바이브 코딩은 엑셀보다 엑셀 매크로에 가깝다

바이브 코딩은 홈페이지나 SaaS를 만드는 개발 기술이 아니라, 엑셀·워드·PPT처럼 내 일을 처리하려고 여는 도구라는 주장이 있습니다. 5년 동안 워드프레스로 홈페이지를 만들어온 웹핏 운영자가 쓴 글이고, 논지는 설득력 있게 짜여 있어요. 판매할 서비스가 없어서 바이브 코딩을 미뤄온 사람에게, 거창한 아이디어 대신 매일 일하다 손이 멈추는 자리에서 시작하라고 권하죠.

근거도 구체적입니다. 고객에게 보낼 비즈니스 프로필을 워드 대신 HTML로 만들어 브라우저에서 바로 열리고, 작은 화면에서도 읽히고, 인쇄까지 되게 했습니다. 폴더와 노션에 흩어져 있던 홈페이지 참고자료는 사이트별이 아니라 화면의 역할별로 나눈 '홈페이지 패턴 도감'으로 묶었고요. 둘 다 회원가입도 결제도 필요 없는, 자기 일만을 위한 결과물이었습니다.

엑셀로 하던 계산과 분류는 작은 처리 도구로, 워드로 쓰던 문서는 디자인과 사용 방식을 묶은 문서로, 파워포인트로 하던 구성은 검색하고 비교하는 화면으로 옮겨 간다는 그림입니다. 입구를 옮겨놓는다는 점에서 저는 이 글의 절반에 동의해요. 바이브 코딩을 창업 도구로만 소개하는 흐름이 많은 사람을 문 앞에서 돌려보낸 건 맞으니까요.

비유가 갈라지는 자리

동의하지 않는 건 비유의 나머지 절반입니다. 엑셀과 워드와 PPT에는 공통점이 하나 더 있거든요. 프로그램은 남이 유지하고, 나는 그 위에 파일만 만든다는 것. 엑셀 파일은 몇 년 뒤에도 엑셀이 열어주고, 계산이 이상하면 셀을 눌러 수식을 보면 됩니다. 만든 사람이 퇴사해도 다른 사람이 열어서 고칠 수 있고요.

글 안에도 이 차이를 비추는 문장이 하나 있습니다. 바이브 코딩이 오피스 도구를 없애지는 않을 거라며, 계산표 한 장이면 엑셀이 빠르고 여러 사람이 함께 문장을 고칠 때는 구글 문서가 편하다고 한 대목이죠. 저는 이걸 취향의 문제로 읽지 않아요. 여럿이 쓰기 시작하는 순간 사람들은 남이 유지하는 프로그램으로 돌아간다는 관찰이고, 바이브 코딩 결과물이 약한 자리가 정확히 거기입니다.

바이브 코딩으로 만든 결과물은 사정이 다릅니다. 로직도, 그 로직이 돌아가는 환경도 내 몫이에요. 이 차이는 글이 스스로 그어둔 구분에서 이미 드러납니다. 메일 초안은 답을 받아 복사하면 끝나지만, 바이브 코딩 결과물은 다시 열어 사용하고, 입력을 바꾸고, 기능을 고치고, 다음 업무에서도 반복해서 쓴다는 대목이요.

다시 열고 고쳐 쓰는 물건은 문서가 아니라 프로그램입니다. 글 후반부에 붙은 단서, 고객 정보가 들어가면 어디에 저장되는지 살피고 여럿이 쓰면 누가 볼 수 있는지 확인하라는 말도 같은 사실을 가리켜요. 워드 파일을 만들면서 저장소와 열람 권한을 따지는 사람은 없잖아요. 그 확인 목록이 필요하다는 것 자체가 이미 오피스 도구의 영역을 벗어났다는 뜻입니다.

그래서 엑셀이 아니라 매크로

비유를 고쳐 쓰자면 저는 바이브 코딩이 엑셀보다 엑셀 매크로에 가깝다고 봐요. 매크로도 처음엔 한 사람이 자기 반복 작업을 덜려고 만듭니다. 잘 돌면 옆자리 동료가 쓰기 시작하고, 어느새 팀의 월말 마감이 그 파일 없이는 안 돌아가게 되죠. 그러다 만든 사람이 자리를 옮기면 아무도 손대지 못하는 파일이 남습니다. 업무 자동화를 해본 사람이라면 한 번쯤 지켜본 경로일 거예요.

바이브 코딩은 이 경로를 더 빨리, 더 멀리 갑니다. 매크로는 적어도 엑셀 안에 갇혀 있었지만, 바이브 코딩으로 만든 도구는 링크 하나로 회사 밖까지 나가고 고객 데이터를 품을 수도 있어요. 만든 사람이 코드를 읽지 않고 대화로만 고쳐왔다면, 그걸 고칠 수 있는 사람은 그 대화를 이어갈 수 있는 사람뿐이기도 하고요.

이 글의 예시는 왜 비유를 버텼나

공정하게 말하면, 글에 나온 두 예시는 엑셀 비유를 잘 버팁니다. 비즈니스 프로필은 고객에게 보내고 끝나는 문서예요. HTML이라는 형식을 빌렸을 뿐 다시 열어 고쳐 쓸 프로그램이 아닙니다. 홈페이지 패턴 도감은 반복해서 쓰는 도구지만 사용자가 만든 사람 한 명뿐이고, 회원가입도 결제도 없습니다. 혼자 쓰고, 망가지면 혼자 불편하고, 고칠 사람도 본인이죠.

비유가 깨지는 건 이 두 조건을 벗어날 때입니다. 결과물을 다른 사람이 쓰기 시작할 때, 그리고 내 것이 아닌 데이터가 들어갈 때. 글도 마지막에 이 둘을 짚긴 하지만 문단 하나짜리 단서로 붙였어요. 이건 단서가 아니라 기준이 돼야 합니다.

글이 제안한 다섯 가지 질문, 손이 멈추는 순간과 매번 다시 찾는 자료와 결과물을 쓰는 사람·장소, 달라지는 부분과 같은 부분, 확인 방법은 그대로 쓸 만합니다. 저는 그 앞에 하나를 더 두겠어요. 이건 보내고 끝나는 문서인가, 다시 열어 고칠 프로그램인가. 문서라면 엑셀처럼 가볍게 만들어도 됩니다. 프로그램이라면 매크로처럼 다뤄야 하고, 나 말고 누가 쓰게 될지와 내가 없을 때 누가 고칠지를 만들기 전에 정해둬야 합니다. 바이브 코딩의 문턱을 낮추자는 데는 찬성하지만, 그 뒤에 유지보수라는 두 번째 문턱이 있다는 것까지 같이 말해야 공정한 권유라고 봐요.