천천히, 조용히 무너지는 개발자의 사고력 (Cognitive Atrophy)
AI에 의존할수록 개발자의 사고 능력이 서서히 퇴화한다는 문제를 짚은 글. 프롬프트-수락-반복으로 굳어진 작업 방식이 어떻게 코드 리뷰와 팀 전체로 번지는지, 그리고 저자가 직접 실천하는 대응법을 소개한다.
The Slow and Quiet Cognitive Atrophy of a Modern Software Engineer
Over the past couple of months, I've read a lot of articles about the consequences of AI dependency...
개요 #
개발자 Elmar Chavez가 AI 의존이 불러오는 인지 위축(cognitive atrophy) 문제를 정면으로 다뤘다. 핵심은 하나다. 문제를 직접 풀지 않는다는 것. 해결책을 스스로 떠올리기 전에 AI에게 먼저 묻는 습관이 굳으면, 생각하는 과정 자체가 통째로 빠진다.
그가 글의 배너로 고른 그림은 피터르 브뤼헐의 〈장님을 이끄는 장님〉(1568)이다. 앞을 못 보는 사람이 앞을 못 보는 사람들을 이끌다 결국 다 같이 넘어지는 장면. 1568년 그림이 2026년의 개발 현장을 그대로 비춘다는 게 그의 진단이다. 차이는 딱 하나, 지금의 우리는 스스로 눈을 감기로 선택했다는 점이다.
프롬프트 → 수락 → 반복 #
이 흐름에 리뷰 단계가 없다는 걸 눈치챘는가. 그게 문제의 전부다.
"작은 변경인데 뭐 어때"라고 넘어가도 괜찮아 보인다. 하지만 그 과정을 수백 번 반복하면 "작은 변경"이 쌓인다. 길게 놓고 보면 어느 순간 AI 없이는 코드를 못 쓰는 자신을 발견하게 된다.
우리는 생성된 코드를 의도적으로 보지 않고 있다.
AI가 뽑아낸 코드는 깔끔하면서 동시에 사람을 속인다. UI는 그럴듯하고, 테스트도 통과한다. 물론 그 테스트마저 AI가 짰다. 코드베이스가 온통 무지개와 햇살로 만들어진 것처럼 보이니 그냥 수락하고 넘어가는 게 당연해진다.
기술이 녹스는 건 개발 업계만의 일이 아니다. 어떤 기술이든 쓰지 않으면 무뎌진다. 지시하는 쪽이 직접 하는 쪽보다 늘 쉽다. 그리고 지시하는 것과 실제로 구현하는 것은 대체로 같은 일이 아니다.
직접 해보면 뇌가 강제로 돌아간다. 놓치기 쉬운 엣지 케이스가 눈에 들어오고, UX를 한 번 더 고민하게 되고, 어떤 테스트가 의미 있는지 판단이 선다. 어느 코드가 더 중요한지도 감이 온다. 반복 작업에 AI를 보조로 쓰는 것과, 사고 전체를 AI에 외주 주는 것은 완전히 다른 이야기다.
Photo by Song Kaiyue on Pexels
물론 사람이 쓴 코드도 완벽하지 않다. 대부분은 천재 프로그래머가 아니고, 코드에는 사람이 낸 실수가 섞인다. 저자는 바로 그 지점이 가치라고 본다.
거기엔 사람이 붙어 있다.
누군가 이미 그 결정의 주인이고, 책임을 지고, 맥락을 쥐고 있다. 문제가 터져도 바닥부터 시작하지 않는다. 자기가 만든 코드니 자기가 고칠 수 있다. 헤매고, 틀린 가정을 세우고, 결국 답을 찾아내는 과정이 진짜 이해를 만든다. 다음에 같은 문제를 만나면 그때는 혼자 풀 가능성이 높아진다. 효율은 그렇게 올라간다.
AI는 배우는 데 쓰고, 내 빈틈을 드러내는 용도로 쓰자는 게 저자의 제안이다. 질문하고, 따지고, 검증하라. 사고 과정을 넘겨주지 않으면서 AI를 쓰는 훨씬 건강한 방법이다. 모든 작업을 통째로 맡길 거라면, 스스로를 AI의 탭 누르는 로봇이라고 선언하는 편이 솔직하다.
맹목적 신뢰가 만드는 도미노 #
리뷰를 거치지 않은 AI 코드가 PR로 올라가는 순간 도미노가 쓰러지기 시작한다. 주니어는 AI를 믿고, 시니어는 주니어를 믿고, 그 코드는 그대로 프로덕션까지 간다. 인지 위축만 문제가 아니다. 가짜 신뢰가 함께 만들어진다.
우리는 어쩌다 이 지경까지 왔을까.
속도는 한 번도 좋은 코드의 척도였던 적이 없다. 코드베이스는 원래 부서지기 쉽다. 잘못된 구현 하나가 온갖 에러를 연쇄시킨다.
AI는 설득력 있는 코드를 아주 잘 깔아놓는다. 작성자는 그걸 보고 "동작한다"는 착각에 갇힌다. 정작 이해한 건 없다. 그 코드가 푸시되는 순간 맥락은 이미 사라진 상태다. 직접 들여다봐서 성공 확률을 올리는 대신, 처음부터 그냥 되기를 걸고 있는 셈이다.
시니어 입장에서도 "이게 좋은 변경인가"보다 "이 친구가 자기가 보낸 코드를 이해하고는 있나"가 먼저 떠오른다. 아니, 읽기는 했을까.
1000줄 넘는 슬롭을 누가 읽고 싶어 하겠나.
AI 코드를 읽는 피로는 전염된다. 리뷰어도 똑같이 게을러져서 그냥 승인해 버린다. 사람 심리가 원래 그렇다. 한 번에 변경이 너무 많이 들어오면 품질 검사가 고르게 될 리 없다. 전체를 건너뛰거나, 중요한 부분만 훑거나, 더 나쁘게는 AI 리뷰 에이전트에 다시 기대게 된다. 불확실성만 한 겹 더 쌓인다.
AI는 보조로 쓸 때 좋고, 대체로 쓸 때 나쁘다. 올바르고 책임감 있게 다뤄야 하는 도구다. 모두에게 이 방식을 강요할 수는 없지만, 나부터 시작할 수는 있다. 보내기 전에 읽고, PR을 이해하고, 의도를 가지고 푸시하라.
PR을 "리뷰 받을 준비가 된" 상태로 만드는 게 핵심이다. 완벽할 필요는 없다. 중요한 건 그게 내 것이고, 리뷰어가 물었을 때 바로 방어할 수 있다는 점이다. 코드의 안팎을 설명하고, 결국 "왜?"에 답할 수 있어야 한다.
그다음이 다른 사람의 눈이다. 다듬고, 크고 작은 수정을 더하고, 리팩터링을 요청한다. 변경을 두고 나누는 대화가 팀 전체에 맥락을 자연스럽게 퍼뜨린다. 잘 굴러가면 주변도 따라오고, 안 따라오더라도 최소한 자신은 인지 위축에서 벗어난다.
뇌는 계속 두들겨 맞아야 한다 #
인지 위축과 싸우려면 머리를 쓰게 만들 방법을 찾아야 한다. 지금의 작업 방식으로는 부족하다는 게 데이터가 말하는 바다.
저자가 개인적으로 하는 건 이렇다. 매일 최소 한 문제씩 코딩 챌린지를 푼다. 푸는 과정을 녹화한다. 누군가에게 가르치듯 사고 과정을 단계별로 소리 내어 설명한다. 카메라를 보고 화면을 띄운 채 혼자 떠드는 영상이 지금 폴더에 쌓여 있다.
이 방식은 빈틈을 드러낸다. 저자는 그게 마음에 든다고 했다. 녹화를 다시 보면 어디서 막혔는지, 설명 중 어디서 말이 끊겼는지가 그대로 보인다. 실수와 침묵은 현재 실력을 냉정하게 알려준다. 무엇보다 개선할 거리가 손에 잡히고, 그 사이 뇌는 계속 새 연결을 만든다.
확실히 나아지는 게 보였다.
첫 녹화와 지금의 설명을 비교하면 확실히 날카로워졌고, 다루는 언어와 개념에 대한 이해도 깊어졌다고 그는 말한다. 게임에서 캐릭터 스탯이 오르는 걸 볼 때 더 파고들게 되는 것과 같은 원리다.
코딩 챌린지 말고도 저자는 자기 작업을 한 번 더 의심한다. 베스트 프랙티스와 방법론을 다시 확인하는 식이다. 순서가 중요하다. 먼저 인터넷에서 문서와 예제, 여러 접근법을 찾아본다. 자기 생각을 먼저 세운 뒤에야 AI를 붙여 이해를 더 깊게 만든다.
AI가 이미 폐기된(deprecated) 메서드를 추천하는 걸 잡아낸 적도 있다.
미리 공부해두지 않았다면 그냥 넘어갔을 일이다. 지적했을 때 AI의 답변은 이랬다.
"You're absolutely right!"
그 순간 AI가 얼마나 못 미더운 물건인지 실감했다고 한다. 맞을 때도 있고 틀릴 때도 있다. 애초에 아는 게 없으면 놓칠 확률이 훨씬 높다. 그리고 그들 스스로도 프롬프트 입력창 아래에 이미 적어두고 있다. 실수할 수 있다고.
사람마다 맞는 방법은 다르다. 중요한 건 머리를 계속 적당히 괴롭혀서 날을 살려두는 것이다. 인지 위축은 사고를 외주 주기로 결심한 바로 그 순간부터 스며든다. 그리고 AI 없이 예전처럼 코딩하지 못하는 자신을 발견했을 때에야 알아차리게 된다.
규율은 자기 존중의 최고 형태 #
저자는 자신도 AI 생성 코드를 써본 적이 있다고 인정한다. 그리고 별로였다고 했다. 로컬호스트를 열자 버그가 우수수 쏟아졌다. 그런데 정작 그를 좌절시킨 건 버그 자체가 아니었다.
어디를 봐야 할지조차 모르겠다는 것. 그게 문제였다.
무력감과 소유권 없음이 압도적이었다고 그는 썼다. 내가 만든 코드가 아니니 그럴 수밖에. 그래서 다시 프롬프트를 넣었다. AI는 문제 해결을 위해 먼저 확인해야 할 점검 항목 서너 개를 던져줬다. 지쳤다. 그 방식은 자신에게 맞지 않았다. 버그가 안 잡히자 AI는 또 다른 점검 목록과 수정안을 내놨다. 해결책을 계속 새로 생성하는 무한 루프였다.
경험이 부족해서라거나, 프롬프트가 잘못됐다거나, 아키텍처와 맥락을 적어둔 마크다운 파일이 없어서라고 반박할 수 있다. 저자도 그건 타당하다고 인정한다. 다만 이렇게 되묻는다.
"동작하는" 코드를 AI에게 받겠다고 거기까지 할 거면, 그냥 직접 짜는 게 낫지 않나.
그래서 직접 했다. 디버깅하고, 다시 하고, 공부하고, 고치고, 부수고, 또 고쳐서 필요한 컴포넌트를 만드는 데 15~30분이 걸렸다. 헤매긴 했지만 어딘가로 가고 있다는 감각이 있는 종류의 헤맴이었다. 사다리를 실제로 오르는 것처럼, 힘든 만큼 손에 잡혔다.
그리고 전보다 더 알게 됐다. 코드도 내 것, 실수도 내 것, 해결책도 내 것. 그렇게 얻은 이해는 사라지지 않는다.
이 방식에서 유일한 적은 나의 규율뿐이다.
저자는 "규율은 자기 존중의 최고 형태"라는 문장을 어딘가에서 읽고 계속 마음에 담아뒀다고 한다. 코드 생성이 날마다 쉬워지는 세상에서, 지름길을 마다하고 배우는 규율은 초능력에 가깝다. 어떤 일을 하든 기본기는 늘 깔려 있다. 규율을 들여 기본기에 투자하면 자기 존중이 따라오고, 주변 엔지니어의 존중도 따라온다.
눈을 떠라 #
해법은 단순하다. 인지 위축과 싸우려면 스스로 더 많이 생각하면 된다. 머리를 쓸수록 애써 쌓아온 기술이 남는다.
AI를 완전히 버리자는 말은 아니다. 있는 자원을 낭비할 이유는 없다. 책임감 있게 쓰자는 얘기다. 사고를 대체하는 게 아니라, 사고를 한 단계 끌어올리는 도구이자 보조로.
AI는 강력하지만 소프트웨어를 만드는 모든 결정을 넘겨받을 만큼은 아니다. 그건 인지 위축으로 가는 직행 티켓이다. AI는 그것을 다루는 엔지니어의 좋은 습관과 나쁜 습관을 똑같이 증폭시킨다. 다른 모든 도구처럼, 잘못 쓰면 결과물이 어긋난다.
품질을 여전히 소중히 여기는 새로운 세대에 끼자는 이야기다. 완벽하게, 그리고 빠르게 내놓을 필요는 없다. 내가 소유하고, 방어할 수 있고, 잘못됐을 때 고칠 수 있고, 그러면서 계속 나아지고 있으면 된다.
편리함이 사고를 외주 주는 이유가 되게 두지 말자.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.