스토리 홈

인터뷰

피드

뉴스

조회수 1623

워크인사이트 프론트엔드 개발환경

조이코퍼레이션은 오프라인 고객 분석 서비스인 워크인사이트를 만들고 있습니다. 워크인사이트는 스마트폰 신호를 통해 매장 방문객의 출입 및 체류 패턴을 측정하고 분석합니다. 분석된 데이터는 웹 대시보드를 통해 한 눈에 파악하기 쉬운 형태로 매장에 제공됩니다. 매장들은 이 대시보드를 보고 중요한 판단과 의사 결정을 내리기 때문에 대시보드는 보기 쉬워야 하고 쓰기 편해야 하며 무엇보다 아름다워야 합니다. 조이의 빅데이터 기술을 통해 분석된 데이터를 매장에 효과적으로 전달하기 위해 프론트엔드 기술에 많은 노력을 기울이고 있습니다. 이 글에서는 조이의 대시보드를 만들기 위해 사용하고 있는 기술과 개발 환경 그리고 기술적인 관점에서 고민하고 있는 부분들을 간략하게 공유하고자 합니다.그림1. 대시보드 화면사용하는 기술AngularJS: AngularJS를 기본 프레임워크로 사용하고 있습니다. AngularJS는 SPA (Single Page Application) 형태의 웹 애플리케이션을 빠르게 개발할 수 있도록 도와주는 MVC 프레임워크입니다. 조이에서는 현재 프로덕션 버전인 1.3.x를 사용하고 있습니다. 대시보드는 사용자의 이벤트에 따라 동적으로 데이터를 변경해야하는 애플리케이션적 요소가 많기 때문에 AngularJS의 양방향 데이터 바인딩의 유용함을 느끼고 있습니다.D3.js: 다양한 그래프를 아름답게 보여주기 위해서 D3.js를 사용합니다. D3.js는 데이터 시각화를 위한 자바스크립트 라이브러리로, HTML/CSS/SVG 등의 웹 기술을 이용해 그래프를 그릴 수 있습니다. 자유도가 매우 높아서 생각할 수 있는 많은 형태의 그래프를 그릴 수 있으며 부드러운 전환이나 애니메이션도 추가할 수 있습니다. 다만 초기 학습 비용이 높고 신경쓰지 않으면 너저분한 코드가 양산될 수 있다는 단점도 있습니다.CoffeeScript: 자바스크립트를 더 깔끔하고 효율적으로 사용할 수 있도록 Compile to JS 언어를 사용하는데, 여러 선택 사항 중 CoffeeScript를 사용하고 있습니다. CoffeeScript는 문법적 간결함 덕분에 타이핑을 줄이고 빠르게 코드를 작성할 수 있습니다. 특히 클래스와 클래스 상속 등을 문법적으로 지원하기 때문에 OOP적인 설계를 할 때 도움을 받았습니다. 하지만 자바스크립트와는 다른 새로운 문법을 익혀야하고 그마저도 일관성이 떨어지는 문제가 있습니다. 또 특별한 신경을 쓰지 않으면 가독성이 안 좋은 코드를 작성하기 쉽습니다. 조이에서는 Lint 툴과 코드 리뷰를 통해 코딩스타일을 엄격히 제한하고 있습니다.개발 환경빌드 및 배포: Bower와 npm(Node Package Manager)을 이용해서 패키지를 관리합니다. 빌드 시에는 JS Minify & Uglify, HTML/CSS 최적화, CoffeeScript Lint를 통한 코드 품질 검증, Karma를 이용한 테스트 수행 등의 과정을 거치며 이 모든 빌드 과정은 Grunt를 사용하여 자동화하고 있습니다. 빌드가 끝난 파일들은 AWS (Amazon Web Service)의 S3 저장소로 배포하고 있습니다. 배포 과정 역시 Grunt의 task로 자동화되어 있습니다.코드 관리: 모든 코드는 Jenkins로 통합되어 자동화된 테스트를 통과해야 합니다. 모든 커밋은Gerrit을 통해 다른 엔지니어의 리뷰를 거쳐야만 머지를 할 수 있습니다. 따라서 모든 코드는 적어도 둘 이상의 엔지니어가 이해하고 있습니다. 같은 코드에 대해 더 좋은 설계가 있는지 논의하면서 함께 코드를 발전시켜 나갑니다. 더 좋은 설계가 발견될 때마다 수시로 리팩토링을 진행합니다.프로젝트 관리: 디자이너와 엔지니어 그리고 기획에 참여하는 데이터 분석가 등은 Trello를 이용해 태스크와 이슈를 관리합니다. 일주일을 한 번의 스프린트로 보고 매주 월요일에 일을 분배하고 금요일에 회고를 합니다. 이 과정에서 엔지니어도 기획에 능동적으로 참여할 수 있으며, 어떤 데이터를 어떤 형태의 그래프로 보여주어야 효과적인지를 함께 고민할 수도 있습니다.그림2. 트렐로를 이용한 프로젝트 관리지속적으로 고민하는 부분성능 이슈: 대시보드에는 많은 수치 데이터를 다룹니다. API 서버로부터 하나의 큰 JSON 데이터를 받아서 시간별/일별/요일별/날씨별/최고기온별/평일휴일별 방문객 정보, 방문전환율/체류전환율/구매전환율 등의 지표를 그리기 위한 데이터로 가공합니다. 여기에는 계산량이 적지 않기 때문에 성능에 대한 고민을 많이 하게 됩니다. 연산 로직을 더 간단히 하거나 더 적게 Draw/Redraw 하는 방법을 고민하고 응답성을 향상시키기 위해 Async하게 연산하는 등의 고민을 합니다. 설계: 대시보드는 빠르게 업그레이드됩니다. 기능이 추가되고 변경됨에 따라 그에 맞는 좋은 설계도 계속해서 변합니다. 수시로 진행하는 리팩토링이 좋은 설계를 만든다고 생각합니다. 따라서 리팩토링에 쓰는 시간을 아까워하지 않습니다.테스트: 테스트는 매우 중요합니다. 특히 버그로 인해 잘못된 데이터가 보여지는 것은 용납될 수 없습니다. 그래서 데이터를 가공하는 로직에 대한 테스트는 엄격하게 수행됩니다. 설계 단에서도 테스트하기 쉬운 코드를 작성하려고 노력합니다.최신 기술: 조이의 프론트엔드 팀은 최신 기술에 민감합니다. Gulp, Angular 2.0, EcmaScript6, TypeScript, React와 같은 자바스크립트 최신 기술들에 관심을 갖고 그들의 기본 철학이나 장단점들을 파악하려고 노력합니다. 때때로 우리에게 더 잘 맞는 기술이 등장하면 과감하게 적용하기도 합니다.맺음말조이는 임베디드 기술과 빅데이터 기술을 보유한 기술 회사입니다. 그러나 프론트엔드 기술 역시 그 못지 않게 중요하게 생각하고 있습니다. 말뿐이 아니라 며칠 전에는 OKKY 자바스크립트 컨퍼런스에 후원을 하고 좋은 자바스크립트 개발자들을 만나기 위해서 부스를 차리기도 했습니다. 앞으로도 프론트엔드 기술 관련 컨퍼런스에 후원도 하고 기여도 계속 할 계획입니다.저도 조이에서 엔지니어로 일하면서 훌륭한 동료 엔지니어들과 함께 많은 성장을 했습니다. 무엇보다 기술적인 욕심과 의욕이 넘치는 분위기 속에서 일하는 것 자체가 즐겁고요. 혹시 이 글을 읽고 위와 같은 고민을 공유하고 폭풍 성장을 함께 할 멋진 자바스크립트 개발자가 있다면 이 글을 읽어보시길 바래요 :)그림3. OKKY 자바스크립트 컨퍼런스 부스#조이코퍼레이션 #개발팀 #개발자 #개발환경 #업무환경 #기업문화 #조직문화
조회수 7175

클라우드 서비스 이해하기 IaaS, PaaS, SaaS

클라우드 컴퓨팅은 인터넷으로 가상화 된 IT 리소스를 서비스로 제공하는 것을 의미합니다. 그리고 클라우드 컴퓨팅에서 가상화 하여 서비스로 제공하는 대상은 인프라스트럭쳐, 플랫폼, 소프트웨어입니다. AWS와 Azure가 대중화되면서 클라우드를 인프라스트럭쳐의 가상화 개념으로만 이해하기도 하지만 클라우드는 인프라스트럭쳐 뿐만이 아니라 플랫폼과 소프트까지 포함하는 온라인의 모든 영역을 다루는 꽤 광범위한 개념입니다. 그렇기 때문에 클라우드는 분야별 특성별로 나누어서 이해하는 것이 좋습니다. 클라우드 서비스의 종류는 아래와 같이 크게 3가지로 나눌 수 있습니다. Infrastructure as a Service (IaaS, 아이아스, 이에스)서비스로 제공되는 인프라스트럭처입니다. 개발사에 제공되는 물리적 자원을 가상화합니다. Platform as a Service (PaaS, 파스)서비스로 제공되는 플랫폼입니다. 개발사에 제공되는 플랫폼을 가상화합니다.Software as a Service (SaaS, 사스)서비스로 제공되는 소프트웨어입니다. 고객에게 제공되는 소프트웨어를 가상화합니다.클라우드 구분하여 알아보자IaaS: 서비스로 제공하는 인프라스트럭쳐클라우드 인프라스트럭처 서비스는 확장성이 높고 자동화된 컴퓨팅 리소스를 가상화하여 제공하는 것입니다. IaaS는 컴퓨팅, 네트워킹, 스토리지 및 기타 인프라스트럭쳐를 사용하기 위한 서비스이며 사용자는 필요할 때 마다 서비스를 통해 리소스를 구입할 수 있습니다.(IaaS는 한국에서 이아스 또는 아이아스로 부르며 영미권에서는 이에:스 또는 아이아스로 발음합니다.)PaaS: 서비스로 제공하는 플랫폼클라우드 플랫폼 서비스는 주로 응용 프로그램을 개발 할 때 필요한 플렛폼을 제공하는 것입니다. PaaS는 사용자 정의 응용 프로그램을 개발하고 사용할 수있는 개발자를위한 프레임워크를 제공합니다. 개발사는 미들웨어를 설치하지 않고도 미들웨어에서 제공하는 API를 사용하여 소프트웨어를 개발할 수 있습니다. SaaS : 서비스로 제공하는 소프트웨어클라우드 애플리케이션(소프트웨어) 서비스는 사용자에게 제공되는 소프트웨어를 가상화하여 제공하는 것입니다. SaaS는 타사 공급 업체가 관리하는 사용자에게 응용 프로그램을 제공하기 위해 인터넷을 사용합니다. 대부분의 SaaS 애플리케이션은 웹 브라우저를 통해 직접 실행되므로 클라이언트 측에서 다운로드 나 설치가 필요하지 않습니다.무엇을 제공하는가클라우드는 온라인의 광범위한 영역을 모두 다루는 광범위한 영역입니다. 클라우드 서비스들은 제공하는 범위에 따라 IaaS, PaaS, SaaS로 나뉘고 있으므로 각각의 클라우드 서비스가 제공하는 내역을 살펴보는 것은 클라우드를 이해하는 데 많은 도움이 됩니다.  IaaS: 물리적 자원 제공IaaS는 고객에게 서버, 네트웍, OS, 스토리지를 가상화하여 제공하고 관리합니다. IaaS는 가상화 된 물리적인 자산을 UI형태의 대시보드 또는 API로 제공합니다. IaaS의 고객들은 서버와 스토리지를 접근할 수 있지만 사실상 클라우드에 있는 가상 데이터 센터를 통해 리소스를 전달받는 형태입니다. IaaS는 기존의 데이터센터에서 제공받던 물리적인 자산을 완벽하게 가상화하여 제공하기 때문에 서버 사양의 변경 등 물리적 자산의 수정이 필요한 경우 기존의 방식에 비해 훨씬 빠른 대응이 가능합니다.IaaS의 제공업체는 서버, 하드 드라이브, 네트워킹, 가상화 및 스토리지를 관리하며 고객은 OS, 미들웨어, 애플리케이션 및 데이터와 같은 자원들을 관리해야 합니다. PaaS: 소프트웨어 개발을 돕는 플랫폼 제공PaaS는 고객에게 OS, 미들웨어, 런타임과 같은 소프트웨어 작성을위한 플랫폼을 가상화하여 제공하고 관리합니다. 이 가상화 된 플랫폼은 웹을 통해 제공되며 개발자는 운영 체제, 소프트웨어 업데이트, 저장소 또는 인프라에 대한 관리 없이 소프트웨어 개발에 집중할 수 있습니다.PaaS를 사용하면 기업에서는 특수 소프트웨어 구성 요소를 사용하여 PaaS에 내장 된 응용 프로그램을 설계하고 만들 수 있습니다. 이러한 응용 프로그램 또는 미들웨어는 특정 클라우드 특성을 채택 할 때 확장 가능하고 가용성이 높습니다.SaaS: 고객이 사용하는 소프트웨어 제공SaaS는 고객을 대신하여 소프트웨어와 데이터를 제공하고 관리합니다. 패키지 또는 On-Prems 방식이라고 하는 기존의 소프트웨어 전달 방식과 다르게 SaaS는 개별 컴퓨터에 응용 프로그램을 다운로드하고 설치할 필요가 없습니다. SaaS를 통해 서비스를 공급하는 업체는 데이터, 미들웨어, 서버 및 스토리지와 같은 모든 잠재적 인 기술적 문제를 관리하기 때문에 고객은 유지 보수 및 지원을 간소화 하면서 비지니스에 집중 할 수 있습니다.클라우드의 장점과 단점클라우드 인프라 서비스를 사용할 때의 장점과 클라우드 소프트웨어 서비스를 사용할 때의 장점은 다를 수 밖에 없습니다. 이에 3가지 클라우드 서비스의 장점과 단점을 각각 설명합니다. IaaS: 장점비용물리적 자원을 소비 형태로 사용하기 때문에 고정비가 들지 않습니다.속도물리적 자원을 즉시 소비할 수 있습니다.관리물리적  자원에 대한 관리를 논리적인 영역으로 대체할 수 있습니다.물리적 자원에 대한 자동화 된 배포가 가능합니다.물리적 자원에 대한 안정적인 운영을 벤더에 맞길 수 있습니다.물리적 자원에 대한 규모의 확장 또는 축소가 자유롭습니다.  PaaS: 장점비용필요한 플랫폼만 소비 형태로 사용하기 때문에 비용 부담을 덜 수 있습니다. 속도개발 및 배포 프로세스를 빠르게 확보할 수 있습니다.관리소프트웨어 유지 관리가 쉬워집니다.가상화 기술을 기반으로 구축되어 비즈니스가 변함에 따라 리소스를 쉽게 확장 또는 축소 할 수 있습니다.응용 프로그램의 개발, 테스트 및 배포를 지원하는 다양한 서비스를 제공합니다.수많은 사용자가 동일한 개발 응용 프로그램에 액세스 할 수 있습니다.PaaS: 단점특정 플랫폼 서비스에 종속될 수 있습니다.SaaS: 장점SaaS는 소프트웨어 설치, 관리 및 업그레이드와 같은 지루한 작업에 소요되는 시간과 비용을 크게 줄임으로써 직원과 회사에 많은 이점을 제공합니다. 따라서 기술 직원이 조직 내에서 보다 긴급하고 중요한 문제에 집중할 수 있습니다. 비용소프트웨어를 소비 형태로 사용하기 때문에 비용 부담을 덜 수 있습니다.속도즉시 사용이 가능합니다. 관리소프트웨어를 설치할 물리적 자원이 필요하지 않습니다.언제 어디서든 접근가능합니다.SaaS: 단점커스터마이징이 어렵습니다. 클라우드 언제 적용해야 하는가IaaS: 빠른 변화를 원한다면스타트업이나 중소기업에게 IaaS는 훌륭한 옵션이므로 하드웨어나 소프트웨어를 설치하는데 시간과 돈을 낭비 할 필요가 없습니다. IaaS는 응용 프로그램과 인프라를 완벽하게 제어하고자하는 대규모 조직에 유용하지만 실제로 소비되거나 필요로하는 것을 구매하려는 경우에만 유용합니다. 빠르게 성장하는 기업의 경우, IaaS는 요구 사항이 변화하고 발전함에 따라 특정 하드웨어 나 소프트웨어에 전념 할 필요가 없으므로 좋은 선택이 될 수 있습니다. 또한 필요에 따라 확장 또는 축소 할 수있는 많은 유연성이 있으므로 새로운 응용 프로그램에 어떤 요구가 필요한지 확실하지 않은 경우 도움이됩니다.PaaS: 신속한 개발을 원한다면PaaS를 이용하는 것이 유익하거나 필요한 경우가 많이 있습니다. 동일한 개발 프로젝트를 수행하는 여러 개발자가 있거나 다른 공급 업체도 포함해야하는 경우 PaaS는 전체 프로세스에 뛰어난 속도와 유연성을 제공 할 수 있습니다. PaaS는 사용자 정의 된 응용 프로그램을 만들려는 경우에도 유용합니다. 또한이 클라우드 서비스는 비용을 크게 절감 할 수 있으며 앱을 신속하게 개발하거나 배포하는 경우 발생하는 몇 가지 문제를 단순화 할 수 있습니다.SaaS: 비지니스에 집중하고 싶다면보안상 민감한 사항이 아니라면 모든 기업에게 SaaS는 훌륭한 옵션입니다. 또한 협업이 필요한 단기 프로젝트라면 SaaS 를 도입하는 것이 훨씬 유리합니다. 일반적으로 On-Prems 솔루션은 모바일 액세스를 지원하지 않기 때문에 모바일 액세스가 필요한 경우에도 SaaS를 사용하면 비용가 시간을 절약할 수 있습니다.클라우드 서비스 예클라우드는 적용된 분야별로 이해해야 합니다. 아래는 분야별 서비스 예입니다. IaaSAmazon Web Services (AWS), Microsoft Azure, DigitalOcean, Google Compute Engine (GCE)PaaSAWS Elastic Beanstalk, Windows Azure, Heroku, Google App EngineSaaSGoogle Apps, Dropbox, Salesforce, WhaTap마무리지금도 많은 기업의 임원분들이 클라우드의 적용 여부에 대해 고민을 하고 있으며 많은 스타트업들이 클라우드 기반의 서비스를 만들어 가고 있습니다. 회사에 클라우드를 도입해야 한다면 IaaS를 도입할 지, PaaS를 도입할 지 아니면 SaaS를 도입해야 하는지 알고 있어야 합니다. 그리고 자사의 서비스가 클라우드 기반의 서비스라면 고객에게 왜 도입해야 하는지 쉽게 설명할 수 있어야 합니다. 제가 다니는 와탭랩스(whatap.io)는 국내에서 드물게 SaaS 모니터링 서비스를 제공하고 있습니다. 2015년 1월에 시작한 서비스는 이제 만 4년을 달려가고 있습니다. 앞으로 한국에서 더 많은 클라우드 서비스들이 나왔으면 합니다. #와탭랩스 #개발자 #개발팀 #클라우드서비스 #서비스소개
조회수 2295

JIRA하고 자빠졌네!?

Overview“JIRA하고, 자빠졌네!” 세종대왕은 확실히 개발자의 두뇌를 가지고 있었던 게 분명합니다. 먼 시대를 지나 오늘날 QA를 하는 저에게 응원을 해주시니 말입니다. 하지만 그는 틀렸습니다. 걱정과는 다르게 다행히 자빠지진 않았거든요. 지라(JIRA) 덕분입니다.갑자기 지라 이야기가 나와 당황하셨죠? 축하해주세요. 드디어 브랜디도 지라를 사용하게 되었답니다. (짝짝짝!) 지라 도입은 처음이라 세팅부터 쉽지 않았는데요. 이번 글은 눈물겨웠던 지라 세팅 과정과 브랜디의 이슈관리를 소개하겠습니다. 스크럼을 쓰면 좋은 점스크럼(Scrum)은 요구 사항 분석부터 하는 칸반(Kanban)보다 효율적입니다. 안드로이드와 iOS로도 나눠져 있고 업무를 짧게 반복하기 때문이죠. 스크럼에 적합한 워크플로우(Workflow)를 볼까요? 이것은 실제로 브랜디 R&D본부에서 사용하고 있기도 합니다. 스크럼에 적합한 워크플로우IN PROGRESS: 이슈나 개발 요건을 티켓으로 만들면 IN PROGRESS 상태가 됩니다. RESOLVED: 이슈나 개발 요건이 완료되면 RESOLVED 상태로 변경합니다.QA: QA가 필요한 개발 요건은 QA상태로 변경합니다.PASS: 이슈 또는 개발 요건이 수정되었거나 문제가 없다면 PASS 상태로 변경합니다.FAIL: 이슈 또는 개발 요건이 제대로 수정되지 않았거나 다른 이슈가 발생하면 FAIL 상태로 변경합니다.QA불필요: QA가 필요하지 않은 개발 요건은 QA불필요 상태로 변경합니다.DONE: 이슈를 해결했거나 개발을 완료하면 DONE 상태로 변경합니다CLOSE: 담당 팀장님이 이슈 확인 후 CLOSE 처리합니다. 예를 들어보겠습니다. 킥오프 서비스 회의를 하고, SB를 제작, 리뷰합니다. 이후에 디자인팀과 개발팀 일정을 공유하고 스크럼 마스터는 스프린트 주기를 책정하죠. 스프린트가 시작되면 개발자는 스토리 티켓을 작성하는데요. 개발이 끝나면 QA가 필요한 티켓은 테스트를 진행하고, QA가 종료되면 스프린트도 종료됩니다.Epic 티켓위의 이미지는 Epic 티켓입니다. Android, iOS, 이슈 등 모든 티켓은 Epic 안에서 관리합니다. 한 곳에서 한꺼번에 관리하기 때문에 히스토리 관리가 편하고, 진행 상황도 확인할 수 있습니다.티켓 생성개발팀의 티켓 생성입니다. 개발자는 SB를 보고 개발 티켓을 작성합니다. 개발 티켓 작성 후에 개발이 진행되며 QA 판단 여부를 체크해 QA 상태로 변경합니다. 변경된 티켓에 관한 QA가 진행되며 문제가 없으면 해당 티켓은 종료됩니다.이슈 생성다음은 이슈 생성입니다. 파악한 SB는 디자인 시안과 비교하며 개발이 된 Android, iOS 테스트 파일을 QA합니다. QA를 진행할 때 발생한 이슈는 지라 티켓으로 등록하여 이슈를 관리합니다. 모든 이슈 티켓 종료되면 해당 차수의 QA는 끝나고 마침내 상용에 배포합니다. 배포가 완료되면 필수 및 크리티컬 리그레이션 테스트가 진행됩니다. Conclusion실수는 항상 모든 것이 끝난 이후에 보이기 마련입니다. 수십 번 QA를 해도 보이지 않던 문제들이 상용에 올라간 이후부터 보이기 시작하죠. 스크럼은 이런 실수들을 가장 최소화할 수 있는 툴이 아닐까 생각합니다. 물론 아무리 좋은 툴을 써도 팀원들과 함께 뭉치는 것보다 중요한 것은 없겠죠. 다음 글은 자동화를 주제로 찾아뵙겠습니다. JIRA하고 자빠지지 않는 개발자가 됩시다!글김치영 대리 | R&D PM팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #JIRA
조회수 669

오픈서베이가 구성원과 함께하는 방식, 병특 Z세대에게 묻다

끊임없는 자기 계발과 성장 욕구는 Z세대의 특징이라고들 합니다. 약관 20세에 병역특례로 입사해 2년째 오픈서베이의 Z세대를 대표하는 김승엽 웹 프론트엔드 개발자(이하 레드)도 그렇습니다. ‘나이에 비해 잘한다’는 ‘아직 잘 못 한다’는 뜻이라며, 달콤한 퇴근 후 시간을 방통대 강의와 과제에 투자하고 있죠.  원동력이 무엇인지 물으니, 그도 얼마 전까지는 게으른 집고양이처럼 사는 게 꿈이었다고 합니다. 직원들을 진정으로 위하는 회사의 모습과 형·누나·아빠뻘의 구성원과 일하며 받은 좋은 자극 덕에 향상심이 자라났다고 하죠. Z세대의 마음을 울린 회사의 모습은 무엇일까요?       오픈서베이 김승엽(레드) 웹 프론트엔드 개발자   레드, 안녕하세요!  안녕하세요. 오픈서베이 웹 프론트엔드 개발을 담당하는 레드입니다. 오픈서베이 DIY 리뉴얼, 랜딩페이지 등 오픈서베이의 각종 웹페이지 개발을 맡고 있습니다. 오픈서베이에서 병역특례 복무 중이기도 하고요(웃음).   2년 전 스무살 나이로 입사했는데, 실은 오픈서베이도 2번째 회사라면서요. 맞아요. 고등학생 때 바로 취업을 했거든요. 특성화 고등학교에 다니면서 프로그래밍을 배웠어요. 배우다 보니 재미가 붙어서 친구들이랑 프로젝트도 해보고 교내 대회에도 나갔고요. 그때 대학교에 진학하기 보다는 빨리 취업해서 실무에서 배우고 성장하는 게 더 좋을 것 같다고 생각했던 것 같아요. 또 저희 학교 특성 상 졸업 전에 다양한 회사에서 구인 행사를 하러 와요. 전 그때 한 스타트업에서 병역특례 지원 해준다는 말만 듣고 멋모르고 첫 취업을 했어요. 아직 병특 지정 업체도 아니었는데, 입사만 하면 병특 업체 지원 해준다는 말만 믿고 순진했었죠.  그렇게 멋모르고 1년 정도 다녔더니 대표님이 병특 업체 선정 안 됐는데 더 신청한다고 될지 모르겠다고 하더라고요. 군대는 각자 일이니 스스로 해결 방법을 찾으라면서요. 그때 회사가 말하는 성장에 대한 비전이나 직원과의 약속이 현실성 없는 허황된 말이라고 생각했던 것 같아요. 그렇게 첫 회사에 실망해서 이직한 곳이 오픈서베이입니다.    첫 회사에서의 경험으로 이직 시 고려요소가 좀 달라졌나요? 조건이 까다로워졌다기보다는 회사에 바라는 게 줄었어요. 그냥 내가 다니는 동안 배울 게 있는 회사였으면 좋겠다는 생각만 있었어요. 병특 지원이 급했을 때라 더 그랬던 것도 같아요(웃음). 그런데 오픈서베이를 다니면서는 좋은 회사에 대한 생각이 또 조금씩 달라졌어요. 예전에는 천국 같은 회사에 대한 환상이 있었는데, 지금은 회사는 천국일 수 없다고 생각하는 편이거든요. 일을 하는 곳이 천국 같을 순 없으니까요.   그럼 정말 현실적으로 좋은 회사가 뭘까 생각해보게 되겠군요. 맞아요. 저는 열심히 살아야겠다는 생각이 들게 하는 회사가 좋은 회사라고 생각해요. 그런 면에서 오픈서베이는 정말 좋은 회사 같아요. 제가 계속 더 잘해야겠다는 자극을 받게 하거든요. 특히 함께 일하는 팀원들에게 긍정적인 자극을 많이 받는 편인 것 같아요.  조셉(김경만 안드로이드 개발자 겸 오베이 PM)이 입사하신 지 얼마 안 돼서 개발팀 세미나를 했을 때가 처음으로 충격을 받았어요. 저는 주제와 내용 자체가 어려워서 이해하기 힘들었는데 그걸 다 소화해서 발표하는 모습을 보면서 경각심이 생기더라고요.   조셉은 어떤 주제로 개발팀 세미나를 했을까요? (클릭)   아무래도 완전 경력자보다는 비슷한 또래나 경력을 가진 분들에게서 더 자극을 받나 보군요. 저는 그런 것 같아요. 그래서 로빈(권장호 개발자)이 입사했을 때는 진짜 충격이었어요. 저보다 어리고 경력도 짧은데 일을 대하는 태도나 적극성이 저랑 많이 달랐어요. 일하는 시간 외에도 시간 내서 꾸준히 개발 공부나 블로그를 하는 모습을 보면서, 저도 열심히 해야겠다는 생각이 들더라고요.  그전까지는 좀 안주하려는 면이 있었어요. 왜 그러냐면 저는 저보다 나이나 경력이 많은 분들이랑만 일해왔잖아요. 그러다 보니 칭찬도 “나이에 비해 잘한다”는 말을 주로 들었어요. 사실 그게 “아직 잘은 못한다”는 뜻이잖아요. 그걸 모르고 그냥 내가 잘하고 있구나 하면서 안도해왔던 것 같아요.  그런데 아직 어리다는 장점은 시간이 지날수록 약해지잖아요. 이른 나이에 빠르게 일을 시작했다는 저만의 장점을 계속 가지고 있으려면 지금 상황에 만족하는 게 아니라 계속 노력해야 한다는 걸 깨달은 것 같아요. 개발자를 하루 이틀 하다가 때려치울 것도 아니고 남들보다 빨리 실전에 뛰어든 만큼 이론적으로 부족한 것도 많으니 더 공부해야 한다는 거죠.    “일을 일찍 시작했다는 장점을 유지하려면  지금 상황에 만족하지 않고 계속 노력해야 돼요”   그런데 열심히 해보려고 해도 뭘 해야 할지, 어떤 공부를 어떻게 하면 좋을지 막막할 때도 있잖아요. 전 직장이었다면 그랬을 것 같아요. 그런데 개발팀원은 모두 저보다 개발 경력이나 사회 경험도 많고 언제든 조언해줄 마음이 열려있는 분들이라 도움을 받고 있어요. 특히 폴(이건노 CTO)은 주니어 개발자들과 1:1 미팅을 자주 가지면서 도움 되는 조언을 많이 해줘요.  한번은 폴이 제 개발자 커리어에 대한 조언을 해주셨어요. 저는 프론트엔드 개발자라면 프론트엔드만 전문적으로 파면된다고 생각했거든요. 그런데 백엔드 등 다른 개발 분야도 1단계 정도는 공부를 해둬야 지반이 탄탄한 프론트엔드 개발자가 될 수 있다는 조언을 해주셨어요. 그 조언이 지금도 기억에 많이 남아요. 왜냐면 지금 당장 해야 하는 프로젝트 단위가 아니라 제 인생 관점에서 조언을 해주신 거잖아요. 사실 폴은 CTO고 저는 직원이니까 조언도 업무 코치 위주로만 해줄 수도 있는 건데요. 이렇게 저보다 10, 20년 넘는 경력을 가진 분이 제 개발자 인생에 대해 해주는 조언은 어디서도 듣기 힘들잖아요.    그렇죠. 멘토가 중요하다고는 하는데, 20대 초반의 멘토는 보통 책이나 TV같이 멀리서만 접할 수 있는 인물이잖아요. 좋은 멘토는 많지만 나를 위한 조언이 아닐 때는 공허하게 들리기도 하고요.  맞아요. 저도 지금 이 시기에 바로 옆에서 조언해줄 수 있는 분이 있다는 건 정말 좋은 것 같아요. 그런 폴 덕에 개발팀은 시켜서 하기보다 자기 주도적으로 일할 수 있는 환경과 문화가 잘 갖춰진 것 같아요.  매주 진행하는 개발팀 업무 공유 회의 때도 단계나 일정에 대한 틀을 잡아주는 역할에 집중하는 편이세요. 위에서 “이거 해, 저거 해”라고 콕 집어서 마이크로 매니징을 하는 게 아니라, 프로젝트 단위로 자발적으로 구성원이 꾸려져서 진행해 나가는 게 오픈서베이의 업무 문화인 것 같아요.  그런 문화다 보니까 저도 시키는 일만 하는데 그치지 않고 다양한 시각에서 프로젝트를 바라보면서 의견도 많이 낼 수 있는 것 같아요. 구성원들이 제 의견을 경청해주고 수용해주면 ‘내가 프로젝트에 직접적으로 기여하고 있구나’란 생각이 들면 책임감도 더 생기는 것 같아요.    “내가 프로젝트에 기여하고 있다는 생각이 들면 더 책임감을 가지면서 일할 수 있어요”   그런 긍정적인 자극이 실제 업무 능력 향상으로도 이어지는 편인가요?  네. 저는 기술적인 면에서도 많이 성장하고 있다고 생각해요. 유지보수하기 수월한 깔끔한 코드를 짜는 능력도 예전보다 많이 향상됐고, 주어진 시간 내 일을 더 빨리 효율적으로 마칠 수 있는 생산성도 많이 올랐다고 생각해요. 저는 야근 없이 깔끔하게 일을 끝내는 게 일을 잘하는 거라고 생각해서요(웃음).   와! 그럼 레드가 배운 일 잘하는 방법 하나만 알려주세요.  저는 ‘똑똑하게 질문하기’라고 생각해요. 질문사항에 대해 충분히 고민해본 뒤 물어봐야 한다는 걸 알았어요. 사실 주니어 때 가장 많이 하는 고민이 ‘어떻게 해야 좋은 질문을 할 수 있을까’ 잖아요. 회사에서는 모르면 물어보라고 하는데 그냥 물어보면 혼날 때도 있으니까요. 그런데 질문거리에 대해 제가 충분히 소화를 못 하면 어디에서 어려움을 겪고 있고 그래서 어떤 도움이 필요한지 질문을 받은 분도 몰라요. 질문이란 건 제 업무를 위해 다른 분의 업무 시간을 빌리는 건데, 정확히 질문하지 못하면 질문한 사람이나 받은 사람의 시간을 그만큼 허비하는 거니까요.  이걸 알고 난 뒤 충분히 고민하고 물어보기 시작했더니 신기하게도 질문을 받은 분의 답변도 달라졌어요. 제가 테리(이한별 개발자)에게 질문을 많이 하는 편인데, “이렇게 해라, 저렇게 해라”는 단편적인 답변이 아니라 “이건 이래서 이렇고, 저건 저래서 저렇다. 그래서 이럴 땐 이걸 써야 하고, 저럴 땐 저걸 써야 한다”는 맥락적인 답변을 해줘요.  테리가 좋은 분이라 답변을 잘 해주시는 것도 있지만 제가 질문거리에 대해 충분히 고민해서 알고 있으니까 구체적으로 대답해줄 수 있는 거라고 생각해요. 이런 좋은 답변으로 과정을 충분히 알면 질문을 반복하거나, 다른 분의 질문에 불필요한 시간 낭비를 하지 않고 답할 수 있게 되는 것 같아요. 나중에 비슷한 상황이 오면 제가 스스로 문제를 해결할 수 있게 되고요.   주니어에게 꼭 필요한 팁이네요! 고맙습니다. 최근에는 방송통신대학교에 진학했다고 들었어요.  맞아요(웃음). 사실 방통대 진학도 로빈의 영향이 컸어요. 안 그래도 최근에 개발 이론 공부를 따로 해보자고 생각하던 차였어요. 그런데 로빈이 방통대 진학을 하면서 같이 해보자고 해서 이참에 도전했죠. 마음만 먹고 있다가 로빈 덕에 실행할 수 있었던 거에요. 요즘은 일을 마치면 방통대 강의를 듣거나 과제를 하는 데 시간을 보내고 있어요.     “이론 공부는 마음만 먹고 있다가 로빈 덕에 실행할 수 있었어요” (레드 옆에 노란옷을 입고 앉아 있는 분이 로빈입니다)   와.. 그럼 일과가 어떻게 되는 거예요?  오픈서베이 병특은 출퇴근 시간이 기본 10시 출근-7시 퇴근인데, 경우에 따라 신청해서 9시-6시로 변경할 수 있어요. 저는 방통대 다니면서부터 9시로 출근 시간을 조정했어요. 출근이 늦으면 그만큼 퇴근도 늦어지니 저녁 시간을 충분히 활용하지 못하겠더라고요.  하루일과는 9시까지 출근해서 우다다 일하고 점심 먹고 일하다가 6시에 칼같이 퇴근해요. 집에 가서는 씻고 밥 먹고 강의를 듣거나 과제를 하죠. 최근에는 저녁 필라테스를 시작해서 평일 저녁 중 이틀은 필라테스를 하러 가요. 주말에 좀 쉬고요(웃음).   조바심이 든다고 다 열심히 할 수 있는 건 아닌데, 남다른 원동력의 배경이 궁금하네요.  저도 진짜 빡센 것 같고 가끔 힘도 들어요. 그런데 다른 회사에서 병특 중인 주변분들 보면 운영보수 위주의 반복적인 업무만 하거나, 병특이라 쉽게 이직할 수 없으니 업무를 과다하게 몰아주는 경우도 보곤 해요.  제가 주어진 업무 시간에만 집중하고 퇴근 후 시간을 자기 계발을 위해 쓸 수 있다는 건 쉽게 얻기 힘든 기회일 수도 있는 거죠. 성장을 위한 중요한 시기에 주어진 기회라고 생각하면 열심히 할 수 있게 되는 것 같아요. 저보다 더 열심히 하는 다른 구성원을 보면서 자극을 받는 것도 물론 있고요.   산업기능·전문연구요원으로  오픈서베이에 지원하고 싶다면? (클릭)   자기개발에 매진하면 회사 생활에 소홀해질 것도 같은데.  음. 회사에서 성취가 없다는 생각이 들면 그럴 수 있겠네요. 그런데 오픈서베이는 반기마다 전사 회의를 통해 하이(황희영 대표이사)가 회사 성장에 대해 공유해주잖아요. 이 시간은 단순히 오픈서베이 매출 성장 공유가 아니라 제 기여가 회사에 어떤 도움이 됐는지, 이를 바탕으로 회사가 얼마나 성장하고 있는지를 점검하는 과정이라고 생각해요.  개인적으로는 투자 받은 돈 까먹는 스타트업이 아니라 우리 서비스와 구성원의 노력으로 흑자를 기록하고 매번 매출 성장을 하고 있다는 점도 저한테는 큰 보람이고 성취거든요. 실질적인 매출이 있고, 고객사가 계속 늘고, 매출 성장도 계속 일어난다는 이야기를 들으면 진짜 회사다운 회사라는 생각이 들고 성취감이 느껴져요.   6월에 강남역 1분 컷 초역세권 사무실로 이사도 가고! (웃음) 그것도 좋은데 사실 저는 하와이 간다고 했을 때 진짜 신났어요(웃음).  사실 전사 하와이 워크샵은 18년 목표 공약이라서 가는 거잖아요. 회사가 진짜 할 수 있는 목표를 잡아서 노력하고 목표 달성을 했을 때 약속을 지키는 모습을 보면서 되게 멋지다는 생각을 했어요. 좋은 회사와 좋은 어른의 모습은 이런 건가 싶고, 이런 모습을 보면서 저도 더 성장해야겠다고 생각하는 것 같아요.      “레드와 함께 일하고 싶으시다면 지금 바로 오픈서베이 입사 지원을 해보세요”
조회수 2785

PHP CI 환경에서 완전한 Vue 사용하기

편집자 주Vue 또는 VUE로 혼용하나 공식 사이트의 표기에 맞춰 아래와 같이 통일함-Vue-Vuex-Vue-Router목차1.Controller2.VIEW3.webpack Vue 소스 진입점4.webpack 설정5.Package.json6.Vue-Router7.Vuex8.공통 처리 mixin9.요약10.마치며시작하며드디어 브랜디 관리자 서비스에 Vue를 도입하고자 떠났던 여정의 마지막 장입니다. 브랜디 관리자 서비스는 PHP Codeigniter와 jQuery로 구성되어 있습니다. 사실 잘 운영되고 있는 서비스에 리스크가 큰 신기술을 도입하는 것은 도박에 가깝습니다. 몇 시간만 운영이 정지되어도 회사에 엄청난 피해를 안겨줄 수도 있으니까요. 하지만 여러 번의 검증과 실험으로 도박에서 이길 확률을 100%에 가깝게 끌어올린다면 한번 도전해볼 만하지 않을까요?이전 글인 PHP Codeigniter 환경에서 VUE 사용해보기에서 기본적인 webpack + Vue + Codeigniter 환경 구축 방법을 알아봤는데요. 하지만 단순히 webpack과 Vue만 적용했다고 해서 “우리 시스템은 UI 프레임워크로 Vue를 사용하고 있습니다.”라고 말할 순 없습니다. 아주 중요한 숙제가 남았죠.Vue에는 활용도를 대폭 끌어올려주는 Vue-Router와 Vuex Store1)가 있는데 그중 Vue-Router를 이번 글에서 자세히 다루려고 합니다.2) Vue-Router는 Vue.js의 공식 라우터입니다. 공식 홈페이지의 소개는 아래와 같습니다.중첩된 라우트/뷰 매핑모듈화된, 컴포넌트 기반의 라우터 설정라우터 파라미터, 쿼리, 와일드카드Vue.js의 트랜지션 시스템을 이용한 트랜지션 효과세밀한 내비게이션 컨트롤active CSS 클래스를 자동으로 추가해주는 링크HTML5 히스토리 모드 또는 해시 모드(IE9에서 자동으로 폴백)사용자 정의 가능한 스크롤 동작한마디로 정리하면 입력된 URL에 반응해 부분에 해당 URL의 view를 보여주는 기능인 것입니다. 다시 말해 URL이 변경될 때 한 페이지에서 화면 전체를 갈아끼우거나, 화면의 일부분(부분)을 치환해주는 역할을 한다는 것이죠. 더 나아가 해당 화면이 로드되기 전후로 전처리, 후처리 기능까지 가능합니다.착안점Vue와 Vue-Rotuer를 알게 되었을 땐 PHP 기반 프로젝트에 Vue-Router를 적용할 수 없으니 처음부터 새로 만들어야 한다고 생각했습니다. 로그인 인증 문제, 메뉴의 권한 관리 등 모든 것이 Vue 아래에 있어야 한다고 생각했기 때문입니다.어느 날 관리자 서비스에 TDD를 구현해보려고 Python Flask + webpack + Vue 프로젝트를 구성하고 있었습니다. 그러던 중 우연히 Flask + Vue-Router에서 404 페이지를 처리하려면 Flask Fallback 페이지를 Vue-Router 메인 페이지(가 있는 페이지)로 보내고, Vue-Router에서 진짜 매핑된 URL이 없으면 404 처리를 하는 식으로 구성한다는 글을 읽고 문득 호기심이 생겼습니다.‘관리자 서비스에서도 컨트롤러로 여러 URL을 한 가지 페이지로 보낸다면?’PHP를 거쳐 페이지로 이동한 것이므로 권한 관리와 메뉴 트리까지는 PHP에서 처리되면서 URL이 변할 것이고, 실제로 화면을 보여주는 Contents 영역만 를 사용한다면 어떻게 될지 궁금해졌습니다. 바로 하던 일을 멈추고 관리자 소스에 Vue-Router를 활용한 테스트 소스코드를 작성해봤습니다.예상했던 대로 PHP의 로그인 인증 처리를 거치면서 실제로 보이는 부분에는 부분만 정상적으로 치환되었습니다. 이 간단한 실험을 바탕으로 통계 시스템의 일부를 구현하는 데에 Vue-Router와 Vuex Store, 공통 처리 Mixin을 추가해 제작했습니다.1.Controller4개의 페이지를 가진 통계 시스템의 Codeigniter 컨트롤러 모습입니다. 기존의 서비스 URL들이 존재하기 때문에 Fallback을 통으로 Vue-Router로 보낼 순 없었고, 라우터를 사용할 페이지들을 하나의 페이지로 보냈습니다.1-1) /application/controllers/[컨트롤러 경로]... 생략 /* [라우터 view]에서 태그를 포함하고 있습니다. */ public function salesAnalysisProduct() { $this->load->view('[라우터 view]'); } public function salesAnalysisSeller() { $this->load->view('[라우터 view]'); } public function trendAnalysisProduct() { $this->load->view('[라우터 view]'); } public function trendAnalysisSeller() { $this->load->view('[라우터 view]'); } ... 생략 2.VIEWCodeigniter 환경에 반영하는 것이므로 CI에서 인식시킬 PHP view와 webpack에서 빌드 결과를 자동으로 바인딩할 html 파일로 구성됩니다.2-1)/application/views/[Vue용 view 경로]/index.php// [index.php] Vue 를 매핑할 php파일 컨트롤러의 view로딩용 [라우터 view]입니다. ... header, menu 생략 ... //바인딩될 부분 //자동매핑 html 인클루드 <?php include('index.html'); ?> ... footer 생략 ... 2-2)/application/views/[Vue용 view 경로]/index.html webpack의 빌드 결과로 자동으로 생성되는 파일입니다. [removed][removed] 위는 webpack의 HtmlWebpackPlugin에 의해 자동으로 바인딩된 모습입니다. 빌드되기 전 index.html은 다음 항목에 있습니다.3.webpack Vue 소스 진입점관리자에서는 프로젝트 폴더 안에 webpack과 Vue 용 서브 폴더를 두고 webpack.config.js에서 output 옵션을 통해 빌드 결과를 삽입하는 구조입니다. webpack 루트 폴더는 application 폴더와 같은 레벨에 위치하며, 폴더 구조나 파일 위치는 어디에 둬도 상관없습니다. webpack.config.js에서 entry 속성으로 잡아주시면 됩니다.3-1)/[webpack루트]/index.html// HtmlWebpackPlugin으로 스크립트를 삽입하기 위한 빈 템플릿 파일 3-2)/[webpack루트]/index.js/** * 진입용 index.js */ import Vue from 'vue' import axios from 'axios' import router from './router' import App from './App.vue' Vue.prototype.$http = axios new Vue({ el : '#app', router, components : { App }, template : '' }); 3-3)/[webpack루트]/App.vue [removed] import mixin from './common/common-mixin.js' import store from './vuex/store' export default { store, name : 'App' } [removed] Vuex와 통신 모듈 axios, Vue-Router 등을 루트 Vue 객체에 추가해줍니다. 브랜디 관리자의 webpack은 babel을 사용하고 있기 때문에 위의 store처럼 축약해서 작성하면 빌드된 파일에는 store: store와 같이 입력됩니다.Vue-Router는 태그에 자동으로 매핑되며, 위와 같은 구조로 상위 컴포넌트에서 할당되어 있어야 합니다. Vuex와 Vue-Router 설정은 글 아래에서 다루겠습니다.4.Webpack 설정이번에 Vue-Router와 Vuex를 도입하면서 webpack의 설정도 실제 서비스용과 개발용으로 분리했습니다. 폴더는 편의상 추가하였으며, package.json에서 자신이 설정한 경로로 설정하면 됩니다.Webpack 설정 파일은 Webpack의 시작과 끝이라고도 할 수 있습니다. Webpack 설정 파일에서 빌드할 소스의 경로와 빌드 결과 파일의 명명 규칙을 정하고, html 파일에 스크립트파를 자동으로 주입시키거나, Babel 플러그인을 통해 최신 스크립트 작성법을 브라우저를 신경쓰지 않고 사용할 수도 있습니다.그중에서도 중요한 옵션이 있는데 바로 Code Splitting에 관련된 옵션입니다.관리자 초기 Vue 모델에는 Vue-Router가 없었기 때문에 js 번들 파일의 크기가 그렇게 크지 않았습니다. 하지만 Vue-Router를 사용해 싱글 페이지 어플리케이션이 되거나 화면의 UI가 복잡해 컴포넌트 수가 많아지면 번들 js 파일의 크기가 매우 커집니다. 즉, 캐시를 사용하지 않는 익스플로러라면 소스에서 한 글자만 바뀌더라도 모든 페이지에서 거대한 번들 js를 새로 로딩하게 되고, 상당한 서버 자원을 소모합니다.Code Splitting 적용 전위의 이미지는 Code Splitting을 적용하기 전의 번들 js 정보입니다. 실제로 완성된 Vue 프로젝트의 번들 js는 더욱 큽니다. 정말 단순한 페이지 하나를 띄우는데 매번 뚱뚱한 js를 로딩해야 하는 것은 서비스 제공자와 서비스 사용자를 모두 괴롭게 할 것입니다.Code Splitting 적용 후하지만 위처럼 작은 조각으로 나눠 필요한 시점마다 필요한 번들 js만 로드하면 매우 빠른 페이지를 제작할 수 있습니다. 따라서 Code Split 기능은 매우 중요한 이슈입니다.물론 개발을 진행하다 보면 역시 어느 것 하나 쉽게 넘어가지지 않습니다. 관리자의 웹팩은 4.x 버전대를 사용하고 있습니다. 예전에 TF에서는 Webpakc 3.x 버전대를 사용하였는데 당시에는 CommonChunkPlugin 설정을 통해 Code Splitting을 사용할 수 있었습니다. 그대로 관리자에 적용하려 했는데..Removed라고 쓰여 있습니다. 찾아보니 CommonChunkPlugin이 옵티마이즈 옵션 하위의 splitChunk 속성으로 들어가면서 설정 방법이 바뀌었더군요. 머리를 싸매고 설정을 잡습니다.4-1) /[webpack루트]/build/webpakc.config.js : 공통 설정파일'use strict' const HtmlWebpackPlugin = require('html-webpack-plugin'); const { VueLoaderPlugin } = require('vue-loader'); const path = require('path'); module.exports = { entry: { //string, object, array 가능 - 기본은 ./src app: path.join('[스크립트 파일 경로]', 'index.js') //진입점 스크립트 파일입니다. }, output: { path: '[빌드된 js 목적지 경로]', publicPath: '[이미지등의 웹상 리소스 경로]', filename: './[name].[chunkhash].js', // 엔트리 파일명명규칙 chunkFilename: '[id]_[chunkhash].js', // chunk파일 명명 규칙 // --mode development에서는 [id]에도 chunkName들어갑니다. }, //vue와 js, css 로드 규칙을 설정합니다. module: { rules: [ { test: /\.vue$/, loader: 'vue-loader', include: [ /[Vue 소스 경로]/ ] }, { test: /\.js$/, use: { loader: 'babel-loader?cacheDirectory', }, include: [ /[Vue 소스 경로]/ ] }, { test: /\.css$/, oneOf: [ { use: [ 'vue-style-loader', 'css-loader' ] } ] } ] }, resolve: { alias: { '@': '[Vue소스 경로]', // 편의상 소스단축경로를 설정합니다. }, //파일 확장자 자동인식 임포트시 해당 확장자는 생략가능합니다. extensions: ['.js', '.vue', '.json'], }, plugins: [ // Vue 파일 로더 new VueLoaderPlugin(), // html 자동 바인딩 // 아래의 플러그인으로 인해 index.html에 해시네임으로 빌드된 index.js가 자동으로 매핑됩니다. new HtmlWebpackPlugin({ // index.php에서 include할 파일이 생성될 경로와 파일명 입니다. filename: path.join('[View경로]', 'index.html'), // 자동으로 매핑할 진입점파일을 지정합니다. template: path.join('[Vue소스 경로]', 'index.html'), inject: true, minify: { removeComments: true, collapseWhitespace: true, removeAttributeQuotes: true } }), ], optimization: { //웹팩 4.x 버전에서 옵티마이즈 속성으로 추가된 CodeSplitting 기능입니다. splitChunks: { //initial - static파일만 분리, async - 동적로딩파일만 분리, all - 모두 분리 chunks: 'async', minSize: 30000, minChunks: 1, maxAsyncRequests: 5, //병렬 요청 chunk수 maxInitialRequests: 3, //초기 페이지로드 병렬 요청 chunk수 automaticNameDelimiter: '_', //vendor, default등 prefix 구분문자 (default : '~') name: true, //development모드일때 파일에 청크이름 표시여부 cacheGroups: { default: { minChunks: 2, //2개 이상의 chunk priority: -20, reuseExistingChunk: true //minChunks이상에서 사용할경우 공통사용 }, //axios, vue 같은 공통 모듈은 vendor로 관리합니다. vendors: { test: /[\\/]node_modules[\\/]/, priority: -10 } } } } }; 4-2) /[webpack루트]/build/webpack.dev.config.js 개발용 설정 파일 (네이밍은 자유)'use strict' const merge = require('webpack-merge') const webpack = require('webpack') const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin const baseWebpackConfig = require('./webpack.config') const config = require('../config').dev //개발용설정 const devWebpackConfig = merge(baseWebpackConfig, { //mode는 chunk[id], 디버깅 코드 등에 영향을 줍니다. webpack 3.x 버전에서는 Env 속성을 통해 관리했다고 합니다. mode: 'development', plugins: [ new BundleAnalyzerPlugin(), //번들 무게 분석기 제대로 스플릿 되었는지 확인할 때 사용합니다. new webpack.DefinePlugin({ env : config.env }), ], watch: true, //코드의 변화를 감지해 자동으로 재빌드해주는 옵션입니다. cache: true, //캐시 사용을 활성화하면 변경사항이 있는 코드만 재빌드합니다. optimization: { //uglify 플러그인 코드 압축 여부를 설정합니다 압축 시 용량을 매우 줄일 수 있으나 빌드 속도가 크게 저하되므로 개발 시에는 꺼줍니다. minimize: false, } }) module.exports = new Promise((resolve, reject) => { resolve(devWebpackConfig); }) 4-3) /[webpack루트]/build/webpack.prod.config.js 서비스용 설정파일 (네이밍은 자유)'use strict' const merge = require('webpack-merge') // 설정파일 결합에 사용합니다. const webpack = require('webpack') const baseWebpackConfig = require('./webpack.config') //베이스 설정파일 const config = require('../config').prod //서비스용 설정 const prodWebpackConfig = merge(baseWebpackConfig, { mode: 'production', //chunk[id], 디버깅 코드등 영향 있음 plugins: [ new webpack.DefinePlugin({ env : config.env }), ], //개발용과 반대로 용량은 줄이고 필요 없는 기능은 꺼줍니다. watch: false, cache: false, optimization: { minimize: true, } }) module.exports = prodWebpackConfig 5.package.json웹팩 설정 파일이 분리되면서 package.json의 런 스크립트도 변경했습니다.... "scripts": { "build": "webpack --config build/webpack.prod.config.js --progress", "build-dev": "webpack --config build/webpack.dev.config.js --progress" }, ... 6.Vue-RouterVue-Router는 위에서 설명한 대로 Vue의 컴포넌트와 밀접하게 결합된 라우터입니다. 그런데 여기서 webpack의 Code Split을 사용하려면 컴포넌트 import 방법이 매우 중요한데요.import './testComponent' 위처럼 import 구문을 사용해 컴포넌트를 불러오면 코드가 쪼개지지 않고 한 덩어리로 빌드되므로 아래와 같은 형태로 사용해야 합니다.const testComponent = () => import('./testComponent') webpack 공식 문서에도 나와있듯이 위처럼 ES2015 Loader spec에 있는 import()를 사용하여 컴포넌트를 생성해야 번들 js가 제대로 분리되며, Dynamic Import가 가능해집니다.Vue-Router를 쓰는 순간 싱글 페이지 어플리케이션이 되기 때문에 이곳에서 설정을 잘못 잡아주는 순간 육중한 컴포넌트 한 덩어리가 튀어나오면서 Code Splitting은 물거품이 되어버립니다. 조심합시다!또한 import 함수 안쪽엔 아래와 같은 주석을 달아야 청크 이름이 적용됩니다.const testComponent = () => import( /* webpackChunkName: '[청크이름]'*/ './testComponent') 라우터 경로 속성인 path 와 Codeigniter의 컨트롤러 경로를 맞춰주는 것이 포인트입니다!6-1) /[webpack루트]/router/index.js - 경로와 파일명은 자유입니다!import Vue from 'vue' import Router from 'vue-router' // 주석의 webpackChunkName = 코드 스플릿 chunk Name으로 사용됩니다. // 꼭 컴포넌트와 청크 이름을 같게 설정할 필요는 없습니다. const SalesAnalysisProduct = () => import(/* webpackChunkName: "salesAnalysisProduct" */ '[컴포넌트 파일 경로]') const SalesAnalysisSeller = () => import(/* webpackChunkName: "salesAnalysisSeller" */ '[컴포넌트 파일 경로]') const TrendAnalysisProduct = () => import(/* webpackChunkName: "trendAnalysisProduct" */ '[컴포넌트 파일 경로]') const TrendAnalysisSeller = () => import(/* webpackChunkName: "trendAnalysisSeller" */ '[컴포넌트 파일 경로]') Vue.use(Router) const router = new Router({ mode: 'history', routes: [ /* 통계 */ { path: '[CI컨트롤러 url]/salesAnalysisProduct', name: 'salesAnalysisProduct', component: SalesAnalysisProduct }, { path: '[CI컨트롤러 url]/salesAnalysisSeller', name: 'salesAnalysisSeller', component: SalesAnalysisSeller }, { path: '[CI컨트롤러 url]/trendAnalysisProduct', name: 'trendAnalysisProduct', component: TrendAnalysisProduct }, { path: '[CI컨트롤러 url]/trendAnalysisSeller', name: 'trendAnalysisSeller', component: TrendAnalysisSeller }, ] }) // 아래의 함수로 전처리 후처리도 가능합니다! router.beforeEach((to, from, next) => { // ... }) router.afterEach((to, from) => { // ... }) export default router 7.Vuex앞서 Vue와 Vuex, 컴포넌트간 통신과 상태 관리에서 소개했던 상태 관리와 통신을 위한 Vuex도 추가합니다. Vuex는 하나의 Store만 쓸 경우 상태 변수의 과포화로 인해 유지 보수가 어려워질 수 있으므로 namespace: true 옵션을 통해 도메인별로 관리합니다.7-1) /[webpack루트]/vuex/store.js - Vuex 진입파일import Vue from 'vue' import Vuex from 'vuex' // 각 도메인별 store들이 들어있는 modules 를 임포트해줍니다. import * as modules from './modules/index' Vue.use(Vuex) export default new Vuex.Store({ state : { }, getter: { }, mutations : { }, actions : { }, modules : modules.default }) 7-2) /[webpack루트]/vuex/modules/index.js - 도메인별 Store 자동 바인딩 스크립트const files = require.context('.', false, /\.js$/) const modules = {} //자신(index.js)를 제외한 파일들을 파일이름을 Key로 modules에 담습니다. files.keys().forEach((key) => { if (key === './index.js') return modules[key.toLowerCase().replace(/(\.\/|\.js)/g, '')] = files(key).default }) export default modules 7-3) /[webpack루트]/vuex/modules/statistics.js(통계 store 파일) - 예시입니다.export default { namespaced : true, //해당 속성을 통해 파일명을 namespace로 사용합니다. state: { /* 상태값 및 데이터 */ ... }, getters: { }, mutations: { /* state 변경처리 */ ... }, actions: { /* 통신처리 */ ... } } namespace: true로 되어있으므로 파일명인 statistics를 namespace로 사용하게 됩니다. 따라서 store 각 항목에 대한 접근은 다음과 같이 이뤄지며 computed 속성에 state: this.$store.state.statistics 처럼 정의해두면 편리합니다.dispatch는 this.$store.dispatch(‘statistics/[action 이름]’)commit은 this.$store.commit(‘statistics/[mutation 이름]’)state 변수 접근은 this.$store.state.statistics.[state 이름]8.공통 처리 mixinapi 통신에 사용되는 통신 라이브러리와 그 라이브러리의 복잡한 설정 코드, 단순한 Toast 출력 함수, 로딩 이펙트를 보여주는 함수 등 모든 항목들이 매 페이지마다 있으면, 통일되지 못한 UI, 페이지마다 일관되지 못한 설정 등으로 휴먼 에러가 발생할 확률이 높아집니다. 유지 보수 측면에서도 비용이 높아집니다. 이러한 단순 반복 코드들은 한번만 정의하고 재사용하는 것이 바람직합니다. 나중에 수정할 때도 용이하죠.공통사항을 묶어 Vue 전역 믹스인으로 Vue 루트 객체에 추가합시다. 단, global 옵션인 만큼 조심해서 써야 합니다. 시스템에 영향을 줄 것 같으면 하위 컴포넌트 mixins 속성에 넣어 해당 스코프에서만 사용하는 것이 바람직합니다.8-1) /[webpack루트]/common/common-mixin.js (파일이름, 경로는 자유입니다!)import Vue from 'vue' import Vue from 'axios' import Cookies from 'js-cookie' const TIMEOUT = '[타임아웃 시간(ms)]' /* mixin의 기본 형태는 Vue 컴포넌트의 형태와 동일합니다. 주로 전역 통신과 상태 관리는 vuex store에서, 전역 data 속성과 전역 함수는 mixin에서 관리합니다. */ Vue.mixin({ /* 전역 사용 data속성 선언 */ data: () => { return { ... //이곳에 선언하는 data 속성은 전역에서 this로 접근 가능합니다. } }, created: function() { // 공용 axios 객체 생성 this.axios = axios.create({ timeout: TIMEOUT, withCredentials: true, //공통해더는 여기에 headers : { } }); //axios 의 success와 error를 mixin method에서 처리 하도록 등록 this.axios.interceptors.response.use(this.onSuccess, this.onError) }, /* 전역 사용 함수 선언 */ methods: { /* axios의 response handling 함수*/ onSuccess : response => { }, onError : function (error) { }, /*GET, POST 등의 통신 함수, Toast(alert) 표출함수, 에러핸들링함수 등 선언*/ /*... 내용이 너무 길어서 생략 ...*/ } }); 9.요약지금까지의 내용은 파일 경로를 토대로 요약하면 다음과 같습니다. 참고로 아래의 폴더 구조는 절대적인것은 아닙니다. 모든 폴더 구조는 자율이며, 폴더 구조에 맞게 webpack.config.js에서 조정해주면 됩니다.[프로젝트 루트] └ [웹팩 루트] └ package.json └ [Vue 소스 루트] └ [common] └ [router] └ index.js // 라우터 설정파일 - CI 컨트롤러와 url 맞춰줘야함 └ [vuex] └ index.js // 도메인별 store module export 스크립트 └ [modules] └ 도메인별 store.js └ [컴포넌트 폴더] //예시에서는 ststistics └ App.vue //진입점 vue파일 Vuex와 전역 mixin 세팅 └ index.html //index.js가 주입될 껍데기 └ index.js //진입점 js Vue-Router와 App.vue 세팅 └ [build] // 빌드파일경로 └ webpack.config.js //베이스 설정파일 └ webpack.dev.config.js //개발용 설정파일 └ webpack.prod.config.js //서비스용 설정파일 └ [application] //Codeigniter 루트 └ [controllers] └ [컨트롤러 경로] // 예시의 통계부분 └ [views] └ [웹팩빌드 결과 폴더] └ [index.php] // CI 에서 로드하는 view (index.html include) └ [index.html] // js 번들이 자동 주입된 빌드결과 파일 └ [include] └ [scripts] └ [빌드결과 js 경로] //public path 속성 경로 └ 빌드 결과 js chunk들 마치며관리자 서비스에서 완전한 Vue를 사용하기 위해 꽤 험난한 과정을 거쳤습니다. 지금도 잘 돌아가는 서비스에 리스크를 감수하면서도 새로운 것을 도입하려는 이유를 찾아야 했고, 한동안은 레거시와 Vue로 된 소스를 2중으로 개발해야 했습니다.게다가 이 글을 작성하기 시작했을 땐 Code Splitting 설정 방법이 바뀌어 적용하지도 못한 상황이었기 때문에 사실 Code Splitting 내용이 없었습니다. 그런데 글을 작성하면서 splitChunk옵션을 성공해버렸어요! 덕분에 이 글도 모두 수정해야 했죠. Vue의 도입을 고려하는 개발자분들에게 도움이 되길 바라는 마음으로 글을 마칩니다.참고1)Vuex Store는 Vue와 Vuex, 컴포넌트간 통신과 상태 관리에 자세히 정리해두었다.2) 브랜디 관리자 서비스는 jQuery로 작성되어 있다. 따라서 jQuery를 베재할 수만은 없는 상황이었다. 이에 따라 기존 jQuery 컴포넌트들에 대한 해결책은 천보성 팀장님이 작성한 JQuery 프로젝트에 VUE를 점진적으로 도입하기를 참고했다. props와 emit 기능을 이용해 jQuery로 제작한 컴포넌트를 깔끔하게 Wrapping 하는 방법에 대해 자세히 기술되어 있으며, 이를 활용하면 레거시 UI 플러그인을 마치 네이티브 Vue 플러그인처럼 사용할 수 있다.글강원우 과장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만
조회수 3229

ReactorKit 시작하기

ReactorKit 시작하기오늘은 StyleShare에서 ReactorKit을 사용한지 딱 1년이 되는 날입니다. ReactorKit은 반응형 단방향 앱을 위한 프레임워크로, StyleShare와 Kakao를 비롯한 여러 기업에서 사용하고 있는 기술입니다.StyleShare의 iOS 프로젝트 첫 커밋은 2011년 8월 23일입니다. 그 뒤로 약 7년간 크고 작은 기능을 추가하며 굉장히 큰 코드베이스를 가지게 되었습니다. 특히 2015년에는 스토어 기능을 런칭하면서 기존 서비스 만큼이나 많은 코드를 작성했습니다. 서비스 복잡도는 점점 높아졌고, 지속 가능한 코드베이스를 위해 많은 개선이 필요했습니다.ReactorKit은 많은 부분에 있어서 StyleShare가 가진 고민을 해결해주었습니다. Flux와 Reactive Programming의 개념을 결합하여 만들어진 ReactorKit에서는 사용자 인터랙션과 뷰 상태가 관찰 가능한 스트림을 통해 단방향으로 전달됩니다. 뷰와 비즈니스 로직을 분리할 수 있게 되면서 모듈간 결합도가 낮아지고 테스트하기 쉬워졌습니다. 또한, 자칫 복잡해질 수 있는 비동기 코드를 일관되게 작성할 수 있게 되었습니다.이 글에서는 ReactorKit의 기본 개념과 테스트를 위한 기법을 소개 합니다.데이터 흐름ReactorKit에는 뷰(View)와 리액터(Reactor)라는 개념이 존재합니다. 뷰는 상태를 표현합니다. 뷰 컨트롤러나 셀도 모두 뷰에 해당합니다. 뷰는 사용자 인터랙션을 추상화하여 리액터에 전달하고, 리액터에서 전달받은 상태를 각각의 뷰 컴포넌트에 바인드합니다. 뷰는 비즈니스 로직을 수행하지 않습니다.반대로, 리액터는 뷰의 상태를 관리합니다. 뷰에서 액션을 전달받으면 비즈니스 로직을 수행한 뒤 상태를 변경하여 다시 뷰에 전달합니다. 리액터는 UI 레이어에서 독립적이기 때문에 비교적 테스트하기 쉽습니다.ViewView 프로토콜을 적용하면 뷰를 정의할 수 있습니다. DisposeBag 속성과 bind(reactor:) 메서드를 필수로 정의해야 합니다.import ReactorKit import RxSwift class UserViewController: UIViewController, View { var disposeBag = DisposeBag() func bind(reactor: UserViewReactor) { } }<iframe width="700" height="250" data-src="/media/78a16e327ba4eb073cc5bdbb703c81f9?postId=c7b52fbb131a" data-media-id="78a16e327ba4eb073cc5bdbb703c81f9" data-thumbnail="https://i.embed.ly/1/image?url=https://avatars2.githubusercontent.com/u/931655?s=400&v=4&key=a19fcc184b9711e1b4764040d3dc5c07" class="progressiveMedia-iframe js-progressiveMedia-iframe" allowfullscreen="" frameborder="0" src="https://medium.com/media/78a16e327ba4eb073cc5bdbb703c81f9?postId=c7b52fbb131a" style="display: block; position: absolute; margin: auto; max-width: 100%; box-sizing: border-box; transform: translateZ(0px); top: 0px; left: 0px; width: 700px; height: 236.984px;">이 프로토콜을 정의하면 reactor 속성이 자동으로 생성됩니다. 이 속성에 새로운 값이 지정되면 bind(reactor:) 메서드가 자동으로 호출됩니다. 이곳에는 사용자 인터랙션을 리액터에 바인드하거나, 리액터의 상태를 각각의 뷰 컴포넌트에 바인드하는 코드를 작성합니다.func bind(reactor: UserViewReactor) { // Action self.followButton.rx.tap .map { Reactor.Action.follow } .bind(to: reactor.action) .disposed(by: self.disposeBag) // State reactor.state.map { $0.isFollowing } .distinctUntilChanged() .bind(to: self.followButton.rx.isSelected) .disposed(by: self.disposeBag) }<iframe width="700" height="250" data-src="/media/6a6d5aa66b156cae7d4475f6ed13efb0?postId=c7b52fbb131a" data-media-id="6a6d5aa66b156cae7d4475f6ed13efb0" data-thumbnail="https://i.embed.ly/1/image?url=https://avatars2.githubusercontent.com/u/931655?s=400&v=4&key=a19fcc184b9711e1b4764040d3dc5c07" class="progressiveMedia-iframe js-progressiveMedia-iframe" allowfullscreen="" frameborder="0" src="https://medium.com/media/6a6d5aa66b156cae7d4475f6ed13efb0?postId=c7b52fbb131a" style="display: block; position: absolute; margin: auto; max-width: 100%; box-sizing: border-box; transform: translateZ(0px); top: 0px; left: 0px; width: 700px; height: 325px;">Reactor리액터를 정의하기 위해서는 Reactor 프로토콜을 사용합니다. 사용자 인터랙션을 표현하는 Action과 뷰의 상태를 표현하는 State, 그리고 상태를 변경하는 가장 작은 단위인 Mutation을 클래스 내부에 필수로 정의해야 합니다. 또한 가장 첫 상태를 나타내는 initialState가 필요합니다.import ReactorKit import RxSwift final class UserViewReactor: Reactor { enum Action { case follow } enum Mutation { case setFollowing(Bool) } enum State { var isFollowing: Bool } let initialState: State = State(isFollowing: false) }<iframe width="700" height="250" data-src="/media/572f53fb442c67060d2a69f90a42a07b?postId=c7b52fbb131a" data-media-id="572f53fb442c67060d2a69f90a42a07b" data-thumbnail="https://i.embed.ly/1/image?url=https://avatars2.githubusercontent.com/u/931655?s=400&v=4&key=a19fcc184b9711e1b4764040d3dc5c07" class="progressiveMedia-iframe js-progressiveMedia-iframe" allowfullscreen="" frameborder="0" src="https://medium.com/media/572f53fb442c67060d2a69f90a42a07b?postId=c7b52fbb131a" style="display: block; position: absolute; margin: auto; max-width: 100%; box-sizing: border-box; transform: translateZ(0px); top: 0px; left: 0px; width: 700px; height: 435px;">Action이나 State와 달리 Mutation은 리액터 클래스 밖으로 노출되지 않습니다. 대신, 클래스 내부에서 Action과 State를 연결하는 역할을 수행합니다. Action이 리액터에 전달되면 두 단계를 거쳐서 뷰의 상태를 변경합니다.mutate() 함수에서는 Action 스트림을 Mutation 스트림으로 변환하는 역할을 합니다. 이곳에서 네트워킹이나 비동기로직 등의 사이드 이펙트를 처리합니다. 그 결과로 Mutation을 방출하면 그 값이 reduce() 함수로 전달됩니다. reduce() 함수는 이전 상태와 Mutation을 받아서 다음 상태를 반환합니다.func mutate(action: Action) -> Observable { switch action { case .follow: return UserService.follow() .map { Mutation.setFollowing(true) } .catchErrorJustReturn(Mutation.setFollowing(false)) case .unfollow: return UserService.unfollow() .map { Mutation.setFollowing(false) } .catchErrorJustReturn(Mutation.setFollowing(true)) } } func reduce(state: State, mutation: Mutation) -> State { var newState = state switch mutation { case let setFollowing(isFollowing): newState.isFollowing = isFollowing } return newState }<iframe width="700" height="250" data-src="/media/dc8fbdce8314a7eba99be944241c5432?postId=c7b52fbb131a" data-media-id="dc8fbdce8314a7eba99be944241c5432" data-thumbnail="https://i.embed.ly/1/image?url=https://avatars2.githubusercontent.com/u/931655?s=400&v=4&key=a19fcc184b9711e1b4764040d3dc5c07" class="progressiveMedia-iframe js-progressiveMedia-iframe" allowfullscreen="" frameborder="0" src="https://medium.com/media/dc8fbdce8314a7eba99be944241c5432?postId=c7b52fbb131a" style="display: block; position: absolute; margin: auto; max-width: 100%; box-sizing: border-box; transform: translateZ(0px); top: 0px; left: 0px; width: 700px; height: 522.984px;">테스팅테스트를 위해 가장 먼저 고민하게 되는 것은 ‘무엇을 테스트할 것인가’에 대한 것입니다. ReactorKit을 사용하면 뷰와 로직이 분리되어 상대적으로 쉽게 해답을 얻을 수 있습니다.View사용자 인터랙션이 발생했을 때 Action이 리액터로 잘 전달되는지리액터의 상태가 바뀌었을 때 뷰의 컴포넌트 속성이 잘 변경되는지ReactorAction을 받았을 때 원하는 State로 잘 변경되는지뷰 테스팅리액터의 stub 기능을 이용하면 뷰를 쉽게 테스트할 수 있습니다. stub 기능을 활성화하면 리액터가 받은 Action을 모두 기록하고, mutate()와 reduce()를 실행하는 대신 외부에서 상태를 설정할 수 있게 됩니다.func testAction_refresh() { // 1. Stub 리액터를 준비합니다. let reactor = MyReactor() reactor.stub.isEnabled = true // 2. Stub된 리액터를 주입한 뷰를 준비합니다. let view = MyView() view.reactor = reactor // 3. 사용자 인터랙션을 발생시킵니다. view.refreshControl.sendActions(for: .valueChanged) // 4. Reactor에 액션이 잘 전달되었는지를 검증합니다. XCTAssertEqual(reactor.stub.actions.last, .refresh) } func testState_isLoading() { // 1. Stub 리액터를 준비합니다. let reactor = MyReactor() reactor.stub.isEnabled = true // 2. Stub된 리액터를 주입한 뷰를 준비합니다. let view = MyView() view.reactor = reactor // 3. 리액터의 상태를 임의로 설정합니다. reactor.stub.state.value = MyReactor.State(isLoading: true) // 4. 그 때 뷰 컴포넌트의 속성이 잘 변하는지를 검증합니다. XCTAssertEqual(view.activityIndicator.isAnimating, true) }<iframe width="700" height="250" data-src="/media/9e5e0349766c69076a5081cbd680645b?postId=c7b52fbb131a" data-media-id="9e5e0349766c69076a5081cbd680645b" data-thumbnail="https://i.embed.ly/1/image?url=https://avatars2.githubusercontent.com/u/931655?s=400&v=4&key=a19fcc184b9711e1b4764040d3dc5c07" class="progressiveMedia-iframe js-progressiveMedia-iframe" allowfullscreen="" frameborder="0" src="https://medium.com/media/9e5e0349766c69076a5081cbd680645b?postId=c7b52fbb131a" style="display: block; position: absolute; margin: auto; max-width: 100%; box-sizing: border-box; transform: translateZ(0px); top: 0px; left: 0px; width: 700px; height: 721px;">리액터 테스팅리액터는 뷰에 비해서 상대적으로 테스트하기 쉽습니다. Action이 전달되었을 때 비즈니스 로직을 수행하여 State가 바뀌는지를 확인하면 됩니다.func testBookmark() { // 1. 리액터를 준비합니다. let reactor = MyReactor() // 2. 리액터에 액션을 전달합니다. reactor.action.onNext(.toggleBookmarked) // 3. 리액터의 상태가 변경되는지를 검증합니다. XCTAssertEqual(reactor.currentState.isBookmarked, true) } func testUnbookmark() { // 1. 리액터를 준비합니다. 액션을 미리 한 번 전달해서 테스트 환경을 만들어둡니다. let reactor = MyReactor() reactor.action.onNext(.toggleBookmarked) // 2. 리액터에 액션을 한 번 더 전달합니다. reactor.action.onNext(.toggleBookmarked) // 3. 리액터의 상태가 변경되는지를 검증합니다. XCTAssertEqual(reactor.currentState.isBookmarked, false) }<iframe width="700" height="250" data-src="/media/32af3eac8c1c9646bf95ea1442ad8ff4?postId=c7b52fbb131a" data-media-id="32af3eac8c1c9646bf95ea1442ad8ff4" data-thumbnail="https://i.embed.ly/1/image?url=https://avatars2.githubusercontent.com/u/931655?s=400&v=4&key=a19fcc184b9711e1b4764040d3dc5c07" class="progressiveMedia-iframe js-progressiveMedia-iframe" allowfullscreen="" frameborder="0" src="https://medium.com/media/32af3eac8c1c9646bf95ea1442ad8ff4?postId=c7b52fbb131a" style="display: block; position: absolute; margin: auto; max-width: 100%; box-sizing: border-box; transform: translateZ(0px); top: 0px; left: 0px; width: 700px; height: 522.984px;">마치며ReactorKit은 지금까지 CocoaPods에서 약 3만 7천회 다운로드 되었고, 약 730개 앱에서 사용되고 있습니다. 최근에는 Wantedly에서 사용하며 일본에서도 많은 호응을 얻고 있습니다. 공개된지 1년밖에 되지 않았지만 굉장히 좋은 평을 받으며 성장하고 있는 프레임워크입니다. 만약 새로운 프로젝트를 시작하거나, StyleShare와 비슷한 고민을 하고 계신다면 ReactorKit을 강력하게 추천합니다.ReactorKit GitHublet’Swift 2017 ReactorKit 발표 영상let’Swift 2017 ReactorKit 발표 자료#스타일쉐어 #개발팀 #개발자 #경험공유 #인사이트
조회수 7458

Kafka 모니터링

Kafka 도입 이후에 점진적으로 모니터링을 개선해나간다. Kafka와 그 제반 환경에 대해 이해한만큼 모니터링을 구성하고 모니터링 시스템에서 피드백을 받아 다시 학습하고 그렇게 배운 것을 토대로 다시 모니터링을 구성한다. 그 과정을 따라 나가며 Kafka 를 어떻게 모니터링하면 좋을지 알아보자.프로세스 모니터링아무래도 가장 기초적이면서 중요한 지표는 Kafka 프로세스가 잘 살아 있는지 확인하는 것이다. 다섯 대로 구성한 클러스터라면 상시 Kafka 프로세스가 확인되어야 한다. 만약 Kubernetes의 StatefulSet으로 Kafka 클러스터를 구성한 경우라면 Kafka 프로세스 다섯과 프로세스 모두를 엮는 서비스, 그러니까 로드밸런서 하나를 포함해 총 여섯 개의 프로세스를 확인해야 한다. DataDog(통칭 멍멍이)을 이용해 모니터링하는 경우라면 다음과 같이 설정하면 된다.Monitoring Kafka ClusterKafka는 Zookeeper를 이용하므로 ZooKeeper 역시 동일하게 모니터링하면 된다.DataDog을 이용한 메트릭 모니터링`dd-agent는 Kafka 관련 메트릭을 Broker, Consumer, Producer 세 측면에서 수집한다.Monitoring Kafka with DatadogMonitoring Kafka performance metrics위의 두 문서가 Kafka 모니터링의 상세한 측면을 기술하는데 멍멍이를 이용하지 않더라도 꼭 한번 읽어볼만하다. 두 문서가 매우 훌륭하므로 이 글에서는 Kubernetes 환경에 초점을 맞춰 주목할 점만 살펴본다.Kubernetes 환경에서 멍멍이 에이전트는 보통 PetSet으로 구성한다. 말인즉 Kubernetes Worker 한 대마다 에이전트를 한 대씩 띄워서 Worker 안에서 작동하는 모든 도커 인스턴스의 메트릭을 수집한다. 일단 에이전트를 설정하고 나면 아래와 같이 Kafka 모니터링이 정상 작동하는지 확인하면 된다.kube exec -it dd-agent-17vjg -- /opt/datadog-agent/agent/agent.py info kafka ----- - instance #kafka-kafka-0.broker-9999 [OK] collected 46 metrics - instance #kafka-kafka-1.broker-9999 [OK] collected 46 metrics - instance #kafka-kafka-2.broker-9999 [OK] collected 46 metrics - Collected 138 metrics, 0 events & 0 service checks Emitters ======== - http_emitter [OK]Broker의 경우는 설정하기가 비교적 쉽다. Kubernetes에서 Kafka 같은 Stateful cluster는 StatefulSet으로 구성하게 되는데 이때 호스트 주소가 kafka-0, kafka-1 같이 예측 가능한 이름으로 정해지기 때문에 kafka.yaml을 미리 작성해두기 쉽다.instances: - host: kafka-0.broker port: 9999 # This is the JMX port on which Kafka exposes its metrics (usually 9999) - host: kafka-1.broker port: 9999Producer와 Consumer 모니터링은 이와는 다르다. 구현하기 나름이지만 Producer 또는 Consumer가 되는 응용프로그램은 Stateless cluster일 때가 많고 그런 경우에는 Kubernetes에서 Deployment로 클러스터를 구성한다. 이때는 StatefulSet인 경우와 달리 호스트 주소가 worker-903266370-q3rcx와 같이 예측하기 힘들게 나오므로 에이전트에 미리 설정을 넣을 수가 없다. 상당히 까다로운 문제이다.Consumer 모니터링Kafka의 설계는 매우 단순하면서도 강력해서 감탄하곤 한다. 하지만 복잡한 문제를 단순하게 풀어냈다고 해서 이를 둘러싼 환경을 제대로 모니터링하는 것도 쉽다는 뜻은 아니다. 특히 Consumer groups이 제대로 제 몫을 하고 있는지 파악하기는 더 어렵다. Consumer group마다 모니터링 체계를 갖추자니 번거롭다. 게다가 그런 번거로움을 극복하더라도 Kafka에 문제가 있는 경우를 탐지하기는 여전히 어렵다. 예를 들어 Consumer에게 가야 할 메시지 중 5%가 실제로는 전달되지 않는다 하면 이를 Consumer가 알기는 어려울 것이다. 이 외에도 Consumer 측 모니터링이 엄청나게 까다로운 문제임은 Burrow: Kafka Consumer Monitoring Reinvented에서 잘 밝혔다.Burrow: Kafka Consumer Monitoring Reinvented에 등장하는 Burrow는 Kafka를 세상에 내놓은 LinkedIn 엔지니어링 팀이 개발한 Kafka 컨슈머 모니터링 도구이다. 커뮤니티에서는 대체로 현존하는 가장 뛰어난 모니터링 도구라고 인정하는 분위기이다. 그러니 다른 도구도 많지만 우선 Burrow로 모니터링을 강화하기로 한다.Burrow로 Consumer 모니터링하기Burrow는 Dockerize가 잘 되어 있기 때문에 사용하기 어렵지 않다. LinkedIn이 공식 도커 이미지까지 제공했더라면 더 좋겠으나 GitHub에 Dockerfile과 docker-compose.yml을 올려놓아서 도커를 잘 아는 사람이라면 큰 어려움 없이 바로 설정하고 설치할 수 있다. 컨테이너 환경의 관례대로 주요 설정을 환경변수로 미리 빼놨으면 더 좋았겠지만 …알람 받기Burrow는 문제가 생겼을 때 알람을 발송하는 기능이 있다. 위키에는 이메일 알람과 HTTP 알람(Webhook)을 어떻게 설정하는지 설명한다. 그런데 Burrow 소스코드를 살펴보면 문서화되지 않은 알람 기능도 있으니… 바로! Slack 알람을 제공한다. 아직 공식 문서가 없고 소스코드도 godoc 관례에 맞춰 설명해놓은 부분이 전혀 없기 때문에 소스코드를 읽거나 GitHub 이슈에서 논의된 내용을 토대로 설정해야 한다.[slacknotifier] enable=true url=https://hooks.slack.com/services/xxxx/xxxxxxxxxx group=local,critical-consumer-group group=local,other-consumer-group threshold=0 channel="#general" username=burrower interval=5 timeout=5 keepalive=30멍멍이로 메트릭을 꾸준히 수집하고 이슈가 생겼을 때 알람을 받고자 한다면 packetloop/datadog-agent-burrow를 이용하면 된다.This plugin will push the offsets for all topics (except the offsets_topic) and consumers for every kafka cluster it finds into Datadog as a metric.멍멍이 에이전트에 필요한 파일과 설정을 넣고 나면 아래와 같이 메트릭이 수집된다.kafka.topic.offsets 와 kafka.consumer.offsets 이렇게 두 개의 메트릭만 수집하지만 각 메트릭을 cluster, topic, consumer 세 개의 토픽으로 세분화하기 때문에 실제로는 꽤 다양한 지표를 멍멍이에서 확인하고 이용할 수 있다.알`람 설정하기앞서 살펴봤지만 프로세스 모니터링 등은 어렵지 않다. 클러스터에서 한대라도 빠지면 바로 알람을 받는다. 끝!하지만 그 외의 지표는 알람의 기준을 설정하기가 힘들다. 예를 들어 Burrow의 kafka.topic.offsets 값이 600이면 정상인가? 그렇다면 700은? 또는 400은? 도무지 감을 잡을 수가 없다. 이럴 때는 멍멍이가 제공하는 Outlier detection기능으로 알람을 걸면 쉽다. 이 기능은 쉽게 말해 평소와 다른 행동을 감지했을 때 알람을 보낸다. 그러므로 정상의 범위를 확실하게 모를 때 아주 유용하다.설정 자체는 DBSCAN 또는 MAD라는 알고리즘이 등장하는 것만 빼곤 여타의 모니터링과 다르지 않기 때문에 매우 쉽다.참고 문헌How to Monitor KafkaCollecting Kafka performance metricsOriginally published at Andromeda Rabbit.#데일리 #데일리호텔 #개발 #개발자 #개발팀 #인사이트 #기술스택 #스택소개 #Kafka
조회수 2728

React + Decorator + HOC = Fantastic!!

React + Decorator + HOC = Fantastic!!지난 포스팅에서는 ES7의 Decorator 문법을 이용해 선언된 클래스와 그 프로퍼티들을 디자인 시간에 변경하는 법을 알아보았습니다. 그렇다면 리액트 컴포넌트와 Decorator가 만나면 어떤 시너지가 발생할까요?만약 ES7의 Decorator에 대해 모르신다면 지난 포스팅을 읽고 오시는 걸 권장합니다. 이 포스팅은 독자들이 Decorator에 대해 이미 알고 있다고 가정하고 작성됐습니다.Higher Order Component리액트 공식 문서를 보면 Higher Order Component(이하 HOC)를 다음과 같이 설명하고 있습니다.리액트 컴포넌트 로직을 재활용할 수 있는 고급 기법리액트에서 공식적으로 제공하는 API가 아니라 단순히 아키텍쳐이 설명으로는 HOC가 어떤 역할을 하는지 이해하기는 역부족이기 때문에 간단한 예제를 통해 HOC를 어떻게 작성하는지 알아보겠습니다.function withSay(WrappedComponent) {     return class extends React.Component {     say() {       return 'hello'     } render() {       return (                   {...this.props}           say={this.say} />       )     }   } } withSay 함수는 WrappedComponent를 인자로 받아 원하는 속성들을 결합해 새로운 컴포넌트를 반환합니다. 이렇게 만들어진 withSay 함수는 아래와 같이 사용 가능합니다.@withSay class withOutSay extends React.Component {     render() {     return (               {this.props.say()}           )   } } withOutSay 컴포넌트는 say 메소드를 가지고 있지 않습니다. 하지만 withSay 함수를 사용하니 say 메소드를 사용할 수 있게 됐습니다. 이처럼 컴포넌트를 인자로 받아 입맛에 맞게 바꾼 뒤 새로운 컴포넌트로 반환하는 기법을 HOC라고 부릅니다.그렇다면 HOC는 리액트에서 어떻게 사용을 해야 효율적일까요?Cross Cutting Concerns개발을 하다 보면 다음과 같은 상황에 직면하는 경우가 종종 있습니다.개발 전반에 걸쳐 반복해서 등장하는 로직그럼에도 불구하고 모듈화가 쉽지 않은 로직예를 들어 방명록 작성, 게시글 작성, 게시글 스크랩을 하는 컴포넌트들에서 유저 인증과 에러 처리의 과정이 필요하다고 했을 때 어떻게 코드를 디자인해야 할까요? 컴포넌트와 직접적으로 연관이 없는 기능들이 컴포넌트와의 결합이 너무 강해 쉽게 모듈화를 시키지 못합니다.그림 1. Cross Cutting Concerns의 예시이렇듯 코드 디자인적인 측면에서 공통적으로 발생하지만 쉽게 분리를 시키지 못하는 문제를 Cross Cutting Concerns라고 합니다. 이 문제를 끌어안고 가면 프로젝트의 코드는 쉽게 스파게티가 되고 나중에는 유지 보수를 하기 힘들어집니다.하지만 우리게에는 HOC와 Decorator가 있고 이를 이용해 이 문제를 쉽게 해결할 수 있습니다.유저 인증 문제를 HOC로 해결아래는 인증이 안된 유저에게 다른 페이지를 보여주는 코드입니다.class TeamChat extends React.Component {     constructor() {     super()     this.state = {       unAuthenticated: false     }   } componentWillMount() {     if (!this.props.user) {       this.setState({ unAuthenticated: true })     }   } render() {     if (this.state.unAuthenticated) {       return     }     return I'm TeamChat   } } 유저 인증을 전통적인 if-else 구문으로 구현했습니다. 당장 이 컴포넌트를 본다면 문제가 없어 보입니다. 어떻게 보면 정답처럼 보이기도 합니다. 하지만 유저 인증이 필요한 컴포넌트가 많아지면 상황이 달라집니다.100개의 컴포넌트에서 위와 같은 방식으로 유저 인증을 하고 있는데 유저 인증을 하는 로직이 변경된 상황을 생각해 봅시다. 100개의 컴포넌트 모두 유저 인증 코드를 바꿔야 하는 상황에 직면하게 됩니다. 전부 다 바꾸는 것도 일이지만 실수로 몇 개의 컴포넌트를 수정하지 않을 확률이 농후합니다. 당장에는 간단하지만 잠재적 위험을 안고 있는 위 코드는 아래와 같이 수정되어야 합니다.function mustToAuthenticated(WrappedComponent) {     return class extends React.Component {     constructor() {       super()       this.state = {         unAuthenticated: false       }      } componentWillMount() {       if (!this.props.user) {         this.setState({ unAuthenticated: true })       }     } render() {       if (this.state.unAuthenticated) {         return       }       return     }    } } HOC를 이용해 확장이 용이한 유저 인증 로직이 탄생했습니다!! 이렇게 만들어진 HOC는 아래와 같이 적용이 가능합니다.@mustToAuthenticated class TeamChat extends React.Component {     render() {     return I'm TeamChat   } } @mustToAuthenticated class UserChat extends React.Component {     render() {     return I'm UserChat   } } 기존의 코드와 비교했을 때 코드가 훨씬 간단해진 것을 확인할 수 있습니다. 비단 코드만 간단해진 것뿐만 아니라 아래와 같은 추가 효과를 기대할 수 있습니다.유저 인증 로직이 컴포넌트와 분리가 되어 자신이 맡은 역할에만 집중할 수 있습니다.유저 인증 로직이 바뀌어도 코드를 수정해야 할 곳은 하나의 컴포넌트뿐입니다.예시로 작성한 HOC는 최소한의 코드로만 작성된 예시입니다. 실제 제품에서 사용되기 위해서는 몇 가지 고려해야 할 사항이 있는데 이는 리액트 공식 문서를 참고해주세요.i18n 컴포넌트를 HOC로 작성채널 서비스는 한국어, 영어, 일본어를 지원하기 때문에 번역 기능이 필요했습니다. 초기에는 번역 서비스를 아래와 같이 구현했습니다.@connect(state => ({   locale: getLocale(state) }) class Channel extends React.Component {     render() {     const local = this.props.locale     const translate = TranslateService.get(locale)     return (               {translate.title}         {translate.description}           )   } } 처음에는 위와 같은 방식으로 번역 서비스를 구현하는 것이 괜찮았습니다. 하지만 번역을 제공해야 하는 컴포넌트가 많아지면 많아질수록 중복되는 코드가 많아지는 것을 보고 아래과 같이 HOC를 이용해 코드의 중복을 제거했습니다.function withTranslate(WrappedComponent) { @connect(state => ({     locale: getLocale(state)   }))   class DecoratedComponent extends React.Component {     render() {       const locale = this.props.locale       const translate = TranslateService.get(locale) return (                   {...this.props}           translate={translate} />       )    }   } } 이렇게 작성된 HOC는 아래와 같이 사용이 가능합니다.@withTranslate class Channel extends React.Component {     render() {     const translate = this.props.translate     return (               {translate.title}         {translate.description}           )   } } HOC의 작성 방법은 예시로 작성한 두 개의 HOC에서 크게 벗어나지 않습니다. 이를 응용해 자신의 프로젝트에 맞는 코드를 작성해보세요.중첩 가능한 HOCHOC는 여러 개를 중첩해서 사용할 수 있습니다.. 예를 들어 유저 인증과 i18n 서비스를 동시에 제공하고 싶을 때 두 HOC를 중첩해서 사용하면 됩니다.@mustToAuthenticated @withTranslate class Channel extends React.Component {     render() {     return (               {`Hello!! ${this.props.user.name}`         {translate.title}         {translate.description}           )   } } 마무리이상으로 리액트에서 HOC를 사용할 수 있는 상황과 작성 방법을 알아보았습니다. 본 포스팅에서 다루지는 않았지만 만능처럼 소개한 HOC에도 몇 가지 단점은 존재합니다.Component Unit Test를 할 때 문제가 있을 수 있습니다.HOC를 몇 개 중첩하면 디버깅이 힘들 수 있습니다.WrappedComponent에 직접적으로 ref를 달 수 없어 우회 방법을 사용해야 합니다.비동기 작업과 같이 사용하다 보면 예상치 못한 결과를 만날 수 있습니다.하지만 이러한 단점에도 불구하고 상속을 제공하지 않은 리액트에서 HOC는 많은 문제를 효율적으로 해결해주는 단비와 같은 존재입니다. 유명한 리액트 라이브러리들(react-redux, redux-form 등)은 이미 예전부터 HOC를 사용해 사용자들에게 편의를 제공해 왔습니다. 이러한 라이브러리들과 자신의 프로젝트가 직면하고 있는 문제에 맞는 HOC를 작성해 같이 사용한다면 우아하고 아름다운 설계에 한층 더 다가간 프로젝트를 발견할 수 있습니다.마지막으로 한 문장을 남기고 본 포스팅을 마치도록 하겠습니다.React + Decorator + HOC = Fantastic!!본 포스팅은 2017 리액트 서울에서 발표한 내용입니다. 발표 자료와 발표 영상을 확인해보세요.#조이코퍼레이션 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 1186

레진 기술 블로그 - AWS Auto Scalinging Group 을 이용한 배포

레진코믹스의 서버 시스템은 잘 알려진대로 Google AppEngine에서 서비스되고 있지만, 이런저런 이유로 인해 최근에는 일부 컴포넌트가 Amazon Web Service에서 서비스되고 있습니다. AWS 에 새로운 시스템을 셋업하면서, 기존에 사용하던 PaaS인 GAE에서는 전혀 고민할 필요 없었던, 배포시스템에 대한 고민이 필요했습니다. 좋은 배포전략과 시스템은 안정적으로 서비스를 개발하고 운영하는데 있어서 필수적이죠.초기에는 Beanstalk을 이용한 운영에서, Fabric 을 이용한 배포 등의 시행착오 과정을 거쳤으나, 현재는 (스케일링을 위해 어차피 사용할 수밖에 없는) Auto Scaling Group을 이용해서 Blue-green deployment로 운영 중입니다. ASG는 여러 특징 덕분에 배포에도 유용하게 사용할 수 있습니다.ASG를 이용한 가장 간단한 배포는, Instance termination policy 를 응용할 수 있습니다. 기본적으로 ASG가 어떤 인스턴스를 종료할지는 AWS Documentation 에 정리되어 있으며, 추가적으로 다음과 같은 방식을 선택할 수 있습니다.OldestInstanceNewestInstanceOldestLaunchConfigurationClosestToNextInstanceHour여기서 주목할 건 OldestInstance 입니다. ASG가 항상 최신 버전의 어플리케이션으로 스케일아웃되게 구성되어 있다면, 단순히 인스턴스의 수를 두배로 늘린 뒤 Termination policy 를 OldestInstance 로 바꾸고 원래대로 돌리면 구버전 인스턴스들부터 종료되면서 배포가 끝납니다. 그러나 이 경우, 배포 직후 모니터링 과정에서 문제가 발생할 경우 기존의 인스턴스들이 이미 종료된 상태이기 때문에 롤백을 위해서는 (인스턴스를 다시 생성하면서) 배포를 다시 한번 해야 하는 반큼 빠른 롤백이 어렵습니다.Auto scaling lifecycle 을 이용하면, 이를 해결하기 위한 다른 방법도 있습니다. Lifecycle 은 다음과 같은 상태 변화를 가집니다.기본적으로,ASG의 인스턴스는 InService 상태로 진입하면서 (설정이 되어 있다면) ELB에 추가됩니다.ASG의 인스턴스는 InService 상태에서 빠져나오면서 (설정이 되어 있다면) ELB에서 제거됩니다.이를 이용하면, 다음과 같은 시나리오로 배포를 할 수 있습니다.똑같은 ASG 두 개를 구성(Group B / Group G)하고, 그 중 하나의 그룹으로만 서비스를 운영합니다.Group B가 라이브 중이면 Group G의 인스턴스는 0개입니다.새로운 버전을 배포한다면, Group G의 인스턴스 숫자를 Group B와 동일하게 맞춰줍니다.Group G가 InService로 들어가고 ELB healthy 상태가 되면, Group B의 인스턴스를 전부 Standby로 전환합니다.롤백이 필요하면 Standby 상태인 Group B를 InService 로 전환하고 Group G의 인스턴스를 종료하거나 Standby로 전환합니다.문제가 없다면 Standby 상태인 Group B의 인스턴스를 종료합니다.이제 훨씬 빠르고 안전하게 배포 및 롤백이 가능합니다. 물론 실제로는 생각보다 손이 많이 가는 관계로(특히 PaaS인 GAE에 비하면), 이를 한번에 해주는 스크립트를 작성해서 사용중입니다. 대략 간략하게는 다음과 같습니다. 실제 사용중인 스크립트에는 dry run 등의 잡다한 기능이 많이 들어가 있어서 걷어낸 pseudo code 입니다. 스크립트는 사내 PyPI 저장소를 통해 공유해서 사용 중입니다.def deploy(prefix, image_name, image_version): '''Deploy specified Docker image name and version into Auto Scaling Group''' asg_names = get_asg_names_from_tag(prefix, 'docker:image:name', image_name) groups = get_auto_scaling_groups(asg_names) # Find deployment target set future_set = set(map(lambda g: g['AutoScalingGroupName'].split('-')[-1], filter(lambda g: not g['DesiredCapacity'], groups))) if len(future_set) != 1: raise ValueError('Cannot specify target auto scaling group') future_set = next(iter(future_set)) if future_set == 'green': current_set = 'blue' elif future_set == 'blue': current_set = 'green' else: raise ValueError('Set name shoud be green or blue') # Deploy to future group future_groups = filter(lambda g: g['AutoScalingGroupName'].endswith(future_set), groups) for group in future_groups: asg_client.create_or_update_tags(Tags=[ { 'ResourceId': group['AutoScalingGroupName'], 'ResourceType': 'auto-scaling-group', 'PropagateAtLaunch': True, 'Key': 'docker:image:version', 'Value': image_version, } ]) # Set capacity, scaling policy, scheduled actions same as current group set_desired_capacity_from(current_set, group) move_scheduled_actions_from(current_set, group) move_scaling_policies(current_set, group) # Await ELB healthy of instances in group await_elb_healthy(future_groups) # Entering standby for current group for group in filter(lambda g: g['AutoScalingGroupName'].endswith(current_set), groups): asg_client.enter_standby( AutoScalingGroupName=group['AutoScalingGroupName'], InstanceIds=list(map(lambda i: i['InstanceId'], group['Instances'])), ShouldDecrementDesiredCapacity=True ) def rollback(prefix, image_name, image_version): '''Rollback standby Auto Scaling Group to service''' asg_names = get_asg_names_from_tag(prefix, 'docker:image:name', image_name) groups = get_auto_scaling_groups(asg_names) def filter_group_by_instance_state(groups, state): return filter( lambda g: len(filter(lambda i: i['LifecycleState'] == state, g['Instances'])) == g['DesiredCapacity'] and g['DesiredCapacity'], groups ) standby_groups = filter_group_by_instance_state(groups, 'Standby') inservice_groups = filter_group_by_instance_state(groups, 'InService') # Entering in-service for standby group for group in standby_groups: asg_client.exit_standby( AutoScalingGroupName=group['AutoScalingGroupName'], InstanceIds=list(map(lambda i: i['InstanceId'], group['Instances'])) ) # Await ELB healthy of instances in standby group await_elb_healthy(standby_groups) # Terminate instances to rollback for group in inservice_groups: asg_client.set_desired_capacity(AutoScalingGroupName=group['AutoScalingGroupName'], DesiredCapacity=0) current_set = group['AutoScalingGroupName'].split('-')[-1] move_scheduled_actions_from(current_set, group) move_scaling_policies(current_set, group) 몇 가지 더…Standby 로 돌리는 것 이외에 Detached 상태로 바꾸는 것도 방법입니다만, 인스턴스가 ASG에서 제거될 경우, 자신이 소속된 ASG를 알려주는 값인 aws:autoscaling:groupName 태그가 제거되므로 인스턴스나 ASG가 많아질 경우 번거롭습니다.cloud-init 를 어느 정도 최적화해두고 ELB healthcheck 를 좀 더 민감하게 설정하면, ELB 에 투입될 때까지 걸리는 시간을 상당히 줄일 수 있긴 하므로, 단일 ASG로 배포를 하더라도 롤백에 걸리는 시간을 줄일 수 있습니다. 저희는 scaleout 시작부터 ELB에서 healthy 로 찍힐 때까지 70초 가량 걸리는데, 그럼에도 불구하고 아래의 이유 때문에 현재의 방식으로 운영중입니다.같은 방식으로 단일 ASG로 배포를 할 수도 있지만, 배포중에 혹은 롤백 중에 scaleout이 돌면서 구버전 혹은 롤백 버전의 인스턴스가 투입되어버리면 매우 귀찮아집니다. 이를 방지하기 위해서라도 (Blue-green 방식의) ASG 두 개를 운영하는게 안전합니다.같은 이유로, 배포 대상의 버전을 S3나 github 등에 기록하는 대신 ASG의 태그에 버전을 써 두고 cloud-init 의 user-data에서 그 버전으로 어플리케이션을 띄우게 구성해 두었습니다. 이 경우 인스턴스의 태그만 확인해도 현재 어떤 버전이 서비스되고 있는지 확인할 수 있다는 장점도 있습니다.다만 ASG의 태그에 Tag on instance 를 체크해 두더라도, cloud-init 안에서 이를 조회하는 경우는 주의해야 합니다. ASG의 태그가 인스턴스로 복사되는 시점은 명확하지 않습니다. 스크립트 실행 중에 인스턴스에는 ASG의 태그가 있을 수도, 없을 수도 있습니다.굳이 인스턴스의 Lifecycle 을 Standby / InService 로 전환하지 않고도 ELB 를 두 개 운영하고 route 53 에서의 CNAME/ALIAS swap 도 방법이지만, DNS TTL은 아무리 짧아도 60초는 걸리고, JVM처럼 골치아픈 동작 사례도 있는만큼 선택하지 않았습니다.물론 이 방법이 최선은 절대 아니며(심지어 배포할때마다 돈이 들어갑니다!), 현재는 자원의 활용 등 다른 측면에서의 고민 때문에 새로운 구성을 고민하고 있습니다. 이건 언젠가 나중에 다시 공유하겠습니다. :)
조회수 1015

비트윈 시스템 아키텍처

VCNC는 커플을 위한 모바일 앱 비트윈을 서비스하고 있습니다. 비트윈은 사진, 메모, 채팅, 기념일 등 다양한 기능을 제공하며, 오픈 베타 테스트를 시작한 2011년 11월부터 현재까지 연인 간의 소통을 돕고 있습니다. 그동안 비트윈 시스템 아키텍처에는 많은 변화가 있었으며 다양한 결정을 하였습니다. 비트윈 아키텍처를 발전시키면서 배우게 된 여러 가지 노하우를 정리하여 공유해보고자 합니다. 그리고 저희가 앞으로 나아갈 방향을 소개하려 합니다.소프트웨어 스택Java: 비트윈 API서버는 Java로 작성되어 있습니다. 이는 처음 비트윈 서버를 만들기 시작할 때, 서버 개발자가 가장 빨리 개발해낼 수 있는 언어로 프로그래밍을 시작했기 때문입니다. 지금도 자바를 가장 잘 다루는 서버 개발자가 많으므로 여전히 유효한 선택입니다.Netty: 대부분의 API는 HTTP로 호출되며, 채팅은 모바일 네트워크상에서의 전송 속도를 위해 TCP상에서 프로토콜을 구현했습니다. 두 가지 모두 Netty를 통해 사용자 요청을 처리합니다. Netty를 선택한 것은 뛰어난 성능과 서비스 구현 시 Thrift 서비스를 통해 HTTP와 TCP 프로토콜을 한 번에 구현하기 쉽다는 점 때문이었습니다.Thrift: API서버의 모든 서비스는 Thrift 서비스로 구현됩니다. 따라서 TCP뿐만 아니라 HTTP 또한 Thrift 인터페이스를 사용합니다. HTTP를 굳이 Thrift서비스로 구현한 이유는, TCP로 메세징 전송 시 똑같은 서비스를 그대로 사용하기 위함이었습니다. 덕분에 빠른 채팅 구현 시, 이미 구현된 서비스들을 그대로 사용할 수 있었습니다. 또한, 채팅 패킷들은 패킷 경량화를 위해 snappy로 압축하여 송수신합니다. 모바일 네트워크상에서는 패킷이 작아질수록 속도 향상에 크게 도움이 됩니다.HBase: 비트윈의 대부분 트랜젝션은 채팅에서 일어납니다. 수많은 메시지 트랜젝션을 처리하기 위해 HBase를 선택했으며, 당시 서버 개발자가 가장 익숙한 데이터베이스가 HBase였습니다. 서비스 초기부터 확장성을 고려했어야 했는데, RDBMS에서 확장성에 대해 생각하는 것보다는 당장 익숙한 HBase를 선택하고 운영하면서 나오는 문제들은 차차 해결하였습니다.ZooKeeper: 커플들을 여러 서버에 밸런싱하고 이 정보를 여러 서버에서 공유하기 위해 ZooKeeper를 이용합니다. Netflix에서 공개한 오픈 소스인 Curator를 이용하여 접근합니다.AWS비트윈은 AWS의 Tokyo리전에서 운영되고 있습니다. 처음에는 네트워크 및 성능상의 이유로 국내 IDC를 고려하기도 했으나 개발자들이 IDC 운영 경험이 거의 없는 것과, IDC의 실질적인 TCO가 높다는 문제로 클라우드 서비스를 이용하기로 하였습니다. 당시 클라우드 서비스 중에 가장 안정적이라고 생각했던 AWS 를 사용하기로 결정했었고, 지금도 계속 사용하고 있습니다.EC2: 비트윈의 여러 부가적인 서비스를 위해 다양한 종류의 인스턴스를 사용 중이지만, 메인 서비스를 운용하기 위해서는 c1.xlarge와 m2.4xlarge 인스턴스를 여러 대 사용하고 있습니다.API 서버: HTTP 파싱이나 이미지 리시아징등의 연산이 이 서버에서 일어납니다. 이 연산들은 CPU 가 가장 중요한 리소스이기 때문에, c1.xlarge를 사용하기로 했습니다.Database 서버: HDFS 데이터 노드와 HBase 리전 서버들이 떠있습니다. 여러 번의 테스트를 통해 IO가 병목임을 확인하였고, 따라서 모든 데이터를 최대한 메모리에 올리는 것이 가장 저렴한 설정이라는 것을 확인하였습니다. 이런 이유 때문에 68.4GB의 메모리를 가진 m2.4xlarge를 Database 서버로 사용하고 있습니다.EBS: 처음에는 HBase상 데이터를 모두 EBS에 저장하였습니다. 하지만 일정 시간 동안 EBS의 Latency가 갑자기 증가하는 등의 불안정한 경우가 자주 발생하여 개선 방법이 필요했는데, 데이터를 ephemeral storage에만 저장하기에는 안정성이 확인되지 않은 상태였습니다. 위의 두 가지 문제를 동시에 해결하기 위해서 HDFS multiple-rack 설정을 통해서 두 개의 복제본은 ephemeral storage에 저장하고 다른 하나의 복제본은 PIOPS EBS에 저장되도록 구성하여 EBS의 문제점들로부터의 영향을 최소화하였습니다.S3: 사용자들이 올리는 사진들은 s3에 저장됩니다. 사진의 s3키는 추측이 불가능하도록 랜덤하게 만들어집니다. 어차피 하나의 사진은 두 명밖에 받아가지 않고 클라이언트 로컬에 캐싱되기 때문에 CloudFront를 사용하지는 않습니다.ELB: HTTP는 사용자 요청의 분산과 SSL적용을 위해 ELB를 사용합니다. TCP는 TLS를 위해 ELB를 사용합니다. SSL/TLS 부분은 모두 AWS의 ELB를 이용하는데, 이는 API서버의 SSL/TLS처리에 대한 부담을 덜어주기 위함입니다.CloudWatch: 각 통신사와 리전에서 비트윈 서버로의 네트워크 상태와 서버 내의 요청 처리 시간 등의 메트릭을 CloudWatch로 모니터링 하고 있습니다. 따라서 네트워크 상태나 서버에 문제가 생긴 경우, 이메일 등을 통해 즉각 알게 되어, 문제 상황에 바로 대응하고 있습니다. Netflix의 Servo를 이용하여 모니터링 됩니다.현재의 아키텍처처음 클로즈드 베타 테스트때에는 사용자 수가 정해져 있었기 때문에 하나의 인스턴스로 운영되었습니다. 하지만 처음부터 인스턴스 숫자를 늘리는 것만으로도 서비스 규모를 쉽게 확장할 수 있는 아키텍쳐를 만들기 위한 고민을 하였습니다. 오픈 베타 이후에는 발생하는 트래픽에 필요한 만큼 여러 대의 유연하게 서버를 운영하였고, 현재 채팅은 TCP 위에서 구현한 프로토콜을 이용하여 서비스하고 있습니다.HTTP 요청은 하나의 ELB를 통해 여러 서버로 분산됩니다. 일반적인 ELB+HTTP 아키텍처와 동일합니다.채팅은 TCP 연결을 맺게 되는데, 각 커플은 특정 API 서버로 샤딩되어 특정 커플에 대한 요청을 하나의 서버가 담당합니다. 비트윈에서는 커플이 샤딩의 단위가 됩니다.이를 통해, 채팅 대화 내용 입력 중인지 여부와 같이 굉장히 빈번하게 값이 바뀌는 정보를 인메모리 캐싱할 수 있게 됩니다. 이런 정보는 휘발성이고 매우 자주 바뀌는 정보이므로, HBase에 저장하는 것은 매우 비효율적입니다.Consistent Hashing을 이용하여 커플을 각 서버에 샤딩합니다. 이는 서버가 추가되거나 줄어들 때, 리밸런싱되면서 서버간 이동되는 커플들의 수를 최소화 하기 위함입니다.클라이언트는 샤딩 정보를 바탕으로 특정 서버로 TCP연결을 맺게 되는데, 이를 위해 각 서버에 ELB가 하나씩 붙습니다. 어떤 서버로 연결을 맺어야 할지는 HTTP 혹은 TCP 프로토콜을 통해 알게 됩니다.Consistent Hashing을 위한 정보는 ZooKeeper를 통해 여러 서버간 공유됩니다. 이를 통해 서버의 수가 늘어나거나 줄어들게 되는 경우, 각 서버는 자신이 담당해야 하는 샤딩에 대한 변경 정보에 대해 즉각 알게 됩니다.이런 아키텍처의 단점은 다음과 같습니다.클라이언트가 자신이 어떤 서버로 붙어야 하는지 알아야 하기 때문에 프로토콜 및 아키텍처 복잡성이 높습니다.서버가 늘어나는 경우, 순식간에 많은 사용자 연결이 맺어지게 됩니다. 따라서 새로 추가되는 ELB는 Warm-up이 필요로 하며 이 때문에 Auto-Scale이 쉽지 않습니다.HBase에 Write연산시, 여러 서버로 복제가 일어나기 때문에, HA을 위한 Multi-AZ 구성을 하기가 어렵습니다.한정된 자원으로 동작 가능한 서버를 빨리 만들어내기 위해 이처럼 디자인하였습니다.미래의 아키텍처현재 아키텍처에 단점을 보완하기 위한 해결 방법을 생각해보았습니다.Haeinsa는 HBase상에서 트렌젝션을 제공하기 위해 개발 중인 프로젝트입니다. 구현 완료 후, 기능 테스트를 통과하였고, 퍼포먼스 테스트를 진행하고 있습니다. HBase상에서 트렌젝션이 가능하게 되면, 좀 더 복잡한 기능들을 빠르게 개발할 수 있습니다. 서비스에 곧 적용될 예정입니다.Multitier Architecture를 통해 클라이언트와 서버 간에 프로토콜을 단순화시킬 수 있습니다. 이 부분은 개발 초기부터 생각하던 부분인데, 그동안 개발을 하지 못하고 있다가, 지금은 구현을 시작하고 있습니다. 커플은 특정 Application 서버에서 담당하게 되므로, 인메모리 캐싱이 가능하게 됩니다. 클라이언트는 무조건 하나의 ELB만 바라보고 요청을 보내게 되고, Presentation 서버가 사용자 요청을 올바른 Application 서버로 릴레이 하게 됩니다.Multitier Architecture를 도입하면, 더 이상 ELB Warm-up이 필요하지 않게 되므로, Auto-Scale이 가능하게 되며, 좀 더 쉬운 배포가 가능하게 됩니다.Rocky는 API 서버의 Auto-Failover와 커플에 대한 샤딩을 직접 처리하는 기능을 가진 프로젝트입니다. 현재 설계가 어느 정도 진행되어 개발 중에 있습니다. 알람이 왔을 때 서버 팀이 마음을 놓고 편히 잠을 잘 수 있는 역할을 합니다.기본적인 것은 위에서 언급한 구조와 동일하지만 몇 가지 기능이 설정을 추가하면 Multi-AZ 구성이 가능합니다.특정 커플에 대한 모든 정보는 하나의 HBase Row에 담기게 됩니다.HBase의 특정 리전에 문제가 생긴 경우, 일정 시간이 지나면 자동으로 복구되긴 하지만 잠시 동안 시스템 전체에 문제가 생기가 됩니다. 이에 대해 Pinterest에서 Clustering보다는 Sharding이 더 낫다는 글을 쓰기도 했습니다. 이에 대한 해결책은 다음과 같습니다.원래는 Consistent Hashing을 사용하여 커플들을 Application 서버에 샤딩하였습니다. 하지만 이제는 HBase에서 Row를 각 리전에 수동으로 할당하고, 같은 리전에 할당된 Row에 저장된 커플들은 같은 Application 서버에 할당하도록 합니다.이 경우에, 같은 커플들을 담당하는 Application 서버와 HBase 리전 서버는 물리적으로 같은 머신에 둡니다.이렇게 구성 하는 경우, 특정 HBase 리전이나 Application 서버에 대한 장애는 특정 샤드에 국한되게 됩니다. 이와 같이 하나의 머신에 APP과 DB를 같이 두는 구성은 구글에서도 사용하는 방법입니다.이와 같이 구성하는 경우, Multi-AZ 구성이 가능하게 됩니다.AWS에서 같은 리전에서 서로 다른 Zone간 통신은 대략 2~3ms 정도 걸린다고 합니다.Presentation의 경우, 비동기식으로 동작하기 때문에 다른 리전으로 요청을 보내도 부담이 되지 않습니다.HBase에서 Write가 일어나면 여러 복제본을 만들게 됩니다. 하나의 사용자 요청에 대해 Write가 여러번 일어나기 때문에 HBase연산의 경우에는 서로 다른 Zone간 Latency가 부담으로 작용됩니다. Haeinsa가 적용되면, 한 트렌젝션에 대해서 연산을 Batch로 전송하기 때문에 AZ간 Latency 부담이 적습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!
조회수 2099

외부 서비스 이용을 장려해서 개발력을 아끼자.

2017년 목표 중 하나인 Product Management에 관한 weekly 포스팅의 네번째 포스팅입니다. 원래는 weekly 포스팅이었는데..어느덧 biweekly 포스팅이 되고 있습니다. 이번에는 제가 Product Manager로서 “팀 내부 직접 개발 vs 외부 서비스 이용”에 대해서 어떻게 생각하는지에 대해서 정리할까 합니다. 이번에도 confidential한 내용은 생략했습니다.이거 한 달이면 만들어요.제품 개발을 하다보면 Core feature는 아니지만 더 나은 사용자 경험을 위해 필요한 기능을 추가해야 하는 경우가 있습니다. 그리고 이 feature가 개발하기에 쉽지 않다고 예상되는 경우가 있습니다. 이런 상황이 오면 PM, 제품 담당자(혹은 기획자, 대표)은 내부에서 개발할지 아니면 외주를 줄 지, 아니면 외부 서비스를 이용할 지 등을 고민합니다. 그리고 판단을 돕기 위해 기획자/개발자가 모여서 이런 대화를 나눕니다.이거 다 만드는데 얼마나 걸릴 것 같아요?이거 한 달이면 만들어요.그렇습니다. 저 대화가 바로 나중에 개발자가 “내가 이걸 왜 하고 있죠?”라고 얘기하는 그 순간의 시초입니다.하지만 기간은 두 배가 걸린다.하지만 직접 개발에 들어가면 기간(UX, UI디자인 포함해서)은 점점 늘어집니다. 십중팔구 안 됩니다. 되는게 더 이상한 법이에요.헛된 꿈을 꾸었다기간이 두 배가 되는 이유는 딱 하나입니다.  우리에겐 그 분야의 전문성이 없기 때문입니다. 물론 그런 일을 한 경험이 있는 사람들은 좀 더 낫습니다. 하지만 이 사람이 파편적인 경험(혹은 기억)만 가진 경우에는 똑같습니다. 별 차이가 안 나요.-_-;일단 제품의 개발 범위 결정이 안 됩니다. 이게 가장 크리티컬한 이유입니다. 처음에는 앞단에 보이는 것만 생각하고 시작하면서 역기획으로 풀어냅니다. 하지만 기획 단계에서 고려해야 할 요소들은 점점 추가되고 이 중에서 뭘 버리고, 뭘 해야 하는지 정확한 판단이 안 됩니다. 그럴 수 있는 데이터도 적고요.  거기에 디테일하게 개발하는 과정에서 고려해야 할 요소들이 빠지는 경우도 비일비재 합니다. 추가로 각종 정책 결정 이슈도 존재합니다. 이런저런 일들이 계속 추가되고, 해보지 않은 일을 하면서 업무 효율도 떨어집니다. 그러면서 기간은 계속 늘어납니다.결국 사람은 지치고, 일은 계속 늘고, 시간을 쓰게 됩니다. 그리고 그 과정에서 진짜로 에너지를 써야 할 일에 집중을 못 하게 됩니다.그냥 외부 서비스 쓰자!푸른밤의 PM으로서 저 스스로 가지고 있는 원칙이 있습니다.(사실 이건 예전에 프라이베리 때도 지키려고 했던 노력입니다.)기회를 놓치지 않는다.팀의 시간을 헛되이 쓰지 않는다.사람들의 에너지가 낭비되게 하지 않는다.좋은 역량을 가진 사람들은 제품의 core feature에만 집중한다.기회, 시간, 사람, 돈 중에서 가장 가치 없는 것은 돈이다.위 5가지 원칙을 준수하고자 하면, 대부분의 경우 그냥 외부 서비스를 이용하게 됩니다. 예를 들어서 서버 쪽에서 약간 낭비되는 코드가 있더라도 어떤 순간에는 그냥 돈을 더 써서 서버를 늘리는 것을 선택합니다. 메일 서버를 직접 구축해서 각종 마케팅용 메일을 직접 하는 것도 좋지만 그냥 메일침프를 씁니다. 요근래 저와 대표가 함께 부산에 미팅을 다녀왔는데..이것도 비슷한 맥락입니다. 제품 내에 꽤 중요하지만 서비스의 Major급 feature라고 하긴 좀 애매한 기능을 붙여야 하는 상황이었습니다. 개발팀에서는 1개월 정도면 될 것 같다고 했지만 그것보다는 전문적으로 이 일만 하는 곳의 제품을 이용하는 것이 좋다고 판단해서 부산에서 관련 사업을 하는 팀을 찾아갔습니다.“어설프게 우리가 하는 것보다, 인생을 건 사람들의 제품을 쓰는 것이 훨씬 좋다.”는 생각을 가지고 있습니다. 특히 제가 관리하는 제품들도 이런 생각을 가진 사람들이 돈을 쓰기 때문에 운영될 수 있는 제품이라서 다른 사람들보다 거부감이 낮을 수도 있습니다.외부 서비스 선택의 기준추가로 외부 서비스를 선택할 때는 이런 기준을 가지고 판단합니다.우리가 원하는 것이 어느 수준 정도로 충족되는가: 이게 제일 중요합니다. 원하는 것이 안 채워지는데도 돈을 쓸 필요는 없습니다.ㅠ어느 정도 커스텀이 가능하고, API가 제공 범위는 어떻게 되는가: 기존 시스템과 붙이기 얼마나 편하고, 우리 개발팀이 에너지를 어느 정도로 써야 하는지를 판단하기 위해 필요합니다. 덕분에 요즘은 API 문서 읽는 것이 일입니다.-_-;;(마케터, 운영팀 등이 쓰는 경우)개발자/디자이너가 꼭 붙지 않아도 사용할 수 있는가: 전 푸른밤의 모든 사람들이 코딩을 기초적인 수준으로는 했으면 합니다만 (진짜 잘하면 SQL까지도.) 그렇지 못 한 경우가 더 많고 그 과정에 역시 에너지/기회/시간 낭비가 좀 있다고도 생각합니다. 그래서 위 조건도 꽤 중요하게 봅니다.우리가 지금 쓰고 있는 다른 외부 서비스들과 연동이 어느 정도 되는가? 직접 연동이 안 되더라도 다른 방식으로 연동할 수 있는가: 가장 중요합니다. 세상 제일 중요합니다. 저희 같이 외부 서비스 연동을 하나씩 하나씩 하다보면 어느 순간부터 매월 SaaS 툴에만 $1000 넘게 쓰게 됩니다.(정말이에요.) 일단 가장 중요한 데이터 분석 툴과 연동되는지를 봅니다. 그리고 각 부분에서 core한 툴과 연결되는지 봅니다. 예를 들어서 마케팅 오토메이션 단계에서는 유입 관련 데이터 분석 툴과 연결되는 것이 핵심입니다. 제품 관련해서 외부 서비스 쓸 때도 메인 분석툴인 GA와 어떻게 붙는지가 핵심입니다.유기적인 연결이런 복잡한 기준을 잡으면서 외부 서비스 선택을 합니다.우리가 새로 만들자.하지만 이런 힘든 과정 거쳐서 외부 서비스 선택해서 잘 사용하다가 다시 직접 개발하게 될 때도 있습니다. 커스텀의 한계가 오거나, 외부 서비스 회사가 망하거나(ㅠㅠ), 서비스의 오픈 API 범위나 정책이 바뀌거나, 의외로 이 feature의 중요도가 크거나 하면 이런 의사결정을 할 수 있지 않을까 싶습니다. 하지만 아직 제가 이런 경험을 한 적은 없어서..향후에 이런 일이 발생하면 꼭 공유하겠습니다.정리하며스타트업에서 가장 부족한 것이 뭐냐는 질문을 하면 대체로 돈과 사람이라고 답할 것 같은데요. 여기에 기회, 시간이라는 것도 변수로 추가하길 권합니다. 그러면 어떤 경우에도 내 사업의 core가 되는 일들, 내 사업의 core랑 직결되는 제품 관련 과업들, 디자인/개발 관련 과업들만 생각하게 되고 여기에만 집중하게 됩니다.물론 돈이 부족한 것도 알고 있습니다만..정말 인생을 걸고 하는 사업에서 가장 아쉬운 것은 기회와 시간이라고 생각해서 외부 서비스 주구장창 이용하는 PM 안창영이었습니다.푸른밤 안창영#푸른밤 #알밤 #개발 #운영 #개발자 #PM #업무프로세스 #인사이트 #일지 #경험공유
조회수 2561

스타트업이 CTO를 찾는 법?

스타트업이 CTO를 찾는 법? 을 알고 계신 분에게 드리는 "질문"입니다. 이 글을 읽으시는 분들에게 부탁드리고 싶은 것은.. 1. 어디에 만나볼 엔지니어(개발자) 분들이 있으니 거기에 포스팅을 해보세요2. 엔지니어 들은 job을 찾을 때, 이런저런 고민을 하니.. 이런 포인트에서 조금 더 고민해보세요. 3. job 포스팅에는 이런저런 구체적인 내용들이 더 필요하니, 구체적으로 XX를 더 작성해보세요4. 이분 한번 만나보시겠어요? (소개 등등) 5. 공유를 해주셔도 좋습니다... 이런 고민을 함께 하시는 분들을 위해~등등의 조언을 댓글로 주셔도 좋고, 메일로 주셔도 좋고.. 아무튼 이 글은 조언을 구하고자 쓰는 글입니다. ^^;개발을 잘 모르는 스타트업 대표가 CTO를 모시는 방법은 어떤 것이 있을까요? ㅜㅜ대부분의 경우 co-founder 중, 엔지니어(engineer) 분이 CTO의 역할을 담당해주시는 것이 일반적인 경우로 보입니다. 하지만 서비스에서 engineer의 비중이 상대적으로 낮은 스타트업의 경우는 회사가 성장해 나감에 따라 function을 더 크게 만들어 나가는 경우도 있겠지요? 파펨도 그러한 회사 중에 하나입니다.지금까지는 할 수 있는 한 효율성을 따져가면서 최소한의 개발을 진행해왔지만, 이제는 조금 더 적극적으로 서비스를 고도화시켜야 할 때! 이기에 이제 좋은 분을 내부에 모셔야 하는데.. 우선 대표 입장에서의 고민을 한번 늘어놔 본다면.. 1) 개발을 거의 모르기 때문에 (새로 모셔야 할) 그분이 실력자 인지 아닌지 알 수가 없다는 불안감2) Ruby on Rails로 개발이 되어 있어, 이 언어에 능한 분을 찾는다는 것이 어렵다는 소문을 이미 많이 들음3) 엔지니어 분들이 선호하는 job 에 대한 구체적인 정보가 없음  반대로 job을 찾고 있는 엔지니어 분의 입장에서 상상력을 발휘해 본다면.. A) 잘 될 회사인지 아닌지 정확히 모르겠음 : 투자 몇 번 받은 것으로 스타트업 평가가 가능?B) 개발팀이 구성되어 있지 않아.. 당분간 나 혼자 full stack으로 일해야 함 : 내가 하나하나 다해야 함? C) 개발이 중심이지 않은 회사에서 일을 하는 게 적합할지? : 나의 커리어 차원에서 도움이 되는가? 위의 내용을 고려한다면, 100년 만의 개기일식이 일어나는 것과 같은 우연이 없다면 정말 만나기 어려운 인연이 아닐까?라는 생각이 듭니다. ㅜㅜ 그래도 어쩌겠습니까... 그런 인연을 찾아 나서야죠. 예전에는 엔지니어 한 분을 만나면, 리쿠르팅과 관계없이 다른 한 분을 소개 요청드리고, 또 그분에게서 다른 분을 소개받아서 계속해서 아는 분들의 영역을 넓혀가고자 노력도 해보았습니다. 그렇다면 파펨 대표가 생각하는 CTO는 어떤 분일까요? 현재의 파펨 구성원들과 아래의 일들을 함께 해나가 주실 분입니다. 1. 자체 커머스로써의 서비스 업그레이드 : 전체 팀과 함께 논의할 일 2. 알고리즘의 upagrade 반영 : 알고리즘 설계자(대표)와 함께 할 일3. 파펨 DB에서 추출할 수 있는 data를 바탕으로 마케팅 insight 발굴 : marketer와 함께 할 일4. 새로운 tool(예, GA보다 amplitude를 한번 사용해보자 등)을 소개하고 도입 이렇게 쓰면 컴퓨터 공학을 전공한 사람에게 저렇게 많은 것을 요청하는 당신은 경영학과 출신이니.. 재무, 회계, HR, 생산관리 모두 잘할 수 있는 사람인가요?라는 질문을 받을 것 같은 느낌이 들지만... ㅜㅜ 아무튼 어려운 리쿠르팅의 길을 떠나기 전에 머릿속에 생각나는 것들을 한번 써보았습니다.파펨에서 engineer를 찾습니다!! 파펨은? a. Ruby on Rails / AWS에서 서비스되고 있고, 나름 github에 히스토리 정리가 잘 되어 있고, 이전에 프리랜서로 개발에 도움을 주신 분이 체계적으로 정리해주셔서 나중에 열어보시면 뜨악하실 정도는 아닙니다. (라고 합니다. ^^;) b. 구체적인 연봉, job title 등은 상황별로 합리적인 논의를 할 준비가 되어 있습니다. C. 퓨쳐플레이와 아모레퍼시픽에서 투자를 유치하였습니다. #파펨 #스타트업 #창업가 #창업자 #마인드셋 #인사이트 #채용 #CTO #팀빌딩 #팀원

기업문화 엿볼 때, 더팀스

로그인

/