바이브 코딩과 에이전트 엔지니어링의 경계가 무너지고 있다
Simon Willison은 최근 팟캐스트에서 AI 코딩 도구의 발전으로 인해 '바이브 코딩(Vibe coding)'과 전문가의 '에이전트 엔지니어링(Agentic engineering)'의 경계가 모호해지고 있다고 지적했습니다. 특히 코딩 에이전트의 신뢰성이 높아지면서 프로덕션 코드를 작성할 때도 더 이상 모든 코드를 직접 리뷰하지 않게 된 자신의 모습을 발견하고 그에 대한 죄책감을 토로했습니다. 이 글은 AI가 코드를 작성해주는 시대에 소프트웨어 엔지니어의 역할과 '코드 리뷰'의 의미가 어떻게 변화해야 하는지에 대한 깊은 통찰을 제공합니다.
Simon Willison의 웹로그 구독 후원: MongoDB — 5월 7일 열리는 MongoDB.local London 2026에 참여하여 팀들이 AI를 프로토타입에서 프로덕션으로 옮기는 방법을 알아보세요.
바이브 코딩과 에이전트 엔지니어링이 나의 생각보다 더 가까워지고 있다 2026년 5월 6일
나는 최근 Heavybit의 High Leverage 팟캐스트에서 Joseph Ruscio와 함께 AI 코딩 도구에 대해 대화를 나눴습니다: 에피소드 #9, Simon Willison과 함께하는 AI 코딩 패러다임의 전환. 다음은 그 대화의 핵심 내용이며, 내 업무에서 '바이브 코딩'과 '에이전트 엔지니어링'이 서로 융합하기 시작했다는 충격적인 깨달음도 포함되어 있습니다.
내가 팟캐스트를 정말 좋아하는 이유 중 하나는, 대화를 통해 내가 이전에는 말로 표현하지 못했던 아이디어를 소리 내어 생각하게 만드는 순간이 찾아오기 때문입니다.
바이브 코딩과 에이전트 엔지니어링의 겹치기 시작하는 영역 '바이브 코딩'이라는 용어가 처음 만들어진 지 몇 주 후, 나는 '모든 AI 보조 프로그래밍이 바이브 코딩인 것은 아니다 (하지만 바이브 코딩은 훌륭하다)'라는 글을 발표했습니다. 이 글에서 나는 '바이브 코딩'과 책임감 있게 AI를 사용하여 코드를 작성하는 방식(이후부터 나는 이를 '에이전트 엔지니어링'이라고 부르기 시작했습니다)이 완전히 다른 성격의 것이라는 나의 확고한 믿음을 밝혔습니다.
그런데 Joseph이 이 두 가지의 차이점에 대해 이야기를 꺼냈을 때, 나는 예전만큼 둘이 명확하게 구분되지 않는다는 사실을 문득 깨달았습니다:
"묘하게도 이 두 가지가 이미 내게는 흐릿해지기 시작했고, 이건 꽤나 당혹스러운 일입니다. 나는 바이브 코딩이 전혀 코드를 보지 않는 행위라는 매우 명확한 선을 그을 수 있다고 생각했습니다. 당신은 프로그래밍을 할 줄 모를 수도 있습니다. 비개발자가 무언가를 요청하고 결과물을 얻은 뒤, 그게 작동하면 끝! 작동하지 않으면 작동하지 않는다고 말하며 애쓰는 방식일 수 있습니다. 하지만 코드의 품질이나 그 밖의 제약 조건들은 전혀 신경 쓰지 않는 방식이죠.
나는 바이브 코딩이 언제 사용할 수 있고 언제 사용하면 안 되는지 정확히 알고 있다면 훌륭한 방법이라고 생각합니다. 버그가 생겨도 본인만 손해를 보는 개인용 도구라면, 당연히 써도 됩니다! 하지만 다른 사람들을 위해 소프트웨어를 개발한다면, 바이브 코딩은 지극히 무책임한 행동입니다. 다른 사람들의 정보를 다루기 때문입니다. 당신의 하찮은 버그 때문에 다른 사람들이 피해를 입을 수 있습니다. 그래서 적어도 그보다는 높은 수준의 관리가 필요합니다.
이는 '에이전트 엔지니어링'과는 대조됩니다. 여기서 당신은 전문 소프트웨어 엔지니어입니다. 보안, 유지보수성, 운영, 성능 등을 이해하고 있습니다. 이러한 도구들을 당신의 역량을 최대한 끌어올리는 방식으로 사용합니다. 나는 이 도구들의 지원 덕분에 내가 감당할 수 있는 과제의 범위가 상당히 넓어졌음을 느끼고 있습니다. 하지만 여전히 나의 25년 소프트웨어 엔지니어 경험에 크게 의존하고 있습니다.
궁극적인 목표는 고품질의 프로덕션 시스템을 구축하는 것입니다. 더 낮은 품질의 결과물을 더 빨리 만들어내는 것은 좋지 않다고 생각합니다. 나는 더 높은 품질의 결과물을 더 빨리 만들고 싶습니다. 내가 만드는 모든 것이 이전보다 모든 면에서 더 나아지기를 원합니다.
문제는 코딩 에이전트가 점점 더 신뢰할 수 있게 되면서, 이제는 내 프로덕션 수준의 작업조차도 그들이 작성한 코드를 매 줄마다 검토하지 않게 되었다는 것입니다. 만약 Claude Code에게 SQL 쿼리를 실행하고 그 결과를 JSON으로 출력하는 JSON API 엔드포인트를 만들어달라고 요청하면, 그것이 그냥 제대로 처리할 거라는 걸 나는 너무나 잘 알고 있습니다. 실수하지 않을 것이라는 걸 알죠. 자동화된 테스트와 문서화까지 추가하게 만들면, 결과가 훌륭할 거라는 걸 알고 있습니다. 하지만 나는 그 코드를 직접 검토하지 않고 있습니다.
그리고 이제 죄책감이 들기 시작했습니다. 코드를 검토하지 않았다면, 이걸 프로덕션 환경에서 사용하는 것이 과연 책임감 있는 행동일까? 라는 생각 말입니다.
이런 고민에 대해 정말 큰 도움이 된 것은, 내가 규모가 큰 조직에서 엔지니어링 매니저로 일하던 시절을 떠올려 보는 것이었습니다. 내 팀이 다른 팀이 만든 소프트웨어에 의존해야 할 때가 있었습니다. 다른 팀이 무언가를 인계하며 '자, 여기 이미지 리사이즈 서비스가 있어. 이미지 크기를 조절하려면 이렇게 사용하면 돼'라고 말한다면... 저는 가서 그들이 작성한 코드를 한 줄씩 다 읽어보지 않습니다. 문서를 살펴보고, 이미지 크기를 조절하는 데 사용해 본 뒤, 제 기능을 배포하기 시작할 겁니다.