긍정적 사고, 음식의 절제, 규칙적인 운동

"개발자가 대체된다"는 유행은 왜 반복될까 ?

The Recurring Cycle of 'Developer Replacement' Hype

https://alonso.network/the-recurring-cycle-of-developer-replacement-hype/

• NoCode부터 AI까지, 개발자를 대체하겠다는 기술은 반복적으로 등장하지만 실제로는 기술 변화에 따라 역할이 변형됨
• NoCode는 개발자를 없애지 않고 NoCode 전문가와 통합 기술자를 탄생시켰고, 클라우드는 DevOps 엔지니어라는 고급 직군을 만들었음
• 현재 AI 개발도구도 비슷한 길을 걷고 있으며, AI가 코드를 짜는 시대에도 시스템 아키텍처 설계 능력은 여전히 핵심임
• AI는 로컬 최적화는 잘하지만 전체 시스템 설계에는 약하며, 빠른 생성 속도로 인해 구조적 실수를 빠르게 고착화할 위험이 있음
• 개발자 대체는 결국 기술 스택 변화에 따른 진화와 고도화일 뿐, 본질적 역할은 계속 필요함

From NoCode to AI-Assisted

• 몇 년 주기로, 소프트웨어 개발자를 대체할 것이라 주장하는 새로운 기술이 등장함
• "코딩의 종말", "이제 누구나 앱을 만들 수 있음", "아이도 코딩한다" 등 과장된 기대가 포함된 유사한 제목들이 반복적으로 생성됨
• 경영진과 컨설턴트들이 이 흐름에 주목하고, 예산이 이동하는 모습이 나타남
• 하지만 현실은 항상 “대체”가 아니라 “변형”이었음
  • 복잡해진 기술을 다루는 새로운 역할과 고도화된 전문직이 탄생하고, 임금 수준도 상승하는 경향이 반복적으로 드러남
• NoCode는 전문 기술자 없이 앱을 만들 수 있다는 기대를 만들었지만, 결국 데이터 모델링, 통합, 유지보수 등 복잡한 문제가 존재했고 이를 해결할 새로운 직군이 탄생함
• 클라우드는 시스템 관리자 없이 운영 가능하다는 믿음을 줬지만 실제로는 DevOps 엔지니어라는 고급 전문성을 요구하게 되고, 임금도 상승함
• AI도 마찬가지로, “AI가 코드를 대신 작성”할 수 있을 것 같지만 실제로는 AI를 관리·오케스트레이션 할 수 있는 숙련 개발자의 중요성이 더욱 커짐

반복되는 대체 약속의 회전목마(The Endless Carousel of Replacement Promises)

NoCode/LowCode 혁신

• 직관적인 인터페이스로 모든 사용자가 앱을 만들 수 있다는 NoCode/LowCode 혁신이 등장
• 하지만 실제 현장에서는 데이터 모델 설계, 기존 시스템과 데이터베이스 통합, 예외 처리, 유지 관리 등 신규 문제가 발생함
• 이에 따라 단순 개발자가 아닌, 도메인 지식과 기술적 한계를 동시에 이해하는 NoCode 전문가가 필요해짐
• 이들은 기존 개발자보다 더 높은 연봉을 받음

클라우드 혁명

• 클라우드로 이전하면 시스템 관리자가 필요 없어질 거라는 기대가 컸음
• 하지만 클라우드 관리 전문성과 복잡성이 오히려 증가함
• 기존 시스템 관리자는 DevOps 엔지니어로 변신하여 더 높은 급여를 받고, 인프라 자동화, 배포 파이프라인, 분산 시스템 관리 등 업무 수준이 고도화됨
• 업무는 사라진 것이 아니라, 새로운 작업 형태로 진화함
• 마이크로서비스 전환에서도 복잡성이 커지고, 결국 근본적으로 시스템을 관리하는 전문가의 역할이 중요함이 드러났음

오프쇼어(Offshore) 개발 바람

• 해외 아웃소싱으로 비용을 절감할 수 있다는 믿음이 생겨났지만, 커뮤니케이션 문제, 품질 저하, 도메인 지식 부족으로 어려움 발생
• 결국 분산 팀 구조조, 명확한 소유권, 강력한 아키텍처 등으로 전략이 변화하며, 초기 기대했던 것보다 전체 비용이 증가하는 결과를 낳음

AI 코딩 어시스턴트 혁명

• 이제는 AI가 코드를 자동으로 생성한다는 약속이 화두임
• 초기 현실에서는, AI가 만들어주는 코드는 종종 미묘한 오류와 일관성 문제를 내포함
• 시니어 엔지니어가 AI 결과를 검토·수정하는 데 많은 시간을 쓰며, 경험 있는 개발자일수록 훨씬 더 많은 가치를 창출함
• AI 보조만으로 구축된 시스템은 체계적인 아키텍처가 부재한 경우가 많음
• 즉, 기술이 기술자를 대체하는 것이 아니라, 더 높은 추상화 계층으로 기술자의 전문성을 끌어올리는 것임

이번 사이클이 특별한 이유

• 사람들이 간과하는 핵심: 코드는 자산이 아니라 부채
• 빠르고 쉽게 코드를 만들수록, 유지보수와 보안, 리팩터링의 부담도 커짐
• AI는 함수 단위 최적화는 가능하지만 전체 시스템 설계 능력은 부족
• 구현 속도가 빨라질수록 구조적 실수를 빠르게 고착화할 위험 존재
• 결국, AI 시대에도 진정한 자산은 시스템 아키텍처 설계 능력이며, 이는 대체가 아닌 강화의 대상임

• "AI가 개발자를 대체한다"는 주장은 다음의 근본적 오해에서 비롯됨
  • 코드는 자산이 아니라 부채라는 사실
  • 코드는 지속적인 유지·검증·보안 관리·교체가 필요하며, 그 라인 수만큼 부채가 증가함
• AI가 코드를 빠르게 만들어준다는 것은, 부채를 그만큼 빠르게 발생시킨다는 것에 불과함
• 즉, AI는 로컬 최적화(함수, 부분 기능)는 잘하지만, 글로벌 설계·아키텍처 결정은 부족함
• 구현 속도가 빨라질수록, 잘못된 설계가 시스템 전체에 '굳어지는' 위험성이 커짐
• 일회성 단기 사이트 제작에는 문제가 없으나, 장기적으로 발전하는 시스템에는 치명적임

• 기술 혁신의 패턴은 변함없이 유지됨
  • 시스템 관리자는 DevOps 엔지니어가 되고, 백엔드 개발자는 클라우드 아키텍트가 됨
• 하지만 AI는 모든 것을 가속화함. 살아남고 발전하는 기술은 코드 작성이 아님
• 그것은 바로 시스템을 설계하는 것(Architecting systems). AI가 할 수 없는 유일한 일이 바로 그것임

생성형 AI 골드러시 속에서 초기 사용 사례로 각광받는 것 중 하나는 코딩 어시스턴트였다. 그러나 기대했던 생산성 향상 효과는 기대에 미치지 못하고 있다는 보고서가 등장해 눈길을 끈다.

많은 개발자가 AI 코딩 어시스턴트가 생산성을 높여준다고 말하지만, 최근의 한 연구에 따르면 생산성을 측정한 결과 큰 이득을 얻지 못했다. 코딩 및 협업 데이터에서 인사이트를 제공하는 업레벨(Uplevel)은 해당 연구 보고서에서 깃허브 코파일럿을 사용할 때 버그도 41% 더 많이 발생했다고 전했다. 

이 연구는 코드를 리포지토리에 병합하는 데 걸리는 시간인 PR(풀 리퀘스트) 주기와 병합된 풀 리퀘스트의 수인 PR 처리량을 측정해 효과를 살펴봤다. 그 결과 코파일럿 사용 개발자에게는 유의미한 개선 사항이 발견되지 않았다. 업레벨은 고객 기업들이 생성한 데이터를 사용하여 약 800명의 개발자가 3개월 동안 깃허브 코파일럿을 사용한 결과와 도입 전 3개월 동안의 결과물을 비교했다고 설명했다.
 

번아웃 측정
업레벨 연구는 생산성과 더불어 개발자의 번아웃 요인도 살펴봤다. 그 결과 깃허브 코파일럿이 번아웃에도 도움이 되지 않는다는 사실을 드러났다. 코딩 도구를 사용한 대조군과 테스트군 모두 표준 시간 외의 작업 시간이 감소했지만, 개발자가 코파일럿을 사용하지 않았을 때 오히려 더 많이 감소했다.

업레벨의 제품 관리자이자 데이터 분석가인 매트 호프만은 AI 코딩 어시스턴트가 보편화되면서 생산성이 크게 향상될 것이라는 주장에 대한 호기심에서 이 연구를 진행하게 되었다고 전했다. 지난 8월에 발표된 깃허브 설문조사에 따르면 소프트웨어 엔지니어, 개발자, 프로그래머의 97%가 AI 코딩 어시스턴트를 사용한다고 답했다.

호프만은 “생산성에 큰 도움이 된다는 주장을 담은 여러 연구들이 있었다. 어떤 사람들은 '그거 알아? 나는 앞으로 [코드] 리뷰어가 되어야 할 것 같아"라고 말하기도 했다”라고 전했다.

한편 깃허브 코파일럿 이번 업레벨의 연구에 대해 직접적으로 언급하지 않았다. 단 개발자가 코딩 어시스턴트를 사용하여 코드를 55% 더 빠르게 작성할 수 있었다는 최근의 연구를 언급했다. 

호프만에 따르면 업레벨은 당초 생산성 향상을 기대하며 연구에 착수했다. 그는 “우리 팀의 가설은 PR 주기 단축 효과에 대한 긍정이었다. 코드를 더 많이 작성할 수 있을 것이라고 생각했고, 실제로 코드를 배포하기 전에 이러한 생성형 AI 도구를 사용하여 코드를 검토하기 때문에 결함률이 낮아질 것이라고 생각했다”라고 말했다.

호프만은 PR 주기 시간과 PR 처리량 외에도 개발자의 생산성을 측정하는 방법이 더 있을 수 있다는 점을 인정한다면서도, 업레벨은 이들 메트릭이 개발자의 성과를 측정하는 확실한 척도로 보고 있다고 말했다.

앞으론 달라질 수도
업레벨은 이번 연구 결과에도 불구하고 코딩 어시스턴트가 빠르게 발전하고 있다는 점을 감안할 때 코딩 어시스턴트 사용을 중단하라고 제안하지는 않는다고 밝혔다. 호프만은 “코드 생성보다 코드 리뷰에 투입하는 시간이 늘고 있다. 코드가 제대로 작동하고 있다고 착각하기 쉽다. 무엇이 생성되는지, 예상한 대로 작동하는지를 면밀히 주시해야 한다”라고 말했다.

현장의 개발 팀들은 엇갈린 결과를 보고하고 있다. 맞춤형 소프트웨어 개발 회사인 게트소프트 USA(Gehtsoft USA)의 개발자들은 LLM(대규모 언어 모델) AI를 기반으로 한 코딩 어시스턴트를 통해 생산성이 크게 향상되지 않았다고 이 회사의 CEO인 이반 게트는 전했다. 게트소프트는 샌드박스 환경에서 코딩 어시스턴트를 테스트해 왔지만 아직 고객 프로젝트에 사용한 적은 없다.
 

“AI가 생성한 코드를 이해하고 디버깅하는 것이 점점 더 어려워지고 있다. 문제 해결에 투입되는 리소스가 크기 때문에 코드를 수정하는 것보다 처음부터 다시 작성하는 것이 더 쉬운 편이다.”
-이반 게크트, Gehtsoft CEO

게트 CEO는 “생산성 향상을 위해 LLM을 사용하려면 LLM이 실제 사람에 필적하는 능력을 갖춰야 하고, 실제 사용자도 LLM을 효율적으로 사용하는 방법을 알아야 한다. LLM은 비판적 사고, 자기 인식, 사고 능력이 없다”라고 말했다.

게트는 몇 줄의 코드를 작성하는 것과 본격적인 소프트웨어 개발에는 차이가 있다고 지적했다. 코딩은 문장을 쓰는 것과 같고, 개발은 소설을 쓰는 것과 같다고 그는 표현했다. “소프트웨어 개발은 요구 사항을 이해하고, 시스템을 설계하고, 한계와 제약을 고려하는 등 90%는 두뇌의 작동이다. 모든 지식과 이해를 실제 코드로 변환하는 것은 더 간단한 부분이다”라고 게트는 말했다.

업레벨 연구와 마찬가지로 AI 비서가 코드에 오류를 발생시키는 경우도 발견했다고 그는 전했다. AI가 생성한 코드가 반복적으로 재활용되면서 일관성 문제로 이어진다는 것이다. 개발자마다 다른 프롬프트를 사용함에 따라 나타나는 문제다. “AI가 생성한 코드를 이해하고 디버깅하는 것이 점점 더 어려워지고 있다. 문제 해결에 투입되는 리소스가 크기 때문에 코드를 수정하는 것보다 처음부터 다시 작성하는 것이 더 쉬운 편이다"라고 그는 말했다.

실효 체감
클라우드 서비스 제공업체 이노베이티브 솔루션(ovative Solutions)에서는 다르다. 이 회사의 CTO인 트래비스 렐은 클로드 데브 및 깃허브 코파일럿과 같은 코딩 어시스턴트를 사용하여 상당한 생산성 향상을 경험하고 있다고 전했다. 또한 자체 개발한 앤트로픽 통합을 사용하여 풀 리퀘스트를 모니터링하고 코드 품질을 검증하고 있다는 설명이다.

렐은 개발자 티켓의 완료 속도, 고객 결과물의 처리 시간, 코드 내 버그 수로 측정한 티켓의 품질을 기준으로 개발자 생산성이 2~3배 향상되는 것을 확인했다며, 과거 30일 정도 걸렸던 고객 프로젝트를 코딩 어시스턴트를 사용하여 24시간 만에 완료한 사례도 최근 있었다고 덧붙였다. 

하지만 코딩 어시스턴트가 전체 개발팀을 대체할 것이라는 주장 등 코딩 어시스턴트에 대한 일부 과대광고는 비현실적이라고 렐은 강조했다. 그저 코딩 어시스턴트는 코드의 일부를 재작업하여 코드를 빠르게 대체하거나 코드 경로를 최적화하는 데 사용되기에 적합하다고 그는 덧붙였다.

“코딩 어시스턴트가 처음부터 전체 코드를 올바르게 작성하지는 못한다. 코딩 어시스턴트에 대한 기대치를 낮춰야 한다. 단코딩 어시스턴트를 올바르게 사용하면 개발자의 코딩 속도를 두세 배까지 높일 수 있다”라고 그는 말했다.

https://www.ciokorea.com/news/351488

책 읽어주는 딥러닝: 배우 유인나가 해리포터를 읽어준다면 DEVIEW 2017

https://deview.kr/2017/schedule/192

코드 : https://github.com/devsisters/multi-speaker-tacotron-tensorflow 

음성 합성 데모 : http://carpedm20.github.io/tacotron 

발표 소개 : https://deview.kr/2017/schedule/182 

...

좋은 개발자 되기

* 프로그래머가 되는 법

* 읽기 쉬운 코드 작성법

.

.