A1Mobilsoft의 운영 문의 자동화 여정 (1): 문제 정의와 3-에이전트 아키텍처 설계

A1Mobilsoft 가 Slack 운영 문의 대응을 자동화하며 문제를 정의하고 3-에이전트 구조를 설계한 1편이다. 32개월 846건을 분석해 첫 답변까지 평균 2.6시간이 걸리고 3.4%는 8시간 넘게 방치된다는 사실에서 출발한다. 단일 LLM 으로는 컨텍스트가 80k 토큰까지 부풀어 Supervisor 1 + 전문 에이전트 3 구조로 갈랐다.

핵심 포인트

병목이 세 갈래로 반복된다: 과거 해결책 재탐색, 어느 레포부터 볼지 모르는 코드 탐색, DB 권한자를 기다리는 시간
단일 LLM 검증에서 컨텍스트 폭증·모델 비용 비효율·도구 격리 실패 세 한계가 드러나 멀티 에이전트로 전환했다
Knowledge 는 Haiku 4.5, Code 는 Sonnet 4.6, DB 는 Haiku 4.5 로 난이도에 맞춰 모델을 분리했다
DB 접근은 rds-mcp-server 게이트웨이를 강제해 INSERT·UPDATE·DELETE 를 원천 차단했다
👍 피드백을 받은 답변이 Lambda 전처리를 거쳐 Knowledge Base 로 자동 축적된다

상세 정리

문제 규모: Slack 운영개발문의 채널 32개월치 846건, 첫 응답 중앙값은 16.7분이지만 평균은 2.6시간으로 꼬리가 길다
병목 1: 같은 문제가 분기마다 반복되는데 이전 해결책을 찾는 데 시간이 든다
병목 2: 모호한 문의에서 정확한 파일·라인까지 가는 결정론적 탐색을 사람이 매번 되풀이한다
병목 3: DB 조회 권한자가 자리에 없으면 확인 자체가 멈춘다
단일 모델 한계: Knowledge Base 결과와 코드 분석과 DB 결과를 한 컨텍스트에 넣으면 입력이 80k 근처까지 쌓인다
비용 관점: 간단한 진단은 Haiku 로 충분한데 단일 모델이면 복잡한 코드 분석 기준에 맞춰야 해 낭비가 생긴다
도구 관점: 한 에이전트가 모든 도구를 쥐면 상황에 안 맞는 도구 호출이 늘어난다
Knowledge Agent: Retrieve → LLM Rerank → Diagnosis 3단 게이트로 매칭 정확도가 낮은 후보를 떨궈낸다
Code Agent: 16개 레포를 S3 에 tar.gz 로 캐시해두고 압축을 푼 뒤 grep·file_read·Serena MCP 의 LSP 심볼 검색으로 원인을 좁힌다
DB Agent: 읽기 전용 SELECT 로 레코드 상태를 보고, needs_code_check 플래그가 서면 Code Agent 를 자동 호출한다
요청 흐름: Slack 입력을 EC2 봇이 받아 SQS FIFO 에 넣고, 180초와 60초 지연으로 추가 정보가 붙을 시간을 준 뒤 AgentCore Runtime 을 호출한다
학습 루프: 👍 표시가 붙은 사례를 Lambda 로 전처리해 S3 에 원본과 가공본을 두고 Bedrock Knowledge Base 와 OpenSearch Serverless 로 인덱싱한다
관측: CloudWatch 커스텀 메트릭으로 에이전트별 input·output·cache 토큰을 나눠 추적한다
설계 원칙: 모르면 에스컬레이션하고, SSE 로 진행 상황을 즉시 보여주며, Slack 봇은 로직 없는 무상태 워커로 둔다