인터페이스 앱 MVP 설계를 'MCP 하이브리드'로 전환하다

앱(MVP) 설계서를 확정해두고도 코딩 직전에 v2로 갈아엎었다. "LLM CLI로 이미 볼트를 다루는데 굳이 앱을 왜 만들어?" 라는 질문에서 출발해, "합성의 진짜 레버는 두뇌가 아니라 검색" 이라는 깨달음과 MCP를 만나 하이브리드 구조에 도달하기까지의 기록.

이런 분들께 도움돼요

• LLM Wiki에 Claude Code·Codex 같은 LLM CLI로 접근할 수 있는데, 별도의 앱을 만들 필요가 있는지 잘 모르겠다

• "내 지식을 합성해 새로운 통찰을 얻고 싶다" 는 목표가 있다

• MCP가 왜 유용한지 감을 잡고 싶다

출발점: 확정된 설계서를 두고 생겨난 의문

OpenAI 단일 + FastAPI 챗앱 + 웹 UI로 "두뇌 서버"를 만든다는 앱 MVP설계서는 이미 확정된 상태다. 사전 단계인 볼트 Git 전환도 끝냈으니 이제 코딩만 하면 됐다.

그런데 1단계에 들어가기 직전, 근본적인 의문이 생겼다:

"지금 이 순간에도 난 Codex/Claude Code로 지식체계 볼트를 검색하고 저장하잖아. 그런데 지식체계 볼트를 관리하는 앱을 왜 굳이 만들려고하지? 뭐가 더 좋아지는 건데?"

설계 변경은 이 의문에서 시작됐다.

깨달은 것 (변경 동기)

곰곰히 생각해보고서 깨닫게 된 건 이렇다.

1) 앱을 사용한다고 '지능'이 더 나아질 것은 없다

새로운 통찰을 만드는 합성·창조 능력은 '모델'이 결정한다 — CLI든 내 앱이든 같은 모델을 사용한다면 결과도 같을 것이다. 오히려 비용 아끼려고 앱에 싼 모델을 넣으면 책상에서 최강 모델을 사용하는 CLI보다 합성력이 떨어진다.

→ 즉 앱의 존재 이유는 "더 똑똑하게 하려는" 것이 아니라 ① 어디서나 접근할 수 있고 ② 규칙에 일관성을 가지며 ③ 자동화 연계선 상에 있어야 한다. (이게 안 되면 굳이 앱을 만들 이유가 없다.)

2) 합성의 진짜 레버는 '두뇌'가 아니라 '재료(검색)'

내가 가장 원하는 건 "내가 생각 못 한 새로운 연결" 이다. 그러려면 모델이 똑똑한 것만으론 부족하고, 흩어진 관련 노트를 정확히 끌어와 재료로 먹여줘야 한다.

문제는 일반 CLI의 검색이 키워드 매칭(grep) 이라 — 개념은 같은데 표현이 다른 노트를 놓친다. 그래서:

합성 품질 = f( 모델 지능 , 끌어온 맥락의 질·폭 )

여기서 두 번째 항을 끌어올리는 게 의미검색(임베딩) 이다. 그래서 의미검색을 "6단계(선택)"에서 "1.5단계(핵심)"로 승격시켰다. 합성이 1순위라면, 검색 품질이 1.5순위여야 한다.

3) MCP = 일관성 + 두뇌 교체의 자유

볼트의 4가지 동작(찾기/읽기/저장/업데이트)을 MCP 서버로 만들면:

• 규칙(frontmatter·폴더분류·트랙가드)이 한 곳에 살고, 모든 클라이언트가 똑같이 따른다 → 일관성.

• 더 중요한 건 "볼트 능력"과 "사용하는 두뇌"가 분리된다는 점. 같은 MCP 서버에 연결하지만 책상에선 최강 모델을, 밖에선 저렴한 모델을 붙일 수 있다.

이 세 깨달음이 합쳐지자, "FastAPI 단일 앱"이라는 그림이 "MCP 서버(단일 진실 소스) + 여러 두뇌·입구" 로 자연스럽게 바뀌었다.

토큰을 절약할 것이냐 아니면 최고의 질로 합성할 것이냐

토큰을 아낄 것인가 아니면 합성의 질을 높일 것인가? 두 우선순위가 정면으로 충돌했다:

• 토큰 절약 → 싸고 가벼운 모델 + 적은 맥락

• 최고의 합성 → 강한 모델 + 넓은 맥락(=토큰 많이)

해법은 하이브리드 + 모델 티어링이었다:

• 책상 = Codex Pro(구독) — 정액제라 토큰 부담 없이 최강 모델로 깊은 합성. (구독료가 사실상 "무제한 합성" 입장권)

• 밖 = OpenAI API — 평소엔 저렴한 모델, 합성 요청일 때만 강한 모델로 승급.

즉 토큰을 많이 먹는 깊은 합성은 정액 구독(책상) 에서 하고, 종량제 API(밖)는 가벼운 검색·저장에 쓴다.

변경 내역 (v1 → v2)

그대로 유지한 것(좋은 결정이라 안 건드림): 규칙 엔진(rules.py), 4개 도구, 앱 코드는 볼트 밖 별도 repo, 저장 미리보기→승인 게이트.

이동한 것: 에이전트 루프·FastAPI·웹 UI는 폐기가 아니라 3단계(밖 두뇌)로 이동. 1단계 책상에선 Codex가 그 역할을 대신하므로 불필요.

부수 확인: HTTP가 Tailscale에서 동작함을 확정(SMB·ping 성공으로 임의 TCP 통과 증명). 밖에서 미니PC MCP를 HTTP/SSE로 쓰는 길이 열림. git용 SMB는 그대로 유지(MCP 전송과 별개 층).

배운 점

1) 안정되었다고 영구적인 건 아니다. 더 나은 구조가 보이면 바꾸는 게 맞다. 단, 이유와 변경 내역을 반드시 남긴다. 그래야 나중에 나도, 협업하는 AI도 안 헷갈린다.

2) 도구를 만들 땐 '지능'을 늘리려 하지 말고 '재료·입구·일관성'을 설계하라. 합성을 더 잘하고 싶다면 모델을 바꾸기 전에 검색(재료) 부터 의심하라.

3) MCP는 "한 번 만들어 여러 두뇌가 공유"하는 레버다. 능력을 클라이언트에서 떼어내 서버에 두면, 두뇌는 상황에 맞게 갈아끼우면 된다.

가장 크게 와닿은 건 — "왜 굳이?" 라는 질문을 회피하지 않고 끝까지 따라간 게 더 단순하고 강한 설계로 이어졌다.

향후 계획

1. 1단계 — 볼트 MCP 서버(4도구+규칙) + 노트북 Codex 연결 (착수 전 Codex의 MCP 지원 검증)

2. 1.5단계 — 의미검색(임베딩) + synthesize 합성 도구

3. 이후 — 미니PC 배포 → 밖에서 접근(웹/텔레그램) → 메신저 연동