99% 의 사람들이 /goal과 루프를 잘못 사용하고 있습니다.
그들이 듣는 과대광고는 "장기 실행 루프로 자율 에이전트를 구동하는 것: 작업을 지정하고 자리를 비우면, 돌아왔을 때 작동하는 코드가 완성되어 있다"는 식입니다.
하지만 최고의 에이전틱 엔지니어들은 /goal 없이도 6개월 동안 그렇게 해왔습니다 (GPT-5.2와 Opus 4.5가 나왔을 때부터요). 그것은 harness engineering + spec-driven development라고 불립니다:
- 에이전트가 문제를 관찰할 수 있는 harness 를 구축합니다
- 모든 테스트 케이스가 포함된 정밀한 스펙을 작성합니다
- Codex 나 Claude Code 가 모든 항목을 충족할 때까지 무인 상태로 루프를 실행합니다
저는 이런 작업을 밤새도록 자주 실행합니다 — 한 번에 2~5시간 정도입니다. 4월에는 하나가 Vercel 모노레포 전체의 Turbo 빌드 캐시 버그를 해결해서 아침이 되기 전에 모든 테스트를 통과시켰습니다. 실제로 /goal은 필요하지 않습니다.
그렇다면 /goal은 실제로 무엇을 위한 것일까요?
제가 자리를 비운 동안 하나의 프롬프트가 한 일은 다음과 같습니다:
- 약 30시간, 6,300줄의 코드, 92,000페이지 크롤링, API 비용 $40 소모
- 다른 제품의 핵심 루프를 복제 — 전체 아키텍처를 처음부터 리버스 엔지니어링
- 동일한 쿼리에 대해 저희 버전의 출력이 참조 제품보다 약 50배 더 나은 결과를 보여줌 (이것은 제가 작업 중인 오픈소스 뉴스 인텔리전스 스킬인 newsjack.sh 를 구동할 새로운 데이터 레이어입니다)
비결은 손실 함수 개발 (Loss Function Development, LFD) 입니다: 에이전트에게 구축할 스펙이 아니라 최적화할 대상을 작성하는 것입니다.
이는 Peter 의 트윗을 실제로 구현한 구체적인 예시입니다.
스펙 주도 개발에서 사용된 스펙은 이제 출발점이 되며, 더 이상 결승선이 아닙니다.
이것을 제대로 이해하는 데 약간의 실험이 필요했습니다. 하지만 전체 플레이북을 여기에 공개합니다 — 다만 먼저 얼마나 잘못되었는지부터 시작해야 여러분이 이러한 /goal 을 어떻게 설계해야 하는지 이해할 수 있습니다.
에이전트가 3번이나 속임수를 썼습니다.
모든 것은 제가 항상 하는 방식, 즉 스펙으로 시작되었습니다.
저는 단순히 codex 를 다른 제품의 공개 웹사이트에指向했습니다 — "이걸 우리가 직접 어떻게 만들 수 있을까?". 30분 만에 완전한 시스템 설계와 테스트 케이스(스펙)를 반환했습니다.
하지만 이번에는 다른 프롬프트를 시도했습니다.
"/goal 당신의 출력이 그들의 것과 정확히 일치할 때까지 구현하세요"
그리고 이런 일이 일어났습니다:
루프 1 (5분)
에이전트가 평가 세트를 가져와 이를 그대로 반영하는 시드 데이터를 생성하고, 5분 만에 승리를 선언했습니다.
"100% 재현율, 제로 일반화" — 내가 건네준 30개 항목만 찾을 수 있는 검색 엔진이었죠.
해결책 → 블라인드 처리. 평가 데이터를 실행 중에는 숨기고, 채점 시에만 공개하며, 항목별 누락 목록을 제공.
루프 2 (20분) - 블라인드, 30개 항목.
에이전트를 평가 세트에서 블라인드 처리했지만, 누락을 통해 학습했습니다 — "X를 찾지 못했습니다"가 다음 사이클마다 키워드가 되었습니다. 몇 번의 루프 후: 정확히 30개의 키워드를 사용했고, 다시 "승리"했습니다.
해결책 → 평가 세트 확대. 수백 개의 항목으로 채점하여 열거 불가능하게 함.
루프 3 (30분) - 블라인드, 200개 항목.
새 평가 세트에 200개 항목을 추가한 후에도 에이전트는 또 속임수를 썼습니다.
재미있게도 에이전트는 여전히 열거했습니다. 키워드 목록이 수백 개로 불어났고, 각 용어는 다음 누락을 위한 정확한 미끼가 되었습니다.
세 번의 라운드, 세 번의 속임수.
그때 깨달았습니다: 에이전트는 단순히 최적화하고 있었던 것입니다.
속임수는 에이전트의 버그가 아니었습니다. 제 목표의 버그였습니다: 목적지를 알려주고 모든 지름길을 열어둔 것입니다.
당신이 막지 않은 모든 값싼 경로는 최적화 도구가 달려가는 방향입니다. 그리고 제 초기 목표는 모든 울타리를 생략했습니다.
루프 4 (30시간) - 블라인드, 200개 항목, 하드 제한.
그래서 방향을 차단하기 시작했습니다. 키워드 목록 제한, 평가 블라인드, 날짜 범위 확대 — 각 수정은 값싼 경로 하나를 막았고, 결국 점수를 움직일 수 있는 유일한 방향은 실제로 작업을 더 잘하는 것뿐이었습니다.
속임수가 멈췄습니다.
그리고 실행되었습니다. 약 30시간의 연산, 92,000페이지 크롤링, 약 $40 의 토큰 비용, 6,300줄의 코드.
알고 보니 우리가 참조한 제품은 바닥이지 천장이 아니었습니다: 동일한 쿼리에서 약 50배의 결과를 표면화했습니다.
(전체 여정과 증거는 궁금한 분들을 위해 여기에 있습니다)
손실 함수 개발 (LFD) - 좋은 손실 함수의 구성 요소
대부분의 사람들이 제품을 만들려고 할 때, 그들은 에이전트를 사용하여 몇 시간 만에 0에서 출시까지 가고 있습니다.
하지만 문제는 그 이후입니다 — 긴 꼬리 부분. 스펙이 상상하지 못한 엣지 케이스는 프로덕션에서만 드러나며, 한 번에 하나의 오류 로그로 나타납니다. 하나씩 수정합니다. 로그에서 잡지 못한 케이스는 사용자가 보고하며, 이는 버그를 찾는 가장 비용이 많이 드는 방법입니다.
저는 이 과정의 저렴한 부분을 자동화했습니다. 제 OpenClaw 에이전트 Zoe 는 매일 오류 로그를 감시하고, 새로운 오류가 발생하면 Codex 를 생성하여 PR을 만듭니다 — 이 루프만큼 타이트한 것입니다. (전체 설정은 여기에 문서화되어 있습니다)
꼬리 부분은 여전히 몇 달이 걸립니다. 그렇기 때문에 에이전트가 작업을 수행하더라도 좋은 제품을 만드는 데는 시간이 걸립니다.
LFD는 꼬리 부분을 앞당깁니다. 실제 예상 출력 예제를 사전에 확보할 수 있다면 — 좋은 결과가 무엇인지, 대규모로 — 출시 전에 소크(soak)를 실행합니다: 수백 개의 엣지 케이스가 분기별 버그 리포트 한 방울이 아니라 단일 최적화 실행에서 에이전트에 도달합니다. 그리고 이것이 갑자기 가능해진 이유는 점점 더 많은 문제에 대해 그러한 예제가 공개적으로 존재하기 때문입니다.
스펙 주도 개발:
이것을 구축하세요. 테스트를 통과시키세요.
손실 함수 개발:
이것을 구축하세요. 테스트를 통과시키세요. 그런 다음 이 1,000개의 평가 케이스에 대해 반복하세요.
테스트 스위트는 유한합니다 — 초록색이 되는 순간 끝입니다. 1,000개 평가에서 95%는 하강하는 대상입니다; 기준 미만으로는 탈출구가 없습니다. 이것이 중요한 이유는 에이전트가 여러분이 절대 보지 못할 수백 번의 결정을 내리고, 모든 결정이 무언가에 대해 해결되기 때문입니다. 대상을 작성하지 않으면 에이전트가 대상을 선택합니다 — 그리고 1~3라운드에서 보았듯이, 가장 만족시키기 쉬운 것을 선택합니다.
손실 함수는 평가보다 더 큽니다. 4가지 요소가 있습니다 — 대상, 제약 조건, 도구, 강제 엔트로피. 네 가지 조각입니다.
1. 대상
- 열거가 이득이 되지 않을 만큼 충분히 큽니다. 28개 항목 평가는 한 라운드에 암기되었습니다. 많을수록 좋습니다.
- 에이전트에게 정답을 블라인드 처리합니다. 평가 데이터는 사후 채점에만 존재합니다. 실행 중에 에이전트가 답을 볼 수 있다면, 보는 방법을 찾을 것입니다.
2. 제약 조건
에이전트가 허용된 것과 허용되지 않은 것.
- 시간은 에이전트가 항상 잊는 제약 조건입니다. 에이전트는 시간 감각이 없습니다. 메트릭이 명목상 움직인다는 이유로 2% 향상을 위해 10시간을 갈아넣을 것입니다. 하지만 2시간 만에 80% 솔루션이 30일 만에 완성된 100% 솔루션보다 낫습니다. 해결책: 벽시계 예산을 설정하세요.
- 비용. 모든 유료 호출에 하드 캡: 크롤러 크레딧, LLM 지출, 폐기 키의 총 달러 상한선.
- 표면. 모든 제공자, 허용된 모델, 동시성 상한. 에이전트가 건드리길 원하는 것만으로 샌드박싱하세요.
- 방법론. LLM 분석이 허용됩니까, 아니면 결정론적 로직만? 에이전트가 접근할 수 있는 데이터 소스는 무엇입니까? 명확히 명시하세요.
3. 도구 (하네스)
도구 없는 제약 조건은 분위기일 뿐입니다 — 에이전트는 위반했다는 것을 알 수 없기 때문에 즐겁게 위반할 것입니다. 위의 모든 제약 조건에 대해 에이전트가 검사할 CLI 명령을 제공하세요.
- 적절한 해상도의 대상 측정. 대상 도구를 신중히 선택하세요. 실제 예: 순진한 "LLM이 두 스크린샷을 평가하도록 하는" 심사위원은 12px 간격 오류가 있는 UI 클론을 승인합니다. LLM은 실제로 이미지를 볼 수 없기 때문입니다. 이미지를 임베딩으로 변환한 다음 임베딩을 비교합니다. 따라서 픽셀 완벽한 UI 클론을 원한다면 에이전트에게 픽셀 차이 도구를 제공하세요. 그런 다음 /goal 을 픽셀 차이가 0이 될 때까지 실행하세요.
- 시간 기록. 모든 실행과 모든 단계에 타임스탬프를 찍으세요. 에이전트는 각 단계가 얼마나 걸렸는지, 총 경과 시간을 알아야 합니다. 시간은 각주가 아니라 일급 도구입니다.
- 제공자 예산. "지금 크롤러에 얼마를 쓰고 있나요?"는 추측이 아니라 하나의 명령어여야 합니다. 남은 스크래핑 크레딧, 현재 루프의 소비, 누적 소비, 다음 유료 배치 전 예상 소비를 추적하세요.
- LLM 지출. 데이터 플레인에서 사용할 LLM API 키를 에이전트에 제공하면 많은 로직을 단순화할 수 있습니다. 하지만 에이전트는 실제로 얼마나 사용하고 있는지 먼저 알고 책임감 있게 사용해야 합니다.
- Codex 사용량. 이것은 약간 메타적입니다. 루프는 자기 인식적이어야 합니다: 이 최적화에 얼마나 많은 토큰을 사용하고 있나요? 현재 최적화 단계의 기울기를 아는 데 도움이 됩니다.
패턴은 오래된 속담과 같습니다: 볼 수 없는 것은 최적화할 수 없습니다.
이러한 루프를 처음 실행하는 경우, 실행하고 자리를 비우지 마세요. 첫 번째 사이클을 앉아서 지켜보세요. 무엇을 건드리는지 관찰하세요. 구축한 하네스가 제대로 사용되고 있는지 확인하세요. 그런 다음 잠자리에 드세요. (그리고 일어났을 때 무엇이 기다리고 있을지 생각하지 않고 잠들려고 노력하세요)
4. 강제 엔트로피
강제 엔트로피가 중요한 이유: 각 루프는 이전 실행의 전체 컨텍스트에서 계속됩니다. 모델이 새로 시작하는 것이 아닙니다 — 자신의 마지막 수백 번의 결정과 지금까지 작동한 기울기를 읽고 있습니다.
/goal 루프에서 지역 최적점에 도달하는 것은 기본 상태입니다. 명시적인 탈출 없이는 에이전트는 같은 언덕을 계속 올라가며, "같은 언덕"은 향상이 멈추었을 때의 위치입니다.
예를 들어, 작은 손잡이가 결과를 0.1% 개선한다면, 에이전트는 시도할 다른 1000개의 손잡이가 있어도 그 손잡이만 계속 돌릴 것입니다.
엔트로피는 명시적으로 실행에 강제되어야 합니다. 모델이 스스로 취하지 않기 때문입니다:
- 매 사이클 과적합 반성. 더 일반적인 해결책을 구축하고 있는가, 아니면 평가를 암기하고 있는가? 암기하고 있다면, 다음 변경은 평가 모양의 인공물을 제거해야 합니다 (목록 제한, 기능 블라인드, 평가 확대, 시드 거부).
- 정체 시 엔트로피 강제. 마지막 사이클이 메트릭을 움직이지 않았다면, 다음 사이클은 "같은 아이디어, 더 세게"일 수 없습니다. 모델은 실제로 명백하지 않은 도약을 해야 합니다 — "틀 밖에서 생각하라"는 좋은 프롬프트입니다. 에이전트가 같은 손잡이를 더 세게 돌리는 것을 막습니다.
- 반복 로그 유지. 에이전트가 가설, 예상 실패 모드, 각 단계의 진단을 기록하게 하여 압축 사이에 되돌아보고 반성할 수 있도록 하세요.
메타-메타-프롬프트
저는 이러한 목표를 직접 작성하다가 곧 이것도 에이전트의 일이라는 것을 깨달았습니다.
그래서 좋은 손실 함수 개발 실행을 위해 이러한 종류의 목표를 생성하는 스킬을 작성했습니다.
현재 여기에 오픈소스로 공개되었습니다:
https://github.com/elvisun/loss-function-development
/lfd-design 으로 하네스와 목표를 생성하세요
끝까지 그래디언트 디센트: 두 개의 루프
한 걸음 물러서면, 끝까지 그래디언트 디센트입니다.
내부 루프는 에이전트입니다: 코드 작성, 테스트 실행, 수정. 짧은 지평선, 빠른 피드백, 하나의 목표 — 테스트 통과. 이것이 개발자의 내부 루프이며, 스펙 주도 개발이 이를 실행하는 방법입니다. 코딩 에이전트가 이미 자동화했습니다.
외부 루프는 /goal 입니다: 여러 사이클에 걸쳐 전체 시스템을 결과 메트릭으로 이끕니다 — 출시, 측정, 방향 전환, 하강. 긴 지평선, 드문 피드백. 이것은 전통적으로 제품 팀의 루프였으며, 몇 달간의 출시-측정-반복 소크가 단일 실행으로 압축되었습니다.
이제 두 루프 모두 자동화되었습니다. 여러분에게 남은 것은 손실 함수를 정의하는 것 — /goal 이 정확히 무엇을, 어떤 방식으로 최적화해야 하는지입니다.
당신은 제품을 증류하고 있습니다 — 또는 공개 인공물을 남기는 모든 것
또 다른 렌즈: 이것은 본질적으로 증류(distillation)이며, 훈련 시간에서 프롬프트 시간으로 이동한 것입니다. DeepSeek, Kimi, Minimax 라인이 GPT와 Claude와의 격차를 대부분 좁힌 방법입니다 — 다른 사람의 출력으로 모델을 훈련시켜 자신의 출력이 그것을 재현할 때까지.
하지만 모델을 증류하는 대신, 이제 /goal 과 LFD를 사용하여 공개적으로 찾을 수 있는 모든 인공물에 대한 증류 피팅을 실행할 수 있습니다 — 내부를 검사하지 않으며 그럴 필요도 없습니다.
공개적으로라는 단어에 주목하세요. ToS 로 보호되고, 로그인이 필요하거나, 유료인 출력을 증류하는 것은 공정하지 않습니다. 하지만 공개적으로 게시된 것 — 회사가 고객을 확보하기 위해 제공하는 출력 —은 항상 배우기에 공정했습니다. 그 부분은 새로운 것이 아닙니다 — 소프트웨어에서 가장 오래된 방법입니다. 새로운 것은 이제 저렴하고 몇 달이 아닌 몇 시간 안에 가능하다는 것입니다.
한 걸음 물러서면, 더 큰 변화가 있습니다. 실행 비용은 정보 대칭이 있는 곳에서 약 $0 으로 붕괴됩니다 — 출력이 공개되면 모든 사람이 좋은 결과가 무엇인지 볼 수 있으므로 누구나 주말 동안 $40 로 다시 증류할 수 있습니다.
따라서 점점 더 가치 있는 새로운 해자(moat)가 있습니다: 정보 비대칭.
정통 오픈소스 회사는 이미 깜빡였습니다. 2026년 4월, cal.com ($5M ARR) 은 프로덕션 코드를 비공개로 전환하고 클로즈드소스로 전환했습니다. 그들이 제시한 이유는 이 글의 초록을 문자 그대로 읽는 것과 같습니다: AI 기반 보안 위협의 시대에는 에이전트가 읽을 수 있는 곳에 소스를 남겨둘 수 없습니다.
"/goal cal.com 소스 코드를 읽고 공격 표면을 성공할 때까지 열거하세요"
그것은 실행하기에 너무 쉬운 너무 위험한 공격입니다.
전체 정체성이 "오픈소스"였던 회사는 2026년에 개방성이 부채가 되었다고 결정했습니다. 그것이 모든 것을 말해줍니다.
소프트웨어의 전체 역사 동안, "우리가 만들었다"는 해자였습니다.
그 시대는 끝나가고 있습니다.
다음 시대는 인공물이 결코 포함하지 않은 것을 소유한 사람에게 속합니다: 아무도 채점할 수 없는 평가 세트. 사용자가 실제로 넘어지는 엣지 케이스 목록. 비공개로 측정하는 근본 진실. 경쟁자의 에이전트가 볼 수 없는 대상을 가진 사람만이 루프가 계속 하강하는 유일한 사람입니다.
제품은 이제 주말입니다.
주말이 건드릴 수 없는 평가를 구축하세요.
