brunch

매거진 유라임 프로젝트 이야기

라이킷 23 댓글 4

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 메튜 May 02. 2018

개발 스택이란 쓸때없는 고민

언어도, 프레임워크도 아닌 내 욕심이 문제.

여러모로 큰 고비를 맞은 유라임 개발로 다시 돌아온지 어엿 3주차가 되었다. 쉽지않은 미국 생활에 겨우 개발을 '안정적'으로 할 수 있는 시간을 다시 잡았고, 덕분에 지난 11월부터 정체되어 있던 개발을 다시 시작할 수 있었다. 분명 미국에 올때만 해도 회사와 학교(MS)를 병행해서 할 수 있을것이라 생각했지만, 어느순간 이 생각은 허물없이 무너져만 갔다. 핑계지만, 처음 지내는 이 캘리포니아의 수 많은 자연경관속에 넋이 나가있었고, 이후에는 자꾸만 사업과 학업의 병행의 갈림길에서 허우적되며 개발은 계속해서 지체되어 갔고, 졸업은 반년이나 연기되었다. 한국처럼, 회사를 '병행'해서 다닌다는 핑계는 이곳에서는 아무리 해도 먹히지 않았다. 학교를 만만하게 봤고, 스타트업이란 것을 그저 개발만 잘하면 되는 것으로 본 내 불찰이고 내 잘못이었다.

그렇다고 논것은 아닌데, 무엇이 문제였을까. 벌써 이곳에서 3년의 시간이 지나니 여러모로 압박이 시작된다. 당최 왜 개발에는 진척이 없을까? 분명한 것은 생각해둔 version 1의 모든 feature를 다 만든 것은 분명하다. 그런데도 왜 유라임은 세상밖으로 나오지 못하는 것일까?

끝 없는 생각 끝에, 결론은 내가 너무나도 '최신'기술에 목메인 것이라는 생각이다. 실상 새롭게 접하던 모든 기술들을 계속해서 '개발중'인 것에 접목시키려다 보니 지속적으로 버그가 보이고, 정확히 이해하지 못하고 들어간 그 '최신기술' 이라는 하나의 유행을 적용하려다보니 심하면 처음부터 끝까지 뜯어고치는 경우가 발생하는 것이다.

유라임은 처음에 Spring 3.5와 Velocity, Freemaker, MyBatis, MySQL을 기반으로 단일 서버에서 Apache HTTP + tomcat기반으로 개발해왔었다. 내가 실무에 있었을 때의 내딴에서의 최신 스택(약 2012년 경)이 이랬다. 내가 가장 익숙하기도 했다. 서비스가 무거워지고 그런건 둘째치고, 개발을 빠르게 할 수 있는게 좋았다. 하지만 문제는 결국 아무리 백엔드를 잘 구축해봤자 거의 70%이상의 소위 노가다 작업이라 할 수 있는 form validation이나 각종 ajax처리 등은 대부분 프론트앤드와 직결됬다. 그래서 프론트앤드에 대한 고민을 해왔었고, 특히나 Web Socket등을 통해 좀더 실시간의 웹을 만들 수 있겠다는 생각을 지속적으로 해왔었다.

백엔드: Spring F/W -> Spring Boot

프론트엔드: JSP -> Backbone, Node.js, Express

어느정도 DB설계와 백엔드가 되어가는 찰나, 나는 두 가지를 만나게 되었다. 하나는, 학부에서 Node.js를 만나면서 MEAN스택을 만나게 된 것이다. 물론, 아무리 해도 내게 NoSQL은 적응이 잘 되지 않아서, Node와 Express만 가지고 어느정도 프론트앤드를 유연하게 구축할 수 있게 되었다. 이맘쯤 배운 Nginx의 proxying기능에 매료되어 Apache HTTP도 갈아치웠다. Node+Express로 프론트앤드의 백엔드(?)를 돌리던 찰나, 어느순간 나는 Backbone.js를 알게 되었고 이리저리 백엔드를 구축하면서 이런 frontend framework를 지속적으로 고민하기 시작했다. 참, Spring도 Spring boot가 나오자마자 갈았다. 귀찮은 XML환경설정을 자동으로 해주고, 마이크로서비스(!) 라는 말에 끌렸다. 물론, 이 과정이 유라임을 본격적으로 만들기 '전'에 일어난 일이었다.

백엔드: Spring/Java -> Play Framework/Scala

유라임을 지속적으로 생각하던 때에, 나는 Play Framework와 Scala라는 언어를 알았다. 그냥 이상하게 끌렸다. '함수형 언어'에 대해, 깊게 공부하지도 않았으면서 그냥 미래라고만 얼추 생각했다. 왠지 스프링의 그것과도 비슷하거나 더 쉬워보여서 단숨에 Play로 갈아치웠다. 그런 와중에 수 많은 문제가 발생했다. Scala라는 언어 자체를 하나도 이해하지 못했다. 자바스크립트가 함수형 언어라며? 스칼라의 기본적인 문법 외에는 아는게 없었다. 그것도 자바랑 비슷한 부분만. 그래서 나는 if를 남발했고, 심지어 for문도 엄청나게 쓰게되었다. 어쨌든, 뭐하면 그냥 기존 java코드 가져다 쓰면 되니깐 나는 굳이 스칼라를 깊게 배울 생각을 하지 않았다(!) 그래도 Play의 라우팅이나 async기능은 뭔가 '비동기'니깐 빠르겠지 라는 막연한 생각이 있었다.

그나마 1년 뒤에 Coursera의 FP in Scala강의를 듣긴 했지만 그때도 (아마 영어부족으로) 이해하지 못했다. 기본서인 Programming in Scala를 몇장만 읽고 말았다. 나중이 되니, 당최 Spring에서 그토록이나 익숙하던 JPA를 어떻게 처리해야 할지 몰랐다. 다행히 Slick을 알게 되었지만, 사실 제대로 이해하고 썼다고 하기에는 적잖히 부족하다. RDB에서 흔한 Join하나 할줄 몰랐고, raw query를 쓸줄 몰랐다. 모든 것을 함수와 맵핑하고 싶었는데, 당최 기본적인 데이터 처리 함수인 filter map flatmap 이런것들의 용도와 종류를 모르니 대체 Future와 맵핑되는게 뭐고 안되는게 뭐고 Nothing Nil Null 의 차이점 자체도 몰랐다. 부끄럽지만, 아는게 없었지만 수 많은 노가다와 시간 끝에 '돌아가게'는 만들었다.

백엔드: Operated-based API -> Resource-based API(Restful)

프론트앤드: Backbone -> AngularJS

인프라: Monolitic -> Microservice (Docker, Kubernetes)

2015년 중순, 유라임을 본격적으로 만들기 시작했다. RESTful에 대해서 배웠다. 그리고 서버를 REST로 바꾸기 시작했다. 기존의 /mainController.do?cmd=getUserList 와 같은 형태의 내 머릿속을 RESTful로 뜯어고쳤다. 자바스크립트를 조금 더 재정비할겸 해서 CodeSchool의 강의를 보다가 우연히 AngularJS를 봤다. 신세계였다. 2-way binding이라는 자체가 뜻밖이었고, 모델까지는 없어도 View, Controller, Service로 구분된 자바스크립트 단의 그것이 좋았다. 오래전의 Flex와 같은 RIA 개발을 할 때에 그런 느낌이 났다. 그간의 프론트앤드는 내가 생각하던 자바스크립트가 아니었다. 더 이상 HTML에 끼워넣기 혹은 연결된 JS파일의 뭉탱구리가 아니었다. MV*C를 기반으로 내가 생각하던 프론트앤드의 모든 개념을 바꿔놓았다. 그렇게 나는 무려 3개월이나 앵귤러를 파면서, 프론트앤드를 앵귤러로 바꾸어 놓았다.

2016년, 리엑트를 접했다. 리엑트는 가히 신세계였다. 일단 앵귤러는 쓰면 쓸수록 느려졌다. 2-way binding을 필두로 여러가지 문제가 있었다. 상위/하위 버전의 호환성도 그랬다. 그래서 view에만 집중한다는 리엑트를 배웠다. 정말로, 2016년 내내 시간이 날때마다 리엑트로 바꾸려고 노력했지만 변변히 실패했다.

올 한해, ReactJS개발은 접다.

충동적인 프레임워크 변경에서 오는 후회, | 3주정도의 시간이 지난 것 같다. 프로토타입 공정률 50%정도, 나름대로 아키텍처 설계를 잘 하고 이제는 레고블럭 맞추듯이 차곡차곡 만들어 나가면 되는 상황을 또 다시 기술의 '욕심' 때문에 무려 3주의 엄청난 시간을 보내고 이제서야 정신을 차려서 포기하고 다시금 원점으로 돌아간 것이다. 구체적으로 말하면 AngularJS 1로 되어있는 프론트엔드를 요즘

brunch.co.kr/@matthew-chang/14

어쨌든, 나는 10개월 만에 유라임 알파버전을 완성했다. 그저 데이터 분석과 수집에만 집중하고 본래 하려던 소셜 기능은 제외했다. 알파버전 이후, 나는 수 많은 피드백을 들었다. 그 중 가장 큰 것이 버그가 수없이나 많았고 프로그램 자체가 느리다는 것이었다. 그래서 또 다시 문제점을 파고들기 위해 프로그램을 뜯어고쳤다.

AngularJS 개발자의 ReactJS 마이그레이션

프레임워크 의존성에서 벗어나기 위한 리엑트의 선택 | 최근 글이 매우 뜸했다. 것도 그런 것이, 학교를 마치고 나서 본격적으로 제품을 만들기 위해 가장 하고싶었던 일이 다름아닌 작년에 포기했었던 리엑트를 올해 꼭 공부해보고, 실제 적용해보고 이를 기반으로 개발환경이나 머릿속에 잡혀있는 Single-page Application에 대한 이해를 다시금 정비하고 싶었다. 그래서 근 두달 정도 공부하며 마이그레이션을

brunch.co.kr/@matthew-chang/28

AngularJS의 느리다는 문제점을 탈피하기 위해, React.js를 본격적으로 사용하려고 수 없이 공부했다. 본래 백엔드 개발자인 내게 프론트앤드의 그것은 생각보다 방대했다. 그래서 느리고, 또 느렸다. 당최 내가 생각하던 그런 자원의 유지 방식이 리엑트는 너무나도 많이 달랐다. 쉽지 않았다. 내가 가장 쉽지 않았던 것은, 리엑트를 앵귤러랑 마찬가지로 통합 프레임워크로 생각했다는 것이 아닐까 싶다. 그렇게 작년 내내 개발을 해서 베타의 한 80%정도를 끝냈지만 서론과 같은 문제의 발생으로 잠시 약 4개월 정도 지체될 수 밖에 없었다. 물론 그 기간동안 Scala와 JS/ES6를 좀더 깊게 공부하긴 했다.

최종적으로 나온 스택.

최근에 내가 발견한 문제점은, 내가 앵귤러처럼 프론트앤드에 로직을 녹여내다 보니, 백엔드에서 처리할 수 있는 Business Logic까지 앵귤러의 서비스에 이리저리 심어넣은 부분이었다. 이건 보안상으로도 큰 문제가 있을 뿐더러, 클라이언트가 수 없이 느려질 수 밖에 없는 원인이기도 했다. 오죽하면 크게 데이터가 없는 내가 메인화면 한번 로그인을 해도 Ajax호출이 200번 가까히 발생할까. 일반적인 Business Logic의 배치를 크게 잘못 생각해서, 클라이언트에 배치한 내 문제가 가장 컸다. 서비스가 워낙 느려서, 아에 Spring REST를 통해 HATEOAS기반으로 가볼까도 생각했다. Frontend에 모든 Business Logic을 빼고 Viewer로써의 기능만 하게 말이다. 그런데 그렇게 하면 또 개발 전체를 뜯어고쳐야 하고, 어느 순간 나는 또 망연자실해서 Scala를 버릴까도 생각했다. 그런데 그건 현실도피일 뿐이었다. 아니, Spring으로 돌아간다는 자체가 웃긴 말이었다.

이걸 또 배워서 적용해야 할까? 나는 여기서, 비로서 나의 '최신기술'에 대한 욕구를 정지할 수 있었다.

유라임과 React의 설계의 문제점을 알고 나서, Server-sided Rendering (SSR)을 알았다. 그나마 이건 공부하고 이해하는데 얼마 걸리지 않았다. 그런데 또 Zeit이란 곳의 Next.js라는게 있더라. 이미 리엑트를 정형화 해서 쓸 수 있에 여러군데서 해두었더라. Slick에서 JPA와 같이 구현하려다 보니 이제 또 GraphQL이 보인다. 이걸 또 배워서 적용해야 할까? 나는 여기서, 비로서 나의 '최신기술'에 대한 욕구를 정지할 수 있었다. 아니, 정확히 말하면 최신기술을 개발중인 프로덕에 적용한다는 자체를 말이다. 생각해 보면, 최신 기술도 사실 '프론트앤드' 의 그 fancy한 기술에 떠밀려서 나도 본질적인 마일스톤을 놓치고 있던것이 가장 컸다. 아니, 이 server-sided rendering이라는 것이 결국 서버에서 렌더링하는 것이고, 이게 SPA (Single Page Application)에서의 reload가 없는것 빼고는 내가 가장 처음에 생각한 Spring+JSP와 크게 다를 것이 없다는 것이다. 언어랑 스택이 다르지만, 그 본질은 같은데 나는 왜 이리도 fancy함에 그토록이나 빠져있었을까?

결국 최신기술에 무턱대고 욕심낸 결과는 참담했다. 비즈니스 로직이 클라이언트에 어느정도도 아니고 95%이상 심어져있으면 말 다했다. 그것도 중구난방으로, 어떤 로직은 클라에 어떤 로직은 백엔드에. 이런 정말, 개발을 한다는 놈이 이런 잡동사니를 개발했다니. 결국 이건 풀스택 개발이라는 '함정'에 빠진 결과이다. 아에 사람들이 선호하는 뭐 MEAN스택이니, Vue.js나 그런 개발이면 모를까, Play+Scala+React라는 희안한 구조를 가진 내 프로그램은 어디서부터인가 아주 깊게, 잘못되도 한참 잘못된 것이다.

참으로 후회스럽다. 최신 기술을 배운것은 후회하지 않는다. 단, 내가 꿈꿔왔던 그 개발을 내 욕심때문에 완성하지 못하고 있었다는 자체가 말이다. 그래서 이제서라도, 더 이상의 라이브러리나 프레임워크를 뜯어고치는 일은 접으려고 한다. 생각해 보면, 나는 개발을 혼자하고 또한 마일스톤도 정해져있다. 그런데 내가 그간 펜시하게 느낀 프레임워크들은 한둘이 개발하는 것도 아니고 수 많은 개발자들이 참여한 오픈소스들이다. 이게 정말, 오픈소스의 함정일까? 아무리 당장 눈 앞에 멋있어 보이는 것들도, 아무리 수 많은 멋진 기능들을 첨가하면 뭐하나, 결과적으로 이는 프로젝트를 (정확히는 개발중인 프로젝트를) 지연시킬 뿐이다. 개발자가 많으면 누군가는 리펙토링하고 누군가는 기존대로 개발하는 것이 가능하겠지만, 나처럼 혼자하는 개발은 더더욱이나 그렇다.

이제는 좀, 신기술을 따라가는데 많이 지친 감이 있다. 물론 개인적으로 공부하는 것은 언제나 좋고 즐겁다. 하지만, 중요한 것은 이 기술을 적용하는데에 있어서 내가 얼마나 큰 리스크를 가지게 될지를 아는게 더 중요한 것 같다. 정말 요즘처럼 하루가 멀다하고 신기술이 쏟아져 나오는 이 시점에서는 오히려 고전적인 코드를 안정적으로 가져가는 서비스나 기업들이 더 승산이 있는 느낌이다. 개발자는 끝없이 공부를 해야한다. 맞는 말이다. 하지만 나는 스타트업을 운영하며, 사업과 개발을 동시에 진행하면 어느 시점에서는 분명 사업에 적극적인 투자를 해야함이 맞다.

고로, 앞으로 나는 그간의 생각과 경험을 토대로 더 이상의 유라임 개발에서 다른 프레임워크로 전향한다던가, 언어를 바꾼다던가, 그런 무모한 짓을 최소한 실무에서 하지 않도록 하겠다. 다만, 공부는 계속해서 하고, 개발은 끝없이 하는 것. 그렇게 해서, 이제는 정말 이 내 기술에 대한 '욕심'때문에 무한히 연기된 유라임을 어여 좀 끝내서, 나를 비롯해 꼭 필요한 사람들에게 꼭 빨리 사용할 수 있도록 해주고 싶은 생각이다.

p.s. 목표는 5월내 베타! :)

글쓴이 메튜장 | matthew@urhy.me | http://www.matthewlab.com

keyword