Based in a country seeing huge growth in its video game sector, Korean game studios have been releasing big hits in the past few years. As seen in our previous post, the Top Ten Things to do in Seoul for Gamers, Koreans of all ages have been diving headfirst into gaming culture. Mostly focused on digital gaming like mobile and PC, the gaming industry has been growing at an annual rate of 4.3% (Statista). Although the most popular games by far are MMORPGs, we tried to diversify the list for all types of players to enjoy.  MapleStory  MapleStory - Source: maplestory.nexon.net  MapleStory has been around for years and only continues to be a huge favorite in Korea and around the world. An extremely social game, it sees players work to improve their own character’s skills while chatting, looting and even getting married to others. The 2D element gives the game an almost retro vibe, even though it has been updated many times, including the release of a sequel. Create your avatar, choose your class and find out how to fulfill your quest by defeating the Black Mage.   Ragnarok Online  Ragnark Online - Source: mmoculture.com  You guessed it, another tried and true MMORPG. Based on a comic of the same name by Lee Myung-jin, this 3D game features a constantly changing timeline that players must interact and adapt with within the specific world. The key part of the game is choosing the “job” of your character. With that choice come make-or-break strengths and weaknesses that can determine the gameplay for you. Starting at 13 but growing to 50 classes, the choice is daunting but crucial as your job can change as well. Whether you want to try out the newest sequel, the mobile version, or even watch the animated TV series, Ragnarok Online is definitely one to check out.   Blade & Soul  Blade and Soul - Source: www.bladeandsoul.com  Developed by one of the most notable studios in Korea, NCSOFT, this fantasy martial arts game was only released in Western countries 2 years ago, but had been out in Korea and Japan since 2012. A super renowned character customization system gives the game an update from the more traditional fighting style games. There are four playable races that reference the four Chinese Symbols of Azure Dragon, Vermillion Bird, Black Tortoise and White Tiger. Definitely a must for fans of combat-driven games.   ANIPANG  ANIPENG - Source: anipang-for-kakao.en.softonic.com  Finally a change of pace! ANIPANG is a mobile puzzle game, and also the first Korean game to reach 20 million downloads. Filled to the brim with squishy animal faces, this match-3 style game can be enjoyed alone or by competing with friends. Whether it’s killing time waiting for the bus or just wanting to beat that one tricky level, ANIPANG can be played anywhere at any time.   Lineage  Linage - Source: mmogames.com  Rounding out this list is Lineage, a video game series released in the 90s and still receiving sequels and spin-offs to this day. Taking you back to medieval times, this game is one of the most successful MMORPGs to date. The realistic siege warfare and constant lore updates makes it a fun and addictive way to pass the time. The mobile release of the game broke records and had fans eager to play, so don’t miss out. 

2016년 7월 말 제대 후 곧바로 떠난 유럽 여행 중에 한국에 있는 친구로부터 카톡이 왔다. 한 핀테크 스타트업에서 인턴을 구하고 있는데 한 번 지원해보라는 내용이었다. 유럽 한복판에서 복학과 인턴 사이에서 고민을 하다가, 스위스에서 인턴 지원서를 작성하여 회사로 보냈다. 귀국한 날, 인생 처음으로 양복을 샀으며 그다음 날 면접을 보러 갔고, 2016년 9월 내 첫 직장 어니스트펀드 성장전략실에서의 인턴 생활이 시작되었다. 금융회사와 스타트업의 Identity를 모두 가지고 있는 어니스트펀드에서 6개월간 많은 것을 배울 수 있었는데, 이 배움은 어니스트펀드가 아니라 다른 회사에서 일했다면 절대로 얻을 수 없는 것이라고 생각한다. 인턴 생활을 마무리하는 이 시점에 이번 브런치 글을 통해 내가 어니스트펀드에서 느끼고 배운 것들에 대해 이야기해보도록 하겠다.1. 자발적인 동기에서 나온 열정 어니스트펀드의 하루는 언제나 열정적이다. 어쩌면 스타트업의 ‘열정’은 굉장히 진부한 이야기일 수 있지만, 나는 어니스트팀이 가지고 있는 열정에는 남다른 것이 있다고 생각한다. (어니스트펀드의 팀원들은 흔히 회사를 어니스트팀이라고 부른다) 한 에피소드를 통해 그 열정을 설명해보고자 한다. 본격적으로 들어가기 전에, 어니스트펀드에서는 직함을 쓰지 않고 영어 닉네임을 통해 소통하는 문화를 채택하고 있음을 밝힌다.인턴 생활을 시작한 초기, 하루는 회식을 마치고 우리 집과 가까운 곳에 사는 포세이돈의 차를 얻어 타고 귀가했던 적이 있었다. 포세이돈이 은행에서 근무하셨던 경험을 전해 듣던 와중에, 어니스트팀에 대한 이야기가 나왔는데 포세이돈은 나에게 아래와 같은 질문을 하였다.“알렉스는 왜 우리 회사의 많은 분들이 어니스트펀드에서 일하고 계시다고 생각해요?” 그 당시 나는 바로 이렇다 할 답변을 내놓지 못하였다. 다른 좋은 곳에서도 충분히 잘 나갈 수 있는 역량을 가지고 계신 분들이 왜 이곳에 모여 계신 것인가라는 질문만이 내 머릿속을 맴돌았다. 조금 기다리시더니 이내 곧 나에게 답변을 주셨다. “우리 회사에서 하는 일, 그 자체를 정말 좋아하고 즐기니까 그런 게 아닐까요?”어찌 보면 별 이야기가 아니었지만 나는 약간의 충격을 받았다. 보통 ‘회사’와 ‘일’은 그다지 긍정적인 의미로 수용되기보다는 빨리 해치워야 하는 것으로 받아들여지는 경우가 많은데, 포세이돈의 답변은 그 보편적인 관념에 반대되었기 때문이다. 밤낮없이 치열한 대화가 오고가는 성장전략실의 회의이후 어니스트팀 속에 있으면서 구성원 모두가 프로페셔널한 정신을 가지고 있고, 금융업의 새로운 분야를 열어가는 것에 자부심을 느끼며, 자신의 일을 즐기고 있음을 발견할 수 있었다. 이러한 특징은 자연스럽게 일에 대한 열정으로 표출되었고, 어니스트펀드의 형광등은 밤늦게까지도 꺼지지 않았다. 또한 어니스트펀드의 회의실은 밤낮없이 치열한 대화가 오고 가는 곳이었고, 사무실은 언제나 집중하는 분위기로 압도되어 있는 곳이었다. 모든 팀원들 한분 한분과도 좋은 이야기를 많이 나누었지만, 나는 특히 디자이너 토니와 했던 이야기가 인상 깊었다. 토니가 나에게 항상 했던 이야기는 바로 어니스트펀드라는 금융회사에서 자신의 분야와는 거리가 멀기만 했었던 금융 분야의 전문가들과 함께 일하면서, 금융업의 디자인을 알아가는 즐거움이 크다는 것이었다. 대출과 투자 서비스를 이용하는 고객들은 어떠한 디자인에 주목하는가? 어떠한 글씨체, 글씨 크기, 아이콘의 모양, 색깔, 어떠한 화면 구성이 금융소비자들의 눈을 사로잡을 수 있을까? 이러한 이야기를 할 때, 내가 마주한 토니의 얼굴에서 나는 언제나 즐거움과 열정을 동시에 볼 수 있었다.'노력하는 자는 즐기는 자를 이기지 못한다'는 말이 있다. 지금껏 내가 본 어니스트팀의 열정은 모두 즐거움을 그 원천으로 두고 있었다. 나는 이것이 바로 어니스트펀드가 단기간에 탁월한 성과를 내며 성장할 수 있는 근본적인 원동력이라고 생각한다.제품개발팀의 Agora 회의그렇다면 '그 즐거움은 어디서 오는가'에 대한 답은 무엇일까? 나는 어니스트펀드가 빠르게 성장하는 만큼 직원들 개인들도 같이 성장하는 구조가 갖춰져 있기 때문이라고 생각한다. 나는 개인적으로 사람들이 보통 즐거움을 느끼는 순간이 자신의 어떠한 상태가 개선되고 있음을 느낄 때라고 생각한다. 자신이 원하는 방향으로 스스로가 변화하고 있을 때 우리는 개선이 된다고 생각하며 이는 곧 우리가 '성장'을 하고 있다는 것을 의미한다.어니스트팀 개개인이 자신이 속한 직무에서 개인의 성장을 일구고 있듯이, 나 또한 비약적인 성장을 할 수 있었다. 63빌딩으로 첫 출근을 하던 때와 지금을 생각하면 나는 내가 원하는 대로 변화했고 완전히 다른 사람이 된 것만 같은 느낌을 지울 수 없기 때문이다. 이제부터 내가 성장할 수 있게 어니스트펀드가 제공해준 기회에 대해 이야기해보겠다. 2. 성장으로 이어질 수 있는 기회의 제공6개월 동안 내가 인턴으로서 했던 업무를 살펴보면, ‘과연 다른 회사에서는 이런 수준의 업무를 할 수 있는 기회를 인턴에게 줄 수 있을까?’라는 의문이 든다.사실 나는 어니스트펀드에서 인턴 생활을 하기 전에, 엑셀과 파워포인트를 다루는 것조차 익숙하지 않았던 갓 제대한 복학예정 대학생이었다. 그랬기 때문에 변화와 성장의 속도가 빠른 어니스트펀드에서의 첫 달은 적응하기 쉽지 않았지만, 그 순간들을 이 악물고 버텨내고 회사에 적응하기 시작한 시점부터 나에게 주어진 업무들은 그 양이나 질을 생각했을 때 매우 파격적이었다고 생각한다. 얼마나 파격적이었는지를 하나의 일화를 통해 설명하도록 하겠다.하루는 어니스트펀드의 대표인 루피가 이야기할 것이 있다며, 회의실로 나를 이끌었다. 루피가 꺼낸 말은 다음과 같았다.“알렉스, 지금 우리 회사에게 필요한 3가지 일이 있는데 앞으로 남은 기간 동안 이 과제들을 직접 해결해보면 정말 좋을 것 같아요. 첫 번째는……”루피가 내게 제안했던 3가지 업무에 대해서 상세하게 밝힐 순 없지만, 인턴 생활이 끝날 때까지 나는 3가지 업무 중에 2가지를 할 수 있는 기회를 얻었다. 사실 다른 회사에서는 대표가 직접 나서서 인턴에게 특정 프로젝트를 제안하는 것은 매우 놀라울 일이지만, 어니스트펀드에서는 그다지 놀랄만한 일은 아니었다. 덕분에 나는 전략 관련 단독 프로젝트를 진행할 수 있었다.나의 자리에는 항상 온갖 자료를 검토하며 보고서를 썼던 흔적이 남아있다하지만 기회를 준다고 해서 모든 것이 해결되지는 않는다. 역량에 초과하는 일을 무작정 던져주는 것은 오히려 그 사람의 부담감을 높이는 결과를 초래하기 때문이다. 사실 전략 관련 단독 프로젝트를 진행하는 것은 나에게 매우 벅찬 일이었다. 여러 자료들을 검토하고 거기에서 얻은 정보들을 요약 및 정리하고 이를 토대로 내가 결국 말하고자 하는 주제에 관한 보고서를 작성하는 일은 대학생이 작성하는 리포트와는 비교할 수가 없었기 때문이다. 내가 이러한 난관에 부딪쳤을 때, 조목조목 도움을 준 분은 바로 나의 사수인 마커스였다. 전직 컨설턴트였던 마커스는 전략을 짜는 프로젝트가 통상적으로 진행되는 절차, 구글에서 자료를 찾는 방법, 자료들 중에서 유의미한 정보를 뽑아내는 법, 그 정보들을 보기 쉽게 보고서로 작성하는 방법까지 전반에 걸쳐 피드백을 주셨다. 나 또한 이에 호응하여, 늦은 밤까지 회사에 남아 자료들을 읽고 또 읽고 정리하고 내 것으로 만들기 위해 노력하였다.어니스트팀 전체에게 최종 보고서를 공유이 과정에서 나는 하루하루 내가 변해가는 것을 느꼈고, 최종적으로 보고서가 완성되기까지의 시간은 오래 걸렸을지라도 기업의 전략 업무의 한 사이클을 제대로 완결할 수 있었다. 이렇게 나는 내 인생 첫 직장에서 내 인생 최초의 리포트를 작성하여 어니스트팀 전체에게 공유하는 경험을 할 수 있었다. 나에게 있어, 어니스트펀드는 기회를 제공하는 것과 더불어 그 기회를 통해 내가 성장할 수 있도록 만들어주는 회사였다.어니스트펀드의 문화 강령인 ‘Honest Manual’ 4번에는 이런 원칙이 있다."4. 개인의 성장과 계발은 월급만큼이나 끊겨서는 안 됩니다. 성장이 없을 때는 리더에게 책임을 묻습니다."우리가 흔히 집단에 속하여 생활을 하다 보면, 정해진 규칙이 무의미해지는 경우가 많다. 가령, 대학교 동아리에서 수요일 오전 10시까지 활동에 참석하라는 구체적인 약속도 제대로 지켜지는 것이 어려운 경우가 많은데, 하물며 ‘성장’에 끊김이 없어야 한다는 추상적인 원칙이 지켜지는 것은 얼마나 어려운 일인지 많은 사람들이 동의할 것이다.그러나 나는 인턴생활을 마치며 내가 성장을 했다는 것을 나 스스로 느끼면서, 위의 원칙이 말뿐만이 아니라 실제로 회사 내에서 실행으로 옮겨지고 있음을 몸소 체험하였다. 이러한 원칙이 준수될 수 있는 이유는, 대표인 루피와 나의 사수 마커스를 포함한 어니스트팀 전체의 노력이 뒷받침되기 때문이다. 단적으로, 성장전략실의 시나몬이 내가 인턴생활을 마무리하며 그동안의 감회와 배운 것들을 정리하고 이를 회사의 얼굴인 브런치에 글로 게재하는 기회를 마련해줘서 나의 인턴 생활을 정리해볼 수 있게 한 것도 이러한 노력의 일환이라고 생각한다.이어서 여러 팀원 분들이 제공해주신 ‘성장’의 기회를 통해, 내가 인턴 생활 동안 깨달았던 2가지 인사이트를 소개하고자 한다.3. 절차적 지식의 중요성나는 확실히 어니스트펀드에서의 인턴 생활을 통해 많은 것들을 배우고 느꼈지만, 그중에 내가 가장 중요한 인사이트라고 생각하는 것이 바로 절차적 지식의 중요성이다.교육학 이론에 따르면, 지식은 크게 두 부류로 나뉘는데 이를 각각 선언적 지식(declarative knowledge)과 절차적 지식(procedural knowledge)이라고 부른다. 선언적 지식은 ‘무엇이 어떠하다’는 정적인 형태의 지식이다. 이를 익히기 위한 학습 목표는 ‘~을 안다’의 형태로 표현되고 주로 암기와 이해를 통해 획득된다. 예를 들면, 조선 22대왕 정조의 업적에 대해 자세하게 설명할 수 있는 것은 정조에 대한 선언적 지식 덕분이다. 이와 달리, 절차적 지식은 ‘무엇을 어떻게 수행하는가’에 대한 지식으로 동적인 형태를 갖는다. 절차적 지식에 대한 학습 목표는 ‘~을 할 수 있다’의 형태로 표현되고 실제로 행동으로 옮겨보는 과정에서 이를 습득하게 된다. 예를 들면, 자전거를 타거나 테니스를 칠 수 있는 사람은 이 두 가지 활동에 대한 절차적 지식 덕분이다.자전거를 탈 줄 아는 것은 대표적인 절차적 지식이다내가 절차적 지식에 주목하는 이유는 우리가 결국 무엇을 아는 것도 중요하지만, 그 어떠한 무엇을 알아내기 위해 어떻게 해야 하는가에 대한 답을 아는 것이 중요하기 때문이다. 왜냐하면 인간은 본질적으로 모든 것을 알 수 없기 때문이다. 이러한 절차적 지식은 회사의 업무에서 더 중요하게 부각되는데, 거의 모든 업무들이 절차적 지식의 영역을 통해 해결되기 때문이다.내가 어니스트펀드에서 일하면서 가장 중요하다고 생각한 절차적 지식은, 바로 ‘Google’을 이용하여 나에게 필요한 정보를 찾는 방법을 아는 것이었다. 어떤 사람들은 Googling은 누구나 하는 쉬운 일이라고 이야기할 수 있으나, 업무는 질적 완벽성도 중요하지만 신속성도 중요하기 때문에 어떻게 Google을 이용할 것인가는 중요한 절차적 지식이라고 생각한다. 내가 업무를 하면서 겪은 에피소드를 통해 Googling에 대한 절차적 지식을 구체적으로 설명하겠다.인턴 생활 막바지에, 나는 회사 소개 페이지를 기획하는 업무를 맡게 되었다. 회사 소개 페이지는 대개 그 회사의 철학을 소개하는 공간으로 쓰인다. 물론 어니스트펀드가 추구하는 바에 대해 이해도가 높았을 무렵이었으나, 나는 도대체 내가 알고 있는 어니스트펀드의 철학을 어떻게 풀어낼지 갈피가 잡히지 않았다. 나는 우선 Googling을 통해 회사의 비전을 작성하기 위한 가이드라인을 만들고, 이에 따라 업무를 진행하기로 결정했다. 여기서부터 Googling이라는 절차적 지식이 매우 중요하게 쓰이는데, 나는 우선 Google 검색창에 ‘company vision’을 검색하였다. 이는 Google에 존재하는 수많은 회사의 비전에 대한 정보들이 대략적으로 무엇이 있는지 감을 잡기 위한 것이었다. 수많은 웹페이지들이 검색된 가운데, 나는 Business Dictionary의 ‘Definition of company vision’,  Harvard Business Review(HBR)의 ‘Building your company’s vision’, GE의 ‘Mission, Vision & Strategy’ 이 세 가지 웹페이지를 열었다. 그 이유는 어떤 것을 검색할 때 항상 이에 대한 ‘정의, 실행 방식, 레퍼런스(참고자료)’ 이 세 가지를 알아야 업무에 유용하게 사용할 수 있기 때문이다.GooglingBusiness Dictionary의 정의에 따르면, 비전은 중장기적인 목표를 의미하며 기업의 현재 업무에 대한 지침으로서 기능한다고 소개되어 있었다. 나는 이를 통해, 회사의 철학을 소개하는 것에 있어서 비전은 하나의 재료이며 단기적인 목표를 의미하는 다른 개념어가 있다는 것을 추론할 수 있었다. 다음으로 HBR에서는 회사의 비전 수립을 위한 방법론으로 Strategical Planning이란 이론을 설명하고 있었다. 이 이론에 대한 설명을 읽은 후, 나는 회사의 철학이 장기적인 비전-중기적인 미션-단기적인 액션플랜 3단계로 이루어진다는 것을 파악할 수 있었다. 따라서 나는 이 Strategical Planning이 내가 찾은 가이드라인이 될 수 있다고 판단하였고, 이를 다시 Google로 검색하였다. 그 결과, 어떤 한 웹사이트에서 Strategical Planning과 관련하여 ‘VMOSA’라는 개념을 찾을 수 있었다. VMOSA는 Vision, Mission, Objective, Strategy, Action Plan을 의미하는 것으로 회사의 철학을 5가지 과업의 층위로 나누어 분류한 체계이다. 이 개념을 토대로, 이전에 찾아 놓았던 GE의 회사 소개 페이지 레퍼런스를 확인하여 우리 회사 철학의 가이드라인으로 삼는 것에 대한 적정성을 검증하였다. 결과적으로, VMOSA가 적절하다고 판단되었고 나는 내가 이해하고 있는 어니스트펀드의 철학을 그 개념에 맞추어 정리하였고 단시간 내에 효율적으로 업무를 완수할 수 있었다.이러한 경험에서 보듯, 회사의 업무과정에는 원래 알지 못하는 것들의 답을 효율적으로 구해야 하는 과정이 반드시 포함되어 있다. 사람들이 모든 것들에 대해 알 수 없기 때문이다. 회사의 철학을 소개하는 페이지를 구성하는 것을 난해한 일이라고 보긴 어렵지만, 나는 그 알지 못하는 것에 대해 스스로 질문하고 답을 구해가는 과정이 나를 성숙시키고 나를 그 분야의 전문가로 만들어주는 유일한 길이라는 것을 알 수 있었다.어떻게 엘론 머스크(Elon Musk)는 우주로 쏘아 올릴 로켓을 만드는 스페이스X를 창업할 수 있었겠는가? 정답은 간단한 것 같다. 지금껏 로켓을 쏘아 올린 회사를 만드는 방법이 존재한 적이 없었음에도 불구하고, 그는 그 방법을 알아낼 절차적 지식을 갖추었기 때문이다. 4. 소통의 기술내가 어니스트펀드에서 일하면서 스스로 가장 부족하다고 느꼈던 것은 바로 소통의 기술인데, 두괄식으로 주장을 이야기하고 반드시 그 근거를 이야기하는 것을 의미한다. 내가 이 소통의 기술이 부족하다고 느낀 이유는 논리적으로 글 쓸 때와는 다르게, 나는 ‘생각나는 대로 말하기’에 익숙했기 때문이다. 실제 회사에서 일을 할 때에는 소통의 신속성과 명확성이 매우 중요하기 때문에, 나의 소통 방식이 업무과정에서 큰 방해 요소가 된다는 것을 알 수 있었다. 예를 들자면, “제가 회의에 참석을 하다 보니 시간이 없어서…… 주신 일을 다 못 했는데…… 어쩔 수 없었던 상황이었습니다.”라고 이야기한다면 상대방의 입장에서 그래서 결국 어떻게 해달라는 것인가라는 의문이 들 것이다. 이것이 바로 생각나는 대로 말하는 것의 폐해이다. 따라서, 이러한 경우 “제게 주신 일을 처리하기 위해 시간을 좀 더 주시면 감사하겠습니다. 왜냐하면, 제가 갑작스럽게 회의에 참석을 해서 업무 처리 시간이 지연되었기 때문입니다.”라고 말해야 명확하고 신속한 의사소통이 가능하다.명확하고 신속한 의사소통의 중요성실제로 나의 사수였던 마커스와 일을 하던 도중에, 이러한 소통방식으로 인해 마커스가 나에게 내가 말하고자 하는 의도를 되물어 본 적이 많았다. 나는 갑작스럽게 사수로부터 ‘왜 그렇게 생각하느냐?’, ‘그래서 결국 이야기하고 싶은 것이 무엇이냐?’라는 질문을 받으면서 당황했었고 그럴 때마다 나의 말하는 방식을 두괄식으로 바꾸어야 하겠다는 필요성을 더 절실하게 느낄 수 있었다. 이러한 두괄식 구조에 의한 소통이 중요한 이유는, 나의 주장을 명확하게 전달하는 것과 더불어 그 주장의 맥락을 상대방이 이해할 수 있도록 해야 하기 때문이다. 회사 내에서 업무를 하면서 발생하는 모든 언행은 탁월한 업무 수행을 위한 목적을 수반하고 있다. 따라서 나의 언행은 모두 그러한 맥락 위에서 이루어져야 하고, 업무의 전반을 이끌어 나가고 있는 시니어와 같은 팀의 구성원들이 그 맥락을 이해하고 있어야 최고의 결과를 낼 수 있다. 맥락의 공유가 실패하면, 내가 공들여했던 몇 시간의 일이 큰 의미가 없는 것이 되어버려 업무의 신속하고 정확한 처리가 물거품이 되기 때문이다.이러한 절차적 지식과 소통 방식에 대한 깨달음뿐만 아니라, 수없이 많은 것들을 배웠던 인턴 생활이 드디어 막을 내렸다.5. 어니스트펀드에서의 인턴을 마치며약 6개월간의 어니스트펀드에서의 긴 여정을 마치고, 2017년 3월에 다시 학교로 돌아간다. 어니스트펀드에서 맷집을 제대로 키워서 그런지 학교로 돌아가서 겪게 될 진로 고민과 나에게 주어질 여러 가지 과제들을 해결해 나가는 것이 그 전과는 다르게 크게 부담으로 느껴지지 않는다. 어니스트펀드는 나를 강하게 만들어준 곳이었으며, 아무것도 갖춘 것이 없어도 뛰어들어서 하다 보면 결국 해낼 수 있다는 마인드를 가질 수 있게 해주었다.인턴 생활 마지막 날 아침내가 한 학기를 늦추면서까지 스타트업에서 일하기로 결정한 것에 대해 많은 사람들이 의아해하였지만, 6개월이 지난 지금 나는 그때 복학이 아닌 인턴이라는 도전을 선택했던 나에게 칭찬을 해주고 싶다.내가 훗날 대기업에서 일하고 있든지, 작은 규모의 회사에서 일하고 있든지, 아니면 스타트업을 운영하고 있든지에 관계없이, 어니스트펀드에서의 인턴 경험은 앞으로 나의 인생 전반에 긍정적인 영향을 미칠 것이라고 확신한다. 이러한 경험을 할 수 있도록 도와주신 모든 어니스트펀드 팀원분들께 감사의 인사를 전하고 싶다.마지막으로 브런치 글을 마무리하면서, 나와 비슷한 연령대의 친구들에게 짧게 이런 질문을 던져보고 싶다.“청년 실업률이 치솟고 있는 요즘, 안정을 찾는 것도 좋고 이것저것 따져가며 사는 것도 좋지만 한 번쯤 새로운 혁신이 꿈틀거리고 있는 곳에 들어가 보는 것은 어떠한가?” “그리고 그곳에서 어쩌면 예상치 못하게 정말 많은 것들을 얻을 수도 있지 않겠는가?”#어니스트펀드 #기획 #전략 #인턴 #인턴생활 #인사이트

빅 데이터 엔지니어는 무엇을 하나요?빅 데이터가 부상하면서 그와 관련된 직업군도 함께 주목받기 시작했습니다. 빅 데이터 엔지니어, 빅 데이터 애널리스트, 빅 데이터 사이언티스트 등 다양한 직업군이 생겼습니다. 오늘은 개발자 직군 중 데이터와 관련된 빅 데이터 엔지니어에 관해 이야기해 볼 것입니다. 빅 데이터 엔지니어는 무엇을 할까요? 빅 데이터 엔지니어가 무엇을 하는지 알기 위해서는 먼저 빅 데이터가 뭔지 알필요가 있겠습니다.빅 데이터는 기존 데이터베이스 관리도구의 능력을 넘어서는 대량의 정형 또는 심지어 데이터베이스 형태가 아닌 비정형의 데이터 집합조차 포함한 데이터로부터 가치를 추출하고 결과를 분석하는 기술입니다(위키 참조).빅 데이터의 특징은 방대한 데이터와 더불어 비정형 데이터까지 포함한다는 것입니다. 많은 양의 데이터와 정형화 되지 않은 데이터를 수집하는 일은 보통 일이 아닙니다. 빅 데이터를 통한 새로운 알고리즘를 만들거나 인사이트를 발견하기 위해서는 빅 데이터가 존재해야 합니다. 빅 데이터 엔지니어는 이러한 빅 데이터를 수집하고 관리하는 프로그래머입니다. 일반적인 데이터 수집과 달리 수십테라 정도의 정보를 수집 하게 됩니다. 또 그런 데이터를 어떻게 효율적으로 관리할지 고민해야합니다.데이터는 미래의 석유라고 합니다. 빅 데이터 엔지니어는 빅 데이터 분석가나 과학자들에게 이러한 석유를 가져다 주는 송유관을 설치하고 관리하는 역할을 한다고 볼 수 있습니다. 빅 데이터 활용을 위해서라면 빅 데이터 엔지니어의 역량이 반드시 필요합니다.데이터 과학자와 데이터 엔지니어는 다르다.위에서 빅 데이터 엔지니어는 데이터를 수집하고 관리하는 업무를 한다고 했습니다. 하지만 구체적으로 빅 데이터 과학자(Big Data Scientist)와 빅 데이터 엔지니어(Big Data Engineer)는 무엇이 다를까요?어떤 직업의 업무라는 것이 무 자르듯 쉽게 나눌 수 있는 것은 아니지만 확실히 그 직업만의 특징은 존재합니다. 각 직업 별로의 특징을 통해 빅 데이터 엔지니어가 빅 데이터 과학자와 어떻게 다른지 알아보도록 하겠습니다.1. 빅 데이터 엔지니어(Big Data Engineer)빅 데이터 엔지니어는 위에서도 언급 했지만, 데이터를 수집하고 관리하는 일을 합니다. 빅 데이터 엔지니어를 통해 '빅 데이터'가 만들어진다고 해도 무방하죠. 숫자나 규칙이 있는 정형 데이터는 물론이고 글자나 불규칙적인 비정형 데이터까지 수집하고 관리합니다. "그냥 데이터를 수집하고 관리하는 일인데 별거 있나?"라고 생각하실 수도 있습니다. 빅 데이터라는 개념 이전에도 데이터는 수집되었고 분석을 통해 비즈니스 문제를 해결해 왔으니까요. 그렇지만, 빅 데이터라는 개념이 부상하고 실현 가능할 수 있었던 이유는 방대한 데이터를 수집할 수 있는 퍼널(funnel) 설계과 그 데이터를 관리하고 알맞게 사용할 수 있는 시스템을 구축할 수 있었기 때문입니다.그렇기 때문에 빅 데이터 엔지니어는 프로그래밍에 아주 능숙해야합니다. 빅 데이터를 수집하고 관리할 수 있는 방법을 짜야하니까요. 또한, 개별적인 정보가 아닌 큰 틀에서의 정보를 다루고 통합하고 나누어 볼 수 있는 설계 능력이 따라주어야 합니다.정교하게 짜여진 빅 데이터가 아니라면 빅 데이터 과학자가 그것을 분석하고 사용하는데 상당한 자원이 들거나 최악의 경우 아예 이용하지 못하게 될 것입니다.2. 빅 데이터 과학자(Big Data Scientist)빅 데이터 엔지니어가 빅 데이터를 수집하고 관리한다면 빅 데이터 과학자는 그것을 요리하는 역할을 합니다. 데이터보고 직면한 비즈니스 문제를 해결할 새로운 인사이트를 도출해 내는 것입니다. 혹은 현재 가지고 있는 프로세스를 개선할 알고리즘을 만들어 낼 수도 있습니다.빅 데이터 과학자는 데이터를 분석할 수 있는 통계학적 지식뿐만 아니라 그 데이터를 다룰 수 있는 프로그래밍적 지식도 요구됩니다. 일반적인 데이터가 아닌 '빅' 데이터다 보니 그것을 쉽게 운용하고 자유자재로 이용하게 해줄 툴을 익혀야합니다. 또한, 빅 데이터 과학자에게 요구되는 핵심 역량 중 하나는 바로 머신러닝에 대한 지식입니다. 이 또한 프로그래밍 지식과 알고리즘 지식이 필요합니다. 빅 데이터 엔지니어가 되기 위한 Key Skills그렇다면 빅 데이터 엔지니어가 되기 위해서는 어떤 기술 스택들을 익혀야할까요? 빅 데이터 엔지니어는 데이터와 관련된 직군인만큼 데이터베이스와 관련된 기술스택들이 중요합니다.1. SQL데이터 관리를 하시는 분들이면 다들 알고 계시는 SQL입니다.  SQL은 관계형 데이터베이스 관리 시스템의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어입니다(위키참조).2. MapReduce(맵리듀스)맵리듀스는 구글에서 대용량 데이터 처리를 분산 병렬 컴퓨팅에서 처리하기 위한 목적으로 제작하여 2004년에 발표한 프레임워크입니다.(위키참조).3. Apache Hadoop(아파치 하둡)Apache Hadoop은 대규모 데이터 세트를 효율적으로 처리하는 데 사용할 수 있는 오픈 소스 소프트웨어 프로젝트입니다. 하나의 대형 컴퓨터를 사용하여 데이터를 처리 및 저장하는 대신, 하둡을 사용하면 상용 하드웨어를 함께 클러스터링하여 대량의 데이터 세트를 병렬로 분석할 수 있습니다.4. Apache Cassandra(아파치 카산드라)Apache Cassandra 자유-오픈 소스 분산형 NoSQL 데이터베이스 관리 시스템의 하나로, 단일 장애점 없이 고성능을 제공하면서 수많은 서버 간의 대용량의 데이터를 관리하기 위해 설계되었습니다. 카산드라는 여러 데이터센터에 걸쳐 클러스터를 지원하며 마스터리스(masterless) 비동기 레플리케이션을 통해 모든 클라이언트에 대한 낮은 레이턴시 운영을 허용합니다(위키참조).5. Java(자바)빅 데이터 엔지니어는 기본적으로 프로그래머이기 때문에 프로그래밍 지식있어야 합니다. 빅 데이터 엔지니어를 목표로 처음 프로그래밍을 시작한다면 자바를 추천합니다. 물론, 다른 언어를 통해 프로그래밍 실력을 쌓아도 됩니다. 그렇지만, 아파치 하둡과 아파치 카산드라가 자바를 베이스로 만들어졌기 때문에 자바를 배운다면 이 기술스택들을 습득하는데 훨씬 효율적일 것입니다.다른 포스팅에서도 항상 말씀드려왔지만 기술스택만 익힌다고 해서 그 직업을 가질 수 있는 것은 아닙니다. 기술스택은 기본이고 개발자로써의 역량이 뒷받침 되어야 시장에서 환영받는 빅 데이터 엔지니어가 될 수 있습니다.Photo by Ehud Neuhaus on Unsplash빅 데이터 엔지니어가 되기 위한 학습 콘텐츠시중에서는 완성된 단계로써 빅 데이터 엔지니어를 양성하는 프로그램은 많지 않습니다. 따라서 개인이 빅 데이터 엔지니어에게 필요한 기술 스택들을 하나씩 익혀 나가야 합니다.무료 온라인 콘텐츠도 많겠지만, 비싸지 않으면서도 잘 정제된 콘텐츠를 소개하려고 합니다. 유튜브 강좌보다는 보기 편하고 학습 환경이 잘 갖춰져 있어서 공부하기에 좋은 콘텐츠를 추천합니다.1. SQL - SQL 프로그래밍 : SQL을 무료로 학습할 수 있는 사이트(한글)2. Hadoop - 유데미 The Ultimate Hands-On Hadoop - Tame your Big Data! (영어)3. Cassandra - 유데미 From 0 to 1: The Cassandra Distributed Database (영어)데이터 엔지니어는 예전부터 있었다.오늘은 빅 데이터 엔지니어에 대해 알아보았습니다. 사실, 빅 데이터 엔지니어는 어느 날 갑자기 생겨난 직업이 아닙니다. 데이터베이스를 관리하는 프로그래머가 더 나은 기술 스택을 익히고 더 좋은 방법으로 데이터를 수집하고 관리하면서 생겨난 것입니다.세상은 빠르게 변한다고 하지만 그 안을 들여보면 서서히 발전한 것들이 다르게 네이밍(Naming) 되면서 새롭게 다가오는 것이라 생각합니다. 그렇다고 해서 그것이 변하지 않는 것이 아닙니다. 새롭게 변하는 기술들을 익히고 자신의 역량을 갈고 닦아야만 새롭게 다가오는 변화에 휩쓸리지 않고 주도할 수 있는 것 같습니다.

풀스택 개발자라는 용어가 가끔 등장한다. 죄송하지만, 한국에서는 이 용어가 정말 잘못 이해된 상태로 사용되고 있다. 처음에 만들어진 의미와 뜻이 한국에 들어오면서 변한 것을 보는 것이 이번만도 아니다.언제나처럼, 이 '단어'가 의미하는 뜻은 '귤이 회수를 건너면서 언제나 탱자가 되는' 한국적인 환경에서는 매우 이상하게 와전된 의미로 사용되고 있다. 특히나 비개발자들인 경영진들이 그러하고, 개발자들도 가끔 잘못된 의미로 사용한다.와전된 의미의 '풀스택 개발자(Full Stack Developer)'는 프런트엔드와 서버 엔드를 넘나드는 모든 것을 다 아는 전지전능한 개발자인 것처럼 쓰인다. 죄송하지만, 풀스택 개발자의 의미는 프런트-엔드부터 서버-엔드까지 모든 것을 다룰 줄 아는 개발자를 의미하는 것이 아니다.이 '용어'가 쓰이는 분야를 조금은 국한시켜야 할 필요가 있다.그것은 '웹'환경의 프론트 영역으로 국한시키는 것이 매우 현명할 것이다. 다음의 링크를 참조하기를 권한다.http://www.sitepoint.com/full-stack-developer/위의 사이트에 있는 이미지와 단어를 차용한다. 아래의 그림을 살펴보라.[이미지출처 : http://www.sitepoint.com/full-stack-developer/ ]OS부터 Database, WebServer, Server Side Code, Browser, Client Side Code를 아우르는 능력을 가진 사람을 Full-Stack Developer라고 부를 수 있다.좀 더 쉽게 이야기하자면, 'Web'환경은 서버사이드 코드와 클라이언트 사이드 코드를 모두 이해하고 작성되어야 한다. 브라우저( 특히나 변덕스러운 호환성 문제들.. )의 스크립트 환경이 효과적으로 가동되기 위해서는 웹서버의 API를 적절하게 디자인하고 구현된 상태에서 동작되어야 하며, 대부분의 코드들은 직접 Database에 영향을 주는 경우가 많다. 더군다나, 소프트웨어 개발을 하려면 형상관리부터 배포 처리를 위한 기술도 할 줄 알아야 한다.맞다. 'Web'개발 환경에서는 Full-Stack Developer가 되지 않으면 제대로 된 개발이 어렵다. 그래서, '웹'에서는 풀스택 개발자를 지향해야 하고, 매우 당연하게 해당 스킬들을 익숙하게 다루어야 한다.풀스택 개발자는 Web의 개발환경에서는 어쩔 수 없이 매우 당연한 기술적인 한계이고 해야 할 업무를 위해서는 필연적인 형태 인 것이다.이렇게 '웹 환경에서의 풀스택 개발자'는 한국에도 많이 존재한다. 상당수의 PHP개발자 분들이 그러한 '풀스택 개발자'인 경우가 많다.그렇지만, 이 풀스택 개발자의 용어는 '개발'이나 '소프트웨어'를 잘 모르는 경영자의 머릿속으로 잘못 들어가서 마치, iOS나 Android APP도 개발하고 Rest API 디자인이나 구현도 하면서, AWS의 분산 환경에 대한 이해나 개발도 모두 가능한 '전지전능한 개발자'와 같은 의미로 잘못 사용되기도 한다.( 더군다나, 디자인능력이 극도로 필요한 자바스크립트나 능동형 웹-UI를 만들어 내는 능력은 전혀 다른 능력이다 )원래 의미의 '풀스택 개발자'는 '혼자서 웹서비스 하나를 만들 수 있는 개발자'라는 좁은 의미로는 맞다. 하지만, 이를 과도하게 해석하거나 아전인수격으로 해석하는 것은 매우 곤란하다. 그것은 바로 한국적인 특수한 환경 때문에 그러하다.슬프지만, 한국적인 의미의 풀스택 개발자가 존재하기는 하고 있다.프로그래머가 기획도 하면서, 서버 구입부터 설치까지 다진 행하고, DB도 일부 다룰 줄 알면서, 웹이나 클라이언트 프로그래밍의 일부도 할 줄 아는 매우 한국적인 풀스택 개발자가 존재하기는 한다. ( 근데, 그런 개발자들을 풀스택 개발자라고 표현하지 않는다. 거의 기업의 잡부(?)처럼 부려지는 경우다. )노가다 - dokata, 土方 -'막일'을 하는 노가다를 하는 잡부가 한국형 풀스택 개발자라고 표현하겠다.하지만, 그런 테크트리로 형성된 한국형 풀스택 개발자들의 실력은 매우 볼품이 없는 경우가 대부분이다. 필자가 공공 SI현장에서 만난 수많은 한국형 풀스택 개발자들이 그러했다.그들은 컴파일러가 만들어내는 에러 메시지에 대한 이해는 없지만, 10년 넘게 업무를 배운 경험과 대충 Linux나 Windows Server의 기본적인 경험과 온통 스파게티 식으로 구성되어진 소스로 만들어진 더 이상 시장이 커지지 않는 한계가 다다른 시장에서 소프트웨어 개발을 하고 있다.태생적으로 '잡부'가 될 수밖에 없는 작업현장에서 진정한 의미의 풀스택 개발자는 거의 형성되기 어렵다. 이런 한국형 풀스택 개발자들은 실제 하나하나의 스킬들을 확인하거나 체크해본다면 거의 대부분 매우 부족하거나, 특정 기능에만 적합한 일반적으로 쓸모없는 기술들이 대부분일 가능성이 크다고 단언하겠다.이런 경향은 게임업계도 비슷하다. 한국형 풀스택 게임 개발자는 게임 기획부터 스프라이트의 2D부터, 포토샵이나 일러스트레이트도 다룰 줄 알며, 3D Max로 3D도 만들고, Auto-Cad로 도면 데이터도 다루고, DirectX에 Unity도 다루며, 서버나 iOS의 앱까지 만들 줄 안다고 하지만, 정작 그 어느 하나도 제대로 못 다루는 경우가 태반이다.물론, 전부 다루는 사람이 없는 것은 아니다. 있기는 있지만... 그분들 굉장히 유명하거나 특정 기술하나 가 대가의 수준이기 때문에 자신이 가진 다른 기술들을 포함해서 자신을 '풀스택 개발자'라고 포장하지 않는다.하지만, 한국에서 유독 '개발자 구인 광고'를 보면 '풀스택 개발자'를 찾는 곳이 많은 이유는 무엇 때문일까?그것은, 무지한 경영진이나 무지한 비즈니스 모델, 무지한 리소스 활용이 난무하는 헬게이트의 주인들이나 그런 단어들을 주로 사용한다고 보면 된다.100% 단언컨대 한 사람의 개발자가 완벽한 풀스택 개발자라고 하더라도, 요구사항이 발생하고 유지보수업무가 존재하는 업무를 하드웨어적인 서버 관리부터 서버 API, 앱 프로그래밍, 웹 프로그래밍을 하기 위한 스킬은 알 수 있다고 하더라도 그 복잡하고 어지러운 업무량은 모두 다룰 수 없다.만일 그런 것이 가능하다고 이야기하는 경영진이 있거나 무지한 영업맨이 있다면 정신 차리라고 조언해주자. 심지어 그렇게 만들 수 있는 서비스는 존재하지 않고, 존재한다고 하더라도.. 어마어마한 '기술적 부채'가 존재하며, 대부분의 가장 비싼 개발자의 리소스를 그 기술적 부채를 해결하기 위해서 사용되고 있을 것이라고.물론, 그렇게 동작하는 허접하고 쓰레기 같은 코드라고 하더라도, 특정 조건과 특정 환경에서는 서비스가 가능한 경우가 한국에는 많이 존재한다. 경영진이나 영업, 기획은 고객들을 설득하고 고객들이 해당 제품과 서비스를 사용하기 위해서 일부를 희생할 것이다. 그리고, 분명 다른 영역에서 누수가 발생하거나 희생되고 있는 것을 잊지 말자.특히나 경쟁이 없는 제품이거나 더 이상 리소스를 투입하기 어려운 소프트웨어나 서비스의 경우에는 이런 형태로도 동작은 할 것이다. 하루에 한두 번 서버의 Oracle 커넥션을 모두 종료하는 유지보수 행위를 하는 전산실의 업무가 그러한 경우 때문에 벌어진다.중견기업이거나 제조업체, 병원의 전산실에 '야간 당직'업무가 있고, 시스템 모니터링에 민감하다면 대부분 '기술적 부채'를 안고 허접하게 만들어진 것뿐이라고 판단하면 된다.말 그대로, 헬조선의 헬게이트, 헬(!)한 업무환경으로 소프트웨어 개발자로서 비전이 없는 영역이라고 생각하면 된다. 하지만, 그럼에도 불구하고... 스타트업 경영진이나 대기업, 중소기업 경영진들은 '풀스택 개발자'의 환상에 대해서 이야기한다.'모든 것을 다 하는 개발자'가 있으면, 복잡한 커뮤니케이션 비용도 안 들고, 인건비도 적게 들것이라는 착각을 한다. 다만, 이 부분만큼은 명쾌하게 이야기하겠다. '그런 회사 가지 말라'는 것이다.'풀스택 개발자'를 구인하고 있는 회사는 개발자의 무덤이라는 것이다. 대부분 그러하다. 그 이유를 다음과 같이 정리하겠다. 그들이 '풀스택 개발자'를 뽑고 싶은 이유는 간단하다. '돈'이 없어서다. 그리고, 다음의 이유들이 있는 경우이다.하나. 경영진이 요구사항 정의도 제대로 못하므로 개발자와 의사소통에 자신이 없다. 그래서, 풀스택 개발자를 구하려고 한다. 한 명 하고만 이야기하면 될 것이라고 착각한다.둘. 개발자의 인력이 몇 명이 투입되는지에 대해서 평가나 정의가 불가능하므로, 풀스택 개발자를 구하려 한다.셋. 개발자가 두 명, 세명이 있다면 팀 리더도 있어야 하고, 관리자도 있어야 하므로 그 비용을 줄이기 위해서 풀스택 개발자가 필요하다. 한마디로, 돈이 없다.넷. 현대의 웹서비스들을 가동하기 위해서는 최소한의 비용과 인건비가 투여된다. 이 비용을 투자할 정도로 비즈니스 모델에 가치가 없기 때문에 여러 명의 개발자를 고용할 수 없기 때문에 풀스택 개발자를 구하려 한다.다섯. 풀스택 개발자라면 막연하게 다 해줄 것 같은 환상을 가진 경영진이 있는 경우이다. 슬프지만, 전설의 개발자인 '제프 딘'을 고용한다고 하더라도, 삽질을 할 것이다.물론, 스타트업에 초기에 합류하면서 CTO의 역할을 부여받았다면 조금은 입장이 달라진다. 정당한 지분을 받고, 미래의 가치에 대해서 나눌 수 있다면, 해당 롤을 가진 사람은 알아서 '풀스택 개발자'가 될 가능성이 크다. 그러므로, 매우 당연하지만 CTO는 풀스택 개발자에 근접되면 좋기는 할 것 같다. 하지만, 현실적으로는 그렇게 세팅하지 못하는 경우가 대부분이다.그리고, 냉정하게 초기 개발이나 Lab수준, 시리즈 A를 투자받기 전의 '소프트웨어'나 '서비스'는 대부분 비즈니스 모델을 증명하는 수준에서 끝내는 것이 바람직하다. 굳이, 환상의 개발자나 풀스택 개발자가 아니라도 비즈니스 모델을 검토하고 증명하는 모델을 구현하는 것은 충분하게 가능한 경우가 대부분이다.사용자가 수백만 명도 아니고, 구현된 기능들도 수백 가지가 아니며, 아직은 스파게티 식으로 구성하더라도 무방하기 때문이다. 해당 기술적 부채는 서비스의 증명 후에 해당 코드는 버려지고, 다시 개발팀을 제대로 세팅하여 구현하면 되기 때문이다. 더군다나, 대부분의 스타트업은 고속 개발을 해야 하기 때문에 '풀스택 개발'이 가능한 '웹'만으로는 모든 것을 커버하기 어려울 것이다.좌우지간, 간단하게 이야기해서 '풀스택 개발자'타령하는 구인광고를 보게 된다면, 그 회사나 팀은 무언가 잘못 생각하고 있거나, '돈'이 없는 조직이라고 생각하면 된다. 거기에, '기술'이나 '개발'에 대해서는 아무것도 모르는 사람이 사장이 존재하는 곳이라고 생각하면 된다.헬게이트에 입성하고픈 개발자라면 '풀스택 개발자'를 구인하는 곳으로 가면 된다. 엄청난 '일'의 쓰나미를 경험하고, 인성이 피폐해지는 것을 경험할 것이다.필자는 국내 최고의 개발자들을 여럿 알고 있다. 하지만, 그분들은 자신들을 '풀스택 개발자'라고 이야기하지 않는다. 그 용어가 의미하는 것 자체가 '날림'이라는 것을 너무도 잘 알고 있기 때문이다. 물론, 10년 20년을 소프트웨어 개발을 하다 보면 얻어지는 경험과 지식들이 있다.궁극적으로는 풀스택 개발자가 이야기하는 비슷한 테크트리를 대부분 알고는 있게 된다. 하지만, 경력 20년 되고 하나의 도메인에 익숙하며, 특정 분야의 대가인 분들을 스타트업에서 고용한다는 것은 거의 불가능에 가깝다. 간혹, 그런 분들이 직접 스타트업을 하는 것이라면 모를까 말이다.이제 이야기를 마무리하겠다.'웹 개발'을 하려면 '풀스택 개발'을 지향하는 것은 맞다. 하지만, 그것 자체가 완벽한 풀스택 개발을 의미하는 것이 아니라는 것을 생각하기 바란다. 그리고, 경영진이나 비개발자들에게도 다시 한번 이야기한다. '풀스택 개발자'를 구인하겠다는 환상을 버리기 바란다.그런 사람 없고, 있다고 하더라도... '풀스택 개발자'를 구인하겠다는 발상으로는 절대 초빙하거나 모실 수 없다는 것을... 깨몽 하기 바란다.물론, '풀스택 개발자'처럼 이것 저것 다하는 정성스럽고, 일에 애정 넘치는 개발자들을 제대로 대우해주시기를... 기술로써의 풀스택 개발자가 아니라, 그 기업이 원하는 일을 풀스택 개발자처럼 일할 뿐이다. 그들에 대한 애정 넘치는 말한마디... 경영진들에게 부탁드린다.갑자기, '풀스택 개발자'에 대한 환상에 대해서 정리하고 싶어서 한 번에 글을 써 내려갔다. ~.~

대부분의 프로젝트는 실패한다. 처음 세웠던 계획대로 진행되는 경우는 거의 본적 없다.원숭이도 나무에서 떨어지고, 아키텍트도 당연하게 실패를 자주 만나게 된다. 그리고, 프로젝트는 언제나 성공하지 않는다. 성공과 실패를 거듭할 뿐이다. 여기서, 실패를 어떻게 다루느냐에 따라서 아마추어와 프로의 차이는 극명하게 구분된다.아마추어는 실패를 변명하기에 급급하지만, 프로는 실패를 냉정하게 인정하고, 실패를 하게 된 이유를 찾고, 똑같은 실패를 반복하지 않기 위해서 실패의 원인에 대해서 분석하고 리뷰한다.많은 실패를 거듭할수록 전문가가 된다. 전문가는 실패를 반복하지 않기 위해서 언제나 실패에 대해서 필요한 리뷰 스킬을 높이게 된다. 이번 이야기에서는 필자가 지켜보았던 미니 프로젝트의 하나를 기준으로 실패에 대한 이야기를 해보도록 하겠다.여기서 이야기하는 프로젝트는 처음부터 실패가 될 것으로 예견되었다. 그리고, 그 예견된 결과대로 실패했다. 결론적으로 해당 팀이 해체되었고, 관련된 개발자들은 흥미를 잃고 해당 업체를 떠나게 되는 상황까지 진행되었다.문제가 더욱 심각한 것은 이러한 실패의 이유에 대해서 예견되었고, 그 문제를 지적하고, 향후 그 처리방안을 경영진에게 제시하였지만, 결론적으로 회사의 리더의 생각이 변화하지 않았기 때문에 ‘실패에서 주는 경험’이 제대로 전파되지 못했다. 하지만, 아키텍트는 이러한 실패에 대해서 분명하게 기록해두고, 다시 그러한 실패를 하지 않도록 준비를 하는 것이 전문가로 성장하는 가장 중요한 버릇 중의 하나라고 이야기하겠다. 아키텍트가 아니라고 해도 개발자는 자신만의 노트로 '실패'를 기록해야 한다."어떤 실패한 프로젝트에 대한 리뷰"실패에 대해서 정의할 수 있는가? 이 기준에 대해서 느슨하게 적용하게 되면 대부분의 프로젝트는 실패할 이유가 없어지며, 매우 엄격하게 적용하게 되면 대부분의 프로젝트는 실패라고 기록될 것이다.필자는 프로젝트의 성공과 실패의 요소에 있어 가장 중요한 것은 ‘비용’이 계획보다 많이 투자되었다면 그 프로젝트는 ‘실패’라고 평가를 한다. 가능하다면, 아키텍트를 목표로 하고 있는 개발자라면 모든 프로젝트의 기준과 투입인력, 시간과 하드웨어 리소스들을 모두 ‘비용’으로 환산하는 방법을 터득하는 것이 좋다.가능하다면, 필자는 이 기준으로 프로젝트를 평가한다.이 기준에 따라서 필자가 지켜본 미니 프로젝트를 평가해보자. 소프트웨어 개발자의 실제 일하는 것들이 모두 비용이고, 그들이 투입되고 생각하고, 무언가를 하는 행위들은 대부분 ‘비용’으로 모두 환산할 수 있다. 이러한 비용을 기준으로 프로젝트에 투입되게 되면 초기에 필자가 프로젝트의 기준을 세우는 원칙은 다음과 같다.소프트웨어 디자인과 기획에 30%, 실제 개발에 50%, 테스트에 20%를 투여하는 법칙이다. 다만, 이 수치에서의 약간의 차이는 투입되는 팀원이나 회사의 사정에 따라서 조금씩 달라지기는 하지만, 필자는 가능하면 저 수치를 지키려 한다.그동안의 필자의 경험으로 느껴지는 저 수치는 약간의 조정이 있을 수 있으나, 대부분의 국내의 프로젝트에서는 대부분 일치하거나 근사치로 정의될 것이다. 이번 이야기에서 언급하려는 프로젝트는 2013년도에 필자가 실패한 프로젝트의 사례에 해당한다.이 규칙에서 기획에 30%의 투자가 있었어야 했는데, 실제 초기 기획에 2%도 안 되는 투자 후에 실제 개발이 진행되면서, 프로젝트가 제대로 진행되지 않는 케이스가 발생하였다.물론, 이번의 케이스는 작은 스타트업에서 매우 작은 외주 프로젝트를 진행하는 일이었는데, 실제 프로젝트에 참여할 팀원의 구성이나 팀워크, 주된 목표치에 대한 설정 등이 제대로 서술되지 못하면서 기획이 제대로 진행되지 못한 케이스가 되었다.작은 모바일 프로젝트였고, 필자가 판단하기에 4주면 넉넉하게 해결될 프로젝트가, 필자의 계산착오로 4개월간 뒤틀린 프로젝트가 벌어지게 된 것이다. 필자는 왜 이런 실수를 하게 된 것일까?기본적은 린 개발 방법이나 에자일 방법과 같은 방법론의 문제가 아니라. ‘초기 기획’이 부정확한 상태에서, 팀워크도 갖추어지지 않고, 소통이 안 되는 팀원들이 보고체계가 붕괴된 상태에서 프로젝트가 지속되면서, 팀 자체가 와해되어 버린 아주 엉터리같이 진행된 프로젝트가 되어버렸다.필자도, 이러한 대대적인 실패에 대한 경험을 정말 오래간만에 한 셈이 되었는데, 결론적으로는 프로젝트를 수행할 제대로 된 팀원을 제대로 세팅하지 못한 ‘인사’에서 그 문제는 시작되었다고 프로젝트의 실패 원인 중에 가장 큰 원인을 지적하고 싶다.목표도 불확실한 상태에서 기획이 제대로 진행이 안되었고, 서버 개발자의 능력 부족에 아이폰과 안드로이드 앱 개발자의 자기 멋대로의 전횡과 서버 개발자가 이중으로 서버 인터페이스를 구현하면서 보고체계까지 제멋대로 진행된 아주 최악의 프로젝트가 진행되었다는 것을 거의 프로젝트 후반부에 가서야 알 수 있었다. 말 그대로 전형적닌 실패사례가 된 것이다.결론적으로 이야기하자면, 가장 먼저 이야기한 ‘기획’이란 팀 빌딩과 목표 수립과 같은 부분에 대해서 제대로 된 접근을 수행했어야 했는데, 이 부분에 대한 고려와 협의 없이 진행되면서 프로젝트가 일정에 떠밀려서 진행되면서 프로젝트가 상당히 누더기가 되어버렸다.어떻게든 중간에 올바른 방향으로 유도하려고 하였으나, 언제나 입버릇처럼 말하듯이 ‘한번 기본이 뒤틀린 경우에는 다시 바로 잡을 수 없다’가 정답이고, 그 여파로 인하여, 많은 비용과 시간적인 소모, 정력적인 소비까지 매우 불유쾌하게 진행된 프로젝트였다.결론적으로 이 프로젝트는 마무리는 되었지만, 이 프로젝트를 참여하게 된 팀원들은 모두 해산되고, 서버 개발자만 빼고는 모두 팀에서 해체가 되게 되었다. 물론, 이 프로젝트 이후에 해당 문제들을 보완한 상태에서 다시 프로젝트는 본래의 궤도로 올려놓기는 했지만, 이렇게 진행된 부분에 대해서는 명세 화가 절실하게 필요하고, 이를 리뷰해야 한다.이 프로젝트의 가장 큰 원인은 개발에 참여한 개발자나 디자이나, 기획자나 PM의 문제가 아니라, 전체적인 개발의 틀을 만들어 주어야 하는 ‘개발회사의 경영진’이 가장 큰 문제였다. 말 그대로 ‘인사’ 문제였다. 그중에 몇 가지의 문제들에 대해서 언급해보자."개발자의 의사소통의 문제"후반부에 개발과 관련된 보고체계의 문제점은 서버 개발자와 클라이언트 개발자 간의 의사소통과 의사결정에 대해서 개발자들 간에 ‘숨겨왔던 문제’가 드러났다. 가장 큰 원인은 ‘보고’를 제대로 하지 않았다는 것이다.안드로이드와 iOS의 앱 개발을 동시에 진행하였는데, PM이 인터페이스를 ‘동일’하게 추상화해서 구현하라는 방향성에 대해서 클라이언트 개발자들과 서버 개발자들이 서로 협의한 것이 아니라, 서버 개발자가 클라이언트 개발자들의 요구조건을 모두 받아들여, 인터페이스가 두배로 늘어나고, 테스트와 관련된 처리 방안들이 모두 증가하게 된 것이다.실제, 클라이언트에서 구현해야 하는 상당 부분의 기능들을 서버에서 구현하게 한 것은 향후 Web개발을 일부 처리하기 위한 방안이었는데, 이 부분들이 모두 무시된 채로, 클라이언트 개발자들 간에 자신이 하고 싶은 개발을 추진하면서, 서버 개발자가 의지 없이 끌려다닌 결과물이었다.당연하지만, 개발 일정이 늘어나고, 테스트도 진행되지 못하면서, 품질이 저하되는 것뿐만 아니라, 전체적인 프로젝트가 모두 붕괴되었다. 참으로 애통스러운 상황을 지켜보아야 하는 마음은 참으로 아픈 경험이다.그래도, 최악의 프로젝트였지만 ‘테스트’가 좀 더 명쾌했다면, 이 프로젝트는 초기에 문제를 잡을 수 있을 가능성이 있었다. 그래서, ‘테스트’에 대해서 몇 가지 더 정리해봤다."테스트, 그 계획과 실행의 전부"과연, ‘테스트의 적정선은 어느 정도 인가?’. 소프트웨어 개발에 있어서 테스트에 투입되는 비용이나 기간에 대해서 근접한 수치를 보여주거나 적절한 경험성을 부여하는 경우가 매우 드물다. 다만, 경험자의 직관에 의존하는 경우가 많거나, 각 개발사의 프로세스에 따라서 정형화되어 있는 경우가 많다.실제 자기 자신에게 다음의 화두들을 던져보자.정말로 테스트 커버리지 100%의 테스트란 존재하는가제품 개발 시간과 테스트 코드의 비율은 어느 정도가 적정한가?개발에 착수하기 전에 테스트를 얼마나 준비해야 하는가?통합 테스트는 매번 해야 하는가?테스트 전담자는 있어야 하는가?TDD는 비용 합리적인가?과도한 테스트란 어떤 것을 의미하는가?실제 개발환경에서 테스트란 무엇인가?현장 품질 커버리지란 무엇인가?테스트에 대해서 위의 질문에 대해서 독자들은 얼마나 명쾌하게 답변을 할 수 있을까? 아마도, 다음번 칼럼에는 테스트에 대해서 좀 더 자세한 이야기를 할 것으로 계획을 잡고 있다.테스트에 대한 유명한 Kent Beck의 말을 인용해보자.I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.나는 코드가 작동하는지에 대해 보수를 받지, 테스트를 위해서는 보수를 받지는 않는다. 그래서 나의 철학은 신뢰할 수 있는 수준에 도달하기 위해 가능한 한 테스트를 적게 한다는 것이다.(신뢰할 수 있는 수준이라는 것은 업계 표준에 비해 높다. 조금 거만한 들릴지 모르지만). 만약 전형적인 실수(생성자에서 다른 변수를 설정하는 것 같은)를 하지 않는다면, 나는 테스트하지 않는다.-Kent Beck의 말소프트웨어 개발자들에게 테스트 환경과 테스트 조직, 테스트 문화에 대해서 강요하는 것이 바람직한가?라는 물음에 필자는 이렇게 이야기하고 싶다. ‘개발자’에게 ‘테스트’를 강요하지 말고, ‘테스트한 경과’를 제시하고 ‘수정’과 ‘제대로 된 결과’를 강조하라.일반적인 소프트웨어 개발에 대해서 무지한 사람들의 반복적인 질문은 ‘소프트웨어 개발자들은 왜 테스트를 소홀하게 하는 가?’라는 질문을 버그가 발생할 때마다 이야기를 한다. 대부분의 소프트웨어 개발은 ‘목표’가 불명확하기 때문에 ‘버그’가 발생한다고 생각한다.아마도, ‘개발자’에게 사용자의 ‘제약사항’과 ‘하지 말아야 할 행위’에 대한 언급이 없었다면, 개발자는 문제 해결을 위하여 상당 부분 위험요소를 건너뛰거나 넘어서게 된다. 물론, 적절한 여유시간과 품부 한 리소스를 제공한다면, 당연하겠지만. 튼튼한 소프트웨어를 만들기 위해서 노력한다. 하지만, 일정이 정해지고, 목표가 명확한 SI성의 프로젝트의 경우에는 ‘목표’를 향해서 가장 빠른 코드를 만들기를 강요하기 때문에, 이때에 만들어지는 ‘버그’의 대부분은 개발자의 실수이기보다는, ‘요구사항’에 대한 부정확한 전달 때문이다.별 요구사항이 없는 것 같은 DataGrid를 만들어 달라고 이야기를 했지만, 사실, 고객은 Excel정도의 기능을 원하고 있다. 하지만, 일정과 비용상의 문제 때문에 단순 데이터의 표현을 위한 DataGrid인 것처럼 요구를 하는 경우가 대부분이다.이때에 개발자는 당연한 것처럼 최소한의 제약사항과 요구사항을 통해서, ‘숫자’만을 처리할 수 있는 DataGrid를 만들지만, 고객은 개발에 착수함과 동시에 다양한 요구사항들을 요구한다. 문자열을 처리해달라, 날짜, 함수 등등… 그리고, 종이 출력도 자연스럽게 되게 해달라고 한다.개발자는 중간에 발생한 요구사항과 제약사항에 최대한 맞추려고 기능들을 구현하다 보면, 당연한 것처럼 특정 이슈만 처리하는 기능으로 구현되고, 다른 프로세스에서는 당연한 듯이 버그와 같은 현상을 발생시킨다.그럴 때에 고객은 이야기하고, 개발회사의 사장도 이야기한다. ‘개발자가 테스트도 없이 소프트웨어를 만들고 있다’고. 이것이 현실이다.대부분 소프트웨어 개발에 대해서 무지하기 때문에, 이런 일이 반복된다. 필자도, 이러한 경험을 최소한으로 하려고 하였지만, 역시. 회사의 대표가 되어서 프로젝트의 계약부터 관여하기 전에는 이러한 문제들을 모두 해결할 수 없다는 것이 정답일 것이다.필자는 단언한다. ‘소프트웨어 개발자에게 넉넉한 일정과 풍부한 리소스를 제공하지 못한다면, 소프트웨어 개발자가 모든 것을 해결할 것으로 기대하지 말아라’. 다만, ‘소프트웨어 개발자들이 보다 원활하게 개발에 전념할 수 있도록 다음과 같은 필수조직이 따라붙어야 한다.하나. 요구사항에 대해서 고객과 꾸준하게 소통할 수 있는 담당자나 조직둘. 정해진 일정에 맞추어 기능이 동작할 수 있게 하는 테스트 담당자나 조직하지만, 보통의 스타트업이나 작은 SI를 전담하고 있는 기업의 경우에는 위의 가장 중요한 두 조직이나 담당자들이 대부분 부재중이거나 기능이 모호한 경우가 많으며, 위의 두 가지 기능을 모두 담당 개발자의 책임으로 귀속시킨다.만일 이러한 기능이나 리소스를 모두 담당 개발자에게 귀속시키고 있는 회사나 조직에 있다면, 조직을 다시 만들거나, 해당 기업을 빠른 시일에 빠져나가는 것이 가장 현명한 방법일 것이다. 대부분 소프트웨어 개발에 무지한 경우에 이 두 기능을 너무 소홀하게 하고, 개발자들이 대부분 야근과 휴일근무를 밥먹듯이 하게 되는 경우가 이에 해당된다.실제 필자 또한 경험이 풍부했지만, 실제 기업의 인사권과 경영권이 없었기 때문에 이에 대해서 해결할 수 없는 경우를 또 만났기 때문이다. 그래서, 또 실패했다. 아무리 경험 많은 사람이라고 하더라도, 이미 알고 있는 내용이라고 하더라도. 그것을 실제 바꾸지 못한다면, 필패한다는 것이 소프트웨어 개발의 현장이다.그래서, 필자도 크게 실패한 경험을 또 하나 기록에 남기게 되었다."체계적인 품질관리 지표"개발과정에서 발생되는 요구사항의 지표에 대해서 NIPA의 SW Visualization을 참조하면 요구사항 추적성, 요구사항 달성률, 요구사항 커버리지의 3가지 지표에 대해서 서술하고 있다. 여기서, 달성률과 커버리지는 100% 처리가 되는 것을 목표로 움직이는 정략적인 지표로 보면 되고, 실제 개발현장에서 주목할 부분은 요구사항 추적성을 주목해야 한다.개발 공정별로 요구사항의 일관성이 어떻게 유지되고 있는지 확인하면서, 형상관리가 등록된 내용의 변경률과 비교하면서 요구사항의 변화된 추이를 꾸준하게 주목해야 한다. 대부분, 이 부분 때문에 개발이 뒤틀리는 진입점을 제공하게 된다.품질검증에서 사용되는 정적인 테스트는 ‘코딩 표준 준수율’과 ‘메트릭 만족률’, ‘정적 분석 이행률’을 기반으로 진행된다. 대부분 이 정적인 테스트는 ‘자동화 도구’를 사용하여 코드의 룰과 만족 여부를 확인하기 때문에 결국은 ‘개발 비용’을 얼마나 투자하느냐에 달려있는 부분이라고 할 수 있다. 특히, ‘정적 분석 이행률’과 같은 SW 실행 전에 잠재적인 결함을 분석하는 것은 이러한 투자 없이는 대부분 이룰 수 없는 수치이다. 그래서, 보통 ‘정적 테스트’는 제대로 갖추어진 개발 조직이 아니라면 성립하기 어려운 지표가 된다.보통, 이 ‘정적 테스트’ 지표를 얼마나 진행하고 있느냐에 따라서, 소프트웨어 개발 조직의 성숙도를 체크할 수 있으며, 소프트웨어 개발 조직에 얼마나 투자를 하고 있느냐에 대해서 알 수 있는 지표이기도 하다.보통은 품질검증에서 동적 테스트로써 요구사항 검증방법과 구조 검증방법이 진행되는데, 마찬가지로 구조 검증인 구조적 커버리지 또한 Basic path, Statement, Branch, MD/DC Coverage 등을 선택해야 하므로, 이 또한 개발 조직의 투자 없이는 이루어지기 힘들다. 그래서, 대부분의 개발 조직 현장에 가보면 기능 검증, 비기능 검증, 정형 검증, 사용자 검증 중에 기능 검증과 사용자 검증만을 취해서 품질검증을 하는 경우가 대부분이다.소프트웨어 개발자에게 ‘품질검증’을 제대로 요구하기를 원하는 조직이라면, ‘정적 테스트’를 수행할 수 있는 투자나 일정, 준비 또는 품질 관련 조직이 세팅되어 있어야 한다. 이러한 단계 없이, 개발자에게 ‘테스트’를 제대로 하지 않는다고 강요하는 개발회 사는 정말 크게 잘못된 케이스라고 보면 된다. 그런 회사는 배울 것도 없으니 피하는 것이 최선이다.또한, 기능 검증이나 비기능 검증 또한 테스트 케이스에 대한 자동화된 방법들을 사용하지 않는 다면, 이 또한 개발자에게는 상당히 모호한 테스트들만이 존재하게 된다."좌우지간, 소프트웨어 개발의 시각화"소프트웨어 개발의 경험자라고 하더라도, 소프트웨어 개발 현장에서 일어나는 일들을 모두 파악할 수 있는 방법은 ‘지감’밖에 없을 것이다. 그래서, 소프트웨어 개발에 있어서 적정한 범위까지 개발의 과정을 ‘시각화’하는 기준이 필요하다.하지만, 이 ‘시각화’는 말 그대로 ‘과비용’으로 책정되거나, 소프트웨어 개발을 하기도 어려운 일정과 시간에 촉박한 경우에는 이 시각화의 최소 영역에 대해서 고민하고 결정해야 한다. 완전한 시각화를 이룰 경우에는 소프트웨어 개발 관리조직과 품질조직, 테스트 조직 등의 PM관리체계가 완비되어 있는 경우에만 이러한 과정을 수행하는 것이 최선이다.그리고, 중요한 케이스나 문서 등에 대해서 품질관리 조직과 PM조직이 해당 문서를 작성하는 것이 되어야지, 각 개발자에게 이러한 업무를 전가하는 방식으로 진행되어서는 문제가 해결되지 않는다. 언제나, 품질조직은 옥상옥이 되어서는 안된다.2/2페이지결론적으로 '능력 부족한 개발자'소리를 듣는 것이 대부분이다.대부분 급하다고 일을 의뢰하거나 서비스 론칭을 위해서 급하게 요구하는 경우가 있다. 개발자의 선택은 매우 명쾌하다. 정해진 기간과 인원 숫자로 만들어야 하는 서비스가 특정한 시간 내에 동작하게 하는 방법은 동작시에 제약사항과 커버하지 못하는 품질 이슈를 만드는 것뿐이다.말 그대로 기술적 부채를 만들어 낼 수밖에 없으며, 이 기술적 부채는 결론적으로 반복적인 유지보수 업무와 처리하지 못하는 기능들에 대한 하소연을 만들어 낸다.슬프지만 그렇게 반복되는 과정에서 경영진은 해당 개발자를 신뢰하지 못하게 된다. 그리고, 그렇게 반복적인 유지보수 업무를 만든 것은 개발자의 능력 부족이라고 생각하게 되고, 이 관계는 보고서가 늘어나거나 주간회의시에 디테일하게 보고하라는 식의 결론으로 귀결된다.물론, 이런 상황을 만든 '착한 개발자의 결정'이 문제이기는 하다.대부분 경험이 풍부한 개발자들은 이런 과정들을 반복해 보았기 때문에 처음부터 거부하거나 거절하거나, 적정한 선에서 타협하는 방안들을 제시한다. 물론, 그 과정에서 무지한 경영진과 트러블이 발생하는 것도 다반사이다.이 경우 중간관리자가 개입해서 타협하는 경우가 분명 있다.단언컨대 해당 중간관리자는 둘 중 하나이다. 무지하거나 난파하려는 개발 조직을 재빠르게 떠날 사람이다.소프트웨어 개발에서 '급한 일'이란 없다.정해진 규칙과 기본에 충실하게 하고, 빠진 것 없는지 체크하고 디자인, 설계 후에 미래의 변화에 대해서 적절하게 해당 조직의 규모와 형태에 따라서 반영한 후에 '개발'하는 것이다.지금 이상황에도...'급한 일'이라면서 일을 가져다주는 경영진을 만나고 있을 슬픈 개발자들을 위해서...끄적끄적...#와탭랩스 #와탭 #프로젝트 #인사이트 #경험공유 #조언

멋진 서비스를 제공하기 위해 잘 만들어진 앱을 개발하는 것은 중요합니다. 하지만 출시 이후 앱 운영을 통해 사용자 Retention과 Engagement를 유지 및 증가시키는 것 또한 앱을 잘 개발하는 것 만큼이나 중요하고 많은 고민과 노력을 들여야합니다. 그런 관점에서 Firebase는 앱을 운영함에 있어서 고민할 법한 다양한 기능들을 적절히 잘 모아놓은 서비스인 것 같습니다.스타일쉐어에서도 Crashlytics, Remote Config, Analytics 등 Firebase에 포함된 서비스들을 잘 활용하고 있습니다. 그래서 Firebase에 개선 및 변경 사항이 있다면 항상 주의 깊게 살펴보고 있습니다.https://events.google.com/io/올해도 어김없이 Google I/O가 개최됐습니다. 역시나 흥미로운 주제들이 많았습니다만, 이번 글에서는 앞서 언급한 Firebase 에 추가된 새 기능을 다룬 ‘What’s new in Firebase’ 세션에 대해서 공유드리고자 합니다.세션에서 주요 골자는 다음 4 가지입니다.ML Kit 베타 시작Test Lab iOS 플랫폼 지원Performance Monitoring 개선Google Analytics 개선이 글에서는 이 4 가지 내용에 대해서 정리하도록 하겠습니다.ML Kit 베타아직까지 베타 버전이긴 합니다만 ML Kit 를 통해 Machine Learning 을 앱에서 쉽게 활용할 수 있다고 하니 Machine Learning 이 한층 가까워진 느낌입니다.ML Kit 는 Android, iOS 양 플랫폼 모두 지원합니다. 따라서 앱에서 Machine Learning 을 활용해 서비스를 제공해보고 싶다면, 양 플랫폼 모두 시도해볼 수 있겠네요.What’s new in Firebase (Google I/O ’18) SlideML Kit 은 기본 API 를 제공합니다. 이 API 들은 Machine Learning 에 대한 폭 넓은 배경지식이 없더라도 충분히 활용할 수 있기 때문에 저처럼 막막한 느낌이 드는 분들은 아래 기본 API 5가지를 사용해서 먼저 친해져보는 것도 좋겠네요.텍스트 추출얼굴 인식바코드 스캔이미지 라벨링렌드마크 인식ML Kit 은 on-device 와 cloud 에서 모두 동작하기 때문에 상황에 맞게 적절한 방식을 사용하면 된다고 합니다. 예를 들어 사진앱 처럼 네트워크 연결이 중요치 않은 서비스의 경우에는 on-device 를 통해 오프라인으로도 동작이 원활하게 만들 수 있겠네요.또한 Machine Learning 에 대한 배경 지식이 충분하다면 TensorFlow-Lite 모델을 통해 직접 원하는 학습을 시킬 수도 있습니다.ML Kit 은 Android, iOS 양 플랫폼 모두 사용 가능하며 기본으로 제공하는 5가지 이외에도 향후에 더 추가될 예정이라고 합니다. 추가될 기능들에 대해서 조금 더 일찍 테스터로서 경험해보고 싶다면 waiting list에 메일을 등록하면 됩니다.Test Lab iOS 플랫폼 지원Test Lab 은 다양한 디바이스를 모두 고려한 앱을 개발하기 어려운 Android 플랫폼의 특징을 보완하기 위한 서비스입니다. 주로 UI 테스팅과 관련된 기능들을 제공하며, 좀더 쉽고 편하게 UI 테스팅을 작성하고 다양한 디바이스에서 테스트할 수 있는 환경을 제공해줍니다.What’s new in Firebase (Google I/O ’18) Slide앱을 서비스 할 때 Android, iOS 어느 한 쪽 플랫폼만 개발하는 경우는 드문 것 같습니다. 그래서인지 Firebase 팀도 iOS 지원에 항상 신경을 쓰는 것 같은 인상을 받았는데, 이번 경우도 그런 느낌이 강하게 듭니다.이번에 추가된 iOS 용 Test Lab 을 활용한다면 출시 전 Android와 iOS 모두 동일한 기준으로 품질 상태를 확인하고 배포할 수 있는 환경을 갖출 수 도 있겠네요. iOS용 Test Lab 은 다음 달에 정식으로 선보일 예정입니다만, 이 기능 또한 일찍 테스터로 참여하고 싶다면 waiting list에 메일을 등록하면 됩니다.Performance Monitoring 개선Performance Monitoring 의 베타 기간이 끝나고 정식으로 서비스를 한다고 합니다. Crash-free 도 중요하지만 사용자 입장에서 고려해봤을 때 앱의 퍼포먼스도 놓치면 안되는 중요한 요소입니다. Performance Monitoring 은 이런 관점에서 인사이트를 얻을 수 있게 도와주는 서비스라고 합니다.What’s new in Firebase (Google I/O ’18) Slide세션에서 강요한 기능은 New Issues Feed 입니다. Performance Monitoring화면의 상단에서 확인할 수 있는 이 기능은 단순한 데이터를 나열하는 것이 아니라 자체적인 분석을 통해 가장 최근에 해결해야할 이슈를 제안합니다.What’s new in Firebase (Google I/O ’18) Slide이 외에도 디바이스에서 렌더링할 때나 네트워크 요청을 할 때의 이벤트들을 기록해서 퍼포먼스 저하 요소들을 보여줍니다. 덕분에 어떤 부분에서 퍼포먼스 저하가 가장 심한지 보다 쉽게 파악할 수 있다고 합니다.Performance Monitoring 은 별도 코드 없이 모든 페이지에서 자동으로 데이터를 수집하고 있으니 별도의 노력없이 인사이트를 얻을 수 있다는 점이 또 다른 장점입니다.Google Analytics 개선What’s new in Firebase (Google I/O ’18) SlideGoogle Analytics 에서 두드러지는 개선 점은 Project level reporting이 가능해졌다는 것 입니다. 플랫폼 별 사용자 특성이 있기는하지만 하나의 서비스 차원에서 병합해서 데이터를 보고싶은 경우가 종종 있는데, 그럴 때 마다 별도의 서버 처리를 통해 병합하는 과정이 번거로웠습니다. 하지만 이번 개선을 통해서 프로젝트 단위의 데이터 분석이 가능해진 덕분에 번거로움을 좀 덜어낼 수 있겠습니다.그리고 세션에서 언급하진 않았지만, Filter가 조금 더 유연해지고 세분화된다고 합니다.지금까지 ‘Google I/O 2018: What’s new in Firebase’ 세션 중 주요 내용만 간단하게 살펴봤습니다. Firebase 는 매년 발전을 거듭해가며 앱 운영의 통합 관리 서비스로서의 자리매김을 해나가는 중인 것 같습니다. 덕분에 직감에만 의존해서 앱의 방향을 정하던 예전에 비해 정량적 데이터에 기반을 두며 더 성공에 가깝게 한발짝 씩 다가갈 수 있는 것 같습니다.이번에 Firebase 에 새로 추가된 기능들을 조금씩 건드려보면서 우리 서비스에서 어떻게 활용하며 인사이트를 얻고, 서비스를 이용하는 사용자들에게 더 나은 서비스를 제공해 줄 수 있을까 고민해봐야겠습니다.#스타일쉐어 #개발자 #개발팀 #인사이트 #Firebase #경험공유 #일지 #후기

콜라보레이션!스타트업들 간의 협업은언뜻 멋져 보인다.취지도, 명분도뭔가 그럴듯해 보인다.우리가 강한 경쟁자를 상대하기에부족한 것들을 같은 처지의 스타트업끼리뭉쳐 이겨낼 수 있을 것 같다.이론상 참 좋은 연합이다.(출처: 만화책 "드래곤볼카이" 중에서 퓨전합체)그런데 실제로는 어떠할까?나도 콜라보레이션의 취지는 좋게 생각한다.분명 장단점이 있고,콜라보를 통해 서로 시너지를 낸 선례들도 있다.근데 그게 그냥 "같이 합시다"라고 뭉친다고잘 되는 게 아니라더 신경 쓰고, 양보하고, 신뢰해야 하며,에너지가 많이 소비되는 형태이다.부족한 것은 상대방이 채워줄 것 같지?아니, 상대방도 너를 의존하고 있고,너에게 기대하는 바가 크기에제대로 뭉치지 않으면오합지졸 당나라 군대가 돼버리기 쉽다.우리 함께 연합해서 Win-win 하자고?괜히 어설프게 연합하다간함께 Lose-lose 할 수도 있다.무작정 뭉친다고 강해지는 게 아니다.오히려 서로에게 악영향이 되고,서로에게 감정만 상할 수도 있다.그럼 콜라보레이션은어떻게 해야 제대로 운영될 수 있을 까?1. 리더가 필요하다.양 무리에도 리더가 있다.둘 이상의 콜라보에서 동등한 의사결정이이상적으로 보일지는 몰라도업무를 수행하는 데 있어서 누군가는 전체 연합을조율하고, 이끌어가야 할 보다 강한 리더십이 있어야 한다.스타트업들 간의 연합의 취약점은바로 체계가 없음이다.동등한 위치에서,평등한 의사결정을 꿈꾼다면평행선을 달릴 일도 많아진다.우리에게 시간이 넉넉하고,자금이 풍족하다며시장이 우리의 제품/서비스를 기다려 준다면그 사이에 우리 모두 웃음꽃 피우며좋은 게 좋다고 끝없는 토론의 장을 가질 수 있겠지.한정된 시간과늘 부족한 자금과눈 깜빡할 새 변하는 변덕스러운 시장을순간순간 체크해야 하는데...누군가는 앞서서 진두지휘를 해야 한다.이게 참 말이나 글로 적긴 쉬운 건데실제로 적용되는 건 어려운 일이다.이리저리 신경 쓰기엔창업자가 할 일이 참 많잖아.2. 목적이 명확해야 한다.콜라보로 우리가 얻을 수 있는 것이 무엇인지에 대한명확한 목표/목적이 있어야 한다.양보할 수 있는 부분은 무엇이고,물러 설 수 없는 부분은 무엇인지를 확실하게 알려야 한다.이게 어정쩡하면,뒤에서 아쉬운 소리가 나올 수밖에 없다.두 가지 문제가 있더라.일단 뭔가를 잘 정의를 못 내리는 문제.우리가 왜 콜라보를 해야 하고,무엇을 위해서 해야 하는지 그다지 선명하지 않았다.두 번 째는상대방의 목적이 무엇인지 모르겠더라.뭐 상생이라던가,파트너십이라던가 참 듣기는 좋은 말인데...그래서 어쩌라는 건지,뭘 어떻게 하자는 건지너무 두리뭉실하다 보니...결국 거절을 하였다.서로의 목적이 다르면,서로 딴 주판을 튕기게 되고,그 끝은 서로에 대한 원망과 후회가 남는다.그나마 서로의 목적이 다르다는 것을 알기라도 한다면의견을 조율하고, 협의를 할 수 있겠지만서로 무슨 목적을 가지고 있는지 관심이 없을 때도 있다.그보다 콜라보를 해야 할 자신들의 근거조차스스로 모를 때가 더 많다고 해야 하나?3. 서로 신뢰할 수 있어야 한다.상대방을 믿을 수 있느냐가 가장 큰 벽이다.스타트업과 스타트업 간의 협력은대표들끼리 쿵짝쿵짝 코드 맞춘다고 돌아가는 게 아니다.구성원들 모두가 공감하고커뮤니케이션이 원활해져야 하는데...더군다나 자주 만나지도 못 하고,어쩌다 이슈가 생길 때만서로 연락 주고받는다면콩가루 스타트업 연합이 되지 않을까?사실 우리에게도 몇 번인가 콜라보 제의가 들어왔었다.그중 두 번 진행을 해봤다.한 번은 Good case, 한 번은 Bad case처음에는 뭣도 모르고  바로 계약서 준비하려 한 때가 있었다.(상대 쪽 대표가 착하고, 좋아서...)분쟁의 소지를 미연에 방지하기 위해서계약서는 큰 도움이 되는 것은 사실이니까.하지만 다시 생각해보니계약서는 굳이 쓸 필요를 못 느끼겠더라.괜히 계약서에 싸인 잘 못 했다가,우리 멤버들이 고생은 고생대로 하고,우리 방향에서 벗어날까 봐하는 노파심이 들었다.그래서 우리는 콜라보 제의에크게 비중을 두지 않은 상태에서확인 작업을 한다.아주 작은 사소한 일을 함께 해 본다.그리고 일이 진행되는 과정을 확인한다.그러다 몇 번의 소소한 미팅이 동반되는작은 일을 같이 해 본다.그리고 결과적으로신뢰할 수 있는 상대라고 판단되면,계약서를 준비한다.최근에 두 곳과 이런저런 일로작은 일을 진행하고 있는데...글쎄...좀 시간과 거리를 두고더 신중하게 접근하고 있다.신뢰라는 것은갑자기 생기는 것이 아니라관찰과 행동에서 나오는 것이다.팀빌딩에 신중했듯이,협업도 신중해야 하고,확인해야 하고, 복기해야 한다.힘들 때,우리는 누군가를 의지하고 싶어 진다.외로울 때,우리는 누군가 공감해 줄 사람이 그리워진다.그러한 감성적인 이유는콜라보레이션의 타당성을 주지 못 한다.논리적이고 합리적인 타당성이 없는콜라보레이션은 서로에게 죄를 짓는 것이다.오랜만에 스타트업 대표들끼리식사를 한 적이 있다.그 자리에서 한 분이연합 이야기를 꺼내셨다.어떤 대표들은 박수를 치며 환호를 하였지만,어떤 대표들은 고개를 절레절레 흔들었다.(출처: 게임 삼국지10, 황건동란, 도원결의)삼국지의 유비, 관우, 장비의 도원결의에 대해지극히 현실적이고 냉철하게 상상해보자.뜬금없이 술 한잔 나누면서 뭉친 모습으로상상하고 있는 건 아니겠지?그들이 서로를 몰랐겠는가.유비가 누구이고, 어떤 상황에 놓여 있는지,관우는 어떤 사람이고, 무엇을 중요시 여기는지,장비는 성격이 어떻고, 무엇이 관심사인지...그리고 그들이 공통적으로 꿈꾸는 목적이무엇인지 제대로 나누지도 않은 채그냥 꽃잎 날리는 복숭아나무 아래에서술 한 잔 주거니 받거니 하며의형제를 맺었겠는가.서로 다른 환경에서다른 삶을 살아왔던셋이 모여 리더(유비)를 정하고,더 필요한 누군가(공명)를 영입하고,후원자와 병사들을 모으고황건적의 난이라는 시기적절한 타이밍에그들이 전면에 등장하지 않았던가.단지,동지애만으로,즉흥적인 분위기에 휩쓸려서,아는 사람들이니까,백지장도 맞들면 낫다니까이런 말도 안 되는 이유로연합하자는 것은다 죽자는 거다.혼자 가는 길보다는 같이 가는 길이더 좋을 거라 착각하지 말자.같이 가는 길이 같은 방향일 때,같이 가는 동료가 서로에게 도움이 될 때,동행이 의미있고, 행복한 길이 되는거지무작정 함께라고 꽃길이 되지 않는다.함께 동행한다고 안심했는데그 길이 낭떠러지로 향하는 길일 수도 있다.이 글을 쓰는 말미에 꼭 남기고 싶은 말이 있다.스타트업 간의 연합 또는 콜라보레이션이나쁘다는 주장으로 오해하지 마시라.어정쩡한 콜라보레이션을 피하자는 것이다.방향이 없는, 목적성이 없는, 신뢰가 없는그런 연합을 만들지 말라는 것이다.실제로콜라보레이션이 성공한 케이스는너무나도 많다.그들이 성공한 이유는서로에게 시너지를 줄 수 있는제대로 된 콜라보레이션이었기 때문이다.한 가지만 더 첨언하자면,우리가 좋은 스타트업과 함께 동행하길 원한다면,우리도 상대에게 좋은 스타트업으로 준비되어 있어야 한다.세상은 Give and Take!줄 것이 있어야 받을 것이 있고,우리에게도 무언가가 있어야상대방의 필요를 채워 줄 수 있다.오늘도스타트업 창업자 동지들을 응원합니다.#클린그린 #스타트업 #스타트업창업 #초기창업 #창업자 #고민 #응원 #인사이트

CFO인터뷰어제 옐로모바일의2015년 실적 발표가 있었죠.약3,200억원의 매출과470억원의 영업손실을 기록하며 한 해를 마무리했는데요,연 단위의 적자이긴 했으나 마지막4분기에 매출1,000억원과 소폭이지만 영업이익 흑자전환을 이루어낸 것에 대해서는 긍정적인 여론이 형성되고 있는 것 같습니다.국내외 다양한 유니콘 및 독보적 스타트업들이 수익성 확보에 어려움을 겪고 있는 것을 감안할 때,이 정도 규모의 분기 매출 및 흑자전환은 옐로모바일의 재무 성장성 및 건전성에 대해 새로운 시각을 갖게 하는 기회가 될 수도 있을 것 같다는 생각이 들었는데요,이와 관련하여 이상훈CFO와 간단하게 몇 마디 나누어 보았습니다.드디어 분기 영업이익이 흑자로 돌아섰는데요,감회가 새로우시겠어요.하하 실은 예상된 시나리오대로 진행 중이라 실적에 대한 긴장과 감동이 있지는 않습니다만, 그래도 영업적자대신 영업이익이라는 단어를 쓰게 되니 기분은 좋네요 :) 많은 분들께서 잘 모르고 계시는 사실이 있는데요, 옐로모바일은 2014년 상반기까지 영업이익 흑자를 기록하던 회사입니다. 2014년 하반기부터 사업 규모 확장 및 성장 촉진을 위해 다방면의 투자를 시작했고, 2014년 포메이션8 (Formation8)의 투자 이후 2015년 상반기에는 투자 규모를 보다 확대했죠. 이로 인해 2014년과 2015년 각각 영업손실로 한 해를 마무리하긴 했지만,애당초 옐로모바일은 수익을 충분히 낼 수 있는 체력을 확보한 상태였습니다. 수익의 규모를 늘리는 것이 관건이었죠.특히 이번 2015년 연말 실적은 3분기까지 회사 자체적으로 진행했던 가실적 발표가 아닌 금융감독원이 지정한 지정 감사인의 공신력 있는 감사를 통과한 성과라 더 의미가 있습니다. 감사인의 판단 기준에 따라기존 발표내용보다 분기별 영업손실 기준이 조정되어 4분기 영업이익이 20억원대 후반 수준까지 갈 수 있었는데 가지 못한 점은 좀 아쉽지만요.그럼2016년은 영업이익 흑자를 기록할 수 있을 것으로 보시나요?물론입니다. 2015년 투자의 많은 부분이 쿠차에 집행되었는데,쿠차는 이미 월 단위의 흑자전환을 이루었고,계속해서 성장할 플랫폼입니다.또 다른 집중 투자 대상이 미디어 사업을 이끌고 있는 피키캐스트인데,피키캐스트는 올해부터 본격적으로 수익화를 준비하고 있습니다.올 해 안에 연 단위의 흑자 달성은 무리일 수 있지만,적어도 연 내에 월 단위의 흑자는 낼 수 있을 것으로 기대하고 있습니다.이에 더해 광고,여행, O2O사업은 원래도 흑자를 내 온 사업들이기에, 2016년은 무리 없이 연 단위의 영업이익 흑자를 기록할 것으로 예상되며, 2017년이 되면 다섯 개 사업 그룹 모두가 각자 흑자를 달성할 것입니다.그렇군요.그럼 조금 다른 방향에서 질문을 드려볼까 합니다.실은 옐로모바일은 아직 스타트업이고 비상장사인데,왜 이익을 내는데 집중하고 계신가요? 여타의 주목받는 스타트업들도 아직 적자를 기록하고 있는 것으로 알고 있지만 여전히 이익보단 성장에 초점을 맞추고 있는 것 같은데 말이죠.저희가 이익에만 집중하고 있는 것은 절대 아닙니다.성장하는 회사에게는 어찌 보면 매출 성장(Top-line Growth)이 더 중요할 수 있고,그렇기에 저희도 지속적으로 외형적 성장을 이어가고 있습니다.네이버, 카카오, 옐로모바일의 2015 분기별 매출 비교다만,결국 외형적 성장의 끝에 있는 목표는 수익이죠. 국내의 주요 스타트업들 역시 궁극적으로 훌륭한 수익 기반을 마련하기 위해 전략을 수립하고 실행하고 있을 것이라 생각합니다.유니콘의 단계를 넘어선 기업이 수익성을 확보하지 못했을 때 생기는 문제가 조금씩 드러나고 있는 곳이 오늘날의 실리콘밸리인 것 같아요.최근 타임지(TIME)에서도트위터(Twitter)의 수익성 문제를 지적한 적이 있죠.트위터는 상장 이전에 이미4억 달러 이상의 누적 적자를 기록하고 있었고,상장 이후 상황이 극적으로 호전되지 못하고 있는 실정입니다.최근3년 연속 영업손실을 기록하고 있죠.옐프(Yelp)역시 고전을 면치 못하고 있는데요, 2015년4분기에2,200만 달러의 적자를 보이며 네 분기 연속 적자를 기록,주가 관리에 어려움을 겪고 있습니다.물론 상장사이기 때문에 이러한 문제에 더 노출되어 있는 것은 맞습니다.그렇다고 해서 비상장 기업이 성장을 위해 수익성을 간과해도 된다고 생각하지는 않습니다.제가 꼭CFO여서 그러는 것이 아니라,안정적인 수익에 기반하여 성장할 수 있는 회사가 가장 이상적이지 않을까요?그런 의미에서 옐로모바일은 오늘도 성장과 수익이라는 두 마리 토끼를 잡는 쉽지 않은 길을 계속해서 걸어가고 있습니다.기업의 존재 이유가 이윤 추구만은 아닐 것입니다.그러나 동시에 기업의 생존과 지속 가능성을 위해 필수적인 요소가 수익인 것은 부정할 수 없는 사실이죠.스타트업이 언제부터 수익을 내야 하는지에 대한 정답은 없는 것 같습니다.또한 성장성과 수익성이 항상 상반되는 개념도 아닌 것 같고요.빠르게 성장하는 회사가 이익까지 낼 수 있다면,정말 더할 나위 없는 상황이겠지만,설령 둘 중 하나가 조금씩 정체되더라도 꾸준히 나아지는 모습을 보이는 것이 가장 중요한 것이 아닐까 싶습니다.옐로모바일이 어제보다 오늘,오늘보다 내일이 나은 회사가 될 수 있기를 기대해 보며,이상Y였습니다.

외부 전문가의 도움을 받아 역량을 더더 성장시킬 수 있도록 에이스프로젝트에서는 사외 교육비를 전액 지원하고 있습니다.  본인의 업무와 관련이 있는, 역량발전에 도움이 되는 교육이라면금액에 관계없이 사외 교육비를 전액(100%) 무제한 지원합니다!실제로 회사에 걸어둔 포스터!2017년에 에이스인이 들었던 교육 리스트를 살펴 보면,기획팀 - 엑셀VBA, 프로젝트 관리 교육그래픽팀 - Adobe After Effects, 타이포그래피 컨퍼런스프론트 - 회계, 글쓰기 교육개발팀 - 파이썬 컨퍼런스, 개발자 컨퍼런스 참여 등다양한 분야의 교육을 수강했습니다. 꾸준히 공부하는 에이스인!에이스프로젝트는 교육비 뿐만 아니라 교육 받을 수 있는 시간도 지원합니다.평일 낮 교육이어도 업무 스케줄을 조율해, 얼마든지 교육을 받으러 갈 수 있습니다. 교육 듣는 날은 공결!! 개인 연차를 소진하지 않습니다 :)교육을 들은 후에는 교육 내용이 궁금한 동료들을 위해 컨플루언스를 이용하거나 사내 발표를 통해 내용을 공유합니다. (나만 똑똑해지기 없기 ! 공유로 에이스인을 널리 이롭게 하자.)내 직무의 전문성을 높이기 위해 자격증에 도전하고 싶다면 그것도 OK!자격증 응시 비용도 지원해 드립니다. 두려워말고 자격 시험에 도전해보세요. 에이스프로젝트는 전문가가 되는 길을 응원합니다.회사에서 일만 한다고 생각하면 오산!에이스프로젝트는 회사와 직원의 성장 모두를 응원합니다♥︎(부러우면 지는거!!!)

폴 손 (Paul Sohn)은 그의 블로그에서 ‘문화는 어려움 속에서 반드시 전략을 초월한다’라고 썼습니다. (Here's How Leaders Create Healthy Organizational Culture, http://paulsohn.org/heres-how-leaders-create-healthy-organizational-culture/)시프티의 예를 들면, 비즈니스에 대한 경험이 전무한 두 명의 공동 설립자에 의해서 시작되었습니다. 사업이 계속 성장함에 따라 2017 년 9 월, 2 명의 팀원을 추가로 합류하였고 바로 그 때 시프티의 팀과 문화, 가치에 대해 다시 한 번 생각해 보기 시작했습니다.우리는 모든 회원들이 참여하기를 열망하는 독특한 문화를 육성하여 미래에 시프티 팀에 합류할 모든 구성원들에게도 자연스럽게 전달되게 하고자 했습니다. 시프티의 문화는 우리가 누구인지, 어떻게 사업을 함께 해 왔는지, 그리고 우리 모두가 시프티를 운영하는 데에 서로 동의하는 철학에서 비롯되었습니다. 그래서 우리 고유 문화를 구축하기 위해 2016 년 7 월 시프티 프로젝트가 시작된 후 첫 해를 되돌아 보고 팀과 공유할 시프티의 핵심 가치, 미션과 비전을 수립하였습니다.Unconventional첫 번째로, 우리는 우리가 누구인지, 다른 기업과 다른 차별성이 무엇인지를 아는 것이었습니다. 한 예로 우리는 한국에서는 다소 익숙하지 않을 수 있는 언어를 사용하여 기존 방식과 다른 제품 개발 프로세스를 수행했습니다. 또한 북미 지역에서는 스케줄링, 출퇴근 용 앱 또는 소프트웨어 시장이 상당히 포화 상태라고 말할 수 있지만 한국은 완전히 새로운 시장이었습니다. 중견 기업의 경우에도 오래된 방법으로 출퇴근을 기록하고 근무표 계획과 급여를 엑셀로 처리하는 전통적인 방법에 크게 의존하고 있습니다. 우리는 시프티의 익숙치 않은 언어를 기꺼이 배우고 일해줄 인력을 찾기 어려울 것이라는 예상과 새로운 시장을 개척한다는 위험을 가지고 시작하게 되었고 UNCONVENTIONAL이라는 가치는 시프티가 앞으로 나아가는 데에 있어 중요한 코어 가치가 되었습니다.Insight두 번째 핵심 가치는 INSIGHT입니다. 우리는 나날이 들어오는 사용자들에 신기했지만 많은 사람들이 시프티를 사용하지 않고 떠나는 것들으르 지켜보았습니다. 사용을 하든 떠나든, 우리는 그들의 요구와 불만을 듣는 데에 많은 노력을 했습니다. 이 과정 속에서 우리는 주로 많은 사용자들의 ‘원함’만을 들었습니다. 우선순위가 없는 의견들과 요청들이 난무하여 우선 순위를 정하는 데 어려움이 있었습니다. 시프티 서비스의 핵심과 사용자에게 제공하는 가치의 중심을 지키기 위해 합리적이지 않은 ‘원함’ 류의 피드백 대부분을 제거해야 했습니다. 우리는 비즈니스의 본질 인 사용자가 실제로 ‘필요’로 하는 것을 연구하기 시작했습니다. 우리는이 접근법을 취하면서 더 나은 통찰력을 가지게되었고 사용자가 정말 필요로 하는 기능을 구현할 수가 있었습니다. 우리는 팀에게 다음과 같은 메시지를 전하게 되어 자랑스럽습니다. “단순히 원하는 것이 아니라 사용자가 정말로 필요로 하는 본질을 찾자.”Flexibility제품 초기에는 MVP 만 있었기 때문에 대부분의 대기업 요구에 부응할 수 없었습니다. 그렇다고 당시에는 우리가 소상공인을 위한 문제를 완벽하게 해결할 수 있지도 않았습니다. 초기에는 제품의 성숙도가 낮아서 주요 타겟 시장으로 간주되는 소상공인의 니즈도 거의 처리하지 못했기 때문입니다. 저는 매일 새로운 자영업 사용자에게 시프티를 떠난 이유를 묻곤 했습니다. (MVP가 갓 나온 초기에 심각한 인게이지먼트와 리텐션 문제를 겪었습니다.) 시프티를 그만 두는 핵심 사유를 찾아내려는 많은 시도는 효과가 없었습니다. 많은 사용자는 시프티에서 무엇이 필요한 지를 정확히 표현하지 못했습니다. 우리는 마침내 소상공인으로부터 피드백을 얻는 것이 대기업의 피드백만큼 효과적이지 않다는 것을 알게 되었고, 사업의 방향성을 중소/대기업 중심으로 전환하게 되었습니다. 대기업은 직원 관리에 대한 절차가 확실하여 특정 기능 요청이나 귀중한 피드백을 세세히 제공할 수 있었기 때문입니다. 이러한 피드백들은 지금의 시프티로 성장하는 데에 결정적인 역할을 했습니다. 결국 시장반응에 빠르고 현명하게 변화하기 위해 pivot할 수 있었던 시프티의 세 번째 가치는 FLEXIBILITY입니다. (소상공인도 여전히 시프티를 편리하게 이용할 수 있습니다.)Customer Satisfaction and Openness마지막 두 가지 핵심 가치는 CUSTOMER SATISFACTION과 OPENNESS입니다. 우리는 고객의 니즈에 필수적인 서비스로 고객을 만족시키고자 합니다. 또한 팀 내에서 열린 문화를 가짐으로써 자유롭게 의견을 제시하고 협력을 촉진할 수 있는 환경을 만들고자 합니다. 우리는 계층적 보고 절차를 가진 전통적이고 엄격한 기업이 되고 싶지 않았기 때문입니다.핵심 가치:Unconventional: 다르다는 것을 두려워하지 않음Insight: 원하는 것을 제공하지 않고 사용자가 필요한 것을 제공Flexibility: 변화에 신속한 대응Customer Satisfaction: 고객을 만족시키기 위해 더 나아감Openness: 투명성과 협업을 수용, 구성원의 평등 추구우리가 위에서 확립한 다섯 가지 핵심 가치는 시프티 팀 내에서 공유될 것이며 궁극적으로 아래의 사명을 이루는 데에 기여할 것입니다.사명:올인원 솔루션을 제공하여 직원 근무일정 스케줄링, 출퇴근기록 및 급여정산 프로세스를 간소화합니다.기업의 운영 효율성을 향상시킵니다.고객이 직원 관리 비용을 절감 할 수 있도록 도와줍니다.#시프티 #고객가치 #핵심가치 #기업소개 #서비스소개

안녕하세요. 에이스프로젝트의 채용담당자 K입니다. (꾸벅)오늘은 에이스프로젝트 면접에서 꼭 만나게 되는 ‘우황청심책’에 대해 이야기해보려고 해요.이것이 말로만 듣던 에이스프로젝트 '우황청심책'!서류 합격! 즐거움도 잠시 면접 준비로 정신없던 날들이 지나고 드디어 면접일이 다가왔어요.오는데 고생한 지원자를 위한 물은 센스!면접을 보러 오는 지원자는 친절한 채용 담당자의 안내로 면접실에 들어선 후 우황청심책을 건네받습니다.지원자는 우황청심책을 읽으며 면접 전에 릴랙스하는 시간을 갖게 돼요.면접은 누구에게나 떨리고 긴장되는 시간이죠, 긴장한 탓에 본인의 모습을 제대로 보여주지 못하고 돌아가는 지원자도 정말 많습니다. 지원자에게도, 회사에게도 면접은 중요한 기회인 만큼지원자가 긴장을 풀고 최대한 본인의 역량을 잘 이야기할 수 있는 시간을 만들고 싶었어요.'면접 시작 전에 뭔가 읽으면서 긴장을 풀면 좋지 않을까?'라는 생각에서우황청심책이 탄생하게 되었죠!(이름에서도 느껴지죠? 제발 긴장을 풀었으면 좋겠다ㅠㅠ)우황청심책은 에이스프로젝트에 대해 알 수 있는 이야기들로 채워져있는 '스크랩북'이라고 생각하시면 돼요.첫 장을 열면, 지원자의 긴장을 풀어주기 위한 채용담당자의 따뜻한 편지가 지원자를 기다리고 있어요. 지원자가 가장 궁금해하는 채용 프로세스에 대한 내용도 깔끔하게 정리해두었죠.채용 담당자의 마음을 듬뿍 담아서 편지를 썼어요 (힘내세요!)지원 분야가 모두 다르니, 우황청심책도 '개발/그래픽/기획/프론트 편'으로 나눠져 있어요!본인이 지원한 직무를 맡고 있는 에이스人의 이야기도 확인해 볼 수 있답니다. '어서 와 에이스프로젝트는 처음이지?'예를 들면, 우황청심책 ‘개발 편’에는 서버 개발, 클라이언트 개발, R&D 개발에 대한 직무 인터뷰 내용이 있어요.직무 인터뷰뿐만 아니라, 면접 전에 우리 회사의 조직문화나 성훈님(대표님)의 생각에 대해 알 수 있는 회사소개와 성훈님의 인터뷰도 수록해두었죠.면접은 지원자에게도 이 회사에 대해 알아볼 수 있는 시간이니까요!에이스프로젝트의 조직문화를 간접적으로 느낄 수 있어요!성훈님(대표님) 생각 미리 보기 +_+사실 지원자의 긴장감을 우황청심책이 모두 없애줄 순 없겠지만,  심리적으로 회사와 가까워진 상태로 면접을 볼 수 있다는 점은 긍정적이지 않을까요?우황청심책이 여러분의 기량을 100% 발휘하는데 조금이나마 도움이 되었으면 좋겠어요!

OverviewAmazon Web Services(AWS)는 많은 고객들이 이용하고 있습니다. AWS를 이용하여 프로젝트를 운영하고 있다면 각종 서비스의 리소스를 모니터링 하는 게 귀찮게 느껴질 수 있습니다. 이번 글에서는 AWS 리소스를 효과적으로 모니터링할 수 있는 Cloudwatch 서비스를 소개하겠습니다.Cloudwatch는 통합 뷰를 확보하는데 필요한 데이터를 제공합니다. 뿐만 아니라 이벤트 및 리소스를 이용해 경보를 생성할 수도 있습니다.1. Events2. Logs3. Custom Metrics(맞춤형 지표) 생성하기4. Alarm 생성5. Dashboards쉬어가기: Query 언어가 지원하는 여섯 가지 명령 유형1. EventsCloudWatch Events는 정기적인 일정에서 트리거(trigger)되는 규칙을 생성할 수 있습니다.1.규칙 생성을 클릭합니다.2.대상을 호출할 일정을 설정합니다.호출 방식에는 이벤트 패턴과 일정 두 가지가 있습니다. 이벤트 패턴은 json 구조로 표현됩니다. AWS 서비스에서 발생하는 패턴과 일치하면 트리거가 동작합니다. 일정은 지정한 시간과 일치하면 트리거가 동작합니다.cron 또는 rate 표현식을 사용해 예약된 모든 이벤트는 UTC+09:00 시간대를 사용합니다. 최초 단위는 1분입니다.아래는 각각의 필드에 대한 일정 cron식 설명입니다.이번 예제에서는 특정 시간에 트리거되는 일정으로 설정하겠습니다.매일 4시에 동작하도록 설정19 + 9(UTC) - 24(하루) = 새벽 4시3.대상 추가를 선택해 호출할 대상을 지정합니다.Lambda 함수 외에 여러 서비스를 선택할 수 있지만 이번 예제에서는 Lambda 함수를 지정하여 구성하겠습니다.4.규칙의 이름과 설명을 등록하고 규칙 생성을 클릭합니다.5.규칙이 생성된 것을 볼 수 있습니다.2. LogsCloudWatch Logs는 운영 중인 애플리케이션 리소스를 기록하고 액세스할 수 있으며, 관련된 로그 데이터를 검색할 수도 있습니다.1.생성된 규칙이 지정된 시간에 동작하면 CloudWatch Logs에 로그 그룹이 생성된 걸 확인할 수 있습니다.2.Lambda 함수에서 실행된 로그 메시지를 확인할 수 있으며 필터링도 가능합니다.3.로그 그룹에 이벤트 만료 시점을 설정해 오래된 데이터는 모두 자동으로 삭제되도록 설정할 수 있습니다.3. Custom Metrics(맞춤형 지표) 생성하기모니터링하고자 하는 통계치를 직접 선정하고, CloudWatch로 보내 관리하는 지표를 생성해보겠습니다.1.Log Groups에 대한 지표를 생성하겠습니다. 해당 Log Groups에 ‘Filters’를 클릭합니다.2.’Add Metric Filter’를 클릭합니다.3.로그 지표에 대한 필터 패턴을 정의합니다.Filter Pattern* “INFO Success 200” → 세 단어를 모두 포함하는 로그 이벤트 메시지와 일치* “INFO - Start - End” → ‘INFO’ 포함된 메시지 중에 ‘Start’, ‘End’ 제외된 필터 로그 이벤트 메시지와 일치4.필터 및 지표 정보를 입력한 후 ‘Create Filter’를 클릭합니다.Metric Details* Metric Namespace → CloudWatch 지표에 대한 대상 네임 스페이스* Metric Name → 모니터링된 로그 정보가 게시되는 CloudWatch 지표의 이름* Metric Value → 일치하는 로그가 발견될 때마다 지표에 게시하는 숫자 값* Default Value → 일치하는 로그가 발견되지 않은 기간 동안 지표 필터에 보고되는 값5.두 가지 케이스의 필터를 생성했습니다.4. Alarm 생성단일 CloudWatch 지표를 감시하거나 CloudWatch 측정치를 기반으로 하는 수학 표현식의 결과를 감시하는 CloudWatch 경보를 생성할 수 있습니다. 지표가 지정된 임계값에 도달하면 자동으로 이메일을 보내는 Alarm을 만들어보겠습니다.1.추가된 지표 필터에 ‘Create Alarm’ 버튼을 클릭해 경보를 추가합니다.2.경보 세부 정보 및 수행할 작업을 정의합니다.경보 평가경보를 생성할 때, CloudWatch가 경보 상태를 변경하는 조건 세 가지에 대한 설정을 지정할 수 있습니다.기간은 경보에 대해 개별 데이터 포인트를 생성하기 위해 지표 또는 표현식을 평가하는 기간입니다. 초로 표시됩니다. 1분을 기간으로 선택하면 1분마다 하나의 데이터 포인트가 생성됩니다.Evaluation Period(평가 기간)는 경보 상태를 결정할 때 평가할 가장 최근의 기간 또는 데이터 포인트의 수입니다.Datapoints to Alarm(경보에 대한 데이터포인트)는 평가 기간에 경보가 ALARM상태에 도달하게 만드는 위반 데이터 포인트의 수입니다. 위반 데이터 포인트가 연속적일 필요는 없습니다. Evaluation Period(평가 기간)와 동일한 마지막 데이터 포인트의 수 이내면 됩니다.3.경보가 발생할 Alarm 상태와 알림 받을 이메일을 등록합니다.경보 상태/OK/ 지표 또는 표현식이 정의된 임계값 내에 있습니다./ALARM/ 지표 또는 표현식이 정의된 임계값을 벗어났습니다./INSUFFICIENT_DATA/ 경보가 방금 시작되었거나, 측정치를 사용할 수 없거나, 또는 측정치를 통해 경보 상태를 결정하는데 사용할 충분한 데이터가 없습니다.4.이메일 수신함에서 ‘AWS 알림 - 구독 확인’이라는 제목의 메일을 클릭합니다. 내용에 포함된 링크를 클릭해 알림을 수신할 것을 확인합니다. (AWS는 확인된 주소로만 알림을 전송할 수 있습니다.)5.이메일 수신함을 확인해 ‘Confirm subscription’을 클릭합니다.6.등록한 이메일이 확인되었습니다.7.AWS에 이메일이 정상적으로 등록되었는지 SNS Subscriptions 메뉴에서 확인합니다.8.Lambda를 실행해 Alarm 상태를 변경해보겠습니다.9.등록한 이메일 주소로 Alarm 메일이 도착했습니다.5. DashboardsCloudWatch를 통해 리소스를 손쉽게 모니터링할 수 있는 맞춤형 통계 기능입니다.1.Metric Filter에서 추가된 Custom Namespaces를 클릭합니다.2.생성된 Metrics를 선택한 후, Graphed metrics Tab을 클릭합니다.3.Metrics에 표시될 그래프를 설정합니다.1)그래프 제목 : testLambda12)그래프 표시 : 숫자3)그래프 라벨 : testMetrics-400, testMetrics-2004)통계 : 합계5)기간 : 1 Day4.수식을 응용하여 여러 형식의 Metrics 표현식을 추가하겠습니다.지표 수식 함수* METRICS() : 요청에 모든 지표를 반환* SUM(METRICS()) : 모든 지표의 합계* AVG(METRICS()) : 모든 지표의 평균* MIN(METRICS()) : 모든 지표의 최소값* MAX(METRICS()) : 모든 지표의 최대값* ABS(METRICS()) : 각 요소의 절대값* RATE(METRICS()) : 각 요소의 초당 변경 비율5.완성된 지표 Source를 복사합니다.{ "metrics": [ [ { "expression": "SUM(METRICS())", "label": "합계", "id": "e1", "stat": "Sum", "period": 86400 } ], [ { "expression": "AVG(METRICS())", "label": "평균", "id": "e2", "stat": "Sum", "period": 86400 } ], [ { "expression": "MIN(METRICS())", "label": "최소값", "id": "e3", "stat": "Sum", "period": 86400 } ], [ { "expression": "MAX(METRICS())", "label": "최대값", "id": "e4", "stat": "Sum", "period": 86400 } ], [ { "expression": "SUM(METRICS())/SUM(m1)", "label": "SUM(METRICS())/SUM(m1)", "id": "e5", "stat": "Sum", "period": 86400 } ], [ { "expression": "SUM(100/[m1, m2])", "label": "SUM(100/[m1, m2])", "id": "e6", "stat": "Sum", "period": 86400 } ], [ "testMetrics", "testMetrics1", { "id": "m1", "stat": "Sum", "period": 86400, "label": "testMetrics-400" } ], [ ".", "testMetrics2", { "id": "m2", "stat": "Sum", "period": 86400, "label": "testMetrics-200" } ] ], "view": "singleValue", "stacked": false, "region": "ap-northeast-1", "title": "testLambda1", "period": 300 } 6.Dashboard name을 입력한 후 ‘Create dashboard’를 클릭합니다.7.’Add widget’을 클릭해 Number 유형을 선택합니다.8.Source Tab에서 복사해 둔 지표 Source를 붙여 넣고, ‘Create widget’을 클릭합니다.9.위젯이 추가되었습니다. 추가된 위젯은 ‘Save dashboard’ 버튼을 클릭해야 최종 저장됩니다.10.이번에는 로그 메시지 결과를 확인할 수 있는 Query result 유형을 추가해보겠습니다. 먼저 Query result 유형을 선택합니다.11.로그 메시지에 조건을 추가해 필터링합니다.잠시 쉬어가기!: Query 언어가 지원하는 여섯 가지 명령 유형fields : 지정한 필드를 검색합니다. 필드 명령 내에서 함수 및 연산을 사용할 수 있습니다. 만약 @ 기호, 마침표(.) 및 영숫자 문자 이외의 문자가 포함된 로그 필드가 쿼리에 명명되어 있으면 해당 필드 이름은 억음 기호로 둘러싸야 합니다.filter : 하나 이상의 조건으로 필터링합니다. filter statusCode like /2\d\d/ → 필드 statusCode의 값이 200~299인 로그 이벤트를 반환합니다.stats : 로그 필드에 대한 지정된 시간 간격의 집계 통계를 계산합니다.sort : 검색된 로그 이벤트를 정렬합니다.limit : 쿼리에서 반환되는 로그 이벤트 수를 제한합니다.parse : 로그 필드에서 데이터를 추출하고 쿼리로 추가 처리할 수 있는 임시 필드가 하나 이상 생성됩니다.12.추가된 위젯은 이름과 사이즈를 조절한 후, ‘Save dashboard’ 버튼을 클릭해 최종 저장합니다.13.생성한 Alarm을 Dashboard에 추가하겠습니다.14.Dashboard가 완성되었습니다!Conclusion지금까지 CloudWatch 서비스를 소개했습니다. 이 서비스를 이용하면 로그와 지표를 쉽게 시각화할 수 있고, 작업을 자동화할 수도 있는 것을 확인했습니다. CloudWatch를 이용해 애플리케이션을 최적화하고, 원활하게 실행해보는 건 어떨까요. 분명 리소스를 효과적으로 다룰 수 있을 겁니다.글곽정섭 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만