AI 코딩 에이전트가 일상 업무에 깊숙이 들어오면서, 개발자들이 공유하는 작업 방식과 고민도 하나의 장르가 되고 있다. 개발자 Kunal이 자신의 작업 노트에 남긴 'Resisting Cognitive Surrender(인지적 항복에 저항하기)'는 그중에서도 실무자가 매일 마주하는 유혹을 정면으로 다룬다. 그가 말하는 '인지적 항복'이란, 에이전트가 내놓은 결과물을 스스로 따져보거나 대안을 검토하지 않고 무비판적으로 받아들이는 태도다. 이렇게 일하면 빠르고, 머리도 덜 아프고, 그래서 거부하기 어렵다. 문제는 그 대가가 눈에 잘 띄지 않는다는 데 있다.
왜 '항복'은 그토록 매력적인가
저자는 항복을 부추기는 힘을 솔직하게 나열한다. 좋은 프로그래머의 덕목 중 하나가 게으름이라면, 문제를 통째로 넘겨버릴 수 있는 '소프트웨어 공장'은 그 극단적 실현이다. 여기에 동료 압력 또는 게임이론이 더해진다. 주변이 모두 읽는 속도보다 빠르게 코드를 쏟아내는데 혼자 코드를 이해하겠다고 시간을 쓰면 오히려 뒤처져 보인다. 하루에 올리는 PR 수가 늘어나니 생산성도 높아 보인다. 여기에 모델 특유의 확신에 찬 말투가 겹친다. 저자는 이를 RLHF의 의도치 않은 부작용일 수 있다고 보는데, 모델은 자기 추천에 놀랄 만큼 자신감을 보이고 실수를 인정할 때조차 덤덤하다. 그 확신이 사람의 사회적 본능을 건드려 답을 액면 그대로 받아들이게 만든다.
위험한 것은 이 비용의 피드백 루프가 느슨하다는 점이다. 'slop'이 만들어낸 복잡성은 즉시 물지 않고, 방심한 사이 서서히 누적된다. 깨진 창문 이론처럼, 에이전트가 풀린 상태에서는 결함이 빠르게 번식한다. 저자는 2026년 10월 시점의 경험으로, 에이전트를 최대한 활용하면 '대체로 돌아가지만 기이한 엣지 케이스와 버그를 품은' 복잡성 폭발로 이어진다고 말한다. 수십만 줄을 빠르게 찍어낸 프로젝트들은 기존 개발 도구가 감당하는 규모를 넘겨, 그 도구마저 다시 손봐야 하는 악순환에 빠진다.
진짜 병목은 '이해'다
저자가 특히 불편해하는 지점은 에이전트 앞에서 겪는 일종의 겔만 기억상실이다. 자신이 전문성과 설계 방향을 쥐고 있을 때는 에이전트의 출력을 크게 단순화하며 복잡성을 통제할 수 있지만, 그렇지 못한 영역에서는 에이전트가 세상에서 가장 똑똑한 엔지니어처럼 보여 그저 감탄하며 따라갈 뿐이다. 그러다 에이전트가 디렉터리 하나 만드는 데서 막히면 모든 가정을 다시 세워야 한다. 더 근본적인 문제는 시스템에 대한 자신의 이해와 '기계적 공감(mechanical sympathy)'이 급격히 침식되거나, 애초에 형성될 기회조차 잃는다는 것이다. 손으로 짜던 시절에는 버그를 금방 진단했지만, 에이전트 의존도가 높아질수록 할 수 있는 일은 세션을 하나 더 띄우고 잘 되기를 바라는 것뿐이고, 자동 수정은 이해를 더 깎아내린다.
이 대목에서 저자는 1983년 논문 'Ironies of Automation'을 직접 읽어보라고 권한다. 쉬운 작업을 사람이 손대지 않으면 연습 기회를 얻지 못해, 정작 자동화가 실패한 어려운 상황을 다루기가 더 어려워진다는 경고다. 코드를 짓는 시간은 과거에도 곧 이해하는 시간이었다. 에이전트는 '짓는 시간'을 0에 가깝게 줄일 수 있지만 다음 병목인 '이해'는 거의 움직이지 않았다. 케이크를 먹으면서 동시에 가질 수는 없다는 것, 즉 인간을 넘어선 속도를 얻는 대신 예전 수준의 깊이와 확신은 노력 없이 유지되지 않는다는 사실을 먼저 받아들여야 한다는 것이 저자의 출발점이다.
어디서 항복하고 어디서 운전대를 쥘 것인가
그렇다고 저자가 비관론자는 아니다. 핵심은 쉬운 길을 택하되 의식적으로, 단점을 완화할 만큼의 노력을 들여 택하라는 것이다. 그는 몇 달 전 '바이브 리밋(vibe limit)'을 에이전트로 충분한 확신을 갖고 수행할 수 있는 변경의 복잡도로 정의했다. 적당히 좋으면 되는 프로젝트, 충분히 격리된 샌드박스라면 에이전트 결과를 그대로 받아들여도 된다. 반대로 시스템이 중요하거나 취약하고, 쉽게 점검하기 어렵거나 격리가 부실하다면 직접 시간을 들여야 한다. 공격적인 우선순위 설정과 트리아지, 그리고 새 모델이 나올 때마다 자신의 예측과 실제 결과를 대조해 보정하는 일이 중요해진다. 팀을 이끄는 것과 비슷하되 속도만 훨씬 빠른 셈이다. 그가 꼽는 경고 신호는 한 세션에서 '예, 계속'을 반복해서 누르고 있는 자신을 발견하는 순간이다. 그때는 문제를 아예 더 나은 샌드박스와 피드백 루프로 완전히 위임하든지, 아니면 사고를 멈췄음을 깨닫고 결정들을 다시 점검해야 한다.
깊이 관여해야 하는 프로젝트에서 그가 쓰는 전술은 구체적이다. 직접 타이핑하며 모든 결정에 개입하는 '운전'을 택하거나, 에이전트에게 변경을 소화 가능한 형태로 만드는 비계를 짓게 한다. 예컨대 큰 스택에서는 PR을 4열 뷰로 만드는데, 2열은 일반 diff, 3열은 에이전트의 변경 이유 해설, 4열은 자신이 코멘트와 지시를 다는 공간이다. '변경을 쉽게 만든 뒤, 그 쉬운 변경을 하라'는 원칙으로 작은 스택들을 쌓게 하고, 디버거로 실제 실행 경로를 추적하며, 명령줄 헬퍼에는 생소한 플래그와 명령을 설명하게 해 일하면서 배운다. 흥미롭게도 그는 이 글 자체를 Codex 세션으로 교정하되 모든 수정은 손으로 했다고 밝힌다. 과거 스택오버플로 답을 복붙하지 않고 문서와 대조하며 직접 써보던 습관의 연장이다.
한국 실무자에게 주는 함의
이 글의 가치는 새로운 도구를 소개하는 데 있지 않다. 오히려 에이전트 도입이 '다운사이드가 전혀 없다'는 전제 아래 이야기되기 쉬운 분위기에서, 트레이드오프를 명시적으로 꺼내 놓는다는 점이 유용하다. 결국 책임지는 주체는 에이전트가 아니라 개발자이며, 사고를 양도하면 소유 없이 책임만 지는 상태가 된다. 다만 한계도 분명하다. 저자가 제시하는 판단 기준은 상당 부분 개인의 전문성과 취향에 의존하며, 4열 PR 뷰나 커스텀 하네스 같은 전술은 조직 차원의 표준이라기보다 한 숙련자의 작업 방식에 가깝다. 모델이 설계 감각과 품질에 대한 안목을 넓혀가면 복잡성 폭발 문제는 완화될 수 있다고 그 스스로 예상하지만, 이해의 침식이라는 문제는 쉽게 사라지지 않을 것이라고 본다. 속도가 공짜가 되는 시대에, 어디에 비싼 '이해'의 시간을 배분할지 의식적으로 고르는 일이 각 팀의 숙제로 남는다.