업무용 AI 비서의 탄생 (1편) — 도구 네 개를 한 에이전트에 엮기

TL;DR

• 계기: 이슈 하나 들여다보려면 이슈 트래커, 사내 위키, 모니터링, 운영 DB를 매번 손으로 오가야 했습니다.
• 결심: 분석에 필요한 정보가 네 곳에 흩어져 있어서, 그 자료를 모으는 일 자체를 대신해 줄 비서를 만들기로 했습니다.
• 탄생: 업무용 AI 비서에 네 도구를 MCP로 한꺼번에 물려서, LLM이 직접 여러 도구를 호출해 데이터를 모으게 했습니다.
• 변화: 도구를 오가던 컨텍스트 스위칭이 사라지고, 질문 한 번에 응집된 분석이 돌아옵니다.
• 한계: 환각·권한·토큰 비용이 남고, 결론은 결국 사람이 한 번 검증해야 합니다.

비서를 만들기로 한 날

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

이슈 트래커에서 티켓을 읽고, “이거 원래 설계가 어떻게 돼 있더라” 싶으면 사내 위키를 뒤지고, 언제부터 터졌는지 보려고 모니터링을 켜고, “데이터가 진짜 그런가” 확인하려고 운영 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든 같은 방식으로 꽂힙니다.

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

{
  "mcpServers": {
    "issue-tracker": { "command": "npx", "args": ["-y", "mcp-server-jira"] },
    "wiki":          { "command": "npx", "args": ["-y", "mcp-server-confluence"] },
    "monitoring":    { "command": "npx", "args": ["-y", "mcp-server-datadog"] },
    "db":            { "command": "npx", "args": ["-y", "mcp-server-mysql"] }
  }
}

이렇게 물려두면, 비서는 질문을 받았을 때 어느 도구를 몇 번 호출할지를 스스로 정합니다. 사람이 “이건 위키부터 봐”라고 순서를 지정하지 않습니다. “결제 정산 이슈 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에 들어가는 입력이 커집니다. 그래서 모든 질문을 비서에게 보내지는 않고, 도구 두세 곳을 엮어야 하는 분석성 질문에만 씁니다. 단순 조회는 그냥 그 도구를 직접 봅니다.

비슷한 비서를 만들 때 점검할 것

• 도구를 묶어서 꽂았는가: 단일 도구 자동화보다, 분석에 필요한 도구를 한 비서에 함께 물릴 때 컨텍스트 응집 효과가 납니다.
• 출처를 강제했는가: 결론마다 근거 링크를 같이 받게 해야 환각을 거를 수 있습니다.
• 권한을 좁혔는가: 특히 DB 같은 쓰기 가능한 도구는 읽기 전용 계정으로 묶었는지 확인합니다.
• 비서에게 보낼 질문을 골랐는가: 도구 여러 곳을 엮는 분석성 질문에만 쓰고, 단순 조회는 직접 봅니다.
• 비용을 보고 있는가: 입력이 커지는 구조라 토큰 사용량을 주기적으로 들여다봐야 합니다.

마무리

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

여기까지가 비서의 탄생입니다. 그런데 도구를 엮고 보니 한 가지가 아쉬웠습니다. 비서가 질문마다 매번 백지에서 도구를 긁다 보니, “저번에 비슷한 이슈 봤는데” 하는 맥락이 전혀 쌓이질 않았습니다.

다음 편 예고

2편에서는 이 비서에 기억을 붙인 이야기를 다룹니다. 제 질문들을 로컬 벡터 저장소에 쌓고, 이중 인덱싱으로 과거 맥락과 도메인 인사이트까지 프롬프트에 얹으면서, 업무 효율이 몇 배로 뛴 과정입니다.

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

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