클로드 코드 만드는 엔지니어가 경고한 ‘인지적 항복’…퀴즈 통과해야 병합하라

AI 코딩 도구를 만드는 사람이 정작 그 도구가 개발자를 무디게 만들 수 있다고 경고했다. 앤트로픽 클로드 코드 팀의 엔지니어 애디 오스마니(Addy Osmani)는 화요일(현지시각) X(옛 트위터)에 올린 에세이에서 ‘인지적 항복(cognitive surrender)’이라는 개념을 꺼냈다. AI의 답을 비판 없이 내 답으로 받아들이는 상태를 가리킨다. 그는 AI를 쓰지 말라는 것이 아니라 생각하는 습관을 일부러 설계하라고 주문했다.

구글 14년 거친 엔지니어가 AI 코딩의 한복판에서 던진 질문

오스마니는 구글에서 14년을 일하며 크롬 개발자 도구(Chrome DevTools)와 라이트하우스(Lighthouse), 코어 웹 바이탈(Core Web Vitals)을 만드는 데 참여했다. 지금은 앤트로픽에서 클로드 코드를 개발한다. 앤트로픽은 에이전트(스스로 작업을 수행하는 AI) 기반 코딩에 전력을 쏟고 있고 사람이 직접 코드를 쓰는 비중도 줄였다고 비즈니스 인사이더는 전했다.

그래서 이번 경고에는 아이러니가 따른다. 오스마니 스스로 “이제 내 업무 상당 부분이 에이전트를 거치다 보니 일상에서 비판적 사고를 강제하는 것이 점점 없어진다”고 적었다. 그는 “비판적 사고는 하루 일과에 직접 심어 넣어야 한다. 기본값으로는 아무것도 대신해 주지 않기 때문”이라고 말했다.

비슷한 고민은 업계 곳곳에서 나온다. 비즈니스 인사이더는 최근 1년 사이 AI 때문에 엔지니어가 만드는 사람보다 운영하는 사람에 가까워졌다는 우려가 나왔다고 짚었다. 한 오픈AI 출신 인사는 이 매체에 AI 코딩이 지루하고 따분하다고 말했다. AI가 사람을 더 멍청하게 만드는지, 사고방식을 바꾸는 것인지는 아직 분명하지 않다. 이 매체가 만난 연구자들은 좋지 않은 신호를 봤지만 섣부른 결론은 경계했다.

위임에서 항복까지, 3단계로 미끄러진다

‘인지적 항복’이라는 말은 오스마니가 만든 것이 아니다. 와튼스쿨(Wharton School)의 스티븐 쇼와 기디언 나브의 논문에서 빌려왔다. 오스마니는 이것이 한 번에 일어나지 않고 세 단계에 걸쳐 서서히 진행된다고 설명한다.

1단계는 ‘인지적 위임’이다. 단순 반복 작업을 AI에 맡기되 과제를 이해하고 결과물을 판단할 수 있는 상태다. 오스마니는 “나는 하루 종일 이렇게 한다. 여러분도 그래야 한다”고 썼다. 2단계는 ‘판단 유예’다. AI의 답이 내 출발점이 되고, 답을 보기 전에 스스로 견해를 세우는 일이 사라진다. 3단계가 인지적 항복이다. AI의 출력이 곧 내 출력이 되고, 코드가 왜 이렇게 동작하느냐는 질문에 답하지 못한다. 이해한 적이 없고 승인만 했기 때문이다.

오스마니는 “인지적 항복은 AI가 말하는 것을 그대로 내 답으로 삼는 것이다. 비판적 사고를 정말로 놓아버리게 된다”고 표현했다. 이런 일이 잦아지면 ‘인지 부채’가 쌓인다고 했다. 다만 모든 항복이 나쁜 것은 아니다. 그는 “위험이 낮은 일은 전부 맡겨도 된다”면서도 “에이전트를 거치더라도 답을 설명하지 못한다면 주도권을 내준 것”이라고 선을 그었다.

600줄짜리 풀 리퀘스트가 보여주는 ‘이해 부채’

오스마니가 든 사례는 구체적이다. AI 에이전트가 600줄짜리 코드 변경을 올렸다. 구조는 깔끔하고 테스트는 모두 통과해 개발자는 그대로 병합한다. 에이전트가 한 함수에서 트랜잭션 처리 순서를 슬쩍 바꿨거나 다른 함수의 경계 조건을 조정했다는 사실은 눈치채지 못한다.

당장은 아무 문제가 없다. 하지만 몇 주 뒤 운영 환경에서 시스템이 멈추면 개발자는 코드가 왜 그렇게 동작하는지 설명하지 못한다. 실제로 읽은 적이 없기 때문이다. 오스마니는 이런 간극이 쌓이는 것을 ‘이해 부채’라고 불렀다. 코드베이스는 커지고 기능은 늘어나는데 개발자의 이해는 따라가지 못한다는 뜻이다.

에세이를 소개한 글은 관련 조사도 인용했다. 소나소스 조사에서는 AI가 도운 코드를 커밋(저장소 반영) 전에 꾸준히 확인하는 개발자가 48%에 그쳤다. 아피로는 AI가 만든 코드의 48%에 보안 취약점이 있다고 보고했다. 읽지 않은 코드가 그대로 배포되고 있다는 오스마니의 우려와 맞닿는 수치다.

퀴즈 통과해야 병합하고, 주 1회는 AI 없이 코딩

오스마니는 진단에 그치지 않고 다섯 가지 실천법을 내놨다. 가장 눈에 띄는 것은 AI에게 시험관 역할을 맡기는 방법이다. 클로드가 큰 변경을 끝내면 바로 승인하지 말고 무엇을 왜 바꿨는지 요약하게 한 뒤 그 내용으로 짧은 퀴즈를 내게 한다. 퀴즈를 통과해야만 병합한다는 규칙을 세우라는 것이다. 출시할 코드에 대한 질문에 답하지 못한다면 출시해서는 안 된다는 논리다.

두 번째는 프롬프트를 쓰기 전에 요구사항을 직접 적는 일이다. 에이전트는 개발자가 몰랐던 빈틈도 위험할 만큼 잘 메운다. 목표와 제약, 범위를 정하지 않으면 에이전트가 대신 결정하고, 어떤 선택을 했는지도 알 수 없다. 오스마니는 이를 ‘의도 부채’라 부르고, 프롬프트를 두 번 고쳐도 원하는 결과가 안 나오면 프롬프트를 멈추고 요구사항으로 돌아가라고 했다.

세 번째는 허락받지 않고 내린 결정을 에이전트에게 묻는 것이다. 에이전트는 기본 매개변수, 범위 조정, 충돌하는 요구 사이의 절충 같은 결정을 조용히 내리고 늘 보고하지는 않는다. 작업이 끝나면 명시적으로 승인하지 않은 결정과 기댄 가정, 검증하지 않은 부분, 시스템 다른 곳에 영향을 줄 변경을 직접 물어보라고 했다. 네 번째는 초록색 테스트를 곧이곧대로 믿지 않는 것이다. 테스트는 테스트가 다룬 조건만 증명한다. 경계 사례가 빠져 있으면 에이전트가 문제를 감춘 채 깨끗한 보고서를 낼 수 있다. 위험도가 높은 변경에는 독립된 두 번째 에이전트를 돌려 첫 번째가 놓친 문제를 찾게 하라고 권했다.

다섯 번째는 다소 복고적이다. 일주일에 한 번은 AI 없이 코딩하라는 것이다. 클로드 코드를 만드는 엔지니어가 가끔은 클로드 코드를 쓰지 말라고 하는 셈이지만 이유는 실용적이다. 쓰지 않는 기술은 퇴화한다. 그는 “연습을 멈춘 기술은 짐작보다 빨리 사라질 것이다. 놓치고 싶지 않은 기술은 계속 연습하라”고 썼다. 매달 어떤 기술을 AI에 넘겼고 무엇은 안전하게 맡겨도 되며 무엇은 지켜야 하는지 점검하라는 조언도 더했다.

에이전트를 늘릴수록 검증도 늘려야 한다

오스마니는 에이전트 여러 개를 병렬로 돌리는 흐름에도 경고를 남겼다. 프런트엔드와 백엔드, 테스트를 각각 다른 에이전트가 맡으면 인계할 때마다 정보가 깎인다. 한 에이전트의 요약이 다음 에이전트의 입력이 되고, 세 번째 단계쯤 가면 원래 자료의 핵심 내용이 사라질 수 있다는 지적이다.

그의 처방은 중요한 작업일수록 원본 자료와 검증 증거를 보존하라는 것이다. 검토할 물량이 너무 많아져 제대로 확인할 수 없다면 자동 검증을 더하거나 병렬 에이전트 수를 줄여야 한다. 감독 없이 에이전트만 늘리는 것은 생산성이 아니라 도박이라고 했다. 그는 “책임질 수 있는 양보다 많은 결과물을 만들어내면 더는 검토가 아니라 괜찮을 것이라는 데 거는 내기”라고 썼다.

비즈니스 인사이더에 따르면 오스마니는 스스로에게 던지는 질문 목록도 공유했다. ‘묻기 전에 가설을 세웠는가’, ‘나는 지금 무엇을 연습하지 않고 있는가’ 같은 질문이다. 그는 ‘습관으로서의 검증’을 강조하며 AI 에이전트에게 무엇을 검증할 수 있고 무엇은 못 했는지 물으라고 했다. 에세이를 소개한 글은 프롬프트를 보내기 전에 기대하는 결과를 먼저 적어두는 습관을 가장 간단한 자가 테스트로 꼽았다. 도움을 받는 것과 일을 통째로 넘기는 것의 차이를 묻는 질문에는 “무엇을 하는지 알고 있다면 둘 다 괜찮다”고 답했다.