기능 개발

1. 무엇을 만드나

예제 기능은 긴 글을 붙여넣으면 3줄로 요약해 주는 페이지다. 이 강의에서 겉모습(폼·뷰·템플릿)을 만들고, 다음 강의들에서 여기에 AI 처리를 붙인다.

핵심은 예제 자체가 아니라 /develop 워크플로우다. /develop 은 자유 코딩이 아니라 스펙 기반 구조화 개발이다. worktree 격리, 계획·스펙 두 번의 승인 게이트, 자동 검증(spec-verifier), merge-master 머지, 백로그 연동이 한 흐름으로 묶여 있다. 개발자는 무엇을 만들지 정의하고 게이트에서 판단만 한다. 코드 작성·검증·머지는 워크플로우가 돌린다.

• /dev 와 /develop 은 다른 스킬이다. /dev = 개발 서버를 띄운다(CHAP.03 L01 개발 서버 실행). /develop = 기능을 개발하는 워크플로우. 이름만 비슷하니 주의.

2. 실행

프로젝트 루트(src)에서 Claude Code 를 켠다.

# 🖥️ 서버 터미널
gildong@ip-172-31-39-132:~$ cd ~/my_project/src
gildong@ip-172-31-39-132:~/my_project/src$ claude

/develop {app_name} {task} 형식으로 호출한다. app_name 은 기능이 담길 Django 앱, 그 뒤는 만들 것의 정의다.

/develop summarizer 글을 입력받아 3줄로 요약해 보여주는 페이지 만들어줘

• summarizer = 앱 이름.
• 뒤 문장 = task 정의. 백로그 ID(#D###)가 있으면 함께 적으면 그 항목에 연결된다.
• 자연어 개발 요청("summarizer 앱에 ... 만들어줘")도 이 워크플로우로 라우팅된다.
• 기본은 worktree 모드다. git worktree add 로 dev/{slug} 브랜치를 격리 생성해 master 작업 트리를 건드리지 않는다. 오타·주석·단일 문서 한 줄 같은 사소한 변경만 --inplace 로 우회한다.

3. 확인 질문에 답하기

/develop 은 자동으로 끝까지 달리지 않는다. 아래 순서로 진행하며, 승인 게이트 두 곳에서 멈춰 판단을 요구한다.

1. 컨텍스트 로드 + 백로그 연동: docs/specs/, docs/features/, docs/structures/, 백로그 대기 항목, 관련 모델·뷰·템플릿을 병렬로 읽는다. 연결할 백로그 항목이 있으면 한 번 확인을 요청한다.
2. 승인 게이트 ① 계획: 변경할 파일 목록, 구현 접근, 영향 범위를 제시한다. 괜찮으면 진행, 아니면 무엇을 바꿀지 지시한다.
3. 승인 게이트 ② 스펙: docs/specs/summarizer.md 초안(입력/출력 형태, 처리 흐름, 예외 케이스, URL·응답 스키마)을 보여준다. 이 스펙이 이번 사이클의 SoT 이자 뒤 검증 단계의 기준이다. 승인해야 구현으로 넘어간다.
4. 구현: 스펙대로 코드를 작성한다. 이때 ## Code Patterns 체크리스트(LLM 호출은 standarda_core.llm 경유, 키워드 매칭 금지, CSRF·escapeHtml() 등)를 따른다.
5. 검증 라운드: spec-verifier 가 구현을 스펙과 대조한다(스펙이 없으면 BLOCKED). API 엔드포인트가 생겼으면 api-tester, 파싱 코드면 pdf-parser/excel-parser 가 병렬로 돈다. 미준수 항목이 하나라도 있으면 머지가 차단되고, 코드 수정 또는 스펙 patch 후 재검증한다.
6. 문서 생성: 새 기능이면 /feature-doc, 구조 변경이면 /structure-doc 로 문서를 만든다.
7. 머지 + 마무리: merge-master 가 worktree 를 master 로 머지·커밋한다. 마이그레이션이 포함됐으면 dev DB 에 migrate 를 적용하고, 연결된 백로그 항목을 완료 처리한다.

즉 게이트 두 곳(계획·스펙)만 사람이 판단하고, 검증·머지·문서·마이그레이션은 자동으로 돈다. 끝나면 dev 도메인에서 만든 화면을 확인한다.

마무리

• 핵심 정리: /develop summarizer {task} 로 요청하고, 계획·스펙 두 게이트를 승인해 spec-verifier 검증과 merge-master 머지까지 자동으로 도는 사이클로 기능 하나를 완성했다.
• 주의 사항: task 정의가 막연하면 스펙도 막연해지고 spec-verifier 검증도 헐거워진다. 입력과 출력을 명제 단위로 적을수록 스펙과 검증이 정확해진다. 한 번에 큰 걸 시키지 말고 한 가지 단위로 쪼갠다.
• 다음 시간: AI API 키 발급.