에이전트가 빠르고 매끄럽고 대체로 맞는 답을 내놓을수록, 사람이 결과를 다시 들여다볼 계기는 줄어듭니다. Addy Osmani가 11월 3일 공개한 글은 이 역설을 정면으로 다룹니다.
결론은 에이전트를 덜 쓰자는 것이 아닙니다. 모델이 좋아질수록 드러나는 오류가 줄어서 스스로 검토할 이유가 사라지기 때문에, 비판적 사고를 작업 흐름에 의도적으로 넣어야 한다는 쪽입니다.
현업에서 바로 쓸 수 있는 기준이 몇 개 나옵니다. 검증이 초록불일 때 무엇을 증명했는지 묻는 습관, 에이전트가 대신 정한 기본값을 읽는 절차, 그리고 책임질 수 있는 양보다 많이 만들지 않는 규칙입니다.
위임과 항복 사이, 세 단계
글은 AI를 쓰는 태도를 세 칸으로 나눕니다. 맨 위는 인지적 위임입니다. 일은 맡기되 결과의 주도권은 내가 쥡니다. 가운데는 지연입니다. 도구의 출력이 검증할 가설이 아니라 다음 작업의 입력이 되어 버립니다.
맨 아래는 인지적 항복입니다. AI의 출력이 조용히 내 판단이 되고, 확인할 필요를 느끼지 않습니다. 이 용어는 와튼스쿨의 Steven Shaw와 Gideon Nave가 만든 것입니다.
무서운 점은 이동이 눈에 띄지 않는다는 것입니다. 지난 답을 잘 읽었으니 다음 답은 훑고, 그다음은 뼈대만 봅니다. 그러다 한 줄을 설명해 보라는 질문에 답하지 못합니다. 글은 이렇게 이해가 빠지는 상태를 인지 부채라 부르고, 팀 단위로는 공유 시스템에 대한 이해가 침식되는 현상으로 설명합니다.
전체 구조를 머리에 담는 것은 원래 불가능합니다. 글은 Claude Code 팀이 필요할 때 해당 부분을 다시 이해하는 방식을 쓴다고 전합니다. 요점은 완전한 모델이 아니라 내가 무엇을 모르는지 아는 것입니다.
어디까지 넘길지는 판단 비용으로 가릅니다. 저자는 녹화 장소로 쓸 호텔 세 곳을 고를 때는 결정을 AI에 맡겼습니다. 틀려도 손실이 작기 때문입니다. 반대로 돈을 어디에 투자할지, 자녀의 진로를 어떻게 조언할지, 무엇을 만들고 무엇이 사용자에게 영향을 주는지, 출시해도 안전한지는 넘기지 않습니다. 틀렸을 때 비용이 싼 곳은 맡기고, 다른 사람이 결과를 감당할 일은 추론을 남깁니다.
초록불은 한 가지만 증명한다
병목이 옮겨갔다는 진단이 이 글의 핵심입니다. 예전에는 코드를 쓰는 일이 병목이었는데, 지금은 내가 맞다는 것을 확인하는 일이 병목입니다. 에이전트에 검증 수단을 주면 고치고, 돌리고, 읽고, 다시 시도하는 순환을 혼자 돕니다.
문제는 그 검증까지 넘겨버릴 때 생깁니다. "내 결론을 뒷받침하는 증거가 있나"라는 질문이 "체크가 초록불인가"로 바뀝니다. 테스트를 만드는 비용이 싸졌기 때문에 초록불은 쉽게 늘어납니다.
글의 표현을 옮기면 이렇습니다. 기능과 같은 실수를 담은 테스트는 통과합니다. 초록불은 한 가지 속성만 알려줍니다. 그래서 체크가 통과했을 때 무엇을 증명했고 무엇을 증명하지 않았는지 물어야 합니다.
"검증됨"의 기준은 미리 정해야 합니다. 일이 끝난 뒤에 정하면 어떤 결과든 합리화하게 됩니다. 완료의 기준도 실물이어야 합니다. 통과한 테스트, 화면 캡처, 로그나 추적 기록처럼 해석의 여지가 없는 것들입니다.
질문 하나는 특히 실용적입니다. 에이전트에 묻기 전에 내가 답을 어떻게 예상하는지 먼저 적어 두는 것입니다. 틀린 추측이어도 됩니다. 잘 쓴 답을 한 번 읽고 나면 다른 가능성을 상상하기 어려워지기 때문에, 순서를 바꾸는 것만으로 검토가 가능해집니다.
600줄 변경을 승인할 때 실제로 봐야 하는 것
글은 600줄짜리 변경을 구조만 훑고 승인하는 장면을 예로 듭니다. 변수 이름은 그럴듯하고 테스트는 통과합니다. 그런데 중간에 트랜잭션 경계의 순서가 바뀌어 있거나, 생각하지 못한 예외의 기본값이 뒤집혀 있을 수 있습니다.
코드를 쓰는 기술과 리뷰하는 기술은 다릅니다. 리뷰가 도장 찍기로 변하는 지점이 있습니다. 글은 AI가 쓰지 않은 것처럼 변경을 읽고, 그 너머에 있는 결정을 보라고 말합니다.
긴 세션에서 에이전트는 작은 결정을 계속 내립니다. 기본값을 무엇으로 둘지, 무엇을 범위 밖으로 뺄지, 요구사항 두 개가 부딪힐 때 어느 쪽을 다시 해석할지입니다. 요약에는 이런 내용이 남지 않으니, 결정과 가정을 목록으로 달라고 요청해야 합니다.
확인 방법도 구체적입니다. 무작위로 몇 줄을 골라 이 줄은 왜 이렇게 됐는지 묻고, 문서라면 닫은 뒤 핵심 논지를 기억으로 써 봅니다. 변경 보고서와 함께 퀴즈를 받아 만점을 받은 뒤에만 병합하는 규칙을 쓰는 사람도 있습니다.
양을 늘리는 문제는 따로 있습니다. 글은 에이전트가 만든 양과 내 이름을 걸 수 있는 양의 차이를 오케스트레이션 세금이라 부릅니다. 밀린 작업이 쌓이는데 세션을 더 여는 것은 답이 아닙니다. 검사를 조이거나 속도를 줄여야 합니다. 책임질 수 있는 것보다 많이 생산하면 리뷰가 아니라 희망입니다.
프롬프트가 곧 이해도다
사람의 사고는 작업 중간에서 앞과 뒤로 이동합니다. 앞단은 요청과 맥락을 만드는 일이고, 뒷단은 결과를 평가하는 일입니다. 그래서 글은 좋은 프롬프트를 비판적 사고 기술로 봅니다.
예전에는 두루뭉술한 요청을 누군가 되물었습니다. 에이전트는 대개 멈추지 않고 빈칸을 채워 그럴듯한 결과를 돌려줍니다. 글은 내가 쓰지 않은 산출물에 남는 암묵적 목표와 제약을 의도 부채라 부르고, 이 빚은 다른 사람이 갚을 수 없다고 말합니다.
실천은 간단합니다. 요청 전에 내 말로 짧은 브리프를 씁니다. 독자, 범위 밖, 완료의 정의를 적습니다. 두 번째 수정에도 제자리라면 프롬프트를 만지작거리지 말고 다시 씁니다.
입력이 오염되는 경로도 짚습니다. 에이전트가 앞 에이전트의 요약을 물려받는 구조가 반복되면, 세 번째 에이전트는 원문을 읽지 않은 채 판단합니다.
모델이 좋아져도 남는 책임
"곧 모델이 나보다 잘할 텐데 기술을 유지할 이유가 있나"라는 반문도 글에 나옵니다. 저자는 탐지 능력 상당 부분은 넘길 수 있다고 인정합니다. 그래도 남는 것이 있습니다. 무엇이든 출시되는 순간 누군가는 책임을 진다는 사실입니다.
Anthropic이 자사 엔지니어와 연구자를 분석한 자료에서 감독의 역설이라는 표현도 인용합니다. Claude를 감독하려면 AI를 과하게 쓰면서 퇴화할 수 있는 코딩 능력이 필요하다는 것입니다.
일상에서 해볼 만한 실천도 남깁니다. 주 1회는 에이전트 없이 코드를 쓰고, 월 1회는 그동안 그만둔 일을 적어 어떤 것을 계속 안 해도 되는지 고릅니다. 검증에 드는 시간을 일정의 항목으로 잡아 실제로 확보하라는 조언도 붙습니다.
에이전트에게 일을 넘겨도 답을 설명할 수 있어야 합니다. 설명이 안 되면 그 순간이 항복한 지점입니다.
GIGABYTE GIGABYTE 라데온 AI PRO R9700 AI TOP D6 32GB 피씨디렉트
로켓배송으로 바로 받기이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
