전체 SDLC에서 순수 판단 엔진으로서 클로드 코드 실행하기

r/ClaudeAI의 한 개발자가 소프트웨어 개발 수명 주기 전반(티켓, 교차 저장소 구현, 코드 리뷰, MR, 지속적 지식 계층)에 걸쳐 Claude Code(도구 사용 및 다중 턴 루프를 갖춘 런타임)를 사용하는 수개월간의 설정을 자세히 설명했습니다.

핵심 아키텍처 결정: Claude Code를 오케스트레이션에서 배제합니다. 일반 Python이 모든 기계적 작업(Jira API 호출, git 작업, 테스트 실행, 린트, 파일 이동)을 처리합니다. Claude Code는 판단이 필요한 경우에만 호출됩니다—코드 작성, 리뷰 결과 평가, 아키텍처 옵션 선택 등. 저자는 두 가지를 혼합(에이전트가 도구 사용을 통해 오케스트레이션하도록 허용)하면 첫 번째 버전이 느리고, 비용이 많이 들며, 비결정적이었다고 발견했습니다.

하나의 티켓에 대한 구체적인 수명 주기:

• Python 오케스트레이터: Jira 티켓을 가져오고, 로컬 위키에서 관련 아키텍처 결정을 검색하며, 새 브랜치에 작업 트리를 설정하고, 30-50줄의 구현 요약(수락 기준, 대상 파일, 수정된 공유 함수 호출자, 관련 표준)을 작성합니다. JSON 번들을 출력합니다.
• Claude Code: 요약을 읽고 코드를 작성합니다. 이 단계만 상당한 토큰을 소비합니다.
• Python + 리뷰 하위 에이전트: 테스트, 린트, 포맷을 실행합니다. 실패 시 구현 에이전트로 다시 넘깁니다(최대 3회 재시도). 그런 다음 편집 또는 쓰기 권한이 없는 코드 리뷰 하위 에이전트를 호출합니다—읽기 및 결과 보고만 가능합니다.
• Python: 대시보드에 제안을 생성합니다. 수동 승인 후 오케스트레이터가 푸시하고 MR을 생성합니다.

중요했던 구체적인 Claude Code 기법:

• 하위 에이전트 격리. 리뷰 에이전트는 자체 컨텍스트 창에서 실행되며 거부 목록(편집, 쓰기)이 있습니다. 리뷰와 구현을 분리함으로써 구현 에이전트가 계속 놓치던 공유 코드의 동작 변경을 포착했습니다.
• 사전 조립된 요약이 동적 탐색보다 우수. 초기에는 구현 전에 Claude Code가 코드베이스를 탐색하도록 두는 것이 Python이 조립한 집중된 요약(Jira 가져오기, 위키 검색, 의존성 분석)을 전달하는 것보다 눈에 띄게 더 많은 토큰을 소모했습니다.
• YAML을 통한 스킬/명령 라우팅 에이전트가 결정하도록 두지 않음. /ticket, /review, /standup 등을 오케스트레이터에 매핑하는 것이 명시적이므로 기능이 검사 가능하며 우연히 생기지 않습니다.
• 훅이 커밋을 제어. 커밋 전 훅이 Claude Code가 시도하는 모든 커밋 전에 린트와 포맷을 실행합니다. 위반 시 커밋이 차단되며 에이전트는 이를 수정해야 합니다.

위키 계층: 세 가지 신뢰 수준(확인됨, 추론됨, 인간 제공)과 필드 수준의 오래됨 임계값이 있는 마크다운 페이지. 계층화가 없으면 에이전트는 자신의 과거 추론을 진실로 취급하고 환각을 권위 있는 지식으로 증폭시킵니다.

여전히 해결 중인 어려움:

• 교차 저장소 기능: 기능이 여러 서비스에 걸쳐 있을 때 에이전트는 일관성을 잃습니다. 구조화된 변경 세트 추적이 있더라도 마찬가지입니다.
• 모호한 티켓: 에이전트는 모호한 명세에서 합리적이지만 종종 잘못된 구현을 생성합니다. 저자는 이제 모호한 티켓을 차단 항목으로 표시합니다.
• 범위 확장: 과도한 엔지니어링 성향은 표준과 리뷰 에이전트를 통한 지속적인 보정이 필요합니다.
• 긴 세션: 초기 컨텍스트가 유효한 주의 범위를 벗어납니다. 세션 시작 시 재초기화가 완화하지만 완전히 제거하지는 못합니다.