도어대시는 여러 팀이 고객용 AI 기능을 만들면서 생기는 중복 작업과 비용·안전 문제에 대응해 공통 플랫폼을 구축했다. 이 사례를 바탕으로 기업이 모델 연결, 품질 관리, 사내 지식과 에이전트 권한을 어떤 순서로 마련할지 살펴본다.
2023년 4월 오픈AI와 첫 계약을 맺은 뒤 도어대시에서는 각 팀이 모델 연결, 재시도, 비용 추적, 프롬프트 버전 관리를 따로 만들기 시작했다. 3년 뒤 플랫폼은 사내 사용자 5,000명 이상을 지원하고, 에이전트가 하루 30만 차례 회사 도구를 호출한다. 도어대시의 스와룹 치틀루(Swaroop Chitlur)와 시다르트 코드와니(Siddharth Kodwani)는 이 플랫폼 구축 경험을 공개했다.
기업 직원이 ChatGPT나 Claude를 직접 쓰는 경우와, 기업이 제품에 AI 기능을 넣어 고객에게 제공하는 경우는 다르다. 후자에서는 어떤 모델을 쓰고, 모델에 무엇을 허용하며, 비용과 고객 데이터는 어떻게 관리할지 기업이 책임져야 한다. 여러 팀이 기능을 만들면 이 공통 업무를 맡는 AI 플랫폼이 필요해진다.
플랫폼은 크게 네 영역으로 나뉜다. 모델에 연결하고 팀별 비용을 관리하는 접근, AI의 응답과 품질을 확인하는 신뢰, 사내 지식과 도구를 제공하는 맥락, 그리고 이를 운영하는 사람이다. 도어대시가 처음부터 모든 영역을 한꺼번에 만든 것은 아니다. 여러 팀이 동시에 모델을 쓰던 상황에서 공통 연결 지점부터 마련했다.
모델 게이트웨이는 각 팀의 기능과 여러 모델 사이에 놓이는 단일 연결 지점이다. 도어대시는 이를 통해 모델 제공업체가 과부하일 때 다른 경로로 요청을 보내고, 모델을 바꿀 때 제품 코드를 크게 손대지 않도록 했다. 팀별 사용량과 예산도 이곳에서 관리할 수 있다. 다만 모델 제공업체가 하나이고 바꿀 계획도 없다면 게이트웨이가 불필요한 복잡성을 더할 수 있다는 반론도 있다.
AI가 고객에게 잘못된 답을 내놓으면 기업이 책임을 져야 한다. 따라서 요청과 응답을 기록하고, 개인정보나 부적절한 응답을 걸러내며, 변경 전후의 품질을 시험하는 일이 중요하다. 도어대시 지원팀은 먼저 저비용 검사로 답변을 확인하고, 문제가 의심될 때 모델을 추가로 호출하는 방식을 적용했다. 회사가 공개한 사례에서는 환각이 90%, 심각한 규정 준수 문제가 99% 줄었다. 이는 도어대시 지원 기능에 대한 결과다.
기록에는 고객 메시지가 들어갈 수 있어 보관 기간과 열람 권한도 정해야 한다. AI의 지침을 바꾸는 일 역시 품질에 영향을 줄 수 있다. 도어대시 지원팀은 자주 발생하는 실패를 테스트로 만들고, 지침을 바꿀 때마다 시험해 문제가 있으면 배포를 막는다. 무엇을 좋은 답으로 볼지는 제품팀이 정해야 한다는 것이 치틀루의 설명이다.
사내 문서와 시스템에 연결하면 모델은 회사 정책을 참고하고 업무를 수행할 수 있다. 검색 증강 생성(RAG)은 관련 문서를 찾아 모델에 전달하는 방식이며, 모델 컨텍스트 프로토콜(MCP)은 AI 도구와 회사 시스템을 연결하는 표준이다. 에이전트에 도구를 연결할 때는 사용자 신원과 권한을 확인하고, 민감하거나 파괴적인 작업에는 사람의 승인을 두는 것이 핵심이다. 도어대시는 에이전트가 어떤 도구를 쓸 수 있는지 통제하는 게이트웨이를 만들었지만, 에이전트의 기억 기능은 아직 상태를 저장하지 않는다고 밝혔다.
기업 규모에 맞춰 단계적으로 도입하기
원문은 다음 다섯 단계를 제안한다. 순서는 정해진 처방이 아니며, 도어대시도 여러 팀과 재무 부서의 필요 때문에 제안된 순서보다 앞서 게이트웨이를 도입했다.
- 첫 AI 기능은 모델 제공업체의 관리 도구에서 팀별 예산을 설정하고, 변경 뒤 실제 응답 20~50개를 읽으며 문제를 기록한다.
- 고객에게 기능을 제공하면 요청·응답 기록, 지침 변경 때마다 실행하는 품질 테스트, 응답 안전 검사와 AI 사용 표시를 추가한다.
- 두 번째 팀이나 모델 제공업체가 생기면 팀별 키와 예산, 대체 경로를 갖춘 게이트웨이를 검토하고 운영 책임자를 정한다.
- AI가 사내 정보를 활용해야 하거나 비용이 커지면 지식 출처별 담당자를 지정한다. 더 저렴한 모델이나 자체 호스팅은 사용량이 운영 비용을 정당화할 때 검토한다.
- 에이전트가 도구를 사용하기 시작하면 도구별 권한을 설정하고, 민감한 작업은 사람의 승인을 받도록 한다.
플랫폼을 직접 운영할지, 외부 서비스를 이용할지, 클라우드 제공업체의 기능을 쓸지도 선택해야 한다. 도어대시는 처음에는 빠르게 바뀌는 분야라는 이유로 제품을 구매하는 방식을 택했지만, 필요에 맞지 않는 평가 도구는 자체 구축으로 전환했다. 핵심은 비용 추적, 인증, 정확도처럼 회사에 중요한 업무의 책임을 내부에 두고, 그 업무를 수행하는 도구는 상황에 따라 바꿀 수 있게 하는 것이다. 자체 운영에는 보안 업데이트와 유지보수를 맡을 인력이 필요하며, 외부 도구를 고를 때도 공급업체의 지속성과 표준 지원을 살펴야 한다.
기술 검토에서는 어떤 문제를 해결하려는지, 제품 기능과 직원용 코딩 도구 중 무엇을 위한 것인지, 앞으로 사용할 팀과 모델 제공업체는 몇 곳인지부터 물을 수 있다. 기록을 누가 얼마나 자주 확인하는지, 고객 데이터가 어디에 얼마나 보관되는지, 에이전트가 승인 없이 할 수 있는 일이 무엇인지, 운영 주체와 도구를 바꿀 때의 비용은 무엇인지도 확인해야 한다.
도어대시 사례는 모든 기업이 같은 플랫폼을 그대로 만들어야 한다는 뜻이 아니다. 문제에 맞춰 필요한 부분부터 도입하고, 운영 책임자를 정하며, 회사가 맡아야 할 업무와 공급업체가 제공하는 도구를 구분하는 것이 이 글의 제안이다. 주요 근거로는 도어대시의 플랫폼 발표와 AI 플랫폼 구성 가이드가 제시됐다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요