MCP 두 개로 앱을 만들었다 — Mobbin과 Higgsfield

vibing은 먹은 것·체중·움직임을 적으면 매일의 칼로리 적자가 보이는 앱이다. 거북이 비비가 코치처럼 말을 건다. 코드는 Claude Code가 썼고, 나는 화면을 보면서 방향을 정했다. 그 옆에 도구를 두 개 붙였다 — 진짜 앱들의 화면을 뒤지는 Mobbin, 그림을 그리는 Higgsfield. 이 글은 그 둘이 각각 무엇을 할 수 있고, 실제로 어디에 썼는지에 대한 기록이다.

12일

첫 커밋부터 지금까지

269

커밋

81장

비비 일러스트

MCP는 에이전트의 손

MCP(Model Context Protocol)는 모델이 바깥 도구를 부르는 규격이다. Claude Code에 서버 주소 하나를 등록하면, 그 서버가 내놓는 기능들이 대화 안에서 함수처럼 불린다. “이런 화면 레퍼런스 찾아 줘”라고 하면 에이전트가 검색 함수를 부르고, 결과 이미지를 보고, 그걸 근거로 코드를 쓴다. 사람이 브라우저 탭을 열어 스크린샷을 끌어다 주는 과정이 통째로 사라진다.

이 프로젝트에는 둘을 등록했다. api.mobbin.com/mcp와 mcp.higgsfield.ai/mcp. 둘 다 HTTP로 붙고, 새 세션을 열 때마다 /mcp에서 한 번 인증한다.

Mobbin MCP — 진짜 앱들의 화면을 뒤진다

Mobbin은 실제 서비스 앱의 화면과 흐름을 모아 둔 곳이다. MCP로는 세 가지를 물을 수 있다.

• search_screens화면 한 장을 자연어로 찾는다. iOS와 웹을 따로 고른다.

  “큰 세리프 제목·바이라인·커버 일러스트가 있는 긴 글 읽기 화면”처럼 한 화면을 구체적으로 묘사할수록 잘 맞는다. 앱 이름을 넣으면 그 앱으로 좁혀진다.

• search_flows온보딩·결제처럼 여러 단계로 이어지는 흐름을 찾는다. 단계별 미리보기가 함께 온다.

• search_sections웹사이트의 섹션(가격표, 푸터, 히어로)을 찾는다. 이 블로그의 인덱스 레이아웃이 여기서 나왔다.

vibing에서 어떻게 썼나

• 디자인 토큰. 크림 바탕(#f4f1ea), 테라코타 포인트(#c9633f), 제목의 Noto Serif KR — 처음에 Future Pro와 Claude 앱 화면을 레퍼런스로 놓고 뽑은 조합이다. 앱 전체가 아직 이 토큰 위에 있다.
• 동기부여 화면. Finch·Alan·Me+·Headway·Duolingo를 찾아 보고 공통점을 추렸다. 상단에 컴패니언과 말풍선, 행동마다 눈에 보이는 보상(+N), 스트릭 약속, 축하 오버레이. vibing 홈의 비비 카드와 XP 토스트가 그 결과다.
• 이 글. 모바일 기사 화면은 NYTimes와 Zocdoc(키커 → 세리프 제목 → 바이라인 → 큰 커버), 웹 인덱스는 Passionfroot와 Intercom(크림 바탕 위 에디토리얼 카드)을 보고 잡았다. 글을 쓰기 시작한 지 몇 분 안에 레이아웃이 정해졌다.

Higgsfield MCP — 비비를 81번 그렸다

Higgsfield는 이미지·영상 생성 서비스다. MCP로 붙이면 모델 카탈로그를 뒤지고, 생성을 걸고, 결과를 받아 오고, 배경을 지우는 일이 전부 대화 안에서 끝난다.

• generate_image프롬프트 하나로 이미지를 만든다. 참조 이미지를 같이 넣을 수 있다.

• generate_image_batch + jobs_wait서로 다른 프롬프트 여러 개를 한 번에 걸고, 끝날 때까지 기다린다. 포즈 여덟 개를 한 번에 뽑을 때 이걸 쓴다.

• remove_background완성된 생성물의 배경을 지운다. 생성 job id를 그대로 넣으면 된다.

  vibing의 비비는 전부 누끼다. 그래야 라이트·다크 어느 배경에도 놓인다.

• media_import_url바깥 이미지 URL을 참조용 media id로 가져온다.

• models_explore모델별 비율·해상도·참조 역할을 확인한다. 이 글 커버는 nano_banana_pro, 16:9, 1k.

• balance남은 크레딧. 생성 전에 한 번 본다.

같은 비비가 계속 나오게 하는 절차

1. 1

   기준 이미지를 정한다

   처음 마음에 든 생성물의 job id 하나를 “비비의 원본”으로 못 박는다. 이후 모든 포즈는 이 id를 image_references로 넣는다. 이걸 빼먹으면 다른 거북이가 나온다.
2. 2

   포즈를 한 번에 건다

   generate_image_batch로 프롬프트 여러 개를 동시에 넣고 jobs_wait로 기다린다. 장당 2크레딧, 1k 해상도면 충분하다 — 앱에서는 640px로 쓴다.
3. 3

   배경을 지운다

   remove_background에 생성 job id를 그대로 넣는다. 깨끗한 단색 배경으로 생성해 두면 잘린다.
4. 4

   sharp로 마무리한다

   투명 여백을 trim하고 정사각으로 패딩한 뒤 webp로 저장한다. 원본 PNG는 assets/에, 앱이 쓰는 webp는 public/에.

이 글의 커버가 정확히 그렇게 나왔다. 프롬프트를 그대로 옮기면 이렇다.

3D rendered clay-like cute turtle character, NOT flat 2D, pastel mint-green skin, pale sage-green shell, big friendly eyes. The turtle stands proudly next to a small wooden easel that holds a phone-app mockup, wearing a tiny beret, holding a paint palette; behind it a small mood board with a few pinned rounded UI cards and pastel color chips. Soft studio lighting, gentle shadow. Plain solid pure white background, subject group centered, whole character fully visible, nothing cropped, landscape composition with breathing room on both sides.

둘을 한 루프에

순서는 늘 같았다.

1. Mobbin으로 그 화면이 다른 앱에서 어떻게 생겼는지 본다.
2. 코드를 쓴다.
3. 거기 들어갈 비비가 없으면 Higgsfield로 만든다.
4. 브라우저에서 라이트·다크 모두 열어 보고 고친다.
5. 커밋.

이 페이지도 그 순서로 만들었다. 레퍼런스 넷을 보고 레이아웃을 정하고, 커버 후보 세 장을 한 번에 걸고, 하나를 고르고, 배경을 지우고, 여기 올렸다. 도구가 대화 안에 있으니 “찾아보고 올게”가 없다.

솔직한 한계

• Mobbin은 유료 플랜이 필요하고, 두 서비스 모두 새 세션마다 인증을 다시 한다.
• 기준 이미지를 넣어도 열에 한두 장은 다른 얼굴이 나온다. 한 장만 걸고 그걸 쓰면 안 되고, 여러 장 걸어 고르는 비용이 든다.
• 배경 제거는 단색 배경에서 잘 된다. 복잡한 장면은 가장자리가 지저분해진다.
• 레퍼런스는 레퍼런스다. Mobbin이 보여 주는 건 잘된 화면이지, 우리 사용자가 원하는 화면은 아니다. 그건 여전히 써 보고 재 봐야 안다.

마무리

MCP 둘을 붙이고 나서 바뀐 건 속도보다 그만두지 않게 된 것이다. 레퍼런스를 찾으러 나가면 돌아오지 않을 때가 많았고, 그림은 아예 시도를 안 했다. 지금은 둘 다 대화 안에서 끝난다. 그래서 거북이 한 마리가 여든한 번 그려졌다.