바이브코딩은 정말 안 되는가 — 비개발자가 AI와 하루 종일 설계하고 내린 결론

나는 개발자가 아니다. 그런데 AI와 함께 꽤 복잡한 시스템을 설계하고 있다. 오늘 문득 든 질문 — "AI가 코딩을 이렇게 잘하는데, 왜 다들 바이브코딩은 안 된다고 할까?" 그 답을 정리해봤다.

먼저, "바이브코딩이 안 된다"는 말은 과장이다

바이브코딩(vibe coding) — 대충 느낌으로 지시하고 AI가 코드를 뽑아내게 하는 것. 이걸로 작동하는 것을 만드는 건 실제로 된다. 간단한 앱, 프로토타입, 스크립트는 놀랄 만큼 잘 나온다.

그러니 "안 된다"는 건 틀렸다. 개발자들이 진짜 하려는 말은 대개 이쪽이다:

"바이브코딩만으로는 오래 못 간다."
"복잡해지면 무너진다."

왜 그런지가 핵심이다.

코딩의 진짜 어려움은 '타이핑'이 아니다

AI가 코드를 잘 뽑는 건 맞다. 하지만 코딩의 어려움은 코드를 치는 데 있지 않다. 어려움은 이런 데 있다:

지금 짠 이 부분이 6개월 전에 짠 저 부분과 충돌하지 않는가
이 수정이 다른 20군데에 어떤 파장을 일으키는가
같은 단어가 여기선 이 뜻, 저기선 저 뜻으로 미묘하게 달라지는 걸 일관되게 유지하는가

이건 코드를 뽑는 능력이 아니라 전체를 머릿속에 들고 있는 능력이다.

그리고 여기서 AI의 근본 한계가 나온다. AI는 대화가 길어지면 앞을 잊는다. 실제로 오늘 내 대화도 중간에 "대화 압축"이 일어났다 — 앞부분을 요약본으로 갈아치우고 진행하는 것이다. 사람 개발자는 프로젝트 전체를 몇 달간 머리에 이고 있지만, AI는 지금 창에 들어온 것만 본다.

그런데 — 바로 그래서 오늘 한 일이 정답이었다

여기가 재미있는 지점이다. 오늘 하루 종일 AI와 뭘 했나? 코드를 짠 게 아니다. 문서를 정교하게 관리했다.

설계 문서를 버전 매기고, 서로 충돌하는 부분을 잡고, "이 규칙은 여기가 정본, 저 이름은 저기가 정본"을 명시하고, 마지막엔 "어떤 순서로 만들지" 로드맵까지 박았다.

이게 정확히 바이브코딩의 한계를 메우는 방법이다. 이게 바이브스킬링이다.

AI가 앞을 잊어도, 문서가 기억한다. 핵심 규칙이 문서에 못박혀 있으면, 석 달 뒤 다른 대화의 AI가 와도 그걸 읽고 일관되게 잇는다. 이름 규칙을 정해놨으니, AI가 헷갈릴 때 대조할 기준이 있다.

문서가 AI의 부족한 기억을 대신하는 '외장 메모리' 역할을 한다.

순수 바이브코딩(문서 없이 느낌으로 계속 지시)이 무너지는 이유와, 오늘 방식이 튼튼한 이유는 같은 동전의 양면이다 — 전자는 일관성을 유지할 닻이 없고, 후자는 문서라는 닻이 있다.

개발자들의 걱정에는 타당한 부분이 있다

정직하게 그들 편을 들면, 맞는 지점이 있다.

"작동한다"와 "믿을 수 있다"는 다르다. 바이브코딩은 눈에 보이는 화면은 잘 만드는데, 안 보이는 것 — 보안 구멍, 예외 상황, 이상한 입력에 대한 방어 — 을 빠뜨리기 쉽다. 화면상 잘 돌아도, 누가 이상한 값을 넣었을 때 터지는 걸 놓칠 수 있다. 그래서 자동 검사(테스트 코드)를 설계 단계에 박아둬야 한다.

"고칠 수 있는가"의 문제. 바이브로 뽑은 코드는 나중에 사람이 열어봤을 때 왜 이렇게 짰는지 알 수 없는 경우가 많다. 그럼 고치질 못한다. 그래서 "왜"를 따로 문서에 남겨야 한다.

책임의 문제. 코드가 잘못돼 실제 손해가 나면 누가 책임지나. AI는 책임을 못 진다. 그래서 사람이 검수하고 이해한 뒤 승인하는 층이 반드시 필요하다.

그래서 결론 — 이분법이 틀렸다

"바이브코딩 되냐 안 되냐"는 사실 잘못된 질문이다. 진짜 그림은 이렇다:

AI 혼자 느낌으로 = 빠르지만, 복잡해지면 일관성과 안전성이 무너진다. (개발자 걱정이 맞는 영역)
AI + 좋은 문서 + 사람 검수 = 오늘 내가 한 방식. AI는 잘 짜고, 문서가 그 기억을 대신하고, 사람이 최종 판정한다. 이게 강력하다.

즉 답은 "바이브코딩을 하느냐 마느냐"가 아니라 **"바이브코딩에 무엇을 더하느냐"**다.

마지막으로 — 비개발자의 진짜 강점

솔직히 오늘 대화에서 코드 얘기는 거의 안 했다. 우리가 한 건 "무엇을 만들지, 왜 그렇게, 어떤 순서로"를 정하는 일이었다. 그리고 그건 코딩이 아니라 설계와 기획이다.

여기서 내 판단이 시스템을 끌고 갔고, AI는 그걸 계산과 문서로 옮겼다.

바이브코딩의 진짜 교훈은 이거다:

AI가 잘하는 건 "어떻게 짜나"(구현)이고, 사람이 잘하는 건 "무엇을 왜 짜나"(판단)다. 이 둘이 만나면 세다.

나는 비개발자라 "코드를 몰라서 걱정"이라고 생각했다. 그런데 오늘 대화에서 가장 중요한 일 — 무엇을, 왜 만들지 — 은 내가 했다.

코딩은 그다음 문제다. 스킬링이 먼저다.

AI에게 코드를 맡기는 게 불안하다면, 코드를 배우려 하기 전에 문서로 닻을 내리는 법과 무엇을 왜 만들지 판단하는 법부터 익히면 된다. 그게 비개발자가 AI와 함께 큰 것을 만드는 길이다. 바이브코딩은 안 되는 게 아니라, 혼자서는 안 되는 것이다.

이 글은 실제로 AI와 하루 종일 시스템을 설계한 경험에서 나왔다. 그날 우리가 짠 것은 코드 한 줄이 아니라, 앞으로 코드가 될 문서들이었다.

저작자표시 비영리 변경금지 (새창열림)