비트윈 팀은 지난달 비트윈에 Android Wear 앱 기능을 릴리즈했습니다. 즐거운 개발 경험이었지만, 힘들었던 점도 많았습니다. 어떤 과정을 통해서 개발하게 되었고, 내부 구조는 어떻게 되어 있는지, 신경 쓰거나 조심해야 할 점은 어떤 것들이 있는지 저희의 경험을 공유해보려고 합니다. 이 글을 통해 Android Wear 앱 제작을 고민하는 개발자나 팀이 더 나은 선택을 하는 데 도움이 되고자 합니다.Android Wear에 대해¶Android Wear는 최근 발표된 구글의 새 웨어러블 플랫폼입니다. 공개된 지 얼마 되지 않았음에도 불구하고 완성도 있는 디바이스들이 출시된 상태이며, 기존의 웨어러블 기기보다 기능과 가격이 매력 있다는 평가를 받고 있습니다. 또한, 2014 Google I/O에서 크게 소개되고 시계를 참가자들에게 나눠주는 등, 구글에서 강하게 밀어주고 있기 때문에 상당히 기대되는 플랫폼입니다.Android Wear의 알림 기능은 연결된 mobile1 기기와 연동됩니다. 예를 들어 메시지를 받았을 때 mobile과 wear에서 모두 알림을 받아볼 수 있고, Google Now와 연동하여 교통, 날씨 등 상황에 맞는 알림을 제공합니다.또, 여러 가지 앱들의 다양한 기능을 음성으로 제어하도록 하여 사용자에게 기존의 시계와는 완전히 다른 경험을 주고 있습니다.한국에서는 Google Play Store의 기기 섹션에서 구매가 가능합니다.Android Wear 개발하기¶Android Wear는 Android 플랫폼을 거의 그대로 사용하기 때문에, Android 개발 경험이 있는 개발자라면 아주 쉽게 개발을 시작할 수 있습니다. 비트윈에서는 구글의 80:20 프로젝트를 패러디한 100+20 프로젝트를 통해 개발을 진행하게 되었습니다. (하던 일을 다 해내면서 시간을 내어 진행한다는 의미로 100+20 프로젝트입니다. 하지만 가끔은 '20' 부분에 너무 몰입하여 0+20이 되기도 한다는 게 함정입니다...)Activity, Service 등 Android의 기본 component들을 모두 그대로 사용 가능하며, 손목에 찰 수 있는 크기의 화면에서 유용하게 사용할 수 있는 WearableListView, GridViewPager 같은 새 widget들이 추가되었습니다. 구글 개발자 사이트의 wearable training 섹션에서 자세한 안내를 볼 수 있습니다.비트윈의 아이디어¶비트윈 Android Wear 기능의 컨셉은, 항상 몸에 착용하는 Wear의 특징을 살려, '커플이 떨어져 있더라도, 항상 함께 있는 느낌을 주기' 였습니다. 그래서 아래와 같은 기능들이 기획되었습니다.Feel His/Her Heart (그대의 심장박동 느끼기): 상대방의 심장박동을 진동으로 재현해주기Where He/She Is (그/그녀는 어느 방향에 있을까?): 상대방의 위치를 나침반과 같은 형태로 보여주기 (안심하세요. 여러분. 방향만 알려주고 정확한 위치는 알려주지 않습니다!)Feel Memories (메모리박스): 언제든 추억을 떠올릴 수 있도록 비트윈의 기존 기능인 메모리박스(추억상자)를 Android Wear에서 구현하지만 이 아이디어들은 하루 만에 망하게 됩니다.메인 아이디어였던 심장박동 느끼기는 사용자가 요청하면 상대방의 시계에서 심장박동이 측정되어 사용자에게 상대방의 심장박동을 진동으로 재현해주는 멋진 기능이었습니다. 하지만 이 아이디어를 낼 때 심박센서가 탑재된 Android Wear 기기가 없었던 게 함정이었습니다.다음날 Android Wear Bootcamp에 참가하여 심박센서가 작동하는 삼성 Gear Live 기기를 사용해 볼 수 있었습니다. 결과는 충격이었습니다. 생각과는 달리 심박박동 측정 결과가 나오는데 10~20초가 걸리고, 그나마도 측정되는 동안은 올바른 위치에 시계를 차고 가만히 있어야 했습니다. 결국, 이러한 제약 때문에 사용자들이 실제로 유용하게 사용할 수 있는 기능이 될 수 없었습니다.그래서 계획을 수정하여 현실적으로 구현 가능한 기능들을 먼저 만들어 보기로 했습니다.목소리로 답변하기: 상대방에게 온 메시지에 Android Wear Framework에서 제공하는 음성인식을 이용하여 목소리를 텍스트로 바꾸어서 답장하기이모티콘 답변하기: 이모티콘을 사용자가 선택하여 이모티콘으로 답장하기비트윈 메모리박스: 비트윈의 기존 기능인 메모리박스(추억상자)를 Android Wear에서 구현처음의 원대한 계획에서 뭔가 많이 변경된 것 같지만, 기분 탓일 겁니다.내부 구현¶비트윈 Android Wear 앱은 크게 두 가지 기능을 가지고 있습니다. 하나는 상대방에게 메시지를 받았을 때, 메시지 내용을 확인하고 여러 가지 형태로 답장할 수 있는 Notification 기능이고, 다른 하나는 Wear에서 원래 Application의 일부 기능을 시작 메뉴를 통하거나 목소리로 실행시킬 수 있게 해주는 Micro App입니다. 해당 기능들의 스크린샷과 함께 내부 구조를 설명하겠습니다.우선 Notification 부분입니다. 앱 개발사에서 아무 작업도 하지 않더라도, 기본적으로 Android Wear Framework이 스크린샷 윗줄 첫 번째, 네 번째 화면과 같이 예쁜 알림화면과 Open on phone 버튼을 만들어 줍니다. 여기에 추가적인 기능을 붙이기 위하여 WearableExtender를 이용하여 목소리로 답장하기, 이모티콘 보내기 버튼을 덧붙였습니다.비트윈 Android Wear 스크린샷 - Notification둘째로는 Micro App 부분입니다. 여기에는 이모티콘 전송과 메모리박스를 넣었습니다. 이 부분은 일반적인 Android 앱을 만들듯이 작업할 수 있습니다비트윈 Android Wear 스크린샷 - Micro App화면을 보면 무척 단순해 보이지만 내부 구조는 간단하지가 않습니다. 연결된 화면들을 만들어내는 코드가 한곳에 모여있지 않고, 각기 다른 곳에 있는 코드들을 연결하여야 하기 때문입니다. Notification 하나를 만들 때에 Framework에서 만들어주는 1, 4번째 화면, Notification에 WearableExtender를 이용하여 덧붙이는 2, 3번째 화면, 그리고 다시 Framework에서 만들어주는 목소리로 답장하기 화면, 그리고 Wear 쪽의 Micro App을 통해 구동되는 이모티콘 선택 화면과 같이 여러 군데에 나누어 존재하는 코드가 연결됩니다.하나의 앱처럼 느껴지는 화면이지만 각각 다른 곳에 코드가 쓰여있습니다.그러면 이번에는 각 화면이 어떻게 연결되는지 알아보겠습니다.사용자가 상대방으로부터 받은 메시지를 Android Wear의 Notification으로 확인하고, 답장으로 이모티콘을 보내고자 하는 상황을 가정해 봅시다. 사용자가 Send Emoticon 버튼을 눌렀을 때 이모티콘 선택화면을 보여주고 싶은데, 이 행동에 대한 pending intent를 wear 쪽의 micro app이 아닌, mobile 쪽에서 받게 되어 있습니다. 이 때문에 아래의 표와 같이 mobile 쪽에서 pending intent를 받은 뒤 다시 wear 쪽으로 이모티콘 선택 화면을 보여주라는 메시지를 전송해줘야 합니다.이모티콘 전송 과정이번에는 메모리박스를 보겠습니다. 메모리박스도 단순한 화면이지만 mobile 쪽과 통신하여 내용을 불러와야 하므로 생각보다 해야 하는 일이 많습니다. Android Wear Message API와 Data API를 이용하여 데이터를 주고받아 사진을 화면에 보여줍니다.메모리박스를 보여주는 과정개발 시 신경 써야 하는 점¶개발하면서 주의 깊게 신경 써야 하는 점들이 있습니다.첫 번째로 코드 퀄리티입니다.Android Wear는 아직 성숙하지 않은 플랫폼이기 때문에 많은 사람이 받아들인 정형화된 패턴이 없습니다. 앞서 살펴보았듯이, 간단한 기능을 구현하려고 해도 상당히 복잡한 구조를 가진 앱을 만들게 되기에, 코드 퀄리티를 높게 유지하기 어려웠습니다비트윈 팀에서는 EventBus를 활용하여 코드를 깔끔하게 유지하려고 노력하였습니다. 이러한 문제를 해결할 수 있는 Guava의 Concurrent 패키지나, RxJava 등의 도구들이 있으니 익숙한 도구를 선택하여 진행하는 것을 추천합니다. 또한, 구글의 Android Wear 코드랩 튜토리얼의 내용이 매우 좋으니, 한번 처음부터 수행해 보면 좋은 코드를 만들 수 있는 아이디어가 많이 나올 것입니다.두 번째로는 원형 디바이스 지원 및 에러 처리입니다.처음부터 원형 디바이스를 신경 쓰지 않으면 마무리 작업 시 상당한 고통을 받게 됩니다. 원형 디바이스에 대한 대응법은 Android 개발자 트레이닝 사이트의 wearable layout 섹션에 자세히 나와 있습니다. 현재는 원형 디바이스를 처리하는 프레임웍에 약간 버그가 있지만, 곧 수정될 것으로 생각합니다.사용자 입력이 있을 때, 그리고 에러가 났을 때 적절하게 처리해주는 것은 제품의 완성도에 있어 중요한 부분입니다. Android Wear Framework에서 제공하는 ConfirmationActivity등을 활용하여 처리하면 됩니다.마지막으로 패키징입니다.자동 설치 패키징은 비트윈 팀에서도 가장 고생했던 부분입니다. Android Wear는 본체 앱을 설치하면 자동으로 함께 설치되는데, 앱이 정상작동하기 위해서는 몇 가지 까다로운 조건이 있습니다.build.gradle 의 applicationId 를 wear와 mobile 양쪽 모두 똑같이 맞춰야 합니다.Wear app의 AndroidManifest에 새롭게 선언한 permission이 있다면 mobile 쪽에도 포함해 주어야 합니다.기본적으로, 똑같은 key로 서명합니다. 다른 key로 sign 하는 경우는 문서를 참고해서 신경 써서 합니다.위 항목들은 아주 중요한 내용이지만 아직 문서화가 완벽하지 않으니 주의 깊게 진행해야 합니다.후기¶개발 과정에서 여러 가지 어려움이 있었지만, 무척 즐거웠던 프로젝트였습니다!우선 새로운 플랫폼에서 새로운 제품의 아이디어를 내고 만들어내는 과정이 많은 영감과 즐거움을 주었습니다.두 번째로는 Android Wear를 포함한 버전 출시 이후 구글플레이의 Android Wear 섹션 및 추천 앱 섹션에 올라가게 되어 홍보 효과도 얻을 수 있었습니다. 또한, 구글의 신기술을 적극적으로 사용하고자 하는 팀에게는 구글 쪽에서도 많은 지원을 해주기 때문에 도움도 많이 받았습니다.세 번째로는 기존의 Android 개발과 비슷하여 접근하기 쉬우면서도, 원하는 것을 구현하려면 상당히 도전적이어서 재미있었습니다.다만 조심해야 할 점은, 구글에서 적극적으로 밀고 있는 프로젝트라고 해서 다 성공하는 것은 아니라는 점입니다. 얼마만큼의 시간과 자원을 투자할지는 신중하게 생각하면 좋겠습니다.정리¶Android Wear는 새로운 기술과 플랫폼에 관심이 많은 개발자, 혹은 팀이라면 시간을 투자해서 해볼 만한 재미있는 프로젝트입니다. 하지만 완성도 있는 좋은 제품을 만들기 위해서는 생각보다 할 일이 많으니 이를 신중하게 고려하여 결정해야 합니다.구글의 튜토리얼 등에서 지칭하는 것과 마찬가지로, 이 글에서도 Android Wear와 연결된 휴대폰을 mobile이라 하겠습니다.↩저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 jobs@vcnc.co.kr로 이메일을 주시기 바랍니다!

Overview새로운 사용환경 구축에 도전하는 건 개발자의 운명과도 같습니다. 오늘은 여러 장점을 가지고 있는 Vue (프론트엔드 자바스크립트 프레임워크)를 도전해보겠습니다. Vue는 다른 프레임워크에 비해 가볍고, 개발하기에 편합니다. 그럼 우선 Vue를 설치합시다! Vue 설치CDNhttps://unpkg.com/vue 주소를 script 태그에 직접 추가 Vue.js 파일다운개발용, 배포용 버전을 다운 받아 script 태그에 추가개발용 버전은 개발에 도움이 되는 모든 경고를 출력하기 때문에 개발 중에만 사용하고, 실제 서비스에서는 배포용 버전으로 사용해야 한다. NPM 설치규모가 큰 프로젝트 경우 컴포넌트별 독립적으로 관리할 수 있는 싱글 파일 컴포넌트 방식 추천 Vue를 설치하는 방법은 여러 가지가 있습니다. 각자 특성에 맞게 편리한 방법으로 설치해주세요. 이번 글에서는 싱글 파일 컴포넌트 방식을 사용할 것이므로 NPM vue-cli 를 설치해 프로젝트를 구성하겠습니다. # vue-cli 전역 설치, 권한에러시 sudo 추가 $ npm install vue-cli -global vue-clivue-cli를 사용하면 뷰 애플리케이션을 개발하기 위한 초기 프로젝트 구조를 쉽게 구성할 수 있습니다. 다만, 싱글 파일 컴포넌트 체계를 사용하려면 .vue 파일을 웹 브라우저가 인식할 수 있는 형태의 파일로 변환해 주는 웹팩(Webpack)이나 브라우저리파이(Browserify)와 같은 도구가 필요합니다. vue-cli 설치 명령어 vue init webpack : 고급 웹팩 기능을 활용한 프로젝트 구성 방식. 테스팅，문법 검사 등을 지원vue init webpack-simple : 웹팩 최소 기능을 활용한 프로젝트 구성 방식. 빠른 화면 프로토타이핑용vue init browserify : 고급 브라우저리파이 기능을 활용한 프로젝트 구성 방식. 테스팅，문법 검사 등을 지원vue init browserify-simple : 브라우저리파이 최소 기능을 활용한 프로젝트 구성 방식. 빠른 화면 프로토타이핑용vue init simple : 최소 뷰 기능만 들어간 HTML 파일 1개 생성vue init pwa : 웹팩 기반의 프로그레시브 웹 앱(PWA, Progressive Web App) 기능을 지원하는 뷰 프로젝트여러 설치 명령어 중에 특성에 맞는 초기 프로젝트를 생성하세요. 1) vue init webpack 실행# 해당 프로젝트 폴더에서 실행 $ vue init webpack   # 현재 디렉토리에서 프로젝트 생성 여부 ? Generate project in current directory? (Y/n) # 프로젝트 이름 ? Project name (vue_ex) # 프로젝트 설명 ? Project description (A Vue.js project) # 프로젝트 작성자 ? Author (곽정섭 ) # 빌드 방식 ? Vue build (Use arrow keys) # vue-router를 설치 여부 ? Install vue-router? (Y/n) # 코드를 보완하기 위해 ESLint를 사용 여부 ? Use ESLint to lint your code? (Y/n) # ESLint 사전 설정 선택 ? Pick an ESLint preset (Use arrow keys) # 단위 테스트 섧정 ? Set up unit tests (Y/n) # 테스트 러너 선택 ? Pick a test runner (Use arrow keys) # Nightwatch로 e2e 테스트를 설정 여부 ? Setup e2e tests with Nightwatch? (Y/n) # 프로젝트가 생성 된 후에`npm install`을 실행해야합니까? ? Should we run `npm install` for you after the project has been created? (recommended) (Use arrow keys) 2) 고급 웹팩 기능을 활용한 프로젝트 구성 방식으로 설치3) 설치완료4) package.json 파일에 설정된 라이브러리 설치$ npm install 5) 개발모드 실행# 해당 프로젝트 폴더에서 실행(소스수정시 자동 새로고침) $ npm run dev 6) http://localhost:8080/ 브라우저 실행7) Yeah, You got it!!!!추가 도구: Vue Devtools(크롬 확장 플러그인)Vue Devtools(크롬 확장 플러그인)은 Vue를 사용할 때, 브라우저에서 사용자 친화적으로 검사하고 디버그할 수 있습니다.크롬 개발자 도구에 Vue 탭이 추가됨ConclusionVue를 설치하는 여러 방법 중 고급 웹팩 기능을 활용한 프로젝트 구성을 알아봤습니다. 다음 글에서는 Vue 인스턴스 및 디렉티브(지시문) 사용법을 다뤄보겠습니다.참고설치방법 — Vue.js 글곽정섭 과장 | R&D 개발1팀kwakjs@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유 #Vue

Angular는 비동기식 라우팅이 가능합니다. 나중에 사용할 기능들을 NgModule로 분리하여 사용자의 요청이 들어왔을 때 모듈을 불러와 기능을 사용할 수 있고, 이러한 기술을 지연 로딩이라 합니다.프로젝트가 진행되고 기능이 추가될수록 어플리케이션 번들 크기가 커지고, 결국엔 초기 로딩 시간도 길어지게 됩니다. 지연 로딩을 사용하면 초기 로딩 시간을 줄일 수 있습니다. 컴파일 단계에서 나중에 사용할 모듈들을 메인 모듈에서 분리하여 번들을 생성합니다. 그리고 사용자가 기능을 요청할 때 비동기로 스크립트를 불러와 실행합니다. 지연 로딩에 대한 소개와 사용법은 Angular 공식 문서의 Routing & Navigation — Milestom 6: Asynchronous routing 을 참고하시길 바랍니다하지만 지연 로딩을 사용할 때 유의해야할 점이 몇 가지 있습니다.지연 로딩 모듈과 인젝터(Injector)지연 로딩이 완료되었을 때 Angular는 지연 로딩된 모듈을 루트 인젝터(Root Injector)의 자식이 되는 자식 인젝터를 이용하여 초기화하고, 서비스들을 자식 인젝터에 추가합니다. 즉, 인젝터가 분리되기에 지연 로딩된 모듈의 클래스들은 자식 인젝터로의 서비스 주입이 가능하지만 루트 인젝터로 만들어진 클래스들은 불가능합니다.이는 Angular의 독특한 의존성 주입 시스템 때문입니다. Angular의 인젝터는 처음 애플리케이션이 시작되었을 때, 컴포넌트나 다른 서비스에 주입되기 전에 포함된 모든 모듈들의 서비스 제공자들을 블러와 루트 인젝터를 생성합니다. 애플리케이션이 시작되고 나면 인젝터는 서비스들을 생성하고 주입을 시작하고, 새로운 서비스들을 제공자로 추가가 불가능합니다.그러므로 지연 로딩된 서비스들은 이미 생성이 완료된 루트 인젝터로 추가가 불가능합니다. 따라서 Angular는 지연 로딩된 모듈에 대해서 새로운 자식 인젝터를 만들는 전략을 취하게 된 것입니다.자식 인젝터가 새로 만들어지기 때문에 공통된 모듈을 사용할 때 주의하여야 합니다. 예를 들어 다음과 같이 SharedModule 에 CounterService 를 서비스로 추가하고 루트 모듈인 AppModule 과 지연 로딩 모듈인 LazyModule 에 각각 SharedModule 을 import 하였습니다.import { BrowserModule } from '@angular/platform-browser'; import { NgModule } from '@angular/core'; import { RouterModule } from '@angular/router'; import { SharedModule } from './shared/shared.module'; import { AppShellComponent } from './app-shell.component'; const APP_ROUTES = [ { path: 'lazy', loadChildren: 'app/lazy/lazy.module#LazyModule' } ]; @NgModule({ imports: [ BrowserModule, SharedModule, RouterModule.forRoot(APP_ROUTES) ], declarations: [ AppShellComponent ], bootstrap: [AppShellComponent] }) export class AppModule { }import { Injectable } from '@angular/core'; @Injectable() export class CounterService { count = 0; increase(): void { this.count++; } decrease(): void { this.count--; } }import { NgModule } from '@angular/core'; import { RouterModule } from '@angular/router'; import { SharedModule } from '../shared/shared.module'; import { SomeLazyComponent } from './some-lazy.component'; const LAZY_ROUTES = [ { path: '', component: SomeLazyComponent } ]; @NgModule({ imports: [ SharedModule, RouterModule.forChild(LAZY_ROUTES) ] }) export class LazyModule { }import { NgModule } from '@angular/core'; @NgModule({ providers: [ CounterService ] }) export class SharedModule { }그리고 루트 모듈의 컴포넌트와 지연 로딩 모듈의 컴포넌트에서 각각 CounterService 를 사용하여 숫자 값을 바꿔봅니다.서로 다른 인젝터에 CounterService 인스턴스가 만들어졌기 때문에 두 컴포넌트에 표시되는 숫자값은 다릅니다. 앞에서 말했듯이 지연 로딩 모듈은 루트 인젝터가 아닌 자식 인젝터를 이용하여 초기화하기 때문입니다.만약, 지연 로딩 모듈에서 제공되는 서비스를 다른 모듈에서 사용하려면 루트 모듈에 포함시켜 줘야 합니다. 다음과 같이 루트 모듈에게만 노출시킬 서비스 제공자들을 따로 빼내어 줄 수 있습니다.import { NgModule } from '@angular/core'; import { RouterModule, Routes } from '@angular/router'; import { AccountLoginPageComponent } from './login-page.component'; const ACCOUNT_ROUTES: Routes = [ { path: 'login', component: AccountLoginPageComponent } ]; @NgModule({ imports: [ ... RouterModule.forChild(ACCOUNT_ROUTES) ], decalartions: [ AccountLoginPageComponent ] }) export class AccountLazyModule { }import { ModuleWithProviders, NgModule } from '@angular/core'; import { AccountAuthService } from './auth.service'; @NgModule({ imports: [...] }) export class AccountModule { static forRoot(): ModuleWithProviders { return { ngModule: AccountModule, providers: [ AccountAuthService ] }; } }AccountModule.forRoot() 를 루트 모듈에 import하면 다른 모듈에서도 AccountAuthService 를 사용할 수 있게 됩니다. 물론 이 경우 AccountModule를 지연로딩 모듈로 만들면 루트 모듈에 포함되기 때문에 번들을 나누는 의미가 없어질 수 있으니 AccountLazyModule 을 따로 두어 코드를 분리하였습니다.#타운컴퍼니 #개발 #개발자 #인사이트 #꿀팁

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

비트윈 팀은 비트윈 안드로이드 클라이언트(이하 안드로이드 클라이언트)를 가볍고 반응성 좋은 애플리케이션으로 만들기 위해 노력하고 있습니다. 이 글에서는 간결하고 유지보수하기 쉬운 코드를 작성하기 위해 Reflection을 사용했었고 그로 인해 성능 이슈가 발생했던 것을 소개합니다. 또한 그 과정에서 발생한 Reflection 성능저하를 해결하기 위해 시도했던 여러 방법을 공유하도록 하겠습니다.다양한 형태의 데이터¶Java를 이용해 서비스를 개발하는 경우 POJO로 서비스에 필요한 다양한 모델 클래스들을 만들어 사용하곤 합니다. 안드로이드 클라이언트 역시 모델을 클래스 정의해 사용하고 있습니다. 하지만 서비스 내에서 데이터는 정의된 클래스 이외에도 다양한 형태로 존재합니다. 안드로이드 클라이언트에서 하나의 데이터는 아래와 같은 형태로 존재합니다.JSON: 비트윈 서비스에서 HTTP API는 JSON 형태로 요청과 응답을 주고 받고 있습니다.Thrift: TCP를 이용한 채팅 API는 Thrift를 이용하여 프로토콜을 정의해 서버와 통신을 합니다.ContentValues: 안드로이드에서는 Database 에 데이터를 저장할 때, 해당 정보는 ContentValues 형태로 변환돼야 합니다.Cursor: Database에 저장된 정보는 Cursor 형태로 접근가능 합니다.POJO: 변수와 Getter/Setter로 구성된 클래스 입니다. 비지니스 로직에서 사용됩니다.코드 전반에서 다양한 형태의 데이터가 주는 혼란을 줄이기 위해 항상 POJO로 변환한 뒤 코드를 작성하기로 했습니다.다양한 데이터를 어떻게 상호 변환할 것 인가?¶JSON 같은 경우는 Parsing 후 Object로 변환해 주는 라이브러리(Gson, Jackson JSON)가 존재하지만 다른 형태(Thrift, Cursor..)들은 만족스러운 라이브러리가 존재하지 않았습니다. 그렇다고 모든 형태에 대해 변환하는 코드를 직접 작성하면 필요한 경우 아래와 같은 코드를 매번 작성해줘야 합니다. 이와 같이 작성하는 경우 Cursor에서 원하는 데이터를 일일이 가져와야 합니다.@Overridepublic void bindView(View view, Context context, Cursor cursor) { final ViewHolder holder = getViewHolder(view); final String author = cursor.getString("author"); final String content = cursor.getString("content"); final Long timeMills = cursor.getLong("time"); final ReadStatus readStatus = ReadStatus.fromValue(cursor.getString("readStatus")); final CAttachment attachment = JSONUtils.parseAttachment(cursor.getLong("createdTime")); holder.authorTextView.setText(author); holder.contentTextView.setText(content); holder.readStatusView.setReadStatus(readStatus); ...}하지만 각 형태의 필드명(Key)이 서로 같도록 맞춰주면 각각의 Getter와 Setter를 호출해 형태를 변환해주는 Utility Class를 제작할 수 있습니다.@Overridepublic void bindView(View view, Context context, Cursor cursor) { final ViewHolder holder = getViewHolder(view); Message message = ReflectionUtils.fromCursor(cursor, Message.class); holder.authorTextView.setText(message.getAuthor()); holder.contentTextView.setText(message.getContent()); holder.readStatusView.setReadStatus(message.getReadStatus()); ...}이런 식으로 코드를 작성하면 이해하기 쉽고, 모델이 변경되는 경우에도 유지보수가 비교적 편하다는 장점이 있습니다. 따라서 필요한 데이터를 POJO로 작성하고 다양한 형태의 데이터를 POJO로 변환하기로 했습니다. 서버로부터 받은 JSON 혹은 Thrift객체는 자동으로 POJO로 변환되고 POJO는 다시 ContentValues 형태로 DB에 저장됩니다. DB에 있는 데이터를 화면에 보여줄때는 Cursor로부터 데이터를 가져와서 POJO로 변환 후 적절한 가공을 하여 View에 보여주게 됩니다.POJO 형태로 여러 데이터 변환필요Reflection 사용과 성능저하¶처음에는 Reflection을 이용해 여러 데이터를 POJO로 만들거나 POJO를 다른 형태로 변환하도록 구현했습니다. 대상 Class의 newInstance/getMethod/invoke 함수를 이용해 객체 인스턴스를 생성하고 Getter/Setter를 호출하여 값을 세팅하거나 가져오도록 했습니다. 앞서 설명한 ReflectionUtils.fromCursor(cursor, Message.class)를 예를 들면 아래와 같습니다.public T fromCursor(Cursor cursor, Class clazz) { T instance = (T) clazz.newInstance(); for (int i=0; i final String columnName = cursor.getColumnName(i); final Class<?> type = clazz.getField(columnName).getType(); final Object value = getValueFromCursor(cursor, type); final Class<?>[] parameterType = { type }; final Object[] parameter = { value }; Method m = clazz.getMethod(toSetterName(columnName), parameterType); m.invoke(instance, value); } return instance;}Reflection을 이용하면 동적으로 Class의 정보(필드, 메서드)를 조회하고 호출할 수 있기 때문에 코드를 손쉽게 작성할 수 있습니다. 하지만 Reflection은 튜토리얼 문서에서 설명된 것처럼 성능저하 문제가 있습니다. 한두 번의 Relfection 호출로 인한 성능저하는 무시할 수 있다고 해도, 필드가 많거나 필드로 Collection을 가진 클래스의 경우에는 수십 번이 넘는 Reflection이 호출될 수 있습니다. 실제로 이 때문에 안드로이드 클라이언트에서 종종 반응성이 떨어지는 경우가 발생했습니다. 특히 CursorAdapter에서 Cursor를 POJO로 변환하는 코드 때문에 ListView에서의 스크롤이 버벅이기도 했습니다.Bytecode 생성¶Reflection 성능저하를 해결하려고 처음으로 선택한 방식은 Bytecode 생성입니다. Google Guice 등의 다양한 자바 프로젝트에서도 Bytecode를 생성하는 방식으로 성능 문제를 해결합니다. 다만 안드로이드의 Dalvik VM의 경우 일반적인 JVM의 Bytecode와는 스펙이 다릅니다. 이 때문에 기존의 자바 프로젝트에서 Bytecode 생성에 사용되는 CGLib 같은 라이브러리 대신 Dexmaker를 이용하여야 했습니다.CGLib¶CGLib는 Bytecode를 직접 생성하는 대신 FastClass, FastMethod 등 펀리한 클래스를 이용할 수 있습니다. FastClass나 FastMethod를 이용하면 내부적으로 알맞게 Bytecode를 만들거나 이미 생성된 Bytecode를 이용해 비교적 빠른 속도로 객체를 만들거나 함수를 호출 할 수 있습니다.public T create() { return (T) fastClazz.newInstance();} public Object get(Object target) { result = fastMethod.invoke(target, (Object[]) null);} public void set(Object target, Object value) { Object[] params = { value }; fastMethod.invoke(target, params);}Dexmaker¶하지만 Dexmaker는 Bytecode 생성 자체에 초점이 맞춰진 라이브러리라서 FastClass나 FastMethod 같은 편리한 클래스가 존재하지 않습니다. 결국, 다음과 같이 Bytecode 생성하는 코드를 직접 한땀 한땀 작성해야 합니다.public DexMethod generateClasses(Class<?> clazz, String clazzName){ dexMaker.declare(declaringType, ..., Modifier.PUBLIC, TypeId.OBJECT, ...); TypeId<?> targetClassTypeId = TypeId.get(clazz); MethodId invokeId = declaringType.getMethod(TypeId.OBJECT, "invoke", TypeId.OBJECT, TypeId.OBJECT); Code code = dexMaker.declare(invokeId, Modifier.PUBLIC); if (isGetter == true) { Local<Object> insertedInstance = code.getParameter(0, TypeId.OBJECT); Local instance = code.newLocal(targetClassTypeId); Local returnValue = code.newLocal(TypeId.get(method.getReturnType())); Local value = code.newLocal(TypeId.OBJECT); code.cast(instance, insertedInstance); MethodId executeId = ... code.invokeVirtual(executeId, returnValue, instance); code.cast(value, returnValue); code.returnValue(value); } else { ... } // constructor Code constructor = dexMaker.declare(declaringType.getConstructor(), Modifier.PUBLIC); Local<?> thisRef = constructor.getThis(declaringType); constructor.invokeDirect(TypeId.OBJECT.getConstructor(), null, thisRef); constructor.returnVoid();}Dexmaker를 이용한 방식을 구현하여 동작까지 확인했으나, 다음과 같은 이유로 실제 적용은 하지 못했습니다.Bytecode를 메모리에 저장하는 경우, 프로세스가 종료된 이후 실행 시 Bytecode를 다시 생성해 애플리케이션의 처음 실행성능이 떨어진다.Bytecode를 스토리지에 저장하는 경우, 원본 클래스가 변경됐는지를 매번 검사하거나 업데이트마다 해당 스토리지를 지워야 한다.더 좋은 방법이 생각났다.Annotation Processor¶최종적으로 저희가 선택한 방식은 컴파일 시점에 형태변환 코드를 자동으로 생성하는 것입니다. Reflection으로 접근하지 않아 속도도 빠르고, Java코드가 미리 작성돼 관리하기도 편하기 때문입니다. POJO 클래스에 알맞은 Annotation을 달아두고, APT를 이용해 Annotation이 달린 모델 클래스에 대해 형태변환 코드를 자동으로 생성했습니다.형태 변환이 필요한 클래스에 Annotation(@GenerateAccessor)을 표시합니다.@GenerateAccessorpublic class Message { private Integer id; private String content; public Integer getId() { return id; } ...}javac에서 APT 사용 옵션과 Processor를 지정합니다. 그러면 Annotation이 표시된 클래스에 대해 Processor의 작업이 수행됩니다. Processor에서 코드를 생성할 때에는 StringBuilder 등으로 실제 코드를 일일이 작성하는 것이 아니라 Velocity라는 template 라이브러리를 이용합니다. Processor는 아래와 같은 소스코드를 생성합니다.public class Message$$Accessor implements Accessor { public kr.co.vcnc.binding.performance.Message create() { return new kr.co.vcnc.binding.performance.Message(); } public Object get(Object target, String fieldName) throws IllegalArgumentException { kr.co.vcnc.binding.performance.Message source = (kr.co.vcnc.binding.performance.Message) target; switch(fieldName.hashCode()) { case 3355: { return source.getId(); } case -1724546052: { return source.getContent(); } ... default: throw new IllegalArgumentException(...); } } public void set(Object target, String fieldName, Object value) throws IllegalArgumentException { kr.co.vcnc.binding.performance.Message source = (kr.co.vcnc.binding.performance.Message) target; switch(fieldName.hashCode()) { case 3355: { source.setId( (java.lang.Integer) value); return; } case -1724546052: { source.setContent( (java.lang.String) value); return; } ... default: throw new IllegalArgumentException(...); } }}여기서 저희가 정의한 Accessor는 객체를 만들거나 특정 필드의 값을 가져오거나 세팅하는 인터페이스로, 객체의 형태를 변환할 때 이용됩니다. get,set 메서드는 필드 이름의 hashCode 값을 이용해 해당하는 getter,setter를 호출합니다. hashCode를 이용해 switch-case문을 사용한 이유는 Map을 이용하는 것보다 성능상 이득이 있기 때문입니다. 단순 메모리 접근이 Java에서 제공하는 HashMap과 같은 자료구조 사용보다 훨씬 빠릅니다. APT를 이용해 변환코드를 자동으로 생성하면 여러 장점이 있습니다.Reflection을 사용하지 않고 Method를 직접 수행해서 빠르다.Bytecode 생성과 달리 애플리케이션 처음 실행될 때 코드 생성이 필요 없고 만들어진 코드가 APK에 포함된다.Compile 시점에 코드가 생성돼서 Model 변화가 바로 반영된다.APT를 이용한 Code생성으로 Reflection 속도저하를 해결할 수 있습니다. 이 방식은 애플리케이션 반응성이 중요하고 상대적으로 Reflection 속도저하가 큰 안드로이드 라이브러리에서 최근 많이 사용하고 있습니다. (AndroidAnnotations, ButterKnife, Dagger)성능 비교¶다음은 Reflection, Dexmaker, Code Generating(APT)를 이용해 JSONObject를 Object로 변환하는 작업을 50번 수행한 결과입니다.성능 비교 결과이처럼 최신 OS 버전일수록 Reflection의 성능저하가 다른 방법에 비해 상대적으로 더 큽니다. 반대로 Dexmaker의 생성 속도는 빨라져 APT 방식과의 성능격차는 점점 작아집니다. 하지만 역시 APT를 통한 Code 생성이 모든 환경에서 가장 좋은 성능을 보입니다.마치며¶서비스 모델을 반복적으로 정의하지 않으면서 변환하는 방법을 알아봤습니다. 그 과정에서 Reflection 의 속도저하, Dexmaker 의 단점도 설명해 드렸고 결국 APT가 좋은 해결책이라고 판단했습니다. 저희는 이 글에서 설명해 드린 방식을 추상화해 Binding이라는 라이브러리를 만들어 사용하고 있습니다. Binding은 POJO를 다양한 JSON, Cursor, ContentValues등 다양한 형태로 변환해주는 라이브러리입니다. 뛰어난 확장성으로 다양한 형태의 데이터로 변경하는 플러그인을 만들어서 사용할 수 있습니다.Message message = Bindings.for(Message.class).bind().from(AndroidSources.cursor(cursor));Message message = Bindings.for(Message.class).bind().from(JSONSources.jsonString(jsonString));String jsonString = Bindings.for(Message.class).bind(message).to(JSONTargets.jsonString());위와 같이 Java상에 존재할 수 있는 다양한 타입의 객체에 대해 일종의 데이터 Binding 기능을 수행합니다. Binding 라이브러리도 기회가 되면 소개해드리겠습니다. 윗글에서 궁금하신 점이 있으시거나 잘못된 부분이 있으면 답글을 달아주시기 바랍니다. 감사합니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 jobs@vcnc.co.kr로 이메일을 주시기 바랍니다!

끊임없는 자기 계발과 성장 욕구는 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년 목표 공약이라서 가는 거잖아요. 회사가 진짜 할 수 있는 목표를 잡아서 노력하고 목표 달성을 했을 때 약속을 지키는 모습을 보면서 되게 멋지다는 생각을 했어요. 좋은 회사와 좋은 어른의 모습은 이런 건가 싶고, 이런 모습을 보면서 저도 더 성장해야겠다고 생각하는 것 같아요.      “레드와 함께 일하고 싶으시다면 지금 바로 오픈서베이 입사 지원을 해보세요”

코인원의 파이콘 한국 2018 참여기 그 두번째 이야기!코인원의 핵심, 코인원의 자랑 ‘코인원 개발자’들에 대한 이야기를 나눠보려 합니다.지금의 코인원이 있을 수 있는 이유는 바로 더 좋은 프로덕트를 만들어내기 위해 치열하게 고민하는 개발 크루들의 노력이 있었기 때문입니다.코인원은 지난 파이콘 한국 2018 ‘열린공간(Open Speak Talking)’ 세션에 참여했습니다. 이 시간을 통해 그동안 코인원 개발 크루들이 축적한 지식과 경험 그리고 노하우를 공유했어요. 파이콘이 개발자들을 위한 행사인만큼, 코인원의 개발문화와 환경, 채용 원칙에 대한 심도깊은 이야기가 오고갔답니다.그래서 예고했던대로 코인원 개발자들의 ‘Mini Interview’를 통해 개발 크루들은 기술본부를 어떻게 만들어나가고 있는지 자세히 알려드릴게요 :-)'파이콘 한국 2018' 후기 1탄 현장스케치▼코인원X'파이콘 한국 2018' 현장스케치!파이썬 개발자들의 즐거운 축제, ‘파이콘 한국 2018’이 지난 19일 성황리에 막을 내렸습니다. 이번 행사...blog.naver.com지난 8월 19일 진행된 파이콘 열린공간 현장, Open Speak Talking!진우님(CTO)을 집중 심문하고 있는 피플팀 수장 대경님코인원 기술본부는 어떻게 구성되어 있나요?진우님(CTO) : 안녕하세요, 코인원 CTO(Chief Technical Officer, 최고기술책임자) 이진우 입니다. 현재 코인원 기술본부는 총 8개의 팀으로 이루어져 있는데요. Core팀, Web팀, API팀, APP팀, QA팀, SRE팀, 데이터팀, 기술연구팀으로 나뉘어진답니다. 코인원 기술본부는 사용자에게 편리한 서비스를 제공하기 위해 프로덕트를 만들어나가고 있어요. 먼저, 사용자에게 직접적으로 보여지는 화면인 프론트엔드를 책임지는 ‘Web팀과 APP팀’ 그리고 사용자에게 보이지 않지만 시스템의 안쪽에서 수행되는 백엔드를 책임지며 프론트엔드에서 필요로하는 결과를 제공하는 ‘Core팀, API팀, QA팀, SRE팀, 데이터팀, 기술연구팀’이 인터렉티브하게 일하고 있습니다.저희는 암호화폐 거래소 코인원을 더욱 더 잘 구축하고, 개선하고, 안전하게 운영하는 것을 목표로 삼고 있어요. 또한 개발 뿐만 아니라, 지속적인 블록체인 연구를 통해 거래소에 최신 기술 트렌드를 반영할 수 있도록 항상 고민하죠.파이콘의 질문왕, 웹팀의 경화님 :)저 멍때리는거 아니에요, OST에 집중하고 있는거에요. (feat. 새로찬가로찬님)눈감은거아니에요, 뜬거에요. (feat. 킹갓제너럴대현님)코인원 개발자들은 어떻게 일하나요?경화님 (Web developer) : 코인원 개발자들은 서로 어떤 업무를 하고 있는지 눈으로 트래킹 할 수 있고, 투명하게 업무를 공유할 수 있는 개발환경을 만들고 있어요. 저희는 협업툴로 Jira와 Confluence를 사용하고 있습니다. 협업툴로 업무의 효율성을 높이면서 새로운 개발업무에 집중하는데 많은 도움이 되고 있어요. 또한 협업툴 이외에도 새로운 기술 도입에 긍정적이라 자기주도하에 여러가지 기술을 실무에 적용해볼 수 있다는 점이 매력적이죠.새로찬님 (Engineer) : 주어진 요구사항에 맞게 그대로 개발하기 보다는 요구사항의 필요성에 대해 공감하고 더 좋은 방향으로 만들 수 있도록 기획, 디자인, 개발 모든 단계에서 능동적으로 의견을 제시합니다. 기술본부에서는 빠르게 변화하는 시장상황에 맞추기 위해 매일 아침마다 PM, 개발자, 디자이너가 모여 *데일리스크럼을 진행하는데요, 서로의 Task나 Project 진행상황을 공유하고 최고의 프로덕트를 사용자에게 전달하기 위해 노력하고 있어요. *데일리스크럼이란? 정해진 시간에 개발크루들이 모여서 어제 했던 일과 오늘의 할 일 등을 공유하고, 다른 개발 크루들이 이야기하는 업무현황을 들으면서 내가 기여할 수 있는 부분과 이슈를 빠르게 파악할 수 있는 자리에요! 대현님 (Engineer) : 서비스를 만드는데 있어 주도적으로 그리고 적극적으로 개발업무를 수행합니다. 예를 들어, 코인원 Live Service에서 Manual하게 처리하고 있었던 이슈들을 자동화하는 프로젝트가 있었는데요. 수동으로 해결할 수 있는 부분이지만, 이를 서비스 기획자분들과 연계해 Task로 만들어 해결방안을 얻을 수 있었습니다. 또한 여기서 그치는게 아니라, 계속해서 코인원 사용자들을 위해 필요한 기능들을 추가하는 프로젝트에 참여하면서 많은 재미를 느꼈죠.왼쪽부터 파이콘의 나이스걸 (윤정님), 개발자 (희수님), ddddeveloper (선우님)개발본부의 공식포즈, 쁘쁘브브브이 종헌님 ㅇ_ㅇV코인원 개발자가 되면 어떤 점들이 좋나요?희수님 (Engineer) : 이전에 경험하지 못했던 거래소 프로덕트를 만들어볼 수 있다는 점이 정말 좋습니다. 저는 원래 암호화폐와 핀테크에 관심이 많았는데요. 코인원에서 거래소 프로덕트를 직접 만들면서 관심 분야에 대해서도 더 많이 알게 되고, 또 이런 서비스를 개발할 때 중요한 것이 무엇인지 고민해보면서 배워가는 것이 정말 많아요. 제가 코인원 합류 이전에 개발한 프로덕트들과는 성향이 많이 달라서 더 재미를 느끼고 있어요!종헌님 (Web developer) : 함께 일하는 모든 개발자 분들이 더 효율적인 개발 프로세스를 만들기 위해 치열하게 고민하는 것을 보면서 매일 놀라고 있어요. 서비스를 개발하며 느끼는 문제점을 도출하면서 치열하게 토론하고, 그 문제들을 해결하기 위한 아이디어들을 직접 시도해 볼 수 있어서 좋아요. 일을 더 효율적으로, 즐겁게 할 수 있는 환경을 만드는 과정이 코인원만의 애자일을 만들어나가는 것 같아 더 열정적으로 일할 수 있는 것 같습니다.선우님 (Web developer) : 많은 사용자들이 직접 이용하는 서비스를 만드는 개발자로서 다양한 문제 상황을 직면하고 해결해 나가며 보고 배우는게 많습니다. 또 코인원 기술본부는 여느 코인원 조직처럼 언제든 자신의 의견을 자유롭게 이야기하는 분위기가 형성돼있어요. 특히 하나의 프로젝트가 끝나면 회고(Retro)를 진행하는데, 프로젝트의 진행과정, 이슈, 결과물을 공유하면서 저 자신을 성장시켜나갈 수 있는 요소들이 많습니다.안녕하세요, 코인원 신입개발자 (a.k.a CTO) 입니다. (인사성 밝음밝음)“코인원에서는 어떤개발자를 원하나요?진우님 (CTO) : 블록체인을 좋아하고, 개발을 좋아하시는 분이라면 언제든지 환영입니다. 코인원 개발 크루들을 생각했을 때 ‘몰입’이라는 단어가 가장 먼저 떠오르는데요. 모두가 마니아적이고 덕후기질이 있어, 자기주도적으로 업무를 하고 적극적으로 개발할 것들을 찾고 실행합니다.  앞으로 코인원 개발 크루로 합류하실 분들 또한, 적극적으로 아이디어를 내고, 그 아이디어를 실현할 수 있도록 프로젝트를 리딩할 수 있는 분이었으면 해요. 물론 개발하는데 있어서는 누구보다 신중한 자세가 필요하겠죠? 누구보다도 내가 짠 개발코드를 꼼꼼하게 검토하고, 표용력이 있어 좋은 아이디어에는 귀 기울일 줄 아는 분들이셨으면 좋겠습니다. 참고로 Node.js, Python, Spring, C#, AngularJS를 업무에 많이 활용하고 있답니다.개발을 사랑하시는 분! 블록체인을 함께 탐험할 준비가 되신 분! 코인원 개발자 채용에 많은 관심 부탁 드립니다.코인원 개발자 채용에 많은 관심 부탁드립니다 :-)지금까지 미니 인터뷰를 통해 코인원 개발 크루들의 이야기를 들어봤습니다:) 블록체인이라는 새로운 기술 영역에서 매일매일 즐겁게 도전하고 있는 코인원 개발팀에 합류하고 싶은 분들은 현재 코인원 개발자 채용이 진행되고 있으니 지금 바로 확인해주세요!#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트 #기업문화 #조직문화 #팀원소개 #인터뷰

제 깃헙블로그 https://heelog.github.io/about/ 에서 동시에 포스팅을 진행하고 있습니다.개발 관련 글을 보기에는 블로그를 통하시는 것이 더 좋습니다!안드로이드에서 색상을 표현할 때는 #AARRGGBB 형태로 표현한다. 앞의 AA 자리에 16진수를 이용하여 투명도를 표현해줄 수 있다. 범위는 0~255이다.0%~100% 투명도 값  100% — FF99% — FC98% — FA97% — F796% — F595% — F294% — F093% — ED92% — EB91% — E890% — E689% — E388% — E087% — DE86% — DB85% — D984% — D683% — D482% — D181% — CF80% — CC79% — C978% — C777% — C476% — C275% — BF74% — BD73% — BA72% — B871% — B570% — B369% — B068% — AD67% — AB66% — A865% — A664% — A363% — A162% — 9E61% — 9C60% — 9959% — 9657% — 9456% — 9156% — 8F55% — 8C54% — 8A53% — 8752% — 8551% — 8250% — 8049% — 7D48% — 7A47% — 7846% — 7545% — 7344% — 7043% — 6E42% — 6B41% — 6940% — 6639% — 6338% — 6137% — 5E36% — 5C35% — 5934% — 5733% — 5432% — 5231% — 4F30% — 4D28% — 4A28% — 4727% — 4526% — 4225% — 4024% — 3D23% — 3B22% — 3821% — 3620% — 3319% — 3018% — 2E17% — 2B16% — 2915% — 2614% — 2413% — 2112% — 1F11% — 1C10% — 1A9% — 178% — 147% — 126% — 0F5% — 0D4% — 0A3% — 082% — 051% — 030% — 00참고한 블로그: 커피한잔의 여유와 코딩#트레바리 #개발자 #안드로이드 #앱개발 #인사이트 #경험공유 #꿀팁

이 포스팅은 총 4부로 이어지며 현재는 4부입니다.1부 : Android, MVC, MVVM, MVP2부 : Android 와 Annotation3부 : AndroidAnnotations 과 MVC4부 : AndroidAnnotations 과 테스트앞선 3개의 포스팅을 통해 AndroidAnnotations 과 MVC 가 view 에 관여하는 동작들이 모두 View 로 분리된 것을 확인할 수 있습니다.이러한 구조덕분에 Model 에 대한 테스트와 View 에 대한 테스트가 명확히 구분지어지게 되었습니다.Test 코드를 작성함에 있어서 View 에 대한 테스트가 다소 어려움이 있다는 것을 감안한다면 Model 에 대한 테스트만 집중할 수 있는 구조가 테스트에 대한 접근을 더욱 쉽게 해줍니다.다음은 앞선 포스팅에서 정의된 코드 중에서 Model 에 대한 테스트입니다.※ 테스트코드는 Robolectric 을 이용하여 작성하도록 하겠습니다.Model Test@RunWith(RobolectricGradleTestRunner.class) public class MainModelTest { private MainModel mainModel; @Setup public void init() { mainModel = new MainModel(Robolectric.application); } @Test public void testGetReleaseState() { // given String version = "3.19" // not yet released // when boolean isReleased = mainModel.getReleaseState(version); // then assertThat(isReleased, is(equalTo(false)); // given version = "3.18" // released // when isReleased = mainModel.getReleaseState(version); // then assertThat(isReleased, is(equalTo(true)); } }위와 같이 Model 만 별도로 테스트가 용이해졌습니다.Presenter TestPresenter 에 대한 테스트는 Model 에 대한 테스트와 다릅니다.Activity 에 커플링이 높기 때문에 해당 Activity 를 직접 바인딩해야 합니다.@RunWith(RobolectricGradleTestRunner.class) public class MainViewTest { private MainActivity mainActivity; private MainView MainView; @Setup public void init() { mainActivity = Robolectric.buildActivity(MainActivity.class).create().start().resume().get(); MainView = mainActivity.mainView; } @Test public void testGetVersionText() { // given String version = "3.19" // when MainView.versionEditText.setText(version); // then assertThat(MainView.getVersionText(), is(equalTo(version)); } }Jandi Team은 View 를 테스트하기 위해서 Presenter 와 Activity 의 패키지 Level 을 같은 Level 로 유지하고 있습니다.AndroidAnnotations 에서 DI 를 설정하기 위해서는 해당 변수나 메소드는 최소 Package Scope 로 정의해야하기에 위와 같은 형태의 Field 접근을 볼 수 있습니다.정리AndroidAnnotations 를 활용한 MVC 패턴의 전환의 또다른 이점은 이와 같이 테스트를 명확히 분리할 수 있다는 장점을 주었습니다. 물론 이 방법은 MVVM, MVP 로 구현하였을때보다 나은 형태라 할 수는 없으나 View 에 대한 테스트가 좀 더 용이해진 것이라 생각합니다.※ Activity 는 왜 테스트하지 않나요?MVP 패턴에서 Activity는 Controller 의 모습을 지니고 있습니다. 이는 Unit Test 가 아닌 Behavior 테스트에 가까운 모습이며 다른 방식으로의 테스트코드 구현이 필요하다고 생각합니다.#토스랩 #잔디 #JANDI #개발 #개발자 #개발팀 #기술스택 #일지 #후기 #꿀팁 #인사이트

백엔드 서비스로 Python을 사용한다면 만나게될 상황을보다 쉽게 해결하기 위한 와탭의 Python APM, 개발하게 된 이유입니다.파이썬은 배우기 쉽고, 어디서나 실행되는 언어라고 이야기되며, 인기도 높습니다. 생각보다 많은 곳에서 배울 수 있으며, 혼자 배우기도 좋습니다. 그런데, 이 규모가 확대되어서 스타트업의 경우에 Python을 사용하여 백엔드 서비스를 개발하는 경우를 찾는 것이 어렵지 않습니다. 또는, 수학적인 알고리즘이거나 ML(머신러닝)과 같은 영역이거나 블록체인등에서 Python을 사용하여 API geteway나 broker를 사용하는 경우에 한정한 상황을 고려하고 있습니다.Python으로 백엔드 서비스를 만들 때에는 성능과 설계 부분에 대해서 많은 걱정을 하게 됩니다. 이런 상황을 만나게되는 개발자는 여러가지 문제를 만나게 됩니다. 그 문제에 와탭은 집중합니다.!와탭은 백엔드 서비스를 Python으로 개발시에 만나게 되는 상황을 가장 최우선으로 생각하게 되었습니다.Python으로 '설계', '개발'되고 '테스트'된 후에 '배포'되는 상황에서 서비스의 불완전함과 속도상의 문제, 리소스의 불협화음등을 '유지보수'하는 단계를 '성능 튜닝'이라고 정의하고, 이를 고려한 상황을 보다 단순화하는 것이라고 생각하게 되었습니다. 이를 어떻게 처리하느냐가 와탭 Python의 핵심 가치라고 생각하였습니다.----- 이 부분은 Python korea 페이스북에서 '배권한'님이 지적하신 내용을 기반으로 일부 첨언되었습니다.----- python native 개발자들에게는 불필요한 설명에 해당됩니다.파이썬은 분명, 읽기 쉽고 사용하기 쉬운 것은 장점이며, 라즈베리파이 위에서 동작되는 기민함은 정말 매력적입니다. <- 원래 문장.(* 현재에는 jvm도 동작합니다. 하지만, 작고 기민하게 다양한 IoT 디바이스에서 폭넓게 활용되는 것은 파이썬의 장점은 분명하지 않나 합니다. 이 부분에 대한 지적이 있어서 첨언합니다. )내부 구성상 비동기식으로 쓰레딩이 아니라, 단일 이벤트 루프를 사용하는 비동기식 작성은 매우 효과적입니다. <- 원래 문장.(* 이 부분도 asyncio나 gevent등에 대한 이야기이고, CPython의 언어 구현상 GIL때문에 쓰레드가 비효율적이라는 이야기를 거론하고 싶었으나, 일반적으로 파이썬에 대한 언어를 사용할때에 대부분 사용하는 이유가 단일 이벤트 루프기반의 비동기식 작성이 매우 일반적으로 사용되기 때문에, 이렇게 서술되었습니다. 하지만, 이런 설명은 백엔드로 Python을 사용하는 경우에 대부분의 프레임웍들에서 처리되고 있기 때문에 서술이 불분명하다는 지적이 있었습니다. 당연, 백엔드 서비스를 개발할때에 사용되는 wsgi interface등에 맞추어서 서술되는 경우에는 이런 설명이 무의미합니다.다만, 이렇게 서술한 이유는 Java를 기반으로 APM이 개발되어졌기 때문에 이 부분에 대한 서술이나 설명이 필요하다고 생각한 저의 과도한 설명이 되겠습니다.이 부분은 Python Native개발자들에게는 불필요한 설명이 되겠습니다. 하지만, 백엔드 서비스를 개발하면서 만나게될 환경에서는 이 부분에 대한 이해가 어느정도 필요하다고 생각되어 서술된 내용이라고 생각해주시면 감사하겠습니다. )----------------------------------------------------------------------------------------------------------------------이 방식은 복잡한 자원 경쟁이나 교착상태를 발생하지 않게 되며, 기본 코딩과 유지보수를 정말 수월하게 만들어 줍니다. 그만큼 일관성이 높은 수학 알고리즘을 구현하는데 매우 적합합니다. 하지만, 냉정하게, 비즈니스 로직이나 분기가 많은 업무 로직에 적합한 언어는 아닙니다.하지만, 수학적 알고리즘 기반의 주요 모듈 위에 데이터베이스가 일부 필요하고, 웹서비스의 형태로 가동되는 구조라면 파이썬은 매우 훌륭한 선택이 되고 있으며, 생각보다 많이 사용됩니다.그런 이유 중의 하나는 파이썬의 멀티패러다임 구성과 같은 구성에서는 자바에서처럼 굳이 프린트를 위해서 객체지향 클래스를 만들 필요 없이 간단한 함수형 스타일도 가능하게 구성이 됩니다. ( 자바 8에서는 이런 함수 기능도 추가되었습니다. )단순한 구조와 방식 때문에 파이썬 개발은 요즘처럼 ML이나 AI 등의 기술적 요소들이 많이 사용되는 환경에서는 매우 효과적입니다. 백엔드 파이썬 개발이 많이 보이게 되는 이유이기도 하죠.또한, 파이썬 개발의 단점이라고 지적되던 문제들도 현재에는 실행 속도 문제는 사실상 큰 문제가 되지 않는 상황입니다. 일례로, 파이파이(PyPY)로 실행된 파이썬 코드는 웬만한 수준의 C 코드보다 빠르게 동작합니다.굳이 더 지적하자면, 모바일 컴퓨팅과 브라우저에 따른 웹 애플리케이션 클라이언트는 굳이 파이썬으로 작성할 필요성을 느끼지 못한다고 이야기하는 정도입니다.하지만, 이런 파이썬 개발에 가장 큰 문제가 있습니다.테스팅 없이는 동작하기 어렵고,실제 동작 환경에서만 등장하는 오류의 발생파이썬의 특성상 동적 입력 형태에 따르는 더 많은 테스팅을 필요로 하고 있으며, 실제 실행시간에만 나타나는 오류를 찾는 것이 가장 큰 문제가 있습니다. 이 부분은 수많은 파이썬 개발자들을 괴롭히고 있습니다.( 단편적으로 파이썬 개발환경이 매우 고도화되어있지 않으며, 파이썬으로 백엔드 서비스를 만들 것이라고 예측하지 못한 점도 있을 것입니다. 앞으로 파이썬 개발이 더 고도화 되기를 기원합니다. )이 가장 큰 문제를 잡기 위해서와탭은 집중하였습니다.파이썬 백엔드 개발 시의 문제 해결!물론, Python도 디버깅에 대한 지원 유틸리티가 존재합니다.pdb라는 파이썬 디버깅 모듈을 통해서 Step over/Step into, 중단점(breakpoint) 설정, 콜 스택 검사, 소스 리스팅, 변수 치환 등을 할 수 있습니다.‘Phthon -m pdb 파이썬 파일. py’의 형태로 디버그 동작 화면에서 세부적인 동작을 트레이스 해보는 방식을 사용하거나, pdb모듈을 import 한 후에 pdb.set_trace()를 중단하고 싶은 부분에 넣어서 사용하는 방식도 사용됩니다. 또한, 디버그 세션을 사용하는 방식이며, PDB를 사용하여 디버깅하는 방식들도 흔하게 사용됩니다.PyCharm, PTVS, Spyder 등의 IDE를 사용해서 디버깅을 하는 방법은 전통적인 개발환경과 동일하게 사용할 수 있습니다.하지만, 이 방식들은 백엔드 서비스에는 맞지 않게 되며 개발자들은 백엔드 서비스 동작시에 디버그 추적을 위한 로그를 거는 방식을 흔하게 사용하게 됩니다. ( 너무도 전통적인 방식이죠. )정말 백엔드로 파이썬을 사용하고 있다면, 오류 추적이나 동작 메커니즘을 추적한다는 것은 매우 귀찮고 번거로운 작업이 됩니다.만들어지는 파이썬의 모든 파일에 해당 로그를 넣었다가 빼었다가, 배포의 오류를 만나는 상황까지 매우 번거로운 작업들이 끊임없이 반복되게 됩니다. 이런 상황들을 추적하기 위한 APM의 추적 기능들을 찾게 됩니다.또한, Python의 특징상 수학 알고리즘으로 구성된 API 중개인의 형태를 취할 경우에 DB에 대한 접근을 위한 ORM에서의 추적과 외부 웹 호출들이 뒤섞이게 되면서 오류 추적은 매우 짜증스러운 단계로 진화되게 됩니다.Python으로 백엔드 개발을 하게 되면만나게 되는 매우 짜증스러운 상황이죠.그래서, 와탭의 Python APM은 이 문제에 집중하기 위해서 와탭 고유의 문제 해결 방식을 그대로  아키텍처로 적용하여서 개발시에 편하고 빠르게 성능을 추적할 수 있도록 제작되었습니다. Python 백엔드 개발을 위한 최선의 방향을 제시합니다.Python개발자는 와탭의 APM을 설치하면 매우 손쉽게 웹 트랜잭션의 단계, 에러 추적, 클래스 추적, DB의 형태 및 Slow Query추적, 외부 호출 메커니즘의 구성 등을 설치 이후부터 빠르게 추적할 수 있으며, 개발자의 실수이거나 다른 외부 호출의 문제, DB와의 관계 등을 빠르게 잡아낼 수 있습니다.에러를 추적하기 위한 로그를 동작한다던지, 실환경시에 배포를 다시 한다던가 하는 귀찮은 작업을 모두 제거하는 것뿐만 아니라, 매우 통계적으로 의미 있는 와탭의 트랜잭션 추적 메커니즘을 사용할 수 있게 됩니다.파이썬을 기반으로 백엔드를 구성하는 곳이라면,와탭 APM은 매우 의미 있는 결과를 도출할 수 있습니다.와탭 Python의 세부적인 기능을 조금 더 상세하게 설명드리겠습니다.가장 먼저, 실시간 트랜잭션 모니터링!5초 주기로 트랜잭션을 수집하는 와탭의 방식은 서버의 부하를 최소화하면서 가장 의미 있는 데이터들을 수집하고 데이터 기반으로 오류와 트랜잭션을 빠르게 추적할 수 있게 합니다.파이썬 개발 시의 동작성을 체크하기 위한 와탭만의 고유의 진행 중인 트랜잭션 실시간 모니터링 기능인 아크 이퀄라이져와 동작된 웹 트랜잭션의 종료시간을 기준으로 시각화하여 동작된 트랜잭션의 상황을 한눈에 파악할 수 있습니다.와탭 Python APM위의 그림을 보면, Active Transaction으로 불리는 원형( 아크 이퀄라이져라 함 )으로 실제 동작중인 트랜잭션의 개수와 동작속도 등을 체크할 수 있으며, Hitmap을 통해서 종료된 트랜잭션의 속도를 시각화하여 볼 수 있습니다. 이 두 개의 시각화 만으로도 느린 트랜잭션을 추적 관리할 수 있습니다.Python 트랜잭션 추적 및 분석개발자는 단지 APM을 동작시켰을 뿐이지만, postgreSQL 데이터베이스에 연결하고 SQL문장을 주고받는 부분들을 하나의 시각화된 관점으로 나열해서 확인할 수 있습니다.각각의 동작 시간을 추적하는 것은 물론이고, 이 내용은 ORM으로 매핑된 상태에서도 SQL의 동작 순서대로 시각화되기 때문에 순서가 꼬이거나 문제가 발생되는 부분들을 손쉽게 찾아볼 수 있게 합니다.이외에도 와탭 APM( Java, Node, PHP 등의 모든 APM)에 기본적으로 제공되는 트랜잭션 추적 모듈 이외에도 사용자가 원하는 모듈 추적에 대한 기능들을 플러그인 형태로 정의할 수 있습니다. 더 복잡한 추적을 위해서 와탭의 고유기능을 추가적을 확대 사용이 가능합니다.WHATAP_HOME 의 plugin.json파일에 적절한 내용을 수정하여 특정 모듈의 데이터를 추적할 수 있습니다. 특정 모듈의 데이터를 추적하거나, 사용자 별로 원하는 모듈을 추적할 수 있습니다.*사용 안내:•[module_name]: 추적하고자 하는 대상의 모듈 명. import 하는 모듈 명 이기도 하다.•[class_name]: 추적하고자 하는 대상의 클래스 명. 없다면 ‘’(empty string)으로 사용한다.•[def_name]: 추적하고자 하는 대상이다.•args_indexes: 추적하고자 하는 대상의 아규먼트 인덱스. 여러 개일 경우 , 로 구분한다.•kwargs: 추적하고자 하는 대상의 키워드 명. 여러 개일 경우 , 로 구분한다.Plugin 기능 사용위의 예제에서는 Plugin과 SQL update문장의 순차적인 실행,세부 Plugin 설정에서 사용자의 모듈명, 추적 클래스 명, 추적대상과 아규먼트 인덱스, 키워드 등을 추적할 수 있습니다.*사용 예:plugin.json{"[module_name]": {      "class_name": "[class_name]",      "def_name": "[def_name]",      "args_indexes": ", ",      "kwargs": ", "},"httplib2": {      "class_name": "Http",      "def_name": "request",      "args_indexes": "1",      "kwargs": "method"},"faker.providers.address": {      "class_name": "Provider",      "def_name": "street_address",      "args_indexes": "",      "kwargs": ""}}두 번째, 데이터베이스를 매핑한 ORM과 SQL의 순서와 속도, Slow Query!매우 당연하게 파이썬을 기반으로 백엔드 개발을 할 경우에 데이터베이스를 사용하게 되며, 이에 대한 Slow Query와 관련된 추적하는 것이 개발자에게 필요하게 됩니다. 향후, RDS기반을 사용하게 되면 Query추적은 대부분의 데이터베이스 처리에 기본이 될 것입니다.현재 지원되고 있는 mysql / postgresql에 대하여 SQL Query, Fetch Count, SQL Query수행 시간을 수집합니다.Python개발 시에 RDBMS(관계형 데이터베이스 관리 시스템)를 선택하면 거의 항상 ORM(객체 관계 매핑) 라이브러리를 함께 사용하게 됩니다.특히, 파이썬에서는 이런 ORM라이브러리가 다양하고 사용하기 쉽기 때문에, 매우 흔하게 사용하고 있습니다.ORM의 장점으로는 쿼리를 생성하거나 추상화하는 대신, 데이터 베이스 시스템에 대한 접근을 쉽게 할 수 있는 장점이 있습니다. 다만, 이러한 장점 때문에 실제 만들어진 쿼리가 어떠하고 쿼리 수행 시간이 얼마나 걸리는지에 대해서는 추적이 어렵다는 점이 있습니다.이처럼, 파이썬의 특징상 ORM(객체 관계 매핑) 라이브러리를 사용할 경우에 추상화된 쿼리가 어떻게 동작하고, 실제 어떤 상황으로 발생 및 동작되는지를 한눈에 파악할 수 있게 합니다.ORM으로 매핑된 SQL의 순차적인 동작 상태 파악그리고, 세 번째. 외부 호출 추적파이썬 백엔드 개발 시에 사용되는 외부 호출(request/httplib2)등의 외부 호출과 관련된 호출 정보 및 수행 시간 등을 수집합니다.외부 호출을 사용하는 경우에는 각각의 호출에 대한 지연시간에 대해서 세밀하게 추적해야 하므로, 이와 관련된 에러와 지연시간 등을 추적하는 것은 매우 중요한 개발 시의 관점입니다.Python 외부 호출 추적마지막 중요 관점 네 번째는, 튜닝을 위한 다양한 프로파일 데이터의 제공을 이야기할 수 있습니다.와탭의 파이썬 에이전트는 위에서 나열되는 성능 저하를 위한 요소들의 전체적인 관점에서 수집하고 그 데이터들을 시각화할 수 있습니다.데이터베이스를 효율적으로 사용하고 있는지, 사용하는 ORM툴과 매핑과의 관계, 쿼리와 쿼리의 수행 시간과 상태에 대한 추적, 외부 호출시간과 각각의 지연되는 외부 호출과의 관계와 순서 등이 전체적으로 백엔드로 개발되는 Python의 성능 튜닝에 영향을 주게 되는 것이죠.그 이외에도 전체적으로 백엔드 서비스의 TPS, 응답 시간, 서비스 리소스 사용량과 어떤 에러가 발생되고 있는지를 알 수 있습니다.서비스 사용자가 사용하는 상세한 정보들을 프로파 일릉 함으로써 이들의 연관관계를 한분에 파악하게 해줍니다. 와탭에서 관리되는 프로파일 정보는 - 트랜잭션, SQL Query, 외부 HTTP호출, Error, User Agent, Client IP 등의 상관관계들입니다.그리고, 덤으로... Python이 설치 운영되는 전체적인 패키지의 버전을 한눈에 파악할 수 있는 것은 너무도 당연한 기능입니다.설치된 Python 패키지 확인그리고, 와탭의 DNA를 그대로 이어받은 APM이기 때문에, 기본적인 APM의 기능들을 대부분 담고 있습니다. 처음 와탭 APM을 접하시는 분들을 위해서 간단하게 설명드리면 다음과 같습니다.CUBE 메뉴는 시간을 기점으로 와탭 Python APM이 설치된 이후부터 현재까지의 모든 상황들을 추적 관찰할 수 있습니다. 주말에 오류 간 난 상황이라던지, 특정 오류의 발생 시점을 알고 있는 경우에 빠르게 해당 문제가 발생한 위치나 SQL 등을 추적할 수 있습니다.상세한 일간, 주간, 월간 리포트나 MAU 등을 추적할 수 있는 리포트 기능들은 와탭만이 가지고 있는 장점에 해당됩니다.Python으로 백엔드 웹서비스를 개발하고 계시다면, WHATAP Python APM은 개발과 운용을 매우 풍요롭고 빠르게 해줍니다.파이썬 백엔드 서비스 개발자라면 와탭 APM!

Overview개발 도중 내용이 복잡하거나 소스가 길면 종종 오픈소스 라이브러리를 사용합니다. 쉽게 원하는 기능을 구현할 수 있기 때문이죠. 그렇다면 오픈소스 라이브러리는 어떻게 앱에 가져와서 사용할까요? 바로 ‘CocoaPods(이하 코코아팟)’을 쓰면 됩니다.What is CocoaPods?코코아팟의 공식 웹사이트에서는 코코아팟을 이렇게 소개하고 있습니다.“CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects”“코코아팟은 스위프트와 오브젝티브-C 코코아 프로젝트를 위한 의존성 매니저(dependency manager)다.”즉, ‘개발자가 편리하게 사용할 수 있게 오픈소스 라이브러리를 프로젝트와 연결해주는 환경 또는 도구’를 말합니다. 이로 인해 다양한 장점을 가지고 있는데요. 우선 코코아팟은 개발자가 개발한 앱에 라이브러리를 추가, 삭제, 업데이트 등의 관리를 할 수 있습니다. 예를 들어, 네트워크 관련 라이브러리를 개발자가 직접 개발하지 않고, Alamofire 라이브러리를 코코아팟으로 앱에 연결해 사용하는 것입니다. 둘째, 라이브러리 버전을 직접 지정하여 사용할 수 있어 업데이트 버전이 나와도 지정한 버전을 계속 사용할 수 있다는 점입니다. 만약 새로운 버전에 맞춰 개발할 준비가 되면 그때 업데이트를 하면 됩니다.CocoaPods에서 facebook을 검색하면 관련된 다양한 라이브러리가 나옵니다.How to use Cocoapods?1.코코아팟 설치하기개발한 앱에 사용할 오픈소스 라이브러리를 찾았다면 코코아팟을 설치해 앱과 연결해봅시다. 먼저 코코아팟을 설치하고 터미널 프로그램을 열어 아래와 같은 명령어를 입력합니다.$ sudo gem install cocoapods 그리고 CocoaPods Master Specs repository에 있는 Podspec file를 컴퓨터에 다운로드합니다. –verbose 명령어를 이용해 현재 진행 상황을 터미널에서 볼 수 있게 합니다.$ pod setup --verbose 이제 코코아팟을 사용할 준비가 되었습니다. Xcode에서 간단한 프로젝트를 만들고 끝냅니다. 이번 글에서는 관광명소를 보여주는 목록 앱을 예제로 만들겠습니다.2.라이브러리 연결하기터미널 프로그램을 이용해 방금 전 만든 프로젝트 경로로 이동하고, Podfile을 만들어 앱에 필요한 라이브러리를 설정합니다. Podfile을 만드는 방법이 두 가지입니다. 첫 번째는 pod init 명령어를 이용해 코코아팟이 기본 틀이 있는 파일을 생성하게 하는 것입니다. 두 번째는 개발자가 직접 빈 파일을 만들어 설정하는 방법입니다. 이번 글에서는 pod init 명령어를 사용하겠습니다. (편리합니다.)$ pod init podfile이 생성된 것을 확인할 수 있습니다.이제 Podfile을 열어 우리가 사용할 라이브러리를 세팅하고 코코아팟 공식 사이트에 접속합니다. 사용하고자 하는 라이브러리를 검색하고 이름 옆 클립보드 아이콘에 마우스 포인터를 올려보세요. Podfile에 복사할 텍스트가 나타날 겁니다. 이 텍스트를 복사하여 Podfile에 붙이고 저장합니다. 이 글에선 URL에서 가져올 이미지를 다루기 위해 SDWebImage 라이브러리를 사용하겠습니다.완성된 Podfile의 모습위의 Podfile을 잠시 설명하자면 프로젝트의 배포 타겟은 iOS 9.0 입니다. ‘use_frameworks!’ 은 코코아팟을 통해 프로젝트에 추가할 라이브러리가 스위프트로 작성되어 있고, 프레임워크를 사용할 것이기 때문에 꼭 추가해야 하는 문장입니다. 라이브러리 옆의 숫자는 4.3 그리고 4.4 이전까지 라이브러리 버전을 사용하겠다는 뜻 입니다. 최소한의 설정을 맞췄으니, 저장하고 다음 명령어를 실행합니다.$ pod install --verbose pod install 완료 후 xcworkspace 파일이 추가된 것을 확인할 수 있습니다.Pod 설치가 완료되면 xcworkspace 파일이 생성된 것을 확인할 수 있습니다. Xcworkspace 파일은 쉽게 말해서 프로젝트들의 컬렉션(collection of projects)입니다. 기존에 제작한 프로젝트(Original project)와 pods 프로젝트(Pods project)를 함께 묶는데, 이 pods 프로젝트 하나로 모든 라이브러리를 관리할 수 있습니다. 기존 프로젝트는 이 pods 프로젝트를 의존하기 때문에 xcodeproj 파일을 열면 연결된 라이브러리들에 대한 정보가 없어서(혹은 발견하지 못해서) Xcode 프로그램이 에러를 발생시킵니다. 그러므로 코코아팟으로 pod을 설치했을 때, 프로젝트는 xcworkspace 파일을 열어 개발해야 연결한 라이브러리들을 잘 사용할 수 있습니다.3.라이브러리 사용하기이제 연결한 라이브러리를 사용해봅시다.1) 예제에서는 SDWebImage 라이브러리를 이용해 URL 이미지 주소로 ImageView에 이미지를 설정하도록 코드를 추가하겠습니다.테이블뷰(UITableViewController) 컨트롤러를 이용해 목록으로 관광명소 이름, 설명, 이미지를 보여줄 것입니다. 관광명소 이름, 설명, 이미지에 맞게 데이터 모델을 만들고 스토리보드에서 UI를 디자인합니다. 테이블뷰 컨트롤러 파일을 새로 생성해서 이 소스 파일에서 라이브러리를 연결해서 기능을 구현해봅시다. 먼저 라이브러리를 이 소스에 연결하도록 import 명령어를 입력합니다.AttractionTableVC.swift import SDWebImage 그리고 아래와 같이 tableView(tableView:cellForRowAtIndexPath:) 함수에 코드를 작성합니다.2)override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> AttractionTableViewCell {         // Table view cells are reused and should be dequeued using a cell identifier.         let cellIdentifier = "AttractionTableViewCell"         guard let cell = tableView.dequeueReusableCell(withIdentifier: cellIdentifier, for: indexPath) as? AttractionTableViewCell else {             fatalError("The dequeued cell is not an instance of AttractionTableViewCell.")         }         let attraction = attractions[indexPath.row]                  // . . .         cell.attractionLabel.text = "\(indexPath.row). \(attraction.nameWithDescription)"         cell.attractionImage.sd_setImage(with: attraction.photoURL, completed: nil)                 // . . .                 return cell     } SDWebImage 라이브러리를 쓴 이유는, URL 이미지 주소를 이용해서 관광명소 이미지를 보여주고 싶었습니다. 하지만 UIImage에 바로 URL 주소를 사용할 수 없었고, Data 형식으로 변환한 다음 사용해야 했습니다. 라이브러리를 안 쓴 다면 아래와 같은 소스를 작성해야 했을 겁니다.// return UIImage which is set from url data     private func imageFromUrl(url: URL) -> UIImage {         var photo = UIImage()          do {             let imageData = try Data.init(contentsOf: url)             photo = UIImage(data: imageData)!             return photo         } catch {             print(error.localizedDescription)             return photo         }     } 하지만 위에서 만든 소스를 SDWebImage 라이브러리를 이용하면 아래처럼 딱 하나의 명령문으로 줄일 수 있습니다.cell.attractionImage.sd_setImage(with: attraction.photoURL, completed: nil) 소스 길이가 확연히 줄어들었습니다. 이외에도 GIF 지원, asynchronous image downloader 등 SDWebImage 라이브러리 GitHub 페이지로 접속하면 자세한 기능들을 만날 수 있습니다.CocoaPods Error브랜디의 앱 프로젝트를 클론해서 작업하면 종종 코코아팟 관련 오류로 당황했던 적이 있습니다. 몇 가지 에러의 해결 방법들을 소개하겠습니다.1.“/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/sqlite3.h” not found”-> 대부분의 오류들은 코코아팟을 다시 설치하면 거의 다 해결됩니다.$ sudo gem install cocoapods$ pod install –verbose2.“Could not build module firebase core” Error-> project’s temp file 삭제 (~/Library/Developer/Xcode/DerivedData — Xcode->Preference->Location에 위치함)우선 위의 폴더 경로를 먼저 찾아 Finder로 여세요. 그 다음에 Xcode를 종료해 안전하게 삭제해야 합니다.-> ProjectName, .xcworkspace 삭제-> Podfile.lock 파일과 Pods 폴더 삭제-> $ pod install –verbose-> 새로 생성한 ProjectName.xcworkspace 실행하여 다시 빌드하기-> 그래도 안 된다면?—> $ pod update(or) —> $ pod –version 체크(or) —> $ pod repo update—> Podfile에 ‘Firebase’ 주석 처리—> $ pod install (old Firebase가 제거된다)—> Podfile에 ‘Firebase’ 주석 해제—> $ pod install (new Firebase 설치)—> 해결 완료!Conclusion이제는 새로운 기능을 개발하거나 소스를 수정할 땐 코코아팟에서 관련 라이브러리를 찾아봅니다. 마음에 드는 라이브러리는 곧바로 개발하고 있는 앱 프로젝트에 연결해 적용하기도 하고요. 자신의 언어로 순수하게 소스를 개발하는 것도 좋지만, 좋은 도구를 활용하는 것도 업무에 도움이 될 겁니다. 혹시 마음에 드는 라이브러리 찾으셨다면 저에게도 알려주세요. 코코아팟을 사용하는 iOS 개발자가 되신 걸 축하드립니다!주석 1)각 라이브러리의 GitHub 페이지에서는 소스를 연결하는 자세한 방법들을 소개하고 있다.2)attractions 배열에 미리 만들어 놓은 관광명소 데이터들을 저장한다. 배열에서 선정한 하나의 관광명소 데이터 정보를 이용해 각 테이블 뷰 셀에 알맞게 설정한다. 여기서 테이블 뷰 셀에 있는 attractionImage(UIImageView)에 URL 주소로 이미지를 설정하면 된다.참고문헌 swift3 - Error: Could not build Objective-C module ‘Firebase’ - Stack OverflowGoogle 그룹스An Introduction to CocoaPods (Route 85) - YouTube글김주희 사원 | R&D 개발1팀kimjh3@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

안녕하세요. 스타일쉐어에서 서버사이드 개발을 하고있는 김현준입니다. 스타일쉐어의 엔지니어링 블로그의 첫 글에서는 저희 서비스의 스택을 소개하도록 하겠습니다. 사실은 Instagram의 스택과 유사한 면이 많아 글 또한 많이 유사할 것 같네요.서버먼저 스타일쉐어는 서버의 운영 체제로 Ubuntu 12.04 (Precise Pengolin)를 사용합니다. 모든 서버는 아마존 웹 서비스(Amazon Web Services)의 Elastic Compute Cloud(EC2) 위에서 돌아가고 있습니다. 스타일쉐어는 EC2 이외에도 Simple Storage Service(S3)와 같은 AWS의 다양한 서비스를 사용하고 있는데요, AWS를 사용하는 가장 큰 이유는 유연한 확장성(Scalability)이라 말할 수 있을 것 같습니다. EC2의 서버는 모두 가상 머신이기 때문에 관리 콘솔에서의 쉬운 조작으로 서버를 끄고 켤 수 있을 뿐만 아니라, 장애가 생겼을 때도 간편하게 장애가 생긴 서버를 내리고, 새로운 서버로 대체할 수 있는 이점이 있습니다. 이 모든 기능은 API로도 제공되고 있기 때문에, 자동화도 가능합니다. 실제로 스타일쉐어에서도 웹 요청을 처리하는 웹 서버들과 작업을 처리하는 워커들에 대해서 오토-스케일러를 구현해 사용하고 있습니다.로드 밸런싱스타일쉐어의 웹 서버들은 AWS의 Elastic Load Balancing(ELB)에 등록되어 있어서 ELB가 수많은 요청들을 여러 서버들에게 차례로 나누어 보냅니다. 보내어진 요청들은 각각의 서버에서 nginx를 거치며 또 한번 여러 개의 프로세스로 분배되어 처리됩니다.웹 어플리케이션스타일쉐어의 웹 어플리케이션은 Werkzeug 기반의 웹 프레임워크 Flask와 ORM 프레임워크인 SQLAlchemy 위에서 Python으로 구현되어 있습니다.데이터스타일쉐어의 대부분의 데이터는 PostgreSQL에 저장되고 있습니다. 여러 대의 PostgreSQL 인스턴스의 풀링(Pooling)을 하기 위해서 pgpool을 사용합니다. 서비스의 성능 향상을 위한 캐싱 도구로는 Memcached를 사용합니다.스타일쉐어에 올라오는 사진들을 비롯한 대부분의 이미지들은 Key 기반의 스토리지인 AWS S3에 저장하고, 관리합니다. S3의 가장 큰 장점은 사용자가 용량 제한과 파티셔닝에 대해 신경쓰지 않아도 된다는 점일 것입니다. 앞으로도 무한히 많은 사진이 올라올 서비스를 만드는 저희로서는 아주 유용하답니다. 이미지 뿐만 아니라, 서비스를 배포할 때마다 만드는 패키지와 매일매일 데이터베이스 백업 모두 S3에 저장되어 있습니다.작업 관리대부분의 서비스와 마찬가지로, 스타일쉐어도 웹 어플리케이션 서버와 별개로 무거운 작업(Task)을 처리하기 위한 워커(Worker) 서버를 따로 구동하고 있습니다. 여기서 작업이란 계속해서 쏟아지는 웹 요청을 처리하기도 벅찬 웹 어플리케이션에서 처리하기에는 비교적 오래걸리는, 예를 들면 알림(푸시)과 메일을 보내거나, 이미지 프로세싱과 같은 일들을 이야기합니다. 이러한 작업들을 비동기적으로 처리하기 위해 저희는 Celery와 RabbitMQ를 사용합니다. Celery는 Python으로 구현된 비동기 작업 워커이고, RabbitMQ는 워커로 넘길 작업을 관리하는 AMQP 프로토콜 기반의 브로커(Broker) 큐입니다.오픈 소스?스타일쉐어 서버는 비동기 네트웍(asynchronous I/O)을 구현하기 위해서 gevent를 사용합니다. 그 외에 배포(deploy)를 위한 Fabric과 boto나, 내부 문서화를 위해 사용하는 Sphinx 등이 스타일쉐어에서 주로 사용하는 라이브러리/프로젝트 입니다.오픈 소스.위에 적은 것처럼, 스타일쉐어의 구현의 많은 부분이 오픈 소스 프로젝트에 크게 의존하고 있습니다. 훌륭하고 건강한 오픈 소스 생태계 덕분에 우리는 스타일쉐어를 훨씬 더 수월하게 만들고 지탱할 수 있었습니다. 그래서 저희도 도움을 받은 만큼 기여하고, 구성원으로서 더 나은 생태계를 만드려 합니다. 그 중 하나가 바로 이 스타일쉐어 엔지니어링 블로깅 활동이고, 다른 하나가 저희 팀의 오픈 소스 프로젝트 활동입니다. 스타일쉐어 팀의 오픈 소스 활동들은 StyleShare’s GitHub에서 살펴보실 수 있답니다. 여러분들의 관심어린 피드백과 기여도 언제나 감사히 환영합니다.그 외의 도구들스타일쉐어 실 서비스에서 발생하는 오류와 버그를 추적하기 위해 사용하는 Exceptional도 매우 유용합니다. Flask 프레임워크에서 Exceptional 서비스를 쉽게 이용할 수 있도록 도와주는 Flask 확장 모듈인 Flask-Exceptional이 공개되어 있습니다.함께해요저희와 비슷한 환경에서 개발하시는, 같은 도구를 사용하시는, 저희에게 도움을 주고 싶으시거나, 저희에게 (저희가 도와드릴 수 있다면) 도움을 받고 싶으신, 또는 그저 많은 이야기를 나누고 싶은 분들까지 많은 분들과의 소통과 교류가 많았으면 좋겠습니다. IRC를 하시는 분들은 오징어 네트워크(irc.ozinger.org)의 #styleshare-tech 채널로 놀러오세요.#스타일쉐어 #개발 #서버개발 #서버환경 #업무환경 #개발자 #인사이트