Claude Code로 애플리케이션을 만들 때, 모델이 좋아질수록 정교한 파이프라인이 필요 없어진다
수개월에 걸쳐 Claude Code용 다단계 작업 파이프라인을 직접 구축해 사용해왔다. 스펙 작성, 계획 수립, 실행 전 검증 단계, 단계별 실행, 자동 리뷰, 발견 사항 분류(triage)로 이어지는 구조였다. 이 파이프라인은 실제로 문제를 잡아냈다 — 버전이 확인되지 않은 패키지, 모호한 완료 기준, 체크포인트 없이 20개 이상의 파일을 건드리는 계획 같은 것들이었다. 현재 진행 중인 프로젝트는 10년 된 을 로 다시 만드는 작업으로, 실사용자가 수천 명 있는 만큼 제약이 엄격하다.
기존 앱의 를 그 자리에서 그대로 읽어야 하고, 암호화 로직은 바이트 단위로 완전히 동일해야 하며, 예전 백업 파일 형식 4가지를 모두 처리해야 한다. 최근에는 수동으로 처리하던 백업 기능을 백그라운드 동기화 서비스로 교체하는 작업을 했는데, 여러 파일에 걸친 변경과 테스트 재작성, 11개 언어 문자열 수정이 필요한 작업이었다. 예전 같으면 전체 파이프라인을 돌렸겠지만, 이번엔 그냥 평범한 대화로 작업 내용을 설명하기만 했다. 모델은 스펙 단계가 강제하던 확인 질문들을 스스로 물었고, 코덱을 건드리기 전에 예전 백업 형식들을 먼저 점검했는데 이는 원래 단계가 하던 역할이었다.
테스트도 시키지 않았는데 알아서 돌렸다. 결국 그동안 만든 도구 대부분이 모델의 약점을 메우기 위한 장치였고, 그 약점들은 매 릴리스마다 하나씩 사라지고 있다는 결론이었다.
핵심 포인트
- 다단계 파이프라인(스펙→계획→검증→실행→리뷰)이 버전 미확인 패키지, 모호한 기준 등 실제 문제를 잡아냈던 경험이 있다
- 현재 프로젝트는 10년 된 을 로 재작성 — 그대로 읽기, 암호화 바이트 단위 일치, 레거시 백업 4종 지원이 필수 제약
- 백업 기능을 백그라운드 동기화로 바꾸는 다중 파일 작업을 파이프라인 없이 평범한 대화로 진행
- 모델이 스스로 확인 질문을 하고, 레거시 포맷을 먼저 점검하고, 테스트까지 알아서 실행함 — 예전 파이프라인 단계들을 대체
- 자체 결론: 커스텀 하네스 상당수는 모델의 약점을 메우던 임시방편이었고, 그 약점은 릴리스마다 줄어들고 있다