에이전트 엔지니어링의 8단계
저자: Bassim Eledath
번역: 보옥
AI의 프로그래밍 능력이 우리가 이를 제어하는 능력을 이미 넘어섰다. 이것이 바로 SWE-bench 점수를 열심히 올리려는 모든 노력들이 엔지니어링 리더십이 진정으로 관심을 두는 생산성 지표와 동조되지 않는 이유다. Anthropic 팀은 단 10일 만에 Cowork를 출시했지만, 다른 팀은 동일한 모델을 사용함에도 불구하고 개념 검증(PoC)조차 완료하지 못했다. 차이점은 한 팀은 능력과 실천 사이의 격차를 이미 해소했고, 다른 팀은 그렇지 못했다는 데 있다.
이 격차는 하룻밤 사이에 사라지지 않으며, 등급별로 단계적으로 줄어든다. 총 8개의 등급이 있다. 이 글을 읽는 대부분의 독자들은 이미 초반 몇 개 등급을 통과했을 가능성이 높다. 그리고 다음 등급에 도달하기를 간절히 기다리고 있을 것이다—왜냐하면 등급 하나가 오를 때마다 산출물이 급격히 증가하며, 매번 모델 능력이 향상될 때마다 이러한 수익은 더욱 확대되기 때문이다.
또 다른 주목할 만한 이유는 다중 협업 효과다. 당신의 산출물은 당신이 생각하는 것보다 훨씬 더 동료들의 등급에 의존한다. 예를 들어, 당신이 7등급 고수라면, 잠자는 동안 백그라운드 에이전트가 여러 PR을 자동으로 작성해준다. 그러나 코드 저장소의 PR 병합을 위해 동료의 승인을 받아야 하는데, 그 동료가 아직 2등급에 머물러 있고 여전히 수동으로 PR을 검토하고 있다면, 당신의 처리량은 정체된다. 따라서 동료의 등급을 높이는 것은 곧 당신 자신에게도 이익이 된다.
여러 팀 및 개인이 AI 기반 프로그래밍을 어떻게 활용하는지를 관찰하고 인터뷰한 결과, 다음과 같은 등급 진화 경로를 관찰하였다(순서는 절대적이지 않음):
에이전트 엔지니어링의 8단계
1단계 및 2단계: Tab 자동 완성과 에이전트 전용 IDE
이 두 단계는 전체 구조를 완성하기 위해 간략히 언급만 하겠다. 필요 시 건너뛰어도 무방하다.
Tab 자동 완성은 모든 시작점이다. GitHub Copilot이 이 운동의 서막을 열었다—Tab 키 한 번 누르면 코드가 자동으로 완성된다. 많은 사람들은 이 단계를 이미 잊어버렸을 수도 있고, 신입 개발자들은 아예 이 단계를 건너뛰었을 수도 있다. 이 방식은 코드 골격을 먼저 구성한 후 AI가 세부 사항을 채워주는 경험 많은 개발자들에게 더 적합하다.
Cursor와 같은 AI 전용 IDE는 판도를 바꾸었다. 이 도구들은 채팅 기능을 코드베이스와 연결하여 파일 간 편집을 훨씬 쉽게 만들어준다. 하지만 한계는 여전히 컨텍스트에 있다. 모델은 자신이 ‘보는’ 내용만을 처리할 수 있으며, 문제는 종종 올바른 컨텍스트를 보지 못하거나, 반대로 너무 많은 부관련 컨텍스트를 보게 되는 데 있다.
이 단계에 있는 대부분의 사람들은 선택한 프로그래밍 에이전트의 계획 모드(plan mode)를 시도해본다: 대략적인 아이디어를 LLM에게 구조화된 단계별 계획으로 전달하고, 이 계획을 반복적으로 개선한 후 실행을 유도한다. 이 단계에서는 효과가 좋으며, 통제력을 유지하는 합리적인 방법이기도 하다. 그러나 이후 등급에서 보게 되겠지만, 계획 모드에 대한 의존도는 점차 줄어들게 된다.
3단계: 컨텍스트 엔지니어링
이제 흥미로운 부분에 진입한다. 컨텍스트 엔지니어링(Context Engineering)은 2025년의 올해의 키워드가 되었다. 이 개념이 등장한 이유는 이제 모델이 적절한 양의 명령을 안정적으로 따르고, 적절한 컨텍스트와 함께 작동할 수 있게 되었기 때문이다. 시끄러운 컨텍스트나 부족한 컨텍스트는 모두 나쁘다. 따라서 핵심 작업은 각 토큰의 정보 밀도를 높이는 것이다. “모든 토큰은 프롬프트 내 자신의 위치를 위해 싸워야 한다”는 것이 당시의 신조였다.
같은 정보를 더 적은 토큰으로—정보 밀도가 최고의 가치다 (출처: humanlayer/12-factor-agents)
실제로 컨텍스트 엔지니어링은 대부분 사람들이 인식하는 것보다 훨씬 광범위한 범위를 포함한다. 여기에는 시스템 프롬프트와 규칙 파일(.cursorrules, CLAUDE.md)이 포함된다. 또한 도구 설명 방식도 중요하다—모델은 이 설명을 읽고 어떤 도구를 호출할지 결정하기 때문이다. 대화 기록 관리도 포함되며, 장시간 실행되는 에이전트가 10차례째 대화에서 방향을 잃지 않도록 해야 한다. 또 한 가지는 매 라운드마다 노출할 도구를 결정하는 것으로, 너무 많은 선택지는 모델을 혼란스럽게 만들 수 있다—사람도 마찬가지다.
현재는 ‘컨텍스트 엔지니어링’이라는 용어를 거의 듣지 못한다. 균형추는 더 시끄러운 컨텍스트를 용인하고, 더 혼란스러운 상황에서도 추론할 수 있는 모델(더 큰 컨텍스트 윈도우 역시 도움이 된다) 쪽으로 기울었다. 그러나 컨텍스트 소비량을 주의 깊게 관리하는 것은 여전히 중요하다. 다음의 몇 가지 상황에서는 여전히 병목 현상이 발생할 수 있다:
- 소규모 모델은 컨텍스트에 더 민감하다. 음성 애플리케이션은 일반적으로 작은 모델을 사용하며, 컨텍스트 크기는 첫 토큰 지연 시간과도 관련되어 응답 속도에 영향을 준다.
- 토큰 소비가 많은 경우. Playwright와 같은 MCP(Model Context Protocol, 모델 컨텍스트 프로토콜)나 이미지 입력은 토큰을 급격히 소모하여, Claude Code에서 예상보다 훨씬 일찍 ‘압축된 세션’ 상태에 진입하게 만든다.
- 수십 개의 도구가 연결된 에이전트의 경우, 모델이 도구 정의를 파싱하는 데 사용하는 토큰 수가 실제 작업 수행에 사용하는 토큰 수보다 많아진다.
더 거시적인 관점에서 보면, 컨텍스트 엔지니어링은 사라진 것이 아니라 진화한 것이다. 초점은 ‘나쁜 컨텍스트 걸러내기’에서 ‘적절한 컨텍스트를 적절한 시점에 제공하기’로 옮겨갔다. 바로 이 전환이 4단계로 가는 길을 닦아주었다.
4단계: 복리 엔지니어링
컨텍스트 엔지니어링은 현재의 한 번의 세션을 개선한다. 복리 엔지니어링(Compounding Engineering, Kieran Klaassen 제안)은 이후의 모든 세션을 개선한다. 이 아이디어는 나를 비롯한 많은 사람들에게 전환점이 되었다—‘직관에 의한 프로그래밍’이 단순한 프로토타이핑 이상임을 깨닫게 해주었다.
이는 ‘계획 → 위임 → 평가 → 정착’의 반복 순환 구조다. 당신은 작업을 계획하고, LLM이 성공적으로 수행할 수 있도록 충분한 컨텍스트를 제공한다. 그런 다음 작업을 위임한다. 산출물을 평가한 후, 가장 중요한 단계—학습한 내용을 정착시키는 것이다: 무엇이 효과적이었는가, 무엇이 잘못되었는가, 다음에는 어떤 패턴을 따라야 하는가.
복리 순환: 계획, 위임, 평가, 정착—매 라운드가 다음 라운드를 더 나아지게 함
마법은 바로 ‘정착’ 단계에 있다. LLM은 무상태(stateless)다. 어제 당신이 명확히 제거한 의존성을 오늘도 다시 도입한다면, 내일도 똑같이 반복될 것이다—당신이 그렇게 하지 말라고 명시하지 않는 한. 가장 흔한 해결책은 CLAUDE.md(또는 이와 동등한 규칙 파일)를 업데이트하여 얻은 교훈을 미래의 모든 세션에 고정시키는 것이다. 다만 주의할 점은, 규칙 파일에 무작정 모든 것을 쏟아넣으려는 충동이 오히려 역효과를 낼 수 있다는 것이다(지시사항이 너무 많으면 아무것도 없는 것과 같다). 더 나은 접근법은 LLM이 스스로 유용한 컨텍스트를 쉽게 발견할 수 있는 환경을 조성하는 것이다—예를 들어, 항상 최신 상태로 유지되는 docs/ 폴더를 운영하는 것(7단계에서 자세히 설명함).
복리 엔지니어링을 실천하는 사람들은 LLM에 주입하는 컨텍스트에 매우 민감하다. LLM이 실수를 저질렀을 때, 그들의 본능적인 반응은 ‘모델이 못하니까’라고 탓하기보다는 ‘어떤 컨텍스트가 빠졌을까?’를 먼저 고민하는 것이다. 바로 이런 직관이 5~8단계를 가능하게 한다.
5단계: MCP 및 기술(Skill)
3단계와 4단계는 컨텍스트 문제를 해결한다. 5단계는 능력 문제를 해결한다. MCP와 맞춤형 기술을 통해 LLM은 데이터베이스, API, CI 파이프라인, 디자인 시스템뿐 아니라 브라우저 테스트용 Playwright, 알림용 Slack 등 다양한 외부 리소스에 직접 접근할 수 있게 된다. 모델은 이제 단순히 코드베이스를 ‘생각’하는 것을 넘어서, 실제로 그것을 조작할 수 있게 된 것이다.
MCP 및 기술에 관한 우수한 자료는 이미 많이 존재하므로, 그것들이 무엇인지 재설명하지는 않겠다. 다만 내가 실제로 사용하는 사례 몇 가지를 소개하겠다: 우리 팀은 PR 검토 기술을 공유하고 있으며, 팀원들이 함께 반복적으로 개선 중이다(현재도 계속 개선 중). 이 기술은 PR의 성격에 따라 조건부로 하위 에이전트를 실행한다. 하나는 데이터베이스 통합 보안을 점검하고, 하나는 복잡도 분석을 통해 중복 또는 과잉 설계를 표시하며, 또 하나는 프롬프트 건강도를 점검하여 팀 표준 형식을 준수하도록 보장한다. 또한 lint 검사와 Ruff도 실행한다.
왜 이처럼 PR 검토 기술에 많은 투자를 하는가? 에이전트가 대량의 PR을 생성하기 시작하면, 인간에 의한 수동 검토는 품질 관문이 아니라 병목이 되기 때문이다. Latent Space는 설득력 있는 논거를 제시했다: 우리가 잘 알고 있는 전통적 코드 리뷰는 이미 죽었다. 대신 자동화되고, 일관되며, 기술 중심의 검토가 그 자리를 차지했다.
MCP 측면에서는 Braintrust MCP를 사용하여 LLM이 평가 로그를 직접 조회하고 수정까지 수행할 수 있도록 했다. DeepWiki MCP를 사용하면, 에이전트가 수동으로 문서를 컨텍스트에 불러오지 않고도 어떤 오픈소스 저장소의 문서라도 접근할 수 있다.
팀 내 여러 사람이 유사한 기술을 각자 개별적으로 작성하기 시작하면, 이를 통합해 공유 레지스트리로 만드는 것이 바람직하다. Block(애도함)은 훌륭한 기사를 발표했는데, 그들은 100개 이상의 기술을 갖춘 내부 기술 시장과 특정 역할 및 팀을 위한 기술 패키지를 구축했다. 기술은 코드와 동등한 대우를 받는다: pull request, 검토, 버전 이력 등이 모두 적용된다.
또 하나 주목할 만한 트렌드는, LLM이 점차 MCP보다 CLI 도구를 선호하게 되고 있다는 점이다(그리고 각 회사가 자사의 CLI 도구를 내놓는 것 같기도 하다: Google Workspace CLI, Braintrust도 곧 출시 예정). 이유는 토큰 효율성이다. MCP 서버는 매 라운드마다 전체 도구 정의를 컨텍스트에 주입하는데, 에이전트가 해당 도구를 실제로 사용하든 안 하든 상관없이 말이다. 반면 CLI는 정반대다: 에이전트가 특정 목적에 맞는 명령을 실행하면, 관련 출력만이 컨텍스트 윈도우로 들어간다. 나는 바로 이 이유로 Playwright MCP 대신 agent-browser를 대량으로 사용한다.
잠시 멈춰서 생각해보자. 3단계부터 5단계까지는 이후 모든 것을 위한 기반이다. LLM은 어떤 일에는 놀라울 정도로 뛰어나고, 또 다른 일에는 놀라울 정도로 서투르다. 당신은 이러한 경계에 대한 직관을 키워야 하며, 그 위에 더 많은 자동화를 쌓을 수 있다. 만약 당신의 컨텍스트가 시끄럽고, 프롬프트가 부족하거나 부정확하며, 도구 설명이 모호하다면, 6~8단계는 단지 이러한 문제들을 확대시킬 뿐이다.
6단계: 하네스 엔지니어링
이제 로켓이 진짜로 이륙하기 시작한다.
컨텍스트 엔지니어링은 모델이 무엇을 보는지에 초점을 맞춘다. 하네스 엔지니어링(Harness Engineering)은 에이전트가 인간의 개입 없이도 신뢰성 있게 작동할 수 있도록 전체 환경—도구, 인프라, 피드백 루프—을 구축하는 데 초점을 둔다. 단순한 편집기가 아니라, 완전한 피드백 루프를 에이전트에게 제공하는 것이다.
OpenAI의 Codex 도구 체인—에이전트가 자신의 출력을 질의, 연관, 추론할 수 있는 완전한 관측 가능성 시스템 (출처: OpenAI)
OpenAI의 Codex 팀은 Chrome DevTools, 관측 가능성 도구, 브라우저 내비게이션을 에이전트 런타임에 통합하여, 스크린샷 캡처, UI 프로세스 자동화, 로그 조회, 자체 수정 결과 검증 등을 가능하게 했다. 단 하나의 프롬프트만 주어져도, 에이전트는 버그를 재현하고, 동영상을 녹화하며, 수정을 구현한다. 그런 다음 애플리케이션을 직접 조작하여 수정 내용을 검증하고, PR을 제출하며, 리뷰 피드백에 응답하고, 병합까지 수행한다—단지 판단이 필요한 순간에만 인간의 개입을 요청한다. 에이전트는 단순히 코드를 작성하는 것을 넘어서, 코드가 어떤 결과를 낳는지를 ‘보며’ 반복적으로 개선한다—마치 인간처럼 말이다.
나의 팀은 기술 장애 진단을 위한 음성 및 채팅 에이전트를 개발하고 있는데, 이를 위해 백엔드 인터페이스와 대화할 수 있는 CLI 도구인 converse를 만들었다. 이를 통해 어떤 LLM이라도 온라인 시스템에서 대화를 테스트하고, 코드를 수정한 후 반복적으로 개선할 수 있다. 때때로 이러한 자기 개선 루프는 몇 시간 동안 연속으로 실행되기도 한다. 결과가 검증 가능한 경우 특히 강력하다: 대화는 반드시 특정 프로세스를 따라야 하거나, 특정 상황에서 특정 도구(예: 인적 서비스 전환)를 호출해야 한다.
이 모든 것을 뒷받침하는 핵심 개념은 백프레셔 메커니즘(Backpressure)—자동화된 피드백 메커니즘(타입 시스템, 테스트, linter, pre-commit 훅)이다. 이는 에이전트가 인간 개입 없이도 오류를 스스로 발견하고 수정할 수 있게 한다. 자율성을 원한다면 반드시 백프레셔 메커니즘이 있어야 한다. 그렇지 않으면 단지 쓰레기 생산 기계를 얻게 될 뿐이다. 이는 보안 영역에도 확장된다. Vercel의 CTO는, 에이전트, 에이전트가 생성한 코드, 그리고 당신의 인증 정보는 서로 다른 신뢰 영역에 있어야 한다고 지적했다. 로그 파일에 묻힌 단 하나의 프롬프트 주입 공격만으로도, 모든 요소가 동일한 보안 컨텍스트를 공유한다면 에이전트가 당신의 자격 증명을 탈취할 수 있기 때문이다. 보안 경계 자체가 바로 백프레셔 메커니즘이다: 그것은 단순히 ‘무엇을 해야 하는가’가 아니라, ‘失控 시 에이전트가 무엇을 할 수 있는가’를 제약한다.
이 개념을 더 명확히 해주는 두 가지 원칙:
- 완벽함보다 처리량을 우선시하라. 매번 커밋이 완벽해야 한다고 요구하면, 에이전트는 동일한 버그를 반복적으로 수정하며 서로의 수정을 덮어쓰게 된다. 더 나은 방법은 작은 비차단 오류를 허용하고, 출시 전에 최종 품질 검사를 수행하는 것이다. 인간 동료에게도 우리는 그렇게 한다.
- 지시보다 제약을 우선시하라. 단계별로 명령하는 방식(“먼저 A를 하고, 다음에 B를 하고, 마지막으로 C를 하라”)은 점차 구식이 되고 있다. 내 경험상, 목록을 나열하는 것보다 경계를 정의하는 것이 훨씬 효과적이다. 왜냐하면 에이전트는 목록을 집요하게 따르면서 목록 외부의 모든 것을 무시하기 때문이다. 더 나은 프롬프트는 “이것이 내가 원하는 결과이며, 모든 테스트를 통과할 때까지 계속하라”는 것이다.
하네스 엔지니어링의 또 다른 핵심은, 에이전트가 코드 저장소 내에서 인간의 개입 없이 자유롭게 탐색할 수 있도록 보장하는 것이다. OpenAI는 AGENTS.md를 약 100행 이내로 유지하여 다른 구조화된 문서를 가리키는 목록 역할을 하도록 하고, 문서의 최신화를 CI 프로세스에 통합하여, 빠르게 구식이 되는 일시적 업데이트에 의존하지 않도록 한다.
이 모든 것을 구축한 후 자연스럽게 떠오르는 질문은: “에이전트가 자신의 작업을 검증하고, 저장소 내에서 자유롭게 탐색하며, 오류를 스스로 수정할 수 있다면, 왜 당신은 여전히 의자에 앉아 있어야 하는가?”
초반 등급에 머무르는 분들을 위한 경고: 앞으로 나올 내용은 다소 공상과학처럼 들릴 수 있다(하지만 괜찮다. 일단 저장해두고, 나중에 다시 읽어보면 된다).
7단계: 백그라운드 에이전트
직설적 평가: 계획 모드는 사라지고 있다.
Claude Code의 창시자인 Boris Cherny는 현재까지도 80%의 작업을 여전히 계획 모드로 시작한다고 밝혔다. 그러나 매 세대 새로운 모델이 출시될 때마다, 계획 후 단일 시도 성공률은 계속해서 상승하고 있다. 나는 계획 모드가 독립적인 인간 개입 단계로서 점차 사라질 임계점에 다다르고 있다고 본다. 이는 계획 자체가 중요하지 않다는 의미가 아니라, 모델이 이미 스스로 계획을 잘 세울 만큼 충분히 똑똑해졌다는 뜻이다. 다만 중요한 전제가 있다: 당신이 3~6단계의 작업을 제대로 해야만 이는 성립한다. 컨텍스트가 깨끗하고, 제약이 명확하며, 도구 설명이 완전하고, 피드백 루프가 닫혀 있다면, 모델은 인간의 검토 없이도 신뢰성 있게 계획을 수립할 수 있다. 이러한 준비가 되어 있지 않다면, 여전히 계획을 직접 감독해야 한다.
명확히 말하자면, 계획이라는 일반적인 실천은 사라지지 않지만 형태가 변하고 있다. 초보자의 경우, 계획 모드는 여전히 올바른 입구다(1~2단계 참조). 그러나 7단계의 복잡한 기능에서는 ‘계획’이 단순한 단계별 개요를 작성하는 것이 아니라, 코드베이스를 탐색하고, worktree에서 프로토타이핑 실험을 수행하며, 해결 방안의 공간을 탐색하는 ‘탐구’에 가까워진다. 그리고 점점 더 많은 경우, 이러한 탐구를 대신 수행하는 것은 백그라운드 에이전트다.
이는 매우 중요하다. 바로 이것이 백그라운드 에이전트를 가능하게 하기 때문이다. 만약 에이전트가 당신의 승인 없이도 신뢰성 있는 계획을 생성하고 실행할 수 있다면, 당신이 다른 일을 하는 동안 비동기적으로 실행될 수 있다. 이는 ‘나는 동시에 여러 탭을 왔다 갔다 한다’에서 ‘내 개입 없이도 작업이 진행되고 있다’는 근본적인 전환을 의미한다.
Ralph 루프는 인기 있는 입문 방식이다: 자율 에이전트 루프로, 제품 요구 사양(PRD)에 명시된 모든 항목이 완료될 때까지 프로그래밍 CLI를 반복 실행하며, 매 반복마다 새 컨텍스트를 가진 새로운 인스턴스를 시작한다. 내 경험상, Ralph 루프를 잘 운영하는 것은 쉽지 않다. PRD에 명시된 사항이 부족하거나 부정확하면, 결국 그 결함이 돌아와 당신을 괴롭힌다. 다소 ‘던져놓고 잊어버리는’ 성격이 강하다.
여러 개의 Ralph 루프를 병렬로 실행할 수 있지만, 에이전트를 더 많이 시작할수록 시간이 어디에 쓰이는지 알게 된다: 에이전트 간 조정, 작업 순서 배정, 산출물 검토, 진행 상황 촉진 등이다. 이제 당신은 코드를 작성하지 않는다—중간 관리자가 되어버린 것이다. 당신은 스케줄링을 처리할 오케스트레이션 에이전트가 필요하며, 그를 통해 의도에 집중할 수 있어야 한다.
Dispatch는 3개의 모델을 가로질러 5개의 워커를 병렬로 시작한다—당신의 세션은 간결하게 유지되며, 에이전트가 작업을 수행한다
최근 내가 대량으로 사용하는 도구는 Dispatch인데, 이는 내가 개발한 Claude Code 기술로, 당신의 세션을 지휘 센터로 바꾼다. 당신은 깔끔한 단일 세션에 머물러 있고, 워커(worker)는 격리된 컨텍스트에서 중노동을 처리한다. 스케줄러가 계획, 위임, 추적을 담당하며, 주요 컨텍스트 윈도우는 오케스트레이션에만 사용된다. 워커가 막힐 경우, 침묵 속에서 실패하는 대신 명확화 질문을 던진다.
Dispatch는 로컬에서 실행되므로, 작업과 긴밀히 연계되어야 하는 빠른 개발 시나리오에 매우 적합하다: 피드백이 빠르고, 디버깅이 용이하며, 인프라 오버헤드가 없다. Ramp의 Inspect는 보완적인 솔루션이다. 이는 실행 시간이 더 길고, 더 자율적인 작업에 적합하다: 각 에이전트 세션은 클라우드 샌드박스 VM에서 완전한 개발 환경과 함께 시작된다. PM이 Slack에서 UI 버그를 발견하고 표시하면, Inspect는 당신이 노트북을 닫는 순간부터 이를 인수하여 처리한다. 다만 인프라, 스냅샷, 보안 등 운영 복잡성이라는 대가가 따르지만, 로컬 에이전트가 따라갈 수 없는 규모와 재현성을 얻게 된다. 나는 로컬 및 클라우드 백그라운드 에이전트를 모두 사용할 것을 권장한다.
이 등급에서 놀랍도록 강력한 패턴 하나가 있다: 다른 작업에 대해 다른 모델을 사용하는 것이다. 최고의 엔지니어링 팀은 클론들로 구성되지 않는다. 팀원들은 서로 다른 사고방식, 다른 훈련 배경, 다른 강점을 지닌다. 동일한 논리가 LLM에도 적용된다. 이 모델들은 서로 다른 후처리(post-training)를 거쳤으며, 명확히 구분되는 성격 특징을 지닌다. 나는 자주 Opus를 구현 작업에, Gemini를 탐색적 연구에, Codex를 검토에 배정한다. 이렇게 얻는 종합 산출물은 어떤 단일 모델이 독립적으로 작업했을 때보다 훨씬 우수하다. 이를 집단 지성이라고 이해할 수 있지만, 코드에 적용된 집단 지성이다.
핵심적인 것은 구현자와 검토자를 분리해야 한다는 점이다. 이 교훈은 내가 너무나도 자주 실수하며 배웠다: 동일한 모델 인스턴스가 구현과 자신의 작업 평가를 모두 담당한다면, 편향이 생긴다. 문제를 무시하고, 모든 작업이 완료되었다고 말할 것이다—실제로는 그렇지 않다. 이는 악의가 있어서가 아니라, 당신이 자신의 시험을 채점하지 않는 것과 같은 이유다. 검토는 다른 모델(또는 검토 전용 프롬프트를 가진 별도 인스턴스)이 담당해야 한다. 그러면 신호 품질이 크게 향상된다.
백그라운드 에이전트는 CI와 AI의 결합을 위한 문을 활짝 열어준다. 일단 에이전트가 인간의 상시 감독 없이 실행될 수 있게 되면, 기존 인프라에서 이를 자동으로 트리거할 수 있다. 문서 봇은 매 병합 후 문서를 재생성하고, CLAUDE.md를 업데이트하기 위해 PR을 제출한다(우리는 이것을 사용 중이며, 엄청난 시간을 절약했다). 보안 검토 봇은 PR을 스캔하여 수정 사항을 제출한다. 종속성 관리 봇은 문제를 표시하는 데 그치지 않고, 실제로 패키지를 업그레이드하고 테스트 스위트를 실행한다. 좋은 컨텍스트, 지속적으로 정착되는 규칙, 강력한 도구, 자동화된 피드백 루프—이제 모두 자율적으로 실행된다.
8단계: 자율 에이전트 팀
현재까지 이 등급을 진정으로 정복한 사람은 아무도 없지만, 소수의 사람들이 이 방향으로 향해 나아가고 있다. 이것이 현재의 최전선이다.
7단계에서는 중심-방사형 모드로 작업 에이전트에게 작업을 분배하는 오케스트레이션 LLM이 존재한다. 8단계에서는 이 병목을 제거한다. 에이전트 간 직접 조정이 이루어진다—작업을 자발적으로 인수하고, 발견 사항을 공유하며, 종속성을 표시하고, 충돌을 해결한다—모든 과정이 단일 오케스트레이터를 거치지 않는다.
Claude Code의 실험적 Agent Teams 기능은 초기 구현 사례다: 여러 인스턴스가 공유 코드베이스에서 병렬로 작업하며, 각 팀원은 자신의 컨텍스트 윈도우에서 실행되면서 직접 상호 소통한다. Anthropic은 16개의 병렬 에이전트를 사용하여 Linux를 컴파일할 수 있는 C 컴파일러를 처음부터 구축했다. Cursor는 수주간 수백 개의 동시 에이전트를 실행하여 브라우저를 처음부터 구축하고, 자신의 코드베이스를 Solid에서 React로 마이그레이션했다.
하지만 자세히 보면 문제가 드러난다. Cursor는 계층 구조가 없을 때 에이전트들이 위축되어 제자리걸음을 하며 진전이 없음을 발견했다. Anthropic의 에이전트는 CI 파이프라인이 추가되어 회귀를 방지할 때까지 기존 기능을 계속 망쳐버렸다. 이 등급에서 실험을 수행하는 모든 사람들은 동일한 말을 한다: 다중 에이전트 조정은 매우 어려운 문제이며, 아직 최적의 해법은 없다.
솔직히 말해, 나는 대부분의 작업에 대해 모델이 이러한 수준의 자율성을 갖추기에는 아직 준비되지 않았다고 본다. 설령 모델이 충분히 똑똑하더라도, 컴파일러 및 브라우저 구축 외의 ‘달 착륙 수준’ 프로젝트에는 여전히 너무 느리고, 토큰 소비가 너무 많으며, 경제적으로 비효율적이다(인상적이나, 결코 성숙하지 않다). 우리 대부분이 매일 하는 작업에 대해서는 7단계가 진정한 레버리지 포인트다. 나는 8단계가 궁극적으로 주류가 될 것이라고 전혀 놀라지 않지만, 지금은 7단계에 집중할 것이다(단, Cursor처럼 ‘돌파’ 자체가 사업 모델인 경우는 예외).
??단계
피할 수 없는 “다음은 무엇인가?”라는 질문이다.
한 번의 마찰 없이 에이전트 팀을 오케스트레이션할 수 있게 되면, 인터페이스가 텍스트에 머무를 이유가 없다. 음성 대 음성(혹은 생각 대 생각?)으로 프로그래밍 에이전트와 상호작용하는 방식—단순한 음성-텍스트 변환 입력이 아니라, 대화형 Claude Code—이 자연스러운 다음 단계다. 당신의 애플리케이션을 보고, 일련의 변경 사항을 소리 내어 설명하면, 그것들이 당신 눈앞에서 실시간으로 이루어지는 모습을 보게 될 것이다.
완벽한 단일 생성을 추구하는 사람들이 있다: 원하는 것을 말하면, AI가 단번에 완벽하게 구현해준다. 문제는 이 전제가 인간이 자신이 정말 원하는 것을 정확히 안다고 가정한다는 데 있다. 그러나 우리는 모른다. 지금까지도 몰랐고, 앞으로도 모를 것이다. 소프트웨어 개발은 언제나 반복적인 과정이었으며, 앞으로도 그러할 것이다. 다만 이제는 훨씬 쉬워지고, 순수 텍스트 상호작용을 훨씬 넘어서며, 훨씬 더 빨라질 것이다.
그러면 물어보겠다: 당신은 어느 등급에 있는가? 다음 등급에 도달하기 위해 무엇을 하고 있는가?
당신은 어느 등급에 있는가?
프로그래밍 작업을 시작할 때 보통 어떻게 AI를 활용하는가?
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
