일년간 경험한것을 기술적인 요소들만 뽑아서 정리하면 3가지다. 1. 마이크로서비스 개발 2. 자바 기반 멀티스레딩 및 비동기 처리 3. 분산형 데이터베이스 모델링 및 최적화
2017년 8월에 시작한 회사 프로젝트가 1년 3개월만에 일단락되었다. 간단하게 프로젝트를 설명하자면, 2017년 매상 6조원의 일본 최대규모급 호텔/항공권/버스/렌트카 예약 서비스를 다시 개발하는 프로젝트였다. 기존의 서비스는 그대로 유지한채, 문자 그대로 제로베이스에서 스펙, 데이터 모델링 등 모든것을 처음부터 새로 만들어서 기존의 서비스와 스위칭하는 야심찬 대규모 프로젝트이다. 이 프로젝트에 200억 정도가 투자되었다고 한다. 게임 개발이 아니고 웹서비스 개발에 이만큼 들었다.
내가 회사에 입사한 17년 4월 이전에 이미 이 프로젝트에 마이크로서비스 아키텍쳐를 적용하기로 결정이 나있는 상태였다. 나, 팀장, 팀원A 로 구성되어 총원이 3명이던 우리 팀은 17년 12월부터 개발에 착수해 8개의 서비스를 만들어냈다. 난 이 중에서 2개의 서비스를 담당해 API 인터페이스, 데이터 모델링부터 시작해 수많은 사양변경을 적용다며 마지막까지 개발을 끝냈고, 2개의 서비스는 팀장과 함께 아키텍쳐와 데이터모델링만 끝낸채 팀원A에게 인수인계했다. 팀원A가 당시 절반 정도 개발해놓았던 3개의 서비스는 18년 7월부터 담당해 개발을 끝마쳤는데, 이 3개의 서비스중 2개는 버그가 너무 많아 인터페이스는 그대로 둔 채 코드는 거의 지우고 다시써야했다. 팀장과 함께 몇일간 하루에 1000줄씩 지워가며 다시 썼다. 1개의 서비스는 팀장이 담당해서 개발했기때문에 별 문제 없었다.
집중 개발하는 몇달간은 손가락 염좌에 시달려야했는데, 요새는 새로 추가된 스펙을 적용하기 위해 서비스 2개를 새로 디자인해서 만들고 있어서 키보드 타이핑을 되도록 살살하도록 신경쓰고있다. 또한 개발이 끝난 뒤이기는 하지만, 팀원 네명이 보강되어 이젠 어느정도 워라벨을 유지할수 있게 되었다.
9월엔 회사 MVP로 뽑혀 상을 받았다. 담당한 서비스 중 하나가 약 60여개의 HTTP 리퀘스트를 순차 또는 비동기로 보내며 서비스 오케스트레이션을 하는 역할이었는데, 웹서버 스레드와 워커 스레드풀등을 최대한 효율적으로 사용하면서도 latency 또한 최소화할수 있도록 설계, 구현 및 여러번의 퍼포먼스 테스트를 통해 검증 한것, 그리고 버그가 많은 서비스들을 도중부터 인수인계받아 빠른 시간 내에 버그제로를 만든 것 등이 인정을 받은것 같았다.
1년간 일이 정말 많아 힘들긴 했지만, 이 덕분에 팀원이 7받이 된 지금도 적어도 팀에선 베스트퍼포머로 인정받을 수 있게 된것같다.
스타트업에서나 경험할 수 있는 종류의 개발을 이런 규모로, 개발프로세스의 시작부터 릴리즈까지 참가할수 있었던건 다른곳에선 하기 힘든 경험이었다고 생각한다.
학생때부터 공부하며 익혀온 내용을 실제 서비스를 만들면서 적용할수 있는 기간이기도 하면서, 기술적으로나 업무적으로나 수많은 새로운 것들에 도전하는 기간이었다.
아직 각 세부 서비스의 bounded context를 마무리 짓기 전부터 난 내가 알고있는 몇가지 기술들을 빨리 써먹고싶었다. 물론 모르는게 더 많았으니 따라가기 위해선 이 악물고 공부하는 수밖에 없었는데, 막 2년차가 된 당시의 나는 회의중 사양에 대해서 토론 할때에도 항상 기술적인 부분을 연관지어 의견을 내고는 했다.
아직 사양과 기술적인 부분 (엄밀히 말하자면 내가 써먹고 싶은 기술) 을 명확히 구분해서 업무에 임하지 못했고, 성찰을 해보자면 사실상 아는게 많지 않은 상태에서 문제를 해결에 사용할수 있을 메커니즘, 라이브러리, 미들웨어를 찾는과정에 대한 두려움때문에 내가 알고있는 기술범위에서 사양을 결정짓고 싶은 마음이 있었던 것 같다.
반대로 팀장은 사양을 의논하는 단계에선 되도록 기술적인 요소를 배제하고 토론에 임했는데, 나에겐 여런 모습이 ‘기술적인 부분은 엔지니어인 우리가 해야할 문제이고, 그 이전에 어떤 문제 (비지니스 레벨의 사양) 을 해결 할건지부터 이야기하자’ 는 것처럼 보여 롤모델로 삼고싶다고 느꼈다.
그 외에 기술적인 부분에 있어선, 마이크로서비스에 대해 여러 각도로 고민을 했고, 대부분의 경우 웹이나 책에서 다른 여러 사람들이 먼저 고민, 토론하고 해결방안들을 제시한 것들을 찾을수 있었지만 나 또한 이것들은 다른 포스팅을 통해 하나씩 올려보겠다.
팀에서 주로 사용하는 MongoDB 에 대해선 클러스터링, 복제, 데이터 모델링, 디비 최적화 및 쿼리 최적화 까지 인프라에 관련된것 외엔 모든걸 혼자 담당하고 있다. 모든게 순조롭지만은 않아서, 당장 문제될일은 없지만 향후 최적의 퍼포먼스를 뽑아내기 위해서 기존 디비의 클러스터링을 완전히 삭제하고 새로 클러스터링 해야는 문제가 있다. 이젠 개발단계가 아니라 이미 들어온 고객데이터를 어떻게 손실없이 빠르게 다업을 마무리할 수 있을지 연초가 되면 고민해봐야한다.
한가지 장애물은 MongoDB 의 다큐먼트에 언급되지 않은 내용의 경우 디비 코드를 까봐야 하는데, 이게 C++ 로 쓰여있다는 것이다. 학생때 써보긴 했지만 아직도 마음의 숙제로 남아있는 C++ 을 다시 공부하며 읽어보고 싶진 않아서 MongoDB 출신의 DBA 에게 염치 불구하고 물어본다. 언젠간 술술 읽으며 버그가 있으면 커밋도 해보고싶다. 실제로 Spring Data MongoDB 에 문제가 있어서 이슈티켓 만들어 풀리퀘스트까지 보냈는데, 이 사람들이 내 코드는 심지어 코멘트까지 복사 붙여넣기 해놓고는 풀리퀘스트는 받아주지 않았다. 어쨌든 이슈는 해결되어 다음 버전에 릴리즈 될거라고 하지만 기분이 좋지는 않다.
서비스는 사내 PaaS 또는 IaaS 를 통해 디플로이하는데, 아직 사내 PaaS 가 성숙되지 않아 자질구레한 버그들이 남아있다. 최근에도 컨테이너와 VM의 TCP 소켓 관련하여 문제가 있어서 레포팅하고 해결할 수 있었다.
테스트에 대해서도 많은 것들을 느꼈는데, 더이상 TDD 에 흥미를 느끼지 않게되었다. 내가 담당한 첫 서비스를 구현할땐 TDD 로 구현하였다. 유닛테스트의 커버리지는 90%가 넘었고 Integration Test 도 필요하다고 생각되는 여러 패턴을 만들었다. 하지만 빈번한 사양 변경을 구현하는데 있어서 테스트코드는 개발 속도를 늦추는 짐밖에 되지 않았고, 고민 끝에 구현을 변경함으로 인해 실패하기 시작한 테스트코드는 모두 코멘트아웃시키기로 했다. 그 뒤로는 다른 서비스를 구현할 때에도 프레임워크나 라이브러리 디버깅 용도로 잠시 사용한 테스트 케이스 외에는 테스트를 한줄도 작성하지 않고 개발했고, 버그는 거의 없었다.
오히려 팀원A가 개발한 서비스들은 상당수의 유닛 테스트 및 인테그레이션 테스트가 있었음에도 버그가 많았고, 결국 나와 팀장이 메인 코드와 테스트까지 모조리 지우고 다시썼는데 빠른 시간 안에 버그 제로를 달성했다.
테스트코드와 TDD 가 가져올 수 있는 많은 장점들이 있지만 팀 상황에 맞지 않는데 굳이 억지로 쓸 필요는 없다고 생각한다. 짧은 경험에 비추어 볼 때, 적어도 개발 단계에선 테스트 커버리지와 개인 또는 한두명의 개발자가 얼마나 꼼꼼하게 테스트 케이스를 짰는냐는 결국 API의 버그 비율과 관련이 없다고 생각하게 되었다.
물론 개발도 완료되고 팀원의 숫자도 늘어나 여유가 생긴 지금은 유지보수할 사람을 위해서 테스트코드를 잘 만들어놓을 생각이다.
한가지 생각할 수 있는 문제점은 개발자와 테스트 작성자가 같았다는 점이겠지만, 사양 작성자가 테스트를 작성하지 않는 이상, 오히려 ‘사양서 작성자’ - ‘개발자’ 간의 커뮤니케이션 에러 뿐만 아니라 ‘사양서 작성자’ - ‘테스트 작성자’ 와 ‘테스트 작성자’ - ‘개발자’ 간의 에러로 에러발생 포인트가 늘어날 뿐이라고 생각한다.
경험 없던 시절 많은 사람들이 좋다고 하니 나도 따라했다가 고생만했던 억울함에 테스트에 대한 글이 길어졌는데, 나중에 마이크로서비스에 있어서의 테스트에 대한 주제로 다시한번 포스팅해봐야겠다.
기술을 습득할 때 난 주로 웹 포스트와 책을 통해 배우는 걸 선호한다. 가장 선호하는건 저자가 몇개월간 고민하며 쓴 책이지만, 최신 정보나 압축된 정보는 역시 웹 포스트를 읽는게 낫다. 매뉴얼의 경우 분량상 만만한 Java MongoDB Driver 나 JUnit 5, Spek 같은 매뉴얼은 그냥 시간내서 처음부터 끝까지 읽지만, 스프링같이 분량이 상당한 경우엔 그냥 필요할때 브라우저 검색기능으로 검색해가면서 읽는다.
지금까지 어렴풋하게만 느끼고 있었는데, 지난 1년간 읽은 책 목록을 정리해보니 내가 여러번 읽은 책들은 모두 업무에 직접적으로 관련이 있는 책들이다. 스스로 호기심이 많아서 개발 관련 서적을 읽는다고 생각했는데, 역시나 직접 부대끼며 같이 개발하고 경쟁하는 사람들이 있는 회사에서 남들보다 앞서가기 위함이 더 큰 원동력이었나보다.
규모가 있는 개발부서에 속해있지만, 부서 내의 사람들과 경쟁하는것에는 사실 한계가 있다. 모두가 개발에 전념하는게 아니라, 개발보다는 가족과 시간을 더 보내고 싶어사는 취미생활을 즐기고싶어하는 사람도 있으니 어쩔수 없다.
다른 포스트에도 업로드 할 생각이지만, 내년의 메인 목표중 하나는 오픈소스 프로젝트 기여이다. 먼저는 관심있는 분야의 프로젝트를 잘 찾아서 좋은 경쟁자들과 같이 성장할수 있으면 좋겠고, 오픈소스 프로젝트를 통해 2019년 회고록엔 더 많은 양질의 책을 읽었던것을 회고할 수 있으면 좋겠다.
신기하게도 프로그래밍 언어 책은 전부 읽다 말았다. 꾸준한 프로젝트 없이 호기심으로 읽기 시작한 책들은 전반부의 문법 요소들을 다 외우지 못하면서 후반부에서 흥미를 읽기 시작한듯하다. 역시나 최소한 배운 문법들을 직접 써보면서 그럴싸한 프로젝트를 꾸준히 병행하는게 필수겠다.
코틀린의 경우 내년에 시작하려 생각해둔 프로젝트가 몇개 있고, 회사에서도 테스트코드를 코틀린 위주로 짤수있도록 매니져와 팀원들을 설득할 생각이니 내년에 재도전할 계획은 이미 세워졌다.
Effective Java 를 끝까지 읽지 못한건 내용에 대해선 감탄하면서 읽었음에도 불구하고 이미 다른 블로그나 책들을 통해서 여러번 읽은 내용들도 있기에 이 책을 읽는 시간 대비 업무에 바로 적용할 수 있는 내용의 비율이 적다고 생각했기때문이다. 하지만 뒷부분 내용은 읽기전까진 나에게 얼마나 임팩트를 줄수 있을지 모르는 일이니, 자바계의 바이블인만큼 내년엔 완독하고싶다.
RxJava 관련 책들은, 스프링 5가 나오고 나서 한참 리액티브로 갈지 고민할 때 읽다가 톰캣을 사용한 논리엑티브를 선택하면서 도중에 안읽게 되었다. 토비님 유투브 강좌 보다가 리엑티브에 대해서 좀더 보고싶어져서 샀는데, 앞으로 스프링, Reactive Streams 관련해서 좋은 자료가 더 많이 나올테니 RxJava는 최소 반년간 볼일이 없을거같긴하다.
Cloud Native Java 는 나에겐 영어가 어려워 1⁄3 읽고는 책장에서 좀처럼 뽑질 않게된다. 왠지모르게 나에겐 술술 읽히지가 않았다. 저번에 저자인 Josh Long 이 회사에 온 기념으로 한국에서 번역판까지 주문했는데 (혼자만의 기념이다) 아직까지도 안읽었다. 내년 초에 읽어야지.
팀에선 주로 NoSQL을 쓰고있어서 몇번인가 JPA 와 Oracle 데이터베이스를 사용하면서 진행한 사이드프로젝트를 제외하고는 본격적으로 깊이있는 RDBMS 를 경험해볼 기회가 아직 없었다. 이론적으로나마 관계형 데이터베이스의 데이터 모델링과 SQL 에 대해선 공부했지만, 적어도 한가지 RDBMS 에 대해서 어느정도는 깊이있게 아는것이 백엔드 개발자로써 필수라고 생각했다.
그래서 OCA/OCP Oracle Database 12c All-in-One Exam guide 책을 읽으며 오라클 자격증을 따려고 했지만 역시나 바쁘고 업무에 직접적인 관련이 없다는 이유로 중도포기. 이 두꺼운 책이 지금은 책장에 놓여만 있다. 언젠가 반드시 읽고 말거다.
Site Reliability Engineering 는 목차까지는 재밌어보여 샀는데 실제로 읽으니 나에겐 너무 흥미가 안생겨 챕터 1 읽고 말았다. 돈아깝다.
OS 책은, 시스템 프로그래밍 서적을 포함하면 그동안 여댓권이상은 읽어왔지만, 내가 빠뜨리고 있는 내용과 기억이 흐려지고 있는 내용을 복습하기위해 바이블중 한권인 Operating System Concepts 를 구매했다. 역시나 프로젝트가 바빠지면서 포기. 아직은 내년에도 이 책을 완독할 계획은 없다.
짧게 쓰려 했던 2018 글이 길어졌다. 그래도 덕분에 내가 무엇을 경험했고 얻었으며 배웠는지 머릿속으로도 글로도 정리할 수 있는 시간이었다.