[번역] 에이전트 시대의 비판적 사고

이번 포스팅에서는 Addy Osmani 의 글 Critical thinking when agents do the work를 번역해보려고 한다.

에이전트에게 코드와 문서를 맡기는 일이 늘었는데, 돌아온 결과를 정말 읽고 있는지 자신이 없는 개발자를 위한 글이다. 위임을 줄이자는 주장이 아니다. 위임하면서도 판단을 놓치지 않으려고 저자가 스스로에게 던지는 질문 여섯 개, 초록색 체크를 그대로 믿지 않는 검증 습관, 그리고 매주와 매달 할 수 있는 연습을 다룬다.

Addy Osmani 는 Google 에서 14년 넘게 일하며 Chrome, DevTools, Lighthouse, Core Web Vitals 의 개발자 경험을 이끌었고, 『Learning JavaScript Design Patterns』를 쓴 엔지니어다. 지금은 Anthropic 에서 Claude Code 를 만들고 있다. 원문은 2026년 11월 3일 X 아티클로 올라왔다.

용어는 원어를 살렸다. cognitive surrender 처럼 저자가 다른 연구자의 개념을 빌려 온 말은 첫 등장에만 우리말 풀이를 붙였다. 원문의 링크는 살렸고 같은 글을 가리키는 링크는 처음에만 걸었다. 본문에 인용된 문장은 해당 출처에서 문구를 다시 확인했다. 아래부터는 원문을 옮긴 것이고, 글 속의 "나"는 저자다.

비판적 사고가 어려워진 이유

예전에는 비판적 사고를 이렇게 배웠다. 새로운 정보를 겸손한 호기심과 적당한 의심으로 대하고, 여러 관점을 들어 본 뒤 자기 의견을 세우는 것. 지금도 맞는 말이다. 그런데 일의 상당 부분이 에이전트를 거쳐 가는 지금, 내 일상에는 비판적 사고를 강제하는 것이 점점 사라지고 있다. agentic workflow 에 완전히 올라탄 엔지니어와 프로덕트 담당자(여러 세션을 병렬로 돌리고 모델이 계속 좋아질 거라 기대하는 사람들)에게 먼저 말해 두고 싶다. 나는 이 도구들을 아주 좋아한다. 에이전트를 덜 쓰자고 이 글을 쓰는 것이 아니다.

내 목표는 무엇이든 에이전트에게 넘기기 쉬운 세상에서 당신이 비판적 사고를 유지하도록 돕는 것이다.

예전에는 인지적, 미적 판단의 대부분이 질문과 답 사이의 시간에 일어났다. 그 시간이 이제는 초 단위로 줄었다. agentic workflow 를 쓸수록 이 일은 더 어려워진다(다만 사람들이 예상한 방식으로 어려워지지는 않는다고 본다). 모델이 좋아질수록 눈에 띄는 오류의 비율이 낮아지기 때문이다. 많은(대부분의?) 결과물이 잘 쓰여 있고 대체로 맞을 것이다. 그런데 다시 들여다보게 만들지는 않는다.

에이전트를 여러 개 동시에 돌려도 결과물을 보는 눈은 여전히 한 쌍뿐이다.

비판적 사고는 하루 일과 안에 직접 끼워 넣어야 한다. 가만히 있으면 아무것도 대신 해 주지 않기 때문이다. 스스로 이것을 바로잡기 어려운 이유 중 하나는 agentic workflow 가 기분 좋기 때문이다. 바쁜 하루에 빠르고 편하고 자주 맞는 답을 받는 것은 상쾌한 일이다. 그리고 바로 그래서 경계를 늦추기 쉽다.

위임, 판단 맡기기, 항복

사람들과 이 이야기를 할 때 나는 이것을 하나의 스펙트럼으로 설명한다.

맨 위에는 cognitive offloading(인지 위임)이 있다. 일은 AI 에게 맡기되 결과의 주인으로는 내가 남는다. 나는 하루 종일 이렇게 일한다. 당신도 그러길 권한다. 가운데에는 deferral(판단 맡기기)이 있다. 도구의 출력이 그대로 다음 입력이 되고, 결과는 더 이상 가설로 취급되지 않는다. 맨 아래에는 cognitive surrender(인지적 항복)가 있다. AI 의 출력이 조용히 내 생각이 되어 버리고, 확인할 필요조차 느끼지 못한다.

cognitive surrender 는 와튼 스쿨의 Steven Shaw 와 Gideon Nave가 만든 말이다. 내가 보아 온 것과 꼭 맞는다. 신뢰가(혹은 게으름이) 커질수록 사람은 스펙트럼 아래로 흘러내린다. 그 이동은 좀처럼 눈에 띄지 않는다. 한 걸음 한 걸음이 완만하고 그럴듯해 보이기 때문이다. 지난번 답을 꼼꼼히 읽었으니 이번 답은 훑어본다. 그다음 답은 뼈대만 본다. 그러다 누가 한 줄을 짚어 물었을 때, 에이전트의 도움을 받아도 설명하지 못한다.

그것이 인지적 항복이다. cognitive debt(인지 부채)는 이렇게 쌓인다. 대개는 시스템에 대한 멘탈 모델을 꺼내 쓰려는 순간, 그런 모델이 없다는 것을 알게 되면서 드러난다. Margaret-Anne Storey 는 이것이 팀 안에서 시스템에 대해 함께 세운 이론(shared system theory)이 깎여 나가는 모습으로 나타난다고 썼다. 나는 코드 쪽의 같은 현상을 comprehension debt(이해 부채, Jeremy Twei 가 만든 말)라는 이름으로 쓴 적이 있다. 그 순간에는 전혀 보이지 않는다. 코드베이스는 깔끔해 보이고 테스트도 통과한다. 시스템을 고쳐야 할 때가 와서야 더 이상 아무도 그것을 이해하지 못한다는 사실이 드러난다. 전략 문서나 명세의 목차만 읽고 승인했을 때도 마찬가지다.

분명히 해 두자면, 불가능한 것을 요구하려는 것이 아니다. 큰 현대 코드베이스의 멘탈 모델을 통째로 머리에 들고 있는 것은 불가능하다. Claude Code 팀은 이해를 필요할 때 다시 세운다고 공개적으로 밝혔다. 어떤 부분을 알아야 할 때 전체 모델을 머리에 들고 있는 대신, Claude 에게 그 조각만 설명해 달라고 한다. 예전에 쓴 것처럼 이런 부채는 대부분의 엔지니어가 예상하는 것보다 회복하기 쉽다. 필요할 때 그 부분만 다시 세울 수 있다면 전체 모델을 유지할 필요는 없다. 다만 내가 무엇을 갖고 있지 않은지는 알아야 한다.

잘못돼도 잃을 것이 적은 일이라면 마음 놓고 통째로 맡겨도 된다. 에이전트를 거쳐서도 그 답을 설명하지 못한다면 주인 자리를 내준 것이다. 그게 늘 문제인 것도 아니다. 얼마 전 강의를 녹화하면서 평점이 비슷한 호텔 셋 중 하나를 촬영 장소로 골라야 했다. 리뷰를 일일이 읽을 시간이 없어서 결정을 AI 에게 넘겼다. 결과는 괜찮았고, 같은 상황이면 또 그렇게 할 것이다. 하지만 우리 집 돈을 어디에 투자할지, 아이들의 진로를 어떻게 조언할지, 혹은 회사에서 무엇을 만들지, 어떤 변경이 어떤 사용자에게 닿는지, 배포해도 안전한지를 정할 때는 그렇게 하지 않는다. 틀려도 대가가 작은 일은 넘기고, 그 결과를 다른 사람이 감당해야 하는 일에서는 추론을 손에 쥐고 있으라.

내가 나에게 묻는 질문

내 생각이 뭔지 나도 모를 때는 보통 이런 기본 질문 목록으로 돌아갔다. 내가 옳은 문제를 풀고 있다는 걸 어떻게 아는가? 옳은 방식으로 풀고 있다는 걸 어떻게 아는가? 내 결론을 뒷받침하는 증거가 있는가? 다 끝났다는 걸 어떻게 아는가? 대부분은 누가, 무엇을, 어디서, 왜, 언제, 어떻게다. 적어 놓고 보면 우스울 만큼 유치해 보이지만, 평소라면 지나쳤을 범주까지 생각하게 된다. 요즘은 이 모든 것을 건너뛰고 에이전트에게 내가 뭘 해야 할지 물어보기가 너무 쉽다. 지금 내가 스스로에게 묻는 새 버전의 질문은 이렇다.

묻기 전에 가설을 세웠는가? 사소하지 않은 일에 에이전트를 돌리기 전에, 머릿속으로라도 답이 무엇일지 적어 둔다. 엉터리 추측이어도 괜찮다. 새로운 정보를 보고 생각을 바꾸는 건 언제든 환영이다. 그런데 잘 쓴 답을 한번 읽고 나면 다른 가능성을 떠올리기가 어려워진다. 아무 실마리도 없다면 Thariq Shihipar 가 blind spot pass(사각지대 점검)라고 부르는 것을 요청하라. 내가 아는 것을 모델에게 주고, 내가 모르는 줄도 모르는 것을 찾게 하는 것이다.

생각을 돕게 하는가, 생각을 덜어 내게 하는가? 둘 다 괜찮다. 지금 어느 쪽을 하고 있는지만 알면 된다.

무엇이 사실이라면 이게 틀린 것이 되는가? 그리고 그걸 직접 확인하러 가라. 모델이 스스로 매긴 확신은 실제로 돌려 볼 수 있는 테스트 하나보다 훨씬 가치가 낮다. 그러니 모델에게 테스트를 하나 주라.

반대 논리를 다른 각도에서 들어 봤는가? 정답이 딱 정해지지 않은 편인 문제에서 내가 강한 입장을 정했을 때는, 모델 둘 이상에게 반대편을 논증하게 한 뒤 그 결과를 읽고 내 의견을 세운다. 시간은 더 들지만 그 주제를 훨씬 많이 알게 된다.

이걸 유지보수할 사람 앞에서도 이게 맞다는 데 내기를 걸 수 있는가? 코드에도, 내가 내놓는 다른 모든 것에도 해당한다. 나는 이것이 내가 한 일에 답할 수 있어야 한다는 기준선이라고 생각한다.

나는 무엇을 더 이상 연습하지 않는가? 일상적인 디버깅 일부일 수도 있다. 그중 일부는 놓아도 괜찮다. 다만 그게 의도한 것이었으면 한다.

검증을 습관으로

요즘 나는 검증에 대해 많이 쓰고 있다. 병목이 코드를 짜는 일에서 내가 옳다고 확신하는 일로 옮겨 갔다고 믿기 때문이다. 에이전트에게 자기 작업을 검증할 수단을 주면(end-to-end 테스트든, property 테스트든, 실제 앱을 조작해 보는 것이든) 에이전트는 내가 아무것도 보기 전에 변경을 만들고, 검증을 돌리고, 출력을 읽고, 다시 시도할 수 있다. Boris Cherny 가 "Claude 에게 자기 작업을 검증할 방법을 줘라"라고 부르는 것이 이것이고, 나는 이것이 좋은 결과를 얻는 데 가장 중요한 요소 중 하나라고 본다. 모든 줄을 읽는 대신 이런 루프를 만들고 그 증거를 검토하게 된다.

검증에서도 항복할 수 있다. "내 결론을 뒷받침하는 증거가 있는가?"가 "체크가 초록색이 됐나?"로 바뀐다. 에이전트 덕분에 테스트를 만드는 비용이 너무 싸져서 초록색을 많이 보게 될 텐데, 깨진 기능을 잡지 못하는 테스트가 통과하고 있을 수도 있다. 테스트와 기능에 같은 실수가 들어 있으면 테스트는 통과한다. 그리고 초록 체크 하나가 알려 주는 것은 한 가지 성질뿐이다. 그런데 그것이 모든 걸 덮는다고 상상하기가 너무 쉽다.

체크가 초록색이 되면 그게 무엇을 증명했는지 물으라. 그리고 무엇을 증명하지 못했는지 물으라. "검증됐다"의 정의는 미리 정해 두라. 결과가 나온 뒤에 정하면 어떤 결과든 합리화하게 된다.

에이전트 작업의 결승선은 손에 잡히는 것이어야 한다. 통과한 테스트, 스크린샷, 로그나 trace 같은 것이다. 그래야 끝났다는 기준이 사실이 되고, "다 된 것 같은데" 같은 해석(그리고 항복)에 맡겨지지 않는다. 에이전트에게서 완료 알림을 받으면 요약을 보기 전에, 실행된 명령의 코드와 그 출력부터 확인하라.

Claude Code 는 새 컨텍스트에서 띄운 subagent 로 자기 작업을 비판적으로 검토하게 해서 기본적인 점검을 할 수도 있다. 이걸 루프 안에 넣어 두어서, 내가 떠올릴 때만이 아니라 매번 돌게 만들 만하다. 나는 마지막에 아직도 "내가 뭘 놓쳤지?"라고 묻는다. 우스워 보이지만, frontier 모델로 복잡한 기능 작업을 끝내고 직접 보고 리뷰한 뒤에 "내가 뭘 놓쳤지?"라고 물으면 정말 자주 두세 가지가 더 돌아온다. 그래서 나는 늘 묻는다.

물론 이 모든 걸 매번 할 필요는 없다. 언제 깊게 들어갈지 아는 것도 기술이다. 우리 Claude Code 팀이 코드 리뷰를 어떻게 하는지 정리한 글에서 내가 가장 좋아하는 경험칙은 이것이다. "체크가 무엇을 놓칠지 말할 수 없다면, 빠른 승인 말고 제대로 된 리뷰를 요청하라."

이건 코드 밖에도 해당한다. 에이전트가 고객 통화 50건이나 경쟁사 분석을 종합해 줬다면, 원본 문서 두어 개를 직접 열어 요약이 정확한지 확인하라. 내 권고의 근거가 되는 숫자 하나를 골라 제대로 계산됐는지 확인하라. 에이전트 덕분에 검증을 준비하는 일은 싸졌다. 어려운 것은 좋은 검증이 어떤 모습인지 아는 일이다.

생성된 것을 실제로 보기

에이전트가 600줄짜리 PR 을 줬다고 하자. 구조를 대충 훑는다. 모든 줄을 읽지는 않는다. 변수 이름도 그럴듯하고 테스트도 통과하니 승인한다. 그런데 그 중간 어딘가에 트랜잭션 경계의 순서가 미묘하게 바뀌어 있거나, 한 번도 생각해 보지 않은 edge case 의 기본값이 뒤집혀 있다. 리뷰를 하긴 한 셈이다. 다만 이미 찾을 줄 알고 있던 것만 봤을 뿐이다.

코드를 짜는 것과 리뷰하는 것은 다른 기술이고, 리뷰가 rubber stamping(형식적 승인)으로 변하는 지점이 있다. 그러니 diff 를 AI 가 쓰지 않은 것처럼 읽고, 그다음 diff 너머에서 에이전트가 무엇을 결정했는지 보라. 긴 세션 동안 에이전트는 작은 결정을 많이 대신 내린다. 기본값을 무엇으로 할지, 무엇을 범위 밖으로 둘지, 요구 사항 둘이 부딪힐 때 어느 쪽을 다시 해석할지 같은 것들이다.

"다 잘 됐습니다"라는 요약에는 그중 어느 것도 보이지 않는다. 그러니 에이전트에게 자기가 내린 결정과 가정을 나열하게 하라. 그다음 스스로에게 퀴즈를 내라. 아무 줄이나 몇 개 골라 "이 줄은?" "저 줄은?" 하고 물어보는 것이다. 문서라면 닫아 놓고 핵심 논지를 기억만으로 적어 보라. 긴 세션에서 어떤 사람들이 쓰는 습관 중 내가 좋아하는 것이 있다. Claude 에게 변경 사항 보고서를 쓰게 하고 맨 아래에 퀴즈를 내게 한 뒤, "퀴즈를 만점으로 통과해야만 머지한다"는 규칙을 두는 것이다. 배포하는 것을 변호할 수 있을 만큼 이해하라. 언젠가 누군가 물어볼 수 있으니까.

에이전트는 주의력을 지켜 주는 데도 쓸 수 있다. 예를 들어 내가 관리하는 오픈소스 프로젝트에는 PR 이 많이 들어온다. 에이전트의 도움을 받아 무엇이 들어오는지, 무엇이 가이드라인에 어긋나는지, 어디에 내 주의가 필요할 것 같은지를 가려낸다. 그 판단을 에이전트가 혼자 내리게 두는 일은 드물지만, 내가 집중할 곳을 좁혀 줄 수는 있다. 그러면 나는 그 변경이 옳은 문제를 옳은 방식으로 풀고 있는지를 실제로 생각할 수 있다.

그리고 양의 문제가 있다. 이건 스스로에게 정직해야 한다. 나는 이것을 orchestration tax(조율 비용)라고 불렀다. 에이전트가 만들어 내는 양과, 내 이름을 걸어도 괜찮다고 느끼는 양 사이의 차이다. 끝난 작업이 내가 소화하는 속도보다 빨리 쌓인다면, 그걸 고치기 전까지 세션을 하나 더 여는 것은 도움이 되지 않는다. 체크를 조여서 내가 봐야 할 양을 줄이든지, 속도를 늦추라. 내가 책임질 수 있는 것보다 많이 만들어 내고 있다면 그건 더 이상 리뷰가 아니다. 운에 맡기는 것이다.

좋은 입력, 좋은 출력

사람의 멘탈 모델은 여전히 관여한다. 다만 그 자리가 가운데가 아니라 앞과 끝이다. 에너지를 앞쪽의 작업 설명과 컨텍스트에, 그리고 뒤쪽의 출력 리뷰에 쓰게 된다. 그래서 좋은 입력이 출력의 품질에 그만큼 중요하고, 나는 좋은 프롬프트 작성을 비판적 사고의 기술로 본다.

예전에는 막연한 요청을 하면 누군가 그걸 되물었고, 그러다 "아, 나 이거 사실 정리 안 했구나" 하고 깨닫곤 했다. 에이전트는 거기서 멈춰 세우지 않을 때가 많다. 빠진 부분을 알아서 채우고, 그 바탕의 생각은 여전히 흐릿한데도 다 된 것처럼 보이는 결과를 건넨다. 나는 이것을 intent debt(의도 부채)라는 이름으로 쓴 적이 있다. 내가 쓰지 않은 산출물 안에 들어 있을 수 있는 암묵적인 목표, 제약, 근거를 말한다. 다른 부채와 달리 이건 누구도 대신 갚아 줄 수 없다. 의도는 나에게서 나와야 한다.

프롬프트는 문제를 얼마나 이해했는지를 비춘다. 그걸 명확히 말하지 못한다면 내 머릿속에서도 명확하지 않은 것일 수 있다. 도움을 청하기 전에 요청 개요를 내 말로 직접 쓰라. 대상 독자, 범위 밖의 것, 완료의 정의를 적는다. 두 번째 수정 요청으로도 원하는 데 닿지 못했다면, 조금씩 고치는 걸 멈추고 프롬프트를 새로 쓰라.

이 일에도 에이전트의 도움을 받을 수 있다. 나는 Andy Clark 가 AI 시스템에 위임하는 것과 협업하는 것을 구분한 방식을 좋아한다. 협업에서는 서로를 키우는 선순환에 들어간다. 프롬프트가 출력을 다듬고, 그 출력이 다음 프롬프트를 다듬고, 문제에 대한 멘탈 모델까지 다듬는다. 정리가 안 됐다면 에이전트에게 자기가 이해하지 못한 것에 대해 나를 인터뷰하게 하라. 세션을 닫을 때 내 멘탈 모델이 다듬어져 있다면 성공했다는 신호다.

입력도 조심하라. 에이전트가 앞 에이전트의 요약만 자기 컨텍스트로 넘겨받기 쉽다. 그러다 보면 세 번째 에이전트는 원본 문서를 한 번도 읽지 않은 상태가 된다.

출력에 대한 나만의 기준도 필요하다. 나는 여러 창작 매체에서 AI 를 이것저것 써 봤는데, 그 대부분은 내 기준에 못 미쳐서 아무에게도 보여 주지 않았다. 모든 것이 깔끔한 서식과 자신 있는 어조로 나오기 때문에, 매끈함은 더 이상 쓸모 있는 신호가 아니다. AI 덕분에 만드는 속도는 빨라졌을지 모른다. 그래도 그 결과물을 내 이름으로 내놓기가 편하지 않다면 내놓지 않는다.

기준에 못 미치는 것이 있으면 그 이유를 공유 설정이나 hook, 테스트에 적어 두어 다시 일어나지 않게 하라. 안목은 그렇게 쌓인다. 그리고 무엇이 왜 탈락했는지 적는 일 자체가 좋은 연습이다.

"그래도 모델이 나보다 잘하게 될 텐데"

이 분야의 미래를 내 주변의 많은 사람만큼 낙관한다면, 앞의 몇 절을 읽는 동안 이런 생각이 들었을 것이다. 1~2년 뒤면 내가 잡아낼 수 있는 것을 모델도 잡아낼 텐데, 왜 굳이 그 기술을 유지해야 하지?

그 탐지의 상당 부분에 대해서는 당신이 맞을 수 있다. 나 자신도 탐지를 점점 더 에이전트에게 넘기자고 주장해 왔다. 그래도 이것이 여전히 중요하다고 생각하는 이유는 이렇다. 결국 배포되는 것에는 누군가 책임을 진다. AI 가 얼마나 도왔든 사람이 책임을 져야 한다.

어떤 일에 에이전트를 얼마나 믿을지는 그 자체가 판단의 문제다. 그 판단의 눈금을 맞춰 두는 일의 일부가 작업을 리뷰하는 것이다. 모델이 틀리는 지점이 계속 바뀌기 때문이다. Anthropic 이 자사 엔지니어와 연구자를 대상으로 한 연구도 이 함정을 짚으면서 paradox of supervision(감독의 역설)이라고 부른다. "Claude 를 감독하려면 바로 그 코딩 기술이 필요한데, 그 기술은 AI 를 과하게 쓰면 쇠퇴할 수 있다."

나에게 가장 중요하고 더 나은 모델이 해결해 주지 않을 것들이 있다. 무엇을 만드는가, 왜 만들 가치가 있는가, 누구에게 영향을 주는가, 무엇을 기꺼이 포기할 것인가. 모두 당신이 답해야 하는 질문이다. 에이전트는 그 답을 찾아가는 데 도움이 될 수 있고, 나도 그러기를 바란다. 하지만 결국 그 질문은 여전히 당신의 것이다. 일은 넘길 수 있고 검토의 상당 부분도 넘길 수 있다. 하지만 책임은 넘길 수 없다.

매일의 연습

이 모든 걸 엄격하게 할 필요는 없다. 내 작업 방식에 맞는 것만 끼워 넣으면 된다.

일주일에 한 번은 에이전트 없이 코드를 조금 짜거나, 잊어버리면 곤란할 실제 일을 하나 직접 해 보라(나는 이것을 calibration exercise(눈금 맞추기 연습)라고 불렀지만, 훈계하려는 말은 아니다). 한 달에 한 번은 내가 그만둔 일을 적고, 그중 무엇을 안 해도 괜찮을지 정하라. 예전 블로그 글의 질문 하나는 지금도 그대로 유효하다. AI 가 없다면 나는 얼마나 길을 잃을까?

이해가 안 되는 것이 있으면 가서 배우라. 글을 쓰다가 처음 보는 표현을 만나면 Google 에서 한 줄 설명을 찾아 넣을 수도 있다. 나는 조금 더 조사해서 제대로 이해하는 쪽을 택한다. 그래야 그것이 어디에 들어맞는지 보인다.

기계가 한 일을 제대로 확인하는 것은 진짜 일이다. 아닌 척하면 팀은 결국 그 일을 하지 않게 된다. 공짜가 아니니 일정에 한 항목으로 잡아 두라. 그래야 실제로 하게 된다.

쓰지 않는 기술은 사라진다. 아마 생각보다 빨리. 놓고 싶지 않은 기술은 계속 쓰라.

가져갈 것

• 의도적으로 설정하라: 에이전트는 퀴즈를 내고, 인터뷰하고, 증거를 보여 줄 수 있다. 단 그렇게 설정했을 때만이다. 그러니 설정하라.
• 스펙트럼 위의 내 자리에 정직하라: 에이전트의 도움을 받아도 답을 설명하지 못한다면 그 답에 항복한 것이다.
• 가설을 세워라: 엉터리여도 좋으니 묻기 전에 하나 세운다.
• 초록 체크는 한 가지만 뜻한다: 무엇을 확인했는가? 무엇을 확인하지 않았는가?
• 증거를 찾아라: 요약을 읽기 전에 무엇을 실행했고 무엇이 돌아왔는지 읽는다.
• 어떤 결정을 내렸는지 읽어라: 에이전트가 나 대신 무엇을 정했는가?
• 프롬프트를 다듬어라: 프롬프트를 어떻게 쓰는지가 문제를 얼마나 이해했는지 보여 준다.
• 기준을 정하고 지켜라: 내 이름을 걸 수 없다면 내보내지 않는다.

중요한 기술은 직접 써먹으면서 손을 놓지 마라. 해 볼 만한 것 하나를 권한다. 묻기 전에 무슨 일이 일어날지 적고, 에이전트가 끝난 뒤에는 에이전트가 확인하지 않은 것 하나를 적으라. 그게 출력을 읽는 방식을 바꾸는지 알려 달라. 독립적으로 생각하라. 더 나은 질문을 하라. 결과에 책임을 져라.

필자의 생각

AI 가 중요하다는 것은 분명하다. 그래도 지금 필자가 먼저 고르고 싶은 것은 기술 스택을 넓히는 일이 아니라, 사고하는 능력과 판단의 기준을 만드는 일이다.

저자가 경계하는 cognitive surrender 는 판단을 에이전트에게 넘겨 버리는 일이다. 필자도 AI 와 자동화 도구를 적극적으로 쓰되, 사고 자체를 맡기기보다 사고의 생산성을 높이는 쪽으로 쓰고 싶다. 이 우선순위를 왜 그렇게 정했는지는 생각을 증명하는 과정에 따로 적었다.