도메인 전문성을 AI 제품에 녹여내는 법 - Chris Lovejoy
📺 원본 영상: How to Leverage Domain Expertise — Chris Lovejoy, Notius Labs 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-05-17 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 강연은 버티컬 AI(Vertical AI) 분야에서 도메인 전문성을 어떻게 조직 구조 속에 녹여낼 것인가를 다룬다. 발표자인 Chris Lovejoy는 의대 출신으로 NHS 임상의를 거쳐 여러 의료 AI 스타트업에서 일한 경험을 바탕으로, 도메인 전문가를 조직에 통합하는 세 가지 모델 — Oracle(오라클), Evaluator(평가자), Architect(설계자) — 을 제시한다. 이 프레임워크는 추상적인 이론이 아니라 Granola, Tandem, Anterior 세 회사의 구체적인 사례로 뒷받침된다.
왜 버티컬 AI는 조직 문제인가
Gartner에 따르면 지난해 생성형 AI 프로젝트의 약 50%가 중도 폐기되었다고 한다. Chris Lovejoy는 이 실패의 핵심 원인이 모델의 성능 부족이 아니라고 단언한다. 그의 진단은 명확하다. “프론티어 모델은 이미 충분히 좋다. 문제는 조직이 그 주변의 전문가적 판단을 어떻게 운용하느냐다.” 즉, 기술적 우위보다 조직적 우위가 버티컬 AI 경쟁의 판도를 가른다는 것이다.
버티컬 AI가 중요한 이유는 시장 규모에 있다. 과거의 버티컬 SaaS(Software as a Service)가 약 500억 달러 규모의 시장이었다면, AI는 이제 노동력 자체를 대체하는 방향으로 침투하고 있으며 이는 수조 달러 규모의 기회를 의미한다. 그러나 그 잠재력에도 불구하고 아직 대규모 성공 사례는 드물다. Lovejoy는 그 이유를 세 가지 공통 실수로 정리한다. 첫째, 도메인 전문가를 고용하지 않거나 너무 늦게 고용하는 것. 둘째, 잘못된 유형의 도메인 전문가를 고용하는 것. 셋째, 그들을 조직 내에서 올바르게 배치하지 않는 것이다. 이 세 가지 실수는 곧 이 강연이 답하려는 세 가지 질문으로 이어진다. 도메인 전문가가 정말 필요한가? 누가 필요한가? 그리고 어떻게 활용해야 하는가?
도메인 전문가는 왜 필수인가
Lovejoy는 도메인 전문가의 필요성을 ‘AI 품질 평가’라는 문제로 환원한다. AI 제품을 만드는 조직은 끊임없이 “우리의 AI가 잘 작동하고 있는가?”를 판단해야 하며, 이 판단은 필연적으로 특정 도메인의 맥락적 이해를 요구한다. 법률 AI라면 변호사의 판단이, 의료 AI라면 임상의의 판단이 필요하다. 흥미로운 점은 이 ‘도메인 전문성’이 반드시 공식적인 자격증을 의미하지 않는다는 것이다. 그는 이를 ‘비공식 도메인 전문성’이라고 부르며, 특정 업무 흐름이나 사용자 니즈에 대한 깊은 이해 역시 전문성으로 인정될 수 있다고 설명한다. 또한 이 강연은 도메인 전문가를 반드시 새로 채용하라는 주장이 아니다. 조직 내에 이미 그 역할을 수행할 수 있는 사람이 있다면, 그들을 어떻게 구조적으로 활용할 것인가를 설계하는 것이 더 현실적인 출발점이다.
핵심 프레임워크 - Oracle, Evaluator, Architect
02:50 - Oracle/Evaluator/Architect 세 가지 모델 프레임워크 소개
Oracle (오라클) - 전문성을 직접 제품에 녹이다
Oracle 모델에서 도메인 전문가는 가장 직접적인 방식으로 AI 품질에 개입한다. 그들은 AI의 출력물을 직접 검토하고, 어디서 무엇이 잘못되었는지를 파악한 뒤, 프롬프트를 수정하거나 문서, 툴, 컨텍스트를 보강하는 방식으로 제품을 개선한다. 평가와 개선, 두 단계 모두를 도메인 전문가 한 명이 담당하는 구조다. 이는 특히 초기 스타트업에 적합하다. 조직이 작고 AI 출력물의 양이 많지 않을 때, 도메인 전문가가 가장 빠른 피드백 루프를 형성할 수 있기 때문이다.
Evaluator (평가자) - 측정 시스템을 설계하다
Oracle이 직접 손을 대는 장인이라면, Evaluator는 품질을 정의하고 측정하는 시스템을 설계하는 역할이다. 도메인 전문가는 “무엇이 좋은 AI 출력인가”를 정의하고 이를 객관적으로 측정 가능한 지표로 변환한다. 실제 개선 작업은 엔지니어링 팀이 담당하지만, 무엇을 개선해야 하는지를 알려주는 나침반 역할은 여전히 도메인 전문가가 맡는다. 측정 시스템은 다양한 형태를 띤다. 고객 사용 데이터에서 추출한 지표일 수도 있고, 외부 임상의들이 AI 출력의 일부를 직접 검토하는 구조일 수도 있으며, LLM-as-judge 방식으로 자동화할 수도 있다. Evaluator 모델이 작동하려면 AI 품질을 어떤 형태로든 객관적으로 수치화할 수 있어야 한다는 전제 조건이 있다.
Architect (설계자) - 자동으로 학습하는 시스템을 만들다
Architect는 세 모델 중 가장 높은 수준의 추상화를 다룬다. 도메인 전문가가 AI 품질을 평가하고 개선하는 과정 자체를 자동화하는 시스템을 설계하는 역할이다. 인간의 개입을 최소화하면서도 사용 데이터로부터 지속적으로 학습하고 스스로를 개선하는 AI 파이프라인을 구축하는 것이 목표다. 이 단계에서 도메인 전문가는 코드를 직접 작성하지 않더라도, 어떤 메커니즘이 자동 개선을 가능하게 하는지를 이해하고 그 방향을 설정할 수 있어야 한다. Lovejoy는 이 주제에 대해 별도의 강연에서 더 자세히 다룬다고 언급했다.
세 가지 모델 중 무엇을 선택할 것인가
08:53 - 조직 규모와 유스케이스에 따른 모델 선택 의사결정 가이드
Lovejoy는 모델 선택의 첫 번째 분기를 “AI 품질을 지표로 측정할 수 있는가?”로 잡는다. 측정 자체가 어렵거나 품질이 취향과 감각의 영역에 가깝다면, Oracle 모델이 적합하다. 이때 하위 질문은 한 명의 Oracle이면 충분한가, 아니면 영역별로 여러 Oracle이 필요한가이다. 반면 품질을 객관적으로 측정할 수 있다면, 그다음 분기는 “수동 반복(manual iteration)이 충분히 빠른가?”다. 엔지니어가 피드백을 받아 손으로 고치는 속도가 고객 니즈의 변화를 따라갈 수 있다면 Evaluator 모델로도 충분하다. 그러나 변화의 속도가 너무 빠르거나 케이스의 다양성이 너무 크다면, 자동화된 개선 루프를 설계하는 Architect 모델로 진화해야 한다. 중요한 것은 이 모델들이 고정된 선택이 아니라는 점이다. 조직이 성장하고 제품이 복잡해짐에 따라 Oracle에서 시작해 Evaluator로, 다시 Architect로 자연스럽게 진화하는 경로가 일반적이다.
세 가지 사례 연구
Granola - 단 한 명의 Oracle이 품질을 지킨다
Granola는 AI 기반 회의록 생성 서비스로, 최근 10억 달러 이상의 기업가치를 인정받은 회사다. Lovejoy의 지인인 Jo는 작가이자 저널리스트 출신으로 Granola의 첫 번째 직원으로 합류했다. 그녀는 수백 수천 명의 사용자를 인터뷰하고 논문을 읽으며 “좋은 회의록이란 무엇인가”를 집요하게 연구했고, 그 결과를 모든 프롬프트에 녹여냈다. 지금도 그녀는 AI 출력물을 직접 검토하고 개선하는 Oracle 역할을 수행하고 있다.
11:04 - Granola 사례 - Jo의 Oracle 역할 설명
Granola에 Oracle 모델이 적합한 이유는 두 가지다. 첫째, ‘완벽한 회의록’이란 객관적으로 정의될 수 없다. 회의록의 품질은 본질적으로 인간의 취향과 맥락에 달려 있기 때문에, 수치 지표보다 숙련된 감각이 더 중요하다. 둘째, 회의록이 제품의 핵심 출력물이기 때문에 규모가 커져도 직접적인 인간 검토와 개선 루프를 유지하는 것이 충분히 가능하고 의미 있다.
Tandem - 분산된 Oracle 네트워크로 확장하다
Tandem은 영국 최대 규모의 임상 AI 제품 제공업체로, 의사와 환자의 진료 대화를 실시간으로 받아 의료 기록을 자동 생성하는 AI 스크라이브(medical AI scribe) 제품을 보유하고 있다. Tandem이 처음 고용한 도메인 전문가 Roy는 의사 출신으로 McKinsey 경력도 보유한 인물이었다. 그는 의료 기록을 직접 검토하고 프롬프트를 수정하는 Oracle 역할을 수행했다. 그러나 고객 수와 서비스 범위가 늘어남에 따라 단 한 명이 이 모든 것을 처리하는 구조는 한계에 부딪혔다.
Tandem이 선택한 해법은 ‘분산된 Oracle 네트워크’였다. 다양한 국가와 전문 진료과의 의사들을 추가로 투입하여 각 세그먼트의 프롬프트를 직접 관리하게 했다. 특정 국가의 특정 진료과 담당 의사가 해당 고객군의 피드백을 수집하고 프롬프트를 수정하면, 그 버전이 해당 세그먼트에만 배포된다. 결과적으로 수천 가지의 프롬프트 변형이 각기 다른 컨텍스트에서 운용되는 구조가 탄생했다.
13:11 - Tandem의 분산형 Oracle 네트워크 구조 설명
이 접근법이 유효했던 이유는 완벽한 의료 기록이 존재하지 않고, 국가와 진료과마다 기록 방식에 대한 기준이 다르며, 그 다양성을 처리하려면 현장에 가까운 전문가가 직접 개입해야 하기 때문이다.
Anterior - Oracle에서 Architect까지 진화한 여정
Anterior는 미국의 사전승인(Prior Authorization) 자동화 AI 스타트업이다. 사전승인이란 환자의 치료 요청이 보험사의 의학적 기준을 충족하는지를 검토하는 행정 절차로, 보험사 내부의 의사와 간호사들이 담당하는 복잡한 임상적 판단이 요구된다. Lovejoy는 Anterior의 첫 번째 기술 직원으로서 초기 제품과 프롬프트를 직접 구축하고, 임상의로서의 시각으로 AI 출력을 검토하며 Oracle 역할을 수행했다.
그러나 고객이 늘고 다루어야 할 케이스의 다양성이 증가하면서, 그는 Evaluator 역할로 전환했다. 임상의들이 AI 출력의 일부를 검토할 수 있는 대시보드를 구축하고, 성능 지표와 실패 패턴을 정의하며 엔지니어링 팀과 협력하는 구조를 만들었다. 하지만 이것도 충분하지 않았다. 보험사마다 사전승인 기준을 해석하는 방식이 서로 달랐고, 그 변이를 수동 반복으로는 따라잡을 수 없었다. 결국 그는 Architect 역할로 진화하여, 에지(edge)에서 발생하는 다양한 케이스로부터 자동으로 학습하고 개선되는 시스템을 설계하는 방향으로 나아갔다. 이 여정이 가능했던 이유는 AI 출력의 품질이 ‘올바른 승인 결정인가, 아닌가’로 명확히 측정될 수 있었고, 이 판단에는 임상적 추론이 필수적이었기 때문이다.
15:09 - Anterior의 Oracle에서 Evaluator/Architect로의 진화 경로
어떤 역할에 어떤 사람이 필요한가
17:08 - Oracle/Evaluator/Architect 각 역할별 필요 스킬셋 정리
세 모델은 각각 다른 종류의 사람을 필요로 한다. Oracle에게 가장 중요한 것은 해당 유스케이스에 대한 직접적인 경험이다. ‘의사’라는 자격증이 아니라, 의료 코딩이라는 구체적인 업무를 직접 수행해본 경험이 훨씬 더 가치 있다. 여기에 프롬프트 엔지니어링 감각과 디테일에 대한 집요한 주의력, 고객 이해 능력이 더해지면 이상적이다.
Evaluator는 도메인 전문성에 더해 데이터 사이언스적 직관이 필요하다. Lovejoy는 Evaluator의 핵심 역량을 데이터 과학의 그것과 동일시한다. 측정하려는 지표를 정의하고, 그 데이터를 수집하는 시스템을 설계하며, 통계적으로 유의미한 신호를 읽어내는 능력이 필요하다. 또한 임상의나 변호사 등 외부 리뷰어 팀을 운영할 수 있는 리더십과, 엔지니어링 팀과 협업하는 프로덕트 매니지먼트 역량도 중요하다.
Architect는 앞선 두 역할의 역량에 더해, LLM 기반 제품 개발 경험과 자동화 개선 메커니즘에 대한 이해가 필수다. 어떤 레버를 당겨야 성능이 개선되는지를 이론이 아닌 실전 경험으로 알아야 하며, 직접 코드를 작성하지 않더라도 엔지니어링적 사고방식으로 시스템을 설계할 수 있어야 한다.
도메인 전문가를 조직에 통합하는 세 가지 원칙
19:38 - 도메인 전문가 활용을 위한 세 가지 원칙 요약
원칙 1 - 주도적 도메인 전문가(Principal Domain Expert)를 정의하라
Lovejoy가 가장 강조하는 원칙은 AI 품질에 대한 최종 책임을 지는 단 한 명을 명확히 지정하는 것이다. 모두가 책임지는 구조는 사실상 아무도 책임지지 않는 구조다. 주도적 도메인 전문가가 존재할 때, 그 개인은 AI 품질의 세부적인 실패 패턴을 깊이 이해하게 되고, 이 이해가 더 나은 의사결정으로 이어진다. 위원회적 합의(consensus by committee) 구조는 의사결정 속도를 늦추고, 책임의 소재를 불분명하게 만들어 결국 AI 품질 개선의 속도를 저하시킨다.
원칙 2 - 진정한 오너십을 부여하라
도메인 전문가를 ‘자문 역할’이나 ‘검토자’로 한정하는 것은 그들의 잠재적 기여를 절반으로 줄이는 것과 같다. Lovejoy는 그들이 제품 방향을 결정하는 자리에 직접 참여해야 한다고 강조한다. 그는 자신이 목격한 실패 사례를 직접 인용했다. 한 회사에서 두 명의 시니어 임상 전문가가 있었지만 명확한 주도권이 없었고, 자문적 역할에 머물렀다. 결과적으로 AI 품질 개선 시스템은 좀처럼 발전하지 못했고, 약 12~18개월 후 두 사람 모두 조직을 떠났다. 그들이 머릿속에 가지고 있던 도메인 지식과 네트워크도 함께 사라졌다. 오너십은 도메인 전문가를 조직에 묶어두는 것이 아니라, 그들이 진정으로 기여할 수 있는 환경을 만드는 것이다.
원칙 3 - 인접 역량의 폭을 고려해 채용하라
도메인 전문성은 채용의 필수 조건이지, 충분 조건이 아니다. Lovejoy는 도메인 전문성을 기반으로 하되, 그 위에 가능한 한 많은 인접 역량(데이터 감각, 프롬프트 이해, 리더십, 엔지니어링 소양 등)을 갖춘 사람을 선택하라고 조언한다. 순수한 도메인 전문가는 Oracle 역할은 잘 수행할 수 있지만, 조직이 성장함에 따라 Evaluator나 Architect로 진화하는 데 어려움을 겪을 수 있다. 처음부터 한 명이 그 여정을 함께할 수 있는 사람을 채용하는 것이, 나중에 다른 사람을 추가로 영입하는 것보다 훨씬 효과적이다. 물론 어느 한 영역이 부족하다면, 그 부분을 보완하는 협력자를 매칭하는 방법도 현실적인 대안이 된다.
마무리 - 버티컬 AI의 경쟁은 조직 설계에서 갈린다
Chris Lovejoy의 논지는 하나의 핵심 명제로 요약된다. 버티컬 AI에서 승리하는 것은 기술적 문제가 아니라 조직적 문제다. 모델의 성능은 이미 충분하며, 그것을 특정 도메인의 복잡성과 뉘앙스에 맞게 조율하고 지속적으로 개선하는 시스템을 갖추는 것이 진정한 경쟁력의 원천이다. Oracle, Evaluator, Architect라는 세 가지 모델은 상호 배타적인 선택지가 아니라, 조직의 성장 단계에 따라 자연스럽게 진화하는 여정의 지도다. 아직 이 분야는 초기이며 확립된 플레이북이 없다. 그러나 도메인 전문성을 조직의 핵심 역량으로 내재화한 팀이, 그렇지 않은 팀보다 훨씬 더 빠르게 학습하고 개선할 것이라는 점은 분명하다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | How to Leverage Domain Expertise — Chris Lovejoy, Notius Labs |
| 채널 | AI Engineer |
| 발표자 | Chris Lovejoy |
| 리포트 작성 | 2026-05-17 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.