끊기지 않는 연결, 새지 않는 토큰
- [꼼꼼한] MCP

AI에 수첩을 연결하는 일, 즉 MCP를 '지원'하는 것 자체는 어렵지 않습니다. 정말 어려운 건 그 다음입니다 — 연결이 자꾸 끊기지 않을 것, 한 번 부탁에 토큰을 적게 쓸 것, 그리고 AI가 채워 넣은 구조가 실제로 맞을 것. '되는 것'과 '쓸 만한 것' 사이의 거리죠.

이번 글은 [꼼꼼한] MCP를 그 '쓸 만한' 쪽으로 밀어 넣은 네 가지 설계 결정을, 실제 코드를 들여다보며 풀어 보려고 합니다.

#① 끊기지 않는 연결 — 잦은 인증의 피로 없이, 안전은 그대로

AI에게 수첩을 맡기는 일은 한 번의 대화로 끝나지 않습니다. 아침엔 오늘 할 일을 읽고, 저녁엔 기록을 정리하고, 주말엔 메모를 묶는 — 일련의 행위는 이어지는 관계입니다.

그래서 MCP를 쓸 때 가장 거슬리는 건, 일하다 말고 자꾸 튀어나오는 "다시 로그인해 주세요"입니다. 백그라운드에서 조용히 일해야 할 비서가 시도 때도 없이 사람을 부르는 셈이죠.

그렇다고 인증을 없앨 수는 없습니다. 인증은 본래 안전과 맞바꾸는 장치라, 느슨하게 풀수록 계정은 위험해집니다. 즉 '덜 귀찮게'와 '더 안전하게'는 정면으로 부딪힙니다. 우리가 풀어야 했던 건 바로 이 상충이었습니다.

우리가 택한 답은 기기 인증입니다. 신뢰할 수 있는 기기를 한 번 등록해 두면, 그 기기에서는 매번 다시 인증을 요구하지 않습니다 — 한 번 연결하면 오래 가도록 한 거죠. 덕분에 한 번 연결해 둔 AI는 끊김 없이 일을 이어갑니다.

오래 유지된다고 안전을 푼 건 아닙니다. 오히려 그 반대로, 기기 자체를 신뢰의 단위로 삼아 단단히 잠갔습니다.

정리하면, 잦은 인증의 피로는 기기 인증으로 덜되, 안전은 기기를 신뢰의 단위로 삼아 지켰습니다. 인증과 안전을 맞바꾸지 않고, 둘 다 가져가려 한 선택입니다.

#② 새지 않는 토큰 — 필드 이름을 두 번 말하지 않는다

AI와 수첩이 주고받는 것은 결국 텍스트이고, 그 텍스트의 길이가 곧 토큰이고, 토큰이 곧 비용이자 속도입니다. 그래서 "같은 내용을 얼마나 짧게 담느냐"가 사용성을 직접 좌우합니다.

흔한 방식은 항목마다 필드 이름을 또박또박 붙이는 것입니다. 보기엔 친절하지만, 항목이 50개면 같은 이름표를 50번 반복합니다.

{
  "lists": [{
    "name": "장보기",
    "tasks": [
      { "name":"우유", "done":false, "minutes":5, "color":"red" },
      { "name":"계란", "done":false, "minutes":3, "color":"blue" }
    ]
  }]
}

[꼼꼼한]은 같은 내용을 위치 기반 배열로 담습니다. "첫 칸은 이름, 둘째 칸은 완료 여부, 셋째 칸은 분(시간), 넷째 칸은 색" — 순서가 곧 의미라서, 이름표를 한 번도 쓰지 않습니다.

// [ 이름, 완료(0/1), 분, 색 ]
[["장보기",[["우유",0,5,"red"],["계란",0,3,"blue"]]]]

같은 두 항목인데 길이가 확연히 줄어듭니다. 항목이 많아질수록 격차는 더 벌어지고요 — 반복하던 이름표가 통째로 사라지니까요. 게다가 저장할 때는 여기에 한 번 더 압축을 거쳐 보관합니다. AI가 읽고 쓰는 양도, 우리가 저장하는 양도 모두 가볍습니다.

거창한 기술이 아닙니다. "필요한 값만, 순서대로"라는 단순한 원칙을 데이터 구조 맨 밑바닥에 둔 것뿐입니다. 그 작은 결정이 매 호출의 토큰으로, 그대로 돌아옵니다.

#③ 떼어낼 수 있는 한 덩어리 — 한 페이지는 생각보다 무겁다

우리가 화면에서 보는 '한 페이지'와, 그 뒤에서 돌아가는 데이터베이스는 같지 않습니다. 깔끔해 보이는 한 페이지라도, 그 안에는 생각보다 꽤 큰 데이터가 담겨 있습니다. 여행 일정 한 장, 가계부 한 권, 학습플래너 한 장 — 펼쳐 보면 수십·수백 개의 값이 한 덩어리로 얽혀 있죠.

MCP 설계에서 가장 어려운 지점이 바로 여기입니다. AI에게 "이번 여행 일정만 정리해줘"라고 하려면, 그 한 페이지에 담긴 (꽤 큰) 데이터를 통째로, 그리고 그 페이지만 정확히 떼어 주고받을 수 있어야 합니다. 그런데 데이터가 여기저기 흩어져 서로 얽혀 있으면 "이 페이지"의 경계가 흐려져, 한 조각만 정확히 골라내는 일이 사실상 불가능해집니다. 결국 전부 통째로 보내게 되고 — 관계없는 데이터까지 실려 토큰이 불어나고, AI도 무엇이 핵심인지 헷갈립니다.

[꼼꼼한]은 처음부터 한 페이지 = 독립적인 한 덩어리로 설계했습니다. 한 페이지의 모든 데이터가 그 하나의 단위 안에 온전히 모여 있어서, 그 덩어리가 아무리 커도 통째로 깔끔하게 떼어낼 수 있습니다. AI는 딱 그 페이지만 정확히 읽고, 딱 그 페이지만 고쳐 돌려줍니다 — 옆 페이지를 건드리지도, 끌려 나오지도 않습니다. MCP에 최적화된 데이터 처리 방식입니다.

#④ 거대한 만능 양식이 아니라, 쓰임에 맞춘 16개

무엇이든 담을 수 있는 거대한 만능 양식 하나는 언뜻 강력해 보입니다.

하지만 AI에게 "학습 계획 짜줘"라고 했을 때, 그 만능 칸은 '어떤 모양으로 채워야 하는지'를 알려주지 않습니다. 무엇이든 될 수 있다는 건 곧 무엇도 아니라는 뜻이라, 같은 요청에도 매번 제각각의 형태가 나옵니다.

[꼼꼼한]은 반대로 갔습니다. 체크리스트·학습플래너·가계부·여행계획표·독서기록·일기 등 쓰임에 맞춘 16종의 전용 양식을 두고, 양식마다 고유한 구조와 전용 검증을 붙였습니다. 그래서 AI가 데이터를 채워 보내면, 서버가 그 양식의 규칙에 맞는지 확인하고 — 틀리면 "이 양식은 이렇게 채워야 한다"는 힌트까지 돌려줍니다. 구조를 만들어 달라는 요청이 정확히 먹히는 이유입니다.

• 양식별 전용 검증 — 학습플래너에 가계부 모양을 넣으면 걸러집니다. 양식마다 맞는 틀이 정해져 있으니까요.
• 틀렸을 때 해답을 찾기 위한 힌트 안내 — 작동 중 오류가 나면, 그 양식을 어떻게 채워야 하는지 안내해 줍니다. 그러면 AI가 스스로 고쳐 다시 시도합니다.
• 설계 가이드 — AI가 구조를 짜기 전에 "이 양식은 무엇을 담는 곳인지" 안내를 먼저 읽을 수 있습니다.

거대한 만능 양식은 무엇이든 담지만 무엇도 정확히 담지 못합니다. 전용 양식은 그 양식이 담아야 할 것을 정확히 담습니다. 자유도를 조금 내주고, 정확도를 크게 얻은 교환입니다.

덧붙여 — 한글로 채워도 알아듣습니다

전용 양식의 또 다른 이점은 한글 친화성입니다. 양식의 항목이 한글 라벨을 기준으로 정의돼 있어, AI가 한글 이름표로 값을 채워 보내도 우리 쪽에서 내부 구조로 정확히 정규화해 받습니다. 정규화는 데이터의 일관성을 지키고 중복을 줄이려고 구조를 다시 정리하는 과정인데, 이 단계를 거치면 한글로 채운 값이 흐트러짐 없이 제자리에 들어갑니다. 한국어로 부탁하고, 한국어로 채우고, 한국어로 돌려받는 흐름이 어느 한 군데서도 어긋나지 않도록요.

#마치며

MCP를 "지원한다"고 말하는 건 쉽습니다. 문 하나를 내면 되니까요. 하지만 그 문이 매일 드나들 만한지는 전혀 다른 이야기입니다.

[꼼꼼한]이 택한 답은 화려한 기능이 아니라, 네 개의 조용한 설계 결정이었습니다 — 끊기지 않고(기기 인증으로 인증과 안전을 함께), 가벼우면서(최소 필드 + 압축), 깔끔하고(큰 한 페이지도 통째로 떼어내기), 정확하게(쓰임에 맞춘 양식 + 한글)!

어느 하나도 눈에 띄지 않지만, 합쳐지면
"AI에게 [꼼꼼한] 수첩을 맡겼더니 진짜로 편하더라"는 한 줄의 평이 남으면 좋겠습니다.