JENNIFER 5의  유용한 기능을 소개해 드리는 시간. 새로운 기능을 검토해 보시고, 지금 바로 사용해 보세요. 제니퍼소프트는 제품을 사용하는 고객이 최적의 환경에서 모니터링 할 수 있도록 하는데 최고의 가치를 두고 모든 제품을 개발합니다.제니퍼(JENNIFER)는 웹 애플리케이션 (Java EE, .NET, PHP) 시스템 모니터링을 위한 APM(Application Performance Monitoring) 솔루션입니다. 제니퍼는 경량화(Light-Weight), 실시간(Real-Time), 그리고 개별 트랜잭션 모니터링(Individual Transaction Monitoring) 등 기술기반의 '직관적인 통합 성능관리 솔루션'으로 이미 국내외 1200여 개 고객사를 통해 검증된 바 있습니다.  또한, 시대의 요구 사항인 모바일, 클라우드, 그리고 빅 데이터 시장의 온전한 모니터링 체계를 위하여, 웹 서비스 사용자 모니터링 (Web Service Real-User Monitoring), 웹 서비스 중심의 토폴로지 뷰(Web Service Topology View), 클라우드(대규모 시스템) 환경을 고려한 아키텍처, HMTL 5기반의 N스크린(N-Screen)까지도  지원하는 APM 제품입니다.웹 서비스 중심 토폴로지 뷰 (Web Service Topology View)제니퍼 토폴로지 뷰(Topology View)는 기업의 웹 서비스를 중심으로 연결된 서비스에 대한 가시성(Visibility)을 확보하는 것이 핵심 기능입니다. WAS를 중심으로 연결된 서비스(DB, 외부 연계 서비스, HTTP 등) 사이에 발생하는 트랜잭션, 즉, 구간에서 처리되는 트랜잭션까지 실시간으로 모니터링 할 수 있습니다.구간 엑티브 서비스 모니터링: 구간에서 처리되고 있는 엑티브 서비스를 실시간 모니터링 하여 병목 지점과 그 원인을 분석할 수 있습니다.X-view 연계 분석: 병목 지점이 되는 구간에서 처리되는 모든 트랜잭션에 대한 분석을 할 수 있습니다.구간 실시간 모니터링: 실시간 차트를 통해 원하는 구간에 대한 모니터링이 가능합니다.웹 서비스 사용자 응답시간 모니터링(RUM)클라이언트 구현 기술의 발전과 모바일 기기의 대중화로 인해 기업의 서비스는 복잡해졌습니다. 사용자는 모바일을 통해 언제, 어디서든 기업의 서비스를 이용할 수 있게 되었고, APM은 이제 서버사이드 영역의 모니터링뿐만 아니라, 실제 사용자의 만족도를 높일 수 있는 사용자 중심의 성능 모니터링 기능을 요구하고 있습니다. 이러한 변화에 따라 제니퍼는 프런트 앤드(Front-End) 영역의 모니터링을 위한 실제 사용자 모니터링, 즉 RUM(Real User Monitoring)을 지원합니다.이 기능은 웹 표준 조직 기구인 W3C의 Timing Navigation API를 사용하여 별도의 모듈 설치 없이 브라우저에서부터 서버사이드까지 전 영역에 대한 응답시간 측정이 가능하며, 서버와 네트워크로 이어지는 애플리케이션 수행 경로를 시각적으로 표시하여 애플리케이션 성능에 대한 깊이 있는 분석이 가능합니다.제니퍼 for CLOUD최근 IT 흐름의 큰 변화 중 하나는 클라우드(대용량 시스템)입니다. 클라우드 환경의 큰 특징은 트랜잭션의 양에 따라 하드웨어의 제약을 받지 않고 필요에 따라 서버 수를 조절하며 운영할 수 있어야 한다는 것입니다. 제니퍼는 자동감지(Agent Auto Detection), 일괄 설정(Central Configuration), 일괄 배포 (Central Deployment) 기능을 통하여 클라우드 환경에서의 애플리케이션 성능 모니터링을 지원합니다.스마트 프로파일링(Smart Profiling)제니퍼의 개별 트랜잭션의 응답시간을 활용한 엑스 뷰 기반의 분석은 이미 수많은 고객사에서 검증된 트랜잭션 모니터링 기법입니다. 하지만, 프로파일링 분석은 개발자 혹은 성능 튜닝의 전문가가 아니면 어려움을 겪는 것이 사실이었습니다. 이에 제니퍼는 누구나 쉽게 프로파일링 데이터를 분석 할 수 있는 스마트 프로파일링(Smart Profiling)을 제공합니다. 이 기능을 통해 사용자는 Method, SQL, 외부 서비스 중 응답시간이 느린 구간을 선택하여 해당 시점의 프로파일을 쉽게 분석할 수 있습니다.실시간 Connection Pool 모니터링실시간 Connection Pool 모니터링은 Instance별 Connection Pool을 실시간으로 모니터링하는 기능입니다. 이 기능은 액티브 서비스 차트와 함께 모니터링하며 액티브 서비스 점유가 주로 DB Connection에 있을 경우 Connection Pool 설정을 조정할 수 있어 서비스 성능을 개선할 수 있다는 것입니다. 다른 측면에서 DB Connection을 특정 애플리케이션에서 많이 사용할 경우 현재 Connection을 사용하고 있는 Active Service를 찾아내어 원인을 분석할 수 있습니다.실시간 애플리케이션 변경 이력 모니터링기업에서 운영하는 서비스는 수많은 고객의 요구사항을 반영하고 서비스 개선을 위해 하루에도 여러 번 애플리케이션을 변경합니다. 모니터링 관점에서 애플리케이션 변경 시점은 곧 서비스 장애가 일어날 가능성이 가장 많은 시점입니다. 그렇기에 모니터링이 가장 필요한 시점이기도 합니다. 애플리케이션 변경 감지 기능은 변경 전후의 성능 변화를 실시간으로 모니터링하고, 변경 시점에 변경된 소스코드를 추적하여 어떤 소스코드가 변경되었는지 추적할 수 있습니다.  이를 통해 개발자와 운영자 모두가 쉽고 빠르게 서비스의 변화를 감지하고 대응할 수 있는 장점이 있습니다. 엑스 뷰(X-View) > 애플리케이션 연계 분석애플리케이션 연계 분석은 검색한 X-View의 개별 트랜잭션을 기반으로 애플리케이션 단위 호출건수, 평균 응답 시간, 최대 응답 시간, 평균 SQL 시간, 평균 CPU 시간을 함께 분석할 수 있는 기능입니다.  또한 이러한 성능 수치들이 높은 애플리케이션의 개별 트랜잭션을 분석하여 성능에 영향을 미치는 애플리케이션을 튜닝 할 수 있습니다.엑스 뷰(X-View) > 연계 트랜잭션 분석제니퍼는 하나의 요청으로부터 시작된 다수의 트랜잭션 간의 상관 관계를 모니터링하거나 분석할 수 있습니다. 하나의 서버에서 처리된 서로 다른 업무 트랜잭션들을 연계할 수 있으며, 다른 서버에서 발생된 트랜잭션을 연계할 수 있습니다. 프로토콜 후킹 방식(HTTP, RMI)과 GUID를 활용한 연계방식을 지원합니다.엑스 뷰(X-View) > 자동 스택트레이스제니퍼를 포함한 대부분의 APM은 트랜잭션이 느린 원인을 분석하기 위해 매서드 프로파일링 기능을 제공합니다. 하지만 매서드 프로파일링 기능은 잘못된 설정으로 성능에 영향을 주거나 실제 느린 매서드를 찾지 못할 경우가 많습니다. 또한, 로직을 잘 알아야 하므로 성능 전문가가 아닌 이상 사용이 매우 어려운 단점이 있습니다.제니퍼는 이런 제약사항을 없애고 좀 더 쉽게 사용하기 위해 자동 스택트레이스 기능을 제공합니다.  이 기능은 성능 전문가가 아니더라도 느린 트랜잭션이 발생했을 때 해당 시점에 자동적으로 스텍트레이스(Stacktrace)를 남겨서 원인을 쉽고 빠르게 분석할 수 있습니다. 제니퍼소프트는 항상 제니퍼 고객의 모니터링 환경을 좀 더 쉽고 유용하게 할 수 있도록 고민하고 있습니다.  더 좋은 기능을 제공할 수 있도록 노력하겠습니다. 

안녕하세요. 스포카 개발팀에서 서버 관련 개발 업무를 담당하고 있는 문성원입니다. 오늘은 스포카 서버의 구조와 사용된 기술들에 대해서 함께 살펴보겠습니다.스택이란?먼저 스택(Stack)이란 용어에 대해서 함께 생각해보죠. 컴퓨터 과학을 공부하신 분들이라면 선입후출(FILO)이나 스택 오버플로우(Stack Overflow)등의 개념으로 익숙하실만한 용어기도 합니다. 그런데 서버 구조를 설명한다면서 왠 스택이냐구요? 다행히(?)도 지금부터 살펴 볼 스택은 솔루션 스택(Solution Stack)입니다. 스포카 서버라는 큰 솔루션이 원활히 동작하기 위해서 쓰이고 있는 각종 서브 시스템과 컴포넌트들의 묶음을 이야기하는 것으로 바꿔말하자면 이 글에서 다룰 기술 이야기는 모두 이 스택에 관한 이야기입니다.2011년 12월 현재 스포카 서버를 구성하고 있는 스택은 다음과 같습니다.DotcloudLinux 2.6.38.2nginx 0.8.53uwsgi 0.9.8.5Python 2.6.5Redis 2.2.2Celery 2.2.7Amazon Relational Database ServiceMySQL 5.5.12Amazon Simple Storage ServiceDotcloudDotcloud는 지금부터 설명드릴 스택을 묶어서 제공해주는 PaaS(Platform as a Service)의 일종입니다. Amazon Elastic Cloud Computing(Amazon EC2) 기반으로 동작하며 거기에 더해 손쉬운 확장과 배포가 장점입니다. 스포카 서버는 데이터베이스(Amazon RDS)와 업로드되는 데이터(Amazon S3) 이외의 모든 서비스를 Dotcloud를 통하여 제공하고 있습니다.nginx, uwsgi. 그리고 WSGI기본적으로 스포카 서버는 HTTP 형식의 요청을 받아 응답을 돌려주는 웹 어플리케이션입니다. 이러한 처리는 1차적으로 nginx를 통해 이뤄지는데, 이 중 서버사이드에서 처리가 필요한 경우에는 uwsgi라는 데몬이 이 처리를 담당합니다. (구버젼의 Apache Tomcat을 사용하시던 Java개발자분들은 Apache Tomcat과 Apache httpd와의 관계를 떠올리시면 편합니다.)이 경우 uwsgi는 일종의 어플리케이션 컨테이너(Application Container)로 동작하게 됩니다. 적재한 어플리케이션을 실행만 시켜주는 역할이죠. 이러한 uwsgi에 적재할 어플리케이션(스포카 서버)에는 일종의 규격이 존재하는데, 이걸 WSGI라고 합니다.(정확히는 WSGI에 의해 정의된 어플리케이션을 돌릴 수 있게 설계된 컨테이너가 uwsgi라고 봐야겠지만요.) WSGI는 Python표준(PEP-033)으로 HTTP를 통해 요청을 받아 응답하는 어플리케이션에 대한 명세로 이러한 명세를 만족시키는 클래스나 함수, (__call__을 통해 부를 수 있는)객체를 WSGI 어플리케이션이라고 합니다.정리하자면 스포카 서버는 WSGI에 맞게 작성된 프로그램을 nginx와 uwsgi를 통해 운용하여 요청을 처리하는 웹 어플리케이션이라고 할 수 있습니다.RedisRedis란 키-값(Key-Value) 저장 서버로 확장이 용이하며 속도가 우수합니다. 스포카 서버에선 이를 내부적인 임시 데이터 관리와 Celery의 작업(Task) 분배에 사용하고 있습니다.CeleryCelery는 Python으로 작성된 비동기 작업 큐(Asynchronous task queue/job queue)입니다. 앞서 소개한 작업(Task)를 브로커(Broker, 스포카 서버는 Redis를 사용)를 통해 전달하면 하나 이상의 워커(Worker)가 이를 처리하는 구조입니다. 포인트 적립-공유에 따른 분배처리, 포스팅 기능, 페이스북/트위터 공유등의 비동기 처리가 필요한 작업을 Celery에 위임하여 처리하고 있습니다.Amazon Relational Database Service대부분의 웹 어플리케이션과 마찬가지로 스포카 서버는 영속적으로 저장되어야하는 정보(회원 목록, 구매 내역)들을 디스크 기반의 데이터베이스(Database)에 저장합니다. Amazon Relational Database Service(Amazon RDS)는 Amazon EC2를 기반으로 그러한 데이터베이스를 간편하게 관리(모니터링, 백업, 접근제어)할 수 있게 도와주는 웹서비스입니다. Oracle과 MySQL을 지원하는데 스포카 서버는 그 중 MySQL을 사용하고 있습니다.Amazon Simple Storage ServiceAmazon Simple Storage Service(Amazon S3)는 Amazon RDS와 마찬가지로 Amazon EC2를 기반으로 한 데이터 저장 관리 서비스입니다. 스포카 서버에 업로드 되는 사진이나 문서등의 파일들을 통합하여 관리하여 서버의 인스턴스를 늘려 확장하는 경우에도 문제없이 대처할 수 있도록 하는 것이 주 목적입니다.#스포카 #스택 #개발 #개발자 #개발팀 #인사이트 #조언 #스킬스택 #스택설명

 Buzzvil People에서는 다양한 배경과 성격 그리고 생각을 지닌 버즈빌리언들을 한 분 한 분 소개하는 시간을 갖습니다. 어떻게 버즈빌에 최고의 동료들이 모여 최고의 팀을 만들어가고 있는 지 궁금하시다면, 색색깔 다양한 버즈빌리언들 한분 한분의 이야기가 궁금하시다면, Buzzvil People을 주목해주세요.1. 간단한 자기 소개 부탁드립니다. 안녕하세요, 버즈빌에서 기술지원 업무를 담당하고 있는 Jen입니다. 본명은 윤진 (Yoon Jeen) 인데요, 입사 당시 ‘본명이 매일 불리면 일상과 회사가 구분되지 않지 않을까’라는 생각에 이름에서 한 자를 줄여 Jen으로 결정했습니다. 그런데 얼마 지나지 않아 프로덕트 팀의 윤진한 매니저가 Jin 이라는 이름으로 입사했지요. 덕분에 매일 제 이름을 제 입으로 부르고 있습니다. 버즈빌에 입사하기 전에 소셜 스타트업, 푸드 스타트업, 인테리어 O2O 스타트업 총 세 곳에서 인턴으로 근무한 경험이 있습니다. 그리고 2017년 중순 버즈빌에 입사하여만 1년 3개월 동안 BD(Business Development)팀의 전략 매니저로 일했으며, 올해 초부터 BD팀 업무와 TAM(Technical Account Manager) 업무를 겸하다가 올 10월에 정식으로 TAM 업무를 전담하게 됐습니다. 2. 어떻게 버즈빌에 오시게 되셨나요? 지인의 추천으로 버즈빌에 대해 알게 됐고, 미래에 제가 사업을 할 때 도움이 될 좋은 회사라고 판단해 입사하고자 마음먹게 됐습니다. 몇 번의 인턴 경험을 통해 세운 ‘회사를 고르는 기준’ 중 1순위는 나중에 사업을 할 때 도움이 될 만한 곳에 가자는 것이었습니다. 세부적으로는 1) 리더가 능력 있고 2) 사람들에게서 많은 것을 배울 수 있고 3) 서로의 의견을 경청하는 곳이어야 한다는 것이었어요. 지인이 버즈빌을 추천하면서 해준 말들이 이 모든 것에 너무나 아름답게 부합했답니다. 더해서 CEO인 John이 대학교 특강에 연사로 와서 해준 설명을 듣고 입사에 대한 더욱 강한 열망을 품게 됐습니다. 그래서 학기 중에 면접을 보고, 여러 우여곡절 끝에 감사하게도 합격하게 됐어요. 면접을 보는 기간 과제 때문에 엄청나게 힘들어하기도 했고, 합격하지 못할까 봐 얼마나 노심초사했는지 모르겠습니다. 뽑아주신 덕에 8학기에 교환학생을 가려 했던 계획을 내던지고 지난 8월에 졸업해 완전한 직장인이 됐답니다. 3. 버즈빌에서 어떤 업무를 담당하고 계신가요? Technical Account Manager 의 업무는 크게 3가지입니다.  연동문서 관리 – 버즈빌에서 보유하고 있는 모든 프로덕트 및 기능에 대한 문서를 관리하고 있습니다. 문서를 작성하고 적절히 연결 짓고 업데이트하고 이에 대해 내외부에 설명하는 부분까지 포함됩니다. 파트너사와 개발 미팅이 있으면 문서를 설명하기 위해 참석하기도 하고요. 내외부 이슈 해결 – 업무시간의 가장 큰 비중을 차지하는 부분은 외부 파트너의 기술 관련 이슈 해결입니다. 버즈스크린 등의 SDK를 연동한 퍼블리셔(Supply 단) 및 버즈빌이 제공하는 광고 트래킹 기능을 연동한 광고주(Demand 단)까지가 모두 파트너에 포함됩니다. 우선 연동하면서 이상이 없도록 잘 안내하고, 이후 연동이 마무리되어 출시된 이후의 이슈를 처리하며, 추가 작업이 필요할 경우 개발팀에 전달하는 것까지 모두 이에 해당합니다. 내부 프로세스 개선을 위한 요청을 관리하는 것 또한 이 업무에 포함됩니다. 프로세스 세팅 및 개선 – 위 모든 것이 수많은 커뮤니케이션을 통해 이루어지기 때문에, 효율적으로 진행될 수 있도록 유관 팀과 협력하여 프로세스를 세팅하고, 현재 비효율적인 부분을 개선해나갑니다. 그리고 세팅하는 것보다 더 중요하게 이러한 프로세스가 잘 지켜지도록 안내하는 것도 업무의 일부입니다.  얼마 전까지는 하루 대부분을 문의와 이슈를 받아 이를 해결 or 전달하고, 있었던 커뮤니케이션에 대해 기록을 남기고 유관 팀에 공유하는 것에 할애해왔어요. 버즈빌의 사업 규모가 상당해서 모든 이슈를 관리하고 프로세스를 만들고 기록까지 하다 보면 하루가 늘 빠듯하더라고요. 감사하게도 최근에 좋은 분들이 팀에 참여해주셔서, 연동문서 체계화 및 문서화 쪽에 보다 집중할 수 있는 시간이 생기고 있습니다. 업무를 하면서 가장 곤란한 순간은 ‘이게 왜 이렇게 되어있지?’ 하게 되는 때입니다. 주로 개별 적용 되어있는 부분에 대해 히스토리가 남아있지 있거나, 기능 등이 실제로 어떻게 작동하는지 또는 사용되는지 몰라서 나오는 의문들입니다. 다행히 BD팀에서 파트너사를 운영하면서 알고 있었던 히스토리와 경험이 있어서 많은 도움이 되는 것 같아요. 이를 저뿐 아니라 다른 분들이 궁금하면 언제든지 아실 수 있도록 기록을 남기는 일에 힘쓰고 있습니다. 4. 스타트업에서 혹은 광고업계에서 일하는 느낌이 어떠세요? 스타트업으로서는 모든 것을 내 손으로 빚어나가는 느낌이에요. 이건 이전 회사들에서도 많이 느꼈던 부분이네요. 물론 버즈빌은 제가 입사할 당시부터 규모가 꽤 큰 상태였고 갖춰져 있는 시스템이 많아 매우 놀랐지만, 그런데도 많은 것들을 직접 만들어나가야 하는 ‘스타트업’이에요. 그래서 할 것이 너무 많아 버겁고 힘들 때도 있지만, 결국 제가 원하는 그림을 그려나가며 최대한 완벽하게 만들어나갈 수 있어서 매일 도전적이고 스릴 넘치는 하루를 보냅니다. 저뿐 아니라 버즈빌리언 모두 각자의 자리에서 본인에게 주어진 도전들을 클리어해나가는 것 같아요. 광고업계의 스타트업으로서는 변화와 적응의 결정체랄까요. 제가 모든 업계에 종사해본 것은 아니지만, 광고업계 특성 상 변화의 속도가 더 빠른 것 같아요. 수요와 공급 쪽의 요구가 계속해서 넘쳐나고, 그 안의 플레이어들도 계속해서 나타나서 변화와 혁신이 끊이지 않는 것 같습니다. 그 와중에 플랫폼 별 정책도 변화하게 되니 그야말로 내일을 점칠 수 없는 업계인 것 같아요. 그래서 저의 업무도 매일 변화하고 새로운 상품이나 퍼블리셔에 적응하는 과정의 일부입니다. 저는 이런 역동성이 좋아서 버즈빌에서 만족하며 일하고 있어요. 버즈빌에서 일하면서 받는 느낌은, 일이 제 삶 대부분을 차지해버렸다는 점이겠네요. 하루 대부분을 회사에서 보내고 그 외의 시간에도 회사나 일 생각을 하는 것 같아요. 이것의 장단점이 있다보니 이제 워라밸도 생각하려 하고는 있지만, 여전히 제 생각의 대부분을 차지하고 있는 것이 바로 버즈빌이랍니다. 5. 이것만큼은 버즈빌이 참 좋다! 어떤 게 있으실까요? 일단 사람들이 본인 일과 다른 사람에 대한 애정을 품고 있어요. 그 덕에 무엇 하나 대충 넘기는 일 없이 다 같이 힘을 모아 일을 해낼 수 있습니다. 다들 사소한 질문에도 답을 찾기 위해 적극적으로 도와주시고, 짜증 내지 않고 웃으며 대해주세요. 그래서 크고 작은 문제를 맞닥뜨렸을 때 혼자 끙끙대는 일 없이 헤쳐나갈 수 있고, 저도 질문을 받았을 때 더 신나게 도와드릴 수 있는 것 같습니다. 두 번째로는 회사가 커뮤니케이션을 굉장히 중시한다는 점이에요. 솔직히 저는 우리나라에서 나이에 따른 꼰대질이 없는 회사는 정말 희귀할 거로 생각하는데요, 버즈빌은 그 희귀한 곳 중 하나입니다. 제가 언제 어디서든 적극적으로 의견을 낼 수 있고, 아닌 것에 대해 아니라고 말할 수 있는 회사가 얼마나 있을까요. 말만 번지르르하게 하는 것이 아니라 실제로 모두의 의견을 존중하려는 버즈빌의 문화는 버즈빌의 큰 동력 중 하나라고 생각해요. 마지막으로 사람들이 끊임없이 자기발전을 위해 노력합니다. 기본적으로 사람들의 성향이 그런 것도 있고 회사도 적극적으로 지원해줘서 더 시너지가 나는 것 같아요. 그 덕에 저도 많은 자극을 받고 더 실력 있는 사람이 될 방법은 무엇일까 고민하게 돼요. 매일매일 기분 좋은 압박감 같은 것을 느끼고 있답니다. 6. 개인적인 목표나 꿈이 있으신가요? 있다면, 버즈빌에서의 경험이 어떻게 도움이 된다고 생각하시나요? 저는 ‘기댈 수 있는 존재’가 되고 싶습니다. 누군가 힘들 때 제게 말하거나 의지해줄 때 제 존재의 의미를 느끼거든요. 개인적으로는 누군가 힘들 때 찾아올 수 있는 사람이 되고 싶어요. 한때 ‘따뜻한 사람이 되고 싶다’ 정도로 마음에 품고 살았는데, 최근에 마냥 따뜻한 것을 넘어서 누군가 찾아올 수 있는 사람이 되고 싶다고 생각이 바뀌었어요. 그리고 삶의 큰 목표로서도 마찬가지로 즐거울 때든 힘들 때든 기댈 수 있는 상품이나 서비스로 사업을 하고 싶습니다. 사실 삶에서 힘이 되는 것들이 엄청 대단한 건 아닌 것 같아요. 아침에 눈을 떠서 오늘 좋아하는 사람들과 점심 약속이 있다는 사실에 벌떡 일어나기도 하고, 아무리 새벽까지 힘들게 일하고 집에 가도 고양이가 품에 안겨있으면 피로가 사르르 녹는 것처럼요. 그래서 일확천금의 기회를 준다거나 인생을 반전시킬 만큼의 서비스는 아니라도, 잔잔한 일상 속에서나 마음이 벼랑 끝에 몰리고 지친 순간이나 머릿속에 떠오를 만한 그런 사업을 하고 싶습니다. 아무래도 관심사가 음식, 동물, 심리 이런 분야이다 보니 그 교차점에 있는 무언가를 꼭 하고 싶어요. 아침마다 고양이들에게 둘러싸여 오늘의 요리를 준비한다면 더할 나위 없이 행복할 것 같네요. 일단 버즈빌에서의 직무가 저의 이런 꿈과 관련하여 참 잘 맞는 것 같아요. 누군가가 저를 필요로 하고 불러주는 게 정말 진심으로 너무 좋답니다. 그걸 잘 처리해드리지 못할 때는 매우 힘들지만, 제 이름을 불러주실 때마다 “넵!!” 하고 대답하는 게 항상 행복하고 감사해요. 그런 점에서 현 상태만으로도 제가 되고 싶은 제 모습을 만들어나가는 데에 도움이 많이 됩니다. 두 번째로는 나중에 사업을 할 때 도움이 될 인사이트를 많이 얻어가고 있어요. 특히 사업의 확장성에 대한 것인데요, 어릴 때 단순 자영업을 꿈꾸다가 더 많은 사람에게 도움이 되면 좋지 않을까 생각해서 기업가로 꿈을 바꾸었어요. 그와 유사하게, 버즈빌에 들어와 B2B 사업을 경험하면서 파트너사가 지닌 경험과 사용자를 leveraging하여 투자하여 더 큰 확장성을 가질 수 있다는 것을 절절히 느꼈습니다. 해서 나중에 사업을 하면서 다른 주체와 협업하고 소통하는 과정에서 지금 버즈빌에서 BD매니저, 그리고 현재 TAM으로서의 경험이 아주 큰 도움이 될 거라고 확신합니다. 이에 더해서 좋은 회사란 무엇인가 고민하고, 그 고민을 통한 액션 아이템이 도출되고 실행되는 과정에 함께하는 것 또한 나중에 제 일을 할 때 큰 도움이 될 것 같습니다. 마지막으로 모든 것을 다 떠나서 너무나 좋은 사람들과 함께 웃고 이야기하고 일할 수 있다는 것 자체가 제 인생을 풍요롭게 해줍니다. 단 하루도 쉬이 넘어간 적이 없지만, 동시에 즐겁게 웃지 않았던 날도 없어요. 앞으로 버즈빌에서 제 삶이 어떻게 될지 모르지만, 여기에서 시간과 경험과 인연은 제 삶에 보석 같은 존재로 남을 것 같습니다. 

안녕하세요. 크몽 개발팀 입니다!   지난주에는 개발하기 전 개발환경 셋팅에 필요한 개발도구들을 소개해 드렸습니다.그러나 개발환경을 셋팅하기 전에 먼저 결정해야 할 것이 있습니다.바로 어떤 프로그래밍 언어로 개발을 할것인가 하는 문제 인데요~언어의 종류가 많고 사용하는 언어마다 특성이조금씩 다르기 때문에 결정하는 것이 어려울 때가 많습니다. 오늘은 다양한 종류의 언어 중에서 요즘 개발자 분들사이에서 화제가 되고 있는 'Swift(스위프트)'라는 언어를 소개해보려고 합니다.    2014년 6월 2일 미국 샌프란시스코 모스콘웨스트컨벤션센터에서 열린애플 WWDC(WorldWide Developers Conference)에서발표 마지막에 새로운 프로그래밍 언어 'Swift(스위프트)'를 공개했습니다.Swift는 C와 Objective-C의 중간에 있는 언어로서iOS와 OS X 기반의 애플리케이션 개발을 위한 언어입니다. 간단하게 장점들을 말씀드리면 고성능 앱을 개발 하기 위하여LLVM의 발전된 코드 분석기를 이용해 컴파일과 최적화를 수행합니다. 이 결과 Python 기준으로 오브젝트 정렬 속도는 3.9배,RC4 인크립션 처리속도는 220배나 빠른 처리속도를 가지고 있습니다. 그리고 현대적인 언어에서 지원하는 주요 기능들을 대거 흡수하고,Cocoa 및 Cocoa Touch frameworks의 모든 부분에서 접근이 가능합니다.또한 C와 Objective-C에서 써오던 기존 방식 또한 그대로 도입할 수있기 때문에 기존에 개발하던 업무에 지장을 주지 않습니다.   마지막으로  읽고 쓰기 쉬운 문법으로 코드를 작성하기 때문에유시보수 시 적은 양의 코드가 사용됩니다.그리고 소스를 코딩한 후 그 결과를 실시간으로 볼 수 있습니다. [출처] 애플 스위프트 언어 (Swift) - 앱 개발을 위한 애플의 새로운 언어|작성자 마스터 현재 9월에 애플에서 Swift 정식버전이 출시 되었고Swift로 작성된 애플리케이션의 iOS 앱스토어 승인도 시작되었습니다.또한 Xcode 6 시험판을 내려받아서 사용할수 있고,iTunes Store와 App Store를 통해 Swift 프로그래밍 언어 전자책을 다운받을 수 있다고 합니다.  개발된지 오래 되지 않아서 아직 Objective-C를 함께 사용하고있지만 쉽게 접근할 수 있는 언어이기 때문에점점 Swift를 사용하는 개발자 분들이 많아질 것으로 보입니다 ^^ 이상 포스트를 마치겠습니다. #크몽 #개발팀 #신입개발자 #신입사원 #경험공유

유저 반응을 볼 때가 즐겁다는 프론트엔드 엔지니어 인턴 Mino조이에서 소프트웨어 엔지니어 인턴으로 살아간다는 것이 어떤지 궁금해 하시는 분들이 많아 4개월차 소프트웨어 엔지니어 인턴 미노(본명 천민호)를 Zoyiful Talk 첫 번째 주자로 모셨습니다.ZOYI: 미노 안녕하세요! 인턴으로 조인하신지 벌써 4개월이 지나셨다면서요. 우선 간단한 소개부터 해주세요. 회사에서 무슨 일을 하고 있나요?MINO: 안녕하세요, 채널(Channel)이라는 조이 신규 서비스를 개발하고 있는 엔지니어 미노입니다. 채널은 소비자와 커머스 기업을 연결해주는 소통 창구 같은 서비스인데요, 저는 그 중에 웹 프론트엔드를 개발하고 있습니다.ZOYI: 프론트엔드가 뭔가요? 좀 더 설명해 주세요.MINO: 프론트엔드는 흔히 ‘웹 개발자’라 하는데요, 웹이나 앱에서 서비스 이용자가 경험하는 부분을 개발합니다. 이용자에게 더 좋은 시각적 효과를 주고, 더 편리한 경험을 제공하기 위해 기술을 이용하죠. 이를 구현하기 위해 자바스크립트라는 언어를 사용하고, react.js를 프레임워크로 사용하고 있습니다.ZOYI: 원래부터 프론트 개발을 많이 하셨었나요?MINO: 프론트엔드는 HTML 작성할 수 있는 정도? 아니면 레일즈로 간단한 홈페이지 게시판 만드는 정도였어요. 자바스크립트는 조이에서 처음 배워봤고요.사실 개발 시작한 것 자체가 작년 9–10월이니 이제 반 년 좀 넘었네요. 코딩은 2년 전부터 시작했었는데 거의 알고리즘 공부가 위주였고 최근에야 제대로 개발을 한 것 같아요ZOYI: 조이에는 어떻게 조인하게 되신 거예요?MINO: 대학 개발 동아리 회장을 할 당시 대회 후원사가 필요해서 레드(CEO)한테 컨택한 적이 있거든요. 후원을 받고 나서 레드의 권유로 회사에 한 번 놀러왔는데, 사무실이 생각보다 좋더라고요. (웃음)스타트업 하면 좁은 공간에 다닥다닥 붙어있는 모습을 생각했었는데… 깔끔한 공간이 인상깊었어요.높은 천장과 통유리 채광을 자랑하는 조이 사무실에 반했다고 합니다.ZOYI: ㅎㅎㅎ 직접 일해보니 어때요? 실제로도 깨끗하던가요?MINO: 레드의 책상이 좀 더럽긴 하지만…은 농담이고요, 실제로 일해보니 더 좋은 것 같아요. 책상도 넓고… 제가 이렇게 하얀 느낌을 좋아하거든요.ZOYI: 조이에서의 4개월을 지내보니 어때요?MINO: 음… 4개월 지나고 나니, 이제야 내가 뭘 모르고 뭐가 부족한지를 알 수 있게 된 것 같아요. 잘한다고 말하긴 아직 부끄럽지만, 적어도 구글링으로 뭘 찾아야 할지는 알 수 있게 됐어요.ZOYI: 안해본 것들을 했잖아요, 주로 어떻게 습득을 했어요?MINO: 사람마다 좀 다를 수 있는데 저는 그냥 시간 날때마다 조이 오픈소스 프로젝트들을 하나하나 열어보면서 이게 어떻게 동작하나를 봤어요. 그래도 모르면 물어보면서 Follow up 받고… 동료들한테 부담없이 물어볼 수 있어서 좋았어요. 촉진제같은 역할을 해 준 것 같아요.한 번은, 전혀 새로운 분야이고 처음 접해보는 언어를 다루는 거라 익숙치 못해 하루종일 구글링을 한 적이 있어요. 그런데도 오늘 커밋 했냐, 뭐했냐 이런 얘기가 없고… 당신의 성장을 그냥 지켜보겠다는 태도인 거예요. 처음엔 익숙하지가 않았는데, 그런 분위기 덕분에 결과적으로 리서치를 잘 하고 일을 성공적으로 마무리 할 수 있었어요.ZOYI: 동료들과 교류가 많은 편인가요?저는 프론트엔드를 하다보니 주로 개발팀 멤버들과 많은 시간을 보내는데요, 업무 외적으로도 되게 재미있어서 친하게 지낼 수 도 있고 그래요. 꾸준히 소통하려 하는 게 느껴져요. 나를 막연히 6개월 후 나가는 인턴이 아니라, 함께 성장해 가는 동료로 생각하고 있구나. 하는 기분이 들죠.ZOYI: 푸스볼 중독이라는데?MINO: 푸스볼도 ZOYI에서 처음 배웠는데, 이건 정말, 최고의 레져인 것 같습니다 (목소리 톤 올라감). 가격 대비 효율이 최고예요. 하루 한 번 이상 꼭 하고 있습니다.10분만 해도 맥박이 빨라진다는 엄연한 스포츠, 푸스볼ZOYI: 본인의 푸스볼 랭킹은?MINO: 글쎄요, 디케이(하드웨어 디자이너)보단 잘하지 않을까요? ㅎㅎZOYI: 인턴 끝나면 생각나겠어요, 그러고 보니 인턴도 이제 두 달 남았네요. 돌아가면 하고싶은 일이 있나요?MINO: 아직 고민중이예요. 사실 조이 들어오기 전에는 프론트, 웹 개발자는 정말 안하겠다고 생각했었는데 지금은 이게 재미있다는 생각이 들어요.초반에 누가 “잘 하게 되면 점점 재미있어 질거다”라고 말해준 적이 있는데, 그 말이 공감이 돼요. 점점 배워가면서 지금은 어느정도 의도한 대로 구현이 되니까…이젠 재미있는 거예요. 새로운 분야를 알게 된 느낌? 그래서 앞으로 프론트엔드 개발자로 일해도 좋고, 뭐든 최대한 많은 경험을 하고 많은 지식을 습득해 보고 싶어요.ZOYI: 좋은 계기가 되었네요, 인턴 생활은 만족스러워요?MINO: 네, 생각하던 것 이상으로 좋았어요. 주도적으로 일을 해 나갈 수 있다는 점과, 하나하나 해 나갈 때마다 내가 성장하고 있는 느낌이 좋아요. 사실 처음 입사할 땐 단순히 반복작업만 할 줄 알았거든요. ZOYI엔 뭔가 ‘네 꿈을 펼쳐봐라~’하는 태도가 있는데, 저는 거기에 잘 맞았던 것 같아요.ZOYI: 그렇다면 향후 ZOYI 지원을 고민하시는 분께 어떤 조언 한마디 해주시겠어요?MINO: 주변에 많은 친구들이 ‘난 안될거야’라고 생각하고 지원조차 안하는 경우가 많은데, 저는 일단 지원해 보라고 말해주고 싶어요. 저도 지원할 당시 굉장히 걱정을 했었거든요. 나는 알고리즘 공부밖에 못해봤고, 서버도 용어 하나도 모르는데 내가 잘 할 수 있을까?하는 생각.막상 회사에 들어오고 난 지금은 생각이 많이 달라졌어요. 인턴에게 중요한 자질은 완벽함보다 가능성인 것 같아요. 그 가능성이란 게 대단한 스펙이 아니라, 기초를 탄탄히 가지고 있는 거예요. 그리고 나면 회사에 와서 충분히 성장할 수 있어요.그 좋은 사례가 션(CTO)인 것 같아요. 함께 일하면서 CTO가 되어가는 모습을 곁에서 보는 게 참 좋았어요. 내부에서 우리가 성장해 더 큰 역할을 맡을 수 있는 조직이란 게 참 좋아요.ZOYI: 조언 감사합니다. 남은 기간 ZOYI에서 기대하는 점이 있다면?MINO: 이번 주부터 시작될 개발팀 위클리 세션이 기대돼요. 각자가 알고 있는 기술을 다른 멤버들과 공유하는 시간인데요, 조이가 워낙 다양한 기술을 다루다 보니 제가 담당하지 않는 분야에 대해서는 잘 모르는 게 많거든요. 같이 일하는 사람들은 어떤 분야에 대해 일하고 있는지 기술적으로 알아보고 싶어요.ZOYI: 좋은 시도네요. 마지막으로 글 읽으시는 분들께 한마디 하시겠어요?MINO: ZOYI는 잘하는 사람들이 와서 더 잘하게 되는 곳이 아니라 가능성 있는 사람들이 와서 잘하게 되는 곳이라고 생각해요. 누구에게나 열려 있으니 편히 찾아와 주셨으면 좋겠어요 ^^#조이코퍼레이션 #개발팀 #개발자 #개발환경 #업무환경 #팀원인터뷰 #팀원소개 #팀원자랑

요즘은 데이터 분석이 스타트업, 대기업 가릴 것 없이 유행입니다. VCNC도 비트윈 출시 때부터 지금까지 데이터 분석을 해오고 있고, 데이터 기반의 의사결정을 내리고 있습니다.데이터 분석을 하는데 처음부터 복잡한 기술이 필요한 것은 아닙니다. Flurry, Google Analytics 등의 훌륭한 무료 툴들이 있습니다. 하지만 이러한 범용 툴에서 제공하는 것 이상의 특수하고 자세한 분석을 하고 싶을 때 직접 많은 데이터를 다루는 빅데이터 분석을 하게 됩니다. VCNC에서도 비트윈의 복잡한 회원 가입 프로세스나, 채팅, 모멘츠 등 다양한 기능에 대해 심층적인 분석을 위해 직접 데이터를 분석하고 있습니다.빅데이터 분석 기술큰 데이터를 다룰 때 가장 많이 쓰는 기술은 Hadoop MapReduce와 연관 기술인 Hive입니다. 구글의 논문으로부터 영감을 받아 이를 구현한 오픈소스 프로젝트인 Hadoop은 클러스터 컴퓨팅 프레임웍으로 비싼 슈퍼컴퓨터를 사지 않아도, 컴퓨터를 여러 대 연결하면 대수에 따라서 데이터 처리 성능이 스케일되는 기술입니다. 세상에 나온지 10년이 넘었지만 아직도 잘 쓰이고 있으며 데이터가 많아지고 컴퓨터가 저렴해지면서 점점 더 많이 쓰이고 있습니다. VCNC도 작년까지는 데이터 분석을 하는데 MapReduce를 많이 사용했습니다.주스를 만드는 과정에 빗대어 MapReduce를 설명한 그림. 함수형 프로그래밍의 기본 개념인 Map, Reduce라는 프레임을 활용하여 여러 가지 문제를 병렬적으로 처리할 수 있다. MapReduce slideshare 참조MapReduce는 슈퍼컴퓨터 없이도 저렴한 서버를 여러 대 연결하여 빅데이터 분석을 가능하게 해 준 혁신적인 기술이지만 10년이 지나니 여러 가지 단점들이 보이게 되었습니다. 우선 과도하게 복잡한 코드를 짜야합니다. 아래는 간단한 Word Count 예제를 MapReduce로 구현한 것인데 매우 어렵고 복잡합니다.MapReduce로 단어 갯수를 카운트하는 간단한 예제 (Java). 많은 코드를 작성해야 한다.이의 대안으로 SQL을 MapReduce로 변환해주는 Hive 프로젝트가 있어 많은 사람이 잘 사용하고 있지만, 쿼리를 최적화하기가 어렵고 속도가 더 느려지는 경우가 많다는 어려움이 있습니다.MapReduce의 대안으로 최근 아주 뜨거운 기술이 있는데 바로 Apache Spark입니다. Spark는 Hadoop MapReduce와 비슷한 목적을 해결하기 위한 클러스터 컴퓨팅 프레임웍으로, 메모리를 활용한 아주 빠른 데이터 처리가 특징입니다. 또한, 함수형 프로그래밍이 가능한 언어인 Scala를 사용하여 코드가 매우 간단하며, interactive shell을 사용할 수 있습니다.Spark으로 단어 개수를 카운트하는 간단한 예제 (Scala). MapReduce에 비해 훨씬 간단하다.Spark과 MapReduce의 성능 비교. I/O intensive 한 작업은 성능이 극적으로 향상되며, CPU intensive 한 작업의 경우에도 효율이 더 높다. (자료: RDD 논문)Apache Spark는 미국이나 중국에서는 현재 Hadoop을 대체할만한 기술로 급부상하고 있으며, 국내에도 최신 기술에 발 빠른 사람들은 이미 사용하고 있거나, 관심을 갖고 있습니다. 성능이 좋고 사용하기 쉬울 뿐 아니라, 범용으로 사용할 수 있는 프레임웍이기에 앞으로 더 여러 분야에서 많이 사용하게 될 것입니다. 아직 Spark를 접해보지 못하신 분들은 한번 시간을 내어 살펴보시길 추천합니다.기존의 데이터 분석 시스템 아키텍처기존의 데이터 분석 시스템 아키텍처기존의 시스템은 비용을 줄이기 위해 머신들을 사무실 구석에 놓고 직접 관리했으며, AWS S3 Tokyo Region에 있는 로그를 다운받아 따로 저장한 뒤, MapReduce로 계산을 하고 dashboard를 위한 사이트를 따로 제작하여 운영하고 있었습니다.이러한 시스템은 빅데이터 분석을 할 수 있다는 것 외에는 불편한 점이 많았습니다. 자주 고장 나는 하드웨어를 수리하느라 바빴고, 충분히 많은 머신을 확보할 여유가 없었기 때문에 분석 시간도 아주 오래 걸렸습니다. 그리고 분석부터 시각화까지 과정이 복잡하였기 때문에 간단한 것이라도 구현하려면 시간과 노력이 많이 들었습니다.Spark과 Zeppelin을 만나다이때 저희의 관심을 끈 것이 바로 Apache Spark입니다. MapReduce에 비해 성능과 인터페이스가 월등히 좋은 데다가 0.x 버전과는 달리 1.0 버전에서 많은 문제가 해결되면서 안정적으로 운영할 수 있어 비트윈 데이터 분석팀에서는 Spark 도입을 결정했습니다.Apache Zeppelin은 국내에서 주도하고 있는 오픈소스 프로젝트로써, Spark를 훨씬 더 편하고 강력하게 사용할 수 있게 해주는 도구입니다. 주요한 역할은 노트북 툴, 즉 shell에서 사용할 코드를 기록하고 재실행할 수 있도록 관리해주는 역할과 코드나 쿼리의 실행 결과를 차트나 표 등으로 시각화해서 보여주는 역할입니다. VCNC에서는 Zeppelin의 초기 버전부터 관심을 가지고 살펴보다가, Apache Spark를 엔진으로 사용하도록 바뀐 이후에 활용성이 대폭 좋아졌다고 판단하여 데이터 분석에 Zeppelin을 도입하여 사용하고 있고, 개발에도 참여하고 있습니다.또한, 위에서 언급한 하드웨어 관리에 드는 노력을 줄이기 위해서 전적으로 클라우드를 사용하기로 함에 따라서1 아래와 같은 새로운 구조를 가지게 되었습니다.새로운 데이터 분석 시스템 아키텍처새로운 데이터 분석 시스템 아키텍처새로운 데이터 분석 시스템은 아키텍처라고 하기에 다소 부끄러울 정도로 간단합니다. 애초에 전체 시스템 구성을 간단하게 만드는 것에 중점을 두었기 때문입니다. 대략적인 구성과 활용법은 아래와 같습니다.모든 서버는 AWS 클라우드를 이용수 대의 Zeppelin 서버, 수 대의 Spark 서버운영Spark 서버는 메모리가 중요하므로 EC2 R3 instance 사용로그는 별도로 저장하지 않고 서비스 서버에서 S3로 업로드하는 로그를 곧바로 가져와서 분석함중간 결과 저장도 별도의 데이터베이스를 두지 않고 S3에 파일로 저장Zeppelin의 scheduler 기능을 이용하여 daily batch 작업 수행별도의 dashboard용 Zeppelin을 통해 중간 결과를 시각화하며 팀에 결과 공유이렇게 간단한 구조이긴 하지만 Apache Spark와 Apache Zeppelin을 활용한 이 시스템의 능력은 기존 시스템보다 더 강력하고, 더 다양한 일을 더 빠르게 해낼 수 있습니다.기존현재일일 배치 분석코드 작성 및 관리가 어려움Zeppelin의 Schedule 기능을 통해 수행 Interactive shell로 쉽게 데이터를 탐험 오류가 생긴 경우에 shell을 통해 손쉽게 원인 발견 및 수정 가능Ad-hoc(즉석) 분석복잡하고 많은 코드를 짜야 함분석 작업에 수 일 소요Interactive shell 환경에서 즉시 분석 수행 가능Dashboard별도의 사이트를 제작하여 운영 관리가 어렵고 오류 대응 힘듦Zeppelin report mode 사용해서 제작 코드가 바로 시각화되므로 제작 및 관리 수월성능일일 배치 분석에 약 8시간 소요메모리를 활용하여 동일 작업에 약 1시간 소요이렇게 시스템을 재구성하는 작업이 간단치는 않았습니다. 이전 시스템을 계속 부분적으로 운영하면서 점진적으로 재구성 작업을 하였는데 대부분 시스템을 옮기는데 약 1개월 정도가 걸렸습니다. 그리고 기존 시스템을 완전히 대체하는 작업은 약 6개월 후에 종료되었는데, 이는 분석 성능이 크게 중요하지 않은 부분들에 대해서는 시간을 두고 여유 있게 작업했기 때문이었습니다.Spark와 Spark SQL을 활용하여 원하는 데이터를 즉석에서 뽑아내고 공유하는 예제Zeppelin을 활용하여 인기 스티커를 조회하는 dashboard 만드는 예제결론비트윈 데이터 분석팀은 수개월에 걸쳐 데이터 분석 시스템을 전부 재구성하였습니다. 중점을 둔 부분은빠르고 효율적이며 범용성이 있는 Apache Spark, Apache Zeppelin을 활용하는 것최대한 시스템을 간단하게 구성하여 관리 포인트를 줄이는 것두 가지였고, 그 결과는 매우 성공적이었습니다.우선 데이터 분석가 입장에서도 관리해야 할 포인트가 적어져 부담이 덜하고, 이에 따라 Ad-hoc분석을 수행할 수 있는 시간도 늘어나 여러 가지 데이터 분석 결과를 필요로 하는 다른 팀들의 만족도가 높아졌습니다. 새로운 기술을 사용해 본 경험을 글로 써서 공유하고, 오픈소스 커뮤니티에 기여할 수 있는 시간과 기회도 생겼기 때문에 개발자로서 보람을 느끼고 있습니다.물론 새롭게 구성한 시스템이 장점만 있는 것은 아닙니다. 새로운 기술들로 시스템을 구성하다 보니 세세한 기능들이 아쉬울 때도 있고, 안정성도 더 좋아져야 한다고 느낍니다. 대부분 오픈소스 프로젝트이므로, 이러한 부분은 적극적으로 기여하여 개선하여 나갈 계획입니다.비트윈 팀에서는 더 좋은 개발환경, 분석환경을 위해 노력하고 있으며 이는 더 좋은 서비스를 만들기 위한 중요한 기반이 된다고 생각합니다. 저희는 항상 좋은 개발자를 모시고 있다는 광고와 함께 글을 마칩니다.연관 자료: AWS 한국 유저 그룹 - Spark + S3 + R3 을 이용한 데이터 분석 시스템 만들기↩저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!

 이번글은 덕력이 솟구친다는!!!은 아니고요(진짜 아니에요), 혹시 "하츠네 미쿠"라는 캐릭터를 보신 적 있으신가요?하츠네 미쿠! 설마 처음보는 분들이 계신가요?? 출처: https://ec.crypton.co.jp/pages/prod/vocaloid하츠네 미쿠는 VOCALOID(보컬로이드)로서, 간단히 설명하면, 야마하에서 만든 음성 엔진입니다(자세한 내용은 링크를 확인!). 해당 엔진을 기반(자세히는 VOCALOID2인데... 아, 저는 잘 몰라요 진짜예요...)을 기반으로 크립톤 퓨처 미디어사가 아티스트를 만들고, 이를 지적 재산권(이하 IP라고 하겠습니다)으로 창출해 낸 사례입니다! 해당 세션은 이 보컬로이드가 성공할 수 있게 된, 창작자들에게 프로그램 번들 시디를 팔던, 크립톤 퓨처 미디어사가 새로운 미디어와 아트의 중심에 설 수 있게 된 이유를 들을 수 있게 된 좋은 시간이었습니다. 앞으론 말이 매우 딱딱하니 이점 히해해 주세요~! 시작하겠습니다!씨디파는 회사가 인터넷 시대를 맞이하며 겪게 된 위기, 그리고 해결방안. 앞서 말씀드렸든, 크립톤 퓨처 미디어(이하 크립톤이라고 하겠습니다)는 창작자들을 위한 서비스(또는 프로그램)를 번들 또는 디스크 형식으로 판매하는 회사였습니다. 그리고 새로운 세대로 들어서면서, 해당 사업이 사양되고 있고(디스크 판매> 콘텐츠 다운로드의 변화), 특히 음악 제작 서비스의 경우, 작은 시장의 규모 때문에 비즈니스에 대한 한계를 느끼고, 새로운 사업 영역을 펼쳐나가기 위해 방향 모색하기 시작했다고 합니다. 그리고 크립톤이 생각할 수 있는 "자사가 가장 잘할 수 있는 것"을 생각해 보았을 때, "소리"라는 콘텐츠를 방점으로 서비스를 응용해 나가면서 스팩트럼을 넓히자!라는 생각을 했다고 합니다. 그래서 시작한 것이 바로, 보컬로이드!라는 것이었죠.보컬 합성 기술(보컬로이드) + IP의 도입은 처음부터 성공적이진 않았습니다. 처음 크립톤은 야마하의 보컬로이드 기술을 기반, Leon과 Lola라는 소프트웨어를 제작,  당사에서 유통을 시작했을 때에는, 타깃 유저를 잡는데 실패해 매출에 전혀 도움이 되지 않았다고 합니다(아래 사진을 보면 왠지 알 거 같...)첫 보컬로이드 레온과 로라입니다..... 음... 입술이 매력적 이네요.... 출처: http://vocaloid.wikia.com/wiki/Forever_(Zero-G_song) 그 이유는 해당 서비스를 사용할 것이라고 타게팅한 아티스트들의 경우, 목소리에 관해 리얼함을 추구하는 데, 해당 소프트웨어는 하드웨어로 조정하는 음과 음성들이 리얼함이 다소 떨어져 전혀 니즈가 없었던 것이죠.그래서 트립톤은"해당 서비스를 진짜 사용하는 유저들은 어떤 사람들 일까?"에 대한 고려를 기반으로,"메이코"라는 일본어로 노래하는 보컬로이드를 제작, 흥미를 끌 수 있도록 캐릭터를 모티브로 하는 커버 디자인 작업 시작(안드로이드 아니 보컬로이드 이니깐요!)이제는 버전 쓰리가 된 메이코! (출처:http://vocaloid.wikia.com/wiki/MEIKO) 첫 출시 당시, 거부감도 있었지만, 당시 KPI 목표인 500개를 훌쩍 넘어 3,000개의 판매 성공을 거뒀고, 성공의 요인은 패키징 디자인과 단순한 아티스트뿐만이 아닌, 다양한 콘텐츠에 관심을 가지는 다양한 유저들을 유저들을 이끌 수 있는 요소들이 있어서 라고 판단하였다고 합니다. (서비스를 사용할 것이다 라는 사용자의 경험에 대한 고려를 더 많이 한 포인트라고 생각되는 부분이지요!)메이코 이후 드디어 그분을 만들어 내는 것을 준비합니다.크립톤은 이때부터 정말로 사용자들이 무엇을 원하는가에 대한 생각을 많이 한 것 같다고 보이는 포인트입니다. 메이코의 등장 이후, "하츠네 미쿠"라는 캐릭터 산업으로 만들어 내는 것을 준비합니다. 그리고 해당 캐릭터를 하나의 "사업전략"으로 생각해 낸 이유는 메이코의 KPI달성도 있겠지만, "사람의 목소리와 극히 다른 목소리로 노래를 부르게 된다면, 이상하지 않을까?라는 부분을 오히려 역으로 기획, "인간이 아닌 다른 안드로이드가 하는 노래"라는 새로운 존재로서 IP를 만들어 버린 것이죠!또,  캐릭터를 기반으로 다양한 성격을 가질 수 있도록 "성우"라는 시스템을 집어넣어 "특별한 존재"라는 특징 성을 추가하였고, 기존의 보컬로이드는 "인간의 가수를 대체하는 것"이었으나, 하츠네 미쿠는 "안드로이드 가 부르는 진짜 보컬로이드"라는 접근을 통해 새로운 존재를 만들고, 메이코 디자인을 기반으로, "아이돌 라이즈 된 새로운 사이버 가수"를 만든 것이죠!아아.... 이제 고인이 되신 사이버 가수 아담... (http://beautinaru.tistory.com/196 또한, 해당 콘텐츠를 기반으로 음악을 만들었던 유저들에게 레트로 한 마크들을 집어넣어서 예전에는 이랬었지 라는 향수를 불러일으키고, 해당 콘텐츠를 기반으로 다시 작업을 할 동기를 줄 수 있도록 유저들의 의견을 듣고 반영하는 일들을 굉장히 많이 했다고 합니다!그리고 하츠네 미쿠의 진정한 아이덴티티를 생성합니다. 그것은 바로 Chain of Co-creation!!!하츠네 미쿠가 이렇게 성장할 수 있었던 이유는 저는 하나만 꼽으라 라고 한다면 이쁘잖아요! 가아니라... "확산 가능 여부"에 대한 많은 고려가 있었기에 가능했다고 생각합니다.인터넷 덕분에 음악 등을 만드는 사람들이 쉽게 업로드하고 공유할 수 있는 많은 플랫폼들이 생성되는 현실.덕이 많은 분들이 공유를 통해 자아실현을 하는 공감대를 형성할 수 있는 움직임이 확산.콘텐츠가 콘텐츠를 만들고 퍼져나가는 순기능적인 부분들이 늘어나는 현상들을 확인하고,2차 3차 저작물을 통한 확산> Chain of co-creation의 순선환 적인 기능들이 생겨나는 것이죠!! 그리고 그런 상황을 기반으로, 궁극적으론,모든 사람들이 제작자가 될 수 있는 현실 상황을 받아들이고,제작할 수는 있지만,  저작에 관련한 법률 등에서 막히는 상황을 막기 위해, 창작자들의 창작활동을 돕고, 실제 업로드된 콘텐츠를 기반으로, 실제 사업이 일어날 수 있는 방향으로 전개합니다!그리고 수익화를 통해서 창작자들이 창작활동 = 수익활동이 될 수 있도록 플랫폼 화를 추진한 것이죠!그래서 처음 하츠네 미쿠가 나온 2007년부터 10년이 지난 지금까지도 "보컬로이드"의 선두 주자로 전 세계적으로 콘서트를 다니며 성공적인 투어를 하고 있습니다.투어는 계속된다. (출처: http://mikuexpo.com/) 저는 하츠네 미쿠가 단지 덕후들의 승리라고 요만큼도 생각하지 않습니다.하츠네 미쿠를 성장시킬 수 있었던 건 "우리가 제공하는 서비스가 어떤 유저들에게 더 많은 강점이 있고, 해당 유저들은 어떤 행동을 통해서 자아를 성찰할 수 있을까? 그리고 해당 행동을 통해 유저가 얻는 궁극적인 이익들이 잇을까?"를 생각했던, 크립톤의 유저를 생각하는, 유저의 직접적인 경험을 서비스에 반영하려고 하는 강한 의지가 해당 서비스를 성공시킬 수 있게 한 요인이라고 생각해요. 그런 의미에서 저에겐 정말로 뜻깊고 즐거웠던 세션이었습니다!P.S.: 이제 슬슬 NDC2017 영상들이 올라오기 시작하네요! 관심 있는 분들은 https://ndc.nexon.com/main에서 확인해 보세요~오늘도 긴 글 읽어주셔서 감사합니다! 다소 글이 엉망진창이라도 이해해 주세요! #코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트

클라우드 서비스를 사용하시는 많은 분들이 CPU Steal Time에 대해 문의합니다. CPU Steal은 클라우드 서비스와 물리 서버의 환경차이에서 발생하는 대표적인 지표이기도 합니다. CPU Steal Time이 높아지면 CPU 부하율이 높아지기 때문에 웹 서비스에 장애를 초래하기도 합니다. 가상화를 위해 자원을 분배하는 과정에서 cpu의 자원을 빼기는 것이기 때문에 클라우드 사용자 입장에서는 억울한 감이 있는 지표이기도 합니다. 하지만 클라우드 서비스가 공유 자원을 효율적으로 사용하는 것이기에 어쩔 수 없는 부분이기도 합니다. 그럼 이 CPU Steal Time 또는 CPU Stolen Time이라고 불리는 지표에 대해 알아보도록 하겠습니다.  CPU Steal Time이 무언가요?CPU Steal time은 은 하이퍼 바이저가 다른 가상 프로세서를 서비스하는 동안 가상 CPU가 실제 CPU를 기다리는 시간을 백분율로 표시한 값입니다.가상 환경에서 동작하는 가상 시스템 (VM)은 단일 호스트에있는 다른 인스턴스와 리소스를 공유합니다. 공유하는 리소스 중 하나가 CPU주기입니다. VM이 실제 서버에있는 동일한 크기의 4 개의 VM 중 하나 인 경우 해당 CPU 사용률은 모든 CPU주기의 25 %로 제한되지 않습니다. CPU 사용 비율보다 많은 비율을 사용할 수 있습니다.CPU Steal Time은 어떻게 확인하는가?Linux top 명령을 실행하면 주요 성능 메트릭의 실시간보기를 볼 수 있습니다. 그 중 하나는 CPU를위한 것입니다.이미 경험 한 두 가지 통계는 % id (percent idle)와 % wa (percent I/O wait)입니다. % id가 낮 으면 CPU가 열심히 작동하고 있는 것이며 % id가 높으면 남은 용량이 많지 않은 것입니다. % wa가 높으면 CPU는 실행할 준비가되었지만 I / O 액세스가 완료 될 때까지 기다리고 있습니다 (디스크에 저장된 데이터베이스 테이블에서 행을 가져 오는 것과 같습니다).% st 또는 % steal time은 표시된 마지막 CPU 메트릭입니다.CPU steal time이 높으면 어떤 상황이 발생하는가.백그라운드에서 장시간 걸리는 작업의 경우, 다른 VM들과 CPU 주기를 공유하는 과정에서 조금 더 느리게 작업이 마무리 될 수 있습니다. CPU steal time은 이런 경우 작업을 중지시키는 요소로 작용하지 않습니다. 가끔은 리소스를 나누는 과정에서 작업이 더 빠르게 끝나기도 합니다. 하지만 웹앱의 경우 실시간 처리가 필요한 경우들이 있습니다. 많은 웹 응답이 이뤄져야 하는 상황에서 cpu steal time이 높아지고, 그로인해 성능이 4배이상 감소한다면 중요한 리케스트가 처리되지 못하면서 서비스에 장애가 발생할 수도 있습니다. CPU steal time이 높은 원인은?cpu steal time이 높은 원인은 둘 중 하나입니다.  더 많은 CPU 리소스를 가지고 있는 VM을 필요로 합니다. (여러분의 문제입니다.)물리버서가 과대 판매되어 가상화 장비가 공격적으로 경쟁하는 상황입니다. (여러분의 문제가 아닙니다. 아마존 나빠요.)아쉽게도 cpu 매트릭만으로 위 두가지 상황을 판별하는 것은 쉽지 않습니다. 하지만 같은 역할을 하는 복수의 호스트를 여러개 가지고 있다면 다음과 같이 분별해 볼 수 있습니다.  1. 리소스 부족의 경우위 그림처럼 모든 VM에서 %st(cpu steal time)이 높다면 시스템이 더 많은 cpu를 사용해야 한다는 것을 의미합니다. 더 높은 사양의 VM을 선택하셔야 합니다. 2. 클라우드 사업자의 과다 판매의 경우위 그림처럼 일부의 VM에서만 %st(cpu steal time)이 높다면 같은 물리 호스트에 있는 다른 VM들이 서버의 자원을 과다하게 사용하고 있을 확률이 높습니다. 물리적으로 다른 호스트로 이동하여 해결 할 수 있습니다.대처 방법을 알아보자.일반적인 경우 steal time이 20분동안 10%를 넘기는 상태에서 유지되고 있다며, VM은 정량 보다 느리게 동작하고 있을 것입니다.인스턴스를 중지하고 다른 물리 서버로 이동하세요. 그래도 steal time이 높다면 cpu 리소스를 업그레이드하세요. 그리도 steal time이 높다면 클라우드 서비스 제공자에게 문의하세요.클라우드 서비스가 과설계된것은 아닌지 알아보세요. 와탭을 사용해서 cpu steal 매트릭을 추적하세요. 최근 와탭에 들어오는 가장 많은 문의 중 하나가 cpu steal입니다. cpu steal로 인해 cpu 부하율이 80%이상으로 올라가는 경우 클라우드 서비스에 익숙하지 않은 분들은 많이 당항하게 됩니다. 이런 경우 너무 곤란해 하지 마시고 일회성 이슈인지 체크하시고 반복된다면 cpu 리소스를 업그레이드 하거나 서비스를 다른 물리서버로 이동하시기 바랍니다. 제가 가지고 있는 sample중에 cpu steal이 나온 케이스가 없지만 whatap.io는 cpu steal 값을 5초마다 저장하여 제공합니다.  관련 urlhttp://hakurei.tistory.com/67[Linux] 가상환경에서의 CPU Steal Time 개념물리 장비에다가 여러대의 가상머신을 두는 가상환경을 구축하는 경우가 많다. 가상머신이 많아지는 경우, 동일한 물리 장비에서 제공되는 환경이다보니, 특정 가상머신이 CPU를 많이 차지하게 되면, 다른 머신들도 따라서 느려지게 되는데, 이 현상을 CPU Steal이라고 한다. CPU를 많이 차지하고 있는 머신의 CPU Steal Time은 낮게 측정이되고, 같은 물리 장비에 구성된 다른 가상 머신의 경우 CPU Steal Time이 높게 측정이..hakurei.tistory.com http://www.stackdriver.com/understanding-cpu-steal-experiment/» Understanding CPU Steal – An Experimentwww.stackdriver.com http://blog.scoutapp.com/articles/2013/07/25/understanding-cpu-steal-time-when-should-you-be-worriedUnderstanding CPU Steal Time - when should you be worried?blog.scoutapp.com #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

스푼을 만드는 사람들 여섯 번째 이야기서비스 플랫폼 팀 막내이자 분위기를 담당을 맡고 있는, 6개월 차 개발자 Kyu를 소개하고자 한다.영어가 편해요? 아니면 한국어가 편해요?"일반적인 의사소통에 있어선 한국어가 편하고, 업무를 볼 땐 영어가 편해요."Q. 원래 되게 개구쟁이(?)의 이미지를 가지고 계신 줄 알았는데.."저 원래 진지한 거 진짜 싫어해요. 제가 겉보기엔 늘 장난꾸러기 같아 보이실 수도 있지만, 사실 이렇게 단 둘이 이야기를 하면 또 다른 진지하고 진정성 있는 저의 모습이 보이실 거예요. 저 지금 많이 진지해요?"(인터뷰 전에는 큐가 그저 재미있는 사람이라고 생각했는데, 인터뷰를 하고 나서 그를 다시 보았습니다..)'Kyu'라는 사람을 알고 싶습니다.Q. 본인은 어떤 사람이라고 생각하세요?Me, Myself, and I - "저는 제가 느끼는 것 그리고 원하는 것에 굉장히 집중을 하는 편이에요.제 본인 스스로에게 집중하는 양도 기준치도 꽤나 높은 편이에요. 무엇보다 스스로 혼자만의 시간을 굉장히 중요시합니다."Q. 국적이 Canadian이라 들었습니다. "네, 저는 8살 때 부모님과 함께 교육을 위해서 캐나다로 이민을 갔었어요. 그리고 캐나다에서 고등학교까지 있었고 그 후엔 미국에서 대학을 졸업했어요. 졸업 후에 한국에 취업을 하게 되어서 어느덧 한국 생활이 1년 3개월 차가 되어가고 있네요."Q. 한국에서 취업을 하게 된 계기가 있다면?"사실 처음에 제가 스타트업에 취업을 한다고 했었을 때, 주변에서 안정적인 곳이 아닌 스타트업을 선택하느냐라고 많이들 물어보셨어요. 그것도 한국에서요. 근데 저는 제가 정말 무슨 일을 하고 싶은지 잘 몰랐었어요. 목표의식과 노력 없이 공부를 하다 보니, 어느덧 졸업이 다가왔고 좌절하게 됐었어요. 정말 오랜 시간 아무것도 못했었어요. 길을 잃었다고 할까요? 그러다가, 용기를 내서 현실적으로 내가 할 수 있는 일이 무엇일까 고민 끝에 한국을 선택했어요. 한국엔 유능한 사람들이 정말 많고, 실력 있는 사람들이 열심히도 하는 곳이에요. 정말 무언가를 최선을 다해서 해본 다는 게 무엇인지 겪기 위해선 한국에서 배워보는 게 좋다고 생각했고, 실제로도 그렇다는 걸 느끼고 있어요."당신의 회사생활이 궁금합니다Q. 서비스 플랫폼 팀(서버팀)에서 하고 계신 업무는?"저는 현재 하고 있는 업무는, 정확히 말하자면 로그 데이터 수집 및 스푼 앱 내에서 발생하는 유저들의 행동 그리고 현상에 대한 데이터를 실시간으로 수집하고 조회합니다. 그리고 시간에 흐름에 따른 서비스 상태를 나타내 주는 작업을 하고 있습니다."Q. 현재 업무의 만족도는 어느 정도인가요?"업무에 대한 만족도는 높습니다. 저는 신입이고, 기본 역량이 팀원들에 비해서는 낮지만 제가 입사한 후 처음 시도한 것이 '로그 데이터 수집'인데요. 처음부터 끝까지 독립 시스템을 맡고 있다는 점이 굉장히 뿌듯합니다. 저를 그만큼 믿어주시기에 가능한 일이라고 생각합니다. 그렇다 보니 주인의식을 가지게 되고요. 앞으로 조금 더 만족도를 높이고자 한다면, 팀원들과 프로젝트를 도 함께 진행해보고 싶습니다."Q. 스푼 라디오가 큐의 첫 직장인 가요?"네, 정사원으로는 첫 직장이지만 그 전에는 인턴을 잠시 했었어요. 이건 제가 한국에서 겪은 좋지 않은 기억이지만, 인턴 생활 때, 타 스타트업에서 3개월 정도를 일을 했었는데, 임금 체불 문제가 있었어요. 당연한 부분이자 저의 권리가 지켜지지 않는 것을 보고, 다시 캐나다에 가고 싶단 생각을 했었어요. 그때 자존감도 많이 낮아지고 참 암울했던 시기였어요."Q. 한국 회사에서 느끼는 문화 차이가 있나요?"사실 제가 생각했던 것보다 워라벨이 잘 지켜지고 있어서 그 부분은 의외라고 생각이 들었어요.다만, 사람들과 함께 편하게 이야기를 하는 과정에서 문화적 차이를 느끼곤 해요. 예를 들면 Gender 부분 이라던지 등등. 의식이 조금 다르다고 느낄 때가 있어요. 하지만 한국 문화라던지, 의식의 차이를 저도 받아들이고 많이 노력하고 있어요. 누구나 의견과 관점은 다를 수 있으니까요. 잘 못되었다기 보단, 다른 사람들이구나 하고 받아들이려고 합니다."Q. 회사에서 가깝게 지내는 동료는 누구인가요?"업무를 가장 많이 함께 해서 가까운 분은 찰스, 개인적으로 제일 친하다고 느끼는 분은 샘입니다. 왜 친하다고 느끼는지는 모르겠지만 저도 모르게 자꾸 관심이 가요. 빨리 더 친해지고 싶은 생각도 들고, 그저 좋은 분이라고 느껴서입니다." (하지만 그분의 마음은 저도 몰라요.. 저만 친하다고 느낄 수도?)커피를 좋아하는 Kyu 당신의 사생활이 궁금합니다Q. 언제 가장 캐나다가 그립다거나 가고 싶어요?"일단, 미세먼지 많은 날이요.  그리고, 가끔씩 이런 마음이 들 때가 있어요. 한국에서는 쳇바퀴도는 매일 똑같은 삶을 사는 것 같다는 느낌(?) 한국에서는 아무것도 하지 않아도, 뭔가 늘 바쁜 그런 느낌이 들어요. 안정감이 없다고 해야 할까요? 한국은 소비를 통해서 스트레스를 해소하는 나라인 거 같아요. 주로 뭘 사 먹거나, 소유하거나. 근데 캐나다에서 랑 미국에선 다른 방식으로 스트레스를 풀 수 있었거든요. 공감하시려는지 모르겠어요. 저는 그렇답니다. 한국에 살다 보니 이제는 사실 오히려 이제는 외국에 나가 산다는 게 더 큰 도전이 된 느낌이기도 하고요."Q. 가장 좋아하는 캐나다 음식은?"캐나다 초밥요! 캘리포니아 롤이 캐나다 밴쿠버에서 만들어졌단 사실 알고 계시나요? 저 그거 정말 좋아합니다.."Q. 스스로를 어느 나라 사람이라고 생각하나요?"저는 국적은 캐나다이지만, 저의 정체성은 한국에서 시작되었고, 한 번도 그걸 잊은 적이 없어요. 캐나다에서도 한국 문화에 대한 관심을 늘 가지고 있었거든요. 예능이라던지, 시트콤 다 따라서 봤었으니까요. (원래 외국에 살면 더 한국 프로그램 많이 보게 된다는..) 아무쪼록, 저는 제가 한국인임을 잊어 본 적이 없어요. 비록 국적은 캐나다인이지만요. 그리고 저는 최대한 한국의 가십거리를 말하지 않아요. 왜냐면, 저는 이곳에 오래 살지 않았고 제가 기여할 수 있는 부분이 굉장히 제한적이거든요. 제가 국방의 의무를 했다거나, 투표권이 있으면 모를까 제가 감히 함부로 한국에 대해서 말하고 싶지 않아요. 무엇보다 저는 제 스스로가 어느 국가의 사람인 지보단 '나'라는 스스로에 집중하는 편이에요."(앞으로 외국인이라고 부르지 않을게요 큐..)Q. 다른 이루고 싶은 꿈이 있다면?"다음 생에 저는 래퍼가 되고 싶어요. 정말로 진지하게, 힙합과 랩이라는 문화를 존중하고 좋아합니다. 그저 취미로 시작하고 싶은 게 아니라,  정말 다시 태어나면 온전히 랩에 집중해서 좋은 래퍼가 되고 싶어요."Q. 어떤 사람과 함께 일하고 싶나요?개발자로서 이루고 싶은 비전이 확실한 사람이요. 무엇보다 소통하는 데 있어서 나이를 떠나, 마음이 열려있는 사람과 함께 일하고 싶습니다. 서로를 존중할 수 있는 그런 사람이요.탁구를 좋아하는 KyuQ. 마지막으로 하고 싶은 말이 있다면?"주변 친구들이 스푼에서 일을 시작하기 전과 후가 많이 바뀌었다고 말하는데, 저는 제 스스로에게 정말 많은 변화가 생겼다고 생각해요. 조금 더 진지하고 진중한 사람이 된 것 같고 이 긍정의 변화가 앞으로도 계속되길 바랍니다. 아! 그리고 회사에 제공되는 샐러드가 매일 아침마다 오면 좋겠어요. 저 그럼 정말 회사 지금보다 더 즐겁게 다닐 수 있습니다"P.S: 매번 다른 사람들의 인터뷰를 하고 계신 Sunny를 제가 직접 인터뷰해보고 싶어요.서비스 플랫폼팀 팀원들이 Kyu를 한마디로 표현한다면?Charles 曰:  '대장' - 대시보드 장인Sam 曰:  '거머리' - 자꾸 달라붙어서..Mark 曰: '감초 같은 사람' - 약방의 감초처럼 저희 팀 업무 전반에 없어선 안될 사람(큐가 이렇게 하라고 시켰어요) 

1. Planning PokerStyleShare 개발팀에서는 스크럼을 활용하여 일을 진행하고 있습니다.1 스크럼에는 일감의 크기를 추정estimate하는 과정이 있는데요. 구성원들 모두가 일감에 대해 이해하고 일감의 크기가 어느정도인지 함께 논의하여 합의에 이르는 과정입니다. 스프린트 회의에서 일감을 등록한 사람(리포터)이 일감에 대해 설명하고 나서 전체 구성원들이 일감의 크기를 추정하는데, 이 때 사용하는 것이 바로 Planning Poker입니다.Planning Poker는 0.5부터 시작해서 1, 3, 5, 8, 13, 20, … 100과 같이 피보나치 수열로 증가하는 숫자를 가진 카드 덱입니다. 리포터의 설명이 끝난 뒤 스크럼 마스터가 하나, 둘, 셋을 외치면 각자 생각한 일감의 크기에 맞는 카드를 꺼내고, 스크럼 마스터는 구성원들의 추정치가 최대한 가까워지도록 부가설명이나 질문을 유도합니다.2▲ Planning Poker는 이렇게 생겼다. (출처: Control Group 블로그)하지만 개발팀이 커지면서 불편함이 생기기 시작했습니다. 회의에 참여하는 인원이 7-8명씩 되다 보니, 각자가 어떤 카드를 들고있는지 한눈에 보기가 어려워진 것입니다. StyleShare에서 자칭 아이디어 뱅크 역할을 담당하고 있는 저는 획기적인 방법이 필요하다고 생각했고, 굳이 카드를 꺼내들지 않아도 각자가 무슨 카드를 선택했는지를 쉽게 볼 수 있는 애플리케이션을 만들기로 결심했습니다.2. BLE (Bluetooth Low Energy)불편함을 덜기 위한 애플리케이션이므로, 사용자 경험이 굉장히 직관적이고 단순해야 했습니다. N:N 통신이 가능해야하고, 사용자를 귀찮게 하는 페어링Pairing이나 네트워크 접속 과정이 없어야 했습니다. 한마디로, 카드를 꺼내들고 눈으로 확인하는 것보다 더 편한 무언가를 만들어야 했습니다!처음에는 근거리 무선 통신을 위한 기술로 스타벅스에서 사이렌 오더 개발에 사용한 고주파 인식 기술을 생각했습니다.3 각자의 기기에서 선택한 카드에 맞는 소리를 내보내고, 다른 기기에서는 고주파를 읽겠다는 것이었는데요. Soundlly(구 aircast.me)와 같은 상업용 SDK를 쓰지 않는 이상, 사운드 프로그래밍을 한 번도 해본 적 없는 저에게는 데이터가 실린 고주파를 만드는 것부터 소리를 인식해서 데이터를 읽어내는 과정이 마치 화성에서 감자 키우는 이야기처럼 들렸습니다.그러다 문득 생각난 것이 바로 비콘Beacon입니다. 언젠가 소비자가 오프라인 매장에 방문하면 BLE를 이용해서 매장 위치를 파악하는 기술이 있다는 이야기를 들은 적이 있었습니다. 찾아보니 시중에 나와있는 대부분의 모바일 기기에서는 BLE를 위한 최소 조건인 블루투스 4.0을 지원했고, 페어링이나 네트워크 접속 과정도 불필요했습니다. 무엇보다, 화성에서 감자 키우는 것보다는 쉬워보였습니다.3. Swift로 BLE 개발하기그래서 BLE를 사용해서 개발하기로 했습니다. 컨셉은 간단했습니다. 내가 선택한 카드를 브로드캐스팅하고, 다른 사람들이 선택한 카드를 내 모바일 기기에 보여주면 되는 것이었습니다. BLE를 사용하면 정보를 브로드캐스팅할 수 있고, 다른 기기에서 브로드캐스팅하는 정보를 읽을 수 있습니다.BLE에서 데이터를 브로드캐스팅하는 것을 Advertising이라고 합니다. 정보를 advertising하는 주체는 Peripheral이고, advertising되는 정보를 스캔하여 데이터를 읽어들이는 주체는 Central이라고 합니다. Peripheral에서 정보를 advertising할 때에는 특정한 정보를 실어나를 수 있는데요. 이를 Advertising Data Payload라고 합니다. 이 정보에 카드 숫자와 이름을 실어서 전송하면 될 것 같습니다.BLE를 구현하기 위해서, iOS에서는 SDK에 기본적으로 포함돼있는 CoreBluetooth 프레임워크를 사용하면 손쉽게 개발이 가능합니다. CBPeripheralManager 클래스와 CBCentralManager 클래스를 쓰면 되는데요. BLE를 이용하여 제 이름 석자를 advertising하는 코드는 다음과 같습니다.Peripheralimport CoreBluetooth let serviceUUID = CBUUID(string: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX") let service = CBMutableService(type: serviceUUID, primary: true) /// 1. `CBPeripheralManager`를 초기화하고, self.peripheral = CBPeripheralManager(delegate: self, queue: nil) /// 2. 사용가능한 상태가 되면 특정 UUID를 가진 서비스를 추가한 뒤에 func peripheralManagerDidUpdateState(peripheral: CBPeripheralManager) { if peripheral.state == .PoweredOn { self.peripheral.addService(service) } } /// 3. 원하는 정보를 advertising합니다. func peripheralManager(peripheral: CBPeripheralManager, didAddService service: CBService, error: NSError?) { self.peripheral.startAdvertising([ CBAdvertisementDataLocalNameKey: "전수열", CBAdvertisementDataServiceUUIDsKey: [serviceUUID], ]) } 참고로, UUID는 커맨드라인 명령어를 통해 쉽게 만들 수 있습니다.$ uuidgen XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX 마찬가지로, Peripheral에서 advertising하는 정보를 스캔하는 Central 코드는 다음과 같이 작성할 수 있습니다. UUID는 Peripheral에서 advertising에 사용한 UUID와 동일해야합니다.Centralimport CoreBluetooth let serviceUUID = CBUUID(string: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX") let service = CBMutableService(type: serviceUUID, primary: true) /// 1. `CBCentralManager`를 초기화하고, self.central = CBCentralManager(delegate: self, queue: nil) /// 2. 사용가능한 상태가 되면 특정 UUID를 가진 서비스를 스캔합니다. func centralManagerDidUpdateState(central: CBCentralManager) { if central.state == .PoweredOn { // 이미 한 번 스캔된 정보라도 계속 스캔합니다. let options = [CBCentralManagerScanOptionAllowDuplicatesKey: true] self.central.scanForPeripheralsWithServices([serviceUUID], options: options) } } /// 3. Peripheral이 스캔되면 이 메서드가 호출됩니다. func centralManager(central: CBCentralManager, didDiscoverPeripheral peripheral: CBPeripheral, advertisementData: [String : AnyObject], RSSI: NSNumber) { print(advertisementData[CBAdvertisementDataLocalNameKey]) // "전수열" } 스캔을 시작할 때 CBCentralManagerScanOptionAllowDuplicatesKey 옵션을 true로 설정해서 한 번 스캔된 정보라도 중복으로 계속 스캔하도록 합니다.4. 원하는 정보를 실어나르기CBPeripheralManager을 사용하여 advertising을 할 때에는 Advertising Data Payload를 포함시킬 수 있는데, 이 정보 중 개발자가 원하는 값을 넣을 수 있는 곳은 CBAdvertisementDataLocalNameKey밖에 없습니다. 그마저도 길이가 제한돼있기 때문에, 패킷을 효율적으로 사용하기 위해서는 정보를 저장하는 프로토콜을 직접 정의해야 합니다.우선, 카드에 대한 정의는 enum을 사용해서 작성했습니다. 0부터 0xFF까지의 숫자를 가지도록 정의했습니다.public enum Card: Int { case Zero = 0 case Half = 127 case One = 1 case Two = 2 case Three = 3 case Five = 5 case Eight = 8 case Thirteen = 13 case Twenty = 20 case Fourty = 40 case Hundred = 100 case QuestionMark = 0xFD case Coffee = 0xFE case None = 0xFF } 그리고 제가 정의한 패킷의 프로토콜은 다음과 같습니다.영역길이예시설명Version200프로토콜 버전 (00~FF)Channel201BLE 커버리지 내에서 회의하는 팀이 여럿일 수 있으니, 채널로 구분합니다. (00~FF)Card2FE카드의 16진수 값 (00~FF)Name12전수열사용자 이름 (UTF-8 기준 한글 4글자)이렇게 하면 총 18바이트 내에서 필요한 정보를 모두 전송할 수 있습니다. 이제 이 "00", "01", "FE", "전수열" 값을 직렬화해서 CBAdvertisementDataLocalNameKey로 advertising하면 됩니다.Peripheralself.peripheral.startAdvertising([ CBAdvertisementDataLocalNameKey: "0001FE전수열", CBAdvertisementDataServiceUUIDsKey: [serviceUUID], ]) 그리고, Central에서 정보를 스캔할 때에는 이 값을 각 영역의 길이에 맞게 끊어서 읽을 수 있습니다.5. 마치며비록 적은 양의 정보지만, BLE를 사용해서 실시간으로 근거리 통신을 할 수 있게 되었습니다. 이제 남은 것은 카드를 선택할 수 있는 화면과, 다른 사용자가 선택한 카드를 화면에 보여주는 인터페이스입니다. UI 개발은 본 포스트에서 중점적으로 다루고자 하는 주제와는 조금 벗어난 이야기가 될 것 같아, 오픈소스로 공개된 코드로 대신하려고 합니다. 소스코드는 GitHub에서 볼 수 있으며, Estimator는 앱스토어에서 받아보실 수 있습니다.6. 참고 자료BLE(BLUETOOTH LOW ENERGY) 이해하기 - Hard Copy World스타일쉐어의 스크럼이 지나온 길 포스트에 보다 자세히 설명되어 있습니다. ↩구성원들의 추정치에 차이가 난다는 것은 해당 일감에 대해 서로가 이해하고 있는 정도가 다르기 때문입니다. 스크럼 마스터는 구성원들이 일감에 대해 모두 비슷한 생각을 가지도록 커뮤니케이션을 유도해야합니다. ↩http://www.bloter.net/archives/226643 ↩#스타일쉐어 #개발 #개발팀 #개발자 #인사이트

최근의 서비스/애플리케이션의 개발 흐름은 멀티 플랫폼, 멀티 디바이스 시대로 넘어와 있습니다. 단순히 하나의 브라우저만 지원하면 되었던 이전과는 달리, 최근의 서버 프로그램은 여러 웹 브라우저는 물론이며, 아이폰, 안드로이드 애플리케이션과의 통신에 대응해야 합니다. 그렇기 때문에 매번 서버를 새로 만드는 수고를 들이지 않기 위해선 범용적인 사용성을 보장하는 서버 디자인이 필요합니다.REST 아키텍처는 Hypermedia API의 기본을 충실히 이행하여 만들고자 하는 시스템의 디자인 기준을 명확히 확립하고 범용성을 보장하게 해줍니다. 이번 글에선 현대 서비스 디자인을 RESTful하게 설계하는 기초적인 내용에 대해 정리하려고 합니다.REST란 무엇인가?REST는 Representational state transfer의 약자로, 월드와이드웹과 같은 분산 하이퍼미디어 시스템에서 운영되는 소프트웨어 아키텍처스타일입니다. 2000년에 Roy Fielding에 의해 처음 용어가 사용되었는데, 이 분은 HTTP/1.0, 1.1 스펙 작성에 참여했었고 아파치 HTTP 서버 프로젝트의 공동설립자이기도 합니다.REST는 HTTP/1.1 스펙과 동시에 만들어졌는데, HTTP 프로토콜을 정확히 의도에 맞게 활용하여 디자인하게 유도하고 있기 때문에 디자인 기준이 명확해지며, 의미적인 범용성을 지니므로 중간 계층의 컴포넌트들이 서비스를 최적화하는 데 도움이 됩니다. REST의 기본 원칙을 성실히 지킨 서비스 디자인은 “RESTful 하다.” 라고 흔히 표현합니다.무엇보다 이렇게 잘 디자인된 API는 서비스가 여러 플랫폼을 지원해야 할 때, 혹은 API로서 공개되어야 할 때, 설명을 간결하게 해주며 여러 가지 문제 상황을 지혜롭게 해결하기 때문에 (버전, 포맷/언어 선택과 같은) REST는 최근의 모바일, 웹 서비스 아키텍처로서 아주 중요한 역할을 하고 있습니다.중심 규칙REST에서 가장 중요하며 기본적인 규칙은 아래 두 가지입니다.URI는 정보의 자원을 표현해야 한다.자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다.1번 사용자에 대해 정보를 받아야 할 때를 예를 들면, 아래와 같은 방법은 좋지 않습니다.GET /users/show/1 이와 같은 URI 방식은 REST를 제대로 적용하지 않은 구 버전의 Rails에서 흔히 볼 수 있는 URL입니다. 이 URI은 자원을 표현해야 하는 URI에 /show/ 같은 불필요한 표현이 들어가 있기 때문에 적절하지 않습니다. 본다는 것은 GET이라는 HTTP Method로 충분히 표현할 수 있기 때문이죠. 최근의 Rails는 아래와 같이 변경되었습니다.GET /users/1 자원은 크게 Collection과 Element로 나누어 표현할 수 있으며, 아래 테이블에 기초한다면 서버 대부분과의 통신 행태를 표현할 수 있습니다.ResourceGETPUTPOSTDELETERESTful Web Service HTTP methodsCollection URI, such as http://example.com/resources/컬렉션에 속한 자원들의 URI나 그 상세사항의 목록을 보여준다.전체 컬렉션은 다른 컬렉션으로 교체한다.해당 컬렉션에 속하는 새로운 자원을 생성한다. 자원의 URI는 시스템에 의해 할당된다.전체 컬렉션을 삭제한다.Element URI, such as http://example.com/resources/item17요청한 컬렉션 내 자원을 반환한다.해당 자원을 수정한다.해당 자원에 귀속되는 새로운 자원을 생성한다.해당 컬렉션내 자원을 삭제한다.이 외에도 PATCH 라는 HTTP Method에도 주목하시기 바랍니다. PUT이 해당 자원의 전체를 교체하는 의미를 지니는 대신, PATCH는 일부를 변경한다는 의미를 지니기 때문에 최근 update 이벤트에서 PUT보다 더 의미적으로 적합하다고 평가받고 있습니다. Rails도 4.0부터 PATCH가 update 이벤트의 기본 Method로 사용될 것이라 예고하고 있습니다.입력 Form은 어떻게 받아오게 하지?위의 예시를 통해 많은 행태를 표현할 수 있습니다만 새로운 아이템을 작성하거나 기존의 아이템을 수정할 때 작성/수정 Form은 어떻게 제공할지에 대한 의문을 초기에 많이 가집니다.정답은 Form 자체도 정보로 취급해야 한다는 것입니다. 서버로부터 “새로운 아이템을 작성하기 위한 Form을 GET한다”고 생각하시면 됩니다. Rails 에선 기본적인 CRUD를 제공할 때 아래와 같은 REST 인터페이스를 구성해줍니다.HTTPVerbPathactionused forGET/photosindexdisplay a list of all photosGET/photos/newnewreturn an HTML form for creating a new photoPOST/photoscreatecreate a new photoGET/photos/:idshowdisplay a specific photoGET/photos/:id/editeditreturn an HTML form for editing a photoPUT/photos/:idupdateupdate a specific photoDELETE/photos/:iddestroydelete a specific photo모바일 환경에 따라 다른 정보를 보여줘야 한다면?접속하는 환경에 따라 다른 정보를 보여줘야 할 때가 있습니다. 가령 모바일 디바이스에서 볼 때 다른 사용자 인터페이스를 제공한다든지 하는 경우인데요. 일부 애플리케이션은 독립적인 모바일 웹서비스를 개발한 후 단지 이를 이동시켜주기만 할 때가 있는데, 이는 어떤 경우에 좋지 못한 사용성을 보여줍니다. 모바일 뷰와 일반 웹페이지 뷰의 URI가 달라서 같은 정보를 공유할 때 각 환경에 적절한 디자인과 인터페이스로 보이지 않기 때문입니다.모바일에서 블로그를 구경하던 도중, 컴퓨터를 이용하고 있는 친구에게 자신이 보고 있는 내용을 보내주고 싶을 때가 있습니다. 티스토리 블로그는 모바일 뷰의 URI가 기존 URI와 달라서, 친구가 해당 URI를 데스크탑에서 열어도 모바일에 최적화된 정보를 받을 수밖에 없게 됩니다. 이 URI를 데스크탑에서 열어보시기 바랍니다.REST 하게 만든다면 URI는 플랫폼 중립적이어야 하며, 정보를 보여줄 때 여러 플랫폼을 구별해야 한다면 Request Header의 User-Agent 값을 참조하는 것이 좋습니다. 예를 들어 iPhone에서 보내주는 User-Agent 값은 아래와 같습니다.Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3 대부분 브라우저, OS 플랫폼은 HTTP Request를 보낼 시 보내는 주체에 대한 설명을 User-Agent에 상세하게 포함하여 통신하고 있기 때문에 요청자의 환경을 정확히 알 수 있습니다.버전과 정보 포맷을 지정할 수 있게 해야 한다면?오픈 API를 제공하거나, 클라이언트가 항상 최신 버전을 유지할 수 없는 환경이라면 서버에서 버전 협상을 지원해야 합니다. 서버가 버전 협상을 지원한다면 최신 버전으로 업데이트가 되더라도 구 버전의 정보 요청에 하위 호환하게 하여 서비스 적용범위를 넓게 유지할 수 있습니다. 이와 함께 클라이언트가 html로 정보를 받을지, json으로 받을지, xml로 받을지 선택할 수 있다면 더욱 좋을 것입니다.Header의 Accept 헤더를 이용해서 요청 환경에서 정보의 버전과 포맷을 지정할 수 있게 합니다. 아래는 Github API에 요청 시 쓰는 Accept 헤더입니다.application/vnd.github+json vnd.는 Vendor MIME Type으로, 서비스 개발자가 자신의 독자적인 포맷을 규정할 수 있게 HTTP 표준에서 제공하는 접두어입니다. vnd. 이후에 서비스 제공자 이름을 쓴 후, +로 문서의 기본 포맷을 표현해줍니다.이에 더해, Accept 헤더는 파라미터를 받을 수 있습니다. 많은 REST 지지자들은 이 파라미터를 이용해 버전 명을 지정하는 것을 권장합니다.vnd.example-com.foo+json; version=1.0 Ajax와 REST최근 빠른 속도의 웹서비스를 구현하기 위해 서비스 전체를 Ajax 통신으로 구동되게끔 HTML5 애플리케이션을 만드는 일이 많습니다. 서비스 전체를 Ajax 기반으로 구동되게 개발한다면 중복된 콘텐츠를 여러 번 전달하지 않아도 되고, 브라우저 렌더링 과정이 간소화되므로 더욱 빠른 서비스를 구축할 수 있습니다. 하지만 Ajax 기반의 서비스는 초기에 URL에 관련된 문제가 있어 REST한 서비스를 만들 때 애로사항이 있었습니다. 콘텐츠가 바뀌어도 URL은 그대로여서 친구에게 내가 보고 있는 콘텐츠를 보여줄 방법이 불편했기 때문이죠.최근엔 두 가지 방법으로 이를 보완할 수 있습니다. 첫 번째는 #! 기법으로, 구형 브라우저에서도 # 이하의 URL을 Javascript로 자유자재로 변경할 수 있다는 점을 이용한 방법입니다. 방법은 아래와 같습니다.Ajax 통신을 통해 이동되는 페이지의 URI는 현재 URI의 #! 이후에 붙인다.페이지가 처음 열릴 때, #! 이후로 URI가 붙어있다면 해당 URI로 redirect를 해준다.이와 같은 방법으로 Ajax 서비스를 만들면, 페이지를 이동한 이후에 URL을 친구에게 복사해서 전달해주어도 친구가 내가 보고 있는 콘텐츠를 볼 수 있으며, 구글에서 수집할 때 해당 #! 이하의 URL을 판별해서 제대로 수집해주기 때문에 검색엔진에도 성공적으로 노출될 수 있습니다.하지만 위 방법의 단점은 1. 상대방이 Javascript를 지원하지 않는 브라우저를 이용하거나 Javascript 기능을 꺼 놓았을 때 제대로 된 콘텐츠를 볼 수 없다는 것이며, 2. URI가 몹시 보기 지저분해진다는 것입니다. 두 번째 방법은 pushState라는 새로운 표준을 이용한 방법으로, javascript의 pushState를 통해 Ajax 통신 후에 변경된 컨텐츠의 URI을 제대로 바꿔줄 수 있습니다. 하지만 최신 표준을 지원하는 브라우저에서만 정상적으로 구동되기 때문에, 하위 호환에 신경을 써야 한다는 단점이 있습니다. pjax같은 프로젝트들이 하위 호환을 포함하여 이런 구현을 쉽게 하도록 도와주고 있습니다.언어언어별로 다른 URI의 서비스를 가지는 서비스들을 종종 볼 수 있습니다. 역시 좋지 못한 설계입니다. 한국어로 작성된 컨텐츠를 보고 있는 중 해당 콘텐츠를 미국인 친구에게 보여줄 일이 생겼다고 가정해봅시다. 단순히 URI를 복사해서 주는 것으로는 미국인 친구에게 내가 보고 있는 정보를 제대로 전달해줄 수 없다면 아주 불편할 것입니다.Request Header의 Accept-Language는 받고자 하는 언어를 명시하고 있습니다. 대부분 브라우저, OS 플랫폼은 사용자가 즐겨 쓰는 언어를 이 Header에 포함하여 요청을 만들고 있기 때문에, 해당 Header를 참조하여 그에 걸맞은 언어를 제공해주는 것이 가장 정확한 서비스를 제공해줄 수 있습니다.물론 이 방법만으로 부족한 점이 있습니다. 자신의 주 언어와 다른 언어의 세팅을 가지고 서비스를 이용하는 사용자도 있으며, 몇 가지 이유 때문에 해당 사이트만, 해당 순간에만 다른 언어로 정해서 보고 싶을 수 있기 때문입니다. 아쉽게도 일반적인 브라우저에서 언어 변경을 하는 인터페이스는 매우 불편하고 찾기 어렵게 되어있기 때문에, 서비스에서 이에 대한 추가 인터페이스를 제공해주지 않으면 일부 사용자를 잃거나 불편하게 할 수 있습니다. 보통은 Accept-Language보다 우선해서 적용하는 언어 옵션을 세션에 저장할 수 있게 하고, 이에 대한 변경 인터페이스를 서비스에서 제공해주는 식으로 문제를 해결할 수 있습니다.마치며REST는 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화해주고, HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해줍니다. 이번 글에서는 REST하지 않은 서버 설계를 통해 생길 수 있는 실질적인 문제들을 제시하고 REST 아키텍처가 이를 어떻게 해결해주는지 함께 보았습니다.‘REST가 완전한 정답이냐?’라고 한다면 이에 대해서는 아직 논의가 남아있습니다. 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 분명히 있으며 (PUT, DELETE를 사용하지 못하는 점, pushState를 지원하지 않는 점) 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값은 왠지 더 어렵게 느껴지기도 합니다.만일, 만들고 있는 서비스의 API가 널리 쓰여야 한다면 REST를 완전하게 적용한 디자인이 더 독이 될 수 있습니다. 많은 개발자는 별로 똑똑하지 못하며, HTTP 프로토콜에 대한 이해가 부족하여서 API가 어렵게 느껴질 수 있기 때문입니다. 그러므로 Google을 포함한 많은 기업의 서비스 API가 REST 스타일을 완전히 따르고 있진 않습니다.하지만 그럼에도 REST가 중요한 점은, 이를 제대로 구현하는 것이 서비스 디자인에 큰 부가이익을 가져다 줄 수 있으며, 많은 현대의 API들이 REST를 어느 정도로 충실하게 반영하느냐를 고민할 뿐이지 REST를 중심으로 디자인되고 있다는 점은 분명하기 때문입니다. REST를 얼마나 반영할 지는 API가 어떤 개발자를 범위에 두는지, 개발 기간이 얼마나 되는지, 함께 하는 동료의 역량은 어떠한지 등을 고려해서 집단마다 다르게 반영하게 될 것입니다.#스포카 #개발 #개발자 #개발팀 #꿀팁 #인사이트 #REST

경력이 아닌 업력이 되는 단계에 이르러야 가능한 것 아닌가 합니다.대부분의 경력은 '어느 회사의 누구'라는 표현에서 만들어진 것이 아닙니다.진정한 경력의 결과는 '자신의 이름'이 곧 브랜드화 되는 것입니다.매우 당연하게,하루 이틀, 한 두해 한다고 해서 얻어지는 것이 아닙니다."10년 경력!"10년 이상 한 분야나 하나의 도메인, 하나의 테크, 하나의 경력, 하나의 경험을 꾸준하게 파고들었을 때에 얻어지고, 그러는 경험속에서 인사이트, 통찰력이 생기게 됩니다.물론. 그래서, 20대에도 명성을 얻을 수 있는 '경력관리'가 가능하다고 이야기합니다.(실제 얻은 사람을 많이 봤습니다. 그들은 10대에 시작했죠. )회사의 테두리 내에서 얻을 수 있는 '경력'은 '경험'일뿐입니다.자신의 이름을 중심으로 기술할 수 있을 때에 '경력'이라고 이야기할 수 있습니다.개발자라면...글을 써서도 얻을 수 있고,강연을 해서도 얻을 수 있고,GitHub에 오픈소스를 공개하면서도 얻을 수 있습니다.현재 30대와 그 이전의 개발자라면...10대와 20대도 똑같습니다.40대, 50대 이후를 준비하세요.반복적인 일, 똑같은 일, 회사의 프로세스의 하나인 일만 하는 '사람'이라면...그냥, 그 회사의 톱니바퀴가 되는 것입니다.대부분 '경력관리'가 잘 안됩니다.앞으로 50대 이후에도 '브랜드'를 얻을 사람이 되려면...자신의 '경력'관리를 잘 해야 얻을 수 있습니다.나중에 닭 튀기거나 치킨 배달할 것이 아니라면...관리를 잘해야 합니다.경력관리가 가능하려면 어떤 회사를 찾아야 할까요.다음을 기억하세요.1. 구루급 개발자가 있는 회사를 찾으세요.2. 자신이 주도적으로 무언가를 만들 수 있는 권한과 책임을 줄 수 있는 회사를 찾으세요.3. 커뮤니티나 외부 강연, 외부 오픈소스 개발 행사에 적극 참여할 수 있는 기회를 주는 회사를 찾으세요.4. 반복적인 업무와 정체된 마켓에서만 반복적으로 서비스를 하는 회사는 회피하세요.5. 우리 도메인은 원래 이래, 이 일은 원래 이래... 이런 식으로 이야기하는 '상급자'가 있는 회사를 피하세요.6. 쉽게 설명할 수 있도록 준비하고, 리뷰를 할 수 있는 기회와 시간이 주어지는 회사를 찾으세요.그리고, 마지막으로...비전은 누가 주거나 만들어 주지 않습니다.결국, 자기 자신이 찾아야 하는데...이것도, 주변에 이야기가 통하는 '구루급 개발자'가 있어야 그나마 방향성을 찾기 좋습니다.혼자 고민하거나,주변에 비슷한 사람들끼리 고민해봐야 답이 안 나옵니다.꼭, 기억하세요!'구루급 개발자'와 상의하세요.그분들은 실패와 성공, 포기와 단념, 선택과 집중에 대해서 알고 있답니다.퇴근시간이라면..구루급 개발자에게 치맥 한잔 하자고 하세요!