업계 특화 SaaS를 MCP화하기: 왜 배차와 캐스트 시프트부터 시작했는가
요약
나이트 레저 업계용 SaaS인 tasteck을 MCP(Model Context Protocol)로 전환하는 과정과 전략을 다룹니다. 사용자의 저항이 적고 LLM의 추론 능력이 효과적으로 발휘될 수 있는 '배차'와 '시프트 관리' 도메인을 우선 선택한 이유를 설명합니다.
핵심 포인트
- 사용자의 현상 유지 편향을 고려해 '스트레스가 높은 태스크'부터 MCP화
- 배차 퍼즐과 같은 인지적 추론 영역은 LLM이 해결하기에 최적화된 도메인
- 복잡한 데이터 연계 로직을 MCP Tool 서버 측에서 처리하여 UI 제약 극복
- 자연어 인터페이스를 통해 복잡한 조건 검색 및 조작을 단순화
나이트 레저(Night Leisure) 업계용 예약·고객 관리 SaaS(tasteck)를 1인 + AI로 개발하고 있다. ChatGPT Plus가 MCP에 대응하게 된 것을 계기로, 「업계 특화 SaaS를 MCP화하면 어떻게 될까」를 시험하고 있다. 설계를 마치고, 구현은 이번 주부터 시작한다.
그 "첫 번째 도메인 선택" — 수주도 고객도 분석도 아닌 배차와 캐스트 시프트(Cast Shift)부터 시작한 이유 — 에 대해 쓰고자 한다. 같은 고민을 하는 사람들의 논의를 위한 발판이 되기를 바라며.
무엇을 만들려고 하는가
경영자(점포 오너)나 배차 담당자가 ChatGPT에게 자연어로 배차·시프트 조작을 할 수 있게 하는 MCP server.
「오늘 밤 비어 있는 드라이버 누구야?」
→ ChatGPT가 tasteck의 MCP tool을 통해 그날의 시프트 재직 드라이버를 반환
「19시 다나카 씨의 수주, 배웅은 사토 씨로」
...
UI를 계속 만드는 것이 힘들었기에 「ChatGPT에게 대신 시키기」가 당초의 동기였다. 그러다 보니 「업계 최초의 MCP 대응 SaaS」라는 새로운 포지셔닝 축이 보였다는 흐름이다.
왜 전체 도메인이 아니라 「배차 + 캐스트 시프트」인가?
처음에는 수주 화면의 MCP화를 생각했다. 하지만 그만두었다.
SQB (Status Quo Bias)의 이분 가설
업계용 SaaS를 8년간 운용해 온 감각으로, 사용자의 「현상 유지 편향 (Status Quo Bias)」에는 두 종류가 있다는 것을 깨달았다:
| 타입 | 예 | MCP로의 이행 저항 |
|---|---|---|
| 「편안한 현상」을 지킴 | 경영 판단, 수주 확인, 수치 확인 | 강함. 「인간이 한 번 판단하고 싶다」 |
| 「스트레스 있는 현상」을 지킴 | 배차 퍼즐, 시프트 연계 해결, 메시지 전송 | 약함. 오히려 환영받음 |
「편안한 현상」을 ChatGPT에게 넘기려 하면, 경영자는 「직접 보고 싶다」며 저항한다. 「스트레스 있는 현상」 — 즉 「하고 있으면 힘든 태스크」를 대신하게 하는 것은 환영받는다.
배차 퍼즐이 어떻게 「스트레스」가 되는가
나이트 레저의 배차는 인지와 추론의 퍼즐이다. 당사의 전직 현장 담당자인 당사 대표가 개발 전에 몇 번이고 말했던 내용이다:
「배차는 추론이야. 지금 누가 비어 있고, 얼마나 있으면 돌아오고, 어떤 순서로 돌려야 하는지 — 그것을 머릿속에서 계속 다시 짜고 있어. 엄청난 스트레스지.」
이것은 LLM이 잘하는 영역 그 자체다. 「20건의 수주, 8명의 드라이버, 각 드라이버의 현재 위치·예상 귀환 시간·휴식 희망 사항 — 최적의 배차 패턴을 제안」과 같은 쿼리 말이다.
캐스트 시프트의 「연계 지옥 (紐付き地獄)"
또 하나 「배차」와 세트로 MCP화를 한 이유는, 캐스트 시프트의 데이터 연계 복잡성 때문이다.
수주 화면에서 「배정할 캐스트를 선택」할 때, 후보 리스트에 나오는 캐스트의 조건:
캐스트가 시프트에 포함되어 있고 (castShift)
∧ 예명 (castName)이 존재하며
∧ 그 예명의 소속 점포가 수주 대상 점포와 일치하고
...
이것을 인간이 UI로 조작하면:
- 「예명이 설정되어 있지 않으면 후보에 나오지 않는다」는 제약에 몇 번이고 걸린다.
- 「점포 체크를 먼저 하지 않으면 캐스트가 나오지 않는다」는 함정에 빠진다.
실제로 개발 검증 작업 중에 AI 디버거가 몇 번이나 「캐스트 후보가 비어 있다」고 오보를 했다. 하지만 실제로는 시프트에 들어있고 캐스트도 재직 중이다. 다만 조건이 너무 복잡해서 「인간이 손으로 조립하는 UI」에서는 혼란이 발생한다.
→ 이러한 연계야말로 MCP tool이 server 측에서 해결하여 반환해야 할 것이다. 「자연어로 『오늘 밤 배정 가능한 캐스트 누구야?』라고 물으면, server 측에서 연계를 전부 풀어서 후보를 반환」하도록 만든다. 이것이 이번 MCP화의 핵심 tool이 된다.
tool 설계: read 3개부터 시작
MCP의 write tool은 dangerous + dryRun의 2단계로 안전하게 만들 수 있지만, 우선 「ChatGPT로부터 읽을 수 있는 것」을 내놓아 반응을 보고 싶다. 따라서 Phase 1 B1 (이번 주)은 read 3개뿐이다:
| 도구 (tool) | 할 수 있는 일 | 내부 API |
|---|---|---|
list_available_drivers | 「오늘 밤 비어 있는 드라이버」 | driver/spFind |
list_cast_shifts | 「오늘의 시프트 (shift)」 | castShift/findAll |
list_assignable_casts ★ | 연관된 해결 완료 후보 리스트 | castShift/findAll + 필터 로직 |
★이 핵심이다. 위에 적은 「시프트 재직 ∧ 예명(源氏名) 있음 ∧ 점포 일치」를 서버 (server) 측에서 해결하여, LLM에게 「사용 가능한 castNameId 리스트」를 반환한다. LLM 측은 「점포가・notelClass가...」 등을 의식하지 않고, 자연스러운 대화로 「배정 가능한 인원은 [사토, 야마다, 스즈키]입니다」라고 답변할 수 있다.
이것이 MCP의 올바른 사용법의 예라고 생각한다: 복잡한 도메인 (domain) 제약 조건은 서버 (server) 측에서 해결하고, LLM 측에는 심플한 인터페이스로 전달한다. LLM에게 「전체 데이터 + 제약 조건」을 넘겨서 풀게 하지 않는다.
자연어 날짜의 해결
업계 특유의 함정: 「오늘」 「내일」이 업무일 기준으로 무엇을 가리키는지가 복잡하다. 나이트 레저(night leisure) 점포는 심야 영업이 많아, 업무일의 경계(changeDateTime)가 04:00 또는 05:00인 경우가 있다. 03:00에 「오늘 수주 건수가 몇 건이야?」라고 물으면, 업무일 기준으로는 「전날」을 가리켜야 한다.
MCP 서버 (server)에 **resolve_business_date(natural_text) 헬퍼 (helper)**를 갖추어, 각 도구 (tool)의 날짜 입력을 정규화한다. LLM은 「오늘」이라고 말하기만 하면 된다.
async function resolveBusinessDate(
naturalText: string,
companyId: number
...
사소해 보이지만, 이것이 있고 없고에 따라 「ChatGPT가 실수로 전날을 가리켜 패닉에 빠지는」 식의 사고를 방지할 수 있다.
인증은 기존 staff JWT를 유용
점주는 이미 스태프 로그인 (staff login)을 통해 JWT를 가지고 있다. 이것을 MCP의 Bearer token으로 유용하는 것이 가장 솔직한 방법이다:
[경영자] → ChatGPT Plus → MCP 접속 설정
└─ URL: https://api.no-tel.com/v1/api/mcp/sse
└─ Authorization: Bearer <staff_jwt>
...
초기에는 점장 계정 (role=clientMaster)으로 고정한다. 「ChatGPT에게 부여하는 권한을 세분화하는 것」은 B3에서 진행한다. 우선은 1 경영자 = 1 전권 계정으로 동작하는 것을 우선시한다.
write는 B2에서, dangerous + dryRun
read를 통해 가치를 창출할 수 있다는 것을 알게 되면, 배차 할당 (assign_order_driver)이나 시프트 추가 (create_cast_shift)를 넣는다. 모든 write 도구 (tool)에 dangerous: true 플래그와 dryRun: true/false 파라미터를 사용하여 「대화 속에서 승인 → 실행」의 2단계로 구성한다.
ChatGPT: 「19시 다나카 씨의 송영, 사토 씨로 배정하겠습니다. 괜찮습니까?」
↓
사용자: 「부탁해」
...
이 「대화 속에서 승인을 받는 것」이 MCP write의 본질이다. 클릭 한 번으로 실행되는 UI와는 다른 안전성이다.
업계 최초의 MCP 대응 SaaS를 목표로
이것을 업계(나이트 레저 특화 SaaS)에서 가장 먼저 수행하는 것에 의미가 있다. 경쟁사(다른 업계 특화 SaaS)가 「AI 기능 탑재」로 추격하기 전에, 「업계 AI agent 에코시스템 (ecosystem)」 포지션을 선점하러 간다. 단일 기능인 「AI가 예측한다」가 아니라, 「ChatGPT가 tasteck을 조작할 수 있다」는 쪽이 체감 가치가 다르다.
기술적으로 하고 있는 일은 「NestJS 모듈 (module) 1개를 추가하고, staff API에 대한 얇은 래퍼 (wrapper)를 작성하는 것」뿐이다. 하지만 사용자의 체감(「ChatGPT로부터 배차할 수 있다」)은 비약적으로 변한다.
이것이 제대로 맞아떨어진다면, 자사 매장 홈페이지(제작 서비스)도 MCP화하여 「ChatGPT를 경유해 tasteck과 홈페이지를 오갈 수 있는」 생태계로 확장한다. 구인 매체(채용 사이트)까지 MCP로 연결할 수 있다면, 단 한 번의 ChatGPT 대화로 「교대 근무(shift) 추가 → 홈페이지의 캐스트 소개 업데이트 → 구인 매체에 게시」가 완결되는 세계선이 펼쳐진다.
Phase 1 로드맵 (build-in-public 공약)
| Phase | 기간 | 내용 |
|---|---|---|
| B0 (완료) | 6/3 | tool spec 설계 |
| B1 (이번 주) | 6/8-6/15 | read 3 tools 구현 + ChatGPT Plus 통신 + 데모 기사 발행 |
| B2 | 6/16-7/1 | write 3 tools (assign / create / send) |
| B3 | 7/2-7/15 | 얼리 어답터 1개사 대상 실운영 통신 |
| B4 | 7/16-7/31 | 「업계 최초 MCP 대응 SaaS」 정리 + 수평 전개 준비 |
B1의 동작 데모 기사 (「ChatGPT로부터 배차할 수 있다」가 동작했다)는 6/15 발행 예정이다. 이번 (설계 편)의 속편으로 작성할 것이다.
요약
업계 특화 SaaS의 MCP화는 어디서부터 시작할 것인가의 선택에 따라 성격이 결정된다. 우리의 경우:
- 「편안한 현상」이 아니라 「스트레스가 있는 현상」(배차 퍼즐 + 근무 시간표 연동)부터
- 모든 tool을 한꺼번에가 아니라 「read 선행」으로 출시
- 복잡한 제약 사항은 server 측에서 해결(LLM에 던지지 않음)
- 업무일 경계의 자연어 해결을 MCP server에서 담당
- 인증은 기존 staff JWT 유용을 통해 1개 계정으로 전권 부여
- write는 dangerous + dryRun을 통해 대화 과정 속에서 승인
「ChatGPT로부터 배차할 수 있는 SaaS」가 동작하면, 데모 영상과 함께 속편을 작성할 예정이다. 동일한 도메인(업계 특화 SaaS의 MCP화)을 고민하고 계신 분들은 함께 논의해 보자.
(속편 예정: 「ChatGPT로부터 배차에 성공했다: B1 read 3개 동작 이야기」)
Discussion
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기