1장. LLM 서비스는 기존 웹 서비스와 무엇이 다른가

웹 서비스 개발에 익숙한 사람이라면 처음 LLM을 붙일 때 이렇게 생각하기 쉽다. "API 하나 더 붙이면 되겠네." 실제로 시작은 그렇게 보인다. 회원가입 API가 있고, 결제 API가 있고, 문자 발송 API가 있듯이, 텍스트를 넣으면 답을 주는 LLM API도 그중 하나처럼 보인다.

하지만 막상 제품을 만들기 시작하면 분위기가 달라진다. 같은 요청인데 답이 조금씩 달라지고, 호출 한 번의 비용이 무시하기 어렵고, 응답 시간이 들쭉날쭉하며, 품질 문제는 버그처럼 딱 잘라 재현되지도 않는다. 사용자는 분명히 "이상하다"고 느끼는데, 개발자는 어디서부터 확인해야 할지 막막해진다.

이 장의 핵심은 단순하다. LLM은 기능처럼 붙일 수 있어도, 제품은 반드시 서비스처럼 운영해야 한다는 점이다. 이 관점을 초반에 잡아야 이후의 설계가 흔들리지 않는다. 프롬프트를 어떻게 짤지, 어떤 모델을 선택할지, 캐시를 넣을지, 품질을 어떻게 측정할지 모두 이 출발점에서 연결된다.

기존 웹 서비스의 상식이 잘 통하는 영역

기존 웹 서비스는 대체로 결정적이다. 같은 입력이 들어오면 같은 규칙에 따라 같은 결과가 나온다. 상품 가격 계산, 권한 체크, 주문 상태 변경, 정렬과 필터링, 쿠폰 적용 같은 로직이 여기에 해당한다. 물론 버그는 있을 수 있지만, 로직이 같다면 결과는 재현 가능하다.

이 특성은 서비스 운영을 훨씬 단순하게 만든다. 문제가 생기면 로그를 보고 같은 입력을 다시 넣어 재현하면 된다. 테스트 코드로 기대값을 박아둘 수도 있다. 성능도 비교적 예측 가능하다. 데이터베이스 조회가 몇 번 일어나는지, 외부 API가 몇 개 붙는지, 평균 응답 시간이 어느 정도인지 계산하기 쉽다.

많은 개발 문화와 운영 관행은 이런 세계를 전제로 발전해 왔다. "정확한 입력, 정확한 출력, 재현 가능한 오류"라는 상식이다.

LLM 서비스는 이 상식이 완전히 무너지지는 않지만, 중요한 부분에서 계속 빗나간다. 그리고 바로 그 틈에서 제품 설계와 운영 난도가 높아진다.

LLM 서비스는 왜 다르게 느껴지는가

LLM은 입력을 받아 다음에 올 가능성이 높은 내용을 생성하는 시스템이다. 쉽게 말해, 계산기라기보다 매우 능숙한 작문가에 가깝다. 질문을 해석하고 문맥을 이어 받아 그럴듯한 답을 만들어 낸다. 그래서 결과가 유용할 수는 있지만, 언제나 고정적이지는 않다.

이 차이는 사소해 보이지만 서비스 차원에서는 매우 크다. 일반 웹 서비스가 "규칙을 실행하는 기계"에 가깝다면, LLM 서비스는 "확률적으로 좋은 결과를 뽑아내는 시스템"에 가깝다. 즉, 정답을 저장해 두고 꺼내는 것이 아니라, 매 요청마다 새로운 결과를 생성한다.

여기서부터 네 가지 차이가 본격적으로 드러난다. 출력은 확률적이고, 비용은 호출량과 토큰 사용량에 민감하며, 지연 시간은 길고 불안정하며, 품질 관리는 정답 여부만으로 끝나지 않는다.

첫 번째 차이: 출력이 확률적이다

기존 웹 서비스에서는 "같은 입력이면 같은 출력"이 기본이다. 반면 LLM은 같은 의미의 질문을 조금 다르게 말해도 답이 달라질 수 있고, 심지어 완전히 같은 입력을 넣어도 표현, 길이, 세부 내용이 바뀔 수 있다. 모델 설정과 프롬프트, 대화 이력, 시스템 지시문, 샘플링 설정 같은 요소가 모두 결과에 영향을 준다.

이 확률성은 장점이기도 하다. 창의적인 초안 작성, 문장 재작성, 다양한 후보 생성에는 오히려 이런 성질이 필요하다. 똑같은 홍보 문구만 반복해서 내놓는 모델은 실무에서 금방 쓸모가 떨어진다.

하지만 서비스 운영 관점에서는 골칫거리가 된다. 예를 들어 고객 문의 답변 도우미를 만든다고 해보자. 어떤 날은 아주 친절하고 정확한 답을 내놓다가, 어떤 날은 불필요하게 장황해질 수 있다. 어떤 질문에는 잘 답하면서도, 표현이 조금만 바뀌면 엉뚱한 설명을 길게 늘어놓을 수도 있다.

이때 중요한 사실은, 이것이 단순한 버그가 아니라는 점이다. 코드가 틀린 것이 아니라 시스템의 본성이 그런 것이다. 그래서 LLM 기능을 설계할 때는 "정확히 하나의 정답"을 기대하기보다, 허용 가능한 출력의 범위를 설계해야 한다.

예를 들어 다음과 같은 질문이 필요해진다.

• 이 기능은 매번 같은 답이 나와야 하는가?

• 답이 조금 달라도 괜찮은가?

• 틀려도 치명적이지 않은가, 아니면 반드시 맞아야 하는가?

• 자유 서술이 필요한가, 아니면 선택지 중 하나만 고르게 해야 하는가?

이 질문에 답하지 않은 채 LLM을 붙이면, 제품은 처음부터 흔들린다. 생성형 기능이 어울리는 문제와, 규칙 기반 로직으로 남겨야 하는 문제를 구분하지 못하기 때문이다.

확률적 출력은 설계 문제로 이어진다

확률적 출력의 세계에서는 프론트엔드와 백엔드의 역할도 달라진다. 기존 서비스라면 서버가 결과를 계산해 내려주고 클라이언트가 보여주면 끝이다. 하지만 LLM 서비스에서는 "결과를 그대로 보여줘도 되는가"가 별도 문제로 생긴다.

예를 들어 분류 기능을 만든다면, 모델이 자유롭게 문장을 생성하도록 두기보다 미리 정한 카테고리만 반환하게 만드는 편이 낫다. 요약 기능이라면 길이 제한, 금지 표현, 필수 포함 항목을 두는 것이 좋다. 초안 작성 기능이라면 바로 발송하지 않고 사람이 검토하는 흐름을 넣을 수 있다.

즉, LLM을 잘 쓰는 서비스는 모델에게 일을 전부 맡기지 않는다. 모델이 잘하는 부분만 맡기고, 나머지는 제품 구조로 제어한다. 이 장의 표현으로 바꾸면, 확률적 모델 위에 결정적인 서비스 껍질을 씌우는 것이 핵심이다.

두 번째 차이: 비용 구조가 완전히 다르다

기존 웹 서비스의 비용은 보통 인프라 중심으로 관리한다. 서버 몇 대, 데이터베이스 크기, 캐시 사용량, 네트워크 비용, 저장 공간 같은 요소를 보고 대략적인 비용 구조를 이해할 수 있다. 요청이 늘면 비용이 늘어나지만, 그 증가 방식은 비교적 익숙하다.

LLM 서비스는 여기에 새로운 축이 추가된다. 바로 생성 비용이다. 사용자가 요청할 때마다 모델이 실제로 추론을 수행하고, 그에 따라 비용이 발생한다. 그것도 요청 수만이 아니라 입력 길이와 출력 길이에 따라서도 비용이 달라진다.

같은 "질문 답변" 기능이라도 상황은 제각각이다. 짧은 문의 한 줄에 답하는 기능과, 긴 계약서를 읽고 요약하는 기능은 호출 한 번의 원가가 다르다. 문서 몇 개를 붙이고, 대화 이력을 길게 싣고, 응답을 장문으로 받기 시작하면 비용은 생각보다 빠르게 올라간다.

여기서 초보 팀이 자주 빠지는 함정이 있다. 데모 단계에서는 사용량이 적어서 괜찮아 보이는데, 실제 사용자 트래픽이 붙는 순간 원가가 갑자기 눈에 띄기 시작하는 것이다. 특히 무료 플랜이나 체험판 위주로 유입을 받아 놓고, 모든 요청에 고성능 모델을 장문 응답으로 물리면 제품이 인기를 얻을수록 손해가 커지는 기묘한 상황이 벌어진다.

LLM 서비스에서는 기능을 추가하는 것이 곧 원가 구조를 바꾸는 일일 때가 많다. 그래서 제품 기획 단계부터 이런 질문이 필요하다.

• 이 기능의 요청 1건당 평균 원가는 얼마인가?

• 긴 입력과 긴 출력이 꼭 필요한가?

• 모든 사용자에게 같은 모델을 써야 하는가?

• 실패하거나 재시도하는 요청까지 포함하면 비용은 얼마나 되는가?

• 유료화하지 않아도 유지 가능한가?

즉, LLM 기능은 단순한 UX 요소가 아니라 손익 구조에 직접 연결되는 기능이다. 버튼 하나를 추가하는 일이 아니라, 작은 비용 엔진을 제품 안에 심는 일에 가깝다.

비용은 기술보다 제품 전략과 더 가깝다

흥미로운 점은 비용 문제가 단순히 엔지니어링 문제로 끝나지 않는다는 것이다. 예를 들어 사용자가 "조금 더 자세히 설명해줘"를 여러 번 누를 수 있게 하면 만족도는 올라갈 수 있다. 하지만 그만큼 출력 토큰이 늘고, 대화 이력도 쌓여 다음 호출 비용이 커진다. 반대로 응답을 짧게 자르면 원가는 줄지만 만족도가 떨어질 수 있다.

결국 비용은 모델 선택만의 문제가 아니라 사용자 경험 전체의 문제다. 무료 사용량 제한, 응답 길이 정책, 문서 첨부 개수, 고급 기능의 유료화, 배치 처리 여부, 캐시 전략까지 모두 비용과 연결된다.

기존 웹 서비스에서 "사용자에게 더 좋은 경험을 주자"가 거의 항상 옳은 방향이었다면, LLM 서비스에서는 "좋은 경험을 어떤 원가로 제공할 것인가"까지 함께 물어야 한다. 서비스 운영의 언어가 훨씬 더 직접적으로 비즈니스와 맞닿는다.

세 번째 차이: 지연 시간이 길고 흔들린다

웹 서비스에서 속도는 늘 중요했지만, LLM 서비스에서는 훨씬 더 민감하다. 일반적인 API는 데이터 조회나 저장처럼 비교적 짧고 예측 가능한 작업을 수행한다. 반면 LLM은 입력을 읽고, 추론하고, 문장을 생성하는 시간이 필요하다. 답이 길수록 더 오래 걸리기도 한다.

사용자 입장에서 이 차이는 즉시 체감된다. 버튼을 눌렀는데 100밀리초 안에 화면이 바뀌는 경험과, 5초 동안 기다리며 "생각 중…" 표시를 보는 경험은 완전히 다르다. 심지어 같은 기능이라도 어떤 요청은 빠르고 어떤 요청은 느릴 수 있다. 문서 길이, 컨텍스트 길이, 모델 종류, 서버 상태, 스트리밍 여부 등 많은 요소가 지연 시간에 영향을 준다.

그래서 LLM 서비스는 단지 "빠른 서버"만으로 해결되지 않는다. 제품 레벨에서 지연 시간을 다루는 방법이 필요하다. 예를 들어 사용자는 완성된 답변이 아니라도, 답이 생성되고 있다는 신호를 원한다. 스트리밍으로 문장이 조금씩 보이면 기다림이 덜 답답해진다. 오래 걸리는 작업은 즉시 응답 대신 비동기 작업으로 넘겨야 할 수도 있다. 문서 분석처럼 시간이 걸리는 기능은 업로드 직후 결과를 주기보다 "처리 중" 상태를 보여주는 편이 낫다.

즉, LLM의 지연 시간 문제는 백엔드 성능 튜닝만으로 풀리지 않는다. 사용자 경험 설계, 작업 구조 분리, 큐 시스템, 상태 표시 방식까지 함께 설계해야 한다.

느린 것은 죄가 아니라, 설명 없는 느림이 문제다

사용자는 의외로 몇 초 기다리는 것 자체를 무조건 싫어하지는 않는다. 다만 왜 기다리는지 모르고, 언제 끝날지 모르고, 기다린 끝에 별 가치 없는 결과를 받는 상황을 싫어한다.

이 점은 LLM 서비스에서 특히 중요하다. 사람이 "생각해서 답하는" 느낌을 주는 인터페이스는 어느 정도의 지연을 받아들이게 만든다. 하지만 같은 시간을 기다려도 결과가 믿을 만하지 않으면 인내심은 급격히 줄어든다.

따라서 속도는 절대적인 숫자만의 문제가 아니다. 사용자가 체감하는 속도와 납득 가능한 흐름을 만드는 문제다. 빠른 모델을 쓰는 것 못지않게, 중간 상태를 보여주고, 예상 소요 시간을 설계하고, 짧은 답을 먼저 주고 자세한 답은 나중에 확장하게 만드는 전략이 중요해진다.

네 번째 차이: 품질 관리는 테스트만으로 끝나지 않는다

기존 웹 서비스에서는 품질 관리의 중심이 정확성 검증에 있다. 로그인 로직이 맞는지, 결제가 정상 동작하는지, 할인 규칙이 의도대로 적용되는지 테스트하고 배포한다. 실패하면 재현해서 고친다.

LLM 서비스에서는 이 방식이 필요하지만 충분하지 않다. 왜냐하면 결과 품질이 단순한 정오 문제를 넘어가기 때문이다. 같은 답변이라도 더 명확할 수도 있고, 더 친절할 수도 있고, 더 위험할 수도 있다. 맞는 말처럼 보여도 중요한 정보를 빠뜨릴 수 있고, 문맥상 부적절할 수도 있다.

예를 들어 회의록 요약 기능을 만든다고 하자. 품질이 좋다는 것은 단순히 문법이 맞는다는 뜻이 아니다. 핵심 결정 사항이 빠지지 않았는지, 액션 아이템이 제대로 살아 있는지, 화자의 의도가 왜곡되지 않았는지, 너무 장황하지 않은지, 민감한 내용이 과하게 노출되지 않았는지까지 봐야 한다.

즉, LLM 품질은 보통 다음 층위가 겹쳐 있다.

• 사실성: 없는 내용을 지어내지 않는가

• 관련성: 사용자의 질문에 정말 답하고 있는가

• 형식 적합성: 원하는 길이와 형식을 지키는가

• 안전성: 위험하거나 부적절한 내용을 내놓지 않는가

• 일관성: 비슷한 요청에 품질 편차가 너무 크지 않은가

이 문제는 단위 테스트 몇 개로 끝나지 않는다. 샘플 데이터셋, 사람 평가, 자동 평가, 운영 로그 분석이 함께 필요하다. LLM 서비스 운영에서 "품질"은 배포 전 확인 항목이 아니라 배포 후 계속 관리해야 하는 운영 지표다.

LLM 서비스에서 버그와 품질 저하는 다르다

여기서 중요한 구분이 하나 있다. 기존 웹 서비스에서는 오류가 나면 대개 버그다. 그런데 LLM 서비스에서는 사용자가 불만을 느껴도, 코드상 오류는 없을 수 있다. 모델이 애매하게 답했고, 프롬프트가 충분히 제약하지 못했고, UI가 기대치를 잘못 심어줬을 수 있다.

예를 들어 사용자가 "이 문서를 간단히 요약해줘"라고 했는데 결과가 너무 길었다면, 서버 장애는 아니다. 하지만 사용자 입장에서는 기능이 기대를 어긴 것이다. 또 고객지원 답변 생성기가 지나치게 단정적인 어투로 틀린 정보를 말했을 때도 HTTP 200은 잘 떨어졌을 수 있다. 시스템은 성공했고, 제품은 실패한 셈이다.

이런 상황이 반복되면 팀은 깨닫게 된다. LLM 서비스에서 성공률은 단지 API 에러율로 측정할 수 없다는 사실을 말이다. 응답이 돌아왔는지보다, 쓸 만한 응답이 돌아왔는지가 더 중요하다.

그래서 LLM 서비스 운영 지표는 보통 더 복합적이다. 성공 응답률, 첫 토큰까지 걸린 시간, 전체 응답 시간, 사용자 재시도율, 복사 버튼 클릭률, 수정 후 사용률, 사람 검토 반려율 같은 지표가 함께 의미를 가진다. 즉, 시스템 모니터링과 제품 분석이 강하게 결합된다.

기능 중심 사고에서 서비스 중심 사고로

이제 핵심 문장을 다시 보자. LLM은 API 한 번 붙이는 기능이 아니라 운영해야 하는 서비스다. 이 말은 단순한 태도론이 아니다. 실제 설계 원칙을 바꾼다.

기능 중심 사고에서는 보통 이렇게 접근한다. "텍스트를 넣고 답을 받는다. UI에 보여준다. 끝." 데모는 빨리 나온다. 발표도 그럴듯하다. 하지만 운영이 시작되면 문제가 몰려온다. 응답 편차, 예기치 않은 비용, 느린 속도, 품질 불만, 안전성 이슈가 한꺼번에 터진다.

반대로 서비스 중심 사고에서는 처음부터 다르게 묻는다. "이 기능은 어떤 입력을 받는가? 출력의 허용 범위는 무엇인가? 실패하면 어떻게 처리할 것인가? 너무 비싸지 않은가? 기다릴 만한 가치가 있는가? 품질은 어떻게 관찰하고 개선할 것인가?"

이 차이는 생각보다 크다. 전자는 LLM을 마법 상자로 보고, 후자는 LLM을 불완전하지만 유용한 부품으로 본다. 전자는 데모에 강하고 운영에 약하다. 후자는 시작은 조금 느려 보여도 실제 서비스로 살아남는다.

LLM 서비스는 제품, 백엔드, 운영이 한 몸처럼 움직여야 한다

기존 웹 서비스에서도 협업은 중요하지만, 역할 분리가 비교적 선명한 편이다. 제품이 요구사항을 정하면 개발이 구현하고 QA가 검증하는 흐름이 잘 작동한다.

LLM 서비스에서는 이 경계가 더 자주 겹친다. 프롬프트 하나를 바꾸는 일이 곧 사용자 경험을 바꾸고, 비용을 바꾸고, 실패 패턴을 바꾼다. 모델을 교체하는 일은 단지 백엔드 변경이 아니라 품질 기준 전체를 흔들 수 있다. 입력 폼에서 사용자의 질문 방식을 유도하는 문구 하나도 응답 품질에 영향을 준다.

그래서 LLM 서비스를 잘 만드는 팀은 제품, 디자인, 백엔드, 데이터, 운영이 따로 노는 대신 하나의 루프를 만든다. 사용자가 어디서 막히는지 보고, 프롬프트를 조정하고, 출력 형식을 바꾸고, 필요하면 모델을 교체하고, UI에서 기대치를 다시 설계한다. 즉, 모델 품질을 모델만의 문제로 보지 않는다.

예시로 보는 차이: FAQ 챗봇과 LLM 고객지원 도우미

겉보기에는 둘 다 "질문에 답하는 기능"이다. 하지만 실제로는 전혀 다른 성격을 가진다.

기존 FAQ 챗봇은 준비된 질문-답변 목록에서 가장 가까운 항목을 찾아 보여주면 된다. 답변 범위가 정해져 있고, 잘못 답하면 어떤 규칙이 틀렸는지 추적하기 쉽다. 속도도 빠르고 비용도 비교적 안정적이다.

반면 LLM 고객지원 도우미는 질문을 해석하고, 필요한 문맥을 끌어오고, 자연스러운 문장으로 재구성하고, 때로는 불완전한 정보 속에서 가장 적절한 안내를 만들어야 한다. 표현은 유연하지만, 그만큼 잘못 답할 위험도 있다. 답변이 길어질 수 있고, 문맥이 많이 붙으면 비용도 증가한다. 또 민감한 정책이나 환불 규정처럼 틀리면 안 되는 내용이 섞이면 검증 구조가 필요해진다.

같은 "답변 기능"처럼 보여도, 하나는 검색된 정보를 보여주는 도구에 가깝고 다른 하나는 생성형 서비스에 가깝다. 둘을 같은 방식으로 설계하면 대부분 실패한다.

그래서 첫 장에서 무엇을 기억해야 할까

이 책은 이후에 프롬프트, 구조화 출력, 멀티 벤더, RAG, 세션 관리, 비용 최적화, 테스트, 보안, 운영 개선까지 차례로 다룰 것이다. 하지만 그 모든 내용은 하나의 전제를 공유한다. LLM은 결과를 잘 뽑는 모델 이전에, 흔들리는 특성을 가진 운영 대상이라는 점이다.

이 전제를 받아들이면 다음과 같은 태도가 자연스러워진다.

• 모델에게 모든 책임을 넘기지 않는다.

• 출력은 제약하고 검증하며 후처리한다.

• 비용은 기능 설계 단계에서부터 계산한다.

• 지연 시간은 UX와 아키텍처로 함께 해결한다.

• 품질은 배포 후에도 계속 측정하고 개선한다.

반대로 이 전제를 놓치면 팀은 계속 같은 착각을 반복하게 된다. "프롬프트만 조금 더 고치면 되겠지", "더 좋은 모델로 바꾸면 해결되겠지", "데모에서는 잘 됐는데 왜 운영에서 문제지?" 같은 말이 나온다. 물론 프롬프트도 중요하고 모델도 중요하다. 하지만 그것만으로는 서비스가 되지 않는다.

마무리: LLM은 똑똑한 API가 아니라 불완전한 동료다

LLM을 가장 현실적으로 이해하는 비유는 이것이다. LLM은 완벽한 계산기가 아니라, 매우 빠르고 꽤 유능하지만 가끔 과장하고 가끔 엉뚱한 말을 하는 동료와 비슷하다. 잘 시키면 큰 도움이 되지만, 시킨 일을 그대로 믿고 바로 고객 앞에 내보내면 사고가 날 수도 있다.

그래서 필요한 것은 맹신도 불신도 아니다. 역할을 나누고, 기대치를 조정하고, 검토와 보호장치를 넣고, 비용과 시간을 관리하는 서비스 설계다. 그 설계가 있을 때 LLM은 데모용 장난감이 아니라 실제 가치를 만드는 제품의 일부가 된다.

이 책의 나머지 장들은 바로 그 설계를 하나씩 쌓아 올리는 과정이다. 먼저 문제를 고르고, 모델보다 제품을 먼저 설계하고, 공통 API 구조를 이해하고, 출력과 품질을 통제하고, 운영 가능한 아키텍처로 확장해 갈 것이다. 출발점은 분명하다. 우리가 만드는 것은 LLM 기능이 아니라 LLM 서비스다.