스토리 홈

인터뷰

피드

뉴스

조회수 3463

Good Developer 1 | 좋은 개발자의 5가지 기준

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

2016, 개발자의 Life.. 꿈...#1

주변 개발자들의 삶이 매우 행복을 추구하는 삶으로 변해가고 있다는 것을 느낀다. 주변의 개발자들의 모습을 몇 가지 정리해보자. 이를 '지속 개발을 위한 개발자 Life 스타일'이라고 정의하겠다.개발자#A10년 넘게 개발하던 패키지를 기반으로 필요 기능을 최소화하여 1인 개발기업에 성공하였고 제주도로 내려가서 지역에 속한 분들과 호흡하는 삶을 추구하면서도 소프트웨어 개발의 핵심을 잃지 않았다. 정말, MVP 기능에 최대한 집중하면서 필요한 시장 영역을 더 확대하지 않고, 소프트웨어를 개발하고 있는 개발자와 해당 소프트웨어를 사용하는 고객과 시장에 대해서 같이 합리적으로 지속할 수 있는 지속할 수 있는 소프트웨어 개발의 삶을 이루었다.그리고, 그러한 Life환경을 주변에 전파하면서 불과 얼마 전 또 한 명의 구 루급 개발자에게 비슷한 삶의 길을 가르쳐준다. 정말 부러운 개발자들...개발자#B복잡한 업무나 더 많은 보수를 위해서 더 좋은 회사를 찾기보다는 삶이 존재하는 근무시간을 위해서 재택근무를 찾고 있다. 비용도 최대한 낮추면서 생활을 위한 회사를 찾아다니고 있다. 아무래도, 외국계 개발회사를 선택할 것 같다.개발자#C오픈소스 진형에서 인정받는 개발자이다. 본인이 원하는 오픈소스 프로젝트를 추진하는 것을 보장받고 외국계 기업의 원격근무를 선택했다. 보수도 나쁘지 않고, 근무시간은 알아서 하는 것이지만, 원격으로 일하는 것이기 때문에 '능력'을 보여주기 위해 더 많은 시간을 소프트웨어 개발에 투자한다. 굳이, 서울 시내에 있을 필요가 없기 때문에 외각으로 집도 옮겼다.개발자#D일부러, 실리콘 벨리의 스타트업을 선택했다. 조만간 상장 예정인데 매우 큰 혜택을 받을 것 같다. 그 역시 지속 개발이 가능한 삶을 추구한다.2016년 올 초의 개발자 트렌드는 '지속 개발을 위한 Life'를 지향하는 개발자들이 늘어났다고 평가해본다.우리 모두 지속개발이 가능한 삶을 지향해 보는 것은 어떨까나...
조회수 2972

야놀자 기술 블로그 만들기

Hello world!저는 CX서비스실에서 기획을 담당하고 있는 강미경입니다. R&D 그룹의 기술 블로그, 그 영광의 첫 포스트로 개발의 보람을 대신할 수 있어 기쁩니다. 오늘은 ‘기획자가 어쩌다가’ 기술 블로그를 만들게 되었는지 얘기해보려고 합니다.왜 기술 블로그인가제가 야놀자에 입사한 지 만 1년이 되었습니다. 입사하면서 가진 개인적인 목표 중의 하나는 블로그를 운영하는 것이었습니다. 저는 오래전부터 개인 블로그를 운영하고 있고, 외부 커뮤니티 활동에서도 팀 블로그를 운영합니다. 그래서 개발자에게는 기술 블로그에 쓸 글을 작성하는 것보다 코딩을 하는 게 더 쉬울 정도로, 글 쓰는 고통이 남다르다는 것도 알고 있지요.하지만 ‘알고 있다’고 생각하는 정보를 정리하고 그것이 잘 전달될 수 있도록 하는 것은 개발실력과는 약간은 다른 영역의 것이기도 합니다. 그래서 테크 스웩이 넘치는 블로그가 아니더라도, 꾸준히 스토리를 전달하면 그게 개인과 조직의 히스토리로써의 가치가 충분하다고 생각했습니다. 무엇보다 조직 자체의 성장에 큰 밑거름이 되고요.블로그를 시작해보자기술 블로그를 하자는 말에, 놀랍게도 한결같이 ‘관심만’ 주더군요(…) 평소 업무가 많고 바쁨을 떠나서, 보람보단 책임만 남아 유지보수 대상이 되어버릴 가능성이 무궁하지 않겠습니까. 하지만 목마른 사람이 우물을 파라고, 개발자의 도움 없이 블로그를 만들 각오를 하기에 이르렀습니다.(과거의 나를 규탄…#야놀자 #개발팀 #블로그 #인사이트 #경험공유
조회수 782

[Buzzvil People] Alan Kim, Senior Software Engineer

 Buzzvil People에서는 다양한 배경과 성격 그리고 생각을 지닌 버즈빌리언들을 한 분 한 분 소개하는 시간을 갖습니다. 어떻게 버즈빌에 최고의 동료들이 모여 최고의 팀을 만들어가고 있는 지 궁금하시다면, 색색깔 다양한 버즈빌리언들 한분 한분의 이야기가 궁금하시다면, Buzzvil People을 주목해주세요.1. 간단한 자기 소개 부탁드립니다. 안녕하세요. 김진언입니다. 영어 이름은 Alan Kim 이고, 현재 버즈빌에서 클라이언트 팀의 리더를 맡고 있습니다. 저는 2002년에 병역 특례로 IT업계에서 근무를 시작했고, 첫 직장에서는 연구소 장비들에 들어가는 소프트웨어 개발을 하다가 그 뒤로 모바일 게임 포팅, 게임 서버 개발 등 지금까지 14년 동안 여러 회사에서 여러가지 업무를 해 왔습니다. 소프트웨어를 만드는 능력이 뛰어난 분들은 워낙 많기 때문에  A급 개발자라고 소개할 수는 없겠지만(^^) 컴파일러 관련 시스템 개발이나 게임, 네비게이션 시스템 등 꼭 APP개발에 국한되지 않은 다양한 경험을 해 왔기 때문에 그런 장점을 살릴 수 있는 부분에서는 나름대로 역할을 하고 있다고 생각합니다.  저는 예전부터 개발자로서 여러가지 경험을 하는 것을 중시해 왔는데요. 그러다보니 임베디드 시스템부터 게임, 게임 서버, PC 툴이나 스마트폰 관련 개발까지 다양한 분야의 경험을 쌓아올 수 있었습니다. 그런데 요즘에는 다양한 경험을 하는 것보다 어떤 개발을 하든지 간에 지켜나가야 하는 기준을 세우는 것이 중요하다는 생각을 많이 하고 있습니다. 그러다 보니 코드 자체 보다는 코드를 작성하는 방식에 대한 고민들을 많이 하게 되는 데요. 최근에는 ‘클린 코드’에 대해 많이 관심을 가지고 있습니다. 요즘에는 과거에 비해 Computing resource나 컴파일러 최적화 등이 눈에 띄게 발전해왔습니다. 따라서 무조건 효율좋은 코드를 짜기보다는 조금 효율은 부족하더라도 Readability가 잘 갖추어진 코드를 짜는게 중요하다는 생각을 하게 되었고 클린코드를 위해 고민해야 하는 모듈화 방법이나 디자인 패턴에 대해서 여러가지로 고민 중입니다. 실제로 저희 팀을 운영할때도 굉장히 강조하고 있는 부분이기도 합니다. 개발 이외의 성격적인 부분으로는 평소에 말수가 적어서 종종 과묵한 사람이라 오해받고는 하는데요. 표현력이 서툴러 말수가 적을 뿐, 다른 분들을 싫어하는 게 아니니 오해하지 않으셨으면 좋겠습니다. ^^  2. 어떻게 버즈빌에 오시게 되셨나요? 버즈빌과의 인연을 설명하려면 먼저 Jay와 슬라이드 조이라는 미국 회사를 말씀 드려야 하는데요. Jay는 인포뱅크라는 회사에서 처음 인연이 시작된 동료인데, Jay가 스타트업을 창업한 후 1년쯤 지난 시점에 저에게 연락이 와서, 같이 일해보자는 제안을 했고 그렇게 슬라이드 조이에 조인했습니다.  그 당시에 저는 인프라웨어라는 회사에서 게임 서버를 개발하고 있었는데요. Jay가 권유했던 그 시기가 마침  진행했던 프로젝트가 완료된 시점이었고, 개발자로서 이런 저런 고민을 하던 시기였습니다. 내가 개발하고 싶은 것, 배워보고 싶은 것, 도전해보고 싶은 것과 같은 부분을 현 회사에서 충족할 수 있느냐에 대한 갈등이 심했던 때 였죠. 원래 저는 직장을 선택함에 있어서 제가 정말 하고 싶은 일인지와 리스크가 크더라도 그 결과를 구성원이 함께 공유할 수 있는 구조를 가지고 있는지를 많이 고민했었는데요. 결혼을 하게 되면서 자연스레 조금 더 안정적인 직장을 찾고 싶어서 들어가게 된 곳이 인프라웨어라는 회사였습니다. 하지만 그곳에서 1년간 문제 없이 일하다보니 안정적인 점은 좋았지만 제 의견이 반영되기 힘들다는 점과 개발과정에서 소통이 중시되지 않는다는 점이 저와는 맞지 않는 부분이라고 생각하고 있었습니다. 그렇기 때문에 좋은 타이밍에 연락이 왔다 생각하여 큰 고민 없이 자연스럽게 합류하게 된 것 같습니다. 물론 미래가 불확실 할 수 있는 스타트업으로 가는 것에 대해서 가족들도 염려했지만 당시 슬라이드 조이를 이루고 있던 멤버들이 정말 훌륭하고 의견들도 잘 맞았기 때문에 슬라이드 조이로의 합류를 결정하게 되었던 것 같습니다. 그 후, 여러가지 우여곡절이 있었지만, 슬라이드 조이도 상당한 성장을 이루었고 마침 좋은 기회로 버즈빌과 합병이 되면서 지금은 버즈빌에서 클라이언트 개발팀의 리더로 근무하게 되었습니다. 3. 버즈빌에서 어떤 업무를 담당하고 계신가요? 현재 클라이언트 팀의 리더를 맡고 있지만, 슬라이드조이에서는 백엔드를 전담했었고 버즈빌에서 근무를 시작할 시점에는 광고 서버쪽을 다뤘기 때문에 아직도 약간의 서버쪽 업무를 병행해 가면서 일하고 있습니다. 차츰 앱 서버를 포함한 백엔드쪽 업무를 줄이고, 클라이언트 팀 리더로서의 업무에 주력하기 위해 일부 업무를 서버 팀 개발자에게 옮기고 있습니다. 버즈빌 클라이언트 팀의 업무가 일반적인 클라이언트 개발과 다른 점이 있다면 단순히 하나의 앱을 개발하는 것이 아니라 stable 한 SDK를 개발해야 한다는 점입니다. 여러 버즈스크린 파트너들의 다양한 개발환경에서 동작되어야 하고, 어떤 상황에서든 항상 동작되어야 하기 때문에 시스템 전반에 걸친 깊은 이해가  이 필요한 일입니다. 때문에 단순히 소프트웨어 개발자 보다는 깊이 연구하고 세밀하게 설계하는 능력을 가진 사람이 필요하고 현재 클라이언트 팀의 경우 그런 사람들로 구성이 되어있다고 생각합니다.   클라이언트 팀의 리더가 되면서 아무래도 개발 자체보다는 팀원들이 개발을 잘 할 수 있도록 하는 환경들에대해 더 많은 고민을 하고 관련 업무들을 하고 있습니다. CI(Continuous Integration)나 개발 프로세스 등 흔히 말하는 DevOps에 관련된 일들을 하고 있습니다. 뿐만 아니라 구현 방식에 대한 최종적인 방향을 결정하는 의사결정이나 개발 과제가 내려오는 과정과 개발이 완료된 과제들에 대해 외부의 팀과 커뮤니케이션이 필요한 사항들을 맡아서 관리하고 있습니다. 4. 스타트업에서 혹은 광고업계에서 일하는 느낌이 어떠세요? 스타트업은 한 사람, 한 사람의 목소리가 회사의 성장에 직접적으로 영향을 줄 수 있다는 점이 큰 매력이라고 생각합니다. 저의 경우에는 게임 서버 개발(수천명 규모), 자동차 관련 TF팀(수백명 규모), 스타트업 두 곳, 또 다른 게임회사(60명 규모) 등 많은 케이스의 회사에서 근무를 해 왔기 때문에 큰 차이를 직접적으로 느낄 수 있었는데요. 저에게 스타트업이란 “회사의 성장에 직접적으로 기여할 수 있는 곳” 입니다. 대부분의 회사는 규모가 커짐에 따라 어쩔 수 없이 여러가지 체계가 도입되고, 문화적으로도 경직화 되는것 같아요. 사원 개인이 회사의 의사 결정에 참여 하기는 정말 어렵고, 위로부터 내려온 결정 사항에 자신의 동의 여부와 관계 없이 일이 하는 경우가 대부분입니다. 개인의 개성은 최소화하고 회사라는 체계의 한 부품으로만 움직이게 되고요. 동기부여 없이 그에 따른 무의미한 업무가 반복되면 회사 생활이 정말 재미 없게 되는 거 같습니다. 예를 들어, 특정 Feature를 개발 함에 있어서도 왜 이 Feature에 대한 개발이 필요한지, 어떤 맥락에서 이 Feature의 구현이 중요한지에 대한 커뮤니케이션 없이 그저 과제만 주어지는 경우는 해당 업무에 대한 흥미를 떨어뜨린다고 생각합니다. 하지만 스타트업의 특성상 다른 팀과의 의사소통이 활발하게 진행될 수 있는 환경이다 보니 같은 일을 하더라도 좀 더 큰 맥락에서 파악하고 내가 하는 일에 대한 의미와 기대효과를 고민해보면서 일 할 수 있다는 것이 장점이라는 생각이 드네요. 5. 이것만큼은 버즈빌이 참 좋다! 어떤 게 있으실까요?  아마 많은 분들도 공감하시겠지만, 회사 일이란 게 혼자 하는 게 아니니만큼 같이 일하는 직원이 어떤 사람이냐에 따라서 자신의 업무에도 영향을 받게 되죠. 일에 대한 열정도 없고, 월급 생각하며 대충 일하는 직원과 같이 일하게 되면 다른 팀원들도 영향을 받게 됩니다. 안 좋은 케이스의 일을 몇 번 겪고 나니 일 할 때는 같이 일하는 사람이 어떤 사람인지에 대해 촉각을 많이 세우게 되었죠. 그런데 제가 지금 버즈빌에 근무한 지 1년 반이 넘은 것 같은데, 처음 입사할 때나 지금이나 여전히 느끼는 점은 버즈빌에는 ‘능력자들’이 정말 많다는 점입니다. 보통 회사에서는 10명 중 1명 있을까 말까 할 정도로 특출난 인재들이 한 곳에 모여있다는 그 부분이 정말 인상적이었어요. 스펙도 스펙이지만 보통 사회 초년생이라 일컫는 어린 나이 임에도 일에 대한 진지한 태도와 전문성, 빠른 일 처리 속도 등 대부분의 직원들이 ‘능력자’라 부르기에 손색이 없을 정도입니다. 그런 직원들과 매일 생활하니 저 또한 분발해야겠다는 생각과 함께 많은 의욕을 얻고 있어요.   또한 개발자로서 느끼는 버즈빌은 제가 일했었던 다른 회사들과 극명하게 차이가 있는 곳이라는 생각이 듭니다. 회사가 평등한 문화를 가지고 있다고 PR을 하는 경우가 많은데 버즈빌 만큼 실제로도 수평적인 문화를 가진 회사는 처음입니다. 개발에 관련된 여러가지 의사결정을 함에 있어서도 서로의 의견을 존중하고 워낙 뛰어난 사람들이 많다보니 서로에게 많은 것들을 배울 수 있는게 좋습니다. 저도 팀장이지만 팀원들에게 여러가지를 물어볼 때도 많고 팀원들 통해 새롭게 배우는 것들도 많구요. 이렇게 뛰어난 사람들도 많이 있고 이런 사람들 간에 서로에게 시너지를 줄 수 있는 좋은 문화를 가지고 있다는 점은 분명 다른 회사에서 찾아보기 힘든 장점이라고 생각합니다. 저는 합병을 통해 입사했기 때문에, 버즈빌이라는 회사에 기대를 많이 하고 합류하게 되었는데요. 그 점에 있어서는 200% 이상 충족되었다고 생각합니다. 구성원 한 사람 한 사람을 믿고 자신의 업무에 집중할 수 있다는 것은 저에게 있어 매우 중요한 의미이기 때문에, 현재 회사 생활이 무척 만족스럽네요. 6. 개인적인 목표나 꿈이 있으신가요? 있다면, 버즈빌에서의 경험이 어떻게 도움이 된다고 생각하시나요? 먼 미래에 대한 목표는 ‘돈 걱정 없는 편안한 노후’고요.(^^)  사실 이런 목표를 늘 생각하면서 살고 있진 않습니다. 미래보다는 현재가 중요하고 단기적인 목표에 최선을 다하는 것에 보람을 느끼는 편입니다. 당장 생각나는 목표는…혼자만의 여행일까요? 예전부터 같은 일상에 지치거나 슬럼프가 올때면 한번씩 여행을 가서 충분히 쉬고 생각도 정리하는 시간을 가졌었는데요. 버즈빌에는 다양한 국적의 직원들이 많다보니 그들의 성장환경과 문화 이야기를 들으면 저도 당장 떠나고 싶은 기분이 들 때가 있어요.  가정이 있다보니 혼자 여행을 가는게 쉽지만은 않고 지난 3월에 회사 워크샵으로 발리를 다녀 온 이후로 더욱 눈치가 보이기는 하지만, 몽골에 배낭여행을 가는게 너무 하고 싶네요. 그리고… 생각만 하고 실천을 잘 못하고 있는 부분이 있는데, ‘영어권 나라로의 이민’을 위해 기반을 마련하는 것 입니다. 영어권 나라들의 경우 대부분이 한국에 비해서 삶의 방식이 자유롭고 틀에 박힌 부분이 적다는 생각이 들더라구요. 제가 느끼기엔 아직까지 우리나라가 여유가 없고 바쁜 느낌이 강하게 들어서 좀더 여유로운 환경에서 생활해 보고 싶다는 꿈이 있습니다. 무엇보다 영어가 중요할텐데, 버즈빌에서는 많은 의사 소통을 영어로 하고 있다보니 생각해 보면 엄청 좋은 기회이지만, 아직까지 영어 사용을 적극적으로 하지 않고 있어서 다시 한번 마음을 다 잡고 시작해 봐야겠습니다.
조회수 10492

Next.js 튜토리얼 7편: 데이터 가져오기

* 이 글은 Next.js의 공식 튜토리얼을 번역한 글입니다.** 오역 및 오탈자가 있을 수 있습니다. 발견하시면 제보해주세요!목차1편: 시작하기 2편: 페이지 이동 3편: 공유 컴포넌트4편: 동적 페이지 5편: 라우트 마스킹6편: 서버 사이드 7편: 데이터 가져오기 - 현재 글8편: 컴포넌트 스타일링9편: 배포하기개요꽤 그럴듯한 Next.js 애플리케이션을 만드는 방법과 Next.js 라우팅 API의 모든 장점을 배웠습니다.대부분의 경우 데이터 소스에서  원격으로 데이터를 가져와야 합니다. Next.js는 페이지에 데이터를 가져오기 위한 표준 API를 제공합니다. getInitialProps라 불리는 비동기 함수를 사용하여 구현할 것입니다.주어진 페이지에 원격 데이터 소스를 통해 데이터를 가져오고 원하는 페이지에 props을 통해 전달할 수 있습니다. 서버와 클라이언트 둘 다 동작하도록 getInitialProps를 작성할 수 있습니다. 그래서 Next.js는 클라이언트와 서버에서 모두 사용할 수 있습니다. 이번 편에서는 getInitialProps를 사용하여 공개된 TVmaze API에서 가져온 데이터로 배트맨 TV 쇼에 대한 정보를 보여주는 애플리케이션을 구현할 예정입니다.설치이번 장에서는 간단한 Next.js 애플리케이션이 필요합니다. 다음의 샘플 애플리케이션을 다운받아주세요:아래의 명령어로 실행시킬 수 있습니다:이제 http://localhost:3000로 이동하여 애플리케이션에 접근할 수 있습니다.배트맨 쇼 데이터 가져오기데모 애플리케이션 내의 home 페이지에 블로그 포스트 목록이 있습니다. 배트맨 TV 쇼 목록을 표시할 것입니다.쇼의 데이터들을 하드코딩하는 대신에 원격 서버에서 그 정보를 가져옵시다.여기서는 TV 쇼를 가져오기 위해 TVMaze API를 사용합니다.TV 쇼 정보를 검색하는 API 입니다.먼저 isomorphic-unfetch를 설치해야 합니다. 데이터를 가져올 때 사용할 라이브러리입니다. 브라우저 fetch API 구현을 간단히 할 수 있도록 만들어진 것이지만 클라이언트와 서버 환경에서 모두 동작합니다.npm install --save isomorphic-unfetchpages/index.js를 다음과 같이 변경해주세요:위의 페이지에 있는 모든 내용은 아래에 표시된 Index.getInitialProps를 제외하고는 익숙할 것입니다:애플리케이션의 어떤 페이지에든 추가할 수 있는 정적 비동기 함수입니다. 이것을 사용하여 데이터를 가져오고 가져온 데이터를 props를 통해 페이지로 보낼 수 있습니다.보다시피 배트맨 TV 쇼 데이터를 가져오고 'shows' props를 통해 페이지로 전달합니다.위에서 보았던 getInitialProps 함수에서 가져온 데이터 숫자를 콘솔에 출력합니다.이제 브라우저 콘솔과 서버 콘솔을 살펴봅시다. 그리고 페이지를 새로고침 해주세요.페이지를 새로고침 한 후 출력되는 메시지는 어디에서 보였나요?- 서버 콘솔- 브라우저 콘솔- 둘 다- 어떤 콘솔에도 출력되지 않았다서버에서만 출력됩니다이 경우 메시지는 서버에서만 출력됩니다.이는 서버에서 페이지가 랜더링되기 때문입니다.이미 데이터를 가지고 있어 클라이언트에서 다시 정보를 가져올 필요가 없습니다.post 페이지 구현하기TV 쇼에 대한 자세한 정보를 보여주는 "/post" 페이지를 구현해봅시다.먼저 server.js를 열고 /p/:id 라우트를 다음과 같이 바꿔주세요.위처럼 바꾼 코드를 적용하기 위해 애플리케이션을 재실행시켜주세요.이전에는 title 쿼리 파라미터를 페이지에 매핑했습니다. 이제 id로 이름을 바꿔야합니다.다음과 같은 내용으로 pages/post.js를 변경해주세요.페이지의 getInitialProps을 살펴봅시다:여기에서 함수의 첫 번째 파라미터는 context 객체입니다. 정보를 가져올 때 사용할 수 있는 쿼리 필드를 가지고 있습니다.예제에서 쿼리 파라미터로부터 보여지는 ID를 선택하고 TVMaze API로부터 데이터를 가져옵니다.이 getInitialProps 함수에서 표시할 제목을 출력하는 console.log를 추가했습니다. 이제 어디에서 출력되는지 볼 수 있습니다.서버와 클라이언트의 콘솔를 둘 다 열어주세요.그 다음 홈페이지 http://localhost:3000로 이동하여 배트맨 쇼 제목을 클릭하세요.위에서 애기했던 console.log 메시지가 보여지는 장소는 어디인가요?- 서버 콘솔- 브라우저 콘솔- 콘솔 둘 다- 아무 콘솔에서도 출력되지 않는다클라이언트 사이드에서 데이터 가져오기브라우저 콘솔에서 메시지를 볼 수 있습니다.클라이언트 사이드를 통해 포스트 페이지에 이동했기 때문입니다. 그런 다음 클라이언트 사이드로부터 데이터를 가져오는 것은 가장 좋은 방법입니다.예를 들어 http://localhost:3000/p/975에 직접 이동한다면 클라이언트가 아닌 서버에서 메시지가 출력되는 것을 볼 수 있습니다.마무리데이터를 가져오고 서버 사이드에서 렌더링하도록 만드는 Next.js의 가장 중요한 기능 중 하나를 배웠습니다.대부분의 유스 케이스에서 충분히 사용할 수 있는 getInitialProps의 기본을 배웠습니다. 더 많은 것을 배우고 싶다면 Next.js의 문서 중 data fetching 문서를 참고할 수 있습니다.#트레바리 #개발자 #안드로이드 #앱개발 #Next.js #백엔드 #인사이트 #경험공유
조회수 1558

AWS X-Ray를 이용한 분산 애플리케이션 분석

OverviewMSA(Micro Service Architecture)를 구축하다 보면 분산 애플리케이션에 대한 분석, 디버깅, 모니터링이 어려울 때가 있습니다. 이 문제를 풀기 위해 AWS에서는 X-Ray라는 분산 추적 시스템을 제공하고 있는데요. X-Rray는 요청이 애플리케이션들을 통과하는 전체 과정을 추적합니다. 오늘은 Lambda에서 X-Rray를 사용하는 방법을 간단하게 살펴보겠습니다. lambda debuggingAWS Lambda 콘솔 > 함수선택 > Configuration > Debugging and error handling > Enable active tracing 을 선택합니다.AWS X-Ray 서비스맵Lambda에서 Enable active tracing만 선택해도 Lambda 서비스용 노드와 Lambda 함수용 노드를 확인할 수 있습니다.Lambda SDK를 추가해 하위 세그먼트를 구성하고, 주석 및 메타 데이터를 포함시키는 등의 작업을 할 수 있습니다. 이번 글에서는 Python SDK를 이용해 샘플을 만들어 보겠습니다. 우선, pip로 aws-xray-sdk를 설치합니다.SDK 패치X-Ray에서 지원하는 라이브러리를 패치해 SDK가 하위 세그먼트를 생성하고 레코딩할 수 있도록 합니다. 그 다음 patch_all 함수를 사용해 지원되는 모든 라이브러리를 패치합니다. (patch 함수로는 특정 라이브러리만 패치할 수 있습니다.)X-Ray 지원 라이브러리 (18.07.10 현재) botocore, boto3, pynamodb, aiobotocore, aioboto3, requests, aiohttp, httplib, http.client, sqlite3, mysql-connector-python subsegment 생성 및 metadata 작성subsegmentxray_recorder.begin_subsegment/end_subsegment 메서드를 사용해 하위 세그먼트를 구성할 수 있고, @xray_recorder.capture 데코레이터를 사용해 함수에 대한 하위 세그먼트를 생성할 수 있습니다.annotation, metadataput_annotation을 사용해 주석을 기록할 수 있고 put_metadata를 사용해 메타데이터를 기록할 수 있습니다. 1) Service mapTrace timelineSegment annotationSegment metadata서비스 맵을 통해 요청에 대한 노드 연결을 시각화해서 확인할 수 있습니다. 간단한 방법으로 서비스 오류, 병목, 지연 등 애플리케이션의 여러 문제를 식별할 수 있습니다. Service map errorTrace timeline errorSegment Exceptions서비스 맵과 타임라인을 이용하면 동기/비동기 요청, 서비스별 상태 및 오류 내용까지 확인할 수 있습니다. Service mapTrace timeline지금까지 분산 애플리케이션 환경에서 사용하는 AWS X-Ray의 기본 기능들을 실행했습니다. 기본적인 기능들만 살펴봤는데도 AWS 플랫폼의 분산 어플리케이션 환경에서 요청 추적 및 검토, 문제식별, 성능개선 등을 유용하게 활용할 수 있다는 걸 알 수 있었습니다. 추가적인 설명은 아래 참고의 링크들을 확인해주세요. 1) 어노테이션 데이터는 검색용으로 인덱싱되고 메타데이터는 검색에 사용할 수 없습니다. 참고AWS X-Ray – 분산 추적 시스템AWS X-Ray SDK for Python - AWS X-Ray글이상근 팀장 | R&D 개발1팀[email protected]#브랜디 #개발자 #개발팀 #인사이트 #경험공유
조회수 1415

대시보드 만들다 문득,

 고수의 프레젠테이션은 늘 심플하다. 읽기 좋은 보고서는 한 페이지로 요약된다. 가진 정보가 많다는 건 좋은 일이지만 때론 감당할 수 없는 양에 압도 당하고 교란 당한다. 정보는 권력이 된다. 그것의 불균형은 누군가에겐 돈을 벌어다 주고 누군가에겐 좋은 일자리를 준다. 정보가 있는 곳엔 그래서 늘 사람과 힘이 몰린다. 하여, 정보제공자에겐 막중한 책임역시 따라야 한다 생각한다. 제공할 정보가 사실에 기반해야 하는 건 물론이고 더 중요한 건 진정 필요한 콤팩트(compact)한 정보만을 제공해야 한다는 것이다. 현재진행형인 대시보드(dashboard) 프로젝트 과정에서 위와 같은 생각이 들었다. 그러면, 주관과 사욕을 완전히 배제하고, 내가 드러내고 보여주고 싶은 정보가 아니라 최대한 많은 이에게 가치롭게 활용되는 정보는 어떤 형태여야 할까? 스스로 답을 내렸다.  우선 사람별, 상황별로 다른 관점과 해석이 양립할 수 없는 요소로 구성돼야 하고, 전달과정에서 요구되는 추가적 배경지식은 불필요해야 하며 필요하다면 극히 적은 양이어야 한다. 무엇보다 관련된 이는 누구나 궁금해 해야 할 것이어야 하고 부차적인 것을 제외한 본질만을 담고 있어야 한다. 이 같은 정보를 핵심정보라고 정의하면 핵심정보는 각각의 업이 가진 '본질적 성장 방정식(fundmetal growth equation)'과 연관이 깊다. 본질적 성장 방정식이란 현 시점에서 비즈니스의 성장을 추진하는 모든 핵심요소, 즉 핵심적인 성장 지렛대를 표현한 간단한 공식을 뜻한다. 제아무리 시가총액 1조를 넘은 기업일지라도 그들의 성장공식을 대여섯 가지의 핵심요소로 도식화하는 것은 가능하며 그것은 제품, 서비스가 가진 성격별로 달라진다. 본질적 성장 방정식을 <진화된 마케팅 그로스 해킹>이란 책에서 나온 사례를 인용해 예시를 들면 아래와 같다.# 이베이의 방정식{아이템을 등록한 판매자의 수}x{등록된 아이템의 수}x{구매자의 수}x{성공적인 거래의 수}=총 매출 성장# 어느 온라인 뉴스사이트의 방정식{웹사이트 트래픽}x{이메일 전환율}x{활성 사용자 비율}x{유료구독으로의 전환율}+다시 찾은 구독자 =총 구독자 매출 성장 이베이의 방정식을 보면 트래픽 양보다는, 거래량을 일정수준 이상 유지하는 것이 성장에 있어 더 중요한 미션일 것이다. 그래서 신규 셀러와 동시에 판매 아이템에 대한 공급이 지속적으로 원활히 이뤄져야만 한다. 아울러 매일, 매주 등록되는 아이템 개수와 그것의 품질, 카테고리 같은 것도 광장히 중요한 관리요소 중 하나일 것이다. 한편, 어느 온라인 뉴스사이트의 경우 트래픽의 양은 광고매출과 직결되고 신규 독자 확보의 가능성을 높여주는 성과의 선행지표다. 뉴스레터 이메일은 수신자를 이후 결제 - 유료구독 -할 확률이 높은 활성 사용자로 전환시키는 데 주력할 것이다. 그래서 사이트를 드나드는 빈도가 높은 활성 사용자층을 얼마나 두껍게 유지하느냐는 온라인 뉴스 비즈니스에서 관건 중 하나일 것이다.  참고: https://www.youtube.com/watch?v=PvSW0ri7AEg기본적인 매출 성장 방정식을 소개하는 강의 동영상이 있어 첨부한다 이처럼 본질적 성장 방정식을 구성하는 요소를 해부해보면 어떤 정보가 현 시점에 우리의 비즈니스를 이끄는 핵심정보이고, 비교적 불필요한 정보인지, 잘 드러난다. 또한, 생각한 것보다 관리해야 할, 혹은 제공해야 할 정보가 적다는 것에 놀란다 - 개인적으론 충격이었다.  페이스북 광고 관리자 페이지에서 관찰할 수 있는 데이터 필드 수는 맞춤설정 활용 시 약 300개까지 지원된다. 그들 중 절반은 서비스와 관련성이 적거나 매일 추적한다 해도 당장의 마케팅 관련 의사결정에 도움을 주지 못하는 것이 대부분일 수 있다. 구글애널리틱스에서 제공하는 지표 또한 마찬가지다. 이탈률을 체크하는 것이 중요하다고들 하지만, 서비스의 태생적 특성 상, 신규 사용자 유치를 위해 지속적이고 공격적인 온라인 광고가 불가피하다면? 때론 업계 평균보다 높은 이탈률이 당연한 것이고 그것이 가진 시사점은 적을 수도 있다. 단지 '쿨'해 보이는 지표를 관찰할 게 아니라 각각의 비즈니스 '실정'에 맞는 성장 방정식을 꾸리고 그것을 지켜 보는 게 중요하단 말이다. 결론적으로 다시 대시보드 이야기로 돌아가면, 정보판으로써 구실하기 위한 최소요건으로 대시보드에는 성장 방정식을 이루는 구성요소만 들어있으면 된다. 그것들이 최소요건이자 거의 대부분이다. 그 외 정보는 실제로는 불필요하거나 수요가 낮은 정보일 가능성이 높다. 물론 그런 정보는 필요에 따라 '드릴 다운' 방식으로 제공하는 것도 좋겠다. 하지만 당장의 우선순위는 아니란 것이다. 대시보드의 첫인상은 고수의 피티처럼 심플하고, 잘 짜여진 보고서 앞 한 장 요약본처럼 말하는 바가 적확해야 한다.블랭크 코퍼레이션의 CI내밀한 이야기가 될 수 있는데, 대시보드 프로젝트를 진행하며 자사 비즈니스의 본질적 성장 방정식은 어떻게 생겼을까, 혼자 그려봤다. 디지털 마케팅  중심적 사고이기 때문에 주관적이며 생각차는 있을 수 있다. 그리고 미래의 가변적 환경을 반영하지 않았다. 어차피 대시보드에선 미래를 projection하지 않기 때문이다.# (현 시점 기준) blank의 방정식{상품기획력}x{콘텐츠 파워}x{SNS 광고비}x{광고유입후 0일-1일내 구매하는 이의 비율}x{재구매율}x{고객생애가치}= 성장의 크기 방정식 안에 bold체로 표시된 요소를 살펴보자. 내가 생각하는 - 공식적인 내용이 아니다 - 우리의 모델 안에서 {SNS 광고비}는 성장(매출)의 크기를 좌우하는 핵심인자다. 광고를 통해 설득 당한 잠재고객을 단번에 구매로 이끌 수 있는 흡인력 - 앞선 방정식에선 {광고유입후 0일-1일내에 구매하는 이의 비율}로 표시했다 - 을 지속하느냐 또한 DR(direct response ; 직접 반응) 마케팅에서 관찰하고 관리해야 할 주요요소다. 이후 구매자의 {재구매율}과 {생애가치}도 이해하고 관리할 수 있다면 완벽할 것이다. 하지만 해당 지표의 정의와 계산은 마냥 쉽지 않기에 정밀한 설정 안에서 관련 정보의 해상도를 높이는 일이 요구된다. 이 정도의 정보가 현 시점에서 마케팅 유닛에서 필수적으로 관찰하고, 유관부서에 공유해야 할 핵심지표가 될 수 있을 것이다. 대시보드 상에 CTR(클릭률), CPC(클릭당비용), CPM(1,000회 노출당비용)과 같은 매일의 광고지표를 넣었다간 보는 이로 하여금 복잡성만 가중시킬 뿐이다. 전자상거래 마케팅 과정에서 오직 알아야 할 정보는 "광고비를 얼마나 효율적으로 투자해 얼마를 벌었는가"라고 생각한다. 현재 페이스북이 제공하는 구매 최적화 광고의 알고리듬 상에선 구매 수와 CPA(액션당비용, 구매당비용) 외 다른 지표들은 그때그때 알고리듬 컨디션에 따라 결정되는 후행지표이자 수단일 뿐이다 - 이 부분은 나중에 기회가 있다면 더 설명해보고 싶고 다른 이와 토의하고 싶다. 불과 얼마 전까지 - 아니면 지금까지; - 난 아마도, 엑셀 시트에 피봇테이블을 덕지덕지 붙여넣고 형형색색으로 트렌드를 표시하면 좋은 정보가 되는 줄 착각했었다. 그리고 난 데이터분석가도 아니고 고급통계지식이 풍부한 편도 아니다. 프로그래밍을 할 줄 알아 데이터 처리기술이 남다른가? 고작 엑셀 단축키와 기본 함수를 사용해 평균보단 빠르게 잔머릴 굴리는 정도다. 하지만 최근에는 시각화, 데이터분석, 고급통계지식 모두 중요한 정보를 전달하는 수단일 뿐이란 생각이 든다. 자기위로적 감상일 수 있지만, 정말로, 정보를 다루는 데 있어 그러한 스킬보다 중요한 건 진정 필요한 정보를 옥석 가리듯 가려내는 정보 분별력이라고 생각한다. 수단에 현혹돼 정작 알맹이는 없고, 누구에게도 도움되지 않는 보고서를 만드는 일이 어떤 마케터, 사업PM에게도 없었으면 하는 바람이다.(끝)Jin Young Choi회사원
조회수 4059

제니퍼5 기능 소개

JENNIFER 5의  유용한 기능을 소개해 드리는 시간. 새로운 기능을 검토해 보시고, 지금 바로 사용해 보세요. 제니퍼소프트는 제품을 사용하는 고객이 최적의 환경에서 모니터링 할 수 있도록 하는데 최고의 가치를 두고 모든 제품을 개발합니다.제니퍼(JENNIFER)는 웹 애플리케이션 (Java EE, .NET, PHP) 시스템 모니터링을 위한 APM(Application Performance Monitoring) 솔루션입니다. 제니퍼는 경량화(Light-Weight), 실시간(Real-Time), 그리고 개별 트랜잭션 모니터링(Individual Transaction Monitoring) 등 기술기반의 '직관적인 통합 성능관리 솔루션'으로 이미 국내외 1200여 개 고객사를 통해 검증된 바 있습니다.  또한, 시대의 요구 사항인 모바일, 클라우드, 그리고 빅 데이터 시장의 온전한 모니터링 체계를 위하여, 웹 서비스 사용자 모니터링 (Web Service Real-User Monitoring), 웹 서비스 중심의 토폴로지 뷰(Web Service Topology View), 클라우드(대규모 시스템) 환경을 고려한 아키텍처, HMTL 5기반의 N스크린(N-Screen)까지도  지원하는 APM 제품입니다.웹 서비스 중심 토폴로지 뷰 (Web Service Topology View)제니퍼 토폴로지 뷰(Topology View)는 기업의 웹 서비스를 중심으로 연결된 서비스에 대한 가시성(Visibility)을 확보하는 것이 핵심 기능입니다. WAS를 중심으로 연결된 서비스(DB, 외부 연계 서비스, HTTP 등) 사이에 발생하는 트랜잭션, 즉, 구간에서 처리되는 트랜잭션까지 실시간으로 모니터링 할 수 있습니다.구간 엑티브 서비스 모니터링: 구간에서 처리되고 있는 엑티브 서비스를 실시간 모니터링 하여 병목 지점과 그 원인을 분석할 수 있습니다.X-view 연계 분석: 병목 지점이 되는 구간에서 처리되는 모든 트랜잭션에 대한 분석을 할 수 있습니다.구간 실시간 모니터링: 실시간 차트를 통해 원하는 구간에 대한 모니터링이 가능합니다.웹 서비스 사용자 응답시간 모니터링(RUM)클라이언트 구현 기술의 발전과 모바일 기기의 대중화로 인해 기업의 서비스는 복잡해졌습니다. 사용자는 모바일을 통해 언제, 어디서든 기업의 서비스를 이용할 수 있게 되었고, APM은 이제 서버사이드 영역의 모니터링뿐만 아니라, 실제 사용자의 만족도를 높일 수 있는 사용자 중심의 성능 모니터링 기능을 요구하고 있습니다. 이러한 변화에 따라 제니퍼는 프런트 앤드(Front-End) 영역의 모니터링을 위한 실제 사용자 모니터링, 즉 RUM(Real User Monitoring)을 지원합니다.이 기능은 웹 표준 조직 기구인 W3C의 Timing Navigation API를 사용하여 별도의 모듈 설치 없이 브라우저에서부터 서버사이드까지 전 영역에 대한 응답시간 측정이 가능하며, 서버와 네트워크로 이어지는 애플리케이션 수행 경로를 시각적으로 표시하여 애플리케이션 성능에 대한 깊이 있는 분석이 가능합니다.제니퍼 for CLOUD최근 IT 흐름의 큰 변화 중 하나는 클라우드(대용량 시스템)입니다. 클라우드 환경의 큰 특징은 트랜잭션의 양에 따라 하드웨어의 제약을 받지 않고 필요에 따라 서버 수를 조절하며 운영할 수 있어야 한다는 것입니다. 제니퍼는 자동감지(Agent Auto Detection), 일괄 설정(Central Configuration), 일괄 배포 (Central Deployment) 기능을 통하여 클라우드 환경에서의 애플리케이션 성능 모니터링을 지원합니다.스마트 프로파일링(Smart Profiling)제니퍼의 개별 트랜잭션의 응답시간을 활용한 엑스 뷰 기반의 분석은 이미 수많은 고객사에서 검증된 트랜잭션 모니터링 기법입니다. 하지만, 프로파일링 분석은 개발자 혹은 성능 튜닝의 전문가가 아니면 어려움을 겪는 것이 사실이었습니다. 이에 제니퍼는 누구나 쉽게 프로파일링 데이터를 분석 할 수 있는 스마트 프로파일링(Smart Profiling)을 제공합니다. 이 기능을 통해 사용자는 Method, SQL, 외부 서비스 중 응답시간이 느린 구간을 선택하여 해당 시점의 프로파일을 쉽게 분석할 수 있습니다.실시간 Connection Pool 모니터링실시간 Connection Pool 모니터링은 Instance별 Connection Pool을 실시간으로 모니터링하는 기능입니다. 이 기능은 액티브 서비스 차트와 함께 모니터링하며 액티브 서비스 점유가 주로 DB Connection에 있을 경우 Connection Pool 설정을 조정할 수 있어 서비스 성능을 개선할 수 있다는 것입니다. 다른 측면에서 DB Connection을 특정 애플리케이션에서 많이 사용할 경우 현재 Connection을 사용하고 있는 Active Service를 찾아내어 원인을 분석할 수 있습니다.실시간 애플리케이션 변경 이력 모니터링기업에서 운영하는 서비스는 수많은 고객의 요구사항을 반영하고 서비스 개선을 위해 하루에도 여러 번 애플리케이션을 변경합니다. 모니터링 관점에서 애플리케이션 변경 시점은 곧 서비스 장애가 일어날 가능성이 가장 많은 시점입니다. 그렇기에 모니터링이 가장 필요한 시점이기도 합니다. 애플리케이션 변경 감지 기능은 변경 전후의 성능 변화를 실시간으로 모니터링하고, 변경 시점에 변경된 소스코드를 추적하여 어떤 소스코드가 변경되었는지 추적할 수 있습니다.  이를 통해 개발자와 운영자 모두가 쉽고 빠르게 서비스의 변화를 감지하고 대응할 수 있는 장점이 있습니다. 엑스 뷰(X-View) > 애플리케이션 연계 분석애플리케이션 연계 분석은 검색한 X-View의 개별 트랜잭션을 기반으로 애플리케이션 단위 호출건수, 평균 응답 시간, 최대 응답 시간, 평균 SQL 시간, 평균 CPU 시간을 함께 분석할 수 있는 기능입니다.  또한 이러한 성능 수치들이 높은 애플리케이션의 개별 트랜잭션을 분석하여 성능에 영향을 미치는 애플리케이션을 튜닝 할 수 있습니다.엑스 뷰(X-View) > 연계 트랜잭션 분석제니퍼는 하나의 요청으로부터 시작된 다수의 트랜잭션 간의 상관 관계를 모니터링하거나 분석할 수 있습니다. 하나의 서버에서 처리된 서로 다른 업무 트랜잭션들을 연계할 수 있으며, 다른 서버에서 발생된 트랜잭션을 연계할 수 있습니다. 프로토콜 후킹 방식(HTTP, RMI)과 GUID를 활용한 연계방식을 지원합니다.엑스 뷰(X-View) > 자동 스택트레이스제니퍼를 포함한 대부분의 APM은 트랜잭션이 느린 원인을 분석하기 위해 매서드 프로파일링 기능을 제공합니다. 하지만 매서드 프로파일링 기능은 잘못된 설정으로 성능에 영향을 주거나 실제 느린 매서드를 찾지 못할 경우가 많습니다. 또한, 로직을 잘 알아야 하므로 성능 전문가가 아닌 이상 사용이 매우 어려운 단점이 있습니다.제니퍼는 이런 제약사항을 없애고 좀 더 쉽게 사용하기 위해 자동 스택트레이스 기능을 제공합니다.  이 기능은 성능 전문가가 아니더라도 느린 트랜잭션이 발생했을 때 해당 시점에 자동적으로 스텍트레이스(Stacktrace)를 남겨서 원인을 쉽고 빠르게 분석할 수 있습니다. 제니퍼소프트는 항상 제니퍼 고객의 모니터링 환경을 좀 더 쉽고 유용하게 할 수 있도록 고민하고 있습니다.  더 좋은 기능을 제공할 수 있도록 노력하겠습니다. 
조회수 4461

Kubernetes을 활용한 분산 부하 테스팅

Kubernetes을 활용한 분산 부하 테스팅동명의 글이 Google Cloud Platform에도 있으니 여기서는 여태까지 한 삽질과 교훈에 집중한다.첫 시도 ngrinder처음에는 ngrinder로 부하 테스트 환경을 구축하려 했다. 몇 달 전에 부하 테스트를 진행할 때 잠시 쓴 적이 있었기 때문에 굳이 다른 솔루션을 찾을 이유가 없었다. 하지만 결국 후회하고 다른 솔루션으로 넘어갔는데 그 이유를 중요한 순으로 꼽자면로컬 개발환경과 실제 환경이 차이가 많다. 로컬에서는 JUnit 기반으로 개발과 디버깅이 가능하다. 하지만 이렇게 작성한 코드를 ngrinder에 넣으려 하면 외부 라이브러리가 문제가 된다. .jar 등 패키지 파일을 업로드하는 방식이 아니라 Groovy 스크립트 따로 스크립트에서 사용하는 라이브러리 따로 업로드를 해야 하는데 상당히 번거롭다.웹 UI를 통해 설정한 내용이 내장 데이터베이스에 바이너리로 들어가기 때문에 ngrinder 데이터를 관리하기가 힘들다.개발이 활발하지 않다. 주력 개발자가 Naver를 떠났다는 이야기도 있긴 한데 아무튼 커밋 히스토리를 보면 개발이 정체되어 있는 건 분명하다.설계가 진보적이지 않다. 예를 들어 현재 쓰레드의 ID를 시스템이 직접 계산해서 주입하지 않고 개발자가 주어진 코드 스니펫을 Copy & Paste 해야 하는 이유를 모르겠다.등이 있다. 이런 까닭에 좀더 간단한 솔루션을 찾아보았다.대안몇 가지 대안을 살펴보았는데Artillery는 테스트 스크립트를 yaml로 기술하기 때문에 얼핏 쉬워보이지만 이런 식의 접근 방법은 매번 실망만 안겨주었다. 조금만 테스트 시나리오가 복잡해지면 일반적인 코딩보다 설정 파일이 훨씬 짜기가 어렵고 이해하기도 어렵다.config: target: 'https://my.app.dev' phases: - duration: 60 arrivalRate: 20 defaults: headers: x-my-service-auth: '987401838271002188298567' scenarios: - flow: - get: url: "/api/resource"Gatling은 아직 분산 서비스를 지원하지 않아서 제외했다. 팀 내에 Scala 개발경험이 있는 사람이 극소수인 점도 문제였다.Locust로 정착이런 까닭에 Locust로 넘어왔다. 장점은파이썬 스크립트로 시나리오를 작성하니 내부에 개발인력이 충분하다.로컬환경과 실제 부하테스팅 환경이 동일하다. 즉, 디버깅하기 쉽다.Locust 데이터를 Dockerize하기 쉽다.한마디로 ngrinder에서 아쉬웠던 점이 모두 해결됐다. 반면 ngrinder에 비해 못한 면도 많긴 하다.통계가 세밀하지 않다.테스트 시나리오를 세밀하게 조정하기 힘들다.현재로썬 그때그때 가볍게 시나리오를 작성해서 가볍게 돌려보는 게 중요하지 세밀함은 그리 중요하지 않아서 Locust가 더 나아 보인다. 시나리오는 몰라도 통계의 경우, DataDog 같은 모니터링 시스템에서 추가로 정보를 제공받기 때문에 큰 문제도 아니긴 하다.결과물Locust on KubernetesGoogleCloudPlatform/distributed-load-testing-using-kubernetes에 있는 소소코드를 참고로 작업하면 된다. 단지 Dockerfile의 경우, 테스트 스크립트만 바뀌고 파이썬 패키지는 변경사항이 없는 경우에도 파이썬 스크립트 전체를 새로 빌드하는 문제가 있다.# Add the external tasks directory into /tasks ADD locust-tasks /locust-tasks# Install the required dependencies via pip RUN pip install -r /locust-tasks/requirements.txt 그러므로 이 부분을 살짝 고쳐주면 좋다.ADD locust-tasks/requirements.txt /locust-tasks/requirements.txtRUN pip install -r /locust-tasks/requirements.txtADD locust-tasks /locust-tasksngrinder on Kubernetesngrinder를 Kubernetes v1.4.0 위에서 돌리는데 사용한 설정은 다음과 같다. 참고로 dailyhotel/ngrinder-data는 ngrinder의 데이터만 따로 뽑아서 관리하는 도커 이미지이다.ControllerapiVersion: v1 kind: Service metadata:  name: ngrinder  labels:  app: ngrinder  tier: middle  dns: route53  annotations:  domainName: “ngrinder.test.com” spec:  ports:  # the port that this service should serve on  — name: port80  port: 80  targetPort: 80  protocol: TCP  — name: port16001  port: 16001  targetPort: 16001  protocol: TCP  — name: port12000  port: 12000  targetPort: 12000  protocol: TCP  — name: port12001  port: 12001  targetPort: 12001  protocol: TCP  — name: port12002  port: 12002  targetPort: 12002  protocol: TCP  — name: port12003  port: 12003  targetPort: 12003  protocol: TCP  — name: port12004  port: 12004  targetPort: 12004  protocol: TCP  — name: port12005  port: 12005  targetPort: 12005  protocol: TCP  — name: port12006  port: 12006  targetPort: 12006  protocol: TCP  — name: port12007  port: 12007  targetPort: 12007  protocol: TCP  — name: port12008  port: 12008  targetPort: 12008  protocol: TCP  — name: port12009  port: 12009  targetPort: 12009  protocol: TCP  selector:  app: ngrinder  tier: middle  type: LoadBalancer  — - apiVersion: extensions/v1beta1 kind: Deployment metadata:  name: ngrinder spec:  replicas: 1  template:  metadata:  labels:  app: ngrinder  tier: middle  spec:  containers:  — name: ngrinder-data  image: dailyhotel/ngrinder-data:latest  imagePullPolicy: Always  volumeMounts:  — mountPath: /opt/ngrinder-controller  name: ngrinder-data-volume  — name: ngrinder  image: ngrinder/controller:latest  resources:  requests:  cpu: 800m  ports:  — containerPort: 80  — containerPort: 16001  — containerPort: 12000  — containerPort: 12001  — containerPort: 12002  — containerPort: 12003  — containerPort: 12004  — containerPort: 12005  — containerPort: 12006  — containerPort: 12007  — containerPort: 12008  — containerPort: 12009  volumeMounts:  — mountPath: /opt/ngrinder-controller  name: ngrinder-data-volume  volumes:  — name: ngrinder-data-volume  emptyDir: {}AgentsapiVersion: extensions/v1beta1 kind: Deployment metadata:  name: ngrinder-agent spec:  replicas: 5  template:  metadata:  labels:  app: ngrinder-agent  tier: middle  spec:  containers:  — name: ngrinder-agent  image: ngrinder/agent:latest  imagePullPolicy: Always  resources:  requests:  cpu: 300m  args: [“ngrinder.test.com:80”]구 블로그 시절의 댓글#데일리 #데일리호텔 #개발 #개발자 #개발팀 #기술스택 #도입후기 #일지 #Kubernetes #인사이트
조회수 2012

스켈티인터뷰 / 스켈터랩스의 조깨비 조경희 님을 만나보세요:)

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 조깨비 조경희 님을 만나보세요:)사진1. 스켈터랩스의 조깨비 조경희 님Q. 자기소개를 부탁한다.A. 이름은 조경희, 아이리스 팀에서 소프트웨어 엔지니어로 일하고 있다. 2016년 8월에 입사했으니 이제 스켈터랩스에 합류한 지도 2년이 훌쩍 넘었다.Q. 맡고있는 업무를 설명한다면?A. 우리 팀은 일종의 실시간 맥락 인식(Context Recognition) 기술을 개발하고 있다. 다양한 종류의 맥락 인식이 있겠지만, 현재 우리는 모바일 기기를 주요 디바이스로 삼고있다. 핸드폰을 통해 사용자의 다양한 정보를 수집하고, 우리의 기술이 알아서 사용자의 취향이라던지 성향, 좋아하는 음식부터 음악까지 다양한 정보를 여러 시그널을 바탕으로 추론하고자 한다. 이후에는 사용자에 딱 맞는 ‘추천'까지 제공하는 기술을 개발하는 것이 목표다.Q. 핸드폰 하나로 사용자의 다양한 정보를 수집하고 추론할 수 있다는 부분이 신기하다. 조금 더 자세히 얘기해줄 수 있나.A. 가령 내가 안드로이드 사용자라고 가정해보자. 우리가 택시를 부를 때 흔히 사용하는 것 처럼 내가 현재 위치한 곳을, 즉 장소 정보를 핸드폰은 알아서 수집하고 있다. 우리는 장소를 비롯하여 와이파이나 사운드, 배터리, 자이로센서 등으로부터 시그널을 수집하고, 스트리밍 프로세싱 엔진에 송출한다. 그럼 그 엔진에서 실시간으로 이러한 스트림(정보)를 받고, 받은 데이터를 조합하여 새로운 데이터로 변환한 후 다음 단계를 추론하다. 내가 만일 아침 9시쯤에는 항상 일정한 A라는 장소로 이동하고 있고, A 장소로 이동하는 길목에서 카페에 들러 커피를 한 잔 사는 일과를 가지고 있다면, ‘A는 사용자의 회사이고, 사용자는 출근하기 전 커피를 마시기를 즐기는 사람이다'라고 추론할 수 있다. 우리는 이러한 상황에 대한 추론을 바탕으로, 조금 더 고차원적인 추론을 하거나, 사용자의 취향 및 패턴을 찾는 기술을 개발하고 있다. 궁극적으로는 <아이언맨>에 등장하는 자비스(JARVIS)와 같은 퍼스널 어시스턴트(Personal Assistant)를 세상에 내보이고 싶다. 사실 자비스는 어디까지나 영화 속의 상상이 많이 묻어있고, 현재로서는 갈 길이 멀기도 하다. 하지만 현재 스켈터랩스는 음성 인식이나 이미지(Vision), 챗봇과 같은 다양한 프로젝트를 동시에 진행하고 있으며 각각의 기술력도 뛰어나다. 이 여러가지 기술이 총체적으로 구현된 서비스가 탄생한다면, 일상을 혁신적으로 바꿀 것이라고 생각한다. Q. 지금까지의 개발 상황을 살짝 공개하자면?A. 시장에 공개한 것을 기준으로 하자면, 일단 베타 버전으로 런칭한 앱 서비스 ‘큐(CUE)’ 이야기를 하고 싶다. 간단한 상황 인식을 통해 사용자에게 추천을 제공한다. 가령 강수량이 높게 예고된 날에는 ‘우산 챙겨가'라고 카드를 띄워준다거나, 라면을 즐겨 먹는 사용자에게 ‘오늘은 라면 대신 건강한 샐러드 어때?’라고 말해주기도 한다. 사실 큐에 대한 사용자의 의견은 정말 가지각색이었다. 날씨 예보를 기반으로 한 추천의 경우 ‘너무 뻔해서 의미가 없는 것 같다’ 라고 생각하는 사용자가 있는 반면, 출근 직전과 같은 적시에 카드가 알아서 추천해주니 매우 편하게 느꼈다는 사용자도 있었다. 결국 나는 상황 인식이 사용자에게 유용한 서비스로 와닿기 위해서는 ‘정확성'이 큰 척도라고 생각한다. 적시에, 적절한 장소에서, 나에게 꼭 맞는 추천을 해주는 것, 이를 위해서는 사용자를 정확하게 파악하는 것이 우선되어야 하기 때문이다. 지금까지의 개발이 상황 정보를 적절하게 받을 수 있는 플랫폼 구축 중심이었다면, 현재는 더 자세한 상황을 찾는 쪽으로 초점이 맞추어져 있다. 가령 사용자가 ‘지하철을 타고 이동한다'가 아니라, ‘어느 역에서 지하철에 탑승하여 어느 역에서 내렸다'까지 인식할 수 있는 것이다. 음악도 마찬가지다. 음악과 같이 엔터테인먼트 컨텐츠의 경우 단순히 ‘음악을 듣고 있다'라는 정보가 아니라, 취향 정보가 중요하다. 때문에 ‘어떤 가수의 어떤 음악을 들었다'까지 인식하여 이를 조합한 추론을 만들려고 한다.사진2. 사내 Tech Talk 세미나를 진행하고 있는 경희님Q. 큐의 베타 서비스를 런칭하며 팀원들끼리 자축하던 장면이 떠오른다. 굉장히 뿌듯한 경험이었을 것 같다.A. 나는 사실 뿌듯함 보다는 ‘갈 길이 멀다'라는 생각을 먼저 했다. 베타 버전이기도 했고, 개발한 우리 스스로도 정확성이 기대에 미치지 못하고 있다고 생각했다. 그럼에도 불구하고 런칭을 결정한 이유는 명확하다. 다양한 사용자가 큐를 통해 어떤 경험을 얻고, 어떻게 느끼는지 들어야만 더욱 사용자의 핏에 맞는 정식 버전을 제대로 개발할 수 있을 것이라고 판단했기 때문이다. 모든 서비스가 마찬가지겠지만 나는 큐야 말로 많은 사용자와 함께 만들어가는 서비스라고 생각한다.Q. 경희님 개인의 이야기를 들어보고 싶다. 스켈터랩스에 어떻게 합류하게 되었는가.A. 스켈터랩스의 CTO인 조성진 님과 같은 연구실에서 일했다. 연구를 마친 후 나는 전문연구요원으로 다른 회사에서 일을 했고, 성진님은 구글에 입사한 것으로만 알고 있었는데, 구글을 나와서 회사를 차렸다는 얘기를 듣게되었다. 그때만 해도 대기업이 주는 안정감을 놓칠 수 없어 대기업에 머물러있었다. 하지만 성진님을 자주 만나 스켈터랩스의 프로젝트가 어떠한 방향으로 구체화되고 있는지 들을수록 매력적으로 와닿았다. 대기업의 경우 조직의 구조 때문에 어쩔 수 없이 쪼개진 일에 집중하게 된다. 하지만 스켈터랩스는 구성원들 모두가 자발적으로 참여하여 방향성을 결정 짓고, 개발 환경을 선진적으로 꾸리고 있다는 점도 좋았다. 이러한 요소가 결국 스켈터랩스로의 이직을 결정지었던 것 같다.Q. 스켈터랩스로 이직하여 얻은 가장 큰 성취를 꼽자면?개인적으로 코드리뷰 문화를 통한 개발 실력의 발전을 꼽고 싶다. 다른 조직에서는 다른 사람이 내 코드를 봐주고, 평가하는 것이 마치 자존심 싸움처럼 여겨지곤 했다. 타인의 코드는 일종의 침범할 수 없는 ‘불가침 영역'으로 인식되었다. 하지만 스켈터랩스에서는 코드리뷰가 너무나도 당연하다. 다른 사람에게 코드를 보여주고, 내 코드가 더욱 효율적으로 작동할 수 있도록 바꾸어주는 것이 자연스럽게 이루어지고 있다. 이 과정을 통해 코드를 리뷰하는 사람도, 리뷰받는 사람도 모두가 윈윈(win-win)할 수 있다. 코드리뷰 문화가 익숙하지 않은 사람에게는 이 문화가 마치 일의 효율을 저해하는 것 처럼 여겨질 수 있다. 그러나 결론적으로는 목표에 닿기 위한 가장 빠른 방법이라고 생각한다. 확실히 여러 개발자의 리뷰를 거칠수록, 버그는 적어지고 개인의 실력이 향상될 뿐더러 시야도 넓어질 수 있기 때문이다. 나 또한 같은 경험을 했다. 스켈터랩스에서 몇 개월 근무한 후, 내가 이전에 짜놓은 코드를 보면 ‘어떻게 이렇게 짜놓았지' 싶을 때가 있다. 개발 실력에 관한 이러한 성취를 정량적으로 판단할 수 는 없지만, 회사와 개인이 모두 발전할 수 있는 가장 의미있는 성취라고 생각한다.Q. 반대로 스켈터랩스에서 개발을 하며 가장 어려운 점은 무엇이 있을까.개발 자체에 대한 어려움보다는 방향성에 대한 어려움이 있다. 인공지능이라는 분야는 워낙 넓기도 하고, 상황인식 기술의 경우 근래에 크게 발전하고 있는 것은 맞지만, 세부 기술에 대해서는 시장 자체가 뚜렷하지 않다. 참고할만한 제품도, 경쟁사도 없기 때문에 새로운 시장을 만들어내는 것에 대한 부담이 있다. 언뜻 보기에는 경쟁사가 크게 없는 니치마켓(Niche market)처럼 여겨질 수 있지만, 기술을 쪼개고 쪼개어 들여다보면 하나의 기술을 바탕으로 각각 다른 사용자와 상황을 타깃으로 변주한 다양한 서비스가 등장하는 상황이다. 이러한 기술을 마냥 뭉뚱그린다면 기술에 대한 깊이가 얕아질 수 있고, 특정 상황과 사용자에게만 집중한다면 타깃이 좁아질 위험이 있다. 때문에 시장과 사용자에 대해 매 순간 유추하며 적절한 균형을 가지고 개발을 진행할 수 있도록 노력하고 있다. 사진3. 프로젝트 별 Sync-up 미팅, 짧은 미팅을 통해 업무 효율을 높이고 있다Q. 스켈터랩스의 개발 문화가 타 기업과 확고하게 다르다고 느낀 사례가 있다면, 그 이야기를 구체적으로 듣고싶다.A. 두 가지를 꼽고 싶다. 첫 번째는, 다른 분들도 많이 얘기했을 것 같지만 역시 와 다. 각각 상반기와 하반기에 한 번 씩, 하는 일을 모두 멈추고 일주일 간 원하는 개발에 집중하는 일종의 해커톤이다. 내가 입사한 날이 Demo Days 시작 이틀 전이었다. 입사하자마자 부랴부랴 팀을 만들고, 아이디어를 구체화하여 개발에 매달렸다. Demo Days 기간 내내 팀원들이 밤을 새워가며 개발에 매달리는데, ‘매일 이렇게 일하는 곳인가' 라는 두려움과 ‘이렇게 뛰어난 개발자들이 집중하니까 뚝딱 서비스가 나올 수 있구나'라는 재미를 동시에 느꼈다. 그 기간이 끝나고 보니 역시 매일 그렇게 일하는 것은 아니었다. 일주일 간 그토록 밤을 세워 개발을 할 수 있는 원동력은 ‘내가 원하는 서비스를 직접 만들어볼 수 있다'라는 흥미와 ‘최종 발표일에 어설픈 개발로 쪽팔리고 싶지 않다'라는 감정인 것 같다. 매일 하는 업무에서 벗어나 리프레쉬 할 수 있는 재미요소도 크다. 그 기간의 우리 성과를 돌아보면, 이토록 개발을 사랑하고 기대 수준이 높은 사람들이 모여있으니, 뭘 하던 성공할 것이라는 일종의 확신을 얻을 수 있다. 두 번째는 ‘빠르다'라는 점이다. 새로운 아이디어나 기술에 대해 흥미가 생겼을 때 쉽고 빠르게 팀을 꾸릴 수 있다. 그렇기 때문에 자연스럽게 자신의 흥미와 역량에 맞는 팀을 찾아 이동하는 것도 매우 자발적으로, 빠르게 이루어진다. 오픈 소스 사용도 빠르다. 새로운 기술이나 제품을 들여다보고 싶다면, 그냥 진행해 볼 수 있다. 기존의 큰 회사들은 수직적으로 팀장 급에서 업무를 할당하고 시일에 맞추어 개발을 진행하다 보니, 속도 자체는 빠를 수 있지만 허술한 부분이 생기기 마련이고 새로운 기술을 도입에 있어서도 조심스럽다. 하지만 스켈터랩스에서는 ‘빨리 도입하고 빨리 경험해보자’ 라는 의식을 공통적으로 가지고있다.Q. 개발자는 개발이 막히는 순간도 종종 맞닥뜨릴 것 같다. 그럴 때 어떻게 해결하는지 자신만의 팁을 공유한다면.A. 고민의 양이 아니라, 그저 고민의 끈을 놓지 않고 있는 것이 중요한 것 같다. 나는 개발이 막혔을 때 스트레스를 꽤 많이 받는 편이다. 한 번 막히면 맥주를 마시면서도, 밥을 먹으면서도 항상 머리 한 구석에는 개발 고민을 이어간다. 꿈에서도 하도 코딩을 한 탓에, 와이프가 어느 날 “어젯 밤에도 ‘테스트 코드는 이렇게 해야지’ 라는 잠꼬대 하던데?”라고 말할 정도다. 그러다 신기하게도 개발을 아무 것도 모르는 제 3자와 얘기하다가 번뜩 방법이 떠오르곤 한다. 지극히 일상의 순간, 가령 샤워를 한다거나 멍하니 지하철을 타다가 해결책을 찾기도 한다. 이 방법이 훌륭한 팁은 아닐 수 있지만, 포기하는 것이 아니라 개발에 대한 고민을 놓지않는 것이 중요하다는 얘기를 전하고 싶다.사진4. 경희 님과 아내 분의 투샷Q. 경희님이 회사에서 종종 드라마 얘기를 하는 것을 들었다. 드라마를 많이 보는 편인가, 하루 일과를 듣고 싶다.A. 예전에는 <와우>라는 게임을 정말 많이했다. 덕분에 게임 동호회에도 가입해있는데, 요즘에는 <오버워치>나 <클래시로얄> 정도만 즐기고 있다. 결혼하고 와이프와 시간을 함께 보내면서, TV 시청이 늘었다. 와이프가 워낙 TV를 좋아하기도 하고 함께 집에서 시간을 보낼 수 있는 가장 편리한 방법인 것 같기도 하다. 하루 일과는 그래도 일찍 시작하는 편이다. 와이프는 일곱시 쯤 일어나 출근하는데, 나도 보통은 맞춰서 함께 일어난다. 재택근무를 할 수 있는 환경이다보니, 오전에는 주로 집에서 코딩을 하며 개발에 집중한다. 보통 점심 때 출근을 하거나, 미팅에 맞추어 출근하는 편인데, 오후 시간은 미팅과 개발 모두를 병행해서 꽤 정신 없이 하루가 흘러가는 것 같다.사진5. 게임동호회에 가입하면, 회사의 지원을 받아 게임을 즐길 수 있다.Q. 스켈터랩스에서 이루고 싶은 것을 듣고싶다.A. 나의 꿈이 원래 ‘내가 개발한 기술이나 제품이 최대한 많은 사람에게 편리함을 주는 것'이었다. 우연히도 스켈터랩스의 미션인 “언제 어디서나 우리의 일상을 이해하고, 도와주고, 더 나아지게 하는 머신 인텔리전스의 혁신을 이룬다”와 일치하더라. 덕분에 내 꿈을 이루어나가는 것과 스켈터랩스가 혁신적인 기술을 바탕으로 성장하는 것은 궤를 같이한다. 그것이 내가 스티브잡스 처럼 특정 분야의 스타가 되는 것을 뜻하지는 않는다. 연속성이 있고 확장성이 있는 기술로 우리의 일상을 조금씩 더욱 편리하게 가꾸어나가고 싶다.Q. 마지막 질문이다. 스켈터랩스에 바라는 점이 있다면 무엇인가.A. 내가 입사했을 때만 해도 20명 정도에 불과했던 인원이 현재는 70여 명으로 늘었다. 체감상 인원이 조금씩 느는 것이 아니라 순간적으로 확 늘어나는 시기가 있는 것 같다. 그 때마다 약간의 침체기랄까, 분위기가 변하는 모습이 감지된다. 예전에는 사람이 적기 때문에 자연스레 커뮤니케이션이 자율적이이었지만, 사람이 늘어난 만큼 제한적인 커뮤니케이션 모습을 종종 발견할 수 있었다. 이러한 문제 의식의 발로로 컬쳐커미티(Culture Committee)가 생겨났다. 커미티의 활동 덕분에 매주 1:1로 커피를 마실 수 있는 커피믹스와 같은 제도도 신설되었다. 이렇듯 지속적으로 우리만의 모습을 유지하기 위한 노력이 지속되었으면 좋겠다. “우리는 답을 찾을 것이다. 늘 그랬듯이”, 흔한 명대사지만 스켈터랩스 또한 내부적으로도, 외부적으로 늘 답을 찾아가길 바란다. 물론 나 또한 그 답을 찾는 여정에 함께할 테지만 말이다.
조회수 4008

리디북스 서비스 장애 복구 후기

지난 8월 26일에는 약 21분간 리디북스 서비스 전체가 중단되는 장애가 있었습니다.사실 서버 스택 일부에만 영향을 주는 장애는 눈에 잘 띄지 않지만 꽤 흔하게 발생하는 일입니다. 기기 1대당 외부적인 요인으로 인한 장애가 평균 2년에 1번 발생한다고 가정하면, 서버가 100대 있을 때는 대략 1주일에 1번꼴로 장애가 발생하는 셈입니다.이런 형태의 장애는 서버 스택의 한 곳에서만 발생하므로, 이중화 혹은 클러스터링을 통해서 극복하곤 합니다. 또한 원인이 명확하므로 해당 기술에 대한 이해도가 높다면 비교적 빠른 시간 내에 복구가 가능합니다.그러나 이번에 리디북스가 경험한 장애는 달랐습니다. 현재 리디북스는 2개의 데이터센터와 클라우드에 인프라가 분산되어 있는데, 이 중에서 1차 데이터센터의 전원 공급에 문제가 생겨 특정 서버 랙에 있는 서버 17대가 동시에 내려간 것입니다. 즉, 소프트웨어나 머신의 물리적인 장애가 아닌, 데이터센터의 장애였습니다. AWS로 비유를 하자면 가용 영역(Availability Zone)의 장애라고 할 수 있겠습니다.원인에 대해이번 장애의 근본적인 원인은 데이터센터가 전원을 정상적으로 공급해주지 못한 것입니다. 물론 데이터센터 혹은 클라우드 서비스(IaaS)는 고객사에게 전원과 네트워크를 안정적으로 제공해주어야 하는 의무가 있습니다.하지만 이들 역시 천재지변이나 사람의 실수에 대한 대비가 100% 완벽할 수는 없습니다. 따라서 이러한 점을 사전에 고려하고 인프라를 설계하지 못한 것이 2차적인 원인입니다.이번 계기를 통해 데이터센터 이중화를 계획하게 되었고, 사용 중인 클라우드 역시 지역(Region) 전체에 장애가 생길 경우에 대한 대비가 되어있지 않아, 이번 계기로 복제 계획(Geo-Replication)을 세우게 되었습니다.구체적인 상황당시 전원이 차단되어 강제 종료된 서버들은 아래와 같습니다.데이터베이스 프록시 x 2메인 리버스 프록시 x 1읽기 분산용 MySQL 슬레이브 x 1서점용 웹 서버 x 3추천 알고리즘 API 서버 x 1알림센터 API 서버 x 2메인 스토리지 서버 x 2출판 플랫폼용 데이터베이스 x 2테스트 및 배치 작업용 서버 x 3그림으로 표현해 보자면, 대략 아래와 같은 상황에서… 아래와 같은 상황이 된 셈입니다.서버 스택의 여러곳에 순간적으로 장애가 발생한 상황공인 IP가 할당된 메인 프록시 서버 중 1대가 내려갔지만, 실제로는 아래와 같이 가상 IP로 구성을 한 상태였기 때문에 대기 중인(stand-by) 프록시가 동작하여 곧 서점에 장애 공지를 띄울 수 있었습니다.[이미지 출처: DigitalOcean™]공지 이후의 움직임우리는 데이터센터의 복구 시점을 명확히 알 수 없어서 신규 구축(provisioning)을 시작함과 동시에, 서버들의 물리적인 위치 이동을 고려하고 있었습니다. 그러나 다행히 10분이 지난 시점에서 전원 문제는 해결되었고, 서버들은 순차적으로 부팅이 완료되었습니다.일부 서버들은 부팅 과정에서 예상치 못한 지연이 발생하기도 하였지만, 모든 서버의 부팅이 완료된 이후에도 서비스는 완전히 정상으로 돌아오지 않았습니다. 당시 우리가 겪었던 문제와 해결책은 아래와 같습니다.A. 읽기 분산용 MariaDB 슬레이브의 복제 지연(replication lag) 문제슬레이브 서버의 부팅이 완료되자 데이터베이스 프록시(HAProxy)는 해당 서버를 정상으로 간주하여 라우팅 대상에 포함하게 되었고, 애플리케이션 서버들은 정상적으로 커넥션을 맺기 시작하였습니다. 하지만 해당 슬레이브는 수십 분간 마스터를 따라잡지 못한 상태였기 때문에 최신 데이터가 보여지지 않는 문제(stale data)가 있었습니다. 우리는 즉시 해당 슬레이브를 제거하였고 지연이 사라진 이후에 다시 서비스에 투입하였습니다.B. 읽기 분산용 슬레이브의 웜업(warm-up) 문제복제 지연은 사라졌지만 서버의 CPU 사용량이 크게 높은 상태가 한동안 유지되었고, 응답속도는 정상적인 슬레이브에 비해서 많이 느렸습니다. 왜냐하면 캐시가 비워진 상태에서 바로 서비스에 투입되어, 캐시 미스가 휘몰아치는 현상(cache stampede)이 발생하였기 때문입니다. 따라서 간단한 쿼리도 평소보다 오래 걸렸고, 그대로 둔다면 커넥션풀이 꽉 차는 현상이 발생할 것으로 예상되었습니다.곧 우리는 HAProxy로 해당 서버의 가중치를 10%로 낮추어 인입되는 쿼리의 양을 조절하였으며 응답속도는 정상 수치로 돌아오게 되었습니다. 이후 스크립트를 작성하여 수동으로 캐시를 채워나감과 동시에 점차 가중치를 높여 처리량을 정상화하였습니다.프로덕션에서 사용하는 서버는 innodb_buffer_pool 이 100G 이상으로 매우 크게 설정되어 있으며, 재시작 시 캐시가 날아가는 현상을 해결하기 위해 innodb_blocking_buffer_pool_restore 옵션을 적용하고 있습니다. 하지만 지금처럼 메모리를 덤프하지 못하고 비정상 종료가 된 상황에서는 해당되지 않았습니다.C. 인메모리 데이터의 보존 문제알림센터는 다양한 프로모션과 개인화된 정보를 전달해주는 공간입니다. 알림센터의 특징은 데이터의 영구 보존(persistency)이 필요하지 않고, 매일 수백만 건의 개인화된 메시지가 기록된다는 것입니다. 이러한 특징은 인-메모리 데이터베이스에 적합하므로 우리는 Redis를 마스터/슬레이브로 구성하여 저장소로 사용하고 있었습니다.어떠한 이유로든 Redis를 재시작해야 할 경우가 생기면, 메모리 상의 데이터가 날아가는 것을 방지하기 위해 주기적으로 스냅샷을 남기고 있습니다만, 이번에는 로그가 마지막까지 기록되지 못한 상태에서 메모리의 데이터가 날아가 버렸습니다.다행히 알림 발송과 관련된 메타정보는 모두 MariaDB에 기록하고 있으므로, 우리는 이를 기반으로 소실된 시점부터의 알림을 순차적으로 재발송할 수 있었습니다. 물론 모든 알림이 신규 상태로 간주되어 아이콘이 잘못 노출되는 문제가 있었지만, 고객님들은 너그럽게 이해해 주신 것 같습니다. 😅그래서 앞으로는?리디북스 DevOps 멤버들은 이번 데이터센터 장애를 통해 현재 인프라의 한계점을 실감하였고, 앞으로의 개선 방향에 대해 고민하게 되었습니다.몇 가지를 정리하면 다음과 같습니다.랙 단위로 장애가 발생할 수 있음을 인지하고 대비하자.같은 기능을 하는 서버를 하나의 랙이나 같은 가용 영역에 두지 말자.2차 데이터센터는 더 이상 옵션이 아닌 필수다.낙뢰나 지진으로 인해 데이터센터에 문제가 생길 수도 있다.긴급하게 프로비저닝이 필요한 상황에 대비하자.문서화가 되어 있더라도 경험이 없다면 동일한 구성에 많은 시간이 소요된다.모든 구성요소들에 대한 Ansible 스크립트를 작성하여두자.캐시 웜업 스크립트도 작성하여 두자.백엔드 구성요소들 간의 불필요한 의존 관계를 끊자.단 한 줄의 코드라도 참조하고 있다면 이는 독립적인 것이 아니다.언제나 서비스 지향적인 설계를 추구하자.Uptime을 관리하자.최대 180일을 기점으로 무조건 리부팅을 하자.재시작 과정에서 다양한 문제와 개선점이 발견될 것이다.커널 패치, 보안 패치를 할 수 있는 것은 덤이다.아래와 같은 긍정적인 면도 발견하였습니다.장애 상황이 실시간으로 Slack 채널을 통해 전파되었음진행 상황에 대해 모두가 동일한 수준으로 이해할 수 있었다.모니터링 연동(integration) 기능 때문에라도, Slack은 유료로 구매할만한 값어치가 충분하다.같은 기능을 하는 서버들이 다른 랙에 많이 분산되어 있었다.인프라가 확장될 때마다 빈 공간에 필요한 서버를 추가했을 뿐이지만, 자연스럽게 물리적인 위치가 분산되는 효과가 있었다.이 외에도 특정 클러스터를 구성하는 노드들을 분산하여 배치시키자.서버별로 오너쉽이 부여되어 있어서 빠르게 복구가 된 점여러 명의 백엔드 개발자들이 병렬적으로 복구를 진행할 수 있었다.마지막으로넷플릭스의 엔지니어들은 무질서한 원숭이(Chaos Monkey)라는 프로그램을 만들어서 운영한다고 합니다. 이 원숭이는 서비스 인스턴스들을 무작위로 중단시키는 역할을 합니다. 다소 황당하게 들리지만, 넷플릭스에는 일부 서비스에 장애가 발생하더라도 나머지 부분은 문제없이 운영되어야 한다는 원칙이 있으므로, 이를 수시로 시뮬레이션하는 과정을 통해 복구 능력을 높여둔다는 것입니다.실제로 이렇게 급진적인 아이디어를 실천할 수 있는 회사는 매우 드물 것입니다. 하지만, 우리는 이번 계기를 통해 무질서한 원숭이의 필요성을 절감하였고, 이로 인해 서버를 주기적으로 리셋하는 정책을 만들게 되었으며 모든 단일 장애점(SPoF)에 대한 대비를 시작하게 되었습니다.장애를 단순히 피해라고만 생각한다면, 서로를 비난하고 책임을 전가하는 상황이 펼쳐질 것입니다. 하지만 고객의 불편함과 맞바꾼 매우 비싼 경험이라고 생각한다면, 보다 튼튼하고 회복탄력적인 시스템을 갖추기 위해 노력하게 될 것입니다. 그러다 보면 언젠가는 데이터센터 전체에 문제가 생겨도 버틸 수 있는 모습으로 진화할 것이라고 생각합니다.#리디북스 #장애복구 #역경돌파 #개발 #개발후기 #개발자 #서버개발 #서버

기업문화 엿볼 때, 더팀스

로그인

/