AI에게 “이런 앱 만들어줘”라고 말하면 정말로 코드를 뚝딱 만들어냅니다. 디자이너가 기능하는 프로토타입을 만들고, 창업자가 개발자 없이 아이디어를 테스트하죠. 진입 장벽이 이렇게 낮았던 적이 없습니다.

하지만 개발 전문 회사 Evil Martians가 수십 개의 ‘vibe-coded’ 프로젝트를 직접 다뤄본 결과, 명확한 패턴이 보였습니다. 프로토타입과 실제 서비스 사이의 간격은 생각보다 훨씬 넓고, 결국 무시할 수 없다는 것이죠.

Evil Martians의 개발자 Anton Lovchikov이 실제 프로젝트 경험을 바탕으로 작성한 글입니다. Vibe coding(AI로 대충 만든 코드)이 왜 초기 검증에는 탁월하지만, 실제 제품으로 발전시키려면 경험 있는 개발자가 필요한지를 구체적 사례와 함께 설명합니다.

출처: Why your vibe-coded project needs a developer – Evil Martians

AI가 만드는 코드는 왜 ‘평범’할 수밖에 없나

AI 모델은 온라인에 있는 모든 코드로부터 학습합니다. 훌륭한 코드도, 평범한 코드도, 끔찍한 코드도 모두 포함되죠. 통계적으로 대부분의 코드는 평범합니다. 뛰어난 개발자는 드물고, 대부분의 저장소는 마감 압박 속에서 작성된 “충분히 괜찮은” 솔루션들이거든요.

그래서 AI가 코드를 생성할 때는 가장 흔한 패턴을 제시합니다. 최고의 방법이 아니라 가장 흔한 방법을요.

React를 예로 들어볼까요. 온라인에서 가장 흔히 보이는 패턴은 비즈니스 로직을 컴포넌트 안에 hooks로 직접 넣는 겁니다. 데이터 가져오기? useEffect. 계산? useMemo를 컴포넌트 안에 바로. 작동은 합니다. 수백만 개의 튜토리얼이 이렇게 가르치니까요.

하지만 이 방식은 확장되지 않습니다. 로직이 React에 묶이고, 재사용할 수 없으며, 테스트하기 어렵죠. 성능 최적화가 필요할 때는 모든 게 엉켜있어서 난감합니다.

경험 있는 개발자는 언제 로직을 별도 레이어로 분리해야 하는지 압니다. 하지만 AI는 명시적으로 요청하지 않으면 이걸 제안하지 않습니다. 그리고 이런 패턴이 존재한다는 걸 모르면 요청할 수도 없죠.

반복되는 문제들

수많은 vibe-coded 프로젝트에서 같은 문제들이 계속 나타납니다. 하나하나는 치명적이지 않지만, 합쳐지면 코드베이스를 점점 다루기 어렵게 만듭니다.

명확한 도메인 모델이 없습니다. 비즈니스 로직이 React 컴포넌트들에 흩어져 있어요. 어떤 계산은 한 컴포넌트에, 관련 검증은 다른 컴포넌트에, 상태 관리는 온갖 hooks에 분산되어 있죠. 시스템의 동작이 정의된 명확한 장소가 없습니다.

모든 게 한 곳에 몰려있습니다. 로직, API 요청, UI 관심사가 모두 몇 개의 거대한 컴포넌트에 압축되어 있어요. 이런 컴포넌트는 모든 걸 하기 때문에, 어떤 변경이든 전혀 관계없는 걸 망가뜨릴 위험이 있습니다.

재사용 대신 복사-붙여넣기. 같은 로직이 약간씩 다른 형태로 여러 곳에 나타납니다. 한 곳에서 버그를 고치면 다른 다섯 곳에서도 고쳐야 한다는 걸 기억해야 하는데, 기억 못 하겠죠.

TypeScript를 형변환으로 우회. AI가 타입 에러를 만나면 경험 없는 개발자처럼 형변환으로 해결합니다. 코드는 컴파일되지만 타입의 진짜 목적인 문서화, 안전성, 리팩토링 자신감은 잃게 됩니다.

보안은 나중 생각. 프로젝트는 작동하지만 미묘한 취약점들로 가득합니다. Raw SQL 문자열, 입력 검증 누락, 로그의 민감한 데이터. 데모를 망가뜨리진 않지만 프로덕션은 망가뜨릴 문제들이죠.

실제 사례: Harmonizer 프로젝트

Evil Martians 팀의 디자이너 Anton Lovchikov은 Harmonizer의 첫 버전을 vibe coding으로 만들었습니다. 접근성 있고 일관된 색상 팔레트를 생성하는 도구예요. 아이디어는 간단합니다. 밝기 레벨과 색조를 정의하면 OKLCH 색상 모델과 APCA 공식을 사용해 일관된 대비를 가진 색상들을 생성하죠.

개념 증명으로는 작동했습니다. Anton은 아이디어를 검증하고, 실제 팔레트로 테스트했으며, 유용하다는 걸 증명했어요. Vibe coding이 잘하는 일이 바로 이겁니다.

문제는 실제 작업에 사용하려 하자 문제들이 나타났다는 겁니다. 10×6 팔레트의 색상을 다시 계산하는 데 200밀리초가 걸렸어요. 열에 마우스를 올릴 때마다 전체 그리드가 다시 렌더링됐죠. 헤딩, 색상 셀, 버튼 모두요. 인터페이스가 느리고 반응이 없게 느껴졌습니다.

성능을 고려해서 만들어지지 않았던 거예요. 모든 로직이 React 컴포넌트 안에 있었고, 상태가 바뀔 때마다 불필요한 재계산이 일어났으며, UI와 비즈니스 로직 사이에 분리가 없었습니다.

개발자가 개입했습니다. 로직을 signal 기반 store로 추출해 전체 컴포넌트를 다시 렌더링하지 않고도 세밀한 반응성을 얻었어요. 무거운 색상 계산은 web worker로 옮겨 메인 스레드 부하를 줄였죠. 그리고 여러 플랫폼을 타겟팅할 수 있는 코어 패키지로 재구조화했습니다.

결과? 60fps 렌더링, 마우스 오버 시 불필요한 재렌더링 없음, 확장하기 쉬운 아키텍처. 이 구조 덕분에 나중에 Figma 플러그인 버전을 만드는 것도 가능했어요. 원래 코드로는 훨씬 더 어려웠을 겁니다.

Vibe-coded POC는 가치가 있었습니다. 아이디어가 작동한다는 걸 증명했으니까요. 하지만 실제 제품으로 만드는 데는 개발자 경험이 필요했습니다.

장기적으로 생각하기

Vibe coding이 나쁜 게 아닙니다. 단지 불완전한 프로세스일 뿐이죠.

프로젝트의 첫 단계, 즉 아이디어 테스트, 컨셉 검증, 실제로 써볼 수 있는 뭔가 만들기에는 환상적인 도구입니다. Anton의 Harmonizer 개념 증명이 정확히 그랬어요. 직접 코드를 쓰지 않고도 아이디어가 추구할 가치가 있다는 걸 증명했습니다.

하지만 POC는 제품이 아닙니다. 그리고 그 사이의 간격은 vibe coding으로 메울 수 없습니다.

중요한 건 위에서 설명한 문제들이 첫날부터 나타나지 않는다는 겁니다. 쌓입니다. 정리 없이 계속 개발할수록 고치기가 더 어려워지죠. 시니어의 감독 없는 주니어 팀이 작성한 코드베이스 같아집니다.

작동은 합니다… 망가지기 전까지는요.

LinkedIn의 생성형 AI 담당 엔지니어 Dhyey Mavani도 기업 환경에서 비슷한 패턴을 관찰했습니다. 그의 분석에 따르면 AI 코딩 에이전트 도입이 실패하는 이유는 모델의 문제가 아니라 ‘컨텍스트 엔지니어링’의 부재 때문입니다. 워크플로우를 바꾸지 않고 AI 도구만 추가하면 오히려 생산성이 떨어진다는 거죠. 검증과 재작업에 시간이 더 걸리기 때문입니다.

Vibe-coded 프로젝트를 지속 가능한 것, 즉 확장하고 유지보수하며 의존할 수 있는 것으로 만들고 싶다면, 경험 있는 개발자의 도움이 필요합니다. 정리하고, 재구조화하고, 올바른 아키텍처 결정을 내리는 데 말이죠.

사실 처음부터 경험 있는 개발자를 참여시키는 게 더 좋습니다. 아키텍처를 계획하고, 기술적 결정을 안내하며, AI가 생성한 코드를 검토해서 문제가 쌓이기 전에 잡을 수 있으니까요.

흥미로운 건 LLM이 그런 개발자들에게도 훌륭한 도구라는 겁니다. 어쩌면 초보자보다 경험 있는 개발자에게 더 나을 수도 있어요. 무엇을 요청해야 하는지 아니까요. 취향도 있고, 패턴도 알고, 어떻게 만들어져야 하는지 이해합니다.

그러니 vibe coding으로 아이디어를 만들어보세요. 테스트하고 작동하는지 확인하세요. 하지만 진짜로 만들 준비가 되면, 정리해줄 사람을 데려오세요.

참고자료: Why most enterprise AI coding pilots underperform (Hint: It’s not the model) – VentureBeat