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

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

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

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

AI에게 수첩을 맡기는 일은 한 번의 대화로 끝나지 않습니다. 아침엔 오늘 할 일을 읽고, 저녁엔 기록을 정리하고, 주말엔 메모를 묶는 — 오래, 자주, 띄엄띄엄 이어지는 관계입니다. 그래서 MCP를 쓸 때 가장 거슬리는 건, 일하다 말고 자꾸 튀어나오는 "다시 로그인해 주세요"입니다. 백그라운드에서 조용히 일해야 할 비서가 시도 때도 없이 사람을 부르는 셈이죠.

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

우리가 택한 답은 기기 인증입니다. 신뢰할 수 있는 기기를 한 번 등록해 두면, 그 기기에서는 매번 다시 인증을 요구하지 않습니다 — 인증의 지속성을 끌어올린 거죠. 덕분에 한 번 연결해 둔 AI는 끊김 없이 일을 이어갑니다. (연결에 쓰는 API 키에도 짧은 만료를 두지 않아 자주 끊기지 않습니다. 반면 OAuth 액세스 토큰은 표준대로 짧게 만료되고 자동 갱신됩니다 — 쓰임이 다릅니다.)

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

• 새 기기는 한 번 더 확인합니다. 새 기기에서 로그인하면 메일로 재확인을 거쳐, 허용한 기기만 등록됩니다. 비밀번호를 바꾸면 그 기기 외 전부 자동 해제되고요.

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

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

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에게 <꼼꼼한> 수첩을 맡겼더니 진짜로 편하더라"는 한 줄의 평이 남겨져 있으면 좋겠습니다.