AI Agent Admin & AI Gateway 구축기

작성자: 로빈(서용덕) | 작성일: 2026.07.22

들어가며

안녕하세요. 카카오모빌리티 LLM Platform TF에서 AI 플랫폼을 개발하는 로빈입니다. 저희 TF는 사내 여러 서비스가 LLM 기능을 더 빠르고 안정적으로 만들 수 있도록, 공통으로 쓰는 AI 플랫폼을 구축하고 있습니다.

LLM 기능을 한 번이라도 출시해 보신 분이라면, 아마 비슷한 경험을 하셨을 겁니다. 모델은 하루가 다르게 똑똑해지는데, 정작 그 모델을 다루는 일상은 이상할 만큼 손이 많이 갔습니다. “지난주에 제일 잘 됐던 프롬프트가 어떤 버전이었죠?”라는 질문에 아무도 선뜻 답하지 못하거나, 분명 슬랙 어딘가에 올렸던 프롬프트를 다시 찾지 못하거나, 어제까지 잘 되던 응답이 오늘 갑자기 달라졌는데 무엇을 고쳤는지 추적할 수 없는 상황이 반복됐습니다.

서비스에 AI 기능을 더하는 데 드는 비용의 상당 부분은, 사실 모델 자체가 아니라 프롬프트를 둘러싼 협업에서 발생하고 있었습니다. 이 글에서는 바로 그 지점을 어떻게 진단했고, 사내 서비스들이 더 빠르고 수월하게 AI 기능을 도입할 수 있도록 만든 두 가지 축인 AI Agent Admin과 AI Gateway를 어떻게 구축했는지 소개하려고 합니다.

📚 추천 독자

이 글은 프롬프트 관리와 배포 과정에서 반복적인 비효율을 겪고 있는 개발자, 여러 서비스의 LLM 연동과 인증 체계를 하나의 플랫폼으로 통합하고 싶은 엔지니어, 개발자와 비개발자가 함께 AI 기능을 만들고 개선할 수 있는 협업 환경을 고민 중인 팀이 읽으시면 더욱 좋아요!

AI 기능 하나를 출시하기까지

본격적인 소개에 앞서, 플랫폼을 만들기 전 저희가 겪었던 과정을 먼저 공유하려고 합니다. AI 기능을 하나 출시하는 일은 기대와 달리 생각보다 많은 시간과 손이 필요했습니다.

당시의 작업 흐름은 대략 이랬습니다. 먼저 담당자가 각자 사용하는 AI 챗 도구에서 직접 대화를 주고받으며 원하는 결과가 나올 때까지 프롬프트를 다듬습니다. 괜찮은 결과가 나오면 그 프롬프트를 슬랙으로 전달하고, 개발자가 이를 코드에 반영합니다. 이어서 클라우드 연동(키와 인증)을 맞춰 배포하고, 운영에서 결과를 본 뒤 다시 프롬프트를 고치는 과정을 반복했습니다.

언뜻 보면 평범한 흐름이지만, 그 안에는 작고 끈질긴 마찰이 곳곳에 숨어 있었습니다.

가장 먼저, 기준이 되는 프롬프트가 어디에도 없었습니다. 어떤 버전은 각자의 챗 도구에, 어떤 버전은 슬랙 스레드에, 또 어떤 버전은 코드 안에 흩어져 있었습니다. 변경 이력이 남지 않다 보니 “지난주에 제일 잘 됐던 그 버전”을 다시 찾는 일이 일종의 발굴 작업이 되곤 했습니다.

다음으로, 프롬프트 수정이 코드 배포 사이클에 묶여 있었습니다. 프롬프트의 문구 한 줄을 바꾸려 해도 결국 서버 배포가 필요했습니다. 그래서 비개발자가 프롬프트를 고쳐 서비스에 반영하려면, 매번 개발자에게 배포를 부탁해야 했습니다. 프롬프트는 원래 빠르게 여러 번 고쳐 보며 다듬어야 하는데, 그때마다 무거운 배포 과정을 거쳐야 하니 좀처럼 속도를 낼 수 없었습니다.

연동을 준비하는 데에도 시간이 제법 들었습니다. 버티컬 서비스가 LLM Provider와 직접 연동하려면, 서비스마다 각자 credential을 발급받아 직접 관리해야 했습니다. 연동하는 곳이 많아질수록 관리해야 할 credential도 계속 늘어나 부담이 되었고, 새로 붙는 서비스마다 LLM Provider 연동을 위한 똑같은 작업을 처음부터 반복해야 하는 비효율도 있었습니다.

여기에 더해, 이렇게 발급되는 키는 대체로 LLM 모델 전반에 접근할 수 있는 범용 키였습니다. 한 번 발급되고 나면 그 키가 이후 어디에서 어떤 프롬프트로, 어떤 용도에 쓰이는지 추적하기가 어려웠고, 그만큼 사용 내역이 관리 범위 밖에 놓이는 거버넌스 사각지대가 생겼습니다.

마지막으로, 여럿이 함께 프롬프트를 다듬을 도구가 마땅치 않았습니다. 프롬프트 품질은 직군과 무관하게 누구나 평가하고 의견을 보탤 수 있는 영역입니다. 하지만 프롬프트가 코드 안에 들어 있다 보니, 함께 보면서 고치고 그 결과를 바로 확인할 공간이 없었고, 결국 모든 의견이 개발자라는 좁은 통로를 거쳐야만 반영될 수 있었습니다.

진짜 병목은 협업에 있었다

이 마찰을 한자리에 모아 보니 결론은 분명했습니다. AI 기능 개발의 진짜 병목은 모델의 성능이 아니라, 프롬프트를 함께 만들고 관리하는 협업 과정에 있었습니다.

프롬프트는 코드처럼 버전과 이력이 관리되어야 하고, 위키처럼 여러 사람이 함께 다듬을 수 있어야 하며, 설정값처럼 코드 배포 없이도 바뀔 수 있어야 합니다. 그런데 당시의 프롬프트는 이 세 가지 중 어느 것도 충족하지 못한 채 코드의 일부로만 취급되고 있었습니다.

그래서 저희가 플랫폼의 방향으로 삼은 것은 화려한 기능이 아니라 두 가지였습니다. 하나는 협업, 다른 하나는 손쉬운 연동입니다. 그리고 이 둘을 떠받치는 핵심 설계 원칙은 한 문장으로 요약됩니다.

“프롬프트를 수정하는 일과, 코드를 배포하는 일을 분리한다.”

AI Agent Admin: 프롬프트를 코드 밖 협업 공간으로

AI Agent Admin은 사람을 위한 협업 공간입니다. 프롬프트를 작성·수정하고, Playground에서 바로 테스트하고, 변경 및 배포 이력을 확인하고, 멤버와 함께 다듬어 배포하는 일련의 과정이 모두 이곳에서 이루어집니다.

먼저 새로운 AI 기능을 위한 에이전트를 생성합니다. 이 단계에서 모델 설정과 프롬프트는 코드 일부가 아니라 플랫폼이 관리하는 독립된 대상으로 들어옵니다. 프롬프트가 코드 밖으로 나오는 순간, 비로소 코드 배포와 무관하게 자유롭게 다룰 수 있게 됩니다.

작성한 프롬프트는 Playground에서 즉시 테스트할 수 있습니다. 프롬프트를 고치고 그 자리에서 바로 결과를 확인할 수 있기 때문에, 기존처럼 “전달하고, 반영을 기다리고, 다시 결과를 받아 보는” 번거로운 과정이 사라집니다.

모든 변경은 이력으로 남습니다. “마지막으로 잘 됐던 버전이 무엇이었는지”라는 질문에 이제는 답할 수 있습니다. 누가 언제 무엇을 바꿨는지가 기록되고, 필요하면 이전 버전으로 되돌릴 수 있습니다.

무엇보다 에이전트마다 함께 작업할 멤버를 둘 수 있다는 점이 중요합니다. 프롬프트가 코드 밖으로 나온 덕분에, 협업에 참여하는 사람이 반드시 개발자일 필요가 없어졌습니다. 예를 들어 응답 속도가 느리다는 의견이 나오면 “Thinking 옵션을 꺼 보자”라는 제안이 오가고, 실제로 옵션을 끈 뒤 응답이 빨라지면서 품질도 괜찮다는 점을 그 자리에서 함께 확인합니다. 또 도메인 담당자가 버티컬 지식베이스 내용을 프롬프트에 직접 보강하면, 답변이 그 지식을 근거로 달라지는 모습을 모두가 같이 지켜볼 수 있습니다. 이렇게 합의된 버전을 그대로 배포로 이어 가게 됩니다.

마지막은 배포입니다. 운영(production) 환경 배포에는 한 단계의 안전장치가 추가로 안내되어, 빠른 반복과 신중한 출시 사이의 균형을 맞추도록 설계했습니다.

AI Gateway: 서비스가 기능에만 집중하도록

AI Agent Admin이 사람을 위한 공간이라면, AI Gateway는 서비스를 위한 연동 지점입니다.

버티컬 서비스 입장에서 AI Gateway 연동은 단순합니다. 에이전트를 호출하는 Agentic API 하나면 충분합니다. 인증과 credential 발급, 모델 연동처럼 매번 반복되던 준비 작업이 게이트웨이 계층으로 모이면서, 서비스 팀은 연동을 준비하는 데 시간을 쏟는 대신 자신의 기능 자체에 집중할 수 있게 되었습니다.

키를 관리하는 방식도 달라졌습니다. 기존에는 LLM 모델 전반에 접근할 수 있는 범용 키가 발급되어 이후 사용을 통제하기 어려웠다면, 이제는 기능 에이전트와 프롬프트 단위로 키가 발급됩니다. 어떤 키가 어떤 에이전트의 어떤 프롬프트에 연결되어 있는지가 분명해지면서, 사용 내역을 추적하고 통제할 수 있게 되었고 앞서 이야기한 거버넌스 사각지대도 사라졌습니다.

특히 Admin에서 다듬어진 에이전트가 게이트웨이를 통해 곧바로 서비스에 연결되기 때문에, 프롬프트를 개선하는 일과 그 개선을 실제 서비스에 반영하는 일 사이의 거리가 크게 줄었습니다. 프롬프트를 고치는 일이 더 이상 부담스럽지 않으니, 팀은 훨씬 쉽고 빠르게 기능을 개선할 수 있게 되었습니다.

무엇이 달라졌나

가장 체감되는 변화는 AI 기능의 출시 과정입니다.

플랫폼을 도입하기 전에는, 프롬프트를 다듬는 일이 개발·배포 과정과 단단히 얽혀 있었습니다. 프롬프트를 한 번 고칠 때마다 코드를 반영하고 다시 배포해야 했고, 이 때문에 출시 일정도 전반적으로 늦어지곤 했습니다.

플랫폼 도입 이후의 흐름은 한결 단순해졌습니다. 기능 기획과 기술윤리 검토, 비용 검토 같은 단계를 거친 뒤에는, Admin에서 프롬프트를 만들고, Gateway에 연결한 다음, 다시 Admin에서 프롬프트를 다듬으면 됩니다. 이 과정을 짧게 여러 번 반복할 수 있고, 출시한 뒤에 개선할 때도 같은 방식으로 이어집니다.

달라진 건 단계의 수가 아니라, 한 번 고치는 데 드는 수고입니다. 프롬프트를 다시 고치는 부담이 줄어들면서, 개선 속도 자체도 빨라졌습니다.

마치며

이번 작업에서 저희가 얻은 가장 큰 교훈은, 프롬프트를 코드 안에 섞어 두지 말고, 코드와 분리된 별도의 공간에서 관리해야 한다는 것이었습니다. 그리고 코드가 그렇듯, 프롬프트에도 변경 이력을 남기고 손쉽게 테스트해 볼 수 있는 도구가 필요합니다. 프롬프트가 코드에 묶여 있으면 코드와 똑같은 무게를 짊어질 수밖에 없지만, 코드 밖으로 꺼내는 순간 더 많은 사람이 더 빠르게 함께 만들 수 있게 됩니다.

비슷한 고민을 하고 계신 팀이라면, 새로운 모델을 고르기 전에 먼저 이 질문을 던져 보시길 권합니다.

“우리 프롬프트는 지금 어디에 있고, 누가, 어떻게 고치고 있나요?”

AI 기능은 더 이상 엔지니어 혼자 만드는 것이 아닙니다. 카카오모빌리티는 앞으로도 더 많은 구성원이 손쉽게 AI 기능을 함께 만들고 서비스에 바로 연결할 수 있도록, 플랫폼을 계속해서 발전시켜 나가겠습니다. 감사합니다.