인지 항복

어제 접한 개념 하나를 이야기해보려 한다. 바로 인지 항복(cognitive surrender)이다. UPenn 와튼스쿨에서 나온 최근 논문, Steven Shaw와 Gideon Nave의 "Thinking - Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender"에서 가져온 개념이다. 신학적 맥락에서는 더 오래된 연원을 가진 표현이지만, AI 관점에서의 재정의는 새롭다. 그리고 에이전트를 곁에 두고 코드를 짜는 사람이라면 이 표현이 꽤 날카롭게 와닿을 것이다.

논문에서 가장 기억해둘 만한 건 두 개념의 구분이다:

인지 위임은 계산기, 검색 엔진, 내비게이션과 같다. 방법은 위임하되 무엇을은 스스로 결정한다. 결과가 적절한지 판단하고, 아닐 경우 개입한다.
인지 항복은 답을 스스로 구성하는 것 자체를 멈출 때 일어난다. AI의 결과물이 곧 나의 결과물이 된다. 비교할 독립적인 관점을 애초에 형성하지 않았으니, 수정할 것도 없다.

Shaw와 Nave는 세 가지 실험, 1,372명의 참여자를 대상으로 한 연구에서, AI를 사용할 수 있다는 것만으로도 사람들이 항복하기에 충분하다는 것을 밝혀냈다. AI가 틀린 답을 제시한 상황에서 참여자의 73%가 그 틀린 답을 그대로 수용했다. 더 심각한 건 따로 있다. AI를 사용할 수 있는 조건에서 참여자들의 자신감이 오히려 높아졌는데, 제시된 답의 절반은 의도적으로 틀린 것이었다. 모델의 자신감—항상 꽤 높은—을 빌려다가 자기 것처럼 쓴 셈이다.

이 '빌린 자신감' 효과야말로, 이 이야기가 일반적인 인지 과학의 문제를 넘어 소프트웨어 엔지니어링의 문제로 이어지는 지점이다.

우리 업무에서 항복이 나타나는 순간들

쉬운 작업에서 항복하는 사람은 별로 없다. 에이전트가 없는 API를 만들어내거나 엉뚱한 import를 가져올 때는 금방 알아챈다. 항복은 스택 더 깊은 곳에서 일어난다. 독립적인 관점을 형성하는 데 드는 비용이 해당 작업에 비해 지나치게 크게 느껴지는 순간들에서다.

내가 직접 경험한 몇 가지 상황들을 꼽자면:

diff를 읽을 때. 에이전트가 600줄짜리 PR을 만들었다. 쭉 훑어봤다. 변수명도 괜찮고, 테스트도 통과한다. 승인 버튼을 누른다. 그런데 그 중간 어딘가에 트랜잭션 경계의 미묘한 순서 변경이 있거나, 미처 확인하지 않은 엣지 케이스에서 기본값이 뒤집히는 경우가 있다. 코드를 리뷰한 게 아니라 추인한 것이다. 항복은 결정의 부재로 나타났다.

제대로 이해하지 못한 에러를 디버깅할 때. 스택 트레이스가 무섭게 생겼다. 에이전트에 붙여넣는다. 수정 방법이 돌아온다. 적용하니 된다. 다음으로 넘어간다. 그로부터 2주 뒤, 비슷한 증상이 다시 나타나고 나서야 원래 버그를 실제로는 이해하지 못했음을 깨닫는다. 표면적인 증상만 제거했을 뿐이다. 머릿속의 시스템 멘탈 모델은 이제 어디가 잘못됐는지조차 짚을 수 없는 곳에서 틀어져 있다.

아키텍처 결정을 내릴 때. 두 서비스 사이에 큐를 쓸지 직접 호출할지 확신이 서지 않는다. 에이전트에게 묻는다. 에이전트는 자신 있어 보이는 문단 하나와 함께 하나를 골라 돌려준다. 그대로 따른다. 처리량, 장애 시나리오, 재처리 의미론(replay semantics)에 대해 직접 따져보지 않았다. 문제를 바라보는 프레임도, 그 답도 모두 모델한테서 한꺼번에 받아온 것이다.

새로운 것을 배울 때. Anthropic의 기술 형성 논문이 수치로 보여주는 부분이다. 새로운 라이브러리를 배우면서 AI로 코드를 생성한 엔지니어들은 이후 이해도 평가에서 대조군보다 17% 낮은 점수를 받았다. 반면 AI를 개념 탐색에 활용한 엔지니어들—질문하고, 트레이드오프를 살피는 방식—은 이해도를 유지했다. 같은 도구였지만, 사용하는 자세가 결과를 갈랐다.

이 모든 사례를 꿰뚫는 공통점은 하나다. 모델이 완성된 답을 내놓았고, 우리는 스스로 병렬적인 관점을 구성하는 대신 그것을 그대로 받아들였다. 때로는 그게 맞는 선택이다. 때로는 그게 항복이다. 안에서 느끼기엔 둘이 똑같다.

이해 부채와의 연결

나는 이전에 이해 부채(comprehension debt)에 대해 쓴 적이 있다. 시스템에 존재하는 코드의 양과 그 코드를 실제로 이해하는 인간 사이의 격차가 점점 벌어지는 현상이다. 인지 항복은 바로 이 이해 부채가 쌓이는 메커니즘이다.

매번의 항복은 작은 대출이다. 제대로 이해하지 못한 패치 하나가 코드베이스에 쌓인다. 직접 내리지 않은 결정 하나가 아키텍처에 스며든다. 직접 설계하지 않은 테스트 하나가 테스트 스위트에 추가된다. 각각의 날에는 문제처럼 느껴지지 않는다. 하지만 복리로 불어난다.

MIT의 Your Brain on ChatGPT 논문은 신경과학적 차원에서 동일한 패턴을 보여줬다. AI에 의존한 글쓰기를 한 참여자들에게서 신경 연결성이 측정 가능한 수준으로 감소했고, 방금 작성한 내용에 대한 기억도 약해졌으며, 자신의 추론 과정을 재구성하는 것도 어려워졌다. 저자들은 이를 기술 부채에서 빌려온 개념인 인지 부채(cognitive debt)라 불렀다. 단기적 이득, 장기적 복리 비용.

두 프레임을 합치면 이렇다. 인지 항복은 인지 부채를 지는 방식이다. 이해 부채는 그 청구서이며, 잃어버린 멘탈 모델로 표시된다. 이자는 다음에 무언가 잘못됐을 때 지불된다. 팀의 누구도 시스템을 처음부터 재구성할 수 없을 때.

부채를 만드는 건 AI가 아니다. 그것을 대하는 자세가 만든다. 한 엔지니어의 멘탈 모델을 갉아먹는 바로 그 모델이, 다른 엔지니어의 사고를 더 날카롭게 만들 수도 있다. AI를 사고의 도구로 쓰느냐, 사고 대신 쓰느냐에 따라.

소프트웨어 엔지니어가 특히 취약한 이유

우리 업무의 몇 가지 특성이 일반적인 지식 노동자보다 우리를 더 취약하게 만든다.

겉으로 보이는 신호가 기본적으로 올바르게 보인다. 생성된 코드는 컴파일된다. 린터를 통과한다. 실행된다. 나머지 코드와 비슷하게 생겼다. 대부분의 분야에서 AI 결과물에는 이렇게 강력한 '그럴듯해 보임' 필터가 없다. 우리 분야에는 있다. 그리고 그건 잘못된 필터다. 표면적 정합성은 시스템적 정합성이 아니다. 그리고 그 사이의 간극이 바로 항복이 숨어 있는 곳이다.

가시적인 지표는 처리량이다. 머지된 PR, 출시된 기능, 닫힌 티켓. 이 중 어느 것도 '내가 직접 만들고 이해한 것'과 '에이전트가 만들고 내가 승인한 것'을 구분하지 않는다. 조직은 단기적으로 두 가지를 똑같이 보상한다. 항복은 대시보드에 나타나지 않는다.

자신감은 깔끔하게 전이된다. 모델은 단언하는 방식으로 말한다. 코드 리뷰에서는 단언을 권위로 읽는 경향이 있다. 에이전트가 "화면 끊김을 방지하기 위해 여기서는 300ms 디바운스를 사용합니다"라고 쓰면, 모델이 그 숫자를 즉흥적으로 만들어냈더라도 조직의 축적된 지식처럼 들린다. 근거는 없는데 확신만 물려받는 것이다.

작업은 쌓인다. 한 번의 항복이 다음 항복을 가능하게 한다. 제대로 이해하지 못한 코드 덩어리를 한 번 받아들이고 나면, 그 코드에 대한 다음 변경 역시 거의 필연적으로 또 다른 항복이 된다. 독립적인 관점을 갖추려면 먼저 건너뛴 부분을 재구성해야 하기 때문이다. 항복은 경로 의존적이다.

AI 코딩 도구를 쓰지 말자는 얘기가 아니다. 도구보다 자세가 중요하고, 우리에겐 아직 필요한 습관들이 충분히 갖춰져 있지 않다.

조율의 문제

Shaw 본인은 이 문제에 대해 과도한 경계를 조장하지 않으려 조심한다. 그의 프레임은 이 도구들을 진지하게 사용하는 누구에게든 전해줄 만하다:

인지 항복이 AI가 나쁘다거나 AI를 사용하는 것이 비합리적이라는 의미는 아니다. 많은 상황에서 AI는 판단력을 향상시킬 수 있다. 핵심 문제는 조율이다. AI가 내 사고를 돕고 있는 순간과 AI가 조용히 나 대신 생각하고 있는 순간을 구분하는 것.

스스로에게 계속 물어야 할 질문이 있다. 나는 이 답에 대해 독립적인 관점을 형성하고 있는가, 아니면 에이전트의 관점을 통째로 받아들이고 있는가? 두 가지는 심리적으로 전혀 다른 행위이지만, 외부에서 보면 똑같아 보인다.

내가 인지 위임 쪽에 머무르기 위해 쓰기 시작한 몇 가지 방법들을 공유한다:

결과물을 보기 전에 먼저 예상을 세운다. 에이전트를 비중 있는 작업에 투입하기 전에, 답이 어떤 모습이어야 할지 먼저 적어본다. 머릿속으로라도. 세 줄이든 쉰 줄이든. 큐를 쓸지 직접 호출할지. 버그가 이 모듈에 있을지 저 모듈에 있을지. 에이전트의 답이 내 예상과 일치하면 조율이 잘 된 것이다. 다르다면, 진짜 선택을 해야 한다. 내가 틀린 건지, 에이전트가 틀린 건지. 항복이 건너뛰는 것이 바로 이 선택이다.

AI가 쓰지 않은 것처럼 diff를 읽는다. 팀의 주니어 엔지니어가 제출한 PR이라고 생각해보자. '테스트 통과'라는 이유만으로 머지하겠는가? 그러지 않을 것이다. 저자가 모델일 때도 같은 기준을 적용해야 한다. 해야 할 일이 바뀐 게 아니라 저자가 바뀐 것이다. "괜찮아 보인다"는 여전히 리뷰가 아니다.

모델에게 스스로 반박하게 한다. 대부분의 모델은 자신 있는 답을 내놓고, 프롬프트를 주면 그 못지않게 자신 있는 반론도 내놓는다. 두 번째 패스는 비용이 거의 없고, 빌린 자신감 효과를 깨트린다. 두 답 중 어느 것이 옳은지 따질 수 없다면, 막 항복하려던 지점을 찾은 것이다.

피로한 순간을 인식한다. 항복은 피로 현상이다. 하루의 첫 번째 PR은 제대로 리뷰하고, 다섯 번째는 대충 훑는다. 내가 신뢰하는 시니어 엔지니어들은 모두 어떤 형태로든 같은 결론에 도달했다. "평가할 수 없을 만큼 피곤할 때는 에이전트가 생성하게 두지 않는다." 이 자기 인식 자체가 이제 업무의 일부다.

자신감이 어디서 오는지 살핀다. 회의에서 어떤 설계 결정을 방어하다가 왜 그 결정을 내렸는지 실제로 재구성할 수 없는 상황, 에이전트가 제안했고 그럴듯해 보였다는 것밖에 모르는 상황이라면, 근거 없이 모델의 확신만 물려받은 것이다. 항복의 흔적이다. 대화를 이어가기 전에 코드로 돌아가서 이유를 다시 세워라.

항복에 저항하는 엔지니어링 방식

개인적인 방법도 중요하지만, 구조적인 차원의 접근도 있다. 내가 지난 몇 달간 써온 글들(Agent Skills, 에이전트 하네스 엔지니어링, 이해 부채 글)은 대부분 항복을 더 어렵게 만드는 발판을 구축하는 것에 관한 이야기였다.

실제로 효과가 있는 방식들을 정리하면:

검증을 필수 종료 조건으로. 에이전트가 완료한 모든 작업은 구체적인 증거로 마무리되어야 한다. 실행되는 테스트, 스크린샷, 로그, 런타임 트레이스, 리뷰어 승인. "완료된 것 같다"는 항복에 친화적인 종료 방식이다. "동작한다는 증거가 여기 있다"는 항복에 저항하는 종료 방식이다. 증거 요건을 워크플로에 내재화하면 항복으로 가는 가장 쉬운 경로를 차단할 수 있다.

합리화 방지 테이블. Agent Skills에서 가장 독특한 설계 결정은 워크플로 단계를 건너뛰는 흔한 핑계들 옆에 서면 반박문을 나란히 배치한 것이다. 이것이 항복 저항 메커니즘이기도 하다. "이 작업은 너무 간단해서 스펙이 필요 없다." → "인수 기준은 여전히 적용된다." 모델이, 혹은 금요일 오후의 지친 자신이 아직 내놓지도 않은 합리화에 대한 반박을 미리 써두는 것이다. 모델은 까다로운 단계를 건너뛸 그럴듯한 이유를 만들어내는 데 탁월하다. 합리화 방지 테이블은 그날그날 그들과 논쟁을 벌이는 대신 미리 선을 그어둔다.

범위를 줄이고, PR을 작게. 항복은 크기에 비례한다. 50줄짜리 변경은 직접 읽을 수 있지만, 600줄은 그럴 수 없다. 구글의 ~100줄 PR 원칙은 인간적인 이유에서 나왔지만, AI 항복에 저항하는 데도 같은 이유로 효과적이다. 리뷰의 단위가 곧 이해의 단위다. 단위를 실제로 이해할 수 있을 만큼 작게 만들어라.

배울 때는 생성보다 개념 탐색을. 기술 형성 논문의 발견을 습관으로 바꾼 것이다. 새로운 라이브러리나 시스템을 접할 때는, 생성을 요청하기 전에 먼저 설명을 요청하라. 생성이 아닌 탐문의 방식으로 사용하면, 같은 도구가 멘탈 모델을 무너뜨리는 대신 쌓아준다. 데이터는 명확하고, 모드를 전환하는 비용은 거의 없다.

의도적인 마찰. arXiv의 "Cognitive Agency Surrender" 논문은 발판화된 인지 마찰(Scaffolded Cognitive Friction)을 제안한다. 습관적 수용을 끊기 위해 의도적으로 저항의 순간을 만드는 것이다. 엔지니어링 관점에서 번역하면, 생성 전 필수 설계 문서, 머지 전 확인 단계, 배포 전 체크리스트다. 마찰은 생산성 담론에서 나쁜 평판을 갖고 있다. 하지만 인지 위임과 인지 항복 사이를 가로막는 것이 바로 이 마찰이다.

혼자 키보드 앞에 앉는 시간. 에이전트 없이 코드를 작성하는 시간을 매주 가져라. 원칙의 문제가 아니라 조율의 문제다. AI 없이는 간단한 것도 편하게 만들 수 없다는 걸 깨닫는 날, 인지 위임이 인지 항복으로 바뀐 것을 알아차리지 못한 것이다.

위임이 아닌 상호 증폭

마지막으로 남기고 싶은 프레임은 암울한 것이 아니다. 이 연구를 다룬 Time 기사에서 인용된 Andy Clark은 핵심적인 구분을 제시한다. AI 시스템에 위임하는 것과 AI 시스템과 협력하는 것은 다르다. 위임은 항복을 낳는다. 협력은 그가 상호 증폭(mutual amplification)이라 부르는 것을 만들어낸다. 내 프롬프트가 모델의 결과를 날카롭게 하고, 그 결과가 다음 프롬프트를 날카롭게 하고, 그것이 문제에 대한 내 이해를 날카롭게 하는 선순환.

차이는 느낌으로 알 수 있다. 상호 증폭의 상태에서는 대화를 통해 도메인을 배우고 있는 자신을 발견한다. 장애물에도 불구하고가 아니라, 대화를 통해서. 세션이 끝날 때 멘탈 모델이 처음보다 흐려진 게 아니라 선명해져 있다. 직접 만들 수도 있는데, 그보다 빠른 경로를 택한 것이다. 에이전트는 방 안의 두 번째 엔지니어지, 유일한 엔지니어가 아니다.

항복의 자세는 그 반대다. 문제에 대한 이해는 에이전트가 더 선명하고 나는 그렇지 못하다. 설계를 재구성할 수 없다. 에이전트 없이는 코드를 디버깅할 수도 없다. 나를 성장시켜야 했을 작업의 그 부분을 외주로 내보낸 것이다.

두 자세 모두 같은 도구를 쓴다. 둘 다 코드를 출시한다. 한 번의 스프린트만 보면 외부에서는 구분이 되지 않는다. 차이는 6개월 후, 무언가 망가졌을 때 드러난다. 두 엔지니어 중 한 명은 처음 원리부터 다시 따져서 고칠 수 있고, 다른 한 명은 그럴 수 없다.

이 글로 가장 바라는 것

이 도구들을 쓰지 말라는 게 아니다. 나는 매일 사용한다. 지난 12개월 동안 그 이전 어느 12개월보다 더 많이 만들었고, 이 흐름에서 비켜선 사람들이 적극적으로 쓰는 사람들보다 훨씬 더 큰 실수를 하고 있다고 생각한다.

하지만 자세가 중요하고, 우리는 그것에 대해 충분히 이야기하지 않는다. 지금 대화의 대부분은 모델이 무엇을 할 수 있느냐에 쏠려 있다. 우리가 그것으로 무엇을 하고 있는지, 그리고 그 답이 함께 생각하는 것인지 아예 생각하지 않는 것인지에 대한 논의가 적어도 그만큼은 있어야 한다.

인지 위임은 강력한 능력이다. 인지 항복은 그 능력을 쓰면서 둘 사이의 경계를 인식하지 못할 때 일어나는 실패 방식이다. 이 일은 점점 더, 지금 이 순간 자신이 그 경계의 어느 쪽에 서 있는지를 스스로 조율하는 것이 된다.

코드는 출시되는데 시스템에 대한 이해가 줄어들고 있다면, 인지 부채를 치르고 있는 것이다. 코드는 출시되는데 시스템에 대한 이해가 늘어나고 있다면, 진짜 일을 하고 있는 것이다. 다만 이전보다 빠르게.

두 경우 모두 도구는 같다. 다른 것은 자세다. 그리고 자세는 여전히 온전히 당신의 몫이다.