3인 규모의 YC 팀이 어떻게 4개월 만에 AI 네이티브 프로세스 발견 엔진 (process discovery engine)을 구축했는지, 그리고 이 분야의 모든 기업이 규모 확장 시 직면하게 될 아키텍처적 긴장 관계에 대한 존중을 담은 고찰입니다.

설정: 이것이 중요한 이유

대부분의 엔터프라이즈 AI 데모는 PowerPoint 허구에 불과합니다. 매끄러운 인터페이스, 몇 개의 가짜 차트, 그리고 마치 그것이 제품인 양 "GPT-4를 사용하고 있습니다"라고 말하는 창업자를 보게 됩니다.

그러다 저는 Ontora의 제품 데모를 보았습니다. YC 피칭이 아니라, 실제 UI 워크스루(walkthrough)였습니다. 그리고 저는 다른 것을 보았습니다. 6개의 뚜렷한 계층 (layers), 고정된 온톨로지 (ontology), 그리고 그들이 마케팅에서 절대 언급하지 않는 문제를 얼마나 잘 해결했느냐에 따라 천재적이거나 혹은 위험할 수 있는 피드백 루프 (feedback loop)를 가진, 실제 아키텍처로 보이는 무언가를 말입니다.

Ontora는 YC P26 기업입니다. 3명의 창업자. 약 70만 달러의 투자 유치. 5개의 엔터프라이즈 디자인 파트너. 그들의 피칭은 간단합니다. AI 에이전트 (AI agents)를 배치하여 회사의 모든 직원을 인터뷰한 다음, 전사 기록 (transcripts)을 프로세스 맵 (process maps), 병목 현상 분석 (bottleneck analysis), 그리고 자동화 로드맵 (automation roadmap)으로 합성하는 것입니다. 4개월의 컨설팅 대신 4시간이면 충분합니다.

저는 제품 데모 프레임, 창업자 배경, GitHub 리포지토리 (repos), YC 디렉토리 데이터 등 그들의 공개된 신호들을 역공학 (reverse-engineering)하는 데 일주일을 보냈습니다. 이어지는 내용은 이 시스템이 어떻게 작동할지에 대한 저의 최선의 재구성이며, 엔지니어링이 진정으로 어려워지는 지점과, 어려운 부분을 해결하는 기업들이 왜 이 카테고리를 점유하게 될지에 대한 분석입니다.

이것은 해체 (teardown)가 아닙니다. 극단적인 제약 조건 하에 구축된 야심 찬 아키텍처에 대한 **기술적 연구 (technical study)**입니다. 모든 빌더(builder)들은 여기서 발생하는 트레이드오프 (tradeoffs)를 인지할 것입니다. 그리고 저의 분석 중 틀린 부분이 있을 수 있으니, 수정 제안을 환영합니다.

계층 1: 캠페인 오케스트레이션 (Campaign Orchestration) — 인터뷰 위의 두뇌

데모가 처음으로 드러내는 사실은 Ontora가 한 번에 "모두를 인터뷰"하는 것이 아니라는 점입니다. 그들은 **캠페인 (campaigns)**을 실행합니다.

당신은 "인터뷰 생성 (Create Interview)" 모달을 엽니다. AI Transformation Discovery, Employee Engagement, Change Management, 또는 Process Optimization 중 목표 템플릿을 선택합니다. 범위를 특정 부서로 지정합니다. 주제가 요구하는 바에 따라 20분, 30분 등 지속 시간을 설정합니다. 음성 페르소나("Blake — Helpful Agent")를 선택합니다. 직접 참가자 명단을 업로드할지, 아니면 디렉토리 연동 (directory integration)을 통해 Ontora가 직원을 찾아내도록 할지 결정합니다.

그런 다음 시작 버튼을 누릅니다.

이것은 설문 조사 도구가 아닙니다. 이것은 **캠페인 오케스트레이션 엔진 (campaign orchestration engine)**입니다. 그리고 이것은 당신이 아키텍처를 생각하는 방식의 모든 것을 바꿉니다.

이 레이어가 어려운 이유

UI에서 파악할 수 있는 바로는, 제 최선의 추측은 각 캠페인이 다음과 같은 고유한 요소를 가진 범위가 지정된 상태 유지 워크플로우 (scoped, stateful workflow)라는 것입니다:

• 프롬프트 템플릿 (Prompt template) (LLM 시스템 프롬프트는 목표 + 부서 + 주제를 바탕으로 구성됨)
• 참가자 코호트 (Participant cohort) (HRIS/SCIM 또는 CSV 업로드를 통해 결정됨)
• 라이프사이클 상태 머신 (Lifecycle state machine) (초안 → 예약됨 → 진행 중 → 일시 중지됨 → 완료됨)
• 진행 상황 집계 (Progress aggregation) (실시간 카운터: 547명 중 526명 완료)
• 출력 스키마 (Output schema) (이 캠페인이 생성해야 할 인사이트, 맵, 그리고 지표)

10명 규모에서 이를 구축하는 것은 간단합니다. 하지만 5명의 고객사가 각각 서로 다른 조직 구조, 언어, 컴플라이언스 요구 사항을 가진 상태에서 50개의 캠페인이 동시에 실행될 때 이를 구축하는 것은 — UX 문제로 위장한 분산 시스템 (distributed systems) 문제처럼 보입니다.

데모에서는 사이드바에 17개 이상의 캠페인이 표시됩니다. 일부는 활성 상태이고, 일부는 초안이며, 일부는 일시 중지된 상태입니다. 그 사이드바는 제가 의심하기를, 상태를 잃지 않으면서 수백 개의 동시 인터뷰 세션에 걸쳐 스케줄링, 재시도, 타임아웃 및 집계를 수행해야 하는 멀티 테넌트 오케스트레이션 레이어 (multi-tenant orchestration layer)를 위한 컨트롤 플레인 (control plane)인 것으로 보입니다.

그것은 진정한 엔지니어링처럼 보입니다.

레이어 2: 인터뷰 인터페이스 — 텍스트 우선, 음성 선택 사항

여기가 바로 저의 원래 가설이 무너진 지점입니다.

저는 "100개의 병렬 호출"이 전화 통신(telephony)을 의미한다고 가정했습니다. Twilio, Bland AI, Retell 같은 것들 말이죠. 그에 따른 모든 비용과 복잡성을 수반하는 실시간 음성 인프라(real-time voice infrastructure)를 말입니다.

하지만 데모는 완전히 다른 것을 보여줍니다: 바로 **웹 기반 채팅 인터페이스 (web-based chat interface)**입니다.

직원이 링크를 엽니다. 채팅창이 보입니다. 에이전트가 자기소개를 합니다: "안녕하세요 David님, 이 채팅은 Pilot Group의 재무 부서에서 높은 ROI를 가진 자동화 기회를 찾는 것에 관한 것입니다. 약 20분 동안 대화할 예정이며, 모든 내용은 비밀이 보장됩니다. 준비되셨을 때 시작해 주세요."

직원은 답장을 타이핑합니다. 또는 스페이스바를 누른 채로 말합니다. 전사된 내용(transcript)이 텍스트 말풍선으로 나타납니다. 나중에 일시 중지했다가 다시 시작할 수도 있습니다. 진행 상황은 저장됩니다.

이것이 영리한 이유

전화 통신 기반의 음성 AI (telephony voice AI)는 대규모 운영 시 분당 약 $0.05~$0.10의 비용이 듭니다. 20분짜리 인터뷰는 LLM, 저장소(storage) 또는 컴퓨팅(compute) 비용을 지불하기 전, 순수 인프라 비용만으로도 $1~$2가 소요됩니다.

반면 웹 기반 텍스트 인터뷰는 동일한 시간 동안 총 약 $0.05~$0.10의 비용이 듭니다. 전송 계층(transport layer)이 아닌 LLM 토큰(tokens)이 주요 비용이 됩니다. 여기에 선택 사항으로 푸시 투 토크(push-to-talk) 음성(STT + TTS)을 추가하면, 전화 통신 비용 없이도 음성의 풍부함을 얻을 수 있습니다.

한 달에 500건의 인터뷰를 진행할 경우, 비용 차이는 $500 대 $5,000입니다. 5,000건의 인터뷰라면 $5,000 대 $50,000가 됩니다. 계약당 약 $50,000에 판매하는 프리시드(pre-seed) 스타트업에게 이 마진은 매우 중요합니다.

이것이 어려운 이유

UX(사용자 경험) 문제는 미묘합니다. 전화 통화는 사회적 중력(social gravity)을 가집니다. 전화를 받으면 집중하게 되고, 대화를 마칩니다. 하지만 웹 채팅은 비동기적(asynchronous)입니다. 직원이 한 시간 동안 멈출 수도 있고, 멀티태스킹을 할 수도 있으며, 아예 이탈할 수도 있습니다.

Ontora는 세션 상태 유지(session state persistence)를 통해 이 문제를 해결하는 것으로 보입니다: 진행 상황이 저장되고, 컨텍스트(context)가 다시 로드되며, 에이전트가 정확히 멈췄던 지점에서 대화를 재개합니다. 하지만 장시간 지속되는 LLM 대화의 세션 상태를 관리하는 것은 결코 간단하지 않습니다. 다음과 같은 것들이 필요합니다:

• 대화 컨텍스트를 유지할 수 있는 세션 저장소 (Session store: Redis, DynamoDB, Firestore)
• 컨텍스트 윈도우 관리 전략 (Context window management strategy: 매 턴마다 20분 분량의 전사 내용을 LLM 프롬프트에 입력할 수는 없으므로, 요약(Summarization) 또는 RAG가 필요함)
• 대화를 중단하고 돌아오지 않는 직원을 위한 재참여 시스템 (Re-engagement system: 이메일 알림, Slack 리마인더)

데모는 이 모든 것들이 작동하는 것처럼 보이는 모습을 보여줍니다. 이는 3명 규모의 팀에게 결코 사소한 일이 아닙니다.

레이어 3: 추출 및 연결 (Extraction & Linking) — 채팅에서 구조화된 지식으로

인터뷰가 끝나면, 가공되지 않은 전사 데이터(Raw transcript)는 그저 소음에 불과합니다. 진짜 어려운 작업은 자연어를 구조화된 지식 그래프(Knowledge graph)로 변환하는 것입니다.

데모를 통해, 저는 아마도 실행되고 있을 최소 네 가지의 추출 파이프라인(Extraction pipelines)을 추론할 수 있습니다:

3.1 엔티티 추출 (Entity Extraction)

누가 언급되었는가? 어떤 도구들이 사용되었는가? 어떤 프로세스가 있는가? 데모에서 에이전트는 다음과 같이 질문합니다: "어떤 기록, 문서, 대화 내용을 확인해야 했나요?" 직원은 다음과 같이 답합니다: "Outlook, NetSuite, SharePoint, 그리고 Teams입니다." 이 도구 이름들은 추출되고, 정규화(Normalized)되어 회사의 시스템 커넥터 인벤토리(System connector inventory)와 연결됩니다.

3.2 감성 및 의도 (Sentiment & Intent)

데모에서 이를 명시적으로 보여주지는 않지만, 출력 결과로 암시됩니다. Anna Keller에 대한 인사이트 카드에는 다음과 같이 적혀 있습니다: "Anna는 영향력이 큰 재무 운영자(High-impact finance operator)를 나타냅니다. 업무가 자동화할 수 있을 만큼 충분히 구조화되어 있지만, 예외 상황은 여전히 문서, 이메일, 채팅에 흩어져 있는 컨텍스트를 필요로 합니다."

이 문장은 전사 내용의 인용구가 아닙니다. 이는 직원의 역할을 분류하고, 업무 패턴을 설명하며, 자동화 준비도를 평가한 LLM에 의해 생성된 **합성된 페르소나 아키타입 (Synthesized persona archetype)**입니다. 이는 아마도 인터뷰 후 배치 작업(Post-interview batch job)으로 실행되는 감성 분석(Sentiment analysis), 역할 분류(Role classification), 프로세스 성숙도 점수 산정(Process maturity scoring)을 필요로 할 것입니다.

3.3 프로세스 추출 (Process Extraction)

이것이 바로 핵심(crown jewel)입니다. 데모에서는 **스윔레인 다이어그램 (swimlane diagram)**인 _'수동 송장 불일치 검토: 현재 상태 스윔레인(Manual invoice mismatch review: current-state swimlane)'_을 보여줍니다. 여기에는 Vendor, Finance/AP, Operations, 그리고 Procurement/Buyer를 위한 레인(lane)이 있습니다. 단계는 다음과 같습니다: 송장 접수 (Invoice Intake) → 3-Way Match → 증거 검색 (Evidence Search) → 예외 결정 (Exception Decision) → 승인 라우팅 (Approval Routing).

이것은 **다수의 직원 인터뷰 (multiple employee interviews)**로부터 추출되어 시각적인 프로세스 맵으로 렌더링되었습니다. 이것이 작동하기 위해서는, LLM이 다음과 같은 작업을 수행했어야 합니다:

• 비정형 서사 (unstructured narrative)로부터 순차적인 단계 식별
• 각 단계를 조직 내 역할 (swimlane)에 매핑
• 의사결정 지점 (decision points) 및 루프 (loops) 감지
• 정량적 지표 계산 ($27,310/yr, 10.1h/week)

3.4 시스템 언급 연결 (System Mention Linking)

데모는 NetSuite, SharePoint, Outlook, Teams와 같은 시스템 이름이 추출되고 연결되는 과정을 명시적으로 보여줍니다. 이것은 단순한 키워드 매칭이 아닙니다. 에이전트는 특정 시스템에 대해 후속 질문을 던지는데, 이는 해당 회사가 그 시스템들을 사용한다는 것을 알고 있기 (커넥터 통합을 통해) 때문입니다. 이것은 **문맥 인식 대화 시스템 (context-aware dialogue system)**입니다. 즉, 에이전트의 질문은 회사의 기존 도구 인벤토리로부터 동적으로 구성됩니다.

레이어 4: 온톨로지 (The Ontology) — 숨겨진 아키텍처

이것은 데모에서 발견한 가장 중요한 사실이며, Ontora는 마케팅에서 이를 전혀 언급하지 않습니다.

데모의 11번째 프레임은 지식 채팅 / 위키 (Knowledge Chat / Wiki) 뷰를 보여줍니다. 왼쪽 사이드바에는 다음과 같은 계층 구조가 표시됩니다:

Company
├── Departments
│   ├── Finance Department
...

이것은 문서 폴더가 아닙니다. 이것은 온톨로지 (ontology) — 또는 적어도 회사가 어떻게 구성되어 있는지에 대한 공식적인 분류 체계 (taxonomy)인 것으로 보입니다. 모든 인터뷰가 이 계층 구조로 파싱되는 것으로 보입니다. 모든 통찰(insight)은 온톨로지 내의 위치와 함께 태그가 지정됩니다.

이것이 중요한 이유

대부분의 AI 지식 도구는 **평면적 벡터 저장소 (flat vector store)**를 사용합니다. 문서를 쏟아붓고, 시맨틱 검색 (semantic search)으로 쿼리를 날리면, 관련 있는 청크 (chunks)를 돌려받는 방식입니다. 강력하지만 단순합니다.

Ontora는 고정된 계층 구조를 가진 **구조화된 지식 베이스 (structured knowledge base)**를 사용합니다. 시스템이 "Anna Keller는 NetSuite에서 송장 예외 사항을 처리합니다"라는 문장을 추출할 때, 이를 단순히 텍스트로 저장하는 것이 아니라 다음과 같이 저장합니다:

• 엔티티 (Entity): Anna Keller
• 유형 (Type): 직원 (Employee)
• 부서 (Department): 재무 (Finance)
• 프로세스 (Process): 송장 예외 처리 (Invoice Exception Handling)
• 시스템 (System): NetSuite
• 역할 (Role): 매입 채무 리드 (Accounts Payable Lead)
• 인사이트 (Insight): 높은 자동화 잠재력 (High automation potential)

이것이 검색 엔진 (search engine)과 **지식 그래프 (knowledge graph)**의 차이점입니다. 검색 엔진은 관련 텍스트를 찾아내지만, 지식 그래프는 다음과 같은 구조화된 질문에 답합니다: _"NetSuite를 사용하면서 자동화 잠재력이 높은 재무 프로세스는 무엇인가?"

이것이 어려운 이유

온톨로지 (ontology)가 **고정 (fixed)**되어 있습니다. 기업이 이 구조에 맞지 않으면 어떻게 될까요?

• 매트릭스 조직 (Matrix organizations)에는 여러 부서에 속한 직원들이 있습니다.
• 플랫폼 팀 (Platform teams)은 제품이 아닌 횡단적 역량 (cross-cutting capabilities)을 소유합니다.
• 프리랜서와 계약직은 "직원"이 아닙니다.
• 비영리 단체는 "고객 계정 (customer accounts)"이 없습니다.

온톨로지가 경직되어 있다면, 시스템은 모든 기업을 동일한 구조적 틀에 강제로 끼워 맞추게 됩니다. 반대로 온톨로지가 유연하다면 엔지니어링 복잡도가 폭발합니다. 즉, 동적 스키마 진화 (dynamic schema evolution), 사용자 정의 엔티티 유형 (user-defined entity types), 그리고 고객 간의 온톨로지 병합 (ontology merging)이 필요하게 됩니다.

데모는 깔끔하고 고정된 계층 구조를 보여줍니다. 저는 이것이 v1 버전일 것이라고 추측합니다. 물론 제가 틀렸을 수도 있습니다 — 진짜 테스트는 이 구조가 부러지지 않고 유연하게 휘어질 수 있는지 여부입니다.

레이어 5: 출력 및 시각화 — 그래프에서 의사결정으로

데모는 세 가지 출력 모드를 보여줍니다:

5.1 경영진 대시보드 (The Executive Dashboard)

인터뷰 횟수, 완료율, 참가자 메타데이터를 포함한 테이블 뷰입니다. 이는 프로젝트 매니저를 위한 "다 끝났나요?" 확인용 뷰입니다.

5.2 보고서 뷰 (The Report View)

심각도 태그 (severity tags), 인용구, 시스템 참조가 포함된 구조화된 인사이트입니다. 데모에서는 다음과 같은 "주요 발견 (Key Finding)" 카드를 보여줍니다: _"송장 예외 사항으로 인해 재무팀은 결제가 진행되기 전 NetSuite, SharePoint, Outlook, Teams, 그리고 벤더 트래커(vendor tracker)에 걸쳐 하나의 의사결정 패킷을 재구성해야 합니다."

이것은 단일 인터뷰를 전사(transcription)한 것이 아니라, 여러 인터뷰를 통해 합성(synthesized)된 결과입니다. 이는 그 어떤 단일 직원도 온전히 설명하지 못했던 **교차 기능적 패턴 (cross-functional pattern)**을 나타냅니다. 시스템이 점들을 연결한 것입니다.

5.3 프로세스 맵 (The Process Map)

정량화된 지표가 포함된 스윔레인 다이어그램 (swimlane diagram)입니다. 이것은 "이사회에 보여줄" 결과물입니다. 마치 소프트웨어로 생성된 맥킨지(McKinsey) 슬라이드처럼 보입니다.

지표 문제 (The Metrics Question)

여기서부터 아키텍처가 철학적으로 흥미로워집니다.

스윔레인은 다음과 같은 내용을 표시합니다: 연간 $27,310의 직접 AP(Accounts Payable) 노력. 해결된 연간 $43,025의 중복 비용. 주당 10.1시간의 수동 작업. 연간 247건의 지연 사례.

이 수치들이 어떻게 계산되었는지 알 방법은 없지만, 제 추측으로는 다음 중 하나일 것입니다:

1. 인터뷰 텍스트로부터 LLM이 추정한 값 (예: "일주일에 약 2시간 정도 걸립니다" → 2시간 × 52주 × $26/시간 = $2,704)
2. NetSuite/SharePoint 통합을 통해 실제 시스템 데이터와 연결된 값
3. 두 방식의 혼합