요즘 바이브 코딩이 핫합니다.
바이브 코딩에 다양한 의견과 경험담들이 있지만, 제 직접적인 경험을 실제 사례를 들어 여러분과 나누고자 글을 써봅니다.
"바이브 코딩"이라고 불리기 위한 코딩 규칙이 있는지는 모르겠으나, 저는 제가 할 수 있는 한 AI의 도움을 많이 받으면서 개발한 경험을 "바이브 코딩"이라고 정의하겠습니다. 저는 이번에 모바일 어플리케이션 서비스 (백엔드, 프론트엔드 전체)를 직접 1인 개발했습니다. 그 과정에서 기존에 제가 10여년간 하던 코딩 방식과 전혀 다른 경험, 그리고 그 경험이 발전하는 과정을 매주 목격하고 있습니다.
거슬러 올라가면, 작년 초 쯤 github에서 제공하는 copilot을 경험하고 깜짝 놀랐습니다. 한줄씩, 몇줄씩이라도 코드가 자동 완성되는 것이 너무 신기했습니다. 업무 능력 향상에도 꽤 도움이 많이 됐습니다. 회사에서는 관심이 없었지만, 저는 곧바로 연간 구독하고 AI를 제 업무 공간으로 불렀습니다. (작은 회사라 대표님 허락은 받고 했습니다)
그리고 시간이 흘러 세간에 cursor ai, windsurf, claude code 같은 도구들이 주목받기 시작했고, 저는 바로 업계 1위인 cursor ai의 유료 버전에 가입했습니다. 그게 올해 2월쯤입니다. 그 전까지는 브라우저 즐겨찾기에 chatgpt, claude, perplexity, grok, gemini를 넣어두고 코딩 관련 질문을 한 후, 복사 붙여넣기 하는 방식으로 도움을 받았습니다. 그 마저도 깃허브와 스택오버플로를 헤메는 시간을 획기적으로 줄여주어 너무 고마웠습니다. 무료 사용량이 다 차면 다음 서비스로 옮기는 식으로 체리피킹을 했었더랬죠. 저는 cursor만 써보았기 때문에 요즘 핫한 다른 cli 도구들이 있지만, 제가 경험한 cursor만 주로 다루겠습니다.
어쨌든 cursor ide(코드 편집 프로그램)를 설치했고, 열었습니다. vscode에서 분기한거라 개발 환경은 이질감이 없었습니다. 그 당시 cursor에는 다른 서비스에는 없던(지금은 다 따라한) composer라고 불리는 ai agent가 있었습니다. 그냥 답변만 하는게 아니라 아예 코드 블럭을 찾아서 수정하거나, 필요하면 파일을 생성하거나 삭제까지 하는 녀석이었습니다. 이 기능이 "바이브 코딩"의 포문을 열었다 생각합니다. 찾고, 검증하고, 복사하고, 붙여넣고, 테스트하는 일련의 작업이 "해줘" 한마디에 동작했거든요. 이게 와우 포인트였기 때문에 아마 유튜브를 보면 "~해줘"라고 말하니, "되더라!"는 형식의 내용을 많이 찾아보실 수 있을겁니다.
여기까지만 읽으시고 나가신다면 이 글에서 얻어가실게 없을겁니다. 하지만 진짜 내용은 이제 시작입니다.
곧 cursor의 composer 기능은 agent라는 이름이되었습니다. 그리고 thinking 모델의 출현으로 그 성능이 더 높아지게 됩니다. 하지만 여기서 중요한 것은 이것이 단순 재미를 넘어서서 "프로덕션 레벨"까지 도달하는 여정이 가능하느냐 입니다.
결과적으로 저는 "아보행 (아주 보통의 행복)"이라는 iOS, 안드로이드 모바일 어플리케이션을 개발 시작 후 약 40일만에 출시했습니다. 서비스는 flutter(dart) + pocketbase(go) 기반인데, dart, go 둘다 문법도 여전히 서툴지만, 개발하는데 문제 되지 않았습니다.
바이브 코딩에 대한 의견이 갈리는 근본적인 이유는 저는 하나라고 봅니다. "너무 쉬워서".
처음 경험한 바이브 코딩이 너무 쉽다보니, 그리고 잘 되다보니, 작업자가 AI가 완성한 코드를 점점 안읽게 됩니다. 게을러지고 그냥 믿어버리게 됩니다. 여기서부터 여러 문제가 발생합니다. 검증없이 반복 사용하다보면 코드 품질이 점차 나빠지고, 관리가 오히려 어려워집니다. 이것을 경계하는 사람들이 "주니어는 하지마라", "시니어를 위한 도구"라는 이야기들을 하게 되는 것 같습니다.
서비스가 조금만 복잡해지면, 자연어만 사용하는 바이브 코딩으로는 프로덕션까지 갈 수 없습니다. 저는 아예, 자연어로만 사용하는 바이브 코딩은 당분간 "재미"의 영역을 넘을 수 없을거라 생각합니다. 그렇다면, 이제 프로덕션까지 가기 위해 제가 했던 방법들을 소개하겠습니다.
cursor에서 AI에게 특정 업무를 시키면 최대 5분~10분까지 걸리는 경우도 있습니다. 그러다보니 브라우저처럼 ai agent의 탭이 나뉘게 되고, 1번 탭에서 AI가 한 업무를 수행하는 동안 2번 탭에서 다른 업무를 맡기기 위한 프롬프트를 입력하고 있는 경우가 많아지게 됩니다. 어느새 저는 코드 레벨에서 붙어있기 보다는 작업단위를 생각하게 되고, PM처럼 일을 시키는 사람이 됩니다.
혹자는 "AI는 모든 사람이 5명의 인턴을 거느린 것과 같다"라고 말합니다. 인턴으로 실무자는 마련했으니, 이제 어떻게 일을 시키느냐가 중요해집니다. 유능한 PM이 필요한 시점입니다. 이 때가 되면 앵무새처럼 "해줘"하는 프롬프트는 힘을 잃습니다. 특히 코드가 길어지고, 파일 디렉토리가 세분화되면, 작업자는 프로젝트의 구조를 정확히 인지하고 있어야합니다. AI는 매번 호출될 때마다 프로젝트의 컨텍스트를 새로 인지해야하기 때문에, 잘못하면 똑같은 기능을 하는 코드를 중복 생산하거나 엉뚱한 작업을 하게 되기 마련입니다.
이 시점이 되면 상당수의 개발자에게 더 이상 바이브 코딩이 "너무 쉽다"고 할 수 없게 됩니다. 이제 코드는 작성하는게 아니라 읽는 것이 되었습니다. 5명의 똑똑한 인턴이 나의 업무 지시만을 똘망똘망 기다리고 있습니다. 같은 1시간이라도, 기존보다 훨씬 많은 업무를 할 수 있게 됩니다. 실제 인턴이었다면 "내일까지 드리겠습니다" 했겠지만, 이놈들은 5분만에 결과물을 내놓습니다. 이제 나의 업무 지시 속도가 병목이 되었습니다. AI에게 업무를 지시하는 나의 업무 시간이 늘어납니다. 전체 업무량은 어마무시하게 늘어납니다. (누군가는 해고되겠죠.. 또르르...)
어쨌든, 훌륭한 AI 업무 지시자가 되기 위해서는 두 가지 방법을 써야합니다.
- 세심한 작업 지시
- 효과적인 컨텍스트 제공
먼저 "세심한 작업 지시"는 명백합니다. 간단하게는 어떤 파일을 수정할지, 어떤 메소드를 이용할지 제공하는 것부터, 어떤 방법으로 작업하라는 지시까지 해주어야합니다. 그래야 갑자기 "아하, 좋은 방법이 있는데 이걸로 해볼ㅇ르.ㄴ르..... 몰겠음" 하는 경우가 사라집니다. AI 답변이 "몰겠음"으로 끝나면 그나마 다행인데, 망쳐놓고도 "완벽합니다!"로 답변하면 피곤해집니다. 작업 지시가 잘 되면 AI가 계획을 짜서 하나씩 실행합니다. 보통 이렇게 진행되면 문제가 잘 없습니다.
두번째는 "효과적인 컨텍스트 제공"입니다. AI와 함께 작업하다보면 매번 똑같은 말을 해야할 때가 있습니다. 예를들어, claude 4.0 sonnet은 flutter에서 이미 deprecated(쓰지않아야 할) color.withOpacity() 메소드를 자꾸 씁니다. 옛날 버전의 코드로 학습했기 때문이겠죠. 이게 계속 warning을 띄우기 때문에 컬러를 다룰 때는 color.withValue()로 쓰라고 매번 말해줘야합니다. 이게 귀찮기 때문에 프롬프트에 자동으로 끼워넣는 것. 이걸 rules라고 합니다.
보통은 별도의 문서를 AI에게 제공하는 방법을 이용합니다. cursor의 경우 cursor rules를 사용하고, windsurf나 claude같은 경우에도 rules를 파일로 만들어 제공합니다. 여기에는 프로젝트의 구조, 코드 컨벤션 등 서로 다른 AI 모델이 독립적으로 구동할 때에도 어느정도 일관성 있는 코드를 만들도록 기여합니다. 다양한 종류의 rules를 만들 수 있는데, cursor의 경우 이 문서도 AI에게 만들어라고 합니다. ("현재 프로젝트 구조를 분석하고 일관성 있는 코드를 생산하기 위한 rules를 만들어줘"). 모든 rules를 항상 agent에 입력하면 토큰 낭비가 심합니다. cursor에서는 rule 마다 요약을 넣어놓고, 이번 agent 요청에 이 rule이 필요한지 여부도 ai가 결정하도록 하고 있습니다.
필요할때마다 rules를 잘 관리하는 것이 중요합니다. 저같은 1인 개발자도 그렇지만, 팀이 함께 바이브 코딩을 한다면 더욱 중요하겠죠. API나 DB의 스키마가 바뀌었을 때 매번 꼭 동기화해주어야합니다.
그리고, 대부분의 사람들이 바이브 코딩에서 별로 중요하게 생각하지 않는 부분인데, 생각보다 주석이 꽤 중요합니다.
cursor를 비롯한 ide형 AI 코딩 서비스에서는 특정 코드 블럭을 찾기 위해 코드를 임베딩으로 만들어서 인덱싱해놓습니다. 그리고 다음과 같이 일반적인 query로 검색합니다. 높은 확률로 코드에서 주석을 제거하지 않고 임베딩으로 만듭니다. 따라서 여러번의 AI 수정으로 인해 실제 코드와 주석에 차이가 발생하면 search 품질이 떨어질 수 있습니다. 틀린 주석이 있다면 넘어가지말고 수정해줘야합니다.
마지막으로, 프론트엔드를 바이브 코딩으로 처음 개발하는 분들에게 도움이 되는 꿀팁입니다. 저도 superdesign이라는 extension을 만든 개발자의 유튜브를 보고 처음 알게된건데, ascii 와이어 프레이밍을 통해 디자인 품질을 높일 수 있다는 것입니다. 디자인에서는 AI와 텍스트로 소통하는 것이 불편할 수 밖에 없습니다. 하지만 먼저 ascii wireframe을 요청한 후, 서로 UI를 인지한 상태에서는 수정이 편리합니다.
업무 지시 속도가 느려서 AI가 대기하고 있는 것을 못참는 저로서는 정말 열심히 썼습니다. 그 사이 cursor의 요금 체계가 잠시 무제한으로 바뀌면서 제게 cursor가 "너 임마, 20달러 플랜으로 290달러치 썼다 야! 적당히 좀 해" 한 적도 있었고, usage based pricing을 켜놨더니 이틀만에 50달러가 나와서 황급히 옵션을 껐던 적도 있었습니다. 지금은 카탈로그에는 없는 60달러짜리 pro+를 사용하고 있습니다. 각 회사의 프론티어 thinking 모델을 쓰지 않으면 코드 품질이 떨어지기 때문에 여러 AI 모델들을 돌아가며 사용하다가, 지금은 비용이 제일 저렴하고, 결과가 안정적인 gemini 2.5 pro를 주로 사용하고 있습니다. 잘 안되면 claude 4.0 sonnet을 쓰고요.
결국 AI 모델들은 더 발전할테고, 가격은 저렴해질겁니다. 이상, AGI가 나와서 우리 모두 노동하지 않아도 되는 세상이 오기 전까지, 지식 산업 혁명의 시기에 뭐라도 한번 해봐야하지 않겠나 싶어 발 동동 구르고 있는 한 가정의 가장이자, 예쁜 3살 딸아이의 아빠였습니다. 작성하면서 보니, 지난 한달동안 AI와 함께 15만줄의 코드를 작성했네요.. 하핳 우리 모두 화이팅입니다!
아 참, 위의 방법을 총동원해서 열심히 바이브 코딩을 한 결과를 여러분께 소개드리고 물러가고자 합니다.
사실 어제 자료실 게시판에 올렸었는데, 수익화가 된 앱이라서 관리자 삭제당하고 말았네요 ㅠㅠ
양질의 바이브 코딩 후기 컨텐츠를 만들고 크레딧에 홍보를 끼우면.. 봐주시지 않을까 싶어서 다시 작성해봅니다.
https://abohaeng.stella-dev.org/
아주 보통의 하루, "아보행" 어플리케이션을 직접 개발했습니다. iOS, 안드로이드 모두 출시했습니다!
소소한 일상과 일기를 기록하면 다양한 AI 캐릭터의 따뜻하고 개성있는 댓글을 받아 볼 수 있는 폐쇄형 SNS입니다. 가끔은 AI에 의해 나와 연관이 있는 기록에 연결되어 그 기록으로부터 위로를 받거나, 내가 다른 사람에게 위로가 되어줄 수도 있습니다!
주 기능은 다음과 같습니다.
- 쉬운 일상 기록 : 내용과 사진만 정하세요. 나머지 제목, 태그, 이모지는 모두 AI가 정해줍니다. 글 쓰기가 귀찮으세요? 그럼 말로 하셔요! 알아서 내용을 정리해드릴게요!
- 따뜻한 공감 댓글 : 수십가지 다양한 캐릭터가 따뜻한 공감과 위로가 되는 개성있는 댓글을 달아줍니다.
- 다른 일상으로부터 : 나와 비슷한 경험을 한 다른 일상으로 연결되어, 다른 이의 일상으로부터 위로를 받으세요. 또, 원한다면 나의 댓글로 그에게도 위로가 되어주세요!
---
저는 10년 전부터 인스타그램, 페이스북, X(트위터) 같은 기존 SNS를 하지 않습니다.
기록 자체에 대해 집중하기 보다는, '얼마만큼 전파되었는지', '얼마만큼 좋아요가 눌렸는지', '얼마만큼 댓글이 달렸는지'에 집중하게 되더라고요. 피로하게 느껴졌습니다.
그래서 소모적인, 뾰족한 도파민이 아니라, 둥글둥글, 부드러운 재미를 가진, 기록에 집중한 SNS를 만들어야겠다 생각했습니다. 그래도 기록에 아무 반응이 없으면 심심하니 다양한 캐릭터가 원하는 만큼 댓글을 달아주도록 했어요.
클리앙에 자신있게 올리는 이유는 40대, 50대, 60대 형님 누님들이 좋은 경험을 하는 것에 집중하며 개발했기 때문입니다. 음성을 녹음하면 내용을 정리해주는 기능이나, 시력이 예전 같지 않아도 글자 크기 설정 기능을 통해 편안한 UX를 전달하려 노력했습니다. 기록 습관 형성을 위해 사용자별 기록 패턴을 분석하여 스마트 리마인더도 드립니다.
피로한 생활에 활력이 될 수 있게끔 부드러운 즐거움을 담았습니다. 물론 과도한 도파민에 대한 노출이 우려되는 10대 친구들에게도 분명 긍정적인 경험을 줄겁니다!
---
나의 순간 순간을 간단히 기록하고 관리해보세요!
기쁨은 나누면 두배가 됩니다.
언제나 나의 편이 되어주는 친구가 되겠습니다.
많은 관심과 사랑 부탁드립니다!!
https://abohaeng.stella-dev.org/
끝까지 읽어주셔서 감사합니다.
바이브 코딩과 함께 만들어보고 싶었던 무언가에 보다 쉽게 다가갈 수 있게 되길 응원합니다.
/Vollago
1. 무료 계정 - 홈화면의 기록 5개마다 네이티브 광고 배너 노출, 잔여 크레딧 부족 시, 전면 광고 시청 후 크레딧 보상 가능
2. 구독제 - 광고 제거, 매월 크레딧 제공 (30일 유효)
3. 크레딧 번들 구매 (1년 유효)
저도 요즘 바이브 코딩 해보려고 하는 중이라
재미있게 잘 읽었습니다 ^^
AI코딩을 신뢰하게 되서 코드를 잘 안보게 된다는 말에 공감이 됩니다.
프론트는 AI 도움을 좀 많이 받지만, 백엔드는 비즈니스 로직에 크리티컬 섹션까지 다뤄야해서 AI가 추천해주더라도 꼼꼼히 보게 되더라구요.
AI랑 일하면서 생산성이 좋아지신 분들도 있겠지만 저 같은 경우엔 생산성이 더 떨어졌습니다...
그럼에도 쓰는 이유는 조금씩 업그레이드 되는 AI를 체험하기 위함이기도 하고요.
무엇보다 이슈트래커와 MCP랑 연결해서 쓰는데 간단하게 이슈를 올려달라고 하면,
개발계획까지 꼼꼼히 작성해주고 그에 어떤 개발을 해야하는지 방향까지 정해주니 온전히 코딩에만 집중할 수 있게 해줘서 이걸 끊을래야 끊을 수가 없더라고요.
저 궁금한게 하나 있는데, 서비스에서 ai가 댓글다는건 api이용하시는건가요. 이거 사용자가 많아지면 api 과금이 계속 생길텐데 금액이 크지는 않으려나요?
바이브 코딩에 너무 맛을 들여버려서 예전처럼 한줄한줄 생각하면서 코딩하기는 점점 힘들어질것 같습니다.
없으면 일 못하죠.. 시니어에게 정말 좋은 것 하나는 언어 간 문법 장벽을 자연스럽게 없애 준 게 너무 좋아요.
C++ 15년 하다가, 자바/파이썬으로 넘어 왔는데. 코파일럿 없으면.. 넘어 갈 때 진짜 힘들 거 같아요.
UI를 시각적으로 보여주니, 커서에게 수정 요청하기 좋을거 같습니다.
너무 감사합니다.
(마케팅이 제일 어렵습니다...)
프롬프트 날리면 기획 -> 설계 -> Task 까지 이전 툴들보다 훨씬 자세하게 남겨주고 Task 별로 실행하고 나면 결과까지 모두 문서화 해줍니다. 테스트 코드까지 작성해주고 Task에 통합 테스트코드해서 문제해결해줍니다.
게다가 다국어 뿐만 아니라 스토어에 배포할 문구들까지 다국어로 모두 문서화 해줍니다.
그리고 서버 셋팅부터 배포할때 커멘드들 하고 주의사항 같은 부분들도 문서화해서 남겨주네요.
다만 지금 사용자가 많아서 그런지 중간에 실패하고 retry 하라고 뜨네요. 빨리 유료결제 가능하도록하고 잘 돌아가게 해주면 좋겠습니다.
다음 프로젝트에서는 kiro도 한번 확인해보겠습니다.
아보행 ~ 어감이 좋네요 ^^
ISO42001 인데 뭐 이걸 회사 규모가 큰게 아니라면 바로 접목하는건 어렵겠지만 한번 읽어보시고 이런 부분을 점검하면 좀 낫겠구나 싶습니다.
1. 서비스의 디자인은 직접 구현하신건가요? 아니면, 이것도 AI의 도움을 받으셨을까요?
2. 디자인을 구상하신다음 그걸 ASCII로 변환하셔서 만들어달라고 하신걸까요?
3. 배포는 어떻게 하셨나요? (웹 모바일 서버) 그 과정에서도 혹시 AI의 도움을 받으셨는지 궁금합니다!
1. 서비스 디자인은 아무래도 제가 손으로 그려서 와이어 프레이밍은 했었습니다. 대략적으로 머리속에 디자인을 해놓고, 이걸 AI로 뼈대를 구현하고, 디테일은 직접 코드를 만져서 완성했습니다.
2. AI로 디자인 뼈대를 만들 때 ascii 와이어 프레이밍이 아주 좋은 방법론이었습니다.
3. 배포는... 처음이라 손으로 했습니다. 그렇게 많은 배포를 필요로할지 몰라서 자동화를 안했고, 지금도 play console이나 apple connect로 배포하는게 크게 불편함은 없습니다. 추후에 좀 더 커지면.. 고려해봐야겠습니다. 아마 그것도 AI의 도움을 많이 받으면서 github action같은걸 이용하게되지 않을까 싶습니다.
AI가 댓글을.달아주면
토큰 비용이.많이 발생하지는.않나요?
물론 수익이 훨씬크면 상관 없을것 같긴.합니다
windows95와 아이폰의 등장이 그랬습니다.
초고속인터넷의 등장으로 누구나 홈페이지 하나쯤 만들어서 갖고 있던 시절이 있었듯이 누구나 자기 이름으로 앱 하나쯤은 출시할 수 있는 날이 올 것 같습니다.
또는 sns처럼 앱 플랫폼이 나와서 플랫폼안에서 서로의 앱을 사용하는 생태계가 만들어 질 수도 있을 것 같습니다.
잘하시는게 그저 부럽습니다
"톺아보기" 기능을 업데이트 할 예정입니다. 기록에 대한 통계와 인사이트를 제공해서 댓글도 댓글이지만, 기록하는 재미에 더 집중하는게 좋겠어요.
그러면 빌드는 앱 다 만들고 마지막에만 해주면 되는것 인가요??