vibe coding의 실력은 '지시 수정'에서 결정된다

첫 번째 생성보다, 두 번째 수정에서 도구의 성격이 드러납니다.

AI app builder나 coding agent의 데모는 대개 첫 화면이 기분 좋게 나옵니다. LP(Landing Page)가 만들어지고, dashboard가 나오고, form도 그럴싸합니다. 이것만 보면 이미 구현이 절반은 끝난 것처럼 보입니다.

하지만 실무에서 힘든 것은 그 이후입니다.

• navbar의 여백만 줄이고 싶다
• chart의 축 레이블(axis label)만 바꾸고 싶다
• form validation을 깨뜨리지 않고 문구를 바꾸고 싶다
• mobile의 card layout만 1컬럼으로 만들고 싶다
• hero image는 교체하고 싶지만 component 구조는 건드리고 싶지 않다

이런 부분을 겨냥해서 고칠 수 있는가. 게다가, diff(차이)를 읽을 수 있는 사이즈로 수렴하는가.

vibe coding의 평가 축은 이제 '생성할 수 있는가'만으로는 부족하다고 생각합니다. 보고 싶은 것은 '지시 수정(指差し修正)'에 얼마나 잘 견디는가입니다.

최근의 agent UI는 editor에 명령을 쓰는 방식이라기보다, 화면의 일부를 선택해 "여기를 고쳐줘"라고 말하는 방향으로 기울고 있습니다. selected area, annotation, screenshot comment 같은 조작입니다.

이것은 prompt engineering이라기보다, 상당히 code review에 가깝습니다.

좋은 review comment는 대상이 좁습니다.

이 card 전체를 다시 만들어줘

보다는,

이 card의 price 표시만, 월간/연간 toggle에 따라 변하도록 해줘

가 더 좋습니다.

AI에게 던지는 지시도 마찬가지로, 대상이 좁을수록 검증하기 쉬워집니다. 반대로, 모호한 지시를 내리면 agent는 관계없는 CSS, component 분할, routing까지 건드리기 시작할 때가 있습니다.

저라면 UI 생성 후의 수정 요청은 다음과 같이 나눕니다.

1. 변경 대상의 위치
2. 변경해도 좋은 범위
3. 건드리지 않았으면 하는 것
...

예를 들면 이렇습니다.

PricingSection의 plan card만 수정해 주세요.
desktop은 3 columns 그대로 유지하고, mobile만 1 column으로 만들어 주세요.
Plan data의 타입, CTA의 URL, billing toggle의 state는 변경하지 마세요.
...

이 정도로 좁게 작성하면 인간 측에서도 review하기 쉽습니다.

AI가 UI를 고친 후, 가장 먼저 보는 것은 화면이 아니라 diff여도 좋다고 생각합니다.

git diff --stat
git diff -- app components

여기서 navbar를 수정하는데 package.json이나 global CSS가 크게 바뀌어 있다면 일단 멈춥니다. 의도한 수정이 아닐 가능성이 높습니다.

특히 frontend repo에서는 국소 수정(local fix)을 하려던 것이 global override가 되기 쉽습니다.

/* 이것이 늘어난다면 경계할 것 */
.card {
width: 100%;
...

component 내부의 class를 조금 바꾸면 될 것을, global selector로 전체를 때려 부수고 있습니다. AI 생성 UI에서는 자주 있는 일입니다.

보는 순서는 대략 이렇습니다.

git diff --stat
git diff -- app components
git diff -- package.json pnpm-lock.yaml

lockfile이 바뀌어 있다면, 왜 dependency가 필요한지 확인합니다. UI의 여백 수정에 새로운 package가 들어온다면 상당히 수상합니다.

다음에 볼 것은 component의 책임(responsibility)입니다.

예를 들어 PricingSection의 외관 수정을 부탁했더니, agent가 Header, Footer, AppLayout까지 건드리고 있는 경우가 있습니다. 아마도 "전체적인 외관을 정돈한다"는 방향으로 해석했을 것입니다.

하지만 이것은 실무에서는 곤란합니다.

변경 범위가 넓어질수록 rollback(되돌리기)하기 어렵고, review의 초점도 흐려집니다.

저라면 수정 후에 이런 관점으로 보겠습니다.

• state(상태)의 소유자가 바뀌지 않았는가
• props(속성)가 갑자기 늘어나지 않았는가
• presentational component(프레젠테이션 컴포넌트)에 business logic(비즈니스 로직)이 들어있지 않은가
• CSS의 책임이 컴포넌트 외부로 새어나가지 않았는가
• unrelated component(관련 없는 컴포넌트)의 snapshot(스냅샷)이 변하지 않았는가

예를 들어, form(폼)의 copy(문구)를 변경했는데 validation schema(검증 스키마)까지 바뀌었다면 위험합니다.

// copy만 바꾸고 싶은데, 이 부분까지 바뀌어 있다면 확인이 필요함
const schema = z.object({
email: z.string().email(),
...

"작동한다"보다 "수정해야 할 부분만 수정했다"를 먼저 확인하는 것이 AI 생성물의 review(리뷰)를 안정적으로 만듭니다.

UI 수정은 diff(차이점)만으로는 부족합니다.

사람의 눈으로 본 "뭔가 괜찮네"는 다음 수정에서 쉽게 사라집니다. 그러므로 적어도 주요 화면은 screenshot(스크린샷)으로 재현할 수 있도록 해두고 싶습니다.

pnpm test
pnpm exec playwright test

Playwright를 사용 중인 repo(저장소)라면, 수정 대상 화면에 대해서만이라도 spec(스펙)을 만들어 두면 편리합니다.

import { expect, test } from "@playwright/test";
test("pricing cards keep mobile layout", async ({ page }) => {
await page.setViewportSize({ width: 390, height: 844 });
...

여기서 중요한 것은, 완벽한 visual regression(시각적 회귀) 환경을 갑자기 만드는 것이 아닙니다.

"이 수정은 이 URL, 이 viewport(뷰포트), 이 selector(셀렉터)로 확인한다"라는 발판을 남겨두는 것입니다. agent(에이전트)에게 다음 수정을 요청할 때도 이 발판이 있으면 대화가 빠릅니다.

이전과 동일한 pricing spec이 통과되는 범위 내에서, CTA button의 높이만 44px로 맞춰주세요.

이런 요청을 할 수 있게 됩니다.

UI 생성 시 잊기 쉬운 것이 이미지나 copy(문구)입니다.

실제 LP(랜딩 페이지)나 dashboard(대시보드)에서는 컴포넌트만으로 끝나지 않습니다. dummy data(더미 데이터), OG image(오픈 그래프 이미지), icon(아이콘), hero image(히어로 이미지), empty state(빈 상태)의 copy까지 함께 움직입니다.

AI로 만든 이미지를 mock(모크)이나 LP에 넣는 경우에도, 후처리를 수작업의 의지에만 맡기지 않는 것이 좋습니다. 예를 들어 Gemini / Google AI Studio 유래의 소재를 사용하는 workflow(워크플로우)라면, 저장 후의 cleanup(정리)을 매번 이미지 편집 소프트웨어로 하는 대신, Gemini의 워터마크를 제거하는 온라인 도구와 같은 browser-local(브라우저 로컬) 처리를 하나의 step(단계)으로 끼워 넣는 정도로 취급해야 작업의 흐름이 끊기지 않습니다.

여기서 말하고자 하는 것은 특정 도구에 대한 이야기가 아니라, asset(에셋)도 review(리뷰) 대상으로 삼아야 한다는 이야기입니다.

• 이미지의 비율이 깨지지 않았는가
• alt text(대체 텍스트)가 들어가 있는가
• dark mode(다크 모드)에서 보이는가
• mobile(모바일)에서 crop(자르기)이 이상해지지 않는가
• OG image와 본문 이미지가 섞이지 않았는가

code(코드)의 diff(차이점)만 깔끔해도 asset(에셋) 운용이 허술하면 UI는 망가집니다.

AI web app builder(웹 앱 빌더)의 평가 기준도 점점 "demo(데모)가 작동하는가"에서 멀어지고 있습니다.

SWE-WebDevBench와 같은 평가에서는 requirements(요구사항), architecture(아키텍처), production code(프로덕션 코드), iterative modification(반복적 수정), business readiness(비즈니스 준비도)까지 확인합니다. 이는 상당히 현장감이 있습니다.

frontend engineer(프론트엔드 엔지니어)가 내일부터 바라봐야 할 지점도 마찬가지입니다.

첫 화면이 나왔느냐가 아니라, 변경 요구에 추종할 수 있느냐입니다.

예를 들어, 다음과 같은 작은 요구사항입니다.

chart(차트)의 tooltip(툴팁)만 currency format(통화 형식)으로 바꿔주세요.
axis label(축 레이블)과 legend(범례)의 배치는 바꾸지 마세요.

이 수정으로 chart component (차트 컴포넌트) 전체를 다시 작성하는 agent (에이전트)는 무섭습니다. 반대로, formatter (포맷터)만 추가하고 test (테스트)와 screenshot (스크린샷)을 통과해 오는 agent (에이전트)는 상당히 사용하기 편리합니다.

채점표를 만든다면 다음과 같은 느낌이 됩니다.

생성 품질: 최초 UI가 요구 사항을 충족하는가
수정 국소성: 지시한 부분만 바뀌었는가
diff 가독성: review (리뷰) 가능한 사이즈인가
...

이 중에서 가장 간과하기 쉬운 것은 수정 국소성입니다.

하지만 실무에서는 이 부분이 핵심입니다. 좁게 고칠 수 있는 agent (에이전트)는 몇 번이고 부탁할 수 있습니다. 넓게 망가뜨리는 agent (에이전트)는 첫 demo (데모)가 예쁘더라도 무서워서 맡기기 어렵습니다.

지금이라면, 저는 AI 생성 UI를 다음과 같이 돌립니다.

# 1. 생성 전 상태 확인
git status --short
# 2. 좁은 지시로 수정시키기
...

여기서 위화감이 느껴진다면, 수정을 거듭하기보다 한 번 되돌립니다.

git restore app/components/PricingSection.tsx

물론 실제로는 file (파일) 단위로 되돌리기보다 patch (패치)를 보고 판단합니다. 다만, rollback (롤백) 할 수 있는 입도(granularity)로 작업해 두는 것이 중요합니다.

AI에게 맡길수록 되돌릴 수 있는 상태를 만들어 둔다. 이는 사소해 보이지만 상당히 효과적입니다.

vibe coding (바이브 코딩)의 가치는 처음의 마법 같은 생성보다, 그 이후의 지루한 수정 loop (루프)에서 나타납니다.

좋은 agent (에이전트) UI는 쓰는 화면이 아니라 고치는 화면에서 차이가 납니다.

"이 부분만 고쳐줘"가 통하는가. diff (디프)는 좁은가. state (상태)는 깨지지 않았는가. screenshot (스크린샷)으로 재현 가능한가.

여기까지 확인되어야 비로소 실무 도구로서 신뢰할 수 있습니다.

최초 생성의 화려함에 너무 휘둘리지 않고, 좁은 지시, 좁은 diff (디프), 재현 가능한 검증을 통해 사용할 수 있는 형태로 맞춘다. 지금의 AI frontend workflow (프론트엔드 워크플로우)는 바로 그 지점이 가장 흥미로운 부분이라고 생각합니다.