한 사람인가, 팀인가? 역량, 의존 관계와 위험을 기준으로 프로젝트 최소 구성을 정하는 방법

연구는 "작은 팀이 항상 더 낫다" 또는 "큰 팀이 항상 더 많은 성과를 낸다" 같은 단순한 규칙을 지지하지 않습니다.

2023년 메타분석은 208개의 독립 효과와 21,435개 팀을 검토했습니다. 전체적으로 팀 규모와 과제 수행 성과 사이의 관계는 사실상 0에 가까웠지만, 상황에 따른 차이는 매우 컸습니다. 저자들은 과제 복잡성과 조정 요구 같은 요소에 따라 팀 규모의 영향이 달라진다고 설명합니다. [4]

복잡한 위기 지도 작성 과제를 사용한 실험에서도 큰 팀의 이점과 비용이 동시에 나타났습니다. 팀이 커질수록 협업은 늘었지만 개인의 노력 방식도 달라졌습니다. 그 특정 실험에서는 가장 큰 팀이 같은 수의 독립 작업자보다 더 높은 성과를 냈습니다. 하지만 이것이 모든 종류의 업무에 적용되는 보편적 처방은 아닙니다. [5]

실무적 결론은 간단합니다. 인원수는 마법의 숫자가 아니라 업무의 성격에서 결정되어야 합니다.

2020 Scrum Guide는 Scrum Team을 작고, 교차 기능적이며, 스스로 업무를 관리하는 팀으로 설명합니다. 또한 일반적으로 10명 이하라고 말합니다. [3]

이 기준은 Scrum의 맥락에서는 유용하지만 모든 프로젝트, 서비스, 산업, 수행 방식에 적용되는 보편적 법칙은 아닙니다.

건설 프로젝트, 마케팅 캠페인, 보안 평가, 금융 시스템, 작은 정보 제공 사이트는 요구사항이 크게 다릅니다. 하나의 숫자를 이런 서로 다른 상황에 그대로 적용해서는 안 됩니다.

영국 Service Standard는 디지털 서비스 팀이 여러 전문 분야를 아우르고 적절한 범위의 역량에 접근할 수 있어야 한다고 요구합니다. 또한 팀 구성은 해당 단계에서 달성해야 할 목표에 맞아야 한다고 설명합니다. [1]

별도의 GOV.UK 지침은 서비스 구축 단계에 따라 팀 규모와 필요한 역할이 달라진다고 설명합니다. [2]

여기서 실용적인 원칙을 도출할 수 있습니다.

먼저 업무와 책임을 정리하고, 그다음 필요한 역량을 정한 뒤, 마지막에 구체적인 사람을 배치하세요.

범위가 불명확한 프로젝트는 적절한 팀 구성을 정하기 어렵습니다.

최소한 다음을 적어 두세요.

• 어떤 결과를 만들어야 하는가
• 무엇이 범위에 포함되는가
• 무엇이 범위 밖인가
• 가장 중요한 품질 요구사항은 무엇인가
• 시간과 예산 제약은 무엇인가
• 누가 결과를 승인하거나 인수하는가
• 팀이 솔루션을 전달하기만 하는가, 아니면 운영까지 맡는가

**"애플리케이션을 만든다"**는 프로젝트와 **"애플리케이션을 설계하고, 만들고, 보호하고, 배포하고, 1년 동안 운영한다"**는 프로젝트는 필요한 업무 범위가 완전히 다릅니다.

바로 직함을 배치하지 말고 실제로 수행해야 할 업무 종류부터 목록으로 만드세요.

디지털 서비스라면 예를 들어 다음이 포함될 수 있습니다.

• 사용자 요구 파악
• 솔루션 설계
• 사용자가 보는 부분 구현
• 서버 측 로직과 연동 구현
• 테스트
• 보안
• 접근성
• 배포와 운영
• 범위와 의사결정 조정

다른 종류의 프로젝트라면 목록도 달라집니다.

GOV.UK는 디지털 서비스를 만들고 운영하는 팀이 사용자 요구, 설계, 구현, 테스트, 보안, 배포, 운영을 포함한 폭넓은 역량을 갖춰야 한다고 설명합니다. [2]

필요한 모든 역량이 팀 안의 전일제 한 사람을 의미하지는 않습니다.

각 영역을 다음처럼 구분해 보세요.

상시 - 꾸준히 필요하고 일상적인 의사결정에 직접 영향을 줍니다.
주기적 - 특정 단계나 검토 시점에 필요합니다.
외부 활용 가능 - 응답 시간과 책임이 충분히 명확하다면 다른 사람이나 팀이 제공할 수 있습니다.

GOV.UK는 전문 지식이 필요할 때 해당 전문가가 반드시 상시 팀원일 필요 없이 팀이 그 전문성에 접근할 수 있는 방식을 명확히 허용합니다. [1]

이렇게 하면 중요한 전문성을 잃지 않으면서 불필요하게 팀을 키우는 일을 피할 수 있습니다.

두 사람이 합쳐서 모든 필요한 역량을 가지고 있어도, 모든 업무가 하나의 좁은 의존 사슬에 놓여 있다면 좋은 구성이라고 할 수 없습니다.

다음을 확인하세요.

• 어떤 작업을 병렬로 진행할 수 있는가
• 어떤 작업은 다른 작업이 끝날 때까지 기다려야 하는가
• 후속 작업을 막을 수 있는 의사결정은 누가 하는가
• 프로젝트가 어떤 외부 팀이나 공급자에 의존하는가
• 한 사람의 부재가 동시에 여러 영역을 멈추는 지점은 어디인가

GOV.UK는 다른 팀에 대한 의존 관계를 관리하는 능력을 디지털 서비스 구축에 필요한 역량 중 하나로 제시합니다. [2]

여러 팀이 하나의 서비스를 함께 맡는다면 계획과 진행 상황을 팀 사이에서 조정해야 하는 추가적인 필요도 생깁니다. [8]

필요한 전문성 중 일부는 제품 기능 목록에는 보이지 않지만, 빠졌을 때 큰 비용이 생길 수 있습니다.

프로젝트에 따라 다음이 포함될 수 있습니다.

• 보안
• 개인정보와 데이터 보호
• 접근성
• 법적 또는 산업별 요구사항
• 신뢰성
• 데이터 이전
• 핵심 시스템과의 연동
• 팀이 이전에 사용하지 않은 기술

GOV.UK는 프로젝트가 필요로 할 때 전문 지식에 접근할 수 있어야 하며, 팀 구성도 현재 단계의 가장 위험한 가정을 반영해야 한다고 설명합니다. [1]

그렇다고 모든 위험마다 별도 전일제 직무가 필요하다는 뜻은 아닙니다. 역량 있는 누군가가 명확한 책임을 가지고 실제 의사결정에 영향을 줄 수 있어야 한다는 뜻입니다.

한 사람이 설계, 개발, 테스트, 배포를 모두 할 줄 알 수 있습니다. 그렇다고 어떤 일정에서도 이 모든 일을 동시에 수행할 수 있다는 뜻은 아닙니다.

PMI의 자원 계획 자료는 프로젝트 필요와 기술, 가용성, 비용, 경험을 맞추는 중요성을 강조합니다. [7]

각 사람에 대해 확인하세요.

• 실제로 얼마나 많은 시간을 투입할 수 있는가
• 어떤 작업이 같은 사람의 주의를 두고 경쟁하는가
• 어떤 업무가 병렬로 진행되어야 하는가
• 일정이 여러 종류의 업무 사이에서 비현실적인 전환을 가정하고 있지는 않은가
• 출시 후에도 누군가 솔루션을 운영해야 하는가

역량이 모두 있어도 시간이 부족하면 프로젝트 전체를 제대로 커버한 것이 아닙니다.

최소 구성에는 연속성도 포함되어야 합니다.

다음을 물어보세요.

• 핵심 사람이 부재하면 무슨 일이 생기는가
• 솔루션의 중요한 부분을 한 사람만 이해하고 있지는 않은가
• 의사결정과 지식이 기록되어 있는가
• 다른 사람이 핵심 업무를 인수할 수 있는가
• 부재 기간 동안 프로젝트를 안전하게 멈출 수 있는가

모든 소규모 프로젝트에 완전한 대체 인력이 필요한 것은 아닙니다. 짧고 위험이 낮은 프로젝트라면 이런 위험을 의식적으로 받아들이는 것도 합리적일 수 있습니다.

반대로 중요한 프로젝트에서는 같은 한 사람 의존이 허용되지 않을 수 있습니다.

프로젝트가 모든 역할 이름마다 별도 사람을 필요로 하는 것은 아닙니다.

한 사람이 실제로 필요한 역량을 갖고 있고, 충분한 투입 가능 시간이 있으며, 허용할 수 없는 위험을 만들지 않는다면 여러 영역을 책임감 있게 담당할 수 있습니다.

예를 들어 작은 프로젝트에서는 한 사람이 인터페이스 설계와 구현을 함께 맡을 수 있습니다. 다른 프로젝트에서는 사업 분석과 범위 조정을 함께 맡을 수도 있습니다.

단지 "누군가는 해야 하니까" 책임을 합치지는 마세요. 두 책임을 요구되는 수준으로 수행할 능력과 시간이 모두 있을 때만 합치는 것이 합리적입니다.

다음 조건이 동시에 충족된다면 한 사람이 합리적인 구성이 될 수 있습니다.

• 범위가 작고 명확하다
• 필요한 역량이 실제로 그 사람의 능력 안에 있다
• 많은 병렬 작업이 필요하지 않다
• 외부 의존 관계가 제한적이다
• 위험이 허용 가능한 수준이다
• 일정이 실제 투입 가능 시간과 맞는다
• 대체 인력이 없다는 위험을 의식적으로 받아들였다

작은 정보성 결과물, 단순 분석, 일회성 자문, 익숙한 환경에서의 제한된 구현 등이 예가 될 수 있습니다.

그래도 구체적인 범위가 결정적입니다. **"작은 프로젝트"**라는 이름만으로 답이 정해지지는 않습니다.

다음 조건이 여러 개 나타날수록 팀 구성이 더 타당해집니다.

• 필요한 역량 범위가 한 사람이 감당하기에는 너무 넓다
• 여러 작업이 동시에 진행되어야 한다
• 일정이 현실적인 순차 수행보다 짧다
• 프로젝트에 의존 관계와 접점이 많다
• 위험 때문에 독립된 전문 지식이 필요하다
• 솔루션을 만들면서 동시에 운영해야 한다
• 한 사람이 프로젝트 전체의 핵심 단일 지점이 된다
• 책임이 서로 다른 여러 전문 분야에 걸쳐 있다

이런 상황에서는 단순히 사람 수를 늘리는 것보다 빠진 역량을 채우는 것이 더 중요합니다.

사람을 추가하면 이용 가능한 지식과 잠재적 업무 처리 능력이 늘어납니다. 하지만 의존 관계, 업무 인계, 의사결정 조정 필요도 함께 늘어날 수 있습니다.

Journal of Systems and Software에 발표된 소프트웨어 프로젝트 연구는 팀 규모, 생산성, 노력, 시간 사이의 관계가 복잡하며 직관적 기대와 항상 일치하지 않는다고 보고했습니다. [6]

팀 규모에 관한 메타분석도 결과가 과제 맥락과 팀 내 과정에서 발생하는 비용에 따라 달라진다고 보여 줍니다. [4]

따라서 질문은 **"몇 명을 더 추가할 수 있는가?"**가 아니라 **"다음 한 사람이 추가적인 조정 비용보다 더 큰 실제 제약을 제거하는가?"**여야 합니다.

모든 중요한 역량이 매일 팀 안에 있을 필요는 없습니다.

상시 참여는 그 사람이 자주 의사결정을 내리거나, 다른 영역과 의존 관계가 많거나, 빠른 대응이 중요한 경우 더 적합합니다.

주기적 지원은 검토, 자문, 위험 평가, 전문 검수처럼 특정 시점에만 전문성이 필요한 경우 충분할 수 있습니다.

한 가지 조건이 있습니다. 가용성은 명목상이 아니라 실제여야 합니다. 다음이 분명해야 합니다.

• 누가 책임지는가
• 언제 이용 가능한가
• 기대 응답 시간은 얼마인가
• 어떤 결정을 내릴 수 있는가
• 문제를 발견하면 이후 절차는 무엇인가

책임이 정해지지 않은 전문가에게 형식적으로만 접근할 수 있는 구조는 조직도에서는 좋아 보여도 실제 프로젝트에서는 작동하지 않을 수 있습니다.

온라인 예약 시스템을 출시한다고 가정해 보겠습니다.

안 A: 아이디어를 검증하기 위한 단순 프로토타입
범위가 제한적이고 결제나 특히 민감한 데이터가 없으며, 소규모 사용자 집단으로 흐름을 확인하는 것이 목표입니다. 폭넓은 역량을 가진 한 사람이 설계와 구현을 맡고, 필요할 때 주기적으로 자문을 받는 구성이 가능할 수 있습니다.

안 B: 계정, 결제, 연동을 포함한 공개 서비스
더 많은 전문화, 테스트, 위험, 의존 관계, 병렬 작업이 필요합니다. 여러 사람으로 구성된 팀이 훨씬 더 타당해집니다.

안 C: 계속 운영되며 문제에 빠르게 대응해야 하는 서비스
구축 외에도 운영, 모니터링, 장애 대응, 지식 연속성이 필요합니다. 출시할 때 충분한 구성도 지속적인 운영에는 부족할 수 있습니다.

일반적인 제품 유형은 같지만 범위, 위험, 운영 방식이 달라지면 필요한 팀 구성도 달라집니다.

1. 해야 할 일보다 미리 정한 직함 목록에서 시작합니다.

2. 모든 역할에 별도 사람이 필요하다고 가정합니다.

3. 역량만 보고 실제 투입 가능한 시간을 무시합니다.

4. 의존 관계와 병목을 없애지 않은 채 사람만 추가합니다.

5. 눈에 보이는 기능을 만들지 않는다는 이유로 위험 대응 역량을 빼버립니다.

6. 위험을 의식적으로 수용하지 않은 채 여러 핵심 영역을 한 사람에게 의존시킵니다.

7. 프로젝트 시작 시점의 구성이 끝까지 변하지 않는다고 가정합니다.

GOV.UK는 서비스 개발 단계에 따라 팀 규모와 역할이 변한다고 명확히 설명합니다. [2]

공공 서비스 밖에서도 합리적인 원칙입니다.

• 초기에는 조사와 문제 정의가 더 많이 필요할 수 있습니다
• 구현 단계에서는 제작과 테스트 역량의 비중이 커집니다
• 출시 전에는 보안, 품질, 운영 준비가 더 중요해질 수 있습니다
• 출시 후에는 개발과 운영 사이의 균형이 바뀝니다

최소 구성은 단계와 범위에 따라 달라지는 값이지, 프로젝트 전체 기간에 고정된 숫자가 아닙니다.

중요한 각 영역에 대해 다섯 가지를 적으세요.

업무 영역 - 무엇을 해야 하는가?
역량 - 어떤 지식과 능력이 필요한가?
책임 - 누가 결정하고 결과를 책임지는가?
가용 방식 - 상시, 주기적, 외부 활용 중 무엇인가?
부재 위험 - 역량이나 사람이 없으면 무슨 일이 생기는가?

그런 다음 구체적인 사람을 배치하세요.

한 사람이 여러 줄을 맡는다면 시간과 의존 관계를 확인하세요. 한 줄에 여러 사람이 필요하다면 그 이유가 업무 처리 능력, 독립 검토, 병렬 작업 중 무엇인지 확인하세요.

1. 모든 필수 업무 영역에 책임자가 있는가?
2. 모든 핵심 책임을 적절한 역량을 가진 사람이 맡고 있는가?
3. 여러 역할을 맡은 사람이 실제로 충분한 시간을 갖고 있는가?
4. 현재 구성으로 감당할 수 없는 병렬 작업이 필요한가?
5. 다른 사람, 팀, 공급자에 대한 주요 의존 관계를 알고 있는가?
6. 중요한 위험에 필요한 전문 지식을 이용할 수 있는가?
7. 한 사람의 부재가 프로젝트 전체를 멈출 수 있는가?
8. 범위에 포함된다면 구축뿐 아니라 출시와 운영에도 충분한가?
9. 상시가 아니라 주기적으로 이용해도 되는 역량을 구분했는가?
10. 범위나 단계가 바뀔 때 구성을 다시 평가할 시점을 정했는가?

팀 설계는 다음 질문에서 시작하면 안 됩니다.

"이런 프로젝트에는 보통 몇 명이 필요한가?"

더 좋은 순서는 다음과 같습니다.

결과 -> 업무 -> 역량 -> 의존 관계 -> 위험 -> 실제 투입 가능 시간 -> 사람.

이 순서로 검토했을 때 한 사람이 정말 모든 것을 커버한다면 한 사람이 맞는 선택일 수 있습니다.

역량, 시간, 독립 검토, 연속성, 병렬 작업 능력이 부족하다면 추가 인력이나 신뢰할 수 있는 전문가 접근이 필요합니다.

목표는 가장 작은 팀이 아닙니다. 필요한 위험과 품질 수준에서 요구 결과를 현실적으로 만들어 낼 수 있는 가장 작은 구성입니다.

[1] GOV.UK Service Standard - Have a multidisciplinary team
출처 열기

[2] GOV.UK Service Manual - Set up a service team at each phase
출처 열기

[3] The Scrum Guide, 2020 - Scrum Team
출처 열기

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
출처 열기

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
출처 열기

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
출처 열기

[7] Project Management Institute - Solving The Resource Puzzle
출처 열기

[8] GOV.UK Service Manual - Running more than one service team
출처 열기

방법론 참고: 일부 출처는 디지털 공공 서비스, 일부는 Scrum Team, 프로젝트 관리, 또는 팀과 소프트웨어 개발 연구를 다룹니다. 이 글은 각 출처가 실제로 뒷받침하는 범위에서만 활용합니다. 최소 구성을 정하는 7단계 방법은 이런 원칙을 편집해 종합한 것이며, 위 기관들이 발행한 공식 표준은 아닙니다.