Tab 키를 누르는 손이 너무 가벼워졌다면
요즘 코딩 에이전트 쓰시는 분들, 솔직하게 한번 돌아볼까요? AI가 제안한 코드를 끝까지 읽지 않고 ‘Accept’를 누른 적, 테스트가 통과하니까 왜 통과했는지도 모른 채 커밋한 적이 한 번쯤은 있으시죠. 이런 일이 쌓이다 보면 어느 순간 “이거 내가 짠 코드인데 내가 설명을 못 하겠네” 하는 순간이 와요.
‘Resisting Cognitive Surrender(인지적 항복에 저항하기)’라는 에세이는 바로 이 감각을 정면으로 다뤄요. 제목에 나온 인지적 항복(cognitive surrender)은 AI와 사람의 사고방식을 연구하는 쪽에서 최근 쓰이기 시작한 표현이에요. 개발자라면 한 번쯤 곱씹어볼 만한 개념이라서, 오늘은 이걸 차근차근 풀어볼게요.
오프로딩과 항복은 달라요
먼저 비슷해 보이는 두 개념을 구분해야 해요. 인지적 오프로딩(cognitive offloading)은 원래 아주 자연스러운 일이에요. 전화번호를 외우는 대신 연락처 앱에 저장하고, 암산 대신 계산기를 두드리는 것처럼 머리가 할 일을 도구에 맡기는 거죠. 여기서 핵심은 결과를 판단하는 능력은 여전히 내가 갖고 있다는 거예요. 계산기가 2+2=5라고 하면 우리는 바로 “어? 이상한데” 하고 알아채잖아요.
반면 인지적 항복은 판단 자체를 넘겨버린 상태예요. AI의 답이 맞는지 따져보는 단계를 건너뛰고 “AI가 그렇다니까 그런가 보다” 하고 받아들이는 거죠. 문제는 AI가 틀렸을 때도 똑같이 받아들인다는 거예요. 심리학자 대니얼 카너먼은 사람의 사고를 빠르고 직관적인 ‘시스템 1’과 느리고 분석적인 ‘시스템 2’로 나눴는데요. 최근 일부 연구자들은 AI를 우리 바깥에 있는 ‘시스템 3’로 보고, 시스템 2를 써야 할 순간에 그 일을 시스템 3에 통째로 넘겨버리는 현상을 지적하고 있어요.
개발자에게 이게 왜 특히 위험할까
이 문제는 다른 직군보다 개발자에게 더 아파요. 코드는 그럴듯해 보이는 것과 실제로 맞는 것 사이의 간극이 유난히 큰 결과물이거든요. 컴파일도 되고 테스트도 통과하는데 경계 조건에서 터지거나, 동시성 문제를 숨기고 있거나, 보안 구멍을 품고 있는 코드는 얼마든지 있어요.
2025년에 METR이라는 연구 기관이 숙련된 오픈소스 개발자들을 대상으로 실험을 했는데요. AI 도구를 쓴 쪽이 작업 시간이 오히려 더 걸렸는데도, 정작 본인들은 더 빨라졌다고 느꼈다는 결과가 나왔어요. 체감과 실제 사이에 이 정도로 큰 차이가 생길 수 있다는 거죠. 항공 업계에서 오래전부터 이야기해온 자동화 편향(automation bias)과도 닮았어요. 자동조종 장치를 너무 믿다가, 정작 이상 상황이 오면 조종사가 제대로 대응하지 못하는 문제 말이에요.
주니어 개발자에게는 더 직접적인 문제예요. 디버깅 실력은 결국 삽질하면서 쌓이는데, 막힐 때마다 AI가 바로 답을 주면 그 근육이 자랄 기회가 없거든요. 시니어도 안전하지 않아요. 코드베이스 전체에 대한 멘탈 모델, 그러니까 머릿속에 그려둔 시스템 지도가 흐려지면 장애가 났을 때 어디부터 봐야 할지 감이 안 와요.
그럼 어떻게 저항할 수 있을까
AI를 쓰지 말자는 이야기가 절대 아니에요. 핵심은 판단의 주도권을 내가 쥐고 있느냐예요. 실무에서 바로 써먹을 수 있는 습관 몇 가지를 정리해볼게요.
- 내 가설부터 세우고 물어보기: 버그가 나면 AI에 붙여넣기 전에 “내 생각엔 여기가 원인 같다”를 한 줄 먼저 적어보세요. 그다음 AI의 답과 비교하면 내 사고가 계속 돌아가요.
- 설명 못 하면 머지하지 않기: 이 코드가 왜 이렇게 동작하는지 동료에게 말로 설명할 수 없다면, 아직 내 코드가 아니에요.
- AI에게 반론을 요청하기: “이 코드의 문제점을 찾아줘”, “이 접근이 틀렸다면 왜일까?”처럼 반대 방향으로 질문하면 맹신을 깨는 데 도움이 돼요.
- AI 없이 일하는 시간을 일부러 만들기: 운동선수가 기초 체력 훈련을 하듯이, 일주일에 몇 시간은 손으로 직접 짜보는 거예요.
한국 개발 현장에서 생각해볼 점
요즘 국내 회사들도 AI 코딩 도구 도입률이나 생산성 향상을 KPI처럼 재기 시작했죠. 속도 압박이 커질수록 인지적 항복은 개인의 게으름이 아니라 조직 구조가 만든 결과가 되기 쉬워요. 그래서 팀 차원의 장치가 필요해요. 예를 들면 코드 리뷰에서 “AI가 짠 부분은 어디고, 내가 직접 검증한 범위는 어디까지인지”를 적게 하는 거죠.
채용 시장도 달라지고 있어요. AI가 기본 코드를 다 짜주는 시대일수록, 결국 차이를 만드는 건 그 코드가 맞는지 판단하는 능력이니까요.
마무리
한 줄 정리: AI에게 일을 맡기는 건 괜찮아요. 하지만 판단까지 맡기는 순간, 우리는 개발자가 아니라 승인 버튼을 누르는 사람이 돼요.
여러분은 AI가 짠 코드를 어디까지 검증하고 머지하시나요? 스스로 ‘항복’하고 있다고 느낀 순간이 있었다면 같이 이야기해봐요.
🔗 출처: Hacker News