Eval 공부 #4 — HITL 에이전트 회귀 테스트, 통과했는데 원인이 틀린 경우

Eval 공부 #3 — 에이전트 도구 선택 · 멀티스텝 에 이어 오늘은 HITL 에이전트 회귀 테스트. 지난번 만든 HITL 에이전트 를 대상으로.

Table of contents

왜 이번엔 단위 테스트 스타일인가

지난 편에서는 (질문 · 기대 도구 · 기대 인자) 테스트셋으로 채점했다. 이번은 다르게, 각 테스트 함수에 “어떤 행위가 있어야 통과” 를 직접 적어두는 단위 테스트 형태. 테스트셋을 따로 두지 않았다.

이유: HITL 은 행동 시나리오 자체가 검증 대상이다. “이 질문이 들어왔을 때 이 도구를 골라야 함” 이 아니라 “위험 도구를 부르려 할 때 중단점에서 멈춰야 함” 을 확인해야 한다. 시나리오형 검증이라 단위 테스트가 자연스럽다.

회귀 테스트 3축

이번에 만든 함정 회귀 테스트:

1. 위험 도구 → 중단점 진입 확인 — 사람이 y/n 을 누르는 게 아니라 중단점 상태를 직접 검사 하는 식으로
2. 멀티턴 → 매 턴 LLM 응답 확인 — 대화가 이어질 때 매번 LLM 이 응답하는지
3. 안전 도구 → 위험 분류 안 됨 확인 — safe 도구는 그냥 바로 실행하는지

sys.exit(1) 는 왜 필요한가

회귀 테스트가 실패했을 때 sys.exit(1) 로 종료 코드를 뱉는다. 처음에는 왜 있어야 하는지 이해가 안 갔다.

사람 눈으로만 보면 “통과했으면 진행, 실패했으면 멈춤” 인데 왜 굳이 코드로?

정답은 자동화 — CI/CD 파이프라인 같은 시스템이 이 스크립트를 돌릴 때 종료 코드로 성공/실패를 판단 한다. exit 0 = pass, exit ≠ 0 = fail. 파이프라인은 사람이 아니니까 콘솔 로그를 못 읽는다.

1차 실행 — 3/3 통과, 그런데 이게 정답이 아니다

3/3 통과. 모든 함정 방어 유지됨.

그런데 오히려 실패를 예상하고 돌린 것 이라서 통과한 게 문제가 됐다.

이유 — 지난번 HITL 에이전트 만들 때 문제였던 “명확한 의도 확인 후 호출” 이라는 시스템 프롬프트가 지운 줄 알았는데 남아있었다. 이 프롬프트 때문에 LLM 이 자체 방어기제로 매번 확인 을 하고 있었고, 그래서 우리 HITL 로직이 없어도 위험 도구를 부르지 않는 상태.

즉:

테스트는 통과했지만, 통과의 원인이 우리 HITL 로직이 아니라 LLM 프롬프트의 부작용.

이걸 “eval 통과” 로 넘기면 나중에 프롬프트를 바꾸는 순간 방어가 뚫린다.

2차 — 삭제 케이스로 도발

프롬프트 방어가 걷혀도 우리 HITL 이 진짜로 잡는지 확인하려고, “삭제” 를 명시적으로 요구하는 케이스로 바꿔 다시 실행.

테스트 1 FAIL. next=('execute_tools',) — 즉 다음 스텝이 도구 실행으로 잡혀있고 실제 중단은 안 됨. 우리 HITL 안전장치가 작동 안 함.

원인 추정: 문제의 프롬프트가 여전히 LLM 을 자체 방어 모드로 몰아넣어서 LLM 이 자체 확인만 하고 우리 로직은 우회. 함정 재발.

3차 — 문제 프롬프트 제거 → 멀티스텝 확장

“명확한 의도 확인 후 호출” 문구를 프롬프트에서 뺐다. 그런데 여전히 실패:

이번 실패 양상은 다르다 — LLM 이 아예 도구를 안 부르고 텍스트로만 안내. get_user_info 는 부르는데 위험 도구 (delete_user) 는 안 부르고 “이 사용자를 정말 삭제하시겠습니까?” 같은 문구를 그냥 마지막 메시지로 뱉음.

즉 프롬프트에 다른 방어 문구 (사용자 ID 정확히 알고 있을 때만 수정/삭제) 가 남아있어서 여전히 LLM 이 도구 호출을 회피.

4차 — 프롬프트 최소화 → 진짜 통과

프롬프트를 완전히 단순화:

• Before: 사용자 ID 정확히 알고 있을 때만 수정/삭제
• After: 사용자가 요청한 작업에 맞는 도구를 호출하세요

이번엔 진짜 통과 — 위험 도구 delete_user 에서 정확히 중단 (HITL 로직이 작동한 것). 종료 코드 0 확인. 이제 우리 안전장치가 실제로 위험을 잡는다.

Eval 도구의 지속적 가치

의도대로 동작하는 eval 을 한 번 만들어두면, 다음에 모델을 바꾸거나 벡터 DB 를 바꿔도 이 회귀 셋으로 바로 재검증 이 가능하다. 이게 자동화 회귀 테스트의 핵심 이득 — 시간이 지날수록 재활용 이자가 커진다.

회고

HITL eval 에서 잡은 감각 3가지:

1. Eval 통과 = 안전 신호가 아니다 — “무엇 때문에 통과했는지” 원인 검증이 진짜 안전. 프롬프트 부작용이 방어를 대신하고 있는 상태로 통과했다면, 프롬프트를 바꾸는 순간 방어가 뚫린다. 원인 없는 통과는 통과가 아니다.
2. 회귀 테스트는 실패 시나리오에서 시작하는 게 낫다 — 실패를 예상하고 돌려야 통과했을 때 그게 진짜 통과인지 의심하게 된다. 성공을 예상하고 돌리면 통과 원인을 파헤치지 않게 된다.
3. 프롬프트는 조건이 많아질수록 도구 호출이 회피된다 — “언제 도구를 부르면 안 되는지” 를 많이 적을수록 LLM 이 안 부르는 쪽으로 기운다. 도구 호출 로직은 최소한의 프롬프트 + 별도 안전장치 (HITL 같은 것) 조합이 안정적.

LLM 공부 시리즈 잠시 정리

원래는 파인튜닝 · LoRA · 프로덕션 배포 · 관찰가능성 등으로 계속 이어가려 했지만, 프로덕션 배포 쪽은 백엔드 기반이 두터워진 뒤 이해가 잘 될 것 같다. LLM 공부는 여기서 잠시 쉬고, 백엔드 공부 (자바 → Spring Boot) 를 매듭짓고 돌아올 예정.

지금까지의 LLM 공부 궤적은 LLM 공부 시리즈 에 정리되어 있다.

더 공부해볼 것

1. HITL 회귀 테스트 패턴 심화

• langgraph.checkpoint 를 활용한 상태 스냅샷 검증
• 실제 사람이 y/n 을 누르는 대신 자동 응답 목 (mock) 만들기
• 여러 개의 중단점을 순서대로 통과하는 시나리오 회귀

2. 안전장치 계층화

• LLM 자체 방어 (프롬프트) vs 시스템 안전장치 (HITL/중단점) 의 역할 분리
• 어느 쪽에 무엇을 맡길지의 판단 기준
• 두 층이 동시에 있을 때 서로를 무력화하지 않도록 하는 설계

3. 회귀 테스트 CI 통합

• GitHub Actions 로 python hitl_regression_test.py 를 매 커밋 실행
• 실패 시 PR 머지 차단
• 참고: LangSmith Evaluations CI 예제

4. 파인튜닝 vs 프롬프트 엔지니어링

• 언제 프롬프트로 해결하고 언제 파인튜닝으로 넘어가는가
• LoRA · QLoRA — 경량 파인튜닝 방식
• 파인튜닝 후에도 여전히 프롬프트 엔지니어링이 필요한가

5. LLM 관찰가능성

• LangSmith · Langfuse · Traceloop 비교 (궤적 추적 · 비용 · 지연 · eval 통합)
• 프로덕션에서 실제로 어떤 지표를 대시보드에 올리는가
• 이건 백엔드 공부 마치고 돌아왔을 때 이어서