28장. 출시 이후의 개선 사이클

출시는 끝이 아니다. LLM 제품에서는 오히려 그때부터 진짜 일이 시작된다. 데모 단계에서는 누구나 그럴듯한 결과를 만들 수 있다. 하지만 실제 사용자가 들어오면 상황이 달라진다. 예상보다 엉뚱한 질문이 들어오고, 잘 쓰일 줄 알았던 기능은 외면받고, 사소해 보였던 한 단계의 불편이 반복 사용을 막는다. 모델 성능만으로 설명되지 않는 현실이 한꺼번에 밀려온다.

그래서 LLM 제품의 승부는 출시 순간보다 출시 이후 얼마나 빨리 학습하느냐에서 갈린다. 빨리 학습하는 팀은 사용자의 진짜 문제를 더 선명하게 이해하고, 유지율이 떨어지는 이유를 더 빨리 찾고, 모델을 어디에 써야 하는지와 어디에는 쓰지 말아야 하는지를 더 빨리 구분한다. 반대로 학습이 느린 팀은 늘 비슷한 기능을 바쁘게 추가하면서도 제품은 제자리걸음을 한다.

이 장에서는 출시 후 제품이 어떻게 좋아져야 하는지, 그리고 그 개선이 어떤 리듬으로 반복되어야 하는지를 제품 관점에서 정리해 보겠다.

출시 후 가장 먼저 봐야 하는 것은 "반응"이 아니라 "반복 사용"이다

출시 직후에는 팀이 숫자에 쉽게 흥분한다. 가입자가 몇 명인지, 첫 주에 호출 수가 얼마나 나왔는지, SNS에서 반응이 어떤지가 눈에 먼저 들어온다. 물론 이런 신호도 중요하다. 하지만 LLM 제품에서 더 중요한 질문은 따로 있다.

사람들이 한 번 놀라고 끝나는가, 아니면 다시 돌아오는가?

LLM 기능은 첫인상이 강하다. 사용자는 처음 결과를 보고 "오, 신기하네"라고 말한다. 문제는 그다음이다. 다음 날에도 쓰는가? 다음 주에도 돈을 낼 만큼 가치가 있는가? 팀 안에서 한 사람만 쓰는가, 아니면 다른 동료에게도 퍼지는가? 이 질문에 답하지 못하면 출시 성공처럼 보였던 숫자는 금방 사라진다.

그래서 출시 직후의 핵심 지표는 단순 방문 수가 아니라 반복 사용과 습관 형성에 가깝다. 특히 다음과 같은 흐름을 보는 것이 중요하다.

• 처음 사용한 사람이 핵심 결과를 실제로 얻었는가

• 첫 경험 이후 다시 돌아온 비율은 어떤가

• 반복 사용자가 공통적으로 밟는 경로는 무엇인가

• 유료 고객이 결제를 유지하는 이유와 끊는 이유는 무엇인가

LLM 제품은 "좋아 보이는 기능"보다 "다시 쓰게 되는 흐름"이 더 중요하다. 한마디로, 첫 박수보다 두 번째 방문이 더 값지다.

피드백은 말로만 듣지 말고 행동으로도 읽어야 한다

출시 후 팀은 보통 피드백 수집부터 시작한다. 그런데 이 단계에서 흔히 생기는 오해가 있다. 사용자가 남긴 말이 곧 원인이라고 생각하는 것이다.

예를 들어 사용자가 "답변 품질이 별로예요"라고 말했을 때, 정말 모델이 나쁜 것일까? 실제로는 입력이 너무 넓어서 실패했을 수도 있고, 결과가 길어서 핵심이 안 보였을 수도 있고, 기대한 출력 형식과 달라서 별로라고 느꼈을 수도 있다. 사용자의 말은 매우 중요하지만, 그것만으로는 충분하지 않다.

좋은 팀은 피드백을 두 층으로 모은다. 하나는 사용자가 직접 말한 피드백이고, 다른 하나는 사용자가 남긴 행동 데이터다. 이 둘이 만나야 진짜 문제가 보인다.

직접 피드백에는 만족도 평가, 자유 의견, CS 문의, 영업 통화 메모, 이탈 고객 인터뷰 같은 것이 들어간다. 행동 데이터에는 첫 결과 생성 성공률, 재시도 횟수, 복사 버튼 클릭, 편집 후 사용 비율, 세션 길이, 팀 공유 여부, 유료 전환 전 사용 패턴 같은 것이 들어간다.

이 둘을 같이 보면 해석이 훨씬 선명해진다. 사용자는 "정확하지 않다"고 말했는데, 실제로는 결과를 거의 읽지 않고 바로 새로고침만 여러 번 눌렀다면 품질만의 문제가 아닐 수 있다. 반대로 만족도 점수는 높아 보여도 반복 사용이 없다면, 감탄은 있지만 습관은 없는 기능일 수 있다.

제품팀이 정말 알고 싶은 것은 의견의 총합이 아니다. 어떤 사용자 집단이 어떤 순간에 왜 멈추는가다.

유지율은 전체 평균보다 코호트와 사용 맥락으로 봐야 한다

유지율 분석은 LLM 제품에서 특히 중요하다. 왜냐하면 이 제품들은 겉으로는 모두 "질문하고 답을 받는 도구"처럼 보여도, 실제 반복 사용 구조는 아주 다르기 때문이다.

회의록 요약 서비스와 개발자 코파일럿은 같은 방식으로 유지율을 보면 안 된다. 회의록 요약은 회의가 열리는 리듬에 따라 주간 반복이 더 중요할 수 있고, 개발자 도구는 거의 매일 사용해야 습관이 생길 수 있다. 고객지원용 내부 코파일럿은 개인 유지율보다 팀 단위 침투율이 더 중요할 수도 있다.

그래서 유지율은 단일 숫자로 끝내면 안 된다. 최소한 다음 세 가지로 나눠 봐야 한다.

첫째는 사용자 코호트다. 어떤 주에 가입한 사용자가 이후 얼마나 남는지 보면, 최근 온보딩 변경이 실제로 좋아졌는지 나빠졌는지 보인다.

둘째는 사용 맥락이다. 무료 사용자와 유료 사용자는 다르고, 개인 사용자와 팀 계정은 다르며, 문서 요약을 주로 쓰는 집단과 고객 응답 초안을 주로 쓰는 집단은 완전히 다른 제품처럼 행동한다.

셋째는 핵심 행동 도달 여부다. 계정 생성만 하고 떠난 사용자와, 첫 번째 유용한 결과를 만든 뒤 떠난 사용자는 같은 이탈이 아니다. 전자는 온보딩 문제일 가능성이 크고, 후자는 반복 가치가 약한 문제일 가능성이 크다.

유지율은 제품의 체온계와 비슷하다. 숫자 자체보다, 어느 구간에서 얼마나 떨어지는지가 더 중요하다. 계정 생성 직후 급락하면 첫 경험이 약한 것이다. 첫 주는 괜찮은데 둘째 주에 빠지면 반복 사용 이유가 약한 것이다. 유료 전환 후 한 달 안에 빠지면 가격보다 가치 설명이나 실제 팀 정착이 부족한 것이다.

출시 후 개선은 네 가지 질문으로 정리할 수 있다

출시 후의 모든 개선은 복잡해 보이지만, 결국 네 가지 질문으로 정리할 수 있다.

첫 번째 질문은 이것이다. 누가 계속 쓰고 있는가?

여기서 제품은 가장 건강한 사용자 집단을 찾아야 한다. 어떤 고객은 유난히 자주 쓰고, 만족도도 높고, 팀 안으로 확산도 잘 된다. 이 집단은 우연히 붙잡힌 고객이 아니라, 제품이 현재 가장 잘 맞는 시장 신호일 가능성이 크다.

두 번째 질문은 누가 중간에 멈추는가?다.

중간 이탈은 늘 이유가 있다. 첫 결과가 불안정했는지, 입력이 귀찮았는지, 결과를 실제 업무에 붙이기 어려웠는지, 가격에 비해 효용이 약했는지 구간별로 확인해야 한다.

세 번째 질문은 지금의 핵심 가치는 무엇인가?다.

팀은 종종 제품을 넓게 정의한다. "우리는 업무 생산성을 높이는 AI 플랫폼입니다" 같은 말은 멋있지만 개선 방향을 알려주지 않는다. 출시 후에는 더 좁고 더 선명한 문장이 필요하다. 예를 들어 "회의 내용을 실행 항목으로 빠르게 바꾸는 도구"처럼 핵심 가치를 좁혀야 한다. 그래야 어떤 기능을 더 다듬고 무엇을 버릴지 결정할 수 있다.

네 번째 질문은 다음 개선이 유지율을 올릴 가능성이 있는가?다.

기능 추가는 늘 재미있다. 하지만 제품을 강하게 만드는 기능은 대개 화려한 신기능이 아니라, 반복 사용 경로를 덜 끊기게 만드는 개선이다. 결국 출시 후 로드맵은 재미보다 잔존을 기준으로 정리되어야 한다.

제품 개선 사이클은 "수집-해석-선택-실험-정착"으로 돌아간다

출시 후 팀이 계속 배워야 한다고 말하면 모두 고개를 끄덕인다. 문제는 그 학습이 회의실의 구호로 끝나는 경우가 많다는 점이다. 실제로는 학습도 반복 가능한 구조가 있어야 한다.

가장 실전적인 개선 사이클은 다섯 단계로 이해하면 좋다.

수집: 신호를 한곳에 모은다

먼저 사용자 의견, 세션 로그, 재시도 패턴, 취소 이유, CS 대화, 영업 피드백을 한곳으로 모은다. 이 단계에서는 데이터가 완벽할 필요는 없다. 중요한 것은 신호가 흩어지지 않게 만드는 것이다. 서로 다른 팀이 각자 다른 해석을 하기 시작하면 제품은 금방 방향을 잃는다.

해석: 증상을 문제 유형으로 묶는다

그다음에는 신호를 비슷한 문제끼리 묶어야 한다. 예를 들어 "결과가 들쭉날쭉하다"는 품질 안정성 문제로, "좋긴 한데 손이 더 간다"는 워크플로 연결 문제로, "한 번 써보고 말았다"는 반복 가치 부족 문제로 분류할 수 있다.

여기서 중요한 것은 모든 이슈를 모델 문제로 번역하지 않는 것이다. 출시 후 실제 문제의 상당수는 모델 능력치보다 제품 흐름, 기대 관리, 입력 구조, 협업 기능, 가격 설계에서 나온다.

선택: 가장 중요한 한두 개만 고른다

문제를 많이 아는 것과 잘 고르는 것은 다르다. 한 번의 스프린트에서 다섯 가지를 동시에 해결하려 하면, 결국 아무것도 선명하게 배우지 못한다. 그래서 팀은 늘 지금 가장 중요한 한두 가지를 정해야 한다.

이때 기준은 단순하다. 반복 사용에 가장 큰 영향을 주는가, 핵심 사용자에게 중요한가, 비교적 짧은 시간 안에 검증 가능한가를 함께 본다.

실험: 작은 변경으로 가설을 검증한다

출시 후 개선은 대개 거대한 리뉴얼보다 작은 실험이 더 강하다. 온보딩 문구 하나를 바꾸거나, 첫 결과 예시를 제공하거나, 출력 형식을 두 가지로 분리하거나, 특정 사용자군에 더 적합한 기본 프리셋을 주는 식의 변경이 의외로 큰 차이를 만든다.

LLM 제품에서는 특히 한 번에 너무 많은 걸 바꾸면 안 된다. UI, 프롬프트, 모델, 가격을 동시에 바꾸면 숫자가 움직여도 이유를 설명할 수 없다. 작은 실험일수록 배움이 축적된다.

정착: 효과가 있으면 운영의 기본값으로 만든다

실험이 성공했다고 끝이 아니다. 그 변경이 일시적인 해프닝이 아니라 제품의 새로운 기본값이 되도록 문서화하고, 온보딩과 운영 도구, 지표 대시보드에 반영해야 한다. 팀이 실험을 잘하는 것만큼, 배운 것을 잊지 않는 것도 중요하다.

LLM 제품에서 모델 개선은 제품 개선의 일부여야 한다

출시 후 팀은 자주 이런 유혹에 빠진다.

"요즘 더 좋은 모델이 나왔다는데, 갈아타면 다 좋아지는 것 아닐까?"

물론 어떤 시점에는 모델 변경이 큰 차이를 만든다. 하지만 출시 이후의 모델 개선은 벤치마크 점수보다 제품의 실제 사용 장면에서 평가해야 한다. 모델이 더 똑똑해졌다는 이유만으로 고객 가치가 커지는 것은 아니다.

예를 들어 더 비싼 모델이 답변 길이와 문장 품질은 좋아졌는데, 사용자는 여전히 복사 후 손으로 많이 고친다면 핵심 문제는 남아 있는 것이다. 반대로 아주 강력한 모델이 아니어도 특정 업무 템플릿과 구조화 출력, 후처리 로직이 잘 결합되면 반복 사용은 크게 늘 수 있다.

그래서 모델 개선은 다음 순서로 보는 것이 좋다.

먼저 현재 고객이 자주 겪는 실패 패턴을 확인한다. 그 실패가 정말 모델 한계 때문인지, 아니면 입력 구조나 컨텍스트 설계 문제인지 본다. 그다음 실제 사용 시나리오를 기준으로 작은 집단에서 비교 실험을 한다. 마지막으로 품질뿐 아니라 속도, 비용, 재시도율, 편집량, 유료 유지율까지 같이 본다.

모델 개선의 질문은 "어느 모델이 더 똑똑한가"가 아니라, 어느 구성이 더 많이 다시 쓰이게 만드는가여야 한다.

기능 확장은 옆으로 넓히기보다 아래로 깊게 파야 한다

출시 후 어느 정도 사용자가 붙기 시작하면 팀은 확장 욕구를 느낀다. 요약이 되니 번역도 넣고 싶고, 분류도 넣고 싶고, 챗봇도 붙이고 싶고, 이미지 입력도 받게 하고 싶다. 가능한 일이 많아 보이기 때문이다.

하지만 제품이 강해지는 확장은 대개 "기능 수 증가"가 아니라 "핵심 워크플로 깊이 증가"에서 나온다.

예를 들어 회의록 요약 서비스가 있다고 해 보자. 여기서 옆으로 넓히는 확장은 블로그 초안 생성, 이메일 작성, 문서 번역 같은 기능을 마구 붙이는 일이다. 반면 아래로 깊게 파는 확장은 회의 녹음 업로드, 화자 구분, 액션 아이템 추출, 담당자 할당, Slack 공유, 후속 일정 생성처럼 하나의 업무 흐름을 완성하는 방향이다.

돈이 되는 제품은 대개 두 번째에 가깝다. 사용자는 기능 목록이 아니라 문제 해결의 마찰이 얼마나 줄었는지에 돈을 낸다.

기능 확장을 고민할 때는 다음 질문이 유용하다.

• 이 기능이 핵심 사용자의 반복 사용 빈도를 높이는가

• 이 기능이 결과를 실제 업무 행동으로 연결해 주는가

• 이 기능이 기존 강점을 더 분명하게 만드는가

• 이 기능이 제품을 더 넓게가 아니라 더 끈끈하게 만드는가

신기한 기능은 홍보에 도움이 되지만, 끈끈한 기능이 유지율을 만든다.

출시 후 로드맵은 신규 기능보다 "마찰 제거 지도"에 가까워야 한다

많은 팀이 로드맵을 기능 목록처럼 쓴다. 그런데 출시 후 일정 기간 동안은 그 방식이 잘 맞지 않는다. 이 시기의 로드맵은 새로운 걸 얼마나 많이 넣을지가 아니라, 사용자가 핵심 가치를 얻는 과정에서 어디서 걸리는지를 얼마나 줄일지에 더 가까워야 한다.

예를 들어 다음과 같은 마찰이 있을 수 있다.

• 처음 무엇을 입력해야 할지 모르겠다

• 결과는 좋지만 형식이 매번 달라 바로 쓸 수 없다

• 팀원과 공유하거나 검토하기 어렵다

• 한 번의 결과로 끝나고 다음 행동으로 이어지지 않는다

• 가격이 비싼 게 아니라, 가치가 눈에 보이지 않는다

이런 마찰을 하나씩 줄이면 제품은 더 매끄러워진다. 그리고 놀랍게도 많은 경우 매끄러움이 새로운 기능보다 더 큰 성장을 만든다. 사용자가 원하는 것은 놀라운 데모보다 덜 피곤한 반복이다.

팀이 매주 봐야 할 숫자와 매달 봐야 할 숫자는 다르다

출시 후 개선 사이클이 제대로 돌아가려면 숫자도 리듬에 맞게 봐야 한다. 모든 지표를 매일 들여다보면 오히려 노이즈에 흔들린다.

매주 봐야 할 숫자는 비교적 빠르게 움직이는 운영형 지표다. 첫 결과 생성률, 재시도율, 세션당 성공 작업 수, 편집 후 채택 비율, 핵심 기능 사용률, 불만 유형 변화 같은 지표가 여기에 들어간다. 이 숫자는 지금 실험한 개선이 바로 영향을 주는지 확인하기 좋다.

매달 봐야 할 숫자는 더 느리지만 더 본질적인 제품 지표다. 코호트 유지율, 팀 확산률, 유료 전환률, 유료 유지율, 고객당 사용 깊이, 가격 플랜별 수익성 같은 숫자가 여기에 해당한다. 이 숫자는 제품이 진짜 사업이 되어 가는지 알려 준다.

즉 주간 회의는 "무엇이 막히는가"를 보고, 월간 회의는 "무엇이 남는가"를 봐야 한다.

좋은 출시 후 개선 회의는 책임 추궁보다 학습 속도를 높인다

출시 후 문제가 생기면 팀 분위기가 쉽게 예민해진다. 특히 LLM 제품은 결과가 불안정하게 보일 수 있어서, 누군가는 모델 탓을 하고 누군가는 프롬프트 탓을 하고 누군가는 사용자 탓을 한다. 하지만 이런 분위기에서는 학습 속도가 급격히 떨어진다.

좋은 개선 회의는 누가 틀렸는지를 따지는 자리가 아니라, 무엇을 배웠고 다음엔 무엇을 더 빨리 검증할지를 정하는 자리여야 한다. 그래서 회의에서는 다음 같은 질문이 반복되어야 한다.

이번 주에 반복 사용자를 늘린 신호는 무엇이었는가. 어디에서 이탈이 가장 컸는가. 새로 추가한 기능 중 핵심 가치에 기여하지 않은 것은 무엇인가. 실제 사용자 작업 흐름을 더 짧게 만든 변화는 무엇이었는가. 다음 실험은 어떤 가설을 검증하는가.

이 질문들이 쌓이면 팀은 감에 의존하지 않고 점점 더 빠르게 움직이게 된다. 출시 후 개선의 본질은 열심히 일하는 것이 아니라, 배움을 더 빨리 쌓는 것이다.

사례로 보는 출시 후 개선 사이클

AI 제안서 작성 SaaS를 예로 들어 보자. 출시 초반에는 반응이 좋았다. 많은 사용자가 가입했고, 생성 결과도 꽤 그럴듯했다. 그런데 한 달 뒤 보니 반복 사용이 기대보다 낮았다.

인터뷰를 해 보니 사용자들은 이런 말을 했다. "처음엔 좋았는데 실제 제출용으로는 손볼 게 많다." 로그를 보니 더 흥미로운 사실이 있었다. 많은 사용자가 초안을 생성한 뒤 복사만 하고 다시 돌아오지 않았다. 팀은 처음에 모델 품질 문제라고 생각했다. 하지만 더 깊이 보니 진짜 문제는 따로 있었다.

첫째, 입력이 너무 자유로워 사용자마다 기대하는 제안서 구조가 달랐다. 둘째, 결과는 길었지만 회사 내부 포맷에 맞지 않아 매번 많이 고쳐야 했다. 셋째, 생성 이후 검토와 공유, 버전 관리 흐름이 약해 실제 팀 업무에 붙지 못했다.

이 팀은 방향을 바꿨다. 먼저 업종별 템플릿과 제안서 목적별 시작 화면을 만들었다. 다음으로 출력 형식을 섹션 단위로 구조화해 바로 수정하기 쉽게 바꿨다. 마지막으로 팀 리뷰와 코멘트 기능을 붙여 생성 결과가 문서 작업 흐름 안으로 들어가게 했다.

그 결과 모델은 그대로였는데도 반복 사용이 올라갔다. 이후에야 특정 고가 고객군을 대상으로 더 강한 모델을 시험했고, 그 집단에서만 프리미엄 플랜 전환이 의미 있게 늘었다. 이 사례가 보여 주는 것은 분명하다. 출시 후 개선은 모델 성능을 올리는 경기이기 전에, 실제 업무 흐름에 더 잘 붙게 만드는 경기라는 점이다.

결국 더 강한 제품은 더 빨리 배우는 제품이다

LLM 시장은 변화가 빠르다. 새 모델이 나오고, 가격이 바뀌고, 경쟁 제품이 우후죽순 생긴다. 그래서 팀은 자칫 바깥 변화에만 정신을 빼앗기기 쉽다. 하지만 실제로 오래 살아남는 제품은 외부 변화에 가장 빨리 반응하는 팀이 아니라, 자기 사용자에게서 가장 빨리 배우는 팀이다.

출시 후 개선 사이클의 핵심은 거창하지 않다. 사용자 반응을 모으고, 유지율이 떨어지는 지점을 찾고, 핵심 가치를 더 좁고 선명하게 정의하고, 작은 실험으로 반복 사용을 높이고, 그 과정에서 모델과 기능을 제품 안에 맞게 조정하는 것이다. 이 바퀴를 빨리, 그리고 꾸준히 돌리는 팀이 결국 앞서간다.

출시 순간은 출발선이다. 박수는 잠깐이고, 습관은 오래간다. LLM 제품의 승부는 "처음에 얼마나 놀라웠는가"보다, 그다음 달에 얼마나 더 유용해졌는가에서 결정된다.

마치며

이 책의 마지막 장에서 꼭 남기고 싶은 말이 있다. LLM 제품은 정답을 한 번에 찾아가는 사업이 아니다. 가설을 세우고, 실제 사용 속에서 틀린 부분을 발견하고, 더 나은 기본값을 만들어 가는 사업이다.

출시 후에는 모든 것이 선명해진다. 누가 남는지, 누가 떠나는지, 무엇이 진짜 가치인지, 무엇이 단지 데모에 불과했는지 드러난다. 이때 중요한 것은 완벽한 첫 버전이 아니라, 배우고 고치는 리듬을 가진 팀이다.

결국 돈이 되는 서비스는 화려한 AI 기능을 많이 붙인 서비스가 아니다. 사용자의 반복되는 문제를 더 빠르게 이해하고, 더 작게 실험하고, 더 꾸준히 좋아지는 서비스다. 그리고 그 힘은 언제나 출시 이후의 개선 사이클에서 나온다.