에이전트가 일을 대신할 때 비판적 사고를 지키는 법

Claude Code 팀의 Addy Osmani는 일의 대부분이 에이전트를 거치게 된 뒤로, 하루 중 어느 것도 비판적 사고를 강제하지 않게 됐다고 말한다. 그는 에이전트 활용을 줄이자고 주장하지 않는다. 여러 세션을 병렬로 돌리는 방식을 지지하면서, 무엇이든 에이전트에 넘기기 쉬운 환경에서 비판적 사고를 유지하는 방법을 정리했다.

예전에는 질문과 답 사이의 공간에서 생각이 이루어졌다. 지금 그 공간은 몇 초다. 모델이 좋아질수록 뻔한 오류의 비율은 줄어든다. 결과물 대부분은 잘 쓰였고 대체로 맞아서, 다시 들여다볼 이유를 주지 않는다. 에이전트를 여러 개 돌려도 결과물을 보는 눈은 한 쌍뿐이다. 빠르고 기분 좋고 대개 맞는 답은 바쁜 하루에 반갑지만, 경계가 느슨해지는 이유도 거기에 있다. 그래서 비판적 사고는 하루 일과 안에 직접 만들어 넣어야 한다. 가만히 두면 아무것도 대신 해 주지 않는다.

위임, 유예, 항복

Osmani는 이 문제를 하나의 스펙트럼으로 설명한다.

단계	상태
인지적 위임(cognitive offloading)	작업을 AI에 맡기지만 결과의 소유권은 내가 쥔다
유예(deferral)	도구의 출력이 곧 나의 새 입력이 된다. 결과가 더는 가설이 아니다
인지적 항복(cognitive surrender)	AI의 출력이 조용히 내 것이 되고, 확인할 필요를 느끼지 않는다

맨 위 단계는 그가 종일 하는 일이고 독자에게도 권하는 일이다. 인지적 항복은 와튼스쿨의 Steven Shaw와 Gideon Nave가 만든 용어다. 신뢰가 쌓이거나 게을러질수록 사람은 스펙트럼 아래로 미끄러진다. 단계마다 조금씩 움직이고 그때마다 합당해 보여서 넘어가는 순간을 알아차리기 어렵다. 지난 답을 꼼꼼히 읽었으니 다음 답은 훑어본다. 그다음 답은 뼈대만 본다. 그러다 누가 어떤 줄을 물었을 때 에이전트의 도움을 받고도 설명하지 못한다.

인지 부채는 이렇게 쌓인다. 시스템에 대한 머릿속 모델을 꺼내 쓰려는 순간 그 모델이 없다는 사실을 알게 된다. Margaret-Anne Storey는 이것이 팀에서 공유된 시스템 이론에 대한 이해가 깎여 나가는 모습으로 나타난다고 썼다. Osmani는 코드 쪽의 같은 현상을 이해 부채(comprehension debt, Jeremy Twei가 만든 용어)라고 불러 왔다. 그 순간에는 전혀 보이지 않는다. 코드베이스는 깔끔하고 테스트는 통과한다. 시스템을 고쳐야 할 때가 되어서야 아무도 이해하지 못한다는 사실이 드러난다. 전략 문서나 스펙의 목차만 읽고 승인한 경우도 마찬가지다.

불가능한 일을 요구하는 것은 아니다. 큰 코드베이스 전체의 모델을 머릿속에 유지할 수는 없다. Claude Code 팀은 필요할 때 이해를 다시 세운다고 공개적으로 밝혔다. 어떤 부분을 알아야 하면 Claude에게 그 조각을 설명해 달라고 한다. 그는 이런 부채가 엔지니어 대부분의 예상보다 회복하기 쉽다고 본다. 필요한 곳에서 모델을 다시 세울 수 있다면 전체를 쥐고 있을 필요는 없다. 다만 자신에게 무엇이 없는지는 알아야 한다.

판돈이 낮은 일은 통째로 맡겨도 된다. 그는 강의 촬영 장소로 평점이 비슷한 호텔 세 곳 중 하나를 골라야 했는데, 후기를 다 읽을 시간이 없어 AI에게 결정을 맡겼다. 잘 풀렸고 다시 해도 그렇게 하겠다고 한다. 하지만 돈을 어떻게 투자할지, 아이의 진로에 어떤 조언을 할지, 그리고 일에서 무엇을 만들지, 어떤 변경이 어느 사용자에게 영향을 주는지, 출시해도 안전한지는 그렇게 정하지 않는다. 틀려도 값이 싼 곳에서는 넘겨받고, 다른 사람이 결과를 감당해야 하는 곳에서는 추론을 직접 쥔다는 것이 그의 기준이다.

스스로 던지는 질문

생각이 정리되지 않을 때 그는 기본 질문으로 돌아가곤 했다. 올바른 문제를 풀고 있는가, 올바른 방식으로 풀고 있는가, 결론을 뒷받침하는 증거가 있는가, 끝났다는 것을 어떻게 아는가. 대개는 누가, 무엇을, 어디서, 왜, 언제, 어떻게에 해당한다. 적어 놓으면 유치해 보이지만 그냥 지나쳤을 범주를 따져 보게 만든다. 지금은 이 과정을 건너뛰고 에이전트에게 어떻게 해야 하느냐고 묻기가 너무 쉽다. 그래서 질문을 다음과 같이 고쳐 쓴다.

• 묻기 전에 가설을 세웠는가. 사소하지 않은 작업이라면 에이전트를 돌리기 전에 답이 무엇일지 머릿속으로라도 적어 둔다. 틀린 추측이어도 괜찮다. 잘 쓰인 답을 읽고 나면 다른 가능성을 떠올리기 어렵다. 짚이는 것이 전혀 없으면 Thariq Shihipar가 blind spot pass라고 부르는 방법을 쓴다. 아는 것을 모델에 주고, 내가 모른다는 사실조차 모르는 것을 찾게 한다.
• 생각을 돕게 하는 중인가, 생각을 떠넘기는 중인가. 둘 다 괜찮다. 어느 쪽인지 알고 있으면 된다.
• 이것이 틀리려면 무엇이 참이어야 하는가. 그리고 실제로 확인한다. 모델이 스스로 매긴 확신보다 직접 돌려 볼 수 있는 테스트가 훨씬 값지다.
• 다른 각도의 반론을 들었는가. 열린 문제에 강한 입장을 정했다면 둘 이상의 모델에게 반대편을 변호하게 한 뒤 읽고 자기 의견을 정한다. 시간은 더 들지만 주제를 훨씬 많이 알게 된다.
• 이것을 유지보수할 사람 앞에서 이 결과에 내기를 걸 수 있는가. 코드뿐 아니라 내놓는 모든 것에 해당한다. 그는 이것이 답할 책임의 기준선이라고 본다.
• 내가 더는 연습하지 않는 것은 무엇인가. 일상적인 디버깅 일부는 놓아도 된다. 다만 의도한 선택이어야 한다.

검증을 습관으로

Osmani는 병목이 코딩에서 자신이 옳다고 확신하는 일로 옮겨 갔다고 본다. 에이전트에게 엔드투엔드 테스트, 속성 테스트, 실제 앱 조작 같은 검증 수단을 주면, 에이전트는 사람이 들여다보기도 전에 변경하고 검증을 돌리고 출력을 읽고 다시 시도한다. Boris Cherny가 “Claude에게 자기 작업을 검증할 방법을 주라”고 한 말이 이것이다. 사람은 모든 줄을 읽는 대신 이런 루프를 만들고 증거를 검토하게 된다.

검증도 항복할 수 있다. “결론을 뒷받침하는 증거가 있는가”가 “체크가 초록색이 됐는가”로 바뀐다. 에이전트 덕에 테스트를 만드는 비용이 낮아져 초록색은 많이 보이지만, 통과한 테스트가 고장 난 기능을 잡지 못할 수 있다. 테스트가 기능과 같은 착각으로 쓰였다면 통과한다. 초록색 체크는 한 가지 속성만 알려 준다. 체크가 초록색이 되면 무엇을 증명했는지 묻고, 이어서 무엇을 증명하지 않았는지 묻는다.

“검증됨”의 뜻은 미리 정해 둔다. 사후에는 어떤 결과든 합리화하게 된다. 에이전트 작업의 결승선은 통과한 테스트, 스크린샷, 로그나 트레이스처럼 손에 잡히는 것이어야 한다. 그래야 완료 기준이 “다 된 것 같다”는 해석이 아닌 사실에 놓인다. 에이전트의 완료 알림을 받으면 요약을 보기 전에 실행된 명령과 그 출력부터 확인한다.

Claude Code는 새 컨텍스트의 서브에이전트로 자기 작업을 비평할 수도 있다. 기억날 때만 돌리지 말고 루프에 넣어 매번 돌게 한다. 그는 마지막에 “내가 놓친 게 있나?”라고 여전히 묻는다. 복잡한 기능 작업을 마치고 검토까지 한 뒤에 이렇게 물으면 두세 가지가 더 나오는 일이 잦다고 한다.

이 모든 것을 늘 할 필요는 없다. 언제 깊이 들어갈지 아는 것도 기술이다. Claude Code 팀의 코드 리뷰 방식을 다룬 글에서 그가 가장 좋아하는 경험칙은 이렇다. “체크가 무엇을 놓칠지 말할 수 없다면, 빠른 승인 말고 진짜 리뷰를 요청하라.”

코드 밖에서도 같다. 에이전트가 고객 통화 50건이나 경쟁사 분석을 종합해 줬다면 원본 문서 몇 개를 열어 요약이 맞는지 본다. 권고안이 기대고 있는 숫자 하나를 골라 계산이 맞는지 확인한다. 에이전트 덕에 검증을 차리는 일은 싸졌다. 어려운 것은 좋은 검증이 어떤 모습인지 아는 일이다.

생성된 것을 실제로 읽기

에이전트가 600줄짜리 PR을 내놓았다고 하자. 구조를 대강 보고, 모든 줄을 읽지는 않는다. 변수 이름은 그럴듯하고 테스트는 통과하니 승인한다. 그런데 중간 어딘가에 트랜잭션 경계 안의 미묘한 순서 변경이나, 생각해 본 적 없는 엣지 케이스의 기본값 뒤집힘이 들어 있다. 리뷰를 하긴 했지만 이미 찾을 줄 알았던 것만 찾은 셈이다.

코드 작성과 리뷰는 다른 기술이고, 리뷰가 도장 찍기로 바뀌는 지점이 있다. 그러니 AI가 쓰지 않은 코드인 것처럼 diff를 읽고, diff 너머에서 에이전트가 무엇을 결정했는지 본다. 긴 세션 동안 에이전트는 작은 결정을 많이 대신 내린다. 기본값, 범위 밖으로 둔 것, 두 요구사항이 부딪칠 때 다시 해석한 쪽이 그렇다. 모든 것이 잘됐다는 요약에는 이런 것이 보이지 않는다. 그러니 내린 결정과 가정을 나열하게 한다.

그다음 자신을 시험한다. 몇 줄을 무작위로 골라 이 줄은 무엇인지 묻는다. 문서라면 닫고 핵심 논지를 기억으로 적어 본다. 긴 세션에서 Claude에게 변경 보고서를 쓰게 하고 끝에 퀴즈를 내게 한 뒤, 퀴즈를 완벽히 통과해야만 머지한다는 규칙을 두는 사람도 있다. 출시하는 것을 변호할 수 있을 만큼 이해해야 한다. 언젠가 누군가 물을 수 있다.

에이전트는 주의력을 지키는 데도 쓸 수 있다. Osmani는 풀 리퀘스트가 많이 들어오는 오픈소스 프로젝트에서 에이전트로 무엇이 들어오는지, 무엇이 지침에 어긋나는지, 어디에 자신의 주의가 필요한지를 가린다. 판단 자체를 에이전트에게 맡기는 일은 드물다. 에이전트가 볼 곳을 좁혀 주면, 그는 그 변경이 올바른 문제를 올바른 방식으로 푸는지 직접 생각한다.

양의 문제도 정직하게 봐야 한다. 그는 에이전트가 생성하는 것과 자기 이름을 걸 수 있는 것 사이의 간극을 오케스트레이션 세금이라고 부른다. 끝난 작업이 처리 속도보다 빠르게 쌓인다면 세션을 하나 더 띄워도 소용없다. 사람 손이 덜 가도록 체크를 조이거나 속도를 늦춰야 한다. 책임질 수 있는 양보다 많이 만들고 있다면 그것은 리뷰가 아니다. 잘되기를 바라고 있을 뿐이다.

좋은 입력이 좋은 출력을 만든다

사람의 머릿속 모델은 여전히 개입한다. 위치가 가운데에서 앞과 끝으로 옮겨 갔다. 작업 설명과 컨텍스트를 만드는 앞단, 출력을 검토하는 뒷단에 힘을 쓴다. 그래서 그는 좋은 프롬프트 작성을 비판적 사고 기술로 본다.

예전에는 모호하게 요청하면 누군가 되물었고, 그제야 아직 정리하지 못했다는 사실을 깨닫곤 했다. 에이전트는 대개 거기서 멈춰 세우지 않는다. 빠진 부분을 채워 넣고 완성된 듯한 것을 돌려준다. 바탕의 생각은 여전히 흐릿한데도 그렇다. 그는 이것을 의도 부채(intent debt)라고 써 왔다. 내가 쓰지 않은 산출물 속에 들어 있을 암묵적 목표, 제약, 근거를 가리킨다. 다른 부채와 달리 이것은 남이 대신 갚아 줄 수 없다. 의도는 본인에게서 나와야 한다.

프롬프트는 문제를 얼마나 이해했는지를 비춘다. 명료하게 표현하지 못한다면 머릿속에서도 명료하지 않을 수 있다. 도움을 청하기 전에 요청서를 자기 말로 쓴다. 대상 독자, 범위 밖 항목, 완료의 정의를 적는다. 두 번째 수정까지 하고도 원하는 곳에 닿지 못했다면 손보기를 멈추고 프롬프트를 새로 쓴다.

이 일에도 에이전트의 도움을 받을 수 있다. 그는 Andy Clark가 AI에 위임하는 것과 AI와 협업하는 것을 구분한 방식을 좋아한다. 협업에서는 프롬프트와 출력이 서로를 다듬고 문제에 대한 머릿속 모델도 함께 날카로워진다. 불분명하면 에이전트에게 이해하지 못한 부분을 놓고 자신을 인터뷰하게 한다. 세션을 닫을 때 자신의 모델이 더 정교해졌다면 성공한 것이다.

입력도 조심해야 한다. 에이전트마다 앞 에이전트의 요약을 컨텍스트로 넘겨받다 보면, 세 번째 에이전트는 원본 문서를 읽지 않은 상태가 된다.

출력에 대한 자기 기준도 필요하다. 그는 여러 창작 매체에서 AI를 써 봤지만 기준에 못 미쳐 대부분 공개하지 않았다. 지금은 무엇이든 서식이 깔끔하고 자신감 있게 나오므로 매끈함은 쓸모 있는 신호가 못 된다. 자기 이름으로 내놓기 불편한 결과물은 내놓지 않는다. 기준에 못 미친 것이 있으면 이유를 공유 설정, 훅, 테스트에 남겨 재발을 막는다. 취향은 그렇게 쌓이고, 왜 탈락했는지 적는 일 자체도 좋은 연습이다.

모델이 나보다 잘하게 될 텐데

한두 해 뒤면 모델이 내가 잡아낼 것을 다 잡아낼 텐데 왜 그 기술을 유지하느냐는 물음이 나올 수 있다. Osmani는 탐지에 관해서는 그 말이 상당 부분 맞을 수 있다고 인정하고, 자신도 탐지를 에이전트로 넘기자고 주장해 왔다고 말한다. 그래도 중요하다고 보는 이유는 책임이다. AI가 얼마나 도왔든 출시되는 것은 사람이 책임져야 한다.

특정 작업에서 에이전트를 얼마나 믿을지도 판단의 문제다. 모델이 틀리는 지점은 계속 바뀌므로, 작업을 검토하는 일이 보정된 상태를 유지하는 방법의 하나다. Anthropic이 자사 엔지니어와 연구자를 대상으로 한 연구는 이 함정을 감독의 역설이라고 부른다. “Claude를 감독하려면 AI 과용으로 퇴화할 수 있는 바로 그 코딩 기술이 필요하다.”

더 나은 모델이 풀어 주지 않는 질문도 있다. 무엇을 만드는가, 왜 그럴 가치가 있는가, 누구에게 영향을 주는가, 무엇을 희생할 것인가. 에이전트가 함께 따져 보는 데 도움이 될 수는 있어도 답은 본인 몫이다. 일과 점검의 상당 부분은 넘길 수 있지만 책임은 넘길 수 없다.

일상에서 할 일

전부 엄격하게 할 필요는 없고, 자기 작업 흐름에 맞는 것만 끼워 넣으면 된다고 그는 말한다.

• 일주일에 한 번 에이전트 없이 코드를 조금 쓰거나, 방법을 잊으면 곤란할 실제 일을 하나 한다. 그는 이것을 보정 연습이라고 부르며 도덕적 의미를 담은 말은 아니라고 덧붙인다.
• 한 달에 한 번 그만둔 일을 적고, 그중 무엇을 안 해도 괜찮은지 정한다. 그가 예전 글에서 던진 질문은 지금도 유효하다. AI가 없다면 얼마나 헤맬 것인가.
• 이해 범위를 넘는 것이 나오면 배운다. 글을 쓰다 처음 보는 표현을 만나면 한 줄 설명을 검색해 끼워 넣을 수도 있지만, 그는 조금 조사해서 그것이 어디에 들어맞는지 제대로 이해하는 쪽을 택한다.
• 기계를 제대로 확인하는 일은 실제 업무다. 아닌 척하면 팀은 결국 그 일을 하지 않게 된다. 공짜가 아니므로 일정에 항목으로 잡아 둔다.

쓰지 않는 기술은 사라지고, 그 속도는 짐작보다 빠를 것이다. 놓고 싶지 않은 기술은 계속 쓴다.

가져갈 것

글 끝에 그가 정리한 여덟 가지다.

1. 의도를 갖는다. 에이전트는 퀴즈를 내고 인터뷰하고 증거를 보여 줄 수 있지만, 그렇게 하도록 설정해 둘 때만 그렇다.
2. 스펙트럼에서 자신의 위치를 정직하게 본다. 에이전트의 도움을 받고도 답을 설명하지 못하면 항복한 것이다.
3. 가설을 갖는다. 틀린 가설이라도 묻기 전에 세운다.
4. 초록색 체크는 한 가지만 뜻한다. 무엇을 확인했고 무엇을 확인하지 않았는지 묻는다.
5. 증거를 찾는다. 요약을 읽기 전에 무엇을 실행했고 무엇이 돌아왔는지 읽는다.
6. 에이전트가 내린 결정을 알기 위해 읽는다. 나 대신 무엇을 정했는지 본다.
7. 프롬프트를 공들여 쓴다. 프롬프트를 쓰는 방식이 문제를 얼마나 이해했는지를 드러낸다.
8. 기준을 정하고 지킨다. 이름을 걸 수 없는 것은 내보내지 않는다.

당장 해 볼 일로 그는 한 가지를 권한다. 묻기 전에 어떤 결과가 나올지 적어 두고, 에이전트가 끝낸 뒤에는 에이전트가 확인하지 않은 것 하나를 적는다.

출처

• Addy Osmani (@addyosmani), “Critical thinking when agents do the work”, X 아티클, 2026-11-03. https://x.com/addyosmani/status/2117512471930167377
• 글에서 인용한 자료
  • Steven Shaw, Gideon Nave, 인지적 항복 논문. https://ssrn.com/abstract_id=6097646
  • Margaret-Anne Storey, 인지 부채. https://margaretstorey.com/blog/2026/02/09/cognitive-debt/
  • Addy Osmani, cognitive surrender. https://addyosmani.com/blog/cognitive-surrender/
  • Addy Osmani, comprehension debt. https://addyosmani.com/blog/comprehension-debt/
  • Addy Osmani, orchestration tax. https://addyosmani.com/blog/orchestration-tax/
  • Addy Osmani, intent debt. https://addyosmani.com/blog/intent-debt/
  • Addy Osmani, agentic verification. https://addyo.substack.com/p/agentic-verification
  • Andy Clark의 논문. https://pubmed.ncbi.nlm.nih.gov/40389440/
  • Claude Code 팀의 코드 리뷰 방식. https://claude.dev/blog/solving-code-review-at-anthropic/
  • Thariq Shihipar, blind spot pass. https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns
  • Boris Cherny의 게시물. https://x.com/bcherny/status/2007179861115511237
  • Anthropic 연구. https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic