10년마다 되풀이되는 개발자 대체의 꿈
(caimito.net)- 지난 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는 개발 방식의 변화를 촉진
- 결국 제약은 도구가 아니라 우리가 해결하려는 문제의 복잡성에 있음
- 새로운 도구를 거부할 필요는 없으며, 현실적 기대와 인간 판단의 중요성을 인식해야 함
Hacker News 의견들
-
이번 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을 참고할 만함- 하지만 Anthropic의 CEO를 비롯한 기업들은 그런 철학적 목표보다 비용 절감과 대체에 더 관심이 있음
- 그래도 사람들은 여전히 “개발자 대체”를 이야기할 것임
- 각 추상화 단계는 내부를 들여다볼 수 있어야 함
LLM은 컴파일러처럼 토큰, AST, IR 등을 볼 수 없기에 불투명함 - AI 기업의 진짜 목표는 모든 지적 노동의 자동화임
- 추상화가 높아질수록 정확성과 통제력이 줄어듦
자연어 기반의 비결정적 시스템은 이전 세대의 추상화와는 다름
그래서 “어셈블리에서 C로의 전환” 비유는 적절하지 않음
-
Dijkstra의 말처럼, 과학은 어렵기 때문에 미움받고, 그 힘을 가진 과학자도 미움받음
EWD1041 원문 링크 -
반대로, 개발자들은 늘 비개발 직군을 자동화하려는 꿈을 꿔왔음
AI는 그 꿈의 최신 버전임- 언젠가 모든 직업이 좋은 직업이 되는 Star Trek식 세상이 올까?
-
2000년대 초, 대학에서 Rational Rose UML이 필수 과목이었음
당시 한 스타트업 CEO가 “이제 다이어그램만 그리면 코드는 자동 생성되니 개발자는 필요 없다”고 말했음
하지만 결국 그 예언은 실현되지 않았음