Vibe Coding: Vibe를 타도 좋은 부분과 그렇지 않은 부분

Vibe(바이브)라는 단어에는 묘한 매력이 있습니다.

효율이 좋아 보이고, 편해 보이며, 게다가 미래적인 느낌이 납니다.

노력하지 않아도 된다. 배우지 않아도 된다. 지름길을 통해 올드 타입의 「프로그래머 (Programmer)」를 단번에 앞지를 수 있다.

그런 울림이 있습니다.

그렇다면 실제로는 어떨까요?

부분적으로는 그렇지만, 그렇지 않은 부분도 있습니다.

단 몇 줄의 지시만으로 AI가 중규모 이상의 프로젝트를 완벽하게 만들어낸다. 인간은 일절 감독할 필요가 없다.

언젠가는 그렇게 될지도 모릅니다. 하지만 적어도 지금은 아직 거기까지 오지 않았습니다. 아마 내일도 아직은 무리일 것입니다.

우리는 오늘의 기술로, 오늘의 프로덕트 (Product)를 만들어야 합니다.

그렇기에 어디를 Vibe Coding (바이브 코딩)에 맡겨도 괜찮고, 어디를 스스로 쥐고 있어야 하는지를 판별할 필요가 있습니다.

AI의 진화는 지금까지 몇 번이고 인간의 예상을 뒤엎어 왔습니다.

프로그래머가 가장 먼저 대체될 것이라고 생각되던 시기도 있었지만, 실제로는 기사, 화가, 작가의 영역이 먼저 침식되었습니다.

그렇기 때문에, 저는 「AI가 내가 살아있는 동안 프로그래머를 완전히 대체할 것」이라고 단정 지으며 커리어 (Career)를 생각할 생각은 없습니다.

애초에, 설령 정말로 그날이 온다 하더라도 특별한 준비가 필요하다고는 생각하지 않습니다.

프로그래머를 완전히 대체할 수 있는 AI가 수중에 있다면, 이쪽은 원하는 것을 전달하기만 하면 될 것입니다. 나머지는 AI가 만들어 줄 테니까요.

그 정도 단계에 이르렀다면 준비도 아무것도 없습니다.

다만, 그런 강력한 AI가 일반 사용자에게 가볍게 개방될 것이라고도 생각하지 않습니다. 지금조차 우리는 Claude Mythos에조차 닿을 수 없으니까요.

이야기가 조금 옆으로 샜습니다.

저는 업무에서도 개인 개발에서도 AI 에이전트 (AI Agent)를 상당히 많이 사용하고 있습니다.

최근에는 Neovim을 여는 기회도 상당히 줄었습니다.

긴 시간을 들여 만들어 놓은 설정도, 몸에 익힌 단축키도 이전만큼 쓰임새가 없습니다.

하지만 업무에서는 Vibe Coding을 거의 하지 않습니다.

AI 에이전트, 주로 Claude Code와 대화하면서 이쪽이 주도권을 가지고 코드를 작성하게 합니다.

AI가 작성한 코드에서 뜻밖의 힌트를 얻기도 하고, 반대로 이쪽이 오류를 수정하기도 합니다.

이러한 형태는 상당히 긍정적인 변화라고 느끼고 있습니다. 저는 이전보다 더 좋은 코드를 작성할 수 있게, 아니, 산출할 수 있게 되었습니다.

업무의 속도와 품질도 올라갔습니다.

다만, 한계 없이 무한히 돌파할 수 있었던 것은 아닙니다. 결국 병목 (Bottleneck)은 저였습니다. 인간은 느립니다.

그럼에도 효율을 위해 컨트롤 (Control)을 놓을 생각은 없습니다.

왜냐하면 무섭기 때문입니다.

AI의 불확실성이 중대한 장애로서 운영 환경 (Production Environment)에 들어갈지도 모른다.

그것이 무섭습니다.

제가 참여하고 있는 프로젝트에는 신뢰할 수 있는 테스트 (Test)가 있습니다. 하지만 매우 중요하며, 사용 기간 중에 장애가 발생하면 큰 손실로 이어지는 시스템이기도 합니다.

저는 안심하고 잠들고 싶습니다.

그렇기에 운영 환경에 내보내는 코드는 스스로 자신이 확신을 가진 것이어야만 합니다.

반면, 개인 개발에서는 상당히 자유롭게 시도할 수 있습니다.

실제로 저는 여러 프로젝트를 Vibe Coding으로 만들었습니다.

결과는 생각보다 좋았고, 조금 큰 프로젝트라도 나름대로 잘 돌아갔습니다.

다만, 「나름대로 돌아가는 것」으로 정말 충분할까요?

수백 줄 정도의 작은 도구라면 Vibe Coding은 상당히 합리적입니다.

오히려 구현의 세부 사항을 일일이 읽는 것이 시간 낭비일지도 모릅니다.

그렇다면 수천 줄을 넘는 중규모 이상의 프로젝트는 어떨까요?

작은 도구에서는 신경 쓰이지 않았던 문제가 갑자기 무시할 수 없는 크기로 다가옵니다.

프로그래밍 세계에서는 「은탄환은 없다 (No Silver Bullet)」라는 말이 잘 알려져 있습니다.

이 말에 이의를 제기하는 사람은 적을 것입니다.

언어, 프레임워크 (Framework), 설계 방침, 나아가 if 문을 쓰는 방식 하나를 보더라도 정답은 하나가 아닙니다.

이 지점이 Vibe Coding의 어려운 부분입니다.

AI는 완벽한 코드를 작성할 수 없습니다.

애초에 완벽한 코드란 존재하지 않기 때문입니다.

프로젝트가 커지고 복잡해질수록 AI가 한 번에 훑어볼 수 있는 범위는 상대적으로 좁아집니다.

작은 프로젝트처럼 매번 모든 파일을 읽게 할 수는 없습니다.

AI는 확실히 우수합니다.

하지만 부분 최적화가 전체 최적화와 반드시 일치하는 것은 아닙니다.

국소적으로는 옳은 판단이 프로젝트 전체에 있어서는 반드시 옳다는 보장이 없습니다.

그 지점에 문제가 있습니다.

설계 (Design) 레벨의 작은 왜곡이 AI의 손을 거쳐 놀라운 속도로 증폭됩니다.

구조를 조금만 바꾸면 쉽게 해결할 수 있는 문제임에도, AI는 눈앞의 목적을 효율적으로 달성하기 위해 패치 (Patch)를 계속해서 덧붙이는 경우가 있습니다.

그 순간에는 작동합니다.

테스트 (Test)도 통과할지 모릅니다.

하지만 그 수정은 다음 개발을 조금씩 어렵게 만듭니다.

머지않아 코드의 복잡성 (Complexity)이 AI 스스로도 감당할 수 없을 정도로 부풀어 올랐을 때, 막다른 길에 다다르게 됩니다.

AI는 너무나 효율적입니다.

완전히 망가지기 직전까지는 아무런 문제가 없는 것처럼 일이 진행될 것입니다.

물론 인간도 완벽한 코드 따위는 쓸 수 없습니다.

우리는 언제나 과거의 자신이 내린 판단 때문에 고통받습니다.

그럼에도 인간에게는 경험과 직관이 있습니다.

그 경험과 직관이야말로 AI의 약점을 보완할 수 있는 힘입니다.

프로젝트의 구조가 건전한지 확인하는 것.

설계의 방향이 파탄 나지 않았는지 판단하는 것.

그것은 아직 인간이 담당해야 할 업무입니다.

물론 인간도 실수합니다.

다만 그럴 때 AI가 도와줄 것입니다.

AI 에이전트 (AI Agent)가 가져다준 큰 혜택 중 하나는 리팩터링 (Refactoring) 비용을 극적으로 낮췄다는 점입니다.

개발 도중에 설계 실수를 깨달았을 때, 수정에는 막대한 작업량이 따릅니다.

그 작업량 때문에 우리는 몇 번이고 타협해 왔습니다.

디렉터리 (Directory) 구성을 처음에 제대로 나누지 못했다.

네임스페이스 (Namespace) 분할을 잘못했다.

하지만 이제 와서 옮기자니 방대한 양의 임포트 (Import)를 수정해야 한다.

그렇게 코드는 잘못된 위치에 그대로 남겨지게 됩니다.

하지만 지금은 다릅니다.

한마디 지시만 하면 AI 에이전트는 묵묵히 리팩터링을 수행해 줍니다.

그렇기에 현시점에서 가장 현실적인 방법은 인간과 AI를 조합한 「선택적 Vibe Coding」이라고 생각합니다.

인간이 전체를 보고 어디를 AI에게 맡길지, 그리고 어디를 스스로 판단해야 할지를 결정하는 것입니다.

어떤 부분에서는 함수의 내부 내용까지 읽을 필요가 없을지도 모릅니다.

다만 함수의 시그니처 (Signature)는 파악해 두어야 할 것입니다.

또 다른 부분에서는 구현의 세부 사항을 쫓지 않아도 될지도 모릅니다.

다만 클래스 설계 (Class Design) 전체가 타당한지는 살펴봐야 할 것입니다.

어디에서 자신의 판단이 필요할 것인가.

그 자체를 판단해야 합니다.

그렇지 않다면 그것은 개발이 아니라 그저 AI로 놀고 있는 것에 불과합니다.

AI가 전부 알아서 잘해주기를 기도하는, 단순한 가챠 (Gacha)가 되어버립니다.

AI가 완전 자동(Full-auto)으로 해결할 수 없는 상황에서도 안심하고 나아가고 싶다면.

몇 달 후에도 프로젝트를 무리 없이 앞으로 진행할 수 있는 상태로 유지하고 싶다면.

선택의 여지는 없습니다.

지금의 정답은 선택적인 Vibe Coding입니다.

물론 Vibe Coding만으로 대규모 프로젝트를 안정적으로 다룰 수 있다는 것이 증명된다면, 저는 망설임 없이 생각을 바꿀 것입니다.

상황을 보고 입장을 바꿀 수 있는 것 또한 엔지니어에게 필요한 능력입니다.