Simon Willison — 바이브 코딩과 에이전트 엔지니어링의 경계가 무너질 때

원문: https://simonwillison.net/2026/May/6/vibe-coding-and-agentic-engineering/ | Simon Willison, 2026년 5월 6일

핵심 요약

Simon Willison은 한때 명확히 구분된다고 보았던 “바이브 코딩”과 “에이전트 엔지니어링”의 경계가 실제 개발 현장에서 빠르게 흐려지고 있다고 말한다. 핵심은 AI가 코드를 잘 쓰느냐가 아니라, 사람이 코드의 품질과 책임을 어떤 방식으로 확인할 수 있느냐에 있다. Hacker News 반응은 생산성 확대를 긍정하는 쪽과, 이해·검증 능력의 약화를 우려하는 쪽으로 크게 갈렸다.

구분은 쉬웠다: 책임 없는 생성과 책임 있는 엔지니어링

AI 코딩 도구 논쟁에서 “바이브 코딩”은 편리한 경멸어처럼 쓰인다. 대충 원하는 것을 말하고, 생성된 결과가 돌아가면 충분하다고 보는 태도다. 반면 “에이전트 엔지니어링”은 더 전문적인 이름을 가진다. 요구사항을 정리하고, 테스트를 만들고, diff를 검토하고, 운영 환경에서 안전하게 동작하는지 확인하는 개발 방식이다.

Willison은 원래 이 둘을 꽤 엄격하게 나눴다. 개인용 스크립트나 일회성 도구라면 바이브 코딩도 괜찮다. 망가지면 나만 불편하다. 하지만 다른 사람의 데이터, 돈, 시간, 업무를 다루는 소프트웨어라면 이야기가 달라진다. 그때는 버그가 나만의 장난감 안에 머물지 않는다. 사용자가 피해를 입고, 운영자가 대응해야 하며, 조직의 신뢰가 깎인다.

그래서 그의 구분은 단순했다. 코드를 이해하지 않고 결과만 소비하는 것은 바이브 코딩이고, 전문 지식과 검증 절차를 동원해 AI를 도구로 쓰는 것은 엔지니어링이다. 이 구분은 개발자에게 심리적으로도 편했다. 우리는 AI를 쓰더라도 “나는 여전히 책임지는 엔지니어다”라고 말할 수 있었다.

그런데 Willison이 불편해하는 지점은 바로 여기서 시작된다. 최신 코딩 에이전트가 단순한 작업을 너무 자주, 너무 안정적으로 잘 해내기 시작하면서, 책임 있는 개발자조차 모든 줄을 읽지 않는 순간이 늘어나고 있다는 것이다.

문제는 코드 생성이 아니라 신뢰의 단위다

이 글에서 가장 흥미로운 비유는 에이전트를 “다른 팀이 만든 내부 서비스”처럼 대하기 시작했다는 대목이다. 큰 조직에서 일하다 보면 내가 의존하는 모든 시스템의 코드를 직접 읽지 않는다. 이미지 리사이즈 서비스, 결제 모듈, 검색 인덱서가 있다고 하자. 우리는 문서와 계약, 테스트, 운영 이력, 팀의 평판을 보고 그 서비스를 신뢰한다. 문제가 생겼을 때야 저장소를 파고든다.

Willison은 점점 코딩 에이전트를 비슷하게 대하고 있다고 고백한다. 간단한 JSON API, 뻔한 SQL 조회, 문서와 테스트가 붙은 작은 기능은 이제 매번 모든 줄을 뜯어보지 않아도 된다고 느끼는 순간이 생긴다. 이 자체가 반드시 무책임하다는 뜻은 아니다. 현실의 소프트웨어 개발은 원래 타인의 코드, 라이브러리, 운영체제, 클라우드 서비스 위에 세워진다.

하지만 인간 팀과 AI 에이전트 사이에는 결정적인 차이가 있다. 인간 팀은 평판과 책임을 가진다. 실수하면 설명하고, 고치고, 다음 설계에 반영한다. 반면 모델은 책임을 지지 않는다. 특정 버전의 Claude Code가 지난주에 잘했다는 사실은 오늘 보안 민감한 JWT 처리도 잘할 것이라는 보증이 아니다. 반복된 성공은 신뢰를 만들지만, 그 신뢰가 어느 순간 과잉 신뢰로 변할 수 있다.

이것이 Willison이 말하는 위험의 핵심이다. AI가 나쁘다는 주장이 아니다. 오히려 충분히 잘하기 때문에 위험하다. 형편없는 도구는 금방 의심받는다. 위험한 도구는 “대체로 잘하는 도구”다. 사용자는 성공 경험을 축적하면서 점점 감시를 줄이고, 마침내 감시가 가장 필요한 순간에도 같은 습관을 유지할 수 있다.

테스트와 README만으로는 더 이상 충분하지 않다

예전에는 좋은 README, 많은 커밋, 자동화된 테스트가 있는 저장소를 보면 어느 정도 안심할 수 있었다. 물론 완벽한 증거는 아니었지만, 누군가 시간을 들여 설계하고 다듬었다는 신호였다. 이제 그 신호의 의미가 약해졌다. AI는 그럴듯한 README, 촘촘해 보이는 테스트, 긴 커밋 기록을 짧은 시간 안에 만들어낼 수 있다.

이 변화는 오픈소스 평가 방식에도 영향을 준다. 겉모습만으로는 “오래 사용되며 단련된 도구”와 “한 번에 생성된 데모”를 구분하기 어려워진다. Willison이 더 중요하게 보는 기준은 실제 사용 이력이다. 누군가가 그 도구를 며칠 혹은 몇 주 동안 자기 문제에 매일 써봤는지, 실패를 겪고 고쳤는지, 운영 중인 맥락이 있는지가 더 강한 신호가 된다.

이 관점은 기업 소프트웨어에도 그대로 적용된다. 사내에서 AI로 CRM, 대시보드, 업무 자동화 도구를 빠르게 만들 수 있어도, 중요한 업무 시스템을 선택할 때는 “다른 조직에서 충분히 써봤는가”가 여전히 중요하다. 생성 비용이 내려가도 신뢰 비용은 같은 속도로 내려가지 않는다.

병목은 코드가 아니라 개발 생애주기 전체로 이동한다

Willison의 또 다른 중요한 주장은 코드 생산 속도가 빨라지면 다른 병목이 드러난다는 점이다. 하루에 수백 줄을 쓰던 팀이 하루에 수천 줄을 만들 수 있게 되면, 단순히 더 많은 기능을 더 빨리 낼 수 있는 것이 아니다. 요구사항 정의, 제품 판단, 디자인 검토, 코드 리뷰, 테스트 설계, 배포 승인, 운영 모니터링이 모두 압박을 받는다.

기존 개발 프로세스는 코드가 비싸다는 전제 위에 설계됐다. 잘못된 설계를 넘기면 몇 달의 구현 비용이 낭비되므로, 앞단에서 회의와 문서와 디자인 검토를 많이 했다. 그런데 구현 비용이 낮아지면 실험을 더 많이 해볼 수 있다. 이는 분명 기회다. 하지만 동시에 조직이 무엇을 검증해야 하는지 다시 정의해야 한다는 뜻이기도 하다.

코드가 싸졌다면, 더 비싸진 것은 판단이다. 무엇을 만들지, 누가 쓸지, 어떤 위험을 감수할지, 어느 수준의 품질이면 충분한지 결정하는 일이 더 중요해진다. AI 시대의 생산성은 “코드를 많이 만드는 능력”이 아니라 “생성된 가능성 중 버릴 것을 빨리 버리는 능력”에 가까워진다.

커뮤니티 반응: 생산성, 이해, 그리고 검증

Hacker News에서는 이 글이 큰 반응을 얻었다. 논의는 크게 세 갈래로 나뉘었다. 첫째는 AI를 새로운 추상화 계층으로 보는 입장이다. 어셈블리를 직접 쓰지 않아도 고수준 언어로 좋은 시스템을 만들 수 있듯, 모든 구현 세부를 직접 타이핑하지 않아도 엔지니어링은 가능하다는 주장이다. 중요한 것은 산출물이 요구를 만족하고, 테스트와 운영에서 검증되느냐라는 것이다.

둘째는 이해 능력의 약화를 걱정하는 입장이다. 코드를 쓰는 행위는 단순 입력이 아니라 설계 감각을 유지하는 훈련이라는 반론이다. 직접 쓰고 고치면서 추상화가 새는 지점, 이름이 어색한 지점, 책임이 섞인 지점을 몸으로 배운다는 것이다. 읽기만 해서는 얻기 어려운 감각이 있다는 말이다.

셋째는 검증 인프라의 문제를 지적한다. AI가 더 많은 코드를 만들수록, 사람의 리뷰 시간은 상대적으로 부족해진다. 그렇다면 필요한 것은 “AI를 믿을지 말지”라는 감정적 논쟁이 아니라, 산출물을 감사하고 재현하고 위험도에 따라 검토 깊이를 조절하는 체계다. 테스트, 타입, 린트, 보안 스캐너, 런타임 관측, 작은 배포 단위가 더 중요해진다.

흥미로운 점은 찬반 양쪽 모두 극단적이지 않다는 것이다. 생산성 향상을 인정하는 사람도 무검토 배포를 옹호하지는 않는다. 위험을 걱정하는 사람도 AI 도구를 전면 금지하자고만 말하지 않는다. 실제 쟁점은 어디까지 위임할 수 있고, 어떤 신호가 충분한 신뢰를 만드는가다.

남는 질문: 우리는 코드를 얼마나 알아야 하는가

이 글이 던지는 질문은 개발자의 정체성과 연결된다. 좋은 개발자는 모든 줄을 직접 이해해야 하는가, 아니면 시스템의 위험을 판단하고 적절한 검증 장치를 배치할 줄 알면 되는가. 과거에도 우리는 모든 의존성을 읽지 않았다. 하지만 이번 변화는 속도와 규모가 다르다. AI는 의존성을 가져오는 것이 아니라, 우리 이름으로 새 코드를 계속 만들어낸다.

따라서 앞으로의 기준은 “AI가 썼는가”가 아니라 “책임의 경로가 남아 있는가”가 되어야 한다. 어떤 요구에서 출발했는지, 어떤 테스트가 의미 있는지, 어떤 부분을 사람이 검토했는지, 어떤 위험은 의도적으로 받아들였는지 기록되어야 한다. AI가 작성한 코드도 이런 맥락 안에 들어오면 엔지니어링의 일부가 될 수 있다. 반대로 맥락 없이 생성된 코드는 테스트가 많아도 불안하다.

Willison의 불편함은 그래서 건강한 신호다. 그는 AI 도구를 거부하지 않는다. 오히려 많이 쓰기 때문에 그 경계가 흐려지는 순간을 정확히 느낀다. 지금 개발 조직에 필요한 태도도 비슷하다. AI 코딩을 금지하거나 찬양하는 대신, 어느 순간부터 우리가 무엇을 검토하지 않게 되었는지 계속 물어야 한다.

코드 생산의 미래는 더 빨라질 것이다. 하지만 신뢰 생산의 미래는 아직 발명 중이다. 이 글의 진짜 주제는 바이브 코딩이냐 에이전트 엔지니어링이냐가 아니다. 더 많은 코드를 더 쉽게 만들 수 있는 시대에, 우리가 어떤 증거를 보고 “이건 책임 있게 만든 소프트웨어다”라고 말할 수 있을지에 대한 질문이다.