진짜 병목은 코딩이 아니다, 에이전트 6개가 쓴 코드 동시 리뷰다

이번 주 Meta의 AI 코딩 시장 진입에는 곱씹어 볼 만한 구체적인 주장이 따라붙었다. 이 회사의 새로운 터미널 기반 코딩 에이전트인 Muse Code는 단순히 한 번에 한 파일씩 코드를 작성하는 데 그치지 않는다. 마크 저커버그의 출시 게시물에 따르면, 작업 규모가 충분히 크면 Muse Code는 "격리된 워크트리에서 병렬로 작업하는 별도의 하위 에이전트들로 작업을 분산"하며, Meta 자체 테스트에서는 충돌 없이 게임용 기능 6개를 동시에 구축했다고 한다. 이는 출시 당일 자사 제품에 대해 공급업체가 내놓은 주장이지 독립적으로 검증된 결과가 아니므로, 구체적인 수치는 회의적으로 받아들일 필요가 있다. 하지만 이 설명이 보여 주는 워크플로의 형태는 Meta만의 아이디어가 아니다. 병렬적이고 격리된 에이전트 실행은 코딩 에이전트 업계 전반에서 기본 패턴이 되어 가고 있으며, 이는 실제로 "이 일을 잘한다"는 것이 무엇을 의미하는지 바꿔 놓는다.

지난 2년 동안 AI 코딩 도구의 핵심 홍보 문구는 대체로 단일 작업 흐름에서의 속도에 관한 것이었다. 에이전트 하나, 작업 하나, 검토할 diff 하나라는 식이다. 이는 대부분의 엔지니어가 이미 어느 정도 익힌 기술이다. diff를 읽고, 테스트를 실행하고, 배포하면 된다. 하지만 격리된 워크트리에서 작업하는 여러 에이전트에게 일을 분산하면 이 모델이 깨진다. 더 이상 하나의 사고 흐름에서 나온 일관된 변경 하나를 검토하는 것이 아니다. 서로 독립적으로 추론한 여러 변경 사항을 동시에 검토하고, 이들이 서로 모순되거나 로직을 중복하거나 코드베이스의 공유된 한 부분이 어떻게 동작해야 하는지에 대해 조용히 엇갈리지 않으면서 하나의 작동하는 시스템으로 수렴하도록 해야 한다.

왜 이것은 기존 기술의 더 빠른 버전이 아니라 진정으로 다른 기술인가

AI가 작성한 diff 하나를 검토하는 일은 대체로 정확성 확인이다. 이 코드가 말한 대로 동작하는가, 주변의 무언가를 망가뜨리지는 않는가를 보는 것이다. 여러 병렬 에이전트의 결과물을 검토하면, 지금까지 대부분의 사람이 연습해 볼 일이 없었던 층위가 추가된다. 최근까지는 어느 한 사람의 업무에도 필요하지 않았던 교차 diff 일관성이다. 두 에이전트가 같은 헬퍼 함수의 각자 버전을 만들어 내지는 않았는가? 한 에이전트의 "격리된" 변경이 다른 에이전트가 한창 다시 작성 중인 파일에 조용히 의존하고 있지는 않은가? 병합 단계가 실제 충돌을 제대로 포착했는가, 아니면 한 브랜치의 가정을 다른 브랜치의 가정 대신 조용히 선택해 버렸는가? 이는 전통적인 의미의 버그가 아니다. 각각의 개별 diff가 자체 테스트를 통과하면서도, 합쳐진 뒤에는 일관성 없는 시스템을 만들어 낼 수 있다.

이는 분산된 엔지니어링 팀이 인간 기여자들과 늘 관리해 온 것과 같은 문제를 며칠이 아니라 몇 분 안에 압축해 처리하는 것이다. 차이가 있다면, 주니어 엔지니어들로 구성된 팀은 작업이 모호해 보일 때 자연스럽게 지침을 요청하지만, 맡은 범위를 완수하도록 최적화된 에이전트는 종종 엉뚱한 질문에 대해 자신감 있고 문법적으로 깔끔한 답을 내놓는다는 점이다. 이를 잡아내려면 처음부터 작업을 충분히 잘 이해해 분해한 사람이 필요하다. 즉 실제 병목이 되는 기술은 "코드를 빠르게 검토하는 것"이 아니라 "안전하게 병렬로 실행할 수 있는 조각들로 작업을 나누고, 어떤 조각들은 병렬로 실행할 수 없는지 아는 것"이다.

특히 코딩 도구를 넘어 나타나는 더 넓은 패턴

이 현상이 개발자 도구에만 국한되지 않는다는 점에 주목할 필요가 있다. 같은 주에 공개된 Google의 검색창 개편은 AI Overviews와 AI Mode를 하나의 흐름으로 통합한다. 이 흐름은 텍스트, 이미지, PDF, 동영상, 그리고 열려 있는 Chrome 탭을 입력으로 받을 수 있으며, 작업을 쿼리 파서가 아니라 에이전트에게 맡긴다. 두 출시의 공통된 흐름은 같다. 인터페이스가 "AI에게 하나의 명확한 지시를 주고 하나의 명확한 결과를 확인하는" 방식에서 벗어나, "AI에게 범위가 느슨하게 정해진 목표와 입력 자료 더미를 넘기고, 단계는 AI가 알아서 정하도록 하는" 방식으로 이동하고 있다. 이 패턴은 코드 편집기뿐 아니라 에이전트형 도구가 배포되는 모든 곳에서 나타난다. 따라서 검토하고 조율하는 능력은 엔지니어링 직무를 훨씬 넘어, 단일 프롬프트가 아니라 여러 단계의 작업을 AI 시스템이 수행하도록 지시하는 모든 사람에게 중요해질 것이다.

실제로 무엇을 연습해야 하는가

코드를 작성하거나 관리한다면, 구체적으로 확인할 수 있는 몇 가지 습관을 들이는 것이 관련 내용을 읽는 것보다 이 능력을 더 빠르게 키워 준다.

• 격리된 워크트리가 실제로 무엇인지 알아 두라 (git의 worktree 기능을 사용하면 여러 브랜치를 한 번에 별도의 디렉터리에 체크아웃할 수 있다) 병렬 변경이 "충돌할 수 없다"는 도구의 주장을 믿기 전에 이를 익혀 두어야 한다. 실행 중 격리되어 있다고 해서 병합 시점의 일관성까지 보장되는 것은 아니다. 이는 별도의 단계이며, 면밀히 지켜볼 가치가 있다.
• 코딩 에이전트가 작업을 분해해야 할 만큼 충분히 큰 작업을 의도적으로 맡기고, 결과로 나온 diff를 읽기 전에 에이전트가 작업을 어떻게 나누는지 읽어 보라. 분해 방식은 코드 자체보다 결과물을 신뢰할 수 있는지에 대해 더 많은 것을 알려 준다.
• diff를 한 번에 하나씩이 아니라 묶음으로 검토하는 연습을 하라. 서로 관련된 변경 세 가지나 네 가지를 동시에 머릿속에 담고 서로 어긋나는 지점을 찾아내는 능력은 각각을 따로 검토해 각자의 장점만으로 승인하는 것과 다르다.
• 성공했을 때뿐 아니라 충돌이 발생하면 어떻게 되는지도 물어보라. 자동 병렬 병합을 주장하는 도구라면 두 에이전트가 실제로 같은 로직을 건드렸을 때 무엇을 하는지 보여 줄 수 있어야 한다. 성공 경로보다 이 실패 경로가 그 도구에 실제 작업을 맡겨도 안전한지를 더 잘 알려 준다.

이 중 어느 것도 고용주가 특정 제품을 도입할 때까지 기다릴 필요는 없다. 분해하고, 할당하고, 다시 합치고, 검증하는 패턴은 이제 여러 공급업체의 코딩 에이전트와 소비자용 AI 인터페이스 모두에서 나타나고 있다. 단일 작업 흐름의 결과물만 검토하는 데 그치지 않고 그 순환을 관리하는 데 익숙해지는 사람들은 결국 어느 회사의 에이전트가 우위를 차지하든 계속 유효한 기술을 쌓게 된다.