인지적 항복
TMT인지적 오프로딩(cognitive offloading)은 AI에게 일을 맡기되, 최종 책임은 여전히 내가 지는 상태입니다. 인지적 항복(cognitive surrender)은 AI가 내놓은 결과가 어느새 내 결과가 되어버리고, 내가 따로 확인해야 할 것이 남아 있다고 느끼지 못하는 상태입니다. 소프트웨어 엔지니어에게 이 둘 사이의 경계는 매일 발밑에서 움직이고 있고, 우리 대부분은 그것을 자각하지 못한 채 그 선을 넘고 있습니다.
어제 들은 표현 하나를 이야기해보고 싶습니다. 바로 **인지적 항복(cognitive surrender)**입니다. 이 용어는 와튼 스쿨(펜실베이니아 대학교)의 최근 논문, Steven Shaw와 Gideon Nave의 “Thinking - Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender.”(“생각하기 - 빠르게, 느리게, 그리고 인공지능: AI가 인간의 추론 방식을 어떻게 바꾸고 있는가, 그리고 인지적 항복의 부상”) 에서 가져온 것입니다. 신학적인 맥락에서 더 오래된 뿌리가 있는 표현이지만, AI를 중심에 둔 이 새 프레이밍은, 옆자리에 에이전트를 두고 코드를 배포하는 사람이라면 누구에게나 강하게 와닿는 개념입니다.
이들이 나눈 구분은 꼭 기억해둘 만합니다.
- 인지적 오프로딩은 계산기, 검색 엔진, GPS 같은 것입니다. 어떻게(how) 하는지는 외부에 맡기지만, 무엇(what) 인지는 여전히 내가 쥐고 있습니다. 결과가 말이 되는지 스스로 판단하고, 그렇지 않을 땐 개입합니다.
- 인지적 항복은 아예 답을 스스로 구성하지 않는 상태에서 벌어집니다. AI가 낸 답이 곧 내 답이 됩니다. 비교할 만한 나만의 관점을 만들어보지 않았기 때문에, 그 결과를 덮어쓸 이유도, 덮어쓰지 않을 이유도 없는 상태죠.
Shaw와 Nave는 세 번의 실험과 1,372명의 참가자를 통해, AI가 “있기만 해도” 사람들이 쉽게 항복한다는 사실을 보여줍니다. AI가 틀린 답을 내놓은 시도에서조차, 참가자들은 그 오답을 73%나 그냥 받아들였습니다. 더 나쁜 점은, 절반의 답이 의도적으로 틀리게 설정되어 있었는데도, AI가 있을 때 사람들의 자신감 이 오히려 올라갔다는 겁니다. 사람들은 모델의 (항상 꽤 높은) 확신을 빌려와, 그것을 자신들의 확신으로 착각하고 있었던 겁니다.
이 “빌려온 확신(borrowed-confidence)” 효과가 등장하는 지점부터, 이 이야기는 단순한 일반 인지 이야기에서 벗어나, 소프트웨어 엔지니어링의 이야기로 들어갑니다.
우리 일이 ‘항복’으로 이어지는 지점들
대부분의 사람들은 쉬운 일에서는 항복하지 않습니다. 에이전트가 없는 API를 지어내거나, 존재하지 않는 import를 가져오면 금방 눈치챕니다. 항복은 더 아래 층위, 내가 독자적인 관점을 세워보는 비용이, 그 일을 하는 것 자체보다 더 커 보이는 순간들에서 벌어집니다.
제가, 주로 제 자신에게서, 이런 일이 일어나는 걸 본 몇 가지 순간들입니다.
Diff 읽기. 에이전트가 600줄짜리 PR을 만들어냅니다. 대충 훑어봅니다. 변수명도 그럴듯합니다. 테스트도 모두 통과했습니다. 승인 버튼을 누릅니다. 그런데 어딘가 중간에는 트랜잭션 경계의 미묘한 순서 변경이 들어가 있거나, 엣지 케이스에 대한 기본값이 내가 예상하지 못한 방향으로 바뀌어 있을 수 있습니다. 이건 리뷰가 아니라, 그냥 승인(ratification)입니다. 항복이 일어나는 순간은, “판단의 부재” 그 자체입니다.
완전히 이해하지 못한 에러 디버깅. 스택 트레이스가 무섭게 보입니다. 그걸 에이전트에게 붙여넣습니다. 해결책이 돌아옵니다. 그 해결책이 작동합니다. 그대로 넘어갑니다. 두 주쯤 뒤에 비슷한 증상이 다시 나타났을 때, 문득 깨닫습니다. 사실 나는 애초에 그 버그를 이해하지 못했었다는 것을. 나는 단지 그 버그의 “겉으로 드러난 증상”만 없애버린 겁니다. 이제 내 머릿속의 시스템 정신 모델(mental model)은, 어디가 잘못됐는지 짚지도 못하는 지점에서 이미 틀어져 있습니다.
설계 결정을 내릴 때. 두 서비스 간에 큐를 둘지, 직접 호출을 할지 애매합니다. 에이전트에게 묻습니다. 에이전트는 그럴 듯한 단락짜리 근거와 함께 둘 중 하나를 골라줍니다. 나는 그대로 따릅니다. 처리량, 실패 모드, 재처리(replay) 시맨틱을 스스로 따져보지 않았습니다. 문제를 바라보는 관점과 그에 대한 답을, 모델이 제시한 걸 통째로 가져다 쓴 겁니다.
새로운 것을 배울 때. 이 부분은 Anthropic의 skill-formation 논문이 숫자로 보여줍니다. 새 라이브러리를 배우면서 AI에게 코드 생성을 맡긴 엔지니어들은, 나중에 치른 이해도 테스트에서 대조군보다 평균 17% 낮은 점수를 받았습니다. 반면, 개념 질문과 탐색(conceptual inquiry) 에 AI를 쓴 엔지니어들은 자신의 이해도를 지켜냈습니다. 같은 도구인데, 취하는 자세(posture) 가 결과를 갈랐습니다.
이 모든 사례를 관통하는 공통점은 같습니다. 모델이 “완결된 답”을 내놓았고, 우리는 그걸 받아들이는 순간, 내 쪽의 평행한 관점 구축을 멈췄다는 것입니다. 어떤 때는 그게 옳을 수 있습니다. 어떤 때는 그게 항복입니다. 안쪽에서 느껴지는 감각만 놓고 보면, 둘은 거의 구분되지 않습니다.
이해 부채(comprehension debt)와의 연결
예전에 저는 이해 부채(comprehension debt) 에 대해 쓴 적이 있습니다. 이는, 시스템 안에 존재하는 코드의 양과, 그 코드 중 실제로 어떤 인간이 “진짜로 이해하고 있는” 부분의 양 사이에서 벌어지는 간극이 점점 커지는 현상을 말합니다. 인지적 항복은, 이해 부채가 쌓이는 메커니즘입니다.
각각의 항복 행위는 아주 작은 대출 한 건입니다. 코드베이스는, 내가 완전히 이해하지 못한 패치 하나를 더 안게 됩니다. 아키텍처는, 내가 직접 내리지 않은 결정을 하나 더 품게 됩니다. 테스트 스위트는, 내가 직접 정의하지 않은 테스트를 하나 더 떠안게 됩니다. 이런 일들은, 그 일이 일어나는 바로 그날에는 아무 문제처럼 느껴지지 않습니다. 그런데, 이게 복리로 쌓입니다.
MIT의 Your Brain on ChatGPT 논문은 같은 패턴을 신경 수준에서 보여줍니다. AI에 기댄 글쓰기를 한 사람들은, 측정 가능한 수준의 신경 연결성 감소, 방금 쓴 내용을 더 약하게 기억하는 경향, 자신의 추론 과정을 다시 재구성하는 데 어려움을 보였습니다. 저자들은 이를 기술 부채에서 빌려온 표현으로 인지 부채(cognitive debt) 라고 부릅니다. 단기적인 이득을 위한 선택이지만, 장기적인 비용은 점점 커지는 형태의 부채라는 뜻입니다.
이제 이 두 프레임을 합쳐봅시다. 인지적 항복은 인지 부채를 떠안는 방식이고, 이해 부채는 그 청구서입니다. 잃어버린 정신 모델의 크기로 청구서가 발행되는 셈입니다. 그리고 그 이자는, 무언가 잘못되었을 때 팀에 있는 누구도 시스템을 1원칙부터 다시 세워볼 수 없게 되는 순간에 지불됩니다.
AI 자체가 부채를 만들어내는 건 아닙니다. 우리가 AI를 대하는 자세가 부채를 만듭니다. 같은 모델이라도, 어떤 엔지니어의 정신 모델은 텅 비게 만들고, 또 다른 엔지니어의 정신 모델은 더 날카롭게 다듬어줄 수 있습니다. 둘을 가르는 건, 그들이 AI를 “생각하기 위한 도구로” 쓰는지, “생각 대신” 쓰는지입니다.
소프트웨어 엔지니어가 유난히 취약한 이유
우리 일이 가진 몇 가지 특성은, 평균적인 지식 노동자보다 우리가 이 문제에 더 취약하게 만듭니다.
겉보기에 맞는 신호들이 기본값으로 깔려 있다. 생성된 코드는 컴파일됩니다. 린터를 통과합니다. 돌아갑니다. 옆 줄의 코드와도 잘 섞여 보입니다. 대부분의 도메인에는, AI 출력이 “그럴듯해 보인다”는 느낌을 줄 만큼 강력한 필터가 없습니다. 우리 도메인에는 있습니다. 하지만 그건 잘못된 필터입니다. 겉으로 맞는 코드와 시스템 수준에서 맞는 코드는 다릅니다. 그리고 바로 그 사이 간극이, 항복이 숨어드는 지점입니다.
눈에 보이는 메트릭은 처리량뿐이다. 머지된 PR 개수, 배포된 기능 수, 닫힌 티켓 수. 이런 것들은 “내가 이걸 만들었고 잘 이해하고 있다”와 “에이전트가 만들었고 난 승인만 했다”를 전혀 구분해주지 않습니다. 조직은 단기적으로 두 경우를 똑같이 보상합니다. 항복은 대시보드에서 보이지 않습니다.
확신이 너무 말끔하게 전이된다. 모델은 단정문으로 말합니다. 코드 리뷰는, 단정문을 권위로 읽는 경향이 있습니다. 에이전트가 “여기서 300ms 디바운스를 쓰는 이유는 잔끊김(jank)을 방지하기 위해서입니다.”라고 쓸 때, 그 숫자를 즉석에서 지어냈더라도, 그 문장은 조직의 축적된 지식처럼 들립니다. 우리는 모델의 확신만 깔끔하게 물려받고, 그 뒤에 실제로 존재하지 않는 추론은 전혀 물려받지 못합니다.
일이 합성(composition) 가능하다. 한 번의 항복은, 그다음 항복을 더 쉽게 만듭니다. 한 번 제대로 이해하지 못한 코드를 받아들인 순간, 다음에 그 코드를 수정하는 작업은 거의 확실하게 또 다른 항복이 됩니다. 독립적인 관점을 새로 만들려면, 지난번에 건너뛴 부분부터 다시 복원해야 하기 때문입니다. 항복은 경로 의존적(path-dependent)입니다.
여기서 제가 주장하고 싶은 건 “AI 코딩 도구를 쓰지 말자”가 아닙니다. 도구보다 중요한 건 자세이고, 우리는 아직 그에 맞는 습관들을 충분히 갖추지 못했습니다.
캘리브레이션(calibration)의 질문
Shaw 본인은 이 문제를 두고 과도하게 공포를 조성하지 않으려 조심합니다. 그가 제시하는 프레이밍은, 이 도구들을 진지하게 사용하는 사람이라면 누구에게든 그대로 전해주고 싶은 문장입니다.
요지는 이렇습니다. 인지적 항복은 “AI가 나쁘다”거나 “AI를 쓰는 게 비합리적이다”라는 뜻이 전혀 아닙니다. 많은 상황에서 AI는 우리의 판단을 더 좋게 만들어줍니다. 핵심은 캘리브레이션, 즉 AI가 내가 생각하는 걸 도와주는 순간과 조용히 나 대신 생각해버리는 순간을 구분할 줄 아는 능력입니다.
그래서 스스로에게 계속 던져야 할 질문은 이겁니다. “나는 지금 이 답에 대해 독립적인 관점을 만들고 있는가, 아니면 에이전트의 관점을 고스란히 받아들이고 있는가?” 이 둘은 외부에서 보면 똑같이 보이는, 서로 다른 심리적 행위입니다.
제가 이 경계의 “오프로딩 쪽”에 머물기 위해 쓰기 시작한 몇 가지 휴리스틱은 이렇습니다.
출력을 보기 전에, 먼저 내 기대를 구성한다. 비(非) 사소한 일을 에이전트에 맡기기 전에, 먼저 (머릿속으로만이라도) “내가 생각하는 답이 어떤 모양이어야 하는지”를 적어봅니다. 세 줄짜리일 수도, 쉰 줄짜리일 수도 있습니다. 큐를 쓸지, 직접 호출을 할지. 버그가 어느 모듈에 있을지. 에이전트의 답이 내 기대와 맞으면, 나는 어느 정도 캘리브레이션이 된 상태입니다. 맞지 않는다면, “내가 틀렸는지, 모델이 틀렸는지”라는 실제 선택지가 생깁니다. 항복은 이 선택 과정을 건너뛸 때 일어납니다.
“AI가 쓴 코드”라는 사실을 잊고 diff를 읽는다. 마치 팀의 주니어 엔지니어가 이 PR을 올렸다고 상상합니다. “테스트가 통과했으니 됐다”는 이유만으로 머지했을까요? 아마 아닐 겁니다. 저자가 모델로 바뀌었다고 해서, 리뷰의 역할이 바뀐 건 아닙니다. 여전히 “그럴듯해 보인다” 는 기준만으로는 리뷰가 아닙니다.
모델에게 스스로를 반박하게 한다. 대부분의 모델은 처음에는 매우 확신에 찬 답을 내놓고, “이제 네가 방금 한 말을 반박해봐”라고 요청하면, 같은 확신의 강도로 반대 주장을 내놓기도 합니다. 이 두 번째 패스는 비용이 거의 들지 않으면서, “빌려온 확신”을 깨뜨려줍니다. 둘 중 어느 쪽이 맞는지 스스로 논리적으로 가늠할 수 없다면, 방금 내가 항복하려던 자리를 발견한 것입니다.
내가 피곤할 때를 알아챈다. 항복은 피로 현상입니다. 하루 첫 번째 PR은 제대로 리뷰하지만, 다섯 번째 PR쯤 되면 슬쩍 훑어보고 넘어갑니다. 믿을 만한 시니어 엔지니어들은 모두, 각자 방식으로 같은 결론에 도달했습니다. “내가 평가할 기운이 없을 때는 에이전트에게 생성을 시키지 않는다.” 이 자기 인식 역시 이제는 일의 일부입니다.
내 확신이 어디에서 오는지 지켜본다. 회의에서 어떤 설계 결정을 옹호하고 있는데, 사실 “왜 그렇게 결정했는지”를 다시 말해보라면, 떠오르는 건 “에이전트가 그렇게 제안했고 당시엔 합리적처럼 보였다” 정도밖에 없다면, 나는 모델의 확신만 물려받고, 그 밑바탕이 될 논리를 하나도 가져오지 못한 셈입니다. 이건 항복의 흔적입니다. 그 대화가 더 진행되기 전에 코드로 돌아가, 그 결정의 “왜” 를 다시 쌓아올려야 합니다.
항복을 어렵게 만드는 엔지니어링 설계
개인적인 휴리스틱도 중요하지만, 이 문제에는 구조적인 버전도 있습니다. 제가 지난 몇 달 동안 써온 글들(Agent Skills, agent harness engineering, 이해 부채 글)은 대부분, 항복이 어려워지도록 발판(scaffolding)을 쌓는 방법에 관한 이야기였습니다.
그중에서도 잘 버티는 몇 가지 설계 움직임을 짧게 정리해보면 이렇습니다.
검증을 “하드 종료 조건”으로 삼기. 에이전트가 끝낸 모든 작업에는, 반드시 구체적인 증거가 따라붙어야 합니다. 실행되는 테스트, 스크린샷, 로그, 런타임 트레이스, 리뷰어의 승인 같은 것들 말이죠. “이제 다 된 것처럼 보인다” 는, 항복이 스며들기 쉬운 종료입니다. “이게 작동한다는 증거가 여기 있다” 는, 항복에 저항하는 종료입니다. 이 “증거 요구사항”을 워크플로에 아예 박아두면, 항복으로 가는 가장 쉬운 길을 없애버릴 수 있습니다.
안티-합리화(anti-rationalization) 테이블. Agent Skills의 가장 독특한 설계 선택 중 하나는, “흔히 나오는 변명”과 그에 대한 “사전 작성 반박문”을 한 쌍으로 유지하는 것입니다. 이는 동시에 항복에 대한 방어 장치이기도 합니다. “이 작업은 너무 단순해서 스펙까지는 필요 없다.” → “여전히 수용 기준(acceptance criteria)은 필요하다.” 와 같이, 모델(혹은 금요일 오후의 피곤한 나 자신)이 아직 만들어내지 않은 변명에 대해, 미리 반박문을 적어 두는 겁니다. 모델은 “이번만은 절차를 건너뛰어도 되는 것처럼 보이는” 그럴듯한 이유를 만들어내는 데 매우 능숙합니다. 안티-합리화 테이블은, 그날그날 그 변명과 논쟁을 벌이지 않겠다는 선언입니다.
작은 범위, 작은 PR. 항복은 크기에 비례해 커집니다. 50줄짜리 변경은 실제로 다 읽을 수 있지만, 600줄짜리는 거의 불가능합니다. 구글의 PR 크기 ~100줄 권장 규범은, 본래는 사람을 위한 기준이지만, 같은 이유로 AI 항복에도 효과적으로 대항합니다. 리뷰의 단위는 곧 이해의 단위입니다. 이해할 수 있는 크기까지, 이 단위를 잘게 쪼개야 합니다.
배울 때는 생성보다 개념 질문. skill-formation 논문 의 결론을 습관으로 옮기면 이렇습니다. 어떤 라이브러리나 시스템에 처음 진입할 때, 에이전트에게 코드를 “생성해달라”기보다, 먼저 설명해달라, 트레이드오프를 풀어달라고 요청하는 편이 좋습니다. 같은 도구라도, “캐묻는 모드”로 사용할 때는 내 정신 모델을 구축하는 데 기여하고, “생성 모드”로만 사용할 때는 그 모델을 깎아 먹습니다. 데이터는 이 점에서 매우 분명하고, 모드를 바꾸는 비용은 거의 들지 않습니다.
설계 차원에서 도입하는 마찰(friction). arXiv의 “Cognitive Agency Surrender” 논문은 Scaffolded Cognitive Friction 이라는 개념을 제안합니다. 즉, “그냥 그럴듯해 보인다”는 이유로 결과를 받아들이는 휴리스틱을 깨기 위해, 의도적으로 저항 지점을 만들어두자는 아이디어입니다. 엔지니어링 언어로 옮기면 이렇습니다. 생성 전 필수 설계 문서, 머지 전 확인 단계, 배포 전 체크리스트. 생산성 담론에서는 마찰이 대체로 나쁜 것처럼 이야기되지만, 바로 이 마찰이, 오프로딩과 항복 사이를 갈라놓는 장벽 역할을 합니다.
매주, 에이전트 없이 혼자 키보드 잡는 시간. 매주 일정 시간은 에이전트 없이 코드 쓰기를 해보는 겁니다. 도덕적인 훈련이라기보다는, 캘리브레이션 훈련에 가깝습니다. “에이전트 도움 없이 간단한 것조차 불편해졌다”고 느끼는 날이 오면, 이미 오프로딩이 항복으로 넘어간 뒤인데, 내가 거기까지 온 줄도 모르는 상태인 겁니다.
“대리(delegation)”가 아닌 상호 증폭(mutual amplification)
마지막으로 남기고 싶은 프레임은 비관적인 것이 아닙니다. Andy Clark는 Time 지에서 이 연구를 인용하며, 아주 좋은 구분을 짚어줍니다. 그는 AI 시스템에게 업무를 위임(delegating to) 하는 것과, 그 시스템과 함께 협력(cooperating with) 하는 것을 구분합니다. 위임은 항복을 낳고, 협력은 그가 상호 증폭(mutual amplification) 이라고 부르는 상태를 만들어냅니다. 내 프롬프트가 모델의 출력을 더 날카롭게 만들고, 그 출력이 다음 프롬프트를 더 정교하게 만들고, 그 과정이 다시 내 문제 모델을 더 뚜렷하게 해 주는 루프 말입니다.
이 둘은 감각적으로도 다릅니다. 상호 증폭이 일어날 때는, 대화를 하는 동안 “이 대화를 통해 도메인을 더 잘 배우고 있다” 는 느낌이 듭니다. 대화가 없었다면 스스로 공부했어야 할 것들을, 그 대화 속에서 더 빨리 흡수하고 있다는 느낌이죠. 세션을 마칠 때, 시작할 때보다 정신 모델이 더 선명해져 있습니다. 여전히 혼자서도 그걸 구현해낼 수 있지만, 단지 더 빠른 길을 택했을 뿐입니다. 에이전트는 방 안의 “두 번째 엔지니어”이지, 유일한 엔지니어가 아닙니다.
항복의 자세는 그 반대입니다. 세션이 끝났을 때, 이 문제에 대해 더 잘 아는 쪽은 사람보다 에이전트입니다. 설계를 다시 설명해보라 하면 말이 막힙니다. 에이전트의 도움이 없이는 코드를 제대로 디버깅하지 못합니다. 원래 나를 더 좋은 엔지니어로 만들어줘야 했던 그 부분을, 통째로 외주를 준 셈입니다.
두 자세 모두, 같은 도구를 사용합니다. 둘 다 실제로 돌아가는 코드를 만들어냅니다. 한 번의 스프린트를 놓고 겉으로 보면, 둘은 거의 동일해 보입니다. 차이는 여섯 달 뒤에 드러납니다. 무언가가 망가졌을 때, 둘 중 한 엔지니어는 1원칙부터 시스템을 다시 세워서 고칠 수 있고, 다른 한 명은 그렇지 못한 시점에서요.
이 글이 정말로 말하고 싶은 것
제가 바라는 건, 이 도구들을 쓰지 말자는 게 아닙니다. 저 역시 매일 씁니다. 지난 12개월 동안 제가 배포한 것들은, 그 이전 어느 12개월보다도 많았고, 이 도구를 외면하는 쪽이, 그것을 적극적으로 쓰는 쪽이 저지르는 실수보다 훨씬 더 큰 실수를 하고 있다고 믿습니다.
하지만 자세(posture) 는 중요하고, 우리는 그 이야기를 아직 충분히 하지 않고 있습니다. 지금의 대화는 대개, “모델이 무엇을 할 수 있는가”에만 머물러 있습니다. 이제는 최소한 그만큼이나, “우리가 모델과 함께 무엇을 하고 있는가, 그리고 그게 함께 생각하는 것 인지, 아니면 아예 생각을 멈추는 것 인지”를 이야기해야 합니다.
인지적 오프로딩은 초능력입니다. 인지적 항복은, 그 초능력을 쓰면서도 그 경계를 자각하지 못할 때 나타나는 실패 모드입니다. 이 일에서 점점 더 중요한 책임은, 매 순간 내가 어느 쪽에 서 있는지에 대한 감각을 잃지 않는 것입니다.
내 코드가 잘 배포되고 있는데, 동시에 시스템에 대한 내 이해가 줄어들고 있다면, 나는 인지 부채로 그 비용을 치르고 있는 것입니다. 반대로, 내 코드가 잘 배포되고 있으면서, 시스템에 대한 내 이해가 커지고 있다면, 나는 예전과 같은 일을, 단지 더 빠르게 하고 있을 뿐입니다.
두 경우 모두 도구는 같습니다. 달라지는 건, 자세입니다. 그리고 그 부분은 여전히 전적으로 우리의 몫입니다.