요즘 주변 디자이너들이 클로드 코드 설치 방법을 물어보는 걸 정말 많이 본다. 모두 바이브 코딩과 바이브 디자인에 열광하고 있다. 물론 나도 내가 만들고 싶은 걸 정말 쉽게 뚝딱 만들어가며 살고 있다. 한 번이라도 써보면, 이게 단순히 편한 도구 하나가 생긴 느낌이 아니라는 걸 바로 느끼게 된다. 예전에는 머릿속으로만 그리던 것들이 이제는 그냥 누워서 말로 던지면 바로 형태가 나온다.

그래서 요즘은 자연스럽게 작업의 시작점이 바뀌어 있다. 예전에는 피그마에서 이런 형태, 저런 형태를 먼저 그려본 다음, 구현에 대한 기술적인 고민을 했는데 지금은 완전히 정반대다. 이제는 구조나 기술적인 배경을 먼저 만들어 동작하는지를 보고, 그다음에 스타일과 디자인 정책을 입히기 시작한다. 그런데 생각해보면 원래 이렇게 만드는 게 맞지 않나 싶기도 하다. 실물 제품을 만들 때는 당연히 작동 여부를 테스트하고, 그다음에 껍데기를 씌우지 않나? 자동차도 엔진, 프레임, 축 같은 걸 먼저 만들어 굴러가는지를 테스트한 뒤, 그 위에 옷을 입히는 식이다. 아무튼 지금은 일단 만들어 보고, 나중에 맞추는 쪽으로 흐른다. 만들어야 하는 방향도 빨리 잡히고, 시도에 대한 부담도 없다.

그런데 이걸 몇 번 반복하다 보면 뭔가 애매하다. 이게 빠르긴 빠른데, 생각보다 결과물 자체가 빨리 나오는 건 아닌 것 같다. 원래는 앞에서 줄인 만큼 결과물도 빨리 나오는 게 맞는데, 중간에 멈추고 다시 돌아가고, 한 번에 끝날 것 같던 작업이 계속 늘어지기 시작한다. 특히 개발을 모르다 보니 계속 ‘아니야, 그게 아니야’ 하면서 AI한테 성질도 내고 욕도 하며 대판(?) 싸우게 된다. 그러다 해탈하는 시점이 오면, 이게 단순히 도구의 문제가 아니라 작업 방식에서 오는 패턴이라는 게 보인다.

물론 에이전트와 스킬, 오케스트레이션 같은 개념들을 배우고 도입하면 바이브 코딩이 어마어마한 효율성을 갖추게 되지만, 여기서는 그런 부분을 제외하고 생각해보려 한다. 정말 일반적인 비전공자, 비개발자들이 바이브 코딩을 처음 접했을 때 겪을 만한 현실적인 문제들을 한 번 짚어보려고 한다.

현실 1. AI는 아무것도 모른다

처음 바이브 코딩을 할 때는 “이거 만들어줘”로 시작하게 된다. 나도 별생각 없이 말하는 거라, 대충 방향만 던지고 결과를 보면서 맞추면 된다고 생각한다. 이런 방법도 되긴 된다. 그런데 계속 어긋나기 시작한다. 결과는 나오는데 내가 생각한 것과는 많이 다르다. 그래서 자꾸 설명을 덧붙이고, 다시 만들고, 또 고친다. 이게 계속 반복된다. 결과물은 짜잔! 의도와 다르게 누더기가 나온다. 내가 생각한 건 토스 같은 서비스인데, 뭔가 시중은행에서 쓰다가 버려진 포인트 적립 앱 같은 게 나오는 식이다.

이 과정을 다시 들여다보면, 대화를 주고받다 보면 처음에 내가 굳이 말하지 않은 정보들이 하나씩 붙는다. ‘해줘’였다가, ‘~~를 해줘’였다가, 다시 ‘~~에 ~~하는 ~~를 ~~하게 해줘’ 식으로 구체화된다. 어디에 쓰는 건지, 어떤 상황에서 필요한 건지, 어떤 식으로 동작해야 하는지 계속 추가된다. 설명이 길어질수록 결과는 맞아가지만, 그만큼 순식간에 복잡해진다. 그래서 방식을 바꿔야 한다. 바로 ‘해줘’가 아니라, 맥락을 최대한 풀어서 전달하는 쪽으로 가는 것이다. 내가 알고 있는 걸 먼저 다 깔아놓는 방식이다. 원래 좋은 스토리텔러는 이야기 도입부에서 빌드업을 엄청나게 잘해야 하는 법이다.

예를 들면, 예전에는 이렇게 썼다.

[피그마 코멘트를 백업하는 플러그인 만들어줘]

이렇게 쓰면 당연히 내가 원하는 방향이 나오지 않는다. 아마 이 글을 보는 독자들도 ‘어떻게 백업한다는 거야?’, ‘뭘 백업해서 저장하는 거야?’, ‘무슨 용도지?’ 하는 궁금증이 들어야 정상이다. 그게 맞다.

[피그마 파일의 모든 코멘트를 백업하고, 다른 피그마 파일에 복원할 수 있는 플러그인을 만들고 싶어. 백업되는 요소는 작성자 이름, 시간, 작성한 내용이야. 원본과 동일한 위치에 매칭하고 싶어. 백업한 댓글을 파일로 저장한 다음, 그 파일을 다시 넣는 방식으로 만들어줘.]

이렇게 맥락을 먼저 던져야 한다. 그래야 ‘아, 주인님께서 이런 걸 만들고 싶어 하시는구나!’ 하고 처음부터 알잘딱깔센으로 해준다. 즉, 디자인을 위한 기획을 잘 쓰는 게 중요하다. 제일 쉽게 연습하는 방법이 있긴 한데, 한 사람은 그림을 설명하고 다른 한 사람은 그림을 보지 않은 채 설명만 듣고 따라 그리는 방법이 있다. 생각보다 내가 얼마나 두루뭉술하게 설명하며 살았는지 뼈저리게 반성하는 시간이 될 것이다. 아무런 맥락 없는 “선 하나만 쭉 그어주세요”가 얼마나 폭력적인 요구사항이었는지 깨달아야 한다.

현실 2 : 똑똑하지만, 현명하진 않다

물론 AI의 속도는 인정할 수밖에 없다. 사람이 눈으로 읽는 동안, AI는 마치 마음으로 쭉 모든 코드를 읽고 해답을 내놓는 것처럼 보인다. 그래서 현자와 대화하는 느낌도 든다. 그런데 정작 내용은 엉터리 약장수 같은 느낌일 때가 있다. 로그인 기능을 만들어달라고 하면 정말 금방 나오고, 회원 관리 기능 같은 복잡한 어드민도 바로 나온다. 겉으로만 보면 ‘이대로 상용화 가즈아’ 싶은 수준까지 간다.

그런데 사람에게는 직감이라는 게 있지 않나. ‘이래도 되나’ 싶을 때는 멈추는 게 맞다. 로그인이나 회원 관리는 단순히 화면 하나를 만드는 문제가 아니다. 개인정보를 받게 되니, 이를 어떻게 저장할지부터 고민해야 한다. 민감 정보는 보안 문제와도 얽혀 있으니 암호화도 필요하고, 비밀번호 저장 방식과 접근 권한을 어떻게 나눌지, 약관은 어떻게 붙일지 같은 문제도 함께 따라온다. 이건 기능이라기보다 거의 시스템에 가깝다. 그리고 여기서 더 나아가 계정 찾기, 비밀번호 찾기 같은 기능도 필요하고, 비밀번호 초기화를 어드민이 가능하게 할지 말지처럼 세세한 부분까지 논의해야 한다. 1을 만들면 10이 생겨나는 게 맞다.

그런데 AI는 그냥 로그인 기능을 만든다. 회원 관리도 만든다. 각각은 버튼도 눌리고, 얼핏 보면 잘 돌아간다. 문제는 그게 서비스로 바로 쓸 수 있는 상태는 아니라는 점이다. 대표님들이 어디선가 AI 강의를 듣고 오셔서는 딸깍 만들어 실무진에게 프로토타입을 던지며 ‘이렇게 하자!’ 하는데, 실무자들이 속 터져 하는 이유가 이런 데서 온다. “이거 보안은?” “이거 데이터는?” 같은 문제가 뒤늦게 붙으면서 구조를 다시 건드리게 된다. 처음에 만든 것이 틀린 건 아닌데, 그렇다고 그대로 쓸 수 있는 상태도 아니다. 그래서 한 번 더 손을 대게 된다. 그러면 AI를 부려먹은 이유가 없다.

아마 대부분은 이렇게 할 것이다.

[로그인 기능 만들어줘]

이렇게 쓰면 ‘로그인’ 만 만든다. 로그인에 필요한 구조는 취약해진다.

[로그인/회원 관리 기능을 만들려고 하는데, 이게 실제 서비스 기준에서는 어떤 구조로 설계되어야 하는지 먼저 정리해줘. 보안, 개인정보 처리, 권한 구조까지 포함해서 필요한 요소와 구현 순서를 함께 제안해줘.]

이렇게 전달해야 AI도 로그인에 필요한 서비스 맥락을 받아들이고, 그에 필요한 구조를 점검할 수 있다. 또 회원 정보를 받기 위해 대폭적인 수정이 필요하다면, 계획부터 짜고 단계별로 처리해주는 등의 일도 가능해진다.

현실 3. 너무 내 위주로 맞춰준다

이건 AI 초창기부터 있던 환각과도 비슷하고, 기본적으로 사용자에게 동조하도록 만들어진 AI 특유의 ‘알랑방구’ 같은 성향이다. 처음 경험했을 때는 우와, 감정이 있네 싶으면서도 꽤 기분이 좋다. 내 의견을 납득하고 수용해주는 동료가 있으니 얼마나 좋은가. 내가 뭔가를 던지면 거의 대부분 ‘좋은 생각이다’로 시작한다. 그래서 초반에는 내가 맞는 방향으로 가고 있는 것처럼 느껴진다.

그런데 단맛도 계속 먹으면 쓴맛으로 느껴지는 법이다. 계속 내 말이 맞다고 하니, 이제는 오히려 신뢰가 가지 않는다. 그래서 질문 방식을 바꿔야 한다. 내가 선택지를 주고 의견을 묻는 것이 아니라, 스스로 적합한 해결책을 생각하도록 문제를 던지는 방향으로 가야 한다.

예전에는 이런 식으로 질문을 했던 것 같다.

[이런 구조보단 이렇게 하는 게 더 나은 거 아냐?]

그러면 십중팔구 “네, 당신의 의견이 더 맞는 방향이에요.”라는 답이 나온다. 이걸 어떻게 하면 의견 선택이 아니라, 스스로 제안하게 만들 수 있냐면 다음과 같이 던져보면 된다.

[지금 구조에서 사용자가 중간에 이탈할 가능성이 높은 구간을 줄이고 싶은데, 이걸 개선할 수 있는 다른 접근 방식이 있으면 제안해줘. 지금 구조를 유지하지 않아도 괜찮아.]

이렇게 해야 내 의견에 AI가 끌려가지 않고, 현재 상황을 다시 분석해서 부작용은 가장 적으면서도 사용자 의도를 가장 잘 구현하는 방법이 무엇인지 찾아오게 된다.

현실 4. 고칠수록 더 망가진다

바이브 코더들을 가장 많이 미치게 만드는 궁극의 포인트는 “왜 잘 되는데!”가 아니라, “왜 갑자기 안 되는데!”일 가능성이 높다. 물론 처음에는 잘 된다. 기능도 뭐 없고, 나 역시 ‘일단 작동은 하니까 여기서 스타일을 입혀야지’ 하면서 만들기 시작한다. 이제 하다보니까 이것도 필요하고 저것도 필요하고, 아까 했던 거 이렇게 수정해야 하고, 하다보면 오류도 생기니까 오류도 고쳐야 한다. 예를 들면, 사용자가 입력한 값이 맞지 않으면 어떤 모달을 띄워야 하는데, 그 모달이 뜨지 않는 식의 오류다. AI도 ‘간단한 수정이에요’라고 분명히 말했다. 그런데 안 고쳐진다. ‘아직 안 고쳐졌어’를 한 3번 정도 반복하면, AI도 ‘뭐가 문제지?’ 하면서 이번에는 저걸 고쳐보겠다고 하고, 또 이걸 고쳐보겠다고 반복한다.

어느새 모달이 나오지 않던 문제는 잊히고, 오류를 고치다가 만든 더 큰 오류 때문에 화면 자체가 다 박살 나거나 레이아웃이 뒤틀리거나, 아니면 화면이 아예 나오지 않는다. 개발자 도구를 열어보면 빨간 오류 줄이 멈추지 않고 계속 올라온다. 어찌저찌 해결해도, 이런 현상은 빈번하다. 점점 내가 하는 일이 코드나 구조를 설계하는 일이 아니라, ‘구멍 난 양말 기우는 것’처럼 느껴진다. 갑자기 현타도 온다. 이렇게 해서 만드는 게 맞나? 하는 허탈감이다. 전체를 보고 고치는 게 아니라 보이는 문제를 하나씩 해결하다 보니, 연결된 부분들이 계속 영향을 받는다.

그래서 수정 방식도 바꿔야 한다. 하나씩 던지지 않고, 꼭 묶어서 주는 습관을 들이자.

예를 들어,

[버튼 패딩 줄여줘]

[텍스트 키워줘]

[hover 했을 때 버튼 색 바꿔줘]

이런 식으로 했었다면, 지금은 이렇게 한다.

[아래 수정사항을 반영하고 결과를 요약해줘. 수정할 땐 반드시 사이드이펙트에 대해 분석 먼저 해줘.

UI 일관성

버튼 padding 전체 16px 기준으로 정리
텍스트 hierarchy 다시 맞추기

인터랙션

hover 상태 대비 더 명확하게 조정
우선순위는 UI → 인터랙션 순서로 적용할 것

이렇게 하면 확실히 수정하는 과정에서 오류가 나는 부분이 줄어든다. AI도 땜질식 대응이 아니라 전체를 보고 맥락에 맞게 수정 작업을 하게 되니, 결과도 더 좋아지는 것 같다. 여기서 ‘반드시 사이드 이펙트를 분석해달라’는 요청은, 앞으로는 스킬로 분리해 AI가 매번 자동으로 활용하도록 만드는 것이 더 바람직해 보인다.

아직은 ‘Human in the loop’가 필요하다

바이브 코딩이나 바이브 디자인을 해보면 확실히 정말 빠르다. 사용자 분석과 시장 분석부터 시작해 PRD 작성, 디자인 작업, 개발자에게 전달, 프로토타입 확인, QA, 배포까지 모든 과정이 뚝딱 가능하다. 아이디어를 바로 실물로 만드는 데 있어서는 거의 끝판왕에 가깝다. 하지만 그 속도를 그대로 끝까지 가져간다고 해도, 작업 자체가 짧아지지는 않았던 것 같다. 내가 빠르게 축약한 만큼 다른 부분에서 그 시간이 비용으로 붙는다. 간단한 문장만으로 만든 대가는, 추가 설명을 계속해야 하는 비효율과 불필요한 수정이 늘어나고 결국 코드를 다시 뒤집어엎어야 하는 비용으로 돌아온다.

그래서 이걸 무조건 ‘빠른 방식’이라고만 볼 수는 없다. 빠르게 출시하고 반응을 살펴본다는 MVP 제품 원칙에는 맞지만, 이게 단순히 빠르기만 하다고 되는 건 아니다. 전제는 ‘충분한 분석과 정교한 기획을 바탕으로’ 해야 제대로 빨라진다는 점이다. 그렇지 않으면 사실상 뒤쪽 단계로 시간을 전부 미뤄버리는 셈이 된다. 빠르게 만들 수 있는 대신, 그만큼 다시 맞추는 과정도 함께 따라온다. 초반 아이데이션과 프로토타이핑은 빠르게 가도 괜찮지만, 중간부터는 한 번 멈추고 정리해야 한다. 그 타이밍을 놓치면 작업은 계속 우회하고, 먼 길로 돌아가고, 삼천포로 빠지게 된다.

그리고 그 정리는 사람이 개입해야 가능한 부분이다. ‘Human in the loop’라는 말이 있다. AI가 작업하는 순환 구조 안에 사람이 개입해 관리하는 지점이 필요하다는 뜻이다. 쉽게 시작할 수 있는 만큼, 그 대가는 결국 정확하게 다시, 더 어렵게 돌아온다. 바이브 코딩에 공짜 점심은 없다.