바이브 코딩에 관한 두 가지 지배적인 서사가 있다. 첫째는 한 문장만 쓰면 AI가 백만 달러짜리 앱을 내놓는다는 것이고, 둘째는 AI가 모든 코드를 작성하기 때문에 인간은 그 안에 무엇이 있는지 전혀 모른다는 것이다. 따라서 결국 실패하여 대규모 종말을 초래할 것이라는 이야기다.
이 두 서사 모두 현실을 과장한 캐리커처에 불과하다. 이전 글에서 나는 다양한 바이브 코딩 프로젝트에서의 작업에 대해 이야기한 바 있다. 우리는 그것들이 놀라우면서도 많은 작업이 필요하다는 점을 살펴보았다. 이 글에서는 코딩 통제권을 기계에 넘길 때 발생하는 유지보수와 지속 가능성 문제에 대해 깊이 파고들 것이다.
내가 젊은 프로덕트 매니저였을 때, 영업 부사장을 지원하기 위해 로스앤젤레스로 파견된 적이 있다. 그는 자신이 가장 좋아하는 레스토랑 중 한 곳으로 나를 데려가기로 했다. 이 레스토랑은 퓨전 요리를 전문으로 했는데, 셰프가 다양한 영향을 음식에 혼합했다. 셰프의 스페셜 메뉴로 유명했는데, 그날 저녁 셰프가 결정한 요리가 나왔다.
나는 내가 도대체 무슨 일에 휘말린 건지 궁금했다. 음식이 나올 거라는 건 알았지만, 무엇을 먹어야 할지 전혀 몰랐다. 알고 보니 그날 밤 우리가 먹은 음식은… 이상했다. 먹을 수는 있었다. 자발적으로 다시 가고 싶은 곳은 아니었다.
에이전틱 코딩은 그 레스토랑에 가는 것과 매우 비슷하다. 사용 중인 코딩 AI의 평판이 좋다는 것은 알지만, 실제로 무엇이 전달될지는 전혀 모른다. AI가 만든 실제 코드에 대한 통찰력이 거의 없다. 기본적으로, 무엇이 나오든 먹어야 한다.
에이전트가 코드를 작성할 때는 여러 계약자나 부하 직원이 코드를 작성하는 것과 같다. 테스트하고 평가하기 전까지는 무엇을 얻을지 전혀 알 수 없다.
모든 것은 프롬프트에 달려 있다. 쓰레기를 넣으면 쓰레기가 나온다는 말은 오래된 진부한 표현이 암시하는 것보다 훨씬 더 깊은 의미를 가진다. 충분히 명확하게 프롬프트를 작성하지 않고, 충분한 명확성과 감독으로 대화를 유지하지 않으면, AI가 반환하는 코드는 소화하기 어려울 것이다.
엔지니어링 관리자들은 피라미드 시대부터 자신이 감독하는 계약자를 관리하는 과제에 직면해 왔다. 작업을 할당하고 작업 결과물을 평가하는 것이 엔지니어링 관리자의 역할이다. 그 과정에서 품질과 통제를 유지하는 것은 소프트웨어 엔지니어링의 핵심이다.
반면, 바이브 코딩의 종말론이 과장된 면이 있긴 하지만, 진실도 있다. 품질 기준과 관행 없이는 문제가 있는 코드가 나올 수 있다. 이 글에서는 에이전틱 코딩을 둘러싼 신화와 AI가 요청한 대로 결과물을 제공하도록 돕는 모범 사례에 대해 논의할 것이다.
많은 AI 코딩 옹호자들은 AI에게 깊고 풍부한 요구사항 문서를 제공할 것을 권장한다. 그러나 내 경험상, AI는 그 깊은 문서의 단일 요소를 잘못 해석하여 추적하거나 찾을 수 없는 방식으로 완전히 엉뚱한 방향으로 갈 수 있다.
나는 AI에게 한 번에 하나의 간단한 작업을 주는 것을 선호한다. 그 작업이 성공적으로 완료되면, 다음 작업을 준다. 그렇게 하면 AI나 나 모두 전체 계획을 놓칠 기회가 줄어든다.
단독 개발자로서 나는 한 줄 한 줄 코드를 작성했다. 모든 줄에 땀을 흘렸다. 내 코드에 대해 모든 것을 알고 있었다. 그러나 엔지니어링 관리자였을 때는 내 팀과 팀의 개별 개발자에게 의존해야 했다.
물론 우리에게는 코더(대략 에이전트에 해당)가 있었다. 하지만 여전히 시스템에 테스트와 통합의 규율을 구축하여, 우리 코더나 계약자 중 누군가가 제출한 것이 다른 모든 것과 함께 작동하는지 확인해야 했다.
에이전틱 코딩을 사용하려면 똑같이 해야 한다. 모든 단계에서 체크포인트를 설정하고, 통합을 주의 깊게 추적하라. 외부 계약자로부터 인도받는다고 가정하고, 메인 프로젝트에 통합하기 전에 그들의 작업을 확인해야 한다.
내게는 소프트웨어를 공유하는 것이 두려운 친구가 있다.