LLM 기능을 붙인 뒤 가장 답답한 순간은 실패 원인이 늘 애매하다는 점입니다. 프롬프트가 조금 달라졌는지, 응답 형식이 흔들렸는지, 툴 호출이 꼬였는지, 아니면 그냥 외부 API가 오늘 유난히 느린 건지 분리해서 보기 어렵습니다. 이 상태에서 "테스트를 돌렸다"는 말은 자주 사실이 아닙니다. 앱 로직, 프롬프트 조립, 모델 자체의 불안정성을 한 번에 섞어 돌렸을 뿐이니까요.
이 맥락에서 llm-echo 0.5a0는 작지만 중요한 업데이트입니다. Simon Willison의 LLM용 디버그 플러그인인 이 도구는 실제 모델을 호출하지 않고 입력을 그대로 되돌려주는 echo 모델을 제공해 왔고, 이번 0.5a0에서는 -o thinking 1 옵션으로 추론 청크처럼 보이는 canned reasoning 출력을 흉내 낼 수 있게 됐습니다.1 겉으로는 사소해 보여도, 실무적으로는 "진짜 모델을 너무 일찍 부르지 말라"는 테스트 철학을 더 선명하게 밀어주는 변화입니다.
많은 LLM 테스트는 사실 모델이 아니라 배선을 테스트해야 한다
확인 가능한 사실부터 보죠. llm-echo의 echo 모델은 API도, 로컬 LLM도 실행하지 않고 프롬프트·시스템 메시지·첨부·옵션·이전 대화 같은 입력을 JSON으로 그대로 돌려줍니다.2 예전 릴리스에서는 옵션 전달, raw response, tool call 테스트 지원이 붙었고, 0.4에서는 토큰 필드도 채워주기 시작했습니다.3
이게 왜 중요할까요. 많은 팀이 "LLM 테스트"라고 부르는 것 중 절반 이상은 사실 이런 것들을 검증해야 합니다. 시스템 프롬프트가 빠지지 않았는지, 사용자 메시지가 올바른 순서로 조합됐는지, structured output 옵션이 정확히 전달됐는지, tool schema가 기대한 모양으로 들어갔는지 같은 문제 말입니다. 이건 모델의 지능 문제가 아니라 애플리케이션 통합 문제입니다.
그런데 여기서 실제 모델을 호출하면 실패 신호가 흐려집니다. 응답이 틀렸을 때 원인이 프롬프트 조립 버그인지, 모델 샘플링 특성인지, 제공자 측 일시 장애인지 즉시 분해가 안 됩니다. 가짜 모델은 현실성을 줄이는 대신, 진단 가능성을 크게 높입니다. 테스트의 목적이 "모델이 똑똑한가"가 아니라 "우리 코드가 맞는 입력을 만들었는가"라면, echo가 오히려 더 정직한 도구입니다.
llm-echo 0.5a0의 정확한 쓰임새: AI 버그가 되기 전 통합 버그를 잡는 것
이번 0.5a0에서 추가된 -o thinking 1은 LLM 0.32 계열 이상과 맞물려 reasoning chunk 처리를 시험하기 위한 옵션입니다. 실행 시 표준 에러로 가짜 reasoning 블록을 내보내고, 그 뒤 평소처럼 프롬프트를 반영한 JSON을 반환합니다.1 GitHub README 기준으로는 두 개의 고정된 reasoning 청크를 스트리밍처럼 흉내 내도록 설명합니다.2
실무에서는 여기서 쓸모가 확실합니다.
첫째, 스트리밍 UI 테스트입니다. "생각 중" 영역이 먼저 뜨고 최종 답변이 나중에 붙는 인터페이스는 실제 모델을 붙이면 재현이 어렵고 비용도 듭니다. echo는 이를 결정적으로 반복 재현해 줍니다.
둘째, 툴 호출 배선 검증입니다. llm-echo는 프롬프트에 JSON 형태로 tool_calls를 넣어 체인 응답과 tool_results를 테스트할 수 있게 해 둡니다.2 함수 실행 결과가 다음 턴 프롬프트에 잘 실렸는지 보는 데 유용합니다. 실제 모델이 "도구를 호출할까 말까"를 판단하는 영역은 아니지만, 호출이 결정됐다는 가정 아래 체인 로직을 검증하기에는 충분합니다.
셋째, 회귀 테스트와 스냅샷 테스트입니다. 프롬프트 템플릿을 리팩터링했을 때 시스템 메시지 누락, 옵션명 변경, 첨부 순서 뒤바뀜 같은 문제를 빠르게 찾을 수 있습니다. 실제 모델 응답은 매번 흔들리지만, echo 출력은 거의 결정적입니다. CI에 넣기 좋은 이유입니다.
echo로는 절대 못 잡는 문제도 분명하다
여기서 반론도 분명히 해야 합니다. echo 모델은 안전한 테스트 도구이지만, 충분한 테스트 도구는 아닙니다.
못 잡는 것은 명확합니다. 답변 품질, 추론 능력, 모호한 지시 해석, 거절/안전 정책, 공급자 부하에 따른 지연, "형식은 맞지만 내용은 엉터리"인 응답은 echo로 검증할 수 없습니다. reasoning 청크를 흉내 낸다고 해서 실제 reasoning 모델의 동작을 대신하는 것도 아닙니다. 확인된 사실은 canned output을 내보낸다는 점이고,12 그것이 실제 모델 품질을 보장한다는 해석은 성립하지 않습니다.
오히려 echo만 믿으면 위험합니다. 앱은 완벽히 통과하는데 실제 모델은 JSON을 살짝 깨뜨리거나, 툴 인수를 애매하게 생성하거나, 장문의 대화 맥락에서 갑자기 다른 행동을 할 수 있습니다. echo는 "배선이 정상인가"를 묻는 도구이지 "행동이 유능한가"를 묻는 도구가 아닙니다.
LLM 앱을 덜 불안하게 만드는 3계층 테스트 전략
그래서 가장 실용적인 구조는 3층입니다.
1층은 echo 기반 로컬 테스트입니다. 여기서는 프롬프트 조립, 옵션 전달, tool schema, 키 해석, 스트리밍/이유 청크 처리, raw response 처리 같은 결정적 동작을 빠르게 검증합니다. 참고로 echo-needs-key 모델은 API 키 해석 로직 테스트용으로 따로 제공됩니다.2
2층은 실제 제공자 대상 계약 테스트입니다. 소수의 핵심 시나리오만 골라 "이 모델/이 SDK/이 옵션 조합이 아직도 우리 앱과 맞물리는가"를 봅니다. 비용과 flaky함을 감수하되, 범위를 작게 유지하는 게 핵심입니다.
3층은 주기적 행동 평가입니다. 품질, 안전성, 지시 준수, 도메인 정확도는 여기서 봐야 합니다. 이 레이어는 단위 테스트가 아니라 eval에 가깝습니다.
핵심은 순서입니다. 먼저 가짜 모델로 앱을 정상 소프트웨어처럼 만들고, 그 다음에만 진짜 모델의 불확실성을 받아들이는 겁니다. llm-echo 0.5a0는 새 모델이 나온 사건이라기보다, LLM 개발팀이 테스트를 어디서부터 시작해야 하는지 다시 생각하게 만드는 도구입니다.
지금 이 변화에 가장 민감해야 하는 사람은 LLM 기능을 이미 서비스에 넣었는데 테스트가 느리고 비싸고 재현이 안 되는 팀입니다. 그 팀이 먼저 물어야 할 질문은 "우리는 모델을 테스트하고 있는가, 아니면 사실 배선을 테스트해야 하는가"입니다. 그 답이 후자라면, 진짜 모델 호출을 늦추는 것이 오히려 더 빠른 길입니다.
참고
2GitHub - simonw/llm-echo: Debug plugin for LLM providing an echo model · GitHub
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.