자바 스프링이 대세가 된 과정에 대해

오래된 이야기이고 저도 개발 경력이 많지 않은 시절 직간접적으로 경험한 것을 토대로한 내용이기 때문에 어쩌면 다소 주관적이거나 부정확한 내용이 섞여 있을 수도 있음을 양해하고 봐주시면 좋겠습니다.

일단 자바라는 언어 자체가 어떻게 대세가 되고 다시 기업 시스템이나 안드로이드 같은 일부 분야를 제외하고 몰락하게 되었는지에 대해선 다른 글에도 적었으니 다시 적지 않겠습니다. 관심있으신 분들은 아래 글을 참조하시기 바랍니다:

• 데스크탑 자바가 몰락한 이야기
• 자바가 아닌 다른 언어를 배워야 하는 이유
  
  

대신 이번 글에서는 순수하게 지금 우리나라에서 자바가 아직 굳건하게 버티고 있는 기업 시스템 분야에서 어떻게 대세가 되었는지에 대해서만 간단하게 이야기를 해보려고 합니다.

90년대 말에서 2000년대 초반은 막 우리나라 기업들이 인터넷 시대를 맞아 기존 전산 시스템을 개편하기 시작한 때입니다. 정부에서도 IT를 정책적으로 적극 밀어주기 시작해서 갑자기 관련 기술에 대한 수요가 폭발적으로 늘어나게 됩니다.

이 때 자바가 주력으로 자리 잡은 것은 이상할 것이 없는데, 이는 당시엔 해외에서도 자바가 막 전성기에 접어든 시점이었기 때문입니다. 다만 그 때 해외에서 자바를 도입하는 큰 기업들과 우리나라의 경우 기술 환경엔 꽤 차이가 있었습니다.

당시엔 객체지향 패러다임의 위상이 거의 절대적이었고, 미국의 경우 크고 복잡한 시스템을 객체지향으로 설계할 수 있는 능력을 지닌 아키텍트들이 상대적으로 많이 활동하고 있었습니다.

그리고 자바는 그런 아키텍트들이 저수준 계층이나 특정 벤더의 제품 특성에 구애받지 않고 고도의 추상적인 객체지향 시스템을 설계하는데 최적화된 도구였습니다.

물론 미국이라고 틀에 맞춰 페이지 찍어내는 식의 개발을 안했던 건 아닙니다만, 왜 그런 틀을 그런 식으로 만드는 지에 대한 문제를 고민하고 흐름을 만들 수 있는 아키텍트나 컨설턴트에 대한 수요나 공급은 부족하지 않았습니다.

그리고 자바의 전성기와 함께한 EJB, 그리고 J2EE 어플리케이션 서버의 인기는 바로 그런 사람들이 만들었던 현상입니다.

그런 아키텍트들이 원했던 건 기업의 모든 업무를 잘 짜여진 객체지향 API의 집합으로 표현하는 것이었는데, 이를 위해 필요한 보안이나 트랜잭션, 메시징, 스케줄링 등 필요한 자원은 마찬가지로 잘 짜여진 객체지향 API의 형태로 추상화되어 제공 받기를 희망했고, 그걸 실현한 것이 웹로직이나 웹스피어 같은 이른바 "풀스택 J2EE 컨테이너", 혹은 'WAS'의 역할이었습니다.

여기서 해외, 특히 미국과 당시 우리나라 상황의 간극이 있었는데, 우리나라의 경우 그런 객체지향 설계를 전문으로 하는 아키텍트 집단이 존재하지 않았거나 있더라도 시장을 형성하고 이끌어갈 수준이 되지 못했습니다.

하지만 앞서 말했듯 우리나라에서도 기업들이 앞다투어 전산 시스템을 웹 기반으로 개편하기 시작했고, 당연히 해외에서 유행하는 J2EE라는 대세를 따르게 됩니다. 문제는 EJB가 좋다니까 도입했고, WAS가 필요하다니 샀는데 이걸 왜, 어떻게 쓰는 지는 몰랐다는 것입니다.

지금도 그렇지만, 당시에도 우리나라엔 객체지향 전문가는 드물어도 데이터베이스 전문가는 부족하지 않았습니다. 대부분의 큰 기업에선 잘 짜여진 스키마로 구축한 데이터베이스가 전산 시스템의 핵심이었고, 이를 설계하고 개발할 인력은 상대적으로 많았기 때문에, 새로 도입하는 자바 J2EE를 이용하는 프로젝트도 그런 사람들이 주도하게 됩니다.

그래서 탄생한 것이 지금도 아마 대부분의 국내 프로젝트들이 따라하고 학원에서도 공식처럼 가르치는 다계층 구조의 설계 패턴과 데이터베이스 중심 개발의 묘한 조합입니다.

다들 아시는 DAO/VO/Service/ServiceImpl/MVC로 구성된 다계층 구조 설계 자체는 해외에서도 널리 쓰이는 내용이긴 합니다. 아마 당시에 우리나라에서 베껴와서 '표준화'했던 것이 그런 구조를 택한 J2EE의 펫스토어(PetStore) 예제였을 건데, 문제는 그 틀은 가져왔지만 그 안에 채워 넣는 설계 관행이나 사상은 배우지 못했다는 것입니다.

즉, 외국처럼 기업 시스템을 잘 구조화된 객체지향 API로 뽑아 내기 위해 그런 틀을 도입한 것이 아니라, 일단 틀이 좋다니까 베껴왔는데 아는 것은 데이터베이스 밖에 없으니 객체지향 설계를 생략하고 그냥 그 위에서 SQL 날려서 데이터 가져오고 어떻게 해서든 화면 만들어 뿌리는, 3티어의 복잡함과 2티어의 지저분함을 결합한 이상한 한국형 설계 관행이 탄생하게 됩니다.

그 와중에 EJB의 인기가 시들해지고 해외에서도 스프링이 유행하자 우리나라도 그 흐름에 동참하게 됩니다. 그 전에 유행하던 스트러츠는 당시까지만 해도 순수하게 MVC 계층만 제공했을 뿐이고, 가뜩이나 J2EE의 극히 일부만 활용하던 상황에서 EJB를 안 쓰게 되니 스프링이 있으면 더 이상 비싼 WAS를 살 이유가 없다는 것도 늦게나마 깨닫게 된 결과이기도 했습니다.

물론 여전히 '한국형' 개발은 결국 데이터 뽑아서 어떻게든 화면을 만든다는 걸로 요약되는 것이라, 스프링에서 필요한 기능은 트랜잭션 관리하고 MVC 처리하는 부분을 제외하면 거의 없었습니다. 스프링 시큐리티 같은 게 관심을 받게 된 건 상대적으로 꽤 최근의 일입니다.

사실 그렇게 비즈니스 로직을 객체지향이 아닌 SQL로 대체하고 어떻게든 화면을 만들자고 생각하면 펫스토어 방식의 다계층 설계가 최적이라고 하기 어렵습니다. 그리고 애초에 펫스토어 예제 자체도 오버엔지니어링 경향이 있는 객체지향 아키텍트들이 객체지향 시대의 정점에서 J2EE 기술에 대한 쇼케이스 목적으로 최대한 유연한 설계를 보여주기 위해 만든 것이기도 합니다.

하지만 우리나라 시장에서 필요했던 건 막 폭발적으로 증가하던 웹 개발 수요를 채울 수 있는 적당한 수준의 개발자를 대량 양산할 수 있는 시스템이었고, 무엇보다 그런 개발자들이 따라하면 최소한 중간은 갈 수 있는 '검증된' 틀이었습니다.

그래서 애초에 예제 목적으로 만들어진 펫스토어 설계가 절대 불변의 진리처럼 굳어지게 된 것이고, 해외에서 도메인주도 개발이니 메시징 기반 시스템이니 마이크로 아키텍쳐니 하는 새로운 흐름이 뜨고 지는 건 무시한 채로 모든 시스템을 무작정 펫스토어 빵틀에 대고 찍어 내서 만드는 기형적인 관행이 자리 잡은 것입니다.

아키텍쳐야 닥치고 스프링/펫스토어니 고민할 필요가 없고, 시스템 설계는 디비 스키마와 SQL 짜는 걸로 대체해버렸으니 그와 관련없는 기술 동향의 변화가 의미가 없어진 상태에서 남은 건 그냥 똑같은 스프링MVC 기술자의 경력과 단가를 따지는 일 뿐입니다.

그게 십 년 이상 이어지면서 개발 환경은 어떻게 하면 전자정부 프레임워크 같은 걸 통해서 스프링MVC 로 정해진 틀에 맞게 최소한의 노력으로 최대한 균질한 결과를 얻는 방향으로, 그리고 시장은 국비학원 등을 통해 그런 프로젝트에 최적화 된, 오직 그런 프로젝트에서 만 일할 수 있는 인력을 최단 기간에 양산하는 방향으로 최적화 한 결과가 지금의 우리나라 SI 시장의 모습입니다.

문제는 그 동안 해외 기술 환경이 우리가 박제해서 공식화 한 개발 관행이 득세하던 시절에 비해 크게 바뀌었다는 점인데, 설계 패러다임 같은 것이야 어찌됐건 결과만 뽑으면 무시할 수 있다 쳐도, 당장 클라이언트의 눈에 보이는 프론트엔드 관련 기술이나 비용과 직결되는 클라우드 관련 환경의 변화는 언제까지나 무시할 수 없다는 것입니다.

당장 오키만 해도 한 5년 쯤 전에는 프론트엔드나 클라우드 관련 이야기는 거의 나오지 않았지만 지금은 구인구직란에서도 관련 키워드를 검색하면 꽤 많은 게시물을 볼 수 있습니다.

그렇게 보면 앞으로 5년, 10년 뒤에 시장의 수요가 어떻게 변화할지는 분명한데, 과연 그 때도 여전히 '빵틀'을 만들어서 동일 구조의 프로젝트를 찍어내는 '한국형' 개발이 유효할지, 그게 통한다 쳐도 과연 지금의 인력 공급 구조나 이를 통해 배출된 스프링 빵틀 전문가들이 새로운 빵틀에 쉽게 안착할 수 있을지는 한 번 쯤 고민해볼 문제라고 생각합니다.