스토리 홈

인터뷰

피드

뉴스

조회수 1273

jekyll의 메커니즘을 이해하고 커스터마이징하기

편집자 주-PHP 기반의 서비스를 기준으로 설명했다.-서버의 프로그램은 ‘서버 스크립트’로 표기했다.-HTML/html: 약어로 사용할 경우엔 대문자, 파일명으로 사용할 경우엔 소문자로 표기했다.목차jekyll이 어렵게 느껴지는 이유 jekyll은 모든 화면을 미리 만들어둔다.서버 스크립트 없이 검색 기능을 어떻게 만들까?이미지 캡션 추가이미지 사이즈 대응부록: 글 반영 과정, 도메인 연결 방법, 추가 옵션에 대하여Overview기술 블로그인 브랜디 랩스를 관리하기에 jekyll은 안성맞춤인 도구입니다. 1년 넘게 탈 없이 잘 사용하고 있죠. 물론 커스터마이징을 하려면 고생이 이만저만이 아닙니다. 그 과정은 jekyll을 이용한 Github 블로그 만들기에도 잘 나와있습니다. 도대체, jekyll은 왜 이리도 어려운 걸까요? 브랜디 랩스를 사례로 설명하겠습니다.jekyll이 어렵게 느껴지는 이유일반적인 웹서비스는 정적 리소스와 동적 스크립트의 조합으로 이뤄집니다. 예를 들어 PHP 서비스에서는 정적인 부분을 아파치 웹서버로, 동적인 부분을 PHP 스크립트로 작동합니다.하나의 게시글이 생기면 PHP 스크립트가 데이터베이스에 row 생성을 요청합니다. 게시글 등록 요청을 마치고, 글 목록 화면 요청을 한다면 데이터베이스에서 등록된 글목록을 정리해 HTML 양식으로 응답값을 만들어줄 것입니다.PHP 기반의 블로그 프로그램하지만 jekyll은 컨셉부터 다릅니다. 아주 생소한 메커니즘을 갖고 있습니다. 파일 기반의 데이터를 정적인 리소스로 빌드해서 서비스하죠. 게시글마다 md 파일이나 html 파일을 생성합니다. 글을 작성하고 배포하기 위한 빌드를 진행하면 응답할 html 화면을 만들고, 파일로 저장해 준비합니다. 이 상태에서 유저가 특정 화면을 요청하면 미리 생성한 html 파일을 찾아 꺼내주기만 하면 되죠. 다시 말해, 데이터베이스를 조회하고 HTML 양식으로 응답값을 만드는 과정이 생략되는 것입니다.실제로 Github page가 아파치 서버를 쓰는지는 알 수 없지만 개념 설명을 위해 동일하게 그렸다.jekyll은 모든 화면을 미리 만들어둔다.jekyll은 유저가 요청할 수 있는 모든 화면을 미리 빌드하는 방식을 씁니다. 앞서 다뤘던 브랜디 랩스의 gnav 영역의 회사소개, 채용 화면도 미리 빌드해둬야 합니다. 저자를 소개하는 프로필 페이지도 마찬가지죠. 글이 많아지면서 점점 길어지는 글 목록 화면도 예외는 아닙니다. 글 목록을 보여주는 화면이 많아지만 페이지 수만큼 미리 만들어야 합니다.위의 이미지는 jekyll이 동작하는 메커니즘을 간단히 정리한 것입니다. jekyll을 커스터마이징하려면 완전히 새로운 관점으로 접근해야 합니다. 지금부터는 브랜디 랩스의 검색 기능 구현 과정을 살펴보면서 커스터마이징을 자세히 알아보겠습니다.서버 스크립트 없이 검색 기능을 어떻게 만들까?검색을 하려면 작성된 모든 글의 제목과 내용에 원하는 키워드가 있는지 찾아야 합니다. 하지만 검색어는 변동값이므로 미리 빌드하는 방식으로는 커버할 수 없습니다. 검색어마다 화면을 미리 만들 수 없기 때문입니다.이럴 때는 클라이언트 스크립트는 활용해야 합니다. 서버 스크립트를 쓸 수 없기 때문에 어쩔 수 없는 선택이기도 합니다. 검색에 필요한 정보를 json 파일로 빌드시키고 자바 스크립트를 이용해서 검색하도록 했습니다.먼저 최상위 경로에 search.json을 만듭니다. 파일 시작점에 아래와 같은 패턴이 있다면 빌드 대상으로 인식됩니다.--- --- 이전에 쓴 jekyll 문서를 PDF로 배포하기에서 pdf.html 파일을 만들 때도 비슷한 방법을 사용했습니다.--- --- [ {% for post in site.posts %} { "title" : "{{ post.title | escape }}", "category" : "{{ post.category }}", "tags" : "{{ post.tags | join: ‘, ’ }}", "url" : "{{ site.baseurl }}{{ post.url }}", {% if post.author %}{% for author in site.data.authors %}{% if post.author == author.name %} "author" : "{{author.koname}}", "email" : "{{author.email}}", {% endif %}{% endfor %}{% endif %} "date" : "{{ post.date }}", "content" : "{{ post.content | strip_html | replace: "\", ‘’ | replace: ‘"’, ‘\"’ | replace: ' ‘,’ ' | replace: ' ‘, ’ ' }}" } {% unless forloop.last %},{% endunless %} {% endfor %} ] ▲서머리 데이터를 만드는 json 파일search.json은 모든 페이지의 제목과 내용을 정리해 json으로 만들어야 하기 때문에 site.posts변수를 이용해 만들었습니다. post내용에는 글의 저자, 작성일, 제목, 내용 등 필요한 정보가 있으니 출력하면 됩니다. json을 만드는 것이므로 내용에 “가 들어가면 안되 "으로 치환시켰습니다. 마지막으로 HTML 태그는 검색에 필요하지 않기 때문에 luqid strip_html 함수를 이용해 제거했습니다.http://labs.brandi.co.kr/search.json위의 URL을 클릭하면 브랜디 랩스에서 검색에 사용하는 json을 볼 수 있습니다. 빌드하면 search.json이 만들어지는 것을 확인할 수 있습니다. 이제 json을 로딩하고 해당 키워드를 가진 글을 찾아내기만 하면 됩니다. json 내에 제목과 내용에 입력한 키워드가 있을 때 아래와 같은 UI로 표현했습니다. 기능 구현은 Simple-Jekyll-Search를 이용했습니다. 1)이미지 캡션 추가블로그는 이미지를 많이 사용하고, 상황에 맞게 노출도 해야 합니다. 아래 이미지는 최종적으로 적용한 이미지와 캡션의 결과 화면입니다. {% include figure.html file="/assets/20190415/05.png" alt="05" caption="커스터마이징한 gnav 영역" width="fitcontent" border="true" %} 위와 같이 구성하려고 html과 css를 다음과 같이 구성했습니다. 커스터마이징한 Gnav영역 ▲캡션 html 소스figure { margin: 1em auto; } figcaption { text-align: center; font-weight: bold; color:#999; } ▲캡션에 관련된 css 소스이미지는 가운데 정렬했고, 캡션 텍스트도 옅은 회색으로 가운데 정렬했습니다. 하지만 편집을 담당하는 장근우 대리는 개발자가 아니므로 태그를 입력해달라고 하기엔 무리가 있었습니다. 좀 더 편리한 방식이 없을지 고민하다가 liquid 템플릿의 include 기능을 쓰면 되겠다는 생각이 들었죠. 아래는 브랜디 랩스 원고에 이미지를 넣을 때 쓰는 liquid 문법입니다.{% include figure.html file="/assets/easydebug/5.png" alt="07" caption="커스터마이징한 Gnav영역" %} liquid 템플릿 엔진에서 include할 때 추가 파라미터를 전달할 수 있습니다. file, alt, caption은 파라미터로 전달하고, include되는 파일에서 전달할 내용을 바탕으로 프로그램을 구현할 수 있습니다. {{include.caption}} ▲ /_includes/figure.html이미지 사이즈 대응작은 이미지를 확대하면 이렇게 된다.대부분은 이미지는 화면에 꽉 차지만, 어떤 이미지는 사이즈가 너무 작아 원래의 사이즈로 보여줘야 했습니다.{% include figure.html width="fitcontent" border="true" file="/assets/easydebug/5.png" alt="07" caption="커스터마이징한 Gnav영역" %} ▲사이즈와 외곽 테두리 선에 스펙을 추가했다.추가 전달 인자를 넣고, figure.html 파일에서도 사이즈 대응을 했습니다. {{include.caption}} ▲완성된 /_includes/figure.html 파일figure { margin: 1em auto; } figure.percent100 { width: 100%; } figure.percent90 { width: 90%;} figure.percent80 { width: 80%;} figure.percent70 { width: 70%;} figure.percent60 { width: 60%;} figure.percent50 { width: 50%;} figure.percent40 { width: 40%;} figure.percent30 { width: 30%;} figure.percent20 { width: 20%;} figure.percent15 { width: 15%;} figure.percent10 { width: 10%;} figure.percent5 { width: 5%;} figure.fitcontent { width: fit-content;} figcaption { text-align: center; font-weight: bold; color:#999; } ▲완성된 css이제 원하는 사이즈를 지정해 이미지 상황별 적절한 대응을 할 수 있게 되었습니다.Conclusionjekyll은 브랜디 랩스를 운영하기에 아주 유용한 도구입니다. 기본 템플릿도 훌륭하지만 상황과 편의에 맞게 변경하면 개성 있는 기술 블로그를 만들 수 있을 겁니다. 물론 커스터마이징이 어려울 수 있지만 jekyll의 메커니즘을 이해한다면 금방 적응할 수 있을 겁니다. 이제 블로그를 만들 모든 준비가 끝났습니다. 자, 도전해봅시다!부록1.글 반영 과정jekyll을 이용해서 글을 작성했나요? 이제 Github 저장소에 push하면 글이 반영될 겁니다. push하는 과정을 보면 빌드된 파일을 push하는 게 아니라, 원본에 해당하는 md파일 또는 html 파일을 push하는 걸 알 수 있습니다. push하면 Github page에 바로 반영되지 않고, 몇 분 정도 걸립니다. 이것을 통해 작성한 글이 저장소에 push되면 스케줄러나 트리거에 의해 빌드된다는 걸 유추할 수 있습니다. 아마도 빌드 결과를 위한 저장소가 따로 있고, 빌드된 결과가 저장되는 것이라 예상합니다.2.도메인 연결 방법jekyll 서비스에서는 구매한 도메인을 간편하게 연결할 수 있습니다. 프로젝트의 가장 위쪽에 CNAME 파일을 만들고 push하면 금방 적용됩니다.CNAME 파일3.추가 옵션에 대하여자료를 조사하던 중에 공식 사이트의 빌드 추가 옵션을 찾았지만 0.2초 정도로 큰 차이가 없었습니다. 만약 별도의 옵션이 없다면 빌드 결과는 _site 폴더로 모일 겁니다.공식 사이트 빌드 옵션옵션을 넣어 빌드옵션을 넣지 않고 빌드참고1) GitHub - christian-fei/Simple-Jekyll-Search: A JavaScript library to add search functionality to any Jekyll blog.글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만
조회수 2955

iOS 아키텍처 패턴(MVC, MVVM, VIPER)

Overview“글 한 번 써보실래요?” 입사하고 일주일이 지나 기술 블로그에 글을 써 보라는 제안을 받았습니다. 여러 고민 끝에, 아이폰 앱(이하 ‘iOS’) 주니어 개발자로서 프로젝트 경험과, 공부한 내용을 바탕으로 글을 쓰기로 했습니다. 적절한 짤이라고 생각하는 중iOS 개발자 사전 준비iOS 개발자의 길에 들어섰다면 이미 앱 개발과 개발 언어에 대해서는 알고 있을 겁니다. 개발 프로그램 Xcode와 프로그램을 지원하는 macOS 환경, 개발 언어 Swift 또는 Objective-C, iOS 앱 프로그래밍 등 iOS 앱을 개발하기 위해 필요한 내용까지도요. 우선 ‘iOS 주니어 개발자라면 꼭 알고 있어야 할 것’들을 아래 목록과 같이 정리했습니다. 글을 읽기 전, 목록 중에서 공부가 더 필요한 것이 있다면 꼭! 검색해보세요. Xcode, macOSApple Developer ProgramSwift or Objective-CCocoa TouchUIKitAuto Layout…iOS Architecture Patterns(아키텍처 패턴)“Viper 패턴 들어보셨어요?” Viper는 단순히 ‘독사’를 의미하는 줄 알았는데, MVC 패턴와 같이 디자인 패턴의 한 종류라는 건 입사하고 나서 알게 됐습니다. MVC와 SingleTon(싱글톤) 패턴은 익숙했지만 Viper 패턴은 생소했습니다. Viper 패턴을 3일 안에 분석하겠다는 저의 부끄러운 과거를 반성합니다... ㅜㅜ검색해보니 다양한 디자인 패턴을 찾을 수 있었습니다. iOS 개발자는 앱 프로젝트를 시작하기 전 또는 이미 진행되고 있는 프로젝트에서 개발을 시작한다면 우선 어떤 패턴으로 설계되어 있는지 파악해야 합니다. 그러므로 오늘은 iOS 개발에 주로 사용되는 패턴인 MVC, MVVM, VIPER를 간단하게 살펴보겠습니다.MVCMVC 패턴Model(모델), View(뷰), Controller(컨트롤러). Model에서는 애플리케이션에서 사용할 데이터들을 관리하고, View는 유저 인터페이스를 표현 및 관리합니다. Controller는 View와 Model의 다리 역할을 해 View의 입력을 Model이 반영하고, Model의 변화를 View에 갱신하는 역할을 합니다. 하지만, 애플의 MVC 패턴은 기존 MVC 패턴과 다릅니다. View와 Controller가 강하게 연결되어 있어 View Controller가 거의 모든 일을 합니다.1) 애플 MVC 패턴MVVMMVVM 패턴Model(모델), View(뷰), ViewModel(뷰모델). Controller를 빼고 ViewModel을 추가한 패턴입니다. 여기서 View Controller가 View가 되고, ViewModel이 중간 역할을 합니다. View와 ViewModel 사이에 Binding(바인딩-연결고리)가 있습니다. ViewModel은 Model에 변화를 주고, ViewModel을 업데이트하는데 이 바인딩으로 인해 View도 업데이트됩니다. ViewModel은 View에 대해 아무것도 모르기 때문에 테스트가 쉽고 바인딩으로 인해 코드 양이 많이 줄어듭니다.import Foundation // ViewModel var gameScore: Int? var gameScoreLabel: UILabel func updateGameScoreLabel() {   var text = ""   if let gameScore = gameScore, gameScore == 100 {       text = "Excellent!!"   } else if let gameScore = gameScore, gameScore >= 90 && gameScore < 100>       text = "Great Job!"   } else if let gameScore = gameScore, gameScore < 90>       text = "Not Bad~"   }   gameScoreLabel.text = text } // View Controller gameScoreLabel.text = viewModel.updateGameScoreLabel간단한 예를 들면, 게임 점수에 따라서 textView에 보여줄 내용을 담당하는 함수 등, View에서 변화가 일어나는 함수들이 View Controller에 정의되어 사용하는 경우가 많을 겁니다. 이런 함수들이 점점 많아지면 View Controller가 Massive, 많은 코드를 담게 됩니다. 그래서 이런 함수들을 ViewModel에 옮기고, 값들을 미리 세팅한 다음에 view controller에서 viewModel을 선언하고 viewModel의 함수를 불러오는 식으로 사용하면 됩니다. 매우 간단한 예제이기 때문에 대략 viewModel과 view controller에서 어떻게 사용하는지만 보시면 될 것 같습니다. 이 패턴은 주로 Reactive programming(ReactiveCocoa, RxSwift 등)을 할 때 많이 사용하는 패턴이어서 다음에 설명하겠습니다.VIPERVIPER 패턴View(뷰), Interactor(인터렉터), Presenter(프리젠터), Entities(엔티티), Router(라우터). MV(X) 패턴과 다른 패턴으로 MVC 패턴을 대체하기 위해 만들어진 패턴입니다. 먼저 Entity는 그저 모델 객체입니다. 단순하게 어떤 모델의 속성들만 있는, Dumb Model이라고 부를 수 있습니다. 이 모델 객체를 조작하는 것이 바로 Interactor입니다. 어떤 행동(behavior or use case)에 따라서 모델 객체를 조작하는 로직이 담겨 있습니다. 작업이 완료되어도 View에 아무런 영향 없이 오로지 데이터 작업만 합니다.Presenter는 데이터를 Interactor에서 가져오고, 언제 View에 보여줄지 결정합니다. View에 보여주기 전 내용을 준비하는 로직을 담당한다고 생각하면 됩니다. View는 Presenter에서 어떻게 보여줘야 할지 요청대로 디스플레이하고, 사용자의 입력을 받으면 다시 Presenter로 넘깁니다. Presenter는 View/ViewController, Interactor, Router와 상호작용합니다. Interactor로부터 조작된 데이터를 가져오고, 디스플레이하기 위해 데이터들을 준비한 다음 View/ViewController에 보냅니다.Router 또는 Wireframe은 화면 전환(navigation information)을 담당합니다. Presenter가 “언제” 화면을 전환해야 하는지 안다면, Router는 화면 전환을 “어떻게” 하는지 알고 있습니다. Router는 화면 전환 애니메이션을 구현하고, View Controller를 생성하여 Presenter와 연결합니다.항목내용ViewPresenter의 요청대로 디스플레이하고, 사용자 입력을 Presenter로 보내는 작업을 합니다.InteractorUse case에 따라서 Entity 모델 객체를 조작하는 로직을 담고 있습니다.PresenterInteractor로부터 데이터를 가져오고, View로 보내기 위해 데이터를 준비하여 “언제” View에 보여줄지를 결정합니다.Entity모델 객체. Dumb Model.Router(Wireframe)화면 전환(navigation information)을 담당하며, Presenter가 “언제” 화면 전환해야하는지를 안다면, Wireframe은 화면 전환을 “어떻게” 하는지를 알고 있습니다.하...지금까지 설명한 내용들은 막상 프로젝트 만들어 소스를 작성하려고 하면 막막해집니다. 역할이 잘 분할되어 있기에 앱의 기능을 하나 정하여 interactor, entity, presenter, view, router 만들고, 또 앱의 기능에 따라서 다시 interactor, entity,…. 고민을 많이 해야 해서 다시 MVC 패턴으로 돌아가고 싶은 마음이 생깁니다.크게 보면 Add Module와 List Module, 그리고 공통적인 모델(데이터)을 잘 분리한 앱 구조Conclusion도대체 우리는 왜 다양한 앱 디자인 패턴을 알아야 할까요? 그 이유는 바로 앱의 특성에 따라 적합한 설계를 가지고 작업해야 하기 때문입니다. 간단한 앱 프로젝트는 쉽게 개발하고 적용할 수 있는 MVC 패턴이 더 적합합니다. 반대로 MVVM 패턴이나 VIPER 패턴을 적용하면 점점 커지는 앱 프로젝트에 잘 대응할 수 있습니다. 또는 어떤 디자인 패턴이 적용된 앱 프로젝트에 참여하면, 그 디자인 패턴에 대해 알아야 앱 구조를 이해하고 기능을 추가하거나 수정할 수 있고, 작업하는 시간을 줄일 수 있을 겁니다.가장 좋은 패턴은 사람마다 차이가 있습니다. 패턴마다 장단점도 있습니다. 다만 어떤 패턴이든지 간에 구조화되고 정리된 코드는 쉽고, 직관적입니다. 이 글 하나만으로 앱 패턴을 완벽하게 마스터할 수는 없어도 패턴의 종류와 특징을 알게 되었다면 본전입니다. 다음 편도 기대해주세요! :-) 도움말 1) View Controller에서는 Controller가 View의 life cycle(라이프 사이클)에 관여하기 때문에 View와 Controller를 분리하기 어렵습니다. 개발자들 사이에서는 Massive View Controllers라고도 불립니다. 앱을 테스트할 때, Model은 따로 분리되어 테스트를 할 수 있어도 View와 Controller는 강하게 연결되어 있기 때문에 각각 테스트하기 어렵습니다. 참고문헌 iOS Architecture Patterns: Demystifying MVC, MVP, MVVM and VIPER글김주희 사원 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유 #iOS
조회수 2514

JANDI 검색엔진 도입기

이번 포스트에서는 JANDI가 검색엔진을 도입하게 된 배경과 어떤 작업을 했는지 공유하려고 합니다검색엔진 도입 배경JANDI는 사용자가 입력한 메시지를 검색하고 사용자가 올린 파일의 파일명/파일 타입을 검색하는 메시지/파일 검색 기능을 제공하고 있습니다. 데이터 저장소로 MongoDB를 사용하고 있는데 검색되는 필드에 인덱스를 걸고 정규 표현식을 이용하여 DB Like 검색(“DB는 검색을 좋아한다”아니에요;;)을 하고 있습니다.초기에는 데이터가 아담했는데, 서비스가 커감에 따라 사용자 증가하면서 생성되는 데이터도 많아졌습니다. 올 초에 데이터가 많아지면서 검색이 DB에 부하를 주고, JANDI 서비스에도 영향을 주게 되었습니다. 그래서 JANDI 서비스용 MongoDB와 검색 전용 MongoDB를 분리했는데 이는 임시방편이었고 언젠가는 꼭 검색엔진을 도입하자며 마무리를 지었습니다.시간은 흘러 흘러 4월이 되었습니다. 당시 메시지 증가량을 봤을 때 올해 안에 검색엔진을 사용하지 않으면 서비스에 문제가 될 거라고 판단이 되어 도입을 진행하게 되었습니다.검색엔진 도입의 목표는 다음과 같았습니다.현재 DB Like 검색과 비슷한 검색 품질이어도 좋다. (일정때문에)검색엔진 도입을 통해 검색이 JANDI 서비스에 영향을 주지 않도록 한다.색인을 위해서 주기적으로 JANDI의 MongoDB 데이터를 가져 와야 했지만, 이 작업이 JANDI 서비스에 큰 부하를 주지 않을 거라고 생각했습니다.검색엔진 후보로는 Solr, ElasticSearch, CloudSearch, ElasticSearch Service 가 있었는데 Solr를 선택했습니다.왜냐하면제가 경험한 검색엔진이 Solr 였습니다. 더군다나 2010년 초에 접했던 Solr 비해 많이 발전한 것 같아 개발자로서의 열정과 도전 욕구가 샘솟았습니다. SolrCloud pdf, WhyNoWarAWS에서 제공하는 검색 서비스는 많은 부분을 관리해준다는 면에서 솔깃했지만, Custom Analyzer는 적용할 수 없어서 선택하지 않았습니다.ElasticSearch에 크게 흔들렸지만 경험이없다 보니 공부하면서 프로젝트를 진행한다는 부담감이 커서 다음을 기약했습니다.작업 내용1. MongoImporter, Sharding. MongoImporter 수정현재 JANDI는 MongoDB를 데이터 저장소로 사용하고 있습니다. MongoDB의 데이터를 색인하기 위해 데이터를 검색엔진으로 가져와야 하는데 Solr에서는 DataImportHandler 기능을 제공하고 있습니다. 기본 DataImportHandler로 RDB 데이터는 가져올 수 있지만 이 외 MongoDB나 Cassandra 같은 NoSQL의 데이터를 가져오기 위해서는 따로 구현이 필요합니다. 구글신에게 물어봐서 SolrMongoImporter 프로젝트를 찾았는데 문제가 있었습니다. mongo-java-driver 버전이 낮아서(2.11.1) 현재 JANDI에서 서비스 되고 있는 MongoDB(3.0.x)의 데이터를 가져올 수 없었습니다.url: Reference compatibility MongoDB Java2.11.1에서 3.2.2로 버전을 올리고 변경된 api를 적용하는 작업, 빌드 툴을 ant에서 maven으로 변경하는 작업을 하였습니다. 마음의 여유가 된다면 P/R을 할 계획입니다.여담으로 DataImportHandler 작업과 함께 검색 schema 정하는 작업을 했는데 sub-document 형식이 필요하게 되었습니다. Solr 5.3부터 nested object를 지원한다는 article을 보았는데, nested object 지원 얘기를 보니 Solr도 text search 뿐 아니라 log analysis 기능에 관심을 가지는건 아닐까 조심스레 생각해봤습니다. (역시나… 이미 banana, silk 같은 프로젝트가 있습니다. Large Scale Log Analytics with Solr 에 관련된 이야기를 합니다.). Sharding. 그리고 Document Routing대량의 데이터를 처리하기 위해 한 개 이상의 node로 구성된 데이터 베이스에 문서를 나누어 저장하는 것을 sharding이라고 합니다. SolrCloud는 shard 생성/삭제/분리할 수 있는 API가 있고, 문서를 어떻게 나눌지 정할 수 있습니다. 어떻게 나눌지는 shard 생성 시 router.name queryString에 개발한 router 이름을 적어주면 됩니다. 그렇지않으면 Solr에서 murmur Hash 기반으로 문서를 나누는 compositeId router를 사용합니다. JANDI의 검색 기능은 Team 단위로 이루어지기 때문에 TeamId를 기준으로 문서를 나누기로 하고, compositeId Router를 사용했습니다. 실제 서비스의 문서 데이터를 색인 돌려서 각 node에 저장되는 문서 개수나 메모리/디스크 사용량을 확인했는데 다행히도 큰 차이가 나지 않았습니다.하나의 문서는 TeamId와 MessageId를 조합한 “TeamId + ! + MessageId” 값을 특정 field에 저장하고 해당 필드를 uniqueKey 지정했습니다. 간단한 수정으로 문서 분배가 되는점이 좋았고, 더 좋았던건 검색시 _route_ 를 이용해서 실제 문서가 존재하는 node에서만 검색을 한다는 점이 었습니다. 4년 전 제가 마지막으로 Solr를 사용했을 때는 사용자가 직접 shards queryString에 검색할 node를 넣어주어야 했습니다..../select?q=\*:\*&shards=localhost:8983/solr/core1,localhost:8984/solr/core1SolrCloud RoutingSolrCloud Routing2Multilevel CompositeId2. analyzer, queryParser. analyzerSolr에 기본으로 있는 text_cjk analyzer를 사용하였습니다. <!-- normalize width before bigram, as e.g. half-width dakuten combine --> <!-- for any non-CJK --> text_cjk는 영어/숫자는 공백/특수기호 단위로 분리해주고 cjk는 bigram으로 분리해주는 analyzer 입니다. analyzer는 이슈 없이 완성될 거라 생각했지만 오산이었습니다. 텍스트가 들어오면 token을 만들어주는 StandardTokenizerFactory 에서 cjk와 영어/숫자가 붙어있을 때는 분리하지 못해 원하는 결과가 나오지 않았습니다. 또한 특수기호중에 ‘.’(dot), ‘_‘(underscore)가 있을 때에도 분리하지 못했습니다.nametextInputTopic검색개선_AB1021_AB제시CD.pdfStandardTokenizerFactoryTopic검색개선_AB1021_AB제시CD.pdfCJKWidthFilterFactoryTopic검색개선_AB1021_AB제시CD.pdfLowerCaseFilterFactorytopic검색개선_ab1021_ab제시cd.pdfCJKBigramFilterFactorytopic검색개선_ab1021_ab제시cd.pdf원하는 결과topic 검색개선 ab 1021 ab 제시 cd pdf그래서 색인/검색 전에 붙어있는 cjk와 영어/숫자사이에 공백을 넣어주고 ‘.’와 ‘_‘를 공백으로 치환해주는 작업을 하였습니다. 색인은 Transform에서 처리하고 검색은 다음에 알아볼 QParserPlugin에서 처리했습니다.nametextInputTopic검색개선_AB1021_AB제시CD.pdfTransform 단계Topic 검색개선 AB 1021 AB 제시 CD pdfStandardTokenizerFactoryTopic 검색개선 AB 1021 AB 제시 CD pdfCJKWidthFilterFactoryTopic 검색개선 AB 1021 AB 제시 CD pdfLowerCaseFilterFactorytopic 검색개선 ab 1021 ab 제시 cd pdfCJKBigramFilterFactorytopic 검색개선 ab 1021 ab 제시 cd pdf※ 추가 : 검색 결과를 보여줄때 어떤 키워드가 매칭되었는지 Highlight 해야했는데, 색인하기 전에 원본을 수정을 해서 Solr에서 제공하는 Highlight를 사용하지 못하게 됐습니다. 눈 앞의 문제만 바라보고 해결하기 급급했던 저를 다시금 반성하게 되었습니다.. queryParser앞에서도 언급하였지만, 색인뿐만 아니라 검색할 때도 검색어가 입력되면 검색하기 전에 붙어있는 cjk와 영어/숫자를 분리하고 ‘.’, ‘_‘를 공백으로 치환해주는 작업이 필요합니다. Solr에서 기본으로 사용하는 LuceneQueryParserPlugin 을 수정하였습니다.@Override public Query parse() throws SyntaxError { // 수정한 코드 String qstr = splitType(getString()); if (qstr == null || qstr.length() == 0) return null; String defaultField = getParam(CommonParams.DF); if (defaultField == null) { defaultField = getReq().getSchema().getDefaultSearchFieldName(); } lparser = new SolrQueryParser(this, defaultField); lparser.setDefaultOperator (QueryParsing.getQueryParserDefaultOperator(getReq().getSchema(), getParam(QueryParsing.OP))); return lparser.parse(qstr); } QParserPlugin3. DataImportHandler manageMongoImporter에서도 얘기했지만 Solr에서는 DB 데이터를 가져오는 DataImportHandler 기능을 제공 하고 있습니다. DataImportHandler Commands를 보면 총 5개의 명령을 제공하고 있는데, 그중 색인을 실행하는 명령은 full-import와 delta-import입니다. full-import 명령은 DB의 모든 데이터를 색인 하는 것을 말합니다. 색인 시작할 때의 시간을 conf/dataimport.properties에 저장하고 이때 저장한 시간은 delta-import 할때 사용됩니다. 전체 색인한다고 말합니다. delta-import 명령은 특정 시간 이후로 생성/삭제된 데이터를 색인 하는 것을 말합니다. 특정 시간이란 full-import 시작한 시간, delta-import가 최근 종료한 시간을 말합니다. full-import와는 다르게 delta-import가 종료된 시간을 conf/dataimport.properties에 저장합니다. 증분 색인 혹은 동적 색인이라고 하는데 여기서는 증분 색인이라고 얘기하겠습니다. 두 명령을 이용하여 JANDI의 메시지/파일을 색인 하기 위한 삽질 경험을 적었습니다.. 첫 번째 삽질full-import는 현재 active인 데이터를 가져올 수 있도록 query attribute에 mongo query를 작성하고, delta-import 는 특정 시간 이후에 생성된 데이터를 가져올 수 있도록 deltaQuery attribute에 mongo query를 작성합니다. 또한 deltaQuery로 가져온 id의 문서를 가져올 수 있도록 deltaImportQuery attribute에 mongo query를 작성하고, 특정 시간 이후에 삭제된 데이터를 가져올 수 있도록 deletedPkQuery 에도 mongo query를 작성합니다.<!-- data-config.xml --> <?xml version="1.0" encoding="UTF-8" ?> 정상적으로 동작은 했지만, 색인 속도가 실제 서비스에 적용하기 힘들 정도였습니다. 실행되는 mongo query를 확인했는데 다음과 같이 동작하였습니다.특정 시간 이후에 생성된 데이터를 색인하기 위해 약 (새로 생성된 문서개수 + 1) 번의 mongo query가 실행되었습니다. (batch size와 문서 갯수에 따라 늘어날 수도 있습니다.) 메신저 서비스 특성상 각각의 문서 크기는 작지만 증가량이 빠르므로 위 방식으로는 운영 할 수 없었습니다. 그래서 delta-import using full-import 를 참고해서 두 번째 삽질을 시작 하였습니다.. 두 번째 삽질full-imoprt 명령을 실행할 때 clean=false queryString을 추가하고 data-config.xml query attribute를 수정하는 방법으로 증분 색인 하도록 수정했습니다. 특정 시간 이후 생성된 문서를 가져오는 attribute인 deltaQuery와 deltaImportQuery 는 필요가 없어 지웠습니다.<!-- data-config.xml --> <?xml version="1.0" encoding="UTF-8" ?> <!-- if query="" then it imports everything --> 전체 색인은 /dataimport?command=full-import&clean=true 로 실행하고, 증분 색인은 /dataimport?command=full-import&clean=false(생성된 문서)와 …/dataimport?command=delta-import&commit=true(삭제된 문서)로 실행하도록 했습니다.정상적인 것 같았지만, 문제가 있었습니다.full-import, delta-import 명령을 실행하면 conf/dataimport.properties 파일에 전체 색인이 실행한 시작 시각 혹은 증분 색인이 최근 종료한 시간이 “last_index_time” key로 저장됩니다. 첫 번째 삽질에서 증분 색인시 delta-import 명령 한 번으로 생성된 문서와 삭제된 문서를 처리했지만, full-import와 delta-import 두개의 명령으로 증분 색인이 동작하면서 생성된 문서를 처리할 때도 last_index_time이 갱신되고 삭제된 문서를 처리할 때도 last_index_time이 갱신되었습니다.예를 들면증분색인 동작이 1분마다 삭제된 문서를 처리하고, 5분마다 생성된 문서를 처리 한다고 가정해보겠습니다. 3시 13분 14초에 delta-import가 완료되어 last_index_time에 저장되고, 다음 delta-import가 실행되기 전 3시 13분 50초에 full-import가 완료되어 last_index_time이 갱신되었다면, 3시 13분 14초부터 3시 13분 50초 사이에 삭제된 문서는 처리를 못 하는 경우가 발생합니다.Solr에서 dataimport.properties에 기록하는 부분을 수정하는 방법과 전체/증분 색인을 동작시키는 Solr 외부에서 특정 색인 시간을 관리하는 방법이 있었는데 Solr를 수정하는 건 생각보다 큰 작업이라 판단되어 외부에서 관리하는 방법으로 세 번째 삽질을 시작하였습니다.. 세 번째 삽질전체/증분 색인을 주기적으로 동작 시키는 곳에서 full-import&clean=false(생성된 문서) 처리할 때 필요한 마지막으로 색인 된 문서 id와 delta-import(삭제된 문서) 처리할 때 필요한 마지막으로 색인 된 시간을 관리하도록 개발하였습니다. 증분 색인 시 full-import&clean=false를 실행하기 전에 현재 색인 된 마지막 id 조회 후 해당 id보다 큰 데이터를 처리하도록 하였고, delta-import를 마지막으로 마친 시간을 따로 저장하다가 delta-import 실행 시 해당 시간을 전달하는 방법으로 수정하였습니다.<!-- data-config.xml --> <?xml version="1.0" encoding="UTF-8" ?> 마치며튜닝의 끝은 순정이라는 말이 있는데 IT 기술은 예외인 것 같습니다. 현재는 Solr의 기본 기능만으로 구성했지만, 고객에게 더 나은 서비스를 제공할 수 있는 시작점으로 생각하고, JANDI 서비스에 맞게 끊임없이 발전해나가겠습니다.감사합니다.참고Getting Started with SolrApache Solr 5.5.0 Reference Guide PDFApache Solr 6.1 - Analyzers, Tokenizers and FiltersRebalance API for SolrCloud issueYonik Blog#토스랩 #잔디 #JANDI #개발자 #개발팀 #개발후기 #인사이트
조회수 775

Android Wear 개발하기

비트윈 팀은 지난달 비트윈에 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이라 하겠습니다.↩저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!
조회수 1343

레진 기술 블로그 - 모두를 위한 설계. 레진 웹 접근성 가이드라인.

레진엔터테인먼트는 글로벌(한국, 일본, 미국) 서비스를 운영하고 있기에 다양한 사람들의 재능과 욕구에 관심이 있습니다. 우리는 웹 접근성에 관심을 기울여 조금 특별한 욕구를 가진 사람들의 문제를 해결하려고 합니다. 소수의 특별한 욕구는 모두의 욕구와 연결되어 있다고 생각하기 때문입니다.조금 특별한 욕구를 가진 사람WHO는 세계 인구의 15%에 해당하는 사람들이 장애가 있는 것으로 파악하고 있습니다. 그리고 보건복지부 장애인 실태조사에 따르면 후천적 장애 발생률은 90% 수준입니다. 이런 통계에 따르면 한 개인이 일생을 살면서 장애인이 되거나 일시적으로 장애를 체험하게 될 확률은 무려 13.5%나 됩니다.저는 적록 색약입니다. 약한 수준의 장애로 분류할 수 있죠. 채도가 낮은 상태의 적색과 녹색을 쉽게 구별하지 못합니다. 충전 중 적색이었다가 완충이 되면 초록색으로 변하는 LED가 박혀있는 전자제품은 전부 망했으면 개선하면 좋겠어요. 전 세계 남성의 8%가 색약이고, 여성은 0.5%가 색약입니다. 대부분 적록 색약이고 마크 저커버그도 적록 색약입니다. 만화가 이현세 선생님도 적록 색약이고요. 한편 색약인 사람은 빛의 밝고 어두움을 구별하는 능력이 뛰어난 것으로 밝혀져 있어 저격과 관측에 탁월한 능력을 발휘합니다. 숨어있는 저격수 빨리 찾기 게임을 해 보세요. 위장 사진 1, 위장 사진 2, 위장 사진 3. 색약인 사람이 이길 것입니다.전맹 시각장애인은 마우스 포인터와 초점을 볼 수 없으므로 키보드만을 사용해서 웹을 탐색합니다. 키보드와 음성 낭독에 의존하지만, 키보드 기능을 정말 잘 다루죠. 그래서 키보드 접근성 문제를 해결하면 시각장애인뿐만 아니라 키보드를 능숙하게 사용하는 사람들의 사용성이 높아집니다. 소수의 특별한 요구사항을 해결하는 것이 모두를 위한 설계와 연결되어 있습니다.결국, 누구에게나 특별히 다른 측면이 있고 그것을 고려할 때 "모두를 즐겁게 하라!"라는 우리의 좌우명에 한 걸음 더 가까워질 수 있다고 믿습니다.도저히 풀 수 없을 것 같은 숙제웹 접근성을 소개할 때 많이 듣는 질문이 있습니다.장애인이 우리 서비스를 이용해요?매출에 도움이 돼요?시간과 비용이 많이 필요하지 않아요?이 질문에 대한 제 대답은 다음과 같습니다.이용한다면 기쁠 것 같아요.큰 도움은 안 될 거예요.조금은 그렇죠. 하지만 반환이 있어요.레진코믹스와 같이 이미지 기반의 콘텐츠를 서비스하는데 웹 접근성을 준수하려고 노력한다는 것은 무모한 도전에 가깝습니다. 왜냐하면, 현재로서는 전맹 시각장애인 고려가 없고 논의조차 쉽지 않기 때문입니다.하지만 달에 갈 수 없다고 해서 일찌감치 체념할 필요는 없겠지요. 쉬운 문제부터 하나씩 풀어 나아가길 기대합니다. 로켓에 올라탔으니까 금방 갈 수 있지 않을까요?W3C 표준을 우리 언어로W3C에서는 WCAG 2.1이라는 웹 콘텐츠 접근성 지침을 제시하고 있고요. 국내 표준 KWCAG 2.1 또한 있습니다. 국내 표준은 W3C 표준에서 중요도가 높은 항목을 우리 언어로 정리한 것이기 때문에 결국 어떤 지침을 선택해서 따르더라도 괜찮습니다.하지만 표준 문서는 너무 장황하고 전문 용어가 많아 다양한 분야 전문성을 가진 직원들과 함께 보기에는 한계가 있다고 생각했습니다. W3C 표준을 근간으로 하되 비전문가도 15분 정도면 읽고 이해할 수 있을 만큼 정리된 문서가 필요했고 레진 웹 접근성 가이드라인 사내 표준을 제안하고 공개하게 됐습니다.의미를 전달하고 있는 이미지에 대체 텍스트를 제공한다.전경 콘텐츠와 배경은 4.5:1 이상의 명도 대비를 유지한다.화면을 400%까지 확대할 수 있다.키보드만으로 조작할 수 있다.사용할 수 있는 충분한 시간을 제공한다.발작을 유발하는 콘텐츠를 제공하지 않는다.반복되는 콘텐츠 블록을 건너뛸 수 있다.모든 문서의 제목은 고유하고 식별할 수 있다.링크와 버튼 텍스트는 콘텐츠의 목적을 알 수 있다.섹션에는 의미있는 마크업과 헤딩이 있다.문서의 휴먼 랭귀지 속성을 제공한다.문맥 변경은 예측할 수 있다.폼 콘트롤 요소에 설명을 제공한다.실수를 예방하고 정정하는 것을 돕는다.HTML 문법을 준수한다.WCAG 2.1 지침의 1.1.1 항목 예를 들어 볼게요.All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. 사용자에게 제공되는 모든 텍스트 아닌 콘텐츠는 아래 나열된 상황을 제외하고 같은 목적을 수행하는 대체 텍스트를 제공한다.원문 표현보다 아래와 같이 다듬은 표현이 좋다고 보는 것이죠.의미를 전달하고 있는 이미지에 대체 텍스트를 제공한다.물론 사내 지침은 너무 단순하게 표현했기 때문에 지침마다 ‘부연 설명, 관련 예시, 기대 효과, 관련 표준, 평가 도구’ 텍스트와 링크를 간략하게 제공하고 있습니다. 사실상 W3C 표준에 대한 링크 페이지라고 생각해도 괜찮습니다. 사실이 그런걸요.맺음말레진 웹 접근성 가이드라인은 사내 유관 부서 담당자분들께 공유하고 동의를 얻어 사내 지침으로 결정하고 공개할 수 있게 됐습니다. 긍정적으로 검토해 주신 사우님들 감사합니다.레진 웹 접근성 가이드라인은 W3C 표준을 요약한 버전에 불과하므로 누구라도 복제(Fork), 개선 요청(Pull Requests), 문제 제기(Issues)할 수 있습니다."Design for all, amuse everyone!"
조회수 4889

“디자인과 기술을 이어주는 존재, 마크업 개발자를 함께 알아볼까요?” - 유저플로우셀 오혜진

'마크업 개발자', 아직은 우리들에게 다소 생소한 직군이죠. '마크업 개발자'는 디자이너와 개발자 사이에서 '오작교' 같은 역할을 하는 아주 중요한 포지션이에요. 오늘은 코인원의 마크업 개발자로 활약 중인 혜진님과 이야기를 나눠보려 해요. 자신의 위치에서 묵묵히 유저 친화적인 웹 환경을 만들어나가고 있는 혜진님을 만나러 가보시죠!사실 이미 혜진님은 지난 4월 13일(토), 테크 업계 여성들의 목소리에 집중하는 소중한 행사 ‘Women Techmakers Seoul 2019’에서 ‘스타트업에서 마크업 개발자로 살아남기’를 주제로 자신의 이야기를 널리 알리고 왔답니다. 스타트업 그리고 코인원에서 마크업 개발자로 살아남는 혜진님만의 방법은 무엇일까요? :-)Q. 혜진님 안녕하세요, 자기소개 부탁드립니다.안녕하세요, 코인원 유저플로우셀에서 마크업 개발자로 일하고 있는 오혜진입니다. 유저플로우셀은 암호화폐 거래와 프로차트와 같은 트레이딩 영역을 제외한 전반적인 서비스 영역을 담당하고 있어요. 특히 ‘셀'이라는 목적조직으로 개편된 이후 PM, 디자이너, 개발자가 한곳에 모여 누구나 코인원에서 거래를 하고 싶은 마음이 들도록 매력적인 곳으로 탄생시키고 있답니다. 저는 셀안에서 마크업 개발자로 일하며 디자이너와 프론트엔드 개발자를 이어주는 다리 역할을 하고 있습니다.Q. 지난 ‘Women Techmakers Seoul 2019’에서 마크업 개발자를 널리 알리는 발표를 했다고 들었어요. 어떤 내용인지 소개해주세요!감사하게도 ‘스타트업에서 마크업 개발자로 살아남기' 라는 주제로 300명이 넘는 관중들 앞에서 발표를 하고 왔습니다. (사실, 많은 분들이 와주셔서 땀이 좀 나기도 했고요;) 마크업 개발자는 스타트업에서 발견하기 힘든 직군이기도 해요. 보통은 웹 에이전시에 많이 속해 있거든요. 제가 마크업 개발자로 일한지 6년이라는 시간 동안 스타트업에서 어떤 방식으로 일해왔는지 알리고 싶었어요. 그래서 지금까지 이런 일들을 해왔고, 앞으로도 더 활발하게 할 것이라고 속시원하게 말하고 왔습니다.Q. 마크업 개발자는 구체적으로 어떤일들을 하나요?마크업 개발자는 한마디로 디자인(Design)과 기술(Tech)의 오작교 같은 존재입니다. 디자인의 의도가 개발과 충돌하는 부분은 없는지 파악하고, 개발에 잘 녹아들 수 있도록 프론트엔드의 앞단을 맡고 있어요. 코인원 웹 서비스에서 제공하는 신규 기능의 마크업 개발을 담당하고, 운영하면서 생긴 이슈들을 처리합니다. 또한 마크업 레거시에 대한 유지보수 작업도 병행하죠.예를 들어, 코인원의 회원가입 페이지를 제작할 때 디자인 작업을 먼저 들어갑니다. 그럼 디자인 작업을 바탕으로 개발자들이 기능을 만들어 넣게 돼요. 이 때, 기능적인 개발을 제외하고 UI(User Interface)적인 부분을 제가 담당합니다. 회원가입 페이지에는 이메일 인증, 휴대폰 인증 등 여러가지 개발요소들이 많아요. 그래서 개발하기 전에 기능이 들어가는 기본적인 레이아웃을 만들어 개발자에게 전달합니다. 마크업 작업이 바탕이 되어 그 위에 기능 개발이 이뤄진다고 보시면 돼요.디자이너가 레시피를 만드는 사람이라면, 마크업 개발자는 레시피 재료를 세팅해 주는 사람이에요. 개발자들은 세팅된 레시피를 끓이고 버무려 요리를 완성시키고요. 저는 좋은 요리가 탄생할 수 있도록 중간과정을 도와주는 역할인거죠. ▲ 'Women Tachmakers 2019'에서 발표에 열중한 혜진님!Q. 디자인과 기술의 중간 역할을 담당하고 계시군요, 사실 중간자의 역할이라고 하면 이어주는 과정에서 고충(?)이 생길 것 같아요.아무래도 디자이너와 개발자, 양쪽과 다 소통해야하는 부분입니다. 디자이너 입장에서는 ‘왜 프론트엔드에서 이 디자인이 안되는걸까?’ 라는 불만이 생길때도 있고, 프론트엔드에서는 ‘왜 디자인이 이렇게 들어가야 하는걸까?’ 라고 이해를 못할 때도 있어요. 서로의 이해관계를 잘 전달해야 한다는 점이 나름의 고충이죠. 코인원에서는 ‘디자이너 - 마크업 개발자 - 프론트 개발자’의 협업 프로세스를 정립해서 각자가 맡은 분야에 집중 할 수 있는 초석을 다졌어요. 무엇보다도 배경이 다른 세 개의 직군이 원활하게 소통할 수 있는 체계가 잡혀 고충이 해결되고 있습니다 :) Q. 그렇다면 마크업 개발자는 어떤 부분을 기여한다고 볼 수 있나요?코인원 메인 화면에 기능 개발을 추가하지 않고도 마크업단에서의 처리만으로도 쉽게 변화를 줄 수 있습니다. 메인화면의 배너 이미지는 유저들이 코인원에 접속해 제일 먼저 마주하는 부분이죠. 그래서 유저들이 코인원의 시각화된 정보를 빠르게 접할 수 있도록 이미지를 교체합니다. 웹 페이지의 운영 측면에서 비주얼 개편을 빠르게 할 수 있는 환경을 만들어 놓고 대응하는거에요.곧 코인원 마이페이지 화면이 개편될겁니다. 웹 페이지를 새로 만든다는 것은 무에서 유를 창조하는 과정과 같아요. 제가 마크업 개발을 잘 해놓으면 다른 직군에게도 도움이 됩니다. 개발 속도도 더 잘 붙고, 디자인에서도 빈공간이 없는 페이지가 탄생하는거죠. 최대한 밑바탕을 꼼꼼하게 만들어 모두가 일에 더 집중할 수 있는 환경을 만든다고 보시면 돼요.Q. 코인원 마이페이지에서 새롭게 바뀌는 부분은?기존의 마이페이지는 유저들이 보기에 정리가 잘 안되어있다는 느낌이 있었어요. 어떤 인증과정을 끝마쳐야 하는지 한눈에 들어오지 않는 부분이 있었거든요. 이번에 개편될 마이페이지는 좀 더 명확해졌습니다. 이전의 인증페이지가 도돌이표의 느낌이었다면, 이번에는 UX(User experience)를 생각해서 flow 개선도 많이 이뤄졌습니다. 편리한 암호화폐 거래 경험을 코인원에서 느낄 수 있어요. (새롭게 바뀔 마이페이지 많은 기대 부탁드립니다! 물론 편리한 암호화폐 거래도 언제나 코인원!)Q. 유저들에게 편리한 거래경험을 선사하기 위해 어떤 가치를 가장 중요시 여기나요? 저는 중간자이므로 유저들 뿐만 아니라 개발까지 두 가지 측면을 모두 고려합니다. 유저의 입장에서 사용성과 접근성이 용이한 마크업을 짜려고 하고, 개발측면에서는 유지보수가 편리한 마크업을 최대한 짜려고 해요. 개발하기 편한것과 사용하기 편한 것은 다른 맥락이거든요. 요새는 코인원 디자인시스템을 적용하고 있어요. 디자이너 분들이 정리해주신 디자인 시스템을 잘 적용시켜서 코드적으로도 재사용성이 용이하게 관리가 되도록 하고, UI도 정돈이 되어가는 과정을 진행 중입니다. 이런 과정을 계속 거치면 유저들에게 편리한 거래 경험을 선사하는 부분은 놓치지 않을 것 같아요.▲ 마크업에 열중하고 있는 혜진님 (약간의 설정샷 +_+)Q. 코인원 크루로 일하면서 장점을 뽑자면?유저플로우셀은 코인원이 셀이라는 목적조직으로 개편되고나서 만족도가 높은 셀이라고 알고 있어요. 업무도 많은 편인데, 톱니바퀴처럼 잘 맞물린다는 느낌이거든요. 특히 일에 대해서 선긋지 않고, 이슈가 발생했을 때 해결할 수 있는 부분들을 빠르게 파악해주는 부분들이 정말 좋아요. 속도랑 효율성 측면에서 이만큼 해낼 수 있는 팀은 앞으로 만나지 못할 것 같아요. 항상 원활한 업무 소통을 위해 힘써주시는 셀원들에게 감사 드립니다!Q. 앞으로 이루고 싶은 목표가 무엇인가요?회사 안 뿐만 아니라, 바깥에서의 활동도 꿈꾸고 있어요. 마크업 개발자들이 모두 모여 이야기할 수 있는 CSS 컨퍼런스를 열어 좀 더 커뮤니티를 활성화 시키고 영향력을 높이고 싶습니다. 아직 마크업 개발자들만이 모여서 이야기 할 수 있는 곳이 부족하거든요. 저의 이야기도 차곡차곡 쌓아서 여러 창구를 통해 들려드리고 싶고요.코인원에서는 지금 하는 것 이상으로 마크업 개발도 열심히 할거에요. 우선 단기적인 목표로, 프론트엔드에서 사용하고 있는 angular에 대한 이해력을 높일 겁니다. 마크업 컴포넌트 단위에 최적화 된 CSS로 개편해서 사용하지 않는 스타일 리소스가 최소화가 되도록 만들거에요.▲ 마크업 개발자에 많은 관심 부탁드려요 :)디자이너가 디자인에 집중할 수 있게, 개발자가 개발에 집중할 수 있게 ‘일잘러’로 통한다는 혜진님. 혜진님의 인터뷰를 통해 ‘마크업 개발자’에 좀 더 친해지는 시간이길 바라봅니다. 그리고 이렇게 멋진 코인원 크루와 함께 성장하고 싶지 않으세요?  현재 코인원은 멋진 크루들과 함께 크립토갤럭시를 헤쳐나갈 분들을 기다리고 있습니다 :-)
조회수 2151

스켈티인터뷰 / 스켈터랩스의 스테로이드 서종훈 님을 만나보세요:)

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 스테로이드 서종훈 님을 만나보세요:)사진1. 스켈터랩스 스테로이드 서종훈 님Q. 진부한 첫 번째 질문, 자기소개를 부탁한다.A. 스켈터랩스에서 소프트웨어 엔지니어로 일하고 있는 서종훈이다. 연세대학교 컴퓨터과학과에서 HCI(Human-computer interaction)와 컴퓨터 비전(Vision)쪽 연구로 박사 학위를 받았다. 그리고 L모 기업의 AI연구소에서 일을 하다가 최근 스켈터랩스에 입사했다.Q. 어떻게 스켈터랩스에 입사하게 되었는지 궁금하다.A. 지인을 통해서 스켈터랩스의 여러가지 프로젝트에 대해 듣게 되었다. 스켈터랩스의 Inno Lab에서 진행 중인 프로젝트가 HCI와 가장 연관성이 깊고, 재미있는 디바이스를 구현하고 있어서 눈여겨 보다가 입사를 지원했다. 물론 프로젝트의 방향성이 나의 관심 분야와 일치하는지 뿐만 아니라, 함께 일하는 사람이 어떤 사람인지 알아보는 과정도 필요했다. 다행히 스켈터랩스에 지인이 있었고, 그의 소개로 하드웨어 엔지니어팀을 이끌고 있는 재경 님을 비롯하여 다른 팀원들을 미리 만날 수 있었다. 긴 대화 끝에 회사의 조직문화나 방향성의 결이 나와 맞는다는 생각을 했다. 뛰어난 개발자가 많기 때문에 내가 계속 성장해나갈 수 있는 환경이라는 점도 입사 결심을 굳히게 된 큰 요소 중 하나다.Q. 스켈터랩스에서는 어떤 업무를 맡고 있는가. A. 스마트 거울 샘(Samm)의 제스처 인식을 담당하고 있다. 이미지 인식을 기반으로 하는 작업이기 때문에 카메라로 구현을 하는게 맞을 지, 혹은 센서를 사용하는 것이 좋을지를 테스트하며 최적의 답을 찾아내려 하고 있다. 또한 엔도어 솔루션(Endor Solution, 공정 과정에서 부품의 결함을 자동으로 검출하는 솔루션)이 더욱 뛰어난 성능을 발휘할 수 있도록 개발에 참여하고 있다. 기존의 팀원들 모두가 딥러닝 경험이 풍부하다. 반면 전통적인 비전(Vision) 쪽 경험은 상대적으로 내가 더 풍부하기 때문에, 데이터처리나 고전적인 방법을 적용한 개발을 통해 엔도어 솔루션을 탄탄하게 보완하려고 한다. 텐서플로우(Tensorflow) 기반으로 기존의 팀이 일해왔다면, 나는 OpenCV를 통해 선행 데이터를 처리한다.사진2. 영화 <마이너리티 리포트>에 등장하는 G-SpeakQ. 비전 기술에 관심을 갖게 된 특별한 계기가 있었는지 궁금하다.A. 글쎄, 계기라고 말하기는 힘들다. 그냥 자연스럽게 HCI쪽에 관심을 가지게 되었고, 그러다보니 다양한 인터페이스를 구현하는 일을 맡아왔다. 당시 HCI가 붐이었고, 아이폰이 이제 막 세상에 등장한 시기이기도 했다. 그런데 HCI 분야의 개발을 지속할수록, 사람들에게 편리한 방식으로 원하는 것을 제공할 수 있는 분야에서 비전 기술은 필수라는 생각이 들더라. 웨어러블 디바이스를 사용하지 않고서도, 개개인의 행동을 관찰하고 그에 맞게 적절한 가이드를 제시하는 것은 모두 비전을 바탕으로 한다. 스티븐 스필버그 감독의 톰 크루즈 주연 영화 <마이너리티 리포트>를 보면, 톰 크루즈가 특수장갑을 착용한 채 스크린을 제어하는 장면이 등장한다. 양손을 사용하여 자유자재로 허공에 활성화시킨 스크린을 제어하는데, 이 장면은 단지 영화 연출이 아닌 실제로 개발된 기술에서 영감을 얻은 장면이다. 기술의 명칭은 ‘G-스피크(G-Speak)’. 이 혁신적인 기술을 개발한 존 언더코플러(John Underkoffler)는 영화 자문 이후, ‘오블롱 인더스트리즈(Oblong Industries)’라는 회사를 설립했다. 사실 ‘G-스피크'를 구현하기 위한 개별 기술들은 당시에도 굉장히 많았다. 오블롱의 차별점은 이 다양한 개별 기술을 하나로 통합한다는 점이다. 오블롱의 행보를 관찰하며, 비전 기술의 활용도에 대해 일종의 확신을 강하게 품게 되었다. NUI(Natural User Interface) 기술이 보편화되면, 기존 오퍼레이션 시스템 환경은 크게 변화할 것이다. 그때 일반 소비자에게 편하게 와닿을 수 있는 새로운 인터페이스를 선도하는 회사가 시장의 선도자가 될 것이고, 비전 기술은 시장 선도자의 핵심일 것이라고 생각하고 있다.Q. 여러 프로젝트에 동시에 참여하고 있기 때문에, 각 팀마다 업무 방식이 어떻게 다른지를 경험했을 것 같다. 그 이야기를 듣고싶다.A. 기본적으로 분위기가 굉장히 다르다. 엔도어 솔루션은 기업의 사설연구소의 느낌이랄까, 굉장히 학구적인 느낌이 강하다. 딥러닝과 관련된 많은 논문을 읽고 깊이 있게 연구하고자 한다. 많은 실험도 필수적으로 병행되는데, 내부적으로는 각 논문과 실험을 통해 얻은 인사이트를 정리하고 공유하고자 노력하고 있다. 이러한 과정을 통해 기존의 다양한 모델을 조합하고 자체적인 모델 개발을 통해 최적의 결과물을 구축하려고 한다. 반면 Inno Lab의 다양한 프로젝트는 오히려 내가 기대했던 스타트업스러운 느낌이 있다. 기존에 없던 디바이스를 만들어 내기 위해 다같이 아이디에이션 과정을 진행했다. 그리고 빨리 구현하고 피드백을 취합한 후, 다시 개발에 들어가는 과정이 꽤 다이나믹하게 이뤄진다. 현재 개발 중인 샘 덕분에 주변의 신기하고 재미있는 디바이스를 검색해보고, 직접 써보고 있는데 덕분에 굉장히 얼리어답터가 된 듯한 느낌이다.사진3. 종훈 님의 일하는 모습을 몰래 촬영해보았다Q. 동시에 결이 다른 두 개의 프로젝트를 진행하기가 어려울 것 같다.A. 어렵다. 그래서 나는 아예 프로젝트마다 기한일을 설정한다. 한 분야에 몰입해서 쭉 끌고 나가는 것이 내게는 더 맞는 느낌이라, 각 프로젝트의 PM과 상의하여 샘 개발에 15일까지 참여한다면, 월 말까지는 엔도어 솔루션에 참여하는 식으로 조정한다.Q. 이전 직장과 스켈터랩스의 업무가 어떻게 다른지도 궁금하다.A. 이제 스켈터랩스에 합류한지 3개월이 좀 지났는데, 크게는 두 가지가 가장 다른 점이자 만족스러운 점인 것 같다. 첫 번째는 일단 개발 환경이다. 스켈터랩스는 개발 환경이 굉장히 빠르고 선진적이다. 개발을 워낙 잘 하시는 분들이 많기 때문에 협업하면서 배울 점도 많고 협업을 통한 시너지도 강하다. 여러가지 툴을 똑똑하고 빠르게 잘 활용하는 것도 업무 효율을 크게 향상시키는 부분이다. 구글 드라이브, 깃허브(GitHub) 뿐만 아니라, 유트랙(Youtrack)과 같은 이슈트래커(Issue Tracker)도 적극 활용한다. 클라우드 환경, 빌드 환경 등도 모두 유연하게 잘 갖춰져있다. 이전 회사가 폐쇄적으로 운영되었던 부분이 있어서 상대적으로 이런 부분을 더 만족스럽게 생각한다. 스타트업인 만큼, 신기술에 대해서 팔로우하고 적용시켜 보려는 과정이 빠르게 일어나고 있는 점도 좋다. 두 번째는 ‘함께 하고 있다'라 느낌이 강하다는 것이다. 이전에는 워낙 프로젝트의 규모도 컸기 때문에, 각자 맡은 업무의 경계선이 분명하게 그어져있었다. 그러나 스켈터랩스는 잦은 미팅을 통해 함께 기획부터 참여하기 때문에 ‘우리의 것'을 만들어낸다는 느낌을 준다.Q. 스켈터랩스에서 가장 애정하는 조직문화가 있다면?A. 맥주를 먹으면서 일할 수 있다는 것(스켈터랩스에는 맥주 디스펜서가 구비되어 있다)! 다이어트를 하고는 있지만 워낙 맥주를 좋아하는 나로서는, 개발이 잘 안풀릴 때 맥주를 먹으면서 일을 할 수 있다는 것 자체가 만족스럽다. 매주 금요일마다 함께 모여서 회사의 여러 프로젝트 진행 상황을 듣고, 구성원에 대해서 알아보는 시간인 올핸즈(All-hands)도 좋아한다. 보통 다른 회사의 경우 정보가 총체적으로 전달되지 않고, 쪼개진 정보만이 내려오는 경우가 많다. 하지만 올핸즈 덕분에 회사의 정보들이 모두에게 공유될 수 있고, 또한 참여할 수 있다고 생각한다.Q. 비슷한 질문이지만 회사 자랑을 위해 하나 더 묻고싶다. 스켈터랩스에서 가장 자랑하고 싶은 점을 꼽는다면 무엇일까.A. 두 가지를 꼽고 싶다. 먼저 자유로운 문화라는 점. 한국에서 정말 몇 안되는 실리콘밸리의 분위기를 풍기는 곳이라고 생각한다(단순히 나만의 의견이 아니라, 실제 실리콘밸리에서 근무하는 친구가 사무실에 놀러왔을 때 ‘실리콘밸리 같다'라고 표현했다). 겉으로는 허름한 창고같은 사무실이지만, 문만 열리면 다른 세계가 펼쳐지는 듯한 느낌을 받을 수 있다. 자유롭게 의견을 내고 토론을 하는 문화도 이 사무실의 분위기와 일맥상통한다. 두 번째는 개개인의 실력이 높아서 정말 배울 것이 많다는 점이다. 그게 한편으로는 스트레스기도 하다. ‘내 밑천이 바닥나면 안될텐데'라는 생각에 책과 다양한 소스를 통해 끊임없이 자발적으로 공부하게 만든다. 실제 개발자 중 몇 분은 구글에서 개발자 레벨의 최고 등급을 받은 것으로 알고있다. 개발 실력은 당연히 코드에 묻어나온다. 다른 개발자의 코드를 보면서도 많은 영감을 얻을 수 있고, 코드 리뷰에 참여하는 것 만으로도 개발 실력이 향상될 수 있다.Q. 자유로운 출퇴근 문화지만, 종훈 님은 꽤 일찍 출근하는 편으로 알고 있다. 하루 일과가 궁금하다.A. 집에서 아침 시간을 여유롭게 즐기는 편이다. 여섯시에 일어나 아침 밥을 집에서 챙겨먹고 출근하고 있다. 일찍 출근할수록, 그 날 내가 목표로 한 업무를 빨리 마치고 퇴근할 수 있기 때문에 너무 늦게는 출근하지 않으려 한다. 덕분에 규칙적으로 일곱시 쯤에는 퇴근을 마치고 운동을 한다. 주말에도 주로 운동을 즐기는 편인데, 요즘에는 토요일마다 꼬박 꼬박 딥러닝 스터디를 하고있다. 나는 전통적인 비전(Vision) 연구를 해왔기 때문에, 딥러닝 쪽은 바탕 지식이 얕은 편이다. 업무를 진행하는데 큰 어려움은 없지만, 회사 프로젝트의 좋은 결과물을 내기 위해서는 딥러닝을 썼을 때 효율적인 부분이 크다. 때문에 많은 시간을 공부에 할애하는 것 같다.Q. 스켈터랩스 헬스동호회 스켈터 스테로이드의 수장으로 알고있다. 동아리를 소개한다면?A. 동호회를 만들게 된 계기는 단순하다. 새 회사에 왔으니, 새로운 몸을 만들겠다는 마음이었다. 사실 헬스는 누군가랑 같이 하는 운동은 아니지않나. 그래도 동호회원들 덕분에 ‘오늘은 그냥 좀 운동을 쉴까’ 싶다가도 누군가가 먼저 나서면 ‘그래도 빠지지 말아야지'란 생각에 꼬박꼬박 운동을 가게된다. 일주일에 두 번이니, 부담스럽지 않은 양이기도 하다. 내가 수장인 만큼 본보기로 열심히 나가야한다는 일종의 책임감도 꾸준히 운동을 이어나가는 원동력이 되었다. 날씨가 추워지면서, 다들 몸을 만들겠다는 의지가 약해져서인지 최근에는 참여률이 떨어지고 있다. 실내에서 할 수 있는 다양한 운동 종목을 더해, 참여를 높이는 방법을 고민 중이다. Q. 운동을 꾸준히 해오고 있는데, 헬스 동호회를 통해 목표했던 성취는 이루었는지 궁금하다.A. 동호회 소개를 하며 ‘이틀 밤을 새도 지지않는 체력을 얻어갈 수 있습니다'라고 공표했는데, 변명이지만 목표가 너무 거창했던 것 같다. 이틀 밤을 새도 지지않는 체력이 갖기 위해 갈 길이 멀다. Q. 이제 인터뷰를 마무리할 단계다. 스켈터랩스가 어떤 회사가 되면 좋겠는가.A. 앞서 말했던 오블롱 인더스트리즈나 센스타임(Sensetime)처럼, 확고한 기술력으로 시장의 선두주자가 되었으면 한다. 이를 위해서는 논문도 많이 내야할 것이고, 더욱 많은 개발자와 함께 기술을 더 깊게 파고드는 과정이 지속되어야 한다. 또한 스타트업으로서 시장의 성패와 상관 없이 가치있고 재미있는 개발을 많이 하면 좋겠다. 현재로서는 Inno Lab이 이러한 성격을 띠고 있다. 그래서 일단은 프로젝트 중 하나인 샘을 성공적으로 런칭하는 것이 나의 목표다.Q. 진짜 마지막 질문. 앞선 질문과 비슷하지만, 개인적인 꿈이 있다면?A. 오래 일하고 싶다. 나이가 들어서도 시장의 흐름을 읽고, 새로운 기술에 대한 충분한 이해와 개발력을 갖춘 사람으로 오래오래 일하고 싶다. 사실 일반적으로 개발자의 수명은 길지 않다. 그래서 창업에 대한 욕심도 품고 있다. 스켈터랩스의 CEO인 테드 님을 보면서 한편으로는 기업 운영 노하우를 배워나간다는 생각도 있다. 향후에는 스켈터랩스의 경쟁사를 내가 세울 수도 있지 않을까(테드 님이 이걸 보면 뭐라하실지 걱정이긴 하다).#스켈터랩스 #사무실풍경 #업무환경 #사내복지 #기업문화 #팀원인터뷰 #팀원소개 #팀원자랑
조회수 1080

2016, 개발자의 Life.. 꿈...#1

주변 개발자들의 삶이 매우 행복을 추구하는 삶으로 변해가고 있다는 것을 느낀다. 주변의 개발자들의 모습을 몇 가지 정리해보자. 이를 '지속 개발을 위한 개발자 Life 스타일'이라고 정의하겠다.개발자#A10년 넘게 개발하던 패키지를 기반으로 필요 기능을 최소화하여 1인 개발기업에 성공하였고 제주도로 내려가서 지역에 속한 분들과 호흡하는 삶을 추구하면서도 소프트웨어 개발의 핵심을 잃지 않았다. 정말, MVP 기능에 최대한 집중하면서 필요한 시장 영역을 더 확대하지 않고, 소프트웨어를 개발하고 있는 개발자와 해당 소프트웨어를 사용하는 고객과 시장에 대해서 같이 합리적으로 지속할 수 있는 지속할 수 있는 소프트웨어 개발의 삶을 이루었다.그리고, 그러한 Life환경을 주변에 전파하면서 불과 얼마 전 또 한 명의 구 루급 개발자에게 비슷한 삶의 길을 가르쳐준다. 정말 부러운 개발자들...개발자#B복잡한 업무나 더 많은 보수를 위해서 더 좋은 회사를 찾기보다는 삶이 존재하는 근무시간을 위해서 재택근무를 찾고 있다. 비용도 최대한 낮추면서 생활을 위한 회사를 찾아다니고 있다. 아무래도, 외국계 개발회사를 선택할 것 같다.개발자#C오픈소스 진형에서 인정받는 개발자이다. 본인이 원하는 오픈소스 프로젝트를 추진하는 것을 보장받고 외국계 기업의 원격근무를 선택했다. 보수도 나쁘지 않고, 근무시간은 알아서 하는 것이지만, 원격으로 일하는 것이기 때문에 '능력'을 보여주기 위해 더 많은 시간을 소프트웨어 개발에 투자한다. 굳이, 서울 시내에 있을 필요가 없기 때문에 외각으로 집도 옮겼다.개발자#D일부러, 실리콘 벨리의 스타트업을 선택했다. 조만간 상장 예정인데 매우 큰 혜택을 받을 것 같다. 그 역시 지속 개발이 가능한 삶을 추구한다.2016년 올 초의 개발자 트렌드는 '지속 개발을 위한 Life'를 지향하는 개발자들이 늘어났다고 평가해본다.우리 모두 지속개발이 가능한 삶을 지향해 보는 것은 어떨까나...
조회수 1896

한국에서 SaaS 서비스 하기

와탭랩스 는 국내에서 보기드문 B2B SaaS 서비스 기업입니다. 그러다 보니 많은 도움도 받을 수 있었고 좋은 기업들도 많이 만날 수 있었습니다. 하지만 모든 것이 처음이다 보니 많은 실수들과 함께 커온 것도 사실입니다. 아래는 SaaS 기업들에게 꼭 필요한 내용들만 추렸습니다. 건너뛰거나 아직 진행 안한 내용들은 지금이라도 꼭 해보세요.  좋은 고객을 골라내세요. 와탭랩스는 서버 모니터링 서비스를 먼저 시작했습니다. 우리는 스타트업이 자사의 제품을 안정적으로 서비스하기 위해 우리의 제품을 사용할 거라 생각했습니다. 하지만 와탭에게 스타트업들은 생각처럼 좋은 고객은 아니였습니다. 그래서 우리는 서버 모니터링의 주요 고객층을 SMB 중에서 100대정도의 서버를 가진 기업으로 변경해야 했습니다. 우리는 초기에 좋은 제품을 만드는 일에 집중하고 좋은 고객을 찾는 과정을 허술히 생각했습니다만 그것은 큰 오판이였습니다. 우리는 우리가 만든 서비스를 사랑하는 사람들을 찾아 내는 데 최선을 다해야 합니다. 우리가 만든 제품의 가치를 지속적으로 발견해내는 고객들이 누군지 찾아 내야 합니다. 그러기 위해 계속 고객을 정의해 나가야 합니다."고객이 우리의 제품을 사는 것은 고객이 우리가 하는 일을 알아서가 아니라 우리가 고객이 하는 일이 무엇인지 알기 때문입니다." 계속, 끊임없이 고객을 분류하세요. 와탭의 서버 모니터링은 서비스에 가입하고 자사의 서비스에 에이젼트를 설치 한 후에 간단한 무료 모니터링을 시작으로 유료 기능까지 넘어가게 되어 있습니다. 반대로 와탭의 어플리케이션 모니터링은 가입 후 트라이얼 사용 후 유료 사용자로 넘어가게 구조화 되어 있습니다. 단계별 활성화 사용자와 비 활성화 사용자를 구별할 수 있어야 합니다. 단계별로 고객을 분류 할 수 없다면 분류할 수 있는 장치들을 마련해야 합니다.고객을 팬으로 만드세요. TV를 보면 많은 걸그룹과 남성그룹들이 나옵니다. 그리고 열성적이 팬들이 있죠. 그리고 팬들은 자신들만의 공간을 만들어 갑니다. 와탭도 그런 과정을 만들기 위해 노력하고 있습니다. 좋은 컨텐츠를 만들고 세미나를 열고 다양한 IT 행사를 지원합니다. 아직은 많이 어설프지만 와탭의 고객분들이 저희의 팬이 될 수 있도록 노력하고 있습니다. 와탭 사용자 분들은 앞으로 더 기대하셔도 좋습니다.  현재 줄 수 있는 가치로 고객을 유치하세요.항상 세일즈에게 당부드리는 이야기 입니다. 미래에 나올 기능으로 고객을 대하지 마라. 미래에 나올 A라는 기능을 대상으로 고객과 이야기 하면 고객은 A가 나올 때까지 기다립니다. SI 기술 영업인 경우에는 SI를 통해 제공 될 미래의 기능을 파는 것이지만 서비스를 파는 와탭랩스는 현재의 제공되는 서비스로 영업을 해야 합니다. 그렇기 때문에 현재 우리가 가지고 있는 제품이 고객에게 어떤 도움이 되는지 정확하게 이해하고 설명할 수 있어야 합니다. 이것은 와탭이 온라인 상에서 제공하는 마케팅에도 그대로 적용됩니다. 허황된 약속은 Churn Rate만 높일 뿐입니다. 우리가 고객에게 줄수 있는 가치를 정확히 전달해야 합니다. 이메일을 다양하게 사용하세요.와탭은 서비스를 오픈하고 처음에는 메일 서버를 만들어서 가입 인증 메일만 보냈습니다. 사용자가 쌓인 후에는 메일챔프를 사용해서 뉴스레터를 보내기 시작했죠. 이메일을 통해 튜토리얼을 보내거나, 교육 컨텐츠를 보내는 것도 좋은 방법입니다.Transactional Email을 사용하세요. 와탭도 이제 Transactional email을 추가하려고 준비 중에 있습니다. Transactional email은 가입 축하 / 유료 권유 / 패스워드 변경 등 가입 또는 사용 기간 및 상황에 맞쳐 자동으로 보내는 이메일 입니다. 대표적인 서비스로는 맨드릴 이 있습니다. Transactional Email을 사용해서 가입 축하 메일, 에이젼트 설치 튜토리얼 메일, 탈퇴 후 다시 돌아와 달라는 메일 등 다양한 메일을 보낼 수 있습니다.소셜 미디어를 사용하세요.제가 지금 사용하고 있는 브런치도 좋은 소셜 미디어 입니다. 제가 이 글 하나에 얼마나 많은 와탭링크를 남겼을까요? :) 유튜브 채널을 활용하는 것도 좋습니다. 페이스북은 이제 거의 필수죠. 회사마다 블로그도 운영하고 있을 것입니다. 슬라이드쉐어에 회사 관련한 많은 내용들을 올리는 것도 좋으며 큐오라도 적절하게 사용한다면 좋을 것입니다. 생태계를 배척하지 마세요. 와탭랩스는 클라우드협회의 회원사입니다. 클라우드 협외의 많은 분들이 다양한 경험을 바탕으로 국내 클라우드 사업과 SaaS 사업의 발전을 위해 노력하고 있습니다. 혹시 해외 사례와 비교하다보니 지엽적인 한계가 명확히 보일지도 모릅니다. 그럼 같이 들어와서 바꿔가면 됩니다. 와탭랩스가 서비스하는 IT 모니터링은 MSP(Managed Service Provider)와 영업을 전문으로 하는 리셀러사들이 복잡하게 얼켜있는 생태계를 구성하고 있습니다. 와탭은 좋은 솔루션을 제공하는 기업으로써 해당 생태계의 좋은 구성원이 되는 노력을 수년간 진행하고 있습니다. 자신의 생태계를 만들어 가세요. 최근 저희는 제2회 와탭 세미나를 개최했습니다. 이제 막 시작했지만 100명이나 모인 세미나였습니다. 규모를 키우다 보면 컨텐츠도 쌓일 것입니다. 와탭은 백엔드 서비스 기업들을 모인 백엔드클럽도 만들었습니다. 열심히 회원사로 활동도 해야겠지요. (아, 최근 열심히 못했습니다. 죄송합니다. ) 와탭은 성능 분석 전문가들이 모일 수 있는 플랫폼도 만들 계획입니다. 이처럼 직첩 다양한 생태계를 만들어 가는 것도 중요합니다. SaaS 세계에서는 이 모든 것들이 마케팅입니다. 회원 탈퇴를 숨기지 마세요.미국 엘리베이터에 닫음 버튼은 동작하지 않습니다. 장애인의 불편을 해소하고자 닫음 버튼을 막았지만 여전히 닫음 버튼이 엘리베이터에 있는 이유는 심리적 안정감(내가 엘리베이터의 문을 닫을 수 있다는)을 제공하기 위해서 입니다. 그런데 많은 서비스들이 회원 탈퇴를 숨기고 있거나 또는 애써 외면하고 있습니다. 숨긴다는 것보다는 신경을 안씀으로써 자연스레 숨겨지는 결과를 만들어 내는 것에 가까운것 같습니다. 이 또한 가입자에게는 심리적 압박감으로 다가올 수 있습니다. 그리고 사용하지 않는 사용자들만 사이트에 쌓이게 만드는 효과를 내기도 합니다. 차라리 탈퇴를 공개하고 탈퇴 시 이유를 묻는 과정을 넣는 것이 유리합니다. 탈퇴를 하는 이유를 조사하세요.정말 중요한 질문입니다. 왜 탈퇴를 하시는 건가요? 해당 질문은 탈퇴의 마지막 구간에서 집행하는 것이 좋습니다. 와탭랩스는 아직 해당 프로세스를 타고 있지 못합니다. 하지만 결국은 우리도 만들 예정인 프로세스입니다. 아쉽게도 한국은 서베이를 참 안해주는 국가로 알고 있긴 합니다. :)고객과 관계를 맺으세요.와탭은 무료 서비스와 트라이얼 서비스를 제공합니다. 물론 유료화가 최종 목표입니다. 그렇기 때문에 매일 아침 무료 고객과 트라이얼 고객의 서비스 이슈를 분석합니다. 알럿이 너무 많이 나온 고객에게 전화해서 이슈를 확인하고 도움을 드린다거나 설치에 곤란을 겪는 고객에게 전화를 드리고 시연을 진행하는 일들이 있습니다. 물료 유료 고객에게도 마찬가지입니다. 유료 고객에게는 성능 리포트를 무료로 제공해 드리기도 합니다. 신용카드를 통한 자동이체 프로세스를 만드세요. 대부부의 가맹점들이 공식적으로 지원하지 않는 것이 신용카드를 통한 자동이체 프로세스입니다. 특히 한국에서는 어떤 빌링사에서도 공식적으로 지원하고 있지 않습니다. 하지만 SaaS 서비스 기업이라면 꼭 진행하셔야 합니다. 혹 당장 안해준다면 고객을 조금만 모은다음에 다시 연결해 보세요. #와탭랩스 #와탭 #SaaS #인사이트 #운영 #SaaS서비스 #SaaS기업
조회수 1310

Android Wear 개발하기 - VCNC Engineering Blog

비트윈 팀은 지난달 비트윈에 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는 새로운 기술과 플랫폼에 관심이 많은 개발자, 혹은 팀이라면 시간을 투자해서 해볼 만한 재미있는 프로젝트입니다. 하지만 완성도 있는 좋은 제품을 만들기 위해서는 생각보다 할 일이 많으니 이를 신중하게 고려하여 결정해야 합니다.끝으로 2014 GDG Korea Android Conference에서 같은 주제로 발표하였던 슬라이드를 첨부합니다.<iframe class="speakerdeck-iframe" frameborder="0" src="//speakerdeck.com/player/a1415af04644013234cf7a3f7c519e69?" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true" style="border: 0px; background: padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 750px; height: 563px;">구글의 튜토리얼 등에서 지칭하는 것과 마찬가지로, 이 글에서도 Android Wear와 연결된 휴대폰을 mobile이라 하겠습니다.↩
조회수 3979

코드리뷰, 이렇게 하고 있습니다.

토스랩 안드로이드팀이 코드리뷰 하는 방법실리콘밸리 이야기 - 코드리뷰는 어떻게 하나요? 를 보고 토스랩이 코드리뷰 하는 프로세스와 방법에 대해서 공유해드리고자 합니다.왜 코드리뷰를 하게 되었나요?토스랩에 안드로이드가 팀 단위로 꾸려진 것은 5월 전후였습니다. 그 전에는 1인 개발 체제를 가지고 있었습니다. 갑작스럽게 인원이 많아지면서 코드스타일, 구조의 일관성 등이 계속적으로 깨지게 되고 이에 따라 제품의 안정성도 급격히 떨어지는 사태가 발생하였습니다.이에 내부적으로 제품의 품질을 강화하기 위한 대책들이 강구되었는데 그 중에 하나가 코드리뷰였습니다.코드리뷰를 위한 프로세스는 토스랩 웹 개발팀의 프로세스를 참고하여 안드로이드 개발 팀원의 내부 의견을 반영하여 진행되었습니다.1. 언제 코드리뷰를 요청하나요?안드로이드팀은 코드리뷰 요청에 대해 별도의 제약을 두지 않았습니다. 언제든지 코드리뷰 시스템이 코드리뷰를 요청할 수 있습니다. 다만 코드 리뷰가 시작되는 시점이 조금 다릅니다.모든 개발자가 코드리뷰를 각자의 업무(Task)가 완료되면 코드리뷰 시스템에 코드리뷰를 요청하고 이를 각 개발자가 언제든지 확인할 수 있도록 하고 있습니다.코드리뷰의 시작은 3. 그럼 코드리뷰는 언제 하나요? 에서 확인해보록 하겠습니다.2. 어떻게 요청하나요코드리뷰는 내가 아닌 다른 사람이 코드를 읽어야 하므로 어떤 목적에서 작업 된 코드인지를 미리 할 수 있어야 빠르게 코드리뷰를 할 수 있습니다. 최대한 자유롭게 하되 아래와 같은 형식을 지키도록 하고 있습니다.TitleFeature/Bug-fix 건인지 알 수 있도록 합니다.어떤 목적인지 간략하게 적도록 합니다.어떤 이슈와 연결된 건인지 알 수 있도록 합니다.Description어떤 로직을 추가/수정했는지를 작성합니다.어떻게 추가/수정했는지를 작성합니다ex)Title - [fix] 소켓 API 버전 처리 (JND-3986) Description@Version 커스텀 어노테이션 추가Version 없는 Event 에 Version 필드 추가, @Version어노테이션 부여SocketObject -> EventObject 로 파싱하는 로직 공통 메소드로 분리파싱 후 바로 반환하지 않고 Version Valid 로직 추가class JandiSocketServiceModel { T getObject(Object, T) // 파싱 공통 메소드 boolean validVersion(Object) // version 확인 } Java Reflection 사용.위와 같이 작성함으로써 이 이슈는 소켓 API 버전에 대한 버그 수정건으로 JND-3986 이라는 이슈와 연관된 것임을 알 수 있습니다. 상세 내용으로는 @Version 이 JandiSocketServiceModel의 getOject 와 validVersion 메소드와 연관되어 있음을 알 수 있도록 기술하였습니다.코드리뷰를 상세하게 쓰는 것은 리뷰어들이 코드리뷰를 효율적으로 하기 위함이기 때문에 리뷰할 부분을 빨리 확인 할 수 있게 적도록 하도 있습니다.3. 그럼 코드리뷰는 언제 하나요?실리콘 밸리의 큰 회사들 (구글, 페이스북 등)은 코드리뷰가 요청이 오면 업무의 최우선순위로 조정되어 즉시 응답하도록 하는 것이 원칙입니다. (지금 당장 하든지 아니면 언제부터 할 것인지를 피드백을 반드시 줘야 한다고 들었습니다.)하지만 스타트업은 일반적으로 개발해야 할 것들이 훨씬 더 많고 코드리뷰가 아니더라도 일이 산더미인 경우가 많습니다. 저희 토스랩이라고 이를 크게 벗어나지 않기 때문에 안드로이드팀은 별도로 코드리뷰하는 프로세스를 정의하였습니다.월~수 : feature/bug-fix 개발이 업무의 최우선 순위이다.목, 금 : 코드리뷰가 업무의 최우선 순위이며 코드리뷰 대상은 목요일 출근 전까지 리뷰 요청을 한 건을 대상으로 한다.이는 개발자들끼리 코드리뷰의 중요성을 이해하지만, 이것이 개발 건보다 더 큰 업무 비중을 차지하게 되면 개발 속도나 의욕을 저해할 수 있기 때문에 최대한 분리하여 해당 건에만 집중하기 위해 룰을 정하였습니다.업무에 따라서 편차는 있지만, 대개의 코드리뷰는 금요일에 모두 완료를 하고 있으며 긍정적 피드백이 나올때까지 코드를 변경해야만 완료가 됩니다.4. 무엇을 리뷰하나요?개발자 개인의 성향과 개발건의 성격에 따라 그때마다 다른 모습을 보여줍니다.성능 개선 개발 : 시간복잡도신규 feature 개발 : 잠재적인 오류에 대한 검출리팩토링 : 테스트코드나 구조에 대한 물음신규 기술 도입 : 해당 기술의 로직과 그에 대한 물음기타 : 변수명과 같은 코드 컨벤션을 하기도 합니다. 전체적인 흐름을 이해하기 위해 실제 빌드를 해서 동작을 시켜보고 이해하기도 합니다.기본적인 사항들은 CI 품질도구 리포팅 기능을 이용하기 때문에 주로 큰 그림에서의 코드리뷰를 하는 편입니다.5. 코드리뷰 코멘트는 어떻게 작성하나요?OO 보다는 XX 가 더 나은 것 같아요.XX 는 OO 부분을 참고해서 이용하면 되요.OO 는 XX 에 의해서 문제되지 않을까요?XX 를 하려다가 OO 로 했는데 어떻게 생각하세요?위와 같이 가급적이면 상대방을 공격하지 않는 느낌을 주도록 하며 단순히 문제를 이슈업하기 보다는 대안을 제시하는 방법을 주로 하고 있습니다. 코드리뷰는 서로의 코드에서 이해할 수 없는 부분을 찾고 문제가 될 수 있는 부분을 미리 찾아내는 자리인만큼 문제의 검출과 해결에 주안을 두고 진행합니다.6. 코드리뷰가 끝나면 어떻게 하나요?서로가 이해할 수 있을 만큼 리뷰가 진행되면 코드는 그때서야 개발용 브랜치에 통합을 합니다. 최소 1명의 피드백도 진행되지 않은 코드는 통합하지 않는 것이 원칙으로 하며 통합되어야 하는 건이 코드리뷰가 진행되지 않으면 늦어도 월요일 아침에 긴급히 진행해 줄 것을 환기시킵니다.7. 긴급히 코드리뷰해야 하는 건은 어떻게 하나요?긴급히 해야하는 건은 그만큼 사안이 중요하다고 생각하기 때문에 리뷰를 요청하는 즉시 진행을 하도록 합니다. 다만 해당 건이 즉시 반영해야 할만큼 중요한지를 서로간의 의논해서 진행하도록 합니다.총평안드로이드팀이 코드리뷰를 최초 시작한 것은 6월초입니다. 브랜치를 통합하기 전 개발 완료된 건에 대한 코드리뷰가 처음이었기 때문에 자리를 잡는데는 2달여 시간이 흐른 다음이었습니다. 초기에는 실수로 코드리뷰를 생략한다던가, 어떻게 코멘트를 남겨야할지에 대해서 조심스럽다던가 하는 시행착오를 겪어서 지금은 개발 건에 따라 20건이 넘는 의견이 남겨질 정도로 활발하게 의견을 교류하고 통합을 거칩니다.코드리뷰에 생소한 사람은 대개 나의 작업물을 누군가에게 검토 받는다는 느낌에 거부감을 가지기 마련입니다. 하지만 더 큰 그림에서 본다면 코드리뷰는 코드의 안정성을 서로 다른 관점에서 검토하는 것이기 때문에 코드의 신뢰성이 더욱 커지는 과정입니다. 그러기에 이에 대한 이해 없이 진행하는 코드리뷰는 금방 유명무실해지기 때문에 모두의 이해를 가진 다음에 진행 할 것을 추천합니다.제품의 안정성을 신경써야 하는 시점에 QA 강화와 같은 외부의 요인만을 찾는 것보다 내부에서 좀 더 개선 할 수 있는 요인을 찾는 것도 하나의 방법입니다. 토스랩에서는 다양한 품질 검증 과정에서 코드리뷰를 매우 중시하고 있습니다. 모든 팀이 각자만의 스타일대로 코드리뷰를 진행하고 있습니다.모든 개발자분들이 코드리뷰에 열린 자세로 올바른 코드리뷰를 진행하기를 바랍니다.#토스랩 #잔디 #JANDI #개발 #개발팀 #개발자 #개발환경 #업무환경 #코드리뷰 #인사이트 #조언
조회수 1828

서비스 중단 없이 Amazon EKS로 옮긴 이야기 - VCNC Engineering Blog

Amazon EKS는 AWS의 관리형 Kubernetes 서비스입니다. 2017년 11월 AWS re:Invent에서 프리뷰 버전이 출시되었고, 2018년 6월에 상용(GA) 버전이 미국 리전에만 출시되었습니다. 그래서 서울 리전을 사용해야 했던 타다 프로젝트에서는 Kubernetes 클러스터를 직접 kops로 설치하여 운영할 수 밖에 없었습니다.2019년 1월, 오랜 기다림 끝에 드디어 서울 리전에 EKS가 출시되어 기쁜 마음으로 EKS로 옮겨가게 되었습니다. 이 글에서는 직접 구축한 클러스터 대비 EKS의 특징에는 어떤 것이 있는지 살펴보고, 서비스 중단 없이 EKS로 옮기기 위한 전략을 공유하고자 합니다.EKS 서울 리전 출시를 염원하던 한국인(?)들EKS는 뭐가 다른가요?AWS에서 마스터 노드를 관리해줍니다.Kubernetes 클러스터는 마스터 노드와 워커 노드로 구성되어 있습니다. EKS는 이 중에서 마스터 노드를 직접 EC2로 띄울 필요 없이 AWS에서 관리해주는 서비스입니다. RDS를 사용할 때 직접 DB 인스턴스를 생성하지 않는 것과 비슷합니다. 별도의 설정 없이도 알아서 여러 가용 영역에 마스터 노드를 실행하여 HA(고가용성) 구성을 해주고, 비정상 마스터 노드를 자동으로 감지하고 교체합니다. 또한 자동화된 버전 업그레이드 및 패치를 지원합니다. EKS를 사용하더라도 워커 노드는 직접 EC2 인스턴스를 생성·관리해야 합니다.EKS 클러스터의 요금은 2019년 2월 현재 시간당 $0.20입니다. 타다에서는 기존에 t2.medium 3대를 마스터 노드로 사용하고 있었기 때문에 관리를 직접 하지 않는 대신 비용이 약간 증가하게 되었습니다.AWS IAM 기반 인증을 사용합니다.VCNC에서는 기존에 Kubernetes API에 접속할 때 가장 간단한 basic auth 인증 방식을 사용했습니다. 그 대신 외부 네트워크에서 접근할 수 없게 해두고 필요한 경우 Bastion 호스트를 통해 SSH 터널링하여 접속했습니다.EKS의 API 서버는 인터넷에 노출되어 있으며, 별도로 네트워크 접근 제한 설정을 할 수 없고 AWS IAM으로 사용자를 인증합니다. (물론 공개망에 노출되어 있으면 Kubernetes API 서버에 보안 취약점이 발견되는 경우 안전하지 않을 수 있는 단점이 있습니다. 앞으로 PrivateLink가 지원되면 해결될 것입니다.)IAM은 인증에만 사용되고, 특정 작업을 할 수 있는 권한은 Kubernetes 기본 RBAC로 관리됩니다. IAM 사용자나 역할을 RBAC 그룹에 매핑할 수 있습니다.EKS 인증 흐름도워커 노드 당 Pod 개수 제한이 있습니다.예를 들어 c5.large 인스턴스에는 29개의 Pod을 띄울 수 있습니다. (표 참고) 그러므로 기존 클러스터에서 노드 당 Pod이 몇 개나 되는지 미리 확인할 필요가 있습니다. 왜 이런 제약이 있을까요?Kubernetes에서는 네트워킹 플러그인으로 Pod 사이에 네트워크 통신하는 방식을 다양하게 설정할 수 있습니다. EKS는 기본적으로 amazon-vpc-cni-k8s를 사용합니다. 이 네트워킹 플러그인은 VPC 상에서 유효한 실제 IP를 Pod에 할당합니다.그러기 위해서는 하나의 EC2 인스턴스에서 여러 개의 IP를 받아와야 하고, 이를 위해 추가적인 네트워크 인터페이스(ENI)를 붙입니다. 그런데 인스턴스 타입에 따라 추가할 수 있는 ENI 수와 ENI 당 IP 수에 제한이 있습니다. 따라서 이 제한이 워커 노드 하나에 띄울 수 있는 Pod 개수 제한이 됩니다.flannel 등 오버레이 네트워크 기반의 다른 네트워크 플러그인을 사용하면 이러한 제약을 피할 수 있습니다. 하지만 EKS에서 기본 제공하는 방법을 그대로 사용하는 것이 좋고, Pod을 엄청나게 많이 띄워야 하는 상황이 아니어서 시도하지 않았습니다.EKS로 중단 없이 넘어가기개요타다의 Kubernetes 클러스터에서 돌아가는 서비스들은 모두 영속적인(persistent) 상태를 가지고 있지 않습니다. 따라서 EKS 클러스터 위에 동일한 서비스를 띄우고 외부 트래픽을 옮겨주기만 하면 특별히 데이터를 옮기지 않고도 이전이 가능했습니다. 또한 거의 대부분의 Kubernetes 리소스는 Helm 차트로 생성한 것이기 때문에 새로운 클러스터에 동일한 서비스를 띄우는 작업도 쉽게 할 수 있었습니다.이전 작업은 다음과 같은 순서로 진행했습니다.EKS 클러스터를 만들고 워커 노드를 생성모든 서비스 다시 설치트래픽을 새 클러스터로 보내기이전 클러스터 제거EKS 클러스터를 만들고 워커 노드를 생성타다의 AWS 환경은 거의 모두 Terraform으로 정의되어 관리되고 있습니다. EKS 클러스터와 워커 노드도 HashiCorp Learn의 문서를 참고해서 Terraform으로 생성했습니다. 해당 문서에 설명이 잘 되어 있어서 거의 그대로 따라할 수 있었습니다.EKS 클러스터 설정은 재사용 가능하도록 Terraform 모듈로 만들었습니다. 덕분에 테스트용 클러스터와 실서비스용 클러스터를 동일한 모듈로 변수만 바꿔서 설정할 수 있었습니다.모든 서비스 다시 설치타다의 Kubernetes 리소스는 Helm 차트로 관리되고 있어서 기존 차트를 거의 그대로 설치할 수 있었습니다. 사용자에게 직접적인 영향을 덜 주는 워커 서비스를 먼저 설치해서 제대로 동작하는 것을 확인한 뒤, 마지막으로 프론트엔드 서비스를 설치하였습니다.트래픽을 새 클러스터로 보내기타다의 모든 트래픽은 NLB로 들어온 뒤 NGINX를 거쳐 다시 적절한 Pod에 라우팅됩니다. 그러므로 타다의 모든 도메인은 NLB를 가리키고 있습니다.타다는 Route 53을 DNS 서버로 사용합니다. Route 53에는 가중치 기반 DNS 레코드를 설정할 수 있습니다. 이를 이용하여 일부 트래픽만 새 클러스터의 NLB로 보낼 수 있습니다. 처음에는 아주 적은 트래픽만 새 클러스터로 보내다가 문제 없이 작동하는 것을 확인한 다음 조금씩 트래픽을 늘려나갔습니다.DNS 가중치 설정으로 일부 트래픽만 새 클러스터의 NLB로 보낼 수 있습니다.DNS 설정에서 이전 클러스터로 가는 레코드를 완전히 제거한 뒤에도, DNS 캐시 등의 이유로 일부 클라이언트가 이전 클러스터에 접속할 수도 있습니다. 따라서, 이전 클러스터 NLB에 새 클러스터의 노드들을 붙여서 아직 DNS를 따라오지 못한 클라이언트들의 요청을 처리하였습니다.이전 클러스터 제거가장 신나면서 조심해야 하는 작업입니다. 먼저 이전 클러스터로 트래픽이 전혀 들어오지 않는 것을 확인하였습니다. 그 다음에는 Terraform에서 이전 클러스터 리소스에 대한 참조를 제거한 뒤, terraform destroy 명령으로 이전 클러스터와 관련된 리소스를 한번에 삭제할 수 있었습니다.맺음말Kubernetes는 깔끔한 추상화를 통해 컨테이너 기반 배포를 간단하게 만들어주지만, 직접 클러스터를 관리해야 하는 부담이 있었습니다. Amazon EKS는 이러한 부담을 많이 덜어주는 좋은 서비스입니다. 앞으로 EKS의 무궁한 발전을 기원합니다.VCNC에는 오랫동안 쌓아온 AWS 인프라 운영 경험이 있습니다. 타다에서는 그동안의 경험과 비교적 최근에 시작한 프로젝트의 이점을 살려 컨테이너, Infrastructure as Code 등 업계 표준의 인프라 관리 방법론을 적극 도입하려고 노력하고 있습니다. 앞으로도 이에 관해 기술 블로그에 더 자세히 공유할 계획이니 기대해주세요. 또한 저희와 함께 안정적인 서비스를 만들어나갈 좋은 분들을 기다리고 있으니 VCNC 채용에도 많은 관심 부탁드립니다.

기업문화 엿볼 때, 더팀스

로그인

/