LLMOps 32

LLM 운영, 프롬프트 너머의 지속 가능한 개선 루프

운영 개선을 프롬프트 몇 줄 고치는 일로만 생각하기 쉽다.

근거 · 교안 p120-p122

1장: 운영 개선, 프롬프트만이 전부일까?

솔라는 모니터 한구석에 떠 있는 프로젝트 관리 도구의 카드 하나를 멍하니 바라보고 있었다. 카드에는 ‘LLM 요약 봇 운영 개선’이라는 제목 아래, 담당자가 방금 남긴 짧은 메모가 적혀 있었다.

“운영에서 무엇을 측정하고 어떻게 개선할지 정하기”

“음… 결국 프롬프트 고치라는 소리네.”

솔라는 혼잣말을 하며 의자를 뒤로 쭉 뺐다. 새로 출시한 뉴스 기사 요약 봇에 대한 사용자 불만이 조금씩 쌓이고 있었다. ‘요약이 너무 딱딱하다’, ‘핵심을 놓치는 것 같다’는 의견이 대부분이었다. 문제를 해결하는 길은 명확해 보였다. 더 똑똑한 프롬프트를 만들어서 결과물의 품질을 높이는 것. ‘무엇을 측정할지’는 당연히 결과물의 품질일 테고, ‘어떻게 개선할지’는 프롬프트 수정을 뜻하는 게 분명했다. 솔라는 간단한 작업이라고 생각하며 자리에서 일어났다.

거실 테이블에서 스케치북에 무언가 그리고 있던 언니 루나에게 다가간 솔라는 방금 본 메모에 대해 가볍게 입을 열었다.

“언니, 지금 회사에서 맡은 요약 봇 있잖아. 사용자들이 결과가 별로라고 해서 개선해야 하는데, 결국 프롬프트 엔지니어링 싸움이겠지? ‘측정하고 개선하기’라고 거창하게 써놨던데, 그냥 더 나은 프롬프트 만들어서 적용 전후 비교해보면 되는 거 아니야?”

루나는 그림을 그리던 손을 멈추고 고개를 들었다. 솔라의 자신감 넘치는 얼굴을 잠시 바라보더니, 스케치북의 새 페이지를 펼쳤다.

“그래? 솔라 네가 생각하는 ‘더 나은 프롬프트’는 어떤 건데?”

“지금은 그냥 ‘기사를 세 문장으로 요약해줘’ 수준이거든. 너무 건조하다는 평이 많아. 그래서 ‘가장 중요한 핵심 내용 세 가지를 찾아서, 초등학생도 이해할 수 있도록 친근한 말투로 설명해줘’ 이렇게 바꿔보려고. 훨씬 좋아지지 않겠어?”

솔라의 목소리에는 확신이 담겨 있었다. 루나는 말없이 고개를 끄덕이며 스케치북 위에 솔라가 말한 새 프롬프트를 간결하게 적었다.

“좋아. 그 프롬프트를 적용했다고 상상해보자.”

루나는 프롬프트 아래에 웃는 얼굴 아이콘을 하나 그렸다. “일주일쯤 지났어. 사용자 설문을 받아보니 ‘말투가 친근해져서 좋다’는 긍정적인 피드백이 늘었어. 성공적이네.”

“그렇지?” 솔라가 의기양양하게 말했다. 역시 프롬프트가 답이었다.

하지만 루나의 펜은 멈추지 않았다. 웃는 얼굴 아이콘 옆에, 이번에는 ‘₩’ 기호와 위로 솟구치는 화살표를 그렸다.

“그런데 이상한 점이 발견됐어. 그 주에 정산된 API 사용료 청구서를 열어봤더니, 비용이 이전보다 세 배나 늘어난 거야.”

“세 배라고?” 솔라의 얼굴에서 미소가 사라졌다.

루나는 아랑곳하지 않고 말을 이었다. 그녀의 펜은 마지막으로 작은 시계 아이콘을 추가했다. “그리고 기술 지원팀에서는 몇몇 사용자들이 ‘요약 결과를 받는 데 시간이 너무 오래 걸린다’고 불평하기 시작했다는 보고를 보내왔어.”

솔라는 스케치북 위에 나란히 그려진 세 개의 그림—웃는 얼굴, 솟구치는 비용, 느려진 시계—을 뚫어지게 쳐다보았다. 머릿속에서 각기 다른 조각들이 맞춰지기 시작했다.

“아…!”

나지막한 탄성이 터져 나왔다.

“‘핵심 내용 세 가지’를 찾고, ‘친근한 말투로 설명’하라고 지시했으니까… 응답이 훨씬 길어졌겠구나. 더 긴 텍스트를 생성했으니 토큰 사용량이 늘어서 비용이 급증한 거고, 그걸 생각하고 만드는 데 시간이 더 걸려서 속도가 느려진 거네.”

품질을 잡았다고 생각했는데, 생각지도 못한 곳에서 비용과 속도 문제가 터져 나온 것이다. 한 가지 문제를 해결하기 위한 행동이 다른 두 가지 문제를 만들어 낸 셈이었다.

루나는 그제야 펜을 내려놓고, 솔라가 처음에 언급했던 문장을 스케치북 한쪽에 다시 적었다.

운영에서 무엇을 측정하고 어떻게 개선할지 정하기

“그래서 ‘무엇을 측정할지’라는 질문이 중요한 거야. 솔라, 네가 처음 개선하려고 했던 건 뭐였지?”

루나의 질문에 솔라는 스케치북 위의 웃는 얼굴 아이콘을 손가락으로 가리켰다.

“응답의 ‘품질’이었어. 말투나 형식 같은… 그런데 이제 보니, 내가 보던 건 아주 작은 부분이었네.”

솔라는 잠시 생각에 잠기더니, 루나의 펜을 빌려 스케치북 위에 그려진 세 개의 아이콘—품질, 비용, 속도—모두를 커다란 원으로 둘러쌌다. 마치 하나의 연결된 시스템처럼 보였다.

“운영 개선이라는 게… 단순히 프롬프트 몇 줄 고치는 작업이 아니었구나. 뭔가를 바꾸면, 예상치 못한 다른 곳에 영향을 주니까. 하나만 보고 달려들면 안 되는 거였어.”

솔라는 자신이 처음 가졌던 생각이 얼마나 단순했는지 깨달았다. ‘측정하고 개선한다’는 말의 무게가 다르게 느껴졌다. 이제 그 문장은 단순히 ‘프롬프트를 고쳐라’는 지시가 아니라, 훨씬 더 넓고 복잡한 질문으로 다가왔다.

솔라는 스케치북을 가만히 들여다보며 중얼거렸다.

“그럼 품질, 비용, 속도 말고 우리가 또 놓치고 있는 게 있을까? LLM 시스템의 운영 문제를 제대로 점검하려면, 도대체 ‘무엇을’ 빠짐없이 봐야 하는 거지?”

2장: LLM 운영의 4가지 문제 유형 파악하기

솔라의 펜 끝이 스케치북 위를 망설이며 맴돌았다. 페이지 한쪽에는 어제 루나와 함께 그렸던 그림이 남아 있었다. ‘품질(웃는 얼굴)’, ‘비용(₩ 기호)’, ‘속도(시계)’ 세 아이콘을 커다란 원 하나가 감싸고 있는 그림. 그 옆 빈 공간에 솔라는 방금 네 번째 사각형을 그리고 그 안에 물음표를 그려 넣었다.

어젯밤 이후로 머릿속을 떠나지 않던 질문, ‘또 놓치고 있는 게 있을까?’에 대한 답을 찾아보려 했지만 막막했다. 분명 품질, 비용, 속도만으로는 설명되지 않는 문제들이 있었다. 사용자들이 ‘봇이 가끔 엉뚱한 소리를 한다’고 불평하는 건 ‘품질’ 문제로 분류할 수 있었다. 하지만 가끔 서비스가 전체적으로 이상하게 꼬여버리는 느낌을 받을 때가 있었다. 그걸 뭐라고 불러야 할지, 어떤 상자에 넣어야 할지 감이 잡히지 않았다.

“흐음…”

낮은 신음과 함께 솔라가 펜을 내려놓자, 맞은편에서 조용히 책을 읽던 루나가 고개를 들었다. 솔라의 시선이 머무는 스케치북의 물음표를 본 루나가 물었다.

“네 번째 상자를 찾고 있구나.”

“응. 품질, 비용, 속도. 이건 이제 알겠어. 그런데 이걸로 다 설명이 안 되는 문제들이 있는 것 같아서. 예를 들면… 우리 요약 봇이 아주 가끔, 특정 종류의 뉴스 기사만 들어가면 자꾸 똑같은 문장을 반복하면서 요약을 끝내지 못하는 경우가 있대. 이건 품질이 나쁜 걸까? 속도가 느린 걸까? 애매하잖아.”

솔라는 자신이 겪었던 다른 경험도 떠올렸다.

“아, 최근에 여행 계획 짜주는 LLM 앱을 써봤는데, ‘제주도 2박 3일 코스 짜줘’라고 했더니 갑자기 서울 맛집을 검색해서 알려주더라고. 답변 자체는 멀쩡한 맛집 리스트였어. 품질도, 비용도, 속도도 괜찮았지. 근데 내가 원한 흐름이 아니었잖아. 이런 건 뭐라고 불러야 해?”

솔라의 말에 루나는 책을 덮고 테이블 위로 몸을 기울였다. 그녀는 솔라가 그린 물음표 상자를 손가락으로 가리켰다.

“솔라 네가 방금 답을 두 개나 말했어. ‘똑같은 문장을 반복하는 것’과 ‘원치 않는 흐름으로 빠지는 것’.”

루나는 스케치북을 자신 쪽으로 돌려 깔끔한 글씨로 목록을 정리하기 시작했다.

LLM 운영 문제 유형

품질 (Quality)
비용 (Cost)
성능 (Performance/Speed)

“여기까지가 우리가 어제 이야기한 세 가지.” 루나가 말했다. 그리고 이어서 네 번째 항목을 적어 내려갔다.

흐름 (Flow)

“흐름?” 솔라가 되물었다.

“응, 흐름. LLM 시스템이 정해진 작업 순서를 제대로 따라가지 못하거나, 비효율적인 경로로 빠지는 모든 문제를 말해. 네가 예로 든 ‘고장 난 레코드처럼 같은 문장을 반복하는 현상’이나, ‘제주도 여행을 물었는데 서울 맛집을 검색하는 것’ 모두 대표적인 흐름 문제야.”

루나는 ‘흐름’ 항목 아래에 작은 글씨로 몇 가지 예시를 덧붙였다. 불필요한 반복(loop), 잘못된 도구 호출.

순간 솔라의 머릿속에 안개가 걷히는 기분이었다. 자신이 애매하다고 느꼈던 문제들이 ‘흐름’이라는 이름 아래 제자리를 찾아가는 느낌이었다. 그동안 ‘품질’이라는 너무 큰 상자에 억지로 쑤셔 넣으려 했던 문제들의 정체가 선명해졌다.

“아…! 그렇구나. 답변의 내용 자체는 멀쩡해도, 그 답변을 만들어내는 ‘과정’이 꼬여버리는 문제구나. 작업 순서가 엉망이 되거나, 엉뚱한 길로 새어 나가는 거.”

솔라는 자신이 마주했던 문제들을 새로운 네 가지 분류에 맞춰 다시 생각해 보았다.

‘요약이 너무 딱딱하다’ → 품질 문제. ‘API 비용이 세 배로 늘었다’ → 비용 문제. ‘응답을 받는 데 너무 오래 걸린다’ → 성능 문제. ‘봇이 엉뚱한 기능을 실행한다’ → 흐름 문제.

“와…” 솔라의 입에서 감탄이 흘러나왔다. “이렇게 네 가지 틀로 보니까, 내가 마주한 문제들이 훨씬 명확하게 정리돼. 이제 어떤 문제가 발생하면, 이게 넷 중에 어디에 속하는지부터 진단할 수 있겠어. ‘무엇을 측정할지’에 대한 첫 번째 지도가 생긴 기분이야.”

솔라는 뿌듯한 얼굴로 자신이 그렸던 물음표를 지우고, 그 자리에 루나가 써준 ‘흐름’이라는 단어를 정성껏 옮겨 적었다. 이제 LLM 운영이라는 복잡한 세계를 탐험하기 위한 네 개의 나침반이 생긴 셈이었다. 프롬프트만 들여다보던 좁은 시야에서 벗어나, 시스템 전체를 조망할 수 있는 관점을 얻은 것이다.

한참 동안 완성된 네 가지 분류표를 들여다보던 솔라의 눈썹이 다시 미세하게 좁혀졌다. 새로운 질문이 고개를 들고 있었다.

“좋아, 이제 문제의 ‘종류’를 분류할 수는 있겠어. 그런데 말이야… 내 ‘느낌’이 그렇다는 거랑, 실제로 그 문제가 ‘발생했다’고 증명하는 건 다른 문제잖아? 예를 들어 그 챗봇이 진짜로 불필요한 반복에 빠졌는지, 얼마나 자주 그러는지 감이 아니라 데이터로 딱 보여주려면 어떻게 해야 하지?”

3장: 문제, 감이 아니라 데이터로 측정하기

솔라는 며칠째 머리를 싸매고 있던 스케치북을 다시 펼쳤다. 깔끔하게 정리된 네 가지 문제 유형—품질, 비용, 성능, 흐름—이 한눈에 들어왔다. 어지럽던 머릿속이 정리된 것 같아 잠시 뿌듯했지만, 곧 새로운 막막함이 밀려왔다. 솔라는 펜을 들어 각 항목 옆에 새로운 칸을 그렸다. 그리고 그 위쪽에 ‘증명 방법?’이라고 썼다.

이내 솔라의 펜이 움직이기 시작했다. ‘품질’ 문제 옆에는 ‘답변이 정확한지 사용자가 평가함’이라고 적었다. ‘성능’ 문제 옆에는 ‘사용자들이 느리다고 불평함’이라고 썼다. 하지만 쓰고 나서 보니 막막하기는 마찬가지였다. ‘정확하다’와 ‘느리다’는 것을 어떻게 숫자로 바꿀 수 있을까? ‘몇몇 사용자’는 도대체 몇 명을 말하는 걸까? 이건 증명이 아니라 그냥 의견 수렴에 가까웠다. 감으로 문제를 진단하던 처음의 상태와 다를 바가 없었다. 자신의 생각이 만든 감옥에 갇힌 기분이었다.

“결국 원점이네.”

솔라가 펜을 내려놓으며 중얼거렸다. 그 소리에 주방에서 커피를 내리던 루나가 고개를 돌렸다. 솔라의 스케치북을 잠시 들여다본 루나는 커피 잔을 들고 테이블 맞은편에 앉았다.

“지도만 가지고는 실제 길을 건널 수 없으니까.”

루나는 솔라가 ‘증명 방법?’이라고 적어놓은 부분을 손가락으로 가볍게 두드렸다.

“솔라, 네가 지금 하려는 건 두 종류의 다른 질문을 하나의 방법으로만 풀려는 것과 같아. ‘답변이 정확한가?’라는 질문과 ‘응답이 얼마나 빨랐나?’라는 질문은 성격이 완전히 다르지 않아?”

루나는 스케치북의 빈 공간에 선을 하나 그어 두 개의 영역으로 나누었다. 한쪽에는 ‘품질, 흐름’을, 다른 한쪽에는 ‘비용, 성능’이라고 적었다.

“비용과 성능은 비교적 간단해. ‘얼마나 썼나?’, ‘얼마나 걸렸나?’를 묻는 거니까. 이건 시스템이 작동하는 모든 과정을 발자국처럼 기록하고 추적하면 알 수 있어. 마치 마라톤 선수가 구간별 시간을 기록하는 것처럼 말이야.”

루나는 ‘비용, 성능’ 영역 아래에 ‘Trace(추적)’ 라고 썼다.

“아… Trace. 개발자 도구에서 본 적 있는 단어야. 시스템이 어떤 순서로, 각 단계에 시간을 얼마나 썼는지 보여주는 기록 같은 거.”

솔라의 머릿속에 복잡한 로그 화면이 스쳐 지나갔다. 전에는 의미 없는 데이터의 나열처럼 보였지만, 이제는 ‘비용’과 ‘성능’ 문제를 증명할 수 있는 보물 지도로 보이기 시작했다. 토큰 사용량, API 호출 시간 같은 것들이 모두 거기에 기록되어 있을 터였다.

“맞아. 그럼 이제 남은 질문. ‘품질’과 ‘흐름’은 어떻게 증명할까? ‘답변이 정확한가?’, ‘챗봇이 엉뚱한 도구를 호출하지는 않았나?’ 같은 문제들 말이야. 이건 발자국 기록만 봐서는 알 수 없잖아.”

루나의 질문에 솔라는 다시 생각에 잠겼다. Trace 데이터는 속도나 비용은 말해주지만, 답변 내용이 좋은지 나쁜지, 혹은 작업 흐름이 올바른지는 판단해주지 않는다.

“누군가 보고 판단해야겠지. 정답지와 비교해본다거나, 정해진 규칙을 잘 지켰는지 검사한다거나…”

“바로 그거야. 일종의 심판이 필요한 거지.”

루나는 ‘품질, 흐름’ 영역 아래에 ‘Evaluator(평가자)’ 라고 썼다.

“Evaluator는 정해진 기준에 따라 결과물의 좋고 나쁨, 과정의 옳고 그름을 판단해주는 자동화된 심판이야. 예를 들어 ‘답변에 욕설이 포함되어 있는가?’라는 간단한 규칙부터, ‘제시된 근거 문서를 기반으로 요약이 작성되었는가?’ 같은 복잡한 판단까지 할 수 있지.”

Trace와 Evaluator. 두 단어가 스케치북 위에서 선명하게 빛나는 것 같았다. 그제야 솔라는 자신이 왜 막막했는지 깨달았다. 성격이 다른 문제들을 하나의 잣대로만 재려고 했던 것이다. 속도를 재는 스톱워치로 답변의 품질을 잴 수는 없는 노릇이었다.

“그럼… 이렇게 정리할 수 있겠네. 우리 요약 봇의 문제를 다시 본다면…”

솔라는 펜을 고쳐 잡고, 자신이 마주했던 문제들을 새로운 도구와 연결하기 시작했다.

‘응답이 너무 느리다’는 불만 (성능 문제) → Trace로 각 사용자의 요청 처리 시간을 측정하고, 평균값이 특정 기준을 넘는지 확인.
‘API 비용이 급증했다’ (비용 문제) → Trace로 요청당 토큰 사용량을 추적하고, 비용 급증의 원인이 된 요청 패턴을 분석.
‘요약의 핵심 내용이 빠졌다’ (품질 문제) → Evaluator를 만들어, 원문과 요약문을 비교하며 핵심 키워드 포함 여부를 자동으로 평가.
‘봇이 가끔 엉뚱한 기능을 실행한다’ (흐름 문제) → Evaluator를 통해, 챗봇의 작업 계획이 사용자의 초기 의도와 일치하는지 단계별로 검사.

“와…”

막연했던 ‘느낌’과 ‘불평’들이 구체적인 숫자와 ‘Pass/Fail’ 점수로 바뀌는 그림이 머릿속에 그려졌다. 솔라는 루나가 맨 처음 그렸던 커다란 사각형—모든 것을 담는 모니터 화면—을 다시 떠올렸다.

“그럼 Trace로 수집된 시간과 비용 데이터, 그리고 Evaluator가 매긴 품질과 흐름 점수들을… 한곳에서 모아볼 수 있는 화면이 있다면! 마치 자동차 계기판처럼!”

“그게 바로 ‘운영 대시보드’ 지.”

루나가 미소 지으며 솔라의 스케치북에 그려진 모든 요소들을 커다란 사각형으로 감쌌다. 솔라는 그 사각형을 보며 가슴이 뛰는 것을 느꼈다. 더 이상 감에 의존하지 않아도 되었다. 데이터라는 명확한 언어로 시스템의 건강 상태를 진단하고, 문제의 심각성을 정확히 파악할 수 있는 방법이 눈앞에 펼쳐진 것이다. ‘무엇을 측정할지’에 대한 지도가 마침내 완성된 순간이었다.

솔라는 잠시 만족스럽게 대시보드를 내려다보다가, 문득 계기판의 경고등을 떠올렸다.

“좋아, 이제 대시보드에 ‘품질 저하’라고 빨간불이 떴다고 치자. 원인이 뭔지 데이터로 정확히 알게 됐어. 그럼… 이제 내가 할 일은 역시 프롬프트를 고치는 것뿐일까? 이 모든 문제를 해결하는 열쇠가 결국엔 다 프롬프트 수정 하나로 통하는 걸까?”

4장: 개선은 프롬프트 너머, 4가지 레버 활용법

솔라는 자신의 스케치북을 만족스럽게 내려다보았다. 지난 며칠간의 고민이 한 장의 그림으로 깔끔하게 정리되어 있었다. 왼쪽에는 ‘품질, 비용, 성능, 흐름’이라는 네 가지 문제 유형이, 오른쪽에는 ‘Trace’와 ‘Evaluator’라는 두 개의 측정 도구가 자리 잡고 있었다. 문제와 도구들은 화살표로 연결되어, 어떤 문제를 어떤 도구로 측정할 수 있는지 명확히 보여주었다.

하지만 그림의 가장 중심에는, 모든 화살표가 향하는 단 하나의 커다란 상자가 있었다. 솔라는 그 안에 ‘프롬프트 개선’이라고 힘주어 써넣었다. 마치 모든 길은 로마로 통하듯, 모든 운영 문제는 결국 프롬프트 개선으로 귀결된다는 그녀의 현재 믿음을 보여주는 그림이었다. 대시보드에 어떤 경고등이 켜지든, 원인을 어떤 데이터로 파악하든, 해결책은 결국 하나라고 생각했다. 망치를 든 사람에게는 모든 것이 못으로 보이는 법이니까. 솔라는 이제 ‘프롬프트 엔지니어링’이라는 망치를 아주 잘 다룰 수 있을 것 같았다.

“그럼 이제 모든 문제에 대한 답을 찾은 건가?”

옆에서 솔라의 그림을 잠시 들여다보던 루나가 나지막이 물었다. 그녀의 질문은 칭찬도 비판도 아니었지만, 솔라는 순간 자신의 그림에 확신이 흔들리는 것을 느꼈다.

“아니, 그럴 리가. 언니는 항상 내가 놓친 걸 찾아내잖아.” 솔라가 웃으며 말했다. “그래도 이건 꽤 명확하지 않아? 어떤 문제든 데이터로 원인을 찾았으면, 그 원인을 해결하도록 프롬프트를 고치면 되잖아.”

루나는 고개를 끄덕이는 대신, 펜을 들어 솔라의 그림 옆에 작은 시나리오를 그리기 시작했다. 여행 계획 챗봇 그림과 함께, ‘제주도 여행’이라는 사용자 질문이 적혔다. 하지만 챗봇의 말풍선에는 ‘서울 맛집 검색 중…’이라는 엉뚱한 내용이 들어 있었다. 전형적인 ‘흐름’ 문제였다.

“자, 이 문제를 해결해야 해. 대시보드에서 ‘잘못된 도구 호출’ 경고등이 계속 깜빡이고 있어. 솔라, 네가 가진 망치, 즉 프롬프트로 이 못을 박아보겠어?”

솔라는 자신만만하게 대답했다. “쉽지. 프롬프트를 훨씬 더 강력하게 만들면 돼. ‘사용자가 제주도 관련 질문을 하면, 절대로 서울 맛집 검색 도구를 사용해서는 안 된다. 오직 제주도 관련 도구만 사용해야 한다!’ 이렇게 대문자로 강조하고, 규칙을 여러 번 반복해서 알려주는 거야.”

“좋은 시도야.” 루나가 말했다. 하지만 그녀의 펜은 멈추지 않았다. “그렇게 프롬프트를 바꿨더니, 실제로 오류가 90% 줄었어. 하지만 여전히 10%의 사용자는 가끔 서울 맛집을 추천받고 있어. 완벽히 사라지지가 않아. 어떻게 할래?”

“음… 프롬프트를 더 정교하게… ‘서울이라는 단어가 언급되어도, 사용자의 최종 목적지가 제주도이면 무시해야 한다’ 같은 예외 규칙을 더 추가해야지.”

솔라의 목소리는 조금씩 작아지고 있었다. 프롬프트에 규칙을 덕지덕지 붙이는 모습이 머릿속에 그려졌다. 그것이 과연 똑똑한 해결책일까? 마치 구멍 난 댐을 손가락으로 계속 막고 있는 기분이었다.

루나는 솔라의 고민을 읽은 듯, 펜으로 ‘프롬프트 개선’이라고 쓰인 상자를 가리켰다.

“프롬프트는 LLM에게 보내는 ‘지시문’이야. 하지만 아무리 지시를 잘해도, 작업자(LLM)가 가끔 실수를 하거나 지시를 오해할 수 있어. 그렇다면 지시문만 계속 고쳐 쓰는 게 유일한 방법일까?”

루나는 ‘프롬프트 개선’ 상자 옆에 새로운 상자를 하나 더 그렸다.

“만약 작업자에게 ‘서울 맛집 검색 도구’ 자체를 쥐여주지 않는다면 어떨까? 애초에 잘못된 도구를 쓸 가능성을 원천 차단하는 거야.” 루나는 새 상자 안에 ‘구조(Workflow) 개선’ 이라고 썼다. “사용자 질문에서 ‘제주도’라는 키워드가 감지되면, 시스템의 작업 흐름, 즉 구조 자체를 바꿔서 서울 관련 도구는 아예 접근 불가능하게 만드는 거지. 지시문이 아니라 시스템의 설계를 바꾸는 거야.”

솔라의 눈이 커졌다. 망치 외에 다른 도구가 있다는 것을 처음 본 순간이었다.

루나는 멈추지 않고 세 번째 상자를 그렸다. “아니면 이런 방법도 있어. 챗봇이 ‘서울 맛집을 검색할게요’라는 계획을 세웠을 때, 바로 실행하지 못하게 막는 거야. 실행 전에 ‘이 계획이 사용자의 원래 질문과 관련이 있는가?’를 확인하는 규칙을 추가하는 거지.” 루나는 상자 안에 ‘정책(Decision Policy) 개선’ 이라고 적었다. “마치 공항의 보안 검색대처럼, 위험하거나 엉뚱한 행동은 통과시켜주지 않는 결정 정책을 두는 거야.”

마지막으로 루나는 네 번째 상자를 그리며 말했다. “그리고 우리가 ‘잘못된 도구 호출’을 어떻게 알았지? Evaluator 덕분이었지. 만약 우리의 Evaluator가 엉성해서, 진짜 잘못된 호출은 놓치고 애매한 것만 잡아낸다면? 그럼 우리는 엉뚱한 문제를 해결하느라 시간을 낭비하게 될 거야. 때로는 해결책 자체가 아니라, 문제를 진단하는 평가 기준을 더 날카롭게 만드는 것이 가장 중요한 개선일 수 있어.” 루나는 네 번째 상자에 ‘데이터 & 평가 기반 개선’ 이라고 썼다.

솔라는 멍하니 네 개의 상자를 바라보았다.

프롬프트 개선: LLM에게 보내는 지시문 수정
구조 개선: 작업 흐름이나 시스템 설계 변경
정책 개선: 행동을 제어하는 규칙 추가/변경
데이터 & 평가 기반 개선: 문제 자체를 정의하는 기준점 수정

지금까지 그녀가 전부라고 생각했던 ‘프롬프트 개선’은 거대한 기계를 고치는 수많은 ‘레버’ 중 하나에 불과했다. 어떤 문제는 프롬프트라는 레버로 쉽게 해결되지만, 어떤 문제는 구조나 정책이라는 다른 레버를 당겨야만 해결되는 것이었다. ‘잘못된 도구 호출’ 문제는 프롬프트를 아무리 강화해도 완벽히 막기 힘든, ‘구조’나 ‘정책’의 레버로 해결해야 하는 문제였던 것이다.

“아…”

솔라는 루나의 펜을 받아, 자신이 그렸던 그림을 수정하기 시작했다. ‘흐름 문제’에서 뻗어 나온 화살표를 지우고, ‘구조 개선’과 ‘정책 개선’ 상자로 새롭게 연결했다. ‘비용 문제’는 ‘프롬프트 개선’(짧은 답변 유도)으로도 해결할 수 있지만, ‘정책 개선’(비용 한도 초과 시 저렴한 모델 사용)으로도 해결할 수 있었다. 문제 하나에 연결될 수 있는 해결책 레버가 여러 개일 수도 있었다.

‘어떻게 개선할지 정하기’라는 문장이 완전히 새로운 의미로 다가왔다. 이것은 단순히 프롬프트를 고치는 기술을 묻는 것이 아니었다. 주어진 문제에 가장 적합한 개선 ‘레버’를 선택하고 당길 줄 아는 능력을 묻는 것이었다. 솔라는 더 이상 망치만 든 사람이 아니었다. 이제 막 4개의 각기 다른 레버가 달린 제어판 앞에 선 시스템 운영자가 된 기분이었다.

솔라는 완성된 그림을 보며 뿌듯함을 느꼈다. 문제의 종류, 측정 도구, 그리고 이제 개선을 위한 다양한 레버까지. 모든 조각들이 제자리를 찾은 것 같았다. 하지만 그 순간, 새로운 질문이 머릿속을 스쳤다.

“좋아, 이제 내 앞에 문제 유형, 측정 대시보드, 그리고 4가지 개선 레버가 모두 놓여 있어. 모든 부품은 다 모였는데… 이걸 어떤 순서로 움직여야 하지? 문제가 생기면 일단 아무 레버나 당겨보고, 대시보드 보고, 또 다른 레버 당겨보고… 이렇게 주먹구구식으로 하는 건 아닐 거 아냐? 이 모든 걸 하나로 묶어서, 계속 돌아가게 만드는 체계적인 ‘과정’ 같은 게 있지 않을까?”

5장: 지속 가능한 LLM 운영: LLMOps 개선 루프 완성하기

솔라의 책상 위는 여러 장의 스케치북 페이지와 색색의 메모지로 가득했다. 마치 복잡한 사건 현장을 분석하는 탐정의 작업대 같았다. 지난 며칠간 루나와 함께 정리한 개념들이 메모지 하나하나에 적혀 있었다. ‘품질 문제’, ‘비용 문제’ 같은 문제 유형들, ‘Trace’, ‘Evaluator’ 같은 측정 도구들, 그리고 ‘프롬프트 개선’, ‘구조 개선’ 같은 네 가지 개선 레버까지. 솔라는 이 모든 조각들을 체계적으로 연결해 보려고 애쓰고 있었다.

하지만 결과물은 썩 만족스럽지 않았다. 솔라가 그린 다이어그램은 시작과 끝이 있는 직선적인 형태였다. ‘문제 발생’에서 시작된 화살표는 ‘측정’을 거쳐 ‘개선’으로 이어졌고, 거기서 멈춰 있었다. 문제가 생기면, 원인을 분석하고, 해결책을 적용하면 끝. 마치 일회성 프로젝트처럼 보였다. 이 그림대로라면 개선 활동은 문제가 생길 때마다 임시방편으로 수행하는 단발성 작업에 불과했다. 모든 부품은 다 모았는데, 조립하고 나니 어딘가 어색하고 불안정한 기계가 된 느낌이었다.

“이게 아닌데…”

솔라가 펜 뒤쪽으로 머리를 긁적이며 중얼거렸다. 그 모습을 지켜보던 루나가 다가와 솔라가 그린 다이어그램을 들여다보았다.

“다이어그램이 ‘개선’에서 멈춰 있네. 개선하고 나면, 그 시스템은 영원히 완벽해지는 걸까?”

루나의 한마디가 정곡을 찔렀다. 솔라는 자신의 그림에 빠져있던 치명적인 허점을 깨달았다. ‘개선’을 적용하고 나면, 그 시스템은 또다시 운영된다. 그러다 보면 언젠가 새로운 문제가 발생하거나, 기존 문제가 다른 형태로 다시 나타날 수 있다. 자신의 모델은 이 ‘반복’을 담아내지 못하고 있었다. 개선 활동이 파편처럼 흩어져 있을 뿐, 서로 연결되어 계속해서 돌아가는 힘을 만들지 못했다.

루나는 말없이 스케치북의 깨끗한 페이지를 펼쳤다. 그리고 중앙에 커다란 화살표 고리, 즉 순환하는 루프(Loop)를 그렸다. 단방향으로 흐르다 멈춰버린 솔라의 다이어그램과는 전혀 다른 모양이었다.

“네가 가진 조각들을 여기에 한번 배치해볼까?”

루나는 루프의 다섯 지점을 가리키며 각각의 이름을 적어주었다. 설계(Design), 실행(Run), 관측(Trace), 평가(Evaluate), 개선(Improve).

솔라는 잠시 그 단어들을 쳐다보다가, 이내 자신의 메모지들을 집어 들기 시작했다. 이것은 이전에 다룬 모든 개념들을 재조립하는 거대한 퍼즐이었다.

먼저, ‘Trace’와 ‘운영 대시보드’ 메모지를 들어 관측(Trace) 영역에 놓았다. 시스템이 작동하는 모든 발자국을 기록하고 지켜보는 단계라는 것이 명확했다. 이어서 ‘Evaluator’ 메모지는 평가(Evaluate) 영역으로 옮겼다. 관측된 데이터를 바탕으로 결과물의 좋고 나쁨을 판단하는 심판의 자리였다.

“그리고… 여기서 발견된 문제를 해결하는 게 바로 ‘개선’이지.”

솔라는 ‘프롬프트’, ‘구조’, ‘정책’, ‘데이터&평가 기반’ 네 가지 개선 레버 메모지를 모두 개선(Improve) 영역에 차곡차곡 쌓았다. 그러자 루프의 다음 단계가 보였다. 개선된 내용은 새로운 설계(Design) 에 반영되어, 다시 실행(Run) 된다. 그리고 그 실행 과정은 또다시 관측 되고 평가 받는다.

모든 조각이 제자리를 찾은 순간, 솔라의 입에서 나지막한 탄성이 터져 나왔다.

“아…! 이건 선이 아니라 고리였구나. 끝이 있는 작업이 아니라, 계속해서 돌아가는 바퀴였어.”

문제 파악, 측정, 개선 활동은 결코 단발성으로 끝나지 않았다. 하나의 개선이 또 다른 관측과 평가의 대상이 되고, 그 결과가 다시 다음 개선으로 이어지는, 살아있는 유기체 같은 순환 과정이었다. 이것이 바로 ‘지속 가능한’ 운영의 핵심이었다. 솔라는 자신이 처음 프로젝트 관리 도구에서 보았던 ‘운영에서 무엇을 측정하고 어떻게 개선할지 정하기’라는 문장이, 바로 이 끝없는 순환 루프 전체를 의미했음을 비로소 깨달았다.

솔라는 벅찬 마음으로 자신의 ‘LLM 요약 봇’을 떠올렸다. 더 이상 ‘프롬프트 고치기’라는 단편적인 작업으로 보이지 않았다. 이제는 이 개선 루프 위에서 관리해야 할 살아있는 시스템으로 느껴졌다.

솔라는 펜을 들어, 루나가 그려준 루프 옆에 자신만의 개선 루프 초안을 그리기 시작했다.

<LLM 요약 봇 운영 개선 루프 v0.1>

관측/평가: ‘요약 결과가 딱딱하다’는 사용자 피드백(품질 문제)을 Evaluator로 자동 측정. (목표: ‘친근함’ 점수 70점 이상)
개선:
- 1순위: 프롬프트 레버 사용. 친근한 말투 지시 강화.
- 2순위: 구조 레버 고려. 뉴스 카테고리(정치/연예)에 따라 다른 프롬프트 적용.
설계/실행: 개선된 프롬프트 v2를 적용하여 시스템 재배포.
다시 관측/평가로…

자신이 직접 그린 루프를 보며 솔라는 미소 지었다. 이것은 단순히 지식을 정리한 노트가 아니었다. 앞으로 자신이 맡은 시스템을 책임지고 계속해서 더 나은 방향으로 이끌어갈 구체적인 행동 계획이자, 운영자로서의 새로운 다짐이었다. 이제 솔라는 망치만 든 사람이 아니었다. 끊임없이 돌아가는 개선의 바퀴를 움직이는, 시스템의 진정한 주인이 될 준비를 마친 것이다.