대규모 언어 모델(LLM) 분야에서는 오랫동안 “더 큰 모델일수록 더 뛰어난 성능을 낸다”는 믿음이 강하게 자리잡아 왔습니다.하지만 모델의 파라미터가 커질수록 훈련과 서비스에 필요한 비용 또한 기하급수적으로 늘어나 현실적으로 한계에 부딪히곤 했죠.이쯤에서 한 번쯤은 “정말 좋은 성능을 내려면 무조건 파라미터가 많아야만 할까?”라는 질문이 자연스럽게 떠오릅니다.최근 이 질문에 새로운 답변을 제시하는 접근법으로 MoE(Mixture of Experts) 아키텍처가 다시 주목받고 있습니다.MoE는 거대한 하나의 신경망 대신, 다양한 전문성을 가진 여러 ‘전문가(Expert)’ 네트워크를 두고, 입력에 따라 딱 맞는 몇 명의 전문가만 선택적으로 활용하는 구조입니다.마치 거대한 도서관에서 모든 책을 샅샅이 찾는 대신, 궁금한 분야에 특화된 사서를 찾아가 바로 답을 듣는 것처럼 말이죠.이런 방식을 통해 전체적으로는 큰 모델이지만, 실제 추론 시에는 필요한 계산만 수행할 수 있어 성능과 효율이라는 두 마리 토끼를 잡을 수 있습니다.이 글은 AI 분야에 전문가는 아니지만 엔지니어로서 MoE에 대해 공부하며 알게 된 내용을 정리한 것입니다.AI의 내부 구조에 궁금증이 있고 이를 활용하고자 하는 일반 개발자분들에게 조금이나마 도움이 되었으면 합니다.이름에서 알수 있듯이 전문가 혼합 모델로. 독립적으로 수행할 수 있는 보다 작은 크기의 다수 전문가 네트워크를 보유하고 필요에 따라 활용하는 형태로 동작하는 구조를 말합니다.이에 따라 각 요청별로 전체 파라미터를 활성화하여(통과시켜) 문장을 생성하는 기존의 방식에 대비해 일부의 파라미터만을 활성화하여계산의 효율성은 높혀 빠른 응답이 가능하도록 했지만 적절한 파라미터 선택과정을 통해 생성된 문장의 질은 유지하는 특징을 갖고 있습니다.DeepSeek을 비롯하여 GPT-4, KIMI-2, Qwen3 등 최신 LLM 모델들이 모두 사용하고 있는 증명된 아키텍쳐입니다.모델의 크기가 커지면서 일정 수준을 넘어가면서 발생하는 이전에는 불가능했던 것들을 가능하게 하는 창발효과를 보여줌으로써 크기에 대한 경쟁이 이뤄졌습니다.트랜스포머 아키텍쳐에서는 파라미터간의 연산들을 통해 결과를 내는 특성이 있으므로 파라미터가 커지면 그 제곱만큼의 계산량이 늘어나는 특징이 있습니다.이에 따라 급격한 하드웨어 수요가 발생하게 되었고 지금까지 계속되고 있는 nVidia GPU 품귀현상을 만들어 내고 있습니다.하지만 최근 연구들은 이러한 창발효과가 한계체감의 법칙을 따른다는 것을 보여주고 있습니다.초기에는 파라미터를 10배 늘리면 성능도 비례적으로 향상되었지만, 현재는 같은 수준의 성능 향상을 위해 훨씬 더 많은 파라미터가 필요합니다.더욱 중요한 것은 계산 비용과 에너지 소비가 기하급수적으로 증가한다는 점입니다.1조 개 파라미터 모델 하나를 훈련하는 데 드는 비용은 수십억 원에 달하며, 이는 지속 가능한 발전 방향이 아닙니다.이에 따라 성능향상을 위한 새로운 시도들이 있습니다.아키텍쳐의 혁신으로 주목받는 MoE, 거대모델의 지식을 작은 모델로 전수하는 지식증류(Distillation), 모델의 파리미터별 희소성을 적용하기 위한 희소 모델링 등이 그것입니다.그중 가장 주목받고 있으며 활발히 적용되고 있는 기술이 MoE입니다.전통적인 트랜스포머 모델은 모든 계층이 '밀집(Dense)'되어 있습니다.입력된 모든 토큰은 어텐션 레이어와 FFN(Feed-Forward Network) 레이어의 모든 뉴런을 거쳐 처리됩니다.이는 모델의 표현력을 높이지만, 파라미터 수가 증가할수록 연산량도 동시에 폭증합니다.반면, MoE는 트랜스포머의 FFN 레이어를 여러 개의 작은 FFN(전문가)과 게이팅 네트워크로 대체합니다.아래 그림은 n개의 전문가중 2개를 선택하는 MoE 구조입니다.게이팅 네트워크는 MoE의 핵심 컴포넌트로, 각 토큰이 어떤 전문가에게 전달 할지를 결정하는 라우터(Router) 역할을 수행합니다.일반적으로 간단한 선형 레이어와 Softmax 함수로 구성됩니다.• None 입력: 트랜스포머 블록의 이전 레이어에서 온 토큰의 임베딩 벡터를 입력으로 받습니다.• None 로짓 계산: 선형 레이어를 통과시켜 각 전문가에 대한 로짓(logit) 값을 계산합니다.• None 가중치 생성: 이 로짓 값에 Softmax 함수를 적용하여 각 전문가에 대한 확률 분포, 즉 가중치를 얻습니다.• None Top-K 선택: 가장 높은 가중치를 가진 상위 K개의 전문가를 선택합니다.각 전문가는 독립적인 신경망이며, 보통 표준 트랜스포머의 FFN(Feed-Forward Network)과 동일한 구조를 가집니다.즉, 두 개의 선형 레이어와 그 사이의 비선형 활성화 함수(GeLU, SiLU 등)로 구성됩니다.게이팅 네트워크에 의해 선택된 토큰들은 해당 전문가들에게 전달됩니다.각 전문가는 자신에게 할당된 토큰들을 병렬적으로 처리합니다.마지막으로, 각 전문가의 출력은 게이팅 네트워크가 계산한 가중치와 곱해져 합산됩니다.이 가중 합산(weighted sum) 과정이 전문가들의 '지식'을 부드럽게 융합하는 역할을 합니다.이러한 구조를 통해 다음과 같은 효과를 얻습니다.• None 연산량 (FLOPs) 감소: MoE는 토큰당 활성화되는 파라미터가 적어, 총 파라미터 수가 비슷한 Dense 모델보다 훨씬 적은 연산량으로 추론이 가능합니다. 이를 '희소 활성화(Sparse Activation)'라고 부릅니다.• None 파라미터 효율성 증가: 훈련 시에는 모든 전문가가 업데이트되지만, 추론 시에는 일부만 사용됩니다. 이는 더 적은 계산 비용으로 더 큰 모델 용량(capacity)을 확보할 수 있음을 의미합니다.• None GPU 분할: 각각의 전문가는 독립적인 네트워크로 구성되어 있으므로 다중 GPU환경에서 분할 단위로 활용할 수 있습니다.주의 해야할 점은 추론 시 연산량은 적지만, 모델의 모든 파라미터(모든 전문가 포함)는 여전히 GPU 메모리에 상주해야 합니다.필요에 따라 언제든 계산에 활용될 수 있어갸 하기 때문입니다. 이것의 해소는 MoE 배포와 관련하여 가장 큰 도전 과제 중 하나 입니다.위에서 언급한 것처럼 Mo

ian.wizard AI시대를 맞아 카카오페이와 다양한 AI 에이전트들을 잇기 위한 많은 고민과 노력을 엿볼 수 있었습니다. MCP를 직접 개발할 때 어떤 것들을 고려해야 할지, 어떠한 구조로 가져가면 좋을지에 대해 궁금하시다면 이 글을 추천합니다.snow.y 결제가 AI를 만나면 어떤 방향으로 진화할까요? 개발자에게는 더욱 쉬운 결제 연동을, 사용자에게는 더 친숙하고 편리한 결제 경험을 주기 위해 결제에 을 도입한 구체적인 사례를 만나보세요.안녕하세요, 저는 카카오페이 결제기술파티에서 결제 코어 시스템을 개발하고 있는 리입니다. 최근 AI 에이전트 기술이 빠르게 발전하면서 “AI가 결제도 처리할 수 있을까?”라는 질문을 자주 받게 되었습니다.특히 ChatGPT, Claude 등의 AI 모델이 function calling을 통해 외부 API를 호출할 수 있게 되면서, 결제 시스템과의 연동 가능성에 대한 관심이 높아졌습니다. 이러한 기술적 가능성을 실제 서비스로 구현하기 위해서는 체계적인 접근이 필요했습니다.이번 글에서는 카카오페이에서 AI 에이전트와 결제 API를 효과적으로 연동하기 위해 Model Context Protocol(MCP)을 도입하고, 멀티 프레임워크를 지원하는 Agent Toolkit을 개발한 경험을 공유하고자 합니다.왜 AI 에이전트와 결제 API 연동을 고민했는가?AI 에이전트의 현실화요즘의 AI는 빠르게 우리에게 다가오고 있습니다. 과거 특정 시기에 기술적으로 광풍이 불었지만 유의미한 형태로 현실 세계에 나오지 못했던 기술들과는 사뭇 다릅니다. 특히 function calling 기능이 등장하면서 AI가 단순히 대화만 하는 것이 아니라, 실제로 시스템을 조작할 수 있게 되었습니다.개발자로서 하루가 다르게 새로운 뉴스가 나오는 AI 기술을 바라볼 때마다 놀라운 변화의 속도를 실감합니다. 이제는 “이 기술을 어떻게 하면 더 많은 개발자들이 쉽게 활용할 수 있을까?”, “결제 시스템과 AI를 어떻게 효과적으로 연결할 수 있을까?”라는 고민을 하게 되었습니다.이러한 고민은 개인적인 호기심을 넘어 카카오페이 차원에서도 중요한 화두가 되었습니다. 이에 따라 LLM 기술의 빠른 발전과 가능성을 주의 깊게 살피며, 앞으로 더 많은 개발자들이 변화에 자연스럽게 적응하고 활용할 수 있도록 필요한 도구와 인프라를 차근차근 준비하려고 합니다.이러한 AI와 결제 시스템의 연동은 카카오페이만의 고민이 아닙니다. 글로벌 핀테크 업계에서도 AI 에이전트 기술을 적극적으로 도입하고 있습니다.PayPal과 Stripe 같은 글로벌 핀테크 기업들은 이미 AI Agent Toolkit과 MCP Server를 출시하여 개발자들이 결제, 배송 추적, 반품 처리 등의 운영을 AI로 자동화할 수 있도록 지원하고 있습니다.이처럼 글로벌 핀테크 기업들이 AI 연동에 적극 투자하는 이유는 명확합니다. AI를 통해 고객 지원 자동화, 개발자 경험 개선, 새로운 비즈니스 모델 창출이 가능해졌기 때문입니다.처음에는 단순히 OpenAI의 function calling이

“재무회계팀은 수기 작업이… 굉장히 많아요.”재무회계팀은 ‘수기 작업의 집합체’로 불렸습니다. 숫자의 정확성이 생명인 조직이 AI에 업무를 맡긴다는 건 쉽지 않은 결정이었죠. 하지만 반복과 대조로 가득한 업무는 자동화의 최적 대상이었습니다. 재무회계팀 임수진님은 소위 바이브 코딩을 통해 단순 반복 업무를 효율화 하였는데요, Python 이 엑셀의 기능으로 이해할뻔 했던 비개발자의 바이브 코딩 도전기를 소개합니다.작은 자동화의 시작 — 수식 추천에서 매크로, 앱 스크립트로AI 도입 초기, 팀은 가장 익숙한 도구에서 도움을 받았습니다. 간단한 엑셀 수식만 쓰던 시절을 지나 ChatGPT는 더 복잡하지만 빠르게 할 수 있는 수식들을 추천했고, 그다음 단계로 매크로와 Apps Script 사용을 제안하는 자연스러운 흐름으로 이어졌습니다.하지만 결국 기존 도구로는 처리할 수 없는 대용량 데이터 문제에 직면하면서 Python 을 도입하는 상황까지 오게 되었습니다. 하지만 검은 화면의 개발 도구, Python 코드들은 비개발자인 재무회계 팀원들에게는 다른 나라 이야기 같았죠.ChatGPT 에게 질문을 거듭할수록 Python 을 추천하기 시작. 하지만 너무 멀게만 느껴졌다.‘파일이 안 열려요’에서 Python까지 — 기술 선택의 결정적 순간“ 데이터 파일이 열리지 않아서… 제 노트북에서는 하루 종일 기다려도 열리지가 않는 거예요.”전환점은 위기에서 찾아왔습니다.대용량 엑셀 파일이 하루 종일 기다려도 열리지 않는 상황이 온 것이죠. 노트북을 바꾸자니 결산 때만 쓰는 고사양 장비는 ‘가성비’가 없었습니다. 개발 요청을 해도 “임팩트가 뭐죠?”라는 질문 앞에 후순위로 밀릴 수 밖에 없었습니다.결론은 스스로 해결하는 길. ChatGPT에게 묻자 용량이 너무 커서 안 돌아가는 상황엔 Python을 추천했습니다. 처음엔 무시했지만, 더는 파일을 열 수 없게 되었을 때 Python이 답이었습니다. 무엇보다 파일을 열지 않아도 되는 방식이 결정적이었죠.Cursor AI가 바꾼 워크플로 — ‘추천’에서 ‘실행’까지사내에서 지나가다 우연히 추천받은 유튜브 한 편이 전환을 가속했습니다. Cursor AI는 자기가 코딩도, 설치도 하고 오류도 자기가 분석해서 수정하는 도구였습니다. ChatGPT가 ‘방법’을 알려주는 데 그쳤다면, Cursor는 ‘대행’까지 해준 셈이죠.재무회계팀에서 사용 중인 Cursor IDE 화면이 경험은 비개발자에게도 강력했습니다. “검은색 배경” IDE가 허들로 느껴지던 팀에게, GUI와 자동 실행, 오류 리포트는 ‘할 수 있다’는 확신을 줬습니다. 파일을 열 필요가 없는 Python 스크립트, 데이터 검증과 전표화까지 이어지는 자동화 파이프라인이 완성되었습니다.팀 문화의 변화재무회계팀의 AI 도입은 단순히 도구의 변화에 그치지 않고, 팀 문화 전반에 긍정적인 변화를 가져왔습니다. 임수진님은 팀원 모두가 자동화 경험을 직접 발표하도록 독려하며, 각자가 AI와 Python을 활용해 실무 자동화를 체득할 수 있도록 했습니다. 이 과정에서 팀원들은 새로

claude에서 제공하는 설치형 에이전트 AI 도구대세가 cursor이지만 cursor는 vscode에서 지원이 유리한점에서 일단 제외하고 사용하게된 상황나는 pycharm(jetbrains)을 사용하는 사용자로 여러가지 GPT 에이전트를 참고해봤지만 claude code가 현재 사용중인 IDE에서도 지원이 가능하다는 점에서 (터미널국한) 높은 점수를 주어 현재 사용중임.claude code는 현재 오픈소스의 프로젝트의 코드를 빠르게 확인하고 설명해준다는 점에서 코드리뷰를 한다던지 오픈소스코드의 특정기능을 발췌한다던지 등등 사용성에서 좋았음.mcp서버는 의외로 token이나 IDE에 열려있는 파일들로만 국한지어 판단하는 경우가 많다보니 생각보다 느리고 끊기는 점이 많았고 실제로 에러도 많이 나타나서 약간 불편함이 있었음개인적으로는 전반적인 코드를 살펴보고 파악하는데 있어서는 claude code가 프로젝트 내부코드를 빠르게 살펴보고 제안한다는 점에서 오히려 좋았던거같음일반적으로 프로젝트 단위로 시야를 조절하는사용성에서는 mcp를 이용한 방법보다 훨씬 나은 선택지가 아닐까 싶음사용해보면서 느낀점은 mcp의 가장 큰 단점은 열린 파일만 시야가 간다는점이였던거 같음• None 터미널 네이티브: 터미널에서 직접 실행• None 전체 프로젝트 인식: 프로젝트 디렉토리 전체를 컨텍스트로 이해• None 터미널에서 직접 사용하고 코드를 제안하는 방법 + 직접 수정도 가능하여 간단한 토이프로젝트 같은 경우는 바이브코딩으로 구현가능• None 예시 그림) 실제로 운영중인 소모임의 회원 집계툴을 claude code로 100% 바이브로 만들어본 예제• None IDE 통합: PyCharm 플러그인이나 확장을 통해 Claude와 연결• None MCP 중개: MCP 서버가 PyCharm과 Claude API 사이의 중개자 역할• None GUI 기반: PyCharm의 그래픽 인터페이스 내에서 작동• None 컨텍스트 제한: 현재 열린 파일이나 선택된 코드 블록에 주로 의존• None 코드 하이라이팅, 자동완성 등 IDE 기능 활용• None claude code와 동일하게 mcp claude를 통해서 pycharm에 열려 있는 batch.py를 수정한 케이스

Backend 개발은 서비스의 성능과 안정성을 결정하는 중요한 요소입니다.최근 인공지능 기술이 발전하면서 개발자의 생산성을 획기적으로 높일 수 있는 도구가 많이 등장하고 있는데요,그 중에서도 Cursor AI를 활용한 효율적인 Backend-API 개발 방법을 소개하겠습니다.Cursor AI는 개발자의 생산성을 높여주는 AI 기반의 코드 작성 도구입니다.Claude, GPT, Gemini 등 다양한 모델을 기반으로 하며, 코드 생성, 디버깅, 코드 최적화 등의 기능을 제공하여 반복적이고 지루한 개발 업무를 크게 줄여줍니다.2. Backend API 개발에서의 Cursor AI 활용법Step 1: Cursor AI를 이용한 AWS EC2 정보를 호출하는 API 작성AWS EC2의 리스트를 수집하고, CloudWatch 메트릭으로 성능 데이터를 호출하는 API를 작성하도록 합니다.Fast API를 기반으로 Open API를 지원하는 프로젝트를 구성합니다.Cursor AI의 채팅창에 다음과 같이 입력합니다.Cursor AI가 점점 더 스마트해져서 이제 자동으로 테스트 코드도 만들고 생성합니다.이미 Step 1에서 를 통하여 정상적으로 API가 동작되는 것을 확인할 수 있습니다.Cursor AI를 효율적으로 활용하기 위해서는 AI가 이해하기 쉬운 문장을 작성하는 것이 중요합니다.사용자가 원하는 결과를 정확하게 전달할 수 있도록 상황과 목적을 명확히 설명하고, 불필요한 정보는 최대한 줄이는 것이 좋습니다.이렇게 하면 보다 빠르고 정확한 결과물을 얻을 수 있습니다.• None 명확한 지시어 사용: Cursor AI가 원하는 결과물을 정확히 생성하도록 지시어를 명확하게 작성합니다.• None 작은 단위로 요청: 한 번에 너무 많은 기능을 요청하지 말고 작은 단위로 나누어 요청하면 더 정확한 결과를 얻을 수 있습니다.• None 반복적으로 피드백 주기: Cursor AI와의 소통을 반복하며 점차 원하는 형태로 코드를 발전시킵니다.Cursor AI를 Backend API 개발에 활용하면 반복적인 작업을 줄이고, 더욱 중요한 비즈니스 로직에 집중할 수 있습니다.개발 효율성을 높이고 빠른 프로토타이핑이 가능하게 해주는 Cursor AI로 여러분도 더 스마트한 Backend 개발자가 되어 보세요.다음 연재에서는 Backend API를 활용하여 포털을 쉽게 구성하는 방법에 대해서 공유드리겠습니다.

대용량 트래픽을 소화하는 에이닷 전화, 통화요약, 문자 서비스를지난 2년 동안 개발/배포하며 무수히 많은 API 들의 생성과 변경이 있어왔습니다."인터페이스" 는 하나의 약속임에 따라이를 관리하는데 적지 않은 리소스가 들어가는 것을 공감하실 거라 생각합니다.• None 협업 및 관련 부서와의 소통, 히스토리 등등저 역시 아직도 번번이 이러한 이슈를 겪고 있습니다만적어도 담당하고 있는 서비스들 내에서라도 이러한 이슈를 해결하고자를 모토로, API 명세 & SDK 용 프로젝트를 개발했고지난 2년 동안 개발/운영해온 후기를 적고자합니다.이 중에 하나는 공감되실까요서버 개발자 A 와 클라이언트 개발자 B 의 사례로 문제점들을 설명드리려고 합니다.일단 코드 나가고 명세는 좀 이따 작업할게요개발자 A 가 출근한 어느 날, 급하게 연락이 와 새로운 요구사항을 전달받았습니다.일단 코드는 수정하고 명세는 나중에 변경하면 되지라고 생각하며, 명세 변경을 미루었습니다.그리고 그새 버그가 발생해 대응을 하는 동안, 명세 최신화를 까먹습니다.이제 연동하려는 다른 개발자 B 는 명세에 나와있는 대로 구현을 해도 실패가 납니다.이전에도 이런 경험이 있어, 더이상 명세를 신뢰할 수 없게 되었습니다.명세대로 동작하지 않아 매번 확인을 위해 메신저를 보내보지만, 개발자 A 는 바빠서 답장 확인이 느립니다연동이 성공할 때까지 커뮤니케이션 리소스가 더 들어가겠네요.개발자 B는 드디어 연동을 위한 올바른 API 명세를 확인했습니다.이제 코드로 구현을 해볼텐데요이럴수가! JSON 객체 필드가 10개가 넘는데, Nested JSON 도 있습니다!한 땀 한 땀 데이터 모델 클래스로 변환하다가 오타가 났는데,실제로 연동을 시도하기 전까지 어떤 부분을 실수했는지 확인도 어렵습니다.클라이언트 종류가 다양해, Android, iOS (Swift), Flutter, Javascript 코드로 각각 이를 반복합니다.시간이 흘러 개발자 B는 기존 API 를 업데이트하고자, 담당자인 개발자 A에게 연락을 했습니다.새로운 API 버젼이 많이 나와있는데, 현재 몇 버젼까지 배포가 되어있는지 묻습니다.그런데 개발자 A가 휴가를 가있어 대무를 맡은 다른 담당자는현재 배포되어있는 서버는 어떤 버젼의 명세를 구현하고 있는지 모른다고 합니다.이 후 개발자 B 는 개발자 A 가 휴가에서 복귀했다는 소식을 듣고 다시 연락을 했습니다.기존 버젼과 신규 버젼의 변경점이 많은데, 어떤게 변경되었는지 질문을 합니다.개발자 A는 시간이 많이 지나 잘 기억이 안나니, 직접 보고 비교해서 보라고 합니다.새로 추가된 필드들이 너무 많아 실수할 것만 같습니다.문제 1과 2의 원인은 명확합니다."명세를 수정하는 작업"과 "코드를 작성하는 작업"이 분리되어 있기 때문입니다.이 작업을 하나로 합쳐로 만든다면 해결할 수 있습니다.이를 가능하게 해주는 오픈소스가 바로 OpenAPI Generator 입니다.사실 개발자 분이시라면 이러한 Concept 을OpenAPI Generator 보다 protobuf 를 사용하는 gRPC 를 통해 미리 알고 계실 수도 있으실텐데요.인터페이스 명세를 원하는 프로그래밍 언어의 코드 파일로 생성해주는 오픈소스입니다.아직 지원하지 않는 기능이 좀 있지만, 이를 감안하더라도 생산성이 극대화되기 떄문에사용할 이점이 훨씬 더 크다고 판단했습니다.참고로, 팀 내 메인 Tech Stack 이 Kotlin, Gradle 프로젝트인 관계로이 오픈소스를 Gradle Plugin 으로 포팅한 플러그인 방식으로 프로젝트에 적용하였습니다.(문제 3은 후술) 문제 4는 이미 익숙한 문제라고 생각합니다.Version Control System, Git 을 통해 해결할 수 있는 문제입니다.버져닝이 되는 Wiki 도 방법이겠지만, OpenAPI 명세 파일은 일반적인 자연어가 아닌, Yaml /JSON 포맷이고API 관리 주체인 개발자가 관리하는 측면에서, 개발자에게 친숙한 Git 이 더 좋은 해결책이라고 생각합니다.API 명세의 변경과 히스토리를 커밋과 PR/MR, 코멘트 등을 통해 관리하도록 Git 프로젝트로 만들었습니다.명세 파일은 근본적으로 Yaml 혹은 JSON 포맷입니다.이를 잘 렌더링된 UI 로 보아야 비로소 가독성이라는 진가가 발휘된다고 생각합니다. (예쁜 UI는 마음이 편해지죠)UI 로 제공하는 방법들은 여러 가지 있는데요, 직접 Web UI 서버(Swagger UI, Redoc 등)를 구축해도 되지만,Gitlab 에서 자체 제공하는 OpenAPI 렌더링 기능을 이용할 수도 있습니다.저는 CI 를 통해 이러한 prefix 가 자동으로 들어가게끔 강제하였습니다.이렇게 브라우저, Gitlab UI 를 통해 볼 수 있게 됨에 따라API 명세를 공유하는 방법 역시 Git Repository 의 코드 파일 URL 을 공유하기만 하면 됩니다.따라서 자동으로 Git 에 접근할 수 있는 권한을 가진 사람만 볼 수 있도록, 인증 및 인가도 처리되구요.추가로 위에서 설명드린 OpenAPI Generator 로 생성된 코드 파일을 사용하는 방법도Gitlab 을 통해 손쉽게 이용할 수 있습니다.바로 Gitlab Package Registry 에 코드 파일을 빌드해서 배포하면, SDK/Library 처럼 pull 받아서 이용하는 방식입니다.Maven 과 같이 Public Registry 가 아닌 Private Registry 를 이용하려면, SaaS 를 사용하거나 직접 On-premise 로 구축해야할텐데요Github 뿐만 아니라 Gitlab Server 에서도 이를 지원하고 있어, 별도 구축 비용 없이 전사 시스템을 이용할 수 있었습니다.SDK/Library 를 publish 하는 작업도 maven-publish Gradle plugin 를 통해, 손쉽게 코드로 설정할 수 있었는데요.Publish 간에는 버젼값을 설정할 수 있으므로, 명세의 버젼을 그대로 이용하여 SDK 버젼으로 배포하였습니다.이를 통해 SDK 를 pull 받아 사용하는 Application 프로젝트에서는,의존성 관리 (ex. build.gradle.kts) 파일에서 특정 버젼을 명확하게 명시하게 되고

TV를 켜는 순간, 우리는 수많은 질문과 마주하게 됩니다.“지금 화면에 나오는 저 배우 어디서 많이 봤는데… 누구더라?”,“이런 줄거리의 영화 제목이 뭐더라?“콘텐츠를 소비하는 과정 자체가 이미 수많은 궁금증으로 가득 차게 됩니다.그런데 만약 나의 취향과 감정,지금 보고 있는 장면의 분위기와 등장인물, 줄거리까지 파악하고그 모든 맥락을 반영하여 추천까지 해주는 나만의 AI 미디어 친구가 있다면 어떨까요?B tv는 작년 10월, 국내 최초로 대화형 미디어 에이전트 서비스를 선보이며‘보는 TV’를 넘어 ‘소통하는 TV’로의 전환을 시작했습니다.그리고 지금, B tv는 나를 기억하고 이해하는 AI 미디어 친구로의 진화를 시도하고 있으며,그 중심에는 대화형 AI 플랫폼 에이닷이 자리하고 있습니다.이러한 진화를 위한 첫 걸음으로, 2025년 상반기에는 IPTV 3사 최초로 AI 플랫폼 에이닷과의 회원 연동을 통해사용자 개인화를 위한 첫 기반을 마련했습니다.이 글에서는 이 연동된 프로필 정보를 바탕으로,에이닷과 함께하는 B tv가 어떻게 나를 알아보고, 기억함으로써 ‘콘텐츠 플랫폼’을 넘어 ‘AI 미디어 파트너’로 진화 할 예정인지,그리고 에이닷-B tv가 실제 일상 속에서 어떻게 작동할 것이고, 어떤 가능성을 열어갈지 그 방향성과 비전을 소개하고자 합니다.첫번째 방향성, 나를 이해하는 대화 – 나를 알아보는 것부터B tv는 오랫동안 가족이 함께 사용하는 서비스로 자리 잡아 왔습니다.여러 사람이 하나의 프로필을 공유하며 이용하는 모습이 익숙한 풍경이었죠.하지만 최근 1년간의 사용 데이터를 살펴본 결과, 전체 사용자 중 약 30%가 개인 프로필을 직접 생성해 사용하는 것으로 나타났습니다.TV 안에서도 나만을 위한 경험을 바라는 니즈가 점점 뚜렷해지고 있는 겁니다.이러한 흐름에 발맞춰, B tv는 기존의 개인 프로필에에이닷의 회원 정보를 연동하며 더 깊이 있는 개인화의 기반을 갖추기 시작했습니다.단순히 TV 안의 데이터를 넘어서,에이닷과의 연동을 통해 사용자의 일상과 일정, 감정을 이해하고 반영하는더 정교하고 입체적인 개인화 대화를 실현할 수 있는 기반을 갖춘 것입니다.나만의 이름으로 시작되는 대화, 내 이름을 부르는 TV현재 B tv 에이닷에서는 아래 이미지 예시와 같이 하나의 TV에 최대 4개의 에이닷 프로필을 연동할 수 있으며,사용자를 구분해 이름을 불러주고, 나만을 위한 대화를 시작합니다.이는 단순한 계정 구분을 넘어, TV가 나를 개인으로 인식하고 대화를 시작한다는 점에서 사용자 경험에 큰 전환을 예고합니다.목소리로 나를 알아보는 TVB tv는 2023년, 휴대폰의 Wi-Fi 및 Bluetooth 신호를 활용한모바일 기반 사용자 자동 인식 기능(Auto Detection) 을 도입하며사용자별 맞춤 환경 제공의 기반을 다져왔습니다.그리고 이제 그 다음을 준비 중입니다.TV가 직접 목소리를 듣고 ‘누가 말했는지’를 구분하는 기술,이를 통해, 같은 질문이라도누가 말했느냐에 따라 TV의 설정과 응답이 달라지게 됩니다.사용자의 목소리를 인식하여 각자에게 맞는 콘텐츠, 기능, 말투까지 자동으로 구성되는 거죠.이처럼 B tv는 목소리만으로 누구인지를 알아보고,각자의 취향과 시청 히스토리를 반영한 ‘맞춤 환경’을 능동적으로 구성해주는 방향으로 진화하고 있습니다.앞으로는 리모컨을 일일이 조작하거나, 기억을 되짚으며 정확히 말하려 애쓸 필요가 없습니다.TV가 내가 누구인지, 무엇을 좋아하는지 이미 알고 기억하고 있기 때문에,그저 생각나는 대로 말만 하면 나를 위한 반응이 자연스럽게 이어지는 새로운 대화 경험의 시대가 열리는 것입니다.이처럼 앞으로 B tv가 사용자를 인식하게 되면,단순한 구분을 넘어 어떤 개인화 경험들이 가능해질까요?‘나’를 알아보는 B tv가 어떻게 나만을 위한 미디어 메이트로 진화해 나갈지, 함께 살펴보겠습니다.두 번째 방향성, 지극히 개인적인 – 나만의 TV, 나와의 TV, 에이닷B tv 에이닷이 사용자 개인을 구분할 수 있게 되면서,이제는 단순히 나를 인식하는 것을 넘어‘나에게 맞는 대화’와 ‘나만을 위한 콘텐츠’로 연결되는 개인화 경험이 본격적으로 시작됩니다.우리는 먼저 “사용자들은 어떤 개인화 경험을 원할까?”라는 질문에서 출발했습니다.그리고 실제 사용자 발화 로그를 하나하나 살펴보며“내가 좋아하는 채널만 틀어줘”, “선호하는 채널만 보고 싶어”와 같은 요청이생각보다 자주 등장하고 있다는 점을 발견했습니다.이러한 사용자 니즈를 반영하여, Btv는 정교하게 학습된 사용자의 선호와 성향을 기반으로 맞춤형 콘텐츠 콜렉션 추천을 제공할 예정입니다.이제는 말 한마디면 나만을 위한 큐레이션이 눈앞에 펼쳐지는 시대가 오는 겁니다.예를 들어 TV에서 보고 싶지 않은 채널이 나올 때,굳이 리모컨을 조작하지 않아도 “내가 좋아하는 채널 틀어줘”라고 말하면,Voice ID 기반으로 프로필이 자동으로 전환되고나의 선호 채널만 골라 보여주는 방식으로 더욱 편리한 시청 환경이 제공되는 겁니다.그때그때 궁금한 걸, 맥락까지 읽고 응답하는 – 콘텐츠 맥락 기반 실시간 응답 기능또한 에이닷은 단순한 질의응답을 넘어,콘텐츠를 보는 순간 떠오르는 다양한 궁금증에 실시간으로 반응하고,그때그때의 맥락과 사용자 정보를 고려해 더 정교하고 자연스러운 추천을 이어가는 기능을 준비중입니다.“이거 너무 잔인하지 않아?”, “이 배우 어디서 봤지?”와 같은 질문에사용자의 과거 시청 이력과 성향, 발화 문맥을 고려해더욱 자연스럽고 정교하게 응답하는 기능을 제공하게 될 것입니다.이처럼 Btv 에이닷은 단순한 VOD 추천을 넘어,콘텐츠 시청 중 떠오르는 궁금증에 실시간으로 응답하고,개인의 성향과 상황을 바탕으로 콘텐츠 경험을 확장하는 방향으로 진화해 나가고 있습니다.언젠가 우리는 이렇게 자연스럽게 이야기할 수 있을 겁니다.• None “에이닷, 이 장면 너무 진부하지 않아? 어제 그 반전 맛집 영화가 훨씬 짜릿했잖아.”• None 에이닷: "어제 보신 〈기묘한 전개〉는 확실히 긴장감 넘쳤죠. 비슷한 스타일의 추천작을 준비해둘게요!"세 번째 방향성, 말하기 전에 알아서 – 나를 알고 먼저 말을 거는 TV항상 대답만 하는

데이터 엔지니어의 Airflow 데이터 파이프라인 CI 테스트 개선기들어가며 안녕하세요, 버즈빌 데이터 엔지니어 Abel 입니다. 이번 포스팅에서는 데이터 파이프라인 CI 테스트에 소요되는 시간을 어떻게 7분대에서 3분대로 개선하였는지에 대해 소개하려 합니다. 배경 이전에 버즈빌의 데이터 플랫폼 팀에서 ‘셀프 서빙 데이터 …

29분 이상 걸리던 CS 처리를 2.9분으로 줄이다안녕하세요 29CM 세일프라이싱팀의 백엔드 개발자 김도영(Dorie)입니다.저희 팀은 고객에게 정확하고 매력적인 가격 경험을 제공하기 위해상품 등록부터 노출, 할인, 쿠폰, 결제 혜택에 이르는 전 과정의 가격 전략과 시스템 운영을 담당하고 있습니다.그 과정에서 내부 운영팀의 요청으로 상품 설정 변경이나 이관 처리 등 개발자가 직접 수동으로 대응해야 하는 CS 업무 가 반복적으로 발생하곤 합니다.오늘은 이러한 CS 업무를 LangChain 기반 AI로 자동화한 사례를 공유드리려 합니다.CS 업무로 인한 개발 생산성 병목세일프라이싱팀은 매 스프린트마다 평균 16.45건, 일 기준으로는 평균 약 3건이 넘는 CS 업무를 처리하고 있었습니다. 하나하나 보면 그리 어렵지 않은 단순 요청이지만 문제는 그 수와 반복성이었습니다.CS 요청 예시CS 한 건을 처리하는 데 평균 30분이 걸렸습니다. 이를 환산하면 하루 약 100분, 스프린트(2주) 기준으로는 8시간 이상을 반복적인 CS 작업에 사용한 셈입니다. 심한 경우에는 스프린트당 17시간이 넘기도 했습니다.생산성이 떨어진 개발자개발 리소스가 이런 운영성 업무에 지속적으로 묶이다 보니 기획된 기능 개발이나 시스템 개선에 대한 비중이 점점 줄어들 수밖에 없었습니다.그래서 저희는 반복적인 CS 업무를 대신 생각하고 대신 실행해 줄 수 있는 LangChain 기반의 AI Bot을 만들기로 했습니다.우리 팀의 손을 덜어줄 뿐 아니라 더 빠르고 더 정확하게 대응하는 자동화 흐름을 만드는 게 목표였습니다.왜 LangChain이어야 했을까?처음에는 단순한 RPA(Robotic Process Automation)만으로 해결해 볼 수 있지 않을까 생각했습니다. 하지만 곧 한계에 부딪혔습니다. 정형화된 규칙 기반의 RPA만으로는 비정형 요청의 문맥을 이해하고 적절히 대응하기 어려웠습니다.우리가 필요했던 것은 정해진 규칙의 반복 실행 이 아니라, 문맥을 이해하고 상황에 맞게 판단할 수 있는 지능형 자동화 였습니다.이런 요구에 가장 적합했던 도구가 LangChain이었습니다.LangChain은 GPT나 LLaMA 같은 대형 언어 모델(LLM, Large Language Model)을 애플리케이션에 쉽게 통합하고 구조적으로 개발할 수 있도록 돕는 프레임워크입니다.무엇보다도 LLM을 사용하게 되면서 별도의 모델 학습 없이 사내 위키, 내부 API, 권한 시스템 등과 유연하게 연결할 수 있어 복잡한 시나리오를 빠르게 구현할 수 있었습니다.특히 검색 증강 생성(RAG, Retrieval-Augmented Generation) 기법을 통해 실시간으로 내부 문서를 검색하고, 그 검색 결과를 답변에 반영함으로써 보안·비용·정확도 측면 모두에서 효율적인 구조를 만들 수 있었습니다.LLM을 활용한 LangChain은 Spring 기반 시스템과의 호환성도 뛰어났습니다. 도입 당시 Spring AI보다 훨씬 많은 기업이 이미 사용 중이었고 공식 문서도 체계적이며 실제 사례도 풍부해서 업무에 빠르게 적용 가능하다는 점에서 도입을 결정하게 되었습니다.어떻게 CS 업무 프로세스가 바뀌었을까?LangChain 기반 지능형 자동화가 기존의 업무 프로세스를 어떻게 개선했는지, 도입 이전(As-is)과 이후(To-be)를 비교하여 살펴보겠습니다.기존 프로세스기존에는 다음과 같은 수작업 과정을 거쳐야 했습니다.CS 요청자가 Jira에 티켓을 등록하고 Slack 채널에 공유담당 개발자가 티켓 내용을 확인문맥 파악을 위해 과거 티켓 또는 요청자에게 직접 문의처리 가능한 API나 수동 방법을 탐색해 직접 실행결과를 요청자에게 전달하고 요청자가 확인 후 종료이 일련의 흐름에는 평균 30분 이상이 소요되었으며 요청이 몰리는 경우엔 더 지연되고, 담당 개발자의 피로도도 심각해졌습니다. 이는 곧 핵심 기능 개발 일정에 영향을 주는 병목으로 작용했습니다.자동화 후 프로세스변화는 매우 직관적입니다.사용자가 Slack을 통해 자연어로 CS 요청을 전달하면 29CM-AI-BOT이 적절한 문서를 참조하여 실행 가능 여부를 판단하고 승인하면 사용자 확인을 거쳐 API를 실행합니다.전체 프로세스는 3분 이내로 끝나고 담당 개발자는 더 이상 CS에 소모되지 않고 고도화된 업무에 집중할 수 있습니다.어떻게 작동하는가  1. 사용자 요청 수신AI Bot에 100번 상품을 8547번 브랜드로 이관해 줘 라는 요청이 들어오면,Slack 멘션 이벤트를 수신한 AI Bot 서버는 우선 해당 요청의 내용을 분석합니다.2. 시나리오 판별 및 선택이후 분석 결과가 상품 정보 변경 유형에 해당함을 판단하고, 이에 따라 상품 정보 변경 시나리오 를 선택합니다.3. 내부 문서 검색선택된 시나리오에 따라 LangChain 기반 RAG 검색을 수행해 Confluence에 등록된 내부 API 문서 중 상품 브랜드 이관 API 문서를 탐색합니다.4. LLM을 통한 파라미터 추론LLM은 요청 내용에서 API 실행에 필요한 파라미터를 추론합니다.5. 실행 전 승인 절차이후 실질적인 API 호출 전에 사용자 승인 단계를 거칩니다. AI Bot은 다음과 같은 정보를 요청자에게 사전 제공하며 확인을 요청합니다.추출된 API 설명추론된 파라미터예상 실행 결과6. API 실행 및 결과 응답요청자가 승인 버튼을 클릭하면, AI Bot은 해당 API를 실제로 실행하고 그 결과를 요청자에게 다시 응답합니다.7. 자동화의 신뢰성과 안정성 확보이러한 구조는 사람이 직접 SQL이나 API를 찾고 실행하던 과정을 LLM과 RAG로 대체하면서도 승인 기반 가드레일을 통해 자동화의 신뢰성과 안전성을 확보합니다.품질·보안 가드레일자동화의 궁극적인 목적은 업무 효율을 높이는 것이지만, 우리가 그보다 더 중요하게 본 가치는 정확성과 신뢰성 이었습니다.사람이 아닌 봇이 실수한다면?잘못 변경한 AI Bot예를 들어 누군가가 A로 변경해줘 라고 요청했는데, AI가 잘못 이해하고 B로 변경해버린다면 이건 단순한 실수가 아니라 데이터 손상 또는 정책 위반이 될 수 있습니다. 해결책 1: 사용자 승인 기반의 안전 장치승인/반려 과정이에

CTO가 직접 만든 온디맨드 서비스의 탄생기2025년 초, 마이리얼트립은 새로운 도전에 나섰습니다. 이름하여 “온디맨드 현지도우미”. 여행자가 낯선 도시에서 실시간으로 가이드를 호출하고, 근처에 있는 현지인이 도우미로 연결되어 여행을 도와주는, 말 그대로 ‘여행판 우버’ 같은 서비스입니다. 우리나라는 물론 세계적으로도 최초로 시도하는 혁신적인 서비스라고 할 수 있죠.그런데 문제는 개발 리소스였습니다. 당장 여기에 전담할 수 있는 개발자가 없었죠. 예전 같았으면 인력을 채용하거나, 우선순위를 조정해 프로젝트를 미뤘을 겁니다.하지만 이번엔 다르게 접근했습니다.“내가 직접 개발해보자.”제가 마이리얼트립에 합류한 이후 실무 개발은 거의 4년 만이었습니다. 그동안은 조직과 구조, 기술 방향을 잡는 역할에 집중해 왔죠. 그런데도 직접 개발에 나선 이유는 단순히 리소스를 채우기 위함만은 아니었습니다.AI 시대, 개발자의 역할이 어떻게 변하고 있는지 몸소 체험해보고 싶었기 때문입니다.프로토타입부터 시작된 AI 도구와의 협업디자이너가 그려준 UX 플로우를 기준으로 웹 기반 프로토타이핑을 시작했습니다. 백엔드는 그래도 익숙했지만, 클라이언트 개발은 정말 막막했습니다. 제가 알던 웹 개발은 프리마커(Freemarker) 수준이었고, React나 Next.js는 사실상 처음이었습니다.이때부터 AI 개발툴인 Cursor의 도움을 받기 시작했습니다. 프로젝트 세팅부터 로그인 페이지, 지도 API 연동까지 — 커서는 마치 옆에서 함께 일해주는 페어 개발자 같았습니다. 디자이너가 작성한 피그마에서 html 소스를 받은 다음 “Next.js로 로그인 페이지를 만들고 아래 html 코드 형태로 스타일링해줘”라고 말하면, 금세 코드와 설명이 눈앞에 펼쳐졌습니다.가장 인상 깊었던 건 지도 기능이었습니다. 구글 맵을 모바일 웹에 최적화된 형태로 띄우고 마커를 찍는 일은 저에겐 꽤 까다롭게 느껴졌던 작업인데, AI에게 설명하자 마치 마법처럼 구현됐습니다. 이 과정을 통해 “아, 웹 개발도 내가 해볼 수 있겠구나”라는 자신감을 얻었죠.물론 AI가 완벽한 건 아니었습니다. 종종 의도와 다른 코드를 제시하거나, 문맥을 놓치고 엉뚱한 방향으로 나아가기도 했습니다. 하지만 그 과정에서 저는 중요한 교훈을 얻었습니다.AI를 제대로 활용하려면, 명확한 질문을 던지고, 기술에 대한 기본 이해가 있어야 한다는 것.이렇게 완성한 프로토타입은 내부 경영진에게 긍정적인 반응을 얻었고, 우리는 이 프로젝트에 본격적으로 투자하기로 결정했습니다.프로토타이핑 당시의 프로젝트 구조. backend/frontend 모듈로만 이뤄졌지만 저에게 frontend 모듈은 새로움의 연속이었습니다.작은 팀, 빠른 실행, 그리고 다시 AI팀은 정말 작았습니다. 저(BE), 디자이너, iOS 개발자, Android 개발자. 단 네 명.PM도 없었고, 사업개발 인력도 없었습니다. 오히려 그 덕분에 모든 구성원이 제품의 본질에 집중하며 빠르게 실행할 수 있었습니다.하지만 본격적인 개발이 시작되자, 프로토타입 단계에서 겪지 않