스타트업을 시작하고 나서 가장 많이 받는 질문이 있었다."어떤 사업을 하고 계신가요?"< 사업 설명은 시작하면 끝이 없다. 아마? 시킨다면 밤도 샐 수 있다. >피부로 느낀 현실은 해당 사업에 대한 설명을 아무리 잘 해도 상대방을 완벽하게 이해시킬 수 없다는 것이었다. 이야기를 듣는 그는 당신의 하는 비즈니스의 전문가가 아닐뿐더러 타깃 고객층 역시 아닌 경우가 많기 때문이다. IT 지식이 없는 상대에게 성능 좋은 SDK를 개발해서 파는 사업을 설명한다던가, 중년이 넘어선 상대방에게 아이돌 가수들과 연관된 서비스를 이해시키기란 정말 쉽지 않은 일이다.1. 그는 당신의 비즈니스에 관심이 없다. ( 숫자가 궁금할 뿐 )2015년 SF에서 머무르던 시기, 스타트업 네트워크 모임에서 맥주를 마시며 캐주얼하게 한 친구와 이야기를 나눈 적이 있다. 인사를 나누고 안 되는 영어와 바디랭귀지를 마구 섞어 우리 팀이 하고 있는 서비스에 대해서 열심히 소개를 했지만 반응이 시큰둥했다. 많은 스타트업이 그러하듯 나 역시도 우리 팀이 하는 비즈니스는 정말 멋지고 훌륭하고 대박이 날 것 같은 근거 없는? 자신감과 똘끼가 충만하던 시기였다. 우리는 홍대의 노점상부터 시작해서 개고생을 하며 바퀴벌레 같은 생명력과 독기를 가지고 있던 시기였고 그 당시는 정말 뭐라도 다 씹어먹을 기세였다.곧 그 친구의 논리 정연한 답변과 질문이 이어졌다. 네가 하는 비즈니스에 대해서는 네가 가장 잘 알 꺼야. 내가 해당분야의 전문가가 아니기 때문에 이해를 못하는 점 미안해. 그리고 수많은 시간과 열정을 쏟아부었던 너의 비즈니스를 판단하는 것은 말이 안 된다고 생각해. 내가 이해할 수 있게 주요 숫자들만 말해 줄 수 있니? 였다.당시 내게 이런 형식의 질문을 던전 사람은 처음이었다. 그가 원하는 답변은 매출 같은 숫자가 아닌 바로 MAU, DAU, LTV, CAC, CTR, Retention, MoM Growth Rate 등과 같이 서비스가 실제 사용자에게서 획득한 숫자였다. 무지했고 별로 중요하지 않게 생각했기 때문에 완벽한 답변을 하지 못했다. 나중에 알게 된 사실인데 그 친구는 이름만 되면 알만한 어느 유명 VC의 파트너였고 난 어찌 보면 좋은 투자기회를 놓친 실수를 하고 만 것이었다. 그 사건 이후 비즈니스 설명은 최대한 적게 하는 대신 숫자로 이야기하는 연습? 아니 숫자들을 파악하고 머릿속에 집어넣기 시작했다.<  숫자로 설명하고 숫자로 설득 시켜야 한다는 것을 몰랐었다. >예를 들어, 우리가 사용자를 확보하는데 평균 5,000원의 마케팅 비용이 들고 (UAC) 이렇게 확보한 사용자는 우리 서비스에서 한 달간 10,000원을 지불한다.(LTV) 그래서 얼마의 돈이 있다면 얼마를 벌 수 있고 (Scale up) 우리가 이렇게 성장을 계속한다면 몇 년 안에 무엇을 달성할 수 있어(KPI).라는 식이다.2. 비즈니스의 판단의 몫은 따로 있다.스타트업 초기 열심히 참가하는 네트워크 모임이나 발표 현장에서 만났던 투자자나 멘토들은 사업 설명을 듣고 "이 사업이 되네 마네 감 놔라 배 놔라" (심지어 창업 경험도 없는) 하는 사람들이 대부분이었다. 수년간의 시간과 자신의 모든 것을 걸고 실행과 개선을 반복하고 있는 창업팀이 경험한 인사이트를 단 1분 만에 깨 부셔버리기 일쑤였다.수천, 수만 가지의 다양한 산업이나 다양한 고객층이 존재하는 시장과 기회를 보고 서비스나 제품을 만들고 있는 스타트업 사업의 본질을 타인이 이해하기란 실로 쉽지 않다. 한 발표 자리에서는 스푼 라디오를 설명하고 나서 실제로 들었던 질문 중에 "개인 라디오 서비스 앱이라고 하셨는데 그렇다면 라디오 주파수를 어떻게 할당받으셨나요?"라는 질문을 받은 적이 있다. (실화다...)아직도 사업을 그냥 짧은 순간의 자신이 가지고 있는 경험과 지식을 바탕으로 바로 판단하는 사람들이 절대다수이지만 숫자로 대화를 이어갈 수 있는 기회나 사람들이 분명 존재한다.반대로 자신감에 넘쳐 '천상천하 유아독존' 유형의 밑도 끝도 없는 자신감만으로 세계 최고가 될 거라 주장하는 스타트업들도 많이 만났다. '제2의 페이스북이 되겠다.'라고 한다면 그 이유와 논리를 숫자(데이터)로 펼칠 수 있어야 하고 추가적으로 가능할 수밖에 없는 수백수천 가지의 가설 검증과 객관적인 지표를 내밀 수 있어야 하지 않을까?스타트업이 하는 비즈니스의 판단의 몫은 냉정하게 따지고 본다면 창업자의 몫이 아니다. 그렇다고 투자사나 멘토 역시 아니다. 그 서비스나 제품을 실제로 쓰는 타깃 사용자만이 그 서비스를 실제로 판단할 수 있는 자격? 이 있는 사람이다. 물론 사용자가 전문가처럼 비즈니스 자체를 판단하지는 않는다. 타깃 사용자들이 얼마나 서비스에 대한 구매전환율이나 사용 패턴을 보이고 충성도 재방문주기가 어떤지 등으로 냉정한 판단?을 받게 된다.  아무리 혁신적인 기술로 무장한 제품이나 매력 있는 서비스라고 주장해도 사용자가 외면한 제품, 서비스라면 존재의 이유 자체가 없거니와 해당 스타트업이 죽음의 계곡에서 살아 남지 못함을 우리는 뼈저린 실패를 통해 배운 경험이 있다.세상에 없던 혁신적인 서비스라 주장하고 자랑했던 스타트업들이 망하기도 하고, 투자자나 멘토들이 혹평을 하고 무시했던 서비스들이 유니콘 기업이 된 해외사례를 충분히 찾아볼 수 있다. 국내에서도 세계 최고라고 떠들면서 배임 횡령 등의 문제를 일으킨 스타트업들이 보도되기도 했고, 몇 년 전 투자사들에게 무시당하고 아무도 거들떠보지 않았던 스타트업이 이제 업계를 좌지우지할 정도로 성장한 사례를 이제는 심심치 않게 국내에서도 찾아볼 수 있으니 어찌 보면 우리나라 스타트업계도 많은 성장을 하고 있음이 분명하다.한국의 문화와 특성상 남이 잘되면 가만히 놔두지 않는 문화가 존재한다.오죽하면 "사돈이 땅을 사면 배가 아프다."라는 속담이 있을까?사돈이 땅을 사면 좋은 일이니깐 함께 기뻐해 줘야 하는데...해당 부분은 쉽게 바꿀 수가 없기 때문에 내부에서는 자신감을 가지지만 겸손해야 하며, 절대 자만해서는 안 된다는 점을 느끼고 있다. 또한 외부에서 어떤 비판이나 심지어 비난이 이어지더라도 초연해 지려 하고 있으며, 반대로 칭찬에는 우리는 언젠가 다시 또 망할 수 있다는 점을 잊지 않으려 되새김질하고 있다.3. 숫자는 거짓말을 하지 않는다.아쉽게도 지금 우리가 하는 스푼이라는 서비스는 20대가 타깃인 서비스로 30대 후반인 나는 타깃 고객층이 아니다. 그래서 스푼 라디오를 들어봐도 재미를 느끼거나 공감을 할 수 없을뿐더러 서비스의 수많은 방송에서는 그들만이? 쓰는 특정한 단어들의 이해 또한 힘들다.하지만 사용자들의 로그나 숫자(데이터)는 거짓말을 하지 않는다. 우리 서비스 숫자(데이터)의 본질과 가능성을 우리가 먼저 파악을 하고 있어야 하고 해당 부분을 볼 줄 알아야 하고 그런 사람들을 만나야만 한다. 그게 투자사가 될 수도, 합류하는 멤버가 될 수도 있다.SNS에서 "20대가 쓰는 서비스를 30대가 기획하고 40대가 리뷰하고, 50대가 최종 의사 결정을 하는 것이 문제다."라는 글을 본 적이 있다. 매우 공감한다. 주변에서도 아직 수많은 서비스들이 이러한 프로세스를 통해 망하는 사례를 수 없이도 많이 보았다. 그렇다고 50대가 20대의 머릿속에 들어갈 수 없는 노릇이고 아무리 그들과 어울려 본다고 하지만 그들의 감성과 문화를 완벽하게 이해할 수는 없다. 해서 판단을 하는 기준과 의사결정을 숫자(데이터)를 보고 정하고 있고 숫자를 최대한 많이 보기 위해 수많은 분석 툴과 로그들을 보고 있고  그 필요성을 더욱 절실하게 느껴 유료 분석 툴들을 사용하기 시작했다.< 정말 많은 툴을 써보면서 분석 노가다를? 아직도 열심히 하고 있다. >개발자 시절 코드는 거짓말을 하지 않는다.라는 동료 개발자의 말이 생각난다. 로직으로 돌아가는 코드가 거짓말을 할 수 없을뿐더러 모든 오류나 문제는 사람의 실수( 사람이 잘못 작성한 코드)에서 비롯되기 때문이다.숫자 역시 거짓말을 하지 않는다. 1을 투입하면 2가 나오는 곳을 확대하고 2를 넣으면 1을 손해 보는 곳을 줄이며 서비스를 개선시켜나가면 서비스는 성장을 하기 시작한다. 그리고 이 숫자의 로직이 큰 숫자들을 대입했을 때도 동일하게 동작하는지 지속적인 테스트를 해나가고 있다. 100만 원의 마케팅비를 들여서 200만 원을 번 서비스에 1억 원의 마케팅비를 투입했다고 해서 2억 원의 매출이 나올지는? 아무도 모른다.그래서 우리는 지금도 그리고 앞으로도 우리의 경험이나 기존 지식을 판단의 기준으로 하지 않고 사용자들의 피드백과 사용자들이 서비스 내에서 만들어낸 숫자(데이터)를 보기 위한 노력을 게을리하지 않아야 한다.#스푼 #Spoon #초기창업 #성장 #인사이트 #조언

 <어반 테이스트 2탄>어반베이스의 87년생 토끼들이 뭉쳤어요! (예전엔 토끼띠라고 하면 어리고 귀여운 느낌이었는데32살에 토끼를 말하려니 오그ㄹㄹㄹㄹㄹ .... )   우리는 아주 심플하게 '나이'로 단합해서팀결성을 5분 만에 끝냈어요! 이 절호의 기회에 무엇을 먹어야 잘 먹었다고 소문이 날 수 있을지…메뉴를 고르고 고르고 고르다가 역삼에 위치한 맛집 중 최종 후보로 선정한 2곳!<나혼자산다>에서 비와 이시언이 먹었던 고깃집“돝고기506”VS친구가 추천해준 와사비 파스타 맛집“계절미각”(이런 결정장애......) 우리는 긴 고민 끝에 계절미각을 선택했어요! 드.디.어 테이스트 가는 날 ! 그런데 이게 왠걸…. 가기로 한 당일, 비가 너무 쏟아져서..결국 취소.....다시 약속을 잡았습니다!그.러.나...두번째 약속 당일, 비가 더 ‘미친듯이’ 와서 또 취소....(우와와와와와오아아 미춰붜리게ㄸㅏㅏㅏㅏ)우리에게 비(를 몰고 다니는)신이 붙은걸까요?...이러다 계속 못먹겠다 싶어다시 약속 잡은날은 천재지변이 오지 않는 이상 무조건 고고 하는걸로 했는데 다.행.히!!!!!!!!!세번째 약속 잡은 날은 날씨가 음청 좋았더랬죠!계절미각 가는 길. 사이 좋아 보이는 민수님과 태욱님참고로 계절미각은절대미각으로 불리는 허영만 화백이 추천한 역삼 맛집이랍니다 ><역삼역에서 약 10분정도 걸어서드디어 계절미각 입성!(민수님 왼쪽다리 출연)외관은 생각외로 고급스럽기보다 귀엽고 아담한 느낌이였어요!내부에 들어서니'어머!' 인테리어나 분위기가 딱 제스타일!이곳저곳 감각이 묻어있는 공간이였습니당!자, 이제 저희가 먹었던 음식들을 품평해보는 시간을 갖겠습니다! 1. 스테이크 샐러드계절미각에서 먹었던 요리 중 쵝오!! 평소 샐러드를 막 즐기는 편은 아니지만 간이 잘 베인? 스테이크랑 같이 먹어서 그런지 맛이 좋았어요!2. 연어 와사비 파스타사실 친구에게 계절미각을 추천 받았을 때 '연어 와사비 파스타'는 꼭 먹으라며 추천 받았어요!파스타에 생와사비라..... 혹시 코끝이 아리진 않을까 걱정했는데 묘하게 맛있었어요 ㅎㅎ 생각보다 크림과 와사비의 조합이 괜찮았고 소스의 느끼함을 와사비가 잡아주는 것 같다는~ 색다른 맛을 기대하는 분들에게 추천 !3. 봉골레 파스타음...... 이건 기대 이하였어요. 맛이 좀 기름지고 해산물 향도 덜했던 것 같아요.그래서 요건 짧게 패스 !4. 게장 볶음밥비쥬얼적으로 이색적이고 게장을 비벼서 먹었는데 생각보다 비리지 않았어요!평소 게장 좋아하고, 한식 좋아하는 분들에게 추천 !근데 파스타랑 같이 먹으려니.. 뭔가 두 메뉴의 궁합은 안맞았네요 ㅠ음식들과 함께 낮술도 한잔씩! 평일 낮에 먹는 낮술은 참 맛있어요(일탈을 꿈꾸는 직딩의 삶) 우리의 계절미각 평가는?(5점 만점에)결과적으로 늘 먹던 파스타가 아닌 새로운 맛의 파스타를 경험해서 좋았어요! ㅎㅎ(집나간 미각, 와사비 파스타로 심폐소생..) 근데 계절미각은 런치보단 디너 위주의 주메뉴들이 많더라고요. 다음엔 저녁에 한번 와보고 싶어요! 친구 또는 애인과 이색적인 분위기 속에서 디너를 즐기고 싶은 분들에게 추천합니다!아....근데 여기 조금 언덕에 있습니다^^ (다리운동 후아후아) 이렇게 든든히 배를 채우고 나왔는데도 시간이 30분이나 남아서 우리는 1분 1초까지 다 쓰고 가자는 단합으로 커피숍 '바나프레소' 입성 !(어반 테이스트는 근무시간 중 2시간을 사용할 수 있답니다) 시원한 아메리카노 마시며 눈뉴난나~~~~동갑이라 그런지연애 이야기운동 이야기이런 저런 사는 얘기가 잘 통.....하나 싶더니 마지막에 야구 얘기가 나오면서 (민수 LG vs 태욱 롯데 vs 은지 한화)우리의 어반 테이스트는 디스 아닌 디스전으로 끝이 났습니다 ㅎㅎ다음 어반테이스트 3탄도 기대해 주세요 :) 출처: https://blog.naver.com/urbanbaseinc 

블로그 첫 글에서 비트윈의 시스템 아키텍처에 대해 다룬 적이 있습니다. 시스템 구성의 미래에 대한 계획으로 멀티티어 아키텍처에 대해 언급했었는데, 이는 프로토콜을 단순화시키고 배포 자동화를 가능하게 하기 위해서 클라이언트와 비즈니스 로직을 담당하는 서버 사이에 일종의 게이트웨이를 두는 것이었습니다. 그 외에도 여러 가지 필요성이 생겨 해당 역할을 담당하는 프레젠터라는 것을 만들게 되었고 비트윈의 채팅 시스템에 적용하게 되었습니다. 만드는 과정 중에 여러 기술적인 문제들이 있었고 이를 해결하기 위한 노력을 하였습니다. 이 글에서는 비트윈 시스템에서의 프레젠터에 대해 이야기 하고자 합니다.프레젠터¶프레젠터는 일종의 게이트웨이 입니다. 기존의 시스템에서는 클라이언트들이 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]로 이메일을 주시기 바랍니다!

어딜 가나 주인공이 있기 마련이다.주목받고, 건강하고, 씩씩하며, 잘 웃고, 인기 많은 바로 그 사람.언제나 그 사람은 존재했다.어렸을 적 우리의 무대- 학급, 놀이터, 운동장-에서의 주인공은 고민할 여지도 없이 '잘 노는 아이'였다.그 '잘 노는 아이'는 얄궂게도 뭐든 잘했다.친구들과 잘 어울리고 수업도 곧잘 따라와서 선생님의 사랑도 유난히 더 받는 듯했다. 놀이를 진행하거나 놀이를 응용하기도 잘했던 걸로 기억한다. 유머러스하고 눈치가 빨라 분위기를 이끄는 역할을 했다. 아무튼 ‘잘 노는 아이’는 대체로 주인공이었다. 놀이 치료 연구소에서 실시한 연구에서 초등 500명을 대상으로 흥미로운 실험을 진행했다.놀이를 잘 하는 친구를 떠올리게 한 다음, 그 친구가 지닌 특성에 대해 구체적으로 서술하게 했다.어떤 결과가 나왔을까?또래에 의해 놀이를 잘 한다고 인지된 아동들은 신체적, 성격적, 사회적, 정서적, 인지적, 언어적 능력, 그리고 유머감각과 놀이 행동 및 재능 등 제반 발달 영역에서 압도적이게 긍정적으로 인식되고 있었다. 놀이를 잘하는 아동은 운동을 좋아하고 민첩하며, 활동적이고, 건강하고, 에너지가 많다.  놀이를 잘하는 아동은 활발하고, 착하며, 자신감이 있고, 털털하며, 적극적이고, 인내심도 있으며 경우에 따라서는 차분하다고 비춰진다.놀이를 잘하는 아동은 재미있고 유머가 있어 다른 사람을 웃게 한다. 또한 그들은 장난을 잘 치고 흉내를 재미있게 내기도 하며, 재미있는 이야기를 곧잘 한다.놀이를 잘 하는 다른 사람을 잘 배려해 주고 잘 대해주며 잘 도와주는 등 친사회적 특성으로 친구들이 많으며 친구들 사이에서 인기가 많다. 매사에 주도적이며 협동을 잘하며 건강하게 경쟁한다.놀이를 잘 하는 아동은 항상 잘 웃으며, 표정이 다양하고, 감정 표현을 적절하게 잘한다고 평가받는다.놀이를 잘 하는 아동은 기발한 생각이나 아이디어가 많으며 상상력이 풍부하다. 다양한 놀이 방법을 알고 있을 뿐만 아니라 놀이 방법을 새로이 잘 만들어 내기 때문에 색다르게 놀기를 잘한다. 재미있는 이야기나 새로운 소식 등 아는 것이 많으며 상황 판단을 잘한다 또한, 학업성적에서 매우 우수한 결과를 보여주지만 또래 친구들이 가시적으로 학업능력이 좋다고 평가하지는 않는다.놀이를 잘 하는 아동은 말이나 이야기를 잘하며 의사 발표를 잘 하고 나쁜 말을 사용하지 않으며 말의 속도가 빠른 편이고 목소리의 크기도 큰 편으로 인식된다.결론은 아이들은 잘 노는 아이에 대해서 착하고, 매력적이고, 주도적이라고 생각한다.개인적으로 필자에게 흥미로웠던 대목은 “학업성적에서 매우 우수한 결과를 보여주지만 또래 친구들이 가시적으로 학업능력이 좋다고 평가하지는 않는다”는 부분이었다.  또래 친구들이 가시적으로 학업능력을 높게 평가하지 않는다는 것은 무엇을 의미할까?"잘 노는 사람"으로 인정받는다는 것은 놀이를 승리했다, 잘 이긴다, 딱지를 많이 땄다- 와 같은 승패와 관련한 것이 아니다. 잘 논다는 것은 결국 잘 승리한다는 것을 의미하는 게 아니라 우리의 놀이를 재밌게 만들어 준다는 것을 의미한다.놀이와 같은 듯 다른 "게임"에 대해 생각해보자. 게임의 목표는 승리다.보드게임, 컴퓨터 게임이 그러하다. 이 안에서는 그들만의 매너와 소통이 분명히 있겠지만 목표 자체는 승리다. 승리 한자가 주인공이란 얘기.학업도 마찬가지다. 결과적으로 누군가 더욱 뛰어난 성과를 내고 그 능력이 명확하게 점수로, 등급으로 나뉜다.하지만 놀이는 아니다.놀이판에서는 즐기는 자가 또는 모두가 즐기도록 하는 자가 주인공이다.놀이는 우리의 사회생활과 참 닮았다. 보통은 고등학교를 마지막으로 무언가를 남들보다 잘 해서 승리하는 종류의 게임이 끝난다.수명에서 수백 명이 구성하는 조직에 속하게 되고 함께 힘을 모아 달성해야 하는 목표가 생긴다. 목표 달성이나 문제 해결을 위해 함께 머리를 맞대고 문제를 해결한다.그 과정은 끝이 없기 때문에 그 안에서 계속 재미를 찾아야 한다.또 그 과정은 사람들과 함께 만들어야 하기 때문에 관계에서 빚어지는 크고 작은 갈등도, 희열도 존재한다.다른 사람을 이기는 게 아니라 모두가 함께 이기고 즐기도록 하는 것이 진정한 의미의 승리일 것이다.고개를 들고 둘러보면 그 역할을 해내는 사람이 이 시대의 리더이며 주인공이다."우리 뭐하고 놀까?""너도 같이 할래?""그럼 이런 방법은 어때?"라 묻던 어린이."우리 함께 이런 것들을 해냅시다""같이 할까요?""이렇게 해보면 어떨까요?"하고 세상을 이끄는 어른이 될 것이라 조심스럽게 예측해본다.

최근의 서비스/애플리케이션의 개발 흐름은 멀티 플랫폼, 멀티 디바이스 시대로 넘어와 있습니다. 단순히 하나의 브라우저만 지원하면 되었던 이전과는 달리, 최근의 서버 프로그램은 여러 웹 브라우저는 물론이며, 아이폰, 안드로이드 애플리케이션과의 통신에 대응해야 합니다. 그렇기 때문에 매번 서버를 새로 만드는 수고를 들이지 않기 위해선 범용적인 사용성을 보장하는 서버 디자인이 필요합니다.REST 아키텍처는 Hypermedia API의 기본을 충실히 이행하여 만들고자 하는 시스템의 디자인 기준을 명확히 확립하고 범용성을 보장하게 해줍니다. 이번 글에선 현대 서비스 디자인을 RESTful하게 설계하는 기초적인 내용에 대해 정리하려고 합니다.REST란 무엇인가?REST는 Representational state transfer의 약자로, 월드와이드웹과 같은 분산 하이퍼미디어 시스템에서 운영되는 소프트웨어 아키텍처스타일입니다. 2000년에 Roy Fielding에 의해 처음 용어가 사용되었는데, 이 분은 HTTP/1.0, 1.1 스펙 작성에 참여했었고 아파치 HTTP 서버 프로젝트의 공동설립자이기도 합니다.REST는 HTTP/1.1 스펙과 동시에 만들어졌는데, HTTP 프로토콜을 정확히 의도에 맞게 활용하여 디자인하게 유도하고 있기 때문에 디자인 기준이 명확해지며, 의미적인 범용성을 지니므로 중간 계층의 컴포넌트들이 서비스를 최적화하는 데 도움이 됩니다. REST의 기본 원칙을 성실히 지킨 서비스 디자인은 “RESTful 하다.” 라고 흔히 표현합니다.무엇보다 이렇게 잘 디자인된 API는 서비스가 여러 플랫폼을 지원해야 할 때, 혹은 API로서 공개되어야 할 때, 설명을 간결하게 해주며 여러 가지 문제 상황을 지혜롭게 해결하기 때문에 (버전, 포맷/언어 선택과 같은) REST는 최근의 모바일, 웹 서비스 아키텍처로서 아주 중요한 역할을 하고 있습니다.중심 규칙REST에서 가장 중요하며 기본적인 규칙은 아래 두 가지입니다.URI는 정보의 자원을 표현해야 한다.자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다.1번 사용자에 대해 정보를 받아야 할 때를 예를 들면, 아래와 같은 방법은 좋지 않습니다.GET /users/show/1 이와 같은 URI 방식은 REST를 제대로 적용하지 않은 구 버전의 Rails에서 흔히 볼 수 있는 URL입니다. 이 URI은 자원을 표현해야 하는 URI에 /show/ 같은 불필요한 표현이 들어가 있기 때문에 적절하지 않습니다. 본다는 것은 GET이라는 HTTP Method로 충분히 표현할 수 있기 때문이죠. 최근의 Rails는 아래와 같이 변경되었습니다.GET /users/1 자원은 크게 Collection과 Element로 나누어 표현할 수 있으며, 아래 테이블에 기초한다면 서버 대부분과의 통신 행태를 표현할 수 있습니다.ResourceGETPUTPOSTDELETERESTful Web Service HTTP methodsCollection URI, such as http://example.com/resources/컬렉션에 속한 자원들의 URI나 그 상세사항의 목록을 보여준다.전체 컬렉션은 다른 컬렉션으로 교체한다.해당 컬렉션에 속하는 새로운 자원을 생성한다. 자원의 URI는 시스템에 의해 할당된다.전체 컬렉션을 삭제한다.Element URI, such as http://example.com/resources/item17요청한 컬렉션 내 자원을 반환한다.해당 자원을 수정한다.해당 자원에 귀속되는 새로운 자원을 생성한다.해당 컬렉션내 자원을 삭제한다.이 외에도 PATCH 라는 HTTP Method에도 주목하시기 바랍니다. PUT이 해당 자원의 전체를 교체하는 의미를 지니는 대신, PATCH는 일부를 변경한다는 의미를 지니기 때문에 최근 update 이벤트에서 PUT보다 더 의미적으로 적합하다고 평가받고 있습니다. Rails도 4.0부터 PATCH가 update 이벤트의 기본 Method로 사용될 것이라 예고하고 있습니다.입력 Form은 어떻게 받아오게 하지?위의 예시를 통해 많은 행태를 표현할 수 있습니다만 새로운 아이템을 작성하거나 기존의 아이템을 수정할 때 작성/수정 Form은 어떻게 제공할지에 대한 의문을 초기에 많이 가집니다.정답은 Form 자체도 정보로 취급해야 한다는 것입니다. 서버로부터 “새로운 아이템을 작성하기 위한 Form을 GET한다”고 생각하시면 됩니다. Rails 에선 기본적인 CRUD를 제공할 때 아래와 같은 REST 인터페이스를 구성해줍니다.HTTPVerbPathactionused forGET/photosindexdisplay a list of all photosGET/photos/newnewreturn an HTML form for creating a new photoPOST/photoscreatecreate a new photoGET/photos/:idshowdisplay a specific photoGET/photos/:id/editeditreturn an HTML form for editing a photoPUT/photos/:idupdateupdate a specific photoDELETE/photos/:iddestroydelete a specific photo모바일 환경에 따라 다른 정보를 보여줘야 한다면?접속하는 환경에 따라 다른 정보를 보여줘야 할 때가 있습니다. 가령 모바일 디바이스에서 볼 때 다른 사용자 인터페이스를 제공한다든지 하는 경우인데요. 일부 애플리케이션은 독립적인 모바일 웹서비스를 개발한 후 단지 이를 이동시켜주기만 할 때가 있는데, 이는 어떤 경우에 좋지 못한 사용성을 보여줍니다. 모바일 뷰와 일반 웹페이지 뷰의 URI가 달라서 같은 정보를 공유할 때 각 환경에 적절한 디자인과 인터페이스로 보이지 않기 때문입니다.모바일에서 블로그를 구경하던 도중, 컴퓨터를 이용하고 있는 친구에게 자신이 보고 있는 내용을 보내주고 싶을 때가 있습니다. 티스토리 블로그는 모바일 뷰의 URI가 기존 URI와 달라서, 친구가 해당 URI를 데스크탑에서 열어도 모바일에 최적화된 정보를 받을 수밖에 없게 됩니다. 이 URI를 데스크탑에서 열어보시기 바랍니다.REST 하게 만든다면 URI는 플랫폼 중립적이어야 하며, 정보를 보여줄 때 여러 플랫폼을 구별해야 한다면 Request Header의 User-Agent 값을 참조하는 것이 좋습니다. 예를 들어 iPhone에서 보내주는 User-Agent 값은 아래와 같습니다.Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3 대부분 브라우저, OS 플랫폼은 HTTP Request를 보낼 시 보내는 주체에 대한 설명을 User-Agent에 상세하게 포함하여 통신하고 있기 때문에 요청자의 환경을 정확히 알 수 있습니다.버전과 정보 포맷을 지정할 수 있게 해야 한다면?오픈 API를 제공하거나, 클라이언트가 항상 최신 버전을 유지할 수 없는 환경이라면 서버에서 버전 협상을 지원해야 합니다. 서버가 버전 협상을 지원한다면 최신 버전으로 업데이트가 되더라도 구 버전의 정보 요청에 하위 호환하게 하여 서비스 적용범위를 넓게 유지할 수 있습니다. 이와 함께 클라이언트가 html로 정보를 받을지, json으로 받을지, xml로 받을지 선택할 수 있다면 더욱 좋을 것입니다.Header의 Accept 헤더를 이용해서 요청 환경에서 정보의 버전과 포맷을 지정할 수 있게 합니다. 아래는 Github API에 요청 시 쓰는 Accept 헤더입니다.application/vnd.github+json vnd.는 Vendor MIME Type으로, 서비스 개발자가 자신의 독자적인 포맷을 규정할 수 있게 HTTP 표준에서 제공하는 접두어입니다. vnd. 이후에 서비스 제공자 이름을 쓴 후, +로 문서의 기본 포맷을 표현해줍니다.이에 더해, Accept 헤더는 파라미터를 받을 수 있습니다. 많은 REST 지지자들은 이 파라미터를 이용해 버전 명을 지정하는 것을 권장합니다.vnd.example-com.foo+json; version=1.0 Ajax와 REST최근 빠른 속도의 웹서비스를 구현하기 위해 서비스 전체를 Ajax 통신으로 구동되게끔 HTML5 애플리케이션을 만드는 일이 많습니다. 서비스 전체를 Ajax 기반으로 구동되게 개발한다면 중복된 콘텐츠를 여러 번 전달하지 않아도 되고, 브라우저 렌더링 과정이 간소화되므로 더욱 빠른 서비스를 구축할 수 있습니다. 하지만 Ajax 기반의 서비스는 초기에 URL에 관련된 문제가 있어 REST한 서비스를 만들 때 애로사항이 있었습니다. 콘텐츠가 바뀌어도 URL은 그대로여서 친구에게 내가 보고 있는 콘텐츠를 보여줄 방법이 불편했기 때문이죠.최근엔 두 가지 방법으로 이를 보완할 수 있습니다. 첫 번째는 #! 기법으로, 구형 브라우저에서도 # 이하의 URL을 Javascript로 자유자재로 변경할 수 있다는 점을 이용한 방법입니다. 방법은 아래와 같습니다.Ajax 통신을 통해 이동되는 페이지의 URI는 현재 URI의 #! 이후에 붙인다.페이지가 처음 열릴 때, #! 이후로 URI가 붙어있다면 해당 URI로 redirect를 해준다.이와 같은 방법으로 Ajax 서비스를 만들면, 페이지를 이동한 이후에 URL을 친구에게 복사해서 전달해주어도 친구가 내가 보고 있는 콘텐츠를 볼 수 있으며, 구글에서 수집할 때 해당 #! 이하의 URL을 판별해서 제대로 수집해주기 때문에 검색엔진에도 성공적으로 노출될 수 있습니다.하지만 위 방법의 단점은 1. 상대방이 Javascript를 지원하지 않는 브라우저를 이용하거나 Javascript 기능을 꺼 놓았을 때 제대로 된 콘텐츠를 볼 수 없다는 것이며, 2. URI가 몹시 보기 지저분해진다는 것입니다. 두 번째 방법은 pushState라는 새로운 표준을 이용한 방법으로, javascript의 pushState를 통해 Ajax 통신 후에 변경된 컨텐츠의 URI을 제대로 바꿔줄 수 있습니다. 하지만 최신 표준을 지원하는 브라우저에서만 정상적으로 구동되기 때문에, 하위 호환에 신경을 써야 한다는 단점이 있습니다. pjax같은 프로젝트들이 하위 호환을 포함하여 이런 구현을 쉽게 하도록 도와주고 있습니다.언어언어별로 다른 URI의 서비스를 가지는 서비스들을 종종 볼 수 있습니다. 역시 좋지 못한 설계입니다. 한국어로 작성된 컨텐츠를 보고 있는 중 해당 콘텐츠를 미국인 친구에게 보여줄 일이 생겼다고 가정해봅시다. 단순히 URI를 복사해서 주는 것으로는 미국인 친구에게 내가 보고 있는 정보를 제대로 전달해줄 수 없다면 아주 불편할 것입니다.Request Header의 Accept-Language는 받고자 하는 언어를 명시하고 있습니다. 대부분 브라우저, OS 플랫폼은 사용자가 즐겨 쓰는 언어를 이 Header에 포함하여 요청을 만들고 있기 때문에, 해당 Header를 참조하여 그에 걸맞은 언어를 제공해주는 것이 가장 정확한 서비스를 제공해줄 수 있습니다.물론 이 방법만으로 부족한 점이 있습니다. 자신의 주 언어와 다른 언어의 세팅을 가지고 서비스를 이용하는 사용자도 있으며, 몇 가지 이유 때문에 해당 사이트만, 해당 순간에만 다른 언어로 정해서 보고 싶을 수 있기 때문입니다. 아쉽게도 일반적인 브라우저에서 언어 변경을 하는 인터페이스는 매우 불편하고 찾기 어렵게 되어있기 때문에, 서비스에서 이에 대한 추가 인터페이스를 제공해주지 않으면 일부 사용자를 잃거나 불편하게 할 수 있습니다. 보통은 Accept-Language보다 우선해서 적용하는 언어 옵션을 세션에 저장할 수 있게 하고, 이에 대한 변경 인터페이스를 서비스에서 제공해주는 식으로 문제를 해결할 수 있습니다.마치며REST는 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화해주고, HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해줍니다. 이번 글에서는 REST하지 않은 서버 설계를 통해 생길 수 있는 실질적인 문제들을 제시하고 REST 아키텍처가 이를 어떻게 해결해주는지 함께 보았습니다.‘REST가 완전한 정답이냐?’라고 한다면 이에 대해서는 아직 논의가 남아있습니다. 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 분명히 있으며 (PUT, DELETE를 사용하지 못하는 점, pushState를 지원하지 않는 점) 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값은 왠지 더 어렵게 느껴지기도 합니다.만일, 만들고 있는 서비스의 API가 널리 쓰여야 한다면 REST를 완전하게 적용한 디자인이 더 독이 될 수 있습니다. 많은 개발자는 별로 똑똑하지 못하며, HTTP 프로토콜에 대한 이해가 부족하여서 API가 어렵게 느껴질 수 있기 때문입니다. 그러므로 Google을 포함한 많은 기업의 서비스 API가 REST 스타일을 완전히 따르고 있진 않습니다.하지만 그럼에도 REST가 중요한 점은, 이를 제대로 구현하는 것이 서비스 디자인에 큰 부가이익을 가져다 줄 수 있으며, 많은 현대의 API들이 REST를 어느 정도로 충실하게 반영하느냐를 고민할 뿐이지 REST를 중심으로 디자인되고 있다는 점은 분명하기 때문입니다. REST를 얼마나 반영할 지는 API가 어떤 개발자를 범위에 두는지, 개발 기간이 얼마나 되는지, 함께 하는 동료의 역량은 어떠한지 등을 고려해서 집단마다 다르게 반영하게 될 것입니다.#스포카 #개발 #개발자 #개발팀 #꿀팁 #인사이트 #REST

2017년 6월의 마지막날. 프라이머 배치 11기 데모데이에 카바조가 참여하였습니다. 프라이머에 참여하여 한단계 아니 몇단계 성장할 수 있는 기회였습니다. 아산나눔재단의 후원이라 마루180에 입주한 저희에 모습을 담아주셨네요!^^카바조를 시작할 때의 초심을 잊지않도록 조심하고 노력하며 이끌어 가겠습니다.더욱 화이팅 하겠습니다~!~!#카바조 #데모데이 #경험공유 #발표 #프라이머 #마루180

밍케터)  인터뷰에 임하시는 각오 부탁드려요! 말량광이) 인터뷰를 그만할 때가 되지 않았나..ㅎㅎ아니에요! 열심히 해야죠. 하하!밍케터)  (밍무룩...)제1장. 키보드와 함께하는 손_ 디자인의 원천밍케터) 회사에서 하시는 일 소개 좀 해주세요.말량광이) 음..일단 웹 디자인, 앱 디자인, 캐릭터 디자인 등 각종 디자인을 도맡아 하고 있습니다.디자인 결과물 중 빙산의 일각.JPG  아 각종 쇼핑도 도맡아 하고 있습니다. 오늘은 화이트 보드를 구매했습니다! 회의실에 걸 예정인데 배송비가 비싸서 고민이네요… 흠!쇼핑 결과물 중 빙산의 일각.JPG 밍케터)  자소설닷컴 디자인 철학이 궁금합니다!! 알려주세요!!말량광이) 자소설닷컴 초기에는 ‘신뢰도’에 중점을 두었어요! 아무래도 개인의 소중한 정보가 들어있는 곳이니까요~이번 시즌에 사이트를 리뉴얼 하면서 분위기를 다르게 꾸몄어요.지금의 자소설닷컴은 또래 같은 느낌이에요.“무겁고 딱딱”에서 “재미있고 유쾌”로 정리가 되었죠!밍케터)  네네 동의합니다! (끄덕끄덕)자소설닷컴 메인컬러에도 변화가 있던 것으로 아는데요! 말량광이) 가장 초반에는 노란색+회색이었구 그다음 버전에는 남색+주황색이었어요! 현재는 주황색 + 회색입니다! 밍케터)  혹시 도입해보고 싶은 색 있으신가요?말량광이) 형광색이요.(단호) 현재처럼 기능에 최적화된 사이트가 아니라면 꼭 써보고 싶어요.밍케터)  혹시 사이트 디자인을 변경하시는 과정에서 재미있었던 에피소드 있으신가요?말량광이) 자소설닷컴 초기 작업할 때는 그래픽에 빠져있었어요.유행에 따라서 그래픽을 화려하게 넣었었죠!사람들은 이쁘다 이쁘다 했는데 정작 쓰는 사람들은 많이 튄다고 느꼈었나 봐요!한 번은 사이트 사용자분 중에 이직을 준비하시던 분이 회사에서 사이트를 몰래 사용하고 있는데 '너무 눈에 띈다'라는 의견을 주셨던 적도 있습니다!밍케터)  자소설닷컴의 모든 디자인을 전적으로 담당하고 계시잖아요~? 가장 힘든 디자인과 가장 즐거운 디자인을 꼽는다면?말량광이) 재미있는 디자인은 얼마 전 진행했던 유니브 엑스포 제작물 같은 것들이요! 유니브 엑스포 제작 결과물 중 빙산의 일각.JPG 재미없는 디자인은 홈페이지 디자인이요… ㅎㅎㅎ더 이상 넣을 공간이 없는데 중간중간 기능추가가 되니까 꾸역꾸역 넣고 있습니다...ㅎㅎ 채팅도 중간에 넣었죠… ㅎㅎㅎㅎㅎ그런데 대표님이 광고를 넣는다고 하셔서 당황스러웠어요ㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎ최대한 티 안나게 넣어야죠! 밍케터)  디자이너님으로서 팀원들을 색으로 표현해 주세요! 간단한 이유와 함께!  문케터 문규 -> 철쭉"이상하게 발랄해요. 그냥 발랄이 아니고, 엉뚱하게 발랄해요"주케터 주연 -> 라임"상상도 할 수 없을 만큼 발랄해요. 문규씨와 주연씨의 발랄함 정도는 비슷한 것 같아요"밍케터 민지 -> 빨강"딱 부러진다는 느낌이에요. 열심히 하기도 하고, 말투나, 일 처리도 그렇구요" 데이터 초롱 -> 브라운 "차분하니 묵직한 느낌이 있어요.가벼운 스타일의 사람이 아니에요."pm 상호 -> 남색"진중하고 발랄함의 경계에 있는 사람이에요.남색이 그런색이에요" 개발 선빈 -> 겨자"말할 때 핵심을 톡톡 찌르는게 있어요.그리고 알게 모르게 웃겨요." 대표 수상 -> 초록색(feat. 대표로서)"성실한 느낌이요. 회사에서의 대표님 색은 바름, 착한 대표님, 청년의 모습이에요"대표 수상 -> 베이비 블루(feat. 남친으로서)             "애같아요. ㅎㅎ"  제2장. 취준이_제 2의 인격밍케터) 자소설닷컴의 공식 마스코트 취준이 소개해주세요!말량광이) 캐릭터 디자인을 한 번도 해본 적이 없어요 사실! 파워퍼프 걸 참조해서 그래픽으로 만들어 놨던 애를 발전시켰죠!초반엔 참 미국스러운 친구였어요.다중이 취준이.JPG 밍케터)  취준이 공식 이모티콘화에 대해서 어떻게 생각하시는지?말량광이) “~~~너무 귀찮아~~~~”농담이구요~ 사업화해서 수익을 5:5로 나누면 할 마음이 있습니다.ㅎㅎ밍케터)  취업 못 하게 생긴 취준이에게 격려의 한 마디 해주세요!말량광이) "넌 머리스타일만 바꿔도 괜찮을 거야 ^^" 사실 열심히 하는 순.진.한 취준생.바로 우리네 모습 아니것어요~밍케터)  (급 구수한 마무리다)    제3장. 입_철두철미한 피드백의 근원밍케터)  매일 문케터(=페이스북 콘텐츠 담당)에게 디자인 피드백을 해주시고 계시잖아요? 디자이너님께 문케터의 존재란?말량광이) 우선 가르쳤던 사람 중에는 제일 발전속도도 빠르고, 퀄리티 좋고, 의욕 넘치고 그렇습니다.ㅎr….그런데 고집이 있어요. 예를 들면 핑크색, //사선// 같은 것들? 밍케터)  가장 고쳐주고 싶은 점 한 가지만 꼽으신다면요?말량광이) 글자 자간 행간을 맞춰주고 싶어요. 에이 그래도 다 괜찮은 편이에요~아 ,그리고 선 두 개 쓰는거?에이 그래도 진짜 다 괜찮은 편이에요~아, 그런데 가독성도 더 높게 해주고 싶고…밍케터)  (문케터의 콘텐츠는 다 괜찮은 편이지만 핑크, 사선, 선 두개, 자간과 행간, 가독성 부분에 고칠 점이 있다.보고있나 문케터?)밍케터)  제보를 받은 부분이 있습니다. 데이터 전문가 초롱 씨에게 항상 메이크업을 해주고 싶다고 하셨다던데, 어떤 메이크업을 해주시고 싶으셨나요?말량광이) 한 번 해드린 적 있어요!초롱 씨가 아이라인을 그리고 왔는데 ‘아, 저거 더 예쁠 수 있을 것 같은데…’란 생각이 들더라구요.집에 가는 초롱씨에게 세미스모키를 해줬죠.ㅎㅎ결과적으로 맘에 들었는지 알 수 없어요...ㅎㅎ*그래서 초롱초롱초롱씨에게 제가 물어봤습니다*알 수 없는 그녀의 속마음.jpg밍케터)  디자인뿐만 아니라 마케팅 쪽에 대한 감각도 뛰어나신 것 같아요. 평소 디자인과 마케팅 분야에서 영감을 얻기 위해 어떤 노력을 하고 계신가요?말량광이) 마케팅을 배운 적은 학교 다닐 때 수업을 들은 것 외에는 없어요. 그런데 사업 시작하면서 다 같이 마케팅을 해야 하는 상황이어서 책도 읽고 타 서비스 분석을 많이 했어요. 요즘은 마케팅 동향도 파악하고, 브랜딩 쪽으로 많이 공부하고 있습니다.디자인은 계속 봐야 해요. 순수 예술 전공이라 친구들과 그림얘기도 많이 나누고, 다양한 디자인도 많이 보구요.음...디자인을 본다기보다 예술을 많이 보고 있어요. 요즘은 경계가 뚜렷한 편은 아니에요!  제4장. 발가락_인간 김상은의 삶의 애환밍케터)  발가락 부상 중이십니다. 어쩌다 이렇게 되신 것인지…말량광이) 회사의 미래가 달린 일이었어요.제 노트북에는 회사 디자인과 관련된 모든 것들이 다 들어있어요.즉, 노트북을 잃으면 모든 것을 잃는 것이죠.그런 노트북이 바닥에 떨어져 버려서…제 발을 내어주었습니다... 불가피한 선택이었고, 지금도 옳다고 믿고 있습니다.밍케터) (보고 계시나요? 대표님?) 삶의 무게_뒷모습.JPG  밍케터) 또 제보를 받은 부분이 있습니다. 신체와 관련된 에피소드가 많던데… #강릉#방충망#파괴왕 이게 다 뭐죠..?말량광이) 아?? 이거 어떻게 알았어요???? 하하하하pm 님이 얘기했어요? 하하하하하아니~ 야외에서 고기를 굽다가 옆에서 불이 났어요. 물을 뿌려야 하니까 방안으로 들어가려다가 방충망을 못 봤어요!팅겨 나왔습니다! 하하! 제5장. 속눈썹_나의 베스트 OF 베스트 부위속눈썹이요.컬링이 정말 잘 되는 속눈썹이에요.한 번 올라가면 내려가지 않아요.착한 속눈썹이죠. ㅎㅎ   결론. 앵커리어 공식질문1. 나에게 앵커리어란?언제 여기까지 왔지? 시작은 집 앞에 카페였는데, 사업을 하고 있고 회사도 컸어요.초반엔 정말 동아리의 느낌이었는데, 지금은 회사 같은 느낌이 들어요.성장이 눈에 보여서 좋습니다. 2. 자소설닷컴을 한 마디로 표현하면?취준생의 와이파이.#앵커리어 #팀원소개 #인터뷰 #팀원자랑 #기업문화 #조직문화

 약 2주전, 어반베이스의 독특한 문화 '백일잔치'를 소개해드렸었죠!백일잔치는 어반베이스의 가족이 되어 무사히 잘 적응하시고 건강하게 100일을 보낸 것을 다 함께 축하해 주는 자리인데요.벌써 두번째 100일잔치가 돌아왔습니다!올해 하반기 입사자가 많다보니 백일 잔치를 굉장히 자주하는 느낌적인 느낌. (담주에 세번째 100일잔치가 있다고 하네요?)일단 두 번째 백일잔치 이야기부터 보시죠! 점심 시간에 맞추어 라운지 공간에 음식 세팅이 완료되었습니다!  주인공 아님 1주인공 아님 2 이번 100일 잔치의 메뉴는 '치킨'치맥파티입니다!!오예!내적 댄스가 폭발합니다오늘의 주인공 성민님과 주희님이 직접 고른 메뉴라고 하는데요, 주인공들의 안목, 인정 또 인정합니다.지난번 피자가 조금 적었다는 어반인들의 의견을 적극수렴하여 이번엔 2인 1닭으로 아주 푸짐하게 준비를 했습니다!다양하게 맛보시라고 양념, 핫후라이드. 뿌링클, 맛초킹까지!!! 치킨만 먹으면 허전하니까 맥주와는 찰떡궁합인 프렌치후라이도 준비하였습니다 하하점심에 치킨을 이렇게 푸짐하게 종류별로 맛볼 수 있다니! 어반베이스 백일잔치 아니고서 또 어디서 이렇게 먹겠어요! 역시 치맥이 진리아니겠습니까. 맥주(와 콜라)도 함께 준비되었습니다!치맥파티 이야기가 너무 길었죠? 이제 치킨 이야기는 잠시 접어두고 메인 이벤트를 해야죠! 주인공들을 위한 1인 1케익을 준비했습니다. (100일을 축하하는 의미로 맛있게 드시라고 준비했지만 결국 어반인들의 배로 몽땅 들어갔다는 아름다운 이야기..)케잌도 준비가 되었으니 성민님과 주희님을 모시고 축하노래도 불렀습니다.주희님 성민님 축하드려요!주희님의 고깔모자, 성민님의 빨간 리본 넘나 찰떡인 것..! 자주 해주세요! (?)귀엽게 하트도 한 번 해주시고이렇게 다 같이 한 공간에 모여 백일잔치(라 쓰고 치맥파티라 읽는다)를 하니 참 뜻깊은 시간이 아닐 수 없습니다. 열렬한 축하를 받으며 이렇게 2번째 100일잔치도 무사히 마무리가 되었습니다.백일잔치라니, 점심시간에 치맥이라니, 다 어반베이스가 아니면 경험할 수 없는 것들이죠. 다음 메뉴는 과연 무엇일까요? 괜히 기대가 됩니다. 하하어반베이스의 100일잔치는 계속 이어집니다. 계속 기대해주세요!   출처: https://blog.naver.com/urbanbaseinc 

안녕하세요, 여러분! 크로키닷컴 입니다. :-)오늘은 지그재그 팀이 사용하고 있는 기술 Typescript 및 GraphQL에 대해 낱낱이 파헤쳐보려고 합니다.특별히 크로키닷컴에 합류하면서 Typescript와 GraphQL을 처음 접하고 빠르게 적응하신 개발자 세 분, 그리고 오늘의 특별MC! 줄기세포 개발자 형래님(크로키닷컴을 소개합니다#5 참고)을 모셨는데요.지극히 현실적이고 실무적인, 개발자라면 궁금하고 공감할 수 밖에 없는 이야기들을 지금 시작합니다~!여러분, 함께 채팅에 참여해보니 어떠셨나요? 같은 개발자의 입장으로서 공감하셨던 분들도 계실 수 있고, 혹은 어떤 분야에서든 새로 도전해보는 데 주저하거나 고민이 있으신 분들도 있으셨을 텐데요, 모든 분들께 이 인터뷰가 좋은 영향으로 다가왔으면 좋겠습니다. :-) 모두 도전해보세요!지그재그에서는 누구보다 활발하게 채용을 진행하고 있습니다. 지그재그 팀과 함께, 수면 아래 숨겨진 가치를 찾아내는 경험에 동참할 팀원을 꼭 모시고 싶습니다 :-) 궁금하신 점은 언제나 [email protected] 또는 http://facebook.com/zigzagcareer로 연락 주세요!더 많은 공고는 채용 사이트에서 확인 가능합니다! >>> 채용 사이트 바로가기

제품을 담당하는 팀이 일하는 방식은 제품 그 자체에 영향을 줍니다. 어떠한 기능을 어떤 주기로 사용자에 배포할 것이냐에 대한 결정을 하는 과정이기 때문에 구체적인 결과물에 영향을 끼치기도 하지만 누가 기능을 만들고 디버깅 하고 그 업무에 대한 조직의 시각에 따라 결과적으로는 제품의 품질에도 영향을 미칩니다.구태의연한 말이지만 테크 업계에서 일하는 방식에 있어 정답은 없습니다. 제품과 조직은 끊임없이 변화하고 이에 맞추어 일하는 방식도 바뀌어야 하기 때문에 지난 해에 불합리하다고 여기던 방식이 올해는 검토해 볼 만한 것이 될 수도 있습니다. 일하는 방식 그 자체도 협의를 거쳐 지속적으로 개선하는 과정이 필요합니다.일하는 방식과 함께 제품 그리고 조직마다 프로덕트 매니저의 역할과 권한도 바뀝니다. 비즈니스에 제품이 기여하는 정도에서부터 조직 내 이해관계자와의 관계까지 제품과 조직의 모든 요소가 프로덕트 매니저의 일하는 방식을 바꿉니다. 스포카 프로덕트 매니저의 경우, 서비스 백로그 관리의 역할도 담당하기 때문에 유동적인 일하는 방식에 따른 결과는 제품에 다시금 반영됩니다.이번 샌프란시스코 테크 업계 인터뷰는 위와 같은 가정 하에 ‘스포카는 앞으로 어떤 방식으로 일할 것인가’라는 질문에 대한 참고할 사례를 수집하기 위하여 진행하였습니다. 닭과 계란 문제일 수 있지만 이것은 ‘스포카는 어떤 제품을 만들고자 하는가’하는 고민과 맞닿아 있습니다.인터뷰는 총 5회에 걸쳐 아래와 PM 분들과 진행 되었습니다. 흔쾌히 인터뷰에 응해 주신 모든 분들께 감사드립니다. 각 인터뷰이와 나눈 이야기 중 인상적이었던 부분을 발췌하여 2개의 포스팅에 걸쳐 공유하겠습니다.Stephanie Shum(Director Product Management at Facebook)David Park (Refereum COO)Michael Hsu (Product Manager at FiveStars)Chris Nguyen (VP Product at Bleacher Report)홍성철 (Product Manager at Udemy)정대영 (Product Manager at Intuit)Stephanie Shum(Director Product Management at Facebook) & David Park (Refereum COO)좌측에서부터 Stephanie Shum, 옥지혜, David Park제품팀에 대한 동기부여는 PM의 중요한 역할 중 하나입니다. 팀에의 동기부여를 어떻게 하나요?S: 모든 제품팀의 구성원은 실제 사용자가 사용하는 제품을 만들고 그것이 비즈니스 임팩트가 있을 때 신나게 일할 수 있다. 그리고 제품이 전달하는 가치가 유의미하고 수익을 창출할 때 즐거워한다. 실제 사용자를 만날 수 있는 기회를 제공하고 팀에서 작업한 내용의 비즈니스 임팩트를 지속적으로 공유해야 한다.D: 엔지니어로 일할 당시에 중요하다고 생각하지 않는 것을 만들고 심지어 배포도 하지 못했을 때 가장 의욕이 떨어졌다. 진행 중인 작업의 사업적인 의미를 알리거나 테스트를 진행하는 이유를 팀에 설명할 수 있어야 한다. 사람들은 똑똑하고 쓸모 없는 것을 만드는 일을 싫어한다. 엔지니어를 이해하는 것은 매우 중요하다. 모든 엔지니어와의 원온원 면담을 진행하여 팀의 상태를 알고 그들이 행복할 수 있도록 노력해야 한다.S: 사람을 움직이는 것이 무엇인지 알아야 한다. 어떤 사람은 제품에 대한 스토리텔링에 흥미를 가지기도 하고 데이터 기반의 설득이 효과적인 사람도 있고 신기술에 관심을 보이는 사람도 있다. 나는 각자의 자기효능감을 느낄 수 있도록 실제 사용자와 대면하는 경험을 주는 것이 중요하다고 생각한다.제품팀이 잘 하고 있는지에 대하여 어떠한 잣대로 평가하나요?S: 제품팀이 행복하고 제품이 목표를 달성하고 있다면 잘 하고 있는 것이다. 페이스북은 서로에 대한 피드백에 대하여 열린 편이라 의견 교환이 빠르게 자주 이루어진다. 제품팀의 직무 만족도에 있어 업무 외적인 부분도 PM이 관장하는 영역이다. 이를테면 모종의 이유로 팀의 분위기가 침체 되었을 때 팀 전체 티타임을 가지면서 휴식할 수 있도록 유도하는 것도 PM의 역할이다. 어찌 보면 PM의 역할은 파티 플래너와 같다.D: 제품팀의 모든 평가는 제품의 비즈니스 임팩트에 달려있다. 유능한 피엠은 적절한 시점에 제품에 필요한 기능을 배포하는 데에 있다.제품의 목표를 달성하지 못했을 때의 경험을 공유 해주세요.S: 목표 달성을 하지 못함으로 인해서 무엇을 얻었는지가 명확하다면 그것은 실패가 아니다. 이를테면 페이스북의 경우, 매해 안정적으로 셧다운 했거나 유의미한 실패를 한 팀의 PM에게 상을 준다. 특정 팀은 수립된 전략에 따라 제품을 만들었다. 결과적으로는 목표를 달성하지 못했는데 개발 과정에는 문제가 없었으나 수립된 전략의 재검토가 필요하다는 결론이 났다. 그 팀의 PM이 그 해의 수상자였다.기술 조직이 아닌 팀과의 커뮤니케이션은 쉽지 않습니다. 영업 조직과의 커뮤니케이션에 있어 팁이 있나요?S: 제품팀의 인원이 주기적으로 현장에서 실제 사용자와 주변환경을 마주할 수 있도록 하자. 영업 조직에게 제품팀이 영업환경에 대하여 진지하게 생각한다는 것을 보여줄 필요가 있다. 반대로 영업과 사업개발 조직은 사용자 피드백의 필터가 되어야 한다. 이들은 수많은 의견을 청취하지만 모든 내용을 제품팀에 전달하지 않아야 한다. 비즈니스상 필요하다고 생각하는 몇 가지를 추려 제품팀에 전달하고 제품팀은 이를 실행할 수 있는 계획을 세우는 일을 담당한다. 서로의 일에 대한 존중과 공감 그리고 제품과 사용자와의 밀접한 관계를 언제나 염두에 주는 것이 중요하다.D: 인정 역시 중요하다. 제품팀의 인원을 포함하여 기술 조직이 아닌 팀과의 협업이 있는 프로젝트가 런칭한 경우, 모두가 볼 수 있는 메일 등을 통해 감사를 전하는 것도 팁이다.Michael Hsu (Product Manager at FiveStars)Fivestars 인터뷰 진행을 위해 게스트 체크인 중스스로가 유능한 PM이라는 것을 어떤 잣대로 평가 하나요?M: PM의 역할과 권한은 제품마다 그리고 조직마다 모두 다르다. 과거의 경험을 미루어 볼 때, 회사의 규모를 불문하고 PM은 그 자신이 제품의 성공을 책임 지는 사람이다. 따라서 구체적으로 무슨 일을 하는지 보다는 제품이 성공하기 위해서라면 다양한 일을 해야 한다.나는 3가지를 중점적으로 생각한다 - “제품(팀)이 사업목표에 기여하고 있는가”, “제품(팀)이 각 고객에게 유의미한 가치를 전달하고 있는가”, “각 팀(원)이 자신이 이루고자 하는 바를 달성하고 있는가”. 자원이 한정적이라는 것을 언제나 잊어서는 안된다. 최대의 비즈니스 임팩트를 낼 수 있는 선택을 해야 하고 이를 하기 위해 업무에 우선순위를 부여함에 있어 단호 해야 한다.현재 담당하고 있는 팀의 구성은 어떻게 되어 있나요?M: 제품팀만 두고 보았을 때, 전체 인원 중 10%가 운영만을 전담하는 팀이다. 영업인원 대비 비율은 1:7 정도에 해당한다. 이외의 팀은 각자 새로운 기능을 만드는 업무를 담당한다. (서비스 특성 상 버그가 많을 수 밖에 없는데, 운영 팀의 동기부여는 어떻게 하는지?) 우리 조직의 경우 신규 기능 개발 보다 기존 서비스 유지보수에 엔지니어들이 관심이 많다. 실제 사용자가 사용하는 것을 보고 왔을 때는 더욱 그러한 편이다.조직 내 PM이 모자라는 상황일 때 어떤 방식으로 일할 수 있을까요?M: 권한을 위임한다. 유저 스토리 작성, 기능 요구사항 구체화 하는 일 등 가시화 되지 않는 일지만 반드시 진행해야 하는 일을 팀원에게 위임하는 방법이 있다. 이 때 각 기능의 개발을 위한 비용과 시간 계산 등에 대한 책임도 함께 질 수 있도록 하는 것이 좋다.기능에 대한 요구사항은 어떻게 수렴하나요?M: 각 팀 단위로 스프린트에서 진행할 티켓을 정하고 백로그 관리를 담당하게 된다. 이 절차는 기술적인 요구사항이 한정적인 자원 안에서 처리 된다는 점과 비즈니스 임팩트의 여하에 따라 우선순위를 정하는 협상의 과정이라는 것을 가시화 한다는 점에서 유효하다. 요구사항을 발의 하는 사람은 어떠한 배경에서 해당 기능을 제안을 하고 그것이 가져올 비즈니스 임팩트에 대한 내용을 포함하여 발의할 수 있어야 한다.우선순위를 결정함에 가장 중요한 잣대는 비즈니스 임팩트를 얼마나 발생시킬 수 있느냐이다. 운영팀이 대응할 버그를 결정함에 있어서도 데이터를 기반으로 한다. 신규 기능에 대한 요구사항은 이 회의체에 접근하기 이전에 필터링 되어 발의되며 마찬가지로 기존 업무와의 우선순위를 조정하여 스프린트 항목을 정한다.Chris Nguyen, 홍성철님과 정대영님의 인터뷰와 인터뷰를 통해 얻은 인사이트는 다음 포스팅에서 다룹니다. 마지막으로 스포카는 현재 제품을 함께 만들어 나갈 PM을 채용 중입니다. 관심 있으신 분들의 많은 지원 부탁 드립니다.#스포카 #기업문화 #조직문화 #팀원소개 #인터뷰 #회사소개

업계에서는 대기업이나 공공기관 등의 데이터 분석 수요가 커지면서 빅데이터를 다루거나 데이터 분석가들을 찾는 기업이 늘어난다고 하는 기사나 이야기들이 떠돌아다닌다.한국정보화진흥원에서 발간한 '2015년 빅데이터 시장 현황조사'보고서에 의하면 빅데이터 공급기업과 수요기업 모두 빅데이터 분석가가 필요하다고 내다보고, 많은 데이터 분석가가 필요하다고 이야기했다.분야도 금융을 비롯하여 통신, 커머스 등을 아우르고, IT 관련부서뿐만 아니라, 현업이라고 불리는 마케팅이나 영업도 포함된 관계에서의 데이터 활용을 위해서 빅데이터 '분석가'가 필요하다고 이야기를 한다.죄송하지만.. 한국형 환경에서는 '빅데이터 분석가'나 '전문가'는 그다지 필요 없을 것 같다.1. 변화하지 않는 기업어차피 정해져 있는 프로세서, 내부 R&R과 내부 혁신을 하기 위한 인사이트를 찾고, 데이터 변수를 찾는다고 하더라도 굳이 기업 내부의 변화를 일으키지 않을 것이기 때문에 '진정한 데이터 분석가'는 해당 기업에 무의미할 것이다.정말, 전문가라면 '내부 혁신'에 대한 키워드들을 뽑아줄 텐데... 이런 이야기는 '컨설팅'업체에서도 하지 않고, 내부에서도 '금기'시 해야 할 단어들이 대부분이다.만일, 대기업인 중요 키워드가 '오너'의 키가 문제라고 지적한다면... 아마도, 해당 부서나 관련자들은 움직이지도 못할 것이다.죄송하지만, '내부 혁신'이 불가능하고, '오너'중심의 대기업은 데이터 분석가가 필요하지 않다. 다만, '오너'의 생각을 읽고서 적당하게 마사지된 '데이터'를 보여줄 '외부 데이터 분석'서비스 업체만 필요할 뿐이다.그래서, 국내에서는 데이터 분석 서비스 업체 정도가 적당하다.2. 기업과 조직에 데이터가 없다.프로세스 하단에서 동작하는 수많은 로그들을 추적 감시, 감사하는 시스템이 가동되고 있어야 하며, 고객 서비스를 하는 서비스 집단에서도 하단에서 아이디어가 상단으로 올라가는 환경들이 이미 가동되고 있어야 한다. 데이터의 대부분은 그런 인사이트를 증명하는 근거가 되기 때문이다.이미, 중요한 움직임을 보이고 있을 때에만 '의미 있는 정보'를 추출할 데이터들이 축적되는데... 사실상, 의미 없이 마사지된 '보고서'들만 존재한다.원천적으로 의미 있는 데이터를 추출할 데이터가 있어야 하는데.. 대부분이 왜곡된 정보들이거나, 특정 힘에 의해서 데이터들이 왜곡돼 있다면, 해당 기업과 조직은 데이터가 없다고 봐야 한다.3. 오랜 경험을 축적한 실전 전문가들이 일찍 퇴직한다.빅데이터를 통해서 단지 현황만을 보여주는 것이 아니라, 기업의 미래나 새로운 먹거리를 유도할 수 있는 인사이트를 추출하기 위해서는 해당 도메인이나 해당 마켓에 익숙하고 경험이 풍부한 전문가들이 같이 있어야 한다. 실제, 데이터가 의미하는 방향성이나 수치, 지수가 어떤 것을 의미하는지 읽어 줄 수 있는 것은 데이터 전문가들이 하는 일이 아니다.해당 업무와 해당 도메인의 전문가가 그 '수치'를 읽어 줄 수 있는 것이다.대부분의 기업에서 '실전'이거나 '실제 업무'에 익숙한 전문가나 경험이 축적된 사람들은 하청업체이거나 이미 퇴직한 경험이 풍부한 사람들이다.해당 기업에서는 아무리 데이터가 분석되어도 어떤 의미인지 판독해줄 사람이 없다.4. IT기술 전문가가 필요한 것이 아니다.빅데이터나 머신러닝과 같은 지식화 인사이트는 절대 IT기술이나 주변의 소프트웨어 설루션으로 만들어지는 것이 아니다. 기업 내부에 축적된 '지식'을 기반으로 '사람'을 기준으로 데이터가 만들어진다. 데이터 분석 전문가는 단지, 그것의 가치를 '판정'해줄 수 있는 기준을 마련해줄 뿐이다.대부분의 '한국형'조직들은 데이터 거버넌스 조직도 없으며, 제대로 된 인사시스템이 가동되지 않고 있다. 슬프지만, 빅데이터 전문가들은 내부에서 영입하는 것이 아니라, 내부에서 자생적으로 생성되는 것이다.자생적으로 빅데이터 전문가가 생성되지 않는 조직은 이미, 지식화가 불가능한 형태이기 때문에, 너무 무리하지 말고, 현재 환경에서 연착륙하는 것을 고려하는 것이 최선일 것이다.역시, '한국형'에서는 굳이 '빅데이터 분석가'가 필요한 것이 아니라, '빅데이터 분석가 코스프레'를 하는 사람이 필요한 것 아닌가?오너가 이야기하는 'A'를 'A'처럼 써줄 수 있는 코스프레가 가능한 사람이면 충분한 것 아닌가 한다.

인공지능 열풍이 거세게 불면서 이를 개발하는 엔지니어에 대한 수요도 폭발적으로 늘었다. 글로벌 IT의 중심이라 불리던 실리콘밸리를 포함해 중국에서도 막대한 자본을 바탕으로 엔지니어에게 기존 연봉의 2~3배를 제공하는, '인재 쟁탈전'에 돌입했다. 암흑기라 불릴 정도로 이공계 기피현상이 심했던 과거 일은 어느새 기억 속에서 잊혀질만큼 소프트웨어 엔지니어의 위상은 날이 갈수록 높아지고 있다. 심지어 교과 과정에 코딩 교육 의무화를 논의하는 단계다.AI 전문인력이란, 대게 원천기술을 개발하는 소프트웨어 엔지니어나, 학문적인 연구를 하는 리서치 인력을 많이 생각한다. 하지만, 실제로 핵심적인 역할을 담당하는 사람은 하드웨어 엔지니어다. 일반적으로 하드웨어 엔지니어라고 하면 많은 사람들이 납땜을 하고, 모터를 돌리는 등 '기계'를 만지는 엔지니어를 떠올리지만(물론 이 역시 하드웨어 엔지니어가 하는 일 중 하나다), 요즘처럼 인공지능이 적용되지 않은 곳이 없는 세상에서 하드웨어 엔지니어 역할은 그 이상이다.모두의 이해를 돕고, 인공지능 기술을 만드는 회사에서 하드웨어 엔지니어 역할이 얼마나 중요한지 알 수 있도록, 스켈터랩스 사내에서 시니어 하드웨어 엔지니어로 일하고 있는 오혁님과 질의응답 시간을 가졌다.< 스켈터랩스 오혁 하드웨어 엔지니어 >하드웨어 엔지니어로서 주로 하고 있는 일은?사용자가 실제로 만질 수 있는 기기, NVIDIA에서 생산하는 하드웨어 플랫폼과 운영체제(OS) 등을 막론하고, 소프트웨어 알고리즘을 실제 프로덕트로 구현하는 일을 한다. 이런 면에서 보면 소프트웨어 엔지니어링 서포터라고 생각할 수 있다. 하지만, 많은 사람이 더욱 더 심층적으로 인공지능을 연구할 수 있는 이유는 바로 하드웨어의 발전 때문이다.< '구글I/O 2017'에서 차세대 인공지능 전용 칩 'TPU'를 발표하는 모습, 출처: 구글 >예를 들어보자. 프로세서(CPU) 연산속도는 계속 빨라지고 있고, 그래픽 프로세서(GPU)가 프로세서 역할을 일부 담당하고 있으며, 대용량 메모리, 인공지능 가속기 등 모든 면에서 하드웨어 성능이 뒷받침되어야 한다. 하드웨어가 없다면, 소프트웨어 엔지니어가 열심히 만들어도 실제 구현하기가 어렵다. 간단하게 정리하면 하드웨어 엔지니어로서 리서처 역할을 하고, 눈으로 보이는 하드웨어도 만든다.일반인들이 알고 있는 것과 가장 큰 차이가 있다면?일반적으로 하드웨어 엔지니어라고 하면 많은 사람이 빛을 내거나, 모터를 돌리고, 부품을 조립하는 등 물리적인 제품을 만든다고 생각한다. 맞는 말이다. 하지만, 이 모든것을 컨트롤하기 위한 펌웨어, 미들웨어, OS, 디바이스 드라이버 등 소프트웨어가 돌아가기 바로 직전 단계까지, 하드웨어 엔지니어가 담당한다. 또한, 실제 제품 구현도 우리가 맡는다. 때문에, 놀랍게도 하드웨어 엔지니어도 소프트웨어 엔지니어의 전유물이라고 여겨지는 코딩을 많이 한다.< 'GTC 2017'에서 엔비디아 젠슨 황 CEO가 고성능 GPU 아키텍쳐 '볼타'를 발표하고 있다, 출처: 동아일보 >인공지능 붐이 일어나면서 어떤 점이 달라졌는가?인공지능 열풍이 불기 전 하드웨어 엔지니어는 제품을 목적에 맞게 실행하는 역할을 주로 했다. 제품을 구동되기 위해서는 대부분 순차적으로 프로세스를 진행한다. 땜질하고, 코딩하고, 각 부품에 연동하면 완성되는 형태다. 그러나, 지금은 이런 기본적인 프로세스 외에도 기계학습에 대한 알고리즘이나 인공지능 기술 전반에 걸쳐 소프트웨어적인 기술을 이해하지 못하면 절대로 원활하게 제품을 구현할 수 없다. 소프트웨어 엔지니어링을 서포트하는 역할에서 벗어나 인공지능 기술에 들어가는 소프트웨어가 어떻게 구현되는지 이해해야 적합한 제품을 만들 수 있기 때문이다.심지어 이제는 펌웨어를 코딩하는 것도 예전과 많이 달라졌다. 결과물만 놓고 보면, 모터를 돌리는 것은 같을 수 있다. 하지만, 예전에는 로봇 팔을 만들어 무언가를 잡기 위해, A 모터와 B 모터를 순차적으로 돌려서 잡는 것에 그쳤다면, 이제는 기계학습을 적용해 어떤 종류의 컵이라도 스스로 알아서 잡을 수 있도록 제작한다. 하나하나 펌웨어로 낮은 레벨에서 구현하는 것이 아니라, 로봇팔이 잡았을 때 이에 맞는 조건을 제공, 코드 하나로 학습하는 커스터마이징을 적용하는 것이다.< 국산 복강경 로봇수술기기 '레보아이'의 모습, 출처: 동아일보 >인공지능 기업의 하드웨어 엔지니어로서 가장 재미있는 점은?인공지능을 적용하면서 굉장히 재미있는 것을 많이 시도할 수 있다. 아이디어를 내고 무언가를 만들고 싶다면, 최종 제품으로 가는 길에 있어 여러 옵션을 선택할 수 있기 때문이다. 다시 말해 인공지능 소프트웨어를 통해 기존과 다른 방식으로 문제에 접근하고, 이를 해결할 수 있다는 점이다. 비유하자면, 지금까지 손으로 직접 돌리는 드라이버를 사용했다면, 이제는 앞의 부품을 언제든 바꿔낄 수 있는 전동드릴을 사용하고 있다고 보면 된다.반대로 힘든 점은 무엇인가?아무래도 인공지능이 너무 핫하다 보니 계속해서 새로운 기술이 등장한다. 인공지능 업계에서 종사하는 모든 사람들도 마찬가지겠지만, 신기술을 공부하고 연구해야 좋은 제품을 만들 수 있다. 또한, 하드웨어 엔지니어들이 열심히 만든 결과물이 너무나도 빠른 기술 발전속도로 잠시 거쳐가는 것에 불과할까 걱정되기도 한다.그럼에도 앞으로 기대되는 점은 무엇인가?하드웨어 엔지니어로서 세상을 이롭게 하는 제품을 더 많이 제작할 수 있다는 점이다. 인공지능 기술이 발전함에 따라 인간이 못 하는 영역도 조금씩 다가서고 있다.개인적으로는 로봇 쪽에 관심이 많다. 기술 발전속도가 빨라지는 만큼 다양한 제품이 등장해 사람들의 삶에 많은 혜택을 줄 것으로 기대한다. 예를 들면, 청각 장애인을 위해 음성인식을 시각적으로 바꿔주는 제품이나, 거동이 불편한 독거노인을 돕기 위한 기술 등이 있다. 삶을 윤택하게 해주는 기술을 개발하는 것이 점점 더 쉬워지고 있다는 점에서 많이 기대하는 중이다. 어떤 형태가 될 지는 예측할 수 없지만, 지금 단계에서는 소프트웨어든 하드웨어든 커다란 인공지능 플랫폼을 만들고 있다고 생각한다.이호진, 스켈터랩스 마케팅 매니저조원규 전 구글코리아 R&D총괄 사장을 주축으로 구글, 삼성, 카이스트 AI 랩 출신들로 구성된 인공지능 기술 기업 스켈터랩스에서 마케팅을 담당하고 있다#스켈터랩스 #기업문화 #인사이트 #경험공유 #조직문화 #인공지능기업 #기술기업 #하드웨어엔지니어