2016년 회고

26 Jan 2017

이직

2016년의 가장 큰 변곡점이라면 역시 이직이었다.

입사일은 2015년 12월 22일이었지만 본격적으로 업무를 시작한건 2016년부터이니. 이직을 생각하기 시작한건 2015년 9월 중순경이었고, 9월 말쯤에 이력서를 정리하고 이직을 위한 첫 발을 내딛었다. 그러나 연봉협상 과정에서 근 한달간의 줄다리기에 지쳐서(사실 기분이 상했던게 크다), 10월 말에 지금 다니는 레진엔터테인먼트를 지원했다.

이력서를 다시 고쳐서 낸게 10월 28일이었고, 회신이 온 건 10월 29일, 실무진 면접을 본건 11월 5일, 경영진 면접은 11월 11일, 최종합격 및 연봉협상 완료된건 11월 13일이었다.

그 전에 지원했던 회사가, 이력서를 보낸게 10월 초였는데 이때까지 연봉협상이 끝나지 않았었던 걸 생각하면 어마어마하게 빠른 처리였다. 게다가 그 다음번 처우제안도 만족스럽지는 못했고. 일처리가 더 빨랐으면, 그리고 “내규” 를 들먹이며 처우제안을 질질 끌지 않았으면 지금 앉아있는 곳이 다른 곳이었을수도 있지 않았을까.

회사를 옮기고 나서

생활

레진도 그렇고 이직하려고 했던 곳도 그렇고, 둘 다 서울 강남권이다보니 출퇴근 거리가 대폭 단축되었다. (이직 사유중 이게 좀 컸음) 정자/서현/판교는 최소 50분에서(서현) 한시간(판교/정자)까지 걸렸는데, 여기는 문 열고 나가서 책상에 앉을때까지 30분이니. 게다가 휴가도 많은 편이고 출퇴근시간도 매우 자유로운지라 삶의 질이 매우 올라갔다. 게다가 회사가 강남이다보니 저녁에 누구 만나기로 약속잡기도 편하고, 이런저런 세미나 같은 행사를 평일에 다니기도 매우 편하다.1

덤으로 밥값 커피값을 전부 법인카드로 해결하다보니 술값(…) 말고는 딱히 돈쓸일이 없는것도 큰 장점이다. (그러나 아낀 돈을 기름값에 탕진하고 있는게 함정)

업무

1. Google Cloud Platform

레진이 개발적인 측면에서 외부에 가장 잘 알려진건 Google AppEngine 을 쓴다는게 아닐까 싶다. AppEngine 은 고대시절(2010년쯤…?) 한번쯤 써본적이 있는데, Heroku 에 비교해서 영 못쓸물건이라는 인식이 박혀있던지라 이런저런 걱정이 많았지만 생각보다는 나쁘지 않았다. 그리고 생각보다는 좋지 않았다.

비단 GAE에 한정지을게 아니라 이런저런 Google Cloud Product 들을 보자면 제법 괜찮다. 빠르고 정밀한 앱엔진의 스케일아웃이 점이나, NoSQL이면서 RDBMS의 장점도 어느정도 가지고 있는 Datastore 라던가, 생각보다는 괜찮은 솔루션들이다.

근데 단점도 만만치 않다. 일단 앱엔진은 소켓도 쓰레드도 반쪽짜리라서2 없는 걸로 생각하는게 낫고, Datastore 는 RDBMS 처럼 인덱스 걸고 SQL(정확히는 GQL)로 RDBMS처럼 쓸 수 있다고 생각하다간 망하고, GCP API들은 버전이 올라갈때마다 하위호환성은 엿바꿔먹는 수준인데다가 동작도 제대로 보장이 안된다.3

결정적으로, 한국에서 가까운 일본 리전은 2016년 중순에나 생겼다. 물리적인 거리로 인한 레이턴시는 어떤 짓을 해도 해결이 안된다. 그렇다고 일본으로 옮기자니 cross-region replication 같은게 안되는지라 그것도 어렵고, 앱엔진 자체를 버리는 것도 이런저런 기술적 이슈 덕에 매우 어렵고, 쉽지 않은 선택이다. (이건 언젠가 또 썰을..)

앞으로 서비스를 만든다면, 무슨 일이 있더라도 특정한 서비스 플랫폼에 종속적으로 구현하거나 플랫폼에 락인되어버리는 솔루션은 절대로 선택하지 않을 것이다.

2. AWS

신규로 만든 컴포넌트들은 AWS위에다 올렸다. AWS는 EC2/ELB/Route 53정도만 써본 수준이었던지라 초보나 다름없었는데, 덕분에 이제야 AWS의 몇몇 서비스들에 대해 간신히 이해하고 있는 수준인듯하다.

기존에도 AWS에 일부 모듈이 올라가있긴 했지만, 단순히 EC2+ELB만 사용하고 있는 정도라 VPC 및 네트워크 구성부터 IAM 권한 부여나 ASG설정, 사내용 기본 AMI빌드, 배포시스템, 기초적인 ChatOps 등 바닥부터 싹 셋업했는데, AWS를 제대로 사용해본게 처음인지라 삽질도 많이 했지만 큰 경험이 되었다.

1년간 AWS를 만지작거리면서 든 소감은 : 아마존 이 무서운 놈들…

개발자가 필요로 하는 걸 거의다 만들어내고 있다. 그럼에도 불구하고 위에 썼다시피, 플랫폼 락인 성향이 강한 솔루션들도 선택해야할지는 고민이다. 일단 아직까지는 안하고 있다.4

3. Python

만화 이미지를 보여주는 이미지서버를 새로 만들면서, 자바를 고민하다가 flask+gevent 로 만들었다. 파이썬을 선택한 이유는 이미지 프로세싱 때문. 프로세싱이라고 해봐야 리사이즈 및 퀄리티 조절이긴 하지만, 일단 이미지 처리 라이브러리는 제일 흔하고 표준적인 ImageMagick을 포함해 거의 대부분이 C/C++로 되어있고, ImageIO 가 영 못미더웠던 게 크다. 그렇다고 JNI에 손대긴 더 싫고.

파이썬은 2.4시절에 좀 만지작대다가 2015년에야 asyncio 로 어플리케이션 지표를 collect/aggregate 하는 에이전트와, 관리용 서버를 flask+sqlalchemy 로 한번 만들어본게 끝인지라 고민했는데, (바꿔 말하면 사용자 대상의 상용 서비스의 프론트엔드에 써본적 없음) 이래저래 삽질도 했지만 재미있게 만들었다. 처음에는 성능때문에 고생하다가 gevent를 적극 사용하도록 뜯어고치고 나서 크게 개선이 되었고, 지금은 큰 문제없이 운영중이다.

여담으로 language switching은, 문법나 프레임워크의 사용이야 금방 적응하지만 그 안에 녹아 있는 언어나 프레임워크의 설계 철학을 이해하는게 가장 어려운 과정이 아닐까 싶다. 하다못해 네이밍이나 모듈 구조 잡는데도 이게 “Python way” 가 맞는지 의문이 드니까. 비슷한 측면에서, 아직도 자바 식의 주절주절한 이름 짓는 버릇에서 벗어나질 못하고 있다보니, PEP8의 79글자는 너무 빡빡하다.

뭐 하여튼, 파이썬은 앞으로도 적극적으로 쓸 생각이다.

기타

  1. 강남대로 차 좀 줄었을테니 이제 집에 가야겠다.
  2. 자바 이야기 : JDK8 좋다. 근데 코틀린 써보고싶다.
  3. 2016년의 또다른 특이점이라면 차덕질을 시작한건데 이것도 나중에…
  1. 덕분에 PyCON 2016 APAC 준비하기가 수월했다! 

  2. 굳이 쓰려면 쓸 수는 있지만 상황에 따라 온갖 꼼수를 다 써야 하는 경우가 많다. 

  3. API 버전에 따라 string consistency 가 보장된 API가 ​eventually consistency로 동작하는 기가 막힌 경험도 했다. 

  4. SQS나 DynamoDB를 유용함에도 불구하고 일부러 크리티컬하게는 쓰지 않고 있는데, 이런 이유도 크다.