대바이브코딩 시대

자연어로 코딩을 하는 ‘바이브 코딩’이 익숙해지면서, 디자이너도 머릿속으로만 상상하던 화면을 실제 UI로 빠르게 구현할 수 있게 됐습니다. 예전에는 “이렇게 동작했으면 좋겠다” 수준의 아이디어가 프로토타입에서 끝나는 경우가 많았다면, 이제는 컴포넌트와 상태를 포함한 화면을 직접 만들고 수정하는 일이 점점 자연스러워지고 있습니다.

바이브 코딩의 한계

▲ 바이브코딩 하다보면 과부하는 일상이다.

그런데 바이브 코딩을 조금이라도 해본 사람이라면 금방 한계가 느껴집니다. 특정 부분만 수정하고 싶은데 AI가 주변까지 같이 손대면서 화면이 예상치 못하게 바뀌는 일이 자주 생깁니다. 버튼 하나를 다듬으려 했는데 카드 레이아웃이 달라지고, 텍스트 줄바꿈만 정리하려 했는데 폰트나 간격이 전반적으로 바뀌어 버리기도 합니다. 코드로 보면 사소해 보이는 변경이지만 UI에서는 4px의 간격, 정렬 한 칸의 어긋남, 라운드 정도의 차이가 전체 퀄리티를 크게 흔들기 때문에 이런 “원치 않는 수정”이 특히 치명적으로 느껴집니다.

앵커를 만들자

이럴 때 필요한 건 프롬프트를 더 길게 쓰는 기술이 아니라, 수정 범위를 고정하는 장치입니다.

저는 그 장치를 ‘앵커(anchor)’라고 부르는데, 쉽게 말해 AI가 핀포인트로 수정할 수 있도록 만들어 주는 표시입니다. 앵커는 여러 방식으로 만들 수 있습니다. data-ui 같은 데이터 속성을 붙이거나, 컴포넌트 경계 자체를 분리해서 “이 컴포넌트만 수정”이 가능하게 만들 수도 있고, “여기는 구조를 바꾸지 말라”는 가드레일 주석을 두는 방식도 있습니다. 저는 그중에서 가장 가볍게 시작할 수 있는 방법으로, 수정이 잦은 영역(특히 div)에 id를 부여하는 방식을 많이 씁니다. CTA 버튼, 요약 패널, 카드 리스트 같은 요소에 고유한 id를 달아두면, 추상적인 지시 대신 정확한 타겟을 지정할 수 있어 AI가 주변을 갈아엎는 확률이 줄어듭니다.

▲ Div에 id만 작성해놓으면, 길게 설명할 필요없이 특정 id를 수정해달라고하면 된다.

그렇다면 앵커의 이름은 어떻게 짓는게 좋을까요? 저는 “UI 타입(cta, summary, modal 등) + 상황(checkout, cart 등)” 조합으로 작명하는 편인데, 일관된 규칙만 잡아도 작업 속도와 정확도가 함께 좋아집니다. 꿀팁은 AI에게 “이 화면에서 핵심 CTA의 id를 역할이 드러나게 지어줘”라고 부탁하면 꽤 괜찮은 제안을 주는 경우가 많습니다. 왜냐면 AI는 코드의 맥락을 읽고 대표적인 이름을 지을 수 있기 때문입니다. 마음에 드는 규칙이 생기면 프로젝트에서 표준처럼 쓰면 되고요.

말로 지시하기 VS 앵커 지정하기

이 방식의 효과는 지시 문장만 비교해도 바로 드러납니다. “CTA 버튼 디자인 수정해줘”라고 말하면 AI는 CTA가 어디인지 추정하면서 주변 요소까지 같이 손대는 경우가 많습니다. 반대로 “checkout-cta의 디자인을 수정해줘”라고 하면 수정 대상이 고정됩니다.

여기에 한 줄만 더 얹으면 결과가 훨씬 안정됩니다. “checkout-cta의 디자인만 수정해줘. 구조나 텍스트는 유지하고 padding, radius, 색상만 조정해줘.” 이렇게 말하면 “어디를” 뿐 아니라 “어디까지”도 고정되어, 의도치 않은 구조 변경을 크게 줄일 수 있습니다. 결국 바이브 코딩에서 UI를 제어하는 핵심은 수정 대상(앵커)과 수정 범위(제약 조건)를 같이 주는 것입니다.

마무리

바이브 코딩은 속도가 빠른 만큼 수정이 누적될수록 화면이 쉽게 흔들립니다. 특히 디자이너가 만드는 UI는 작은 흔들림이 곧 퀄리티 하락으로 보이기 때문에, ‘정확하게 수정하는 능력’ 자체가 전문성처럼 보이기도 합니다. 저는 프롬프트를 더 잘 쓰는 것보다 먼저, 수정 영역을 고정하는 앵커를 만들고 그 앵커를 역할이 드러나게 이름 짓는 습관부터 가져가려고 합니다. 이 두 가지가 자리 잡히면 원하는 UI를 원하는 만큼만 손대는 일이 훨씬 쉬워지고, 개발자와 협업할 때도 “무엇을 바꾸고 무엇은 유지할지” 합의가 선명해집니다.