[서평] 역사의 역사

역사의 역사

저자: 유시민 

 

간만에 블로그를 그리고 몇 광년만에 서평을 쓰게 됐습니다. 유시민 작가가 글을 썼다고 하니 바로 읽었습니다. 긴 여행중 비행기 안에서 읽게 되었는데 참으로 괜찮은 책이였습니다. 나도 모르게 좁은 비행기에서 잠이 들게 할 수 있는게 강력한 수면제 말고 또 있다는 것을 알게 됐습니다. 각설하고 쫌 졸리긴 하지만 책 자체는 흡입하는 매력이 있습니다. 아마도 졸았던건 제가 피곤해서 그런 것이겠지요. 

  책은 유시민 작가가 생각하는 역사를 다루는 저자와 저작물을 역사적으로 나열하고 있습니다. 헤로도토스 (그리스 말로는 에로도토스라고 몹시 에로하게 불리더군요)와 투키티데스의 책부터 제레드 다이아몬드와 하라리의 책까지를 주욱 이어나가고 있습니다. 그 와중에 평소에는 잘 안 다루어지는 이슬람 문화의 역사 이븐 할둔의 책들과 우리 나라 역사를 다룬 책까지도 누구나 들어도 알만 한 책들과 또한 나는 잘 모르지만 유시민 작가가 좋아하는 역사 책들까지 본인이 이야기 하는 역사의 이야기의 흐름에 잘 맞추셨습니다. 

  그래도 느껴지는건 역사책을 소개하기 위한 책 같다는 느낌이 강합니다. 역사를 좋아하는 나도 잠깐 정신이 아스트랄로 빠질 정도니 저보다는 역사를 안 좋아하시는 분의 평이 궁금합니다. 

AWS 에서 ELB 설정의 교과서

요즘 왠만한 웹 서비스를 만들어서 런칭을 하는 경우에도 https 를 감안해야 합니다. 아마존 웹 서비스(AWS) 에서 서비스 만들어서 런칭을 할 때도 마련해두면 편하게 작성할 수 있을거 같은 교과서적인 튜토리얼을 발견해서 첨부합니다. 비록 설명은 자바 기반이지만 웹서비스에 대해서 어느정도 관심 있는 분이라면 필히 자신이 쓰는 플랫폼으로 변경해서 적용할 수 있으리라 봅니다. 


  https://goo.gl/1guuCC



걸그룹과 보이그룹이 판을 치는 회사로 옮겼다.

회사를 옮기기 전 고민하고, 옮긴 후의 바쁜 과정이 뒤를 이은터라 블로그를 못 만지다가 간만에 만지게 됐습니다.

그렇습니다!! 제가 옮긴 회사는 걸그룹과 보이그룹이 판을 치며 새로 데뷰하는 걸그룹들이 인사하러 오는 업체입니다. 뭐 아직 국내 서비스 전이긴 하지만요. 


그래서 이제 걸그룹들을 (보이그룹은?..) 자주 보겠거니 했는데.. 

역시나 프로그래머 데이터만 죽어라고 보고 있네요. 프로그래머 인생이 뭐 그렇지 -ㅅ- 


산적해 있는 일을 빠르게 처리 하기 위해서는 파이썬 만한 친구가 없군요. 정말 후다다다닥 일을 처리 할 수가 있습니다. 역시 파이썬 자주 애용하게 되지요. 간단한 에디터로도 만들 수가 있으니 얼마나 멋집니까 ㅋㅋ 


두서 없이 썼지만 앞으로 종종 글을 남길 예정입니다. 

[Deep Learning] seq2seq 를 이용한 챗봇 - 프론트 엔드 변경


프론트 개발이 가능하신 개발자 분들이 제 오픈소스 프로젝트에 참여해서 프론트 엔드를 꾸며 주었군요. 모바일도 적용이 되어 있습니다. 


데모: https://chat.crazia.org/

소스: https://github.com/crazia/NM-chatbot


딥러닝 관련 과거 포스트들: 

1. AI 학 개론 (초보 개발자를 위한 정리) 

2. seq2seq 를 이용한 챗봇 (Neural Network Chatbot)

3. seq2seq 를 이용한 챗봇 - 웹버젼

4. seq2seq 를 이용한 챗봇 - 자동 진화 버젼

5. seq2seq 를 이용한 챗봇 - 형태소 분석을 추가한 버젼



(초보) 개발자가 기획 주도 회사에서 일할 때 마음 가짐

큰 회사를 제외하고 일반적으로 작은 형태의 IT 회사는 다양한 형태가 존재하지만 무리하게 일반화를 굳이 하자면, CTO (Technology) 주도의 회사와 CPO (Product) 주도의 회사가 있습니다. 


쉽게 말하자면 기술 주도의 회사와 기획 주도의 회사 입니다. 각각의 장점이 확실히 존재합니다. 기술 주도는 제품이 단순하고 개발 이터레이션이 짧게 돌아가고, 기획 주도는 창의적이고 다양한 시도를 하기에 기존하고 다른 제품이 나올 확률이 높습니다. 어떤 개발 스타일을 제가 좋아하는 것은 별도로 치고도, 잘 생각해 보면 회사의 개발 방향이 이런 형태중에 한가지에 가까울 수가 있습니다. 


다만 개발자 출신으로서 생각해 보기에는 (초보) 개발자는 기술 주도의 회사가 더 편하겠지요? 아무래도 CTO 가 주도하는 사이클을 몸에 익히면 추후에 팀장이나 또는 본인이 CTO 로 나아갈 때 도움이 됩니다. 


그렇다고 기획 주도의 회사가 (초보) 개발자가 일하기 힘들기만 한 것이냐? 그렇지는 않습니다. 고난 속에서도 배우는 것이 있듯이 나중에 기획이 바꼈을 때 어떻게 기획자들과 싸워서 일정을 쟁취해야 하는지에 대해서 확실히 배울 수가 있습니다. 다만 변경되는 일정에 대한 짜증은 별도이지만요. 즉 심각하게 힘들게 하는 SI 의 대비를 미리 할 수가 있다는 것입니다. 농담 처럼 이야기 하지요 SI 에 계속 있으면 안되지만 군대 가듯이 SI 를 해 볼 필요는 있다고 말이죠. 그리고 이 바닥에서 말하듯이 개발자에게 있어 군대란 .. 


즉 처음의 논조와는 달라졌지만 (초보) 개발자가 기획 주도 회사에서 일할 때 


1. 자주 기획이 변한는 것에 대한 불만

 - 기획이 자주 변경 되는 건 당연한 일이 라고 여겨야 합니다. 

 - 잘 교육된 기획자가 아니면 아닐 수록 생각을 확정 못 시키고 자주 기획이 변경됩니다.


2. 기획이 바꼈는데도 일정을 고정할려고 하면

 - 절대 납득하고 날 새시면 안됩니다. 

 - 그 기획자에게도 기획이 바뀌면 일정이 변경된다는 것을 교육 시켜야 합니다. 그래야 그 분도 나중에 다른 개발자랑 일할 때 신경을 써 줍니다. 


3. 지속적으로 일정 관리에 대한 분위기 조성

 - 어떠한 일이 있더라도 기획이 바뀌면 일정은 무조건 변경되야 한다는 것을 모든 개발 참여자들이 인지하는 분위기를 조성해야 합니다. 

 - 그래서 개발 시작 전에 기획이 확정 되어지고 그 기획은 마일스톤 (or 스프린트) 기간 내에는 변경이 안되게 확답을 받아야 합니다. 

 - 개발 일정이 변경 되는 것에 대한 원인이 기획 변경에 있다는 것이 인지되면 기획자들도 조금 더 노력해서 기획을 확정 지으려고 합니다.


최근 회사 개발자가 확정 안되어진 기획서를 가지고 개발하는 데 짜증을 내길래 달래주다가 정리한 글입니다.