웹 기술의 역사는 겉으로 보면 새 프레임워크가 오래된 프레임워크를 밀어낸 이야기처럼 보입니다. PHP가 있었고, EJB가 있었고, Struts와 custom servlet이 있었고, Spring이 왔고, ASP.NET과 Spring Boot가 지나갔고, Node.js 계열이 유행했습니다. 요즘은 Next.js, NestJS, 서버리스, 엣지 런타임, AI 코딩 에이전트까지 한 줄에 세워 놓을 수 있습니다.
그런데 국내 웹 개발의 실제 현장은 그렇게 빨리 바뀌지 않았습니다. 특히 돈이 큰 곳, 즉 금융과 공공 프로젝트에서는 기술의 최신성보다 안정성, 인력 수급, 유지보수성, 감리 대응, 장기 운영 가능성이 훨씬 더 중요했습니다. 그래서 한국의 웹 백엔드 주류는 오랫동안 Java와 Spring 위주로 굳어졌습니다.
이 글은 그 흐름을 한 번 길게 정리해보려는 글입니다. "최신 기술이 꼭 좋은 기술인가"라는 질문도 같이 다룹니다. 결론부터 말하면, 아닙니다. 대규모 엔터프라이즈 환경에서는 아직도 Java와 Spring이 좋은 선택인 경우가 많습니다. 동시에 더 긴 시간축으로 보면 Java도 영원하지는 않을 겁니다. 개발자가 사라지면 언어도 사라집니다. 다만 AI가 그 결말을 조금 이상하게 바꾸고 있습니다. 언어 종속은 약해지고, 과거의 유산은 AI가 가지고 노는 재료가 될 가능성이 커졌습니다.
1990년대 말부터 2000년대 초까지: 웹은 빨리 만들 수 있는 사람이 이겼습니다
1990년대 말의 웹은 지금 기준으로 보면 거칠었습니다. HTML 페이지를 만들고, 폼을 받고, DB에 저장하고, 목록을 보여주면 서비스가 됐습니다. CGI, Perl, PHP, ASP, 초기 JSP가 이 시기의 주인공이었습니다. 당시의 핵심은 우아한 아키텍처가 아니라 "빨리 화면을 띄우는 것"이었습니다.
PHP가 강했던 이유도 여기에 있습니다. PHP 공식 문서의 역사 페이지는 PHP가 개인 홈페이지 도구에서 출발해 웹 페이지를 동적으로 만들기 위한 언어로 성장했다고 설명합니다. Apache에 붙이기 쉽고, HTML 사이에 코드를 끼워 넣기 쉬웠고, MySQL과 같이 쓰기 좋았습니다. 웹호스팅 업체들이 PHP와 MySQL을 저렴하게 제공한 것도 컸습니다. 작은 회사, 커뮤니티, 쇼핑몰, 게시판, 초기 CMS에는 PHP가 잘 맞았습니다.
ASP도 비슷한 이유로 인기가 있었습니다. Windows 서버와 IIS, Visual Basic 계열 개발자 경험, Microsoft 생태계를 이미 쓰던 회사에는 ASP가 편했습니다. 특히 국내에는 Windows 기반 사무환경이 널리 깔려 있었고, Visual Basic이나 Classic ASP로 빠르게 내부 업무 화면을 만드는 개발자도 많았습니다.
이 시기의 흥망성쇠를 점유율로 딱 잘라 말하기는 어렵습니다. 국내 프로젝트 단위의 정확한 장기 통계는 공개 자료가 부족합니다. 다만 전 세계 공개 웹 기준으로 보면 PHP의 영향력은 아직도 큽니다. W3Techs는 2026년 7월 기준, 서버 사이드 언어를 파악할 수 있는 웹사이트 중 PHP 사용 비율을 70.6%로 집계합니다. 이 수치는 WordPress 같은 CMS의 영향이 매우 크기 때문에 국내 엔터프라이즈 백엔드 점유율로 읽으면 안 됩니다. 그래도 PHP가 "한때의 유행"이 아니라 공개 웹의 긴 생명력을 가진 기술이라는 점은 보여줍니다.
국내 기업 업무 시스템은 조금 다른 길을 갔습니다. 쇼핑몰, 게시판, 소규모 웹서비스에서는 PHP와 ASP가 강했지만, 대형 SI와 금융·공공에서는 Java가 빠르게 힘을 얻었습니다. 이유는 단순했습니다. JVM은 서버 프로그램을 장기간 운영하기 좋았고, 벤더와 솔루션 생태계가 있었고, 대기업·공공기관이 요구하는 표준화와 문서화에 맞추기 쉬웠습니다.
왜 그때 그 기술들이 인기 있었나
초기 웹 기술의 인기는 기술적 우월성 하나로 설명되지 않습니다.
| 시기 | 많이 쓰인 기술 | 인기 이유 | 약점 |
|---|---|---|---|
| 1990년대 후반 | CGI, Perl | 웹 서버와 붙이기 쉬웠고 자료가 많았음 | 유지보수와 구조화가 어려움 |
| 1990년대 후반~2000년대 | PHP | 배포가 쉽고 웹호스팅과 궁합이 좋았음 | 큰 조직의 계층형 설계에는 약했음 |
| 1990년대 후반~2000년대 | ASP | Windows/IIS 환경에서 빠른 업무 화면 개발 | Microsoft 스택 종속, 이후 ASP.NET으로 이동 |
| 2000년대 초 | JSP/Servlet | Java 기반 서버 개발의 표준 흐름 | 화면과 로직이 쉽게 섞임 |
여기서 중요한 점은 "개발자 수"입니다. 어떤 기술이 살아남는 데에는 성능보다 개발자 풀이 더 중요할 때가 많습니다. 프로젝트를 수주하고, 투입하고, 운영하고, 장애를 대응하고, 5년 뒤에도 사람을 구해야 합니다. 국내 SI 시장에서는 이 조건이 기술 선택을 아주 강하게 눌렀습니다.
EJB, Struts, custom servlet: 엔터프라이즈라는 이름의 무거운 시대
2000년대 초중반으로 넘어오면 Java 웹 개발은 더 조직적인 형태를 갖습니다. JSP와 Servlet만으로도 서비스를 만들 수 있었지만, 프로젝트가 커지면 문제가 생겼습니다. 화면 처리, 세션 처리, DB 접근, 트랜잭션, 권한, 로그, 배치, 연동 코드가 뒤엉켰습니다. 그래서 엔터프라이즈 Java 진영은 더 큰 틀을 만들려고 했습니다.
EJB는 그 상징 같은 기술이었습니다. Enterprise JavaBeans는 분산 객체, 트랜잭션, 보안, 풀링 같은 엔터프라이즈 기능을 컨테이너가 관리하게 하려는 시도였습니다. 당시에는 그럴듯했습니다. 은행, 보험, 카드, 공공기관 업무는 트랜잭션이 중요하고, 서버를 여러 대로 나누고, 장애를 버텨야 합니다. "복잡한 기업 시스템을 표준 Java 방식으로 만들 수 있다"는 약속은 매력적이었습니다.
문제는 너무 무거웠다는 겁니다. 설정은 많고, 배포는 느리고, 테스트는 어려웠습니다. XML 설정과 컨테이너 의존성이 늘어났고, 개발자가 비즈니스 코드를 쓰는 시간보다 프레임워크와 싸우는 시간이 길어졌습니다. 엔터프라이즈라는 단어가 주는 안정감은 있었지만, 현장 개발자에게는 답답함도 컸습니다.
Struts는 이 무거운 흐름을 조금 더 웹에 맞게 정리했습니다. Apache Struts는 Java 웹 애플리케이션을 MVC 패턴으로 구성하도록 도와줬습니다. 요청을 Action으로 받고, 설정 파일로 흐름을 정하고, JSP로 화면을 렌더링했습니다. 당시 JSP 안에 Java 코드가 마구 들어가던 혼란을 줄이는 데에는 효과가 있었습니다.
하지만 Struts도 시간이 지나며 한계를 보였습니다. XML 설정이 많았고, Action 중심 구조가 복잡해졌고, 테스트와 리팩터링이 쉽지 않았습니다. 그래서 많은 SI 현장은 Struts를 쓰거나, Struts 비슷한 custom servlet 프레임워크를 직접 만들었습니다. 회사별, 프로젝트별로 "우리 프레임워크"가 생겼습니다. 공통 Action, 공통 Controller, 공통 DAO, 공통 권한 체크, 공통 메시지 처리 같은 것들이었습니다.
이 custom servlet 문화는 나쁘기만 한 것은 아니었습니다. 당시에는 오픈소스 프레임워크 생태계가 지금만큼 성숙하지 않았고, 각 기관의 요구사항도 제각각이었습니다. 공통 모듈을 만들어 반복 작업을 줄이려는 시도는 자연스러웠습니다. 다만 시간이 지나면 사내 프레임워크는 지식의 감옥이 됩니다. 만든 사람은 떠나고, 문서는 낡고, 프레임워크는 남습니다. 한국 SI 현장에서 "과거의 유산으로 지키는 현시대의 개발"이 시작된 지점도 이 근처라고 봅니다.
국내 IT 시장의 특성: 돈은 주로 금융과 공공에서 나왔습니다
국내 IT 시장을 이해하려면 "누가 돈을 쓰는가"를 먼저 봐야 합니다. 웹서비스 스타트업도 있었고 제조·유통·통신도 있었지만, 대규모 SI 예산을 꾸준히 집행한 축은 금융과 공공이었습니다. 은행 차세대, 보험 기간계, 카드 승인, 증권 HTS, 전자정부, 지방자치단체 시스템, 공공 포털, 교육·세무·조달 시스템 같은 프로젝트가 시장의 큰 물줄기를 만들었습니다.
이 시장은 기술을 고르는 기준이 소비자 웹과 다릅니다. 최신 프레임워크가 아니라 다음 질문이 중요합니다.
- 이 기술을 아는 개발자를 수십 명, 많으면 수백 명 투입할 수 있는가.
- 5년, 10년 뒤에도 유지보수할 수 있는가.
- 보안 점검, 감리, 문서화, 운영 인수인계에 대응할 수 있는가.
- 장애가 났을 때 벤더, SI사, 하도급사가 책임 구조를 만들 수 있는가.
- 기관 내부 표준과 기존 시스템 연동을 깨지 않는가.
이 조건에서는 새 기술이 불리합니다. 성능이 좋아도 개발자가 적으면 위험합니다. 코드가 짧아도 감리 문서가 빈약하면 위험합니다. 배포가 빠른 기술이어도 운영팀이 익숙하지 않으면 위험합니다. 그래서 국내 기술 주도권은 개발자 커뮤니티의 취향보다 금융·공공 발주 구조에 더 강하게 묶였습니다.
전자정부 표준프레임워크도 이 흐름을 상징합니다. eGovFrame 포털은 실행환경, 개발환경, 운영환경, 공통 컴포넌트, 호환성 확인 같은 항목을 제공합니다. 이는 단순히 프레임워크 하나를 배포했다는 뜻이 아닙니다. 공공 프로젝트에서 반복되는 구조를 표준화하고, 교육과 적용지원을 통해 일정한 개발 방식을 확산했다는 뜻입니다. 그 기반에는 Java와 Spring 생태계가 있었습니다.
Spring에서 Spring Boot, Node.js까지: 주류는 바뀌었지만 속도는 달랐습니다
Spring은 EJB의 반작용으로 힘을 얻었습니다. 복잡한 컨테이너와 무거운 배포 모델 대신, 평범한 Java 객체를 중심으로 애플리케이션을 구성하게 해줬습니다. DI, AOP, 트랜잭션 추상화, JDBC/ORM 연동, MVC 구조는 Java 개발자가 대형 업무 시스템을 만들 때 필요한 것들을 비교적 현실적으로 제공했습니다.
Spring이 국내에서 주류가 된 이유는 몇 가지가 겹쳤습니다.
첫째, 기존 Java 인력을 그대로 흡수했습니다. PHP나 Ruby on Rails처럼 언어 자체를 바꾸지 않아도 됐습니다. Java를 쓰던 회사가 Spring으로 옮기는 일은 가능했지만, Java 조직이 갑자기 Ruby나 Python 웹 프레임워크로 바뀌는 일은 훨씬 어려웠습니다.
둘째, 레거시와 공존할 수 있었습니다. 기존 Servlet 컨테이너, WAS, Oracle DB, 내부 인증, 배치, 메시징, 파일 연동을 한 번에 버릴 수 없는 환경에서 Spring은 점진적 전환이 가능했습니다. 국내 금융·공공은 전환 비용을 매우 싫어합니다. 운영 중인 시스템을 완전히 갈아엎기보다는 주변부터 바꾸고, 일부 모듈을 바꾸고, 표준을 조금씩 업데이트하는 방식을 선호합니다.
셋째, 표준과 비표준 사이에서 균형을 잡았습니다. 순수 Java EE 표준만 고집하면 개발 생산성이 낮아졌고, 완전한 사내 custom 프레임워크는 장기 유지보수 리스크가 컸습니다. Spring은 오픈소스이면서도 엔터프라이즈 기능을 제공했고, 레퍼런스와 교육 자료, 책, 강의, 커뮤니티가 빠르게 늘었습니다.
넷째, 공공 표준화와 SI 인력 시장이 같은 방향으로 움직였습니다. eGovFrame이 Spring 기반 개발 방식을 넓히면서 공공 프로젝트에서 Spring 경험은 사실상 기본 역량이 되었습니다. 금융도 비슷했습니다. 한 번 Java/Spring 중심으로 대규모 인력 풀이 형성되면, 다음 프로젝트도 같은 기술을 고릅니다. 기술이 좋아서 사람이 모이고, 사람이 많아서 다시 기술이 선택되는 순환이 생깁니다.
Spring Boot는 이 흐름을 더 굳혔습니다. Spring 공식 문서는 Spring Boot가 독립 실행 가능한 production-grade Spring 애플리케이션을 쉽게 만들고, 내장 Tomcat/Jetty/Undertow, starter dependency, 자동 설정, metrics와 health check 같은 운영 기능을 제공한다고 설명합니다. 예전에는 WAR를 만들어 WAS에 올리고 XML 설정을 길게 만졌다면, Spring Boot 이후에는 java -jar로 실행하는 애플리케이션 구조가 자연스러워졌습니다.
이 변화는 클라우드와 마이크로서비스 시대에 잘 맞았습니다. 컨테이너로 감싸기 쉽고, 배포 단위가 작아지고, health endpoint를 붙이기 쉬웠습니다. 그래서 Spring은 죽은 것이 아니라 Spring Boot로 다시 살아났습니다. 정확히는 "낡은 Java 웹"이 아니라 "운영 가능한 Java 애플리케이션 플랫폼"으로 재포장됐습니다.
ASP.NET과 Microsoft 계열은 왜 다른 궤적을 탔나
ASP와 ASP.NET은 국내에서도 꾸준히 쓰였습니다. Microsoft 공식 ASP.NET 소개는 웹 앱과 API를 만들기 위한 .NET 기반 프레임워크로 설명합니다. Windows Server, IIS, Visual Studio, MS SQL Server를 함께 쓰는 조직에서는 생산성이 높았습니다. 특히 내부 업무 시스템, 제조·유통 기업, Microsoft 라이선스가 이미 깔린 조직에서는 좋은 선택이었습니다.
다만 국내 대형 공공·금융 SI의 중심축은 Java 쪽으로 더 강하게 기울었습니다. 이유는 기술 하나보다 조달, 운영, 인력, 벤더 구조의 문제였습니다. Java는 특정 OS나 벤더에 덜 묶인다는 인식이 있었고, WebLogic, WebSphere, JEUS 같은 상용 WAS와도 함께 쓰였습니다. 공공 표준프레임워크도 Java/Spring 중심으로 자리를 잡았습니다.
그래서 ASP.NET은 사라진 기술이 아닙니다. 다만 국내 대규모 SI의 상징 기술은 되지 못했습니다. 반대로 글로벌 개발자 조사에서는 ASP.NET Core가 여전히 의미 있는 위치에 있습니다. Stack Overflow 2024 조사에서 전문 개발자 기준 ASP.NET Core 사용률은 19.1%, ASP.NET은 14.3%로 집계됩니다. Spring Boot의 전문 개발자 기준 사용률은 14.2%입니다. 이 숫자는 전 세계 응답자 기반이라 국내 금융·공공의 체감과는 다르지만, "Java/Spring만 남고 .NET은 죽었다"는 식의 단순화는 틀렸다는 점을 보여줍니다.
Node.js와 프론트엔드 시대: 빠른 변화는 앞단에서 먼저 왔습니다
2010년대 이후 웹 개발의 변화는 백엔드보다 프론트엔드에서 더 빨랐습니다. jQuery, AngularJS, React, Vue, TypeScript, Next.js 같은 기술이 사용자 화면과 개발 경험을 크게 바꿨습니다. SPA와 API 분리는 백엔드 구조에도 영향을 줬습니다. 서버는 HTML을 그리는 곳에서 JSON API를 제공하는 곳으로 바뀌었고, 프론트엔드 빌드와 배포가 별도 영역으로 커졌습니다.
Node.js는 이 변화의 핵심 런타임이었습니다. Node.js 공식 문서는 Node.js를 비동기 이벤트 기반 JavaScript 런타임으로 설명하며, 많은 연결을 동시에 처리하는 네트워크 애플리케이션에 적합하다고 말합니다. 브라우저에서 쓰던 JavaScript를 서버에서도 쓰게 되면서, 한 언어로 프론트와 백엔드를 모두 다룰 수 있다는 장점이 생겼습니다.
Node 계열이 인기 있었던 이유는 명확합니다.
- 프론트엔드 개발자가 서버 코드까지 확장하기 쉬웠습니다.
- npm 생태계가 폭발적으로 커졌습니다.
- JSON API, 실시간 통신, BFF(Backend for Frontend), 서버 사이드 렌더링에 잘 맞았습니다.
- 스타트업과 제품 조직은 Java/Spring보다 가볍게 시작할 수 있었습니다.
- React/Next.js 같은 프론트엔드 프레임워크와 자연스럽게 연결됐습니다.
Stack Overflow 2024 조사에서도 Node.js는 웹 프레임워크/기술 항목에서 전체 응답자 40.8%, 전문 개발자 40.7%로 높은 사용률을 보였습니다. React도 전문 개발자 기준 41.6%입니다. 전 세계 개발자 생태계에서 JavaScript/TypeScript 계열의 힘은 매우 큽니다.
그런데 국내 대형 엔터프라이즈 백엔드가 Node.js로 완전히 넘어갔느냐 하면 그렇지 않습니다. 새 프론트엔드, BFF, 관리자 도구, 일부 마이크로서비스, 실시간 서비스에는 Node가 들어갔지만, 핵심 계정계나 장기 운영 업무의 중심은 여전히 Java/Spring인 경우가 많습니다. 이유는 다시 시장 구조입니다. 금융·공공은 기술 전환을 실험으로 보지 않습니다. 장애, 보안 사고, 감사 지적, 운영 인수인계 실패가 실제 비용으로 돌아옵니다.
이 지점에서 최신 기술의 한계가 드러납니다. 최신 기술은 개발 경험이 좋고, 생산성이 높고, 커뮤니티가 활발할 수 있습니다. 하지만 대규모 엔터프라이즈에서는 다음 조건도 필요합니다.
| 기준 | 최신 Node/프론트 계열이 강한 곳 | Java/Spring이 강한 곳 |
|---|---|---|
| 초기 개발 속도 | 빠른 프로토타입, 제품 실험 | 상대적으로 무겁지만 구조화 쉬움 |
| 인력 수급 | 프론트/풀스택 인력 풍부 | SI·공공·금융 백엔드 인력 매우 풍부 |
| 운영 표준 | 조직별 편차 큼 | 장기 운영 패턴이 축적됨 |
| 규제/감리 대응 | 문서화 체계는 조직 의존 | 레퍼런스와 표준 산출물이 많음 |
| 대규모 트랜잭션 | 가능하지만 설계 역량 의존 | 오래 검증된 패턴이 많음 |
그래서 "Node가 Spring을 대체한다"는 식의 말은 현실을 너무 단순하게 봅니다. Node는 많은 영역에서 이미 주류입니다. 하지만 Spring도 다른 이유로 주류입니다. 기술의 주류성은 하나의 왕좌가 아니라 시장 구역마다 다르게 나타납니다.
기술 변천이 느린 이유는 보수성만이 아닙니다
국내 웹 기술이 느리게 바뀌는 이유를 "한국 개발 문화가 보수적이라서"라고만 말하면 반쪽짜리 설명입니다. 느린 변화에는 합리적인 이유도 있습니다.
금융 시스템은 돈을 직접 다룹니다. 공공 시스템은 행정 서비스와 국민 데이터를 다룹니다. 장애가 나면 단순히 사용자가 불편한 수준이 아니라 사회적 비용이 생깁니다. 이 환경에서는 1년 된 기술보다 10년 버틴 기술이 더 설득력을 가집니다. 개발자는 지루하다고 느낄 수 있지만, 발주자와 운영자는 다르게 봅니다.
또 하나는 계약 구조입니다. 대형 SI 프로젝트는 요구사항 정의, 설계, 개발, 테스트, 감리, 운영 이관으로 나뉩니다. 여기서 기술은 코드만의 문제가 아닙니다. 산출물 템플릿, 개발 표준, 보안 점검표, 운영 매뉴얼, 장애 대응 절차까지 함께 움직입니다. 새로운 언어와 프레임워크를 도입하려면 이 문서 체계도 바꿔야 합니다. 비용이 큽니다.
그래서 아직도 Java/Spring 위주인 것은 낡음의 증거이면서 동시에 생존 전략의 결과입니다. 대규모 엔터프라이즈에서는 Spring이 여전히 좋습니다. DI, 트랜잭션, 보안, 배치, 데이터 접근, 메시징, 관측성, 테스트, 배포, 운영 생태계가 촘촘합니다. Spring Boot는 이를 더 쉽게 묶어줍니다. Kubernetes, 컨테이너, 클라우드와도 잘 연결됩니다.
다만 이 장점은 영원하지 않습니다. 모든 기술은 개발자 풀이 줄어드는 순간 급격히 늙습니다. COBOL이 사라지지 않은 이유는 업무가 남아 있어서입니다. 동시에 COBOL이 새 서비스의 주류가 되지 못한 이유는 개발자가 줄었기 때문입니다. Java도 같은 압력을 피할 수 없습니다. 지금은 개발자가 많고, 시스템이 많고, 교육 경로가 있습니다. 하지만 미래 세대가 Java를 덜 배우고, Kotlin·TypeScript·Python·Rust·AI 도구 중심으로 이동하면 Java의 생명력도 약해집니다.
저는 Java가 당장 끝난다고 보지는 않습니다. 오히려 꽤 오래 갑니다. 문제는 "언제 죽느냐"가 아니라 "어떤 모습으로 남느냐"입니다. 신규 서비스의 언어가 아니라 기존 거대 시스템의 운영 언어로 남을 수도 있습니다. 또는 AI 도구가 Java 코드를 읽고 고치고 테스트하는 능력이 좋아지면서, 사람이 직접 Java를 깊게 알 필요가 줄어드는 방향으로 갈 수도 있습니다.
AI 이후: 기술 종속이 약해지고, 레거시는 AI의 놀이터가 됩니다
AI의 발전은 웹 기술 변천사를 이상한 방향으로 틀고 있습니다. 예전에는 언어와 프레임워크를 모르면 그 시스템을 고칠 수 없었습니다. 개발자는 Java 개발자, PHP 개발자, ASP.NET 개발자, Node 개발자로 나뉘었습니다. 물론 좋은 개발자는 여러 언어를 배울 수 있지만, 실제 프로젝트 투입에서는 특정 스택 경험이 매우 중요했습니다.
AI 코딩 도구가 좋아질수록 이 경계는 약해집니다. 개발자가 Spring을 10년 한 사람만큼 내부 구조를 아는 것은 여전히 어렵지만, 낯선 코드베이스를 읽고, API 흐름을 요약하고, 테스트를 만들고, 마이그레이션 후보를 찾는 일은 AI가 점점 잘합니다. 언어 문법과 프레임워크 관용구의 진입장벽이 낮아집니다.
이 변화는 두 가지 상반된 결과를 낳습니다.
첫째, 신기술 도입의 압력이 줄어들 수 있습니다. 예전에는 낡은 프레임워크가 생산성을 떨어뜨리면 새 프레임워크로 갈아타고 싶었습니다. 하지만 AI가 낡은 코드를 꽤 잘 다루게 되면, 굳이 전체를 갈아엎지 않아도 됩니다. 요구사항을 충족시키는 구 기술을 그대로 두고, AI가 그 위에서 수정·테스트·문서화를 돕는 방식이 가능해집니다. 미래의 일부 개발 현장은 신기술 경연장이 아니라, 과거 기술들을 AI가 다루는 놀이터가 될 수 있습니다.
둘째, 기술 선택의 기준이 언어에서 요구사항으로 이동합니다. "이 프로젝트는 무조건 Spring" 또는 "요즘은 무조건 Node" 같은 말의 힘이 약해집니다. 대신 다음 질문이 중요해집니다.
- 이 요구사항은 어떤 운영 리스크를 갖는가.
- 기존 시스템과 어떤 방식으로 연동해야 하는가.
- AI 도구가 이 코드베이스를 얼마나 안전하게 이해하고 수정할 수 있는가.
- 테스트와 배포 자동화가 충분한가.
- 사람 개발자가 마지막 판단을 할 수 있는 구조인가.
이 관점에서는 최신 기술이 꼭 좋은 기술이 아닙니다. Spring과 Java는 지루하지만 예측 가능합니다. Node와 TypeScript는 빠르고 생태계가 넓지만, 패키지와 런타임 변화가 빠릅니다. PHP는 공개 웹과 CMS에서 여전히 강합니다. ASP.NET Core는 Microsoft 생태계와 클라우드에서 좋은 선택입니다. 중요한 것은 유행이 아니라 요구사항입니다.
과거의 유산으로 지키는 현시대의 개발
현재 많은 개발 현장은 과거의 유산 위에 서 있습니다. 오래된 DB 스키마, 오래된 배치, 오래된 인증 방식, 오래된 WAS, 오래된 화면 템플릿, 오래된 사내 프레임워크가 남아 있습니다. 개발자는 새 기능을 만들면서 동시에 이 유산을 지켜야 합니다.
이 말은 비관적으로만 들리지만, 꼭 그렇지는 않습니다. 레거시는 실패한 코드의 무덤이 아니라, 오래 살아남은 업무 지식의 저장소이기도 합니다. 은행의 이자 계산, 보험의 계약 변경, 공공의 민원 처리, 세금과 조달의 예외 규칙은 코드 속에 들어 있습니다. 문서보다 코드가 더 정확한 경우도 많습니다.
문제는 사람이 그 유산을 점점 읽기 어려워진다는 점입니다. 만든 사람은 떠나고, 신규 개발자는 다른 기술을 배우고, 문서는 낡습니다. 여기서 AI는 꽤 현실적인 도구가 될 수 있습니다. 레거시 코드를 요약하고, 영향 범위를 찾고, 테스트 케이스를 생성하고, 마이그레이션 계획을 만들고, 위험한 변경을 표시하는 역할입니다.
물론 AI가 모든 것을 해결하지는 않습니다. AI는 업무 책임을 지지 않습니다. 배포 버튼을 누른 뒤 장애가 나면 책임은 조직과 사람이 집니다. 그래서 AI 시대의 개발자는 더 이상 문법 암기자가 아니라 검증자, 요구사항 해석자, 운영 리스크 관리자에 가까워질 가능성이 큽니다.
미래는 어떻게 될까요?
제 예상은 이렇습니다. 웹 기술은 겉으로는 더 다양해질 겁니다. Next.js, Astro, Remix, Htmx, FastAPI, Spring Boot, ASP.NET Core, Go, Rust, Python, 서버리스, 엣지 런타임이 계속 공존할 겁니다. 하지만 대형 조직의 핵심 시스템은 쉽게 바뀌지 않습니다. 특히 국내 금융·공공은 Java/Spring 중심을 꽤 오래 유지할 가능성이 큽니다.
다만 그 Java/Spring의 의미는 달라질 겁니다. 예전에는 "사람이 Java를 잘 알아서 시스템을 지키는 시대"였습니다. 앞으로는 "AI가 Java/Spring 레거시를 이해하고, 사람이 요구사항과 위험을 판단하는 시대"가 될 수 있습니다. 그러면 기술 종속은 약해집니다. 언어를 잘 모르는 사람이 바로 운영 시스템을 고쳐도 된다는 뜻은 아닙니다. 대신 낯선 기술을 읽는 비용이 줄어든다는 뜻입니다.
신기술은 사라지지 않을 겁니다. 하지만 신기술을 도입하는 이유는 바뀔 수 있습니다. "요즘 유행이라서"가 아니라 "이 요구사항에는 이 기술이 운영 비용을 낮춘다"가 되어야 합니다. 반대로 구 기술도 부끄러운 것이 아닙니다. Spring이 요구사항을 충족하고, 인력과 운영 체계가 있고, 장애 대응이 가능하다면 좋은 기술입니다.
마지막으로 Java의 미래를 생각해봅니다. 언젠가는 Java도 지금의 COBOL처럼 보일 수 있습니다. 하지만 그 시점이 와도 Java 시스템은 곧바로 사라지지 않을 겁니다. 오히려 AI가 가장 많이 읽고 고치는 레거시 언어 중 하나가 될 가능성이 있습니다. 개발자가 사라지면 언어도 사라진다는 말은 맞습니다. 다만 AI 이후에는 "사라진다"의 의미가 바뀝니다. 사람이 매일 새로 쓰는 언어에서는 밀려나도, AI가 유지하고 변환하는 업무 자산으로 남을 수 있습니다.
그래서 미래의 웹 개발은 최신 프레임워크의 승부가 아니라, 요구사항과 레거시와 AI가 뒤섞인 이상한 혼합물이 될 가능성이 큽니다. 금융과 공공은 여전히 안정성을 요구할 것이고, 제품 조직은 여전히 빠른 실험을 원할 것이고, 개발자는 그 사이에서 오래된 코드를 읽고 새 도구를 붙일 겁니다.
웹 기술의 변천사는 결국 "무엇이 더 멋진가"의 역사가 아니었습니다. 누가 돈을 쓰고, 누가 운영하고, 누가 책임지고, 누가 10년 뒤에 고칠 수 있는가의 역사였습니다. 앞으로도 그 질문은 남습니다. 단지 답을 찾는 방식에 AI가 끼어들 뿐입니다.
