코딩을 한 번도 안 해본 사람이 '바이브 코딩'을 하며 겪은 가장 큰 함정
The biggest trap I've hit doing "vibe coding" as someone who's never written code
핵심 요약
AI로 코딩하며 겪은 가장 큰 문제는 AI가 근본적인 해결 대신 임시방편(패치)만 내놓아 코드베이스가 엉망이 되는 것입니다.
- 임시방편의 함정 — AI가 근본 원인 대신 특정 사례만 예외 처리하여 문제를 숨김
- 코드 가독성 부족 — 비개발자는 AI의 수정안이 근본 해결인지 임시 패치인지 구분하기 어려움
- 검증 질문 활용 — AI에게 '이게 일반적인 규칙인가, 아니면 특정 사례를 위한 예외인가'라고 직접 물어봐야 함
- 문서화의 중요성 — 설계 원칙을 기록해두어야 나중에 AI가 잘못된 방향으로 코드를 수정하는 것을 방지함
나 자동차 업계에서 구매 담당하는 사람인데, 코딩이라곤 1도 모름. 지난 6개월 동안 AI(Claude, Cursor) 써서 엑셀 쿼리 툴 하나 만들었거든. 처음엔 "AI한테 내가 원하는 걸 정확히 설명하는 게" 제일 힘들 줄 알았는데, 진짜 함정은 거기 있는 게 아니더라.
진짜 함정은 이거임: AI는 매번 문제를 "고쳐"주긴 하는데, 그게 진짜 해결된 건지 아니면 그냥 임시방편으로 때운 건지 확인할 방법이 없다는 거.
예를 하나 들어볼게. 시스템에서 부품 가격 조회하는 쿼리 하나가 무한 루프에 빠져서 계속 엉뚱한 값만 뱉어내더라고. 토큰 150만 개나 날려 먹고 나서야 겨우 멈췄지. Cursor한테 고쳐달라고 하니까 바로 해결해주더라. 그 특정 상황은 더 이상 안 나타났음.
근데 나중에 보니까 어떻게 고쳤는지 알아? 그냥 "부품 번호가 X면 이렇게 처리해라" 식으로 코드를 짠 거였음. 그러니까 루프가 왜 생겼는지 근본 원인은 건드리지도 않고, 그냥 그 특정 케이스만 예외 처리로 땜빵한 거지.
여기서 진짜 골 때리는 점: 이런 식의 해결책은 단기적으로는 완벽해 보임. 버그는 사라졌고, "오, 문제 해결 완료!"라는 기분이 들거든. 근데 코드를 읽을 줄 모르는 사람 입장에서는 이게 근본적인 구멍을 메운 건지, 아니면 그냥 우회해서 돌아간 건지 구분할 방법이 아예 없음. 결과가 똑같아 보이거든.
그래서 6개월쯤 지나니까 내 시스템은 이런 조각들로 가득 찼어. 겉보기엔 다 독립적인 코드 같은데, 사실은 전부 같은 근본 문제를 따로따로 땜빵하고 있었던 거지. 그러다 어느 날, 아무도 예외 처리를 안 해둔 새로운 상황이 터지니까 시스템 전체가 박살 나더라. 그때 디버깅하느라 진짜 죽는 줄 알았음. 코드 베이스가 온통 일회성 패치로 도배돼 있어서, 도대체 뭐가 문제인지, 어떤 패치가 이번 오류랑 연관된 건지 알 수가 없었거든.
결국 내가 찾아낸 해결책은 말하기 민망할 정도로 간단함.
AI가 "고쳤습니다"라고 할 때마다 딱 잘라서 물어보는 거임: "이거 일반적인 규칙이야, 아니면 이번 한 번만 적용되는 예외 케이스야?"
만약 답변에 특정 이름, 특정 ID, 특정 숫자("부품 번호가 X일 경우") 같은 게 들어가면? 그건 빨간 불임. 제대로 고친 게 아니라 그냥 땜빵하고 있을 확률이 높음.
그 외에 습관 들인 거 두 가지 더 있음.
-
주기적으로 AI한테 "이 코드 베이스 전체를 훑어서 똑같은 패턴이 숨어있는 곳이 있는지 찾아봐"라고 시키기. 이거 덕분에 눈에 안 보이던 똑같은 버그들을 몇 번이나 잡아냈음.
-
깨달은 원칙들을 '살아있는 문서(living doc)'에 다 적어두기. 6개월 뒤면 왜 이렇게 설계했는지 다 까먹음. 나중에 AI가 헛소리할 때, 그 문서가 똑같은 실수를 반복하지 않게 막아주는 방패가 됨.
비전공자가 AI로 코딩할 때 가장 큰 장벽은 "코딩 문법을 모르는 것"이 아님. AI가 내놓은 해결책이 진짜 문제를 해결한 건지, 아니면 문제를 더 깊숙이 파묻어버린 건지 구분하지 못하는 게 진짜 문제임.
단기적으로는 둘 다 똑같아 보이거든. 어쨌든 문제는 "사라지니까". 그게 진짜 해결이었는지 땜빵이었는지는 한참 뒤에나 알게 되는데, 그때는 이미 수습하기 훨씬 더 힘들어져 있음.


