Compound Engineering : AI 네이티브 엔지니어링 철학

• 모든 엔지니어링 작업 단위가 이후 작업을 더 쉽게 만드는 복리형 소프트웨어 개발 방법론으로, AI 에이전트와의 협업을 체계화한 4단계 루프(계획→실행→리뷰→복리화) 를 핵심으로 구성
• 반복 루프에서 엔지니어의 시간 중 80%는 계획과 리뷰, 20%는 실행과 복리화에 배분해야 함
• 26개 전문 에이전트, 23개 워크플로우 커맨드, 13개 스킬을 포함한 플러그인 형태로 배포되며, Claude Code·OpenCode·Codex에 설치 가능
• 기존 소프트웨어 개발의 8가지 통념(코드는 손으로 작성해야 한다, 모든 라인을 수동 리뷰해야 한다 등)을 버려야 할 믿음으로 제시하고, 시스템에 취향을 인코딩하는 새로운 원칙을 채택해야 함
• 개발자의 AI 도입 수준을 0단계(수동 개발)부터 5단계(병렬 클라우드 실행) 까지 구분하고, 각 단계별 레벨업 방법과 팀 협업·디자인·리서치·마케팅까지 확장한 포괄적 프레임워크

---

핵심 철학

• 각 엔지니어링 작업 단위가 이후 작업을 더 쉽게 만들어야 한다는 것이 핵심 원칙
• 전통적인 코드베이스는 기능 추가 시마다 복잡성이 증가하여, 10년 후에는 시스템과 싸우는 데 더 많은 시간을 소비
• Compound Engineering에서는 기능이 시스템에 새로운 역량을 학습시키고, 버그 수정이 미래 버그 범주 전체를 제거하며, 패턴이 도구로 전환되어 코드베이스가 시간이 지날수록 이해·수정·신뢰하기 쉬워짐

메인 루프: Plan → Work → Review → Compound

• Every 팀은 5개 제품(Cora, Monologue, Sparkle, Spiral, Every.to)을 주로 1인 엔지니어링 팀으로 운영하며, 이를 가능하게 하는 것이 4단계 루프
• 처음 3단계(계획, 실행, 리뷰)는 일반적이나, 4단계 Compound가 복리적 이익이 축적되는 핵심 차별점
• 5분짜리 버그 수정이든 며칠짜리 기능 개발이든 동일한 루프를 사용하되, 각 단계에 투입하는 시간만 조절

• 1단계: Plan (계획)

  • 요구사항 이해: 무엇을 만들고, 왜 만들며, 어떤 제약이 있는지 파악
  • 코드베이스 조사: 유사 기능의 작동 방식과 기존 패턴 분석
  • 외부 조사: 프레임워크 문서, 업계 베스트 프랙티스 확인
  • 솔루션 설계: 접근 방식과 변경 대상 파일 결정
  • 계획 검증: 전체 계획의 완결성과 정합성 확인

• 2단계: Work (실행)

  • 격리 환경 설정: Git worktree(저장소의 격리된 복사본) 또는 브랜치로 작업 분리
  • 계획 실행: 에이전트가 단계별로 구현
  • 검증 실행: 변경 후마다 테스트, 린팅(자동 코드 검사), 타입 체크 수행
  • 진행 상황 추적 및 이슈 발생 시 계획 수정
  • 계획을 신뢰한다면 코드 한 줄 한 줄을 감시할 필요 없음

• 3단계: Review (리뷰)

  • 여러 에이전트가 병렬로 코드 검토 수행
  • 발견 사항을 P1(필수 수정), P2(권장 수정), P3(개선 사항) 으로 우선순위 분류
  • 에이전트가 리뷰 피드백 기반으로 이슈 수정, 수정 결과를 검증
  • 패턴 기록: 무엇이 잘못되었는지 문서화하여 재발 방지

• 4단계: Compound (복리화) — 가장 중요한 단계

  • 전통적 개발은 3단계에서 종료되지만, Compound 단계에서 시스템 개선이 축적
  • 처음 3단계가 기능을 생산한다면, 4단계는 기능을 더 잘 만드는 시스템을 생산
  • 수행 작업:
    • 무엇이 효과적이었고 무엇이 아니었는지, 재사용 가능한 통찰은 무엇인지 포착
    • YAML frontmatter로 메타데이터, 태그, 카테고리를 추가하여 검색 가능하게 설정
    • 새로운 패턴을 CLAUDE.md에 추가하고, 필요 시 새 에이전트 생성
    • "다음에 시스템이 이 문제를 자동으로 잡을 수 있는가?" 검증

플러그인 구성

• 26개 전문 에이전트: 리뷰(14개), 리서치, 디자인, 워크플로우, 문서화 등 각각 특정 업무에 특화
• 23개 워크플로우 커맨드: 메인 루프 + 유틸리티
• 13개 스킬: 에이전트 네이티브 아키텍처, 스타일 가이드 등 도메인 전문성 제공
• Claude Code, OpenCode(실험적), Codex(실험적)에 제로 설정으로 설치 가능

• 파일 구조

  • CLAUDE.md: 에이전트가 매 세션 시작 시 읽는 가장 중요한 파일로, 선호사항·패턴·프로젝트 컨텍스트 저장
  • docs/solutions/: 해결된 문제가 검색 가능한 문서로 축적되어 제도적 지식(institutional knowledge) 구축
  • docs/brainstorms/: brainstorm 커맨드 출력 저장
  • docs/plans/: plan 커맨드 출력 저장
  • todos/: 우선순위와 상태별로 작업 항목 추적

핵심 커맨드

• /workflows:brainstorm

  • 무엇을 만들지 불분명할 때 사용하는 커맨드
  • 경량 레포 리서치 후, 목적·사용자·제약·엣지 케이스를 하나씩 질문하며 명확화
  • AI가 접근 방식을 제안하고, 결과는 docs/brainstorms/에 저장되어 /workflows:plan으로 핸드오프

• /workflows:plan

  • 원하는 것을 설명하면 구현 계획을 반환
  • 3개의 병렬 리서치 에이전트 실행: repo-research-analyst(코드베이스 패턴), framework-docs-researcher(문서), best-practices-researcher(업계 표준)
  • spec-flow-analyzer 에이전트가 사용자 플로우와 엣지 케이스 분석
  • ultrathink 모드 활성화 시 /deepen-plan이 자동 실행되어 40개 이상의 병렬 리서치 에이전트 가동

• /workflows:work

  • 에이전트가 실제 코드를 작성하는 단계
  • 4개 페이즈: quick start(Git worktree 생성 및 브랜치 설정) → execute(진행 추적과 함께 태스크별 구현) → quality check(선택적으로 5개 이상의 리뷰어 에이전트 가동) → ship it(린팅 실행, PR 생성)

• /workflows:review

  • PR을 14개 이상의 전문 에이전트가 병렬로 동시 리뷰
  • 보안(security-sentinel), 성능(performance-oracle), 아키텍처(architecture-strategist), 데이터 무결성(data-integrity-guardian), 코드 품질(code-simplicity-reviewer), 프레임워크별 리뷰어(DHH-rails, Kieran-rails/python/typescript), 배포 검증, 프론트엔드 레이스 컨디션, 에이전트 네이티브 리뷰어 등 포함
  • 출력은 P1(크리티컬), P2(중요), P3(마이너)로 분류된 단일 우선순위 리스트
  • /resolve_pr_parallel 커맨드로 발견 사항을 자동 수정(P1 우선, 각 수정은 격리 실행)
  • /triage 커맨드로 발견 사항을 하나씩 승인/건너뛰기/커스터마이즈하여 필터링 가능

• /workflows:compound

  • 해결된 문제를 미래 참조용으로 문서화
  • 6개 병렬 서브에이전트 가동: context analyzer, solution extractor, related docs finder, prevention strategist, category classifier, documentation writer
  • YAML frontmatter가 포함된 검색 가능한 마크다운 생성

• /lfg

  • 기능을 설명하면 에이전트가 계획·구현·리뷰까지 모두 수행하여 머지 가능한 PR을 제출
  • plan → deepen-plan → work → review → resolve findings → browser tests → feature video → compound의 전체 파이프라인을 체이닝
  • 계획 승인 시 일시 정지 후 자율적으로 실행, 전 단계에 걸쳐 50개 이상의 에이전트 가동

버려야 할 8가지 믿음

• "코드는 손으로 작성해야 한다"

  • 유지보수 가능하고 올바른 문제를 해결하는 좋은 코드를 작성하는 것이 실제 요구사항이며, 누가 타이핑하는지는 중요하지 않음

• "모든 라인을 수동 리뷰해야 한다"

  • 수동 라인별 리뷰는 품질 보장의 한 가지 방법일 뿐, 동일한 이슈를 잡는 자동화 시스템도 유효
  • 결과를 신뢰하지 못하면 직접 하는 것으로 보상하지 말고, 시스템을 수정해야 함

• "솔루션은 엔지니어에게서 나와야 한다"

  • AI가 접근 방식 조사, 트레이드오프 분석, 옵션 추천을 할 수 있으므로, 엔지니어의 역할은 취향(taste) 추가 — 이 코드베이스, 이 팀, 이 맥락에 어떤 솔루션이 맞는지 판단

• "코드가 주요 산출물이다"

  • 코드를 생산하는 시스템이 개별 코드보다 더 가치 있음
  • 하나의 뛰어난 구현보다 일관되게 좋은 구현을 생산하는 프로세스가 중요

• "코드 작성이 핵심 업무다"

  • 개발자의 업무는 가치를 전달(ship value)하는 것이며, 코드는 그 중 하나의 입력
  • 계획, 리뷰, 시스템 교육 모두 업무에 해당

• "첫 시도가 좋아야 한다"

  • 첫 시도의 불량률은 95%, 두 번째도 50%
  • 이는 실패가 아닌 프로세스이며, 세 번째 시도가 첫 시도보다 빠르게 완성되도록 빠른 반복에 집중해야 함

• "코드는 자기 표현이다"

  • 코드는 팀, 제품, 사용자에게 속하며, 코드를 자기 표현으로 보지 않으면 피드백 수용, 리팩터링, 품질 논쟁이 수월해짐

• "더 많이 타이핑해야 더 많이 배운다"

  • 오늘날은 근육 기억보다 이해가 중요
  • AI 구현 10개를 리뷰하는 개발자가 직접 2개를 타이핑한 개발자보다 더 많은 패턴을 이해

전환 과정의 심리적 도전

• 타이핑이 줄면 일을 덜 하는 느낌: 실제로는 에이전트 지시가 구현보다 더 많은 사고를 요구
• 자율 실행의 불안감: 통제권을 포기하는 것이 아니라 제약·규칙·리뷰 프로세스에 통제를 인코딩하는 것
• "이거 내가 만든 건가?"라는 의문: 계획, 리뷰, 품질 기준 확보가 바로 그 작업이며, AI는 작성만 수행

채택해야 할 믿음

• 시스템에 취향을 추출할 것

  • 네이밍 규칙, 에러 처리 패턴, 테스트 접근 방식 등 개발자의 취향은 보통 문서화되지 않고 시니어 엔지니어 머릿속에 존재
  • CLAUDE.md 또는 AGENTS.md에 이런 선호를 기록하고, 리뷰·테스트·배포용 전문 에이전트와 스킬을 구축하여 AI가 승인할 만한 코드를 직접 생산하도록 해야 함

• 50/50 규칙

  • 엔지니어링 시간의 50%는 기능 개발, 50%는 시스템 개선에 배분
  • 전통적으로 90% 기능/10% 기타인데, 리뷰 에이전트 생성, 패턴 문서화, 테스트 생성기 구축 등이 미래 기능을 더 쉽게 만드는 투자
  • 리뷰 에이전트 1시간 투자가 1년간 10시간의 리뷰 시간 절약

• 프로세스를 신뢰하고 안전망을 구축할 것

  • AI 보조가 확장되려면 모든 라인을 인간이 리뷰할 수 없으므로, 테스트, 자동 리뷰, 모니터링 같은 가드레일 구축이 핵심
  • 산출물을 신뢰하지 못하면 수동 리뷰로 전환하지 말고 해당 단계를 신뢰할 수 있게 만드는 시스템을 추가

• 환경을 에이전트 네이티브로 구성할 것

  • 개발자가 볼 수 있거나 할 수 있는 것을 에이전트도 할 수 있어야 함: 테스트 실행, 프로덕션 로그 확인, 스크린샷 디버깅, PR 생성 등
  • 에이전트에게 허용하지 않는 모든 작업은 직접 수동으로 수행해야 함

• 병렬화 활용

  • 과거의 병목은 인간의 주의력(한 번에 한 태스크)이었으나, 새로운 병목은 컴퓨트(동시에 실행 가능한 에이전트 수)
  • 여러 에이전트, 여러 기능을 동시에 실행하고, 리뷰·테스트·문서화를 병렬 수행

• 계획이 새로운 코드

  • 계획 문서가 이제 가장 중요한 산출물
  • 코드 먼저 작성하고 나중에 문서화하는 대신, 계획을 먼저 작성하면 에이전트가 코드를 생성·테스트·검증하는 소스 오브 트루스로 활용
  • 아이디어를 종이 위에서 수정하는 것이 코드에서 수정하는 것보다 저렴

• 핵심 원칙 요약

  • 모든 작업 단위가 후속 작업을 쉽게 만들 것
  • 취향은 리뷰가 아닌 시스템에 내장할 것
  • 직접 작업하지 말고 시스템을 가르칠 것
  • 리뷰 프로세스가 아닌 안전망을 구축할 것
  • 환경을 에이전트 네이티브로 구조화할 것
  • 복리적 사고를 모든 곳에 적용할 것
  • 위임의 불편함을 수용하고, 완벽하지만 확장 불가한 결과보다 불완전하지만 확장 가능한 결과 선택
  • 더 적은 코드를 작성하고 더 많은 가치를 전달할 것
  • 이 원칙들은 엔지니어링을 넘어 디자인, 리서치, 글쓰기 등 취향과 맥락의 코드화가 도움 되는 모든 분야에 확장 가능

개발자 성장 단계 (5단계 래더)

• Stage 0: 수동 개발

  • AI 없이 코드를 한 줄씩 작성, 문서와 Stack Overflow로 조사, print 문으로 디버깅
  • 수십 년간 좋은 소프트웨어를 만들어왔지만 2025년에는 충분히 빠르지 않음

• Stage 1: 채팅 기반 어시스턴스

  • ChatGPT, Claude, Cursor 등에 질문하여 코드 스니펫을 받고 유용한 것을 복사·붙여넣기
  • AI가 리서치와 보일러플레이트 생성을 가속하지만 모든 라인을 직접 리뷰하며 완전한 통제 유지

• Stage 2: 에이전틱 도구 + 라인별 리뷰

  • Claude Code, Cursor Composer, Copilot Chat 등 에이전틱 도구가 파일을 읽고 코드베이스에 직접 변경
  • 에이전트가 제안하는 모든 것을 승인/거절하는 게이트키퍼 역할
  • 대부분의 개발자가 이 단계에서 정체하여 AI 위임의 이점을 누리지 못함

• Stage 3: 계획 우선, PR 수준 리뷰

  • 모든 것이 변하는 단계: 요구사항·접근 방식·엣지 케이스를 포함한 상세 계획을 AI와 공동 작성
  • 계획 수립 후 AI가 감독 없이 구현, 출력물은 PR로 리뷰
  • Compound Engineering이 여기서 시작 — 매 사이클의 계획·구현·리뷰가 시스템을 학습시켜 다음 사이클을 더 빠르고 쉽게 만듦

• Stage 4: 아이디어 → PR (단일 머신)

  • 아이디어를 제공하면 에이전트가 코드베이스 리서치, 계획, 구현, 테스트, 자체 리뷰, 이슈 해결, PR 생성까지 모두 처리
  • 참여가 아이디어 제시, PR 리뷰, 머지 3단계로 축소
  • 아직 한 컴퓨터에서 한 번에 하나만 실행

• Stage 5: 병렬 클라우드 실행 (다중 디바이스)

  • 실행을 클라우드로 이전하여 병렬 실행
  • 3개 기능에 3개 에이전트를 동시 투입, PR이 완료되면 리뷰
  • 에이전트가 피드백을 모니터링하고 자발적으로 수정 제안까지 가능
  • 개별 기여자가 아닌 에이전트 함대를 지휘하는 역할

레벨업 가이드

• 0 → 1: 협업 시작

  • 도구 하나를 선택(Cursor with Opus 4.5 또는 Claude Code 등)하고 매일 사용
  • 코드 작성 전 AI에게 기존 코드 설명을 요청하여 이해도 확인
  • 테스트, 설정 파일, 반복 함수 등 보일러플레이트부터 위임
  • 모든 라인을 리뷰하여 학습
  • 복리화 작업: 잘 작동한 프롬프트를 지속적으로 기록

• 1 → 2: 에이전트 접근 허용

  • 에이전틱 모드로 전환하여 에이전트에 파일 시스템 접근 권한 부여
  • "이 함수에 테스트 추가" 같은 단일 파일·단일 목적의 좁은 변경부터 시작
  • 각 액션을 승인/거절하며 신뢰 직관 구축
  • diff를 리뷰하여 변경된 부분에 집중
  • 복리화 작업: CLAUDE.md 파일 생성, 에이전트 실수 시 메모 추가

• 2 → 3: 계획을 신뢰 (핵심 전환)

  • 요구사항, 접근 방식, 엣지 케이스를 명시적인 계획으로 작성
  • AI에게 코드베이스를 읽고 패턴을 찾아 접근 방식을 제안하도록 허용
  • 계획 작성 후 에이전트에게 구현을 맡기고 완료될 때까지 자리를 비움
  • 개별 단계나 코드 라인이 아닌 PR 수준에서 리뷰
  • 복리화 작업: 매 구현 후 계획이 놓친 부분을 문서화

• 3 → 4: 지시가 아닌 결과를 제시

  • "새 댓글에 이메일 알림 추가"처럼 결과(outcome)를 제공, 구현 방법은 에이전트가 결정
  • 에이전트가 코드베이스를 알고 리서치를 수행하므로 계획도 에이전트의 책임
  • 구현 전 접근 방식을 리뷰하여 잘못된 방향을 조기 차단
  • 복리화 작업: 잘 작동한 결과 중심 지시 라이브러리 구축

• 4 → 5: 모든 것을 병렬화

  • 실행을 클라우드로 이전하여 로컬 머신 병목 해소
  • 3개 에이전트에 3개 기능을 동시에 할당
  • 아이디어, 버그, 개선 사항을 큐로 구성하여 에이전트가 순서대로 처리
  • 에이전트가 사용자 피드백을 모니터링하고 기능을 자발적으로 제안하도록 활성화
  • 복리화 작업: 병렬 수행 가능한 작업과 본질적으로 직렬인 작업을 구분하여 문서화

AI 산출물 승인 전 3가지 질문

• "여기서 가장 어려운 결정은 무엇이었나?" — AI가 까다로운 부분과 판단 지점을 드러내도록 유도
• "어떤 대안을 거부했고, 왜 그랬나?" — 고려한 옵션을 확인하여 잘못된 선택 포착
• "가장 확신이 없는 부분은?" — LLM이 자신의 약점을 인정하게 하되, 직접 물어야만 답변

에이전트 네이티브 아키텍처

• 에이전트에게 개발자와 동일한 역량을 부여하는 것이 핵심
• 에이전트가 테스트를 실행하지 못하면 직접 실행해야 하고, 로그를 볼 수 없으면 직접 디버깅해야 하므로 허용하지 않는 모든 역량이 수동 작업으로 전환

• 에이전트 네이티브 체크리스트

  • 개발 환경: 로컬 애플리케이션 실행, 테스트 스위트 실행, 린터·타입 체커 실행, DB 마이그레이션, 개발 데이터 시드
  • Git 작업: 브랜치 생성, 커밋, 리모트 푸시, PR 생성, PR 코멘트 읽기
  • 디버깅: 로컬/프로덕션 로그 조회(읽기 전용), UI 스크린샷, 네트워크 요청 검사, 에러 트래킹(Sentry 등) 접근

• 점진적 에이전트 네이티브 도입

  • Level 1 (기본 개발): 파일 접근, 테스트 실행, Git 커밋 — 기본 Compound Engineering 가능
  • Level 2 (전체 로컬): 브라우저, 로컬 로그, PR 생성 접근 — Stage 3~4 가능
  • Level 3 (프로덕션 가시성): 프로덕션 로그(읽기 전용), 에러 트래킹, 모니터링 대시보드 — 에이전트 능동적 디버깅 가능
  • Level 4 (전체 통합): 티켓 시스템, 배포 역량, 외부 서비스 통합 — Stage 5 가능

• 에이전트 네이티브 마인드셋

  • 기능 구축 시: "에이전트가 이것과 어떻게 상호작용할 것인가?"
  • 디버깅 시: "에이전트가 무엇을 볼 수 있어야 하는가?"
  • 문서화 시: "에이전트가 이것을 이해할 수 있는가?"

Skip Permissions

• Claude Code의 --dangerously-skip-permissions 플래그는 매 액션마다 묻는 권한 요청을 비활성화
• 이름이 의도적으로 무서운 것은 사용 전 신중하게 생각하도록 유도하기 위함

• 사용 시점

  • 사용 권장: 좋은 계획과 리뷰 시스템이 있을 때, 샌드박스 환경에서 작업할 때, 속도가 필요할 때
  • 사용 자제: 학습 중일 때(권한 요청이 이해에 도움), 프로덕션 코드 작업 시, 롤백 체계가 없을 때

• 권한 생략 시 안전 메커니즘

  • Git이 안전망: 에이전트 작업이 Git에 기록되어 git reset --hard HEAD~1으로 복원 가능
  • 테스트가 실수 포착: 머지 전 테스트 실행
  • 머지 전 리뷰: 구현 중 권한은 생략하지만 최종 리뷰는 반드시 수행
  • Worktree로 리스크 격리: 위험한 작업은 격리된 디렉토리에서 실험

• 생산성 계산

  • 권한 미생략 시 약 30초마다 프롬프트 발생, 매번 "y" 입력으로 집중력 상실
  • 권한 생략 시 플로우 상태 유지 가능하여 5~10배 빠른 반복 달성, 가끔 롤백하는 리스크를 크게 상회하는 시간 절약

디자인 워크플로우

• Baby App 접근법

  • 테스트·아키텍처·브레이킹 걱정 없이 자유롭게 반복할 수 있는 일회용 프로젝트(baby app) 생성
  • 디자인이 만족스러우면 색상·간격·타이포그래피·컴포넌트 패턴을 추출하여 본 프로젝트에 이전

• UX 탐색 루프

  • 여러 버전을 생성하여 클릭스루, 사용자에게 기능적 프로토타입을 공유하여 피드백 수집
  • Figma 목업과 달리 실제로 클릭 가능
  • 프로토타입은 학습용이며, 이후 적절한 계획으로 처음부터 다시 구축

• 디자이너와의 협업: Compound 플로우

  • 전통적 플로우: 디자이너 목업 → 개발자 해석 → 수정 반복
  • Compound 플로우: 디자이너 Figma 목업 → /plan에 Figma 링크 전달 → AI 구현 → figma-design-sync 에이전트가 구현과 목업 일치 여부 확인 → 디자이너가 스크린샷이 아닌 라이브 버전 리뷰

• 디자인 취향 코드화

  • 디자이너와 몇 가지 기능을 함께 작업하며 발견한 패턴(선호 색상, 폼 레이아웃 등)을 스킬 파일에 기록
  • AI가 디자이너의 취향에 맞는 디자인을 디자이너 없이도 생산 가능

• 디자인 에이전트

  • design-iterator: 현재 디자인 스크린샷을 분석하고 개선을 반복하여 점진적으로 정제
  • figma-design-sync: Figma에서 디자인을 가져와 구현과 비교, 차이를 자동 수정
  • design-implementation-reviewer: 구현이 Figma 사양과 일치하는지 검사하여 시각적 버그를 사용자 도달 전에 포착

바이브 코딩 (Vibe Coding)

• 코드 자체가 아닌 결과만 원하는 사람을 위한 접근법: 프로덕트 매니저, 디자이너, 개인 프로젝트 등
• 래더를 건너뛰고 Stage 4로 직행: 원하는 것을 설명 → 에이전트가 계획·코드·테스트·리뷰·PR 모두 처리
• 적합한 경우: 개인 프로젝트, 프로토타입, 실험, "이게 가능한가?" 조사, 내부 도구, UX 탐색
• 적합하지 않은 경우: 사용자가 있는 프로덕션 시스템, 다른 사람이 유지보수할 코드, 보안 민감 앱, 성능 크리티컬 시스템

• 바이브 코딩 패러독스

  • 바이브 코딩이 오히려 계획 능력을 향상시킬 수 있음
  • 무엇을 만들지 모를 때 프로토타입을 생성하여 사용자 피드백 수집 후, 모든 것을 삭제하고 적절한 계획으로 다시 시작
  • 최적 분배: 바이브 코딩으로 발견, 스펙으로 구축 — 최종 구현에서는 항상 스펙이 승리

팀 협업

• 새로운 팀 다이내믹스

  • 전통적: 사람 A가 코드 작성 → 사람 B가 리뷰 → PR 코멘트 토론 → 승인 후 머지
  • Compound: 사람 A가 계획 생성 → AI 구현 → AI 에이전트가 리뷰 → 사람 B가 AI 리뷰를 리뷰 → 인간 승인 후 머지

• 팀 표준

  • 계획 승인: 침묵은 승인이 아니므로 구현 전 명시적 사인오프 필요
  • PR 소유권: 코드 작성 주체와 무관하게 작업을 시작한 사람이 PR 소유, 계획 품질·리뷰·수정·머지 후 영향에 책임
  • 인간 리뷰 초점: AI 리뷰 에이전트가 이미 분석한 PR에서 인간은 구문 에러·보안·성능·스타일이 아닌 의도(intent) 중심으로 리뷰 — "합의한 것과 일치하는가?", "접근 방식이 합리적인가?", "비즈니스 로직 이슈가 있는가?"

• 커뮤니케이션 패턴

  • 비동기 기본: 계획을 생성·리뷰·승인하는 데 회의 불필요, "계획 문서를 만들었으니 오늘 중 코멘트 부탁"
  • 명시적 핸드오프: 상태, 완료 내용, 남은 작업, 컨텍스트, 계속 방법을 포함

• 확장 패턴

  • 명확한 소유권 + 비동기 업데이트: 주요 기능마다 한 명의 소유자가 계획·모니터링·리뷰·머지·팀 업데이트
  • Feature flag + 작은 PR: 모두가 빠르게 배포할수록 머지 충돌 증가, 작은 단위로 배포하고 메인에 자주 머지하며 충돌 즉시 해결
  • Compound 문서 = 부족 지식(tribal knowledge): "Sarah에게 물어봐, auth 잘 알아"가 아니라, Sarah가 /compound를 실행하여 솔루션을 문서화하면 누구나 검색 가능

사용자 리서치

• 리서치-개발 갭

  • 전통적: 리서처가 인터뷰 → 리포트 작성 → Google Drive에 방치 → 개발자가 리포트 미확인 → 기능이 사용자 니즈 미반영
  • Compound: 리서치가 구조화된 인사이트 생성 → 인사이트가 계획 컨텍스트로 활용 → AI가 계획 시 인사이트 참조 → 사용 데이터가 인사이트를 검증 → 인사이트가 복리적으로 축적

• 리서치 구조화

  • 원시 인터뷰 노트를 AI가 활용할 수 있도록 구조화된 마크다운으로 변환: 참여자 정보, 핵심 인사이트, 인용문, 함의, 신뢰도(n/5 참여자) 포함

• 페르소나 문서

  • 목표, 불만, 인용문을 포함한 페르소나 문서 생성하여 AI가 참조 가능

• 리서치 기반 계획

  • /workflows:plan 실행 시 리서치 컨텍스트(인터뷰 결과, 페르소나 패턴, 현재 페인포인트)를 포함하여 리서치 인사이트가 기능으로 직접 연결

데이터 패턴 추출

• 사용자가 제품을 사용하는 방식이 무엇을 만들지 알려주는 단서

• 주목할 패턴 유형

  • 과다 사용 패턴: 예상보다 훨씬 많이 사용되는 기능, 동일 페이지에 반복 방문
  • 어려움 패턴: 단순 페이지에서의 높은 체류 시간, 동일 액션 반복 시도, 에러→재시도→에러 루프
  • 우회 패턴: 한 곳에서 데이터를 내보내 다른 곳에 다시 가져오기, 화면 간 복사·붙여넣기, 비교를 위해 여러 탭을 동시에 열어두기
  • 이탈 패턴: 플로우에서의 이탈, 시작했지만 완료되지 않은 기능

• 패턴에서 기능으로

  • 사용자가 테이블 간 데이터를 주 50회 복사·붙여넣기 → "테이블 B에 동기화" 버튼 기능화
  • 사용자가 "템플릿" 프로젝트를 만들고 복제 → 일급 템플릿 지원 기능화

카피라이팅

• 계획에 카피 포함

  • 대부분의 팀이 카피를 기능 구축 후 채우는 후순위로 취급하지만, 카피는 사용자 경험의 일부
  • 계획 단계에서부터 이메일 제목, 성공 메시지, 에러 메시지 등 사용자 대면 카피를 포함하면 AI 구현 시 카피가 이미 준비됨

• 보이스 코드화

  • 원칙(인간처럼 말하기, 에러 메시지는 도움을 주어야 함, 짧은 문장, 명확한 단어)과 피해야 할 단어(Invalid → didn't work, Error → 무슨 일이 일어났는지 설명 등)를 스킬 파일로 작성

• 카피 리뷰

  • /workflows:review 프로세스에 카피 리뷰를 추가: 명확성, 도움 여부, 톤, 일관성 4가지 기준으로 검토하는 copy-reviewer 에이전트

프로덕트 마케팅

• Compound 플로우

  • 엔지니어가 제품 가치 제안을 포함한 계획 생성 → AI 기능 구현 → AI가 계획에서 릴리즈 노트 생성 → 릴리즈 노트에서 소셜 포스트 생성 → Playwright로 스크린샷 자동 캡처 → 엔지니어가 리뷰 후 모든 것을 함께 배포
  • 모든 것이 한 곳에서 흐르므로 핸드오프 불필요, 빈틈 없음

• 릴리즈 노트 생성

  • AI가 계획, 코드 변경, 테스트를 모두 보유하므로 정확히 무엇이 구축되었는지 파악 가능
  • 사용자 이점 우선, 구체적 예시 1개 포함, 브레이킹 체인지 언급, 200단어 이내

• 체인지로그 생성

  • /changelog 커맨드로 최근 메인 머지를 확인하고, 각 계획/PR을 읽어 매력적인 체인지로그 생성

• 자동 스크린샷

  • Playwright를 사용하여 마케팅용 스크린샷 자동 캡처, 엔지니어링에 스크린샷 요청 불필요, 오래된 스크린샷 문제 해소