Vibe coding에 잠식되어 살다 느꼈던 피로에 대한 반쪽짜리 해답을 되짚어보며, 그 김에 기존에 하고 있던 생각들을 함께 정리함.
Vibe Coding Fatigue
Vibe coding은 처음 소개되었을 때부터 개발자들의 생산성을 폭발적으로 향상시켜준다고 믿어져왔고, 지금도 그렇다. 하지만 내가 체감하는 생산성 향상의 정도는 도구가 생산해내는 코드의 양과 비교하면 매우 부족하다. 많은 개발자들이 이 단계를 겪었을 것이라고 생각하는데, 나는 한참 동안 이 도구가 왜 이전과 비교하여 내가 생산하는 작업물의 양과 질을 크게 향상시켜주지 못하는지에 대해 스트레스를 받았었다.
실제로 내가 작업하는 방식을 뜯어보면, 코드 작성에 쓰는 시간이 획기적으로 줄어들었다는 것은 자명했다. 템플리팅, 공통 코드 추상화 등 아무리 도구가 숙련되어도 몇백 줄짜리 변경사항을 만드는 것은 최소 분 단위 작업이 들어갔어야 하는데 이제는 몇 초 안에 몇천 줄의 변경사항을 거의 완벽하게 만들 수 있다. 그렇다면 문제가 코드 작성이 아닌 다른 곳에 있다는 점이 명백하다.
코딩에 시간을 쓰지 않는 개발자에게 남은 작업은 결국 설계와 결과물 검토밖에 없다. agent가 내가 할 일을 대신하는동안 나는 다른 제품, 다른 기능의 설계를 쓰거나 다른 agent가 작성 완료한 결과물들을 리뷰하는 것을 끝없이 반복한다. 작업에서 오는 효용이 없는 상태에서 검토해야 할 작업의 양과 맥락이 폭발적으로 늘어나면서 피로가 누적되기 시작한다. 이 시점의 나는 마치 똑똑하지만 일머리 없는 인턴 여럿을 마이크로매니징하는 개발자처럼 일하고 있다.
검토의 인지 부하
요구사항과 명세를 잘 만드는 것이 문제의 한 축이라면 다른 축은 리뷰, 즉 검토의 문제이다. 코드가 생성되는 속도가 이전에 비해 비약적으로 빨라진 것이 검토의 질을 낮추고 검토자의 피로를 유발한다. 기존에 진행된 인간이 작성한 코드에 대한 연구들에 의하면 주요 코드에 대한 변경사항 400줄 정도가 검토자에게 적절한 난이도로 다가오고, 1000줄 이상의 변경은 검토자에게 인지 부하를 유발하며 결과적으로 검토된 결과물의 질도 떨어지게 된다는 것이 여러 연구를 통해 뒷받침된다. 그런데 지금은 plan 세션 한 번당 기본적으로 1000줄 이상의 코드를 작성하는 것이 일반적인 일이 되었다.
이전과 검토의 난이도가 다르게 느껴지는 또 다른 이유는 vibe coding으로 작성한 코드는 내가 작성한 코드처럼 쓰이지만 실제로 내가 생각해서 작성한 적이 없는 코드이기 때문이다. 아무리 입력으로 주어진 명세가 상세하고 스스로의 인지를 해치지 않는 선에서 빼곡히 작성되었다고 하더라도 생성된 코드에 낮선 로직이 등장하는 부분들이 있고, 이 부분들을 발견하고 검토할 때 인지 부하를 소모하게 된다.
결과적으로 같은 작업 단위를 완수하는데 들어가는 시간은 비슷하거나 종종 눈에 띄게 줄어들기도 하지만, 소모하는 인지부하는 최소 비슷한 수준에 머물러있거나 체감상 더 크게 늘어난다. 늘어난 생산성에 맞춰 병렬 작업이 잦아지고 많은 맥락을 동시에 다루려고 하다보면 맥락 전환에서 오는 인지 부하까지 합쳐져 개발자는 인지 부하 관점에서 기존 대비 몇 배의 과부하를 받게 된다. 결국 이 부하를 관리 가능한 수준으로 낮추려면 생산성은 어느 수준 이하에 머무를 수밖에 없다.
코드를 읽지 않을 결단
개발자로 일한다는 것은 단순히 코드를 작성해서 결과물을 만드는 것에서 끝나는 것이 아니라 자신이 작성한 코드에 대한 책임을 지는 것이다. 코드를 읽지 않고 배포한다는 것은 이 원칙에 정면으로 배치되는 행위이기 때문에 나에겐 금기에 가까운 행위였다. 그런데 OpenClaw 개발자를 시작으로 자신이 코드를 읽지 않고 배포한다는 사실을 당당하게 선언하는 개발자들이 늘어나기 시작해, 공공 공간에서는 사실상 대세처럼 자리잡았다. 1인 개발자가 대다수를 차지하는 공간임을 감안해야겠지만, 직관에 정면으로 배치되는 패러다임이 대세처럼 번지는게 두려웠다.
그래서 최근 아무 아이디어나 잡고 vibe coding으로 완성시켜보자는 생각으로 토이 프로젝트를 시작했다. 작업은 여러 세션에 각자 다른 요구사항들을 던져넣어서 진행됐다. plan 세션이 적극적으로 활용되었지만, agent가 세운 계획을 검토하지 않고 승인했다. 각 agent가 작성한 코드는 따로 커밋되었지만 별도로 리뷰되지 않았다. 가능하면 agent가 직접 요구사항 충족을 확인할 수 있는 방향으로 설계 후 검증해달라고 요청했고, 검증 또한 거의 전적으로 agent에게 위임했다. 최종 검토는 결과물의 완성도를 보고 평가했다.
이 접근법으로 꽤나 맘에 드는 토이 프로젝트를 서너개 완성하고 나서 첫 번째로 든 생각은 이전에 잃어버렸던 코딩에 대한 즐거움을 찾은 것 같은 감정을 느꼈던 것이었다. 검토의 인지 부하에서 해방되자 내가 해야 할 일은 좋은 요구사항을 적당한 단위로 나눠 작성하는 것밖에 없었고, 좀더 단순화해서 생각하면 머릿속의 아이디어를 다듬어서 끄집어내는 것이 전부였다. 그러면 코드로 구현할 수 있는 것들은 거의 대부분 배포 완료 단계의 결과물을 얻을 수 있었다.
아마도 내가 되찾은 것은 코딩이 주던 여러 즐거움 중 하나인 결과물 완성의 즐거움이었을 것이고, 다만 이전의 접근법으로는 소모하는 인지 부하 대비 결과물의 아쉬움, 속도에 대한 아쉬움이 회고의 대부분을 차지했기 때문에 느끼지 못했을 것이다. 이 시점의 나는 인턴들을 전적으로 신뢰하고 작업을 위임하며 작업물에 대한 검토는 전혀 하지 않는 엔지니어링 관리자처럼 일하고 있다.
코드를 읽지 않거나, 전부 읽거나
내가 코드를 읽지 않는 방식으로 즐거움을 되찾았다고 해서 앞으로 이 방식이 지속 가능하다고 생각하지는 않는다. 검토되지 않은 작업물이 리스크라는 점은 예전이나 지금이나 똑같고, 예전에도 사람이 작성한 코드를 아무리 신뢰해도 동료 평가 과정이 있었던 이유이기도 하다. 이미 vibe coding으로 작성되어 검토되지 않은 채 실행되어 조직과 사용자들에게 피해를 끼친 사례들이 다수 발생했다. 나 또한 내가 검토하지 않은 방식으로 완성한 작업물을 절대 개방하거나 타인이 사용할 때 안전에 대한 책임을 담보할 수 없을 것이다.
직접 두 가지 방식을 사용해보고 느낀 점은, 검토를 어느 순간 놓친, 혹은 놓아야겠다고 생각한 때부터 그 이후로 작성된 코드는 전부 검토되지 않은 코드가 된다. agent가 검토되지 않은 코드 기반으로 새로운 코드를 생산하고, 그렇게 작성된 코드를 검토하기 위해서는 이전에 검토하지 않았던 코드가 왜 그렇게 작성되었는지를 이해해야 한다. 결국 검토에는 중간이 없이, 모든 코드를 읽거나 혹은 아무 코드도 읽지 않는 선택지밖에 존재하지 않는다. 검토를 하기로 결심했다면, 최소한 해당 작업물이 영향을 미치는 범위 내의 코드는 전부 읽고 이해해야 한다.
다시 개발자의 본질로 돌아가 자신이 작성한 코드에 대해 책임을 질 수 있으면서도 높은 생산성을 유지하기 위해서는 결국 코드를 모두 읽되, 효율적이고 생산적으로 읽을 방법에 대해 계속 고민하고 탐구할 수밖에 없다고 생각한다. 긍정적인 점은 이 부분 또한 AI의 도움을 받을 수 있는 여지가 아주 많다는 것이다. 먼저 검토의 입력인 코드 작성 측면에서는 많은 레퍼런스 코드를 읽고 참조할 맥락이 잘 관리되어 세션에 주입될 수록 작성된 코드가 기존의 코드 스타일에서 벗어나는 일이 적어지고 따라서 읽을 때 소모하는 인지 부하도 낮아진다.
또 하나는 AI의 도움을 받아 코드에서 핵심적으로 읽어야 할 부분들을 식별해냄으로써 이전보다 훨씬 빠르게 코드를 읽을 수 있게 되었다는 것이다. 1000줄짜리 변경사항을 읽을 때 사람은 먼저 1000줄을 모두 읽고 핵심 변경사항이 무엇인지 식별해야 하는데, AI는 이 앞 과정을 앞당겨 핵심적으로 읽어야 할 코드와 간단한 검토가 필요한 코드를 식별하는데 도움을 줄 수 있다.
결국 내가 목표해야 할 지향점은 마이크로매니저도, 전부 위임 매니저도 아닌, 자신의 작업물에 책임을 질 수 있는 매니저가 되는 것이라고 생각한다. 완전히 새로워진 워크플로우가 주어진 상황에서 본질을 잃지 않으면서도 즐겁게 일하기 위해서는 이런 메타인지를 하는 과정이 꼭 필요하다고 느꼈다.