3장. 모델보다 먼저 제품을 설계하라

2장에서 우리는 어떤 문제가 LLM에 맞는지 살펴봤다. 이제 많은 팀이 바로 다음 질문으로 뛰어간다. "그래서 OpenAI를 쓸까, Claude를 쓸까, Gemini를 쓸까?" "제일 좋은 모델은 뭐지?" "파라미터가 큰 모델이 더 낫겠지?"

이 질문이 아주 틀린 것은 아니다. 하지만 순서가 자주 틀린다.

LLM 서비스에서 초반 실패의 상당수는 모델이 나빠서가 아니라, 무엇을 좋은 결과라고 볼지 제품 차원에서 정하지 않은 채 시작했기 때문에 생긴다. 사용자가 어느 순간에 이 기능을 쓰는지, 한 번의 응답이 어떤 일을 끝내줘야 하는지, 틀렸을 때 어디까지 허용되는지, 사람이 개입해야 하는지, 응답이 몇 초를 넘으면 이탈하는지 같은 핵심이 비어 있는데 모델부터 고르면, 팀은 금방 "생각보다 별론데?"라는 벽에 부딪힌다.

쉽게 말해 모델은 엔진이고, 제품은 차다. 엔진이 좋아도 운전대가 없고 브레이크가 없고 목적지가 없으면 멋진 차가 되지 않는다. LLM도 마찬가지다. 똑똑한 모델 하나로 서비스가 완성되지는 않는다. 먼저 필요한 것은 어떤 사용자 경험을 만들 것인가에 대한 설계다.

왜 팀은 자꾸 모델부터 고를까

이유는 간단하다. 모델은 비교하기 쉬워 보이기 때문이다. 벤치마크 점수도 있고, 가격표도 있고, 데모를 돌리면 금방 "오, 얘가 더 잘하는데?"라는 느낌도 난다. 반면 제품 설계는 더 모호하다. 사용자의 맥락을 이해해야 하고, 실패를 가정해야 하고, 운영까지 내다봐야 한다. 머리가 더 아프다.

그래서 많은 팀이 이렇게 출발한다. 가장 좋아 보이는 모델을 하나 고르고, 프롬프트를 몇 줄 써서, 채팅창이나 입력창에 붙인다. 처음에는 꽤 그럴듯하다. 질문 몇 개는 잘 답하고, 회의에서 박수도 받는다. 그런데 실제 사용자가 들어오면 상황이 달라진다.

어떤 사용자는 너무 긴 질문을 넣고, 어떤 사용자는 필요한 정보 없이 답만 요구한다. 어떤 요청은 2초 만에 끝나는데 어떤 요청은 15초가 걸린다. 어떤 답변은 훌륭한데 어떤 답변은 이상하게 장황하다. 틀린 답을 해도 시스템은 HTTP 200을 반환한다. 사용자는 "답은 왔는데 도움이 안 됐어요"라고 말한다.

이때 문제를 모델 탓으로만 돌리기 쉽다. 물론 모델 차이는 있다. 하지만 더 자주 근본 원인은 이쪽이다.

• 사용자가 언제 이 기능을 써야 하는지 불명확하다.

• 한 번의 응답이 끝내야 할 일이 지나치게 크다.

• 실패했을 때 다음 행동이 설계되어 있지 않다.

• 품질 기준이 없어 팀마다 "좋다"의 정의가 다르다.

• 속도, 비용, 안전성 조건이 처음부터 정리되지 않았다.

즉, 모델이 아니라 제품 설계가 먼저 흔들린 것이다.

모델보다 먼저 정해야 하는 첫 질문

LLM 기능을 붙이기 전에 가장 먼저 물어야 하는 질문은 "어떤 모델을 쓸까?"가 아니다. 이 질문이다.

사용자는 어떤 순간에 이 기능을 열고, 무엇을 끝내고 싶어 하는가?

이 질문이 중요한 이유는 LLM 서비스가 늘 "답변 생성"으로 끝나지 않기 때문이다. 사용자는 답을 읽으려고 제품을 쓰는 것이 아니라, 어떤 일을 끝내려고 제품을 쓴다. 문의를 처리하려고, 문서를 빨리 이해하려고, 초안을 만들려고, 분류 시간을 줄이려고, 다음 행동을 정하려고 제품을 연다.

그래서 제품 설계는 응답 문장 자체보다 사용자 작업의 흐름을 먼저 봐야 한다. 응답이 아무리 똑똑해도 그 다음 행동이 막혀 있으면 좋은 제품이 아니다. 반대로 응답이 완벽하지 않아도 다음 행동으로 자연스럽게 이어지면 충분히 유용한 제품이 된다.

예를 들어 "고객 문의 답변 생성기"를 만든다고 해보자. 이 기능의 목표가 단순히 답변 문장을 만드는 것인지, 아니면 상담원이 더 빨리 정확한 답변을 보내게 하는 것인지에 따라 설계가 완전히 달라진다. 전자라면 채팅창만 있어도 된다. 하지만 후자라면 정책 근거 표시, 수정 가능한 초안, 금지 표현 점검, 발송 전 검토 흐름이 필요해진다. 그리고 대부분 실무에서 중요한 것은 전자가 아니라 후자다.

제품 설계는 한 번의 멋진 답변이 아니라 한 개의 작업 흐름을 설계하는 일이다

초보 팀은 종종 LLM 기능을 "질문하면 답하는 화면"으로 상상한다. 하지만 서비스는 질문과 답변의 교환으로만 이루어지지 않는다. 그 앞에는 맥락이 있고, 그 뒤에는 행동이 있다.

좋은 제품 설계는 보통 다음 흐름을 본다.

• 사용자는 어떤 상황에서 이 기능을 호출하는가

• 호출 전에 어떤 정보가 이미 있는가

• 시스템은 어떤 입력을 더 받아야 하는가

• 응답은 어떤 형태여야 바로 쓸 수 있는가

• 응답이 부족하거나 위험할 때는 무엇을 해야 하는가

• 사용자는 결과를 보고 어떤 다음 행동을 하는가

이 흐름이 정리되지 않으면 팀은 자꾸 프롬프트만 만지게 된다. 하지만 프롬프트는 제품 설계의 일부일 뿐이다. 사용자 입력을 더 구조화해야 할 수도 있고, 출력 형식을 자유 문장 대신 체크리스트로 바꿔야 할 수도 있고, 답을 바로 보여주지 말고 사람 승인 단계를 넣어야 할 수도 있다. 이건 모델의 지능 문제가 아니라 제품 구조의 문제다.

사용자 흐름부터 설계하라

LLM 서비스에서 사용자 흐름은 특히 중요하다. 같은 모델을 써도 흐름 설계에 따라 체감 품질이 크게 달라지기 때문이다.

예를 들어 문서 요약 기능을 생각해보자. 사용자가 긴 문서를 업로드하고 "요약" 버튼을 눌렀는데, 몇 초 뒤 긴 문단 하나가 툭 나오면 기술적으로는 동작한 것이다. 하지만 사용자 입장에서는 아직 일이 덜 끝났다. 핵심 결정 사항이 무엇인지, 액션 아이템이 무엇인지, 위험 요소가 무엇인지, 원문에서 어디를 근거로 삼았는지 다시 읽어야 한다.

반대로 같은 요약이라도 이렇게 설계할 수 있다. 먼저 한 줄 요약을 보여주고, 그 아래에 핵심 포인트 세 개, 결정 사항, 할 일, 주의할 점을 나눠서 보여준다. 필요하면 원문 근거 위치도 함께 보여준다. 그러면 사용자는 "좋은 요약이냐"를 따지기 전에 이미 일을 더 빨리 끝낼 수 있다.

즉, 사용자 흐름을 설계한다는 것은 LLM이 생성한 문장을 보기 좋게 꾸민다는 뜻이 아니다. 사용자가 덜 생각하고 더 빨리 다음 행동을 하게 만드는 구조를 만드는 것이다.

입력 설계가 곧 품질 설계다

많은 사람이 출력 품질에만 집중하지만, 실제로는 입력 단계에서 결과의 절반이 결정된다. 사용자는 늘 좋은 입력을 주지 않는다. 급하게 쓰고, 중간 정보를 빼먹고, 감정과 요구사항을 한 문장에 섞고, 파일 이름만 올려놓고 "요약해줘"라고 할 수도 있다.

그래서 LLM 서비스에서는 입력창 하나만 던져놓고 사용자에게 맡기는 방식이 생각보다 약하다. 제품 설계가 입력을 도와줘야 한다.

예를 들면 이런 방식이 있다.

• 자유 입력 아래에 좋은 예시를 보여준다.

• 길이, 목적, 톤처럼 중요한 옵션을 미리 선택하게 한다.

• 문서 종류를 먼저 고르게 해 맥락을 좁힌다.

• 필요한 정보가 비어 있으면 추가 질문을 한다.

• 내부 데이터가 필요하면 사용자가 직접 붙이지 않아도 시스템이 먼저 불러온다.

이런 장치는 겉보기에는 사소하다. 하지만 실제 서비스에서는 프롬프트 한 줄보다 더 큰 차이를 만들기도 한다. 이유는 단순하다. 모델이 더 똑똑해지기 전에, 입력 자체가 덜 흔들리기 때문이다.

출력 형식을 먼저 정하라

많은 팀이 처음에는 자유로운 문장 생성을 선호한다. 사람처럼 말하는 결과가 가장 인상적이기 때문이다. 하지만 운영으로 가면 오히려 너무 자유로운 출력이 문제를 만든다. 길이가 들쭉날쭉하고, 빠져도 안 되는 항목이 빠지고, 후속 시스템과 연결하기 어려워진다.

그래서 제품 설계 단계에서 먼저 정해야 한다. 이 기능의 결과는 정말 자유 문장이어야 하는가? 아니면 정해진 구조가 더 나은가?

예를 들어 다음 상황을 비교해보자.

상담원 보조 도구에서 필요한 것은 "그럴듯한 답변"이 아니라, 문의 유형, 추천 답변 초안, 정책 근거, 주의 문구일 수 있다. 회의록 요약에서 필요한 것은 "예쁜 한 문단"이 아니라, 결정 사항, 액션 아이템, 담당자, 일정일 수 있다. 상품 리뷰 분석에서는 "리뷰에 대한 감상문"이 아니라, 감성, 핵심 불만, 언급 빈도 높은 키워드일 수 있다.

이처럼 출력 형식을 먼저 정하면 많은 것이 쉬워진다. 품질 평가도 쉬워지고, UI 설계도 쉬워지고, 후처리도 쉬워지고, 사람 검토도 쉬워진다. 모델은 그 형식 안에서 일하도록 도와주는 존재가 된다.

실패 경험을 먼저 설계하라

LLM 서비스에서 정말 중요한 차이는 여기서 드러난다. 기존 웹 서비스에서는 성공 흐름만 잘 만들어도 어느 정도 굴러간다. 하지만 LLM 서비스는 실패가 더 자주, 더 애매한 형태로 나타난다. 답이 아예 안 오는 실패보다, 답은 왔지만 쓰기 곤란한 실패가 훨씬 많다.

그래서 제품 설계에서 반드시 먼저 다뤄야 하는 것이 실패 경험이다. 사용자가 기대한 결과를 얻지 못했을 때 무엇이 일어나는가를 미리 정해야 한다.

실패는 여러 형태를 가진다.

• 답이 느리다.

• 답이 너무 길거나 너무 짧다.

• 핵심이 빠졌다.

• 틀린 내용을 단정적으로 말한다.

• 형식을 지키지 않는다.

• 민감하거나 위험한 내용을 섞는다.

• 확신할 수 없는 상황인데도 그럴듯하게 말한다.

이런 실패가 생겼을 때 제품이 할 수 있는 대응도 설계해야 한다.

예를 들어 확신이 낮으면 "답을 지어내는" 대신 추가 정보를 요청하게 만들 수 있다. 근거가 필요한 기능이라면 답변과 함께 출처나 원문 위치를 보여줄 수 있다. 위험도가 높은 업무라면 자동 발송 대신 검토 대기 상태로 보내야 한다. 시간이 오래 걸리면 즉시성 있는 짧은 결과를 먼저 주고, 자세한 분석은 나중에 보여줄 수 있다.

좋은 LLM 제품은 실패를 숨기지 않는다. 실패가 생겨도 사용자가 길을 잃지 않게 한다. 이것이 중요하다. 실패를 0으로 만드는 것은 어렵지만, 실패했을 때의 경험을 덜 나쁘게 만드는 것은 설계로 가능하다.

"모르겠습니다"를 허용하는 제품이 강하다

초기 제품에서 자주 놓치는 부분이 있다. 바로 모델에게 모든 상황에서 답하게 만들려는 욕심이다. 하지만 현실의 좋은 서비스는 모든 질문에 답하는 서비스가 아니라, 답할 수 있을 때 잘 답하고, 답할 수 없을 때도 안전하게 행동하는 서비스다.

예를 들어 내부 정책 도우미가 최신 근거를 찾지 못했다면, 그럴듯한 추정 답을 길게 쓰는 것보다 "현재 확인 가능한 근거가 부족합니다. 관련 문서를 다시 선택하거나 담당 부서에 확인하세요."라고 말하는 편이 훨씬 낫다. 사용자 입장에서는 조금 덜 화려해 보여도, 훨씬 신뢰할 수 있다.

이 원칙은 특히 운영 단계에서 강력하다. 서비스가 모든 요청에 어설프게 대답할수록 신뢰는 빠르게 무너진다. 반대로 제한을 분명히 드러내면 사용자는 어느 범위에서 믿고 써야 하는지 학습한다.

검증 기준이 없으면 팀은 끝없이 싸운다

LLM 서비스 프로젝트가 이상하게 지치는 이유 중 하나는, "좋아졌다"의 정의가 흐리기 때문이다. PM은 더 자연스러운 답변을 원하고, 개발자는 더 짧은 응답 시간을 원하고, 운영팀은 더 적은 오답을 원하고, 경영진은 더 낮은 비용을 원한다. 다 맞는 말이다. 문제는 우선순위가 없다는 것이다.

그래서 제품 설계 단계에서 검증 기준을 먼저 정해야 한다. 최소한 다음 네 가지 축은 분리해서 봐야 한다.

• 사용자가 실제로 과업을 더 빨리 끝내는가

• 응답 품질이 허용 범위 안에 드는가

• 속도와 비용이 서비스 운영 가능한 수준인가

• 실패가 생겨도 위험이 통제되는가

예를 들어 회의록 요약 기능이라면 "좋은 답변처럼 보인다"가 아니라 이런 기준이 필요하다. 핵심 결정 사항 누락률은 어느 정도까지 허용되는가? 액션 아이템 추출의 정확도는 어느 수준이면 실무에 쓸 만한가? 평균 응답 시간은 몇 초 이하여야 하는가? 사용자가 요약 결과를 복사하거나 후속 작업으로 이어가는 비율은 얼마나 되는가?

이 기준이 있어야 팀이 움직인다. 그래야 모델 변경도 평가할 수 있고, 프롬프트 수정도 비교할 수 있고, 기능 출시 여부도 판단할 수 있다.

품질은 문장 미감이 아니라 과업 성공률로 보라

LLM 데모를 보면 자꾸 문장 자체에 마음을 빼앗긴다. 말투가 자연스러운지, 문장이 부드러운지, 설명이 똑똑해 보이는지가 눈에 잘 띄기 때문이다. 하지만 실무 서비스에서는 그보다 더 중요한 질문이 있다.

그래서 사용자의 일이 끝났는가?

예를 들어 고객 응답 초안 기능에서 정말 중요한 것은 문장이 시적이냐가 아니다. 상담원이 더 적은 수정으로 더 빨리 보낼 수 있는가가 중요하다. 분류 기능에서는 설명이 아름다운가보다 올바른 큐로 잘 보내지는가가 중요하다. 문서 요약 기능에서는 문장이 매끄러운가보다 놓치면 안 되는 항목이 살아 있는가가 중요하다.

이 관점을 잡아야 검증 기준도 현실적으로 세울 수 있다. "사용자가 편집 후 그대로 채택한 비율", "사람 검토에서 반려된 비율", "후속 문의 감소율", "작업 완료 시간 단축" 같은 지표가 중요한 이유가 여기에 있다. 좋은 제품은 보기 좋은 답변보다 일을 줄여주는 답변을 만든다.

운영 조건을 제품 설계의 일부로 넣어라

많은 팀이 운영 조건을 나중 문제로 미룬다. 일단 기능이 되게 만들고, 그다음에 속도와 비용을 보자는 식이다. 하지만 LLM 서비스에서는 이 순서가 자주 위험하다. 왜냐하면 운영 조건이 제품의 형태 자체를 바꾸기 때문이다.

예를 들어 평균 응답 시간이 8초가 걸리는 기능이라면, 일반 검색창처럼 설계하면 안 된다. 사용자는 느리다고 느낄 것이다. 대신 스트리밍, 진행 상태 표시, 비동기 처리, 결과 알림 같은 구조가 필요하다.

입력이 길어질수록 비용이 크게 늘어나는 기능이라면, 모든 문서를 한 번에 넣게 만들면 안 된다. 문서 개수 제한, 우선순위 선택, 요약 후 확장 보기 같은 흐름이 필요하다.

오답의 위험이 높은 업무라면, 자동 실행 구조 대신 추천과 승인 구조가 필요하다. 테넌트별 데이터 분리가 중요하다면, 기능 정의 단계부터 권한과 데이터 범위를 설계해야 한다.

즉, 운영 조건은 나중에 붙는 기술 제약이 아니다. 애초에 어떤 제품을 만들 수 있는지를 결정하는 조건이다.

네 가지 운영 조건은 초반에 반드시 적어야 한다

실무에서 최소한 이 네 가지는 제품 문서에 먼저 써두는 편이 좋다.

• 허용 가능한 지연 시간은 얼마인가

• 요청 1건당 감당 가능한 비용은 얼마인가

• 잘못된 답변이 나갔을 때의 피해 수준은 어느 정도인가

• 사람 검토가 필요한가, 가능하다면 어느 단계에서 개입하는가

이 네 줄만 적어도 모델 선택의 폭이 크게 달라진다. 예를 들어 "상담원 내부 초안 도구, 평균 5초까지 허용, 1건당 원가 낮아야 함, 사람 검토 필수"라면 비교적 저렴한 모델과 구조화 출력, 검토 중심 UI가 어울린다. 반대로 "유료 프리미엄 리서치 도구, 20초 허용 가능, 고가 모델 허용, 다만 근거 제시 필수"라면 완전히 다른 설계를 택할 수 있다.

같은 LLM이라도 제품의 운영 조건이 다르면 정답도 달라진다. 그래서 모델을 먼저 고르면 자꾸 설계가 어색해진다. 이미 산 신발에 발을 맞추는 꼴이 되기 쉽다.

모델 선택은 마지막이 아니라, 마지막에 가까운 결정이다

여기서 오해하면 안 된다. 모델 선택이 중요하지 않다는 뜻은 아니다. 중요하다. 다만 제품 초반에는 대개 결정해야 할 것들의 맨 앞이 아니라, 맨 뒤에 가까운 곳에 있다.

보통 순서는 이쪽이 더 건강하다.

첫째, 사용자 과업을 정의한다. 사용자가 무엇을 끝내고 싶은지 적는다.

둘째, 성공 흐름을 설계한다. 어떤 입력을 받고 어떤 결과를 보여주며 어떤 다음 행동으로 이어질지 정한다.

셋째, 실패 흐름을 설계한다. 부족한 정보, 낮은 확신, 느린 응답, 위험한 결과에 어떻게 대응할지 정한다.

넷째, 검증 기준을 만든다. 품질, 속도, 비용, 안전성, 사용성 기준을 세운다.

다섯째, 운영 조건을 적는다. 지연 시간, 원가, 권한, 데이터 범위, 사람 검토 구조를 정한다.

그다음에야 비로소 묻게 된다. "이 조건을 만족하려면 어떤 모델과 어떤 조합이 맞는가?"

이렇게 가면 모델 선택은 감각이 아니라 설계의 결과가 된다. 더 비싼 모델이 꼭 더 좋은 제품이 아니라, 제품 조건에 더 잘 맞는 모델이 좋은 모델이 된다.

작은 제품 명세서가 큰 시행착오를 줄인다

LLM 기능을 만들기 전에 거창한 문서를 쓸 필요는 없다. 하지만 아주 짧은 제품 명세서는 꼭 있는 편이 좋다. 예를 들면 이런 식이다.

예시: 고객지원 답변 초안 기능

사용자: 상담원

상황: 반복 문의에 빠르게 답해야 하지만 정책 문서를 매번 찾아보기 번거롭다.

목표: 상담원이 30초 안에 검토 가능한 초안을 얻는다.

입력: 고객 문의 내용, 고객 주문 정보, 관련 정책 문서

출력: 문의 유형, 추천 답변 초안, 근거 정책, 주의 문구

성공 기준: 상담원이 초안을 수정 후 발송하는 비율이 높고, 평균 처리 시간이 줄어든다.

실패 처리: 근거 부족 시 추정 답변 대신 추가 확인 필요 표시. 환불·법적 민감 이슈는 자동 발송 금지.

운영 조건: 평균 응답 5초 이내, 1건당 원가 제한, 모든 결과 로그와 검토 이력 저장.

이 정도만 있어도 팀의 대화가 달라진다. 이제 논의는 "어떤 모델이 가장 똑똑해요?"가 아니라 "이 출력을 안정적으로 만들려면 구조화 출력이 필요하겠네", "근거가 없을 때 답을 막아야겠네", "정책 문서 연결이 먼저겠네"로 바뀐다. 드디어 제품을 만들기 시작하는 것이다.

좋은 제품은 모델의 약점을 구조로 흡수한다

LLM은 강력하지만 완벽하지 않다. 그래서 좋은 제품은 모델이 잘하는 일을 전부 믿고 맡기지 않는다. 대신 모델의 약점을 제품 구조로 흡수한다.

예를 들어 이런 방식이다.

• 정보가 부족할 때는 추정하지 말고 추가 입력을 받는다.

• 자유 서술 대신 구조화된 출력으로 제한한다.

• 위험한 작업은 자동 실행하지 않고 승인 흐름을 둔다.

• 긴 응답이 필요할 때는 요약본을 먼저 보여준다.

• 답변과 함께 근거를 보여 사용자가 판단할 수 있게 한다.

• 품질이 흔들리는 영역은 사람 검토를 기본값으로 둔다.

이런 장치는 겉보기에 모델을 덜 믿는 것처럼 보일 수 있다. 하지만 실제로는 반대다. 모델이 잘하는 구간에서 더 안정적으로 힘을 발휘하게 만드는 방법이다. 제품은 모델의 재능을 끌어내는 무대이고, 운영은 그 무대가 무너지지 않게 하는 장치다.

첫 버전일수록 범위를 더 좁혀야 한다

모델부터 고르는 팀은 대개 기능 범위도 넓게 잡는다. "문서도 읽고, 답변도 하고, 분류도 하고, 추천도 하게 하자" 같은 식이다. 하지만 첫 버전에서 이런 욕심은 거의 항상 독이 된다. 무엇이 잘됐는지, 무엇이 실패했는지 알기 어려워지기 때문이다.

제품 설계가 먼저인 팀은 보통 더 좁게 시작한다. 한 사용자, 한 상황, 한 과업, 한 출력에 집중한다. 예를 들어 "환불 문의 초안 작성"처럼 아주 구체적인 문제로 시작한다. 그러면 성공 기준도 선명해지고, 실패 처리도 설계할 수 있고, 운영 조건도 계산 가능해진다.

LLM 서비스는 범위를 넓히는 것보다, 범위를 선명하게 자르는 능력이 더 중요하다. 초기에는 만능 비서보다 날카로운 도구가 낫다.

사용자 기대치를 설계하라

LLM 제품에서 기대치는 기능만큼 중요하다. 사용자가 무엇을 기대하느냐에 따라 같은 답변도 만족스럽게 느껴질 수도 있고 실망스럽게 느껴질 수도 있기 때문이다.

예를 들어 "무엇이든 물어보세요"라는 문구는 멋지지만, 제품이 감당해야 할 기대 범위를 지나치게 넓힌다. 반면 "회의록에서 결정 사항과 할 일을 정리합니다"라고 말하면 사용자는 훨씬 정확한 기대를 갖게 된다. 그러면 제품이 해야 할 일도 좁아지고 평가도 쉬워진다.

좋은 제품은 기능을 과장하지 않는다. 어디까지 잘하는지, 무엇은 못하는지, 어떤 입력이 좋고 어떤 결과가 나오는지 사용자에게 은근히 가르친다. 이것은 마케팅 문구의 문제가 아니라 품질 문제다. 기대치를 잘못 심으면, 같은 기술도 더 나쁜 제품처럼 보인다.

결국 제품 설계가 모델 선택의 기준을 만든다

이제 처음 질문으로 돌아가 보자. OpenAI, Claude, Gemini 중 무엇을 써야 할까? 이 질문에 바로 답하려는 순간, 팀은 다시 모델 중심 사고로 미끄러질 수 있다.

더 나은 질문은 이쪽이다.

• 우리 사용자는 어떤 과업을 더 빨리 끝내고 싶은가?

• 그 과업에서 필요한 출력 형식은 무엇인가?

• 실패하면 어떻게 보여주고 어떻게 막을 것인가?

• 어느 정도의 속도와 비용을 감당할 수 있는가?

• 사람 검토와 운영 통제는 어디에 넣을 것인가?

이 질문에 답한 뒤라면 모델 선택은 훨씬 쉬워진다. 긴 문맥이 중요한지, 구조화 출력이 중요한지, 속도가 더 중요한지, 비용 상한이 빡빡한지, 멀티모달 입력이 필요한지 같은 조건이 드러나기 때문이다. 그때 고르는 모델은 유행을 따르는 선택이 아니라, 제품 요구사항을 만족시키는 설계 선택이 된다.

마무리: 좋은 모델은 제품을 대신 설계해주지 않는다

LLM 시대에는 모델이 점점 더 좋아진다. 내년 모델은 올해 모델보다 더 똑똑할 가능성이 크다. 하지만 그 사실이 제품 설계를 덜 중요하게 만들지는 않는다. 오히려 반대다. 모델이 상향 평준화될수록 차이를 만드는 것은 더 선명한 사용자 흐름, 더 안전한 실패 경험, 더 명확한 검증 기준, 더 현실적인 운영 조건이 된다.

좋은 모델은 강력한 재료다. 하지만 재료가 좋다고 요리가 저절로 완성되지는 않는다. 누구를 위해 만들지, 어떤 맛을 낼지, 실패했을 때 어떻게 수습할지, 어떤 주방에서 얼마나 빨리 내야 할지를 먼저 정해야 한다.

LLM 서비스도 똑같다. 먼저 설계할 것은 모델이 아니라 제품이다. 사용자의 순간을 정의하고, 흐름을 만들고, 실패를 다루고, 검증 기준을 세우고, 운영 조건을 적어야 한다. 그 위에 모델을 올려야 비로소 서비스가 된다.

이 장에서 꼭 기억할 한 문장을 남기자.

좋은 모델이 좋은 제품을 보장하지는 않지만, 잘 설계된 제품은 모델의 장점을 실제 가치로 바꾼다.

다음 장부터는 이 설계를 실제 구현으로 옮기기 위해, LLM API가 공통적으로 어떤 구조를 갖는지부터 차근차근 살펴보자.