바이브 코딩의 50가지 그림자

그러니까 이건 지난 1년 동안 50개의 서비스를 만들면서, 바이브 코딩에 대해 배운 것에 대한 이야기다.

🗒️

서비스 50개를 만들어 본 이야기는 이전에 쓴 1년에 50개 서비스 만들기 를 참고해 주세요.

빛과 그림자

바이브 코딩에 대한 개발자들의 반응은 극단으로 갈린다. 나보다 더 개발을 잘하고, 내 동료보다 내 말을 더 잘 알아들으니 이제 딸깍 딸깍만 하고 더 이상 직접 손으로 개발 할 필요는 없다고 말하는 AI 낙관론자가 있다. 그리고 그 반대편에는 AI는 레거시가 될 코드를 뽑아내는 속도만 빠를 뿐 오히려 복잡성, 보안 문제 등 여러가지 문제를 더 키운다는 AI 비관론자가 있다.

나는 이 둘 사이에 진실이 있다고 생각한다. 그림자가 있는 것은 밝은 빛이 있기 때문이고, 반대로 밝은 빛이 있는 곳에는 강한 그림자가 생긴다. 그래서 이 글의 제목을 이렇게 만들었다. 바이브 코딩의 그림자, 즉 바이브 코딩이 해결해주지 못하는 것들을 말하면서, 다른 한편으로는 바이브 코딩이 해결해주는 것들을 말하기 위해서. 할 수 있는 것을 아는 것만큼, 할 수 없는 것을 아는 것도 중요하다.

50개를 만들면서, 50가지의 빛과 50가지의 그림자를 만나보았다. 이 글에서는 바이브 코딩을 좋아하는 사람들이 말하는 빛에 대한 이야기가 아닌, 그림자에 대한 이야기를 해보려고 한다.

사람들은 필경사들이 자취를 감추었듯, 인쇄기 또한 머지않아 사라질 운명이라 믿었다. 더 이상 찍어낼 성경도, 그것을 읽을 독자도 남아있지 않을 것이라 여겼기 때문이다. 하지만 그들은 결정적인 사실을 간과하고 있었다. 인쇄기는 단순히 수백 명의 필경사를 대체하는 효율성의 도구가 아니었다. 그것은 책을 '복제'하는 기계인 동시에, 인쇄기가 없던 시절에는 결코 존재할 수 없었던 새로운 종류의 책을 '탄생'시키는 기계였다. - <인쇄기의 역사>

Unknown Unknowns

요즘 계속 생각하는 단어 중에 Unknown Unknowns라는 개념이 있다. 모르는 것인데, 모른다는 것조차 모르는 일에 대해 말하는 용어이다. 모르지만, 모른다는 사람을 안다면 공부를 해서 모르는 점을 해결 할 수 있을테고, 존재를 모르지만 아는 것이라면 해당 문제가 갑자기 튀어 나왔을 때, 경험적 직관으로 해결 할 수 있다. 하지만, Unknown Unknowns(모르는 것을 모른다는 것)의 상태는 문제의 존재 자체를 모르기에, 문제가 발생했을 때 대처하기가 가장 어렵다.

지난 1년 동안 AI의 발전을 바라본 거의 모든 개발자들의 생각이 비슷할거라고 생각한다. AI가 너무 빠르게 좋아지기 때문에 모든게 처음 보는 상황이고, 내가 뭘 따라가야 할지조차 모르는 Unknown Unknowns 적인 상황에 있다는 걸.

Unknown Unknowns 문제를 줄일 수 있는 방법은 빠르게 탐색해서 하는 방법 밖에 없다. 걷는 방법에 대해 아무런 경험도 없는 아이가 걷는 법을 배우는 것처럼 빠른 시도와 반복을 통해서만, 한번도 안해본 모르는 문제를 해결 할 수 있다.

그래서 나도 최대한 많이 시도해 봤다. 그리고 몇가지 아는 것들이 생겼다. AI가 어떤 걸 잘하고, 어떤 걸 못하는지에 대해.

알았는데, 실제로 잘 하는 것들

Vibe Coding Subreddit이 있다. Vibe Coding으로 만든 서비스들이 가장 많이, 가장 활발하게 올라오는 곳이 여기 일 것이다. 다양한 서비스들이 올라오지만 단연 가장 많은 건 웹 서비스이다. 아무래도 가장 만들기도 쉽고, Playwright MCP나 Chrome DevTools MCP를 연결하면, AI가 직접 결과물을 보면서 바로 수정할 수 있는 것도 한몫 하는 것 같다. (여담으로 저기 sub-reddit에서 봤던 것 중 제일 재밌던 건 vibe calculator 였다. 해당 계산기 앱에 1 + 1 같은 걸 넣으면 3 같은게 나온다. Vibe 넘치게)

사실 AI가 뭘 잘 하는지는 내가 말하지 않아도 다들 알 것이다. 많이 보기도 했고, 그냥 생각해봐도 그럴거 같으니.

끝까지 저항하는(?) 최후의 개발자 후보 중 하나로 생각되던 리누스 토발즈도 장점을 깨닫고 Antigravity를 쓴다.

몰랐는데, 해보니 잘 하는 것들

해보기 전에는 생각하지 못했는데, 여러가지 해보고 나니 알게 된 것에 해당된다.

서비스를 만들 때 하면 좋지만, 우선순위가 항상 밀리는 종류의 기능들이 있다. Back office 기능이라고 말할 수 있는 dashboard, admin과 같은 기능들은 출시 후에 하자고 미루게 되고, 출시 후에도 유저가 쓰는 신규 기능에 우선 순위가 번번히 말리기 마련이다. 신기하게도 바이브 코딩을 하다보니, 나도 모르게 대부분의 서비스에서 dashboard와 admin을 같이 만들고 있는 것을 알게 되었다. 아무래도 Claude Code와 같은 Coding Agent로 개발을 하는 것은 양손으로 코딩을 하기보다는 한손으로 혹은 손가락 하나하나로 하는 개발에 가까웠고, 메인 개발이 아닌 다른 쪽 개발을 쓸 손 혹은 손가락의 여유가 항상 있었다.

연말에 Anthropic에서 발표한 글(원문, 긱뉴스 요약)에서도 비슷한 이야기를 했었다.

Claude 덕분에 전체 Claude 보조 업무의 27%가 원래는 하지 않았을 일로 채워지며, 프로토타이핑·대시보드·테스트·문서화 같은 ‘미뤄두던 일’까지 처리되는 양상이 보임

그런 관점에서 똑같이 귀찮은 작업들인 SEO 개선 작업과 데이터 사이언티스트 없는 상태에서 일단 GA 넣기 같은 작업들도 간단하게 시킬 수 있었고, 시키면 잘했다.

추가적으로 간단한 유틸리티 library 만드는 것도 엄청 잘한다. 1시간 만에 npm에 배포 할 v0.1.0 버전까지 만들어졌다. 1시간 만에 만든 library로 기존에 만든 프로젝트 5개를 이 library를 쓰도록 변경하게 AI에게 시켰고, 변경된 5개 모두 문제 없이 새로운 library가 잘 동작했다.

아직 만들어 본 샘플이 1개 밖에 안되지만, testcode를 만들기도 test를 하기도 쉬운 유틸리티 library 쪽이 AI를 이용해 레버리지 하기 좋은 쪽이라고 생각된다. Simon Willison이 올린 150개가 넘는 HTML tools도 이런 걸 AI가 잘한다는 것을 보여준다는 좋은 예가 아닐까 싶다.

이 강연에서 말하는 관점에서보면 더 맞는 말 같다. 복잡도로 인한 크기가 문제라면, 문제를 더 잘게 짤라서 더 많이 풀면 되니.

몰랐는데, 해보니 못 하는 것들

생애 처음으로 노래방 갔을 때를 기억 하는 사람이 많을 것이다. 자신있게 마이크를 들고 노래를 부른다. 그리고 곧 당황 했을 것이다. “내 목소리가 이랬다고???” 내 목소리처럼, 세상에서 나에 대해 제일 모르는 사람이 나인 경우가 종종 있다. 마찬가지로, AI가 제일 못하는 것은 본인을 인지하는 것이다.

Antigravity에 붙은 Gemini 3에게 AI 기능을 만들어 달라고 하면, 자꾸 Gemini 1.5를 붙여서 만든다. 마찬가지로 AI는 자꾸 최신이 아닌 본인이 학습 될 때 알고 있는 Model들을 이야기 한다. 생각해보면, 우리도 2025년이라고 실수로 말하는 경우가 종종 있는 것처럼, AI도 그럴만 하지만, 사람의 머리 속에는 이렇게 똑똑한 애가 본인도 모르고 1~2년 전 것을 자연스럽게 가져온다는게 이상하게 느껴지기만 한다.

인류의 99%는 색맹이라는 사실을 아는가? 인류의 1%는 사원색을 볼 수 있다. 그 사람들의 입장에서는 나머지 99%는 색맹이라고 말 할 수 있을 것이다. 마찬가지로 AI가 보는 시각이 우리랑 달라서 이상한 결과를 만나는 경우가 있다. 나에게는 Antigravity가 만들어 내는 투명 Modal이 그러했다.

브라우저에서 DOM을 직접 열어서 보는 Antigravity에게는 띄운 Modal의 배경이 투명이건, 색상으로 채워져 있건 같게 보였을 것이다. 그러나 실제 유저가 보는 입장에서는 이상했다.

해보고, 잘 시키는 방법을 찾은 것

적고 보니, 이제는 웬만하면 아는 내용이라 굳이 안보셔도 될거 같다.

Research 단계에서 잘못 넣거나 빠진 정보가 코드까지가면 엄청난 영향을 준다.

그러니까, 초기 단계에 시간을 더 많이 써야한다.

Source of Truth 보다는 문서끼리 상호 소통하고 업데이트 해야 하는 걸 받아들이자.

AI에게 일을 시키는 내가 항상 맞다. 그 말은 single source of truth는 결국 내가 될 수 밖에 없고 이걸 대신 해줄 AI는 없다.
README.md ↔ CLAUDE.md ↔ RESEARCH.md ↔ PLAN.md

Context Window는 100%가 찰 때부터 멍청해 지는게 아니라, 그 전부터 멍청해진다. 작업을 끊어서 할 수 있으면, 끊어서 할 수 있는게 더 좋다.

여러개의 UI 디자인을 만들어 달라고 해라.

디자이너들은 단 1개 시안만 생각하고 발전 시키지 않는다. 보통은 2~4개의 시간을 고민해온다.
마찬가지로 AI에게도 3개의 서비스 레퍼런스를 찾으라고 하고(이제는 모든 AI에 Web tool이 다 붙어 있으니), 레퍼런스를 기반으로 UI 시안 페이지 3개 만들어 달라고 해라.
그리고 이걸 기반으로 다시 3개 만들고 하기
미드저니가 성공한 것은 1개의 이미지가 아니라, 4개의 이미지를 만들어주고, 이걸 중 맘에 드는 것을 골라서 또 다른 4개의 발전된 이미지를 만들 수 있는 UX에 있었다

Test code 작성도 AI에게 위임하는 단계로 진입했다면, test code를 검증용이 아닌, 관찰용으로 사용해라.

Dashboard에 있는 그래프는 우리에게 문제를 알려주지 않는다. 변화만 알려줄뿐.
마찬가지로 AI가 작성한 test code를 검증용이 아닌, 변화의 유무를 확인하는 관찰용으로 사용하면 유용하다.

지금은 틀리지만, 다음은 맞을지도?

"어떤 뛰어난, 그러나 나이든 과학자가 무언가가 가능하다고 말했을 때, 그것은 거의 확실한 사실에 가깝다. 그러나 그가 무언가가 불가능하다고 말했을 경우, 그의 말은 높은 확률로 틀렸다." - 아서 C. 클라크(Arthur C. Clarke)

이번 달이 안 된다고, 다음 달에도 안 된다는 보장은 없다.
같은 PRD 문서를 넣어서 5월에 만든 것과 반년 뒤인 11월에 만든 것의 차이를 보면, 이 차이를 느낄 수 있다.

어떤 도구가 가장 좋은가?

Cursor, Claude Code, Codex, Antigravity, v0, Lovable, OpenCode 등등등 바이브 코딩 관련 서비스와 Tool들이 출시 되는 속도와 각각이 업데이트 되는 속도가 너무 빠르다. 흡사, 매주 신규 챔피언이 나오는 롤을 하는 것과 비슷한 느낌이다. 새로운 챔피언이 나왔다고 해서 그 챔피언의 Skill 설명을 읽고 연습게임을 좀 하다보면, 또 다른 챔피언이 나온다. 그리고 새로 나온 그 챔피언이 Game Changer, 즉 OP 챔이라고 한다. 나는 아직 지난 주에 나온 챔피언도 다 못 해봤는데 말이다.

새로운 AI가 출시 되는 속도보다, 내가 새로 출시된 AI를 익히는 속도가 더 느리다. 그러니 내가 새로운 AI와 Tool을 익히는 것이 Bottle Neck이 된다. 내가 Faker라면, 매번 새로운 것을 빠르게 익혀서 메타에 맞는 챔피언을 할 수 있지만, 그게 아니라면 하나의 챔피언만 계속 파는게 전략적으로 맞을 확률이 높다. 그리고 지난 1년 간 봐오던 것처럼, 몇달 지나면, Cursor나 Claude Code나 Codex나 Gemini나 그게 그거가 된다. 다 같이 지금보다 좋아질테니.

그러니, 쓰던거 쓰자.

Bottle-neck이 바뀌었다

바이브코딩을 하는 사람들이 말하는 것처럼 바이브 코딩을 통해서 AI를 통해서 코드를 만드는 속도가 10배 빨라졌다고 생각해보자. 그러면, 제품을 만드는 속도도 10배 빨라졌을까? 아직까지는 그렇지 않다. 왜냐하면, 코드가 SW 제품을 만드는 모든 일이 아니기 때문이다.

개발만 효율성이 많이 개선되었다. 그러다보니, 오히려 예전에는 개발에 비해 작아 보였던 것들이 지금은 더 커보인다.

기존에 있던 SW 개발이라는 병목 지점이 사라졌다. 그러면, 병목 자체가 없어졌을까? 그럴리 없다. 병목 지점이란, 전체 공정에서 처리 용량이 가장 낮은 구간을 뜻하기 때문에, 그 구간이 사라지면 그 다음 처리 용량이 낮은 구간이 새로운 병목이 된다.

우리의 Andrew Ng 교수님도 최근에 찍은 CS 230 수업에서 같은 이야기를 했다.

Reverse Sprint

1년 전, 집에서 구글 디자인 스프린트를 진행하면서, 앞으로도 이 방법이 최선일까? 라는 생각을 한적이 있다. 디자인 씽킹(Design Thinking) 프로세스도, 구글 디자인 스프린트 프로세스도, 앞단이라고 할 수 있는 User Research와 제품 탐색에 시간을 많이 쓰는데, 그러는 가장 큰 이유는 Software Product를 만드는데 시간과 노력이 많이 필요하기 때문이다.

제품을 다 만들고 출시하고 나서, ‘고객이 원하던게, 이게 아닌가벼…’ 하기엔 리스크가 너무 크기에, 최대한 앞단에서 그런 실수를 줄이고, 뒤에서 배울 교훈을 최대한 앞에서 배우려고 노력한다. 그렇기에 이 프로세스에서 끝단은 Product 또는 MVP가 아니라, Prototype이 된다. 빠르게 시도하고 배운다. 그러려면, 최대한 빨리 여러번 만들어 볼 수 있는 Prototype이 가장 적절한 목표가 된다.

그러나 이제는 Prototype을 30분이면 만들 수 있다. 심지어 Prompt에 PRD 내용을 잘 정리해서 넣는다면, Prompt 한번으로도 만들어 낼 수도 있다. 이 말은 뒷단이라고 할 수 있는 Prototype에 걸리는 시간이 엄청나게 줄었고, 더 나아가 MVP까지 만드는데 걸리는 시간도 줄었을 거라는 뜻이다. 예전에는 그럭저럭 작동하는 Prototype을 만드는데 하루나 걸렸기에, 구글 디자인 스프린트에서는 앞단에 3일의 탐색 기간을 두었다.

이제는 Prototype을 만드는데 30분도 안 걸리는데, 30분짜리를 잘 만들기 위해 3일을 탐색 기간으로 쓰는게 맞을까? 시간 배분이 너무 비대칭적이어서 오히려 이상한 프로세스가 된다. 30분짜리 작업의 정확성을 위해, 3일을 투자하는 꼴이 되니.

최근에 본 유튜브에서도 같은 이야기를 하길래 살짝 놀랐다. Figma에서 Director of Design을 했었고, 현재는 Anthropic의 Design Lead을 맡고 있는 Jenny Wen은 “Don’t Trust the Process”라고 말한다. 환경이 바뀌었으니 기존의 디자인 프로세스를 믿지 말고 다시 개편해야 한다고.

그러면서 발표 자료에서 아래 2개의 이미지를 보여줬다.

2025년이 개발자들에게 직접적인 영향을 준 한해였다면, 2026년은 그 영향이 개발자와 함께 일하는 다른 구성원들에게도 영향과 변화를 가져다 주는 한해가 될지도 모르겠다. 그리고 이 변화에 적응한 회사와 그렇지 않은 회사가 밖에서 볼 때도 확연하게 구분되는 해가 될지도.

10 → 1 혹은 0 → 1

처음에는 10시간 걸리던 일이 1시간으로 줄어들어서 좋았다. 그런데 요즘 느끼는 건, 전혀 할 수 없던 일을 하게 해주는 것, 그러니까 0 이던 일을 1로 만들게 도와주는 것에 좀 더 큰 가치가 있다는 생각이 든다. 그 말을 다시 하자면, 0 → 1로 만들어 줄 수 있는 사람들을 찾고 가치를 창출해주는 일이 더 많은 기회가 있는 일이 될 수 있다는 것이다. 미드저니와 DALL-E를 기존에 그림을 직접 그려서 만들 수 있던 사람들보다 그걸 못하던 일반인들이 더 좋아하고 많이 쓰게 되었던 것처럼.

사람, 연결, 사람

2025년 올해의 컨텐츠 부문에 노미네이트 되신 노정석님 유튜브를 듣다가, 결국 연말에 하는 AI Frontier 모임까지 가게 되었다. (참고로 1등은 Andrew Ng 교수님의 2025 CS 230 강의입니다)

100명이 넘는 사람들이 모인 모임이 이렇게 원활하게 운영되는 것도 신기했지만, 다른 한편으로는 AI 세상이 될거라고 믿는 사람들이 이렇게 오프라인으로 모여서 사람들과 이야기하고 싶어한다는 사실이 가장 신기했다(나도 그러고 싶어하던 1인이기도 했지만). 노정석님 유튜브에서 하는 AI 시대에 우리는 어디로 갈까?라는 질문에 공감해서 오신 분들이었지만, 반대로 “누구와 함께 갈까?”라는 숨겨진 질문도 보였다고 할까?

어찌보면, ChatGPT에게 물어보고, 좀 더 자세히 알고 싶으면 Deep Research 쓰거나, NotebookLM에 수십, 수백개의 참고자료를 넣어놓고 질문하면 될거 같지만, 그래도 AI가 채우지 못하는 것은 결국 사람이 아닐까 싶다. 어디에도 있다는 것은 반대로 말하면 어디에도 없다고 말할 수도 있을 것이다. 그렇기에 이 순간 온전히 나와 같은 공간과 같은 시간을 공유하는 사람이 더 소중한 세상이 된 것 일지도, 그리고 그렇게 될지도.

히든 피겨스

1960년대 초 NASA에 근무하는 3명의 흑인 여성에 대한 이야기 다룬 영화인 히든 피겨스를 보다가 살짝 눈물을 흘린 부분이 있다. 내가 감정이입이 많이 되었던 곳은 계산팀의 리더인 ‘도로시 본’이 나사에 IBM 컴퓨터가 도입된다는 소식을 듣고, 그 뒤에 벌어지는 이야기였다.

계산팀의 역할은 수학적 계산을 대신 해주는 일이었다. 나사에서는 IBM 컴퓨터 도입을 앞두고 있었고, 컴퓨터가 도입되면, 계산팀의 작업은 100% 컴퓨터로 대체 되기에 계산팀은 모두 백수가 되는 운명이었다. 마치 우리가 걱정하는 미래의 AI로 대체되는 개발자의 모습처럼.

2025년의 변화를 좋아하면서도, 다른 한편으로는 당황하던 우리의 모습이 많이 겹쳐 보였다. AI로 인해서 코딩이 훨씬 편해지고 좋아지긴 했는데, 이러다가 일자리도 줄고 다가올 내일엔 내 일도 사라지지 않을까? 하는 걱정 말이다. 이런 변화에 우리는 어떻게 대처해야 할까?

영화로 다시 돌아가보자. 도로시는 NASA에 설치되기 시작한 IBM 컴퓨터를 관찰한다. 그리곤 컴퓨터를 사용하기 위해서는 기존에 계산팀에서 쓰던 손으로 계산을 하는 방식이 아닌, 새로운 도구를 이용하는 방법부터 배워야 한다는 것을 깨닫는다. 그리고 그 방법에 대해 공부를 한다. 모든 계산팀 팀원들과 함께.

그 방법이라는게 사실 바로 지금의 우리가 하는 일, 바로 프로그래머가 되는 일이었다. IBM 컴퓨터와 포트란에 대해 미리 공부를 했기 때문에, IBM 컴퓨터가 설치되고 운용되기 시작 했을 때, 다른 NASA 직원들과 IBM 직원들도 쩔쩔매던 시스템을 능숙히 다룬다. 또한 계산팀 팀원들 다 같이 함께 프로그래밍과 펀치카드 작성 등에 대한 스터디를 해놨기에, 결국 전원 해고 위기 였던 계산팀을 IBM 컴퓨터를 다루는 프로그래머로의 전환을 이끌어 낸다.

영화적으로 각색된 장면일 수는 있지만, 단순히 “이게 우리의 일자리를 없애고 다 백수로 만들 것이다”라는 식으로 대응하지 않고, 새로운 변화에 대응하는 모습이어서 좋았다. 그리고 그게 우리의 앞선 선배들의 모습이라서, 그리고 주인공 혼자가 아닌, 팀원들 모두가 함께 하는 모습이라 더더욱 좋았기에, 살짝 눈물이 났었다.

몇년 전, 아는 지인이 나에게 이런 질문을 던진 적이 있다. AI를 만드는데, 나중에 AI가 직업을 없애는 것에 대해 무섭지 않냐고.

그 때 나는 이렇게 말을 했었다.

AI가 발전해서 새로운 것을 할 수 있는게 재미있어요. 그리고 만약에 AI가 개발자라는 제 직업을 없어지게 할 정도라면, 다른 직업들도 다 없어져서 큰 상관 없지 않을까요? 모두 직업이 없는 상태일테니. 어떻게든 정부나 사회에서 대책이 나왔겠죠.

내 예언은 50%만 맞았다. 예언의 순서가 바뀐게 문제지만.

결국 해결책은 사람이라고 본다. 새로운 AI 도구의 Bottle-neck이 나였듯이, 반대로 나를 극복할 해결책은 다른 사람들과 함께 하는 것 뿐이라고 생각한다. AI Frontier 모임이 그랬듯이, 히든 피겨스의 주인공들이 그랬듯이, 그리고 올해의 나의 유튜브 Andrew Ng 교수님이 강의에서 말했듯, 함께 하는 사람들이 가장 중요하다.

내가 한국어 네이티브인 이유는 언어 능력이 뛰어나서도, 국어시간에 더 열심히 공부해서도, 아닌 단순히 내 주위가 한국인들로 가득 차있다는 환경 단 하나 뿐이었던 것처럼. 바이브 코더, 아니 더 나아가 AI Native Engineer가 되기 위해선, 나와 같이 손을 모으고 있는 사람들을 AI Native Engineer로 변하려는 사람들로 채우는 방법 뿐일 것이다.

📢

그런 의미에서 비슷한 사람들을 찾고 계시다면, 제가 작년부터 운영 중인 바이브 비스타 코딩 클럽이라는 디스코드 모임(링크)에 와보셔도 좋습니다. 모임은 매일 저녁 10시에 디스코드에서 진행됩니다.

ps. 글 중간에 인용된 <인쇄기의 역사>는 존재 하지 않는 책이고, 문장도 제가 만들어 낸 문장 입니다. 인용을 통해 말하고 싶었는데, 원하는 문장을 못 찾아서 GenAI스럽게, 스스로 생성 했습니다.