AI시대 개발자가 인간 클립보드 되지 않는 법
안녕하세요, 해외 IT 이야기를 전하는 트파원입니다.
개발자 여러분 업무에 AI 쓰시나요? 편리하기는 하지만 요즘IT에 발행됐던 <다시는 챗GPT를 사용하지 않겠다>에서처럼 무의식의 학습 기회를 빼앗는 것 같은 기분이 들기도 합니다. 쉽게 말하면 조금 멍청해지는 기분이 드는 것 같달까요. 생산성 향상에 도움을 줬다고 볼 수도 있지만 비판적으로 사용할 필요도 있다고 생각하는데요.
이와 비슷한 관점의 글을 발견해 소개하려고 합니다. 구글 크롬 웹 브라우저 팀의 시니어 엔지니어링 리더 애디 오스마니(Addy Osmani)의 글 "AI 시대에 기술 퇴보를 피하는 법(Avoiding Skill Atrophy in the Age of AI)"입니다. 이 글에서 애디는 AI의 발전으로 우리가 직면하게 된 '기술 퇴보(skill atrophy)' 현상을 심도 있게 다루면서, 우리가 힘들게 쌓아온 엔지니어링 기술이 무용지물이 되지 않도록 AI를 현명하게 활용하는 방법에 대해 이야기합니다.
20년 이상 개발자로 활동했고, 또 구글에서 12년 넘게 일하면서 구글 크롬의 개발자 경험(Developer Experience) 조직을 이끄는 리더인 만큼 팀의 AI 사용에 대해서도 고민이 많았을 텐데요. 개발자들의 실제 경험담과 AI를 비판적으로 활용하는 구체적인 전략도 글에 담고 있습니다.
인간 클립보드가 된 개발자 이야기
애디는 이 글에서 AI 코딩 보조 도구의 등장으로 인해 생기는 ’인지적 부담 분산(cognitive offloading)'현상을 지적합니다. 인지적 부담 분산은 정신적인 작업을 외부 도구에 의존하는 것을 뜻하는데, 이는 마치 GPS 내비게이션에 너무 의존하여 길 찾기 능력이 퇴화하는 것과 비슷하다고 합니다. 그는 AI 기반 자동 완성이나 코드 생성기를 사용하면서 우리가 루틴한 코딩 작업에 대해 "뇌를 끄는" 유혹에 빠지기 쉽다고 지적합니다. ‘뇌를 끈다’는 표현에 저도 정말 공감했는데요.
이 글에 따르면, 최근 연구들도 이러한 우려에 힘을 실어줍니다. 2025년 마이크로소프트(Microsoft)와 카네기 멜론(Carnegie Mellon) 연구진의발표에 따르면, 사람들이 AI 도구에 더 많이 의존할수록 '비판적 사고'를 덜 하게 되는 것으로 나타났다고 합니다. AI의 능력을 신뢰할수록 사람들이 특히 쉬운 작업에서 “정신적으로 한 발 물러서게”된다는 것입니다. 장기적으로 그렇게 의존할수록 독립적인 문제 해결 능력의 감소로 이어질 수 있다고 하고요. 또 AI가 획일적인 답변을 내놓기 때문에 사람들이 어떤 문제에 대해 '덜 다양한 해결책'을 만들어내기도 하는데, 이는 '비판적 사고의 저하'로 볼 수 있다고 합니다.
애디가 글에서 소개한 실제 개발자의 경험담은 더욱 와닿습니다. 한 엔지니어는 12년간의 프로그래밍 경력에도 불구하고 AI가 바로바로 도움을 주다 보니 "자신의 기술이 퇴보했다"고 고백했답니다.
LLM이 즉시 설명을 해주다보니 처음에는 문서 읽기를 중단했고, 그러자 디버깅 기술이 약해졌다고 합니다. 스택 추적과 오류 메시지가 부담스럽게 느껴져서 AI에 복사 + 붙여넣기해서 해결했고요. 이게 반복되니 “나는 인간 클립보드가 되었다”고 한탄합니다. 예전에는 오류 하나하나가 배움의 기회였지만, 이제 해결책이 뿅 나타나버리니 배우는 것이 없어졌고요.
시간이 지나면서는 ‘깊은 이해’가 사라졌습니다. 문제를 깊이 이해하기 위해 오랜 시간을 들이기보다 AI가 제안하는 모든 것을 구현하게 됐다고 해요. 그게 작동하지 않으면 프롬프트를 수정해 다시 질문하는 ‘점점 더 의존하는 순환’에 빠졌고요. 또 예전에는 어려운 버그를 해결하는 게 기쁜 일이었지만 이제 AI가 해결책을 금방 내놓지 않으면 좌절감이 드는 것으로 변했지요.
그 개발자는 자신의 블로그에 이런 고백을 하면서 “우리는 AI와 함께 10배 개발자가 되는 것이 아니라, AI에 10배 더 의존하게 되고 있다”며 “우리가 스스로 해결할 수 있었던 문제를 AI가 해결하도록 내버려 둘 때마다, 우리는 장기적인 이해를 단기적인 생산성과 맞바꾸고 있는 것이다”고 합니다.
버스팩터와 AI팩터?
애디는 이 개발자의 고백을 소개하며, 나의 기술이 퇴보하고 있는지 알 수 있는 구체적이지만 미묘한 신호 네 가지를 이야기합니다.
디버깅 절망
디버거를 건너뛰고 바로 AI에게 모든 예외 처리를 묻고 있다면 퇴보의 신호일 수 있습니다.스택 트레이스를 읽거나 코드를 단계별로 살펴보는 것이 이제는 힘든 일처럼 느껴진다면 이 기술에 주의를 기울여야 합니다.
묻지마 복사-붙여넣기 코딩
AI가 준 코드가 왜 작동하는지, 어떻게 동작하는지 설명할 수 없는데도 그냥 붙여넣고 있나요? 애디는 특히 주니어 개발자들이 AI로 코드를 빠르게 배포하면서도, 특정 해결책을 왜 선택했는지 또는 엣지 케이스를 어떻게 처리하는지 질문받으면 당황한다고 지적합니다.
아키텍처 및 큰 그림 사고 부족
AI 없이는 고차원적인 설계를 꺼리게 되나요? AI는 단편적인 문제 해결에는 능하지만, 복잡한 시스템 설계나 전체적인 맥락을 파악하는 데는 한계가 있다고 합니다. 애디는 경험 많은 엔지니어들이 오랜 시간 노력해 얻은 직관을 통해 성능, 보안, 유지보수와 같은 더 넓은 관점에서 구성 요소가 어떻게 맞물리는지 고려하는 능력이 약화될 수 있다고 우려합니다.
기억 및 회상 능력 감소
자주 쓰는 API 호출이나 언어 문법도 AI 자동 완성이 없으면 기억나지 않나요? 애디는 AI 자동 완성에 너무 의존하여 일상적인 구문이나 개념조차 기억나지 않는다면 기술이 퇴색하고 있는 것일 수 있다고 경고합니다.
궁극적으로 애디는 과도한 의존은 '비판적 사고 위기'를 초래할 수 있다고 말합니다. AI가 해결할 수 없는 문제에 직면했을 때, 스스로 해결할 능력이 없어서 당황하게 될 수 있다는 거죠. 그는 이미 AI 코딩 어시스턴트 서비스 중단 시 개발 워크플로우가 완전히 멈춰버려 개발자들이 당황했던 사례가 있었다고 언급합니다. AI에 무비판적으로 의존하면 스스로를 기술적으로 무력하게 만들어버릴 수 있다는 것입니다.
팀 차원에서도 문제가 발생한다는데요. 특히 주니어 개발자들이 AI에만 의존하게 되면 시니어 개발자로부터의 멘토링이나 지식 전수가 어려워질 수 있습니다. 또한, AI가 미묘하게 틀린 코드를 생성해도 경험 부족으로 이를 놓쳐 버그나 보안 취약점으로 이어질 수도 있다고 하고요. 애디는 이 문제도 ‘버스팩터’처럼 생각해야 하는 게 아니냐고 합니다. ‘팀원 중 몇 명이 버스에 치이면 프로젝트가 망하는가’처럼 ‘AI 서비스가 중단되면 개발이 중단되는가?’를 프로젝트의 리스크로 생각해봐야 한다는 거죠.
AI를 비판적으로 활용하는 전략 7가지
그렇다고 촛불 켜고 코딩하던 시대로 돌아가자는 것은 아닙니다. 애디는 AI는 분명 강력한 도구이며, 그 이점을 최대한 활용해야 한다고 강조합니다. 핵심은 '지혜롭게' 사용하는 것이며, AI가 작업 자체뿐만 아니라 '우리의 비판적 개입'까지 아웃소싱하게 두어서는 안 된다는 것입니다.
그의 목표는 ‘AI로 얻을 수 있는 생산성 향상과 편리함을 누리면서도, 우리 자신의 핵심 기술 세트를 약화시키지 않는 것’입니다. 즉, AI를 '협력자(collaborator)'나 주니어 페어 프로그래머처럼 대해야 한다고 하고요. 이를 위해 비판적으로 AI를 활용하는 구체적인 전략 7가지를 제안합니다.
- "AI 위생" 실천: 항상 검증하고 이해하기
AI 결과물이 그럴듯해 보여도 맹신하지 말고, 적극적으로 '레드 팀'처럼 오류나 예외 상황을 찾아보라고 조언합니다. AI가 코드를 생성했다면, 테스트 케이스로 시험해보고 "이 솔루션이 왜 작동하는지? 한계는 무엇인지?" 스스로에게 질문해야 합니다. AI에게 코드 설명을 요청하거나 다른 접근 방식을 물어보면서 학습 도구로 활용하는 것도 좋은 방법입니다. 수동적인 답변을 능동적인 학습으로 바꾸는 것이죠.
- 기본적인 것에는 AI 사용하지 않기
애디는 일주일에 특정 시간을 정해 '수동 모드' 코딩을 해보라고 제안합니다. 한 경험 많은 개발자는 일주일에 하루 "노-AI 데이"를 정해 AI 없이 코드를 작성하고 오류를 직접 읽으며 문서를 찾아보았다고 합니다. 처음에는 느리고 답답하게 느껴질 수 있지만, 이는 코딩 뇌를 위한 '크로스 트레이닝'이라고 생각하라고 그는 말합니다.
- AI에게 묻기 전에 스스로 먼저 시도하기
문제에 부딪혔을 때 바로 AI에게 묻지 말고, 먼저 15~30분 정도 스스로 조사하고 해결책을 구상해보라고 조언합니다. 디버깅이나 콘솔 로그를 활용하며 코드를 직접 들여다보는 연습을 하는 것입니다. 충분히 고민한 후 AI의 도움을 받는다면, AI의 답변과 자신의 생각을 비교하며 진정으로 배울 수 있다는 것이죠.
- 코드 리뷰를 보완하는 데 AI를 활용하기
AI가 생성한 코드도 동료 개발자가 작성한 것처럼 꼼꼼히 검토하라고 제안합니다. AI 기여분에 대해서도 인간 코드 리뷰를 진행하는 것이 좋다고 말합니다. 그는 "AI가 초안을 만들었지만, 소유권은 우리에게 있다"는 문화를 조성하여, 모든 코드는 누가 작성했든 팀 전체가 이해하고 유지보수할 책임이 있다는 인식을 공유하라고 강조합니다.
- 능동적 학습하기: 후속 질문과 반복 반복하기
AI 솔루션이 작동했다고 해서 바로 다음으로 넘어가는 게 아니라, 잠시 시간을 내서 그 지식을 확실히 내 것으로 만들라는 조언입니다. 예를 들어, AI가 복잡한 정규식이나 알고리즘을 구현해줬다면, 그것을 쉬운 말로 설명해보거나 AI에게 "왜 다른 방식은 안 되는지?"를 질문해보세요. 애디는 이런 방식이 AI를 코드를 던져주는 도구가 아니라 '무한한 인내심을 가진 튜터'처럼 활용하는 것이라고 말합니다.
- "AI 도움" 학습 일지 또는 목록 만들기
AI의 도움을 자주 받는 항목들을 기록해두라고 합니다. 그렇게 하면 지식이 부족한 부분, 채워야 할 부분이 무엇인지 알 수 있습니다. 자주 묻는 주제에 대해서는 스스로 학습해 다음번에는 AI 없이 해결하도록 도전해보는 것입니다. “AI는 '최후의 보루'가 되어야 한다.”는 것입니다.
- AI와 '페어 프로그래밍' 하기
AI를 단순히 쿼리를 던지는 API처럼 대하지 말고, 페어 프로그래밍 파트너처럼 대화하며 사용해보라고도 조언합니다. 예를 들어, 함수를 작성하고 AI에게 개선 사항이나 실수를 찾아달라고 하거나, AI가 작성한 초안을 스스로 다듬는 것이죠. "이 함수는 작동하는데, 명확성을 위해 리팩토링을 도와줄 수 있을까?"와 같은 대화를 통해 우리가 주도권을 유지할 수 있다고 설명합니다.
애디 오스마니는 이처럼 AI의 유익함을 활용하되, 모든 것을 기계에 의존하는 게 아니라 나의 능력을 증폭시키는 도구로 사용해야 한다고 강조했습니다. 그를 위해 엔지니어로서 AI에 의존하고 있다는 징후를 알아차릴 수 있도록 가이드하고, 실제로 AI를 비판적으로 사용할 수 있는 구체적인 방법을 제시했습니다.
글 마지막 단락 부분에는 “코딩을 사랑한다면, 단순히 더 빠르게 기능을 만들어내는 것을 넘어, 우리가 이 분야에 발을 들여놓게 된 '문제 해결의 즐거움과 기술'을 보존하는 것이 중요”하다는 문장이 있는데요. 코드랑 버그랑 씨름하면서 개발자로 재미를 느꼈던 순간들이 떠오르네요. 디버깅 로그를 하나하나 들춰보다가 딱 퍼즐처럼 뭔가 맞춰지는 순간이 있었죠. 빨리 해결되지 않고 고통스럽기도 했지만 그런 경험이 쌓여 저만의 경험과 자신감을 만들었던 게 아닌가 합니다. 여러분은 어떠신가요?
그는 끝으로 “성공하는 개발자는 인간의 직관과 경험을 AI의 초능력과 결합하는 사람들, 즉 자동 조종 장치 유무에 관계없이 코드베이스를 탐색할 수 있는 사람들일 것”이라며, “AI가 당신을 대체할 것을 걱정하지 마세요. 당신을 대체할 수 없게 만드는 기술을 개발하지 않는 것을 걱정하세요.”라고 말합니다.
저도 AI와 함께 개발하는 원칙을 하나씩 잡아가야겠습니다. “노 AI-데이”같은 아이디어도 좋아보이네요. 여러분의 노하우나 경험이 있으면 공유해주세요!
