# 10년마다 되풀이되는 개발자 대체의 꿈 > Clean Markdown view of GeekNews topic #25916. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25916](https://news.hada.io/topic?id=25916) - GeekNews Markdown: [https://news.hada.io/topic/25916.md](https://news.hada.io/topic/25916.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-18T11:32:49+09:00 - Updated: 2026-01-18T11:32:49+09:00 - Original source: [caimito.net](https://www.caimito.net/en/blog/2025/12/07/the-recurring-dream-of-replacing-developers.html) - Points: 30 - Comments: 5 ## Summary 소프트웨어 개발을 단순화하려는 시도는 **COBOL**에서 **AI 코드 도우미**까지 50년 넘게 반복되어 왔습니다. 그러나 생산성 향상에도 불구하고, 복잡한 문제를 정의하고 판단하는 일은 여전히 인간의 몫으로 남아 있습니다. AI는 개발자의 손을 빠르게 하지만, **비즈니스 맥락을 이해하는 사고 과정**을 대신하지는 못합니다. 결국 핵심은 도구가 아니라, 복잡성을 다루는 사람의 사고력에 대한 투자입니다. ## Topic Body - 지난 50여 년간 **소프트웨어 개발을 단순화해 개발자 의존을 줄이려는 시도**가 반복되어 왔음 - 1960년대 **COBOL**에서 시작해 **CASE 도구**, **Visual Basic**, **로우코드·노코드**, 그리고 최근의 **AI 코드 도우미**까지 같은 패턴이 이어짐 - 각 기술은 생산성을 높였지만, **복잡성을 다루는 사고 과정**은 여전히 사람의 몫으로 남음 - **AI**는 개발자의 역량을 증폭시키지만, **비즈니스 문제 이해와 판단력**을 대체하지는 못함 - 이 반복된 시도는 **도구의 한계가 아닌 문제의 복잡성**을 드러내며, 결국 **사람의 사고 능력 투자**가 핵심임 --- ### 반복되는 패턴의 시작 - 매 10년마다 “이번에는 개발이 쉬워질 것”이라는 약속이 등장 - 1969년 아폴로 프로그램 이후 소프트웨어가 핵심 기술로 부상 - 그러나 개발에는 **전문 지식, 집중력, 시간 투자**가 필요함이 드러남 - 이때부터 “개발을 단순화해 인력을 줄이자”는 **지속적 꿈**이 시작됨 ### COBOL: 비즈니스 담당자가 직접 코딩할 수 있을 것이라는 믿음 - COBOL은 **Common Business-Oriented Language**라는 이름처럼, **비즈니스 담당자가 영어 문장처럼 코드를 작성**할 수 있도록 설계 - 그러나 실제로는 **논리·데이터 구조·시스템 설계의 복잡성**이 여전해, 결국 **전문 COBOL 개발자 계층**이 새로 형성됨 - “누구나 코딩할 수 있다”는 비전은 실현되지 못함 ### 1980년대: CASE 도구의 자동 생성 약속 - **CASE(Computer-Aided Software Engineering)** 도구는 **다이어그램으로 코드를 자동 생성**한다는 약속으로 등장 - 기업들은 생산성 10배 향상을 기대하며 대규모 투자 진행 - 그러나 생성된 코드는 **성능 문제, 유지보수 어려움, 모델 불일치**로 실패 - **논리적 복잡성 이해가 여전히 필요**했기 때문에, 문제는 해결되지 않음 ### 1990년대: Visual Basic과 Delphi의 접근 - **드래그 앤 드롭 방식**으로 UI를 쉽게 만들 수 있게 하여 개발 진입 장벽을 낮춤 - 단순한 애플리케이션은 가능했지만, **통합·보안·성능·유지보수**가 필요한 복잡한 시스템에는 여전히 숙련된 개발자가 필요 - 결과적으로 **개발자 수요는 줄지 않고 오히려 확대**됨 ### 2000년대 이후: 웹 프레임워크, 로우코드, 노코드 - **Ruby on Rails**는 “설정보다 관례”를, **로우코드·노코드 플랫폼**은 “코드 없는 개발”을 내세움 - 특정 영역에서는 속도 향상과 참여 확대를 달성했지만, **전문 개발자의 필요성은 지속적으로 증가** - 반복되는 질문: “왜 이 패턴은 계속되는가?” ### 복잡성의 본질 - 소프트웨어는 언뜻 단순해 보이지만, 실제로는 **세부 상황과 예외 처리**에서 복잡성이 폭발 - 예: 재고 예약 충돌, 결제 실패, 이메일 서비스 중단 등 - 이러한 세부 판단이 바로 **개발 행위의 본질**이며, 어떤 도구도 이를 제거할 수 없음 ### AI 시대의 새로운 장 - **AI 코딩 도우미**는 자연어로 코드를 생성하고, 설명·디버깅·개선 제안을 수행 - 이는 **실질적 진전**이지만, 여전히 **문제 정의·보안·통합·유지보수 판단**은 인간의 역할 - AI는 **개발자의 생산성을 증폭**시키지만, **판단력과 맥락 이해**는 대체하지 못함 ### 여전히 부족한 개발 역량 - 기술은 비약적으로 발전했지만, **소프트웨어 수요가 공급을 초과** - 기업들은 “더 빠르게, 더 많이 만들 방법”을 찾으며 **개발 단순화 도구**에 기대를 품음 - 그러나 병목은 **타이핑 속도나 문법이 아니라 복잡성 사고 능력**에 있음 ### 리더가 던져야 할 질문 - “이 도구가 개발자를 대체할까?”가 아니라 - “복잡한 문제 해결에 도움이 되는가?” - “반복 작업을 줄여 창의적 문제에 집중하게 하는가?” - “새로운 기술 습득이 필요한가?” - 이러한 질문은 **도구의 한계와 인간 사고의 불가피성**을 인식하게 함 ### 50년의 교훈: 문제는 기계적이 아니라 지적임 - COBOL은 문법을 단순화했고, CASE는 타이핑을 없앴으며, AI는 함수 전체를 생성하지만 **본질적 어려움은 여전** - **소프트웨어 개발은 ‘생각을 구체화하는 행위’** 이며, 이는 도구로 대체 불가 - 건축 설계나 의학 진단처럼, **사고 과정 자체가 핵심 가치** ### 앞으로의 방향 - 새로운 도구는 계속 등장하겠지만, **사람의 사고력에 대한 투자**가 가장 중요 - **AI·로우코드·새 프레임워크**를 실험하되, **복잡성 이해 능력**을 조직의 핵심 역량으로 삼아야 함 - 아폴로 프로그램처럼, **도구보다 사고의 정밀함**이 성공의 결정 요인 ### 꿈이 계속되는 이유 - “개발자를 대체하려는 꿈”은 실패가 아니라 **도구 혁신을 자극하는 낙관주의** - 각 시도는 완전한 대체에는 실패했지만, **새로운 세대의 유용한 도구**를 만들어냄 - COBOL은 비즈니스 시스템 개발을 확산 - CASE는 시각적 모델링 발전 - Visual Basic은 개발 접근성 확대 - AI는 개발 방식의 변화를 촉진 - 결국 제약은 **도구가 아니라 우리가 해결하려는 문제의 복잡성**에 있음 - 새로운 도구를 거부할 필요는 없으며, **현실적 기대와 인간 판단의 중요성**을 인식해야 함 ## Comments ### Comment 49410 - Author: neo - Created: 2026-01-18T11:32:49+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46658345) - 이번 **AI 혁신의 물결**을 보면, 코딩의 많은 부분이 본질적 복잡성이 아니라 **우연적 복잡성**임을 깨닫게 됨 인간에게 개념적인 작업이 AI에게는 절차적인 작업으로 바뀌는 현상임 예를 들어, 예전에는 Java의 `public static void main(String[] args)`를 쓰기 위해 여러 개념을 배워야 했지만, AI에게는 “클래스의 진입 메서드를 작성하라”는 프롬프트만 주면 거의 확정적으로 그 코드를 생성함 인간에게 어려운 절차적 작업이 AI에게는 쉬운 반면, 사회는 이런 절차적 노동을 중심으로 구조화되어 있어서 혁신이 확산되면 **누군가는 상승하고 누군가는 고통받게 됨** - 올바른 질문을 던지는 데 필요한 **경험과 전문성**을 과소평가하고 있다고 생각함 - “**No-code가 개발자를 대체한다**”는 주장은 매번 반복되지만, 실제로는 개발자 일자리를 더 많이 만들어왔음 COBOL, VB, Squarespace, 그리고 이제 AI까지 — 도구가 진입 장벽을 낮추면 더 많은 사람이 무언가를 만들려 하고, 결국 한계에 부딪히면 진짜 개발자가 필요해짐 단순 반복 작업은 사라지지만, **무엇을 만들지 정의하고 디버깅하는 일**은 여전히 남음 - 나도 그 확장이 계속되길 바라지만, 결국 **새로운 수요**가 생기느냐에 달려 있음 AI가 복잡한 프로젝트를 스스로 코딩할 수 있다면, 인간이 세부사항에 신경 쓰지 않아도 되므로 개발자 수요가 줄 수 있음 과거에는 인터넷, 클라우드, 모바일, 머신러닝 같은 대규모 트렌드가 있었지만, 앞으로도 그런 **‘큰 문제’** 가 계속 생길지는 확신이 없음 - 이건 **Jevons Paradox**의 고전적 사례임 — 무언가가 싸지면 시장이 오히려 커짐 - 물론 이번에는 다를 수도 있음. AI가 진짜 약속한 대로 된다면, 개발자 수가 줄 가능성도 있음 - 농기계가 농부를 더 효율적으로 만들었지만, 지금은 오히려 더 많은 농부가 존재함 - “개발자 수가 줄지 않는다”는 주장은 너무 단정적임. **AI가 디버깅과 요구 해석까지** 할 수 있게 되면 상황이 달라질 수 있음 - 지난 20년간 시스템 관리 분야에서도 같은 패턴을 봐왔음 “더 높은 추상화가 전문가의 일을 민주화한다”는 약속은 반복되지만, 실제로는 **비용이 큰 재발명**이 일어남 Kubernetes 같은 도구는 복잡성을 감췄다고 하지만, 결국 개발자들이 기본 개념을 모른 채 같은 문제를 더 비싼 방식으로 다시 배우고 있음 Excel이 대표적 예시임 — 끔찍한 오류를 양산했지만, **접근성** 덕분에 성공했음 결국 우리는 “Excel의 접근성과 엔지니어링의 신뢰성”을 동시에 원하지만, 둘 다 가질 수 없음 - 그렇다면 **비결정적 소프트웨어**를 쓸 때 보험료나 보상 정책이 바뀌게 될까? - Kubernetes가 노동을 줄이지 못했다면, 대기업 95%가 바보라는 말이 됨 실제로는 규모가 커지면서 **업무 복잡도**가 상향 이동한 것임 - 모든 추상화는 **누수되는 추상화**임. C조차도 컴파일러마다 결과가 달라짐 - 이런 패턴이 반복되는 이유는 **시장 인센티브** 때문임 기업들은 AI를 만능 해결사로 포장해야 주가가 오르기 때문에, 실제 성능보다 **믿음을 파는 구조**가 됨 결국 현실이 드러나면 시장은 혼란스러워질 것임 - 시장은 만유인력이 아님. **정치 질서가 있어야 시장이 존재**함 - 정말 제품이 약속한 대로 작동했다면, “회의론자 비판”에 집중하지 않고 개발에 몰두했을 것임 - 사실 개발자 수를 줄일 수도 있었음 기업이 더 **선별적 채용과 교육 투자**를 했다면 말임 하지만 현실은 반대였고, 웹 프레임워크는 생산성 향상보다 **교육비 절감과 인력 풀 확대**를 위해 만들어졌음 - 동의하지 않음. 좋은 프레임워크는 **유지보수성과 생산성**을 높여줌 - 중간 관리자와 경영진은 기술 부서를 **비용 센터**로만 봄 그래서 AI를 모든 보도자료에 언급하며 인건비 절감을 외침 실제로는 AI 때문이 아니라 **오프쇼어 인력 교체**로 비용을 줄이는 중임 남은 온쇼어 팀은 더 많은 일을 떠안으며 생산성을 높이고 있음 - 하지만 오프쇼어 지역에서도 **해고가 동일하게 발생**함 인건비 절감이 아니라 전반적인 **투자 위축**이 원인임 결국 AI가 데이터센터 투자로 자본을 흡수하면서 일자리를 줄이는 셈임 - “세일즈는 제품 없이는 존재할 수 없다”는 주장에는 역사적 반례가 많음 - AI의 목적은 개발자 대체가 아니라 **추상화 수준을 높여 더 복잡한 문제를 다루게 하는 것**임 초기 컴퓨터의 배선 프로그래밍에서 시작해, 어셈블리, C, Python, 프레임워크로 발전하면서 개발자는 점점 더 높은 수준의 문제를 다루게 되었음 단, 이전 단계들은 모두 **결정적이고 검증 가능한 변환**이었지만, **생성형 AI는 비결정적**이라는 점이 다름 관련 이야기로 [The Story of Mel](http://catb.org/jargon/html/story-of-mel.html)을 참고할 만함 - 하지만 Anthropic의 CEO를 비롯한 기업들은 그런 철학적 목표보다 **비용 절감과 대체**에 더 관심이 있음 - 그래도 사람들은 여전히 “개발자 대체”를 이야기할 것임 - 각 추상화 단계는 **내부를 들여다볼 수 있어야 함** LLM은 컴파일러처럼 토큰, AST, IR 등을 볼 수 없기에 불투명함 - AI 기업의 진짜 목표는 **모든 지적 노동의 자동화**임 - 추상화가 높아질수록 **정확성과 통제력**이 줄어듦 자연어 기반의 비결정적 시스템은 이전 세대의 추상화와는 다름 그래서 “어셈블리에서 C로의 전환” 비유는 적절하지 않음 - Dijkstra의 말처럼, **과학은 어렵기 때문에 미움받고**, 그 힘을 가진 과학자도 미움받음 [EWD1041 원문 링크](https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1041.html) - 반대로, 개발자들은 늘 **비개발 직군을 자동화**하려는 꿈을 꿔왔음 AI는 그 꿈의 최신 버전임 - 언젠가 **모든 직업이 좋은 직업**이 되는 Star Trek식 세상이 올까? - 2000년대 초, 대학에서 **Rational Rose UML**이 필수 과목이었음 당시 한 스타트업 CEO가 “이제 다이어그램만 그리면 코드는 자동 생성되니 개발자는 필요 없다”고 말했음 하지만 결국 그 예언은 실현되지 않았음 ### Comment 49470 - Author: [hidden] - Created: 2026-01-19T14:19:16+09:00 - Points: 2 - Parent comment: 49410 - Depth: 1 [숨김 처리된 댓글입니다] ### Comment 49471 - Author: [hidden] - Created: 2026-01-19T14:19:50+09:00 - Points: 1 - Parent comment: 49470 - Depth: 2 [숨김 처리된 댓글입니다] ### Comment 49571 - Author: kayws426 - Created: 2026-01-21T09:18:17+09:00 - Points: 1 - Parent comment: 49471 - Depth: 3 기계가 기계를 위한 코드를 만든다. 기계어 위에 인간이 구축한 모래성은 결국 붕괴할 운명이다. ...라는 소리도 가능한데요ㅋㅋ ### Comment 49601 - Author: [hidden] - Created: 2026-01-21T12:08:52+09:00 - Points: 1 - Parent comment: 49571 - Depth: 4 [숨김 처리된 댓글입니다]