업무용 AI 비서의 탄생 (1편) 도구 네 개를 MCP로 연결하기

이슈 하나를 볼 때마다 이슈 트래커, 사내 위키, 모니터링, 운영 DB를 손으로 오가던 일을, 네 도구를 MCP로 한 AI 비서에 연결해 맡겼습니다. 질문을 한 번 던지면 비서가 필요한 도구를 직접 호출해 자료를 모아 오기 때문에, 도구 사이를 오가며 맥락을 머리에 들고 다니던 부담이 줄었습니다. 대신 환각과 권한, 토큰 비용은 남아 있고 결론은 사람이 한 번 검증해야 합니다.

이 글과 현재 경력 기록의 범위

이 글은 이슈 트래커·위키·모니터링·운영 DB 네 도구를 연결한 초기 단계입니다. 이후 문서 도구까지 포함한 다섯 시스템 연동으로 확장했고, 제가 제안하고 구현한 업무용 AI가 팀 승인을 거쳐 공식 프로젝트로 진행됐습니다. 초기 네 도구 구성과 이후 다섯 시스템 기록은 서로 다른 시점입니다.

개인 RAG의 저장소나 검색 방식도 시점에 따라 달라졌습니다. 이 글의 구성을 현재 모든 환경의 배포 상태로 읽기보다, 도구 간 자료 수집을 어떻게 묶었는지에 초점을 맞춰 읽어 주세요.

연결보다 어려웠던 검증 경계

사람 대신 도구를 호출하게 하는 것과 분석을 믿고 실행하는 것은 별개입니다. 다음은 이 경험을 바탕으로 정리한 검증 기준입니다. 현재 모든 항목을 자동화했다는 뜻은 아닙니다.

에이전트 계정이 사람보다 넓은 권한을 갖지 않도록 하고, 문서 검색 결과도 요청자의 접근 권한을 따라야 합니다. 운영 DB는 읽기 전용 계정만으로 끝내지 않고 허용 쿼리·시간·행 수를 제한해야 합니다. 문서 속 지시는 실행 권한이 아니라 분석할 자료로 취급합니다.

성공 기준도 “답변이 그럴듯하다”보다 근거 링크가 유효한지, 답할 수 없는 질문에서 모른다고 하는지, 권한 밖 자료를 노출하지 않는지로 잡는 편이 낫습니다. 이 평가를 동일 질문 세트로 반복하기 전에는 생산성 향상을 배수로 표현하지 않겠습니다.

비서를 만들기로 한 날

어느 날 운영 이슈 하나를 들여다보다가, 제가 분석이 아니라 자료 수집만 하고 있다는 걸 깨달았습니다.

이슈 트래커에서 티켓을 읽고, “이거 원래 설계가 어떻게 돼 있더라” 싶으면 사내 위키를 뒤지고, 언제부터 터졌는지 보려고 모니터링을 켜고, “데이터가 진짜 그런가” 확인하려고 운영 DB에 쿼리를 날립니다. 창을 네 개 띄워놓고 알트탭을 백 번쯤 누릅니다. 정작 머리를 써야 할 원인 추론은 이 자료를 다 모으고 나서야 시작됩니다.

여기서 든 생각은 단순했습니다. 자료를 줍는 일은 제가 할 게 아니라 누가 대신 해줘야 하는 일이라는 것입니다. 그래서 회사 일에 쓸 업무용 AI 비서를 하나 만들기로 했습니다. 개인용 비서가 아니라, 업무 도구들에 직접 손을 뻗는 비서입니다.

예전에 Datadog MCP로 단일 도구 분석을 자동화한 글을 쓴 적이 있는데, 그게 이 비서의 출발점이었습니다. 도구 하나를 자동화해보니, 다음은 자연스럽게 “그럼 네 개를 한꺼번에 엮으면?”이 됐습니다.

이 이야기는 2편으로 나눠 풀겠습니다. 1편인 이번 글은 여러 도구를 한 비서에 엮어 자료 수집을 통째로 넘긴 과정이고, 2편은 그 비서에 기억을 입힌 과정입니다.

왜 굳이 비서까지 필요했나

제가 하던 방식을 그대로 옮기면 이렇습니다.

1. 이슈 트래커에서 티켓 읽기        (무슨 증상인지)
2. 사내 위키에서 관련 설계 문서 찾기  (원래 어떻게 동작해야 하는지)
3. 모니터링에서 에러 추이 확인        (언제부터, 얼마나)
4. 운영 DB에 직접 쿼리               (데이터가 실제로 어떤지)
5. 1~4를 머릿속에서 합쳐 원인 추론

병목은 5번이 아니라 1~4번이었습니다.

도구마다 검색 문법이 다르고, 로그인 세션이 다르고, “이 티켓이랑 저 설계 문서가 같은 얘기인가”를 매번 사람이 머릿속에서 이어 붙여야 했습니다. 한 도구에서 다른 도구로 넘어갈 때마다 방금 본 내용을 잠깐 머리에 들고 있어야 하는데, 이 컨텍스트 스위칭이 생각보다 비쌌습니다.

게다가 어느 도구를 먼저 볼지가 그날의 감이었습니다. 운이 좋으면 두 번째 도구에서 답이 나오고, 나쁘면 네 곳을 다 돈 뒤에야 “아 이건 위키부터 봤어야 했네” 합니다. 숙련으로 줄일 수는 있어도, 매번 드는 고정 비용은 사라지지 않았습니다. 비서가 필요했던 건 이 고정 비용 때문이었습니다.

비서에게 네 도구를 쥐여주다

MCP(Model Context Protocol)는 LLM이 외부 도구를 직접 호출할 수 있게 해주는 규격입니다. 쉽게 말하면 “AI한테 도구 사용법을 표준 콘센트로 꽂아주는 것”입니다. 콘센트 모양만 맞으면 이슈 트래커든 DB든 같은 방식으로 꽂힙니다.

비서를 만들 때의 핵심은 도구를 하나만 꽂지 않고, 분석에 필요한 네 곳을 전부 꽂아둔 것입니다.

아래는 구성의 개념도이며 설치 명령이 아닙니다. 이전 예시의 npm 패키지명은 공식 배포·버전을 검증한 목록이 아니어서 실행 가능한 설정처럼 제시하지 않도록 제거했습니다.

업무 AI 클라이언트
  → 검증된 이슈 트래커 MCP 연결
  → 검증된 문서 MCP 연결
  → 검증된 모니터링 MCP 연결
  → 권한과 쿼리가 제한된 DB 조회 도구

실제 설정은 각 제공자의 공식 설치 안내, 지원 transport, 인증 방식, 사용 권한을 확인해 작성해야 합니다. 공개된 동명의 패키지를 -y 옵션으로 즉시 실행하는 방식은 재현 절차가 아닙니다.

이렇게 물려두면, 비서는 질문을 받았을 때 어느 도구를 몇 번 호출할지를 스스로 정합니다. 사람이 “이건 위키부터 봐”라고 순서를 지정하지 않습니다. “결제 정산 이슈 OO 원인 좀 좁혀줘”라고 한 줄 던지면, 비서가 알아서 티켓을 읽고, 관련 설계 문서를 찾고, 같은 기간 모니터링을 보고, 필요하면 DB까지 확인한 뒤 그걸 다 합쳐서 돌려줍니다.

흐름으로 그리면 이렇습니다.

flowchart TD
    Q["질문 한 줄<br/>(자연어)"] --> A[업무용 AI 비서]
    A -->|필요한 만큼 호출| T1[이슈 트래커]
    A -->|필요한 만큼 호출| T2[사내 위키]
    A -->|필요한 만큼 호출| T3[모니터링]
    A -->|필요한 만큼 호출| T4[운영 DB]
    T1 --> M[응집된 분석]
    T2 --> M
    T3 --> M
    T4 --> M
    M --> R["원인 가설 + 근거<br/>한 덩어리로 회신"]

    style A fill:#e0e7ff,stroke:#4F46E5,stroke-width:2px,color:#1a1a1a
    style M fill:#d1fae5,stroke:#059669,stroke-width:2px,color:#1a1a1a
    style R fill:#e0f2fe,stroke:#0EA5E9,stroke-width:2px,color:#1a1a1a

예전 그림과 결정적으로 다른 건 화살표의 방향입니다. 전에는 사람이 도구를 향해 네 번 걸어갔다면, 지금은 도구들이 한곳으로 모여 한 덩어리로 돌아옵니다.

비서가 일하는 방식

비서가 생기고 가장 크게 바뀐 건 컨텍스트를 모으는 주체입니다.

전에는 자료 수집(사람) → 추론(사람)이었습니다. 지금은 자료 수집(비서) → 추론(비서가 1차, 사람이 검증)입니다. 사람이 알트탭을 누르며 머리에 이고 다니던 부분이 통째로 빠졌습니다.

품질도 묘하게 올라갔습니다. 사람이 네 도구를 돌면 보통 “급해 보이는 것”만 골라 보게 되는데, 비서는 네 곳을 빠짐없이 긁어와서 한 번에 엮습니다. 그래서 “티켓엔 결제 실패라고 적혔는데, 모니터링을 보면 사실 그 앞단 외부 연동이 먼저 흔들렸다” 같은, 도구 사이에 걸쳐 있어서 사람이 놓치기 쉬운 연결을 더 자주 짚어줍니다. 흩어진 자료가 아니라 밀도 있게 모인 한 덩어리로 돌아오는 게 체감상 가장 컸습니다.

비서를 믿되 검증한다

좋은 점만 적으면 거짓말입니다. 비서를 쓰면서 분명히 보인 한계가 있었습니다.

LLM은 그럴듯하게 틀립니다. 네 도구에서 긁어온 근거가 진짜인지, 비서가 중간을 메우려고 지어낸 건 아닌지는 결국 사람이 한 번 봐야 합니다. 그래서 저는 비서에게 항상 출처를 같이 달라고 시킵니다. “이 결론은 어느 티켓, 어느 로그를 근거로 했는지” 링크가 없으면 그 결론은 믿지 않습니다.

권한도 신경 써야 합니다. DB까지 꽂아둔 만큼, 비서에 주는 계정은 읽기 전용으로 묶고, 운영 DB는 조회만 허용했습니다. “AI가 알아서 다 한다”는 편리함과 “AI가 운영 데이터를 건드린다”는 위험은 종이 한 장 차이입니다.

마지막은 토큰 비용입니다. 네 도구를 다 긁어오면 그만큼 LLM에 들어가는 입력이 커집니다. 그래서 모든 질문을 비서에게 보내지는 않고, 도구 두세 곳을 엮어야 하는 분석성 질문에만 씁니다. 단순 조회는 그냥 그 도구를 직접 봅니다.

마무리

비서가 자료를 대신 모아주기 시작하니, 제가 할 일은 비서가 모아온 걸 의심하고 검증하는 쪽으로 옮겨갔습니다. 자료를 줍는 일에서 자료를 판단하는 일로 무게중심이 이동한 것인데, 개인적으로는 이쪽이 사람이 할 만한 일이라고 느낍니다.

도구를 엮고 보니 아쉬운 점이 하나 있었습니다. 비서가 질문마다 매번 백지에서 도구를 긁다 보니, “저번에 비슷한 이슈 봤는데” 하는 맥락이 전혀 쌓이질 않았습니다. 2편에서는 이 비서에 기억을 붙인 이야기를 다룹니다. 제 질문들을 로컬 벡터 저장소에 쌓고, 이중 인덱싱으로 과거 맥락과 도메인 인사이트를 프롬프트에 얹은 과정입니다.

2편 - 기억을 입히는 이중 인덱싱에서 계속

읽어주셔서 감사합니다.🖐