혜이드
지난 글
https://gpdbs9409.tistory.com/104
AI 자동화, 그냥 자동화랑 뭐가 다른건지?
며칠 전에 선배님이 대시보드 하나를 슬랙으로 공유해주셨습니다. 주제를 하나 넣으면 인스타 카드뉴스랑 쓰레드 글을 자동으로 만들어주는 도구였는데, 구글시트에 내용만 채워두면 대시보드
gpdbs9409.tistory.com
에서 카카오T의 AI 주소 자동입력 얘기를 하다가, "카카오 내부에도 회의실 예약하고 휴가 신청 자동화해주는 AI가 있다"고 이야기 했는데요, 카카오 CTO가 컨퍼런스에서 구조 자체를 공개해놓은 걸 찾아서, 오늘은 그 내용을 정리합니다.
1. 카카오는 AI 자동화를 두 가지 다른 방식으로 썼다
먼저 대조부터 하겠습니다. 카카오T 퀵·배송의 AI 주소 자동입력은 구글의 Gemini 2.0 Flash를 API로 호출하는 방식입니다. 사용자가 복사해온 긴 메시지(주소, 수신인, 연락처가 뒤섞인 비정형 텍스트)를 AI가 읽고 필요한 필드만 뽑아냅니다. 접수 완료까지 걸리는 시간을 평균 24% 줄였고 접수 완료율은 13.39% 올렸습니다 (AI타임스). 외부 모델을 그대로 갖다 쓴, 단일 기능 단위의 API 호출입니다.
반면 카카오 내부 업무용으로 쓰는 'AI 버디'는 완전히 다릅니다. 이건 2024년 10월 if(kakaoAI)2024 컨퍼런스에서 카카오 CTO 정규돈이 공개한 사내 AI 에이전트로, 외부 모델을 API로 가져다 쓴 게 아니라 카카오가 자체 개발한 에이전트입니다. 회의실 예약, 사내 문서 요약, 인사·복지·내규 검색, 휴가 신청까지 처리합니다.
같은 회사가 같은 시기에 "외부 API를 그대로 쓰는 방식"과 "자체 에이전트를 밑바닥부터 구축하는 방식"을 둘 다 씁니다. 이 차이가 어디서 오는지 궁금해서 AI 버디 쪽을 더 뜯어봤습니다.
2. AI 버디는 정확히 어떻게 만들어졌나
핵심은 LLM을 "라우터"로 쓴다는 겁니다. 사용자 질문이 들어오면 LLM이 먼저 이 질문을 분석해서, 어떤 처리 방식으로 보낼지 스스로 판단합니다. 카카오 CTO가 공개한 도식을 기준으로 정리하면 세 갈래입니다.
첫째, Function Call입니다. 회의실 예약이나 사내식당 메뉴 확인처럼 "실행"이 필요한 요청은 관련 내부 API를 직접 호출합니다. 예를 들어 "오늘 오후 5시 10층 회의실에서 PR 멤버들과 리뷰 회의 예약해줘"라고 메시지를 보내면, LLM이 이 문장에서 의도(예약)와 파라미터(시간, 층, 참석자, 회의 제목)를 뽑아내고, 그 파라미터로 회의실 예약 시스템 API를 호출해서 빈 회의실 목록을 가져옵니다. 확정되면 예약 처리와 참석자 초대장 발송까지 자동 실행됩니다.
둘째, Agentic RAG입니다. "ifkakao 세션 내용 요약해줘"처럼 검색이 필요한 요청은, 에이전트가 사용자 질의를 스스로 더 구체화해서 RAG로 검색하고, 이 과정을 필요한 만큼 반복하면서 정확도를 높입니다. 사용자에게 되묻는 게 아니라, 에이전트가 내부적으로 스스로 질문을 다듬어서 재검색하는 방식입니다.
셋째, Graph RAG입니다. "ifkakao 회의 자료 요약해줘"처럼 문서 간 관계가 중요한 요청은, 문서에서 개체(entity)와 개체 간 관계(relation)를 추출해 지식 그래프를 만들고 그걸 기반으로 답합니다. 단순 벡터 유사도 검색보다 문맥을 더 정확하게 잡아냅니다.
마지막 단계도 정해져 있습니다. RAG나 Function Call에서 받아온 결과를 LLM이 한 번 더 정리해서 최종 답변을 구성합니다. 정리하면 흐름은 이렇습니다.
질문 → LLM이 라우팅 판단 → Function Call / Agentic RAG / Graph RAG 중 실행 → 결과를 LLM이 다시 자연어로 조립 → 사용자에게 응답
이 구조에서 "AI"라고 부를 수 있는 지점은 라우팅 판단과 질의 구체화, 최종 응답 조립입니다. 판단이 필요한 지점에만 LLM이 개입하고, API 호출이나 지식그래프 조회 같은 실행 자체는 정해진 로직대로 도는 SW입니다 (바이라인네트워크).
3. 이걸 지탱하는 인프라: KAP
AI 버디는 카카오 AI 플랫폼(KAP, Kakao AI Platform)이라는 사내 인프라 위에서 만들어졌습니다. AI 서비스를 만들려면 원래 데이터 정제, AI 세이프티·개인정보·라이선스 법무 검토, GPU 확보와 분산 학습 환경 구축, 모델 트레이닝, 파인튜닝, 평가·검증, 추론 엔드포인트 생성, 보안 검토까지 거쳐야 합니다. KAP는 이 과정을 표준화해서, 모델 개발자는 이미 검토가 끝난 안전한 데이터를 데이터 스토어에서 선택하기만 하면 되고, AI 서비스 개발자는 모델 카탈로그에서 모델을 골라 추론 엔드포인트를 만들고 바로 서비스나 에이전트에 연결하면 됩니다..이게 개 미친것 같아요 AI Agent 공장을 만들었습니다. AI 버디 하나만 따로 잘 만든 게 아니라 "에이전트를 반복해서 빠르게 만들 수 있는 공장"을 먼저 만들었다는 뜻이기 때문입니다. 실제로 카카오는 같은 인프라 위에서 개발자용 PR 리뷰 에이전트인 '코드 버디'도 함께 내놨습니다. 최근 1년간 카카오 사내에서 생성된 PR이 32만 건, 하루 평균 1,200건이 넘는데, 코드 버디가 리뷰 절차를 간소화하고 자동화된 리뷰·제안을 제공합니다.
4. 왜 굳이 직접 만들었을까
카카오T의 주소 자동입력은 사용자가 붙여넣은 텍스트 한 번을 처리하고 끝나는 단발성 작업입니다. 외부 API 한 번 호출로 충분합니다. 반면 AI 버디는 인사 정보, 복지 규정, 내규처럼 외부로 나가면 안 되는 사내 데이터를 다루고, 회의실 예약 시스템 같은 내부 API와 계속 연동돼야 하고, 사용 빈도도 훨씬 높습니다.
이 세 가지 조건(민감한 내부 데이터, 여러 내부 시스템과의 상시 연동, 높은 사용 빈도)이 맞아떨어지면 외부 API를 그때그때 호출하는 것보다 자체 인프라를 구축하는 쪽이 장기적으로 이득이 됩니다. 반대로 카카오T 사례처럼 단발성이고 외부 데이터(사용자가 복사해온 텍스트)만 다룬다면 굳이 자체 모델을 만들 이유가 없습니다. 결국 "직접 만들 것이냐, API를 가져다 쓸 것이냐"는 기술력의 문제가 아니라 데이터 민감도와 사용 빈도, 얼마나 여러 시스템과 엮이는지의 문제라는 생각이 들었습니다.
정리하며
이번에 카카오 사례를 정리하면서 확실해진 게 하나 있습니다. "AI 에이전트를 만들었다"는 한 문장 뒤에는 라우팅 로직, RAG 파이프라인 두 종류, Function Call 연동, 그리고 이 전체를 반복 생산할 수 있는 플랫폼(KAP)까지 여러 층이 쌓여 있다는 것입니다. 저는 그동안 "에이전트 만들었다"를 뭉뚱그려서 생각했는데, 실제로는 이 층 하나하나가 각각 설계 결정이고, 그 결정들이 "왜 굳이 직접 만들었나"에 대한 답이 되더라고요.
주니어 개발자 입장에서 배운 건, 케이스스터디를 읽을 때 "얼마나 시간을 줄였다"는 결과만 보지 말고 "그 판단이 어느 레이어에서 일어나는지"를 뜯어보는 습관이 필요하다는 겁니다. 다음엔 이 라우터 구조를 미니 버전으로 직접 만들어보고, 실제로 얼마나 흉내 낼 수 있는지 정리해보려고 합니다.
참고한 글들
'AX' 카테고리의 다른 글
| 토큰 단가가 더 싼 모델이 사실 7배 비쌌던 이야기 (0) | 2026.08.13 |
|---|---|
| 포트폴리오를 Claude랑 같이 만들다가 데이터를 날려먹을 뻔한 이야기 (2) | 2026.08.13 |
| AI 자동화, 그냥 자동화랑 뭐가 다른건지? (4) | 2026.07.23 |