36
이 글은 [조쉬의 뉴스레터]에서 발행됩니다.
퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 받아보세요.
한국 기업의 MRR(월 반복 매출)은 얼마일까요? 티로 팀 안에서 이 질문에 답이 달랐어요. 일본에서 결제한 고객을 어느 국가 매출에 넣을지 기준이 정해져 있지 않았거든요. 같은 지표를 이야기하면서 서로 다른 숫자를 보고 있던 거죠.
티로는 이렇게 답이 엇갈리면 안 되는 말부터 정의합니다. 무엇을 기록하고, 어떻게 판단하고 실행할지, 누가 접근할 수 있는지까지 공통 규칙으로 묶어요. 여울 님이 티로에서 사용하는 ‘온톨로지’예요. 사람과 AI가 같은 기준으로 일하기 위한 회사의 공통 언어에 가깝습니다.
2026년 8월 더벨이 연간 매출 40억 원 규모로 보도한 티로. 이번 HOW I AI PODCAST에서는 운영사 더플레이토의 공동창업자이자 CTO 여울 님, AX와 B2B 세일즈·BD를 담당하는 현제 님을 만났어요. 회의 기록과 개인 에이전트가 이 공통 규칙에 어떻게 연결되는지 들었습니다.
대화를 자산으로 만드는 티로
Q. 먼저 두 분 소개와 티로 소개 부탁드려요.
여울 | 티로를 만드는 더플레이토의 공동창업자이자 CTO 김상철이에요. 회사 안에서는 영어 이름을 쓰는데, 저는 여울이라는 이름으로 활동하고 있어요.
현제 | B2B 세일즈와 사업 개발, BD를 맡고 있는 박현제예요. 티로에서는 레오라는 이름을 쓰고 있고요. 지금은 AX와 B2B 쪽 업무를 많이 담당하고 있어요.
여울 | 티로는 실시간으로 대화를 기록하고, 필요하면 15가지 이상의 언어로 번역해주는 서비스예요. 번역 이후에는 조직이나 개인이 원하는 형태의 문서도 만들어요. 그다음에는 슬랙이든 MCP든 CLI든 원하는 방식으로 공유할 수 있고요. 대화 기록부터 활용까지 통합된 워크플로를 지원한다고 보시면 돼요.
기업마다 필요한 게 달라요. 어떤 곳은 회의록 자체가 필요하고, 어떤 곳은 그 회의록을 어떻게 활용할지가 더 중요하거든요. 그래서 만나는 분에 따라 AI 회의록 서비스라고 소개하기도 하고, 대화를 자산으로 만드는 서비스라고 설명하기도 해요.
사람을 부르면 그 사람의 AI가 먼저 답해요
Q. 지금 티로의 팀원들은 AI를 어떻게 쓰고 있나요?
여울 | 작년 11월쯤 프로젝트 매크로하드를 시작했어요. 고객을 직접 만나 목소리를 듣는 일 외에는 많은 업무를 AI로 시뮬레이션할 수 있지 않을까 생각했죠. 팀의 인원은 적었지만, 각자의 역할과 맥락을 가진 개인 에이전트를 만들기 시작했어요.
지금은 팀원이 약 12명이고 각 개인을 대신하는 에이전트가 있어요. 제가 레오에게 일을 부탁하면 레오의 에이전트인 미오가 먼저, 레오가 했을 법한 답변과 해야 할 일을 알려줘요. 답이 맞으면 그대로 쓰고, 틀리면 레오가 확인해 고쳐요.
개발, 장애 모니터링과 원인 분석, 고객의 이전 이메일과 레퍼런스를 참고한 답장 초안 같은 일에도 에이전트가 들어가 있어요. 사람이 자리를 비워도 그 사람이 쌓아온 업무 맥락은 회사에서 계속 꺼내 쓸 수 있게 만드는 거예요.
Q. 동료가 아니라 동료의 에이전트에게 묻는 방식은 어떻게 나오게 됐나요?
여울 | 팀원 한 분이 다른 시간대에서 생활하게 됐어요. 중요한 B2B 업무를 담당하고 있어서 그분의 의견이 없으면 진행하기 어려운 일이 있었거든요. 회사 입장에서는 병목이죠. 그 사람이 할 법한 일을 대신하는 존재를 만들어서 병목을 풀어야겠다는 생각에서 출발했어요.
그 일에는 업무 규칙이 있고, 봐야 하는 데이터가 있고, 일반적인 지능이 있으면 할 수 있는 부분이 있어요. 사람도 고유한 경험을 가진 주체가 특정 조직의 규칙을 지키며 일을 하는 거잖아요. 그 요소들을 잘 분리해서 부여하면 사람과 비슷하게 행동하게 만들 수 있지 않을까 생각했어요.
꼭 그 사람이 깨어 있어야만 질문할 수 있는 상태에서 벗어나고 싶은 거예요. 물론 틀린 답을 할 수 있으니 본인이 확인하고 고치는 과정은 남아 있어요. 처음부터 사람을 완벽하게 대체했다기보다, 사람이 하던 역할을 조금씩 에이전트에 옮기는 방식에 가까워요.
Q. 개인을 대신하는 에이전트는 어떤 구성으로 만드나요?
여울 | 레오의 에이전트는 미오이고, 저는 여울이니까 겨울이에요. 미오의 소울을 정의할 때는 레오의 6개월에서 1년 정도 슬랙 메시지를 여러 에이전트에 통과시켜 SOUL.md를 만들어요. 말투나 언제 개입하는지 같은 특성이 들어가요.
그다음에는 평소 소비하는 데이터가 있어요. 관심사에 따라 보는 정보도 있고, 대화할 때 티로에 남기는 기록도 있죠. 그 대화 기록은 CLI 같은 도구로 연결해서 LLM 위키에 넣어요. 개인이 알고 있는 내용과 계속 쌓이는 맥락을 담는 거예요.
그리고 그 사람이 누구인지와 무관하게 회사에서 지켜야 하는 규칙이 있어요. 고객에게 어떤 기준으로 응대하고 B2B 세일즈는 어떻게 해야 하는지 같은 내용이죠. 그건 회사 공용 온톨로지 레이어에 둬요. 소울, 위키, 회사 공통 규칙. 세 가지를 조합하면 개인 단위로 에이전트를 부여해도 효율적으로 동작하는 것 같아요.
일본 고객의 메일부터 CTO의 아침 브리핑까지
Q. 현제 님의 에이전트 미오는 구체적으로 어떤 일을 하나요?
현제 | 지금은 AX와 B2B 세일즈를 많이 담당하지만, 티로에서 쌓인 업무 맥락 중 큰 부분은 일본 B2B예요. 그동안 나눈 대화, 일본어 메일, 작성한 계약서 같은 내용이 미오에게 들어가 있어요.
외국어 메일은 내용뿐 아니라 톤이 중요하잖아요. 일반적인 AI로 다른 분들이 메일을 만들면 그대로 믿지 못하고 저에게 맞는지 다시 물어보는 과정이 있었어요. 그 규칙을 미오에게 정의해준 거예요. 고객에 따라 어떻게 답하는 게 좋을지, 일본어의 촘촘한 경어 체계에서 어떤 매너를 쓰면 좋을지 제안하고 바로 보낼 수 있는 형식으로 만들어줘요.
결제나 계약, 보안 관련 대응도 한국 기업과 다른 부분이 있어요. 그런 데이터가 쌓여 있으니 제가 담당 업무에서 빠져도 미오를 호출해서 어떻게 대응하면 되는지 알아볼 수 있어요. 다른 동료가 일본 쪽 비즈니스에 집중하고 저는 한국 쪽에 집중하게 됐는데, 제가 일일이 설명하지 않아도 미오에게 물어서 해결하는 방식으로 진행하고 있어요.
Q. 여울 님의 에이전트 겨울은 어떤 일을 하나요?
여울 | 회사에서 제 권한이 많은 편이라 무엇을 하면 안 되는지부터 정리하는 데 시간을 썼어요. 쿼리를 실행하거나 상태를 바꾸고 환불하는 요청은 누가 요청했는지 슬랙 ID를 보고 거르도록 해뒀어요.
팀의 업무를 수행하는 역할과 제 개인 비서 역할이 있는데, 개인 비서로는 새벽 5시에서 6시 사이에 리포트를 두세 개 보내줘요. 제가 자는 동안 회사에서 어떤 일이 있었는지와 참고 자료를 알려주죠. 오늘 캘린더에 있는 일정과 만날 사람도 가져와요. 지난 미팅의 티로 노트를 보고 어떤 이야기를 했으니 오늘은 무엇을 준비해 가야 한다고 브리핑해요.
팀 차원에서는 보안 인증을 받으면서 정기적으로 해야 하는 업무가 생겼어요. 권한 점검이나 감사 보고서 작성 같은 일이요. 어느 주기에 어떤 규칙과 흐름으로 진행할지 온톨로지에 넣어두고 겨울과 연결해요. 정기 실행을 통해 정책을 점검할 때가 됐다고 알려주는 식이에요.
여울 | 큰 기업의 보안성 검토는 160개, 200개 항목에 이르기도 해요. 비슷한 내용을 다른 표현으로 묻는 경우가 많아서 회사 온톨로지의 정의를 연결하고 필요한 경우 번역해 초안을 만들어요. 저는 틀리거나 더 넣어야 할 부분을 확인하고요.
법률 검토도 같은 방식으로 준비해요. 내용을 충분히 이해한 뒤 변호사에게 초안과 함께 자문을 요청합니다. 에이전트가 결론을 대신 내리는 게 아니라, 전문가가 더 중요한 판단에 시간을 쓰도록 준비하는 역할이에요.
슬랙 봇과 클로드, 코덱스, 터미널을 섞어서 써요. 인터페이스는 달라도 회사가 따라야 하는 규칙을 읽거나 업데이트할 때는 한 곳의 티로 온톨로지를 거치도록 했어요.
반면 LLM 위키는 개인의 세션과 에이전트마다 달라요. 각자 필요한 지식은 다르게 갖되, 회사가 함께 지켜야 할 규칙은 같은 곳을 보는 구조예요.
모든 지식을 온톨로지로 만들 필요는 없어요
Q. 티로에서 말하는 온톨로지는 어떤 개념인가요?
여울 | 저희가 엄격한 의미의 온톨로지를 그대로 지키고 있느냐고 하면, 일단 아니라고 말씀드리고 싶어요. 제가 참고하는 건 팔란티어에서 정의한 개념인데, 크게 데이터, 로직, 액션 세 가지와 그 위의 감사, 권한으로 구성된다고 생각해요. 무엇을 기록하고 어떤 판단을 내리며 무엇을 실행하는지, 로그를 잘 남기는지, 누가 접근할 수 있는지까지 다섯 요소예요.
온톨로지가 필요한지 볼 때는 이걸 절대로 틀려서는 안 되는지부터 생각해요. 엄격하게 정의할 수 있는 명확한 워크플로와 언어가 존재하는지, 그걸 기술해낼 수 있는지도 중요하고요. 이메일을 써달라는 요청을 전부 온톨로지로 넣는 건 잘 상상이 안 돼요. 유연한 결과가 오히려 도움이 될 때도 있잖아요.
반면 발주를 넣거나 계약서에 금액을 쓰는 행위는 내용이 바뀌면 안 돼요. 조직의 서로 다른 사람들이 같은 질문에 다른 이야기를 해서도 안 되고요. 그런 것들을 골라 온톨로지로 정의하려고 해요. 모든 일을 엄격한 규칙으로 만드는 게 목적은 아니에요.
Q. 실제로 어떤 언어부터 정의하게 됐나요?
여울 | 서로 다르게 말했을 때 문제가 생기는지를 기준으로 봤는데, 저희에게는 MRR을 측정하는 기준이었어요. 한국 기업의 MRR이 얼마냐고 물었을 때 서로 다른 답을 하고 있었거든요.
일본 사람이 일본에서 결제하고 팀에 들어온 경우는 일본 매출이라고 볼 수 있을 것 같아요. 그런데 한국에서 일본인이 도입한 뒤 일본 팀원 열한 명을 데려왔다면 일본 MRR일까요, 한국 MRR일까요? 그런 기준이 정해져 있지 않았어요. 같은 지표를 말하지만 정의가 달랐던 거죠.
그런 모호한 언어를 정의하는 게 출발점이었어요. 정의한 내용을 반드시 지켜야 하는 규칙으로 만드는 게 정말 가치가 있다면 온톨로지로 올릴 준비를 해요. 그렇지 않다면 프롬프트에 들어가 있는 정도로 충분할 수도 있어요. 어디까지 엄격하게 관리할지를 나누는 거예요.
Q. 데이터, 로직, 액션을 좀 더 쉬운 예로 설명해주실 수 있나요?
여울 | 창고를 예로 들어볼게요. 창고를 칠하는 회사라면 색깔이 중요하겠죠. 그런데 창고에 물건을 쌓아 판매하는 물류 회사라면 색보다 크기와 넣을 수 있는 물건의 종류가 중요해요. 같은 창고라도 조직에 따라 필요한 데이터가 달라지는 거예요.
그다음은 로직이에요. 아무것도 없어야 비었다고 할 수도 있고, 많이 들어갈 수 있는데 한두 개밖에 없으니 비었다고 할 수도 있어요. 우리 조직에서 비었다는 말이 정확히 무엇을 뜻하는지 데이터의 속성을 가지고 정하는 거죠. 액션은 그다음이에요. 비었으면 무엇을 해야 하는지, 어떻게 채울지를 정해요.
그냥 알아서 창고를 채우라고 하는 말이 얼마나 불친절한 지시인지, 이런 정의를 하다 보면 알게 돼요. 창고를 채우고 비우는 일이 중요한 회사라면 규칙이 강제돼야 하고, 아무나 물건을 넣거나 빼면 안 되니 권한 관리가 필요해요. 나중에 누가 접근했는지도 찾아볼 수 있어야 하고요.
그 다섯 가지 요소를 다 갖춰야 할 만큼 중요한 언어라면 온톨로지로 정의하려고 해요. 그렇지 않다면 LLM 위키와 충분히 똑똑한 모델로도 해결할 수 있지 않을까 생각해요.
Q. 요즘 온톨로지에 관심이 몰리는 현상은 어떻게 보고 계세요?
현제 | 마케팅 용어처럼 쓰이는 느낌도 있어요. AI와 AX에 대한 조급함이 커지면서 정답이 있다고 생각하는 것 같거든요. 특정 프레임워크를 회사에 도입하면 문제가 해결될 거라고 보는 거예요.
제 생각에 AX에서 가장 중요한 건 기업이 풀어야 할 문제를 명확히 정의하고, 그 문제를 AI로 어떻게 풀 것인지 정하는 일이에요. 온톨로지의 뜻을 이해하고 우리 회사가 풀고 싶은 문제에 맞게 만들면 괜찮아요. 그런데 그 자체를 하나의 공식이나 해답처럼 받아들이는 분위기 때문에 더 많이 퍼진 면도 있지 않을까 생각해요.
여울 | 온톨로지의 가치 중 하나는 언어를 정하는 과정 자체에서 나와요. 암묵적으로 알아서 하던 일을 말로 표현해야 하거든요. 그냥 받아서 처리하면 되는 일이었다면, 어떤 규칙으로 처리했는지, 다른 상황에서는 어떻게 해야 하는지까지 설명해야 해요.
처음부터 엄격한 객체 형태일 필요는 없어요. 각자 하는 일을 다른 사람이 그대로 수행할 수 있을 만큼 자세하게 적어보는 거예요. 그러면 공통 개념이 보이고, 내가 말하는 고객과 동료가 말하는 고객이 다르다는 것도 드러나요. 그 과정에서 개념을 나누고 정리해요.
기술적인 구축 자체보다 중요한 건 그 정의예요. 기술적으로는 감사 기록을 어떻게 남길지, 접근 권한을 어떻게 둘지 등을 고민하고요. 업무 규칙은 이런 질문으로 생각해요. 정말 똑똑하지만 이 도메인을 모르는 팀원에게 문서 하나를 주고 한 달 동안 휴가를 떠난다면, 마음이 편하려면 무엇이 적혀 있어야 할까요? 그걸 먼저 정의하는 게 저희 접근이에요.
Q. 티로가 말하는 프리온톨로지는 무엇인가요?
여울 | 프리온톨로지는 온톨로지 자체가 아니에요. 온톨로지는 앞으로 어떤 개념을 어떻게 부르고 적용할지 의사결정자가 정해야 하거든요. 대화 기록은 그 결정을 자동화하는 답이 아니라, 규칙을 정하기 직전의 재료예요.
코딩 에이전트가 먼저 두각을 나타낸 배경에는 많은 컨텍스트와 하네스가 있었다고 봐요. 예시 코드가 많고 코드베이스와 규칙을 넣어주며, 잘 실행됐는지처럼 성공 여부도 비교적 쉽게 정의하잖아요. 비즈니스 영역에서도 그런 맥락과 규칙이 필요한데, 그 재료를 대화 기록이 제공할 수 있다고 생각했어요.
Q. 대화가 실제로 온톨로지를 만드는 데 어떻게 쓰이나요?
여울 | 대화를 자산화해 필요한 시점에 맥락으로 넣는 게 저희가 줄 수 있는 가치예요. 전체 스크립트나 요약본만으로는 부족해요. 어떤 사람과 조직이 언제 어떤 관계로 대화했고, 참고할 원본이 어디 있는지 같은 최소한의 관계가 필요해요.
그 관계를 제공하면 대화에 참여하지 않은 사람도 어떤 개념이 조직 안에서 어떻게 쓰이고 있는지 이해할 수 있어요. 저희도 온톨로지를 만들 때 티로를 많이 활용해요. 장애라는 말을 어떻게 정의하고 있는지 궁금하면 관련된 대화를 쭉 뽑아보는 거예요.
서버 문제뿐 아니라 고객 CS로 들어온 문제도 장애라고 부르기로 한 맥락이 있다면, 그 대화까지 찾아 정의에 반영할 수 있어요. 대화 기록이 합의를 대신하는 게 아니라, 합의에 필요한 맥락을 찾아주는 거예요.
Q. 실제 온톨로지 화면은 어떤 모습이고, 어떻게 업데이트하나요?
여울 | 저장소 하나예요. 엔지니어링이나 그로스처럼 여러 도메인이 있고 계속 바뀌어요. 엄격한 규칙부터 갖추기보다 팀원들이 자신의 업무 규칙을 에이전트나 다른 사람이 이해할 만큼 잘 나눠뒀는지를 먼저 보고 있어요.
내용은 YAML로 돼 있어요. 스키마가 있고, B2B MRR 같은 개념을 정의하면 설명과 어떤 쿼리로 값을 가져오는지 같은 규칙이 들어가요. 규칙들의 모음이라고 보시면 돼요. 에이전트가 직접 업데이트하기도 하고, 개인이 새 규칙을 추가하거나 더 이상 쓰지 않을 규칙을 바꾸기도 해요. 그래서 PR이 생각보다 많아요.
저는 일주일에 한 번씩 전체 린트를 돌려요. 공동창업자이자 CTO로서 회사에서 일어나는 오작동을 이해해야 하니까요. 지금 운영 방식은 작은 팀이어서 가능한 면도 있는 것 같아요. 여기서 노하우를 쌓으면서 조금 더 엄격한 방식으로 넘어가려는 중이에요.
에이전트를 믿으려면 근거가 일하는 화면 안에 보여야 해요
Q. 에이전트의 답변을 어떤 근거로 신뢰하시나요?
여울 | 겨울이 계약서나 보안 검토 요청을 처리할 때 어떤 도구와 위키를 가져왔고, 어떤 규칙으로 결론을 냈는지 남겨요. 결과만 보여주는 게 아니라 근거와 경로를 함께 보여주는 거죠.
일반적인 지능은 많은 영역에서 저보다 뛰어날 수 있다고 생각해요. 그래도 실제로 필요한 근거를 가져왔는지 한 번씩 검증해요. 에이전트가 자율적으로 행동할 때 믿을 수 있으려면, 특정 환경과 경계 안에서만 움직이고 있다는 믿음이 있어야 하거든요.
한두 번 잘하는 걸 보고 아주 큰 규모로 늘리면 문제가 생길 수 있어요. 잘했던 몇 번의 인상만으로 맡기기보다는 어떤 도구를 썼고 어떤 규칙 안에서 동작했는지 확인할 수 있게 만드는 게 중요해요.
평가하는 사람도 더 뛰어나져야 한다는 철학이 있어요. 로그를 관리자 화면에 쌓아두고 가끔 확인하라고 하면 잘 보지 않게 되거든요. 그래서 슬랙처럼 실제로 일하는 화면 안에 답변과 근거를 함께 보여줘요.
모든 답변을 전수 검토하지는 않아요. 다만 이상한 내용은 동료가 지나가다 발견할 수 있고, 계약처럼 반드시 확인해야 하는 대화는 사람이 챙겨보게 해요. 검토를 별도 업무로 떼기보다 일하는 흐름 안에 넣는 방식이에요.
Q. AI가 빨라지면 조직의 성장 속도는 어디에서 막힐까요?
여울 | 최근에 조화평균이라는 개념을 다시 생각했어요. 같은 거리를 이어 달리는데 앞 주자는 시속 100km, 뒤 주자는 시속 1km로 달린다고 해볼게요. 평균 속도는 약 1.98km예요. 빠른 주자를 아무리 더 빠르게 해도 전체 속도는 시속 2km 언저리에서 크게 달라지지 않아요.
반면 느린 주자를 시속 10km, 50km로 만들면 그때부터 전체 속도가 달라지죠. 저희 조직에서는 그 느린 주자가 사람일 수 있다고 생각해요. 에이전트를 더 튜닝하고 하네스를 개선하는 것도 중요하지만, 사람의 판단이 느리면 거기서 막히는 거예요.
그래서 팀원의 사고 능력과 문제를 정의하는 능력을 기르는 데 많이 투자해요. 성과 평가에서도 중요한 기준이고요. 어떤 루프를 돌다가 실패할 수는 있어요. 그런데 그 과정을 통해 무엇을 배웠는지가 중요해요. 실패했어도 배운 게 있으면 괜찮지만, 배운 게 없다면 아쉬운 거죠.
Q. 개인 단위의 에이전트가 조직 문화에는 어떤 영향을 주나요?
여울 | CS나 B2B 같은 기능별 봇 대신 개인 단위로 만든 건 문화적으로 중요한 결정이었어요. 기능별로 나누면 책임과 권한이 흐려질 수 있지만, 자기 에이전트는 자기를 대신하는 존재라 직접 개선할 이유가 생겨요.
레오의 에이전트는 잘하는데 내 에이전트는 왜 이럴까 생각하면서 더 잘 만들게 돼요. 잘 만들수록 내 일이 줄어드니 인센티브도 맞고요. 고장 나면 본인이 고치고, 어렵다면 도움을 요청해요.
미오가 고장 나도 겨울까지 고장 나지는 않도록 격리해뒀어요. 고장 나면 본인이 고치고, 어렵다면 저에게 도움을 요청해요. 반면 온톨로지는 회사의 공용 규칙이니 좀 더 엄격하게 봐요. 개인이 책임질 부분과 공동으로 관리할 부분을 나누는 거예요.
같이 일하면 다른 사람의 에이전트가 잘하는 방식이 보여요. 격주에는 각자가 회사에서 자기 역할을 어떻게 20%씩 덜어내고 있는지 나누고, 공통으로 좋은 패턴은 회사 규칙에 반영해요.
공통 온톨로지에는 팀원들이 PR을 올려요. 저는 일주일에 한 번 규칙이 어긋나는지 점검하고, 최근에는 온톨로지용 린트도 만들었어요. CI에서도 몇 가지를 체크하죠. 개인 에이전트는 각자가 개선하고, 공통 규칙은 함께 관리하는 구조예요.
B2B에서는 안전하게 저장하고 꺼내 쓸 수 있어야 해요
Q. 보안에 대한 투자를 일찍 결정한 이유가 무엇인가요?
여울 | 두 가지가 있었어요. 먼저 제품 특성상 민감한 정보를 다룰 수밖에 없어요. B2C에서는 제품이 좋으면 쓰자는 반응이 나오지만, B2B는 안 쓸 이유가 없어야 쓰는 쪽에 더 가까운 것 같아요. 제품이 괜찮아도 보안성 검토나 개인정보 처리 조건을 만족하지 못하면 도입이 안 되는 거죠.
저희가 안정적인 매출 기반을 다지고 더 큰 기회를 얻으려면 B2B를 해야 했어요. 그러려면 보안성 검토를 먼저 준비해야겠다고 판단해서 비교적 빠르게 투자를 결정했어요. 제품을 잘 만드는 일과 별개로, 고객 조직이 안심하고 도입할 수 있는 조건이 필요했던 거예요.
Q. 실제 세일즈 현장에서는 보안 인증이 어떤 차이를 만들었나요?
현제 | 보안의 세부 내용을 하나하나 설명하기에는 옆에 전문가가 계시지만, 가장 크게 달라진 건 인증인 것 같아요. 예전에는 한국이든 일본이든 고객에게 이것도 잘하고 저것도 잘한다고 설명하면서 계속 질문과 답변이 오갔어요.
SOC 2와 ISO 인증을 취득한 이후에는 그 사실을 말씀드리는 것만으로도 어느 정도 기본 신뢰를 가지고 이야기를 시작할 수 있었어요. 인증이 크다는 걸 느꼈죠. 그렇다고 보안성 검토가 전부 없어지는 건 아니고요.
추가 검토는 여울이 아니라 겨울에게 많이 물어요. 보안 관련 내용이 겨울에게 있으니까요. 이메일로 큰 엑셀 표가 오면 겨울에게 넘겨서 검토하게 하고, 여울 님이 한 번 더 확인하는 흐름으로 일해요.
Q. B2B 고객에게는 티로를 어떻게 제안하고 있나요?
여울 | 대화를 자산으로 만드는 제품이라고 설명하다 보니 자산의 조건을 생각하게 돼요. 안전하게 저장할 수 있어야 하고, 필요할 때 꺼내 가치를 만들 수 있어야 하잖아요. 저장과 검색, 활용이 함께 있어야 해요.
아직은 기록을 안전하게 저장하고 원하는 보고서나 표로 바꿔 컨플루언스, 구글 드라이브 같은 곳에 넣어주는 것만으로도 비용을 지불하는 고객이 있어요. 최근에는 그 기록을 에이전트의 지식 기반으로 활용하려는 기업도 늘고 있고요.
그래서 반드시 티로 안에서 모든 일을 하라고 말하지 않아요. 티로에서 안전하게 기록하고, 고객이 선택한 에이전트가 필요한 맥락을 꺼내 쓰게 하는 지갑 같은 역할을 생각하고 있어요.
Q. 티로 위키는 에이전트가 기록을 꺼내 쓰는 데 어떤 도움을 주나요?
여울 | 에이전트는 전체 대화 스크립트보다 누가 어떤 프로젝트를 맡았고 누구와 어떤 기업이 관련돼 있는지를 알고 싶을 수 있어요. 모든 노트의 텍스트를 가져오면 토큰을 많이 쓰고, 필요한 것과 다른 내용을 섞어 이해할 수도 있어요.
반면 특정 인물의 위키 페이지를 가져오면 그 사람에게 연결된 개념들을 볼 수 있어요. 필요한 관계를 따라갈 수 있으니 에이전트가 쓰기 좋은 형태가 되는 거예요. 위키는 그런 검색과 활용을 위한 개념이에요.
그래서 기록을 원하는 형태로 CLI, MCP, API에서 꺼낼 수 있다는 점을 말씀드려요. 기록 자체에서 끝나는 게 아니라 에이전트가 필요한 맥락을 가져다 쓸 수 있게 하는 거죠. 저희는 그 방식이 정확도뿐 아니라 토큰 사용 측면에서도 도움이 된다고 설명하고 있어요.
여울 | 큰 도서관에서 특정 책의 한 페이지를 찾는다고 생각해보세요. 충분한 시간과 지능이 있으면 찾을 수 있지만 색인이 있으면 더 빠르고 정확하죠. 위키는 LLM 시대의 인덱스예요. 관계와 색인을 따라가면 전체 회의록을 한꺼번에 읽지 않고도 필요한 맥락을 찾을 수 있어요.
AI가 일을 대신할수록, 사람이 남겨야 할 것
Q. 현제 님은 요즘 어떤 관심사나 고민이 있나요?
현제 | AI 시대에 제 가치를 어디서 찾아야 하는지 고민해요. 이전 회사에서 제가 하던 일을 AI가 하고, 저는 명령을 내리는 상황을 직접 보면서 먼 미래의 문제가 아니라고 느꼈어요.
그동안은 단위 시간에 얼마나 많은 일을 하고 회사에 얼마나 많은 가치를 만드는지가 기준이었어요. 그런데 그 일을 AI가 맡기 시작하면, 사람은 생산성 이외의 기준으로 자기 가치를 설명해야 하지 않을까요?
어떤 가치를 내세우면 스스로 납득할 수 있을지 생각하고 있어요. 업무를 에이전트에 남기는 일은 결국 사람이 무엇을 맡고 싶은지 다시 묻게 만들어요.
Q. 앞으로 티로는 어떤 방향으로 가게 될까요?
여울 | 제 개인적인 생각이지만, 에이전트가 주요 사용자가 되는 세계를 고민하고 있어요. 사람을 위한 화면만 만드는 게 아니라 에이전트가 회사의 기록과 맥락을 안전하게 소비할 수 있는 인터페이스가 필요해질 수 있거든요.
에이전트가 직접 대화를 녹음하러 오지는 않을 테니, 사람이 남긴 대화를 잘 모아 자산으로 만들고 필요한 주체가 꺼내 쓰게 해야 해요. 그 인터페이스를 어떻게 깔끔하게 만들지가 다음 고민이에요.
현제 | 회의록을 사람이 읽는 단계에서 에이전트가 읽는 단계로 넘어가고 있다고 봐요. 그래서 단순한 AI 회의록을 넘어, 기업에서 휘발되던 맥락을 보존하고 이해할 수 있게 해주는 도구라는 위치를 만들고 싶어요.
소중한 노력이 들어간 글을 널리 알려주세요.
이 기사가 좋으셨다면, 보상을 해주세요.
가장 좋은 보상은 ‘조쉬의 뉴스레터 구독’입니다. :)
구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.
0
0
1