COBOL부터 AI까지, ‘개발자를 덜 필요로 하게 만들겠다’는 약속이 왜 매번 되풀이되는지, 그리고 그 50년의 반복이 소프트웨어 작업의 본질에 대해 무엇을 말해주는지 살펴본다.
07.12.2025, 작성: Stephan Schwab
1969년 닐 암스트롱이 달 표면에 발을 디뎠을 때, 세계는 조직화된 인간의 창의성이 무엇을 이룰 수 있는지 목격했습니다. 그 성취의 뒤에는 마거릿 해밀턴과 그녀의 팀이 있었고, 그들은 아폴로의 유도 소프트웨어를 손으로 직접 작성했으며, 꼼꼼한 리뷰를 통해 치명적인 오류를 잡아내면서 소프트웨어가 ‘미션 크리티컬’할 수 있음을 증명했습니다.
아폴로 프로그램은 ‘불가능을 가능하게 하는 데’ 소프트웨어 개발이 필수라는 사실을 보여주었습니다. 하지만 동시에 앞으로 수십 년간 비즈니스 리더들을 답답하게 만들 어떤 사실도 드러냈습니다. 소프트웨어를 작성하려면 전문 지식, 강도 높은 집중, 그리고 상당한 시간 투자가 필요하다는 점입니다. 더 쉽게 만들고자 하는 꿈—즉, 이런 비싼 전문가가 덜 필요하도록 만드는 꿈—은 거의 즉시 시작되었습니다.
1960년대 후반과 1970년대에는 COBOL이 등장했는데, 이름에 그 목표가 노골적으로 담겨 있었습니다. Common Business-Oriented Language(공통 비즈니스 지향 언어). 비전은 명확했습니다. 언어가 영어 문장처럼 읽히도록 만들면, 비즈니스 분석가들이 직접 프로그램을 작성할 수 있을 것이다. 전문 프로그래머가 필요 없을 것이다.
"문법을 충분히 읽기 쉽게 만들면, 비즈니스를 이해하는 누구나 코드를 쓸 수 있다."
이 비전에는 진짜 매력이 있었습니다. 소프트웨어는 비즈니스 운영에 필수가 되어가는데, 프로그래머는 여전히 희소하고 비싼 자원이었기 때문입니다. COBOL은 소프트웨어 제작을 ‘민주화’하겠다고 약속했습니다.
하지만 실제로는 어떻게 되었을까요? COBOL은 또 하나의 ‘전문 교육이 필요한’ 프로그래밍 언어가 되었습니다. COBOL을 쓰려던 비즈니스 분석가들은 곧, 읽기 쉬운 문법이 논리의 복잡성, 데이터 구조, 시스템 설계의 복잡성을 제거해 주지 않는다는 사실을 깨달았습니다. 새로운 ‘COBOL 프로그래머’ 계층이 등장했고, 전문 개발자를 없애려던 꿈은 실현되지 않았습니다.
그렇다고 꿈이 사라진 것은 아닙니다. 그저 다음 기술의 물결을 기다렸을 뿐입니다.
1980년대에는 컴퓨터 지원 소프트웨어 공학(CASE) 도구가 엄청난 기대와 함께 등장했습니다. 플로우차트와 엔터티-관계(ER) 다이어그램을 그리기만 하면, 도구가 동작하는 코드를 생성해 준다는 약속이었습니다. 마케팅 메시지는 설득력이 있었습니다. 난해한 명령을 타이핑하는 것보다 시각적 설계가 더 직관적이라는 주장입니다. 비즈니스 전문가가 프로세스를 모델링하면, 소프트웨어가 ‘물질화’될 것이라고 말했습니다.
조직들은 크게 투자했습니다. 벤더들은 생산성이 10배 이상 증가한다고 약속했습니다. 하지만 대부분의 CASE 도구 이니셔티브는 고전하거나 완전히 실패했습니다.
생성된 코드는 종종 상당한 수작업 개입이 필요했습니다. 성능 문제가 나타났습니다. 생성 코드가 시각적 모델에서 벗어나기 시작하면 유지보수는 악몽이 되었습니다. 무엇보다도, 정확한 다이어그램을 그리려면 프로그래밍이 요구하는 것과 동일한 논리적 복잡성을 이해해야 했습니다. 도구는 인터페이스를 바꿨을 뿐, 근본적인 도전 과제를 바꾸지 못했습니다.
다시 한 번, 문제는 해결책보다 더 완고하다는 것이 증명되었습니다.
1990년대에는 다른 접근이 등장했습니다. 마이크로소프트의 Visual Basic과 볼랜드의 Delphi는 사용자 인터페이스 구축을 극적으로 쉽게 만들었습니다. 구성 요소를 폼에 끌어다 놓고, 속성을 설정하고, 이벤트 핸들러를 작성합니다. 갑자기 윈도우 애플리케이션을 만드는 일이 적당한 경험의 개발자에게도 가능해 보이기 시작했습니다.
이 물결은 COBOL이나 CASE 도구와는 다른 방식으로 성공했습니다. 이 환경들은 프로그래밍 지식이 여전히 필요하다는 점을 인정하면서도, 진입 장벽을 낮췄습니다. 더 넓은 범위의 사람들이 유용한 애플리케이션을 만들 수 있게 되었습니다.
하지만 ‘개발자를 없애겠다’는 꿈은 지속되었습니다. “파워 유저”와 “시민 개발자”가 부서용 애플리케이션을 만들 것이고, IT 부서는 인프라에 집중하며 비즈니스 부서가 스스로 소프트웨어 요구를 해결할 수 있다는 기대였습니다.
현실은 더 미묘했습니다. 단순한 애플리케이션은 действительно 더 많은 사람이 접근할 수 있었습니다. 그러나 요구사항이 복잡해지면—기존 시스템과의 통합, 보안 고려, 부하 상황에서의 성능, 장기 유지보수—숙련된 개발자의 필요성이 분명해졌습니다. 도구는 소프트웨어를 작성할 수 있는 사람의 범위를 넓혔지만, 중요한 시스템에 필요한 전문성을 제거하진 못했습니다.
그리고 사이클은 새천년으로 이어졌습니다.
이후 매 10년마다 새로운 변주가 등장했습니다. Ruby on Rails는 ‘설정보다 관례(Convention over configuration)’를 약속했습니다. 로우코드 플랫폼은 최소한의 코딩으로 시각적 개발을 제공했습니다. 노코드 플랫폼은 흔한 비즈니스 애플리케이션에 대해 프로그래밍을 완전히 제거하겠다고 주장했습니다.
각 물결은 실제 가치를 제공했습니다. 특정 맥락에서는 개발이 진짜로 더 빨라졌습니다. 더 많은 사람이 소프트웨어 솔루션 제작에 참여할 수 있게 되었습니다. 그러나 전문 소프트웨어 개발자는 여전히 필수였고, 그 기술에 대한 수요는 줄기는커녕 계속 늘어났습니다.
그렇다면 질문은 이것입니다. 왜 이 패턴이 반복될까요?
이 반복되는 패턴은 우리가 복잡성을 어떻게 생각하는지에 대한 중요한 사실을 드러냅니다. 소프트웨어 개발은 우리가 원하는 것을 평범한 언어로 설명할 수 있기 때문에 단순해 보입니다. “고객이 주문을 하면, 재고를 확인하고, 배송비를 계산하고, 결제를 처리하고, 확인 이메일을 보낸다.” 이 설명은 단순해 보입니다.
복잡성은 디테일에서 발생합니다. 재고가 다른 주문에 의해 임시로 예약된 상태라면 어떻게 할까요? 부분 결제는 어떻게 처리하나요? 이메일 서비스가 일시적으로 사용 불가하면요? 재시도해야 할까요? 몇 번이나요? 결제 과정에서 고객 세션이 만료되면 어떻게 할까요? 중복 주문을 어떻게 방지하나요?
각 답은 더 많은 질문으로 이어집니다. 누적되는 의사결정, 예외 케이스, 상호작용이 어떤 도구나 언어로도 제거할 수 없는 진짜 복잡성을 만듭니다. 누군가는 이런 시나리오를 끝까지 생각해내야 합니다. 그 ‘사고’ 자체가 소프트웨어 개발입니다. COBOL로 표현되든, CASE 도구 다이어그램으로 표현되든, Visual Basic으로 표현되든, AI 프롬프트로 표현되든 마찬가지입니다.
그리고 여기서 오늘의 흥분으로 이어집니다.
오늘날의 AI 코딩 어시스턴트는 소프트웨어 제작을 돕기 위한 시도 중 가장 강력한 형태를 보여줍니다. 자연어 설명만으로도 상당한 양의 동작하는 코드를 생성할 수 있습니다. 기존 코드를 설명하고, 개선을 제안하고, 디버깅을 돕기도 합니다.
이는 진정한 진보입니다. 도움은 वास्तविक로 존재하며 가치가 큽니다. 숙련된 개발자들은 이 도구를 사용해 더 효율적으로 일합니다. 코딩을 배우는 사람들은 대화형 안내가 유용하다고 느낍니다.
하지만 이미 익숙한 패턴이 다시 나타나고 있습니다. AI가 개발자를 대체할 것이라는 초기의 열광은, 더 미묘한 이해로 바뀌고 있습니다. 즉 AI는 개발자가 일하는 방식을 바꾸지만, 판단(judgment)의 필요를 제거하진 않습니다. 복잡성은 그대로 남습니다. 누군가는 비즈니스 문제를 이해하고, 생성된 코드가 이를 올바르게 해결하는지 평가하고, 보안상 함의를 고려하고, 기존 시스템과 적절히 통합되는지 확인하고, 요구사항이 변화함에 따라 유지보수해야 합니다.
AI는 개발자의 역량을 증폭시킵니다. 문제 도메인과 기술적 환경을 모두 이해하는 사람의 필요를 대체하진 않습니다.
이 패턴을 특히 더 아프게 만드는 역설이 있습니다. 우리는 소프트웨어 역량에서 놀라운 진보를 이뤘습니다. 아폴로 유도 컴퓨터의 RAM은 4KB였습니다. 여러분의 스마트폰은 수백만 배의 컴퓨팅 파워를 가지고 있습니다. 우리는 개발의 많은 측면을 진짜로 쉽게 만들어 주는 도구와 프레임워크를 구축했습니다.
그런데도 소프트웨어 수요는 우리가 만들 수 있는 능력을 훨씬 초과합니다. 모든 조직은 만들 수 있는 것보다 더 많은 소프트웨어가 필요합니다. 원하는 기능과 신규 이니셔티브의 백로그는 개발팀이 처리할 수 있는 속도보다 더 빠르게 늘어납니다.
이 긴장—강력한 도구, 그러나 부족한 생산 능력—이 꿈을 살아 있게 합니다. 비즈니스 리더들은 백로그를 보며 “더 빨리 갈 방법이 있을 텐데, 더 많은 사람이 기여할 수 있게 해야 하는데”라고 생각합니다. 이는 합리적인 생각입니다. 그리고 소프트웨어 제작을 민주화한다고 약속하는 어떤 도구나 접근법에도 자연스럽게 열광하게 됩니다.
문제는 소프트웨어 개발의 주요 제약이 타이핑 속도나 문법 지식이 아니라는 점입니다. 복잡성을 잘 다루기 위해 필요한 ‘사고’가 제약입니다. 데이터베이스 동시 업데이트를 어떻게 처리할지 고민하는 상황에서 타이핑이 빨라져도 도움이 되지 않습니다. 보안상 함의를 추론해야 하는 상황에서 문법이 단순해져도 도움이 되지 않습니다.
그렇다면 리더는 이 이해를 바탕으로 무엇을 해야 할까요?
이 패턴을 이해하면 새로운 도구와 접근법을 평가하는 방식이 달라집니다. 누군가 ‘개발자 없이도 비즈니스 사용자가 앱을 만들 수 있다’고 약속할 때, 그 열망을 이해하면서도 현실적인 기대치를 유지할 수 있습니다.
올바른 질문은 “이것이 개발자를 없애 줄까?”가 아닙니다. 올바른 질문들은 다음과 같습니다.
이 질문들은 개발에는 제거 불가능한 복잡성이 있음을 인정하면서도, 진짜 레버리지(지렛대)를 제공하는 도구에 열린 태도를 유지합니다.
그리고 소프트웨어 작업의 본질에 대해 더 깊은 무언가를 가리킵니다.
이 50년의 패턴은 소프트웨어 개발 자체에 대해 근본적인 무언가를 가르쳐 줍니다. 만약 문제가 주로 기계적이라면—너무 많은 타이핑, 너무 복잡한 문법, 너무 많은 단계—우리는 진작 해결했을 것입니다. COBOL은 문법을 읽기 쉽게 만들었습니다. CASE 도구는 타이핑을 제거했습니다. 비주얼 도구는 문법을 제거했습니다. AI는 이제 설명만으로 전체 함수를 생성할 수 있습니다.
각 발전은 실제 마찰 지점을 해결했습니다. 그러나 근본적 도전은 지속됩니다. 그 이유는 문제가 기계적이지 않기 때문입니다. 지적(intellectual) 문제이기 때문입니다. 소프트웨어 개발은 ‘생각을 형태로 만든 것’입니다. 우리가 만드는 산출물—COBOL 프로그램이든, Delphi 폼이든, Python 스크립트든—은 복잡성에 대한 보이지 않는 추론이 눈에 보이는 형태로 나타난 결과입니다.
건물을 설계하거나 의료 상태를 진단하는 데 필요한 추론을 단축할 수 없는 것처럼, 그 추론을 단축할 수도 없습니다. 더 나은 도구는 도움이 됩니다. 경험도 도움이 됩니다. 하지만 누군가는 여전히 끝까지 생각해내야 합니다.
그렇다면 이 모든 것을 알면서 우리는 어떻게 앞으로 나아가야 할까요?
다음 개발 도구의 물결은 또 올 것입니다. 어떤 것은 진짜 가치를 제공할 것이고, 어떤 것은 새로운 기술로 익숙한 약속을 반복할 것입니다. 이 반복 패턴에 대한 관점을 갖고 있으면, 새로운 도구들과 생산적으로 관계 맺을 수 있습니다.
AI 어시스턴트를 사용하세요. 로우코드 플랫폼을 평가하세요. 새로운 프레임워크를 실험하세요. 하지만 가장 크게 투자해야 할 대상은 사람들의 ‘복잡성을 명료하게 사고하는 능력’입니다. 그 능력은 아폴로 프로그램 때와 마찬가지로 여전히 제약 요인입니다.
달 착륙은 비범하게 복잡한 도전의 모든 디테일을 뛰어난 사람들이 꼼꼼히 생각했기 때문에 가능했습니다. 그들은 사용 가능한 도구가 그것뿐이어서 손으로 소프트웨어를 작성했습니다. 더 나은 도구가 있었다면 기꺼이 썼을 것입니다. 하지만 도구가 그들이 복잡성을 끝까지 생각해야 할 필요를 없애주진 못했을 겁니다.
우리는 여전히 같은 근본적 상황에 있습니다. 우리는 더 나은 도구—훨씬 더 나은 도구—를 갖고 있지만, ‘사고’는 여전히 필수입니다.
어쩌면 개발자를 대체하려는 반복되는 꿈은 실수가 아닐지도 모릅니다. 어쩌면 도구 창조를 이끄는 필요한 낙관주의일지도 모릅니다. 개발을 더 접근 가능하게 만들려는 각 시도는 실제로 도움이 되는 도구를 만들어 냅니다. 꿈은 상상한 그대로 실현되지는 않지만, 추구하는 과정에서 가치가 창출됩니다.
COBOL은 비즈니스 분석가가 프로그램을 작성하게 하진 못했지만, 한 세대의 개발자들이 비즈니스 시스템을 효과적으로 구축할 수 있게 했습니다. CASE 도구는 완전한 애플리케이션을 생성하진 못했지만, 시각적 모델링에 대한 사고를 진전시켰습니다. Visual Basic은 전문 개발자를 없애진 못했지만, 더 많은 사람들에게 애플리케이션 개발을 가져다주었습니다. AI는 개발자를 대체하진 못하지만, 우리가 일하는 방식을 의미 있게 바꿀 것입니다.
이 패턴이 계속되는 이유는, 그 꿈이 정당한 필요를 반영하기 때문입니다. 우리는 소프트웨어를 더 빠르고 효율적으로 만드는 방법이 진짜로 필요합니다. 다만 우리는 계속해서 제약이 도구가 아니라 ‘우리가 해결하려는 문제의 복잡성’임을 발견합니다.
이 이해는 새로운 도구를 거부하라는 뜻이 아닙니다. 도구가 제공할 수 있는 것과, 인간의 판단이 항상 필요할 것을 명확한 기대치로 구분하라는 뜻입니다.
당신의 실제 상황을 이야기해봅시다. 전달 속도를 높이고, 기술적 장애물을 제거하고, 아이디어가 더 많은 투자 가치가 있는지 검증하고 싶나요? 짧은 대화(20분)를 예약하세요. 저는 당신의 맥락을 듣고 1~2개의 실용적인 권고를 드립니다—세일즈 피치도, 의무도 없습니다. 맞으면 계속하고, 아니면 명확함을 얻고 나가면 됩니다. 비밀 보장, 그리고 직설적으로 진행합니다.
대화 예약 이메일이 더 좋나요? 여기로 연락하세요: sns@caimito.net
새 글, 스토리 에피소드, 영웅 프로필을 받은편지함으로 받아보세요.
구독 이메일은 newsletter.caimito.net의 개인정보 처리방침에 따라 처리됩니다. 언제든 구독 해지할 수 있습니다.
팀에 실제 기여자로서 임베드되어, 효과성을 높이고 엔지니어링 명확성을 끌어올립니다.
시니어 Developer Advocate 자세히 보기 →
큰 결정을 내리기 전에 동료(피어) 스타일의 기술 평가를 수행해, 아키텍처 및 제품 리스크를 초기에 줄입니다.
실제 사용자에게 동작하는 소프트웨어를 더 일찍 전달하세요. 가정이 아니라 근거를 측정하고 그에 따라 적응합니다.
고품질의 유지보수 가능한 소프트웨어. 단기 증원이지만, 팀 내부에 지속 가능한 역량을 남깁니다.
Caimito Agile Life "소프트웨어 딜리버리에 엔지니어링의 정직함을 회복하다"
팔로우:
언어 변경:
×
