바이브 코딩 vs 손코딩 - 이길 수 있을까?

낙차는 어디서 오는가

매일 터미널에서 Claude Code를 켜는 입장이라 이 거리감은 사실 어렵지 않게 해결할 수 있다. 간단한 스크립트 하나는 체감 성공률이 거의 100%다.

다만 여러 파일에 걸친 설계를 새로 잡아야 하는 순간부터는 신뢰가 뚝 떨어지는 감각이 온다.

예전에 쓴 글에서도 비슷한 이야기를 짚었다. 코드 리뷰나 리팩토링처럼 검증하기 쉬운 일에서는 AI가 확실히 값을 하는데, 결정을 많이 요구하는 작업으로 갈수록 쓸모가 급격히 떨어진다는 관찰이었다.

판단할 게 드문 작업은 AI가 잘 버티고, 판단이 촘촘한 작업은 AI가 더 흔들린다는 뜻이다.

이 차이를 가장 잘 나타내는 사례가 하나 있다.

오랫동안 (30년 넘게) 베이식만 짜온 개발자가 있었다. (베이식은 오래된 프로그래밍 언어다.)
이 오래된 그루(전문가)에게 처음으로 챗지피티에 코드를 시켜봤다.

과제는 세 개였다.

첫 번째는 자기 코드를 그대로 콘솔에 출력하는 프로그램, 창 크기에 맞춰 글씨가 자동으로 커지는 200x100 시계, 파란 배경에서 노란 원이 도는 640x480 애니메이션. 첫 과제에서 AI가 압승했다. 자기 코드를 자기가 출력하는 quine 문제를 AI는 한 줄로 풀었다. 그루가 짠 코드는 아홉 줄이었다. 스스로 바보처럼 느껴졌다고 했다.

두 번째는 시계 과제는 거의 비등했다.

세 번째, 원이 도는 애니메이션에서는 판이 뒤집혔다.
AI는 3D 효과도 가능하다며 자신 있게 코드를 내놨는데 실제로는 돌아가지 않았다. 다시 시켜보니 부주의로 실수가 있었다며 두 가지 개선안을 내놨고, 그중 하나는 종료 키가 아예 빠져 있었다. 세 번째 시도에서야 그루가 직접 손을 봐서 완성했다.

이 원문이 내린 결론은 이거다. "인간이라도 전문가가 아니면 AI보다 나을 수 있다." → "프로그래머라는 직업이 사라질 때는 아직 멀었다."

처음 두 과제에서 승승장구하다가 세 번째에서 뒤집힌다는 것을 인정하기 어렵다.

그런데 이 후기를 자세히 살펴보면 주목해야 할 것이 있다. 그루가 쓴 방식은 챗지피티 웹 채팅창에 요청을 쓰고, 나온 코드를 복사해서 에디터에 붙여넣고, 직접 실행해보는 방식이었다.

처음엔 로그인도 안 한 채로 썼고, 나중에는 다른 컴퓨터에서 로그인해 같은 작업을 반복했다. 실행은 전부 사람 몫이었다. AI는 자기가 짠 코드가 실제로 돌아가는지 한 번도 직접 확인하지 못한 채로, 더 나아졌다는 말을 계속 반복했다. (무언가 잘못되었다.)

"바이브 코딩"이라는 말을 처음 쓴 앤드리 카파시의 2025년 2월 트윗을 다시 찾아봤다. "코드가 존재한다는 사실조차 잊고 vibes에 완전히 몸을 맡긴다"면서, diff를 제대로 안 보고 받아들이고 에러 메시지를 그대로 복사해 AI에 다시 붙여넣는 걸 자기 작업 방식으로 묘사한 글이었다.

그루가 한 방식과 그대로 겹친다. 지금은 Claude Code나 커서에 실행 권한까지 쥐여준다. 카파시가 트윗에서 그렸던 장면보다 한 걸음 더 나아간 셈이다. 지금은 좀 더 강화되었다, 예전과는 확실히 다르다. 다시 대결한다면 더 쉽게 이기지 않을까?

챗봇 복붙과 에이전틱 코딩, 루프의 주인이 다르다

Claude Code나 커서 같은 도구는 다르다. 코드를 쓰고 나서 직접 실행하고, 에러가 나면 그 메시지를 스스로 읽고 고친다. 사람은 요청할 때와 마지막에 확인할 때만 끼어든다.

챗봇 복붙 방식은 다르다. 실행 결과가 AI에게 전달되는 통로가 사람이 다시 타이핑해서 알려주는 것 하나뿐이다. 부주의로 실수가 있었다는 사과를 받고도 그루가 원 그리는 알고리즘 오류와 색상 루프 오류를 두 번 더 마주친 이유가 여기 있다고 본다. AI는 자기가 짠 코드를 실행해서 확인할 방법이 없으니, 코드를 고칠 때마다 확신을 매번 처음부터 새로 만들어 붙인다. 검증 없이 확신만 반복된다.

그렇다고 에이전틱 도구를 쓰면 이 낙차가 사라지느냐 하면, 그건 아니다. 실행이 되는 것과 설계가 맞는 것은 다른 문제다. 그루가 세 번째 과제에서 정말로 맞닥뜨린 건 원을 어떤 알고리즘으로 그릴지, 색을 어떤 순서로 순환시킬지 같은, 매 줄이 결정인 작업이었다. 판단이 촘촘한 자리라는 뜻이다. Claude Code로 비슷한 성격의 작업을 시켜봐도, 실행은 스스로 돌려서 최소한 에러 없이 돌아가는 상태까지는 수렴하지만, 그게 원한 설계인지는 또 다른 확인이 필요하다는 인상을 매번 받는다. 돌아간다는 확인과 맞다는 확인은 서로 다른 검증이다.

판단이 촘촘한 지점인지는 코드를 보기 전에도 어느 정도 가늠할 수 있다. 선택지가 두 개 이상 놓이고 그중 하나를 골라야 하는 줄이 몇 줄에 한 번씩 나오는지가 기준이다. 파일 하나를 고치는 일과 여러 파일에 걸쳐 이름과 구조를 동시에 바꿔야 하는 일은 겉보기엔 둘 다 "코드 작성"이지만 판단 밀도가 다르다.

차이는 그 흔들림이 사람 눈에 언제 보이느냐다. 에이전틱 도구는 실행해보고 안 돌아가면 그 자리에서 바로 안다. 챗봇 복붙은 사람이 직접 돌려보고 알려주기 전까지 AI가 확신을 그대로 유지한다. 그래서 챗봇 복붙 방식에서는 같은 버그가 반복돼도 AI 쪽에서 먼저 의심하는 법이 없다. 사람이 매번 새로 실행해서 알려줘야 다음 시도가 나온다.

이 사례에서 정말 건질 건 AI가 복잡한 프로젝트를 못 짠다는 문장이 아니다. 진짜 배울 건, 작은 과제 한두 개에서 얻은 성공 경험을 다음 과제로 그대로 이월시키면 안 된다는 쪽이다. quine 문제와 회전 애니메이션은 어려운 정도가 다른 게 아니었다. 원을 어떻게 그리고 색을 언제 바꿀지, 매 줄마다 결정을 새로 내려야 했을 뿐이다.

첫 승리에 취해 그 신뢰를 세 번째 과제에도 그대로 넘겨준 것, 그루가 진짜로 실패한 대목은 거기다. 처음 AI 코딩 도구를 만져보는 사람일수록 이 함정에 더 쉽게 걸린다. 작은 성공 두어 번으로 신뢰를 다 써버리고, 판단할 게 갑자기 많아지는 순간 낙차를 만나면 그제서야 당황한다.

프로그래머라는 직업이 사라질 때는 아직 멀었다는 결론에는 나도 동의한다. 다만 이유는 다르게 본다. 그루는 AI가 부분은 봐도 전체 그림은 못 본다고 정리했는데, 나는 매일 Claude Code로 전체 코드베이스를 훑게 시키는 작업도 하고 있어서 이 진단에는 선뜻 동의가 안 된다.

문제는 큰 그림을 못 보는 게 아니다. 판단할 일이 몰리는 순간 낙차가 온다는 신호를, 도구가 미리 주지 않는다는 데 있다. 그 경고를 사람이 먼저 알고 시작하면, 챗봇이든 에이전트든 낙차는 준비한 만큼 작아진다.