바이브 코딩과 에이전트 엔지니어링, 생각보다 빨리 섞이고 있음

• 사이먼 윌리슨이 요즘 제일 불편하게 느끼는 지점은, ‘바이브 코딩’과 ‘에이전트 엔지니어링’의 경계가 생각보다 빨리 흐려지고 있다는 거임

  • 원래 그의 구분은 꽤 명확했음. 바이브 코딩은 코드를 보지도 않고, 심하면 프로그래밍을 몰라도, AI에게 “이거 만들어줘” 하고 결과물이 돌아가면 끝나는 방식임
  • 반대로 에이전트 엔지니어링은 전문 개발자가 보안, 유지보수성, 운영, 성능 같은 제약을 이해한 상태에서 AI 도구를 최대한 잘 활용하는 방식임

• 그는 바이브 코딩 자체를 무조건 까는 입장은 아님. 쓸 곳과 쓰면 안 되는 곳이 다르다는 쪽에 가까움

  • 혼자 쓰는 개인용 도구라면 버그가 나도 본인만 다치니까 괜찮다는 입장임
  • 하지만 남들이 쓰는 소프트웨어라면 얘기가 달라짐. 다른 사람의 정보가 걸려 있고, 멍청한 버그 때문에 실제 사용자가 피해를 볼 수 있음

• 문제는 코딩 에이전트가 점점 잘해지면서, 프로덕션 수준 작업에서도 매 줄을 직접 리뷰하지 않는 일이 생기고 있다는 점임

  • 예를 들어 Claude Code에게 JSON API 엔드포인트를 만들고, SQL 쿼리를 실행해서 결과를 JSON으로 내보내라고 하면, 이제는 그냥 잘할 거라고 믿게 된다는 것
  • 테스트 추가, 문서화까지 시켜도 꽤 안정적으로 기대한 스타일에 맞춰 결과물을 낸다고 봄
  • 그래서 찝찝함이 생김. “내가 이 코드를 안 읽었는데, 이걸 프로덕션에 넣는 게 책임 있는 행동인가?”라는 죄책감임

• 글쓴이는 이 감각을 대기업 조직에서의 팀 간 의존성과 비교함

  • 어떤 팀이 이미지 리사이즈 서비스를 만들어서 “이렇게 쓰면 됨”이라고 넘겨주면, 보통 다른 팀은 그 코드 전체를 한 줄씩 읽지 않음
  • 문서를 보고, 몇 장 리사이즈해 보고, 자기 기능을 계속 배포함
  • 문제가 생기거나 성능이 이상할 때 그제야 저장소를 파고 들어가 보는 식임

• 이제 코딩 에이전트도 비슷하게 ‘반쯤 블랙박스’로 다루기 시작했다는 게 그의 고백임

  • 단순하고 반복적인 작업을 계속 제대로 해내니까, 매번 내부 구현을 까보는 비용이 점점 아깝게 느껴짐
  • 하지만 인간 팀과 다른 점이 있음. 사람은 평판과 책임이 있고, “저 팀은 좋은 소프트웨어를 만들어왔다”는 신뢰 자산이 쌓임
  • Claude Code는 직업적 평판도 없고, 결과에 대해 책임질 수도 없음. 그런데도 반복적으로 잘해내며 신뢰를 얻고 있다는 게 묘하게 불편한 포인트임

• 개발자 입장에서는 이 논쟁이 꽤 현실적임. 이미 많은 팀이 코드 리뷰, 테스트, 린트, 타입 체크, 배포 파이프라인 사이에 AI 코드를 끼워 넣고 있음

  • 중요한 건 AI가 쓴 코드냐 사람이 쓴 코드냐보다, 어떤 검증 경로를 통과했느냐에 가까워짐
  • 다만 검증을 자동화했다고 해서 책임이 사라지는 건 아님. 장애가 나면 호출당하는 건 여전히 사람임

---

기술 맥락

• 여기서 갈리는 선택은 “AI가 짠 코드를 매 줄 읽을 것인가, 아니면 테스트와 문서, 동작 검증을 믿고 통과시킬 것인가”예요. 코딩 에이전트가 단순 작업을 안정적으로 처리하기 시작하면, 사람 리뷰의 병목이 점점 더 비싸게 느껴지거든요.

• 바이브 코딩이 위험한 이유는 코드 품질을 확인하는 주체가 사실상 사라지기 때문이에요. 개인용 도구면 실패 비용이 작지만, 사용자 데이터와 운영 환경이 걸린 제품에서는 작은 SQL 실수나 권한 체크 누락도 바로 사고로 이어질 수 있어요.

• 에이전트 엔지니어링은 그 빈자리를 개발자의 경험과 검증 체계로 메우는 쪽이에요. 테스트를 추가하고, 문서를 요구하고, 성능과 보안 제약을 걸어두는 이유는 AI를 믿어서가 아니라 실패했을 때 잡아낼 장치를 만들기 위해서예요.

• 글쓴이가 내부 팀의 서비스와 비교한 부분이 중요한데, 실제 회사에서도 모든 의존 코드의 내부를 다 읽지는 않아요. 대신 팀의 평판, 문서, 운영 경험, 장애 대응 이력이 신뢰의 근거가 되는데, 코딩 에이전트는 이 책임 구조가 없다는 점이 아직 해결되지 않은 구멍이에요.