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

> Clean Markdown view of GeekNews topic #26560. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26560](https://news.hada.io/topic?id=26560)
- GeekNews Markdown: [https://news.hada.io/topic/26560.md](https://news.hada.io/topic/26560.md)
- Type: news
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-02-10T11:31:01+09:00
- Updated: 2026-02-10T11:31:01+09:00
- Original source: [every.to](https://every.to/guides/compound-engineering)
- Points: 51
- Comments: 0

## Summary

모든 개발 단위를 다음 작업을 더 쉽게 만드는 **복리형 엔지니어링 루프**로 재구성하는 것이 Compound Engineering의 핵심입니다. 계획→실행→리뷰→복리화의 4단계 루프를 통해 AI 에이전트가 코드 작성뿐 아니라 학습과 개선까지 수행하며, 개발자는 시스템에 자신의 **취향과 원칙을 인코딩**하는 역할로 전환합니다. 코드보다 프로세스를, 타이핑보다 계획을 중시하는 이 접근은 시간이 지날수록 코드베이스가 스스로 성장하는 구조를 지향합니다.

## Topic Body

- 모든 엔지니어링 작업 단위가 이후 작업을 더 쉽게 만드는 **복리형 소프트웨어 개발 방법론**으로, 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를 사용하여 마케팅용 스크린샷 자동 캡처, 엔지니어링에 스크린샷 요청 불필요, **오래된 스크린샷 문제 해소**

## Comments



_No public comments on this page._