어쩌다, 블로그

[2편] 개발 7년차에서 매니저 3년차로(개발팀 7명에서 33명이 되기까지)

김병규 — Fri, 11 Mar 2022 16:37:23 +0900

들어가면서

[1편]에서 매니저로서 피해야 할 길(절망 편)에 대해서 이야기했다. 2편에서는 반대로 마주하고 나아가야 할 길(희망 편)에 대해서 말해보려 한다. 초보 매니저에게 도움이 되는 글이 되었으면 좋겠다.

마주하고 나아가야 할 길

작은 목소리에 귀 기울이기

매니저가 된 이후 가장 어려웠던 부분은 구성원의 기분과 컨디션을 파악하는 일이었다. 팀원들에게 나의 의견을 강하게 전달하거나 회의에서 구성원과 반대되는 목소리를 내고 난 후에는 하루 종일 회의가 떠오르고 신경 쓰여 편히 쉴 수가 없었다. 구성원의 사기가 꺾이거나 실망하진 않았을지, 더 부드럽게 전달할 수 있는 방법은 없었는지 고민이 고민을 낳아 잠을 이루기 어려운 적도 많았다.(소심함이 문제였을지도...) 매니저로서 의사결정에 확신이 있었더라면 고민이 덜 했을지도 모르겠다. 하지만 나는 주니어 매니저였고 확신에 찬 결정을 할 수 있는 인사이트가 부족했다.
이렇게 잠 못 드는 상황을 피하기 위해 구성원들에게 늘 반대 의견을 내어주길 요청했지만 사실 구성원들이 강한 목소리를 내는 것은 매니저인 나보다 더욱 어려움이 따르는 일이었다. 그래서 나는 구성원에게 강한 목소리를 내어주는 것을 요구하는 것에 앞서 그들이 내어주고 있는 작은 목소리를 듣는 것에 집중했다. 주니어, 그리고 비전공자로서 가지는 고민, 회사 복지 체계에 대한 개선 의견, 장비나 의자와 같은 소모품에 대한 불편함 등 흘러가듯 오가는 말들에 집중하여 피드백을 드렸다. 모든 요청에 대하여 대하여 해결책을 드릴 수는 없었지만, 작은 목소리에도 확실한 피드백을 드리는 것을 통해 구성원들의 의견 표현이 조금씩 늘어갔다. 작지만 분명한 피드백을 통해 활발한 의사소통을 이어간다면 프로덕트에 집중된 다양하고 강한 목소리도 편하게 낼 수 있지 않을까? 작은 목소리에 귀 기울이는것을 시작으로 구성원의 목소리에 집중하여 잠 못 드는 밤(서로의 상심을 걱정때문에)을 줄여가고 있다.

동종 업계의 연봉 시세 확인하기

스타트업처럼 작은 회사는 HR을 위한 전문 부서를 꾸리기 어려울 때가 많다. HR부서가 없는 작은 조직의 경우 연봉협상을 위해 사내 연봉 테이블과 업무성과 평가표에 절대적으로 의존하기보다, 1차 조직장의 리뷰와 회사와 프로덕트의 성과를 바탕으로 연봉협상을 진행하는 경우가 많다. 우리 팀은 여기에 서라운드 리뷰라는 팀 평가기준을 더했지만 정량적인 기준이 되기엔 부족한 면이 있었다. 이런 상황에서 프로덕트의 성장을 위해 함께 달려온 동료와 돈 이야기를 나누고 연봉을 결정해야 하는 것은 초보 매니저에게 여간 어려운 일이 아니었다. (당장 나의 연봉 협상 자리도 어려운걸...)

더군다나 코로나 이슈로 인해 IT인력시장은 뜨겁게 달궈져 있었고 하루가 멀다 하고 "OO기업 신입 연봉 6천만원!", "이직 시 사이닝 보너스 1억 제공!" 등 자극적인 채용가 홍보 쏟아지며 연봉협상의 난이도를 더욱 높였다.

이런 상황에서 구성원의 이탈을 막고, 동기를 부여하면서도 회사까지 수용할 수 있는!! 회사와 구성원 사이에서 최대한의 협상 만족점을 찾아내야 한다는 고민에 빠졌다. 나는 그 고민을 업계 시세에 기반하여 연봉을 협상하는 방법으로 덜어 낼 수 있었다. 헤드헌터로부터 우리 팀원이 제의받은 금액, 초봉 6천이라는 기업의 인재 요구 수준, 이직한 동료가 받는 연봉과 해당 회사의 연봉 밴드, 전 직장 동료들의 재계약 연봉 등 최대한 많은 곳에서 업계 싯가?를 모았고 이를 토대로 구성원과 회사 사이에서 합의점을 찾을 수 있었다. 어렵게 모은 업계 시세정보는 나와 구성원, 그리고 회사에게도 계약 연봉을 가늠할 수 있는 좋은 척도가 되었고 연봉 협상을 조금이나마 가볍게 시작할 수 있는 출발점으로 활용할 수 있었다.

강약약약으로 처세하기 (강자에게 약하고, 약자에게도 약하게)

회사의 정치적 구조를 생각하지 않고 프로덕트에 몰입할 수 있는 것은 스타트업이 가진 큰 매력점이다. 지나친 정치에서 벗어나기 위해 대기업에서 스타트업으로 이직하는 경우도 많다. 하지만 사람이 셋만 모이면 정치가 시작된다고 하지 않던가. 정도의 차이는 있겠지만, 성장하는 회사라면 구성원 간의 관계 복잡도 또한 올라가기 마련이다. 특히 매니저라는 직책은 협의를 통해 결과물을 만들어내는 것이 주요 업무이고, 정치적 구조안에서 풀어 가야 하는 일이 많기 때문에 매니저로서 협업을 위한 중심을 잡는 것이 중요하다.

나는 그 중심을 '정정당당함'에서 찾으려 했다. '강자에게는 강하고 약자에게는 귀를 귀울이는 것'을 정정당당한 것으로 생각했고 이에 맞춰 회사에서도 강강약약의 자세로 협업을 진행했다. 특히 강강에 집중했던 나는 상위 결정권자의 의견을 더욱 엄격한 기준으로 판단했고, 팀원들에게 부끄럽지 않은 결정을 해야 한다는 생각에 몰입했다. 하지만 '정정당당'함을 지키기 위한 노력이 협업에 도움이 되거나 프로덕트의 성장에 긍정적인 영향을 미쳤을까? 아니다. 매니저로서 2년이 지난 지금 돌이켜 보면, 나의 강강약약은 프로덕트와 팀원보다 나의 자존심을 더 잘 지켜내는 방법이었다.

회사는 수익을 내기 위해 협업을 하는 곳이다. 강자에게 강하게 대응한다고 해서 우리의 프로덕트가 눈에 띄게 성장하거나, 우리 팀이 더 편해지지 않는다. 팀과 프로덕트의 성장을 위해서는 강자에게도 약하고 약자에게도 약한 자세를 취해서 최대한 많은 의견을 끌어내고 수렴해서, 발화자의 직책 높낮이에 상관없이 프로덕트만을 위한 결정을 해야 한다. 나보다 직책이 높은 사람의 의견을 따른다고 해서 아부하는 게 아니며, 직책이 낮은 사람의 의견을 반대한다고 해서 군림하는 것이 아님을 늦게 알게 되었다. (정말 집중하고 잘 보이기 위해 노력해야 하는 곳은 유저와 프로덕트였던 것을....) 그때부터 강약약약으로 대응하려 노력하고 있으나 잘 하고있는지 판단하기 위해서는 좀 더 시간이 필요할 것 같다.

개밥 먹기

개밥 먹기란 우리가 개발하고 있는 프로덕트를 일상적인 생활과 업무에서 사용해보는 것을 뜻하는 IT업계 용어다. 이스포츠 플랫폼을 개발하는 우리 팀의 경우 사내 게임대회를 레벨업지지에서 개최해 본다거나, 유저가 만든 대회에 직접 참가하는 것이 개밥을 먹는 것이다.

매니저에게 개밥 먹기는 우리가 만들고 있는 것이 무엇인지 제작자의 관점에서 한발 벗어나서 객관적으로 볼 수 있는 좋은 도구이다. 여러 곳에서 쏟아지는 아이디어를 정리하며, 기능을 구현하고 더하는 것에만 집중하다 보면 우리가 만들고 있는 것이 무엇인지 놓칠 때가 있다. 그럴 때면 개밥 먹기를 통해 우리 프로덕트의 현황을 파악하고 해결해야 할 문제점들을 파악할 수 있다.

그리고 개밥 먹기는 애자일 형태로 개발을 진행하는 조직에게 필수사항으로 업무시간을 들여서라도 진행 하는 것을 추천한다. 무엇을 만들 것인지, 어떻게 만들 것인지, 이번 변경사항이 얼마나 의미있었는지, 어디를 개선해야 할지 등 애자일의 과정 과정마다 좋은 아이디어를 낼 수 있는 원동력을 프로덕트에 대한 이해도로부터 얻을 수 있기 때문이다. 기획자와 디자이너는 물론 개발자와 운영자까지 유저로서 프로덕트를 이해한다면 각자의 파트에서 더욱 의미 있는 역할을 해낼 수 있을 것이라 믿는다.

투명한 정보 공유

매니저 업무를 시작하면서 관리해야 하는 정보의 양이 기존보다 두배 이상 증가했다. 실무자일 때보다 더 많은 회의에 참석했고, 더 많은 의사 결정에 참여함으로써 운영진과 타 부서의 정보도 챙겨야 했다. 매니저로서 얻는 정보를 어디까지 구성원에게 공유해야 할까?라는 물음표가 생겼고, 잦은 결정 변경으로 인한 피로감, 무뎌짐, 실패의식을 느꼈던 과거 실무자로서의 경험을 바탕으로 '확정된 것만 공유하자'라는 판단을 했었다.

하지만 대표님은 반대로 대부분의 정보(심지어 투자 현황까지)를 전 직원에 공유했고, 나의 우려와는 반대로, 정보를 받아들이는 주체였던 구성원들은 성숙하게 정보를 소화해내고 있었다. 빅픽처의 동료들은 나보다 훨씬 더 강하고 성숙한 사람들이었고, 모든 정보를 투명하게 공유하였을 때 실망하거나 걱정하기에 앞서 그들의 사유를 바탕으로 판단하고 있었다. 정보의 제한을 통해 피할 수 있었던 실망과 아쉬움을 감내해야하는 경우도 있었지만, 투명한 정보 공유로부터 오는 고통은 정보를 차단하고 필터링 하는 것으로부터 오는 부작용보다 건강하고 성장의 바탕이 되는 성장통이었다. 앞선 경험을 통해 나 역시 확정된 정보만 공유하는 것에서 모든 정보를 투명하게 공유하는 것으로 자세를 바꾸었다. 정보를 투명하게 공유함으로써 쌓이는 신뢰도는 우리를 더 단단하게 만들어 주었고 정보 공유를 더 편하게 할 수 있는 선순환구조가 자연스럽게 생겨나 매니저로서 정보를 관리해야 하는 어려움을 줄일 수 있었다.

마치면서

[1편]은 하면 안 되는 것들에 대하여 적다 보니 편하게 쓸 수 있었나보다. 이번 편은 해야 하는 것들에 대해 적다 보니 소심함과 조심스러움이 더해져 문장들마다 쉼표가 늘어났다. 이제 막 3년 차에 접어드는 초보 매니저의 글로써 나와 비슷한 길에 올라선 분들께 조금이나마 도움이 되는 글이길 바란다. 다음 회고 때는 조금 더 자신감을 뿜뿜할 수 있기를....!

김병규 (bk@bigpi.co)
새로움과 자유로움을 좋아하는 개발자입니다.
프로덕트의 성장은 구성원의 성장으로부터 온다고 믿습니다.

[1편] 개발 7년차에서 매니저 3년차로(개발팀 7명에서 33명이 되기까지)

김병규 — Fri, 11 Mar 2022 16:35:35 +0900

들어가면서

실무자가 매니저로 넘어가는 길에 도움이 되는 이정표를 작게나마 더하고 싶었다.

개발자로 7년을 일하다 7명을 팀원을 맡게 되고(자기소개의 글), 2년간 팀과 함께 성장하며 33명이 되기까지 경험을 바탕으로 피해서 돌아가야 할 것과 마주하고 정면 돌파해야 하는 것들을 정리해 보았다.

피하고 돌아가야 할 길

비교형 문장

우리 팀은 반기마다 서라운드 리뷰(협업했던 동료를 서로 리뷰하고 평가함)를 진행한다. 팀을 리드하는 입장에서 좀처럼 받기 어려운 동료들의 피드백을 들을 수 있는 소중한 시간이다. 서라운드 리뷰를 통해 나는 "프런트엔드와 백엔드를 비교하며 표현하지 말아 달라."라는 피드백을 받았다. 할 일을 계획하는 부서회의 때 "A라는 기능은 트랜잭션 관리 때문에 프런트엔드 개발보다 백엔드 개발이 중요하다. 일정을 더 많이 잡아 달라"라는 표현을 하였고 이에 대한 피드백으로 주신 말씀이었다. 너무나 맞는 피드백이었고 늘 새기며 일하게 되었다. 업무량과 영향범위는 다를 수 있지만 무엇이 더 중요한 일은 없다. 더 중요하다고 생각되더라도 그것은 개인의 의견일 뿐 모두가 동의할 수 있는 사실은 아니다.
비교하는 표현을 사용하면 부정적으로 표현되는 면이 생기기 마련이다. 매니저가 전체회의에서 하는 말은 영향력이 크기 때문에 비교형 문장은 피하자.

개발 리소스에 등 떠밀리기

스타트업은 언제나 리소스가 부족하다. FE개발자에게 퍼블리싱 작업은 기본이고 데이터 지표 추적 같은 스크립트 추가는 일상이다. 이런 상황에서 새로운 프로젝트를 목표한 기간 안에 완성하기 위해 가장 쉽게 선택할 수 있는 선택지는 개발자 채용이다. (채용 난이도도 높지만 개발자 출신 뉴비 매니저였던 나는 '그 일정으로는 안됩니다'라고 말하고 실망감을 감내하는 것보다 채용을 통해 일정을 맞추는 방향이 좀 더 쉬웠다.)
어려운 채용시장에 맞춰 주니어 역량의 구성원을 채용하고 성장을 유도하며 프로젝트를 완료한 뒤 우리 팀은 디자인/기획 리소스에 비해 개발 리소스가 큰 조직이 되었다.(팀 유지비용이 올라가는 것은 덤이었다.)

이때부터 매니저로서의 나는 '개발자를 놀릴 순 없어!', '개발하지 않으면 재미가 없어져버린다구!'라는 생각을 하며 충분한 고민이 담기지 않은 기획서와 디자인을 요구했고, 유기적으로 돌아가는 팀을 보며 흐뭇해하기까지 했다. 높아진 팀 유지비용을 성과로서 상쇄해야 한다는 조바심이 더해져 상황은 좀처럼 나아질 기미가 없었다.

조바심이 난 매니저는 어떤 행동이든 할 수 있는 무서운 동물이었다. 의욕이 넘치는 초보 매니저로서 회사를 위해 열심히 달리고 목표를 완수하기 위해 최선을 다했을 뿐인데 나는 예측 불가한 추진체가 되어 있었다. 자연스럽게도 개발 리소스에 등이 떠밀리게 되었고 매니저로서 부족한 결정을 하면서 팀과 프로덕트의 성장에 걸림돌을 만들었다.

사용자를 충분히 고려하지 않거나 모두를 만족시키기 위해 복잡한 기능을 설계하고, 유지보수에 사용되는 리소스 예측에 소홀해 매일같이 야근이 이어졌다. 무엇보다 철야하며 구현한 기능들이 유저에게 외면받을 때에는 그 원인을 나에게서 찾지 않고 시장을 탓하곤 했다. 자연스럽고 쉽게 빠져들 수 있는 실수로 인한 등떠밀림의 효과는 강력했고, 그로 인한 결과는 랜덤박스처럼 다방면에서 터져 나왔다. 매니저는 여유롭게 고민하는 시간이 많아야 한다는 조언을 들었을 때 이것은 무슨 소리인가! 했었는데 실수를 거듭하고 난 뒤에야 비싼 값을 치르고 그 의미를 체득하게 되었다. 다시 처음으로 돌아갈 수 있다면 개발 리소스를 늘리기 전에 충분히 고민하고 설계할 수 있는 기획/디자인 리소스 그리고 개발 리소스를 효율적으로 사용할 수 있는 매니저로서의 역량을 먼저 준비할 것이다.

매니징과 실무를 동시에 하기

개발자에서 초보 매니저로 넘어온 나는 의욕이 넘쳤다. 동료들에게 기술역량이 있는 매니저로서 인정받고 싶었고 코드를 작성하는 실무를 통해 증명할 수 있다고 생각했다. 하지만 실무를 통해 구성원의 신뢰를 얻을 수 있었던 기간은 고작 6개월이었던 것 같다. 성장곡선이 너무나 가팔랐던 동료들은 내가 공유했던 기술 레벨 수준을 각자의 분야에서 빠르게 뛰어넘었고 나는 그들이 챙기지 못하거나 리소스 부족으로 담당자가 없는 업무들을 찾아 빈틈을 채우는 정도로 실무를 이어갔다.

물론 실무를 이어가며 매니징을 하는데 문제가 없다면 실무에도 도움이 되는 매니저가 될 수 있었다. 하지만 나는 초보 매니저였고, 새로운 업무에 적응하기 위해 모든 리소스를 사용하여도 부족한 상황인 것이 문제였다. 그로 인해 매니저로서 해야 하는 것들을 놓치는 경우가 많았고, 실무에도 온전히 집중할 수 없어 리팩터링이 필요한 코드들이 쌓여갔다.

매니징과 실무를 동시에 하느라 매일같이 야근하는 매니저, 거기에다 완성도 낮은 코드와 인사이트가 부족한 결정을 내리는 리더와 함께 일하는 동료들은 얼마나 힘이 들지 그때는 미처 생각하지 못했다. 초보 매니저라면 겸업은 피하고 매니저로서의 역할을 먼저 소화해 내는 것이 동료들에게 깊은 신뢰를 얻을 수 있는 길이 아니었을까. 역시나 다시 돌아간다면 매니저로서 역할을 할 수 있도록 온전히 노력을 쏟고 싶다.

K-애자일

스타트업이나 소프트웨어를 개발하는 IT조직에서는 애자일 방법론을 채택하는 경우가 많다.
K-애자일을 논하기 전에 찐 애자일 선언문 먼저 살펴보자.

공정과 도구보다 개인과 상호작용을, 포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을, 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.

Source: YouTube, Making Sense of MVP (Minimum Viable Product), https://youtu.be/0P7nCmln7PM

나는 애자일 선언문을 바탕으로 최소 기능 제품(MVP)을 만드는데 주력하고 유저에 집중하여 완성도를 높여가는(때로는 목적지도 바꾸어가며) 형태로 일하려고 했다(근데 못했다). 지난 2년간 우리 팀은 정말 유저에 집중하고 있었을까? 프로덕트의 완성도를 높여가는데 집중하고 있었을까? 반문해보면 명확히 '아니다'라는 답이 돌아온다. 그러면 내가 추구하고 요구했던 개발 방법론은 무엇이었을까? 그것은 바로 K-애자일이었다 흑ㅠ흑ㅠ

우리가 했던 K-애자일은 이렇게 진행된다.

① 스프린트 결과에 대한 정량적, 정성적 성과를 측정할 수 있는 환경이 없다.

이전 스프린트의 성과를 측정하지 않고서 다음 스프린트를 계획할 수 있을까? 스케이트보드가 제대로 완성되었는지 알기 어려운 상황에서 핸들을 추가한다면 그것은 킥보드로서 동작할 수 있을 것인가? 거듭되는 스프린트마다 행운이 따라야만 우리는 목적지에 다다를 수 있을 것이다.

② 결과물(목적지)은 변경할 수 없으며, 개발 완료 시점이 확정되어있다.

나는 스프린트로 작업해나가는 것을 관철했고 스프린트를 계획하고 종료하는 기준은 배포일이었다. 2주 또는 3주마다 배포일을 지정해두고 배포일에 맞춰 스프린트를 진행했다. 정해진 개발 완료 시점으로 인해 우리 팀은 유저와 기능에 대하여 충분히 고민할 시간은 줄어들고 기획 파트와 개발 파트의 갈등을 야기했다. 기획서 리뷰 시간에 개발자 의견이 더해지면 기획자는 다시 기획서를 업데이트해야 했고, 그만큼 개발할 시간은 줄어들기에 일정을 더 확보해야 했다. (그러나 일정을 추가하지 못하는 것이 K-애자일의 핵심!)

③ 기능 배포 시점을 팀 외부(타 부서, 고객사 등)에서 결정한다.

앞선 ②번의 상황에서 기능의 퀄리티 높이기 위해서는 일정을 조율하고 다시 첫 스탭부터 수정해나가는 과정을 반복해야 한다. 하지만 기능 배포 시점을 우리가 조정할 수 있는 상황이 아니라면? 스프린트를 진행하는 중간에 꼭 개발해야만 하는 기능이 추가된다면? 무엇보다 그것이 전사 관점의 이슈(이것은 몹시 민감하고 예민하다.)가 반영되어있다면, 개발팀은 일정보다 늦게 완성된 기획서에 발맞춰 개발을 해내야만 한다. 이를 통해 우리는 파트 간 볼맨 소리, 퀄리티의 결핍, 우리가 원했던 건 이게 아닌 데와 같은 다양한 부작용을 얻게 된다.

④ ①번부터 ③번까지 과정을 반복한다.

어쩌면 워터폴 방식이 어울렸을 우리 조직에 K-애자일이 자리 잡게 된 것은 애자일에 대한 이해도가 부족한 상태에서 애자일을 해야 한다고 큰소리로 주장했던 매니저(나)가 가장 큰 원인이었다. "한국 기업들에서 행해지는 애자일 방법론은 일을 빠르게 많이 시키기 위한 것이 아니냐"는 글이 커뮤니티에 올라올 때마다 "~~우리는 아니야~~(응 맞아)"라며 현실을 부정하는 내 모습이 늘 함께했다.

다행히도 우리 조직은 얼마 전 애자일을 코치와 스크럼 마스터를 전담해주시는 @김영민 님을 만나게 되어 건강한 애자일 문화를 처음부터 다시 키워나가고 나가고 있다. 곧 건강한 애자일 문화에 대한 블로그를 올릴 수 있을 것 같아, 자조 섞인 K-애자일에 대한 설명은 서둘러 마친다.

Source: YouTube Product Owner in a Nutshell, https://youtu.be/502ILHjX9EE

마치면서

초보 매니저로서 피하고 돌아가야 할 길을 작성하다 보니, 내용이 너무 길어져 버렸다. 아마도 많은 길을 돌아왔기 때문이 아닐까? 매니저로서 역할을 더 잘했다면 피해 갈 수 있었던 길들을 돌아보면서, 어떤 문제든 팀에서 발생하는 문제는 모두 매니저의 책임임을 또 한 번 느낀다. (그렇다면 잘한 것도 모두!? )

피해 가야 할 길에 대해서 글을 쓰다 보니 반성문이 되어버렸다. 잘해온 것도 무척?이나 많기에, 반대로 마주하고 지나가야 할 길에 대해서 페이지를 분리해서 공유할 예정이다. 내가 작성한 글이 나와 비슷한 길에 올라서 있는 분들께 조금이나마 도움이 되고 실수를 덜할 수 있는, 혹은 잘못된 길은 피해 갈 수 있는 단서가 될 수 있으면 좋겠다.

다음 글) 마주하고 지나가야 할 길

작은 목소리에 귀 기울이기
동종 업계 연봉 시세
강약약약
개밥 먹기
투명한 정보 공유

김병규 (bk@bigpi.co)
새로움과 자유로움을 좋아하는 개발자입니다.
프로덕트의 성장은 구성원의 성장으로부터 온다고 믿습니다.

[애자일로 빅픽처를 그리다] 데이터 대시보드 #2

김병규 — Fri, 11 Mar 2022 16:30:13 +0900

들어가면서

지난 데이터 대시보드 1편에서 공유한 데이터 대시보드를 고도화하고 당시 아쉬웠던 부분들(고객군 분리, 유저 획득 경로 상세화, 리소스 데이터 추가)을 보완한 내용을 공유한다. 데이터 대시보드 생성 이후 프로덕트를 담당하는 팀원들의 아이디어가 더해지면서 조금 더 실용적인 지표들이 추가되었다. 정답이 없는 질문에 최선의 답을 구하기 위해, 계속해서 데이터와 결과물을 조정해야 하는 작업이다 보니 소심해지고 , 집단지성 에 기대게 된다. 이 글도 집단지성이라는 호수에 한 방울 보탬이 되기를, 그리고 다음 단계를 제안하고 발전할 수 있는 발판이 될 수 있기를 바란다.

대시보드 추가

기존에 구축했던 데이터 대시보드에는 프로덕트 사용자의 흐름을 전반적으로 살펴보는 AARRR 분석만 존재했다. 동료들에게 AARRR 대시보드를 공유하고 나서, 프로덕트 담당자들이 가지고 있는 개발 스토리에 대한 기능별 대시보드 생성 요청을 받았고 이에 맞춰 3가지 대시보드를 추가했다. 새로운 대시보드를 추가하면서 데이터 구렁텅이에서 방향감각을 잃어 갈 때마다 아래 세 가지 포인트를 기준점으로 다시 정신을 부여잡고 작업을 진행했다. 새롭게 추가한 대시보드들을 소개하며 더불어 대시보드를 통해 개인적으로 얻을 수 있었던 힌트들을 첨언했다.

우리가 무엇을 위해 리소스를 투입하는지 목표에 대한 선명도를 높이자.(목표)
유저에게 전달한 스토리는 목표를 달성했는지 확인할 수 있어야 한다.(결과 측정)
다음 작업에서 우리가 집중해야 할 부분은 무엇인지 힌트를 제공하자.(계획)

유저 랜딩 기능분석 (연관 페이지 : online.gamecoach.pro)
- 목표
  - 신규 수강생 방문자에게 제품의 핵심 가치를 전달한다.
  - 방문자가 CTA버튼 통해 핵심 Task를 수행하도록 유도한다.
- 결과 측정
  - 신규 수강생 페이지 참여도 지표 (참여율, 평균 참여 시간, 스크롤 90%, 기타 세부 이벤트)
  - CTA버튼 클릭률 (CTA 클릭 수 / 첫 방문자 수, CTA 클릭 수 / 세션 수, CTA 클릭 수 / 페이지 방문 수)
- 특이사항 & 힌트
  - CTA버튼 클릭률을 어떤 기준으로 보아야 할 것인지에 대한 고민이 필요하다. 첫 방문자의 CTA 클릭률이 유저 랜딩 페이지의 목적에 가장 적합하고 퍼센트도 가장 높은 상황이지만, 목표한 클릭률을 달성했는지 등의 성공 판단 기준이 추가된다면 다음 단계를 고민하는데 더욱 도움 될 것으로 보인다.
  - 기존 유저의 CTA 버튼 클릭률은 첫 방문자 대비하여 12 ~ 20% 낮은 상황이다. 재방문자에게는 상대적으로 CTA 버튼이 매력적으로 다가가지 못하고 있다. 재방문에게 맞는 CTA버튼이나 기능 등 리텐션과 연계해서 고민해 본다며 개선 목표를 정할 수 있을 것 같다.

CTA 클릭률 지표를 메인으로하는 유저 랜딩 대시보드

코치 추천 기능분석 (연관 페이지 : online.gamecoach.pro/coach-matching)
- 목표
  - 신규 방문자와 코치님의 1:1 채팅 성사율을 높인다.
- 결과 측정
  - 생애 첫 채팅과 일반 채팅 성사에 대한 커스텀 이벤트를 생성하여 분자에 대입하고 첫 발문자 수, 세션 시작 수를 분모로 활용하여 목표 결과를 측정할 수 있는 3가지 핵심 지표를 등록했다.
  - 추천 코치 페이지에서 추천받기 시작부터 추천받기 완료, 추천 코치 카드 선택 등 스탭 별 참여도 지표를 생성하여 유저가 코치를 추천받는 스탭 별 정보를 시각화했다.
- 특이사항 & 힌트
  - 커스텀 이벤트를 만드는 과정에서 이벤트 등록을 누락한 포인트가 있어서 중요 포인트인 `채팅 수` 값이 상당기간 오염되어 있었다. 확인 즉시 수정하였지만 과거 데이터와 비교가 불가하여 아쉬운 점이 있었다.
  - 추천받기 완료율 | 채팅 성사율 | 수강 결제 완료율 세 가지 지표 간에 강한 연관도가 있을 것으로 보인다. 수강률은 프로덕트 최종 목표에 직결되는 분명한 지표지만 수강률 상승까지 복잡한 단계와 설계가 필요하다. 반면 채팅 성사율 | 추천받기 완료율은 접근 단계가 단순하고, 수강률과 강한 연관이 있기 때문에 수강률 상승을 위한 분할 공략지점으로 활용할 수 있을 것으로 보인다.

수강생과 코치의 채팅 성사율을 메인으로하는 추천 코치 대시보드

코치 찾기 기능분석 (연관 페이지 : online.gamecoach.pro/coach-finder)
- 목표
  - 수강생이 코치를 검색하는 행동을 분석한다.
- 결과 측정
  - 수강생이 어떤 코치를 찾는지, 중요하게 보는 이력은 무엇인지 등 유저의 니즈를 파악하는 것은 유저 페르소나를 선정할 때 매우 중요한 부분이다. 코치 찾기 페이지를 오픈 한 뒤 실제 유저가 검색하는 태그와 정렬 등 클릭 위주의 데이터를 수집하여 시각화했다.
- 특이사항 & 힌트
  - 코치를 검색하기 위해 태그를 클릭하거나 우선순위 정렬을 변경하는 등의 액션이 페이지 뷰 대비 10% 이하로 측정되었다. 코치를 검색하고 정렬하는 기능 자체의 사용률이 낮은 것을 바탕으로 수강생이 코치를 검색하기 이전에 검색이 필요한 환경을 마련하는 것이 우선일지 고민해봐야겠다.

코치 찾기에서 유저들이 사용하는 정렬기준 정보들

고객군 분리 & 유저 획득 경로 상세화

대시보드 개선을 위해 유저 타입을 세분화하여 데이터를 필터링할 수 있는 뷰와 유저 획득 경로를 상세화하여 주요 유입 포인트를 필터링할 수 있는 뷰를 제공하려 노력했다. 무엇보다 기능 안정화 이후 본격적인 마케팅을 진행할 예정이어서, 신규 유저의 획득 경로 파악이 꼭 필요한 상황이었다.

먼저 유저 타입을 세분화하기 위해 GA4 연동 스크립트에 userId와 user_properties값을 추가하여 로그인 여부 및 유저 역할(수강생, 코치)을 GA4 보고서의 비교 기준으로 사용할 수 있도록 개선했다. 작업량은 크지 않았은데 레퍼런스가 적고 공유된 자료들은 쇼핑몰 기준이라 온라인 게임코치 서비스 특성에 맞게 커스텀하기에 어려움이 있었다. (결과적으로 GA4 연동 스크립트를 수정하여 대부분 gtag의 'config'기능을 사용하여 세팅했다. 비슷한 작업을 하실 분들을 위해 구글 공식문서를 추천한다.) userId와 user_properties값을 세팅한 이후에는 데이터 비교/필터링 기준으로 로그인 여부와 유저 타입 (코치인지, 학생인지)을 선택할 수 있게 되었고 코치와 유저라는 양 극단에 위치한 유저들의 데이터를 분리하여 확인/비교할 수 있게 되었다.

[개발환경 테스트 지표] 로그인 여부와 user_role을 기준으로 실시간 지표를 비교 할 수 있다.

두 번째로 유저 획득 경로를 상세화 하기 위해 구글 캠페인 URL 빌더를 적극 활용했다. 구글 캠페인 URL 규격에 맞춰 생성한 URL을 통해 유저가 페이지를 방문하면 URL에 세팅한 referrer(source)와 medium, campaign name 등의 데이터를 얻을 수 있다. 이 기능을 이용하여 direct와 not set으로 뭉쳐져 있던 세션 유입 경로를 각 캠페인, 소스 등으로 세분화하여 확인할 수 있게 되었다. (드디어 direct와 not set의 유입 순위를 떨어뜨렸다. )

획득한 트래픽 차트에서 기존에 최상위었던 referral, direct, not set이 하위로 내려간 모습

앞서 설정한 두 가지 작업을 바탕으로 데이터 대시보드에서도 필터링을 쉽게 적용할 수 있었다. 이제 모든 대시보드에서 로그인 여부와 캠페인을 기준으로 데이터를 확인할 수 있다. 예를 들면 페이스북 캠페인으로 얻은 유저들의 지표와 틱톡 캠페인으로 얻은 유저들의 지표들을 디테일하게 비교하여 우리가 집중해야 할 매체들을 찾을 수 있게 된 것이다.

새롭게 추가된 데이터 데시보드 필터 옵션

구글 데이터 대시보드에 새로운 데이터 소스 추가

프로덕트 매니저가 요구하는 지표들을 GA4와 데이터 대시보드가 제공하는 기본적인 기능으로 표현하기 어려울 때가 많다. 이를 극복하기 위해 gtag를 이용하여 커스텀 이벤트를 만들어 대응하고 있지만 부족함을 느끼고 있다. 예를 들어 `게임코치 온라인 유료 포인트를 가지고 있는 유저` 필터 옵션이나 `특정 이벤트를 기준 페이지별 발생 횟수`같은 지표를 구현하기 어렵다. 이를 극복하기 위해 Google BigQuery와 게임코치 온라인 DB를 대시보드의 데이터 소스로 추가하는 작업을 진행했다.

Google BigQuery
- BigQuery는 대규모 데이터 세트에 대해서 쿼리를 신속하게 처리할 수 있는 클라우드 데이터 웨어하우스로 GA4에서 축적한 데이터를 기반으로 SQL과 유사한 구문을 사용하여 조회할 수 있는 기능 제공한다. 기존에 UA 버전에서의 GA에서는 BigQuery와 연결하는 BigQuery connector가 유료버전에만 포함되어 있었는데 GA4버전부터는 무료로 변경되어 손쉽게 사용할 수 있게 되었다. (BigQuery 자체는 유료이지만 무료 플랜으로도 충분히 사용 가능함)
- Google BigQuery로 GA4 데이터를 들여다보니 모든 데이터는 이벤트 형태로 저장하고 있어서, 이벤트 발생 시 함께 저장한 상세 데이터(이벤트 발생 위치, 유저 식별자, 이벤트 벨류 등)를 기준으로 검색하거나 그룹화할 수 있었다. 덕분에 프로덕트 매니저가 요구하는 다양한 이벤트 기반 지표들(채팅 이벤트가 어떤 위치에서 얼마나 발생하는지 등)을 시각화할 수 있었다. (GA4를 조회하는 빅쿼리를 시작한다면 구글 공식 문서를 강추한다.)
게임코치 온라인 데이터베이스
- 구글 데이터 대시보드는 MSSQL, MYSQL 등 다양한 데이터베이스를 데이터 소스로 사용할 수 있게 도와주는 커넥터를 지원한다. 또한 데이터 소스들을 연결하는 JOIN 기능을 지원하기 때문에 GA에서 수집한 유저 정보에 기반하여 데이터베이스 정보를 더해 확장하면 강력한 분석 환경을 제공할 수 있다.
  하지만 구글 데이터 대시보드에 우리 게임코치 온라인의 데이터베이스 접근권한을 부여하는 것은 보안상 위험할 뿐만 아니라 법적으로도 검토가 필요한 민감한 사항이기 때문에 연동을 진행하지 않고 내부망에 구성된 별도의 분석 툴을 이용하는 것으로 결정했다. 서비스 DB와 연계가 필요한 지표 요청이 계속되고 있기 때문에 민감한 정보를 조회할 수 없는 DB 엔드포인트를 별도로 준비하여 연결하는 방법을 백엔드 팀장님과 함께 계속 고민하고 있다.

A/B테스트 환경 추가

최근 12주간 축적해온 개발 내용을 프로덕션에 반영하고 게임코치 메인 페이지는 명확한 CTA 버튼을 노출하고 있다. 페이지의 목표가 명확해지고 예산을 사용하여 마케팅을 진행하려다 보니 A/B테스트에 대한 니즈가 생겼고 해결안으로 Google Optimize를 선택했다. Optimize는 사용하게 된 이유로 몇 가지 장점이 있는데 실제 사용해본 경험을 바탕으로 소개한다.

GA4와의 연동
- Optimize의 가장 큰 장점은 A/B테스트에서 가장 중요한 각 대안별 효과 측정을 GA4 데이터에 기반하여 자동으로 생성해주는 부분이다. 특히 A/B테스트를 생성할 때 테스트의 목적을 선택할 수 있으며, GA4에서 설정해둔 전환 이벤트를 선택할 수 있고, 부가적인 목표도 차순위 이벤트를 선택할 수 있기 때문에 A/B테스트 목적을 GA4와 일원화하고, 결과를 분석하는 뷰를 목적에 맞게 별도로 생성하는 수고를 덜 수 있다.
코드 수정이 필요 없는 대안 생성 툴
- Optimize에서는 A/B테스트를 진행할 대안을 생성하는 툴을 제공한다. 개발자가 아니더라도 클릭만으로 새로운 대안을 추가할 수 있으며 코드 상의 변화도 없기 때문에 배포나 개발팀 도움 없이 대안을 관리할 수 있다. (레이아웃을 변경하거나 노출 순서를 변경하는 등 매우 강력한 기능을 제공하는 것을 보고 감탄만... )
- 만약 서비스 프런트엔드를 Vue나 React를 이용하여 SSR형태로 개발했다면, 서버에서 랜더링 한 화면과 프론트에서 랜더링 한 화면이 다르기 때문에 hydration error가 발생할 수 있다. 이 경우 client에서만 렌더링 되도록 예전에 종선 개발자님이 공유한 client-only 컴포넌트와 같은 방법을 적용하면 해결할 수 있다.

Optimize에서 새로운 대안을 수정하는 중&amp;amp;amp;amp;amp;amp;nbsp;

데이터 대시보드를 구축하면서 어려웠던 부분

프로덕트 매니저가 필요한 데이터와 지표는 자연어 형태로 전달된다. 그리고 이런 요청들은 GA4, BigQuery, 데이터 대시보드, Optimize 등 앞서 소개한 데이터 소스와 툴들이 이해할 수 있는 문맥으로 변환되어야 한다. 데이터 지표를 만드는 과정 초반에는 툴들을 세팅하고 데이터 정합성을 맞추는 것이 어려웠지만, 현재는 매니저 분들의 자연어를 최대한 빈틈없이 기계어로 바꾸는 과정이 가장 어렵고 결과 만족도를 얻기 어려운 상황이다. 지표 생성을 요청 주시는 분들이 데이터 분석 환경과 친해진다면, 그리고 나의 번역 스킬을 높여 간다면 이런 어려움을 극복할 수 있다고 생각한다.(그래서 블로그도 열심히!✍) 울퉁불퉁 어려움 많은 비포장 도로 위에서 프로덕트 매니저와 협업하며 자연어를 기계어?로 번역한 예시를 첨부한다.

자연어 - '1월 15일을 기준으로, 기존 서비스 이용자가 아니었던 사람들의 데이터를 분리해주세요.'
- '서비스 이용자'라는 기준을 페이지 방문 여부로 결정할 것인지, 전환 이벤트 발생자로 잡을 것인지, 구매를 완료한 수강생으로 잡을 것인지에 대한 논의가 필요하고 데이터 요청자와 콘텍스트를 맞추어야만 결과 지표를 바라보는 시점도 맞출 수 있다.
- '1월 15일'이라는 기준을 충족하려면 앞서 논의한 '서비스 이용자'의 기준에 날짜 개념을 적용할 수 있어야 한다. GA4에서 날짜 기반으로 필터링 하기 애매한 것들이 있다. 예를 들어 '서비스 방문', '페이지 조회'를 기반으로 필터링하면 1년 전에 서비스를 마지막으로 방문한 유저가 재방문했을 경우 신규 방문자 속성을 가진 '기존' 방문자 이기 때문에 결과 분석 시 이런 예외 케이스에 대한 고려가 필요해진다.
- 이런 상황에서 프로젝트 매니저와 '서비스 이용자', '기간'에 대한 논의(개발자의 애원이었을 지도.. ‍ )를 진행하고, 다른 예시 대시보드 참고하여 GA4 전환 이벤트 중 하나인 '구매자'를 기존 서비스 이용자로 구분자로 활용하고 데이터 대시보드 조회 기간을 수동으로 선택하여 '기존'이라는 조건은 적용하는 것으로 기계어 번역을 마쳤다. (프로젝트 매니저의 요구사항을 깔끔하게 구현하지 못한 것과 불완전할 수 있는 지표로 인해 번역 품질 만족도가 걱정된다. 어렵고 개선이 필요한 부분이다.)

다음 단계

지금까지 우리 서비스에서 발생하는 데이터를 수집하고, 팀원 모두 간편하게 확인할 수 있는 기반을 다졌다. 지금부터는 '제품 구매'라는 최종 목표로 더 정확하게 나아갈 수 있는 '중간 목표'를 만들어 데이터 대시보드의 실용성을 높이고 싶다. 예를 들면 스트리밍 서비스의 경우 수익이 발생하는 최종 목표가 '도네이션' 또는 '광고 등록'일 때, 최종 목표에 도달한 유저가 공통적으로 가지고 있는 이벤트를 분석하여 '중간 목표'를 '스트리밍 5분 신청'으로 찾아낼 수 있다. 반대로 '스트리밍 5분 지속 시청 여부'를 기준으로 유저를 분리하고 두 집단의 전환율을 비교하여 1차적으로 가설을 증명해 볼 수도 있다. 만약 '스트리밍 5분 지속 시청'이라는 이벤트가 전환율에 중요한 영향을 미친다면 이것을 '중간 목표'로 잡고 '최종 목표'보다 좀 더 명료한 계획과 실행, 증명을 할 수 있을 것이다.

우리 서비스인 게임을 1:1로 강의하는 게임코치 온라인의 경우 '제품 구매'를 최종 목표로, '코치와 1:1 대화'를 중간 목표로 잡아 볼 수 있다. 하지만 이런 생각을 상상과 가설에 기반하지 않고 데이터에 기반하여 중간 목표 설정이 타당한지, 최종 목표에는 얼마나 영향을 미치는지, 우리의 작업이 중간 목표 달성률을 올렸는지 등을 데이터에 기반하여 판단해야만 한다. 다음 단계로 '중간 지표'를 찾고, 이를 통해 '최종 목표'에 긍정적인 영향을 미칠 수 있는 대시보드 실용성 향상에 집중해 보겠다. 조만간 즐거운 마음으로 데이터 대시보드 3편을 쓸 수 있기를 바라본다.

김병규 (bk@bigpi.co)
새로움과 자유로움을 좋아하는 개발자입니다.
프로덕트의 성장은 구성원의 성장으로부터 온다고 믿습니다.

[애자일로 빅픽처를 그리다] 데이터 대시보드 feat. GA4

김병규 — Fri, 11 Mar 2022 16:27:34 +0900

들어가면서

우리는 게임코치온라인(https://online.gamecoach.pro/) 서비스를 애자일 하게 개발하고 있다. 애자일의 가치와 효과를 경험하면서 목적지를 향해 (애자일 코치님의 팀 건강 검진 결과에 따르면 ) 즐겁게 항해하고 있으며 K-애자일로 변질되지 않도록 부단히 노력하고 있다. 애자일은 함께 일하기 위한 관점으로써 우리가 무엇을-어떻게 만들어야 할지 안내하는 눈이 되어준다. 우리의 시야를 더욱 분명하게 개선하기 위한 노력 중 하나로 데이터 대시보드를 만들고 있으며, 현재까지의 과정을 공유한다.

애자일을 위한 데이터 대시보드?

스타트업은 모호함을 명확함으로 바꿔가는 과정이라고 생각한다.(by 모호좌 ‍ ) 우리는 끊임없이 무엇을 할 수 있는지, 언제까지 할 수 있는지에 대한 물음에 대답을 해야 하며, 결과물을 통해 어떤 성과를 얻을 수 있을지(또한 무엇을 얻었는지) 예측할 수 있어야 한다. 애자일 하다는 것은 어쩌면 이러한 질문들에 조금 더 정확한 대답을 찾기 위해 노력한다는 것일 수 있겠다. 하지만 완벽한 애자일 방법론이 완벽한 답변을 만들 수는 없다. 앞서 말했듯 애자일은 모호함을 선명하게 보기 위한 관점이기 때문이다. 우리는 선명한 시야를 가지고 서비스에 맞는 정답을 향해 나아가야만 정답에 가까워질 수 있다.

애자일을 위한 데이터는 우리 관점의 정확함을 검사할 수 있는 시력검사표 역할을 한다. 그것은 서비스가 현재 위치하는 곳을 제대로 파악하고, 우리가 예측했던 것이 얼마나 정확했는지 혹은 얼마나 틀렸는지를 바라볼 수 있는 검사 지표로써 동작할 것이다. 매번 돌아오는 스프린트의 성과를 측정하지 않으면서, 좋은 서비스로 나아가는 것을 기대한다면 복권 당첨을 기대하는 것과 다를 바 없다. 스케이트 보드의 바퀴가 제대로 굴러가지 않는 걸 모른 채 핸들을 추가한다면 그것은 킥보드로써 역할을 할 수 있을까?

애자일을 위한 여정에 동참하고, 지속적인 물음에 대답하기 위해 데이터 대시보드를 만들고 있다. 현재까지 구성한 대시보드는 다음과 같은 목표를 가지고 있다.

팀의 모든 구성원이 쉽게 확인할 수 있어야 한다.
데이터에 기반하여 아이디어를 구현할 수 있는 틀을 제공 해야 한다.
기능 추가/변경 시점을 기준으로 우리가 의도한 바를 달성하였는지 확인할 수 있어야 한다.
설계자의 질문에 대답할 수 있어야 한다. ex) 특정 기능 사용률, 수정한 기능에서의 구매 전환 변동률 등

기존 데이터 대시보드의 아쉬웠던 부분

레벨업지지 플랫폼을 개발하기 위해 Google 애널리틱스(이하 GA)와 아파치 제플린(디자인 툴 Zeplin 과는 다름)을 이용한 데이터 대시보드를 이용하고 있었다. 아파치 제플린을 이용하여 데이터베이스와 로그 저장소에 있는 데이터를 상세하게 조회할 수 있고 GA를 통해 웹에서 발생하는 이벤트들을 파악할 수 있지만 애자일 측면에서 몇 가지 아쉬운 부분이 있었다.

대시보드로써 스토리가 부재하다.

데이터 대시보드는 표현하고자 하는 스토리가 분명해야 설득력 있게 데이터를 전달할 수 있다. 하지만 제플린으로 구성한 대시보드는 기능별(유저 사용성이 아닌)로만 대시보드가 분리되어있어 지표들 간의 상호관계가 없다.
아파치 제플린으로 구현된 데이터 대시보드는 근엄하고 위압감이 느껴진다. 개발자에게는 각종 테이블에서 뿜어내는 숫자들과 실시간으로 업데이트되는 데이터들이 다정하게 다가갈 수 있지만, 서비스를 운영하고 기획하는 분들에게는 대화를 거부하는 답정너 대시보드처럼 보일 수 있다.

apache zeppelin 예시화면

유저와 서비스 간의 상호작용을 확인하기 어렵고, 특정 시점 기준으로 데이터를 비교하기 어렵다.

GA로 유저 이벤트를 수집하고 있었으나 이를 들여다볼 커스텀 보고서가 없었기에 이벤트 발생 빈도, 종류 등 단편적인 정보만 확인하고 있었다. 또한 커스텀 보고서를 이용하더라도 GA를 이용해서 확인할 수 있는 이벤트 상세 정보 (이벤트 벨류, 이벤트 로케이션 등)를 파악하기 어려운 문제점이 있다.

제플린으로 표현하는 차트들은 기간을 기준으로 비교하기 어렵다. (GA에서는 최근 2주에 대한 데이터를 조회하면 자동으로 과거 4~3주 차의 데이터와 비교해서 지표 증감률을 표현해준다.)

새롭게 추가된 데이터 대시보드

게임코치 온라인 서비스를 개발하는 팀원 전체가 이해하기 쉽고 친근하게 다가갈 수 있는 대시보드 형태가 무엇일까 고민하다 AARRR 해적 지표를 구글 데이터 스튜디오로 구현하는 것을 목표로 첫 번째 대시보드를 만들었다. 우리 서비스의 현재 상황을 파악할 수 있고 개선해야 할 포인트를 드러내서 새로운 아이디어를 유도할 수 있는 지표라고 생각했기 때문이다. 두 번째로 특정 기능에 집중하지 않고, 유저 스토리를 기준으로 데이터를 표현하는 대시보드를 추가했다. 예를 들면 '코치 찾기 스토리' 대시보드의 경우 '유저들은 어떤 추천 태그를 많이 클릭하는가?', '유저들은 어떤 정렬을 많이 적용하는가?', '유저들은 코치 찾기 페이지를 얼마나 탐색하는가?'에 대한 기획자의 질문에 대답할 수 있는 데이터를 중심으로 시각화해서 데이터 가독성을 높이는데 집중한 것이다.

AARRR FUNNEL 대시보드

서비스를 이용하는 유저의 획득부터 수익, 레퍼럴까지 FUNNEL(깔때기) 형태로 데이터를 표현하여 위에서부터 아래로 데이터를 읽어 갈 수 있도록 구성했다. 데이터를 읽어가는 방향을 제공한다는 점에서, 기존에 사용 중인 GA 보고서와 제플린의 차트와 가장 대비되는 부분이다.

대시보드 구성을 위한 데이터 소스로 GA4(새로운 버전의 GA로 빅쿼리를 무료버전에서도 사용할 수 있다.)와 GA3(GA4 이전 버전인 UA 버전), Google BigQuery를 모두 사용하여 GA에 친숙하지 않은 사용자도 배포일 기준으로 방문자나 전환(수익)이 얼마나 발생했는지 쉽게 확인할 수 있다.

AARRR 대시보드를 통해서 우리가 집중해야 하는 부분을 파악할 수 있고 "새로운 기능 A는 무엇을 개선하기 위함인가?", "이번에 배포된 기능 B는 우리가 개선하고자 했던 목표를 달성했는가?" 등 팀원들의 질문에 대답할 수 있다. 그리고 데이터에 기반하여 지나간 스프린트를 회고하고 우리가 했던 예측과 대답들이 얼마나 정확했는지 판단할 수 있기 때문에 우리 대답의 정답률을 높이는데 도움이 될 것이다.

게임코치온라인 개발환경 AARRR 대시보드

코치 찾기 페이지 대시보드

스프린트 리뷰&회고 시간을 통해 AARRR대시보드를 팀에 공유 한 뒤, 서비스 전체 관점이 아닌 에픽이나 유저 스토리 기준의 대시보드의 필요성에 대해서 대화를 나누었다.
우리는 에픽이나 스토리의 성과를 측정할 수 있는 지표를 데이터 기반으로 설정하여 무엇이 목표인지 분명히 하고자 했다. 또한 유저 스토리 적용 전부터 부재되어있던 데이터를 미리 쌓아 기능 배포 이전과 이후를 비교할 수 있는 환경을 구축하고자 했다. (스토리 적용 전/후 비교를 통해 에픽의 성공 여부와 개선점을 다시 찾을 수 있기 때문에)
그래서 에픽을 작성하는 단계에서부터 에픽의 목적과 효과를 데이터에 기반하여 설정하였고, 유저에게 개발 내용이 전달되었을 때 변화를 측정할 수 있도록 데이터 수집 요청 일감을 스토리 개발과 같은 스프린트에 추가하여 데이터 대시보드 구성을 하나의 업무로서 진행하게 되었다.
에픽이나 유저 스토리 기반의 데이터 대시보드는 유저의 클릭, 스크롤 상황 등 DB에 저장하지 않는 단순한 유저 상호작용을 모아 메인 데이터로 사용한다.
그렇기 때문에 GA4, GA3(UA버전)을 데이터 소스로 만들었던 AARRR대시보드와는 달리 GA4로 수집하고 있는 유저 이벤트를 좀 더 상세히 분석해야만 했고 GA4를 연동한 구글 BigQuery를 데이터 소스로 추가하였다. GA4 <-> BigQuery를 이용하면 이벤트의 상세 내용까지 추출할 수 있고, 데이터 요청자의 질문에 더 상세하게 대답할 수 있게 때문에 데이터 대시보드를 구축하는데 큰 도움이 되었다.

게임코치 온라인 개발환경 코치찾기 대시보드

앞으로 개선이 필요한 부분

애자일을 위한 데이터 대시보드를 공개하고, 다양한 의견들이 더해지면서 개선이 필요한 부분들을 찾을 수 있었다. 수강 유저와 코칭 유저로 고객군을 분리하는 것, GA 유저 획득 소스가 not set과 direct 부분을 분석하는 것 등 공감되는 부분이 많았다. 의견들을 반영하여 대시보드를 개선하기 위해 다음과 같은 작업을 진행할 계획이다.

GA 수집 데이터 상세화

고객군 분리: 게임코치 온라인은 코치님과 수강생을 연결하는 서비스를 제공하기 때문에, 고객군을 수강 유저와 코칭 유저로 나눌 수 있다. 두 개의 고객군에게 제공하는 서비스와 집중해야 할 데이터가 다르기 때문에 대시보드도 분리하여 볼 수 있는 기능이 필요하다.

유저 획득 들여다보기: GA특성상 많은 유저 획득이 not set이나, direct로 집계된다. AARRR대시보드의 분석 첫 단계로 획득 단계가 구체화될수록 기초를 단단하게 할 수 있을 것이다. 유저 획득을 상세화하고 구분하는 것은 GA를 사용하는 많은 팀들이 같이 고민하는 이슈로 UTM, 뷰저블 등 다양한 방법을 이용하여 not set과 direct를 줄여보려 한다.

대시보드 데이터 리소스 추가 & 연결(Join)

코칭 서비스의 친구 초대 이벤트를 상세 추적하거나, 프로모션에 투입된 비용 대비 유적 획득 비용을 계산하는 대시보드를 작업하기 위해서는 GA와 서비스 DB, 광고 비용 정보 등 다양한 데이터 리소스를 연결(Join) 해서 보아야 한다. 예를 들어 GA에서 추적한 데이터와 코칭 서비스 DB를 연결하여 대시보드를 구성한다면 구매 유저의 수강 횟수나, 잔여 포인트 현황 등을 함께 볼 수 있어 좀 더 리더블한 대시보드를 만들 수 있을 것이다.

마무리

우리는 더 좋은 서비스를 만들기 위해 애자일 하게 일하고 있다. 지속적으로 쌓아온 데이터를 분석하여 예측을 하고 유저와 상호작용을 분석하여 예측 결과를 평가한다. 그리고 더 나은 예측을 기대한다. 좋은 서비스를 만드는 것은 서비스를 만드는 사람들의 공통적인 목표일 것이다. (애자일 방법론을 떠나서라도) 팀에서 활용하고 있는 데이터에 스토리를 더하고 더 나은 예측을 위한 노력은 좋은 서비스를 만드는데 도움이 될 것이라 믿는다. 계속해서 발전시켜나갈 데이터 대시보드가 더 좋은 제품을 위한 우리 팀의 노력에 보탬이 될 수 있으면 좋겠다.

김병규 (bk@bigpi.co)
새로움과 자유로움을 좋아하는 개발자입니다.
프로덕트의 성장은 구성원의 성장으로부터 온다고 믿습니다.

Spring Batch 와 Jekins 를 이용하여 간단한 배치 환경 구성하기

김병규 — Wed, 13 Feb 2019 14:28:22 +0900

개요

2분 마다 시총 상위 100개 코인에 대한 가격정보를 크롤링하려 한다.
크롤링을 위해서는 Batch Job 과 Scheduler가 필요한데, 어떤 환경으로 구성할까 고민하다 Batch Job은 Spring Batch로 Scheduler는 Jekins로 구성했다.

Spring Batch를 쓴 이유

1. Spring boot를 사용중이라 기존에 만들어둔 Service를 재사용할 수 있다.
2. Transaction, Datasouce 관리가 편하다.
3. 익숙한 환경 (Java, RestTemplate, Error handling 등등)

Jekins를 쓴 이유

1. GUI 환경 Batch Job 관리가 편리하다. (상태확인, 실행 주기 관리, 로그 확인 등등)
2. Jenkins에서 Jar 형태의 Batch Job Application 을 직접 실행할 경우, 로그 확인이 편리

문제점

Q Spring Batch 를 단순 크롤링 작업으로만 사용하기에는 오버스팩!
A 오버스팩인것은 맞다. 하지만 구현 속도는 가장 빠르다.

Q Spring Batch 는 Database Table로 Job을 관리하는데 Jekins로 실행한다고?
A Database Table를 이용하지 않고, In - Memory 에서 작동하도록 설정했다.

Q Batch Application를 이중화 하려면?
A 이중화가 불가능한 문제다. 다만, 배포를 위한 중단시간이 제로에 가깝고, 잡을 분리하는 등 운영방식으로 해결할 수 있다.

구현

1. 스프링 배치 설정

Spring Batch 의존성 추가 (Spring boot 2.1 기준)

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-batch</artifactId>
</dependency>

Batch Config, Batch Job 생성
(InMemoryBatchConfigurer는 따로 생성했다.)

@Configuration
@EnableBatchProcessing
public class BatchJobConfig {

    @Autowired
    JobBuilderFactory jobBuilderFactory;
    @Autowired
    StepBuilderFactory stepBuilderFactory;

    @Bean
    public BatchConfigurer batchConfigurer() {
        return new InMemoryBatchConfigurer();
    }

    @Autowired
    private UpdateTop100CoinPriceTasklet updateTop100CoinPriceTasklet;

    @Bean
    public PlatformTransactionManager transactionManager() {
        return new ResourcelessTransactionManager();
    }

    @Bean
    public Job updateTop100CoinPriceJob() {
        return jobBuilderFactory.get("updateTop100CoinPrice")
            .start(updateTop100CoinPrice())
            .build();
    }

    @Bean
    public Step updateTop100CoinPrice() {
        return stepBuilderFactory.get("updateTop100CoinPrice")
            .tasklet(updateTop100CoinPriceTasklet)
            .build();
    }
}

Batch Tasklet 생성
Tasklet과 InitializingBean을 구현하면 된고 RepeatStatus를 통해 Tasklet 반복여부를 선택할 수 있다.
Tasklet에서 실행시킬 로직은 기존 Service Bean 주입을 통해 해결할 수 있어서 편

@Component
public class UpdateTop100CoinPriceTasklet implements Tasklet, InitializingBean {

    @Autowired
    MarketCapService marketCapService;

    @Override
    public RepeatStatus execute(StepContribution contribution, ChunkContext chunkContext) throws Exception {
        marketCapService.updateTop100CoinPrice();
        return RepeatStatus.FINISHED;
    }

    @Override
    public void afterPropertiesSet() throws Exception {

    }
}

In - Memory Batch Configurer 설정
Database Table로 Job을 관리하면 여러모로 신경써야할게 많다. 단순한 목적에 맞게 Memory에서 관리하자.

public class InMemoryBatchConfigurer implements BatchConfigurer {

    private PlatformTransactionManager transactionManager;
    private JobRepository jobRepository;
    private JobLauncher jobLauncher;
    private JobExplorer jobExplorer;

    @Override
    public PlatformTransactionManager getTransactionManager() {
        return transactionManager;
    }

    @Override
    public JobRepository getJobRepository() {
        return jobRepository;
    }

    @Override
    public JobLauncher getJobLauncher() {
        return jobLauncher;
    }

    @Override
    public JobExplorer getJobExplorer() {
        return jobExplorer;
    }

    @PostConstruct
    public void initialize() {
        if (this.transactionManager == null) {
            this.transactionManager = new ResourcelessTransactionManager();
        }
        try {
            MapJobRepositoryFactoryBean jobRepositoryFactoryBean = 
                new MapJobRepositoryFactoryBean(this.transactionManager);
            jobRepositoryFactoryBean.afterPropertiesSet();
            this.jobRepository = jobRepositoryFactoryBean.getObject();

            MapJobExplorerFactoryBean jobExplorerFactoryBean = 
                new MapJobExplorerFactoryBean(jobRepositoryFactoryBean);
            jobExplorerFactoryBean.afterPropertiesSet();
            this.jobExplorer = jobExplorerFactoryBean.getObject();

            SimpleJobLauncher jobLauncher = new SimpleJobLauncher();
            jobLauncher.setJobRepository(jobRepository);
            jobLauncher.afterPropertiesSet();
            this.jobLauncher = jobLauncher;
        } catch (Exception e) {
            throw new BatchConfigurationException(e);
        }
    }
}

2. Application 실행환경 설정

Application Type을 WEB에서 NONE으로 변경했다. 이제 포트를 찾지 않아도 되어서 여러 Job들을 실행할 수 있다. (프로세스 생성비용은 늘어나지만..)
Spring Batch CommandLineJobRunner 를 사용할까 하다가, 어렵고 과한것 같아서 Application 실행 변수로 Batch Job 명을 전달 받아 실행하는 방식으로 세팅했다.

@Slf4j
@SpringBootApplication(exclude = {
    DataSourceAutoConfiguration.class,
    DataSourceTransactionManagerAutoConfiguration.class,
    HibernateJpaAutoConfiguration.class
})
@EnableAsync
@EnableScheduling
@EnableCaching
@EnableTransactionManagement(proxyTargetClass = true)
@EnableJpaRepositories(basePackages = "com.happy.life")
public class BatchApplication {

    public static void main(String[] args)
        throws JobParametersInvalidException, JobExecutionAlreadyRunningException, 
        JobRestartException, JobInstanceAlreadyCompleteException {

        SpringApplication app = new SpringApplication(BatchApplication.class);
        app.setWebApplicationType(WebApplicationType.NONE);
        ConfigurableApplicationContext ctx = app.run(args);
        JobLauncher jobLauncher = ctx.getBean(JobLauncher.class);

        if (args.length > 0) {
            Job job = ctx.getBean(args[0], Job.class);
            jobLauncher.run(job, new JobParameters());
        } else {
            log.error("배치 잡 이름을 입력해 주세요. EX) {}", "java -jar app.jar updateTop100CoinPriceJob");
        }

        System.exit(0);
    }
}

3. 젠킨스 설정

젠킨스를 설치하고 깃헙 연동하는 과정은 생략한다.

배포하기

젠킨스에서 Freestyle project를 하나 만들어서 Batch Application을 배포하자.
Github에서 소스를 받아와 maven build하는 기본 빌드 이후에 jar를 복사한다. yes|cp -rf 옵션을 줘서 항상 덮어쓰기 하도록한다.
이렇게 하면 순단없이 아주 빠르게 배포? 한다고 말할 수 있지않을까? 호호호호

실행하기

배포한 jar를 실행한다. Jenkins의 Build periodically값을 조정해서 2분만다 실행하도록 한다.
그리고 Execute shell 에서 Java -jar 옵션으로 배치를 실행한다.

결과 확인

Job에서 뱉어내는 로그들을 잘 기록하면서 수행된 것을 확인할 수 있다. 오예 끝~!

결론

Spring Batch가 소잡는 칼이라 닭을 더 쉽게 잡을 수 있다.

Spring batch의 transaction manager bean 중복 문제 해결하기 (feat Spring boot 2.1)

김병규 — Tue, 12 Feb 2019 20:34:46 +0900

문제

Spring Batch를 사용하기 위해 Maven 의존성을 추가하고, BatchConfig.java를 설정을 완료했다.
그리고 배치를 시작하는 순간 transactionManager bean이 중복선언 되었다는 에러를 마주했다.
배치에서 새로 생성한 transactionManager 때문에, 기존 프로젝트에서 사용하던 기존의 transacrionManager bean을 등록할 수 없다는 이유였다.

@Configuration
@EnableBatchProcessing
public class BatchJobConfig {

    @Autowired
    JobBuilderFactory jobBuilderFactory;
    @Autowired
    StepBuilderFactory stepBuilderFactory;

    @Bean
    public Job updateSomethingJob() {
        return jobBuilderFactory.get("updateSomethingJob")
            .start(somethingStep1())
            .build();
    }

    @Bean
    public Step somethingStep1() {
        return stepBuilderFactory.get("updateSomethingJobStep1")
            .tasklet((contribution, chunkContext) -> {
                log.info("Running UpdateSomethingJobStep1...");
                return RepeatStatus.FINISHED;
            })
            .build();
    }
}

APPLICATION FAILED TO START
***************************
Description:

The bean 'transactionManager', defined in class path resource [...], 
could not be registered. A bean with that name has already been defined in 
class path resource [SimpleBatchConfiguration.class] 
and overriding is disabled.

Action:
Consider renaming one of the beans or enabling overriding 
by setting spring.main.allow-bean-definition-overriding=true

해결 시도

"아 왜 배치용 transactionManager Bean 이름을 'transactionManager'로 한거야... batchTransactionManager 이런걸로 하면 안되나" 하여 불평.
DefaultBatchConfigur, SimpleBatchConfiguration Bean을 상속받아서 열심히 getTransactionManager()를 열심히 오버라이딩 시도.
오버라이딩 하며 한창 삽질하다, Error description 에서 BatchConfiguration을 내가 만든게 아니라, SimpleBatchConfiguration.class 만 보던것을 발견.
왜 그러지? 왜 왜 bean overriding이 안되지 고민 끝에 Error 내용 중에 Action 문구를 발견함.

Action: Consider renaming one of the beans or enabling overriding by setting spring.main.allow-bean-definition-overriding=true

5. 구글링해보니 Spring Boot 2.1 부터 사고를 방지하기 위하여 Bean Overriding이 기본 비활성화 됨. - Spring Boot 2.1 Release Notes

Bean Overriding
Bean overriding has been disabled by default to prevent a bean being accidentally overridden. If you are relying on overriding, you will need to set spring.main.allow-bean-definition-overriding to true.

6. Bean Overriding을 활성화 하기 위해 application.yml에 spring.main.allow-bean-definition-overriding: true 옵션 추가.
7. 파-워 해결.

결론

Spring boot 2.1 부터는 bean definition overriding이 false인것을 기억하자.

분명 이전에도 비슷한 문제를 겪었었는데....

R3와 Corda의 탄생배경

김병규 — Sun, 13 Jan 2019 18:02:33 +0900

R3는 금융 서비스를 위해 설계된 엔터프라이즈 블록체인 플랫폼인 corda를 개발하고 서비스하는 소프트웨어 회사다. R3는 2014년 소규모의 가족 회사로 출발했는데 R3중 R은 CEO인 David Rutter의 성을 뜻하고, 3은 공동 설립자의 수를 뜻한다.

R3는 2014년 동안 암호화폐 회사들이 금융 기관들을 대체하고자 하는 시도를 계속해서 지켜봐왔고, 블록체인 기술이 금융시장에 가져올 혁신을 대응하기 위해 비트코인과 이더리움 등 성공적으로 동작하고 있는 블록체인에 대한 연구를 진행했다. 연구의 목적은 암호화폐 회사들의 공격에 대응하는 것도 있었지만, 블록체인을 금융시장에 어떻게 적용할지, 실무적인 측면에서 바라보고 금융시장에 적용할 수 있는 기존 블록체인 기술에 대한 리뷰와 선택을 진행하는 것도 포함되어 있었다.

R3는 2014부터 2015년까지 수차례의 컨퍼런스를 진행하면서 블록체인과 분산원장에 대한 차이점을 분명히 하는 최초의 논문인 CaaS(Consensus-as-a-Service)를 발표했고, FX 결제를 초함한 구체적인 금융 유즈케이스를 포함한 협의를 진행했다. 또한 다양한 은행과 블로체인 기업, 금융기관들이 함께하는 컨소시엄을 구성하게 되면서 2015년 11월 말 42개의 금융 기관이 참여하는 DLG(Distributed Ledger Group)를 발표하며 R3라는 이름을 대체하게 되었다.

IBM에서 하이퍼레저를 개발하던 Richard Brown은 여러차례의 컨퍼런스와 대화를 통해 기존의 블록체인 플랫폼으로는 실 금융시장에 적용할 수 없다는 판단을 내렸고, 영국 버클레이 은행의 아키택트였던 James Carlyle, 비트코인 초기 개발자 Mike Hearn 등을 영입하여 Corda라는 새로운 금융 특화 블록체인 플랫폼을 개발하였고 2016년 1분기 말에 Corda라는 새로운 시스템을 구축하였다. 2016년 4월 5일 Richard는 Corda가 무엇인지, 설계 목표가 무엇진지, Corda는 블록체인이나 Cryptocurrency가 아니라 분산 원장이라는는 점에 대해 처음으로 공개적으로 설명했다. (Corda의 블록체인에 대한 기술적 정의는 다음편에 다루는 것으로...)

기존의 비트코인, 이더리움, 리플과 같은 블록체인 플랫폼을 실 금융시장에 적용할 수 없었던 이유에 대하여 백종찬님의 글을 인용하였다.

1. 데이터 프라이버시
기존의 블록체인 구조는 네트워크 참여자가 모든 거래 내역을 보관하고 열람하는 구조다. 즉 A와 B간의 거래를 C가 검증해야한다. 고객 또는 자산의 기밀성을 보호해야 하는 금융산업에서 이와 같은 공개적인 데이터 검증 구조는 적용될 수 없다.
2. 확장성
모든 네트워크 참여자가 거래에 대한 합의를 도출하고 검증을 하게 되면 참여자가 많아질수록 거래 처리의 속도가 느려진다. 업계에서 주로 "초당 거래수"라고 얘기하는데, 빠른 속도가 생경인 긍융거래에서 이러한 확장성의 한계는 큰 문제다.
3. 법률적 책임
스마트계약의 경우 기존의 블록체인은 법률적 책임의 소재가 불분명하다. 컴퓨터 코드에 의한 비가역적인 실행은 가능하지만 실제로 그것이 법률적 강제성을 가지는 것은 아니다.
4. 개연적 결제 완결성
기존의 블록체인, 특히 비트코인이나 이더리움과 같은 퍼블릭 블록체인의 경우, 결제의 완결성을 법률 또 기술적으로 100% 보장하지 않는다. 항상 네트워크의 포크 또는 블록 재종에 등의 가능성이 존재한다. 은행거래의 경우 결제의 완결성은 중앙은행이 법적으로 보장하기 때문에 법률적인 특면에서도 문제가 있다.

2017년 R3 컨소시엄은 공식적으로 두 그룹으로 나누었다. 한 그룹은 Corda 플랫폼 구축에 중점을 두고 있으며, 다른 하나는 컨소시엄 멤버에게 적절한 서비스를 제공하는데 중점을 두는 연구 그룹이다. 연구팀은 40개가 넘는 프로젝트를 진행중이며 20개 이상의 프로젝트를 완료했다. 그들이 진행하는 프로젝트들은 모두 이더리움, 리블, 패브릭, 코다, 캐나다 중앙은행, 바클레이즈 은행 등 블록체인에 국한되지 않은, 다양한 플랫폼과 관련되어 있다.

R3 컨소시엄의 프로젝트 중 하나인 제네시스 프로젝트는 42개 금융사들이 블록체인 위에서 기업어음을 보내는 프로젝트를 진행했고 그 이후에도 60개가 넘는 다양한 프로젝트에 은행들이 자발적으로 참여하여 매우 빠른 발전을 이루었다. 또한 국내 사례로 2017년 5월 국내 은행 중 국민,신한,우리,하나,기업은행 등 5개 시중은행이 R와 함께 고객확인 정보를 블록체인으로 저장,관리하는 프로젝트를 성공한 바 있다. 다만 금융사들의 고객정보를 공유하는 행위 등 법적으로 금지되어 있는 문제가 있기 때문에 상용화까지 처리해야할 이슈가 있을것으로 보인다.

지금까지 R3와 Corda의 탄생 배경과 발전 과정을 알아보았다. 다음 글에서는 Corda의 기술적 바탕을 좀 더 살펴보고 기존의 블록체인과 다른점은 무엇인지, 엔터프라이즈 플랫폼으로서 하이퍼레져와 차이점은 무엇인지 등 기술적인 부분을 좀 더 살펴 보고 Corda에 대한 이해도를 높이고자 한다.

참조

A brief history of R3 – the Distributed Ledger Group

THE CORDA WAY OF THINKING

R3, 넌 도데체 누구냐!

모바일 청첩장 공개 (Parallax scrolling, skrollr.js)

김병규 — Fri, 2 Nov 2018 18:19:55 +0900

개요

결혼을 하게 되어 모바일 청첩장을 직접 만들기로 했다.

기획자가 확실하신 분이라 그분의 니즈를 만족시키기 위한 템플릿을 찾을 수 없었다.

기획자님은 선과 원이 만나 우리가 된다는 것을 강조하길 원하셨고

나는 스크롤을 내리면 화면의 구성을 변경할 수 있는 parallax scrolling라는 기술로 개발하기로 했다.

Parallax scrolling를 위한 라이브러리는 skrollr.js 를 사용했다.

개발

최대한 단순화 하기 위해서 index.html 안에 css와 js 모두 인라인으로 개발했다.

jquery, skrollr 두개의 라이브러리를 사용했고, 이미지는 상대경로로 설정해서, 사용하고자 하는 분은 이미지만 바꾸면 된다.

나는 AWS S3에 public 저장소를 하나 생성하고, FrontCloud CDN 을 연결해서 하객들에게 공유했다.

사용자 환경은 모바일에 최적화 했고, PC화면에서 보아도 깨지지 않도록 살짝 설정해 두었다.

청첩장을 직접 만드시는 분들께 도움이 될 수 있길 바라며 포스팅한다.

데모

https://s3.ap-northeast-2.amazonaws.com/wedding-github/index.html

깃헙

https://github.com/wantutopia/mobileWeddingTemplate

스크린샷

중앙 거래소 호가 매칭 알고리즘 설계

김병규 — Wed, 24 Oct 2018 16:39:57 +0900

개요

호가창 무결성을 보장하고 트랜잭션을 쉽게 관리하기위해서 RDB를 이용한 구현을 찾아봤다.

하지만 RDB를 이용한 구현은 수평적으로 확장이 어렵기 때문에 IO를 담당할 하나의 MASTER DB에 의존성이 매우 높다.

또한 물리적 성능 향상을 위해서는 더 좋은 장비를 구매해야하고 단일장비의 성능엔 한계가 존재한다. (물리적으로나 비용적으로나)

그래서 호가 매칭 알고리즘에서 IO가 많이 발생하는 사용자 주문 생성, 주문 매칭 단계는 수평적 확장이 쉬운 Redis를 사용하여 처리하고

매칭된 주문 트랜잭션 생성 및 처리는 Mysql에서 관리하는 방향으로 설계해 보았다.

Redis 살펴보기

레디스는 메모리 기반 저장소라서 클러스터 서버 전체 다운시 데이터가 날아간다??
1. Redis가 Memory 기반 저장소라서 캐시 전용 저장소로 오해하는 부분이 많은데, Redis도 옵션에 따라 텍스트 형태의 파일로 데이터를 저장할 수 있다.
  때문에 클러스터가 전체 다운되어도 파일을 통해 데이터를 복구할 수 있다.
트랜잭션 관리가 어렵다??
1. 레디스는 싱글 쓰레드 기반이라 트랜잭션 관리가 쉬운편이다.
  또한 Lua Script 를 사용하거나 트랜잭션을 지원하는 명령어 (MULTI) 를 통해서 트랜잭션을 보장할 수 있다.
2. 오히려 싱글 쓰레드라 대량 작업시 블럭되는 점을 조심해야 한다. (keys 명령어나, 대용량 삭제와 같은 작업을 조심해야한다.)
대용량 데이터 저장이 어렵다??
1. 하나의 Key 당 최대 512MB까지 저장가능하다. 적지않은 사이즈지만 히스토리 정보까지 모두 메모리에 올려두기엔 부담스러운게 사실이다.
  그래서 IO 관련 데이터들만 redis에 저장하고 거래/히스토리 데이터는 RDB에서 관리하는 방향으로 설계해야한다.
클러스터링을 지원하여 가용성이 높다?
1. Redis를 사용하는 가장 큰 이유이기도하지만 가장 조심해야할 부분이기도 하다.
  클러스터 구성에 따라 다르지만 보통 레디스 클러스터는 Master - Slave 구조로 구성된다.
  Master가 다운될 시 Slave가 자동으로 Master로 승격되는데 이때 승격될 Slave 에 데이터가 비어있으면 모든 클러스터의 데이터가 비워지게 된다.
  우리는 Redis 클러스터를 직접 구현하지않고 AWS 를 사용할거라 다행이다 ^^

설계

필요한 자료구조

주문 상황판
(buy/sell 주문의 order price 별로 order quantity 를 가지는 Sorted Set<score, orderSum>)
주문 리스트
(Map<typeAndCoinAndPrice, List<order>> buyList, Map<typeAndCoinAndPrice, List<order>> sellList )
내 주문
(내 주문 상태를 관리하고 목록을 확인할 수 있는 Map<memberNo, Map<orderId, order>>)
매칭된 두개의 Order 를 저장/처리할 Transaction RDB 테이블

동작 시나리오

주문생성 (Create) - (주문 생성 전 주문이 필요로하는 코인/현금만큼 사용자의 잔고를 freeze 해야한다.)
1. 새로운 주문이 들어오면 시퀀스 시작.
2. (redis 트랜잭션 시작)
  '주문 상황판'을보고 매칭할 주문 리스트 진입점을 찾는다. (매칭되는 진입점이 없으면 v 단계로 이동)
  1. 주문 타입이 Buy면 주문 가격이하의 Sell List중 가장 저렴한 리스트를 찾는다.
  2. 주문 타입이 Sell이면 주문 가격 이상의 Buy List중 가장 비싼 리스트를 찾는
3. 매칭되는 리스트가 있으면 LPOP으로 order를 꺼내오고, '주문 상황판'과 '내 주문'에서 해당 order를 제거한다.
4. 요청 들어온 주문과 매칭된 주문의 거래량을 비교하여 분기 시퀀스를 따른다.
  1. IF (RequestOrder.quantity > MatchedOrder.quantity)면 두개의 주문을 갖는 Transaction 객체를 생성하고,
    RequestOrder.quantity 를 차감한다.
    처리된 MatchedOrder를 상황판과 사용자별 주문에 반영한다.
    (redis 트랜잭션 커밋 후 다시 ii 단계부터 시작)
  2. ELSE IF (RequestOrder.quantity <= MatchedOrder.quantity) Matched Order을 RequestOrder.quantity 기준으로 분리한 후
    Transaction 객체를 추가하고, 분리된 여유분의 Order를 다시 주문리스트로 LPUSH한다. (RequestOrder 의 주문량은 0이됨)
    스플릿되어 처리된 MatchedOrder를 상황판과 사용자별 주문에 반영한다.
    (redis 트랜잭션 커밋후 vi 단계로 이동)
5. 매칭되는 리스트가 없으면 Request Order의 가격 리스트에 RPUSH 하고 상황판과 내 주문에 반영한다.
  (redis 트랜잭션 커밋)
6. 생성된 Transaction 객체들을 처리한다.
  1. 주문 밸리데이션 (잔고, 요청내용 2중 검증)
  2. 사용자별 잔고 증감 및 수수료 취득
주문 관리 (Read)
1. 고객별 My 주문 리스트는 사용자 별 '내 주문' 모델을 통해 관리한다.
2. 전체 주문량은 '주문 상환판' 모델을 통해 관리한다.
3. 체결내역은 Transaction 테이블을 통해 관리한다.
주문 수정 (Update)
1. 주문량/주문가 수정의 경우
  (redis 트랜잭션 시작)
  대상 주문을 리스트에서 POP 하여 값 수정 후 RPUSH
  주문 상황판, 내 주문도 업데이트
  (redis 트랜잭션 종료)
주문 취소(Delete)
1. 주문 취소의 경우
  (redis 트랜잭션 시작)
  대상 주문을 리스트에서 POP
  주문 상황판, 내 주문도 업데이트
  (redis 트랜잭션 종료)

예외 처리

모든 주문은 요청 전에 검증(잔고확인, 소유자 확인, 권한 확인)을 통과해야한다.
검증된 주문이라도 트랜잭션 처리 전에 한번 더 검증한다.
주문처리 우선순위는 가격 > 시간이다.
트랜잭션 생성을 위해 주문을 LPOP 하여 거래량 차감 후 LPUSH 하는사이 시간 우선순위를 위배할 수 있다.

암호화폐 거래소 구축을 위한 주문 매칭 알고리즘 분석 #1

김병규 — Thu, 13 Sep 2018 18:56:35 +0900

개요

암호화폐 거래소를 구축하기 위해 주문(호가) 매칭 알고리즘을 찾아보던 중 좋은 글이 있어 번역과 사족을 달았다.

David Veksler 라는 소프트웨어 아키택트의 글이고, 설계한 암호화페 거래소를 중국 시장에 런칭까지 했다고 한다.

원문과 더불어 중국 시장 거래소 런칭에 관련된 글도 있으니 같이 보면 좋겠다.

번역은 녹색으로 표현하고 사족은 검은색으로 달았다.

결론

아주 단순한 구조의 설계지만 꼼꼼히 살펴볼수록 튼튼해 보인다.

Buy/Sell 주문을 하나의 테이블에 넣기 때문에 RDB 저장소를 사용하여도 괜찮은 IO를 보장할 것같다. (사실 IO 성능이 아닌 확장성 문제 때문이긴 하지만 하나의 마스터DB와 슬레이브들로 어느정도 서비스 가능한 TPS를 보장해 줄 수 있을듯)

아래에 사족을 달았듯이 Order 의 Status 검증을 주문 요청 전에 진행한다면 트래픽을 분산시켜 성능 높일 수 있을것 같다.

테이블 구조도에서 Type 값들을 모두 정규화 했는데 반정규화해서 사용해도 무방해 보이고 (미약하나마 성능향상위해) OrderBook 과 Transaction 이 가지는 관계, 남은 거래량을 처리하는 방법이 단순하지만 명시적이라 좋은 방법이라 생각한다.

또한 매칭 모듈 시작 트리거를 고객이 주문한 시점으로만 제한하고있어서 개인적으로 모호했던 부분을 분명히 할 수 있어서 좋았다.

본문

비트코인 거래소 프로젝트 파트 2: 주문 매칭 알고리즘

요약

통화 거래소는 구매자와 판매자가 자신이 가진 통화를 서로 다른 통화 유형으로 교환 할 수 있는 시스템이다.

본문

주문 매칭 모듈은 구매/판매 주문을 매칭하고 거래를 만들어 거래의 흐름을 기록하고 고객들의 잔고를 업데이트 한다.

트리거: 한명의 고객이 거래량과 가격을 입력하고 주문버튼(Buy 또는 Sell)을 클릭 한다.

본문에서는 액션으로 적혀있지만 트리거라고 이해하면 더 좋을것 같다. 이제부터 나오는 1~12번까지의 과정은 고객의 주문 트리거를 통해 실행된다.

1. 웹사이트는 고객의 Order를 Pending 상태로 OrderBook 이라는 테이블에 저장한다. 우선 주문을 처리하기 위해 쌓는다(filed).

그런 다음 오더 매칭 서비스는 Pending된 Order를 순차적으로 훑어본다.

[public int PlaceBuyBid(int customerId, decimal quantityOfBTC, decimal pricePerBTC, DateTime ?expirationDate = null) ,

public int PlaceSellOffer(int customerId, decimal quantityOfBTC, decimal pricePerBTC, DateTime ?expirationDate = null)]

2. 이 때 주문이 취소되었거나 만료되었는지를 확인하여 Order의 상태를 재검증 한다.

3. order 마다 자금 검증을 하고, 고객은 order 가 필요로 하는 자금을 가지고 있어야만 해당 order의 상태룰 active로 변경한다.

그렇지 않을 경우엔 suspended 되는데 고객이 이후에 자금을 입금하면 다시 활성화 한다.

검증을 통과하면

a: order 의 상태가 Active로 변경된다.

b: 비용 지불이 필요한 order면(sell order를 뜻하는 듯) Frozen Balance를 더한다. (고객이 자신이 가진 자산보다 더 많은 주문생성을 못하게 하기 위함) - 하지만 이 기능은 나중에 제거했다 - 우리는 Available balance보다 더 많은 주문 생성을 가능하게 했고 거래 전에 검증하는 쪽으로 방향을 바꾸었다.

Order suspended 는 그냥 pending 상태로 둔다는 말 같다. 앞서 말한 트리거가 발동할때마다 잔고를 확인해서 pending 또는 active로 처리한다. 잔고 확인하는 부분이 특이한데, 잔고 확인없이 주문을 생성해줄 경우 고객입장에서 주문생성을 빠르게 진행할 수 있지만 어뷰징이 걱정되고, 그냥 주문 요청시 잔고 체크하여 걸러 내는게 더 좋을것 같다. David는 이걸로도 부족했는지 order 검증시에도 잔액 검증을 빼고 거래 시점에 검증하는 쪽으로 바꿨다고한다.

4. 주문 매칭 시스템은 buy와 sell order 를 매칭하기 위해 동작한다. 주문을 매칭하기위해 모든 Acitve 상태인 Order의 가격을 검색한다.

* 만약 트리거 주문이 buy 이면 가격이 작거나 같은 주문을 찾는다.

* sell 이면 가격이 크거나 같은 주문을 찾는다.

* 시장가의 sell 이면 가장 비싼 주문을, buy 만 가장 싼 주문을 찾는다.

Order 인입시 검증을 해서 바로 Active 상태로 들여온 다음 1, 2, 3 과정을 생략하고 바로 4번으로 하는건 어떨까?
pending -> active 대신 active -> pending 으로 상태변경 과정을 바꾸고 외부 배치 작업으로 order 의 pending -> active, expired 작 업을 진행하는것도 좋을것 같다.

우리는 buy order를 위해서 오름차순으로 매칭하고 sell order를 위해서 내림차순으로 매칭한다. 그럼 다음 가격이 매칭되면 시간순으로 정렬한다.

[ISpecification IsMatchingOrderQuery(decimal price, int orderTypeId, int wantAssetTypeId,int offerAssetTypeId, bool? isMarketOrder)]

5. 우리는 상위 3개의 매치들을 메모리로 불러온다. 3개까지 가져오는 이유는 매칭된 주문들이 추후 검증에서 실패할 수 있기 때문이다.

메모리로 불러온다는 말은 단순히 DB에서 시스템상으로 SELECT 해온다는 말 같다.

6. 우리는 order 와 match를 비교한다. 이것은 C#은 이용한 이중 검증이다. - Order가 이전 데이터베이스 쿼리 결과와 일치해야한다.

order는 다음 조건은 만족해야한다. ($/BTC, order types[buy/sell], non-two market orders, matching prices)

[OrderComparisonResult CompareOrders(Order firstOrder, Order secondOrder)]

쿼리로 매칭하는 주문들을 불러왔지만 시스템 상에서 다시 한번 검증한다는 말인듯.

7. 만약 order 비교가 성공하면 매칭됨을 기록(record)하는 transaction 을 만든다.

[Transaction GetTransactionForTwoOrders(OrderComparisonResult comparisonResult)]

* A_Order 는 buy order

* B_Order 는 sell order

(A와 B를 사용하는 이유는 아직 어떤 주문이 Buy/Sell 이 될지 확실하지 않기 때문이다.)

Buy/Sell 두개의 오더를 가지는 하나의 Transaction 생성
Transaction 에 들어간 Order Status도 변경하는게 좋지 않을까?

8. 만약 주문간에 주문량이 정확히 일치하지 않으면 주문량이 남은 쪽 주문을 쪼개서 새로운 주문을 생성한다.

9. [ActivateTakeProfitAndStopLossOrders(Order order)] 를 실행한다.

TODO - 여기서 바로 시작하는게 아니라 스케쥴링한다. 자세한 내용은 다른 포스트 참고

무슨내용인지 궁금한데 연결된 포스트가 없다 ㅠㅠ

10. 주문이 매칭된 거래 (Transaction)을 처리하고 결과를 기록(record)한다.

[public Order ProcessTransaction(Transaction transaction)] (note: this module is a database transaction)

a: 거래와 쪼개진 주문을 DB에 추가한다.

b: 거래에 포함된 두 주문 모두에게

* 인출 금액을 차감한다. (고객의 달러나 BTC 계좌에서)

* 신용자산을 더한다. (고객의 달러나 BTC 계좌에서))

* 수수료 계좌에 수수료를 기록(record)한다.

* 동결 자산을 녹인다.

* 변경점들을 저장한다.

11. 쪼개진 주문의 남은 거래량이 0이 될때까지 대상으로 과정을 반복하거나, 매칭되는 주문이 없을때까지 반복 한 뒤 해당 주문을 active 상태로 유지한다.

foreach (OrderProcessResultModel n in ProcessOrder(splitOrder.OrderId)){
yield return n;
}

거래량이 남았을경우 처리가 궁금했는데 단순하게 푼것 같다.
필요한 거래량만큼 여러 주문을 불러와서 트랜잭션 진행하는것보다 직관적인 방법이지만
시간 복잡도 N이 추가된다. 안정성이 중요하다면 이정도는 감수하는것도 좋을듯..

12. 만약 남은 거개량이 0이되면 status를 Completed 로 변경한다.

Java Garbage Collection 요약

김병규 — Wed, 22 Nov 2017 12:45:41 +0900

Java로 몇년간 서버개발을 하고, 안드로이드 개발을 최근에 시작했다.

그래도 자바 개발자인데 GC에 대해서 확실하게 설명할 수 있어야지! 하는 생각에 Java GC를 요약해본다.

요약을 위한 포스트임으로 자세한 내용은 아래 참고를 확인 바란다.

자바의 신 이상민님이 NAVER D2에 올리신 글과 '자바 고양이 Tomcat 이야기' 도서를 참고했다.

Garbage Collection

GC는 Garbage Collection의 약자다. (Garbage Collector 아님ㅋ) Java는 Garbage Collector가 메모리 관리(Garbage Collection)를 자동으로 해주기 때문에 메모리 해제를 위한 별도의 코드가 필요없다. (Java 1.2부터 GC에 관여할 수 있는 클래스가 추가 됨) 하지만 GC에 대한 고민없이 Garbage Collector만 믿고 규모있는 어플리케이션을 서비스하면 어김없이 장애가 발생한다. 왜일까?

STW (Stop-The-World)

Full GC가 발생하면 JVM은 어플리캐이션 실행을 멈추고 GC를 실행하는 쓰레드만 작동한다. 만약 웹서버에서 Full GC가 발생하면 서비스는 중단될 것이고 서비스가 중단 된 동안 각종 Time Out이 발생할 것이고 미뤄진 작업들이 누적되어 또 다른 Full GC를 발생시켜 장시간 장애가 발생 할 수 있다.

메모리 공간(heap)을 늘리면 Full GC를 피할 수 있을까? 메모리공간을 늘리면 Full GC의 첫 수행 시점은 늦출 수 있겠다. 하지만 STW의 시간은 heap 크기에 비례하기 때문에 메모리 공간이 클수록 더 많은 시간과 노력이 필요하다. 때문에 Heap을 많이 할당하는 것이 반드시 좋은 것만은 아니다.

어떤 GC알고리즘을 사용하더라도 Full GC와 STW는 발생한다. Full GC를 어떻게 제거할 것인가!? 하는 질문 보다 Full GC는 왜 발생하는가? 그리고 어떻게 피할것인가? 어떻게 최소화 할 것인가? 라는 질문에 초점을 맞춰 보자.

Garbage Collector

Garbage Colletor는 두 가지 일을 한다.

힙(heap)내의 객체 중에서 garbage를 찾아낸다.
찾아낸 garbage를 처리해서 heap의 메모리를 회수한다.

그리고 두 가지의 전제조건 아래에서 만들어졌다.

대부분의 객체는 금방 접근 불가능 상태(unreachable)가 된다.
오래된 객체에서 젊은 객체로의 참조는 아주 적게 존재한다.

이러한 전제조건 아래에서 garbage를 처리하기 위해 HotSpot Vm)에서는 2개의 물리적 공간을 만들었다.

Young Generation 영역 : 새롭게 생성한 객체의 대부분이 이곳에 위치. 대부분의 객체가 금방 접근 불가능 상태가 되기 때문에 대부분의 객체가 Young 영역에 생성되었다가 사라진다. 이 영역에서 객체가 사라질 때 Minor GC가 발생했다고 말한다.
Old Generation 영역 : Minor GC이후에도 Young 역역에서 사라남은 객체가 여기로 복사 된다. 대부분 Young 영역보다 크게 할당하며, 크기가 큰 만큼 Young 영역보다 GC는 적게 발생한다. 이 영역에서 객체가 사라질 때 Major GC(혹은 Full GC)가 발생한다고 말한다.

Heap Area 구조 : https://www.journaldev.com/2856/java-jvm-memory-model-memory-management-in-java

위 그림에는 Perm(Permanent Generation) 영역이 추가로 보이는데 이곳은 클래스 로더에 의해 로드되는 클래스, 메소드 등에 대한 메타정보가 저장되는 영역으로 어플리케이션이 아닌 JVM에 의해 사용된다. 리플렉션을 사용하여 동적으로 클래스가 로딩되는 경우에 사용되기도한다.

Young Generation 영역의 구성

위 그림을 보면 Young 영역은 Eden과 S0, S1영역으로 나누어져 있다. S는 Survivor를 뜻한다.

Young 영역에서 객체 처리절차는 이상민님의 글을 그대로 인용하겠다.

새로 생성한 대부분의 객체는 Eden 영역에 위치한다.

Eden 영역에서 GC가 한 번 발생한 후 살아남은 객체는 Survivor 영역 중 하나로 이동된다.

Eden 영역에서 GC가 발생하면 이미 살아남은 객체가 존재하는 Survivor 영역으로 객체가 계속 쌓인다.

하나의 Survivor 영역이 가득 차게 되면 그 중에서 살아남은 객체를 다른 Survivor 영역으로 이동한다. 그리고 가득 찬 Survivor 영역은 아무 데이터도 없는 상태로 된다.

이 과정을 반복하다가 계속해서 살아남아 있는 객체는 Old 영역으로 이동하게 된다.

이 절차를 확인해 보면 알겠지만 Survivor 영역 중 하나는 반드시 비어 있는 상태로 남아 있어야 한다. 만약 두 Survivor 영역에 모두 데이터가 존재하거나, 두 영역 모두 사용량이 0이라면 여러분의 시스템은 정상적인 상황이 아니라고 생각하면 된다.

이렇게 Minor GC를 통해서 Old 영역까지 데이터가 쌓인 것을 간단히 나타내면 다음과 같다.

Old Generation의 GC

Old 영역은 기본적으로 할당 된 메모리에 데이터가 가득 차면 GC를 실행한다. 기본적으로 Young와 Old 영역크기는 1:2의 비율을 가지기 때문에 Old Generation의 GC가 더 많은 시간을 소요한다.

JDK버전이 올라가면서 GC를 위한 방식들이 추가되었다. GC의 방식은 Young 영역과 Old 역역 모두에 영향을 미치며 JDK7 기준으로 5가지 방식이 있다. (최근 JDK 8은 G1GC 방식을 Default로 한다.)

5가지의 GC에 대한 설명도 이상민님의 글을 그대로 인용하겠다.
다만 해당 이상민님의 글은 2011년에 작성되어서 G1GC방식의 안정성에 대해 걱정하고 있지만, 지금은 G1GC 안정화 과정을 마치고 대부분의 서비스에서 채택하고있다.

Old 영역은 기본적으로 데이터가 가득 차면 GC를 실행한다. GC 방식에 따라서 처리 절차가 달라지므로, 어떤 GC 방식이 있는지 살펴보면 이해가 쉬울 것이다. GC 방식은 JDK 7을 기준으로 5가지 방식이 있다.

Serial GC

Parallel GC

Parallel Old GC(Parallel Compacting GC)

Concurrent Mark & Sweep GC(이하 CMS)

G1(Garbage First) GC

이 중에서 운영 서버에서 절대 사용하면 안 되는 방식이 Serial GC다. Serial GC는 데스크톱의 CPU 코어가 하나만 있을 때 사용하기 위해서 만든 방식이다. Serial GC를 사용하면 애플리케이션의 성능이 많이 떨어진다.

그럼 각 GC 방식에 대해서 살펴보자.

Serial GC (-XX:+UseSerialGC)

Young 영역에서의 GC는 앞 절에서 설명한 방식을 사용한다. Old 영역의 GC는 mark-sweep-compact이라는 알고리즘을 사용한다. 이 알고리즘의 첫 단계는 Old 영역에 살아 있는 객체를 식별(Mark)하는 것이다. 그 다음에는 힙(heap)의 앞 부분부터 확인하여 살아 있는 것만 남긴다(Sweep). 마지막 단계에서는 각 객체들이 연속되게 쌓이도록 힙의 가장 앞 부분부터 채워서 객체가 존재하는 부분과 객체가 없는 부분으로 나눈다(Compaction).

Serial GC는 적은 메모리와 CPU 코어 개수가 적을 때 적합한 방식이다.

Parallel GC (-XX:+UseParallelGC)

Parallel GC는 Serial GC와 기본적인 알고리즘은 같지다. 그러나 Serial GC는 GC를 처리하는 스레드가 하나인 것에 비해, Parallel GC는 GC를 처리하는 쓰레드가 여러 개이다. 그렇기 때문에 Serial GC보다 빠른게 객체를 처리할 수 있다. Parallel GC는 메모리가 충분하고 코어의 개수가 많을 때 유리하다. Parallel GC는 Throughput GC라고도 부른다.

다음 그림은 Serial GC와 Parallel GC의 스레드를 비교한 그림이다.

그림 4 Serial GC와 Parallel GC의 차이 (이미지 출처: "Java Performance", p. 86)

Parallel Old GC(-XX:+UseParallelOldGC)

Parallel Old GC는 JDK 5 update 6부터 제공한 GC 방식이다. 앞서 설명한 Parallel GC와 비교하여 Old 영역의 GC 알고리즘만 다르다. 이 방식은 Mark-Summary-Compaction 단계를 거친다. Summary 단계는 앞서 GC를 수행한 영역에 대해서 별도로 살아 있는 객체를 식별한다는 점에서 Mark-Sweep-Compaction 알고리즘의 Sweep 단계와 다르며, 약간 더 복잡한 단계를 거친다.

CMS GC (-XX:+UseConcMarkSweepGC)

다음 그림은 Serial GC와 CMS GC의 절차를 비교한 그림이다. 그림에서 보듯이 CMS GC는 지금까지 설명한 GC 방식보다 더 복잡하다.

그림 5 Serial GC와 CMS GC(이미지 출처)

초기 Initial Mark 단계에서는 클래스 로더에서 가장 가까운 객체 중 살아 있는 객체만 찾는 것으로 끝낸다. 따라서, 멈추는 시간은 매우 짧다. 그리고 Concurrent Mark 단계에서는 방금 살아있다고 확인한 객체에서 참조하고 있는 객체들을 따라가면서 확인한다. 이 단계의 특징은 다른 스레드가 실행 중인 상태에서 동시에 진행된다는 것이다.

그 다음 Remark 단계에서는 Concurrent Mark 단계에서 새로 추가되거나 참조가 끊긴 객체를 확인한다. 마지막으로 Concurrent Sweep 단계에서는 쓰레기를 정리하는 작업을 실행한다. 이 작업도 다른 스레드가 실행되고 있는 상황에서 진행한다.

이러한 단계로 진행되는 GC 방식이기 때문에 stop-the-world 시간이 매우 짧다. 모든 애플리케이션의 응답 속도가 매우 중요할 때 CMS GC를 사용하며, Low Latency GC라고도 부른다.

그런데 CMS GC는 stop-the-world 시간이 짧다는 장점에 반해 다음과 같은 단점이 존재한다.

다른 GC 방식보다 메모리와 CPU를 더 많이 사용한다.

Compaction 단계가 기본적으로 제공되지 않는다.

따라서, CMS GC를 사용할 때에는 신중히 검토한 후에 사용해야 한다. 그리고 조각난 메모리가 많아 Compaction 작업을 실행하면 다른 GC 방식의 stop-the-world 시간보다 stop-the-world 시간이 더 길기 때문에 Compaction 작업이 얼마나 자주, 오랫동안 수행되는지 확인해야 한다.

G1 GC

마지막으로 G1(Garbage First) GC에 대해서 알아보자. G1 GC를 이해하려면 지금까지의 Young 영역과 Old 영역에 대해서는 잊는 것이 좋다.

다음 그림에서 보다시피, G1 GC는 바둑판의 각 영역에 객체를 할당하고 GC를 실행한다. 그러다가, 해당 영역이 꽉 차면 다른 영역에서 객체를 할당하고 GC를 실행한다. 즉, 지금까지 설명한 Young의 세가지 영역에서 데이터가 Old 영역으로 이동하는 단계가 사라진 GC 방식이라고 이해하면 된다. G1 GC는 장기적으로 말도 많고 탈도 많은 CMS GC를 대체하기 위해서 만들어 졌다.

그림 6 G1 GC의 레이아웃(이미지 출처: "The Garbage-First Garbage Collector" (TS-5419), JavaOne 2008, p. 19)

G1 GC의 가장 큰 장점은 성능이다. 지금까지 설명한 어떤 GC 방식보다도 빠르다. 하지만, JDK 6에서는 G1 GC를 early access라고 부르며 그냥 시험삼아 사용할 수만 있도록 한다. 그리고 JDK 7에서 정식으로 G1 GC를 포함하여 제공한다.

그러나 JDK 7을 실서비스에서 사용하려면 많은 검증 기간(1년은 필요하다는 생각이다)을 거쳐야 할 것으로 보이기 때문에, G1 GC를 당장 사용하고 싶어도 더 기다리는 것이 좋다는 것이 개인적인 생각이다. JDK 6에서 G1 GC를 적용했다가 JVM Crash가 발생했다는 말도 몇 번 들었기에 더더욱 안정화될 때까지 기다리는 것이 좋겠다.

GC 방식 보충

Parallel GC

이름처럼 여러 Thread를 동원해 GC를 처리한다. 정확히 말하면 Young Generation의 GC를 병렬 처리하는 것이며 Parallel Copy 알고리즘을 사용한다. Old Generation은 Serial GC와 같은 Mark-compact 알고리즘을 사용한다. 자바 1.5부터 Parallel Old GC가 소개 됐고, Old Generation도 병렬처리 하게 되었다.

CMS GC

Low Latency GC 혹은 Low Pause GC라고도 부른다. Old Generation GC시 발생하는 STW 시간을 최소화 하는는게 목적이어서 Old Generation 의 GC 알고리즘만 차이가 있다. Young Generation은 Serial GC나 Parallel GC와 같다.

GC를 줄이기 위한 JVM 튜닝

http://d2.naver.com/helloworld/37111 이곳 만한곳이 없다. 하하하!

정리/요약으로 JVM 튜닝작업을 내것으로 만들기는 어려울 것 같다.

GC에 대하여 요약한 내용을 바탕으로 서비스를 해보고 직접 헤딩해보는게 최선일 듯!

헤딩하게 되면 그 내용을 추가하겠다.

안드로이드 빌드 서버 구축하기 - Centos7, Jenkins, Sdkmanager

김병규 — Wed, 13 Sep 2017 14:07:42 +0900

안드로이드 빌드 서버를 구성하면서 메모한 내용을 정리한다.

빌드환경은 CentOS7, Jenkins, Github, Sdkmanager 로 구성하였다.

안드로이드 25 버전부터는 GLIBC_2.14 를 사용하기 때문에 CentOS 6이 아닌 7을 사용해야한다.

CentOS 6에도 GLIBC_2.14를 설치할 수 있지만, 커널쪽 라이브러리를 수정하는건 부담이다. 피하자.

안드로이드 SDK설치

안드로이드 SDK설치 과정이 바뀌었다. 포스트를 쓰게 된 가장 큰 이유다.

안드로이드 빌드환경 구성 방법을 구글링 해보면 adnroid-sdk r24.4.1 압축파일을 다운받아 SDK를 설정하는 방법이 대부분이다.

여기서는 최신버전 SDK로 빌드하기 위해, 안드로이드 공식 홈에 나와있는 sdkmanager를 사용했다.

sdkmanger 설치 & 경로 설정

android 폴더를 만들어 sdkmanger를 다운 받는다.

sdkmanger의 bin 폴더를 PATH에 추가 후 sdkmanger --list 명령어로 테스트 해본다.

안드로이드 패키지 리스트가 나오면 설치완료.

mkdir android
cd android
wget https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip
unzip sdk-tools-linux-3859397.zip
rm sdk-tools-linux-3859397.zip
PATH=$PATH:/절대경로/android/tools/bin
sdkmanager --list

sdkmanger로 sdk 다운로드

아까 생성한 android 폴더에서 platform-tools와 android-25, 26 platform을 설치한다.

설치가 완료되면 몇몇 폴더들이 추가되어있다.

지금의 android 폴더가 ANDROID_HOME이니 경로를 기억해두자.

sdkmanager "platform-tools" "platforms;android-25" "platforms;android-26"

[bkim@server android]$ ls
build-tools  licenses  output  platforms  platform-tools  tools

깃 설치

깃허브에서 안드로이드 프로젝트 소스를 받아올것이다. 젠킨스 세팅 전에 git을 설치하자.

설치 후 git 명령어를 날려보면 깃 명령어 리스트가 보인다.

yum update
yum install git
git

젠킨스 세팅

젠킨스 설치

젠킨스 설치 과정은 따로 설명하지 않겠다. jar 파일을 다운받아 바로 실행하는 방법도 좋고, tomcat으로 띄우는 방법도 좋다.

젠킨스 공식 사이트를 참고하면 최신버전을 설치 할 수 있다.

환경변수 설정

ANDROID_HOME을 설정하자. 젠킨스는 편리하게 환경변수를 추가할 수 있는 메뉴를 제공한다.

왼쪽 메뉴 중 Jenkins 관리 -> 시스템 설정 -> Global properties에 추가 -> 이름 ANDROID_HOME -> 값 아까 SDK 설치 경로 (/절대경로/android)

플러그인 설치

github 연동을 위하여 git 관련 플러그인들을 설치해주자.

왼쪽 메뉴 중 Jenkins 관리 -> 플러그인 관리 -> 설치가능 -> git plugin, github plugin 설치

(gradle이 설치되어있지않으면 gradle 플러그인도 추가하자)

빌드 테스크설정

빌드 테스크 설정을 위해 새로운 Item을 추가하자.

왼쪽 메뉴 중 새로운 Item -> Item 이름입력 -> Freestyle project 선택 -> OK

아이템이 생성되었으면, 아이템 설정을 해주자. 단순 빌드를 위한 설정은 단순하다.

소스 코드 관리 탭 -> git 선택 -> Repository 주소 입력 -> 깃헙 계정 입력 (나는 서버에 깃헙 키를 등록해두어서 따로 사용자 연동을 하진 않았다)

빌드 탭 -> Use Gradle Wrapper 선택 -> Make gradlew executable 체크 -> Tasks 에 clean assembleDebug 입력 (gradle 명령어는 각자에 맞게 수정)

빌드 후 조치 탭 -> 빌드 후 조치 추가에서 Archive the artifacts 선택 -> Files to archive에 빌드 완료시 apk 결과물이 떨어지는 경로 입력 (따로 세팅 안했으면 app/build/outputs/apk/*.apk 로 입력하면 된다.)

빌드 후 조치에서 Jenkins 저장 이외에 메일로 apk를 보내준다던지, 배포서비스로 apk를 전달하는 것 같은 태스크를 추가 할 수 있다.

또한 빌드 유발 탭에서 깃헙 push 할때마다 빌드도록 세팅해두고, 빌드 후 조치 탭에서 빌드 결과를 메일이나 메신저로 전달하면... 좋다.

설정 저장 -> Build Now 클릭 -> 빌드 결과로 들어가면 빌드된 이미지를 확인할 수 있다

마치며

젠킨스를 이용해서 안드로이드 빌드 서버를 구성했다.

빌드 서버를 구성하는 이유는 대부분 CI 환경을 만들기 위함일 것이다.

이제 젠킨스에 Findbugs 같은 코드 분석툴을 붙이고, 그래들 스크립트로 테스트 검증도 할 수 있다.

Deploy Gate라는 서비스를 이용하면 apk를 배포하고, 무선으로 테스트폰에 설치까지 해준다고한다.

결국에는 편하자고 하는 일들이니 우리들 모두 화이팅!!!

Maven vs Gradle

김병규 — Tue, 4 Jul 2017 10:27:58 +0900

Maven vs Gradle

스프링 기반의 프로젝트를 시작하면서 Maven을 처음 접했다.

Ant를 사용한적도 없었고 의존성 관리와 빌드 스크립트에 대한 지식도 없었기에 이런게 있나보다 하고 사용했었다.

Maven 책을 한권 보고나서야 프로젝트 구성, 빌드툴이 무었인지 이해할 수 있었고, 편리한 의존성 관리에 감사하며 부족함을 느끼지 못했다.

하지만 프로젝트의 단위가 커지면서 빌드와 테스트에 소요되는 시간이 길어졌고,

여러 모듈에서 설정을 상속받기 시작하면서 Gradle이라는 녀석이 계속 눈에 뛰었다.

Gradle이 Maven의 단점을 보완해주고 사용해본 사람들이 좋다고들 하니 Maven이랑 비교해서 얼마나 좋은지 알아보려 한다.

Maven

Apache의 이름 아래 2004년 출시

Ant를 사용하던 개발자들의 불편함을 해소 + 부가기능 추가

Maven은 무엇인가?

빌드를 쉽게 (Making the build process easy)
pom.xml을 이용한 정형화된 빌드 시스템 (Providing a uniform build system)
뛰어난 프로젝트 정보 제공 (Providing quality project information_

Change log document created directly from source control
Cross referenced sources
Mailing lists
Dependency list
Unit test reports including coverage

개발 가이드 라인 제공 (Providing guidelines for best practices development)

Keeping your test source code in a separate, but parallel source tree
Using test case naming conventions to locate and execute tests
Have test cases setup their environment and don’t rely on customizing the build for test preparation.

새로운 기능을 쉽게 설치할 수 있고 업데이트할 수 있음 (Allowing transparent migration to new features)

Gradle

Ant와 Maven의 장점을 모아모아 2012년 출시

Android OS의 빌드 도구로 채택 됨

Gradle이란 무엇인가?

Ant처럼 유연한 범용 빌드 도구 (A very flexible general purpose build tool like Ant.)
Maven을 사용할 수 있는 변환 가능 컨벤션 프레임 워크 (Switchable, build-by-convention frameworks a la Maven. But we never lock you in!)
멀티 프로젝트에 사용하기 좋음 (Very powerful support for multi-project builds.)
Apache Ivy에 기반한 강력한 의존성 관리 (Very powerful dependency management (based on Apache Ivy))
Maven과 Ivy 레파지토리 완전 지원 (Full support for your existing Maven or Ivy repository infrastructure.)
원격 저장소나, pom, ivy 파일 없이 연결되는 의존성 관리 지원
(Support for transitive dependency management without the need for remote repositories or pom.xml and ivy.xml files.)
그루비 문법 사용 (Groovy build scripts.)
빌드를 설명하는 풍부한 도메인 모델 (A rich domain model for describing your build.)

Maven VS Gradle

Maven에는 gradle과 비교 문서가 없지만, gradle에는 비교문서가 존재. (비교에 자신있는 모습 ..ㅋ)

Gradle이 시기적으로 늦게 나온만큼 사용성, 성능 등 비교적 뛰어난 스펙을 가지고있다.

Gradle이 Maven보다 좋은점

Build라는 동적인 요소를 XML로 정의하기에는 어려운 부분이 많다.

설정 내용이 길어지고 가독성 떨어짐
의존관계가 복잡한 프로젝트 설정하기에 부적절
상속구조를 이용한 멀티 모듈 구현
특정 설정을 소수의 모듈에서 공유하기 위해서는 부모 프로젝트를 생성하여 상속하게 해야 함 (상속의 단점 생김)

Gradle은 Groovy를 사용하기 때문에, 동적인 빌드는 Groovy 스크립트로 플러그인을 호출하거나 직접 코드를 짜면 된다.

Configuration Injection 방식을 사용해서 공통 모듈을 상속해서 사용하는 단점을 커버했다.
설정 주입 시 프로젝트의 조건을 체크할 수 있어서 프로젝트별로 주입되는 설정을 다르게 할 수 있다.

Gradle vs Maven: Performance Comparison

600명의 엔지니어가 1년동안 1분걸리는 빌드를 매주 42번 빌드를 진행할 때 들어가는 비용은
600 engineers * $1.42/minutes * 42 builds/week * 44 work weeks/year = $1,600,000/year
이때 빌드 속도가 90% 빨라진다면?
Gradle은 메이븐 보다 최대 100배 빠르다.
어떻게?

the Gradle Daemon is a long-lived process that keeps build information “hot” in memory
incremental task inputs and outputs for various types of tasks makes it unnecessary to run clean ever again
incremental compilation analyzes the dependencies between your sources and classes and recompiles only those which are affected by changes
the build cache fetches results from a cache when switching branches or running a clean build and the same output has already been produced somewhere else in the organization.
Gradle’s smart classpath analyzer avoids unnecessary compilation when the binary interface of a library hasn’t changed
better modelling of dependencies using the Java Library plugin reduces the size of the compile classpath which has a large, positive impact on performance

예제

스프링부트를 이용하여 같은 기능과 라이브러리 의존성을 가지는 Maven, Gradle 프로젝트를 생성해 보았다. (Java 1.8, Spring Boot 1.5.4)

스크립트 길이와 가독성 면에서 Gradle(groovy)이 앞선다.
빌드와 테스트 실행 결과 Gradle이 더 빠르다. (Gradle이 캐시를 사용하기 때문에 테스트 반복 시 차이가 더 커진다.)
의존성이 늘어날 수록 성능과 스크립트 품질의 차이가 심해질 것이다.

Maven
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>

   <groupId>com.example</groupId>
   <artifactId>demo-maven</artifactId>
   <version>0.0.1-SNAPSHOT</version>
   <packaging>jar</packaging>

   <name>demo-maven</name>
   <description>Demo project for Spring Boot</description>

   <parent>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-parent</artifactId>
      <version>1.5.4.RELEASE</version>
      <relativePath/> <!-- lookup parent from repository -->
   </parent>

   <properties>
      <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
      <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
      <java.version>1.8</java.version>
   </properties>

   <dependencies>
      <dependency>
         <groupId>org.springframework.boot</groupId>
         <artifactId>spring-boot-starter</artifactId>
      </dependency>

      <dependency>
         <groupId>org.springframework.boot</groupId>
         <artifactId>spring-boot-starter-test</artifactId>
         <scope>test</scope>
      </dependency>
   </dependencies>

   <build>
      <plugins>
         <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
         </plugin>
      </plugins>
   </build>


</project>

Gradle
buildscript {
    ext {
        springBootVersion = '1.5.4.RELEASE'
    }
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
    }
}

apply plugin: 'java'
apply plugin: 'idea'
apply plugin: 'org.springframework.boot'

version = '0.0.1-SNAPSHOT'
sourceCompatibility = 1.8

repositories {
    mavenCentral()
}


dependencies {
    compile('org.springframework.boot:spring-boot-starter')
    testCompile('org.springframework.boot:spring-boot-starter-test')
}

결론

지금 시점에서 Gradle을 사용하지 않을 이유는 '익숙함' 뿐인 것 같다.

Gradle이 출시되었을 때에는 Maven이 지원하는 Scope를 지원하지 않았고 성능면에서도 앞설것이 없었다.

Ant의 유연한 구조적 장점과 Maven의 편리한 의존성 관리 기능을 합쳐놓은 것만으로도 많은 인기를 얻었던 Gradle은 버전이 올라가며 성능이라는 장점까지 더해지면서 대세가 되었다.

물론 그동안 사용해왔던 Maven과 이제는 익숙해진 XML을 버리고 Gradle과 Groovy문법을 배우는 것은 적지않은 비용이 든다.

특히 협업을 하는 경우, 프로젝트 구성과 빌드만을 위해 모든 팀원이 Groovy 문법을 익여야 한다는 사실은 Gradle를 사용하는데 큰 걸림돌이 된다.

실제로 여전히 Maven의 사용률은 Gradle을 앞서고 있으며 구글 트랜드 지수도 Maven이 Gradle을 앞선다.

협업과 러닝커브를 고려하여 여전이 Maven를 사용하는 팀이 많고 부족함 없이 잘 사용하고 있지만,

앞서 요약했듯 프로젝트의 빌드타임이 비용문제로 이어질 경우 Gradle을 사용해야 할 것 같다.

리드미컬?하게 테스트를 진행하고 민첩한? 지속적 배포를 생각하고 있다면 새로움 배움이 필요하더라도 Gradle을 사용해보자. 아자.

출처

https://gradle.org/

https://maven.apache.org/

http://egloos.zum.com/kwon37xi/v/4747016

Nginx 설치하기 (컴파일 설치, CentOS 6.8, nginx-1.12.0)

김병규 — Fri, 23 Jun 2017 12:14:03 +0900

Nginx는 컴파일된 바이너리를 제공하지 않는다.

apt-get이나 yum을 통해 설치하면 설정 관리나, 이중화같은 작업이 어렵기 때문에 컴파일 설치를 선호하는 편이다.

2017년 6월 23일 기준 최신 Stable version인 nginx-1.12.0 버전 설치 스크립트를 아래 작성했다.

설치 기준 위치는 /home/username/apps/ 로 한다.

1. NGINX 다운로드

cd /home/username/apps/
wget https://nginx.org/download/nginx-1.12.0.tar.gz
tar -xvf nginx-1.12.0.tar.gz
rm nginx-1.12.0.tar.gz

2. PCRE 다운로드

cd /home/username/apps/nginx-1.12.0
wget http://downloads.sourceforge.net/project/pcre/pcre/8.37/pcre-8.37.tar.gz
tar -zxf pcre-8.37.tar.gz

3. zlib 다운로드

cd /home/username/apps/nginx-1.12.0
wget http://zlib.net/zlib-1.2.11.tar.gz
tar -zxf zlib-1.2.11.tar.gz

4. OpenSSL 다운로드

cd /home/username/apps/nginx-1.12.0
wget http://www.openssl.org/source/openssl-1.0.2f.tar.gz
tar -zxf openssl-1.0.2f.tar.gz

5. NGINX 설치

cd /home/username/apps/nginx-1.12.0
./configure --prefix=/home/username/apps/nginx --with-zlib=./zlib-1.2.11 --with-pcre=./pcre-8.37 --with-openssl=./openssl-1.0.2f --with-http_ssl_module --with-http_stub_status_module
make install
cd /home/username/apps/
rm -rf nginx-1.12.0

6. 실행권한 설정

cd /home/username/apps/nginx/sbin
sudo chown root nginx
sudo chmod +s nginx

7. 실행 및 테스트

cd /home/username/apps/nginx/sbin
./nginx //시작
//포트 80 이 사용중이면, /home/username/apps/nginx/conf/nginx.conf 에서 liten 80 을 변경해주면 된다. 
//자신의 서버 ip:prot 로 접근해보면 nginx index페이지 뜬것을 확인 할 수 있다. 
./nginx -s stop  //종료

Html5 Video Player 알아보기, 개발하기

김병규 — Tue, 6 Jun 2017 19:54:39 +0900

HTML5 Video Tag

HTML5는 HTML의 완전한 5번째 버전으로 월드 와이드 웹 (World Wide Web)의 핵심 마크업 언어이다. 2004년 7월 Web Hypertext Application Technology Working Group(WHATWG)에서 웹 애플리케이션 1.0이라는 이름으로 세부 명세 작업을 시작하였다.

HTML5는 HTML 4.01, XHTML 1.0, DOM 레벨 2 HTML에 대한 차기 표준 제안이다. 비디오, 오디오 등 다양한 부가기능과 최신 멀티미디어 콘텐츠를 액티브X 없이 브라우저에서 쉽게 볼 수 있게 하는 것을 목적으로 한다.
W3C는 2014년 10월 28일 HTML5 표준안을 확정했다고 발표했다. - https://ko.wikipedia.org/wiki/HTML5

HTML4에서 5로 넘어오면서 audio, video, canvas라는 멀티미디어 관련 태그가 추가되었다.

W3C는 2004년 새로운 표준을 제안하였고, 단계적으로 HTML5를 지원하는 범위를 넓혀가던 2007년까지 HTML5에 대한 시선이 곱지만은 않았다.

이제는 레거시 시스템이 된 Silver Light와 Flash, Active X가 라이벌을 물리치고 평정한 시대였고, 브라우저가 HTML5를 랜더링하는 성능도 눈에 뛰게 부족했기 때문이었다.

하지만 HTML5가 있으면 모든 클라이언트 서비스(읽고, 쓰고, 보고, 듣는)를 지원할 수 있다는 희망이 생겨났고, 이를 증명하듯 수많은 웹앱이 태어났다. 스마트폰과 하드웨어의 발전이 계속되고 복잡한 웹생태계를 표준화하고자 하는 사람들의 열망이 모여 현재 Flash와 Silver Light, Actice X는 레거시를 넘어 웹생태계를 해치는 악의 축으로 밀려 나기 까지 했는데, 이러한 HTML5 내용 중 Video에 대해서 살펴보고자 한다.

Video element 는 Medeia element를 구현하고 있으며, 속성으로 src, poster, preload, autoplay, mediagroup, loop, muted, controls, width, height 속성을 가진다. DOM생성시 해당 옵션을 지정할 수 있으며 이름을 통해서 알 수 있듯이 플레이어가 지원해야할 기본적인 옵션들이다.

Video element의 DOM interface로는 width, height, videoWidth, videoHeight, poster가 있고, Media elemet에 current와 duration 같은 좀 더 상세한 interface가 있다. 상세내용은 아래에 첨부하였다.

W3C Video 정의

Video Element

Content attributes

src
poster
preload
autoplay
mediagroup
loop
muted
controls
width
height

DOM interface

interface HTMLVideoElement : HTMLMediaElement {
           attribute unsigned long width;
           attribute unsigned long height;
  readonly attribute unsigned long videoWidth;
  readonly attribute unsigned long videoHeight;
           attribute DOMString poster;
};

Media elements (audio and video, in this specification) implement the following interface:

interface HTMLMediaElement : HTMLElement {

  // error state
  readonly attribute MediaError error;

  // network state
           attribute DOMString src;
  readonly attribute DOMString currentSrc;
  const unsigned short NETWORK_EMPTY = 0;
  const unsigned short NETWORK_IDLE = 1;
  const unsigned short NETWORK_LOADING = 2;
  const unsigned short NETWORK_NO_SOURCE = 3;
  readonly attribute unsigned short networkState;
           attribute DOMString preload;
  readonly attribute TimeRanges buffered;
  void load();
  DOMString canPlayType(in DOMString type);

  // ready state
  const unsigned short HAVE_NOTHING = 0;
  const unsigned short HAVE_METADATA = 1;
  const unsigned short HAVE_CURRENT_DATA = 2;
  const unsigned short HAVE_FUTURE_DATA = 3;
  const unsigned short HAVE_ENOUGH_DATA = 4;
  readonly attribute unsigned short readyState;
  readonly attribute boolean seeking;

  // playback state
           attribute double currentTime;
  readonly attribute double initialTime;
  readonly attribute double duration;
  readonly attribute Date startOffsetTime;
  readonly attribute boolean paused;
           attribute double defaultPlaybackRate;
           attribute double playbackRate;
  readonly attribute TimeRanges played;
  readonly attribute TimeRanges seekable;
  readonly attribute boolean ended;
           attribute boolean autoplay;
           attribute boolean loop;
  void play();
  void pause();

  // media controller
           attribute DOMString mediaGroup;
           attribute MediaController controller;

  // controls
           attribute boolean controls;
           attribute double volume;
           attribute boolean muted;
           attribute boolean defaultMuted;

  // tracks
  readonly attribute MultipleTrackList audioTracks;
  readonly attribute ExclusiveTrackList videoTracks;
  readonly attribute TextTrack[] textTracks;
  MutableTextTrack addTextTrack(in DOMString kind, in optional DOMString label, in optional DOMString language);
};

Youtube, Twitch, Pooq

실서비스 되고 있는 비디오 플레이어를 살펴보면, Html5 Video 태그로 플레이어 기본 기능을 구현한 것을 알 수 있다.

각종 버튼과, 광고노출과 같이 플레이어와 겹쳐서 보여지는 부분들은 DIV형태로 플레이어 위에 덧씌어져서 사용자에게 노출하고,

외부 Html요소를 이용하여 사용자로부터 전달되는 이벤트를 Video Eelement로 전달하는 방식으로 플레이어를 구현했다.

You Tube

Twitch

Pooq

Open Source

여러 종류의 Html5 Video Player 비교1, 비교2, 추천들이 있다.

다수의 Html5 Video Player 중에서 눈에 뛰는 두가지 오픈소스 플레이어를 소개한다.

두가지 플레이어 모두 플레이어 기본기능을 구현하고 있고, YouTube와 Vimeo완 연동이 가능하다.

또한 공통적으로 자막, 반응형, 스트리밍, 풀스크린, 다국어와 같은 사용자 편의기능을 포함하고있다.

Video.js의 Github Start는 16,549개다. Jquery가 45,000개 인것을 감안하면 엄청난 숫자이다.

사용자가 많은만큼 레퍼런스가 풍부하고, 대부분의 플러그인이 개발되어 있다.

커스터마이징이 필요없고, 하나의 솔루션처럼 Html5 Video Player가 필요하다면 가장 추천할만한 플레이어다.

Plyr의 Github Star는 9,469개다. 유명도에 비해 높은 Star 수를 보유하고 있으며,

경량화된 Html5 Video Player에 대한 개발자들의 요구를 반영하여 경량과, 커스터마이징에 초점을 맞추어 개발했다.

비교적 부족한 플러그인과 Owner가 육아에 돌입했다는 단점이 있지만 커스터마이징이 필수인 경우 가장 추천할만한 플레이어다.

Video.js

가장 사용자가 많은 Video Player Open Source (40만 사이트 이상)
HTML5와 Flash video까지 지원
활발한 PR과 다수의 플러그인
js간 의존성이 높고, 파편화(좋은말로 모듈화) 됨
Apache License

Plyr

경량, 커스터마이징에 초점을 맞춤
js 파일 하나, 10kb
비교적 부족한 플러그인
Owner가 최근 육아에 전념함
MIT License

Solution

유료 솔루션 형태의 Html5 Video Player도 많이 있다.

유료형태의 솔루션은 HLS(스트리밍)지원과 광고 연동, 사용자 통계, DRM지원, Preview Thumbnail, 360 View, 고객지원과 같은 부가기능을 무기로 가격을 책정한다.

하지만 Video.js 와 플러그인, hls.js와 같은 오픈소스들로 유료 기능들을 구현할 수 있기 때문에 플레이어만 판매하는 것을 넘어서 인코딩과 CDN, 그리고 스트리밍을 위한 서버를 함께 제공해주는 업체가 많다. 또는 플레이어를 무료로 풀고 고개지원에만 가격을 책정하는 업체도 있다.

자체적으로 스트리밍 서버와 CDN, 인코딩서버를 구축하기 힘든 경우 해당 업체를 사용하면 좋을것 같지만, 최근 AWS에서 워낙 친절한 솔루션을 내놓았기 때문에 개발자 관점에서 매력을 찾기는 어려울 것 같다.

OpenSource Issue (DRM, Streaming, Mobile, Ad)

오픈소스를 사용하여 Html5 Video Player를 구현할 때 어려운 점이 무엇일까 고민해보았다.

(유료 솔루션들이 해당 기능을 해결해주고 돈을 받는 것이기 때문에 유료 솔루션의 피처리스트들이 구현 시 어려운 점이었다.)

HLS Streaming : hls.js를 사용하면 된다.

DRM : hls.js를 사용하면 되지만, 스트리밍이 아닌경우 생각해봐야할 문제.

Mobile : 반응형 개발로 Web View 재생을 하면 되지만, 성능이 받쳐줄지는 미지수. 성능이슈라면 유료 솔루션도 어쩔수 없다.

Ad : 광고를 심는 시점과 고객 행동 데이터를 수집해야한다. 광고 노출기능은 Video.js에서 videojs-contrib-ads라는 플러그인 형태로 구현해 두었지만, 광고 전환율, 사용자당 클릭 퍼센트와 같은 통계데이터 수집은 따로 구현해야할 부분이다. 이 부분은 플레이어 자체의 기능이라기보다 서비스 플랫폼의 관점으로 바라봐야 할 것 같다.

Angular Change Detection & Zone.js

김병규 — Thu, 1 Jun 2017 12:34:24 +0900

Change Detection 란 무엇인가?

Change Detection(이하 CD)는 뷰와 모델을 동기화 할 수 있도록 컴포넌트의 변경을 감지하고 값을 동기화 하는 프로세스다.

Angular JS (1.x)

뷰단의 변경을 감지하는 것 뿐만 아니라, 비동기로 돌아가는 자바스크립트(ajax, setTimeout 등..)가 데이터 변경하는 시점을 감지하여 모델의 변경의 뷰단에 반영해야 하는데 Angular 1에서는 이런 로직을 Digest Loop로 구현 했었다.

Digest Loop로 감시할 대상을 지정하기 위해 scope마다 watcher을 등록하여 감지할 목록들을 만들어야 했는데 이런 상황 때문에, 데이터의 변경을 감지하기 위해서는 Angular 도구만을 사용해야 했다. ajax call 또는 click 같은 이벤트도 $http와 ng-click으로 구현해야만 모델 변경이 감지되었다.

이를 보완하기 위해 명시적 호출($diest, $apply, $timeout)을 지원했지만 개발자가 직접호출해야한다는 이질감이 있었다.

또한 Angular 1은 양방향 데이터 바인딩으로 구현했기 때문에 watcher들이 늘어날 수록 Digest Loop은 걷잡을 수 없이 혼란스러워졌다.

Angular

Angular2에서는 $scope기능을 없애고 Zone.js를 이용하여 CD를 구현하였는데, Zone.js 덕분에 Angular 도구 뿐만 아니라, 순수 자바스크립트로 컴포넌트를 구성할 수 있게 되었다. 또한 Angular 2는 단방향 바인딩을 구현하였기 때문에 (ngModel을 사용해서 양방향 바인딩을 구현할때도 데이터의 흐름은 단방향) CD는 어플리케이션 전체를 변경할 필요 없이 데이터가 바인딩 되어있는 곳만 변경을 감지하고 Angular2는 변경된 부분만 다시 그려주면 되었다. 이를 통해 Angular는 성능을 높일 수 있었고 강제되던 Angular 도구들을 제거할 수 있었다.

Figure: File Structure 출처 - https://angular-2-training-book.rangle.io

어떻게 변화를 감지하는가? (Zone.js - 동영상)

Angular는 Angular도구가 아닌 순수 자바스크립트로 변경한 데이터 변경 또한 감지 할 수 있다고 했다.

우리가 웹에서 ajax로 데이터로 가져오거나, Timer로 함수를 실행하거나, click 이벤트를 발생시키는것은 모두 비동기로 이루어지는데 사용자가 명시적으로 호출하지 않고도 어떻게 Angular는 어플리케이션 상태 변화를 감지할 수 있을까?

답은 Zone.js에 있었다. (Angular는 자체적인 Zone을 가지고 있고 ngZone이라고 한다.)

Zone.js는 JAVA의 ThreadLocal 개념과 비슷해서 각각의 비동기 기능에서 kick on과 kick off를 설정하지 않아도 Zone이 이를 감지하여 후킹할수 있게 해준다.

위 코드를 실행해보면 콘솔 창에 다음과 같이 나타단다.

1번에서 click event listener가 등록된것을

2번에서 setTimeout이 발생하여 Invoike 한것을 상세하게 알 수 있다.

이렇게 Zone.js는 비동기 코드들을 컨트롤하면서 사용자에게 편리한 후킹인터페이스를 제공해주는 것이고,

Angular는 ngZone을 이용해서 컴포넌트의 변화를 감지하는 것이다.

Angular에서 구현된 소스는 다음과 같다.

this.zone.onMicrotaskEmpty
    .subscribe(() => {
        this.zone.run(() => this.tick()
    })
})

tick()
{
    this.changeDetectorsRefs
        .forEach((ref) => ref.detectChanges())
}

어떻게 변경하는가?

그렇다면 앞서 ngZone이 감지한 변화를 Angular는 어떻게 View에 적용할까?

Angular의 컴포넌트들은 각자 자신만의 CD를 가지고 있어서, 각자 CD 수행하고 컨트롤할 수 있다. 예를 들어 클릭 이벤트가 발생하면, Zone.js가 이벤트를 감지하여 알려주고 Angular는 CD를 실행한다. 이 때 컴포넌트는 각자 자신의 CD를 가지고 있고 컴포넌트는 트리구조로 이루어져 있기 때문에 CD의 구조도 방향이 있는 트리구조로 구성된다. 방향성이 있는 트리구조 때문에 CD는 항상 TOP에서 ROOT로 전파된다.

http://pascalprecht.github.io/slides/angular-2-change-detection-explained/#/59

Angular 컴포넌트들은 자신만의 Change Detector를 가진다?

Runtime에 Angular는 각 컴포넌트마다 자신이 가진 속성들에 대하여 Change Detector 클래스를 생성한다.

Change detector들은 컴포넌트의 각 속성에대한 Old Value를 가지고 있기때문에 독립적으로 자신의 컴포넌트에 대한 변경 여부를 확인 할 수 있고,

감지 속도를 높이기 위해 개발자가 전략을 작성하거나 속성값 등을 전달 할 수 있다.

/**
 * @license
 * Copyright Google Inc. All Rights Reserved.
 *
 * Use of this source code is governed by an MIT-style license that can be
 * found in the LICENSE file at https://angular.io/license
 */
/**
 * @stable
 */
export declare abstract class ChangeDetectorRef {
    abstract markForCheck(): void;
    /**
     * Detaches the change detector from the change detector tree.

     */
    abstract detach(): void;
    /**
     * Checks the change detector and its children.
     */
    abstract detectChanges(): void;
    /**
     * Checks the change detector and its children, and throws if any changes are detected.
     */
    abstract checkNoChanges(): void;
    /**
     * Reattach the change detector to the change detector tree.
     */
    abstract reattach(): void;
}

Change Detection을 빠르게

그렇다면 어떻게 Chage Detection을 효율적으로 실행할 수 있을까?

앞서 설명했듯이 CD는 Runtime시 각 컴포넌트마다 생성되기 때문에 다양한 형태를 가질 수 있다. 각 컴포넌트의 구조에 맞게 CD 클래스를 정의 하고 생성하기 때문에, CD가 감시해야할 대상을 줄이면 성능을 높일 수 있다. Angular는 CD가 감시해야 할 대상을 줄이기 위해 Immutable 객체와 Observable 객체를 알아?보고 감시 대상에서 제외해 할 수 있는데, 이런 최적화는 Angular의 OnPush 전략(컴포넌트에 바인딩된 Input 값의 변화가 없는 경우에는 Subtree 에 대해 Change Detection을 하지 않음)으로 설정하여 처리한다.

Immutable

Immutable 객체는 값의 변화가 없음을 보장한다. 새로운 값을 지정하고 싶으면 객체를 변경하는 것이 아니라 새로 생성 해야만한다.

객체를 새로 생성한다는 것은 Angular 입장에서 값(상태) 비교가 필요 없다는 것을 뜻한다. Immutable 객체를 사용하는 바인딩된 컴포넌트들은 변경된 객체의 상태를 비교해 볼 필요 없이 객체의 레퍼런스만으로 변화를 감지할 수 있다.

(Javascript Immutable lib들을 이용하여 손쉽게 Immutable 객체를 생성해 볼 수 있는다. Immutable.js Gith ub)

http://blog.thoughtram.io/angular/2016/02/22/angular-2-change-detection-explained.html

Observable

관찰할 수 있는, 식별할 수 있는 객체를 의미한다. 관찰할 수 있는 객체를 구독(subscribe)하면서 값을 참조하는 방법이다.

예를 들어 다음과 같은 코드가 있을 때, firstName만 변경하여도 fullName까지 함께 변경 되는 것이다.

var firstName = Observable('BK');
var lastName = Observable('KIM');

var fullName = Observable(function () {
    return firstName.value + ' ' + lastName.value;
});

Angular에서는 Immutable 객체 반대 방식으로 CD를 생략한다. Immutable 객체의 레퍼런스 참조만으로 CD를 생략할 수 있었다면 반대로 Observabel 객체는 값의 변경점에서 이벤트를 발생시켜서 TOP CD까지 변경을 전파한다. 따라서 Angular는 ROOT에서 TOP으로 가는 길목에 있는 CD만 수행하면 되는 것이다. 이때 OnPush전략을 함께 사용하면 Observable 객체의 레퍼런스는 변경되지 않기 때문에, 이벤트 컴포넌트 Subtree의 CD가 생략 된다. 하위 컴포넌트들도 함께 업데이트 해야한다면 디텍터의 markForCheck()라는 API를 이용하여 Subtree까지 CD를 수행 할 수 있다.

http://blog.thoughtram.io/angular/2016/02/22/angular-2-change-detection-explained.html

마치며

AngularJs 1.x에서 Angular 2로 넘어오면서 가장 관심이 갔던 부분은 성능이었다.

Change Detection에 대해서 자세히 알아보기 전까진 ReactJS의 Virtual DOM과 비슷한 방식이라 생각했었는데, 깊이 들여다보니 Framewrok로서 장점을 잘 이용한 것 같다. 성능 저하와 복잡도 상승의 주 원인이던 양방향 바인딩을 없애고, Zone.js를 도입 함으로써 라이브러리 사용에 비해 자유롭지 못한 Framework의 단점을 보완하려 한 부분도 흥미로웠다. 들여다 볼수록 매력있는 Angular지만 제대로 사용하지 않으면 이러한 장점들의 존재조차 모르고 사용하게 될것이란 게 두렵기도 하다.

참조

Change Detection In Angular : https://vsavkin.com/change-detection-in-angular-2-4f216b855d4c

Change Detection : https://angular-2-training-book.rangle.io/handout/change-detection/

Angular Change Detection Explained : https://blog.thoughtram.io/angular/2016/02/22/angular-2-change-detection-explained.html

OnPush 동작 방식 이해 : https://jongmoon.github.io/blog/2017/02/13/ng-onpush-mechanism/

자바스크립트 프레임워크 소개 2 : Angulr2 - http://meetup.toast.com/posts/98

Javscript Framework와 Library (Angular VS React.js VS VanillaJS)

김병규 — Mon, 22 May 2017 15:58:31 +0900

결론

JavaScript개발시 어떤 프레임워크 또는 라이브러리는 사용할것인가? 라는 질문에 대답하기 위해 기술조사를 했다.

사용할 기술을 선택할 때는 언제나 트레이드 오프가 발생한다.

따라서 개발하려고 하는 서비스와 팀의 규모를 고려해서 결정 하는 것이, 트렌드와 유행에따라 결정하는것보다 타당하다 생각한다.

기술조사를 마치고 느낀점은 Angular는 개발자의 자유도를 제한하는 대신, 우리가 마주할 수 있는 이슈에 대하여 기본적인 방법을 제시해고 있었고,

React는 스스로 라이브러리임을 밝히며 몸집을 최소화하며 개발자의 선택을 존중하고 있었다. 개발자의 자유도를 제한하지 않는면에서 잘나가는? 분야에서 조예가 깊은? 개발자는 React Family를 좋아하겠다는 생각을 여러번 했다. 실제로 기술조사를 하면서 React를 추천하는 곳에서 geek함과 개발자스러운 냄새를 맡을 수 있었다.

부족한 견해일지 모르지만 서버개발 프레임워크와 비교해보았을 때 Angular를 보면서 Spring같다는 생각을, React Family를 보면서 Node.js 같다는 생각을 했다. 또한 진정으로 POJO와 닮은 Vanilla JS의 간단한 페이지를 돌아보며 이것 또한 좋은 방법 같았다. Jquery 또한 여전히 사용성에서 1등을 고수하고 있었으며, 사용 추세가 전혀 줄어들지 않고 있었다.

다만 우리가 Spring을 사용하듯이, 팀단위로 일정한 수준 이상의 JavaScript 생산성과 품질을 유지하려면 Angular의 프레임 안에서 개발해나가는게 좋을 것 같다. 개발자에게 주어지는 자유도가 높을수록 성능은 높아질 수 있지만, 유지 보수와 협업의 관점에서의 성능은 어플리케이션의 규모가 커질수록 낮아질 것이다.

만약 우리가 Front개발에 익숙하지 않은 팀이라면 Angular를, Front개발에 익숙한 팀이라면 React Family를 사용하는 것이 좋겠다.

소규모의 팀이거나 규모가 작은 서비스는 Front개발의 숙련도를 떠나 React Family를 이용하는것이 좋을 것 같다.

Framework

프레임워크란 무엇일까? 자바스크립트 프레임워크를 비교하기 전에 프레임워크에 대한 정의부터 분명히 해야겠다.

GoF의 디자인패턴 저자 랄프존슨은 "프레임워크란 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스를 제공하는 것" 라고 말한다. 혹자는 디자인 패턴 + 라이브러리 = 프레임워크라고 주장한다.

다양한 프레임워크가 존재하는 만큼 다양한 의미를 포함하고 있지만, 자바스크립트 프레임워크는 Inversion of control을 가능케하고 Modularity, Reusability, Extensibility 를 높이기 위한 목적을 가진 라이브러리 + 구조화 된 뼈대의 조합이라고 생각하면 좋을 것 같다. 우리가 흔히 사용하는 Jquery는 뼈대를 제공하지 않고 라이브러리만 제공하기때문에 프레임워크라고 부르지 않는다. Jquery를 사용해서 MVC 패턴을 입히면 그것은 프레임워크라 부를 수 있을 것이다.

최근 JavaScript가 사용되는 분야가 많아지고 인기가 높아지면서 오픈소스로 개발되는 자바스크립트 프레임워크들 또한 다양해지고 있다.

그 중에서 Angular 와 React를 비교해보고 이러한 상황을 비꼬는 듯한 용어인 Vanilla JS에 대하여 알아보자.

Angular

Angular는 MVC Framework로 최근 4.0버전을 출시했다. AngularJs는 1.x 버전을 지칭하고 Angular는 2.0 이후 버전을 지칭하는데, 1버전과 2버전은 패러다임의 변화가 있었고, 2버전 이후부터는 하위버전 호환을 유지하고있다. AngularJs에서 성능 문제의 주요원이었던 2 way data binding을 Angular에서는 빌트인으로 제공하지 않으며 서로 호환되지도 않음으로 분리해서 보아야 한다.

Angular는 구글 자체적으로 개발하던 AtScript를 사용하려 했으나, Microsoft와 협력하여 TypeScript를 채택했다.

한편에선 Facebook의 React와 달리 구글이 Angular를 사용하는 비중이 낮다는 점을 우려하고 있다. (YouTube를 새로 개편할 때 Polymer 사용)- 링크1, 링크2

React.js

UI 컴포넌트를 만들기 위한 라이브러리로, UI 컴포넌트만을 지원함으로 지원하는 범위가 작지만 다향한 조합으로 사용 할 수 있다.

React.js로 Angular의 directives를 구현하여 프레임워크를 구성할 수 있지만, 보통 Redux를 이용하여 프레임워크를 구축한다.

JavaScript와 TypeScript를 지원하지만 JSX라는 ECMAScript 친화적인 XML 문법을 사용할 것을 추천한다.

VanillaJS

VanillaJS는 자바스크립트 라이브러리와 프레임워크 홍수를 풍자하는 단어이다.

Java에서 POJO와 비슷한 개념이라 볼 수 있다.

순수한 JavaScript만을 이용하여 구현한?(구현해야 할) 프레임워크다.

별도의 라이브러리 없이 순수한 JavaScript만을 사용했기 때문에 가장 빠르고, 가벼운 장정이 있다.

http://vanilla-js.com/ 에서 사용하고 싶은 컴포넌트를 선택 후 다운받아 소스를 열어보면 그 의미를 더욱 잘 알 수 있다.

Angular VS React.js ? (2016 데뷰 정리 - 영상 , 발표자료)

위에서 설명했듯이 Angular는 프레임워크고 React.js는 라이브러리다.

둘을 1:1로 비교하는것은 무리가 있고 Angular VS React Family(React.js + Redux + React router + Babel) 정도로 비교해야할 것이다.

2016년 데뷰발표자료에 사견을 더해 둘을 비교해 봤다.

1. 성능

https://github.com/CoderK/js-framework-benchmark 로 성능 평가 해본 결과

	Angular	React	Vanilla
상대 시간	2.12	2.00	1.00
메모리 사용량	2.67	1.79	1.00

의미있는 속도차이는 없었음. 엔터프라이즈급 서비스 개발을 위해서 생산성에 좀 더 초점을 두어야 할것 같다.

학습 비용은 비슷하다고 생각함.

2. 언어 생산성

최근 Angular CLI 까지 나오면서 개발 환경과 학습 비용은 Angular가 낮다고 생각한다.

또한, Angular가 사용되는 곳이 많아지면서 (웹앱, 앱, 데으크탑 앱) 사용성도 증가되고 있다.

Angular	React
구글은 웹표준을 철저히 지키는 회사. 새로운 언어를 배운다는 개념보다 Next Es 라고 생각하자 구글이 만든게 표준이 아니면 표준을 추가하려고한다...?!	TypeScript는 지나친 비용을 야기한다. 타입 체커 라이브러리인 FLOW면 충분하다.
언어 생산성 측면에서 JavaScript 언어의 한계가 존재 했고 TypeScript가 탄생했다. Angular 와 React 모두 TypeScript를 사용할 수 있지만, React는 타입을 지정해 주는 체커형태 라이브러리인 FLOW를 더 많이 사용하는 편

3. 컴포넌트

Angular	React
Angular는 HTML 과 JS CSS 를 잘 분리했고 CSS 캡슐화를 내부적으로 지원해서 높은 이식성과 재사용성을 보장한다. JSX를 쓰면 마크업이 JS안으로 들어가는 형태. 코드를 실행하기 전까지 마크업 미리보기가 안된다. 또한 자바스크립트를 모르는 마크업 개발자와 협업할 경우 협업 자체가 매우 어렵다. Angular는 표준 HTML에 디렉티브를 확장해나가는 개념이라 기존 HTML 문법을 그대로 사용할 수 있다.(React는 className, defaultValue 같은 문법 사용)	React역시 Webpack를 사용하면 CSS 캡슐화를 지원할 수 있지만 네이티브로 지원하지 않은 것은 조금 아쉬운 부분인건 사실. 협업이 어려운점은 동의한다. 하지만 Angular도 Html에 논리코드(디렉티브)를 끼워넣어야 함으로 구조 안에 행위를 집어 넣는 순간 순수하지 못하다. 사실 구조와 기능을 분리할 수 없다. 그래서 통합하는 것을 목적으로 했고, JSX 는 기존 javascript에서 DOM을 생성하던 것의 단점을 보안하고 가독성을 높인 결과물이다.
컴포넌트 = HTML + JS + CSS CSS분리에 대해서는 동의하지만 JSX의 존재에 대하여선 대립

4. 데이터 동기화

Angular	React
Angular의 경우 양방향 바인딩으로 성능이슈가 있었지만 Angular2와 React는 상당히 닮아있고 성능부분에서도 비슷해짐. Angular는 React의 Virtual DOM을 보고? 체인지 디렉터라는 것을 만들었다. 마찬가지로 모델이 바뀌면 트리구조의 DOM을 훑으면서 달라진 부분만 다시 그린다. Angular는 조금 더 나아가서 Zone(실행영역)이란 것을 이용해서 DOM 변경시 setState, setValue를 개발자가 명시하지 않아도 자동으로 모델을 변경시켜준다. (React 는 DOM -> Model 은 명시해줘야함)	React는 Virtual DOM을 이용하여 모델이 바뀌면 새로운 Virtual DOM을 그리고 기존 Virtual DOM 과 비교해서 Diff 된 부분만 새로 그려준다.
뷰와 모델의 분리 후 데이터 동기화 문제 등장. Angular의 경우 양반향 바인딩으로 성능 이슈가 있었지만, Angular2로 넘어오면서 개선된 상태

5. 비동기 처리

Angular

React

비동기 처리를 위해 RxJS를 품었다. ZONE을 이용한 DOM -> MODEL 로 데이터 전송처럼 Angular 자체적으로 RxJS는 잘 품었다.
Javascript가 가진 다른 대안도 많은 와중에 왜 RxJS를 품은 것인지는 더 지켜봐야할 일

React는 라이브러리인 만큼 Angular보다 자유롭게 비동기 라이브러리를 쓸 수 있다.
페이스북은 리엑트를 라이브러리로 지원하기 때문에 RxJS를 포함하려고 하는 움직임은 없지만 커뮤니티에서 활발히 진행 중.
또한 React와 함께 쓰는 Redux와 RxJS 는 궁합이 좋고 NetFilx에서 사용한 예가 있다.
Angular가 RxJS를 플레임워크로 품은것은 관심가지고 볼 사항이다.

JavaScript Test Framework 비교 (Mocha vs Jasmine vs QUnit)

김병규 — Wed, 17 May 2017 16:44:18 +0900

Node.js의 탄생과 JavaScript라는 언어의 범용성이 커짐에 따라 JavaScript의 테스트 환경은 점점 더 중요해졌다.

JavaScript가 서버언어로 사용되면서 JavaScript 테스트는 e2e 테스트 뿐만아니라 BDD 또는 TDD가 가능한 유닛 테스트가 필요했고,

기존 테스트 환경은 발전했고, 새로운 테스트 프레임워크들이 탄생했다.

여러종류의 테스트 프레임워크 중 Mocha, Jasmine, QUnit을 비교해보자.

결론

테스트는 개발을 돕기위한 도구일 뿐 목적이 아님으로 개발 환경에 맞고 사용하기 편한 툴을 선택하면 된다.

테스트 속도 차이는 미비하고, 대부분의 툴들이 비동기 테스트를 지원함으로 테스트 툴간 성능비교는 무의미 한 것 같다.

자바스크립트 프레임워크를 사용하지 않고 Jquery만 사용한다면 Qunit으로 간단하게 테스트 환경을 구축하면 되고

Angular와 같은 자바스크립트 프레임워크를 사용한다면 Mocha와 Jasmine중 선택하면 될 것이다.

TDD를 생각한다면 DOM 이 필요 없는 Jasmine을 확장성 높은 테스트 환경을 생각한다면 Mocha를 선택하면 좋겠다.

나는 테스트 기능에만 충실하고 별도의 Dependency 설정이 필요없어 사용하기 쉬운 Jasmine을 선택하고 싶다.

테스트 비교

	Mocha	Jasmine	Qunit
버전	3.4.0	2.6.1	2.3.2
인기	중간	높음	낮음
assertion 라이브러리	chai 라는 외부 라이브러리 사용	내장	내장
러너	Karma 가능	Karma 가능 (Python, Ruby)	Karma 가능
난이도	보통 (3rd party library 필요, 유연함)	쉬움	가장 쉬움
커뮤니티	12.3K github Stars, 4.45K stack over flow	12.4K github Stars, 8.01K stack over flow	3.63K github Stars, 1K stack over flow
특징	Simple, flexible, fun javascript test framework for node.js & the browser	DOM-less simple JavaScript testing framework	A JavaScript Unit Testing framewor

테스트 문법

Mocha

var assert = require('assert');
describe('Array', function() {
  describe('#indexOf()', function() {
    it('should return -1 when the value is not present', function() {
      assert.equal(-1, [1,2,3].indexOf(4));
    });
  });
});

Jasmine

describe("A suite is just a function", function() {
  var a;
  it("and so is a spec", function() {
    a = true;
    expect(a).toBe(true);
  });
});

Qunit


<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>QUnit Example</title>
  <link rel="stylesheet" href="https://code.jquery.com/qunit/qunit-2.3.2.css">
</head>
<body>
<div id="qunit"></div>
<div id="qunit-fixture"></div>
<script src="https://code.jquery.com/qunit/qunit-2.3.2.js"></script>
<script src="tests.js"></script>
</body>
</html>


QUnit.test( "hello test", function( assert ) {
  assert.ok( 1 == "1", "Passed!" );
});

사람들이 좋아하는 이유(출처 https://stackshare.io/stackups/jasmine-vs-mocha-vs-qunit)

Mocha	Jasmine	Qunit
105 오픈소스	50 TDD 로 사용할 수 있음	5 단순함
77 단순함	39 오픈소스	3 오픈소스
62 Promise 지원	14 RSpec 표준	3 세팅하기 쉬움
32 유연함	11 DOM조차 필요없는 독립성	2 Promise 지원
18 사용하기 쉬움	10 훌류한 커뮤니티
7 브라우저와 서버 테스트	5 세팅하기 쉬움
2 다른 좋은 대안이 없음	3 단숨함
	2 Pivotal-Labs에서 개발함

Stackshare 특징비교 (https://stackshare.io/stackups/jasmine-vs-mocha-vs-qunit)

구글 트렌드

IntelliJ 에서 Angular 2 프로젝트 시작하기

김병규 — Tue, 16 May 2017 18:19:33 +0900

Angular를 시작하기 위해 문서를 찾아보면 대부분 편집 툴로 Visual Studio Code 를 추천한다.

처음 접해보는 용어와 Node라는 런타임, 그리고 npm 사이에서 새로운 편집툴은 Angular의 진입 장벽을 더욱 높인다.

평소 사용하고 있는 IDE인 IntelliJ에서 Angular2(이하 Angular) 프로젝트를 생성할 수 있으면 조금이나마 진입 장벽을 낮출 수 있을것 같아서 내용을 정리한다.

해당 문서는 Window 환경을 기준으로 작성했다.

1. Node.js 설치

https://nodejs.org/ko/ 에 접속하여 stable 버전인 v6.10.3 LTS 를 다운받고 설치한다.

Node.js라는 개념이 쉽게 와닿지 않는다. 노드란 무엇일까?

"Node.js 는 Chrome V8 JavaScript 엔진으로 빌드된 JavaScript 런타임" 이라고 공식페이지에서 말한다.

런타임이란 프로그램이 실행되고 있을 때 존재하는 곳을 뜻하는데, 우리가 익숙하게 사용하고 있는 JRE를 떠올리면 쉽다.

JRE는 Java Runtime Environment의 준말로 우리가 개발한 JAVA 어플리케이션을 구동하기 위한 환경인 것이다.

이처럼 노드는 JavaScript로 개발된 어플리케이션을 구동하기 위한 환경이다.

또한 Node.js의 패키지 생태계를 지원하기 위해 npm 이란 것이 있다.

리눅스에서 흔히 사용하는 yum, apt-get, rpm과 비슷한 개념의 패키지 매니져이며 npm은 JavaScript를 위한 패키지 매니저라고 보면 된다.

Node.js를 설치할때 npm도 같이 설치 된다.

2. Angular CLI 설치 (https://cli.angular.io/)

cmd 창에서

npm install -g @angular/cli@latest

npm install --save-dev @angular/cli@latest

여기까지 설치 후 cmd 창에서 ng -v를 날려보면 다음과 같은 버전 정보가 나와야한다.

#최근 angular 패키지의 이름이 변경되었고, 이전버전을 디프리케이트 했다.

골뱅이가 붙어서 시작하는게 변경된 버전이니 책이나 구버전 문서들을 볼때 주의해야겠다.

Angular 프로젝트 생성, 빌드, 테스트를 도와주는 command line interface(CLI)이다.

Angular CLI 로 프로젝트를 생성하면 각각 따로 설정해줘야하는 polyFill, tsConfig, typings, karma 등등 각종 의존성등을 설정해준다.

NodeJs를 처음 접하면 온갖 의존성 관리에 좌절하기 마련인데, 이러한 문제를

Angular CLI는 가장 최적화된 상태로 프로젝트를 생성함으로써 진입 문턱을 낮춰준다.

이밖에 쉽게 테스트할 수 있는 로컬 서버과 테스트까지 제공해주니 각각 따로 세팅하는것 보다 Angular CLI 사용하는것을 추천한다.

3. IntelliJ 플러그인 설치

IntelliJ에는 Angular 프레임워크가 없다. (Web Storm 에는 있음)

플러그인으로 설치 하기 위해 IntelliJ Settings -> Plugins -> Browse Repositories -> AngularJS 를 검색 설치한다.

재시작 후 File -> New -> Project -> Static Web 을 보면 Angular CLI 를 확인할 수 있다.

4. 프로젝트 생성

File -> New -> Project -> Static Web 을 보면 Angular CLI 후 Next를 클릭하면,

프로젝트 이름과 위치를 지정할 수 있으며, Node Interpreter 와 Angular CLI를 선택 할 수 있다.

Node 는 1번 단계에서 설치한 node.exe.의 위치를, Angular CLI 는 npm으로 설치한 Angular CLI 패키지 위치를 지정해주면된다.

프로젝트 생성을 마치면 IntelliJ가 자동으로 Angular CLI에 new 명령어를 날려 필요한 라이브러리들을 다운받고 설치한다.

Angular CLI 위치가 목록에 보이지 않는다면 다음 사이트를 참조해보자.

https://www.jetbrains.com/help/idea/2017.1/using-angular.html

http://revf.tistory.com/entry/IntelliJ%EC%97%90%EC%84%9C-Angular2-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0-with-Angular-CLI

5. output 세팅

AngularJs는 타입스크립트를 사용하기 때문에 타입스크립트를 자바스크립트로 컴파일 하는 빌드과정이 필요하다.

IntelliJ 터미널 또는 좌측 하단 npm 창에서 build 를 클릭하면 명시적으로 컴파일할 수 있다.

이때 컴파일 결과물들을 임의의 위치에 저장하려면 angular-cli.json 설정을 수정하면 된다.

추후 스프링과 연동할때 필요할것으로 보이므로 관심이 있으면 수정해보자.

"outDir": "dist",  --> "outDir": "output",

빌드 시작

빌드 성공

빌드 결과물

6. 프로젝트 실행

생성한 프로젝트를 실행하기 위해 Angular CLI 는 serve 명령어를 지원해준다.

IntellJ의 npm 창에는 start로 표시되어있는데, 클릭해보면 터미널 창에서 ng serve 명령어를 날리는 것을 볼 수 있다.

ng serve 를 하면 콘솔창에서 연결정보 (localhost:4200)를 확인 할 수있다.

(ng serve 는 ng build 를 포함한다.)

7. 실행 확인

별다른 설정을 하지 않았다면, ng serve로 시작한 어플리케이션은 라이브 코딩을 지원한다. (자동 빌드)

src/app/app.component.ts 의 title 변수를 변경하고 저장하면 자동으로 업데이트 되는것을 확인 할 수 있다.

Linux 환경에서 Selenium으로 웹 테스트 자동화하기 (Spring, CentOS, Jenkins)

김병규 — Tue, 7 Mar 2017 14:52:31 +0900

목적

윈도우 로컬환경에서 셀레늄 테스트 모듈을 구현하는 것은 비교적 쉽게 구현할 수 있다.

문제는 커맨드 환경인 리눅스 서버에서 가상 모니터를 띄우고 젠킨스와 연동하여 테스트를 자동화 하는것이다.

때문에 CentOS 환경에서 셀레늄 테스트를 자동화 하는데 초점을 맞추어 가이드를 썼다.

해당 포스트는 아래 내용을 포함한다.

Selenium을 이용하여 웹 테스트 모듈을 구현.
CentOS와 Jenkins를 이용하여 셀레늄 웹 테스트를 자동화.

테스트 환경

최대한 최신환경을 사용하려 노력했다.

셀레늄 : 3.2.0 (selenium-java, selenium-chrome-driver, selenium-server)

브라우저 : Chrome 56.0.2924.87 (64-bit)

크롬 드라이버 : ChromeDriver 2.27

스프링 : 3.2.17.RELEASE

CentOS : CentOS Linux release 7.1.1503 (Core)

Jdk : 1.8.0_101 (Oracle)

테스트 구현

1.Spring Maven 프로젝트를 생성하여, 테스트환경을 구성한다.

2.셀레늄 테스트를 위하여 pom.xml에 라이브러리 의존성을 설정한다.

<!-- pom.xml selenium -->
<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version>3.2.0</version>
</dependency>
<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-chrome-driver</artifactId>
    <version>3.2.0</version>
</dependency>
<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-server</artifactId>
    <version>3.2.0</version>
</dependency>

3.테스트를 작성한다.

setUp() 에서 크롬 드라이버 위치 지정

테스트 내용은 구글에서 "어쩌다, 블로그"를 검색

-> 검색 결과중 "어쩌다, 블로그"라는 문자열을 가진 링크를 10초간 대기하면 찾기

-> 클릭

public class SeleniumSampleTest {

   private WebDriver driver;

   @After
   public void tearDown() throws Exception {

      Thread.sleep(5000);
      driver.quit();
   }

   @Before
   public void setUp() throws Exception {

      System.setProperty("webdriver.chrome.driver", "D:\\gecko\\chromedriver.exe");
      driver = new ChromeDriver();
   }

   @Test
   public void testGetGoogle() throws Exception {

      driver.get("http://www.google.com");
      WebElement searchBar = driver.findElement(By.cssSelector("#lst-ib"));
      searchBar.sendKeys("어쩌다, 블로그");
      driver.findElement(By.cssSelector("#_fZl")).click();
      WebElement bkim = new WebDriverWait(driver, 10).until(ExpectedConditions.elementToBeClickable(
                                                                                   linkText("어쩌다, 블로그")));
      bkim.click();
   }
}

4.테스트 정상작동확인.

리눅스에서 셀레늄 환경 구성 하기

CentOS 메이븐과 젠킨스가 설치되어 있다는 가정하에 진행한다.

젠킨스가 아니더라도 메이븐 테스트를 진행하는 방법은 많다.

아래 가이드하는 환경 설정 후 메이븐 테스트를 위해 다른 툴을 사용하여도 무방하다.

1. 혹시 GCC가 깔려있지 않으면 설치해주자. 크롬 실행 시 필요한 라이브러리들을 가지고있다.

2. 크롬 설치 (https://tecadmin.net/install-google-chrome-in-centos-rhel-and-fedora/)

위 링크에서 크롬을 설치하여도 GUI 환경이 준비되지 않은채 google-chrome 명령어를 날리면

browser_main_loop.cc(272)] Gtk: cannot open display 와 같은 에러를 뱉으며 크롬이 실행 되지 않는다. 우선 설치만 해두자.

3. 크롬 드라이버 다운로드 (https://chromedriver.storage.googleapis.com/index.html?path=2.27/)

위 링크에서 환경에 맞는 드라이버를 다운로드 후 적절한 경로에 다운 받은 후,

테스트 소스에서 chrome.driver 경로를 맞춰주자.

4. Xwindows 설치 (http://chandrewz.github.io/blog/selenium-on-centos)

위 링크를 참고하거나 아래 명령어를 수행한다.

설치

$ sudo yum install Xvfb libXfont Xorg
$ sudo yum groupinstall "X Window System" "Desktop" "Fonts" "General Purpose Desktop"

99번 포트로 Xwindows 실행

$ Xvfb :99 -ac -screen 0 1280x1024x24 &

99번 포트로 XWindows display 포트 지정

$ export DISPLAY=:99

이제 다시 google-chrome 명령어로 크롬을 실행해보면 cannot open display 와같은 에러가 사라진것을 알 수 있다.

젠킨스 연동

1. 테스트로 만든 maven 프로젝트를 서버로 업로드한다.

(메이븐으로 테스트를 돌릴것이기 때문에 따로 빌드하여 올릴 필요는 없다.)

2. Jenkins에서 Freestyle project를 하나 생성한다.

3. 프로젝트 이름과 로그 로테이션을 각각 설정한다.

4. 빌드 환경에서 테스트 전후로 Xwindow를 사용할 수 있도록 Start Xvfb before the build, and shut it down after. 를 반드시 체크한다.

5. Build 단계로 이동하여 Execute shell 항목에 테스트를 실행할 쉘 명령어를 입력한다.

2번단계에서 소스 업로드한 폴더로 이동 (cd /home1/irteam/deploy/test)

메이븐으로 테스트 실행 -Dtest=클래스명#메소드명 test (mvn -Dtest=SeleniumSampleTest#testGetGoogle test)

cd /home1/irteam/deploy/test
mvn -Dtest=SeleniumSampleTest#testGetGoogle test

6. 테스트 수행 및 테스트 성공 확인.

마치며

셀레늄은 브라우저를 포함한 사용자 환경을 그대로 재현하여 테스트하기 때문에, 클라이언트에 가장 가까운 테스트 툴이라 할 수 있다.
그 특성때문에 리눅스 서버에서 수행하기에는 어려움이 따른다. 이를 해결하고자 삽질했던 내용들을 블로그에 남겼다.

리눅스에서 셀레늄을 돌리고자하는 분들의 삽질에 도움이 되길바란다.

☞ 관련하여 어떤 내용이듯 댓글로 달아주시면 답글 드리겠습니다. 감사합니다.

AWS CodeBuild 사용하여 빌드하기

김병규 — Mon, 12 Dec 2016 18:46:55 +0900

목적

그동안 프로젝트 CI(Continuous Integration) 관리를 위하여 빌드서버를 따로 관리해야하는 번거로움이 있었는데,

AWS에서 이러한 어려움을 덜어주기위해 AWS CodeBuild를 출시했다.

보편적으로 사용되고 있는 빌드툴인 젠킨스를 사용하기 위해서는 다소 복잡한 세팅과정과 빌드용 서버가 필요했다.

빌드를 위한 작업자와 서버에 들어가는 비용을 줄이기 위하여, AWS CodeBuild를 사용하려 한다.

빌드하고자하는 프로젝트의 환경은 Maven, Spring4, Github 이다.

AWS CodeBuild란?

CodeBuild는 빌드에 소요되는 시간(분당 $0.005)에 과금하며, 빌드용 서버 사양을 선택할 수 있다.

테스트 해본결과 보통 5분이면 빌드가 완료되었고, 가격으로 따지면 빌드당 $0.025이다. 왠만큼 큰 프로젝트가 아니면 저렴하게 사용할 수 있겠다.

소스 레파지토리는 AWS CodeCommit, GitHub, S3bucket를 사용할 수 있고 언어 대부분의 서버언어를 커버한다.

빌드 스펙은 YAML 양식을 사용하는데 상세 내용은 아래 세팅하기에서 다루겠다.

상세 스펙은 한글로 번역된 페이지를 첨부하여 대신한다.

https://aws.amazon.com/ko/blogs/korea/aws-codebuild-fully-managed-build-service/

빌드 서버를 설치, 설정 및 확장 및 패치 등에 신경쓰지 않고, CodeBuild를 활용하여 개발 과정에서 유연상을 보장하고 여러 형태의 빌드 상태나 호환성의 불일치 문제를 해결할 수 있습니다. CodeBuild를 사용 하면, 사전에 빌드 서버를 프로비저닝 할 필요가 없으며, 대기중인 빌드를 쌓아 두는 대신에 빌드 볼륨을 활용할 수 있도록 자동으로 확장됩니다. 분당 $0.005부터 시작하는 가격으로 분당 기준으로 빌드 리소스에 비용을 지불하기 때문에 사용한 시간만 비용을 지불합니다.

세팅하기

빌드를 위한 서버세팅이 필요 없었기 때문에, 전체적인 빌드 세팅은 젠킨스보다 훨씬 간편했다.

다만, 레퍼런스가 적고 ASIA쪽 리전은 서비스 이전이라 Oregon 리전을 사용해야하는 번거로움이 있었다.

CodeBuild 프로젝트 생성 (Configure your Project)

CodeBuild 서비스에서 Create Project를 클릭한다.
Project name은 아무거나 상관없다.

Source: What to build

소스코는 github에서 가져오려고한다. 간단하게 사용자 인증을 하면, 내 깃헙의 레파지토리를 볼 수 있다.

buildspec.yml 작성

프로젝트 루트레벨에 buildspec.yml 이름의 파일을 생성한다.
실직적으로 빌드를 위한 스크립트내용을 담고 있는 파일이다.

version : 0.1 (빌드할 프로젝트의 버전)
environment_variables : (환경 변수로 빌드 시 입력받을 수도 있지만 여기서도 받을 수 있다. 없어도 됨)
phases : 빌드 단계별 설정으로 pre bulid 와 build만 작성했다.
artifacts : 빌드 완료 후 결과물 경로를 위한 설정으로 AWS S3에 업로드하기 위한 필수조건이다.

Environment: How to build

빌드 스크립트를 buildspec.yml를 통해 정의했다면 빌드 환경만 선택해 주면 된다.
OS는 현재 Ubuntu만 사용가능하다. (Java, jdk8 선택)
Artifacts: Where to put the artifacts from this build project

빌드 후 생성되는 war 파일을 저장할 곳을 지정한다.
같은 리전의 S3 저장소만 사용할 수 있음에 유의한다.

Service role & Advanced settings

서비스 롤과 빌드 서버 성능, 환경변수값을 지정할 수 있다.
자세한 설명은 생략한다.

빌드하기

이제 Source Version에 빌드할 브랜치명만 추가하면 프로젝트를 빌드할 수 있다.

빌드 과정과 로그가 친절하게 표시된다.

빌드과 완료되면 단계별 결과와 로그를 확인 할 수 있다.

빌드가 끝나면, 앞서 세팅해두었던 S3에 artifact가 저장되어있다. 완료~!

삽질내용, 앞으로 AWS CodeDeploy 연동

buildspec.yml 을 정의하지 않고 커맨드라인으로 빌드 스크립트를 작성했더니, 빌드 완료 후 S3에 올릴 artifact를 찾지 못했다.

pom에 등록된 의존성 중에서 oracle 관련한 라이브러리를 가져오지 못했다. -> pom에 레파지토리 추가.

이제 CodeDeploy를 이용하여 무중단 자동 배포만 준비하면 된다.

Jenkins를 알고 CodeBuild를 설정해서 그런지, 무척이나 쉽게 느껴졌다.

하루빨리 Seoul 리전에도 서비스 되길!

JDBC에서 Batch Processing 이란? (Mybatis 연동)

김병규 — Tue, 21 Jun 2016 18:29:38 +0900

목적

Spring + Mybatis로 구성된 서비스를 운영하던 중 사용자가 몰렸을 때 DB에 부담을 덜어주기 위한 방법을 고민했다.

Mybatis 의 ExcutorType 을 Batch로 설정하면 성능이 향상 되었는데 이유를 파악하기 위해 포스트 남긴다.

결론적으로 Batch 는 statement를 재사용 하며 Create, Insert, Update를 벌크로 모아서 처리하고,

Select를 만나면 기존에 모아놓았던 쿼리들을 수행하기 때문에 C, I, U 작업은 연달아서 할 때 가장 효율적이었다.

트랜잭션과, select문이 끼어드는 위치를 잘 조정하여 사용하면 DB의 부담을 덜 수 있을것으로 보인다.

Batch Processing? - wiki

일괄 처리(batch processing)란 컴퓨터 프로그램 흐름에 따라 순차적으로 자료를 처리하는 방식을 뜻한다.

일괄 처리 시스템(batch system)이란 일괄처리(batch processing) 방식이 적용된 시스템으로서, 하나의 작업이 끝나기 전까지는 다른 작업을 할 수 없다.

장점

많은 사용자 사이에서 컴퓨터 자원을 공유할 수 있다.
작업 프로세스의 시간대를 컴퓨터 리소스가 덜 사용되는 시간대로 이동한다.
분 단위의 사용자 응답 대기와 더불어 컴퓨터 리소스의 유휴 사용을 피한다.
전반적인 이용률을 높임으로써 컴퓨터의 비용을 더 잘 상환하도록 도와 준다.

JDBC에서 Batch Processing

JDBC 2.0는 batch proccessing 은 다음과 같이 제공한다.

1. Prepare statement.

2. Bind parameters.

3. Add to batch.

4. Repeat steps 2 and 3 until interest has been assigned for each account.

5. Execute.

preparedStatement를 사용한 Batch Processing

PreparedStatement stmt = conn.prepareStatement(
    "UPDATE account SET balance = ? WHERE acct_id = ?");"UPDATE account SET balance = ? WHERE acct_id = ?");
int[] rows;

for(int i=0; i<accts.length; i++) {
    accts[i].calculateInterest( );
    stmt.setDouble(1, accts[i].getBalance( ));
    stmt.setLong(2, accts[i].getID( ));
    stmt.addBatch( );
}
rows = stmt.executeBatch( );

addBatch() : create, insert, update, deleted 일괄 처리 결과를 관리 할 필요가 없기 때문에 batch에 statement를 추가하는 일만 한다.
excuteBatch()가 쿼리들을 수행하고 정수형 배열을 리턴하는데, 각 배열의 요소는 각 statement로 인해 update된 row의 숫자이다.

batch모드로 수행할 때 auto-commit을 사용하면 각각의 statement 를 수행 후 commit이 발생한다.

그래서 batch 수행 중 에러가 발생하면 에러 발생 전까지 statement는 DB 에 반영되어있고 BatchUpdateException에서 getUpdateCounts()로 성공한 쿼리의 숫자를 얻어 올 수 있다.

실제 배치 과정에서, 각 statement 마다 commit을 하면 배치의 성능이 떨어지게 되는데 이것을 트랜잭션으로 묶어서 관리하려고 해도 성능에 악영향을 미친다. 가장 좋은 방법은 임의의 수 만큼 statement 를 묶어서, 명시적으로 commit 하는 것 같다.

Mybatis Batch Mode

Mybatis는 SqlSessionFactory에서 SqlSessionTemplate(SqlSession 구현체)을 생성할 때 ExcutorType을 지정해 줄 수 있다.

ExcutorType	Description
SIMPLE	executor does nothing special
REUSE	executor reuses prepared statements
BATCH	executor reuses statements and batches updates

ExecutorType.BATCH : 이 실행자는 모든 update(C,I,U,D)구문을 배치처리하고 중간에 select 가 실행될 경우 필요하다면 경계를 표시한다.

여기서 이 경계는 아래 소스코드를 통해 확인 할 수 있다.

SqlSessionTemplate에서 ExecutorType이 BATCH인 경우에 Create, Insert, Update, Delete 구문은 doUpdate 에서, Select 구문은 doQuery 에서 처리한다.

아래 코드의 59번 줄에서 statement를 재사용하는 로직을 확인 할 수 있고, 61번, 69번 줄에서 statement 재사용 여부에 따라 statementList에 statement를 추가하고 63번, 70번 줄에서 파라미터 추가, 다른 구문일 경우 BatchResult를 추가하는 것을 볼 수 있다.

그리고 doQuery 메소드의 81번줄에서 flushStatements()를 호출 하는데, 이는 그동안 statementList에 쌓아 왔던 statement를 executeBatch() 메소드로 수행한다. 수행 결과는 batchResult에 저장하여 return 하고, 그동안 쌓아왔던 statementList 와 batchResultList 를 초기화한다.

아래 코드처럼 Select문이 실행 될 경우 BATCH 처리를 멈추고 초기화 하기 때문에, BATCH 작업 도중 SELECT 문이 끼어들면 성능이 저하된다.

org.apache.ibatis.executor.BatchExecutor.class - grepcode

40 public class More ...BatchExecutor extends BaseExecutor {
41
42   public static final int BATCH_UPDATE_RETURN_VALUE = Integer.MIN_VALUE + 1002;
43
44   private final List<Statement> statementList = new ArrayList<Statement>();
45   private final List<BatchResult> batchResultList = new ArrayList<BatchResult>();
46   private String currentSql;
47   private MappedStatement currentStatement;
48
49   public More ...BatchExecutor(Configuration configuration, Transaction transaction) {
50     super(configuration, transaction);
51   }
52
53   public int More ...doUpdate(MappedStatement ms, Object parameterObject) throws SQLException {
54     final Configuration configuration = ms.getConfiguration();
55     final StatementHandler handler = configuration.newStatementHandler(this, ms, parameterObject, RowBounds.DEFAULT, null, null);
56     final BoundSql boundSql = handler.getBoundSql();
57     final String sql = boundSql.getSql();
58     final Statement stmt;
59     if (sql.equals(currentSql) && ms.equals(currentStatement)) {
60       int last = statementList.size() - 1;
61       stmt = statementList.get(last);
62       BatchResult batchResult = batchResultList.get(last);
63       batchResult.addParameterObject(parameterObject);
64     } else {
65       Connection connection = getConnection(ms.getStatementLog());
66       stmt = handler.prepare(connection);
67       currentSql = sql;
68       currentStatement = ms;
69       statementList.add(stmt);
70       batchResultList.add(new BatchResult(ms, sql, parameterObject));
71     }
72     handler.parameterize(stmt);
73     handler.batch(stmt);
74     return BATCH_UPDATE_RETURN_VALUE;
75   }
76
77   public <E> List<E> More ...doQuery(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql)
78       throws SQLException {
79     Statement stmt = null;
80     try {
81       flushStatements();
82       Configuration configuration = ms.getConfiguration();
83       StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameterObject, rowBounds, resultHandler, boundSql);
84       Connection connection = getConnection(ms.getStatementLog());
85       stmt = handler.prepare(connection);
86       handler.parameterize(stmt);
87       return handler.<E>query(stmt, resultHandler);
88     } finally {
89       closeStatement(stmt);
90     }
91   }
92
93   public List<BatchResult> More ...doFlushStatements(boolean isRollback) throws SQLException {
94     try {
95       List<BatchResult> results = new ArrayList<BatchResult>();
96       if (isRollback) {
97         return Collections.emptyList();
98       } else {
99         for (int i = 0, n = statementList.size(); i < n; i++) {
100          Statement stmt = statementList.get(i);
101          BatchResult batchResult = batchResultList.get(i);
102          try {
103            batchResult.setUpdateCounts(stmt.executeBatch());
104            MappedStatement ms = batchResult.getMappedStatement();
105            List<Object> parameterObjects = batchResult.getParameterObjects();
106            KeyGenerator keyGenerator = ms.getKeyGenerator();
107            if (Jdbc3KeyGenerator.class.equals(keyGenerator.getClass())) {
108              Jdbc3KeyGenerator jdbc3KeyGenerator = (Jdbc3KeyGenerator) keyGenerator;
109              jdbc3KeyGenerator.processBatch(ms, stmt, parameterObjects);
110            } else if (!NoKeyGenerator.class.equals(keyGenerator.getClass())) { //issue #141
111              for (Object parameter : parameterObjects) {
112                keyGenerator.processAfter(this, ms, stmt, parameter);
113              }
114            }
115          } catch (BatchUpdateException e) {
116            StringBuffer message = new StringBuffer();
117            message.append(batchResult.getMappedStatement().getId())
118                .append(" (batch index #")
119                .append(i + 1)
120                .append(")")
121                .append(" failed.");
122            if (i > 0) {
123              message.append(" ")
124                  .append(i)
125                  .append(" prior sub executor(s) completed successfully, but will be rolled back.");
126            }
127            throw new BatchExecutorException(message.toString(), e, results, batchResult);
128          }
129          results.add(batchResult);
130        }
131        return results;
132      }
133    } finally {
134      for (Statement stmt : statementList) {
135        closeStatement(stmt);
136      }
137      currentSql = null;
138      statementList.clear();
139      batchResultList.clear();
140    }
141  }
142
143}

기타, 참조

용어

SqlSessionTemplate - http://www.mybatis.org/spring/ko/sqlsession.html

SqlSessionTemplate은 마이바티스 스프링 연동모듈의 핵심이다.

SqlSessionTemplate은 SqlSession을 구현하고 코드에서 SqlSession를 대체하는 역할을 한다.

SqlSessionTemplate 은 쓰레드에 안전하고 여러개의 DAO나 매퍼에서 공유할수 있다.

getMapper()에 의해 리턴된 매퍼가 가진 메서드를 포함해서 SQL을 처리하는 마이바티스 메서드를 호출할때 SqlSessionTemplate은 SqlSession이 현재의 스프링 트랜잭션에서 사용될수 있도록 보장한다.

추가적으로 SqlSessionTemplate은 필요한 시점에 세션을 닫고, 커밋하거나 롤백하는 것을 포함한 세션의 생명주기를 관리한다.

또한 마이바티스 예외를 스프링의 DataAccessException로 변환하는 작업또한 처리한다.

SqlSessionTemplate은 마이바티스의 디폴트 구현체인 DefaultSqlSession 대신 항상 사용된다.

왜냐하면 템플릿은 스프링 트랜잭션의 일부처럼 사용될 수 있고 여러개 주입된 매퍼 클래스에 의해 사용되도록 쓰레드에 안전하다.

동일한 애플리케이션에서 두개의 클래스간의 전환은 데이터 무결성 이슈를 야기할수 있다.

참조

Batch Processing - https://ko.wikipedia.org/wiki/%EC%9D%BC%EA%B4%84_%EC%B2%98%EB%A6%AC

Batch Processing(JDBC) - https://www.safaribooksonline.com/library/view/database-programming-with/1565926161/ch04s02.html

Batch Processing(JDBC) - http://www.tutorialspoint.com/jdbc/jdbc-batch-processing.htm

Mybatis3 - http://www.mybatis.org/mybatis-3/ko/index.html

Grep Code(org.apache.ibatis.executor.BatchExecutor.class) - http://grepcode.com/file/repo1.maven.org/maven2/org.mybatis/mybatis/3.2.7/org/apache/ibatis/executor/BatchExecutor.java#BatchExecutor

Spring long polling(Async Servlet) 이용하여 응답지연 서버 만들기

김병규 — Sun, 22 Nov 2015 14:55:18 +0900

1. 개요

서비스에 대용량의 트래픽이 몰리면서, 특정 API 호출에 대한 응답이 지연되면 전체적 로직에 영향을 미치게 된다.

이러한 상황을 재현하기 위해 응답을 늦게 보내는 서버를 구현 하고자 했다.

단순하게 요청을 받고 몇초간의 sleep 후 응답을 돌려주면 간단하게 구현할 수 있지만,

제한된 자원(톰캣 1대)에서 다수(초당 15000명)의 request 를 처리하기 위해서 일반적인 sleep 방법으로는 구현 할 수 없었다.

(성능 이슈가 없다면 이곳 을 참조하면 간단하게 응답 지연 api를 얻을 수 있다.)

2. 문제점

사실, response time은 늦으면서, 다수의 request를 처리한다는 건 역설적인 말이다.

request 가 많을 수록, connection 의 수는 늘어 날 것이고, sleep 을 통해 connection을 놓아주지 않으면 더 이상의 request 를 처리할 수 없기 때문이다.

request 를 위한 connection 비용이 적지 않을 뿐더러, Spring 에서 request 를 처리하기 위한 servlet container thread 자원은 application의 로직을

수행하기 위한 application thread 보다 적고 한정적이다.

3. 해결 방법

Long polling 방식으로 request 에 대하여 늦은 response를 전달하는 방법으로 서버 성능 문제를 해결하고자 했다.

단순히 클라이언트 쪽에서 long polling 방식은 connection을 그대로 유지하고 있기 때문에 문제를 해결 할 수 없는 방식이었고,

서버쪽에서 long polling 을 적용하여 connection 위한 thread 관리가 필요했다.

사실 long polling 방식도 request - response 모델이어서, 서버에서 클라이언트에게 응답을 주기 전까지 connection을

유지하기 때문에 이 방식도 성능 이슈를 해결하기 어려울 것 처럼 보였다.

그러던 중 이러한 long polling의 문제점을 보완하기 위해 Spring 3.2에서 추가된 Async Servlet 기능을 보게 되었다.

Async Servlet는 request 처리를 위한 servlet container thread의 일을 application thread에 위임시키고 servlet container thread를 반납해서

새로운 request 를 처리하는 방식으로 작동한다.

Spring 의 Async Servlet 을 이용하면, 서버의 thread pool 과 acceptCount 값을 조정하여,

제한된 자원에서 다수의 request 를 처리할 수 있을것이라 생각했다.

4. 적용

소스 코드는 Spring-mvc-showcase 를 참조하였다.

(1) 소스

@Controller
@RequestMapping("/async/callable")
public class CallableController {


    @RequestMapping("/response-body-2")
    public @ResponseBody Callable<String> callable() {

        return new Callable<String>() {
            @Override
            public String call() throws Exception {
                Thread.sleep(2000);
                return "Callable result";
            }
        };
    }
}

(2) 결과

응답이 2초 후 온 것을 알 수 있다.

위 로직을 수행하는 동안의 로그는 다음과 같다.

15:23:20 [http-apr-80-exec-9] DispatcherServlet - DispatcherServlet with name 'appServlet' processing GET request for [/async/callable/response-body-2]

15:23:20 [http-apr-80-exec-9] RequestMappingHandlerMapping - Looking up handler method for path /async/callable/response-body-2

15:23:20 [http-apr-80-exec-9] RequestMappingHandlerMapping - Returning handler method [public java.util.concurrent.Callable<java.lang.String> org.springframework.samples.mvc.async.CallableController.callable()]

15:23:20 [http-apr-80-exec-9] DispatcherServlet - Last-Modified value for [/async/callable/response-body-2] is: -1

여기 까지 기존 로직을 따른다

15:23:20 [http-apr-80-exec-9] WebAsyncManager - Concurrent handling starting for GET [/async/callable/response-body-2]

WebAsyncManager(application thread) 에서 병행처리를 시작하고

15:23:20 [http-apr-80-exec-9] DispatcherServlet - Leaving response open for concurrent processing

Dispatcher(servlet container thred) 에서 작업을 끝낸다.

이렇게 작업 쓰레드간 switching 이 이루어지고

15:23:22 [MvcAsync5] WebAsyncManager - Concurrent result value [Callable result] - dispatching request to resume processing

작업을 넘겨받은 MvcAsyc 는 작업을 수행(2초간의 sleep)후 dispatching 을 요청한다.

15:23:22 [http-apr-80-exec-4] DispatcherServlet - DispatcherServlet with name 'appServlet' resumed processing GET request for [/async/callable/response-body-2]

15:23:22 [http-apr-80-exec-4] RequestMappingHandlerMapping - Looking up handler method for path /async/callable/response-body-2

15:23:22 [http-apr-80-exec-4] RequestMappingHandlerMapping - Returning handler method [public java.util.concurrent.Callable<java.lang.String> org.springframework.samples.mvc.async.CallableController.callable()]

15:23:22 [http-apr-80-exec-4] DispatcherServlet - Last-Modified value for [/async/callable/response-body-2] is: -1

15:23:22 [http-apr-80-exec-4] RequestMappingHandlerAdapter - Found concurrent result value [Callable result]

15:23:22 [http-apr-80-exec-4] RequestResponseBodyMethodProcessor - Written [Callable result] as "text/html" using [org.springframework.http.converter.StringHttpMessageConverter@7967f612]

Spring mvc가 callable 을 보고 병행작업임을 알고 나머지 로직을 수행한다.

15:23:22 [http-apr-80-exec-4] DispatcherServlet - Null ModelAndView returned to DispatcherServlet with name 'appServlet': assuming HandlerAdapter completed request handling

15:23:22 [http-apr-80-exec-4] DispatcherServlet - Successfully completed request

5. Servlet container thread 와 application specific thread 의 차이

여기서 servlet container thread 와 application thread 의 차이점을 살펴보자.

servlet thread의 일을 application thread 로 넘겨줌으로 해서 long polling 의 단점을 보완한다고 하는데, 결국 application thread 역시

서버의 자원을 사용하지 않는가? 라는 의문을 가질 수 있다.

Servlet container 란 HTTP Request 와 response 객체를 서블릿에 넘겨주고, 서블릿의 생명주기를 관리한다.

따라서 servlet container thread 는 사용자의 request 를 처리하는 작업을 수행한다.

반면 application는 서비스 자체를 의미하고, application thread는 Spring framework 에서 발생하는 작업들을 수행한다.

이러한 관점에서 보았을때, serblet thread 의 일을 application thread 에 위임하는 것이

많은 request 를 수신하기 위한 효율 적인 방법임을 알 수 있다.

하지만, 결국 한정된 서버의 자원을 공유하여 사용한다는것은 변함이 없다.

spring mvc 내에서 servlet container에 할당 할 thread 수를 조정할 수 있는지 알아보고 최적화가 필요할 것 같다.

6. 결론

서버의 한정된 자원에서 다수의 request 를 처리하는데 한계가 있지만,

서버는 무엇으로 구성할지 (톰캣, 네티, 직접구현)에 따라서, 그리고 서버 환경 설정을 어떻게 하는냐에 따라 동시에 수용할 수 있는 request의 수를 증가 시킬 수 있다.

서버의 설정 이후에는, 어플리케이션의 구현 부분에서 최적화가 필요할 것이다.

고민의 시작은 전자에서 시작했지만, 작업은 후자에서 진행되었다.

다시 서버단으로 돌아가서 고민을 해봐야겠지만, 넉넉한 자원이 주어졌을때, 해당 자원을 제대로 활용하지 못하는 경우

application의 구현부분에서의 최적화 역시 필요할것으로 생각한다.

결과적으로 Async Servlet를 이용한 long polling 방식으로 서버에 요청할 수 있는 최대 request 를 늘리는 것은 실패하였다.

추가적으로 서버의 최적화 또는, tomcat 에 comet 을 적용, 심플한 구조의 서버 구축과 같은 작업이 병행되어야 할 것으로 보인다.

Flyway 개념 & 사용법

김병규 — Thu, 5 Nov 2015 10:38:58 +0900

Flyway?

데이터베이스 형상관리 툴.

로컬에서 변경한 데이터베이스의 스키마나 데이터를 운영 데이터베이스에 반영하는 것을 누락하는것을 막기 위해 사용한다.

또한 개발 DB와 운영 DB의 스키마를 비교하거나, 운영 DB에 수작업을 가하는 노가다와 위험성을 줄이기 위해 사용한다.

생성한 형상을 새로운 DB에 적용하면 그게 마이그레이션이다.

동작방식

Flyway 가 연결된 데이터베이스에 자동으로 SCHEMA_VERSION 이라는 메타데이터 테이블을 생성한다.

Flyway 는 사용자가 정의한 sql의 파일명을 자동으로 스캔하여, SCHEMA_VERSION 에 버전 정보를 남기는 동시에,

데이터베이스에 변경내용을 적용한다.

SCHEMA_VERSION 테이블에는 다음과 같은 정보를 담고 있다.

명령어 설명

init - SCHEMA_VERSION 을 baseline 과 함께 생성한다. 테이블이 이미 생성되어 있으면 수행되지 않는다.

migrate - 스키마정보를 리얼DB에 마이그레이션한다.

clean - flyway로 생성한 스키마를 모두 삭제한다고 하지만, 해당 데이터 베이스의 모든 테이블을 삭제한다.

info - DB에 적용된 스키마 정보와, 로컬에 pending 되어있는 변경 정보를 보여준다.

validate - DB에 적용된 스키마 정보와, 로컬의 변경점을 비교하여 보여준다.

repair - 마이그레이션 실패한 내역을 수정한다 (삭제, 교체)

baseline - flyway로 형상 버전관리를 시작 할 baseline 을 설정한다.

Command-line tool 로 예제 실행

(1) 설치

http://flywaydb.org/getstarted/firststeps/commandline.html

(2) 설정

설치 폴더 -> conf -> flyway.con 파일 수정 (C:\flyway\conf\flyway.conf)

flyway.url=jdbc:mysql://localhost:3306/테이블명
flyway.user=아이디
flyway.password=비번

(3) 마이그레이션 sql문 생성

설치 폴더 -> sql (C:\flyway\sql) 에 파일 생성.

init을 이용하여 SCHEMA_VERSION 테이블을 생성하면 V1 로 생성되기 때문에 파일명을 V2 로 생성함.

V2__Create_person_table.sql
create table PERSON ( ID int not null, NAME varchar(100) not null );create table PERSON ( ID int not null, NAME varchar(100) not null );

V2.1__Insert_person.sql
insert into PERSON (ID, NAME) values (1, 'Axel'); insert into PERSON (ID, NAME) values (2, 'Mr. Foo'); insert into PERSON (ID, NAME) values (3, 'Ms. Bar');

파일명은 V 와 숫자로 버전명을 지정하고 under_bar 두개로 시작되어야한다. 이미지참조.

(4) flyway init 명령문 수행

flyway init 없이 migrate를 수행하면, 자동으로 schema_version이 생성된다.

flyway init 을 수행하면 결과 화면과 같이 baseline 이 V1 로 입력되어있는것을 확인 할 수 있다.

명령문 수행화면

데이터베이스 적용 결과

(5) flyway migrate 명령문 수행

flyway가 sql 파일들을 스캐닝하여 수행한다.

V2 와 V2.1 의 sql 파일이 버전 순서대로 수행된 것을 확인 할 수 있다.

명령문 수행화면

데이터베이스 적용결과

(6) 마이그레이션 sql문 추가 생성

V2.2__Insert_another_person.sql
insert into PERSON (ID, NAME) values (5, 'CLEAN!!!!');

(7) flyway validate 명령문 수행

migrate 없이, flyway validate 를 수행하면 새로 추가한 쿼리문에 실제 DB에 적용되어 있지않기 때문에,

fail이 떨어진다.

명령문 수행화면

(8) flyway info 명령문 수행

flyway info 로 내용을 확인해 보면 2.2 버전의 파일이 pending 상태인것을 알 수 있다.

명령문 수행화면

(9) flyway clean 명령문 수행

flyway clean 을 수행하면 y/n 질문도 없이 데이터베이스의 모든 테이블들이 드랍된다.

flyway로 작업된 테이블만 드랍된다는 말이 있는데, 아니다 모두 드랍된다.

명령문 수행화면

생각

전체적으로 사용하기 쉽고 대부분의 툴과 연동이 가능한 것이 장점.

데이터 베이스의 스키마 변경 이력을 확인 할 수 있다는 점이 가장 좋았음.

각자 로컬 데이터 베이스를 이용하여 개발하지 않으면 형상관리와 마이그레이션의 의미가 약해짐.

개발 DB 를 따로 운영함으로서, 작업중 스키마 변경에 따른 이슈가 발생 할 수 있지만,

스키마 이력관리를 위해, Flyway 를 적용하는 것은 오버스팩이라고 생각함.

데이터베이스의 스키마를 변경하면 이력을 남기는 워크벤치쪽 플러그인이 있으면 좋겠다고 생각함.

참조

http://flywaydb.org/

FUSE 를 이용하여 카메라 연동 테스트 앱 만들기

김병규 — Thu, 5 Nov 2015 10:38:01 +0900

1.목적

FUSE 를 이용하여 Native Camera에 접근하여 사진을 찍고, 보여주고, 저장하는 앱을 만든다.

2. 알아야 할 것

현재 FUSE 는 배타 환경으로 오픈하였기 때문에 NATIVE API가 빈약한 상태이다.

구현에 들어가기 전 FUSE 에서 제공하는 API의 스펙을 확인하는 것을 추천한다.

사용하려고 했던 API스펙

(1) Camera - https://www.fusetools.com/learn/fusejs#camera

Native Camera를 호출할 수 있는 API 다.

제공하는 함수는 takePicture 가 유일한데, 전달 값으로 너비와 높이, 방향이 있다.

그러나 직접 구현해본 결과 전달 값과 상관없이 기본 카메라의 앵글로 촬영되었으며,

이미지 생성도 기본 카메라와 동일한 크기로 작동하였다.

(2) Storage - https://www.fusetools.com/learn/fusejs#storage

Camera API 로 생성한 이미지를, 안드로이드 이미지 폴더에 복사(이동) 하기 위해 사용하려 했었던 API다.

하지만 상세 스펙을 보면

'The storage API allows you to save text to files in the application directory.'

라고 한다. 이미지를 저장해보려 테스트를 해보니, 에러를 뱉진 않았지만, 결과값이 에러 값을 저장하고 있었다.

Camera로 생성한 이미지를 따로 저장하기 위해서는 다른 방법을 찾아봐야 할 것 같다.

3. 구현

(1) 화면 구성

ui구현이 목적이 아니기 때문에, FUSE 에서 제공한 Slides using PageControl 예제를 수정하여 화면을 구성하였다.

Style 과 assets 들은 예제와 같기 때문에 MainView.ux 코드만 첨부한다.

MainView.ux

<App Theme="Basic" Background="#fff">
<DockPanel>
<MainStyle />
<Page>
<Info>
<Header>
<Text TextColor="#a94442" Value="{myfilePath}" Alignment="Center" />
<Text TextColor="#a94442" Value="{errorMessage}" Alignment="Center" />
</Header>
<Button Text="Take a photo!!" ux:Name="button1" Clicked="{myTakePicture}" />
<Button Text="Save a photo!!" ux:Name="button2" Clicked="{mySavePicture}"/>
</Info>
<BackgroundImage File="{myfilePath}" />
</Page>
</DockPanel>
</App>

(2) Camera 연동

카메라 촬영 후, 화면에 표시하기 위해 Observable API와 함께 작성하였다.

Camera.takePicture 의 너비와 높이 값은 결과물에 영향을 주지 못했고, takePicture 가 리턴해주는

file 객체에서 path 를 꺼내 myFilePath 에 연결하였다.

(file 객체를 이용하여 storage 에 저장하려 했으나, 실패하였다.)

2,3번 줄에서 사용할 객체 선언.

8번째 줄에서 takePicture 함수 선언.

16,19번 줄에서 모듈에 등록.

MainView.ux

<App Theme="Basic" Background="#fff">
<JavaScript>
var Observable = require("FuseJS/Observable");
var Camera = require('FuseJS/Camera');
var myfilePath = Observable();
var myTakePicture = function() {
Camera.takePicture({ targetWidth: 640, targetHeight: 360}).then(function(file) {
myfilePath.value = file.path;
}).catch(function(e) {
console.log(e);
});
}
module.exports = {
myfilePath: myfilePath,
myTakePicture: myTakePicture
};
</JavaScript>
<DockPanel>
<MainStyle />
<Page>
<Info>
<Header>
<Text TextColor="#a94442" Value="{myfilePath}" Alignment="Center" />
</Header>
<Button Text="Take a photo!!" ux:Name="button1" Clicked="{myTakePicture}" />
</Info>
<BackgroundImage File="{myfilePath}" />
</Page>
</DockPanel>
</App>

(3) 테스트

초기화면

촬영 후 화면

사진 아래에 파일 경로가 출력된 것을 볼 수 있다.

파일 저장 경로 확인

Android > data > 앱이름 > files 에 이미지가 저장 된 것을 확인할 수 있다.

4. 정리

카메라 호출 속도가 기존의 하이브리드 앱 툴에 비해 눈에 띄게 빨라서 놀랐다.

베타 환경이라는 점을 고려하면, 앞으로 하이브리드 앱을 개발하는데 있어서 점유율이 올라갈 것 같다.

아직 Native filesystem 을 이용할 수 있는 API 가 부족하여 촬영한 이미지를 갤러리 폴더로 옮기지 못했지만

기본이 되는 기능이므로 Fuse tools 에서 빠른 시일 내에, 업데이트할 것으로 예상한다.

이미지를 활용한 앱을 개발하기 위해서는 당분간 촬영한 이미지를 서버에 저장 가공 후, 제공해주는 형태로

개발을 진행하는 것이 좋겠다.

※작성 코드 중 개선할 부분이나, 틀린 부분 지적해주시면 감사히 반영하도록 하겠습니다.

5. 참조

https://www.fusetools.com/

어쩌다, 블로그

[2편] 개발 7년차에서 매니저 3년차로(개발팀 7명에서 33명이 되기까지)

들어가면서

마주하고 나아가야 할 길

마치면서

[1편] 개발 7년차에서 매니저 3년차로(개발팀 7명에서 33명이 되기까지)

들어가면서

피하고 돌아가야 할 길

마치면서

[애자일로 빅픽처를 그리다] 데이터 대시보드 #2

들어가면서

대시보드 추가

고객군 분리 & 유저 획득 경로 상세화

구글 데이터 대시보드에 새로운 데이터 소스 추가

A/B테스트 환경 추가

데이터 대시보드를 구축하면서 어려웠던 부분

다음 단계

[애자일로 빅픽처를 그리다] 데이터 대시보드 feat. GA4

들어가면서

애자일을 위한 데이터 대시보드?

기존 데이터 대시보드의 아쉬웠던 부분

새롭게 추가된 데이터 대시보드

마무리

Spring Batch 와 Jekins 를 이용하여 간단한 배치 환경 구성하기

개요

구현

결론

Spring batch의 transaction manager bean 중복 문제 해결하기 (feat Spring boot 2.1)

문제

해결 시도

Bean Overriding

결론

R3와 Corda의 탄생배경

모바일 청첩장 공개 (Parallax scrolling, skrollr.js)

개요

개발

중앙 거래소 호가 매칭 알고리즘 설계

개요

Redis 살펴보기

설계

필요한 자료구조

동작 시나리오

예외 처리

암호화폐 거래소 구축을 위한 주문 매칭 알고리즘 분석 #1

개요

결론

본문

비트코인 거래소 프로젝트 파트 2: 주문 매칭 알고리즘

요약

본문

Java Garbage Collection 요약

Garbage Collection

STW (Stop-The-World)

Garbage Collector

Young Generation 영역의 구성

Old Generation의 GC

Serial GC (-XX:+UseSerialGC)

Parallel GC (-XX:+UseParallelGC)

Parallel Old GC(-XX:+UseParallelOldGC)

CMS GC (-XX:+UseConcMarkSweepGC)

G1 GC

GC 방식 보충

Parallel GC

CMS GC

GC를 줄이기 위한 JVM 튜닝

안드로이드 빌드 서버 구축하기 - Centos7, Jenkins, Sdkmanager

안드로이드 SDK설치

sdkmanger 설치 & 경로 설정

sdkmanger로 sdk 다운로드

[bkim@server android]$ lsbuild-tools licenses output platforms platform-tools tools

깃 설치

젠킨스 세팅

젠킨스 설치

환경변수 설정

플러그인 설치

빌드 테스크설정

마치며

Maven vs Gradle

Maven vs Gradle

Maven

[bkim@server android]$ ls
build-tools licenses output platforms platform-tools tools