Feature Pipeline

Feature Pipeline은 사내 Flutter 앱 개발에 쓰는 Claude Code 스킬입니다. 명령 하나로 Jira 티켓 하나를 계획 → 검증 → 구현 → 리뷰 → PR 순서로, 정해진 단계를 따라 끝까지 진행합니다. 사내 프로젝트라 코드는 공개하지 않고, 어떤 문제를 어떤 방식으로 풀었는지 위주로 정리했습니다.

왜 만들었나

AI 에이전트에게 기능 하나를 통째로 맡기면 비슷한 문제가 반복됐습니다.

• 세션이 끊기면 그동안의 맥락과 결정이 같이 사라집니다.
• 구현한 에이전트가 자기 작업을 스스로 “완료”라고 판정합니다.
• 리뷰가 끝나지 않고, 이미 결정한 논점을 몇 번이고 다시 꺼냅니다.

어떻게 만들었나

처음부터 완성된 설계가 있었던 건 아닙니다. 3주 동안 실제 티켓을 처리하면서 다듬었고, 지금 있는 규칙 대부분에는 그 규칙이 생기게 만든 티켓이 하나씩 있습니다.

상태는 대화가 아니라 커밋된 문서에 둡니다. 티켓마다 계획 문서를 만들고, 맨 위에 단계별 체크리스트와 다음에 실행할 명령을 적어 커밋합니다. 어떤 세션이든 이 문서부터 읽고 체크되지 않은 첫 단계에서 시작하기 때문에, 세션이 죽거나 사용량 한도에 걸려도 작업을 잃지 않고 다른 머신에서도 그대로 이어집니다.

중요한 경계에서는 새 세션으로 넘어갑니다. 계획에서 구현으로, 구현에서 리뷰로 넘어갈 때는 항상 새 세션을 엽니다. 리뷰하는 쪽이 구현하면서 버린 가설을 물려받지 않게 하려는 것입니다. 나머지 경계는 컨텍스트 사용량을 재서 정합니다.

구현한 쪽이 스스로 채점하지 않습니다. 단계마다 다른 시선이 검증합니다. 계획은 여러 모델이 함께 검토하는 Fusion Council과 Codex가 원문 요구사항과 대조합니다. 구현과 수정은 세션이 프롬프트를 볼 수 없는 Codex 리뷰와 매 턴 끝의 리뷰 게이트를 거칩니다. UI가 바뀌면 실제 화면을 렌더해서 제가 직접 확인합니다.

체크박스가 아니라 영수증으로 완료를 증명합니다. 에이전트는 “완료”를 직접 체크할 수 없습니다. 해당 커밋에서 정적 분석과 전체 테스트가 통과해야만 스크립트가 영수증을 남기고, 다음 단계는 그 영수증부터 확인합니다. 애매하면 출하가 아니라 재리뷰 쪽으로 넘어갑니다.

반복되는 건 판단 대신 숫자로 막습니다. 한 티켓이 34시간 걸렸는데 구현은 5시간이었고, 나머지는 이미 세 번 결정한 논점을 도는 리뷰였습니다. “같은 논점을 반복하지 말라”는 규칙이 있었는데도 에이전트는 그 규칙을 인용하면서 같은 라운드를 또 돌았습니다. 그래서 리뷰 횟수, 규칙 파일 크기, 세션 인계 시점에 숫자 상한을 걸었습니다. 숫자는 올릴 수 있지만, 올리는 순간 사유와 함께 diff에 남습니다.

규칙을 더하는 루프와 빼는 루프를 둘 다 돌립니다. 티켓이 끝날 때마다 겪은 함정을 규칙이나 가이드로 올립니다. 그렇게 쌓다 보니 규칙 파일이 87KB까지 불어나 에이전트가 따라갈 수 없는 상태가 됐습니다. 그래서 2주마다 회고 스킬이 세션 기록 수백 개를 분석해, 쓰이지 않는 규칙은 지우고 두 번 이상 어겨진 규칙은 테스트가 붙은 스크립트로 옮깁니다. “왜 이 규칙이 생겼는지”는 별도 문서로 분리해서, 에이전트는 실행할 규칙만 읽습니다.

결과

• 티켓당 리뷰 라운드: 최악 31회 → 중앙값 3회
• 구현 단계 세션이 읽는 규칙 분량: 약 90KB → 약 47KB
• 규칙 크기는 상한 안에서 유지하고, 규칙마다 생긴 이유는 160여 개 항목으로 따로 기록
• 어떤 티켓에서는 제가 입력한 게 명령 하나와 질문 9개에 대한 선택뿐이었고, 진행 중 방향 수정은 전부 검증 단계에서 나왔습니다