프롬프트는 소모품이 되고 검증 기준은 남는다: 루프 엔지니어링의 작동 방식
모델이 새 버전으로 바뀌면 성능은 좋아져도 기존 업무 자동화가 갑자기 어긋나는 경우가 있습니다. 예전 모델에 맞춰 세밀하게 다듬은 프롬프트가 새로운 모델의 추론 방식, 응답 길이, 검증 습관과 맞지 않기 때문입니다. 단순한 요청에도 지나치게 확인하거나 결과물을 과하게 설계하는 현상은 이런 변화를 잘 보여줍니다.
이 문제를 다루는 한 가지 접근이 루프 엔지니어링입니다. 사람이 매번 긴 프롬프트를 직접 수정하는 대신, 에이전트가 작업하고 결과를 검증받고 실패 원인을 반영해 자신의 스킬과 지시를 고치는 반복 구조를 설계하는 방식입니다. 핵심은 프롬프트를 잘 쓰는 데서 끝나지 않고, 프롬프트가 바뀌어도 유지되는 평가 기준과 개선 루프를 만드는 데 있습니다.
모델이 똑똑해져도 기존 프롬프트가 흔들리는 이유
프롬프트는 고정된 설명서처럼 보이지만 실제로는 특정 모델의 동작 특성에 맞춰진 조정값에 가깝습니다. 어떤 모델은 짧고 명확한 지시를 잘 따르고, 어떤 모델은 배경과 제약 조건을 길게 설명해야 안정적으로 움직입니다. 같은 문장을 입력해도 모델이 무엇을 중요하게 판단하는지에 따라 결과가 달라질 수 있습니다.
특히 성능이 높은 모델은 사용자가 명시하지 않은 부분까지 추론해 작업 범위를 넓히기도 합니다. 요청한 문서만 만들면 되는데 자료를 추가로 검증하거나, 필요 이상으로 복잡한 구조를 설계하거나, 여러 예외를 가정하는 식입니다. 이것은 모델이 덜 똑똑해서 생기는 문제가 아니라 ‘똑똑하게 처리하는 방식’과 사용자가 원하는 작업 방식이 다르기 때문에 발생합니다.
그래서 기존 프롬프트에 조건을 계속 덧붙이는 방식은 단기적으로는 효과가 있어도 모델 교체 때 다시 손봐야 합니다. 정교하게 작성한 프롬프트일수록 특정 모델의 반응을 전제로 만들어졌을 가능성이 높습니다. 모델이 바뀌면 그동안 쌓은 조정이 오히려 새로운 모델의 행동을 방해할 수도 있습니다.
루프 엔지니어링은 프롬프트 대신 개선 구조를 설계한다
루프 엔지니어링에서는 에이전트에게 모든 작업 기준을 한 번에 알려주지 않습니다. 사람은 에이전트가 작업할 수 있는 공간과 달성해야 할 목표를 정하고, 별도의 검증 장치에 결과를 판단할 기준을 둡니다. 에이전트는 기본 요청을 바탕으로 결과물을 만든 뒤 검증 결과를 확인하고, 통과하지 못한 이유를 반영해 자신이 사용할 스킬이나 작업 지시를 수정합니다.
구조를 단순화하면 다음과 같습니다.
- 사람이 목표와 작업 환경을 준비합니다.
- 에이전트가 최소한의 요청을 받고 결과물을 작성합니다.
- 검증 에이전트가 결과물을 체크리스트나 평가 기준에 따라 검사합니다.
- 실패한 항목과 그 이유가 작업 에이전트에 전달됩니다.
- 작업 에이전트가 스킬, 절차, 출력 형식을 수정합니다.
- 다시 실행해 기준을 통과할 때까지 반복합니다.
여기서 중요한 점은 검증 기준과 실행 지시를 분리하는 것입니다. 체크리스트를 작업 에이전트의 프롬프트에 그대로 넣으면, 에이전트가 처음부터 그 목록을 만족하도록 결과물을 만드는 일반적인 프롬프트가 됩니다. 반면 체크리스트를 검증 에이전트만 보게 하면 작업 에이전트는 목표를 수행하고, 결과에 대한 외부 평가를 통해 자신에게 필요한 작업 방식을 찾아가게 됩니다.
앤트로픽의 Claude Code와 관련해 보리스 체르니가 이제 클로드에 직접 프롬프트하기보다 프롬프트를 보내는 루프를 사용한다고 말한 사례, 오픈클로를 만든 피터 스타인버거가 코딩 에이전트에 직접 지시하기보다 에이전트에 프롬프트를 보내는 루프를 설계해야 한다고 말한 사례가 이 관점과 연결됩니다. 보리스 체르니가 밤사이 수천 개의 서브에이전트를 돌리고 Claude Code의 8~9할이 이 방식으로 만들어진다는 이야기도 함께 알려졌지만, 이 수치는 구체적인 조건과 측정 기준을 함께 확인할 필요가 있습니다.
포스트모템 보고서로 보는 실제 작동 예시
예를 들어 목표가 포스트모템 보고서 작성이라고 해보겠습니다. 작업 에이전트에게는 “포스트모템 보고서를 작성해줘”라고만 전달합니다. 대신 검증 에이전트에는 결과물이 만족해야 할 기준을 둡니다.
보고서가 다섯 장을 넘지 않는지, 첫 장에서 결론과 핵심 수치를 바로 확인할 수 있는지 검사합니다. 핵심 지표 세 가지는 원문 표현을 그대로 사용해야 하고, 후속 작업 목록과 담당자도 포함해야 합니다. 슬라이드의 불릿은 세 개로 제한해 정보가 과밀해지지 않도록 합니다.
작업 에이전트가 처음부터 이 기준을 알지 못한다는 점이 이 구조의 특징입니다. 첫 번째 결과물이 여섯 장이거나 담당자가 빠졌다면, 검증 에이전트는 단순히 불합격이라고만 말하지 않고 어떤 기준을 충족하지 못했는지 알려줍니다. 작업 에이전트는 이 피드백을 바탕으로 보고서 작성 스킬을 수정하고 다시 실행합니다. 이후에는 문서 작성뿐 아니라 디자인 검토까지 별도 루프로 연결할 수 있습니다.
이 방식은 한 번의 원샷 생성과 다릅니다. 원샷에서는 사람이 긴 요구사항을 한 번에 정리하고 모델이 그 지시를 따라야 합니다. 루프 방식에서는 첫 결과가 완벽하지 않아도 되며, 반복 실행을 통해 결과물과 작업 스킬이 함께 조정됩니다. 다만 반복 횟수가 늘어나면 처리 시간과 토큰 사용량이 증가하므로, 모든 업무에 무조건 적용할 필요는 없습니다.
체크리스트를 숨기는 것이 항상 더 좋은 것은 아니다
검증 기준을 작업 에이전트에게 숨긴다는 설명은 루프 엔지니어링의 핵심을 잘 보여주지만, 실무에서는 목적에 따라 공개 여부를 나눌 필요가 있습니다. 반복적인 문서 형식처럼 기준을 명확히 지켜야 하는 업무라면 작업 에이전트가 일부 제약을 알고 있는 편이 효율적일 수 있습니다. 반대로 기준을 직접 알려주면 형식만 맞추고 내용의 품질은 놓칠 수 있는 업무라면 독립적인 검증 단계가 더 유용합니다.
또 하나의 문제는 검증 기준 자체의 품질입니다. 체크리스트가 형식만 평가하면 에이전트는 형식 통과에 최적화될 수 있습니다. 예를 들어 불릿 세 개 제한은 지켰지만 중요한 원인 분석이 빠진 보고서가 나올 수 있습니다. 따라서 검증 기준에는 분량, 슬라이드 수 같은 측정 가능한 조건과 함께 사실성, 핵심 내용의 누락 여부, 원문 수치의 정확한 사용처럼 결과의 본질을 확인하는 항목도 들어가야 합니다.
검증 에이전트가 작업 에이전트와 같은 오류를 반복할 가능성도 고려해야 합니다. 중요한 보고서라면 사람의 최종 검토, 원문 대조, 수치 검산 같은 독립적인 확인 절차가 필요합니다. 루프가 있다고 해서 결과가 자동으로 정확해지는 것은 아닙니다. 루프는 개선을 자동화하는 장치이지 책임 있는 검토를 완전히 없애는 장치가 아닙니다.
모델이 바뀌어도 살아남는 자산은 무엇인가
모델이 바뀔 때마다 다시 만드는 것이 프롬프트라면, 장기적으로 남겨야 할 것은 목표와 평가 기준입니다. 좋은 루프를 만들려면 먼저 어떤 결과가 합격인지 설명할 수 있어야 합니다. ‘잘 작성된 보고서’처럼 추상적인 표현만으로는 에이전트가 실패 원인을 학습하기 어렵습니다. 페이지 수, 핵심 수치의 출처, 필수 항목, 담당자 표기, 불릿 수처럼 확인 가능한 조건으로 바꾸는 작업이 먼저입니다.
그다음에는 에이전트가 실제로 수정할 수 있는 작업 공간이 필요합니다. 스킬 파일, 템플릿, 참고 자료, 생성 결과, 검증 결과를 분리해 두면 무엇이 바뀌었고 개선됐는지 추적하기 쉽습니다. 매번 기존 스킬을 덮어쓰면 이전보다 나빠졌을 때 되돌리기 어렵기 때문에 버전 관리나 변경 기록도 실무적인 안전장치가 됩니다.
| 루프에 맞는 업무 | 보조로만 쓰는 편이 나은 업무 |
|---|---|
| 정해진 형식의 반복 문서 | 평가 기준이 사람마다 크게 다른 일 |
| 코드 수정과 테스트 | 한 번의 판단이 매우 중요한 일 |
| 규칙이 분명한 자료 변환 | 반복 실행 비용이 큰 일 |
| 포스트모템 보고서 | 합격 기준을 문장으로 적기 어려운 일 |
루프를 적용하기 좋은 업무는 반복성이 있고 결과 평가 기준이 비교적 분명한 작업입니다. 반대로 평가 기준이 사람마다 크게 다르거나, 한 번의 판단이 매우 중요하거나, 반복 실행 비용이 큰 업무는 처음부터 전면 자동화하기보다 검증 루프를 보조적으로 두는 편이 낫습니다.
이런 접근으로는 GEPA, Skill Opt, VPRM 스타일의 루프가 거론됩니다. 이들은 에이전트의 결과를 평가하고 작업 방식이나 스킬을 개선하는 계열의 접근으로 볼 수 있지만, 각각의 구현 방식과 평가 절차가 동일하다고 단정해서는 안 됩니다. 실제 적용 전에는 어떤 입력을 사용하고, 무엇을 평가하며, 실패 시 어떤 파일이나 지시를 수정하는지 확인해야 합니다.
새 모델을 맞이하는 방법도 달라진다
루프 엔지니어링의 관점에서 모델 교체는 기존 프롬프트를 처음부터 다시 쓰는 사건이 아닙니다. 목표와 검증 기준을 유지한 채 새 모델에게 동일한 작업을 수행하게 하고, 새 모델에 맞는 스킬을 루프 안에서 다시 찾는 과정에 가깝습니다. 이때 기존 스킬을 그대로 유지할지, 새 모델이 만든 버전을 채택할지는 검증 결과와 비용을 기준으로 판단해야 합니다.
가장 먼저 할 일은 작업 요청과 평가 기준을 섞지 않는 것입니다. 에이전트가 무엇을 해야 하는지와 결과가 합격인지 판단하는 기준을 별도 구성으로 나누면 모델이 바뀌어도 유지되는 부분이 생깁니다. 이후 대표적인 입력 몇 개를 테스트 세트로 정해 새 모델이 만든 결과를 기존 결과와 비교하면, 막연한 체감보다 변경 효과를 확인하기 쉽습니다.
모델이 똑똑해졌는데 사람이 더 바빠지는 이유는 생성 능력만 개선되고, 그 생성 능력을 업무 기준에 맞추는 구조는 그대로 남아 있기 때문입니다. 루프 엔지니어링은 이 조정 작업을 매번 사람이 직접 수행하지 않고, 목표·환경·검증·개선의 반복 과정으로 옮기려는 시도입니다. 다만 성패는 ‘프롬프트를 숨기는 것’ 자체보다 검증 기준이 얼마나 정확하고 독립적인지, 반복 비용을 감당할 수 있는지에 달려 있습니다.
