1. 개요
행정안전부 산하 한국정보화진흥원에서 만든 웹 기반 애플리케이션 프레임워크로서 정부 및 공공 기관, 공기업 등의 웹사이트에 자주 쓰이는 공통 기능들을 Java의 Spring 프레임워크와 유명 Java 라이브러리(MyBatis, Jackson, Apache Commons 등)를 가지고 미리 만들어 놓은 공통 컴포넌트와 이를 개발하는 개발 환경, 실행 환경, 운영 환경, 관리 환경 등으로 구성되어 있다. 전자정부프레임워크 포털다양한 기술이 난잡하게 사용되던 SI업계에 표준을 정해주어 업계 전체적으로 생산성을 증가시키려는 목적을 가지고 있다.
지금은 국내 IT 산업의 적폐로 찍혀서 평판이 좋지 않지만, 등장 당시인 2009년 기준으로는 나름 최신 트렌드를 따라갔던 시도였다. 중구난방이던 상용 소프트웨어가 판치고 EJB 같은 폐기물들이 널리 쓰이던 시기였으니, 당시 핫했던 오픈 소스 프로젝트[1]를 정부에서 밀어준 것은 꽤나 선진적인 시도였다고 볼 수도 있다. 지금도 최신 트렌드라고 하기는 어렵지만, React나 Spring Boot 같은 신기술을 꾸준히 지원 대상에 포함시키고 있는 것을 감안하면 인식처럼 심각한 적폐라고 보기는 힘들다.
2. 인식
2010년대 후반 이후엔 전자정부표준프레임워크를 국내 웹 기술 발전을 가로막는 적폐라고 비난하는 목소리가 생겼는데, 사실 전자정부표준프레임워크 입장에선 억울한 면이 없잖아 있다. 정부에서 Java/Spring을 표준으로 정해서 Java/Spring의 위치가 견고해진 면이 없지는 않지만, Spring 자체는 세계 기준으로 봐도 여전히[2] 메이저한 기술 스택이고, 지속적으로 업데이트가 있어왔기 때문에 다른 핫한 최신 프레임워크들과 비교해도 그다지 후진적이라고 보기는 어렵다.애초에 근본적인 문제는 기형적인 국내 SW 산업 구조 자체에 있다. 정부 주도 프로젝트에 과도하게 의존하는 다수의 SI업체엔 민간 서비스 기업 수준의 SW 품질을 달성하려는 의지 자체가 없다. SW 품질이 수익과 직결되는 민간 IT 서비스 기업과는 달리, 최소한의 기준만 맞추면 끝인 중소 SI업체에서는 최신 기술을 도입할 필요도 없고, 비싼 연봉을 지급해 가며 뛰어난 개발 인력을 고용할 필요도 없다. 변화를 거부하는 게으른 개발자들을 데리고 구닥다리 기술만 주구장창 써먹더라도 살아남을 수 있는 기형적인 구조인 것이다. 전자정부표준프레임워크를 이용해서 SW 개발을 하는 것이 주로 이런 업체들이기 때문에 오명이 생긴 것이라고 봐야 한다.[3]
3. 문제점과 논란
3.1. 자바 공화국의 원흉
국내 웹 백엔드 개발에 있어서 Spring은 사실상 표준으로 사용되고 있으며, 다른 어떤 기술 스택과 비교하더라도 압도적으로 높은 점유율과 일자리 수를 자랑한다. 심지어 네카라쿠배조차도 Spring을 쓰지 않는 회사가 오히려 손에 꼽을 정도다. 해외에서는 이미 Node.js나 Python 기반 웹 프레임워크의 점유율이 상당한 수준이다. 스프링 자체는 여전히 인기 있는 프레임워크지만 해외에서는 스프링을 쓴다고 하면 십중팔구는 스프링 부트를 쓰지 생짜로 스프링을 쓰는 경우는 거의 없다. 게다가 언어 역시 스프링을 자바가 아닌 코틀린 등의 JVM 호환 언어로 사용하는 사례가 점점 늘고 있다. 스프링 부트 역시 코틀린을 공식적으로 지원한다.[4][5]전자정부표준프레임워크는 공공 기관 웹사이트 개발 과정을 표준화하기 위한 행정 편의주의에서 비롯되었는데, 그러한 의도로 인해 정부발 프로젝트에 기대는 SI 회사가 절대 다수를 차지하는 한국의 SW업계 자체를 똥통으로 만들어버렸다. 백엔드 프로그래밍을 한다는 것이 곧 자바를 한다는 것이고, 자바를 한다는 것은 스프링을 하기 위한 것이며, 스프링은 전자정부프레임워크를 사용하는 수단이 되어버린 것이다.
정상적인 관점에서 보면 프레임워크는 물론이고 심지어 언어조차도 수단에 불과하다. 제대로 된 개발자가 있고 설계가 확실하다면 생전 처음 보는 언어로 개발을 한다고 해도 어려움이 없어야 정상이다.
물론 배우는 시간이 필요한 건 어쩔 수 없다. 그러나 국내 개발자 중에서는 다른 언어를 논할 것도 없이, 같은 언어의 프레임워크는커녕 라이브러리조차 바꾸려 하지 않는 꼰대 개발자가 상당히 많다. 예컨대 자바스크립트의 Angular/React/Vue 프레임워크를 할 줄 아는 개발자에게 Svelte 결과물을 요구하면 “왜 Svelte를 써야 하느냐”라는 반문이 돌아오는 게 현실이다.
다만 여기서 한 가지 짚고 넘어갈 점은, 현실적으로 Svelte 같은 상대적으로 마이너한 라이브러리를 채택함에 있어서, 아니, 라이브러리와 코딩을 떠나서 굳이 프로그램 짜는 게 아니더라도 모든 기술에 대해서 러닝 커브를 감수하고서라도 도입하는 것을 납득할 만한 기술적/경제적 이득이 있는 지 따져보는 건 지극히 타당하고 당연한 논리이기에[6], 서비스하는 입장에서 해당 기술이 제공하는 이점의 가치보다 재교육을 위한 시간/비용이 더 크게 든다고 판단하거나, SI업종에서 전체적인 시장 트랜드와 단가를 따져봤을 때 굳이 리스크를 감수해 가면서까지 잘 모르는 기술을 요구하는 프로젝트를 수주하는 게 이득이 되지 못한다면 해당 기술을 배제하는 것도 당연하고 타당하며 합리적인 논리이다. 어차피 해외에도 Major와 Minor 스택의 선호도 차이와 타 스택에 대한 배타성은 엄연하게 있다. 물론, 서비스 회사는 기술 도입에 있어서 조금 더 급진적인 경향이 있지만, 자기가 스스로 만든 소프트 가지고 스스로 B2C로 밥벌이하는 서비스 회사랑, 납품하고 유지 보수 계약 기간 지나면 떙인 SI의 차이일 뿐이다. 이건 외국도 똑같다.
국내뿐만 아니라 해외에서도 소프트웨어 엔지니어링 전공 과정에서 엄연히 교육하는 주제이며, 서비스가 아닌 SI나 솔루션의 경우 해외에서도 사실 기술 스택 채택에 있어서 모험적인 시도를 잘 하지 않는 편이다. 사실 당연한 게 인하우스 자체 운영 목적도 아니고 하도급 납품 계약으로 딱 픽스해 놓고 만드는 입장에서 시장 트랜드가 확 엎어져서 더 이상 일거리 거의 못 받을 정도로 구닥다리가 아닌 이상(한국으로 치면 레거시 PHP나 아예 벤더에서 강제로 숨통 끊어놓은 Flash 정도) 계약 조건 위반으로 돈을 토해낸다는 최악의 결말을 유발할 수 있는 비숙련 기술의 무작정 도입에 대한 리스크를 감수해야 할 이유가 없다. 개발자는 코드로 말한다지만 일부 프리랜서나 경영에 대한 일부 의사 결정권을 가진 서비스 회사 팀장/임원(CTO)급 아닌 이상에야 결국에 개발자이기 이전에 회사원이고 밥벌이다. 그리고 회사원은 실적으로 말하고 밥벌이는 원천 징수 소득 금액과 직무 안정성으로 말한다.
문제 되는 건 일부 고령의 한국 개발자들은 이런 안정성 추구가 너무 지나치다는 것과, 국내 IT 시장은 SI 및 공공 조달 비중이 지나치게 높다는 것이다. 사실 이것은 종신 고용 시절의 잔재를 치우고 노동 유연화를 위한 개편(사회 안전망 확충, 비정규직의 유연성에 대한 가치 반영, 해고 및 채용의 유연화, 창업자의 보호와 활성화, 중소기업 노동자의 처우 개선과 중소기업 자체에 대한 지원, 규제 철폐 등)은 미처 하지도 못하거나 미흡하게 한 주제에 반쪽짜리 비정규직이나 포괄 임금제 같은 노동자를 쥐어짜는 부작용을 수반하는 서구식 제도만 무리하고 어설프게 도입해 버려 노동 유연화의 장점은 전혀 살리지 못한 채로 단점만 잔뜩 유발하여 노사 갈등, 민관 갈등만 왕창 키워 사업자 입장에서는 신규 창업은 물론 기존 중소기업들의 성장과 신사업 개척 의지까지도 다 꺾어버리게 만들고 노동자 입장에서는 다른 건 다 쓰레기통에 갖다 처넣어서라도 보신주의와 직무 안정성에만 집착하게 만들어버린 한국 경제와 노동 시장 자체의 문제이기도 하다. 한마디로 30살 넘어서 짤리든가 사업 망하면 사장이건 직원이건 사이좋게 굶어 죽어야 하는 창업/노동 시장을 만들어 놓고 안정성 추구를 못 하게 하면 뭘 어쩌란 말인가?
해서 객관적으로 보았을 때 FE를 예로 들면 관련 정보에 대한 접근성이나 커뮤니티 수준, 단가와 납기, 리스크 수준 등을 고려했을 때 Svelte 같은 건 팀 상황에 따라 합리적으로 거부할 수 있고, 그렇다고 해서 무작정 꼰대라고 보긴 어려운 점도 있다. 하지만 차세대나 신규 개발 프로젝트에 특별한 사유 없이 현용으로서는 이미 Deprecated(도태)된 기술들을 고집하면 그건 꼰대라고 부를 수 있다. 예를 들면 PHP 5 버전이나 Java 6, Java 8을 고집하면서 계약 조건 등[7] 별다른 외적인 이유 없이 SPA를 거부하는 웹 개발자나, Vue 3이 나온 시점에서 Vue 1.x 초기 버전에 라이브러리도 특정 버전만을 고집하면 계약 조건 또는 납품 기한, 인력 사정 등의 외적인 제약이 없는 이상[8] 꼰대가 맞다.
결론적으로 전자정부프레임워크 말고는 아무것도 할 줄 모르는 일부 구세대들이 SI 시장의 기득권을 붙잡고 있는 한국에서는 일부 대기업/중견/신생 SI의 일부 프로젝트를 제외하면 신입들에게도 레거시만 사용할 것을 강요하며 발목을 잡는 상황이다. 이는 결국 국가 전체의 IT 경쟁력 저하로 이어지는 문제다. 다만 이건 노동자들을 때려잡아서 해결할 문제가 아니라 신규 SI/서비스업체를 키워서 아직도 신규 플젝에 Java 8, PHP, Spring 2~3, JSP, Struts 같은 거 고집하려 하는 몇몇 악성 업체들에 대한 자연 도태 및 세대 교체를 유도함과 동시에 장기적으로 민간 분야 솔루션/서비스 시장을 키워야 될 문제이다. 최소한 SI/서비스로 딱 양분되진 못하더라도 SI하는 회사들이 그거에만 안주하지 말고 신규 사업으로 서비스나 솔루션 사업에 투자할 만한 여건을 만들어 주는 것이 필요하다.
3.2. Java 저작권 문제
한때 Java 저작권을 가지고 있는 오라클이 JDK에 구독료를 도입한다거나, Java API를 사용하여 Android를 개발한 Google을 고소한다거나 하는 문제가 연달아 터지면서 Java 생태를 버려야 한다는 목소리가 나오기도 했다. 그러나 2023년 현재 시점에서는 대부분의 소동이 일단락된 것으로 봐야한다. 구글과의 소송에선 구글이 끝내 소송에서 승리했으며, JDK 유료화 역시 오라클 쪽에서 한발 물러난 모양새이다. Oracle이 쥐고 흔들기에는 Java 생태계가 너무나도 커져버렸기 때문이다. Oracle JDK 이외에도 Amazon 같은 굴지의 IT 대기업에서 개발하는 JDK 구현체들이 등장했으며 많은 수가 무료로 공개된다. 몇몇은 심지어 공식 버전보다 더욱 긴 기술 지원 종료 시점을 공표하고 있기도 하다. 이후에는 Oracle이 Java EE를 포기하고 이클립스 재단에 프로젝트를 이관하는 등 점차 Java를 놓아주는 모습을 보이고 있으니, Oracle의 위협은 점점 가능성이 떨어지는 시나리오가 되고 있다고 봐도 된다.3.3. SI업계의 문제점
결국 근본적인 문제점은 SI 쪽으로 편중된 한국의 S/W 시장에 있다. 어지간한 대기업이 아니라면 SI를 빼고는 소프트웨어 사업을 벌이는 것이 힘들 정도로 우리나라의 시장 상황은 열악했다. 어느 나라든 관공서가 아닌 민간 시장을 대상으로 자사 솔루션을 개발, 판매하는 기업들이 소프트웨어 시장의 기술 발전을 선도하는 편인데, 한국에는 이런 업체가 상대적으로 부족하다는 것이 근본적인 문제인 것이다.어찌됐건 전자정부프레임워크는 업계에 성공적으로 안착했고, 4.0에서는 스프링 5 기반으로 구성하였다. 스프링 5버전부터는 자바 8 버전 사용이 강제되지만 대부분의 SI 개발자들은 자바 7 이하만 사용하던 경험이 대부분이기 때문에 고착화되고 꽉 막힌 개발 환경은 앞으로도 계속될 것이며, 대체재 또한 없다. 그렇기 때문에 다양성이 죽은 SI 중심의 국내 개발 미래는 여전히 암울하고, 앞으로도 암울할 전망이다.
2022년에 출시하는 다음 버전은 스프링 부트를 수용하는 등 기술적으로 굉장히 많이 발전하고 간편해졌지만, 원본인 스프링은 같은 시기에 6.0 버전을 출시할 정도로 차이가 많이 벌어져 있다.[9] 스프링 부트는 스프링의 문제점으로 손꼽히던 프로젝트 세팅 문제를 매우 간편하게 제공하고 있는데, 부트 기반의 전자정부프레임워크가 출시된다 한들 스프링 부트가 주는 기술적 간편함을 누릴 수가 없다. 4.0부터 스프링 부트 기반의 전자정부 프로젝트를 지원하지만, 전자정부표준프레임워크의 핵심인 공통 컴포넌트를 사용할 수 없기 때문이다. 업계 특성상 군부대나 금융업계 등 일부 발주처는 자바 버전을 6 정도로 강제하는 경우라면 울며 겨자 먹기로 구버전을 사용할 수밖에 없다. 가장 큰 걸림돌은 윗자리에 앉은 늙은 퇴물 개발자의 고집 때문인 경우이다. 극악의 워라밸에서 살아남은 구시대의 SI 개발자들은 기술적 발전보다는 익숙함과 생존을 선택하며 신기술을 거부하는 경향을 보이고 있다.
2015년에 출시한 자바 8을 이제서야 강제하다시피 사용하게 만든다는 점도 큰 아이러니이다. 스프링 5.0은 2017년 출시되었으며 시장에 안착되는 데에 2년 정도의 시간이 소요되었다. 이를 감안하면 아직도 자바 7↓, 스프링 5.0↓를 사용하는 SI의 현실이 암울하지 않은 게 이상할 정도인 셈이다.
가장 큰 문제는 구버전에만 있는 보안 취약점이다. 자바가 오래된 언어인 만큼, JVM 자체의 알려진 보안 취약점만 해도 다 적기엔 여백이 없을 수준이다. Log4j 보안 취약점 사태 때 크게 논란이 되기도 했다.
전자정부표준프레임워크는 태생적인 특성으로 인해 공공사업에 주로 도입되고 있는데, 일반 사기업(대기업 포함)들의 경우 초기 출시 동안에는 행정 편의 및 유행에 편중하여 많이 도입했었으나, 많은 이슈 또한 떠안게 되어 컨트리뷰터의 느린 패치 속도와 불안정함에 한계를 느낀 이후 로는 사기업이 전자정부를 도입하기보단 간편한 세팅과 안정성, 유연한 확장성까지 혜택을 주는 스프링 부트를 쓰는 추세다. 전자정부표준프레임워크의 기본적인 세팅 특성상, 각 부처 홈페이지들의 URL 패턴이 동일한 이유는 과거 Struts 시절의 기존 서블릿 충돌을 막기 위해 공식 채택된 확장자
.do 사용이 시니어 위주로 고착화되어 사용된 것. .do 를 쓰지 않았던 공공 데이터 또한 리뉴얼 이후 다시 .do 확장자를 쓰기 시작하는 등 완전히 고착화되어, 이젠 개발 패턴을 벗어나면 계약 위반이란 위험 부담까지 떠안게 되는 지경까지 이르게 되었다. 게다가 유연하지 못한 예산으로 정해진 개발 일정과 사후관리 편의에 치중하다 보니, 예산이 많이 책정된 대규모일 경우 넥사크로 및 웹스퀘어 같은 정해진 RIA 솔루션, 예산이 부족할 땐 SI 개발 주요 커뮤니티에서는 전자정부 프레임워크 4.0에 포함된 React UI에 대한 우려 사항이 많이 나오고 있다. 분석-설계-구현-테스트-오픈, 디자인-퍼블리싱-웹 개발-백엔드 연동 등 공정별 세분화된 영역별로 엔지니어가 투입되는 SI 시장에서 React로 UI로 개발하면 퍼블리셔가 작업한 HTML을 웹 개발자가 React 문법에 맞게 HTML 파일을 재수정하기 때문이다. 하지만 다행인지 우려인지 공공의 React 구축 사례는 현재까지 없다. 물론 있을 수가 없지만. 실제로는 표준에는 React.js가 탑재되어 있으나 프론트엔드 개발자-백엔드 개발자로 인력 구분을 하기보다는 UI 퍼블리셔-풀스택 웹 개발자 형태의 구성이 많기 때문에, 이런 식의 협업이 유리한 Vue.js 쪽을 많이 사용하는 형태로 바뀌어 가고 있다. 네이버와 삼성SDS의 성공 사례도 있고. 현재로서는 SPA를 사용하는 국내 SI 한정으로는 오히려 Vue.js로 소폭 기울고 있으나, JSP+JQuery로 꿋꿋이 버티는 낡은 SI업체들도 여전히 많고, 서비스와 솔루션 기업을 중심으로 React.js도 꽤 사용한다. 결론적으로는 백엔드보단 생각보다는 편중이 없는 셈. 사실 당연한 이유가 Spring 및 그로부터 파생된 전자정부프레임워크, Spring Boot는 셋 다 쓸 수 있다. React.js 및 Vue.js 연동 매뉴얼을 다 제공하고 있고, JSP 방식은 옛날에 하던 대로 하면 되니까….
[1] 스프링이 처음 발표된 것은 2003년으로, 전자정부프레임워크가 발표된 시점은 스프링이 처음 생긴 지 6년밖에 지나지 않은 시점이었다. 정부 주도 사업에 존재하는 오버헤드를 감안하면 그보다 몇 년은 앞서서 스프링을 검토하기 시작했을 테니, 선구적인 결정이었다고 봐도 된다.[2] 2023년 기준[3] Java 생태계의 강력한 Legacy 지원이 한몫하기도 했다. 최신 버전 Java에서도 20년 전 구닥다리 코드가 잘만 돌아가다 보니 변화를 거부하는 게으른 개발자들은 문제의식 따위 없이 20년 전 방식 그대로 프로젝트를 설계하고 코드를 작성한다. 애초에 객체 지향조차 잘 모르고, 조금이라도 복잡하다 싶은 비즈니스 로직은 수백 줄이 넘어가는 SQL 쿼리로 해결한다. Java의 이점조차 전혀 살리지 못한다는 것이다.[4] 다만 아직까지는 주류가 코틀린이라고 하기는 어려운 상황이다. 대부분의 Spring 생태계가 아직 자바를 기반으로 작성되었으며, 결국에는 자바 바이트코드로 변환되어 JVM 위에서 실행되기 때문에 코틀린을 사용한다고 해도 자바를 잘 알아야 한다.[5] 그리고 현실적으로 안정성과 공공 발주처 입장에서의 호환성 때문에 전자정부 사용을 강제로 요구해서 그런 거에 가깝지 서비스나 솔루션 등 공공 납품이나 레거시 유지 보수와 관련 없는 시장에서는 우리나라도 스프링보다 스프링 부트를 더 많이 쓰기 시작하는 추세이다. 서비스나 솔루션은 Node.js 기반이랑 스프링 부트랑 대략 1:2 정도 비중이다. Python은 SPA 시대에 아직까지도 템플릿 엔진이 베이스인 Django는 해외에서도 낡았다는 평을 듣는 편이고, Flask는 그 자유도가 오히려 유지 보수성에서 발목을 잡아버린다는 문제가 있다. 네카라쿠배 같은 데서는 코프링도 많이 쓴다. 어차피 해외도 상위 3개 스택이 시장 대부분을 먹는 건 공통적으로 나타나는 현상이고, 한국의 레거시 이슈는 전자정부 문제라기보다는 지나치게 높은 SI 비율과 공공 조달 시장의 비중이 원인이다.[6] 예를 들어 단순히 1층짜리 단독 전원주택 하나 짓는 데 있어서 200층 넘어가는 롯데월드타워에 적용된 최신 공법을 반드시 적용해야 할 이유는 없다. 오히려 개 발에 편자, 돼지 목에 목걸이라고, 고작 단독 주택 짓자고 그런 기술 준비하는 게 더 비효율에 가깝다.[7] 재교육에 소요되는 기간을 감안했을 때 납기가 지나치게 빡빡하다든지, 인력상의 여유가 없다든지, 다른 익숙한 일감 널리고 널렸는데 단가 면에서 메리트가 없다든지, 아예 발주처에서 일부 기술의 사용 여부를 지정했다든지 등[8] 이것도 중요하다. 생소한 기술을 요구하면서 재교육을 위한 충분한 시간과 비용을 제공하지 않는다면 PM의 성향에 따라서 도전은 해 볼 수 있겠지만, 익숙한 기술을 요구하는 다른 일감이 있으면 안 하는 게 이상할 것은 없다. 막말로 투입 인력과 기간 딱 픽스해 놓고 계약하는 와중에 버그 왕창 나고 제시간 안에 다 못 고치면 얼리 어답터들이 다 물어줄 건가? 아무리 뛰어난 개발자라도 처음 만지는 기술은 시행착오를 겪을 수밖에 없다. SI/솔루션 납품 계약 조건이나 서비스 런칭 로드맵이 그러한 시행착오를 허용하지 않는다면 소속 개발자 입장에선 안 하는 수밖에 없는 거고. 같은 시간에 같은 돈 벌 수 있고, 앞으로 시장 변화 면에서 그리 뒤처질 거 같지 않다고 판단되면 익숙한 걸 하는 것도 경제/경영적으로 타당한 운영법이다. 반면 시장의 흐름이 점차 변화하거나 국제적인 트렌드와 일정 이상 괴리가 생겨 이슈가 되는 일이 하나둘씩 늘어난다면 그때는 잠깐 휴식기를 가져서라도 미래를 위해 투자해야 겠지만 말이다.[9] 스프링 6은 자바 17 이상에서만 동작한다. 대부분의 SI 개발자는 자바 8에 익숙하지 않다는 걸 생각해 보면 SI와 비SI 사이에는 어마어마한 기술적 간극이 존재한다.