본문 바로가기
C.W.K.
Stream
Lesson 04 of 04 · published

언제 뭐 쓸까

~18 min · decision, heuristics, architecture

Level 0호기심 많은 독자
0 XP0/48 lessons0/14 achievements
0/100 XP to next level100 XP to go0% complete

여기까지 ecosystem 을 써보면서 다듬어온 짧은 기준이야. 새 integration 을 만들 때마다 위에서 아래로 걸어봐 — 답이 거의 항상 깔끔하게 떨어져.

  1. 쓰는 쪽이 네가 통제하는 LLM app 하나뿐이야? → 그 provider 의 function calling. App 하나짜리 고민에 protocol 을 한 겹 더 얹지 마.
  2. 같은 capability 가 네가 통제하지 않는 여러 AI product 한테도 쓸모 있어?MCP server 를 짜. Product 가 하나 늘 때마다 코드를 고치는 대신 설정만 고치게 돼.
  3. AI 가 아닌 client 도 (브라우저, 모바일 앱, 스크립트) 쓸 거야?REST/OpenAPI 도 같이 내놔. MCP server 가 감싸는 밑단 API 로 두든, 얇은 MCP 층이 거기서 뽑혀 나오는 원본 contract 로 두든.
  4. 만든 쪽이 event 를 밀어주고 쓰는 쪽이 빨리 반응해야 해?webhook 을 추가해. 그 event 도 같은 OpenAPI 문서 안에 적어둘 수 있어.
  5. 작업이 오래 걸리는데 쓰는 쪽이 별도 URL 없이 protocol 안에서 비동기를 원해?MCP async task.

더 깊은 교훈은 조합에 있어. 정답이 'MCP 아니면 REST' 인 경우는 드물어. 대개는 'REST 가 밑바닥 진실이고, MCP 가 agent 한테 친절한 얼굴이고, function calling 이 모델을 부르는 봉투이고, webhook 이 event 가 흐르는 방향이고, async task 가 느린 길' 이야. Contract 마다 한 조각씩 풀어. 쌓여 있는 게 정상이야.

Code

넷 다 stack 하는 진짜 architecture·text
[Browser/mobile/CLI clients]
        │  REST + JSON  (OpenAPI document)
        ▼
[Your service]  ──── webhook events ────►  [Customer endpoints]
        ▲
        │  REST internal
[MCP server (thin facade)]
        ▲  protocol (sync calls + async tasks)
        │
[MCP host (Claude Desktop, IDE, custom)]
        ▲  function calling envelope
[LLM provider API]

External links

Exercise

실제로 내보내는 product 하나를 위 그림처럼 스케치해봐. 선마다 어떤 contract 로 말하는지 이름을 붙여. 그 이름표들이 어디에 덜 투자했는지 (MCP 층 하나가 시장을 열어줄 수도 있어) 와 어디에 과하게 투자했는지 (사람도 AI 아닌 소비자도 안 쓰는 REST 층) 를 드러내줘.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.