솔직히 말씀드리면, 저는 GPT-4가 처음 나왔을 때 그냥 자동완성 도구 정도겠거니 했습니다. 20년 가까이 코드를 짜온 사람으로서, 새로운 도구가 나올 때마다 과대포장된 경우를 너무 많이 봐왔거든요. 그런데 실제로 써보고 나서 그 생각이 완전히 바뀌었습니다. 문제는 속도가 아니었습니다. 일을 대하는 방식 자체가 달라졌습니다.
생산성: 숫자가 말해주는 것과 말해주지 않는 것
개발자들 사이에서 AI 도구 도입 이후 생산성이 올랐다는 이야기는 이제 낯설지 않습니다. 실제로 개발자 커뮤니티 전반에서 AI 도구 사용률이 빠르게 높아지고 있는데, GitHub Octoverse 리포트에 따르면 AI 코드 어시스턴트를 사용하는 개발자의 55% 이상이 반복 작업 시간이 줄었다고 응답했습니다(출처: GitHub).
제가 직접 써봤는데, 숫자로는 설명이 안 되는 변화가 있었습니다. 예전에 레거시 코드(legacy code), 그러니까 오래되어 구조 파악이 어려운 기존 코드를 분석할 때면 3일이 기본이었습니다. 코드를 한 줄씩 따라가면서 의존성을 손으로 그려가며 파악했죠. 지금은 그 작업을 반나절 안에 끝냅니다. 코드를 붙여넣고 잠재적 버그와 리팩터링(refactoring) 포인트를 짚어달라고 하면, 제가 놓쳤을 법한 엣지 케이스(edge case)까지 건드려줍니다. 리팩터링이란 기능은 그대로 두면서 코드의 내부 구조를 개선하는 작업을 말하고, 엣지 케이스란 정상 범위를 벗어난 특이한 입력값이나 조건을 의미합니다.
물론 AI가 틀릴 때도 있습니다. 맥락을 잘못 짚거나, 코드베이스(codebase) 전체를 이해하지 못한 채 단편적인 조언을 내놓는 경우도 있습니다. 코드베이스란 한 프로젝트에서 관리되는 소스 코드 전체를 가리키는 말입니다. 그래서 AI가 내놓는 결과물을 무비판적으로 붙여넣는 개발자와, 그것을 검토하고 판단하는 개발자 사이의 차이는 오히려 더 벌어지고 있다는 생각이 듭니다.
AI가 생산성을 높인다는 주장에 동의하는 분들도 있는 반면, 단순 작업만 빨라질 뿐 진짜 실력 향상에는 도움이 안 된다는 시각도 있습니다. 저는 둘 다 맞다고 봅니다. 도구를 어떻게 쓰느냐의 문제이기 때문입니다. Stack Overflow의 2024년 개발자 서베이에서도 AI 도구에 대한 신뢰도는 높지만 결과물을 항상 검증해야 한다고 응답한 비율이 과반을 넘었습니다(출처: Stack Overflow). 도구가 강력할수록 쓰는 사람의 판단력이 더 중요해진다는 이야기입니다.
AI 도구를 활용할 때 실질적으로 달라지는 업무 영역을 정리하면 다음과 같습니다.
- 레거시 코드 분석 및 문서화 속도 단축
- 반복적인 보일러플레이트 코드 작성 자동화
- 코드 리뷰 과정에서 놓치기 쉬운 엣지 케이스 사전 점검
- 에러 메시지 해석 및 디버깅 방향 제시
설계사고: AI가 열어준 시간을 어디에 쓸 것인가
제가 가장 크게 체감한 변화는 사실 속도가 아니었습니다. '생각의 밀도'가 달라졌다는 표현이 더 정확합니다. AI 이전에는 구현 방법을 찾는 데 전체 업무 시간의 60% 가까이를 쏟았던 것 같습니다. 어떤 API를 써야 하는지, 어느 라이브러리가 적합한지 찾는 데 대부분의 에너지가 들어갔습니다. 그러다 보니 소프트웨어 아키텍처(software architecture), 즉 시스템 전체의 구조와 구성 요소 간의 관계를 설계하는 작업은 늘 뒤로 밀렸습니다.
지금은 구현의 초안을 AI가 빠르게 잡아주기 때문에, 그 시간을 '왜 이렇게 설계해야 하는가'에 쓸 수 있습니다. 이것이 단순한 효율 향상과는 다른 이야기입니다. 브라이언졸프슨과 맥아피가 『The Second Machine Age』에서 지적했던 핵심도 비슷합니다. 자동화가 단순 반복 작업을 대체하면, 인간에게는 더 고차원적인 판단과 창의적 문제해결이 요구된다는 것입니다.
그렇다면 AI가 개발자를 대체할 것이라는 공포는 타당한가. 저는 과장된 동시에 안이한 반응이라고 생각합니다. 과장된 이유는 분명합니다. 비즈니스 요구사항을 코드로 번역하는 과정에는 수많은 비명시적 맥락(implicit context)이 개입합니다. 비명시적 맥락이란 문서에 적혀 있지 않지만 조직 내에서 암묵적으로 공유되는 제약조건과 우선순위를 말합니다. AI는 이 부분에서 여전히 한계가 뚜렷합니다.
그러나 동시에 안이한 반응이기도 합니다. '대체되지 않는다'는 안심이 도구 학습을 미루는 명분이 되는 순간, 그 개발자는 AI를 제대로 활용하는 동료에게 밀릴 수밖에 없습니다. 솔직히 이 부분이 제 주변에서도 제일 많이 보이는 패턴입니다. 연차가 높을수록 기존 방식에 대한 확신이 강해서, 오히려 새로운 도구 앞에서 더 보수적이 되는 경우가 있습니다. 경험은 분명히 자산이지만, 그것이 변화를 거부하는 명분이 되면 곤란합니다. 20년 경력자가 주니어에게 프롬프트 엔지니어링(prompt engineering)을 배워야 하는 상황이 왔습니다. 프롬프트 엔지니어링이란 AI 모델에서 원하는 결과를 끌어내기 위해 입력 문장을 설계하는 기술을 말합니다. 연차와 별개의 스킬입니다.
McKinsey Global Institute의 분석에 따르면 생성형 AI는 지식 노동 전반에서 생산성을 연간 수조 달러 규모로 끌어올릴 잠재력이 있다고 추산됩니다(출처: McKinsey Global Institute). 그 혜택이 모든 개발자에게 균등하게 돌아가지는 않을 것입니다. AI를 제대로 다루는 사람과 그렇지 않은 사람 사이의 격차가 앞으로 더 커질 가능성이 있습니다.
결국 중요한 건 AI가 무엇을 할 수 있는가가 아니라, 내가 그 도구로 무엇을 하려고 하는가입니다. 구현을 빠르게 처리해주는 도구를 손에 쥐었을 때, 남은 시간을 설계와 판단에 쓰는 개발자와 그냥 더 빨리 같은 방식으로 일하는 개발자의 5년 후는 꽤 다를 것이라고 저는 봅니다. 지금 당장 AI 도구를 아직 써보지 않으셨다면, 일단 레거시 코드 하나를 붙여넣고 리팩터링 포인트를 물어보는 것부터 시작해보시길 권합니다. 결과보다 그 과정에서 본인이 어떤 질문을 하게 되는지가 더 중요한 출발점이 될 것입니다.
참고:
McKinsey Global Institute, "The Economic Potential of Generative AI", mckinsey.com
GitHub Octoverse Report 2023, github.blog/octoverse
Stack Overflow Developer Survey 2024, survey.stackoverflow.co/2024
Erik Brynjolfsson & Andrew McAfee, "The Second Machine Age", MIT