에이전트에도 테스트가 필요해요 — evaluation layer와 loop engineering

프롬프트를 개선하는 요령은 이제 꽤 알려져 있어요. XML 태그로 역할과 지침과 데이터를 구조화하고, 애매한 표현을 걷어내고, 명확하게 쓰라는 것. 저도 그렇게 고쳐요. 그런데 어느 순간 이런 질문이 남더라고요. 그렇게 고친 게 정말 좋아진 건 어떻게 알까요?

Anthropic의 The Prompting Playbook 발표(Code w/ Claude 2026, Margot van Laar)를 보면서 이 질문에 대한 답이 또렷해졌어요. 결국 좋아졌는지 확인하려면 평가(eval, 출력이 기대에 맞는지 반복해서 측정하는 테스트셋)가 있어야 한다는 거예요.

좋아졌다는 걸 무엇으로 아는가

발표에서 van Laar는 지저분해진 프롬프트를 정리해요. 웹사이트에서 복붙된 잔재를 걷어내고, 한 덩어리로 뭉쳐 있던 지침을 XML 태그로 역할·정책·톤으로 나눠요. 그러자 성능이 올라가요. 그런데 여기서 중요한 건 성능이 올랐다는 사실이 아니라, 그걸 어떻게 알았는가예요. 정리한 프롬프트로 eval을 다시 돌렸더니 통과하는 케이스가 늘었기 때문이에요.

발표 내내 출발점은 프롬프트를 손대는 게 아니라 eval을 갖추는 거예요. eval이 있어야 "이 변경이 개선과 실제로 상관있는가"를 엄밀하게 볼 수 있으니까요. 모델을 새 버전으로 바꿨을 때 잘 안 되는 이유조차 eval이 갈라줘요. 새 모델이 능력은 되는데 행동만 달라진 거라면 프롬프트로 고칠 수 있고, 능력 자체가 부족한 거라면 프롬프트를 아무리 만져도 안 돼요. 이 둘을 구분하려면 회귀를 재는 eval이 필요해요.

발표에서 좋았던 한 마디가 있어요. "프롬프트를 읽는 내가 지침과 정책과 데이터를 구분하지 못하면, 모델도 못 한다." eval도 똑같이 뒤집어 말할 수 있을 것 같아요. 이 자산이 "잘 됐다"를 내가 무엇으로 판단하는지 적어두지 못하면, 나는 사실 그 자산을 판단하지 못하고 있는 거예요.

eval에 챙겨야 할 세 가지 케이스

그럼 eval에는 뭘 넣어야 할까요. 발표에서는 세 종류 케이스를 챙기라고 해요.

• control: 항상 통과해야 하는, 모호하지 않은 기본 케이스.
• edge: 예전에 모델이 틀렸던 케이스. 같은 실수가 다시 새지 않게 가둬두는 거예요.
• constraint & refusal, escalation(제약·거절·에스컬레이션): 모델이 자기 능력의 경계를 알고, 함부로 답하지 말아야 할 때 거절하거나 사람에게 넘겨야 하는 지점.

세 번째가 특히 중요하다고 느꼈어요. 우리는 모델이 사실을 지어내는(할루시네이션) 걸 걱정하지만, 발표에서는 반대 경우도 짚어요. 모델이 가지고 있는 정보를 오히려 숨기거나, 스스로 처리하면 안 되는 걸 붙잡고 진단하려 드는 것. 어디서 멈추고 넘겨야 하는지를 eval이 붙잡아줘야 해요.

재사용할 자산에는 evaluation layer가 필요해요

여기서 제 생각이 하나 자리를 잡았어요. 에이전트든 스킬이든, 재사용할 AI 자산을 만들 때는 evaluation layer를 함께 갖춰야 한다는 거예요.

이유는 예전 개발을 떠올리면 분명해져요. 변경에 확신(confidence)을 얻으려면 테스트 케이스를 작성했잖아요. 테스트가 있어야 리팩터링을 겁내지 않고 할 수 있었어요. 에이전트도 똑같아요. 더 좋은 모델이 나오면 갈아타고, 새로운 케이스에 대응하려고 프롬프트를 덧대고, 비용 때문에 더 작은 모델로 내리기도 해요. 이 모든 변경이 사실은 회귀예요. 예전에 잘 되던 걸 여전히 잘 하는지 확인하지 않으면, 새 케이스 하나 막다가 옛 케이스 셋을 조용히 깨뜨릴 수 있어요.

그러니까 에이전트 변경에도 "테스트"가 있다면, 그게 바로 evaluation layer예요. 일반 애플리케이션의 test layer와 같은 자리에 놓이는 거예요. 다른 점이 있다면 LLM은 같은 입력에도 출력이 흔들리는 확률적 시스템이라, 회귀가 더 조용히 스며든다는 것 정도예요. 그래서 오히려 눈에 보이는 기준이 더 필요해요.

광고 서류 자동심사에서 eval은 어떤 변경에도 자신 있는 배포의 기반이 됐어요

최근에 광고 서류를 자동으로 심사하는 프로젝트를 진행했는데, 여기서 이 evaluation layer를 실제로 세워 썼어요. 문서 서류의 특정 케이스마다 OCR을 돌리고, 거기서 의도한 대로 출력이 잘 나오는지를 확인하는 방식이었어요.

핵심은 순서였어요. eval 케이스를 미리 자산으로 갖춰두고, 변경사항을 배포하기 전에 그 케이스들을 잘 통과하는지 먼저 확인해요. 한 번 실행해보고 "잘 동작하네"로 끝내는 게 아니라, 변경이 생길 때마다 같은 eval을 다시 돌리는 거예요. 이렇게 해두면 프롬프트를 바꾸든 처리 방식을 바꾸든, 통과 여부를 눈으로 보면서 나아갈 수 있어요. 변경에 대한 확신이 감이 아니라 자산에서 나와요.

그리고 loop engineering으로 이어져요

여기서 한 발 더 나가면 요즘 회자되는 loop engineering(observe → reason → act → evaluate를 목표에 닿을 때까지 반복하는 자기주도 루프를 설계하는 것)과 만나요. 저는 이 개념의 무게 중심이 "자동으로 반복한다"가 아니라, 무엇을 기준으로 반복을 멈출지에 있다고 생각해요. evaluation이 완전히 통과할 때까지 작업하게 만드는 것, 그게 loop engineering의 뼈대예요.

발표의 두 번째 예시가 이걸 그대로 보여줘요. shift scheduling 에이전트를 만들면서, 하나의 큰 프롬프트로 다 시키는 대신 세 개의 작은 프롬프트로 쪼개요.

generate evaluate repair loop — generator가 초안을 만들고, 별도 프롬프트가 위반 사항을 근거와 함께 보고(evaluate)하고, 세 번째 repair 프롬프트가 그 위반을 받아 표적 수정을 해요.

이 방식이 하나의 큰 프롬프트보다 토큰도 지연도 더 낮으면서 테스트 케이스를 전부 통과해요. 여기서 축은 evaluate예요. 무엇이 위반인지, 그걸 어떻게 판정하는지가 정해져 있으니까 generate와 repair가 그 기준을 향해 돌 수 있는 거예요.

결국 자동으로 개선하는 루프를 만들 수 있느냐는, 명세(무엇이 맞는지)와 평가 기준·방법(그걸 어떻게 확인하는지)을 얼마나 또렷하게 적어뒀느냐에 달려 있어요. 루프의 품질은 eval의 품질에 수렴해요. 평가가 흐릿하면 아무리 많이 돌려도 흐릿한 곳으로 가고, 평가가 또렷하면 그 지점까지 스스로 기어올라가요.

정리하면

예전 개발에서 변경에 확신을 주던 게 테스트 케이스였다면, 에이전트에서 그 자리에 놓이는 건 evaluation layer예요. 그리고 그 eval은 control, edge, constraint & refusal·escalation 세 케이스를 챙길 때 제 몫을 해요.

이게 지금은 배포 전에 회귀를 잡아주는 안전장치지만, 조금 더 멀리 보면 에이전트 엔지니어링에서 loop engineering과 아주 가깝게 이어져요. 평가 기준을 또렷하게 세워두는 일이, 나중에 그 기준을 향해 스스로 개선하는 루프를 세우는 첫 단추가 되니까요. 그래서 요즘은 순서를 바꿔요. 무엇이 좋아졌다고 말하기 전에, 무엇을 기준으로 좋아졌다고 말할 건지를 먼저 갖추려고 해요.