목표 모드

목표 모드는 프롬프트를 /goal로 시작하고 에이전트가 무엇을 하길 원하는지 지정하면 됩니다.

이렇게 하면 에이전트는 목표를 달성할 때까지 계속 반복해서 작업합니다. 다만 에이전트가 이 일을 효과적으로 수행하게 하려면, 우리가 익숙한 프롬프트 방식과는 조금 다르게 모델에게 지시해야 합니다.

일반 프롬프트는 "다음 작업을 해줘"에 가깝습니다. 목표는 "이 결과가 참이 될 때까지 계속 작업해줘"에 가깝습니다. 그래서 목표 모드에서는 지시문 자체보다 완료 조건, 검증 방법, 지켜야 할 제약이 더 중요해집니다.

목표를 쓸 때와 쓰지 않을 때

목표는 끝 상태는 분명하지만 다음 행동이 매번 달라질 수 있는 작업에 적합합니다. 성능 최적화, 불안정하게 실패하는 테스트 조사, 버그 재현, 의존성 마이그레이션, 여러 단계의 리팩터링, 벤치마크 기반 튜닝, 증거 기반 보고서 작성이 좋은 예입니다.

반대로 한 줄 수정, 짧은 설명, 단순 코드 리뷰, 한 번 답하고 멈추면 되는 질문에는 목표보다 일반 프롬프트가 낫습니다. 목표 모드는 계속 진행할 이유가 있는 작업에 써야 합니다.

명확하고 정량적인 목표 지정하기

모델 성능이 크게 좋아지면서, 많은 사람이 일상적인 작업에서 프롬프트를 꽤 느슨하게 쓰게 되었습니다. 인공지능 모델에게 만들고 싶은 것을 대략적으로만 말해도, 모델은 무엇을 해야 하고 어떻게 도달해야 하는지 꽤 잘 파악합니다.

하지만 이런 프롬프트 방식은 목표 모드에서 자주 보이는 주요 실패 원인입니다.

목표 모드는 본질적으로 반복 루프입니다. 에이전트가 몇 가지 행동을 실행하고, 그 행동을 평가하고, 평가 결과가 목표를 만족하는지 확인한 뒤, 아직 만족하지 못했다면 계속 진행하고 만족했다면 종료합니다.

핵심은 세 번째 단계, 즉 평가 결과가 목표를 만족하는지 확인하는 부분입니다. "내 코드를 더 좋게 만들어줘"처럼 모호하고 정성적인 목표를 주면 루프의 종료 상태가 충분히 정의되지 않습니다. 에이전트는 언제 목표를 달성했다고 판단하고 루프를 끝낼 수 있을까요? 어떤 코드 상태가 "더 좋은" 상태이며, 어느 정도 좋아지면 멈춰도 되는 걸까요?

이처럼 목표가 충분히 정의되지 않으면 모델은 두 가지 방식으로 실패하곤 합니다. 어떤 경우에는 몇 분만 작업하다가 너무 일찍 포기합니다. 다른 경우에는 만족할 수 없는 목표를 달성하려고 방향 없이 변경을 반복하며 끝없이 작업을 계속합니다.

"내 코드를 더 좋게 만들어줘"보다 나은 목표는 다음과 같습니다.

specific_file에 들어 있는 코드의 실행 시간을 기존 단위 테스트와 통합 테스트의 회귀 없이 20% 줄여줘.

이제 에이전트에게는 명확하고 정량적인 목표가 있습니다. 특정 파일의 코드 실행 시간을 20% 줄이는 것입니다. 동시에 단위 테스트와 통합 테스트에서 회귀가 없어야 한다는 명확한 제약도 생겼습니다.

목표가 명확하고 정량적이라면 모델 자체가 평가를 수행할 수도 있습니다. 예를 들어 문서 형식을 변환할 때 규칙들을 형식 및 스타일 규칙 체크리스트가 포함된 마크다운 파일로 추출하고, 다음과 같이 목표를 설정할 수 있습니다.

글의 원문 내용은 바꾸지 말고, 제공된 checklist.md를 기준으로 형식을 바꿔줘.

체크리스트를 제공하면 정성적인 목표를 정량적인 목표로 바꿀 수 있습니다. 에이전트는 "200개 규칙 중 200개를 모두 체크하면 목표를 완료한 것"이라고 생각하면 됩니다. 각 규칙 자체가 다소 모호하더라도, 에이전트는 목표 전체가 모호한 상태일 때보다 개별 규칙의 완료 여부를 훨씬 잘 판단할 수 있습니다.

완료한 항목을 체크리스트에서 바로 체크하라는 지시도 함께 제공하면 모델이 자신의 상태를 파일 시스템에 지속적으로 남길 수 있고, 진행 상황을 눈으로 확인할 수 있습니다.

좋은 목표의 구성 요소

좋은 목표는 긴 프롬프트가 아니라 작은 작업 계약에 가깝습니다. 다음 여섯 가지를 가능한 한 명확히 적습니다.

• 결과: 작업이 끝났을 때 무엇이 참이어야 하는지
• 검증 표면: 성공을 확인할 테스트, 벤치마크, 보고서, 산출물, 명령 출력, 원자료
• 제약: 작업 중 깨지면 안 되는 동작, API, 테스트, 문서 내용
• 범위: 사용할 수 있는 파일, 도구, 데이터, 저장소, 외부 자료
• 반복 정책: 한 번 시도한 뒤 다음 행동을 어떻게 고를지
• 차단 조건: 더 진행할 수 없을 때 무엇을 보고하고 어떤 입력이 필요하다고 말할지

다음 틀을 사용하면 목표가 흐려지는 것을 막을 수 있습니다.

/goal <원하는 최종 상태>를 <구체적인 증거>로 검증하고, <보존해야 할 제약>은 유지해줘.
사용할 수 있는 범위는 <파일, 도구, 데이터, 리소스>로 제한해줘.
각 반복 사이에는 <무엇을 기록하고 다음 행동을 어떻게 고를지>를 남겨줘.
막히거나 유효한 경로가 없으면 <시도한 경로, 수집한 증거, 차단 요인, 필요한 입력>을 보고하고 멈춰줘.

예를 들어 다음 목표는 작동하지만 아직 얇습니다.

/goal 정확성 테스트 회귀 없이 p95 지연 시간을 120ms 아래로 낮춰줘.

더 강한 목표는 검증 방법과 반복 정책을 함께 포함합니다.

/goal 결제 벤치마크로 검증했을 때 p95 지연 시간을 120ms 아래로 낮추고,
정확성 테스트 묶음은 계속 통과하게 해줘.
결제 서비스, 벤치마크 고정 데이터, 관련 테스트만 사용해줘.
각 반복마다 무엇을 바꿨는지, 벤치마크가 무엇을 보여줬는지,
다음에 시도할 가장 좋은 실험이 무엇인지 기록해줘.
벤치마크를 실행할 수 없거나 유효한 경로가 남지 않으면
시도한 경로, 수집한 증거, 차단 요인, 필요한 다음 입력을 보고하고 멈춰줘.

작업은 분명하지만 목표 문장이 잘 떠오르지 않는다면, 먼저 에이전트에게 목표 초안을 만들게 할 수 있습니다.

이 작업을 강한 /goal 문장으로 바꿔줘. 불안정하게 실패하는 결제 테스트를
증거를 가지고 고치거나, 무엇이 막고 있는지 명확히 설명할 때까지
계속 작업하게 하고 싶어.

그다음 사용자가 완료 조건, 검증 표면, 제약, 차단 조건을 검토하고 조정한 뒤 목표로 실행합니다.

피드백 루프를 촘촘하게 만들기

에이전트가 자신의 행동을 목표에 비추어 평가하려면 변경 사항을 테스트할 수 있는 장치가 필요합니다.

이 테스트를 더 빠르게 실행할 수 있고, 모델이 더 쉽게 실행하게 만들수록 모델은 목표를 향한 진행 상황에 대해 더 빠르게 피드백을 받습니다.

예를 들어 에이전트에게 머신러닝 알고리즘의 아키텍처를 개선하게 한다면, 전체 학습 실행에 쓰는 모델 크기와 데이터셋 대신 더 작은 모델 크기와 샘플링된 데이터셋에서 작업하게 하는 것이 도움이 됩니다. 그러면 프로덕션 학습 환경을 매번 사용해야 할 때보다 훨씬 빠르게 아이디어를 시험할 수 있습니다.

모델이 받는 평가 점수의 품질을 훼손하지 않는 선에서 피드백 루프를 빠르게 만들 방법을 최대한 찾아야 합니다.

활성 목표가 있을 때의 사고방식

목표가 활성화되면 에이전트는 "작업하고, 확인하고, 계속할지 완료할지 판단하는" 루프로 움직입니다. 이때 완료 판단은 에이전트의 자신감이 아니라 증거에 기대야 합니다.

테스트가 실패했다면 목표는 아직 완료되지 않은 것입니다. 벤치마크가 좋아졌지만 목표 수치에 못 미쳤다면 계속해야 합니다. 목표 수치는 달성했지만 회귀 방지 테스트가 깨졌다면 역시 완료가 아닙니다. 검증 명령 자체를 실행할 수 없다면 성공으로 처리하지 말고 차단 요인으로 보고해야 합니다.

목표는 너무 좁지도, 너무 넓지도 않아야 합니다. "결제 테스트 하나를 고쳐줘"는 실제 원인이 상위 의존성에 있을 때 지나치게 좁을 수 있습니다. "전체 시스템을 개선해줘"는 검증 표면이 없어 지나치게 넓습니다. "현재 브랜치에서 공개 API 동작을 바꾸지 않고 결제 테스트 묶음이 통과하게 해줘"처럼 감사 가능한 범위와 제약을 함께 주는 편이 낫습니다.

에이전트가 추적에 사용할 마크다운 파일 제공하기

목표 모드를 사용하면 인공지능 모델을 여러 날 동안 계속 실행하게 할 수 있습니다. 에이전트에 뛰어난 압축 기능이 내장되어 있더라도, 이렇게 긴 시간 동안 모델이 일관된 흐름을 유지하기는 매우 어렵습니다.

모든 관련 컨텍스트를 모델의 메모리에만 유지하도록 강요하기보다, 에이전트가 자신이 무엇을 하고 있는지 추적하기 위해 쓸 수 있는 마크다운 파일을 제공하는 편이 도움이 됩니다.

목표 모드에서 보통 에이전트에게 세 가지 마크다운 파일을 제공할 수 있습니다.

• PLAN.md: 에이전트가 목표를 향해 나아가며 따르려는 상위 수준의 계획을 기록합니다. 처음부터 따르길 원하는 방향이나 아이디어가 있다면 여기에 미리 적어둘 수 있습니다.
• EXPERIMENTS.md: 에이전트가 실행한 각 실험의 세부 내용을 추적하는 곳입니다. 보통 실험 제목, 시도한 내용의 짧은 설명, 결과를 담은 정돈된 목록 형태가 됩니다.
• EXPERIMENT_NOTES.md: 에이전트의 작업 메모장입니다. 여러 행동을 실행하면서 떠올린 실시간 생각을 시간순으로 기록하는 목록입니다. 이 파일이 있으면 에이전트의 사고 과정을 점검하고, 필요할 때 다른 방향으로 다시 유도할 수 있습니다.

이 세 가지 중 EXPERIMENTS.md가 가장 중요합니다. 사용자와 에이전트가 목표 달성을 위해 이전에 무엇을 시도했고, 왜 성공했거나 실패했는지 함께 검토할 수 있기 때문입니다.

조사와 연구 목표

조사나 연구 작업에서는 "성공"의 의미를 시작 전에 더 엄격하게 정해야 합니다. 정확한 재현, 부분 재구성, 대리 근거, 차단 요인을 구분하지 않으면 에이전트가 그럴듯한 산출물을 실제 검증처럼 과장할 수 있습니다.

좋은 연구 목표는 에이전트에게 다음 일을 요구합니다.

• 주장 목록을 만든다.
• 각 주장을 근거와 연결한다.
• 로컬에서 검증 가능한 부분을 구현하거나 재현한다.
• 불가능한 부분은 차단 요인으로 표시한다.
• 최종 보고서에서 확인된 주장, 보조 근거만 있는 주장, 차단된 주장, 남은 불확실성을 분리한다.

예를 들어 "논문을 재현해줘"는 약한 목표입니다. 더 나은 목표는 다음과 같습니다.

/goal 사용 가능한 논문 자료와 로컬 리소스를 바탕으로 가장 강한 증거 기반 재현을 만들어줘.
핵심 결과를 가능한 범위에서 시도하고, 출력은 검증 가능한 곳까지 검증해줘.
마지막에는 확인된 결과, 근사적으로 재구성한 결과, 정확한 재현이 막힌 주장,
남은 불확실성을 분리한 보고서를 작성해줘.

이런 목표는 에이전트가 모호한 상황에서도 계속 탐색할 수 있게 하면서, 최종 결론은 증거의 강도에 맞게 표현하도록 만듭니다.

목표를 흐리게 만들지 않기

목표는 불확실성을 숨기기 위한 장치가 아닙니다. 데이터가 없을 수 있다면 목표 안에 그렇게 적어야 합니다. 벤치마크가 불안정할 수 있다면 어떻게 다룰지 정해야 합니다. 대리 근거를 허용한다면 최종 보고서에서 어떻게 표시할지 지정해야 합니다.

결국 좋은 목표는 세 가지를 갖습니다. 오래 유지될 목적, 증거 기반 종료선, 그리고 여러 번의 조사와 시도가 필요할 수 있는 경로입니다.

명확하고 측정 가능한 목표를 설정하고, 피드백 루프를 촘촘하게 유지하고, 에이전트가 생각을 정리할 마크다운 파일을 제공하세요. 이 세 가지가 갖춰지면 에이전트는 가장 어려운 문제를 몇 시간, 때로는 며칠 동안 꾸준히 밀고 나갈 수 있습니다.

이제 루프를 실행해 보세요.