바이브 코딩의 변하지 않는 단 두 가지 원칙
원칙1. 작성자는 PM의 애티튜드.
원칙2. 에이전트를 도구가 아닌 동료를 대하듯.
지난 2년간 바이브 코딩을 하면서 수많은 모델과 방법론이 등장했다. 예를 들어 프롬프트 엔지니어링부터 최근의 하네스 엔지니어링까지, 그 흐름은 꽤 빠르게 변화해왔다. 그에 따라 다양한 스킬과 협업 방식들도 계속해서 생겨나고 있다.
그런데 이 모든 변화를 한 걸음 떨어져 바라보면, 결국 사람이 프로젝트를 위해 해오던 일들의 연장선이라는 걸 알 수 있다. 최근 주목받는 하네스 엔지니어링 역시 본질적으로는 에이전트와의 커뮤니케이션 방법론이다. 형태는 지금까지 그래왔듯 앞으로도 계속 바뀔 것이다.
그래서 ‘원칙1’을 이렇게 정의해봤다. 작성자는 ‘PM의 애티튜드’를 가져야 한다.
PM은 기존 팀원뿐만 아니라 새로 합류하는 팀원, 그리고 각 파트의 구성원들이 가진 성향과 커뮤니케이션 방식을 이해하고 존중해야 한다. 프로젝트 도중 팀원이 바뀌는 일도 흔하다. 때로는 더 뛰어난 인력이 들어오기도 하고, 그렇지 않은 경우도 있다.
개인적으로 Claude Code와 OpenAI Codex를 함께 사용하고 있는데, 그 사이에서도 다양한 기능과 방법론이 계속 추가되고 있다. 마치 프로젝트 중간에 팀원이 바뀌거나 추가되는 것과 비슷한 느낌이다.
이때 현실에서 중요한 것은 흔들리지 않는 뼈대다. 지속적으로 업데이트되는 기획 문서와 DevOps 구조. 바이브 코딩도 다르지 않다. 결국 지속적인 관리의 문제일 뿐이다.
현실에서와 같은 방식으로 진행하려면 ‘원칙2’, 즉 ‘에이전트를 도구가 아닌 동료로 대해야 한다’는 생각에 도달하게 된다. 에이전트와의 협업을 사람과의 협업과 구분하지 않고 같은 결로 대하면, 사실 크게 달라질 것은 없다. 아니, “달라지더라도 크게 문제 되지 않는다.”
현실에서도 팀원이 바뀐다고 해서 프로젝트 관리 방식이 완전히 뒤집히지는 않는다. 프로젝트는 계속되어야 하기 때문이다. 이런 관점은 비단 바이브 코딩에만 해당되는 이야기는 아니다.
보너스.
종종 “에이전트가 너무 멍청하다”는 말을 듣는다. 하지만 대부분은 넌센스에 가깝다.
불과 1년 전 기준으로만 봐도 Claude나 Codex 같은 에이전트는 평균적으로 사람보다 더 깊고 넓은 전문 지식을 갖고 있는 경우가 많다. 문제는 성능이 아니라, 커뮤니케이션이다.
이건 현실에서도 익숙한 장면이다. 준비되지 않은 PM이 유능한 팀원과 “말이 안 통한다”고 느끼는 상황과 크게 다르지 않다. 최근에는 특정 분야에서 PM보다 더 전문적인 팀원들이 점점 많아지고 있다. 협업자들의 재학습 속도가 새로운 기술의 등장과 생산성 도구의 발전 속도를 따라잡지 못하기 때문이다. 어쩌면 매우 자연스러운 흐름이다. 물론 PM이 ‘스승님’처럼 지식을 전파하는 위계적인 조직도 존재한다(도망쳐!!). 하지만 HR이 제대로 작동하는 조직이라면, 단순히 연차나 나이, 학위만으로 PM을 세우지는 않는다.(물론 그런 곳도 있겠지만… 역시 도망쳐!!)
그런 의미에서, 바이브 코딩을 하는 개인이라면 에이전트를 도구가 아닌 동료로 대하며 협업하고, 그 과정을 PM의 애티튜드로 운영해보기를 권장한다.
구체적인 방법.
기술 트렌드나 키워드 같은 '최근 동향'은 유튜브나 SNS로 가볍게 확인하고, '학습과 자기개발'은 PM, PO 관련 책을 읽거나 사이드 프로젝트를 통해 경험을 쌓는 것을 추천한다. 특히 사람과 에이전트를 반씩 섞어 협업해보는 방식이 좋다.
