Claude Code /goal 명령어로 안드로이드 PR 깎기 — 일주일 실전기

 

지난주 금요일 밤 11시, 안드로이드(이하 안드) PR에 달린 리뷰 코멘트 30개를 보고 노트북을 덮을 뻔했어요. 그때 /goal 한 줄을 박아봤습니다.

 

클로드 코드 /goal, 실행 모델과 평가 모델이 분리됐어요

/goal은 5월 12일에 출시된 클로드 코드(Claude Code) 2.1.139 버전부터 들어간 기능입니다. 핵심은 "완료 조건을 충족할 때까지 멈추지 말고 가라"는 자율 실행 명령이에요.

 

동작 구조가 흥미로운데요. 실행은 Opus나 Sonnet 같은 메인 모델이 맡고, 매 턴이 끝날 때마다 별도의 평가자 모델(기본은 Haiku)이 전체 대화 기록을 다시 훑어서 "목표가 충족됐는가?"를 Yes/No로 판정합니다.

 

No가 나오면 그 사유가 다음 턴의 작업 지침으로 자동 전달되고, Yes가 나오면 거기서 자동 종료됩니다. 실행하는 머리와 점수 매기는 머리를 떼어놨다는 게 설계 의도라고 보시면 되겠습니다.

 

안드로이드 PR 리뷰 자동화에 /goal 박는 법

지난주에 제가 실제로 던졌던 줄은 이거였어요.

/goal all review comments are resolved and all unit tests pass, or stop after 50 turns

 

이 한 줄을 박고 화장실 다녀온 사이에, 코루틴 디스패처 누락 7건과 ktlint 오류 14건이 알아서 정리되어 있더라고요. 정적 분석 영역, 특히 Dispatcher 누락이나 Null Safety, 비구조적 동시성 같은 패턴은 클로드가 꽤 안정적으로 잡아내는 편입니다.

자동화에 잘 맞는 작업은 대체로 이런 결입니다.

• 리뷰 코멘트 반영해서 패치 자동 생성
• lint, detekt, ktlint 같은 정적 분석 0건까지 깎기
• 단위 테스트와 Espresso UI 테스트 통과 확인
• PR 설명·CHANGELOG 자동 갱신

기계적 반복 비중이 클수록 효과가 좋아요. 반대로 아키텍처 결정이나 도메인 모델 분리 같은 판단 작업은 /goal에 던져두면 안 됩니다. 결과가 그럴듯해 보여도 사람이 다시 봐야 해요 — 이른바 HITL(Human-in-the-Loop) 단계는 빼면 안 된다는 얘기지요.

 

 

트랜스크립트만 보는 평가자, 할루시네이션 위험

여기가 진짜 함정입니다. 평가자 모델은 실제 파일 시스템이나 셸, CI 결과를 직접 못 봐요. 오로지 대화창에 출력된 텍스트만 가지고 완료 여부를 판정합니다.

 

그러면 어떤 일이 생기냐면, 메인 모델이 "테스트 27개 모두 통과했습니다"라고 거짓 보고를 출력하는 순간, 평가자는 그걸 사실로 받아들이고 작업을 끝내버립니다. 진짜로 실행했는지는 알 길이 없으니까요.

 

이걸 막으려면 완료 조건에 검증 가능한 텍스트 산출물을 강제로 끼워 넣어야 합니다. 예를 들면 "테스트 결과 로그 전체를 출력할 것", "./gradlew test의 exit code와 함께 마지막 50줄을 붙여넣을 것" 같은 식이요. 평가자가 텍스트만 본다는 약점을 역으로 활용하는 방법이라는 얘기입니다.

 

 

무한 루프와 토큰 비용, 자율 실행 시 조심할 지점

/goal의 가장 큰 함정은 비용입니다. 매 턴마다 평가자 모델이 추가로 호출되거든요. 50턴짜리 자율 실행을 돌리면 같은 작업을 일반 모드로 했을 때보다 토큰 사용량이 눈에 띄게 올라갈 수 있어요. 50턴이 어느 정도냐면, 제 케이스에선 일반 모드에서 PR 코멘트 정리에 보통 10~15턴 정도 쓰니까 3~5배쯤 더 도는 셈이지요. (어디까지나 제 작업 패턴 기준이니 팀 환경에 따라 다를 수 있어요.)

 

저는 처음 돌렸을 때 점심시간 동안 방치해뒀다가 /usage 찍어보고 잠깐 멈칫했습니다. 그래서 이젠 무조건 or stop after N turns 절을 함께 박습니다 — "조건 + 턴 상한"을 한 줄에 같이 넣는 패턴이 실제로 잘 동작하더라고요. 공식 문서가 OR 절 동작을 명시적으로 보장하는 건 아니지만, 제 관례로는 일종의 Task Budgets처럼 상한을 함께 거는 식으로 쓰고 있어요. 단순 리팩토링은 20턴, PR 코멘트 정리는 50턴 정도로 잡아두고 있어요.

 

비슷한 명령어로 /loop가 있는데, 둘이 결이 다릅니다. /goal은 "조건이 만족되면 멈추는" 상태 기반이고, /loop는 정해진 주기로 반복 실행하는 시간 기반이에요. 안드 PR처럼 종료 조건이 명확한 작업엔 /goal이 맞다고 봅니다.

 

긴 작업에선 토큰 한도가 차서 초반 요구사항을 잊는 일도 생길 수 있어요. /compact로 압축할 수 있긴 한데, 원본 디테일이 같이 깎이는 건 감수해야 합니다.

 

자동 PR 머지 전에 팀과 합의해야 할 세 가지

여기서부턴 도구 얘기가 아니라 사람 얘기예요. /goal이 잘 도는 걸 보면 자꾸 자동 머지까지 욕심이 나는데, 그 전에 합의해둬야 할 게 있습니다.

 

1. PR 리뷰는 지식 공유 통로이기도 합니다 PR 리뷰는 코드 수정 채널만이 아니라 팀 안의 지식 공유 통로이기도 합니다. 주니어가 코멘트를 받고 "왜 이렇게 고쳐야 하는지"를 따라가는 학습 경로를 자동화가 통째로 가져가버릴 수 있어요. 속도와 학습 사이 어디에 선을 그을지는 팀에서 명시적으로 합의해야 한다고 봅니다.

 

2. CI 연동 시 자동 커밋·푸시 사이 사람 단계 필수 깃허브 액션(GitHub Actions) 같은 CI와 묶어 자동 커밋·푸시까지 연결할 때는 시크릿 노출이나 의도치 않은 프로덕션 코드 변경 같은 위험이 따라옵니다. 자동화 브랜치와 프로덕션 브랜치 사이에는 사람이 한 번 보는 단계를 반드시 깔아두시는 게 좋겠습니다.

 

3. 자동화 범위를 문서로 남겨두기 자동화 범위를 문서로 남겨두는 게 의외로 중요해요. "lint·포맷·테스트 통과 정도까지는 /goal이 한다, 클래스 분리나 모듈 경계 변경은 사람이 한다" 식으로요. 이게 없으면 PR마다 누가 어디까지 손댈지를 두고 부딪치는 일이 생기더라고요.

 

 

마치며

참고로 저는 깃허브 액션 워크플로에 /goal 자동 실행은 안 걸어두고, 로컬에서만 돌린 결과를 다시 사람이 PR 올리는 방식으로 쓰고 있습니다. 자율성과 안전판 사이 타협점이 거기쯤이라고 보고 있어요.

 

리뷰 코멘트 30개짜리 PR을 토요일 아침 9시 전에 닫고 그 주말엔 동네 천변으로 산책을 다녀왔습니다. 도구가 일을 가져간 게 아니라, 제가 쥐고 있던 야근 한 토막을 돌려받은 셈이지요.