AI 생산성 뒤의 그림자: 러닝커브
저는 AI를 사용하려고 고생하시는 분들, 그리고 AI로 생산성을 올리라고 하는 여러 사람들을 위해서 메시지를 던지고 싶었습니다.
AI 사용이 단순히 편하거나 좋은 것이 아닌, 공부할 부분들이 매우 많고 실제로는 역효과가 날 가능성도 충분히 있다는 사실을 인지하면 좋겠다는 메시지를요.
이 아이디어는 해커 뉴스에 매일 벌어지고 있는 댓글 토론으로부터 생각했는데요, 바이브 코딩이라는 이름이 나온 지 6개월이 되었지만 시장에서 개발자들은 매일 쓸모에 대해서 갑론을박이 벌어지고 있습니다.
- TDD의 아버지 Kent Beck의 augmented coding에서는 적응할수록 시간 대비 많은 코드를 생산하고 있는 기록을 보여주었습니다.
- METR 연구에서는 숙련된 개발자들이 생산성이 높아졌다고 생각했지만, 실제로는 19% 작업이 더 오래 걸렸다는 결과를 제시했습니다.
제가 생각했을 때, AI는 가장 자유로운 도구 중 하나이고, 각자가 사용하는 방식이 너무나 달라서 내는 결과물의 차이는 더 크다고 생각합니다. 저는 숙련도가 AI의 생산성과 관련해서 가장 중요하다는 주장을 하고 싶었습니다.
이 아이디어로부터 글을 작성하려고 ChatGPT를 켜고 초안을 작성하고, 내용 피드백과 보충을 요청했습니다. 그리고, 모두 삭제했습니다.
혼란을 불러오는 AI 사용
저는 이 글을 읽으실 분들을 위해서 아주 가벼운 인사이트와 주장을 던지고 싶었던 것 같습니다. 그러나 AI는 전혀 제가 고려하고 있는 청중, 뉘앙스를 반영하지 못했습니다. 지금 제가 쓰고 있는 글보다는 훨씬 좋은 글이었지만, 저는 마음에 들지 않았습니다. 예를 들면 이런 것이죠.
바이브 코딩 / Augmented Coding 찬성 측면(GPT)
- Kent Beck 등 바이브 코딩 혹은 augmented coding을 옹호하는 개발자들은, AI가 단순 반복 작업이나 창작의 초기 단계, 또는 아이디어 구상(prototyping)에서 개발자의 사고 확장(thought augmentation) 및 창의적 흐름(flow state)에 도움을 준다고 본다.
- GitHub Copilot 관련 연구에서는 예를 들어 작업 완료(task completion) 속도가 55% 더 빠름을 보고한 바 있으며, 코드 가독성(readability), 오류 없음(error-free), 유지보수성(maintainability) 등 여러 품질 지표에서도 개선이 관찰됨.
- 또 다른 연구 “Transforming Software Development: Evaluating the Efficiency and Challenges of GitHub Copilot in Real-World Projects”에서는 문서화(code documentation)나 자동완성(autocomplete)에서 최대 50% 시간 절약, 반복 작업 및 단위 테스트(unit test)의 생성, 디버깅, 페어 프로그래밍(pair programming)에서 30~40% 절약 등의 결과가 보고됨.
- 오픈소스 프로젝트들을 대상으로 한 연구 (“The Impact of Generative AI on Collaborative Open-Source Software Development: Evidence from GitHub Copilot”)에서는 프로젝트 수준(project-level) 생산성이 6.5% 증가, 핵심 기여자(core developers)의 경우 개별 생산성(individual productivity) 및 참여도(participation) 면에서 더 큰 이익을 본 것으로 나타남. 다만 조정(integration) 비용이 증가함.
반대 및 실제 생산성 연구: 느려지는 경우들(GPT)
- METR 연구 (“Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”)에서는 숙련된 개발자(experienced open-source developers) 16명을 대상으로 실험했으며, AI 도구 사용 시 작업 시간이 약 19% 더 오래 걸림을 밝혀냄.
- 참여자들은 AI 사용 이전에 속도 개선을 약 24% 예상했고, 사용 후에는 약 20% 개선되었다고 인지하였지만, 실질적 결과는 반대로 나옴.
- 주요 원인으로는 AI 출력(suggestion)의 검토(review)/수정(editing) 과정, 맥락(context)이 맞지 않는 제안들, 코드베이스 친숙성(familiarity) 등이 있음.
- 또 다른 사례: “The Impact of Github Copilot on Developer Productivity: A Case Study”에서는 Copilot을 도입한 팀에서 Pull Request 개수가 10.6% 증가, 사이클 타임(cycle time)이 약 3.5시간 단축됨. 하지만 이 수치는 팀별·작업 유형(task type)별로 편차가 큼.
제가 쓴 글보다 훨씬 잘 쓴 부분 같지만, 독자들은 위의 전문적인 글들보다 그저 “한 50시간 정도는 공부해야 드디어 의미 있는 걸 할 수 있더라”와 같은 단순한 한 문장을 원할 수도 있다고 생각했습니다.
AI는 내가 정말 잘하는 것을 대체할 수 없다.
리서치 보고서 제작 대체, 코드 제작 대체 등등 당신들께서 하는 일을 AI에게 조금이라도 넘길 수 있지 않은가 하는 질문들이 저에게 들어옵니다. 그러나 대부분 정말 잘하고 계시는 전문 업무들에서 대체될 수 있는 것은 거의 없습니다.
다만, AI는 그동안 소홀하거나 관심을 가지지 못했던 것들을 도전할 수 있는 브릿지가 됩니다.
- 많은 뉴스 사이트로부터 하루 요약 받기
- 코드 버전 업데이트 하기(java 8 -> 17, 테스트 마이그레이션 등)
- 코드 리뷰 시에 도움을 받아 더 자세한 리뷰하기
AI는 편리한 도구가 아닌 공부의 대상이다.
제가 AI를 아무 부담 없이 사용하고 계속 시도할 수 있었던 이유는, 저는 이미 많은 분들이 알고 계신 지식들을 모르기 때문에 AI를 공부하는 것과 그 지식들을 공부하는 것이 동일한 일이었습니다. 따라서 수많은 책들과 지식을 공부하는 것보다 AI를 잘 활용하는 것이 업무 이해를 높이고 제 작업을 완료하는 데 더 좋은 도구였던 것입니다. 그러나 이미 많은 지식을 알고 있는 사람들에게는 자신만의 일하는 방법을 내려놓고 새로운 도구를 공부하고 익혀야 하는 도전입니다. 이는 결코 빠르게 결과가 나오지 않고, 많은 연구와 시도가 필요한 부분입니다.
숙련도를 공유하는 시도들
한때 지브리 사진 변환하기를 모두가 했던 시간들을 기억하시나요? 아무도 거부감 없이 이를 시도할 수 있었던 이유는 사진 한 장 업로드와 1줄의 프롬프트 “이 사진을 지브리 스타일로 변환해줘”로 모두가 같은 결과를 얻을 수 있었기 때문입니다. 자유로운 사용이 가능하기 때문에 모두가 쉽게 따라할 수 있는 best practices들이 중요하고, 다음과 같은 시도들이 이뤄지고 있습니다.
- cursor rules, 프롬프트 공유
- BMad-Method
- Spec-driven development
개발자들이 AI를 잘 사용하기 위해서는 그 전보다 훨씬 더 많은 커뮤니티 활동과 상호작용과 교육, 공유 작업들이 필요합니다.
AI 사용을 도전하시는 분들에게 보내는 메시지
저를 돌이켜보면, 상대적으로 가장 빨리 도전했기 때문에 실패할 시간도, 연구할 시간도 많았습니다. 제가 9개월 전에 신기한 사례들로 공유했던 것들은 이제 당연하게 여겨지는 사용법이 되었고, 끊임없이 새로운 요소를 제시해야만 영감이 됩니다.
사용을 도전하시는 분들도 10%의 성공을 목표로 실패하시는 시간들에 포기하지 않고, 스스로의 이해를 높여가시면서 많은 시도를 해보셨으면 좋겠습니다. 그리고 많은 공유와 대화로 같이 발전해나가면 좋겠습니다.
마무리하며
결국 제가 하고 싶었던 이야기는 간단합니다. AI는 생각보다 어렵다입니다.
Kent Beck처럼 잘 쓰는 사람도 있고, METR 연구처럼 오히려 더 오래 걸리는 경우도 있었습니다. 차이는 결국 얼마나 공부했느냐라고 생각합니다.
저처럼 원래 모르는 게 많았던 사람들에게는 새로운 공부 방법이 되었지만, 이미 잘하고 계신 분들에게는 새로운 도전입니다. 그래서 “AI 써서 생산성 올려라”라는 말이 때로는 부담스러울 수 있다고 생각해요.
하지만 천천히, 실패해도 괜찮다는 마음으로 시도해보시면 분명 새로운 가능성들을 발견하실 수 있을 거예요. 그리고 그 과정에서 많이 공유하고 대화하면서 함께 배워나가면 좋겠습니다.