제목을 보고 분노하기를 바란다. 화내라. 책상을 쾅 내려치고 고개를 절레절레 흔들어라. 그리고 진지하게 받아들여라. 바이브 코딩(Vibe Coding)을 배워야 한다. 그렇지 않으면 소프트웨어 개발자 커리어는 끝난다.

바이브 코딩은 최신 세대의 코드 생성 툴, 즉 LLM(흔히 말하는 챗GPT)을 활용하는 방식을 귀엽게 부르는 말이다. 커서(Cursor), 코드라인(Codeline), 탭나인(Tabnine) 같은 수많은 툴이 있는데, 솔직히 말해 전부 별로다. 이제 여기에 이 분야의 원조 격인 깃허브 코파일럿(GitHub Copilot)까지 본격적으로 가세하고 있다. 대부분은 비주얼 스튜디오 코드(Visual Studio Code)의 파생 버전이거나 플러그인 형태다.

게임 개발 경험이 전혀 없는 사람이 GPT로 게임 하나를 뚝딱 만들어서 대통령이 트위터에 올리고, 그걸로 백만장자가 되는 일이 가능하다는 말은 아니다. (사실 그보다 더 황당한 일이 실제로 벌어지기는 했다.) 생성형 AI 코딩 툴이 훌륭하다는 얘기를 하려는 것도 아니다. 오히려 더 엉망이고, 보안 취약점이 더 많은 코드를 낼 가능성이 크다. 여기서 말하려는 건 단 하나다. 이런 툴을 배우지 않으면, 곧 업계에서 은퇴할 준비를 해야 할 거라는 점이다.

어디서 들어본 이야기

뻔한 이야기다. 이런 일은 예전에도 있었다. 커리어 초장기에 필자는 한 개발자를 만났다. 편의상 톰이라고 부른다. 톰은 전형적인 구세대 개발자였다. 키보드를 눈으로 보며 타자 치는 식의 ‘독수리 타법’으로 프로그래밍을 하던 사람이었다. 톰은 비주얼 베이직(Visual Basic)으로 보고서 하나 만드는 데 6개월이 걸렸다. 예전에는 어떤 언어를 썼는지는 모르겠지만, VB는 책을 통해 독학했다고 했다. 톰이 휴가를 간 동안, 원래는 둘이 함께하기로 했던 보고서를 10일 정도 만에 끝냈다. 일부러 톰이 할 부분은 남겨뒀는데, 그때부터 톰은 나를 싫어했다.

어떻게 그렇게 빨리 해냈느냐고? IDE를 활용했고 인터넷 검색을 했다(이때는 ‘구글링하다’라는 말이 없던 시기였다). 우리가 자바로 전환했을 때 필자는 인터넷에서 자바를 일주일 만에 익혔고 동시에 J빌더(JBuilder) 사용법도 배웠다. 반면 톰은 브루스 에켈의 『씽킹 인 자바(Thinking in Java)』 책을 사서 여전히 독수리 타법으로 쿵쾅대며 타이핑하고 마치 성경이라도 되는 듯 그 책에 의존했다. 톰은 새로운 방식으로 배우고자 하지 않았다. 세상이 바뀌는 걸 비난하면서 낡은 방식에 머무르고 싶어 했을 뿐이었다.

현재 링크드인에는 두 부류의 사람이 있다. 1년 전까지만 해도 웹3를 외치던 사람이 지금은 바이브 코딩에 대해 과장된 주장을 늘어놓는다. 그리고 또 한 부류는 ‘톰들’이다. 보안이 어쩌니, 코딩은 예술이니 하면서 온갖 불평을 늘어놓는 사람들이다. 만약 당신이 톰이라면, 이제 퇴직 알람을 맞춰야 할 때다. 새로운 방식으로 일하는 법을 배우는 것은 개발자라는 직업의 일부다.

비즈니스 소프트웨어를 만드는 개발자는 예술가도 아니고 코드 시인도 아니다. “소프트웨어 장인 정신” 같은 건 아무도 신경 쓰지 않는다. 상사의 말이 맞다. 새로운 방식을 배우고 더 빠르게 코딩해야 한다. 그게 아니면, 키보드 좀 잘 두드릴 줄 알고 구글 검색 하나 잘하는 20대를 만난 뒤 결국 은퇴를 택했던 톰이 된다. 그게 전부다. 바이브 코딩을 하든가, 은퇴하든가.

LLM이 정말 그렇게 대단하냐고? 그렇다. 완전한 애플리케이션을 생성할 수 있냐고? 그렇다. 결과물이 형편없을 거냐고? 그건 사용자의 실력에 달렸다. LLM은 만병통치약이 아니다. “코딩 없이도 할 수 있다”라는 새로운 세대의 구호는 사실 이전 세대의 “코딩 없이도 할 수 있다”라는 말과 전혀 다르지 않다. 단순한 것만 하려면 정말 코딩 없이도 되기는 한다. 하지만 버전 2.0이 필요하거나 복잡한 뭔가를 만들려면 결국 코딩이 필요하다. 예전과 똑같다. 달라진 건 단 하나, 코딩 툴의 속도와 품질이 더 좋아졌다는 점뿐이다.

시간이 필요하다

바이브 코딩 툴을 처음 써서 만든 애플리케이션은 형편없을 것이다. 툴이 무척 답답할 것이고 스스로 잘 활용하지 못한다고 느낄 것이다. 하지만 그건 도구 탓이 아니라 사용자 탓이다. 이런 툴은 아직 성숙도나 안정성 면에서 J빌더, (아마 이 정도까진 아니겠지만) 비주얼 베이직 4.2, 자바스크립트 1.0 수준이다. 사용하다 보면 이상한 동작을 해서 짜증이 나고 당장이라도 때려치우고 싶어질 수도 있다. 하지만 점점 적응하고 이런 툴과 함께 일하는 방법을 익히면 점점 속도가 붙기 시작한다.

코딩을 조금이라도 할 줄 아는 사람이라면 이런 툴은 처음 구조를 잡는 단계 이후부터는 오히려 속도를 늦출 수 있다. 툴이 내리는 이상한 결정에 고개를 절레절레 젓게 되겠지만, 결국에는 이 툴을 원하는 대로 사용하는 방법을 배우게 된다. 지금까지 새로운 개발 툴이나 기술을 배울 때 항상 그랬던 것처럼 말이다.

일단 요령이 생기면 새로운 역량을 얻게 된다. 필자 역시 코딩은 할 줄 알지만, 자바스크립트를 제대로 배워야겠다고 생각한 적은 별로 없었다. 그런데도 최근에 제법 복잡하고 방대한 자바스크립트 애플리케이션을 3주도 안 돼서 완성했다. 물론 생성형 AI 없이도 언젠가는 다 했을 일이다. 하지만 필요한 API를 일일이 검색하고 확장 포인트를 익히는 데는 시간이 꽤 걸렸을 것이다. 심지어 지금보다 훨씬 괜찮았던 시절의 구글링을 한다 해도 말이다. 필자가 바이브 코딩으로 완성한 결과물은 예전 같으면 석 달은 걸렸을 작업이었다. AI 덕분에 생산성이 10배 증가한 건 아니지만, 평소보다 작업 속도가 5배는 빨라졌다.

다가올 바이브 코딩 시대, 살아남고 싶다면 지금부터 준비해야 한다. 다음은 실전에 바로 쓸 수 있는 몇 가지 팁이다.

• 우선 커서, 코드라인 같은 툴의 무료 버전부터 시작하라. 뭐든 상관없다. 그리고 곧바로 최소 40달러는 지불하라. 코드가 그려지는 걸 멍하니 보고만 있어선 실력이 늘지 않는다.
• “시간만 있었으면 만들었을” 프로젝트를 골라라. 예를 들어, 줌 녹화 저장 문제를 스스로 해결했던 어떤 사람처럼 말이다.
• 깃(Git)을 자주 사용하라. AI 코딩 툴은 종종 어이없는 짓을 종종 저지른다. 복구하려면 버전 관리에 익숙해야 한다.
• 본격적으로 코딩을 시작하기 전에 LLM과 설계 대화를 나눠라. 결과를 마크다운 형식으로 받아두면 좋다. 대부분의 바이브 코딩 IDE는 이 마크다운을 지침 설정에 넣을 수 있다. 모델에게 같은 설명을 반복하지 않아도 된다. 혹시 까먹으면 다시 넣어주면 된다.
• 매 단계마다 결과를 검토하고 모델이 엉뚱한 짓을 하면 과감히 되돌려라.
• 답답해도 버텨라. 써먹을 줄 알게 되면 이런 툴은 무기가 된다.
• 지금 시점에서는 클로드 3.7 소넷(Claude 3.7 Sonnet)이나 제미나이 2.5 프로(Gemini 2.5 Pro) 혹은 실험 버전(Gemini 2.5 Experimental)이 가장 쓸 만하다.

바이브 코딩은 곧 현실이 된다. 개발자는 앞으로 이렇게 코딩할 것이다. 지금 배우기 시작하라. 아니면 은퇴 준비를 하라.
dl-itworldkorea@foundryco.com