스토리 홈

인터뷰

피드

뉴스

조회수 880

프로그래밍에는 왜 창의성이 필요하다고 할까요?

왜 프로그래밍에는 창의성이 필요하다고 할까요? 실제로 프로그래밍을 하다 보면 복잡한 문법을 이해하고, 암호 같은 에러를 차분히 해결해야 하니, 오히려 수학적이며 논리적인 사고가 더 필요해 보입니다. 그런데도 프로그래밍이 창의적이어야 하는 이유는 하나의 프로그램을 만드는 답이 여럿이기 때문입니다.답이 하나여도 가르치기 어려운데, 다양한 방법을 어떻게 가르쳐야 하는 걸까요? 또, 기상천외한 학생들의 코드를 보며 이해하고 교육하는 것이 얼마나 긴 시간이 필요하며 어려운 일인가요? 어디서부터 해결해나가야 할지 막막합니다.Elice 리서치 팀에서 하는 일 중 하나는 학생들의 수많은 코드 중 비슷한 타입들을 추려내는 것입니다. 코드를 몇 가지 타입으로 추려내고 나면, 선생님은 학생 하나하나의 코드를 보고 교육하는 것이 아니라, 비슷한 형태의 코드를 작성한 학생 그룹 전체에게 적절한 피드백을 줄 수 있습니다. 이렇게 그룹 전체에게 피드백을 준다면 선생님은 같은 시간에 더 많은 학생을 교육할 수 있을 것입니다.그럼 이제, 비슷한 코드를 어떻게 찾아내서 분류할지 이전 연구를 보며 알아봅시다. (현기증이 날 수 있으며, 다 이해할 수 없어도 괜찮으니 걱정하지 마세요!)지프의 법칙과 숙제 제출 패턴자연어 처리(Natural Language Processing;NLP)를 배울 때 자주 거론되는 사람이 있습니다. 바로 미국의 언어학자인 조지 킹슬리 지프George Kingsley Zipf인데, 이 사람이 만든 지프의 법칙은 자연적으로 일어나거나 생성되는 특정 정보들이 일정하게 나타내는 경향을 나타낸 것입니다. 지프는 영어로 된 텍스트를 분석하던 도중, 자주 쓰이는 단어를 순서대로 나열하면 각 단어의 빈도는 그 단어의 출현 순위에 반비례함을 찾아냈습니다. 영어에서 가장 많이 사용되는 단어 1~3위가 “the”, “of”, “and” 인데, “the”는 “of”의 약 두 배, “and”의 약 세 배의 빈도를 보입니다.이것을 수학적으로 표현하면, 일정 크기 이상의 영어 말뭉치(corpus)에 들어 있는 단어들의 개수를 전부 세서 그 단어들을 가장 많이 쓰이는 것부터 순위를 1위부터 나열했을 때, 특정 단어의 순위가 k 라면 (즉 전체에서 k번째로 많이 쓰인 단어라면) 그 단어가 말뭉치에서 쓰인 개수는 1/k에 비례한다는 것입니다. 이것을 그래프로 그려보면 다음과 같습니다. 재미있는 사실은, 여기에서 x축과 y축에 log를 씌워 보면 (이것을 log-log scale로 변환한다고 합니다.) 다음과 같은 직선 형태로 변환된다는 것입니다.이것이 도대체 숙제 제출과 무슨 관계가 있길래 이렇게 장황한 설명을 한 것일까요? 위에서 나온 지프의 법칙을 기억하시나요? 학생이 낸 숙제를 채점하다 보면 꽤 많은 학생이 비슷한 방식으로 숙제를 푸는데, 제출된 풀이 방식들을 비슷한 것끼리 묶어 분석해 보니, 이것 또한 지프의 법칙을 따른다는 것이 발견되었습니다. 예를 들어 가장 인기 있었던 풀이 방식으로 100명이 숙제를 제출했다면, 두 번째로 인기 있는 풀이 방식으로는 약 50명이 숙제를 제출했다는 뜻입니다.여기서 우리가 찾아낼 수 있는 인사이트는 무엇일까요? 첫째, 학생들의 숙제들을 비슷한 것끼리 묶을 수 있다면, 그리고 이 분류를 컴퓨터로 자동으로 할 수 있다면 조교가 채점하거나 코멘트를 할 때 써야 할 시간이 상당히 줄어들 것입니다. 둘째, 방법 서너 개에 대해서만 어떻게 채점할지 혹은 어떻게 코멘트할지에 대해 준비를 해놓으면, 그걸로 숙제 대부분을 채점/코멘트할 수 있을 것입니다. 대다수의 숙제는 몇 가지 인기 있는 풀이방식으로 만들어졌을 것이기 때문입니다.그러면 이제 다음 문제는, ‘비슷한 풀이 방식으로 푼 프로그램 코드’를 어떻게 찾아낼 것인가? 를 고민해봅니다. MIT의 Elena Glassman은 이에 대한 해법으로 Overcode를 제시했습니다.Overcode뉴스 기사나 책, 블로그 글 등 자연어로 이루어진 텍스트 데이터를 분석하고, 여기에 어떤 주제가 들어있는지 밝혀내는 연구는 많이 진행 됐습니다. 이를 위한 머신러닝 알고리즘 중 하나가 토픽 모델, Topic model 입니다(토픽 모델에 대해서는 다른 글에서 자세히 다룰 예정입니다). 그러나 토픽 모델링을 프로그래밍 문제에 실제로 적용하기는 쉽지 않습니다. 코드에 사용되는 문법이나 키워드가 자연어와 1:1로 매칭되지 않기 때문에, 기존에 자연어에서 사용되던 모델을 그대로 사용할 수 없기 때문입니다. 가령, 슬쩍 보면 무척 달라 보이는 아래 두 파이썬 코드는 사실 완전히 같게 동작합니다. 이 두 코드를 (사람들이 일상생활에서 사용하는) 자연어를 분석하는 모델로 분석한다면 제대로 된 결과를 낼 수 없는 건 당연합니다.def fibonacci(): parents, babies = (1, 1) while babies < 100 xss=removed>fibonacci()def fib(parents, babies): ‘’’ parents = 1 babies = 1 ‘’’ while True: print ‘This generation has {0} babies’.format(babies) parents = babies # set parents as babies babies = parents + babies # recursively add number of babies if babies >= 100: break fib(1, 1)Elena Glassman이 제시한 Overcode의 목적은 비슷한 로직으로 만들어진 프로그래밍 코드들을 모으는 것입니다. 이제 Overode가 어떻게 작동하는지 간단하게 소개하도록 하겠습니다. 가장 먼저 수행되어야 하는 것은 서로 다른 형식으로 쓰인 소스 코드들을 정리하는 것입니다. 소스코드 정리에는 주석 제거, 줄 및 공백/들여쓰기를 일정하게 맞추는 작업 등이 포함됩니다.Image from Overcode하지만 이 작업만으로는 충분하지 않습니다. 거의 같아 보이는 코드도 실제로 프로그램을 실행하기 전까지는 같은지 알 수 없고, 꽤 달라 보이는 코드도 실제로는 완전히 같게 동작할 수 있기 때문입니다 (여기서 같게 동작한다 함은, 결과를 같게 내는 것 이상으로 결과를 내는 중간과정이 완전히 같다는 것을 의미합니다). 다시 위로 돌아가, fibonacci() 함수와 fib(parents, babies) 함수를 살펴봅시다. 위 두 코드는 기존의 자연어 처리 기법에 따르면 완전히 다른 프로그램일 것입니다. 변수명이 달라서가 가장 큰 이유일 텐데, 사실 컴퓨터의 입장에서 변수는 어떤 값을 할당하는 공간에 불과하며, 그 공간에 어떤 이름을 붙이느냐는 중요하지 않습니다. 코드를 작성하는 것이 사람이기 때문에 공간에 편하게 이름을 붙이는 것뿐입니다. 서로 다른 프로그램에서 어떤 변수가 서로 같은 역할을 하는지, 컴퓨터가 알아내려면 어떻게 해야 할까요? (컴퓨터는 창의적이지 않습니다!)Image from OvercodeElena가 제시한 방법은 프로그램을 실행하면서 변수의 값이 어떻게 바뀌는지를 추적한 것입니다. 아래 두 코드를 보고, 한번 머릿속으로 프로그램을 실행해 봅시다. 학생 B의 코드는 for문으로 5의 3승을 계산했고, 학생 C의 코드는 while문으로 5의 3승을 계산한 것입니다. 학생 B의 코드가 실행됨에 따라 r이라는 변수가 어떻게 변하는지, 학생 C의 코드에서 result가 어떻게 변하는지 확인해보면 둘 다 1 → 5 → 25 → 125 의 값을 가지게 됩니다. 그렇다면 컴퓨터는 이렇게 판단할 수 있습니다. “B의 코드에서의 변수 r과 C의 코드에서의 result가 완전히 같은 방식으로 변하니, 같은 의미로 사용된 것이다.”Image from Overcode이제 같은 의미를 가지는 변수들을 알아냈다면, 컴퓨터는 쉽게 가장 “흔한” 이름으로 변수의 이름을 바꿔치기 합니다. 그러면 처음에 서로 다르게 보였던 코드들도 이제 같아질 것입니다.물론 이것이 다는 아닙니다. 예를 들어, 간단한 테스트 케이스들을 통해 결과를 비교함으로써 변수를 분석하기 전에 먼저 거르는 방법, 너무 흔한 변수들을 처리하는 방법 (예를 들어 완전히 다르게 동작하는 코드들에서도 반복문에서 사용되는 인덱싱 변수들은 같이 변화할 것입니다), 한 변수가 다른 의미론적으로 두 번 사용되는 경우 처리하는 방법… 등이 논문에는 더욱 자세히 적혀있습니다. 궁금한 독자들은 한번 논문을 읽어보도록 합시다.남은 문제들Elena가 제시한 방법은 위에서 보여준 예제와 같은 간단한 코드에서 꽤 잘 동작합니다. 예를 들어, 다음과 같은 문제들이 있습니다.a의 b승을 구해서 리턴하는 프로그램N번째 피보나치 숫자를 리턴하는 프로그램다항식의 미분 결과를 리턴하는 프로그램하지만 대학교에서 1학년만 넘어가더라도 이런 간단한 프로그램 과제는 내지 않습니다. 예를 들어 Elice에서 교육 중인 기초 프로그래밍/ 프로그래밍 유치원 수업을 듣는 학생들은 매우 많은 실습문제를 풉니다. 여기에서 푸는 과제들은 초반 몇 주가 지나면 이 정도의 간단한 프로그래밍 수준을 뛰어넘기 때문에, 코드가 꽤 길어지고 다양성이 생기게 되는데 이런 경우 이 방법은 잘 동작하지 않습니다.또 다른 문제는, 이 방법이 “동작하는” 코드에서만 작동한다는 것입니다. 예를 들어, 수강생들이 아직 기초 문법을 배우고 있다면? 제대로 실행도 되지 않는 코드를 만들었을 때, 비슷한 실수를 한 사람들끼리 묶어주고 싶다면? 아쉽게도 Elena가 제시한 방법은 이렇게 에러가 나는 코드에서는 동작하지 않습니다. 코드가 실행되지 않는다면 변수의 값의 변화를 추적할 수 없기 때문입니다.마치며이번 포스트에서는 학생의 제출 코드를 비슷한 것끼리 묶는(Clustering하는) 방법에 대해 간단하게 살펴 보았습니다. 학생이 낸 비슷한 답안을 모아주는 솔루션은 수학 문제 같은 단답식 문제, 혹은 영어 에세이같은 자연어에 대해서는 이미 상용화가 되어 있습니다. 영어 에세이의 경우 여러분들이 가장 친숙할 만한 상용화된 솔루션은 아마 copy detector일 것입니다.하지만 프로그래밍 코드의 클러스터링은 연구가 계속 진행되고 있습니다. 앞서 말했듯 코드에서 한 글자 한 글자가 가지는 의미가 자연어에서 가지는 알파벳과는 완전히 다르기 때문이기도 하고, 정말 실행을 해 보기 전까지는 어떻게 동작하는지 예측하는 것이 매우 어렵기 때문이기도 합니다. Elice 리서치 팀에서도 프로그래밍 코드에 대한 분석을 자동으로 수행하는 머신러닝 연구를 수행하고 있습니다. 이러한 기술을 통해 선생님이나 조교가 학생을 더욱 효율적으로 지도하고, 컴퓨터의 도움으로 지도에 아낀 시간을 한 단계 더 개인화된 도움을 주도록 하는 것이 Elice의 목표 중 하나 입니다.글쓴이김수인: KAIST 전산학부 박사과정 / Research Lead, Elice김재원: KAIST 전산학부 박사과정 / The Lead, Elice배휘동: KAIST 전산학부 박사과정 / Frontend Lead, Elice#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개
조회수 1774

아키텍트, 개발 리더십의 변화...

보통, 하나의 서비스를 개발하는데 얼마나 걸리며, 그 시간 동안 어떤 일을 '구체적'으로 진행시켜야 하느냐에 따라서 아키텍팅의 관점이 변화된다.자주 쓰는 장표 중의 하나이다. 간단하게 설명하면 과거의 비즈니스와 현재의 비즈니스의 차이를 디지털 서비스로 만들어 내는 기간으로 표시한 것이다.과거에는 하나의 디지털 비즈니스가 동작하기 위해서 데이터를 수집하고 분석, 기획, 구현, 실행하기까지 대부분 8.5개월에서 10개월 정도의 시간이 소요되었고, 이렇게 만들어진 서비스들은 실제 고객과 단절되어 있는, 내부 시스템에 가까웠다는 것을 표현한다.그리고, 디지털 비즈니스의 세계에서는 모바일로 실 고객과 커넥티드 되어 있으며, 각 비즈니스가 실제 수집부터 실행까지 1주에 동작되는 세계를 표현한다.이 차이는 정말 개발 조직과 개발 리더십에 많은 차이를 주게 된다.Classic Business에서는 8개월 이상의 방향성이 흔들리지 않도록, 전체적인 방향성이 흐트러지지 않도록 개발 리더십을 발휘하는 것이 중요했다. 특히, 초기의 개발 조직을 세팅하고 예산과 비즈니스의 완성과 실 서비스 후의 이익과 같은 경영적인 판단이 더 중요하던 시기였기 때문에, 실제 소프트웨어를 만들어내는 관점은 디테일하고, 기능적인 것에 집중화된 상태로 개발 조직이 구성되고, 리더십도 그것을 최대한 끌어내는 것에 집중했다.또한, 내부적 조직의 문제로 일이 더디게 진행되거나, 품질이나 세부적인 문제를 쥐어짜거나, 어떻게든 일정을 맞추기 위해서 조정하는 조정자의 역할도 매우 큰 상태였다. 개발 리더십도 그런 관점에서 구성되었고, 기술적인 변화도 거의 없이 초기에 결정된 상태로 대부분 진행되었다.그런데, Digital Business의 세계로 넘어오면 이것은 완전 다른 구도를 가지게 된다.1주 단위의 개발 및 배포까지 매우 유연한 상태로 가동되고, 이 단위는 기술적 선택과 실패가 매우 빠르게 반복되는 것을 의미하게 되며, 개발 조직은 말 그대로 작게 세분화되고, 전체적인 방향성은 계속 유동적으로 변화하게 된다.24시간 내에 하나의 개념이 수립되고, 이를 배포까지 진행시키기 위한 매우 다양한 시도들을 선택할 수 있게 하며, 기획 조직과 개발 조직이 하나의 '지표'나 '시각화'된 장표를 보고 빠르게 판단하게 할 수 있다.매우 빠른 순간 판단이 중요하며, '몇 분'간격으로 회사의 운명을 결정할 수 있는 서비스의 론칭도 가능하게 한다.관리적인 방법은 DevOps의 자동화된 환경과, 세분화된 배포 권한, 기획자들과의 유기적인 환경들을 보다 효율적으로 운용할 수 있는 방법들에 대해서 개발 리더십은 고민하게 된다.어떻게 빠르게 일을 효과적으로 움직일 것이며, 빠른 판단을 할 수밖에 없다. 빠르게 변화하는 기술 스택을 더 잘 알고 있는 것은 개발 조직이기 때문에, 아키텍트나 개발 리더의 권한은 계속 실무자에 가깝게 내려가게 되는 것이 순리에 가깝다.현재 DevOps를 지향하고 있는 개발 조직에서 아키텍트가 지향하는 것은 크게 개념적으로 변화한 것은 없다. '고객과 비즈니스를 이해하는 개발'임에는 틀림없으나, 기존의 아키텍팅과 많이 달라진 것은 실시간 서비스에 대한 분석과 기획의 변화, 데이터 중심의 개발 구조의 시각화를 통해서 개발 조직을 통제한다기보다는, 개발 조직을 숨 쉬게 만드는 '심장'과 같은 역할을 하게 된다.마치, 비즈니스가 빨라지면, 심장도 빨리 뛰고, 비즈니스가 좀 수월해지면 호흡을 고를 수 있는 형태...현재의 아키텍트는 개발 조직의 '심장'과도 같아.속도와 박자, 전체적인 흐름을 중시하는 것이 현재의 아키텍트의 역할이다.건축가인 아키텍트들에게는 엄청난 규칙과 법칙, 책임의 범위가 상당하다. 하지만, 소프트웨어 아키텍트들에게는 그런 책임이 법적으로 제시되고 있지 못하고 있다. 보통 소프트웨어 아키텍트라고 한다면, 부정적인 환경에서 제대로된 소프트웨어를 만들 수 없기 때문에 부당한 개발환경을 담당할 가능성이 없다는...그래서, SI현장에서 아키텍트는 거의 나오지 않는다고 봐야 한다. 슬프지만. 그리고, 마지막으로... 아키텍트는 '직위'나 '권위'가 아니다. '롤'일뿐이다. 그뿐...
조회수 1014

스푼 EX팀의 Chuck을 만나보세요!

스푼을 만드는 사람들 열두 번째 이야기누구라도 '내 주변에도 이런 사람 한 명쯤은 있으면 좋겠다'라고 할법한 그런 사람.핑크색 아이폰이 너무나도 잘 어울리는 남자! 회사에서 보면 좋은 동료 같고, 때론 편한 동네 언니(?) 같이 카페에서 5시간 동안 함께 수다 떨 수 있을 법한 그런 다양한 매력이 있는, 멋진 척을 소개합니다!남자는 턱수염이죠!"제가 처음에 스푼에 입사 전에 물어본 게 있어요. 바로 '수염'을 안 깎아도 되는지에 대한 질문이었어요. 근데 웬걸.. 복장도 자유, 모자 쓰고 오시는 분들도 있고 저의 수염이 막 튀거나, 남다르게 느껴지지 않더라고요. 신선했습니다! 나와 코드가 잘 맞는 곳이구나!라고 생각했죠. 저 수염 기르고 싶거든요."EX 멤버들과 Chuck (오른쪽)듣고 싶은 당신의 스푼 라이프Q. 스푼에 입사하시게 된 계기가 궁금해요"저는 사실 취직을 조금 늦게 한 편인데요. 예전에 첫 직장을 다니다가 몸이 안 좋아져서 조금 오랫동안 쉬었어요. 충분히 쉬고 나서 회복되었을 때, 다시 구직활동을 하려던 차, 스푼에 근무하고 있는 지인이 추천을 해주시더라고요. 사실 그전부터 저는 라이브 스트리밍에 관심이 많은지라  스푼에 대해서 이미 알고 있었고 지인이 스푼을 너무 즐겁게 그리고 열심히 다니시는 모습을 보고 궁금하기도 하고 관심이 생겼었는데, 기회가 닿아서 입사를 하게 되었어요." Q. 척은 어떤 업무를 담당하고 있나요?"저는 사실 처음에 총무 포지션으로 들어왔다가, EX팀 업무도 함께 병행하면서 May의 제안으로 EX팀에서 노무 업무를 맡고 있어요! 예를 들면, 회사 규정을 만드는 업무 있잖아요? 규칙 등 그런 일들을 합니다. 무엇보다 다른 분들을 서포트하는 업무를 많이 하고 있어요."Q.  EX팀에서 나의 존재는?아기 - "EX팀에서 유일한 초보자이니까요!"그래서, 앞으로 배워야 할 것도 많고 열심히 배우려고 노력하고 있답니다. 경험 많은 팀원들께서 잘 이끌어주시고 도와주셔서 열심히 따라가고 있어요.Q. 내가 생각하는 스푼에서 일하는 장점은?"업무에 대해 개개인의 의견을 말할 수 있는 기회가 참 많은 것 같아요. 모든 구성원의 의견을 다 귀담아 들어주려고 노력하는 모습도 멋지고요. 이 부분이 저는 가장 큰 장점이라고 생각해요. 수평적인 조직의 문화의 기초가 되는 부분이라고 생각하거든요"Q. 함께 일하고 싶은 사람은 어떤 사람인가요?제겐 없는 부분을 가진 사람, 차분하고 밸런스가 잡힌 사람과 일하고 싶어요.그 예로, 저희 팀 새로 들어오신 Noah가 계신데요. 면접 때가 굉장히 인상 깊었어요. 면접 때 긴장하셨을 텐데도 불구하고 질문에 대한 답변을 굉장히 차분히, 틀린 부분은 정정하시면서 대답을 해주시더라고요. 그 부분이 굉장히 매력 있고 저와는 다른 부분으로 서로 부족한 부분을 채워줄 수 있을 것 같다고 생각했어요. 팀 내에 다양한 성향과 성격의 사람들이 있으면 그런 부분이 좋을 것 같아요.척이 수집하는 신발들의 '일부분' 사진알고 싶은 Chuck의 이야기Q. 나를 한마디로 표현한다면?오나이 - "사나이의 상반되는 개념이고, 한량이되 한심하지 않은 사람을 말합니다."Q. 법을 공부하셨다고 들었습니다."네, 어릴 땐 제 꿈이 법조인이 되는 거라고 생각했고, 그래서 법학과를 나왔어요. 생각해보면 제가 법을 공부하고 고시 준비를 했던 건 법조인이 되고 싶다는 마음보다는, 법조인이 된다면 제가 얻을 수 있는 것들과 제게 돌아오는 것들이 좋다고 생각했던 것 같아요. 공부는 중학교 때 까진 정말 열심히 했던 것 같은데, 고등학교 땐 잘 안 했던 것 같아요(겸손모드..) 그 당시엔 사실 저는 공부 말고 제가 무엇을 잘하는지 모르겠더라고요. 그래서 열심히 해야 한다고 생각했던 것 같아요"Q. 신발 수집은 언제부터 시작됐나요?"어릴 때부터 신발을 좋아했던 것 같아요. 우리 세대, 제 세대엔 마이클 조던이 전성기였거든요. 그때 뭔가 트렌드였어요. 저는 운동화뿐만 아니라, 부츠도 좋아하고 모든 신발을 좋아하지만 그중 운동화가 가장 많은 것 같아요. 이유는 음.. 모르겠어요.. 그냥 좋아하는 신발을 신고 있다는 그 느낌이 좋아요. 근데 저 생각보다 운동화 몇 켤레 없어요. 한 20켤레 정도 될걸요? 더 어릴 땐 지방까지 내려가서 사고, 줄 서서 사곤 했는데 요즘은 그러진 않아요! 아! 그리고 저 모자도 수집해요. 매년 4월이 되면 모자를 꼭 하나씩 사요. 생일 쿠폰이 나오거든요. 그래서 얼마 전에 또 신상 모자 하나 샀어요"Q. 척의 인싸력은 타고난 건가요?"저요? 저 낮 좀 가리는 편인데요? (실상 전혀 그렇게 보이지 않음. 누구보다도 친근하고, 편함)단지 저는 어색한 상황을 좋아하지 않는 편이에요. 아마 그래서 모두와 편하게 지내려고 하는 게 아닐까 싶어요"Q. 원래부터 Yolo 인생을 살았나요?*Yolo (You live only once) : 미래를 위해 현재를 희생하기보다 현재를 즐기려는 사람"저는 오늘이 행복하지 않으면, 내일도 행복하지 않다고 생각해요. 제 좌우명이 오늘이 행복하면 됐다이거든요. 내가 지금 행복한가?라고 묻는 다면 그건 내가 지금 행복하지 않기에 묻는 질문이라고 생각해요. 원래부터 그랬던 건 아닌 것 같은데, 크게 아프고 나서 변한 것 같아요. 지금은 물론 의학적으로 건강하지만요. 저는 제가 완전한 Yolo족은 아닌 것 같은데.. 제가 다른 분들에겐 그래 보일 수도 있을 것 같네요!"Q. 인터뷰해보시니 어떠셨어요?"기분이 좋았어요. 누군가 저에게 관심을 가져주고, 질문을 해준다는 게 기분 좋은 일이더라고요 :)"(인터뷰에 응해주셔서 감사합니다)Chuck은, 1. 음식을 가리지 않지만, '직화' 요리만 먹지 않습니다 2. 술, 담배를 하지 않습니다.함께 식사를 하게 된다면, 센스 있게 '직화' 요리는 피하고 술과 담배는 권하지 않으면 센스만점 동료가 될 수 있을 것 같아요 :) 팀원들이 척을 한마디로 표현한다면?Go 曰: 마이쿤의 명태 코다리 명태 코다리는 사계절 내내 명태의 참맛을 느낄 수 있다고 합니다,속초 출신인 척이 마이쿤을 위해서 사계절 내내 열심히 일해주세요~May 曰: 냉철한 두뇌와 뜨거운 마음의 소유자 사고는 논리적이고 체계적이지만 행동은 정의롭고 따뜻하거나 가끔 뜨겁기도 함 ㅎㅎKai 曰: 무서운 형 - 가끔 눈살을 찌푸릴 때 화난 거 같이 보여서요..Noah 曰: 고등학교 동창 - 낯설지 않은 친근함이 매력 포인트
조회수 934

국내 IT 산업을 주무르는 첫눈 마피아

업계에서 페이팔 마피아(PayPal mafia)에 대한 이야기를 듣는 건 어렵지 않다. 전세계 IT 산업의 핵심인 실리콘밸리를 장악하고 있는 페이팔 마피아를 탄생시킨 회사는 컨피니티(Confinity)라는 회사다. 이 회사의 이름은 낯설지 몰라도 이 회사가 개발한 페이팔(PayPal)이라는 전자 송금 서비스의 이름은 낯설지 않을 것이다. 1998년 시작된 컨피니티는 페이팔을 만들어 2002년 상장한 뒤 얼마 지나지 않아 이베이(eBay)에 매각된 닷컴 버블 폭풍의 몇 안되는 생존자 중 하나였다. 페이팔 마피아란 페이팔의 초기 임직원들을 일컫는 말로, 이들은 이후에 또 다른 혁신적인 회사들(Tesla Motors, LinkedIn, Palantir Technologies, SpaceX, YouTube, Yelp, Yammer 외 다수)을 계속 만들어 내고 있다. 이들의 모습이 마치 사회 모든 곳에 얽혀 있는 마피아 조직을 연상시킨다는 것에 비유해, 이들을 페이팔 마피아라고 부르기 시작했다. 심지어 포춘지(Fortune)에서는 2007년 이들을 한데 모아 마피아 같은 옷을 입히고 재미있는 사진을 남기기도 했다. 출처 : Fortune Magazine, 2007년 11월페이팔 마피아들의 성공은 절대 우연이 아니라고 생각한다. 이들이 닷컴 버블의 위기를 이겨낼 수 있었던 밑바닥에는 페이팔이라는 회사가 가진 확고한 고유의 문화(culture)가 존재했다. 자신들이 만들어 낸 본연의 문화가 몸에 배인 초기 구성원들이 새로운 회사를 시작하고, 또 다시 새로운 그들만의 확고한 문화를 만들어 가면서 또 다른 페이팔이 만들어 질 가능성이 높아졌다고 할 수 있다. 또한 각자가 가진 강력한 인적 네트워크를 통해 서로 도움을 주고 받으며 새로운 회사를 만들고 함께 성장할 수 있도록 하는 노력을 아끼지 않았다. 실리콘밸리에 또 다른 닷컴 버블이 터진다 하더라도 이들 페이팔 마피아의 생존 가능성은 의심할 여지가 없을 것이다. 정부 시스템이 무너져도 마피아 조직의 견고함은 무너지지 않는 영화 같은 이야기가 실리콘밸리에서 실제로 일어나고 있는 것이다.출처 : jamesaltucher.com한국에서는 이런 사례가 없는지 늘 궁금했다. 얼마 전 알토스벤처스의 한킴 대표님 페이스북에서 ‘네오위즈 마피아'에 대한 이야기를 본적이 있다. 그런데 나는 이 이야기를 읽으면서 네오위즈보다 주목해야 할 회사는 첫눈이 아닌가 하는 생각이 들었다. 네오위즈, 넥슨, NHN 같은 회사보다 훨씬 더 마피아의 밀집도가 높은, 미국의 페이팔을 연상시킬만한 작은 조직이었기 때문이다.첫눈은 2005년 6월 네오위즈에서 분사하며 설립되었던 검색 회사다. 가장 큰 특징은 자사의 내부 DB를 통해 검색 결과를 제공하는 경쟁사들과 차별화하여 인터넷 전체를 검색 대상으로 삼는다는 점이었다. 이후 설립 1년 만에 NHN에 350억원 규모로 매각되었고, NHN의 당시 보도자료에 따르면 임직원은 총 55명이었다. ‘첫눈 마피아’에 대해 정리하려고 마음 먹고 그간 나왔던 첫눈에 대한 기사들을 많이 읽어 봤다. 간간이 첫눈을 페이팔 마피아에 비유했던 기사들도 있었다. 또 마침 우리 회사 렌딧의 홍보 담당인 꼬날이 첫눈의 홍보 담당이었던 덕분에 생생한 이야기를 직접 들을 수 있었다. 정리해 본 첫눈 마피아들은 아래와 같다 (존칭 생략):장병규 : 지난 9월 25일 4차산업혁명위원장에 임명되어 국가적 화제의 인물로 떠오른 장병규 블루홀스튜디오 의장이 첫눈의 창업자. 2005년 6월 네오위즈에서 검색엔진 개발팀 인력들을 이끌고 분사해 첫눈을 창업했다. 2006년 6월 첫눈 설립 1년 만에 NHN 과 350억원 규모로 매각. 이렇게 NHN에 들어간 첫눈의 인재들이 주축이 되어 개발한 서비스가 라인(LINE)이다. 장병규 대표는 첫눈의 NHN 인수 후 초기 기업에 전문적으로 투자하는 벤처캐피털 본엔젤스벤처파트너스를 설립해 우수한 창업자와 스타트업을 발굴하고 지원하는 일에 힘써왔다. 2007년에는 게임개발사인 블루홀스튜디오를 창업해 현재까지 의장직을 맡고 있다.신중호 : 신중호 라인 CGO(Chief Global Officer)는 첫눈의 CTO였다. 2005년에 첫눈 창업 시 장병규 대표와 함께 네오위즈에서 나왔다. 2006년 NHN 인수합병 시 NHN에 합류, NHN 재팬의 검색서비스를 책임지고 일본에 건너가 있던 중 라인을 개발했다. 일본과 동남아시아 여러나라에서 현지화에 성공, 2016년 7월 라인의 나스닥 상장을 견인했다. 최근에는 WAVE, Clova 등 네이버의 AI 사업을 총괄하며 미래를 이끌어 가고 있다.이상호 : SK텔레콤 AI사업단장 역시 첫눈 출신이다. 자연언어처리와 음성합성, 음성검색 분야의 국내 최고 권위자로 알려졌다. 첫눈에 합류하기 전에는 LG전자 연구원을 거쳐 서울산업기술대학 교수를 지냈다. 당시 이상호 교수를 첫눈에 영입하기 위해 장병규 대표가 오랜 시간 공을 들인 것으로 알려졌다. 이상호 단장 역시 첫눈의 NHN 인수합병으로 NHN에 합류한 후 음성 검색 서비스 등 검색 개발에 집중하다, 2011년 다이알로이드라는 음성 인식 개발사를 창업했다. 국내 최고의 음성 검색 전문가 4인으로 구성되었던 다이알로이드는 2012년 9월 국내 최초로 음성으로 문자를 전송하는 앱 ‘다이알로이드'를 선보였다 (관련 내용 : http://limwonki.com/536). 이상호 대표는 2012년 말 다음이 다이알로이드를 인수하며 다음을 거쳐 카카오에서 음성 검색 연구를 지속했으며, 이후 SK플래닛에 입사, CTO 로 기술을 책임지다 2017년 4월부터 SKT AI 사업단장을 맡아 누구 (NUGU) 등 AI 부문 사업을 총괄하고 있다.노정석 : 잘 알려지지 않은 사실이지만 노정석 리얼리티 리플렉션 대표 역시 첫눈 출신이다. 첫눈 창업 초기 약 4개월 간 글로벌 사업 담당으로 일하다, 2005년 9월에 블로그 개발사인 태터앤컴퍼니를 창업했다. 노정석 대표는 1996년 카이스트-포항공대 해킹 전쟁의 주인공으로 유명하다. 이후 1997년 선배들과 창업한 보안회사 인젠이 2002년 코스닥 상장에 성공. 2005년에 설립한 태터앤컴퍼니는 2007년 9월 구글이 인수하며 국내 스타트업으로는 드물은 글로벌 M&A 성공 사례로 기록 되었다. 이후 구글에서 2년여 간 프로덕트 매니저로 일하다 2010년에 설립한 파이브락스(설립 시 사명은 아블라컴퍼니)가 2014년 8월 다시 미국의 모바일 광고 플랫폼 회사인 탭조이에 매각되며, 국내 스타트업에서 드물은 글로벌 M&A 성공 사례를 다시 남긴 주인공이 되었다. 2015년 5번째 회사인 리얼리티 리플렉션을 창업해 국내 대표적인 ‘연쇄 창업가'로 불리운다. 창업과 더불어 엔젤투자자로서 좋은 창업가들을 발굴하고 후배 창업가들과 함께 호흡하는 것을 좋아한다. 티몬, 비트파인더, 미미박스, 다이알로이드, 다노, 다이알로이드(다음이 인수), 파프리카랩(일본 그리 인수), 울트라캡숑(카카오 인수) 등에 투자했다. 나 역시 2011년 미국에서 창업했던 두번째 회사인 스타일세즈 창업 때 노정석 대표의 엔젤투자를 받았다.그 외 2011년 모바일 메신저 ‘틱톡'을 개발해 카카오톡의 강력한 경쟁자로 부상했던 매드스마트의 김창하 대표 역시 첫눈 개발자 출신이다. 김창하 대표는 2012년 매드스마트를 SK플래닛에 매각하며 SK플래닛에서 일하다, 현재는 라인에 합류해 신중호 CGO와 함께 일하고 있는 것으로 알려져 있다. 라인의 박의빈 CTO 역시 첫눈 출신으로 오랜 기간 신중호 CGO 와 함께 하고 있는 핵심 인물이다. 천재 개발자로 유명한 보이저엑스 남세동 대표 역시 장병규 대표와 오랫동안 함께 한 개발자다. 19살에 네오위즈 인턴으로 시작해서 세계 최초의 웹기반 채팅 서비스인 ‘세이클럽 채팅' 개발을 주도하였고, 이후 첫눈을 거쳐 라인에서 일했다. 카카오의 AI 사업을 총괄하고 있는 김병학 부사장 역시 첫눈 출신이다.    대기업과 스타트업을 오가며 활약 중인 첫눈의 인재들도 있다. 이은정 라인플러스 이사는 베인앤컴퍼니 등에서 컨설턴트로 일하던 중 장병규 대표에게 스카우트되어 첫눈에 입사. 첫눈이 NHN에 인수된 후 현대카드, GS홈쇼핑, 삼성카드 등 대기업에서 승승장구 하던 중 2014년 라인플러스에 입사해 글로벌 사업의 중추 역할을 하며 다시 신중호 CGO와 일하고 있다. 엘지생활건강에서 모바일 플랫폼 혁신을 주도하고 있는 권도혁 상무 역시 첫눈 출신이다. 첫눈 합류 전 베인앤컴퍼니와 NHN에서 경력을 쌓았던 권도혁 상무는, 첫눈이 NHN에 인수된 후 다시 전직장 NHN에 합류하지 않고 스타트업인 큐박스에 합류했다. 이후 2011년 ‘울트라캡숑' 이라는 재미있는 이름의 스타트업을 창업, 대학생들의 익명 커뮤니티인 ‘클래스메이트', 소셜미디어 서비스 ‘너 말고 니 친구', ‘마티니', 다이어트 앱 ‘다이어터' 등을 개발해 서비스 하던 중 2014년 카카오에 매각하고 엘지생활건강에 합류했다.   스타트업 홍보를 열심히 하고 있는 우리 회사 꼬날도 첫눈 출신이다. 첫눈 (NHN 매각) - 태터앤컴퍼니 (구글 매각) - 엔써즈 (KT 매각, 이후 닐슨에 재매각됨) - 파이브락스 (탭조이 매각) 등 성공적인 엑시트로 평가되는 스타트업에 연이어 렌딧에 합류. 스타트업 홍보의 미다스 손으로 불리는 국내 유일무이한 이력의 홍보전문가다.첫눈이 NHN에 인수되면서 첫눈의 새로운 검색 정책과 혁신적인 서비스에 기대를 많이 했던 초기 사용자들이 '첫눈이 녹아 버렸다'며 아쉬워했었다고 한다. 하지만 첫눈은 매각 당시 보도했던대로 NHN과 함께 글로벌 서비스 개발에 힘썼고, 메신저 서비스 라인을 만들어 글로벌 시장 진출에 성공했다. 또한 다양한 첫눈 마피아들이 여전히 창업 전선에서 맹활약 중이다. 내가 창업에 뛰어든지 이제 만 12년이 되었고 세번째 회사인 P2P금융 렌딧을 시작한지 2년 반이 지났다. 렌딧은 기술 혁신을 통한 금융 서비스의 효율화라는 미션을 갖고 시작되었다. 혁신적인 서비스를 통해 우리 삶에 긍정적인 영향을 주는 것만큼이나 내게 강한 동기가 되는 것은 함께 일하는 사람들과의 동반 성장이다. 렌딧의 성장 뿐만 아니라 우리 고유의 문화가 몸에 배인 렌딧맨들이 미래에 또 다른 곳에서 새로운 혁신을 만들어 낼 수 있는 강력한 렌딧 마피아가 형성되기를 기대해본다.지난 5월27일, 렌딧의 SeriesB 투자가 확정되던 날 모든 렌딧맨과 함께
조회수 12434

Jekyll을 이용하여 github에 블로그 만들기

티스토리에서 여러 불편함들을 느껴 깃헙 블로그로 갈아타려고 한다. 자유도가 높아보여 티스토리에 블로그를 개설했으나 오히려 글이 노출되는 디자인이나 (줄간격, 글씨 크기 등등) 기존 테마를 변경하기에 불편했다. 결정적으로 gist 스크립트를 삽입했을 때 미리보기가 안돼서 고민 끝에 깃헙 블로그를 선택했다. 워드프레스도 개설해봤지만 왠지 모르게 마음에 안들어서 깃헙 블로그로 갈아타기로 마음먹었다. 그 후에 이것저것 알아보니 내 마음에 쏙 드는 요소들이 많았다.마음에 드는 부분git을 이용해 커밋, 푸시로 글을 포스팅함. 그 덕분에 블로그에 대한 모든게 로컬에 있고 모든 글들을 로컬에서 관리 할 수 있음.마크다운을 이용하여 글 작성. 글과 html을 마음대로 오갈 수 있어서 좋음. 마크다운 에디터가 없었다면 불편했겠지만 세상은 넓고 좋은 에디터는 많다..! 다만 이미지 삽입에서는 좀 불편.다른 웹 프로젝트처럼 웹스톰에서 블로그 관리 가능. 인텔리 제이를 사랑하는 나로서는 이 부분 또한 큰 장점.아무튼 이런 이유로 깃헙 블로그로 갈아타기로 결정. 구글링을 통해서 깃헙 블로그를 개설하는 방법에 대해 잘 정리해놓은 블로그를 찾았다. 놀부 블로그를 참고하여 깃헙 블로그를 개설했다. 아래에는 내가 보기 편하도록 더 간략하게 정리해보았다.깃헙 블로그 만들기 (Mac OS X)1. Jekyll 설치터미널에서 아래 명령어 입력으로 설치. $ sudo gem install jekyll2. 설치한 Jekyll을 이용하여 블로그 생성블로그를 만들고자 하는 위치에서 아래 명령어로 생성.$ jekyll new [github사용자명].github.com블로그 생성후 생성된 위치로 이동하여 아래의 명령어 실행 후 브라우저에서 http://localhost:4000으로 접속하면 로컬에 생성된 블로그를 볼 수 있음.$ jekyll serve --watch3. github에 온라인 저장소 만들기위에서 생성한 블로그 이름과 동일한 이름([github사용자명].github.com)으로 github에 온라인 저장소를 생성. 그 후 로컬에 있는 블로그와 만들어준 저장소를 remote 해주면 끝.$ git init$ git remote add origin [저장소URL]$ git add .$ git commit -m "Initialize Blog"$ git push origin master생성된 블로그는 http://[github사용자명].github.com으로 접속하면 볼 수 있다. 처음 생성하는 경우 몇 분의 시간이 걸리는 경우도 있다고 함.포스팅하기글은 _post 파일 안에 YYYY-MM-DD-[글 제목].markdown 형식으로 파일명을 지정하여 생성한 후 커밋, 푸시하면 업로드됨.테마 적용하기테마를 직접 만들기에는 시간이 너무 많이 소요되니 인터넷에 공유되어있는 테마를 사용하면 좋다. 테마를 적용하는 부분에서 여러모로 애를 먹었는데 제일 쉬운 방법은 테마가 올라가있는 저장소를 포크하여 [github사용자명].github.com으로 이름을 바꾸는게 제일 쉽다. 내 블로그는 심플한 테마를 적용하였다.다른 테마들은 Jekyll Themes 사이트에서 찾아볼 수 있다. 훨씬 이쁘고 좋은 테마들도 많음.Jeykll 더 알아보기Jeykll 공식 번역 사이트에서 몇 개의 문서를 읽어보면 더 다양하게 활용해 볼 수 있다. _config.yml파일이나 _post, _include, _layout 파일 정도는 기본으로 살펴보아야 함.#트레바리 #개발자 #안드로이드 #앱개발 #Jeykll #백엔드 #인사이트 #경험공유
조회수 370

금요일의 해커톤

안녕하세요. 엘리스입니다!지난 8월 말, 엘리스의 야심 찬 첫 해커톤이 있었습니다. 이번 해커톤은 매주 금요일 찾아가는 문제 ‘금요일에 코딩하는 토끼’에 대한 수강생 여러분의 성원에 힘입어 개최되었습니다.주제는 ‘코딩 문제의 A에서부터 Z까지 직접 설계하고 제작한다.’ 해커톤에서는 아이데이션 단계에서부터 문제 기획과 코딩, 채점을 위한 그레이더 제작까지 코딩 문제의 모든 것을 다루었습니다. 물론 실제 문제 동작을 위해 실행과 채점을 반복하며 디버깅하여 완벽한 실습 문제를 만드는 것 역시 이번 경연의 핵심이었는데요.이를 통해 모든 참가자 여러분들은 일일 엘리스 아카데미 실습 문제의 출제자가 되었습니다. 어떤 과정을 거친 어떤 결과물들이 있었을까요?해커톤 현장 스케치해커톤의 소개를 경청 중이신 참가자 여러분.지금까지 프로그래밍 문제를 많이 풀어보셨을 여러분이, 반대로 문제의 출제자가 되어 문제를 구성하는 관점에서 생각해보고 채점 방식까지 고민해본다면 프로그래밍에 대한 이해도를 더 높일 수 있을 것이라는 기대로 이와 같은 해커톤이 기획되었습니다. 교육자로서 엘리스 플랫폼의 다양한 기능을 직접 이용해볼 수 있는 것은 일석이조의 이점이었죠!경직된 분위기를 깨고 뇌를 말랑말랑하게 만들기 위한 아이스 브레이킹 시간은 팀 대항전으로 진행되었습니다.간단한 코딩 문제를 가장 먼저 맞히는 팀이 점수를 얻는 스피드 코딩 게임을 통해서 순발력을 높이고, 잠시 후 해커톤에서 본격적으로 사용하게 될 엘리스 플랫폼과 친해질 시간도 가질 수 있었습니다.'그림 그리기 게임'에서는 각 팀 디자이너들의 창의력이 폭발! 개발과 관련된 온갖 단어들을 1초 만에 그림으로 표현해야 하는 설명자의 재치와 크로키 실력(?)이 강조되었던 순간이었는데요. 승자는 '오즈'팀! 모두 오즈 팀 디자이너의 그림 실력에 입을 다물지 못했다고 합니다.게임을 하는 동안 어느새 어색했던 처음의 분위기가 파괴되었습니다. ^^ 1시간 동안 문제의 초안을 기획하는 시간이 주어지고, 이어 각 팀의 아이디어 발표 시간이 있었습니다.해커톤의 룰은 아래와 같았는데요.실행 가능한 프로그래밍 문제 1개 출제.동화를 모티브로 한 문제 스토리를 기획.채점 가능한 그레이더 제작.모든 팀들이 알고리즘 문제를 기획해주셨습니다. 동화의 서사구조를 논리적으로 단순화하거나 변형하여 알고리즘 문제에 녹여낸 과정이 인상적이었습니다.아이데이션 단계에서는 문제의 완성된 모습이 전부 그려지지는 않았지만 많은 고민의 흔적과 창의적인 생각들을 엿볼 수 있어 이로부터 탄생될 프로그래밍 실습을 기대할 수 있었습니다.밤샘 코딩 중...우승 문제 소개기획하고 코딩하고 디자인을 하다 보니(!) 어느새 날이 밝아왔습니다. 이제 남은 것은 팀별 결과물 발표와 우승팀 시상 뿐!'금코토'를 패러디하여 팀 명을 지어주신 어린 왕자 팀. /* prince */로고까지 깨알 섬세!모든 팀이 각기 다방면에서 강점을 부각하는 문제를 출제해주셨기 때문에 우열을 가리기 어려웠는데요. ‘금코토’배 해커톤이라는 이름에 걸맞게 금코토 과목의 취지와 가장 부합하는 문제를 출제한 팀에게 가산점을 주어 우승팀을 선발하였습니다. 그 결과 대망의 우승 문제는...거울나라의 앨리스팀의 ‘케이크와 병’ 단순한 명료한 문제 구성과 초등학생도 이해할 수 있는 쉽고 친절한 프레젠테이션으로 인상 깊었던 문제였습니다. 완성도, 문제 활용도 면에서 금코토 문제를 능가하며 단순하면서도 재미있게 풀 수 있는 문제라는 심사위원들의 평가가 있었습니다. 우승팀인 거울나라의 앨리스 팀 전원에게는 엘리스 굿즈를 선물로 보내드립니다. :)이밖에 겁쟁이 사자를 동물의 왕으로 만들기 위해 용기의 성을 짓는 알고리즘 문제를 낸 오즈의 마법사 팀의 문제는 스토리에 착안하여 자칫 복잡해질 수 있는 내용을 세세한 문제 설계로 극복하려 했던 점이 우수하게 평가받았습니다. 술주정뱅이 별에 사는 만취한 아저씨를 옮기는 알고리즘 문제를 낸 ‘목요일에 코딩하는 어린 왕자’ 팀은 참신성과 '넓이 우선 탐색', '깊이 우선 탐색', '다익스트라 알고리즘'을 모두 공부해볼 수 있도록 한 문제 구성 면에서 높은 평을 받았습니다.큰 상품도 내걸지 않았던 첫 해커톤이었는데도 참가자분들 모두가 열과 성을 다해 밤을 새워 문제를 만들어 주셨습니다. 모든 참가자 여러분들께 감사의 말씀 전합니다. :) 해커톤 이후 진행한 설문 조사에서 100%의 확률로 모든 분들이 다음 해커톤에 재참가 의사를 밝히셨는데요. 모두 첫 해커톤을 즐겨주셨던 것 같네요. 엘리스에서는 앞으로도 해커톤을 지속적으로 개최할 예정입니다. 코끝 시려질 때쯤 더욱 풍성하고 유익한 기획의 해커톤으로 찾아뵐 예정이니 많은 관심 가져주세요!*금코토 — ‘금요일에 코딩하는 토끼’라는 엘리스 아카데미 과목의 줄임말. 매주 금요일 저녁때쯤 업로드되는 문제로, 특정 루트로 토끼가 움직이도록 코딩해야 하는 콘셉트와 귀여운 휴보 래빗이 특징입니다. >>문제 풀어보기(무료)
조회수 837

2017 NDC 리뷰) 몬스터 슈퍼리그 리텐션 프로젝트

 2017년 4월 25일부터 27일까지 진행된 Nexon Developer Conference 에 나녀온 후기입니다.제가 들었던 재밌는 세션들 하나하나 올릴 테니 기대해 주세요! :)2017 NDC 재밌었다능!!!몬스터 슈퍼리그 리텐션 15% 개선 리포트 - 숫자보다 매력적인 감성 테라피"몬스터 슈퍼리그"의 게임 리텐션 개선 리포트였는데요, 기본적인 서비스의 소비자를 향한 어프로치인"당신은 똑똑한 유저!"라는 인식 심기(쉬운 접근성/ 심도 깊은 진행 유도)"빠른 어필"(이벤트에 대한 빠른 피드백)"축복받은 계정" (다양하고 많은 초반 보상)이라는 인식과,"주어지면 알아서 하겠지""보상이 있으면 알아서 하겠지"라는 생각을 지양하고, "의도하지 않았지만 수행을 할 수 있도록" 하는 넛지(Nudge) 효과를 일으킬 수 있는 무의식을 자극하는 재밌는 전략에 대해서 흥미를 느꼈습니다. 그리고 이후 리텐션 강화를 위한 프로젝트로 가장 중요한 건,단지 "무슨 기능을 만들 것이냐?"가 아닌, "어떤 부분에서 유저가 이탈"하게 되고,이탈한 유저들 중 "우리가 진짜 챙겨야 할 유저"가 어떤 유저들인가에 집중한다.라는 부분에서 항상 우선돼야 하지만, 되지 못한 부분들을 생각하게 되었던 것 같아요. 그래서 이를 통해스스로 모험 입장을 몇 번 한 유저: 원하는 것에 접근하지 못한 유저에 대한 파악 후 개선다음 지역에 접근 한 유저: 지속 플레이 의향 있으나, 니치를 못 찾은 유저들의 의도 파악 후 개선이라는 개선에 필요한 정확한 목표를 가지고, 어떤 방식으로 접근해야 하는지에 대한 고민을 보는 것에 정말 재미를 느꼈고요, 이에 대한 진행방향을 듣는 것도 정말 값진 경험이었습니다.개선 시퀀스1차 개선 (-)보상 10배 상향에도 불구, 큰 성장 없음.>"가치비교가 익숙하지 않은 유저들에게 보상의 절대적 수치 증가는 큰 감흥이 없다."라는 점을 파악하고, 유저에 "감정"을 터치하는 방법을 고안.2차 개선 (+ & -)조사 결과, 첫 패배 지점에서 유저들의 높은 이탈률을 파악> 패배 지점을 인위적으로 미루지 않되, 패배에 신경 쓰지 않도록 다른 부분들에 대한 장치를 추가.> "도전 가능한 포인트를 생성하는 것은 유효하다."는 부분을 Metric으로 확인했으나, 타깃 유저 범위를 정확하게 파악하지 않고  Metric만 집중해서 정확한 범위 파악을 놓침.3차 개선 (+ & +)유저가 얻을 수 있는 보상의 기회를 꼭 찾아가도록 유도옵션 1. 텍스트 강조? 텍스트는 망각의 영역 (X)옵션 2. 강제 터치? 이미 자유 플레이가 된 유저에게 부자연스러운 접근 (X)옵션 3. 얻고 싶은 보상이 있다면, 어떨까? 그리고 보상 등에 대해서 스토리 텔링이 될 수 있다면?  (O)  - 부정 경험 개선을 통한 리텐션 향상 효과  - 초반에 한 일을 다시 하게 하는 것은 큰 부정 경험을 초래  - 강제적 이동보다는 원하는 보상을 통해 부여4차 개선 (+)스토리 텔링 요소 추가  1. 일러스트  2. 캐릭터에 대한 스토리 추가글로벌 원빌드로서 북미권 영역에서  특히 추가결과개선 프로세스 이후,"무언가가 무조건 있다."라는 이야기 보단, "기대치 않은 행동에 대해서 얻는 보상의 획득"으로 유저의 감성을 자극하는 스토리 텔링의 중요성 확인.교훈보상도 주지만, "보상을 준다"라는 이벤트를 행하는 것 만으로 서비스 제공자는 끝내선 안된다. 보다 감성적인 접근을 통해 유저의 감정을 이해하는 것이 더 중요하다. 첫날 첫 번째 세션이었는데요, 아침부터 정말 보람찬 세션 들을 수 있어서 정말로 감사했습니다. 사실, 게임이건, 모바일 서비스건, 웹 서비스건 "소비자를 이해한다."라는 부분은 언제 어디서나 필요한 부분이지만, 결과적으로 서비스 제공자들은 "보상을 제공했다."로 서비스 제공을 스스로 끝을 내버리는 순간들을 더 많이 마주하기 때문에, 다양한 분야들에서 생각해 볼만한 이야기라고 생각합니다. 한줄평: 중요한 건, "내가 이런 걸 줬다!"보다는 "이런 걸 줘서 고마워"라는 것을 느낄 수 있도록 소비자의 마음에 초점을 맞추는 서비스 제공이 맞다!#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트
조회수 1429

CTO의 인간선언

아이오에서 일 한지 어느 덧 한 달 가까이 되어간다.이젠 나도 어느 정도 팀의 비즈니스 로직, 도메인, 문화, 사용하는 기술들이 조금씩 이해되기 시작하고 있다.그러자 이번엔, CTO이자 나의 멘토이며 사수인 미정님이, "직접 기능을 하나 TDD로 개발해서 Pull Request 해보라"는 미션을 주었다.API를 보고, 구글링하고, 기존에 미정님이 짰던 코드를 참고해서 만들어갔다.그럼에도 불구하고 제대로 작동하지 않는 코드가 있었다.혼자 해볼 수 있는 것은 다 해 본것 같은데도 해결법이 떠오르지 않아, 미정님에게 이런저런 문제가 있다고 설명하고 도움을 요청했다.미정님이 코드를 좀 보더니 해결했다. 미정님이 짰던 기존 코드에 오류가 있었고, 내가 그것을 참고해서 코드를 짰기 때문에 생긴 문제였다.그녀는 쓴 웃음을 지으며, “변형덕에 오류발견 했네, 잘했어.”라고 약간 주눅들어 말했고,나는 “아, 저는 미정님 코드는 완벽하다 생각하고 그걸 레퍼런스로 하고 코드를 짰는데, 그래서 오류를 못 찾았나봐요.”라고 대답했다.그러자 그녀는 갑자기 눈빛을 바꾸며 역정을 냈다. “그건 변형이 아직 엔지니어의 마인드를 못 갖췄다는 말이야!”예상치못한 임기응변에 순간 나는 움찔했고, 내게 유리했던 분위기를 뺐기고 말았다.그녀의 설명이 이어졌다.“세상에 실수 없는 사람은 없어! 엔지니어라면, 컴퓨터는 믿어도 사람은 못 믿는 다는 생각을 갖고 있어야 되!나는 선배가 짠 코드라도 안 믿어. 심지어 구글러가 짠 코드도 난 안 믿어!100%완벽한 코드는 없어.우리가 TDD를 하는 것도 실수나 오류를 최소한으로 줄이기 위해서지, 그렇게해도 오류없는 100% 완벽한 코드를 보장하지는 않아.그러니까 누가 짠 코드든 완벽하다고 생각하면 안 돼! 내 코드도 마찮가지고!”구구절절이 맞는 말이다.친절한 미정님은 스스로를 실수할 수 밖에 없는 인간으로 낮추면서까지, 엔지니어로서 가져야할 자세를 알려주셨다.진정한 살신성인의 멘토라고 아니할 수 없다.ㅜ친절한 박미정줄여서 친박.앞으로 친박이라 부르고 싶다.#스위쳐 #Switcher #개발자 #스타트업 #스타트업CTO #CTO #개발일지 #경험공유
조회수 1451

RxJava2 함수 파헤치기!

Overview지난 글 Rxjava를 이용한 안드로이드 개발에서는 RxJava의 Android 연결 방법과 기본적인 사용법을 다뤘습니다. 이번 글에서는 RxJava의 강력하고 다양한 함수들을 살펴보고자 합니다. Android에서 복잡하게 구현되는 내용들을 단 몇 개의 함수로 처리할 수 있는 RxJava를 꼭 사용해보길 권합니다.1. just2. fromArray/fromlterable3. range/rangLong4. interval5. timer6. map7. flatMap8. concatMap9. toList10. toMap11. toMultiMap12. filter13. distinct14. take15. skip16. throttleFirst17. throttleLast18. throttleWithTimeout참고: 공통적으로 사용하는 구독(수신) 클래스는 아래와 같습니다.static class CustomSubscriber<T> extends DisposableSubscriber<T> { @Override public void onNext(T t) { System.out.println(Thread.currentThread().getName() + " onNext( " + t + " )"); } @Override public void onError(Throwable t) { System.out.println(Thread.currentThread().getName() + " onError( " + t + ")"); } @Override public void onComplete() { System.out.println(Thread.currentThread().getName() + " onComplete()"); } } 1. just파라미터를 통해 받은 데이터로 Flowable을 생성하는 연산자입니다. 최대 10까지 전달할 수 있고, 모든 데이터가 수신되면 onComplete() 수신됩니다. 기본적인 Flowable 생성자 함수로 볼 수 있으며 단순 작업에서 많이 사용합니다.public static void just() { //파라미터 값을 순차적으로 송신하는 Flowable 생성 Flowable<String> flowable = Flowable.just("A", "B", "C", "D", "E", "F"); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 main onNext( A ) main onNext( B ) main onNext( C ) main onNext( D ) main onNext( E ) main onNext( F ) main onComplete() 2. fromArray/fromIterablefromArray, fromIterable 함수는 파리미터로 배열 또는 Iterable(리스트 등)에 담긴 데이터를 순서대로 Flowable을 생성하는 연산자입니다. 모든 데이터를 순차적으로 송신 후 완료됩니다. 반복적인 데이터 변환 작업 같은 경우 for 문 대신 대체할 수 있습니다. 결과를 보면 main Thread 에서 작업 결과가 나오지만, flatMap 을 사용한다면 별도의 Thread로 main Thread의 부하를 막을 수 있습니다.1. fromArray public static void fromArray() { //fromArray 배열로 파라미터를 전달 받는다. Flowable<String> flowable = Flowable.fromArray("A", "B", "C", "D", "E"); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 main onNext( A ) main onNext( B ) main onNext( C ) main onNext( D ) main onNext( E ) main onComplete() 2. fromIterable public static void fromIterable() { List<String> list = Arrays.asList("A", "B", "C", "D", "E"); //fromIterable 리스트로 파라미터를 전달받는다. Flowable<String> flowable = Flowable.fromIterable(list); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 main onNext( A ) main onNext( B ) main onNext( C ) main onNext( D ) main onNext( E ) main onComplete() 파라미터와 함수는 다르지만 동일하게 처리된다. 3. range/rangLongrange 함수는 지정한 숫자부터 지정한 개수만큼 증가하는 Integer 값 데이터를 송신하는 Flowable를 생성합니다. rangLong 함수는 range와 동일하며 데이터 타입은 Long을 사용합니다. 두 함수 데이터 송신을 마치면 onComplete를 송신합니다.1. range public static void range() { //range(int start, int count) //start : 시작 값 //end : 발생하는 횟수 Flowable<Integer> flowable = Flowable.range(10, 5); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 main onNext( 10 ) main onNext( 11 ) main onNext( 12 ) main onNext( 13 ) main onNext( 14 ) main onComplete() 2. rangLong public static void rangeLong() { //range(int start, int count) //start : 시작 값 //end : 발생하는 횟수 Flowable<Long> flowable = Flowable.rangeLong(10, 5); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 main onNext( 10 ) main onNext( 11 ) main onNext( 12 ) main onNext( 13 ) main onNext( 14 ) main onComplete() 4. interval지정한 간격마다 0부터 시작해 Long 타입 숫자의 데이터를 송신하는 Flowable을 생성합니다. 데이터는 0, 1, 2, 4 순차적으로 증가된 데이터를 송신합니다. Android 에서는 반복적인 작업인 TimerTask를 대신해서 interval로 간단하게 처리할 수 있습니다. UI 변경이 필요한 부분에서는 interval scheduler를 AndroidSchedulers.mainThread() 를 변경해 적용할 수 있습니다.public static void interval() { //(long time, TimeUnit unit, Scheduler scheduler) //time : 발생 간격 시간 //unit : 간격 시간 단위 //scheduler : 발생 scheduler를 변경하여 사용할 수 있습니다. // ex)AndroidSchedulers.mainThread() // - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 // 1초 간격으로 데이터 요청을 송신하다. Flowable<Long> flowable = Flowable .interval(1000L, TimeUnit.MILLISECONDS).take(10); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( 0 ) RxComputationThreadPool-1 onNext( 1 ) RxComputationThreadPool-1 onNext( 2 ) RxComputationThreadPool-1 onNext( 3 ) RxComputationThreadPool-1 onNext( 4 ) RxComputationThreadPool-1 onNext( 5 ) RxComputationThreadPool-1 onNext( 6 ) RxComputationThreadPool-1 onNext( 7 ) RxComputationThreadPool-1 onNext( 8 ) RxComputationThreadPool-1 onNext( 9 ) 5. timertimer 함수는 호출된 시간부터 일정한 시간 동안 대기하고 Long 타입 0을 송신 및 종료하는 flowable을 생성합니다. interval이 조건까지 반복적으로 송신한다면, timer는 한번만 송신하고 종료됩니다.public static void timer() { SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy.MM.dd hh:mm ss"); System.out.println("현재시간 : " + simpleDateFormat.format(System.currentTimeMillis())); //(long time, TimeUnit unit, Scheduler scheduler) //time : 발생 간격 시간 //unit : 간격 시간 단위 //scheduler : 발생 scheduler를 변경하여 사용할 수 있습니다. // ex)AndroidSchedulers.mainThread() Flowable<Long> flowable = Flowable.timer(1000L, TimeUnit.MILLISECONDS); //구독을 시작한다. flowable.subscribe(value -> { System.out.println(" timer : " + simpleDateFormat.format(System.currentTimeMillis())); }, throwable -> { System.out.println(throwable); }, () -> { System.out.println(" complete"); }); } 결과 현재시간 : 2019.04.29 09:09 56 timer : 2019.04.29 09:09 57 complete 6. mapFlowable 에서 송신하는 데이터를 변환하고, 변환된 데이터를 송신하는 연산자입니다. 하나의 데이터만 송신할 수 있으며, 반드시 데이터를 송신해야 합니다. 혹여 송신되는 데이터가 null 을 포함하면 map 대신 아래의 flatMap 을사용하는 것이 좋습니다.public static void map() { Flowable<String> flowable = Flowable.just("A", "B", "C", "D", "E") //map(Function mapper) //mapper : 받은 데이터를 가공하는 함수형 인터페이스 //알파벳 값을 소문자로 변경하여 return 한다 .map(value -> value.toLowerCase()); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 main onNext( a ) main onNext( b ) main onNext( c ) main onNext( d ) main onNext( e ) main onComplete() 7. flatMapflatMap은 map과 동일한 함수이지만, map과는 달리 여러 데이터가 담긴 Flowable을 반환할 수 있습니다. 또한 빈 Flowable를 리턴해 특정 데이터를 건너뛰거나 에러 Flowable를 송신할 수 있습니다.파라미터 mapper에서 새로운 Flowable의 데이터 전달이 아닌 다른 타임라인 Flowable로 작업하면 들어온 데이터 순서대로 출력을 지원하지 않습니다. 타임라인 Flowable(timer, delay, interval 등)에서는 가급적 사용을 피하거나, 순서에 지장이 없을 때 사용하는 것이 좋습니다.public static void flatMap() { Flowable<String> flowable = Flowable.range(10, 2) //flatMap(Function mapper, BiFunction combiner) //mapper : 받은 데이터로 새로운 Flowable를 생성하는 함수형 인터페이스 //combiner : mapper가 새로 생성한 Flowable 과 원본 데이터를 조합해 새로운 송신 데이트를 생성하는 함수형 인터페이스 //첫 번째 데이터를 받으면 새로운 Flowable를 생성한다. //take(3) : 3개까지만 발생한다. .flatMap(value -> Flowable.interval(100L, TimeUnit.MILLISECONDS).take(3), (value, newData) -> "value " + value + " newData " + newData); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( value 10 newData 0 ) RxComputationThreadPool-2 onNext( value 11 newData 0 ) RxComputationThreadPool-1 onNext( value 10 newData 1 ) RxComputationThreadPool-2 onNext( value 11 newData 1 ) RxComputationThreadPool-1 onNext( value 10 newData 2 ) RxComputationThreadPool-2 onNext( value 11 newData 2 ) RxComputationThreadPool-2 onComplete() 결과를 보면 각기 생성된 Flowable이 비동기식으로 송신 되기때문에 서로 다른 스레드에서 실행돼 데이터를 받는 순서대로 송신하지 않는다는 점을 주목하자 8. concatMap받은 데이터를 Flowable로 변환하고 변환된 Flowable을 하나씩 순서대로 실행해서 수신자에서 송신합니다. 다시 말해 여러 데이터를 계속 받더라도 첫 번째 데이터로 생성한 Flowable 의 처리가 끝나야 다음 데이터로 생성한 Flowable을 실행하는 것입니다.생성된 Flowable의 스레드에서 실행되더라도 데이터를 받은 순서대로 처리하는 것을 보장하지만, 처리 성능에 영향을 줄 수 있습니다.public static void concatMap() { Flowable<String> flowable = Flowable.range(10, 5) //map(Function mapper) //mapper : 받은 데이터를 가공하는 함수형 인터페이스 .concatMap(value -> Flowable.interval(100L, TimeUnit.MILLISECONDS).take(2) .map(data -> ("value : " + value + " data : " + data))); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( value : 10 data : 0 ) RxComputationThreadPool-1 onNext( value : 10 data : 1 ) RxComputationThreadPool-2 onNext( value : 11 data : 0 ) RxComputationThreadPool-2 onNext( value : 11 data : 1 ) RxComputationThreadPool-3 onNext( value : 12 data : 0 ) RxComputationThreadPool-3 onNext( value : 12 data : 1 ) RxComputationThreadPool-4 onNext( value : 13 data : 0 ) RxComputationThreadPool-4 onNext( value : 13 data : 1 ) RxComputationThreadPool-5 onNext( value : 14 data : 0 ) RxComputationThreadPool-5 onNext( value : 14 data : 1 ) RxComputationThreadPool-5 onComplete() 결과를 보면 생성된 Flowable 스레드와 데이터 순서대로 출력이 보장된다 것을 알 수 있다. 9. toListtoList는 송신할 데이터를 모두 리스트에 담아 전달합니다. 한꺼번에 데이터를 List로 가공해서 받기에 좋습니다. 하지만 많은 양의 데이터를 처리할 경우 버퍼가 생길 수 있고, 쌓은 데이터 때문에 메모리가 부족해질 수도 있습니다. 또한 수신되는 데이터는 하나이므로 Flowable이 아닌 Single 반환값을 사용합니다.public static void toList() { Single<List<String>> single = Flowable.just("A", "B", "C", "D", "E", "F") .toList(); // 구독을 시작한다. single.subscribe(new SingleObserver<List<String>>() { @Override public void onSubscribe(Disposable d) { System.out.println(Thread.currentThread().getName() + " onNext()"); } @Override public void onSuccess(List<String> strings) { //최종 완료된 리스트를 순서대로 출력한다. for (String text : strings) { System.out.println(Thread.currentThread().getName() + " onSuccess( " + text + " )"); } } @Override public void onError(Throwable e) { System.out.println(Thread.currentThread().getName() + " onError() " + e); } }); } 결과 main onNext() main onSuccess( A ) main onSuccess( B ) main onSuccess( C ) main onSuccess( D ) main onSuccess( E ) main onSuccess( F ) 10. toMaptoMap은 송신할 데이터를 모두 키와 값의 쌍으로 Map에 담아 전달합니다. 나머지는 toList의 특징과 같습니다. 송신되는 데이터 타입은 Map에 담아서 송신하는데 동일한 key에서 value는 마지막 데이터가 덮어 씁니다. 요청되는 값보다 결과 값이 적을 수도 있습니다. List 값을 손쉽게 key, value로 분리할 수 있는 함수이기도 합니다.public static void toMap() { Single<Map<Long, String>> single = Flowable.just("1A", "2B", "3C", "1D", "2E") //toMap(Fuction keySelector, Function valueSelector, Callable mapSupplier) //keySelector : 받은 데이터로 Map에서 사용할 키를 생성하는 함수형 인터페이스 //valueSelector : 받은 데이터로 Map 넣을 값을 생성하는 함수형 인터페이스 .toMap(value -> Long.valueOf(value.substring(0, 1)), data -> data.substring(1)); //구독을 시작한다. single.subscribe(new SingleObserver<Map<Long, String>>() { @Override public void onSubscribe(Disposable d) { System.out.println(Thread.currentThread().getName() + " onNext()"); } @Override public void onSuccess(Map<Long, String> longStringMap) { //최종 완료된 map을 순서대로 출력한다. for (long id : longStringMap.keySet()) { System.out.println(Thread.currentThread().getName() + " onSuccess( id : " + id + ", value " + longStringMap.get(id) + " )"); } } @Override public void onError(Throwable e) { System.out.println(Thread.currentThread().getName() + " onError() " + e); } }); } 결과 main onNext() main onSuccess( id : 1, value D ) main onSuccess( id : 2, value E ) main onSuccess( id : 3, value C ) 11. toMultiMap키와 컬렉션 값으로 이루어진 Map을 데이터로 변환하여 송신하는 함수입니다. 나머지 특징은 toList, toMap과 같습니다. toMap에서 중복되는 value를 관리하는 건 없었지만, value를 collection으로 관리하여 전달되는 데이터를 모두 수신할 수 있습니다.public static void toMultiMap() { Single<Map<String, Collection<Long>>> single = Flowable.interval(100L, TimeUnit.MILLISECONDS) .take(5) //toMultimap(Function keySelector, Function valueSelector) .toMultimap(value -> { //value가 홀수인지 짝수 인지 판단해서 key값을 리턴한다. if (value % 2 == 0) { return "짝수"; } else { return "홀수"; } }); //구독을 시작한다. single.subscribe(new SingleObserver<Map<String, Collection<Long>>>() { @Override public void onSubscribe(Disposable d) { System.out.println(Thread.currentThread().getName() + " onNext( " + d + " )"); } @Override public void onSuccess(Map<String, Collection<Long>> stringCollectionMap) { for (String key : stringCollectionMap.keySet()) { StringBuffer stringBuffer = new StringBuffer(); for (long value : stringCollectionMap.get(key)) { stringBuffer.append(" " + value); } System.out.println(Thread.currentThread().getName() + " onSuccess( id : " + key + ", value " + stringBuffer.toString() + ")"); } } @Override public void onError(Throwable e) { System.out.println(Thread.currentThread().getName() + " onError() " + e); } }); } 결과 main onNext() RxComputationThreadPool-1 onSuccess( id : 짝수, value 0 2 4 ) RxComputationThreadPool-1 onSuccess( id : 홀수, value 1 3 ) 12. filterfilter는 받은 데이터가 조건에 맞는지 판단해 결과가 true인 값만 송신합니다. 위의 just, fromArray, interval이 반복적인 케이스였다면, filter는 if문처럼 조건문의 역할을 할 수 있습니다. 반복문 함수와 조건문 함수를 같이 사용해 몇 줄 안에 for, if와 똑같이 구현할 수 있죠.public static void filter() { Flowable<Long> flowable = Flowable.interval(300L, TimeUnit.MILLISECONDS) //짝수만 통과한다. 3개만큼 .filter(value -> value % 2 == 0).take(3); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( 0 ) RxComputationThreadPool-1 onNext( 2 ) RxComputationThreadPool-1 onNext( 4 ) RxComputationThreadPool-1 onComplete() 13. distinct이미 처리된 데이터를 다시 볼 필요가 없을 때 사용하는 함수입니다. 송신하려는 데이터가 이미 송신된 데이터와 같다면 해당 데이터는 무시합니다. 이 함수는 내부에서 HashSet으로 데이터가 같은지 확인합니다.public static void distinct() { Flowable<String> flowable = Flowable.just("A", "a", "B", "b", "A", "a", "B", "b") //distinct(Function keySelector) //keySelector : 받은 데이터와 비교할 데이터를 확인하는 함수 //모두 소문자로 변환하여 알파벳 기준으로 데이터를 판단한다. .distinct(value -> value.toLowerCase()); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 main onNext( A ) main onNext( B ) main onComplete() 14. take1.taketake 함수로 지정된 횟수만큼 받은 데이터를 송신합니다. 지정된 횟수에 도달하면 완료를 송신해 처리 종료합니다.2.takeUntil지정된 조건까지 데이터를 송신하는 연산자입니다. 조건이 되면 완료를 송신해 종료합니다.3.takeWhile지정된 조건이 해당할 때만 데이터를 송신하는 연산자입니다.4.takeLast데이터의 끝에서부터 지정한 조건까지 데이터를 송신하는 연산자입니다.take 함수는 한 화면에 출력되거나 칠요한 데이터만큼 리스트에서 값을 하나씩 수신할 때 사용합니다. 예를 들어 화면에 데이터가 6개가 필요하면 take를 이용해 원하는 만큼의 데이터를 가져올 수 있습니다.Flowable.take(6) 또한 이후에 나올 skip 함수를 같이 사용하면 두 번째 화면에서 필요한 데이터를 6개 가져올 수 있습니다.Flowable.skip(6).take(12) 1. take public static void take() { // 100 밀리세컨드만큼 반복하며 총 5개를 출력후 종료한다. Flowable<Long> flowable = Flowable.interval(100L, TimeUnit.MILLISECONDS) .take(5); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( 0 ) RxComputationThreadPool-1 onNext( 1 ) RxComputationThreadPool-1 onNext( 2 ) RxComputationThreadPool-1 onNext( 3 ) RxComputationThreadPool-1 onNext( 4 ) RxComputationThreadPool-1 onComplete() 2. takeUntil public static void takeUntil() { // 100 밀리세컨드만큼 반복하며 값이 5가 될때까지 송신한다. Flowable<Long> flowable = Flowable.interval(100L, TimeUnit.MILLISECONDS) .takeUntil(value -> value == 5); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( 0 ) RxComputationThreadPool-1 onNext( 1 ) RxComputationThreadPool-1 onNext( 2 ) RxComputationThreadPool-1 onNext( 3 ) RxComputationThreadPool-1 onNext( 4 ) RxComputationThreadPool-1 onNext( 5 ) RxComputationThreadPool-1 onComplete() 3. takeWhile public static void takeWhile() { // 100 밀리세컨드만큼 반복하며 값이 5가 아닐경우까지 송신한다. Flowable<Long> flowable = Flowable.interval(100L, TimeUnit.MILLISECONDS) .takeWhile(value -> value != 5); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( 0 ) RxComputationThreadPool-1 onNext( 1 ) RxComputationThreadPool-1 onNext( 2 ) RxComputationThreadPool-1 onNext( 3 ) RxComputationThreadPool-1 onNext( 4 ) RxComputationThreadPool-1 onComplete() 4. takeLast public static void takeLast() { //100밀리 세컨트만큼 반복하며 5개의 출력중 뒤에 2개만 송신한다. Flowable<Long> flowable = Flowable.interval(100L, TimeUnit.MILLISECONDS) .take(5) .takeLast(2); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( 3 ) RxComputationThreadPool-1 onNext( 4 ) RxComputationThreadPool-1 onComplete() 15. skip1.skip함수로 지정된 횟수만큼 받은 데이터 송신을 제외합니다. 지정된 횟수가 초과되면 나머지 데이터를 송신합니다.2.skipUntil지정된 조건까지 데이터 송신을 제외하는 연산자입니다. 조건이 되면 나머지 데이터를 송신합니다.3.skipWhile지정된 조건이 해당될 때만 데이터 송신을 제외하는 함수입니다.4.skipLast데이터의 끝에서부터 지정한 조건까지 데이터 송신을 제외하는 함수입니다.take와 반대의 기능을 갖고 있습니다. 보통 페이저나 리스트에서 paging을 처리할 때는 take와 skip을 혼용합니다.1. skip public static void skip() { //100 밀리세컨드만큼 반복하며 5번 발행하고, 처음 2개를 제외합니다. Flowable<Long> flowable = Flowable.interval(100L, TimeUnit.MILLISECONDS) .take(5) .skip(2); //구독을 시잔한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( 2 ) RxComputationThreadPool-1 onNext( 3 ) RxComputationThreadPool-1 onNext( 4 ) RxComputationThreadPool-1 onComplete() 2. skipUntil public static void skipUntil() { //300밀리 세컨드만큼 반복하며 5개를 발행하고, 1000 밀리세컨드 제외 후 송신합니다. Flowable<Long> flowable = Flowable.interval(300L, TimeUnit.MILLISECONDS) .skipUntil(Flowable.timer(1000L, TimeUnit.MILLISECONDS)) .take(5); //구독을 시잔한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-2 onNext( 3 ) RxComputationThreadPool-2 onNext( 4 ) RxComputationThreadPool-2 onNext( 5 ) RxComputationThreadPool-2 onNext( 6 ) RxComputationThreadPool-2 onNext( 7 ) RxComputationThreadPool-2 onComplete() 3. skipWhile public static void skipWhile() { //300밀리세컨드만큼 반복하며 5개를 발행하고, 데이터 3이 올때까지 데이터를 제외힙니다. Flowable<Long> flowable = Flowable.interval(300L, TimeUnit.MILLISECONDS) .skipWhile(value -> value != 3) .take(5); //구독을 시잔한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( 3 ) RxComputationThreadPool-1 onNext( 4 ) RxComputationThreadPool-1 onNext( 5 ) RxComputationThreadPool-1 onNext( 6 ) RxComputationThreadPool-1 onNext( 7 ) RxComputationThreadPool-1 onComplete() 4. skipLast public static void skipLast() { //1000 밀리세컨드만큼 반복하며 5개를 발행하고 마지막 2개는 제외합니다 Flowable<Long> flowable = Flowable.interval(1000L, TimeUnit.MILLISECONDS) .take(5) .skipLast(2); //구독을 시작한다. flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( 0 ) RxComputationThreadPool-1 onNext( 1 ) RxComputationThreadPool-1 onNext( 2 ) RxComputationThreadPool-1 onComplete() 16. throttleFirst데이터를 송신하고 지정된 시간 동안 들어오는 요청을 무시합니다. 이 함수는 View의 Event 처리에서 많이 사용됩니다. 중복되는 처리를 막기 위해 최초 실행 후 일정 시간 동안 View의 클릭 이벤트나 API 이벤트를 막을 수 있기 때문에 비동기 처리와 화면에 직접적인 피드백이 발생했을 때 throttleFirst를 자주 사용하고 있습니다. //데이터 요청이 30 밀리초마다 5번 발생합니다. //데이터 요청 발생시 100 밀리세컨트 동안 들어오는 데이터 요청을 무시합니다. // — 0 — 1 — 2 — 3 — 4 interval 30 밀리초 마다 // — — -*- — throttleFirst 100 밀리초 무시 Flowable<Long> flowable = Flowable.interval(30L, TimeUnit.MILLISECONDS) .take(5).throttleFirst(100L, TimeUnit.MILLISECONDS); flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( 0 ) RxComputationThreadPool-1 onNext( 4 ) RxComputationThreadPool-1 onComplete() 17. throttleLastthrottleLast 함수는 데이터를 송신하고 지정된 시간 동안 들어오는 마지막 요청을 송신합니다. 이 함수도 throttleFirst처럼 반복적인 선택 이벤트 처리에 유용하게 사용할 수 있습니다. 간단하게 장바구니 카운트 변경을 요청할 때 마지막 변경 이벤트 데이터만 처리하면 되므로 값이 선택되고 일정 시간이 지났을 때 API를 요청해 리소스 낭비를 줄일 수 있습니다.public static void throttleLast() { //데이터 요청이 1 초 마다 6번 발생합니다. //데이터 요청 발생시 2 초 동안 들어오는 마지막 요청을 송신하다. // - 0 - 1 - 2 - 3 - 4 interval 1 초 마다 // - - -* - throttleLast 2 초의 마지막 값 송신 Flowable<Long> flowable = Flowable.interval(1, TimeUnit.SECONDS) .take(5) .throttleLast(2, TimeUnit.SECONDS); flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( 2 ) RxComputationThreadPool-1 onNext( 4 ) RxComputationThreadPool-1 onComplete() 18. throttleWithTimeoutthrottleWithTimeout 함수는 데이터를 송신하고 지정된 시간 동안 다음 데이터를 받지 못하면 현재 데이터를 송신합니다. 완료 시엔 마지막 데이터를 송신하고 종료됩니다.public static void throttleWithTimeout() { Flowable<String> flowable = Flowable.<String>create(emitter -> { emitter.onNext("A"); Thread.sleep(1000L); // 1000 밀리세컨드 슬립 // 500 밀리세컨드 동안 데이터 다음 데이터 요청이 없으므로 A 송신 emitter.onNext("B"); Thread.sleep(300L); // 300 밀리세컨드 슬립 emitter.onNext("C"); Thread.sleep(300L); // 300 밀리세컨드 슬립 emitter.onNext("D"); Thread.sleep(1000L); // 1000 밀리세컨드 슬립 // 500 밀리세컨드 동안 데이터 다음 데이터 요청이 없으므로 D 송신 emitter.onNext("E"); Thread.sleep(100L); // 100 밀리세컨드 슬립 emitter.onComplete(); //완료 요청 시 마지막 데이터 송신 후 종료 }, BackpressureStrategy.BUFFER) .throttleWithTimeout(500L, TimeUnit.MILLISECONDS); flowable.subscribe(new CustomSubscriber<>()); } 결과 RxComputationThreadPool-1 onNext( A ) RxComputationThreadPool-1 onNext( D ) main onNext( E ) main onComplete() ConclusionRxJava에서 많이 사용되고, 또 알고 있으면 좋은 함수들을 살펴봤습니다. 브랜디에서도 이 함수들을 응용해 그동안 다양한 기능을 구현했고, 복잡한 함수도 사용하고 있습니다. 지금까지는 Flowable로 송신과 수신이 1 : 1 로 진행되었지만, 다양한 수신자를 사용해 하나의 Flowable로도 다른 화면에서 여러 수신자를 등록하여 반복적인 작업을 할 수 있습니다. 덕분에 같은 작업을 코드 중복 없이 간단하게 구현할 수 있죠.다음 글에서는 2개 이상의 Flowable을 결합해 사용하는 방법과 Android View에서 RxJava를 응용하는 방법, 구독을 관리하는 방법 등 Android에서 유용하게 쓰는 방법들을 알아보겠습니다.글고재성 팀장 | R&D 개발MA팀[email protected]브랜디, 오직 예쁜 옷만
조회수 1727

Genius? Jininus!

나는 인생을 살면서 많은 "천재"들을 만났다. 스타트업에 있다보면 더더욱 "영재""천재"로 불리는 수 많은 사람들을 보게 된다. 그들은 학문적으로 놀라운 성과와 스펙을 보유하고 있었다. 아마 당신이 한 회사를 운영하는 사람이거나 인사 담당자라면 분명 혹할 것이다. 하지만 정작 나는 같이 일하고 싶었던 사람이 단 한 명도 없었다. 주변에서는 천재들과 같이 일하면 성공할 것이라고 생각하지만, 사업적 결과물과 두뇌는 별개의 문제라고 나는 생각한다. 대단한 능력을 가지고도 빛 없이 사라진 사람들을 얼마나 많이 보았는가. 물론 나도 대단한 사람과 일하고 싶다. 그러나 그 기준을 "영특함"에 국한시키고 싶지는 않다. 사업적으로 혹은 사회적으로 더 나은 미래를 후손에 물려주기 위해서는 그 이상의 "무언가"가 필요하다. 지금부터 나에게 그 "무언가"를 가르쳐 준 "진짜 천재"에 대한 이야기를 하고자 한다. 그에 대한 이야기를 하기 전에 나에 대한 이야기를 가볍게 하고자 한다. 5년 전만 해도 나는 비전과 목표가 없었다. 어려서 부터 돈 욕심만 많았다. 대학교를 다니면서도 돈을 벌 수 있는 방법이면 수단과 방법을 가리지 않았다. 한 일화로 당시에 학원 강사 아르바이트를 하고 있었는데 도매시장에서 트렌디한 문구류를 사와 수업을 가르쳤던 중/고등학생에게 팔았다. 시간과 행동에 제약이 있는 학생들은 수업 시간에 벌어지는 소소한 쇼핑에 돈을 지불했다. 그러나 끝이 좋지 않았다. 학생의 부모님에게 알려져 결국 학원에서 해고 조치 되었다. 지금의 내가 돌이켜보면 엄청나게 창피한 일이다. 학생들에게 단순한 편리와 재미를 줄 순 있었지만, 돈 말고는 남는게 없었다.20대의 대부분은 가치 없는 돈벌이의 연속이었다. 혹자는 말한다. 우선 돈 벌고 가치 있는 곳에 쓰면 된다고. 그러나 이런 식의 무의미한 접근은 내가 가야할 길이 아니라고 느꼈다. 인생에서 가치 있는 일을 찾아야 했다. 그때 발견했다. 혁신, 도전, 열정이 정말 실천되고 있는 세계가 있다는 것을. 스타트업이라는 단어조차 생소했던 시기였다. 심지어 IT라는 분야를 그 전까지 제대로 공부해 본 적도 없었다. 스타트업의 "ㅅ"도 모르던 내가 이 세계에 적응할 수 있는 방법은 뛰어난 사람들과 함께 시작하는 것 뿐 이었다. 온갖 미사여구로 괜찮은 연봉과 복지를 내세우는 기업도 꽤 있었다. 그러나 나에게 가장 중요한 건 "내가 성장할 수 있는지"와 “구성원”이였다. 꽤나 당연한 조건으로 기업을 찾았음에도 불구하고 찾을 수가 없었다. 그러다가 첫 스타트업으로 선택한 게 라우드소싱 이라는 작은 팀이었다. (찾게 된 과정에 대해서는 다른 글을 통해 소개하겠다) 안정적인 연봉도 없고, 확실한 미래도 없었지만 내가 이 팀과 같이 해야겠다 결정한 건 "권진" 이라는 단 한 사람 때문이었다. 모든 기업이 그렇지만 누구나 회사에 합류하면 3개월간의 수습기간을 거친다. 스타트업이라고 예외는 아니다. 오히려 더 냉정하게 자신을 되돌아 보는 시간을 가져야 한다. 나는 내 스스로를 입증하고 싶었다. “제가 3달 안에 이 회사가 성장할 수 있는 계약들을 가져오겠습니다. 그 정도 능력도 발휘 못한다면 제 발로 나가겠습니다” 3달 동안 권진은 일에 대해서 전혀 간섭하지 않았다 . 팀워크에 있어서 가장 중요한 부분은 신뢰라고 생각한다. 하지만 신뢰라는 부분이 친하다고 해서 혹은 비전과 목표가 같다고 해서 생기는 것이 아니다. 각자의 위치에서 최고의 성과를 목표로 내고, 한계를 뛰어넘어 성장하는 모습을 보여줄 때 강력한 신뢰가 생긴다. 서로가 같이 일하고 싶은 마음을 만들어 주는 것.이게 팀워크의 핵심이다. 나는 나대로 권진은 권진대로 각자가 맡은 일들을 완벽하게 수행했고, 우리는 그 일들을 하나의 사업으로 만들어 갔다. 그는 나에게 따로 주저리 주저리 피드백을 하지 않았다. 하지만 행동으로 결과물의 중요성을 보여주었고, 나는 3달동안 7건의 B2B 계약을 성사시켰다.애초에 같이 할 사람을 정할 때는 모든 부분을 면밀히 살피고 고민해야 하지만, 내가 같이 하기로 결정 했다면 상대가 최고의 결과물을 낼 수 있도록 믿어주는 것. 내가 배운 첫번째 교훈이었다.실력을 보여주었다고 환상적인 Fit일까? 누구든 본인이 만들어 내는 결과물을 혼자만의 능력이라고 오판하기 쉽다. 내가 영업처를 설득하고, 계약서를 체결해 왔기 때문에 내가 없었으면 이 계약도 없었을 것이다. 감각적이고 환상적인 디자인을 뽑아냈는데 이건 순전히 나의 재능에 의한 것이다. 팀원들이 이런 생각들을 하기 시작한다면 그 팀은 단시간 내에 모래성처럼 무너질 것이다. 권진은 개인이 만들어 내는 결과물도 팀원들이 각자의 분야에서 해 온 노력들의 최종산출물이라고 생각한다.영업처를 설득할 수 있었던 건, 우리 팀이 환상적인 서비스를 만들어 주었기 때문이다.나의 디자인은 기획팀과 마케팅팀의 노력을 하나로 담은 것 뿐이다.톱니바퀴처럼 팀원들이 맞물려 돌아가며 서로의 존재에 대해 감사함을 느낄 때 놀라운 일이 벌어진다. 내가 배운 두번째 교훈이다.권진이 지켜온 2가지 요건이 계속 좋은 사람을 팀으로 영입할 수 있었던 강력한 요소였다고 생각한다. 나의 실력을 우리 팀에 입증하는 것. 나의 결과물은 우리 팀 노력의 산물 이라는 것.권진과 함께 일하며 느낀 그의 주요한 능력은 개발도 디자인도 아니었다. (물론 이 2가지도 잘한다)팀 내의 균형을 맞추고 팀원들이 끊임없이 성장하게 도와주는데 있다. 개성 넘치는 팀원들을 하나의 비전으로 묶어서 성장할 수 있게 하는 사람을 나는 살면서 권진 이외에는 아직 본 적이 없다. 장담컨데, 만약 현재 더팀스 대표가 권진이 아니라 다른 사람으로 바뀐다면 팀원들은 전부 팀을 나갈 것이다. (연봉이 대폭 인상된다 할지라도)그래서 나는 이걸 Jin in Us 라고 명칭했다. 권진이라는 확실한 구심점 안에 개성넘치는 팀원들이 한 몸처럼 목표로 향해가는. 나는 앞으로 대표라는 역할을 할 생각이 없다. 권진 이라는 사람보다 대표의 역할을 충실히 수행할 자신이 없어졌기 때문이다.리더십이라는 분야가 있다면 그는 천재가 아닐까?내가 우리 팀에 합류시키고 싶은 사람이 있을 때면 하는 단골멘트로 이 글의 마무리를 짓는다.“우리 팀의 권진을 만나보세요. 분명히 함께 하고 싶을 겁니다”#더팀스 #THETEAMS #천재디자이너 #풀스택개발자 #CEO #리더십 #경험공유 #팀원자랑 #팀원소개 #회사의자랑
조회수 2029

왜 차세대 SaaS는 페이스북처럼 될 것인가.  

사람들이 매일 사용하는 서비스 중 가장 유용한 것은 무엇일까?대부분의 경우에 있어, 그것은 Slack, Gmail 혹은 Excel 같은 SaaS 툴이 아닐 것이다. 그것은 바로 페이스북이다.페이스북으로 할 수 있는 모든 것들에 대해 생각해보자.친구들에게 메시지 보내기 영상 통화 하기 뉴스 보기 이벤트 기획하기 사진과 동영상 공유하기사람들은 페이스북에 얼마나 많이 의지하고 있는 지 종종 잊어버리지만, 페이스북은 이미 우리의 일상 생활에 아주 깊숙이 자리잡고 있다. 오늘날에는 수 백만 개의 서비스가 존재하지만, 그들은 그럼에도 만족할 줄을 모른다. 그리고 페이스북은 SaaS 회사들이 할 필요가 있는 것들을 정확히 집어서 하고 있다.On-premise(인하우스 서비스)에서 SaaS(클라우드 컴퓨팅)로SaaS는 “Software as a Service.” 의 약자이다. 페이스북은 사실 기술적으로 SaaS라기 보다는, 일종의 소비자 네트워크 서비스라고 할 수 있다. 하지만 페이스북만큼 많은 서비스를 제공하는 곳은 존재하지 않는다. 페이스북이 이렇게까지 성공한 것은 그 서비스 내에서 유저들의 이용률을 크게 늘렸기 때문이다. 다른 SaaS 기업들은 이 부분을 더 신경 써야 될 필요가 있다. 이용률이야말로 지금 SaaS 비즈니스의 생존에 있어 그 어느 때보다 중요하기 때문이다.그 이유는 다음과 같다. 예전에, 소프트웨어는 회사의 컴퓨터 네트워크에 실제 물리적으로 깔려야만 했다. 소프트웨어 판매업자들은 대기업에 라이선스를 팔기도 했고, 그런 기업들은 해당 소프트웨어 이용을 위해 Accenture나 CSC 같은 회사에 돈을 지불하기도 했다. 당시 판매업자들은 라이선스를 많이 팔기만을 원했지, 얼마나 많은 사람들이 그 소프트웨어를 쓸 지에 대해선 관심이 없었던 것이다.그리고 1999년, Salesforce의 공동 창업자인 Marc Benioff는 새로운 모델을 소개하며 다음과 같이 말했다.“설치하는 데만 수 개월이 걸리고 하드웨어와 네트워킹에 엄청난 투자를 요구하는 비싼 CD-ROM 소프트웨어를 기업들에게 파느니, 우리는 클라우드 컴퓨팅이라고 알려진 모델을 통해 Software-as-a-Service(SaaS)를 팔기로 했다. 기업들은 이제 유저의 수에 맞춰 서비스를 이용한 만큼 비용을 지불해야 할 것이고, 그런 서비스들은 인터넷, 클라우드를 통해 즉시 제공될 것이다.”구독 기반(subscription-based) 소프트웨어는 회사 내부의 데이터 센터가 아닌 웹 브라우저를 통해 제공된다. 이는 소프트웨어 개발자로 하여금 언제든지, 즉각적으로 그들의 고객에 접근할 수 있게 해주었다. 어느 순간, 유저를 만족시키는 일은 CIO(Chief Information Officer)나 시스템 통합업체의 책임이 아니게 된 것이다. 그 일은 이제 소프트웨어 판매업자가 하게 되었다.이러한 클라우드 컴퓨팅 방식은 SaaS 소프트웨어로 하여금 생존을 위해 끊임없이 자신들의 가치를 어필하게끔 만든다. 그리고 SaaS 회사들은 계속해서 자신들의 소프트웨어를 이용하는 소비자들을 확보하기 위해 많은 양의 돈을 쓰고 있다. 이는 과거 기업 고객들에게 소프트웨어 라이선스를 팔러 다니던 때와는 180도 달라진 상황인 것이다. 오늘날의 SaaS 회사들은 예전처럼 높으신 몇몇 분들을 만나 무언가를 사라고 설득할 필요가 없다. 그저 이용자들이 자신들의 제품을 계속 사용하게끔 유도하면 되는 것이다.페이스북은 SaaS의 새로운 모델이다이제 페이스북을 한 번 살펴보자. 페이스북은 클라우딩를 통해 지속적으로 서비스를 제공한다. 그들은 광고를 통해 돈을 벌기 때문에, 그들의 가장 중요한 목표는 사람들로 하여금 계속 서비스를 이용하게 하는 데 있다. CIO들을 만나서 큰 계약을 체결하는 데 시간을 쓸 바에야 그 100분의 1초도 안 되는 시간에 12억 명의 사람들에 서비스를 파는 것이 더 낫다는 것이다.페이스북이 딱 한 가지 신경 써야 될 것이 있다면 그것은 사람들이 지금보다 더 적극적으로 페이스북을 이용하게끔 만드는 것에 있다.“우리의 최우선 목표는 모바일 장치나 개인용 컴퓨터를 통해 사람들을 연결시켜주고 공유하게끔 하는 유용하고 매력적인 서비스를 창조하는 것에 있습니다.” – 미국증권협회 기업정보 페이지의 페이스북 파일에서페이스북이 사람들의 관심을 많이 받을수록, 그들은 더 많은 광고를 사람들에게 보여줄 수 있다. 페이스북에게 있어서, 그러한 관심은 아주 중요한 것이다. 더 많은 관심을 받는 다는 것은 더 많은 성장과 확장의 기회를 갖는 다는 것을 의미하기 때문이다. 이것은 드롭박스나 Slack과 같이 바텀업 방식으로 성장한 SaaS 기업들이 새겨들어야 할 점이다. 유저들이 서비스를 쓰는 시간이 많아진다면, 앞으로 그들에게 더 많은 다른 서비스를 쓰게 만들 수 있기 때문이다.앞으로 페이스북이 더 성장하고 발전하려면 유저의 관심이 필요하다. 그래야 여러 방면에서 이용률을 늘릴 수 있는 방법을 찾을 수 있기 때문이다. 이제 여기서 페이스북이 그들 서비스의 이용률과 성장을 이뤄낸 3가지 방법에 대해서 소개해 보도록 하겠다. 모든 SaaS 기업들은 비슷한 방법으로 자신들의 이용률과 성장을 이뤄낼 수 있을 것이다.페이스북은 이용률을 측정하여 현재 운영하는 서비스를 최적화 시켰다페이스북은 이용률을 늘리기 위해 새로운 서비스를 내놓는다페이스북은 다른 앱들과 통합하는 과정을 거쳤기 때문에 페이스북을 쓰지 않는 사람들조차 페이스북을 쓰게 되었다페이스북이 이용률을 어떻게 늘렸는지에 대해 좀 더 깊이 이야기해 보도록 하겠다. 그러고 나면 페이스북의 노하우를 다른 SaaS에 어떻게 적용할 수 있을 지 분명하게 보여줄 수 있을 것이다.이용률 측정을 통해 서비스의 최적화를 이뤄낸다지금 사람들이 어떻게 서비스를 이용하고 있는 지 모르고 있다면 그들에게 당신의 서비스를 사용하게 만들 수도 없을 것이다. 페이스북은 이용률을 늘리는 방법에 대해 집요하게 연구해왔기 때문에 좋은 사례로 들기에 적합하다.핵심은 사람들이 지금 하고 있는 것, 그리고 그들이 원하는 것을 정확하게 아는 것에 있다. 페이스북은 단순히 월 이용자 수나 일 이용자 수를 알아보려 애쓰지 않는다. 왜냐하면 그런 수치들은 사용자들이 그 서비스를 통해 무엇을 하는지를 전혀 설명하지 못하기 때문이다. 대신 페이스북은 서비스 이용의 질적인 부분에 집중한다. 사람들이 페이스북을 통해 무엇을 이루려고 하는 지와 그들이 실제로 그렇게 할 수 있는 지에 대해서 말이다.이 부분에 있어 페이스북의 대표적인 전략 중 하나가 바로 10일안에 친구 7명 만들기이다. 일찍이, 페이스북은 10일안에 7명의 친구를 만드는 사람은 페이스북을 계속 사용할 확률이 훨씬 더 높다는 사실을 알게 되었다. 일단 이것을 알게 되자, 그들은 신규 유저들이 7명의 친구를 만날 수 있게 하기 위해 가진 모든 수단을 쓸 수 있게 된 것이다.바로 지금도, 페이스북은 새로운 친구를 추가할 것을 사람들에게 계속해서 권장한다. 왜냐하면 이것이야 말로 네트워크를 이루는 데 있어서 가장 가치 있는 부분이기 때문이다.페이스북 계정을 만들자마자, 유저들은 뉴스 피드 상단에 새로운 친구를 추가하시겠냐는 메시지가 뜨는 것을 볼 수 있다.아래 사진은 유저들이 다른 페이지를 둘러 보는 동안 뜨는 사이드바인데, 보다시피 그들이 알 수 있을 법한 사람들을 친구로 추가하게끔 권장하고 있다.또한 페이스북은 뉴스 피드와 같이 그 기능을 최대한 활용하기 위해 더 많은 친구들을 추가할 것을 권장하고 있다.페이스북은 이런 전략을 앞으로도 고수할 것이다. 2017년, 페이스북은 “Discover people” 이라는 새로운 기능을 출시했다. 이는 당신으로 하여금 프로필을 업데이트 하게끔 유도하고 기존에 친구가 아니더라도 같은 이벤트에 참여하는 경우 서로를 연결시켜 준다.페이스북은 사람들이 자신들의 서비스를 계속 이용하게 만들기 위해 기나긴 세월 동안 노력해왔고 앞으로도 그럴 것이다. 그들은 친구 최적화를 빠르게 해줄 뿐만 아니라 흥미를 잃은 사람들도 쉽게 다시 돌아올 수 있도록 여러 요인들을 제공해준다. 페이스북의 성장 전담 부서를 이끌고 있는 Chamath Palihapitiya은 “당장의 단기적인 이익에만 집중하지 않기 위해서는 절제력이 필요하다.” 라고 말한다. 페이스북은 초창기부터 무엇보다 사람들의 이용률이야말로 그들의 성패를 좌우한다는 것을 알고 있었다. 사람들의 주된 목표를 파악해서 이용률을 장기적으로 늘리는 것이 그들의 제1과제 였던 것이다.Trello는 어떻게 유저들이 쉽게 직장 동료를 추가하도록 만들었는가페이스북과 똑같이, Trello는 유저들이 무엇을 하는지를 이해하고 그들이 원하는 걸 더 많이 하게 도와주는 방식으로 이용률을 올렸다. Trello의 핵심적인 가치는 사람들이 프로젝트를 협력하게끔 만드는 것이었기 때문에, 그들이 그렇게 하도록 도움을 줘서 자신들 서비스의 가치를 보여줘야 했다.그래서 Trello가 직장 동료를 추가하는 방식은 놀라울 정도로 쉽게 되어 있다. 이는 페이스북이 친구를 추가하는 방식과 정확히 똑같다. 페이스북이 사람들로 하여금 쉽게 친구를 추가하게 하여 소셜 네트워크의 가치를 입증했다면, Trello는 쉽게 동료들을 추가하게 하여 프로젝트 협업 툴로써의 가치를 입증했다.Trello는 유저들로 하여금 이름이나 이메일 주소로 아는 사람들을 등록할 수 있게 만들었다. 유저들은 코드나, ID, 링크 같은 것 없이도 사람들을 쉽게 추가할 수 있다. 심지어 다른 사람들이 Trello를 사용하는지도 알 필요가 없다. 어찌 됐든 Trello를 통해 사람들을 찾아보고 확인해 볼 수 있는 것이다.또 만약 Trello를 한 번이라도 썼던 사람이라면 더욱 쉽게 목록에 추가할 수 있다.이런 방식을 통해 이용자들은 아무런 마찰 없이 많은 동료, 협력자들을 통해 프로젝트를 공유할 수 있다. 즉, Trello의 핵심 가치를 이루게 되는 것이다. 이는 사람들에게 Trello가 얼마나 유용한 서비스인지를 빠르고 쉽게 이해시켰다. 또한 이는 더 많은 사람들이 더 많은 프로젝트를 하게끔 유도했고, 결국 모두가 Trello를 더 많이 이용하게 되었다.Slack은 어떻게 이용률을 늘려왔는가이렇게 사용자의 이용률에 집중해서 성장을 이루고 있는 유명한 SaaS 기업이 또 하나 더 있다. Slack이 바로 그 기업인데, Slack은 메시지를 매끄럽게 전송하는 역할 하나에만 전념하고 있다.Slack은 자신들의 서비스를 이용해 2000개 이상의 메시지를 보낸 적 있는 팀들은 Slack의 가치를 알고 있기 때문에 앞으로도 계속 서비스를 사용할 것이라고 예측한다. 왜냐하면 Slack의 통계에 따르면, 다른 요소들이 어떻든 간에, 2000개 이상의 메시지를 보낸 팀들 중 93%가 지금까지도 Slack을 사용하고 있기 때문이다. 그래서 이용률을 늘리기 위해선, 메시지를 보내는 것을 더 쉽게 만들어야 하는 것이다. Slack의 공동 창업자인 Stewart Butterfield 역시도 이 목표를 위해 사람들이 실제로 어떻게 Slack을 쓰고 있는가에 대해서 생각해보았다.“처음으로 Slack을 쓰려고 온 사람이 되었다고 생각해 보는 겁니다. 특히 진짜 사회생활을 하는 사람들 말이죠. 상사에게 Slack을 쓰라고 해서 쓰게 된 사람, 아침 먹을 시간도 없어서 짜증이 난 사람, 주말이 오기 전에 프로젝트를 끝낼 수 있을지 걱정하는 사람… Slack을 면밀히 살펴봐서, 이런 사람들에게 먹히지 않을 것 같은 요소들을 생각해 내는 겁니다. 냉정하게 보는 거에요. 최고의 서비스를 주기 위해서 말이죠.”Slack은 메시지 전송에 따르는 불편함을 개선하면서 이용률을 늘려왔다. 그러한 개선의 예를 들어 보자면, 누군가가 Slack에서 링크를 걸었다고 했을 때, Slack은 그 링크에 대한 간단한 정보를 미리 보여준다. 즉, 사람들은 링크를 보려고 앱에서 빠져나와야 될 필요가 없는 것이다. 나중에 다시 그것을 확인해보기도 편하고 말이다.이런 시스템상의 개선점들이 Slack을 성장하게 만들었다. 메시지를 보내는 것에 있어서 사람들이 원하는 부분을 아주 쉽게 할 수 있게 만들었기 때문이다.이렇듯 페이스북, Trello, Slack은 모두 실제 이용자들이 원하는 것을 이해하고 그들이 그것을 쉽고 빠르게 할 수 있는 서비스를 제공하고 있다. 아래에 이런 SaaS 기업들이 어떻게 자신들의 서비스를 통해 이용자들에게 도움을 줬는지 요약해보았다.페이스북의 10일안에 친구 7명 만들기, Slack의 2000개 이상의 메시지 보내기, Dropbox의 파일 한 개 업로드 하기 등과 같이 그들은 수치로 표시되는 목표를 세웠다. 이러한 목표는 당신의 팀으로 하여금 무엇이 가장 이용률을 끌어오는데 중요한 지를 확인시켜줄 뿐만 아니라 그들에게 목표 달성을 위한 구체적인 숫자를 알려준다.핵심적인 기능들을 사람들이 이용하게 하려면 그것을 직관적으로 만들어야 한다. Raymond Loewy(미국의 전설적인 산업 디자이너)에 따르면, 성공적인 서비스는 사람들이 당장 사용하기에 편해야 한다고 한다. 예를 들어, 페이스북이 처음 “On this day” 서비스를 도입한 것은 유저들로 하여금 무언가 새로운 것을 하는 걸 권하기 위해서였다. 하지만, 이 서비스는 여전히 유저들에게 친숙한 태그, 공유하기 기능들을 사용하고 있다.유저들의 참여를 막을 만한 요소들을 찾아서 없애야 한다. 사용자들이나 얼리 엑세스 베타 테스터 등과 이야기를 해봐서 무엇이 서비스에 있어 가장 짜증나는 요소인지 알아내야 한다. “이거 어떻게 하는 건지 모르겠어요” 라던가 “이게 좀 쉽게 됐으면 하는데…” 와 같은 불만들에 귀기울여야 한다. 이런 장애물들을 제거하면 유저들이 서비스를 이해하기 더 쉽고 그 서비스의 가치를 파악하는 것 역시 쉬워진다.즉, 현재 가지고 있는 서비스 내에서 이용률을 끌어올리려면 유저들에게 무엇이 가장 도움이 되고 의미가 있는지 파악하는 것이 가장 중요하다고 할 수 있다.이용률을 늘리기 위해 서비스를 추가한다이용률을 끌어올린다는 것은 단순히 사람들로 하여금 기존의 서비스를 계속 쓰게 만드는 것 만을 의미하지는 않는다. 당신은 끊임없이 실험을 해보고 새로운 서비스를 제공해서 유저들이 서비스를 통해 더 많은 것들을 얻을 수 있도록 해야 한다.페이스북은 기존에 그들이 가진 서비스가 수명이 다할 것을 걱정해서 계속 실험을 하고 이용자들이 앞으로 무엇을 원할지를 예상해왔다.페이스북의 직원 가이드북을 보면, 새로운 직원들은 그들의 팀이 계속 새로운 생각을 하게끔 자극 할 것을 권장하고 있다.그 결과, 페이스북은 끊임없이 혁신하고, 또 그만큼 실패를 경험하고 있다.페이스북은 스냅챗으로부터 이용자들을 뺏어오기 위해 2012년 별도의 앱인 Poke를 출시한다. 그런데 이 앱은 대실패작이 되었고 페이스북은 얼마 지나지 않아 앱스토어에서 이 앱을 삭제하게 되었다.2014년에 페이스북은 이용률을 늘리기 위한 일환으로 슬링샷이라는 앱을 출시했다. 이 앱은 사진과 함께 메시지를 보내면 스냅챗과 같이 몇 초안에 사라지는 것이 특징인데 불과 1년만인 2015년에 앱스토어에서 내려가게 되었다.또 페이스북은 2016년 Quick Update라는 것을 시도했다. 이는 스냅챗과 비슷한 기능을 페이스북 앱에 추가시키는 것이었는데, 이런 기능을 유저들을 대상으로 그룹테스트 해 본 결과 반응이 좋지 않아 결국 공식적으로는 출시되지 못하게 되었다.이런 좋지 않은 결과들은 페이스북이 혁신에서 실패하고 있다는 소문을 자아냈다. Jason Calacains 같은 논평가는 이에 대해 “페이스북의 앱 플랫폼은 망하기 위해서 혁신을 하는 것인가?” 라고 하기도 했다.하지만 페이스북의 이런 계속되는 시도는 결국 그들을 새로운 기회로 인도했다. 그들은 스냅챗의 스토리 기능을 페이스북과 인스타그램에 도입하려고 시도해 왔는데 이 과정에서 마침내 페이스북 라이브라는 새로운 서비스를 만들어냈다. 이 서비스는 대히트를 쳤고, 이제 회사, 미디어, 그리고 유명인사들까지 모두 페이스북의 라이브 스토리를 사용하고 있다.이렇듯 페이스북이 큰 성공을 거둘 수 있었던 이유는 그만큼 실패도 많이 해봤기 때문이다. 그들은 그저 사람들이 관심 가질 만한 새로운 무언가를 계속 만드는데 집중할 뿐이다. 왜냐하면 이런 시도야말로 궁극적으로 이용률을 더 많이 올릴 수 있는 방법이기 때문이다.드롭박스 역시 이용률을 높게 유지하기 위해 새로운 서비스를 만들고 있다SaaS 기업들은 현재의 서비스보다 한 걸음 더 앞선 서비스 제공을 통해 이용률을 끌어올릴 수 있다. 그들은 지금 하는 것 이외에 이용자들이 무엇을 더 원하고 더 신경 쓸까를 생각해 볼 필요가 있다.그 예로 드롭박스의 드롭박스 페이퍼를 들 수 있다. 드롭박스는 원래 파일 공유 서비스였다. 하지만 오늘날, 드롭박스는 파일을 공유하는데 있어 다양한 방법을 제공해준다. 만약 드롭박스가 처음 서비스 이외에 유저들이 뭘 더 원할 것인 지를 생각해보지 않았다면 결국 이용률을 올릴 방법이 바닥나서 망하게 됐을 것이다.즉 드롭박스는 단순한 파일 공유 서비스에서 사람들이 함께 일하는 걸 더 쉽게 만들어 주는 일종의 팀 협업 툴로 자신들의 브랜드를 쇄신한 것이다. 이러한 재브랜딩 과정과 함께, 드롭박스는 2015년에 “창조적인 업무를 위한 새로운 형태의 파일 편집 툴” 이라는 신규 서비스인 드롭박스 페이퍼를 런칭했다.드롭박스 페이퍼는 단순히 문서와 파일을 저장하는 데 드롭박스를 쓰는 것이 아니라, 이제 문서와 파일을 만드는 데에도 드롭박스를 쓸 수 있게 만들어 주었다. 드롭박스 페이퍼는 사람들이 더 많이 서비스를 이용하게 만들었는데, 이는 파일 공유를 넘어 사람들간의 협업을 더 쉽게 해준다는 추가적인 옵션을 제공해줬기 때문이다.드롭박스가 이렇게 새로운 서비스를 만들려는 이유는 생존하기 위해서이다. 이 산업에 있어 망하는 일은 너무나 쉽게 일어나기 때문이다. Intercom의 Des Traynor는 다음과 같이 이를 설명한다.“원래 이쪽 산업이란 게 이런 겁니다, 기술이란 것의 특성 자체가 이런 것이죠. 모든 서비스가 결국 다 죽어 없어지게 되어있습니다. 만약 내 말이 사실이 아니라고 생각한다면 저에게 그렇지 않은 경우를 알려주세요. 한때는 SaaS 비즈니스가 절대 안 망할 것 같은 시절도 있었습니다. 하지만 더 이상은 아니에요.”만약 당신이 유저들이 당장 원하는 것에 대해서만 생각하고 있다면, 이미 망하고 있는 것이다. 성공적인 SaaS 기업들은 항상 유저들이 미래에 뭘 원하게 될 지에 대해서 생각한다. 아래에 SaaS 기업들이 어떻게 소비자들의 미래 욕구와 새로운 서비스에 대해 예측하려 하는 지 정리해보았다.당신의 경쟁자들, 그리고 왜 유저들이 그들의 서비스를 이용하는지 이해하라. 온라인 포럼 등을 보고 사람들이 경쟁사의 서비스를 어떻게 평가하는지를 알아내라. 이를 통해 당신은 사람들이 무엇을 원하는지, 그 방향이 어디로 향하게 되는지에 대한 통찰력을 얻게 된다. 이런 과정은 서비스의 확장과 새로운 서비스를 실험해 볼 수 있는 기회도 제공해준다.당신의 서비스를 사용했을 때 유저들이 무엇을 할 수 있을지를 생각해 봐야 한다. 유저들이 당장 요구하는 것만 만드는 것이 아닌 그들이 앞으로 원할 것이 무엇인지를 한 발 앞서 생각해 보는 것이다. 예를 들어, 아마존이 최근 개시한 새로운 서비스인 “Your idea” 리스트를 보자. 이 서비스는 유저들이 쇼핑을 하면서 비록 구입 하진 않더라도 커뮤니티에 자신이 생각한 리스트를 보여주고 싶은 욕구를 미리 연구해서 나온 결과물이다.가장 효과적이면서도 남들이 쉽게 예상하기 힘든 기능들을 우선순위로 짜는 것이 좋다. Gusto의 Tomer London은 서비스를 만들고 그것을 개선시킬 때, 가장 좋은 기능은 타인이 예측하기 어려움에도 불구하고 사용자 경험을 개선시키는데 가장 효과적인 것들이라고 한다. 사람들이 서비스를 통해 무엇을 가장 하고 싶어하는 지를 이해하고 그들을 도와줄 더 쉽고 나은 방법들을 생각해본다면 가장 효과적인 기능에 대한 단서를 잡을 수 있다. 남들이 예측하기 어려운 방법들은 당신이 처한 경쟁 지형에 대해 이해함으로써 알아갈 수 있다. 서비스 이용률을 늘리기 위해 다른 서비스와 통합한다우물 안의 개구리처럼 서비스를 홀로 제공하려 한다면 최대한의 이용률을 얻기란 요원하다. 당신은 새로운 서비스를 내놓음으로써 이용률을 늘릴 수 있지만, 그것으론 충분하지 않다. 유저들은 항상 다른 서비스 역시도 사용하고 있다. 당신이 이길 수 있는 방법은 당신의 서비스를 다른 서비스에 포함시킴으로써 사람들이 그 서비스를 쓸 때, 당신의 서비스도 쓰게 만드는 것이다.당신이 페이스북 웹사이트나 앱을 통해 페이스북을 쓰고 있지 않더라도, 당신은 페이스북을 사용하고 있는 것이나 마찬가지이다.페이스북을 이용해서 다른 서비스에 로그인 할 수 있다당신은 다른 웹사이트의 컨텐츠를 페이스북에 공유할 수 있다당신이 작업하는데 쓰는 서비스를 페이스북에 연결시킬 수 있다.티켓마스터를 통해 공연 티켓을 구매하는 것 역시도 페이스북으로 할 수 있다.페이스북은 다른 서비스들과도 완전히 통합이 되었기 때문에 사람들은 페이스북 인터페이스를 다른 서비스에서 보더라도 전혀 이상하게 생각하지 않는다. 심지어 어떤 경우에는, 페이스북 계정이 없다면 다른 사이트에 가입하기 어려울 때도 있다.페이스북이 다른 서비스와 더 통합이 될수록 당신은 더 페이스북을 쓰게 되고 그것을 필요로 하게 된다. Social Capital LP의 공동 경영자인 Arjun Sethi는 이점에 대해 다음과 같이 말한다.“페이스북이 권장하는 행동들이 일종의 문화가 되고 있어요. 페이스북은 그냥 가만히 앉아서 다른 서비스가 자신의 특징들을 베끼는 걸 보고만 있지 않았습니다. 자신들의 서비스를 다른 곳에 아주 쉽게 통합될 수 있게 만들었고 그 과정에서 핵심적인 이득은 다 챙겨갔습니다.”이것은 페이스북의 신중한 성장 전략의 일환이다. 다른 서비스의 개발자들이 페이스북을 쉽게 그들의 서비스에 통합할 수 있게 만듦으로써, 그냥 자신들의 서비스 내에만 머물러 있는 것에 비해 훨씬 더 많이 사람들이 페이스북을 사용하게끔 만들었다.Slack 역시도 다른 툴과 쉽게 통합이 가능하다페이스북이 다른 소셜, 라이프스타일 서비스들과 통합해서 유저들을 끌어모은 것처럼, Slack 역시도 자신들의 서비스를 다른 관련된 툴들과 통합할 수 있게 만들었다.Front와 같은 이메일 클라이언트와의 통합은 사람들로 하여금 Slack에서 바로 이메일을 관리할 수 있게 하였다.Slack은 또 Stripe와 통합을 하였는데, 이로 인해 사람들은 Slack 내에서 고객 결제 데이터를 보고 관리할 수 있게 되었다.Google Docs와의 통합으로 Slack 앱을 나가지 않고도 구글 문서 활동들을 볼 수 있게 되었다.Slack은 서드 파티의 통합을 장려하기 위해 거대한 앱 생태계를 구축하고 있다. 2015년에, 그들은 앱과 관련해서만 8천만 달러의 벤처 펀드를 만들었다. 2016년에, Slack은 자신의 플랫폼 내에 600개 이상의 앱을 보유하게 되었다. 그래서 이메일을 관리하거나, 고객과 커뮤니케이션을 하거나, 제품 분석 결과를 보는 것 등을 하러 다른 곳으로 일일이 가는 대신에 Slack 유저들은 기존 자신들의 서비스를 통해서 그 모든 것들을 할 수 있게 되었다.페이스북과 Slack은 그들 서비스의 유저들이 사용할 만한 다른 서비스들과 통합을 통해 이용률을 올렸다. 당신 서비스의 이용자들도 알고 있는 이런 기술의 생태계 속에 당신의 서비스를 끼워 넣는 방법에 대해 아래에 정리해 보았다.당신의 서비스를 사용하는 유저들의 워크플로우 대해 생각해보고 그것을 개선시킬 수 있는 점들에 대해서 추측해보라. 예를 들어, HubSpot을 이용하는 기업들의 궁극적인 목적은 사람들을 광고로 유인해서 실제 고객으로 만드는 데 있다. 그래서 HubSpot은 그 목적을 더 잘 수행하기 위해 자신들의 CRM 툴을 페이스북의 광고 관리 프로그램인 Adespresso와 통합할 수 있 게 만들었다. 즉, 사람들이 페이스북 광고를 클릭하게 되면 그 유저의 정보는 자동으로 그들의 CRM에 업로드가 된다.다른 유명 서비스들과의 통합을 통해 그들의 규모가 가진 이점을 가져오는 것이 좋다. 눈에 잘 띄는 서비스와의 통합은 당신의 서비스 역시도 눈에 잘 띄게 만들어준다. 잠재적 유저들에게 당신의 서비스를 소개할 수 있는 기회를 더 얻을 수 있을 뿐만 아니라, 다른 유명 서비스가 가진 브랜드 신뢰성 역시도 가져올 수 있다. 만약 당신의 회사가 아직 작다면, 유명하고 접근하기도 쉬운 Slack이나 페이스북과 같은 서비스와 함께 시작하라.Zapier를 활용해서 다른 서비스들과의 통합을 도모해라. Zapier에 호환이 되도록 앱을 만든다면, 유저들로 하여금 당신이 아직 직접적으로 통합을 제안하기 어려운 다른 앱들과 통합할 수 있는 옵션을 제공해 주는 것과 다름이 없다. 이 방법은 당신의 서비스가 아무리 독특하다 할지라도 그것을 유저들의 워크플로우에 집어넣는 데 도움이 된다.서비스를 개선시키는 데 있어 한 가지 방법만 써서는 이용률을 끌어올리는 데 한계가 있다. SaaS 기업들이 정말로 유저들로 하여금 그들의 서비스를 계속 좋아하고 이용하게끔 만들려면, 할 수 있는 모든 방면에서 이용률 최적화를 해야 한다. 기존의 서비스 내에서 할 뿐만 아니라, 새로운 서비스, 다른 유저들에게 이미 필요한 다른 서비스와의 통합을 해서라도 말이다.차세대 SaaS를 만드는 것에 대해SaaS 서비스들은 점점 더 무용지물이 되어 가는 경우가 많고 사라지는 서비스들도 많다. 만약 SaaS 기업들이 왜 사람들이 그들의 서비스를 쓰는 지 이해하지 못한다면, 그들은 계속 성장할 수 없을 것이고 유저들도 이탈할 것이다.지금까지의 내용을 정리하자면 페이스북은 이용률과 성장을 도모할 수 있는 매우 포괄적이면서도 단순한 방법 3가지를 생각해냈다. 사람들이 현재의 서비스를 더 많이 사용하게 만드는 것, 새로운 서비스를 통해 더 많이 사용하게 만드는 것, 그리고 다른 서비스와의 통합을 통해 자신의 서비스를 더 이용하게 만드는 것. 이 3가지이다. 그리고 이렇게 이용률을 올린다는 것은 성공을 의미한다.미래에 가장 성공적인 SaaS 기업 역시 이용률에 중점을 두게 될 것이다. 지금까지 페이스북을 모델로 삼아 설명한 것처럼, 이것들이 SaaS 기업이 앞으로 더 나은 서비스를 만드는 방법이 될 것이다.원문 : 프로덕트해빗#더팀스 #THETEAMS #SaaS #인사이트 #페이스북
조회수 1319

EOS Smart Contract 배포

Smart Contract 배포를 위한 준비 과정은 이전글 확인 부탁드립니다.저번시간과 연계하여 이번 시간엔 스마트 컨트랙트를 배포해 보도록 하겠습니다. 지갑 key와 계정 이름등은 본 포스팅에서 그대로 사용하시면 됩니다.배포할 컨트랙트는 eosio.token 으로 eos 개발환경 세팅 시 존재하는 코드를 컴파일하여 실제 사용하는 계정에 setting 하겠습니다. 먼저 컴파일을 위해 ../eos/contracts/eosio.token 으로 이동 하겠습니다.eos/contracts/eosio.token이동 하면 위와 같은 파일들을 확인 하실 수 있습니다.hpp : cpp 파일에서 사용하는 변수, 상수, 함수를 담는 헤더파일cpp : contract 함수를 구현하는 소스 파일eosiocpp 를 통해 소스코드를 컴파일 해보겠습니다. eosiocpp 는 WASM 및 ABI 컴파일러 로써 블록체인에 업로드 되는 .wasm, .wast, .abi 파일을 생성합니다. 또한 기본 스켈레톤 파일을 제공합니다eosiocppwasm 컴파일wasm 파일은 아래 명령어를 사용하여 컴파일 만들 수 있습니다.$ eosiocpp -o eosio.token.wast eosio.token.cppeosiocpp 명령어를 사용하여 컴파일 하게 되면 .wast 파일과 .wasm 파일을 생성하게 됩니다. 각 확장자는 다음을 의미합니다.wast : 텍스트 파일로써 읽을 수 있는 webAssembly 파일wasm : 컴퓨터가 실제로 이해할 수 있는 webAssembly 파일abi 파일 생성$ eosiocpp -g eosio.token.abi eosio.token.cppabi 파일은 JSON과 Binary 간에 사용자 작업을 변환하는 방법에 대해 설명해주는 파일입니다. 실제로 이 JSON 파일을 통해 블록체인 위에서 개발자와 사용자간 상호작용 하는데 도와주게 됩니다.위 2과정을 통해 abi 파일 과 wast 파일을 생성하게 됩니다.compile 결과Contract 세팅하기아래 명령어를 입력하여 contract 를 set 해줍니다.$ cleos set contract hexlanthenry ../eos/build/contracts/eosio.token account : contract 를 배포할 계정이름contract-dir : 계정에 set 할 contract 가 저장된 directoryset contract 수행 결과만약 해당 계정이 RAM 을 보유하고 있지 않다면 다음과 같은 에러가 나타날 것입니다. 이를 해결하기 위해 RAM 을 구매합니다.RAM을 보유없이 contract$ cleos system buyram hexlanthenry hexlanthenry "100.0000 EOS"payer : EOS 를 지불할 계정receiver : RAM 을 사용할 계정amount : 지불할 EOS의 양 ( eos 1.1 기준 소수점4개 자리와 symbol을 무조건 넣어주어야 정상 동작 합니다)contract 확인계정에 contract가 잘 배포 되었는지 확인해 보겠습니다.$ cleos get code hexlanthenry배포한 contract 가 있을때의 code hash배포한 contract 가 없을때의 code hash또한 abi 를 통해서도 확인할 수 있습니다.$ cleos get abi hexlanthenryget abi위 과정을 통해 해당 계정에 실제로 contract 가 잘 배포 되었는지 확인 할 수 있습니다.다음 시간에는 배포된 contract 를 통하여 토큰을 발행 해보고 token에 대한 balance 체크 및 transfer 하는 과정을 진행해 보도록 하겠습니다.+또한 abi를 분석하여 struct 와 action 을 어떻게 확인 하는지에 대한 자세한 방법은 다른 포스팅에서 다루도록 하겠습니다.감사합니다.#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심

기업문화 엿볼 때, 더팀스

로그인

/