이 문서는 '컴파운드 엔지니어링'이라는 독특한 소프트웨어 개발 철학과 방법론을 소개합니다. 이 방법론은 각 엔지니어링 작업 단위가 다음 작업을 더 쉽게 만드는 데 기여하도록 하여, 시간이 지남에 따라 코드베이스가 더 이해하기 쉽고, 수정하기 쉽고, 신뢰할 수 있게 되도록 돕습니다. 특히 인공지능(AI) 도구를 적극적으로 활용하여 개발 효율성을 극대화하는 4단계 루프(계획-작업-검토-컴파운드)를 중심으로 설명하며, AI 시대에 개발자가 버려야 할 전통적인 믿음과 채택해야 할 새로운 사고방식, 그리고 다양한 개발 분야에 적용 가능한 구체적인 베스트 프랙티스를 제시합니다.

1. 컴파운드 엔지니어링의 철학 ✨

컴파운드 엔지니어링의 핵심 철학은 모든 엔지니어링 작업 단위가 후속 단위를 더 쉽게 만들어야 한다는 거예요. 보통 코드베이스는 새로운 기능을 추가할수록 복잡성이 증가해서 시간이 지날수록 다루기 어려워지죠. 하지만 컴파운드 엔지니어링은 이 과정을 뒤집어서, 기능 추가가 시스템에 새로운 역량을 가르치고, 버그 수정은 유사한 미래의 버그들을 원천적으로 제거하며, 패턴들은 미래 작업의 도구가 되도록 합니다. 결국 코드베이스가 시간이 지날수록 더 이해하기 쉽고, 수정하기 쉬우며, 신뢰할 수 있게 되는 것을 목표로 해요. 🚀

2. 핵심 4단계 루프: 계획 → 작업 → 검토 → 컴파운드 🔄

Every는 Cora, Monologue, Sparkle, Spiral, 그리고 Every.to와 같은 다섯 가지 제품을 주로 1인 엔지니어링 팀으로 운영하고 있는데요. 이것이 가능한 비결이 바로 계획 → 작업 → 검토 → 컴파운드 → 반복으로 이어지는 4단계 루프입니다. 처음 세 단계는 일반적인 개발자에게 익숙하겠지만, 네 번째 단계인 '컴파운드'가 바로 컴파운드 엔지니어링을 특별하게 만드는 부분이에요. 이 단계에서 얻는 이득이 축적된답니다! 이 단계를 건너뛰면 AI의 도움을 받는 전통적인 엔지니어링이 될 뿐이죠.

이 루프는 5분짜리 버그 수정이든 며칠에 걸친 기능 구축이든 동일하게 적용되며, 각 단계에 소요되는 시간만 다를 뿐이에요. 엔지니어는 계획과 검토에 시간의 80%를, 작업과 컴파운드에 20%를 할애하는 것이 이상적이라고 합니다. 즉, 코드 작성 전후에 대부분의 사고 과정이 일어나는 거죠.

2.1. 1단계: 계획 💡

계획은 아이디어를 청사진으로 바꾸는 과정이에요. 좋은 계획은 더 좋은 결과를 만들어냅니다. 이 단계에서는 다음과 같은 질문들을 스스로에게 던지고 행동해야 해요.

• 요구사항 이해: "무엇을 만들고 왜 만드는가? 어떤 제약 조건이 있는가?"
• 코드베이스 연구: "유사한 기능은 어떻게 작동하는가? 어떤 패턴이 존재하는가?"
• 외부 연구: "프레임워크 문서는 무엇을 말하는가? 확립된 모범 사례는 무엇인가?"
• 솔루션 설계: "어떤 접근 방식을 사용할 것인가? 어떤 파일이 변경되어야 하는가?"
• 계획 검증: "이 계획이 견고하고 완전한가?"

2.2. 2단계: 작업 👷‍♀️

작업은 계획을 실행하는 단계입니다. 개발자가 지켜보는 동안 AI 에이전트가 구현을 진행해요. 이 단계에는 몇 가지 작은 작업들이 포함돼요.

• 격리 설정: Git worktree나 브랜치를 활용하여 작업을 분리해요.
• 계획 실행: 에이전트가 단계별로 계획을 구현해요.
• 유효성 검사 실행: 각 변경 후 테스트, 린팅, 타입 검사를 실행해요.
• 진행 상황 추적: 완료된 작업과 남은 작업을 확인해요.
• 문제 처리: 문제가 발생하면 계획을 수정해요.

"계획을 신뢰한다면, 모든 코드 라인을 지켜볼 필요는 없어요."

2.3. 3단계: 검토 (평가) 🧐

이 단계는 문제가 배포되기 전에 발견하고 해결하는 중요한 역할을 합니다. 더 나아가 다음 주기를 위한 학습 내용을 포착하여 컴파운드 엔지니어링의 기반을 다져요.

• 여러 에이전트가 결과물 검토: 여러 전문 검토자가 코드를 병렬로 검토해요.
• 결과 우선순위 지정: P1(필수 수정), P2(수정 권장), P3(수정하면 좋음)로 우선순위를 매겨요.
• 결과 해결: 에이전트가 검토 피드백에 따라 문제를 수정해요.
• 수정 사항 검증: 수정 사항이 정확하고 완전한지 확인해요.
• 패턴 포착: 재발 방지를 위해 문제가 발생한 패턴을 문서화해요.

2.4. 4단계: 컴파운드 (가장 중요한 단계!) 🌟

전통적인 개발은 3단계에서 끝나지만, 컴파운드 단계에서야 비로소 진정한 이득을 얻을 수 있습니다. 첫 세 단계가 기능을 만드는 것이라면, 네 번째 단계는 매번 더 나은 기능 구축을 가능하게 하는 시스템을 만드는 것입니다. 이 마지막 단계에서는 다음 행동들을 취해야 해요.

• 솔루션 포착: "무엇이 효과 있었고, 무엇이 아니었는가? 재사용 가능한 통찰력은 무엇인가?"를 스스로에게 물어봐요.
• 찾기 쉽게 만들기: 검색을 위해 올바른 메타데이터, 태그, 카테고리로 태그될 수 있도록 YAML frontmatter를 추가해요.
• 시스템 업데이트: 에이전트가 모든 세션 시작 시 읽는 CLAUDE.md 파일에 새로운 패턴을 추가하고, 필요하다면 새로운 에이전트를 생성해요.
• 학습 검증: "시스템이 다음번에도 이 문제를 자동으로 감지할까?"라고 스스로에게 물어봐요.

3. 플러그인과 핵심 명령어 🔌

컴파운드 엔지니어링 워크플로우는 플러그인 형태로 제공되어 설치만 하면 바로 사용할 수 있어요. 이 플러그인에는 26개의 전문 에이전트, 23개의 워크플로우 명령어, 13개의 도메인 전문 지식(스킬)이 포함되어 있습니다.

3.1. 플러그인 구성 요소

• 26가지 전문 에이전트: 각 에이전트는 특정 작업을 위해 훈련되었어요.
• 23가지 워크플로우 명령어: 메인 루프와 유틸리티를 포함해요.
• 13가지 스킬: 에이전트 네이티브 아키텍처 스킬, 스타일 가이드 스킬 등 도메인 전문 지식을 제공해요.

3.2. 중요한 파일들 📁

• CLAUDE.md: 에이전트가 매 세션마다 읽는 가장 중요한 파일이에요. 개발자의 선호 사항, 패턴, 프로젝트 컨텍스트를 여기에 기록하고, 문제가 발생하면 에이전트가 학습할 수 있도록 메모를 추가해요.
• docs/solutions/: 해결된 문제가 검색 가능한 문서가 되어 기관의 지식으로 축적됩니다. 미래 세션에서 과거 솔루션을 자동으로 찾을 수 있어요.
• todos/: 우선순위와 상태를 가진 작업 항목을 추적해요. 검토 단계에서 발견된 문제들을 기반으로 수정할 가치가 있는 것을 결정하고, 해결 명령어를 사용하여 작업을 진행해요.

3.3. 핵심 명령어들 🚀

• /workflows:brainstorm: 무엇을 구축해야 할지 불확실할 때 아이디어를 브레인스토밍하고 계획에 필요한 질문들을 합니다. 경량 리포지토리 연구를 수행하고, 질문을 통해 목적, 사용자, 제약 조건 등을 명확히 한 후, 접근 방식을 제안하고 그 결정은 docs/brainstorms/에 저장돼요.
• /workflows:plan: 원하는 것을 설명하면 구축 계획을 만들어줍니다. 코드베이스 패턴 연구, 프레임워크 문서 연구, 모범 사례 연구를 병렬로 수행하고, 사용자 흐름 및 엣지 케이스를 분석하여 영향을 받는 파일과 구현 단계를 포함한 구조화된 계획을 생성해요. ultrathink 모드를 활성화하면 40개 이상의 병렬 연구 에이전트를 사용하여 계획을 심화시킬 수도 있어요.
• /workflows:work: 에이전트가 실제로 코드를 작성하는 명령어입니다. git worktree를 생성하고(빠른 시작), 각 작업을 구현하며(실행), 품질 검사를 수행하고(품질 확인), 최종적으로 린팅을 실행하고 PR을 생성합니다(출하).
• /workflows:review: PR을 12개 이상의 전문 에이전트가 동시에 검토하도록 합니다. 보안, 성능, 아키텍처, 데이터 무결성, 코드 단순성 등 다양한 측면에서 병렬로 분석하고 우선순위가 지정된 목록을 제공해요.
  • 검토 에이전트: security-sentinel, performance-oracle, architecture-strategist 등 14가지 전문 에이전트들이 각자의 영역에서 코드를 분석하고 우선순위가 지정된 문제점을 보고합니다.
  • 자동 해결: /resolve_pr_parallel 명령어를 사용하면 모든 발견 사항을 자동으로 처리합니다. P1 문제부터 수정하고, 각 수정은 격리된 상태로 실행되며, 최종적으로는 생성된 수정 사항을 수동으로 검토할 수 있어요.
• /triage: 각 발견 사항을 하나씩 제시하여 사람이 직접 결정할 수 있도록 합니다. 승인(할 일 목록에 추가), 건너뛰기(삭제), 사용자 지정(우선순위/세부 정보 수정) 옵션이 있어요.
• /workflows:compound: 해결된 문제를 미래 참고를 위해 문서화하는 명령어입니다. 문제 컨텍스트 분석, 솔루션 추출, 관련 문서 연결, 재발 방지 전략, 카테고리 분류, 문서 작성 등 6개의 병렬 하위 에이전트를 생성하여 검색 가능한 마크다운 문서를 만들어요.
• /lfg: 기능 설명을 입력하면 에이전트가 계획, 구축, 검토, 그리고 병합 준비 완료된 PR까지 모든 것을 처리합니다. 이 명령어 하나로 전체 파이프라인(계획 → 심층 계획 → 작업 → 검토 → 발견 사항 해결 → 브라우저 테스트 → 기능 비디오 → 컴파운드)을 연결하고, 50개 이상의 에이전트를 모든 단계에서 실행해요.

4. 버려야 할 믿음과 채택해야 할 믿음 🤔

AI 도구의 발전과 함께 소프트웨어 개발에 대한 우리의 일부 믿음은 이제 방해가 될 수 있습니다.

4.1. 버려야 할 믿음 🙅‍♀️

• '코드는 손으로 작성되어야 한다': 중요한 것은 유지 보수 가능하고 문제를 해결하는 좋은 코드이며, 누가 작성하느냐는 중요하지 않아요.
• '모든 라인은 수동으로 검토되어야 한다': 자동화된 시스템도 동일한 문제를 잡아낼 수 있습니다. 시스템을 신뢰하지 못한다면, 시스템을 고쳐야 합니다.
• '솔루션은 엔지니어로부터 나와야 한다': AI가 접근 방식을 연구하고, 장단점을 분석하며, 옵션을 추천할 수 있다면, 엔지니어의 역할은 '어떤 솔루션이 적합한지'에 대한 감각을 더하는 것으로 바뀝니다.
• '코드가 주요 산출물이다': 코드를 생산하는 시스템이 개별 코드 조각보다 더 가치 있습니다.
• '코드 작성은 핵심 업무 기능이다': 개발자의 역할은 가치를 제공하는 것이며, 코드는 그저 하나의 투입 요소일 뿐이에요.
• '첫 시도는 좋아야 한다': 우리의 경험상 첫 시도는 95%가 쓰레기입니다. 빠른 반복을 통해 세 번째 시도가 첫 시도보다 적은 시간에 완성되도록 하는 것이 목표가 되어야 해요.
• '코드는 자기 표현이다': 코드는 팀, 제품, 사용자의 것이며, 자기 표현이라는 생각에서 벗어나면 피드백을 더 잘 수용하고 리팩토링에 망설임이 없어집니다.
• '더 많이 타이핑해야 더 많이 배운다': 이제는 이해하는 것이 근육 기억보다 중요합니다. AI 구현을 검토하고, 실수와 AI의 오류를 아는 것이 학습입니다.

4.2. 채택해야 할 믿음 🙏

• 50/50 규칙: 엔지니어링 시간의 50%는 기능 구축에, 50%는 시스템 개선(기관 지식 구축에 도움이 되는 모든 작업)에 할애해야 합니다. 시스템 개선은 미래의 기능을 더 쉽고 빠르게 만듭니다.
• 프로세스를 신뢰하고 안전망 구축: 모든 라인을 수동으로 검토할 필요 없이, 테스트, 자동 검토, 모니터링과 같은 안전망을 구축하여 AI를 신뢰해야 합니다.
• 환경을 에이전트 네이티브로 만들기: 개발자가 할 수 있는 모든 것을 에이전트도 할 수 있도록 환경을 구축해야 합니다. AI에게 기능을 제한하면 그만큼 개발자가 수동으로 처리해야 할 작업이 늘어납니다.
• 병렬화 활용: 인간은 한 번에 하나의 작업만 할 수 있지만, AI 에이전트는 여러 작업을 병렬로 실행할 수 있습니다. 여러 에이전트를 동시에 실행하여 효율성을 극대화하세요.
• 계획이 새로운 코드: 계획 문서는 가장 중요한 산출물이 됩니다. 코드를 먼저 작성하고 나중에 문서화하는 대신, 계획부터 시작하여 에이전트가 코드를 생성, 테스트, 검증하는 데 사용하는 진실의 원천으로 만드세요.

4.3. 핵심 원칙 🌟

이 새로운 소프트웨어 개발 접근 방식의 핵심 원칙들은 다음과 같습니다.

• 모든 작업 단위는 다음 작업을 더 쉽게 만든다.
• 취향은 시스템에 속하며, 검토에 속하지 않는다.
• 시스템을 가르치고, 스스로 모든 작업을 하지 않는다.
• 검토 프로세스가 아닌 안전망을 구축한다.
• 환경을 에이전트 네이티브로 만든다.
• 모든 곳에 컴파운드 사고를 적용한다.
• 포기하는 불편함을 받아들인다.
• 더 많은 가치를 제공하고, 더 적은 코드를 타이핑한다.

5. 시작하기: AI 활용 단계별 로드맵 📈

컴파운드 엔지니어링 루프는 프로세스이지만, AI에 대한 익숙도와 능력에 따라 AI에게 맡길 프로세스의 범위는 달라져요. 개발자들이 자신의 위치를 파악하고 다음 단계로 나아갈 수 있는 5가지 단계가 있습니다.

5.1. 단계 0: 수동 개발 ✍️

AI 없이 코드 라인을 직접 작성하고, 문서를 통해 조사하며, print문으로 디버깅하는 단계입니다. 2025년에는 충분히 빠르지 않아요.

5.2. 단계 1: 채팅 기반 지원 💬

AI를 스마트 참조 도구로 사용하며, ChatGPT, Claude, Cursor 등에 질문하고 코드 스니펫을 복사-붙여넣기 하는 단계입니다. AI는 연구 및 상용구 생성을 가속화하지만, 여전히 모든 라인을 검토하며 전적으로 제어합니다.

5.3. 단계 2: 에이전트 도구와 라인별 검토 🤖

파일을 읽고 직접 변경할 수 있는 Claude Code, Cursor Composer, Copilot Chat과 같은 에이전트 도구를 사용하는 단계입니다. AI가 파일에 접근하고 변경할 수 있도록 허용하지만, 개발자는 모든 제안을 승인하거나 거부하는 게이트키퍼 역할을 합니다. 대부분의 개발자가 이 단계에서 정체되어 AI에게 더 많은 것을 맡기는 이점을 누리지 못해요.

5.4. 단계 3: 계획 우선, PR만 검토 📝

이 단계부터 모든 것이 바뀝니다. 개발자와 AI가 요구사항, 접근 방식, 엣지 케이스를 포함한 상세한 계획을 공동으로 수립합니다. 그 후 개발자는 감독 없이 AI가 계획을 구현하도록 하고, 결과물인 PR을 검토합니다. 비로소 코드 라인 수준의 개입에서 벗어나 PR 검토에서 문제를 파악할 수 있게 되죠. 컴파운드 엔지니어링이 시작되는 단계입니다.

5.5. 단계 4: 아이디어에서 PR까지 (단일 머신) 🚀

개발자가 아이디어를 제공하면 에이전트가 코드베이스 연구, 계획, 구현, 테스트 실행, 자체 검토, 문제 해결, PR 생성 등 모든 것을 처리합니다. 개발자의 개입은 아이디어 구상, PR 검토, 병합의 세 단계로 줄어듭니다. 하지만 여전히 자신의 컴퓨터에서 한 번에 하나의 작업을 실행하는 단계입니다.

5.6. 단계 5: 병렬 클라우드 실행 (다중 기기) ☁️

최종 단계로, 실행을 클라우드로 옮겨 여러 작업을 병렬로 실행합니다. 세 가지 기능을 동시에 시작하고, 세 가지 에이전트가 독립적으로 작업하며, 개발자는 PR이 완료되면 검토합니다. 더 나아가 에이전트가 요청 없이 피드백을 모니터링하고 수정 사항을 제안하도록 할 수도 있습니다. 이제 개인 기여자가 아닌 '함대를 지휘하는' 사령관이 되는 거죠.

6. AI 산출물 승인 전 세 가지 질문 🤔

고급 다중 에이전트 검토 시스템이 없더라도, AI 산출물을 승인하기 전에 다음 세 가지 질문을 던져보면 많은 이점을 얻을 수 있습니다.

1. "여기서 가장 어려웠던 결정은 무엇이었나요?"
   • AI가 어려운 부분과 판단이 필요했던 지점을 드러내도록 합니다.
2. "어떤 대안들을 거부했고, 그 이유는 무엇인가요?"
   • AI가 고려했던 옵션들을 보여주어 잘못된 선택을 했는지 파악하는 데 도움이 됩니다.
3. "무엇에 대해 가장 확신이 없나요?"
   • AI가 자신의 약점을 인정하도록 합니다. LLM은 자신의 약점을 알고 있지만, 물어봐야 답해줍니다.

7. 모범 사례 🌟

7.1. 에이전트 네이티브 아키텍처 🏗️

에이전트 네이티브 아키텍처는 에이전트에게 개발자가 가진 것과 동일한 기능을 부여하는 것을 의미합니다. 에이전트가 테스트를 실행할 수 없으면 개발자가 직접 해야 하고, 로그를 볼 수 없으면 직접 디버깅해야 합니다. AI에게 부여하지 않는 모든 기능은 개발자가 수동으로 처리해야 할 작업이 됩니다.

7.1.1. 에이전트 네이티브 체크리스트 ✅

에이전트가 다음을 수행할 수 있는지 확인해보세요.

• 개발 환경: 로컬에서 애플리케이션 실행, 테스트 스위트 실행, 린터 및 타입 체커 실행, 데이터베이스 마이그레이션 실행, 개발 데이터 시딩.
• Git 작업: 브랜치 생성, 커밋, 원격 저장소 푸시, PR 생성, PR 댓글 읽기.
• 디버깅: 로컬 로그 보기, 프로덕션 로그(읽기 전용) 보기, UI 스크린샷 찍기, 네트워크 요청 검사, 오류 추적(Sentry 등) 접근.

7.1.2. 점진적 에이전트 네이티브 🚀

처음부터 100% 에이전트 네이티브일 필요는 없어요. 점진적으로 에이전트에 접근 권한을 부여하세요.

• 레벨 1: 기본 개발: 파일 접근, 테스트 실행, Git 커밋.
• 레벨 2: 완전한 로컬: 브라우저 접근, 로컬 로그, PR 생성 능력.
• 레벨 3: 프로덕션 가시성: 프로덕션 로그(읽기 전용), 오류 추적, 모니터링 대시보드 접근.
• 레벨 4: 완전 통합: 티켓 시스템 접근, 배포 기능, 외부 서비스 통합.

7.2. 권한 건너뛰기 🛑

--dangerously-skip-permissions 플래그는 Claude Code가 파일 생성과 같은 모든 작업 전에 요청하는 권한 프롬프트를 비활성화합니다. 이 이름은 의도적으로 무서워서 사용 전에 생각하게 만들지만, 컴파운드 엔지니어링의 3단계 이상에서는 지속적인 권한 요청이 흐름을 방해할 거예요.

7.2.1. 사용 시기 🟢

• 프로세스를 신뢰할 때: 좋은 계획과 좋은 검토 시스템이 있을 때.
• 안전한 환경에서: 실제 사용자나 라이브 제품에 영향을 주지 않는 샌드박스에서 작업할 때.
• 속도를 원할 때: 권한 요청이 워크플로우를 늦출 때.

7.2.2. 사용하지 않을 시기 🔴

• 학습 중일 때: 권한 요청이 무엇이 일어나고 있는지 이해하는 데 도움이 될 때.
• 프로덕션 환경에서: 실제 사용자에게 영향을 미치므로 프로덕션 코드 작업 시에는 절대 사용하지 마세요.
• 롤백이 어려울 때: 실수 복구가 쉽지 않을 때는 프롬프트를 유지하세요.

7.2.3. 안전을 위한 조치들 🛡️

• Git: 에이전트가 하는 모든 작업은 Git에 기록되므로 쉽게 되돌릴 수 있어요.
• 테스트: 병합 전에 테스트를 실행하여 에이전트가 문제를 일으켰는지 확인해요.
• 병합 전 검토: 권한 건너뛰기는 구현 프롬프트를 건너뛸 뿐, 최종 PR 검토는 필수입니다.
• 워크트리: 위험한 작업에는 git worktree를 사용하여 위험을 격리해요.

7.3. 디자인 워크플로우 🎨

디자인은 목업보다 코드에서 반복하는 것이 더 쉽습니다. 하지만 프로덕션 코드베이스에서 실험하고 싶지는 않죠.

7.3.1. 베이비 앱 접근 방식 👶

임시 프로젝트인 "베이비 앱"을 만들어서 테스트나 아키텍처, 기존 코드 파손 걱정 없이 자유롭게 디자인을 반복하세요. 디자인이 만족스러우면 패턴을 추출하여 실제 프로젝트에 적용합니다.

7.3.2. UX 발견 루프 🔎

무엇을 구축해야 할지 모를 때, 여러 버전의 프로토타입을 생성하고 사용자 피드백을 수집하여 학습합니다. 프로토타입은 학습용이며, 배포용이 아님을 기억하세요.

7.3.3. 디자이너와의 협업 🤝

컴파운드 엔지니어링에서는 디자이너가 Figma 목업을 만들면, AI가 이를 정확히 구현하고 figma-design-sync 에이전트가 구현이 목업과 일치하는지 확인합니다. 디자이너는 라이브 버전을 검토하며 완벽해질 때까지 반복합니다.

7.3.4. 디자인 취향 코드화 💅

디자이너와 몇 가지 기능을 작업한 후 선호하는 색상, 간격, 타이포그래피 등의 패턴을 skill 파일에 기록하세요. 이를 통해 AI는 디자이너의 개입 없이도 디자이너의 취향에 맞는 디자인을 생성할 수 있습니다.

7.4. 바이브 코딩 🧘‍♀️

바이브 코딩은 코드 자체에는 관심이 없고 결과만 원하는 사람들을 위한 방식입니다. 제품 관리자가 아이디어를 프로토타이핑하거나, 디자이너가 인터랙션 감각을 테스트하거나, 개인 프로젝트를 구축하는 경우에 적합해요. 목표는 코드가 작동하는지 확인하는 것입니다.

7.4.1. 바이브 코더의 철학 💫

AI에게 원하는 것을 설명하고 에이전트가 구축하게 하는 4단계로 바로 넘어가는 방식입니다. 코드 품질, 아키텍처, 테스트, 모범 사례에 신경 쓸 필요가 없어요.

7.4.2. 사용 시기 🕰️

• 완벽: 개인 프로젝트, 프로토타입, 실험, 내부 도구, UX 탐색.
• 적합하지 않음: 사용자 기반 프로덕션 시스템, 다른 사람이 유지 보수할 코드, 보안에 민감한 앱, 성능이 중요한 시스템.

7.4.3. 바이브 코딩 역설 🧩

바이브 코딩은 계획을 더 좋게 만들 수도 있어요. 무엇을 원하는지 모를 때 프로토타입을 만들고 피드백을 수집한 다음, 모든 것을 삭제하고 제대로 된 계획으로 다시 시작할 수 있습니다. 바이브 코딩은 발견을 가속화하고, 최종 구현은 상세한 스펙이 담당합니다.

7.5. 팀 협업 🤝

AI가 구현을 처리하면 팀 역학이 변화합니다. 누가 계획을 승인하고, 누가 PR을 소유하며, 에이전트가 1차 검토를 마친 후 인간이 무엇을 검토해야 하는지에 대한 새로운 합의가 필요해요.

7.5.1. 새로운 팀 역학 🔄

• 전통적: 개발자 A가 코드를 작성 → 개발자 B가 검토 → PR 댓글에서 논의 → 승인 후 병합.
• 컴파운드: 개발자 A가 계획을 생성 → AI가 구현 → AI 에이전트가 검토 → 개발자 B가 AI 검토를 다시 검토 → 인간 승인 후 병합.

7.5.2. 팀 표준 📏

• 계획 승인: 구현 전에 명시적인 승인이 필요합니다.
• PR 소유권: 작업을 시작한 사람이 PR을 소유하며, 계획의 품질, 작업 검토, 문제 해결, 병합 후 영향에 대한 책임이 있어요.
• 인간 검토의 초점: AI 검토 에이전트가 이미 PR을 분석했다면, 인간 검토자는 구현이 아닌 '의도'에 집중해야 합니다. 비즈니스 로직 문제 등을 확인하고, 구문 오류, 보안 취약점 등은 AI에게 맡기세요.

7.5.3. 소통 패턴 🗣️

• 기본적으로 비동기: 계획 생성, 검토, 승인이 회의 없이 비동기적으로 이루어질 수 있습니다.
• 명시적인 인계: 작업을 인계할 때는 상태, 완료된 작업, 남은 작업, 컨텍스트, 계속하는 방법 등 필요한 모든 것을 포함해야 합니다.

7.6. 사용자 연구 🧑‍💻

AI가 사용할 수 있도록 연구를 구조화해야 합니다. 페르소나 문서를 만들고, 통찰력을 기능과 연결하며, 연구와 구현 간의 루프를 닫으세요.

7.6.1. 연구-개발 격차 🌉

• 전통적: 연구자가 인터뷰 → 보고서 작성 → 보고서가 Google Drive에 방치 → 개발자가 기능 구축 → 개발자는 보고서를 읽지 않음 → 기능이 사용자 요구에 맞지 않음.
• 컴파운드: 연구가 구조화된 통찰력 생성 → 통찰력이 계획 컨텍스트가 됨 → AI가 계획 시 통찰력 참조 → 연구 기반 기능 구축 → 사용 데이터가 통찰력 검증 → 통찰력이 축적됨.

7.6.2. 연구 구조화 📑

AI가 사용하기 어렵게 작성된 원시 인터뷰 노트 대신, 주요 통찰력, 인용, 시사점, 확신도 등을 포함하여 구조화하세요.

7.6.3. 페르소나 문서 구축 🎭

AI가 참조할 수 있는 페르소나 문서를 생성하여 목표, 불만, 인용 등을 포함시킵니다.

7.6.4. 연구 기반 계획 🗺️

계획 수립 시 관련 연구 컨텍스트를 제공하여, AI가 사용자 요구에 맞는 기능을 설계하도록 유도합니다.

7.7. 사용자 행동 분석 📊

사용자들은 제품을 어떻게 사용하는지를 통해 무엇을 만들어야 할지 이미 알려주고 있습니다.

7.7.1. 찾아야 할 패턴 유형 📈

• 과도한 사용 패턴: 예상보다 훨씬 많이 사용되거나 반복적으로 방문하는 페이지.
• 어려움 패턴: 간단한 페이지에서 높은 체류 시간, 동일한 작업을 반복 시도, 오류 → 재시도 → 오류 루프.
• 해결책 패턴: 사용자가 제품이 필요로 하는 것을 제공하지 않아 스스로 해결책을 만드는 경우 (예: 데이터 복사-붙여넣기, 여러 탭 사용).
• 포기 패턴: 사용자 흐름에서 이탈하거나 시작했지만 완료되지 않은 기능.

7.7.2. 패턴에서 기능으로 💡

사용자 패턴에서 얻은 통찰력을 기반으로 실제 제품 기능을 만들어야 합니다. 예를 들어, 사용자가 데이터를 수십 번 복사-붙여넣기 하는 것을 발견했다면, 테이블 간의 자동화 기능이 필요하다는 통찰력을 얻어 "테이블 B와 동기화" 버튼을 만들 수 있어요.

7.8. 카피라이팅 📝

대부분의 팀은 카피를 기능 구축 후 채우는 부수적인 것으로 여기지만, 카피는 사용자 경험의 일부이며 코드와 동일한 주의를 기울여야 합니다.

7.8.1. 계획에 카피 포함 ✍️

처음부터 계획에 사용자에게 보여질 문구를 포함하고, AI가 따를 수 있도록 브랜드 보이스를 코드화하며, 다른 결과물처럼 검토해야 합니다.

7.8.2. 브랜드 보이스 코드화 🗣️

skill 파일을 생성하여 브랜드 보이스의 원칙, 피해야 할 단어, 좋은 예시 등을 정의하면 AI가 디자이너의 취향에 맞는 카피를 생성할 수 있습니다.

7.8.3. 코드처럼 카피 검토 🧐

/workflows:review 프로세스에 카피 검토를 추가하세요. copy-reviewer 에이전트는 명확성, 유용성, 톤, 일관성 등을 검토합니다.

7.9. 제품 마케팅 📢

무언가를 출시했다면 이제 세상에 알릴 시간입니다. 기능을 구축하는 데 사용된 동일한 시스템으로 이를 발표할 수 있어요.

7.9.1. 컴파운드 흐름 🔄

엔지니어가 제품 가치 제안을 포함한 계획을 생성 → AI가 기능 구현 → AI가 계획에서 릴리스 노트를 생성 → AI가 릴리스 노트에서 소셜 미디어 게시물을 생성 → AI가 Playwright를 사용하여 스크린샷 자동 생성 → 엔지니어가 모든 것을 검토하고 출시. 이 모든 것이 한 곳에서 이루어지므로 정보 누락이 없습니다.

7.9.2. 릴리스 노트 생성 📝

기능 구현 후 계획과 구현을 기반으로 릴리스 노트를 작성하도록 AI에게 요청할 수 있습니다. 사용자 이점, 구체적인 예시, 변경 사항 등을 포함하여 간결하게 작성되도록 지시합니다.

7.9.3. 변경 로그 생성 📜

여러 기능에 대해서는 /changelog 명령어를 사용하여 main 브랜치에 최근 병합된 내용을 바탕으로 계획/PR을 읽고 매력적인 변경 로그를 생성할 수 있어요.

7.9.4. 자동화된 스크린샷 📸

Playwright를 사용하여 마케팅을 위한 스크린샷을 자동으로 캡처할 수 있습니다. 더 이상 엔지니어에게 스크린샷을 요청하거나 오래된 스크린샷을 사용할 필요가 없어요.

결론 🌟

컴파운드 엔지니어링은 단순히 AI 도구를 활용하는 것을 넘어, 소프트웨어 개발에 대한 근본적인 사고방식의 전환을 요구합니다. AI가 반복적이고 예측 가능한 작업을 처리하도록 맡기고, 개발자는 계획 수립, 시스템 개선, 그리고 AI가 생산하는 결과물의 품질을 보장하는 데 집중함으로써 훨씬 더 큰 가치를 창출할 수 있습니다. 처음에는 불편하고 익숙하지 않을 수 있지만, 이러한 새로운 믿음과 모범 사례를 채택하고, 점진적인 AI 활용 단계를 밟아 나간다면, 개발팀은 시간이 지남에 따라 더욱 효율적이고 강력해지는 시스템을 구축할 수 있을 거예요. 결국 이 모든 노력은 "더 적은 코드를 타이핑하고, 더 많은 가치를 제공하는 것"이라는 목표를 향합니다. 🚀