'AI가 짜준 코드가 정말 내 코드인가'라는 질문은 감성적으로 들리지만, 사실은 매우 실용적인 질문이다. AI가 생성한 코드는 처음 동작할 때는 그럴듯해 보이지만, 다음 스프린트에서 누군가 그 코드를 건드려야 하는 순간 진짜 문제가 시작된다. 그 코드가 살아남느냐, 아니면 조용히 무너지느냐.
흥분과 단절 사이에서
dev.to에 올라온 Valeria의 Rackula 회고는 vibe coding의 양면을 정직하게 보여준다. Andrej Karpathy가 2025년 2월 명명한 'vibe coding'—코드가 어떻게 돌아가는지 몰라도 AI에게 맡기면 일단 굴러가는 방식—은 분명히 프로토타입 속도를 끌어올린다. Rackula 제작자 Gareth Evans는 Claude Code로 5개 에이전트를 병렬 실행하며 초기 프로토타입을 '매우 빠르게' 완성했다고 말한다. 하지만 Valeria 자신은 달랐다. OpenCode로 30분을 보낸 뒤 코드를 들여다봤을 때, 그 코드는 '낯설었다'. 동작은 했지만 자신의 것이 아니었다. 그 이질감이 며칠간의 '손코딩 해독' 과정으로 이어졌다.
이 단절감은 단순한 심리 문제가 아니다. AI가 생성한 코드는 컨텍스트가 부족하면 다음 AI 수정 시도에서도 예측 불가능하게 변형된다. 즉, LLM이 처음 만든 코드를 LLM이 다시 수정할 때—실제 프로덕션 워크플로우에서 반복되는 그 상황에서—코드가 살아남는 비율이 얼마나 되는지가 핵심 질문이 된다.
측정 가능한 지표로: modification survival rate
dev.to의 또 다른 글에서 한 개발자는 이 질문을 실험으로 끌고 갔다. 그는 Almide라는 정적 타입 언어를 직접 설계하면서, 'LLM이 코드를 수정했을 때 그 결과물이 컴파일을 통과하고 기존 테스트를 버텨내는 비율'을 modification survival rate라고 이름 붙였다. 30개의 코드 수정 태스크를 벤치마크로 구성하고 Claude Sonnet 4.6을 돌린 결과, Almide는 30/30을 통과했다. 동일한 태스크를 Rust로 실행하면 약 58%였다.
이 숫자를 'Almide가 Rust보다 낫다'고 읽으면 안 된다. Rust는 훨씬 성숙하고, 더 넓은 문제를 다룬다. 여기서 진짜 질문은 좁고 예리하다: 언어 설계 자체가 LLM 수정의 생존율에 영향을 줄 수 있는가? Almide는 프로그램 구조를 쉽게 추론하게 만들고, 변경을 국소적으로 제한하며, 잘못된 상태를 컴파일 타임에 차단하도록 설계됐다. LLM이 '그럴듯하지만 틀린' 코드를 만들어내는 실패 패턴—한 쪽 콜 사이트만 바꾸거나, 에러 케이스를 빠뜨리거나, 타입 변형 후 영향 범위를 추적하지 못하는 것—을 언어 수준에서 걸러내겠다는 발상이다.
두 실험이 공통으로 가리키는 것: 설계가 먼저다
Rackula 사례와 Almide 실험은 접근이 전혀 다르지만 같은 방향을 가리킨다. Gareth는 초기에 데이터 모델과 스키마 설계를 제대로 하지 않으면 AI가 그 위에서 엉뚱한 방향으로 달려간다는 걸 배웠다. 그는 NetBox에서 개념 모델을 빌려와 Rackula의 스키마를 잡고 나서야 AI 에이전트가 '방향 있는 빠름'을 보여줬다고 말한다. Almide 실험은 이를 언어 설계 레벨로 확장한다. 구조를 사전에 명확히 정의하면, LLM의 수정 성공률이 극적으로 달라진다.
프론트엔드 맥락으로 옮기면 이 원칙은 더 구체적이 된다. 컴포넌트 경계가 모호하고, props 타입이 any로 열려 있고, 사이드 이펙트가 여기저기 섞인 코드는 LLM이 수정하기 가장 위험한 코드다. 반대로 TypeScript strict 모드, 명확한 인터페이스, 테스트로 고정된 행동 명세가 있는 코드는 LLM이 수정해도 살아남을 가능성이 높다. 이건 '인간이 읽기 좋은 코드'와 거의 동일한 기준이기도 하다.
vibe coding의 진짜 한계, 그리고 실용적 대안
vibe coding이 나쁜 것은 아니다. 문제는 그것이 '탐색 모드'임을 잊는 데 있다. Rackula는 1040개의 커밋으로 완성됐다. 초기 프로토타입이 빠른 것과 그것이 오래 살아남는 것은 다른 이야기다. Gareth가 TDD 기반 AI 워크플로우—스펙을 먼저 정의하고, 테스트를 먼저 만들고, AI가 그 테스트를 통과하는 코드를 생성하는 순서—를 고수한 것은 결국 modification survival rate를 인간이 개입해서 높인 전략이었다.
전망: 언어와 도구가 LLM을 위해 재설계되는 시대
Almide 실험이 흥미로운 건 결과 숫자가 아니라 질문의 방향이다. 지금까지 프로그래밍 언어는 '인간이 읽고 쓰기 좋게' 설계됐다. 앞으로는 'LLM이 수정하기 좋게'라는 축이 언어 설계의 새로운 고려 대상이 될 수 있다. TypeScript가 대규모 팀 협업을 위해 타입 안전성을 선택했듯, 미래의 언어나 프레임워크는 AI 수정의 생존율을 설계 목표로 삼을 수 있다. 30개 태스크짜리 벤치마크로 결론을 내리기엔 이르지만, 이 방향의 탐구 자체는 프론트엔드 생태계에 실질적인 질문을 던진다.
AI가 코드를 고칠수록 중요해지는 건 AI의 능력이 아니라 그 코드가 수정을 버텨낼 수 있는 구조적 기반이다. 스키마를 먼저 잡고, 테스트로 행동을 고정하고, 경계를 명확히 그은 코드—그것이 vibe coding 이후에도 살아남는 코드다.