Addy Osmani블로그
AI 코딩 에이전트에게도 매니저가 필요하다
뛰어난 테크 리드나 매니저를 만드는 역량은 AI 코딩에도 그대로 적용된다. 여러 에이전트를 병렬로 돌리기 시작하는 순간, 컨텍스트를 디버깅하는 수준을 넘어 팀을 이끄는 일이 펼쳐진다. 명확한 지시, 위임, 검증 루프, 비동기 커뮤니케이션 — 오케스트레이션(orchestration)이 점차 주류로 자리 잡으면서, 일하는 방식의 본질이 달라지고 있다.
머지않아, 가장 큰 레버리지를 발휘하는 개발자는 비동기 우선 매니저처럼 여러 AI 코딩 에이전트를 병렬로 운용하는 모습이 될 것이다. 에이전트는 이제 격리된 환경에서 백그라운드로 의미 있는 작업을 수행하고, 검토 가능한 결과물 — 대개 풀 리퀘스트(pull request) — 를 들고 돌아올 수 있다. 물론 품질 검증은 여전히 필요하다. 하지만 병목은 더 이상 "에이전트가 코드를 짤 수 있느냐?"가 아니다. "이걸 만들어야 하는가?"와 "여러 에이전트를 효과적으로 관리할 수 있는가?"로 바뀌었다.
이 미래를 예고하는 워크플로가 이미 등장하고 있다. Claude Code 개발자 Boris Cherny의 스레드가 최근 화제를 모은 것도 그 변화를 실감 나게 보여줬기 때문이다. 그는 터미널 탭에서 Claude Code 세션 다섯 개를 로컬로 돌리는 동시에, 브라우저에서 다섯에서 열 개를 추가로 실행한다. 심지어 외출 중에 휴대폰으로 세션을 시작해두고 나중에 확인하기도 한다. 이것이 바로 오케스트레이션이다.
한편, 신중한 엔지니어들은 병렬 에이전트 방식을 좀 더 회의적인 시각에서 기록하고 있다. 내가 계속 되새기게 되는 건 Simon Willison의 견해다. 그가 짚은 핵심은 이렇다. 진짜 병목은 코드 생성이 아니라 코드 리뷰다. 그럼에도 병렬 작업 자체에서 실질적인 가치를 발견했는데, 자신의 집중력 한계를 솔직하게 인정하고, 인지 과부하를 일으키지 않을 작업을 고를 때만 가능하다고 했다. 나 역시 비슷한 워크플로를 구축해보면서 같은 결론에 닿았다. 가치는 분명히 있다. 단, 마법처럼 기대하는 게 아니라 관리의 관점으로 접근할 때만.
사고방식 자체를 바꿔야 한다. 이제는 에이전트 하나와 짝을 이루는 게 아니라, 작은 팀 하나를 이끄는 것이다.
바로 이 때문에, 뛰어난 테크 리드나 엔지니어링 매니저, 기술 리더십을 갖춘 사람의 역량이 곧바로 "AI 코딩을 잘하는 것"으로 연결된다. 규모가 커지면 AI 코딩은 더 이상 프롬프트 문제가 아니라 관리 문제가 되기 때문이다.
새로운 워크플로를 위한 멘탈 모델
나는 두 가지 모드를 나란히 운용하는 방식으로 생각한다.
첫 번째는 직접 개입하며 인간이 루프 안에 머무는 로컬 세션이다. 아키텍처 결정, 까다로운 리팩터, 제품의 미묘한 맥락, 요구사항이 불분명한 상황, 그리고 판단력과 감각이 지배하는 모든 작업이 여기에 해당한다. 에이전트와 짝을 이뤄 실시간으로 방향을 잡아가며, 에이전트가 갖지 못한 컨텍스트를 바탕으로 결정을 내린다.
두 번째는 비동기로 돌아가는 클라우드 또는 백그라운드 세션이다. 범위가 명확하게 정해진 작업에 적합하다. 단순한 기능 구현, 패턴이 뚜렷한 마이그레이션, 테스트 생성, 문서 업데이트, 의존성 버전 업, 소규모 버그 수정, 국소적인 리팩터 등이 여기에 속한다. 작업을 던져두고 다른 일로 전환한 뒤, 나중에 돌아와 결과물을 검토하면 된다.
이 구분은 현재 도구들의 발전 방향과도 자연스럽게 맞아떨어진다. 클라우드 에이전트(GitHub Copilot Agent, Claude Web, Codex, Jules 등)는 명시적으로 병렬 실행이 가능한 샌드박스 작업 방식으로 포지셔닝되어 있으며, 코드를 작성하고, 명령을 실행하고, 검토를 위한 변경사항을 제안한다.
GitHub의 Copilot 코딩 에이전트도 같은 방식을 표방한다. 비동기 백그라운드 에이전트로서 드래프트 풀 리퀘스트를 열고 백그라운드에서 작업을 진행한 뒤, 리뷰를 요청하면 코멘트를 남기고 반복 개선할 수 있다. 플랫폼들은 에이전트 하나를 다루는 것을 넘어 여러 에이전트를 통합 관리하는 '미션 컨트롤' 대시보드로 나아가고 있다. GitHub은 한 걸음 더 나아가, 서드파티 코딩 에이전트 여러 개를 한 곳에서 조율하는 컨트롤 플레인 'Agent HQ'를 공개 예고했는데, 같은 작업을 병렬로 실행해 결과물을 비교하는 기능까지 포함한다.
결국 핵심 질문은 "어떤 모델이 코드를 가장 잘 짜는가?"에서 "이걸 고성과 팀처럼 운용할 수 있는가?"로 바뀐다.
바로 그 지점에서 매니저의 역량이 빛을 발한다.
매니저의 역량이 AI 코딩 실력으로 이어지는 이유
나는 효과적인 관리 역량에 대해 깊이 다룬 글을 쓴 바 있다
사람을 관리하다 보면 쓴맛을 보며 배우게 된다. 결과물의 품질은 이미 그 전 단계에서 결정된다는 사실을. 모호한 요구사항, 불분명한 오너십, '완료'의 기준 부재, 피드백 루프의 부재가 낭비를 만들어낸다. 이는 "팀원"이 빠른 속도로 움직이는 비인간 에이전트 집합일 때도 마찬가지다. 어쩌면 더 심하게.
Anthropic의 Claude Code 모범 사례 가이드는 이 점을 명확히 짚는다. 처음부터 구체적으로 지시할수록 성공률이 실질적으로 올라가고, 방향 수정도 줄어든다. 도구를 위한 가이드지만, 쓰인 언어는 영락없이 매니저의 언어다.
가장 직접적으로 전이되는 네 가지 역량을 소개한다.
명확한 작업 범위 설정: 감으로 말하지 말고, 브리프(brief)로 전달하라
모호함이 에이전트의 효율을 떨어뜨린다면, 해야 할 일은 분명하다. 아이디어 수준의 생각을 구현 단계에서도 흔들리지 않을 브리프로 바꾸는 것. 이것이 바로 좋은 매니저가 하는 일이다. 의도를 실행 가능한 형태로 변환하는 것.
실용적인 에이전트 브리프는 이런 요소를 담아야 한다. 결과물(작업이 끝났을 때 어떤 상태여야 하는가), 컨텍스트(코드베이스의 어디에 위치하며 어떤 패턴이 있는가), 제약 조건(성능, 보안, API 형태, 의존성 규칙, 스타일 컨벤션), 비목표(명시적으로 하지 않을 것), 수락 기준(테스트 통과나 엔드포인트 동작처럼 구체적인 확인 항목), 통합 주의사항(수정 금지 파일과 인터페이스 경계), 그리고 검증 계획(제대로 동작하는지 어떻게 확인할 것인가).
깔끔한 풀 리퀘스트를 받느냐, 믿을 수 없는 천 줄짜리 뭉텅이를 받느냐의 차이가 여기서 갈린다.
이 과정을 훨씬 쉽게 만드는 두 가지 방법이 있다. 첫째, 에이전트에게 기존 패턴을 참고하게 한다. Anthropic의 가이드는 에이전트가 따르거나 수정해야 할 파일을 명시적으로 언급하도록 권장한다. 에이전트가 스스로 규칙을 만들어내는 대신, 실제 컨벤션에 기반해 작업하게 된다.
둘째, 에이전트가 항상 참조할 수 있는 곳에 규칙을 영구적으로 기록해둔다. 이미 표준으로 자리 잡은 방식으로, OpenAI의 Codex 문서는 AGENTS.md 파일을 활용해 실행할 테스트, 린트 규칙, 의존성 정책, 문서화 요건에 대한 일관된 기대치를 전달하도록 안내한다. 새로운 팀원을 코드베이스에 온보딩해본 경험이 있다면 낯설지 않을 것이다. 작업을 시작하기 전에 지도와 컨벤션, 그리고 완료의 정의를 먼저 건네는 것.
위임: 완전히 넘길 것과 직접 판단해야 할 것을 구분하라
에이전트를 활용할 때 빠지기 쉬운 함정이 있다. 정작 사람이 해야 할 일 — 제품 의도, API 설계의 트레이드오프, 아키텍처 경계, 장기 유지보수 결정 — 까지 지나치게 위임하는 것이다.
OpenAI의 'AI 네이티브 엔지니어링 팀' 가이드는 이를 소프트웨어 개발 생애주기 전반에 걸친 세 단계로 나눈다. 위임, 검토, 직접 소유. 낙관적인 시각에서 쓰인 가이드임에도, 특히 모호한 문제에서는 최종 결정과 최종 승인의 책임을 엔지니어가 유지해야 한다고 명시한다.
이는 오케스트레이션에도 그대로 적용된다. 명확한 스펙이 있는 기계적 구현, 보일러플레이트 리팩터, 꼼꼼한 리뷰를 전제로 한 테스트 생성, 문서 업데이트, 위험도 낮은 유지보수 작업은 완전히 위임할 수 있다. 공유 인터페이스에 영향을 주거나, 머지 충돌 가능성이 있거나, 까다로운 제품 엣지 케이스가 있거나, 데이터 마이그레이션이 포함된 작업은 체크포인트를 두고 관여한다. 그리고 시스템 아키텍처와 새로운 추상화, 감각이 필요한 범위가 넓은 리팩터, 제품 방향과 "이걸 만들어야 하는가?"에 관한 결정, 보안이나 개인정보에 민감한 설계 결정은 위임하지 않거나, 선택지 탐색 용도로만 제한적으로 맡긴다.
이것은 팀에서 일을 배분하는 것과 같은 근육이다. 누가 무엇을 소유하는지, 어느 정도의 자율성이 적절한지, 작업이 굳어지기 전에 어디서 체크포인트를 두어야 하는지를 끊임없이 판단하는 것.
검증 루프: 문제를 조기에 잡아라
사람을 관리하다 보면 깨닫게 된다. 시간을 가장 빠르게 잃는 방법은 품질이 낮은 결과물을 너무 늦게 검토하는 것이라는 사실을. 그래서 초기 피드백 루프와 품질 게이트가 필요하다. 에이전트도 다르지 않다. 다만 에이전트는 낮은 품질의 결과물을 고속으로 쏟아낼 수 있다는 점이 다르다.
검증 루프가 핵심 열쇠다. 최고의 도구 개발사들은 이를 가이드에 직접 반영하고 있다. Anthropic의 모범 사례는 여러 Claude 인스턴스를 동시에 실행하되, 하나는 코드를 작성하고 다른 하나는 리뷰와 테스트를 통해 검증하는 방식을 명시적으로 제안한다. 역할 분리가 있는 2인 체계처럼 운용하는 것이다. OpenAI의 Codex 역시 도구 활용을 명확히 강조한다. 명령 실행, 테스트 실행, 통과 상태까지 반복, 그다음 풀 리퀘스트 제안.
실제로 검증 루프를 구성하면 이런 모습이 된다. 에이전트에게 테스트 스위트(또는 범위를 좁힌 부분집합)를 실행하고, 그 결과를 최종 메시지에 포함하도록 요구한다. 수정된 영역에 대해 린트와 타입 검사를 통과하도록 요구한다. 동작 변경이 있다면 테스트를 추가하거나 수정하도록 요구한다. 마지막으로 구조화된 'PR 패킷'을 요구한다. 변경 내용 요약, 이 접근 방식을 선택한 이유, 수정된 파일 목록, 테스트 계획과 결과, 그리고 위험 요소나 후속 과제.
한 단계 더 나아가고 싶다면, 2에이전트 패턴을 써보자. 에이전트 A가 구현하고, 에이전트 B가 정확성, 스타일, 엣지 케이스, 누락된 테스트를 기준으로 리뷰한다. 그리고 에이전트 A(또는 새로운 에이전트 C)가 리뷰 피드백을 반영해 검증을 다시 수행한다. 이론이 아니다. Anthropic이 워크플로 고도화 방안으로 명시적으로 권장하는 방식이다.
여기서도 매니저의 본능이 중요하다. 단순히 코드가 컴파일되는지 확인하는 것을 넘어, 컨벤션에 부합하는지, 유지보수 가능한지, 의도와 일치하는지를 판단해야 한다.
비동기 체크인: 에이전트를 팀원처럼 대하라
열 개의 세션을 병렬로 돌리고 있다면, 각각을 일일이 스크롤하며 무슨 일이 있었는지 파악할 여유가 없다. 가볍고 반복 가능한 체크인이 필요하다. 이것이 바로 비동기 관리 방식을 에이전트에 적용하는 것이다.
체크인 주기를 정해둔다. "15분 안에 의미 있는 진전이 없으면 멈추고 블로커를 보고하라." 상태 보고는 예측 가능한 형식으로 요청한다. 무엇이 바뀌었나? 다음 단계는? 위험 요소나 블로커는? 나에게 필요한 게 있나?
사소해 보일 수 있지만, 이 방식이 있어야 병렬 작업이 궤도를 벗어나지 않는다. 계속 들여다보지 않아도. 구체적인 비유를 들자면, 에이전트 관리는 시간대가 다른 분산 팀을 이끄는 것과 많이 닮았다. 명확성을 미리 충분히 확보하고, 서면 업데이트에 의존하며, 실시간 개입은 의사결정과 블로커 해소에만 집중한다.
어려운 부분은 분명 존재한다 (그리고 그것들은 관리 문제다)
머지 충돌은 빠르게 불어난다
인접한 코드를 건드리는 병렬 에이전트는, 조율 없이 다섯 명의 엔지니어가 같은 파일에 동시에 손대는 것과 같다. 도구의 문제가 아니라 경계 설정의 문제다. 해법도 인간 팀에서와 동일하다. 의도적인 작업 경계를 만들고, 작업을 격리하고, 인터페이스를 명확히 정의하는 것.
실질적으로는 에이전트를 별도의 작업 디렉터리나 브랜치에서 실행하는 방식이 자주 쓰인다. Git worktree가 깔끔한 패턴이다. 같은 저장소에서 여러 브랜치를 각자의 디렉터리에 동시에 체크아웃할 수 있다. Claude Code 문서는 병렬 세션에서 인스턴스 간 충돌을 막기 위해 git worktree 사용을 명시적으로 권장하며, Anthropic의 모범 사례 가이드는 worktree에 터미널 탭을 하나씩 배정하는 방식을 운용 패턴으로 단계별로 안내한다. 클라우드 에이전트를 사용하더라도 원칙은 같다. 브랜치 분리, 작은 풀 리퀘스트, 모듈별 오너십 명확화.
팀 협업에서 빌려온 내가 가장 좋아하는 경계 규칙은 이렇다. 에이전트 하나당 풀 리퀘스트 하나, 여러 에이전트가 만든 거대 풀 리퀘스트는 금지. 두 에이전트가 같은 파일을 건드릴 가능성이 있다면, 작업 분할을 다시 설계한다. 공유 인터페이스는 첫 번째 풀 리퀘스트(사람 주도)에서 처리하고, 그 위에서 에이전트가 작업하게 한다.
감각과 "이걸 만들어야 하는가?"가 진짜 병목이 된다
만드는 일이 저렴해지면, 모든 걸 만들기 시작한다. 그것이 생산적으로 느껴지다가도, 결국 제품은 잡동사니 기능 창고가 되어버린다.
이 변화에서 충분히 주목받지 못하는 지점이 바로 이것이다. AI는 판단의 필요성을 없애는 게 아니라, 판단의 가치를 높인다. "할 수 있는가?"보다 "해야 하는가?"가 점점 더 중요해진다.
이것은 사실 매니저의 역량이 위장한 모습이다. 우선순위 설정, 거절하기, 성공 기준 정의, 작은 실험 운용, 나쁜 아이디어를 빠르게 끊어내기.
이를 실제로 적용하고 싶다면, 관리 기법에서 두 가지 개념을 빌려오면 된다. 첫째, WIP 한도(WIP limit). 동시에 활성화할 에이전트 스트림 수를 제한해서 리뷰에 잠기지 않도록 한다(Willison이 짚은 것과 같은 병목이다). 둘째, 중단 기준. 기능을 만들기 시작하기 전에, 어떤 상황이 되면 개발을 멈출 것인지를 미리 정해둔다.
내가 즐기고 있는 것들 (그리고 이 수고가 가치 있는 이유)
"언제 어디서나 위임"하는 효과는 실제로 체감된다. 백그라운드 에이전트가 저장소를 기반으로 작업하고 검토 가능한 변경사항을 들고 돌아오면, "나중에 이슈로 남겨두기"에서 "지금 바로 아이디어를 구현하기"로 전환된다.
현재 내 셋업은 이렇다. 네다섯 개의 백그라운드 에이전트가 중하위 복잡도 작업을 처리하는 동안, 나는 아키텍처와 섬세한 제품 작업에 직접 개입하며 세 개에서 다섯 개의 세션을 로컬에서 운용한다. 모바일에서도 작업을 위임할 수 있게 되면서 내 창작 루프가 바뀌었다. 아이디어 → 구현 초안 → 리뷰 → 반복.
품질 기준과 프로세스가 갖춰져 있을 때 이 루프는 정말 짜릿하다. 창작 사이클이 촘촘해지기 때문이다. 하지만 오케스트레이션을 마법이 아닌 관리로 대할 때만 그 만족감이 유지된다. 멀티태스킹과 컨텍스트 전환의 한계를 스스로 솔직하게 인정해야 한다. 모든 사람이 열 개에서 열다섯 개의 에이전트를 동시에 돌릴 필요는 없다. Boris의 워크플로는 가능성의 극단을 보여주는 사례로 참고할 것이지, 따라야 할 기준이 아니다.
오케스트레이션을 위한 간단한 운용 체계
반복 연습할 수 있는 하나의 루프를 정리하면 이렇다.
매니저처럼 계획한다 — 결과물, 제약 조건, 수락 기준을 담은 브리프를 작성한다. 오케스트레이터처럼 실행한다 — 명확한 경계를 기반으로 병렬 에이전트에 작업을 배분한다. 비동기로 모니터링한다 — 가벼운 체크인, 빠른 블로커 해소, 진행 중 간섭 최소화. 철저하게 검증한다 — 테스트, 린트, 구조화된 PR 패킷, 필요시 2에이전트 리뷰. 신중하게 통합한다 — 순서를 정해 머지하고, 경계 침범 여부를 확인한다. 그리고 회고한다 — AGENTS.md와 체크리스트를 업데이트해서 다음 번엔 더 스마트하게 시작한다.
대부분의 사람에게 최적 지점은, 중하위 복잡도 작업을 처리하는 소수의 백그라운드 에이전트를 운용하면서 아키텍처와 제품의 세부 맥락에는 직접 개입하고, 자신이 감당할 수 있는 컨텍스트 전환의 한계를 현실적으로 인정하는 모습에 가깝다.
그것이 오케스트레이션이다. 그리고 그것을 가장 빨리 익히는 방법은, 엔지니어를 이끄는 데 효과적인 역량을 기르는 것과 같다. 명확성, 위임, 피드백 루프, 비동기 커뮤니케이션.
O'Reilly와 함께 새로운 AI 지원 엔지니어링 도서를 출간했습니다. 관심 있으신 분들을 위해 책 사이트에 무료 팁도 여럿 준비되어 있습니다.