바이브 코딩은 정말 그렇게 쉬운 걸까? 상상해보라. 집사라는 존재는 현실 세계의 AI와도 같다. 실제로 신입 집사에게 아침 식사 차리기나 완벽한 마티니 제조법 같은 스킬을 가르치는 전문 학교도 있다. 그런데 이 학교들은 부유층에게도 따로 교육을 제공한다는 사실을 알고 있는가? 부유층도 집사가 우아하게 찻잔에 차를 따를 수 있도록 찻잔을 제대로 들고 있는 법을 배운다. 심지어 어떤 부탁은 적절하고 어떤 부탁은 부적절한지도 교육받는다. 2분짜리 틱톡 영상으로는 절대 익힐 수 없는 영역이다.

타인의 수발을 받는 일도 쉽지 않다. 찻잔을 잡는 방식에는 정석이 있고, 해도 되는 부탁과 실패할 수밖에 없는 부탁의 경계도 정확히 이해해야 한다.

바이브 코딩도 마찬가지다. 물론 생성형 AI가 할 수 있는 일은 놀랍다. 우수한 AI 코딩 어시스턴트는 몇 줄의 어설픈 문장과 손짓(일명 프롬프트 엔지니어링)만으로도 개발자가 원하는 기능 대부분을 구현하는 작동 가능한 코드를 만들어내기도 한다. 어떤 날은 몇 줄만 입력해도 AI가 수 시간, 길게는 수일 걸릴 작업을 단 몇 분 만에 끝내버린다. 그러나 그런 날은 ‘운이 좋은 날’일 뿐이다. AI가 생성한 코드에는 미묘하지만 분명한 한계가 존재하며, 그 한계가 무엇인지조차 명확히 알 수 없는 경우도 많다. 인간도 AI도 아직은 학습 중인 셈이다.

다음은 바이브 코딩을 시도하는 소프트웨어 개발자가 범할 수 있는 아홉 가지 실수다.

1. LLM을 신뢰하는 것

오늘 아침, AI에게 URL 목록을 만들어달라고 요청했다. 결과는 깔끔했고 형식도 정확했다. 그런데 확인해보니 모든 링크가 404 오류를 뱉었다. 전부 깨진 링크였다.

AI에게 알리자, 이렇게 답했다. “맞습니다. 죄송합니다! 웹사이트 링크는 자주 바뀌며, 이전 정보가 오래된 것 같습니다. 각 항목을 다시 검증하고 올바른 URL로 업데이트했습니다.” 하지만 업데이트된 링크들도 마찬가지로 전부 동작하지 않았다.

오늘날 대부분의 AI에 숨겨진 시스템 프롬프트를 작성한 인간은 우리 모두에게 큰 실수를 저질렀다. 많은 대규모 언어 모델(LLM)은 과도하게 친절하고 굽실거리는 성격으로 훈련돼 있다. 해결책을 찾지 못하더라도 뭔가를 생성해놓고는 자신 있게 “작동한다”라고 우긴다.

바이브 코딩에서 가장 치명적인 첫 번째 실수는 바로 LLM을 신뢰하는 것이다.

2. 모든 모델이 같다고 생각하는 것

얼핏 보면 대다수 LLM은 그저ㅗ 비슷하다. 텍스트를 넣으면 마법처럼 결과가 나오니, 다 똑같다고 생각하기 쉽다. 간단한 질문에는 비슷한 답을 내놓기도 한다. 모델 이름도 대개 귀엽고 친근하게 지어져서 기술적 특성을 파악하긴 어렵다.

그러나 내부 구조는 천차만별이다. 특히 복잡한 논리를 요하는 코딩 작업의 경우, 문제를 분해하고 여러 단계로 나누어 처리하는 메커니즘의 차이가 큰 영향을 미친다.

파라미터 수는 모델이 학습한 지식의 양을 대략적으로 나타내는 지표다. 많을수록 일반적으로는 좋지만, 예외도 존재하며 이는 실험해보기 전에는 알 수 없다.

또한 각 LLM은 서로 다른 학습 데이터셋으로 훈련된다. 오픈 웹에서 수집한 자바스크립트 코드를 배운 것인지, 제대로 문서화된 실전 코드 리포지토리에서 학습했는지 여부도 중요하다. 코볼(COBOL) 같은 레거시 언어를 제대로 학습했는지도 불분명하다.

결국, 어떤 문제에 어떤 모델이 적합한지는 직접 시험해봐야만 알 수 있다.

3. LLM을 쓰레기통처럼 사용하는 것

많은 개발자가 LLM 입력 크기의 중요성을 간과한다. LLM은 프롬프트에 포함된 모든 토큰을 처리한 뒤에야 결과를 생성할 수 있다. 입력이 많을수록 자원도 더 많이 소모된다.

거대한 코드 블록을 아무 생각 없이 던져 넣으면, 하드웨어 리소스를 소모하고 컨텍스트 윈도우를 초과할 수 있다. 일부 개발자는 소스 코드 전체 폴더를 “혹시 몰라서” 업로드한다고 말하기도 한다.

상용 LLM은 입력 및 출력 토큰 수에 따라 비용이 청구된다. 이른바 ‘낚시’ 프롬프트가 길어질수록 느려지고, 요금도 올라간다. 코드가 많아지면 AI의 집중력도 분산되고 혼란스러워질 수 있다. AI는 불필요한 코드에 집중해 핵심을 놓칠 수 있다.

4. AI가 인간처럼 사고한다고 생각하는 것

AI는 인간처럼 말하고, 헛소리도 하고, 기억도 틀린다. 그래서 인간처럼 느껴질 수 있다. 하지만 본질적으로 AI는 훈련 데이터를 조합해 출력하는 정교한 모방자일 뿐이다. ‘사고’하는 것은 아니다.

AI 어시스턴트는 문서 속 숨겨진 정보나 찾기 힘든 기능을 드러내는 데는 탁월하다. 방대한 학습 자료에서 정확한 인사이트를 찾아내는 데 능하다.

그러나 통합적 사고나 깊은 통찰을 요구하는 작업은 늘 기대만큼 뛰어나지 않다. 물론 어떤 순간에는 놀라운 결과를 내놓지만, 그건 학습 데이터에 포함된 누군가의 뛰어난 문서 덕분일 뿐이다.

AI 어시스턴트가 매번 천재처럼 행동하리라 기대하지 않는 것이 현명하다.

5. 누더기 같은 코드 생성

많은 개발 조직은 코딩 스타일 가이드를 갖추고 있다. AI는 그런 규율에 그다지 관심이 없다. 오히려 매 실행마다 결과 스타일이 바뀌는 무작위성을 포함하고 있다.

같은 프롬프트를 반복 실행해도 서로 다른 코드가 생성된다. 작동은 하지만, 스타일이 들쭉날쭉해 일관성은 없다. 바이브 코더는 이를 무시하고 그냥 복사해 붙인다. 코드는 돌아가지만, 뒤죽박죽의 코드베이스가 되어버린다. 이후 코드 유지보수는 악몽이 된다.

6. LLM의 프로그래밍 편향을 무시하는 것

AI는 학습 데이터에 따라 출력이 달라진다. 일부 개발자는 작은 편향이 코드에 치명적인 오류로 이어졌던 경험을 공유한다.

최근 학습한 내용을 반복해 사용하는 ‘근접 편향’, 자신이 만든 설계를 선호하는 ‘내부 지향 편향’ 등, 다양한 편향 요소가 존재하며 이들은 코드에 스며든다.

바이브 코더는 대체로 이런 디테일을 신경 쓰지 않는다. 간단한 작업에는 괜찮지만, 대규모 시스템이나 중요한 프로젝트에는 이들 편향이 심각한 문제를 일으킬 수 있다.

7. 비용을 무시하는 것

AI 툴은 겉보기에 저렴하다. 건강 보험도 없고 휴가도 필요 없으니까. 그러나 AI는 토큰 단위로 요금이 청구된다. 게다가 그 토큰은 결국 클라우드 자원과 전력을 소모한다.

바이브 코더는 같은 요청을 반복하고, 대량의 코드를 입력해 비용이 기하급수적으로 증가하는 상황을 유발한다. 입력 토큰도, 출력 토큰도 계속 쌓인다. 어딘가에서는 화석연료 발전기가 돌아가고 있고, 비싼 GPU는 계속 전기를 빨아들인다.

8. 통제권을 AI에 넘기는 것

프로그래밍은 반복적이지만, LLM은 기본적으로 무작위성을 포함하고 있어, 매번 다르게 반응한다. 따라서 특정 역할을 완전히 맡기기에는 위험하다.

어떤 바이브 코더는 실제 운영 데이터베이스를 삭제당한 사례도 겪었다. 데이터는 사라졌고, AI는 아무런 죄책감 없이 다음 프롬프트로 넘어갔다.

9. AI 환각을 추적하는 것

최근 기억 중 최악의 프로그래밍 날이 있었다. AI 코딩 어시스턴트가 보기 좋은 주석과 함께 완성된 듯한 코드를 내놓았다. 일부는 잘 작동하기도 했다.

하지만 문제는, 존재하지 않는 라이브러리 호출을 마치 실재하는 것처럼 만들어낸 것이었다. 감싼 코드와 API 연결 부분은 멀쩡했지만, 핵심 메서드는 라이브러리에 존재하지 않았다. 이름을 잘못 입력했나 싶어 문서와 소스 코드를 수 시간 동안 뒤졌다.

AI에게 문제를 지적하자, “죄송합니다. 맞습니다”라고 진심 없는 사과를 반복한 뒤, 똑같이 틀린 코드를 다시 생성해냈다.

결국, 어떤 날은 직접 코딩하는 것이 더 낫다.
dl-itworldkorea@foundryco.com