모바일은 플랫폼의 생태계와 규모에 비해 개발자들이 처리해야 할 것이 매우 많습니다.서버나 타 플랫폼들 또한 개발자들의 영역이 많지만 그 영역들이 세분화되고 전문화되어 가고 있습니다. 데이터베이스, 백엔드, 프론트웨어, 인프라, DevOps 와 같이 점점 분야별로 심화되고 독립성을 갖추어 가고 있습니다.하지만 모바일은 각 플랫폼의 개발자들이 전체적인 아키텍쳐, 프론트, 내부용 데이터베이스, 리소스 관리, 배포 등이 해당 플랫폼의 소수의 개발자들에게 광범위하게 공존합니다. 다양한 분야가 전문화되기엔 변화가 잦고 규모가 점 형태로 구성이 된 경우가 많기 때문입니다.그렇기 때문에 반복적이고 불필요하게 비용이 소모되는 작업일수록 자동화 해서 최대한 코드 작성 본연에 업무에 집중할 수 있도록 환경을 구성하는 것이 중요합니다.토스랩 안드로이드 팀은 2015년 초부터 조금씩 자동화 환경을 구성하여 현재는 아래와 같습니다.다국어 문자 관리 자동화이미지 관리 자동화CI다국어 문자 리소스 자동화1. 다국어 글로벌 담당자의 원본 문서토스랩은 다국어 지원을 위해 글로벌 번역 문서를 관리하고 있습니다. 문서는 Google Drive 를 통해서 관리되고 있으며 기획/개발 파트에서 다국어 지원을 위한 리소스를 기입하면 각 언어의 담당자들이 해당 언어를 번역하고 있습니다.구성은 아래와 같습니다ABCDEFGH영어한국어일본어중국어-간체중국어-번체웹키ios 키안드로이드 키2. 기존 작업기존에는 해당 언어의 번역 데이터를 추가하기 위해 개발 파트에서 수동으로 각 언어의 리소스 파일에 추가하는 형태로 진행하였습니다.이러한 작업의 단점은 언어별 리소스 파일에 키-값 형태의 문자 리소스를 추가하는 작업을 반복적으로 해야 한다는 것입니다. 또한 반영이 된 후에 수정된 문자에 대해서 반영하기가 매우 어렵고 실수도 빈번하게 발생합니다.이러한 가능성을 최소화 하기 위해 자동으로 문자 리소스를 갱신하는 작업을 진행하였습니다.3. 안드로이드 파트를 위한 별도 필터 파일 추가|A|B|C|D|E|F| |—-|—-|—-|—-|—-|—-| |영어|한국어|일본어|중국어-간체|중국어-번체|안드로이드 키|가급적 원본 파일에 대한 조작을 피하기 위해 안드로이드용으로 Read-Only SpreadSheet 를 별도로 생성하였습니다.해당 작업을 위해 Google SpreadSheet Script 를 사용하였습니다.4. 자동화 툴 작업자동화 툴의 역할은 크게 3가지였습니다.안드로이드용 필터 파일을 다운로드한다.Spread-sheet를 분석해서 다국어용 자료구조로 변환한다.다국어용 자료구조를 XML 파일로 변경한다.툴은 Python 스크립트로 작업하였습니다.5. Gradle Task 로 추가별도의 Python 파일을 실행해도 되지만 Gradle Task 로 추가하여 Android Studio 에서도 Task 를 실행할 수 있도록 하였습니다.개발팀에서 안드로이드 키를 원본 문서에 추가한 후 Gradle Task 실행하면 바로 반영되도록 하였습니다. 기존의 방식과 가장 큰 차이점은 Merge 시 충돌 이슈에 대해서 더이상 관여하지 않아도 된다는 것입니다. 가장 최근 시점을 기준으로 자동화 Task 를 실행하면 모든 리소스가 최신화되기 때문에 충돌이 난다하더라도 무시하고 새로 Task 를 실행함으로써 충돌에 의한 이슈를 완전히 배제하고 작업할 수 있다는 장점이 생겼습니다.더 나아가 현재는 Android 용 리소스 Key를 기획 팀에서 기획시 적용하도록 하기로 현재 논의되고 있습니다. 이러한 논의가 반영된다면 더이상 리소스 관리에 있어서 개발파트에서 관리 할 필요가 없어지므로 다국어 리소스에 반영해야할 리소스 또한 최소화 될 것이라 기대하고 있습니다.이미지 리소스 자동화1. 기존 작업앱에 사용되는 디자인 리소스는 이슈 트래커와 JANDI 의 디자인 토픽을 통해서 전달 받아 작업을 하였습니다.이런 작업 형태는 이미지 관리가 분산 될 뿐만 아니라 일관성 있는 전달 방식이 아니기 때문에 누락건이 언제든지 존재할 수 있습니다.그래서 디자인 리소스에 대한 관리를 디자인 팀이 주도적으로 하며 개발팀에서는 빠르고 편하게 이미지를 전달 받을 수 있도록 하기 위해 자동화 툴을 만들었습니다.2. 개선 작업토스랩의 디자인 팀에서 사용하는 저장소는 권한에 따라 접근이 가능하도록 API 를 제공하고 있습니다. Read-Only 권한을 부여받은 후 API 를 통하여 이미지를 다운로드하도록 툴을 구성하였습니다.툴은 Python 스크립트로 구성하였습니다.3. Gradle Task 로 추가문자 리소스와 마찬가지로 별도로 Gradle 로 툴을 이용할 수 있도록 하기 위해 별도의 Task 를 정의하여 사용하도록 하였습니다.자동화된 리소스의 관리문자와 이미지를 자동화로 관리한다 하더라도 개발자가 필요에 따라 임의로 추가/수정하는 리소스가 존재 할 수 있습니다.이를테면 다운로드한 이미지 리소스를 활용한 Selector-Drawable 과 같은 것들입니다.이에 따라 자동화 처리된 리소스들은 별도의 관리를 위해 추가적으로 ResourceSet 을 만들었습니다. android { // ...중략 sourceSets { main.res.srcDirs += ${별도의_리소스_경로} } } 이러한 방식을 통해서 자동화된 리소스와 추가적한 리소스를 분리하여 발생할 수 있는 문제를 최소화 하였습니다.지속적 통합 (Continuous Integration, CI)자동화와 관련되어서 결코 빠질 수 없는 내용입니다. 빌드, 테스트, 배포, 리포팅에 이르기까지 이 모든 과정에 있어서 자동화 되지 않았다면 상상하기 어려운 작업들입니다.토스랩에서는 Jenkins 를 활용하여 빌드-테스트-리포팅을 하고 있습니다.1. 빌드 대상빌드의 의미는 최소한 컴파일 오류가 발생하지 않는 코드들이 최종 상태로 관리되고 있음을 의미합니다. 그러기 때문에 언제나 중앙 저장소에 반영되었거나 반영될 예정의 소스들은 항상 빌드 대상이라고 볼 수 있습니다.안드로이드 팀은 내부적으로 빌드 대상이 되는 브랜치를 아래와 같이 정의하였습니다.개발된 이슈가 최종적으로 반영된 브랜치 (develop)Github 에서 코드에 변경이 발생하면 이를 Jenkins 로 통보하여 해당 브랜치를 빌드합니다.개발 브랜치에 반영을 위해 코드리뷰 중인 브랜치 (features, fixes)Github 에 새로운 Pull-Request 가 발생하면 Jenkins 로 통보하여 해당 브랜치를 빌드합니다.테스트와 리포팅은 이 시점부터 발생한다고 볼 수 있습니다.2. 빌드빌드를 하는 과정에 기본적인 정적 분석을 사용하고 있습니다. 코드의 Convention 이나 복잡도 등을 측정하고 이를 분석하여 수정할 부분을 파악하기 위해서입니다.3. 테스트안드로이드팀은 작년 중순까지 Robolectric 이라는 Test Framework 을 사용하였으나 여러가지 이슈로 인하여 현재는 Android Test Support Library 를 사용하고 있습니다. ATSL 은 에뮬레이터를 필요로 하기 때문에 Jenkins 서버에 에뮬레이터를 구동하여 Test-Bed 를 구성하였습니다.빌드 과정에서 정적 분석이 완료되면 테스트 코드를 동작 시킵니다.테스트 된 결과는 JUnit Test Report 와 Jacoco Coverage Report 를 받고 있습니다.4. 결과 리포트빌드, 테스트 결과는 Jenkins 에서 별도로 관리되고 있지만 모든 동작들은 자동화 되어 관리되기 때문에 별도의 장치가 없다면 알아채기 어렵습니다.좀 더 빠른 피드백을 받기 위해 JANDI-Webhook 기능을 이용하여 결과 리포팅을 바로 받아 확인 할 수 있도록 하였습니다. 또한 Github Pull-Request 화면에서 Build-Status 연동하여 코드리뷰 하는 과정에서 잠재적 오류를 찾을 수 있도록 하였습니다.※ 빌드된 결과물의 배포는 내부적인 정책으로 현재는 하지 않고 있습니다만, 현재 가용 가능한 리소스 안에서 해결 방안을 찾고 있습니다.총평자동화의 가장 큰 목적은 반복적이지만 시간을 소요하기엔 가치가 떨어지는 작업을 단순화 하기 위함이었습니다. 여기서 오는 가장 큰 의미는 관리에 소요되는 시간을 최소화함으로써 생산성을 향상 시켰다는 데에 있습니다.특히 다국어 리소스와 이미지 리소스를 자동화 하기 위한 작업은 소요된 시간이 극히 미미하지만 그 효과는 매우 긍정적이라 할 수 있습니다.CI 는 초기 설정뿐만 아니라 관리가 매우 어려운 작업입니다. 해당 시스템을 총체적으로 알고 있다는 가정에서 해야 하며 정책적으로 규정해야 하는 것들도 있습니다. 하지만 결과물 그 자체에 대한 관리를 위해서는 없어서는 안되는 도구이며 정적분석과 자동화 테스트 등 다양한 효과를 얻을 수 있기 때문에 많은 개발자들에게 권장하고 싶습니다.#토스랩 #잔디 #JANDI #개발 #효율 #자동화툴 #업무환경

Event(이후 '이벤트'로 통칭)Node.js(이후 '노드'로 통칭)는 이벤트 기반 비동기 방식으로 작동한다. 그러므로 노드를 잘 다루기 위해서는 이벤트에 대해 이해하여야 한다.노드에서 이벤트를 호출하고 여러 처리를 하기 위해서는 EventEmitter 객체를 상속받아 구현해야 한다.아래 예제 코드를 통해 EventEditter를 상속받은 객체를 가지고 이벤트를 생성하고 호출하는 등 여러 처리하는 법을 살펴보자.* 코드 복사붙여넣기가 필요한 경우 http://madeitwantit.tistory.com/32 에서 가능하다.EventEmitterEventEmitter 클래스는 events 모듈에 의해 정의되고 제공된다.EventEmitter = require('events');위와 같이 EventEmitter를 정의할 수 있다.EventEmitter의 메서드EventEmiter.on('이벤트 이름', '리스너 함수') - 지정한 '이벤트 이름' 이벤트에 '리스너 함수'를 리스너 배열 가장 끝에 추가한다. EventEmiter.once('이벤트 이름', '리스너 함수') - on() 메서드와 기능이 비슷하다. 다만 이 메서드로 등록된 리스너는 일회성으로 한 번 실행된 후 제거된다. EventEmiter.addListener('이벤트 이름', '리스너 함수') - on() 메서드와 같다.EventEmiter.emit('이벤트 이름'[, arg]...) - '이벤트 이름'  이벤트에 등록된 리스너 함수를 등록된 순서에 따라 호출한다. 이벤트가 존재한다면 true, 그 외에는 false를 반환한다.EventEmiter.setMaxListeners(n) - EventEmitter는 디폴트로 최대 리스너 수가 10으로 지정되어 있다. 10보다 더 많은 리스너를 등록할 때 사용한다. Infinity나 0을 지정하면 제한 없이 리스너를 등록할 수 있다.EventEmiter.getMaxListeners() - 현재 EventEmitter에 지정된 최대 리스너 수를 반환한다.EventEmiter.listenerCount('이벤트 이름') - '이벤트 이름'에 등록되어 있는 리스너의 수를 반환한다.EventEmiter.listeners('이벤트 이름') - '이벤트 이름'에 등록되어 있는 리스너 배열의 사본을 반환한다.EventEmiter.removeAllListeners(['이벤트 이름']) - 모든 리스너나 파라미터에 지정한 '이벤트 이름'의 리스너를 제거한다.EventEmiter.removeListeners('이벤트 이름', '리스너 함수') - '이벤트 이름'에 등록되어 있는 특정 '리스너 함수'를 제거한다. 같은 리스너가 여러 개 등록되어 있으면 이 메서드를 여러 번 호출해야 한다.EventEmitter의 이벤트'newListener' - 새로운 이벤트를 등록할 때, 추가될 리스너를 리스너 배열에 추가하기 전에 호출된다. 이벤트에 리스너가 전달되기 위해 이벤트 이름과 추가될 리스너가 전달된다.'removeListener' - 리스너가 제거된 후 호출된다.하단의 예제를 통해 newListener가 호출되는 시점에 대해 살펴보자.                                                              * 코드 복사붙여넣기가 필요한 경우 http://madeitwantit.tistory.com/32 에서 가능하다.참고문헌:모던 웹을 위한 Node.js 프로그래밍 - 윤인성Haruair (http://haruair.com/blog/3396)Node.js Documentation (https://nodejs.org/api)조대협의 블로그 (http://bcho.tistory.com/885)#트레바리 #개발자 #안드로이드 #앱개발 #Node.js #백엔드 #인사이트 #경험공유

기업의 슬로건은 기업의 이미지를 좌우할만큼 중요하다고 할 수 있습니다.나이키의 'Just Do It' 이나 아디다스의 'Impossible Is Nothing'과 같이 대중의 머릿속에 이미지 그 자체로 각인될 수 있기 때문이죠. 어반베이스가 3D 공간데이터 플랫폼으로서 전 세계의 모든 실내공간정보를 자유롭게 활용할 수 있는 코어 기술과 서비스를 런칭하게 되면서 미래를 향한 메시지를 내포할 수 있는 새로운 슬로건을 만들게 되었습니다. 어반베이스는 과연 어떤 방법으로 새로운 슬로건을 만들었을까요?슬로건도 '어반베이스'답게 만들다어반베이스는 IT 기술 기반의 스타트업인만큼 직원 중 절반 이상이 개발자입니다.그렇다보니, 출퇴근기록 계산기부터 점심알람봇(bot)까지 일상에서 조금이라도 불편한 점이 있다면 개발자분들이 출동하여 프로그램을 만들어 주시곤 합니다.  이러한 문화를 가지고 있는 어반베이스는 슬로건 만드는 방법 또한 '어반베이스'답게 만들어 냅니다. 슬로건에 대한 다양한 아이디어를 얻기 위해 어떤 방법이 좋을지 고민하다가, 진우님(진우님=대표님=건축가 출신 프로그래머)께서 룰렛 하나를 만들었습니다. 같이 살펴볼까요?만들어 공유해 주신 링크를 타고 들어가면 이렇게 깔끔한 룰렛하나가 나오는데요참여방법은 간단합니다.1. 랜덤버튼을 2회 누르면 문장이 완성됩니다. 마음에 드는 문장이 나타나면 아래의 세이브 버튼을 누릅니다. 그 리고 그 문장은 저장되어 하단의 그래프로 반영이 됩니다. 'RANDOM'버튼을 한 번 눌러보았더니 클릭 두번에 슬로건 하나가 탄생합니다.'We Generate Urban'조금 더 나은 슬로건을 위해 RETRY 해 봅니다.이번엔'We Reform The Next World' 가 탄생했습니다.2. 그래도 마음에 드는 문장이 안나오면 보라색 '후리스타일' 버튼을 누르셔서 직접 입력해주시면 우측 리스트에 반영됩니다. (무기명입니다)'후리스타일' 버튼을 누르고 입력한 문장들입니다.이렇듯, 룰렛을 사용해 간단하고 간편하게 많은 문장들을 만들어냈습니다. 몇몇 단어를 가지고 고민하는 것보다, 룰렛을 최대한 많이 돌려서 저장하는 방법을 선택했습니다. '이런식으로도 슬로건을 만들 수 있다니' 재미 반 진지 반으로 어반피플들이 모두 참여하여 슬로건 짓기에 동참했습니다.그러하여 나온 최종 두 가지 안 입니다. We Invent the Next WorldWe Reinvent the World우리는 이 최종 두 가지 안을 가지고 다시 투표를 하였습니다. (다수결의 원칙) 그 결과, 아주 근소한 차이로 우리의 슬로건 탄생!어반베이스의 새로운 슬로건'We Invent The Next World'4차 산업혁명의 시대, 국내 뿐 아니라 전 세계적으로 공간데이터의 높은 활용 가능성에 주목하고 있습니다.3D 공간데이터 플랫폼 어반베이스는 앞으로 “We Invent The Next World” 라는 모토 아래, 보다 앞선 새로운 삶의 모습을 제시하고자 합니다. 2D 도면 이미지를 단 몇 초만에 3차원 공간으로 자동 변환해주는 기술부터가상의 인테리어를 돕는 3D HomeDesign, 3D데이터를 증강현실로 경험할 수 있는 AR Viewer, 머신러닝과 인공지능을 이용한 공간 기반 추천 서비스까지. 전 세계의 모든 실내공간정보를 하나의 플랫폼 안에서 자유롭게 활용할 수 있는 코어 기술 및 서비스를 선보이고자 하오니 많은 기대 부탁드립니다.*2019.01 어반베이스 개발자 사이트 런칭 예정 *2019.02 AR SCALE 런칭 예정출처: https://blog.naver.com/urbanbaseinc 

문제 상황안드로이드 어플리케이션을 개발하다 보면 주소록을 다루는 일이 종종 있습니다. 어플리케이션에서 주소록에 관련된 정보를 접근할 일이 있는 어플이라면 ContentResolver를 통해 단말의 주소록에 접근해서 필요한 정보를 가져오게 됩니다.그런데, 최근 개발하고 있는 스포카 어플을 통해 아주 많은 사람의 연락처가 저장된 주소록을 가지고 이런 저런 로직을 실행하는 상황을 테스트 하다보니, OutOfMemory(OOM)에러가 발생하는 현상을 볼 수 있었습니다. 모바일 디바이스들은 PC와 다르게 자원이 제한적이기 때문에 어떻게 하면 OOM을 일으키지 않을 수 있을까 라는 고민을 해야 하는 상황이었습니다.대강 문제가 되었던 클라이언트 사이드의 로직을 살펴보면 이렇습니다.단말의 주소록에 접근하여 필요한 정보를 추출 후 서버에 전송서버에서 정보를 가공하여 필요한 json 문자열을 생성 후 반환, 이 문자열은 주소록에서 보낸 정보의 양에 비례해서 늘어나게 됩니다.클라이언트 측에서 서버 측에서 보낸 json 문자열을 이용하여 JSONObject객체를 만든 후 이 JSONObject를 이용 리스트 완성eclipse의 MAT(Memory Analyzer)을 이용하여 어느 시점에서 OOM이 일어나는지를 추측해보았습니다. 서버에서 보내준 json형식의 문자열을 HttpURLConnection을 통해 전달받고 이를 StringBuilder를 이용하여 완전한 문자열으로 만들던 도중에 OOM이 일어나는 것으로 의심되었는데 이 때문에 JSONObject의 생성자에 json 문자열을 전달하기도 전에 메모리가 가득 차 버리니 매우 난감한 상황이었습니다.대게 주소록에 사람이 그렇게 많지 않으므로 (200~500명 정도) 아무런 문제가 없었지만 10000명 정도의 더미데이터를 주소록에 저장하고 테스트하다 보니 append 메서드를 호출하다 OOM에러를 뱉으면서 어플이 종료되었습니다. 문제는 append 메서드를 호출 시 StringBuilder의 capacity를 넘을 경우 내부적으로는 메모리 재할당과 copy과정이 일어난다는 것이었습니다. 그렇다고 초기 StringBuilder생성시 capacity를 무작정 높게 잡기도 애매한 상황이었습니다.gsongson은 Java객체를 json형식으로 변환하고 그 역으로도 변환할 수 있도록 도와주는 라이브러리입니다. gson의 사용법이 궁금하다면 gson user guide를 읽어보면 되고 api가 궁금하다면 gson api document를 참조하면 됩니다.gson 적용대략 이런 방식으로 프로젝트에 gson라이브러리를 적용하였고, HttpURLConnection을 통해 받아온 InputStream을 이용 바로 객체를 생성할 수 있었습니다. 이전에 StringBuilder를 이용할때 생기는 오버헤드가 사라진 셈이죠. 위와 같은 방식으로 OOM이 생기는 문제 상황을 해결 할 수 있었습니다.위의 예는 상황을 최대한 단순화하여 설명하려고 작성한 예제이고 이 사이트를 통해 더 상세하게 설명된 사용예를 보실 수 있습니다.#스포카 #개발 #개발자 #GSON #Java #인사이트 #google_gson

채널 웹 플러그인을 개발하며 겪은 문제들과 우리 팀의 해결책을 소개합니다. 채널 웹 플러그인은 SDK의 형태로 고객사 웹사이트에 붙어서 고객이 매니저와 대화할 수 있는 인터페이스를 제공합니다. 이 글을 쓰고 있는 당시 약 2300개의 채널이 개설되었고, 하루 약 180만 명의 일반 유저가 웹사이트에 붙은 저희 플러그인을 보고 있습니다.플러그인은 고객사 웹사이트 (이하 호스트 웹사이트라고 함) 의 HTML 도큐멘트에 붙어서 실행됩니다. 이 말은 실행 환경 (자바스크립트, CSS, DOM 환경 등) 을 우리가 컨트롤하지 못한다는 것을 의미합니다. 이것이 일반적인 웹서비스와 플러그인 개발의 가장 큰 차이점이고 사실상 많은 이슈들은 이 차이로부터 기인합니다. 또 이것에 대응하기 위해 프레임워크의 선택부터 개발, 배포에 이르기까지 훨씬 신경 써야할 부분이 많았습니다. 이 글에서는 그 중 호스트 웹사이트와의 실행 환경 공유에 따른 문제들을 자바스크립트와 CSS로 나누어 나열하고 iframe 을 이용하여 해결한 과정에 대해 설명하겠습니다.채널 홈페이지에 웹 플러그인이 붙은 모습1. 자바스크립트와 관련된 이슈1-1. 네임스페이스 공유에 따른 충돌 문제브라우저에서 자바스크립트는 글로벌 네임스페이스를 공유합니다. 이 속성 때문에 플러그인에서 window 를 접근해서 수정한다던가 글로벌로 객체를 정의해서 사용하면 호스트 웹사이트에 영향을 미칠 수 있습니다. 이 문제는 코딩할 때 아래 항목을 주의하는 정도로 큰 비용 없이 방지할 수 있습니다.플러그인의 최상위 네임스페이스를 만든다.(ex. window.CHPlugin)플러그인에서 사용하는 모든 객체는 최상위 네임스페이스 아래에 정의되도록 한다.(ex. window.CHPlugin.outObject)window 객체에 접근할 때는 수정하거나 추가하는 부분이 없도록 주의한다.(ex. [removed] = function(){}와 같은 코드는 사용하면 안 됨. 기존에 [removed] 이벤트가 날아감)사용하는 라이브러리들 중에 window에 바인딩하는 것이 없는지 체크하고 있으면 직접 수정하여 모듈화한다. (ex. lodash는 기본적으로 window 에 _ 객체를 생성함)이건 사실 플러그인이 아니더라도 주의해야하는 거죠..1-2. 에러로 인한 오동작 가능성더 어려운 문제는 바로 예측하기 어려운 오동작의 가능성이 있다는 것입니다. 호스트 웹사이트에서 동작하는 자바스크립트에서 에러가 날 경우 플러그인의 동작에도 영향을 미칠 수 있으며, 반대로 플러그인에서 에러가 발생해서 호스트 웹사이트의 코드 실행을 멈출 수 있다는 것입니다. 양방향으로 영향을 미칠 수 있는 것이죠. 특히 후자의 경우는 우리의 실수로 고객사의 서비스에 피해를 끼칠 수 있으니 쉽게 넘길 문제는 아닙니다.아이디어 1: try/catch를 적절히 처리한다?이를 해결하기 위해 가장 쉽게 생각할 수 있는 방법으로는 호스트 웹사이트 쪽에서 try/catch를 적절하게 처리하도록 가이드를 하는 방법입니다. 예를 들어 플러그인 코드의 바깥 쪽에 try/catch처리를 하고 호스트 웹사이트의 자바스크립트에도 적당하게 처리를 하면 되지만 이 방법은 현실적으로 어려움이 있습니다. 우리의 타겟 고객사들은 일반 쇼핑몰들이고 이들은 대부분 개발자가 없거나 쇼핑몰 빌더를 이용해 만들어진 사이트들이기 때문에 개발력이 없는 경우가 많습니다. 또 설사 개발력이 있다 하더라도 플러그인을 붙이기 위해 가이드할 것이 너무 늘어나는 문제가 있죠.아이디어 2: 자바스크립트 실행 순서를 강제한다?생각해볼 수 있는 또 다른 방법은 호스트 웹사이트의 코드와 플러그인 코드의 실행 순서를 명확히 정해서 한 방향의 영향이라도 차단하는 것입니다. 예를 들어 플러그인 코드가 호스트 웹사이트의 코드보다 항상 먼저 실행되도록 고객사에게 가이드한다면 우리의 코드는 항상 문제 없이 실행될 것이고 호스트 웹사이트에서 에러가 발생하더라도 영향을 받지 않을 것입니다. 하지만 이 방법 역시 마음에 들지 않았는데요 양방향의 영향을 모두 차단하지는 못하기 때문입니다. 그리고 더욱 큰 문제는 플러그인은 한 번 실행되고 끝나는 단순한 스크립트가 아니라 계속해서 실행이 되는 애플리케이션이기 때문에 사실상 소용이 없습니다.2. CSS와 관련된 이슈채널 웹 플러그인은 UI도 포함합니다. 플러그인의 DOM이 호스트 웹사이트에 붙어있기 때문에 플러그인의 스타일을 정의하는 CSS도 호스트 웹사이트에 Inject 되어야합니다. 호스트 웹사이트의 CSS와 플러그인의 CSS가 같은 스코프에 존재하기 때문에 우리가 의도한 스타일이 제대로 표현되지 않을 가능성이 있습니다. 실제로 이 문제는 런칭 초기에 우리를 가장 괴롭혔던 문제입니다. 쉽게 생각해볼 수 있는 방법은 아래와 같습니다.플러그인의 CSS에 네임스페이스를 둔다.(플러그인 CSS가 호스트 웹사이트 CSS에 주는 영향을 차단함)CSS 의 우선순위를 이해하고 플러그인 CSS의 우선순위가 항상 높도록 처리한다. (CSS Specificity 링크 참조)하지만 위처럼 처리하더라도 모든 경우에 대해 해결이 되는 것은 아닙니다. 주된 이유는 우리가 개발을 할 때 모든 CSS 속성을 정의하지 않기 때문입니다. 플러그인에서 정의하지 않은 속성을 호스트 웹사이트에서 사용한다면 호스트 웹사이트의 스타일이 적용될 것입니다. 또 특수한 경우이긴 하지만 만약 호스트 웹사이트에 !important 가 적용되어 있다면 그 속성이 덮어씌워지게 됩니다.!important는 사용하지 맙시다..ㅜ아이디어: 스타일 Normalizing?여기에서 의미하는 Normalizing은 모든 DOM 엘리먼트에 가능한 모든 CSS 속성의 기본값을 정의하는 것을 의미합니다. 크로미움을 기준으로 모든 CSS 속성 목록은 이 곳을 참조하시면 됩니다. 이것을 바탕으로 normalize.css를 만들어 적용했습니다.이 방법을 적용한 이후로는 스타일이 오버라이딩되는 문제는 어느 정도 해결되었습니다. 물론 !important에 대한 대응은 여전히 되지 않지만요. 그런데 예상하지 못한 부작용이 발생했는데 첫번째는 디버깅할 때 크롬 인스펙터가 도저히 사용하지 못할 정도로 느리다는 것입니다. 두번째는 CSS가 inheritance 가 안 되고 기본 엘리먼트 셀렉터의 우선순위가 높아서 직접 코딩해야하는 CSS가 2~3배는 길어지는 불편함입니다. 위 두 이유로 개발 피로도가 상당히 높아져서 머지 않아 다른 방법을 알아보게 되었습니다.3. iframe 도입위에 나열한 문제들을 해결할 수 있는 아이디어로 iframe을 리서치하게 되었습니다. 사실 iframe은 최근 웹서비스에서는 잘 사용하지 않기도 하고, 보통은 사용하지 않는 것을 권장하기도 하죠. 따라서 저희 팀에서도 처음에는 고려사항이 아니었는데요 우리와 유사하게 채팅 인터페이스를 제공하는 인터콤에서 iframe 을 적용한 것으로부터 아이디어를 얻어왔습니다.원래 목적에 맞게 사용하지 않으면 독이 됩니다.iframe은 HTML 도큐멘트 안에서 또 다른 도큐멘트를 임베드합니다. iframe 내에 있는 도큐멘트는 호스트 도큐멘트와 자바스크립트 스코프가 분리되어 있고, CSS가 적용되는 스코프 역시 분리되어 있습니다.이런 속성 때문에 위에 나열한 문제들을 원천 차단할 수 있습니다. 자바스크립트 스코프가 분리되어 있기 때문에 글로벌 네임스페이스에 접근해도 호스트 웹사이트에는 전혀 영향이 없고, 자바스크립트의 에러로 인해 다른 쪽 자바스크립트까지 실행을 멈추는 오동작을 막을 수 있습니다. CSS 역시 Normalizing 을 하지 않더라도 호스트 웹사이트와 플러그인은 완벽히 분리가 됩니다.4. iframe 의 단점iframe을 도입하여 1, 2번에 나열한 문제들은 해결했지만 그에 따른 작은 문제들도 발생했습니다. 첫번째는 iframe도입 시 가장 먼저 고민해야할 부분인데 바로 3rd-party cookie 문제입니다. iframe 안에서 로드되는 도큐멘트는 3rd-party 컨텐츠로 인식합니다. IE에서는 기본 설정이 3rd-party cookie 허용을 하지 않기 때문에 쿠키를 사용해서 인증을 구현한 경우 문제가 될 수 있습니다.두번째는 도큐멘트가 분리됨에 따라 발생하는 코딩상의 여러 불편함들입니다. 여기에서는 범위를 벗어나 더 자세하게는 설명하지 않겠지만 도큐멘트가 분리되니 조금 더 신경써야할 것들이 있었습니다.저희 팀의 경우 쿠키 인증 방식이 아닌 토큰 형태의 인증도 지원을 하고 있었기 때문에 첫번째는 크게 문제되지 않았고 두번째 문제도 얻는 이득에 비하면 불편함을 감수하는 편이 훨씬 좋다는 판단이 들어서 도입을 결정했습니다.마무리플러그인 개발을 시작할 당시에 우리 팀은 웹 SDK 형태의 프로젝트 개발 경험이 없었습니다. 리서치를 해도 플러그인 개발과 관련된 아티클이나 리소스 그리고 보일러플레이트 프로젝트도 많지 않았습니다. 프레임워크, 아키텍쳐를 선택하는 것부터 프로젝트를 구성하는 것부터 개발, 배포 및 운영에 이르기까지 일반적인 웹서비스를 개발할 때와 조금 다른 고민들을 해왔던 것 같습니다. 앞으로 저희가 해 온 고민을 공유하려고 합니다. 저희와 같은 플러그인, SDK 형태의 제품을 개발하고 계신 분들에게 도움이 되었으면 좋겠습니다.#조이코퍼레이션 #개발자 #개발팀 #인사이트 #경험공유 #일지

지난 Part 1 포스팅에 이어 자바스크립트 기초 문법에 대해 정리해보았습니다. 이번 포스팅에서는 여러 객체와 그 객체에서 제공하는 각 메서드에 대해 정리하였습니다. 다루는 객체의 여러 메서드에 대해 정리하였기 때문에 전 포스팅처럼 간략하지는 않지만 이번 포스팅을 저장해 두고 자바스크립트로 개발하면서 필요할 때마다 참고하여 보기에는 좋을 것 같습니다. 다만, 메서드 사용 예의 코드는 넣지 않았으니 예제 부분이 필요하다면 필히 공식 문서를 참고해주세요. 익히는 것 자체도 공식 문서를 통하여 보는 것이 가장 좋지만 혹여 영어에 취약하신 분이라면 이 포스팅을 참고하는 것도 괜찮을 것 같습니다. :)내장 객체브라우저의 자바스크립트 엔진에 내장된 객체. String/Date/Array/Nath/RegExp Object 등이 있음.날짜 객체 DateDate 객체 생성new Date()new Date(milliseconds)new Date(dateString)new Date(year, month, day, hours, minutes, seconds, milliseconds)Date Get 메서드getDate() - 일 정보를 가져옴.getDay() - 요일 정보를 가져옴. 0(일요일)-6(토요일)getFullYear - 연도 정보를 가져옴. (yyyy)getHours() - 시간 정보를 가져옴.getMilliseconds() - 밀리초 정보를 가져옴. 0-999 (1/1000 초의 단위)getMinutes() - 분 정보를 가져옴.getMonth() - 월 정보를 가져옴. 현재 월에서 -1한 값으로 옴.getSeconds() - 초 정보를 가져옴.getTime() - 1970년 1월 1일부터 경과된 시간을 밀리초로 가져옴.Date Set 메서드setDate() - 일 정보를 설정.setFullYear() - 연도 정보를 설정. 원한다면 월과 일 정보도 설정할 수 있다.setHours() - 시간 정보를 설정.setMillseconds() - 밀리초 정보를 설정.setMinutes() - 분 정보를 설정.setSeconds() - 초 정보를 설정.setTime() - 1970년 1월 1일부터 경과된 시간을 밀리초로 설정.기타 Date 메서드now() - 1970년 1월 1일부터 지금까지의 밀리초를 반환.parse() - 날짜 형태의 문자열을 변환하여 1970년 1월 1일부터 입력한 날짜까지의 밀리초를 반환.toString() - Date 객체를 문자열로 변환.toJSON() - Date 객체를 JSON 데이터로 변환.valueOf() - Date 객체를 밀리초로 반환.숫자 객체 NumberNumber 생성var num = 1;      var num2 = new Number(1);Number 객체의 속성MAX_VALUE - 표현 가능한 가장 큰 수.MIN_VALUE - 표현 가능한 가장 작은 수.POSITIVE_INFINITY - 무한대 수 표기.NEGATIVE_INFINITY - 음의 무한대 수 표기.NaN - 숫자가 아닌 경우 표기.Number 객체 메서드toExponential(n) - 자수 표기법으로 소수점 n자리만큼 문자형 데이터로 반환.toFixed(n) - 소수점 n자리만큼 반올림하여 문자형 데이터로 반환.toPrecision(n) - 유효 숫자 n의 개수만큼 반올림하여 문자형 데이터로 반환.toString() - 숫자형 데이터를 문자형 데이터로 반환.valueOf() - 객체의 원래 값을 반환.parseInt(값) - 데이터를 정수로 변환하여 반환.parseFloat(값) - 데이터를 실수로 변환하여 반환.수학 객체 MathMath 메서드 및 상수Math.abs(숫자) - 숫자의 절댓값을 반환.Math.max(숫자1, 숫자2, 숫자3) - 숫자 중 최댓값을 반환.Math.min(숫자1, 숫자2, 숫자3) - 숫자 중 최솟값을 반환.Math.pow(숫자, 제곱값) - 숫자의 거듭제곱한 값을 반환.Math.random() - 0~1 사이의 난수를 반환.Math.round(숫자) - 소수점 첫째 자리에서 반올림하여 정수를 반환.Math.ceil(숫자) - 소수점 첫째 자리에서 무조건 올림에서 정수를 반환.Math.floor(숫자) - 소수점 첫째 자리에서 무조건 내림해서 정수를 반환.Math.sqrt(숫자) - 숫자의 제곱근 값을 반환.Math.PI - 원주율 상수를 반환.배열 객체 ArrayArray 생성var array = new Array();array[0] = 1;array[1] = 2;var array2 = new Array(1, "temp", true);var array3 = [1, true, "문자열도 가능"];Array 객체의 메서드 및 속성join(연결문자) - 배열 객체에 데이터를 연결 문자 기준으로 1개의 문자형 데이터로 반환.reverse() - 배열 객체에 데이터의 순서를 거꾸로 바꾼 후 반환.sort() - 배열 객체에 데이터를 오름차순으로 정렬.slice(index1, index2) - 배열 객체에 데이터 중 원하는 인덱스 구간만큼 잘라서 배열 객체로 가져옴.splice() - 배열 객체에 지정 데이터를 삭제하고 그 구간에 새 데이터를 삽입할 수 있음.concat() - 2개의 배열 객체를 하나로 결합.pop() - 배열에 저장된 데이터 중 마지막 인덱스에 저장된 데이터 삭제.push(new data) - 배열 객체에 마지막 인덱스에 새 데이터를 삽입.shift() - 배열 객체에 저장된 데이터 중 첫 번째 인덱스에 저장된 데이터를 삭제.unshift(new data) - 배열 객체의 가장 앞의 인덱스에 새 데이터를 삽입.length - 배열에 저장된 총 데이터의 개수를 반환.문자 객체 StringString 생성var str = "hello";      var str2 = new String("hi");String 객체 메서드 및 속성charAt(index) - 문자열에서 인덱스 번호에 해당하는 문자 반환.indexOf("찾을 문자") - 문자열에서 왼쪽부터 찾을 문자와 일치하는 문자를 찾아 최초로 일치하는 문자의 인덱스 번호를 반환. 찾는 문자가 없으면 -1 반환.lastIndexOf("찾을 문자") - indexOf와 동일하나 문자열의 오른쪽부터 찾음.match("찾을 문자") - indexOf와 동일하나 찾는 문자가 없으면 null을 반환.replace("바꿀 문자", "새 문자") - 문자열에서 왼쪽부터 바꿀 문자와 일치하는 문자를 찾아 최초로 찾은 문자를 새 문자로 치환.search("찾을 문자") - 문자열 왼쪽부터 찾을 문자와 일치하는 문자를 찾아 최초로 일치하는 인덱스 번호를 반환.slice(a, b) - a개의 문자를 자르고 b번째 이후에 문자를 자른 후 남은 문자를 반환.substring(a, b) - a 인덱스부터 b 인덱스 이전 구간의 문자를 반환.substr(a, 문자 개수) - 문자열에 a 인덱스부터 지정한 문자 개수만큼 문자열을 반환.split("문자") - 지정한 문자를 기준으로 문자 데이터를 나누어 배열에 저장하여 반환.toLowerCase() - 문자열에서 영문 대문자를 모두 소문자로 바꿈.toUpperCase() - 문자열에서 영문 소문자를 모두 대문자로 바꿈.length - 문자열에서 문자의 개수를 반환.concat("새로운 문자") - 문자열에 새로운 문자열을 결합.charCodeAt("찾을 문자") - 찾을 문자의 아스키 코드 값을 반환.fromCharCode(아스키 코드 값) - 아스키 코드 값에 해당하는 문자를 반환.trim() - 문자의 앞 또는 뒤에 공백 문자열을 삭제.브라우저 객체 모델(BOM)브라우저에 내장된 객체. window 객체브라우저 객체의 최상위 객체.window 객체 메서드open("url 경로", "창 이름", "옵션 설정") - 새 창을 열 때 사용.- open() 메서드 옵션 설정: width/height/left/top/location/status/scrollbars/tollbarsalert("메세지") - 경고 창을 띄움.prompt("질의 내용", "기본 답변") - 질의응답 창을 띄움.confirm("질의 내용") - 확인/취소 창을 띄움.- 확인 클릭시 true 반환, 취소 클릭시 false 반환.moveTo(x 위치값, y 위치값) - 창의 위치를 이동시킬 때 사용.resizeTo(너빗값, 높잇값) - 창의 크기를 변경시킬 때 사용.setInterval("스크립트 실행문", 시간 간격) - 일정 간격으로 반복하여 실행문을 실행시킬 때 사용.clearIntervar(참조 변수) - 참조 변수에 참조되어 있는 setInterval() 삭제.setTimeout("스크립트 실행문", 시간 간격) - 일정 간격으로 한 번만 실행문을 실행시킬 때 사용.clearTimeout(참조 변수) - 참조 변수에 참조되어 있던 setTimeout() 삭제.screen 객체사용자의 모니터 정보를 제공하는 객체.screen 객체 속성width/height/availWidth/availHeight/colorDepth(사용자 모니터가 표현 가능한 컬러 bit)location 객체사용자 브라우저의 주소 창에 url에 대한 정보와 새로 고침 기능을 제공하는 객체.location 객체 속성 및 메서드href - 주소 영역에 참조 주소를 설정하거나 URL 반환.hash - URL의 해시값을 반환.hostname - URL의 호스트 이름을 설정하거나 반환.host - URL의 호스트 이름과 포트 번호를 반환.port - URL의 포트 번호를 반환.protocol - URL의 프로토콜을 반환.search - URL의 쿼리를 반환.reload() - 새로 고침.history 객체사용자가 방문한 사이트 중 이전에 방문한 사이트와 다음 방문한 사이트로 다시 돌아갈 수 있는 속성과 메서드를 제공하는 객체.history 메서드 및 속성back() - 이전 방문한 페이지로 이동.forward() - 다음 방문한 페이지로 이동.go(이동 숫자) - 이동 숫자만큼의 페이지로 이동. 음의 값이면 이전 페이지로 이동.length - 방문 기록에 저장된 목록의 개수 반환.navigator 객체현재 방문자가 사용하는 브라우저 정보와 운영체제의 정보를 제공하는 객체.navigator 속성appCodeName - 방문자의 브라우저 코드명을 반환.appName - 방문자의 브라우저 이름 반환.appVersion - 방문자의 브라우저 버전 정보를 반환.language - 방문자의 브라우저 사용 언어를 반환.product - 방문자의 브라우저 사용 엔진 이름을 반환.platform - 방문자의 브라우저를 실행하는 운영체제를 반환.userAgent - 방문자의 브라우저와 운영체제의 종합 정보를 제공.문자 객체 모델(DOM)HTML 문서의 구조.선택자직접 선택자직접 문서에서 요소를 선택함. (id/class/폼 명/요소 명 등)document.getElementById("아이디 명") - 아이디를 이용해 요소를 선택.document.getElmentsByTagName("요소 명") - 요소의 이름을 이용해 요소를 선택.document.formName.inputName - 폼 요소에 name 속성을 이용해 요소를 선택.인접 관계 선택자직접 선택자를 사용해 선택해 온 문서 객체를 기준으로 가까이에 있는 요소를 선택함. (parentNode/childeNodes 등)parentNode - 선택한 요소의 부모 요소를 선택.childNodes - 선택한 요소의 모든 자식 요소를 선택. 선택한 모든 요소가 저장됨.firstChild - 선택한 요소의 첫 번째 자식 요소만 선택.previousSibling - 선택한 요소의 이전에 오는 형제 요소만 선택.nextSibling - 선택한 요소의 다음에 오는 형제 요소만 선택.문서 객체 이벤트 핸들러 적용하기onclick - 선택한 요소를 클릭했을 때 이벤트 발생.onmousevoer - 선택한 요소에 마우스를 올렸을 때 이벤트 발생.onmouseout - 선택한 요소에 마우스가 벗어났을 때 이벤트 발생.submit - 선택한 폼에 전송이 일어났을 떄 이벤트 발생.버튼document.getElementById("btn").onclick = function() {    alert("welcome");}일단은 참고하는 책을 기준으로하여 정리해보았는데 후에 시간이 될 때마다 공식 문서를 참고하여 번역한다는 생각으로 보다 세부적인 사항을 정리해도 좋을 것 같다는 생각이 드네요. 우선적으로는 빠르게 함수와 이벤트에 대해 배우고 객체에 대한 더 자세한 사항을 정리하도록 하겠습니다. 다음 포스팅은 자바스크립트의 함수와 이벤트에 대해 다룰 예정입니다!참고문헌:Do it! 자바스크립트+제이쿼리 입문 - 정인용JavaScript 튜토리얼 문서 (http://www.w3schools.com/js/default.asp)티스토리 블로그와 동시에 포스팅을 진행하고 있습니다.http://madeitwantit.tistory.com#트레바리 #개발자 #안드로이드 #앱개발 #Node.js #백엔드 #인사이트 #경험공유

비트윈에서는 서비스 초기부터 HBase를 주요 데이터베이스로 사용하였습니다. HBase에서도 일반적인 다른 NoSQL처럼 트랜잭션을 제공하지 않습니다. HBase, Cassandra와 MongoDB는 하나의 행 혹은 하나의 Document에 대한 원자적 연산만 제공합니다. 하지만 여러 행에 대한 연산들을 원자적으로 실행할 수 있게 해주는 추상화된 트랜잭션 기능이 없다면 보통의 서비스 개발에 어려움을 겪게 됩니다. 비트윈 개발팀은 이런 문제를 해결하기 위해 노력했으며, 결국 HBase에서 트랜잭션을 제공해주는 라이브러리인 Haeinsa를 구현하여 실제 서비스에 적용하여 성공적으로 운영하고 있습니다. VCNC에서는 Haeinsa를 오픈소스로 공개하고 이번 글에서 이를 소개하고자 합니다.Haeinsa란 무엇인가?Haeinsa는 Percolator에서 영감을 받아 만들어진 트랜잭션 라이브러리입니다. HAcid, HBaseSI 등 HBase상에서 구현된 트랜잭션 프로젝트는 몇 개 있었지만, 성능상 큰 문제가 있었습니다. 실제로 서비스에 적용할 수 없었기 때문에 Haeinsa를 구현하게 되었습니다. Haeinsa를 이용하면 다음과 같은 코드를 통해 여러 행에 대한 트랜잭션을 쉽게 사용할 수 있습니다. 아래 예시에는 Put연산만 나와 있지만, 해인사는 Put외에도 Get, Delete, Scan 등 HBase에서 제공하는 일반적인 연산들을 모두 제공합니다.HaeinsaTransaction tx = tm.begin(); HaeinsaPut put1 = new HaeinsaPut(rowKey1); put1.add(family, qualifier, value1); table.put(tx, put1); HaeinsaPut put2 = new HaeinsaPut(rowKey2); put2.add(family, qualifier, value2); table.put(tx, put2); tx.commit(); Haeinsa의 특징Haeinsa의 특징을 간략하게 정리하면 다음과 같습니다. 좀 더 자세한 사항들은 Haeinsa 위키를 참고해 주시기 바랍니다.ACID: Multi-Row, Multi-Table에 대해 ACID 속성을 모두 만족하는 트랜잭션을 제공합니다.Linear Scalability: 트래픽이 늘어나더라도 HBase 노드들만 늘려주면 처리량을 늘릴 수 있습니다.Serializability: Snapshot Isolation보다 강력한 Isolation Level인 Serializability를 제공합니다.Low Overhead: NoSQL상에서의 트랜잭션을 위한 다른 프로젝트에 비해 오버헤드가 적습니다.Fault Tolerant: 서버나 클라이언트가 갑자기 죽더라도 트렌젝션의 무결성에는 아무 영향을 미치지 않습니다.Easy Migration: Haeinsa는 HBase를 전혀 건드리지 않고 클라이언트 라이브러리만 이용하여 트랜잭션을 구현합니다. 각 테이블에 Haeinsa 내부적으로 사용하는 Lock Column Family만 추가해주면 기존에 사용하던 HBase 클러스터에도 Haeinsa를 쉽게 적용할 수 있습니다.Used in practice: 비트윈에서는 Haeinsa를 이용하여 하루에 3억 건 이상의 트랜잭션을 처리하고 있습니다.Haeinsa는 오픈소스입니다. 고칠 점이 있다면 언제든지 GitHub에 리포지터리에서 개선에 참여하실 수 있습니다.Haeinsa의 성능Haeinsa는 같은 수의 연산을 처리하는 트랜잭션이라도 소수의 Row에 연산이 여러 번 일어나는 경우가 성능상 유리합니다. 다음 몇 가지 성능 테스트 그래프를 통해 Haeinsa의 성능에 대해 알아보겠습니다.아래 그래프는 3개의 Row에 총 6개의 Write, 3개의 Read연산을 수행한 트랜잭션의 테스트 결과입니다. 두 개의 Row에 3Write, 1Read 연산을 하고, 한 개의 Row에 1Read 연산을 한 것으로, 비트윈에서 가장 많이 일어나는 요청인 메시지 전송에 대해 시뮬레이션한 것입니다. 실제 서비스에서 가장 많이 일어나는 종류의 트랜잭션이라고 생각할 수 있습니다. 그런데 그냥 HBase를 사용하는 것보다 Haeinsa를 이용하는 것이 더 오히려 좋은 성능을 내는 것을 알 수 있습니다. 이는 Haeinsa에서는 커밋 시에만 모든 변경사항을 묶어서 한 번에 반영하기 때문에, 매번 RPC가 일어나는 일반 HBase보다 더 좋은 성능을 내는 것입니다.HBase 클러스터가 커질수록 트랜잭션 처리량이 늘어납니다. HBase와 마찬가지입니다.HBase 클러스터의 크기에 따른 응답시간 입니다. HBase와 다르지 않습니다..아래 그래프는 2개의 Row에 각각 한 개의 Write, 나머지 한 개의 Row에는 한 개의 Read 연산을 하는 트랜잭션에 대해 테스트한 것입니다. 각 Row에 하나의 연산만이 일어나기 때문에 최악의 경우라고 할 수 있습니다. 처리량과 응답시간 모두 그냥 HBase를 사용하는 것보다 2배에서 3배 정도 좋지 않은 것을 알 수 있습니다. 하지만 이 수치는 DynamoDB 상의 트랜잭션과 같은 다른 트랜잭션 라이브러리와 비교한다면 상당히 좋은 수준입니다.HBase보다 처리량이 떨어지긴 하지만, 클러스터가 커질수록 처리량이 늘어납니다.HBase보다 응답시간이 크긴 하지만 클러스터 크기에 따른 변화가 HBase와 크게 다르지 않습니다.프리젠테이션Haeinsa에 대한 전반적인 동작 원리와 성능을 소개하는 프리젠테이션입니다. 좀 더 자세히 알고 싶으시다면 아래 프리젠테이션이나 Haeinsa 위키를 참고해주세요.<iframe class="speakerdeck-iframe" frameborder="0" src="//speakerdeck.com/player/2d4b2bd00fc201314ae312fe4cd13937?" 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;">

2016년 4월에 에잇퍼센트에 합류해서 2016년을 에잇퍼센트와 함께 보냈다. 1년을 다 채운건 아니지만 에잇퍼센트의 성장과 발전에 개발자로서 어떤 기여를 했는지 한 번 정리해 보려고 한다. 나에게 있어서는 물론이고 에잇퍼센트에도 의미가 있을 것이다.1. 대출 개설 내역 신용평가사 공유대출자에게 대출이 실행되면 이 내역을 신용평가사의 시스템으로 공유하는 것을 개발했다. 에잇퍼센트에서 받은 대출 내역이 공유되면 타 금융권에서 대출 개설 내역을 확인할 수 있으므로 추가 대출이 쉽게 이루어지지 않을 것이다. 우리의 고객은 대출자도 있지만 투자자도 있다는 측면에서 투자자의 소중한 투자금을 안전하게 지켜내기 위한 안전 장치 중 하나가 될 수 있다.  2. 성능 개선에잇퍼센트는 빠르게 성장하고 있는 스타트업이다. 스타트업이 비즈니스적으로 빠른 실행을 하며 달리다 보면 성능의 벽에 부딪힐 때가 있는데 마침 내가 합류하고 얼마 되지 않은 시점이었다. 주로 우리의 개발 환경인 Python Django 코드를 개선하는 방향으로 진행을 했고 추후에는 사용자 브라우저단 성능 개선도 진행했다. Python Django 코드 개선에 대한 자세한 내용은 내가 쓴 블로그 포스팅에서 확인할 수 있다.3. 서버 인프라 서울 이전에잇퍼센트는 서버 인프라로 Amazon Web Services(이하 AWS)를 사용하고 있다. 서비스를 처음 시작할 때에는 AWS 도쿄 리전이 가장 가까운 곳이어서 도쿄 리전을 사용하고 있었다. 그러다가 2016년이 되어 서울 리전이 생겼고 도쿄 리전에 비해 네트워크도 빠르고 비용도 저렴해서 사용하지 않을 이유가 없었다. 그래서 도쿄 리전에서 서울 리전으로 이전하는 작업을 진행했다. 밤샘 작업을 함께 해준 개발팀원들에게 고맙다는 얘기를 다시 한번 하고 싶다.그 날의 풍경과 작업 기록, 그리고 django-storages 서울 리전 연동에 대한 글까지 남겨두었다.4. Python Django 버전 업그레이드에잇퍼센트에 합류했을 때 Python 3.4 , Django 1.8을 사용하고 있었고 Python 3.5 Django 1.9로 버전 업그레이드를 진행했다. 버전 업을 하면서 발견된 큰 문제는 없었고 Django admin 의 UI 에 flat 디자인이 적용되어 화면이 이뻐졌다. 내가 직접 한 건 아니지만 화면이 이뻐졌다고 다들 좋아해 준 기억이 난다.참고로 현재의 최신 버전은 Python 3.6 Django 1.10이다.5. 테스트 개선개발을 빠르게 하는 것도 중요하지만 안정적으로 잘 동작하는 것도 그에 못지않게 중요하다. 안정적인 서비스 개발과 운영을 위해 테스트가 중요하다. 특히나 돈을 다루는 금융회사라면 더욱 중요한 것이 테스트이기에 에잇퍼센트 개발팀에도 테스트는 매우 중요하다. 테스트 코드를 잘 작성해야 하고 테스트 코드가 실제 코드를 얼마나 커버하는지에 대한 측정도 필요하다. 에잇퍼센트는 코드를 개발해서 push 하고 pull request를 할 때마다 travis를 통해서 테스트를 수행하고 커버리지를 측정하고 있다. 커버리지 측정을 처음 시작할 때와 비교해보면 기존 대비 10% 포인트 가량 커버리지가 올라갔다. 커버리지가 떨어지면 pull request를 승인하지 않는 것을 정책으로 가져가고 있다.테스트 수행 시 커버리지 측정과 함께 PEP8 준수 확인, migration 체크, 템플릿 검증 등을 하도록 개선했다. 또한 기존에는 테스트 수행 시 sqlite3을 DB로 사용했는데 개선 후에는 실제로 사용하고 있는 PostgreSQL을 사용하도록 했다. 성능을 위해 raw SQL을 사용하는 경우가 가끔 있는데 이때 테스트가 제대로 안 되는 문제를 개선할 수 있었다.6. 개발 환경 개선유지 보수가 용이하고 효율적으로 개발하기 위한 환경을 만들기 위해 노력했다. smarturls, django-debug-toolbar, factory boy 등의 패키지를 적용했으며 로컬 서버 외에 개인별로 배포해서 테스트할 수 있는 서버 환경을 만들어서 테스트를 용이하게 했다. django 설정 분리, 모델 분리, 상수 분리 등의 리팩토링도 진행했다.7. NH핀테크 오픈플랫폼 적용 (진행 중)NH 농협 은행에서 제공하는 API를 사용해서 금융 관련 작업을 자동화하고 효율화하려고 한다. NH에서 요구하는 정보보호 및 보안 기준에 맞춰 시스템을 정비하고 만들어 나가는 중이다. 올해 상반기 안에 API 연동이 되어 에잇퍼센트에 NH핀테크 오픈플랫폼이 알맞게 녹아들어 가기를 기대해본다.8. 서비스 개선에잇퍼센트의 서비스적인 개선도 몇 가지 진행했다.- 채권 상세 페이지 개선 : 투자한 채권에 대한 지급 현황, 지난 내역을 볼 수 있게 되었다.- 로그인 상태 유지 : 기본 30분 로그인이 유지되고 30일 유지를 선택할 수 있게 되었다.- Ada 챗봇 연동 : 금융권 챗봇 중 유일하게 학습하는 Ada가 서비스와 연동하기 위한 개발을 진행했다.1~7번까지의 작업은 주로 눈에 보이지 않거나 개발팀 내부적인 개선이었고 8번은 사용자에게 바로 보이는 서비스적인 개선이었다. 위에 언급한 것 외에 코드 리뷰를 열심히 한 것이 기억에 남는다. 코드 리뷰를 통해 유지보수가 용이하고 효율적인 코드를 만들어 나가고 싶었다. 어떤 코드가 유지보수가 용이하고 효율적인지 리뷰를 통해 토론하고 배워나가는 과정이 나뿐만 아니라 개발팀 모두에게 도움이 되었으리라 본다.개인적으로는 이음에서 Ruby on Rails로 개발을 재밌게 하다가 에잇퍼센트에서의 Python Django를 사용한 개발로의 도전과 전환이었다. 새로운 언어를 접하고 배워나가는 과정 또한 개발자에게는 즐거움이 아닐까 싶다. Ruby, Python 둘 다 엄청나게 잘 하는 건 아니지만 기회가 되면 Ruby와 Python 각각의 장단점을 비교해보는 것도 재미있을 것 같다.2016년은 내가 2006년 첫 회사에 들어간 지 10년이 된 해였다. 10년 전 신입 사원 시절에는 서비스적인 개선을 주로 하고 다른 팀원에게 도움을 주기보다 내 할 일에만 충실했었다. 10년이 지난 지금 작년 한 해를 이렇게 돌아보니 서비스에 직접적인 개선도 하고 다른 팀원들이 개발을 더 잘할 수 있도록 환경을 만들고 도움을 주는 데에도 제법 역할을 했다는 생각이 든다. 나 자신이 엄청나게 변화한 건 아니지만 10년이 헛된 시간은 아니었다는 생각이 들어서 내심 뿌듯하다.2016년을 이렇게 정리하고 보니 2017년에는 더 잘 해야겠다는 생각이 든다. 에잇퍼센트 모든 구성원들과 함께 엄청나고 멋지게 성장해 보고 싶다. 화이팅!2016년 처럼 올해도 해맑게 화이팅!#8퍼센트 #에잇퍼센트 #조직문화 #기업문화 #2016년 #돌아보기 #스타트업개발자 #개발자

웹기반 컨텐츠 저작 도구 셀프(XELF) v1.0 (Web-based Contents Authoring Tool XELF v1.0)이 한국정보통신기술협회(TTA) 소프트웨어 시험인증연구소로부터 GS인증 1등급을 획득하였습니다.  셀프(XELF)는 별도의 프로그램 설치 없이도 접속만으로 웹브라우저 상에서 다양한 용도의 콘텐츠를 저작할 수 있는 디자인 플랫폼입니다. 디자인 전문가가 아니어도 누구나 손쉽게 프리젠테이션, 웹브로셔, 유저 인터페이스, 문서 등 비즈니스 및 교육환경에 필요한 다양한 콘텐츠를 디자인할 수 있습니다. 또, 이렇게 제작된 콘텐츠는 클릭만으로 SNS에 공유하거나 이메일로 전달하는 등 간편하게 활용할 수 있는 장점을 가지고 있습니다.   GS인증은 엄격한 시험을 통해 품질이 우수한 소프트웨어를 인증해주는 국가공인 소프트웨어 품질인증제도로 공공기관에서 우선 구매 대상으로 지정되기도 합니다. ISO 국제표준을 기준으로 SW의 기능성, 신뢰성, 효율성, 사용성, 유지보수성, 이식성, 성능 등을 평가하고 검증을 거쳐 부여되었습니다. ㈜그로비스인포텍은 이번 GS인증을 계기로 디자인 플랫폼으로서의 기술성과에 자신감을 가지고 향후 계획된 베타서비스 준비에 최선을 다하고 있습니다. 더 나은 사용성과 기술적 안정성을 목표로 다양한 환경에 적용하고 테스트를 진행하고 있습니다. 곧이어 더 향상된 성능과 기능으로 찾아뵙길 기대하겠습니다. 감사합니다.

오프라인 고객 분석 솔루션 워크인사이트를 개발해 온 조이는 최근 온라인 접객 서비스 채널을 런칭했습니다. 이 글은 채널과 관련된 기술 블로그의 첫번째 글로 채널 데스크 프론트엔드(웹, 윈도우, OSX)의 기술 스택 및 개발 환경을 소개하도록 하겠습니다.React채널 개발을 처음 시작할 당시 (지금으로부터 1년 전) 에 워크인사이트 대시보드 및 기타 사내 툴에서는 AngularJS 1을 사용하고 있었습니다. 비교적 적은 코드로 복잡한 애플리케이션을 빠르게 만들 수 있는 점에는 만족했지만 퍼포먼스면에서는 아쉬운 부분이 많았습니다. 따라서 새로운 프레임워크 및 라이브러리를 리서치 했고 매우 가볍고 렌더링 퍼포먼스 면에서 AngularJS 1 대비 우위에 있던 React 를 사용하기로 결정했습니다.컴포넌트의 설계 패턴은 Redux를 만든 Dan이 제안한 Container 와 Presentational 컴포넌트를 구분하는 방식으로 설계하고 있습니다. 따라서 Container 가 data fetch 및 update 등의 액션을 실행하고 Presentational 컴포넌트들을 조합하여 렌더링을 하게 됩니다.React를 실제 1년째 사용해 본 결과 저를 비롯한 팀원들은 매우 만족하고 있습니다. 구조, 스타일, 동작을 한 컴포넌트로 묶어 재사용성이 매우 높아졌으며 React의 휴리스틱한 Dom diff algorithm 덕분에 렌더링 퍼포먼스에서도 많은 이득을 얻을 수 있었습니다.Facebook Flux Utils아키텍쳐는 페이스북이 제안한 flux 철학에 따라 설계되었습니다. flux를 구현하기 위한 기본적인 유틸리티 기능을 제공하는 Flux Utils을 사용합니다. Flux의 많은 구현체 중에 요즘 가장 인기인 Redux도 고려했었습니다. 저희가 프로젝트를 시작할 당시에 Redux는 5~6개월밖에 되지 않은 프로젝트였고 거의 Dan의 1인 프로젝트였기 때문에 향후 메인터넌스를 장담할 수 없다고 판단했습니다. 그보다는 페이스북이 만든 Flux Utils가 그런 면에서는 더 안전할 거라고 생각했던 것이죠.약 1년 정도 Flux Utils로 개발해오며 몇 가지 문제를 겪게 되었습니다. 애플리케이션이 커지면서 관리해야할 State가 많아지고 그들 사이의 의존성 관리 때문에 Store의 복잡도가 빠르게 증가했습니다. 그에 따라 테스트가 어려워지고 올바른 유닛테스트를 위해서는 테스트 코드 역시 매우 복잡해지는 문제가 있었습니다.그래서 Redux를 다시 리서치하게 되었고, 결론적으로 “단일 Store, 다수Reducer” 라는 Redux의 철학을 통해 State 관리 로직(Reducer)을 단순하고 테스트도 쉽게 유지할 수 있겠다는 생각을 하게 되었습니다. 뿐만 아니라 그 동안 설계와 관련되어 고민하고 필요한 경우 저희 스스로 개발해서 사용하던 많은 부분이 Redux의 서브 프로젝트 형태로 (redux-actions, redux-thunk, reselect 등) 개발되어 사용되고 있는 것을 발견해서 Redux로의 마이그레이션을 결정했고 현재 진행 중에 있습니다.Electron이 글의 도입부에서 이야기한 것처럼 채널 데스크는 윈도우용, OSX용 애플리케이션으로도 제공됩니다. 채널 개발 초기 당시 윈도우, OSX 각각 네이티브로 만들 리소스가 부족했기 때문에 웹 기술 기반으로 네이티브 앱을 만들 수 있는 다양한 솔루션들을 리서치했고 그 중 Electron을 선택하게 되었습니다.Electron은 제가 정말 좋아하는 제품인 Slack, Simplenote에서 사용하고 알려져 있고 국내에서는 Remember 등에서 사용하고 있습니다. 초기 개발 당시에는 안정성에 의문을 제기하는 개발자들도 많았고 저희도 여러 문제와 삽질(인증, 패키징, 이슈 레포팅의 어려움, 메모리릭 등등)을 많이 겪긴 했습니다만 개인적으로는 충분히 프로덕션에 쓸 수 있을 정도 수준이라고 생각합니다. 무엇보다 프론트엔드 개발자가 매우 적은 노력으로도 네이티브 데스크탑 앱을 만들 수 있는 장점이 다른 모든 문제점을 상쇄하고도 남습니다.언어개발 언어로는 자바스크립트 ES6를 사용합니다. 언어를 선택할 당시에도 여러 옵션이 있었는데 가능하면 실험적이지 않고 표준을 사용하는 것이 미래 유지보수에 안전하다고 판단했습니다. 또한 다른 자바스크립트 대안 언어를 사용하지 않더라도 ES6 (일부 ES7 포함) 스펙도 충분히 효율적인 개발이 가능하다고 생각했습니다.코딩 스타일은 기본적으로 Airbnb의 코딩 스타일 가이드라인을 따르며 조이의 상황과 맞지 않는 부분은 엔지니어들과 상의 후 수정해서 사용하고 있습니다. 스타일 체크는 ESLint로 자동화한 뒤 Circle CI와 붙여서 모든 풀리퀘스트에 대해 점검하고 있습니다.테스트초기 개발할 때는 테스트 코드를 별도로 붙이지 않았습니다. 고객의 요구와 기타 상황에 따라 기획과 설계가 크게 변경되기도 했고 그 때마다 기민하게 반응하기 위해서, 어느 정도 확립된 제품이 되기 이전에는 테스트 코드는 작성하지 않는 것이 좋다고 판단했습니다. 이제는 많은 부분이 확정되었고 안정성이 중요해지기 시작했으며 애플리케이션이 커지면서 자동화된 테스트는 필수가 되기 시작했기에 최근에 도입을 하고 있습니다.테스트를 위한 도구는 Jest, Enzyme 등을 사용합니다. Presentational 컴포넌트에 대한 테스트는 props에 따라 원하는 형태로 렌더링이 이루어지는지, 이벤트에 따라 콜백이 잘 실행되는지 등의 Spec 을 작성합니다. Container 컴포넌트에 대한 테스트는 각종 이벤트 및 동작을 시뮬레이션하고 그에 따라 Action이 잘 발생하는지 또는 내부 state가 잘 변경되는지를 테스트합니다. 또한 Store (또는 Reducer), Action Creator, Model, Util 등 모든 구성 요소에 대한 테스트를 붙이려고 노력하고 있습니다. 유닛 테스트가 아닌 e2e 테스트 혹은 css 스타일 테스트 등은 하지 않고 있습니다.빌드 및 배포현재 채널 데스크는 Client-side rendering을 합니다. 초기 로딩 속도가 느리다는 단점이 있어서 Server-side rendering으로의 전환도 고려하고 있습니다. 이미 Node.js 를 사용하고 있어서 Isomorphic Javascript의 형태로 어렵지 않게 전환이 가능합니다.작성된 자바스크립트는 Babel로 컴파일되고 Webpack으로 번들화됩니다. css를 포함한 각종 리소스들 역시 Webpack을 통해 처리됩니다. 웬만한 작업은 npm과 Webpack으로만 자동화하려고 했으며, Electron과 관련된 작업(패키징, 인증 등)들만 gulp를 이용해 자동화됩니다. 모든 리소스들은 Node.js + express 서버로 Serving 되고, Node.js 앱은 Docker로 빌드되어 AWS EC2로 배포됩니다.마무리이상으로 채널 데스크 프론트엔드의 기술 스택을 소개해드렸습니다. 앞으로 각 부분 별로 저희 팀이 고민해 온 문제들과 해결 방법을 공유하고자 합니다. 뛰어난 개발자 분들의 많은 관심과 피드백 부탁드립니다!

커플 필수 앱 비트윈은 여러 종류의 오픈 소스를 기반으로 이루어져 있습니다. 그 중 하나는 HBase라는 NoSQL 데이터베이스입니다. VCNC에서는 HBase를 비트윈 서비스의 메인 데이터베이스로써 사용하고 있으며, 또한 데이터 분석을 위한 DW 서버로도 사용하고 있습니다.그동안 두 개의 HBase Cluster 모두 최적화를 위해서 여러 가지 설정을 테스트했고 노하우를 공유해 보고자 합니다. 아랫은 저희가 HBase를 실제로 저희 서비스에 적용하여 운영하면서 최적화한 시스템 구성과 설정들을 정리한 것입니다. HBase를 OLTP/OLAP 목적으로 사용하고자 하는 분들에게 도움이 되었으면 좋겠습니다. 아래 구성을 최적화하기 위해서 했던 오랜 기간의 삽질기는 언젠가 따로 포스팅 하도록 하겠습니다.HBaseHBase는 Google이 2006년에 발표한 BigTable이라는 NoSQL 데이터베이스의 아키텍처를 그대로 따르고 있습니다. HBase는 뛰어난 Horizontal Scalability를 가지는 Distributed DB로써, Column-oriented store model을 가지고 있습니다. 사용량이 늘어남에 따라서 Regionserver만 추가해주면 자연스럽게 Scale-out이 되는 구조를 가지고 있습니다. 또한, Hadoop 특유의 Sequential read/write를 최대한 활용해서 Random access를 줄임으로 Disk를 효율적으로 사용한다는 점을 특징으로 합니다. 이 때문에 HBase는 보통의 RDBMS와는 다르게 Disk IO가 병목이 되기보다는 CPU나 RAM 용량이 병목이 되는 경우가 많습니다.HBase는 많은 회사가 데이터 분석을 하는 데 활용하고 있으며, NHN Line과 Facebook messenger 등의 메신저 서비스에서 Storage로 사용하고 있습니다.시스템 구성저희는 Cloudera에서 제공하는 HBase 0.92.1-cdh4.1.2 release를 사용하고 있으며, Storage layer로 Hadoop 2.0.0-cdh4.1.2를 사용하고 있습니다. 또한, Between의 데이터베이스로 사용하기 위해서 여러 대의 AWS EC2의 m2.4xlarge 인스턴스에 HDFS Datanode / HBase Regionserver를 deploy 하였습니다. 이는 m2.4xlarge의 큰 메모리(68.4GB)를 최대한 활용해서 Disk IO를 회피하고 많은 Cache hit이 나게 하기 위함입니다.또한 Highly-Available를 위해서 Quorum Journaling node를 활용한 Active-standby namenode를 구성했으며, Zookeeper Cluster와 HBase Master도 여러 대로 구성하여 Datastore layer에서 SPOF를 전부 제거하였습니다. HA cluster를 구성하는 과정도 후에 포스팅 하도록 하겠습니다.HDFS 최적화 설정dfs.datanode.handler.countHDFS에서 외부 요청을 처리하는 데 사용할 Thread의 개수를 정하기 위한 설정입니다. 기본값은 3인데 저희는 100으로 해 놓고 사용하고 있습니다.dfs.replicationHDFS 레벨에서 각각의 데이터가 몇 개의 독립된 인스턴스에 복사될 것 인가를 나타내는 값입니다. 저희는 이 값을 기본값인 3으로 해 놓고 있습니다. 이 값을 높이면 Redundancy가 높아져서 데이터 손실에 대해서 더 안전해지지만, Write 속도가 떨어지게 됩니다.dfs.datanode.max.transfer.threads하나의 Datanode에서 동시에 서비스 가능한 block 개수 제한을 나타냅니다.과거에는 dfs.datanode.max.xcievers라는 이름의 설정이었습니다.기본값은 256인데, 저희는 4096으로 바꿨습니다.ipc.server.tcpnodelay / ipc.client.tcpnodelaytcpnodelay 설정입니다. tcp no delay 설정은 TCP/IP network에서 작은 크기의 패킷들을 모아서 보냄으로써 TCP 패킷의 overhead를 절약하고자 하는 Nagle's algorithm을 끄는 것을 의미합니다. 기본으로 두 값이 모두 false로 설정되어 있어 Nagle's algorithm이 활성화되어 있습니다. Latency가 중요한 OLTP 용도로 HBase를 사용하시면 true로 바꿔서 tcpnodelay 설정을 켜는 것이 유리합니다.HBase 최적화 설정hbase.regionserver.handler.countRegionserver에서 외부로부터 오는 요청을 처리하기 위해서 사용할 Thread의 개수를 정의하기 위한 설정입니다. 기본값은 10인데 보통 너무 작은 값입니다. HBase 설정 사이트에서는 너무 큰 값이면 좋지 않다고 얘기하고 있지만, 테스트 결과 m2.4xlarge (26ECU) 에서 200개 Thread까지는 성능 하락이 없는 것으로 나타났습니다. (더 큰 값에 관해서 확인해 보지는 않았습니다.)저희는 이 값을 10에서 100으로 올린 후에 약 2배의 Throughput 향상을 얻을 수 있었습니다.hfile.block.cache.sizeHBase 의 block 들을 cache 하는데 전체 Heap 영역의 얼마를 할당한 것인지를 나타냅니다. 저희 서비스는 Read가 Write보다 훨씬 많아서 (Write가 전체의 약 3%) Cache hit ratio가 전체 성능에 큰 영향을 미칩니다.HBase 에서는 5분에 한 번 log 파일에 LruBlockCache (HBase 의 Read Cache) 가 얼마 만큼의 메모리를 사용하고 있고, Cache hit ratio가 얼마인지 표시를 해줍니다. 이 값을 참조하셔서 최적화에 사용하실 수 있습니다.저희는 이 값을 0.5로 설정해 놓고 사용하고 있습니다. (50%)hbase.regionserver.global.memstore.lowerLimit / hbase.regionserver.global.memstore.upperLimit이 두 개의 설정은 HBase에서 Write 한 값들을 메모리에 캐쉬하고 있는 memstore가 Heap 영역의 얼마만큼을 할당받을지를 나타냅니다. 이 값이 너무 작으면 메모리에 들고 있을 수 있는 Write의 양이 한정되기 때문에 디스크로 잦은 flush가 일어나게 됩니다. 반대로 너무 크면 GC에 문제가 있을 수 있으며 Read Cache로 할당할 수 있는 메모리를 낭비하는 것이기 때문에 좋지 않습니다.lowerLimit와 upperLimit의 두 가지 설정이 있는데, 두 개의 설정이 약간 다른 뜻입니다.만약 memstore 크기의 합이 lowerLimit에 도달하게 되면, Regionserver에서는 memstore들에 대해서 'soft'하게 flush 명령을 내리게 됩니다. 크기가 큰 memstore 부터 디스크에 쓰이게 되며, 이 작업이 일어나는 동안 새로운 Write가 memstore에 쓰일 수 있습니다.하지만 memstore 크기의 합이 upperLimit에 도달하게 되면, Regionserver는 memstore들에 대한 추가적인 Write를 막는 'hard'한 flush 명령을 내리게 됩니다. 즉, 해당 Regionserver이 잠시 동안 Write 요청을 거부하게 되는 것입니다. 보통 lowerLimit에 도달하면 memstore의 크기가 줄어들기 때문에 upperLimit까지 도달하는 경우는 잘 없지만, write-heavy 환경에서 Regionserver가 OOM으로 죽는 경우를 방지하기 위해서 hard limit가 존재하는 것으로 보입니다.hfile.block.cache.size와 hbase.regionserver.global.memstore.upperLimit의 합이 0.8 (80%)를 넘을 수 없게 되어 있습니다. 이는 아마 read cache 와 memstore의 크기의 합이 전체 Heap 영역 중 대부분을 차지해 버리면 HBase의 다른 구성 요소들이 충분한 메모리를 할당받을 수 없기 때문인 듯합니다.저희는 이 두 개의 설정 값을 각각 0.2, 0.3으로 해 놓았습니다. (20%, 30%)ipc.client.tcpnodelay / ipc.server.tcpnodelay / hbase.ipc.client.tcpnodelayHDFS의 tcpnodelay 와 비슷한 설정입니다. 기본값은 전부 false입니다.이 설정을 true로 하기 전에는 Get/Put 99%, 99.9% Latency가 40ms 와 80ms 근처에 모이는 현상을 발견할 수 있었습니다. 전체 요청의 매우 작은 부분이었지만, 평균 Get Latency가 1~2ms 내외이기 때문에 99%, 99.9% tail이 평균 Latency에 큰 영향을 미쳤습니다.이 설정을 전부 true로 바꾼 후에 평균 Latency가 절반으로 하락했습니다.Heap memory / GC 설정저희는 m2.4xlarge가 제공하는 메모리 (68.4GB)의 상당 부분을 HBase의 Read/Write cache에 할당하였습니다. 이는 보통 사용하는 Java Heap 공간보다 훨씬 큰 크기이며 심각한 Stop-the-world GC 문제를 일으킬 수 있기 때문에, 저희는 이 문제를 피하고자 여러 가지 설정을 실험하였습니다.STW GC time을 줄이기 위해서 Concurrent-Mark-and-sweep GC를 사용했습니다.HBase 0.92에서부터 기본값으로 설정된 Memstore-Local Allocation Buffer (MSLAB) 을 사용했습니다. hbase.hregion.memstore.mslab.enabled = true #(default)hbase-env.sh 파일을 다음과 같이 설정했습니다. HBASE_HEAPSIZE = 61440 #(60GB) HBASE_OPTS = "-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps"GC log를 Python script로 Parsing해서 STW GC 시간을 관찰하고 있습니다. 지금까지 0.2초 이상의 STW GC는 한 번도 발생하지 않았습니다.그 밖에 도움이 될 만한 설정들hbase.hregion.majorcompactionHBase는 하나의 Region에 대해서 여러 개의 StoreFile을 가질 수 있습니다. 그리고 주기적으로 성능 향상을 위해서 이 파일들을 모아서 하나의 더 큰 파일로 합치는 과정을 진행하게 됩니다. 그리고 이 과정은 많은 CPU usage와 Disk IO를 동반합니다. 그리고 이때 반응 속도가 다소 떨어지게 됩니다. 따라서 반응 속도가 중요한 경우에는, 이 Major compaction을 off-peak 시간대를 정해서 manual 하게 진행하시는 것이 좋습니다.저희는 사용자의 수가 상대적으로 적은 새벽 시간대에 crontab 이 실행시키는 script가 돌면서 전체 Region에 대해서 하나하나 Major Compaction이 진행되도록 하였습니다.기본값은 86,400,000 (ms)로 되어 있는데, 이 값을 0으로 바꾸시면 주기적인 Major Compaction이 돌지 않게 할 수 있습니다.hbase.hregion.max.filesizeHBase는 하나의 Region이 크기가 특정 값 이상이 되면 자동으로 2개의 Region으로 split을 시킵니다. Region의 개수가 많지 않을 때는 큰 문제가 없지만, 계속해서 데이터가 쌓이게 되면 필요 이상으로 Region 수가 많아지는 문제를 나을 수 있습니다. Region 수가 너무 많아지면 지나친 Disk IO가 생기는 문제를 비롯한 여러 가지 안 좋은 점이 있을 수 있기 때문에, split 역시 manual 하게 하는 것이 좋습니다. 그렇다고 Table의 Region 수가 너무 적으면 Write 속도가 떨어지거나 Hot Region 문제가 생길 수 있기 때문에 좋지 않습니다.HBase 0.92.1 에서는 기본값이 1073741824(1GB)로 되어 있는데, 저희는 이 값을 10737418240(10GB)로 늘인 후에 manual 하게 split을 하여 Region의 개수를 조정하고 있습니다.hbase.hregion.memstore.block.multipliermemstore의 전체 크기가 multiplier * flush size보다 크면 추가적인 Write를 막고 flush가 끝날때까지 해당 memstore는 block 됩니다.기본값은 2인데, 저희는 8로 늘려놓고 사용하고 있습니다.dfs.datanode.balance.bandwidthPerSec부수적인 설정이지만, HDFS의 Datanode간의 load balancing이 일어나는 속도를 제한하는 설정입니다. 기본값은 1MB/sec로 되어 있지만, 계속해서 Datanode를 추가하거나 제거하는 경우에는 기본값으로는 너무 느릴 때가 있습니다. 저희는 10MB/sec 정도로 늘려서 사용하고 있습니다.dfs.namenode.heartbeat.recheck-intervalHDFS namenode에만 해당되는 설정입니다.Datanode가 응답이 없는 경우에 얼마 후에 Hadoop cluster로부터 제거할 것인지를 나타내는 값입니다.실제로 응답이 없는 Datanode가 떨어져 나가기까지는 10번의 heartbeat가 연속해서 실패하고 2번의 recheck역시 실패해야 합니다. Heartbeat interval이 기본값인 3초라고 하면, 30초 + 2 * recheck-interval 후에 문제가 있는 Datanode가 제거되는 것입니다.기본값이 5분으로 되어 있는데, fail-over가 늦어지기 때문에 사용하기에는 너무 큰 값입니다. 저희는 문제가 있는 Datanode가 1분 후에 떨어져 나갈 수 있도록 이 값을 15,000 (ms) 으로 잡았습니다.Read short-circuitRegionServer가 로컬 Datanode로부터 block을 읽어올 때 Datanode를 통하지 않고 Disk로부터 바로 읽어올 수 있게 하는 설정입니다.데이터의 양이 많아서 Cache hit이 낮아 데이터 대부분을 디스크에서 읽어와야 할 때 효율적입니다. Cache hit에 실패하는 Read의 Throughput이 대략 2배로 좋아지는 것을 확인할 수 있습니다. OLAP용 HBase에는 매우 중요한 설정이 될 수 있습니다.하지만 HBase 0.92.1-cdh4.0.1까지는 일부 Region이 checksum에 실패하면서 Major compaction이 되지 않는 버그가 있었습니다. 현재 이 문제가 해결되었는지 확실하지 않기 때문에 확인되기 전에는 쓰는 것을 추천하지는 않습니다.설정하는 방법은 다음과 같습니다. dfs.client.read.shortcircuit = true #(hdfs-site.xml) dfs.block.local-path-access.user = hbase #(hdfs-site.xml) dfs.datanode.data.dir.perm = 775 #(hdfs-site.xml) dfs.client.read.shortcircuit = true #(hbase-site.xml)Bloom filterBloom filter의 작동방식에 대해 시각적으로 잘 표현된 데모 페이지HBase는 Log-structured-merge tree를 사용하는데, 하나의 Region에 대해서 여러 개의 파일에 서로 다른 version의 값들이 저장되어 있을 수 있습니다. Bloom filter는 이때 모든 파일을 디스크에서 읽어들이지 않고 원하는 값이 저장된 파일만 읽어들일 수 있게 함으로써 Read 속도를 빠르게 만들 수 있습니다.Table 단위로 Bloom filter를 설정해줄 수 있습니다.ROW와 ROWCOL의 두 가지 옵션이 있는데, 전자는 Row key로만 filter를 만드는 것이고, 후자는 Row+Column key로 filter를 만드는 것입니다. Table Schema에 따라 더 적합한 설정이 다를 수 있습니다.저희는 데이터 대부분이 메모리에 Cache 되고 하나의 Region에 대해서 여러 개의 StoreFile이 생기기 전에 compaction을 통해서 하나의 큰 파일로 합치는 작업을 진행하기 때문에, 해당 설정을 사용하지 않고 있습니다.결론지금까지 저희가 비트윈을 운영하면서 얻은 경험을 토대로 HBase 최적화 설정법을 정리하였습니다. 하지만 위의 구성은 어디까지나 비트윈 서비스에 최적화되어 있는 설정이며, HBase의 사용 목적에 따라서 달라질 수 있음을 말씀드리고 싶습니다. 그래서 단순히 설정값을 나열하기보다는 해당 설정이 어떤 기능을 하는 것인지 저희가 아는 한도 내에서 설명드리려고 하였습니다. 위의 글에서 궁금한 점이나 잘못된 부분이 있으면 언제든지 답글로 달아주시길 바랍니다. 감사합니다.

안녕하세요. 언제 어디서나 함께하는 코딩 교실 엘리스입니다 :)아이디어만 좋다면 뭐든 실현해볼 수 있는 시대! 지금은 '프로그래밍'이라는 강력한 무기를 통해 원하는 세계를 실현할 수 있는 잠재적 가능성이 폭발적인 때입니다. 그리고 그 기회는 비단 '개발자'라는 특정 직업에 국한하지 않더라도 각계 분야에 펼쳐져 있는데요. 이미 마케터, 기획자, 디자이너, 콘텐츠 창작자, 금융업계 종사자, 지리학자, 연구원 등 다양한 분야의 많은 사람들이 프로그래밍을 통해 각자의 영역과 세계 곳곳을 새로운 곳으로 만들고 있습니다.높은 급여와 삶의 질을 보장하고 나의 꿈을 펼칠 수 있는 탁월한 수단인 프로그래밍.프로그래밍을 업으로 삼고 있는 사람들의 시작은 어땠을까요?이 글에서는 소프트웨어 엔지니어가 되고자 이제 막 마음먹은 분들을 위해 프로그래머가 되기 위한 다섯 가지 짚고 넘어가면 좋을 팁들을 알려드릴게요.STEP 1. 개발 친화적인 환경 찾아가기서당개 삼 년이면 풍월을 읊는다컴퓨터 공학 전공자와 비전공자가 가지게 되는 가장 큰 차이는 무엇일까요? 개발에 대한 이론 지식? 개발 능력?물론 모든 게 상대적인 것이겠지만 일반적으로 한 가지 큰 차이가 있다면 바로 '환경'이라고 할 수 있을 듯합니다. 내 주변에 개발과 관련된 자원이 얼마나 풍부한가 하는 점입니다.전공자가 개발을 시작하고자 마음을 먹으면 주위에서 좋은 리소스를 쉽게 찾을 수 있습니다. 한편 비전공자는 개발 공부를 시작하려고 할 때 레퍼런스로 삼을만한 좋은 예가 없으니 망망대해에 홀로 떠있는 기분이 들 수밖에 없겠죠! 그렇다고 해서 반드시 컴퓨터 공학 전공에서부터 다시 시작하거나 고액의 학원에 다닐 필요는 없습니다. 먼저 개발과 관련된 인적, 물적 자원이 풍부한 곳으로 적극적으로 다가가보세요. 작은 환경의 변화가 큰 변화의 시작점이 될 수 있습니다.엘리스가 추천하는 방법!온라인 커뮤니티 활동하기 : 코딩과 관련된 페이스북 그룹에 가입하여 많은 정보를 접하고 질문도 하면서 활동해보세요. 나와 비슷한 상황인 사람을 만나 서로 도움을 주고받을 수도 있고, 내 롤모델이 될만한 훌륭한 개발자를 만나 공부의 동력이 될지도요!개발 동아리, 스터디 등에 참여하기★ 엘리스 코딩 클래스 활용하기 : PC로도, 모바일 앱으로도 언제 어디서든 프로그래밍을 위한 환경에 접속하세요! 엘리스에 로그인하는 것만으로 공부하기 위한 모든 리소스를 얻을 수 있을 뿐만 아니라 과목별 채팅방을 통해서 함께 공부하고 있는 수강생들, 과목 튜터와의 활발한 대화에 참여할 수 있습니다. STEP 2. 강력한 동기와 조력자 만들기하늘은 스스로 돕는 자를 돕는다컴퓨터 공학 전공자라고 하면 모두 다 개발을 잘할까요? 적어도 아주 조금은 더 잘할까요? 대답은 NO!아무리 많은 이론을 배웠다고 해도 직접 개발을 하지 않는다면 아무런 소용이 없겠지요. 이해도가 다르기 때문에 배움의 속도는 조금 다를 수도 있겠지만 이런 차이보다는 개인의 학습 의지와 동기가 얼마나 분명하냐가 더 중요합니다.막연하게 '개발자'라는 너무 먼 목표만 보고 달리는 것보다는 보다 가까이에 있고 달성하기 쉬운 분명한 목표를 단계별로 설정해보세요. 그리고 '즐거움'을 느낄 수 있는 수단을 찾아 목표 달성을 위한 집중력을 높이세요. 동시에 내가 어려움에 처하거나 헤매고 있을 때 도와줄 조력자가 있다면 금상첨화!Photo by Mimi Thian on Unsplash엘리스가 추천하는 방법!동기 부여를 위한 작은 목표 설정 : 지식 습득 및 학습과 관련된 목표로 그룹 스터디 참여, 부족한 부분의 프로그래밍 강의 완강, 책 한 권 떼기 등이 있을 수 있고, 더 적극적인 형태의 개발 경험을 위해 공모전, 경진 대회 등 기간과 보상이 정해져 있는 대외 활동 참가 및 수상도 좋은 목표가 될 수 있을 거예요.★ 엘리스 코딩 튜터 활용하기 : 엘리스에는 학습을 도와주는 튜터가 있습니다. 엘리스 튜터는 답을 알려주는 사람이 아니라 답을 찾는 법을 알려주는 길잡이입니다. 공부하다가 막힐 때, 길을 잃은 것 같을 때 엘리스 튜터를 멘토로 삼아 보세요! 구독 및 트랙 이용 시 담당 튜터가 배정되어 개인 채팅방을 통해 1:1 튜터링을 받을 수 있고, 클래스 수강 시 단체 채팅방을 통해 언제든 질문할 수 있습니다.STEP 3. 원하는 개발 분야 탐색해보기  콩 심은 데 콩 나고 팥 심은 데 팥 난다개발에는 아주 숱~한 다양한 분야가 있습니다. 그리고 그 분야에 따라 특성도, 익혀야 하는 언어와 기술도 천차만별인데요. 아래 몇 개의 개발 분야와 사용 언어 및 기술에 대해서 적었으니 참고해보세요. 그리고 이보다 더 다양한 개발의 세계를 탐색해보면서 흥미가 가는 분야가 있다면 구체적으로 검색하고 공부를 시작할 계획을 세워보세요.Photo by Victoriano Izquierdo on Unsplash잘 모르겠다 or 코알못이다파이썬은 분야를 막론하고 많은 분야에서 사용되며 익히기에 쉬워 처음 코딩을 시작하는 입문자에게 가장 적합한 언어 중 하나입니다. 개발 언어부터 접해보고 싶다면 파이썬 언어 학습에서 시작해보세요!웹 개발 '콩 심은 데 콩 나고~'라는 속담을 인용했지만, 사실 다양한 개발 영역의 많은 지식들이 서로 겹치는 부분도 있고, 어느 한 분야를 잘할 수 있을 때 다른 분야로 전향하거나 옮겨가는 일은 보다 수월할 수 있습니다. 개발의 시작을 보다 쉽게 하고 싶다면 웹 개발부터 접근해보세요. 공부할 수 있는 자원이 풍부하고 추후 다른 개발 분야로의 전향도 가능하기 때문이에요.프론트엔드프론트엔드 개발은 주로 웹 환경에서 사용자와 맞닿는 가시적인 부분을 개발하는 영역입니다. 사용자가 코드를 작성하지 않고도 컴퓨터에게 명령을 내리는 등의 의사소통을 그래픽적으로 쉽게 할 수 있도록 가시적으로 만들어주는 것이 바로 프론트엔드 개발자의 역할이라고 할 수 있는데요. 예를 들어 엘리스에 로그인하고 싶을 때 '로그인 버튼을 클릭'하여 쉽게 로그인할 수 있는 인터페이스도 프론트엔드에 해당합니다. * 익혀야 하는 기본기 : HTML, CSS, JavaScript* 좀 더 나아가서 : JavaScript의 프레임 워크인 React.js 또는 Vue.js 또는 Angular.js 백엔드/서버백엔드 개발은 웹 환경에서 보통 사용자에게는 보이지 않는 서버(컴퓨터) 단의 개발을 의미하며, 사용자가 웹 상에서 활동함으로 인해 쌓이는 데이터가 모이는 DB(Data Base)를 다루는 영역을 개발합니다.* 익혀야 하는 기본기데이터베이스에 대한 지식 : MariaDB, PostgreSQL, MongoDB 등. 서버 쪽의 언어- 금융, 제약 등 전통적인 대기업 : Java의 프레임 워크인 Spring을 많이 사용- 과거 많이 쓰이던 기술 : Php(학습 속도와 개발 속도가 빠르며 무료!)를 많이 사용- 요즘 떠오르는 기술 : Python 기반 프레임 워크인 Django 또는 Flask. JavaScript의 프레임 워크인 Node.js* 좀 더 나아가서 : 클라우드 컴퓨팅 기술 Amazon AWS 또는 Azure에 대한 지식데이터 사이언스 - 데이터 분석가21세기에 가장 각광받는 직업 중 하나로 떠오른 '데이터 사이언티스트'에 대해서 모두 다 한 번쯤은 들어보셨을 거예요. 데이터 사이언스 분야에도 아주 복잡하고 다양한 영역들이 존재하는데요. 통상 데이터 사이언스라고 하면 수학 및 통계에 대한 지식, 컴퓨터 공학에 대한 지식, 인공지능 및 머신러닝과 관련된 기술을 사용하게 됩니다. 너무 많아 보이나요? 아래에는 데이터 사이언스의 많은 영역 중에서도 '데이터 분석가'로서 꼭 알아야 하는 내용을 적었습니다.* 익혀야 하는 기본기수학적 지식 : 통계, 선형대수학분석을 위한 언어 : Python, R* 좀 더 나아가서 : 머신러닝 기술임베디드 개발계산기, 에어컨, 자동차 등의 기계가 일정 기능을 컴퓨터처럼 수행할 수 있도록 기계 내부의 하드웨어 시스템을 구축하는 것이 임베디드 개발입니다. 사물 인터넷(IoT, Internet of Things)이나 하드웨어 부품과 관련된 분야에 관심이 간다면 임베디드 개발에 대해서 좀 더 알아보세요!* 익혀야 하는 기본기임베디드 개발 언어- 가장 많이 사용하는 언어 : C언어 - 국내 전통적인 대기업 : Java- 수요가 많은 언어 : Python (임베디드 분야에서도 빠지지 않고 자주 사용하는 언어! 국내 채용 사이트에서 임베디드 관련 개발 스택으로 많이 요구.)* 좀 더 나아가서 : 무선 통신 기술에 대한 지식*(공통) 개발자라면 익히고 있어야 할 기본기 : Git을 사용한 버전 관리 방법엘리스가 추천하는 실습 기반 과목HTML/CSS | JavaScript | 모바일 웹 코딩Git과 Git 버전 관리 (6월 오픈 예정)Python 기초 I | Python 기초 IIC 언어 | C++Java 기초 및 심화인공지능/머신러닝 기초 | 프로그래밍 수학데이터 분석 | Numpy, Pandas | 크롤링 | Kaggle 문제R 기초 |  R 패키지 | R 데이터 분석STEP 4. 실습, 프로젝트 기반으로 공부하고 개발 경험 쌓기구슬이 서 말이어도 꿰어야 보배다책을 사고 인강을 결제해도 직접 만들어보면서 익히지 않으면 절대 내 것이 될 수 없는 것이 또 개발!처음 언어를 익히는 단계에서부터 실습 기반으로 직접 코딩하고 그 결과를 확인해보면서 학습하는 것이 중요해요! 필요한 공부를 실습 단위로 쪼개어 직접 구현해보면서 익히고, 좀 더 나아가서는 프로젝트 단위로 구현하면서 실전 기술을 습득해보세요. 또한 실무에서는 혼자 개발하는 것이 아니라 뭐든 '협업'해야 하기 때문에 혼자 하는 프로젝트 외에도 여러 사람들과 함께하는 그룹 프로젝트의 경험이 큰 도움이 될 거예요. 자기소개서, 포트폴리오, 면접 시에도 어떤 프로젝트에서 내가 맡은 부분은 어느 부분이었고 어떻게 주도적으로 이끌었는지가 관건이 될 수 있습니다.엘리스가 추천하는 방법!★ 온라인 코딩 실습으로 기본기 다지기 : 엘리스는 별도의 코딩 환경 세팅 없이 온라인에서 바로 코딩 문제를 풀고 내가 짠 코드의 결과를 확인할 수 있어서 실습 기반으로 학습하기에 탁월한 플랫폼입니다. :) KAIST, SKT, 삼성 SDS 등에서도 활용하는 검증된 플랫폼에서 코딩 실습으로 기본기를 다지세요!프로젝트 단위로 혼자서 만들어보기 : 프로그래밍 언어의 기본에 익숙해졌다면, 직접 A to Z를 구현하는 작은 프로젝트를 통해 실제 필요한 기술이 뭔지 파악해가며 실전 기술을 익혀보세요. 그룹 프로젝트에 참여해서 협업 경험을 통해 익히기 : 취업을 위해서 중요한 것 중 하나인 '협업'능력! 그룹 프로젝트에 참여하여 비단 개발 실력뿐만 아니라 실무에 필요한 다양한 역량 또한 길러보세요.STEP 5. 포트폴리오, 시험 준비하고 개발 직군에 지원하기시작이 반, 그 이상이다!아시겠지만 개발자가 되면 끝인 그런 일은 없겠죠. (어떤 직무에서도 마찬가지일 거예요.) 끊임없는 공부, 새로운 기술 연마, 리팩토링, 문서화, 코딩 공부 코딩 공부!그러니 완벽에서 시작해야 한다는 생각은 버리고 지금까지 최선을 다해온 결과물을 가지고서 개발 직군에 지원하세요. 실제 개발자로 일하게 되면 그 속에서 배우고 성장할 수 있는 자원이 훨씬 더 많아집니다!'자리가 사람을 만든다'라는 말이 괜한 말이 아니니, 더 큰 성장과 가능성이 있는 곳으로 가기 위한 준비와 지원을 주저 없이 해보시길 바라요!Photo by Green Chameleon on Unsplash엘리스가 추천하는 방법!나를 잘 보여줄 포트폴리오 만들기 : (사용한 언어 / 프레임 워크 / 앞의 것을 적용하여 프로젝트에서 내가 한 역할) 별로 정리해두고 내가 커밋한 코드와 함께 보여주기.   블로그 쓰기 : 거창한 것이 아니어도 좋으니 공부하면서 느꼈던 것, 새로 알게 된 지식들, 프로젝트하면서 고민했던 것들을 블로그로 정리해보세요. 내가 구현한 것들을 이미지를 통해서 가시적으로 보여줄 수 있다면 금상첨화!★ 엘리스에서 알고리즘 시험 준비하기 : 이미 많은 수강생 분들이 엘리스 알고리즘 과목을 통해서 코드를 발전시키고 알고리즘 시험 및 취업에 성공하고 있습니다. :) 대기업 입사를 준비하시는 분이라면 엘리스 알고리즘 과목들을 꼭 수강해보세요.이다음의 6번째 스텝은 무엇이 될까요? 아마도 1~5 스텝을 계속 반복해나가면서 익숙해지고, 다른 역할로 각각의 스텝에 참여하게 되는 일이 아닐까요.엘리스는 누구나 프로그래밍을 통해 원하는 일을 할 수 있도록 좋은 강의 콘텐츠와 서비스, 플랫폼으로 여러분의 다섯 스텝에 함께하고자 합니다. :) 막막한 초심자 분들에게 앞으로의 방향성을 그려보는 데에 조금이라도 도움이 되길 바라며 글을 발행합니다.그럼 엘리스에서 만나요! >> 엘리스 아카데미 바로가기* 이밖에 조언, 첨언, 질문 등을 댓글로 남겨주시면 이 글의 독자분들에게 큰 도움이 됩니다.