팝업스튜디오 첫 출근날, 제 앞자리에 앉은 사람이 있었어요.
뭐 하는 분인지 궁금해서 물어봤더니, 최근 열린 zero-100 빌더톤에서 가장 많은 표를 받아 인기상을 수상한 'Own It'의 바이브 빌더라고 하더라고요. '이 사람이다!' 싶었죠😎
황인준 님. 10년차 프론트엔드 개발자예요. 데이터 분석 서비스, 반려동물 이커머스, NFT, AI 교육 서비스까지... 스타트업을 전전하며 정말 다양한 도메인을 경험하셨더라고요. 기술적으로도 웹 개발부터 Flutter 앱, Web3, AI까지 폭넓게 다뤄오셨고요.
사무실에서 이런저런 대화를 많이 나눴는데, 정식 인터뷰는 서면으로 진행했습니다. 그런데 답변이 생각보다 훨씬 달변이시더라고요. 글로 써도 이 정도면 실제로 만나면 얼마나 재밌게 얘기하실지🤔
그런데 말입니다.
10년 동안 코딩해온 베테랑이 왜 '바이브 코딩'으로 사이드 프로젝트를 만들었을까요? 손에 익은 방식이 있을 텐데, 굳이?
"예전 방식이었다면 시도조차 못 했을 거예요. 바이브 코딩을 하면서 불가능들이 하나씩 깨진 게 아니라, 한꺼번에 깨져버렸거든요."
이 말이 너무 궁금해서 10개 질문을 던졌습니다. 10년차 개발자가 바이브 코딩을 '놀이'라고 표현하는 이유, AI가 짠 코드를 자기 이름으로 올려도 되는지에 대한 솔직한 고민, 그리고 코딩 1도 모르는 사람도 시작할 수 있는지까지.
바이브 코딩을 망설이고 계신 분들, 특히 "나는 이미 개발 잘 하는데 굳이?"라고 생각하시는 분들께 이 인터뷰를 권합니다✊
안녕하세요, 황인준입니다. 10년간 다양한 스타트업에서 프론트엔드 개발자로 일해왔습니다.
돌이켜보면 정말 다양한 도메인을 경험했더라고요. 데이터를 분석하고 가공하는 서비스, 반려동물 이커머스, NFT와 Web3, 그리고 가장 최근에는 AI 수학 교육 서비스에서 제품 개발을 했습니다. 의도했다기보다는 그때그때 회사에서 필요한 걸 하다 보니 자연스럽게 그렇게 됐어요.
기술적으로도 웹 개발부터 Flutter로 앱 개발, Web3, 그리고 AI까지 폭넓게 다뤄왔습니다. 한 분야만 깊게 파기보다는 필요한 게 있으면 일단 부딪혀보는 스타일이었던 것 같아요.
그리고 AI를 본격적으로 활용하기 시작하면서는 제 전문 분야가 아니더라도 관심 있는 주제(부동산, AI 트렌드)면 직접 만들어보고, 커뮤니티에 공유하는 방식으로 작업하고 있습니다.
Own It은 저와 함께 zero-100 빌더톤에 참여한 윤누리 님의 아이디어에서 시작됐습니다. 누리 님은 기획자로, 현재 GPTers라는 커뮤니티에서 교육 서비스 기획과 운영을 하고 계세요. 최근에는 바이브 코딩을 주제로 많은 기업에서 사내 교육 요청을 받고 계시기도 합니다.
서비스 아이디어는 사실 간단한 문제의식에서 출발했습니다. 바이브 코딩으로 멋진 결과물을 만들어내는 분들이 점점 많아지고 있는데, 정작 그걸 잘 보여줄 방법이 없더라고요. 이력서에 한 줄로 쓰기엔 너무 아쉽고, 그렇다고 포트폴리오를 따로 정리하자니 시간도 부담됩니다. 반대로 기업 입장에서도 이런 AI 인재들을 어디서 찾아야 할지 막막한 상황이었습니다.
Own It은 이 문제를 해결하려고 만들었어요. GitHub에 결과물을 올리기만 하면, 자연스럽게 포트폴리오로 정리되는 서비스입니다. 개발자가 아닌 분께 설명하자면, "만들기만 하면 알아서 이력서가 되는 서비스"라고 할 수 있을 것 같아요.
빌더톤 이후로는 Own It을 통해 바이브 코더들이 모이고, 함께 프로젝트를 진행하고, 그 과정에서 기업의 AI 전환을 도울 수 있는 인재 풀로 성장시켜보고 싶다는 목표를 갖고 있습니다.
몇 가지 이유가 있는데요, 크게 네 가지로 말씀드릴 수 있을 것 같아요.
첫 번째는 속도입니다. 예전에는 하나 만들려면 설계부터 꼼꼼히 하고, 코드 한 줄 한 줄 직접 작성해야 했어요. 지금은 아이디어가 떠오르면 바로 프로토타입을 만들어볼 수 있습니다. 생각에서 결과물까지의 거리가 확 줄어든 거죠.
두 번째는 과감함이에요. 사실 경력이 쌓이면 오히려 보수적이 되거든요. "이건 시간 오래 걸리겠다", "이 기술은 내가 잘 모르니까 패스하자" 이런 판단을 먼저 하게 됩니다. 그리고 무엇보다 예전에는 못할 이유가 너무 많았어요. 백엔드 개발자가 없어서 못 하고, 디자이너가 없어서 못 하고, 시간이 없어서 못 하고. 근데 바이브 코딩을 하면서는 그런 핑계가 사라졌어요. 백엔드 모르면 AI한테 물어보면서 하면 되고, 디자인도 일단 만들어보면 되니까요. 이제는 정말 못할 이유가 없어졌습니다.
세 번째는 작업 방식의 변화입니다. 예전에는 혼자 머리 싸매고 코드 짜는 시간이 대부분이었는데, 지금은 AI랑 대화하면서 기획도 같이 하고, 구조도 같이 잡고, 코드 리뷰도 받아요. 혼자 개발하는데 혼자가 아닌 느낌입니다.
마지막으로 재미입니다. 솔직히 이게 제일 커요. 10년 하다 보면 개발이 일처럼 느껴질 때가 있거든요. 근데 바이브 코딩은 뭔가 새로운 장난감을 가지고 노는 느낌이에요. "이것도 되네?", "이렇게까지 할 수 있어?" 하면서 만드는 재미가 다시 생겼습니다.
충분히 고민되는 지점이라고 생각해요. 저도 1~2년간 Cursor나 Claude Code를 쓰면서 비슷한 고민을 했거든요. AI가 짜준 코드를 그대로 쓰다 보면, 정확히 이해 못 하고 넘어갈 때가 종종 있었어요. 그럴 때마다 "이게 진짜 내 코드인가?" 하는 생각이 들었습니다.
그런데 최근에 팝업스튜디오 김경호 님께서 해주신 말씀이 생각을 바꿔줬어요. 경호 님은 이렇게 말씀하시더라고요.
"AI가 짰다고 해서 정석을 지키지 않아도 되는 건 아닙니다. 저는 AI가 코드를 작성하지만, 제가 만든 서비스의 비즈니스 로직을 전부 설명할 수 있습니다."
이 말이 크게 와닿았어요. 바쁘다는 핑계로 대충 넘어간 적이 있었거든요. 근데 AI가 쓴 코드를 내가 소화하는 과정까지가 바이브 코딩이라고 생각하면, 찝찝하거나 내가 한 게 아니라는 생각은 들지 않을 것 같습니다. 결국 그 코드를 이해하고 책임지는 건 저니까요.
솔직히 말씀드리면, 예전 방식이었다면 시도조차 못 했을 것 같아요.
저는 커리어를 프론트엔드로 시작해서, 백엔드는 사이드 프로젝트에서 정말 대안이 없을 때만 직접 건드렸거든요. 그마저도 사이드 프로젝트가 흐지부지되면 결론 없이 끝나는 경우가 많았습니다. Own It 같은 서비스를 혼자 만든다? 예전 같았으면 엄두도 못 냈을 거예요.
그리고 경력이 쌓이면서 오히려 더 조심스러워지더라고요. 어떤 일을 시작하기 전에 "이거 얼마나 걸리지?", "뭐가 필요하지?" 예측이 되니까, 안 해본 건 시도 자체를 안 하게 됩니다. 바이브 코딩을 해도 여전히 그런 습관이 남아있어요.
그런 면에서 같이 작업한 누리 님한테 많이 배웠습니다. 누리 님은 훨씬 과감하게 시도하시거든요. 파이썬이든 타입스크립트든 코틀린이든, 시작하는 시점에서 언어가 크게 문제가 안 되는 거예요. 어떤 문제가 나오든 마주할 준비가 되어 있는 느낌이랄까요.
실제로 Own It의 데일리 리뷰 기능이 그렇게 만들어졌어요. Claude Code로 작업하다가 커스텀 커맨드 한 번이면 하루 작업이 분석되는 기능인데요, 토큰을 얼마나 썼는지, 주요 작업의 핵심 요약까지 한 번에 보여줍니다. 솔직히 제 상상 범위 밖의 기능이었어요. 누리 님이 먼저 만들어주셨고, 저는 그걸 이해하면서 기능을 개선해나갔습니다. 그게 진짜 바이브 코딩을 잘하는 거라는 생각이 들었어요.
사실 이 질문에 딱 맞는 대답을 드리기가 어려울 것 같아요. "예전엔 왜 이렇게 했지?"라기보다는, 예전엔 아예 못 했던 거거든요.
요즘 다른 분들과 이야기할 때 AI 없이 개발하는 방식을 "전통적인 방식"이라고 부르곤 하는데요, 전통적인 방식으로는 불가능한 일들이 정말 많았습니다. 시간이 없어서, 인력이 없어서, 기술을 몰라서.
근데 바이브 코딩을 하면서 그 불가능들이 하나씩 깨진 게 아니라, 한꺼번에 깨져버렸어요. 바이브 코딩이 재밌다, 놀이 같다고 표현하시는 분들이 많은데, 그 즐거움의 핵심이 바로 이거라고 생각해요. "이것도 되네?", "이것까지 할 수 있어?" 하면서 불가능이 가능으로 바뀌는 걸 발견하는 재미요.
당연하게도, 바이브 코딩을 하면서 개발자로서 역량을 다 쏟지 않고 가볍게 넘겼던 부분들이 나중에 크게 돌아왔습니다. "나중에 보면 되겠지" 하고 설계를 허술하게 한 부분들이 꼭 문제가 됐습니다.
해결 방법은 사실 AI를 쓰기 전 방식과 크게 다르지 않았어요. 어디가 문제인지 찾아가고, "왜 그때 가볍게 넘겼을까" 자책하면서 하나씩 고쳐나갔습니다. AI가 마법처럼 해결해주는 건 아니더라고요.
바이브 코딩 처음 하시는 분들께 팁을 드리자면, 기능을 잘게 쪼개서 단계적으로 해결해보시길 추천드립니다. 예를 들어 회원가입 기능을 만들고 싶다면, 먼저 내가 생각하는 회원가입이 뭔지 정리하고, 필요한 것들을 쭉 나열한 다음, 우선순위대로 하나씩 처리하는 방법입니다. 한 번에 다 만들려고 하면 AI도 헷갈리고 저도 헷갈립니다. 그리고 큰 덩어리는 해결하기 어렵지만, 잘게 나눴을 때는 한 번에 구현해야 되는 범위가 분명해져서 도움이 많이 됩니다.
저는 친구처럼 가볍게 말 거는 스타일이에요. 작업 시작할 때 "안녕" 하고 인사부터 합니다. 샘 알트만이 "제발 인사나 감사 표현 하지 마세요, 돈 낭비입니다"라고 했다는데, 저는 그냥 작업 시작하기 좋은 말인 것 같아서 계속 하고 있어요.
실질적인 팁을 드리자면, "XX 만들어줘"라고 바로 시키기보다 먼저 기획 회의를 해요. 내가 생각하는 XX가 뭔지 설명하거나, AI랑 같이 구체화하는 거죠. 기획 회의라고 생각하시면 돼요.
그래서 이 기능이 뭔지 명확하게 이해가 되고, "이거 바로 개발 가능하겠다" 싶을 때 문서로 정리해달라고 합니다. 그다음 이 기능을 개발하기 위한 세부 계획을 체크리스트로 만들어달라고 요청하고요. 저는 AI가 개발한 걸 체크리스트로 하나씩 확인하고 테스트하면서 기능을 완성시킵니다.
정리하면, 기획 회의 → 문서화 → 체크리스트 → 하나씩 개발 및 테스트. 이 흐름이 저한테는 제일 잘 맞더라고요.
네, 정말 강력하게 추천드립니다.
다만 한 가지 말씀드리고 싶은 게 있어요. 요즘 "바이브 코딩으로 앱 만들어서 월 얼마 벌었다" 같은 글들이 많이 보이잖아요. 근데 바이브 코딩의 목적이 "돈"이라면 좀 실망하실 수도 있어요. 물론 좋은 서비스를 만들면 수익이 따라올 수 있지만, 그게 전부는 아니거든요.
저는 바이브 코딩의 진짜 가치가 일상의 소소한 문제를 해결하는 데 있다고 생각해요. 예를 들어볼게요. 이메일을 100통 보내야 하는데, 각각 고객 이름을 다르게 넣어야 한다고 해봐요. 예전 같으면 100번 복사 붙여넣기 하거나, 엑셀로 참조 걸어서 보내겠죠. 근데 AI를 쓰면 이름만 바꾸는 게 아니라, 고객별로 개인화된 내용까지 넣은 이메일을 만들 수 있어요.
이런 식으로 자신의 일상 업무나 소소한 문제들을 해결해보는 즐거움을 느끼셨으면 좋겠습니다. 그게 바이브 코딩의 시작이에요.
솔직히 말씀드리면, 저도 주변 친구들한테 "AI 써봐", "바이브 코딩 해봐" 엄청 많이 얘기하거든요. 근데 실제로 해봤다는 사람은 별로 없어요. 제가 설득을 못 하는 건가 싶기도 하고요.
그래도 하나는 단언할 수 있어요. 내가 가진 소소한 문제든, 나 혼자 해결하기엔 커 보이는 문제든, 다른 사람한테 도와달라고 하기 애매한 그런 문제들 있잖아요. 바이브 코딩이 그걸 가장 가까이서, 생각보다 빨리 도와줄 수 있는 방법이에요.
요즘 "AI 때문에 대량 해고", "살아남으려면 배워야 한다" 이런 말들이 많은데, 그런 무거운 마음으로 시작하지 않으셨으면 좋겠어요. 어렸을 때 레고 하듯이, 가벼운 마음으로 한번 시도해보세요. 블록 하나씩 쌓아가면서 뭔가 완성되는 그 과정이, 진짜 어렸을 때 느꼈던 그 즐거움이랑 똑같습니다.
레고도 누구한테 배워서 하는 게 아니잖아요. 정답도 없고요. 만들어가는 과정을 즐기다 보면, 그때 "더 배우고 싶다"는 생각이 자연스럽게 드실 거예요. 그건 장담합니다.
사실 빌더톤 끝난 다음 날부터 새로운 아이디어가 떠올라서, 벌써 기획하고 야금야금 개발하고 있어요.
주변에서 커뮤니케이션을 잘한다고 말씀해주시는 분들이 많은데, 그래서인지 저는 계속 사람들 간의 협업을 돕는 서비스에 관심이 가더라고요. 예를 들면 디자이너와 개발자가 Figma랑 Slack으로 소통하는데, 이게 생각보다 쉽지 않거든요. 그 부분을 개선해보고 싶고요. 팀에서 Jira로 이슈 관리하는 것도 더 잘 활용할 수 있는 도구를 만들어보고 싶어요.
업무에 지장 가지 않는 선에서, 지속적으로 만들고 배포하고 홍보까지 해보는 게 목표입니다.
다른 AI 커뮤니티와 달리 bkamp는 바이브 코딩이라는 주제에 집중한 커뮤니티예요. 그게 가장 큰 차이점인 것 같아요.
이 커뮤니티의 장점은 정말 실력 있는 분들이 바이브 코딩 생태계를 확장시키려고 엄청 노력하신다는 거예요. 24시간 대기하시면서 꼭 봐야 하는 글들 공유해주시고, 어려움 겪는 분들 도와주시고요.
그리고 다른 사람들이 어떤 생각을 하고, 어떻게 문제를 해결해가는지 보는 것 자체가 자극이 돼요. 혼자 만들다 보면 시야가 좁아지기 쉬운데, bkamp에서 다른 분들 과정을 보면서 많이 배우고 있습니다.
인터뷰를 마치며
10년차 개발자가 "이제 안 쓸 이유가 없다"고 말하는 바이브 코딩. 핵심은 결국 '불가능이 가능으로 바뀌는 재미'였어요. 베테랑도 초보도 똑같이 느낄 수 있는 그 즐거움, 여러분도 한번 경험해보시길 바랍니다.
레고처럼, 가볍게 시작해보세요✊
댓글을 작성하려면 로그인이 필요합니다.
팝업스튜디오 첫 출근날, 제 앞자리에 앉은 사람이 있었어요.
뭐 하는 분인지 궁금해서 물어봤더니, 최근 열린 zero-100 빌더톤에서 가장 많은 표를 받아 인기상을 수상한 'Own It'의 바이브 빌더라고 하더라고요. '이 사람이다!' 싶었죠😎
황인준 님. 10년차 프론트엔드 개발자예요. 데이터 분석 서비스, 반려동물 이커머스, NFT, AI 교육 서비스까지... 스타트업을 전전하며 정말 다양한 도메인을 경험하셨더라고요. 기술적으로도 웹 개발부터 Flutter 앱, Web3, AI까지 폭넓게 다뤄오셨고요.
사무실에서 이런저런 대화를 많이 나눴는데, 정식 인터뷰는 서면으로 진행했습니다. 그런데 답변이 생각보다 훨씬 달변이시더라고요. 글로 써도 이 정도면 실제로 만나면 얼마나 재밌게 얘기하실지🤔
그런데 말입니다.
10년 동안 코딩해온 베테랑이 왜 '바이브 코딩'으로 사이드 프로젝트를 만들었을까요? 손에 익은 방식이 있을 텐데, 굳이?
"예전 방식이었다면 시도조차 못 했을 거예요. 바이브 코딩을 하면서 불가능들이 하나씩 깨진 게 아니라, 한꺼번에 깨져버렸거든요."
이 말이 너무 궁금해서 10개 질문을 던졌습니다. 10년차 개발자가 바이브 코딩을 '놀이'라고 표현하는 이유, AI가 짠 코드를 자기 이름으로 올려도 되는지에 대한 솔직한 고민, 그리고 코딩 1도 모르는 사람도 시작할 수 있는지까지.
바이브 코딩을 망설이고 계신 분들, 특히 "나는 이미 개발 잘 하는데 굳이?"라고 생각하시는 분들께 이 인터뷰를 권합니다✊
안녕하세요, 황인준입니다. 10년간 다양한 스타트업에서 프론트엔드 개발자로 일해왔습니다.
돌이켜보면 정말 다양한 도메인을 경험했더라고요. 데이터를 분석하고 가공하는 서비스, 반려동물 이커머스, NFT와 Web3, 그리고 가장 최근에는 AI 수학 교육 서비스에서 제품 개발을 했습니다. 의도했다기보다는 그때그때 회사에서 필요한 걸 하다 보니 자연스럽게 그렇게 됐어요.
기술적으로도 웹 개발부터 Flutter로 앱 개발, Web3, 그리고 AI까지 폭넓게 다뤄왔습니다. 한 분야만 깊게 파기보다는 필요한 게 있으면 일단 부딪혀보는 스타일이었던 것 같아요.
그리고 AI를 본격적으로 활용하기 시작하면서는 제 전문 분야가 아니더라도 관심 있는 주제(부동산, AI 트렌드)면 직접 만들어보고, 커뮤니티에 공유하는 방식으로 작업하고 있습니다.
Own It은 저와 함께 zero-100 빌더톤에 참여한 윤누리 님의 아이디어에서 시작됐습니다. 누리 님은 기획자로, 현재 GPTers라는 커뮤니티에서 교육 서비스 기획과 운영을 하고 계세요. 최근에는 바이브 코딩을 주제로 많은 기업에서 사내 교육 요청을 받고 계시기도 합니다.
서비스 아이디어는 사실 간단한 문제의식에서 출발했습니다. 바이브 코딩으로 멋진 결과물을 만들어내는 분들이 점점 많아지고 있는데, 정작 그걸 잘 보여줄 방법이 없더라고요. 이력서에 한 줄로 쓰기엔 너무 아쉽고, 그렇다고 포트폴리오를 따로 정리하자니 시간도 부담됩니다. 반대로 기업 입장에서도 이런 AI 인재들을 어디서 찾아야 할지 막막한 상황이었습니다.
Own It은 이 문제를 해결하려고 만들었어요. GitHub에 결과물을 올리기만 하면, 자연스럽게 포트폴리오로 정리되는 서비스입니다. 개발자가 아닌 분께 설명하자면, "만들기만 하면 알아서 이력서가 되는 서비스"라고 할 수 있을 것 같아요.
빌더톤 이후로는 Own It을 통해 바이브 코더들이 모이고, 함께 프로젝트를 진행하고, 그 과정에서 기업의 AI 전환을 도울 수 있는 인재 풀로 성장시켜보고 싶다는 목표를 갖고 있습니다.
몇 가지 이유가 있는데요, 크게 네 가지로 말씀드릴 수 있을 것 같아요.
첫 번째는 속도입니다. 예전에는 하나 만들려면 설계부터 꼼꼼히 하고, 코드 한 줄 한 줄 직접 작성해야 했어요. 지금은 아이디어가 떠오르면 바로 프로토타입을 만들어볼 수 있습니다. 생각에서 결과물까지의 거리가 확 줄어든 거죠.
두 번째는 과감함이에요. 사실 경력이 쌓이면 오히려 보수적이 되거든요. "이건 시간 오래 걸리겠다", "이 기술은 내가 잘 모르니까 패스하자" 이런 판단을 먼저 하게 됩니다. 그리고 무엇보다 예전에는 못할 이유가 너무 많았어요. 백엔드 개발자가 없어서 못 하고, 디자이너가 없어서 못 하고, 시간이 없어서 못 하고. 근데 바이브 코딩을 하면서는 그런 핑계가 사라졌어요. 백엔드 모르면 AI한테 물어보면서 하면 되고, 디자인도 일단 만들어보면 되니까요. 이제는 정말 못할 이유가 없어졌습니다.
세 번째는 작업 방식의 변화입니다. 예전에는 혼자 머리 싸매고 코드 짜는 시간이 대부분이었는데, 지금은 AI랑 대화하면서 기획도 같이 하고, 구조도 같이 잡고, 코드 리뷰도 받아요. 혼자 개발하는데 혼자가 아닌 느낌입니다.
마지막으로 재미입니다. 솔직히 이게 제일 커요. 10년 하다 보면 개발이 일처럼 느껴질 때가 있거든요. 근데 바이브 코딩은 뭔가 새로운 장난감을 가지고 노는 느낌이에요. "이것도 되네?", "이렇게까지 할 수 있어?" 하면서 만드는 재미가 다시 생겼습니다.
충분히 고민되는 지점이라고 생각해요. 저도 1~2년간 Cursor나 Claude Code를 쓰면서 비슷한 고민을 했거든요. AI가 짜준 코드를 그대로 쓰다 보면, 정확히 이해 못 하고 넘어갈 때가 종종 있었어요. 그럴 때마다 "이게 진짜 내 코드인가?" 하는 생각이 들었습니다.
그런데 최근에 팝업스튜디오 김경호 님께서 해주신 말씀이 생각을 바꿔줬어요. 경호 님은 이렇게 말씀하시더라고요.
"AI가 짰다고 해서 정석을 지키지 않아도 되는 건 아닙니다. 저는 AI가 코드를 작성하지만, 제가 만든 서비스의 비즈니스 로직을 전부 설명할 수 있습니다."
이 말이 크게 와닿았어요. 바쁘다는 핑계로 대충 넘어간 적이 있었거든요. 근데 AI가 쓴 코드를 내가 소화하는 과정까지가 바이브 코딩이라고 생각하면, 찝찝하거나 내가 한 게 아니라는 생각은 들지 않을 것 같습니다. 결국 그 코드를 이해하고 책임지는 건 저니까요.
솔직히 말씀드리면, 예전 방식이었다면 시도조차 못 했을 것 같아요.
저는 커리어를 프론트엔드로 시작해서, 백엔드는 사이드 프로젝트에서 정말 대안이 없을 때만 직접 건드렸거든요. 그마저도 사이드 프로젝트가 흐지부지되면 결론 없이 끝나는 경우가 많았습니다. Own It 같은 서비스를 혼자 만든다? 예전 같았으면 엄두도 못 냈을 거예요.
그리고 경력이 쌓이면서 오히려 더 조심스러워지더라고요. 어떤 일을 시작하기 전에 "이거 얼마나 걸리지?", "뭐가 필요하지?" 예측이 되니까, 안 해본 건 시도 자체를 안 하게 됩니다. 바이브 코딩을 해도 여전히 그런 습관이 남아있어요.
그런 면에서 같이 작업한 누리 님한테 많이 배웠습니다. 누리 님은 훨씬 과감하게 시도하시거든요. 파이썬이든 타입스크립트든 코틀린이든, 시작하는 시점에서 언어가 크게 문제가 안 되는 거예요. 어떤 문제가 나오든 마주할 준비가 되어 있는 느낌이랄까요.
실제로 Own It의 데일리 리뷰 기능이 그렇게 만들어졌어요. Claude Code로 작업하다가 커스텀 커맨드 한 번이면 하루 작업이 분석되는 기능인데요, 토큰을 얼마나 썼는지, 주요 작업의 핵심 요약까지 한 번에 보여줍니다. 솔직히 제 상상 범위 밖의 기능이었어요. 누리 님이 먼저 만들어주셨고, 저는 그걸 이해하면서 기능을 개선해나갔습니다. 그게 진짜 바이브 코딩을 잘하는 거라는 생각이 들었어요.
사실 이 질문에 딱 맞는 대답을 드리기가 어려울 것 같아요. "예전엔 왜 이렇게 했지?"라기보다는, 예전엔 아예 못 했던 거거든요.
요즘 다른 분들과 이야기할 때 AI 없이 개발하는 방식을 "전통적인 방식"이라고 부르곤 하는데요, 전통적인 방식으로는 불가능한 일들이 정말 많았습니다. 시간이 없어서, 인력이 없어서, 기술을 몰라서.
근데 바이브 코딩을 하면서 그 불가능들이 하나씩 깨진 게 아니라, 한꺼번에 깨져버렸어요. 바이브 코딩이 재밌다, 놀이 같다고 표현하시는 분들이 많은데, 그 즐거움의 핵심이 바로 이거라고 생각해요. "이것도 되네?", "이것까지 할 수 있어?" 하면서 불가능이 가능으로 바뀌는 걸 발견하는 재미요.
당연하게도, 바이브 코딩을 하면서 개발자로서 역량을 다 쏟지 않고 가볍게 넘겼던 부분들이 나중에 크게 돌아왔습니다. "나중에 보면 되겠지" 하고 설계를 허술하게 한 부분들이 꼭 문제가 됐습니다.
해결 방법은 사실 AI를 쓰기 전 방식과 크게 다르지 않았어요. 어디가 문제인지 찾아가고, "왜 그때 가볍게 넘겼을까" 자책하면서 하나씩 고쳐나갔습니다. AI가 마법처럼 해결해주는 건 아니더라고요.
바이브 코딩 처음 하시는 분들께 팁을 드리자면, 기능을 잘게 쪼개서 단계적으로 해결해보시길 추천드립니다. 예를 들어 회원가입 기능을 만들고 싶다면, 먼저 내가 생각하는 회원가입이 뭔지 정리하고, 필요한 것들을 쭉 나열한 다음, 우선순위대로 하나씩 처리하는 방법입니다. 한 번에 다 만들려고 하면 AI도 헷갈리고 저도 헷갈립니다. 그리고 큰 덩어리는 해결하기 어렵지만, 잘게 나눴을 때는 한 번에 구현해야 되는 범위가 분명해져서 도움이 많이 됩니다.
저는 친구처럼 가볍게 말 거는 스타일이에요. 작업 시작할 때 "안녕" 하고 인사부터 합니다. 샘 알트만이 "제발 인사나 감사 표현 하지 마세요, 돈 낭비입니다"라고 했다는데, 저는 그냥 작업 시작하기 좋은 말인 것 같아서 계속 하고 있어요.
실질적인 팁을 드리자면, "XX 만들어줘"라고 바로 시키기보다 먼저 기획 회의를 해요. 내가 생각하는 XX가 뭔지 설명하거나, AI랑 같이 구체화하는 거죠. 기획 회의라고 생각하시면 돼요.
그래서 이 기능이 뭔지 명확하게 이해가 되고, "이거 바로 개발 가능하겠다" 싶을 때 문서로 정리해달라고 합니다. 그다음 이 기능을 개발하기 위한 세부 계획을 체크리스트로 만들어달라고 요청하고요. 저는 AI가 개발한 걸 체크리스트로 하나씩 확인하고 테스트하면서 기능을 완성시킵니다.
정리하면, 기획 회의 → 문서화 → 체크리스트 → 하나씩 개발 및 테스트. 이 흐름이 저한테는 제일 잘 맞더라고요.
네, 정말 강력하게 추천드립니다.
다만 한 가지 말씀드리고 싶은 게 있어요. 요즘 "바이브 코딩으로 앱 만들어서 월 얼마 벌었다" 같은 글들이 많이 보이잖아요. 근데 바이브 코딩의 목적이 "돈"이라면 좀 실망하실 수도 있어요. 물론 좋은 서비스를 만들면 수익이 따라올 수 있지만, 그게 전부는 아니거든요.
저는 바이브 코딩의 진짜 가치가 일상의 소소한 문제를 해결하는 데 있다고 생각해요. 예를 들어볼게요. 이메일을 100통 보내야 하는데, 각각 고객 이름을 다르게 넣어야 한다고 해봐요. 예전 같으면 100번 복사 붙여넣기 하거나, 엑셀로 참조 걸어서 보내겠죠. 근데 AI를 쓰면 이름만 바꾸는 게 아니라, 고객별로 개인화된 내용까지 넣은 이메일을 만들 수 있어요.
이런 식으로 자신의 일상 업무나 소소한 문제들을 해결해보는 즐거움을 느끼셨으면 좋겠습니다. 그게 바이브 코딩의 시작이에요.
솔직히 말씀드리면, 저도 주변 친구들한테 "AI 써봐", "바이브 코딩 해봐" 엄청 많이 얘기하거든요. 근데 실제로 해봤다는 사람은 별로 없어요. 제가 설득을 못 하는 건가 싶기도 하고요.
그래도 하나는 단언할 수 있어요. 내가 가진 소소한 문제든, 나 혼자 해결하기엔 커 보이는 문제든, 다른 사람한테 도와달라고 하기 애매한 그런 문제들 있잖아요. 바이브 코딩이 그걸 가장 가까이서, 생각보다 빨리 도와줄 수 있는 방법이에요.
요즘 "AI 때문에 대량 해고", "살아남으려면 배워야 한다" 이런 말들이 많은데, 그런 무거운 마음으로 시작하지 않으셨으면 좋겠어요. 어렸을 때 레고 하듯이, 가벼운 마음으로 한번 시도해보세요. 블록 하나씩 쌓아가면서 뭔가 완성되는 그 과정이, 진짜 어렸을 때 느꼈던 그 즐거움이랑 똑같습니다.
레고도 누구한테 배워서 하는 게 아니잖아요. 정답도 없고요. 만들어가는 과정을 즐기다 보면, 그때 "더 배우고 싶다"는 생각이 자연스럽게 드실 거예요. 그건 장담합니다.
사실 빌더톤 끝난 다음 날부터 새로운 아이디어가 떠올라서, 벌써 기획하고 야금야금 개발하고 있어요.
주변에서 커뮤니케이션을 잘한다고 말씀해주시는 분들이 많은데, 그래서인지 저는 계속 사람들 간의 협업을 돕는 서비스에 관심이 가더라고요. 예를 들면 디자이너와 개발자가 Figma랑 Slack으로 소통하는데, 이게 생각보다 쉽지 않거든요. 그 부분을 개선해보고 싶고요. 팀에서 Jira로 이슈 관리하는 것도 더 잘 활용할 수 있는 도구를 만들어보고 싶어요.
업무에 지장 가지 않는 선에서, 지속적으로 만들고 배포하고 홍보까지 해보는 게 목표입니다.
다른 AI 커뮤니티와 달리 bkamp는 바이브 코딩이라는 주제에 집중한 커뮤니티예요. 그게 가장 큰 차이점인 것 같아요.
이 커뮤니티의 장점은 정말 실력 있는 분들이 바이브 코딩 생태계를 확장시키려고 엄청 노력하신다는 거예요. 24시간 대기하시면서 꼭 봐야 하는 글들 공유해주시고, 어려움 겪는 분들 도와주시고요.
그리고 다른 사람들이 어떤 생각을 하고, 어떻게 문제를 해결해가는지 보는 것 자체가 자극이 돼요. 혼자 만들다 보면 시야가 좁아지기 쉬운데, bkamp에서 다른 분들 과정을 보면서 많이 배우고 있습니다.
인터뷰를 마치며
10년차 개발자가 "이제 안 쓸 이유가 없다"고 말하는 바이브 코딩. 핵심은 결국 '불가능이 가능으로 바뀌는 재미'였어요. 베테랑도 초보도 똑같이 느낄 수 있는 그 즐거움, 여러분도 한번 경험해보시길 바랍니다.
레고처럼, 가볍게 시작해보세요✊
댓글을 작성하려면 로그인이 필요합니다.