너무 오랜만에 블로그에 글을 쓰는것 같다.
개인적으로도 여러 일이 있었고 회사에서 여러가지 일이 있어서 복잡 다산한 생활을 보냈다. 우선 회사 사정을 말하는 것은 조금 그렇고 여러 사황에 의해 결과적으로 모바일 팀의 팀장이 되어 버렸다. 갑작스럽게 되어서 무얼 어떻게 해야할지 고민과 번민의 시간을 가졌었다.
어차피 기술리딩, 팀 관리, 프로젝트 관리도 해야할 것 같은데, 그에 대한 보상은 있겠지? 하는 생각이 든다. 어차피 나는 개발만 해도 잘 벌어먹고 잘하는 사람이니까. 앱 스프린트가 시작되고 왠만하면 예외적인 상황을 안 만드려고 여러가지 고민을 하다가 다른 팀과 협업이 최대의 변수라 협업할 사항들을 새벽까지 정리하고 테이블을 만들었었다. 프로그램 작성할 때도 예외를 최소화해야하는데 기능 개발에 대해서 고심에 고심을 해보니깐 동일한 것 같다. 다만 어떤 기능을 개발해야 할 때 어느 정도 걸릴것이다란 일정 산정이 나는 쉽게 되지 않았다. 기획서를 보고 무얼할지 정리하고 협업 사항을 추출하는 과정에서 각각의 일이 얼마나 걸릴지 예측을 할 수 있겠으나 그것도 예측일 뿐 최대한 넉넉히 다음에는 잡아야 겠다.
어차피 자체 서비스인지라 일정을 너무 빡세게 산정하면 나뿐만 아니라 다른 팀원들도 개발할 때 실수를 하게 되고 결국엔 앱의 품질에 문제가 생길 수 밖에 없다. 한 라인의 코드를 짜더라도 고민하고 고민하는 문화를 가지는 팀을 만드는게 목표인지라 그래야 팀원들의 실력, 내 실력도 늘고 앱의 품질도 보장되고 확장성, 유연성, 유지보수 용이한 앱을 만든는데 초석이 되는 문화라고 생각한다. 바쁘고 야근하는 문화에서는 절대 좋은 코드를 양산하고 좋은 엔지니어가 될 수 없다고 생각하기 때문에 최대한 이 부분을 어떻게 지키고 만들어 나갈까 고민하고 있다. 그런데 다른 팀의 팀장과 애기해 보니 나와는 다른 생각을 가지고 있다. 하지만 나는 내 생각엔 변함이 없다.
회사 일에 파뭍혀 지내면서도 자기 계발에 손을 놓지 않아 다행이다. 디자인 패턴에 대해 이해도 및 숙련도를 조금 더 높히려 디자인 패턴 및 SOLID 원리에 대해 다시 리뷰하는 시간을 가졌고, MIT 알고리즘 책도 1300페이지에 달하는데 한번 빠르게 정독하였다. 지금은 재미로 JVM8 스펙을 두번째 보고 있는데 머리에 쏙쏙 이해되어서 꿀잼이다. 회사에 RxJava, Retro Lambda, Method reference, Optional, Stream등을 안드로이드 앱 개발할 때 사용할 수 있도록 환경을 만들어 놓고 나 같은 경우 거의 모든 코드를 위에 열거한 기술로 거의 구현하고 있긴 하다. 그런데 JAVADOC 및 블로그를 보면서 이해도를 높이면서 사용하고는 있는데 함수형 언어에 대한 근본적인 통찰력이 부족하다고 느껴져 JVM8 스펙을 다 읽은 후 함수형 언어에 대한 책 두권을 읽을 예정이다. 아마도 JVM8 스펙하고 함수형 언어 책 두권을 읽으면 2016이 다 지나갈것 같다. 그 다음은 다시 MIT 알고리즘 정복이다. 아마도 2017년에 3번 더 반복 읽기가 가능하겠다.
개발을 하면서 여러 글을 읽게 되고 reddit 게시물도 항상 모니터링 하고 있는데 그놈의 코틀린 애기가 자주 나온다. 코틀린에 대해 세미나를 한번 들었다. 자바보다 모던하고 간결한 건 인정한다. 근데 언어란게 그게 전부가 아니다. 언어가 제공하는 인프라와 이미 포진되어 있는 그 언어에 대한 통찰력이 풍부한 전문가 인력 풀, JVM 스펙 조차 JAVA를 기준으로 되어 있다. 왠만한 메이저 회사는 섣불리 주력 언어를 타 언어로 변경할 가능성이 거의 없다고 단언한다. 자바가 바보같이 뒤쳐지지 않은한 메이저 회사들은 자바를 유지할 것이고 자바 개발자를 뽑을 것이다. 코틀린이든 어떤 언어든 메이저가 되면 그 때 생각해 봐도 늦지 않다. 굳이 비대중적인 언어를 선택해서 어떤 이득이 있는가? 그것보다 기본 베이스를 익히는데 훈련하는데 충실해야할 것이다.
