최근에 임백준 님의 책, 폴리글랏 프로그래머를 읽으면서 다시금 느끼는 게 많다. 폴리글랏이라는 것은 이미 이슈된지 4년이 넘었지만 (책을 산지 2년 만에 읽음..), 자바개발 5년 차쯤 부터 점차 내가 우물안 개구리라는 생각을 했었고, 이후 프론트앤드 기술과 스칼라를 접하면서 이리저리 스택을 넓혀가려는 내 상황에서 프로그래밍의 “역사” 적으로 깊은 고찰을 안겼던 책이었다.
(폴리글랏 프로그래머: 단일 언어로 제공되지 않는 추가 기능과 효율성을 극대화 하기 위해 여러 언어로 코드를 작성하는 것. 풀스택과는 조금 다르다.)
안주(complacent) 에 대한 고찰,
어딘가에서 안주했던 상황은, 주니어때 한국에서 다녔던 회사들이 그랬다. 초반 한 3개월에서 5개월 정도는 정말 빡쎘다. 퇴근이 보통 11시에서 새벽이었으니, 그도 그럴 것이 실수도 많이 했고 따로 테스트 팀이나 스크립트도 없어서 이를 반영하기 위해서는 꽤나 많은 테스트가 필요해다. 그래서 실제 개발시간이 서너시간 남짓이라 해도 이를 테스트해서 버그를 잡는 시간이 더 걸리는 상황이 발생하곤 했다. 그런데 중요한건, 나중에 되면 미리 그 버그를 알아채기 때문에 점차 버그잡는 시간이 줄어들고, 또 나중에는 나도 엑셀같은거로 미리 버그 체크해야 할 상황을 만들어 두고 체크하기 때문에 시행착오에 걸리는 시간들은 점점 줄어들어서 나중에는 좀 “편하다” 고 느낄 정도가 되었다.
그렇게 편하다고 느끼기 시작하자, 칼퇴근과 늦은 출근이 시작됬다. 한 9시반쯤 슬슬 사무실에 나와서, 5시쯤 슬슬 퇴근을 하는 것이다. 물론 눈치껏이것지만, 예전에 내가 야근을 하면서 하던 작업을 나는 그대로 가지고 있으면서 이런저런 핑계로 내 역량은 실제로 150%가 증가했다면 120%정도 증가했다고 대외적으로 말하면서 ‘내가 중요한 사람이다’ 라는 것을 좀 억지로 만들곤 했다. 회사에선 당연히 짤릴 일도 없었고, 나는 뭔가 신입은 못하지만 중요한 일을 하는 사람이 되었다. 정확히는 내가 만든 조직 속에서의 이미지였고, 나 나름대로의 야근이나 철야 등에 대한 방어막이었고, 그런 적응 속에 나 스스로를 가두고 솔직히, 편하게 보냈다.
어느순간부터는 스프링에 서비스 하나를 추가하는 단순 작업(?)은 아주 손쉽게 해냈다. 처음에 좀 복잡하게 모듈화를 해두면 (주로 선임이), 나중에는 가져다가 쓰면 된다. 내게 설계에 대한 의무는 없었다. 자바개발을 하면서, 주로 JSP나 스프링 개발을 했는데 항상 느꼈지만 copy-and-paste가 많았다. 신입때는 선임들이 만들어 놓은 것에 대해, 어디어디만 수정하면 되는지만 알면 서비스 하나가 후딱 만들어졌다. 심지어, 코드에 대한 이해조차 하려고 시도하지 않았다. 왜 Spring MVC에서 서비스와 서비스 인터페이스를 나누는지, JPA는 뭔가 편하긴 한데 장단점은 무엇인지, 자바를 사용함에 있어서 어떤 예외처리를 감수하고, 한편으론 멀티스레드 등에 대해서 어디를 고려해야 할지, DB상의 병목은 없을지 이런 것들을 하나도 고려하지 않고 나는 말 그대로 카피켓이 되고 있었다. (나중에서야 토비님 책을 정독하고 어느정도 환경설정까지 가능할 정도가 되긴 했다.)
아 예전엔 서블랫밖에 몰랐는데..그렇게 자바를 쓴지 10년이 되었다. 처음 배운건 고2때니깐, 알아간지는 14년. 중간에 HTML5관련 책도 쓰면서, 실상 나는 웹에 대한 기술이 좋았고, 중간중간 프론트앤드 개발도 많이 했었다. 당연히, 위에서처럼 자바 카피켓이 되어가는 상황에서, HTML -> JSP로 변하는 과정에서 Form Validation은 내 몫이었고, jQuery의 그것을 열심히 사용해가면서 자바스크립트를 썼다. 여기서 썼다는 표현은, 말 그대로 똑같이 jQuery나 자바스크립트에 대한 깊은 이해가 없이 썼다는 말이다. $로 표현되는 세상에서 나는 그 흔하디 흔한 클로저의 개념조차 모른 상태에서 수 년을 살아왔다. 물론 학교를 다시 다녔다는 것도 있겠지만, 자바스크립트를 VB스크립트 시절부터 알고 지냈던 내 자만감이 조금 더 추가되서 나는 당연히, 자바스크립트를 공부하려는 시도조차 하지 않았다.
자바를 쓰면서 난 정체되갔다. 왜지..스택의 전환
몇번 이곳에 글로 써왔지만, 약 4년 전부터 나는 자바스크립트의 심상치 않은 움직임을 느끼고 나서부터는 내 기존의 풀스택 역량인 백앤드(8):프론트앤드(2)를 백앤드(4):프론트앤드(6) 정도까지 바꿔나갔다. ES6나 TypeScript등의 문법적인 것과, React, Angular 등을 공부해나가면서 수 많은 개념에 대해 알아나가기 시작했다. 앵귤러의 directive, factory를 알아갈 즘에 리엑트로 바꾸고, react, redux, thunk등을 다루다가 자바스크립트를 제대로 모른다 판단하고 다시 강의등을 들으면서 closure, hoisting, destructer, spread, rest, mixin, set/map, iterator, generator 등을 공부해나갔다.
그런데도 아직도 나는, 어제 만난 형과의 대화에서 PureComponent를 사용하지 않아서 React의 랜더링 시점이 성능에 어떤 영향을 주는지에 대해 아직도 깊은 이해를 하지 못해서 다시금 강의를 듣고, 또 다시 본래 개발한 것들을 리펙토링 하고 있다. 그러다 보니 프로젝트는 계속해서 밀려가기만 하고, 이를 따라잡으려면 주말이고 밤이고 없이 일해야 하고, 그렇게 또 짜임새 있게 리펙토링 하면 스스로 뿌듯하고 말이다. (이래놓고 또 버그가 나올지도..)
스칼라를 3년째 쓰고나서, 진짜 그림 그대로가 됬다. 백엔드도 그렇다. 자바의 그것에서 벗어나고자 고교 선배의 추천으로 스칼라를 공부하기 시작했는데, 이건 뭐 자바와 FP의 아무런 이해도 없이 스칼라를 하려고 했던 내가 바보였다는 생각까지 든다. 다들 주변에서 FP공부하려면 하스켈 하라 했는데 뭔 고집을 피운건지, 코세라의 오더스키 교수님 강의면 만사 ok라고 생각했는데, 미루고 미루다가 그 강의의 2편까지를 지난주에 끝냈다. 올해 초에서야 Programming in Scala를 (몇몇 부분은 넘기고) 다 봤다. 그런데도 아직도 tail recursion같은건 헷갈린다. 뭔가 스칼라가 side-effect를 해결하려는 노력 자체가 많이 보이는데, 아직도 병렬 환경에서 스칼라의 이점이 무엇인지 헷갈린다. 아무래도 코세라 강의를 더 들어봐야지 알 수 있을지 않을까라는 생각이 든다. (3년째 써오는 입장에서, 그래도 코드의 깔끔함과 데이터를 다루는데 있어서 자바보다는 훨씬 낫다.)
최근 맡은 프로젝트에서는 본래 쓰던 익숙한 Spring-boot/JPA/MySQL 을 져버리고 MERN (MongoDB-Express-React-Node.js) 스택을 사용하기로 했다. 드디어 내가 실무의 서버사이드 언어로 Node.js를 선택한 것이다. 노드는 원래 거의 모든 나 학부/석사 프로젝트만 사용했었다. 쉽고 금방금방 만들 수 있으니 자바처럼 설정 건들 필요도 많이 없고. 많은 대학원때의 인도 친구들이 파이썬이 익숙하니 Bottle이라는 경량 REST 프레임워크를 쓰는것과 마찬가지일 것이다. 그런데 실무에서는 쓰려고 시도한 적이 한번도 없다. 왜 이미 오래전부터 내가 가지고 있는 편한 스프링 환경 (이미 다 Enterprise쪽으로는 구축되있는) 놔두고 꼭 노드 써야할까. 이미 프리랜싱을 하면서도 많이 써왔는데. 그런데 막상 노드를 써보니 뭐 이리도 편한걸 내가 왜 진작에 안썼을까 라는 생각까지 든다. 스프링을 단지 개발이 편하다는 이유만으로, 멀티스래드나 분산환경 및 자바 언어 자체에 대한 고민없이 사용하려 했던 내가 바보스러웠다. 이미 docker와 몇몇 pod들로 구성된 MSA환경 속에, Enterprise라는 것이 갖는 이점은 무엇인가, 그리고 꼭 대규모도 아닌 프로젝트에 왜 나는 예전 대규모 고도화작업(?)에서 익숙한 환경을 가져다 쓰는가.
난 이런 나의 생각이 이미 내가 개발 “실무”에 몸담근 가장 처음부터가 잘못되었다는 생각이 들었다. 언젠가 2009년의 글에서 나는 에이전시 회사에서 자바 닷넷 php asp 닥치는대로 개발을 하다보니 이러다 나중엔 이도저도 안되겠다는 생각이 들었다. 물론, 당시 사수가 php만 고집해서 나도 저렇거 해야지 내 몸값이 되나보다 라는 안일한 생각에서, 나는 자바를 선택했고 몇년 뒤 뭐 전자정부 표준 프레임워크부터 해서 이러저러하게 스프링이 대세아닌 대세가 되자 나는 “아, 역시 그때의 결정이 후회스럽지 않다.” 라는 생각에 자바만 고집하다 지금에까지 이르게 된 것이다. (아, 한 언어만 고집하다니 주니어 답다는 생각도 든다.)
C# LINQ폴리글랏 프로그래머 책의 말과 같이, 나도 자바만 고집하다가 여타 멋진 언어의 기능들을 놓친 것이 많은 것 같다. 내가 잠시 닷넷 개발자였던 2008년즈음, LINQ를 보고 와 쿼리로 이런 기능을.. 이라며 감탄한 적이 있다. 그런데 닷넷 개발은 거의 9년째 한번도 하지 않았다. 9년간 맥 생활을 해온 영향도 있겠지만, 플랫폼에 종속되는 닷넷 자체가 마음에 들지 않았기 때문이다. 하지만, 수 많은 고급 개발자들이 MS에서 고군분투하며 언어의 이점을 차곡차곡 쌓아놓는 그것은 전혀 눈치채지 못했다. 이미 람다나 함수형의 그것과 비슷한 기능들은 닷넷에 존재해 왔었다. 어쩐지, 닷넷 개발자로 있는 내 친구에게 내가 스칼라에서 뭔가 이해하고 자랑을 늘어놨을 때 대답이 서늘하더라. 난 정말정말로 우물안의 올챙이었던 것 같이, 부끄러웠다.
또 다른 도전,
최근에 맡게 된 또 다른 모 프로젝트에서는 아에 생판 모르는 GraphQL과 Relay, ReactNative로 구성된 것에 언어 환경이 또 이번엔 TypeScript으로 개발을 한다. 타입스크립트는 뭔가, 기존 pure자바나 flow등의 기능을 좀더 언어의 기능적 차원에서 개선한 느낌이 든다. (아직 깊게는 모른다.) ReactNative를 하다 또 네이티브쪽은 Swift와 Kotlin을 써야한다. 유라임 프로젝트에서는 몇몇 서버의 기능을 Go로 바꿨다. 유라임은 이미 스칼라와 플레이, 프론트는 리엑트를 쓰니, 앞의 프로젝트의 MERN스택부터 해서 이쯤 되면 문어발식으로, 이젠 내가 어디가서 주력 언어가 뭔지 말하기도 좀 그렇기도 하다. (하지만 확실한건, 이제 자바 개발자는 아닌듯?)
확실한 것은, 언어는 언어일 뿐이다. 프레임워크도 프레임워크일 뿐이다. 풀스택을 넘어서 폴리글랏 프로그래머라. 결국 내가 언어를 가장 처음에 베이직과 C로 배웠듯이, 언어의 그 모태는 변하지 않는다. 경험과 지식이 전래할 뿐이다. 한 언어라도 깊게 파자라는 것이 아니라, 프로그래밍 언어와 프레임워크에 대한 보다 더 깊은, 소프트웨어와 컴퓨터 공학적, 그리고 분산 및 클라우드적 이해가 필요한 시점인 것 같다. 깊은 성찰 이후, 자신이나 조직이 원하는 그것을 빠르고 정확하고 안전하게만 만들면 된다. 사실 뭐 그것보다는, 나 개인적으로는 그냥 개발하면서 즐거우면 된다. 알아가는 재미, 그게 프로그래밍의 묘미가 아닐까. 그런 의미에서 나는 오늘도 공부거리를 찾아나선다.
