AI 도구가 쏟아지는 속도가 빨라질수록, 오히려 더 근본적인 질문이 선명해진다. AI가 만들어준 결과물을, 나는 어떤 형태로 다루고 있는가? 멋진 코드 스니펫을 받아놓고 결국 다시 통째로 재생성하고 있다면, 문제는 모델 품질이 아니다. 출력물의 '형태'를 잘못 설정한 것이다.
그림과 청사진: AI 출력물의 두 가지 형태
dev.to에 게재된 글 "You Can't Nudge a Painting"은 이 문제를 날카롭게 짚는다. AI 출력물에는 본질적으로 두 가지 형태가 있다. 페인팅(Painting)과 블루프린트(Blueprint)다. 페인팅은 완성된 결과물이다. 나무를 조금 왼쪽으로 옮기고 싶다면? 다시 그려야 한다. 새로운 그림이 나오고, 하늘 색도 달라지고, 붓터치도 달라진다. 이전 그림을 수정한 게 아니라 새 그림을 주문한 것이다. 반면 블루프린트는 구조화되어 있다. 벽 하나를 옮겨도 집 전체를 다시 그릴 필요가 없다.
코드는 블루프린트다. HTML도, Figma 파일도, 타입이 정의된 함수 스키마도 모두 블루프린트다. 반대로 DALL-E가 생성한 이미지, 한 번 쓰고 버리는 Python 스크립트, 태그라인 시안 세 개는 페인팅이다. 어느 쪽이 우월한가의 문제가 아니다. 어떤 작업에 어떤 형태가 맞는가의 문제다. 유니크함이 가치인 작업엔 페인팅이 맞다. 반복·협업·버전 관리가 필요한 작업엔 블루프린트가 맞다. 이 둘을 혼용하면, AI 출력물은 '마법처럼 느껴지지만 실제로는 쓸 수 없는 무언가'가 된다.
Anthropic Claude Design이 공개적으로 건 내기
2026년 4월 17일, Anthropic이 Claude Design을 출시했을 때 많은 사람들은 슬라이드 제작 도구가 나왔다고 생각했다. 하지만 그 본질은 달랐다. Claude Design의 핵심은 더 큰 모델이 아니라 다른 형태의 아티팩트였다. LLM이 이미지가 아닌 HTML, CSS, JavaScript를 작성한다. 단어 하나를 바꾸고 싶다면 문자열을 수정하고 재렌더링하면 된다. 나머지는 그대로 유지된다. 로고도, 폰트도, 색상도. diff가 가능하고, 리뷰가 가능하며, 버전 관리가 된다. 슬라이드처럼 보이지만, 실제로 다루는 것은 코드다. 이것이 청사진 형태를 '원래 페인팅 작업이라고 여겨지던 영역'에 적용한 사례다.
프론트엔드 워크플로우에서 이미 벌어지고 있는 일
v0.dev는 텍스트나 스크린샷을 React + Tailwind 컴포넌트로 바꾼다. 픽셀이 아니라 코드로. tldraw의 'Make Real'은 캔버스 스케치를 HTML + CSS + JS로 변환해 곧바로 이터레이션할 수 있게 한다. Cursor는 편집기 안에서 코드 블록을 직접 수정한다. 이들의 공통점은 출력물이 편집 가능한 구조라는 것이다. 개발자가 AI에게 "이 컴포넌트 만들어줘"라고 요청하고 결과를 받는 것과, 그 결과를 청사진으로 삼아 수정·조합·고도화하는 것은 완전히 다른 워크플로우다. 전자는 AI를 자동 완성 도구로 쓰는 것이고, 후자는 AI를 설계 파트너로 쓰는 것이다.
코덱스 /goal 기능이 시사하는 것
OpenAI가 코덱스 CLI 0.128.0에 추가한 /goal 기능—이른바 '랄프 루프(Ralph Loop)'—은 이 논의를 에이전트 레벨로 끌어올린다. 개발자가 목표를 설정하면 코덱스가 계획 수립, 코드 작성, 테스트, 디버깅을 목표 달성까지 자율적으로 반복한다. /goal pause, /goal resume, /goal clear로 흐름을 제어할 수 있고, 상태는 '진행 중', '일시 중지', '달성', '미달성', '예산 제한'으로 구분된다. AI 타임즈가 보도한 내용에 따르면, 실제 사용자 작업이 11시간, 심지어 22시간을 넘겨 지속된 사례도 확인됐다.
이 기능이 흥미로운 이유는 단순 자동화 때문이 아니다. '목표와 성공 기준'을 구조적으로 정의하도록 개발자를 강제한다는 점이다. "특정 기능을 구현하고 테스트까지 완료하라"는 목표에는 이미 완료 조건이 내포되어 있다. 이것은 블루프린트 사고의 에이전트 버전이다. 단발성 프롬프트로 결과를 낚는 것이 아니라, 명확한 구조와 기준을 먼저 설계하고 AI에게 그 안에서 작동하도록 위임하는 방식이다. 물론 비용 폭발 리스크—무한 루프, 수천 번의 API 호출—는 여전히 현실적인 제약이며, 이는 성공 조건을 얼마나 명확하게 설계하느냐에 직접적으로 달려 있다.
실제 도구 선택에서도 같은 패턴이 보인다
dev.to의 실전 AI 도구 리뷰 글을 보면 이 원칙이 일상적인 선택에서도 작동한다는 걸 확인할 수 있다. 살아남은 도구들—Claude, Cursor, Notion AI—의 공통점은 '이미 내가 있는 곳에 통합되어 단계를 줄여준다'는 것이다. 반면 삭제된 도구들은 강력하지만 별도의 워크플로우를 요구했다. Midjourney를 삭제한 이유가 의미심장하다. "원하는 것을 정확히 만들 수 없었다"—그것은 페인팅의 본질적 한계이기도 하다. 구체적인 결과물을 반복 수정해야 하는 작업에 페인팅 형태의 도구를 쓴 것이다.
프론트엔드 팀이 지금 바꿔야 할 것
이 모든 흐름이 프론트엔드 워크플로우에 던지는 시사점은 명확하다. AI를 '결과를 받는 도구'가 아닌 '청사진을 만드는 도구'로 다시 설계하라. 구체적으로는 세 가지 전환이 필요하다.
첫째, 프로토타이핑 단계에서 이미지 생성보다 HTML/CSS/React 코드 생성을 기본 출력 형태로 설정하라. v0.dev나 Claude Design처럼 코드로 렌더링되는 결과물은 처음부터 편집 가능한 상태로 시작한다.
둘째, AI에게 작업을 위임할 때는 완료 조건을 함께 정의하라. 코덱스 /goal처럼 성공 기준이 명시된 작업은 무작위 재생성이 아니라 목표 지향적 이터레이션이 된다.
셋째, 도구 통합 기준을 '기능의 강력함'이 아닌 '기존 워크플로우에 얼마나 자연스럽게 끼워지는가'로 삼아라. 컨텍스트 스위칭 비용이 AI 도구의 실질 가치를 결정한다.
전망: 청사진 설계 역량이 개발자의 레버리지가 된다
앞으로 AI 모델의 생성 품질은 계속 올라갈 것이다. GPT-5.5 기반의 코덱스가 OS 커널 빌드나 데이터베이스 최적화 같은 고난도 작업을 수행할 수 있다는 건 이미 현실이다. 그렇다면 개발자의 진짜 레버리지는 더 좋은 프롬프트를 쓰는 데 있지 않다. AI 출력물이 어떤 형태를 가져야 하는지 먼저 판단하고, 그 형태가 이후 이터레이션과 협업에 적합하도록 구조를 설계하는 능력에 있다. 청사진을 설계하는 사람이 페인팅을 무한 재생성하는 사람보다 더 빠르게, 더 일관되게, 더 협업 가능한 결과물을 만들 것이다. AI가 강해질수록, 그것을 청사진으로 다루는 사람의 우위는 오히려 커진다.