2014년 12월 18일 목요일

기년회 준비를 위한 생각 정리

2년전 AC2라는 과정을 통해 애자일을 배우게 되었다. 그리고 AC2 라는 모임에 소속하게 되었는데 올해는 "기년회"라는 것에 참석하기로 하였다.

"기년회"에 대한 것은 "망년회 대신 기년회"라는 글을 참조하면 자세한 것을 알 수 있을 것이다. 간단히 말하면 올한해에 대한 회고인 셈이다.

이번 기년회에서는 사전 미션이 있다. 아래의 질문중 공유하고 싶은 3가지에 대하여 답을 준비해 가는 것이다.

  1. 올해 잘 산 물건?
  2. 올해 좋았던 책?
  3. 올해 좋았던 장소?
  4. 올해 인상 깊었던 사람은?
  5. 올해 고마웠던 분은?
  6. 올해 좋았던 영화는?
  7. 올해 꾸준히 했던 것들은?
  8. 올해 의외의 성공은? (내 예상보다 훨씬 더 잘된 일들)
  9. 올해 잘 쓴 10만원 이하의 소비는?
  10. 올해 좋았던 모임?
  11. 올해 큰 실수?
  12. 올해 눈물이 나왔던 순간?
  13. 올해 뿌듯했던 일은?
  14. 올해 새롭게 접한 것은? 
  15. 올해 나 답지 않았던 순간은? 
  16. 올해 기분 좋았던 경험은?
  17. 올해 당황스러웠지만 잘 대처했던 순간?
  18. 올해 왠지 모르겠지만 그냥 떠오르는 순간은?
  19. 올해 미뤄오다가 해치워서 속 시원한 일은?
  20. 올해 가슴에 남는 명언은?
  21. 올해 칭찬을 받았던 일은?
  22. 올해 내가 만든 것?
  23. 올해 수련한 것?
  24. 올해 나에게 도움된 습관?
어떤 질문에 대한 답을 공유하면 좋을지 고민도 할겸 답변도 마련해 둘겸 정리해 보려고 한다.

가장 먼저 답변을 정리해 볼 것은 "1. 올해 잘 산 물건?" 이다.

답변은 "맥북 프로" 이다. 취미이자 직업은 프로그래머로써 좋은 도구를 구매하게 된 것이다. 참고로 기존에 쓰던 것은 맥북 에어였다. 에어로도 적당했지만 좀 더 다양한 것을 해보려고 하니 작게 느껴져 업그레이드하게 되었다. 기존에 동네 공터에서 맨땅 축구를 했다면 맥북 프로는 그래도 잔디가 깔린 멋진 구장이 된것이다. 물론 월드컵 운동장 처럼 좋은 것은 아니다. 맥프레(맥북 프로 레티나)를 만나면서 몇가지 새로운 도전을 하게 되었다. APM 만드는 일에도 도전해보고 최근 유행하는 Cloud 환경 구축도 해보고하면서 기술적인 역량을 늘릴 수 있었다. 아쉽게도 성과를 내지 못했지만 많은 것을 학습 할 수 있었다. 그리고 좋았던 점은 다양한 무료 어플리케이션으로 생활 리듬을 만드는 일에 도움을 받았다. 도커를 이용해서 로컬 위키를 만들어 기술 정보를 기록하기도 하였고, 원더리스트로 할일 관리도 하였다. 물론 웹에서 무료로 사용할 수 있는 서비스들이 많으나 public 한것보다 private 한 것이 조금은 마음의 안정감을 주었기 때문에 앱을 많이 이용하였다. 남들이 볼 때 크게 차이가 없겠지만 맥북을 사용하는 것은 좋은 장남감을 항상 지니고 다닐 수 있기 때문에 언제나 놀거리가 있고 그것들이 한곳에 집중되어 있어 나로써는 즐거운 시간을 늘 가질 수 있었다.
여튼 맥북은 올해 나를 성장시켜준 도구 중의 하나인 셈이다.

두번째 답변은 "올해 큰 실수?" 에 대한 답변이다.

올해 가장 큰 실수는 지금도 수습중인 타인의 욕망을 쫓아 회사를 옮기려했던 점이다. 먼가 많이 배우고 멋지게 일할 수 있는 회사에서 일하고 싶었다. 사용자 트래픽이 많아 어플리케이션을 튜닝하고 복잡한 엔터프라이즈 어플리케이션을 만드는 일을 하고 싶었다. 여러 곳에 이력서를 넣고 면접 과정을 거쳤다. 준비 없이 가서 망신 당한 적도 있고, 이후 잘 준비해서 합격한 곳도 있다. 나의 레벨보다 더 많은 것을 요구하는 곳에 도전해서 멘붕이 된 적도 있다. 하지만 준비 과정에서 내가 타인의 욕망을 쫓고 있다는 것을 알았다. 면접을 준비하면서 많은 것을 학습할 때 비로서 이전에 나는 게을렀다는 것을 알았다. 일을 하면서 배울 수 있는 곳을 상상했는데 그게 아니라는 것을 알았다. 관심이 있다면 얼마든지 스스로 학습할 수 있다는 것이다. 스스로 환경을 만들고 스스로 트래픽을 발생시킨다면 얼마든지 경험할 수 있다는 것을 알게 되었다. 그리고 평범한 일에서도 많은 것을 생각해본다면 얼마든지 새롭게 해볼 수 있다는 것을 알게 되었다. 
그리고 새로운 회사에 들어가게 되면 또 적응해야하고 사람들과 친해져야하는데 또 시간과 에너지를 써야한다는 것이다. 먼가 낭비한다는 느낌이 많이 들었다. 게다가 내가 하고 싶은 일보다는 조직을 위해 일을 해야하는 경우가 많을 것이라는 것이다. 먼가 잘못생각했던 것이다. 지금은 내가 스스로 일을 만들어서 하고 있는데 이것이 주는 행복감을 완전히 무시했던 것이다.
여튼 그래서 제자리가 되었지만 수습중에 있다. 수습하고 있다. 수습이 되었으면 좋겠다.

세번째 "올해 수련한 것"
올해 수련하였지만 잘 못하고 있는것이 "기록"이다. 바빠지거나 힘들어하거나 게을러져서 기록하는데 소홀했다. 반백수 생활을 할때도 시작한지 15일만에 기록이 멈추어버렸다. 저널이나 일기처럼 꾸준히 쓰는 것을 못해 조각조각 여기저기 남기기도 해봤지만 이도 얼마가지 못했다. 그래서 이런저런 도구도 사용해 보았다. 위키, 메모, 블로그, 노트... 엉망진창이다. 그래도 최근들어 기록하는 작업에 조금씩 습관이 붙기 시작했다. 기록의 문제점은 무조건 잘 정리하려고 했다는 것이다. 프로그램을 작성하면 틈틈히 리팩토링을 해서 프로그램의 품질을 높이는데 글도 똑같이 하면 된다는 것을 깨닫게 되었다. 그 다음부터 마구잡이로 글을 쓰기 시작했다. 좋은 글을 쓰는게 아니라 기록을 남기는데 그래도 충실히 하려고 하니 기록의 양이 늘어나기 시작했다. 물론 처음 생각했던 것처럼 글을 수정하는 작업은 거의 없다. 나중에 관련 글들을 모아 정리할 수는 있겠지만 평상시 글은 그냥 엉망진창으로 남겨둔다. 머 어찌됐든 기록이 남기 때문이다. 현재 기록을 위해 남기는 것은 크게 변하지는 않았지만 메모, 위키, 페이지, 낙서, 블로그, 원더리스트 등등 다양하게 사용하고 있다. 최종적으로 공유하고자 할 때는 키노트에 정리하려고 한다. 좀 더 나아가면 슬라이드쉐어로 공유까지 생각하고 있다. 내년에는 좀 더 체계적이고 다른 이들과 함께하는 방식으로 하려고 한다. 일단 회사내에서 프로세스를 만들어 진행하려고 한다.

일단 이정도로만 정리해두자.

2014년 12월 17일 수요일

실시간 빅데이터 분석 아키텍처를 탐색하다.

얼마전부터 자꾸 실시간 빅데이터 분석에 대한 일련의 사건들이 계속 발생하였다.
빅데이터에 대해서는 별로 관심을 두려하지 않았는데 나에게 하이프 싸이클의 계몽단계(Slope of Enlightenment)로 다가왔나보다.

어찌됐든 내년에는 실시간 빅데이터 분석 시스템을 만드는 것이 목표중의 하나가 될 것 같다. 그래서 빅데이터 아키텍처에 대하여 살펴보기로 했다.
먼저 빅데이터를 다루는 개발자들이 작성한 글들을 쭈욱 살펴보니 알아두어야 할 용어가 몇가지 있었다.


  • CEP (Complex Event Processing)
  • ESP (Event Stream Processing)

빅데이터 시스템의 종류라고 하는데 EDA(Event Driven Architecture) 기반의 시스템으로 CEP 는 ESP 의 기능에 패턴 감지 기능이 추가된 것이라고 구분하기도 한다. CEP 와 ESP 를 알아보기전에 EDA 에 대하여 먼저 알아보기로 하였다.

EDA 란 분산된 시스템 간에 이벤트를 생성, 발행하고 발행된 이벤트를 필요로하는 수신자에게 전송, 필요에 따라 처리하는 시스템 아키텍처라고 한다.

잘 정리된 블로그 글이 있어서 처음에 개념을 잡는데 도움을 받았다.


EDA 에는 SEP(Simple Event Processing), ESP(Event Stream Processing), CEP(Complex Event Processing) 가 있으며 Event Generator, Event Channel, Event Processing Engine 로 구성되어 있다.
잘 몰랐던 점은 EDA 가 SOA 와 같이 언급된다는 것이었다. (최근에는 MSA - MicroService Architecture 와 SOA 를 많이 비교한다.) 관련된 자료에서는 Domain EDA 라고 표현하고 있다.


다시 빅데이터 아키텍처로 돌아오면 ESP 는 실시간 빅데이터 분석에 좀 더 특화된 것이고  CEP 는 패턴 감지 기능을 포함하여 ESP 보다 상위개념으로 생각할 수 있다.

최근에 살짝 살펴보고 관심을 두었던 Spring XD 도 CEP 엔진으로 구분하기도 한다. 이외에도 Esper, Drools 가 있고 ESP 에는 Storm, Spark 등이 유명한데 상세한 구분으로 정리한 글이 있으니 참고할 수 있었다. 


전반적인 CEP 에 대한 사항과 ESP 를 기준으로 상세하게 설명한 글이 있는데 이것만 살펴봐도 많은 도움이 되었다.


해당 슬라이드에서는 빅데이터 분석 시스템을 만들기 위한 절차도 소개하고 있는데 간단히 요약하면 다음과 같다.

이벤트 정의 -> EPL 정의 -> Output Adapter 개발 및 등록 -> Input Adapter 개발 및 등록

최근에 가장 많은 레퍼런스를 가지고 있는 실시간 빅데이터 분석 아키텍처는 Apache Kafka + Storm 이거나 Apache Kafka + Spark 가 있다고 한다. 개인적으로는 Apache Kafka + Spring XD 를 하고 싶어 비교자료를 찾아보니 다음과 같은 글이 있었다.


성능 비교가 있었으면 좋으련만 비교 자료는 찾지 못했다.

참... 하다보니 Java Logging Framework 까지 찾아보게 되었는데 이건 나중에 정리해 봐야겠다.

실제 개발이 진행되면 개발하는 과정을 상세히 정리해 보도록 해야겠다.

글을 올린후 storm 과 spark 를 비교 설명한 글이 새로 올라왔다.

http://www.itworld.co.kr/news/91022

추가적인 비교 자료

http://www.slideshare.net/ptgoetz/apache-storm-vs-spark-streaming

Spark 의 핵심에 대한 설명

http://www.slideshare.net/yongho/rdd-paper-review


2014년 12월 15일 월요일

지식 공유를 위한 나의 생각

애자일을 배우기 시작한지 2년남짓되었다.
이전의 N사에서의 애자일 경험은 신비롭기까지 했다. 기존의 SI 를 할때 언제 어떻게 연락이 올지 몰라 마음조렸던 것을 완전히 잊게 해주었던 것이 애자일이었다.
체계적으로 일에 대한 정의를 하고 일정을 정한다. 개발에 있어서는 TDD 를 이용하여 사전에 충분한 버그를 찾아 해결한다. CI 툴을 이용해 예상치 못한 소프트웨어의 품질을 측정한다. 빌드배포툴을 이용하여 손쉽게 상용서버에 반영한다. 이 모든 작업은 서로 공유하고 공개하여 누구나 다 작업을 이해하고 진행할 수 있다.
기존은 이와 정반대였다고 보면 된다. 일을 숨기고 수작업으로하고 시간에 쫓겨 동작하기만 하면 코딩이 멈추었다. 그런데 이런 내용은 "엔터프라이즈 SOA" 책을 들여다보다 나온 문구를 보고 "남들도 심지어 외국사람들도 똑같은 경험을 했구나"라고 생각했다.
그렇다면 나의 경험과 나의 변화가 결코 방향이 틀리지 않았다는 것이다. 실제로 나와 같이 생각하는 사람들이 많은 것이다. 반면에 나와 같이 제대로 지도를 못받거나 학습을 못한 경우도 있을 것이다. 나는 이미 시간이 지나 늦은 부분이 있지만 나의 후배들에게는 아직 기회가 있다. 그래서 후배를 양성하는 일에 매진하기로 했다.
아직 정리해야할 것이 많으나 방향은 명확해졌다. 이런 글을 남기는 이유도 더이상 나의 다짐이 흔들리지 않기 위해서이다.
흔들림의 첫번째 유혹은 현재 면접이 진행중인 대기업의 유혹이다. 돈도 많이 받을 수 있고 좋은 환경을 제공하고 적절한 명예욕도 챙겨준다. 하지만 곰곰히 생각해보면 돈을 받는만큼 나의 시간을 팔아야한다. 좋은 환경은 돈이 많아 만드는 것이나 경험상 내가 만들면 된다. 특히 개발환경은 많은 오픈소스의 발전으로 더이상 돈이 문제가 되어가지 않고 있다. 명예욕은 나의 마음의 문제다. 주변의 괜찮은 사람들은 좋은 회사를 다니기보다 좋은 일을 하고 있다. 그들과 많은 이야기를 하면서 생각을 바꿀 필요가 있다.
흔들림의 두번째 유혹은 자신의 노하우를 갖추어 몸값을 높이는 일이다. 내가 경험하고 공부해서 알고 있는 것들은 너무 쉽게 다른 사람에게 준다면 나의 가치가 떨어지는것 아니냐는 이야기를 듣고는 한다. 그런데 나의 목표는 나의 가치를 높이는 것이 아니라 조직의 가치를 높이는데 있기 때문에 결코 그렇게 생각해서는 안된다. 게다가 나의 노하우를 알려주려고 해도 대부분 흡수하지 못하거나 무시하는 경우가 많다. 실제로 나도 그런적이 있다. 잘 알지 못하기 때문에 그냥 무시하는 경우가 많다. 지금은 하나하나 놓치지 않기 위해 기록하고 나중에라도 꼭 알기위해 노력한다. 아마도 이런 점이 흡수하지 못하는 자와 차이점일 것이다. 여튼 이런 이유들로 노하우를 알리는 것에 대하여 아깝게 생각하지 않는다.
후배 양성에서 가장 좋은 점은 생각의 차이를 알 수 있다는 것이다. 내가 놓치고 있던 것을 후배가 질문하게 되기도 하고 설명하면서 내 몸에 체화된다는 점이 가장 좋은 점이다.
체계적인 방법과 스케쥴 관리를 한다면 아마도 1년 뒤에는 내가 알고 싶은 것들을 체화할 수 있을 것이라 생각한다. 아직은 시작단계에 있지만 2년동안 시행착오를 바탕으로 매우 치밀하게 움직일 것이다.
여튼 그냥 생각나는 것을 정리해 보았다.

2014년 12월 14일 일요일

린캔버스를 작성하자

블로그를 시작한지 1년도 안되었다.
야심차게 시작했던 모든 상황들은 실패의 연속이었고 게으름의 연속이었다.
그래서 모든 상황들을 바꾸고 차분히 기록을 남기기로 했다.
과정에서 많은 선택이 있었지만 어찌됐든 다시 기록을 남기고자 한다.

시작함에 있어서 구체적인 목표를 만들고자 한다.
사용하고자 하는 도구로 린캔버스를 선택했다.

우선 현재의 문제점을 정의했다.


  • 실제적인 개발 능력이 부족하다.
  • 아키텍처 설계 능력이 부족하다.
  • 어학 능력이 부족하다.
개발 능력이 부족하다. 알고리즘의 활용이나 프로그래밍은 꾸준히 연습하고 있기 때문에 어떤 면에서는 실무자들보다 나은것이 있다. 하지만 스프링이라든지 네티등의 프레임워크를 활용하고 개발하는 능력이 부족하다. 그래서 나는 스프링을 자유롭게 사용하고 네티를 자유롭게 활용하는 등 프레임워크 활용 및 개발 능력을 가지고 싶다. 
이에 따라 매달 한가지를 지정하고 이를 개발하도록 하고자 한다. 전체적인 목표는 가상의 커머스 사이트를 만드는 것이다. 웹, 모바일을 지원하고, 백엔드에서는 배송관련 처리, 정산관련 처리등의 작업이 발생하도록 한다. 이를 위해 필요한 기술들을 정의하고 매달 한가지씩 개발할 내용을 정의하고 개발한다. 물론 정확한 업무의 적용이 아니라 가상 업무의 적용이기 때문에 임의로 정의한 프로세스가 동작하도록 한다. 총 12개의 아키텍처 설계와 개발을 수행하여 동작하는 제품을 만들고 시연하도록 한다.

아키텍처 설계 능력이 부족하다. 머리속에 알고 있는 것과 구체화해서 표현할 수 있는 것이 확실히 다르다는 경험을 했기 때문에 단순한 설계 능력이 아니라 설득할 수 있는 능력을 키우는 것이 중요하다. 때문에 특별히 지정한 아키텍처를 설계하고 가상의 문제를 발생시켜서 이를 해결할 수 있는 아키텍처를 설계한다. 예를 들어 대표적으로 SNS 에서 다량의 친구들의 글들을 가져와서 표현할 수 있도록 하는 아키텍처의 설계이다. 트래픽을 어떻게 분산할지 설계해 보는 것이다. 그리고 다른 사람들에게 표현하여 장단점을 확인하는 것이다. 다른 사람이란 가까운 도반들에서 시작하여 아키텍처 그룹으로 발표해보는 일을 수행한다.

어학 능력이 부족하다. 읽기 위주의 치중했던 영어를 실용적인 회화 위주로 변경하도록 한다. 실제 회화 횟수를 늘리고 잘 알아들을 수 있는 영어 능력을 만드는 것이 목표이다. 냉정하게 현재의 실력을 인정하고 차근차근 준비하여 여행에 불편이 없도록 한다. 여행 영어가 쉬워지면 영어 세미나등을 참석하여 난이도를 높여보도록 한다. 우선 전화영어부터 시작하도록 하자.

지금은 서술형으로 풀어보았지만 이를 린캔버스로 만들어 두었다. 위의 글은 초심이 되겠지만 작성한 린캔버스는 지속적인 수정을 통해 구체화되고 수정될 것이다. 내년 말에는 어떻게 변경되었는지 상세하게 비교하여 글을 작성해보도록 하자.

린캔버스에는 표기하지 않았으나 기록에 대하여 소홀히 하고 있으니 이를 강화하는 것도 잊지말자.