당신의 AI 코딩 에이전트에는 매니저가 필요합니다
TMT강력한 테크 리드나 매니저가 되기 위해 필요한 역량은 그대로 AI 코딩에도 적용됩니다. 여러 개의 에이전트를 병렬로 돌리기 시작하는 순간부터, 더 이상 단순히 컨텍스트를 디버깅하는 수준을 넘어서 실제 팀을 관리하게 됩니다. 명확성, 위임, 검증 루프, 비동기 커뮤니케이션. 오케스트레이션이 점점 더 일반화되면서, 일의 형태 자체가 바뀌고 있습니다.
가까운 미래에는, 가장 레버리지가 큰 개발자는 소수의 병렬 AI 코딩 에이전트를 돌리는 비동기 우선(async-first) 매니저의 모습과 비슷해질 거라고 생각합니다. 이제 에이전트는 격리된 환경에서 백그라운드로 실제로 의미 있는 일을 수행하고, 종종 풀 리퀘스트 형태로 리뷰 가능한 결과물을 가져올 수 있습니다. 물론 품질 검증은 여전히 필요하지만, 이제 병목은 “에이전트가 코드를 쓸 수 있는가?”가 아니라 “우리가 이걸 정말 만들어야 하는가?”, “여러 에이전트를 효과적으로 관리할 수 있는가?”로 옮겨졌습니다.
이미 이 미래를 예고하는 여러 워크플로가 등장하고 있습니다. Claude Code 제작자인 Boris Cherny의 최근 스레드가 큰 화제가 된 이유도 이 전환을 매우 구체적으로 보여줬기 때문입니다. 그는 로컬 터미널 탭에서 Claude Code 세션을 다섯 개, 브라우저에서도 다섯~열 개를 동시에 띄워두고, 심지어는 나중에 확인하려고 휴대폰에서 세션을 시작하기도 합니다. 이것이 바로 오케스트레이션입니다.
동시에, 신중한 엔지니어들은 이 “병렬 에이전트 라이프스타일”을 좀 더 회의적인 관점에서 기록해 오고 있습니다. Simon Willison의 글은 제가 계속 곱씹게 되는 글입니다. 자연스러운 병목은 코드 생성이 아니라 코드 리뷰에 있다는 점을 아주 분명하게 지적하기 때문입니다. 그는 여전히 병렬 작업을 동시에 던져두는 접근에서 실제 가치를 찾았지만, 자신의 집중력을 솔직하게 인정하고, 뇌를 과부하시키지 않는 작업을 고르는 것이 전제였습니다. 저 역시 비슷한 워크플로를 만들면서 같은 결론에 도달했습니다. 이 접근은 분명히 가치가 있지만, “마법”이 아니라 “매니지먼트”라는 관점으로 접근해야만 가치가 생깁니다.
이것이 바로 관점의 전환입니다. 더 이상 하나의 에이전트와 페어 프로그래밍을 하는 게 아니라, 작은 팀을 운영하는 것입니다.
그래서 사람을 잘 관리하는 테크 리드, 엔지니어링 매니저, 엔지니어링 리더가 되기 위해 필요한 역량이 곧바로 “AI 코딩을 잘하는 능력”으로 옮겨옵니다. 일정 규모 이상에서의 AI 코딩은 더 이상 프롬프트를 잘 쓰는 문제가 아니라, 매니지먼트를 잘하는 문제이기 때문입니다.
새로운 워크플로를 위한 멘탈 모델
저는 두 가지 모드가 나란히 돌아간다고 생각합니다.
첫 번째는 로컬에서, 사람이 깊게 개입하는 세션(human-in-the-loop) 입니다. 이 모드는 아키텍처 결정, 까다로운 리팩터링, 제품의 미묘한 뉘앙스, 요구사항이 애매한 작업 등, 취향과 판단이 핵심이 되는 일에 쓰입니다. 여기서는 에이전트와 페어를 이루어 실시간으로 방향을 바로잡고, 에이전트가 가지지 못한 컨텍스트를 바탕으로 중요한 결정을 내립니다.
두 번째는 클라우드나 백그라운드에서 비동기로 돌아가는 세션입니다. 이 모드는 범위가 분명한 일에 적합합니다. 예를 들면, 직관적인 기능 구현, 패턴이 명확한 마이그레이션, 테스트 생성, 문서 업데이트, 의존성 업데이트, 작은 버그 수정, 타깃이 명확한 리팩터링 등이 여기에 들어갑니다. 이런 작업은 한 번 던져두고, 다른 일로 컨텍스트를 전환한 뒤, 나중에 결과를 검토하러 돌아오면 됩니다.
이 두 모드는 현대 도구들이 진화하는 방향과도 자연스럽게 맞물립니다. GitHub Copilot Agent, Claude Web, Codex, Jules 같은 클라우드 에이전트는, 코드 작성·명령 실행·검토용 변경 제안이 가능한, 병렬화 가능한 샌드박스형 작업 단위라는 포지셔닝을 거의 전제로 합니다.
GitHub의 Copilot 코딩 에이전트도 스스로를 비슷하게 정의합니다. 백그라운드에서 돌아가는 비동기 에이전트로, 초안 PR을 열고, 그 사이에 계속 작업을 이어가며, 나중에 리뷰 요청을 보내고, 리뷰 결과에 따라 다시 수정하도록 설계되어 있습니다. 그리고 플랫폼 전반이 “단일 에이전트 창”에서 벗어나, 여러 에이전트를 한 곳에서 관리할 수 있는 일종의 ‘미션 컨트롤’ 대시보드로 움직이고 있습니다. GitHub이 미리 공개한 “Agent HQ” 역시, 여러 서드파티 코딩 에이전트를 하나의 제어판에서 묶어 관리하고, 동일한 작업에 여러 에이전트를 병렬로 돌려 결과를 비교할 수 있는 컨트롤 플레인으로 소개되었죠.
결국 중요한 질문은 “어느 모델이 코드를 가장 잘 쓰는가?”가 아니라 “이걸 고성능 팀처럼 운영할 수 있는가?”로 옮겨갑니다.
여기서 매니저 역량이 빛을 발합니다.
왜 매니저 역량이 당신을 더 나은 AI 코더로 만드는가
저는 예전에 효과적인 매니지먼트 스킬에 대해 깊이 있게 글을 쓴 적이 있습니다.
사람을 관리하다 보면, 결과물의 품질이 ‘위쪽’에서 결정된다는 사실을 뼈저리게 배우게 됩니다. 애매한 요구사항, 흐릿한 오너십, 정의되지 않은 “완료” 기준, 피드백 루프의 부재는 모두 불필요한 소모를 낳습니다. 팀이 사람이든, 아주 빠른 비인간 에이전트들로 구성돼 있든, 이 점은 똑같습니다. 어쩌면 에이전트에게는 더더욱 그렇습니다.
Anthropic이 공개한 Claude Code 활용 베스트 프랙티스는 이 점을 아주 직설적으로 말합니다. 처음부터 구체적으로 요구사항을 정리할수록 성공률이 높아지고, 중간에 경로를 수정할 일이 줄어든다는 것입니다. 이건 도구를 위한 문서처럼 보이지만, 사실상 매니저가 늘 하는 이야기와 다르지 않습니다.
여기서는 네 가지 역량이 특히 직접적으로 옮겨옵니다.
명확한 태스크 스코핑: “분위기”가 아니라 브리프를 써라
애매함이 에이전트의 효율을 갉아먹는다면, 당신의 역할은 아이디어처럼 흐릿한 생각을 구현 가능한 브리프로 바꾸는 일입니다. 좋은 매니저가 하는 일과 정확히 같습니다. ‘의도’를 ‘실행 가능한 것’으로 변환하는 작업이죠.
실용적인 에이전트용 브리프는 다음을 담습니다. 결과(끝났을 때 무엇이 참이어야 하는지), 컨텍스트(이 코드가 코드베이스의 어디에 위치하고, 어떤 패턴이 존재하는지), 제약(성능, 보안, API 형태, 의존성 규칙, 스타일 컨벤션), 논외 범위(이번에 의도적으로 하지 않을 것), 수용 기준(테스트가 어떤 식으로 통과해야 하는지, 어떤 엔드포인트가 어떻게 동작해야 하는지 등 구체적인 체크 항목), 통합 관련 메모(어떤 파일은 건드리면 안 되는지, 어디를 경계로 삼아야 하는지), 그리고 검증 계획(이게 제대로 동작하는지 어떻게 확인할지).
이 차이가 깔끔한 PR을 받느냐, 아니면 믿을 수 없는 1,000줄짜리 코드 덩어리를 받느냐를 가릅니다.
이 작업을 훨씬 쉽게 만들어주는 두 가지 전술이 있습니다. 첫째, 에이전트를 기존 패턴에 의도적으로 “묶어” 두는 것입니다. Anthropic의 가이드도, 에이전트가 따라야 하는 파일이나 갱신해야 하는 파일을 명시적으로 적어 주라고 권장합니다. 그래야 에이전트가 자기 스타일을 새로 발명하지 않고 실제 컨벤션에 앵커링됩니다.
둘째, 변경 불가능한 규칙들을 에이전트가 언제든지 참조할 수 있는 한 곳에 모아두는 것입니다. 이제는 거의 표준이 된 것처럼, OpenAI의 Codex 문서에서는 AGENTS.md 파일을 사용해 테스트 실행 규칙, 린트 규칙, 의존성 정책, 문서화 요구사항 등 에이전트에게 일관된 기대치를 전달하라고 설명합니다. 새 동료를 코드베이스에 온보딩할 때 해왔던 일과 똑같이 느껴지실 겁니다. 에이전트에게도 시작 전에 지도를 주고, 컨벤션을 알려주고, “완료”의 정의를 분명히 알려줘야 합니다.
위임: 무엇을 온전히 맡기고, 무엇은 당신의 판단이 필요한지 결정하라
에이전트와 일하면서 의외로 흔한 함정은, 사실은 사람이 해야 할 부분까지 전부 맡겨버리는 것입니다. 예컨대 제품 의도, API 설계의 트레이드오프, 아키텍처 경계, 장기적인 유지보수 관점의 판단 같은 것들입니다.
OpenAI의 “AI-native engineering team” 가이드는 이 문제를 소프트웨어 개발 생애주기의 세 영역으로 나눠 설명합니다. delegate(위임), review(검토), own(책임). 꽤 낙관적인 시각을 가진 글이지만, 모호한 문제에 대한 최종 결정과 승인 권한은 여전히 엔지니어가 쥐고 있어야 한다고 강조합니다.
이 구조는 오케스트레이션에도 그대로 대응됩니다. 일부 작업은 완전히 위임할 수 있습니다. 명확한 스펙이 있는 기계적인 구현, 루틴한 리팩터링, 강한 리뷰를 전제로 한 테스트 생성, 문서 업데이트, 위험도가 낮은 유지보수 작업 등이 그렇습니다. 또 어떤 작업은 위임하되 중간 체크포인트를 가져가야 합니다. 공유 인터페이스를 건드리는 변경, 머지 충돌 가능성이 큰 변경, 제품의 엣지 케이스가 많은 기능, 데이터 마이그레이션이 포함된 작업 등이 여기에 해당합니다. 그리고 어떤 작업은 아예 위임하지 않거나, 옵션 탐색 용도로만 에이전트를 씁니다. 시스템 아키텍처와 새로운 추상화 설계, 취향이 많이 개입되는 광범위한 리팩터링, “이걸 정말 만들어야 하는가?”에 대한 제품 의사결정, 보안·프라이버시가 핵심인 설계는 여기에 속합니다.
이 역시 팀에 일을 배분하는 것과 같은 근육입니다. 누가 무엇을 소유해야 하는지, 어느 정도의 자율성이 안전한지, 일이 굳어지기 전에 어느 지점에서 체크포인트를 둘지 끊임없이 판단해야 합니다.
검증 루프: 문제를 초기에 잡아라
사람을 관리하면서 배우는 가장 빠른 타임 머니 낭비 방식은 저품질 결과물을 너무 늦게 리뷰하는 것입니다. 가능한 한 이른 시점에 피드백 루프와 품질 게이트를 두는 게 중요합니다. 에이전트도 똑같습니다. 다만, 에이전트는 “저품질 결과물”을 훨씬 빠른 속도로 대량 생산할 수 있다는 점이 다릅니다.
검증 루프가 이 문제를 풀어주는 열쇠이고, 좋은 도구를 만드는 팀들은 이 개념을 가이드라인에 아예 내장하고 있습니다. Anthropic의 베스트 프랙티스는 여러 개의 Claude 인스턴스를 돌리되, 하나는 코드를 작성하고, 다른 하나는 리뷰·테스트를 통해 검증만 담당하는 “두 사람 분업” 패턴을 명시적으로 제안합니다. OpenAI의 Codex 역시 도구 사용에 대해 아주 분명하게 이야기합니다. 명령을 실행하고, 테스트를 돌리고, 통과할 때까지 반복한 뒤, PR을 제안하라는 것입니다.
실제 워크플로에서는 검증 루프가 다음과 같은 모습이 됩니다. 에이전트에게 테스트 스위트(또는 범위를 제한한 서브셋)를 실행하고, 그 결과를 마지막 메시지에 포함하라고 요구합니다. 에이전트가 건드린 영역에 대해 린트·타입 체크가 통과하는 것을 필수 조건으로 둡니다. 동작이 바뀌는 부분에 대해서는 반드시 테스트를 추가하거나 수정하게 합니다. 마지막 단계에서는 “PR 패킷”을 구조화된 형식으로 요구합니다. 어떤 변경이 있었는지, 왜 이런 접근을 택했는지, 어느 파일을 수정했는지, 테스트 계획과 그 결과는 어떤지, 위험 요소나 후속 작업은 무엇인지 등을 정리한 요약입니다.
한 단계 더 나아가고 싶다면 두 에이전트 패턴을 사용할 수 있습니다. 에이전트 A가 구현을 맡고, 에이전트 B가 정확성·스타일·엣지 케이스·빠진 테스트를 중심으로 리뷰를 합니다. 그다음 에이전트 A(또는 새로 띄운 C)가 리뷰 피드백을 반영해 다시 구현하고 검증을 재실행합니다. 이건 이론 속 아이디어가 아니라, Anthropic이 실제 워크플로 업그레이드 사례로 권장하는 방식입니다.
이 지점에서 매니저 감각이 다시 중요해집니다. 단순히 “컴파일이 되느냐”만 보는 게 아니라, 팀의 컨벤션에 맞는지, 유지보수하기 좋은지, 처음의 의도와 여전히 잘 맞는지를 함께 봐야 하기 때문입니다.
비동기 체크인: 에이전트를 직속 보고자처럼 다뤄라
세션을 열 개씩 병렬로 돌리고 있다면, 각 세션의 히스토리를 위에서부터 쭉 스크롤하면서 “무슨 일이 있었는지” 파악하는 방식으로는 금세 한계에 부딪힙니다. 가볍고 반복 가능한 체크인 방식이 필요합니다. 사람을 비동기로 관리하는 매니지먼트 플레이북을 에이전트에게 그대로 적용하는 셈입니다.
우선 체크인 주기를 정합니다. “15분 내에 의미 있는 진척이 없다면, 즉시 멈추고 막힌 점을 보고하라”처럼요. 그리고 상태 보고 형식을 일정하게 맞춥니다. 무엇이 바뀌었는지, 다음에 무엇을 할 것인지, 위험 요소나 막힌 점은 무엇인지, 나에게 필요한 것은 무엇인지 등입니다.
별것 아닌 것처럼 보일 수 있지만, 이것이 병렬로 돌아가는 작업들이 엉뚱한 방향으로 새는 것을 막아줍니다. 매번 옆에 붙어 감시할 필요 없이, 이 비동기 보고만으로도 충분히 관리가 가능해집니다. 조금 더 구체적인 비유를 들자면, 여러 시간대에 흩어져 있는 분산 팀을 관리하는 것과 매우 비슷합니다. 앞단에 명확성을 최대한 끌어올리고, 글로 남는 업데이트를 믿고, 실시간 주의력은 주로 의사결정과 장애 해소에 할당하는 식으로요.
어려운 지점들은 실제로 존재한다 (그리고 대부분 매니지먼트 문제다)
머지 컨플릭트는 기하급수적으로 늘어난다
서로 인접한 코드를 여러 에이전트가 동시에 수정하게 두는 것은, 다섯 명의 엔지니어를 아무 조정도 없이 같은 파일에 투입하는 것과 비슷합니다. 이건 도구의 실패가 아니라 “경계 설정의 실패”입니다. 해결법 역시 사람 팀에서 쓰는 것과 같습니다. 의도적인 작업 경계 만들기, 작업 단위의 격리, 명확한 인터페이스 정의입니다.
실무에서는 보통 에이전트를 서로 다른 작업 디렉터리나 브랜치에서 돌리는 방식이 많이 쓰입니다. Git worktree는 이 경우 특히 깔끔한 패턴입니다. 하나의 저장소에서 여러 브랜치를 동시에 체크아웃해, 각 브랜치마다 독립된 디렉터리를 둘 수 있게 해주기 때문입니다. Claude Code 문서에서도 병렬 세션용으로 git worktree를 사용하는 것을 명시적으로 추천하고, Anthropic 베스트 프랙티스 역시 worktree와 “worktree마다 하나의 터미널 탭”을 묶은 운영 패턴을 단계별로 설명합니다. 클라우드 에이전트를 쓰고 있더라도, 같은 원칙이 필요합니다. 브랜치를 분리하고, 작은 PR 단위로 쪼개고, 모듈마다 명확한 소유권을 설정하는 식입니다.
제가 특히 좋아하는 경계 규칙은 실제 팀 운영에서 가져온 것입니다. 하나의 에이전트는 하나의 PR만 책임진다. 여러 에이전트가 섞인 메가 PR은 만들지 않는다. 두 에이전트가 같은 파일을 건드릴 가능성이 있다면, 작업 단위 쪼개는 방식을 다시 설계한다. 공유 인터페이스는 사람이 주도하는 첫 번째 PR에서 정의하고, 그 뒤에 에이전트들이 그 경계 위에서 작업하도록 한다. 이런 식입니다.
“취향”과 “정말 이걸 만들어야 하는가?”가 진짜 병목이 된다
빌드 비용이 매우 싸지면, 사람은 일단 뭐든 다 만들어 보기 시작합니다. 표면적으로는 엄청 생산적인 것 같지만, 어느 순간 제품이 온갖 기능으로 뒤섞인 잡동사니 서랍이 되어 버립니다.
이 전환에서 잘 이야기되지 않는 부분이 바로 이 지점입니다. AI가 “판단”의 필요성을 없애주지 않습니다. 오히려 “판단”의 가치를 끌어올립니다. “할 수 있는가?”보다 “해야 하는가?”가 더 중요해지는 시점이 오는 것입니다.
이는 이름만 바꾸면 그대로 매니저의 역량입니다. 우선순위를 정하고, “아니오”라고 말하고, 성공 기준을 정의하고, 작은 실험을 설계하고, 나쁜 아이디어를 빠르게 정리하는 능력 말입니다.
이걸 실제로 운용하려면 매니지먼트에서 잘 알려진 두 개념을 가져오면 됩니다. 첫째, WIP(Work In Progress) 제한입니다. 동시에 허용하는 활성 에이전트 스트림의 수를 제한해서, 리뷰에 파묻히지 않도록 하는 것입니다. Simon Willison이 지적한 병목도 정확히 여기죠. 둘째, 킬 크라이테리아(kill criteria)입니다. 기능 구현을 시작하기 전에, 어느 시점·어떤 신호에서 이 작업을 중단할지 기준을 미리 정해두는 것입니다.
내가 즐기고 있는 것들 (그리고 왜 이 노력이 가치가 있는가)
“이동 중 위임”의 효과는 실제로 체감됩니다. 백그라운드 에이전트가 저장소를 기준으로 작업한 뒤, 리뷰 가능한 변경 사항을 가져올 수 있을 때, 우리는 “나중에 할 일로 이슈를 남겨두자”에서 “지금 바로 이 아이디어의 구현을 시작하자”로 옮겨갈 수 있습니다.
제가 현재 사용하는 셋업은, 로컬에서 35개의 세션으로 아키텍처와 제품의 미묘한 부분에 사람(저)이 깊게 개입하는 한편, 45개의 백그라운드 에이전트가 낮은~중간 복잡도의 작업을 맡는 구조입니다. 여기에 모바일에서 작업을 위임할 수 있는 능력이 더해지면서, 제 창작 루프는 “아이디어 → 구현 초안 → 리뷰 → 반복”이라는 흐름으로 꽤 많이 재편되었습니다.
품질 기준과 프로세스를 제대로 갖춘 상태라면, 이 루프가 짧아지는 경험은 정말 큰 만족감을 줍니다. 하지만 이 만족감은 오케스트레이션을 “마법”이 아니라 “매니지먼트”로 다룰 때만 유지됩니다. 결국 스스로 멀티태스킹과 컨텍스트 전환에 쓸 수 있는 대역폭을 현실적으로 바라봐야 합니다. 모두가 열다섯 개의 에이전트를 동시에 돌릴 필요는 없습니다. Boris의 워크플로는 “이런 것도 가능하다”는 극단값을 보여주는 참고 사례지, 필수 조건이 아닙니다.
오케스트레이션을 위한 간단한 운영 시스템
하나의 반복 가능한 루프를 정리하자면 이렇습니다.
매니저처럼 계획합니다. 결과, 제약, 수용 기준까지 포함해 브리프를 작성합니다. 오케스트레이터처럼 스폰합니다. 명확한 경계를 두고 병렬 에이전트들에게 태스크를 할당합니다. 비동기로 모니터링합니다. 가벼운 체크인으로 상태를 확인하고, 빠르게 막힌 부분을 풀어주며, 진행 중 작업을 괜히 뒤흔들지 않습니다. 공격적으로 검증합니다. 테스트, 린트, 구조화된 PR 패킷, 필요하다면 두 번째 에이전트의 리뷰까지 활용합니다. 신중하게 통합합니다. 어떤 순서로 머지할지 정하고, 경계가 깨지는 지점을 유심히 봅니다. 마지막으로 회고합니다. 다음 실행이 더 똑똑하게 시작될 수 있도록 AGENTS.md와 체크리스트를 업데이트합니다.
대부분의 사람들에게는, 현실적인 최적점이 “소수의 백그라운드 에이전트가 낮은~중간 복잡도의 작업을 처리하고, 사람은 아키텍처와 제품의 미묘한 부분에 직접 개입하는” 쪽에 가깝습니다. 그리고 자신이 감당할 수 있는 컨텍스트 전환의 양을 솔직하게 인식하는 것이 중요합니다.
이게 바로 오케스트레이션입니다. 그리고 여기에 빨리 익숙해지는 가장 좋은 방법은, 엔지니어들을 이끄는 사람을 효과적으로 만들었던 바로 그 역량을 배우는 것입니다. 명확성, 위임, 피드백 루프, 비동기 커뮤니케이션 말입니다.