5부 25장. 실제 서비스 아키텍처에 녹여내기
에이전트를 처음 만들 때는 자꾸만 별도의 실험실로 보내고 싶어진다. 작은 채팅 화면 하나를 띄워 두고, 여기에 모델을 붙이고, 도구를 몇 개 연결해 보면서 "오, 된다"를 확인한다. 여기까지는 즐겁다. 문제는 그다음이다. 실제 제품은 채팅창 하나로 끝나지 않는다. 웹 서비스가 있고, 회원 시스템이 있고, 결제와 주문이 있고, 로그와 분석이 있고, 배치 작업과 백오피스도 있다. 결국 진짜 질문은 이것이다.
에이전트를 어디에 둘 것인가?
이 질문에 답하지 못하면 에이전트는 늘 "그럴듯한 데모"로 남는다. 반대로 이 질문에 답하면 에이전트는 제품의 일부가 된다. 이번 장의 목표는 바로 여기에 있다. 에이전트를 별도 장난감이 아니라, 기존 서비스 아키텍처 안에서 역할이 분명한 구성요소로 배치하는 관점을 익히는 것이다.
에이전트는 시스템의 주인공이 아니라 한 구성요소다
많은 팀이 처음에 하는 실수는 서비스 전체를 에이전트 중심으로 다시 상상하는 것이다. 모든 요청이 에이전트를 통과하고, 모든 판단을 모델이 내리고, 모든 화면이 대화형으로 바뀔 것처럼 생각한다. 하지만 실제 제품에서는 그렇게 설계할수록 오히려 불안정해진다.
좋은 출발점은 더 소박하다. 먼저 현재 시스템에서 어느 부분이 정말로 가변적 판단을 필요로 하는지 찾는 것이다. 분류, 요약, 검색, 예외 처리, 자연어 질의, 여러 시스템을 넘나드는 작업 조율 같은 부분이 여기에 해당한다. 반대로 결제 승인, 재고 차감, 권한 검증, 정산 마감처럼 결정론적이고 규칙이 선명한 부분은 기존 소프트웨어가 더 잘한다.
즉, 제품 아키텍처에서 에이전트의 자리는 "모든 것을 대신하는 두뇌"가 아니라, 불확실한 구간을 담당하는 판단 계층에 가깝다. 복잡도는 늘 가장 낮은 수준에서 시작해야 하며, 단순한 모델 호출이나 단일 에이전트로 충분한데 멀티에이전트부터 도입하면 비용, 지연, 조정 실패가 빠르게 커진다.1
제품 안에서 에이전트가 놓이는 다섯 개의 층
실제 서비스에 에이전트를 녹여낼 때는 한 덩어리로 보지 말고 층을 나눠 생각하면 설계가 쉬워진다. 구글 클라우드의 가이드도 프런트엔드, 에이전트 개발 프레임워크, 도구, 메모리, 런타임, 모델 런타임 같은 구성요소를 구분해 보라고 권한다.2 이 관점을 제품 문맥으로 옮기면 다음 다섯 층이 특히 중요하다.
경험 층: 웹, 모바일, 사내 도구, 백오피스 화면처럼 사용자가 에이전트와 만나는 지점
애플리케이션 층: 인증, 세션, 비즈니스 규칙, API, 워크플로, 승인 절차를 관리하는 기존 서비스 백엔드
에이전트 조율 층: 모델 호출, 상태 관리, 도구 선택, 실행 루프, 재시도, 결과 합성을 담당하는 계층
도구·통합 층: 검색, 파일, 브라우저, 사내 API, SaaS, DB, 메시지 큐, MCP 서버, API 게이트웨이 같은 연결 지점
데이터·운영 층: 로그, 이벤트, 데이터 파이프라인, 피처/세만틱 레이어, 감사 기록, 모니터링, 평가 시스템
이 다섯 층을 나누어 두면 중요한 사실이 보인다. 에이전트는 가운데에 있지, 맨 위나 맨 아래에 있지 않다. 사용자를 직접 대신하지도 않고, 데이터 저장소를 직접 지배하지도 않는다. 위쪽에서 요청을 받고, 아래쪽 도구와 데이터를 활용해, 다시 애플리케이션 계층의 규칙 안에서 결과를 돌려주는 중간 계층이다.
이 관점을 놓치면 흔한 사고가 난다. 프런트엔드가 곧바로 에이전트에 붙어 인증과 권한이 새거나, 에이전트가 데이터베이스를 직접 건드려 서비스 규칙을 우회하거나, 반대로 모든 판단이 기존 백엔드에 묻혀 에이전트는 그냥 긴 문장을 만드는 요약기로 전락한다.
웹 서비스에는 동기 경로와 비동기 경로를 나눠 붙여야 한다
웹 서비스에서 가장 먼저 부딪히는 문제는 응답 시간이다. 사용자는 버튼을 눌렀는데 25초 동안 빙글빙글 도는 화면을 좋아하지 않는다. 그런데 에이전트는 생각보다 느리다. 검색도 하고, 도구도 부르고, 중간 판단도 하고, 때로는 사람 승인까지 기다린다.
그래서 서비스 아키텍처에서는 동기 경로와 비동기 경로를 분리하는 것이 중요하다.
동기 경로는 사용자가 기다리며 바로 결과를 받아야 하는 요청이다. 예를 들어 고객센터 화면에서 "이 주문 왜 지연됐지?"를 묻는 경우, 에이전트는 주문 상태와 최근 배송 이벤트를 읽고 짧은 설명을 생성해 몇 초 안에 돌려줘야 한다. 이때는 보통 단일 에이전트 또는 짧은 체인으로 제한하고, 사용할 도구 수도 작게 유지하는 편이 낫다.1
비동기 경로는 시간이 걸려도 괜찮은 작업이다. 예를 들어 "이번 주 취소 주문을 분석해서 재구매 유도 대상과 메시지 초안을 만들어 줘" 같은 요청은 백그라운드 잡으로 보내는 편이 자연스럽다. 작업 큐에 넣고, 중간 상태를 저장하고, 완료되면 알림을 보내거나 백오피스 인박스에 쌓아 두면 된다. 이런 구조는 장기 실행 작업과도 잘 맞고, 실패 복구도 훨씬 쉽다.
실무에서는 이 둘을 섞지 않는 것이 중요하다. 채팅 UI 하나로 모든 일을 처리하려고 하면, 사용자 경험은 느려지고 서버 구조는 꼬인다. "지금 답해야 하는 일"과 "맡겨 두면 되는 일"을 먼저 분리하라. 서비스 품질은 여기서 많이 갈린다.
기존 백엔드는 살아남아야 한다
에이전트를 붙인다고 해서 기존 백엔드가 사라지는 것은 아니다. 오히려 더 중요해진다. 에이전트가 자유롭게 판단할수록, 그 바깥에서 무엇이 허용되고 무엇이 금지되는지 선을 그어 주는 계층이 필요하기 때문이다.
예를 들어 환불 서비스가 있다고 하자. 에이전트는 고객 문의를 읽고 상황을 요약하고, 정책 문서를 참고하고, 필요한 경우 주문 정보를 조회할 수 있다. 하지만 실제 환불 실행은 기존 환불 서비스 API를 통해서만 이뤄져야 한다. 그 API는 주문 상태, 결제 수단, 부분 환불 가능 여부, 회계 마감 여부를 다시 검증해야 한다.
이 구조의 핵심은 단순하다. 에이전트는 제안하고, 애플리케이션은 집행한다.
이 원칙을 지키면 좋은 점이 많다. 모델이 실수해도 마지막 방어선이 남고, 감사 로그를 한곳에서 남길 수 있고, 모바일 앱이든 관리자 화면이든 같은 비즈니스 규칙을 공유할 수 있다. 반대로 에이전트가 곧바로 데이터베이스를 수정하거나 외부 API를 호출하게 두면, 제품의 진짜 규칙은 프롬프트 안으로 숨어버린다. 그 순간부터 디버깅은 추리 소설이 된다.
에이전트에게는 읽기 경로와 쓰기 경로를 따로 줘야 한다
실제 서비스 통합에서 가장 중요한 구분 하나를 꼽으라면 이것이다. 읽기와 쓰기를 분리하라.
읽기 경로는 상대적으로 넓게 열 수 있다. 검색, 문서 조회, 내부 DB 조회, 로그 분석, 과거 티켓 요약, 고객 이력 조회 같은 일은 여기에 들어간다. 물론 개인정보와 민감정보는 가려야 하지만, 대체로 읽기는 "잘못 읽으면 품질 문제"로 끝나는 경우가 많다.
반면 쓰기 경로는 다르다. 티켓 생성, 할인 쿠폰 발급, 주문 변경, 환불 요청, 공지 발송, CRM 업데이트, 코드 배포 같은 일은 시스템 상태를 바꾼다. 이런 경로는 훨씬 더 좁아야 하고, 역할 기반 권한, 입력 검증, idempotency key, 승인 절차, 속도 제한, 감사 로그가 필요하다. MCP나 API 관리 계층을 쓰더라도, 그 위에 실행 정책은 별도로 있어야 한다.26
생산 환경에서 팀들이 고생하는 지점도 대부분 여기다. 도구를 발견하는 일보다, 사용자별 인증 토큰을 안전하게 다루고, 만료를 갱신하고, 재시도와 레이트 리밋을 처리하고, 버전 변경을 따라가고, 남용을 막는 일이 훨씬 어렵다.6
쉽게 말해 읽기 도구는 "도서관 출입증"에 가깝고, 쓰기 도구는 "법인 인감"에 가깝다. 둘을 같은 바구니에 넣으면 반드시 사고가 난다.
데이터 파이프라인은 에이전트의 뒷정리 팀이다
에이전트를 처음 붙일 때는 자꾸 모든 것을 실시간으로 읽게 만들고 싶어진다. 하지만 실제 제품에서는 그 방식이 비싸고 느리고 불안정하다. 에이전트가 매번 원시 로그, CSV, 티켓 원문, 여러 테이블 조인을 직접 해석하게 만들면 똑똑해 보이기 전에 먼저 지친다.
그래서 좋은 아키텍처에서는 데이터 파이프라인이 먼저 움직인다. 실시간 이벤트나 배치 파이프라인이 데이터를 정리하고, 정규화하고, 필요한 요약값과 세만틱 레이어를 만들어 둔다. 그러면 에이전트는 원재료 창고에 들어가는 대신, 이미 정리된 작업대에서 일할 수 있다.4
예를 들어 마케팅 운영 에이전트를 만든다고 해보자. 고객 피드백 원문을 매번 읽게 하는 대신, 데이터 파이프라인이 미리 감성 점수, 이슈 분류, 최신 캠페인 성과, 제품 카테고리 매핑을 계산해 둔다. 스노우플레이크가 소개한 것처럼 AI 함수를 이용해 텍스트를 미리 분류·요약하고, 동적 테이블이나 세만틱 뷰를 만들어 두면, 에이전트는 훨씬 빠르고 값싸게 질문에 답할 수 있다.5
여기서 중요한 발상의 전환이 있다. 에이전트는 데이터 엔지니어를 대체하는 것이 아니라, 잘 준비된 데이터 위에서 더 유연한 인터페이스를 제공하는 것이다.
즉, 데이터 파이프라인은 에이전트의 경쟁자가 아니다. 오히려 최고의 조력자다. 정제된 지표와 세만틱 레이어 없이 자연어 에이전트만 앞세우면, 멋지게 말하는데 자꾸 틀리는 시스템이 된다.
이벤트 기반 구조는 에이전트를 제품 속으로 자연스럽게 넣어 준다
기존 모놀리식 서비스는 대체로 "사용자가 요청하면 서버가 응답한다"는 리듬에 맞춰 설계되어 있다. 하지만 에이전트는 종종 다른 리듬으로 움직인다. 주문 취소 이벤트가 생기면 분석을 시작하고, 결제 실패가 누적되면 운영자에게 요약을 보내고, 새로운 문서가 업로드되면 분류와 태깅을 돌린다. 즉, 에이전트는 요청-응답형 기능이기도 하지만 동시에 이벤트 구독형 작업자이기도 하다.3
마이크로서비스와 이벤트 기반 설계는 여기서 큰 힘을 발휘한다. 주문 서비스, 티켓 서비스, 문서 서비스, 배치 파이프라인이 각자 이벤트를 발행하고, 에이전트는 필요한 것만 구독해 반응한다. 이 구조의 장점은 결합도가 낮다는 점이다. 주문 서비스는 "누가 이 이벤트를 쓸지" 몰라도 되고, 에이전트는 필요한 컨텍스트를 모아 별도의 작업을 수행하면 된다.34
다만 이때도 주의할 점이 있다. 에이전트가 이벤트를 받아 바로 외부 상태를 바꾸게 하지 말고, 중간에 정책 계층이나 작업 큐를 두는 편이 안전하다. 예를 들어 "취소 주문 발생" 이벤트를 받았다고 해서 곧바로 할인 쿠폰을 발급하는 대신, 먼저 후보를 생성하고, 기준에 맞는지 평가하고, 승인을 거쳐 CRM 액션으로 넘기는 식이다. 이벤트는 시작 신호이지, 면허증이 아니다.
백오피스는 에이전트가 가장 먼저 빛나는 곳이다
흥미롭게도 에이전트는 소비자-facing 화면보다 백오피스에서 더 빨리 가치를 내는 경우가 많다. 이유는 간단하다. 내부 운영 도구는 원래도 사람이 여러 시스템을 오가며 판단하고 정리하던 곳이기 때문이다.
백오피스 통합에서 특히 효과적인 패턴은 세 가지다.
자연어 질의 인터페이스: 운영자가 "지난 7일간 환불 증가 원인을 요약해 줘"처럼 묻고, 에이전트가 세만틱 레이어와 검색 도구를 활용해 답하는 방식
작업 보조 인터페이스: 티켓 처리, 승인안 초안 작성, 이상 사례 요약처럼 사람이 최종 결정을 내리기 전까지의 준비 작업을 줄이는 방식
권고안+실행 분리 인터페이스: 에이전트가 추천 액션을 만들되, 실제 실행은 운영자가 확인 버튼을 눌러야만 이뤄지게 하는 방식
이 세 패턴은 제품에 부담을 적게 주면서도 효과를 보기 쉽다. 사용자에게 바로 노출되지 않으니 실패 비용이 낮고, 사람 검토가 자연스럽게 끼어들 수 있으며, 로그와 피드백을 모으기도 좋다. 많은 팀이 외부 챗봇부터 만들다가 고생하는 이유는, 가장 쉬운 진입로를 놔두고 가장 까다로운 공개 무대부터 올라가기 때문이다.
도구 연결은 API 몇 개 붙인다고 끝나지 않는다
서비스 아키텍처에 에이전트를 붙일 때, 겉으로는 도구 연결이 쉬워 보인다. 함수 스키마를 정의하고, 모델이 JSON을 내놓으면, 백엔드가 그걸 실행하면 된다. 하지만 생산 환경으로 가는 순간 어려움이 시작된다.
직접 API를 몇 개만 붙이는 방식은 초기에는 빠르다. 그러나 통합 대상이 늘어나면 인증 방식이 제각각이고, 응답 형식도 다르고, 실패 처리도 다르고, API 버전도 제각각이라 유지보수가 급격히 커진다. 그래서 일정 규모를 넘기면 도구를 중앙에서 관리하는 계층이 필요해진다. MCP는 도구를 표준 방식으로 노출하는 데 유용하고, API 관리 플랫폼은 인증, 정책, 모니터링, 카탈로그, 레이트 리밋을 다루는 데 유용하다.26
여기서 기억해야 할 점은 둘이 경쟁 관계가 아니라는 것이다. MCP는 연결 형식을 표준화하고, API 관리 계층은 운영 책임을 표준화한다. 하나는 말하는 방식이고, 다른 하나는 통제하는 방식이다. 둘을 함께 써야 "도구가 많아져도 서비스가 무너지지 않는 구조"가 나온다.
제품 아키텍처의 핵심은 에이전트를 얇게 두는 것이다
초기 설계에서 자주 나오는 유혹은 에이전트 서버 하나에 모든 것을 몰아넣는 것이다. 채팅 API도 있고, 인증도 있고, 비즈니스 로직도 있고, 도구 실행도 있고, 파일 처리도 있고, 상태 저장도 있고, 운영 대시보드도 있는 거대한 에이전트 백엔드 말이다. 처음엔 편하지만, 시간이 지나면 이 서버는 모든 것을 조금씩 아는 대신 아무것도 선명하게 책임지지 않는 괴물이 된다.
실전에서는 에이전트 계층을 가능한 한 얇게 유지하는 편이 좋다. 에이전트는 다음 역할에 집중하면 된다.
사용자의 목표를 해석한다.
필요한 컨텍스트를 모은다.
어떤 도구나 서브플로를 쓸지 결정한다.
결과를 사람이나 다른 서비스가 이해할 수 있는 형태로 정리한다.
그 외의 인증, 비즈니스 검증, 영속 상태 관리, 감사 기록, 데이터 정합성, 장기 작업 스케줄링은 가능한 한 기존 플랫폼 계층이 맡아야 한다. 마치 좋은 셰프가 재배부터 설거지까지 혼자 다 하지 않듯, 에이전트도 모든 일을 직접 하려 들면 금방 품질이 흔들린다.
하나의 예시로 보는 통합 구조
예를 들어 "운영 지원 에이전트"를 기존 SaaS 서비스에 붙인다고 해보자.
사용자는 관리자 웹 화면에서 자연어로 질문하거나 작업을 요청한다. 프런트엔드는 요청을 기존 백엔드 API로 보낸다. 백엔드는 사용자 인증과 권한을 확인하고, 이것이 즉시 응답할 요청인지, 백그라운드 작업인지 분류한다. 즉시 응답 가능한 경우에만 에이전트 조율 계층으로 넘긴다.
에이전트 조율 계층은 세션 상태와 요청 목적을 받아 필요한 도구 목록을 좁힌다. 검색 도구로 정책 문서를 찾고, 읽기 전용 내부 API로 주문과 고객 상태를 조회하고, 결과를 합쳐 설명이나 권고안을 만든다. 만약 "환불 실행" 같은 변경 요청이라면, 곧바로 쓰기 도구를 호출하지 않는다. 먼저 실행 계획과 근거를 구조화해 백엔드의 승인 워크플로 API로 돌려보낸다.
승인 후에야 백엔드는 내부 환불 서비스 API를 호출한다. 결과는 감사 로그와 이벤트 버스로 기록된다. 데이터 파이프라인은 이후 이 이벤트를 받아 운영 분석용 지표를 갱신하고, 에이전트 품질 평가에도 활용할 수 있다. 사용자는 화면에서 결과만 본다. 하지만 뒤에서는 웹 서비스, 승인 시스템, 내부 API, 이벤트 버스, 데이터 파이프라인이 모두 협력하고 있는 셈이다.
이 구조가 좋은 이유는 에이전트가 똑똑해서가 아니다. 에이전트가 똑똑하지 않아도 서비스가 버틸 수 있게 설계되어 있기 때문이다.
데모를 제품으로 바꾸는 마지막 질문
마지막으로, 에이전트를 실제 서비스 아키텍처에 넣기 전에 팀이 꼭 던져야 할 질문이 있다.
이 기능은 정말 에이전트가 필요하며, 단순 API나 워크플로로는 부족한가?
동기 응답과 비동기 작업이 분리되어 있는가?
읽기 도구와 쓰기 도구의 권한 모델이 다른가?
비즈니스 규칙의 최종 집행자는 여전히 기존 서비스 계층인가?
에이전트가 쓰는 데이터는 원시 데이터가 아니라 준비된 컨텍스트인가?
실패했을 때 재시도, 보류, 사람 승인, 롤백 경로가 있는가?
로그, 추적, 감사 기록이 모델 밖에서도 남는가?
이 질문에 답하지 못하면, 지금 만든 것은 기능이 아니라 시연일 가능성이 크다. 반대로 이 질문에 답할 수 있다면, 에이전트는 더 이상 실험물이 아니다. 이미 제품의 일부다.
이번 장의 결론
실제 서비스 아키텍처에서 에이전트는 마법 상자가 아니다. 웹 서비스 위에 덧씌우는 화려한 껍데기도 아니고, 기존 시스템을 갈아엎는 새로운 왕도 아니다. 에이전트는 기존 제품 구조 안에서, 불확실한 판단과 다단계 조율을 담당하는 하나의 계층이다.
좋은 설계는 늘 같은 방향을 가리킨다. 복잡도는 낮게 시작하고, 기존 백엔드는 규칙의 주인으로 남겨 두고, 읽기와 쓰기를 분리하고, 데이터는 미리 준비하고, 이벤트와 백그라운드 처리로 무거운 작업을 흡수하고, 백오피스부터 실용적으로 확장하는 것이다. 그렇게 해야 에이전트는 실험실을 나와 제품 안에서 오래 살아남는다.
결국 중요한 것은 "에이전트를 어디에 붙일까?"가 아니다. 더 정확한 질문은 이것이다.
우리 제품의 어느 경계에서, 에이전트가 가장 적은 위험으로 가장 큰 판단 가치를 만들 수 있는가?
그 경계를 찾았다면, 이제 에이전트는 기능이 아니라 아키텍처가 된다.
참고
1AI Agent Orchestration Patterns - Azure Architecture Center
2Choose agentic AI architecture components - Google Cloud
3Architecting microservices for seamless agentic AI integration
4Building Data Pipelines and LLM Integration for Agentic Workflows
5From Zero to Agents: Building End-to-End Data Pipelines for an AI Agent
6APIs for AI Agents: The 5 Integration Patterns (2026 Guide)
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.