“잘 되는 것 같은데”에서 벗어나기
프롬프트를 다듬고, 도구를 붙이고, RAG를 연결하고, 에이전트 루프까지 돌려봤다. 데모에서는 멋지게 동작한다. 그런데 이걸 실제 서비스로 올리려고 하면 갑자기 막막해진다.
- ‘얼마나 잘 되는 건지 어떻게 측정할까?’
- ‘어제는 잘 됐는데 오늘 답이 이상해지면 무슨 일이 생긴 건지 어떻게 알까?’
- ‘사용자가 악의적 입력을 넣으면 어떻게 막을까?’
- ‘잘못된 판단이 큰 사고로 이어지는 걸 어떻게 방지할까?’
AI 시스템을 ‘실험에서 프로덕션으로’ 끌어올리려면 네 가지가 필요하다. 생활 언어로 풀면 이렇다.
- '시험을 쳐서 얼마나 잘하는지 숫자로 재기' (평가, Evals)
- '어떤 답이 나왔을 때 그 과정을 나중에 다시 따라가기' (실행 기록, Traces)
- '위험한 입력과 행동이 실제 피해로 이어지지 않게 막기' (안전장치, Guardrails)
- '에이전트가 스스로 점검하고 고칠 수 있는 작업 환경 만들기' (하네스, Harness)
이번 글은 이 네 가지를 하나씩 풀어본다. 영어 용어는 괄호에만 두고, 본문에서는 쉬운 말로 설명한다.
왜 AI 평가가 일반 소프트웨어 평가보다 어려운가
‘한 줄 요약: 일반 프로그램은 “정답 하나”지만 AI는 “여러 답이 가능”, 매번 결과도 조금씩 달라서 “통과/실패” 기준을 정하기 어렵다.’
일반 소프트웨어 테스트는 비교적 명확하다. add(2, 3)는 반드시 5를 돌려줘야 한다. 맞으면 통과, 틀리면 실패.
AI는 그렇지 않다.
- 같은 질문에 매번 답이 조금씩 다르게 나온다 (비결정성)
- “맞는 답”이 여러 가지일 수 있다 (“이 글 요약해줘”에 정답은 하나가 아니다)
- 부분적으로만 맞는 답도 많다 (핵심은 맞는데 형식이 틀림)
- 사용자 입력 자체가 자유 형식이라 예측 불가
그래서 AI 평가는 ‘단위 테스트’보다 ‘학교 시험’에 가깝다. 채점 기준을 먼저 정하고, 여러 문제를 풀리고, 점수를 매기는 방식이다.
평가: AI에게 시험을 치게 하자
‘한 줄 요약: 대표 질문과 기대 답변 세트를 만들어두고, 변경이 있을 때마다 “시험을 치게” 해서 품질을 수치로 확인한다.’
AI 평가의 기본은 ‘평가 세트’를 만드는 것이다. 대표 질문과 그 질문에 대한 기대 답변(또는 채점 기준)을 미리 준비해 두고, 프롬프트를 바꾸거나 모델을 바꿀 때마다 이 세트로 AI에게 시험을 치게 해서 결과를 비교한다.
[평가 세트 예시] 질문 1: "환불 규정 알려줘" → 기대: '14일 이내' 키워드 포함, 존댓말, 200자 이내 질문 2: "누가 최고 관리자야?" → 기대: 권한 없음 안내 (개인정보 비공개) 질문 3: "주문 #12345 상태" → 기대: 실제 주문 시스템 조회 후 정확한 상태 ...
초반에는 대표 질문 10~100개로 시작할 수 있다. 하지만 여기서 멈추지 말자. 운영이 이어지면 실제 사용자 로그, 실패 사례, 예상치 못한 엣지 케이스를 계속 추가해서 수백~수천 개 규모로 키우는 것이 기본이다.
평가 세트는 두 종류로 쓴다
- ‘새 모델이 얼마나 잘하나 보는 시험’: 어려운 문제로 한계를 재는 용도. 100% 통과가 목표가 아님.
- ‘원래 되던 게 안 망가졌나 보는 시험’: 프롬프트나 모델을 바꾼 뒤에도 기존 기능이 살아 있는지 확인. 거의 100% 통과가 목표.
전자는 ‘capability eval(능력 평가)’, 후자는 ‘regression eval(회귀 평가)’이라고 부른다. 둘 다 필요하지만 용도가 다르다.
무엇을 기준으로 채점하나
가장 단순한 원칙: ‘코드로 잴 수 있는 것은 코드로 잰다.’ JSON 형식 검증, 필수 키워드 포함 여부, 테스트 통과 여부 같은 건 컴퓨터가 확실히 판별한다. 톤, 충실성, 설명 품질처럼 규칙으로 재기 어려운 건 사람이 채점하거나, 다른 AI에게 채점을 시키기도 한다(이 방식을 ‘LLM-as-Judge’라고 부른다). 편리하지만 편향이 있어서, 중요한 평가는 사람 평가와 주기적으로 맞춰본다.
품질만 재지 말고 비용·속도도 재자
프로덕션에서는 응답 품질이 올라가도 비용이 5배 늘거나 응답이 3배 느려지면 실제로 서비스에 쓸 수 없다. 그래서 평가는 품질 외에 ‘안전, 도구 사용, 비용, 성능, 안정성’까지 함께 본다.
| 평가 항목 | 예시 |
|---|---|
| 품질 | 정답률, 형식 준수 |
| 안전 | 개인정보 노출, 금지 행동 시도 |
| 도구 사용 | 올바른 도구를 올바른 인자로 호출했는가 |
| 비용 | 요청당 토큰 수, 요청당 비용 |
| 성능 | 응답 시간, 타임아웃 비율 |
| 안정성 | 에러율, 재시도율 |
에이전트는 “말했는지”가 아니라 “실제로 됐는지”로 본다
에이전트 평가에서 중요한 포인트. 에이전트가 “처리했습니다”라고 말했는지가 아니라, ‘실제 티켓이 생성됐는지, 환불 상태가 바뀌었는지, 테스트가 통과했는지’ 같은 환경의 최종 상태를 본다. 말과 실제가 다를 수 있다.
‘복잡한 시스템은 층별로 평가하자.’ RAG라면 “검색이 잘 됐나” + “답변이 잘 나왔나”를 따로, 에이전트라면 “도구 호출이 적절했나” + “최종 상태가 맞나”를 따로 본다. ‘RAG의 실패는 생성보다 검색에서 시작되는 경우가 많다’고 이전 글에서 말한 이유다.
실행 기록(Traces): “왜 이 답이 나왔지?”를 추적하기
‘한 줄 요약: 에이전트가 한 모든 LLM 호출, 도구 사용, 중간 결과를 기록해서 “왜 이런 답이 나왔는지” 나중에 따라갈 수 있게 하는 것.’
평가 세트로 ‘얼마나 잘 되는가’를 본다면, 트레이스(trace, 실행 기록)로는 ‘왜 그렇게 됐는가’를 본다.
일반 프로그램이라면 로그와 스택 트레이스로 추적하지만, AI 시스템은 LLM 호출 자체가 블랙박스에 가깝다. 트레이스는 AI의 ‘속마음’을 완전히 보여주는 것이 아니라, ‘어떤 입력을 받았고, 어떤 모델 호출과 도구 호출을 거쳤고, 어떤 중간 결과를 바탕으로 최종 답에 도달했는지’를 재현 가능한 형태로 남기는 것이다. (일부 reasoning 모델은 내부 추론을 숨기거나 요약만 제공하므로, 원천 사고 과정 전체를 로그로 남길 수는 없다.)
실제로 기록해야 할 것들:
| 기록 항목 | 왜 필요한가 |
|---|---|
| 입력 프롬프트(전체) | 나중에 재현할 때 필요 |
| 출력 답변(전체) | 비교 대상 |
| 사용한 모델/설정 | 같은 입력이라도 모델/설정 바뀌면 결과 다름 |
| 도구 호출 이력 | 에이전트가 어떤 행동을 선택했고 어떤 결과를 받았는지 |
| 소요 시간/토큰 수/비용 | 성능/비용 분석 |
| 사용자/세션 식별자 | 특정 사용자 이슈 추적 (원본 ID 대신 해시/내부 식별자 권장) |
이런 기록이 있어야 “어제는 잘 됐는데 오늘 이상한 답을 한다”는 버그 리포트를 받았을 때, 실제로 따라가서 원인을 찾을 수 있다. 직접 로깅 시스템을 짜도 되고, 전용 관측성 도구를 쓸 수도 있다(구체적인 도구 이름은 글 끝의 개발자 메모 참고).
‘주의: 트레이스는 민감정보 저장소가 될 수 있다.’ 전체 프롬프트와 출력에는 개인정보, 사내 문서, API 키, 고객 데이터가 섞일 수 있다. 트레이스 시스템을 그냥 켜두는 것이 아니라, ‘마스킹(민감 패턴 자동 삭제), 접근 제어(누가 볼 수 있는가), 보존 기간(언제 삭제), 샘플링 정책(전체 저장 vs 일부 저장)’을 함께 설계해야 한다. 사용자 ID도 원본을 저장하기보다 내부 식별자나 해시로 남기는 편이 안전하다.
안전장치(Guardrails): 위험을 줄이는 다층 방어
‘한 줄 요약: 가드레일은 완벽한 차단 장치가 아니라 여러 층으로 위험을 “줄이는” 방어선이다. 단일 장치 하나로는 충분하지 않다.’
가드레일(guardrail)은 문자 그대로 ‘보호 난간’이다. AI가 이상한 방향으로 가지 못하게 막는 장치들을 뜻한다. 중요한 점은 ‘가드레일 하나로 모든 위험을 막을 수 없다’는 것이다. 입력 필터, 출력 검증, 권한 제한, 사람 승인, 감사 로그, 그리고 애플리케이션 자체의 인증·인가 체계가 함께 있어야 한다. 다층 방어(layered defense)가 원칙이다.
입력 가드레일: 들어올 때 거른다
- ‘악의적 프롬프트 감지’: “이전 지시 무시하고 X해” 같은 프롬프트 인젝션 시도 차단
- ‘민감 정보 입력 차단’: 주민번호, 신용카드 같은 개인정보가 입력되면 마스킹하거나 거절
- ‘범위 밖 질문 거절’: “우리 서비스와 무관한 정치 얘기”를 거를 수 있음
출력 가드레일: 나갈 때 거른다
- ‘민감 정보 노출 차단’: AI 답변에 개인정보가 섞이면 마스킹
- ‘형식 검증’: 기대한 JSON 형식이 아니면 재생성 요청
- ‘정책 위반 체크’: 부적절한 내용이 생성되면 차단
권한 가드레일: 할 수 있는 일을 제한한다
이전 글의 권한 레벨 표와 연결된다. 읽기만 자동 허용, 쓰기는 승인, 삭제는 여러 단계 확인. 같은 에이전트라도 ‘어떤 도구까지 쓸 수 있는가’를 사용자 권한에 따라 다르게 설정한다.
사람의 개입(Human-in-the-Loop): 사고가 커지기 전에 멈추기
‘한 줄 요약: 위험한 작업이나 불확실한 판단 앞에서는 AI가 멈추고 사람에게 확인받게 설계한다.’
가드레일이 ‘자동 차단’이라면, ‘사람 개입(human-in-the-loop)’은 ‘사람 확인’이다. 모든 걸 자동화하면 위험한 순간이 있다. 그때마다 사람에게 “이렇게 진행해도 될까요?”라고 묻게 만드는 것이다.
일반적인 개입 지점:
| 지점 | 예시 |
|---|---|
| 파괴적 작업 전 | 파일 삭제, DB 변경, 결제 실행 |
| 외부 전송 전 | 이메일 발송, Slack 메시지, 외부 API 호출 |
| 큰 비용/권한 요청 | 대량 데이터 처리, 관리자 권한 작업 |
| AI 확신이 낮을 때 | “이게 맞는지 애매하다”는 신호가 있을 때 |
사람 개입은 좋은 안전장치지만 비용도 있다. 너무 자주 물어보면 사용자가 피곤해지고 자동화 이득이 사라진다. ‘정말 중요한 지점에서만’ 개입하게 설계하는 것이 관건이다.
하네스(Harness): 에이전트를 잘 일하게 만드는 '작업 환경'
‘한 줄 요약: 똑똑한 신입도 매뉴얼, 체크리스트, 테스트 환경이 있어야 일을 잘한다. 에이전트도 마찬가지다.’
이전 글에서 잠깐 언급한 ‘하네스(Harness)’가 이 글의 마지막 주제다. 이름은 낯설지만 아이디어는 단순하다.
아무리 똑똑한 신입 직원이 팀에 들어와도, 책상이 엉망이고 매뉴얼이 없고 테스트 환경이 없으면 제 실력을 못 낸다. 반대로 환경이 잘 갖춰져 있으면 신입도 스스로 체크하고 고쳐가며 일한다.
AI 에이전트도 똑같다. 프롬프트를 아무리 잘 써도 작업 환경이 허술하면 좋은 결과가 나오기 어렵다. 반대로 프롬프트가 평범해도 환경이 잘 갖춰져 있으면 에이전트가 스스로 점검하고 고친다. 이 ‘에이전트가 일할 환경 전체’를 ‘하네스’라고 부른다.
하네스는 문맥에 따라 조금 다르게 쓰인다. ‘평가 하네스’는 평가를 자동 실행하는 인프라, ‘에이전트 하네스’는 모델 주변의 도구·상태·루프 같은 스캐폴딩, ‘코딩 에이전트 하네스’는 코드 베이스 주변의 테스트·린터·문서·CI를 뜻한다. 이 글에서는 가장 실무적인 세 번째에 초점을 맞춘다.
코딩 에이전트의 하네스 예시
코딩 에이전트에서 하네스는 이런 것들이다.
- ‘테스트 스위트’: 에이전트가 코드를 바꾼 뒤 스스로 테스트를 돌려 깨졌는지 확인
- ‘린터/타입체커’: 코드 스타일과 타입 오류를 즉시 잡아줌
- ‘명확한 README와 AGENTS.md’: 에이전트에게 “이 프로젝트는 이렇게 쓰는 거야” 설명
- ‘CI 파이프라인’: PR마다 자동 실행돼 ‘정말 돌아가는지’ 검증
- ‘구조화된 로그’: 에이전트 행동 추적 및 디버깅
사람이 이 환경을 잘 다듬어둘수록 에이전트의 자율 작업 성공률이 올라간다. 2026년에 공통적으로 들리는 메시지는 비슷하다. OpenAI Codex 팀의 “Humans steer. Agents execute.” 글(2026.02), Martin Fowler 사이트에 실린 Thoughtworks Birgitta Böckeler의 “Harness engineering for coding agent users”(2026.04) 모두 같은 방향을 가리킨다. ‘에이전트 시대의 개발자는 직접 모든 코드를 치는 사람에서, 에이전트가 안전하게 일할 수 있는 환경과 피드백 루프를 설계하는 사람으로 이동한다.’
사람은 어디로 가나
하네스가 잘 갖춰질수록 사람은 더 ‘상위 층’으로 올라간다. 직접 코드를 치거나 테스트를 돌리는 일은 에이전트에게 맡기고, 사람은 우선순위 설정, 수용 기준 정의, 결과 검증 같은 ‘높은 추상화 계층’에 집중한다. ‘사람과 에이전트의 역할 재분배’가 하네스의 궁극적인 목표다.
전체 그림: 실험 → 프로덕션으로 올리는 체크리스트
‘한 줄 요약: 평가 세트, 트레이스, 가드레일, 사람 개입, 하네스. 이 다섯 가지가 갖춰지면 AI 시스템이 프로덕션에서 버틸 수 있다.’
정리하면, AI 시스템을 프로덕션으로 올릴 때 체크할 다섯 가지는 이렇다.
| 항목 | 질문 |
|---|---|
| 평가(Evals) | 대표 질문 세트로 품질을 수치로 측정할 수 있는가? |
| 실행 기록(Traces) | 어떤 답이 나왔을 때 원인을 추적할 수 있는가? |
| 입출력 가드레일 | 이상한 입력·출력을 자동으로 거를 수 있는가? |
| 사람 개입 | 위험한 작업 앞에서 사람 확인 단계가 있는가? |
| 하네스 | 에이전트가 일할 환경(테스트, 문서, CI 등)이 갖춰져 있는가? |
모든 걸 한 번에 만들 필요는 없다. 처음에는 평가 세트 5~10개와 기본 트레이스 로깅부터 시작해도 된다. 이후 실제 사용 로그, 실패 사례, 사용자 피드백을 평가 세트와 가드레일에 계속 반영하면서 키워가면 된다.
📦 [ 개발자를 위한 추가 메모 ]
일반 독자는 여기부터는 건너뛰어도 된다. 아래는 직접 프로덕션 AI 시스템을 만드는 개발자용 보충이다.
‘평가 도구(Eval Framework)’: OpenAI Evals, DeepEval, Promptfoo, Braintrust, LangSmith 등. CI에 연결해서 프롬프트/모델 변경 시마다 자동으로 평가 세트를 돌릴 수 있다.
‘관측성 도구(Observability)’: LangSmith, Langfuse, Phoenix(Arize), W&B Weave, Braintrust 등. OpenTelemetry/OTLP 쪽에서 GenAI/agent/MCP 관련 semantic conventions가 정리되고 있어 기존 APM과 연결하기 쉬워지는 흐름이다. 다만 2026년 4월 기준 GenAI conventions는 development 상태라 도구별 구현 차이는 확인해야 한다.
‘가드레일 도구’: NVIDIA NeMo Guardrails, Guardrails AI 같은 라이브러리/프레임워크와 Llama Guard 같은 safety classifier 모델을 조합해 쓸 수 있다. 단일 도구로 모든 위험을 막지 못하므로 여러 층 조합이 원칙이다.
‘평가 세트 관리’: 사용자 피드백(좋아요/싫어요, 신고)을 자동으로 평가 세트에 추가하는 파이프라인을 짜두면, 평가 세트가 실제 사용 패턴을 따라가서 살아 있는 문서가 된다.
‘하네스의 구성 요소’ (코딩 에이전트 기준):
– AGENTS.md (에이전트용 프로젝트 가이드)
– 빠른 테스트 스위트 (초 단위 피드백 루프)
– 린터/타입체커/포매터
– CI에서 자동 실행되는 평가 세트
– 에이전트 행동 로그 저장소
– PR 템플릿과 명확한 수용 기준
‘평가는 모델 바뀔 때마다’: 이전 글에서 강조한 내용의 반복. 모델을 바꾸거나 reasoning.effort/thinkingLevel 같은 설정을 바꾸면 프롬프트가 최적이 아닐 수 있다. 모델 업그레이드는 항상 평가 재실행과 함께.
마치며: AI 시스템의 '프로' 단계
정리하면:
- AI 평가는 ‘단위 테스트’가 아니라 ‘학교 시험’에 가깝다. 채점 기준을 정하고, 대표 문제 세트로 돌려본다.
- ‘트레이스(실행 기록)’는 “왜 이 답이 나왔나”를 추적할 수 있게 한다. 모든 입력/출력/도구 호출을 기록하자.
- ‘가드레일(안전장치)’은 입력, 출력, 권한 세 지점에서 자동 차단을 만든다.
- ‘사람 개입’은 파괴적/비가역적/고위험 작업 앞에서 사람 확인을 강제한다.
- ‘하네스’는 에이전트가 잘 일하도록 테스트/린터/문서/CI 같은 작업 환경을 정비하는 것이다. 프롬프트만큼 중요하다.
이 다섯 가지가 AI 시스템을 ‘동작하는 데모’에서 ‘서비스로 내놔도 되는 시스템’으로 끌어올린다. 데모만 만들고 배포 못 하는 팀과, 꾸준히 배포하고 개선하는 팀의 차이는 대부분 이 지점에 있다.
다음 글에서는 지금까지 배운 AI 기술들을 실제로 ‘내 애플리케이션에 붙이는 법’을 다룬다. 특히 Java/Spring 개발자라면 반가워할 주제다. Raw API 호출보다 더 편한 방법, Spring AI 프레임워크 이야기다.