AI 네이티브 헬스케어 기업을 만드는 방법 — Dan Feng, Maven Clinic

원문 제목: How to build an AI-Native Health Company — Dan Feng, Maven Clinic 원문 URL: https://www.youtube.com/watch?v=WJRdLNhrsLQ 채널: AI Engineer (aiDotEngineer) 영상 업로드일: 2026-08-19 처리일: 2026-08-20 발표자: Dan Feng, Maven Clinic 영상 길이: 17분 18초 자막: YouTube 자동 생성 영어 자막 기반

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 네이티브 기업은 AI 도구를 도입한 조직이 아니라, 내부 업무·제품·조직문화·개발 프로세스·신뢰성 설계를 AI의 실행 속도와 불확실성에 맞게 다시 만든 조직이다.==

• 내부에서는 사람이 직접 하거나 다른 사람에게 위임하던 일을 먼저 AI로 해결한다.
• 외부 제품에는 사용자 경험을 개선하고 운영비를 줄이는 AI 기능을 넣는다.
• 채용·평가·계획·코드 리뷰·품질 관리까지 AI가 바꾼 비용 구조와 역할 경계를 반영한다.
• 환각(Hallucination)을 0으로 만들려 하기보다 실패 허용도에 따라 검증 강도와 인간 이관 경로를 설계한다.

Maven Clinic은 여성과 가족을 위한 디지털 헬스 플랫폼으로서 약 2년 전 AI 여정을 시작했고, 전 제품을 가로지르는 오케스트레이션 계층인 Maven Intelligence를 구축했다. 핵심 변화는 단일 모델을 도입하는 데 있지 않다. 낮은 위험의 업무부터 신뢰를 쌓고, 다수의 구성원이 쉽게 사용할 인프라를 제공하며, 짧은 주기의 실행과 반복을 조직의 기본 운영 방식으로 만드는 데 있다.

1. Maven Clinic의 출발점과 AI 네이티브의 정의

1.1. 여성과 가족을 위한 디지털 헬스 플랫폼

1. 사업 영역

   1. Maven Clinic은 여성과 가족에 초점을 둔 대형 디지털 헬스 플랫폼이다.
   2. 전문 영역은 임신·출산(maternity), 난임·생식 건강(fertility), 육아(parenting), 폐경(menopause)이다.
   3. 따라서 고객 지원, 예약, 보험·환급 청구처럼 건강과 비용에 직접 영향을 주는 업무가 제품 안에 함께 존재한다.

2. AI 여정의 시작

   1. AI를 본격적으로 도입한 시점은 발표 시점으로부터 약 2년 전이다.
   2. 그 과정에서 Maven Intelligence라는 공통 오케스트레이션 계층(orchestration layer)을 만들었다.
   3. 이 계층은 개별 기능 하나에만 붙은 모델이 아니라 Maven의 모든 제품을 가로질러 AI를 연결한다.
   4. 목표 사용자는 엔지니어만이 아니다. 회사의 모든 구성원과 고객이 AI의 혜택을 받을 수 있도록 공통 기반을 제공한다.

1.2. 도입은 선택이 아니라 생존을 위한 역량

1. 경쟁 환경의 변화

   1. AI는 이미 사용 가능하고 매일 개선되고 있다.
   2. 한 조직이 도입하지 않기로 선택해도 경쟁사는 도입할 수 있으므로, 미도입은 중립적인 선택이 아니다.

2. 트랙터 비유

   1. 트랙터는 농부를 대체하기 위해 만들어진 것이 아니다.
   2. 그러나 트랙터를 운전할 수 있는 농부가 운전하지 못하는 농부를 대체하게 된다.
   3. 조직의 목표는 AI 때문에 대체될지 걱정하는 데 머무는 것이 아니라, AI라는 트랙터를 운전할 수 있는 사람이 되는 것이다.

1.3. AI 네이티브에는 단일 공식이 없다

1. 정의의 부재

   1. AI 네이티브(AI-native)를 설명하는 하나의 정답이나 단일 정의는 없다.
   2. 따라 하기만 하면 어느 순간 AI 네이티브가 되는 사전 제작 플레이북(predefined playbook)도 없다.
   3. 기업마다 제품, 위험도, 고객, 규제, 기존 운영 방식이 다르므로 전환 경로도 달라진다.

2. Maven이 사용하는 세 가지 축

   1. 내부 업무에 AI를 적용한다.
   2. 외부 제품 안에 AI를 넣는다.
   3. 문화·프로세스·일하는 방식을 AI가 제공하는 가능성에 맞게 바꾼다.

2. AI 네이티브를 만드는 세 가지 축

2.1. 첫 번째 축: 내부 업무를 AI 우선으로 재설계하기

1. 직접 수행하는 반복 업무

   1. 매일의 요약(daily summary) 작성은 AI가 처리할 수 있는 가장 단순한 사례다.
   2. 회의 관리(meeting management)와 후속 조치 정리도 AI 적용 대상이다.
   3. Jira 작업(Jira task) 생성처럼 지금 사람이 수동으로 하는 모든 업무는 AI로 수행할 수 있는지 먼저 질문해야 한다.

2. 위임하기 전의 질문

   1. 다른 사람에게 일을 부탁하려는 순간에도 “이 업무를 AI로 처리할 수 있는가?”를 자신에게 물어야 한다.
   2. Maven의 여러 리더, 영업 조직을 포함한 구성원들은 예전처럼 이런 작업을 다른 사람에게 넘기기보다 AI 도구로 직접 해결하기 시작했다.
   3. AI는 단순히 개인의 생산성을 올리는 도구가 아니라, 위임에 필요한 조정 비용을 없애고 리더가 직접 실행하게 하는 수단이 된다.

2.2. 두 번째 축: 제품 안에 AI를 넣어 사용자 가치와 운영 효율을 함께 높이기

1. 사용자 경험 개선

   1. 제품에 AI를 넣는 첫 번째 목표는 사용자 경험(user experience)을 개선하는 것이다.
   2. 고객이 도움을 요청했을 때 사람이 근무하는 시간까지 기다리지 않고 즉시 답을 얻도록 만들 수 있다.

2. 운영비 절감

   1. 두 번째 목표는 운영 비용(operational cost)을 줄이는 것이다.
   2. AI 기반 챗봇은 24시간 이용 가능하고, 고객의 문제를 즉시 다룰 수 있다.
   3. 적절한 범위에서는 사람 상담원보다 빠르고 저렴한 지원을 제공할 수 있다.
   4. 다만 헬스케어처럼 실패 비용이 기능별로 다른 분야에서는 모든 업무를 같은 자동화 수준으로 처리해서는 안 된다.

2.3. 세 번째 축: 문화와 프로세스를 실행 속도에 맞게 바꾸기

1. 기술 도입만으로는 부족함

   1. 모델과 도구를 사서 제공하는 것만으로는 AI 네이티브 조직이 되지 않는다.
   2. 사람들이 어떤 일을 하고, 누구에게 위임하고, 무엇을 문서화하며, 어떤 기준으로 출시하는지까지 바꿔야 한다.

2. 변화의 범위

   1. 채용 기준은 AI를 학습하고 활용하는 역량을 반영해야 한다.
   2. 성과 평가는 AI를 활용해 개인과 팀의 영향력을 얼마나 확장했는지 반영해야 한다.
   3. 계획 수립은 먼 미래의 상세한 확정안보다 짧은 실행 주기와 반복을 중심으로 바뀌어야 한다.
   4. 개발과 출시 과정은 생성 속도가 빨라진 만큼 리뷰·테스트·운영 모니터링을 함께 재설계해야 한다.

3. 구성원 집단별 AI 확산 전략

3.1. 얼리 어답터: 도구를 열고 지식을 확산시키기

1. 필요한 지원

   1. 얼리 어답터(early adopter)는 새로운 도구를 스스로 찾아 빠르게 사용하므로 많은 강제 교육이 필요하지 않다.
   2. 조직이 해야 할 일은 필요한 도구를 활성화하고, 안전하게 사용할 수 있는 기반을 제공하는 것이다.

2. 조직 전체로의 전파

   1. 얼리 어답터가 먼저 얻은 학습을 회사와 공유하도록 독려해야 한다.
   2. 개인의 실험이 개인의 생산성 향상으로 끝나지 않고 팀의 표준과 재사용 가능한 지식으로 전환되어야 한다.

3.2. 다수의 중간층: 공통 인프라와 마찰 없는 사용성

1. 가장 중요한 대상

   1. 대다수 구성원은 얼리 어답터도 아니고 완강한 지연자도 아닌 중간층이다.
   2. 실제 전사 확산의 성패는 소수의 열성 사용자가 아니라 이 다수 집단이 얼마나 쉽게 시작하느냐에 달려 있다.

2. 지원 방식

   1. 조직 차원의 공유 AI 인프라(shared AI infrastructure)를 만들어야 한다.
   2. 도구를 쉽게 사용할 수 있도록 인터페이스와 기본 설정을 단순하게 만들어야 한다.
   3. 도입 과정이 최대한 자연스럽고(seamless), 별도의 큰 결심이나 복잡한 설정을 요구하지 않게 해야 한다.
   4. 사용자의 피드백을 지속적으로 듣고 입력받아 도구와 정책을 고쳐야 한다.

3. 도구 선택은 사용자의 현재 위치를 따라가야 함

   1. Maven에서는 전년도에 많은 구성원이 Cursor를 사용했다.
   2. 다음 해에는 많은 구성원이 Claude Code로 전환했다.
   3. 조직이 특정 도구 하나만 표준으로 강요하면 실제 사용자의 흐름을 끊게 된다.
   4. Cursor와 Claude Code를 모두 지원하고, 구성원이 현재 편하게 쓰는 곳에서 출발하게 해야 한다.

3.3. 느린 어답터: 우려를 이해하되 방향은 분명히 제시하기

1. 저항의 원인 다루기

   1. 새로운 기술을 늦게 받아들이는 사람들은 걱정과 우려가 있다.
   2. 이들을 무시하거나 단순히 사용을 강제하기보다 현재 위치에서 만나야 한다.
   3. 무엇을 걱정하는지 구체적으로 이해하고, 필요한 지원을 제공해야 한다.

2. 조직의 방향성

   1. 공감과 지원이 방향성의 모호함을 뜻하지는 않는다.
   2. 회사가 어디로 향하고 있는지, AI를 업무에 어떻게 반영할 것인지, 기대되는 변화가 무엇인지 명확하고 단호하게 설명해야 한다.
   3. 구성원은 현재 속도가 느릴 수 있지만 조직의 장기 방향을 오해해서는 안 된다.

4. 채용과 보상: 구현자보다 문제 해결자에 가까워지기

4.1. AI가 실행 비용을 낮추면서 역할 구조가 바뀐다

1. 전통적인 위임 모델

   1. 과거에는 시니어 엔지니어가 문제를 감지하고 해결책을 만든 뒤, 구현 작업을 다른 엔지니어에게 위임했다.
   2. 여러 사람이 병렬로 작업하면 더 빠르게 완료할 수 있다는 논리였다.

2. AI 시대의 직접 실행

   1. AI를 활용하는 엔지니어는 문제를 이해하고 해결책을 떠올린 즉시 구현까지 직접 처리할 수 있다.
   2. 이미 해결 방법을 알고 있는데 구현만 다른 사람에게 넘기면 설명·대기·조정이라는 오버헤드가 생긴다.
   3. 신입이나 다른 구성원에게 구현을 위임하면 오히려 전체 효율이 낮아질 수 있다.
   4. 새로운 구성원도 문제를 독립적으로 해결할 수 있어야 하므로, 단순 구현 위임에만 의존하는 기술 리드 방식은 지속하기 어렵다.

4.2. 채용 기준: AI에 대한 진짜 관심과 학습 속도

1. 지속적으로 배우는 사람

   1. AI 영역은 매우 빠르게 움직이므로, 현재 알고 있는 도구의 숙련도보다 계속 배우려는 태도가 중요하다.
   2. AI에 진정으로 관심이 있고 새로운 변화에 스스로 따라가는 사람을 찾아야 한다.

2. 팀을 올바른 방향으로 이끄는 사람

   1. 채용 대상은 개인적으로 AI를 쓰는 사람에 그치지 않는다.
   2. 팀이 변화의 흐름을 놓치지 않도록 돕고, 새로운 활용법을 전파할 수 있어야 한다.

4.3. 엔지니어와 PM의 경계, 그리고 제품 감각

1. 역할 경계의 흐려짐

   1. AI를 사용하면 엔지니어가 과거보다 훨씬 많은 일을 할 수 있다.
   2. 그 결과 제품 관리자(PM)와 엔지니어 사이의 전통적인 경계가 흐려진다.

2. 제품을 이해하는 엔지니어의 가치

   1. 제품을 깊이 이해하는 엔지니어는 소프트웨어 구현에만 집중하는 전통적인 엔지니어보다 훨씬 크게 기여할 수 있다.
   2. 시스템을 깊이 이해하는 능력이 중요하다.
   3. 복잡하고 모호한 문제(complicated, ambiguous problem)를 다룰 수 있는 능력도 핵심 가치가 된다.
   4. AI가 구현 작업을 빠르게 처리할수록 사람의 차별점은 문제 정의, 제품 판단, 시스템 맥락, 모호성 해소로 이동한다.

4.4. 성과 평가: AI로 영향력을 배수화한 정도를 보상하기

1. 평가 질문의 변화

   1. Maven은 성과 리뷰(performance review)에서 “AI 측면에서 무엇을 했는가?”를 묻기 시작했다.
   2. 단순히 AI 도구를 사용했는지가 아니라, AI를 활용해 어떤 결과를 만들었는지를 확인한다.

2. 보상의 기준

   1. AI를 활용해 자신의 영향력(impact)을 여러 배로 늘린 사람에게 보상해야 한다.
   2. 이 원칙은 엔지니어에게만 적용되지 않고 회사의 모든 구성원에게 적용된다.

5. 계획과 실행: 1년의 꿈, 2~4주의 배포

5.1. 과거의 순차적 개발 방식이 가진 한계

1. 긴 사전 설계

   1. 과거에는 사업 요구사항을 구체화하는 데 몇 주, 때로는 몇 달을 썼다.
   2. 요구사항을 확정하고 디자인을 마친 뒤 구현에 들어갔다.

2. 구현 비용을 전제로 한 안전장치

   1. 구현 비용이 높기 때문에 시작 단계에서 잘못 결정하면 나중에 수정하는 비용이 매우 커진다고 생각했다.
   2. 그래서 구현 전에 가능한 한 완벽하게 요구사항과 설계를 고정하려 했다.
   3. 그러나 대규모 프로젝트에서는 시작 시점에 모든 것을 정확히 알 수 없고, 실제로 초기에 완벽한 판단을 내리는 경우도 드물다.

5.2. AI가 바꾼 비용 구조와 반복의 가치

1. 빠른 구축

   1. AI를 활용하면 무언가를 만드는 데 걸리는 시간이 크게 줄어들고, 간단한 프로토타입은 몇 분 안에도 만들 수 있다.
   2. 구현과 수정의 비용이 낮아지므로, 먼 미래의 요구사항을 완벽하게 확정할 이유가 약해진다.

2. 빠른 전달을 중심에 놓기

   1. 중요한 질문은 “어떻게 모든 것을 미리 맞힐까?”가 아니라 “무엇을 가장 빠르게 전달하고 검증할까?”가 된다.
   2. 계획과 구현을 분리해 긴 시간을 기다리기보다, 작게 만들고 실제 결과를 보고 다음 결정을 내려야 한다.

5.3. 1년 계획은 방향, 2~4주 계획은 실행

1. 장기 상상

   1. 1년 뒤 만들고 싶은 것을 크게 상상하는 일은 여전히 유효하다.
   2. 1년 뒤에는 AI 모델이 원하는 일을 무엇이든 할 수 있다고 가정하고, 지금보다 훨씬 큰 목표를 그릴 수 있다.
   3. 다만 1년 계획은 영감을 주고 방향을 정하는 용도이지, 세부 실행 약속이 아니다.

2. 단기 배포

   1. 실제로 집중해야 하는 것은 다음 2~4주 동안 무엇을 전달할지다.
   2. PM과 디자이너는 현재 스프린트에서 무엇을 만들어야 하는지 엔지니어에게 알려준다.
   3. 엔지니어는 스프린트 종료 시점, 가능하면 그보다 빨리 결과물을 출시한다.
   4. 그동안 PM은 다음 요구사항을 구체화할 시간을 확보한다.
   5. 2주 전 결정이 틀렸다는 사실을 발견해도 괜찮다. 빠르게 방향을 바꾸고 수정하면 된다.

5.4. 문서는 통신 수단으로 짧게, 중기 계획은 유연하게

1. PRD와 TDD의 간결화

   1. 수십 쪽의 PRD(Product Requirements Document)나 TDD(Technical Design Document)를 미리 작성하는 방식은 선호하지 않는다.
   2. 한두 쪽의 짧은 문서로 핵심 의도와 제약을 전달하고, 구현을 통해 계속 반복하는 편이 낫다.
   3. 문서의 목적은 영구적인 계약서가 아니라 팀이 대화하고 수정하기 위한 커뮤니케이션이다.

2. 3~6개월 계획의 어려움

   1. 3개월이나 6개월짜리 중기 계획은 AI 시대에 특히 예측하기 어렵다.
   2. 어떤 모델이 3개월 뒤 무엇을 할 수 있을지 알 수 없고, 그 사이 여러 번의 모델 릴리스가 나올 수도 있다.
   3. 따라서 이 구간의 상세 계획을 지나치게 고정하지 않는다.
   4. 분기 또는 6개월 단위 계획에 익숙한 사람에게는 불편하지만, 새로운 AI 시대에 효율적으로 일하는 방법을 배우는 것이 조직의 역할이다.

6. AI 코딩과 소프트웨어 개발의 전환

6.1. 낮은 위험에서 시작해 신뢰를 쌓기

1. AI 코딩 도구의 현재 위치

   1. AI 코딩 도구는 가장 성공적인 AI 활용 사례 중 하나다.
   2. 특히 구현(implementation)을 빠르게 수행하는 데 강하다.
   3. 휴대전화로 소프트웨어를 구현하고 개발의 모든 단계를 자동화한다는 사례도 있지만, 모든 사람이 그 수준까지 갈 필요는 없다.

2. Maven의 단계적 도입

   1. 처음에는 단위 테스트(unit test) 작성과 문서화처럼 위험이 낮은 작업부터 시작했다.
   2. 결과를 쉽게 검증할 수 있고 잘못되어도 피해가 작기 때문에 신뢰를 쌓기에 적합하다.
   3. 작은 성공을 반복하면서 각 팀의 규칙, 스킬, 안전장치(barrier)를 만들었다.

3. 전면 적용으로의 이동

   1. 충분한 경험과 안전 기준이 생긴 뒤 엔지니어링 팀 전체에 모든 작업에서 AI 코딩 도구를 사용하도록 확장했다.
   2. 누군가 사용하지 않는다면 단순히 강제하는 대신 왜 사용하지 않는지 확인한다.
   3. 현재는 구현 작업 대부분을 AI 코딩 도구가 수행한다.
   4. 엔지니어의 중심 업무는 코드 작성에서 코드 리뷰, 아키텍처 설계(architecture), 평가(evaluation)로 이동했다.

6.2. 코드 생산량 증가와 리뷰 병목

1. 생산량의 급증

   1. 과거의 좋은 엔지니어가 하루 수백 줄을 작성했다면, AI를 활용하는 현재는 쉽게 수천 줄을 만들 수 있다.
   2. 과거와 같은 방식으로 모든 코드를 사람이 검토하면 증가한 생산량을 따라갈 수 없다.

2. AI 리뷰 도구의 현재 한계

   1. 여러 AI 코드 리뷰 도구를 시험했고, 검토 부담을 줄이는 데 어느 정도 도움을 받았다.
   2. 그러나 그 결과를 100% 신뢰할 수 있는 수준은 아니다.
   3. 엔지니어가 제공하는 맥락과 판단은 여전히 매우 가치 있으므로, 사람의 리뷰를 전부 자동화했다고 가정할 수 없다.

6.3. 코드 리뷰의 새로운 운영 규칙

1. 리뷰 필요성의 자기 판단

   1. 엔지니어가 해당 PR(Pull Request)에 코드 리뷰가 필요한지 스스로 판단할 수 있게 했다.
   2. PR이 충분히 단순하고 작성자가 결과를 매우 확신한다면 다른 사람의 리뷰 없이 병합할 수 있다.
   3. 자율성을 허용하되 결과에 대한 책임(accountability)은 작성자에게 남긴다.

2. 리뷰 가능한 크기 유지

   1. 리뷰를 요청할 때는 모범 사례를 지켜야 한다.
   2. 한 PR은 500줄을 넘기지 않도록 한다.
   3. 수천 줄짜리 변경은 사람이 의미 있게 검토하기 어렵고, 형식적인 승인만 남길 위험이 크다.

3. 스택 PR(Stacked PR)

   1. 큰 기능은 여러 개의 작은 PR로 쪼갠다.
   2. 일부를 리뷰받는 동안 다음 작업을 계속 진행할 수 있다.
   3. 변경 단위를 줄이면 리뷰어가 실제로 이해하고 피드백할 수 있는 가능성이 높아진다.

4. 러버 스탬프(rubber stamp) 금지

   1. 러버 스탬프는 코드를 실질적으로 검토하지 않고 맹목적으로 승인하는 행위다.
   2. 이것은 리뷰했다는 거짓 확신을 제공하므로 가장 피해야 한다.
   3. AI가 작성한 코드가 많아질수록 리뷰의 숫자를 늘리는 것보다 의미 있는 검토를 보존하는 것이 중요하다.
   4. AI 코드 리뷰 도구는 앞으로도 계속 개선해야 하며, 장기적으로는 중요한 역할을 맡게 될 가능성이 크다.

6.4. 목표: 설계부터 운영 수정까지 이어지는 자동화

1. 전체 생명주기 자동화

   1. 현재 AI 도구는 소프트웨어 개발 각 단계를 지원한다.
   2. 장기 목표는 설계, 구현, 출시를 처음부터 끝까지 자동화하는 것이다.

2. 운영 단계의 자율성

   1. 출시 후 실시간 트래픽을 AI 도구가 관찰해야 한다.
   2. 문제가 커지기 전에 조기에 포착하고, 가능한 경우 자동으로 수정해야 한다.
   3. 이 목표는 아직 완성되지 않았고 계속 개발 중인 영역이다.

7. 생성형 AI 신뢰성: 환각을 없애는 대신 위험을 설계하기

7.1. 전통적 소프트웨어와 생성형 시스템의 차이

1. 결정론적 소프트웨어

   1. 전통적인 소프트웨어는 구현한 규칙대로, 그 이상도 이하도 하지 않는다.
   2. 같은 입력과 조건에서는 예측 가능한 결과를 기대할 수 있다.

2. 생성형 AI의 환각

   1. 생성형 AI 솔루션에는 환각이 존재하며 이를 무시할 수 없다.
   2. 환각을 완전히 제거하려는 시도는 매우 비쌀 수 있다.
   3. 모든 기능에서 완전 제거가 필요한 것도 아니므로, 기능의 실패 결과와 비용을 기준으로 접근해야 한다.

7.2. 실패 허용도에 따른 위험 분류

1. 처음부터 실패 유형을 나누기

   1. 시스템을 만든 뒤 문제가 생길 때까지 기다리지 말고, 설계 초기에 어떤 실패가 허용되고 어떤 실패가 허용되지 않는지 정해야 한다.
   2. 허용 가능한 실패에는 간단한 재시도 경로를 제공할 수 있다.
   3. 허용할 수 없는 실패에는 다중 검증과 사람의 개입을 붙여야 한다.

2. 예약 지원 사례

   1. 예약 일정 조정 기능이 1,000번 중 한 번 실패하는 것은 좋은 경험은 아니지만 허용 가능할 수 있다.
   2. 사용자가 버튼을 다시 누르면 시스템이 예약을 재시도할 수 있기 때문이다.
   3. 이 경우 실패율을 낮추는 노력과 즉시 재시도 경로를 함께 비교해 적정한 투자 수준을 정할 수 있다.

3. 환급 청구 사례

   1. 환급 청구(reimbursement claim)는 실패를 허용할 수 없는 기능이다.
   2. 고객이 200달러를 청구했는데 50달러를 지급하거나, 50달러를 청구했는데 200달러를 지급하면 어느 경우든 즉시 문제 제기와 에스컬레이션이 발생한다.
   3. 금액이 틀리는 것은 단순히 버튼을 한 번 더 누르면 해결되는 종류의 오류가 아니다.

7.3. 고위험 업무의 다중 모델 검증과 인간 이관

1. 서로 다른 모델로 같은 영수증 검토

   1. 환급 청구의 영수증을 받으면 여러 다른 모델로 같은 영수증을 검토한다.
   2. 모델별 결과가 서로 일치할 때만 다음 단계로 진행한다.
   3. 모델 간 결과가 일치하지 않으면 어느 결과가 맞는지 억지로 선택하지 않는다.

2. 불확실성을 고객에게 투명하게 전달

   1. 시스템이 처리를 확신할 수 없다면 고객에게 처리에 어려움이 있다고 알린다.
   2. 사람 상담원과 연결해 처리할지 선택하게 한다.
   3. 자동화율을 높이는 것보다 잘못된 금액을 지급하지 않는 것이 중요하므로, 인간에게 넘기는 것은 실패가 아니라 허용된 안전 해법이다.

7.4. 출시 전 반복 테스트와 출시 후 지속 평가

1. 통합 테스트(integration test) 확대

   1. Maven은 알려진 사용 사례를 거의 모두 포괄하는 수백 개의 통합 테스트를 운영한다.
   2. 새로운 사례가 발견될 때마다 테스트 스위트에 계속 추가한다.

2. 한 번의 통과로 충분하지 않음

   1. LLM은 같은 테스트에서도 서로 다른 결과를 만들 수 있다.
   2. 따라서 각 테스트 케이스를 여러 번 반복 실행해야 한다.
   3. 한 번 통과했는지가 아니라 지속적으로 높은 통과율을 보이는지가 중요하다.
   4. 예시 기준으로 모든 실행에서 약 90%의 높은 통과율을 요구한다.

3. Auto-evolve 시스템

   1. 출시 후에는 auto-evolve 시스템이 각 고객 대화를 평가한다.
   2. 무엇이 좋은 대화이고 무엇이 나쁜 대화인지 미리 정의한 많은 평가 기준(rubric)을 둔다.
   3. 시스템은 그 기준에 따른 결과와 점수를 생성하고, 팀은 점수를 검토한다.

4. 전담 검토 그룹

   1. 별도의 전담 그룹이 대화를 직접 검토한다.
   2. 표본을 확인하면서 시스템을 개선해야 하는지, 평가 기준이 너무 엄격하거나 느슨한지 판단한다.
   3. 시스템과 rubric을 한 번 정하고 끝내지 않고 계속 보정한다.

5. 새 기능의 표본 확대

   1. 새 기능을 출시할 때는 소수의 표본만 확인하는 방식으로 부족할 수 있다.
   2. 그 경우 대화의 약 20%를 직접 검토하는 수준까지 올릴 수 있다.
   3. 환각의 존재를 인정하되, 출시 때마다 결과에 자신감을 가질 수 있는 검증량을 확보하는 방식이다.

주요 발언 모음

“트랙터는 농부를 대체하기 위한 것이 아니지만, 트랙터를 운전할 수 있는 농부가 운전하지 못하는 농부를 대체한다.”

“AI 네이티브가 된다는 의미에 하나의 정의가 있는 것은 아니며, 따라 하기만 하면 되는 사전 제작 플레이북도 없다.”

“다른 사람에게 무언가를 해달라고 부탁하려는 순간, AI로 할 수 있는지 자신에게 물어야 한다.”

“구현 작업을 AI가 맡게 되면 엔지니어는 리뷰, 아키텍처 설계, 평가에 더 집중한다.”

“러버 스탬프는 우리가 검토했다고 생각하게 만들지만, 실제로는 잘못된 확신만 준다.”

“환급 청구에서 모델들이 합의하지 못한다면 고객을 사람 상담원에게 연결하는 것이 받아들일 수 있는 해법이다.”

핵심 데이터 & 수치

• 약 2년: Maven Clinic이 AI 여정을 시작한 기간.
• 24시간/7일: AI 챗봇이 제공할 수 있는 상시 고객 지원.
• 1년: 모델이 무엇이든 할 수 있다고 가정하며 크게 상상하는 장기 방향의 시간 범위.
• 2~4주: 실제로 집중해 결과물을 전달하는 단기 실행 범위.
• 1~2쪽: 요구사항·설계 문서를 커뮤니케이션 용도로 유지하려는 권장 분량.
• 3~6개월: 모델 발전 속도를 예측하기 어려워 상세 계획을 고정하기 힘든 중기 범위.
• 500줄 이하: 의미 있는 코드 리뷰를 위해 권장하는 PR 크기.
• 1/1,000: 예약 실패처럼 재시도로 회복할 수 있어 상대적으로 허용 가능한 예시 오류율.
• 수백 개: 알려진 사용 사례를 다루기 위해 운영하는 통합 테스트 규모.
• 약 90%: 비결정적인 LLM 테스트에서 지속적으로 요구하는 예시 통과율.
• 약 20%: 새 기능 출시 때 직접 검토를 확대할 수 있는 대화 표본 비율.

핵심 요약 (20줄)

1. Maven Clinic은 여성과 가족을 위한 디지털 헬스 플랫폼으로 임신·출산, 난임, 육아, 폐경 영역을 다룬다.
2. 약 2년의 AI 여정 끝에 모든 제품을 가로지르는 AI 오케스트레이션 계층 Maven Intelligence를 구축했다.
3. AI 네이티브 조직은 내부 업무, 외부 제품, 문화와 프로세스를 동시에 AI 중심으로 재설계한다.
4. 매일의 요약, 회의 관리, Jira 작업 생성처럼 사람이 하거나 위임하던 일은 AI로 처리할 수 있는지 먼저 확인한다.
5. 제품 속 AI는 사용자 경험을 높이고 24시간 고객 지원과 운영 비용 절감을 가능하게 한다.
6. 얼리 어답터에게는 도구와 공유 기회를 제공하고, 다수의 중간층에게는 공통 인프라와 쉬운 사용성을 제공한다.
7. 느린 어답터의 우려를 이해하면서도 회사가 향하는 AI 전환의 방향은 명확하게 알려야 한다.
8. AI가 구현 비용을 낮추면서 시니어 엔지니어가 구현을 위임하던 전통적인 구조가 바뀐다.
9. 채용에서는 AI에 진심으로 관심을 갖고 빠르게 배우며 팀의 방향을 이끌 사람을 찾는다.
10. 제품을 깊이 이해하고 복잡하고 모호한 문제를 다루는 엔지니어의 가치가 커진다.
11. 성과 리뷰에서는 AI로 자신의 영향력을 얼마나 배수화했는지를 묻고 그 결과를 보상한다.
12. 1년 목표는 AI의 발전을 전제로 크게 상상하되 방향과 영감을 제공하는 용도로 사용한다.
13. 실제 실행은 다음 2~4주에 집중하고, 틀린 결정은 빠르게 방향을 바꿔 수정한다.
14. 긴 PRD와 TDD 대신 한두 쪽 문서로 의도와 제약을 공유하고 구현을 통해 반복한다.
15. AI 코딩 도입은 단위 테스트와 문서화처럼 검증하기 쉬운 낮은 위험 업무에서 시작한다.
16. AI가 구현을 맡으면 엔지니어는 코드 리뷰, 아키텍처, 평가에 집중하며 리뷰 단위는 500줄 이하로 유지한다.
17. 큰 기능은 스택 PR로 쪼개고, 아무도 읽지 않은 채 승인하는 러버 스탬프를 피해야 한다.
18. 생성형 AI 환각은 기능별 실패 허용도를 정해 재시도, 다중 모델 검증, 인간 이관으로 다룬다.
19. 수백 개 통합 테스트를 여러 번 실행하고 약 90%의 지속 통과율을 요구하며 출시 후 대화도 평가한다.
20. 새 기능은 필요할 때 대화의 약 20%를 직접 검토해 시스템과 평가 기준을 계속 개선한다.

결론 및 시사점

1. AI 전환의 단위는 모델이 아니라 운영 시스템이다: 모델을 추가하는 것보다 사람·도구·프로세스·평가가 서로 맞물리게 만드는 일이 중요하다.
2. 도입 순서는 위험도에 따라 설계한다: 검증이 쉽고 실패 비용이 낮은 업무에서 시작해 신뢰와 안전 기준을 확보한 뒤 고위험 업무로 넓힌다.
3. 조직의 희소 자원은 구현 시간이 아니라 판단력이다: AI가 코드를 빠르게 만들수록 제품 이해, 시스템 설계, 문제 정의, 모호성 처리와 같은 인간의 판단이 더 중요해진다.
4. 계획은 장기 방향과 단기 배포로 분리한다: 1년의 상상은 크게 잡고, 실제 약속은 2~4주 단위로 작게 잡아 틀린 가정을 빨리 버린다.
5. 자동화에는 항상 실패 경로를 포함한다: 환각을 무조건 제거하는 대신 허용 가능한 오류와 금지해야 할 오류를 구분하고, 다중 검증과 인간 이관을 설계에 내장한다.
6. AI 네이티브의 완성은 아직 진행형이다: 설계부터 운영 모니터링과 자동 수정까지 전 과정을 자동화하는 목표를 향해, 실제 결과와 평가 데이터를 바탕으로 계속 진화해야 한다.