C언어 학점 C였던 기획자가 99개 서비스를 만든 법

사실 나는 원래부터 코딩에 자신 있는 사람이 아니었다. 학교 다닐 때 C언어 과목 학점은 늘 C였다. 코딩 중간고사에서 구구단을 짜보라는 문제가 나왔던 기억이 어렴풋이 남아 있다. 그런데 나는 코드를 이해하는 대신 외우려고 했다. 또각또각 글자를 옮겨 적는 식이었다. 집에 돌아가면 아빠는 “장학생은 기대도 안 하는데 C는 너무하지 않냐”라고 하셨다. 그 시절 내가 힘들었던 건 단순히 성적 때문만은 아니었다. 동기들은 저마다 뭔가를 재미있게 구현하고 있었는데 나만 아무것도 만들지 못하는 사람처럼 느껴졌기 때문이다. 나는 코딩과 정말 안 맞는 사람이라고 스스로를 단정했다.

그런데 세상이 많이 바뀌었다. 말만 하면 어느 정도는 알아서 코딩을 해주는 시대가 오고 있다. 바이브코딩을 처음 접했을 때, 내 머릿속에만 있던 생각이 모니터 위에 짜잔 하고 나타나는 감각이 너무 신기했다. 코딩이 더 이상 나를 움츠러들게 만드는 대상이 아니라 내 생각을 한 번 실현해 보게 만드는 도구처럼 느껴졌다.

이 변화가 업무에 본격적으로 들어온 건 작년 11월쯤이었다. 회사에서 챗봇 서비스를 다루는 일이 있었다. 이미 개발팀이 작업을 어느 정도 마친 뒤 임원 보고까지 끝난 상태였는데 가시성이 떨어지고 강조 포인트가 잘 보이지 않는다는 피드백이 나왔다. 그렇게 수정 지시가 다시 내려왔고 나도 그 작업에 들어가게 되었다. 원래 같았으면 PPT를 수정해서 보여주었을 것이다. 화면 캡처를 붙이고, 장표를 고치고, 설명을 보강해서 "이렇게 바꾸면 어떨까요?"라고 말했을 것이다. 이미지가 너무 많아질 것 같아 동작하는 걸 직접 보여주는 편이 낫겠다고 판단했고 바이브코딩을 붙잡았다.

나는 여전히 비개발자였고, 깊은 기술을 파고드는 사람도 아니었다. 대신 사람의 흐름을 보고, 어디서 막히는지 상상하고, 화면이 어떻게 움직이면 더 이해가 쉬울지를 보는 데 익숙한 사람이었다. AI 코딩 도구는 그런 나에게 처음으로 생각을 바로 실체로 옮겨보았다. 수정한 화면을 직접 동작하게 만들어 선보였을 때 반응은 솔직히 좀 놀라웠다. "이렇게 동작해요"라고 보여주었을 때 훨씬 빨리 이야기가 앞으로 나아 같다. 서로 다른 상상을 하며 소모되던 시간이 줄어들었다. 기획안으로 설득하는데 2주가 걸리고 수십 번의 리뷰를 받아야 했던 일이 동작하는 결과물을 보여주자 30분 만에 끝났다.

그때 느꼈다. 좋은 생각을 말하는 것과, 좋은 생각을 검증 가능한 안으로 바꾸는 것은 전혀 다른 일이라는 것을

드림보드에 감사 일기를 넣은 날, 서비스가 흐려졌다.

KPI와 성공 조건을 먼저 정해야 검증이 가능하다

그 경험 이후 나는 아이디어가 떠오를 때마다 예전처럼 먼저 긴 문서를 쓰기보다 한 번씩 만들어보기 시작했다. 바이브코딩을 처음 접했을 때 내가 가장 많이 빠졌던 함정은 기능 과잉이었다. 개발 비용이 거의 들지 않으니 머릿속에 떠오르는 것들을 다 넣고 싶어졌다. 내 실패 사례 중 하나가 드림보드였다. 꿈과 목표를 시각적으로 관리하는 웹서비스를 만들고 싶었다. 노션처럼 깔끔하고, 핀터레스트처럼 카드가 쌓이고, 목표 달성률이 100퍼센트가 되면 폭죽 애니메이션까지 터지는 식으로 아주 구체적으로 프롬프트를 넣었다. 결과물은 꽤 놀라웠다. 내가 막연히 상상하던 드림보드가 화면 위에 나타났다. 미니멀해 보였고, 움직임도 그럴듯했다. 폭죽까지 터졌다.

문제는 그다음이었다. “어? 이걸 매일 쓰게 하려면 감사 일기 같은 것도 넣어볼까?” 그 생각이 드는 순간부터 서비스가 조금씩 이상해지기 시작했다. 감사 일기 탭을 붙이고, 기능을 더 얹고, 이것도 있으면 좋겠고 저것도 필요해 보였다. 그렇게 덧붙이다 보니 금방 누더기가 되었다. 처음에는 분명 목표를 한눈에 보고 움직이게 만드는 보드였는데, 어느 순간 미니멀은 사라지고 정보 구조가 꼬였다. 무엇보다 서비스의 정체성이 흐려졌다.