스토리 홈

인터뷰

피드

뉴스

조회수 34190

소규모팀에 적합한 QA 프로세스 구축기(스타일쉐어팀의 QA방식)

안녕하세요. 스타일쉐어에서 PM을 맡고있는 박성환 입니다. 스타일쉐어팀이 QA프로세스를 도입한 것은 약 4개월 정도 되었습니다. 기존에는 QA 프로세스 없이 진행했었지만 주요 기능에 대한 오류감소 및 릴리즈 안정성 확보를 위해 도입을 고민하게 되었습니다.QA프로세스를 처음 도입할때 많은 고민이 있었습니다. 대규모 서비스에 적용하는 QA프로세스를 그대로 도입하기에는 인력 + 시간이 모두 부족했기에 시간과 인력이 많이 투여되는(다만, 안정성이 높음) 명세기반 테스트는 최소화하고, 도입 가능한 서비스(구글플레이의 단계적 배포, Crashlytics)를 활용해 부족한 부분을 커버하는 형식으로 저희 식의 간략화된 QA프로세스를 만들었습니다.(인력 + 시간이 상대적으로 제한적인 스타트업에 좀 더 효율적인 방식.)스타일쉐어팀의 QA 기간 : 앱 업데이트 당 3일(테스트/수정/릴리즈까지의 모든 기간)테스트 인원 : 2명 (1차QA 1명, 최종확인 1명)마이너 버그 수정 버전에서는 QA진행하지 않음스타일쉐어팀의 QA프로세스는 “주요 사용 케이스의 동작 확인” + “수많은 사용 패턴에 대한 대응”으로 정리할 수 있습니다. 저희 팀이 진행하고 있는 방식을 조금 더 자세히 설명해 드리자면 아래와 같습니다.(API 테스트, 자동화 테스트를 제외한 앱 릴리즈 전 진행하는 사용성 테스트에 대한 내용만을 담았습니다.)1. QA일정스타일쉐어 앱의 업데이트 주기는 4주에 1회로 진행하고 있습니다. 그 중 1주 단위의 스프린트가 3주 동안 진행되고 4주차 스프린트는 QA 및 릴리즈 스프린트로 진행됩니다. 매 스프린트에서 담당 엔지니어가 수정 혹은 추가된 단위기능에 대해 간단한 테스트가 끝나면 4주차에 알파 빌드 및 전 구성원이 설치/사용해보고 동시에 1차 QA(통합 테스트)를 진행하게 됩니다. 1차 QA의 버그들을 수정하면 베타버전 빌드 및 최종 확인을 진행한뒤 문제없으면 바로 릴리즈가 되어 사용자에게 신규 버전을 제공합니다.2. 주요 사용 케이스의 동작 확인1) 1차 QA(명세기반 테스팅)4주차에 신규 알파버전이 생성되면 1차 QA를 진행하게 됩니다. 스타일쉐어는 전담 QA담당자가 없습니다. 1차 QA는 다른 파트 엔지니어 1명이 테스트를 진행하고 2차는 PM이 최종확인 후 릴리즈 됩니다. 이 단계에서는 Test case를 바탕으로한 명세기반 테스트로 진행됩니다.테스트 케이스(TC)를 통한 테스팅은 핵심적인 기능 및 주 사용케이스에 대한 검수작업이라고 보시면 됩니다. 게임 혹은 복잡도가 높은 서비스의 경우에는 매 업데이트마다 모든 케이스에 대한 테스트가 어렵고 비효율적이기 때문에 리스크 분석기법, 탐색적 테스팅, 경계값 테스팅 등과 같은 방식을 사용하지만 스타일쉐어 서비스의 경우 상대적으로 복잡도가 낮아 매 업데이트 마다 대부분의 기능에 대한 테스팅을 진행합니다(TC로 100% 커버리지를 목표로 하지 않습니다. 불가능하다는 것을 인정하고 진행하는 것이 효율적). 테스트케이스 작성시에 유의했던 부분은 쉽고 명확하게 케이스를 명시해서 오류에 대한 판단이 명확하도록 하고 스타일쉐어 앱을 처음 본 사람도 바로 테스트가 가능하도록 작성하고 있습니다. (스트레스 테스트는 특이 사항이 있을 경우에만 진행합니다.)2) 교차 테스팅스타일쉐어의 경우에는 1차QA 과정을 담당 엔지니어가 아닌 다른 파트의 엔지니어(iOS버전 테스트의 경우 web, backend, Android 개발자 중 1명이 진행)가 1차 테스트를 진행합니다. 이 방식의 장점은 매번 같은 사람이 테스트하는 것보다 다른 백그라운드를 가진 엔지니어가 테스트 함으로써 다양한 시각으로 테스트를 하게 되 오류발견이라던지 서비스 개선 아이디어를 찾는데 더 효과적이었습니다. 그리고 신규 입사자의 경우 가장 먼저 테스트 담당자로 참여할 수 있도록 합니다(가장 빠르게 서비스 플로우를 이해할 수 있는 방법).3) 최종확인1차 QA 및 전사 베타버전 사용의 피드백을 통해 나온 버그/주요 기능에 대해 마지막 점검하는 절차입니다. 이 부분은 제품책임자(PM)가 담당을 하며, 이 부분을 통과하면 릴리즈 단계로 진행되어 사용자에게 업데이트 된 앱이 전달됩니다.3. 수많은 사용 패턴에 대한 대응단계적 출시(안드로이드)1차 QA과정인 테스트케이스를 통한 테스팅은 명시되어 있는 패턴과 제한적인 환경(Device, 해상도, 인터넷 환경 등등)에서의 주요 케이스에 대한 테스팅만 가능합니다. 하지만 사용자는 수많은 환경 및 사용패턴으로 서비스를 사용하기 때문에 이 부분을 TC의 스크립트로 모두 추가하고 살펴보기란 불가능에 가깝습니다. 그래서 저희 팀은 단계적 출시를 도입해서 대응하고 있습니다.모든 테스트 과정을 완료한 뒤 구글플레이 개발자 콘솔에서 앱 업데이트시 ‘지금 출시’가 아닌 ‘단계적 출시’로 선택합니다. 그리고 비율을 선택할 수 있는데 이 비율은 업데이트가 적용되는 사용자 비율을 설정하는 기능입니다. 즉, 전체 사용자가 아닌 미리 지정한 비율의 사용자에게만 업데이트 버전을 제공함으로써 우선적으로 우리가 예상하지 못한 버그나 불편한 부분이 있는지 확인해볼 수 있습니다. 스타일쉐어팀의 경우 5%의 사용자 비율로 단계적 출시를 1~2일 동안 진행한뒤 버그 리포팅 및 CS내용 확인 후 100% 대상으로 업데이트를 진행합니다.(5% 단계적 출시 이후 패치된 버전을 배포하면 해당그룹(5%)에게만 업데이트 됩니다.)이 부분은 오류에 대한 대응 및 새로운 기능에 대한 부분적인 반응을 볼 수 있는 용도로도 사용할 수 있어 매우 활용도가 높습니다.(신규 앱에 대해서는 해당 기능 사용이 불가능합니다. 업데이트시에만 사용가능합니다.)4. 도입효과1) Crash Free Sessions(Crashlytics)4월 13일 기준으로 Crash Free Sessions는 전체 사용자 중 99.8%의 안정성을 가져가고 있으며(이전에는 95~96%), 기존에는 주말과 같이 사용자가 많은 경우 그만큼 크래시 발생빈도도 높았지만 최근 버전에서는 주말/평일 관계없는 그래프를 보이고 있습니다.2) Crash Report(Flurry)위 지표는 1월~3월 까지의 Flurry의 안드로이드 버전 Crash Report를 캡처한 화면입니다. 1월 초만 해도 일 40회 정도의 크래시가 발생했다면 최근은 일 3~5회 정도로 개선된 모습을 확인할 수 있습니다.5. 마무리다만, 이러한 노력에도 버그는 여전히 존재합니다. 그래서 저희 QA프로세스도 개선할 방향을 모색하고 있는데, 현재의 개선 목표는 ‘퀄리티는 유지하되 속도는 빠르게’ 라는 방향으로 진행 중입니다. 그물을 더 촘촘히 짜듯이 명세기반 테스트의 규모를 늘리는 것에는 시간적/효율적인 한계가 분명히 존재하므로 자동화 테스팅(UI)의 강화를 통해서 부족한 부분을 채워보기 위한 시도를 준비하고 있습니다.하루라도 빠른 서비스의 개선도 매우 중요하지만 그만큼 우리가 전달하고자 하는 것을 문제없이 사용자에게 제공하는 것도 속도만큼 중요하다 생각 합니다. 문제없이 전달하기 위해 계속해서 고민하고 시도해볼 수 있도록 하겠습니다.#스타일쉐어 #개발 #개발팀 #개발자 #노하우 #인사이트
조회수 2672

MOIN 안드로이드 개발자를 소개합니다

영화 같은 일들이 매일같이 벌어지는 요즘 모두들 안녕하신가요?해외송금 스타트업 모인에게 최근 새로운 변화가 생겼습니다.안드로이드 개발자가 합류했습니다.어떤 분인지 지금부터 소개 해드리겠습니다 ^^안드로이드 개발을 해주실 효찬님!- Professional Experience -2015.01~2016.10 kt R&D 연구개발센터 전임연구원2013.07~2015.12 kt R&D 연구개발센터 연구원2013.03~2013.06 kt R&D 연구개발센터 인턴- Education -2006.03~2013.08 고려대학교 컴퓨터통신공학부 학사2001.09~2005.05 Jakarta International School▶ 모인에서 어떤 일을 담당하고 계신가요?총체적인 안드로이드 개발과 웹 서버를 보조하는 일을 맡고 있습니다.▶ 개발자가 되겠다고 한 계기가 궁금합니다. 개발자로서 이력에 대해 간략히 설명해주시겠어요? 특정한 계기가 있어서 개발자가 되겠다고 한 건 아니었어요. 고등학교 시절, 컴퓨터 게임 하면서 막연히 나도 게임을 만들어 보고 싶다고 생각했고 그래서 관심은 가지고 있었죠. 친구들 이름 넣어서 RPG를 만들어보기도 했는데, 생각해보면 스토리 만들기가 재밌었던 거 같아요. 그러면서 자연스럽게 어떻게 하면 컴퓨터 개발할 수 있나 생각도 해보게 됐고, 책도 뒤적여보게 됐습니다. 이런 생활이 고2때까지 이어졌어요. 그런데 마땅히 공부할 수 있는 방법이 없어서 대학가서 해야겠다 생각했습니다. 대학 와서 본격적으로 컴퓨터공학을 공부하면서 재미를 느끼게 됐어요.▶ 그 중에서도 안드로이드 개발을 선택하게 된 이유는 뭐였을까요?예전에 KT에 있을 때, 안드로이드 개발 프로젝트를 맡으면서부터입니다. 원래 이 분야에 대해 전혀 몰랐는데 회사에서 3일간 안드로이드 개발 교육을 받고 해보라는 지시를 받게 된거죠. 막상 해보니 재밌었어요. 특히 이 시기가 2014년 초였는데, 당시에는 안드로이드가 워낙 인기 있는 분야여서 더욱 할만하겠다는 생각을 하게 됐습니다. 효찬님이 선보인 안드로이드 앱 (왼부터)가계부투게더, 메모캐스트, 돈테크 ▶ 본격적으로 모인에 들어오게 된 이야기를 들어보고 싶습니다. 어떻게 모인을 알게 되셨나요?이전 회사에서 늘 입버릇처럼 ‘스타트업을 하고 싶다’는 말을 하고 다녔습니다. 생각해보면 제가 굉장히 밉상이었을텐데 주변 회사분들이 응원을 많이 해주셨어요. 정말 좋으신 분들입니다. (하하) 지인 추천으로 원티드를 알게 됐어요. 저는 초기 단계에 있는 스타트업에 가고 싶었는데 쉽게 찾기는 힘들더라고요. 이후 설립한지 1년도 안 된 ‘모인’을 찾게 됐습니다. 회사에 대해 이것저것 찾아보고 한 번 만나서 이야기해보면 좋겠다는 생각이 들어 대표님을 만났어요. 대표님과 만나 이야기를 나누어 보니 같이 일하고 싶었습니다.  ▶ ‘스타트업을 하고 싶다’는 말을 입버릇처럼 하셨다고 했는데, 특별한 계기가 있었나요?대학 때, 그래픽 프로그래밍 관련 Term Project를 수행했던 적이 있었어요. 이 때 친구들과 밤을 새면서도 웃고떠들며 프로젝트를 해낸 게 제겐 정말 좋은 경험이었습니다. 친한 친구들과 같이 일을 하면 힘든 업무도 웃으면서 즐겁게 할 수 있다는 생각이 들었어요. 앞으로도 좋은 사람들과 같이 즐겁게 일할 수 있으면 좋겠다는 생각을 가지게 되었죠. 스타트업에서 근무하면 일과 동시에 좋은 조직문화를 만들어나갈 수 있을 거라고 생각했어요.  ▶ 개발자로서 자신 있는 영역이 무엇인가요?두루 다룰 줄 안다는 게 제 장점일 수 있겠네요. 그래서 스스로 찾아가면서 어떤 서비스든 개발할 수 있다는 자신이 있습니다. 하지만 역시 한 분야에 대한 전문성은 좀 부족하지 않나 생각해요. 안드로이드에 더더욱 집중해보려고 노력한 이유이기도 합니다. 앞으로도 저만의 차별점을 발굴하는데 계속 노력을 기울일 생각입니다. 효찬님이 가장 애착간다는 원피스 '상디'▶ 개발 외 관심 있는 영역이 무엇인가요?개발 외적으로는 조직 문화에 관심이 많습니다. 제가 개인적으로 일본 만화 ‘원피스’를 좋아해요. 루피 해적단을 보면 개개인이 발전하면서 동시에 팀이 강해지는 모습을 볼 수 있거든요. 어떠한 모험도 할 수 있을 정도로 강해지죠. 루피 해적단 같은 조직을 꿈꿉니다. 어떻게 보면 제가 꿈꾸는 조직 문화가 담겨있다고도 할 수 있죠.특히, 배트맨을 보면 악당이 배트맨 지인을 인질로 잡으면 배트맨은 지인을 구하러 가죠. 하지만 원피스에서는 악당이 루피 친구들을 인질로 잡으면 루피는 친구를 구하러 가지 않아요. 다만, 친구가 함정에서 알아서 잘 나올거라 믿습니다. 그리고 악당을 쓰려트려야 하는 자신의 역할을 수행하는 데 충실해요. 동료를 믿기 때문에 가능한 자세라고 생각해요. 제 나름대로 ‘믿음의 리더십’이라고 혼자 정의해봤어요. (웃음) 대신 내 능력은 스스로가 키워나가야 하죠. 이렇게 각자 자신의 일에 최선을 다하는 사람들과 함께 큰 꿈을 이루는 게 지금 제게 마지막으로 남아 있는 순수한 이상입니다.▶ 더 키워나가고 싶은 역량이 있나요?역량이라기 보다는 제가 만든 작품을 Developing 해나가고 싶어요. 발전가능성이 없는 서비스는 더 이상하고 싶지 않습니다. 내가 만든 앱을 상용화 시키고, 고객들이 반응하는 걸 직접 보고 싶어요. 더불어 서비스 개선에 필요한 역량은 지속적으로 키워나가려고 합니다.장효찬 개발자에게 '함께 일하고 싶은 사람'이란?#온정 #진솔 #파이팅 ▶ 출근한지 일주일도 안됐지만 (웃음) 모인에 대한 첫인상은 어땠어요?정말 아직 1주일도 안됐는데…. (웃음) 대기업에 있다 와서 그런지 소위 ‘젊음의 열정’이라고 하죠? 다들 파이팅 넘치는 모습이 좋았습니다. 그러면서 동시에 나 잘났다고 으스대지도 않고, 특히 대표님 같은 경우는 능력도 있으신데, 겸손하기까지 해서 반했어요. 무언가를 물어보면 설명도 친절하면서 꼼꼼하게 해주시구요. 팀워크가 좋을 거 같다는 긍정적인 예감이 들었어요. 사람 뽑는 데 신중하시다는 대표님을 믿으며, 앞으로도 잘 부탁드립니다.  ▶ 앞으로 어떤 개발자가 되고 싶으신가요? 모인에게도 한마디 해주세요.개발 PM(Project Manager)에 관심이 많습니다. 사실 앱 구현보다 뼈대를 구축하는 일이 더 중요하다고 생각해요. 저는 이 부분이 개발에서 30% 혹은 그 이상을 오롯이 혼자 차지하고 있다고 생각해요. 그러기 위해서는 리소스나 구현한 코드를 어떻게 관리할까, 어떤 부분을 어떻게 더 추가를 해서 연동시킬 수 있을까 등을 서비스 앱 전체를 보고 관리할 줄 알아야 하죠. 이 역할이 국내에서는 중요하게 다뤄지는 거 같지 않아 안타깝습니다. 대부분 보이는 것에만 관심을 가지고 제품이 어떤 제질로 만들어졌는지는 큰 관심을 가지지 않는 추세거든요. 저는 이러한 부분을 중요시 여기는 개발자가 되고 싶습니다. “저를 버리시면(?) 아니됩니다 (웃음)”- 장효찬이 꼽은 인생 명언 -“Do what you love. Everything else is secondary”by. Steve Jobs#모인 #MOIN #개발자 #개발팀 #안드로이드개발자 #안드로이드 #팀원 #팀원소개 #팀원인터뷰 #인터뷰 #기업문화 #사내문화 #조직문화
조회수 3310

경험 부족한 스타트업의 devops 도입기 1편

개발과 운영을 함께 devops - 출처당분간의 일기 내용앞으로 몇 개월 간 신생 스타트업 I/O가 어떻게 devops를 자기네만의 스타일로 조직에 안착시켜 나가는지 그 시행착오를 생생하게 공유하는 일기를 쓰려고 합니다.첫 번 째 편인 오늘의 이야기는 두 가지 내용을 다룹니다.devops 도입배경: 어떻게 하다가 devops를 도입하기로 했는지 그 배경에 대에서 이야기 합니다.devops 필요성 인지: 가장 먼저 소프트웨어팀이 devops 필요성을 느끼도록 시도한 스터디 세미나에 관한 이야기를 합니다.devops 도입 도중에 실패할 수 있습니다. 그래서 1편이 마지막 연재일 수 있습니다. 혹은 온갖 개고생을 해가면서 결국 devops를 성공적으로 조직에 안착시켜 tech기업다운 모습을 갖출 수 도 있습니다. 정답은 시간이 얼마간 흐른 뒤에야 알 수 있겠죠? 무언가를 조직에 도입하는 스토리를 사후적으로 그러니까 프로젝트가 끝난 후에 쓰게된다면 프로젝트 과정의 생생함이 퇴색됩니다. 힘들었던 추억도 되돌아보면 미화되듯이 그 당시에 골치아팠던 일들을 그 당시에 써놓지 않으면 까먹을 때가 꽤나 많습니다. 한 편으로는 이렇게 칼자루를 뽑아놔야 반드시 devops를 성공시키기 위해 제가 더 처절해질 수 있을 것 같습니다. 제 나약한 마음이 바뀌지 않기 위해 devops 시작과 동시에 연재물도 함께 시작하겠습니다.devops 도입배경스위처 M 앱이 출시된지 약 한 달 정도 되었습니다.경영을 해오면서 항상 위기의식을 느끼고 있지만 이번에는 조금 심상치 않았습니다.“아.. 라이브서비스를 하기엔 현재 I/O의 소프트웨어 역량이 심각하게 부족하구나! 하드웨어 역량이 Critical Path일 줄 알았는데 되려 소프트웨어가 우리의 발목을 잡고 있구나..”그동안 하드웨어 멤버들은 초심자의 마음과 책임감을 동시에 갖고 무서운 속도로 성장해왔습니다. 새로운 버전의 스위처(M)에 적용된 기구설계 수준, Supply chain 관리 능력, 블루투스 모듈 성능은 이전 버전(W) 비할바가 안됩니다. 놀랄만큼 일취월장 했습니다. 단적인 예로 현재 스위처M의 블루투스 연결 거리는 오픈필드에서 70m이상 나옵니다. 이전 세대인 스위처W의 연결거리가 약 20m 미만임을 감안하면 연결성이 300%이상 좋아졌다고 볼 수 있습니다.반면 소프트웨어팀은 여전히 초보적인 수준을 벗어나지 못하고 있습니다. 전공분야라는 자만심에 소프트웨어를 밑도 끝도 없는 구렁텅이에 밀쳐 넣고있는 제 자신을 발견 했습니다. 창피했습니다. 가장 중요하다고 볼 수 있는 초기고객으로부터 어처구니없는 버그 리포팅을 받을때면 쥐구멍으로라도 숨고 싶었습니다. Customer Service역할까지 도맡아하는 마케터가 수 많은 컴플레인을 대응하느라 정말 고생이 많았습니다.심각한 문제는 소프트웨어팀이 문제의 원인이 무엇인지 조차 잘 모르고 있다는 사실이었습니다. 그저 열심히 다음 피쳐를 개발하기 위해 코드를 짜내는 데에만 자신을 몰아붙이고 있었습니다.그 모습은 한 편의 코메디 영화를 보는 것 같았습니다.<디버깅루프>(1) 배포한 기능에 버그가 처음으로 발견됩니다.(2) “엇 이상한데? 그럴리가 없는데?” 일단 현실을 부정하고 지켜봅니다.(3) 한 두 명의 문제가 아니라는 버그리포팅이 들어옵니다.(4) 부랴부랴 원인을 추측하고 핫픽스 코드를 짜기 시작합니다.(5) 개발을 마치고 일단 배포해 봅니다.(6) 그런데 해결될 줄알 았던 버그가 다시 보고됩니다.그렇게 상황은 2번으로 돌아가 이 디버깅루프를 몇 바퀴 돌고난 후에야 잠잠해집니다.하하… 개판이구나 — 출처:구글 이미지 검색허나 이미 많은 고객들이 불쾌한 UX를 겪고 난 뒤… 이대로는 도저히 구상하는 I/O의 큰 그림에 도달할 수 있을 것 같지 않아, 당분간 제가 CTO역할을 도맡아서 하려고 합니다. 벤 호로위츠가 쓴 Hardthing에서 C-level의 포지션이 비어있을 경우 진짜 적임자가 나타나기 전까지는 그 역할을 CEO가 직접 수행하기를 권장합니다. 이제까지 바쁘다는 핑계로 조직 부채, 기술 부채를 안고왔었는데 최근 Event3 사고를 겪으면서 이젠 이 부채들을 털어내고 나아가야 겠구나 결심하게 되었습니다. 직접 현장으로 다이빙해서 소프트웨어 엔지니어들과 함께 악전고투하기로 했습니다.린스타트업에서 말하는 5-why기법을 적용해보니. 근본적인 원인은 이것이였습니다.주먹구구식으로 Product Live service가 운영(operation)된다.엔지니어들의 코드 퀄리티가 낮아서가 아니었습니다. 알고리즘을 몰라서가 아니었습니다. 디자인 패턴을 몰라서도, 함수형 패러다임을 이해하지 못해서도, 동시성 문제를 몰라서도가 아니었습니다. 되려 I/O의 소프트웨어 엔지니어들의 CS 기본기는 나쁘지 않습니다. 저희는 엉클밥, 켄트백, 마틴파울러를 존경합니다.바보야, 문제는 코딩이 아니야!문제는 경제가 아니야, 바보야!저희 팀의 제일 큰 문제점은 그냥 예전 처럼 새로운 feature 코드를 찍어내는일이 Product Live service operation의 전부라는 사고방식입니다. 배포되는 코드가 얼마나 신뢰할만한지에 대한 고민은 전혀 없고 밀어내기식으로 다음 기능을 추가하는 데만 몰두했습니다. 실상 지금의 스위처에는 새로운 기능을 추가하기위해 코딩을 할때가 아니었는데 말이죠. 쿼리 속도를 높이기 위해 인덱싱을 고민 할 때가 아닌데 말입니다. 정작 Product Live service operation에 필요한 일들(tasks)을 수행하고 있지 않았기 때문에 이 문제가 발생한건데 말이죠.린스타트업의 MVP 관점을 포기하고 완벽한 제품을 내보낸다는 의미가 아닙니다. 그 Minimum Viable Product 조차 제대로 작동이 못시키는 문제를 바로잡기 위해서 입니다. 스크럼으로 조직 tasks를 관리해왔지만 소프트웨어팀은 devops로 거듭나야할 때가 왔음을 느꼈습니다.최소한의 검증 절차도 없이 버그가 담긴 소프트웨어가 고스란히 고객에게 전달되는 악몽을 더 이상 마주해선 안됩니다. 불편함을 겪는 고객을 위해서라도 경쟁력을 잃어가는 조직을 위해서라도 곁에서 힘들어하는 동료들을 위해서라도 소프트웨어팀은 변해야만 했습니다.devops 필요성 인지멤버들에게 제가 방금까지 이야기한 문제점을 전달하고 각자 devops가 무엇인지 공부하기로 했습니다. 일주일간 리서치를 마친 후 한 명씩 돌아가면서 devops가 무엇인지 발표하는 세미나를 진행했습니다. 결론부터 말해 devops 필요성에 대한 공감대 형성은 성공적으로 첫 걸음을 뗀듯 합니다. 모두들 세미나를 준비하면서 그동안 무엇이 문제인지 조차 모르는 상황은 벗어나 보였습니다. 한 명쯤은 “devops는 필요없습니다. 지금처럼 해도돼요!”라는 반응을 예상하기도 했는데, 모두가 겸손의 자세로 지금까지의 문제를 반성하고 변화의 필요성을 절감했습니다. 끊임없이 성장하려는 자세를 가진 I/O 멤버들에게 참 고맙습니다.우린 여기에서 어디쯤..?펌웨어 개발자는 우리의 현재 모습이 위의 그림에서 나오는 원숭이조차 안되는 것 같다고 고백 하기도 했습니다. 그만큼 I/O 소프트웨어팀은 변화를 갈망하는 단계로 무사히 넘어왔습니다. 성공적으로 devops의 필요성 공감대를 형성 시킬 수 있었던 요인은 slow-start 덕분인듯합니다. 초기 고객분들이 실험대상이 된것 처럼 말해 죄송하지만, 작은 규모로라도 Live를 진행하고 거기서 작게나마 사고를 치도록 내버려둔 환경이 devops의 필요성을 받아들이는 데 큰 역할을 했습니다.만약 처음부터 무리해서 스케일업을 시도했다면 그래서 감당할 수 없는 수준의 사고가 동시다발적으로 터졌다면 저희는 자멸하고 말았을 겁니다. 아니, 기다리는 많은 고객들의 기대감에 지레 겁먹고 최대한 소프트웨어 출시 일정을 늦췄겠죠. 그리고 그렇게 절벽에서 등 떠밀리듯이 제품을 출시해서 줄을 잇는 버그 리포팅을 받아보며 평정심을 잃고 말았을 것입니다. 그러나, 감당할 수 있는 수준으로 제품 판매수량을 조절했기 때문에 개발자가 문제를 직시해볼 기회를 가졌고 devops의 필요성은 조직에 쉽게 받아들여질 수 있었습니다.물론 devops 세미나를 진행하면서 안좋은 냄새(징조)를 맡기도 했습니다. 저에게는 행운이죠. 사전에 미리 문제를 파악할 수 있어서. 그 냄새는 도구만능주의 였습니다. devops 도달하기 위해서는 시중에 존재하는 다양한 tool들을 최대한 빠르게 도입해야 할것만 같은 느낌을 말합니다. devops tool들만 제대로 구축한다면 devops도 저절도 실현될것 같은 기대감에 젖습니다. 이 도구만능주의가 만연해지면 devops의 본질은 보지 못한 채 최신 tool 사용에만 집착하게되는 오류를 범하고 맙니다.다행이 I/O의 도구만능주의는 심각한 수준까진 아니고 누구나 초기에 충분히 실수할 수 있는 미약한 수준이었습니다. 사실 제가 예전 스타트업에서 스크럼을 도입할 때도 빠졌던 도구만능주의가 묘하게 겹쳐보여서 낌새를 비교적 빠르게 눈치 챌 수 있었습니다.출처 : 구글 이미지 검색devop는 문화와 운동(movement)입니다. 즉, 무형에 가까운 개념입니다. tool이 아니라 행위(action)와 사상(idea)에 역점을 둬야 합니다. tool은 그저 거들 뿐이죠.간단한 사고실험을 해보겠습니다. 모든 microservices의 설정들을 chef와 puppet으로 관리하고 뱀부나 젠킨스로 빌드-배포-리포팅 파이프라인까지 구축한 devops팀이 있다고 가정해 보겠습니다. 달리 말해, 이 팀은 커맨드 입력 한 번으로 방금 짠 코드를 고객에게 배포할 수 있습니다. 어느날 이 팀에 속한 개발자 A가 지난 일주일간 개발해온 피쳐를 지금 막 마무리 지었습니다. 이어서 A는 devops tool로 구축한 배포 파이프라인 이용해 아주 간단하게 새로운 기능을 업데이트 하기로 했는데요. 과연 괜찮을까요? 최신 devops tool로 중무장 했으니 문제가 없을 것 같습니다. 잠시 후 그렇게 배포된 기능을 써본 고객들이 컴플레인을 걸어옵니다. 잠시 화장실을 다녀온 엔지니어는 허겁지겁 hotfix 코드를 다시 짭니다. 그래도 괜찮습니다. A가 속한 팀은 최신 devops tool이 구축되어 있기 때문에 금방 hotfix를 재배포할 수 있으니까요. 그런데 이장면 어디서 익숙하지 않나요? 앞에서 소개한 디버깅루프와 비슷해 보입니다.출처 : 구글 이미지 검색과연 이게 devops일까요? tool들을 전부 사용하는게 진정 devops의 실현일까요?코드를 리뷰하지도 자동화된 테스트 코드를 실행해보지도 않은 상태에서 지속적 배포는 그저 똥을 더 자주 고객에게 전달하는 것과 다르지 않습니다.높은 품질의 제품은 보장할 수 없습니다. 그렇다면 우리는 무엇부터 해야할까요?Next Iteration저는 장황한 계획을 혐오합니다. 계획을 짜내느라 쏟는 에너지와 시간이 너무 아깝고 무엇보다 계획대로 진행될 확률이 낮기 때문입니다. 대신 저는 스타트업 환경에 맞는 방식으로 일하기를 선호 합니다. 비교적 긴 시간이 필요한 프로젝트 성격의 일을 할 땐 북극성의 위치만을 기억합니다. 쉽게 말해 우리가 산출해야하는 프로젝트 결과물만 생각합니다. 북극성까지 도달하는 정해진 길 따위는 없다고 가정합니다. 혹시 있었다 해도 그냥 잊어버립니다. 스타트업의 리스크는 워낙 변화무쌍하거든요.계획 대신 무던히 아래 두 가지 행동을 반복합니다.(1) 고개를 들어 몸이 북극성 향하도록 합니다.(2) 고개를 숙여 한 발짝 전진합니다.출처 : 구글 이미지 검색프로젝트가 끝날 때 까지 위의 두 가지 과정만을 반복하려고 합니다. 저는 이 과정을 baby step이라고 하는데요. 욕심내지 않고 작게 작게 한 번에 하나씩 차근차근 진행하는 방식입니다. 지금 내 딛은 한 걸음이 틀릴 수도 있습니다. 그러나 괜찮습니다. 한 걸음 나아간 다음에는 반드시 고개를 들어 내가 북극성과 가까워졌나 멀어졌나 확인하면 되거든요. 방향이 맞다는 판단이 서면 한 걸음 더 나아가고 틀린 예감이들면 방향을 조절하면됩니다. 만약 판단이 애매하면 더 끌리는 쪽을 택하면 됩니다. 단, 절대 바닥만을 주시한채 두 걸음 이상 걷지 않습니다.devops까지 도달하는 데 지름길은 전혀모릅니다. 하지만, devops라는 북극성은 저에게 명료하고 분명한 목표입니다. devops에 조금이라도 가까워지기 위해 지금 당장 해야하는 가장 중요한 일이 무엇인지 세미나를 진행하면서 그리고 세미나를 돌아보면서 치열하게 고민했습니다. 그렇게 집중하고나니 당장해야 하는 일 3가지는 다음과 같았습니다.(1)코드리뷰(2)테스트코드 작성(3)이슈 관리 프로세스이 세 가지의 일이 정답이 아닐 수 있습니다. 정답인지 아닌지는 얼마간 시간이 흐른 후에야 알 수 있겠죠? 다만, 저희는 늘 저희가 하던 방식대로 용기를 갖고 baby step을 무던히 수행해 나갈 것입니다. 다음화는 위의 세 가지 일을 진행하면서 겪은 시행착오를 공유해 보도록 하겠습니다.긴 글 읽어 주셔서 고맙습니다.#스위쳐 #Switcher #DevOPS #데브옵스 #개발자 #개발 #개발문화 #디버깅 #버그수정 #인사이트
조회수 1963

AWS Rekognition + PHP를 이용한 이미지 분석 예제 (2/2)

이전 글 보기: AWS Rekognition + PHP를 이용한 이미지 분석 예제 (1/2)Overview지난 글에서는 AWS Rekognition을 이용해 S3 Bucket에 업로드한 이미지로 이미지 분석 결과를 확인했습니다. 이번엔 더 나아가 Collection(얼굴 모음)을 생성해보고, 얼굴 검색을 해보겠습니다.1. Collection 만들기Collection은 AWS Rekognition의 기본 리소스입니다., 생성되는 각각의 컬렉션에는 고유의 Amazon 리소스 이름(ARN)이 있습니다. 컬렉션이 있어야 얼굴들을 저장할 수 있습니다. 저는 ‘BrandiLabs’라는 이름의 Collection을 생성했습니다.1-1. createRekognition 메소드를 이용해 손쉽게 Collection 을 생성합니다.# 클라이언트 생성 $sdk = new \\Aws\\Sdk($sharedConfig); $rekognitionClient = $sdk->createRekognition(); # 모음(Collection) 이름 설정 $collection = array('CollectionId' => 'BrandiLabs'); $response = $rekognitionClient->createCollection($collection); 1-2. Collection이 정상적으로 생성되었다면 아래와 같은 응답을 받습니다.[ { "StatusCode" : 200 "CollectionArn" : "aws:rekognition:region:account-id:collection/BrandiLabs" /*...*/ } ] 2. Collection에 얼굴 추가IndexFaces 작업을 사용해 이미지에서 얼굴을 감지하고 모음에 추가할 수 있습니다. (JPEG 또는 PNG) 모음에 추가할 이미지에 대해서는 몇 가지의 권장사항[1]이 있습니다.두 눈이 잘 보이는 얼굴 이미지를 사용합니다.머리띠, 마스크 등 얼굴을 가리는 아이템을 피합니다.밝고 선명한 이미지를 사용합니다.권장사항에 최적화된 사진은 S3 Bucket 에 업로드되어 있어야 합니다. 미리 ‘kimwk-rekognition’ 이라는 이름으로 버킷을 생성 후 제 사진과 곽정섭 과장님의 사진을 업로드해두었습니다.2-1. IndexFaces 메소드를 이용해 얼굴을 추가합니다. 예시에서는 제 얼굴과 곽 과장님의 얼굴을 인덱싱했습니다.$imageInfo = array(); $imageInfo['S3Object']['Bucket'] = 'kimwk-rekognition'; $imageInfo['S3Object']['Name'] = 'kwakjs.jpg'; $parameter = array(); $parameter['Image'] = $imageInfo; $parameter['CollectionId'] = 'BrandiLabs'; $parameter['ExternalImageId'] = 'kwakjs'; $parameter['MaxFaces'] = 1; $parameter['QualityFilter'] = 'AUTO'; $parameter['DetectionAttributes'] = array('ALL'); $response = $rekognitionClient->indexFaces($parameter); 각각의 요청 항목에 대한 상세 설명은 아래와 같습니다.Image : 인덱싱 처리할 사진의 정보입니다.CollectionId : 사진을 인덱싱할 CollectionId 입니다.ExternalImageId : 추후 인식할 이미지와 인덱싱된 이미지를 연결할 ID 입니다.MaxFaces : 인덱싱되는 최대 얼굴 수 입니다. 작은 얼굴(ex. 배경에 서 있는 사람들의 얼굴)은 인덱싱하지 않고 싶을 때 유용합니다.QualityFilter : 화질을 기반으로 얼굴을 필터링하는 옵션입니다. 기본적으로 인덱싱은 저화질로 감지된 얼굴을 필터링합니다. AUTO를 지정하면 이러한 기본 설정을 명시적으로 선택할 수 있습니다. (AUTO | NONE)DetectionAttributes : 반환되는 얼굴 정보를 다 가져올 것인지 아닌지에 대한 옵션입니다. ALL 로 하면 모든 얼굴 정보를 받을 수 있지만 작업을 완료하는데 시간이 더 걸립니다. (DEFAULT | ALL)2-2. Collection에 정상적으로 얼굴이 추가되었다면 아래와 같은 응답을 받습니다. 사진 속 인물의 성별, 감정, 추정 나이 등의 정보를 확인할 수 있습니다.[ { "Face":{ "FaceId":"face-id", "BoundingBox":{ "Width":0.28771552443504333, "Height":0.3611610233783722, "Left":0.39002931118011475, "Top":0.21431422233581543 }, "ImageId":"image-id", "ExternalImageId":"kimwk", "Confidence":99.99978637695312 }, "FaceDetail":{ "BoundingBox":{ "Width":0.28771552443504333, "Height":0.3611610233783722, "Left":0.39002931118011475, "Top":0.21431422233581543 }, "AgeRange":{ "Low":20, "High":38 }, "Smile":{ "Value":false, "Confidence":85.35209655761719 }, "Eyeglasses":{ "Value":false, "Confidence":99.99824523925781 }, "Sunglasses":{ "Value":false, "Confidence":99.99994659423828 }, "Gender":{ "Value":"Male", "Confidence":99.35176849365234 }, "Beard":{ "Value":false, "Confidence":94.80714416503906 }, "Mustache":{ "Value":false, "Confidence":99.92304229736328 }, "EyesOpen":{ "Value":true, "Confidence":99.64280700683594 }, "MouthOpen":{ "Value":false, "Confidence":99.4529037475586 }, "Emotions":[ { "Type":"HAPPY", "Confidence":2.123939275741577 }, { "Type":"ANGRY", "Confidence":6.1253342628479 }, { "Type":"DISGUSTED", "Confidence":19.37765121459961 }, { "Type":"SURPRISED", "Confidence":7.136983394622803 }, { "Type":"CONFUSED", "Confidence":30.74079132080078 }, { "Type":"SAD", "Confidence":9.113149642944336 }, { "Type":"CALM", "Confidence":25.382152557373047 } ], "Landmarks":[ { "Type":"eyeLeft", "X":0.45368772745132446, "Y":0.31557807326316833 }, … ], "Pose":{ "Roll":5.615509986877441, "Yaw":-5.510941982269287, "Pitch":-17.47319793701172 }, "Quality":{ "Brightness":93.13915252685547, "Sharpness":78.64350128173828 }, "Confidence":99.99978637695312 } } ] 3. 얼굴 검색드디어 얼굴 검색의 시간이 왔습니다. searchFacesByImage 메소드를 이용하면 지금까지 그래왔던 것처럼 쉽게 얼굴 검색을 할 수 있습니다. 저는 ‘kimwk2.jpg’ 라는 또 다른 제 얼굴 사진을 S3 Bucket에 업로드해뒀습니다. 얼굴 검색이 제대로 이루어졌다면 응답으로 제 ExternalImageId (kimwk) 가 내려올 것입니다. 한 번 해볼까요?3-1. searchFacesByImage 메소드를 이용해 얼굴 검색을 합니다.$imageInfo = array(); $imageInfo['S3Object']['Bucket'] = 'kimwk-rekognition'; $imageInfo['S3Object']['Name'] = 'kimwk2.jpg'; $parameter = array(); $parameter['CollectionId'] = 'BrandiLabs'; $parameter['Image'] = $imageInfo; $parameter['FaceMatchThreshold'] = 70; $parameter['MaxFaces'] = 1; $response = $rekognitionClient->searchFacesByImage($parameter); 3-2. 정상적으로 검색이 되었다면 아래와 같은 응답을 받습니다.[ { "Similarity":99.04029083251953, "Face":{ "FaceId":"FaceId", "BoundingBox":{ "Width":0.23038800060749054, "Height":0.2689349949359894, "Left":0.2399519979953766, "Top":0.08848369866609573 }, "ImageId":"ImageId", "ExternalImageId":"kimwk", "Confidence":100 } } ] SearchFacesByImage는 기본적으로 알고리즘이 80% 이상의 유사성을 감지하는 얼굴을 반환합니다. 유사성은 얼굴이 검색하는 얼굴과 얼마나 일치하는지를 나타냅니다. FaceMatchThreshold 값을 조정하면 어느 정도까지 유사해야 같은 얼굴이라고 허용할지를 정할 수 있습니다.Conclusion이미지 분석 알고리즘과 얼굴 검색 기능을 직접 구현하려 했다면 시간이 많이 걸렸겠지만 AWS 서비스를 이용하면 이미지 분석을 금방 할 수 있습니다. 이 기능을 잘 활용하면 미아 찾기나 범죄 예방과 같은 공공 안전 및 법 진행 시나리오에도 응용할 수도 있겠죠. 다음엔 보다 재밌는 주제로 찾아오겠습니다.참고[1] 얼굴 인식 입력 이미지에 대한 권장 사항[2] Amazon Rekonition 개발자 안내서[3] 모든 예제는 AmazonRekognition, AmazonS3에 대한 권한이 있어야 함글김우경 대리 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만
조회수 2216

블로그 운영 방법에서 엿보는 VCNC의 개발문화

VCNC에서 엔지니어링 블로그를 시작하고 벌써 새로운 해를 맞이하였습니다. 그동안 여러 글을 통해 VCNC 개발팀의 이야기를 들려드렸습니다. 이번에는 엔지니어링 블로그 자체를 주제로 글을 적어보고자 합니다. 저희는 워드프레스나 텀블러와 같은 일반적인 블로깅 도구나 서비스를 사용하지 않고 조금은 개발자스럽다고 할 수 있는 특이한 방법으로 엔지니어링 블로그를 운영하고 있습니다. 이 글에서는 VCNC 개발팀이 엔지니어링 블로그를 운영하기 위해 이용하는 방법들을 소개하고자 합니다. 그리고 블로그를 운영하기 위해 방법을 다루는 중간중간에 개발팀의 문화와 일하는 방식들에 대해서도 간략하게나마 이야기해보고자 합니다.블로그에 사용하는 기술들Jekyll: Jekyll은 블로그에 특화된 정적 사이트 생성기입니다. GitHub의 Co-founder 중 한 명인 Tom Preston-Werner가 만들었으며 Ruby로 작성되어 있습니다. Markdown을 이용하여 글을 작성하면 Liquid 템플릿 엔진을 통해 정적인 HTML 파일들을 만들어 줍니다. VCNC 엔지니어링 블로그는 워드프레스같은 블로깅 도구를 사용하지 않고 Jekyll을 사용하고 있습니다.Bootstrap: 블로그 테마는 트위터에서 만든 프론트엔드 프레임워크인 Bootstrap을 이용하여 직접 작성되었습니다. Bootstrap에서 제공하는 다양한 기능들을 가져다 써서 블로그를 쉽게 만들기 위해 이용하였습니다. 덕분에 큰 공을 들이지 않고도 Responsive Web Design을 적용할 수 있었습니다.S3: S3는 AWS에서 제공되는 클라우드 스토리지 서비스로서 높은 가용성을 보장합니다. 일반적으로 파일을 저장하는 데 사용되지만, 정적인 HTML을 업로드하여 사이트를 호스팅하는데 사용할 수도 있습니다. 아마존의 CTO인 Werner Vogels 또한 자신의 블로그를 S3에서 호스팅하고 있습니다. VCNC Engineering Blog도 Jekyll로 만들어진 HTML 파일들을 아마존의 S3에 업로드 하여 운영됩니다. 일단 S3에 올려두면 운영적인 부분에 대한 부담이 많이 사라지기 때문에 S3에 올리기로 하였습니다.CloudFront: 브라우저에서 웹페이지가 보이는 속도를 빠르게 하려고 아마존의 CDN서비스인 CloudFront를 이용합니다. CDN을 이용하면 HTML파일들이 전 세계 곳곳에 있는 Edge 서버에 캐싱 되어 방문자들이 가장 가까운 Edge를 통해 사이트를 로딩하도록 할 수 있습니다. 특히 CloudFront에 한국 Edge가 생긴 이후에는 한국에서의 응답속도가 매우 좋아졌습니다.s3cmd: s3cmd는 S3를 위한 커맨드 라인 도구입니다. 파일들을 업로드하거나 다운로드 받는 등 S3를 위해 다양한 명령어를 제공합니다. 저희는 블로그 글을 s3로 업로드하여 배포하기 위해 s3cmd를 사용합니다. 배포 스크립트를 실행하는 것만으로 s3업로드와 CloudFront invalidation이 자동으로 이루어지므로 배포 비용을 크게 줄일 수 있었습니다.htmlcompressor: 정적 파일들이나 블로그 글 페이지들을 s3에 배포할 때에는 whitespace 등을 제거하기 위해 htmlcompressor를 사용합니다. 또한 Google Closure Compiler를 이용하여 javascript의 길이도 줄이고 있습니다. 실제로 서버가 내려줘야 할 데이터의 크기가 줄어들게 되므로 로딩속도를 조금 더 빠르게 할 수 있습니다.블로그 관리 방법앞서 소개해 드린 기술들 외에도 블로그 글을 관리하기 위해 다소 독특한 방법을 사용합니다. 개발팀의 여러 팀원이 블로그에 올릴 주제를 결정하고 서로의 의견을 교환하기 위해 여러 가지 도구를 이용하는데 이를 소개하고자 합니다. 이 도구들은 개발팀이 일할 때에도 활용되고 있습니다.글감 관리를 위해 JIRA를 사용하다.JIRA는 Atlassian에서 만든 이슈 관리 및 프로젝트 관리 도구입니다. VCNC 개발팀에서는 비트윈과 관련된 다양한 프로젝트들의 이슈 관리를 위해 JIRA를 적극적으로 활용하고 있습니다. 제품에 대한 요구사항이 생기면 일단 백로그에 넣어 두고, 3주에 한 번씩 있는 스프린트 회의에서 요구사항에 대한 우선순위를 결정합니다. 그 후 개발자가 직접 개발 기간을 산정한 후에, 스프린트에 포함할지를 결정합니다. 이렇게 개발팀이 개발에 집중할 수 있는 환경을 가질 수 있도록 하며, 제품의 전체적인 방향성을 잃지 않고 모두가 같은 방향을 향해 달릴 수 있도록 하고 있습니다.VCNC 개발팀이 스프린트에 등록된 이슈를 얼마나 빨리 해결해 나가고 있는지 보여주는 JIRA의 차트.조금만 생각해보시면 어느 부분이 스프린트의 시작이고 어느 부분이 끝 부분인지 아실 수 있습니다.위와 같은 프로젝트 관리를 위한 일반적인 용도 외에도 엔지니어링 블로그 글 관리를 위해 JIRA를 사용하고 있습니다. JIRA에 엔지니어링 블로그 글감을 위한 프로젝트를 만들어 두고 블로그 글에 대한 아이디어가 생각나면 이슈로 등록할 수 있게 하고 있습니다. 누구나 글감 이슈를 등록할 수 있으며 필요한 경우에는 다른 사람에게 글감 이슈를 할당할 수도 있습니다. 일단 글감이 등록되면 엔지니어링 블로그에 쓰면 좋을지 어떤 내용이 포함되면 좋을지 댓글을 통해 토론하기도 합니다. 글을 작성하기 시작하면 해당 이슈를 진행 중으로 바꾸고, 리뷰 후, 글이 발행되면 이슈를 해결한 것으로 표시하는 식으로 JIRA를 이용합니다. 누구나 글감을 제안할 수 있게 하고, 이에 대해 팀원들과 토론을 하여 더 좋은 글을 쓸 수 있도록 돕기 위해 JIRA를 활용하고 있습니다.JIRA에 등록된 블로그 글 주제들 중 아직 쓰여지지 않은 것들을 보여주는 이슈들.아직 제안 단계인 것도 있지만, 많은 주제들이 블로그 글로 발행되길 기다리고 있습니다.글 리뷰를 위해 Pull-request를 이용하다.Stash는 Attlassian에서 만든 Git저장소 관리 도구입니다. GitHub Enterprise와 유사한 기능들을 제공합니다. Jekyll로 블로그를 운영하는 경우 이미지를 제외한 대부분 콘텐츠는 평문(Plain text)으로 관리 할 수 있게 됩니다. 따라서 VCNC 개발팀이 가장 자주 사용하는 도구 중 하나인 Git을 이용하면 별다른 시스템의 도움 없이도 모든 변경 내역과 누가 변경을 했는지 이력을 완벽하게 보존할 수 있습니다. 저희는 이런 이유로 Git을 이용하여 작성된 글에 대한 변경 이력을 관리하고 있습니다.또한 Stash에서는 GitHub와 같은 Pull request 기능을 제공합니다. Pull request는 자신이 작성한 코드를 다른 사람에게 리뷰하고 메인 브랜치에 머지해 달라고 요청할 수 있는 기능입니다. 저희는 Pull request를 활용하여 상호간 코드 리뷰를 하고 있습니다. 코드 리뷰를 통해 실수를 줄이고 개발자 간 의견 교환을 통해 더 좋은 코드를 작성하며 서로 간 코드에 대해 더 잘 이해하도록 노력하고 있습니다. 새로운 개발자가 코드를 상세히 모른다 해도 좀 더 적극적으로 코드를 짤 수 있고, 업무에 더 빨리 적응하는데에도 도움이 됩니다.어떤 블로그 글에 대해 리뷰를 하면서 코멘트로 의견을 교환하고 있습니다.코드 리뷰 또한 비슷한 방법을 통해 이루어지고 있습니다.업무상 코드 리뷰 뿐만 아니라 새로운 블로그 글을 리뷰하기 위해 Pull request를 활용하고 있습니다. 어떤 개발자가 글을 작성하기 위해서 가장 먼저 하는 것은 블로그를 관리하는 Git 리포지터리에서 새로운 브랜치를 따는 것입니다. 해당 브랜치에서 글을 작성하고 작성한 후에는 새로운 글 내용을 push한 후 master 브랜치로 Pull request를 날립니다. 이때 리뷰어로 등록된 사람과 그 외 개발자들은 내용에 대한 의견이나 첨삭을 댓글로 달 수 있습니다. 충분한 리뷰를 통해 발행이 확정된 글은 블로그 관리자에 의해 master 브랜치에 머지 되고 비로소 발행 준비가 끝납니다.스크립트를 통한 블로그 글 발행 자동화와 보안준비가 끝난 새로운 블로그 글을 발행하기 위해서는 일련의 작업이 필요합니다. Jekyll을 이용해 정적 파일들을 만든 후, htmlcompressor 통해 정적 파일들을 압축해야 합니다. 이렇게 압축된 정적 파일들을 S3에 업로드 하고, CloudFront에 Invalidation 요청을 날리고, 구글 웹 마스터 도구에 핑을 날립니다. 이런 과정들을 s3cmd와 Rakefile을 이용하여 스크립트를 실행하는 것만으로 자동으로 이루어지도록 하였습니다. VCNC 개발팀은 여러 가지 업무 들을 자동화시키기 위해 노력하고 있습니다.또한, s3에 사용하는 AWS Credential은 IAM을 이용하여 블로그를 호스팅하는 s3 버킷과 CloudFront에 대한 접근 권한만 있는 키를 발급하여 사용하고 있습니다. 비트윈은 특히 커플들이 사용하는 서비스라 보안에 민감합니다. 실제 비트윈을 개발하는데에도 보안에 많은 신경을 쓰고 있으며, 이런 점은 엔지니어링 블로그 운영하는데에도 묻어나오고 있습니다.맺음말VCNC 개발팀은 엔지니어링 블로그를 관리하고 운영하기 위해 다소 독특한 방법을 사용합니다. 이 방법은 개발팀이 일하는 방법과 문화에서 큰 영향을 받았습니다. JIRA를 통한 이슈 관리 및 스프린트, Pull request를 이용한 상호간 코드 리뷰 등은 이제 VCNC 개발팀의 문화에 녹아들어 가장 효율적으로 일할 수 있는 방법이 되었습니다. 개발팀을 꾸려나가면서 여러가지 시행 착오를 겪어 왔지만, 시행 착오에 대한 반성과 여러가지 개선 시도를 통해 계속해서 더 좋은 방법을 찾아나가며 지금과 같은 개발 문화가 만들어졌습니다. 그동안 그래 왔듯이 앞으로 더 많은 개선을 통해 꾸준히 좋은 방법을 찾아 나갈 것입니다.네 그렇습니다. 결론은 저희와 함께 고민하면서 더 좋은 개발문화를 만들어나갈 개발자를 구하고 있다는 것입니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!
조회수 1945

Golang 체험기

AWS EC2 태그를 Kubernetes Label로 뽑아주는 Vungle/Labelgun에 문제가 많아서 이번에 대대적인 수술을 하였다. 하루에 수백번씩 Pod가 죽는 통에 도저히 참을 수가 없었다. 아무튼 이와 관련한 이야기는 다른 글에서 썰을 풀고 여기서는 Go에 초점을 맞추고 경험담을 늘어놓아볼까 한다.장점기술 탐색 — golang이란 글에서는 주로 부정적인 견해를 보였지만 최근에는 생각이 바뀌었다. 무엇보다 Docker와 같은 컨테이너 기반 서비스에는 Golang과 같은 언어가 Java 또는 Python 같은 언어보다 분명 장점이 있다. 미리 빌드한 바이너리 파일만 컨테이너에 넣으면 되기 때문에 가볍다. Java Runtime을 컨테이너에 넣을 때보다 월등히 가볍다. 여기서 가볍다 함은 컴퓨팅 리소스 측면, 컨테이너 빌드 구성의 용이함 모두를 뜻한다. 물론 전통적인 C/C++ 환경도 비슷하지 않냐라고 의문을 품는 사람도 있겠지만 Golang은 goroutine등으로 동시성 제어를 런타임 시스템이 알아서 제어해주기 때문에 언제든 머신을 갈아치울 수 있는 클라우드 환경에 훨씬 적합하다. 그 외에도 현대적인 언어의 여러 장점을 누릴 수 있는데 이는 다른 글이 훨씬 잘 설명해놓았기에 자세한 언급은 하지 않으려 한다.GOPATH 를 처음 여행하는 GOPHER 들을 위한 GOLANG 안내서단점Application Performance Monitoring을 구축하기가 생각보다 어렵다. New Relic과 DataDog Trace 모두 개발자가 코드를 상당량 추가해줘야 한다. 보통 에이전트만 붙이면 알아서 잘 작동하는 Java APM에 비해 상당히 과거의 방식이다.func saveFile(ctx context.Context, path string, r io.Reader) error { // Start a new span that is the child of the span stored in the context. If the span // has no context, it will return an empty one. span := tracer.NewChildSpanFromContext("filestore.saveFile", ctx) defer span.Finish() // save the file contents. file, err := os.Create(path) if err != nil { span.SetError(err) return err } defer file.Close() _, err = io.Copy(file, r) span.SetError(err) return err }소스코드를 바이너리 코드로 컴파일하기 때문에 빌드 및 테스트 피드백 주기가 길다. C++을 한참 다루던 시절로 돌아간 느낌이다. 한마디로 답답하다.게다가 npm과 같은 패키지 관리 시스템이 없고 Git과 같은 소스버전관리시스템을 바로 접근해 사용하기 때문에 초기 빌드가 엄청나게 느리다. Git clone 보다는 이미 잘 패키징된 파일 몇 개를 다운로드 받는 쪽이 월등히 빠를 수밖에 없지 않나?패키지 관리 시스템과 더불어 빌드와 관련해 그 존재가 매우 의심쩍은 게 하나 있으니 바로 GOPATH이다. Python의 virtualenv처럼 프로젝트별로 완전히 고립된 개발환경을 갖추면 여러 모로 장점이 많은데 왜 이런 환경변수가 존재해야 하는가? 왜? 대체 왜?마지막으로 한가지 더. Go는 goroutine 등으로 병렬작업을 지원하여 분명 편하다. 하지만 순수한 함수형 언어가 아니고 Immutable한 데이터를 메시지 패싱하는 방식이 아니기 때문에 애먹는 부분이 많다. goroutine과 channel을 장점으로 내세우는만큼 최소한 표준 라이브러리는 동시성을 최대한 고려해서 설계했을 법한데 그렇지 않은 부분이 많아서 당혹스러웠다. 물론 이러한 설계는 그만한 장점이 있지만 한동안 유행하던 다수의 언어와는 방향이 달라서 다소 적응하기 힘들었다.#데일리 #데일리호텔 #개발 #개발자 #개발팀 #스킬스택 #기술스택 #스택도입기 #후기 #golang
조회수 1602

RxJava2 함수 파헤치기!

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

오픈서베이 개발팀이 일하는 법, 개발자에게 직접 들어봤습니다

김경만님은 오픈서베이의 미들레벨 안드로이드 개발자이자 오베이 시스템 PM(이하 조셉)입니다. 지인 추천으로 2명의 개발자 채용을 도운 오픈서베이 전도사기도 하죠. 이런 조셉은 지원할 때만 해도 오픈서베이가 어떤 회사인지 잘 몰랐다고 합니다. 병특 중인데 TO가 있길래 지원한 게 크죠. 그렇게 덜컥 입사한 오픈서베이를 다니며 잘 갖춰진 업무 환경, 조직 문화, 좋은 구성원에 반해버렸다고 합니다. 병특 복무를 마친 뒤에도 오픈서베이의 훌륭한 구성원으로 5년 차 개발자의 커리어를 쌓아가고 있죠. 조셉에게 오픈서베이에 반한 이유와 개발팀의 업무 문화에 대한 이야기를 들어봤습니다.            오픈서베이 김경만(조셉) 안드로이드 개발자 겸 오베이 앱 PM   조셉, 안녕하세요! 안녕하세요(웃음). 오픈서베이의 미드레벨 안드로이드 개발자 조셉입니다. 올해부터는 오베이 앱 PM으로 역할이 확대됐어요. 오베이는 오픈서베이 패널로 활동할 수 있는 설문조사 앱입니다.   세부적으로는 안드로이드 오베이 앱 개발, 오베이 회원계 시스템, 타겟팅 설문을 위한 유저 세그멘테이션 시스템을 개발·운영하고 있어요. 5년 차 개발자로 오픈서베이에는 17년 12월에 입사해서 벌써 1년 반 정도 일하고 있네요.    입사 계기가 독특하더라고요. 고백하자면 그렇죠. 전 직장에서 병특 복무 중에 이직을 결심하고 원티드에서 오픈서베이를 처음 알게 됐어요. 사실 뭐하는 회사인지도 잘 몰랐고 병특 TO가 있으니까 그때부터 찾아본 거예요.  잡플래닛을 검색해보니 ‘리서치 업계의 게임 체인저’라는 리뷰가 뜨더라고요. 실은 그 말이 정확히 무슨 의미인지도 잘 몰랐어요. 그냥 리서치란 단어가 주는 스마트하고 긍정적인 느낌이 있었는데 “그런 리서치 시장의 게임 체인저라니!”라며 면접을 본 거에요.   그럼 오픈서베이를 다니면서 긍정적인 면을 발견하신 거군요. 일단, 개발 업무 환경이 수준급이라 놀랐어요. 규모가 좀 있는 기업에서나 볼 수 있는 인텔리제이(intellij)도 너무 당연하게 구비돼 있더라고요. 이게 꽤 비싼 툴이거든요. 그래서 스타트업은 개발자 채용 공고에 인텔리제이 구매해서 사용한다고 일부러 적어놓기도 할 정도예요.  그런데 오픈서베이는 입사 때 따로 이야기해 주지 않아서 몰랐는데 떡하니 있길래 놀랐죠. whatap, jenkins, graylog 등을 이용한 배포·운영·모니터링 환경도 체계적으로 갖춰져 있었고요.  사실 이런 개발 환경을 갖춘 스타트업은 정말 흔치 않아요. 그래서 많은 개발자 꿈나무들이 큰 기대를 갖고 스타트업에 입사했다가 좌절해요. 앞에선 기술 중심의 혁신을 외치는데 그만큼의 투자가 없거나 여건이 마련돼 있지 않아서요. 여전히 많은 스타트업 개발자가 수작업으로 일일이 버그 모니터링을 하거나 업데이트 배포를 하는 경우도 많아요.  그런데 구비된 툴을 보면서 오픈서베이 개발팀은 생산성을 위한 비용 투자를 아끼지 않고 구조적인 개발 시스템에 노력하는 회사라는 인상을 받았어요. 개발 입문서 같은 데서 정석이라는 시스템을 그대로 갖추고 있으니까 제가 배운 이론을 현장에 바로 적용할 수도 있는 것도 좋았고요.   무엇보다 일에 집중할 수 있는 환경이군요.  이건 좀 개인적이긴 한데, 입사 전에 업무용 랩탑 선택권을 주는 것도 좋았어요. 사실 랩탑은 일할 때 제일 자주 많이 쓰는 도구잖아요. 업무에 가장 중요한 요소라고도 말 할 수도 있는데, 각 랩탑 사양을 정말 세부적으로 알려주고 원하는 걸 직접 선택할 수 있게 해주는 부분도 인상적이었어요.   그런데 후보 중에 제가 꼭 사고 말겠다고 생각했던 꿈의 랩탑 ‘델 XPS 15’이 있더라고요. 벌써 1년 반이나 지났는데 아직도 이 랩탑으로 일할 때는 괜히 기분이 좋아요.    “업무용 랩탑 선택권을 주는 것도 좋았어요. 사실 랩탑은 일할 때 제일 자주 많이 쓰는 도구잖아요.”   세세한 부분에서도 감동을 받으셨군요(웃음). 이렇게 디테일한 요소까지 챙기는 회사의 모습에 감동하는 거죠. 저는 오픈서베이가 3번째 직장이라서, 회사가 업무 환경에 디테일하게 신경 쓰는 게 얼마나 힘든지를 몸소 경험해서 알고 있거든요. 그런 면에서 오픈서베이는 개발 환경도 잘 갖춰져 있고, 업무를 위한 투자도 많고, 배울 사람도 많아요.   원티드에는 오픈서베이가 어떻게 소개되고 있을까요?   여건만 좋다고 다 좋은 회사는 아닐 수 있잖아요. 물론이죠. 근데 오픈서베이는 여건뿐만 아니라 성장 기회가 많아요. 의욕만 있다면 아직 주인을 찾지 못한 일들을 자신의 것으로 만들 수 있죠. 저는 주도적으로 일할 의지가 있는 구성원이 마음껏 역할을 늘려 갈 수 있는 조직이 긍정적인 면이 많다고 생각해요. 하고 싶은 사람이 그 일을 맡는 거니까요.   이런 면은 주니어나 미들레벨 개발자에게는 좋은 성장 기회가 되는 것 같아요. 제가 오베이 안드로이드 개발자에서 PM으로 역할이 확대되는 과정도 그랬어요. 처음에는 진짜 딱 개발만 했거든요. 운영 장애가 생겨도 저는 제가 개발한 요소의 코드만 아니까 다른 분야는 해결법도 모르고 제 역할도 아니니까 어쩔 줄 몰라 하며 지켜만 봤어요.  그런데 매번 아무것도 할 수 없는 상황에 놓이니까 제가 직접 문제를 해결할 수 있는 사람이 되고 싶어졌어요. 그때부터 오베이 앱 관련 코드를 다 까보면서 시스템 흐름을 파악했고, 장애가 발생했을 때 제가 해결할 수 있는 범위를 차근차근 늘려갔어요. 나중에는 노후한 시스템을 제가 만든 시스템으로 교체까지 했고요. 그러다 오픈서베이 CTO인 폴의 제안으로 올해부터 PM을 맡게 됐습니다.    조셉이 오베이 PM이 된 배경에는 그런 성장 스토리가 있었군요! 주도적으로 일하는 경험은 다른 회사에선 쉽게 얻기 힘든 기회라는 점은 정말 동의해요. 맞아요. 빠른 성장을 원하는 분에게 지금 오픈서베이는 딱 좋은 규모의 회사인 것 같아요.  정말 개발 인력이 적고 여건이 좋지 않아서 어쩔 수 없이 역할을 확대한 게 아니라, 좋은 여건과 환경에서도 빠르게 역할을 확대할 수 있는 단계에 이른 것 같아서요. 더 규모가 크고 탄탄한 회사에서는 사실 주도적으로 일하고 싶어도 환경이 따라주지 않는 경우도 많으니까요.  물론, 역량과 성취에 따라 합당한 보상을 해줘야 구성원들이 적극적이고 주도적으로 일하고 싶은 의욕이 생긴다는 생각도 하는데요. 제 경험에 비춰보면 오픈서베이는 일이 늘어나는 만큼 보상도 확실한 것 같아요(웃음).    “주도적으로 일할 의지가 있는 구성원이 마음껏 역할을 늘려 갈 수 있는 조직이 좋아요. 하고 싶은 사람이 그 일을 맡는 거니까요”     그런 좋은 경험 덕에 병특 이후에도 오픈서베이를 지켜주시는 거군요. 잘 몰랐는데 병특 복무가 끝나면 곧장 이직하는 게 훨씬 흔하다면서요?  맞아요. 더이상 그 회사에 묶여 있을 필요가 없으니 더 처우 좋은 회사를 찾아 떠나는 거죠. 저는 일부러 남았다기보다는 딱히 이직할 이유가 없어서 이직을 고려하지 않았다는 게 맞는 말인 것 같아요. 개발 업무 환경도 잘 갖춰져 있고 회사도 성장하고 있고, 무엇보다 보상 기준도 체계적이라고 생각하니까요.   보상 기준이 체계적이라고 생각하는 이유가 있나요? 개발팀에서 상하반기를 나눠서 1년에 2번씩 이뤄지는 성장진단을 해요. 단순한 연봉 협상이 아니라 정말로 제가 한 일을 돌아보면서 얼마나 성장했고 성취를 이뤘는지 상급자와 점검해보는 시간이에요. 사실 전 제 개인 블로그에 매달 1번씩 업무 성과 회고를 하거든요. 아무래도 명확한 독자가 없으니까 좀 캐주얼하게 쓰는 편이에요. 근데 회사 성장진단 문서는 내용은 같아도 독자가 다르니까 자연스럽게 자기객관화를 하면서 성과와 시행착오를 정리할 수 있는 시간이라 좋더라고요. 특히, 폴(이건노 CTO)은 이스트소프트에서 개발 조직을 오래 리딩하셔서 확실히 조언의 깊이가 달라요. 저는 아무래도 시야가 아직 넓지 않아서 개발 업무를 성능과 기술 중심으로만 대해요. 그런데 폴은 방대한 시각으로 비즈니스나 운영 관점에서 서비스가 확장될 때를 미리 계산해서 조언을 해주셔서 좋았습니다.   오픈서베이와 스타트업 얼라이언스가 함께한 ‘2018 스타트업 트렌드 리포트’를 보면, 재직자들이 스타트업에 가장 만족하는 요인은 ‘빠르고 유연한 의사결정 구조’였어요. 조셉 생각에 오픈서베이는 어떤가요? 자의적으로 해석할 여지가 많은 요소네요. 빠르고 유연한 의사결정 구조를 개발자 맘대로 하는 거라고 생각할 수 있으니까요. 그렇게 생각한다면 오픈서베이는 전혀 그런 회사는 아닌 것 같아요. 모든 의사결정은 전후 사정이나 논리적인 타당성을 따져보고 함께 결정하니까요.  대신 결정할 사안에 대한 논의는 정말 빠르고 유연하게 이뤄져요. 최고 결정권자인 하이(황희영 대표이사)와 논의가 필요하다고 생각되면 물어봐서 일정만 잡으면 얼마든지 1:1 미팅을 할 수 있어요. 대표실이 따로 있는 게 아니라 한 공간에서 같이 일하니까 몇초 걸어가서 바로 물을 수도 있고요. 대표이사와 이렇게 쉽게 이야기 나눌 수 있다는 점도 오픈서베이의 장점이죠.    “빠르고 유연한 의사결정 구조를 개발자 맘대로 하는 거라고 생각한다면, 오픈서베이는 그런 회사는 아니예요. 모든 의사결정은 전후 사정이나 논리적인 타당성을 따져보고 함께 결정하니까요.”   업무 영역을 넓힐 기회뿐만 아니라 발언 기회도 열려있다는 의미일까요? 정확해요. 개발팀에 ‘세미나’라는 제도가 있어요. 주간 회의와 별도로 팀에 공유하고 싶은 내용이 있는 구성원이 자발적으로 발표를 하는 시간이에요. 특정 프로젝트를 하면서 깨달은 점이나 노하우를 공유하는 식이죠. 저는 이런 세미나가 특히 주니어에게는 아주 좋은 발언 기회라고 생각해요.  사실 작년에 제가 ReactiveX와 Reactive System을 좋아해서 공부하고 있었어요. 당연히 오픈서베이 개발팀에도 도입하고 싶었죠. 근데 팀에 리액티브X를 다루던 분이 없어서 도입 시 이득에 대한 공감대가 없었어요. 그래서 세미나를 활용해서 , <리액티브 시스템으로 설문 서비스 구축하기>라는 주제로 두 차례 발표했어요.  당시에는 발표한다고 진짜 리액티브 시스템을 도입할 수 있을까 생각했어요. ‘필요하니 돈 내고 사자!’라며 간단히 설득할 수 있는 사안이 아니었거든요. 리액티브 시스템은 말하자면 개발 패러다임, 업무 방법론이에요. 개발 업무를 아무도 하지 않았던 새로운 방법으로 바꾸자는 얘기니까 팀 차원에서는 훨씬 복잡하고 신중한 의사결정이 필요한 사안이었죠.    조셉에게 세미나는 그런 중요한 사안을 건의할 기회의 장이었군요. 결국 도입은 성공했나요? 네(웃음). 덕분에 오베이 앱은 RxJava를 활용해 개발했어요. 이후 설문 서비스 개발을 담당하는 테리(이한별 개발자)는 리액티브한 방식으로 내부 파일 관리 시스템을 만들었어요. 정말로 저 혼자만 아니라 팀에서도 활용 가능한 개발 방법론이 된 거죠. 생각해보면 입사한 지 1년도 안 된 개발자가 팀에 새로운 업무 방법론을 도입하자는 발언권을 가질 수 있다는 점 자체가 오픈서베이 개발팀의 업무 문화와 일하는 방법을 단적으로 보여주는 예시 아닐까 싶어요.    마지막으로 오픈서베이의 예비 구성원분들께 한마디 부탁드립니다.  저는 오픈서베이를 다니면서 좋은 구성원들에게 자극을 받고 더 성장하기 위해 노력하게 된 것 같아요. 사실 제가 학창시절 때 꿈이 프로게이머였을 정도로 게임을 좋아해요. 회사 다니면서도 다른 시간 다 줄여도 게임하는 시간은 못 줄였을 정도로요.  그런데 좋은 업무 환경과 동료들, 성장 기회, 그리고 확실한 보상까지 고루 갖춘 회사에 다녀보니 더 좋은 사람이 되고 싶다는 생각이 들더라고요. 다른 동료들처럼 훌륭한 사람이 되고 싶어서 말이죠. 그래서 요즘은 그 좋아하던 게임도 접어두고 자기 계발에 몰두하고 있어요.  단순히 높은 연봉이나 좋은 복지가 아니라 함께 성장하고 싶은 예비 구성원분들의 많은 지원을 기대합니다!      “조셉과 함께 일하고 싶으시다면 지금 바로 오픈서베이 입사 지원을 해보세요”  
조회수 1967

비트윈의 스티커 시스템 구현 이야기 - VCNC Engineering Blog

 비트윈에는 커플들이 서로에게 감정을 더욱 잘 표현할 수 있도록 스티커를 전송할 수 있는 기능이 있습니다. 이를 위해 스티커 스토어에서 다양한 종류의 스티커를 제공하고 있으며 사용자들은 구매한 스티커를 메시지의 첨부파일 형태로 전송을 할 수 있습니다. 저희가 스티커 시스템을 구현하면서 맞딱드린 문제와 이를 해결한 방법, 그리고 프로젝트를 진행하면서 배운 것들에 대해 소개해 보고자 합니다.스티커 시스템 아키텍처비트윈에서 스티커 기능을 제공하기 위해 다양한 구성 요소들이 있습니다. 전체적인 구성은 다음과 같습니다.비트윈 서버: 이전에 소개드렸었던 비트윈의 서버입니다. 비트윈의 채팅, 사진, 기념일 공유 등 제품내의 핵심이 되는 기능을 위해 운영됩니다. 스티커 스토어에서 구매한 스티커는 비트윈 서버를 통해 상대방에게 전송할 수 있습니다.스티커 스토어 서버: 스티커를 구매할 수 있는 스토어를 서비스합니다. 스티커 스토어는 웹페이지로 작성되어 있고 아이폰, 안드로이드 클라이언트와 유기적으로 연동되어 구매 요청 등을 처리합니다. 처음에는 Python과 Flask를 이용하여 구현하려 하였으나 결국엔 서버 개발자들이 좀 더 익숙한 자바로 구현하기로 결정하였습니다. Jetty와 Jersey를 사용하였고, HTML을 랜더링하기 위한 템플릿 엔진으로는 Closure Template을 이용하였습니다. ORM으로는 Hibernate/JPA, 클라이언트와 웹페이지간 연동을 위해서 Cordova를 이용하였습니다. EC2에서 운영하고 있으며 데이터베이스로는 RDS에서 제공하는 MySQL을 사용합니다. 이미 존재하는 솔루션들을 잘 활용하여 최대한 빨리 개발 할 수 있도록 노력을 기울였습니다.스티커 다운로드 서버: 스티커는 비트윈에서 정의한 특수한 포맷의 파일 형태로 제공됩니다. 기본적으로 수 많은 사용자가 같은 스티커 파일을 다운로드 받습니다. 따라서 AWS에서 제공하는 CDN인 CloudFront을 이용하며, 실제 스티커 파일들은 S3에서 호스팅합니다. 그런데 스티커 파일들은 디바이스의 해상도(DPI)에 따라 최적화된 파일들을 내려줘야하는 이슈가 있었습니다. 이를 위해 CloudFront와 S3사이의 파일 전송에 GAE에서 운영중인 간단한 어플리케이션이 관여합니다. 이에 대해서는 뒷편에서 좀 더 자세히 설명하도록 하겠습니다.구현상 문제들과 해결 방법들적정 기술에 대해 고민하다스티커 스토어 서버를 처음 설계할때 Flask와 SQLAlchemy를 이용하여 구현하고자 하였습니다. 개발팀 내부적으로 웹서버를 만들때 앞으로 Python과 Flask를 이용해야겠다는 생각이 있었기 때문이며, 일반적으로 Java보다는 Python으로 짜는 것이 개발 효율이 더 좋다는 것은 잘 알려진 사실이기도 합니다. 하지만 Java에 익숙한 서버 개발자들이 Python의 일반적인 스타일에 익숙하지 않아 Python다운 코드를 짜기 어려웠고, 오히려 개발하는데 비용이 더 많이 들어갔습니다. 그래서 개발 중에 다시 웹 서버는 자바로 짜게 되었고, 여러가지 스크립트들만 Python으로 짜고 있습니다. 실제 개발에 있어서 적절한 기술의 선택은 실제 프로젝트에 참여하는 개발자들의 능력에 따라 달라져야한다는 것을 알게되었습니다.스티커 파일 용량과 변환 시간을 고려하다사용자는 스티커 스토어에서 여러개의 스티커가 하나로 묶인 스티커 묶음을 구매하게 됩니다. 구매 완료시 여러개의 스티커가 하나의 파일로 압축되어 있는 zip파일을 다운로드 받게 됩니다. zip파일내의 각 스티커 파일에는 스티커를 재생하기 위한 스티커의 이미지 프레임들과 메타데이터에 대한 정보들이 담겨 있습니다. 메타데이터는 Thrift를 이용하여 정의하였습니다.스티커 zip파일 안에는 여러개의 스티커 파일이 들어가 있으며, 스티커 파일은 다양한 정보를 포함합니다카카오톡의 스티커의 경우 애니메이션이 있는 것은 배경이 불투명하고 배경이 투명한 경우에는 애니메이션이 없습니다. 하지만 비트윈 스티커는 배경이 투명하고 고해상도의 애니메이션을 보여줄 수 있어야 했습니다. 배경이 투명한 여러 장의 고해상도 이미지를 움직이게 만드는 것은 비교적 어려운 점이 많습니다. 여러 프레임의 이미지들의 배경을 투명하게 하기 위해 PNG를 사용하면 JPEG에 비해 스티커 파일의 크기가 너무 커집니다. 파일 크기가 너무 커지면 당시 3G 환경에서 다운로드가 너무 오래 걸려 사용성이 크게 떨어지기 때문에 무작정 PNG를 사용할 수는 없었습니다. 이에 대한 해결책으로 투명 기능을 제공하면서도 파일 크기도 비교적 작은 WebP를 이용하였습니다. WebP는 구글이 공개한 이미지 포맷으로 화질 저하를 최소화 하면서도 이미지 파일 크기가 작다는 장점이 있습니다. 각 클라이언트에서 스티커를 다운 받을때는 WebP로 다운 받지만, 다운 받은 이후에는 이미지 로딩 속도를 위해 로컬에 PNG로 변환한 스티커 프레임들을 캐싱합니다.그런데 출시 된지 오래된 안드로이드나 iPhone 3Gs와 같이 CPU성능이 좋지 않은 단말에서 WebP 디코딩이 지나치게 오래 걸리는 문제가 있었습니다. 이런 단말들은 공통적으로 해상도가 낮은 디바이스였고, 이 경우에는 특별히 PNG로 스티커 파일을 만들어 내려줬습니다. 이미지의 해상도가 낮기 때문에 파일 크기가 크지 않았고, 다운로드 속도 문제가 없었기 때문입니다.좀 더 나은 주소 포맷을 위해 GAE를 활용하다기본적으로 스티커는 여러 사용자가 같은 스티커 파일을 다운받아 사용하기 때문에 CDN을 이용하여 배포하는 것이 좋습니다. CDN을 이용하면 스티커 파일이 전 세계 곳곳에 있는 엣지 서버에 캐싱되어 사용자들이 가장 최적의 경로로 파일을 다운로드 받을 수 있습니다. 그래서 AWS의 S3와 CloudFront를 사용하여 스티커 파일을 배포하려고 했습니다. 또한, 여러 해상도의 디바이스에서 최적의 스티커를 보여줘야 했습니다. 이 때문에 다양한 해상도로 만들어진 스티커 파일들을 S3에 올려야 했는데 클라이어트에서 스티커 파일을 다운로드시 주소 포맷을 어떻게 가져가야 할지가 어려웠습니다. S3에 올리는 경우 파일와 디렉터리 구조 형태로 저장되기 때문에 아래와 같은 방법으로 저장이 가능합니다.http://dl.sticker.vcnc.co.kr/[dpi_of_sticker]/[sticker_id].sticker하지만, 이렇게 주소를 가져가는 경우 클라이언트가 자신의 해상도에 맞는 적절한 스티커의 해상도를 계산하여 요청해야 합니다. 이것은 클라이언트에서 서버에서 제공하는 스티커 해상도 리스트를 알고 있어야 한다는 의미이며, 이러한 정보들은 최대한 클라이언트에 가려 놓는 것이 유지보수에 좋습니다. 클라이언트는 그냥 자신의 디스플레이 해상도를 전달하기만 하고, 서버에서 적절히 계산하여 알맞은 해상도의 스티커 파일을 내려주는 것이 가장 좋습니다. 이를 위해 스티커 다운로드 URL을 아래와 같은 형태로 디자인하고자 하였습니다.http://dl.sticker.vcnc.co.kr/[sticker_id].sticker?density=[dpi_of_device]하지만 S3와 CloudFront 조합으로만 위와 같은 URL 제공은 불가능하며 따로 다운로드 서버를 운영해야 합니다. 그렇다고 EC2에 따로 서버를 운영하는 것은 안정적인 서비스 운영을 위해 신경써야할 포인트들이 늘어나는 것이어서 부담이 너무 컸습니다. 그래서, 아래와 같이 GAE를 사용하기로 하였습니다.GAE는 구글에서 일종의 클라우드 서비스(PaaS)로 구글 인프라에서 웹 어플리케이션을 실행시켜 줍니다. GAE에 클라이언트에서 요청한 URL을 적절한 S3 URL로 변환해주는 어플리케이션을 만들어 올렸습니다. 일종의 Rewrite Engine 역할을 하는 것입니다. 서비스의 안정성은 GAE가 보장해주고, S3와 CloudFront의 안정성은 AWS에서 보장해주기 때문에 크게 신경쓰지 않아도 장애 없는 서비스 운영이 가능합니다. 또한 CloudFront에서 스티커 파일을 최대한 캐싱 하며 따라서 GAE를 통해 새로 요청을 하는 경우는 거의 없기 때문에 GAE 사용 비용은 거의 발생하지 않습니다. GAE에는 클라이언트에서 보내주는 해상도를 보고 적당한 해상도의 스티커 파일을 내려주는 아주 간단한 어플리케이션만 작성하면 되기 때문에 개발 비용도 거의 들지 않았습니다.토큰을 이용해 보안 문제를 해결하다실제 스티커를 구매한 사용자만 스티커를 사용할 수 있어야 합니다. 스티커 토큰을 이용해 실제 구매한 사용자만 스티커를 전송할 수 있도록 구현하였습니다. 사용자가 스티커 스토어에서 스티커를 구매하게 되면 각 스티커에 대한 토큰을 얻을 수 있습니다. 스티커 토큰은 다음과 같이 구성됩니다.토큰 버전, 스티커 아이디, 사용자 아이디, 유효기간, 서버의 서명서버의 서명은 앞의 네 가지 정보를 바탕으로 만들어지며 서버의 서명과 서명을 만드는 비밀키는 충분히 길어서 실제 비밀키를 알지 못하면 서명을 위조할 수 없습니다. 사용자가 자신이 가지고 있는 스티커 토큰과 그에 해당하는 스티커를 비트윈 서버로 보내게 되면, 비트윈 서버에서는 서명이 유효한지 아닌지를 검사합니다. 서명이 유효하다면 스티커를 전송이 성공하며, 만약 토큰이 유효하지 않다면 스티커의 전송을 허가하지 않습니다.못다 한 이야기비트윈 개발팀에게 스티커 기능은 개발하면서 우여곡절이 참 많았던 프로젝트 중에 하나 입니다. 여러 가지 시도를 하면서 실패도 많이 했었고 덕분에 배운 것도 참 많았습니다. 기술적으로 크게 틀리지 않다면, 빠른 개발을 위해서 가장 익숙한 것으로 개발하는 것이 가장 좋은 선택이라는 알게 되어 스티커 스토어를 Python 대신 Java로 구현하게 되었습니다. 현재 비트윈 개발팀에서 일부 웹사이트와 스크립트 작성 용도로 Python을 사용하고 있지만 Python을 잘하는 개발자가 있다면 다양한 프로젝트들를 Python으로 진행할 수 있다고 생각합니다. 팀내에 경험을 공유할 수 있는 사람이 있다면 피드백을 통해 좋은 코드를 빠른 시간안에 짤 수 있고 뛰어난 개발자는 언어와 상관없이 컴퓨터에 대한 깊이 있는 지식을 가지고 있을 것이기 때문입니다.네 그렇습니다. 결론은 Python 개발자를 모신다는 것입니다.
조회수 994

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

지그재그 채용 페이지>> https://career.zigzag.kr오늘은 지그재그 서비스를 위해 각자의 파트에서 이끌어주시는 개발자 두 분! Dev. 팀의 정수님, 형래님과 함께 활발히 채용 중인 [백엔드 개발자]에 대해 파헤쳐 보도록 하겠습니다 :-)Chapter 1. 저를 소개합니다!Q. 정수님, 형래님 반갑습니다! 지난 인터뷰를 통해 궁금한 포지션으로 백엔드 개발자가 선정되었는데요! 인터뷰이로 선정된 간단한 소감과 자기소개를 부탁드립니다.정수, 형래 네.. 좋네요.(기뻐하지 않으시는군요! 저희의 예상과 다르게..)형래 일단은 왜 제가 첫 번째로 인터뷰이가 되지 않았는지 굉장히 서운하게 생각하고요.(웃음) 그래도 지그재그에서 이런 인터뷰를 해보는구나 싶네요.정수 저는 전형적인 부끄러움이 많은 개발자라서요. 부담도 많이 가고, 긴장되네요. '잘해야 되겠다.'라는 생각이 마구 듭니다.(웃음)형래 저는 자기소개를 준비해 왔어요! 사실 제가 6-7년 전부터 사용하고 있는 건데요, 저를 '줄기세포 개발자'라고 표현합니다. 줄기세포가 아무 데나 이식이 된다고 하더라고요. 그래서 저를 개발이 필요한 곳에 가져다 두면 개발을 하고, 매니징이 필요한 곳에 가져다 두면 매니징도 하다가.. 인프라가 필요한 곳에 가면 인프라도 해요. 가리지 않고 다 해서 다른 사람들이 물어보면 '줄기세포 개발자'라고 말하고 다닙니다.우리의 소중한 디에네이 형래님정수 저는 지그재그의 Z결제라는 기능에서 주문과 결제, 물건을 받아보기까지의 과정을 책임지고 있어요. 좋은 개발자가 되기 위해서는 공부가 필수라고 생각하는데요, 개발 기술뿐만 아니라 본인이 만들어가는 제품과 서비스에 대해서도 항상 열심히 공부해야 된다고 생각합니다. 지금 담당하고 있는 업무도 결제 서비스에 대한 지식이 사실상 전무한 상태에서 시작했는데, 많이 찾아보고 공부도 하면서 열심히 만들어가고 있어요.형래 제가 담당하고 있는 역할에 대해서도 말씀드릴게요. Z결제 쪽은 정수님께서 맡아주고 계시고, 저는 그 외에 지그재그 서비스 전반에 있어서 사용자의 UX를 개선하거나 쇼핑몰을 연동하는 등의 서버 개발을 담당하고 있어요.Q. 정수님은 크로키닷컴 초창기 멤버이셨다가 재입사를 하신 거고, 형래님은 K모 대기업을 다니시다가 지그재그에 합류하셨다고 들었어요. 두 분 다 지그재그를 선택하신 특별한 이유가 있었나요?정수 처음 입사했던 건 2012년이었어요. 그땐 지그재그 서비스가 아닌 다른 서비스들을 개발할 때였고요. 그때 한창 스타트업 열기가 모락모락 피어오를 때였는데, 스타트업에서 새로운 걸 해보겠다는 도전정신을 가지고 합류하게 됐고 거의 2년 가까이 함께 했었던 것 같아요. 그러다가 창업을 하려고 떠났었는데, 그 후 몇 년 만에 크로키닷컴이 지그재그 서비스를 오픈하고 급격하게 성장하고 있더라고요. 함께 일했었던 기억도 너무 좋았고, 지그재그라는 서비스도 앞으로 할 수 있는 것들이 많을 것 같아 너무 매력적으로 다가왔던 것 같아요. 그래서 2018년에 다시 합류해서 열심히 다니고 있습니다.형래 저는 우연히 쟈니님(CEO), 정훈님(COO)과 저녁을 먹었었는데, 그때 얘기해주셨던 지그재그 서비스가 너무 궁금하고 직접 경험해보고 싶었어요. 사실 대기업을 퇴사하게 된 이유가 스타트업을 창업해보고자 했거든요, 물론 잘 안됐지만.. 그때 저는 '잘 되는 스타트업은 어떻게 해서 잘 될 수 있었을까?'라는 궁금증이 항상 있었어요. 저녁을 같이 먹으면서 두 분이 지그재그 서비스에 대해 말씀해 주셨을 때 두 분의 엄청난 열정과 확신이 느껴졌고, 저도 그 두 분 못지않은 열정을 지닌 사람이라는 것을 보여주고 싶다는 생각이 들었어요. 그래서 저녁 먹은 다음날인가? 바로 연락드렸어요, 합류하겠다고.(웃음) 저는 자신 있었거든요.지그재그 개발팀의 컨피던스(오 그런 비하인드가 있었군요! 그럼 실제로 입사 후에 경험한 지그재그 팀은 어떠셨나요?)형래 지그재그 팀은 다른 회사들과는 약간 다르게, 극단적으로 사용자의 편의성에 치중해요. 음.. 고객의 입장에서 봤을 땐, 업자의 욕심이 느껴지지 않는다고 해야 하나? 직접 와서 겪어보니 역시나 그랬고요. 이러한 마인드가 우리 서비스에 긍정적인 효과를 많이 가지고 온다고 생각합니다.(그럼 정수님은 이전의 회사의 모습과 지금의 회사의 모습이 어떻게 달라졌다고 느끼시나요?)정수 처음은.. 5명이었을 때였어요. (지금은 무려 97명!) 지금이나 그때나 모두 열정이 넘치는 건 같아요. 다만 방향성이 다른 에너지죠. 예전에는 서비스가 빨리 좋은 반응을 얻지 못하면 회사가 망할 수도 있다는 위기의식을 가지고 소수의 멤버들과 더 끈끈하게 열정을 가지고 하루하루에 임하는 느낌이었어요. 반면에, 지금은 지그재그 팀이 그동안 쌓아온 탄탄한 기반을 바탕으로 새로 도전해볼 수 있는 다양한 과제들이 훨씬 더 많이 기다리고 있고, 그 과제들을 하나씩 함께 해결해나갈 팀원들도 많아져서 그 에너지가 나날이 더 커지는 것 같아요. Q. 두 분의 경력을 합쳐보니 240개월 이더라고요! 그만큼 다양한 회사를 경험해보셨을 것 같은데요. 유독 지그재그 팀만이 지닌 특이한 점이 있다면 소개해주세요!항상 열정 넘치는 Dev. 팀!형래 이전 회사들은 사실 경험이 많은 사람들만 뽑았어요. 아무래도 경험이 많이 쌓이다 보면 점점 더 나에게 편하고 익숙한 방식을 찾아 문제를 해결하려는 유혹에 빠지기가 쉬운 것 같아요. 물론 경험이 쌓여도 새로운 것에 대해 계속 공부하고 고민하시는 분들도 많이 계시지만, 절대 쉬운 일은 아니죠. 근데 지그재그 팀에는 비록 경험은 조금 적은 편인 분들이 많이 있어도, 옆에서 보고 있으면 항상 열정이 넘치는 사람들이에요. 매 순간 공부를 하려고 하거든요. '어떻게 하면 내가 성장할 수 있을까?'라고 생각하는 사람들이 대부분이라 개인적으로 신기하기도 합니다. 정수 저는 급성장하고 있는 회사에서 일해본 건 지그재그 팀이 처음이에요. 생소하기도 하고, 지루할 틈이 없어요.(웃음) 지금도 매우 빠르게 성장하고 있습니다.Chapter 2. 우리는 이렇게 일해요!Q. 두 분은 파트 내에서 추구하는 특별한 업무 방식이 있으신가요?형래 결함을 최대한 앞 단계에서 찾자! 이게 저희 팀 콘셉트이에요. 설계 단계에서 찾은 오류를 의논해서 해결하고 나면 훨씬 손이 덜 들거든요. 아무리 바쁘더라도 Scrum 을 꼭 진행하고 있습니다. 또, 개발하고 있는 서비스에 대한 품질도 더욱 높이기 위해서 Iteration 작업도 새로 제안해서 정착 단계에 있어요.(파트 매니저로서는 중요하게 강조하는 업무 방식이 따로 있나요?)형래 각 팀원이 하나의 일을 맡으면, 그분을 최대한 안 괴롭히는 게(?) 제 원칙이에요. 팀원들이 일에 집중할 수 있게끔 도와주는 게 매니저의 가장 큰 일이라고 생각하거든요. 그러다 보니 다른 팀 팀원 분들이 커뮤니케이션적인 부분에서 약간 불편해하셔서, 그 부분을 해결하기 위해 요즘 가장 노력하고 있어요.정수 저희는 기록을 강조하고 있어요. 지금 저희 파트에서는 결제라는 새로운 기능을 개발하고 있다 보니까 기록을 남기지 않고 그냥 일을 진행하다 보면 혼선이 생기기 마련이거든요. 다 같이 붙어서 만들고 있으니, 기록을 하면서 개발하는 걸 강조하고 있습니다.(그렇다면 두 분은 파트의 팀워크를 향상하기 위해 노력하고 계시는 부분이 있을까요?)정수, 형래 음 팀워크는.. 법카에서 나온다? 농담이고요. (웃음)형래 조금 식상한 얘기일 수도 있는데, 저는 각자 role이 다르다고 생각해요. 제가 윗사람이고 팀원들이 아랫사람인 것이 아니라, 전 매니징 하는 역할을 가지고 있고 팀원들은 또 다른 각자의 역할을 가지고 있는 거라고요. 그렇게 각자 역할이 다른 거라고 항상 말씀드리면, 팀원들도 평소에 본인의 의견을 좀 더 자유롭게 이야기할 수 있는 것 같고 결과적으로 좀 더 책임감을 가지고 일할 수도 있고 재미도 느끼는 것 같아요. 다만 제가 팀원들이랑 나이차가 좀 나는 바람에.. 아무래도 어려워하시는 분도 계셔서 앞으로 더 많이 노력해야 할 것 같네요. 제가 제대할 때 태어나신 분도 계시거든요.(웃음) 정수 저희 파트에서는 태스크마다 다른 팀원과 짝을 지어서 같이 진행하는 방식을 적용해보고 있어요.그중에서 특히나 강조하는 건 '각자의 장단점이 다르니 서로의 장점을 잘 활용하고 단점을 보완해주자'는 건데요, 그러기 위해 여러 시도들을 해보면서 경험을 쌓아가는 중입니다. Q. 지그재그에서 겪는 백엔드 개발자로서 좋은 점과 어려운 점이 있으신가요?정수 보통 큰 회사에서는 개발자가 서비스의 시작부터 끝까지 모두 경험해볼 수 있는 기회가 흔하지는 않은 것 같아요. 그런데 지그재그 팀에서는 처음 기획 단계부터 함께 참여하고 만들어나가는 경험을 해볼 수 있어요. Z결제도 마찬가지였고요. 앞으로도 새로 도전해나가야 하는 과제들이 많아서, 본인이 주도적으로 이끌어서 개발할 수 있는 기회가 많은 게 가장 좋은 점인 것 같아요.형래 어려운 점은 우리가 아직은 메타 서비스에서 커머스로 변화해가는 과정이다 보니, 서비스에 우리만의 색깔을 담아내거나 편의성을 맞춰나가는 부분이 어려운 것 같아요. 하지만 날이 지날수록 점점 맞춰지고 있는 것 같아요, 그만큼 회사가 성장하고 있다는 거겠죠? 아! 그리고 우리는 typescript와 node.js라는 기술을 사용하고 있는데, 아직 많이 사용되는 기술은 아니라 경험해보지 않은 분들은 어려워하실 수 있지 않을까 싶어요. 그래도 새로운 기술에 대해 거부감 없이 호기심을 가지고 적극적으로 배우려고 하시는 분이라면, 지그재그 팀이 사용하는 기술도 금방 익혀서 사용하실 수 있을 거예요. 저도 입사하고 나서 많이 배웠거든요.(웃음)열심히 작업 중이신 형래님! (Feat. 형래님 얼굴이 그려진 텀블러)Chapter 3. Dev. 팀은 이런 분을 찾아요!Q. Dev. 팀에서 찾는 백엔드 개발자는 어떤 분인지 설명 부탁드려요!정수, 형래 우선, 우리 회사는 실험적인 회사이기 때문에 개발에 재미를 붙이고 일하실 수 있는 분이면 좋겠어요. 그리고 기술에 대한 근본적인 이해가 필요한 것 같아요. 그 언어의 특징이 무엇이고, 본인이 왜 이 언어를 사용했는지에 대해 설명해줄 수 있어야 한다고 생각하거든요. 혹은 자기가 만든 프로젝트를 얼마나 깊이 있게 고민해보고 만들었는가에 포커스를 많이 둡니다. 솔직히 말씀드리면, 차이가 나요! 깊이 있게 고민하면서 만들어보신 분들은 이미 몇 년이 지난 프로젝트라고 하더라도 바로 어제 일처럼 설명을 잘하시거든요.Q. 백엔드 개발자 예비 지원자분들께 하고 싶은 말씀이 있으신가요?형래 사실 인터뷰에서 떨어지는 건 본인의 실력이 부족해서라기 보다는, 회사의 성향과 맞지 않아서인 확률이 매우 커요. 그러니 인터뷰 때 너무 긴장하지 마시고, 편하게 본인의 모습을 어필해주셨으면 좋겠어요. 서류 지원도 편하게 해 주셨으면 좋겠고요, 각자의 fit이 지그재그와 잘 맞는지 확인하는 하나의 절차니까요.정수 형래 님이 아까 말씀하신 것 중에, 우리 팀은 '실험적인 시도를 하는 회사'라고 하셨잖아요. 현재보다 더 나은 시스템을 만들기 위한 노력 중에 하나라고 봅니다. 항상 지금에 만족하지 않고 더 나은 시스템을 구현하기 위해 노력하고 있거든요. 본인이 더 나아가고 싶은 길이 있다면 저희 회사와 정말 잘 맞을 거예요!Chapter 4. 마무리Q. 2020년 두 분의 목표가 있으신가요?정수, 형래 좋은 분들을 많이 영입하자!형래 저는 벌써 세 분이나 소개해서 모셔왔는데요, 더 열심히 노력할 예정입니다. 그리고 개인적인 목표는 건강을 유지하자는 겁니다. 더 건강해지는 것은 바라지도 않아요..정수 저도! 작년에는 많이 아팠어요.형래 그리고 회사에 초코류 간식이 많아서, 제 건강을 위해 건자두 같은 자연식품(?) 위주로 많이 사다주시면 제 건강에 많은 도움이 되지 않을까 싶은 소소한 바람입니다.(웃음)Relations팀: 건...ㅈㅏ..두... for.... 형ㄹㅐ.. 정..수...님....Q. 다음으로 인터뷰를 진행했으면 하는 팀이 계신가요? 궁금한 팀이 있으면 말씀해주세요!정수, 형래 마케팅 팀이요. 우리 회사 마케팅 팀이 워낙 잘하고 계시는 것 같다고 입사 전부터 느꼈거든요. 팀에서 어떻게 일하시는지 궁금해요!지그재그에서는 백엔드 개발자를 포함하여 활발하게 채용을 진행하고 있습니다. 지그재그 팀과 함께, 수면 아래 숨겨진 가치를 찾아내는 경험에 동참할 팀원을 꼭 모시고 싶습니다 :-) 궁금하신 점은 언제나 [email protected] 또는 http://facebook.com/zigzagcareer로 연락 주세요!지그재그 [백엔드 개발자] 포지션을 소개합니다!이런 일을 합니다.이런 분을 모십니다.이 중 하나라도 가능하시다면 더더욱 좋아요 :)지원 방법채용 절차혜택과 복지   더 많은 공고는 채용 사이트에서 확인 가능합니다! >>> 채용 사이트 바로가기
조회수 1738

변화하는 웹 플랫폼 따라가기

플랫폼이 어떻게 변화해가는지를 살펴보면, 직접 경험해보지 않더라도 사람들의 문제의식이 어디에 있는지, 어떤 문제들이 언제부터 풀리게 되는지를 파악할 수 있습니다.이 글에서는 이런 변화들을 살펴볼 수 있는 몇가지 유용한 링크들을 소개하려고 합니다.어떤 논의들이 어디서 오가고 있을까WICG discoursehttps://discourse.wicg.io/WICG는 웹 인큐베이터 커뮤니티 그룹이라고 해서, 웹 표준에 기여해본 사람이 아니라도 토론을 통해 아이디어를 발전시켜서 사람들이 실제로 겪는 문제를 W3C 표준까지 끌어올리는 것을 목표로 하는 커뮤니티입니다.이 곳에서는 주로 CSS, DOM API에 대한 아이디어가 올라옵니다.ES-Discusshttps://esdiscuss.org/ES-Discuss는 WICG와 비슷하게 ECMAScript 스펙에 대해서 논의하는 메일링 리스트입니다. 위 링크는 메일링 리스트에서 오간 이야기를 쉽게 조회할 수 있도록 아카이빙 해놓은 사이트입니다.논의된 아이디어는 어디서 표준으로 다듬어지고 있을까HTML: https://github.com/w3c/html 또는 https://github.com/whatwg/htmlCSS: https://github.com/w3c/csswg-draftsJS: https://github.com/tc39/ecma262HTML은 W3C의 WebPlat WG와 WHATWG에서, CSS는 W3C의 CSSWG에서, JS는 ECMA의 TC39에서 표준을 이끌고 있습니다.위 저장소들에 공개된 초안은 표준이 되기까지 여러 단계를 거치게 되는데, 여기서 다루지는 않겠습니다. (2018-01-25 수정) 이에 대한 내용은 다음의 블로그 포스트에서 자세히 설명하고 있습니다.W3C 표준화 제정 단계ECMAScript와 TC39다듬어진 표준은 어떤 브라우저에서 얼마나 구현되고 있을까다음의 링크에서 각 주제에 대해 브라우저들이 현재 어디까지 구현을 했는지 파악할 수 있습니다.Chrome: https://www.chromestatus.com/featuresFirefox: https://platform-status.mozilla.org/Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/status/Safari: https://webkit.org/status/크롬 플랫폼 사이트의 경우 각 주제들이 어떤 버전에 반영되었는지 같이 확인할 수 있어서 편리합니다.나머지 브라우저들의 버전별 구현 상태는 https://caniuse.com/에서 주제를 검색하여 참고할 수 있습니다.구현된 기능들은 언제부터 사용할 수 있었고, 언제부터 사용할 수 있게 될까크롬과 파이어폭스는 릴리즈 캘린더를 공개적으로 관리하고 있습니다. 위에서 확인한 기능들을 담고있는 안정 버전이 언제쯤 릴리즈 될 지 다음의 링크를 보고 대략적으로 예상할 수 있습니다.Chrome: https://www.chromium.org/developers/calendarFirefox: https://wiki.mozilla.org/RapidRelease/Calendar크롬과 관련된 플랫폼 따라가기특정 크롬 버전이 어떤 V8 버전을 사용하고 있는지는 https://omahaproxy.appspot.com/에서 확인할 수 있습니다.Node.jsNode.js의 릴리즈 스케쥴은 https://github.com/nodejs/Release에서 확인할 수 있습니다.어떤 Node.js 버전이 어떤 V8 버전을 사용하고 있는지는 https://nodejs.org/en/download/releases/에서 확인할 수 있습니다.Electronhttps://electronjs.org/에서 일렉트론 최신버전이 어떤 노드, 크로미움, V8 버전을 사용하고 있는지 확인할 수 있습니다.일렉트론의 크로미움 팔로업은 깃헙 일렉트론 저장소의 Projects에서 확인할 수 있습니다: https://github.com/electron/electron/projects따라가는데 도움이 되는 블로그브라우저 벤더들이 직접 운영하는 블로그를 구독하면 웹 플랫폼의 소식을 가장 빠르게 접할 수 있습니다.ChromeChromium Blog: https://blog.chromium.org/V8 Blog: https://v8project.blogspot.kr/FirefoxMozilla Hacks: https://hacks.mozilla.org/SafariWebKit Blog: https://webkit.org/blog/EdgeMicrosoft Edge Dev Blog: https://blogs.windows.com/msedgedev/(2018-01-25 수정): @SaschaNaz님 제보로 Webkit status 사이트와 Edge 블로그 추가#스포카 #개발팀 #개발자 #인사이트 #업무일지 #후기
조회수 1608

개발자 커리어 전환기1| 하드웨어 개발자, 소프트웨어 개발자가 되기로 마음먹다.

개발자는 도대체 어떻게 되는 거고 누가 되는 거야?코드스테이츠가 가장 많이 받아온 질문 중 하나입니다. 그래서 준비한 특급 연재! 개발자 커리어 전환기! 매주 Immersive를 수강하고 있는 수강생 한 분과 인터뷰해서 어떻게 개발을 시작하게 되었는지, 또 현재 무엇을 배우고 있는지에 대한 인터뷰를 포스팅하려고 합니다.아무것도 모르는 비전공자 출신 분들이(물론 전공자 분도 계십니다!) 개발자가 되어가는 과정을 생생하게 보실 수 있습니다. 그럼, 첫 번째 포스팅의 주인공 이야기를 시작하겠습니다.코드스테이츠 코딩 부트 캠프, Immersive 6기 과정이 시작되었습니다. 지난 5기 데모데이를 들뜬 마음으로 지켜보던 Pre-course 수강생들이 어느덧 새로운 Immersive 과정의 주인공이 되었는데요.오늘은 하드웨어 개발자 출신으로서 커리어 전환을 위해 코드스테이츠를 찾아온 6기의 전한길님을 만나봤습니다. Q) 한길님 반갑습니다. Precourse 수료를 축하드리며 간단한 자기소개 부탁드려요.- 안녕하세요! 전한길입니다.Q) 정말 간단하네요! 보통은 인터뷰어를 위해 좀 더 길게 합니다만...- 아... 전 대학에서 전자공학을 전공했고요. 어쩌다 보니 전자회로 설계일을 하게 되었어요. 원래는 소프트웨어 쪽에 관심이 있었는데 하드웨어 쪽으로 일을 했습니다. 사실, 당시에는 집 가까운 회사를 찾다보니..(웃음) 어쨌든! 커리어 전환을 위해 코드스테이츠에 오게 되었습니다.Q) 원래 이쪽에 관심이 있으셔서 소프트웨어 엔지니어로 커리어 전환을 하시는 건가요?- 자신만의 기술을 가질 수 있다는 점이 좋아서 소프트웨어 엔지니어를 하기로 결심했어요. 저는 회사생활을 6년 동안 했는데요. 하루하루 똑같은 업무와 일상이 지루하더라구요. 직급이 올라간다고 해서 더 나아질 거 같지도 않았고...사실 깊이 생각하는 성격이 아니에요. 무작정 회사를 나와서 고민했죠. 그러다가 "나만의 기술을 가질 수 있는 매력적인 직업을 갖자"는 저만의 원칙을 고수한 끝에 소프트웨어 엔지니어가 되기로 결심했어요.Q) 그러면 특별히 코드스테이츠를 선택하신 이유가 무엇인가요?- 처음에는 국비지원과정도 알아봤어요. 국비지원과정에서 공부를 할까 하다가 우연히 친구 소개로 코드스테이츠를 알게 되었죠.'자기 주도적 학습'이라는 단어에 끌렸어요. 전 코딩이 언어랑 비슷하다고 생각하거든요. 문법을 잘 안다고 영어를 잘하는 건 아니잖아요. 아는 것도 중요하지만 습관이 중요하다고 생각해요. 지름길을 가면서 스스로 코딩을 많이 해볼 수 있을 거 같아서 코드스테이츠를 선택하게 되었죠.코딩은, 아는 것도 중요하지만 습관이 중요하다고 생각해요Q) 이건 개인적으로 매우(?) 긴장되는 질문인데, 실제로 Pre-course는 어땠나요?- 코드스테이츠 학습 방식 자체가 강의식이 아니다 보니 생각한 대로 '자기 주도적 학습 위주'고, 특히 실제로 코딩을 많이 해봐서 좋았어요.그리고 위에서 얘기한 것처럼 저는 지름길이 필요했는데요. 방향을 잘 잡아주셔서 좋았어요. 단계별로 공부할 수 있는 내용이 잘 정리되어있더라구요. 시간을 효율적으로 쓸 수 있었습니다.Q) 담당자로서 매우 뿌듯한 답변이네요. :) 특히 어떤 프로젝트가 가장 기억에 남나요?- *twittler 를 만들었을 때가 가장 기뻤어요. 뭐라고 말로 표현하기는 어려운 감정인데, 실제로 눈에 보이는 걸 만들었을 때 성취감이 크더라구요. 그 성취감이 동기부여가 되어서 더 열심히 했던 거 같습니다.*twittler: 코드스테이츠 Pre-course과정에서 수행하는 프로젝트로, 트위터의 일부 기능을 구현한 프로그램한길님이 구현한 twittlerQ) 이제 막 Immersive 과정이 시작되었는데요. 과정에서는 어떤 걸 기대하나요?- 코드스테이츠의 체계적인 커리큘럼과... 웹 개발자로 취업하는 거??Q) 교과서 같은 답변이네요.^^ 3개월 뒤면 웹 개발자가 되어있을 거라고 믿습니다. 그렇다면 어떤 개발자가 되고 싶나요?- 기술을 잘 아는 개발자가 되고 싶어요. 개인적으로 호기심이 많아요. 블록체인부터 빅데이터까지.. 새로운 기술과 관련된 단어들을 들으면 호기심이 생기죠. 이렇게 호기심이 생겼을 때 그 기술에 대해 이해하고 실제로 기술을 잘 구현하는 개발자가 되고 싶어요. 소위 말하는 백엔드 쪽에 더 관심이 있는 거 같아요. 앞으로도 이 방향으로 나아가고 싶구요.음.. 그리고 하나만 덧붙이면, 제 생활도 잘 지킬 수 있는 개발자가 되고 싶어요. 일도 일이지만.!Q) 마지막으로 코드스테이츠를 다른 사람에게 추천한다면?소프트웨어 엔지니어가 되고 싶으신 분들에게 꼭 추천하고 싶어요. 독학을 해도 좋은 점이 있겠지만.. 체계적인 커리큘럼을 따라가면서 방향성 있는 공부를 하면 효율적일 거 같아요. 시간을 아낄 수 있죠. 커리어 전환을 고민하시는 분들에게도 적합하구요.그리고 무엇보다 같은 길을 가는 사람들과 커뮤니티를 형성하고 함께 공부할 수 있다는 점이 코드스테이츠의 가장 큰 장점이라고 생각합니다.

기업문화 엿볼 때, 더팀스

로그인

/