# 소프트웨어 개발의 미래는 소프트웨어 개발자들이다 > Clean Markdown view of GeekNews topic #25448. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25448](https://news.hada.io/topic?id=25448) - GeekNews Markdown: [https://news.hada.io/topic/25448.md](https://news.hada.io/topic/25448.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-30T23:33:10+09:00 - Updated: 2025-12-30T23:33:10+09:00 - Original source: [codemanship.wordpress.com](https://codemanship.wordpress.com/2025/11/25/the-future-of-software-development-is-software-developers/) - Points: 16 - Comments: 1 ## Summary **“프로그래머의 종말” 예언은 여전히 틀렸습니다.** 수십 년간 자동화 기술이 등장할 때마다 개발자의 필요성이 사라질 것이라 했지만, 실제로는 더 많은 소프트웨어와 더 많은 개발자가 생겨났습니다. **LLM 기반 도구**는 과거의 4GL이나 No-Code보다 신뢰성과 유지보수성이 떨어지며, 인간의 논리적 사고를 대체하지 못합니다. 결국 프로그래밍의 본질은 **모호한 인간 사고를 정밀한 논리로 바꾸는 능력**에 있고, 이 영역에서 **숙련된 개발자의 가치는 오히려 커지고 있습니다.** ## Topic Body - 수십 년간 반복된 **“프로그래머의 종말” 예언**은 매번 틀렸으며, 기술 발전은 오히려 더 많은 **개발자와 프로그램의 증가**로 이어져 왔음 - **WYSIWYG, 4GL, No-Code, LLM** 등 다양한 자동화 기술이 등장했지만, 실제로는 개발자의 필요성을 줄이지 못했음 - **LLM 기반 도구**는 과거 기술보다 신뢰성과 유지보수성이 떨어지며, 대부분의 팀에서 **생산성 저하와 품질 악화**를 초래함 - 프로그래밍의 본질적 어려움은 코드 작성이 아니라 **인간의 모호한 사고를 논리적으로 변환하는 능력**에 있으며, 이는 여전히 인간의 영역임 - 따라서 **AI가 개발자를 대체할 가능성은 낮고**, 오히려 숙련된 개발자에 대한 수요가 더 커질 전망임 --- ### 반복되는 “프로그래머의 종말” 주기 - 지난 43년간 **Visual Basic, Delphi, Executable UML, No-Code, Low-Code** 등 다양한 기술이 프로그래머의 필요성을 없앨 것이라 주장되어 왔음 - 1970~80년대에는 **4GL, 5GL**, 그 이전에는 **Fortran, COBOL**, 더 거슬러 올라가면 **컴파일러 A-0**조차 같은 예언을 받았음 - 초기 전자식 컴퓨터 **COLOSSUS**는 물리적 배선으로 프로그래밍되었으며, 이후 세대가 “진짜 프로그래머가 아니다”라 조롱받기도 했음 - 그러나 결과적으로는 **프로그래머 수가 줄지 않고 오히려 증가**, 이는 **Jevons Paradox**의 대표적 사례로 언급됨 ### LLM과 과거 기술의 차이 - 과거 기술은 실제로 **소프트웨어 생산 속도를 높이고 신뢰성도 확보**했지만, **LLM은 대부분의 팀에서 반대 효과**를 보임 - LLM은 코드 품질을 낮추고 유지보수를 어렵게 만들어 **“LOSE-LOSE” 상황**을 초래함 - 동일한 프롬프트로도 동일한 결과를 내지 못하며, 생성된 코드에는 **인간 개발자의 검증과 수정**이 필수적임 - **AI가 개발자를 대체한다는 증거는 없음**, 최근 인력 감축은 **팬데믹 시기 과잉 채용, 금리 상승, 데이터센터 투자 집중** 등 경제 요인 때문임 ### 프로그래밍의 본질적 난제 - 프로그래밍의 핵심은 **인간의 모호한 사고를 논리적으로 정밀한 계산 사고로 전환**하는 과정임 - 이는 천공카드 시절부터 COBOL, Visual Basic, Python에 이르기까지 변하지 않은 어려움임 - **자연어는 본질적으로 모호하고 비정확**하기 때문에, **영어나 프랑스어로 프로그래밍하는 시대는 오지 않을 것**이라 **Dijkstra**의 예언을 인용함 - 이러한 사고방식을 배우는 것은 가능하지만, **모두가 즐기거나 잘할 수 있는 일은 아니며**, 숙련된 인력의 공급은 항상 부족함 ### AI의 한계와 지속 가능성 - **AGI(범용 인공지능)** 은 여전히 멀리 있으며, 인간 수준의 **이해·추론·학습 능력**이 필요함 - **대규모 LLM**은 막대한 비용과 손실을 초래하고 있어 **장기적으로 지속 가능하지 않음** - 시간이 지나면 모델이 학습한 **언어·라이브러리 버전의 제약**으로 인해 활용성이 떨어질 가능성 있음 - 이러한 이유로 **초대형 LLM은 ‘Apollo 달 탐사’처럼 비경제적 실험으로 남을 수 있음** ### 미래의 개발 환경 전망 - 가까운 미래의 소프트웨어 개발은 **소규모 언어 모델 기반의 보조 도구**가 프로토타입 생성이나 코드 자동완성 등 **보조 역할**을 수행하는 형태로 예상됨 - 그러나 **중요한 결정과 품질 확보는 인간 개발자가 주도**하며, Jevons의 법칙에 따라 **개발자 수요는 오히려 증가**할 가능성 있음 - 기업은 **지금부터 숙련된 개발자 채용과 교육에 투자**해야 하며, 이는 **AI 유무와 관계없이 생산성과 신뢰성을 높이는 핵심 전략**임 ## Comments ### Comment 48480 - Author: neo - Created: 2025-12-30T23:33:10+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46424233) - 여러 해 동안 **agent-LLM**을 다뤄본 결과, 실제 프로그래밍에는 전혀 쓸모가 없었음 복잡한 저수준 라이브러리 문제나 **비직관적인 버그**를 해결하지 못하고, 추상화된 계층의 논리를 이해하지 못함 단, 단순한 웹사이트 구축처럼 이미 수천 번 반복된 **보일러플레이트 작업**에는 탁월했음. 이런 단순 작업에서는 하루치 시간을 절약했음 하지만 LLM이 단순 작업 영역을 넘어 복잡한 문제를 이해하는 단계로 갈 가능성은 보이지 않음 - “진짜 프로그래밍”의 정의가 다르다고 생각함 저수준 코딩이나 레거시 버그 해결만이 프로그래밍은 아님. LLM이 해결한 웹사이트 구축도 분명 프로그래밍의 한 형태임 - 나도 비슷한 경력을 가지고 있지만, LLM이 **무용지물**이라는 주장에는 동의하지 않음 대규모 코드베이스 이해, 기능 브레인스토밍, 구현상의 **갭 파악** 등에서 엄청난 시간을 절약했음 완전한 대체는 불가능하지만, 엔지니어의 강력한 도구로서 가치는 분명함 - 아마도 당신은 매우 저수준의 일을 하는 듯함 하지만 대부분의 개발자는 프레임워크와 라이브러리를 **조합**하는 일을 함. 전기차가 대형 화물 운송에는 부적합하지만 일반 운전자에게는 충분히 유용한 것처럼, LLM도 그런 위치에 있음 - 최근 **Codex 5.2**가 CTF 대회에서 암호 문제를 풀었다는 이야기를 들었음 몇 달 전까지만 해도 동의했겠지만, 이제는 기술이 그 경계를 넘은 듯함 - 내 경험은 완전히 다름. 사용하는 **언어와 아키텍처**에 따라 차이가 큼 나는 ERP 분야에서 일하는데, 에이전트들이 생산성을 비약적으로 높여줌 구독료가 월 500달러로 올라도 계속 쓸 만큼 가치가 있음 - AI가 프로그래머의 필요성을 줄인다는 예측이 현실이 될까 두려움 이미 AI가 **설계, 코드 리뷰, 버그 탐지, 프로젝트 계획** 등에서 나보다 낫다고 느낌 나는 단지 그 과정을 지휘하는 **지휘자** 역할만 하는 듯함 예전엔 20명이 하던 일을 혼자 하는 기분이라 무섭기도 함 - LLM이 인간에게 **학습된 무기력감**을 심는다고 생각함 인간만이 장기 계획과 의사결정을 잘함. 우리는 **걱정, 자부심, 감정**을 가지며, 그것이 진짜 강점임 AI는 단지 단어의 가방일 뿐, 사랑도 지속성도 없음 - AI가 그런 수준의 일을 잘한다는 건 사실이 아님 기본적인 역량만 있어도 인간이 훨씬 낫다고 생각함 - 이건 광고처럼 들림. 실제로는 AI가 복잡한 문제에서 **엉터리 결과**를 내고, 테스트도 부실함 20명이 하던 일을 혼자 한다면, 그 20명은 원래 생산성이 낮았을 것임 - 나는 11년간 **미슐랭 레스토랑 셰프**로 일했음 설거지 기계를 계속 돌리는 게 핵심이었는데, AI 코딩 에이전트도 그 기계와 같음 나는 프롬프트를 넣고, 결과를 검수하고 정리하는 역할을 함. 결국 인간의 손이 여전히 필요함 - 자동차가 인간보다 빠르고 오래가지만, 여전히 **운전자는 필요함** AI 덕분에 20명이 하던 일을 한 명이 한다면, 그것은 **생산성 향상**이며 더 큰 부를 창출함 - 지금의 LLM 열풍은 대규모 **Eliza 효과**라고 생각함 관련 개념은 [ELIZA effect](https://en.wikipedia.org/wiki/ELIZA_effect)와 Weizenbaum의 저서 [*Computer Power and Human Reason*](https://en.wikipedia.org/wiki/Computer_Power_and_Human_Reaso...)에서 볼 수 있음 - 나도 Eliza 효과가 강하다고 느낌 LLM은 **영향력 있는 사람들(CEO, 투자자)** 을 감동시키도록 진화한 듯함 실제 전문가 수준이 될 필요는 없고, 단지 “충분히 괜찮아 보이는” 수준이면 채택됨 - 미국 개발자에게 진짜 위협은 **AI가 아니라 아웃소싱**임 나는 이민자로, 뉴욕의 금융회사에서 일함. 직원의 95%가 외국 출신이고, 신규 채용도 대부분 **H1B 비자** 소지자임 - 맞음, 이런 흐름은 이미 수십 년 전부터 계속되어 왔음 - **Dijkstra**가 50년 전 이미 말했듯, 인간 언어로 프로그래밍하는 일은 불가능함 자연어는 본질적으로 **모호하고 비정확**하기 때문임 “프롬프트가 새로운 소스코드다”라고 주장하는 사람들은 마치 **Excel로 앱을 만드는 사람들**과 같음 - “Blood in the Machine”이라는 책을 읽고 **러다이트 운동**의 역사를 알게 되었음 산업혁명 전에는 가족 단위로 옷을 만들었지만, 기계가 등장하면서 **수공업 산업이 붕괴**됨 지금 개발자들도 같은 길을 걷고 있는 듯함 - 러다이트는 **직조기**에 대한 반발이었음. 옷을 만드는 과정 중 가장 시간이 많이 걸리는 부분이었음 하지만 소프트웨어 개발에서 코딩은 전체 과정의 일부일 뿐임 - 자동차 산업 비유가 더 적절함 **Toyota**가 장인들을 대체했듯, LLM이 유지보수까지 자동화한다면 개발자도 같은 운명을 맞을 것임 - 하지만 의류 산업은 여전히 존재함 값싼 옷이 넘쳐나도 **디자이너와 고급 브랜드**는 남아 있음. 소프트웨어도 그렇게 변할 것임 - 과거 **Visual Basic**과 **Delphi** 같은 WYSIWYG 도구가 프로그래머를 대체할 거라 했지만, 결국 아니었음 AI도 비슷함. **취약하고 불안정한 코드**를 생성할 수는 있지만, 여전히 진짜 프로그래머가 안정화해야 함 - 1980년대에도 정부와 업계가 **4GL**에 막대한 투자를 했지만, 결국 실패했음 일본의 **MITI Fourth Generation Project**도 비슷했음. 당시의 “소프트웨어 위기”는 지금의 AI 열풍과 닮아 있음 - 이 글은 **AI 찬양 기사**처럼 느껴짐. 마지막에 교육 서비스를 홍보하는 부분이 특히 그랬음 그래도 실제로 내 생산성이 높아진 건 사실이라, 결국 **개발자 수요 감소**는 불가피할 듯함 - 나도 같은 인상을 받음. 저자는 뛰어난 교사지만, **새로운 통찰**은 없었음 오히려 여러 의견을 짜깁기한 **LLM이 쓴 글**처럼 느껴졌음 - 석탄 기관이 효율적일수록 석탄 수요가 늘었던 것처럼, **Jevons의 역설**이 소프트웨어에도 적용될 수 있음 개발 비용이 절반으로 줄면 더 많은 분야에서 소프트웨어를 활용하게 될 것임 [Jevons paradox](https://en.wikipedia.org/wiki/Jevons_paradox) 참고 - 항공 안전에서 말하는 **Swiss cheese 모델**처럼, LLM도 소프트웨어 개발의 한 층으로 볼 수 있음 각 층이 완벽하지 않아도 서로의 **결함을 보완**해 전체 품질을 높이는 개념임 - 흥미로운 비유지만, 아직 우리는 LLM을 그런 **보조 레이어**로 활용하지 못하고 있음 코드 검증이나 테스트 분석에 지능적으로 적용하는 단계는 아님 하지만 언젠가 제대로 된 사용 사례가 나올 것이라 확신함 - LLM은 **Kraft Singles** 같은 가짜 치즈에 가까움 안전을 보장하려면 결국 사람이 전체를 검수해야 함 - 항공 산업의 **안전 패러다임**을 LLM에 적용하는 건 무리임 항공 소프트웨어의 신뢰성과 LLM의 불안정성은 비교조차 불가능함