최근 Heavybit의 High Leverage 팟캐스트에서 Joseph Ruscio와 AI 코딩 도구를 주제로 대화를 나눴다(Ep. #9, Simon Willison과 함께하는 AI 코딩 패러다임 전환). 이 글에서는 그 대화의 핵심 내용을 정리하면서, 내 작업 방식에서 바이브 코딩과 에이전틱 엔지니어링이 실제로 수렴하기 시작했다는 다소 불편한 깨달음도 함께 이야기한다.
팟캐스트가 좋은 이유 중 하나는, 말로 풀어내는 과정에서 그전까지 미처 언어화하지 못했던 생각이 불쑥 튀어나올 때가 있다는 것이다.
'바이브 코딩'이라는 말이 처음 등장하고 몇 주 뒤, 나는 AI 보조 프로그래밍이 전부 바이브 코딩은 아니다(그래도 바이브 코딩은 멋지다)라는 글을 썼다. 거기서 나는 바이브 코딩이 AI를 활용한 책임감 있는 코드 작성, 즉 내가 이후 에이전틱 엔지니어링이라 부르기 시작한 방식과는 본질적으로 다르다는 입장을 분명히 밝혔다.
그런데 Joseph이 두 개념의 차이를 꺼냈을 때, 나는 문득 깨달았다. 그 경계가 예전만큼 명확하지 않다는 것을.
이상하게도, 어느 순간부터 그 경계가 내 안에서 흐릿해지기 시작했다. 솔직히 꽤 당혹스럽다.
처음엔 구분이 아주 명확하다고 생각했다. 바이브 코딩은 코드를 전혀 들여다보지 않는 방식이다. 프로그래밍을 모르는 사람이 원하는 것을 말하고, 뭔가 결과물을 받아서, 작동하면 좋고, 안 되면 "이거 안 되는데요"라고 다시 말하고 될 때까지 기다리는 식이다.
코드 품질이나 여러 제약 조건에는 전혀 신경 쓰지 않는다. 내 생각엔 바이브 코딩은 그 자체로 훌륭한 방식이다. 단, 어디에 쓸 수 있고 어디에는 쓸 수 없는지를 제대로 이해할 때만 그렇다.
버그가 생겨도 나 혼자만 피해를 보는 개인 도구라면, 마음껏 써도 된다!
하지만 다른 사람을 위한 소프트웨어를 만든다면 이야기가 다르다. 바이브 코딩은 무책임한 선택이 된다. 다른 사람의 데이터가 걸려 있고, 허술한 버그로 피해를 입는 것도 그들이기 때문이다. 그보다 높은 수준의 접근이 필요하다.
에이전틱 엔지니어링은 이와 대조적이다. 여기서의 주체는 전문 소프트웨어 엔지니어다. 보안, 유지보수성, 운영, 성능 같은 요소를 이해하고, 자신의 역량을 최대한 발휘하면서 AI 도구를 활용한다. 나 역시 이 도구들의 도움으로 예전엔 엄두도 내기 힘든 규모의 문제를 다룰 수 있게 됐다.
그러면서도 25년간 쌓아온 소프트웨어 엔지니어로서의 경험에 여전히 기대고 있다.
목표는 높은 품질의 프로덕션 시스템을 만드는 것이다. 더 빨리 개발하면서 품질이 떨어진다면 그건 잘못된 방향이다. 나는 더 빨리, 그리고 더 좋게 만들고 싶다. 내가 만드는 모든 것이 이전보다 모든 면에서 나아지기를 바란다.
문제는 코딩 에이전트의 신뢰도가 높아지면서, 프로덕션 코드조차 한 줄 한 줄 검토하지 않게 됐다는 점이다.
Claude Code에게 SQL 쿼리를 실행해 결과를 JSON으로 반환하는 API 엔드포인트를 만들어 달라고 하면, 그냥 제대로 해낸다는 걸 나는 잘 알고 있다. 실수하지 않는다. 자동화 테스트를 추가하고, 문서도 작성하고, 결과물은 믿을 만하다.
그런데 나는 그 코드를 직접 검토하지 않는다. 그러면서 죄책감이 밀려온다. 코드를 검토하지 않았는데, 이걸 프로덕션에 쓰는 게 과연 책임감 있는 행동인가?
그럴 때마다 내가 엔지니어링 매니저로 일했던 때를 떠올리면 마음이 좀 편해진다. 다른 팀이 만든 소프트웨어에 우리 팀이 의존하는 상황이었다.
다른 팀에서 "이건 이미지 리사이즈 서비스인데, 이렇게 쓰면 됩니다"라고 넘겨주면, 나는 그 팀이 작성한 코드를 전부 읽으러 가지 않는다.
문서를 보고, 이미지를 몇 장 리사이즈해보고, 그 다음엔 내 작업을 이어간다. 이미지 리사이저에 버그가 있거나 성능에 문제가 생기면 그때 가서 그 팀의 저장소를 파고든다. 그 전까지는 웬만하면 들여다보지 않는 반(半)블랙박스로 취급한다.
에이전트도 점점 같은 방식으로 대하게 되고 있다. 그래도 여전히 불편한 건, 사람에게는 책임이 따른다는 사실 때문이다. 팀은 평판을 쌓아간다. "저 팀은 믿을 수 있어. 예전에도 좋은 소프트웨어를 만들었거든. 평판이 걸려 있으니 엉망으로 만들지는 않을 거야"라고 말할 수 있다.
Claude Code에겐 직업적 평판이 없다! 자신이 한 일에 책임을 질 수도 없다. 그런데도 어쩌면 스스로 신뢰를 증명해나가고 있다. 내가 원하는 스타일대로 단순한 작업들을 계속해서 정확하게 해내고 있으니까.
여기엔 일탈의 정상화(normalization of deviance) 요소가 있다. 에이전트가 내 면밀한 감시 없이도 올바른 코드를 내놓을 때마다, 나중에 엉뚱한 순간에 그것을 맹신했다가 낭패를 볼 위험이 조금씩 쌓여간다.
예전에는 커밋이 100개쯤 있고, 잘 정리된 README에 자동화 테스트까지 갖춘 GitHub 저장소를 보면, 그 사람이 프로젝트에 많은 공을 들였다는 걸 꽤 확신할 수 있었다.
지금은 30분이면 커밋 100개짜리 저장소에 멋진 README, 모든 코드 라인을 아우르는 포괄적인 테스트까지 뚝딱 만들어낼 수 있다. 겉으로 보면 공을 많이 들인 프로젝트와 구분이 가지 않는다. 실제로 그만큼 좋은 품질일 수도 있다. 나도 모르겠다. 보기만 해선 알 수가 없다. 내 자신의 프로젝트도 마찬가지다.
그래서 나는 테스트나 문서의 품질보다 더 중요하게 여기는 게 생겼다. 누군가가 실제로 그것을 써봤는가이다. 바이브 코딩으로 만든 것이라도 2주 동안 매일 직접 사용했다면, 막 뽑아놓고 거의 돌려보지도 않은 것보다 훨씬 가치 있다.
하루에 200줄 짜던 코드를 2,000줄씩 짤 수 있게 된다면, 무엇이 다음 병목이 될까? 생각해보면, 소프트웨어 개발 생명주기 전체가 하루에 수백 줄을 생산하는 데 적합하도록 설계되어 있었다. 그런데 이제 그 전제가 흔들리고 있다.
후단만의 문제가 아니라 전단도 마찬가지다. Anthropic의 디자인 리더 Jenny Wen이 한 강연에서 이런 이야기를 했다. 지금까지 디자인 프로세스가 그토록 철저했던 이유는 설계를 제대로 해야 했기 때문이라는 것이다. 엔지니어에게 넘겼는데 3개월을 엉뚱한 것에 쏟아부으면 그건 재앙이니까.
잘못된 설계가 값비싼 개발로 이어지기 때문에 정교한 프로세스가 필요했던 것이다. 그런데 구현에 3개월이 걸리지 않는다면, 실수했을 때의 비용이 크게 줄어드는 만큼 설계 프로세스도 훨씬 과감하게 바꿀 수 있다.
에이전트와 나누는 대화를 보면, 대다수의 사람에게 이건 그야말로 외계어처럼 느껴질 것이라는 게 분명하다.
컴퓨터가 스스로 코드를 짤 수 있게 됐다고 해서 내 커리어가 끝났다고 생각하지 않는 이유는 여러 가지인데, 그중 하나는 이 도구들이 기존 경험의 증폭기라는 점이다. 무엇을 하는지 알고 있다면 훨씬 빠르게 달릴 수 있다. [...]
이 도구들로 작업할 때마다 우리가 하는 일이 얼마나 어려운지 다시금 실감한다. 소프트웨어를 만드는 일은 몹시도 어렵다. 세상의 모든 AI 도구를 동원해도, 우리가 이루려는 것 자체는 여전히 정말 어렵다. [...]
정치 평론가 Matthew Yglesias가 어제 이런 글을 올렸다. "5개월 동안 써보고 결론을 냈다. 나는 직접 바이브 코딩을 하고 싶지 않다. AI 코딩 도구를 활용해서 더 많고, 더 좋고, 더 저렴한 소프트웨어 제품을 만들어 파는 전문 소프트웨어 기업들이 그 일을 해줬으면 한다." 나도 그 말이 맞다고 생각한다. 유튜브 영상을 충분히 보면 나도 집 배관 공사를 할 수 있겠지만, 그냥 배관공을 부르는 편이 낫다.
기업들이 SaaS 대신 자체 솔루션을 직접 구축하는 흐름이 SaaS 업체에 위협이 되는지에 대해서는:
이제 보니 아까 한 말과 같은 맥락이다. 나는 누군가의 사이드 프로젝트를 몇 주 동안 직접 써본 경우에만 쓰고 싶다고 했다. 기업 버전도 마찬가지다. 적어도 두 개 이상의 대형 기업이 6개월 이상 성공적으로 사용한 CRM이어야 도입을 고려한다. [...] 리스크를 감수하기 전에 검증된 솔루션을 원하는 것이다.
현재 블로그의 장문 아티클만 표시되고 있습니다. 모든 포스트를 받아보려면 /atom/everything/을 구독하거나, 다른 구독 옵션을 확인해보세요.