Vibe coding과 agentic engineering이 내가 원하는 것보다 더 가까워지고 있다

• vibe coding과 agentic engineering은 원래 코드 검토와 책임성 기준으로 구분됐지만, 코딩 에이전트의 신뢰도가 높아지면서 실제 프로덕션 작업에서 경계가 흐려지고 있음
• vibe coding은 코드를 거의 보지 않고 원하는 결과가 나오면 받아들이는 방식이라 개인 도구에는 유용할 수 있지만, 다른 사람의 정보와 사용 경험이 걸린 소프트웨어에는 무책임한 방식으로 보임
• Claude Code 같은 에이전트가 JSON API 엔드포인트, SQL 쿼리, 테스트, 문서화를 반복적으로 잘 처리하면서 생성된 모든 코드 줄을 검토하지 않는 일이 생기고, 이는 사람 팀과 달리 평판이나 책임이 없는 대상에 대한 신뢰라는 위험을 만듦
• 이제는 커밋 100개, 좋은 README, 전체 테스트가 있는 저장소도 30분 만에 만들 수 있어 겉모습만으로 품질을 판단하기 어려워졌고, 실제 기준은 누군가 그 소프트웨어를 꾸준히 사용했는지가 됨
• AI 도구는 소프트웨어 엔지니어의 경험을 대체하기보다 증폭하며, 코드 생산 속도가 하루 200줄에서 2,000줄로 늘면 병목은 설계, 검증, 운영, 실제 사용으로 이동함

Vibe coding과 agentic engineering의 경계

• Heavybit High Leverage 팟캐스트 Ep. #9에서 AI 코딩 도구를 다루며, vibe coding과 agentic engineering이 실제 작업에서 서로 더 가까워지고 있다고 보게 됨
• 이전에는 Not all AI-assisted programming is vibe coding (but vibe coding rocks)에서 vibe coding과 책임 있는 AI 보조 프로그래밍을 분명히 구분했으며, 후자를 이후 agentic engineering이라고 부르기 시작함
• vibe coding은 코드를 거의 보지 않고, 프로그래밍을 모를 수도 있는 사용자가 원하는 결과물을 요청한 뒤 동작하면 받아들이고, 안 되면 다시 요청하는 방식으로 구분됨
• 개인 도구처럼 버그가 자기 자신에게만 피해를 주는 경우에는 vibe coding이 유용할 수 있지만, 다른 사람의 정보와 사용 경험이 걸린 소프트웨어를 만들 때는 무책임한 방식으로 보임
• agentic engineering은 전문 소프트웨어 엔지니어가 보안, 유지보수성, 운영, 성능 같은 제약을 이해한 상태에서 AI 도구를 자기 역량의 최대치로 활용하는 방식임
• 목표는 더 낮은 품질의 결과물을 더 빠르게 만드는 것이 아니라, 더 높은 품질의 프로덕션 시스템을 더 빠르게 만드는 데 있음
• 문제는 코딩 에이전트가 더 신뢰 가능해지면서, 프로덕션 수준 작업에서도 생성된 모든 코드 줄을 더 이상 검토하지 않게 됐다는 데 있음

코드 검토를 생략하게 만드는 신뢰

• Claude Code에 JSON API 엔드포인트를 만들고, SQL 쿼리를 실행해 결과를 JSON으로 출력하도록 요청하면 제대로 처리할 것이라는 확신이 생김
• 자동화 테스트와 문서화를 추가하게 해도 결과물이 괜찮을 것이라고 기대하게 되며, 그 과정에서 실제 코드를 검토하지 않는 경우가 생김
• 코드를 검토하지 않았다면 프로덕션에 사용하는 것이 책임 있는 일인지에 대한 죄책감이 남음
• 큰 조직에서 엔지니어링 매니저로 일할 때 다른 팀의 소프트웨어를 사용하는 방식과 비슷하게 볼 수 있음
  • 다른 팀이 이미지 리사이즈 서비스를 제공하면, 보통 그 팀이 작성한 모든 코드 줄을 읽지 않음
  • 문서를 보고 이미지를 리사이즈해 본 뒤 자기 기능을 출시함
  • 버그나 성능 문제가 보일 때에야 Git 저장소를 들여다볼 수 있음
  • 대부분의 경우 해당 서비스를 반쯤 블랙박스처럼 다룸
• 에이전트도 점점 같은 방식으로 다루게 되지만, 사람 팀과 달리 Claude Code에는 전문적 평판이나 책임(accountability)이 없음
• 사람 팀은 과거에 좋은 소프트웨어를 만들며 평판을 쌓을 수 있고, 형편없는 결과물이 자신의 전문적 평판에 영향을 준다는 압박을 받음
• Claude Code는 그런 평판을 가질 수 없지만, 반복적으로 단순한 작업을 선호하는 스타일에 맞게 올바르게 처리하면서 신뢰를 쌓고 있음
• 여기에는 일탈의 정상화 요소가 있음
  • 모델이 가까이 감시하지 않아도 올바른 코드를 작성할 때마다 신뢰가 커짐
  • 나중에 잘못된 순간에 과신해 피해를 볼 위험도 함께 커짐

소프트웨어 평가가 더 어려워짐

• 예전에는 GitHub 저장소에 커밋 100개, 좋은 README, 자동화 테스트가 있으면 프로젝트에 상당한 정성과 주의가 들어갔다고 판단하기 쉬웠음
• 이제는 커밋 100개, 아름다운 README, 모든 코드 줄을 포괄하는 테스트가 있는 Git 저장소를 30분 만에 만들 수 있음
• 이런 저장소는 오랜 정성과 주의가 들어간 프로젝트와 겉보기에는 동일하게 보일 수 있음
• 실제로 그만큼 좋을 수도 있지만, 겉으로 봐서는 알기 어렵고 자기 프로젝트에 대해서도 같은 문제가 생김
• 테스트와 문서의 품질보다 더 중요하게 보는 기준은 누군가가 그 소프트웨어를 실제로 사용했는지임
• vibe coded 결과물이라도 만든 사람이 지난 2주 동안 매일 사용했다면, 거의 실행해 보지 않고 뱉어낸 결과물보다 훨씬 더 가치 있다고 봄

병목은 코드 작성에서 다른 단계로 이동함

• 하루에 코드 200줄을 만들던 상황에서 2,000줄을 만들 수 있게 되면, 소프트웨어 개발 생애주기의 다른 부분이 깨지기 시작함
• 기존 소프트웨어 개발 생애주기는 하루에 코드 몇백 줄을 만드는 속도를 전제로 설계돼 있었음
• 병목 변화는 하류 단계뿐 아니라 상류 단계에도 영향을 줌
• Jenny Wen의 발표에서는 기존 디자인 프로세스가 “디자인을 제대로 맞춰야 한다”는 전제를 갖고 있다고 봄
  • 엔지니어에게 넘긴 뒤 잘못된 것을 3개월 동안 만들면 재앙이 되기 때문임
  • 디자인이 값비싼 작업으로 이어지기 때문에 광범위한 디자인 프로세스를 둠
  • 하지만 빌드에 3개월이 걸리지 않는다면, 잘못됐을 때 비용이 크게 낮아졌기 때문에 디자인 프로세스가 훨씬 더 위험을 감수할 수 있음

그래도 소프트웨어 엔지니어 커리어가 끝났다고 보지 않는 이유

• 에이전트와의 대화는 대다수 사람에게 알아듣기 어려운 “moon language”처럼 보임
• 컴퓨터가 스스로 코드를 쓸 수 있게 됐다고 해서 소프트웨어 엔지니어 커리어가 끝났다고 보지 않는 이유 중 하나는, 이런 도구가 기존 경험을 증폭하기 때문임
• 무엇을 하고 있는지 아는 사람은 AI 도구와 함께 훨씬 더 빠르게 움직일 수 있음
• AI 도구를 사용할수록 소프트웨어 제작 자체가 매우 어렵다는 사실이 반복적으로 확인됨
• 모든 AI 도구가 주어져도 달성하려는 일은 여전히 어렵다고 봄
• Matthew Yglesias는 트윗에서 “5개월이 지나고 보니 vibecode를 하고 싶지 않다. 전문적으로 관리되는 소프트웨어 회사들이 AI 코딩 보조를 사용해 더 많고, 더 좋고, 더 저렴한 소프트웨어 제품을 만들어 나에게 돈을 받고 팔았으면 한다”고 썼고, 여기에 동의함
• 배관 관련 YouTube 영상을 충분히 보면 직접 집 배관을 고칠 수도 있지만, 배관공을 고용하는 편을 선호한다는 비유로 정리됨

SaaS와 사내 제작의 위험

• 기업이 SaaS를 쓰지 않고 자체 솔루션을 만들 수 있게 되는 위협에 대해서도, 실제 사용으로 검증된 소프트웨어를 선호한다는 기준이 그대로 적용됨
• 개인 프로젝트에서는 적어도 몇 주 동안 만든 사람이 직접 사용한 도구를 선호함
• 엔터프라이즈 버전으로 바꾸면, 적어도 두 개의 다른 대기업이 6개월 동안 성공적으로 사용한 CRM이 아니라면 도입하고 싶지 않다는 기준이 됨
• 위험을 감수하기 전에 실제로 작동한다고 입증된 솔루션을 원함