24장. 운영 중 개선: 프롬프트, 모델, 제품의 우선순위

운영 중인 LLM 서비스에서 문제가 생기면 팀은 쉽게 흥분한다. 답변 품질이 떨어지면 더 강한 모델을 찾고, 응답이 느려지면 다른 벤더를 검토하고, 불만이 올라오면 프롬프트를 통째로 갈아엎고 싶어진다. 하지만 실무에서는 이런 반응이 오히려 속도를 늦춘다. 자동차가 흔들린다고 엔진부터 바꾸지 않듯이, LLM 서비스도 모델부터 갈아끼우는 팀보다 문제를 층위별로 분해하는 팀이 더 빨리 좋아진다.

운영 개선의 핵심은 단순하다. 문제를 먼저 분류하고, 가장 값싸고 되돌리기 쉬운 레버부터 움직이는 것이다. 많은 경우 사용자가 겪는 불편은 모델 자체의 한계가 아니라 제품 흐름, 입력 방식, 프롬프트 설계, 검색 컨텍스트, 툴 연결, 후처리 로직에서 발생한다. 그런데 이 모든 층위를 건너뛰고 모델만 바꾸면 비용은 올라가고, 원인은 그대로 남는다.

이 장에서는 운영 데이터를 바탕으로 무엇을 먼저 바꿔야 하는지, 그리고 어떤 순서로 실험해야 하는지 실전적인 개선 사이클로 정리해 보겠다.

운영 개선은 "더 똑똑한 모델 찾기"가 아니다

운영 중 개선을 이야기할 때 가장 먼저 버려야 할 생각은 이것이다.

"모델이 더 좋아지면 문제도 같이 사라지겠지."

물론 어떤 문제는 모델 교체로 해결된다. 긴 문맥 이해가 유독 약하다거나, 한국어 요약 품질이 눈에 띄게 떨어진다거나, 툴 호출 안정성이 벤더마다 크게 다를 수 있다. 하지만 운영 현장에서 자주 만나는 문제는 의외로 훨씬 현실적이다.

사용자가 너무 넓은 질문을 던져 결과가 흔들리거나, 프롬프트가 장황해서 응답이 느려지거나, 검색 문서가 과하게 붙어 비용이 폭증하거나, 구조화 출력 스키마가 실제 UI 요구와 맞지 않아 후처리에서 깨지는 경우가 많다. 이때 모델만 바꾸면 어떨까. 답은 종종 이렇다. 결과는 조금 나아진 듯 보이지만, 비용은 올라가고, 속도는 나빠지고, 문제는 다른 모습으로 다시 돌아온다.

운영 개선은 모델 능력치 경쟁이 아니라 시스템 전체에서 어디가 진짜 병목인지 찾는 일이다. 23장에서 로그와 트레이스로 원인을 보이게 만들었다면, 이제는 그 정보를 바탕으로 손댈 순서를 정해야 한다.

우선순위의 기본 원칙: 제품, 프롬프트, 실행 경로, 모델 순으로 본다

실무에서는 보통 다음 순서가 가장 안전하다.

첫째는 제품이다. 사용자가 무엇을 입력하고, 어떤 기대를 가지고, 어떤 순간에 AI 기능을 쓰는지부터 본다. 입력이 너무 자유로워서 실패가 늘어나는 문제는 입력 폼, 템플릿, 예시 문장, 선택형 옵션, 단계 분리만으로도 크게 줄어든다. 사용자가 "뭘 물어봐야 할지" 모르는데 모델만 바꾸는 것은, 안내판 없는 건물에 엘리베이터만 새로 다는 것과 비슷하다.

둘째는 프롬프트다. 같은 모델이라도 지시문 구조, 역할 정의, 제약 조건, 출력 형식, few-shot 예시 몇 개만 바꿔도 결과가 안정되는 경우가 많다. 특히 장황함, 톤 불일치, 포맷 오류, 누락된 경고문 같은 문제는 프롬프트에서 먼저 잡히는 경우가 많다.

셋째는 실행 경로다. 여기에는 검색 증강 생성, 툴 호출, 후처리, 재시도, 캐시, 컨텍스트 구성 같은 요소가 들어간다. 사용자는 "AI가 틀렸다"고 말하지만, 실제로는 검색 문서가 잘못 붙었거나 외부 API 응답이 비어 있었거나 후처리 로직이 정보를 잘라먹는 경우가 많다. 모델이 아니라 파이프라인이 문제인 셈이다.

넷째가 모델이다. 앞선 세 층위에서 얻을 수 있는 개선 여지가 작고, 문제 패턴이 반복적으로 모델 능력 한계에 닿아 있을 때 모델 교체나 라우팅 변경을 검토한다. 즉 모델은 중요한 레버지만, 가장 먼저 누르는 버튼은 아니다.

이 순서가 좋은 이유는 간단하다. 위로 갈수록 변경 비용이 낮고, 원인 설명이 쉽고, 롤백이 빠르다. 아래로 갈수록 비용이 크고, 효과 예측이 어려우며, 부작용이 넓게 퍼진다.

운영 데이터는 증상이 아니라 패턴으로 읽어야 한다

사용자 피드백은 출발점이지, 결론이 아니다. "답이 별로예요", "느려요", "가끔 이상해요" 같은 말만 보고 개선에 들어가면 늘 헤맨다. 운영 데이터는 한 건의 불만이 아니라 반복되는 패턴으로 읽어야 한다.

예를 들어 품질 이슈가 있다고 해 보자. 이때 정말 알아야 하는 것은 단순한 만족도 평균이 아니다. 어떤 기능에서, 어떤 입력 길이에서, 어떤 테넌트에서, 어떤 프롬프트 버전 이후에, 어떤 실패 유형이 늘었는지를 봐야 한다. 장황한 답변이 늘어난 것인지, 사실 오류가 늘어난 것인지, JSON 파싱이 깨지는 것인지에 따라 손댈 위치가 완전히 달라진다.

속도도 마찬가지다. 사용자가 느리다고 느끼는 이유가 첫 토큰이 늦어서인지, 답변이 너무 길어서인지, 중간 툴 호출이 많아서인지 구분해야 한다. 비용 문제 역시 요청 수 증가 때문인지, 컨텍스트 길이 증가 때문인지, 에이전트 루프 때문인지 나누어 봐야 한다.

운영 개선은 결국 이런 질문으로 시작한다.

• 이 문제는 얼마나 자주 발생하는가

• 누구에게 얼마나 큰 피해를 주는가

• 매출, 유지율, 신뢰에 어떤 영향을 주는가

• 원인이 어느 층위에 있을 가능성이 큰가

• 가장 작은 변경으로 실험할 수 있는 방법은 무엇인가

이 다섯 가지가 분명하지 않다면, 아직은 모델 비교표를 펼칠 때가 아니다.

가장 먼저 손댈 곳을 고르는 실전 기준

문제의 우선순위를 정할 때는 감이 아니라 기준이 필요하다. 실무에서는 다음 네 축을 함께 보는 것이 좋다.

사용자 영향도

문제가 핵심 사용자 여정에 직접 영향을 주는가를 본다. 예를 들어 회원 가입 직후의 첫 경험, 유료 전환 직전의 핵심 기능, 반복 사용을 만드는 주요 워크플로라면 작은 오류도 영향이 크다. 반대로 거의 쓰이지 않는 부가 기능의 품질 문제는 당장 급한 일이 아닐 수 있다.

발생 빈도

한 번 크게 터지는 문제도 중요하지만, 운영에서는 작고 반복적인 실패가 더 위험할 때가 많다. 하루에 몇 건만 생기는 치명적 오류보다, 매일 수백 건 발생하는 애매한 답변 품질 저하가 실제 이탈을 더 크게 만들기도 한다.

수정 비용과 되돌리기 쉬움

입력 문구 한 줄, 기본 옵션 한 개, 프롬프트 버전 하나를 바꾸는 일은 빠르게 실험하고 쉽게 되돌릴 수 있다. 반면 모델 교체는 테스트 범위가 넓고 비용 구조, 속도, 안정성, 벤더 정책까지 함께 바뀐다. 같은 효과가 기대된다면 항상 더 가볍고 되돌리기 쉬운 수정이 먼저다.

원인에 대한 확신도

로그, 트레이스, 샘플 리뷰를 통해 원인이 어느 정도 보이는가도 중요하다. 원인이 불분명한데 모델부터 바꾸는 것은, 어두운 방에서 가구를 옮기는 일과 비슷하다. 뭔가 달라지긴 하겠지만, 문제를 해결했는지는 알기 어렵다.

이 네 축을 종합하면 실무적인 우선순위가 나온다. 영향은 크고, 자주 발생하고, 원인이 비교적 선명하며, 작은 수정으로 검증 가능한 문제가 가장 먼저다.

증상별로 먼저 의심할 층위는 다르다

운영에서는 증상에 따라 출발점이 달라져야 한다. 아래 표는 자주 만나는 패턴을 단순화한 것이다.

이 표가 말하는 요지는 분명하다. 같은 "품질 문제"라도 출발점이 다르다. 장황함은 보통 프롬프트와 UX 문제에 가깝고, 사실 오류는 데이터와 실행 경로를 먼저 봐야 하며, 비용은 제품 구조와 호출 구조를 먼저 줄여야 한다.

제품 수정이 가장 강력한 이유

LLM 팀은 종종 프롬프트에 많은 기대를 건다. 하지만 운영 경험이 쌓일수록 알게 된다. 사용자 행동을 바꾸는 작은 제품 수정이, 프롬프트 몇 페이지보다 더 큰 효과를 낼 때가 많다는 사실이다.

예를 들어 문서 요약 기능에서 사용자가 매번 "이 문서에서 경영진용 핵심만 5줄로 뽑아 줘" 같은 말을 직접 써야 한다면, 입력은 금방 흔들린다. 그런데 UI에서 애초에 요약 목적을 선택하게 하고, 출력 길이를 정하게 하고, 어조를 고르게 하면 실패율이 크게 줄어든다. 모델이 더 똑똑해져서가 아니라, 서비스가 더 똑똑하게 물어봤기 때문이다.

고객지원 챗봇도 마찬가지다. 사용자가 너무 넓은 질문을 던질 수 있는 구조라면, 모델은 계속 불안정해진다. 이때 더 강한 모델을 붙이는 것보다 주문 조회, 환불 문의, 계정 변경 같은 업무를 먼저 분기하고 필요한 정보부터 받는 편이 훨씬 안정적이다.

제품 수정은 세 가지 장점이 있다.

• 실패를 사전에 줄인다.

• 모델 비용 증가 없이 효과를 낸다.

• 사용자에게도 왜 결과가 좋아졌는지 설명하기 쉽다.

즉 제품은 단순한 껍데기가 아니다. LLM 서비스에서 제품 설계는 모델 성능을 끌어올리는 첫 번째 레버다.

프롬프트는 크게 바꾸기보다 작게, 버전으로, 가설 중심으로 바꾼다

프롬프트는 운영 개선에서 매우 유용하지만, 잘못 다루면 가장 미신적인 영역이 되기도 한다. "이 문장을 넣었더니 뭔가 나아진 것 같아" 같은 식으로 움직이면 팀 전체가 감각에 의존하게 된다.

실전에서는 프롬프트를 문학 작품처럼 다루기보다, 버전 있는 설정 파일처럼 다뤄야 한다. 어떤 문제가 있었고, 무엇을 바꿨고, 기대한 효과가 무엇인지가 명확해야 한다. 또한 한 번에 너무 많은 것을 바꾸지 않는 편이 좋다. 역할 정의, 출력 형식, 금지 규칙, 예시, 길이 제한을 한 번에 다 바꾸면 무엇이 효과를 냈는지 알 수 없기 때문이다.

좋은 프롬프트 개선은 대개 이런 식으로 움직인다.

먼저 실패 사례를 모은다. 그다음 실패 유형을 좁힌다. 예를 들어 "답이 맞지만 너무 길다"처럼 한 문장으로 정의한다. 이후 그 문제를 직접 겨냥하는 제약 하나를 넣는다. 필요하면 예시를 한두 개 추가한다. 그리고 소규모 트래픽이나 평가 세트로 비교한다.

이 과정에서 중요한 점은 프롬프트가 만능이 아니라는 것이다. 프롬프트는 모델을 설득할 수는 있어도, 없는 정보를 만들어 주지는 못한다. 검색 문서가 틀렸는데 프롬프트를 더 길게 쓰는 것은, 흐린 지도에 형광펜을 칠하는 일과 비슷하다.

모델 교체는 마지막이 아니라, 조건이 갖춰졌을 때의 큰 카드다

모델 교체를 무조건 늦추라는 뜻은 아니다. 다만 모델 교체는 "가장 강한 해법"이 아니라 "가장 큰 해법"에 가깝다. 효과가 클 수 있지만, 함께 움직이는 변수도 많다.

새 모델을 도입하면 품질만 바뀌지 않는다. 지연 시간, 비용, 토큰 사용량, 안전 정책, 구조화 출력 안정성, 툴 호출 방식, 멀티턴 대화의 성격까지 함께 바뀐다. 이전 프롬프트가 잘 먹히지 않을 수도 있고, 폴백 전략을 다시 짜야 할 수도 있다. 그래서 모델 교체는 항상 더 큰 테스트와 더 넓은 롤아웃 계획을 요구한다.

그렇다면 언제 모델을 바꿔야 할까. 보통 다음 조건이 겹칠 때다.

첫째, 제품과 프롬프트, 실행 경로를 손본 뒤에도 같은 유형의 한계가 반복될 때다. 예를 들어 충분한 근거 문서를 주어도 장문 추론 품질이 계속 낮다면, 이는 모델 한계일 수 있다.

둘째, 문제의 범위가 넓고 핵심 기능에 직접 영향을 줄 때다. 특정 엣지 케이스가 아니라 주요 기능 전반에서 품질 격차가 나타난다면 모델 교체의 경제성이 생긴다.

셋째, 비용 대비 효율이 분명할 때다. 더 싼 모델로 내려도 품질이 유지되거나, 더 비싼 모델을 써도 전환율이나 유지율 개선이 확실하다면 바꿀 이유가 생긴다.

넷째, 안정성이나 공급자 리스크가 실제 운영 문제로 이어질 때다. 속도 편차가 심하거나 특정 지역에서 응답이 불안정하다면 모델 교체가 아니라 벤더 라우팅 재설계와 함께 판단해야 한다.

즉 모델 교체는 감정의 반응이 아니라 데이터가 뒷받침하는 투자 결정이어야 한다.

실전 개선 사이클: 한 바퀴를 이렇게 돌린다

운영 팀이 실제로 따라 하기 좋은 개선 사이클은 다음과 같다.

1. 문제를 모은다

사용자 불만, CS 티켓, 세션 재시도, 포맷 실패, 비정상 종료, 비용 급증 같은 신호를 한곳에 모은다. 이 단계에서는 해결하려 하지 말고, 증상을 충분히 수집하는 데 집중한다.

2. 같은 문제끼리 묶는다

한 건씩 보면 다 달라 보이지만, 묶어 보면 패턴이 보인다. 장황함, 사실 오류, 포맷 실패, 느린 응답, 불필요한 툴 호출처럼 운영에서 다룰 수 있는 실패 유형으로 군집화한다.

3. 층위를 지정한다

각 문제를 제품, 프롬프트, 실행 경로, 모델 중 어디에서 먼저 볼지 정한다. 이 단계가 중요하다. 문제를 곧바로 해결책과 연결하지 말고, 먼저 손댈 층위를 정해야 한다.

4. 가장 작은 가설을 만든다

"모델이 별로다" 같은 문장은 가설이 아니다. "요약 기능에서 사용자 입력이 너무 자유로워 실패가 늘어난다. 입력 목적을 선택형으로 바꾸면 재시도율이 줄어든다"처럼 바뀌어야 한다. 작은 가설일수록 검증이 쉽다.

5. 한 번에 한 가지씩 실험한다

프롬프트와 UI와 모델을 한 번에 바꾸면 결과가 좋아져도 이유를 모른다. 가능하면 한 번에 한 레버만 움직이고, 비교군을 남겨 둔다. 작은 실험을 여러 번 하는 팀이 결국 더 빨리 간다.

6. 온라인 지표와 샘플 리뷰를 함께 본다

클릭률, 재시도율, 포맷 성공률, TTFT, 비용 같은 숫자를 보고, 동시에 실제 응답 샘플도 함께 읽는다. 숫자만 보면 이상한 개선을 놓치고, 샘플만 보면 규모를 놓친다.

7. 남기고, 롤백하고, 다음으로 넘어간다

효과가 있으면 버전 기록을 남기고 확장한다. 효과가 없으면 빨리 되돌린다. 중요한 것은 실패한 실험도 기록하는 것이다. 그래야 같은 함정을 반복하지 않는다.

이 사이클이 익숙해지면 팀은 점점 덜 흥분하고 더 정확해진다. 그리고 그 차이가 운영 성숙도를 만든다.

사례로 보는 우선순위 판단

회의록 요약 SaaS를 운영한다고 가정해 보자. 최근 사용자 불만이 늘었다. "결과가 너무 길다", "핵심 액션 아이템이 안 보인다", "처리 시간이 들쭉날쭉하다"는 피드백이 들어온다.

처음 반응은 보통 이렇다. "더 좋은 모델로 바꾸자." 하지만 데이터를 보면 다른 그림이 나온다. 긴 회의록일수록 원문 전체를 그대로 넣고 있었고, 사용자마다 원하는 출력 형식도 달랐다. 어떤 이는 경영진 요약을 원했고, 어떤 이는 담당자별 액션 아이템만 원했다. 프롬프트는 이 둘을 한 번에 만족시키려다 길고 모호해졌다.

이때 가장 먼저 할 일은 모델 교체가 아니다. 제품에서 요약 목적을 선택하게 하고, 액션 아이템 전용 출력 옵션을 분리하고, 기본 길이를 짧게 잡는다. 다음으로 프롬프트에서 "회의 요약"과 "실행 항목 추출"을 분리한다. 그 후 긴 문서는 먼저 중간 요약을 거치게 하거나, 화자별 구간을 나눠 처리하도록 실행 경로를 바꾼다. 여기까지 했는데도 특정 종류의 회의에서 추론 품질이 부족하다면, 그때 모델 업그레이드를 검토한다.

이 순서를 따르면 비용 증가 없이도 상당수 문제가 해결된다. 무엇보다 팀이 왜 좋아졌는지 설명할 수 있다. 운영 개선에서 설명 가능한 진전은 매우 중요하다. 그래야 다음 판단도 빨라진다.

팀이 흔히 빠지는 세 가지 함정

첫 번째 함정은 모든 문제를 하나로 보는 것이다. 품질 저하, 속도 저하, 비용 증가, 사용자 혼란은 서로 다른 문제다. 한 번에 다 잡으려 하면 아무것도 명확해지지 않는다.

두 번째 함정은 모델에 감정을 투사하는 것이다. 어떤 팀은 특정 모델에 과도한 기대를 걸고, 어떤 팀은 한 번 실망한 모델을 영원히 배제한다. 하지만 운영에서는 취향보다 적합성이 중요하다. 기능마다 좋은 모델이 다를 수 있다.

세 번째 함정은 개선보다 교체를 더 멋지게 여기는 것이다. 새 모델 도입은 눈에 띄지만, 입력 흐름 개선이나 출력 스키마 정리는 덜 화려하다. 그러나 실제 서비스의 품질은 대개 이런 덜 화려한 작업에서 오른다.

운영 개선 회의에서 꼭 던져야 할 질문

주간 운영 회의나 장애 리뷰에서 다음 질문을 반복하면 팀의 판단이 훨씬 선명해진다.

• 이 문제는 사용자에게 정확히 어떤 순간에 보이는가

• 이 문제를 가장 적게 겪는 사용자 집단은 누구이며, 왜 그런가

• 지금 본 현상은 모델 한계인가, 제품 설계 문제인가

• 더 싼 수정으로 먼저 검증할 방법이 있는가

• 이 변경이 실패했을 때 쉽게 되돌릴 수 있는가

• 개선 여부를 어떤 지표와 샘플로 확인할 것인가

이 질문들은 단순해 보이지만 강력하다. 모델 교체 논의가 뜨거워질수록 오히려 이런 기본 질문이 팀을 현실로 끌어내린다.

결국 더 빨리 좋아지는 팀의 습관

운영 중 개선을 잘하는 팀은 공통된 습관이 있다. 문제를 봤을 때 바로 해결책부터 말하지 않는다. 먼저 실패 패턴을 모으고, 가장 작은 레버부터 시험하고, 결과를 버전으로 남기고, 모델 교체를 마지막 카드 중 하나로 다룬다.

이 습관은 보수적인 태도가 아니다. 오히려 가장 실전적이다. 모델은 강력하지만 비싸고 넓게 영향을 준다. 반면 제품과 프롬프트, 실행 경로는 더 빠르게 실험할 수 있고, 원인을 더 선명하게 드러낸다. 그래서 무작정 모델부터 바꾸지 않는 팀이 결국 더 빨리 좋아진다.

마치며

운영 중인 LLM 서비스는 늘 어딘가 아쉽다. 답변은 더 정확했으면 좋겠고, 속도는 더 빨랐으면 좋겠고, 비용은 더 낮았으면 좋겠다. 하지만 그 아쉬움을 해결하는 순서에는 기술보다 판단이 중요하다.

제품이 먼저인지, 프롬프트가 먼저인지, 실행 경로를 손봐야 하는지, 정말 모델을 바꿔야 하는지 구분할 수 있어야 한다. 이 구분이 되는 팀은 개선을 쌓아 올리고, 그렇지 못한 팀은 늘 새 모델 소식에 흔들린다.

운영 개선의 목표는 가장 화려한 변경이 아니다. 가장 작은 비용으로 가장 큰 사용자 개선을 만드는 것이다. 그 원칙을 지키면, 서비스는 한 번에 크게 좋아지지 않더라도 꾸준히 강해진다. 그리고 실무에서는 그 꾸준함이 결국 가장 큰 경쟁력이 된다.