미국온지 한달이 넘었다. 그 동안 본사에서 질질 끌어온 일을 한답시고 이리저리 공부를 해 왔는데 정작 따지고 보니 내가 너무 완벽주의 혹은 제네럴 주의로 접근한게 아닌가 해서 잠깐 회고해 본다.
미국에 오기 전 까지는 그저 Spring F/W위에서, MyBatis와 Velocity와 함께 돌아가는 일련의 나의 고전적인 플랫폼에 만족했었다. 이를 굳이 바꾸고 싶지도 않았고, 그냥 서비스에 집중했다. 그러다 보니 사실 작업량이 좀 많아졌고, 생각보다 스프링 자체가 무거워지기도 했고, 4.1 이상을 사용하다 보니 설정도 잘 모르는게 많았고 신기술이 뭔지도 잘 몰랐다. 그저 웹소켓을 추후에 사용할 수도 있어서 선택한 플랫폼이었으니..
그러던중, 미국에 와서 숨돌리며 살펴본 개발 환경에는 특히 프론트앤드 환경이 너무나도 많이 변해있었다. 뭐 이와 관련되서는 지난 3일 작성한 글(http://matthew.kr/언제-프론트엔드-기술이-이리도-발전했던가/) 에서도 한번 밝히긴 했지만.. 솔직히 좀 크게 놀라기도 했고, 말로만 앵귤러~ 앵귤러~ 라고 들었지 정작 프론트엔드 환경에서까지 스프링처럼 DI로 인한 MV* 환경이 제공되는 줄 누가 알았으랴. 게다가 bower라는게 메이븐처럼 동작하니.. 테스팅에 의존성관리에 변경사항은 자동으로 웹브라우저에서 리로드 하고, 이렇게까지 개발이 편해질 수 있었을까.
그래서 백엔드조차 작년에 배워둔 노드로 가려다가 그래도 배워왔던 스프링에 대한 미련은 버리지 못해 최근 경량+Auto Configuration이 지원되는 Spring Boot로 갈아탔다. 그러다가 Spring Security를 알게되어 마침 Spring에서 제공하는 AngularJS + Spring Security 의 로그인 보안 설정이 있어서 이를 적용하자고 2주정도 삽질. 아무래도 스프링은 Embedded Tomcat위에서 Jar로, AngularJS의 프론트는 grunt를 통해 node.js에서 돌리다 보니 각각 포트가 다르게 된다. CORS(Cross-Origin Resource Sharing)에 대해서 거의 전무하다 싶었는데, 해당 정책에 따라 보안이슈가 엄청나게 갈리더라. 이거 설정한다고 몇일 삽질하고.. 또 스프링 시큐리티의 필터에 대해, CORS뿐만 아니라 CSRS이슈에 대해서도 뭐 이리저리 처리하다가 로그인시 서버의 토큰이 쿠키에 저장되서 이를 통해 Ajax 통신에서 헤더로 먹여줘야 하는 뭐 그런 이슈가 참으로 많더라. 한편으론 최근 Hibernate로 갈아타고, JPA에 대해 알게 되서 이놈이 얼마나 편한건지를 이제야 알게 되었다. Maven에서 Gradle로 갈아타고, Wrapbootstrap의 테마를 구매해 사용하였는데, 이 측면에서도 Grunt기반의 프로젝트가 있어 이를 사용하기로 하였는 등..
결국, 아직도 로그아웃 문제는 해결하지 못했지만 여기서 중요한 것은 서비스적인 측면에서 내가 개발한게 얼마나 될까? 이다. 그나마 본사에서 올해까지 시간을 줘서 망정이지, 아니었으면 나는 지금 짤려도 뭐라 할 말이 없다. 사실 로그인은 서비스의 가장 기본이기도 하지만 동시에 가장 중요한 부분이기도 하다. 그런데 이건 정말 기본이다. 그럼 실제 서비스는? 메인화면이라던가, 스무개의 CRUD식의 메인 모듈들과 신규 추가되는 메신저라던가, NAS연동이나 웹메일 연동 등.. 이런 부분에서는 솔직히 말해, 전혀 한게 없지 않는가.
아직도 사실 욕심은 많다. 특히 운영환경에서 Scalable하게 접근하고자 도커를 이용해서 구축하고 싶다. 그런데 그러자니 시간이 없다. 그런데 더 따지고 볼 것은 눈으로 볼 수 있는 아웃풋이 얼마나 있느냐는 것이다. 로그인이 전부라면, 그게 정말 내가 개발했다고 할 수 있겠는가. 그건 절대 아닐 것이다. 엉망이 된 환경에서도 아웃풋 자체는 온전하게 개발되었다면, 그것은 걷으로 보기엔 완벽한 제품이나 다름없다. 아니, 최소한 내가 개발은 했다는 증거가 될 수 있으니깐 말이다.
이게 참 최근와서 느끼는 나의 큰 딜레마이다. 병특 시절, 어느정도 개발에서 욕심이 생기고 나서는 오픈소스를 대거 채용하고자 하였다. 그런 나의 제안이 가끔은 좋은 결과로 이어져서 팀웍에 큰 효율을 가져오긴 했지만, 한편으론 그때의 그런 욕심이 3년간의 학부를 다시금 거치면서 매번 신기술을 추구해야 하는 그런 '압박'에 시달리게 했다. 그러다 보니 그저 트랜드에만 욕심이 생겼지, 실질적인 개발은 채 5%에서 진전이 없다. 편한 기술이 계속해서 나오고, 가장 중요한 것은 제너럴 한 개발이다. loose-coupling을 중점적으로, 다용성을 목표로 개발을 하다 보니 지금처럼 백엔드와 프론트를 떼어놓는 상황에 놓이게 되었다. 나중에는 DBMS조차 객체지향 기반이나 NoSQL로 갈아탄다면 한차례 더 혁명이 이뤄질 것이다..
기술과 제네럴에 대한 욕심은, 글쎄 내 생각에는 당장의 서비스에 차용하는 자체는 아니라고 본다. 물론 문제를 해결하기 위한 솔루션이나, 추후 신기술 개발을 위한 하나의 발판은 되겠지만 지금은 아니라는 것이다. 물론 나의 저조한 안목도 한몫 했겠지만, 이제 어느정도는 알고 있는 상황에서는 빠른 개발이 더 중요하지 않을까. 프로그래머로써의 자존심처럼, OOP의 핵심적인 정책처럼, loose-coupling하고, 상호 베타적인 의존성 지향 등.. 그런데 솔직히 좀 꼬이면 어떤가, 그런 문제를 해결하고자 소프트웨어 엔지니어가 있는 것이 아니겠는가. 어떤 기술이 베이스가 되던 간에, 기술은 끝없이 발전한다. 이리 저리 좋은 기술들이 나오는 것이다. 하지만 좋다고 무턱대고 받아놓기만 한다는 것은, 그건 마치 신제품이 나오면 무조건 사고 보는 소비지향이나 다름 없다. 기존에 산 것은 제대로 사용도 안한 채로 말이다.. (가끔은 내 구매적 성향이 개발에 반영된 것은 아닌가 싶기도 하다.)
얼마전 대두와의 대화에서, 대두는 내게 "제너럴을 추구하면 절대 서비스가 나올 수 없다. 과유불급. 많은 기술을 차용했다는 것이 꼭 좋은 것은 아니다. 서비스가 먼저 나오고 조금씩 바꿔나가는 스타트업적 개발방식이 중요하다." 라는 언급을 했다. 시간이란 한정되 있고, 그 시간에 얼마나 빨리 아웃풋을 만드느냐가 중요하다. 삶이 마치 해커톤 같다. 짧은 시간안에 얼마나 효율적으로, 기발한 아이디어로 결과물을 만드느냐. 이제는 정말, 결과물을 만들 때가 아닐까. 제너럴한 방식은, 그저 학업에서 배우고 익히는 정도로도 충분하다. 필요할 때 바꾸면 되니깐.
결과는, 빨리 개발이나 하자.
