올해가 벌써 한 달이 가까워지게 지나가고 있다.
세월은 엄청 빠르게 지나가고 있다.. 특히, 내가 나이가 먹으니 더 느껴진다.. ^^;;
작년에 대한 포스트 모텀이지만, 작년을 얘기하려면 제 작년에 N사를 그만두면서 느꼈던 시간의 아까움에 대해서 얘기를 해봐야겠다..

시간,, 정말 중요한 거 같다.. 경력이 주로 N사다 보니 참 편하게 회사에 다녔던 거 같다..
그리고 정말로 나오기 전에 롤 모델로 삼고 싶은 CTO님을 만나게 된 것이 행운이었다.. 어찌 보면 아이러니 하지만, 그분을 보면서 시간의 아까움과 뭔가를 해봐야겠다라는 생각을 강렬하게 받았기 때문이다..
그래서 결국 N사를 퇴사하고 비교적 고행(?)길로 들어서게 되었다.. ^^

그래서, 작년에 한 일에 대해서 얼추 얘기해 보자면..

1. 전 직장에서 퇴사하다..
잘한 결정이고 후회는 없다..
아키텍처링과 백엔드의 경험은 매우 좋았다.. 그리고, 당근 좋은 분들을 알게 된 게 가장 알찬 거겠지.

2. 카산드라 완벽 가이드를 번역하다.
 개인적으로 작년에 최대의 산출물이라고 생각한다. 그 이유는 번역을 하면서 오랜만에 집중해서 공부를 해본거 같다.. 선배 형하고 같이 진행을 하면서, 서로 바쁜 업무로 인해서 쉽지는 않았지만, 정말 편집자(한동훈님)를 잘 만나서 매우 만족을 한다.. 실제 업무에서 카산드라를 사용하고 있었고, 번역하면서 카산드라에 대한 경험치를 많이 터득할 수 있었다.

3. 안드로이드 앱을 런칭하다.
전 회사에서 아이폰 앱을 런칭하려고 시도했으나, 매우 힘들게 진행되는 것을 보고 답답했었다.
그래서, 지금 회사에 TO가 모바일 쪽이었고, 커리어에 대한 고민은 하긴 했지만, 우선 고하기로 했다.
그리고, 작년에 첫 타블릿 앱이 출시가 되었다. 처음 개발한 앱이라서 힘도 들긴 했지만, 그럭저럭 좋은 앱을 개발한 거 같아서 좋다.. 작년부터 지금까지 새로운 안드로이드 앱을 준비하고 있다.. 이 앱은 우여곡절이 좀 있다.. 일 하기가 매우 힘들었고, 난항도 많았다.. 그래도, 거의 개발이 완료가 되서 출시를 목전에 두고 있다..

이 내용은, 별 감정이 개입되지 않은 일련의 업무의 타임라인이라고 할 수 있겠다.

이제, 제 작년부터 준비를 했던, 실리콘 밸리에서의 개발자로서의 삶을 목전에 두고 있다.
어찌보면 영어도 못 하면서 실리콘 밸리에 있는 회사를 들어갔으니, 나름 성공적으로도 보일 수 있겠다. 
개인적으로, 미국에 있었던 반년은 매우 힘들었다. 정말 몰랐으니 덥썩 덤벼든 거였다.. 가족이 있다보니, 가족과 떨어져 있는 것이 이렇게 힘들다는 것을 뼈져리게 느끼게 되었다.
앞으로 누구한테도 가족과 떨어져서 일을 오래해야 하는 형태는 추천하지 않겠다..

그리고, 영어가 부족하다 보니, 일할때 문제가 생기곤 한다. 소프트웨어 개발은 다양한 컨텍스트 상황에서 어떻게 처리를 해야 하는지 명확하게 짚어야 하고, 결정된 내용을 잘 구현해야 좋은 소프트웨어를 개발할 수 있겠다.
그런데, 명확하게 이해를 하지 못하는게 간혹 있기도 하다.. 다행이 나는 옆에서 일하는 개발자가 영어를 잘해서 통역도 해준다.. 땡큐.. ^^
영어는 생존이 걸려 있기 때문에 열심히 해야될 필요가 있겠지만서도 개발과 영어 둘 다 집중할 시간에 대한 선택을 한다면 또 다시 개발을 잘하기 위한 시간에 투자를 할것 같다..

한국에서는 실리콘 밸리가 개발자들의 천국이라고 말하고 있다. 과연 모가 개발자들에게 어필할 수 있기에 천국이라는 표현을 과감하게 썼을까 하는 고민을 해 본다..
천국이라.. 너무 과분한 표현 아닌가? 과분을 떠나 단지 미국에서 일하는 것에 대한 환상 아닐까?
요즘의 국내에서의 개발자들에 대한 대우도 좋아지고, 인식도 매우 좋다. 기술력도 그렇게 나쁘지 않다고 생각한다.
다만, 국내의 유수의 기업에서는 소스에 대한 공개와 유지에 대한 비용문제에 대해서 좋지 않은 견해를 가지고 있는 회사들이 많고, 회사 내부에서도 기득권에 대한 유지를 위해서 소스공개를 터부시하는 문화도 한 목 하기 떄문일 것이라 생각한다..

실리콘 밸리에서 개발자로서의 삶을 살아가기 위해서, 다시금 맘 가짐을 잡자면, 잘 할수 있는것에 집중을 하자이다..
단지 수요에 비해서 공급이 못 따라가는 것이라는 느낌이라서, 경쟁력을 가지는게 현명할 대처일 수 있다는 마지막 소견이라는.. ^^

아래 내용은 제가 테스트한 내용이 아니라, 경험을 기반으로 제가 생각하는 고성능의 서비스를 위한 아키텍처링에 대한 내용입니다. 그리고, 아래 내용은 앱<->API 서버 간의 성능향상을 위한 방안에 대한 내용입니다.

요즘 상당히 많은 앱들이 네트웍으로 데이터를 전송받아서 랜더링하고, 유저가 만들어낸 데이터를 전송하기도 합니다. 그래서, 네트웍으로 데이터를 주고 받는 앱들은 서버(보통 웹서버)와의 통신에서 JSON을 표준(많이 사용하는 추세) 프로토콜처럼 사용하고 있습니다. JSON을 사용하는 아키텍처가 가지고 있는 성능저하 요소를 살펴보면, 아래의 목록을 예상할 수 있습니다.

- JSON의 사용은 파싱에 드는 비용, 데이터 사이즈로 인한 전송(3G 대비)속도 저하가 예상이 됩니다..
- HTTP/HTTPS 프로토콜을 사용하는 서버(웹 서버)를 사용해서, 연결과 데이터 전송과 수신에 오버헤드(HTTP 프로토콜의 헤더만 읽어봐도 이해가 되실 듯)가 발생합니다. 

그래서, 위의 성능저하 요소를 걷어내고 고성능의 앱을 개발하기 위한 방법으로.. 아래의 방식을 고려할 필요가 있습니다.. 아래의 형태로 개발하게 되면, 개발 비용이 증가하는 단점이 있습니다.. 하지만, 네트웍을 많이 사용하는 앱(예로 카카오톡이나 채팅앱)이라면 연결기반의 프로토콜을 서버가 제공하고, 앱이 그 프로토콜을 사용한다면, 매번 연결하지 않고 네트웍으로 데이터를 보내고 받는 것이, 위의 비 연결지향의 프로토콜인 HTTP/HTTPS와는 비교할 수 없을 정도로 빠른것을 알게 될 것입니다..

- JSON 보다는 고 성능의 데이터 직렬화 라이브러리(MessagePack, Thrift, Google Protocol Buffers)를 사용한다.
- 소켓(SSL 적용) 서버(Netty 프레임윅 등으로 개발)로 연결지향 프로토콜 기반에서 데이터를 처리한다. 이 방식의 경우에는 소켓 서버에서 클라이언트의 idle time을 적절하게 계산해서 주기적으로 클라이언트의 소켓을 제거해 주는 로직이 필요합니다.. 이 로직이 없을 경우, file descriptor가 부족해 지겠죠.. ^^

당장은, 필요하다고 느끼지 못하거나, 너무 오버한다고 생각할 수 있으나, 기본적으로 유저가 많은 포털의 앱이나, 이미 많은 유저가 사용하는 앱들은 프로토콜과 데이터 형식만 바꿔도 상당한 성능향상을 가져올 수 있을 것이라 생각합니다.. ^^

전 회사를 퇴사하면서 생각했었던 내용을 끄적여 보는, 포스트 모텀이다..
전 회사는 스타트업 회사로, 재직 기간은 대략 10개월 정도로, 경력에서 제일 짧은 회사생활을 했다. 짧아서 그런지, 전 회사에서는 긴 프로젝트 했다는 느낌이다..

요즘 아이폰이나 안드로이드 앱의 개발주기가 2개월로 싸이클이 도는 지금의 상황을 보면, 스타트업에서 10개월은 긴 시간이라고 생각한다. 10개월의 시간 동안 일은 끊임없이 계속되었으며, 그 와중에 개인적으로만 싸이클을 끊어서 작업을 진행했었다.

이 프로젝트에 대한 성공 vs 실패의 관점에서 질문한다면, 개인적으로 45 vs 55의 포인트를 주겠다.

이 포인트는 주관적인 점수로, 내가 퇴사를 했고, 9년 동안 주로 서비스를 개발했던 경험상 서비스의 승패는 기술력이나 아이템보다 다른 요소로도 성공의 포인트를 잡을 수 있을 것으로 생각하기 때문이다. 다른 요소가 무엇이냐고 물어보면.. 모르겠다.. 경험에서 오는 막연한 기대감일 수 있다.. ^^;; 

그리고 퇴사하기 2달 전 개발팀을 맡게 되었지만, 미국 일정으로 제대로 생각한 바를 이끌어보지 못하고 나오게 되었다. 나오기 전에, 조직과 업무와 일하는 스타일에 대한 전체적인 개편을 해서, 나이스한 형태로 짧은 기간의 마일스톤으로 프로젝트의 사이클을 원했다. 그러기 위해서는 대표의 마인드와 기존에 없어 보이지만 나름 기득권을 쥐고 있는 사람들의 희생이 필요했다.. 하지만, 나름 기득권을 쥐고 있던 사람들은, 희생을 정말로 싫어했다. 서비스를 핑계로..

다음으로, 개발팀 구성과 CTO의 역할에 대한 내용을 적어볼까 한다. 네가 어쭙지 않게 CTO의 역할에 대해서 끄적일 수 있느냐에 대한 질문에는, 전 직장에서 바로 위가 CTO였고, 개발팀은 1개였고, 팀장을 했으니 적어볼 만하다고 생각한다. 또, 퇴사하고 다른 스타트업에서 CTO 제의도 받아 봤으니, 적어봐도 되지 않을까 한다.

초기 개발팀 구성은 완전히 실패했다. 개발을 잘 모르는 대표님과 CTO님의 선구안은 여지없이 볼에 방망이를 휘두른 격이라고 생각한다. 중간에 매우 좋은 타자와 투수를 영입도 했었다.. 하지만, 선수 관리를 못해서 이런 분들 다 나가버렸다.. 나도 내 업무를 쉽게 쉽게 맡아 가시던 그 좋은 타자분이 나가실 때, 나가려고 생각을 했었다.. 흠.. 하지만, 초창기 개발팀 멤버로, 책임(?)감 같은 것에 메여서 못 나갔다. 

3-Tier와 Scalable한 시스템을 기본으로 설계와 개발을 하였지만, 현실적인 문제로 2-Tier와 나름 백엔드는 Scalable한 시스템으로 개발해서 서비스가 돌아가게 되었다. 10개월 동안 개발해서 서비스 하는 게 지금의 서비스 정도라면 문제가 있었을 것이라고 웬만한 개발자들은 감을 잡을 것이다. 굉장히 큰 문제가 있었다. 바로, 서비스의 기본인 웹을 개발하시는 분들이 초보시다.. 엥, 그런데 경력들이 많다.. 경력들이 많다는 것은 나이가 많다는 거라서 회사의 자원 투입대비 산출물들이 영 마음에 들지 않았다.. ^^;; 지금이야 괜찮다라고 생각을 하고 계실지 모르겠지만, 내가 보기에는 아직도 멀었다. 국내 N모사들의 웹 개발의 반도 따라가지 못하는 느낌인데.. 반도 못 따라간다는 것은 HTML + CSS로 맨 바깥의 UI가 만들어지고, 만들어진 UI에 대한 고민이 기술적으로 없다는 것이다. 하다못해 javascript나 css를 왜 합쳐야 되는지도 잘 모르는 느낌이었다..

그래서, 퇴사하면서 개발자로 스타트업으로 이직하는 데 필요한 내용(돈은 모르겠다)을 적어보면, 대략 아래와 같다.

-       CTO가 정말 능력 있는 사람인지 보자.

-       몇 명 안되기 때문에, 개발자들의 레퍼런스를 확인하고 들어가자.

-       면접을 볼 때, 당하지만 말고 면접을 봐 보자.

-       기 제품이 있으면, 제품을 보고 쓰지 않을 것 같으면 들어가질 말자. 

개인적으로 참 아쉬운 10개월을 보낸 것 같다. 정말 세상 물정 모르고 있었다는 딱 그 느낌이랄까? 이제는 이런 시행착오 없고, 훌륭한 개발자들과 일을 할 예정이다. 현재 일에 대한 기대와 우려는 다시 한번 긴장감으로 일을 마주하게 하는 원동력인거 같다. 어떻게 하다 보니, 전 회사에 대한 안 좋은 점만 부각한 것 같은데, 포스트 모텀의 주된 목표가 안 좋은 점을 개선하자기 때문에, 개선방향은 여기서는 적지 않겠다.. 이미 퇴사하기 전에 10번 정도 회의하면서 얘기했으니 말이다.

이상, 포스트 모텀을 적어봤다. 앞으로 진행되는 프로젝트는 이런 식으로 포스트 모텀을 하는게 아니라 동료와 맥주 한잔 마시면서 자유롭게 회사의 시스템으로 녹여봤으면 좋겠다..

눈 앞으로 다가온 물리적 웹의 시대에서 Physical Web, Object, Activity 등의 새로운 개념을 읽고, 포스팅 하신분께 요청해서 정보도 받고 해서, 좀 더 자세히 Activity Stream이라는 것에 대해서 살펴 보았습니다.. 포스팅 하신분께 감사드립니다..

포스팅 하신 분의 도움을 받아서, 제가 파악한 내용은, http://activitystrea.ms/ 이 Object의 Activity에 대한 정의, 그 정의를 바탕으로 한 관계에 대한 포맷에 대한 표준(?)을 제시하고 있더군요.. ^^.

결국, 데이타를 synd하는 포맷을 정의하고, 포맷된 데이타를 통해서 Object간의 관계를 알 수 있을 거 같습니다. 물론, 위치 정보 까지도요... 지금 하는 프로젝트(소셜 합니다..ㅋㅋ)에 써먹기에 참 좋은데 말이죠...

여튼, 기존의 관계가 들어있지 않았던 많은 데이타들이, 관계, 위치등을 기반으로하는 포맷으로 변환이 되서 유저들간의 관계를 좀 더 쉽게 풀어 내기를 기대해 봅니다..

흠...
현재 개발된 프레임웍의 구조는 master, slave reactor가 있고.. slave reactor가 네트웍 이벤트를 디스패칭을 하고있는 구조이고, 또 socketchannel의 read 메쏘드를 통해서 bytebuffer를 worker 쓰레드에 넘기는 구조인데요..

최근에 큰 사이즈의 이미지를 전송하다 보니....
worker 쓰레드에서 socketchannel의 read 메쏘드를 호출하는 것이 더 맞아보이기도 하고..

흠.. socketchannel의 read 메쏘드를 호출하는 객체가 slave reactor가 되야 될까요?? 아님 worker 쓰레드가 되야 될까요??

고민이네.. ㅜㅜ

라이브러리..
 이넘 덕분에 프로그래밍이 많이 쉬워졌죠.. 특히, 자바진영에서는 Apache 재단의 지원이 매우 강력한 힘이 되고 있는게 현실이죠..
라이브러리를 사용하기 위해서는 의존하고 있는 라이브러리도 함께 있어야 제대로 동작을 하겠죠..
그리고, 라이브러리는 자신을 사용하는 클라이언트에게 에러 상황(Exception)에 대한 내용도 알려주겠죠?..

ㅎㅎ
위 상황을 가정하면, 왜 라이브러리가 로깅을 해야 될까요??
로깅이 debugging을 위한 거라고 가정을 한다면, 그 몫은 에러 상황을 리턴받은 클라이언트 몫이 아닐까요??

흠.. 정답이 없어서 모라 하긴 그렇지만..
개인적으로 라이브러리가 로깅을 하는것은 좋지 않다고 생각을 하는데..
혹시 저와 다른 생각이 있으신 분들은 답글 좀..  ^^
 

자바를 주로 하는 개발자로써 재직중인 회사가 망한다거나, 다른 회사에 넘어가는 거보다 훨 슬픈 느낌이네요..
펭귄이 위로해주는게 참 의미심장합니다. ^^;;

http://blogs.sun.com/jag/entry/so_long_old_friend

당장 시작하는 회사들 혹은 서비스들을 위해서 Twitter나 Facebook에서 사용하고 있는 NOSQL 분류의 Cassadra같은 DB가 필요한가?? 필요하다고 생각하는 것은 정말로 중규모 이상으로 서비스가 될 것으로 예측을 하게 되면 필요하게될 것이다. 하지만, 그래도 약간의 불확실성과 성능/비용의 두마리 토끼를 잡기위한 구성으로는 아래의 조합이 가장 좋지 않나 생각합니다.

memcached + mysql(clustering)

성능/비용을 감안해서, 위 조합보다 더 좋은 구성으로 서비스의 백단을 구성하는 모델이 있으면, 댓글 부탁드립니다.. ^^