AI가 나를 멍청하게 만든다는 개발자의 고백

James Pain은 짧은 블로그 글에서 불편한 감정을 솔직히 썼다. 글, 코드, 문서를 AI에게 맡기고 나면 결과물은 빠르게 나오지만 자기 목소리가 사라지고, 1~2년 동안 거의 프롬프트만 쓰다 보니 직접 코딩하는 법을 잊어버린 것 같다는 고백이다. 그는 글을 다 쓰고도 Claude에 붙여 넣어 ‘이상하지 않은지’ 확인하려는 충동을 느꼈다고 말한다.

생산성 도구가 자기 의심을 먹을 때

AI 보조는 초안을 빨리 만든다. 문제는 초안 작성 능력만 외주화되는 것이 아니라, 내가 무엇을 말하고 싶은지 결정하는 과정까지 외주화될 수 있다는 점이다. Pain이 말한 핵심은 기능 부족이 아니라 자기 의심이다. ‘내가 쓴 것이 충분한가’라는 불안을 AI 검수로 달래다 보면, 판단 근육이 점점 약해진다.

이 현상은 AI가 작업 마비를 풀어줄 때의 양면성과 같다. AI는 시작 장벽을 낮추지만, 매번 시작을 AI에게 맡기면 사용자는 시작하는 능력을 잃을 수 있다. LLM 위임 작업의 문서 손상이 보여준 것처럼, 위임은 품질 관리 체계가 있을 때만 생산성이 된다.

개발 역량은 사라지지 않지만 재편된다

Pain은 소프트웨어 개발자가 완전히 사라지지는 않을 것이라고 본다. 여전히 코드를 읽고 쓸 줄 아는 사람이 필요하기 때문이다. 이 판단은 현실적이다. GitHub의 Copilot 연구는 AI가 과제 완료 속도와 만족도를 높일 수 있음을 보여줬지만, 그것이 설계 판단·디버깅·보안 검토를 자동으로 대체한다는 뜻은 아니다. Stanford AI Index도 AI 도입이 빠르게 확산되는 만큼 교육과 평가 방식이 함께 변해야 한다고 강조한다.

한국 개발팀의 교육 문제

한국 조직은 AI 코딩 도구 도입을 비용 절감이나 산출량 증가로만 보면 위험하다. 주니어가 처음부터 전체 구현을 AI에게 맡기면, 코드베이스의 역사와 설계 트레이드오프를 배우는 시간이 줄어든다. 반대로 시니어가 AI를 잘 쓰면 반복 구현을 줄이고 리뷰와 설계에 더 많은 시간을 쓸 수 있다. AI 시대 시니어 개발자의 언어가 중요해지는 이유다. 시니어의 역할은 답을 빨리 내는 사람이 아니라, AI가 낸 답을 검증 가능한 학습 경로로 바꾸는 사람이다.

교육 방법도 바뀌어야 한다. ‘AI 사용 금지’는 현실성이 낮고, ‘AI 마음껏 사용’은 기초 체력을 해칠 수 있다. 더 나은 방식은 단계별 공개다. 먼저 문제를 손으로 분석하고, 다음에 AI에게 대안을 요청하고, 마지막에 결과를 테스트와 코드 리뷰로 검증한다. OpenAI의 교육 관련 안내나 Anthropic의 Claude for Education 흐름도 결국 도구와 학습 설계가 함께 가야 한다는 점을 보여준다.

개인을 위한 회복 루틴

개발자가 당장 할 수 있는 방법은 작다. 하루 한 커밋은 AI 없이 작성한다. AI에게 묻기 전에 실패 가설을 3개 적는다. 생성된 코드를 읽고 변수명과 제어 흐름을 자기 스타일로 고친다. 글을 쓸 때는 AI 교정 전에 첫 문단과 결론을 직접 쓴다. AI가 만든 설명을 그대로 믿지 말고 테스트, 문서, 로그로 되묻는다. 이 루틴은 속도를 포기하자는 말이 아니라, 속도와 숙련을 분리하지 말자는 말이다.

FAQ

AI를 쓰면 정말 실력이 떨어지나?

사용 방식에 따라 다르다. 반복 작업을 줄이면 실력이 오를 수 있지만, 사고와 판단까지 계속 위임하면 특정 근육은 약해질 수 있다.

주니어에게 AI를 금지해야 하나?

전면 금지는 비현실적이다. 대신 AI 사용 전 자기 해법 작성, 사용 후 설명·테스트 제출 같은 규칙이 필요하다.

시니어는 무엇을 해야 하나?

AI 결과를 더 빨리 받는 사람이 아니라, 팀이 왜 그 결과를 받아들이거나 거부하는지 설명하는 기준을 만들어야 한다.

글쓰기에서도 같은 문제가 생기나?

그렇다. 문장 교정보다 위험한 것은 자기 목소리와 판단을 AI 문체에 맞추는 습관이다. 초안의 핵심 주장은 직접 써야 한다.

좋은 AI 사용 습관은?

AI를 정답 공급자가 아니라 페어 프로그래머, 반대 질문자, 테스트 생성자로 두는 것이다. 최종 판단과 책임은 사용자에게 남겨야 한다.