책에 포함된 노트실전 LLM 서비스 개발: ChatGPT·Claude·Gemini API로 만드는 AI 웹 서비스의 설계부터 운영까지

26장. 대표적인 LLM SaaS 패턴

2026-04-24Views 26약 10분생성형 AI 활용

26장. 대표적인 LLM SaaS 패턴

새로운 기술이 등장하면 사람들은 늘 비슷한 질문을 한다. "아무도 안 해본 걸 해야 하지 않을까?"

그런데 돈이 되는 SaaS는 종종 정반대로 움직인다. 완전히 새로운 것을 만들기보다, 이미 시장에서 반복적으로 먹힌 문제 구조를 먼저 이해하고, 그 위에 더 나은 제품 경험을 쌓는다. LLM도 마찬가지다. 지금 수익을 만드는 서비스들을 보면, 겉모습은 달라도 안쪽 구조는 몇 가지 패턴으로 자주 수렴한다.

이 장에서 말하는 패턴은 유행어가 아니다. "이런 문제는 이런 제품 형태로 풀릴 때 결제와 반복 사용이 붙기 쉽다"는 실전형 설계 단위다. 특히 요약 SaaS, 업무 코파일럿, 지식 검색, 자동화 도구는 이미 여러 시장에서 검증된 대표 패턴이다. 새로움을 좇기 전에 이 패턴들을 이해하면, 실패 확률은 내려가고 제품의 방향은 훨씬 또렷해진다.

6부. 실제로 돈 되는 서비스 만들기 / 26장. 대표적인 LLM SaaS 패턴

왜 패턴부터 봐야 하는가

LLM 시대에는 데모를 만드는 것이 너무 쉽다. 프롬프트 몇 줄, API 키 하나, 채팅 UI 하나면 꽤 그럴듯한 프로토타입이 나온다. 문제는 그 다음이다. 데모는 사람을 놀라게 하지만, 제품은 사람을 다시 돌아오게 해야 한다.

그래서 초기에 중요한 질문은 "무엇이 신기한가?"가 아니라 "어떤 형태가 이미 반복 사용과 결제로 이어졌는가?"다. 실제 현장에서는 대부분의 팀이 완전한 AI 전용 제품보다, 기존 업무 흐름 위에 얹히는 보조 기능, 검색, 초안 작성, 분류, 요약, 승인형 자동화부터 시작한다. LLM을 제품의 전부로 두기보다, 결정적이지만 통제 가능한 한 부분으로 넣는 편이 더 안정적이기 때문이다.¹

쉽게 말해, 처음부터 마법사를 만들려 하지 말고 잘 팔리는 전동 공구부터 이해하자는 뜻이다.

대표 패턴은 네 가지로 압축된다

시장에서 자주 보이는 LLM SaaS 패턴은 대체로 네 갈래로 정리할 수 있다.

입력된 정보를 더 짧고 쓰기 좋게 바꾸는 생산성 보조형
흩어진 문서와 지식을 찾아 답하는 지식 검색형
기존 SaaS 화면 안에서 사용자를 도와주는 업무 코파일럿형
반복 업무를 단계적으로 처리하는 자동화 오퍼레이터형

실제 서비스는 이 네 가지를 섞어 쓴다. 예를 들어 고객지원 AI는 문의 분류 기능으로 시작해, 정책 문서 검색을 붙이고, 상담사 답변 초안을 제공한 뒤, 마지막에는 티켓 라우팅까지 자동화할 수 있다. 하지만 제품을 설계할 때는 먼저 "우리의 중심 패턴이 무엇인가"를 정해야 한다. 중심이 흐리면 화면도 흐리고, 가격도 흐리고, 누가 돈을 낼지도 흐려진다.

이제 하나씩 보자.

패턴 1. 요약 SaaS와 재작성 도구: 가장 빨리 만들 수 있고, 가장 빨리 상품성이 드러난다

가장 먼저 검증된 패턴은 요약, 재작성, 초안 작성, 분류 같은 생산성 보조형이다. 회의록 요약, 문서 압축, 이메일 초안, 보고서 정리, 마케팅 카피 변환처럼 "긴 것을 짧게", "거친 것을 다듬어", "빈 화면을 초안으로" 바꾸는 제품이 여기에 들어간다.

이 패턴이 강한 이유는 아주 단순하다. 사용자가 얻는 가치가 즉시 보이기 때문이다. 문서를 넣었더니 30초 뒤 요약이 나오고, 회의록을 올렸더니 액션 아이템이 정리되면, 사용자는 첫날부터 시간을 아꼈다고 느낀다. 진입 장벽도 낮다. 별도의 데이터 파이프라인 없이 API 호출만으로 MVP를 만들 수 있고, 사용자가 제품 가치를 이해하기도 쉽다.²

하지만 이 패턴에는 함정도 있다. 너무 쉽게 보이기 때문에, 경쟁도 아주 쉽다. "문서 요약"만으로는 금세 범용 기능이 되어 버린다. 따라서 생산성 보조형이 진짜 제품이 되려면, 단순 생성기를 넘어 특정 업무 흐름을 붙잡아야 한다.

예를 들어 회의 요약 SaaS라면 단지 요약문만 뽑아 주는 데서 끝나면 약하다. 대신 결정 사항, 담당자별 할 일, 다음 회의 전 준비 항목, 팀 채널 공유, 검색 가능한 히스토리까지 이어지면 갑자기 제품이 된다. 사용자는 텍스트를 사는 것이 아니라 회의 후 정리 시간을 사는 셈이다.

이 패턴이 특히 잘 맞는 분야는 다음과 같다.

텍스트가 많고 반복 문서가 많은 팀
초안을 만드는 시간이 길지만 품질 기준은 비교적 명확한 팀
완전 자동화보다 "초안 + 검토"만으로도 큰 시간을 줄일 수 있는 팀

수익화도 비교적 쉽다. 개인 사용자에게는 빠른 체험을, 팀 사용자에게는 저장, 히스토리, 협업, 템플릿, 대량 처리, 브랜드 톤 관리 기능을 팔 수 있기 때문이다. 다만 차별화의 핵심은 모델이 아니라 워크플로라는 점을 잊으면 안 된다.

생산성 보조형의 승부처는 "더 잘 써준다"가 아니라 "바로 쓸 수 있게 만든다"다

좋은 재작성 도구는 문장을 멋지게 바꿔 주는 데서 멈추지 않는다. 사용자가 실제로 원하는 출력 형식을 미리 준비해 둔다. 예를 들어 "임원 보고용 요약", "고객 발송용 정중한 버전", "슬랙 공지용 5줄 요약"처럼 목적별 버튼을 제공하면 사용자는 프롬프트를 고민하지 않아도 된다.

이런 제품은 UX가 매우 중요하다. 생성 결과를 바로 보여 주는 스트리밍, 다시 생성 버튼, 더 짧게·더 공손하게 같은 정제 버튼, 결과를 즉시 수정할 수 있는 인플레이스 편집, 이전 결과 히스토리는 생산성 보조형에서 특히 강한 패턴으로 자리 잡았다.³

한마디로 말하면, 요약 SaaS는 "LLM이 잘 쓴다"보다 "사용자가 생각보다 덜 고민해도 된다"에서 승부가 난다.

패턴 2. 지식 검색 SaaS: 사람들은 검색창보다 '근거 있는 답'을 원한다

두 번째 패턴은 지식 검색형이다. 내부 문서, 고객지원 문서, 정책 문서, 매뉴얼, 위키, 계약서, FAQ 같은 자료를 기반으로 질문에 답하는 형태다. 기술적으로는 대개 RAG, 즉 검색 증강 생성 구조를 쓴다. 사용자의 질문과 관련 있는 문서 조각을 먼저 찾고, 그 문맥을 바탕으로 모델이 답하게 만드는 방식이다.⁴

이 패턴이 검증된 이유는 명확하다. 대부분의 조직에는 이미 문서가 넘쳐난다. 문제는 문서가 없는 것이 아니라, 사람이 못 찾는다는 데 있다. 검색 결과가 너무 많거나, 키워드가 조금만 달라도 못 찾거나, 문서를 찾아도 다시 읽고 요약해야 하는 일이 번거롭다. 지식 검색 SaaS는 바로 여기서 돈을 번다. "문서를 저장하는 서비스"가 아니라 "필요한 순간에 근거 있는 답을 꺼내주는 서비스"가 되는 것이다.

지식 검색형은 특히 B2B에서 강하다. 사내 지식 검색, 고객지원 상담사 보조, 법무 문서 질의응답, 제품 매뉴얼 도우미, 규정 검색, 영업 자료 탐색 같은 용도는 모두 반복 사용성이 높다. 무엇보다 사용자가 질문하고 끝나는 것이 아니라, 실제 업무 판단과 연결되기 쉽다.

다만 이 패턴에서 가장 중요한 것은 답변 그 자체보다 신뢰다. 그래서 좋은 제품은 단순히 답만 주지 않고, 어느 문서를 근거로 삼았는지 인라인 출처를 함께 보여 준다. 클릭하면 원문을 확인하게 만들고, 근거가 부족하면 솔직하게 "지원 근거를 찾지 못했다"고 말하는 편이 오히려 더 신뢰를 얻는다.³

지식 검색형의 멋진 점은 하나 더 있다. 새로 학습시키지 않아도 외부 지식과 사내 데이터를 거의 실시간으로 반영할 수 있다는 점이다. 그래서 미세 조정보다 먼저 RAG를 고려하라는 조언이 실무에서 반복적으로 나온다.⁴

지식 검색형이 잘 팔리려면 '검색'보다 '업무 맥락'을 좁혀야 한다

많은 팀이 여기서 흔히 실수한다. "우리 회사의 모든 문서를 다 넣어 보자"로 시작하는 것이다. 물론 할 수는 있다. 하지만 그렇게 하면 답이 오히려 흐려진다. 검색 범위가 너무 넓으면 관련성이 떨어지고, 사용자는 다시 "대충 그럴듯한 답"을 받았다고 느낀다.

시장에서는 보통 좁은 범위의 지식 검색형이 더 강하다. 예를 들어 "고객지원용 정책 Q&A", "온보딩 문서 도우미", "제품 기술문서 검색", "법무팀 계약 조항 검색"처럼 질문의 종류와 문서군이 어느 정도 제한될수록 정확도와 신뢰가 올라간다.

또 하나 중요하다. 멀티테넌트 SaaS에서는 검색 정확도만큼 데이터 격리도 중요하다. 벡터 검색은 눈에 잘 보이지 않기 때문에, 테넌트 필터링과 권한 검사를 느슨하게 하면 다른 고객 문서가 섞일 위험이 있다. 그래서 실제 프로덕션 구조에서는 테넌트 단위 인덱스 분리나 메타데이터 기반 사전 필터링, 관계형 DB의 행 수준 보안 같은 방어층을 함께 두는 패턴이 강조된다.⁵

즉 지식 검색형은 "똑똑한 검색창"이 아니라, "권한이 지켜진 믿을 만한 내부 전문가"처럼 느껴질 때 비로소 돈이 된다.

패턴 3. 업무 코파일럿: 채팅창이 아니라 일하는 화면 속 조수

세 번째 패턴은 업무 코파일럿형이다. 이것이 요즘 가장 화려하게 보이는 패턴이지만, 사실 구조는 의외로 소박하다. 코파일럿은 별도 앱이 아니라, 기존 SaaS 안에서 사용자의 현재 작업을 이해하고 도와주는 보조 레이어다. 중요한 점은 "질문에 답하는 챗봇"이 아니라 "지금 하던 일을 덜 귀찮게 만드는 조수"라는 점이다.⁶

이 패턴이 강력한 이유는 사용자가 원래 하던 흐름을 거의 바꾸지 않기 때문이다. GitHub Copilot이 강했던 것도 개발자가 IDE를 떠나지 않아도 되었기 때문이다. 좋은 AI 제품은 사용자의 도구를 바꾸라고 요구하지 않고, 기존 작업대 위에 자연스럽게 얹힌다.⁷

업무 코파일럿의 대표 예시는 아주 많다. CRM에서는 고객 히스토리 요약과 후속 액션 제안을 해 주고, 고객지원 툴에서는 답변 초안과 정책 근거를 제시하고, 분석 도구에서는 현재 대시보드 값을 설명해 주고, 프로젝트 관리 도구에서는 진행 상황을 보고 다음 행동을 제안한다. 여기에 한 단계 더 나아가면, 코파일럿은 단순 설명을 넘어 실제 액션도 제안한다. "이 티켓을 환불팀으로 넘길까요?", "이 리드를 다음 주 화요일에 팔로업 일정으로 만들까요?" 같은 식이다.⁶

이 패턴에서 중요한 것은 세 가지다.

현재 화면과 사용자 상태를 충분히 문맥으로 주입할 것
단순 채팅보다 인라인 추천과 빠른 액션 버튼을 우선할 것
불가역적 행동은 자동 실행보다 승인 흐름을 둘 것

특히 코파일럿 UX는 채팅보다 인라인이 더 강한 경우가 많다. 사용자는 "AI와 대화할 시간"보다 "지금 이 화면에서 바로 다음 행동을 줄여주는 도움"을 원하기 때문이다.⁸

코파일럿은 왜 잘 팔리는가

코파일럿형은 수익화 포인트가 명확하다. 첫째, 기존 SaaS의 핵심 사용 시간을 늘린다. 사용자가 더 오래 머문다는 뜻이 아니라, 같은 시간 안에 더 많은 일을 하게 만든다는 뜻이다. 둘째, AI가 별도 툴이 아니라 기존 제품의 프리미엄 가치가 된다. 그래서 새로운 제품을 파는 대신 기존 플랜 업셀로 연결하기 좋다. 셋째, 화면 맥락, 사용자 역할, 과거 행동, 제품 내부 데이터가 모두 쌓일수록 다른 범용 툴보다 강해진다.⁶⁹

하지만 함정도 있다. 많은 팀이 코파일럿을 만든다며 결국 화면 오른쪽에 채팅창 하나 붙이고 끝낸다. 그러면 사용자는 두 번 질문해야 한다. 첫째, AI에게 질문을 던져야 하고, 둘째, 나온 답을 실제 행동으로 바꿔야 한다. 이중 노동이다.

반대로 좋은 코파일럿은 사용자가 질문하기 전에 필요한 맥락을 이미 알고 있고, 답 뒤에 곧바로 행동 버튼을 붙인다. "설명"과 "실행"이 가까워질수록 코파일럿은 채팅에서 제품 기능으로 진화한다.

패턴 4. 자동화 도구: 초안을 넘어서 업무를 굴리는 서비스

네 번째 패턴은 자동화 오퍼레이터형이다. 이 패턴은 가장 강력하지만, 가장 늦게 도달하는 경우가 많다. 왜냐하면 단순 생성보다 더 많은 책임이 따르기 때문이다.

자동화 도구는 사용자의 요청을 받아 긴 작업을 대신 수행한다. 예를 들어 티켓 분류와 라우팅, 제안서 패키지 준비, 회계 메모 생성, 장애 리포트 정리, 미팅 후 CRM 업데이트, 문서 검토 후 후속 태스크 생성 같은 흐름이 여기에 속한다. 핵심은 "답을 준다"가 아니라 "작업 단계를 진행시킨다"는 것이다.

이 패턴이 실제로 돈이 되는 이유는 가장 직접적으로 인건비와 시간을 줄이기 때문이다. 특히 사람이 매번 비슷한 판단을 하고, 그 뒤에 비슷한 시스템 입력을 반복하는 업무에서 강력하다. 상담 분류, 리포트 초안 작성, 내부 티켓 생성, 데이터 정리 같은 작업이 대표적이다.¹²

하지만 이 패턴은 거의 항상 비동기 구조가 필요하다. LLM 호출은 느리고, 중간에 외부 API도 호출하고, 재시도도 필요하며, 실패 처리도 해야 하기 때문이다. 그래서 실제 제품에서는 요청 핸들러 안에서 곧바로 모델을 돌리기보다, 큐에 작업을 넣고 백그라운드 워커가 처리한 뒤 상태를 갱신하는 방식이 표준처럼 쓰인다.²

또한 결과를 그대로 실행하는 것도 위험하다. 그래서 시장에서는 제안 → 검토 → 승인 → 실행 흐름이 반복적으로 등장한다. 특히 데이터 변경, 결제, 권한 수정처럼 영향이 큰 작업은 더 그렇다. 자동화는 빠르지만, 승인 없는 자동화는 사고도 빠르다.⁸¹⁰

자동화형은 "완전 자율"보다 "통제된 반자동"이 먼저다

에이전트라는 단어가 멋져 보여서 많은 팀이 처음부터 완전자율을 꿈꾼다. 하지만 실무에서는 반자동이 더 잘 팔린다. 이유는 간단하다. 책임 소재가 분명하고, 품질을 학습시키기 쉽고, 조직이 도입하기 덜 무섭기 때문이다.

예를 들어 고객지원 자동화 도구를 만든다고 해 보자. 첫 단계에서는 문의를 읽고 분류하며, 답변 초안을 만들고, 관련 정책 링크를 붙이는 정도만 해도 충분히 가치가 크다. 그다음 단계에서 상담사가 검토 후 발송하게 하고, 더 나중에 특정 저위험 문의만 자동 발송하게 확장할 수 있다. 이 순서가 중요하다.

자동화형은 보통 이렇게 성장한다.

읽고 설명해 주는 단계
초안과 추천을 내는 단계
승인 후 실행하는 단계
일부 저위험 작업을 자동 실행하는 단계

즉 자동화 도구는 갑자기 로봇이 되는 것이 아니라, 잘 훈련된 인턴에서 시작해 점점 믿을 만한 운영자에 가까워진다.

패턴 5. 수직형 전문가 SaaS: 위 네 패턴을 한 산업 문제에 묶는 방식

이쯤에서 눈치챘을 것이다. 진짜 강한 서비스는 사실 하나의 패턴만 쓰지 않는다. 가장 잘되는 제품은 위 네 가지를 특정 산업 문제에 묶어 버린다.

예를 들어 법률 SaaS라면 계약서 요약, 조항 검색, 위험 포인트 설명, 수정안 초안, 승인 워크플로가 한 제품 안에 이어질 수 있다. 고객지원 SaaS라면 문의 요약, 정책 검색, 답변 코파일럿, 자동 라우팅이 연결될 수 있다. 영업 SaaS라면 통화 요약, CRM 업데이트 제안, 제안서 초안, 후속 일정 생성이 한 덩어리가 된다.

이 수직형 패턴이 강한 이유는 문제와 예산이 선명하기 때문이다. "모든 사람을 위한 AI"보다 "보험 콜센터 후처리 시간을 줄이는 AI"가 덜 화려해 보여도 훨씬 빨리 팔릴 수 있다. ROI를 계산하기 쉽고, 품질 기준도 명확하며, 누가 결제하는지도 분명하기 때문이다.⁷

결국 LLM SaaS의 가장 강한 형태는 범용 모델을 파는 것이 아니라, 특정 직무의 반복 고통을 하나씩 제거하는 직무 운영체제가 되는 것이다.

어떤 패턴을 먼저 선택해야 할까

초기 제품이라면 대개 가장 단순한 패턴에서 시작하는 편이 좋다. 일반적인 순서는 이렇다.

생산성 보조형은 가장 빨리 만들 수 있고, 첫 체험 가치가 빠르다. 지식 검색형은 B2B 신뢰를 붙이기 좋고, 조직 데이터와 결합하기 좋다. 업무 코파일럿형은 기존 SaaS의 업셀에 매우 강하다. 자동화형은 가장 큰 ROI를 만들 수 있지만, 운영 난이도와 책임도 가장 높다.

따라서 질문은 "무엇이 멋진가?"가 아니라 "우리 팀이 지금 감당할 수 있는 신뢰 수준은 어디까지인가?"가 된다.

대체로 이렇게 생각하면 도움이 된다.

아직 고객 문제를 좁히는 중이라면 생산성 보조형
조직 문서와 지식이 핵심 자산이라면 지식 검색형
이미 SaaS 사용 흐름이 있고 붙일 자리가 보인다면 업무 코파일럿형
반복 작업량이 크고 승인 체계를 설계할 수 있다면 자동화형

처음부터 가장 어려운 패턴을 택할 필요는 없다. 오히려 쉬운 패턴에서 반복 사용을 만들고, 그 위에 다음 패턴을 붙이는 식이 훨씬 현실적이다.

잘되는 제품들은 어떻게 진화하는가

시장에서는 제품이 보통 한 번에 완성되지 않는다. 진화 경로가 있다.

가장 흔한 경로는 이렇다. 먼저 요약이나 초안 작성처럼 작은 보조 기능으로 사용량을 모은다. 그다음 조직 문서를 붙여 검색 정확도를 올린다. 이후 화면 안에 코파일럿을 넣어 사용 문맥을 더 깊게 잡는다. 마지막으로 승인형 자동화를 도입해 실제 업무를 굴리기 시작한다.

이 순서가 좋은 이유는 매 단계마다 사용자 신뢰를 쌓을 수 있기 때문이다. 사용자는 AI가 한 번에 모든 것을 대신해 주는 것보다, 점점 더 많은 일을 믿고 맡길 수 있게 되는 과정을 더 편하게 받아들인다. 제품팀 입장에서도 로그, 피드백, 실패 케이스가 누적되어 품질 개선이 쉬워진다.⁷⁹

한마디로, 성공한 LLM SaaS는 대개 "챗봇 출시"가 아니라 "보조 기능에서 운영 도구로 진화"하는 과정을 밟는다.

반대로 잘 안 되는 패턴도 있다

대표적인 실패 패턴도 몇 가지 있다.

첫째, 범용 채팅창만 있는 제품이다. 무엇이든 물어보라고 하지만, 실제로는 사용자의 맥락도 모르고, 데이터도 없고, 다음 행동도 연결되지 않는다. 이런 제품은 처음엔 재밌어도 습관이 되기 어렵다.

둘째, AI 호출이 핵심 가치 전체를 떠받치는 구조다. LLM 응답이 느리거나 실패하면 제품 가치가 즉시 무너진다. 그래서 실무에서는 AI를 핵심 기능의 강화층으로 두고, 실패 시에도 기본 흐름은 유지되게 설계하라는 조언이 반복된다.²

셋째, 자동화는 해 놓고 승인과 로그가 없는 경우다. 이것은 제품이 아니라 사고 예약 버튼에 가깝다. 특히 B2B에서는 누가 어떤 문맥으로 어떤 작업을 실행했는지 추적할 수 있어야 도입이 가능하다.⁸¹⁰

넷째, 출처 없는 답변형 지식 검색이다. 특히 문서 기반 제품에서 근거를 안 보여 주면 사용자는 몇 번 실수 이후 바로 떠난다.³

이 실패 패턴들은 모두 공통점이 있다. 모델은 있는데 제품 구조가 없다는 것이다.

결국 어떤 패턴이 가장 돈이 되는가

정답은 하나가 아니다. 하지만 원칙은 있다.

개인 사용자 시장에서는 생산성 보조형이 빠르게 퍼지기 쉽다. 체험 가치가 즉각적이기 때문이다. 팀과 조직 시장에서는 지식 검색형과 코파일럿형이 더 강하다. 기존 데이터와 협업 흐름에 붙기 때문이다. 큰 계약과 높은 전환은 자동화형과 수직형 전문가 SaaS에서 잘 나온다. 업무 시간을 직접 줄이고 책임 구조 안에 들어가기 때문이다.

즉 "가장 멋진 패턴"보다 "가장 예산에 가까운 패턴"이 중요하다. 돈은 보통 놀라움보다 반복성과 책임 절감에서 나온다.

이 장의 핵심 정리

LLM SaaS에서 성공 확률을 높이려면, 새로움을 과장하기보다 검증된 제품 패턴을 먼저 이해해야 한다. 시장에서 반복적으로 먹히는 형태는 크게 네 가지다. 빠른 가치 체험을 주는 생산성 보조형, 조직 지식을 답으로 바꾸는 지식 검색형, 기존 SaaS에 지능을 심는 업무 코파일럿형, 반복 업무를 굴리는 자동화 오퍼레이터형이다. 그리고 실제로 강한 서비스는 이 패턴들을 특정 산업 문제에 묶어 수직형 제품으로 발전한다.

중요한 것은 패턴을 베끼는 것이 아니다. 패턴이 왜 반복적으로 통하는지를 이해하는 것이다. 어떤 입력이 들어오고, 어떤 순간에 가치가 보이고, 어디서 신뢰가 생기고, 누가 예산을 집행하는지까지 읽어야 한다.

새로운 기술일수록 사람들은 자꾸 완전히 새로운 제품을 만들고 싶어 한다. 하지만 실전에서는 오히려 이미 검증된 문제 구조 위에 설계한 제품이 더 빨리 살아남는다. LLM 시대에도 결국 잘되는 서비스는 비슷하다.

사람들이 이미 자주 힘들어하는 일을, 더 빠르고, 더 믿을 만하고, 더 자연스럽게 끝내 주는 제품.

그 구조를 이해한 팀이, 생각보다 덜 화려해 보이지만 훨씬 더 잘 파는 제품을 만든다.