AI 자율성은 종료조건에서 시작된다

사람들은 AI Agent의 자율성을 얼마나 오래 혼자 일할 수 있는지로 평가한다. 한 시간, 네 시간, 밤새, 며칠. 그러나 오래 움직이는 능력만으로는 좋은 Agent가 되지 않는다. 잘못된 방향으로 오래 달리는 시스템은 더 비싼 오류일 뿐이다.

Codex의 Goal이 흥미로운 이유도 “자는 동안 AI가 일한다”는 장면 때문만은 아니다. 더 중요한 변화는 사용자가 다음 지시를 계속 내리는 대신, 무엇이 완료인지 판정할 계약을 먼저 설계한다는 데 있다.

프롬프트의 시대에는 일을 잘게 나눠 “이것을 해줘”라고 말했다. Goal의 시대에는 “어떤 상태가 참이 될 때까지, 무엇으로 확인하면서, 무엇을 훼손하지 않고 움직일 것인가”를 말한다.

프롬프트는 다음 행동을, Goal은 최종 상태를 지정한다

일반 프롬프트는 한 번의 행동에 적합하다. 파일을 설명하고, 작은 버그를 고치고, 문장을 다듬고, 테스트 하나를 추가한다. 요청을 처리한 AI는 결과를 보고하고 멈춘다.

Goal은 경로가 아직 확정되지 않은 일에 적합하다. 성능을 측정하고, 병목을 찾고, 수정하고, 다시 측정했는데 목표에 못 미치면 다음 후보를 찾는다. 올바른 다음 행동이 직전 결과에 따라 달라지는 일이다.

OpenAI의 공식 설명은 이를 간단히 구분한다. 프롬프트는 “다음 일을 하라”고 말하고, Goal은 “이 결과가 참이 될 때까지 계속하라”고 말한다. Goal이 활성화되면 Codex는 작업 뒤의 증거를 확인하고, 완료되지 않았다면 최신 상태에서 다음 유용한 행동을 고를 수 있다.

여기서 핵심 단어는 ‘계속’이 아니라 ‘참’이다. 무엇이 참이 되어야 하는지 측정할 수 없다면 반복은 진전인지 표류인지 구분할 수 없다.

좋은 Goal은 여섯 부분의 완료 계약이다

공식 가이드는 강한 Goal이 보통 여섯 가지를 정의한다고 설명한다. 원하는 결과, 이를 증명할 검증 표면, 유지해야 할 제약, 사용할 수 있는 파일·도구·데이터의 범위, 매 시도 뒤 다음 행동을 고르는 방식, 더 이상 방어 가능한 경로가 없을 때의 중단 조건이다.

“성능을 개선하라”는 Goal이 약한 이유는 AI의 능력이 부족해서가 아니다. 개선이 무엇인지, 어느 수치에서 끝나는지, 속도를 얻는 대신 무엇을 망가뜨리면 안 되는지 적혀 있지 않기 때문이다.

반대로 “checkout benchmark의 p95를 120ms 아래로 낮추고 correctness suite를 통과시켜라”는 요청은 종료선을 만든다. 속도가 180ms에서 135ms로 줄어도 끝이 아니다. 110ms가 됐지만 정확성 테스트가 깨져도 끝이 아니다. 벤치마크를 실행할 수 없다면 성공이 아니라 차단 상태다.

AI의 자율성은 이 계약 안에서만 유용해진다. 결과가 목표를 만족하는지, 증거가 이를 지지하는지, 제약이 보존됐는지를 매번 비교할 수 있기 때문이다.

밤새 돌아간다는 말에는 비용과 권한이 빠져 있다

Lenny’s Newsletter의 Claire Vo 인터뷰는 Goal의 매력을 극적으로 보여준다. Sentry 오류를 줄이고, 3,900개 이메일을 68개로 정리하고, 오래된 Linear 작업을 분류한 사례가 등장한다. 이메일 정리에는 약 네 시간과 600만 토큰이 들었다고 한다.

이 사례는 생산성 자랑보다 운영 경고로 읽는 편이 유익하다. 장시간 자율 작업은 공짜 노동이 아니다. 토큰과 컴퓨팅 비용을 쓰고, 이메일과 이슈 트래커에 접근하며, 경우에 따라 외부 상태를 바꾼다. 시간을 위임할수록 비용 한도와 권한 범위도 함께 위임한다.

따라서 좋은 Goal은 성과 지표만 적지 않는다. 어떤 메일을 지울 수 있는지, 어떤 라벨은 보존해야 하는지, 외부 메시지는 보낼 수 없는지, 몇 회 또는 얼마의 예산 뒤 멈출지까지 포함해야 한다. “깨끗하게 만들어라”는 종료선도 위험하고 권한 경계도 없다.

자율성을 키우는 일은 확인을 모두 없애는 일이 아니다. 되돌릴 수 있는 내부 작업은 넓게 맡기고, 결제·발행·메시지 전송·프로덕션 변경처럼 결과가 외부로 퍼지는 지점은 좁게 통제하는 일이다.

완료 증거가 없으면 Agent는 연극을 한다

AI는 그럴듯한 진행 보고를 만들 수 있다. 코드를 읽었고, 문제를 찾았고, 수정했고, 좋아졌다고 설명한다. 하지만 테스트 결과, 벤치마크 수치, 생성된 파일, 외부 시스템의 read-back이 없다면 이것은 완료가 아니라 완료 서사다.

Goal의 진짜 가치는 Agent가 계속 일한다는 데 있지 않다. “아마 됐을 것”을 “증거상 됐다”와 분리하도록 강제하는 데 있다.

그렇다면 인간의 역할은 지시를 덜 하는 만큼 줄어드는가.

오히려 인간의 역할은 더 앞쪽으로 이동한다. 매 단계의 손놀림을 지시하는 대신, 성공과 실패와 차단을 구분하는 판정 체계를 만든다.

관리자는 작업을 배분하는 사람이 아니라 판정 기준을 설계하는 사람이 된다

기존 위임은 대개 절차 중심이었다. 이 파일을 열고, 이 목록을 보고, 이 순서대로 처리하라고 말했다. Agent가 충분히 많은 도구를 다룰 수 있게 되면 절차를 모두 미리 적는 방식은 병목이 된다. 현장에서 새 사실을 발견해도 정해진 순서밖으로 나가기 어렵기 때문이다.

Goal 기반 위임은 결과와 판정 기준을 고정하고 경로는 열어둔다. 무엇을 달성할지와 어떤 증거를 믿을지는 인간이 정한다. 어떤 로그부터 볼지, 어떤 가설을 먼저 시험할지, 실패 뒤 무엇을 시도할지는 Agent가 고른다.

이 분업은 인간이 문제를 덜 이해해도 된다는 뜻이 아니다. 좋은 종료선을 만들려면 오히려 시스템의 중요한 속성을 알아야 한다. 속도만 높이면 되는지, 정확성과 비용과 보안 가운데 무엇을 함께 지켜야 하는지, 어느 데이터가 정본인지, 어떤 변화가 되돌릴 수 없는지 알아야 한다.

AI가 실행을 싸게 만들수록 무엇을 최적화할지 잘못 고르는 비용은 커진다. 방향이 틀린 자동화는 인간보다 더 빠르게 잘못된 상태를 대량 생산한다.

증거는 하나가 아니라 계층으로 설계해야 한다

모든 완료가 테스트 한 줄로 판정되지는 않는다. 코드에는 테스트가 있고 성능에는 벤치마크가 있지만, 연구·정리·운영 작업에는 불완전한 증거가 섞인다.

이때 성공과 실패의 이분법만 두면 Agent는 둘 중 하나를 과장한다. 부분 재현을 완전 재현으로 부르거나, 일부 자료가 없다는 이유로 유용한 결과 전체를 실패로 처리한다.

공식 Goal 가이드의 연구 사례는 이를 주장별 원장으로 해결한다. 무엇을 확인했는지, 어떤 경로로 확인했는지, 증거 표면은 무엇인지, 결과가 정확한 재현인지 근사치인지, 무엇이 여전히 불확실한지 분리한다.

실무에서도 완료 상태는 최소한 네 층으로 나눌 수 있다. 직접 검증된 결과, 대리 지표로만 지지된 결과, 자료 부족으로 막힌 주장, 아직 시도하지 않은 범위다. 이 구분이 있어야 Agent가 솔직하게 오래 일할 수 있다.

중단 조건은 실패가 아니라 시스템의 브레이크다

좋은 Goal에는 “될 때까지”뿐 아니라 “언제 멈출지”가 있다. 예산을 소진했을 때, 같은 차단 원인이 반복될 때, 허용된 범위 안에서 더 시도할 경로가 없을 때, 사용자 판단이 없으면 다음 행동의 위험이 급격히 커질 때 멈춘다.

중단 조건이 없으면 끈기는 무한 반복으로 바뀐다. 같은 테스트를 다시 돌리고, 같은 API 오류를 다른 표현으로 해석하고, 성과가 없는 작은 수정만 쌓을 수 있다. 긴 실행에서는 한 번의 잘못보다 멈추지 않는 잘못이 더 비싸다.

예산 한도도 완료와 다르다. 토큰을 다 썼다고 목표를 달성한 것이 아니다. 이때 Agent는 성공을 선언하는 대신 지금까지 바뀐 것, 확인된 증거, 남은 차단, 다음에 필요한 입력을 남겨야 한다. 그래야 다음 실행이 처음부터 다시 시작되지 않는다.

Goal에 맞지 않는 일도 분명하다

한 줄 수정, 짧은 설명, 간단한 리뷰처럼 한 번에 끝나는 일에는 Goal이 과하다. “코드를 더 좋게 만들어라”, “메일함을 완벽하게 정리하라”처럼 완료선을 합의할 수 없는 일에도 부적합하다.

Goal은 큰 일의 동의어가 아니다. 경로는 불확실하지만 종료 상태는 검증 가능한 일의 도구다. 반대로 경로도 짧고 결과도 분명하면 일반 프롬프트가 낫다. 경로와 결과가 모두 모호하면 먼저 문제를 정의해야 한다.

이 구분 없이 모든 일을 Goal로 만들면 관리 오버헤드가 늘고, 단순한 작업까지 장시간 루프로 변한다. 자율 실행은 많이 쓰는 기술이 아니라 맞는 곳에만 쓰는 기술이다.

프롬프트 엔지니어링 다음은 완료 엔지니어링이다

지금까지 사람들은 AI에게 어떻게 말해야 원하는 답이 나오는지 배웠다. 역할을 주고, 맥락을 넣고, 형식을 지정하고, 예시를 제공했다. 이것은 한 번의 출력 품질을 높이는 기술이었다.

Agent가 여러 시간에 걸쳐 현실을 바꾸기 시작하면 더 중요한 질문이 생긴다. 어떤 증거가 결과를 참이라고 만들고, 어떤 제약이 함께 보존되어야 하며, 어느 지점에서 더 진행하지 말아야 하는가.

좋은 Goal을 쓰는 사람은 AI에게 일을 많이 시키는 사람이 아니다. 성공을 측정할 표면, 실패를 숨기지 않는 상태, 권한과 비용의 경계를 설계하는 사람이다.

AI의 자율성이 커질수록 인간의 핵심 능력은 지시문 작성에서 완료 판정으로 이동한다. 프롬프트는 일을 시작시키지만, 종료조건은 일을 끝나게 한다.

주요 출처: OpenAI, Using Goals in Codex: Persistent Objectives for Long-Running Work; Lenny’s Newsletter, Claire Vo 인터뷰 The Codex feature that works while you sleep. Goal의 기능·수명주기·여섯 구성요소는 OpenAI 공식 문서를 기준으로 했습니다. Sentry·이메일·Linear 사례와 사용량은 인터뷰 당사자의 사례이며 독립 벤치마크로 일반화하지 않았습니다.