타이거 팀이란 무엇인가? 정의, 유래, 그리고 활용 시점

“휴스턴, 문제가 생겼습니다.”

우리 모두는 적어도 한 번쯤은 이 용어를 사용해 본 적이 있습니다. 이 용어는 중요한 무언가가 고장 나고, 이를 신속하게 수리해야 하는 절박한 순간을 가리키는 약어로 자리 잡았습니다.

업무 현장에서 이는 대개 여러 팀에 영향을 미치는 문제를 의미합니다. 예를 들어, 여러 차례의 수정 과정에서도 남아 있던 버그 하나가 고객 데이터베이스 세 곳을 마비시키고, 지원 티켓 건수를 급증시키고 있는 경우처럼 말이죠. 이 문제는 엔지니어링 팀에서 시작되었지만, 이제는 지원팀, 제품팀, 고객 성공팀까지 모두 이 문제의 일부를 책임지고 있습니다.

바로 그때 필요한 것은 ‘타이거 팀’입니다. 이는 명확하게 정의된, 매우 중요한 문제를 해결하기 위해 모인 소규모의 임시 전문가 팀입니다. 이 개념은 1960년대 항공우주 분야에서 시작되어 이후 공학, 정부, 보안, 일상적인 운영 분야로 확산되었습니다.

하지만 시간이 흐르면서 이 용어의 의미가 확장되어, 고위 간부 몇 명이 참여하는 거의 모든 긴급 회의에까지 적용되게 되었습니다. 이번 글에서는 타이거 팀이 실제로 무엇인지, 이 용어의 유래는 어디인지, 그리고 종종 혼동되는 태스크포스나 워룸과 어떻게 다른지 자세히 살펴보겠습니다.

타이거 팀이란 무엇인가?

타이거 팀은 단기적으로 운영되는 팀으로, 현재 조직 구조로는 필요한 속도로 해결할 수 없는 단 하나의 문제를 해결하는 것을 유일한 임무로 삼습니다.

명칭보다 구조가 더 중요합니다. 타이거 팀은 명확한 목표, 이를 조사할 전문 지식, 그리고 또 다른 상임위원회가 되지 않으면서도 행동할 수 있는 충분한 권한이 필요합니다.

타이거 팀은 일반적으로 다음과 같은 몇 가지 공통된 특징을 공유합니다:

미국 노동부의 실업보험 ‘타이거 팀’에서 이러한 구조를 확인할 수 있습니다. 2021년부터 노동부는 사기 방지, 고객 경험, 실업보험, 데이터, 시스템 엔지니어링 분야의 전문가들을 한데 모아 각 주별 프로그램의 문제점을 평가하고 단기 개선 방안을 제안해 왔습니다. 출범 후 첫 24개월 동안 이 팀들은 36개 주와 협력했습니다.

하지만 모든 타이거 팀이 똑같은 형태를 띠는 것은 아닙니다. 일부 회원은 평소 일에 부분적으로 계속 참여하기도 하고, 다른 회원은 일에서 완전히 손을 떼기도 합니다.

“타이거 팀”이라는 용어는 어디서 유래했을까요?

이 용어는 1960년대 미국 항공우주 산업에서 유래했으며, 비즈니스 문제 해결 분야에서 흔히 쓰이는 용어가 되기 훨씬 이전의 일입니다.

이 용어가 문헌에 처음 등장한 사례 중 하나는 1964년 J. R. 뎀시(J. R. Dempsey), W. A. 데이비스(W. A. Davis), A. S. 크로스필드(A. S. Crossfield), 월터 C. 윌리엄스(Walter C. Williams)가 공동 집필한 SAE 논문 『설계 및 개발에서의 프로그램 관리(Program Management in Design and Development )』에 실려 있습니다. 이 논문은 타이거 팀을 경험, 열정, 상상력을 바탕으로 선발된 “길들여지지 않고 자유분방한 기술 전문가”들로 구성된 그룹으로 묘사했습니다. 이들의 임무는 우주선 시스템과 시뮬레이션에서 발생할 수 있는 결함 원인을 끈질기게 찾아내는 것이었습니다.

그리고 이들은 단순히 한 방에 모인 고위 전문가들이 아니었습니다. 이들은 기존 가정에 의문을 제기하고, 다른 사람들이 간과한 취약점을 찾아내며, 프로그램 운영에 따르는 일반적인 제약 조건에서 벗어나 일을 해야 했습니다.

6년 후, 아폴로 13호는 이 용어에 가장 유명한 연상 이미지를 부여했습니다. 1970년 4월 13일, 우주선이 지구에서 약 20만 마일 떨어진 지점에 있을 때 산소 탱크가 폭발했습니다. 잭 스위거트는 미션 컨트롤에 “휴스턴, 여기 문제가 생겼습니다(Houston, we’ve had a problem here)”라고 무전했고 , 이 대사는 나중에 “휴스턴, 문제가 생겼습니다(Houston, we have a problem)”라는 문구로 대중문화에 자리 잡았습니다.

그 후 NASA 비행 책임자 진 크란즈 ( Gene Kranz)는 NASA 기록에 ‘아폴로 13호 타이거 팀 ’으로 묘사된 팀을 이끌며 , 더 넓은 범위의 임무 운영 팀과 협력하여 우주비행사들의 안전한 귀환을 가로막고 있던 문제들을 해결했습니다. 아폴로 13호 임무 운영 팀은 이 구조 작전에서 수행한 역할을 인정받아 이후 대통령 자유 훈장을 수상했습니다.

아폴로 13호는 압박 속에서 집중적으로 문제를 해결하는 모델로서 ‘타이거 팀’의 위상을 확고히 하는 데 기여했지만, 이 용어를 처음 만든 것은 아닙니다.

타이거 팀 vs. 태스크 포스, 워 룸, 레드 팀, 스컹크웍스

타이거 팀은 종종 태스크포스, 워룸, 레드 팀, 스컹크웍스 등 다른 그룹 구조와 혼동되곤 합니다. 이들 모두 일반적인 팀 구조 밖에서 활동하는 소규모 그룹을 포함할 수 있지만, 구성 목적은 각기 다릅니다.

타이거 팀과 태스크포스를 가장 쉽게 혼동하기 쉬운 이유는 두 조직 모두 여러 기능의 인력을 한데 모을 수 있기 때문입니다. 차이점은 임무 범위에 있습니다. 태스크포스는 광범위한 문제를 조사하거나, 특정 계획을 조정하거나, 개선안을 제안할 수 있습니다. 반면 타이거 팀은 일반적으로 더 좁은 범위의 문제를 맡으며, 이를 신속하게 해결하기 위해 더 많은 자율성을 부여받습니다.

워룸은 다른 맥락에서 시작됩니다. 워룸은 이미 진행 중인 인시던트를 중심으로 구축되며, 이에 대응하는 사람들에게 의사결정을 위한 공유 공간과 일정한 리듬을 제공합니다. 즉각적인 인시던트 상황에서 상황이 안정된 후 집중적인 대응이 필요한 더 근본적인 문제가 드러날 경우, 워룸에서 타이거 팀이 구성될 수 있습니다.

레드 팀은 보다 의도적으로 적대적인 성격을 띱니다. 예시로, 사이버 보안 분야에서 NIST는 레드 팀을 적의 공격이나 악용 능력을 모방하기 위해 조직된 팀으로 정의합니다. 목표는 시스템에 도전함으로써 취약점을 찾아내는 것입니다. 타이거 팀도 이러한 사고방식을 활용할 수 있지만, 더 광범위한 책임은 팀이 결성된 목적인 문제 자체를 해결하는 데 있습니다.

스컹크웍스 (Skunkworks)는 이와 다른 방향을 지향합니다. 록히드 마틴(Lockheed Martin)의 ‘스컹크웍스’로 유명해진 이 모델은 소규모 그룹에 새로운 것을 개발할 수 있는 이례적인 자율권을 부여합니다. 타이거 팀은 대개 해결 조건이 정해진 문제를 중심으로 구성됩니다. 반면 스컹크웍스 팀은 아이디어를 탐구하고, 설계하고, 테스트하는 동안 훨씬 더 오랫동안 함께 활동할 수 있습니다.

이러한 구분은 중요합니다. 팀 이름에 더 긴급하게 들리는 이름을 붙인다고 해서 그 팀의 운영 방식이 바뀌는 것은 아니기 때문입니다. 타이거 팀을 구성하기 전에, 우선 그 문제가 과연 그러한 특정 구조를 필요로 하는지 여부를 먼저 따져보는 것이 더 현명한 접근입니다.

타이거 팀은 언제 구성해야 할까요?

타이거 팀은 문제가 여러 부서에 걸쳐 있거나, 전문가의 의견이 필요하거나, normal 절차에서 진전이 멈춘 경우에 구성하는 것이 합리적입니다. 하지만 전문가들을 임시 팀에 투입하면, 그들이 이미 담당하고 있는 일에서 손을 떼게 되는 결과도 초래합니다.

좋은 사건은 대개 다음 네 가지 기준을 충족합니다:

이 모델은 고위험 변경 사항이 운영 환경이나 출시 단계에 도달하기 전, 예방 차원에서도 활용할 수 있습니다.

타이거 팀의 주요 역할은 무엇인가요?

타이거 팀은 인원이 많을 필요는 없지만, 구성원 각자는 자신의 담당 역할을 명확히 파악하고 있어야 합니다. 대부분의 경우, 다음과 같은 몇 가지 핵심 역할이 필요합니다:

소규모 팀에서는 한 사람이 여러 역할을 맡을 수 있습니다. 핵심은 권한, 일상적인 소유권, 전문 지식, 문서화 업무가 각각 명확한 담당자를 갖는 것입니다.

7단계로 알아보는 타이거 팀 운영 방법

팀이 구성되면, 조사가 끝없는 회의, 가설, 그리고 서로 연결되지 않은 수정 작업의 연속으로 변질되지 않도록 일에 충분한 체계가 필요합니다. 다음 단계들은 팀이 첫 번째 세션부터 검증 및 인계에 이르기까지의 과정을 안내합니다.

1. 목표를 실행 가능한 브리핑으로 전환하기

모든 타이거 팀에는 ‘종료 조건’이 필요합니다. 이는 문제가 해결되어 팀을 해산할 수 있음을 모든 구성원에게 알리는 구체적인 결과입니다. 먼저 이에 대해 합의한 다음, 구성원들이 일상적인 의사결정을 내릴 때 지침으로 삼을 수 있도록 구체화하십시오.

간결한 업무 브리핑 만으로도 대개 충분합니다. 브리핑에는 다음 사항이 포함되어야 합니다:

마지막 질문에 특히 주의를 기울이세요. 처리 대기열이 점점 늘어나는 상황에서 업무를 처리하는 운영 팀을 상상해 보세요. 대기열을 500건 미만으로 줄이는 것은 그날 오후의 성과로 느껴질 수 있습니다. 하지만 매일 들어오는 업무량이 처리량을 계속 앞지르는 상황에서도 일주일 내내 그 수치를 유지한다면, 이는 문제 해결책이 지속될 것이라는 훨씬 더 확실한 증거가 됩니다.

2. 역할, 의사결정 권한, 그리고 업무 범위를 명확히 정하십시오

먼저 팀장, 후원자, 전문가, 그리고 작업 기록을 최신 상태로 유지할 담당자를 지정하십시오. 그런 다음 의사결정 권한에 대한 문제를 조기에 확정하십시오. 팀은 일부 사안에 대해서는 자체적으로 결정할 수 있고, 일부는 후원자의 승인이 필요하며, 또 일부는 여전히 해당 사안을 관장하는 원래 팀에 속합니다.

또한 팀은 일 범위에 대한 명확한 경계를 설정해야 합니다. 조사가 본격화되기 전에 다음 사항을 기록해 두십시오:

마지막 항목은 업무가 본래의 목적에서 벗어나는 것을 방지해 줍니다. 예를 들어, 결제 관련 조사를 진행하다 보면 가격 책정, 계정 설정, 또는 고객 온보딩 과정에서 문제가 발견될 수 있습니다. 그중 일부는 나중에 해결해도 될 수 있지만, 이 모든 문제를 현재 진행 중인 업무에 포함시키다 보면 2주간의 노력이 2개월로 늘어날 수 있습니다.

업무 처리 능력(Capacity)에도 동일한 주의를 기울여야 합니다. 긴급한 업무를 재배정하고, 가능한 경우 마감일을 조정하며, 변경 사항이 있는 소유자에게 상황을 알리십시오. 그렇지 않으면 팀원들이 기존에 담당하던 업무에 더해 타이거 팀 업무까지 떠안게 될 것입니다.

3. 증거와 가설을 구분한 후, 무엇을 검증할지 결정하십시오

타이거 팀이 구성될 무렵이면, 여러 사람이 문제의 원인에 대해 각자의 설명을 내놓을 수 있습니다. 먼저 팀이 알고 있는 사실과 추측하는 내용을 구분하는 것부터 시작하십시오.

이 과정의 일환으로 이전의 수정 사항, 실험 결과, 인시던트 노트, 결정 사항을 검토하십시오. 오늘 유망해 보이는 해결 방안이 이미 6개월 전에 테스트되었을 수도 있습니다. 이를 바탕으로 가장 설득력 있는 설명들을 간결한 가설 목록으로 정리하십시오. 각 가설에 대해 어떤 상황이 발생하고 있다고 생각하는지, 이를 지원하는 증거는 무엇인지, 어떻게 검증할 것인지, 그리고 그 결과가 무엇을 시사하는지를 명확히 기록하십시오.

배울 수 있는 내용에 따라 우선순위를 정하세요. 문제의 대부분을 설명할 수 있고 테스트하는 데 1시간밖에 걸리지 않는 가설은, 일주일간의 엔지니어링 일이 필요한 가설보다 우선적으로 고려해야 합니다.

4. 수사에 영향을 미칠 수 있는 결정 사항들을 기록해 두십시오.

팀의 향후 활동에 영향을 미칠 수 있거나, 나중에 누군가가 합리적으로 파악해야 할 필요가 있을 수 있는 통화 내용을 기록해 두십시오. 여기에는 수용된 위험, 거부된 기술적 접근 방식, 범위 변경, 또는 가설 추구를 중단하기로 한 결정 등이 포함될 수 있습니다.

새로운 증거로 인해 기존 가설이 뒤집힐 때마다 기록을 검토하고, 현재의 결정과 그 근거가 된 증거의 가시성을 유지하십시오.

5. 문제가 업무 리듬을 설정하게 하라

타이거 팀의 회의 빈도는 문제의 변화 속도에 따라 달라집니다. 실제 서비스 중단 상황에서는 팀이 몇 시간마다 다시 모여 논의할 수 있습니다. 진행 속도가 느린 데이터 문제에 대한 2주간의 조사라면, 보통 일주일에 두세 번 정도 현황 점검을 통해 관리할 수 있습니다.

진행 속도가 어떻든 간에, 모든 회의에는 명확한 목적이 있어야 합니다. 상황을 바꿀 만한 새로운 증거, 후원자만이 해결할 수 있는 장애물, 또는 팀이 함께 내려야 할 결정 등이 모두 이에 해당합니다. 일상적인 진행 상황은 서면 기록에 더 잘 정리해 두는 것이 좋으며, 이를 통해 구성원들은 시간이 날 때마다 내용을 검토할 수 있습니다.

작업 기간이 2주 이상으로 길어질 경우, 중간 검토 일정을 잡으십시오. 이를 통해 팀은 일상적인 조사 업무에서 한 발 물러나 다음과 같은 질문을 던질 기회를 갖게 됩니다:

이 단계에서 솔직한 답변을 통해 팀이 후반부에 잘못된 문제에 시간을 낭비하는 것을 막을 수 있습니다.

이 과정에 이해관계자들이 직접 참여할 필요는 대개 없습니다. 팀이 무엇을 파악했는지, 무엇을 결정했는지, 그리고 어떤 부분에서 난관에 부딪혔는지를 담은 짧은 서면 노트를 며칠에 한 번씩 전달하면, 필요할 때 즉시 개입할 수 있을 만큼 충분히 상황을 파악할 수 있습니다.

6. 수정 조치가 효과를 입증할 시간을 주십시오

수정 사항이 출시 당일에는 설득력 있게 보일지라도, normal한 트래픽, 처리량 또는 예외적인 상황이 다시 발생하면 문제가 재발할 수 있습니다. 그렇기 때문에 팀은 수치가 개선되었다고 해서 바로 문제가 해결되었다고 선언해서는 안 됩니다.

수정 사항에 대한 모니터링 기간은 문제가 재발할 가능성이 얼마나 높은지에 따라 달라집니다. 예시로, 트래픽이 많은 서비스의 경우 몇 시간 내에 신뢰할 수 있는 신호를 얻을 수 있습니다. 반면, 월간 재무 마감의 경우 수정 사항이 안정적으로 유지되었다고 판단하기까지 한 번의 전체 주기가 더 필요할 수 있습니다.

기다리는 동안 다음 두 가지 번호를 보기 바랍니다:

번호가 다시 원래 수준으로 돌아오기 시작하면, 이를 새로운 증거로 간주하십시오. 이를 조사에 반영하여 어떤 변화가 일어나는지 살펴보십시오. 이를 통해 다른 가설이 최우선 순위로 떠오르거나, 원래의 진단이 문제의 일부만을 설명했을 뿐이라는 사실이 드러날 수도 있습니다.

7. 일을 깔끔하게 인계하기

이 시점에서 팀은 이미 업무 인계에 필요한 대부분의 자료를 준비해 놓은 상태입니다. 작업 개요서, 증거 자료, 테스트 결과, 의사결정 기록, 검증 데이터 등이 모두 기록에 포함되어 있습니다. 이를 다듬어 완성도 높은 최종 보고서로 재작성하는 것은 일만 늘릴 뿐 별다른 이점은 없습니다.

대신, 해당 기록들을 한데 모아 남은 소유권을 분명히 드러내야 합니다. 최종 소유자는 다음 사항을 확실히 인지한 채 자리를 떠나야 합니다:

누군가 자리를 떠나기 전에 다음 질문에 답해 보세요: 문제가 재발하면 누구에게 연락해야 할까요?

결과가 도출되고 결론이 확정되면 타이거 팀은 해체될 수 있습니다. 회원들은 본래의 일로 복귀하고, 진행 중인 일은 기존 조직 체계로 다시 이관되며, 조사 결과는 향후 필요할 경우를 대비해 기록으로 남게 됩니다.

사후 대응형 타이거 팀 대 예방형 타이거 팀

타이거 팀은 대개 다음 두 가지 시점 중 하나에서 투입됩니다. 어떤 팀은 문제가 이미 비즈니스에 영향을 미치기 시작한 후에 구성되기도 하고, 다른 팀은 취약점을 파악하고 플랜을 수정할 시간이 아직 남아 있는 초기 단계에 투입되기도 합니다.

차이는 결국 팀이 무엇을 파악하고자 하는지에 달려 있습니다.

사후 대응형 타이거 팀은 이미 진행 중인 문제에서 출발합니다.

이것이 바로 대부분의 사람들이 ‘타이거 팀’이라고 하면 떠올리는 전형적인 버전입니다. 출시 일정이 지연되거나, 서비스 중단이 반복되거나, 핵심 프로세스에 장애가 발생하거나, 여러 팀이 원인을 파악하지 못한 채 해결책을 모색하고 있는 상황 등이 이에 해당합니다.

이 시점에서 타이거 팀은 조사할 수 있는 증거를 확보한 상태입니다. 이들의 임무는 이러한 단서들을 연결하고, 근본 원인을 좁혀가며, 가장 설득력 있는 가설을 검증하여 시스템을 다시 안정적인 상태로 되돌리는 것입니다.

이 단계에 도달하는 데는 상당한 비용이 소요될 수 있습니다. 업타임 인스티튜트(Uptime Institute)의 ‘2025년 글로벌 데이터 센터 설문조사’에 따르면, 지난 3년 동안 중대한 서비스 중단을 경험한 응답자의 87%가 더 나은 관리, 프로세스 또는 구성을 통해 이를 방지할 수 있었을 것이라고 답했습니다.

또한 ‘2026년 연간 정전 분석(Annual Outage Analysis 2026 )’ 보고서에 따르면, 응답자의 57%가 가장 최근에 발생한 대규모 정전으로 10만 달러 이상의 손실을 입었다고 답했으며, 5명 중 1명은 그 비용이 100만 달러를 넘었다고 답했습니다. 이러한 수치는 데이터 센터에 한정된 것이므로, 모든 타이거 팀에 대한 보편적인 기준으로 간주해서는 안 됩니다.

하지만 이들은 사후 대응 조치 이후의 일이 당장의 해결책으로 끝나서는 안 되는 이유를 분명히 보여줍니다. 상황이 안정되면, 문제가 그 지경에 이르도록 방치된 조건을 면밀히 살펴봐야 합니다.

예방적 타이거 팀은 문제를 조기에 파악합니다

예방적 타이거 팀은 플랜을 수정할 여지가 남아 있을 때 활동을 시작합니다.

NASA는 이 접근 방식을 직접 적용한 바 있습니다. NASA의 공학 및 안전 센터(Engineering and Safety Center)가 CALIPSO 우주선의 추진 시스템을 검토하기 위해 평가팀을 구성했을 때, 이 팀은 발사 전 가능한 고장 경로를 분석하기 위해 고장 트리(fault tree)를 구축했습니다. NASA가 공학 및 안전 센터의 15년 역사를 되돌아본 보고서에서, NESC 소장 팀 윌슨(Tim Wilson)은 이 접근 방식을 다음과 같이 설명했습니다:

저희의 접근 방식은 발생할 수 있는 모든 것을 보여주는 고장 트리(fault tree)를 작성하고, 조립 과정에서 해당 피팅에서 누수가 발생하지 않도록 보장하기 위한 적절한 통제 수단이 마련되어 있는지 확인하는 것이었습니다.

이는 초기 항공우주 타이거 팀의 정신과 매우 유사합니다. 팀에게는 중대한 과제가 주어지며, 그 결과가 나타나기 전에 이를 해결해 내야 합니다.

그 결과물로, 프로젝트 전반에 걸쳐 다음과 같이 실행 가능한 구체적인 성과를 도출해야 합니다:

실제 예시에서 볼 수 있는 타이거 팀

타이거 팀은 건설, 소프트웨어, 정부 부문에서 활용됩니다. Graham, Grafana Labs, 영국 공공 부문 사기 방지 당국(UK Public Sector Fraud Authority)은 각각 명확한 종료 시점이 정해진 한정된 문제를 해결하기 위해 타이거 팀을 구성했습니다. 사례마다 필요한 전문 지식은 달랐지만, 팀 구성 방식은 동일하게 유지되었습니다.

그레이엄은 타이로드 설치 시간을 51% 단축했습니다.

토목 시공업체 그레이엄(Graham)은 사우스 뱅크 키(South Bank Quay) 프로젝트에서 반복적이면서도 비용이 많이 드는 공정을 중심으로 타이거 팀을 구성했습니다. 작업팀은 각각 38미터 이상 길이로 부두 벽을 앵커 벽에 고정하는 166개의 타이 로드를 설치해야 했습니다.

이 팀은 그레이엄의 프로젝트 담당자, 설치 하도급업체, 타이로드 제조업체 및 기타 공급망 파트너들을 한데 모았습니다. 먼저 설치 공정을 지도한 뒤, 타임랩스 영상과 작업 시간 및 동작 분석을 통해 현장에서 작업 시간을 측정했습니다. 기준치를 확보한 후 공정을 개선하고 다시 측정했습니다.

‘Get It Right Initiative’의 사례 연구에 따르면, 타이로드 1개당 설치 시간이 185분에서 91분으로 약 51% 단축되었으며, 작업 건수도 37% 감소했습니다. 그레이엄은 또한 이 프로그램을 통해 14일의 기간을 단축하고 약 23만 파운드를 절약했다고 보고했습니다.

팀은 프로세스 전반에 걸쳐 사소한 변경 사항을 찾아내어 동일한 일에 적용해 테스트한 결과, 정확히 어떤 부분이 개선되었는지 보여줄 수 있었습니다.

Grafana Labs는 릴리스 문제를 영구적인 소유권 체계로 전환했습니다

Grafana Labs의 오픈소스 릴리스 작업은 점점 더 수작업에 의존하게 되었으며, 이를 개선해야 할 책임은 여러 엔지니어링 팀에 분산되어 있었습니다. 이미 이 문제의 일부를 해결해 오던 세 명의 선임 엔지니어가 한 분기 동안 한 팀을 이루어 워크플로우를 간소화하고, 빌드를 자동화하며, Grafana Cloud 채널에 대한 직접 패치 적용을 지원했습니다.

릴리스 타이거 팀은 수작업 단계를 대폭 줄이고 보안 릴리스를 더 쉽게 처리할 수 있게 했습니다. 분기 말까지 이 일을 통해 Grafana가 전담 릴리스 그룹을 구성할 수 있을 만큼 장기적인 인력 공백이 명확해졌습니다.

이러한 접근 방식은 반복적으로 발생하는 소프트웨어 릴리스 관리 문제를 해결하는 데 도움이 됩니다. 단기간의 개입을 통해 당면한 마찰을 해소하는 동시에, 지속적인 책임 소재를 명확히 할 수 있습니다. Grafana는 주요 파트너사 확보를 지원한 타이거 팀을 포함해 다른 분야에서도 동일한 모델을 적용해 왔습니다.

영국 정부는 사기 위험이 실제 손실로 이어지기 전에 타이거 팀을 활용했습니다.

2022년, 영국의 공공 부문 사기 방지 당국(Public Sector Fraud Authority)은 새로운 에너지 지원 제도가 아직 기획 단계에 있을 때 타이거 팀 모델을 도입했습니다.

이 팀은 정부 부처, 오프젬(Ofgem), 에너지 정산 기관의 사기 전문가들과 에너지 분야 외부 전문가들을 한데 모았습니다. 공공 부문 사기 당국(Public Sector Fraud Authority)의 2022–23 연례 보고서에 따르면, 이 팀은 비즈니스·에너지·산업 전략부(Department for Business, Energy & Industrial Strategy)의 6개 신규 에너지 제도와 영국 재무부(HM Treasury)의 1개 제도에 대한 사기 영향 및 위험 평가를 완료했습니다.

이 일은 프로그램 팀이 전문가들이 발견한 내용을 바탕으로 조치를 취할 수 있을 만큼 충분히 일찍 시작되었습니다. BEIS는 이러한 다양한 전문 범위가 사기 방지 조치를 계획에 반영하는 데 도움이 되었으며, 프로그램이 아직 구상 단계에 있을 때 장관들의 가시성을 높여 주요 위험 요소를 파악할 수 있게 해주었다고 밝혔습니다.

타이거 팀을 좌초시킬 수 있는 5가지 실수

문제와 팀 구조가 명확하더라도, 다음의 다섯 가지 실수는 타이거 팀의 성과를 저해할 수 있습니다.

1. 여러 가지를 한꺼번에 변경하기

압박감이 심할 때면, 유망해 보이는 해결책 세 가지나 네 가지를 한꺼번에 적용해 보고 문제가 해결되는지 확인해 보고 싶은 유혹에 빠지기 쉽습니다.

이를 통해 더 나은 결과를 빠르게 얻을 수 있지만, 한 가지 난처한 의문이 남게 됩니다. 바로 ‘어떤 수정 사항이 효과가 있었는가?’라는 질문입니다. 엔지니어링 타이거 팀이 동일한 릴리스에서 의존성을 업데이트하고, 타임아웃을 변경하며, 용량을 늘린 경우, 오류 발생 건수가 감소했다고 해서 그 원인을 파악하기는 매우 어렵습니다. 또한 나중에 다른 문제가 발생했을 때 롤백하기가 더 어려워집니다.

2. 팀을 전적으로 외부 인력으로 구성하기

새로운 관점은 도움이 될 수 있지만, 해당 시스템을 매일 다루는 사람들은 문서에 기록되지 않은 예외 사항, 우회 방법, 의존성 등을 잘 알고 있는 경우가 많습니다. 이러한 요소들을 간과하면 겉보기에는 깔끔해 보이지만 실제 워크플로우에 적용되는 순간 실패하는 해결책이 나올 수 있습니다.

이는 엔지니어링 분야에만 국한되지 않습니다. 예시로, 승인 절차를 재설계하는 타이거 팀은 해당 절차를 감독하는 리더들뿐만 아니라 매일 그 승인을 처리하는 직원들의 의견도 경청해야 합니다.

3. 타이거 팀을 책임 전가 행사로 전락시키는 것

사람들이 타이거 팀이 문제의 원인을 규명하려는 것으로 인식하게 되면, 정보를 공유하는 데 더 신중해질 수 있습니다. 누군가는 이전에 내린 잘못된 판단을 생략하거나, 실패한 임시 해결책을 언급하지 않으려 하거나, 개인적으로 책임이 있다고 느껴 과거의 결정을 옹호할 수도 있습니다. 이로 인해 팀이 확보할 수 있는 증거가 줄어들고, 진정한 원인을 찾기가 더 어려워집니다.

4. 되돌릴 플랜을 마련하지 않은 채 위험한 변화를 단행하는 것

유망해 보이는 수정 사항이 오히려 새로운 문제를 야기할 수 있습니다. 팀은 변경 사항을 적용하는 방법은 계획했지만, 이를 되돌리는 방법은 고려하지 않았을 때 곤란에 처하게 됩니다. 또한 고객, 데이터 또는 하류 시스템이 변경 사항과 상호 작용을 시작하면 롤백도 더 어려워집니다.

5. 타이거 팀을 위한 두 번째 신뢰할 수 있는 정보원 구축

긴급한 일은 대개 사람들이 가장 빠르게 움직일 수 있는 곳, 즉 개인 채팅, 임시 스프레드시트, 임시 문서, 또는 별도의 프로젝트 보드 등에서 시작됩니다. 문제는 결정 사항, 증거 자료, 작업이 이 모든 곳에 흩어져 있을 때 발생합니다.

한 사람은 채팅에서 최신 결정을 확인하는 반면, 다른 사람은 스프레드시트에서 이전 결정을 바탕으로 작업을 진행합니다. 팀의 닫힘 후에는 무슨 일이 있었는지 재구성하기가 훨씬 더 어려워집니다.

ClickUp에서 타이거 팀을 관리하는 방법

타이거 팀은 적합한 인력과 명확한 임무 지침을 갖추고 있어도, 증거 자료는 한 tool에만 저장되어 있고, 의사 결정은 다른 tool에서 이루어지며, 후속 작업은 또 다른 곳에 분산되어 있다면 시간을 낭비하게 될 수 있습니다. 앞서 언급한 결제 실패 예시를 바탕으로, 한 팀이 ClickUp을 사용하여 전체 노력을 어떻게 운영할 수 있는지 살펴보겠습니다.

첫날 준비하기

최근 릴리스 이후 체크아웃 실패율이 4%까지 상승했고, 스폰서가 타이거 팀에 이 수치를 1% 미만으로 낮추도록 요청했다고 가정해 봅시다. 팀 리더는 먼저 엔지니어링 스페이스 내에 “체크아웃 실패 타이거 팀”이라는 폴더를 생성합니다. 이 일은 타이거 팀이 해체된 후에도 해당 업무를 담당하게 될 팀과 밀접하게 연계되어 관리됩니다.

폴더 내에서 리더는 작업 개요서를 위한 ClickUp 문서를 생성합니다. 여기에는 종료 조건(2주 동안 오류율 1% 미만), 기준선, 성공 및 안전 장치 메트릭, 범위 내·외 항목, 의사결정 권한 및 의사결정 기록 테이블이 포함됩니다. 첫 번째 작업 세션에서 팀은 새로운 결제 API 의존성을 먼저 테스트하기로 합의합니다. 리드는 문서에서 해당 항목을 강조 표시한 후, 브리핑 화면을 벗어나지 않고 이를 작업으로 전환합니다.

가설 대기열 구축

첫 번째 작업은 팀이 검증하고자 하는 다른 모든 가설과 함께 ‘가설 대기열(Hypothesis queue)’이라는 리스트에 포함됩니다. 이 리스트의 상태는 3단계의 증거 분류 체계에 따르며, 진행 중인 작업을 위해 ‘의심됨(Suspected)’, ‘검증 중(Testing)’, ‘확인됨(Confirmed)’, ‘배제됨(Ruled out)’이라는 상태가 추가됩니다. 미확인 사항은 브리핑 문서에 개방형 질문으로 포함될 수 있습니다.

테스트가 완료되면 작업이 이동하며, 팀 전체가 확인된 사실과 여전히 추측에 불과한 부분을 파악할 수 있습니다. 팀 리더는 모든 가설에 ‘영향도’, ‘테스트 비용’, ‘결과’라는 3가지 사용자 지정 필드를 추가합니다. ‘영향도’ 순으로 정렬한 다음 ‘테스트 비용’ 순으로 정렬하면, 가장 많은 현상을 설명할 수 있으면서도 검증에 가장 적은 시간이 소요되는 가설이 상단에 표시됩니다.

이미 시도된 사항 확인하기

엔지니어들이 API 테스트를 실행하기 전, 그중 한 명이 Brain²에게 묻습니다. “결제 제공자의 타임아웃에 대해서는 이전에 테스트해 본 적이 있나요?”

Brain²는 엔터프라이즈 검색 기능을 통해 태스크, 문서, 채팅 및 연동된 앱을 검색하여, 6개월 전의 유사한 조사 사례를 출처 링크와 함께 찾아냅니다. 팀은 지난번에 배제된 내용을 확인하고, 테스트를 조정한 뒤, 링크를 가설 태스크에 붙여넣기하여 해당 이력이 태스크에 계속 연결되도록 합니다.

새로운 요청이 수사에 포함되지 않도록 하기

1주차가 끝날 무렵, 팀 외부에서 가격 표시 버그나 계정 설정 흐름이 느리다는 등 관련 문제들이 제기되기 시작했습니다. 이 문제들은 하나하나가 쉽게 새로운 일로 이어질 수 있습니다.

리드는 ClickUp 양식을 설정하여 제출된 내용을 ‘Parking lot’이라는 별도의 목록으로 전송합니다. 제출된 각 항목은 해당 목록에서 별도의 작업으로 생성되며, 스폰서는 매 체크인 시마다 목록을 검토하여 해당 내용이 범위 내에 포함되어야 하는지 결정합니다.

스폰서가 한 곳에서 모든 정보를 확인할 수 있도록 하기

스폰서는 결정이 자신의 승인을 기다리고 있을 때 개입해야 하지만, 그 외의 조사 과정은 매일매일 일일이 지켜볼 필요는 없습니다.

팀 리더는 “스폰서의 결정 필요”라는 체크박스 필드를 추가하고, 3개의 카드로 구성된 대시보드를 만듭니다. 하나는 스폰서의 결정을 기다리는 작업용, 하나는 진행이 막히거나 기한이 지난 작업용, 그리고 하나는 숫자 필드로 실패율을 추적하는 카드입니다. 스폰서는 매 체크인 전에 이 한 페이지를 엽니다.

알림 및 업데이트를 자동으로 실행하도록 설정하기

2주차에 팀은 임시 해결책으로 영향을 받은 계정에 대한 기능을 비활성화하며, 이 결정은 7일 후에 재검토해야 합니다. 팀 리더는 해당 날짜를 작업의 마감일로 설정하고, 마감일이 되면 소유자에게 알림을 보내는 자동화 기능을 추가합니다.

이해관계자 대상 업데이트 작업도 리더의 시간을 점차 차지하기 시작했습니다. 이제 ‘슈퍼 에이전트’가 매주 Monday와 목요일에 새로운 결정 사항, 진행을 가로막는 장애물, 후원자의 결정을 기다리는 사항 등을 담은 간략한 요약문을 게시합니다.

일 인계

2주 동안 실패율이 1% 미만으로 유지되었으므로, 팀은 종료 조건을 충족했습니다. 팀 리더는 남아 있는 미완료 작업을 결제 팀의 리스트로 이동시키고 담당자를 재지정합니다. 결정 로그의 마지막 항목에는 새로운 소유자와 새로운 조사를 시작해야 하는 조건이 명시됩니다. 그런 다음 팀 리더는 해당 폴더를 보관합니다.

ClickUp 요금제

최고의 타이거 팀은 언제 물러나야 할지 안다

타이거 팀은 통제된 예외 조치입니다. 평소의 조직 구조로는 normal 속도로 처리할 수 없는 문제에 대해, 전문 지식, 권한, 그리고 관심을 일시적으로 집중시키는 것입니다.

따라서 마무리 단계는 개입 과정만큼이나 중요합니다. 문제가 통제 단계에 접어들면, 팀은 자신들의 결정 사항, 증거 자료, 또는 미완료된 일을 떠안지 않고도 현장에서 물러날 수 있어야 합니다. 만약 조직이 여전히 업무를 유지하기 위해 동일한 임시 팀에 의존하고 있다면, 문제는 이미 다른 양상으로 변한 것입니다.

업무 인계 후에도 남아 있는 것은 문제를 어떻게 파악하고 해결했는지에 대한 기록입니다. ClickUp에서는 타이거 팀의 폴더가 보관 처리된 후에도 해당 기록을 계속 검색할 수 있으므로, 다음 소유자는 이를 다시 구성할 필요 없이 개요, 가설, 의사결정 기록을 찾을 수 있습니다.

타이거 팀에 관한 자주 묻는 질문

타이거 팀의 적정 규모는 어느 정도일까요?

정해진 인원 수는 없습니다. 문제의 규모에 맞춰 핵심 인원을 최소한으로 유지한 다음, 전문 지식이 필요할 때만 다른 전문가를 영입하십시오. 인원이 많아지면 의사소통과 일정 조정에 드는 부담이 커집니다. 단순히 증거를 제공하거나 특정 질문에 답변하기만 하면 되는 사람은 반드시 타이거 팀의 정식 회원이 될 필요는 없습니다.

타이거 팀은 원격으로 운영할 수 있을까요?

네. 타이거 팀은 반드시 같은 공간에 모여 있을 필요는 없습니다. 필요한 것은 동일한 증거에 신속하게 접근할 수 있는 환경, 명확한 소유권, 그리고 의사결정을 내릴 수 있는 신뢰할 수 있는 장소입니다. 분산된 팀의 경우, 작업 기록을 최신 상태로 유지하고, 의사결정, 진행을 가로막는 문제, 또는 수사에 변화를 주는 증거가 있을 때에만 실시간 화상 회의를 진행하세요. 이렇게 하면 시간대 차이로 인해 모든 업데이트가 또 다른 회의로 이어지는 것을 방지할 수 있습니다.

타이거 팀은 애자일(Agile)이나 스크럼(Scrum)의 일부인가요?

아닙니다. 타이거 팀은 공식적인 스크럼 역할, 이벤트, 또는 책임 영역이 아닙니다. 공식 스크럼 가이드에서는 제품 소유자, 스크럼 마스터, 개발자로 구성된 스크럼 팀을 정의하고 있습니다. 스크럼을 사용하는 기업은 기존 팀 경계를 넘나드는 문제를 해결하기 위해 타이거 팀을 구성할 수 있습니다. 다만, 이러한 임시 작업이 현재의 스프린트 약속 및 제품 목표와 어떻게 연계될지 결정하기만 하면 됩니다.

타이거 팀은 반드시 기술 전문 팀이어야 할까요?

아닙니다. 이 모델은 항공우주 분야에서 시작되어 현재도 공학 및 보안 분야에서 흔히 사용되지만, 이 구조는 까다로운 문제를 해결하기 위해 집중된 전문 지식이 필요한 곳이라면 어디에서나 적용될 수 있습니다. 타이거 팀은 사기 사건을 조사하거나, 운영 프로세스를 재설계하거나, 규제 문제를 해결하거나, 상업적 문제를 해결하는 데 일할 수 있습니다. 필요한 전문 지식은 문제에 따라 달라집니다.

회사 외부인도 타이거 팀에 합류할 수 있나요?

네. 내부 팀이 갖추지 못한 지식을 보유한 외부 전문가, 공급업체, 컨설턴트 또는 공급망 파트너가 참여할 수 있습니다. 이들에게도 내부 회원과 동일한 수준으로 조사 범위, 접근 권한, 기밀 유지, 의사 결정 권한에 대한 명확한 지침을 제공해야 합니다. 이들은 단순히 조사 결과가 소속 조직에 영향을 미치기 때문이 아니라, 조사에 그들의 전문 지식이 필요하기 때문에 참여해야 합니다.

만약 타이거 팀이 문제를 해결하지 못하면 어떻게 될까요?

팀은 시작 시점보다 더 좁혀진 문제만 남긴 채 조직을 떠나야 합니다. 이는 배제된 요소를 파악하고, 남아 있는 불확실성을 분리하며, 어떤 개입이 실패했는지 문서화하고, 현재 팀이 전문성이나 권한의 한도에 도달한 지점을 보여주는 것을 의미할 수 있습니다. 이를 바탕으로 경영진은 해당 일에 다른 전문가, 더 많은 시간, 상임 소유자, 또는 더 큰 구조적 변화가 필요한지 결정할 수 있습니다. 원래의 종료 조건에 도달하지 못했다고 해서 조사 과정에서 얻은 교훈이 사라지는 것은 아닙니다.

타이거 팀과 크로스-기능 팀의 차이점은 무엇인가요?

“크로스-펑셔널(cross-functional)”은 팀 구성원을 설명하는 용어입니다. “타이거 팀(Tiger team)”은 해당 그룹이 왜 구성되었는지, 그리고 얼마나 오래 유지될 것으로 예상되는지를 설명하는 용어입니다. 크로스-펑셔널 팀은 상설 조직일 수 있으며, 지속적인 제품, 프로세스 또는 비즈니스 영역을 담당할 수 있습니다. 반면 타이거 팀은 특정 문제를 해결하기 위해 구성되며, 해당 임무가 완료되면 해체됩니다. 타이거 팀은 종종 크로스-펑셔널 팀이지만, 이 두 용어는 서로 바꿔서 사용할 수 있는 것은 아닙니다.