vibe coding의 이상한 편안함 (그리고 역효과가 날 때)
I’m sorry, but I can’t retrieve the content from the linked article. If you paste the text you’d like translated here, I’ll be happy to translate it into Korean while preserving the formatting and keeping the source link unchanged.
Source: …
Vibe 코딩의 탄생
우리는 이제 이 개념을 다들 알고 있을 테지만, 앞으로도 같은 페이지에 있기 위해 기본 규칙을 정해두겠습니다:
“Vibe coding” 은 Andrey Karpathy 가 만든 용어로, LLM을 이용해 소프트웨어(랜딩 페이지, 웹 앱, 모바일 앱 등)를 전 과정에 걸쳐 AI만으로 만드는 현상을 설명합니다. 원하는 결과를 설명하고 나면, 마치 생명이 달려 있는 듯
Accept버튼만 계속 눌러갑니다.
버그가 생기면 그 내용을 다시 LLM에 붙여넣어 고치게 하죠. 만족스러운 결과가 나올 때까지 반복합니다… 혹은 정말 그렇게 될까요?
기본부터 시작하기
돋보기를 들고 내부에서 (대략) 무슨 일이 일어나고 있는지 살펴보면, 확률과 통계가 핵심이라는 것을 금방 알 수 있습니다. LLM에 질문을 던지면 돌아오는 것은 교육받은 추측—하지만 여전히 추측입니다.
- 모델은 (보통 방대한) 데이터 코퍼스에 사전 학습(pre‑trained) 되어 있습니다.
- 토큰 단위로 가장 가능성이 높은 응답을 예측(predict) 합니다.
근본적인 문제는 같은 프롬프트에 대해 다섯 가지 다른 응답이 나올 수 있다는 점입니다. 맞춤법 오류 같은 사소한 디테일도 출력에 영향을 미칠 수 있습니다.
이게 나쁜가요? 아니요, 그렇지 않습니다.
문제인 것은 이 반‑무작위성을 존재하지 않는 것처럼 여기거나, 중요하지 않다고 행동하는 것입니다.
그렇다면 이 불확실성을 어떻게 다루나요? 흔히 하는 답은: “스킬 문제.”
같은 출력, 다른 관점
이러한 내재된 무작위성 속에서 품질을 어떻게 보장할 수 있을까요?
프롬프트 작성은 스킬 문제입니다. 혼란스러운 결과가 나온다면, 더 좋은 프롬프트를 만들어야 합니다. 입력이 엉망이면 출력도 엉망이죠. 당연한 얘기입니다.
그렇다고 가정하고 논의를 한 단계 더 진행해 보겠습니다.
- 완벽한 프롬프트를 만들었습니다.
- 다섯 개의 서로 다른 LLM에 검토와 개선을 요청했습니다.
- 이제 그 프롬프트를 Claude Code에 넣을 준비가 되었습니다.
질문: 결과가 정상인지 어떻게 알 수 있나요?
화면에 기대한 대로 보이는 것을 결과 검증의 충분한 근거로 삼아야 할까요?
여기서 제가 가장 크게 느끼는 Vibe 코딩의 문제점이 드러납니다.
- 당신이 소프트웨어 엔지니어(AI 이전 시대의 공룡)라면, 수십만 줄의 코드를 보아 왔을 겁니다. 직접 수천 개의 코드를 작성했고, 다양한 기술을 시도해 보았으며, PoC를 만들고, 여러 기능에 대한 R&D를 진행해 왔을 겁니다. 이는 당신의 회사 최고 판매 SaaS 제품의 전체 수명 주기에 걸친 경험입니다.
당신은 많은 것을 보았습니다. 이것이 당신에게 다음과 같은 관점을 제공합니다:
- 생성된 코드를 차분히 비판하고,
- 그 코드를 도전하고,
- “시스 감지”처럼 빈틈을 찾아내며,
- 대안을 요구합니다.
모델이 당신에게 다섯 가지 다른 출력을 제공한다면—그것은 좋은 일입니다. 마치 PR을 올리고 다섯 명의 엔지니어가 서로 다른 각도에서 리뷰하는 것과 같습니다. 당신이 가장 적합한 것을 선택합니다.
옵션이 제시되면, 수년간의 경험과 힘들게 얻은 교훈을 종합해 판단을 내리고—그 결과와 함께 살아갑니다.
그런데 그 모든 것이 없으면 어떻게 될까요?
와, 작동한다 – 도파민이 솟구친다
Vibe 코딩이 매력적인 가장 큰 이유는 보이고 느껴지는 결과를 손쉽게 만들어낼 수 있다는 점입니다. “코드 민주화”라는 문구가 많은 사람들에게 울림을 주고, 상상 속 아이디어가 맥북 화면에 나타나는 순수한 기쁨은 이제 프로그래머만의 전유물이 아닙니다.
흥분이 생깁니다. 더 원합니다. 이미 해냈으니 말이죠.
문제는—그것이 당신이 아니라는 점입니다.
그 랜딩 페이지는 빠르게 로드되고, 멋져 보이며, 애니메이션도 훌륭합니다. 버튼도 제 역할을 합니다. 바로 배포하죠?
한 달 뒤, 당신은 다음이 필요합니다:
- 새로운 기능 추가,
- 특정 조건에서만 나타나는 버그 수정, 혹은
- 새로운 개발자에게 인증 흐름이 왜 그렇게 동작하는지 설명하기.
갑자기 당신은 코드를 바라보게 됩니다—
Source:
be written in ancient Sumerian.
Sure, you can ask the LLM to fix it. But now you’re playing Jenga again — except this time with production data and real customers.
If you don’t understand the underlying principles, how can you tell whether the code is sane beyond the fact that it “feels kinda right”?
You might argue: “I don’t need to know plumbing to hire a plumber.” Fair enough. But would you hire the first contractor that pops up on Google, or would you vet them? Talk to people who’ve used them? Check their previous work?
That brings us back to square one. You still need a human in the loop — someone who knows what they’re doing, or at least someone who’s already walked the path you’re about to take.
There’s also the accountability angle. If a contractor misplaces the pipes and your ceiling starts leaking on a cold December day, you have options. You have recourse. You have the right to expect a system that’s properly designed, stable, and auditable.
With vibe coding? You don’t.
- You have no meaningful way to audit or reason about failure modes.
- OpenAI’s and Anthropic’s policies explicitly state they’re not liable for generated code.
- You’re on your own.
What happens when you leak customer data because of a vibe‑coded security hole? What happens when your product crashes mid‑day for reasons you can’t debug, causing losses for your clients?
There’s no contractor to call. There’s just you, a pile of generated code, and a problem you don’t have the foundation to solve.
That’s when you start noticing the cracks.
The Wibbly Jenga Tower
I’ve tried vibe coding a bunch of times on a variety of projects:
- Some were frontend‑heavy.
- Some explored a new technology.
- Others were attempts to learn a new framework.
(Continue the narrative as needed…)
“Wibbly Jinja” 타워
친구들과 젠가를 하는 상황을 떠올려 보세요. 처음에는 모든 것이 안정적입니다 – 깔끔한 직육면체가 가만히 서서 완벽하게 균형을 잡고 있죠. 시간이 지나면서 조각들을 옮기다 보면 점점 조심스러워집니다. 어느 블록을 건드려도 괜찮은지, 절대 건드리면 안 되는지를 파악하려 애쓰게 됩니다.
결국 탑이 매우 흔들리기 시작하는 순간에 이르게 됩니다. 그때는 가능한 한 손을 대지 않으려 하고, 이상적으로는 차례를 넘기고 싶어집니다. 한 번이라도 잘못 움직이면 모든 것이 무너질 것이라는 생각에 게임 자체가 더 이상 재미가 없어집니다.
그리고 무너지면 게임은 끝입니다. 처음부터 다시 시작하게 되죠 – vibe‑coding 으로 흔들리는 젠가 탑의 다음 버전을 만들면서.
vibe‑coding의 최적 지점
그렇다면 vibe‑coding은 운명적으로 실패할까요? 완전히 포기해야 할까요?
그렇지 않습니다.
문제는 vibe‑coding 자체가 아니라, 이를 이해를 대체하는 수단으로 여기고 가속화 도구로 활용하지 않는 데 있습니다. 저는 몇 가지 특정 상황(그리고 아마도 더 많은 상황)에서 vibe‑coding이 뛰어나다고 생각합니다:
1. 아이디어를 고객, 투자자, 혹은 커뮤니티에 보여줄 MVP가 필요할 때
가정 검증이나 제품‑시장 적합성을 테스트하는 방법으로 vibe‑coding은 매우 효과적일 수 있습니다. 아이디어가 있고 이를 가능한 한 빨리 사람들에게 보여주고 싶을 때, 이는 완전히 합리적인 요구이며 이때 AI는 10배의 승수처럼 느껴질 수 있습니다.
한 가지 주의점: 이를 바로 프로덕션에 투입해서는 안 됩니다. 이유는 이제 충분히 명확할 것입니다.
2. 무언가가 실제로 구현 가능한지 빠르게 검증하고 싶을 때
항상 확정적인 답을 주지는 못합니다. AI가 겉보기엔 동작하는 코드를 생성해도 실제 부하나 엣지 케이스에서는 무너질 수 있습니다. 때로는 그 실패 자체가 아이디어 자체의 근본적인 한계를 드러내기도 합니다.
그럼에도 “대략 내가 원하는 모습이 맞는 것 같으니, 아마 만들 수 있겠지”라는 빠른 확인 수단으로, 특히 경험 많은 엔지니어와 함께라면 매우 유용합니다.
3. 새로운 프레임워크, 언어, 혹은 기술을 실제로 보고 싶을 때
vibe‑coding만으로 학습하는 것이 좋은 아이디어라고 주장하진 않습니다. 학습 곡선에서 가장 중요한 부분 중 하나인 능동적인 코딩을 평탄하게 만들기 때문이죠. 삶에서도, 프로그래밍에서도 읽고 이해하는 것은 작성하고 이해하는 것과 동등하지 않습니다.
그럼에도 AI는 Context7 같은 도구를 통해 관련 문서를 더 빠르게 찾아내거나, 특정 개념의 “실제 사례”를 보여주는 데 도움을 줄 수 있습니다. steering wheel을 완전히 AI에 넘겨버리지 않는 한, 학습을 더 흥미롭고 재미있게 만들 수 있습니다.
더 큰 질문으로 이어집니다
엔지니어인 우리에게 미래는 무엇을 가져다줄까요?
vibe‑coding은 앞으로도 지속될까요? 아마도 그렇습니다.
진짜 질문은 기술이 남아 있을지 여부가 아니라, 그럼에도 불구하고 당신이 여전히 중요한 존재가 될 수 있느냐입니다.
제가 보는 전개 양상
-
기본을 이해하는 사람들은 AI를 활용해 더 빠르게 움직이고, 더 나은 제품을 만들며, 더 멀리 탐구합니다. 그들은 생성된 코드를 비판하고, 터무니없는 부분을 찾아내며, 좋은 부분을 자신의 정신 모델에 흡수합니다. 그리고 수년간 다져온 탄탄한 기반 위에 계속해서 구축해 나갑니다.
-
AI를 마법처럼 문제를 해결해 주는 블랙 박스로 여기는 사람들은 단기적으로는 더 빠르게 개발합니다. MVP를 출시하고, 도파민을 얻으며, 어쩌면 고객을 따낼 수도 있습니다. 하지만 장난감 수준의 예시를 넘어 규모를 확장해야 할 순간—또는 더 나쁘게는 LLM이 즉시 고칠 수 없는 방식으로 문제가 발생하거나(혹은 무한 루프에 빠지는 경우: 버그 A 수정 → 버그 B 발생 → 버그 B 수정 → 다시 버그 A 발생…)—그들은 난관에 봉착합니다.
그들은 모멘텀을 유지할 기반을 다지지 않은 채 속도에만 최적화했습니다.
진짜 갈림길은 “AI 애호가 vs. 순수주의자”가 아니라 좋은 코드와 나쁜 코드를 구별할 수 있는 사람 vs. 구별하지 못하는 사람입니다. vibe‑coding은 그 능력을 가르쳐 주지 않을 뿐만 아니라, 당신에게 그 능력이 있는지 없는지를 오히려 가려내기 어렵게 만듭니다.
So where does that leave us?
Use vibe‑coding for what it’s good at: rapid prototyping, exploring new technologies, validating ideas, and iterating quickly on feedback. But treat it like training wheels, not as a replacement (or a permission) for learning how to ride.
Because the moment those wheels come off, you’ll find out very quickly whether you actually know what you’re doing.
Are we optimizing for short‑term dopamine hits or for long‑term mastery of the craft?
그래서 우리는 어디에 서 있는가?
vibe‑coding을 그 강점인 빠른 프로토타이핑, 새로운 기술 탐색, 아이디어 검증, 피드백에 대한 빠른 반복에 활용하세요. 하지만 보조 바퀴처럼 여기고, 타는 법을 배우는 것을 대체하거나 허가하는 것으로 여기지 마세요.
그 보조 바퀴가 떨어지는 순간, 자신이 실제로 무엇을 하고 있는지 아주 빨리 알게 될 것입니다.
우리는 단기적인 도파민 충족을 최적화하고 있는가, 아니면 장기적인 장인 정신을 마스터하는 데 초점을 두고 있는가?