도구가 많아질수록 선택이 더 어려워진다
v0, Lovable, Bolt, MeDo, Cursor, Claude Code. AI 빌딩 도구의 선택지는 매달 늘어나고 있다. 그런데 이상하게도, 선택지가 많아질수록 '무엇을 기준으로 고를 것인가'라는 질문은 점점 흐릿해진다. 도구를 먼저 열고, 프롬프트를 먼저 치고, 나중에 결과를 보고 판단하는 패턴이 반복된다. 도구가 워크플로우를 설계하기 시작하는 순간이다.
최근 dev.to에 올라온 두 편의 글이 이 문제를 서로 다른 각도에서 정확하게 찌른다. 하나는 AI 이미지 생성의 브랜드 일관성 문제를 React 컴포넌트로 해결한 Inktag 개발기이고, 다른 하나는 MeDo라는 풀스택 AI 빌딩 플랫폼을 2주간 실사용한 후기다. 두 글의 표면적 주제는 다르지만, 핵심에는 같은 질문이 놓여 있다. "이 도구로 무엇을 고정하고, 무엇을 AI에게 맡길 것인가?"
AI 이미지의 일관성 문제, 기술이 아니라 설계 문제다
Inktag를 만든 Gautam은 스톡 사진 비용보다 더 근본적인 문제를 발견했다. AI 이미지 생성 품질 자체는 충분히 좋아졌다. 문제는 세대 간 일관성이었다. 월요일에 생성한 와인셀러 이미지와 목요일에 생성한 코워킹 스페이스 이미지가 마치 다른 사진작가가 찍은 것처럼 팔레트도, 조명도, 분위기도 달랐다. 블로그 홈페이지의 카드 목록이 네 명이 각자 디자인한 것처럼 보이기 시작했다.
그가 시도한 해결책들—레퍼런스 이미지 첨부, LoRA 파인튜닝, Midjourney 스타일 프리셋—은 모두 같은 이유로 실패했다. 모델이 브랜드를 기억할 수 있는 구조적 장치가 없었기 때문이다. 프롬프트는 매번 제로에서 시작한다. 레퍼런스 신호는 프롬프트 신호에 비해 약하다. Discord 채널에 있는 프리셋은 빌드 파이프라인 안으로 들어오지 못한다.
그래서 그는 API 형태 자체를 바꿨다. brand.config.ts에 팔레트, 스타일, 종횡비, 네거티브 프롬프트를 한 번만 선언하고, 컴포넌트는 <Inktag prompt="a wine cellar at golden hour" />처럼 주제만 받는다. 모델이 실제로 받는 프롬프트에서 브랜드 블록이 토큰의 80%를 차지하고, 주제는 20%다. 드리프트가 구조적으로 불가능한 설계다. 여기에 생성 후 비전 검증 레이어를 추가해 팔레트 히스토그램과 금지 요소를 자동으로 체크하고, 실패하면 재생성한다. 약 8%의 이미지가 재생성되지만 사용자는 실패한 이미지를 절대 보지 못한다.
이 사례가 단순한 React 라이브러리 소개에 그치지 않는 이유는, 제약(constraint)을 어디에 위치시킬 것인가라는 설계 원칙을 보여주기 때문이다. AI에게 모든 결정을 위임하는 것이 아니라, 브랜드 정체성은 코드 레이어에 고정하고 창의적 변수만 AI에게 열어두는 방식이다. Gautam 스스로 "constraints are the product"라고 표현한 이 원칙은 AI 이미지 생성을 넘어 훨씬 넓은 영역에 적용된다.
MeDo 실사용기가 보여주는 통합 플랫폼의 가능성과 한계
MeDo 리뷰를 작성한 fikuri는 처음엔 'v0, Lovable, Bolt와 다를 게 없겠지'라고 생각했다고 말한다. 그리고 2주를 써본 후 생각이 달라졌다. 차이는 통합의 깊이에 있었다. v0나 Lovable은 프론트엔드를 빠르게 만들어주지만, 완성된 프로덕트를 위해서는 Supabase, OpenAI, 결제 서비스 등을 각자 연결하고 API 키를 관리해야 한다. MeDo는 백엔드, LLM, 이미지 생성, TTS, 날씨 API 등을 플랫폼 안에 내장하거나 플러그인으로 통합한다.
이 구조의 실질적 이점은 디버깅 경험에서 가장 선명하게 드러났다. fikuri가 겪은 403 에러 사례에서 MeDo의 에이전트는 프론트엔드 코드뿐 아니라 Supabase 함수 로그를 함께 보고, 백엔드가 올바른 키로 재배포되지 않은 것을 원인으로 파악해 직접 재시작했다. 프론트엔드와 백엔드가 같은 코드베이스와 컨텍스트 안에 있기 때문에 가능한 엔드-투-엔드 디버깅이다. 이것은 단순한 편의 기능이 아니라 에이전트가 프로덕트 전체를 이해하는 구조적 조건이다.
그러나 솔직한 후기는 문제점도 숨기지 않는다. 플랫폼이 여전히 버그가 많고, UI가 느리며, 일부 화면이 영어로 완전히 번역되지 않았다. 특히 fikuri가 지적한 모델 정체성의 불투명함은 실무 관점에서 중요한 문제다. 'fast'와 'deep build' 모드가 있지만, 어떤 모델이 실제로 동작하는지, 어떻게 프롬프트해야 최적의 결과를 얻는지 알 수 없다. 도구를 믿고 워크플로우를 짜려면 도구의 동작 방식을 이해해야 한다. 블랙박스 위에 설계를 쌓는 것은 늘 불안한 기반이다.
두 사례가 교차하는 지점: 무엇을 잠글 것인가
Inktag와 MeDo는 서로 다른 문제를 다루지만, 핵심 시사점은 겹친다. AI 도구의 가치는 얼마나 많은 것을 자동화하느냐가 아니라, 개발자가 통제권을 유지해야 할 영역을 얼마나 명확하게 분리하느냐에 달려 있다.
Inktag는 브랜드 정체성을 config 레이어에 고정함으로써 AI의 자유도를 의도적으로 제한했다. MeDo는 인프라 통합을 플랫폼 레이어에 위임함으로써 개발자가 프로덕트 로직에 집중할 수 있는 공간을 만들었다. 두 접근 모두 '도구에게 모든 것을 맡기는' 방식이 아니다. 무엇을 잠그고, 무엇을 열어둘 것인가를 먼저 결정한 후, 그 기준에 맞는 도구를 선택하거나 설계했다.
반대로 생각하면, 기준 없이 도구를 먼저 선택하면 어떻게 되는가. Inktag가 등장하기 전 Gautam이 경험한 것처럼, 이미지는 매번 다른 방향으로 드리프트한다. MeDo의 블랙박스 모델처럼, 어떤 방식으로 프롬프트해야 할지 모른 채 결과만 기다리게 된다. 도구가 워크플로우를 주도하기 시작한다.
전망: 제약 설계가 AI 도구 선택의 새 기준이 된다
앞으로 AI 빌딩 도구는 더 많아지고, 더 강력해질 것이다. 그러나 도구가 강력해질수록 개발자에게 요구되는 것은 '더 잘 쓰는 기술'이 아니라 '무엇을 기준으로 쓸 것인가'라는 판단이다. Inktag의 config-first 접근은 React 컴포넌트 설계이기 이전에 제약 설계(constraint design)다. MeDo의 통합 플랫폼 실험은 프로토타이핑 도구 선택이기 이전에 통제권 위임 범위에 대한 판단이다.
프론트엔드 개발자로서 AI 도구를 실전에 통합할 때 가장 먼저 던져야 할 질문은 이것이다. "이 도구는 내가 잠그고 싶은 것을 잠글 수 있게 해주는가?" 그 질문에 답할 수 없다면, 도구를 선택하기 전에 먼저 잠글 것을 정해야 한다. 기준이 없으면, 도구가 기준을 만들기 시작한다.