예전에는 혼자서 개발하면서 성장할 수 있는 시기가 있었지만, 요즘은 팀단위로 개발을 진행하기 때문에 빠르게 성장할 수 있지만, 자신의 파트에 특화되는 경향이 있습니다. 물론 지금도 파트를 오가면서 개발을 할 수는 있지만 예전만큼 쉽지 않습니다. 저도 실제로 클라이언트 개발을 하다가 서버 사이드로 옮긴 경우 입니다. 


  예전 다니던 회사에서 공개 개발자 모집을 한 적이 있습니다. 들어온 원서의 비율을 체크 해보니 안드로이드, iOS, 백엔드 개발자의 비율이 8:1:1 이였습니다. 클라이언트와 서버 비율로 따져보면 9:1 입니다. 

  클라이언트 사이드에서 안드로이드 개발자가 iOS 보다 많은 이유를 몇 가지 짐작해 볼 수가 있습니다. 

  안드로이드 폰을 가진 사람이 월등하게 많습니다. 자신이 가진 폰에 맞는 앱을 개발하다보면 당연히 안드로이드 개발이 많을 수 밖에 없다고 생각할 수 있습니다. 

  안드로이드 개발 환경 구축이 훨신 쉽습니다. iOS 는 맥에서 개발을 해야 하지만 안드로이드는 일반 윈도우 환경에서도 개발이 가능합니다. 또한 iOS 는 스토어에 올리려면 개발자 인증서를 사야 하는데 이 비용도 초기 비용에 해당합니다. 또한 지금은 추세가 바꼈지만 예전에 iOS 는 object-c 로 개발을 해야 했는데 이는 java 보다 난이도가 높습니다. java 는 학교 수업시간에도 배우는 언어이기 때문입니다. 

  여러가지 이유로 안드로이드 개발이 iOS 보다 많은 이유를 짐작해 볼 수가 있습니다. 

  그러면 클라이언트와 서버 개발은 어째서 차이가 날까? 
  
  클라이언트 개발은 접근성이 편합니다. 그리고 결과물을 바로 볼 수가 있다는 장점이 있기 때문에 개발에 흥미를 가지고 시작하기가 좋습니다. 그리고 개발 -> 개발 완성까지의 가야 하는 길이 짧습니다. 

  서버 사이드는 개발을 시작하기 위해서 알아야 할 것들이 많습니다. 데이타베이스도 알아야 하고 디플로이도 제대로 할려면 리눅스 관련 명령도 배워야 합니다. 요즘은 클라우드가 대세이기 때문에 AWS (Amazon Web Service) 나 GCP (Google Cloud Platform)을 알아야 하는 시기가 됐습니다. 개발 언어도 알아야 하고 웹 서비스면 웹프레임워크도 알아야 합니다. 게다가 국내에서 가장 많이 쓰이는 자바 관련 개발 환경이라면 스프링 프레임워크를 많이 쓰는데 이 또한 학습곡선이 높고 많은 기간을 필요로 합니다. 만약에 결과를 눈으로 확인 하기 위해서는 프론트엔드도 최소한으로 알아야 하는데 이 또한 만만치 않은 노력을 필요로 합니다. 

  즉 클라이언트 개발은 접근성이 좋고 바로 바로 아웃풋이 확인 가능하니 개발의 재미를 줄 수가 있습니다. 서버 개발은 개발 접근성이 좋지 않고 바로 바로 아웃풋 확인 하기까지가 배워야 할 것들이 많습니다. 하지만 이러한 난이도가 시니어급에 이르렀을 때 연봉의 차이를 가져옵니다. 9:1 클라이언트대 서버 개발자의 비율입니다. 이게 펑균이라고 보기에는 사실상 무리가 있는 특이 케이스 일 수도 있지만 인력시장에서 알아보면 확실히 서버 개발자의 숫자가 적습니다. 

  그래서 내가 클라이언트와 서버 개발중에서 어떤걸 할까 고민을 한다면 각각의 특장점이 있습니다. 

  클라 개발에 전념해서 장인급이 되신다면 회사를다니면서 또는 프리랜서를 하시면서 '돈'만 바라보고 여러가지 일을 동시에 진행한다면 단기간에 큰 돈을 벌 수가 있다는 것입니다. 제 주변에는 프리랜서 시절에 연 1억을 넘게 벌어들인 아이폰 개발자와 연 2억을 넘게 돈을 버는 클라이언트 개발자들이 있습니다. 

  서버는 이후에 올라갈 수 있는 테크가 있습니다. 아키텍트 - 개발 총괄 - CTO 등으로 커 나아갈 수 있는 기회가 열려 있습니다. 물론 클라이언트 개발자 출신으로도 가능합니다. 그리고 클라이언트 개발자 분들의 역량을 무시하는 건 절대 아니지만 이후 실제로 서비스를 론칭해서 운영하는 경우에는 절대적으로 서버쪽의 지식이 필요합니다.

  물론 이런 것들이 생각처럼 잘 되기 위해서는 그에 따르는 노력들이 필요하지만 대체로 이렇습니다. 

  “영화는 스토리텔링이고, 기술 매체가 아무리 발전해 배급 방식이 변할지라도 영화의 스토리텔링적 요소는 결코 변하지 않는다”

  “영화는 스토리텔링이다. 기술과 매체의 변화는 궁극적으로 스토리텔링을 이루기 위해서다. 케이블이나 인터넷 모두 마찬가지다. 이런 기술 변화는 우리가 어떻게 소비자와 스토리를 소통하느냐를 위한 것이다. 배급 방식은 변하지만 스토리텔링은 변하지 않는다.”

  스필버그가 한 이야기 입니다. 영화의 본질이 스토리텔링 이라고. 

  제가 즐겨보는 라이트노벨에서도 특이한 설정으로 독자를 모으는데 유효한 권수가 대략 2권 정도 입니다. 5권 이상 지속할려면 결국 작가의 필력에 의존한다는 소리가 있습니다. 반면에 뻔한 소재라도 작가의 필력이 받쳐주면 여러 권수를 진행하는데도 유리합니다. 

  결국 게임은 종합예술이라 게임 장르에 따라 중요한 요소가 따로 있습니다. 프롬 소프트 게임이나 둠 시리즈에서 뛰어난 스토리를 기대하지는 않습니다. 철권 게임에서 스토리를 기대하지 않듯이, 하지만 라오어(라스트오브어스)는 게임 장르로는 아포칼립스 좀비물입니다. 흔하디 흔한 좀비물이지만 이렇게 사람들에게 칭찬을 받고 기대작이 된 이유는 그 게임이라는 장르를 철저하게 이용한 영화를 뛰어넘는 스토리 몰입감이였다고 봅니다. 물론 게임성이 떨어지는건 절대 아니라고 봅니다. 그래서 명작 소리를 듣는것이지요. 

  라오어2는 액션이 재밌고 그래픽이 쩔어주니까 명작이다? 뭐 사람 마다 주안점이 다르니까 그럴수가 있긴 뭐가 있습니까 -ㅅ-. 인생 최애겜중에 하나 였는데. 스토리텔링이 엉망에다가 쓸데 없이 가르칠려고 드니 반감이 장난 아니네요. 결국 훌륭한 스토리텔링은 의미를 설명하기 위한 설명이 필요 없고 직관적으로 알수 있어야 하는데 라오어2는 이 부분에서 큰 실패를 했다. 그래서 자신의 장점을 날리고 흔한 아포칼립스 액션 게임이 되버렸습니다. 

  

한스 로슬링, 올라 로슬링, 안나 로슬링 뢴룬드 공저

이창신 역 

 

 

최근 열심히 무협 소설만 보다가 독서 모임에 나가기 위해서 간신히 읽어본 책임, TED 강사로 유명한 한스 로슬링 박사가 쓴 책입니다. 저자가 많은 이유가 한스 로슬링 박사께서 말기암 6개월 진단을 받고 집필하시다 돌아가셔서 아들과 며느리가 마무리 한 것으로 알고 있습니다. 볼만한 책이지만 과학 계통에 있던 사람들은 어느 정도 알고 있는 내용 일지도 모릅니다. 그래도 읽어보시길 추천합니다. 

 

https://www.youtube.com/watch?v=gIE4N_G0Als

 

설민석 강사가 책을 요약하는 영상도 있으니 책 읽기 싫은분에게 강추합니다. 

 

제가 이 책에서 인상 깊었던 부분은 '10장 다급함 본능' 입니다. 사람들은 누구나 다급한 상황에서는 제대로 판단을 내리기 힘들다는 내용입니다. 누구나 알고 있는 내용 아닌가? 하지만 막상 닥치면 절대로 안정적으로 생각하기 힘듭니다. 저 또한 수 많은 스타트업에서 절실하고 다급한 상황에서 (보통 회사에 자금이 모자라는 경우) 말도 안되는 황당한 결정을 내리는 경우가 많습니다. 그래서 이 책에 나와 있는 방법을 간단히 소개할까 합니다. 

 

심호흡을 해라

 

다급한 본능이 발동하면 다른 본능도 깨어나 분석적 사고가 멈춰버린다. 일단 시간을 갖고 정보를 더 찾아보라. 지금 아니면 절대 안 되는 경우는 거의 없으며, 이것 또는 저것인 경우도 거의 없다. 

 

데이터를 고집하라 

 

무언가가 다급하고 중요하다면 잘 따져봐야 한다. 관련은 있지만 부정확한 데이터, 정확하지만 관련이 없는 데이터를 조심하라. 관련이 있고 정확한 데이터만 쓸모가 있다.

 

점쟁이를 조심하라

 

미래 예측은 늘 불확실하다. 그 점을 인정하지 않는 예측을 경계하라. 최선 또는 최악의 시나리오뿐 아니라 가능한 한 모든 시나리오를 요청하라. 그 예측이 전에는 얼마나 정확했는지 물어보라.

 

극적 조치를 경계하라

 

어떤 부작용이 있을지 물어보고, 검증된 생각인지도 물어보라. 단계적이고 현실적인 개선과 그 영향력에 대한 평가는 극적이지 않지만 대개 효과가 더 크다. 

귀멸의 칼날 애니메이션

2019년 하반기 화제작이라는 귀멸의 칼날을 봤습니다. 무지하게 수려한 화면 처리와 적절한 3D 와의 조화로 보는 내내 눈이 즐거운 애니입니다. 비록 담고 있는 내용이 피와 살이 난무하는 작품이긴 하지만. 게다가 인물선을 두껍게 먹선을 칠해서 천원돌파 그렌라간과도 같은 묵직한 액션감을 줄려고 노력했습니다. 작붕도 거의 없고(실제로 저는 목격하지 못했습니다 ㅎㅎ) 

  그 외에 귀멸의 칼날은 제 입장에서는 살짝 독특한 애니(원작은 만화)입니다. 일단 주인공이 옛날 스타일입니다. 츤데레도 아니고 삐딱선을 타지도 않았고 자기비하조차 없습니다. 목표를 향한 일직선 묵묵한 인내심 정말 착한..등등의 수식어가 붙는 마치 70-80년대 TV판 주인공을 보는듯 합니다. 

  그리고 일본의 검객을 다루는 만화나 소설은 보통 찬바라 물이라고 하고 독자적인 설정을 가지고 있는데, 이 작품은 특이하게 무협스러운 호흡법이 등장합니다. 마치 내공과도 비슷한 느낌? 이건 뭐 개인적인 생각입니다. 

  적으로 나타나는 혈귀, 또는 귀신 (오니)들도 재밌습니다. 최초의 오니가 있고 그 오니의 피를 받아 먹으면 또한 오니가 되고 이 최초 오니의 피를 많이 먹으면 더 강한 오니가 되고 이 오니들은 기본적으로 햇빛을 쏘이면 불에 타듯이 사라지고. 어디서 많이 본 설정이죠? 진조라고 불리는 초대의 뱀파이어와 그 혈족들에 관한 이야기와 비슷합니다. 뱀파이어들은 나무말뚝에 심장을 뚫리면 죽지만 이 오니들은 태양의 힘을 가지고 있는 날붙이에 목이 썰려야 죽는다는 점이 살짝 다르지만요. 

  간만에 재밌는 애니를 봤습니다. 최근 이고깽물과 그 관련 애니들만 보다 확실한 전투씬이 존재하는 애니를 보니 눈이 행복해지더군요. 최근 이고깽물에 질리신 분들에게 권합니다. 

역사의 역사

저자: 유시민 

 

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

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

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

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


  https://goo.gl/1guuCC



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

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


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

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


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


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


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


데모: 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 스프린트) 기간 내에는 변경이 안되게 확답을 받아야 합니다. 

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


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


기존의 포스트 대로 작업하면 일반적인 형태의 챗봇을 만들 수가 있지만, 한글은 교육 효과가 떨어질 수 밖에 없습니다. 실은 어마 어마한 교육 데이터가 존재한다면 이런 걱정 안하겠지만 애초에 교육 데이터가 많이 존재하지 않으니 그리고 실제로 많이 존재한다고 해도 한글은 원리상 형태소 분석을 추가해야 교육 효율이 좋아집니다. 


즉 seq2seq 방식에서는 


춘천에, 춘천에는, 춘천까지 


등등 춘천이 들어가는 단어를 전부 다르게 분류합니다. 춘천 이라는 명사에 의미를 주기가 어렵습니다. 영어라면 단어 위주로 나뉘어 지니까 이런 문제가 없지만 한글은 조사 때문에 형태소 분석이 필요합니다. 명사랑 조사를 분리시켜서 교육을 시키면 춘천 이라는 단어에 대한 교육을 시킬 수가 있기 때문에. 교육 효과가 높을 수가 있습니다. 


형태소 분석은 KoNLPy  를 씁니다. GPL 이기 때문에 나중에 상업용으로 적용하실 때는 형태소 분석 모듈을 새로 짜줘셔야 합니다. 


-- EDITED -- 

혹시라도 설치가 안되면 라이브러리 다시 링크후에 재시도 하면 됩니다. 

libmecab.so.2를 찾을 수 없는 에러가 나는 경우, 다음과 같이 할 수 있습니다.

  • 라이브러리를 다시 링크하고 확인후 재시도

    $ sudo ldconfig



+ Recent posts