셀잇은 기존 중고거래 시장에서 이용자들이 겪는 불편과 불안감을 해소하기 위해 등장한 서비스라는 자부심을 가지고 구매자와 판매자를 잇는 접점이 되고자 합니다. 이를 위해 서비스를 기획하고 실행하는 저희 구성원들에 대한 이야기를 간간히 들려드리고자 합니다. 좋은 서비스든 아이디어든 결국 사람이 하는 일이니까요-저희가 어떤 생각을 품고 어떤 마음가짐으로 살아가는지에 대해 진솔하게 풀어보고자 합니다. 이 청년들의 이야기, 한 번 들어보실래요? Interviewee: JD (제이디, 개발팀 / 안드로이드앱 개발 담당)Interviewer: Austin (오스틴, 마케터)  우선 자기소개부터 간단히 해주시죠. 흔해 빠진 소개일랑 집어치우고! 최대한 자신을 우리에게 알려봐요! 정~ 뭐라고 쓸지 모르겠으면 자기 이름으로 삼행시라도 해보세요. 우선 저에게 이런 귀찮은 일을 안겨준 브라이언에게 감사의 인사를 전하는 바입니다. 덕분에 독무대에 이어 다시 한번 불면증에 시달리게 되었어요. 그건 브라이언에게 개인적으로 앙갚음(?)을 해주시고, 본인 소개부터 해주세요. 저도 바쁘답니다. 안녕하십니까? 저는 전남 해남의 작은 시골 마을에서 2남 중 장남으로 태어나 안드로이드 개발을 하고 있는 JD라고 합니다. 원래는 게임 개발이 하고 싶어서 프로그래밍 공부를 시작하였지만 어쩌다 보니 앱을 개발하고 있네요. (뭐, 뭐지? 이 ‘신입사원의_패기.wav’ 같은 느낌은?) 그럼 현재 셀잇에서 개발자로 일하시겠군요. 그럼 본인이 하는 일 중에서 이건 나만의 스페셜티다! 하는 부분은 무엇인가요? 당연히 안드로이드 개발입니다. 우리 회사에서 저 밖에 못하는 거죠~(찡긋) (찡...찡긋?) 하하하;; 네네 그렇군요. (셀잇이 잘 되는 이유가 이거였군. 정상적인 놈이 없는...) 그게 다인가요? 개발하시다가 잘 안풀리거나 열 받을 때는 어떻게 하나요? 자세한 건 ‘영업비밀’이니까- 전 안풀리면... 음- (한참을 생각한다)잠을 잡니다. (역시 오늘도 산으로 가는건가…) 아…(포기한 듯) 얼마나 자나요? 한 20분 정도 짧게 자요. 사실 잔다기보다는 자는 척을 하면서 생각을 하는거죠. 읭? 굳이 자는 척을 해야 될 필요가 있나요? 그냥 대놓고 생각하면 안되는건가요? 안됩니다! 온전한 집중을 위해서 자는 척을 해야 해요. (정적) 인터뷰 하는 중에 월드시리즈까지 끝나버렸네요... 올해 모든 야구가 끝나버렸어요 ㅠ (후우... 내가 이걸 왜 시작했을까...) 그럼 일 얘긴 그만하고(더 할 수도 없겠어;;) 업무 외의 시간에는 주로 뭘 하시나요? 듣자하니 야구를 좋아하는 것 같은데- 야구를 봅니다. 한국 야구는 기아를 응원하고, 메이저리그는 한국 선수들이 진출한 팀들을 응원하고 있어요. 주말에는요? 주말이면 아침에 일어나서 메이저리그 두 경기 정도 보고 오후에는 한국 야구를 보면서 하루를 보냅니다. 이제 야구 시즌도 다 끝나서 다가오는 겨울이 두렵습니다ㅠ 차라리 야구선수로 전향하시는게- 만약 실력이 문제라면 사회인 야구팀이라도 해보시는건요? 그건 돈도 많이 들고, 일단 귀찮고-부상 위험도 크고, 일단 귀찮고-그냥 친구랑 캐치볼 하는 것으로 만족합니다. 그리고 일단 귀찮고- 커피나 한 잔 하실래요? 커피나 마시면서 다른 얘기로 넘어가죠~ 괜찮습니다. 저는 카페인 마시면 안되서- 아, 그럼 그냥 계속 하죠. (여자랑은 술 마시고 나랑은 커피도 안 마시냐?-_- 쳇, 근데 이해되네...) 중고에 대해서 어떻게 생각하세요? 중고를 바라보는 가치관 같은게 있으시면 말씀해 주세요. 제가 환경 문제에 관심이 많습니다. 중고거래가 보편적으로 활성화 된다면 상대적으로 공산품의 생산량이 줄어들게 되고, 이는 지구의 자연 환경에 도움이 되지 않을까 합니다. (응? 뭔가 익숙한데?) 제가 예전에 쓴 글을 보신건가요?… 네~ 꼭 중고 거래가 활성화되서 지구 환경을 지켜주세요… 그럼 마지막으로 셀잇에서 이루고 싶은 것은 무엇인가요? 주로 컴퓨터 부품들을 중고 거래를 이용해 구매했던 적이 있는데요. 항상 직거래를 했지만 정상 작동하는지 불안했던 기억이 있습니다. 집에 와서 컴퓨터에 장착해 보고서야 안심을 하곤 했었는데, 셀잇을 이용하면 최소한 이런 걱정 없이 믿고 안심하며 거래할 수 있는 서비스로 자리 잡을 수 있었으면 합니다. 아니 이건 셀잇이 나아갈 방향이고~ 저는 제이디 본인 개인의 목표에 대해서 물은거예요. 셀잇이 곧 저입니다. 화, 화이팅...! (후우...) 이런 자리가 부끄럽죠? 가슴 속에 뜨거운 뭔가가 있는게 보이지만 굳이 밝히지 않으시겠다면 앞으로 안드로이드 앱을 통해 그 뭔가를 제가 찾아보겠습니다. (빨리 끝내려 애쓴다;;) 인터뷰는 이 정도로 마치는 것으로 하고~ 셀잇에서 칭찬하고 싶은 사람 한 명만 꼽아주세요. 이유도 함께 말해주세요. 전 네이쓴을 칭찬하고 싶습니다. 특유의 친화력과 유머러스함으로 주변 사람들을 기분 좋게 만들어주는 아주 훌륭한 팀원이기 때문입니다. 로봇입니까? 네? 아닙니다. 그럼 오늘 수고하셨습니다. 아! 최근에 셀잇 앱 2.0이 배포됐는데 감회가 남다를 것 같 같은~ 어떠세요? 딱히 이렇다할 소감은 없습니다만 이용자분들이 이전보다 더 편하게 서비스를 이용할 수 있었으면 하는 바람입니다. (로봇 맞네...) 넵- 수고하셨습니다. (하아... 네이쓴이라... 다음엔 우주로 가겠구만...)#셀잇 #번개장터 #인터뷰 #팀소개 #팀인터뷰 #팀원소개 #기업문화 #조직문화 #회사문화 #사내문화

좋은 개발자 소개해주세요.많은 기업 관계자분들을 만나면서 항상 듣는 말이다. 스타트업에 있어서 인재 채용이 항상 문제기는 하지만, 이것은 비단 스타트업에만 국한되지는 않은 것 같다. 지난 코드스테이츠 데모데이 때는 카카오와 SK텔레콤 같은 대기업과 더불어 스마트스터디, 데일리호텔 기업 관계자분도 참여해 주셨다. 이것을 보면 대기업이든, 규모가 꽤 있는 기업이든 좋은 개발자를 찾는 것은 어려운 것 같다.기업들이 이런 말을 하는 것을 보면 개발자를 찾는 수요는 빠르게 증가하고 있는데, 기업들의 입맛을 맞추면서 개발을 할 수 있는 '좋은 개발자'는 많이 없는 듯하다. 이런 상황에서 코딩 교육 스타트업 코드스테이츠가 많은 기업 관계자분과 개발자분들을 만나고 코딩 교육을 하면서 느낀 점을 통해 어떤 개발자가 좋은 개발자인지에 대하 포스팅을 하려 한다.이것을 통해 좋은 개발자라는 개념을 구체화할 것이다. 좋다는 개념을 명확히 해서 어떤 것들이 좋아야 좋은 개발자인지, 또 소위 말하는 좋은 개발자가 되기 위해서 어떤 노력들을 해야 하는지 글로 풀어갈 것이다. Good Developer 시리즈 첫 번째 포스팅, 좋은 개발자의 5가지 기준좋은 개발자의 5가지 기준좋은 개발자에 대한 생각은 개인마다 또 기업마다 다를 것이다. 아래의 기준들은 많은 기업 관계자분들과 개발자분들을 만나고, 코드스테이츠가 교육을 하면서 느낀 좋은 개발자의 기준들이다. 아래의 조건들이 좋은 개발자의 충분조건이라고 할 수는 없지만, 필요조건이라고는 할 수 있을 것 같다. 코드, 생산성, 커뮤니케이션, 학습, 관리 능력 이 5가지 관점을 통해 어떤 개발자가 좋은 개발자인지 알아보자.1. 코드의 리딩과 라이팅좋은 코드를 짤 수 있는 역량은 좋은 개발자가 되기 위한 필수적인 기준이다. 하지만, 대부분의 개발자들에게 어떻게 하면 좋은 코드를 짤 수 있는지 물어보면 쉽게 답하는 사람은 많지 않다. 그래서 구체적으로 어떤 능력이 있어야 좋은 코드를 짤 수 있는지, 코드의 리딩과 라이팅의 관점에서 살펴보고자 한다.많은 주니어 개발자들이 처음 회사에 입사해서 해야 하는 것 중 하나는 코드의 리딩(reading)이다. 자신이 처음으로 개발을 시작하지 않는 이상 이미 개발된 소스들을 보고 어떻게 동작하는지 또 변수, 함수, 메서드들의 네이밍(Naming)은 어떤 식으로 하고 있는지 파악해야 한다.코드의 리딩 능력은 업무 환경에 적응하는 능력과는 별개로 자신의 업무를 파악하고 또 다른 사람과 커뮤니케이션할 때 매우 중요하다.  그리고 코드를 잘 읽으면 어디가 잘못되어 있는지, 어떻게 고쳐야 하는지 쉽게 파악할 수 있다. 그리고 이것이 코드를 잘 짤 수 있는 역량으로도 직결된다.리딩 능력과 더불어서 중요한 것이 바로 코드 라이팅(writing) 능력이다. 라이팅은 코드를 잘 짜는 것과 별개로 네이밍(Naming)을 잘하고 이해하기 쉽게 코드를 쓰는 것을 의미한다. 코드 리딩 능력이 뛰어나지 않은 개발자라도 잘 정돈되고 직관적으로 네이밍 되어 있는 코드들을 보면 쉽게 읽을 수 있다.코드 라이팅 능력은 협업하고 코드를 구조화하는 과정에서 매우 중요하다. 코드 라이팅 능력이 떨어진다면 다른 사람이 자신의 코드를 이해하는데 오랜 시간을 소모하게 만들 뿐만 아니라 나중에 가서는 자신조차 자신의 코드를 이해하는데 오랜 시간이 걸릴 수 있다. 이렇기 때문에 안정된 코드, 돌아가는 코드를 짜는 것과 별개로 다른 사람과 자신이 이해하기 쉬운 코드를 짜는 능력은 매우 중요하다.좋은 코드를 짜기 위해서는 다른 사람이 어떤 코드를 짰는지 알아야 하고 내 코드를 다른 사람들이 쉽게 읽을 수 있도록 해야 한다. 개발자는 결국 코드로 말한다. 코드 라이팅 능력이 떨어진다는 것은 코드로 '잘' 말하지 못한다는 것을 의미한다. 또 코드 리딩 능력이 떨어진다는 것은 다른 개발자가 코드로 말하는 것을 '잘' 듣지 못한다는 것을 뜻한다. 좋은 개발자의 조건으로 항상 따라붙는 좋은 코드를 짜는 방법은 코드 리딩과 라이팅 능력이 선행되었을 때 가능할 것이다.2. 빠른 생산성좋은 코드를 짜는 것이 좋은 개발자가 되는데 중요한 조건이기는 하지만 유일한 조건은 아니다. 개발은 필연적으로 시간과의 싸움이다. 그래서 좋은 개발자의 조건 중 하나가 바로 생산성이다. 우리나라의 많은 개발자들이 야근에 시달리는 것도 결국은 생산성과 연결되어 있다.(물론 조직문화도 크게 작용한다. 그리고 CEO의 마인드도...)안정적이고 완벽한 코드를 짜는 것도 중요하지만 때로는 시간과 타협해서 돌아가는 코드를 짜는 것만으로 만족해야 할 때가 있다. 특히, 리소스가 부족한 스타트업에서는 시간이 생명이다. 환상적인 코드를 짤 수 있는 개발자라 할지라도 그 시간이 천년만년 걸린다면 당장 돌아갈 수 있는 코드를 돌릴 수 있는 개발자 보다 좋은 개발자라고 하기 힘들 것이다.투입한 시간 대비 얼마만큼의 코드 생산성이 나오는가? 시간이 생명인 많은 스타트업에서는 안정적이고 완성도 높은 코드를 짜는 개발자보다 생산성 높은 개발자를 선호할 가능성이 크다. 첫 번째 기준인 코드 리딩과 라이팅 능력에서 자신이 없다고 걱정할 것 없다. 자신의 코드 생산성이 좋다면 좋은 개발자로서의 중요한 기준을 하나를 충족한 셈이니까.3. 원활한 커뮤니케이션위의 두 가지 기준이 개발 자체에 대한 능력이었다면, 커뮤니케이션 능력은 다른 사람과 협업하는 능력에 대한 기준이다. 혼자서 개발하는 개발자는 극히 드물다. 코딩 = 개발이 아니다. 코딩은 개발의 한 과정이며 개발을 할 때에는 다른 구성원들과 수많은 상호작용을 해야 한다. 왜냐하면 개발자는 결국 사람들과 일하기 때문이다.그래서 많은 기업들이 개발자를 채용하는 기준에서 '원활한' 커뮤니케이션을 내세운다. 개발과 관련 없을 것 같은 커뮤니케이션은 사실 엄청나게 중요하다! 커뮤니케이션 문제로 발생하는 비용 문제(단순히 돈이 아니다.)는 상당하다.어느 정도 개발 경험이 있는 사람은 누구나 공감할 수 있을 것이다. 같이 일하고 싶은 개발자와 아닌 개발자가 있다는 사실을 말이다. 단지 사람이 좋고 나쁨을 떠나서, 대화를 하는데 숨이 턱 막히는 사람이 있고 대화를 하면 할수록 막혔던 부분이 풀리거나 새로운 아이디어를 떠오르게 만다는 사람이 있다.원활한 커뮤니케이션은 사실 어느 직군에나 해당되는 말이지만, 개발처럼 한 가지 테스크에 여러 사람이 집중적으로 달려드는 업무에 있어서 그 중요성이 더 부각된다. 당신은 원활한 커뮤니케이션 능력을 가지고 있는가?4. 업무 관리, 사람 관리 능력업무 관리와 사람 관리는 사실 개발자 직군에 국한된 역량이 아니라 모든 직군에서 필요로 하는 역량이다. 개발에 치중해야 할 개발자가 좋은 개발자가 되기 위해 이런 것들까지 신경 써야 할 이유는 무엇일까? 위에서도 언급했지만, 개발 = 코딩이 아니다. 개발을 한다는 것은 테스크를 나눠 할당하고 기간에 맞춰 완성시키는 일이다. 이 과정에서 필요한 상호작용, 업무 관리, 생산성이 모두 개발의 과정이다.업무 관리와 사람 관리를 잘 하는 사람은 막말로 그냥 일 잘 하는 사람이다. 좋은 코더가 아니라 좋은 개발자가 된다는 것은 일을 잘하는 사람이 되어야 한다는 뜻이다. 업무 관리는 테스크를 나누고 할당하고 데드라인을 설정하는 일이 아니더라도 나에게 주어진 테스크에 대해 스스로 관리하는 능력까지 포함한다. 결국 자신의 업무 관리를 잘하는 사람은 생산성에서 두각을 나타내리라.주니어 때 좋은 개발자로 인정받고 연차가 쌓이면 시니어가 되고 관리자 직급으로 올라갈 가능성이 크다. 이때 주니어 때 좋은 개발자였다고 시니어 개발자일 때도 좋은 개발자일 거란 보장은 없다. 시니어가 돼서도 좋은 개발자가 되고 싶다면 업무 관리와 사람 관리하는 능력이 필수적이다. 특히, 한국에서는 개발자의 종착지는 관리자일 정도로 연차가 많은 사람이 개발을 하고 있는 경우는 극히 드물다. 이런 상황에서 좋은 개발자로 인정받아 마지막까지 살아남기(?) 위해서는 이 두 가지 능력이 필수적이다.5. 지속적인 학습위에서 제시한 네 가지 능력이 모두 없다고 실망할 것 없다. 좋은 개발자가 되기 위하 마지막 조건, 지속적인 학습이 있기 때문이다. 지속적인 학습은 좋은 개발자가 계속해서 좋은 개발자로 남을 수 있게 만들어주고 일반 개발자가 좋은 개발자가 될 수 있게 만들어주는 중요한 조건이다.개발은 빠르게 변한다. 모든 직군 중에서 가장 학습을 많이 해야 하는 직군을 뽑으라면 자신 있게 개발자라 말할 수 있다. 빠르게 변화하는 환경 속에서 지금 좋은 개발자라 해서 몇 년 후에도 좋은 개발자라고 단정 지을 수 없다. 개발자는 숙명적으로 끊임없이 배워야만 한다. 좋은 개발자가 되기 위해서는 더더욱.지속적으로 배운다는 것이 단순히 새로운 것을 익히고 지식의 지평을 확대해 나간다는 것만을 의미하지 않는다. 지금 현재 소위 나쁜 개발자(코드 퀄리티, 생산성, 커뮤니케이션, 관리능력 모두 떨어지는 개발자)가 블록체인 신기술을 배운다고 해서 좋은 개발자가 되겠는가? 즉, 코딩 지식에 대한 고민뿐만 아니라 위에서 언급한 네 가지 기준에 대한 학습도 필요하다.학습에 측면에서 많은 분들이 간과하고 있는 것이 지식의 질이다. 단순히 지식의 양적인 측면에만 매몰되면 깊이 있는 지식을 얻기 힘들기 때문이다. 물론, 현재의 시대적 흐름을 읽고 최신 트렌드 기술을 습득하는 것은 중요하다. 하지만 그보다 더 중요한 것은 자신이 알고 있는 지식들을 깊이 있게 아는 것이다. 끊임없는 학습, 그리고 깊이 있는 학습만이 좋은 개발자를 계속해서 좋은 개발자로 만들어 준다.좋은 개발자를 위해지금까지 좋은 개발자를 위한 5가지 조건에 대해 알아 보았다. 코드 리딩과 라이팅, 생산성, 커뮤니케이션, 사람과 업무 관리 그리고 지속적인 학습. 이외에도 중요한 조건들이 많지만 많은 개발자를 만나고 교육해오면서 가장 필요하다고 생각하는 5가지 조건을 적어보았다.개발자가 되는 것은 쉽지 않다. 좋은 개발자가 되는 것은 더더욱 쉽지 않다. 좋은 개발자를 양성하기 위해 노력하는 교육 스타트업으로써 어떤 개발자가 좋은 개발자인지 파악하기 위해 항상 노력 중이다. 이 노력을 코드스테이츠만 알고 있는 것이 아니라 다른 분들에게도 공유드리고 싶다. Good Developer 포스팅을 통해 어떤 개발자가 좋은 개발자인지 또 좋은 개발자가 되기 위해서는 어떻게 해야 하는지 이야기할 예정이다. 좋은 개발자의 길은 멀지만 Good Developer를 통해 한층 쉽게 걸어갈 수 있었으면 좋겠다.

Backbone이란?Backbone은 자바스크립트 프레임워크로 MVC 패턴을 적용하여 웹 애플리케이션 개발할 수 있도록 돕는 유용한 프레임워크입니다. MVC 패턴에 대해서는 밑에 더 자세히 설명하기로 하고 간단히 Backbone을 적용한 후의 장점을 소개하면 깔끔하게 뷰와 로직을 분리할 수 있어 코드를 유지 보수하는데 드는 시간이 줄며 기능 수정 혹은 기능 확장이 쉬워진다는 점등을 들 수 있습니다.또한, Backbone에서는 Underscore 라이브러리를 사용하는데, 이 라이브러리에서 제공하는 템플레이트 기능을 통해 뷰의 재사용과 설계를 쉽게 할 수 있다는 점도 장점입니다.만약 서버 측에서 RESTful한 URL을 제공한다면, Backbone을 사용하여 얻을 수 있는 이점이 더 확실해집니다. 모델에 RESTful한 URL을 제공하면, 간단하게 서버와 동기화하면서 그에 따르는 뷰의 변화 따위를 손쉽게 구현할 수 있습니다.RESTful한 인터페이스 설계에 대해서 궁금하시다면 이전에 올라온 글을 참조해보세요. Backbone 기반으로 설계된 여러 웹 애플리케이션 중에는 여러분이 잘 알고 있을만한 서비스들도 있을 것입니다.MVC 패턴?이미 MVC라는 용어에 익숙하신 분들도 많겠지만, 생소하신 분들을 위하여 간단히 정리해보면 MVC 패턴은 디자인 패턴 중의 하나로 모델(실제 쓰일 데이터)과 모델을 보여줄 뷰(인터페이스) 그리고 사용자로부터의 입력을 받아 모델과 뷰를 중재하는 컨트롤러로 나누어서 구현을 해나가는 방식을 말합니다. GoF 책에도 이 패턴이 소개되어 있지요.모델은 뷰나 컨트롤러와 무관하게 작성되는데 그런 모델을 뷰가 관찰하고 있다가 모델의 변화에 따라 적절히 뷰의 모습을 바꾸게 되므로 서로 투명하게 작동하게 됩니다. 즉 모델만 잘 설계해서 만들어주고 그에 따르는 뷰의 모습만 정의하면 그다음부터는 지저분하게 모델의 상태에 따르는 코드를 직접 처리할 필요가 없다는 장점이 있습니다.Backbone이 MVC 패턴을 적용하기 위한 프레임워크라고 하였지만, 실제로 Backbone에서는 MVC 패턴의 변형인 MVR 패턴을 사용합니다. 컨트롤러 대신 Router가 쓰이는 형식인데, 이 링크에서 Backbone의 Router에 대한 자세한 설명을 제공하고 있습니다. 하지만 Router가 컨트롤러의 역할을 대행하는 것은 아니고, 대부분의 Backbone 예제를 살펴보면 실제로 컨트롤러가 담당하는 업무들을 뷰에 이관하여 처리하는 것을 볼 수 있습니다. MV* 패턴 중에는 MVP 패턴이나 MVA 패턴 같은 MVC 패턴의 변형들이 존재합니다만 그 바탕을 이루는 Model-View의 관계는 변하지 않는 것을 볼 수 있습니다.Simple code snippet간단한 예제를 통해 실제 코드 상에서 어떤 식으로 Backbone을 적용하는지 알아보겠습니다.모델먼저 모델을 정의해야 합니다. 가령 밑의 코드에서는 사각형 모델을 정의하고 있는데요, 기본값을 지정해 줄 수 있고, 사각형 모델과 관련된 함수들을 정의해놓은 것을 볼 수 있습니다.var Shape = Backbone.Model.extend({ defaults: { x:50, y:50, width:150, height:150, color:'black' }, setTopLeft: function(x,y) { this.set({ x:x, y:y }); }, setDim: function(w,h) { this.set({ width:w, height:h }); }, });이렇게 Backbone.Model.extend 함수를 통해 모델의 청사진을 구성하게 됩니다. 이 모델을 이용하여 뷰를 구성할 수 있습니다.콜렉션Backbone.Collection.extend({ model: Shape });많은 상황에서 복수의 모델을 다루게 될 일이 생깁니다. 가령, 게시판에 올라온 글들은 게시물의 집합이라고 볼 수 있겠죠. 콜렉션을 통해서 이러한 복수의 모델의 집합을 만들어낼 수 있습니다. 위의 코드에서는 앞서 소개한 Shape 모델의 콜렉션을 정의한 것을 볼 수 있습니다. 모델과 마찬가지로 콜렉션도 뷰에 바인딩할 수 있고, 콜렉션에 관련한 이벤트(change, add, remove)를 뷰과 관찰하게 할 수 있습니다. 또한, Underscore 라이브러리에서는 콜렉션과 밀접하게 관련된 여러 함수를제공합니다.뷰var DocumentRow = Backbone.View.extend({ tagName: "li", className: "document-row", initialize: function() { this.model.bind('change:name', this.render); }, events: { "click .icon": "open", "click .button.edit": "openEditDialog", "click .button.delete": "destroy" }, render: function() { // render or update something } });기본적으로 뷰에 뷰와 관련된 모델이나 콜렉션을 바인딩하게 되는데요, 이 바인딩을 통해 뷰는 모델이나 콜렉션의 상태를 관찰하고 변화를 감지하여 바인딩 시 전달한 핸들러를 통해 적절한 행동을 수행할 수 있게 됩니다. 위의 예제를 보면 모델의 name 속성 변경 시 render 함수를 호출하도록 바인딩한 것을 알 수 있습니다. 또한, 뷰에 관련한 이벤트와 그에 관련된 핸들러를 events에 정의해놓을 수 있습니다. 보통 render 함수 내에서 뷰를 구성하거나 혹은 바인딩 된 모델, 콜렉션의 변화에 따르는 뷰의 변화를 적용하게 됩니다.뷰에 관련된 더 자세한 사항은 뷰 문서를 참조하시기 바랍니다.템플레이트var compiled = _.template("hello: <%= name %>"); compiled({name : 'moe'}); => "hello: moe"Underscore에서 제공하는 템플레이트 기능을 이용하여 문자열을 곧바로 html 요소로 만들어낼 수 있습니다. 또한, 템플레이트 내에 자바스크립트 함수 등을 삽입하는 기능도 제공합니다. 기본적으로 Underscore에서 템플레이트 기능을 제공하지만, 그 외에도 여러 라이브러리가 있습니다.가령 mustache를 이용해서도 똑같은 기능을 할 수 있습니다. 필요에 따라 유연하게 템플레이트 라이브러리를 바꿀 수 있다는 점이 매력이라고 볼 수 있습니다. Backbone 공식 사이트에서도 이러한 템플레이트 라이브러리를 이용하는 것을 권장하고 있습니다.Ember.jsBackbone이 나름의 역사가 있는 프레임워크이기 때문에 많이 쓰이고 있지만, 그 외에도 비슷한 기능을 제공하는 프레임워크가 많습니다. 그 중의 하나인 Ember.js가 있습니다. Ember.js의 장점이라면 기본적으로 Handlebars라는 템플레이트 라이브러리를 지원함과 동시에 Backbone보다 심화된 여러 기능을 제공하는 점이 있습니다.그러면서도 사용의 꼴이 Backbone과 비슷하므로 만약 Backbone을 사용해 본 적이 있다면 적응하기도 쉽습니다. 참고로 아래에 여러 MVC프레임워크를 소개하고 장/단점을 분석한 사이트의 링크를 달아두었는데 여타의 프레임워크보다 더 좋은 점수를 받기도 하였습니다.Backbone 말고 다른 MVC프레임워크를 원한다면, 특히 자체 템플레이트 라이브러리를 지원하는 프레임워크를 원한다면, Ember.js 사용을 고려해 보는 것이 어떨까요?더 읽어볼 만 한 것An Intro to Backbone.jsBackbone.js by exampleBackbone Tutorials위의 사이트들은 제가 Backbone을 공부하면서 참고한 사이트들입니다. 영문 사이트이지만 코드만 훑어 봐도 그 의도와 얼개는 파악할 수 있을 것으로 생각합니다. Backbone 공식 사이트에서 제공하는 튜토리얼 사이트도 방문해볼 가치가 있습니다. Backbone을 이용하여 개발한 간단한 서비스의 소스코드를 공개해 놓았습니다.The Top 10 Javascript MVC Frameworks ReviewedJourney Through The JavaScript MVC Jungle위 두 사이트에서는 앞서서 소개한 Backbone과 Ember.js 외의 여러 MV*패턴 프레임워크를 소개하고 장단점에 대하여 분석해놓았습니다.마치며이상으로 Backbone 도입과 그에 따르는 장점을 살펴보았습니다. 일반적인 홈페이지와 제작과는 약간 양상이 다른 웹플리케이션(웹 + 애플리케이션)개발자 분들은 프로젝트에 MVC 패턴 프레임워크를 적용해 보면 어떨까 하는 생각이 듭니다. 프로젝트의 생산성에 크게 이바지할 수 있으리라 생각됩니다.#스포카 #개발 #개발자 #인사이트 #Backbone #일지 #개발팀

아이들과 오전에 놀아주고 집안일을 마치고 나서 지하철을 탔다. 파이콘에 가는 길이었다. 5년째 참석하다 보니 이제 모든 세션을 빡빡하게 들어야 한다는 부담이 없다. 그래서 늦었지만 여유로웠다. 가는 길에 습관적으로 본  페이스북 타임라인은 이미 파이콘 이야기로 가득했다. 인증과 세션 자료 그리고 개발자를 뽑고 싶어 하는 회사들의 홍보로. 피드에서 스포카에서 진행하는 도도 파이터 이벤트를 보고 "이건 뭐야?" 싶어서  링크를 눌렀다. 어이쿠 개발자 컨퍼런스에 이게 도대체 뭐야오. 깔끔하게 잘 만들었다. 예제 코드를 살펴보니 설명도 잘 되어 있고 간단하다. 도전해 보고 싶은 생각이 들었다. 지하철 자리에 앉아 테더링을 연결하고 코딩을 시작했다. (사실 이것이 내가 세션은 듣지 않고 이틀 동안 부스/이벤트 체험만 하게 된 계기가 될 줄은 몰랐다.)대단히 잘 할 생각은 없었다. 세상에 굇수는 많으니까. 참여에 의의를 둬야지 싶었다. 비록 설명에는 “인공지능 코드”를 작성하여 다른 참가자와 겨루는 “인공지능 격투 대전”이라고 되어 있지만 당연해 보이는 규칙만 구현하고 나머지는 랜덤으로 동작하게 해서 제출해 보자 싶었다. 코엑스에 도착한 후  조금만 더 작업해서 제출하려고 하는데 아무리 제출해도 제출이 되지 않고 다음과 같은 메시지만 받았다.  코드가 테스트를 통과하지 못했습니다.아니 랜덤 봇이랑 하면 잘만 이기는데 왜 통과를 못하는 거야! 하던 차에 다시 설명을 읽어 보니  가만히 있는 더미 에이전트를 상대로 이겨야 제출이 이루어집니다.란다. 먼저 가면 손해인지라 가까워지면 더 안 가고 제 자리에서 주먹질만 시켰더니 더미 에이전트를 못 이기나 보다. 그래서 5초 아래로 시간이 남고 지금까지 한 번도 안 싸웠으면 앞으로 가도록 했더니 테스트를 통과하고 제출이 되었다.  제출에 성공하고 기분 좋게 돌아다니면서 다른 부스도 구경하고 있는데 회사 슬랙으로 함께 파이콘에 참여하고 계신 동료 분이 메시지를 보내셨다.봇이 화끈하면 뭐햐나. 이기면 장땡!스포카 부스에서 사람들이 제출한 봇들을 랜덤으로 붙여 주는 모양이었다. 후후. 어찌 되었든 이겼다고 하니 기분이 좋군.첫날 마지막 행사인 라이트닝 토크에서 스포카 도도 파이터 개발자분의 발표가 있었다. 회사에서 파이콘을 준비하면서 한 달 가까이 준비했다고 한다. 그리고 최근 2주도 동안은 도도 파이터만 달렸다는 이야기를 해주셨다. 컨퍼런스 이벤트로 만든 게임의 퀄리티가 좋아서 감탄한 것도 있었지만 팀에서 개발자들에게 그런 여유를 줄 수 있는 것도 부러운 마음이 들었다. 좋은 회사다. 도도 파이터 토너먼트는 다음날 파이콘 정식 행사가 끝나고 열렸다. 기억으로는 80명 정도가 참여했었던 것 같다. 조별 토너먼트를 진행하고 우승자들을 모아서 다시 토너먼트를 하는 구조였다.   싸워라! 싸워라!조금 늦게 왔더니 자리가 없어서 가장 앞자리에 나왔는데, 내 봇의 차례가 될 때마다 github 계정의 내 얼굴이 스크린에 크게 나와서 부끄러웠다. 외국 친구들은 자기 얼굴 github 프로필에 잘 넣어 놓던데, 왜 우리나라 개발자들은 자기 사진을 안 넣는 걸까... 게다가 내 봇이 나오는 경기는 모두 지루하고 얍삽한 느낌이 있어서 왠지 더 부끄러웠다. 니가 올래? 내가 갈까?다행히 조별리그도 통과해서 결승 리그에 올라갔다. 사실 한 두경기만 이기면 좋겠다 했었는데, 결승 리그에 올라가니 왠지 욕심이 생겼다. 제일 그럴싸하게 싸운 경기운 좋게도 아슬아슬하게 16강부터 4경기를 모두 이겨서 우승을 하고 문성원 CTO님께 해피해킹 키보드도 상품으로 받았다. 기분이 좋으면서도 멋쩍기도 한 기분이다. 사실 이번 파이콘에 와서 여러 곳의 부스를 참여하고, 이벤트도 적극적으로 참여해 본 이유는 내년에 8퍼센트도 파이콘에 스폰서로 참여하고 싶어서 였다. 우리의 (잉여) 개발력도 보여주고, 다른 개발자 분들과도 적극적으로 교류하고 싶은 마음이었다. 그 바람이 꼭 이루어질 수 있게 다음 파이콘 때 까지 좋은 분들을 모시고, 회사의 성장을 만들어 나가야겠다는 생각이 들었다. 마지막으로 내 코드를 공개한다.  https://gist.github.com/leehosung/f784d9efc71dce12855739647dd98877다시 코드를 살펴보니 개선할 점도 여러 개 보인다. 하지만 기존에 제출한 코드를 보기 좋게 정리만 하고 주석만 붙여 보았다. 사실 별 특별한 것이 없는 코드다. 실제 작성하고 테스트하는 것에도 한 시간이 걸리지 않았다.다음에 이런 기회가 온다면 글을 읽으시는 분들도 가벼운 마음으로 도전해 보셨으면 한다.  성적이 좋으면 더 좋지만 나쁘면 또 어떠한가? 개발자인 우리만 즐길 수 있는 놀이인데.  #8퍼센트 #에잇퍼센트 #파이콘 #파이썬 #Python #Pycon #이벤트참여 #참여후기 #개발자 #개발

이번 5회차 수업에서는 베이즈 결정이론(Bayes Decision Theory)과 가우시안 혼합모형(Gaussian Mixture model)에 대해 배웠어요.1980년대 이후 세계 금융시장에서 위험관리를 계량화한 것은 확률이론, 그중에서도 ‘베이즈 정리’가 있었기에 가능했어요. 이전의 경험과 현재의 증거를 토대로 사건의 확률을 추론하는 알고리즘 덕분에 온갖 파생상품이 탄생했어요. 그런데 베이즈 정리는 오랫동안 금기시됐는데요. 주관적인 믿음을 측정하기 때문에 합리적이지 않다는 이유에서였다고 해요. 하지만 베이즈 정리의 활용도는 갈수록 커지고 있어요. 암호 해독부터 전쟁 중 의사결정, 실종된 사람이나 선박의 위치 추정, 암 발병률 예측, 스팸메일 걸러내기 등 무한대에 가깝다고 해요. 이번  필기노트에서는 베이즈 결정이론에 대해 알아볼게요.Bayes Decision Theory베이즈 결정이론은 패턴 인식을 위한 통계적 접근 방법이에요. 베이즈가 제시한 통계적 방법을 통해 의사 결정을 하는 방법이죠. 전통적 통계 방식은 통계적 추리를 할 때 표집으로 얻은 정보만 사용해요. 베이지안 확률이 전통적 통계 방식과 다른 점은 학습자가 기존에 가지고 있는 사전 정보를 활용한다는 것인데요. 불확실한 상황에서 통계적으로 얻은 정보를 가지고 의사 결정을 해야 하는 경제학, 경영학 등 여러 분야에서 많이 사용되고 있어요.베이즈 결정이론에 사용되는 베이즈 정리(Bayes rule)에 대해 간단한 예시를 들어볼게요.우리가 은행 지점장이라고 가정해봐요. 고객에게 돈을 빌려줄 수는 있지만 아무에게나 막 빌려줄 수는 없겠죠?그래서 은행 고객을 high-risk, 즉 돈을 빌려줘도 안 갚을 확률이 높은 고객과 low-risk, 즉 돈을 빌려주면 갚을 확률이 높은 고객으로 나눌 거예요.그런데 은행 고객이 돈을 갚을지 안 갚을지를 판단하는 기준이 있어야겠죠? 그래서 고객의 연봉(yearly income)과 현재 은행 계좌 보유금액(savings)을 가지고 판단할 거예요. 이렇듯 변수가 두 개만 있을 때 우리는 이항분포를 사용해서 의사를 결정해요. 위에서는 두 가지 고객이 존재하므로 이항분포를 사용해서 고객에게 돈을 빌려줄지 여부를 결정하죠. 결정을 내릴 때는 확률이 큰 쪽을 선택할 거예요. 확률이 큰 쪽을 선택하는 것은 이성적인 판단이기 때문이에요. 그래서 고객 x가 high risk일 확률(P(C=1|x)이 x가 low-risk일 확률(P(C=0|x)보다 크다면 1이라는 결정을 내리고, 작다면 0이라는 결정을 내려요.하지만 우리가 내리는 결정에도 error(=risk)가 존재하겠죠?확률의 합은 항상 1이고 결정은 항상 P(C=1|x)나 P(C=0|x) 중 확률이 큰 쪽이기 때문에 1에서 그 확률을 빼면 그 결정의 error가 돼요. 베이즈 결정이론은 이처럼 분류하고자 하는 물체들에 대해서 사전 정보가 주어지는 경우에 사용이 될 수 있는 이론이에요.Bayes’ rule베이즈 결정이론에는 베이즈 정리(Bayes’ rule)가 사용되는데요. 자세히 살펴볼게요.- P(C) : prior probability(선행 확률, 특정 사건이 일어날 것에 대한 추가 정보를 획득하지 못한 확률)로 여기서는 x가 어떤 값을 가지든 C가 1일 확률을 말해요.- p(x|C) : likelihood(우도, C가 주어졌을 때 조건부 확률) C가 주어졌을 때 x를 가지고 있을  확률을 말해요. 따라서 x값에 따라 확률이 달라져요. 예를 들어 p(x|C = 1) 은 C가 1인 즉 high risk인 고객이 x를 가지고 있을 확률을 나타내요.- p(x) : evidence(증거)는 C와 상관없이  x가 나타날 확률이에요.- p(C|x) : posterior probability(사후 확률)로 우리는 사후 확률을 기반으로 아래와 같이 decision을 내려요.위의 예시처럼 두 가지 고객만 있는 상황(이항분포)이 아니라 K명의 고객이 있는 경우(다항분포)는 어떻게 계산할까요? 이 경우에도 베이즈 정리가 적용되는데 식이 조금 달라져요.p(x) 구하는 식만 달라지고 나머지는 위에서 봤던 예시와 같아요. 그리고 이항분포의 error는 1에서 둘 중에 큰 확률을 뺐듯이 다항분포의 error도 아래와 같이 구해요.Loss and Risk위의 이항분포에서는 고객에게 돈을 빌려줌으로써 돈을 못 받는 손실(Loss)이 존재하고 돈을 못 받을 것 같은 고객에게 빌려주지 않음으로써 생기는 손실이 존재해요. 이 중 어떤 것이 더 손실이 적을지 생각해봐야겠죠?의사 결정을 하는 행동(action)을 αi라고 했을 때 αi에 대한 손실을 λik라고 정의할게요.위의 식은 예상되는 손실값이에요. 이 손실값은 실제로는 k인 상황이지만 행동 αi를 취해서 생기는 손실이에요.손실을 줄여야 하기 때문에 가장 작은 손실이 생기는 행동을 취해야 해요. 따라서 위의 식을 보면 argmin함수를 이용해서 k개의 행동 중 가장 작은 손실을 취해요.Reject 의사 결정이 어려운 경우에는 의사 결정을 피하는 것이 더 적절한 경우도 있어요. 이때는 어떠한 행동도 하지 않는 행동 αK+1을 추가해요.action αK+1을 추가하면 αK+1에 따른 손실 λik 또한 하나가 더 늘어요.위의 수식은 reject 행동을 포함했을 때 결정을 내리는 식인데 간단하게 참고하시면 될 것 같아요.이번에는 베이즈 결정이론에 대해 자세하게 다뤘는데요. 이번 수업은 교수님께서 많은 것을 가르쳐주셔서 저 같은 초보자가 듣기에 조금 힘든 점이 있었어요. 벌써 8주차 이론수업의 절반 이상이 지났는데요. 5주 동안 배운 많은 이론들을 코드로 능숙하게 표현하는 데에는 많은 노력이 필요하겠지만, 이만큼 왔다는 것만으로도 뿌듯한 기분이 들어요. 8주차부터 시작하게 될 팀 프로젝트에서 실력 발휘를 하기 위해서 더 열심히 수업에 임해야겠어요!* 이 글은 AI스쿨 - 인공지능 R&D 실무자 양성과정 5주차 수업에 대하여 수강생 최유진님이 작성하신 수업 후기입니다.

8퍼센트에서 Python Django 코드에 대한 Test case 작성시 사용하는 가이드를 공유해보려고 합니다.클래스명일반적으로 TestCase 를 상속 받는 클래스일 경우 class 명의 마지막에 TestCase 를 붙입니다.예제: SimpleTestCase(TestCase)함수명테스트 함수명의 경우 test_ 로만 시작하면 동작하는데 문제가 없고 테스트 코드에까지 주석을 다는 것은 번거로우므로 함수명의 test_ 뒷부분을 한글로 하여 설명을 대신하도록 합니다.class IUPaginationMethodTestCase(TestCase): @classmethod def setUpTestData(cls): cls.request = Mock() cls.request.GET = {'page': 1, 'items_per_page': 1} cls.pagination = IUPagination(cls.request) def test_page_url_기본(self): expected = '?{}=1'.format(self.pagination.page_key) self.assertEqual(self.pagination.page_url(), expected) def test_page_url_쿼리스트링_없는경우_물음표_붙인다(self): expected = '/?{}=1'.format(self.pagination.page_key) self.pagination.url_prefix = '/' self.assertEqual(self.pagination.page_url(), expected) def test_page_url_쿼리스트링_있는경우_엠퍼센드로_붙인다(self): expected = '{}&{}=1'.format( self.pagination.url_prefix, self.pagination.page_key )) self.pagination.url_prefix = '?utm=source' self.assertEqual(self.pagination.page_url(), expected) factory_boyfixture 를 대신해서 가급적 factory_boy 를 사용합니다.signals 끄기factory boy로 모델 객체 생성시 signal 이 호출되는데 signal에 대한 테스트가 아니라면 대부분 실행할 필요가 없습니다.이 때 factory.django.mute_signals를 사용해서 끄면 됩니다.decorator, context manager 둘 다 사용 가능합니다.decorator@mute_signals(signals.post_save) def test_some_code(self): some = SomeFactory() context managerwith mute_signals(signals.post_save): some = SomeFactory() 참고 링크factory_boyDisabling signalssetUpTestData vs setUpfixture를 사용하면 fixture로 정의한 모델 객체가 모든 테스트 시작 전에 생성이 되는데 유사하게 setUp 에서 factory 생성을 하게 되면 매번 객체 생성을 하게 되므로 느립니다.테스트에서 read only 로만 사용하는 객체의 경우 class method인 setUpTestData 에서 생성하면 1번만 생성이 되므로 빨라집니다.가급적 setUp 에서 매번 객체를 생성하는 것을 지양하고 테스트 함수 내에서 필요한 객체만 생성하는 것이 효율적이고 빠릅니다.method mock메소드를 mock 하는 경우 unittest.mock.patch() 를 사용합니다.decorator보통 테스트 메소드에 대한 decorator 로 사용합니다.직접 호출class 내의 여러 테스트 메소드 혹은 모든 테스트 메소드에서 동일한 함수를 mock 하는 경우에는 start, stop 을 활용하면 편합니다.예제 코드from unittest import mock class MyTest(TestCase): def setUp(self): self.mock_method1 = mock.patch('package.module.method1').start() self.mock_method1 = mock.patch('package.module.method2').start() def tearDown(self): mock.patch.stopall() def test_something(self): something() self.assertTrue(self.mock_method1.called) 참고 링크: patch methods start and stoptimezonedatetime.datetime.now() datetime.datetime.strptime() 등을 사용해서 naive datetime 객체를 django 모델의 DateTimeField 에 할당할 필요가 있는 경우 반드시 django.utils.timezone.make_aware() 를 사용해서 time-zone-aware datetime 객체로 변환한 후에 합니다.참고 링크: Django timezone 문제 파헤치기freezegun특정 시점에서의 테스트가 필요한 경우 freezegun 을 사용해서 현재 시간값을 고정합니다.가급적 decorator 나 context manager 를 사용해서 특정 클래스나 메소드, 혹은 코드 블럭에만 적용하도록 하는 것이 좋습니다.decorator 예제from freezegun import freeze_time import datetime import unittest @freeze_time("2012-01-14") def test(): assert datetime.datetime.now() == datetime.datetime(2012, 1, 14) context manager 예제from freezegun import freeze_time def test(): assert datetime.datetime.now() != datetime.datetime(2012, 1, 14) with freeze_time("2012-01-14"): assert datetime.datetime.now() == datetime.datetime(2012, 1, 14) assert datetime.datetime.now() != datetime.datetime(2012, 1, 14) 특정 테스트 케이스 전체에 적용을 하기 위해 start(), stop() 메소드를 사용하기도 하는데 이 경우 반드시 stop() 을 해주어야 다른 테스트 케이스의 시간 값에 영향을 주지 않습니다.예제from django.test import TestCase from freezegun import freeze_time class SomeTestCase(TestCase): def setUp(self): self.freezer = freeze_time("2016-01-05 00:00:00") self.freezer.start() def tearDown(self): self.freezer.stop() 참고 링크: freezegun맺음말Python Django 개발시 Test case 작성을 잘 하기 위한 8퍼센트 개발팀의 가이드를 공유해 보았습니다. Python Django 개발자들이 Test case 작성을 효율적으로 잘 해서 서비스의 안정성을 높이는데 도움이 되기를 기대해 봅니다.#8퍼센트 #에잇퍼센트 #Django #Python #장고 #파이썬 #개발 #개발자 #가이드 #꿀팁 #인사이트

‘보안팀'을 생각했을 때 어떤 단어들이 떠오르시나요? 조금은 무시무시하지만 우람한 팔뚝, 강력한 눈빛, 태평양같은 어깨를 소유한 영화배우 ‘마요미' 마동석님이 떠오르네요. 코인원에서도 무시무시한 매의 눈으로 코인원 크루가 자리를 비울때 화면잠금이 되었는지 확인하는 ‘정요미'가 있습니다. 바로 코인원 보안을 책임지는 보안전략기획팀의 지원님이에요. 코인원 크루의 보안뿐만 아니라 고객들의 소중한 자산을 지키는 코인원의 수문장, 지원님을 만나볼까요?Q. 안녕하세요, 코인원의 ‘프로 화면잠금러'를 만나뵙게되어 정말 영광입니다.네, 저 또한 영광입니다. 제가 이전에 자리를 잠깐 비울때 화면잠금을 하지 않았는데요, 이렇게 영혼까지 털릴줄 몰랐습니다. ‘화면잠금도 모르면서 보안을 어떻게 논하느냐’ 라고들 하셔서 사죄의 의미로 커피를 쏘게 되었습니다. 이후 다시 이런 일이 없도록 스스로에게 다짐했을 뿐만 아니라 화면잠금 안하신 크루가 있는지 없는지 열심히 찾고 있습니다. (걸리기만 해 아주…-_-)Q. ‘프로 화면잠금러’로 오해하실 수도 있는 독자분들을 위해 ‘진짜’ 지원님 소개 부탁드릴게요:)안녕하세요, 코인원 보안본부 내 보안전략기획팀에서 근무하고 있는 정지원입니다. 코인원의 보안본부는 대내외 각종 보안 위협으로부터 선제적으로 대응할 수 있도록 Action Plan을 수립하고 실행하여 코인원의 모든 서비스와 자산을 보호하는 역할을 하고 있어요. 크게 보안전략기획팀, 개인정보보호팀, 보안운영팀으로 나뉘어 집니다.이 중에서 보안전략기획팀은 주로 대/내외 보안 트렌드를 파악하며 거래소 보안전략을 수립하고, 우선순위를 설정하고 조정하여 실행하고 있습니다. 더불어 코인원의 기존 서비스와 앞으로 출시될 신규 서비스의 보안 위험을 식별할 수 있도록 분석하고 대응방안을 마련하죠. 철저한 보안으로 코인원이 고객들에게 신뢰받을 수 있는 거래소가 되기 위해 최선을 다하고 있습니다.Q. 코인원을 이용하는 고객분들이라면 정말 궁금할 것 같아요. 코인원에 보관되어 있는 제 자산, 정말 안전하게 보관되어 있나요?“코인원 고객들의 자산은 100% 안전합니다" 라는 말 대신 “코인원 보안팀은 단 1%의 취약점도 허용하지 않기 위해 정말 최선을 다하고 있습니다" 라고 말씀드리고 싶어요.개인적으로 “고객의 자산은 100% 안전합니다.” 또는 “100% 완벽한 보안” 이라는 말은 성립할 수 없다고 생각해요. 취약점이 발생할 가능성은 언제나 있다고 생각하고, 그것이 1%의 가능성이라고 할지라도 해결방안을 고민해서 현실적인 대책을 세우고 실행해나가야 한다고 생각합니다.현재 코인원에서는 *DID(Defense In-Depth)의 개념으로 계층화된 보안 시스템(Multi-Layered Security)을 구축하고 발생할 수 있는 보안 위협에 대비합니다. 성을 공략하는 게임을 예를 들어 볼게요. A라는 성은 10m의 성벽 1개가 있고 B라는 성은 1m의 성벽 10개가 있다고 가정할께요. 성벽을 우회해서 성에 도착하기까지 어디가 시간이 더 걸릴까요?코인원은 마치 여러 개의 성벽처럼 계층화된 보안 방안을 구현, 거래소에 적용하고 있어요. 적용했다고 끝난게 아닙니다. 계속해서 모니터링 하면서 좋은 점과 나쁜 점을 모아놓고 좋은 점은 더 좋게, 나쁜 점은 개선할 수 있도록 재기획하고 실행합니다. 보다 더 안전하게 고객의 자산을 보호할 수 있는 방법을 고민하고 적용하고 있어요. *여기서 잠깐 DID(Defense In-Depth, 심층방어)란? 여러 계층의 보안 제어가 정보 기술(IT) 시스템 전반에 걸쳐 배치되는 정보 보증 개념입니다. 보안 제어가 실패하거나 시스템의 수명주기 동안 인력, 절차적, 기술적 및 물리적 보안 측면을 포괄 할 수있는 취약점이 악용되는 경우를 대비하여 다수의 방어 중복성을 제공하기 위한 것입니다.Q. 현재 코인원에서 진행하고 있는 보안정책은 어떤것들이 있을까요? 간단하게 소개해주세요.코인원 보안정책 중 몇가지를 소개해 드리자면, 코인원은 콜드월렛 보관 비중을 85%로 유지하여 고객자산을 보다 안전하게 보호하려고 노력하고 있습니다. 이는 사단법인 한국블록체인협회 권고 사항인 70% 보다 높은 비중이죠.또한 IT전문 보안 기업 SK infosec의 체계적인 보안관제 서비스를 제공받고 있습니다. 사이버 침해 위협을 실시간으로 감시하고 SK infosec이 보유한 방대한 위험 정보 데이터 베이스에 기반하여 고도화된 위협에 대응하고 있습니다. 마지막으로 이번에 새로 사이버 보안 기업 티오리(THEORI)의 전문적인 보안 컨설팅을 받게 되었습니다. 티오리는 미국 오스틴에 본사를 둔 기업으로 카네기멜론대학 해커팀(PPP) 핵심 멤버들이 설립한 사이버 보안 R&D 기업인데요, 데프콘(DEFCON) 같은 유명한 국제해킹방어대회에서 항상 상위권에 랭크되고는 합니다. 이렇게 검증된 역량을 바탕으로 Pen-Test(모의해킹)을 통해 코인원의 보안 아키텍쳐를 점검하고, 발생 가능한 모든 침해 시나리오를 상정하여 이에 대비하기 위한 자문을 진행할거에요.이외 다수의 테크니컬한 부분은 영업비밀(?) 입니다. (와하하하)Q. 콜드월렛을 잘 모르실 수도 있는 독자분들을 위해서 자세한 설명 부탁드려요. 또한 85%까지 비중을 유지하는것이 왜 중요한가요?먼저 콜드월렛에 대한 설명을 드릴게요. 콜드월렛은 핫월렛과 달리 네트워크가 연결되지 않은 물리적으로 분리된 저장 공간을 말합니다. 콜드월렛에 보관한다는 의미는 고객의 암호화폐 자산을 침해 또는 해킹 위협으로부터 원천적으로 차단된 별도의 장소에 보관한다는 뜻입니다. 그런일이 있어서는 안되겠지만, 사이버 침해가 발생한다고 가정할 경우 고객의 피해를 최소화할 수 있는 안전 장치에요. 블록체인 협회에서는 70%이상을 콜드월렛에 보관하는 것을 권고하고 있는데요. 저희는 협회에서 권고하기 이전부터 자체적으로 월렛 관리 정책을 만들고 그에 따라 콜드월렛을 운영해왔습니다. 참고로, 85%로 유지하는 이유는 거래소 비즈니스적으로 병목현상이 일어날 수 있는 부분을 방지하기 위한 적정 수준이라고 답할 수 있겠네요.보안팀은 무시무시하지 않아요, 부드럽습니다! (그윽한 눈빛을 발사하는 지원님)Q. 거래소 보안 전문가로서 막중한 책임감을 갖고 계실 것 같아요. 코인원 입사 후에 가장 기억에 남았던 혹은 어려움을 겪었던 에피소드가 있을까요?코인원의 보안 수준을 어떻게 하면 제1금융권 수준까지 끌어올릴 수 있을까에 대한 고민이 매우 컸습니다. 블록체인과 암호화폐 업계가 굉장히 폭발적으로 성장해왔는데요. 폭발적으로 성장하는 속도를 따라잡을 수 있도록 보안 및 인프라팀에서 무수한 노력을 해왔어요. 짧은 시간내에 보안 인프라를 효율적으로 구축할 수 있을지 치열하게 진행했던 회의들이 생각나네요. 코인원의 많은 크루들이 노력해주시고 도와주신 덕분인지 현재까지 코인원에서는 단 한건의 해킹사고도 발생하지 않았습니다. 최근에 생각나는건 금번 NH농협은행과의 재계약에서 보안 요구사항과 점검에 대한 실사가 많았는데 다행이 보안요건을 충족하며 재계약한 것이 생각나네요.Q. 지원님은 앞으로 보안본부에서 어떤 꿈을 이뤄나가고 싶으세요?글로벌 회사를 보면 유명한 보안팀들이 있어요. 예를 들어 구글에는 ‘프로젝트 제로(Project Zero)’라는 팀이 있는데, 이 팀은 ‘제로데이(0-day)’ 공격을 대비하기 위한 팀이에요. 제로데이 공격은 알려지지 않은 취약점을 발견해서 이에 대처하기 전 무방비 상태인 점을 악용하는 사이버 공격 방법이에요. 프로젝트 제로는 제로데이 공격 위협을 사전에 해소하기 위해 자사 제품 뿐만 아니라 타사 제품까지 연구하고 취약점이 발견된다면 해당 회사에 전달해서 대처할 수 있게 합니다. 또 다른 예로 야후에 “패러노이즈(Paranoids)”를 들 수 있겠네요. 야후의 모든 제품은 패러노이즈의 승인 없이는 론칭되지 않습니다. 전문성이 뛰어나지 않다면 가능하지 않은 케이스죠.저는 보안을 위해서라면 편집증적인 집착도 용서가 된다고 생각하는데요, 암호화폐 거래소 뿐만 아니라 블록체인 전반적인 영역에 대해 전문성을 발전시켜 궁극의 편집증 환자가 되는게...(?) 아 이게 아니고, 글로벌 유수의 보안팀들과 어깨와 나란히 하고 싶습니다.Q. 마지막으로 묻겠습니다. 지원님에게 ‘화면잠금' 이란?(인터뷰에서까지 영혼이 털리네요...) 회사 메신저에 제 프로필을 보시면 “화면잠금 털린 보안어린이”라고 되어 있습니다. 슬프네요 흑. 농담이구요, 어떤 일이던지 기본부터 충실해야 한다는 초심을 찾을 수 있었던 계기도 되었고 또 의도하지 않았지만 코인원 크루들이 보안은 어려운게 아니구나 라는 인식으로 바뀌게 된 계기가 된 것 같습니다. 수많은 보안 캠페인을 기획하고 시행했지만 지금처럼 크루들에게 여운이 남아있던 적이 없던 것 같아요. 앞으로 쉽지만 누구나 할 수 있는 보안 캠페인을 고민해 볼께요. (좋은 아이디어 주시면 제가 커피를 쏩니다!)충성! 단결! 필승! 오늘도 보안은 안전합니다 :-)언제나 보안을 최우선으로 고려하고, 원칙을 지키며 건전한 암호화폐 시장을 만들기 위해 지원님은 오늘도 24시간 365일 보안에 대한 고민을 풀가동하고 있습니다. 코인원을 이용하는 고객들의 안전한 거래를 위해 끊임없이 노력하는 보안전략기획팀에 많은 응원 부탁드립니다!#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트 #기업문화 #조직문화 #팀원소개 #인터뷰

사운들리는 '귀에 들리지 않는 소리'를 이용해서 컨텐츠를 전달할 수 있는 SaaS 플랫폼을 서비스하고 있습니다.제품의 구성요소는,음파를 송신할 수 있는 송신단음파를 모바일에서 수신할 수 있는 Android, iOS SDK그리고 컨텐츠를 제공하고 데이터를 수집, 분석하는 백엔드로 구성되어 있습니다.오늘은 구성 요소중 백엔드에 대해서 이야기 해보도록 하겠습니다.<그림 1. 사운들리 솔루션 구성도>사운들리의 인프라는 모두가 잘 아시는 아마존 웹 서비스를 이용하고 있으며, 크게 컨텐츠를 제공하는 API서버 부분, 로그를 수집, 분석하는 부분, 그리고 컨텐츠를 관리하는 CMS 부분으로 이루어져 있습니다.소프트웨어 스택Java : 현재 사운들리의 일부 시스템을 제외하고는 전부 자바로 작성되어 있습니다. Node.js로 시작하여 PHP를 거쳐 지금의 자바 기반의 시스템으로 구성하게 되었습니다. 다양한 사람들이 개발을 해오면서 각자 가장 잘할 수 있고, 빠르게 구현할 수 있는 언어로 개발되어 가다 현재의 자바로 통일되어 구성되게 되었습니다.Spring : API서버는 HTTP 기반의 REST API를 이용해 컨텐츠를 전달하고 있으며 스프링 프레임워크를 이용해 개발되었습니다. 이외에도 일부 분석에 스프링 배치를 사용하고 스프링을 편리하게 사용할 수 있게해주는 스프링 부트도 이용하고 있습니다.gRPC : 분산되어있는 서버들끼리 이기종 언어간 통신을 하기 위해서 Protocol Buffers 기반의 gRPC를 이용하고 있으며 서버들의 모니터링하는 서버와 에이전트들 사이의 통신 목적으로 사용합니다.Flume : 분산된 서버들에서 로그를 수집하는 역할을 합니다. 수집된 로그는 파일로 저장하며 실시간으로 볼수 있도록 엘라스틱서치에 같이 저장하고 있습니다. SDK에서 전송되는 로그 또한 웹서버의 엑세스 로그를 플럼 에이전트가 수집하는 방식으로 비동기로 처리하고 있습니다.ElasticSearch : 수집된 로그들을 실시간으로 확인하기 위해서 사용되며 Kibana를 이용해 시각화하고 있습니다.Angular.js : CMS의 프론트엔드는 Angular.js + Bootstrap을 이용해 개발되었으며, Bower를 이용한 라이브러리 관리, Grunt를 이용한 빌드 관리를 하고 있습니다.소프트웨어 개발/운영GIT : 소스코드는 git로 관리하며 Git-Flow를 이용한 브랜치 정책을 수립하여 가져가고 있고 저장소로는 깃허브를 이용합니다.Quality Practice : QA단계에서 제품을 테스트하기 전 개발자들은 QA 프로세스에 맞게 다음 3가지 기준으로 소스 코드의 품질을 관리합니다.코딩 컨벤션 : 사운들리 내부 코딩 컨벤션에 맞게 개발되었는지 확인합니다. Checkstyle의 규칙을 정의 및 자동화합니다.테스트 코드 : 단위 테스트 코드를 작성하며 테스트 결과는 모두 통과되어야 합니다.테스트 커버리지 : 단위 테스트 코드가 작성된 커버리지를 계산하며 현재 60%를 목표로 진행하고 있습니다.젠킨스 : 소스코드 저장소에 변동이 일어나면 젠킨스가 소스코드를 빌드하고 위에서 언급한 세가지에 대한 리포트를 작성합니다.소나큐브 : 무료 오픈소스로 코드 정적 분석을 해주며 및 QA 리포트를 같이 볼 수 있습니다.슬랙 : 인력이 적은 저희 팀도 슬랙을 적극적으로 개발/운영에서 사용하고 있습니다.팀 커뮤니케이션 : 팀원들 간의 의사사통을 위한 주요 수단으로 모든 팀원이 함께 사용하고 있습니다.분석 리포트 : 젠킨스나 배치를 통해 분석된 데이터들은 분석이 끝난 지표들은 슬랙으로 결과를 전송하여 모든 팀원이 볼 수 있도록 공유하고 있습니다.서버 모니터링 : 서버들의 이상 징후 감지나 배치 오류등을 슬랙을 통해 담당자에게 전송하여 조치할 수 있도록 합니다.애플리케이션 및 서버 모니터링 : 애플리케이션의 모니터링은 Naver에서 오픈소스로 공개한 핀포인트를 사용하고 있고, 서버 상태 모니터링을 위해 자체 개발한 모니터링 시스템을 사용하고 있습니다. 모니터링 데이터 수집을 하는 에이전트와 전체 시스템의 데이터를 관장 하는 서버간에는 gRPC를 이용하여 상태 체크를 합니다. 서버의 상태에 문제가 있을 때에는 slack을 통해 담당자들에게 알람을 주도록 시스템 설계를 하였습니다.개발 문화개발자들은 각각 개발을 할때 정해진 정책에 맞춰 브랜치를 만들어 개발합니다.각각 개발된 소스들은 저장소인 깃허브에 푸시된 후 깃허브의 댓글 기능을 이용하거나 오프라인을 통해 코드 리뷰를 진행합니다.리뷰가 끝난 후 합쳐진 소스는 QP 활동을 통해 분석이 됩니다.빌드가 실패할 경우 커피를 사야합니다 ^^ (커피를 얻어 먹으려는 것이 아닌 소스코드를 푸시하기 전 잘 확인하자는 취지입니다) AWSEC2 : 사운들리의 대부분의 구성 요소인 API서버와 로그 수집, 분석 서버, 엘라스틱서치, 플럼, CMS등이 모두 EC2에 구축되어 있습니다.RDS : 컨텐츠의 주 저장소로 데이터베이스 관리의 용이성을 고려하여 RDS의 Multi-AZ에 배포하여 Active-Standby로 구성되어 있으며 이 데이터들은 레디스와 로컬 캐시를 이용하여 API서버에서 활용하고 있습니다.S3 : 컨텐츠에 포함된 각종 정적 데이터들이 저장되며 수집된 로그들도 저장하여 보관됩니다. EMR : 로그 수집서버를 통해 S3에 저장된 로그들은 EMR을 이용해서 분석됩니다.Beanstalk : 개발 서버의 배포에 사용됩니다. 최근 IntelliJ의 플러그인이 업데이트 되면서 IntelliJ 15버전을 지원하게 되므로써 로컬에서 개발하고 개발 서버에 배포까지 편리하게 하고 있습니다. VPC : 인터넷이 필요 없는 서버들은 VPC 내부 private-zone에 배포 및 ELB를 통해 외부에서 접근하도록 구성되어 있습니다.<그림 2. AWS 배포 구성도>이상으로 사운들리에서 사용하고 있는 백엔드 소프트웨어들을 소개해 보았습니다. 적은 인력으로 빠르게 사업을 진행하는 스타트업에서는 비즈니스에 집중할 수 있도록 도와주는 다양한 툴이나 오픈소스를 이용하여 많은 도움을 받을 수 있는 것 같습니다. 또한 코드를 잘 작성하여 에러를 줄이는 것도 필요하지만 여유가 많지 않으면 최소한 제품의 에러에 빠르게 대응할 수 있도록 하는 방법도 필요한 것 같습니다.#사운들리 #개발 #개발자 #문제해결 #프레임워크 #스킬스택 #스택 #인사이트

비트윈에는 커플들이 서로에게 감정을 더욱 잘 표현할 수 있도록 스티커를 전송할 수 있는 기능이 있습니다. 이를 위해 스티커 스토어에서 다양한 종류의 스티커를 제공하고 있으며 사용자들은 구매한 스티커를 메시지의 첨부파일 형태로 전송을 할 수 있습니다. 저희가 스티커 시스템을 구현하면서 맞딱드린 문제와 이를 해결한 방법, 그리고 프로젝트를 진행하면서 배운 것들에 대해 소개해 보고자 합니다.스티커 시스템 아키텍처¶비트윈에서 스티커 기능을 제공하기 위해 다양한 구성 요소들이 있습니다. 전체적인 구성은 다음과 같습니다.비트윈 서버: 이전에 소개드렸었던 비트윈의 서버입니다. 비트윈의 채팅, 사진, 기념일 공유 등 제품내의 핵심이 되는 기능을 위해 운영됩니다. 스티커 스토어에서 구매한 스티커는 비트윈 서버를 통해 상대방에게 전송할 수 있습니다.스티커 스토어 서버: 스티커를 구매할 수 있는 스토어를 서비스합니다. 스티커 스토어는 웹페이지로 작성되어 있고 아이폰, 안드로이드 클라이언트와 유기적으로 연동되어 구매 요청 등을 처리합니다. 처음에는 Python과 Flask를 이용하여 구현하려 하였으나 결국엔 서버 개발자들이 좀 더 익숙한 자바로 구현하기로 결정하였습니다. Jetty와 Jersey를 사용하였고, HTML을 랜더링하기 위한 템플릿 엔진으로는 Closure Template을 이용하였습니다. ORM으로는 Hibernate/JPA, 클라이언트와 웹페이지간 연동을 위해서 Cordova를 이용하였습니다. EC2에서 운영하고 있으며 데이터베이스로는 RDS에서 제공하는 MySQL을 사용합니다. 이미 존재하는 솔루션들을 잘 활용하여 최대한 빨리 개발 할 수 있도록 노력을 기울였습니다.스티커 다운로드 서버: 스티커는 비트윈에서 정의한 특수한 포맷의 파일 형태로 제공됩니다. 기본적으로 수 많은 사용자가 같은 스티커 파일을 다운로드 받습니다. 따라서 AWS에서 제공하는 CDN인 CloudFront을 이용하며, 실제 스티커 파일들은 S3에서 호스팅합니다. 그런데 스티커 파일들은 디바이스의 해상도(DPI)에 따라 최적화된 파일들을 내려줘야하는 이슈가 있었습니다. 이를 위해 CloudFront와 S3사이의 파일 전송에 GAE에서 운영중인 간단한 어플리케이션이 관여합니다. 이에 대해서는 뒷편에서 좀 더 자세히 설명하도록 하겠습니다.구현상 문제들과 해결 방법들¶적정 기술에 대해 고민하다¶스티커 스토어 서버를 처음 설계할때 Flask와 SQLAlchemy를 이용하여 구현하고자 하였습니다. 개발팀 내부적으로 웹서버를 만들때 앞으로 Python과 Flask를 이용해야겠다는 생각이 있었기 때문이며, 일반적으로 Java보다는 Python으로 짜는 것이 개발 효율이 더 좋다는 것은 잘 알려진 사실이기도 합니다. 하지만 Java에 익숙한 서버 개발자들이 Python의 일반적인 스타일에 익숙하지 않아 Python다운 코드를 짜기 어려웠고, 오히려 개발하는데 비용이 더 많이 들어갔습니다. 그래서 개발 중에 다시 웹 서버는 자바로 짜게 되었고, 여러가지 스크립트들만 Python으로 짜고 있습니다. 실제 개발에 있어서 적절한 기술의 선택은 실제 프로젝트에 참여하는 개발자들의 능력에 따라 달라져야한다는 것을 알게되었습니다.스티커 파일 용량과 변환 시간을 고려하다¶사용자는 스티커 스토어에서 여러개의 스티커가 하나로 묶인 스티커 묶음을 구매하게 됩니다. 구매 완료시 여러개의 스티커가 하나의 파일로 압축되어 있는 zip파일을 다운로드 받게 됩니다. zip파일내의 각 스티커 파일에는 스티커를 재생하기 위한 스티커의 이미지 프레임들과 메타데이터에 대한 정보들이 담겨 있습니다. 메타데이터는 Thrift를 이용하여 정의하였습니다.스티커 zip파일 안에는 여러개의 스티커 파일이 들어가 있으며, 스티커 파일은 다양한 정보를 포함합니다카카오톡의 스티커의 경우 애니메이션이 있는 것은 배경이 불투명하고 배경이 투명한 경우에는 애니메이션이 없습니다. 하지만 비트윈 스티커는 배경이 투명하고 고해상도의 애니메이션을 보여줄 수 있어야 했습니다. 배경이 투명한 여러 장의 고해상도 이미지를 움직이게 만드는 것은 비교적 어려운 점이 많습니다. 여러 프레임의 이미지들의 배경을 투명하게 하기 위해 PNG를 사용하면 JPEG에 비해 스티커 파일의 크기가 너무 커집니다. 파일 크기가 너무 커지면 당시 3G 환경에서 다운로드가 너무 오래 걸려 사용성이 크게 떨어지기 때문에 무작정 PNG를 사용할 수는 없었습니다. 이에 대한 해결책으로 투명 기능을 제공하면서도 파일 크기도 비교적 작은 WebP를 이용하였습니다. WebP는 구글이 공개한 이미지 포맷으로 화질 저하를 최소화 하면서도 이미지 파일 크기가 작다는 장점이 있습니다. 각 클라이언트에서 스티커를 다운 받을때는 WebP로 다운 받지만, 다운 받은 이후에는 이미지 로딩 속도를 위해 로컬에 PNG로 변환한 스티커 프레임들을 캐싱합니다.그런데 출시 된지 오래된 안드로이드나 iPhone 3Gs와 같이 CPU성능이 좋지 않은 단말에서 WebP 디코딩이 지나치게 오래 걸리는 문제가 있었습니다. 이런 단말들은 공통적으로 해상도가 낮은 디바이스였고, 이 경우에는 특별히 PNG로 스티커 파일을 만들어 내려줬습니다. 이미지의 해상도가 낮기 때문에 파일 크기가 크지 않았고, 다운로드 속도 문제가 없었기 때문입니다.좀 더 나은 주소 포맷을 위해 GAE를 활용하다¶기본적으로 스티커는 여러 사용자가 같은 스티커 파일을 다운받아 사용하기 때문에 CDN을 이용하여 배포하는 것이 좋습니다. CDN을 이용하면 스티커 파일이 전 세계 곳곳에 있는 엣지 서버에 캐싱되어 사용자들이 가장 최적의 경로로 파일을 다운로드 받을 수 있습니다. 그래서 AWS의 S3와 CloudFront를 사용하여 스티커 파일을 배포하려고 했습니다. 또한, 여러 해상도의 디바이스에서 최적의 스티커를 보여줘야 했습니다. 이 때문에 다양한 해상도로 만들어진 스티커 파일들을 S3에 올려야 했는데 클라이어트에서 스티커 파일을 다운로드시 주소 포맷을 어떻게 가져가야 할지가 어려웠습니다. S3에 올리는 경우 파일와 디렉터리 구조 형태로 저장되기 때문에 아래와 같은 방법으로 저장이 가능합니다.http://dl.sticker.vcnc.co.kr/[dpi_of_sticker]/[sticker_id].sticker하지만, 이렇게 주소를 가져가는 경우 클라이언트가 자신의 해상도에 맞는 적절한 스티커의 해상도를 계산하여 요청해야 합니다. 이것은 클라이언트에서 서버에서 제공하는 스티커 해상도 리스트를 알고 있어야 한다는 의미이며, 이러한 정보들은 최대한 클라이언트에 가려 놓는 것이 유지보수에 좋습니다. 클라이언트는 그냥 자신의 디스플레이 해상도를 전달하기만 하고, 서버에서 적절히 계산하여 알맞은 해상도의 스티커 파일을 내려주는 것이 가장 좋습니다. 이를 위해 스티커 다운로드 URL을 아래와 같은 형태로 디자인하고자 하였습니다.http://dl.sticker.vcnc.co.kr/[sticker_id].sticker?density=[dpi_of_device]하지만 S3와 CloudFront 조합으로만 위와 같은 URL 제공은 불가능하며 따로 다운로드 서버를 운영해야 합니다. 그렇다고 EC2에 따로 서버를 운영하는 것은 안정적인 서비스 운영을 위해 신경써야할 포인트들이 늘어나는 것이어서 부담이 너무 컸습니다. 그래서, 아래와 같이 GAE를 사용하기로 하였습니다.GAE는 구글에서 일종의 클라우드 서비스(PaaS)로 구글 인프라에서 웹 어플리케이션을 실행시켜 줍니다. GAE에 클라이언트에서 요청한 URL을 적절한 S3 URL로 변환해주는 어플리케이션을 만들어 올렸습니다. 일종의 Rewrite Engine 역할을 하는 것입니다. 서비스의 안정성은 GAE가 보장해주고, S3와 CloudFront의 안정성은 AWS에서 보장해주기 때문에 크게 신경쓰지 않아도 장애 없는 서비스 운영이 가능합니다. 또한 CloudFront에서 스티커 파일을 최대한 캐싱 하며 따라서 GAE를 통해 새로 요청을 하는 경우는 거의 없기 때문에 GAE 사용 비용은 거의 발생하지 않습니다. GAE에는 클라이언트에서 보내주는 해상도를 보고 적당한 해상도의 스티커 파일을 내려주는 아주 간단한 어플리케이션만 작성하면 되기 때문에 개발 비용도 거의 들지 않았습니다.토큰을 이용해 보안 문제를 해결하다¶실제 스티커를 구매한 사용자만 스티커를 사용할 수 있어야 합니다. 스티커 토큰을 이용해 실제 구매한 사용자만 스티커를 전송할 수 있도록 구현하였습니다. 사용자가 스티커 스토어에서 스티커를 구매하게 되면 각 스티커에 대한 토큰을 얻을 수 있습니다. 스티커 토큰은 다음과 같이 구성됩니다.토큰 버전, 스티커 아이디, 사용자 아이디, 유효기간, 서버의 서명서버의 서명은 앞의 네 가지 정보를 바탕으로 만들어지며 서버의 서명과 서명을 만드는 비밀키는 충분히 길어서 실제 비밀키를 알지 못하면 서명을 위조할 수 없습니다. 사용자가 자신이 가지고 있는 스티커 토큰과 그에 해당하는 스티커를 비트윈 서버로 보내게 되면, 비트윈 서버에서는 서명이 유효한지 아닌지를 검사합니다. 서명이 유효하다면 스티커를 전송이 성공하며, 만약 토큰이 유효하지 않다면 스티커의 전송을 허가하지 않습니다.못다 한 이야기¶비트윈 개발팀에게 스티커 기능은 개발하면서 우여곡절이 참 많았던 프로젝트 중에 하나 입니다. 여러 가지 시도를 하면서 실패도 많이 했었고 덕분에 배운 것도 참 많았습니다. 기술적으로 크게 틀리지 않다면, 빠른 개발을 위해서 가장 익숙한 것으로 개발하는 것이 가장 좋은 선택이라는 알게 되어 스티커 스토어를 Python 대신 Java로 구현하게 되었습니다. 현재 비트윈 개발팀에서 일부 웹사이트와 스크립트 작성 용도로 Python을 사용하고 있지만 Python을 잘하는 개발자가 있다면 다양한 프로젝트들를 Python으로 진행할 수 있다고 생각합니다. 팀내에 경험을 공유할 수 있는 사람이 있다면 피드백을 통해 좋은 코드를 빠른 시간안에 짤 수 있고 뛰어난 개발자는 언어와 상관없이 컴퓨터에 대한 깊이 있는 지식을 가지고 있을 것이기 때문입니다.네 그렇습니다. 결론은 Python 개발자를 모신다는 것입니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!

클라우드 서비스를 사용하시는 많은 분들이 CPU Steal Time에 대해 문의합니다. CPU Steal은 클라우드 서비스와 물리 서버의 환경차이에서 발생하는 대표적인 지표이기도 합니다. CPU Steal Time이 높아지면 CPU 부하율이 높아지기 때문에 웹 서비스에 장애를 초래하기도 합니다. 가상화를 위해 자원을 분배하는 과정에서 cpu의 자원을 빼기는 것이기 때문에 클라우드 사용자 입장에서는 억울한 감이 있는 지표이기도 합니다. 하지만 클라우드 서비스가 공유 자원을 효율적으로 사용하는 것이기에 어쩔 수 없는 부분이기도 합니다. 그럼 이 CPU Steal Time 또는 CPU Stolen Time이라고 불리는 지표에 대해 알아보도록 하겠습니다.  CPU Steal Time이 무언가요?CPU Steal time은 은 하이퍼 바이저가 다른 가상 프로세서를 서비스하는 동안 가상 CPU가 실제 CPU를 기다리는 시간을 백분율로 표시한 값입니다.가상 환경에서 동작하는 가상 시스템 (VM)은 단일 호스트에있는 다른 인스턴스와 리소스를 공유합니다. 공유하는 리소스 중 하나가 CPU주기입니다. VM이 실제 서버에있는 동일한 크기의 4 개의 VM 중 하나 인 경우 해당 CPU 사용률은 모든 CPU주기의 25 %로 제한되지 않습니다. CPU 사용 비율보다 많은 비율을 사용할 수 있습니다.CPU Steal Time은 어떻게 확인하는가?Linux top 명령을 실행하면 주요 성능 메트릭의 실시간보기를 볼 수 있습니다. 그 중 하나는 CPU를위한 것입니다.이미 경험 한 두 가지 통계는 % id (percent idle)와 % wa (percent I/O wait)입니다. % id가 낮 으면 CPU가 열심히 작동하고 있는 것이며 % id가 높으면 남은 용량이 많지 않은 것입니다. % wa가 높으면 CPU는 실행할 준비가되었지만 I / O 액세스가 완료 될 때까지 기다리고 있습니다 (디스크에 저장된 데이터베이스 테이블에서 행을 가져 오는 것과 같습니다).% st 또는 % steal time은 표시된 마지막 CPU 메트릭입니다.CPU steal time이 높으면 어떤 상황이 발생하는가.백그라운드에서 장시간 걸리는 작업의 경우, 다른 VM들과 CPU 주기를 공유하는 과정에서 조금 더 느리게 작업이 마무리 될 수 있습니다. CPU steal time은 이런 경우 작업을 중지시키는 요소로 작용하지 않습니다. 가끔은 리소스를 나누는 과정에서 작업이 더 빠르게 끝나기도 합니다. 하지만 웹앱의 경우 실시간 처리가 필요한 경우들이 있습니다. 많은 웹 응답이 이뤄져야 하는 상황에서 cpu steal time이 높아지고, 그로인해 성능이 4배이상 감소한다면 중요한 리케스트가 처리되지 못하면서 서비스에 장애가 발생할 수도 있습니다. CPU steal time이 높은 원인은?cpu steal time이 높은 원인은 둘 중 하나입니다.  더 많은 CPU 리소스를 가지고 있는 VM을 필요로 합니다. (여러분의 문제입니다.)물리버서가 과대 판매되어 가상화 장비가 공격적으로 경쟁하는 상황입니다. (여러분의 문제가 아닙니다. 아마존 나빠요.)아쉽게도 cpu 매트릭만으로 위 두가지 상황을 판별하는 것은 쉽지 않습니다. 하지만 같은 역할을 하는 복수의 호스트를 여러개 가지고 있다면 다음과 같이 분별해 볼 수 있습니다.  1. 리소스 부족의 경우위 그림처럼 모든 VM에서 %st(cpu steal time)이 높다면 시스템이 더 많은 cpu를 사용해야 한다는 것을 의미합니다. 더 높은 사양의 VM을 선택하셔야 합니다. 2. 클라우드 사업자의 과다 판매의 경우위 그림처럼 일부의 VM에서만 %st(cpu steal time)이 높다면 같은 물리 호스트에 있는 다른 VM들이 서버의 자원을 과다하게 사용하고 있을 확률이 높습니다. 물리적으로 다른 호스트로 이동하여 해결 할 수 있습니다.대처 방법을 알아보자.일반적인 경우 steal time이 20분동안 10%를 넘기는 상태에서 유지되고 있다며, VM은 정량 보다 느리게 동작하고 있을 것입니다.인스턴스를 중지하고 다른 물리 서버로 이동하세요. 그래도 steal time이 높다면 cpu 리소스를 업그레이드하세요. 그리도 steal time이 높다면 클라우드 서비스 제공자에게 문의하세요.클라우드 서비스가 과설계된것은 아닌지 알아보세요. 와탭을 사용해서 cpu steal 매트릭을 추적하세요. 최근 와탭에 들어오는 가장 많은 문의 중 하나가 cpu steal입니다. cpu steal로 인해 cpu 부하율이 80%이상으로 올라가는 경우 클라우드 서비스에 익숙하지 않은 분들은 많이 당항하게 됩니다. 이런 경우 너무 곤란해 하지 마시고 일회성 이슈인지 체크하시고 반복된다면 cpu 리소스를 업그레이드 하거나 서비스를 다른 물리서버로 이동하시기 바랍니다. 제가 가지고 있는 sample중에 cpu steal이 나온 케이스가 없지만 whatap.io는 cpu steal 값을 5초마다 저장하여 제공합니다.  관련 urlhttp://hakurei.tistory.com/67[Linux] 가상환경에서의 CPU Steal Time 개념물리 장비에다가 여러대의 가상머신을 두는 가상환경을 구축하는 경우가 많다. 가상머신이 많아지는 경우, 동일한 물리 장비에서 제공되는 환경이다보니, 특정 가상머신이 CPU를 많이 차지하게 되면, 다른 머신들도 따라서 느려지게 되는데, 이 현상을 CPU Steal이라고 한다. CPU를 많이 차지하고 있는 머신의 CPU Steal Time은 낮게 측정이되고, 같은 물리 장비에 구성된 다른 가상 머신의 경우 CPU Steal Time이 높게 측정이..hakurei.tistory.com http://www.stackdriver.com/understanding-cpu-steal-experiment/» Understanding CPU Steal – An Experimentwww.stackdriver.com http://blog.scoutapp.com/articles/2013/07/25/understanding-cpu-steal-time-when-should-you-be-worriedUnderstanding CPU Steal Time - when should you be worried?blog.scoutapp.com #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

블로그 첫 글에서 비트윈의 시스템 아키텍처에 대해 다룬 적이 있습니다. 시스템 구성의 미래에 대한 계획으로 멀티티어 아키텍처에 대해 언급했었는데, 이는 프로토콜을 단순화시키고 배포 자동화를 가능하게 하기 위해서 클라이언트와 비즈니스 로직을 담당하는 서버 사이에 일종의 게이트웨이를 두는 것이었습니다. 그 외에도 여러 가지 필요성이 생겨 해당 역할을 담당하는 프레젠터라는 것을 만들게 되었고 비트윈의 채팅 시스템에 적용하게 되었습니다. 만드는 과정 중에 여러 기술적인 문제들이 있었고 이를 해결하기 위한 노력을 하였습니다. 이 글에서는 비트윈 시스템에서의 프레젠터에 대해 이야기 하고자 합니다.프레젠터¶프레젠터는 일종의 게이트웨이 입니다. 기존의 시스템에서는 클라이언트들이 ELB를 통해 채팅 서버에 직접 TCP 연결을 하였습니다. 하지만 비트윈 PC버전과 자체 푸시 서버를 만들면서 ELB로는 해결할 수 없는 부족한 점들이 생겼고, ELB의 부족한 점을 채워줄 수 있는 시스템이 필요하게 되었습니다. ELB를 대체하는 역할 외에도 다른 여러 필요했던 기능들을 제공하는 프레젠터를 만들기로 하였습니다.프레젠터는 ELB의 역할을 할 뿐만 아니라 여러 다른 기능들도 제공합니다.프레젠터의 기능¶패킷을 적절한 샤드로 중계¶비트윈에서는 커플 단위로 샤딩하여 같은 커플의 채팅 요청에 대해서는 같은 채팅 서버에서 처리하고 있습니다. Consistent Hash를 통해 커플을 여러 채팅 서버로 샤딩하고 ZooKeeper를 이용하여 이 정보를 여러 채팅 서버 간 공유합니다. 프레젠터 또한 ZooKeeper와 연결을 하여 어떤 채팅 서버가 어떤 커플을 담당하는지에 대한 정보를 알고 있도록 설계되어 있습니다. 따라서 프레젠터는 첫 연결 시 보내는 인증 패킷을 보고 해당 채팅 연결에서 오는 요청들을 어떤 채팅 서버로 보내야 할지 판단할 수 있습니다. 어떤 채팅 서버로 보낼지 판단하는 과정은 처음 한 번만 일어나며, 이후 패킷부터는 자동으로 해당 채팅 서버로 중계합니다.프레젠터의 이런 기능 덕분에 클라이언트는 더 이상 어떤 채팅 서버로 붙어야 하는지 알아내는 과정 없이 아무 프레젠터와 연결만 맺으면 채팅을 할 수 있게 되었습니다. 기존에는 클라이언트들이 여러 채팅 서버 중 어떤 서버에 붙어야 하는지 확인하는 작업을 한 후에 할당된 채팅 서버로 연결 맺어야 했습니다. 그래서 클라이언트가 채팅 서버와 연결을 맺기 위해 다소 복잡한 과정을 거쳐야 했지만, 이제는 클라이언트가 프레젠터의 주소로 연결 요청만 하면 DNS Round Robin 통해 아무 프레젠터와 연결하는 방식으로 프로토콜을 단순화할 수 있었습니다. 덕분에 새로운 채팅 서버를 띄울 때마다 ELB를 Warm-Up 시켜야 했던 기존 시스템의 문제가 없어졌습니다. 그래서 비트윈 개발팀의 오랜 염원이었던 채팅 서버 오토스케일의 가능성도 열렸습니다.많은 수의 연결을 안정적으로 유지¶PC버전과 푸시 서버를 만들면서 기존의 채팅 연결과 다르게 많은 수의 연결이 장시간 동안 유지 되는 경우를 처리할 수 있어야 했습니다. 기존에는 TCP 릴레이를 하도록 설정된 ELB가 연결들을 받아주었습니다. 한 머신당 6만 개 정도의 Outbound TCP 연결을 맺을 수 있는데, ELB도 트래픽에 따라 여러 대의 머신에서 돌아가는 일종의 프로그램이므로 이 제한에 걸린다고 생각할 수 있습니다. 따라서 많은 수의 연결을 맺어놓고 있어야 하는 경우 ELB에 문제가 생길 수 있다고 판단했습니다. (과거 ELB가 연결 개수가 많아지는 경우 스케일아웃이 안되는 버그 때문에 문제가 된 적이 있기도 했습니다) 또한 클라이어트 연결당 내부 연결도 하나씩 생겨야 하면 클라이언트가 연결을 끊거나 맺을 때마다 서버 내부 연결도 매번 끊거나 연결해야 하는 오버헤드가 발생합니다.이를 해결하기 위해 프레젠터에서는 TCP 연결을 Multiplexing하는 프로토콜을 구현하여 적은 수의 내부 연결로 많은 수의 클라이언트 연결을 처리할 수 있도록 하였습니다. 서버 내부에서는 고정된 개수의 몇 개의 연결만 맺어 놓고 이 연결들만으로 수많은 클라이언트 연결을 처리할 수 있습니다. 이처럼 TCP Multiplexing을 하는 것은 Finagle과 같은 다른 RPC 프로젝트에서도 지원하는 기능입니다.TCP Multiplexing 프로토콜을 통해 많은 수의 클라이언트 연결을 소수의 서버 내부 연결로 처리합니다.또한, 프레젠터는 많은 수의 SSL 연결을 처리해야 하므로 암복호화 로직을 실행하는데 퍼포먼스가 매우 중요하게 됩니다. 채팅 서버 한 대를 제거하거나 하는 경우 많은 연결이 한꺼번에 끊어지고 연이어 한꺼번에 연결을 시도하게 되는 경우가 있을 수 있는데, 이 때 대량의 SSL Handshaking을 하게 됩니다. 기존 서버들로 대량의 SSL Handshaking을 빠른 시간안에 처리하기 위해서는 높은 퍼포먼스가 필요합니다. Java로 작성된 프로그램만으로 이런 퍼포먼스 요구사항을 달성하기 어려우므로, 클라이언트와의 연결을 담당하는 부분은 OpenSSL, libevent를 이용한 C++로 코드로 작성하였습니다. 인증 패킷을 파싱하거나 패킷들을 릴레이 하는 등의 로직을 담당하는 부분은 Alfred라는 Netty를 이용하여 만든 인하우스 RPC 라이브러리를 이용해 작성되었습니다. 연결을 담당하는 부분은 TCP 연결을 유지하는 역할과 들어온 패킷들을 Netty로 작성된 모듈로 릴레이 하는 역할만 담당하므로 매우 간단한 형태의 프로그램입니다. 짧은 시간 안에 어럽지 않게 구현할 수 있었습니다.클라이언트의 연결을 받아주는 역할을 하는 부분은 C++, 실제 로직이 필요한 부분은 Java로 작성하였습니다.여러 네트워크 최적화 기술의 지원¶ELB에는 여러 네트워크 최적화 기술들을 아직 제공하지 않는 경우가 있습니다. 대표적으로 HTTP/2 혹은 SPDY, QUIC, TCP Fast Open 등이 있습니다. 특히 모바일 환경에서는 SSL Handshaking 등 부가적인 RTT로 인한 지연을 무시할 수 없으므로 이런 기술들을 이용한 초기 연결 시간 최적화는 서비스 퀄리티에 중요한 부분 중 하나입니다. ELB는 AWS에서 관리하는 서비스이므로 AWS에서 이런 기능들을 ELB에 적용하기 전에는 이용할 수 없지만, 프레젠터는 직접 운영하는 서버이므로 필요한 기능을 바로바로 적용하여 서비스 품질을 높일 수 있습니다. ELB에서 이미 제공하는 최적화 기술인 SSL Session Ticket이나 다른 몇몇 기술은 이미 적용되어 있고 아직 적용하지 않은 기술들도 필요에 따라 차차 적용할 예정입니다.프레젠터의 구현¶C++ 연결 유지 모듈¶프레젠터는 퍼포먼스를 위해 C++로 작성되었습니다. 이는 Pure Java를 이용한 암복호화는 프레젠터에서 원하는 정도의 퍼포먼스를 낼 수 없기 때문입니다. 처음에는 OpenSSL과 libevent를 이용해 작성된 코드를 JNI를 통해 Netty 인터페이스에 붙인 event4j라는 인하우스 라이브러리를 이용하려고 했으나, 코드가 복잡하고 유지보수가 어렵다는 점 때문에 포기하였습니다. 그 후에는 netty-tcnative를 이용해보고자 했으나 테스트 결과 연결당 메모리 사용량이 큰 문제가 있었고, 이를 수정하기에는 시간이 오래 걸릴 것 같아 포기하였습니다. 결국, 페이스북에서 오픈소스로 공개한 C++ 라이브러리인 folly를 활용하여 프레젠터를 작성하게 되었습니다. folly의 네트워크 API들이 OpenSSL과 libevent를 이용해 구현되어 있습니다.릴레이 로직¶프레젠터는 첫 인증 패킷을 파싱하여 릴레이할 채팅 서버를 판단하며, 이후의 패킷부터는 실제 패킷을 까보지 않고 단순 릴레이 하도록 설계하였습니다. 처음의 Netty 파이프라인에는 Alfred 프로토콜을 처리할 수 있는 핸들러들이 설정되어 있어 인증 패킷을 파싱 할 수 있으며 인증 패킷에 있는 정보를 바탕으로 어떤 채팅 서버로 패킷을 릴레이 할지 결정합니다. 그 이후 파이프라인에 있던 핸들러를 모두 제거 한 후, 읽은 byte 스트림을 Multiplexing Protocol 프레임으로 감싸서 그대로 릴레이 하는 매우 간단한 로직을 담당하는 핸들러 하나를 추가합니다. 덕분에 로직 부분의 구현도 매우 간단해질 수 있었으며, 채팅 서버에 API가 추가되거나 변경되어도 프레젠터는 업데이트할 필요가 없다는 운영상 이점도 있었습니다.Multiplexing Protocol¶프레젠터의 Multiplexing Protocol은 Thrift를 이용하여 직접 정의 하였으며, 비트윈 개발팀 내부적으로 사용 중인 RPC 라이브러리인 Alfred에 이 프로토콜을 구현하였습니다. Thrift를 통해 C++과 Java로 컴파일된 소스코드를 각각 프레젠터의 연결 처리 부분과 로직 처리 부분에서 이용하여 통신합니다. 프레젠터에서는 Multiplexing된 TCP 연결들을 Stream이라고 명명하였으며 이는 SPDY나 HTTP/2에서의 호칭 방법과 유사합니다. SPDY나 HTTP/2도 일종의 Multiplexing 기능을 제공하고 있으며, 프레젠터의 Multiplexing Protocol도 SPDY 프레임을 많이 참고하여 작성되었습니다.수 많은 클라이언트와의 TCP연결을 Stream으로 만들어 하나의 내부 TCP연결을 통해 처리합니다.Alfred에서는 Multiplexing 된 TCP 연결을 Netty의 Channel 인터페이스로 추상화하였습니다. Netty에서 TCP 연결 하나는 Channel 하나로 만들어지는데, 실제 Stream도 Channel 인터페이스로 데이터를 읽거나 쓸 수 있도록 하였습니다. 이 추상화 덕분에 비트윈 비즈니스 로직을 담당하는 코드에서는 Stream으로 Multiplexing 된 TCP 연결을 마치 기존의 TCP 연결과 똑같이 Channel을 이용해 사용할 수 있었습니다. 그래서 실제 비즈니스 로직 코드는 전혀 건드리지 않고 프레젠터를 쉽게 붙일 수 있었습니다.로드 밸런싱¶클라이언트는 Route53에서 제공하는 DNS Round Robin 기능을 이용하여 아무 프레젠터에 연결하여 채팅 요청을 날리게 됩니다. 하지만 무조건 동등하게 Round Robin 하게 되면 새로 켜지거나 하여 연결을 거의 맺지 않고 놀고 있는 프레젠터가 있는데도 연결을 많이 맺고 있는 기존 프레젠터에에 연결이 할당되는 문제가 생길 수 있습니다. 충분한 시간이 흐르면 결국에는 연결 개수는 동등하게 되겠지만, 처음부터 놀고 있는 프레젠터에 새로운 연결을 가중치를 주어 할당하면 로드를 분산되는 데 큰 도움이 될 것입니다. 그래서 Route53의 Weighted Routing Policy 기능을 이용하기로 하였습니다. 현재 연결 개수와 CPU 사용량 등을 종합적으로 고려하여 Weight를 결정하고 이를 주기적으로 Route53의 레코드에 업데이트합니다. 이런 방법으로 현재 로드가 많이 걸리는 서버로는 적은 수의 새로운 연결을 맺게 하고 자원이 많이 남는 프레젠터로 더 많은 새로운 연결이 맺어지도록 하고 있습니다.스케일 인/아웃¶AWS에서는 트래픽에 따라 서버 개수를 늘리기도 하고 줄이기도 하는 AutoScaling 이라는 기능이 있습니다. 프레젠터가 스케일 아웃될때에는 프레젠터가 스스로 Route53에 레코드를 추가하는 식으로 새로운 연결을 맺도록 할 수 있습니다. 하지만 스케일 인으로 프레젠터가 제거될 때에는 Route53에서 레코드를 삭제하더라도 함부로 프레젠터 서버를 종료시킬 수 없습니다. 종종 클라이언트의 DNS 캐싱 로직에 문제가 있어, Route53에서 레코드를 삭제되었는데도 불구하고 이를 업데이트하지 못해 기존 프레젠터로 연결을 시도하는 경우가 있을 수 있기 때문입니다. 따라서 프레젠터 클러스터가 스케일 인 될 때에는 기존의 모든 연결이 끊어지고 충분한 시간 동안 새로운 연결이 생기지 않은 경우에만 서버를 종료시켜야 합니다. AutoScaling Group의 LifeCycleHook을 이용하여 위와 같은 조건을 만족 시켰을 때에만 프레젠터 서버를 완전히 종료시키도록 하였습니다.못다 한 이야기¶프레젠터라는 이름이 이상하다고 생각하시는 분들이 있을 것으로 생각합니다. 멀티티어 아키텍처를 이야기할 때 프레젠테이션 티어, 어플리케이션 티어, 데이터베이스 티어로 구분하곤 하는데 이 프레젠테이션 티어에서 나온 이름입니다. 지금은 실제 프레젠터가 하는 역할과 프레젠테이션 티어가 보통 맡게 되는 역할에는 많은 차이가 있지만, 어쩌다 보니 이름은 그대로 가져가게 되었습니다.프레젠터에서 AutoScaling을 하기 위해 LifeCycleHook을 이용합니다. 이때 프레젠터를 위해 LifeCycleHook 이벤트를 처리하는 프로그램을 직접 짠 것이 아니라 비트윈 개발팀이 내부적으로 만든 Kharon이라는 프로그램을 이용하였습니다. Kharon은 인스턴스가 시작되거나 종료될 때 실행할 스크립트를 작성하고 인스턴스의 특정 위치에 놓는 것만으로 LifeCycleHook을 쉽게 이용할 수 있게 하는 프로그램입니다. Kharon 덕분에 비트윈 내 다양한 시스템에서 별다른 추가 개발 없이 LifeCycleHook을 쉽게 활용하고 있습니다. 후에 Kharon에 대해 자세히 다뤄보도록 하겠습니다.정리¶비트윈 개발팀에서는 오랫동안 유지되는 수많은 채팅 서버 연결들을 처리하고 클라이언트와 서버 간 프로토콜을 단순화시키는 등 여러 이점을 얻고자 ELB의 역할을 대신하는 프레젠터를 만들었습니다. 프레젠터를 만드는 과정에서 여러 기술적 문제가 있었습니다. 이를 해결하기 위해 C++로 연결 유지 모듈을 따로 작성하였고 Multiplexing Protocol을 따로 정의하였으며 그 외 여러 가지 기술적인 결정들을 하였습니다. 이런 과정에서 시행착오들이 있었지만 이를 발판 삼아 더 좋은 기술적 결정을 내리기 위해 고민하여 결국 기존 시스템에 쉽게 적용할 수 있고 쉽게 동작하는 프레젠터를 만들어 이용하고 있습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!

데일리의 Java 백엔드 개발자는 Docker 기반의 CodeShip Pro를 애용하는데 최근에 빌드가 급격히 느려지는 문제를 겪었다. 빌드가 느려진 원인은 다양하지만 그 중 일부는 CodeShip Pro의 캐싱 방식, 더 정확히는 도커의 캐싱 방식과 관련이 있다.CodeShip Pro는 pom.xml 또는 build.gradle 을 보고 빌드에 필요한 라이브러리를 미리 가져와서 캐싱하기를 권장한다.# We're using the official Maven 3 image from the Docker Hub (https://hub.docker.com/_/maven/). # Take a look at the available versions so you can specify the Java version you want to use. FROM maven:3 # INSTALL any further tools you need here so they are cached in the docker build WORKDIR /app # Copy the pom.xml into the image to install all dependencies COPY pom.xml ./ # Run install task so all necessary dependencies are downloaded and cached in # the Docker image. We're running through the whole process but disable # testing and make sure the command doesn't fail. RUN mvn install clean --fail-never -B -DfailIfNoTests=false # Copy the whole repository into the image COPY . ./예전에는 이 방식이 문제가 안 됐는데 최근 들어 캐시 적중률이 급격히 낮아졌다. 여러 애플리케이션이 공유하는 라이브러리를 몇 개 추가했는데 그 중 하나가 빈번히 업데이트되는 게 문제다. pom.xml 파일을 자주 수정하는데 그 말인즉 COPY pom.xml ./ 줄부터 다시 빌드해야 한다는 뜻이다. 그러므로 RUN mvn install clean --fail-never -B -DfailIfNoTests=false 을 실행하는 횟수가 많고 평균 빌드시간이 장난 아니게 늘어난다.CodeShip Pro에서 이 문제를 해결하는 방법은 비교적 간단하다. pom.xml 파일을 둘로 쪼개면 된다. 자주 수정하는 `pom.xml` 파일부터 빌드하면 빌드 시간을 종전처럼 끌어내릴 수 있다.COPY pom-not-frequently-changed.xml ./ RUN mvn -f=pom-not-frequently-changed.xml install clean --fail-never -B -DfailIfNoTests=falseCOPY pom.xml ./ RUN mvn install clean --fail-never -B -DfailIfNoTests=false하지만 CodeShip Pro가 이와 유사한 문제로 여러 번 문제가 된 터라 Travis-CI로 옮기면 어떤 장단점이 있는지 확인해보았다.장점Travis-CI는 커밋과 푸시를 한 해당 브랜치 뿐 아니라 머징할 브랜치 등에서도 빌드를 돌린다.CodeShip보다 캐싱 정책을 수립하기 쉽다.캐시 적중률 문제가 덜하므로 빌드 시간이 좀더 안정적으로 유지된다.현재 머신 사양으로는 약 1분 가량 빌드가 빠르다.빌드 과정을 한 눈에 이해하기 쉽다.Cron 빌드를 지원한다. 시간이 지나면서 의존성 문제 등으로 빌드가 깨졌을 때 조기에 조치할 수 있다.단점Travis-CI는 로컬에서 CI 환경과 동일한 빌드환경을 제공하지 않는다..travis.yml 파일을 수정하고 테스트하려면 git push 를 반복해야 한다.테스트를 돌리는 리눅스 환경과 실제 서버가 작동하는 도커 리눅스 환경이 같지 않다.돈으로 더 좋은 머신을 도입할 수 없다.빌드 환경을 이전하기는 그리 어렵지 않다. 하지만 장단점이 명확하다 보니 어느 게 꼭 좋다 말하기 힘들다. 상황에 따라 결정하는 수밖에.#데일리 #데일리호텔 #개발 #개발자 #개발도구 #도입후기 #일지 #인사이트 #조언