한 엔지니어의 고백: AI 때문에 코딩하는 법을 거의 잊어버렸다, 업계 기술 공동화 우려가 떠오르다

소프트웨어 엔지니어 James Pain은 개인 블로그에서 AI 보조 프로그램 개발을 1~2년 사용한 후, 거의 "프로그래밍하는 법을 잊어버렸다"고 고백했다. 이는 단순한 개인적 위기가 아니다. 엔지니어 집단 전체가 AI 생성 코드에 의존할 때, 누가 그것을 읽고 수정할 수 있을까? (이전 내용: 캘리포니아 대학교, "AI 브레인 포그" 현상 연구: 14%의 직장인이 Agent와 자동화로 인해 미쳐가고 있으며, 이직 의향이 40% 더 높음) (배경 보충: OpenAI, Apple을 "계약 위반"으로 고소할 것으로 알려져! Siri의 ChatGPT 통합이 기준에 미달하고 수십억 구독이 무산되었다고 분노) 블로그는 다음과 같이 적었다: "나는 1~2년 동안 직접 한 줄의 코드도 작성하지 않았다. 나는 거의 프로그래밍하는 법을 잊어버렸고, 이것이 나를 매우 슬프게 한다." 소프트웨어 엔지니어 James Pain은 AI 도구가 사용하기 어렵다고 불평하는 것이 아니다. 오히려 정반대다. 그는 AI가 너무 사용하기 좋아서, 완전히 "명령을 내리는 것"에 의존해 코드를 생산하고 더 이상 직접 한 줄도 작성하지 않는다고 말했다. 지금 그는 처음부터 자신에게 다시 코딩을 가르치고 있다. Pain의 묘사는 정확하고 불안하다: 그가 글을 쓰거나 프로그래밍하려 할 때마다, 머릿속의 첫 번째 생각은 "AI에게 시키자"이다. 그가 나중에 AI가 생성한 텍스트를 읽었을 때, "전혀 내가 한 말 같지 않다"고 느꼈다; 그가 직접 프로그래밍을 시도했을 때, 손의 감각이 이미 무뎌졌음을 발견했다. 이 현상은 "인지적 오프로딩(cognitive offloading)"이라고 불리는 인지 과학적 기반을 가지고 있다 — 뇌는 외부 도구에 장기간 의존한 후, 해당 기능 영역의 신경 활성화 빈도를 낮추게 된다. 번역하자면: 사용하지 않으면 퇴화한다. 이는 GPS 내비게이션이 공간 기억을 대체하고, 컴퓨터 보조 설계가 손으로 그리는 것을 대체하는 등의 영역에서 이미 연구로 기록되어 있으며, AI 프로그래밍 보조 도구가 가져오는 것은 같은 종류의 효과의 가속화된 버전일 가능성이 있다. 문제의 규모는 개인 차원에 그치지 않는다. GitHub의 2024년 조사에 따르면, 미국 소프트웨어 개발자의 92% 이상이 업무에서 AI 프로그래밍 보조 도구를 사용하고 있으며; Stack Overflow의 같은 해 조사에 따르면, 76%의 개발자가 AI 도구를 사용 중이거나 사용할 계획이다. 만약 "Pain의 현상"이 그중 10%의 사람들에게만 발생한다 하더라도, 이는 수십만 명의 엔지니어가 서로 다른 속도로 능동적 코딩 능력을 잃어가고 있음을 의미한다. 그리고 더 주목할 만한 것은: 이것이 개별적인 게으름이 아니라 합리적인 단기적 결정이라는 점이다. AI를 사용해 코드를 생성하는 것이 더 빠르고 오류가 적으며(초안 단계에서), 산출물은 납품 요구사항을 충족한다. 비즈니스 압박 하에서 엔지니어가 AI를 선택하는 것은 논리적이다. 그러나 장기적으로 누가 이러한 AI 생성 코드를 검토할 것인가? AI가 오류를 낼 때(실제로 오류가 발생한다) 누가 문제를 찾아낼 수 있을까? Pain은 글에서 《Clean Code》의 저자 Robert Martin의 역사적 관찰을 인용했는데, 이는 현재의 곤경에 더 긴 시각을 제공한다. Martin은 컴퓨터 과학이 독립된 학문이 되기 전, 프로그래밍을 하는 사람들은 물리학자, 수학자, 학술 연구자였으며, 그들 자체가 엄격한 전문적 훈련을 받았다고 지적한다. 1970년대부터 1990년대까지, 개인 컴퓨터의 보급과 소프트웨어 수요의 폭발과 함께 업계는 빠르게 확장되었고, 전통적인 "컴퓨터 과학" 배경이 없는 수많은 개발자를 채용하면서 프로그램 개발의 전문성이 희석되기 시작했다: 문서는 점점 적게 쓰이고, 프로그램 아키텍처는 점점 유지관리가 어려워지며, 기술 부채는 점점 쌓여갔다. 오늘날, 응용 계층 코드에 대한 AI 도구의 높은 대체성은 제2차 희석을 형성하고 있다. 이번 물결의 특수성은: 단순히 "인재 품질의 평균화"가 아니라 "기존 인재의 탈숙련화(deskilling)"라는 점이다. 이미 재직 중인 엔지니어들이 장기간 AI 사용으로 인해 기초 능력을 잃어가고 있다. AI 도구의 설계 논리 또한 이 추세를 부추기고 있다. 현재 주류 AI 프로그래밍 어시스턴트(GitHub Copilot, Claude, Cursor 등 포함)의 핵심 가치 제안은 "더 빠르게 납품하도록 돕는 것"이지, "더 깊이 이해하도록 돕는 것"이 아니다. Pain은 글에서 더 깊은 인지적 곤경을 드러내는 한 가지 디테일도 언급했다: 이 글을 완성한 후, 그는 "거의 무의식적으로 이것을 Claude에 붙여 넣어 AI가 어떻게 말하는지 보고 싶어졌다"고 했는데, 자신이 충분히 잘 썼는지 확신할 수 없었기 때문이다. 이것은 단순한 기술 퇴화가 아니라 "인지적 자신감의 이전"이다: 사람들은 AI의 판단을 진실 검증의 기준으로 여기기 시작하고, 자신의 판단이 아니다. 한 엔지니어가 AI가 생성한 코드를 볼 때, 첫 번째 생각이 "읽고 결정하자"가 아니라 "문제없을 것이다"라면, 이것이야말로 더 구조적인 위기다. 이러한 배경에서 업계에서도 역방향 조치의 목소리가 나타나기 시작했다. 일부 시니어 엔지니어 팀은 "AI 단식의 날"을 추진하기 시작했으며, 구성원들에게 매주 일정 시간을 순수하게 손으로 코드를 작성하는 데 할애하도록 요구한다; 일부 기술 면접에서는 AI 보조를 명확히 금지하고 있으며, 이는 까다롭게 굴기 위함이 아니라 응시자가 여전히 기본적인 읽기 및 디버깅 능력을 갖추고 있는지 확인하기 위함이다. Pain 본인도 직업으로서의 프로그램 개발이 사라질 것이라고 생각하지 않는다. 그는 Martin의 관점을 인용하여, 항상 누군가는 진정으로 코드를 읽고 수정해야 할 필요가 있을 것이라고 지적했다. 단지 인원이 더 적어지고, 기준이 더 높아질 뿐이다. 문제는: 만약 산업 전체가 deskilling 되고 있다면, 그 "더 적지만 더 강한" 사람들은 어디서 올 것인가? Pain은 전자로 돌아가는 것을 선택했다: 직접 프로그래밍하는 법을 다시 배우는 것, AI가 나빠서가 아니라, 이 능력을 외주화할 수 없다는 것을 깨달았기 때문이다.