6부 · AI 시대의 프로그램 팀장

6부 · AI 시대의 프로그램 팀장 — 지위 상승과 리더십의 선택

본 장의 질문. 한국 IT 업계의 많은 경영자가 같은 질문을 반복한다. “우리 프로그램 팀장은 이제 무엇을 해야 하는가.” 이 질문은 표면적으로는 직무 재정의의 문제처럼 보이지만, 실제로는 지위의 급격한 상승과 리더십 양식의 선택이라는 두 가지 문제의 겹침이다. 본 장은 이 겹침을 풀어낸다. 대응 규약: AICBOK D.5(이해관계자 영역), D.6(자원 영역), F.1(착수), F.2(계획), P.6(적응형 방법론)

6.1 로봇 병사 1만 개를 받은 신병

과거의 프로그램 팀장은 팀원 다섯 명을 관리하는 사람이었다. 주니어 두 명, 미드레벨 두 명, 시니어 한 명이 일반적인 구성이었다. 팀장의 일상 업무는 작업 할당, 코드 리뷰, 일정 조정, 기술적 조언, 팀원의 모티베이션 관리. 이 모든 것을 한 사람의 팀장이 감당할 수 있었던 이유는 관리 대상이 소수였고, 각 대상이 독립적으로 사고할 수 있는 인격이었기 때문이다. 팀원은 자신의 판단으로 작업을 수행하고, 팀장은 판단이 결정적으로 어긋날 때만 개입하면 됐다.

AI 시대의 팀장은 이 구도와 근본적으로 다른 환경에 서 있다. 팀원 다섯 명은 여전히 있다. 그런데 그 밑에 수십에서 수백 개의 AI 에이전트가 상시 동작한다. 에이전트는 팀원과 달리 독립적으로 사고하지 못한다. 각 에이전트는 주어진 지시 범위 안에서만 작동하며, 지시가 모호하거나 범위를 벗어나면 예측 불가능한 방향으로 움직인다. 팀장은 팀원의 판단을 보조하는 역할에서, 에이전트의 지시 체계 전체를 설계하는 역할로 이동한다.

이 전환을 가장 정확하게 포착하는 비유가 로봇 병사 1만 개를 받은 신병이다¹. 갓 입대한 신병이 지휘관도 아니고 장교도 아닌데, 손에는 1만 개의 로봇 병사를 조종할 수 있는 통제기가 쥐여 있다고 상상해 본다. 이 신병은 무엇을 해야 하는가. 정답은 단순하다. 사단장의 전략을 세워야 한다. 그런데 신병에게 사단장의 전략을 세우는 훈련은 없다. 신병 훈련은 소대 단위의 개인 전투술이었다. 1만 개의 병사를 움직이는 법을 배운 적이 없다.

이 상황이 지금 프로그램 팀장의 위치와 구조적으로 일치한다. 팀장의 경력은 "코드를 잘 쓰는 개발자"에서 출발해 "팀원을 관리하는 시니어 개발자"를 거쳐 "팀장"으로 이어졌다. 이 경력의 어느 단계에서도 수십 개의 자동화된 작업 단위를 동시에 조율하는 훈련은 포함되지 않았다. 훈련 없이 마주친 환경에서 팀장은 선택을 요구받는다. 옛 경력의 방식으로 팀원만 관리하면 AI 에이전트는 통제 없이 움직이고, AI 에이전트를 관리하는 데 집중하면 팀원의 성장과 모티베이션이 방치된다. 두 가지를 동시에 해내야 하지만, 동시에 할 시간은 부족하다.

이 시간 부족이 팀장의 지위를 강제로 끌어올린다. 과거의 팀장은 코드와 사람 사이에 있었다. 현재의 팀장은 전략과 시스템 사이에 있다. 전략은 무엇을 만들 것인가의 방향이고, 시스템은 그것을 실행하는 에이전트 조직이다. 이 두 층위 모두 팀장의 과거 업무보다 한 단계 높은 추상도를 요구한다. 지위가 올라갔다는 것은 권한이 커졌다는 의미가 아니라, 판단의 추상도가 올라갔다는 의미다. 권한은 그대로일 수 있지만, 판단의 층위가 달라진 것이다.

이 전환은 피할 수 없다. AI를 도입하지 않은 팀이 없고, 도입한 이상 에이전트는 계속 늘어난다. 팀장이 전환을 거부하면 팀은 무너지고, 팀장이 교체된다. 이 사실을 분명히 인식하는 것이 본 장의 출발점이다. 팀장 본인이 자신의 위치를 재정의하지 않으면, 조직이 대신 재정의한다. 조직의 재정의는 개인에게 거의 언제나 불리하다.

[배경] 대한민국 대표들의 관심사 지도 2025년 이후 한국 IT 업계의 많은 경영자 사이에서 자주 등장하는 질문이 "AI 시대에 우리 프로그램 팀장은 무엇을 해야 하나"다. 이 질문은 프로그램 팀장 본인보다 대표들의 입에서 먼저 나왔다. 이유는 단순하다. 팀장은 일상 업무에 묻혀 있어 자신의 위치 변화를 느낄 여유가 없지만, 대표는 회사 전체의 생산성 지표를 보며 팀장들의 역할이 재정의되어야 한다는 사실을 먼저 감지한다. 이 비대칭이 의미하는 것은, 팀장 본인이 고민하지 않아도 대표는 이미 고민하고 있다는 사실이다. 그리고 대표의 고민에 먼저 답을 제시하는 팀장이 다음 포지션의 우선권을 가진다. 이 주제는 9부의 개인 브랜딩 논의에서 다시 다뤄진다.

6.2 대화량의 역설 — AI가 늘수록 사람 사이 대화는 증가해야 한다

표면적으로 보면 AI가 업무를 맡을수록 팀원 사이의 대화는 줄어들 것 같다. 각자 AI에게 맡기고 각자의 산출물을 내면 되니까. 그러나 실제로 관찰되는 패턴은 정반대다. AI를 도입한 팀에서 팀원 사이의 대화는 오히려 더 늘어나야 한다. 늘어나지 않으면 팀은 무너진다.

이 역설의 원인은 5부에서 분석한 세 가지 문제(맹신, 이해 부족, 책임감 결여)에서 찾을 수 있다. 개별 팀원이 AI와 일대일로 작업하는 상황에서 세 문제가 누적되면, 팀원 사이의 산출물은 서로 어긋나고, 어긋남은 조율되지 않은 채 쌓인다. 이 어긋남을 해소하는 유일한 방법은 팀원 사이의 상시 대화다. 대화는 단순한 사교가 아니라 조율의 실시간 수행이다. 서로 무엇을 하고 있고, 어떤 결정을 내렸고, 어떤 AI 응답을 받았는지를 주기적으로 공유해야 팀이 한 방향을 유지한다.

이 원리는 과거의 애자일 개발에서 데일리 스탠드업²으로 제도화된 형태로 존재했다. 매일 아침 15분, 각자 어제 한 일·오늘 할 일·막히는 점을 공유한다. 이 15분이 팀의 일관성을 유지하는 가장 작은 단위의 조율이었다. AI 시대에도 이 형식은 유효하지만, 단위와 빈도가 조정되어야 한다. 과거의 데일리 스탠드업이 개인 작업의 공유였다면, AI 시대의 데일리는 개인-AI 협업의 공유다. "오늘 나는 이러이러한 작업을 했다"가 아니라 "오늘 나는 AI에게 이러이러한 지시를 내렸고, 이러이러한 결과를 받았고, 이러이러한 판단으로 수락했다"가 된다. 지시의 내용과 결과의 해석이 공유되어야 다른 팀원이 유사한 지시를 내릴 때의 참고 자료가 된다.

데일리 스탠드업 외에도 대화가 필요한 지점이 몇 가지 더 있다. 각각을 짧게 정리한다.

① 백본 변경 토의 프로젝트의 백본(5부 5.5절)이 변경될 때는 반드시 팀원 전체의 토의가 필요하다. 백본 변경은 모든 팀원의 작업에 영향을 주므로, 단일 팀원이 결정할 수 없다. 팀장이 주재하는 30분 정도의 짧은 회의가 표준이다.

② 위원회 판정 리뷰 AI 위원회가 반려한 안건에 대해서는 팀원 전체가 사유를 공유한다. 한 사람의 안건이 반려되었더라도, 같은 사유가 다른 팀원의 안건에도 적용될 수 있기 때문이다. 리뷰 공유는 비동기로 가능하며, 일반적으로 옵시디안 볼트의 회의록 디렉터리에 올라가는 것으로 충분하다.

③ 시행착오 공유 개별 팀원이 AI와 작업하다가 겪은 시행착오를 팀에 공유하는 시간이 필요하다. 이 공유는 정기 회의보다 비정기적 공유 채널(슬랙의 시행착오 채널 등)로 이루어지는 것이 효율적이다. 한 사람의 실수 사례가 다른 팀원의 예방책이 된다.

④ 전략 토의 프로젝트의 방향이나 우선순위를 결정할 때, 팀장 혼자 결정하지 않고 팀원과 토의한다. 이 토의는 정기적으로 열리지 않고, 필요할 때만 소집된다. 모든 팀원이 참여할 필요도 없으며, 관련된 역할만 참여한다.

이 네 가지 대화 지점은 팀의 규모와 프로젝트 성격에 따라 빈도와 형식이 조정된다. 중요한 것은 대화가 기본값이라는 사실이다. 대화가 없으면 팀은 실패한다. 대화의 부담이 과도하면 생산성이 떨어진다. 그 사이의 균형을 찾는 것이 팀장의 일이다.

경험 법칙 하나. AI가 업무의 80%를 맡아도, 팀원 사이의 대화 시간은 과거보다 줄지 않는다. 오히려 늘어나야 한다 (실무 관찰 기반 추정). AI가 작업의 속도를 높일수록, 그 작업들을 엮는 조율의 속도도 같이 빨라져야 하며, 조율은 대화에서 나온다. 이 원리를 무시한 팀은 "AI 도입 후 생산성이 오히려 떨어졌다"는 결론에 도달한다. 생산성이 떨어진 것이 아니라 조율이 부족한 것이다.

6.3 전원 아키텍트 조직 — 가능성과 한계

위의 대화량 역설을 극단까지 밀고 가면 한 가지 흥미로운 구상에 도달한다. 팀 전체가 아키텍트가 되어야 하는 것 아닌가라는 질문이다. 과거의 개발자는 주어진 설계를 구현하는 사람이었고, 아키텍트는 그 위에서 설계를 하는 소수의 상위 역할이었다. AI가 구현을 맡는 이상, 모든 개발자가 설계 층위로 올라가야 한다는 생각이 자연스럽게 떠오른다. 5명의 팀에서 5명 모두가 아키텍트인 조직. 20명의 팀에서 20명 모두가 아키텍트인 조직.

이 구상은 매력적이지만 한 가지 핵심 오류를 가지고 있다. 모든 사람이 아키텍트가 되면, 아키텍트의 역할 자체가 정의되지 않는다. 아키텍트는 다른 역할(구현자)을 위해 존재한다. 구현자가 없으면 아키텍트의 산출물은 공중에 뜬다. 전원 아키텍트 조직에서 AI가 구현자의 역할을 대체한다고 가정하면, 아키텍트는 AI를 위한 설계를 하는 사람이 된다. 그런데 AI를 위한 설계는 이해 수준의 차이가 있는 동료 개발자를 위한 설계와 질적으로 다르다.

구체적으로 풀어 본다. 전통적 아키텍트는 동료 개발자에게 "이 구조를 따르되, 세부 구현은 당신의 판단에 맡기겠다"라고 말한다. 동료는 판단 능력이 있으므로, 애매한 지점에서 자체적으로 결정하고 구현한다. 그 결정이 아키텍처 원칙과 일치하면 합격, 일치하지 않으면 리뷰에서 수정된다. 이 피드백 루프가 아키텍트와 구현자의 관계를 형성한다.

AI는 판단 능력이 제한적이다. AI에게 "이 구조를 따르되 세부는 당신의 판단에 맡기겠다"라고 말하면, AI는 학습 데이터의 평균에 가까운 선택을 한다. 그 평균이 아키텍처 원칙과 어긋나는 경우가 많고, 리뷰에서 수정해도 AI는 다음 번 비슷한 상황에서 다시 같은 실수를 한다. 피드백 루프가 제대로 작동하지 않는다. 그래서 AI를 위한 설계는 애매함을 허용하지 않는 설계여야 한다. 모든 결정이 미리 명시되고, AI는 명시된 결정을 기계적으로 실행한다.

이 차이는 아키텍트의 일을 근본적으로 바꾼다. 전통적 아키텍트는 “결정을 적게 내리고 원칙을 많이 내리는” 일을 했다. AI 시대의 아키텍트는 “결정을 많이 내리고 원칙을 간결하게 내리는” 일을 한다. 결정의 수가 기하급수적으로 늘어난다. 전원 아키텍트 조직이 가능한 유일한 조건은, 이 기하급수적 결정을 분담할 수 있는 수의 아키텍트가 있을 때다. 5명의 팀에서 5명 모두가 아키텍트라면, 각자 담당하는 결정의 양이 감당 가능한 수준일 때만 작동한다. 그 수준을 초과하면 아키텍트들은 모두 소진되고, 팀은 무너진다.

결론은 이렇다. 전원 아키텍트 조직은 가능하지만, 자동으로 성립하지 않는다. 성립 조건은 (1) 팀원 모두가 결정을 잘 내리는 훈련을 받았고, (2) 결정의 분담 규칙이 명확히 정의되어 있고, (3) 결정의 충돌을 조율하는 장치(위원회)가 있을 때다. 이 세 조건 중 하나라도 빠지면 전원 아키텍트 조직은 혼돈이 된다. 실무에서 가장 자주 빠지는 조건은 (2) 결정의 분담 규칙이다. 누가 어떤 결정을 내리는지가 불분명하면, 같은 결정이 여러 사람에게서 서로 다른 형태로 내려지고, 팀의 산출물은 일관성을 잃는다.

본서의 권장은 이것이다. 전원 아키텍트 조직을 목표로 삼되, 결정의 분담 규칙부터 먼저 정하라. 분담 규칙이 없으면 전원 아키텍트는 구호로만 남는다. 분담 규칙이 있으면 전원 아키텍트는 점진적으로 실현 가능하다. 이 규칙의 구체적 설계는 팀의 성격에 따라 다르지만, 다음 세 가지 축은 공통이다.

모듈 경계: 누가 어느 모듈의 결정권을 가지는가

결정 범위: 어떤 결정은 개별적으로, 어떤 결정은 집단적으로 내리는가

충돌 해결: 결정이 충돌할 때 누가 최종 판정을 내리는가

세 축이 문서화되면 전원 아키텍트 조직은 혼돈이 아닌 분업으로 작동한다. 문서화되지 않으면 암묵적 규칙이 형성되고, 암묵적 규칙은 시간이 지나면 불공평해진다.

6.4 PM에 대한 오래된 오해 — “저 사람 일인데 내가 하고 있다”

지금까지 팀장의 역할을 이야기했지만, 팀장보다 더 미묘한 위치에 있는 존재가 PM(Project Manager)³이다. PM은 팀원도 아니고 팀장도 아닌, 프로젝트의 진행을 책임지는 전문 역할이다. 한국 게임업계에서 PM은 오랜 세월 오해받아 왔고, 이 오해가 AI 시대에도 해소되지 않았다.

오해의 핵심은 다음과 같다. 팀원들은 PM의 일이 자기 일에 도움이 된다고 생각하지 않는다. 그리고 많은 경우 속으로 "PM은 그 사람 직업인데 왜 내가 하고 있는 건가"라고 생각한다. PM이 요청하는 태스크 입력, 날짜 업데이트, 진행 상황 보고, 위험 요소 공유 같은 활동들이 자신의 진짜 일을 방해하는 부담으로 느껴지는 것이다.

이 인식이 존재하는 이유는 PM의 일이 본질적으로 다른 사람의 일을 조율하는 일이기 때문이다. PM 자신은 코드를 쓰지 않고 디자인을 만들지 않는다. PM은 사람들이 자신의 일을 제대로 하도록 옆에서 묶어 주는 역할이다. 이 역할의 결과물은 팀원의 산출물 안에 녹아들어 있고, 팀원 자신은 그 녹아든 부분을 알아차리지 못한다. "내가 이걸 잘 만든 건 PM이 조율을 해 줬기 때문"이라고 의식적으로 생각하는 팀원은 드물다. 대부분은 "내가 잘 만들었다"라고 생각하고, PM의 기여는 인지되지 않는다.

이 인지 부재가 PM의 권위를 약화시킨다. 팀원들은 PM의 요청을 귀찮아하고, 요청을 미루거나 형식적으로 답한다. PM은 응답의 질을 올리기 위해 다시 요청하고, 그 반복이 팀원의 피로를 더한다. 피로한 팀원은 PM을 더 멀리하고, PM의 정보 수집은 더 어려워진다. 이 악순환이 한국 게임업계의 PM 직무를 소진 직군으로 만들어 왔다.

AI 시대에 이 오해는 해소될 수 있는가? 대답은 부분적으로 그렇다이다. AI가 PM의 업무 중 많은 부분을 자동화하면, PM의 요청 자체가 줄어든다. 태스크 입력은 코드 커밋에서 자동 추출되고, 날짜 업데이트는 Git 로그에서 자동 생성되고, 진행 상황 보고는 옵시디안 볼트의 변경 이력에서 자동 생성된다. 팀원은 PM에게 정보를 수동으로 제공하지 않아도 된다. PM은 자동 수집된 정보를 해석하고 판단하는 역할로 이동한다.

그러나 근본적 오해는 남는다. 팀원은 여전히 "PM이 조율해 줘서 내가 잘했다"라고 생각하지 않는다. PM의 기여는 여전히 보이지 않는 접착제다. 이 오해를 완전히 해소하는 방법은 없다. 해소 불가능한 이상, PM은 이 오해를 받아들이고 일하는 것이 원칙이다. 이해받기를 기대하는 PM은 상처받고, 이해받지 않기를 예상하는 PM은 지치지 않는다. 이 심리적 방어는 PM이 장기적으로 일하는 유일한 방법이다.

PMBOK 8판의 언어를 빌리면, 이 문제는 3.6 “책임 있는 리더가 될 것” 원칙⁴과 연결된다. 책임 있는 리더는 이해받지 못해도 자기 역할을 수행하는 사람이다. 이해를 기대하는 것은 리더가 아니라 추종자의 심리다. PM은 본질적으로 리더의 위치이고, 리더는 이해받지 못함을 기본값으로 받아들인다.

한 가지 실무적 조언을 덧붙인다. PM의 기여를 인지시키는 유일한 공식적 경로는 프로젝트가 실패했을 때다. 실패한 프로젝트를 분석하면 PM의 조율 부재가 명백히 드러난다. 이 분석을 사후에 공유하면 팀원들은 "다음에는 PM의 말을 더 들어야겠다"라는 학습을 얻는다. 그러나 이 학습은 다음 프로젝트에서 빠르게 희미해진다. 인간 기억의 구조다. PM은 이 희미해짐을 전제하고 일한다.

6.5 통제력 상실과 PMP의 윤리적 해법

프로젝트 관리에서 가장 극단적인 상황은 통제력 상실이다. 팀이 PM의 지시를 무시하고, 명령이 서지 않는 상태. PMBOK 8판은 이 상황에 대해 두 가지 구조적 장치를 명시한다.

첫째, 에스컬레이션. PMBOK 8판 2.1.4절은 "에스컬레이션은 의사결정 권한이 팀 외부에 있는 조직에서 유용하다. 상위 권한자가 장애를 제거하거나 갈등을 해결해 프로젝트의 성공 확률을 높인다"라고 서술한다. 즉 통제력 상실의 원인이 조직 정치에 있다면, PM은 상위 경영진에게 문제를 올릴 수 있다.

둘째, 프로젝트 종료. PMBOK 8판은 프로젝트 종료 조건으로 "governing body, 스폰서, 또는 팀이 목표를 달성할 수 없다고 판단한 경우"를 명시한다. 4.5.5절(Closing Focus Area)도 "프로젝트를 완료 전에 종료(terminate)하는 경우"를 정식으로 다룬다. 프로젝트 자체의 종료가 정당한 선택지라는 것이다.

여기에 AICBOK은 한 단계를 더 추가한다.

AICBOK의 통제력 상실 3단계 프로토콜

1. 재협상 — 통제력 상실의 원인이 대헌장의 불명확함에 있다면, 관계자들과 대헌장을 다시 검토하고 합의를 갱신한다. 이것이 가장 온건한 대응이다.

2. 에스컬레이션 — 조직 정치에서 비롯된 것이라면, PM 또는 팀장은 상위 경영진에게 더 강한 권한을 요청한다.

3. 프로젝트 이탈 — 위의 두 시도가 모두 실패하면, 프로젝트를 그만두는 것도 선택지다. PMBOK은 프로젝트 종료를 정식 프로세스로 인정하며, PMI 윤리 강령(Code of Ethics and Professional Conduct, 별도 문서)은 윤리적 지속 불가능성에 직면한 PM의 판단을 지지한다.

이 프로토콜은 개인의 감정적 반응이 아니라 구조적 방어막이다. 감정으로 대응하면 관계가 무너지고, 프로토콜로 대응하면 판단이 유지된다.

AICBOK이 여기서 강조하고 싶은 것은*이탈이라는 선택지의 존재 자체다. 많은 팀장은 "이 팀을 그만둘 수는 없다"라는 심리적 제약에 갇혀 통제력 상실 상태에서도 계속 일한다. 그 계속된 일은 본인의 건강과 평판 모두를 갉아먹는다. "나는 언제든 이탈할 수 있다"라는 선택지를 가지고 있는 팀장은, 그 선택지를 가지지 않은 팀장보다 현장에서 더 강하게 일할 수 있다. 역설적이지만, 프로젝트 관리 수십 년의 경험이 도출한 지혜다.

동시에 분명히 해야 할 것이 있다. 통제력 상실은 개발 방법론이나 AI 방법론의 영역 바깥에 있는 문제다. PMBOK의 에스컬레이션도, AICBOK의 위원회도 이 문제를 기술적으로 해결하지 못한다. 통제력 상실은 조직 관리, 코칭 스킬, 인간관계론, 심리학 — 그리고 때로는 그 모든 것의 바깥 — 에 닿는다. 본서가 할 수 있는 것은 이 문제의 존재를 인정하고, 팀장이 감정이 아닌 구조로 대응할 수 있는 프레임을 제공하는 것까지다. 그 이상은 다른 학문과 다른 경험의 영역이다.

6.6 명령과 토의 — 리더십의 두 분기

PMP 교재는 리더십에 대해 독특한 태도를 보인다. PMP는 기본적으로 명령 기반 리더십을 선호한다. "이것을 이렇게 하라"라는 명확한 지시로 프로젝트를 진행하고, 토의와 합의는 최소화한다. 이 스타일이 PMP의 DNA에 박혀 있다.

반대로 애자일 진영은 토의 기반 리더십을 선호한다. 스프린트 회의, 스탠드업, 리뷰와 회고를 통해 팀원 전체가 의사결정에 참여한다. 리더는 팀원의 의견을 수렴하고, 합의된 방향으로 팀을 이끈다.

이 두 스타일은 같은 프로젝트 관리 목표를 서로 다른 방식으로 추구한다. 어느 쪽이 더 우월한가? 본서의 입장은 "상황에 따라 다르다"이다. 그리고 중요한 것은 어느 한쪽을 선택해야 한다는 점이다. 두 스타일을 섞으려고 하면, 팀원은 혼란스러워하고 리더의 권위는 약화된다.

명령 스타일이 적합한 상황:

프로젝트의 성공 조건이 명확하고 변경되지 않는 경우

팀원이 상대적으로 경험이 적고 스스로 판단할 수 없는 경우

시간이 촉박해 토의를 진행할 여유가 없는 경우

외부 규제나 계약이 엄격한 경우

토의 스타일이 적합한 상황:

프로젝트의 목표가 유동적이고 재정의가 자주 필요한 경우

팀원 모두가 숙련되어 있고 각자 전문성을 가진 경우

창의적 해결책이 핵심인 경우

조직 문화가 수평적이고 권위 구조가 약한 경우

AI 시대의 팀장은 이 두 상황을 동시에 마주한다. 에이전트는 명령에 반응하는 존재다. 에이전트에게는 명령 스타일이 맞는다. 사람 팀원은 토의에 참여할 수 있는 존재다. 사람에게는 토의 스타일이 맞는다. 한 팀장이 에이전트에게는 명령을, 팀원에게는 토의를 적용하는 이중 리더십을 운영해야 한다.

이 이중 리더십의 경계를 어떻게 긋는가? 본서의 권장은 다음과 같다. 모든 작업 단위(스킬 문서 하나의 실행)는 명령 스타일로 운영한다. 모든 방향성 결정(스킬 문서를 어떻게 설계할 것인가)은 토의 스타일로 운영한다. 이 분기가 명확하면 팀원과 에이전트 모두가 혼란 없이 움직인다.

한 가지 덧붙이자면, 팀 전체 회의는 피하라는 경험 법칙이다. 전통적 팀 회의는 팀장이 팀원 전체에게 지시하고 의견을 듣는 자리였다. 이 형식은 시간이 많이 들고, 팀원 한 명의 발언이 다른 팀원의 생각을 오염시키기 쉽다. 그리고 팀 전체 회의에서는 팀장의 권위와 팀원의 권위가 충돌하는 경우가 많다. 팀원이 공개적으로 팀장의 결정에 반박하면, 팀장의 권위는 손상되고, 팀 내 다른 팀원의 복종도 약화된다.

더 효율적인 방법은 팀장들끼리만 회의하는 것이다. 프로그램 팀장, 기획 팀장, 디자인 팀장, QA 팀장이 정기적으로 모여 전체 방향을 결정한다. 이 결정은 각 팀장이 자기 팀원에게 하향 전달한다. 이 구조는 팀장의 권위를 지키면서도 전체 조율을 가능하게 한다. 게임업계의 PD(Project Director)⁵는 이 팀장 회의를 주재하는 위치이고, 전통적으로 "PD는 팀원과 직접 회의하지 않는다"라는 경험 법칙이 존재한다. 이 법칙의 근거는 위에서 설명한 권위 구조의 보호다. PD가 팀원과 직접 회의하면, 팀장의 권위가 꺾이고, 꺾인 권위 아래서 팀이 통제 불능에 빠진다.

AI 시대에는 이 구조가 한 번 더 강화된다. AI 에이전트들이 각 팀장에게 종속되어 있기 때문에, 팀장의 권위는 곧 에이전트의 명령 체계다. 팀장의 권위가 흔들리면 에이전트의 명령 체계도 흔들린다. 이 연쇄 효과가 AI 시대의 팀장을 과거보다 더 보호되어야 하는 존재로 만든다. PD와 경영진은 팀장의 권위를 의도적으로 지켜 줘야 하고, 팀원은 팀장의 결정에 일관된 복종을 보여야 한다. 이 원칙이 무너지면 전체 시스템이 무너진다.

6.7 PMBOK 8판의 6 원칙과 팀장의 방향

PMBOK 8판은 6개의 원칙을 제시한다. 이 원칙들은 프로세스 지시가 아니라 태도 지시다. AI 시대의 팀장이 내면화해야 할 태도로 직접 연결된다. 각 원칙을 팀장의 맥락으로 번역하면 다음과 같다.

① 총체적 관점 채택 (Adopt a Holistic View) 개별 작업의 최적화에 매몰되지 말고, 프로젝트 전체의 가치 흐름을 본다. AI 시대의 팀장은 50개의 에이전트가 각각 최선을 다하는 상태가 전체의 최선이 아닐 수 있음을 이해해야 한다. 부분의 합이 전체를 넘지 못하는 상황에서, 부분들을 조정해 전체를 높이는 것이 팀장의 일이다.

② 가치에 초점 맞춤 (Focus on Value) 산출의 양이 아니라 가치를 본다. AI는 산출의 양을 기하급수적으로 늘릴 수 있지만, 가치를 늘리는 것은 여전히 어렵다. 팀장은 "우리가 지금 만들고 있는 것이 사용자에게 실제로 가치를 제공하는가"를 끊임없이 질문한다. 이 질문 없이 진행된 AI 작업은 곧 의미 없는 산출의 산더미가 된다.

③ 프로세스와 산출물에 품질 내재화 (Embed Quality Into Processes and Deliverables) 품질을 사후 검사로 확보하지 말고, 프로세스 단계에 내재화한다. 스킬 문서와 역기획서, 위원회 구조가 바로 이 내재화의 구현이다. 품질은 최종 산출물에서 확인하는 것이 아니라, 산출물이 만들어지는 과정에서 이미 보장되어야 한다.

④ 책임 있는 리더가 될 것 (Be an Accountable Leader) 리더의 위치는 이해받기를 기대하지 않는다. 팀장은 자신의 결정에 대해 책임을 지며, 그 책임을 회피하기 위한 책임 분산을 시도하지 않는다. 실패했을 때 "AI가 그랬다"라고 말하지 않는다. "AI에게 그렇게 하도록 내가 지시했다"라고 말한다. 이 차이가 책임 있는 리더와 그렇지 않은 리더를 구분한다.

⑤ 모든 프로젝트 영역에 지속 가능성 통합 (Integrate Sustainability Within All Project Areas) 단기 성과만 보지 말고, 장기 지속 가능성을 고려한다. 팀원의 소진을 방치하지 않고, 기술 부채를 누적시키지 않으며, 조직 문화가 건강하게 유지되도록 신경 쓴다. AI 도입으로 단기 생산성이 오르더라도, 장기적으로 팀이 무너지면 그 생산성은 사라진다. 지속 가능성은 사치가 아니라 필수다.

⑥ 권한 부여 문화 구축 (Build an Empowered Culture) 팀원에게 결정 권한을 위임한다. 모든 결정을 팀장이 내리는 구조는 AI 시대에 확장되지 않는다. 팀원 각자가 자신의 영역에서 결정을 내릴 수 있어야 하고, 그 결정을 지지하는 문화가 있어야 한다. 권한 부여는 통제의 포기가 아니라 더 큰 통제를 위한 위임이다.

이 여섯 원칙은 팀장이 매일 의식적으로 점검해야 할 체크리스트가 된다. 어느 하나에 소홀하면 팀의 어느 한 부분이 무너진다. 여섯 원칙이 모두 지켜지면 팀은 AI 시대의 새로운 복잡도 속에서도 안정적으로 작동한다.

[배경] PMBOK 8판 3.8 Build an Empowered Culture의 세부 항목 PMBOK 8판은 “권한 부여 문화 구축” 원칙의 세부 항목으로 (1) 심리적 안전감, (2) 의사결정 권한의 분산, (3) 학습과 개선의 상시화, (4) 다양성과 포용성을 든다. 이 네 가지는 표면적으로는 HR의 관심사처럼 보이지만, PMBOK이 이것을 프로젝트 관리 원칙에 포함시킨 이유는 이 네 가지가 없으면 다른 다섯 원칙이 작동하지 않기 때문이다. 심리적 안전감이 없는 팀에서는 문제가 은폐되고, 권한이 집중된 팀에서는 병목이 생기고, 학습이 멈춘 팀에서는 품질이 정체된다.

6.8 재단(Tailoring) — 이 규약을 당신의 팀에 맞게 줄이는 법

지금까지 설명한 모든 것이 모든 팀에 그대로 적용되지는 않는다. 팀의 규모, 프로젝트의 성격, 조직의 문화에 따라 적절히 조정되어야 한다. 이 조정을 PMBOK 8판은 재단(Tailoring)⁶이라 부르고, 별도의 섹션(Section 3 of the Guide)으로 다룬다. AICBOK도 같은 개념을 T(Tailoring) 영역으로 수용한다.

재단의 원리는 간단하다. 원칙은 유지하고, 실행 방식은 상황에 맞춘다. 예를 들어 5명의 작은 팀에서는 별도의 위원회 인스턴스를 돌릴 필요가 없다. 팀장 본인이 검수자 역할을 겸할 수 있다. 스킬 문서도 매 작업마다 작성할 필요 없이, 주요 작업에만 작성한다. 옵시디안 볼트도 단순한 디렉터리 구조로 충분하다.

반대로 50명의 큰 팀에서는 재단이 반대 방향으로 이루어진다. 위원회는 여러 인스턴스로 분리되어 각자 다른 모듈을 담당하고, 스킬 문서는 세분화되며, 옵시디안 볼트는 여러 개의 부분 볼트로 나뉜다. 전 팀원이 따르는 표준 템플릿이 필요하고, 그 템플릿의 관리를 전담하는 역할(예: 아키텍트)이 따로 배치된다.

재단의 핵심 판단 기준은 다음 세 가지다.

① 관리 비용의 임계점 스킬 문서와 위원회를 유지하는 비용이 그 이익을 초과하는가? 초과하면 축소한다. 초과하지 않으면 유지한다. 이 판단은 팀의 실제 운영에서 몇 주 단위로 재평가되어야 한다. AI 환경이 빨리 바뀌므로, 어제 유효했던 재단이 오늘은 과잉이 될 수 있다.

② 팀의 숙련도 분포 팀원 대부분이 숙련자라면 자율적 결정 권한을 넓게 부여한다. 비숙련자가 많다면 결정 범위를 좁히고, 스킬 문서와 백본을 더 상세하게 만든다. 이 조정은 팀원의 성장에 따라 지속적으로 갱신된다.

③ 프로젝트의 생애주기 프로젝트 초기에는 백본을 먼저 잡는 것이 중요하다. 중반에는 스킬 문서와 역기획서의 관리가 중요해진다. 후반에는 아카이빙과 문서화의 완결성이 중요해진다. 생애주기 단계마다 강조점이 다르고, 재단도 단계에 맞춰 조정된다.

재단의 규칙을 만드는 것 자체가 팀장의 역할이다. 본서의 AICBOK은 재단의 기본 틀을 제공하지만, 각 팀의 구체적 재단은 팀장이 직접 결정해야 한다. 이 결정을 미루면 팀은 본서의 틀을 그대로 복사해 운영하게 되고, 그 결과는 십중팔구 과잉이다. 과잉은 피로를 낳고, 피로는 포기를 낳는다. 포기는 본서의 원칙 자체가 쓸모없다는 오해로 이어진다. 이 오해를 막는 유일한 길은 적극적인 재단이다.

6.9 팀장의 하루 — 가상의 일과표

본 장을 마무리하면서, 지금까지의 논의가 구체적으로 어떤 하루의 모습으로 나타나는지를 가상의 일과표로 제시한다. 이 일과표는 5명의 팀원과 30개의 에이전트를 운영하는 중견 팀장의 일반적 하루를 가정한다.

09:00 – 09:15 · 데일리 스탠드업 팀원 5명과 15분. 어제의 AI 지시 결과 공유, 오늘의 작업 우선순위 확인, 막히는 지점 공유. 팀장은 듣는 역할에 집중하고, 필요할 때만 개입한다.

09:15 – 10:00 · 위원회 판정 리뷰 지난밤 동안 처리된 위원회의 안건을 훑는다. 승인된 건은 간단히 확인, 반려된 건은 사유를 읽고 팀원에게 피드백. 조건부 승인은 조건의 이행 여부를 다음 리뷰에서 확인하도록 표시한다.

10:00 – 11:30 · 백본 설계와 스킬 문서 검토 프로젝트의 핵심 구조를 손본다. 새 기능이 추가되면 백본의 어느 부분에 들어갈지 결정하고, 관련 스킬 문서를 작성하거나 기존 스킬을 갱신한다. 이 시간이 팀장의 진짜 일이며, 이 시간에는 방해받지 않아야 한다.

11:30 – 12:00 · 팀원 1:1 팀원 한 명과 15분씩, 한 주에 전 팀원과 한 번씩 돌아간다. 업무 이야기보다 판단의 근거와 성장의 방향을 이야기한다. 이 시간이 팀원의 책임감을 유지하는 가장 중요한 투자다.

12:00 – 13:00 · 점심

13:00 – 14:30 · 전략 회의 또는 팀장 회의 필요할 때 주재되는 회의. 없으면 백본 설계 시간을 연장한다.

14:30 – 16:00 · AI와 함께 작성 팀장 본인도 바이브코딩으로 일정 분량을 직접 작성한다. 작성하지 않으면 현장 감각을 잃는다. 이 시간이 팀장의 AI 코딩 능력을 유지하는 장치다.

16:00 – 17:00 · 위원회 운영과 검수 위원회 에이전트들이 처리하지 못한 경계선 안건을 직접 검수한다. 판정이 애매한 건들을 팀장이 결정한다.

17:00 – 18:00 · 기록과 내일 준비 오늘의 결정과 관찰을 옵시디안 볼트에 기록한다. 내일의 우선순위를 정하고, 팀원에게 필요한 안내를 사전에 준비한다.

이 일과표는 고정된 것이 아니다. 재단의 원리에 따라 각 팀이 자신의 리듬을 찾아야 한다. 그러나 이 일과표가 제시하는 비율은 일반적으로 유효하다. 팀장의 시간 중 약 30%는 관리(스탠드업·리뷰·1:1), 30%는 설계(백본·스킬 문서), 20%는 현장 작업(바이브코딩), 20%는 검수와 기록이다. 이 비율 어느 하나가 10% 미만으로 떨어지면 팀은 그 부분에서 약해진다.

6.10 마지막 문장 — 팀장의 일은 대체되지 않는다

본 장을 닫으면서 한 가지 분명한 문장을 남긴다. 팀장의 일은 AI로 대체되지 않는다. 팀장의 일이 무엇인가의 정의가 바뀔 뿐이다.

대체되지 않는 이유는 구조적이다. AICBOK의 설계에서 다음 결정 지점은 AI가 수행할 수 없도록 못 박혀 있다. 편입 결정(이 변경을 반영할 것인가), 리스크 대응 수준 결정(회피/경감/전가/수용), 제거 또는 수용 결정(롤백할 것인가 유지할 것인가), 최종 서명, 대헌장 확정. 이 결정들은 사람의 판단과 책임을 요구한다. AI는 분석과 제안을 하지만 결정과 서명은 사람만이 한다. 그런데 이 사람의 일이 과거와 똑같은 형태로 남아 있지 않는다. 과거의 팀장은 코드 리뷰와 일정 관리와 팀원 지도가 주 업무였지만, 현재의 팀장은 에이전트 조율과 문서 설계와 위원회 운영이 주 업무다. 업무의 내용이 바뀌었다.

이 변화를 받아들이는 팀장은 살아남고, 받아들이지 않는 팀장은 교체된다. 받아들이는 방법은 단순하다. 자신의 매일의 일과표를 AI 시대의 형태로 재설계하는 것이다. 과거의 일과표를 그대로 유지하면서 AI만 추가로 도입하면, 결과는 과부하다. 일과표 자체를 재설계해야 한다.

본 장은 그 재설계의 방향을 제시했다. 로봇 병사 1만 개를 받은 신병은 혼자서 1만 개를 직접 조종할 수 없다. 조종의 체계를 설계해야 한다. 그 체계가 본서의 스킬 문서·역기획서·위원회·백본·재단의 결합이다. 이 체계 위에 서는 팀장은 과거보다 더 많은 에이전트를 더 적은 스트레스로 운영할 수 있다. 체계 없이 서는 팀장은 훨씬 적은 에이전트에 짓눌려 무너진다.

마지막으로 한 줄을 남긴다. AI는 팀장의 위협이 아니라 팀장의 지위 상승의 기회다. 그러나 그 기회는 자동으로 오지 않는다. 재설계를 선택한 팀장에게만 온다.

[소결]

AI 시대의 팀장은 로봇 병사 1만 개를 받은 신병에 비유된다. 권한이 커진 것이 아니라 판단의 추상도가 올라갔다.

대화량의 역설: AI가 늘어날수록 팀원 사이의 대화는 과거의 120% 수준으로 늘어나야 한다. 줄어들지 않는다.

전원 아키텍트 조직은 가능하지만 자동으로 성립하지 않는다. 결정의 분담 규칙 설계가 선행되어야 한다.

PM에 대한 오래된 오해(“저 사람 일인데 내가 하고 있다”)는 AI 시대에도 해소되지 않는다. PM은 이 오해를 받아들이고 일해야 한다.

PMP의 통제력 상실 프로토콜(재협상·권한 요청·이탈)은 AI 시대의 팀장에게도 적용 가능하다. 이탈이라는 선택지의 존재 자체가 팀장을 강하게 만든다.

명령과 토의 리더십의 분기: 작업 실행은 명령 스타일, 방향 결정은 토의 스타일로 운영한다. 팀 전체 회의는 피하고 팀장 회의를 택한다.

PMBOK 8판의 6 원칙(총체적 관점·가치 초점·품질 내재화·책임 리더십·지속 가능성·권한 부여)은 팀장의 매일 체크리스트다.

재단은 팀장의 필수 활동이다. 본서의 틀을 그대로 복사하면 과잉이 되고, 재단하지 않으면 포기로 이어진다.

팀장의 하루는 관리 30%, 설계 30%, 현장 작업 20%, 검수와 기록 20%의 비율이 권장된다.

팀장의 일은 대체되지 않는다. 그 정의가 바뀔 뿐이다. 재설계를 선택한 팀장에게만 기회가 온다.

각주

¹ 로봇 병사 1만 개 비유의 원천. 본서는 이 비유를 AI 시대 팀장의 상황을 가장 직관적으로 전달하는 장치로 채택했다. 비유의 핵심은 "훈련받지 않은 역할을 강제로 수행해야 하는 신병의 인지 부조화"다. 유사 비유로 “장교가 된 하사”, “대장이 된 중대장” 등이 있지만, 모두 스케일 차이가 본서가 원하는 수준에 미치지 못했다.

² 데일리 스탠드업(Daily Stand-up). 스크럼 방법론의 핵심 의례 중 하나. 매일 아침 15분 이내, 팀원 전체가 서서 진행한다. 각자 (1) 어제 한 일, (2) 오늘 할 일, (3) 방해 요소의 세 가지를 공유한다. "서서 한다"는 형식은 회의가 길어지는 것을 방지하는 물리적 제약이다.

³ PM(Project Manager). 프로젝트의 진행을 책임지는 전문 역할. 한국 게임업계에서는 종종 PM과 PMO와 PO(Product Owner)가 혼용되는데, 이는 미국·유럽 기준과 다르다. PMI의 엄밀한 정의로는 PM은 프로젝트 전체의 관리자, PMO는 여러 프로젝트의 관리 기능을 표준화하는 조직, PO는 애자일의 고객 대표다.

⁴ PMBOK 8판 3.6 Be an Accountable Leader. PMBOK 8판의 여섯 원칙 중 네 번째. 리더의 책임을 "자기 결정에 대한 투명한 소유"로 정의한다.

⁵ PD(Project Director). 한국 게임업계의 고유 직함. 영어권의 “Project Director” 또는 "Creative Director"에 해당하며, 프로젝트 전체의 창의적·전략적 책임을 진다. 게임 회사에 따라 Producer, Director, Lead 등의 직함으로도 사용된다.

⁶ 재단(Tailoring). PMBOK 8판에서 체계적으로 다뤄지는 개념. Section 3 of the PMBOK Guide가 재단만을 다루며, “Why Tailor?”, “What to Tailor”, “The Tailoring Process” 등의 세부 항목이 있다. 재단은 "표준을 상황에 맞게 조정하는 프로세스"로 정의되며, 표준 자체가 변경되는 것은 아니다. AICBOK의 T(Tailoring) 영역이 이 개념을 AI 집합코딩 맥락으로 번역한다.

다음 장 예고 — 7부는 이 모든 구조의 반대편에 있는 AI 자체의 병리를 다룬다. 자기를 먹는 모델(MAD, Model Autophagy Disorder)과 아첨하는 모델(간신배, Sycophancy)의 두 현상이 어떻게 발생하는지, 이것을 구조적으로 막는 방법은 무엇인지가 전개된다.

© 2026. Kim Dongeun(WhtDrgon) at MEJE Works Corp. All rights reserved.