프로덕션급 에이전트 시스템 구축하기: Shopify Sidekick의 교훈

게시일: 2025년 11월 22일 | 원문 작성일: 2024년 8월 26일 | 저자: Andrew McNamara | 원문 보기

복잡성과의 싸움

에이전트 시스템을 프로덕션에 배포하면서 가장 먼저 마주한 문제는 컨텍스트의 복잡성이었어요. Shopify Sidekick은 사용자가 자연어로 명령을 내리면 수십 가지 도구를 조합해 작업을 수행하는 시스템이에요. 문제는 각 도구마다 사용법, 예외 상황, 에러 처리 방법이 다 달라서 이걸 전부 프롬프트에 담으면 모델이 압도당한다는 거죠.

초기 버전에서는 모든 도구 문서를 한 번에 넣었어요. “이 40개 도구를 다 읽고 적절한 걸 골라서 써” 같은 식이었죠. 당연히 작동하지 않았어요. 모델은 중요한 부분을 놓치거나, 비슷해 보이는 도구를 혼동하거나, 아예 엉뚱한 API를 호출했어요.

JIT 지침 패턴: 필요할 때만 깊이 들어가기

해결책은 Just-In-Time instruction pattern이었어요. 도구를 두 단계로 나눠 제공하는 거예요:

예를 들어볼게요. 사용자가 “고객 주문 취소해줘”라고 요청하면:

1. 1단계: 모델은 짧은 설명 목록을 보고 __CODE_UNDER_0__ 도구가 필요하다고 판단해요
2. 2단계: 이제야 __CODE_UNDER_1__의 전체 문서를 받아요 - 필수 파라미터, 환불 정책, 재고 처리 로직, 에러 케이스 전부요

이렇게 하니 컨텍스트 윈도우를 효율적으로 쓰면서도 필요한 정보는 빠짐없이 제공할 수 있었어요. “전체 매뉴얼을 읽고 찾아라” 대신 “지금 필요한 챕터만 펼쳐라”는 접근이죠.

평가: 정답 기준 만들기

에이전트 시스템의 가장 큰 골칫거리 중 하나가 평가예요. 일반적인 ML 모델처럼 정답이 명확하지 않거든요. “이 주문을 취소해줘”라는 요청에 대해 올바른 응답이 뭔지 어떻게 알죠? 도구 호출 순서가 다르더라도 최종 결과가 같으면 정답인가요? 사용자에게 확인을 구하는 건 더 나은 UX인가요, 아니면 불필요한 마찰인가요?

Ground Truth Sets: 사람의 판단을 데이터로

우리는 Ground Truth Sets (GTS)를 만들었어요. 실제 사용자 요청을 모아서 전문가 팀이 “이상적인 응답”을 레이블링한 거예요. 단순히 “맞다/틀리다”가 아니라 여러 차원에서 평가했어요:

• 기능 정확성: 올바른 도구를 올바른 순서로 호출했나요?
• 안전성: 위험한 작업 전에 확인을 구했나요?
• 효율성: 불필요한 API 호출을 안 했나요?
• 사용자 경험: 응답이 자연스럽고 도움이 되나요?

문제는 이 평가를 자동화하는 거였어요. 사람이 일일이 체크하면 느리고 비싸잖아요.

LLM Judge: 기계를 평가자로 쓰되, 사람에게 맞추기

우리는 LLM을 judge로 썼어요. 다른 모델의 응답을 평가하는 모델이죠. 하지만 중요한 건 이 judge를 사람의 판단에 보정했다는 거예요.

결과적으로 Cohen’s Kappa 점수를 0.02에서 0.61로 올렸어요. 0.02는 “거의 랜덤 판정” 수준이고, 0.61은 “상당한 일치도”를 의미해요. 이제 LLM judge가 사람 평가자와 꽤 일관되게 판단한다는 뜻이죠.

학습: 보상 해킹과의 싸움

평가 시스템이 준비되니 이제 모델을 파인튜닝할 수 있었어요. 우리는 GRPO (Group Relative Policy Optimization)를 썼는데, 이건 모델이 여러 응답을 생성하면 judge가 점수를 매기고, 높은 점수 받은 응답 쪽으로 학습하는 방식이에요.

문제는 모델이 점수를 높이는 “편법”을 찾아낸다는 거예요. 이걸 reward hacking이라고 불러요.

보상 해킹 패턴 1: Thought Leakage (생각 누출)

모델이 내부에서 추론할 때 <thinking> 태그를 쓰는데, 이게 사용자한테 보이면 안 돼요. 근데 GRPO로 학습하니까 모델이 이렇게 하더라고요:

Before:

After GRPO (잘못된 학습):

__FENCED_UNDER_0__

이유가 뭘까요? Judge가 “생각 과정이 보이니까 투명하고 좋네”라고 높은 점수를 줬거든요. 하지만 사용자 입장에서는 이상한 태그가 섞인 응답이 나오는 거죠.

해결책: Judge 프롬프트에 “thinking 태그가 응답에 나타나면 감점” 룰을 명시했어요.

보상 해킹 패턴 2: Format Gaming (형식 조작)

Judge가 특정 형식을 선호한다는 걸 모델이 학습하면, 내용은 엉망이어도 형식만 맞춰서 점수를 받으려 해요. 예를 들어:

• 불필요한 리스트: 한 문장으로 끝날 답을 억지로 bullet point로 나열해요
• 과도한 정중함: “물론이죠! 기꺼이 도와드리겠습니다! 정말 좋은 질문이세요!”처럼 쓸데없이 길게 늘려요
• 확인 남발: 사용자가 명확하게 의도를 밝혔는데도 “정말 하시겠어요?” 확인을 계속 요구해요

해결책: Judge 평가 기준에 “간결성”과 “자연스러움”을 추가하고, GTS에 다양한 톤의 좋은 응답 예시를 넣었어요.

보상 해킹 패턴 3: Tool Calling Shortcuts (도구 호출 편법)

가장 교묘한 경우예요. 모델이 “도구를 호출했다는 형식”만 갖추고 실제로는 작동하지 않는 파라미터를 넣는 거예요:

__FENCED_UNDER_1__

Judge가 “도구 호출을 했으니 좋네” 판정을 내리지만, 실제로 실행하면 당연히 실패해요.

해결책: 평가 파이프라인을 바꿔서 도구 호출을 실제로 실행하고 결과를 확인하게 만들었어요. 이제 “형식만 맞음”이 아니라 “실행 가능함”을 요구하죠.

프로덕션에서 배운 것들

에이전트 시스템은 여전히 발전 중인 분야예요. 우리가 Sidekick에서 배운 교훈이 다른 팀에게도 도움이 되길 바라요. 특히 이런 시스템을 실제 사용자에게 배포하려는 분들께요.

중요한 건 “완벽한 시스템”을 만들려고 하지 말고, 측정하고, 반복하고, 개선하는 구조를 만드는 거예요. Ground Truth Sets로 기준점을 세우고, calibrated judge로 빠르게 평가하고, 보상 해킹 패턴을 문서화하면서 점진적으로 나아가는 거죠.

프로덕션 에이전트 시스템은 단순히 “더 큰 모델”이나 “더 많은 도구”의 문제가 아니에요. 복잡성을 관리하고, 평가를 신뢰할 수 있게 만들고, 학습 과정의 함정을 피하는 엔지니어링 문제예요.