Codex CLI /goal, 이제 AI 코딩 에이전트는 목표를 끝낼 때까지 스스로 돈다

나는 새 코딩 도구가 나오면 데모보다 먼저 종료 조건을 본다. 똑똑한 답변은 대부분 금방 따라온다. 대신 언제 멈추고, 무엇을 끝났다고 판단하고, 그 판단을 어떻게 다시 검증하느냐는 아키텍처 문제라서 한 번 차이가 벌어지면 쉽게 안 좁혀진다. 그래서 Codex CLI의 /goal은 단순한 편의 기능이 아니라, AI 코딩 에이전트를 “좋은 답변기”에서 목표를 추적하는 실행 루프로 바꾸는 신호에 가깝다.

핵심은 간단하다. 예전에는 우리가 프롬프트를 한 번 던지고 결과를 받은 뒤 다시 다음 지시를 적어야 했다. 이제는 목표 자체를 올려두고, 에이전트가 턴마다 완료 여부를 스스로 평가하면서 루프를 이어간다. 이 변화가 의미하는 건 모델이 더 똑똑해졌다는 말보다, 도구가 인간의 마이크로 매니지먼트를 덜 필요로 하게 됐다는 데 있다.

/goal이 바꾸는 건 답변 방식이 아니라 작업 단위다

많은 사람이 AI 코딩 도구를 아직도 “질문하면 코드 좀 써주는 터미널” 정도로 본다. 그 관점에서는 프롬프트 품질이 거의 전부다. 어떻게 말해야 더 잘 고치는지, 어떤 제약을 붙여야 이상한 수정을 덜 하는지, 답변 길이를 어떻게 조절할지 같은 문제가 중심으로 온다.

그런데 /goal은 이 프레임을 바꾼다. 이제 중요한 단위가 문장 하나가 아니라 완료해야 할 목표가 된다. 예를 들면 이런 식이다.

/goal PR의 failing test를 모두 복구하고, 원인 설명까지 남긴 뒤 멈춰라.

이 순간부터 에이전트는 단순 반응기가 아니라 작은 작업 관리자처럼 움직인다. 현재 상태를 보고, 다음 행동을 정하고, 실행하고, 다시 목표 달성 여부를 체크한다. 결국 사용자가 매 턴 “다음엔 이거 해”, “이번엔 테스트 다시 돌려”, “아직 안 끝났어”를 반복해서 써주던 부담이 줄어든다.

아키텍처 관점에서 보면 이건 꽤 큰 차이다.

즉, 이제 경쟁력은 “코드를 얼마나 잘 쓰느냐”만이 아니다. 어디서 멈춰야 하는지 알고, 끝나지 않았으면 스스로 한 번 더 도는 능력이 중요해진다.

진짜 차이는 자율성보다 종료 조건 설계에 있다

여기서 사람들이 가장 쉽게 흥분하는 지점은 “이제 AI가 혼자 끝까지 일한다”는 문장이다. 맞는 말이긴 한데, 절반만 맞다. 더 정확히 말하면 목표가 잘 정의된 범위 안에서만 혼자 끝까지 돈다가 맞다.

왜냐하면 /goal이 강해질수록 프롬프트보다 더 중요한 게 세 가지로 바뀌기 때문이다.

1. 완료 기준

“끝났다”는 말이 무엇을 뜻하는지 모호하면 루프는 길어지고 품질은 흐려진다. failing test 0건인지, lint까지 green인지, PR 설명문까지 포함인지, 로그 파일 업데이트도 필요한지 같은 조건이 빠져 있으면 에이전트는 애매한 곳에서 멈추거나 쓸데없이 오래 돈다.

2. 예산 제한

목표를 끝까지 추적하는 기능은 생산성을 올릴 수 있지만, 동시에 토큰과 실행 시간을 더 태울 수 있다. 그래서 /goal이 보편화될수록 “한 번 잘 쓰는 프롬프트”보다 어디까지 돌려도 되는지를 정하는 예산 감각이 더 중요해진다.

3. 중간 검증

에이전트가 스스로 반복 실행한다 해도, 잘못된 방향으로 세 번 빠르게 가는 건 그냥 세 번 더 망하는 것과 같다. 결국 테스트, diff, 실패 로그, 남은 TODO 같은 중간 체크포인트가 있어야 한다. 이게 없으면 자율성은 생산성이 아니라 비용 증폭기로 바뀐다.

이 세 가지를 묶으면 결론은 선명하다. /goal의 본질은 “사람을 없앴다”가 아니라 사람의 개입 위치를 뒤로 밀었다는 데 있다. 초반의 미세 지시를 줄이는 대신, 목표 정의와 검증 설계가 더 중요해졌다.

한국 개발자가 바로 체감할 만한 사용처는 따로 있다

이 기능을 처음 보면 거대한 자율 개발 시스템부터 상상하기 쉽다. 그런데 실제 체감 효용은 오히려 더 현실적인 작업에서 먼저 나온다.

테스트 복구와 반복 디버깅

테스트 하나 고치고 다시 돌리고, 다른 실패를 보고, 또 고치고, 다시 돌리는 작업은 개발자가 하기엔 지루하고 AI가 하기엔 구조가 명확하다. /goal은 이런 유형에 잘 맞는다. 목표가 “전체 테스트 green”처럼 분명하고, 중간 검증도 자동화하기 쉽기 때문이다.

백로그 청소

오래된 TODO, 깨진 예제, 타입 에러, 문서 드리프트처럼 사람 손은 자주 안 가지만 언젠가 정리해야 하는 일들에도 잘 맞는다. 이전에는 이런 잡무를 맡기려면 계속 follow-up을 써야 했는데, 목표 기반 루프가 열리면 한 번 맡기고 결과만 검수하는 흐름이 쉬워진다.

QA 체크리스트 확인

“이 PR이 lint/type-check/test를 모두 통과하는지 보고, 아니면 막는 지점을 정리해라” 같은 작업도 적합하다. 여기서는 창의성보다 절차적 검증이 중요하고, 실패하면 다시 한 단계 전으로 돌아가도 된다. 즉 인간이 매번 핸들을 잡지 않아도 되는 문제다.

반대로 아직도 사람이 촘촘히 붙어 있어야 하는 영역도 있다. 아키텍처 방향 전환, 도메인 모델 재설계, 제품 정책 결정, 민감한 보안 수정처럼 무엇이 정답인지 사람도 논쟁해야 하는 일은 /goal만으로 깔끔하게 닫히지 않는다. 이런 일은 목표가 아니라 판단이 핵심이기 때문이다.

이제 AI 코딩 에이전트의 경쟁 축이 바뀐다

여기서부터가 진짜 중요하다. 코딩 에이전트 시장은 오랫동안 “누가 더 똑똑하냐”를 전면에 세웠다. 하지만 /goal 같은 기능이 들어오기 시작하면 비교 기준이 달라진다.

앞으로는 이런 질문이 더 중요해진다.

• 목표를 얼마나 명확하게 유지하나?
• 루프를 돌수록 품질이 올라가나, 아니면 drift가 커지나?
• 언제 사람 승인을 요구해야 하는지 아나?
• 테스트/로그/diff를 근거로 자기 상태를 설명할 수 있나?
• 예산 안에서 멈추는가, 끝없이 맴도는가?

이건 모델 IQ 비교와는 다른 차원이다. 오히려 에이전트 런타임 설계, 승인 정책, 관측성, 실패 회수 전략이 더 중요해진다. 다시 말해 프롬프트 엔지니어링의 시대에서 goal ops의 시대로 옮겨가는 중이라고 보는 편이 맞다.

한국 개발자에게 이게 실무적으로 중요한 이유도 여기에 있다. 국내 팀들은 이미 Copilot, Claude Code, Codex, 각종 CLI 에이전트를 섞어 쓰고 있지만, 진짜 병목은 답변 한 번의 품질보다 반복 작업의 운영성에서 자주 터진다. 누가 더 많이 맞히느냐보다, 누가 더 덜 귀찮게 끝까지 가느냐가 체감 생산성을 가른다.

그런 의미에서 /goal은 AI 코딩 툴의 UX 변화가 아니라 워크플로우 변화다. 이제 좋은 도구는 “예쁘게 답하는 도구”가 아니라 목표를 붙들고, 실패를 해석하고, 검증 후 멈추는 도구가 된다.

그래서 개발자는 무엇을 바꿔야 하나

내 기준으로는 세 가지만 바꾸면 된다.

첫째, 프롬프트를 지시문이 아니라 종료 가능한 작업 명세로 써야 한다. “이거 고쳐줘”보다 “무엇이 끝인지”를 먼저 적어야 한다.

둘째, 테스트와 검증 명령을 목표 안에 자연스럽게 포함해야 한다. goal loop는 생각보다 성실하지만, 검증 기준이 빠지면 성실하게 엉뚱한 데로 간다.

셋째, 승인 지점을 설계해야 한다. 모든 걸 완전 자율로 돌리는 게 아니라, 비용이 큰 수정이나 파괴적 변경은 어디서 멈춰 세울지 미리 정하는 편이 낫다.

결국 /goal은 개발자를 덜 일하게 만들 수도 있지만, 동시에 더 좋은 운영자로 바꾸길 요구한다. 예전엔 프롬프트 문장력을 다듬으면 됐다면, 이제는 목표 설계와 예산 관리, 검증 루프 설계가 생산성의 핵심이 된다.

김덕환 운영자가 봤을 때

김덕환처럼 혼자 여러 코드베이스와 자동화를 같이 굴리는 운영자 입장에서는 이 변화가 특히 크다. 혼자 일할수록 손은 부족하고, 반복 작업은 계속 쌓인다. 그래서 /goal의 가치는 “AI가 더 똑똑해졌다”보다 한 번 맡긴 일을 끝까지 추적하게 해줘서 운영자의 attention budget을 아껴준다는 데 있다. 대신 그만큼 목표 정의, 검증 로그, 승인 경계를 더 잘 설계해야 한다. 이제 1인 개발자의 생산성도 프롬프트 감각보다 작은 에이전트 시스템을 얼마나 잘 운영하느냐로 갈릴 가능성이 크다.