왜 멍청한 개발자는 더 멍청해질까?

인공 지능(AI)이 코드를 제안하고, 작성하며, 심지어 디버깅까지 가능한 시대가 되면서, “개발자들은 이러한 스마트 도구에 의존함으로써 ‘멍청해질’ 위험이 있는가?”라는 도발적인 질문이 떠오른다.

규칙 기반에서 AI 주도로: 소프트웨어 개발에서의 AI 간략사

소프트웨어 개발에서 AI가 갑자기 등장한 것은 아니다. 프로그래밍 업무를 자동화하려는 아이디어는 이미 수십 년 전부터 존재했다. 사실, 지능형 코드 자동완성의 시초는 1950년대까지 거슬러 올라가며, 단순한 스펠체크 같은 툴이 코딩 타이포를 잡아주곤 했다. 1970년대에는 4세대 언어(4GL)와 모델 기반 접근법이 부상하며, 고수준 사양에서 코드를 생성하겠다는 약속을 내세웠다. 물론 이는 현재의 관점에서 보면 “AI”라고 부를 만한 수준은 아니었지만, 스스로 코드를 작성한다는 꿈에 대한 토대를 마련했다.

21세기로 넘어오면서 머신 러닝이 성숙해짐에 따라, 프로그래밍 영역에도 점차 적용이 이루어졌다. 2017년 마이크로소프트와 케임브리지 대학교 연구진이 선보인 DeepCoder는, 기존 코드 조각들을 조합하여 간단한 코딩 문제를 해결할 수 있다는 점을 입증했다. 제한적이긴 했지만, AI 주도로 프로그래밍을 할 수 있다는 개념을 확실히 보여준 사례였다. 이듬해인 2018년에는 IntelliCode가 출시되어, 파이썬, C++, 자바스크립트 등 다양한 언어에 대해 더욱 정교한 코드 자동완성을 제공하기 시작했다.

그러나 진정한 돌파구는 2020년대 LLM의 부상에서 비롯된다. GitHub Copilot은 OpenAI의 Codex 모델을 기반으로 2021년에 공개되어, 사실상 어떤 언어로든 전체 함수를 자동 완성하거나, 해결책을 제안해 주며 개발자들을 놀라게 했다. 뒤이어 Amazon CodeWhisperer 등 다른 AI 페어 프로그래밍 도구들이 출시되면서, AI 보조가 주류로 자리 잡았다. 2022년 말에는 OpenAI의 ChatGPT(기반 모델: GPT-3.5)가 등장해, 원하는 코드를 작성해 줄 뿐 아니라 대화형으로 설명과 디버깅까지 수행해 주면서 GPT-4 이후 시대의 청사진을 보여주었다. 업계 애널리스트들은 GPT-4와 같은 최신 LLM이 “코드 스니펫을 제안하고, 기술적 질문에 답하며, 간단한 애플리케이션 일부를 작성하기까지 한다”고 평가했고, 그로 인해 개발자가 “적어도 두 배 이상의 생산성을 얻을 수도 있다”고 주장했다. 요컨대, 이제 AI는 더 이상 한정된 도우미 역할을 넘어, 소프트웨어 개발에서 보편적인 존재가 되었다.

LLM 효과: 코딩 역량이 강화되는가, 저하되는가?

강력한 LLM의 등장은 프로그래밍 역량을 확실히 강화해 왔다. 오늘날의 AI 보조는 몇 초 만에 반복적인 코드를 생성해 주고, 모범 사례를 제안하며, 심지어 복잡한 작업(예: 코드 간 번역)도 지원한다. 예컨대, 이전까지는 스택 오버플로(Stack Overflow)를 샅샅이 뒤져야 알 수 있었던 클라우드 서비스 연결 방법이나 난해한 SQL 쿼리 작성법을, 이제는 ChatGPT에게 물어보면 맞춤형 예시 코드와 함께 즉각적인 답변을 얻을 수 있다. 이는 지루한 작업에 쓰는 시간을 줄이고, 창의적인 문제 해결에 더 많은 시간을 투자할 수 있게 한다는 뜻이다. 또한 LLM 기반 툴은 교육적 측면에서도 상당히 유용하다. 낯선 프레임워크를 접하는 개발자는 AI가 제공하는 제안을 통해 그 생태계에서 “이렇게 사용하는구나” 하는 관습적 활용법을 곧바로 배울 수 있다. 실제로 Copilot 사용자는 종종 새로운 라이브러리나 언어 기능을 발견하게 되었다고 전하며, 이는 생산성 향상만이 아니라 학습 보조 역할도 함께 하고 있음을 시사한다.

한편, 이러한 장점이 코어 코딩 스킬을 약화할 수도 있다는 우려도 만만치 않다. AI가 생성한 코드를 깊이 이해하지 않고 그대로 받아들이는 경우, “오토파일럿 모드의 조종사”가 될 위험이 있다. 베테랑 프로그래머들은 디버깅과 알고리즘 설계 과정을 생략함으로써 문제 해결에 필요한 “근육 기억”이 약해질 수 있다고 지적한다. 과거에는 코드를 작성하며 논리와 극한 상황(edge case)을 면밀히 고민했지만, 이제 성급한 개발자는 AI가 제안하는 코드를 탭으로 자동완성만 해 버릴 수 있다. 장기적으로 이는 기본기에 해당하는 코드를 직접 작성하거나 까다로운 버그를 해결하는 능력을 약화시킬 수 있다. “왜 Copilot이 프로그래머를 더 못하게 만드는가?”라는 제목의 어느 칼럼에서는 자동 생성 코드를 매번 수용하면 “기본 프로그래밍 역량이 서서히 침식될 수 있다.”고 경고했다.

코드 품질과 정확성 문제도 중요한 이슈다. LLM은 훈련 데이터에서 발견된 패턴을 바탕으로 결과를 생성할 뿐, 실제로는 코드의 의도를 “추론”하지 않는다. 즉, AI가 제안한 코드가 때때로 비효율적이거나 보안상 취약하거나, 전혀 잘못된 경우도 있다. 개발자가 “AI가 만들어 줬으니 맞겠지”라고 안일하게 생각하면, 부적절하거나 버그가 내재된 코드를 배포할 위험이 생긴다. 예컨대, AI는 편리해 보이는 스니펫을 제안하지만, 사실 동일한 로직을 다른 곳에서도 이미 사용하고 있을 수 있다. 이렇게 되면 코드를 중복 작성하게 되고, 이는 추후 유지보수에 골칫거리를 일으킬 수 있다. 요컨대, LLM은 개발 역량을 ‘확장’해 주는 동시에, ‘과의존’ 시 우리의 개인적 스킬이 퇴화하고, 작성하는 소프트웨어에도 새로운 위험 요소가 스며들 수 있다는 양날의 검이다.

AI 지원 vs. 전통적 워크플로: 생산성 대 위험성

오늘날 개발자의 일상 워크플로는 AI 덕분에 어떻게 달라졌을까? 그리고 기존의 코딩 방식과 비교하면 어떤 차이가 있을까? 그 차이는 매우 극적이다.

제로(0)부터 코딩 vs. 프롬프트(prompt) 활용

전통적 워크플로에서, 새로운 기능을 구현하려면 빈 페이지에서 시작하여 접근 방식을 구상하고, 한 줄씩 코드를 작성하며, 필요할 때마다 문서를 찾아보거나 구글링을 했다. 반면 AI 지원 워크플로에서는 자연어로 문제나 기능을 설명하거나 주석을 남기는 것에서 출발한다. 그러면 AI가 이를 코드로 확장해 준다. 예컨대 데이터 모델이나 API 클라이언트를 만들 때, 기존에는 보일러플레이트 코드를 일일이 작성해야 했지만, 이제는 AI가 순식간에 초기 버전을 제시한다. 즉, 수작업이 많이 필요한 부분을 AI가 대신해 주고, 개발자는 ‘프롬프트 엔지니어링(prompt engineering)’이라 불리는 기법을 습득해, 문제를 어떻게 묘사할지를 잘 고민해야 한다.

속도와 반복(Iteration)

AI 지원 코딩은 작성-테스트-개선 사이클을 극적으로 단축한다. GitHub의 한 연구 결과에 따르면, Copilot을 사용한 프로그래머가 그렇지 않은 프로그래머보다 평균 55% 더 빠르게 작업을 완료했다고 한다. 이는 매우 놀라운 효율 증가다. 예전에는 함수를 하나 작성하는 데 몇 시간을 소비했을 문제가, 이제 몇 분 만에 작동 가능한 프로토타입을 얻고, 그걸 기반으로 빠르게 개선할 수 있다. 전통적 워크플로는 해결책을 찾기 위해 포럼을 뒤지거나 API 문서를 읽는 데 많은 시간을 들였지만, AI가 즉시 답을 제시하기 때문에 그 과정을 대폭 줄일 수 있다. 이에 대해 포레스터(Forrester)의 한 애널리스트는 AI가 생산성을 두 배로 끌어올리는 것은 보수적인 추정치라고도 언급했다.

협업과 지식 공유

AI 없는 워크플로에서는 코드 리뷰, 페어 프로그래밍, 문서화를 통해 사람들 사이에서 지식이 공유되었다. AI와 함께라면, 이 지식 공유의 일부가 외부화된다. LLM 모델이 이미 수백만 개의 예제를 “학습”했기에, 사용자가 팀 동료나 블로그를 찾지 않아도, 생소한 라이브러리의 사용법을 AI가 알려줄 수 있다. 물론, 이는 팀의 협업 양상을 바꾸기도 한다. 예전에는 모두가 머리를 맞대고 아이디어를 공유했지만, 지금은 각자가 AI에게 물어보는 방식으로 바뀔 수 있다. 인간이 사라지지는 않지만, 그 역할이 변형되는 것이다.

그러나 이처럼 뚜렷한 장점에도 불구하고, AI 지원 워크플로는 전통적 워크플로에서 발생하지 않았던 새로운 문제와 위험을 동반한다.

수백만 라인의 코드를 분석한 최근 연구를 보면, AI를 활발히 사용하는 환경에서 오히려 나쁜 습관이 확산될 수 있다는 경고가 있다. 예컨대 GitClear의 2024년 연구에 따르면, AI가 제안한 코드를 다량 받아들인 코드베이스에서는 중복된 코드가 폭발적으로 증가했다. 즉, 복사해 붙인 코드가 8배 늘어났고, 대신 코드를 재구조화하거나 리팩터링하는 비율은 40% 가까이 줄어들었다고 한다. 아래 차트는 이를 시각화한 것으로, AI가 제안하는 코드를 쉽게 추가할 수 있게 됨에 따라 복사/붙여넣기된 코드(중복 로직)가 크게 늘어났고, 그와 동시에 코드 이동이나 재구조화(즉, 체계적으로 정리하는 작업)는 급감했다. 전통적 워크플로에서는 책임감 있는 개발자가 기존 함수를 재활용하는 방식을 고민하겠지만, AI는 입력 토큰 수의 범위를 넘어서는 코드 전체를 인식하지 못하는 경우가 많아, 기존에 있는 함수를 알려주기보다는 새 코드를 첨부하는 식으로 “다시 만들어” 버릴 수 있다. 결과적으로 코드 작성은 빨라지지만, 코드베이스가 더 지저분해지는 셈이다.

GitClear의 2020~2024년 데이터는 AI가 만든 코드의 잠재적인 단점을 시사한다.

갈색 선(복사/붙여넣기된 코드)은 AI 사용이 증가함에 따라 급상승하고, 녹색 선(리팩터링/이동된 코드)은 줄어드는 모습을 보인다. 이는 AI 지원 워크플로가 코드 품질을 유지하기 위해 더 많은 주의가 필요함을 보여준다.

품질 보증과 디버깅

전통적 개발에서 디버깅은 핵심 스킬이었다. 코드를 단계를 나눠 추적하고, 테스트를 작성하며, 실패 원인을 논리적으로 추적했다. AI 지원 방식에서는 이 부분이 두 가지 면에서 달라진다. 첫째, AI가 테스트 코드 작성과 버그 수정까지 지원한다. 둘째, 버그의 성격 자체가 달라질 수 있다. AI의 “이해 부족”에서 기인하는 문제가 생길 수 있기 때문이다. AI 모델은 코드의 의도를 진짜로 이해하지 못하므로, 인간이라면 피했을 오류 - 예를 들면 오프바이원(off-by-one) 에러나 잘못된 엣지 케이스 처리, 보안상 취약한 방식 - 를 의도치 않게 내놓을 수 있다. 따라서 AI가 생성한 코드를 검토하고 테스트하는 일이 매우 중요해진다. 한 전문가가 “사람도 나쁜 코드를 만들 수 있지만, 인간은 자기가 나쁜 코드를 썼다는 사실을 인지하고 이를 통해 배울 수 있다. 반면 AI가 나쁜 코드를 만들었을 때는 사용자가 그걸 알아차리지 못할 수 있다”고 꼬집은 것도 같은 맥락이다. 즉, AI 지원 워크플로를 도입할수록 코드 리뷰와 테스트 문화가 더욱 강조되어야 하며, 게으름을 피울 여유가 없다. 오히려 AI가 코드를 쓰는 만큼 더 많은 주의력이 요구될 수 있다.

보안 및 윤리적 고려

전통적 코딩에서는 개발자의 지식에 기반해 위험한 함수나 라이선스 문제를 피하도록 했다. 하지만 공개된 코드를 학습한 AI 툴은 구식 암호화 기법 같은 취약한 패턴이나, 저작권이 있는 코드를 무심코 되풀이할 수 있다. 실제로 AI 모델이 훈련 데이터에서 본 것을 그대로 답습하며 알려진 취약점을 포함한 코드를 제안하거나, 저작권이 있는 코드를 복제한 사례가 보고되기도 했다. 따라서 AI가 내놓은 결과물은 신뢰할 수 없는 코드로 간주하고, 충분한 보안 검사와 준법성 확인을 거치는 것이 바람직하다. 또한 프롬프트에 민감한 코드를 넣었을 때, 이 정보가 다른 사용자나 모델에 유출될 가능성이 있는지, AI가 생성한 코드가 누군가의 특허나 라이선스를 침해하지 않는지 등, 전통적 워크플로에서는 고려하지 않아도 됐던 문제도 새롭게 대두되고 있다.

결론적으로, AI 지원 워크플로는 개발 과정을 터보 엔진처럼 가속해 주고, 지루한 일을 줄여 주며, 누구든 놀라울 정도의 속도로 코드를 쓸 수 있게 한다. 하지만 이러한 편의는 때로 함부로 사용했을 때 생길 수 있는 함정— 코딩 습관이 엉망이 되고, 잠재적인 버그가 도사리며, 법적 또는 보안상 문제까지 야기—이 존재한다. 궁극적으로 최고의 결과는 하이브리드 접근에서 나온다. AI가 제공하는 속도 이점을 누리되, 전통적 소프트웨어 엔지니어링의 기초(코드 리뷰, 리팩터링, 테스트, 설계)를 철저히 지키는 것이다. AI는 코딩 방식을 바꿔 놓았지만, 뛰어난 엔지니어링 습관과 인간의 통찰력은 여전히 핵심이다.

AI 도구는 이미 코딩의 여러 영역에서 광범위하게 사용되고 있다. 최근 자바(Java) 개발자 대상 조사에 따르면, 응답자의 60%가 AI 기능 중 코드 자동완성을 가장 자주 사용하며, 39%는 코드 리팩터링, 30%는 오류 감지에 사용한다고 답했다. 심지어 문서 생성이나 디버깅 보조 작업 역시 AI가 처리하는 사례가 늘고 있다. 이는 현대 워크플로에서 AI가 얼마나 깊이 통합되었는지를 잘 보여준다.

자동조종 장치에 갇히기: 기술 정체의 위험

AI 시대에 개발자들이 직면하는 가장 큰 위험 중 하나는 기술 정체(skill stagnation)다. 즉, AI 툴에 지나치게 의존하거나, 새로운 기술에 적응하지 못하는 바람에 성장하지 못하거나, 심지어 역량이 후퇴하는 상황이다. 말하자면, 멍청한 개발자가 더 멍청해지는 상황은, 결국 자신이 발전하기를 멈출 때 벌어진다.

예를 들어, 10년 넘게 특정 언어나 도구에만 익숙해진 개발자가 있다고 치자. 갑자기 AI가 그가 잘한다고 생각했던 작업 중 상당 부분을 대신 해준다. 만약 그 개발자가 “이제 편하네”라고 안심하고 새로운 것을 배우지 않는다면, 이는 심각한 문제다. 기술 분야는 발전 속도가 워낙 빨라, 변화에 적응하지 않는 사람을 금세 도태시켜 버린다. 실제로 AI가 개발 업무의 중심이 되어 가는 상황에서, 스스로 제자리걸음을 하면 그것이야말로 ‘멍청함’의 극치다. 예컨대 2010년대에 최신 프레임워크 학습을 거부한 개발자를 상상해 보면, 90년대 기술에만 머물렀을 때 얼마나 빠르게 시장에서 소외되었을지 짐작할 수 있다. AI가 패러다임 전환을 일으키는 지금, 이를 무시하거나 사용법을 배우지 않는다면, 업계 흐름에서 멀어지는 것은 시간문제다.

하지만 정체가 단지 AI를 외면하는 데서만 오는 것은 아니다. AI를 ‘목발’처럼 쓰는 것에서도 비롯될 수 있다. AI에게 모든 함수를 맡기는 주니어 개발자를 생각해 보자. 당장은 업무를 빠르게 끝낼 수 있지만, AI가 무슨 일을 하는지 제대로 이해하지 못한다면 성장이 정체될 것이다. 흔하지 않은 문제 상황을 맞닥뜨렸을 때, AI가 학습한 일반적 패턴과 맞지 않으면 제대로 해결하지 못할 가능성이 높다. 이는 마치 늘 내비게이션만 쓰다가, GPS 없이 길을 찾으려면 방법을 모르는 상황과 비슷하다. AI 보조가 코딩 세션을 매번 “운전”하게 내버려 두면, 스스로 코드를 짜는 능력이 점차 쇠퇴할 수 있다. 실제로 몇몇 연구자는 AI 어시스턴트가 숙련자들의 기술을 빠르게 사장시키고, 초보자들의 역량 습득을 방해할 수 있다고 주장한다. 이는 AI가 유능해 보이는 착각을 불러일으켜, 사용자가 실제 역량이 떨어지고 있다는 사실을 인지하지 못하게 하기 때문이라는 것이다.

그러면 어떻게 하면 더 멍청해지지 않을 수 있을까? 핵심은 의식적인 활용과 꾸준한 학습이다. AI를 받아들이되, 수동적으로 수용하지 않는 태도가 중요하다. AI가 제안한 해결책이 왜 유효한지를 분석하고, 단순히 복사 붙여넣기로 끝내지 말아야 한다. AI 결과물을 최종 답안 대신 과외 선생님의 힌트처럼 활용하라는 말이다. 결국 내가 운전대를 잡고, AI가 내비게이션을 해 주는 관계를 지키는 것이 핵심이다.

이와 동시에, AI가 쉽게 대체하기 힘든 새로운 역량을 키우는 일도 중요하다. 예컨대 고수준의 아키텍처 설계, 제품 요구 사항에 대한 비판적 사고, 혹은 AI 윤리나 데이터 프라이버시, 도메인 지식 같은 영역의 전문성은 AI가 단시간에 흉내 내기 어렵다. 전설적인 소프트웨어 엔지니어 그레이디 부치(Grady Booch)는 “AI는 프로그래머의 역할을 근본적으로 바꿀 것이다… 프로그래머를 없애진 않겠지만, 새로운 스킬을 익히고 새로운 방식으로 일하도록 요구할 것”이라고 말한 바 있다. 한마디로, 개발자는 계속 진화해야 한다. AI/ML 자체에 대한 이해를 높이거나(AI가 어떻게 작동하는지를 아는 것), AI를 보완하는 스킬(예: 시스템 설계, AI 출력물 해석)을 갈고닦고, 끊임없이 호기심을 유지해야 한다. 기술 분야에서 가장 멍청한 행동은 배움을 멈추는 것이기 때문이다. 가만히 서 있으면 사실상 뒤로 가는 것이나 마찬가지다.

AI 시대에 ‘더 똑똑해지기’ (멍청해지지 않기)

결국, 왜 멍청한 개발자는 더 멍청해지는가? 농담 섞인 답변을 하자면: 스스로 그렇게 놔두기 때문이다. 새로운 도구에 적응하지 않거나, AI에 모든 사고 과정을 위임해 버리면, 그 결과는 서서히 “멍청해지는” 것이다. 하지만 이는 결코 피할 수 없는 운명이 아니다. AI는 제대로 활용하면 개발자를 더 생산적이고, 더 창의적이고, 심지어 더 유능하게 만들 수도 있다.

소프트웨어 개발에서의 AI 역사를 돌아보면, 초기의 간단한 자동완성부터 시작해 오늘날의 LLM 보조 페어 프로그래밍까지, 단계적으로 인간 역량을 증폭해 온 흐름이 보인다. 매번 우리는 좀 더 기계적인 일을 덜어 내고, 새로운 가능성의 문을 열었다. 특히 LLM은 단순히 한 번의 코드 완성을 넘어, 실제로 개발자가 할 수 있는 작업의 폭을 넓히고 있다. 그 결과, 워크플로 또한 극적으로 바뀌어, 이전에는 상상하기 어려운 속도로 제품을 만들고 배포할 수 있게 되었다. 24시간 내내 “가상 페어 프로그래머”와 협업할 수 있으며, 수십 년치 오픈소스 코드를 학습한 지식의 저장소에 즉시 접근할 수도 있다.

업계 종사자와 프로그래밍 애호가 모두가 주목해야 할 사실은: ‘멍청한 개발자’가 되지 말아야 한다는 것이다. 여기서 말하는 ‘멍청하지 않음’은 두 가지 의미다. 첫째, AI가 편하다고 해서 스스로 생각하는 습관을 버리지 말라. 둘째, AI나 새로운 패러다임을 거부하지 말라. 유능한 개발자들은 이 둘을 균형 있게 추구한다. 지루한 작업을 AI에게 맡기되, 중요하고 핵심적인 설계 능력은 계속해서 갈고닦는다. AI가 개인의 지적 역량을 증폭시켜 줄 수 있도록 사용하는 것이며, AI가 나를 대체하게끔 방치하는 것이 아니다.

결국 “AI가 개발자를 멍청하게 만든다.”는 공포를 조장하는 말들은 AI를 과대평가하는 동시에 개발자를 과소평가하는 면이 있다. 뛰어난 엔지니어는 언제나 배움에 열정적이고, 시도와 실험을 즐기며, 문제 해결에 전념한다. AI는 그저 또 하나의 도구 - 아주 강력한 도구 - 일 뿐이며, 우리는 그것을 잘 다루는 방법을 배워야 한다. 그렇게 함으로써 AI는 우리의 작업을 한층 높은 차원으로 끌어올려 줄 것이다. 반면, 이를 무시하거나, 맹신하거나, 배우기를 거부한다면, “코드는 동작하지만 왜 이렇게 되는지는 모르겠다.”는 농담이 본인의 현실이 되어 버릴 수도 있다. 멍청해질지, 더 똑똑해질지는 결국 각자의 선택이다. 자동화와 인간의 창의성이 교차하는 이 중대한 시점에서, 인간의 직관과 AI의 능력을 조합해 더 나은 소프트웨어를 만드는 이들이 미래를 이끌어 갈 것이다. 결국 소프트웨어 분야에서 중요한 것은 모든 걸 다 아는 것이 아니라, 끊임없이 배우고, 적응하며, 주어진 모든 도구를 활용해 더 나은 프로그램을 작성하는 것이다. 그리고 이제 AI도 그 도구 상자에 들어온 이상, 제대로 다룬다면 우리 모두를 ‘더 똑똑하게’ 만들어 줄 것이다.