지난 10월 20일, 비트윈 PC 버전의 오픈 베타 테스트를 시작했습니다. PC 버전 덕분에 컴퓨터 앞에서 일과 시간을 보내는 직장인들도 편리하게 비트윈으로 연인과 대화할 수 있게 되었습니다. 이 글에서는 PC 버전에 어떤 기술이 사용되었는지 소개하고 약 4개월의 개발 기간 동안 겪은 시행착오를 공유합니다.비트윈 PC 버전 스크린샷개발 플랫폼 선택PC 버전 개발을 본격적으로 시작하기 전에 어떤 개발 플랫폼을 선택할 것인지 많은 고민을 했습니다. MFC나 WinForms 같은 네이티브 플랫폼, Qt 등의 크로스 플랫폼 라이브러리, 그리고 웹 기반 앱 등의 여러 후보를 가지고 토론을 거쳐 웹 앱으로 개발하기로 했습니다.웹 기반으로 개발하게 된 가장 큰 이유는 생산성입니다. PC 버전 팀이 웹 기술에는 이미 익숙하지만 다른 플랫폼은 경험이 많지 않았습니다. 또한, 비교적 자유롭게 UI를 구성할 수 있으며 기존의 각종 개발 도구를 이용하면 빠른 이터레이션이 가능할 것으로 예상했습니다.단, 사용자가 기존에 설치한 웹 브라우저를 통해 접속하는 방식이 아니라 브라우저 엔진을 내장한 실행 파일을 배포하는 방식을 택하기로 했습니다. 여러 브라우저 환경에 대응하지 않아도 되고, 브라우저에서 지원하지 않는 일부 시스템 기능을 직접 확장해서 사용할 수 있기 때문입니다.서버 아키텍처의 변화비트윈 서버의 서비스 로직은 Thrift 서비스로 구현되어 있습니다. 그리고 Alfred라는 자체 개발 라이브러리를 사용하여 Thrift 서비스를 Netty 기반의 서버로 구동합니다.기존의 비트윈 모바일 클라이언트는 채팅 서버와 Thrift의 바이너리 프로토콜로 통신하고 있습니다.1 그러나 웹 플랫폼에서는 서버와 지속적으로 양방향 연결을 유지하려면 WebSocket 프로토콜을 사용해야 하므로 Alfred에 WebSocket 프로토콜 지원을 추가하였습니다. 애플리케이션이 아닌 라이브러리 수준의 변화였기 때문에 기존 서비스 코드에 영향을 거의 주지 않고 새로운 프로토콜을 지원할 수 있었습니다.Alfred에 웹소켓 지원을 추가하였습니다.비트윈 PC 버전 셸비트윈 PC 버전은 크게 HTML과 자바스크립트로 작성된 웹 앱 부분과 웹 앱을 브라우저 엔진으로 구동해주고 플랫폼 API를 제공하는 셸 (Shell) 부분으로 구성되어 있습니다.비트윈 PC 버전 구조PC 버전 셸은 Chromium Embedded Framework (CEF)를 사용합니다. 이름에서도 알 수 있듯이 Chromium 브라우저 엔진을 애플리케이션에 내장하기 쉽도록 감싸놓은 라이브러리입니다. CEF는 Evernote나 Steam 등 웹 브라우저를 내장한 애플리케이션에서 널리 사용되고 있어 선택하게 되었습니다.2자바스크립트에서 셸이 제공하는 플랫폼 API를 호출할 때는 CEF의 Message Router를 사용하였습니다. Chromium은 멀티 프로세스 구조로 이루어져 있어, 렌더 프로세스에서 작동하는 자바스크립트 코드가 브라우저 프로세스에서 작동하는 C++ 코드를 호출하고 결과를 돌려받기 위해서는 별도의 처리가 필요합니다. Message Router는 이 두 프로세스 사이의 비동기 통신을 지원합니다. 이를 통해 창 투명도 조절이나 트레이 알림 표시 등 원래는 웹 플랫폼에서 지원하지 않는 기능을 확장하여 지원할 수 있었습니다.CEF에서는 Chrome 개발자 도구를 사용할 수 있어 디버깅이 용이했고, 디자이너 옆에서 바로바로 좌표나 색상 등을 바꿔볼 수 있어 협업에도 도움이 되었습니다.그러나 PC 버전을 개발하면서 가장 많은 시행착오를 겪은 부분이 CEF를 다루는 것이었습니다.문서화가 잘 되어있지 않습니다. 그래서 실제 작동 방식을 확인하기 위해 직접 소스 코드를 읽어야 하는 경우가 많았습니다일반적인 웹 브라우저에서는 잘 작동하는 API를 CEF가 자원하지 않거나 버그가 있어 다른 방식으로 구현해야 할 때가 있습니다.CEF에 노출된 API에만 접근할 수 있어 Chromium에서 제공하는 플랫폼 추상화 레이어를 활용할 수 없었습니다.비트윈 PC 버전 웹 앱비트윈 PC 버전의 주요 애플리케이션 코드는 HTML과 자바스크립트로 작성되어 있습니다. 자바스크립트로 큰 규모의 애플리케이션을 작성할 때 발생하는 여러 가지 어려움을 피하고자 React 라이브러리 및 최신 자바스크립트 기술을 적극적으로 활용하였습니다.ReactReact는 Facebook에서 개발한 오픈 소스 자바스크립트 UI 라이브러리입니다. 일반적인 웹사이트보다는 비교적 복잡한 인터페이스를 구현해야 했기 때문에 jQuery처럼 간단한 라이브러리로는 부족할 것으로 생각하여 비트윈 PC 버전은 처음부터 React를 사용하였습니다.전통적인 개발 방식에서는 UI를 변경해야 할 때 기존에 렌더링 된 DOM 요소에 명령을 내립니다. 예를 들어 어떤 항목을 삭제하려면 그 요소를 찾아서 삭제 명령을 내리게 됩니다. React를 사용할 때는 이와 달리 해당 요소가 사라진 DOM 트리 전체를 다시 생성하면 React가 이전 트리와 새 트리를 비교하여 바뀐 부분만 반영해줍니다. 전체를 다시 렌더링하기 때문에 기존에 DOM 트리가 어떤 상태였는지 신경 쓰지 않고도 원하는 상태로 쉽게 변경할 수 있어 UI 코드의 복잡도를 줄일 수 있습니다.또한, React의 컴포넌트 시스템은 독립적인 UI 요소들을 서로 영향을 주지 않고 조합할 수 있도록 해주어, 한가지 컴포넌트를 수정했을 때 의도하지 않은 다른 컴포넌트와 간섭하는 문제가 적게 발생합니다. 비트윈 PC 버전에는 약 40가지의 React 컴포넌트가 쓰이고 있습니다.자바스크립트 모듈 시스템모든 코드를 한 파일에 넣으면 코드를 관리하기가 힘들어집니다. 따라서 서로 관련 있는 코드끼리 모듈로 나누어야 하는데, 자바스크립트에는 모듈 시스템이 기본적으로는 제공되지 않습니다. 비트윈 PC 버전에서는 CommonJS 표준을 따라서 모듈을 나누고, 이를 웹 브라우저가 해석할 수 있는 형태로 합쳐주는 Webpack 빌드 툴을 사용했습니다.Webpack은 자바스크립트뿐만 아니라 CSS나 이미지, JSON 파일 등도 모듈로 취급할 수 있고, 플러그인으로 지원하는 모듈 종류를 추가할 수 있습니다. 비트윈 PC 버전을 빌드할 때 실제로 사용하는 플러그인은 다음과 같은 것들이 있습니다.jsx-loader: React에서 사용하는 JSX 코드를 자바스크립트로 변환합니다. 또한, 미래의 자바스크립트 문법을 현재 브라우저에서 지원하는 형태로 변환합니다.less-loader: LESS 파일을 CSS 파일로 변환합니다.css-loader: CSS에서 참조하는 외부 리소스를 인식하여 의존성을 파악해줍니다.url-loader: 파일 크기가 일정 이하인 리소스를 Base64 인코딩으로 내장해줍니다.ECMAScript 6ECMAScript 6는 차기 자바스크립트 표준입니다. 현재 자바스크립트의 불편한 점을 많이 해소하기 때문에 장점이 많이 있습니다. 일부 기능은 이미 브라우저에 구현되어 있지만, 아직 지원되지 않는 기능도 있어서 jstransform을 통해 ECMAScript 5 코드로 변환하여 사용하였습니다.화살표 함수: 익명 함수를 (a, b) => a + b와 같은 문법으로 훨씬 간단하게 선언할 수 있습니다. 또한, this 변수의 스코프를 현재 코드 상의 위치에 따라 결정해줍니다.클래스: 다른 언어와 유사한 클래스 문법을 제공합니다. 상속이나 접근 제한도 가능합니다.해체(destructuring) 대입: 객체의 필드를 바로 같은 이름의 변수에 대입할 수 있습니다. 예를 들어, var {a, b} = {a: 1, b: 2}; 같은 코드를 작성할 수 있습니다.기타 사용된 패키지RSVP.js: Promise/A+ 구현을 제공하는 라이브러리로, Promise 패턴을 사용하여 비동기 로직을 알아보기 쉬운 형태로 작성했습니다.FormatJS: 다국어, 국제화 지원을 위한 라이브러리입니다. UI 메시지 번역이나 날짜, 시간 등의 포매팅에 사용했습니다.정리비트윈 PC 버전은 개발 비용을 줄이기 위해 웹 플랫폼 기반의 네이티브 애플리케이션으로 개발되었습니다.비트윈 서버에서 사용하는 Alfred 라이브러리에 WebSocket 프로토콜 지원을 추가하였습니다.Chromium Embedded Framework를 브라우저 엔진으로 사용하여 웹 앱을 구동하고 웹 플랫폼에서 제공하지 않는 기능을 확장하여 사용했습니다.자바스크립트 코드의 복잡도를 줄이기 위해 React, CommonJS, ECMAScript 6 등의 기술을 활용하였습니다.VCNC Engineering Blog, 비트윈 시스템 아키텍처, 2013년 4월↩Wikipedia, Chromium Embedded Framework - Applications using CEF↩

영화 같은 일들이 매일같이 벌어지는 요즘 모두들 안녕하신가요?해외송금 스타트업 모인에게 최근 새로운 변화가 생겼습니다.안드로이드 개발자가 합류했습니다.어떤 분인지 지금부터 소개 해드리겠습니다 ^^안드로이드 개발을 해주실 효찬님!- Professional Experience -2015.01~2016.10 kt R&D 연구개발센터 전임연구원2013.07~2015.12 kt R&D 연구개발센터 연구원2013.03~2013.06 kt R&D 연구개발센터 인턴- Education -2006.03~2013.08 고려대학교 컴퓨터통신공학부 학사2001.09~2005.05 Jakarta International School▶ 모인에서 어떤 일을 담당하고 계신가요?총체적인 안드로이드 개발과 웹 서버를 보조하는 일을 맡고 있습니다.▶ 개발자가 되겠다고 한 계기가 궁금합니다. 개발자로서 이력에 대해 간략히 설명해주시겠어요? 특정한 계기가 있어서 개발자가 되겠다고 한 건 아니었어요. 고등학교 시절, 컴퓨터 게임 하면서 막연히 나도 게임을 만들어 보고 싶다고 생각했고 그래서 관심은 가지고 있었죠. 친구들 이름 넣어서 RPG를 만들어보기도 했는데, 생각해보면 스토리 만들기가 재밌었던 거 같아요. 그러면서 자연스럽게 어떻게 하면 컴퓨터 개발할 수 있나 생각도 해보게 됐고, 책도 뒤적여보게 됐습니다. 이런 생활이 고2때까지 이어졌어요. 그런데 마땅히 공부할 수 있는 방법이 없어서 대학가서 해야겠다 생각했습니다. 대학 와서 본격적으로 컴퓨터공학을 공부하면서 재미를 느끼게 됐어요.▶ 그 중에서도 안드로이드 개발을 선택하게 된 이유는 뭐였을까요?예전에 KT에 있을 때, 안드로이드 개발 프로젝트를 맡으면서부터입니다. 원래 이 분야에 대해 전혀 몰랐는데 회사에서 3일간 안드로이드 개발 교육을 받고 해보라는 지시를 받게 된거죠. 막상 해보니 재밌었어요. 특히 이 시기가 2014년 초였는데, 당시에는 안드로이드가 워낙 인기 있는 분야여서 더욱 할만하겠다는 생각을 하게 됐습니다. 효찬님이 선보인 안드로이드 앱 (왼부터)가계부투게더, 메모캐스트, 돈테크 ▶ 본격적으로 모인에 들어오게 된 이야기를 들어보고 싶습니다. 어떻게 모인을 알게 되셨나요?이전 회사에서 늘 입버릇처럼 ‘스타트업을 하고 싶다’는 말을 하고 다녔습니다. 생각해보면 제가 굉장히 밉상이었을텐데 주변 회사분들이 응원을 많이 해주셨어요. 정말 좋으신 분들입니다. (하하) 지인 추천으로 원티드를 알게 됐어요. 저는 초기 단계에 있는 스타트업에 가고 싶었는데 쉽게 찾기는 힘들더라고요. 이후 설립한지 1년도 안 된 ‘모인’을 찾게 됐습니다. 회사에 대해 이것저것 찾아보고 한 번 만나서 이야기해보면 좋겠다는 생각이 들어 대표님을 만났어요. 대표님과 만나 이야기를 나누어 보니 같이 일하고 싶었습니다.  ▶ ‘스타트업을 하고 싶다’는 말을 입버릇처럼 하셨다고 했는데, 특별한 계기가 있었나요?대학 때, 그래픽 프로그래밍 관련 Term Project를 수행했던 적이 있었어요. 이 때 친구들과 밤을 새면서도 웃고떠들며 프로젝트를 해낸 게 제겐 정말 좋은 경험이었습니다. 친한 친구들과 같이 일을 하면 힘든 업무도 웃으면서 즐겁게 할 수 있다는 생각이 들었어요. 앞으로도 좋은 사람들과 같이 즐겁게 일할 수 있으면 좋겠다는 생각을 가지게 되었죠. 스타트업에서 근무하면 일과 동시에 좋은 조직문화를 만들어나갈 수 있을 거라고 생각했어요.  ▶ 개발자로서 자신 있는 영역이 무엇인가요?두루 다룰 줄 안다는 게 제 장점일 수 있겠네요. 그래서 스스로 찾아가면서 어떤 서비스든 개발할 수 있다는 자신이 있습니다. 하지만 역시 한 분야에 대한 전문성은 좀 부족하지 않나 생각해요. 안드로이드에 더더욱 집중해보려고 노력한 이유이기도 합니다. 앞으로도 저만의 차별점을 발굴하는데 계속 노력을 기울일 생각입니다. 효찬님이 가장 애착간다는 원피스 '상디'▶ 개발 외 관심 있는 영역이 무엇인가요?개발 외적으로는 조직 문화에 관심이 많습니다. 제가 개인적으로 일본 만화 ‘원피스’를 좋아해요. 루피 해적단을 보면 개개인이 발전하면서 동시에 팀이 강해지는 모습을 볼 수 있거든요. 어떠한 모험도 할 수 있을 정도로 강해지죠. 루피 해적단 같은 조직을 꿈꿉니다. 어떻게 보면 제가 꿈꾸는 조직 문화가 담겨있다고도 할 수 있죠.특히, 배트맨을 보면 악당이 배트맨 지인을 인질로 잡으면 배트맨은 지인을 구하러 가죠. 하지만 원피스에서는 악당이 루피 친구들을 인질로 잡으면 루피는 친구를 구하러 가지 않아요. 다만, 친구가 함정에서 알아서 잘 나올거라 믿습니다. 그리고 악당을 쓰려트려야 하는 자신의 역할을 수행하는 데 충실해요. 동료를 믿기 때문에 가능한 자세라고 생각해요. 제 나름대로 ‘믿음의 리더십’이라고 혼자 정의해봤어요. (웃음) 대신 내 능력은 스스로가 키워나가야 하죠. 이렇게 각자 자신의 일에 최선을 다하는 사람들과 함께 큰 꿈을 이루는 게 지금 제게 마지막으로 남아 있는 순수한 이상입니다.▶ 더 키워나가고 싶은 역량이 있나요?역량이라기 보다는 제가 만든 작품을 Developing 해나가고 싶어요. 발전가능성이 없는 서비스는 더 이상하고 싶지 않습니다. 내가 만든 앱을 상용화 시키고, 고객들이 반응하는 걸 직접 보고 싶어요. 더불어 서비스 개선에 필요한 역량은 지속적으로 키워나가려고 합니다.장효찬 개발자에게 '함께 일하고 싶은 사람'이란?#온정 #진솔 #파이팅 ▶ 출근한지 일주일도 안됐지만 (웃음) 모인에 대한 첫인상은 어땠어요?정말 아직 1주일도 안됐는데…. (웃음) 대기업에 있다 와서 그런지 소위 ‘젊음의 열정’이라고 하죠? 다들 파이팅 넘치는 모습이 좋았습니다. 그러면서 동시에 나 잘났다고 으스대지도 않고, 특히 대표님 같은 경우는 능력도 있으신데, 겸손하기까지 해서 반했어요. 무언가를 물어보면 설명도 친절하면서 꼼꼼하게 해주시구요. 팀워크가 좋을 거 같다는 긍정적인 예감이 들었어요. 사람 뽑는 데 신중하시다는 대표님을 믿으며, 앞으로도 잘 부탁드립니다.  ▶ 앞으로 어떤 개발자가 되고 싶으신가요? 모인에게도 한마디 해주세요.개발 PM(Project Manager)에 관심이 많습니다. 사실 앱 구현보다 뼈대를 구축하는 일이 더 중요하다고 생각해요. 저는 이 부분이 개발에서 30% 혹은 그 이상을 오롯이 혼자 차지하고 있다고 생각해요. 그러기 위해서는 리소스나 구현한 코드를 어떻게 관리할까, 어떤 부분을 어떻게 더 추가를 해서 연동시킬 수 있을까 등을 서비스 앱 전체를 보고 관리할 줄 알아야 하죠. 이 역할이 국내에서는 중요하게 다뤄지는 거 같지 않아 안타깝습니다. 대부분 보이는 것에만 관심을 가지고 제품이 어떤 제질로 만들어졌는지는 큰 관심을 가지지 않는 추세거든요. 저는 이러한 부분을 중요시 여기는 개발자가 되고 싶습니다. “저를 버리시면(?) 아니됩니다 (웃음)”- 장효찬이 꼽은 인생 명언 -“Do what you love. Everything else is secondary”by. Steve Jobs#모인 #MOIN #개발자 #개발팀 #안드로이드개발자 #안드로이드 #팀원 #팀원소개 #팀원인터뷰 #인터뷰 #기업문화 #사내문화 #조직문화

블록체인에서 PoW는 Proof of Work, 즉 작업증명을 말합니다. 블록체인의 암호화된 작업에 대해 참여자가 암호를 풀면, 보상을 제공받는 것이죠.오늘은 코인원의 PoW에 대해서 이야기 해보려고 합니다. '코인원 PoW'의 PoW는 블록체인을 기반으로 금융을 혁신하는 기업답게 블록체인 용어에서 차용했어요. :-)  코인원 크루들이 스스로와 동료들의 회고를 진행하고 피드백을 주고 받는 과정을 통해, 업무 개선과 성과에 대한 보상을 제공받도록 만들어진 일종의 성과관리 시스템이죠. 코인원 피플팀은 코인원 PoW 과정을 다음과 같이 설명하고 있습니다.크루들이 자신들의 업무 성과에 대해 투명하게 풀어놓는 회고를 우선적으로 진행해요. 그 후 함께 업무를 진행한 페어 그룹(pair group)끼리 서로 잘된 업무와 지원이 필요한 부분에 대해 대화를 진행하며, 이를 통해 개선점과 방법을 찾아 업무에 적용합니다.코인원 PoW의 특별한 점은, 대부분의 과정이 정성적으로 진행된다는 것에 있습니다. 물론 숫자로 보이는 결과도 중요하지만, 모든 일은 결과 못지 않게 과정도 중요하다고 판단했기 때문이에요. 그 과정에 충실함을 보인 크루들을 선별해 ‘슈퍼크루'로 지정하고 보상을 제공하는 과정도 여기에 포함됩니다. 이 변화무쌍한, 그리고 결코 쉽지 않은 크립토(crypto) 세계에서 ‘정도'를 걸어가고 있는 ‘코인원스러운' 성과관리 시스템이 아닐까 생각합니다. :-) 우선 코인원 PoW가 어떤 과정으로 진행되는지 한 번 살펴볼까요? 코인원 PoW는 아래와 같은 5가지 단계로 진행됩니다.Self mining셀프마이닝은 지난 6개월 동안 자신이 진행한 업무와 그 과정에 대해 에세이를 작성하는 단계입니다. 에세이를 작성할 때는 자신이 진행한 업무와, 업무를 진행하는 과정에서 본인이 생각하는 잘한 부분 및 아쉬웠던 점들 등에 대해서 작성합니다. ‘잘한 부분'의 경우, 성과가 좋았던 점 외에 성과는 좋지 않았어도 최선을 다한 것에 대해 상세히 작성합니다. Peer mining피어마이닝은 업무적으로 연관된 동료 크루의 셀프마이닝을 토대로 그 동료에 대한 의견을 작성하는 단계입니다. 함께 일했을 때 동료 크루의 좋았던 점, 훌륭한 점, 배워야 할 점 등을 서술하고, 앞으로 더 효율적인 협업을 위해 동료가 개선하면 좋을 것 같은 점도 함께 작성해요. Segwit세그윗 단계에서는 위 두 단계에서 도출된 자기 평가와 동료 평가를 토대로 각 셀의 리더들과 1:1 면담을 진행합니다. 이때 셀 리더들이 꼭 염두해야 하는 것은, 코인원 PoW를 통해 우리가 이끌어내고자 하는 것은 '평소의 관심과 피드백, 그리고 동반 성장'이라는 것이죠. Blue paper세그윗을 통해 최종 작성되는 것이 바로 블루페이퍼에요. 크루들의 면담을 진행한 각 셀의 리더들이 작성하죠. 이 내용은 크루들이 지난 6개월 동안 한 일에 대한 자기 자신과 동료, 그리고 셀 리더의 피드백이 담긴 한 장의 문서죠. Consensus마지막으로 컨센서스 단계에서는 최종 완성된 블루페이퍼를 바탕으로 본부별 슈퍼크루를 선정합니다. 그리고 이렇게 선정된 슈퍼크루에 대해 전체 크루가 동의 가능한지에 대한 적절성 심사가 한 번 더 진행됩니다. 현재 코인원에는 약 120명의 크루들이 일하고 있어요. 사실 모든 크루들의 정성적인 분석 과정을 진행하는 것이 쉬운 일은 아니에요. 코인원 PoW는 셀프마이닝부터 블루페이퍼 작성 및 슈퍼크루 선정까지 약 5주에 걸쳐 진행되는, 길지만 자연스러운 평가와 이를 통한 성장의 과정이라고 생각합니다.이 과정에서 코인원 피플팀 여러분들이 정말 많은 노력과 정성을 기울여주고 계시죠!그렇게 10월의 어느 날, 2018년 상반기의 코인원 PoW가 성공적으로 마무리가 됐습니다. :-)코인원의 모든 크루들이 지난 상반기의 업무에 대해 작업증명을 진행했죠! 그리고 또 다른 6개월 동안 앞으로 다시 힘차게 나아가기 위해 자신의 어떤 좋은 점을 강화하고, 어떤 점은 보완하면 될지를 나 자신, 그리고 동료 크루들과 공유하는 시간이었습니다.또, 이렇게 진행된 2018년 코인원 PoW를 통해 여섯 명의 슈퍼크루가 탄생했어요!2018 코인원 슈퍼크루를 소개합니다 :-)올 한해도 모든 크루가 각자의 분야에서 최선을 다했어요.슈퍼크루는 그 중에서도 특히 다른 크루들에게 좋은 영향을 준 크루들을 선정한 것인데요, 이 분들에게는 코인원의 특별한 추가 보상이 제공될 예정이랍니다. :-)코인원은 앞으로도 크루들이 즐겁게 일하면서 성장할 수 있는 여러가지 재밌고 유익한 도전들을 해보려고 합니다. 코인원이 크립토 세상에서 어떤 즐거운 도전들을 하고 있는지, 앞으로도 코인원 공식 블로그를 통해 지켜봐주세요! :-)#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트 #기업문화 #조직문화 #사내복지 #업무환경 #팀원소개

안녕하세요. 스티비팀 서버 개발자 이학진 입니다. 저희는 최근 서비스에서 사용 중이던 MySQL DB를 RDS로 이관하는 작업을 진행하였습니다. 무엇 때문에 이관을 결정하게 되었는지와 어떻게 이관을 진행하였는지에 대해 글을 써보도록 하겠습니다.배경stibee.com은 작년 11월에 정식 오픈한 새내기 이메일 마케팅 서비스 입니다. 사실 오픈 초기부터 얼마전까지만 해도 AWS EC2의 m4.large 인스턴스 하나로 운영되던 서비스였습니다.(사실 웹+API 서버 1대, 메일발송서버 1대)그리고 이 싱글 인스턴스에 무려 6개의 서버, mysql 1개, kafka 1개, redis 1개가 돌고 있었습니다. 그럼에도 불구하고 cpu사용률은 20%를 넘지 않았습니다.하지만 최근 사용자도 점점 늘어났고, 네이버에서 메일 수신정책을 변경하면서 메일발송서버에 대한 요청이 급증했습니다.스티비에서 네이버로 대량메일을 발송했을 때 해당 메일의 본문 링크를 자동검사하는 것을 발견했는데요, 따라서 네이버로부터 비정상적으로 많은 요청이 들어오고 있었습니다. (어떤 기준으로 이런 검사를 하는 것인지 정확한 정책은 아직 모릅니다. 담당자분 이 글을 보신다면 연락주세요. 친하게 지냈으면 합니다#슬로워크 #스티비 #개발 #서버개발 #개발환경 #MySQL #인사이트

웹 애플리케이션을 개발할 때 기능적으로는 무관하지만, 사용자에게 인터렉티브하고 심미적으로 예쁜 디자인을 제공하고 싶은 경험이 있을 것입니다. 하지만 막상 직접 구현을 하는 것은 생각보다 시간이 오래 걸리고, 구현하더라도 양질의 UI가 나오지 않는 경우들이 있습니다. 그래서 이번 글에서는 쉽고 빠르게 양질의 UI를 제공해주는 라이브러리를 소개해 드리려고 합니다.Spin.js작업을 완료하거나 페이지가 넘어갈 때 아무런 말도 없이 그냥 기다리는 경우가 있습니다. 이럴 경우 사용자에게 현재 기다리는 중이라는 것을 표현하는 것이 좋습니다. 이러한 기능을 제공해주는 라이브러리가 바로 Spin.js입니다.Spin.js는 위의 그림과 같이 로딩 중이나 무언가를 진행 중이라는 것을 알려주는 사용하기 쉬운 Javascript 라이브러리입니다. 이미지 없이 사용되어 매우 가볍게 사용할 수 있습니다. 그리고 사용할 때 쉽게 설정하여 사용할 수 있으며 대다수 브라우저를 지원합니다.Spin.js / DownloadDatatables많은 양의 정보를 쉽게 볼 수 있도록 테이블로 정리해야되는 경우가 있습니다. 그러나 많은 양의 정보를 처리할 때 쉽게 원하는 정보를 찾을 수 있어야 하고 정보가 쉽게 정렬이 될 수 있어야 합니다. 이러한 기능을 제공해주는 라이브러리가 바로 Datatables입니다.Datatables는 위의 그림과 같이 테이블을 동적인 테이블을 만들어주는 JQuery Javascript 라이브러리입니다. 다양하게 정렬할 수 있도록 테이블을 만들수 있으며, 따로 정보를 찾아주는 기능을 만들어주지 않아도 검색을 할 수 있는 기능을 제공하고, 정보를 편하게 볼 수 있도록 구성을 제공합니다. 그리고 DOM, Ajax, Server-Side Processing으로 쉽게 정보를 Datatables로 만들 수 있습니다.DatatablesCurtain.js긴 내용으로 된 하나의 페이지를 섹션별로 효과적으로 내용을 전환해야 되는 경우가 있습니다. 그러나 사용자에게 혼란을 주지 않으면서 전환 효과를 만들어 내야 합니다. 이러한 기능을 제공해주는 라이브러리가 바로 Curtain.js입니다.Curtain.js는 위의 그림과 같이 마치 커튼이 걷히는 것처럼 내용 전환 효과를 주는 JQueryJavascript 라이브러리입니다. 각 내용을 화면에 고정하고 스크롤이나 키보드를 통해 화면을 전환하여 트렌디하면서 인터렉티브한 느낌을 쉽게 제공할 수 있습니다.Curtain.js / DownloadTurn.js위의 Curtain.js가 세로형태의 전환 효과를 내는 것이었다면 가로형태의 전환 효과를 내야 하는 경우가 있습니다. 이러한 기능을 제공해주는 라이브러리가 바로 Turn.js입니다.Turn.js는 위의 그림과 같이 책장을 넘기는 듯한 내용 전환 효과를 주는 JQuery Javascript 라이브러리입니다. 하나에 페이지를 섹션별로 나눠서 키보드를 통해 화면을 전환하여 책장을 넘기는 느낌을 제공해 스마트폰이나 태블릿에서 책을 읽는 듯한 느낌을 쉽게 제공할 수 있습니다.Turn.js / DownloadGlfx.js이미지를 따로 수정해서 올리는 것이 아니라 웹에서 바로 밝기를 조정하거나 다양한 효과를 주고 싶은 때도 있습니다. 이러한 기능을 제공해주는 라이브러리가 바로 Glfx.js입니다.Glfx.js는 위의 그림과 같이 다양한 효과를 주는 WebGL기반의 Javascript 라이브러리입니다. 이미지에 Blur 효과, 세피아, 밝기 조절, 모자이크처리 등 다양한 효과를 다양한 설정을 통해 쉽게 사용 할 수 있습니다. 그러나 WebGL 기반으로 되어 있어서 WebGL을 지원하는 브라우저만 가능합니다.Glfx.js / DownloadJQuery Tag-it태그를 넣을 때 쉽게 수정 가능하게 하고 자동완성기능을 넣고 싶은 때도 있습니다. 이러한 기능을 제공해주는 라이브러리가 바로 JQuery Tag-it입니다.JQuery Tag-it은 위의 그림과 같이 태그에 대한 JQuery Javascript 라이브러리입니다. 쉽게 태그를 넣고 지울 수 있으며 태그에 대해 자동완성 기능을 지원합니다. 그리고 각 태그에 대해 이벤트를 줄 수 있어서 매우 유용하게 사용하실 수 있습니다.JQuery Tag-it / DownloadTinycon새 글의 개수나 접속자 수에 대한 정보를 사용자에게 알리고 싶은 때도 있습니다. 이럴 경우 브라우저 탭에 정보를 제공하는 경우가 있습니다. 이러한 기능을 제공해주는 라이브러리가 바로 Tinycon입니다.Tinycon는 위의 그림과 같이 파비콘에 동적인 숫자를 통해 정보를 알리는 Javascript 라이브러리입니다. 매우 쉽게 사용할 수 있으며, 설정을 통해 어떤 내용을 숫자로 표현할 것인지를 쉽게 사용자화 할 수 있습니다. 파비콘에 경우 브라우저 탭에 항상 보이기 때문에 아주 유용하게 사용할 수 있을 것 같습니다. 그러나 현재 크롬, 파이어폭스, 오페라 브라우저만이 지원 가능합니다.Tinycon / Download3D GALLERY사진이나 슬라이드 탭을 보여주기 위해 갤러리 공간을 만듭니다. 그래서 좀 더 효과적으로 보여주기 위해 다양한 효과를 넣는 경우가 있습니다. 이러한 기능을 제공해주는 라이브러리가 바로 3D GALLERY입니다.3D GALLERY는 위의 그림과 같이 내용을 3D로 나열해 보여주는 JQuery Javascript 라이브러리입니다. 간단한 설정으로 3D로 배치하고 움직이도록 할 수 있습니다. 그리고 자동으로 내용을 넘어가게 할 수도 있고 다양하게 바뀌는 효과를 줄 수 있습니다.3D GALLERY / Demo글을 마치면서이번 글에서는 UI Component Javascript 라이브러리들에 대해 알아봤습니다. 위의 라이브러리로 좀 더 쉽고 빠르게 양질의 웹 애플리케이션을 개발할 수 있었으면 좋겠습니다.#스포카 #개발자 #디자이너 #협업 #Javascript #라이브러리 #꿀팁 #유용한정보

스포카 개발팀 문성원입니다. 저희는 (익히 아시다시피) 서버를 개발하는데 파이썬(Python)을 사용하고 있는데, 오늘은 이러한 파이썬 코드를 작성할 때 기준이 되는 코딩 컨벤션(Coding Convention)에 대해서 알아보겠습니다.Coding Convention코딩 컨벤션이란 개념에 대해 생소하신 분들도 계실 테니 이를 먼저 알아보죠. 코딩 컨벤션은 프로그램 코드를 작성할 때 사용되는 일종의 기준입니다. 이를테면 들여쓰기(Indentation)는 공백으로 할거냐 탭으로 할거냐. 부터 var a = 3; 과 같은 코드에서 a와 =를 붙이느냐 마느냐라던지를 정해주는 것이죠. 알고 계시는 것처럼 이러한 차이는 특별히 실행 결과의 영향을 주지 않습니다. 다르게 이야기하자면 “실행 결과에 별 차이가 없는 선택지들”이기 때문에 일관성이 있는 기준을 두어 통일하자는 것이지요.그렇다면 왜 이런 선택지를 통일해야 할까요? 불행히도 우리가 작성한 코드는 많은 사람들이 보게 됩니다. 같이 일하는 동료, 이바지하고 있는 프로젝트의 리뷰어, 심지어 내일의 자기 자신까지도 말이죠. 그런데 이런 많은 사람들이 우리가 코드를 작성할 때 했던 선택지를 일일이 추론해서 이해하는 건 굉장히 피곤하고 짜증 나는 일입니다. 그래서 우리는 사소한 것부터 일종의 규칙을 정해서 이런 짜증과 불편함을 줄이려는 겁니다. 또한, 일반적으로 좋은 기준에는 훌륭한 프로그래머들의 좋은 습관이 배어있기 때문에 더 나은 품질의 코드를 작성하는 데에도 많은 도움이 됩니다.이런 코딩 컨벤션은 극단적으로 이야기하면 프로젝트마다 하나씩 존재한다고 볼 수도 있지만, 일반적으로 그 언어문화를 공유하는 공동체에서 인정하는 컨벤션은 대부분 통일되어 있습니다. 파이썬은 지금부터 살펴볼 PEP 8이 대표적입니다.PEP?PEP(Python Enhance Proposal)이란 이름대로 본디 파이썬을 개선하기 위한 개선 제안서를 뜻합니다. 이러한 제안서는 새로운 기능이나 구현을 제안하는 Standard Track, (구현을 포함하지 않는) 파이썬의 디자인 이슈나 일반적인 지침, 혹은 커뮤니티에의 정보를 제안하는 Informational, 그리고 파이썬 개발 과정의 개선을 제안하는 Process의 3가지로 구분할 수 있습니다. (좀 더 자세한 사항은 PEP에 대해 다루고 있는 PEP인 PEP 1을 참고하세요.) 파이썬은 언어의 컨벤션을 이러한 제안서(Process)로 나타내고 있는데 이것이 바로 PEP 8입니다.Laplace’s Box기본적으로 가이드라인이니만큼 규칙만 빽빽할 것 같지만, PEP 8는 서두부터 예외를 언급한 섹션이 있습니다.A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.스타일 가이드는 일관성(consistency)에 관한 것입니다. 이 스타일 가이드의 일관성은 중요하죠. 하지만 프로젝트의 일관성은 더욱 중요하며, 하나의 모듈이나 함수의 일관성은 더더욱 중요합니다.But most importantly: know when to be inconsistent – sometimes the style guide just doesn’t apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don’t hesitate to ask!하지만 가장 중요한 건 언제 이것을 어길지 아는 것입니다. – 때때로 스타일 가이드는 적용되지 않습니다. 의심이 들 때는 여러분의 최선의 판단을 따르세요. 다른 예제를 보고 어느 게 제일 나은지 골라야 합니다. 질문을 주저하지 마세요!Two good reasons to break a particular rule:When applying the rule would make the code less readable, even for someone who is used to reading code that follows the rules.To be consistent with surrounding code that also breaks it (maybe for historic reasons) – although this is also an opportunity to clean up someone else’s mess (in true XP style).다음은 규칙들을 어기는 2가지 좋은 예외 사항입니다.규칙을 적용한 코드가 (규칙을 숙지한 사람 눈에도) 읽기 어려운 경우일관성을 지키려고 한 수정이 다른 규칙을 어기는 경우(아마도 역사적인 이유겠죠.)아직 아무것도 안나왔는데 좀 이르다구요?It’s all about common sense예외 규정을 보여주며 시작하는 PEP 8이지만 얼개는 그리 복잡하지도 않고 크게 난해하지도 않습니다. 여기서는 대표적인 몇 가지만 추려서 소개하겠습니다.Code lay-out들여쓰기는 공백 4칸을 권장합니다.한 줄은 최대 79자까지최상위(top-level) 함수와 클래스 정의는 2줄씩 띄어 씁니다.클래스 내의 메소드 정의는 1줄씩 띄어 씁니다.Whitespace in Expressions and Statements다음과 같은 곳의 불필요한 공백은 피합니다.대괄호([])와 소괄호(())안쉼표(,), 쌍점(:)과 쌍반점(;) 앞키워드 인자(keyword argument)와 인자의 기본값(default parameter value)의 = 는 붙여 씁니다.Comments코드와 모순되는 주석은 없느니만 못합니다. 항상 코드에 따라 갱신해야 합니다.불필요한 주석은 달지 마세요.한 줄 주석은 신중히 다세요.문서화 문자열(Docstring)에 대한 컨벤션은 PEP 257을 참고하세요.Naming Conventions변수명에서 _(밑줄)은 위치에 따라 다음과 같은 의미가 있습니다._single_leading_underscore: 내부적으로 사용되는 변수를 일컫습니다.single_trailing_underscore_: 파이썬 기본 키워드와 충돌을 피하려고 사용합니다.__double_leading_underscore: 클래스 속성으로 사용되면 그 이름을 변경합니다. (ex. FooBar에 정의된 __boo는 _FooBar__boo로 바뀝니다.)__double_leading_and_trailing_underscore__: 마술(magic)을 부리는 용도로 사용되거나 사용자가 조정할 수 있는 네임스페이스 안의 속성을 뜻합니다. 이런 이름을 새로 만들지 마시고 오직 문서대로만 사용하세요.소문자 L, 대문자 O, 대문자 I는 변수명으로 사용하지 마세요. 어떤 폰트에서는 가독성이 굉장히 안 좋습니다.모듈(Module) 명은 짧은 소문자로 구성되며 필요하다면 밑줄로 나눕니다.모듈은 파이썬 파일(.py)에 대응하기 때문에 파일 시스템의 영향을 받으니 주의하세요.C/C++ 확장 모듈은 밑줄로 시작합니다.클래스 명은 카멜케이스(CamelCase)로 작성합니다.내부적으로 쓰이면 밑줄을 앞에 붙입니다.예외(Exception)는 실제로 에러인 경우엔 “Error”를 뒤에 붙입니다.함수명은 소문자로 구성하되 필요하면 밑줄로 나눕니다.대소문자 혼용은 이미 흔하게 사용되는 부분에 대해서만 하위호환을 위해 허용합니다.인스턴스 메소드의 첫 번째 인자는 언제나 self입니다.클래스 메소드의 첫 번째 인자는 언제나 cls입니다.메소드명은 함수명과 같으나 비공개(non-public) 메소드, 혹은 변수면 밑줄을 앞에 붙입니다.서브 클래스(sub-class)의 이름충돌을 막기 위해서는 밑줄 2개를 앞에 붙입니다.상수(Constant)는 모듈 단위에서만 정의하며 모두 대문자에 필요하다면 밑줄로 나눕니다.Programming Recommendations코드는 될 수 있으면 어떤 구현(PyPy, Jython, IronPython등)에서도 불이익이 없게끔 작성되어야 합니다.None을 비교할때는 is나 is not만 사용합니다.클래스 기반의 예외를 사용하세요.모듈이나 패키지에 자기 도메인에 특화된(domain-specific)한 기반 예외 클래스(base exception class)를 빌트인(built-in)된 예외를 서브클래싱해 정의하는게 좋습니다. 이 때 클래스는 항상 문서화 문자열을 포함해야 합니다.class MessageError(Exception): """Base class for errors in the email package."""raise ValueError('message')가 (예전에 쓰이던) raise ValueError, 'message'보다 낫습니다.예외를 except:로 잡기보단 명확히 예외를 명시합니다.(ex. except ImportError:try: 블록의 코드는 필요한 것만 최소한으로 작성합니다.string 모듈보다는 string 메소드를 사용합니다. 메소드는 모듈보다 더 빠르고, 유니코드 문자열에 대해 같은 API를 공유합니다.접두사나 접미사를 검사할 때는 startswith()와 endwith()를 사용합니다.객체의 타입을 비교할 때는 isinstance()를 사용합니다.빈 시퀀스(문자열, 리스트(list), 튜플(tuple))는 조건문에서 거짓(false)입니다.불린형(boolean)의 값을 조건문에서 ==를 통해 비교하지 마세요.Give me a reason하지만 몇몇 규칙은 그 자체만으론 명확한 이유를 찾기 어려운 것도 있습니다. 가령 예를 들면 이런 규칙이 있습니다.More than one space around an assignment (or other) operator to align it with another.Yes:x = 1 y = 2 long_variable = 3No:x = 1 y = 2 long_variable = 3보통 저런 식으로 공백을 통해 =를 맞추는 건 보기에도 좋아 보입니다. 하지만 변수가 추가되는 경우에는 어떨까요. 변수가 추가 될때마다 공백을 유지하기 위해 불필요한 변경이 생깁니다. 이는 소스를 병합(merge)할 때 혼란을 일으키기 쉽습니다.언뜻 보면 잘 이해가 안 가는 규칙은 이런 것도 있습니다.Imports should usually be on separate lines, e.g.:Yes: import os import sys No: import sys, os굳이 한 줄씩 내려쓰면 길어지기만 하고 보기 안 좋지 않을까요? 하지만 이 역시 대부분의 변경 추적 도구가 행 기반임을 고려하면 그렇지 않습니다.#스포카 #개발 #파이썬 #개발자 #Python #컨벤션 #이벤트참여 #이벤트후기 #후기

안녕하세요. 크몽 개발팀입니다.오늘 저는 좀 심오한 주제를 다뤄보려고합니다.이번에 제가 다룰 주제는 ‘자바스크립트’라는 언어입니다.자바스크립트라는 언어와 자바라는 언어에 대해서 혼동을 하는 경우가 많은데요,자바와 자바스크립트는 완전히 다른언어입니다. 쉽게말해서 자바는 서버를 구축하는 부분을 주를 담당하고,자바스크립트는 화면을 구성하는 부분에서 사용되는 프로그래밍 언어라고 보시면 될 것 같습니다.(자바스크립트의 이름을 만들 당시에 자바라는 언어가 유행을 해서 자바스크립트라고 이름을 지었다고 하네요.원래 이 언어의 이름은 라이브 스크립트입니다.)물론 자바스크립트로 서버를 구축을 할 수도 있습니다.(node.js라고하는 플랫폼입니다. 자바스크립트를 이용하여 서버를 구축할 수있는 플랫폼입니다.자세한 사항은 책이나 위키피디아를 참고하시면 좋을 듯 합니다.)각설하고,아무튼 자바스크립트라는 언어에 대해서 좀더 자세히 알아보겠습니다.자바스크립트라는 언어를 알기 위해서는 일단 스크립트라는 것이 무엇인지에 대해 좀더 알아야 합니다.위키피디아에 따르면 스크립트 언어란,'응용프로그램과 독립하여 사용되고 일반적으로 응용프로그램의 언어와 다른 언어로 사용되어최종사용자가 응용프로그램의 동작을 사용자의 요구에 맞게 수행할 수 있도록 해준다.' 라고 정의하고 있습니다. 어렵지요? 쉽게 말하면 연극에서 ‘스크립트’라는 것에 서 유래 되었다고 하고, 그뜻이 연극에서의 시나리오, 각본을 의미합니다. 그 의미를 그대로 적용하면 ‘대본, 시나리오만 제공하면 알아서 작동한다.' 는 그런 뜻이지요.대충 감이 잡히셨나요?자바스크립트는 TIOBE 라는 소프트웨어 회사에서 발표한 2014년 프로그래밍 언어순위에서도 상당히 상위권에 차지를 하고있습니다.그만큼 많이 사용이 된다는 의미겠지요.매우 좋은 것처럼 보이지만 자바스크립트가 만만한 언어는 아닙니다.제가 듣기로는 ‘자바스크립트는 악마의 언어’라고 불린다고 들었습니다.그렇게 불리는 이유는 그만큼 언어가 유연하기때문입니다.조금전에 언급했듯이 연극에서의 대본과 시나리오를 프로그래머가 직접 만들어야한다는 것입니다.그만큼 프로그래밍하기 쉽지 않다는 것이겠지요.자바스크립트는 단점이 바로 장점입니다.'유연하다는 것' 때문에 사람들의 입맛에 맞게 커스터마이징을 할 수있다는 것이고웹상에 이미 프로그래머들이 만들어 놓은 많은 라이브러리가 있습니다.우리는 이걸 잘 이용하면 되겠지요?좀 더 자바스크립에 대해서 자세히 알고싶다면 ‘javascript inside’라는 책을 참고하여 공부해보시면 좋을 듯 하네요. ---------------------------------------------------------------------------------------------------저는 크몽 개발팀의 Sean이었습니다. #크몽 #개발자 #개발팀 #팀원소개 #기업문화

OverviewDB를 다뤄봤다면 SELECT문도 아실 겁니다. 가장 먼저 접하는 명령어 중에 하나이기도 하죠. 보통은 아래처럼 사용합니다. SELECT문SELECT     * FROM 테이블명  ; 명령을 주면 지정한 테이블에 저장된 모든 내용을 검색합니다. 이번 글에서는 테이블을 만들고 SELECT하는 과정을 다뤄보겠습니다. DB는 MySQL 5.6을 기준으로 하고, Tool은 MySQLWorkbench를 사용하겠습니다.Query, 너란 녀석테이블은 위와 같이 생성할 수 있습니다. 위의 내용은 MySQLWorkbench를 이용해 Model을 표시하면 아래와 같습니다. 구성원의 정보를 저장하도록 했고, 컬럼마다 의미를 갖게 됩니다. MBR_ID (구성원 아이디) : DB에서 구성원을 식별하는 아이디MBR_INDFY_NO (구성원 식별 번호) : 구성원을 실제 구별하는 번호로 과거에는 주민등록번호가 많이 사용되었고, 요즘은 e-mail 이 많이 사용됩니다.MBR_NM (구성원 명) : 구성원의 이름 테스트 데이터를 입력해 실행하면 어떤 결과가 나오는지 보겠습니다.가장 기본적인 SELECT문 실행계획을 보면 아래와 같이 나옵니다.실행 계획은 DB가 어떻게 Query를 수행할 건지 보여줍니다. Query가 복잡해지면 실행 계획을 보면서 Query가 올바르게 작성됐는지 확인하고 필요하다면 Query를 수정해야 합니다. DB를 시작할 때부터 실행 계획을 보는 습관을 기르는 게 중요한 이유입니다. 각 항목에 대한 설명id : SELECT 문에 있는 순차 식별자로 Query 를 구분하는 아이디select_type : SELECT의 유형SIMPLE : Subquery나 union 이 없는 단순한 SELECTtable : 참조되는 테이블의 명칭TB_MBR_BAS : 참조되는 테이블명type : 검색하는 방식ALL : TABLE의 모든 ROW를 스캔 위의 이미지는 임의로 만든 자료를 이용해 Query를 실행한 결과입니다. 실행 계획은 TABLE : TB_MBR_BAS 를 TYPE : ALL 전체 검색한다고 나옵니다. 실행한 내용도 같습니다. 여기서 MBR_NM 이 “나서영”인 자료를 검색해볼까요. WHERE 조건이 들어가자 실행 계획도 내용이 변경되었습니다. rows와 Extra에도 값이 있는데요. 두 항목을 잠시 짚고 넘어가겠습니다. rows : Query를 수행하기 위해 접근해야 하는 열의 수Extra : MySQL 이 Query 를 수행할때의 추가 정보Using where : Query 수행시 TABLE에서 값을 가져와 조건을 필터링 함 위의 결과처럼 전체를 검색해 필요한 자료만 추출하는 것을 FULL TABLE SCAN or FULL SCAN 이라고 합니다. 그러나 FULL SCAN은 성능이 좋지 않기 때문에 우선 꼭 필요한 Query인지 검토해야 합니다. 보통 MBR_NM에 INDEX를 추가해서 해결하는데요. INDEX를 추가해서 같은 Query를 수행하면 실행 계획은 어떻게 달라질까요. 분명 같은 Query였는데 INDEX에 따라 실행 계획이 변경된 걸 알 수 있습니다. INDEX를 추가해도 수행한 결과는 같지만 검색 속도에 많은 차이가 있습니다. 각 항목에 대한 설명type - ref : 인덱스로 자료를 검색하는 것으로 현재는 매칭(=) 자료 검색을 나타냄possible_keys : 현재 조건에 사용가능한 INDEX를 나타냄(인덱스가 N개일 수 있음) IX_MBR_BAS_02 : 현재 조건에 사용 가능한 INDEXkey : Query 수행시 사용될 INDEX (possible_keys 가 N 개일 경우 USE INDEX, FORCE INDEX, IGNORE INDEX 로 원하는 INDEX 로 바꾸어 수행할수 있음)key_len : 수행되는 INDEX 컬럼의 최대 BYTE 수를 나타냄152 : 수행되는 INDEX 컬럼의 BYTE 수가 152ref : INDEX 컬럼과 비교되는 상수 여부 or JOIN 시 선행 컬럼 constant : 상수 조건으로 INDEX 수행rows : 678 : 678 rows 접근하여 값을 찾음Extra : using index condition : INDEX 조건에 대하여 스토리지 엔진이 처리(MySQL의 구성에서 스토리지 엔진과 MySQL 엔진이 통신을 주고 받는데 스토리지 엔진에서 처리 하여 속도가 향상됨) ConclusionINDEX가 없으면 결과가 나오기까지 5초 정도 걸리지만, 반대로 INDEX가 있으면 1초 안에 결과가 나옵니다. 별거 아닌 것 같아 보이지만 실무에서는 엄청난 차이입니다. Query를 작성할 때 실행 계획을 확인하고 조금이라도 빨리 결과가 나올 수 있도록 하는 것이 중요하기 때문이죠. 다음 글에서는 단일 TABLE 을 SELECT하는 것을 주제로 이야기를 나눠보겠습니다. 무사히 SELECT하길 바라며.글한석종 부장 | R&D 데이터팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

VCNC는 커플을 위한 모바일 앱 비트윈을 서비스하고 있습니다. 비트윈은 사진, 메모, 채팅, 기념일 등 다양한 기능을 제공하며, 오픈 베타 테스트를 시작한 2011년 11월부터 현재까지 연인 간의 소통을 돕고 있습니다. 그동안 비트윈 시스템 아키텍처에는 많은 변화가 있었으며 다양한 결정을 하였습니다. 비트윈 아키텍처를 발전시키면서 배우게 된 여러 가지 노하우를 정리하여 공유해보고자 합니다. 그리고 저희가 앞으로 나아갈 방향을 소개하려 합니다.소프트웨어 스택Java: 비트윈 API서버는 Java로 작성되어 있습니다. 이는 처음 비트윈 서버를 만들기 시작할 때, 서버 개발자가 가장 빨리 개발해낼 수 있는 언어로 프로그래밍을 시작했기 때문입니다. 지금도 자바를 가장 잘 다루는 서버 개발자가 많으므로 여전히 유효한 선택입니다.Netty: 대부분의 API는 HTTP로 호출되며, 채팅은 모바일 네트워크상에서의 전송 속도를 위해 TCP상에서 프로토콜을 구현했습니다. 두 가지 모두 Netty를 통해 사용자 요청을 처리합니다. Netty를 선택한 것은 뛰어난 성능과 서비스 구현 시 Thrift 서비스를 통해 HTTP와 TCP 프로토콜을 한 번에 구현하기 쉽다는 점 때문이었습니다.Thrift: API서버의 모든 서비스는 Thrift 서비스로 구현됩니다. 따라서 TCP뿐만 아니라 HTTP 또한 Thrift 인터페이스를 사용합니다. HTTP를 굳이 Thrift서비스로 구현한 이유는, TCP로 메세징 전송 시 똑같은 서비스를 그대로 사용하기 위함이었습니다. 덕분에 빠른 채팅 구현 시, 이미 구현된 서비스들을 그대로 사용할 수 있었습니다. 또한, 채팅 패킷들은 패킷 경량화를 위해 snappy로 압축하여 송수신합니다. 모바일 네트워크상에서는 패킷이 작아질수록 속도 향상에 크게 도움이 됩니다.HBase: 비트윈의 대부분 트랜젝션은 채팅에서 일어납니다. 수많은 메시지 트랜젝션을 처리하기 위해 HBase를 선택했으며, 당시 서버 개발자가 가장 익숙한 데이터베이스가 HBase였습니다. 서비스 초기부터 확장성을 고려했어야 했는데, RDBMS에서 확장성에 대해 생각하는 것보다는 당장 익숙한 HBase를 선택하고 운영하면서 나오는 문제들은 차차 해결하였습니다.ZooKeeper: 커플들을 여러 서버에 밸런싱하고 이 정보를 여러 서버에서 공유하기 위해 ZooKeeper를 이용합니다. Netflix에서 공개한 오픈 소스인 Curator를 이용하여 접근합니다.AWS비트윈은 AWS의 Tokyo리전에서 운영되고 있습니다. 처음에는 네트워크 및 성능상의 이유로 국내 IDC를 고려하기도 했으나 개발자들이 IDC 운영 경험이 거의 없는 것과, IDC의 실질적인 TCO가 높다는 문제로 클라우드 서비스를 이용하기로 하였습니다. 당시 클라우드 서비스 중에 가장 안정적이라고 생각했던 AWS 를 사용하기로 결정했었고, 지금도 계속 사용하고 있습니다.EC2: 비트윈의 여러 부가적인 서비스를 위해 다양한 종류의 인스턴스를 사용 중이지만, 메인 서비스를 운용하기 위해서는 c1.xlarge와 m2.4xlarge 인스턴스를 여러 대 사용하고 있습니다.API 서버: HTTP 파싱이나 이미지 리시아징등의 연산이 이 서버에서 일어납니다. 이 연산들은 CPU 가 가장 중요한 리소스이기 때문에, c1.xlarge를 사용하기로 했습니다.Database 서버: HDFS 데이터 노드와 HBase 리전 서버들이 떠있습니다. 여러 번의 테스트를 통해 IO가 병목임을 확인하였고, 따라서 모든 데이터를 최대한 메모리에 올리는 것이 가장 저렴한 설정이라는 것을 확인하였습니다. 이런 이유 때문에 68.4GB의 메모리를 가진 m2.4xlarge를 Database 서버로 사용하고 있습니다.EBS: 처음에는 HBase상 데이터를 모두 EBS에 저장하였습니다. 하지만 일정 시간 동안 EBS의 Latency가 갑자기 증가하는 등의 불안정한 경우가 자주 발생하여 개선 방법이 필요했는데, 데이터를 ephemeral storage에만 저장하기에는 안정성이 확인되지 않은 상태였습니다. 위의 두 가지 문제를 동시에 해결하기 위해서 HDFS multiple-rack 설정을 통해서 두 개의 복제본은 ephemeral storage에 저장하고 다른 하나의 복제본은 PIOPS EBS에 저장되도록 구성하여 EBS의 문제점들로부터의 영향을 최소화하였습니다.S3: 사용자들이 올리는 사진들은 s3에 저장됩니다. 사진의 s3키는 추측이 불가능하도록 랜덤하게 만들어집니다. 어차피 하나의 사진은 두 명밖에 받아가지 않고 클라이언트 로컬에 캐싱되기 때문에 CloudFront를 사용하지는 않습니다.ELB: HTTP는 사용자 요청의 분산과 SSL적용을 위해 ELB를 사용합니다. TCP는 TLS를 위해 ELB를 사용합니다. SSL/TLS 부분은 모두 AWS의 ELB를 이용하는데, 이는 API서버의 SSL/TLS처리에 대한 부담을 덜어주기 위함입니다.CloudWatch: 각 통신사와 리전에서 비트윈 서버로의 네트워크 상태와 서버 내의 요청 처리 시간 등의 메트릭을 CloudWatch로 모니터링 하고 있습니다. 따라서 네트워크 상태나 서버에 문제가 생긴 경우, 이메일 등을 통해 즉각 알게 되어, 문제 상황에 바로 대응하고 있습니다. Netflix의 Servo를 이용하여 모니터링 됩니다.현재의 아키텍처처음 클로즈드 베타 테스트때에는 사용자 수가 정해져 있었기 때문에 하나의 인스턴스로 운영되었습니다. 하지만 처음부터 인스턴스 숫자를 늘리는 것만으로도 서비스 규모를 쉽게 확장할 수 있는 아키텍쳐를 만들기 위한 고민을 하였습니다. 오픈 베타 이후에는 발생하는 트래픽에 필요한 만큼 여러 대의 유연하게 서버를 운영하였고, 현재 채팅은 TCP 위에서 구현한 프로토콜을 이용하여 서비스하고 있습니다.HTTP 요청은 하나의 ELB를 통해 여러 서버로 분산됩니다. 일반적인 ELB+HTTP 아키텍처와 동일합니다.채팅은 TCP 연결을 맺게 되는데, 각 커플은 특정 API 서버로 샤딩되어 특정 커플에 대한 요청을 하나의 서버가 담당합니다. 비트윈에서는 커플이 샤딩의 단위가 됩니다.이를 통해, 채팅 대화 내용 입력 중인지 여부와 같이 굉장히 빈번하게 값이 바뀌는 정보를 인메모리 캐싱할 수 있게 됩니다. 이런 정보는 휘발성이고 매우 자주 바뀌는 정보이므로, HBase에 저장하는 것은 매우 비효율적입니다.Consistent Hashing을 이용하여 커플을 각 서버에 샤딩합니다. 이는 서버가 추가되거나 줄어들 때, 리밸런싱되면서 서버간 이동되는 커플들의 수를 최소화 하기 위함입니다.클라이언트는 샤딩 정보를 바탕으로 특정 서버로 TCP연결을 맺게 되는데, 이를 위해 각 서버에 ELB가 하나씩 붙습니다. 어떤 서버로 연결을 맺어야 할지는 HTTP 혹은 TCP 프로토콜을 통해 알게 됩니다.Consistent Hashing을 위한 정보는 ZooKeeper를 통해 여러 서버간 공유됩니다. 이를 통해 서버의 수가 늘어나거나 줄어들게 되는 경우, 각 서버는 자신이 담당해야 하는 샤딩에 대한 변경 정보에 대해 즉각 알게 됩니다.이런 아키텍처의 단점은 다음과 같습니다.클라이언트가 자신이 어떤 서버로 붙어야 하는지 알아야 하기 때문에 프로토콜 및 아키텍처 복잡성이 높습니다.서버가 늘어나는 경우, 순식간에 많은 사용자 연결이 맺어지게 됩니다. 따라서 새로 추가되는 ELB는 Warm-up이 필요로 하며 이 때문에 Auto-Scale이 쉽지 않습니다.HBase에 Write연산시, 여러 서버로 복제가 일어나기 때문에, HA을 위한 Multi-AZ 구성을 하기가 어렵습니다.한정된 자원으로 동작 가능한 서버를 빨리 만들어내기 위해 이처럼 디자인하였습니다.미래의 아키텍처현재 아키텍처에 단점을 보완하기 위한 해결 방법을 생각해보았습니다.Haeinsa는 HBase상에서 트렌젝션을 제공하기 위해 개발 중인 프로젝트입니다. 구현 완료 후, 기능 테스트를 통과하였고, 퍼포먼스 테스트를 진행하고 있습니다. HBase상에서 트렌젝션이 가능하게 되면, 좀 더 복잡한 기능들을 빠르게 개발할 수 있습니다. 서비스에 곧 적용될 예정입니다.Multitier Architecture를 통해 클라이언트와 서버 간에 프로토콜을 단순화시킬 수 있습니다. 이 부분은 개발 초기부터 생각하던 부분인데, 그동안 개발을 하지 못하고 있다가, 지금은 구현을 시작하고 있습니다. 커플은 특정 Application 서버에서 담당하게 되므로, 인메모리 캐싱이 가능하게 됩니다. 클라이언트는 무조건 하나의 ELB만 바라보고 요청을 보내게 되고, Presentation 서버가 사용자 요청을 올바른 Application 서버로 릴레이 하게 됩니다.Multitier Architecture를 도입하면, 더 이상 ELB Warm-up이 필요하지 않게 되므로, Auto-Scale이 가능하게 되며, 좀 더 쉬운 배포가 가능하게 됩니다.Rocky는 API 서버의 Auto-Failover와 커플에 대한 샤딩을 직접 처리하는 기능을 가진 프로젝트입니다. 현재 설계가 어느 정도 진행되어 개발 중에 있습니다. 알람이 왔을 때 서버 팀이 마음을 놓고 편히 잠을 잘 수 있는 역할을 합니다.기본적인 것은 위에서 언급한 구조와 동일하지만 몇 가지 기능이 설정을 추가하면 Multi-AZ 구성이 가능합니다.특정 커플에 대한 모든 정보는 하나의 HBase Row에 담기게 됩니다.HBase의 특정 리전에 문제가 생긴 경우, 일정 시간이 지나면 자동으로 복구되긴 하지만 잠시 동안 시스템 전체에 문제가 생기가 됩니다. 이에 대해 Pinterest에서 Clustering보다는 Sharding이 더 낫다는 글을 쓰기도 했습니다. 이에 대한 해결책은 다음과 같습니다.원래는 Consistent Hashing을 사용하여 커플들을 Application 서버에 샤딩하였습니다. 하지만 이제는 HBase에서 Row를 각 리전에 수동으로 할당하고, 같은 리전에 할당된 Row에 저장된 커플들은 같은 Application 서버에 할당하도록 합니다.이 경우에, 같은 커플들을 담당하는 Application 서버와 HBase 리전 서버는 물리적으로 같은 머신에 둡니다.이렇게 구성 하는 경우, 특정 HBase 리전이나 Application 서버에 대한 장애는 특정 샤드에 국한되게 됩니다. 이와 같이 하나의 머신에 APP과 DB를 같이 두는 구성은 구글에서도 사용하는 방법입니다.이와 같이 구성하는 경우, Multi-AZ 구성이 가능하게 됩니다.AWS에서 같은 리전에서 서로 다른 Zone간 통신은 대략 2~3ms 정도 걸린다고 합니다.Presentation의 경우, 비동기식으로 동작하기 때문에 다른 리전으로 요청을 보내도 부담이 되지 않습니다.HBase에서 Write가 일어나면 여러 복제본을 만들게 됩니다. 하나의 사용자 요청에 대해 Write가 여러번 일어나기 때문에 HBase연산의 경우에는 서로 다른 Zone간 Latency가 부담으로 작용됩니다. Haeinsa가 적용되면, 한 트렌젝션에 대해서 연산을 Batch로 전송하기 때문에 AZ간 Latency 부담이 적습니다.프리젠테이션다음은 2월에 있었던 AWS 유저 그룹 세미나에서 발표했던 자료 입니다. 비트윈 서버 아키텍처에 대해서 배포 방법을 중심으로 설명이 되어 있습니다. 비슷한 내용이 많이 있으니 살펴보시기 바랍니다.<iframe class="speakerdeck-iframe" frameborder="0" src="//speakerdeck.com/player/e4af60d05bb6013025f71231381b23b3?" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true" style="border: 0px; background: padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 750px; height: 563px;">

스포카 개발팀 문성원입니다. 오늘은 스포카 개발팀의 가공의 개발자 A씨의 일주일을 통해, 스포카 개발팀에서는 일주일간의 개발 일정을 어떻게 진행하는지 살펴보겠습니다. 평소 스타트업(Startup) 개발팀의 문화에 관심이 있으셨던 분들에게 도움이 되길 바랍니다.월요일오전 10시, A씨는 평소보다 조금 일찍 사무실에 도착했습니다. 매주 월요일은 스포카 전체 미팅이 있는 날이기 때문이죠. 한 주간 각자 진행한 것을 토대로 이번 주에 진행할 일을 대외적으로 공표하는 이 회의에 앞서, 스포카 개발팀은 따로 미팅을 잠깐 가집니다. 그동안 지난 주 개발 사항, 이번 주 구현 목록 등을 트렐로(Trello)를 통해 정리한 뒤, 이를 전체 미팅에서 공유합니다. A씨는 지난 주에 미쳐 다 구현하지 못했던 서버의 몇 가지 기능과 클라이언트 신버전 배포 준비를 하게 되었습니다.정신없이 회의 하고 났더니 벌써 점심시간입니다. 늘 가던 근처 식당에서 즐겁게 점심을 먹고 사무실로 올라온 A씨는 막간을 이용해 간밤에 올라온 스포카 개발 블로그의 원고를 검토합니다. 몇 가지 오탈자와 맞춤법을 지적한 뒤 모두가 지루해할 월요일 오후 1~2시경에 공개하는 것이 목표입니다.올라간 블로그 글을 확인한 뒤에, A씨는 구현해야 할 서버 기능을 살펴보기로 했습니다. 생각보단 많긴 하지만 일주일 안에는 어떻게든 끝낼 수도 있을 것 같은 분량이네요. 우선 트렐로에 올라온 카드의 명세를 토대로 작업해야 할 내용을 체크리스트(Check List)로 정리합니다. 그다음은 모두가 짐작하시듯이 열심히 일합니다. A씨는 프로니까요.어느덧 저녁 시간이 다 되었습니다. 특별히 일이 없는 이상 야근은 하지 않는 주의인 A씨지만, 오늘만큼은 저녁을 먹고 조금 더 남아있기로 합니다. 팀 내에서 진행하고 있는 스터디 때문이죠. 혼자서 읽기는 까다로웠던 책을 다 같이 읽어보니 조금은 이해가 더 되는 느낌이 드네요.화요일A씨는 오전에 작업하던 중 이상한 점을 발견합니다. 구현하기로 한 기능이 기존 기능과 모순이 되기 때문이죠. 이걸 어떻게 해결할까 고민하던 A씨는 다행히 사무실에 남아있던 엔에이블러(Enabler)팀원들과 간단하게 미팅을 합니다. 문제를 설명하고 명세를 다시 확인한 A씨는 작성한 회의록과 함께 배포합니다. 트렐로의 해당 카드에도 첨부하여 나중에 다시 볼 수 있게 하는 것은 기본입니다.뜻하지 않은 문제 때문에 오전을 날려서 기분이 나빠진 A씨지만, 다행히 좋아하는 스파게티를 먹고 기운을 내기로 했습니다. 사무실에 올라와 인터넷 뉴스와 페이스북을 잠시 보던 A씨는 암묵적으로만 정해진 점심시간이 끝나자 바로 작업을 시작합니다. A씨는 프로니까요.그런데 문제가 있습니다. 오전에 배포한 회의록을 읽어 본 다른 팀원들이 이건 다른 문제의 원인이 될 수 있다고 합니다. A씨는 새 기능 추가가 단순히 로직이 아니라 클라이언트 UI를 포함한 대규모 변경이 필요하다는 것을 깨닫습니다. A씨는 새 기능에 대한 대략적인 스케치를 발사믹 목업(Balsamiq Mockup)으로 마친 뒤 이를 다시 배포합니다. 또한, 관련된 카드에 설명도 잊지 않습니다.수요일매주 수요일 오전에 스포카 개발팀은 짧은 미팅을 합니다. 금주의 진행사항 중 변경사항이나 도움이 필요한 내용을 공유하는 자리인데요. 여기서 A씨는 어제 일을 다시 정리해서 이야기하고, 일정이 지연될 수 있음을 전달합니다. A씨에게 할당된 카드 일부를 다음 주로 미루거나, 좀 한가한 사람에게 나눠주는 형식으로 짐을 던 A씨였지만, 여전히 큰일이 되어버린 기능 변경은 무거운 짐입니다.이런 대량의 작업 때문에 고민하던 A씨에게 같은 팀 B씨가 어떤 라이브러리를 소개해줍니다. A씨는 처음 보는 라이브러리인지라 B씨가 전담해서 가르쳐주는 모양이 되었지만, 생각보다 문제 해결에 큰 도움이 될 것 같습니다. 마침 다음 주에 개발 블로그에 글을 써야 할 당번이 된 A씨는 그 라이브러리에 대해 좀 더 공부해서 쓰기로 정합니다.B씨의 도움 덕에 진행 속도가 붙은 A씨는, 금주 업무 중 하나였던 클라이언트 새 버전의 테스트를 내일부터 진행하기 위해 페이스북이나 인터넷 뉴스도 보지 않은 채 열심히 일합니다. 이런 A씨의 프로다운 모습에 하늘도 감탄했는지, 퇴근 시간인 7시 전에 작업을 끝낸 A씨는 구현된 기능들을 테스트 해 보고 팀의 다른 개발자와 공유하기 위해 github에 만들어진 스포카 서버 코드 저장소에 푸시(Push)합니다.목요일구글 플레이(Google Play)는 하루 정도면 배포가 되니 다행이지만 애플 앱스토어(Apple App Store)는 일주일 정도의 심사기간이 있기 때문에 거절(Reject)당하지 않게 철저히 준비해야 합니다. 그래서 어느 때보다 A씨는 날카로운 눈매로 클라이언트를 점검합니다. 아니나 다를까 메뉴를 이동하다 보니 화면 구성이 흐트러지는 버그가 발견되었습니다. 하지만 프로답게 A씨는 당황하지 않고 재현 조건을 확인한 뒤, 클라이언트 담당자인 C씨에게 알려줍니다. “클라이언트 관련한 버그를 찾았는데, 트렐로를 확인해보세요.”라구요. QA(Quality Assurance) 업무 역시 스포카 개발팀은 직접 처리합니다.밖에 비가 오는지라 피자를 시켜먹은 뒤, 자리에 앉아 잠깐 쉬고 있던 A씨에게 D씨가 다가와서는, “어제 푸시한 소스를 내려받다(Pull)가 충돌(Conflict)이 났는데, 어떻게 병합(Merge)해야 할지 모르겠네요.” 라며 묻습니다. A씨는 D씨와 충돌이 난 소스를 함께 검토하고 문제가 발생하지 않게끔 조정한 뒤 이를 다시 푸시해서 상황을 종료합니다.이러는 사이 C씨가 A씨가 말한 버그를 고쳤다며 다시 확인해보라고 트렐로의 관련 카드를 “테스트” 리스트로 옮깁니다. A씨는 재현된 상황에서 문제 없이 동작하는 것을 확인하고 카드를 “완료” 리스트로 다시 옮깁니다. 이제 클라이언트 앱을 심의 신청하고 어제 구현한 서버 쪽 코드의 개선사항이 있는지 살펴봅니다. 서버는 클라이언트가 앱스토어나 플레이에 준비되는 것을 확인한 뒤, DotCloud에서 제공하는 배포 스크립트를 통해 손쉽게 버전업할 수 있기 때문에 시간이 좀 남아 있습니다. 현재로선 특별히 더 손댈 부분이 없다는 걸 확인한 A씨는 오늘도 즐겁게 퇴근합니다.금요일월요일과 마찬가지로 오늘도 A씨는 평소보다 조금 서둘러서 사무실에 도착했습니다. 오늘은 사내 전체적으로 한 주간 있었던 업무 내용을 간략하게 보고하는 자리가 있습니다. A씨는 이번 주에 맡은 서버 개발이 이러저러해서 이렇고 저렇게 바뀌었다고 설명한 뒤, 앱스토어에 신청되었다는 사실을 공지합니다. 전체 보고가 끝난 뒤엔 개발팀은 따로 남아서 약간 자세하게 금주 작업을 공유하면서 트렐로의 “완료” 상태에 있는 카드들을 정리하는 시간을 갖습니다.점심을 먹고 나서, 이번 주에 더는 급한 일정이 없다는 것을 확인한 A씨는 개발 블로그에 쓸 글을 정리하기 시작합니다. 수요일에 B씨가 알려 준 라이브러리의 사용 방법은 대강 배웠지만, 그것을 남에게 설명할 수 있을 만큼 자세히 알지는 못했기 때문에 A씨는 한동안 공식 문서와 예제 코드들과 씨름합니다. 그래도 어느새 옆에서 거들기 시작한 B씨 덕에 글은 생각보다 순조롭게 마무리되었습니다. 이제 다음 주 월요일까지 퇴고해서 블로그에 공개하기만 하면 되죠.생각보다 오늘 업무를 끝낸 A씨는 친구들과 약속이 있는 홍대로 가기 위해, 7시 정시에 사무실을 떠납니다.#스포카 #개발 #개발자 #개발팀 #개발자의일주일 #개발자의일상 #인사이트 #경험공유

핀터레스트의 안드로이드 개발팀이 코틀린을 도입하면서 겪은 어려움과 해결책을 소개한 The Case Against Kotlin을 foot번역하고 자의적으로 해석하고 요약했습니다. 저자 라이언 쿡(Ryan Cooke)은 현재 코틀린이 가트너의 하이프 사이클에서 “뻥튀기된 기대감의 산(Peak of Inflated Expectations)” 쯤에 있다고 말합니다. 레진시 개발동에서는 이미 코틀린을 부분적으로 도입했고, 현재는 범위를 넓혀가는 중인데요… 정말 괜찮은 걸까요?문제: 학습 곡선자바 개발자로서 문법에 익숙해지는 데 1주일 정도 걸립니다.코틀린을 이미 잘하는 사람이 없으면 베스트 프랙티스들을 찾아보면서 해야하는 데 시간이 듭니다.코틀린 사용을 가속화 시키는 데 팀 트레이닝을 계속 해야합니다. -> 기회비용 많이 듭니다.하기 싫어 하는 사람도 있고…혼자서 알아서 잘 배우는 사람도 있고…해결책: 학습 곡선코틀린은 아직 말년병장성숙한 언어가 아닙니다! 지금도 자라나고 있습니다! 그게 제일 무서워..책도 있고 인터넷 리소스도 있지만, 코틀린 신봉자가 하나 있어서 다 가르쳐주는 게 짱입니다.필자가 코틀린을 하고 싶었던 이유는 생산성인데요, 동료들 중에는 그렇게 느꼈던 사람들이 많지 않은 것 같습니다. 정착이 되면 보이겠죠.문제: 빌드 속도Gradle 빌드 속도는 보통 30초, 클린 빌드는 75초 까지 걸립니다.코틀린은 보통 빌드 속도의 25%, 클린 빌드의 40% 밖에 안나옵니다.해결책: 빌드 속도알아서 하셈 ㅋ코틀린 파일 하나 변환 -> 클린 빌드 시 조금 시간이 더 걸립니다. 파일을 많이 변환할수록 느려지긴 하지만 체감하긴 어렵습니다.보통 빌드할 때는 코틀린 파일 많아도 상관 없습니다.결론: 클린 빌드할 때 느려진다는 걸 체감할 겁니다.문제: 개발 안정성코틀린의 문법이나 특성이 문제가 아니라, 코드를 생산성 있게 작성하는 자신을 막는 새로운 문제들 때문이라고 생각합니다.사실 그냥 코틀린 배우기 싫은 거 같아요.예를 들면, 코틀린 애노테이션 프로세서 툴(kapt) 때문에 빌드가 안 되고, 무조건 클린 빌드로만 개발을 했던 적이 있습니다.이거… 코틀린 때문 아니야?!?!?! 하는 의심들 많았죠.고치느라 시간이 많이 흘렀습니다.또 어떤 문제가 튀어나올지에 대한 두려움이 커지네요.해결책: 개발 안정성그냥 IDE 나 언어의 stable 버전만 업데이트 하세요.안정된 버전들만 사용하면 그나마 힘든 일 없을거예요.정말?문제: 정적 분석FindBugs, PMD, Error Prone, Checkstyles and LintJava 는 이와 같은 툴들로 인해 Code Review에 쓸데없는 걸 줄이거나 룰을 적용할 수 있는데,코틀린에는… 이런 게 없… 분석을 위한 게 아직… 없습니다… 사람들이 알아서 다 찾아야 합니다.해결책: 정적 분석그냥 손가락빨고 기다려야 합니다. 아니면, 직접 만드세요!문제: 나 돌아갈래~돌아가기 쉽지 않습니다. 자바를 코틀린으로 옮기기에는 쉬운데, 반대는… 어렵습니다!코드가 깨지고, 변수명부터, 이런 저런 부분들을 다시 구현해야합니다.코틀린스럽거나, 코틀린의 고유한 기능들을 사용했다면, 여기서부터 헬이죠.해결책: 나 돌아갈래~되돌아오는 건 쉽지 않기 때문에 잘 생각해야 합니다.유닛 테스트가 정말 잘 된 파일들부터 바꾸세요.간단하고 재사용 가능한 잘 모듈화된 파일들을 먼저 바꾸세요.결론이 글은 고려해야 할 리스크에 대해서 나열했습니다.단점들은 구글과 젯브레인과 스택오버플로우가 차차 해결해 줄 겁니다.TL;DR 코틀린으로 작성하는 건 쉽지만, 되돌리기는 어렵습니다.그래서 말인데… 레진코믹스에서 코틀린 삽질을 함께 할 개발자를 모십니다!

안녕하세요 "사운들리"입니다 :)오늘은 사운들리의 코드 품질 관리에 대해 이야기 해보려 합니다.몇몇 개발자에게는 지루하고 악몽같은 이야기일 수 있겠네요.제 경우에는 예전에는 이런 품질이라는 단어를 멀리했지만 결국 제가 작성한 코드에 발목을 많이 잡히다 보니, 자연스레 관심을 갖게 되었습니다.일단, 어떤 소프트웨어가 좋은 품질의 소프트웨어일까요?좋은 품질이란? 책에 나올법한 내용을 보면, 아래와 같은 항목을 토대로 소프트웨어 품질을 판단한다고 합니다.ISO/IEC 9126 : Software engineering - Product qualityFunctionality: 명시된 요구사항을 잘 충족했는지Reliability: 명시된 조건과 시간 아래에서 일정 성능을 유지 하는지Usability: 사용하기 위해 어느정도의 노력과 자원이 필요한지Efficiency: 소모 자원과 성능간의 효율Maintainability: 수정하기 위해 어느정도의 노력이 필요한지Portability: 다른 환경에서도 사용 할수 있는지출처: https://en.wikipedia.org/wiki/ISO/IEC_9126 뭔가 복잡해 보이지만, 결국 개발자라면 위의 항목은 누구나 추구하게 되는 가치라고 생각 합니다.그런데 말입니다. 이런 좋은 내용을 마음 속으로만 간직한 채 코드를 작성하면 정말 좋은 소프트웨어를 만들 수 있을까요? 저는 객관적인 방법으로 코드를 평가한다면 좋은 피드백이 될 것이라고 생각합니다. (물론 이 성적표를 남에게 보여주는 것과는 다른 문제에요 ㅎㅎ)어떻게 품질을 체크하는가 소프트웨어의 품질을 체크하는 데에 다양한 방법과 툴이 제시되고 있는데요, 저는 크게 두 가지로 분류 해보겠습니다.유저 입장의 품질: 유저의 요구사항에 맞는 소프트웨어인지 체크개발자 입장의 품질: 내가 지금 이 코드를 의도한 대로 잘 작성하고 있는지 체크 유저 입장의 품질은 언급하지 않아도 중요함을 누구나 알고 있습니다. 이 부분이 만족이 되지 않으면 제품이 아니죠! 그래서 저는 개발자 입장에서 스스로 챙길수 있는 품질을 사운들리는 어떻게 챙겨보고 있는 지 이야기 해보도록 하겠습니다. 실은 제가 개발자 입니다 ㅎㅎ사운들리 개발자의 코드는 아래와 같이 흘러갑니다.<그림1> 사운들리 코드 개발상의 품질 관리 순서도간단히 각 항목을 훑어 보겠습니다.Local Machine 각자 갖고 있는 맥북으로, 다양한 IDE를 사용해 코딩합니다. 그리고 git 을 이용해 commit 하고, github 에 push 하죠.Github push 된 수정사항은 pull request 를 통해 동료에게 알려집니다. 이후 코드리뷰를 통해 merge 하게 됩니다. 코드리뷰는 많은 사람들에 의해 그 중요성이 부각되고 있습니다. 사운들리는 같은 모듈을 만드는 개발자끼리, 그리고 다른 모듈에 영향을 주는 코드일 경우에는 해당 모듈의 개발자도 리뷰를 합니다. 코드리뷰를 통해 다른 사람이 어떤 기능을 작성했는지 보고, 오류도 찾고, 더 좋은 방법이 있으면 공유도 하고, 칭찬도 하고, 훈수도 두고 합니다. 참고로 사운들리는 git-flow 정책에 따라 git branch를 운영하고 있습니다.Jenkins  Github 에 commit 이 등록되면 Jenkins 는 자동으로 빌드를 시작 합니다. Jenkins 는 단순 빌드 성공 실패를 떠나서, 코드 품질에 대한 몇가지 report 를 발생 시킵니다. 아래에서 좀더 자세히 다뤄보겠습니다.SonarQube Jenkins 에서 빌드하면서 SonarQube 에 포함된 분석 기능을 사용하게 됩니다.그렇다면, 코드 품질의 지표는 무엇일까요?Jenkins가 발생시키는 레포트를 통해서 알 수 있는 내용은 아래와 같습니다.코딩 스타일 체크 결과: 작성된 코드가 미리 정의된 코딩 스타일에 맞게 작성되어 있는지?Unit Test 결과: 유닛 테스트 결과 (당연히 전부 pass 해야겠죠)Test code coverage 결과: 테스트 코드가 전체 코드의 몇 % 를 커버 하고 있는지 (우리의 최종목표는.. 60%.. 덜덜덜)정적 분석 결과: 코드를 실행하지는 않지만, 코드 그 자체에서 발생할 수 있는 결함을 찾아줍니다. 이 네 가지 레포트는 객관적 수치를 나타내주기 때문에 일종의 코드 품질 지표로 삼을 수 있습니다. 물론 이 지표만 잘 관리 했다고 해서 좋은 코드를 작성했다고 말할 수는 없습니다. 다만 좋은 코드를 작성하기 위한 기초 중의 기초라고 볼 수 있겠죠 :)품질 체크를 위한 툴(tool)은 개발 언어에 따라 다를 수 있습니다. 사운들리에서는 다양한 언어로 소프트웨어가 작성되어 있습니다. 따라서 언어마다 위의 결과를 얻기 위해서 서로 다른 툴을 사용하고 있습니다. AndroidJavaJavascriptC/C++코딩 스타일checkstylecheckstyle jshintcppcheckUnit testjunitjunitmochagoogletestCode coveragejacococoberturamocha-covgcov정적 분석sonarqubesonarqube sonarqubecppcheck 각 개발자는 위의 네 가지 결과를 얻기 위해서 빌드 시스템에 툴을 포함하여 개발하고 있습니다. 제가 주로 개발하고 있는 java 언어에 해당하는 툴들을 좀 더 자세히 살펴보겠습니다.checkstyle코딩 스타일을 체크 해줍니다. xml 파일로 미리 정의 되어있고요. 매번 빌드할때마다 스타일이 틀린것을 지적해 줍니다.코딩 스타일은 중요합니다. 같이 개발하는 개발자와 코딩 스타일이 같다면 마치 내가 작성한 코드처럼 쉽게 읽을 수 있죠.junitjunit 은 자바 유닛 테스트 프레임워크 입니다. 유닛 테스트 코드를 편하게 작성하게 해주고, 쉽게 테스트 결과를 볼 수 있습니다.유닛 테스트 코드를 작성하면 내가 작성한 모듈을 작은 단위로 테스트 해서, 작은 로직에서 발생하는 시시콜콜한 문제를 방지 할 수 있습니다. 테스트 코드를 작성해서 검증한 부분은 스스로도 신뢰가 갑니다.기능 수정간에 유닛 테스트에서 fail 이 나는 경우가 발생하는데, 모르는 사이에 다른 모듈에 영향을 준 것을 알게 됩니다. 다른 모듈에 모르고 영향을 주게 되면 뒷처리가 어려워지잖아요~coberturacode coverage 를 계산해 주는 툴입니다.유닛 테스트 코드가 실행되면, 작성된 코드의 각 부분을 실행하게 됩니다. cobertura 는 이때 각 코드의 어느부분이 실행되었는지 확인해서 통계를 내줍니다.주로 line coverage / branch coverage 두 지표를 보는데요, line coverage 는 해당 라인이 한번이라도 실행 되면 check 되고, branch coverage 는 각 라인에 있는 조건문을 다 따로 check 합니다. 당연히 branch coverage 를 달성하는게 어렵겠죠?sonarqube소나큐브는 다양한 plug-in 을 통해서 정적 분석을 하고, 시각화를 해주는 툴입니다.사운들리는 주로 정적 분석 용도로만 소나큐브를 사용하고 있습니다. (지원하는 plug-in 을 보면 젠킨스와 기능이 겹치는 부분이 있습니다.)정적분석으로 실제 문제가 되는 부분을 찾는 경우도 있고, minor 한 부분에 대한 지적을 하는 경우도 있습니다. 그러나 이런 minor 한 부분도 꼼꼼하게 잘 챙겨야 좋은 개발자가 된다고 믿고 있습니다.마치며 여기까지 사운들리의 코드 품질 관리에 대해 이야기 해보았습니다. 품질 관리를 해보신 분은 아시겠지만, 이런 툴을 쓰다보면 항상 행복하게 코드 품질을 관리할 수는 없습니다. 매달 세워놓은 목표를 달성하기 위해서 뼈를 깎는 노력으로 테스트 코드를 작성해야 되고, 당장 기능 수정해서 배포해야 되는데, 작성해 둔 테스트 케이스가 Fail 되어 말썽을 부릴 수도 있습니다. 그렇지만 객관적 기준으로 코드 품질을 관리하다보면 어느샌가 큰 노력없이 좋은 코드를 작성하는 개발자가 되지 않을까 생각해 봅니다. 코드 졸면서 막 짜도 style warning 0건/ 정적분석 오류없음 / 테스트 코드 기본 탑재 뭐 이런 개발자 말입니다 ㅎㅎ 다른 개발자분들은 어떻게 자신이 작성한 코드의 품질을 관리하고 있는지 궁금하네요.알고 계신 좋은 방법이 있다면 언제든지 공유 부탁드리겠습니다~!#사운들리 #개발자 #개발 #인사이트 #조언 #개발후기 #후기