스토리 홈

인터뷰

피드

뉴스

조회수 2602

삼블리가 만난 사람 - 건축구조 전문가 나민수 수석

안녕하십니까? 삼성물산 건설부문 대학생기자단 8기 주현우, 조영규 기자입니다. 봄기운이 물씬 풍기는 4월의 어느 날, 특별한 만남을 위해 삼성물산 건설부문에 다녀왔습니다. 바로 삼블리 기자단에서 삼성물산 건설부문의 건축구조 전문가이신 나민수 수석님을 만나기 위해서입니다. 평소 건축구조에 대해 궁금한 것들이 많았던 저희에게 정말 알찬 시간이었습니다. 귀한 시간 내어주신 나민수 수석님의 인터뷰, 지금 들려드리겠습니다!Q ) 안녕하십니까! 삼성물산 건설부문 대학생기자단 8기 주현우, 조영규 기자입니다. 만나 뵙게 되어 영광입니다. 먼저 수석님의 간단한 소개 부탁드리겠습니다.안녕하세요. 1989년에 삼성물산 건설부문에 입사해 현재 TA(Technical Advisor)팀에서 근무하고 있는 나민수 수석입니다. 저를 건축구조 전문가라고 소개했는데 사실, 대학시절 건축공학을 전공하고 졸업 후 바로 입사해 지금까지 8개의 현장에서 약 14년 동안 시공을 맡아왔습니다. 사실은 시공전문가에 더 가깝다고 할 수 있죠.Q ) 직접 ‘시공전문가’라고 말씀하셨는데 어떻게 구조기술사와 건축사 자격을 가지고 계신 건가요? 특별한 계기가 있으신 건가요?학부생 때부터 건축구조에 관심이 있어서 개인적으로 조금씩 공부를 했습니다. 그러다 실제 현장에서 구조적인 문제가 발생하면 본사 기술팀에 자문을 요청하고 기다리는 일이 많았는데, 그때 내가 직접 해결해보면 어떨가? 하는 생각을 하게 되었습니다.그렇게 3~4년 동안 공부를 하고 구조기술사 자격을 취득했습니다. 우리가 아는 시공이나 구조는 건축 전체업무 중 일부분 입니다 진정한 엔지니어가 되기 위해서는 관련분야에 대한 지식이 필요하다고 생각하는데, 건축사는 다양한 분야를 폭넓은 이해가 필요한 분야라 도전하게 되었습니다. 시공하다가 어떻게 구조기술사와 건축사 자격을 취득하는지 많이 궁금해 하시는데, 사실 현장에서 경험을 제대로 쌓는다면 설계사무소에서 접하지 못한 훨씬 다양한 부분을 배울 수 있고 도움이 된다고 생각해요. 전 그렇게 현장 경험을 바탕으로 두 가지 자격을 취득할 수 있었습니다. Q ) 일반 건축구조기술사사무소와 삼성물산과 같은 대기업에서의 업무의 차이는 어떤가요?구조기술사사무소는 아무래도 설계위주로 업무가 진행되다 보니 실제 현장에서의 디테일한 부분을 놓치는 경우가 많아요. 건설사에서는 설계를 바탕으로 현장에서 구조물을 지어야 합니다.구조물을 구현하는데 필요한 공법, 요소기술, 품질 및 안전관리, 공기 및 원가관리등 실질적이고 구체적인 업무가 부가됩니다. 예를 들어 구조물을 설계 하는 사람들은 완성된 상태에서 구조계산과 해석을 합니다. 그런데 시공하는 과정에서는 단계가 있을 수밖에 없죠. ‘하부 기둥을 세우고 보, 상부 기둥을 세우고 보’ 이런 식으로 순서가 있습니다. 구조물은 시공 단계에서 외력이 오면 크게 변형하는 불안정한 상태를 거칩니다. 시공 중에 붕괴사고가 발생하는 주된 이유이기도 하죠. 현장에서 이러한 것을 사전에 체크하여 각 단계별로 안전하게 시공하는 것이 굉장히 중요합니다. Q ) 현장에서 구조기술자는 어떤 역할을 담당하나요? 시공 과정에서 여러 분야의 전문가들과 소통하고 때로는 갈등을 겪기도 하실 텐데 이럴 때는 어떻게 해결하시나요?보통 소규모 현장은 시공직들만 있고 구조적인 문제나 결함이 발견되었을 때 자문하는 식으로 진행됩니다. 반면에 대규모 현장에서는 구조담당자가 상주하여 구조 지원을 하고 발생되는 문제를 빠르게 처리합니다.건축 현장에는 여러가지 분야가 있습니다. 하나의 건물을 짓기 위해 설계, 시공, 구조, 전기, 소방, 조경, 토목등 다양한 분야들이 협력하고 있습니다. 부족한 공사 기간 내에 갈등을 겪을 시간이 없어요. 소통할 시간도 부족할 때도 많죠. 물론 설계도면의 디테일 문제나 현장의 진행상황 등으로 갈등이 있을 수도 있지만 최대한 협력해야 합니다.각 분야별 기술적인 소통을 위해 BIM이라는 툴을 이용할 수 있습니다. 각 분야의 모든 정보를 3D 모델 속에 입력하여 각자가 필요한 부분을 추출하여 사용하는 것입니다. 저는 BIM이 소통의 매개체라고 생각해요. 아직은 널리 사용되지는 않고 있지만 머지않아 건축/건설 업계는 모두 BIM을 사용할 것입니다. Q ) 가장 인상 깊었던 현장은 어디였나요? 당시 현장에서 어려움은 없었는지도 궁금합니다.인천공항 교통센터가 가장 기억에 남아요. 2002년 월드컵을 목표로 공사가 진행되었는데 공사 기간이 상당히 부족했어요. 시간상으로 힘들었죠. ‘그레이트 홀’이라는 돔 형태의 비정형 구조의 천정과 그 위에 있는 쥬얼(Jewel)구조물을 시공하는데 공사 기간이 부족해서 바닥 석재마감이랑 같이 진행했어요. 바닥을 사용하면 안 되기 때문에 직접 천정의 곡률과 구조를 계산하고 해석해서 천정에 가시설을 설치하고 공사를 진행했습니다. 그 당시에 야간 철야 작업을 하고 있는데 캐리어를 끄는 첫 승객이 지나갔죠. 그래서 더 기억에 남는 것 같습니다. 허허. Q ) 수석님께서 ‘Partial Top-Down’이라는 공법을 현장에 적용 했다는데, 어떤 공법인가요?‘Partial Top-Down’은 기존 ‘Top-Down’ 공법과 ‘Island Cut’ 공법을 함께 사용하는 공법입니다. 일반적인 Top-Down 공법은 지하층을 파내면서 동시에 지상층도 공사를 진행하는 것을 말합니다. 이를 적용하게 된 계기가 옛날에 공덕에서 아파트 시공현장의 주차장을 공사하고 있었는데 주변 지반의 문제가 있었습니다. 이를 해결하기 위해 고민하다 부분적으로 Top-Down 공법을 적용하면 어떨까 하는 생각에서 고안하게 되었습니다. 흙막이 변위가 심한 굴착작업을 중단하고 먼저 내부  골조를 세웁니다. 그런 다음 Island Cut 공법으로 내부 골조에 지지하여 부분적으로 Top-Down 공법으로 시공합니다. 당시 지반문제로 많은 고민을 했는데 제가 생각해낸 방법으로 잘 해결되어 더욱 뜻 깊었던 현장이었습니다.  Q ) 건축공학이 아닌 건축학을 전공한 학생들도 구조 분야로 진출할 수 있을까요?결론부터 말하면 얼마든지 가능하다고 말씀드리고 싶습니다. 건축설계와 구조설계분야 양쪽에  깊은 전문지식을 가지고 활동하는 사람도 많습니다. 설계를 전공했다고 설계만 해야 한다는 생각은 자신을 너무 구속 하는게 아닌가요? 자신이 하고 싶은 것을 정해서 나아가야 한다고 생각합니다. 얼마 전, 제가 어느 영화에서 본 인상 깊었던 대사가 있는데 자신의 진로에 대해 고민하는 학생들에게 이 말을 꼭 들려주고 싶네요.“당신의 미래는 백지이기 때문에 어떤 지도라도 그릴 수 있습니다. 모든 것이 당신 하기 나름인 것이지요. 모든 것에서 자유롭고 가능성은 무한히 펼쳐져 있습니다. 이것은 멋진 일입니다.”Q ) 수석님께서 근무하시는 TA팀은 어떤 일을 담당하시나요? 또한, 수석님의 일상은 어떤가요?TA팀은 현장에서 기술사고 예방활동을 주임무로 하고 있습니다. Technical Advisor로 현장에서 발생하는 구조문제에 대해 자문하고, 프로젝트 입찰지원, VE(Value Engineering)라고 하는 원가절감 방안 마련 등 굉장히 다양한 업무를 합니다. 그렇기 때문에 저의 일상은 매우 불규칙적입니다.본사보다는 주로 현장에 있습니다. 허허. 매일매일 시간과 공간과 업무 내용이 달라집니다. 처음에는 조금 낯설고 부담이 있었는데 지금은 즐기면서 일하고 있습니다. 이렇게 다양한 일을 하는 것도 재미가 있어요.Q ) 구조 분야를 희망하는 학생들에게 대학원 진학을 추천하시나요? 아니면 학부 수준의 전공지식으로 업무 수행에 충분하다고 생각하시나요?필수조건은 아니지만, 개인적으로 권장하고 싶습니다. 학부 시절에 배우는 구조는 일부입니다. 대학원에서 지도교수와 동기들과 좀더 깊이 있는 지식을 배우기 때문에 구조를 이해하는데 더 효과적일 것입니다. 물론 개인적으로 공부해도 되지만 이러한 것뿐만 아니라 대학원의 동기들, 지도교수 등 인적 네트워크를 형성한다는 것도 중요하다고 생각합니다. 대학원에 진학하여 사회적 네트워크를 형성하고 더 심화된 구조를 배우는 것은 좋다고 생각합니다. Q ) 수석님의 대학 시절을 돌아보았을 때 지금의 대학생들에게 해주고 싶은 조언이 있으신가요?두 가지를 해주고 싶습니다. 첫째로 기본기를 다졌으면 합니다. 각 분야의 전문가가 되기 위해서는 절대적으로 필요한 공부량과 시간이 있습니다. 저는 그것을 학부 시절에 미리미리 준비해야 한다고 생각합니다. 각 분야의 기본적인 원론과 개론 등의 서적을 읽고 자신의 것으로 만들어야 합니다. 졸업하고 준비하려면 시간적으로나 능력적으로나 힘이 듭니다. 학부 시절에 미리 기본기를 충실히 다져야 합니다. “평범함이 쌓여서 비범함이 되는 것이다” 제가 드리고 싶은 말입니다.둘째로 영어, 외국어를 준비했으면 합니다. 나아가 글로벌 스탠다드를 갖춰야 합니다. 앞으로 미래의 시장은 국제적일 것입니다. 해외의 업무를 하기 위해서는 언어라는 장벽을 넘고 국제적인 태도와 스탠다드를 모두 갖추어야 살아남을 수 있습니다. 해외에서 서로 상호작용하고 소통할 수 있는 사람이 되어야 합니다. Q ) 내년이면 30년 근속이십니다. 30년 동안 업무를 해오면서 스트레스는 주로 어떻게 푸시나요?자신이 좋아하는 일을 하면 스트레스를 많이 받지 않아요. 저는 제 일이 너무 좋습니다. 근 30년 동안 일하고 있지만, 아직도 구조가 재미있습니다. 요즈음 모두들 너무 사소한 일에 신경을 쓰는 것 같아요. 많은 사람이 스마트폰, SNS, 웹 서핑, 가십거리등에 에너지를 많이 소비합니다. 저는 머리를 비워내고 꼭 필요한 일에 집중합니다. 또한, 가족들과 즐거운 시간을 많이 보내려고 노력합니다.Q ) 나민수 수석님에게 ‘건축구조’란 무엇인가요?저는 아직도 건축구조를 계속 공부하고 있습니다. 나에게 건축구조란 “끊임없이 몰입하고 열정을 만들어내는 에너지?” 저는 구조를 하는 것이 행복합니다. 인터뷰를 하기 전, 학부생으로서 기본적인 구조적 지식만을 가지고 있었기에 건축에서 구조가 어떤 역할을 담당하고 현장에서의 구조가 어떻게 활용되는지 많은 의문을 가졌습니다. 인터뷰를 통해 지금까지 몰랐던 구조에 대해 더 알게 되고 현장을 더 이해할 수 있는 계기가 되었습니다. 수석님의 커리어를 바탕으로 평소에 알기 힘들었던 것들에 대해 배울 수 있어 뜻 깊은 시간이었습니다. 대부분의 사람은 건축물을 볼 때 겉으로 드러나는 디자인만을 보고 건물을 판단합니다. 외부 디자인만이 아니라 우리가 안전하게 사용할 수 있도록 건물을 지탱해주는 내부의 구조에 대해서도 한번쯤 생각해 보면 어떨까요? 이번 인터뷰를 통해 구조뿐만 아니라 그동안 무심코 지나쳤던 부분을 다시 한번 생각해보는 계기가 되었으면 좋겠습니다. 이상 삼블리 8기 주현우, 조영규였습니다.#삼성 #삼성물산 #삼성물산TA팀 #건축 #시공 #기업문화 #조직문화 #삼성채용 #삼성지원 #구성원인터뷰
조회수 1515

에이스프로젝트 추천도서 - 그래픽팀 편

안녕하세요기업문화가 좋은 야구게임 개발사에이스프로젝트입니다!에이스 추천도서 3탄!이번에는 에이스프로젝트의 금손 아티스트! ‘그래픽팀’편이랍니다.3D부터 원화, UI까지 다양한 그래픽 작업을 하는 그래픽팀.디자이너에게 인사이트를 주는 추천도서가 무엇인지 볼까요?에이스프로젝트 그래픽팀이 추천하는 도서 Best 6!1. 컬러앤 라이트; 리얼리즘을 위한 색과 빛을 그리는 방법 - 제임스 거니[ 이미지 출처 : 예스 24 ]원화 파트 추천도서! 디지털 페인팅의 원리를 설명해주는색채 표현력에 도움이 되는 책2. 3D 게임 비주얼과 연출의 기술 - 오노 코지[ 이미지 출처 : 예스 24 ]연출 추천도서!재미있게 만들어주는 연출의 기술을 알기 쉽게 설명해주는 책3. 열혈 강의 유니티 게임 프로그래밍 - 주세영[ 이미지 출처 : 예스 24 ]테크니컬 아티스트(TA) 추천도서!내가 만든 그래픽 리소스를 직접 게임으로 구현해보고 싶다면 이 책 한 권으로 가능!유니티와 기초 스크립트가 이해하기 쉽게 설명되어 누구나 따라 할 수 있다!4. Creating Stylized Characters - 3dtotal(COR)[ 이미지 출처: amazon ]유럽 감성의 쉽고 재밌는 캐릭터 컨셉 잡기5. 게임 아키텍처 & 디자인 - 앤드류 롤링스, 데이브 모리스[ 이미지 출처 : 예스 24 ]기획자뿐 아니라 개발자 모두가 읽어야 할 필수 고전 도서6. 갓 오브 워 아트북 - 소니 인터랙티브 엔터테인먼트, 산타 모니카 스튜디오[ 이미지 출처 : 예스 24 ]게임은 개별적인 예술의 표현이며 동시에 스토리텔링을 위한 시각적인 요소에 의존하는 매체다양한 분야의 그래픽 작업을 하는 만큼, 책도 정말 다양하네요.대부분은 캐릭터, 원화 스케치 과정이 레퍼런스 위주로 되어있어 참고하기 좋다고 하네요!이상. 그림으로 말하는 그래픽팀의 추천도서였습니다 :)다음은 '개발팀'의 추천도서로 찾아올게요 :)
조회수 812

브랜딩을 망쳐보자(말 한마디로)

사실 브랜딩을 이렇게 해라, 저게 맞다 백날 말하는 건 별 의미가 없습니다. 항상 옳은 방법은 원론적이고 방대하고 추상적입니다. 파괴하는 건 그저 말 한마디, 종이 한 장이면 충분하죠. 오우? 설마 한 번 브랜딩이 되면 쉽사리 바뀌지 않는다는 관성력을 언급하시려구요!? 물론 그렇습니다. 브랜딩은 '의도적 선입견' 을 만드는 과정입니다. 하지만 당신이 코브가 아닌 이상 남의 꿈 속으로 들어가 금고를 열게 아니라면 그것은 당신의 몫이 아닙니다. 우린 우리의 일을 할 뿐, 선입견을 만드는 건 고객들의 몫이죠. 그러니 뭔 전략을 통해서 브랜딩을 한다는 것은 어불성설입니다. 브랜딩 전략이란 말 자체가 어폐가 있다는 겁니다. 브랜딩의 전략은 이미 달성되었습니다. '회사'를 만들었잖아요!우리는 외부의 자극을 줄 뿐, 무엇을 떠올릴 지는 그들의 선택입니다.회사를 잘 운영하기 위해서 브랜딩전략을 짠다구요??? 그건 이상한 말입니다. 당신은 브랜드를 먼저 만들었고 그걸 달성할 수단으로 '회사'를 운영하는 것 뿐입니다. 그러니 이제는 운영단의 문제만 하나하나 해결해 나가면 되는 겁니다. 많은 대표님들이 오해는 이겁니다. 하아, 우리 회사는 브랜딩이 안되서 매출이 안나와.뭐라는...방구같은 소리지요. 브랜딩이 안된 게 아니라 그냥 운영이 개판인 겁니다. 직원들은 시무룩하고, 다들 회사에서 뭐하는 지 별 관심이 없습니다. 의욕도 없습니다. 방향은 이랬다저랬다를 반복하고, 가져다 쓰기나 베끼기식의 컨텐츠가 가득합니다. 3일 전에 한 얘기가 오늘 또 바뀌고, 회의만 계속되는데 말하는 사람은 없습니다. 당장 써야할 제안서가 너무 많으니 전체 회식은 다음 주로 미루기로 합니다. 미뤄서 회식을 했는데 결국 또 직원들은 그냥 하하호호 고기만 먹다가 집에 갑니다. 맡긴 일은 자꾸 늦어지거나 내 맘에 안듭니다. 질책합니다. 의욕이 떨어집니다. 대표도 직원도. 하지만 아이디어는 많습니다. 실행할 사람이 없죠. 이건 브랜딩의 문제가 아니라, 운영과 소통의 문제입니다. 생각을 하나 해보고 넘어갈께요.브랜딩은 고객과 회사만의 문제인가요??브랜딩은 고객과 회사만의 문제인가요??제가 앞선 글에서 얘기했던 내용이 있습니다. 브랜드는 직원과 회사 자체가 지니고 있는 성격, 그 기질이 자연스레 드러나는 것입니다. 정돈된 하나의 비쥬얼과 멘트, 일관된 행동과 철학을 통해서 말이죠. 결국 브랜딩은 사내문화에서부터 기인합니다. 뭐 복지데이 어쩌고 해서 금요일은 5시퇴근이 사내문화가 아닙니다. 아주 사소한 것부터 생각해봅시다. 서로 인사는 하나요? 손님이 들어오면 어떻게 응대하죠? 미팅은 어떤 식으로 해요? 호칭은요? 일이 끝나면 제깍제깍 보고 하던가요? 아니면 가지고 오라고 해야 가지고 오던가요? 결정권자와 실무자간의 커뮤니케이션을 보면 이 회사의 브랜딩이 어디를 향하고 있는지 아주 쉽게 파악할 수 있습니다. 때론 그 방향이 괌을 포위사격하는 형태를 띠며 자폭의 길을 보여주기도 하죠.그런 의미에서 오늘은 고객과 회사가 아닌, 내부의 소통에 대해 얘기해보려고 합니다. 직원들도 고개를 가로젓는 비지니스를 외부에 브랜딩하겠다는 건 말이 안되는 일이거나 그냥 사기치잔 얘기와 비슷하니까요. 브랜딩을 폭망시키는 멘트들! 지금 시작합니다.1. 예를 들어~ 다시 말하면~ 이해됨? 어떤 말이냐면..말이 많다.자꾸 예를 들지 마세요. 예를 드는 것 자체가 나쁘진 않지만, 결과적으로 말을 길게 만듭니다. 회의시간을 4시간으로 만든다구요. 30분이면 끝날 일이 자꾸 예가 붙어서 지구역사만큼 길어집니다. 직원들은 스트로마톨라이트가 되버려요. 굳어진 유기생명체 말이예요. 직원들을 태곳적 존재로 만들어서 지층속에 묻을 것이 아니라면 예를 들지말고 핵심만 딱 전달해주세요.  솔루션은 실무자들이 알아서 만드는 겁니다. 자꾸 예를 들어야 할 정도로 이해력이 좋지 않은 사람이라면 그냥 다른 일을 시키는 게 낫습니다.2. 내 친구가, 내 지인이, 내 사촌이, 내 선배가....지극히 개인적인 개인들의 경험을 실행의 근거로 삼지 마세요. 자꾸 회의시간에 '제가 아는 분이' 라는 얘기가 나오곤 하는데, 아는 분에 대한 데이터를 정확히 밝히던가 아니면 그 사례가 정확한 지 분석을 하고 얘기하는 게 좋습니다. 물론 그런 개개인도 다 고객이 될 수 있으니 중요합니다. 하지만, 더 중요한 건 우리 내부에서 일단 통일되는 것이 중요하잖아요. 종이를 집어던지던 고성이 오고가던 갈등이 있고 몸의 대화가 격렬해지는 한이 있어도 우리들끼리 의견을 합치고 지지고 볶고 해야합니다. 외부사람들의 의견을 끌어들이지 마세요. 차라리 그냥 내 의견이라고 하던가.3. 알겠지? (모르겠는데요..)이 짤 이외는 설명할 도리가 없다.중간이 없는 경우. 절차나 실무는 전혀 모르겠고. '자, 우리 이번 페이스북 좋아요!...지금 심각합니다. 이 정도로는 바이럴도 뭣도 안되요. 무조건 이번에 스폰서드 태워서 좋아요 30,000찍습니다! 다음주까지!'3일 후'팀장님 이번 컨텐츠 도달율이 괜찮은데 스폰서드 태우시죠.''응? 아 그거 거기에 돈 쓰지 말라고 하셔서 그냥 없이 해요.''네?? 그럼 목표치에 다다르기 힘들 건데.''응? 그럼 안되지. 이미 목표는 보고했는데.''뭐라고.요(와씨 반말나올뻔했네)?'무조건 하라고 하지말고, 서포팅을 해줍시다. 알겠지?가 만사장땡이 아니예요. 못 알아듣는 말이나, 불가능한 것 들을 말이 되는 것처럼 자꾸 포장하거나 모호하게 말하면 안되요. 말이란 게 원래 그렇습니다. 얘기 하면 할수록 점점 말이 되는 것 같거든요. 말하는 사람 입장에선. 듣는사람은 점점 미궁속으로 빠져들고.4. 사람은 원래..공자세요?공자세요? 우린 지금 일을 하는 거지, 인간본성에 대한 철학적 고찰이나 지극히 개인적인 가치관을 듣자고 모인 것이 아닙니다. 자신이 그런 모임을 싫어한다고 해서 남들도 싫어하는 건 아니라는 걸 좀 알았으면 합니다.5. 이렇게 하라고 했잖아.(저렇게 하람서요?)본인이 한 말은 기억해야 합니다. 굳이 전략 나부랭이가 아니더라도, 자꾸 뭔갈 갈아엎거나 기억못해서 딴얘기하는 건 브랜딩뿐만 아니라 전반적인 업무를 힘들게 합니다. 이것은 신뢰와 직결되는 문제로, 브랜딩을 위한 어떤 세부전략을 짜거나 회의를 해도 다들 '어차피 바뀔 거...' 라고 고개를 가로젓게 될 거예요!!6. 결론은, 정리하자면...결론은 하나만. 이건 심지어 5번보다 더 심할 수도 있는데, 5분전에 말했던 것과 지금 말한 결론이 다를 때도 있습니다. 보통 생각하고 말하는 게 아니라, 말하면서 정리되는 타입의 사람들이 이렇게 말하는데.....결정사항을 결정할 땐 애드립대잔치말고 명확한 오더를 주도록 합시다. 7. 그래, 니 말도 맞다.경청과 인정은 좋습니다. 하지만 모두의 말이 맞다고 해버리면....뭘 해야하는 지 알수가 없습니다. 경청은 하되 방향성은 잡아야 합니다. 브랜딩은 우리 비지니스와 사람들의 공통된 톤을 정하는 일입니다. 눈에 보이지도 않고 명확하지도 않은 그 '성격과 기질' 이란 것을 표현해내는 일은 아주 세부적이고 구체적이어야 합니다.  우리가 놀기 좋아하는 활발한 분위기의 색을 지니고 있다면 적어도 오프라인 이벤트를 할 때 어떤 텍스트와 어떤 드레스코드로 무장할 지..이렇게 외부로 드러나는 모든 요소들에 대한 결정을 해야하죠. 옷, 텍스트, 디자인, 제작물, 배너, 멘트, 응대방식 등 전방위적 요소에서 컨셉츄얼한 기획이 나와줘야 합니다. 브랜딩자체는 굉장히 모호한 개념이지만, 그걸 실행하는 단계는 어떤 것보다 구체적이어야 하죠. 그래야 고객이든, 내부직원이든 어떤 맥락에서 왜 이런걸 하는지 '이해' 할 수 있습니다. 두루뭉술의 덫에 빠져버리면, 공허한 말잔치만 계속됩니다.이건 사무실을 안개속으로 빠뜨리는 일이죠.   8. 근데...근데..이건 이렇잖아. 근데..이건 이럴 수 없는데? 근데....이러면 어떻해? 근데....내가 이래서 못해. 근데...근데...내 친구가..근데...(가능이 없음)9. 해봤는데..가카?...그 결과가 요즘 대한민국입니다. 지난 레퍼런스를 교훈삼는 것은 물론 좋습니다. 거듭 말하지만 그 레퍼런스의 맥락이 분명할 경우에 말이죠. 개인적인 경험도 교훈이 될 수 있습니다. 현 상황과 적절하다면 말이죠. 사이즈나, 성격이나, 상황이나, 업무적 측면에서 유사점이 많다면 리스크를 미리 방지할 수 있습니다. 하지만, '해봤는데...' 가 지니는 문제점은 이거죠.  그럼 해본 사람이 하셔야지, 한 사람은 본인이고 일은 딴 사람이 한다는 것.발언을 했다면 책임을 지고, 다른 사람들은 손놓고 있는게 아니라 서포트를 약속해주는 겁니다. 서로 무서워서 아무말 못하는 것보다 무서운 건, 내가 안 할거니까 아무말이나 내뱉는 것이죠.10. 일단은 ... 어쨌든..여튼..제가 꽤나 싫어하는 말 중 하나입니다. 앞서 말한 모든 말들을 깡그리 무시하고 맥락을 끊어버리는 말이죠. 브랜딩 뿐 아니라 마케팅, 디자인, 영업, 생산관리 뭐...어떤 파트가 되었던 이 단어는 좋지 않습니다. 맥빠지죠. 한참 열심히 회의하고 전략까지 쭉쭉 짜내고 있는데, 일단은 그거말고. 어쩃든, 여튼 해. 등...뭔가 상대가 지금까지 말했던 수많은 의견들을 단 2,3글자로 묵살시킬 수 있습니다. 무엇보다 세부적인 플랜이 나와야하는 브랜딩영역에서 이 단어는...그렇게 디테일하게 공들인 수많은 시간과 노력을 허사로 돌려버립니다. 한 번 무너진 것들은 다시 쉽게 쌓이기 힘들죠. 그렇게 브랜드는 점점 무너져 갑니다. 방향도, 의욕도 없이위의 10가지 멘트는 브랜딩을 망가뜨리는 말만은 아닙니다. 전반적으로 커뮤니케이션을 망치는 화법이죠. 하지만 브랜딩을 다루면서 굳이 이 주제를 꺼낸 이유는 우리가 생각하는 브랜딩에 대한 거창함과 거품을 걷어내고 싶었기 때문입니다. 위에서 언급했듯 색깔을 드러낼 수 있는 비쥬얼적, 기획/운영적 플랜은 아주 세부적으로 나와주는 것이 맞습니다. 그러나 그 전제는 회사 내부적으로 일단 통일된 의견과 이해입니다. 실제로 출퇴근을 하면서 프로젝트를 하다보면, 운영진의 회의가 끝나고 나온 후 직원들의 뒷담화를 자주 듣게 됩니다. 그 뒷담화에 편을 들어줄 생각은 없습니다. 가만 들어보면 본인들도 전혀 노력도 없이 그냥 월급이나 따박따박 받아가고 싶은 사람들도 태반이기 때문입니다. 컨텐츠를 만들려면 당연히 뛰어다녀야 합니다. 그건 기본중에 기본입니다. 자료조사를 해도 끊임없이 인터넷을 뒤져야 하고, 사람도 만나야 하고, 인터뷰, 콘티작성, 일정조율 등...모르면 공부해야하고, 안되도 되게 해야하는 경우가 많습니다. 그걸 그냥 주저앉아서 '난 그런거 못하는데 왜 나한테 시키고 지랄이야' 하면서 불평이나 하고 있는 사원들의 모습은 좋아보이지 않습니다.(많이 순화함) 하지만 여기서 잘잘못을 따지잔게 아닙니다. 그럼에도 불구하고 제대로 우리 회사의 색을 만들고, 또 살리고 싶다면...  대표님이 그토록 원하는 브랜딩을 성공으로 이끌기 위해선 어쨌든 이 브랜딩 액션을 수행해낼 수 있는 온전한 집단이 필요합니다. 대기업은 BX팀이 있으니 굳이 전 사원이 막 회의에 참여하고 이럴 필요가 없다고 칩시다.. 스타트업이나 중소기업에선...전 사원이 달려들어서 움직여야 하는 것이 맞습니다. 그 와중에 서로를 피곤하고 지치게 만드는 말들은 최소화시키는 것이 효율적으로도, 심리적으로도 좋지 않겠습니까.자칫 우리의 피곤한 표정과 서로를 등진 얼굴이...우리의 브랜드가 될 테니까요.
조회수 1065

[Buzzvil Culture] 개발팀의 모바일 스터디 그룹이란?

 버즈빌 개발팀의 모바일 스터디 그룹이란? 모바일 잠금화면 미디어 플랫폼 ‘버즈빌’의 개발팀이 진행하는 모바일 스터디 그룹이란, 모바일이라는 큰 주제를 핵심으로 하여 크고 작은 연관된 기술을 리뷰하고 토의하는 스터디 모임입니다. 2018년 7월에 처음 개설되어 현재까지 매주 진행하고 있으며 특정한 기한 없이 지속적으로 진행할 예정입니다. 모바일이라는 핵심 주제를 고지하기는 했지만 사실상 개발에 관련된 모든 주제가 이야기될 수 있으며, 개발 언어, 특정 라이브러리 및 프레임워크, 개발 관련 툴, Google I/O와 같은 각종 컨퍼런스 등 거의 모든 것이 저희의 관심사입니다. 심지어 한 번은 자주 쓰는 단축키에 대해서도 토의한 적이 있습니다. 어떤 목적을 갖고 만들어졌는가? 개발이라는 일은 특히나 최신 이슈에 민감한 분야인 것 같습니다. 빈번하게 일어나는 OS 업데이트와 그에 따른 이슈 처리, 주요 컨퍼런스 내용에 따른 개발 트렌드 변화, 갑작스레 혜성처럼 등장한 개발 라이브러리… 저희 개발자들은 이러한 이슈에 항상 귀를 기울여야 하며, 그에 대해 생각을 정리할 필요가 있습니다. 또한 이러한 기술 습득은 저희 직원들의 커리어에도 중요한 지표가 될 것은 자명하지요. 그러나 실제 업무에 집중하다 보면 자칫 이러한 이슈에 대해서 멀어지게 되고는 합니다. 숲을 보지 못하고 나무만 보는 꼴이랄까요. 모바일 스터디 그룹은 바로 이러한 점을 해결해보기 위해서 개설됐습니다. 적어도 1주일에 한 번씩은 업무에서 잠시 떨어져 다양한 개발 주제로 생각을 정리해보자는 게 이 스터디의 목적이며, 다재다능한 그룹원들의 참여 아래 훌륭하게 진행되고 있습니다. 어떻게 진행되고 있는가? 우선, 매주 월요일 점심마다 스터디가 진행되고 있습니다. (스터디를 할 경우 회사에서 점심을 제공하고 있어 회사의 모든 스터디 모임이 더욱 활성화되는 것 같습니다.) 스터디 주제는 1주일 전에 그룹원들과 이야기를 통해서 정하고 있고, 주제가 정해지면 자발적으로 주제에 대해 학습하며 자료를 공유합니다. 스터디 당일에는 일정 시간을 개별 학습하는 용도로 사용하고, 그 후에 각자 공부한 내용을 바탕으로 자기 생각을 이야기합니다. 기본적으로 상황에 맞게 자유롭게 진행되기 때문에 꼭 위와 같은 방식을 고수하지는 않습니다. 때로는 특정 주제에 대해서 스터디원이 세미나를 희망하기도 하는데, 이 경우 발표자가 자료를 만들어서 세미나를 진행하기도 합니다. 한 번 했던 주제에 대해서 다수가 흥미를 가질 경우 다음 주에 조금 더 깊이 있는 이야기를 나누거나 실제 실습을 해보는 시간을 갖기도 합니다. 아직 시도하지는 않았지만, 주요 컨퍼런스 영상을 보는 시간으로도 활용할 생각입니다. 어떤 주제를 진행했는가? 모든 주제를 나열할 수는 없지만, 대표적인 사례에 대해서 전달하겠습니다.  RxJava : Reactive 진영의 자바(Java) 라이브러리. 그 내부 원리와 구조 학습 Unit Test : JUnit 4, Mockito, Robolectric의 활용과 실전 예제 학습 Kotlin(코틀린) : 안드로이드(Android)에서의 Kotlin 트렌드 확인. Kotlin의 장단점 분석 MVP / MVVM : 안드로이드(Android) 아키텍쳐로 바라보는 MVP / MVVM의 내용 및 차이 학습  이 외에도 여러 주제에 대해서 지속해서 스터디를 진행했지만, 위 내용은 스터디원이 전체적으로 공감하고 도입 의지를 이끌었다는 점에서 인상적이었던 것 같습니다. 특히 코틀린과 같은 경우는 실험적으로 프로젝트에서 도입을 진행하고 있고, 코드 간결화, Null-Safety 측면에서 큰 장점을 느끼고 있습니다. 이처럼 저희 스터디는 학습하게 된 내용을 단순히 지식으로 놔두지 않고 실제 프로덕션에 도입까지 충분히 진행 할 수 있으며, 반대로 실제 프로덕션에 더 좋은 기술을 도입하기 위해서 다양한 주제를 찾아가고 있습니다.버즈빌의 스터디는 무엇이 다른가? 개인적으로 꽤 많은 스터디에 참여해 봤다고 생각합니다. 다양한 주제는 물론 강의형, 토론형 등 여러 방식으로 진행해본 경험이 있습니다. 그중에는 1년 넘게 유지되면서 다양한 지식을 습득한 모임도 있었고, 몇 번 해보지도 못하고 와해한 안타까운 케이스도 있었습니다. 덕분에 좋은 스터디란 무엇인가에 대해 꽤 고민을 해봤고 어떤 부분이 중요한지 나름대로 생각하고 있는 부분이 있습니다. 그리고 그러한 측면에서 버즈빌의 스터디는 좋은 스터디라고 분명히 말씀드릴 수 있습니다. 그렇다면 구체적으로 어떤 점이 버즈빌의 스터디를 좋게 만드는 것일까요? 그 이유는 다음과 같습니다. 첫째, 버즈빌의 수평적인 문화 버즈빌의 사내 문화는 수평적이고 자율적인 문화로 유명합니다. 소위 고루한 잔소리꾼 문화가 없기 때문에 자신의 의견을 누구나 자유롭게 이야기합니다. 사내문화가 스터디와 무슨 상관이 있냐 하실 수 있지만, 수직적인 조직의 사내 스터디와 비교했을 때 큰 차이를 볼 수 있었습니다. 버즈빌의 스터디에서는 여러 사람이 어떠한 권위에 눈치 보지 않고 자유롭게 자신의 의견을 제시하며, 듣는 이 또한 어느 의견이든 함부로 가늠하지 않고 진지하게 받아들입니다. 이는 단순히 스터디 토론에서만 적용 되는 것이 아니라, 스터디 시스템에 대해서도 불합리하거나 개선하고 싶은 점을 여과 없이 이야기합니다. 그리고 그들의 의견을 피드백하여 시스템이 지속적으로 개선되고 있습니다. 결국은 버즈빌의 수평적인 문화가 스터디 문화 자체도 현실적이고 합리적으로 바꿔나간다고 할 수 있습니다. 둘째, 뛰어난 구성원 스터디에서 구성원은 분명 굉장히 중요한 요소입니다. 구성원의 역량과 열정에 따라서 스터디의 질과 지속력이 결정됩니다. 그런 측면에서 버즈빌은 상당히 축복받은 조직임에 틀림없습니다. 당장 제 옆만 둘러봐도 어디서 이런 분들이 나왔을까 싶을 정도로 뛰어난 역량의 소유자가 많으니까요. 아마 인사팀에서 일을 잘하고 있나 봅니다. 여하튼, 버즈빌에는 다재다능한 인재가 정말 많습니다. 각종 분야에 있어서 상당한 지식을 보유하신 분도 굉장히 많으시고, 무엇보다 개발을 좋아하고 새로운 기술을 배우는 것에 긍정적입니다. 열정이 넘친 나머지 스스로 일정을 잡아서 기술 세미나를 진행하기도 하지요. 이런 분들과 함께 하는 스터디, 안 좋을 수가 없습니다. 셋째, No 강제, No 의무 제가 생각하는 좋은 스터디의 중요한 요소는 지속력입니다. 아무리 좋은 스터디라도 무리한 일정과 과제의 압박이 있다면 지속되기 힘들다고 생각합니다. 단발성으로 집중하여 어떤 지식을 습득하려는 게 아닌 이상은, 결국 얼마나 꾸준히 스터디원이 참여하고 공부를 할 수 있는지가 중요합니다. 그러한 측면에서 볼 때 참가를 강제하고, 어떠한 의무성인 과제를 부여하는 것은 지양해야 합니다. 공부는 스스로의 의지에 의해서 수행되어야 하며, 스터디 시스템에서 이를 강제 해봤자 결국은 보여주기 식의 활동밖에 되지 않습니다. 사람이 어떻게 모든 주제에 항상 열정적으로 공부를 하겠습니까. 그렇기에 스터디라는 시스템보다는 사람이 우선이어야 하며, 공부는 본인의 자유입니다. 위와 같은 요소로 인해 전 결론을 내봅니다. 버즈빌에서 굉장히 좋은 스터디를 하게 되었다고. 결론 버즈빌에서 스터디는 CEO 분들을 비롯하여 많은 구성원이 장려하고 권장하는 부분입니다. 그들은 직원의 역량 강화가 곧 회사 역량의 강화라는 인식을 바로 갖고 있으며, 이를 위해 정책적으로 지원하는 방안을 마련해주고 있습니다. 스터디 제도뿐만 아니라 각 개인이 성장할 수 있도록 동아리 지원, 자기개발비 지원 등은 물론 읽고 싶은 책은 무제한으로 제공 해주고 있습니다. 어쩌면 이러한 사소한 점 하나하나가 버즈빌의 소중한 자산이 아닐까 생각하며, 이만 글을 마무리 짓습니다. 감사합니다.작가소개 Ethan Yoo, Software Engineer (Android) 안녕하세요. 버즈빌에서 안드로이드 부분 개발을 담당하고 있는 Ethan (이든)입니다. 개발이라는 주제로 다양한 곳에 관심사를 갖고 있고, 동료와 함께 개발 이야기를 하는 것을 좋아합니다. 메인 언어는 자바(Java)를 사용하고 있지만, 코틀린(Kotlin) / 파이썬(Python) / 자바스크립트(JavaScript) / 하스켈(Haskell) 등 다양한 언어에 대해 경험이 있습니다. 최근에는 시스템 아키텍쳐에 관심을 갖고 반응형 프로그래밍, 함수형 프로그래밍 등이 안드로이드와 어떤 구조로 표현 될 수 있을지 고민하곤 합니다. 제가 만든 서비스가 세상을 바꿀 수 있기를 희망하고, 이를 위해 버즈빌에서 오늘도 열심히 개발을 하고 있습니다.
조회수 1761

Database를 왜 사용할까요?

개발자들이 Database 프로그램을 선택한 이유Database(이하 DB) 프로그램을 처음 접한 건 Dos에서 사용하는 Database III plus였습니다. 이때는 학생이었기 때문에 프로그램 개발에 관심이 많았지만 대량의 데이터를 다룰 일은 없었습니다. 다음으로 접한 건 clipper였습니다. 과거 C언어를 하던 사람이면 자료 처리를 위해 한 번쯤은 접해봤을 겁니다. 이때까지는 Dos를 주로 사용했고, 간단한 자료를 다루었기 때문에 File 처리만으로도 충분한 결과를 얻을 수 있었죠.그렇다면 DB는 다중 사용자 환경이 되고 바로 사용하게 되었을까요? 예전에 다중 사용자들이 사용했던 걸 꼽자면 PC 통신과 Web이 있을 것입니다. 초창기의 Web은 PHP, ASP가 개발되기 전이었고 Java는 C보다 성능이 낮아 CGI를 C로 구현했으니 게시판이나 자료실 등도 C로 개발했습니다.규모가 큰 PC 통신은 DB를 사용했지만 사설 BBS나 01410 등에 들어가는 외부 업체는 File로 처리했습니다. 이 시기에 사설 BBS나 01410 서비스를 제공하는 업체들은 Workstation을 구입하거나 x86 계열을 구입해 운영체제 (SCO UNIX, Free BSD, Linux 등)를 사용했지만 이때 역시 C로 개발을 했었습니다. 이런 환경에서 점점 File 처리의 한계가 나타나기 시작했던 것이죠.C File lock 예)int iFd, iResult; iFd = open(“LockTest”,O_RDWR);  iResult = lockf(iFd, F_LOCK,10L); /* 필요한 작업 처리 */ close(iFd); 유저가 늘어나고 운영 체제 내부적으로 동시에 처리하는 프로세스가 증가하면서 자료가 깨지는 현상이 나타납니다. 개발자들은 어쩔 수없이 DB를 선택하기 시작했습니다.DB의 장점들DB를 도입하면 여러 가지 장점이 생깁니다. SQL 문장만 익히면 프로그램으로 일일이 구현해야 했던 것들을 명령어만으로 수행할 수 있고 자료의 무결성 또한 보장해 주며, 개발의 생산성까지 높입니다. 만약 특정 날짜의 자료들을 읽어와서 제목 순으로 보여줘야 할 경우, 프로그램으로 개발한 자료를 날짜 별로 읽어 배열에 담고 Quick sort 알고리즘을 적용해 정렬한 후 자료를 보여줘야 합니다. 하지만 DB에서 SQL 문장을 사용하면 간단하게 완성할 수 있습니다. SELECT * FROM TABLE WHERE DATETIME = 날짜 ORDER BY TITLE ; 조심 또 조심!하지만 DB 역시 만능은 아니기 때문에 모든 자료를 처리할 수는 없습니다. 예를 들어 문서(pdf, doc, hwp등) , 이미지(jpg, gif 등), 압축(zip,rar 등) 등의 바이너리 파일입니다. (물론 DB에서 BLOB 자료형을 지원하므로 하드웨어 자원과 성능만 받쳐준다면 불가능한 것은 아닙니다.) 하드웨어 자원과 성능에는 한계가 있기 때문에 DB로 해야 할 일과 하지 말아야 할 일을 구분해야 합니다. 만약 이를 생각하지 않고 DB에 모든 자료를 넣는다면 어떤 문제가 생길까요? 크게 두 가지가 있습니다.첫 번째는 바이너리를 파일을 읽고 쓸 때 발생하는 시간이 문제가 될 수 있습니다. 그 이유는 DB가 Connection Pool로 접속을 관장하는데, 이는 한정된 자원으로 최소한의 시간을 사용해야 많은 유저가 사용할 수 있기 때문입니다. 만약 바이너리 파일을 DB에 올리면서 오랜 시간 접속을 유지한다면 그만큼 다른 유저가 사용할 수 없을 테고, 결국은 DB에서 감당할 수 있는 유저의 수가 줄어들 것입니다.두 번째는 백업의 문제가 있습니다. 우리는 DB에 장애가 발생할 때를 대비해 DB 전체 백업을 합니다. 그런데 DB에 바이너리 파일이 들어가면 백업 시간이 많이 늘어나 원하는 시간 안에 백업을 하지 못하는 일이 발생할 수도 있습니다. 따라서 DB에 바이너리 파일을 넣을 때는 아주 적은 용량의 파일만 넣어야 합니다. 배치에 대하여: OLTP, OLAPDB 용량이 커지면 Query를 수행해도 원하는 결과를 볼 수 없고 DB에 부담을 많이 주는 Query가 발생합니다. 그래서 주기적으로 Query를 돌려 결과를 테이블에 넣고 필요할 때마다 이를 볼 수 있게 배치 처리를 하며 해결합니다. 일, 월, 년 단위의 집계 자료를 구축하면서 시스템에 부하를 줄 수 있기 때문에 보통 야간에 처리를 하죠. 그런데 만약 DB 용량이 너무 커져서 전일자 집계를 배치로 처리하지 못하는 일이 발생하면 어떻게 할까요?여기서 사용할 수 있는 것이 OLAP(OnLine Analytical Processing) DB입니다. 일반적으로 유저가 사용하는 건 OLTP(OnLine Transaction Processing) 입니다. 대표적으로 Oracle, MySQL PostgreSQL 등이 있습니다. 여기서 MySQL 을 제외하고 Oracle과 PostgreSQL 은 Partition, HASH 조인, Parallel을 지원하여 OLAP 환경에서도 어느 정도 사용 가능합니다.OLAP DB는 주로 DW 환경에서 사용하며 대표적으로 Teradata와 Oracle Exadata 등이 있습니다. OLAP DB 와 비교가 안 될 정도를 빠르게 배치 작업을 처리할 수 있습니다. (자세한 내용은 다음 글에서 설명하겠습니다.)Conclusion지금까지의 이야기를 정리하면 ‘여러 유저가 동시에 안정적으로 자료 처리를 하려면 DB를 사용하고, 자료의 양과 처리 형태(OLAP, OLTP) 에 따라 DB를 선택하면 된다’는 것이었습니다. 자세한 설명을 하자면 각 DB별 특성을 기술해야 하기 때문에 오늘은 전체적인 내용부터 살펴봤습니다. 다음 글에서는 유저가 사용하는 OLTP에 대해 살펴보겠습니다. 글한석종 부장 | R&D 데이터팀[email protected]#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 2860

모바일 데이터 분석의 시작: AARRR (해적지표)

모바일 분석의 중요성은 익히 들어 알고 있지만, 모바일 데이터를 실제 비즈니스에 어떻게 활용해야 하는지 모르겠다고 말씀하시는 고객 분들이 많으신데요. 모바일 분석 툴을 이용하여 아무리 많은 데이터를 쌓더라도, 그것이 실제 비즈니스 목표 달성에 도움이 되지 못한다면 무용지물일 것입니다.오늘은 데이비드 맥클루어의 유명한 분석 프레임워크 AARRR 에 따라 비즈니스 목표를 달성하기 위한 모바일 데이터 분석 활용법을 알아보겠습니다.* AARRR: 미국의 스타트업 엑셀러레이터 500 Startups를 이끌고 있는 데이브 맥클루어 (Dave McClure)가 개발한 분석 프레임워크. 스타트업에서 시장 진입 단계부터 서비스/제품을 홍보하고 사용자를 확보하기 위해 단계별로 집중해야 할 지표를 정리한 성과측정모델. (1) Acquisition (사용자 유치) – 사용자가 어떻게 제품을 접하는가?  모바일 앱을 출시하고, 마케팅을 진행할 때 어떤 광고 채널/캠페인이 가장 효과적인지 파악하기 위해서 어떤 데이터들이 필요할까요? 흔히 가장 많은 앱 설치수나 방문수, 페이지뷰를 일으킨 광고 채널/캠페인이 효과적이라고 생각할 수 있는데요. 하지만 데이비드 맥클루어에 따르면 해당 비즈니스에 의미 있는 이벤트 수를 가장 많이 발생시킨 채널/캠페인에 예산을 집중해야 합니다. 예를 들어, 특정 채널에서 유입된 사용자들의 앱 설치수나 방문수가 높다고 하더라도 비즈니스에 핵심적인 회원가입수, 주문수가 낮다면 효과적인 채널이라고 볼 수 없겠죠. 이 때문에 와이즈트래커에서는 마케팅 채널/캠페인별 앱설치수, 방문수, 페이지뷰 뿐 아니라 비즈니스별 맞춤 성과 (회원가입수, 예약수, 리뷰수, 공유수 등) 전환 데이터를 제공합니다.→ 해당 데이터에서 Facebook과 Google Adwords 광고를 통한 App 설치수는 비슷하지만 주문수 ( 페이스북: 205, 구글: 3 ) 는 크게 차이가 납니다. 이러한 경우, Adwords 광고보다는 Facebook 광고에 마케팅 예산을 집중해야 합니다.  이 뿐 아니라 마케팅 채널 별로 앱 설치 이후에 재사용율 및 삭제율을 Retention 리포트를 통해 제공하기 때문에 어떤 마케팅 채널이 고객들 유치 및 활성화에 효과적인지 파악할 수 있습니다.→ 페이스북으로 유입된 사용자의 Retention 리포트입니다. 앱 설치 이후에 재사용율보다 삭제율이 높아 개선이 필요한 상황입니다.  마지막으로 위의 내용을 통해 가장 효과적인 채널을 파악했다면, 그 채널로 유입된 사용자들이 어떤 사람인지 파악해 보다 효과적인 타겟팅 마케팅을 진행할 수 있습니다. 와이즈트래커의 다차원 세그먼트 기능을 이용하면, 해당 채널에 유입된 사용자의 성별, 연령, 사용국가, 기기 플랫폼 등을 파악할 수 있습니다.→ WISETRACKER 다차원 세그먼트 설정 화면. 광고를 통해 유입된 사용자들을 설정한 세그먼트에 따라 일차원 또는 다차원으로 나누어 볼 수 있습니다. 위와 같이 기기 플랫폼 (IOS vs Android) 과 성별로 다차원 세그먼트를 설정하면 아래와 같은 데이터가 나타납니다.   (2) ACTIVATION (사용자 활성화) – 사용자가 처음 제품 시 경험이 좋았는가? 사용자들이 광고 혹은 특정 경로를 통해 앱을 설치했다 하더라고, 첫 방문 시 사용 경험이 나쁘다면 앱을 삭제하거나 다시 방문하지 않을 확률이 높습니다. 우리 서비스가 유저들에게 만족스러운 경험을 제공하는지 확인하기 위해서는 아래와 같은 데이터 지표를 확인해야 합니다. 첫번째로 화면 이동경로 리포트를 통해, 사용자들이 첫 화면 이후에 앱 기획자가 의도한 화면대로 문제없이 이동하고 있는지를 확인할 수 있습니다. 예를 들어, 메인화면 이후에 서비스/상품 페이지가 아닌 엉뚱한 화면으로 이동하는 비율이 높다면 앱 UI/UX 개선이 필요하겠죠.→ WISETRACKER 화면 이동경로 화면 더 나아가, 전환 퍼널 분석을 통해 각 화면 경로 별 전환율과 이탈율을 분석할 수 있습니다. 4단계로 이루어진 회원가입 전환 경로 분석 시,  2단계에서 이탈률이 높다면 해당 단계에서 고객에게 너무 많은 정보를 기입하게 하거나 민감한 개인 정보를 요구하는 것일 수도 있습니다.→ WISETRACKER 전환 시나리오 화면. 회원가입의 2단계 (가입인증) 단계에서 이탈율이 38.8% 로 가장 높기 때문에 해당 단계에서 인증 단계를 간소화 하기 위한 작업이 필요합니다.   위의 정보들을 통해 우리 서비스가 고객들에게 긍정적인 사용자 경험을 주고 있는지 지속적으로 확인하고, 서비스를 개선해나가는 작업이 필요합니다. (3) RETENTION (사용자 유지) – 사용자가 제품을 계속 사용하는가?사용자가 지속적으로 앱을 방문한다는 것은 그 서비스에 관심이 많다는 의미이므로 추후 의미 있는 전환을 일으킬 가능성이 높습니다. 와이즈트래커의 Retention 리포트를 통해 사용자들이 앱 설치 후 지속적으로 사용하는지, 혹은 방문 후 1~2일 내에 삭제하는지 확인 할 수 있습니다. 만일 앱 설치수는 꾸준히 늘어나는데, 앱 유지율 및 삭제율 또한 점차 높아진다면 처음방문자들에게 앱 서비스가 크게 매력적이게 다가오지 않는다는 의미로 볼 수 있겠죠.→ WISETRACKER의 Retention Report. 1월 12일부터 15일까지 앱 설치수는 크게 늘어나고 있지만, 설치 다음 날(+1d) 앱 삭제율도 증가하고 있기 때문에, 소비자들이 지속적으로 앱을 사용하도록 서비스 개선이 필요한 상황입니다.     이 뿐 아니라 방문 횟수, 방문 분포 리포트를 통해 얼마나 자주 사용자들이 우리 앱을 방문하는지 확인할 수 있습니다. 만일 매일 들어오는 사용자의 수가 제일 많다면, 서비스의 충성고객이 많다는 의미로 볼 수 있습니다. 반대로 15-30일 주기로 들어오는 사용자가 많다면, 이들의 방문을 촉진할 수 있는 이벤트나 프로모션을 푸시메시지로 진행하는 방안을 생각해 볼 수 있습니다.→ WISETRACKER의 방문간격 Report. 방문간격이 0일(매일 방문)인 사용자 비율이 높은 것으로 보아, 앱 충성고객 비율이 높은 것을 알 수 있습니다.  앱 사용자 분석을 통해 우리 비즈니스의 가치고객의 특성을 파악했다면, 특정 사용자 그룹을 대상으로 타겟팅 마케팅을 진행할 수 있습니다. WISETRACKER의 오디언스 타겟팅을 이용하여 데모그래픽, 행태정보, 관심사에 따라 사용자의 ADID/IDFA를 추출하고, 해당 사용자에게만 광고를 노출하거나 푸시메시지를 보내는 것이 가능합니다.→ WISETRACKER의 Audience Targeting 설정 페이지. 위와 같은 설정을 통해 1월에 앱을 설치한 IOS 그룹의 IDFA만 추출하여 광고 노출 및 푸시메시지 전송에 이용할 수 있습니다.  또한 전송된 푸시메시지의 응답률과 실행수 전환분석이 가능하기 때문에, 사용자 방문수와 전환수를 높이는 효과적인 메시지를 파악할 수 있습니다.→ WISETRACKER 푸시메시지 분석 리포트 (4) REVENUE (매출) – 어떻게 돈을 버는가?모바일 비즈니스의 매출 향상을 위해서 앱 내 사용자가 주문을 하도록 만드는 동시에 어떤 사용자들이 가장 많은 돈을 쓰는지 파악해, 유사 사용자들을 대상으로 마케팅을 진행하는 작업이 필요합니다.와이즈트래커의 주문/매출액 리포트에 다차원 세그먼트 기능을 적용하여 주문 고객들의 성별, 연령대, 방문유형, 유입 채널들을 파악해 비즈니스의 가치 고객군을 파악할 수 있습니다.→ 주문/매출액 리포트를 회원 연령대로 세그먼트를 나누면, 아래와 같이 주문한 사용자들의 연령대에 따른 주문수 데이터를 알 수 있습니다.  또한 고객들의 구매 횟수 분포 및 구매 행동 패턴을 파악하여, 앱 내 프로모션 진행 시 활용할 수 있습니다. 예를 들어, 구매 주기가 7일인 사용자가 다수라면, 해당 주기에 맞춰 할인 쿠폰을 푸시로 보내거나 신상품을 소개하는 이메일을 보낼 수 있겠죠마지막으로, 매출 측면에서 가장 인기가 많은 상품과 컨텐츠를 파악해, 앱 내 관련 컨텐츠/상품을 빠르게 업데이트하고 종류를 늘려간다면 같은 기간 내 보다 높은 매출을 기대할 수 있습니다.→ WISETRACKER 상품별 주문/매출액 리포트. (5) REFERRAL (추천) – 사용자가 다른 사람들에게 제품을 소개하는가? 앱 출시 후 비즈니스의 빠른 성장을 위해서는 제품/서비스에 무심한 고객 10000명을 만드는 것보다, 제품과 서비스를 사랑하고 충성도가 높은 고객 100명을 만드는 것이 더 효과적이라고 하죠. 왜냐하면 그 100명은 자신들의 친구와 지인들에게 서비스를 적극적으로 홍보하기 때문에 장기적으로 10만명, 100만명의 고객을 불러올 수 있기 때문입니다.우리 상품/비즈니스가 사용자로 하여금 사랑하고 싶고 매력적인 서비스로 어필되도록 노력하는 것이 가장 중요하고, 그 다음엔 사용자들이 온라인에 쉽게 공유하고, 바이럴할 수 있도록 서비스를 개선해야 합니다.만약 SNS 공유수가 낮다면, 이들에게 적절한 보상을 제공하는 마케팅 방안도 생각해 볼 수 있습니다.마무리하며결국 AARRR 단계별 중요 지표를 데이터로 파악하고, 개선점을 찾아 빠르게 실행하고 업데이트한다면 비즈니스 목표를 달성할 수 있습니다.아직까지 많은 기업들이 추측이나 감을 통해 중요한 의사결정을 내리고 있습니다. 와이즈트래커의 목표는 이러한 고객들에게 데이터를 기반으로 보다 현명한 의사결정을 내릴 수 있도록 돕는 것입니다. 비즈니스 목표를 보다 빠르고 쉽고 달성하고 싶다면, 오늘부터 우리 비즈니스에 핵심적인 지표들부터 데이터 분석을 시작해보는 것이 어떨까요? * WISETRACKER는 모바일 광고 성과 측정부터 In-app 이용자/컨텐츠 분석, 푸시메시지 최적화까지 지원하는 모바일 통합 분석/타겟팅 솔루션입니다. 와이즈트래커 솔루션의 무료체험을 원하실 경우 여기를 클릭해주세요.* WISETRACKER가 제공하는 무료 데이터 분석 컨설팅를 원하신다면 여기를 클릭해주세요.#와이즈트래커 #AARRR #해적지표 #데이터분석 #데이터트래킹
조회수 577

인생 3막 - 창업하다

1막: 학창 시절2막: 샐러리맨 시절3막: 창업!오래 전 첫 사회생활은 창업 준비로 시작했었다. 인터넷 벤처 열풍으로 새로운 시대가 열릴 것이라는 희망을 품고 대학원을 뛰쳐나와 동기 둘, 선배 한명과 모여 넷이서 세상의 변화에 일조하겠다는 마음으로 창업 전선 근처에 갔었더랬다.비즈니스 모델을 만들어 특허까지 신청해 놓았지만 자본금 없이 시작하려던 우리는 결국 블랙먼데이 주가 폭락으로 시장이 급랭하면서 제대로 시작도 못해본 채 접어야 했다. 덕분에 10년 훌쩍 넘게 회사생활을 통해서 안정적인(?) 샐러리맨 생활을 영위해 오며 온갖 조직 생활의 답답함을 인내하면서 언젠가는 온전히 나의 생각을 실현할 그 날을 손꼽아 왔던 것 같다.이미 누군가에겐 기성 세대로 보일 수 있겠지만, 기존의 것을 답습하지 않고 새로운 것을 갈망하는 마음은 그 때 첫 사회생활을 시작할 시절과 다름 없다고 스스로 다짐해왔다.이젠 전문 영역에 대한 인사이트와 기획력이 쌓이고, 아이디어를 구현할 실질적 경험도 있다. 조직 운영에 대한 노하우와 이상만큼 현실적 감각이 중요하다는 것도 터득하면서 인생 3막을 위한 스터디가 어느정도 된 느낌이다. 물론 사업이 느낌으로만은 안된다는 것도 잘 안다.전쟁터에서 야생의 지옥으로 나오는 두려움도 있겠지만, 피할 수 없다면 조금이라도 에너지를 가지고 있을 때 시작하는 게 맞다고 생각한다.정신 바짝 차리고 현실 감각과 진정성을 가지고 무언가를 시도해 가면 시장이, 아니 누군가는 그것을 인정해주고 찾는 사람이 있을거란 믿음으로 용기있게 시작해보는 것이다. 이제 바야흐로 100세 시대이다.앞으로 살아온만큼 이상을 사회의 일원으로 누군가에 의존하지 않고 살아가려면 진정한 독립이 팔요하고, 건강이 허락할 때까지는 무언가 가치 있는 일들을 꾸준히 해나가야 한다.단순히 생계를 위한 경제 활동이 아니라, 자신의 생각을 구현하고 누군가에게 도움이 되는 삶을 살아야 한다. 그래서 해야만하고, 그래서 하는 것이다.생각보다는 말을, 말보다는 행동으로 입증해야 한다. 과정보다 결과로 인정 받아야 하고, 경험보단 실적으로 성과를 내야한다.그리고, 상사의 평가가 아니라 시장의 평가를 기다려야 한다.이제서야 그것을 하려 한다.
조회수 4246

왜 SVG로 갈아탔는가?

이 글에서는 데일리호텔이 왜 png에서 svg로 갈아탔는지, 그리고 간단한 svg 실무 적용 팁에 대해 알려드리고자 합니다.01 SVG란 무엇인가?SVG는 “ Scalable Vector Graphics”의 약자입니다.JPEG, PNG 처럼 SVG도 그래픽 포맷(Graphic format) 중 하나입니다. SVG는 벡터 기반이기 때문에 리사이징이 되어도 전혀 깨지지 않습니다. 모든 해상도에서 자유자재로 활용할 수 있기 때문에 특정 해상도에 제한되어있지 않다는 게 핵심 포인트라고 할 수 있습니다.02 SVG가 왜 좋은가?다른 그래픽 포맷보다 SVG가 좋은 이유는 참으로도 다양합니다. 필자가 생각했을 때의 핵심 장점들은 이러합니다.1. 특정 사이즈에 구애를 받지 않습니다.즉 어느 해상도에서든 pixelate 되지 않습니다. 요새 디자이너들이 자주 사용하는 디자인 프로그램인 스케치로 따지면 아트보드와 비슷한 것 같습니다. 아트보드 안에 만든 레이어, 요소들은 다 벡터 기반입니다. 아트보드를 리사이징 해도 안에 요소들은 깨지지 않고 그 모습 그대로를 가지고 있습니다. 같은 원리로 SVG도 어떤 사이즈로든 그 모습 그대로가 유지됩니다. 그렇기 때문에 사이즈별로 아이콘을 일일이 생성해서 개발자에게 넘겨줄 필요가 없습니다. SVG 파일 하나면 모든 해상도를 대응할 수 있습니다.2. 작은 파일 사이즈비트맵 이미지들(PNG, JPEG) 같은 경우 파일 크기를 결정하는 주요 요소는 바로 ‘해상도’입니다. 예를 들어 5000x5000 픽셀 이미지는 항상 500x500보다 파일 사이즈가 큽니다.반면, SVG 그래픽 같은 경우 파일 크기를 결정하는 주요 요소는 바로 ‘복잡도’입니다. Path가 비교적 적은 간단한 이미지는 PNG, JPEG 보다 파일 사이즈가 적을 수도 있지만 이미지를 구성하는 요소의 복잡도(레이어가 많다든지 특정 효과가 많다든지)에 따라 파일 사이즈가 커집니다.하지만 이런 용량 문제는 SVG Optimizing을 하게 되면 나름 해결됩니다. 필자 같은 경우 업무적으로 스케치를 사용하고 있기 때문에 스케치에서 제공해주는 SVGO Compressor 플러그인을 활용하고 있습니다.https://github.com/BohemianCoding/svgo-compressorBohemianCoding/svgo-compressorsvgo-compressor - A Plugin that compresses SVG assets using SVGO, right when you export them. This Plugin requires Sketch 3.8.github.com 작은 파일 사이즈로 인해 로딩 시간도 훨씬 더 줄어든다는 장점 또한 있습니다.여기서 잠깐!혹시나 Bitmap과 SVG의 구성요소에 대해 잘 모르실 분들을 위하여 간단한 비교 해드리겠습니다.비트맵 그래픽: Raster Graphics (픽셀 기반)대표적인 포맷은 JPEG, PNG입니다. 이들은 픽셀로 구성되어 있습니다. 예를 들어 2x2 픽셀인 비트맵 이미지는 총 4px로 구성되어 있습니다. 개개인에 대한 픽셀들은 자유자재로 바꿀 수가 없고 움직일 수도 없습니다. 그렇기 때문에 100% 이상으로 이미지를 확대하면 Pixelate가 됩니다.SVG 그래픽: 벡터 기반픽셀로 구성되어 있지 않고 작업하고 있는 그래픽에 대한 정보로 구성되어 있습니다. 그렇기 때문에 어떤 사이즈로든 자유자재로 늘어나는 것이 가능합니다. 이러한 이유들로 인해 코드로 쉽게 적용된 스타일을 수정할 수 있습니다. 예를 들어 동그라미의 보더 값을 6에서 8로 바꾼다 / 색상을 그레이에서 블랙으로 바꾼다 / 사이즈를 40x40에서 80x80을 바꾼다 등스케치로 작업할 때도 쉽게 두 개의 차이점을 확인해볼 수 있습니다. 스케치에서 Export를 할 경우 비트맵 이미지는 하나의 압축된 레이어로 Export 됩니다. 반면 SVG는 레이어 그대로 눈에 보이지 않는 그래픽을 구성하는 정보들이 같이 저장된 채 Export가 됩니다.SVG를 구성하는 눈에 보이지 않는 정보들03 스케치가 SVG 이미지를 Export하는 방식다른 그래픽 포맷보다 SVG가 좋은 이유는 참으로도 다양합니다. 제가 생각했을 때의 핵심 장점들은 이러합니다.Sketch Export 기능스케치 하단 오른쪽 패널을 보면 Export 버튼이 있습니다. 여기서 Format을 SVG로 바꾸고 Export하면 금방 쉽게 끝나겠지 라고 생각할 수 있는데 여기서 조심해야 할 점은 본인이 어떻게 이미지를 작업했냐에 따라 옳지 않게 SVG가 내보내질 수 있습니다. 옳지 않게 SVG가 내보내 지게 되면 나중에 두 번 일을 작업하는 일이 발생할 수도 있습니다.쉽게 이해하실 수 있도록 이미지를 제작해 보았습니다. 아래 이미지는 같은 디자인인데 만들어진 방식이 각각 다릅니다.같은 아이콘이지만 구성하는 방식이 다름1. Two Shape2. One Shape3. Border and Shape Mix위 3가지 방법들은 옳고 그름이 없습니다. 다만 어떻게 이 아이콘을 나중에 활용할 것인가에 따라 만드는 방법이 달라지겠죠. 만약에 자동차 아이콘 안에 헤드라이트 색상을 바꾸고 싶다고 하면 위 방법 중 1번을 선택하면 될 것이고 선의 두께를 따로 조정하고 싶다 하면 3번 방식을 택하면 됩니다.SVG에 대해 잘 알지 못할 때는 프로그램 탓을 했었습니다. ‘왜 프로그램이 알아서 잘 못해주지?’라는 질문을 던졌지만… 슬프게도 이건 프로그램 잘못이 아닌 작업자 잘못입니다 �스케치 프로그램이든 아도비 일러스트레이터든 이 프로그램들은 디자이너가 만든 그래픽을 있는 그대로 svg 레이어로 번역하도록 프로그램이 되어 있습니다. 디자이너가 어떻게 작업했냐에 따라 그 정보 그대로 인식해서 svg로 만들어줍니다.04 SVG 아이콘이 제대로 적용 안될 경우다른 그래픽 포맷보다 SVG가 좋은 이유는 참으로도 다양합니다. 필자가 생각했을 때의 핵심 장점들은 이러합니다.헐 이건 도대체 왜….?!!!어느 날 SVG를 적용하기로 마음먹고 데일리호텔 앱 내 편의시설 아이콘 중 수영장 SVG 파일을 개발자에게 넘겼습니다. 근데 구멍이 뚫려야 할 곳이 채워져서 나오는데 원인을 모르고 헤매던 시절이 있었습니다. 미디엄에서 이 문제를 해결해줄 좋은 글을 발견하게 되었는데 난생처음 보는 단어가 2개 있었습니다.Even-Odd, Non-Zero…여기서 Even-Odd, Non-Zero의 차이점을 자세히 언급하기에는 너무 길어서 제가 참고한 미디엄 블로그 링크를 공유해드릴 테니 가서 보시면 이해하실 수 있을 것 같습니다. 작업하기에 앞서 꼭 읽어보시기를 권장합니다.https://medium.com/sketch-app-sources/preparing-and-exporting-svg-icons-in-sketch-1a3d65b239bbPreparing and Exporting SVG Icons in Sketch – Design + Sketch – MediumThis article is going to assume that you already understand the fundamentals of icon design. And focus on how to prepare and export them…medium.com 그래도 가볍게 필요한 내용만 공유드리자면 안드로이드에서는 fill-rule:evenodd를 제대로 지원하지 않고 fill-rule:nonzero만 지원한다고 보시면 됩니다. Even Odd는 특정 앱에서 호환이 안된다는 뜻입니다. (안드로이드 API 24 이상에서만 evenodd가 지원됨)근데 우리가 사용하고 있는 스케치 프로그램에서는 default값이 fill-rule:evenodd로 설정이 되어있고 여러 Path가 겹치는 아이콘 같은 경우 그대로 svg export를 하게 되면 위에서 제가 경험하였던 아이콘이 다 채워진 현상을 겪을 수 있게 되는 것입니다.1. Fills 섹션에서 Even-Odd를 Non-Zero로Fills 섹션에 가면 설정 아이콘이 있습니다. 클릭 시 Even-Odd가 디폴트 값인 것을 확인할 수 있습니다.스케치 Fill Default 값 = Even-OddNon-Zero로 설정값을 바꾸면 수영장 사다리 부분이 가득 채워진 채로 나오게 되는 것을 확인할 수 있습니다. 실제로 이 파일을 개발자에게 넘기게 되면 이렇게 채워진 채로 아이콘이 노출이 됩니다.Non-Zero 설정 / 모든 shape이 다 칠해짐이렇게 나가면 안 될 테니 수정하는 법을 알려드리겠습니다.2. Paths > Reverse Order 적용원래 뚫려 있어야 하는 Path를 Layer 패널에서 찾으면 됩니다. 빨간색으로 칠한 부분이 뚫려있어야 하는 부분들입니다.레이어 패널에서 path 확인하기Path가 선택된 채로 Layers > Paths > Reverse Order을 클릭합니다.Paths > Reverse OrderReverse Order을 클릭한 후 원래 뚫려있어야 하는 부분이 뚫리게 됩니다. 이 상태로 svg로 export하시고 개발자에게 전달을 하면 됩니다.마치며개인적으로 SVG에 대한 장점이 너무나도 크다고 생각하여 굳이 갈아타지 않을 이유가 없다고 생각합니다. 특히 Web 디자인을 할 때도 SVG를 저는 적극적으로 사용하시라고 권장하고 싶습니다. � 안드로이드 개발자에게 넘기기 전에 SVG 파일이 문제가 있는지 가볍게 확인하고 싶은 경우 아래와 같은 사이트를 추천해드립니다.http://inloop.github.io/svg2android/위에 문제가 되었던 수영장 아이콘을 이 사이트에 올려서 보게 되면 이런 화면이 뜹니다. Warning하고 노란색 경고 박스가 뜨게 되는데 fills-rule:evenodd에 대해서 언급을 하더라구요. 정말 유용한 사이트인 것 같습니다.아울러..많은 디자이너들이 SVG 적용을 해보시길 바라며 주변에 이 글도 많이 공유해주시면 감사하겠습니다. (ㅎㅎ)또한 데일리호텔 Tech, UI/UX 등의 정보를 얻어보고자 하시는 분은 https://dailyhotel.io/ 를 읽어 보시길 권장합니다.그럼 다음에도 좋은 정보로 찾아뵙겠습니다!원문 링크 : https://dailyhotel.io/디자인-안드로이드-앱-svg-아이콘-적용기-왜-svg로-갈아탔는가-99c57cd84240작성자 : Product팀 Rachel Kim#데일리 #데일리호텔 #개발자 #개발팀 #업무환경 #개발환경 #SVN
조회수 3189

eventlet을 활용한 비동기 I/O 프로그래밍

안녕하세요. 스포카 크리에이터팀 문성원입니다. 현대적인 프로그래밍 환경에서 네트워크는 더는 특정 직군의 개발자만 접하는 분야가 아닙니다. 그런 만큼 대량의 요청을 네트워크를 통해 송수신하는 프로그램이 생각보다 성능이 나오지 않는 경우를 경험하신 분들도 많으실 겁니다. 물론 스포카 개발팀도 예외는 아니었습니다. 그래서 오늘은 저희의 이러한 경험과 그 해결책-eventlet을 통한 비동기 I/O(Asynchronous I/O)-에 대해 소개합니다.Why우선 스포카 개발팀에서 겪었던 문제부터 시작하죠. 얼마 전 페이스북(facebook)의 FQL(Facebook Query Language)를 통해 정보를 수집해서 이를 활용하는 기능을 작성해야 했습니다. 기존의 함수들은 필요할 때마다 FQL을 요청하는 방식이었고 당연히 이건 너무 느렸죠. 그래서 생각한 것이 “하루의 일정 시간마다 대량의 FQL 요청을 보내서 필요한 정보를 미리 갱신시켜놓자.”였습니다. 여기까진 좋았죠. 이때 제가 작성한 코드의 얼개를 살펴보면 대강 이렇습니다.# 페이스북 계정들을 가져와서 반복하면서for account in FacebookAccount.query:    account.update() #FQL을 보내자.view rawgistfile1.py hosted with ❤ by GitHub그런데 문제가 있었습니다. 기존의 FQL을 보내는 FacebookAccount.update()는 FQL요청이 완료될때까지 멈추고 기다립니다. 대부분의 FQL요청이 2, 3초 정도 걸린다고 했을 때 이러한 지연은 매우 치명적입니다. 대안이 필요했고 자연스레 떠오른 것이 서두에 소개한 비동기 I/O(Asynchronous I/O)였습니다.Asynchronous과거 일부 고급 서버 개발자만 알고 있는(혹은 알아야 하는) 기술로 치부되던 ‘비동기(Asynchronous)’란 개념은 2000년대 들어 등장한 Ajax(Asynchronous JavaScript and XML)의 성공 이후 많은 개발자에게 강한 인상을 줬습니다. 사용자는 HTTP 요청이 끝날 때까지 멈추어 있는 하얀 화면으로부터 해방되었고, 다양하고 많은 요청과 응답들이 자연스럽게 서버로 흘러들어 가서 나왔습니다. 개발자들의 이러한 경험과 통찰은 이후 node.js와 같은 플랫폼의 등장에도 많은 영향을 끼쳤습니다.다시 문제로 돌아가죠. 그렇다면 이러한 비동기에 관한 개념은 위의 상황을 어떻게 해결할 수 있을까요? 문제의 원인부터 다시 살펴봅시다. 2, 3초 정도씩 걸리는 FQL 요청이 문제일까요? 물론 요청이 매우 빨리 처리된다면 별도의 처리 없이도 저 코드는 문제없이 동작합니다. 하지만 현실적으로 이런 I/O의 속도를 빠르게 하는데에는 물리적으로 한계가 있습니다. 오히려 여기에서 주목해야 할 점은 ‘2, 3초’ 보다 ‘기다린다’라는 점입니다. FacebookAccount.update() 같은 경우, I/O가 처리되는 동안 CPU는 하던 일을 멈추고 문자 그대로 기다리게 됩니다. 만약 CPU가 멈추지 않고 다른 요청을 보낸다면 어떨까요? 이렇게 말이죠.비동기만으로는 부족하다?이러한 아이디어는 그동안 많은 개발자가 대량의 I/O를 다루는 올바른 방식으로 여겨왔습니다. 하지만 보통 이러한 비동기 I/O를 통한 구현은 동기식 I/O와는 좀 다른 형태를 띠게 됩니다. 이렇게 말이죠.# http://docs.python.org/library/asyncore.html#asyncore-example-basic-http-clientimport asyncore, socketclass HTTPClient(asyncore.dispatcher):    def __init__(self, host, path):        asyncore.dispatcher.__init__(self)        self.create_socket(socket.AF_INET, socket.SOCK_STREAM)        self.connect( (host, 80) )        self.buffer = 'GET %s HTTP/1.0\r\n\r\n' % path    def handle_connect(self):        pass    def handle_close(self):        self.close()    def handle_read(self):        print self.recv(8192)    def writable(self):        return (len(self.buffer) > 0)    def handle_write(self):        sent = self.send(self.buffer)        self.buffer = self.buffer[sent:]client = HTTPClient('www.python.org', '/')asyncore.loop()view rawgistfile1.py hosted with ❤ by GitHub불행하게도, 이 경우 기존에 사용하던 urllib2대신 HTTP 요청을 처리하는 핸들러를 이처럼 재작성 해야합니다. 거기에 FacebookAccount.update()의 호출 방식마저 바뀔 수 있죠. 더군다나 콜백(Callback) 투성이의 코드는 유지보수가 쉬어 보이지도 않습니다. 여러모로 손이 많이 가는 상황이죠.결국, 기존 코드를 최대한 수정하지 않으면서도, 어느 정도 성능은 보장되는 그런 해결책이 필요했습니다. 그런 해결책이 있을까요? 다행히도 그렇습니다.What저희가 해결책으로 택한 eventlet은 Python(정확히는 CPython)에서 코루틴(Coroutine)을 지원하기 위해 만들어진 greenlet을 이용해 작성된 네트워크 관련 라이브러리입니다. 생소한 용어가 갑자기 튀어나와서 놀라셨을지도 모르니 우선 eventlet에 대해 설명하기 전에 앞에 나온 용어들을 찬찬히 한번 살펴보죠.코루틴과 greenlet먼저 코루틴(Coroutine)부터 살펴보죠. 전산학도라면 누구나 그 이름을 한번은 들어봤을 도널드 카누쓰(Donald Knuth)는 자신의 저서 The Art of Computer Programming에서 코루틴을 다음과 같이 설명합니다.Subroutines are special cases of more general program components, called “coroutines.” In contrast to the unsymmetric relationship between a main routine and a subroutine, there is complete symmetry between coroutines, which call on each other.코루틴은 우리가 잘 알고 있는 서브루틴(Subroutine)과 달리 진입점(Entry Point)이 여러 개일 수 있습니다. 쉽게 이야기하면 실행을 멈췄다가(Suspend) 재개(Resume)할 수 있다는 점인데요. 이 특성을 살리면 우리가 익히 아는 스레드(Thread)처럼 쓸 수 있게 됩니다. 다만 스레드와 달리 코루틴은 비선점적(Non-Preemptive)이기때문에 코드의 흐름을 전적으로 사용자가 제어할 수 있습니다.하지만 불행히도 모든 언어에서 이런 코루틴이 지원되진 않습니다. greenlet은 이런 코루틴을 CPython에서 지원하기 위해 작성된 라이브러리입니다.eventlet코루틴을 통해 스레드를 대체할 수 있다는 점에 주목한 사람들은 greenlet을 통해 유용한 네트워크 라이브러리를 만들어냈습니다. eventlet도 그 중 하나죠. 잠시 eventlet의 소갯글을 봅시다.Eventlet is a concurrent networking library for Python that allows you to change how you run your code, not how you write it.위에서 볼 수 있듯이 eventlet은 사용성에 중점을 두었습니다. 기존의 블로킹 I/O 스타일의 프로그래밍에 익숙한 개발자들도 쉽게 비동기 I/O의 장점을 얻을 수 있게끔 하는 게 목적이죠.특히 저희가 주목한 점은 eventlet의 멍키패치 기능입니다. 멍키패치는 본래 동적 언어에서 런타임에 코드를 고쳐서 별도의 파일 변경 없이 본래 소스의 기능을 변경하는 것을 말합니다. eventlet은 eventlet.monkey_patch 메서드를 통해 표준 라이브러리의 I/O 라이브러리를 논블러킹으로 동작하게끔 변경해서 코루틴에 적합하게 만듭니다.How앞서 소개한 eventlet.monkey_patch를 이용하면 실제로 고칠 부분은 정말로 적어집니다. 다음 코드가 eventlet을 이용해 변경한 전부입니다.import eventleteventlet.monkey_patch() #표준 라이브러리를 변환# 여러가지 import를 하고...pool = eventlet.GreenPool()# 페이스북 계정들을 가져와서 반복하면서for account in FacebookAccount.query:    # 코루틴들에게 떠넘기자.    pool.spawn_n(FacebookAccount.update, account)        pool.waitall()view rawgistfile1.py hosted with ❤ by GitHub정말 적죠? 조금만 구체적으로 살펴보죠. 우선 eventlet.monkey_patch는 socket이나 select등의 Python 표준 라이브러리를 eventlet.green 패키지안에 정의된 코루틴 친화적인 모듈들로 바꿔치기 합니다.# from eventlet/pathcer.pydef monkey_patch(**on):    """Globally patches certain system modules to be greenthread-friendly.    The keyword arguments afford some control over which modules are patched.    If no keyword arguments are supplied, all possible modules are patched.    If keywords are set to True, only the specified modules are patched.  E.g.,    ``monkey_patch(socket=True, select=True)`` patches only the select and     socket modules.  Most arguments patch the single module of the same name     (os, time, select).  The exceptions are socket, which also patches the ssl     module if present; and thread, which patches thread, threading, and Queue.    It's safe to call monkey_patch multiple times.    """        accepted_args = set(('os', 'select', 'socket',                          'thread', 'time', 'psycopg', 'MySQLdb'))    default_on = on.pop("all",None)    for k in on.iterkeys():        if k not in accepted_args:            raise TypeError("monkey_patch() got an unexpected "\                                "keyword argument %r" % k)    if default_on is None:        default_on = not (True in on.values())    for modname in accepted_args:        if modname == 'MySQLdb':            # MySQLdb is only on when explicitly patched for the moment            on.setdefault(modname, False)        on.setdefault(modname, default_on)            modules_to_patch = []    patched_thread = False    if on['os'] and not already_patched.get('os'):        modules_to_patch += _green_os_modules()        already_patched['os'] = True    if on['select'] and not already_patched.get('select'):        modules_to_patch += _green_select_modules()        already_patched['select'] = True    if on['socket'] and not already_patched.get('socket'):        modules_to_patch += _green_socket_modules()        already_patched['socket'] = True    if on['thread'] and not already_patched.get('thread'):        patched_thread = True        modules_to_patch += _green_thread_modules()        already_patched['thread'] = True    if on['time'] and not already_patched.get('time'):        modules_to_patch += _green_time_modules()        already_patched['time'] = True    if on.get('MySQLdb') and not already_patched.get('MySQLdb'):        modules_to_patch += _green_MySQLdb()        already_patched['MySQLdb'] = True    if on['psycopg'] and not already_patched.get('psycopg'):        try:            from eventlet.support import psycopg2_patcher            psycopg2_patcher.make_psycopg_green()            already_patched['psycopg'] = True        except ImportError:            # note that if we get an importerror from trying to            # monkeypatch psycopg, we will continually retry it            # whenever monkey_patch is called; this should not be a            # performance problem but it allows is_monkey_patched to            # tell us whether or not we succeeded            pass    imp.acquire_lock()    try:        for name, mod in modules_to_patch:            orig_mod = sys.modules.get(name)            if orig_mod is None:                orig_mod = __import__(name)            for attr_name in mod.__patched__:                patched_attr = getattr(mod, attr_name, None)                if patched_attr is not None:                    setattr(orig_mod, attr_name, patched_attr)        # hacks ahead; this is necessary to prevent a KeyError on program exit        if patched_thread:            _patch_main_thread(sys.modules['threading'])    finally:        imp.release_lock()view rawgistfile1.py hosted with ❤ by GitHub이렇게 바꿔치기된 eventlet.green안의 모듈들은 I/O에 의해 블럭되는 경우 다른 코루틴에 제어권을 넘기는 식으로 지연을 방지합니다.다른 대안들사실 이러한 목적으로 사용되는 라이브러리는 eventlet만 있는 것은 아닙니다. gevent는 eventlet에서 영향을 받았지만, libevent를 기반으로 하여 더욱 나은 성능과 성숙한 인터페이스를 갖추고 있습니다. 저희처럼 libevent의 설치에 제한이 있는 환경이 아니라면 이쪽을 살펴보셔도 좋습니다.만약 이벤트 주도적 프로그래밍(Event-Driven Programming)에 흥미가 있으신 분은 Twisted역시 좋은 대안이 될 수 있습니다.#스포카 #개발 #개발자 #인사이트 #꿀팁
조회수 1031

크로키닷컴을 소개합니다 #7

안녕하세요. 크로키닷컴 입니다 :-)올해 초, 크로키닷컴은 더 좋은 서비스와 더 빠른 성장을 위해 목적 중심 조직으로의 개편을 진행했습니다. 2020년 메인 프로젝트를 담당하고 있는 각 팀은 PM/개발자/디자이너/마케터 등 다양한 직군의 팀원으로 구성되어 함께 팀의 목표를 달성해나가고 있습니다. 그리고 각자 소속된 팀이 다르더라도 전체 프로덕트가 일관된 방향으로 나아갈 수 있도록 같은 직군의 구성원들이 모여 협업하고 노하우를 나누는 '챕터'가 함께 운영되고 있습니다. 크로키닷컴 내에 존재하는 다양한 챕터들!오늘 처음으로 소개드릴 챕터는 '데이터' 챕터입니다.지그재그 서비스의 성장 과정에서 마주하는 문제들을 해결해나가는 과정에서, 매일 엄청난 양의 데이터를 통해 인사이트를 제공해주시는 데이터 과학자 성운님, 데이터 분석가 인성님과 함께 현재 채용 중인 [데이터 분석가] 포지션 및 지그재그 앱에 관해 소개해보도록 하겠습니다. :-)Chapter 1. 저를 소개합니다!Q. 안녕하세요 성운님, 인성님! 두 분은 각각 어떤 팀에서 어떤 역할을 담당해주고 계신가요?인성 : 안녕하세요, 저는 Growth팀에 속해있는 박인성입니다. 인터뷰는 2번째로 참여하게 되었네요. (웃음) (크로키닷컴을 소개합니다#2 참고)저는 팀 내에서 실행하는 다양한 서브 프로젝트에 대한 결과와 성과를 데이터로 표현합니다. 지그재그 팀에서 시도하는 여러 프로젝트들에 대한 성과 예측, 결과 수집 및 분석을 통해서, 우리가 Growth(성장)를 하기 위해 선택한 방법이 효과적이었는지, 또 앞으로 가장 효율적이고 효과적인 방법은 무엇인지 찾아갈 수 있도록 돕고 있습니다. 예를 들면 이벤트를 기획할 때 '이벤트의 대상자는 몇 명이 될까?', '사람들이 얼마나 주문을 할까?', '거래액은 얼마나 될까?' 등을 예측하면서 우리의 현황을 바라보는 거죠. 팀이 숲을 볼 수 있게 도와드리는 역할을 하는 것 같아요. 최근에는 서비스의 카테고리 확장과 유저 연령대 확대를 위한 데이터 분석과 예측도 진행하고 있습니다.성운 : 저는 커머스 UX팀에서 데이터 분석을 맡고 있습니다. 커머스 UX팀은 작년에 지그재그 내 Z결제(통합결제) 기능이 들어가면서 기존 메타 서비스에서 커머스가 되어가는 과정을 밟고 있고, 또 그렇게 되는 것이 팀의 목표인데요. 아직은 지그재그가 부족한 점이 많아요. 그런 것들을 make-up 하기 위해 여러 프로젝트를 하고 있는데, 결론적으로 기존에 유저들이 사용하고 있던 서비스를 더 편하고 사용하기 쉽게 만들기 위한 팀이라고 보시면 될 것 같아요. 저는 그중 개인화 추천 파트 리더를 맡고 있고요, 1 탭이 곧 개인화된 영역으로 개편될 예정인데 유저들이 앱을 사용하면서 더 좋아하셨으면 좋겠습니다.Q. 얼마 전 입사 3주년을 맞이하신 인성님! 진심으로 축하드립니다. 소감이 어떠신가요?인성 : 제가 3년을 근무한 첫 회사네요. (감격) 시간이 참 빠르다고 생각했어요. 보통 한 회사에서 3년 정도 근무하면 '할 거 다 했다.'라고들 하던데 전 아니더라고요..? 우리는 매해 다른 일들을 하다 보니, 늘 새롭고 어렵기도 해요. 하지만 그만큼 경험을 많이 하게 되어서 너무 좋아요.창밖을 바라보면서도 주변 공간과 분위기를 데이터 로그로 채우는 인성님.jpg(2년 전에 인터뷰를 한 차례 하셨잖아요, 그때의 인성에게 지금의 인성이 해주고 싶은 말이 있다면요?)인성 : 정말 고생했다. (웃음) 저는 경험적인 부분에 있어서는 정말 엄청난 성과를 얻었다고 생각해요. 지금은 예전보다는 단단해진 것 같기도 하고요. 협업하는 과정에서도 성숙해진 느낌? 2년 전에는 지그재그 팀에 데이터 분석가가 저 한 명이었는데, 지금은 Growth팀과 데이터 챕터의 일원으로서 다른 구성원들과 함께 '협업'을 통해 성과를 만들어가는 경험을 하고 있어요. 이 부분에서는 앞으로도 더 많이 성장하고 싶어요.Q. 성운님도 축하드릴 일이 있죠! 바로 AWS 머신러닝 히어로에 선정되었는데요!비하인드가 궁금합니다.히어로 성운님!성운 : 전 회사 일 이외에 데이터 관련 공부나, 트렌드를 쫓아가는 일을 하고 있어요. 그중 하나가 커뮤니티 활동인데요, AWS 한국 유저 그룹 데이터 사이언스 그룹에 참여하고 있고 리딩도 하고 있어요. 햇수로는 3년 정도 됐는데, 개인적으로 발표를 한다거나 노하우들을 알려드리기도 하고 모임도 주최하는 한 명의 운영진이에요. 모임 관련해서 개인적으로 시간을 많이 투자하긴 하지만, 활동할 때 저희 회사에서 하는 업무와 나름 겹치게 하는 편이에요. 예를 들면 발표하는 사례들을 회사에서 해온 업무 위주로 한다거나? 지그재그 사례가 많이 발표되었죠. 그리고 어쩌다 보니 AWS에서 선정을 해주셨더라고요..?(특히 어떤 점에서 뽑혔다고 생각이 드시나요?)성운 : 물론 잘하는 사람을 뽑았겠지만..(웃음) 보는 주요 항목 중 전문성인 부분도 있겠지만, contribution(기여)도 보는 것 같아요. 커뮤니티에 얼마나 기여를 했고, AWS에 대한 내용을 얼마나 전파하는지를 많이 보지 않을까? 생각했어요. 앞으로도 열심히 활동해야겠다고 생각했죠. 계속 공부도 해야 하고, 트렌드들도 빨라지고 많아지고 있는데 사람들과 함께 얘기하다 보면 학습 효과가 커져요. AWS 홈페이지에 들어가면 제가 등록되어 있는데, 한국 사람 중에는 저와 다른 한 분 딱 두 명이예요! 타이틀이 생기니 더 노력해야겠다는 동기도 생겼고, 타이틀에 맞게 더 열심히 활동하고 지식을 나눠야겠다고 생각하고 있습니다.Chapter 2. 우리 챕터를 소개합니다!Q. 지금은 두 분이 각 프로젝트 팀으로 나뉘어서 일하고 계시지만, 지그재그 팀의 데이터 분석가들만의 공통적인 업무 특성이나 프로세스가 따로 있을까요?성운 : 이번에 Z결제 내 리뷰 기능이 들어갔는데, 새로운 기능이 들어가면 사람들의 사용성을 데이터를 통해 보면서 개선할 점을 찾아내는 것이 데이터팀의 기본적인 needs인 것 같아요. 그러다 보니 런칭 전부터 데이터를 모으고 볼 수 있게끔 미리 준비를 해왔어요. 유저가 리뷰를 어떤 방식으로 작성할 것 같은지 등의 예측을 바탕으로, 우리가 세운 가설을 검증하기 위해 어떤 데이터를 모니터링할 것인지 모니터링 기반을 수립하고 실행하기 위한 준비를 했습니다. 예를 들어서 설명해볼까요?성운 : 그래서 최근에 데이터에 익숙하지 않은 팀원들도 데이터를 쉽게 볼 수 있도록 대시보드를 만들었어요. 팀원들이 원하는 데이터를 데이터 분석가에게 따로 요청할 필요 없이, 새로운 데이터들이 있을 때마다 실시간으로 지속적으로 모니터링을 할 수 있습니다. (다른 회사들에 비해 지그재그 팀이 데이터를 공유받는 것에 대한 특이점이 있다고 하던데요!)성운 : 데이터는 누구나 다 쌓을 수 있지만, 양도 양이고 사용할 수 있을 정도로 가공해서 핸들링하고 있는 회사들이 많지 않을 것 같은데요. 데이터를 분석하고 모니터링할 때, 쉽게 볼 수 있는 tool(ex. GA..)들이 있는데 우리 지그재그 팀원들은 데이터를 보고 싶어 하는 needs가 tool의 영역을 벗어났어요. 알고 계시겠지만, 우리 지그재그 팀원분들은 정말 전문적이고 꼼꼼한 분들이거든요. 보고 싶어 하는 데이터가 굉장히 디테일해요. (웃음) 그래서 저희가 직접 대시보드를 만들기도 했고요. 특히 최근에는 데이터 엔지니어 분들이 많이 합류하시면서, 팀원들의 needs를 충족시킬 수 있는 데이터 인프라 구축 속도가 더욱 빨라지고 있어요. Q. 두 분이 생각하시는 데이터 분석 과정에서 가장 중요한 건 어떤 걸까요?인성 : 문제 해결이 가장 중요한 것 같아요. 명확한 문제 인식과 분석 없이 데이터를 보기만 한다면 표류할 가능성이 높아지거든요. 아무래도 데이터가 방대하게 존재하다 보니 파악할 때도 여러 방법을 사용할 수 있는데요, 중요한 것은 그 데이터에 어떤 의미를 담을 수 있고 어떻게 활용할 수 있는지 하나로 연결이 되어있어야 한다고 생각해요. 연결고리처럼? 탐색만 한다고 해서 우리가 찾는 인사이트는 바로 나오기 어려우니까요.성운 : 데이터를 보고 생각만 하는 게 아니라, 가설을 수립하고 목적이 명확하지 않으면 데이터를 봤을 때 일희일비하거든요. 어떤 날은 데이터가 올라가기도 하고, 내려가기도 하니까요. 왜 그랬는지 저희가 알아내야 하고, 어떤 결론을 내고 싶고, 그 결론을 내기 위해 어떤 준비를 해야 하는지 사전에 기획되는 부분이 중요하다고 생각합니다. 저희 팀 안에서 맞추는 것뿐만 아니라, 실제 현업에서 쓸 분들과 함께 얘기하면서 가설을 맞춰야 원하는 데이터를 얻을 수 있어요.Chapter 3. 업무와 일하는 방식Q. 두 분이 추구하시는 업무 방식을 각자 키워드 형태로 말씀해주신다면요?인성 : 저는 속도와 공감이요! 속도는 현재는 잘 지키지 못하고 있지만.. 완결을 보기 위해 무조건 빨리 한다기보다는, 커뮤니케이션을 위한 반복을 빠르게 하는 걸 추구하고 있어요. 공감은 협업하는 파트너와 문제 인식에 대해 공감하기 위해 노력해요. 예를 들면 제가 생각했을 땐 이게 문제가 될 수도 있다고 생각이 들 때가 있는데, 그럴 때 '다른 식으로 해봐도 괜찮지 않을까요?'라고 제안을 드려볼 수도 있고요. 실제로 데이터를 확인해서 그 파트너가 납득할 수 있게 확인을 해드리고 싶달까? 그러려면 우선 서로 말이 잘 통해야 하고, 공감이 필요한 것 같아요.(그럼 인성님은 공감을 위해 시도하는 인성님만의 방식이 있으신가요?)인성 : 사전에 얘기를 많이 나누어보려고 하는 편이에요. 어떤 데이터를 요청하셨을 때, 이 데이터로 어떤 결과를 보고 싶고 어떤 결정을 내릴 건지의 과정을 위한 시간 확보를 하려고 합니다.협업의 하이파이브!성운 : 음.. 저는 키워드를 하나 뽑자면, 재현 가능성을 중요시하는 것 같아요. 제가 한 분석이 인성님이 분석한 것과 같아야 하고, 또 그걸 항상 생각하다 보니 어떤 분석을 할 때 선입견이나 편견, 베이스 등이 없다는 전제로 시작하려고 합니다. 기본적인 것부터 하나하나 발판을 쌓아가듯 체크를 해보거든요. 빌드업 과정이랄까?탑을 쌓는 과정이라고 치면, 뭔가 문제점이 생겼을 때 무너트리고 다시 만들어야 할 때가 있을 수 있잖아요. 그때 발판을 좀 쌓아두면, 다시 시작할 수 있는 시작점이 탄탄하게 있으니 맨 처음으로 돌아가지 않아도 되거든요!Q. 현재 각 팀에서 데이터 분석가가 진행하고 있는, 그리고 앞으로 진행하게 될 업무에 대해서 설명해주세요.성운 : 커머스 UX팀에서는 전반적인 AB테스트와 실험 설계들을 해주실 텐데, 어떤 유저들을 대상으로, 성과를 어떻게 낼 건지 그리고 그 성과를 어떻게 해석하고 공유할 것인지에 많이 집중하게 될 것 같아요. 이번에 개편되는 1 탭(접속 시 보이는 첫 페이지)도 담당해주실 거예요. 그리고 Z결제팀에서는 결제 이후의 경험을 편하게 하기 위한 여러 기능이 들어갈 예정인데요, 셀러에게 데이터 관련된 인사이트를 제공하는 것도 저희와 같이 고민해볼 것 같아요.인성 : Growth팀에서는 유저나 거래액 부분에서의 분석을 주로 진행할 예정이고, 크게는 맵을 2가지 만들어본다고 보시면 될 것 같아요. 첫 번째는 유저 관점의 맵이고, 이 유저들이 지그재그 안에서 어떻게 행동하는지에 대해 살펴볼 예정입니다. 두 번째 맵은 셀러 관점의 맵인데 나중에 어떠한 셀러들이 어떻게 판매하는지에 대해서도 함께 살펴보면 좋을 것 같아요.Q. 데이터 챕터에서는 어떤 사람을 찾고 있는지 설명해주세요!성운 : 저는 간단합니다. 셀프 동기부여가 강하고 문제 해결 과정의 어려움을 즐기시는 분이면 좋겠어요. 데이터 커리어를 고민 중이시라면, 저희 지그재그 데이터 챕터로 오세요!인성 : 데이터 그 자체뿐 아니라, 데이터가 눈앞에 들어오기까지의 흐름과 맥락에 관심을 가지고 이를 분석에 활용할 수 있는 분이면 너무 좋을 것 같아요. 또 저희 챕터는 협업을 중요시하다 보니, 나와 전문영역/배경지식이 다른 분의 이야기를 경청하고, 낮은 진입장벽의 데이터 커뮤니케이션을 펼칠 수 있는 분이면 좋겠습니다.Chapter 4. 마무리Q. 곧 지그재그 앱이 개편된다고 하는데요! 간단히 설명해주세요!인성 : 지그재그 앱의 가장 핵심인 1 탭(첫번째로 보여지는 페이지)이 변경될 예정이에요. 개인적으로는 지그재그 팀에 온 후로 지금의 1 탭을 함께 만들었던 것이 가장 큰 성과 중 하나였었는데, 이번에 1 탭이 더 편하게 바뀐다는 건 굉장히 큰 의미로 와 닿네요. 성운님과 함께 고민하다 보니 더욱 고도화된 버전으로 개편할 수 있게 된 것 같아요!성운 : 유저들이 더 편하게 맞춤형으로 지그재그 앱을 사용할 수 있도록 변경될 예정이에요. 많은 기대 부탁드립니다!곧 개편될 1탭 기대해주세요! :-)Q. 두 분의 2020년 목표가 있을까요? 지그재그와 함께 이뤄내고 싶은 목표!성운 : 저희 데이터 챕터에 좋은 분들을 많이 모셔서 재미있는 데이터 프로젝트들을 많이 진행하고 싶어요. 또, 이미 하고 있긴 하지만 지그재그 내에서 진행한 데이터를 활용한 사례들을 외부에 알리고 소개하고자 노력할 예정입니다.인성 : 데이터 챕터 구성원 분들과 커머스 도메인의 전문성을 키우고, 이를 바탕으로 지그재그 고객에 대한 가치 있고 심도 있는 이해를 쌓아나가고 싶어요!지그재그에서는 데이터 분석가를 포함하여 활발하게 채용을 진행하고 있습니다. 지그재그 팀과 함께, 수면 아래 숨겨진 가치를 찾아내는 경험에 동참할 팀원을 꼭 모시고 싶습니다 :-) 궁금하신 점은 언제나 [email protected] 또는 http://facebook.com/zigzagcareer로 연락 주세요!지그재그 [데이터 분석가] 포지션을 소개합니다!이런 일을 합니다.이런 분을 모십니다.    - 개인화/추천 리서치 및 관련 로직과 평가지표 개발    - 로그설계, A/B테스트 설계 및 운영, 성과분석    - 데이터 분석 방법론(AARRR, Cohort, Funnel)에 대한 높은 이해를 바탕으로 한 문제 해결이 중 하나라도 가능하시다면 더더욱 좋아요 :)지원 방법채용 절차혜택과 복지   더 많은 공고는 채용 사이트에서 확인 가능합니다! >>> 채용 사이트 바로가기
조회수 2516

사운들리 코드 품질 관리 이야기

안녕하세요 "사운들리"입니다 :)오늘은 사운들리의 코드 품질 관리에 대해 이야기 해보려 합니다.몇몇 개발자에게는 지루하고 악몽같은 이야기일 수 있겠네요.제 경우에는 예전에는 이런 품질이라는 단어를 멀리했지만 결국 제가 작성한 코드에 발목을 많이 잡히다 보니, 자연스레 관심을 갖게 되었습니다.일단, 어떤 소프트웨어가 좋은 품질의 소프트웨어일까요?좋은 품질이란? 책에 나올법한 내용을 보면, 아래와 같은 항목을 토대로 소프트웨어 품질을 판단한다고 합니다.ISO/IEC 9126 : Software engineering - Product qualityFunctionality: 명시된 요구사항을 잘 충족했는지Reliability: 명시된 조건과 시간 아래에서 일정 성능을 유지 하는지Usability: 사용하기 위해 어느정도의 노력과 자원이 필요한지Efficiency: 소모 자원과 성능간의 효율Maintainability: 수정하기 위해 어느정도의 노력이 필요한지Portability: 다른 환경에서도 사용 할수 있는지출처: https://en.wikipedia.org/wiki/ISO/IEC_9126 뭔가 복잡해 보이지만, 결국 개발자라면 위의 항목은 누구나 추구하게 되는 가치라고 생각 합니다.그런데 말입니다. 이런 좋은 내용을 마음 속으로만 간직한 채 코드를 작성하면 정말 좋은 소프트웨어를 만들 수 있을까요? 저는 객관적인 방법으로 코드를 평가한다면 좋은 피드백이 될 것이라고 생각합니다. (물론 이 성적표를 남에게 보여주는 것과는 다른 문제에요 ㅎㅎ)어떻게 품질을 체크하는가 소프트웨어의 품질을 체크하는 데에 다양한 방법과 툴이 제시되고 있는데요, 저는 크게 두 가지로 분류 해보겠습니다.유저 입장의 품질: 유저의 요구사항에 맞는 소프트웨어인지 체크개발자 입장의 품질: 내가 지금 이 코드를 의도한 대로 잘 작성하고 있는지 체크 유저 입장의 품질은 언급하지 않아도 중요함을 누구나 알고 있습니다. 이 부분이 만족이 되지 않으면 제품이 아니죠! 그래서 저는 개발자 입장에서 스스로 챙길수 있는 품질을 사운들리는 어떻게 챙겨보고 있는 지 이야기 해보도록 하겠습니다. 실은 제가 개발자 입니다 ㅎㅎ사운들리 개발자의 코드는 아래와 같이 흘러갑니다.<그림1> 사운들리 코드 개발상의 품질 관리 순서도간단히 각 항목을 훑어 보겠습니다.Local Machine 각자 갖고 있는 맥북으로, 다양한 IDE를 사용해 코딩합니다. 그리고 git 을 이용해 commit 하고, github 에 push 하죠.Github push 된 수정사항은 pull request 를 통해 동료에게 알려집니다. 이후 코드리뷰를 통해 merge 하게 됩니다. 코드리뷰는 많은 사람들에 의해 그 중요성이 부각되고 있습니다. 사운들리는 같은 모듈을 만드는 개발자끼리, 그리고 다른 모듈에 영향을 주는 코드일 경우에는 해당 모듈의 개발자도 리뷰를 합니다. 코드리뷰를 통해 다른 사람이 어떤 기능을 작성했는지 보고, 오류도 찾고, 더 좋은 방법이 있으면 공유도 하고, 칭찬도 하고, 훈수도 두고 합니다. 참고로 사운들리는 git-flow 정책에 따라 git branch를 운영하고 있습니다.Jenkins  Github 에 commit 이 등록되면 Jenkins 는 자동으로 빌드를 시작 합니다. Jenkins 는 단순 빌드 성공 실패를 떠나서, 코드 품질에 대한 몇가지 report 를 발생 시킵니다. 아래에서 좀더 자세히 다뤄보겠습니다.SonarQube Jenkins 에서 빌드하면서 SonarQube 에 포함된 분석 기능을 사용하게 됩니다.그렇다면, 코드 품질의 지표는 무엇일까요?Jenkins가 발생시키는 레포트를 통해서 알 수 있는 내용은 아래와 같습니다.코딩 스타일 체크 결과: 작성된 코드가 미리 정의된 코딩 스타일에 맞게 작성되어 있는지?Unit Test 결과: 유닛 테스트 결과 (당연히 전부 pass 해야겠죠)Test code coverage 결과: 테스트 코드가 전체 코드의 몇 % 를 커버 하고 있는지 (우리의 최종목표는.. 60%.. 덜덜덜)정적 분석 결과: 코드를 실행하지는 않지만, 코드 그 자체에서 발생할 수 있는 결함을 찾아줍니다. 이 네 가지 레포트는 객관적 수치를 나타내주기 때문에 일종의 코드 품질 지표로 삼을 수 있습니다. 물론 이 지표만 잘 관리 했다고 해서 좋은 코드를 작성했다고 말할 수는 없습니다. 다만 좋은 코드를 작성하기 위한 기초 중의 기초라고 볼 수 있겠죠 :)품질 체크를 위한 툴(tool)은 개발 언어에 따라 다를 수 있습니다. 사운들리에서는 다양한 언어로 소프트웨어가 작성되어 있습니다. 따라서 언어마다 위의 결과를 얻기 위해서 서로 다른 툴을 사용하고 있습니다. AndroidJavaJavascriptC/C++코딩 스타일checkstylecheckstyle jshintcppcheckUnit testjunitjunitmochagoogletestCode coveragejacococoberturamocha-covgcov정적 분석sonarqubesonarqube sonarqubecppcheck 각 개발자는 위의 네 가지 결과를 얻기 위해서 빌드 시스템에 툴을 포함하여 개발하고 있습니다. 제가 주로 개발하고 있는 java 언어에 해당하는 툴들을 좀 더 자세히 살펴보겠습니다.checkstyle코딩 스타일을 체크 해줍니다. xml 파일로 미리 정의 되어있고요. 매번 빌드할때마다 스타일이 틀린것을 지적해 줍니다.코딩 스타일은 중요합니다. 같이 개발하는 개발자와 코딩 스타일이 같다면 마치 내가 작성한 코드처럼 쉽게 읽을 수 있죠.junitjunit 은 자바 유닛 테스트 프레임워크 입니다. 유닛 테스트 코드를 편하게 작성하게 해주고, 쉽게 테스트 결과를 볼 수 있습니다.유닛 테스트 코드를 작성하면 내가 작성한 모듈을 작은 단위로 테스트 해서, 작은 로직에서 발생하는 시시콜콜한 문제를 방지 할 수 있습니다. 테스트 코드를 작성해서 검증한 부분은 스스로도 신뢰가 갑니다.기능 수정간에 유닛 테스트에서 fail 이 나는 경우가 발생하는데, 모르는 사이에 다른 모듈에 영향을 준 것을 알게 됩니다. 다른 모듈에 모르고 영향을 주게 되면 뒷처리가 어려워지잖아요~coberturacode coverage 를 계산해 주는 툴입니다.유닛 테스트 코드가 실행되면, 작성된 코드의 각 부분을 실행하게 됩니다. cobertura 는 이때 각 코드의 어느부분이 실행되었는지 확인해서 통계를 내줍니다.주로 line coverage / branch coverage 두 지표를 보는데요, line coverage 는 해당 라인이 한번이라도 실행 되면 check 되고, branch coverage 는 각 라인에 있는 조건문을 다 따로 check 합니다. 당연히 branch coverage 를 달성하는게 어렵겠죠?sonarqube소나큐브는 다양한 plug-in 을 통해서 정적 분석을 하고, 시각화를 해주는 툴입니다.사운들리는 주로 정적 분석 용도로만 소나큐브를 사용하고 있습니다. (지원하는 plug-in 을 보면 젠킨스와 기능이 겹치는 부분이 있습니다.)정적분석으로 실제 문제가 되는 부분을 찾는 경우도 있고, minor 한 부분에 대한 지적을 하는 경우도 있습니다. 그러나 이런 minor 한 부분도 꼼꼼하게 잘 챙겨야 좋은 개발자가 된다고 믿고 있습니다.마치며 여기까지 사운들리의 코드 품질 관리에 대해 이야기 해보았습니다. 품질 관리를 해보신 분은 아시겠지만, 이런 툴을 쓰다보면 항상 행복하게 코드 품질을 관리할 수는 없습니다. 매달 세워놓은 목표를 달성하기 위해서 뼈를 깎는 노력으로 테스트 코드를 작성해야 되고, 당장 기능 수정해서 배포해야 되는데, 작성해 둔 테스트 케이스가 Fail 되어 말썽을 부릴 수도 있습니다. 그렇지만 객관적 기준으로 코드 품질을 관리하다보면 어느샌가 큰 노력없이 좋은 코드를 작성하는 개발자가 되지 않을까 생각해 봅니다. 코드 졸면서 막 짜도 style warning 0건/ 정적분석 오류없음 / 테스트 코드 기본 탑재 뭐 이런 개발자 말입니다 ㅎㅎ 다른 개발자분들은 어떻게 자신이 작성한 코드의 품질을 관리하고 있는지 궁금하네요.알고 계신 좋은 방법이 있다면 언제든지 공유 부탁드리겠습니다~!#사운들리 #개발자 #개발 #인사이트 #조언 #개발후기 #후기

기업문화 엿볼 때, 더팀스

로그인

/