사내 서비스 셋을 티켓 시스템 하나로 잇기: AI 도우미 요청과 회의록 할 일이 티켓이 되기까지 (MCP는 왜 아직 아닌가)

요약. 운영 대시보드의 AI 도우미가 받은 요청과, 보고서 서비스에 올라온 회의록의 할 일을 업무 티켓 시스템으로 보내도록 이었습니다. 서비스끼리 짝지어 잇지 않고, 모두 티켓 시스템의 연동 API 하나에만 맞췄습니다. 티켓을 만드는 일은 MCP가 아니라 이 연동 API로 합니다. MCP 서버는 사람을 대신해 티켓을 읽고 처리하는 창구로 따로 있습니다.

5화의 N×M 문제가 회사 안에서 생겼다

저희 팀에는 사내 서비스가 셋 있습니다. 업무 화면을 모은 운영 대시보드, 할 일을 관리하는 업무 티켓 시스템, 보고서와 회의록을 올리는 보고서 서비스입니다.

일은 대시보드와 보고서 서비스에서 생기고, 처리는 티켓 시스템에서 합니다. 대시보드를 쓰다가 "이 표에 이것도 보여 주면 좋겠다"는 요청이 생기고, 회의가 끝나면 할 일이 생깁니다. 이걸 티켓 시스템으로 바로 보내는 것이 이번 작업의 목표였습니다.

서비스가 둘일 때는 짝지어 이으면 됩니다. 하지만 AI를 쓰는 사내 앱은 계속 늘어납니다. 5화에서 본 "앱 N개 × 도구 M개" 문제가 회사 안에서도 그대로 생깁니다.

이번 작업에서 제가 한 일은 기획입니다. 어떤 서비스가 무엇을 티켓으로 보낼지, 사람이 어디서 확인할지를 정했습니다. 코드는 대부분 Claude Code가 썼습니다.

{경험: 사용자가 채움 — Claude Code 없이 했다면 이 연결에 무엇이 더 필요했을지, 또는 직접 기획만 하면서 느낀 점 한두 문장}

가운데 하나에 맞추기: 티켓 시스템의 연동 API

그림 1. 서비스들은 서로 잇지 않고 가운데 티켓 시스템에만 맞춥니다.

구조는 단순합니다. 티켓 시스템이 가운데에 서고, 다른 서비스는 티켓 시스템의 연동 API 하나에만 맞춥니다. 서비스가 하나 늘어도 그 서비스가 연동 API에 한 번 맞추면 끝입니다.

연동 API는 두 번에 걸쳐 자랐습니다. 7월 말 첫판은 공용 키 하나로 티켓을 만드는 것이 전부였고, 프로젝트와 담당자는 서버에 고정돼 있었습니다. 10월 중순 둘째 판에서 많은 것이 바뀌었습니다.

• 서비스별 키. 부르는 서비스마다 키를 따로 줍니다. 키 하나를 끊어도 다른 서비스는 멈추지 않습니다. 짝마다 키를 나눠 갖는 방식은 서비스가 늘면 키도 곱으로 늘어난다는 메모가 설계 문서에 남아 있습니다.
• 받는 쪽이 정한다. 어느 프로젝트가 어느 서비스의 티켓을 받을지는 티켓 시스템에서 프로젝트 담당자가 켭니다. 기본은 꺼짐입니다. 담당자로 지정할 수 있는 사람인지도 티켓 시스템이 판단합니다.
• 두 번 보내도 한 장. 만들기 요청에 중복 방지 키를 붙입니다. 같은 키가 다시 오면 새로 만들지 않고 처음 만든 티켓을 돌려줍니다.
• 상태는 부르는 쪽이 조회. 티켓 시스템이 밖으로 알려 주는 기능(웹훅)이 없어서, 부르는 서비스가 키 묶음으로 상태를 한꺼번에 물어봅니다.
• 요청 기록. 모든 호출을 요청 번호와 함께 남겨, 문제가 생기면 양쪽에서 같은 번호로 찾습니다.

티켓 만들기는 왜 MCP가 아닐까

5화와 6화에서 MCP를 다뤘으니, 티켓도 MCP로 만든다고 짐작하기 쉽습니다. 그런데 티켓을 만드는 일은 MCP가 아니라 위의 연동 API로 합니다.

티켓 시스템에는 MCP 서버가 따로 있습니다. 도구는 다섯 개입니다. 티켓 목록, 상세, 검색, 상태 바꾸기, 댓글 달기입니다. 이 서버는 "특정 사람을 대신해, 그 사람의 권한으로" 움직이도록 설계됐습니다. 요청마다 그 사람의 로그인 토큰을 확인하고, 그 사람으로서 티켓 시스템을 부릅니다.

반면 대시보드나 보고서 서비스가 만드는 티켓은 서비스가 보내는 티켓입니다. 사람의 권한보다 "어느 서비스가 보냈나"가 중요합니다. 그리고 MCP 도구에는 티켓 만들기와 첨부가 없습니다. 그래서 대시보드 기획 문서에는 이렇게 정리돼 있습니다. 만들기와 상태 조회는 연동 API로, MCP는 개발팀의 Claude Code가 티켓을 읽고 처리하는 쪽에 씁니다. 연동 계약 문서의 원칙도 "연동 API 먼저, MCP는 나중"입니다.

MCP를 안 쓰는 게 아니라 쓰는 자리가 다릅니다. 앞으로 AI를 쓰는 사내 앱이 사용자를 대신해 티켓을 찾고 댓글을 다는 일은 MCP 서버가 맡습니다. 예를 들어 보고서 서비스의 대화형 검색 챗봇은 지금 도구를 쓰지 않는데, 나중에 이런 앱이 MCP 클라이언트가 될 수 있습니다.

AI 도우미에게 한 말이 티켓이 되기까지

그림 2. 모델은 초안과 목업까지 만들고, 티켓은 사람이 등록을 눌러야 생깁니다.

대시보드에는 화면 구석에 AI 도우미가 있습니다. 사용자가 "이 표에 지난달 값도 보여 주세요"처럼 말하면 다음 순서로 티켓이 됩니다.

1. 정리. 모델이 대화를 읽고 "어느 화면의, 지금은 어떻고, 바꾸면 어떻게, 그대로 둘 것은"으로 정리합니다. 애매하면 확인 질문을 하나 합니다.
2. 초안. 제목, 요청, 이유, 급한 정도를 채웁니다. 요청은 사용자 말 그대로 쓰고 지어내지 않게 했습니다. 모델이 실패하면 사용자 원문으로 만든 초안을 대신 돌려줍니다. 코드 주석에는 "요청을 잃는 쪽이 어색한 초안보다 비싸다"고 적혀 있습니다.
3. 목업. 바뀐 화면을 그림으로 보여 줍니다. 빠른 스케치는 지금 화면의 한 조각을 모델에게 주고 바뀐 HTML을 받아 그립니다. 모델이 준 HTML은 믿지 않습니다. 허용한 태그만 남기고, 스크립트가 돌지 않는 샌드박스에서 그립니다. 더 정식 목업이 필요하면 컨테이너에서 헤드리스 Claude Code를 돌립니다. 운영 중인 코드 판을 받아 화면을 고친 HTML을 만들고, 헤드리스 브라우저로 찍습니다. 도구는 파일 읽기와 쓰기만 주고, 외부 MCP는 끄고, 비용과 시간에 상한을 걸었습니다.
4. 사람이 등록. 확인 카드에서 제목, 마감, 참조자를 고치고 "등록"을 눌러야 티켓이 생깁니다. 모델은 초안까지만 합니다.
5. 티켓과 첨부. 티켓을 먼저 만들고, 바뀌기 전·후 그림을 첨부로 올립니다. 첨부가 실패해도 티켓은 남고, 다시 보낼 때는 빠진 파일만 보냅니다.
6. 완료 알림. 상태를 되돌려 받다가 티켓이 끝나면, 사용자가 다음에 들어왔을 때 도우미가 말풍선으로 알려 줍니다.

회의록의 할 일 한 줄이 티켓이 되기까지

그림 3. 담당자와 기한은 모델이 아니라 표와 규칙이 정합니다.

보고서 서비스에는 회의록이 올라옵니다. 회의록은 정해진 템플릿을 따르고, 끝에 할 일 표(내용, 담당, 기한)가 있습니다.

여기서는 모델에게 맡기는 범위를 일부러 좁혔습니다. 할 일과 담당, 기한은 표에서 규칙으로 읽습니다. 모델은 각 줄의 종류를 분류하는 일만 합니다. 모델이 원문에 없는 할 일을 지어내면 버립니다.

담당 칸에 적힌 이름은 관리자가 만든 규칙에 맞춥니다. 규칙에는 이름과 별칭, 받을 프로젝트, 담당자와 참조자가 있고, 한 명에게 줄지 돌아가며 줄지도 정합니다. 기본은 "검토" 모드라서, 규칙에 없거나 애매한 줄은 확인함에 쌓이고 관리자가 승인합니다. 티켓이 만들어진 뒤에는 주기적으로 상태를 받아 회의록 위키에 "완료", "진행 중", "다시 열림"을 표시합니다.

연결을 튼튼하게 만든 다섯 가지

그림 4. 대부분 한 번씩 문제가 생긴 뒤에 들어간 장치입니다.

처음부터 다 갖춘 것은 아닙니다. 대부분 문제가 한 번 생긴 뒤에 들어갔습니다.

• 중복 방지 키를 무엇으로 만들까. 같은 회의록을 고쳐서 다시 올렸더니 티켓이 겹쳤습니다. 키를 "할 일 문장 + 규칙 이름"으로 바꿨습니다. 담당자로 만들면 돌아가며 배정할 때마다, 규칙 번호로 만들면 규칙을 지웠다 다시 만들 때마다 키가 바뀌기 때문입니다.
• 거절과 일시 오류를 나누기. 요청이 잘못돼 거절되면(4xx) 다시 보내도 또 거절됩니다. 이런 줄은 사람에게 넘깁니다. 연결이 끊기거나 서버 오류일 때만 나중에 다시 보냅니다. 두 서비스의 연결 코드 모두 오류를 던지지 않고 결과로 돌려줍니다.
• 재시도 상한. 먼저 만든 보고서 서비스는 일시 오류 재시도에 상한이 없었습니다. 나중에 만든 대시보드는 그걸 보고 상한부터 넣었습니다.
• "연동 꺼짐"을 장애와 따로. 티켓 시스템에서 프로젝트 받기를 꺼 두면, 보내는 쪽에서는 그게 장애처럼 보였습니다. 지금은 "연결 실패"와 "연동 꺼짐"을 다르게 표시합니다.
• 같은 내부망이면 내부 주소로. 처음에는 티켓 시스템의 공용 주소로 불렀는데 계속 시간 초과가 났습니다. 같은 내부망 안인데도 트래픽이 인터넷으로 나갔다가 들어와서 방화벽 규칙에 맞지 않았던 것입니다. 내부 주소로 바꾸자 해결됐습니다.

Claude Code로 세 저장소를 맞춘 방법: 계약 문서 하나

서비스마다 저장소가 따로 있고, Claude Code 세션도 저장소마다 따로 돌았습니다. 보고서 서비스 쪽 세션은 "티켓을 이렇게 보내겠다"를 알고, 티켓 시스템 쪽 세션은 "이렇게 받겠다"를 압니다. 둘이 서로의 코드를 보지 않으니 어긋나기 쉽습니다.

그래서 연동 계약 문서 하나를 두 세션이 함께 읽는 기준으로 삼았습니다. 요청과 응답 모양, 오류 코드, 중복 방지 키 규칙이 모두 이 문서에 있습니다. 그리고 계약대로 동작하는지 실제 서버에 대고 확인하는 점검 스크립트를 두었습니다. 대시보드를 붙일 때도 이 문서와 앞서 만든 보고서 서비스의 코드를 읽고 시작해서, 재시도 상한 같은 교훈을 그대로 가져왔습니다.

내 팀에 적용한다면

• 가운데를 먼저 정하기. 일이 모이는 시스템 하나를 정하고, 다른 서비스는 거기에만 맞추게 합니다.
• 모델에게 맡길 범위를 좁게. 담당자, 기한, 최종 등록처럼 틀리면 곤란한 것은 규칙과 사람에게 둡니다. 모델은 초안과 분류만 합니다.
• MCP와 연동 API의 자리를 나누기. 서비스가 기계적으로 보내는 일은 서비스 키를 쓰는 연동 API로, 사람을 대신해 읽고 처리하는 일은 MCP로 둡니다.
• 저장소가 여럿이면 계약 문서 하나. Claude Code 세션이 여럿이어도 같은 문서를 읽게 하면 덜 어긋납니다.

자주 묻는 질문

Q. 처음부터 MCP 하나로 다 하면 안 되나요? 할 수는 있습니다. 다만 MCP 서버가 "사람 대신" 움직이게 만들었다면, 서비스가 보내는 티켓을 같은 창구로 받으면 누구의 권한으로 만들었는지가 흐려집니다. 그래서 저희는 둘을 나눴습니다.

Q. 모델이 만든 티켓 초안이 틀리면요? 그래서 사람이 등록을 눌러야 티켓이 생기게 했습니다. 회의록 쪽도 기본이 검토 모드라서, 애매한 줄은 관리자가 보고 승인합니다.