기록으로 남겨보고 싶었다.사업이 성공적으로 launching되고 나서, 지금의 고민이 나중에 어떻게 증명될 수 있을까에 대한 호기심이랄까? ^^;; 새로운 서비스를 만들어가는 과정에 대한 기록을 남기는 것이 이 글의 목적이다. Brunch에 쓰기 전에 다른 곳에 남겼던 기록들을 이곳으로 옮겨왔다.Phase 0. 향수 서비스를 고민하기 시작하다.사실 지금 고민하고 있는 서비스는 어떤 특정한 problem을 해결하겠다는 접근에서 시작된 것이 아니었다. 원향(Fragrance oil)을 제조하는 회사와 business 관계가 있었고.. 4년 전 처음 그 회사(DROM fragrance)와 업무가 시작될  때부터 그 향을 어떻게 사용해 볼 수 있을까에 대한 고민을 하고 있었다. 그러던 중, Kukka 서비스를 보면서 향을 subscription 해주면 어떨까? 라는 아이디어를 떠올리고 비즈니스 모델을 생각하기 시작하였다. 향수는 지금까지 강력한 브랜드 가치를 통해 "오만한" 가격을 받고 있으며.. start-up에게 깨져본 적이 없는 영역이었다.Phase I. 서비스 모델을 구체화해 나가다..향수를 SPA업체들과 같이 트렌디하게 빨리 만들어서, 그 시점의 trend에 맞게 또한 날씨, fashon 및 occasion을 세팅하여서 한 달 정도에 사용 가능한 5ml 정도를 보내준다면 남기지 않고 잘 사용하고 버릴 수 있지 않을까?Phase II. 문제를 define 해보기 시작하다.사실 문제를 발견하고 그것을 어떻게 서비스화 할 것인가에 대한 고민이 순서에 맞다고 생각하지만, 향수라는 토픽을 정해 두고 시작하니 문제를 오히려 찾아야 하는 상황이다..  파우더 룸 같은 유명 female 카페에 가서 향수 카테고리를 뒤져보니..  남자친구나 저에게 어울리는 향이 무엇일까요? 가 problem number 1이고..   향수 소분 해서 팝니다... 연락 주세요! 가 problem number 2이고..  내가 생각하는 것은.. 향이 50ml, 100ml 이렇게 팔다 보니 너무 많이 집에 쌓아있다는 점.  나에게 어울린다고 생각하는 향수가.. 날씨, occasion 등을 모두 cover 할 수 있을까?   향수를 들고 다니기 쉽게 해서 사용하게 하면 어떨까?   브랜드 좀 있다고 하는 향수들 너무 비싼 거 아님? 공급자의 입장에서는 개발에 들인 공이 있고, 대량 생산을 해야 하기 때문에.. 양을 적게 해서 팔기 어렵다.  언제 어떤 상황에 어울리는지에 대한 story line이 없다.. Phase III. 현실 세계를 둘러보기 시작하다.향수를 만드는 공장을 방문해 보았다. 공장은 한 번의 batch를 돌리기 위한 최소한의 물량이 필요하고.. 이 공장에서는 50ml 기준이라면 불량률 15% 정도를 고려해서 3,000병 정도가 최소한의 물량이라고 한다. 물론 더 적은 양을 만들어 줄 수 있으나.. 단가가 올라갈  수밖에 없다.그리고, bottle 뚜껑은 screw 타입으로 할 것인지, 아니면 clipping type으로 할 것인지?  라벨은 자동 라벨 기를 사용할 것인지? 분사 양은 어느 정도로 할 것인지 등등 현실의 문제가 다가오기 시작한다.Phase IV. 주변의 인물들에게 의견을 구해보기 시작하다.일단은 물어보기 시작한다. 와우 좋은데.. 될 것 같은  비즈니스야!라고 하는 사람부터 음.. 미안한데 난 안 쓸 것 같아!라고 하는 사람 등등 다양한 사람들이 존재한다. 흠.. 그렇다면 이것을 받아들이겠다고 한 사람들의 의견을 모아서 작은 시장에서 시작할 것인가? 아니면 모두가 만족하는 서비스로 계속해서 수정을 할 것인가?뭐가 되든.. 소비자를 push 할 수 는 없다. 좋은 제안을 주고.. 그것에 따라오는 고객이 있다면 그 고객들을 더욱 만족시킬 수 있는 방향으로 진화하는  수밖에..Phase V. "이건 안되지 않을 이유가 없어요"를 주의하라.새로운 서비스를 기획하는 사람의 입장에서는 대부분 밝은 면 만을 볼  수밖에 없다. 어느 정도의 의견은 귀에 들어오지만, 비판적인 의견에 대해서는 귀에서 튕겨내는 것이 특징이다. 그러던 중, 한 선배에게서 "내 서비스가 안되지 않을 이유가  없어요"라고 말하는 것 같이 들린다는 의견을 들었다. 현실의 망치로 뒤통수를 맞아봐야 정신을 차리는 법이다.#파펨 #스타트업 #창업가 #창업자 #마인드셋 #인사이트

Overview2년 전이었을까요. 엄마에게 스마트폰을 꺼내들어 그동안 만들었던 콘텐츠를 보여주었습니다. 아들이 이런 걸 만든다며 당당하게 말했지만, 제 콘텐츠를 처음 마주한 엄마는 인상을 찌푸리며 소리쳤습니다.“아이고, 안 보여!” 분명 제 눈엔 잘 보였는데 엄마는 미간을 찌푸려야 글씨가 보였던 겁니다. 그제서야 무언가 잘못됐다는 걸 느꼈습니다. 노이즈를 없애자!크리에이터는 콘텐츠를 제작해 자신의 생각과 경험을 독자에게 전합니다. 그것이 온전하게 전달되었을 때 독자는 콘텐츠를 보고 웃고, 공감하고, 감동을 받지요. 하지만 그렇지 않을 때는 가차 없이 ‘뒤로 가기’를 누를 겁니다. 독자가 온전히 콘텐츠를 즐기는 데에 방해되는 요소, 즉 노이즈를 미리 없애기만 해도 읽기 편한 콘텐츠가 될 수 있겠지요? 많은 노이즈가 있겠지만, 오늘은 가장 기본적이면서도 중요한 텍스트의 노이즈를 없애는 방법부터 살펴보겠습니다. 1.순서를 정하자! 어느 버튼이 보기 좋을까요대부분의 엘리베이터 버튼은 왼쪽의 형태를 갖추고 있습니다. 오른쪽 버튼처럼 되어 있다면 사람들은 버튼을 누르기 전에 어디를 눌러야 할지 망설일 겁니다. 예를 들어 6층을 가려고 했는데 5층 버튼 위에 보여야 할 6층 버튼이 바로 보이지 않았으니까요. 썸네일이 잘려 있는 건 다 이유가 있습니다. / 네이버 웹툰 제공앱 화면도 종종 우리의 행동을 유도합니다. 위의 앱 화면에서 썸네일이 잘려있을 경우, 우리는 자연스럽게 손가락을 움직입니다. 그러므로 콘텐츠 크리에이터는 독자가 순서대로, 편하게 읽을 수 있도록 시각적인 힌트를 콘텐츠 안에 심어야 합니다. 우리나라 사람들은 왼쪽에서 오른쪽으로 글을 읽는다두 문장 중 어디부터 읽으셨나요? 아마 왼쪽부터 읽었을 겁니다. 우리나라 사람들은 왼쪽부터 글을 읽는 것에 익숙하기 때문입니다. 아래에서 위로 글을 읽는 사람은 없습니다.그렇다면 이번엔 위쪽과 아래쪽 중 어느 문장을 먼저 읽으셨나요? 당연히 위쪽부터 읽었을 겁니다. 결국 독자는 글을 읽을 때 왼쪽에서 오른쪽 순으로, 위에서 아래 순으로 읽는다는 걸 알 수 있습니다. 왼쪽에서 오른쪽으로, 위에서 아래로앞의 두 결과를 합치면 이런 식의 배치가 가능합니다. 두 문장은 똑같지만 마치 왼쪽에 있는 문장이 먼저 말을 거는 것처럼 보이지 않나요? 왼쪽에 있는 사람이 먼저 말을 거는 것처럼 보인다.이번엔 응용해볼까요? 이미지에 대입하면 이런 형태로 제작할 수 있습니다. 독자도 별도의 설명 없이 순서대로 읽을 수 있고요.시선의 이동에 경우의 수를 두지 맙시다!등장하는 인물이 누구인지 나타내고 싶다면 왼쪽보다 오른쪽처럼 표현하는 게 더 좋을 겁니다. 독자가 자연스럽게 시선을 옮길 수 있기 때문에 콘텐츠를 편하게 볼 수 있습니다. 이처럼 크리에이터는 독자의 시선 이동에 경우의 수를 두지 말아야 합니다. 그렇지 않으면 콘텐츠에 몰입할 수 없습니다. 한 명이 반말만 해도 관계가 정의된다.상하의 관계를 표현하고 싶다면 한 명이 반말을 사용하는 것이 좋습니다. 굳이 설명하지 않아도 독자가 인물들의 관계를 알 수 있는 시각적 힌트입니다.2.불필요한 요소를 걷어내자!“맛있는 거 같아요.” “재밌는 거 같아요.” 뉴스에서 시민 인터뷰를 볼 때면 “~같아요”라는 표현을 자주 봅니다. 하지만 유추는 남의 감정이나, 확실하지 않은 현상을 말할 때나 사용하는 것입니다. 자기 자신의 감정을 유추하는 건 분명 잘못된 표현이죠. “그녀의 마음이 진짜 아플 거 같아요.” (O) “그 태풍은 굉장히 위험할 거 같아요.” (O) “영화가 재미있었던 거 같아요.” (X) -> “영화가 재미있었어요.” 문장에서 없어도 되는 것들은 과감하게 지웁시다. 정확한 표현을 써야 전하고 싶은 내용을 충분히 전달할 수 있으니까요. 불필요한 요소를 없애면 독자가 읽기도 쉬울 겁니다. 콘텐츠 크리에이터는 반드시 독자의 시선을 배려해야 한다는 사실을 잊어선 안 됩니다. 3.강조하자!‘이것만큼은 독자에게 꼭 전달하겠다!’하는 것이 있다면 우주가 나서서 도와주길 기다리지 마세요. 색, 서체, 크기, 굵기 등을 활용하는 방법이 있습니다. 이 광고의 기획자는 어떤 걸 전하고 싶었을까?여러분은 위의 광고에서 어떤 것부터 보이시나요? (조정석 말고요.) 위의 광고를 만든 기획자는 죽었다 깨어나도 ‘종신보험’과 ‘생활자금’이란 단어를 전달하고 싶었을 겁니다. ‘종신보험에 가입하면 생활자금이 나온다’는 것이 광고의 핵심이었으니까요. 같은 문장이어도 표현 방식에 따라 다르게 읽힌다.맞습니다. “안녕”이란 간단한 문장도 어떻게 강조했는지에 따라 독자는 글을 다르게 읽습니다. 글씨가 작으면 작은 소리, 글씨가 크면 큰 소리로 읽힙니다. 만약 더 큰 소리를 표현하고 싶다면 느낌표를 왕창 늘려보는 것도 좋습니다. 이 가족이 행복해 보일까?하지만 강조하기는 꼭 필요한 경우에만 써야 효과가 있습니다. 가족과 놀이공원에 놀러가서 행복했던 이야기를 위의 문장처럼 표현한다면 사람들은 공포영화의 오프닝 멘트를 보는 기분이 들 겁니다. 눈이 아파요.색이 예쁘다는 이유만으로 여기저기에 남발하는 것도 마찬가지! 집중도 안 되고, 눈도 아픕니다. 저라면 아래의 이미처럼 표현했을 거예요.강조는 필요한 곳에만!Conclusion글, 이미지, 사진, 영상 등 콘텐츠를 표현하는 방법은 많지만 가장 기본인 글을 다루지 못하면 무용지물입니다. 크리에이터는 독자에게 재미를 선물해야 하는 사람입니다. 독자는 그들의 소중한 시간을 투자해 콘텐츠를 본다는 걸 잊지 마세요. 저는 오늘, 엄마에게 다시 한 번 제 콘텐츠를 보여드릴 겁니다.참고장근우, 「콘텐츠의 정석」, 예문아카이브(2017) 글장근우 대리 | People&Relations Managerjanggw@brandi.co.kr#브랜디 #기업문화 #조직문화 #업무환경 #인사이트 #경험공유 #콘텐츠

어제 문득 든 생각인데, 우리의 인생도 자연 현상과 많이 닮은 것 같다. 노를 저으면 물살을 가로지르며 나아간다. 왼팔, 오른팔 힘의 강도, 회전속도, 박자 비중에 따라 방향이 달라진다. 노를 놓으면 보트는 목적성을 잃은채 둥둥 떠다니며 정체 상태로 있는다.  하고자 하는 의지가 강하고 철저한 계획이 있다 하더라도 모두에게 공평하게 주어진 시간은 한정되어 있고, 체력 또한, 기존 체력 이상으로 무리할 수 없다.  능력도 마찬가지다. 지금 내가 갖고 있는 능력의 범위란 게 있다.    사업운영 하면서 겪은 시행착오는 결과적으론 경험이 되지만, 많은 기회비용 또한 발생한다.  경영학원론에서 생산성을 운운할 수 밖에 없는 이유가 여기에 있다. 누구나 다 알지만, 한번쯤 짚고 넘어가야 할 것들이 있는 것 같아 정리를 해보았다. DO 해야할 것 시간분배하기. 흘러가는 시간이 제일 아깝다.  사무실에서 8시간 기껏해야 오래앉으면 12시간이라 쳐도 그사이 전화응대하고 미팅하러 나가고 왔다갔다 오가는 시간도 있고 어떤 업무를 할 때 제일 시간낭비를 하는지 파악하고 그것을 최대한 자동화하면 좋다.  예를 들어,  고객들을 일일이 대응하는 시간이 오래걸릴 때에는 회사 전화 통화연결음을 ARS로 하는 것도 한 방법이다.   반복적인 업무는 루틴으로 짜기.  사실 나는 다이어리를 꼼꼼히 쓰는 편은 아니다.  대략적인 약속, 미팅은 TimeTree 라는 앱을 쓰고,  그날그날 해야할 업무목록은 GoogleDoc 에 적는다.  만약, 여러분의 경우 종이 다이어리에 꼼꼼히 오늘 할일, 일주일 할일을 적는 편이라면, 이제는 스마트폰에서 제공하는 일정앱 사용을 조심스럽게 권장한다.  요즘에 앱스토어나 구글 플레이스토어가면 무궁무진한 시간표, 일정관리 앱이 나와있다.  괜찮은 무료앱도 많고 거기에 1$언저리만 좀더 추가하면 꽤 오래 쓸만한 비서같은 앱도 있으니 한번 살펴보면 좋을 것 같다.  오전에 제일 하기싫은 일, 흥미없는 일부터 하기. 하기 싫은 일을 오전에 하는게 생산성을 제일 높여준다고 한다.반전이지 않은가.  굳이 아침에 할 필요 없다고 생각이 든다면,  다른 시간대를 고르면 된다.  가령, 점심먹고 직후 라던가,개개인차가 있겠지만, 본인이 생각하기에 제일 일잘되는 시간대가 최적의 시간대가 아닐까. Love what you do.  좋아하는 말 중의 하나.  지금 하고 있는 일이 본인이 정말 열정있게 하는 일이라고 생각하고 일하는 것.일생에서 이 일을 두번 다시 하지 못할 것처럼. 일단 시작해라.그냥 시작해라.  해야할 일은 산더미고 뭐부터 해야할지 모르겠다면, 일단 아무 일이나 시작해보자. 쉴땐 쉬어야 한다.정기적으로, 규칙적으로 쉬는게 중요하다.  장기휴가가 아닌 이상, 짧게는 몇분이더라도 휴식을 취하는게 좋다. 하루 업무시간중에서 몇시부터 몇시몇분까지는 10분 15분정도 휴식을 취하고 (나의 경우, 3시반에서 4시 사이) 다음 일을 보는 것을 권유한다.DONT 하지말아야할 것 계속되는 연속야근은 비추. 야근을 할 수 밖에 없는 상황이기에 집에 못들어가는 것은 대한민국 국민 누구나 안다. 하지만,야근을 하면 좋지 않은 이유는 그다음날, 분명히 업무에 지장이 간다.  피로는 누적되기 때문이다.  이 글을 읽으시는 분이 예비창업가이거나 스타트업이 대표라면, 야근권장은 비추하는 신문화를!  혼자서 모든것을 다하려고 하지말기.  내가 못하는 분야는 인정하고, 인지하고 전문작업자에게 아웃소싱, 외주를 주는게 비용으로나 시간절감으로나 훨씬 이득이다.   아니면 말단 직원에게 일을 주거나 원격사무보조해주는 프리랜서도 있다. 자잘한 일이나, 디자인, 영상 등 전문스킬을 요하는 작업은 맡기고, 여러분은 여러분 사업이나 업무에 있어서 더 중요한 일을 하는게 좋다.  멀티태스킹은 지양하기. 최적의 생산성을 위해선 시간대비 한가지 일에 몰두하고 하나 해치우고 그다음 일처리를 하는게 낫다. 모든 전화문의에 일일이 답변하지 말기.걸려오는 문의전화를 필터할 필요가 있다.  정말 도움이 필요한 건을 제외하고는, 본인이 직접 할 수 있는데 귀찮거나, 사이트 고객센터에 보면 답변이 나와있는데 굳이 전화로 묻는 경우가 상당하다.모든 전화에 친절히 일일이 대응할 필요는 없다.   개인 연락처를 알려주면 그다음부터는 회사전화가 아니라 개인폰으로 연락이 온다.   직급이 높거나 사장/대표라면 전화업무는 경영지원 담당자에게 넘기거나 위에서 말했듯 ARS전화연결음을 제작하거나 카카오톡 옐로아이디를 개설해서 카톡으로 상담을 받거나 고객센터 자주묻는질문 코너를 편리하게 할 필요가 있다.  현재 갖고있는 스킬에 안주하지말기. 타이핑 속도 늘리는 연습을 하는 것도 좋다. 타이핑 속도가 빠르면 보통 비례해서 가독력 속도도 빨라지는 편이니까.  사실, 타이핑은 한 예로 든거고, 뭐든지 항상 현재의 내 상태보다 더 나아지려고 노력하다보면 어느새 나의 업무 생산성은 이전보다 더 많은 양의 업무를 동일 시간대비 해치울 수 있을 것이다.  #넷뱅 #업무효율 #생산성 #인사이트 #성장 #조언

이제 외주이던 내부이던 팀도 구성했고 아이디어도 있다면 그 아이디어를 실현하는 단계에 들어섰다. 이 단계는 Prototype을 만드는 단계이다. 크게 Prototype은 크게 4단계로 나뉜다. Engineering Prototype, Design Prototype, Working Prototype, 그리고 마지막 단계인 Final Protoype for mass production으로 나뉠 수 있다. 일단 Prototype의 종류에 대해서 간단히  이야기해보겠다. Engineering Prototype은 말 그래도 Engineer가 기능 구현 위주로 만든 Prototype이다. 보통 회로 개발자가 실제 우리가 만들고자 하는 기능들을 회로를 구성해서 구현해보는 것이다. 요즘에는 이런 Engineering Prototype을 만드는 여러 모듈들이 나와서 노련한 회로 엔지니어가 아니라도 만들어 낼 수 있는 방법들이 있다. 대표적인 Tool이 아두이노이다. Engineering Prototype에서 검증할 수 있는 것은 '일단 우리가 이 제품의  이러이러한 기능을 만들 수 는 있겠네'라는 정도이다.이제 다음은 Design Prototype이다. 사실 개발의 순서는 보통 Engineering Prototype이 먼저이긴 하지만 Design Prototype이 먼저 시작해서 제품의 콘셉트를 먼저 잡고 회로 개발이 되는 경우도 있고 또는 동시에 진행하는 경우도 있다. 팀워크가 좋고 사전에 제품의 콘셉트에 대해서 팀 간의 논의가 잘 이루어졌다면 동시에 진행해도 무방할 것 같다. Design Prototype은 말 그대로 디자이너가 제품의 콘셉트를 외형으로 구현하는 것이다. 제품의 종류에 따라서 Design Prototype의 중요도가 달라진다. 특히 Wearable Device 같은 경우에는 제품의 사용성이 상당히 중요하기 때문에 Design Prototype 단계에서 제품의 사용성 검증이 상당히 중요한 Point이고 여기서 시행착오가 많이 발생한다. Desging Protoype은 최근에는 3D Printer 기술이 발전해서 3D Printer를 통해서 다양한 시도를 해볼 수 있다. 하지만 3D Printer로는 제품의 질감을 완벽하게 구현하는 것은 힘들기 때문에 일정 단계가 넘어가면 정식 목업을 만들어보는 것이 좋다.다음은 Working Prototype이다. 디자인도 완성되었고 회로도 어느 정도 완성되었다면 기구설계를 진행해서 실제 기능과 디자인을 결합한 Working Prototype을 만드는 단계로 넘어간다. Design Prototype 단계에서는 기능의 구현 없이 외형적인 사용성을 검증했다면 이 단계에서는 기능과 함께 실제 제품의 사용성을 검증해 볼 수 있는 단계이다. 이 단계에서도 3D Printer를 이용할 수 있다. 하지만 어느 정도 진행되면 3D Printer는 아직은 정교한 내부의 기구 설계를 반영하기 쉽지 않기 때문에 어느 정도 지나면 정식 목업을 만들어보는 게 좋다. 다음은 Prototype for mass production이다. 양산 검증을 위한 마지막 단계이다. Working Prototype 단계를 넘어서서 실제 제품의 단계로 넘어가야 한다.  Protype이라기보다는 샘플 제품이다. 금형 설계를 하고 금형을 통해서 내구성, 양산 품질 등을 검증해서 실제 샘플을 찍어보고 문제점을 잡아내는 것이다. 이 단계에서 설계 단계에서 생각하지 못했던 여러 가지 문제점들이  도출될 수 있다. 양산이 어려운 설계일 수도 있고, 양산이 되기는 하는데 금형비가 너무 높게 나오는 설계 일 수도 있고, 아니면 품질에 문제가 발생할 수도 있고 여러 가지 생각하지 못했던 문제점이 나올 수 있다. 이런 문제점들 잡아서 최종 양산까지 진행해야 한다. 이제 하드웨어 스타트업의 딜레마가 도출된다. 도대체 이 과정을 몇 번 반복해야 하는 건가? 그리고 돈은 얼마나 필요한가? 3D Printer로 외형을 만들면 몇 만원 단위이지만 정식 목업을 만들면 한 번 만드는데 몇 백만 원이 소요된다. 그리고 보통 목업은 전문 목업 제작업체를 통해서 제작을 하는데 기간도 빠르게 하면  1주이지만 보통 2주 많게는 3주가 걸릴 수 있다. 만들어보고 문제가 있어서 설계 수정해서 다시 목업 만들면 한 두 달은 금방 간다.  반복할수록 돈과 시간이 엄청나게 날아간다. 세계적인 혁신 제품을 만드는 Dyson은 먼지 통 없는 청소기를 만들 때 5000번의 시제품을 만들었다고 한다. 정말 후덜덜한 숫자이다. 특히 세상에 없던 제품을 만들 때는 시행착오가 정말 많다. Reference가 있으면 그대로 만들면 정말 쉽다. 스타트업은 본질적으로 돈이 없고 시간이 없다. 만약에 회로, 기구, 디자인 중에서 하나라도 외주를 주었다면 이 과정을 몇 번 반복하다가는 외주는 분명히 손들고 나갈 것이다. 하지만 시제품 단계에서 문제점을 검증하지 않고 양산에 들어가는 것은 더 큰 재앙이 되고 또 그 제품이 시장에 풀린다면 더 큰 재앙을  맛볼 수 있다. 금형 한번 제작하면 몇천만 원에서 많게는 억 단위의 투자가 필요하다. 시제품 단계에서 문제점을 잡지 못하고 금형을 제작하면 그 돈을 날릴 수 있고, 제품을 만들고 문제점이 나오면 양산된 제품을 모두 폐기해야 할 수도 있다. 결국 Prototype 단계를 얼마나 반복할 것인가는 이제 창업자의 몫이다. 양쪽의 Risk 사이에서 적절하게 끊어주어야 한다. 답은 없다. 창업은 원래 답이 없고 그 정답을 창업자가 스스로 찾아나가는 과정이기 때문이다. 다만 가급적 돈과 시간이 적게 소비하면서 Protytype 단계를 반복할 방법을 찾아서 Risk를 줄여나가는 방법이 최선이고 이게 경험 많고 노련한 팀을 구성해야 하는 이유이다.#NEOFECT #스타트업 #딜레마 #고민 #스타트업창업 #인사이트 #조언

지금까지 Linear Regression, Logistic Regression 모델을 만들어보았는데요. 우리가 만든 모델이 과연 잘 만들어진 모델이라고 볼 수 있을까요? 이를 알기 위해서 이번 4주차 수업에서는 우리가 만든 모델의 적합성을 보다 객관적으로 평가하기 위한 방법으로 교차 검증(Cross Validation)과 정규화(Regularization)를 배웠어요. 차례대로 하나씩 알아볼까요?1. Cross Validation교차 검증은 새로운 데이터셋에 대해 반응하는 모델의 성능을 추정하는 방법이에요. 학습된 모델이 새로운 데이터를 받아들였을 때 얼마나 예측이나 분류를 잘 수행하는지 그 성능을 알기 위해서는 이에 대한 추정 방식이 필요해요. 먼저 Whole population(모집단)에서 Y와 f를 구하기 위해 Training Set(모집단에서 나온 데이터셋)에서 f와 똑같지 않지만 비슷한 모델 f^를 만들어요. 그리고 이 모델을 모집단에서 나온 또 다른 데이터 셋인 Test Set을 이용하여 확인해요. 하지만 일반적으로 Test Set이 별도로 존재하는 경우가 많지 않기 때문에 Training Set을 2개의 데이터셋으로 나눠요. 이 Training Set에서 Training Set과 Test Set을 어떻게 나누느냐에 따라 모델의 성능이 달라질 수 있어요. 이런 테스트 방법을 교차 검증(Cross validation)이라고 해요.이번 시간에는 교차 검증 방법으로 LOOCV(Leave-One-Out Cross Validation)와 K-Fold Cross Validation을 알아봤어요. LOOCV(Leave-One-Out Cross Validation)LOOCV는 n 개의 데이터 샘플에서 한 개의 데이터 샘플을 test set으로 하고, 1개를 뺀 나머지 n-1 개를 training set으로 두고 모델을 검증하는 방식이에요.K-Fold Cross ValidationK-Fold CV는 n 개의 데이터를 랜덤하게 섞어 균등하게  k개의 그룹으로 나눠요. 한 개의 그룹이 test set이고 나머지 k-1개의 그룹들이 training set이 되어 k번을 반복하게 돼요. LOOCV도 n-fold CV로 볼 수 있어요!코드로 나타내기Step1. 데이터 생성 & train set과 test set  단순 분리# model selection modulefrom sklearn.model_selection import train_test_splitfrom sklearn.discriminant_analysis import LinearDiscriminantAnalysis# read datadf = pd.read_csv('data/data01_iris.csv')data = df.iloc[:,:-1].as_matrix()target = df['Species'].factorize()[0]LOOCV와 K-Fold CV에 사용할 데이터를 구하는 코드에요. data 파일 안의 data01.csv 파일을 읽어서 데이터 프레임 형태로 가져와요.df(데이터 프레임) 안에는 이와 같은 105개의 데이터 셋이 저장되어 있어요.df(데이터 프레임)의 Sepal.Length부터 Petal.Width의 값들을 매트릭스 형태로 data에 할당해요.Species에는 ‘setosa’, ‘versicolor’, ‘virginica’ 값들이 있는데요. factorize() 을 이용하여 setosa는 0, versicolor는 1, virginica는 2로 바꿔줘요.# random splitX_train, X_test, y_train, y_test = train_test_split(            data, target, test_size=0.4, random_state=0)X_train.shape, y_train.shapeX_test.shape, y_test.shape그다음에는 data와 target 데이터를 가지고 training set과 test set으로 6:4로 나눠요.X_train.shape = (90,4),  X_test.shape = (60, 4)가 돼요.# LDA f = LinearDiscriminantAnalysis() f.fit(X_train,y_train) y_train_hat = f.predict(X_train) table_count(y_train,y_train_hat) f.score(X_train,y_train)LDA(Linear discriminant analysis)는 대표적인 확률론적 생성 모형이에요. 즉 y의 클래스 값에 따른 x의 분포에 대한 정보를 먼저 알아낸 후, 베이즈 정리를 사용하여 주어진 x에 대한 y의 확률 분포를 찾아낸다고 해요.Step2. test set 준비(1) LOOCV으로 test set 준비# leave-one-out  from sklearn.model_selection import LeaveOneOutloo = LeaveOneOut()loo.get_n_splits(X_train)scv = []for train_idx, test_idx in loo.split(X_train):    print('Train: ',train_idx,'Test: ',test_idx)    f.fit(X_train[train_idx,:],y_train[train_idx])    s = f.score(X_train[test_idx,:],y_train[test_idx])    scv.append(s) get_n_splits() 함수를 사용하여 (90,4)의 shape을 가지는 X_train을 90개로 나눠요.test set에 0부터 89까지 하나씩 할당되고 할당된 숫자 외의 나머지 숫자들은 training set으로 모델을 검증해요. 위의 결과에서도 볼 수 있듯이 test set에 0이 할당되면 train set에는 1 ~ 89가 할당되어 모델을 검증하게 돼요!(2) K-fold CV로 test set 준비# K-fold CVfrom sklearn.model_selection import KFoldkf = KFold(5)kf.get_n_splits()scv = []for train_idx, test_idx in kf.split(X_train):    print('Train: ',train_idx,'Test: ',test_idx)    f.fit(X_train[train_idx,:],y_train[train_idx])    s = f.score(X_train[test_idx,:],y_train[test_idx])    scv.append(s) KFold(5) : 위에서 배운 k-fold 교차 검증에서 k를 5로 설정하여 우리가 가지고 있는 데이터 셋을 5개의 그룹으로 나눠서 교차 검증을 할 거예요.kf.get_n_splits()를 사용하여 5번 교차 검증할 것을 정해요.위에서 90개의 데이터셋을 5개의 그룹으로 나눴어요. 그리고 각 그룹 한 개씩 test set으로 정하고 나머지 그룹들은 training set으로 할당하고 모델을 검증해요. 예를 들어 그룹 1이 0~17, 그룹 2가 18 ~ 35, 그룹 3이 36~53, 그룹 4가 54~71, 그룹 5가 72~89라고 할 때, test set에 그룹 1을 할당하면 train set에는 그룹 2, 3, 4, 5가 할당되어 모델을 검증하게 돼요.Step3. 교차 검증 시행CV는 단순히 데이터 셋을 나누는 역할을 수행할 뿐이에요. 실제로 모형의 성능(편향 오차 및 분산)을 구하려면 이렇게 나누어진 데이터셋을 사용하여 평가를 반복해야 해요. 이 과정을 자동화하는 명령이 cross_val_score()이에요.# K-fold CVfrom sklearn.model_selection import cross_val_scoref = LinearDiscriminantAnalysis()s = cross_val_score(f,X_train,y_train,cv=3)cross_val_score(f, X_train, y_train, cv=3) : cross validation iterator cv를 이용하여 X_train, y_train을 분할하고 f에 넣어서 scoring metric을 구하는 과정을 반복해요.2. Regularization앞서 말한 우리의 목적은 우리의 데이터셋에 맞는 Y와 f를 구하는 것이었어요. f를 결정하기 위해서는 먼저 결정해야 하는 요소가 있어요. 아래 다섯 가지가 f를 결정하는 요소들이에요.- Model family : linear, neural 등 방법론 결정- Tuning parameter : 모델에 맞는 파라미터 조절 - Feature selection(특징 선택) : 많은 데이터 중 어떤 데이터를 쓸지 고르는 것 - Regularization(정규화)  - Dimension reduction(차원 축소)f를 결정하는 요소 중 Regularization(정규화)에 대해 알아볼게요!정규화 선형회귀 방법은 선형회귀 계수(weight)에 대한 제약 조건을 추가함으로써 모형이 과도하게 최적화되는 현상(과최적화, overfitting)을 막는 방법이에요. 모형이 과도하게 최적화되면 모형 계수의 크기도 과도하게 증가하는 경향이 나타나요. 따라서 정규화 방법에서 추가하는 제약 조건은 일반적으로 계수의 크기를 제한하는 방법이에요. 일반적으로 Ridge Regression, Lasso, Elastic Net 이 세 가지 방법이 사용돼요.Ridge Regression머신 러닝에서는 모델의 오차를 찾기 위해 보통 최소제곱법(Least squares fitting)을 이용하여 β를 최소화시켜요. 위의 RSS는 잔차제곱식으로 예측값과 실제 값 사이의 차이를 구하는 식이에요. 회귀분석의 계수 값을 RSS을 최소화하는 β값을 찾음으로써 구할 수 있어요.Ridge Regression은 최소제곱법에 가중치들의 제곱합을 최소화하는 것을 추가적인 제약 조건으로 갖는 방법이에요. λ는 기존의 제곱합과 추가적 제약 조건의 비중을 조절하기 위한 하이퍼 파라미터에요. λ가 크면 정규화 정도가 커지고 가중치의 값들이 작아져요. λ가 작아지면 정규화 정도가 작아지며 λ가 0이 되면 일반적인 선형 회귀 모형이 돼요.코드로는 아래와 같이 나타낼 수 있어요.from sklearn.linear_model import Ridgef = Ridge(alpha=0.5)f.fit(xtrain,ytrain)f.intercept_,f.coef_f.score(xtrain,ytrain)f.score(xtest,ytest)LassoLasso는 가중치의 절댓값의 합을 최소화하는 것을 추가적인 제약 조건으로 가져요. 아래와 같이 코드로 나타낼 수 있어요.from sklearn.linear_model import Lassof = Lasso(alpha=1.0)f.fit(xtrain,ytrain)f.intercept_,f.coef_f.score(xtrain,ytrain)f.score(xtest,ytest)Elastic NetElastic Net은 가중치의 절댓값의 합과 제곱합을 동시에 제약 조건으로 가지는 모형이에요. 코드로는 아래와 같아요.from sklearn.linear_model import ElasticNetf = ElasticNet(alpha=0.1,l1_ratio=0.5)f.fit(xtrain,ytrain) f.intercept_,f.coef_f.score(xtrain,ytrain)f.score(xtest,ytest)Lasso와 Ridge Regression의 차이점왼쪽 : Lasso, 오른쪽 Ridge Regression위의 두 그림은 Lasso와 Ridge Regression의  차이점을 잘 나타내는 그림이에요. 초록색 부분은 회귀계수(회귀분석에서 독립변수가 한 단위 변화함에 따라 종속변수에 미치는 영향력 크기)가 가질 수 있는 영역이고 빨간색 원은 RSS가 같은 지점을 연결한 것을 보여주는 것으로 가운데로 갈수록 오차가 작아져요.Lasso와 Ridge Regression 모두 RSS를 희생하여 계수를 축소하는 방법이라는 공통점이 있어요.하지만 Ridge Regression과 Lasso의 가장 큰 차이점은 Ridge 회귀는 계수를 축소하되 0에 가까운 수로 축소하는 반면, Lasso는 계수를 완전히 0으로 축소화한다는 점이에요.Cross validation(교차 검증)과 Regularization(정규화)에 대해 알아보았는데요. 간단히 요약해 볼게요.Cross validation(교차 검증)은 머신러닝 모델의 타당성을 검증하는 방법 중의 하나로, 특정 데이터를 training set과 test set으로 분할한 뒤 training set을 활용해 학습하고 test set으로 테스트하여 학습의 타당성을 검증하는 방법이에요. 교차 검증에는 여러 가지 방법이 있는데 그중에서도 우리는 LOOCV와 K-Fold CV를 배웠어요.Regularization(정규화)는 모델의 일반화 오류를 줄여 과적합을 방지하는 방법을 말해요. 일반적으로 Ridge Regression, Lasso, Elastic Net 이 세 가지 방법을 사용해요.이상적인 머신러닝 모델을 만들기 위해 고려해야 할 점들은 정말 많은 것 같아요. 우리가 만든 모델이 적합한 모델인지 이번 수업시간에 배운 교차 검증과 정규화를 통해 잘 살펴봐요!* 이 글은 AI스쿨 - 인공지능 R&D 실무자 양성과정 4주차 수업에 대하여 수강생 최유진님이 작성하신 수업 후기입니다.

안녕하세요. 스포카 프로그래머 박종규입니다. 이번 시간에는 스포카에서 쓰고있는 클라이언트 측 오픈소스와 그 오픈소스가 어떠한 라이센스가 적용이 되었는지 알아 보겠습니다.오픈소스(Open Source)먼저 간략하게 오픈소스의 정의에 대해서 짚어가도록 하겠습니다. 오픈소스는 소스코드를 외부에 공개하여 누구든지 제한없이 소프트웨어를 쓰고 소스코드를 볼 수 있는 소프트웨어를 말합니다. 통상적으로 오픈소스 소프트웨어를 오픈소스라고 부르기도 합니다. 대표적인 오픈소스로는 우리가 많이 쓰는 안드로이드OS와 크로미움 브라우저를 볼 수 있죠.프로젝트에 오픈소스를 적용?그렇다면 오픈소스의 정의도 알았고 제한없이 쓸 수도 있다고 하고 이렇게 많은 장점이 있는 오픈소스를 우리회사 프로젝트에 한 번 도입해볼까?라는 생각을 가지신 분들이 있겠지만 잠시만 기다려 주시길 바랍니다. 이러한 오픈소스는 오픈소스 라이센스라는 일종의 저작권이 적용이 되어 있어서 그 라이센스를 준수 해야합니다.오픈소스 라이센스(Open Source License)오픈소스 라이센스의 정의를 간략하게 보면오픈소스 라이센스는 오픈소스SW 개발자와 이용자간에 사용 방법 및 조건의 범위를 명시한 계약을 말한다. 따라서 오픈소스SW를 이용하기 위해서는 오픈소스SW 개발자가 만들어놓은 사용 방법 및 조건의 범위에 따라 해당 SW를 사용해야 하며, 이를 위반할 경우에는 라이선스를 위반함과 동시에 저작권 침해로 인해서 이에 대한 처벌을 받게 된다.라고 나와 있습니다. 즉 오픈소스이긴 하지만 오픈소스에 적용된 라이센스를 준수하지 않는다면 법적인 처벌을 받는다는 거죠. 그렇기 때문에 프로젝트에 오픈소스를 적용하려면 제일 먼저 라이센스를 확인해야 합니다.스포카 클라이언트에서는 어떠한 오픈소스를 쓰고 있을까?현재 스포카의 클라이언트측에서 사용하고 있는 오픈소스는 다음과 같습니다.jQueryLESSBackbone.jsD3.jsDataTables.js그럼 간략하게 이 오픈소스가 어떠한 역할을 하는지 간략하게 알아보겠습니다.jQueryjQuery(제이쿼리)는 브라우저 호환성이 있는 HTML 속 자바스크립트 라이브러리이며 클라이언트 사이드 스크립트 언어를 단순화 할 수 있도록 설계되었습니다. 즉 자바스크립트를 좀 더 편하게 쓸 수 있도록 개발된 라이브러리이죠.LESSLESS는 css를 동적으로 쓸 수 있게 해주는 자바스크립트 라이브러리 입니다. 기존 css에서 제공하지 않는 변수 및 연산식을 제공하기 때문에 코드를 재사용 할 수 있을 뿐만 아니라 개발시 소요되는 시간을 줄여줍니다. *.less로 개발된 코드는 less 컴파일러를 통해 *.css로 변환이 되어 클라이언트 페이지에 적용됩니다.Backbone.jsBackbone.js는 자바스크립트를 MVC 패턴으로 개발할 수 있게 도와주는 자바스크립트 라이브러리입니다.D3.jsD3.js는 데이터를 우리가 쉽게 볼 수있게 다양한 차트, 표, 그림으로 표현 할 수 있도록 기능을 제공해주는 자바스크립트 라이브러리입니다.DataTables.jsDataTables.js는 table를 만들어주는 기능을 제공하는 자바스크립트 라이브러리입니다.그렇다면 위 오픈소스에는 어떠한 라이센스가 적용되어 있을까?위의 오픈소스에 적용되어 있는 라이센스를 살펴보면jQuery : MIT, GPLv2LESS : apache license 2Backbone.js : MITD3.js : BSDDataTables.js : BSD, GPLv2같은 라이센스가 적용이 되어 있습니다. 그럼 하나씩 살펴보도록 하죠.듀얼라이센스먼저 jQuery와 DataTables.js에는 다른 오픈소스와 다르게 라이센스가 두개가 적용이 되어 있는 것을 볼 수 있습니다.이것을 흔히 듀얼라이센스라고 하는데 이 라이센스는 오픈소스를 쓰는 사용자가 두개의 라이센스중에서 하나를 선택해서 쓸 수 있는 라이센스입니다. 예를 들면 jQuery를 쓰는 사용자는 GPL 라이센스를 적용을 할 수도 있고 MIT 라이센스를 적용해서 쓸 수 있다는 뜻이죠.GPL 라이센스jQuery와 DataTables.js에 적용되있는 GPL라이센스에 대해서 알아 보겠습니다. GPL라이센스는 오픈소스에 가장 많이 적용된 라이센스 중에 하나입니다. 이 라이센스는 자유소프트웨어재단에서 만든 라이센스로 이 라이센스를 가진 오픈소스를 이용하여 응용 프로그램을 개발하는 경우에는 GPL라이센스가 적용이 됩니다. 그리고 GPL라이센스는 3가지의 버전이 있습니다.GPLv1GPL의 버전 1은 1989년 1월에 발표되었다(GPLv1 전문). 이것은 자유 소프트웨어에서의 두 가지 중요한 자유를 보장해 주었는데, 하나는 프로그램의 소스코드를 공개하지 않은 채 바이너리 파일만 배포하는 것을 막는 경우로 이것을 막기 위해 GPLv1에는 프로그램을 GPLv1로 배포할 때는 사람이 이해하기 쉬운 소스 코드를 같이 배포해야 한다는 조건이 들어갔다. 두 번째 문제는 프로그램에 추가적인 제약을 걸 가능성이 있다는 점이었고, 이를 막기 위해 GPLv1 프로그램을 수정한 프로그램은 원래 프로그램과 마찬가지로 GPLv1을 따라야 한다는 조건이 들어갔다.GPLv2자유 소프트웨어 재단(OSF)에서 만든 자유 소프트웨어 라이선스다. 미국의 리처드 스톨만(Richard Stallman)이 GNU-프로젝트로 배포된 프로그램의 라이선스로 사용하기 위해 작성했다. ‘① 컴퓨터 프로그램을 어떤 목적으로든지 사용할 수 있다 ② 컴퓨터 프로그램의 복사를 언제나 프로그램의 코드와 함께 판매 또는 무료로 배포할 수 있다 ③ 컴퓨터 프로그램의 코드를 용도에 따라 결정할 수 있다 ④ 변경된 컴퓨터 프로그램 역시 프로그램의 코드와 함께 자유로이 배포할 수 있다’라는 네 가지 조항을 명시하고 있다. 대부분의 소프트웨어에 대한 라이선스는 소프트웨어를 공유하거나 수정할 수 있는 자유를 금지하기 위 고안되었다. 반면에 GNU 일반 공중 라이선스는 자유 소프트웨어를 공유하고 수정할 수 있는 자유를 보장하기 위해 의도되었다. 즉, 소프트웨어가 사용자 모두에게 자유롭게 이용될 수 있도록 하는 것이다. 이 일반 공중 라이선스는 자유 소프트웨어 재단의 소프트웨어 대부분을 비롯하여, 저작자가 이 라이선스의 사용을 지정한 기타 모든 프로그램에 적용된다. (자유 소프트웨어 재단의 소프트웨어 중 일부는 이 라이선스 대신 GNU 라이브러리 일반 공중 라이선스가 적용된다.) 누구나 자신의 프로그램에 이 라이선스를 적용시킬 수 있다.GPLv3자유 소프트웨어 재단(FSF)과 이 재단의 GNU 프로젝트에 의해 배포되며 GNU 소프트웨어에 적용되는 공개 소프트웨어의 대표적인 라이선스 체계. GNU GPL이라고도 하며, 저작권(COPYRIGHT)의 반대라는 의미로 카피레프트(COPYLEFT)라고도 한다. 라이선스 사용료나 사용상의 제약 조건을 자유롭게 하여 소프트웨어 유통을 활성화하기 위한 의도에서 출발한 것으로 GNU 소프트웨어로 공개되는 원시 부호는 누구나 변경 또는 일반 공중 라이선스(GPL)로 재배포하고, 이를 이용하여 상업적 웹 사이트를 구축할 수도 있다. 그렇다고 저작권의 완전한 포기를 의미하는 것은 아니어서 GPL의 기본 원칙과 공개하는 측이 정의한 바를 충실하게 따르도록 되어 있다. 1990년대에 마련된 GPL V2.0에 이어 2005년에 V3.0이 발표되었다. GPL 버전 3은 2007년 6월 29일에 발표되었다. 2005년 후반에 자유 소프트웨어 재단에서 GPL의 세번째 판을 개발할 것이라고 발표했다. 바뀐 점 중에서 가장 중요한 4가지를 말하자면, 소프트웨어 특허에 대처하는 것, 다른 라이선스와의 호환성, 어떤 부분의 원시 코드와 무엇이 GPL이 포함되어야 하는 원시 코드를 구성하는지와 디지털 제한 관리(DIGITAL RESTRICTIONS MANAGEMENT)에 신경을 썼다.※참고GPL 라이센스가 적용된 오픈소스를 사용했다고 무조건 소스코드를 공개해야 하는 것은 아닙니다. 예를 들면 MySQL db를 이용하여 웹서비스를 개발해서 직접 서비스만 운영하는 경우 이것은 다른 곳에 배포하는 것이 아니므로 GPL 라이센스 의무사항이 적용되지 않습니다. 하지만 다른 곳에 제공하거나 파는 경우(쇼핑몰을 제작해서 파는 경우)에는 배포하는 것이 되므로 GPL라이센스가 적용이 됩니다. 따라서 이런 경우에는 상용라이센스를 구매해서 써야 합니다.MySQL에서 정의한 배포하는 대표적인 예는 다음과 같습니다.MySQL을 포함하고 있는 소프트웨어를 고객에게 팔아 그 소프트웨어를 고객이 소유한 장비에 설치하는 경우고객이 소유한 장비에 기본적으로 MySQL을 설치해야하는 소프트웨어를 파는 경우MySQL을 포함하고 있는 하드웨어 시스템을 고객에게 팔아서 고객이 있는 곳에 설치하는 경우MIT 라이센스MIT 라이센스는 MIT 공과대학교에서 학교 학생들의 소프트웨어 학습을 돕기 위해서 개발한 허가서입니다. 이 라이센스는 강력한 조항이 없어서 MIT 라이센스가 적용된 오픈소스를 이용하여 응용 프로그램을 개발할 시에 응용 프로그램을 오픈소스로 해야할 필요도 없고 소스코드를 공개할 의무가 없습니다. 또 상업적인 제한도 없습니다. 다만 응용 프로그램에 MIT 라이센스라고 표시와 라이센스 사본을 첨부만 해주면 됩니다.BSD 라이센스버클리의 캘리포니아 대학에서 배포하는 공개 소프트웨어의 라이선스입니다. BSD 라이센스는 자유소프트웨어 자작권의 하나로 BSD 계열 소프트웨어를 포함한 많은 프로그램에서 사용하고 있습니다. 이 라이센스는 라이센스라고 할 수 없을 만큼 미약해서 아무나 수정하고 배포하고 소스코드를 공개해야 할 의무가 없습니다. MIT 라이센스와 마찬가지로 라이센스 표시만 해주면 됩니다.Apach license 2아파치 라이센스는 아파치 소프트웨어 재단에서 만든 라이센스입니다. 이 라이센스 또한 MIT,BSD와 마찬가지로 소스코드 공개의 의무는 발생하지 않습니다. 하지만 “Apache”라는 이름에 대한 상표권을 침해하지 않아야 한다는 조항이 있어서 BSD라이센스보다 법적으로 완결된 내용을 담고 있습니다. 라이센스의 표시와 아파치 소프트웨어 재단에 개발된 소프트웨어라는 것을 밝혀야 합니다.참고한국저작권위원회위키백과KLDPwikiGNU공개SW포털MySQL KOREAKLDP 오픈소스라이센스가이드오픈소스 라이센스 비교표#스포카 #운영 #개발 #오픈소스 #개발자 #개발팀 #꿀팁 #인사이트 #조언

안녕하세요. 프론트엔드 bk입니다.자존감이 폭발하는 요즘. 제 자신이 뿌듯하여 이 기분을 오래 간직하고 싶어 쓰는 글입니다. 물론 react native 설치법, 꿀팁 같은 건 없고(react native 경력 2개월) 제가 느꼈던 react native 장단점과 크몽에서 새롭게 선보인 단기 알바 매칭 앱 SOON react native 개발기에 대해 겸손히 적어보려 합니다.어떻게 React Native로 개발하게 되었는가우선 별 볼 일 없는 저를 소개하자면 개발 경력 3년 반 쯤 넘고 React 2년 6개월, Vue 9개월 정도를 프론트 메인 라이브러리로 사용했습니다. 그 동안 훌륭한 분들과 함께 개발을 해왔고, 현재 크몽에 입사한 지는 10개월쯤 되었네요,개발자라면 react native (이하 RN)에 대해선 한 번쯤 들어보셨을 겁니다. 저도 2년 전쯤 처음 들어봤는데요 그때는 네이티브 앱에 비해 느리다, 성능을 못 따라간다, 역시 네이티브!라는 말이 많아서 아 그런가 보다 하고 웹 개발에만 집중했었죠. 그렇게 2018년 9월, 열심히 휴게실에서 크몽의 Vuejs 구조를 잡던 중에 저희 크몽 CTO(a.k.a 크알)가 크몽에서 신규 플랫폼 단기 알바 앱을 기획 중인데, 빠르게 시장 반응을 확인하고, 개발 리소스를 최소화하기 위해 RN로 개발하면 어떨까 하고 React를 경험했던 저에게 권유하셨습니다. 무덤덤한 척했지만 사실 기분 째 질 뻔했습니다. 누군가에게 필요로 하는 사람이 된다는 건 기분 좋은 일이니까요.그렇게 약 1주일간 RN을 필사적으로 공부하여 10월 초부터 본격적인 SOON 폭풍 개발을 시작했습니다. 기본적인 개발 스택은 python + RN + mobx 조합으로 구축되었습니다. (백엔드분 들도 python으로 처음 도입!) 여러 레퍼런스들을 보며 나만의 best practice를 찾아갔고 mobx와의 조합도 훌륭했습니다. react는 익숙하지만 처음 앱 개발을 하는 터라 수많은 시행착오를 겪어야 했죠. 그만큼 새로운 경험도 엄청나게 했습니다. RN 개발자가 당연히? 저 혼자 였기 때문에 누구에게 물어볼 수 도 없었고 그냥 헤딩하며 하나하나 알아갔던것 같네요 ㅎㅎ..... 불과 얼마 전까지도 초창기에 (1달 전..) 짰던 코드를 보고 한숨을 깊게 쉬고 리팩터링을 한 것 수두룩합니다. 그 사이 실력이 늘어났나 보다!라고 열심히 행복 회로를 돌렸죠.RN... 정말 할만할까?정말 할만합니다. 우선 RN은 웹 개발자 (초급 이상의 javascript를 이용한다는 전제하에)라면 10초도 안 걸려 hello world를 띄울 수 있을 만큼 쉽게 만들어져 있습니다.요즘은 expo라는 툴 덕분에 안 그래도 쉽게 개발할 수 있게 만들어진 RN을 더더 더욱 쉽게 접할 수 있게 되어있습니다.hello world기본적으로 RN은 React 기반으로 되어있기에 나는 React를 못써~ 나는 vue or angular 밖에 안 해봤어~라고 하더라도 충분히 빠르게 배울 수 있으리라 생각합니다. React나 vue나 거기서 거기 (위험한 발언이지만 둘 다 상용서비스로 사용해본 입장에선 하나 배우면 다른 라이브러리를 배우는 시간은 처음 배울 때 대비하여 절반도 안 걸렸던 것 같네요)앱 개발이라고 안 하기 보기보단 일단 hello world만 찍어보면 와 재밌다~ 하고 이것저것 더 해보는 자신의 모습을 볼 수 있을 겁니다. 앱 개발을 위해서 RN을 해본다기보다 React를 아주 재미있게 배울 수 있는 도구로서도 훌륭합니다. 그냥 지루하게 docs 보면서 하는 것보단 전혀 새로운 분야를 배우면서 자연스레 React도 배울 수 있습니다. Facebook에서 React를 내세우며 앱 개발 RN도 할 수 있다! 의 기술력 과시가 아니라 RN은 정말 쓸만했습니다.뭘 선택해도 훌륭한 선택. 하지만 난 react와 vueRN의 미친 장점첫 번째는 ios, android 동시 개발하나의 코드로 ios, android가 만들어집니다. 여기서 한술 더 떠 view 부분을 html, css로 변환 후 몇몇 로직들만 수정하면 web으로 그대로 가져올 수 있습니다. 반대로 react로 만들어진 web 기반 서비스를 react native로 변환도 가능합니다. RN이 접근한 Learn once, write anywhere가 뭔가 멋있었죠. (95% 정도는 사실이고 5%의 코드는 ios, android를 나누어 개발합니다 ㅜㅜ)두 번째는 미친 수준의 개발 속도딱히 RN만의 장점은 아니지만.. React는 live-reload(코드가 변경되면 자동으로 새로 고침)와 hot-reload(코드가 변경되면 변경된 딱 그 부분만 렌더링)를 지원합니다. 그 어떤 복잡한 설정 없이 도요. 일단 RN은 compile, build 과정이라는 게 없다고 봐도 되기 때문에(속도 면에서) 굳이 live, hot reload가 없이도 빠른 개발이 가능합니다. 하지만 저 두 놈이 있기에 코드를 수정하면 그 화면을 직접 보는 데까지 오버 좀 섞으면 1초도 채 안 걸립니다. 사실 1~5초 걸림QA 시에도 변경사항을 바로 확인할 수 있습니다. 디자이너, 기획자와의 피드백을 빠르게 반영할 수 있어 UX/UI를 잡는데 아주 효과적입니다. 상상보단 직접 보는 게 더 와 닿으니까요. expo환경에서 개발하고 있다면 가상 simulator가 없어도, xcode, android studio를 건들지 않아도 개발/배포하는 데 아무 지장이 없습니다.(SOON이 론칭되고 나서도 android studio는 아직 설치도 안 했습니다.) 이 정도만 해도 장점이 꽤 큰데 사실 진짜 장점은 다음입니다.마지막으로 OTA(실시간 배포) 기능입니다.정말 이것이 제일 미친 장점입니다. RN으로 만들어진 앱은 기능 추가, 버그 수정, 디자인이 바뀌어도 앱 배포를 위한 심사를 거치지 않습니다. 앱 실행 시 언제나 최신 javascript를 다운로드하고 실행하여 유저는 언제나 최신 상태의 앱을 경험할 수 있습니다. 물론 몇 가지 제한 사항이 있긴 합니다. (앱 아이콘이 바뀌거나 앱과 관련된 config가 바뀔 시엔 심사 필요) 언제나 덤벙대고 맨날 까먹는 저는 정말 유용하게 쓰는 기능입니다. 항상 노트북을 가지고 다니기 때문에 뭔가 오류가 생기면 아 이 부분 예외처리 깜빡했네? 수정하고 publish만 하면 끝이라 오류에 대한 심리적인 부담감이 엄청나게 줄었습니다.당연히 단점도 존재합니다.RN은 성능이 아무래도 딸린다던데...native 코드로 변환작업이 필수 ㅜㅜ태생이 네이티브가 아니라 생기는 해결하기 힘든(불가?) 단점이 있습니다. 저도 이 얘기를 수도 없이 들었습니다. 하이브리드 앱, 웹앱 등이 태생이 Swift와 Java 등의 Native를 따라갈 수 있을 리 만무했죠. RN이 세상에 나오고서도 하브, 웹앱보다는 빠르지만 네이티브와 비교하기엔 민망했다고 합니다. (사실 잘 모름) 그 이후에 주기적으로 성능 향상과 효율성에 대한 업데이트가 있었다는 정도..?  성능에 대해선 딱 이 정도의 정보만 알고 있었고 SOON을 만들기 시작했습니다. 당연히 SOON에는 많은 기능이 담겨있진 않았고 오류 투성이었지만 성능에 대해선 한 번도 이슈가 된 적은 없었습니다. 물론 기능이 계속 추가되고 규모가 커지다 보면 성능이 느려집니다. ms로 비교하여 테스트하지 않는 이상 유의미한 결과라고 생각되진 않았습니다.SOON의 핵심가치는 '빠르고 간편하게 단기 알바를 매칭 시켜준다'입니다. 이것저것 앱의 몸집이 아주 크게 늘어날 것 같지 않다고 판단했고, RN이 가장 최적이라 생각했습니다.(@CTO) 객관적으로 보면 아무리 RN이 나르고 긴다한들.. 성능적으로 보면 네이티브에 대적할 수 없을 것입니다. 하지만 언어를 고르고 서비스를 생각한다기보다 서비스 성격에 맞게 언어를 선택하는 것이 옳다고 생각합니다. 언어는 도구일 뿐이니까요.(참고자료 RN, swift의 성능 테스트)아무래도 javascript와 react에 대해 좀 친해야..RN이 아무리 쉽게 앱 개발을 할 수 있다지만, javascript와 React에 대해 조금(꽤 적당히 많이) 알아야 초기 진입 장벽이 많이 낮아질 것입니다. 이 두 가지를 잘 모르는 상태로 무턱대고 RN을 시작하면, RN보다 javascript, React를 공부하다가 포기하는 경우가 많을 겁니다.사라지지 않는 네이티브에 대한 두려움전 네이티브 코드와 환경을 전혀 모릅니다. 앱 등록 시 인증서가 필요하다는 것도 처음 알았고, 정말 아무것도 몰랐습니다. 초기에 러닝 커브가 꽤나 있었죠. Swift, Java를 공부한 것은 아니지만, 앱 등록/배포는 어떻게 진행되는지 하나의 앱이 존재하는 생태계 등 전반적으로 공부했습니다. 아직도 네이티브 관련 에러가 터지면 앱 개발자 분들을 찾아갑니다. 그렇게 하나하나 배워가고 있죠. 아직은 제가 혼자 해결할 수 없는 부분이 있습니다. RN에 좀 더 적응하면, 기초 앱 개발 정도는 따라 할 수 있도록 공부해야 할 것 같습니다. 이러다 앱 개발로 전향할 지도..Hello World...어쨌든! 장단점이 너무 뚜렷합니다. 새로운 서비스를 론칭 준비 중이면, 내 서비스에 RN이 어울리는지 고민 후 적용하시면 됩니다. 단, 이미 개발된 Native App이 존재하는데, 장기적 관점으로만 RN을 다시 개발하는 것은 강력히 비추합니다. 아무리 RN 개발자가 앱을 만들고 해도 누적된 Native의 경험치를 따라잡긴 힘들거든요. 진짜 어쨌든!앱 개발 관심도 있고, Native를 배울 엄두가 없는 분들.일단 Hello World 만 띄워보세요.아주 아주 재밌습니다.   앞으로 얼마나 더 RN을 하게 될지는 모르겠지만 웹 개발만 하던 제가 할 수 있는 영역이 굉장히 크게 늘어났다는 걸 느낍니다. 그래서 말인데.. 어떻게.. 내년 연봉협상에 반영이 될까요?#크몽 #개발자 #개발팀 #React #기술스택 #도입후기 #인사이트 #경험공유

[라이더소개 #13. 나무처럼 우직하고 깊은 '나무여행 전문가', 헉]헉을 소개합니다! :)Q. 헉의 간단한 자기소개 부탁해얼마 전부터 나무 관련 사진전도 시작했듯이, 나는 ‘나무여행 전문가’라고 불렸으면 좋겠어. 대학로와 우리가 자주 다니는 북촌에 나름대로의 코스를 준비하고 있어. 인력거를 타러 오듯이, 나한테는 워킹투어를 통해서 나무에 대한 이야기를 들으러 오는 거지. 그런 프로그램을 마련해서 가이드도 하고 ‘나무여행 전문가’로 불려지는. 앞으로의 내 모습은 그렇게 비춰졌으면 좋겠어. 아직 구체적으로 개시를 한 건 아니지만, 조만간 시작하지 않을까 싶어.생각보다 이야기할게 많아. 최소 1시간 이상, 2시간까지 충분히 가능해.Q. 대학로와 북촌은 '나무' 때문에 좋아하는 거야?그것도 이유 중에 일부분일 수 있는데, 일단 지리적으로 가까우니까! 내가 성균관대 명륜동에 살잖아. 그래서 어디로든 나오기가 쉽거든. 지리적인 이점이지. 산책할 때는 북촌이 주 무대가 되지. 인사동, 북촌, 대학로. 사진기 들고 돌아다니면서 나무나, 일상사진 찍으면 심심하지도 않고 좋아.Q. 아띠를 시작하게 된 계기가 뭐야?방금 이야기했듯이, 잘 돌아다니다 보니까 언젠가부터 인력거가 눈에 띄더라고. 지금은 우리가 파란색으로 통일을 했지만, 초창기 그 때는 노란색이었거든. 지금 ‘롭스’가 생긴 그 곳에 노란색 인력거가 서있더라고. 내가 기억하는 이미지는 그때 거기 서있던 그 느낌이야. 항상 ‘안녕하세요!’하면서(웃음), 행복해하면서 라이딩을 하는구나. 북촌도 잘 알고, 자전거 타는 걸 좋아하니까 나도 한 번 해보면 좋겠다 싶어서 시작한 거지.Q. 처음 시작했을 때와 2년 가까이가 지난 지금과 비교해보면 어때?한결같이 드는 생각은 부담감이 조금 있다는 거야. 아무래도 연령차이가 나니까, 솔직히 불편한 점이 있어. 물리적으로 연령 차이가 많이 난다는 것에 대해. 어떻게 생각하면 아무것도 아닐 수가 있지만, 아띠인력거 자체가 되게 ‘젊은 이미지’잖아. 밖에서 보이는 이미지도 그렇고. 실제로도 젊은 친구들이 많이 하고. 그렇게 보면 나는 그런 기준에서 살짝 비켜나있는 사람이거든.솔직히 그런 부분에서 중간 중간에 띄엄띄엄 못나오거나 그런 이유가 있었지. 포레스트나 연령대가 비슷한 친구가 없으면, 내가 혼자 남은 느낌이잖아. 근데 그건 어쩔 수 없는 부분인 것 같아. 서로가 이해해주는 부분인 것 같아.내가 조금 더 젊었다면 더 좋았을 것 같아. 더 잘 어울리고, 더 많이 함께하고. 아무튼 아띠가 가진 문화, 젊게 지내려고 하는 것 그런 건 다 좋아. Q. 가장 힘들 때도 그런 느낌을 받을 때겠네. 그렇지. 처음에 할 때는 인력거와 내가 한 몸이 안 되서 그랬는지 무릎 관절도 아프고 그랬거든. 완전히 적응이 안 된 상태에서 긴장도 한 대다가, 요령도 없어서 그런 것 같아. 힘들었었는데 요즘은 그런 느낌은 없더라고.그리고 무슨 이유에서건 만약 한 번 못나오잖아? 그럼 다시 나오기가 되게 힘들어. ‘오늘 못 나갔으니까 내일 나가야지’ 이게 잘 안 돼. 그게 일주일, 한 달 그렇게 되면 페이스도 떨어지고, 다시 나갈 용기를 내는 것도 힘들지.Q. 기억에 남는 손님이 있다면?시골에서 어떤 할머니가 아들을 찾는다고 올라왔는데, 주소도 모르고 아무 것도 모르시는 거야. 내가 그때 창경궁 언덕길 따라서 북촌으로 가던 중이었는데, 가던 길 마다하고 그 할머니 태워가지고 종묘 옆까지 데려다드렸었어. 할머니가 해주시는 말만, 설명만 듣고 재조합해서 아들이 하는 가게에 데려다드렸지. 그 때 주셨던 믹스커피. 그런 게 되게 좋았어.또 마포노인복지관인가 거기에서 단체 라이딩을 한 적이 있었는데, 그때 할머니들이 굉장히 좋아해주셨어. 우리 모든 라이더들을 손자 보듯이 대해주시고 ‘내가 이런 걸 다 해보네!’ 하시면서.그리고 작년 늦가을 쯤, 저녁에 복귀하고 있었는데 한 여성분이 너무나 간절하게 태워달라고 하셔서 태워드렸어. 라이딩을 하면서 자연스럽게 이야기를 하는데 아버지에게 학대당했던 얘기를 하시더라고. 계속 라이딩만 한 건 아니고, 빵하고 커피 사서 삼청동쯤에서 같이 이야기도 했거든. 그 친구는 그런 순간과 시간이 되게 필요했었나봐. 그런 분위기 전환. 되게 좋았다고 하더라고. 내가 전문적으로 상담을 해주는 사람도 아니고, 사실 내가 도와줄 여력도 별로 없는 거잖아. 그럼에도 이런 걸 통해서 같이 뭔가를 공감 내지는 도움을 줄 수 있었다는 게 좋았지.Q. 헉이 생각하는 인력거의 매력은 뭐야?비슷한 의미인데, '소통‘인 것 같아. 우리가 전해주려는 서비스 같은 게 있잖아. 예를 들어서 그냥 라이딩 자체의 happiness 일수도 있고, 사람들이 많이 찾는 북촌과 서촌의 설명일 수도 있고. 보는 사람과 타는 사람, 모두가 서로 행복해지는 거. 거의 대부분 내릴 때 보면 좋아하시는 편이야. 다들 또 타러 오겠다고 하시고. 이런 지역을 더 잘 알게 돼서 좋았다고 하시고. 그런 행복, 소통, 교감 그런 것들이 인력거가 가진 매력이지.Q. 헉이 특히 좋아하는 길이 있어?인력거를 끌고서는 로맨스코스를 좋아해. 히스토리코스 창덕궁까지 가려면 너무 멀어(웃음). 그리고 이야깃거리 같은 것들이 내 기준에는 로맨스가 더 많더라고. 히스토리는 로맨스코스만큼 다양성을 주고, 사람하고 섞인다는 느낌은 덜한 것 같아.개인적으로 좋아하는 길은, -사실 다분히 나무가 있어서이긴 한데- 헌법재판소에서 나와서 골목으로 들어가는 길을 좋아하거든. 사람들이 생각보다 안다니기도하고, 지금 이 시기에는 백목련이 펴서 좋아. 그리고 중간쯤에 400년 된 진짜 멋진 향나무가 있어. 향나무가 정말 너무 예쁘게 자랐어. 사람들도 이 이야기를 해주면 되게 좋아하기도 하고.그리고 계동길이라고 있어. 그 길이 개인적으로 좋더라고. 옛날 동네 느낌이 많이 사라지긴 했지만, 여전히 철물점이나 미용실, 의상실, 밥집이 몇 개라도 남아있어. 사람들이 많이 찾다보니까 카페, 피자집 같은 새로운 것들이 있고. 거기 왜, 참기름집도 있잖아. 거기 지나갈 때 기름 짤 때 고소한 향이 바람 따라 퍼지는 그런 느낌도 좋고.북촌 한옥 마을에 전형적인 이미지 그런 것도 좋지만은, 오히려 나는 계동길을 올라가면서 실제 사람들이 생활하면서 찾을 수 있는 가게들을 보는 것도 좋더라고.아 또 하나 더하자면, 로맨스코스 돌면 동십자각에서 국립현대미술관 쪽으로 더 올라가면 ‘비술나무’ 세 그루가 있거든. 내 개인적인 생각으로는 코스를 바꾸더라도 그 곳은 꼭 설명해야하는 절대적인 포인트거든. 비술나무가 주는 상징성이 굉장히 커. 그곳이 중앙 청계천이었거든. 비술나무가 물가에서 잘 자는 나무야. 예전에 그 길에 흘렀던 개천은 사라졌지만 비술나무가 있어가지고, 그 지형을 보여주고 있는 거잖아. 코스 설명에 완전히 들어가야 되는 부분이라고 생각해. 그리고 국립현대미술관이 설립된 배경에 대해서도 설명해주어야 된다고 생각해.동십자각이 지금은 섬처럼 도로 중간에 있잖아. (헉 핸드폰 속 사진자료를 보여주며) 예전에는 이렇게 담장으로 이어져있고 그 옆은 개천이 있었어. 그 담장, 개천의 물가를 따라서 비술나무가 쫙 있었던 거고 지금도 있는 거지.Q. 와, 비술나무가 살아있는 역사네!그렇지. 내 입장에선 이걸 꼭 설명해주어야지. 코스 중 일부로 적극 반영이 됐으면 좋겠어!Q. 헉 사진찍는 건 언제부터 좋아했어?내가 나무를 좋아하고 잘 보러 다니고 그러다보니까, 나무 사진을 찍고 집에 와서 도감도 뒤져보고 나무 공부를 하고 그런 것들이 반복되니 자연스럽게 사진을 좋아하게 된 것 같아. 나무를 주제로 하는 사진을 찍게 됐고, 찍는 만큼 사진을 잘 찍게 됐고, 아직은 어설프지만 사진전도 하게 되었고. 그리고 2002년쯤 나무강좌를 수강하게 되었는데, 나무를 더 좋아하는 계기가 되고, 나무를 주제로 한 사진을 찍는 걸 좋아하게 된 것도 그때쯤이라고 볼 수 있지. Q. 헉이 생각하는 나무의 매력은 뭐야?아주 어렸을 때부터 자연, 생태, 꽃 그런 것들을 너무 좋아했어. 보는 것도 좋아했고, 초등학교 다닐 때는 교정에 버려진 화분이나 풀이나 꽃들이 있으면 불쌍하고 안타까워서 집에 오는 길에 가져와서 집 꽃밭에 심어주고 그랬었거든. 그런 감수성이 다른 사람보다는 풍부했던 것 같아. 어렸을 때는 시골이었으니까 집에 마당이 있잖아. 아버지가 그 마당을 온갖 나무들로 다 채웠었어. 그리고 화분에는 선인장, 철 따라 피는 온갖 꽃들. 수를 열거할 수 없을 정도로 많았어. 그 속에서 자라났지. 그리고 아까 이야기했듯이 나무강좌를 수강하고 정기적으로 모임도 가지면서, 그런 자연에 대한 관심이 나무로 집중되었지.대부분 사람들은 야생화나 꽃을 보는 정도에 아직은 머물러있거든. 이게 나무로 옮겨오는 게 좀 힘들어. 그리고 그러려고 하지도 않고. 그런데 나무의 세계는 훨씬 우직하고 깊어. 꽃을 보는 건 순간적인 기쁨이고 한 철이지만은, 나무는 일 년 사계절의 모습이 다 달라. 겨울에서 봄이 될 때 움이 트는 느낌, 연초록으로 물들 때의 느낌, 초록이 왕성하고 단풍이 들고 다시 겨울이 될 때의 느낌. 그리고 나무는 한 자리에 머무면서 자기 분수, 자기 만족을 아는 것 같아. 나무를 보면 그런 것들을 보고 느낄 수 있지. 또 이런 것들을 사진으로 표현해보는 재미가 있어.한 자리에서 몇백년을 족히 살아내는 나무들을 보면 보통 철학자가 아닌 거지. 움직일 수 없는 단점을 장점으로 승화시킨 것이라고 해야 될까.(웃음)만약 나무가 동물처럼 이동하고 사람처럼 욕심 부리고 그렇다면, 나무끼리도 서로 상처만 내고 오히려 제명에 못 살걸, 아마. 나무는 그냥 한 자리에서 욕심내지 않고 자기가 취할 것만 취하고, 자기 페이스대로만 가니까. 그런 건 확실히 나무가 가진 다른 점이기도 하고, 좋은 점이지. 사람들이 나무를 많이 알아줬으면 좋겠어. 역사 문화를 다 가지고 있으니까.Q. 아띠인력거란 헉에게 어떤 존재야?나를 더 젊게 해주는 것. 젊은 사람들이 주로 몰려 있기도 하고, 공유하는 문화 자체도 젊은 문화잖아. 그런 가운데 내가 활동을 하게 되니까 확실히 그런 것들은 있는 것 같아. 내가 젊어지는 느낌. 어느 순간 내가 이 사람들이랑 똑같은 라이더라는 느낌이 들 때, 나이를 떠나서 나도 함께 젊은 느낌을 공유하는구나! 그런 생각이 드니까, 아띠는 나를 젊게 해주지. 그리고 반말문화가 서로가 다가가기 쉽게 만드는 연결고리가 되는 것 같아. 많은 젊은 사람들과 어울리는 기회가 된 거니까 너무 좋고.또 북촌의 분위기나 내가 아는 좋은 느낌들을 다른 사람들과 공유하고 싶었는데, 사람들을 태우고 만나고 하면서 아띠를 통해서 실현하니까 그런 매개체 역할을 해줘서 좋고. 또 거기서 소통도 되고 행복해지고. 그런 행복해하는 사름들을 보면 기쁘고 행복해지고.아띠의 상징인 파란색처럼 나를 젊게 해주는 것 같아. 그리고 내가 그렇게 되려고 노력하는 편이고.Q. 미래의 아띠라이더들에게 조언을 해준다면?젊은 사람이라면 한 번쯤은 해봤으면 좋겠다싶어. 몸을 쓰는 일이라 여름에는 덥기도 하고, 겨울에는 춥고 사람이 없어서 힘들긴 하지만, 얻어지는 것들은 충분히 보상하고도 남으니까 많이들 도전했으면 좋겠어. 청춘의 한 페이지가 아띠인력거라는 소중한 경험과 추억이 된다면 굉장히 좋을 것 같아. 자기 몸을 사용하는 데, 행복까지 전달할 수 있다면 젊었을 때 안 해보면 언제 또 해보겠어. 값진 노동이라는 것을 경험해봤으면 좋겠어.그리고 요즘 많은 사람들이 한 곳만 바라본다는 게 문제잖아. 한 가지에만 내몰리게 되는 게 사람을 불행하게 만드는 것 같거든. 꼭 아띠를 안하더라도 젊은 사람들이 좀 더 자기만이 할 수 있는 것들을 도전해보고 생각과 경험을 다양하게 해서, 자기만의 길을 만들어 나갔으면 좋겠어. 꿈을 실현시켜나가고 자기가 하고 싶은 것을 하는 게 결과적으로는 진짜 행복해지는 것 같아. 그런 선택 중에 하나가 아띠인력거가 충분히 될 수 있을 거라고 보거든. 그래서 젊은 사람들이 많이 와서 경험도 쌓고, 자기 꿈을 키워나가는 하나의 계기가 되었으면 좋겠어!자연과 나무를 사랑하는 따뜻한 마음을 가진 헉의 두번째 인터뷰였습니다.우직하고 깊은 '나무여행 전문가' 헉의 새로운 도전을 응원하며인터뷰를 마칩니다:)#아띠라이더스클럽 #팀원소개 #팀원인터뷰 #팀원자랑 #기업문화 #조직문화 #사내문화

본 포스팅은 아래 코드를 보시면 좀 더 이해하기 쉽습니다.build.gradledependencies-variable.gradledependencies-classpath.gradledependencies-app.gradleGradle 의 역할Gradle 은 이제 안드로이드 개발에 있어서 그 중심이 되는 빌드 환경입니다. 안드로이드 빌드에 대한 기본 설정 뿐만 아니라 빌드에 필요한 Task 를 지정하거나 의존성을 추가할 수 있습니다.특히 의존성에서 일반적인 서비스들은 다양한 오픈소스를 활용하게 됩니다. 네트워크 라이브러리, 이미지 라이브러리, DI 라이브러리, Support 라이브러리,Play-Service 라이브러리 등등 이젠 프로젝트를 시작함에 있어서 기본적으로 10개 이상의 라이브러리를 추가하게 됩니다. 이러한 라이브러리들이 많아질수록 필연적으로 빌드 스크립트가 길어지게 됩니다. 이는 나중에 빌드에 관련된 코드를 추가/수정할 때 유지보수에 영향을 끼치게 됩니다.Gradle 의존성 분리하기토스랩에서는 꽤 많은 숫자의 라이브러릴 사용하고 있습니다. 테스트용 라이브러리들까지 포함해서 60여개의 라이브러리를 쓰고 있습니다. 이러한 라이브러리 코드들이 1개의 빌드 스크립트 안에 포함되어 진다면 라이브러리의 버전을 변경하거나 수정하는 작업을 할 때에는 불가피하게 시간이 소요될 수 밖에 없습니다.그에 따라 Gradle 에서 라이브러리들을 변수화 해서 분리하는 작업을 하였습니다.1. 라이브러리 변수화 하기ext { retrofit = 'com.squareup.retrofit2:retrofit:2.1.0' retrofit2_gson = 'com.squareup.retrofit2:converter-gson:2.1.0' retrofit2_rxjava2 = 'com.jakewharton.retrofit:retrofit2-rxjava2-adapter:2.1.0' } 가장 간단한 변수화였습니다. 하지만 Retrofit 은 관련 라이브러리들이 함께 수반되기 때문에 버전명을 다시 분리하였습니다.2. 라이브러리 버전 변수화 하기ext { retrofit_version = '2.1.0' retrofit = "com.squareup.retrofit2:retrofit:$retrofit_version" retrofit2_gson = "com.squareup.retrofit2:converter-gson:$retrofit_version" retrofit2_rxjava2 = "com.jakewharton.retrofit:retrofit2-rxjava2-adapter:$retrofit_version" } 하지만 버전명과 라이브러리이름이 함께 있는 것이 깔끔해보이진 않습니다. 그래서 아래와 같이 바꿨습니다.3. 라이브러리 이름과 버전의 분리ext { retrofit = '2.1.0' } ext.dependencies = [ retrofit2 : "com.squareup.retrofit2:retrofit:$ext.retrofit", retrofit2_gson : "com.squareup.retrofit2:converter-gson:$ext.retrofit", retrofit2_rxjava2 : "com.jakewharton.retrofit:retrofit2-rxjava2-adapter:$ext.retrofit_rxjava2", ] 실제에는 다음과 같이 사용하면 됩니다.dependencies { compile rootProject.ext.dependencies.retrofit2 compile rootProject.ext.dependencies.retrofit2_gson compile rootProject.ext.dependencies.retrofit2_rxjava2 } 이제 라이브러리를 변수화 해서 분리를 하였습니다.이제 변수로 지정한 라이브러리들은 build.gradle 파일안에 존재하게 됩니다.// build.gradle ext { retrofit = '2.1.0' } ext.dependencies = [ retrofit2 : "com.squareup.retrofit2:retrofit:$ext.retrofit", retrofit2_gson : "com.squareup.retrofit2:converter-gson:$ext.retrofit", retrofit2_rxjava2 : "com.jakewharton.retrofit:retrofit2-rxjava2-adapter:$ext.retrofit_rxjava2", ] buildscript { // blah blah } 라이브러리가 3개뿐이니 깔끔해보이는군요. 하지만 토스랩의 라이브러리는 60여개 입니다. 변수명도 60여개라는 말이죠. 그래서 라이브러리 변수들만 파일을 분리하기로 했습니다.4. 라이브러리 변수를 파일로 분리하기// dependencies-variable.gradle ext { retrofit = '2.1.0' } ext.dependencies = [ retrofit2 : "com.squareup.retrofit2:retrofit:$ext.retrofit", retrofit2_gson : "com.squareup.retrofit2:converter-gson:$ext.retrofit", retrofit2_rxjava2 : "com.jakewharton.retrofit:retrofit2-rxjava2-adapter:$ext.retrofit_rxjava2", ] // build.gradle apply from :'dependencies-variable.gradle' buildscript { // blah blah } 이제 좀 교통정리가 되어가는 기분이네요.하지만 app 의 build.gradle 을 보았습니다.// app 의 build.gradle apply plugin: 'com.android.application' dependencies { // 라이브러리 60개 compile rootProject.ext.dependencies.library.retrofit2 compile rootProject.ext.dependencies.library.retrofit2_gson compile rootProject.ext.dependencies.library.retrofit2_rxjava2 } android { // 중략 } 뭔가 잘못되어 가고 있습니다. 여전히 dependencies 가 큰 부분을 차지하고 있습니다.5. app.dependencies 분리하기이제 dependencies 를 분리할 차례입니다.// dependencies-app.gradle repositories { jcenter() } dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile rootProject.ext.dependencies.library.retrofit2 compile rootProject.ext.dependencies.library.retrofit2_gson compile rootProject.ext.dependencies.library.retrofit2_rxjava2 compile rootProject.ext.dependencies.library.okhttp3 compile rootProject.ext.dependencies.library.okhttp3_logging compile rootProject.ext.dependencies.library.stetho_okhttp3 } // app 의 build.gradle apply from: 'dependencies-app.gradle' 이제 dependencies 와 관련된 스크립트가 분리되었습니다.하지만 저 apply from 이 항상 app 의 build.gradle 에 따라 붙어야 하는 것이 아쉽습니다. 그래서 buildscript 에 아예 추가하기로 하엿습니다.6. 빌드 스크립트에 dependencies 추가 동작하기먼저 빌드 스크립트용 스크립트를 만들겠습니다.// dependencies-classpath.gradle rootProject.buildscript.repositories { jcenter() } rootProject.buildscript.dependencies { classpath rootProject.ext.dependencies.classpath.android } 그리고 buildscript 가 시작될 때 모든 dependencies 스크립트가 인식할 수 있게 하겠습니다. 인식할 스크립트는 다음과 같습니다.dependencies-variable.gradle - 라이브러리 변수 저장dependencies-classpath.gradle - 빌드용 스크립트 저장dependencies-app.gradle - 라이브러리 추가 스크립트 저장rootProject 의 build.gradle 를 아래와 같이 변경합니다.// rootProject 의 build.gradle buildscript { apply from: "dependencies-variable.gradle" apply from: "dependencies-classpath.gradle" } apply from: 'dependencies-app.gradle' 위와 같이 변경을 하면 빌드스크립트가 동작하는 시점에 변수를 인식하고 빌드용 스크립트를 인식합니다.하지만 앱용 라이브러리 추가 스크립트는 아직 준비가 덜 되었습니다. “app” 프로젝트가 인식이 된 시점에 라이브러리가 추가되어야 하기때문에 처음 만들었던 스크립트로는 한계가 있습니다.그래서 아래와 같이 변경하겠습니다.// dependencies-app.gradle rootProject.allprojects { project -> if (project.name == 'app') { project.afterEvaluate { repositories { jcenter() } dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile rootProject.ext.dependencies.library.retrofit2 compile rootProject.ext.dependencies.library.retrofit2_gson compile rootProject.ext.dependencies.library.retrofit2_rxjava2 } } } } afterEvaluate 는 프로젝트의 인식이 완료되면 동작이 되는 함수이기 때문에 모든 것이 끝나고 dependencies 가 추가되는 것으로 이해하시면 됩니다.정리위의 과정을 거침으로써 gradle 파일은 좀 더 나뉘었지만 app 의 build.gradle 은 안드로이드 프로젝트 그 자체에 집중 할 수 있도록 하였습니다.이렇게 나누었던 본래의 목적은 의존성 라이브러리와 코드 품질 관리용 스크립트가 1개의 스크립트 파일에 담겨지면서 관리하는 데 있어서 큰 문제가 발생하게 되었습니다. 그에 따라 각각을 나누고 그 목적에 맞도록 각가의 파일 만들었습니다.라이브러리의 변수용 파일buildscript 용 classpath 를 관리하는 파일본 프로젝트의 라이브러리 의존성 관리 파일참고 소스Github : https://github.com/ZeroBrain/DataBind-MVVM-Sample#토스랩 #잔디 #JANDI #개발 #개발후기 #인사이트

안녕하세요 협업툴 플로우입니다.디지털 전환! 코로나로 인해 매출에 타격이 있거나 업무가 마비된 경험을 한 기업이라면, 어떻게 해야 비대면 상황에서도 비즈니스 연속성을 가질 수 있을지 심각하게 고려해 봤을 것입니다. 그렇지 않더라도 대부분의 기업에서 디지털 전환은 한 번 쯤 고민해보셨을텐데요.성공적인 디지털 전환은 어떻게 시작해야 할까요? 선두 기업들은 디지털 전환의 첫 시작으로 협업툴을 선택하고 있습니다. 협업툴을 기존 시스템에 빠르게 적용할 수 있기 때문입니다. 아직도 '디지털 전환, 협업툴로 시작해도 될까?' 에 대한 고민이 있는 분이라면 지금 소개해드리는 ‘협업툴을 사용해 본 1429명의 설문 리포트 자료’를 참고하세요.ⓒ Madras check. Source: 2021 협업툴 플로우 사용해보고서협업툴 필요성 및 이유ⓒ Madras check. Source: 2021 협업툴 플로우 사용해보고서1429명의 직장인들은 무려 93%의 응답자가 협업툴이 회사에 필요하다고 답변했습니다. 회사에서 협업툴이 필요한 이유는 ‘1위 팀 소통’ ‘2위 업무 일정 관리’ ‘3위 자료 ·파일 보관’ ‘4위 목표달성’ ‘5위 조직의 생산성’의 순서로 이유를 선택했어요! 특히 팀 소통과 업무 일정 부분이 압도적인 선택을 받았는데 응답자들이 협업툴을 사용해 보다 원활한 소통을 해야할 필요성을 느끼고 있다는 점을 알 수 있었습니다.협업툴 도입 시 중요한 선택 기준ⓒ Madras check. Source: 2021 협업툴 플로우 사용해보고서63%는 내가 의사결정권자라면, 회사에 협업툴이 도입을 적극적으로 제안한다고 답변했습니다. 협업툴 선택 시 중요한 기준은 ‘1위 사용성’ ‘2위 제품의 기능’ ‘3위 가격 합리성’ ‘4위 보안 안전성’ ‘5위 개발사 신뢰’의 순서로 이유를 선택했습니다. 전 직원이 빠르게 적응하여 사용할 수 있는 쉬운 사용성이 협업툴 선택 시 가장 중요한 기준이 된다는 것을 확인할 수 있었습니다.ⓒ Madras check. Source: 2021 협업툴 플로우 사용해보고서 플로우를 사용하면서 이메일, 단톡방을 대신 해 하루 55분 아낄 수 있었다고 답하였습니다. 시간을 낭비하게 만드는 요인으로 꼽았던 업무 진행 상황 체크, 업무 기록 찾기, 자료 검색 등의 4가지가 모두 개선되었다고 답했으며 재택근무, 원격 회의 등 장소의 제약을 개선한 점이 좋았다고 답한 응답자도 413명 있었습니다.ⓒ Madras check. Source: 2021 협업툴 플로우 사용해보고서 이 글은 포스팅 중 일부를 발췌하였습니다.여러분이 회사의 성공적인 디지털 전환과 협업툴 도입 결정을 하는데에 조금이나마 도움이 되길 바랍니다. 원문 링크 :https://post.flow.team/tip/6392👉플로우 리포트 신청하기

배고픈 스타트업에게 사주는 밥 한 끼, 스타트업 식사는 하셨습니까. 130회 차 스밥은 6월 29일 금요일, 청담동 옛날집에서 진행되었습니다.  오늘의 게스트는 암 환우를 위한 뷰티 서비스를 제공하는 #인디뷰티 팀입니다.암 치료를 하다 보면 머리가 빠지고 피부색이 검게 변하는 등 외모에 변화가 올 수밖에 없지만, 그렇다고 해서 아름다워지고 싶은 욕구가 사라지지는 않습니다. 아니 오히려 하루가 다르게 수척해지는 모습을 보다 보면 예뻐지고 싶다는 욕구가 더 욕구가 강해질지도 모릅니다. 그러나 암 환우분들은 화장품 성분 하나하나에 민감할 수밖에 없기 때문에 화장품을 쓰는 것조차 조심스러울 수밖에 없지요.  암환우에게 메이크업을 하고있는 인디뷰티 유지영 대표인디뷰티 팀은 이런 고충을 겪고 있는 암 환우 메이크업 서비스로 암 환우 전문 화장품과 가발까지 제작하고자 하는 계획을 가진 당찬 소셜벤처입니다. 이 팀을 위해 대한민국 최고의 메이크업 아티스트이자 해외에서도 활발하게 활동하고 계신 서수진 대표님께서 호스트로 함께 해주셨습니다. 서수진팔레트의 서수진 대표님초기 암환자에게 뷰티케어를 하는 직업을 만든 유지영 대표는 단순히 외모를 바꾸자는 마음보다 그분들과 소통을 하는 것이 더 중요하다고 생각하기 때문에, 암센터를 찾아가 직접 환우들을 만나고 그분들의 이야기를 들으며 그분들에게 정말 필요한 것이 무엇인지 길을 찾아가고 있었습니다. 그러나 아직은 사업 초기단계라 지금 제대로 하는 것이 맞는지, 앞으로는 어떻게 나아가야 할 지에 대해서도 고민이 많았는데요. 쉽게 생각하기 어려운 암환자들을 위한 뷰티 산업에 유지영 대표가 뛰어들게 된 계기는 가까운 분들이 암 투병을 하며 힘들어하는 모습을 보면서 자신들이 할 수 있는 메이크업으로 도울 수 있겠다는 생각을 하게 되었기 때문이라고 합니다. 선한 마음에서부터 사업이 시작된 만큼, 그 마음을 알아보고 관심을 가져주시는 분들 덕분에 한발 한발 내딛을 수 있었다고 하네요. 서수진 대표님께서는 먼저 그 길을 걸었던 선배 메이크업 아티스트로서 자라나는 후배들에게 맞춤 조언을 해주셨는데요. 좋은 취지로 시작된 사업도 이윤이 나야 지속될 수 있기때문에, 사업화 시킬 수 있는 부분에 대해서 많은 조언을 해주셨습니다. 어떤 길로 가는 것이 좋을 지 고민하는 스타트업에게 앞서간 선배의 조언만큼 귀중한 것이 없겠죠? 지금 뷰티시장에는 메이크업을 잘하는 사람도 많고, 강의를 잘하는 사람도 많지만, 암환자분들이 원하는 메이크업에 대한 데이터 갖고 있는 사람은 없기 때문에, 인디뷰티가 직접 병원을 찾아가서 환우분들을 만나서 그분들에게 정말 필요한 정보를 차곡차곡 쌓아가고 있는 것이 앞으로 정말 중요한 자산이 될 것이라며 조언과 함께 칭찬 또한 아끼지 않으셨습니다.  이번 모임에는 크립톤의 문지연 이사님과 양경준 대표님도 함께해주셔서 두분도 격려와 조언을 나눠주셨는데요. 밥 먹는 내내 정말 좋은 이야기들을 해주셔서, 에디터로 참석했던 저 또한 몸의 양식뿐 아니라 영혼의 양식까지 가득 채우고 돌아가는 느낌이었습니다. 이번 스밥은 게스트가 고민하는 부분을 너무나 잘 알고 계신 호스트님께서 맞춤 솔루션을 제시해주셔서 게스트에게는 정말 큰 도움이 되었을거라 생각됩니다. 맛난 식사가 끝나고, 유지영 대표가 서수진 대표님께 만나 봬서 영광이었습니다라는 후기를 전하자, "나중에 내가 유대표를 만나는 것이 더 영광이 되는 날이 오도록 열심히 해주세요."라는 답을 주셨는데요. 안될 사업이면, 냉정하게 그만두라고 말씀하신다는 서대표님께 칭찬을 듣고 인디뷰티팀이 정말 기뻐했다는 후문을 전하며 화기애애했던 130회 차 스밥 포스팅을 마무리하겠습니다. **스타트업 식사는 하셨습니까? 에서는 배고픈 스타트업과 스타트업을 사랑하는 선배님들의 신청을 기다리고 있습니다. 언제든지 문을 두드려주세요~ 게스트 신청하기호스트 신청하기#스트레스컴퍼니 #심리스타트업 #스트레스관리 #서비스소개 #제품소개

#재택근무  #재택근무후기 #인터뷰 #협업툴 #기업문화 #조직문화안녕하세요 협업툴 플로우입니다. 협업툴 플로우 직원들의 솔직한 재택근무 시행기를 공개합니다!플로우 재택근무 시행기 두번째는 CX팀의 인터뷰 글입니다.Q. 간단한 본인/ 팀 소개A. 플로우 CX팀 팀장 박예랑입니다. 저를 포함한 저희 팀원들은 모두 고객들에게 플로우의 서비스 경험이 좋은 기억으로 남게하기 위해서, 가장 최전방에서 서비스를 제공하고 있습니다. 저를 포함한 총 4명의 팀원이서 매일 약 15만명의 고객들과 소통을 하고 있죠. 고객들의 요구 사항은 회사의 모든 부서와 이해관계가 직결된 부분이 많기 때문에, CX팀은 사실 회사에서 가장 많은 부서와 협업을 해야 하는 팀입니다. 적은 인원이서 많은 고객들과 소통을 하는 동시에, 여러부서와 협업을 해야하기 때문에 저희 팀은 정확하고 빠른 커뮤니케이션이 매우 중요하죠.Q. 본인의 재택근무 환경을 소개해주세요.A. 저는 회사에서 실제로 사용하고 있는 노트북을 그대로 집에 가져와서 쓰고 있습니다! 업무용 파일들이 모두 그대로 담겨있기 때문에, 재택할 때 마다 필요한 파일을 따로 옮길 필요가 없어서 편해요. 또, 회사로 오는 기업 문의는 제 투폰 번호로 돌려놓고 있어서 고객지원 업무부터 기업 컨설팅까지 집에서도 모두 동일하게 하고 있습니다. 그리고 사진 속 고양이는 저희집 1호 말썽꾸러기 하멜이입니다. 하멜이를 무릎에 앉혀두고 있으면 이너피스..! 업무 스트레스가 싹 날라가요. 정말 최고의 업무 환경이죠? 하핫!Q. 출/퇴근은 어떻게 체크 하나요?A. 지난 2월에 올린 재택근무 시행기 리뷰와는 인증 방법이 달라졌어요. 이제는 재택근무가 회사의 보편적인 출근 방법 중 하나로 정착 되면서, 출퇴근 시간도 자유롭게 운영되고 있습니다. 아침 8시부터 11시까지 자유롭게 출근하고, 각자의 업무시간에 맞게 자율적으로 퇴근하고 있죠. 가장 먼저 재택근무로 출근하는 직원이 '출퇴근시간 기록' 일정을 등록하고 댓글을 다는 방식으로 출퇴근을 인증하고 있어요.재택근무를 시행해도 업무가 안정적으로 잘 돌아가다보니, 회사에서도 저희를 믿고 자율성을 보장해주고 있죠. 오히려 이런 자율적인 출근제도를 잃고 싶지 않아서, 저도 저희 팀원들도 더 정직하게 출퇴근 시간을 지키고 있습니다!Q. 팀원들의 업무 관리는 어떻게 하나요?A. 여러가지 업무가 있지만, 아침에 출근하면 가장 먼저 지난 밤동안 각 기업에서 온 문의를 확인합니다. 어느 한 사람한테 문의가 몰리면 고객과 약속한 일정 전체에 차질을 주기 때문에, 각 담당자들이 최대한 효율을 낼 수 있도록 업무분배는 제가 직접하고 있습니다. 제가 먼저 문의를 확인해서 업무로 등록하고 각 문의의 성격에 맞게 담당자와 마감일을 지정해줍니다. 또, 기존에 등록된 업무 중 마감기한을 넘긴 업무는 재확인해서 일정을 조율하죠. 팀원들의 업무 진행상황을 한눈에 볼 수 있기 때문에, 관리에 시간이 들어가지는 않고 있어요!Q. 본인의 업무는 어떻게 관리하나요?A. 관리랄게 따로 없어요. 플로우에서 전체 업무를 클릭한 뒤, [내 업무] - [마감기한] - [우선순위]로 값을 설정해요. 이렇게 해두면 제가 오늘 해야하는 일을 한눈에 볼 수 있죠.Q. 오전에는 주로 어떤 업무를 하시나요?A. 오전에는 회사 내부의 업무 보다는 외부 기업 상담을 주로 하고 있어요. 상담할 때는 전화도 많이 사용하지만 기능을 주로 보여드려야 하기 때문에 주로 화상회의나 원격지원을 통해서 플로우 사용 방법을 보여드리고 있습니다. 직접 원격지원으로 상담하는 사진을 보여드리고 싶지만, 고객사의 보안을 지켜드려야 하기 때문에 인증은 생략했습니다.Q. 오후에는 주로 어떤 업무를 하시나요?A. 오후에는 주로 내부 회의가 많이 잡혀있어요. CX팀은 가장 고객 접점에 있는 팀이기 때문에 모든 부서의 의사결정에서 CX팀의 의견이 매우 중요하죠. 재택근무에서 회의는 화상회의로 참여합니다. ZOOM을 이용하면 화면공유도 되기 때문에, 엑셀이나 워드파일로 작성한 문서도 잘 공유돼서 대면보다 의미 전달이 떨어지지 않아요. 단점이라면, 재택근무를 핑계로 피하고 싶은 회의까지 모두 참여가 가능하다는 점? ㅎㅎQ. 짝짝!! 모든 업무가 마무리 되었습니다. 퇴근보고는 어떻게 하시나요?A. 퇴근할 때는 업무보고를 따로 하지 않습니다. 오전에 기록한 출퇴근 기록 일정에 퇴근한다고 댓글만 달고 있죠! 어차피 오늘 진행한 모든 업무는 플로우에 남아있기 때문에, 팀원들의 퇴근보고도 따로 받지 않습니다.그럼, 전 퇴근시간이라 이만 안녕~~ 춍춍!협업툴 플로우 바로가기