fender
21k
2021-01-29 04:40:59 작성 2021-02-01 12:38:34 수정됨
26
8139

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


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

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

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

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

51
29
  • 댓글 26

  • 천사와악마
    968
    2021-01-29 08:56:58

    스트러츠 쓸때나 기타 다른 프레임웍이 존재할때도 구조는 비슷했습니다 그때는 시키는데로 만들때라 고민조차 하지않았을때긴 하지만요

    서블릿은 거들뿐인 프로젝트가 많았죠 몇백줄 되는쿼리와 sp 가 핵심이던 시절

  • fender
    21k
    2021-01-29 09:01:50 작성 2021-01-29 09:06:22 수정됨

    천사와악마 // 스프링 전의 스트러츠는 1.x는 순수하게 MVC 프레임워크였습니다. 그래서 본문에서 언급한 이른바 "펫스토어 틀"이라는 걸 적용하는 것이 불가능했습니다.

    다만, 그 때도 모델2니 뭐니 객체지향 설계는 안하면서 굳이 빈에 코드를 분리하는 관행은 있었던 것으로 기억합니다.

    그래서 큰 틀에서 보면 비슷한 구조이긴 한데 그래도 오늘 날 다들 학원에서 배우는 틀과는 좀 차이가 있습니다.


    여담이지만 다른 프레임워크 중에 이상하게 우리나라에서만 유행이 빗겨간 JSF나 위켓 부류의 컴포넌트 중심의 접근도 있었습니다. 특히 JSF는 어쨌거나 자바에서 공식으로 밀던 웹개발 프레임워크라 외국에선 나름대로 쓰긴했는데 우리나라에선 존재 자체도 모르는 분들도 많을 정도로 무시했던 기억이 납니다. 

    결과론적으로 프론트엔드 덕에 MVC는 살아남았고 서버측 컴포넌트 개발은 죽었으니 꼭 나쁜 결과는 아닌지도 모르겠습니다.

  • illuza
    53
    2021-01-29 09:03:55

    좋은 글 잘 읽었습니다.

    말씀하신대로 DB가 중심이다 보니 스프링이나 개발 언어는 단순히 Sub로서 DB 처리를 support해주는 수준 정도로 이해하고 있는 사람들이 많죠... 그리고 이건 비개발자 뿐만이 아니라 개발자들도 많이들 그런 식으로 프로그래밍을 합니다.

    사실 DB가 중심이다는 생각 자체는 틀린게 아닙니다. 당연히 도메인 데이터를 담고 있는 DB가 가장 중요하죠. 단지 거칠게 DB 쿼리로 막 다룰 것인가 아님 레이어를 집어넣어서 좀더 객체지향적으로 다루어 볼까 라고 고민을 할 수가 있습니다.

    다만, 그 전에 짚고 넘어가야할 점이 보통의 개발자들은 해당 도메인에 대한 지식이 거의 전무하기 때문에 DB를 구성하는거 자체가 쉽지가 않습니다... 더군다나 개발 일정도 항상 촉박하고.

    그러한 배경이 있기 때문에 아무래도 소프트웨어 자체의 기술 구현에는 소홀해질 수 밖에 없다고 봅니다.

    (하나만 덧붙이자면, 다른 사람의 코드를 이해해야하는 상황에서, 그 코드 작성자가 나름대로 객체지향적으로 짜놓으면 솔직히 이해도 확 안 와닿고 힘들어집니다... 물론 그 작성자가 진짜 제대로 잘 만들었으면 보고 배우는 과정에서 참을 수가 있는데 대개는 어설프게 해놓죠.)


  • fender
    21k
    2021-01-29 09:18:23 작성 2021-01-29 09:38:27 수정됨

    illuza // 그 부분은 이야기를 하자면 꽤 길어지는데, 요약해서 말하자면 디비 중심적 접근이 틀린 건 아니지만 굳이 따지자면 그건 예외적인 경우이고, 적어도 당시 J2EE의 경우는 객체지향을 중심으로 발전했다고는 할 수 있을 듯 합니다.

    단적으로 ORM을 보면 그런 도구는 J2EE 이전부터 존재했고, EJB 시절에 와서도 CMP라는 이름으로 중요한 한 축이 되고, 또 하이버네이트/JPA로 이어지면서 전통적 객체지향 아키텍트들에게 꾸준히 관심을 받아 왔지만 사실 우리나라처럼 디비 스키마를 최대 공약수로 두고 각자 알아서 화면 어떻게든 만들어 붙이는 데이터베이스 중심 접근에선 쓸만한 물건이 못되기도 합니다.

    기본적으로 관점 자체가 다를 수 있는 것이, 국내 환경에서 대부분의 기업 시스템의 핵심은 디비 스키마이고, 그 위에 올라가는 단위 시스템은 엎어지고 새로 만들고 하는 '껍데기'에 가까운 반면에, J2EE에서 유행하던 객체지향 시스템의 핵심은 프로그램 API이고 디비 스키마는 자동생성해서 전문가에게 넘기면 튜닝해주는 그런 정도 위상으로 보는 경우도 많습니다.

    본문에도 언급한 객체지향에 익숙한 아키텍트나 고급 개발자의 저변의 차이가 그런 관행의 차이로 이어진 것이 아닌가 싶습니다. 말씀대로 객체지향 설계라는 것이 패러다임을 이해하는 사람에겐 훨씬 깔끔하고 쉽지만 그렇지 못한 경우 프로그램을 "쓸데없이 복잡하게 만드는" 무엇이 되어 버리니까요.

  • B급 개발자
    808
    2021-01-29 09:31:27 작성 2021-01-29 09:32:05 수정됨

    클라우드니 MSA니 새로운 빵틀이 만들어지고 있는 현장에서 부대끼는 일인으로서 말씀하신 "스프링 빵틀"은 이미 과거형이 되어가고 있는 것 같다 라고 살짝 생각해 봅니다.

  • 74794C6565
    8k
    2021-01-29 10:07:32 작성 2021-01-29 10:07:50 수정됨

    빵틀ㅋㅋㅋㅋㅋ

    재밌는 표현이네요

    1따봉 드립니다.

  • 아오리사과
    971
    2021-01-29 10:39:17

    오랜만에 예전 이야기를 보니 재미있네요

    그런데 Java가 지는 추세라고는 하지만

    그보다 오래된 C가 전세계적으로 아직도 가장 많이 이용되고 있는

    언어라는 사실은 여전히 영향력이 있듯이 Java도 C만큼의

    롱런을 앞으로도 계속 할것으로 판단됩니다.

    성능적인 부분은 이미 한계에 도달하여 GraalVM이 나오고 있지만

    쓰임새에 있어서는 여전히 C와 Java는 전세계적으로 

    올해 이번달(2021년 january) 에도 C가 1등이네요


    https://www.tiobe.com/tiobe-index/

  • 피자7
    656
    2021-01-29 10:54:25

    요약좀

    -8
  • 마니
    2k
    2021-01-29 10:55:14

    오전부터 재밌는 글 잘 읽었습니다.. 

    글 자주 써주세요 ㅠㅠ 늘 재밌습니당

  • fender
    21k
    2021-01-29 10:59:44 작성 2021-01-29 11:04:38 수정됨

    아오리사과 // 자바가 상당히 오랜 기간 동안 서서히 지분이 줄어들 것이라는데는 이견이 없지만 C와는 조금 상황이 다르다고 생각합니다.

    C가 지금까지 확고한 지위를 유지하고 있는 것은 무엇보다 C가 아니면 안되거나 새로 프로젝트를 할 때 최소한 1순위 선택으로 고려할만한 분야가 있기 때문입니다.

    반면 자바의 경우 그런 확고한 자기 영역을 계속 다른 언어에 내주고 있다는 것이 가장 뼈아픈 부분입니다.

    2000년대 초반만 해도 자바는 데스크탑, 모바일, 게임, 임베디드 등 상당히 다양한 분야에 진출을 활발하게 모색했지만 결국 모두 실패하고 지금은 기업용 웹 시스템, 그리고 안드로이드라는 딱 두 가지 영역만 사수하고 있는 형국입니다.

    문제는 안드로이드는 오라클과 구글의 소송전과 코틀린의 등장으로 사실상 넘어가는 것이 시간 문제이고, 서버 쪽 역시 자바스크립트의 약진과 MSA 같은 보다 다원적인 아키텍쳐의 유행으로 전 만큼 입지가 확고하지 못하다는 부분이 아닌가 싶습니다.

    그런 면에서 전 자바가 생각보다 오래 가더라도 C와 같은 방식으로 계속 살아남을 가능성에 대해선 회의적입니다.

  • moonti
    3k
    2021-01-29 11:16:38
  • moonti
    3k
    2021-01-29 11:18:04

    https://kdw9502.tistory.com/7

    실제 프로젝트에 사용하는 언어순은 아닌것 같스니다만?

  • fender
    21k
    2021-01-29 11:20:45 작성 2021-01-29 11:22:16 수정됨

    moonti // 원래 언어 순위가 기준에 따라 달라져서 크게 의미를 두긴 어렵습니다.

    개인적으로 티오비의 경우는 특히 신뢰하지 않는데, 단적으로 VB6가 스칼라, 줄리아, 코틀린보다 한참 순위가 높다는 것만 보아도 개발자 커뮤니티의 체감과는 꽤 동떨어진 기준을 가지고 있음을 짐작할 수 있습니다.

    저는 그런 용도로는 스택오버플로나 깃헙의 연간 통계를 더 신뢰하는 편입니다.

  • fender
    21k
    2021-01-29 11:42:28 작성 2021-01-29 11:43:28 수정됨

    아이스파이어 // 더 중요해진다는 자체는 왈가왈부할 필요도 없이 분명한 사실로 간주해도 무방하다고 봅니다. 해외에서 이미 대세가 된지 한참 된 기술인데 우리만 눈감고 귀막고 무시할 수야 없으니까요.

    남은 문제는 얼마나 빨리 그 시점이 올 것인지, 그리고 그 와중에 기존 생태계에 얼마나 영향을 줄 지 정도가 아닐까 싶습니다.

  • Carefully
    386
    2021-01-29 14:24:59

    붕어빵틀...

  • SimonTR
    29
    2021-01-29 14:52:18

    좋은 글 감사합니다! ㅎㅎ 안그래도 왜 한국쪽에선 자바가 대세가 된건지 궁금했지만 단순히 전자정부프레임워크? 와 같이 정부주도의 인프라 구축때문에 그런거겠지 정도만 생각하고 있었는데 역사까지 디테일하게 알려주시니 좀 더 이해가가네요 ㅎㅎ

  • java칩프라푸치노
    496
    2021-01-30 07:24:03

    Java가 미래에 점점 위태해지면

    Java를 기반으로 SpringBoot를 이용하는 사람들은

    언어를 코틀린으로만 바꿔서 SpringBoot를 이용하면 살아남을수 있을지 궁금합니다

  • john911120
    15
    2021-01-30 12:46:08

    java칩프라푸치노

    코틀린으로 스프링부트를 할수 있나요? 코틀린은 안드로이드 개발을 위한 언어로 알고 있었어요 

  • 드루이드
    63
    2021-01-30 16:00:38

    코틀린은 범용 언어이고 Spring Boot 사용 가능합니다. 지극히 개인적인 생각이지만 몇년 전부터 많은 언어들이나 프래임워크 들이 새로운 버전을 내놓을때마다 Functional Programming 에 필요한 feature 들을 꽤 추가해 가는 느낌입니다. 완전한 Pure Functional Programming 이 대세가 되긴 아직 어려울것 같지만 OOP + FP 의 조합도 기대해 보고 있습니다. 

    아래 링크는 관심있으신 분들은 그냥 Spring에서는 이런식으로 할수 있구나 정도로 한번 보시면 좋을것 같습니다.

    Introduction to the Functional Web Framework in Spring 5 | Baeldung

  • 오키깡
    159
    2021-02-01 17:53:04
    위의 일들이 반복되면서 수년간 쌓인
    피보탈의 프로젝트가 엄청나게 많아보입니다


  • fender
    21k
    2021-02-01 18:32:23 작성 2021-02-01 18:33:56 수정됨

    오키깡 // 조금은 원론적인 이야기가 될 수 있지만, 크고 복잡한 소프트웨어를 만들기 위해서는 대체로 두 가지 정 반대의 접근을 생각할 수 있습니다.

    우선 어떤 공통된 관행을 따르는 통일성 있는 환경을 구축하는 방법이 있고, 다른 한 편에선 서로 느슨하게 연동하며 서로 부족한 부분을 다양한 구성요소로 생태계를 만드는 접근이 있습니다.

    그리고 지금 질문하신 내용과 연관지어 보면 J2EE는 전자의 방식을, 그리고 노드나 파이썬은 대체로 후자의 방법을 따라 발전하고 있다고 할 수 있습니다.

    서로 장단점이 있기 때문에 꼭 어느 쪽이 맞다 틀리다라고 할 수는 없는 문제지만, 확실한 것은 J2EE의 전성기와 비교하면 지금은 분명 시장의 흐름이 보다 다원적이고 느슨한 결합을 추구하는 방향으로 변하고 있다는 점입니다.

    큰 기업들이 모여서 회의를 해서 스펙을 정하고 벤더들이 구현을 만들고 하기 보단, 다양한 오픈소스 프로젝트가 경쟁하면서 생태계를 이루고 이를 취사 선택해서 심지어 언어조차 상이한 작은 서비스를 느슨하게 결합해서 연동하는 방식이 대세가 되었기 때문입니다.

    물론 그렇다고 스프링 부트나 자바가 그런 방식보다 못 하다고 볼 수 없고, 또 원한다면 스프링 부트 기반 마이크로 서비스 같은 것도 얼마든지 만들 수 있습니다.

    본문에서 이야기한 문제의 맥락에서 핵심은 자바나 스프링이 나쁘다 보다는, 더 이상 "닥치고 XXX" 하는 식으로 단일한 기술 환경의 설계 패턴까지 정해놓고 프로젝트 마다 똑같은 결과물을 찍어 내는 방식, 그리고 그런 작업에만 익숙해진 실무 개발자들이 변화한 환경에서 살아남을 수 있을지입니다.

    반면, 자바가 쇠퇴하고 있는 것은 분명하지만, 이는 자바나 스프링의 기능적인 한계보단 오라클의 행보 등 기술 외적인 여러 요인이 더 크게 작용한 결과라 생각해서 별개의 문제로 보아야 한다고 생각합니다.

    한 마디로 이래저래 자바에 미운털이 많이 박힌 마당에 기술 환경의 변화로 더 이상 자바를 꼭 써야할 이유가 줄어드니 다른 쪽으로 추세가 옮겨가는 모양인 것 같습니다.

    제 생각에 말씀하시는 이유로 스프링 부트가 최적의 선택이라고 판단하신다면 굳이 대세를 따라 다른 기술로 전환하실 필요는 없다고 봅니다.

    개인적으로 파이썬을 배운 것은 블렌더 관련 API와 머신러닝 쪽을 보기 위함이고 노드는 진지하게 개발해본 적이 없어서 말씀하신 내용을 충족하는 구체적인 라이브러리 같은 걸 소개해드리긴 어려운 점 양해 부탁드리겠습니다.

  • 오키깡
    159
    2021-02-01 18:45:38
    답변 감사드립니다
  • 몽달이
    1k
    2021-02-02 07:04:19

    fender님의 글은 항상 유익하고 재미있게 보고 있습니다. 이번 글도 추천드립니다

     

    눈팅만했는데 요즘 불면증이 온 탓에

    다른 주관적인 견해로 몇 줄 적어보도록 하겠습니다.

     

    1. 현재 빵틀(?)은 기형적 관행일까?

    2. Web서비스 분야에 5년 안에 많은 변화가 있을 것인가?

     

    > 현재 빵틀(?)은 기형적 관행일까?

    제가 web개발을 시작할 때에만 하더라도 우리나라에는 PHPJSP가 대세였고 PHP는 소규모 사이트, JSP는 대규모 사이트가 공식처럼 여겨져 왔습니다.(*PHP는 잘 몰라서 패스하도록 하겠습니다)

    2000년대 JSP개발자들은 MODEL1, MODEL2의 방식으로 개발을 진행했고 한 페이지 HTML, JS, JSP소스를 섞어 개발을 하게 되었습니다.

    또한 dbConnection같은 모듈은 java로 각자 만들어서 소스를 들고 다니기도 했죠.

     

    HTML/JS는 퍼블리셔가 JSP는 개발자가 작성을 했고 이렇게 작성된 MODEL1 화면은 관리에 어려움이 있었습니다.

    개발완료 후 퍼블 수정사항이 생기면 퍼블리셔가 개발소스까지 어느 정도 알아야 했죠

     

    이에 웹개발자들은 HTML/JSJSP를 분리하고 싶어졌고

    이후 개발자들은 다양한 방법으로 MODEL2를 이용하여 MVC패턴을 비슷하게 구현하기 시작합니다.

    실제로 제가 아는 분 중에는 서블릿으로 컨트롤러와 비즈니스(서비스), View를 분리하였고

    HTML파일을 렌더링 하여 화면단과 JAVA단을 분리하는 개발자도 있었습니다.

     

    그러다보니 개발자들은 각자의 공통 소스(DbConnection, 메시지처리, 에러처리, 트랜잭션 등)와 자신들만의 프레임웍(?)을 만들어서 갖고 다니게 되었고, 그런던 중 스트럿츠와 스프링 프레임워크을 알게 되었습니다.

    이후 관리자과 개발자들은 해당 기술 적용에 대하여 검토하기 시작했고 스트럿츠와 스프링을 도입하게 됩니다.

     

    관리자입장에서는 다양한 공통소스와 프레임워크를 통합할 수 있는 표준화방안으로 생각하였던 것이죠.

    그래서 처음 가장 많이 시도되었던 건 스트럿츠의MVC+IBATIS또는 (스트럿츠의MVC + 스프링 + IBATIS) 모델 이였습니다.

    스트럿츠의 MVC패턴도 좋았지만 Spring의 디자인패턴에 따른 개발 방식도 좋았기 때문이죠.

     

    이후에 스프링에서 MVC패턴을 제공함으로써 스트럿츠를 제거하고 스프링만을 사용하는 추세가 되었습니다.

     

    관리적인측면에서 스프링을 도입함으로써

    1. 개인별로 구현하던 프로그램구조의 정형화가 가능해졌으며

    2. 실력이 부족한 개발자들의 코드품질을 향상시킬 수 있었고

    3. 정형화가 되다보니 인력수급이 훨씬 수월해 진거죠

  • 몽달이
    1k
    2021-02-02 07:04:33

    이때부터 스프링은 우리나라에서 정착되어 정부전자프레임워크등 스프링기반의 프레임워크가 많이 사용되었던 것 같습니다.

    (* 개인적인 견해로는 정부전자프레임워크는 방향이 좀 잘못 되었다고 생각합니다.)

     

    이후에 개발자들은 스프링시큐리티나 스프링배치 등 많은 써드파티에 관심을 갖고 도입하게 되었습니다.

    (저는 스프링시큐리티를 6~8년 정도부터 도입을 했던 것 같습니다.)

     

    이후 스프링은 2.0 > 2.5 > 3.0 >>> 5.0 으로 발전하게 되고

    스프링설정이 최초 셋팅시 많은 시간이 소모되는 단점을 해결하고자

    spring boot 2.X도 등장하게 됩니다. 손쉬운 세팅으로도 web서버 빠르게 구축이 가능하게 된거죠

    * 예로 간단한 사이트는 spring boot를 통하여 1~2주정도면 개발이 가능합니다.

     

    한국의 개발자들이 패러다임을 주도하지는 않았지만 그렇다고 생각 없이 spring프레임워크를 도입하지는 않았을 겁니다.

    나름 한국형(?)WEB서비스구조는 많은 고민으로 탄생한 구조라는 거죠.

     

    > Web서비스 분야에 5년 안에 많은 변화가 있을 것인가?

    개인적인 견해로 앞으로 다른 언어들이 Web서비스에 진입할 것으로 생각하지만 Spring도 계속 발전하여 향후 10년동안은 우리나라 Web서버 분야에서는 가장 많이 사용되는 언어를 유지할 것 같습니다.

    다수의 대기업에서 이미 비용을 투자하여 자신만의 프레임워크(Spring 또는 java기반)을 만들어 사용을 하고 있고, 보통 대기업에서 시스템을 고도화하는 주기가 10년임을 감안했을때 10년 동안은 변화가 없을 것으로 예상되기 때문입니다.

  • yeori
    2k
    2021-02-03 15:18:56

    개발 관행(문화)의 문제와 프로그래밍 언어에 대한 평가를 교묘히 섞어서 주장하고 있음

    이분이 말하는 지점 대개가 사실상 한국적인 개발 관행의 문제인데 결론은 엉뚱하게 맺고 있음

  • fender
    21k
    2021-02-03 15:30:56 작성 2021-02-03 15:32:50 수정됨

    yeori // 자바의 문제가 전부 한국의 개발 관행 탓이라면 지금 국내보다 해외에서 자바의 인기가 높겠죠.

    그리고 본문은 자바 언어 자체에 대한 장단점을 따지는 내용도 아니고, 그건 제가 "자바 이외에 다른 언어를 배워야 하는 이유"라고 링크한 글에서도 마찬가지입니다.

    자바의 인기가 떨어지는 건 언어 자체가 아니라 기술 환경의 변화와 이미지의 문제입니다. 그리고 어떤 면에선 그게 훨씬 더 심각하고 극복하기 어려운 문제이기도 합니다.

  • 로그인을 하시면 댓글을 등록할 수 있습니다.