스토리 홈

인터뷰

피드

뉴스

조회수 2394

비트윈 PC 버전 개발기 - VCNC Engineering Blog

 지난 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↩
조회수 1598

Humans of TODAIT : 안드로이드 천재 개발자 김범준을 만나다

‘Humans of TODAIT’의 네번째 주인공, 투데잇 안드로이드 개발자 김범준씨를 만나보았습니다. 투데잇의 천재 개발자로 불리는 그의 이야기를 함께 들어볼까요?(2017.08)Q. 자기소개 부탁드려요.안녕하세요! 투데잇에서 까칠남을 맡고 있는 안드로이드 개발자 김범준입니다. 퇴사자 인터뷰를 하게 되니, 정들었던 팀원분들과 헤어질 생각에 아쉽고 싱숭생숭하네요. (웃음) 작년 초 쯤 ‘SW 마에스트로’ 프로그램에서 만난 멘토님께서 제게 투데잇 안드로이드 개발자 자리를 추천해주신 덕분에 이렇게 투데잇과 인연이 닿게 되었어요. 사실 처음에는 큰 생각이 없었는데, 대표님과 팀장님을 만나보니 저와 코드도 잘 맞고 개발 쪽으로도 많이 배워볼 수 있을 것 같아서 그 날 바로 입사 결정을 내렸고, 지금은 퇴사를 앞두고 있네요.Q. 그렇게 좋은 투데잇을 떠나는 이유는 무엇인가요?원래 병특을 가야 했어요. 제가 군대를 아직 안 갔기 때문에, 군대 문제를 해결 해야 더 많은 기회도 생기고 지금 가지고 있는 마음의 짐 같은 것도 덜 수 있거든요. 아쉽게도 투데잇이 병특 산업기능요원지정업체가 아니어서 군대 문제를 해결하기 위해서는 퇴사할 수 밖에 없는 상황이에요. 사실 원래부터 군대 문제 때문에 잠시 동안만 일하기로 했던건데, 회사생활이 너무 만족스럽고 일이 즐거워서 계속 미루다가 이제서야 결정을 내렸네요. 지금도 많이 아쉬워요. 투데잇만한 회사 없거든요.Q. 팀 내에서 평소 자기계발을 많이 하는 것으로 유명한데, 혹시 자기계발 노하우가 있나요?사실 공부는 진짜 하는 것보다 시작하는 것이 어렵잖아요. 그래서 저는 일부러 저한테 강제성을 주는 편이에요. 매주 하는 동아리 활동이라든지 발표 기회를 만든다든지 관련 세미나를 참여한다든지 그런 일정이 생기면 자연스럽게 하게 되더라고요. 하면 또 잘하고 싶은 게 사람 마음이니까 자꾸 강제적으로 그런 기회를 만들죠.그리고 저는 일상에서 배울 수 있는 기회를 얻으려고 해요. 일하다가 힘들거나 머리가 잘 안 돌아갈 때 저장해둔 아티클을 보곤 하죠. 또 술마실 때도 같은 직업군의 친구들을 만나면 그런 얘기를 많이 하잖아요. 너 이거 시도해봤냐 어땠냐 이건 어떻게 하는거냐 같은 이야기요. 제가 주위 사람들에게 자극을 많이 받거든요. 책상 앞에 앉아서 하는 공부보다는 일상적 시간을 활용하고 뭔가를 준비하기 위한 공부의 자기계발을 하는 것 같아요.Q. 지난 1년을 돌아보는 의미에서, 개발자로서의 좌우명이나 철학이 있을까요?저는 어떤 일을 하든 명확한 근거가 있어야 한다고 생각해요. 커뮤니케이션에서도 그렇고 개발에 있어도 마찬가지예요. 내가 하는 일에 대한 충분한 이유가 있어야 하고 그게 코드에 녹아 있어야 해요.예를 들면, 같은 풍경을 보고 글을 쓸 때도 여러 방법이 있잖아요. 사람마다 글 쓰는 방법이 다르고. 그 방법을 선택한 데엔 저마다 이유가 있어요. 코드도 마찬가지예요. 어떤 기능을 개발할 때 그 기능을 구현할 수 있는 여러 방법이 있는데, 개발자라면 내가 만든 코드에 대해 내가 왜 이렇게 짰는지 다른 사람에게 자신 있게 말할 수 있는 개발자가 되어야 한다고 생각해요.저는 힙한 개발자가 되고 싶어요. 그러니까 최신 트렌드에 민감하고, 새로운 것에 도전하고 두려워 하지 않는 그런 개발자요. (웃음)Q. 힙한 개발자 멋지네요. 그렇다면 10년 후에는 무엇을 하고 싶은지 궁금한데요?제 꿈은 그냥 행복하게 사는거예요. (하하) 추상적인 이야기 같겠지만, 행복하게 살기 위해선 많은 것들이 필요하잖아요? 우리가 말하는 이상적인 행복이란 것은 돈, 인간관계, 사회적 직위, 건강과 같은 모든 박자가 잘 맞아 떨어졌을 때 이루어지는 행복이거든요. 그래서 저는 행복하기 위해서는 끊임없이 노력해야 한다고 생각해요. 장차 10년 후에 제가 뭘 하고 있을지는 모르지만, 지금 현재의 상황에서 제가 할 수 있는 최선의 선택을 하면서 열심히 단계적으로 이루어나가면, 10년 후에도 충분히 행복할 것 같아요. 저는 지금 행복하거든요. (웃음)Q. 일하다 보면 해결하기 힘든 난제를 만날 때가 있을 것 같은데, 그럴 땐 어떻게 극복하나요?내가 스트레스를 많이 받고 있다는 걸 깨달으면, 그냥 최대한 스트레스 받지 않으려고 해요. 그냥 뭐 하면 되지 라는 생각이죠. 하면 되지 하면서 하다보면 결국 되는 것 같아요. 어차피 해야 될 일인데, 스트레스 받으면서 하기 보다는 그냥 아무 생각 없이 열심히 하는 게 나으니까요. 만약에 제가 몰라서 못하고 있는 일이면 여러 사람들에게 물어보려고 하면서 어떻게든 해결하려고 하고요.Q. 그렇다면 투데잇에서 가장 만족스러운 결과물은 무엇인가요? 개인적으로 뿌듯하다거나 실제 반응이 좋았다거나 그런 것들이요!‘스탑워치’ 기능이 두 개 다 포함돼요. 이전 개발자가 스파게티 코드(엉망진창의 코드)로 만들어 놓았던 것이 있는데 그 코드를 제가 깔끔하게 다 수정했고, 계속 유저분들이 요청해주셨던 시간 잠금, 극강의 잠금 모드 같은 기능들을 추가해서 코드를 예쁘게 잘 만들어놓았거든요. 일단 제가 기발한 기능과 함께 코드를 예쁘게 잘 만들어냈다는 점에서 스스로도 만족을 했었고, 유저분들도 팀원분들도 좋은 피드백을 해주셔서 굉장히 좋았습니다.Q. 지금 이 글을 보고 계시는 스탑워치 기능 애용 유저분들께 한마디 해주세요!우선 잘 사용해주셔서 감사해요! 제가 만든 기능을 이용해 공부하시는 걸 보면, 저도 정말 큰 자부심을 느끼거든요. :) 다만, 아직 스탑워치 기능에 문제가 조금 있는 거로 알고 있어요. 약간 불편하더라도 이왕이면 둥글게 좋게 별 5점으로 리뷰 주시면! 저희와 의사소통하면서 함께 좋은 서비스 만들어 나갈 수 있을 것 같아요. 안 보는 것 같지만 투데잇 개발자 전체가 매일 열심히 읽고 있거든요. 정말 리뷰 하나에 울고 리뷰 하나에 웃습니다. 저희 투데잇 지금까지 사랑해주셨지만, 앞으로도 계속 사랑해주시면 감사하겠습니다. :)Q. 반대로 투데잇 안드로이드 개발에 있어 아쉬운 부분도 있을 것 같아요. 나 이거 진짜 욕심났다! 혹시 있을까요?음.. 저는 옛날에 있던 아키텍처를 일단 전부 바꾸고 싶어요. 최근에 꽂힌 아키텍쳐가 있는데, 그 아키텍쳐에 맞게 코드를 다 변경해보고 싶다는 욕심이 있거든요. 근데 그 아키텍쳐 특성상 현재 코드에서는 완전히 대대적인 수정이 들어가야되는데, 제가 남은 시간이 얼마 없어서 많이 수정을 못했죠. 우리가 좀 더 많은 시간이 있고 여유가 있었더라면 더 바꿔볼 수 있었을텐데 그런 부분들을 못한 게 조금 아쉬워요.“투데잇의 힘은 서로에 대한 믿음인 것 같아요”Q. 범준님에게 투데잇이란? 투데잇 팀의 힘이 무엇이라고 생각하시나요?무엇보다 투데잇의 힘은 서로에 대한 믿음인 것 같아요. 커뮤니케이션이 잘 되려면 그 사람에 대한 믿음이 있어야 되잖아요. 근데 저흰 그게 되게 잘 되고 있다고 생각되거든요. 업무적으로 제 이야기를 자신있게 할 수 있었던 이유도 이 사람들은 전부 다 각자 일을 열심히 하고 책임을 지려는 사람, 멋있는 사람이라는 걸 알고 있었기 때문에 가능했거든요. 다들 맡은 바에 있어서 최선을 다하고 정말 열심히해요. 그 분위기가 서로에 대한 믿음을 만들고 우리의 원동력을 만들죠. 확실히 저희 팀은 일단은 진짜 서로에 대한 믿음이 강하다? 업무적 믿음이 강하다? 그런 게 있는 것 같아요.Q. 투데잇에서 가장 고마웠던 사람은 누구였나요?솔직히 다 고마운데, 저는 대표님께 가장 감사했어요. 이번에도 혼자 고민하다가 힘들게 퇴사 의사를 밝혔는데, 대표님께서 그건 당연한 거라고 이야기해주시더라고요. 저는 투데잇 팀이 참 좋은 게 어떤 이야기를 했을 때 명확한 근거가 있다면 그 후에 뒤끝이 하나도 없어요. 이번 일도 그렇고 일적으로 이야기 할 때도 그렇고, 이유가 확실하면 OK하고 쿨하게 가곤 하셨거든요. 다 업무적 믿음이 있기 때문이라고 생각해요 저는. 여러모로 저를 많이 믿어주신 대표님한테 제일 감사하죠. 대표님 에너지도 너무 좋고 카리스마도 본받고 싶고 제가 되게 좋아하는 분이에요.Q. 범준님의 다음 타자가 될! 투데잇에 입사하고 싶은, 입사할 분들에게 한 마디 부탁드려요!“팀원 하나하나가 굉장히 중요한 역할을 하고 있는 사람들이어서 그만큼 책임감이 있지만, 그만큼의 자율성도 있는 회사에요”굉장히 좋은 팀이에요. 일적에서는 절대 스트레스 주는 일이 없고요. 뭔가 일이 밀리거나 못하는 거에 있어서는 스트레스가 있을 수도 있어요. 팀원 하나하나가 굉장히 중요한 역할을 하고 있는 사람들이어서 그만큼 책임감이 있지만, 그만큼의 자율성도 있는 회사에요. 노력하는 그대로의 모습을 사람들에게 보여줄 수 있고 인정 받을 수 있기 때문에 흔히 말하는 꼰대 문화가 싫으신 분들은 투데잇에서 행복하게 일할 수 있을 거예요. 업무적으로나 환경적으로나 대우도 근무 환경도 굉장히 좋으니까 관심 있으신 분이면, 특히 안드로이드 개발자 분이면 지금 바로 들어오실 수 있을 것 같아요. 유저한테 피드백도 받을 수 있고 개인적으로 리스펙하는 멋진 CTO분도 계시고, 개발자로서 특히 굉장히 좋은 곳입니다. 주저 마세요!#투데잇 #팀원소개 #팀원인터뷰 #팀원자랑 #기업문화 #조직문화
조회수 880

프로그래밍에는 왜 창의성이 필요하다고 할까요?

왜 프로그래밍에는 창의성이 필요하다고 할까요? 실제로 프로그래밍을 하다 보면 복잡한 문법을 이해하고, 암호 같은 에러를 차분히 해결해야 하니, 오히려 수학적이며 논리적인 사고가 더 필요해 보입니다. 그런데도 프로그래밍이 창의적이어야 하는 이유는 하나의 프로그램을 만드는 답이 여럿이기 때문입니다.답이 하나여도 가르치기 어려운데, 다양한 방법을 어떻게 가르쳐야 하는 걸까요? 또, 기상천외한 학생들의 코드를 보며 이해하고 교육하는 것이 얼마나 긴 시간이 필요하며 어려운 일인가요? 어디서부터 해결해나가야 할지 막막합니다.Elice 리서치 팀에서 하는 일 중 하나는 학생들의 수많은 코드 중 비슷한 타입들을 추려내는 것입니다. 코드를 몇 가지 타입으로 추려내고 나면, 선생님은 학생 하나하나의 코드를 보고 교육하는 것이 아니라, 비슷한 형태의 코드를 작성한 학생 그룹 전체에게 적절한 피드백을 줄 수 있습니다. 이렇게 그룹 전체에게 피드백을 준다면 선생님은 같은 시간에 더 많은 학생을 교육할 수 있을 것입니다.그럼 이제, 비슷한 코드를 어떻게 찾아내서 분류할지 이전 연구를 보며 알아봅시다. (현기증이 날 수 있으며, 다 이해할 수 없어도 괜찮으니 걱정하지 마세요!)지프의 법칙과 숙제 제출 패턴자연어 처리(Natural Language Processing;NLP)를 배울 때 자주 거론되는 사람이 있습니다. 바로 미국의 언어학자인 조지 킹슬리 지프George Kingsley Zipf인데, 이 사람이 만든 지프의 법칙은 자연적으로 일어나거나 생성되는 특정 정보들이 일정하게 나타내는 경향을 나타낸 것입니다. 지프는 영어로 된 텍스트를 분석하던 도중, 자주 쓰이는 단어를 순서대로 나열하면 각 단어의 빈도는 그 단어의 출현 순위에 반비례함을 찾아냈습니다. 영어에서 가장 많이 사용되는 단어 1~3위가 “the”, “of”, “and” 인데, “the”는 “of”의 약 두 배, “and”의 약 세 배의 빈도를 보입니다.이것을 수학적으로 표현하면, 일정 크기 이상의 영어 말뭉치(corpus)에 들어 있는 단어들의 개수를 전부 세서 그 단어들을 가장 많이 쓰이는 것부터 순위를 1위부터 나열했을 때, 특정 단어의 순위가 k 라면 (즉 전체에서 k번째로 많이 쓰인 단어라면) 그 단어가 말뭉치에서 쓰인 개수는 1/k에 비례한다는 것입니다. 이것을 그래프로 그려보면 다음과 같습니다. 재미있는 사실은, 여기에서 x축과 y축에 log를 씌워 보면 (이것을 log-log scale로 변환한다고 합니다.) 다음과 같은 직선 형태로 변환된다는 것입니다.이것이 도대체 숙제 제출과 무슨 관계가 있길래 이렇게 장황한 설명을 한 것일까요? 위에서 나온 지프의 법칙을 기억하시나요? 학생이 낸 숙제를 채점하다 보면 꽤 많은 학생이 비슷한 방식으로 숙제를 푸는데, 제출된 풀이 방식들을 비슷한 것끼리 묶어 분석해 보니, 이것 또한 지프의 법칙을 따른다는 것이 발견되었습니다. 예를 들어 가장 인기 있었던 풀이 방식으로 100명이 숙제를 제출했다면, 두 번째로 인기 있는 풀이 방식으로는 약 50명이 숙제를 제출했다는 뜻입니다.여기서 우리가 찾아낼 수 있는 인사이트는 무엇일까요? 첫째, 학생들의 숙제들을 비슷한 것끼리 묶을 수 있다면, 그리고 이 분류를 컴퓨터로 자동으로 할 수 있다면 조교가 채점하거나 코멘트를 할 때 써야 할 시간이 상당히 줄어들 것입니다. 둘째, 방법 서너 개에 대해서만 어떻게 채점할지 혹은 어떻게 코멘트할지에 대해 준비를 해놓으면, 그걸로 숙제 대부분을 채점/코멘트할 수 있을 것입니다. 대다수의 숙제는 몇 가지 인기 있는 풀이방식으로 만들어졌을 것이기 때문입니다.그러면 이제 다음 문제는, ‘비슷한 풀이 방식으로 푼 프로그램 코드’를 어떻게 찾아낼 것인가? 를 고민해봅니다. MIT의 Elena Glassman은 이에 대한 해법으로 Overcode를 제시했습니다.Overcode뉴스 기사나 책, 블로그 글 등 자연어로 이루어진 텍스트 데이터를 분석하고, 여기에 어떤 주제가 들어있는지 밝혀내는 연구는 많이 진행 됐습니다. 이를 위한 머신러닝 알고리즘 중 하나가 토픽 모델, Topic model 입니다(토픽 모델에 대해서는 다른 글에서 자세히 다룰 예정입니다). 그러나 토픽 모델링을 프로그래밍 문제에 실제로 적용하기는 쉽지 않습니다. 코드에 사용되는 문법이나 키워드가 자연어와 1:1로 매칭되지 않기 때문에, 기존에 자연어에서 사용되던 모델을 그대로 사용할 수 없기 때문입니다. 가령, 슬쩍 보면 무척 달라 보이는 아래 두 파이썬 코드는 사실 완전히 같게 동작합니다. 이 두 코드를 (사람들이 일상생활에서 사용하는) 자연어를 분석하는 모델로 분석한다면 제대로 된 결과를 낼 수 없는 건 당연합니다.def fibonacci(): parents, babies = (1, 1) while babies < 100 xss=removed>fibonacci()def fib(parents, babies): ‘’’ parents = 1 babies = 1 ‘’’ while True: print ‘This generation has {0} babies’.format(babies) parents = babies # set parents as babies babies = parents + babies # recursively add number of babies if babies >= 100: break fib(1, 1)Elena Glassman이 제시한 Overcode의 목적은 비슷한 로직으로 만들어진 프로그래밍 코드들을 모으는 것입니다. 이제 Overode가 어떻게 작동하는지 간단하게 소개하도록 하겠습니다. 가장 먼저 수행되어야 하는 것은 서로 다른 형식으로 쓰인 소스 코드들을 정리하는 것입니다. 소스코드 정리에는 주석 제거, 줄 및 공백/들여쓰기를 일정하게 맞추는 작업 등이 포함됩니다.Image from Overcode하지만 이 작업만으로는 충분하지 않습니다. 거의 같아 보이는 코드도 실제로 프로그램을 실행하기 전까지는 같은지 알 수 없고, 꽤 달라 보이는 코드도 실제로는 완전히 같게 동작할 수 있기 때문입니다 (여기서 같게 동작한다 함은, 결과를 같게 내는 것 이상으로 결과를 내는 중간과정이 완전히 같다는 것을 의미합니다). 다시 위로 돌아가, fibonacci() 함수와 fib(parents, babies) 함수를 살펴봅시다. 위 두 코드는 기존의 자연어 처리 기법에 따르면 완전히 다른 프로그램일 것입니다. 변수명이 달라서가 가장 큰 이유일 텐데, 사실 컴퓨터의 입장에서 변수는 어떤 값을 할당하는 공간에 불과하며, 그 공간에 어떤 이름을 붙이느냐는 중요하지 않습니다. 코드를 작성하는 것이 사람이기 때문에 공간에 편하게 이름을 붙이는 것뿐입니다. 서로 다른 프로그램에서 어떤 변수가 서로 같은 역할을 하는지, 컴퓨터가 알아내려면 어떻게 해야 할까요? (컴퓨터는 창의적이지 않습니다!)Image from OvercodeElena가 제시한 방법은 프로그램을 실행하면서 변수의 값이 어떻게 바뀌는지를 추적한 것입니다. 아래 두 코드를 보고, 한번 머릿속으로 프로그램을 실행해 봅시다. 학생 B의 코드는 for문으로 5의 3승을 계산했고, 학생 C의 코드는 while문으로 5의 3승을 계산한 것입니다. 학생 B의 코드가 실행됨에 따라 r이라는 변수가 어떻게 변하는지, 학생 C의 코드에서 result가 어떻게 변하는지 확인해보면 둘 다 1 → 5 → 25 → 125 의 값을 가지게 됩니다. 그렇다면 컴퓨터는 이렇게 판단할 수 있습니다. “B의 코드에서의 변수 r과 C의 코드에서의 result가 완전히 같은 방식으로 변하니, 같은 의미로 사용된 것이다.”Image from Overcode이제 같은 의미를 가지는 변수들을 알아냈다면, 컴퓨터는 쉽게 가장 “흔한” 이름으로 변수의 이름을 바꿔치기 합니다. 그러면 처음에 서로 다르게 보였던 코드들도 이제 같아질 것입니다.물론 이것이 다는 아닙니다. 예를 들어, 간단한 테스트 케이스들을 통해 결과를 비교함으로써 변수를 분석하기 전에 먼저 거르는 방법, 너무 흔한 변수들을 처리하는 방법 (예를 들어 완전히 다르게 동작하는 코드들에서도 반복문에서 사용되는 인덱싱 변수들은 같이 변화할 것입니다), 한 변수가 다른 의미론적으로 두 번 사용되는 경우 처리하는 방법… 등이 논문에는 더욱 자세히 적혀있습니다. 궁금한 독자들은 한번 논문을 읽어보도록 합시다.남은 문제들Elena가 제시한 방법은 위에서 보여준 예제와 같은 간단한 코드에서 꽤 잘 동작합니다. 예를 들어, 다음과 같은 문제들이 있습니다.a의 b승을 구해서 리턴하는 프로그램N번째 피보나치 숫자를 리턴하는 프로그램다항식의 미분 결과를 리턴하는 프로그램하지만 대학교에서 1학년만 넘어가더라도 이런 간단한 프로그램 과제는 내지 않습니다. 예를 들어 Elice에서 교육 중인 기초 프로그래밍/ 프로그래밍 유치원 수업을 듣는 학생들은 매우 많은 실습문제를 풉니다. 여기에서 푸는 과제들은 초반 몇 주가 지나면 이 정도의 간단한 프로그래밍 수준을 뛰어넘기 때문에, 코드가 꽤 길어지고 다양성이 생기게 되는데 이런 경우 이 방법은 잘 동작하지 않습니다.또 다른 문제는, 이 방법이 “동작하는” 코드에서만 작동한다는 것입니다. 예를 들어, 수강생들이 아직 기초 문법을 배우고 있다면? 제대로 실행도 되지 않는 코드를 만들었을 때, 비슷한 실수를 한 사람들끼리 묶어주고 싶다면? 아쉽게도 Elena가 제시한 방법은 이렇게 에러가 나는 코드에서는 동작하지 않습니다. 코드가 실행되지 않는다면 변수의 값의 변화를 추적할 수 없기 때문입니다.마치며이번 포스트에서는 학생의 제출 코드를 비슷한 것끼리 묶는(Clustering하는) 방법에 대해 간단하게 살펴 보았습니다. 학생이 낸 비슷한 답안을 모아주는 솔루션은 수학 문제 같은 단답식 문제, 혹은 영어 에세이같은 자연어에 대해서는 이미 상용화가 되어 있습니다. 영어 에세이의 경우 여러분들이 가장 친숙할 만한 상용화된 솔루션은 아마 copy detector일 것입니다.하지만 프로그래밍 코드의 클러스터링은 연구가 계속 진행되고 있습니다. 앞서 말했듯 코드에서 한 글자 한 글자가 가지는 의미가 자연어에서 가지는 알파벳과는 완전히 다르기 때문이기도 하고, 정말 실행을 해 보기 전까지는 어떻게 동작하는지 예측하는 것이 매우 어렵기 때문이기도 합니다. Elice 리서치 팀에서도 프로그래밍 코드에 대한 분석을 자동으로 수행하는 머신러닝 연구를 수행하고 있습니다. 이러한 기술을 통해 선생님이나 조교가 학생을 더욱 효율적으로 지도하고, 컴퓨터의 도움으로 지도에 아낀 시간을 한 단계 더 개인화된 도움을 주도록 하는 것이 Elice의 목표 중 하나 입니다.글쓴이김수인: KAIST 전산학부 박사과정 / Research Lead, Elice김재원: KAIST 전산학부 박사과정 / The Lead, Elice배휘동: KAIST 전산학부 박사과정 / Frontend Lead, Elice#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개
조회수 3961

리디북스 서비스 장애 복구 후기

지난 8월 26일에는 약 21분간 리디북스 서비스 전체가 중단되는 장애가 있었습니다.사실 서버 스택 일부에만 영향을 주는 장애는 눈에 잘 띄지 않지만 꽤 흔하게 발생하는 일입니다. 기기 1대당 외부적인 요인으로 인한 장애가 평균 2년에 1번 발생한다고 가정하면, 서버가 100대 있을 때는 대략 1주일에 1번꼴로 장애가 발생하는 셈입니다.이런 형태의 장애는 서버 스택의 한 곳에서만 발생하므로, 이중화 혹은 클러스터링을 통해서 극복하곤 합니다. 또한 원인이 명확하므로 해당 기술에 대한 이해도가 높다면 비교적 빠른 시간 내에 복구가 가능합니다.그러나 이번에 리디북스가 경험한 장애는 달랐습니다. 현재 리디북스는 2개의 데이터센터와 클라우드에 인프라가 분산되어 있는데, 이 중에서 1차 데이터센터의 전원 공급에 문제가 생겨 특정 서버 랙에 있는 서버 17대가 동시에 내려간 것입니다. 즉, 소프트웨어나 머신의 물리적인 장애가 아닌, 데이터센터의 장애였습니다. AWS로 비유를 하자면 가용 영역(Availability Zone)의 장애라고 할 수 있겠습니다.원인에 대해이번 장애의 근본적인 원인은 데이터센터가 전원을 정상적으로 공급해주지 못한 것입니다. 물론 데이터센터 혹은 클라우드 서비스(IaaS)는 고객사에게 전원과 네트워크를 안정적으로 제공해주어야 하는 의무가 있습니다.하지만 이들 역시 천재지변이나 사람의 실수에 대한 대비가 100% 완벽할 수는 없습니다. 따라서 이러한 점을 사전에 고려하고 인프라를 설계하지 못한 것이 2차적인 원인입니다.이번 계기를 통해 데이터센터 이중화를 계획하게 되었고, 사용 중인 클라우드 역시 지역(Region) 전체에 장애가 생길 경우에 대한 대비가 되어있지 않아, 이번 계기로 복제 계획(Geo-Replication)을 세우게 되었습니다.구체적인 상황당시 전원이 차단되어 강제 종료된 서버들은 아래와 같습니다.데이터베이스 프록시 x 2메인 리버스 프록시 x 1읽기 분산용 MySQL 슬레이브 x 1서점용 웹 서버 x 3추천 알고리즘 API 서버 x 1알림센터 API 서버 x 2메인 스토리지 서버 x 2출판 플랫폼용 데이터베이스 x 2테스트 및 배치 작업용 서버 x 3그림으로 표현해 보자면, 대략 아래와 같은 상황에서… 아래와 같은 상황이 된 셈입니다.서버 스택의 여러곳에 순간적으로 장애가 발생한 상황공인 IP가 할당된 메인 프록시 서버 중 1대가 내려갔지만, 실제로는 아래와 같이 가상 IP로 구성을 한 상태였기 때문에 대기 중인(stand-by) 프록시가 동작하여 곧 서점에 장애 공지를 띄울 수 있었습니다.[이미지 출처: DigitalOcean™]공지 이후의 움직임우리는 데이터센터의 복구 시점을 명확히 알 수 없어서 신규 구축(provisioning)을 시작함과 동시에, 서버들의 물리적인 위치 이동을 고려하고 있었습니다. 그러나 다행히 10분이 지난 시점에서 전원 문제는 해결되었고, 서버들은 순차적으로 부팅이 완료되었습니다.일부 서버들은 부팅 과정에서 예상치 못한 지연이 발생하기도 하였지만, 모든 서버의 부팅이 완료된 이후에도 서비스는 완전히 정상으로 돌아오지 않았습니다. 당시 우리가 겪었던 문제와 해결책은 아래와 같습니다.A. 읽기 분산용 MariaDB 슬레이브의 복제 지연(replication lag) 문제슬레이브 서버의 부팅이 완료되자 데이터베이스 프록시(HAProxy)는 해당 서버를 정상으로 간주하여 라우팅 대상에 포함하게 되었고, 애플리케이션 서버들은 정상적으로 커넥션을 맺기 시작하였습니다. 하지만 해당 슬레이브는 수십 분간 마스터를 따라잡지 못한 상태였기 때문에 최신 데이터가 보여지지 않는 문제(stale data)가 있었습니다. 우리는 즉시 해당 슬레이브를 제거하였고 지연이 사라진 이후에 다시 서비스에 투입하였습니다.B. 읽기 분산용 슬레이브의 웜업(warm-up) 문제복제 지연은 사라졌지만 서버의 CPU 사용량이 크게 높은 상태가 한동안 유지되었고, 응답속도는 정상적인 슬레이브에 비해서 많이 느렸습니다. 왜냐하면 캐시가 비워진 상태에서 바로 서비스에 투입되어, 캐시 미스가 휘몰아치는 현상(cache stampede)이 발생하였기 때문입니다. 따라서 간단한 쿼리도 평소보다 오래 걸렸고, 그대로 둔다면 커넥션풀이 꽉 차는 현상이 발생할 것으로 예상되었습니다.곧 우리는 HAProxy로 해당 서버의 가중치를 10%로 낮추어 인입되는 쿼리의 양을 조절하였으며 응답속도는 정상 수치로 돌아오게 되었습니다. 이후 스크립트를 작성하여 수동으로 캐시를 채워나감과 동시에 점차 가중치를 높여 처리량을 정상화하였습니다.프로덕션에서 사용하는 서버는 innodb_buffer_pool 이 100G 이상으로 매우 크게 설정되어 있으며, 재시작 시 캐시가 날아가는 현상을 해결하기 위해 innodb_blocking_buffer_pool_restore 옵션을 적용하고 있습니다. 하지만 지금처럼 메모리를 덤프하지 못하고 비정상 종료가 된 상황에서는 해당되지 않았습니다.C. 인메모리 데이터의 보존 문제알림센터는 다양한 프로모션과 개인화된 정보를 전달해주는 공간입니다. 알림센터의 특징은 데이터의 영구 보존(persistency)이 필요하지 않고, 매일 수백만 건의 개인화된 메시지가 기록된다는 것입니다. 이러한 특징은 인-메모리 데이터베이스에 적합하므로 우리는 Redis를 마스터/슬레이브로 구성하여 저장소로 사용하고 있었습니다.어떠한 이유로든 Redis를 재시작해야 할 경우가 생기면, 메모리 상의 데이터가 날아가는 것을 방지하기 위해 주기적으로 스냅샷을 남기고 있습니다만, 이번에는 로그가 마지막까지 기록되지 못한 상태에서 메모리의 데이터가 날아가 버렸습니다.다행히 알림 발송과 관련된 메타정보는 모두 MariaDB에 기록하고 있으므로, 우리는 이를 기반으로 소실된 시점부터의 알림을 순차적으로 재발송할 수 있었습니다. 물론 모든 알림이 신규 상태로 간주되어 아이콘이 잘못 노출되는 문제가 있었지만, 고객님들은 너그럽게 이해해 주신 것 같습니다. 😅그래서 앞으로는?리디북스 DevOps 멤버들은 이번 데이터센터 장애를 통해 현재 인프라의 한계점을 실감하였고, 앞으로의 개선 방향에 대해 고민하게 되었습니다.몇 가지를 정리하면 다음과 같습니다.랙 단위로 장애가 발생할 수 있음을 인지하고 대비하자.같은 기능을 하는 서버를 하나의 랙이나 같은 가용 영역에 두지 말자.2차 데이터센터는 더 이상 옵션이 아닌 필수다.낙뢰나 지진으로 인해 데이터센터에 문제가 생길 수도 있다.긴급하게 프로비저닝이 필요한 상황에 대비하자.문서화가 되어 있더라도 경험이 없다면 동일한 구성에 많은 시간이 소요된다.모든 구성요소들에 대한 Ansible 스크립트를 작성하여두자.캐시 웜업 스크립트도 작성하여 두자.백엔드 구성요소들 간의 불필요한 의존 관계를 끊자.단 한 줄의 코드라도 참조하고 있다면 이는 독립적인 것이 아니다.언제나 서비스 지향적인 설계를 추구하자.Uptime을 관리하자.최대 180일을 기점으로 무조건 리부팅을 하자.재시작 과정에서 다양한 문제와 개선점이 발견될 것이다.커널 패치, 보안 패치를 할 수 있는 것은 덤이다.아래와 같은 긍정적인 면도 발견하였습니다.장애 상황이 실시간으로 Slack 채널을 통해 전파되었음진행 상황에 대해 모두가 동일한 수준으로 이해할 수 있었다.모니터링 연동(integration) 기능 때문에라도, Slack은 유료로 구매할만한 값어치가 충분하다.같은 기능을 하는 서버들이 다른 랙에 많이 분산되어 있었다.인프라가 확장될 때마다 빈 공간에 필요한 서버를 추가했을 뿐이지만, 자연스럽게 물리적인 위치가 분산되는 효과가 있었다.이 외에도 특정 클러스터를 구성하는 노드들을 분산하여 배치시키자.서버별로 오너쉽이 부여되어 있어서 빠르게 복구가 된 점여러 명의 백엔드 개발자들이 병렬적으로 복구를 진행할 수 있었다.마지막으로넷플릭스의 엔지니어들은 무질서한 원숭이(Chaos Monkey)라는 프로그램을 만들어서 운영한다고 합니다. 이 원숭이는 서비스 인스턴스들을 무작위로 중단시키는 역할을 합니다. 다소 황당하게 들리지만, 넷플릭스에는 일부 서비스에 장애가 발생하더라도 나머지 부분은 문제없이 운영되어야 한다는 원칙이 있으므로, 이를 수시로 시뮬레이션하는 과정을 통해 복구 능력을 높여둔다는 것입니다.실제로 이렇게 급진적인 아이디어를 실천할 수 있는 회사는 매우 드물 것입니다. 하지만, 우리는 이번 계기를 통해 무질서한 원숭이의 필요성을 절감하였고, 이로 인해 서버를 주기적으로 리셋하는 정책을 만들게 되었으며 모든 단일 장애점(SPoF)에 대한 대비를 시작하게 되었습니다.장애를 단순히 피해라고만 생각한다면, 서로를 비난하고 책임을 전가하는 상황이 펼쳐질 것입니다. 하지만 고객의 불편함과 맞바꾼 매우 비싼 경험이라고 생각한다면, 보다 튼튼하고 회복탄력적인 시스템을 갖추기 위해 노력하게 될 것입니다. 그러다 보면 언젠가는 데이터센터 전체에 문제가 생겨도 버틸 수 있는 모습으로 진화할 것이라고 생각합니다.#리디북스 #장애복구 #역경돌파 #개발 #개발후기 #개발자 #서버개발 #서버
조회수 2241

[어반베이스 피플] 알고리즘으로 전 세계 도면을 변환하다_CV 개발자 인터뷰

최근의 가장 핫한 연구분야인 '자율주행'의 바탕에는 '컴퓨터 비전'이 필요하다는 사실을 아셨나요? 홍채인식, 스노우 어플도 '컴퓨터 비전'을 사용한 사례입니다. 우리의 가까이 다가와 있지만, 기술 자체에 대해서는 어딘가 생소합니다. 어반베이스의 CV개발자 대희님이 멀고도 가까운 컴퓨터 비전의 모든 것을 알려드립니다!멀고도 가까운 컴퓨터비전(CV)의 모든 것Q. 간단한 자기소개를 해주세요.네, 안녕하세요. 어반베이스에서 컴퓨터 비전(CV) 개발자 윤대희라고 합니다.Q. CV가 생소한 분들이 많을 것 같아요. CV에 대해 쉽게 설명 부탁드려요.CV는 컴퓨터비전(Computer Vision)의 약자에요. 쉽게 말해 컴퓨터가 인체라면 '눈'역할을 담당해요. 카메라를 사용해 입력받은 이미지나 영상을 프로세싱하면 '컴퓨터 비전 처리했다'고 말해요. 예를 들면, 카메라 어플 내에서 얼굴을 인식한 후에 안경을 달아준다거나, 눈을 크게 해준다거나 그런 것들을 컴퓨터 비전에서 처리할 수 있는 거죠. Q. 그렇다면 컴퓨터 비전의 시작은 언제부터인가요? 최근에 생긴 기술 같은데요. 그렇지 않아요. CV의 시작은 60년대부터 있었어요. (60년대요?) 네. 달 표면을 찍은 위성 사진의 화질을 개선하기 위해 디지털 이미지 프로세싱 분야가 탄생했어요. 그동안 기술력이 뒷받침되지 않아서 무언가를 할 수 없었을 뿐이에요. 하드웨어, 즉 카메라 장비나 처리 기술이 발전하면서 이제서야 붐이 일어난 거죠. Q. CV 개발이 활발히 이루어지는 분야가 있을까요?핸드폰 카메라 어플, 자율주행, 홍채인식 등에도 모두 CV가 필요해요.특히 요즘 떠오르고 있는 분야가 자율 주행이에요. 자율주행을 하려면 주행 시 주위 환경을 모두 살펴해야 해요. 차선이나 신호, 보행자와 차량도 봐야 하죠. 실시간으로 영상을 인식하고 처리하는 분야이니 CV 개발이 활발해요.의학 쪽에서도 많이 써요. MRI 사진을 찍은 후 세포의 영역을 볼 때, 의사가 그 모든 세포를 볼 수가 없으니까 CV 처리를 한 후 이상이 있는 세포의 특징만 뽑아내는 거죠. 아까 말씀드렸듯이 항공 쪽에서는 옛날부터 많이 썼어요. 최근에는 무인 우주선의 이미지 분석에 사용돼요. 무인 우주선에서 여러 가지 이미지 데이터를 보내오는데, 기상상황에 의해 이미지를 제대로 판단하지 못하는 경우가 있어요. 그래서 이런 이미지들을 보정하거나 특징을 뽑아내는, 전처리 과정을 CV 통해 해야 해요. 자율주행의 차량인식스노우 어플 (출처 : 스노우 앱 페이지)홍채인식 (출처 : 삼성전자 블로그)Q. 컴퓨터 비전에 대해 조금 더 자세히 알 수 있을까요?최근에 나온 명함인식 어플도 컴퓨터 비전을 사용해요. 명함에 사람의 사진이 붙어 있는 경우도 CV를 통해서 인식하게 될 거예요. 컴퓨터의 입장에서 사람의 얼굴은 공통적인 특징이 있어요. 눈 밑, 코 밑은 어두울 것이고 광대 이마 등은 밝을 거예요. 이런 패턴을 분석해서 명함 내의 얼굴을 인식하게 만드는 것이 CV에요.Q. 제가 알기론 머신러닝도 이미지를 인식하고 분류해주는 역할이라고 알고 있어요. 컴퓨터 비전과 머신러닝은 어떻게 다른 건가요?간단히 말해 컴퓨터 비전은 '눈', 머신러닝은 '뇌' 역할이죠.CV는 머신러닝에 앞선 전처리를 해주는 역할이에요. 앞서 말했듯 CV를 통해 사람 얼굴을 인식할 수 있어요. 우리 모두 눈 밑, 코 밑은 어둡고 광대 이마는 밝게 인식되겠죠. 하지만 사람마다 패턴이 미묘하게 다를 거예요. 또한 같은 사람이라도 각도나 조명에 의해 패턴이 달라질 거고요. 그래서 이런 패턴을 분석해주는 게 머신러닝이에요.'사람'을 분류해주는 건 CV로, 그 사람들 중 '홍길동'을 인식하는 것은 머신러닝인거죠.사람을 분류해주는 건 CV, '홍길동'을 인식하는 건 머신러닝CV 개발자, 어떻게 시작했나요?Q. 개발자가 되기까지의 과정이 궁금해요. 원래 컴퓨터공학을 전공하셨나요?아뇨, 기계설계를 전공했어요. 요즘은 기계 쪽에서도 공장 자동화를 기본 베이스로 하고 있어서 물건의 바코드 인식이나 라벨 색상 처리도 모두 CV의 영역이에요. Q.기계설계 중에서도 다양한 분야가 있는데, CV를 선택하신 이유가 있나요?저는 처음부터 CV를 생각했어요. 과 특성상 하드웨어 설계와 소프트웨어 설계를 동시에 하는데 저는 소프트웨어 쪽에서도 CV를 많이 했어요. CV는 다른 것에 비해서 확실히 재밌어요. 카메라로부터 받은 데이터들을 처리하는 과정이 눈으로 확실히 보이니까 훨씬 재미있게 느껴져요.Q. 운영하고 계신 블로그를 구경한 적이 있는데, 굉장히 정리가 잘 되어 있더라고요. 블로그 사이트는 어떻게 시작하게 된 거예요? 저는 누군가에게 무언가를 알려주고, 지식을 공유하는 걸 좋아해요. 제가 알고 있는 것을 함께 공유하고 공부하기 위해 블로그를 시작했어요. 어떤 것을 설명하는 방법이 그것에 대한 가장 좋은 공부법이라는 말도 있잖아요? 정보를 함께 공유하고 피드백도 받으면서 굉장히 도움이 많이 됐어요. 그래서 지금도 계속 쓰고 있어요.대희님의 블로그블로그의 강좌 목록Open CV 강좌많은 러브콜을 뒤로하고, 어반베이스에 합류하게 된 이유Q. 어반베이스의 합류 과정이 남달랐던 것으로 알고 있어요. 일종의 '스카웃 당했다'고 말할 수 있을 것 같은데요. 합류 과정을 알려주실 수 있을까요?제가 CV 온라인 강의를 진행하고 있었는데, 그때 저를 보시고 연락을 주셨어요. 강의하는 홈페이지에는 개인적인 연락처를 적어 놓지 않고 제 블로그 링크만 달아놨었어요. 그런데 제 블로그에 있는 메일 주소를 찾으셔서 연락을 주셨어요. Q. 어반베이스의 제안을 받고 어땠어요?좋았어요. 말씀해주신 업무를 제가 할 수 있을 것 같았고, 또 면접을 함께한 현우님에게 굉장히 좋은 인상을 받았어요. 부담을 안 가지고 편하게 얘기했는데 좋게 봐주셨던 것 같아요.Q. 여러 산업분야에서 CV로 할 수 있는 것들이 굉장히 많은데 어반베이스를 선택한 이유가 있을까요?확실하게 ‘사람’의 이유가 가장 컸던 것 같아요. 어반베이스에서 저를 믿고 먼저 연락을 주셨고, 함께 이야기를 나누다 보니 좋으신 분이라는 게 확실히 느껴졌어요. 사실 다른 곳에서도 연락이 많이 왔지만 일단 제 능력을 믿어주는 사람과 같이 일하고 싶었어요. 제 능력을 펼치고 싶어도 그렇게 할 수 없는 경우가 있잖아요. 하지만 어반베이스는 확실하게 제 의견을 반영해주시고 제가 하고 싶은 일을 할 수 있는 환경이라는 생각이 들었어요. 결국은 ‘사람’이 좋아서 선택한 거죠. 그게 가장 큰 이유에요. Q. 어반베이스는 VR, AR을 활용해서 공간데이터 사업을 하는 곳이잖아요. 어반베이스 비즈니스에 대한 첫인상은 어땠어요?저는 되게 좋았어요. 자동화한다는 것 자체에 메리트가 느껴졌어요.기계공학을 전공했지만 기계공학에서 건축과 닮은 부분이 있어요. 기계 도면 역시 2D로 그린 후 3D 파일을 또 만들고, 그 이후 텍스처를 설정하는 과정을 거쳐요. 분야만 다를 뿐 일련의 과정들이 건축과 굉장히 비슷해요. 그래서 막연히 '2D 도면을 3D로 바꿔주는 과정을 CV로 자동화 처리하면 괜찮지 않을까?'라는 생각을 했었어요. 분야가 기계에서 건축으로 바뀌었을 뿐, 제가 가지고 있었던 생각이랑 어느 정도 맞아떨어지더라고요. 그래서 어반베이스 비즈니스에 대한 생각이 굉장히 좋았어요. Q. 그렇다면 입사하신 이후 느꼈던 어반베이스의 개발 환경은 어때요? 굉장히 좋아요. 사람에 대한 믿음이 확실히 느껴져요. 맡은 일에 대해 믿어준다는 느낌이 있어요. 그리고 다른 분들에게 질문을 해도 항상 본인 일을 멈추고 먼저 알려주려고 하세요. 그런 모습을 보며 억압하는 분위기가 없고, 협업을 중시하고 사람을 중시한다는 걸 많이 느꼈어요. 물리적인 환경도 좋아요. 사양 좋은 맥북을 새로 사주셨거든요. 하하사양 좋은 맥북과 함께 일하는 대희님어반베이스 기술의 핵심, 도면 변환 알고리즘을 개발하다Q. 대희님이 하고 있는 일을 소개해주세요. 건축도면 이미지(2D)를 읽어서 3D 모델로 만들어주는 알고리즘을 개발하고 있어요.도면 변환에 가장 중요한 것은 좌표에요. 꼭짓점만 알면 벽을 그릴 수 있잖아요? 2D 도면상 좌표의 위치를 알아내서 벽, 문, 창문의 위치를 만들어내는 역할이에요. 좌표의 위치를 안다면 그 도면에 대해서 3D로 만들 수 있는 거죠. 3D로 만드는 과정까지 제가 담당하고 그 후의 렌더링은 3D 파트에서 담당하고 계세요. 대희님의 작업 과정Q. 업무 일과나 업무 스타일은 어때요?하루 종일 개발밖에 안 해요. 알고리즘 만든 후에 도면을 대입해서 처리가 되는지 확인하고, 오류가 있으면 수정하는 이런 패턴의 반복이죠. 어느 정도 완성이 됐다면 다음 단계로 넘어가는 거죠.제 업무 스타일은 목표한 게 있으면 끝까지 하는 스타일이에요. 해야 할 일을 정해놓고 그 일을 모두 마쳐야 퇴근해요. (막히는 경우가 생길 수도 있지 않나요?) 그러면 쉬지 않고 계속 개발하면 돼요. (웃음)Q.대희님은 어떤 분들과 협업을 많이 하나요? 2D에서 3D로 바꿔주는 도면 변환 부분, 즉 가장 베이스가 되는 부분을 만들고 있다 보니 개발 부문 대부분과 협업을 하고 있어요. 제가 만든 것을 사람들에게 보여줘야 하니까 UI/UX팀과 협업을 많이 해요. 제가 만든 API에 대해서도 이야기해야 하기 때문에 API, 백엔드팀과도 협업을 많이 하고요.Q. CV 개발자로 입사 후 가장 기뻤을 때는 언젠가요?제가 입사한 후 CV 코드 리뷰를 하고 코드를 개선해서 확실하게 좋아진 것이 보일 때 정말 좋았어요. 제 의견이 반영이 되어 바뀔 수 있었고, 결과적으로 결과도 좋았으니까요. 그 부분이 가장 좋았어요.제가 만든 알고리즘이 도면 인식을 잘 할 때도 기분이 좋죠. 도면을 넣었을 때 내가 생각한 대로 처리가 잘 되고 생각한 대로 오류가 잘 날 때 뿌듯해요.Q. 앞으로 어반베이스 내에서 개발 계획은 어떻게 되나요?이번 해에는 도면 변환 알고리즘이 구동될 수 있게끔 만들고, 내년 초부터 코드를 수정하면서 알고리즘의 정확도를 높이는 작업을 계속하려고 해요. 그다음엔 해외 도면을 처리하는 과정을 생각하고 있어요. 데드라인이 정해져있는 프로젝트는 아니지만 최대한 빨리 진행하려고 해요. 2D에서 3D로 도면을 변환하는 개발을 저 혼자 하고 있어서 제가 일을 쉬면 프로젝트 자체가 아예 멈춰 버리니까, 되도록 빨리해야죠. 그렇게 해야 수정하고, 피드백을 받고, 출시하는 모든 과정들이 빠르게 진행될 수 있으니까요.CV 개발자에게 가장 필요한 역량은 코딩 능력이 아니다.Q. 여러 분야의 개발자가 있지만 '컴퓨터 비전(CV) 개발자'는 많이 들어보지 못했는데 최근 들어 '컴퓨터 비전 개발자'의 채용이 굉장히 늘고 있는 것 같아요. 앞으로의 CV 시장을 어떻게 예측하세요?사실 이전까지는 기술력 부족으로 할 수 있는 것이 많이 없었어요. 카메라로 찍었을 때 화질이 안 좋으면 CV 처리하기가 굉장히 힘든데 최근에 카메라 성능이 최근에 굉장히 좋아져서 처리 과정이 수월해진 거죠. 그래서 'CV 개발자'에 대한 수요도 늘고 있어요. 이미지로 무언가를 한다면 무조건 CV 개발자가 필요해요. 요즘은 손쉽게 카메라를 설치하고 이미지/영상 데이터들을 얻을 수 있으니까, 더욱 많이 필요할 거예요. 모든 산업분야에서 CV와 관련된 더 많은 개발자, 더 많은 기술이 필요할 것이라고 생각해요.Q. CV 개발자에게 가장 필요한 역량은 뭘까요? 코드를 잘 짜는 것보다 수학을 잘 하는 게 중요해요. 대부분의 이미지 인식 과정에서 수학공식이 사용되기 때문에 후처리를 하려면 수학을 잘 해야 해요. CV는 공업수학, ML은 통계학이 많이 관련되어 있어요.Q. 그러면 코드를 짤 때 코드에서 막히기보다 수학 공식에서 막힐 때가 있잖아요. 그럴 땐 어떻게 해요?늘 거기서 막혀요. 학교를 최근에 졸업했으니 아직 공식이 머릿속에 많이 남아있어서, 막힐 때가 있으면 이런저런 다른 공식 적용을 시도하죠. 어반베이스의 알고리즘으로 전 세계 도면을 변환하다Q. 좋아하거나 롤모델로 삼고 있는 사람이 있나요?루카스 카나데 교수님이요. CV 분야의 세계적인 권위자이신 분이에요. 교수님의 이름을 딴 함수가 있을 정도로요. 그 정도의 명예와 재력이 있는데도 불구하고 꾸준히 공부하고 논문을 발표하시는 모습도 정말 멋있다고 생각해요.Q. 혹시 CV 외에 어반베이스 내에서 욕심나는 분야가 있어요?머신러닝이요. CV에서 전처리를 하고 머신러닝 후에 후처리에 또 CV가 필요해요. 그래서 중간 영역인 머신러닝을 배우면 모든 프로세스를 혼자서 처리할 수 있으니까 머신러닝을 공부해보고 싶어요.   Q. 어반베이스가 혁신적인 기술을 통해서 많이 이슈가 되고 있고, 많은 컨택이 오고 있잖아요. 스스로 어반베이스의 개발자로서 어반베이스의 가능성은 어떻다고 생각해요?확실히 굉장히 높다고 생각해요. CV로 처리해서 자동화한다는 것 자체가 굉장히 뜨고 있는 기술이고 앞으로 계속 발전할 기술이기 때문에 가능성도 굉장히 크다고 생각해요. Q. 대희님의 포부는 뭐예요?전 세계의 2D 도면을 어반베이스의 알고리즘을 통해 3D로 변환할 수 있게끔 만드는 거죠. 단기간은 국내, 중장기적으로는 해외 도면까지요.컴퓨터 비전. 그저 어렵게만 느껴졌던 단어인데, 이번 인터뷰를 통해 컴퓨터 비전과 많이 가까워진 느낌이 듭니다. 어반베이스의 핵심기술을 담당하고 있는 CV 개발자 대희님! 대희님이 만든 알고리즘으로 전 세계 도면이 3D로 변환될 날이 왔으면 좋겠습니다 :)출처: https://blog.naver.com/urbanbaseinc 
조회수 774

[Buzzvil People] Alan Kim, Senior Software Engineer

 Buzzvil People에서는 다양한 배경과 성격 그리고 생각을 지닌 버즈빌리언들을 한 분 한 분 소개하는 시간을 갖습니다. 어떻게 버즈빌에 최고의 동료들이 모여 최고의 팀을 만들어가고 있는 지 궁금하시다면, 색색깔 다양한 버즈빌리언들 한분 한분의 이야기가 궁금하시다면, Buzzvil People을 주목해주세요.1. 간단한 자기 소개 부탁드립니다. 안녕하세요. 김진언입니다. 영어 이름은 Alan Kim 이고, 현재 버즈빌에서 클라이언트 팀의 리더를 맡고 있습니다. 저는 2002년에 병역 특례로 IT업계에서 근무를 시작했고, 첫 직장에서는 연구소 장비들에 들어가는 소프트웨어 개발을 하다가 그 뒤로 모바일 게임 포팅, 게임 서버 개발 등 지금까지 14년 동안 여러 회사에서 여러가지 업무를 해 왔습니다. 소프트웨어를 만드는 능력이 뛰어난 분들은 워낙 많기 때문에  A급 개발자라고 소개할 수는 없겠지만(^^) 컴파일러 관련 시스템 개발이나 게임, 네비게이션 시스템 등 꼭 APP개발에 국한되지 않은 다양한 경험을 해 왔기 때문에 그런 장점을 살릴 수 있는 부분에서는 나름대로 역할을 하고 있다고 생각합니다.  저는 예전부터 개발자로서 여러가지 경험을 하는 것을 중시해 왔는데요. 그러다보니 임베디드 시스템부터 게임, 게임 서버, PC 툴이나 스마트폰 관련 개발까지 다양한 분야의 경험을 쌓아올 수 있었습니다. 그런데 요즘에는 다양한 경험을 하는 것보다 어떤 개발을 하든지 간에 지켜나가야 하는 기준을 세우는 것이 중요하다는 생각을 많이 하고 있습니다. 그러다 보니 코드 자체 보다는 코드를 작성하는 방식에 대한 고민들을 많이 하게 되는 데요. 최근에는 ‘클린 코드’에 대해 많이 관심을 가지고 있습니다. 요즘에는 과거에 비해 Computing resource나 컴파일러 최적화 등이 눈에 띄게 발전해왔습니다. 따라서 무조건 효율좋은 코드를 짜기보다는 조금 효율은 부족하더라도 Readability가 잘 갖추어진 코드를 짜는게 중요하다는 생각을 하게 되었고 클린코드를 위해 고민해야 하는 모듈화 방법이나 디자인 패턴에 대해서 여러가지로 고민 중입니다. 실제로 저희 팀을 운영할때도 굉장히 강조하고 있는 부분이기도 합니다. 개발 이외의 성격적인 부분으로는 평소에 말수가 적어서 종종 과묵한 사람이라 오해받고는 하는데요. 표현력이 서툴러 말수가 적을 뿐, 다른 분들을 싫어하는 게 아니니 오해하지 않으셨으면 좋겠습니다. ^^  2. 어떻게 버즈빌에 오시게 되셨나요? 버즈빌과의 인연을 설명하려면 먼저 Jay와 슬라이드 조이라는 미국 회사를 말씀 드려야 하는데요. Jay는 인포뱅크라는 회사에서 처음 인연이 시작된 동료인데, Jay가 스타트업을 창업한 후 1년쯤 지난 시점에 저에게 연락이 와서, 같이 일해보자는 제안을 했고 그렇게 슬라이드 조이에 조인했습니다.  그 당시에 저는 인프라웨어라는 회사에서 게임 서버를 개발하고 있었는데요. Jay가 권유했던 그 시기가 마침  진행했던 프로젝트가 완료된 시점이었고, 개발자로서 이런 저런 고민을 하던 시기였습니다. 내가 개발하고 싶은 것, 배워보고 싶은 것, 도전해보고 싶은 것과 같은 부분을 현 회사에서 충족할 수 있느냐에 대한 갈등이 심했던 때 였죠. 원래 저는 직장을 선택함에 있어서 제가 정말 하고 싶은 일인지와 리스크가 크더라도 그 결과를 구성원이 함께 공유할 수 있는 구조를 가지고 있는지를 많이 고민했었는데요. 결혼을 하게 되면서 자연스레 조금 더 안정적인 직장을 찾고 싶어서 들어가게 된 곳이 인프라웨어라는 회사였습니다. 하지만 그곳에서 1년간 문제 없이 일하다보니 안정적인 점은 좋았지만 제 의견이 반영되기 힘들다는 점과 개발과정에서 소통이 중시되지 않는다는 점이 저와는 맞지 않는 부분이라고 생각하고 있었습니다. 그렇기 때문에 좋은 타이밍에 연락이 왔다 생각하여 큰 고민 없이 자연스럽게 합류하게 된 것 같습니다. 물론 미래가 불확실 할 수 있는 스타트업으로 가는 것에 대해서 가족들도 염려했지만 당시 슬라이드 조이를 이루고 있던 멤버들이 정말 훌륭하고 의견들도 잘 맞았기 때문에 슬라이드 조이로의 합류를 결정하게 되었던 것 같습니다. 그 후, 여러가지 우여곡절이 있었지만, 슬라이드 조이도 상당한 성장을 이루었고 마침 좋은 기회로 버즈빌과 합병이 되면서 지금은 버즈빌에서 클라이언트 개발팀의 리더로 근무하게 되었습니다. 3. 버즈빌에서 어떤 업무를 담당하고 계신가요? 현재 클라이언트 팀의 리더를 맡고 있지만, 슬라이드조이에서는 백엔드를 전담했었고 버즈빌에서 근무를 시작할 시점에는 광고 서버쪽을 다뤘기 때문에 아직도 약간의 서버쪽 업무를 병행해 가면서 일하고 있습니다. 차츰 앱 서버를 포함한 백엔드쪽 업무를 줄이고, 클라이언트 팀 리더로서의 업무에 주력하기 위해 일부 업무를 서버 팀 개발자에게 옮기고 있습니다. 버즈빌 클라이언트 팀의 업무가 일반적인 클라이언트 개발과 다른 점이 있다면 단순히 하나의 앱을 개발하는 것이 아니라 stable 한 SDK를 개발해야 한다는 점입니다. 여러 버즈스크린 파트너들의 다양한 개발환경에서 동작되어야 하고, 어떤 상황에서든 항상 동작되어야 하기 때문에 시스템 전반에 걸친 깊은 이해가  이 필요한 일입니다. 때문에 단순히 소프트웨어 개발자 보다는 깊이 연구하고 세밀하게 설계하는 능력을 가진 사람이 필요하고 현재 클라이언트 팀의 경우 그런 사람들로 구성이 되어있다고 생각합니다.   클라이언트 팀의 리더가 되면서 아무래도 개발 자체보다는 팀원들이 개발을 잘 할 수 있도록 하는 환경들에대해 더 많은 고민을 하고 관련 업무들을 하고 있습니다. CI(Continuous Integration)나 개발 프로세스 등 흔히 말하는 DevOps에 관련된 일들을 하고 있습니다. 뿐만 아니라 구현 방식에 대한 최종적인 방향을 결정하는 의사결정이나 개발 과제가 내려오는 과정과 개발이 완료된 과제들에 대해 외부의 팀과 커뮤니케이션이 필요한 사항들을 맡아서 관리하고 있습니다. 4. 스타트업에서 혹은 광고업계에서 일하는 느낌이 어떠세요? 스타트업은 한 사람, 한 사람의 목소리가 회사의 성장에 직접적으로 영향을 줄 수 있다는 점이 큰 매력이라고 생각합니다. 저의 경우에는 게임 서버 개발(수천명 규모), 자동차 관련 TF팀(수백명 규모), 스타트업 두 곳, 또 다른 게임회사(60명 규모) 등 많은 케이스의 회사에서 근무를 해 왔기 때문에 큰 차이를 직접적으로 느낄 수 있었는데요. 저에게 스타트업이란 “회사의 성장에 직접적으로 기여할 수 있는 곳” 입니다. 대부분의 회사는 규모가 커짐에 따라 어쩔 수 없이 여러가지 체계가 도입되고, 문화적으로도 경직화 되는것 같아요. 사원 개인이 회사의 의사 결정에 참여 하기는 정말 어렵고, 위로부터 내려온 결정 사항에 자신의 동의 여부와 관계 없이 일이 하는 경우가 대부분입니다. 개인의 개성은 최소화하고 회사라는 체계의 한 부품으로만 움직이게 되고요. 동기부여 없이 그에 따른 무의미한 업무가 반복되면 회사 생활이 정말 재미 없게 되는 거 같습니다. 예를 들어, 특정 Feature를 개발 함에 있어서도 왜 이 Feature에 대한 개발이 필요한지, 어떤 맥락에서 이 Feature의 구현이 중요한지에 대한 커뮤니케이션 없이 그저 과제만 주어지는 경우는 해당 업무에 대한 흥미를 떨어뜨린다고 생각합니다. 하지만 스타트업의 특성상 다른 팀과의 의사소통이 활발하게 진행될 수 있는 환경이다 보니 같은 일을 하더라도 좀 더 큰 맥락에서 파악하고 내가 하는 일에 대한 의미와 기대효과를 고민해보면서 일 할 수 있다는 것이 장점이라는 생각이 드네요. 5. 이것만큼은 버즈빌이 참 좋다! 어떤 게 있으실까요?  아마 많은 분들도 공감하시겠지만, 회사 일이란 게 혼자 하는 게 아니니만큼 같이 일하는 직원이 어떤 사람이냐에 따라서 자신의 업무에도 영향을 받게 되죠. 일에 대한 열정도 없고, 월급 생각하며 대충 일하는 직원과 같이 일하게 되면 다른 팀원들도 영향을 받게 됩니다. 안 좋은 케이스의 일을 몇 번 겪고 나니 일 할 때는 같이 일하는 사람이 어떤 사람인지에 대해 촉각을 많이 세우게 되었죠. 그런데 제가 지금 버즈빌에 근무한 지 1년 반이 넘은 것 같은데, 처음 입사할 때나 지금이나 여전히 느끼는 점은 버즈빌에는 ‘능력자들’이 정말 많다는 점입니다. 보통 회사에서는 10명 중 1명 있을까 말까 할 정도로 특출난 인재들이 한 곳에 모여있다는 그 부분이 정말 인상적이었어요. 스펙도 스펙이지만 보통 사회 초년생이라 일컫는 어린 나이 임에도 일에 대한 진지한 태도와 전문성, 빠른 일 처리 속도 등 대부분의 직원들이 ‘능력자’라 부르기에 손색이 없을 정도입니다. 그런 직원들과 매일 생활하니 저 또한 분발해야겠다는 생각과 함께 많은 의욕을 얻고 있어요.   또한 개발자로서 느끼는 버즈빌은 제가 일했었던 다른 회사들과 극명하게 차이가 있는 곳이라는 생각이 듭니다. 회사가 평등한 문화를 가지고 있다고 PR을 하는 경우가 많은데 버즈빌 만큼 실제로도 수평적인 문화를 가진 회사는 처음입니다. 개발에 관련된 여러가지 의사결정을 함에 있어서도 서로의 의견을 존중하고 워낙 뛰어난 사람들이 많다보니 서로에게 많은 것들을 배울 수 있는게 좋습니다. 저도 팀장이지만 팀원들에게 여러가지를 물어볼 때도 많고 팀원들 통해 새롭게 배우는 것들도 많구요. 이렇게 뛰어난 사람들도 많이 있고 이런 사람들 간에 서로에게 시너지를 줄 수 있는 좋은 문화를 가지고 있다는 점은 분명 다른 회사에서 찾아보기 힘든 장점이라고 생각합니다. 저는 합병을 통해 입사했기 때문에, 버즈빌이라는 회사에 기대를 많이 하고 합류하게 되었는데요. 그 점에 있어서는 200% 이상 충족되었다고 생각합니다. 구성원 한 사람 한 사람을 믿고 자신의 업무에 집중할 수 있다는 것은 저에게 있어 매우 중요한 의미이기 때문에, 현재 회사 생활이 무척 만족스럽네요. 6. 개인적인 목표나 꿈이 있으신가요? 있다면, 버즈빌에서의 경험이 어떻게 도움이 된다고 생각하시나요? 먼 미래에 대한 목표는 ‘돈 걱정 없는 편안한 노후’고요.(^^)  사실 이런 목표를 늘 생각하면서 살고 있진 않습니다. 미래보다는 현재가 중요하고 단기적인 목표에 최선을 다하는 것에 보람을 느끼는 편입니다. 당장 생각나는 목표는…혼자만의 여행일까요? 예전부터 같은 일상에 지치거나 슬럼프가 올때면 한번씩 여행을 가서 충분히 쉬고 생각도 정리하는 시간을 가졌었는데요. 버즈빌에는 다양한 국적의 직원들이 많다보니 그들의 성장환경과 문화 이야기를 들으면 저도 당장 떠나고 싶은 기분이 들 때가 있어요.  가정이 있다보니 혼자 여행을 가는게 쉽지만은 않고 지난 3월에 회사 워크샵으로 발리를 다녀 온 이후로 더욱 눈치가 보이기는 하지만, 몽골에 배낭여행을 가는게 너무 하고 싶네요. 그리고… 생각만 하고 실천을 잘 못하고 있는 부분이 있는데, ‘영어권 나라로의 이민’을 위해 기반을 마련하는 것 입니다. 영어권 나라들의 경우 대부분이 한국에 비해서 삶의 방식이 자유롭고 틀에 박힌 부분이 적다는 생각이 들더라구요. 제가 느끼기엔 아직까지 우리나라가 여유가 없고 바쁜 느낌이 강하게 들어서 좀더 여유로운 환경에서 생활해 보고 싶다는 꿈이 있습니다. 무엇보다 영어가 중요할텐데, 버즈빌에서는 많은 의사 소통을 영어로 하고 있다보니 생각해 보면 엄청 좋은 기회이지만, 아직까지 영어 사용을 적극적으로 하지 않고 있어서 다시 한번 마음을 다 잡고 시작해 봐야겠습니다.
조회수 1039

[Buzzvil Culture] 개발팀의 모바일 스터디 그룹이란?

 버즈빌 개발팀의 모바일 스터디 그룹이란? 모바일 잠금화면 미디어 플랫폼 ‘버즈빌’의 개발팀이 진행하는 모바일 스터디 그룹이란, 모바일이라는 큰 주제를 핵심으로 하여 크고 작은 연관된 기술을 리뷰하고 토의하는 스터디 모임입니다. 2018년 7월에 처음 개설되어 현재까지 매주 진행하고 있으며 특정한 기한 없이 지속적으로 진행할 예정입니다. 모바일이라는 핵심 주제를 고지하기는 했지만 사실상 개발에 관련된 모든 주제가 이야기될 수 있으며, 개발 언어, 특정 라이브러리 및 프레임워크, 개발 관련 툴, Google I/O와 같은 각종 컨퍼런스 등 거의 모든 것이 저희의 관심사입니다. 심지어 한 번은 자주 쓰는 단축키에 대해서도 토의한 적이 있습니다. 어떤 목적을 갖고 만들어졌는가? 개발이라는 일은 특히나 최신 이슈에 민감한 분야인 것 같습니다. 빈번하게 일어나는 OS 업데이트와 그에 따른 이슈 처리, 주요 컨퍼런스 내용에 따른 개발 트렌드 변화, 갑작스레 혜성처럼 등장한 개발 라이브러리… 저희 개발자들은 이러한 이슈에 항상 귀를 기울여야 하며, 그에 대해 생각을 정리할 필요가 있습니다. 또한 이러한 기술 습득은 저희 직원들의 커리어에도 중요한 지표가 될 것은 자명하지요. 그러나 실제 업무에 집중하다 보면 자칫 이러한 이슈에 대해서 멀어지게 되고는 합니다. 숲을 보지 못하고 나무만 보는 꼴이랄까요. 모바일 스터디 그룹은 바로 이러한 점을 해결해보기 위해서 개설됐습니다. 적어도 1주일에 한 번씩은 업무에서 잠시 떨어져 다양한 개발 주제로 생각을 정리해보자는 게 이 스터디의 목적이며, 다재다능한 그룹원들의 참여 아래 훌륭하게 진행되고 있습니다. 어떻게 진행되고 있는가? 우선, 매주 월요일 점심마다 스터디가 진행되고 있습니다. (스터디를 할 경우 회사에서 점심을 제공하고 있어 회사의 모든 스터디 모임이 더욱 활성화되는 것 같습니다.) 스터디 주제는 1주일 전에 그룹원들과 이야기를 통해서 정하고 있고, 주제가 정해지면 자발적으로 주제에 대해 학습하며 자료를 공유합니다. 스터디 당일에는 일정 시간을 개별 학습하는 용도로 사용하고, 그 후에 각자 공부한 내용을 바탕으로 자기 생각을 이야기합니다. 기본적으로 상황에 맞게 자유롭게 진행되기 때문에 꼭 위와 같은 방식을 고수하지는 않습니다. 때로는 특정 주제에 대해서 스터디원이 세미나를 희망하기도 하는데, 이 경우 발표자가 자료를 만들어서 세미나를 진행하기도 합니다. 한 번 했던 주제에 대해서 다수가 흥미를 가질 경우 다음 주에 조금 더 깊이 있는 이야기를 나누거나 실제 실습을 해보는 시간을 갖기도 합니다. 아직 시도하지는 않았지만, 주요 컨퍼런스 영상을 보는 시간으로도 활용할 생각입니다. 어떤 주제를 진행했는가? 모든 주제를 나열할 수는 없지만, 대표적인 사례에 대해서 전달하겠습니다.  RxJava : Reactive 진영의 자바(Java) 라이브러리. 그 내부 원리와 구조 학습 Unit Test : JUnit 4, Mockito, Robolectric의 활용과 실전 예제 학습 Kotlin(코틀린) : 안드로이드(Android)에서의 Kotlin 트렌드 확인. Kotlin의 장단점 분석 MVP / MVVM : 안드로이드(Android) 아키텍쳐로 바라보는 MVP / MVVM의 내용 및 차이 학습  이 외에도 여러 주제에 대해서 지속해서 스터디를 진행했지만, 위 내용은 스터디원이 전체적으로 공감하고 도입 의지를 이끌었다는 점에서 인상적이었던 것 같습니다. 특히 코틀린과 같은 경우는 실험적으로 프로젝트에서 도입을 진행하고 있고, 코드 간결화, Null-Safety 측면에서 큰 장점을 느끼고 있습니다. 이처럼 저희 스터디는 학습하게 된 내용을 단순히 지식으로 놔두지 않고 실제 프로덕션에 도입까지 충분히 진행 할 수 있으며, 반대로 실제 프로덕션에 더 좋은 기술을 도입하기 위해서 다양한 주제를 찾아가고 있습니다.버즈빌의 스터디는 무엇이 다른가? 개인적으로 꽤 많은 스터디에 참여해 봤다고 생각합니다. 다양한 주제는 물론 강의형, 토론형 등 여러 방식으로 진행해본 경험이 있습니다. 그중에는 1년 넘게 유지되면서 다양한 지식을 습득한 모임도 있었고, 몇 번 해보지도 못하고 와해한 안타까운 케이스도 있었습니다. 덕분에 좋은 스터디란 무엇인가에 대해 꽤 고민을 해봤고 어떤 부분이 중요한지 나름대로 생각하고 있는 부분이 있습니다. 그리고 그러한 측면에서 버즈빌의 스터디는 좋은 스터디라고 분명히 말씀드릴 수 있습니다. 그렇다면 구체적으로 어떤 점이 버즈빌의 스터디를 좋게 만드는 것일까요? 그 이유는 다음과 같습니다. 첫째, 버즈빌의 수평적인 문화 버즈빌의 사내 문화는 수평적이고 자율적인 문화로 유명합니다. 소위 고루한 잔소리꾼 문화가 없기 때문에 자신의 의견을 누구나 자유롭게 이야기합니다. 사내문화가 스터디와 무슨 상관이 있냐 하실 수 있지만, 수직적인 조직의 사내 스터디와 비교했을 때 큰 차이를 볼 수 있었습니다. 버즈빌의 스터디에서는 여러 사람이 어떠한 권위에 눈치 보지 않고 자유롭게 자신의 의견을 제시하며, 듣는 이 또한 어느 의견이든 함부로 가늠하지 않고 진지하게 받아들입니다. 이는 단순히 스터디 토론에서만 적용 되는 것이 아니라, 스터디 시스템에 대해서도 불합리하거나 개선하고 싶은 점을 여과 없이 이야기합니다. 그리고 그들의 의견을 피드백하여 시스템이 지속적으로 개선되고 있습니다. 결국은 버즈빌의 수평적인 문화가 스터디 문화 자체도 현실적이고 합리적으로 바꿔나간다고 할 수 있습니다. 둘째, 뛰어난 구성원 스터디에서 구성원은 분명 굉장히 중요한 요소입니다. 구성원의 역량과 열정에 따라서 스터디의 질과 지속력이 결정됩니다. 그런 측면에서 버즈빌은 상당히 축복받은 조직임에 틀림없습니다. 당장 제 옆만 둘러봐도 어디서 이런 분들이 나왔을까 싶을 정도로 뛰어난 역량의 소유자가 많으니까요. 아마 인사팀에서 일을 잘하고 있나 봅니다. 여하튼, 버즈빌에는 다재다능한 인재가 정말 많습니다. 각종 분야에 있어서 상당한 지식을 보유하신 분도 굉장히 많으시고, 무엇보다 개발을 좋아하고 새로운 기술을 배우는 것에 긍정적입니다. 열정이 넘친 나머지 스스로 일정을 잡아서 기술 세미나를 진행하기도 하지요. 이런 분들과 함께 하는 스터디, 안 좋을 수가 없습니다. 셋째, No 강제, No 의무 제가 생각하는 좋은 스터디의 중요한 요소는 지속력입니다. 아무리 좋은 스터디라도 무리한 일정과 과제의 압박이 있다면 지속되기 힘들다고 생각합니다. 단발성으로 집중하여 어떤 지식을 습득하려는 게 아닌 이상은, 결국 얼마나 꾸준히 스터디원이 참여하고 공부를 할 수 있는지가 중요합니다. 그러한 측면에서 볼 때 참가를 강제하고, 어떠한 의무성인 과제를 부여하는 것은 지양해야 합니다. 공부는 스스로의 의지에 의해서 수행되어야 하며, 스터디 시스템에서 이를 강제 해봤자 결국은 보여주기 식의 활동밖에 되지 않습니다. 사람이 어떻게 모든 주제에 항상 열정적으로 공부를 하겠습니까. 그렇기에 스터디라는 시스템보다는 사람이 우선이어야 하며, 공부는 본인의 자유입니다. 위와 같은 요소로 인해 전 결론을 내봅니다. 버즈빌에서 굉장히 좋은 스터디를 하게 되었다고. 결론 버즈빌에서 스터디는 CEO 분들을 비롯하여 많은 구성원이 장려하고 권장하는 부분입니다. 그들은 직원의 역량 강화가 곧 회사 역량의 강화라는 인식을 바로 갖고 있으며, 이를 위해 정책적으로 지원하는 방안을 마련해주고 있습니다. 스터디 제도뿐만 아니라 각 개인이 성장할 수 있도록 동아리 지원, 자기개발비 지원 등은 물론 읽고 싶은 책은 무제한으로 제공 해주고 있습니다. 어쩌면 이러한 사소한 점 하나하나가 버즈빌의 소중한 자산이 아닐까 생각하며, 이만 글을 마무리 짓습니다. 감사합니다.작가소개 Ethan Yoo, Software Engineer (Android) 안녕하세요. 버즈빌에서 안드로이드 부분 개발을 담당하고 있는 Ethan (이든)입니다. 개발이라는 주제로 다양한 곳에 관심사를 갖고 있고, 동료와 함께 개발 이야기를 하는 것을 좋아합니다. 메인 언어는 자바(Java)를 사용하고 있지만, 코틀린(Kotlin) / 파이썬(Python) / 자바스크립트(JavaScript) / 하스켈(Haskell) 등 다양한 언어에 대해 경험이 있습니다. 최근에는 시스템 아키텍쳐에 관심을 갖고 반응형 프로그래밍, 함수형 프로그래밍 등이 안드로이드와 어떤 구조로 표현 될 수 있을지 고민하곤 합니다. 제가 만든 서비스가 세상을 바꿀 수 있기를 희망하고, 이를 위해 버즈빌에서 오늘도 열심히 개발을 하고 있습니다.
조회수 3068

채널 iOS에 Redux를 적용하게 된 7가지 이유.

친숙한 MVC 패턴개발자라면 누구에게나 친숙한 MVC (모델 - 뷰 - 컨트롤러) 패턴은 꽤 오랜 시간 동안 사용됐고 아직까지 많은 개발자들에게 사랑받고 있는 패턴이다. 그 이유로는 이 패턴이 일단 진입장벽이 낮기도 하지만 코드 재사용성, 동시 개발의 용이성 때문이다. 만약 당신이 초보 iOS 개발자라면 높은 확률로 MVC 패턴을 쓰게될 것인데 그 이유는대부분의 예제 및 튜토리얼이 MVC 패턴을 쓰고 있고iOS의 IDE인 Xcode에서 (Swift 는 예외지만) 클래스를 생성할때 기본으로 이름에 ViewController라고 들어간다.위와 같은 이유로 많은 iOS 개발자에 영향을 주리라 생각된다. (2011년도부터 iOS 세계에 빠진 저자도 사실 iOS에서는 software architectural design pattern으로는 MVC가 넘사벽이라고 생가하고 있었기에) 문제는 상대적으로 복잡도가 높아지거나 코드의 양이 많은 제품의 개발에서는 생산성이나 가독성에 그다지 도움을 주지 못하는 데 있다고 생각한다. 예를 들어, 한 페이지의 복잡도가 높아지면 ViewController 파일 한 개의 코드 라인이 기하급수적으로 증가한다. 또 (코드 관리에 매우 신경을 쓰지 않는 이상) 객체 간의 통신 및 데이터의 통일성이 없어져서 가독성이 떨어지기 쉽고, 기능을 추가할 때 생산성이 점점 떨어지게 된다.왜 MVC 패턴은 이렇게 문제가 생기는걸까라는 질문에서부터 시작해보자.MVC 패턴, 도대체 뭐가 문제인가?!그림 1. 보편적인 MVC 패턴의 구조보편적으로, MVC 패턴의 구조는 위의 그림과 같다. 그림을 간단히 설명하자면:뷰에서 이벤트가 발생하면 컨트롤러에 알린다컨트롤러는 그것을 처리하고 모델에 업데이트를 하라고 전달한다.모델은 업데이트를 하고 컨트롤러에 다시 알린다컨트롤러는 모델이 업데이트되었다는 것을 뷰에 알린다뷰는 모델의 업데이트된 값에 따라 다시 뷰를 그린다그림 1과 위의 설명만 놓고 보면 각각의 역할이 명확하다고 생각한다. 구조가 복잡하지 않기 때문에 초보자들도 쉽게 이해하고 적용 가능하다는 것이 장점이다. 하지만 MVC 패턴은 객체 간에 어떤 방향으로 커뮤니케이션 해야 하는지에 대해서는 강제하지 않기 때문에 파생된 패턴들이 많이 있다. 실제로 구글에서 “MVC pattern”이라고 검색을 하면 위 그림과 다른 MVC 패턴 이미지들을 볼 수 있다. 그 한 가지 예가 밑에 그림 2이다.그림 2. 또 다른 MVC 패턴의 구조그림 2를 보면 그림 1과는 다른 커뮤니케이션 방향을 나타내고 있다. 바꿔 말하면 개발자가 원하면 언제든지 세 가지 구조 안에서 방향을 유동적으로 바꿔 써도 무방하다는 것이 된다 (그것이 원하는 MVC 패턴이든 아니든지 간에). MVC의 변형으로써는 여러 가지가 있지만, 대표적인 것들은 아래의 그림과 같이 MVP, MVVM 같은 것들이 있다.그림 3. MVC, MVP, MVVM 패턴의 비교실제 저자도 MVC 패턴이 커뮤니케이션 방향을 강제하지 않는 것과 관련해 문제를 겪은 경험이 여러 번 있었던 것을 기억한다. 한가지 예를 들어보자.ViewA.swift (뷰)protocol ViewADelegate {       func updateA() }   class ViewA : UIView {        var delegate: ViewADelegate?       //update through protocol      func didClickOnA() {          self.delegate?.updateA()     }      //update through notification     //maybe same kind of update can happen in other views      func didClickOnAA() {         NotificationCenter.default.post(             name: NSNotification.Name(rawValue: “updateFromA”),              object: nil         )     }      func render(_ model: product) {         //update based on model      }  } ViewController.swift (컨트롤러)class ViewController : UIViewController, ViewADelegate {       Var viewA: ViewA?     Var product = Product()     func viewDidLoad() {         self.viewA = ViewA()         self.viewA.delegate = self         // ...         self.view.addSubview(self.viewA)     }      func updateA() {         self.product.update(name: “aa”, version: “123”)         self.viewA.update(self.product)         //re-render viewA     }  } Product.swift (모델)class Product {       var name = “”     var version = “”     init() {         NotificationCenter.default.addObserver(             self,             selector: #selector(self.doSomething),             name: “updateFromA”, object: nil)     }      deinit {         NotificationCenter.default.removeObserver(self)     }      func update(name: String, version: String) {         self.name = name         self.version = version     }      func doSomething() {          //do something…          //notify viewA or any objects through notification     }  } 조금 극단적인 예처럼 보이긴 하지만 실제 개발을 하다 보면 충분히 일어날 수 있는 상황이다. 코드에 대해 간략하게 설명하자면:ViewA에서는 delegate와 notification으로 각각 ViewController와 Product에 이벤트를 날리고 있고ViewController에서는 delegate method를 구현해서 Product를 업데이트 후, 다시 ViewA를 그리라는 로직을 가지고 있다.Product 에서는 객체를 업데이트 할 수 있는 메소드가 있고 notification을 통한 업데이트를 하고 있다.이건 아주 간단한 예이지만 프로젝트가 커진다면 특정 이벤트에 대해 데이터가 업데이트되는 경로가 달라질 수 있다. ViewA -> Product -> SubProduct -> Product -> ViewA 의 경로라던가, ViewA -> Controller -> Product -> SubProduct -> Controller -> ViewA 의 경로 등이 가능하다. 이처럼 특정 이벤트에 대해 여러 가지 체인형식으로 업데이트가 이루어질 경우 그 경로를 일일이 추적하는데 시간이 걸릴 수밖에 없는 구조를 가지고 있는 것을 볼 수 있다.(프로젝트의 크기가 어느정도 커지게 된다면 이렇게 될지도 ㅎㅎ)이런 케이스가 발생하는 근본적인 이유는 결국 MVC 패턴의 장점이라고도 말할 수 있는 유연성과 양방향 커뮤니케이션 때문이다. 이 패턴 자체가 문제가 있는 것은 아니지만 결국 코드는 사람이 작성하는 것이기에 생산성과 가독성을 떨어뜨리는 결과를 초래할 가능성이 높다. 여기에서 우리는 기존 웹 개발에서 쓰이고 있던 Redux 도입을 생각하게 된 것이다.Redux는 무엇인가?Redux 로고Redux는 Facebook의 Flux 를 모태로 삼고 있고 예측 가능한 상태를 자바스크립트 프로그램에서 구현하기 위한 애플리케이션 아키텍쳐이다. Redux는 본래 자바스크립트에서 시작한 오픈소스 프로젝트이지만 다른 개발자들에게 영감을 주었고 2015년 말쯤 iOS 플랫폼에서는 ReSwift(Redux + Swift)가 생겨났다. ReSwift는 결국 Redux랑 크게 다르지 않고 Redux의 세 가지 법칙을 따른다.Single source of truth — 애플리케이션의 전체 상태(State, 또는 데이터)는 트리 형태의 하나의 저장소(Store)로 저장된다.Changes with pure functions — 상태 트리를 변경하는 리듀서(Reducer)는 순수 함수(pure function)이어야한다.Read-only states — 상태는 오직 액션(Action, 어떤 일이 일어날 것인지 설명할 수 있는 객체)으로만 변화가 가능하다.쉽게 말하자면 “Redux는 한 개의 상태 저장소를 가지고 있고 그 안에 있는 데이터만이 신뢰할 수 있으며 저장소의 상태는 오직 순수 함수인 리듀서를 통해서만 변화가 가능하다” 라고 축약 할 수 있다.그림 4 Redux 패턴의 구조위의 그림 4을 보면 충분히 프로그램의 흐름이 어떤 식으로 흐르는지 감이 왔으리라 생각한다.이벤트가 뷰에서 생성되면 그에 해당이 되는 액션을 통해 알린다.액션은 특정 리듀서에서 처리한다.리듀서는 액션에 따라 저장소를 업데이트한다.저장소에 변화가 오면 구독(Subscribe)을 하고 있는 모든 객체에 알린다.이것이 Redux의 커뮤니케이션 사이클이다. Redux만으로도 충분히 여러가지 블로그 주제가 나올 정도로 할 이야기가 많지만 여기까지만 하고, 좀 더 자세한 디테일을 알기 원한다면 옆의 링크를 클릭하시면 된다. :) -> 리덕스 공식 링크Redux vs. MVCMVC와 Redux에 대해 소개를 했으니 간단히 비교해 보자.The Flow — Redux는 데이터 및 애플리케이션의 흐름을 강제한다. 저장소의 변화는 오직 액션을 통해서만 가능하기 때문이다. 이와 다르게 MVC는 강제성이 없기 때문에 여러가지 파생 패턴이 생길 수 있다.Unidirectional flow — Redux에서 흐름은 액션으로만 변화가 일어나기 때문에 오직 한쪽으로만 흐른다. MVC에서는 양방향이 될 수도 있고 한 방향이 될 수도 있지만 보통 양방향이다.Stores — Redux에서는 상태 및 데이터가 하나의 저장소에 있기 때문에 관리하기가 쉬운 반면, MVC에서는 여러 군데에 상태가 분리되어 있기 때문에 동기화에 신경을 써야 한다. (로컬 데이터 스토리지를 쓴다면 문제가 해결되기는 하지만 패턴 이외에 추가적인 노력이 필요함)그 이외에 여러가지 다른 점이 있겠지만, 위의 3가지가 가장 다른 점이라고 저자는 생각한다.채널 데스크 iOS에 Redux를 적용하게 된 이유이제 MVC와 Redux의 차이점을 알게 되셨으리라 생각한다. 우리 팀이 채널 데스크 iOS에 Redux를 적용한 이유를 소개하려고 한다. 아직 모든 부분에 완벽히 적용한 상태는 아니지만 (부분적으로 Notification, Delegate 그리고 Reactive를 쓰고 있다) 그럼에도 Redux를 적용함으로써 얻는 이점이 많다고 느끼고 있다.Explicit data flow — 새로운 개발자가 왔을 때나 여러 명이 작업을 할때 애플리케이션의 전체 흐름을 파악하고 이해하기 쉽다.Unidirectional flow — 데이터 관련 부분을 전부 Redux로 대체하니 모든 데이터 흐름이 한 방향으로 강제되었다. 덕분에 데이터가 어디에서 왔고 어디로 가는지를 파악하기 매우 쉽다.Single storage — 한 곳에서만 데이터를 관리하기 때문에 데이터에 관한 부분은 리듀서만 잘 짜 놓으면 관리하기 쉬워진 점이 있다. Redux를 적용하기 전에 CoreData를 데이터 저장소로 쓰고 있었는데, 어느 시점에 어떻게 저장되는지 눈에 들어오지 않아 불편한 점을 Redux를 사용함으로써 해결할 수 있었다.Immutability and data consistency — 변경 가능한(Mutable) 객체는 보통 iOS 개발에서나 다른 플랫폼 개발에서 장점일수도 있다. 하지만 데이터의 일관성이 깨지기 쉽다. 만약 A에서의 데이터와 B에서의 데이터가 다르면 어떤 것을 신뢰해야 하는지의 문제도 생길 수 있다. 우리는 Redux의 저장소에 있는 데이터를 모두 변경 불가능한 객체(Immutable, Swift에서는 Struct을 쓴다)로 구현하여 이 문제를 해결하였다. 이 부분은 코딩할 때 불편한 점이 조금 있지만, 그 불편함을 감수할만한 가치가 있다고 생각한다.Predictability — 저장소는 오직 액션을 통해서만 변경할 수 있다는 점이 무엇보다 장점인 것 같다. MVC와 같이 데이터를 어디서든 변경할 수 있다면 데이터와 관련된 버그를 찾는 데 소비하는 시간이 길어지곤 한다. Redux는 어떤 액션이 어디에서 불리는지 아는 것만으로도 그 시간을 비약적으로 단축할 수 있다.Maintainability — 저장소, 상태, 액션 그리고 리듀서로 역할과 레이어를 분리하게 되니 보통 코드 라인이 100줄을 넘지 않는다. 그만큼 유지보수 비용이 적어졌다.Organized Code — MVC 패턴에서는 비지니스 로직이 뷰에 들어가는 경우가 있기도 했었는데 Redux의 가이드라인을 따름으로써 자연스럽게 대부분의 뷰는 그저 데이터를 받고 시각화하는 dummy 뷰의 형태가 되었다. 비즈니스 로직이 완전히 뷰와 분리됨으로써 뷰의 복잡도와 코드를 관리하기가 쉬웠다.ReSwift 도입 시 주의할 점ReSwift 도입을 고려하는 분들을 위해 몇 가지 주의할 점을 소개하겠다.Performance — ReSwift에서는 저장소가 변경될 때마다 newState: 메소드가 호출이 되어 화면을 업데이트할 수 있게 되어있다. 채널 데스크 같은 경우는 실시간 애플리케이션(Real-time application)이라서 API 이벤트와 Socket 이벤트가 자주 발생해서 저장소가 변경되는데, 도입 초기 단계에 이 부분을 간과해서 화면이 거의 멈출 정도로 퍼포먼스가 나오지 않았었다. 만약 ReSwift를 적용했는데 퍼포먼스가 나오지 않는다면 newState: 함수 부분을 최적화하거나 미들웨어(middleware)를 만들어서 batch 형식으로 액션을 처리하는 방식을 고려해봐야 한다.Not thread safe — ReSwift는 thread-safe 하지 않아서 초반에 알 수 없는 crash들이 자주 발생했었다. 저자 같은 경우는 ActionWrapper를 만들어서 액션은 항상 메인스레드에서 처리되도록 강제했다.글을 마무리하며..Redux는 이미 자바스크립트 개발에서는 React와 함께 많이 쓰이고 있지만 iOS에서는 아직도 생소한 아키텍쳐이다. ReSwift는 아직 2년도 되지 않은 프로젝트이고 자바스크립트에서 처럼 유용한 Redux 미들웨어도 많지 않다. 또한 인지도도 MVC, MVVM, MVP에 아직 미비한 편이다. 프로덕션에 참고할 만한 예제도 찾기 어려웠기에 초기 러닝 커브는 조금 있었던 것으로 회상한다. 그럼에도 불구하고 우리 팀은 ReSwift를 적용해 보다 깨끗하고 유지보수하기 쉬운 프로그램을 만들 수 있었고 만족하며 사용하고 있다. 기존 MVC의 불편함을 아시는 분들은 충분히 도입할 가치가 있다고 생각한다.#조이코퍼레이션 #개발자 #개발팀 #인사이트 #경험공유 #일지 #Redux
조회수 1230

스푼 라디오 오디오 랩 팀의 Jason을 만나보세요!

인상이 좋은 비결은.. 원래 이렇게 생겼어요 (찡긋)오디오 랩 팀의 막내, 알고 보니 세상 모든 매력을 덕지덕지 붙이고 다니는 Jason을 인터뷰해보았습니다.근데 대체 왜 이렇게 인상이 좋은 거예요? 출처: 알파카 월드 - 제이슨 닮은꼴"그냥 정말 원래 이렇게 생겼어요 하하. 웃는 상이예요. 사실 어릴 땐 눈이 좀 더 찢어지고(?) 올라가 있어서 좋은 인상이 아니었는데, 좋은 인상으로 변하더라고요..(나이 탓인가..) 웃는 게 습관이 되어버렸어요"인싸도 아싸도 아닌 '그럴싸'"인싸요? 아니에요 인싸. 그냥 저는 좀 알고 보면 반전도 많고 '모순덩어리' 일뿐이에요. 그래서 저를 표현하는 한 마디도 저는 '모순덩어리'라고 할래요. 예를 들면, 저는 해병대 출신인데 수영을 못하고요. 이성적인 것 같은데 또 되게 감성적이에요. 발라드를 되게 좋아하는데 제 노래방 18번은 '거꾸로 강을 거슬러 오르는 저 힘찬 연어들처럼'이에요. 사색하는 거 좋아하는데 또 가만히 있는 건 싫어요. 시간 아깝더라고요. (빵긋) 사내 제이슨 feat. 카이와 헤이든 듣고 싶은 당신의 스푼 라이프오디오 랩팀은 어떤 부서인가요?"오디오 랩팀은 스푼 라디오에서 오디오 방송 통신 기술을 연구하고 개발하는 부서입니다. 저희의 궁극적 목표는 세계 최고 오디오 기술 플랫폼이 되는 것이에요. 그리고 오디오 랩에서 제가 하고 있는 업무는 안드로이드 OS 클라이언트에 오디오 기술 개발하는 업무를 맡고 있어요. 오디오 랩팀에 막내이긴 한데.. 재간둥이 역할은 제가 맡고 있지 않아요 하하.. 저희 팀의 재간둥이 역할은 Ben님께서 하고 계십니다"스푼에 입사하기까지"제 입으로 말해도 되나요? 저는 수학을 좋아하진 않았는데, 잘했어요. 국어랑 사회 같은 문과계열 과목을 싫어했는데 이공계 쪽이 저와 적성에 맞더라고요. 수학 1등급 나왔는데 메가스터디 박 XX 선생님께 이 자리를 빌려 감사드립니다. 인강이 저를 만들어주셨어요.저의 원래 장래희망은 항공기 정비사였어요. 언제부터 비행기를 좋아했는지 모르겠지만 초등학교 때부터였던 것 같아요. 고3 때 진로를 정해야 하는데 항공정비과와 전자공학과와 고민을 했었어요. 그러다가 결국엔 전자 공학과 에 진학하게 되었고 자연스럽게 꿈 하고 멀어지게 되더라고요. 사실 항공 소프트웨어 쪽으로 일을 하게 될 줄 알았는데 다른 쪽으로 방향이 틀어지다 보니 어느덧 30대가 되어 있었어요. 사실 처음에 저는 스타트업에서 일하게 될 줄 몰랐어요. 이직을 준비하던 차에 제가 직접 스푼 라디오를 사용해보고, 기사도 읽게 되었고 Neil(대표)의 세바시 강연을 보고 이곳에서 일하고 싶다! 비전이 있다!라고 생각해서 오게 되었어요"내가 함께 일하고 싶은 사람서글서글한 사람을 좋아해요. 제가 그렇게 잘 못하는 편이라서요. 낯을 좀 많이 가리는데 저와는 다른 성향인 사람이라면 시너지 효과가 날 것 같아요파일럿 제이슨알고 싶은 Jason의 이야기해병대 출신부터 비행기 조종사까지"제가 안 그래 보이지만.. 사실 해병대 출신이에요. 해병대 왜 갔냐고 물어보신다면, 멋있어 보여서 가게 되었어요. 그게 전부예요. 복식 호흡하는 게 멋있어 보이더라고요. 원래 하고 싶은걸 다 하면서 살자라는 위주인지라, 꼭 무엇이든 하고 말거든요. 원래 꿈이 비행기 조종사였는데 꿈을 못 이루었으니 취미로도 해보자!라는 생각이 들어서 시작하게 되었어요. 한국에서도 할 수 있는데 제약이 너무 많아서 회사를 그만두고 미국에 갔어요. 여태 모아둔 돈 다 쓰고 왔어요. 4개월 정도 미국에서 하루 10시간씩 비행을 했었는데, 정말 행복했어요. 고등학교 때는 사실 실용음악도 준비했었어요. 아카펠라 중창단에 속해있었는데 2학년이 되고 이걸 진로로 결정하기엔 아니라고 판단이 들어서 그만두긴 했지만요. 그래서 대학교에 들어가고 밴드부에 들어가서 보컬을 맡았었어요. 저 점심시간에 혼자 코노가요. 같이 가기엔 부끄러워서.. 혼자 갑니다"유노윤호의 열정, 최강창민의 쿨함"제가 원래 자소서에 경청을 잘하는 사람이라고 적었는데 사실 가끔 듣는 것도 귀찮아요 하하.. 그리고 본인 이야기하는 것도 민폐라고 생각해서 잘하지 않는데 인터뷰하다 보니 엄청 많이 하게 되었네요. 근데 또 제가 남한테 지는 거 안 좋아해서 벤이랑 운동 누가 더 많이 하나 내기해서 요즘 매일 아침 출근 전에 수영 배우고 있고 화, 목은 영어학원을 다니면서 자기 계발을 하고 있어요. 목표가 없으면 안 되는 것 같아서 늘 목표를 일부러 세워요. 그래서 예전엔 사진도 배우러 다녔어요. 아 참! 수영을 배우다 보니 요즘 새로운 목표는 '라이프 가드'를 하고 싶어 졌어요. 이렇게 하고 싶은걸 하면서 열정적이게 살게 된 계기는 아마 아버지의 영향이 큰 것 같아요. 아버지가 매일 이렇게 말씀해주셨거든요"꿈을 꾸고 살아라, 돈은 따라온다! 반려견 '나무'의 아빠 Jason"저희 집 강아지 이름이 '나무'인데요. 식목일이 생일이라서 나무라고 지었어요. (나무 이야기할 때 눈빛이 초롱초롱해지면서 나무의 사진 보여주시던 제이슨) 나무는 귀엽고요. 비가 오나 눈이 오나 항상 저를 반겨줘요. 그래서 고마운 친구예요. 회사랑 집이 거리가 좀 멀어서 자취를 할까 생각했는데, 그러면 강아지가 혼자 집에 있어야 하니 안쓰러워서 하고 싶지 않았어요. 제가 없더라도 다른 가족들이 나무를 보살펴 줄 수 있어서 다행이라고 생각해요.팀원들이 Jason을 한마디로 표현한다면?Ian: JSON - "가볍고 빠르고 효과적이어서"*JSON [JavaScript Object Notation] :경량의 DATA교환 형식Ben: 알파카계의 알파치노 - "알파카처럼 온순한 외모의 소유자이지만 속엔 야망과 강한 카리스마를 가진 남자라서"
조회수 1886

Mac을 처음 쓰는 개발자에게

Overview애플(Apple) 제품을 한 번도 써본 적이 없습니다. 3주 전, 입사하고 받은 맥북(MacBook Pro)이 첫 애플 제품이었죠. 사실 개발 업무를 하면서 ‘한 번쯤은 애플 제품을 써 봐야겠다’는 생각을 하고 있었습니다. 단지 쉽사리 용기가 나지 않았을 뿐이었죠. 하지만 여러 개발 환경이 존재하는데도 개발자가 한 가지 환경만 고집하는 건 스스로의 잠재 능력을 좁히는 거라 생각했습니다. 그래서 이번 기회에 새로운 환경과 친해지려고 APM 웹서버 구성에 도전해봤습니다. (아자!) OS 설치 완료 후 환경Sierra 10.13apache 2.4php 5.6mysql 5.6 APM 설치 과정MAC 환경에서 APM 설치하려면 MAMP 방법도 있지만 기본적으로 apache, php가 설치되어 있으므로 패키지관리자 Homebrew를 이용하여 설치하겠습니다. 1.apache 설치 버전 확인$ httpd -v 명령어를 실행해서 아래와 같이 버전이 나오면 설치가 되어있는 상태입니다. $ httpd -v Server version: Apache/2.4.27 (Unix) Server built: Jul 15 2017 15:41:46 2.php 설치 버전 확인php -v 명령어를 실행해 아래와 같은 버전이 나오면 설치가 된 것입니다.$ php -v PHP 5.6.32 (cli) (built: Oct 27 2017 11:55:27)  Copyright (c) 1997-2016 The PHP Group  Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies 참고: MAC Sierra 10.13 버전에는 php7 상위 버전으로 설치되어 있습니다. Homebrew로 php5.6 하위 버전을 추가적으로 설치해야 합니다.3.Homebrew 설치Homebrew 명령어1)패키지 검색하기 -> $ brew search 패키지명 2)패키지 설치하기 -> $ brew install 패키지명 3)패키지 삭제하기 -> $ brew uninstall 패키지명 4)설치된 패키지 목록확인 -> $ brew list 5)패키지 정보보기 -> $ brew info 패키지명 6)패키지 업그레이드 하기 -> $ brew upgrade 패키지명 7)패키지 저장소 추가하기 -> $ brew tap homebrew/패키지명 8)패키지 저장소 삭제하기 -> $ brew untap homebrew/패키지명 9)패키지 링크 삭제하기 -> $ brew unlink 패키지명 가.설치파일 다운$ /usr/bin/ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)” 나. Homebrew wget 설치 (Apple에서 제공하지 않는 패키지를 설치하기 위한 것이다.) $ brew install wget다. 심볼릭 링크 연결 $ ls -l /usr/local/bin/wget ../Cellar/wget/1.19.2_1/bin/wget bin/wget -> ../Cellar/wget/1.19.2_1/bin/wget 라. 패키지 저장소 추가 $ brew tap homebrew/dupes $ brew tap homebrew/php $ brew update 4.php56 설치가. Homebrew php56 설치 $ brew install php56 –with-apache 나. Apache에 PHP 설정 수정하기 아파치에 php7 모듈이 연결되어 있어 주석 처리 후 설치한 php5 경로로 연결한다. $ vi /etc/apache2/httpd.conf LoadModule php5_module /usr/local/php5-5.6.31-20170817-164511/libphp5.so #LoadModule php7_module libexec/apache2/libphp7.so 다. apache 재시작 apachectl restart라. phpinfo 확인 phpinfo 확인5.mysql56 설치가. Homebrew mysql56 설치$ brew install mysql56나. mysql 시작$ /usr/local/Cellar/[email protected]/5.6.38/bin/mysql.server start다. mysql 버전확인$ /usr/local/Cellar/[email protected]/5.6.38/bin/mysql –version명령어를 실행해서 아래와 같이 버전이 나오면 설치가 되어있는 상태입니다.$ sudo /usr/local/Cellar/mysql\@5.6/5.6.38/bin/mysql --version  /usr/local/Cellar/[email protected]/5.6.38/bin/mysql  Ver 14.14 Distrib 5.6.38, for osx10.13 (x86_64) using  EditLine wrapper 6.가상호스트 설정로컬에 다수의 프로젝트를 세팅하기 위한 것이다. 가. httpd.conf 파일 수정Include /private/etc/apache2/extra/httpd-vhosts.conf <- 주석제거 $ vi /etc/apache2/httpd.conf  # Virtual hosts Include /private/etc/apache2/extra/httpd-vhosts.conf 나. httpd-vhosts.conf 파일 수정NameVirtualHost : 아파치 2.4 이전 버전일 경우 80 포트에서 이름 기반 가상 호스트를 사용하겠다는 의미로 반드시 적어줘야 한다.DocumentRoot : 해당 프로젝트 소스 경로ServerName : 해당 프로젝트 접속 도메인주소 $ vi /etc/apache2/extra/httpd-vhosts.conf NameVirtualHost *:80       DocumentRoot "/Users/comkjs/Sites/ex1"     ServerName ex1.brandi.co.kr     ErrorLog "/private/var/log/apache2/error_log"     CustomLog "/private/var/log/apache2/access_log" common               Options FollowSymLinks         AllowOverride All         Order allow,deny         Allow from all         Require all granted         DocumentRoot "/Users/comkjs/Sites/ex2"     ServerName ex2.brandi.co.kr     ErrorLog "/private/var/log/apache2/error_log"     CustomLog "/private/var/log/apache2/access_log" common               Options FollowSymLinks         AllowOverride All         Order allow,deny         Allow from all         Require all granted     7. hosts 설정해당 도메인으로 접속시 DNS 서버를 사용하기 이전 로컬에 지정된 IP로 맵핑된다.$ vi /etc/hosts ## # Host Database # # localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 localhost 255.255.255.255 broadcasthost  ::1             localhost   127.0.0.1 ex1.brandi.co.kr 127.0.0.1 ex2.brandi.co.kr Conclusion물론 오랫동안 맥북을 사용했던 개발자에겐 쉬운 내용일 수 있지만 MS와 리눅스에 익숙했던 저에겐 ‘두려움’이었습니다. 리눅스 구조와 명령어가 비슷해서 리눅스를 이용했던 이용자에겐 어렵지 않을 것입니다. 한 번 세팅해두면 환경이 바뀌지 않는 이상 잘 건드리지 않기 때문에 나중에 세팅을 바꾸는 일이 있으면 또 다시 볼 수 있도록 기술 블로그에 남겨둡니다. 분명 언젠가는 도움이 되지 않을까요. 글곽정섭 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #기업문화 #조직문화 #업무환경 #인사이트 #경험공유 #Mac #개발자 #신입개발자 #조언
조회수 1819

Swift 4.1에서 딥링크로 앱을 여는 경우 크래시되는 문제 해결하기

최근 Xcode 9.3 버전이 배포되었습니다. 이 버전에는 가장 최신의 Swift 4.1 버전이 포함되어 있습니다. Swift 4.1에는 여러 흥미로운 개선사항들이 많지만, 치명적인 버그도 존재합니다. 바로 딥링크를 통해 앱을 여는 경우 크래시가 발생하는 문제입니다. StyleShare에서는 QA 과정을 통해 문제를 발견할 수 있었습니다.만약 여러분의 애플리케이션이 아래 조건을 모두 충족할 경우 문제가 발생합니다:Swift 4.1 버전을 이용해서 빌드한 경우Deployment Target이 iOS 11.0 미만인 경우AppDelegate에서 application(_:open:sourceApplication:annotation:) 메서드를 구현한 경우문제를 재현하기에 가장 좋은 방법은 Safari 앱을 이용하는 것입니다.1. iOS 기기 또는 사뮬레이터에서 Safari 앱을 구동합니다.2. 주소 입력란에 앱이 지원하는 딥링크 URL을 입력한 뒤 이동합니다. (e.g. myapp://)3. 앱이 구동됨과 동시에 강제 종료됩니다.이 버그는 Swift 이슈 트래커에 SR-7240 티켓으로 이미 등록되어 있습니다. Resolved 상태로 표시되지만 이번 Xcode 9.3 버전에는 포함되지 않은 것으로 보입니다. 다행히 댓글에 한 개발자가 문제를 해결할 수 있는 workaround를 공유해두었는데요. 이 방법을 이용하면 당장의 문제는 해결할 수 있습니다. AppDelegate 메서드의 annotation 파라미터의 타입을 Any에서 Any?로 변경하는 것입니다.- func application(_ application: UIApplication, open url: URL, sourceApplication: String?, annotation: Any) -> Bool + func application(_ application: UIApplication, open url: URL, sourceApplication: String?, annotation: Any?) -> Bool<iframe width="700" height="250" data-src="/media/0ce1fe8c63fca7a6c953233b94406d02?postId=ed495077c36" data-media-id="0ce1fe8c63fca7a6c953233b94406d02" data-thumbnail="https://i.embed.ly/1/image?url=https://avatars2.githubusercontent.com/u/931655?s=400&v=4&key=a19fcc184b9711e1b4764040d3dc5c07" class="progressiveMedia-iframe js-progressiveMedia-iframe" allowfullscreen="" frameborder="0" src="https://medium.com/media/0ce1fe8c63fca7a6c953233b94406d02?postId=ed495077c36" style="display: block; position: absolute; margin: auto; max-width: 100%; box-sizing: border-box; transform: translateZ(0px); top: 0px; left: 0px; width: 700px; height: 100px;">UIApplicationDelegate에 정의된 메서드 시그니쳐와 다르기 때문에 컴파일러가 경고를 표시하지만 무시하셔도 됩니다.만약 새로운 버전의 앱을 릴리즈 할 계획을 가지고 계시다면 이 이슈를 꼭 확인하시길 바랍니다. 이 버그는 페이스북 로그인 등 다른 앱을 이용한 로그인이나, 카드 결제 후 주문서로 돌아오는 흐름에서 큰 문제를 일으킵니다. 이 글이 여러분들께 도움이 되길 바랍니다.Swift Korea 그룹에서 Xcode Release Notes에도 같은 내용이 있다는 것을 제보해주셨습니다. Swift Compiler 섹션의 Known Issues 4번째 항목입니다.#스타일쉐어 #개발팀 #개발자 #개발후기 #경험공유 #인사이트

기업문화 엿볼 때, 더팀스

로그인

/