연매출 40억 스타트업, Tiro가 설명하는 ''온톨로지'' (feat. 여울님, 현제님)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

연매출 40억 스타트업으로 소개된 티로가 설명하는 온톨로지는 조직의 공통 정의와 실행 규칙, 권한·감사를 정해 에이전트가 업무 맥락에 맞게 행동하도록 하는 기반이다.

📌 핵심 요점

1. 티로는 대화 기록·번역·문서 공유에서 기업의 맥락을 보존하는 도구로 확장하고 있다. 초기에는 특정 고객의 문제를 현장에서 해결하는 데 집중했고, 앞으로는 에이전트가 대화 자산을 활용하도록 지원하려 한다.
2. 약 12명 팀의 개인별 에이전트는 소울·위키·온톨로지의 세 계층을 조합한다. 소울은 개인의 행동 특성, 위키는 업무 데이터와 대화 기록, 공용 온톨로지는 조직이 함께 지켜야 할 규칙을 맡는다.
3. 티로는 온톨로지를 데이터·로직·액션·감사·권한의 다섯 요소로 이해한다. 국가별 MRR의 귀속 기준이나 계약 금액처럼 판단이 달라지면 안 되는 업무부터 정의하며, 모든 업무에 엄격한 규칙을 적용하지는 않는다.
4. 구축의 출발점은 다른 사람이 그대로 수행할 수 있을 만큼 업무와 예외를 서술하는 것이다. 대화 기록은 암묵지와 용어의 실제 사용을 찾는 근거이며, 이를 최종 정의로 확정하는 책임은 사람에게 있다.
5. 에이전트의 신뢰는 권한 제한, 판단 로그, 중요한 결과의 검수와 지속적인 규칙 갱신에서 나온다. 티로는 공용 저장소의 PR·린트와 개인 에이전트 격리를 활용하며, 사람의 문제 정의 능력도 조직 속도를 좌우한다고 본다.

🧩 배경과 문제 정의

• 티로는 대화 기록과 실시간 번역을 문서 생성·공유까지 연결하는 서비스다. 초기 제품 개발에서는 모델의 논문상 성능보다 실제 고객의 문제 해결과 사용 경험을 중요하게 다뤘다.
• 약 12명 규모의 팀은 시차와 특정 담당자에게 집중된 업무 맥락 때문에 생기는 병목을 줄이려 한다. 개인별 에이전트에 경험과 업무 규칙을 전달해 사람이 직접 처리하는 일을 점진적으로 줄이는 방향이다.
• 조직의 AI 활용에는 자료 축적뿐 아니라 용어의 공통 정의, 실행 규칙, 권한과 감사 기록이 필요하다. 티로는 이를 온톨로지로 관리하지만, 모든 업무를 엄격한 규칙으로 만들 필요는 없다고 본다.
• 대화 기록은 암묵지를 찾아내고 조직의 정의를 합의하는 근거가 될 수 있다. 다만 기록에서 맥락을 추출하는 일과 사람이 최종적으로 온톨로지를 확정하는 일은 구분한다.

🕒 시간순 섹션별 상세정리

1. 대화 기록을 번역·문서 생성·공유로 연결하는 티로

• 티로는 대화를 실시간으로 기록하고, 필요한 경우 15가지 이상의 언어로 번역한다. 이후 조직이나 개인이 원하는 형태의 문서를 생성하고 슬랙·MCP·CLI 등으로 공유하는 통합 워크플로를 지원한다. [01:21]
• 고객마다 회의록 자체와 기록의 후속 활용 중 중요하게 여기는 지점이 다르다. 이에 따라 제품의 가치를 AI 회의록 또는 대화를 자산화하는 서비스로 보여준다. [01:50]

2. 초기 고객에게 집중한 제품 개선과 입소문

• 모두를 만족시키기보다 주변에 제품을 퍼뜨릴 수 있는 특정 고객을 깊이 만족시키는 전략을 택했다. 고객의 수정 요청과 필요한 기능에 빠르게 대응하는 경험을 만드는 데 집중했다. [02:34]
• 공동창업자들은 초기 약 1천 명의 고객 이름을 거의 외울 정도로 고객에게 집중했다. 기록 문제가 생기면 강의실이나 회의에 직접 들어가 확인했고, 논문상 지표가 좋아도 고객이 만족하지 못하면 현장에 맞게 교정과 가중치 조정을 반복했다. [03:18]

3. 모델 성능보다 실제 사용 행동에서 찾은 인터페이스

• 모델의 지능은 높아지고 가격은 떨어져 제품 구현 자체의 차별성이 약해질 것이라는 판단 아래 인터페이스에 집중했다. 사용자가 어디에서 이탈하고, 사용할 수 있었는데도 사용하지 않는 이유가 무엇인지 파악하는 일이 중요했다. [04:24]
• 고객을 따라다니며 티로를 켜지 않은 이유와 문제가 있었는데도 다시 사용한 이유를 물었다. 화면상의 데이터만으로 추측하기보다 하루의 행동을 관찰해 제품과 사용자가 만나는 방식을 개선하려 했다. [05:01]

4. 생계를 유지하며 제품에 집중할 수 있었던 선택권

• 회사 내부에서는 선택권을 많이 확보하는 ‘옵셔널리티’를 중요하게 여긴다. 2024년 9월 제품을 처음 출시할 당시 창업자들은 각자 직장을 유지하면서 주말에 모여 16~18시간씩 개발하고 고객을 만났다. [06:33]
• 초기에는 고객 수가 적어 비싼 API를 사용해도 비용이 감당 가능한 수준이었다. 생계와 비용 부담을 관리할 수 있었던 조건이 제품에 집중할 여유를 줬으며, 모두 퇴사하고 제품만으로 승부했다면 같은 결과를 냈을지는 자신하지 못한다. [07:02]

5. 개인별 에이전트로 업무를 대체하는 매크로하드 프로젝트

• 작년 11월경 시작한 ‘매크로하드’ 프로젝트는 고객을 직접 만나 목소리를 듣는 일 이외의 업무를 AI로 시뮬레이션할 수 있지 않겠느냐는 생각에서 출발했다. 현재 약 12명의 팀원에게 각각을 복제한 형태의 에이전트가 있다. [07:49]
• 레오가 슬랙에서 언급되면 에이전트 미오가 예상 답변과 필요한 작업을 먼저 처리한다. 레오는 결과를 확인하고 틀린 부분을 스레드에 남겨, 빠진 규칙이나 수정할 내용을 보완한다. [08:28]

6. 시차 병목을 줄이는 소울·위키·온톨로지의 세 계층

• 다른 시간대에 거주하는 팀원이 중요한 B2B 업무를 담당하면서, 그 사람의 의견을 기다리는 일이 병목이 됐다. 개인의 경험, 업무에 필요한 데이터, 조직의 규칙을 분리해 부여하면 담당자와 비슷하게 행동하는 에이전트를 만들 수 있겠다는 가설이 출발점이었다. [10:09]
• 소울 계층은 레오의 6개월~1년치 슬랙 메시지를 여러 에이전트로 처리해 만든 SOUL.md로 구성한다. 여기에는 말투와 개입 시점 같은 개인의 행동 특성이 들어간다. [11:04]

7. 일본 B2B의 암묵지를 이어받는 미오

• 미오에는 일본 B2B 업무에서 쌓인 일본어 메일과 계약서 등의 맥락이 담겨 있다. 일반적인 AI가 만든 외국어 메일은 담당자의 재확인이 필요했지만, 고객별 응대 규칙과 일본어 경어·톤을 정의하면서 바로 보낼 수 있는 형태의 답변을 제안하게 됐다. [12:43]
• 일본의 결제·계약 방식과 한국 기업 대응의 차이도 업무 데이터로 축적했다. 담당자가 빠지더라도 다른 팀원이 미오를 호출해 대응 방법을 파악할 수 있도록 한 것이다. [13:42]

8. CTO 에이전트의 권한 통제와 운영·검토 업무

• CTO 에이전트는 권한이 큰 만큼 무엇을 하면 안 되는지부터 정의했다. 쿼리 실행, 상태 변경, 환불 같은 요청은 요청자의 슬랙 ID로 걸러내며, 개인 비서 역할로는 새벽 5~6시 사이 회사 상황과 일정·이전 미팅 기록을 바탕으로 준비사항을 전달한다. [14:30]
• 보안 인증 이후 필요한 정기 권한 점검과 감사 보고서 업무는 온톨로지에 주기·규칙·절차를 정의해 에이전트와 동기화했다. 기업 고객이 요구하는 160개 또는 200개 항목의 보안성 검토도 기존 정의를 조합하고 필요하면 번역해 초안을 만든다. [15:28]

9. 공용 규칙 저장소와 온톨로지 적용의 경계

• 온톨로지 저장소는 한 곳에 두고, 구성원이 개인 봇·클로드·코덱스·터미널 중 무엇을 사용하든 공용 규칙을 따르거나 갱신할 때는 이 저장소를 거치게 한다. 반면 LLM 위키는 에이전트와 개인 세션마다 다르게 구성한다. [17:18]
• 티로의 구현이 엄격한 온톨로지를 완전히 충족하는 것은 아니라는 전제가 있다. 팔란티어의 정의를 참고해 데이터·로직·액션에 감사와 권한을 더한 다섯 요소로 이해하고 있다. [17:52]

10. MRR과 창고 사례로 구체화한 공통 언어와 실행 규칙

• 국가별 MRR을 서로 다르게 해석한 경험이 공통 언어 정의의 출발점이었다. 한국에서 일본인이 도입하고 일본 팀원 11명을 데려온 경우 어느 국가의 MRR로 볼지처럼 모호한 기준을 먼저 합의하고, 반드시 지켜야 할 가치가 있는 정의를 온톨로지로 승격한다. [19:15]
• 창고의 데이터는 사업에 따라 달라진다. 도색 기업에는 색깔이, 물류 기업에는 크기와 적재 가능한 물건의 종류가 중요하며, ‘비었다’는 표현도 완전히 비어 있는 상태인지 여유 공간이 많은 상태인지 속성에 근거해 정의해야 한다. [20:04]

11. 온톨로지를 AX의 만능 공식으로 보는 접근의 한계

• AI와 AX에 대한 뒤처짐의 불안이 커지면서 온톨로지가 마케팅 용어처럼 확산됐다는 해석이 나온다. AX의 핵심은 기업이 풀 문제를 명확히 하고 AI로 해결하는 것이지만, 특정 프레임워크를 도입하면 정답을 얻을 수 있다고 여기는 경향이 있다는 지적이다. [21:38]
• 다른 관점에서는 회사마다 고유한 맥락이 있으므로 조직에 맞게 합의된 결과를 얻으려는 수요가 온톨로지의 관심을 키웠다고 본다. 조직에 맞춘 디지털 트윈이나 업무를 돕는 주체를 구현하는 수단으로 기대한다는 해석이다. [22:49]

12. 다른 사람이 그대로 수행할 수 있는 업무 설명부터 시작

• 온톨로지의 가치는 조직의 언어를 정하는 과정에도 있다. 담당자가 알아서 처리하던 암묵지를 명시적인 규칙과 예외 상황의 대응 방식으로 표현하면서 조직의 AI 활용 역량도 높아질 수 있다고 본다. [23:48]
• 구축 초기부터 엄격한 객체를 만들기보다 각자의 업무를 다른 사람이 그대로 수행할 수 있을 만큼 자세히 서술한다. 이후 공통 개념을 찾고, 서로 다른 의미로 쓰던 ‘고객’ 같은 용어를 구분하면서 정의를 다듬는다. [24:17]

13. 프리온톨로지는 최종 합의를 대신하지 않는 준비 단계

• 프리온톨로지가 곧 온톨로지가 되는 것은 아니라는 입장이다. 조직이 앞으로 어떤 개념을 어떻게 부를지는 본인이나 의사결정자가 확정해야 하므로, 온톨로지 구축에는 사람의 최종 결정이 필요하다고 본다. [25:32]
• ‘프리온톨로지’는 대화 기록 서비스가 제공할 수 있는 가치를 표현하려고 만든 말이며, 어느 정도 마케팅 의도가 있었음을 인정한다. [26:01]

14. 대화의 관계와 출처를 조직 정의의 근거로 활용

• 대화를 자산화하려면 전체 자막이나 요약을 그대로 넣는 것만으로는 부족하다. 누가 어느 조직과 언제 어떤 관계로 대화했는지, 원래 근거가 어디에 있는지 같은 최소한의 관계 정보가 필요하다. [27:00]
• 관계 정보가 있으면 자신이 참여하지 않은 대화에서도 특정 개념이 조직 안에서 어떻게 쓰이는지 이해할 수 있다. 티로 내부에서도 온톨로지를 구축할 때 대화 기록을 적극적으로 활용한다. [27:31]

15. YAML 저장소의 지속적인 갱신과 작은 팀의 운영 한계

• 실제 온톨로지는 엔지니어링·그로스 등 여러 도메인을 담은 하나의 저장소이며 계속 바뀐다. 엄격한 규칙을 완성하기보다 사람과 에이전트가 이해할 수 있게 업무를 나누는 데 초점을 두고, YAML 스키마에 B2B MRR의 설명과 조회 쿼리 같은 규칙을 담는다. [28:12]
• 구성원과 에이전트 모두 규칙의 추가·폐기 필요에 따라 업데이트와 PR을 만든다. CTO는 일주일에 한 번 전체 린트를 돌리고 있다. [29:01]

16. 에이전트의 신뢰는 판단 근거와 일상적인 검수에서 나온다

• 계약서 수정과 보안 검토를 수행하는 에이전트는 사용한 도구·위키·스킬과 판단 기준, 온톨로지를 참고해 결론에 도달한 기록을 남긴다. 이 로그가 결과를 검증할 근거가 된다. [30:03]
• 자율적으로 행동하는 에이전트를 신뢰하려면 정해진 환경과 샌드박스 안에서 작동한다는 보장이 필요하다. 한두 번의 성공만으로 실행을 100만 단위로 확대하면 사고 가능성이 크게 높아질 수 있다는 우려가 나온다. [30:42]

17. 조직의 속도를 높이려면 사람의 사고 역량을 키워야 한다

• 같은 거리를 시속 100km와 1km로 나누어 달리면 평균 속도는 약 1.98km에 그친다. 빠른 쪽을 무한히 가속해도 전체 속도는 약 2km에 머문다는 조화평균의 예시로, 느린 단계가 전체 성과를 제한하는 문제를 보여준다. [32:17]
• 조직에서 느린 단계는 사람일 수 있으므로, 에이전트 튜닝과 실행 환경 개선만큼 팀원의 사고 능력과 문제 정의 능력을 높이는 투자가 중요하다. [32:49]

18. 개인별 에이전트가 책임과 개선 동기를 만든다

• CS·B2B 같은 기능별 에이전트는 소유권과 권한 관리가 모호해지고 별도 관리 직무를 만들 수 있다. 자신을 대신하는 개인별 에이전트를 두면 개선 책임이 명확해지고, 동료의 에이전트와 비교하며 더 잘 만들려는 동기도 생긴다. [33:34]
• 동료를 불렀을 때 그 사람의 에이전트만으로 대화가 해결되는지가 성능을 체감하는 기준이 된다. 작은 팀에서는 이런 경험을 바탕으로 서로의 운영 방법을 묻고 공유한다. [34:31]

19. 공용 온톨로지는 엄격하게 관리하고 개인 에이전트는 격리한다

• 중앙 온톨로지는 구성원이 PR로 수정할 수 있지만 회사의 공용 규칙이므로 엄격하게 관리한다. 주기적으로 규칙 위반을 검사하고, 온톨로지용 린트도 만들어 점검한다. [35:29]
• 개인 에이전트는 서로 격리해 하나가 고장 나도 다른 에이전트에 영향을 주지 않도록 한다. 기본적으로 소유자가 직접 고치고, 해결하기 어려울 때 도움을 받는다. [35:55]

20. 보안 투자와 인증이 B2B 도입의 문턱을 낮춘다

• 민감한 정보를 다루는 제품은 성능이 좋아도 보안과 개인정보 관련 조건을 충족하지 못하면 기업에 도입되기 어렵다. 안정적인 매출 기반과 더 큰 기회를 위해 B2B가 필요했기 때문에 보안 검토에 일찍 투자했다. [36:29]
• 한국과 일본의 기업 고객을 상대할 때는 보안 역량을 개별적으로 설명하며 협의를 반복해야 했다. SOC 2와 ISO 인증 취득 이후에는 인증 자체가 기본적인 신뢰를 형성하는 데 도움이 됐다. [37:49]

21. 대화 자산화는 안전한 저장과 자유로운 활용을 함께 요구한다

• 대화가 자산이 되려면 안전하게 저장할 수 있고, 가치를 만들 때 꺼내 쓸 수 있어야 한다. 아직은 저장만 잘해도 비용을 지불하는 고객이 많으며, 이 시장이 초기 수용자에서 초기 다수 수용자로 넘어가는 단계라는 판단이다. [39:04]
• 사내 대화를 고객이 원하는 보고서나 표로 바꾸어 컨플루언스·구글 드라이브 같은 저장소에 넣어 주는 제안만으로도 반응이 있다. 최근에는 축적한 대화를 에이전트에 제공하거나 지식 기반을 구축하려는 관심도 커지고 있다. [39:35]

22. 티로 위키는 에이전트가 필요한 맥락을 찾는 인덱스다

• 에이전트에 필요한 것은 전체 대화록보다 특정 인물이 맡은 프로젝트와 연결된 사람·기업 같은 관계 정보다. 일반 노트를 전부 가져오면 토큰 사용과 환각이 늘 수 있어, 인물의 위키 페이지에서 관련 개념을 함께 찾는 구조를 활용한다. [40:18]
• 기록한 대화를 CLI·MCP·API 등 원하는 방식으로 검색하고 가져갈 수 있게 하며, 높은 검색 품질과 적은 토큰 사용을 제품 가치로 제안한다. [40:52]

23. 인공위성에 대한 관심과 생산성 이후의 가치 탐색

• 여울의 인공위성 관심에는 개인적인 낭만과 팔란티어 협력 기업을 살펴본 경험이 함께 작용했다. 특히 ‘검색 가능한 지구’라는 비전에 흥미를 느껴, 이미 떠 있는 위성의 신호를 직접 받아보는 일부터 시작하려 한다. [42:29]
• 약 72cm 안테나와 동글을 구입했으며, 신호 수신과 해석이 가능해지면 송신을 시도하고 이후 직접 위성을 만들어 띄우려는 구상을 갖고 있다. [43:19]

24. 에이전트가 고객이 되는 미래와 팀의 학습 방향

• 여울은 아직 내부 합의가 없는 개인적인 구상임을 전제로, 에이전트가 주요 사용자가 되는 미래를 예상한다. 에이전트가 티로에서 소비할 대상은 축적된 대화 자산일 수 있으므로, 이를 활용할 수 있는 좋은 인터페이스와 도구를 제공하려 한다. [45:16]
• 팀의 방향은 제품 성장뿐 아니라 티로를 통해 무엇을 배우고 다음에 무엇을 추구할지에도 연결된다. 구성원들이 철학자의 ‘철인’에 가까워지는 방향을 조직의 지향점으로 생각한다. [46:08]

25. 회의록에서 기업의 맥락을 보존하는 도구로 확장한다

• 현제는 향후 1~2년의 전환을 사람이 읽는 회의록에서 에이전트가 읽는 회의록으로의 이동으로 본다. ‘Now your agent works’라는 문구에는 대화 맥락을 이해해 뻔하고 보편적인 답변을 넘어서는 에이전트를 지원하겠다는 방향이 담겨 있다. [47:01]
• 에이전트 활용이 널리 보편화된 단계는 아니며, 그 시대가 다가오는 중이라는 판단이다. 티로는 향후 1~2년 동안 기업에서 휘발되던 맥락을 보존하고 에이전트가 이해하도록 돕는 도구로 빠르게 자리 잡으려 한다. [47:44]

🧾 결론

• 온톨로지의 가치는 조직이 같은 용어와 판단 기준을 공유하고, 그 기준을 실제 실행에 연결하는 데 있다.
• 티로의 방식은 엄격한 온톨로지를 완성한 사례라기보다 작은 팀이 업무 규칙을 계속 다듬는 운영 사례로 읽는 것이 적절하다.
• 대화 기록에서 맥락을 추출해도 조직의 합의가 자동으로 만들어지지는 않는다. 프리온톨로지는 사람이 정의를 결정하도록 돕는 준비 단계다.
• 개인별 에이전트의 개선 책임을 명확히 하고 사람이 검수와 학습을 이어가는 구조가 자동화 확대의 기반이다.

📈 투자·시사 포인트

• AI 제품을 평가할 때 모델 성능뿐 아니라 고객의 실제 사용 행동, 인터페이스, 후속 업무와의 연결을 살펴볼 필요가 있다. 티로는 이런 요소를 차별화의 중심으로 설명한다.
• 기업 시장에서는 보안과 개인정보 조건이 도입 가능성을 좌우한다. 티로 사례에서 SOC 2와 ISO 인증은 기업 고객과 기본적인 신뢰를 형성하는 데 도움이 됐다.
• 대화 자산의 활용 범위는 사람이 읽는 회의록에서 에이전트용 맥락 검색으로 넓어질 수 있다. 다만 에이전트가 주요 사용자가 된다는 전망은 내부 합의가 없는 개인 구상도 포함한다.
• 자동화의 사업적 효과를 판단하려면 처리량과 함께 검수 부담, 오류, 규칙 유지 비용을 확인해야 한다. 제목의 매출 수치만으로 온톨로지 도입의 수익 효과를 입증할 수는 없다.

⚠️ 불확실하거나 확인이 필요한 부분

• 제목의 ‘연매출 40억’은 본문에서 산정 기간, 인식 기준, 검증 자료가 제시되지 않는다. 온톨로지나 에이전트 운영이 해당 매출을 만들었다는 인과관계도 확인되지 않는다.
• 회사의 약 98%를 AI로 시뮬레이션한다는 설명은 장기 목표다. 현재 달성한 자동화율이나 정량적 생산성 개선 수치로 해석하면 안 된다.
• 위키 인덱스가 검색 품질을 높이고 토큰 사용과 환각을 줄인다는 설명에는 정량적 비교 결과가 제시되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 담당자를 기다리느라 지연되는 업무 하나를 골라 필요한 데이터, 판단 기준, 예외 처리와 승인 조건을 문서화한다.
• ‘고객’, ‘장애’, 국가별 MRR처럼 해석이 갈리는 용어를 모으고, 관련 대화 기록과 출처를 확인한 뒤 책임자가 정의를 확정한다.
• 개인의 행동 특성, 업무 지식, 회사 공용 규칙을 구분하고 공용 규칙의 변경·검토 담당자를 정한다.
• 계약·환불·상태 변경처럼 중요한 작업에는 요청자 권한 확인과 사람의 검수 절차를 두고, 판단 근거를 일상적인 업무 대화에서 확인할 수 있게 한다.

❓ 열린 질문

• 어떤 기준으로 위키의 업무 지식을 반드시 지켜야 하는 온톨로지 규칙으로 승격하고, 오래된 규칙은 누가 폐기할 것인가?
• 팀이 커질 때 공용 규칙의 합의와 검토를 어떻게 나눠 CTO에게 집중된 운영 부담을 줄일 수 있을까?
• 개인별 에이전트의 책임 구조는 담당자 이동이나 퇴사 이후에도 어떻게 유지할 수 있을까?