두 번째 발걸음 - 바이브 코딩

바이브 코딩으로 다양한 AI 도구를 활용하면 빠르게 프로토타입을 만들 수 있지만, 비용, 시간, 공유 방법이라는 세 가지 현실적 벽에 부딪힌다. 실패에서 배운 것들을 정리했다.

"서비스 기획 산출물을 프로토타입으로 제공하자" 라는 것도 한번에 정리된 것이 아니다.

잘 모르는 영역에 대해서는 처음부터 계획을 딱 세우고 하기 보다는 우선 부딪히면 배우는 개인적인 스타일이라, 이런 저런 시행착오 끝에 나온 목표이자 결과이다.

바이브 코딩을 어떻게 배웠을까?

이제는 너무 흔한 말이 되어버린 바이브 코딩이긴 하지만, 직무에 상관없이 "무조건 해보고 느껴야 하는 접근 방법" 이라고 생각한다.

유튜브를 따라해보니, 너무 쉽다. 하지만 결과물은 너무 괜찮다. 이 부분에서 위기감을 느꼈지만, 불안감은 잠시 뒤로 던지고, 툴을 익히는데 집중했다.

많이 시도해보고많이 실패해 보자

현재는 사용하지 않지만, 한방에 만들어준다고 했던 툴부터 시작해본다.

오~ 이게 되네? 내가 요청하지 않은 것도 AI가 추가 해준다. 오 이것도 괜찮은데? 의 연속이었다.

이 때 느낀점은 다음과 같다.

러프한 생각을 AI에 요청 하면,AI는 생각을 발산한다.기획자는 발산된 내용을 수렴해서 정리하면 하나의 기획서가 정리가 된다.발산된 생각 중에 내가 생각하지(기대하지) 않았던 것들을 잘 캐치해서 적용하는 것이 괜찮다.

학습된 데이터의 결과를 나에게 답을 주는 것 일텐데,

다양한 AI 툴들이 같은 답을 하는 것이라면 "내가 멈춰있었던 것" 이겠지 라며 **"오, 오늘도 하나 배웠어 오케이" **라고 생각하면서 배운다.

우선 범위를 정하고, 특정한 가이드 없이 요구사항에 대해서 구현을 요청한다.

이렇게 되면 내가 기대하고 있던 것과 다른 결과물이 나오게 되는데, 이 때 괜찮은 것을 Keep 한다.

간단히 페이지를 만드는 것은 다양한 툴에서 무료 버전에서도 제공한다. - Claude, Gemini, Perplexity 등

위의 내용에 대해서 다양한 툴에서 동일한 요청을 해서 괜찮은 아이디어를 여러 개 Keep 한다.

1번을 반복하면서 요구사항 정의서, 화면정의서, UI/UX 그리고 Validation 규칙 등을 명확하게 정리할 수 있었다.

프로토타입으로 만들다 보니, 실제 화면 눌러보면서 체크하면서, 사용자의 동선에 더 신경을 쓰게 되는 것은 바로 체감이 되고, 더 괜찮은 UX 에 대해서 고민할 수 있게 된 것이 가장 효과가 컸던 것 같다.

배우는 것은 좋은데, 아래의 3가지 문제점이 있다고 느꼈다. 아...이러면 의미가 없는데...

1. 비용

유료 구독을 통해서 몇번 만들어 봤더니, 월 한도가 다 되었다는 메시지에 요청/응답이 모두 다 돈이라는 것을 체감했다. 결과물은 아직 많이 부족한데, 돈이 더 들어간다. 이게 맞아? 라는 생각이 든다.

2. 시간

처음 요청해서 나온 결과물은 우와! 괜찮은데 인데, 세부적인 조정을 하려고 하면 내 말을 못알아 먹는데. 계속 요청하면 비용은 비용대로, 시간은 시간대로 들어간다. 이게 맞아? 라는 생각이 든다.

3. 결과물 공유 방법

결과물이 Github 또는 코드산출물인데, 이걸 디자이너와 개발자에게 공유할 수 없었다. 이게 맞아?

실패에서 배운다.