Claude Code로 자체 관리자를 구축하고 Codex로 브랜치를 검토하게 했습니다. 그 과정에서 배운 점들입니다.

다른 프로젝트들을 진행하면서 계속 똑같은 병목 현상에 부딪혔어. 바로 권한 문제랑 설계 결정이었지. 코딩을 하는 대신 하루 종일 감시만 하고 있는 내 모습을 발견했거든. 나는 그냥 스펙을 던져주고, 그쪽에서 반박도 좀 하게 둔 다음, 합의가 되면 내가 세세한 부분까지 신경 쓸 필요 없이 처음부터 끝까지 알아서 다 만들게 하고 싶었어.

게다가 스스로 검증까지 했으면 좋겠더라고. 코딩 에이전트들이 성능은 좋은데, 여전히 멍청한 실수를 저지르고 그게 쌓이면 나중에 골치 아파지잖아. 그래서 내가 믿고 맡길 수 있는 놈이 필요했어. 그래야 얘가 백그라운드에서 돌아가는 동안 나는 다른 일을 할 수 있으니까.

그래서 brindle을 만들었어. 이건 목표를 여러 작업으로 쪼갠 다음, 각 작업마다 워커를 할당해서 각자의 브랜치에서 병렬로 돌리는 방식이야. 병합하기 전에는 무조건 다음 과정을 거쳐야 해.

• 리뷰어가 커밋을 직접 승인해야 함. Codex가 설치되어 있으면 기본적으로 Claude의 브랜치를 리뷰하고, 로컬 모델을 쓸 수도 있어. 수정이 필요한 작업은 다시 워커한테 돌아가.

• 체크 명령어가 통과되어야 함. 나중에 병합이 일어날 때마다 다시 실행되니까, 회귀 버그가 생기면 바로 티가 나지.

브랜치가 통과되면 알아서 병합되니까, 나는 브랜치 더미를 뒤질 필요 없이 완성된 PR 하나만 확인하면 돼. 물론 언제든 워커가 어떻게 돌아가는지 확인할 수도 있고. 두 번 이상 작업한다고 실패한 게 아니야. 핵심은 코드를 빠르고 정확하게 밀어 넣을 수 있는 닫힌 리뷰 루프를 만드는 거니까.

Claude Code를 어떻게 썼나

나는 Claude Code로 brindle을 만들었어. 첫 버전이 돌아가기 시작하자마자 brindle 자체 저장소에 brindle을 돌려봤지. 그래서 나중에 추가된 기능들은 대부분 Codex가 브랜치를 리뷰하는 상황에서 Claude Code 워커들이 직접 만든 거야.

배운 점

• 리뷰는 여러 번 하는 게 정상임. 어려운 작업의 경우, 승인까지 포함해서 브랜치 하나당 평균 두 번 정도 리뷰를 거쳤어. 다른 벤더의 리뷰어를 섞어 쓰는 것도 도움이 되더라. 어떤 브랜치에서는 Codex가 매 라운드마다 새로운 진짜 버그를 찾아내기도 했거든.

• 똑같은 실수가 계속 반복됨. 동작이 바뀌었는데 테스트나 문서를 업데이트 안 하거나, 특정 코드 경로에만 권한 체크를 빼먹는 식의 실수가 계속 튀어나왔어. 그래서 brindle은 반복되는 지적 사항들을 나중에 워커들이 참고할 규칙으로 제안하게 만들었어(이 기능은 유료 플랜 전용이야).

• 컨텍스트가 무조건 많다고 좋은 건 아님. 워커 프롬프트에 분석 문서 요약을 넣어봤는데, 프롬프트의 30~36%를 차지하더라고. 확인해 보니까 워커 메시지나 리뷰어 판정에서 이걸 언급하는 경우는 하나도 없었고, 딱히 이득도 없었어.