불과 6개월 전만 해도 GolemUI를 만드는 이 개발자는 코드 대부분을 직접 손으로 짰다고 한다. 그런데 지금은 Claude 없이 하루치 업무를 해낼 수 있을지 자신이 없다고 고백한다. 개인의 변화가 아니다. 개발자의 84%가 이미 AI 도구를 쓰거나 쓸 계획이라고 답했고, GitHub은 2023년 2월 시점에 Copilot이 켜진 파일에서 코드의 46%가 AI가 생성한 것이라고 측정했다. 당시 GitHub CEO는 그 비율이 머지않아 80%에 이를 것이라 내다봤다. Gartner 역시 2024년 초 14% 미만이던 AI 코드 어시스턴트 사용 비율이 2028년에는 기업 소프트웨어 엔지니어의 90%까지 오르고, 개발자의 역할은 구현에서 오케스트레이션으로 옮겨갈 것이라 전망한다.
이 글의 문제의식은 단순한 도구 예찬이 아니다. 저자는 곧 누군가 "우리가 토큰을 효율적으로 쓰고 있는가"라고 묻는 시대가 온다고 본다. Gartner는 2026년 전 세계 AI 지출이 한 해 만에 44% 늘어 2조 5천억 달러에 이를 것으로 본다. 대부분은 인프라 비용이지 개인의 토큰 요금은 아니지만, 이런 숫자는 결국 재무 부서가 비용을 따지기 시작하게 만든다. 무제한처럼 보이던 토큰은 조용히 계측되고 회사화된다. 그렇게 되면 두 개의 숫자가 조직을 지배한다. 하나는 '기능을 얼마나 만들어냈는가'이고, 다른 하나는 '그 코드를 믿을 수 있는가'다.
신뢰는 내부에서 측정되지 않는다
저자가 핵심으로 꼽는 것은 두 번째 숫자, 즉 신뢰다. 그리고 신뢰는 자기 조직 안에서는 측정이 불가능하다고 말한다. 어떤 코드가 믿을 만한지 판단하려면 그 영역을 AI보다 더 잘 알아야 하는데, 그건 사실상 해당 분야의 전문가일 때만 가능하기 때문이다. 저자는 자신의 일을 두 갈래로 나눈다. GolemUI 소스코드를 다룰 때는 자신이 전문가이므로 Claude가 사실상 자기에게 보고하는 부하 직원처럼 움직인다. 반면 회사 웹사이트를 손볼 때는 결과(WHAT)만 중요하지 과정(HOW)의 전문가는 아니다. 문제는 바로 이 두 번째 영역, 즉 예전에는 손도 못 댔을 분야를 AI 덕분에 건드리게 된 지점에서 터진다. 스스로 완전히 이해하지 못한 채 '돌아가니까' 출하한 코드가 시한폭탄처럼 앱 구석에서 째깍거린다.
이것이 막연한 불안이 아님을 데이터가 뒷받침한다. 2025년 Stack Overflow 개발자 설문에서는 같은 조사 안에서 AI 도입은 늘고 신뢰는 떨어지는 엇갈린 흐름이 나타났다. 실제 사고도 이미 발생했다. 2026년 1월 출시된 AI 에이전트용 소셜네트워크 Moltbook은 며칠 만에 데이터베이스 키가 클라이언트 자바스크립트에 그대로 노출되고 Row Level Security가 아예 켜져 있지 않은 상태로 발견됐다. 클라우드 보안 기업 Wiz의 연구진은 150만 개의 API 토큰을 포함한 운영 데이터베이스 전체를 읽고 쓸 수 있었다.
책임은 누구에게 남는가
AI는 각 직군을 가르던 경계를 지웠다. 이제 한 사람이 앱을 처음부터 끝까지 만들 수 있고, 전에 만들 수 있던 것을 더 빨리, 전에는 못 만들던 것까지 만들어낸다. 그런데 버그의 책임과 소명은 누가 지는가. 예전엔 자명했다. 버그를 넣은 개발자가 고치고, 출하한 조직이 책임졌다. '바이브 코딩'이라는 말을 만든 안드레이 카르파티는 이 지점에서 한 발도 물러서지 않는다. 그는 바이브 코딩이 바닥을 올리고 에이전틱 엔지니어링이 천장을 올린다며 실천을 둘로 나누면서도, 책임에 대해서는 "당신은 여전히 예전과 똑같이 자기 소프트웨어에 책임이 있다"고 못 박는다. Django 공동 개발자 사이먼 윌리슨은 조금 더 흔들린다. 프롬프트하고 그대로 출하하는 바이브 코딩과, 읽고 테스트하고 이해한 뒤 내보내는 책임 있는 엔지니어링 사이의 선을 그어왔지만, 2026년 5월에 이르러 에이전트가 신뢰할 만해지면서 자기도 더는 모든 줄을 검토하지 않는다고 인정했다.
저자는 여기서 Aiden이라는 가상의 시니어 UI 개발자를 등장시킨다. 그는 회사의 금융 앱을 혼자 만든다. UI 명세는 엄격하게 지키지만 DB나 백엔드는 약해서, 세션 중간중간 "이 구현이 정말 맞느냐"고 AI에 되묻는 방식에 기댄다. 그러다 완전히 바이브 코딩한 그리드 영역에서 재현조차 어려운 치명적 버그가 터진다. 그리드는 테스트를 통과하지만, Aiden은 그 코드에 무엇이 들어 있는지 전혀 모른다. 그런데 사업 부서가 요구한 것은 정확한 매출·수익 요약(WHAT)이지 그리드 자체(HOW)가 아니었다. Aiden이 빠진 함정이 바로 이것이다.
토큰을 다른 전문가에게 위임하기
그렇다면 Aiden은 그리드, 차트, 폼, 검증 같은 곳에 토큰을 써야 하는가. 저자는 두 학파가 있다며 자신은 두 번째, 즉 처음부터 어떤 라이브러리를 쓸지 고려하는 쪽에 건다고 밝힌다. 이런 부분의 진짜 비용은 작성이 아니라 유지와 신뢰에 있기 때문이다. 그래서 토큰을 간접적으로 다른 분야의 전문가에게 위임하라고 말한다. 산 라이브러리에서 버그가 나면 티켓을 넣을 상대가 있다. 변경 로그, 지원 계약, 평판을 걸고 고쳐줄 팀이 존재한다. 반면 바이브 코딩한 그리드에는 그 어느 것도 없다. AI는 코드를 만지는 비용은 낮췄지만, 그 코드에 대해 답하는 비용까지 낮추지는 못했다.
코드 품질을 측정하는 GitClear가 2023년부터 2026년 중반까지 6억 2,300만 건의 코드 변경을 분석한 결과도 같은 방향을 가리킨다. 코드 중복은 2023년 대비 81% 늘어 사상 최고치이고, 개발자는 블록을 리팩터링하기보다 복사·붙여넣기할 확률이 약 5배 높아졌으며, 기존 코드를 손보는 변경의 비중은 74% 무너졌다. 어느 때보다 빠르게 짜고 어느 때보다 덜 돌본다는 것이다. 흥미롭게도 AG Grid나 Highcharts처럼 전담 전문가 팀을 둔 라이브러리들의 릴리스는 오히려 빨라진 반면, 커뮤니티 운영 프로젝트에서는 그런 흐름이 약하게 나타난다. 저자는 이 격차 자체가 핵심이라고 본다. 여기에 한 가지 힘이 더 겹친다. 모든 LLM에는 학습 컷오프가 있어서, 두 메이저 전에 이름이 바뀐 속성을 태연히 지어낸다. 결국 이 시대에 살아남을 라이브러리는 잘 관리될 뿐 아니라 에이전트가 읽을 수 있어야 한다. llms.txt로 배포되는 문서, 실제 설치된 버전에 답하는 MCP 서버, 생성된 코드가 운영 환경이 아니라 그 자리에서 즉시 실패하게 만드는 엄격한 타입 인터페이스가 그 조건이다. 어느 학파가 이길지는 저자도 단언하지 않지만, 신뢰를 스스로 만들 수 없다면 그것을 만드는 것이 본업인 팀에게서 사는 편이 낫다는 주장은 실무자에게 곱씹을 만하다.