복합(컴파운드) 엔지니어링: `Every`는 어떻게 에이전트로 코드를 작성하나요

https://every.to/chain-of-thought/compound-engineering-how-every-codes-with-agents?loggedin=true

에이전트가 여러분의 코드를 100% 작성한다면 소프트웨어 엔지니어링은 어떻게 될까요? 이는 AI 코딩이 매우 강력해지면서 우리가 정면으로 마주해야 했던 질문입니다. 아무도 수동으로 코드를 쓰지 않습니다. 컴퓨터에 코드를 입력하거나 코드 에디터의 깜박이는 커서를 바라보는 일이 이상하게 느껴집니다.

지금까지의 엔지니어링은 대부분 코딩이 어렵고 엔지니어가 희소하다는 가정 위에 서 있었습니다. 이러한 병목을 제거하면, 수동으로 테스트를 작성하거나, 풍부한 문서가 딸린 사람이 읽을 수 있는 코드를 고생스럽게 타이핑하는 전통적인 엔지니어링 관행은 느리고 구식처럼 느껴집니다. 이러한 새로운 역량과 변화하는 제약에 대응하기 위해, 우리는 **복합 엔지니어링(compound engineering)**이라고 부르는 새로운 스타일의 엔지니어링을 만들어왔습니다.

전통적 엔지니어링에서는 각 기능이 다음 기능을 더 어렵게 만들 것이라고 예상합니다—더 많은 코드는 더 많은 엣지 케이스, 더 많은 상호의존성, 더 예측하기 어려운 문제들을 의미하기 때문입니다. 반대로 복합 엔지니어링에서는 각 기능이 다음 기능을 더 쉽게 만들 것이라고 기대합니다. 이는 복합 엔지니어링이 에이전트와 팀 구성원을 위한 학습 루프를 만들기 때문으로, 각 버그, 실패한 테스트, 혹은 아하 문제 해결 인사이트가 문서화되어 향후 에이전트가 사용하게 됩니다. 코드베이스의 복잡성은 여전히 증가하지만, 이제 AI의 코드베이스 지식도 함께 증가하여 향후 개발 작업이 더 빨라집니다.

그리고 이것은 효과가 있습니다. 우리는 내부적으로 다섯 개의 소프트웨어 제품을 운영하고 있습니다(그리고 몇 개를 더 인큐베이팅 중입니다). 각 제품은 주로 한 사람이 구축하고 운영합니다. 이 제품들은 단지 멋진 데모가 아니라, 매일 수천 명이 중요한 작업을 위해 사용하고 있습니다.

이 변화는 모든 회사에서 소프트웨어가 구축되는 방식과 모든 개발자가 얼마나 야심차고 생산적일 수 있는지에 막대한 영향을 미칩니다: 오늘날, AI를 올바르게 사용한다면, 단 한 명의 개발자가 몇 년 전 다섯 명의 개발자가 했던 일을 할 수 있습니다—Every¹에서의 우리의 경험에 기반한 말입니다. 필요한 것은 그 힘을 활용할 수 있는 좋은 시스템뿐입니다.

이 글의 나머지 부분은 Every 내부에서 우리가 복합 엔지니어링을 어떻게 실천하는지에 대해 높은 수준에서 감을 잡을 수 있도록 해줍니다. 다 읽고 나면 기본적인 것들을 바로 시작할 수 있을 것이고—더 깊이 들어갈 준비도 될 것입니다.

복합 엔지니어링 루프

복합 엔지니어는 병렬로 실행되는 에이전트를 오케스트레이션하며, 이들은 코드를 계획하고, 작성하고, 평가합니다. 이 과정은 다음과 같은 루프에서 진행됩니다:

1. Plan: 에이전트가 이슈를 읽고, 접근법을 조사하며, 상세한 구현 계획으로 정보를 종합합니다.
2. Work: 에이전트가 그 계획에 따라 코드를 작성하고 테스트를 만듭니다.
3. Review: 엔지니어는 결과물 자체와 결과물에서 얻은 교훈을 검토합니다.
4. Compound: 엔지니어는 결과를 시스템에 다시 피드백하여, 성공과 실패에서의 학습이 전체 시스템을 도와 다음 루프를 더 좋게 만듭니다. 여기서 마법이 일어납니다.

우리는 복합 엔지니어링에 주로 Anthropic의 Claude Code를 사용하지만, 도구에는 구애받지 않습니다—우리 팀의 일부는 스타트업 Factory의 Droid와 OpenAI의 Codex CLI도 사용합니다. 우리가 이 방식으로 어떻게 하는지 더 손에 잡히게 다루고 싶다면, 내부에서 사용하는 정확한 워크플로우를 여러분도 직접 실행할 수 있도록 만든 Claude Code용 복합 엔지니어링 플러그인을 구축해두었습니다.

대략 복합 엔지니어링의 80퍼센트는 계획과 리뷰 부분에 있고, 20퍼센트는 작업과 컴파운드에 있습니다.

자, 들어가 봅시다.

1. Plan

에이전트가 여러분의 코드를 모두 작성하는 세계에서, 계획이 개발자가 가장 많은 시간을 쓰는 곳입니다. 좋은 계획은 연구에서 시작합니다: 우리는 에이전트에게 현재 코드베이스와 그 커밋 히스토리를 살펴보게 하여 코드베이스의 구조, 기존 모범 사례, 그리고 어떻게 구축되었는지를 이해하게 합니다. 또한 해결하려는 문제와 관련된 모범 사례를 인터넷에서 샅샅이 찾도록 합니다. 이렇게 하면 계획을 시작할 때 에이전트가 좋은 작업을 하도록 준비됩니다.

연구가 완료되면, 에이전트가 계획을 작성합니다. 보통 이는 여러분의 컴퓨터에 파일로 존재하거나 Github의 이슈로 존재하는 텍스트 문서입니다. 계획은 모든 것을 서술합니다: 기능의 목적, 제안된 아키텍처, 코드가 어떻게 작성될지에 대한 구체적 아이디어, 연구 소스 목록, 그리고 성공 기준.

Cora 기능을 위한 계획 문서. (이미지 제공: Kieran Klaassen.)

계획은 구축하기 전에 여러분과 에이전트 사이에 무엇을 정확히 만들고 있는지에 대한 공유된 멘탈 모델을 구축하는 데 도움이 됩니다. 좋은 계획은 순수한 위임이 아닙니다—개발자는 에이전트를 올바른 경로로 밀어줄 수 있도록 깊게 생각하고 창의적으로 접근해야 합니다.

모델이 더 좋아질수록, 특히 작은 프로젝트에서는 계획의 필요성이 점점 줄어듭니다—에이전트가 여러분이 원하는 것을 그냥 이해하거나, 어쩌면 놀랍지만 좋은 일을 해낼지도 모릅니다. 하지만 복잡한 프로덕션 프로젝트에서는, 좋은 계획이 여러분이 기대하는 대로 작동하는 고품질 소프트웨어를 구축하는 데 필수입니다.

좋은 계획이 있으면, 어려운 부분은 거의 끝났습니다.

2. Work

이 단계는 매우 단순하기 때문에 가장 쉽습니다: 에이전트에게 작업을 시작하라고 지시하기만 하면 됩니다. 에이전트는 여러분의 계획을 가져다가 할 일 목록으로 바꾸고 단계별로 빌드합니다.

이 단계에서 가장 중요한 요령 중 하나는 Playwright나 XcodeBuildMCP 같은 모델 컨텍스트 프로토콜(MCP)을 사용하는 것입니다. 이러한 도구는 에이전트가 웹앱을 사용하거나 휴대폰에서의 사용을 빌드 중에 시뮬레이션하도록 허용하여, 마치 여러분의 사용자 중 한 명처럼 행동하게 합니다. 그래서 에이전트는 코드를 조금 작성하고, 앱을 걸어가며 문제를 발견한 다음, 코드를 수정하고 완료될 때까지 반복합니다. 이것은 특히 디자인 작업과 워크플로우에 매우 좋습니다. 디자인처럼 보일 때까지 프로토타입을 반복할 수 있기 때문입니다.

Opus 4.5 같은 최신 세대의 에이전트와 함께라면, 작업 단계에서 나오는 결과물은 훨씬 더 기능적이고 오류가 적을 가능성이 높으며, 계획이 잘 작성되었다면 종종 여러분이 상상했던 것에 꽤 가깝습니다.

하지만 좋은 출력이라도 검증이 필요합니다. 다음 단계에서 그렇게 합니다.

3. Assess

평가 단계에서는, 에이전트가 자신의 작업을 리뷰하도록 요청하고, 우리도 작업을 리뷰합니다. 이는 여러 형태를 취할 수 있습니다: 우리는 린터와 유닛 테스트 같은 전통적인 개발자 도구를 사용하여 기본적인 오류를 찾고, 구축된 것을 정상인지 수동으로 테스트합니다. 또한 Claude, Codex, Friday, Charlie 같은 자동 코드 리뷰 에이전트를 사용하여 흔한 문제에 대해 코드 스팟 체크를 수행합니다.

최신 AI는 평가 단계를 더욱 강력하게 만듭니다. 예를 들어, 우리의 복합 엔지니어링 플러그인은 12개의 서브에이전트가 각각 다른 관점에서 코드를 검사하며 병렬로 코드를 리뷰합니다. 하나는 일반적인 보안 문제를 찾고, 또 다른 하나는 흔한 성능 문제를 점검하며, 또 다른 하나는 소프트웨어가 비대하거나 지나치게 복잡하지 않도록 과도하게 구축된 것이 있는지 살핍니다. 이러한 다양한 관점은 종합되어 개발자에게 무엇을 고쳐야 하고 무엇을 무시할 수 있는지 결정할 수 있도록 제시됩니다.

복합 엔지니어링의 진정한 힘은 다음 단계에서 발휘됩니다—다시는 동일한 문제를 겪지 않도록 만드는 단계입니다.

4. Compound

이것이 핵심 단계입니다. 우리는 이전 어느 단계에서든 배운 것—버그, 잠재적 성능 문제, 특정 문제를 해결하는 새로운 방법—을 기록하여 에이전트가 다음 번에 사용할 수 있게 합니다. 이것이 복합 엔지니어링에서 복리가 일어나게 하는 요소입니다.

예를 들어, Every의 AI 이메일 어시스턴트 **Cora (https://cora.computer/)**의 코드베이스에서는, 새로운 것을 구축하기 전에 에이전트가 스스로에게 물어야 합니다: 이것은 시스템에서 어디에 속하는가? 이미 존재하는 것에 추가되어야 하는가, 아니면 자체적인 새로운 것이 필요한가? 우리가 이전에 유사한 문제를 해결한 적이 있어 재사용할 수 있는가? 이러한 질문에는 과거에 우리가 저질렀던 실수로부터 나온 구체적 기술 사례가 함께 제공되어, 에이전트가 코드베이스의 올바른 장소에서 올바른 해결책을 찾도록 준비시킵니다.

이러한 규칙은 대부분 자동화된 방식으로 축적됩니다. 예를 들어, 우리가 코드 리뷰를 수행한 후에는, 에이전트에게 코멘트를 살펴보고 요약한 다음 나중을 위해 저장하도록 요청합니다. 최신 모델은 아주 적은 추가 지시만으로도 이 모든 것을 충분히 해낼 만큼 똑똑하며—다음 번에 실제로 이를 활용할 만큼도 충분히 똑똑합니다.

아름다운 점은 이러한 학습이 팀 전체에 자동으로 배포된다는 것입니다. 코드베이스 내부나 우리의 플러그인 같은 곳에 프롬프트로 기록되기 때문에, 팀의 모든 개발자가 이를 공짜로 얻게 됩니다. 모두가 더 생산적이 됩니다: 코드베이스에 한 번도 들어온 적 없는 신입도 오래 있던 사람만큼 흔한 실수를 피할 준비가 잘 갖춰지게 됩니다.

복합 엔지니어링: 앞을 내다보며 학습하기

이것은 복합 엔지니어링의 기본적인 개요일 뿐입니다—이 단계들 각각은 자체적으로 하나의 글이 될 수 있고, 종종 그렇습니다. 또한 이 새로운 소프트웨어 생산 방식에 아직 존재하는 몇 가지 제약—즉, 개발자가 무엇을 구축할지 얼마나 빠르게 결정하고, 계획을 처리·개선하며, ‘좋음’이 무엇인지 설명할 수 있는가—에 대해서는 다루지 않았습니다.

우리는 복합 엔지니어링과 그 더 넓은 함의의 가능성을 이제 막 탐구하기 시작했습니다. 수동으로 테스트를 작성하거나 풍부한 문서가 딸린 사람이 읽을 수 있는 코드를 작성하는 일은 이제 불필요합니다. 인터넷에 접근하지 못한 채 엔지니어링 후보자에게 코딩을 요구하는 일도, 신입이 코드를 커밋하기까지 몇 주가 걸릴 것이라 기대하는 일도, 이제는 그렇습니다. 그리고 레거시 코드가 너무 이해하기 어렵고 재플랫폼 비용이 너무 비싸서 특정 플랫폼이나 기술에 갇혀 있는 일도 그렇습니다. 우리는 이 새로운 엔지니어링 방식이 무엇을 여는지에 대해 더 많은 글을 쓰게 되어 기대가 큽니다.

이 주제에 관심이 있으시다면, 우리가 이에 대해 출간한 다른 글들도 읽어보시는 것을 강력히 추천합니다:

• “Stop Coding and Start Planning”
• “Teach Your AI to Think Like a Senior Engineer”
• “My AI Had Already Fixed the Code Before I Saw It”
• “How Every Is Harnessing the World-changing Shift of Opus 4.5”