2장. 어떤 문제를 LLM으로 풀어야 하는가

1장에서 우리는 LLM 서비스가 왜 기존 웹 서비스와 다르게 느껴지는지 살펴봤다. 출력은 흔들리고, 비용은 요청마다 생기며, 품질은 정답 여부만으로 평가하기 어렵다. 그렇다면 바로 다음 질문이 나온다. 그런 성질을 가진 도구를 도대체 어디에 써야 하는가?

이 질문에 제대로 답하지 못하면 팀은 금방 이상한 길로 들어선다. 검색창이 있는 곳마다 챗봇을 붙이고, 버튼이 있는 곳마다 "AI로 자동화"를 넣고, 사용자가 한 번도 불편하다고 느낀 적 없는 화면에도 요약 기능을 덧붙인다. 데모는 화려해 보이지만 운영에 들어가면 남는 것은 비용, 느린 응답, 애매한 품질, 그리고 "그래서 이게 왜 필요한데?"라는 질문뿐이다.

LLM은 분명 강력하다. 하지만 강력한 도구일수록 더 조심해서 써야 한다. 망치가 좋다고 해서 모든 문제가 못은 아니다. LLM도 마찬가지다. 어떤 문제에서는 놀랄 만큼 큰 가치를 만들고, 어떤 문제에서는 그럴듯한 소음만 늘린다. 이 장의 목표는 그 차이를 구분하는 기준을 세우는 것이다.

핵심 문장은 간단하다. 모든 문제에 LLM을 붙이면 비용만 늘고, 맞는 문제를 고를 때만 제품이 된다.

문제를 잘 고르는 팀이 결국 이긴다

많은 팀이 LLM 도입을 모델 선택에서 시작한다. 어떤 벤더를 쓸지, 어떤 모델이 더 똑똑한지, 가격은 어떤지부터 본다. 물론 나중에는 중요한 질문이다. 하지만 초반에 더 중요한 것은 그보다 앞선 질문이다.

"우리 사용자가 지금 실제로 겪는 불편은 무엇인가?"

"그 불편은 언어 처리로 줄일 수 있는가?"

"정확도 100점이 아니어도 충분히 쓸모가 있는가?"

이 순서를 바꾸면 일이 이상해진다. 모델이 먼저 오면 문제를 억지로 거기에 끼워 맞추게 된다. 그러면 사용자의 고통이 아니라 기술 데모가 중심이 된다. 제품은 멋있어 보일 수 있지만 오래 살아남기 어렵다.

좋은 LLM 제품은 대개 화려한 곳이 아니라 지루한 곳에서 탄생한다. 매일 반복되는 문의 답변, 문서 초안 작성, 긴 회의록 정리, 애매한 카테고리 분류, 비슷한 문서 재작성처럼 사람의 시간이 계속 들어가지만 완전히 자동화하기는 애매했던 업무들이다. 이런 영역에서는 LLM이 마법처럼 보이기보다, 사람이 하던 언어 노동을 적당한 품질로 빠르게 덜어주는 도구로 작동한다. 실무에서는 바로 이 지점이 돈이 된다.

LLM이 잘 푸는 문제의 공통점

LLM이 잘하는 일을 한마디로 줄이면 이렇다. 언어를 읽고, 압축하고, 바꾸고, 이어서 쓰는 일이다. 숫자를 정확히 계산하는 기계라기보다, 복잡한 언어 덩어리에서 형태를 바꾸어 새 출력으로 만드는 엔진에 가깝다.

이 특성을 이해하면 어떤 문제에 강한지 자연스럽게 보인다.

첫째, 긴 정보를 짧고 읽기 쉽게 줄이는 문제

사람은 긴 텍스트를 읽는 데 시간이 걸린다. 계약서, 회의록, 고객 상담 내역, 운영 로그 설명, 내부 문서, 보고서 초안은 전부 읽는 순간부터 피곤하다. 그런데 업무에서는 그 안의 핵심만 빨리 알고 싶은 경우가 많다.

LLM은 이런 압축 작업에 강하다. 핵심 요점만 뽑기, 한 문단으로 요약하기, 액션 아이템만 추출하기, 의사결정 사항만 정리하기 같은 작업이 여기에 들어간다. 완벽한 한 줄 정답이 아니라도 가치가 생기기 쉽다. 사용자는 보통 "완벽한 요약"보다 "5분 걸릴 일을 30초로 줄여주는 요약"을 원하기 때문이다.

예를 들어 영업팀이 고객 미팅 후 남긴 긴 메모를 생각해보자. 원문은 중복도 많고 순서도 뒤죽박죽일 수 있다. 하지만 다음 행동, 고객 요구사항, 리스크만 정리되면 바로 쓸 수 있다. LLM은 이런 종류의 정리에 꽤 잘 맞는다.

중요한 점은, 이 문제의 정답이 하나가 아니라는 것이다. 같은 문서를 두 사람이 요약해도 문장은 달라질 수 있다. 그런데도 둘 다 쓸모 있을 수 있다. 바로 이런 영역이 LLM의 자연스러운 놀이터다.

둘째, 같은 의미를 다른 표현으로 바꾸는 문제

재작성은 LLM이 특히 잘하는 분야다. 문장을 더 공손하게 바꾸기, 더 짧게 바꾸기, 더 쉽게 설명하기, 이메일 문체로 바꾸기, 보고서 톤으로 바꾸기, 광고 문구 후보 여러 개 만들기 같은 일이다.

이 작업은 사람이 직접 해도 가능하지만 은근히 시간이 많이 든다. 특히 초안을 다듬는 일은 머리를 많이 쓰는 데 비해 결과는 비슷비슷하게 나오는 경우가 많다. 이런 반복적인 표현 변환은 LLM이 크게 도움을 줄 수 있다.

여기서 가치가 생기는 이유는 단순하다. 사람은 "무에서 유를 만드는 것"보다 "어느 정도 나온 초안을 고치는 것"을 훨씬 빠르게 할 수 있기 때문이다. 즉, LLM이 완성품을 못 만들더라도 초안을 잘 뽑아주면 충분히 유용하다.

실무에서는 이 차이가 크다. 마케팅 카피, 고객 응답 초안, 채용 공고 수정, 상품 설명 재작성, 블로그 초안 정리 같은 일들은 최종 승인이 사람에게 있더라도 LLM이 앞단을 맡으면 생산성이 크게 올라간다.

셋째, 애매한 기준을 따라 분류하거나 정리하는 문제

규칙 기반 시스템은 명확한 조건에 강하다. 하지만 실제 업무에는 "대충 보면 알겠는데 코드로 쓰기는 귀찮은" 판단이 많다. 문의 내용을 환불·배송·기술 문제로 나누기, 리뷰를 긍정·부정·중립으로 나누기, 지원서를 직무별로 1차 분류하기, 회의 메모를 주제별로 묶기 같은 일이다.

이런 작업은 사람에게는 쉬워 보여도, 규칙으로 만들면 금방 복잡해진다. 표현이 다양하고 예외가 많기 때문이다. LLM은 자연어 문맥을 통째로 읽고 대략적인 의미를 파악하는 데 강하므로, 이런 분류 작업에 꽤 효과적이다.

물론 여기에도 조건이 있다. 분류 결과가 치명적인 결정으로 바로 이어지지 않아야 하고, 틀렸을 때 수정 가능한 흐름이 있어야 한다. 예를 들어 고객 문의를 우선 담당 팀으로 라우팅하는 1차 분류는 LLM에 잘 맞을 수 있다. 하지만 대출 승인처럼 법적·재무적 결과가 직접 달린 최종 판단은 전혀 다른 문제다.

넷째, 사람의 질문을 더 다루기 쉬운 형태로 바꾸는 문제

사용자는 시스템이 이해하기 쉬운 방식으로 말하지 않는다. 하고 싶은 말을 길게 하기도 하고, 필요한 정보는 빼먹기도 하며, 질문과 감정을 한꺼번에 섞어 말한다. "지난달 결제 이상한 것 같은데 환불도 가능한지 확인해줘요"처럼 여러 의도가 한 문장에 들어오기도 한다.

LLM은 이런 입력을 정리하는 중간 계층으로 유용하다. 사용자의 자유 입력을 구조화된 의도, 슬롯, 카테고리, 질의 요약으로 바꾸면 그다음부터는 일반적인 백엔드 로직과 연결하기 쉬워진다.

즉, LLM이 최종 답을 다 만드는 것이 아니라, 사람의 언어를 시스템의 언어로 번역하는 인터페이스 역할을 하는 것이다. 이 패턴은 서비스에서 매우 강력하다. 왜냐하면 사용자는 편하게 말하고, 시스템은 정리된 형식으로 처리할 수 있기 때문이다.

다섯째, 정답보다 초안이 중요한 문제

많은 업무는 완성본보다 초안을 빨리 만드는 것이 더 중요하다. 제안서의 첫 문단, 공지사항 초안, FAQ 초안, 회신 문구 초안, 기능 명세의 뼈대 같은 것들이다. 처음 한 줄을 쓰는 것이 가장 어렵기 때문이다.

이런 문제에서 LLM은 매우 실용적이다. 결과가 완벽하지 않아도 사람의 시작 비용을 크게 줄여준다. 특히 전문가가 최종 검토하는 환경에서는 가치가 더 커진다. 법무팀, 영업팀, 마케팅팀, 운영팀 모두 "빈 문서 앞에서 멈추는 시간"이 있다. LLM은 이 멈춤을 줄이는 도구로 쓸 때 힘을 발휘한다.

여기서 중요한 것은 자동화율이 아니다. 100퍼센트 자동화가 아니어도 된다. 초안을 70퍼센트 수준으로 잘 만들어서 사람 검토 시간을 절반으로 줄이면 이미 제품 가치가 생긴다.

LLM이 못 푸는 문제의 공통점

반대로 LLM이 잘 맞지 않는 문제들도 분명하다. 이런 영역은 기술적으로 불가능하다는 뜻이 아니라, 서비스로 만들었을 때 위험과 비용이 이익보다 커지기 쉽다는 뜻이다.

첫째, 항상 같은 정답이 나와야 하는 문제

세금 계산, 정산 로직, 재고 차감, 권한 판정, 결제 승인, 배송비 계산처럼 결과가 결정적이어야 하는 문제는 기본적으로 LLM의 영역이 아니다. 같은 입력이면 같은 결과가 나와야 하고, 예외 없이 정확해야 하며, 결과를 나중에 설명할 수 있어야 한다.

이런 문제에 LLM을 넣으면 처음에는 편해 보일 수 있다. 자연어로 규칙을 설명하면 알아서 처리해줄 것 같기 때문이다. 하지만 실제 서비스에서는 재현 가능성과 정확성이 더 중요하다. 숫자 하나가 틀리면 안 되고, 경계 조건에서 흔들리면 안 되며, 왜 그런 결과가 나왔는지 추적할 수 있어야 한다.

즉, 결정적 로직은 기존 코드와 규칙 엔진의 자리다. LLM은 그 주변 설명을 돕거나 입력 해석을 보조할 수는 있어도, 핵심 판정 자체를 맡기면 곤란하다.

둘째, 작은 실수도 큰 사고가 되는 문제

의료 진단, 법률 판단, 금융 승인, 안전 제어처럼 틀렸을 때 피해가 큰 문제는 특히 조심해야 한다. LLM은 그럴듯하게 말하는 데 능숙하므로, 사용자가 틀린 답을 너무 쉽게 믿을 위험이 있다.

물론 이런 영역에서도 LLM을 전혀 못 쓰는 것은 아니다. 문서 검색 보조, 상담 초안 작성, 기록 요약, 내부 검토 지원처럼 사람 전문가를 돕는 보조 도구로는 쓸 수 있다. 문제는 최종 판단자처럼 보이게 만드는 순간이다.

사용자는 말투가 자신감 있으면 정확하다고 착각한다. 바로 이 점이 위험하다. 서비스 설계에서는 "틀릴 수 있다"는 사실보다 "사람이 틀린 줄 모르고 쓸 수 있다"는 사실이 더 중요하다.

셋째, 입력 정보가 부족한데도 정답을 요구하는 문제

LLM은 빈칸을 메우는 성향이 있다. 문맥이 부족하면 "모르겠습니다"보다 그럴듯한 추정을 내놓기 쉽다. 그래서 근거가 충분하지 않은 상황에서 확정적 답을 해야 하는 문제는 잘 맞지 않는다.

예를 들어 사내 문서 접근 없이 회사 정책을 답하게 하거나, 최신 주문 상태 조회 없이 배송 상황을 추측하게 하거나, 사용자 계정 정보 없이 맞춤형 조언을 하게 하면 문제가 생긴다. 이때 필요한 것은 더 좋은 프롬프트만이 아니다. 아예 외부 데이터 연결, 내부 시스템 조회, 명시적 근거 제시 같은 구조가 필요하다.

다시 말해, 정보가 없는데 답만 잘하길 기대하는 것은 무리다. LLM은 똑똑한 척할 수는 있지만, 없는 데이터를 기적처럼 만들어내지는 못한다.

넷째, 사용 빈도가 낮고 고통도 약한 문제

이 부분은 기술보다 제품 감각에 가깝다. 어떤 기능은 시연할 때는 반응이 좋다. "와, 이것도 되네요?"라는 말이 나온다. 하지만 실제 사용 빈도는 낮고, 사용하지 않아도 큰 불편이 없다. 이런 기능은 운영 비용만 먹는 장식이 되기 쉽다.

예를 들어 사용자가 1년에 한 번 볼까 말까 한 화면에 장문의 AI 설명을 붙이는 경우가 그렇다. 재미는 있을 수 있다. 그러나 사용자가 그것 때문에 돈을 내거나, 서비스에 더 오래 머물거나, 중요한 업무를 더 빨리 끝내는가를 따지면 답이 약하다.

LLM 기능은 버튼 하나당 원가가 붙을 수 있다. 그러니 "재미있다"와 "가치가 있다"를 반드시 구분해야 한다.

다섯째, 문제는 언어가 아닌데 해결책만 LLM인 경우

가끔 팀은 진짜 문제를 잘못 진단한다. 사용자가 정보를 못 찾는 것이 아니라 메뉴 구조가 엉망인데 챗봇을 붙인다. 상품 비교가 어려운 것이 아니라 데이터 정리가 안 되어 있는데 요약 기능부터 만든다. 고객 문의가 많은 이유가 정책이 복잡해서인데, 답변 생성기만 강화한다.

이런 경우 LLM은 문제를 해결하기보다 가린다. 사용자 경험의 뿌리 문제는 그대로인데, 앞단에 그럴듯한 말솜씨를 얹어놓는 셈이다. 물론 잠시 효과가 있을 수는 있다. 하지만 결국 사용자는 더 빨리 핵심 문제를 느낀다.

LLM은 서비스의 문제를 해결하는 도구이지, 서비스 기획의 부실함을 덮는 페인트가 아니다.

제품 가치가 나는 업무를 고르는 기준

그렇다면 실무에서는 무엇을 기준으로 판단해야 할까. 가장 쉬운 방법은 "이 기능이 신기한가?"가 아니라 "이 기능이 반복되는 비용을 줄이거나 성과를 올리는가?"를 묻는 것이다. 여기서는 실제로 제품 가치가 날 가능성이 높은 업무의 조건을 정리해보자.

자주 발생해야 한다

아무리 멋진 기능도 한 달에 두 번 쓰이면 제품 가치가 약하다. 반대로 아주 단순한 기능이라도 하루에 수백 번 반복되면 강력한 가치가 된다. LLM은 특히 반복적인 언어 노동에서 힘을 발휘한다.

고객 상담 초안, 영업 메모 요약, 문의 분류, 문서 재작성, 내부 문서 검색 보조가 대표적이다. 이런 작업은 매일 쌓이고, 조금만 빨라져도 누적 절감 효과가 크다. 제품은 결국 반복 위에서 돈을 번다.

사람이 이미 시간을 많이 쓰고 있어야 한다

LLM 도입 전에도 사람의 비용이 존재해야 한다. 그래야 대체나 보조의 가치가 계산된다. 만약 지금도 아무도 하지 않는 일을 AI가 대신해주는 것이라면, 생각보다 가치가 낮을 수 있다. 원래 중요하지 않던 일이기 때문이다.

좋은 후보는 대개 "다들 귀찮아하지만 꼭 해야 하는 일"이다. 예를 들어 상담원이 매번 비슷한 문장을 손으로 쓰고 있다면, 답변 초안 기능은 명확한 가치를 만든다. 반면 누구도 신경 쓰지 않던 소개 문구를 AI가 매번 새롭게 써준다고 해서 바로 매출이 오르지는 않는다.

80점 결과물도 쓸모가 있어야 한다

LLM은 종종 100점보다 80점에 가깝다. 그래서 문제 선택이 중요하다. 80점 초안만으로도 충분히 시간을 절약할 수 있는 업무는 LLM에 잘 맞는다. 반대로 99.99점이 아니면 사고가 나는 업무는 잘 맞지 않는다.

이 기준은 아주 현실적이다. 사람이 나중에 검토해도 되는가? 틀리면 수정 비용이 감당 가능한가? 조금 어색해도 목적 달성이 가능한가? 이런 질문에 "그렇다"라고 답할 수 있으면 가능성이 크다.

결과를 평가하고 개선할 수 있어야 한다

좋은 LLM 기능은 품질이 눈에 보인다. 요약이 너무 길면 알 수 있고, 분류가 자주 틀리면 수정 로그가 남고, 초안이 채택되지 않으면 사용률이 떨어진다. 즉, 무엇이 잘되고 무엇이 안 되는지 추적 가능한 문제여야 한다.

반대로 성공 기준이 모호하면 개선이 어렵다. 사용자가 "그냥 좀 별로예요"라고만 느끼고 끝나면, 팀은 어떤 방향으로 다듬어야 할지 알기 어렵다. 실무에서는 측정 가능한 문제를 선택하는 것이 매우 중요하다.

예를 들어 "회의록을 더 똑똑하게 만들어준다"보다 "회의 후 액션 아이템 정리 시간을 10분에서 2분으로 줄인다"가 훨씬 좋은 문제 정의다.

기존 시스템과 연결될수록 강해진다

LLM 단독 기능보다, 기존 데이터와 워크플로에 붙는 기능이 보통 더 강하다. 회사 문서, 고객 기록, 주문 정보, 상품 데이터, 내부 정책과 연결되면 결과는 훨씬 실용적이 된다. 사용자는 일반적인 조언보다 자기 상황에 맞는 실행 가능한 결과를 원하기 때문이다.

바꿔 말하면, 공개 모델의 일반 지능만으로 만드는 제품은 쉽게 비슷해진다. 반면 특정 도메인의 데이터와 업무 흐름에 깊게 붙은 기능은 차별화되기 쉽다. 제품 가치가 나는 지점도 대개 거기다.

사람이 개입할 자리가 남아 있어야 한다

흥미롭게도 완전 자동화보다 반자동화가 더 좋은 출발점인 경우가 많다. 사람이 검토하고 승인할 수 있으면 위험이 줄고, 품질 학습도 쉬워진다. 특히 초반에는 이 구조가 중요하다.

예를 들어 고객 지원 답변을 바로 발송하는 대신 상담원에게 초안만 보여주면, 잘못된 답변이 나가도 막을 수 있고 어떤 부분이 자주 수정되는지도 알 수 있다. 이 수정 패턴은 나중에 프롬프트와 제품 개선의 재료가 된다.

처음부터 "사람 없이 전부 자동"을 목표로 잡으면, 대부분의 팀은 기대와 현실 사이의 간격에 부딪힌다. 좋은 제품은 종종 자동화가 아니라 사람의 일 속도를 올리는 설계에서 시작한다.

문제 선택을 위한 다섯 가지 질문

실무에서 빠르게 판단하고 싶다면 다음 다섯 가지 질문을 던져보면 좋다.

• 이 업무는 자주 반복되는가?

• 핵심 작업이 언어 이해, 요약, 재작성, 분류 중 하나에 가까운가?

• 80점 결과물만 나와도 사람이 시간을 아낄 수 있는가?

• 틀렸을 때 피해를 통제할 수 있는가?

• 결과를 측정하고 개선할 수 있는가?

다섯 개 중 네 개 이상에 "예"가 나오면 꽤 유망하다. 두세 개밖에 "예"가 안 나오면 신중해야 한다. 하나만 맞는다면 거의 데모용일 가능성이 높다.

이 질문이 좋은 이유는 기술보다 운영 현실을 보게 만들기 때문이다. 모델 성능이 아니라 제품 적합성을 먼저 보게 해준다.

좋은 문제와 나쁜 문제를 나란히 놓고 보면 더 분명해진다

아래 비교를 보면 감이 더 잡힌다.

표를 보면 보통 하나의 원칙으로 정리된다. LLM은 언어 작업의 조수로는 강하지만, 핵심 결정 로직의 판정기로는 약하다.

업무 전체를 맡기지 말고, 잘하는 조각만 맡겨라

문제를 잘 고르는 또 하나의 비결은 업무를 통째로 보지 않는 것이다. 많은 팀이 "고객 지원을 AI로 자동화하자"처럼 너무 큰 문장으로 시작한다. 그러면 곧 막막해진다. 고객 지원이라는 업무 안에는 질문 이해, 정책 조회, 답변 초안 작성, 위험 문장 검토, 발송 승인처럼 전혀 다른 성격의 단계가 섞여 있기 때문이다.

LLM은 이 전체를 한 번에 완벽히 처리하는 데는 약하지만, 일부 단계에서는 아주 유용하다. 예를 들어 문의 의도 분류와 답변 초안 작성은 맡기고, 환불 승인 여부는 기존 규칙 시스템이 처리하게 할 수 있다. 이렇게 나누면 위험은 줄고 가치 실현은 빨라진다.

실무에서는 이런 분해가 매우 중요하다. "업무 전체 자동화"를 목표로 삼기보다, 업무 흐름에서 언어 노동이 집중된 구간을 찾아내는 것이다. 바로 거기가 LLM이 들어갈 자리다.

돈 되는 문제는 보통 아주 현실적이다

LLM 제품을 떠올리면 사람들은 종종 거대한 만능 비서를 상상한다. 사용자의 모든 질문을 이해하고, 모든 문서를 읽고, 모든 업무를 대신 처리하는 슈퍼 에이전트 말이다. 듣기만 해도 멋지다. 하지만 실제로 돈이 되는 제품은 의외로 더 좁고 더 현실적이다.

예를 들어 다음과 같은 문제는 멋져 보이지 않아도 강하다.

• 상담원이 하루 300건의 문의 중 비슷한 답변을 반복해서 쓴다.

• 영업팀이 미팅 후 CRM 입력을 귀찮아해 기록 품질이 낮다.

• 운영팀이 긴 장애 보고서를 요약해 경영진에게 공유하느라 시간을 쓴다.

• 콘텐츠 팀이 같은 원문을 채널별 문체에 맞게 여러 번 다시 쓴다.

• 내부 직원이 사내 정책 문서를 찾지 못해 같은 질문을 반복한다.

이런 문제는 화려하지 않다. 하지만 자주 발생하고, 시간 비용이 명확하며, 개선 효과를 숫자로 확인하기 쉽다. 다시 말해 제품이 되기 좋은 문제다.

반대로 "뭐든지 물어보세요" 식의 범용 챗봇은 처음에는 그럴듯해도, 실제로는 기대 관리가 어렵고 품질 범위가 너무 넓어 금방 흔들린다. 넓게 시작하면 멋있어 보이고, 좁게 시작하면 돈이 된다. 초반에는 후자가 더 낫다.

사용자가 진짜로 사는 것은 AI가 아니라 결과다

이 문장은 꼭 기억할 가치가 있다. 사용자는 AI 자체를 사지 않는다. 더 빠른 업무 처리, 더 쉬운 작성, 더 적은 실수, 더 짧은 대기 시간, 더 나은 전환율 같은 결과를 산다.

그래서 문제를 고를 때도 "우리는 AI 기능을 넣을 수 있는가?"가 아니라 "사용자가 돈을 내거나 계속 쓰게 될 만큼 결과가 좋아지는가?"를 봐야 한다. 예를 들어 요약 기능이 멋져 보여도 사용자의 실제 행동을 바꾸지 못하면 가치가 약하다. 반면 답변 초안 기능이 상담 시간 30퍼센트를 줄여준다면, 그 기능은 아주 평범해 보여도 강력한 제품 가치를 만든다.

기술 팀이 특히 빠지기 쉬운 착각은 정확도가 높아지면 가치도 자동으로 높아진다고 믿는 것이다. 물론 품질은 중요하다. 하지만 제품에서는 품질만큼이나 빈도, 비용, 워크플로 적합성, 대체 가능성, 사용자 습관 변화가 중요하다. 아주 똑똑한 기능보다, 매일 쓰는 괜찮은 기능이 더 강하다.

시작은 작게, 검증은 빠르게 해야 한다

문제를 골랐다면 다음 단계는 거창한 플랫폼 구축이 아니라 작은 실험이다. 가장 작은 단위의 워크플로를 정하고, 그 안에서 사용자가 실제로 시간을 아끼는지, 품질을 받아들이는지, 반복 사용이 일어나는지 확인해야 한다.

예를 들어 "고객 지원 AI" 전체를 만드는 대신, 먼저 환불 문의 초안 작성 한 가지에만 붙여볼 수 있다. "문서 이해 플랫폼" 전체 대신, 긴 회의록에서 액션 아이템 추출 하나만 검증해볼 수도 있다. 이 방식이 좋은 이유는 명확하다. 문제-해결 적합성을 빨리 확인할 수 있고, 실패해도 비용이 적다.

LLM 프로젝트는 특히 범위를 넓히는 속도보다 문제 정의의 정확도가 더 중요하다. 처음부터 많은 기능을 붙이면 무엇이 효과를 냈는지, 무엇이 비용만 늘렸는지 알기 어렵다. 반대로 작은 문제를 날카롭게 잡으면 개선 루프가 빨라진다.

이 장에서 기억해야 할 판단 원칙

이제 내용을 한 줄씩 다시 접어보자.

LLM은 모든 문제를 해결하는 만능 열쇠가 아니다. 언어를 다루는 반복 업무, 초안 생성, 요약, 재작성, 분류, 입력 정리 같은 영역에서 특히 강하다. 반면 결정적 계산, 치명적 판단, 근거 없는 확정 답변, 저빈도 장식 기능에는 잘 맞지 않는다.

좋은 문제는 대개 자주 발생하고, 사람이 이미 시간을 많이 쓰고 있으며, 80점 결과물만으로도 가치가 있고, 사람 검토나 후속 제어가 가능하며, 품질을 측정할 수 있다. 나쁜 문제는 반대로 정확도 요구가 지나치게 높고, 실패 비용이 크며, 사용 빈도가 낮고, 진짜 문제는 다른 데 있는데 LLM으로 덮으려는 경우다.

무엇보다 중요한 것은 업무 전체가 아니라 업무 안의 적합한 조각을 찾는 일이다. LLM에게 전부를 맡기면 실망하기 쉽고, 잘하는 부분만 맡기면 놀랄 만큼 유용해진다.

마무리: 문제를 잘 고르면 모델은 그다음이다

LLM 시대에 자주 나오는 질문은 "어떤 모델이 제일 좋은가?"다. 하지만 제품을 만드는 사람에게 더 먼저 필요한 질문은 이것이다.

"어떤 문제를 풀 때 이 모델이 진짜 돈이 되는가?"

이 순서를 지켜야 한다. 문제를 잘 고르면 모델 선택은 최적화의 문제가 된다. 문제를 잘못 고르면 최고의 모델을 써도 비용만 비싸진다. 사용자는 감탄할지 몰라도 결제하지는 않는다.

결국 LLM 서비스의 성패는 모델의 지능보다 문제 선택의 정확도에서 갈리는 경우가 많다. 사용자가 반복해서 겪는 언어 노동을 찾아내고, 그중 80점 자동화만으로도 큰 이득이 나는 지점을 잡아내는 팀이 이긴다.

다음 장에서는 여기서 한 걸음 더 나아가, 기술보다 먼저 제품을 설계해야 하는 이유를 본격적으로 살펴보겠다. 어떤 모델을 쓸지보다 먼저, 어떤 사용자 흐름과 어떤 가치 제안을 만들지 정해야 하기 때문이다. LLM 서비스는 똑똑한 모델 위에서 시작하는 것이 아니라, 잘 고른 문제 위에서 시작한다.