Realm이 주최한 안드로이드 개발자 오픈토크 행사에서 발표한 동영상입니다. 주제는 [리액트 네이티브로 안드로이드 앱 개발하기의 장단점]입니다. 예전부터 글로 한 번 정리해서 공유하려고 했었는데 발표 기회 덕분에 그럴 필요가 없게 되었네요. 아직 국내에서 리액트 네이티브로 실서비스를 개발하는 경우는 거의 없는 것 같은데 많은 분들이 염두에는 두고 계신지 500회 이상 페이스북에 공유되었습니다. 아래 링크는 Realm 블로그에서 영상과 함께 정리해 주신 내용이고 그 아래는 바로 보실 수 있도록 유튜브 동영상을 첨부했습니다https://realm.io/kr/news/react-native-android-pros-cons/https://www.youtube.com/watch?v=v3_3ZwcHy5Y<iframe width="700.000000" height="393.750000" src="//www.youtube.com/embed/v3_3ZwcHy5Y" frameborder="0" allowfullscreen="">마지막 질문과 답변에 대해 집에 와서 좀 더 고민해 봤습니다. 페이스북 내부적으로 리액트 네이티브를 굉장히 잘 활용하면서 각 플랫폼이 코드를 공유하는 비율이 80%가 되는데, 저희 회사가 그렇게 할 수 있을까, 다른 스타트업들이 그렇게 할 수 있을까, 그렇게 하는 것이 바람직한가를 곰곰이 생각해 봤습니다. 우선 페이스북이 리액트를 사용했을 때의 장점은 '생산성' 보다는 수많은 플랫폼 간의 '일관성'이라는 생각이 들었습니다. 페이스북의 복잡하고 다양한 기능들이 OS별로 브라우저별로 디바이스별로 일관되게 적용되도록 하려면 각 그룹의 개발 인력이 밀접하게 공조를 하거나 더 나아가서는 한 그룹의 개발 인력이 꽤 많은 코어 펑션들을 한 번 만들어 공통적으로 사용하는 것이 유리하다는 것이죠. iOS에서 동작하는 기능이 Android와 PC웹과 모바일 웹에서 동일하게 동작하는 것을 보장하기 위해 크로스 플랫폼은 좋은 전략입니다. 생산 속도 측면의 생산성보다는 중복 제거를 통한 안정성을 획득할 수 있습니다. 중복 제거의 장점은 페이스북처럼 협업하는 개발자가 많아 커뮤니케이션 비용이 높을 때 더욱 빛을 발하죠. 그리고 대규모 유저 베이스에서는 중복 제거가 플랫폼 간의 제품의 일관성과 안정성도 높여줄 수 있습니다.페이스북은 외부 SDK를 사용할 필요가 없어 제가 언급했던 리액트 네이티브의 단점 중 하나가 사라집니다. 페이스북이 트위터나 애드몹, 구글 애널리틱스 등의 외부 SDK를 탑재할 이유가 없으니까요. 그리고 리액트 네이티브를 주도해서 만들어가는 입장이기 때문에 퍼포먼스 이슈들은 우회하거나 크리티컬 한 경우는 장기적으로 고쳐가면서 사용할 수 있습니다.반면 한 명의 개발자 또는 플랫폼 별로 한 두 명의 개발자가 있는 저희 회사나 소규모 기업에서 리액트 네이티브를 검토하고 있는 단계라면, 빠른 개발 또는 한 번 개발해서 여러 플랫폼에 '금방' 론칭할 수 있다는 장점을 염두에 두고 있을 가능성이 큽니다. 아직 론칭 전이고 (유저 베이스가 없어 안정성 이슈가 당장 크지 않고) 개발자 간 커뮤니케이션 비용이나 중복 제거가 덜 중요한 이슈이며(수백 명의 개발자가 있는 것과 상대적으로) SNS 로그인, 광고, 분석 등의 도구를 자체 개발할 여유와 이유가 없는 상황인 것이죠.정리하자면 소규모 기업이 리액트 네이티브를 고려하고 있는 이유와 환경, 그리고페이스북이 내부적으로 리액트 네이티브를 쓰고 있는 이유와 환경이 서로 다름을 염두에 두고 판단하면 좋을 것 같습니다. 이번 발표에서는 크로스 플랫폼으로써 리액트 네이티브에 대해서만 다루었는데요, 5년 전에는 Titanium(http://www.appcelerator.com/)으로 모바일 서비스를 크로스 플랫폼으로 개발했었고, 리액트 네이티브와 유사한 개념의 Fuse(https://www.fusetools.com/)와 네이티브에 가까운 하이브리드를 추구하는 ionic(http://ionicframework.com/) 등도 최근에 살펴보았는데 모두 비슷한 단점이 있다고 볼 수 있습니다.복잡해지면 네이티브와 비교해 느려진다는 것, 약간의 동작 이상(쉽게 고치기 어려운), 그리고 외부 SDK 탑재의 제약 등입니다. 이 것들과 씨름하다 보면 여러 플랫폼에 동시에 출시할 수 있다는 '빠름'의 장점이 많이 사라지게 됩니다. Titanium만 해도 Android와 iOS가 초창기여서 네이티브 개발이 효과적이지 못했을 때 그 대안으로 각광받았었습니다. 많은 개발자가 Titanium이나 Phonegap 등으로 몰렸고 써드파티 SDK들도 Titanium을 꽤 지원했고 플러그인 마켓도 활성화됐었습니다. 도큐먼트도 풍성했죠.현재의 Unity가 누리는 인기와 비슷한 측면이 있었습니다. 게임 솔루션 업체들은 모두 Unity SDK를 지원하고 게임 개발자들은 네이티브 코드를 거의 건드리지 않고 Unity 툴 안에서 개발하며 Unity의 마켓에서 에셋을 거래할 수 있죠. 생태계가 그 정도로 커지고 이 안에서 모든 것이 해결이 가능해진다면 리액트 네이티브가 지금보다 더 강력한 대안이 될 수 있을 것 같습니다. 반면 자바스크립트 개발자들, 특히 React의 단순함과 생산성에 매력을 느껴본 클라이언트 개발자들이라면 리액트 네이티브는 지금으로써도 가장 좋은, 또는 유일한 전략입니다. 네이티브와 비교하면 아쉽지만 하이브리드와 비교하면 월등한 대안이기 때문이죠. react-native의 패키지들을 살펴보면 상당수가 UI 관련 javascript only 라이브러리 들입니다. 상당수가 네이티브와 관계없는 자바스크립트 개발자들의 작품이라고 보입니다. 원론적이지만, 역시 자신의 상황과 목적이 맞게 도입 여부를 판단해야겠다고 결론 내릴 수 있을 것 같습니다. 

안녕하세요. 스타일쉐어 백엔드 개발자 김동현입니다.2018년의 스타일쉐어에서는 뷰티, 중고 그리고 데일리룩이라는 피드가 추가로 등장했는데요, 그중 제가 작업했던 데일리룩 피드를 만들게 된 배경과 개발 방향에 대해 공유드리고자 합니다.스타일쉐어 데일리룩#데일리룩 #ootd / 타자 치는 것은 귀찮아데일리룩에 관련된 스타일들만 뽑아내는 방법 중에 가장 간단한 방법은 텍스트로 분리해내는 방법이었을 것입니다.하지만 #데일리룩 #ootd는 사진이나 내용이 관계가 없더라도 들어가 있는 경우가 많았습니다.또한 위의 피드처럼 정성스러운 글을 써주는 유저도 많긴 했지만 자신의 데일리 로그를 남기면서 글을 작성하지 않는 경우도 더러 있었습니다.즉, 단순히 텍스트로만 구별해내기에는 이미지에 대한 질을 확신할 수 없었고, 텍스트가 주된 서비스가 아니다 보니 설명 없는 좋은 이미지들이 많았는데요.우리는 이 이미지들을 놓치고 싶지 않았습니다.그래서 결과적으로 텍스트 대신 이미지를 사용하는 방향을 선택하게 되었습니다.이미지로 어떻게 구별해낼까?다행히도 R-CNN의 높은 인식률과 Pre-Trained 된 모델의 label 중 person이 이미 학습되어있던 터라 별도의 Transfer Learning 없이 이미지 내에서 body parts가 있는지 없는지 찾아내는 것은 아주 어렵지 않았습니다.다만 문제가 있다면 body parts에 들어가는 모든 부분을 person이라고 예측하던 부분이었죠.예를 들자면 아래와 같습니다.다음과 같이 제가 사용한 모델에서는 body parts를 person이라는 라벨로 처리하고 있었습니다.단순히 R-CNN의 person 라벨만을 믿기에는 의도했던 데일리룩 외에도 너무나도 많은 것들이 데일리룩이라는 이름으로 필터링될 것 같았습니다.그래서 또 다른 필터가 하나 더 필요하다는 생각이 들었습니다.Pose EstimationBody Parts 중 우리가 원하는 부분이 사진에 있으면 좋겠다!라는 생각을 곰곰이 하다 보니 우연히 머릿속에 스쳐 지나가는 하나의 장면이 있었습니다.Source: http://graphics.berkeley.edu/papers/Kirk-SPE-2005-06/바로 3D 모델링 중에서 Motion Tracker 에 관련된 장면이었는데요. 이것을 Tracker가 아니라 이미지에서 stick figure를 뽑아낼 수 있으면 되지 않을까?라는 생각이 들었습니다.놀라운 딥러닝의 세계에는 이미 여러 명의 Stick Figure를 뽑아낼 수 있는 경지에 도달해 있었습니다.Source: https://github.com/ZheC/Realtime_Multi-Person_Pose_EstimationPose Estimation 딥러닝 모델을 사용하여 아래와 같은 결과물을 얻어낼 수 있었는데요.이미지 내의 Body Parts의 존재 여부를 알게 되었으니 우리가 원하는 Body Parts가 이미지 내에 있는지 검사할 수 있게 되었습니다.하지만 해당 모델이 마냥 가볍지는 않았기에 사용자의 업로드가 많은 순간에는 예측 Task가 밀리기 시작했습니다.그래서 아주 단순하지만, 효과적인 아이디어들을 적용하였는데요.pose estimation을 하기 전에 R-CNN을 돌린 후 person으로 예측된 bounding box가 있다면 pose estimation 모델을 돌리도록 했습니다.하지만 위의 필터를 통했음에도 원하는 결과물이 안 나오는 경우가 종종 있었는데요.바로 다음과 같은 경우입니다.생각보다 작은 사람의 stick figure도 잘 추출 내어서 해수욕장으로 떠나 찍은 사진 속의 저 멀리 있는 휴양객을 데일리룩으로 잡는 일이 종종 발생했거든요.그래서 위의 조건에 더불어서 person이라고 예측된 bounding box size가 전체 이미지 크기 대비 n % 이상의 크기 일 경우 Pose Estimation을 진행하자는 것이었죠.적당한 크기 이상의 데일리룩들을 뽑아내고 싶었고 사람이 너무 작아서 안 보이는 경우도 피할 수 있었습니다.빠른 분류 속도는 덤이었고요.덕분에 유저들이 올린 콘텐츠 중 데일리룩이라는 범주에 속하는 콘텐츠를 잘 뽑아낼 수 있었습니다.아래는 위의 과정을 거쳐서 Pose Estimation까지 처리되어 데일리룩 사진이라고 판별된 이미지입니다.이다음으론 무엇을 더 해볼 수 있을까요?사진 속의 자세를 알 수 있게 되었으니 좀 더 재밌는 것을 할 수 있을 것 같은데요.예를 들면 K-Means를 적용하면 비슷한 모습의 데일리룩들만 모아볼 수도 있고 스타일쉐어 유저들이 자주 찍는 자세 라던가 유저 별 자세 선호도 등등 재밌는 것들을 할 수 있을 것 같습니다.날 따라 해 봐요 같은 것도 해볼 수 있겠네요 :)같이 해보지 않을래요?아직도 재밌는 것들이 많이 남은 스타일쉐어 에서는 더 많은 것을 하기 위해 개발자분들을 모시고 있습니다 :)백엔드 개발자라고 해서 백엔드 개발에만 국한되지 않고 하고 싶은 것들을 해도 된다, 할 수 있다고 이야기해 주는 회사라고 생각합니다.스타일쉐어를 좀 더 알고 싶으시다면 여기를 눌러 주세요 :)#스타일쉐어 #개발팀 #개발자 #백엔드개발 #개발인사이트 #경험공유 #후기

오픈서베이 이건노 CTO(이하 폴)는 훌륭한 개발팀의 첫 단추로 ‘일단 매출이 나는 서비스 만들기’를 꼽는 현실주의 개발자입니다. 돈을 벌어야 생존 가능한 환경이 갖춰지고 이때부터 좋은 팀에 대해 고민을 할 수 있다면서요.  동시에 모두가 즐겁게 일하며 공동성장할 수 있는 팀이라는 이상을 꿈꿉니다. 지속가능한 서비스는 지속가능한 개발팀에서 비롯되는데, 즐겁지 않은 업무 환경에서는 그런 개발팀이 나올 수 없다고 믿기 때문입니다.  이런 현실주의적 몽상가는 주니어로 입사해 개발 조직 리더까지 지낸 이스트소프트에서의 경험으로 오픈서베이 개발팀을 리빌딩합니다. 구성원 모두가 즐겁게 일할 수 있는 환경을 위해 폴은 어떤 고민과 노력을 했을까요?   오픈서베이 이건노(폴) CTO   폴, 안녕하세요!  안녕하세요. 스타트업은 처음이라 직원 간 출퇴근 시간도 다르고 영어 이름으로 불리고 하는 게 익숙하지 않았는데, 17년 4월에 조인해서 벌써 만으로 2년째 다니고 있네요(웃음). 오픈서베이 개발팀을 총괄하고 있는 폴입니다.    현실주의적 몽상가의 오픈서베이 합류 계기가 궁금합니다(웃음).  경영진 미팅이었어요. 저는 주변 후배들이 이직 고민할 때도 그 회사의 경영진을 꼭 보라고 이야기하는 편인데, 제가 오픈서베이에 조인한 결정적인 계기도 하이(황희영 대표)와의 미팅이었어요. 하이를 만나보니 제품에 대한 애정이 정말 크다는 걸 느꼈어요. 대표가 제품에 애정이 많다는 뜻은 정말 하고 싶은 일을 한다는 의미잖아요. 사실 제품에는 관심 없고 주식, 엑싯 이런 거만 고민하는 대표도 있거든요. 그런데 하이처럼 제품에 애정이 정말 많은 대표가 있는 회사라면 저도 정말 믿고 다닐 수 있겠다고 생각했어요.  “대표가 제품에 애정이 많다는 뜻은  정말 하고 싶은 일을 한다는 의미라고 생각해요”   현재 개발팀 구성은 어떻게 되나요?  오픈서베이 개발팀은 현재 프로젝트 매니저 3명, 프론트엔드 개발자 2명, 백엔드 개발자 4명, 그리고 앱 개발자 2명까지 총 11명으로 구성돼 있어요. 최근 회사가 빠르게 성장하면서, 올해는 개발팀도 여러모로 성장하는 한 해가 될 것 같아서 기대됩니다.   팀이 성장하면 어떤 변화가 생기나요? 기업의 규모는 천차만별이지만 업무의 범위는 크게 다르지 않아요. 그러다 보니 인원이 적은 스타트업은 한 명이 얕고 넓게 일하는 구조인데, 회사가 성장하면서 직원이 늘면 각 구성원의 역할을 좀 더 세분화하고 전문화할 수 있게 돼요.  오픈서베이 개발팀도 기존에는 프로젝트 매니저가 기획·QA 등 다양한 역할을 모두 소화했다면 최근에는 좀 더 한 분야에 집중해서 깊게 일하는 식으로 역할의 변화를 주고 있어요. 그래서 서비스 기획자·백엔드 개발자·QA 엔지니어 등 다양한 직군을 채용하고 있고요.   오픈서베이 개발팀의 채용 정보를 알고 싶다면? (링크)   조셉(김경만 오베이 PM) 인터뷰를 보면, 개발팀 세미나 제도를 통해 긍정적인 영향을 많이 받은 것 같아요.  사실 세미나 자체가 주니어 개발자의 발언 기회를 위한 제도예요. 개발자는 스스로 제품이나 기술에 대해 주도적으로 고민할 때 역량이 극대화된다고 생각해요. 그런데 주니어 시절에는 아무래도 고민의 결과를 제품이나 기술에 반영하기 힘들죠. 세미나는 이런 갈증을 느끼는 주니어가 좀 더 의욕적으로 일할 수 있는 창구를 제공하기 위해 도입했어요. 구성원분들 덕에 우리 개발팀에는 잘 적용됐지만, 무작정 도입만 한다고 알아서 잘 작동하진 않는 것 같아요. 세미나가 주니어에게는 동등하게 업무 커뮤니케이션을 할 기회지만, 시니어에게는 사실 귀찮고 번거로운 일이 될 수 있거든요. 해왔던 대로 하는 게 편하다는 생각도 들 수 있고 새로운 기술을 팀에 적용하는 과정에서 드는 리소스도 크고요.    주니어 관점일 때는 생각지도 못했는데 이야기를 들어보니 그렇네요.  사실 저도 마찬가지예요. 저도 CTO이기 전에 개발자니까 주니어 개발자의 신선한 아이디어나 최신 기술을 업무에 적용해보고 싶은 마음도 있어요. 주니어분들의 세미나를 통해 저도 새롭게 배우는 점이 많아요. 그런데 CTO 입장에서는 이를 도입했을 때 우리 제품이나 업무 환경에 어떤 영향이 미칠지를 계산하지 않을 수 없어요. 좋아 보인다고 무작정 도입하면 문제가 터졌을 때 대처할 준비가 안 된 거니까 부담이 너무 크거든요.  그래서 이런 제도는 신중하게 도입하고 모든 구성원이 꾸준히 노력해야 잘 유지되는 것 같아요. 저도 간혹 이런 데서 내적 갈등이 생길 때마다 세미나 제도의 긍정적인 영향을 생각하며 이겨내는 편이에요(웃음). 실제로도 팀 업무 환경 개선이나 기술 수준 향상에 많은 도움이 되고 있고요.   “주니어에게도 고민 내용을 공유할 기회를 주려고 해요. 개발자는 주도적으로 제품을 고민할 때 역량이 극대화되거든요”    ‘코드리뷰’도 비슷한 제도라고 들었어요.  맞아요. 코드리뷰는 제품이나 소프트웨어의 변경사항을 체계적으로 관리하는 형상 관리의 일환이기도 해요. 오픈서베이 개발팀은 각 개발 담당자가 코드를 업데이트하면 슬랙에 자동으로 알림이 와요. 그럼 구성원들은 자유롭게 코드를 열어보고 의견을 내는 거죠. 여기서 담당자가 놓친 오류나 실수를 점검해 주거나, 더 효율적이고 경제적인 코드에 대한 의견을 주고받기도 해요.    그럼 코드리뷰는 보통 어떤 식으로 진행되나요?  마이너한 코드는 비대면 방식으로 온라인에서 수시로 리뷰를 진행하는데, 메이저한 코드 업데이트가 있을 때는 따로 회의를 열어서도 해요. 경우에 따라 방식은 다르지만 적극적으로 진행하려는 편이에요.  코드리뷰 제도를 도입하고 장려하는 이유는 명확해요. 개발자는 여럿이 함께 일할수록 시너지가 난다고 생각하거든요. 개발자 개인의 실력이 아무리 좋아도 본인이 작성한 코드의 오류나 실수를 다 잡아내기는 힘드니까요.  코드리뷰 자체가 구성원들이 의견을 주고받으면서 시스템 전반을 두루 이해하고 배우는 과정이기도 해요. 탄탄한 개발팀은 한명의 개발자가 하나의 시스템을 맡는 게 아니라 여러 구성원이 여러 시스템을 보조하는 구조거든요. 그래야 특정 담당자가 공백일 때 다른 구성원이 대신 문제를 처리해줄 수 있고, 개인의 부담도 줄어드니까요.  개발팀의 조셉과 로빈이 코드리뷰 중인 화면   그러다 자칫 잘못하면 서로의 감정을 상하게 하거나, 주니어를 향한 시니어의 훈육 공간으로 전락할 수도 있을 것 같아요.  그래서 어떤 제도가 좋다고 해도 무턱대고 받아들이면 안 된다는 생각을 해요. 도입에 앞서 서로 인신공격을 하면 안 된다거나 리뷰 내용은 공개된 채널에서만 주고받아야 한다는 등의 세세한 규칙을 정할 필요가 있어요. 코드에 대한 의견이 상대방을 헐뜯으려는 게 아니라 제품 개선과 모두의 성장을 위해서라는 상호 신뢰도 충분히 형성돼 있어야 하고요.    구성원들이 서로 자극을 주거나 보고 배우면서 함께 성장하는 팀을 지향하는군요. 정확히 맞아요. 개발자는 연차나 경력과 무관하게 개인별로 역량의 편차가 좀 있는 편이에요. 하나의 팀에 똑같은 수준의 역량을 갖춘 개발자만 모여 있는 게 오히려 부자연스러울 정도로요. 그래서 서로 다른 역량을 가진 팀원들이 함께 일할 때 시너지가 날 수 있는 방법이 필요해요.  저도 예전에는 이렇게 생각하지 않았어요. 일 잘하는 개발자에게 일을 몰아 주고 그 친구가 일을 다 하게 했죠. 거기에 따라 보상도 많이 주고요. 처음에는 일이 되는 것 처럼 보였는데 그런 식으로 한두 명이 일을 많이 하니까 금방 지치더라고요. 결국 서로 도와 가면서 팀으로 일하는 게 필요하더라고요.   그렇게 생각한 특별한 계기가 있나요? 개발팀장 시절에 새로 합류한 구성원 한명이 기억나네요. 좀 독특했어요. 에러·버그 등 문제가 생기면 원인을 파악하고 해결하는 개발업무를 ‘트러블슛(Trouble Shoot)’이라고 하는데, 그 친구는 다른 구성원이 담당하는 시스템의 트러블슛도 함께 고민하는데 시간을 많이 쓰더라고요.  사실 전 그때까지만 해도 팀원은 자신에게 주어진 일을 잘하면 되고 팀장은 역량에 맞춰 일을 잘 분배해주면 된다고 생각했어요. 그래서 이 친구 모습을 보면서 왜 자기 일은 안 하고 다른 사람 일을 야근까지 하면서 보고 있을까 생각했었죠.  그런데 시간이 지날수록 팀원들의 역량과 그 친구의 역량이 동반 성장하더라고요. 그것도 눈에 바로 보일 정도로 빠르게요. 서로 자극을 주고 함께 고민하면서 결국은 팀 전체가 성장한 거예요. 서로 시너지가 났던 거죠. 그러면서 자연스럽게 성과도 잘 나왔어요.   하지만 의지만으로는 자신의 업무를 넘어서 다른 구성원의 업무를 함께 고민하기는 힘들 것 같아요. 팀에서 함께 일할 수 있는 환경을 잘 만들어 주는 게 중요했던 것 같아요. 이슈 관리, 형상 관리, 버전 관리, 테스트, 릴리즈 등 개발과 운영을 위해서 필요한 기본적인 이해가 서로 있어야 해요. 그리고 개발 업무에만 집중할 수 있게 빌드, 배포와 같은 반복적인 업무의 자동화나 운영 툴 개발과 같은 것도 중요합니다.  그리고 가장 중요한 건 서로에 대한 배려심이라고 생각해요. 이번에 도와주고 다음에 도움을 받고 하는 서로에 대한 배려가 없다면 함께 일하는 문화는 자리 잡을 수 없어요. 일이 나뉘어 있기도 하지만 결국 같은 목적으로 일하고 있는 동료와 팀이라는 것을 알고 서로 배려해 주는 거죠. “좋은 제품은 좋은 개발 환경에서 나온다고 생각해요.  그래서 좋은 환경을 만들어주고 싶어요”   레드(김승엽 개발자) 인터뷰만 봐도, 로빈(권장호 개발자)를 통해 자극을 받아 공동성장하는 모습이 인상적이더라고요. 폴은 이런 레드에게 팀장을 넘어 멘토로서도 다양한 조언을 해주려는 것 같아요. 개발팀 구성원들이 회사 안에서의 성장에 갇히길 바라지 않아요. 좋은 인연으로 만났는데 회사라는 틀 안에서 팀장과 팀원 관계로 한정할 필요는 없다고 생각해요. 틀을 벗어나면 제가 할 수 있는 조언의 범위도 넓어지고 깊이도 훨씬 풍부해지기도 하고요. 인생 관점에서 조언해줄 수 있잖아요. 그럼 반대로 저도 레드를 비롯한 다른 구성원들을 통해 많이 보고 배울 수 있게 돼요.    쉽게 가지기 힘든 생각 같은데, 폴의 주니어 때 팀장님을 통해 배우신 건가요? 아니요. 사실 저는 팀장님과의 기억이 많지 않아요. 주니어로 입사한 지 2년 만에 엉겁결에 팀장이 됐거든요. 처음에는 기존 팀장님이 갑작스럽게 자리를 비우면서 팀장 업무를 임시로 맡았어요. 이때는 인사권 같은 건 전혀 없고 그냥 팀 업무를 할당받아서 각 구성원에게 배분하는 역할만 잠깐 한다고 생각했죠. 그런데 회사에서 “이왕 한 거 너가 계속해라”라며 아예 팀장을 시켜버리더라고요. 그때는 많이 당황했어요. 저도 완전 주니어일 때라 좋은 팀장님 밑에서 이것저것 배우고 싶었거든요. 그런데 이렇게 일찍 팀장이 되면서 이젠 내게 가르쳐줄 사람이 없는 걸까 싶어서 앞이 깜깜했어요 “나도 개발 잘할 수 있는데 왜 매니저 역할을 주는 거지? 내가 개발을 잘 못 한다는 건가?”라는 삐뚤어진 생각도 했고요. 얼마나 막막했으면 구글에 ‘팀장이 하는 일’ 같은 걸 검색한 적도 있어요(웃음).   위기를 어떻게 극복했을지 궁금해요. 그 과정이 지금의 폴 인사 철학에 많은 영향을 줬을 것 같아요.  그래도 어쨌든 팀장 일을 해내야 하니까 시선을 좀 넓혀봤어요. 제게는 이제 직속 팀장은 없지만 저보다 경력 많고 실력 좋은 선배 개발자가 팀원으로 있었고, 다른 팀에 훌륭한 시니어 개발자나 선배 팀장님도 계셨죠. 시선을 넓히니 오히려 제가 보고 배울 사람이 더 많더라고요. 그분들에게 궁금한 걸 적극적으로 묻거나 보고 배우면서 중요한 시기를 잘 보낼 수 있었던 것 같아요.  그때 처음으로 깨달은 게 아닐까 싶어요. 제가 엉겁결에 팀장이 되면서 다른 많은 분들을 보면서 보고 배운 것처럼, 팀원들도 꼭 팀장이 아니더라도 다른 팀원들을 서로 보고 배우면서 긍정적인 자극을 받으며 성장할 수 있다는 걸요. ‘팀장은 팀원에게 가르쳐주는 사람이야’란 생각에 갇혀 있었으면 절대 깨닫지 못했을 것 같아요. 얘기를 해보니 정말로 저 난관을 통해서 지금과 같은 생각을 할 수 있게 된 것 같네요(웃음).  “팀장과 팀원이라는 틀을 벗어나면 훨씬 풍부하게 긍정적인 자극을 주고받을 수 있어요”   폴의 경험과 고민이 결국은 팀 업무 환경이나 문화를 통해 드러나는 것 같네요. 그렇게 봐주시면 정말 고맙죠. 사실 어떻게 하면 더 일하기 좋은 회사와 팀을 만들 수 있을지는 계속 고민되는 부분이에요. 돈 많이 주는 회사가 일하기 좋은 회사라고 간단히 생각해버릴 수도 있는데, 저는 일하기 좋은 회사를 이루는 요건은 좀 더 다양한 것 같거든요. 일단 하는 일이 어떤 가치를 가지고 있고 이것을 쓰는 사람들에게 어떤 가치를 제공해 주는지 알고 있어야 해요. 그래야 내가 하는 일에서 보람을 찾을 수 있으니까요. 물론, 회사에서도 보람을 가질 수 있는 방법을 함께 고민해 줘야겠죠.  보람만으로 회사에 다닐 수 없으니 역세권 사무실, 맛있는 커피, 좋은 경영진, 좋은 팀원 등 중요한 요건들이 엄청 많은데요. 오픈서베이는 서로에게 자극을 주거나 보고 배우며 스스로 성장할 수 있는 좋은 구성원들이 많은 것 같아요. 저도 요즘  구성원들에게 많이 배우고 있습니다.    마지막 질문입니다. 좋은 팀을 위한 폴의 역할은 무엇인가요?  장점을 찾아 주는 게 저의 중요한 일이죠. 잘하는 일을 해야 역량도 극대화되거든요. 장점이 없는 사람은 없다고 생각해요. 장점을 잘 모르는 친구들이 있는데 이런 친구들의 장점을 찾아주고 또 그 장점이 회사에서 잘 발현되도록 도와주는 조력자 역할을 잘 해내는 게 제가 할 일이라고 생각해요.  좋은 장점이 잘 발현되면 개발자는 한 단계 더 성장할 기회가 생겨요. 예를 들어 초기 제품 기능을 빠르게 잘 만드는 게 장점인 친구는 신사업 중심의 일을 할 수 있게 해주면 그 역량이 잘 발현되거든요. 거기서 가치를 인정받고 탄력이 붙으면 지속적으로 좋은 성과를 낼 수 있게 되고요. 이 과정을 저는 “알을 깨고 나온다”라고 표현하는데, 이렇게 알을 깨고 나오면 좀 더 제품이 주는 본질적인 가치를 알게 된다고 생각해요. 개발자로서 일하는 가치와 방법을 알게 되는 거죠. 그런 만큼 오픈서베이의 예비 구성원분들도 좋은 자극을 받으며 성장할 수 있는 계기가 되셨으면 좋겠어요. 회사를 그저 출근해서 일만 해주고 돈을 받아가는 공간이라고 생각하면 회사 다니기가 우울하잖아요. 사람마다 얻어갈 수 있는 건 다 다르겠지만, 긍정적인 영향을 받아 성장하는 계기가 오픈서베이가 될 수 있을 것같아요.    “폴과 함께 즐겁게 일하고 싶으시다면 지금 바로 오픈서베이 입사지원을 해보세요”  

최근의 가장 핫한 연구분야인 '자율주행'의 바탕에는 '컴퓨터 비전'이 필요하다는 사실을 아셨나요? 홍채인식, 스노우 어플도 '컴퓨터 비전'을 사용한 사례입니다. 우리의 가까이 다가와 있지만, 기술 자체에 대해서는 어딘가 생소합니다. 어반베이스의 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 

전 세계적으로 프로그래밍 교육 열풍이 불고 있습니다. 몇 년 전부터 시작된 이 열풍을 타고 프로그래밍을 가르치는 공개 온라인 강좌(MOOC; Massive Open Online Course)가 우후죽순으로 생겨났습니다. 이들 수업은 시간과 장소에 구애받지 않고 어디에서나 누구나 자유롭게 수업을 들을 수 있는 MOOC의 특성을 십분 활용하여 수천 수만 명의 학생을 효과적으로 모집하고, 프로그래밍의 기초부터 전문가가 되기 위한 직업 교육의 영역까지 다양한 교육을 진행하고 있습니다.그러나 비디오 강의와 프로그래밍 숙제를 위주로만 이루어지는 온라인 프로그래밍 강의들은 아직까지 소규모 오프라인 강의들이 제공하는 수준의 효과적인 학습 효과를 제공하는 데에는 어려움을 겪고 있습니다. 이러한 학습 효과의 열화가 일어나는 원인에 대해서는 수많은 연구자가 각기 다른 이론과 실험을 근거로 들고 있지만, 그중에서도 많은 사전 연구와 실험을 통해 밝혀진 원인 중 하나는 “학생과 강사 사이의 소통”이 기존에 교육 환경에 비해 부족하다는 점입니다.비디오로 이루어진 강의에서 어떻게 강의를 전달하는 것이 효과적일지에 대한 연구가 진행되었습니다. 논문: How Video Production Affects Student Engagement: An Empirical Study of MOOC Videos몇 가지 예시를 들어보자면, 기존의 소규모 오프라인 교육 환경에서는 학생이 궁금한 점이 있을 때 강사에게 즉석에서 질문하고 답변을 받을 수 있지만, 이미 녹화된 동영상을 보며 학습하는 온라인 비디오 강의에서는 이러한 간단한 소통마저 아직 완벽하게 이루어지지 못하고 있고, 이러한 한계점은 연구자들에게 새로운 연구의 대상이 되고 있습니다.Elice에서는 학생이 문제를 풀다 질문이 생기면 조교와 1:1로 대화를 할 수 있습니다.비슷하지만 다른 예시로, 수업 시간 이외의 시간에 일어날 수 있는 소통의 예를 들어보자면, 숙제의 채점과 피드백을 예로 들어볼 수 있습니다. 소규모 강의에서는 몇몇 조교가 학생들이 제출한 프로그래밍 숙제를 하나하나 검사하고, 채점한 뒤 개개인에게 필요한 피드백을 주는데에 큰 문제가 없습니다. 그러나 많아야 수십 명의 조교가 많게는 수만 명의 학생이 제출한 과제를 채점해야 하는 MOOC 환경이라면 이야기가 달라집니다.MOOC 환경에서 과제의 효과적인 채점에 대한 연구는 아직도 활발하게 연구되고 있는 매우 흥미로운 주제입니다. 서론이 조금 길었던 것 같기도 하지만, 이번 글에서는 온라인 프로그래밍 강의가 좀 더 효과적으로 되기 위해 넘어야 할 허들 중 하나인 “수많은 학생이 제출한 과제를 어떻게 하면 효과적으로 채점하고 피드백을 줄 수 있을까?”라는 문제에 대해 elice 팀에서 연구한 내용을 여러분들과 공유해보고자 합니다.동료 평가 (Peer Assessment)MOOC 환경에서 몇 명의 조교만으로 제출된 수만 개의 과제를 채점하는 것은 현실적으로 불가능하므로, 이미 프로그래밍을 가르치는 일부 MOOC들은 연구를 통해 학생들이 제출한 과제를 자동으로 채점해주는 프로그램을 개발하여 사용하고 있습니다.Elice의 자동 채점. 정해진 답이 있는 경우 자동 채점은 실시간으로 학생들이 받을 수 있는 새로운 피드백 채널이 됩니다.그러나, 프로그래밍 과목에서 자동 채점 프로그램은 한정적인 상황에서만 성공적으로 사용될 수 있으며, 특히나 과제의 내용이 명확한 답을 요구하지 않는 형태이거나 (예를 들어, 오늘 배운 명령어들을 이용하여 멋진 집을 3D로 그려주는 프로그램을 작성하시오!), 단순한 비교만으로 정답을 매길 수 없는 경우에는 사용될 수 없다는 명백한 한계점이 존재합니다. 그래서 프로그래밍 교육을 연구하는 연구자들은 자동 채점 프로그램도 아니고, 조교도 아닌 누가 학생들의 과제를 채점하고, 피드백을 줄 수 있을까를 고민하던 도중 이미 다른 교육 분야에서 연구되어 사용되던 “동료 평가 (peer assessment)”라는 방법에 눈을 돌리게 되었습니다.동료 평가란 간단하게 말하자면 학생들이 서로 간의 과제를 채점해주는 방식의 과제 채점 방법을 말합니다. 제출된 과제의 수 만큼 이것을 채점할 수 있는 학생 수가 존재하기 때문에, 동료 평가는 강의에 크기에 거의 무관하게 사용될 수 있다는 장점이 있습니다. 또한, 학생들은 다른 학생들이 제출한 과제를 채점하면서 자기가 생각하지 못했던 새로운 아이디어를 발견하거나, 자신이 했던 것과 유사한 실수를 하는 친구에게는 자신의 경험을 바탕으로 건설적이고 유용한 피드백을 줄 수 있는 등의 장점도 있습니다. 물론 학생 개개인의 실력은 숙련된 조교보다는 미숙하기 마련이지만, 조교가 한 개의 과제에 대해 한 개의 피드백만 남겨줄 수 있는 시간적 여력이 있었다면, 동료 평가에서는 한 개의 과제에 대해 열 명의 학생들이 서로 다른 열 개의 피드백을 주어 학생 개개인의 부족함을 보완할 수 있습니다. 다양한 선행 연구에 따르면, 하나의 과제를 다수의 학생이 채점하게 될 경우 통계적으로 조교와 비슷한 수준의 채점을 할 수 있다는 점이 증명된 바 있습니다.캔버스에 그림을 그리거나 애니메이션을 만드는 문제에서 동료 평가가 활용되고 있습니다.동료 평가는 프로그래밍 교육 환경에서 특히나 더욱더 빛을 발하고 있는데, 이는 프로그래밍 과목이 기초 과학이나 수학과 같은 과목과는 달리, 프로그램의 작동 원리에 대한 이론과 이를 실제로 구현하기 위한 기술 두 가지가 모두 숙련되어야만 효과적으로 활용될 수 있는 특징으로부터 기인합니다. 하나의 원리를 배우더라도 다양한 구현을 보고, 연습해보는 것이 좋고, 이는 동료 평가를 통해 다른 사람들이 제출한 과제를 검사하며 효과적으로 이루어질 수 있습니다. 그 이외에도 숙련된 프로그래머의 자질을 평가하는 기준 중 하나로 사용되는 “코드의 가독성(다른 사람이 보고 이해하기에 얼마나 좋게 작성되었는가)”과 같이 기계적으로는 채점하기 항목들은 동료 평가를 통해 쉽게 평가될 수 있는 등 프로그래밍 교육 환경에서 동료 평가가 가지는 장점은 전부 나열할 수 없을 정도입니다.그러나 동료 평가가 항상 만능인 것만은 아닙니다. 다음 포스트에서는 프로그래밍 동료 평가가 왜 어려운지, Elice 팀에서는 이 문제를 어떻게 해결했는지 소개해 드리도록 하겠습니다 :)#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개

와탭랩스는 IT 서비스를 운영하는 개발팀과 운영팀에 도움이 되는 솔루션과 서비스를 만드는 스타트업입니다. IT 서비스를 잘 운영하게 위해서는 Infrastructure의 전반적인 상황을 항시 체크할 수 있어야 하는데요. 이런 기능을 하는 대표적인 화면이 대시보드 입니다. 최근 와탭랩스는 Infrastructure 모니터링 서비스에 대시보드를 넣는 작업을 진행하고 있는데요. 와탭랩스는 대시보드를 통해 Infrastructure를 운영하는 개발팀과 운영팀에 어떻게 도움을 줄 수 있도록 할 것인지 소개하겠습니다. 1. IT 서비스 운영에 사용된 인프라 자산 현황을 알아보자지금 회사에서 사용하는 서버의 대수를 알고 계신가요? 현재 동작하는 서버는 몇대인지 혹시 죽어있는 서버가 있는지 등에 대한 정보는 운영팀에서 항상 체크하는 정보입니다. 하지만 개발팀에서는 잘 모르는 정보이기도 하죠. 이런 기본적인 정보가 대시보드에 나온다면 평소 서비스를 운영하는 감을 잡는데 도움이 됩니다. 이런 정보들은 간략한 수치로도 표현할 수 있는데요. 우리는 아래와 같은 데이터를 수집할 수 있습니다. 서버 기본 정보 (inactive servers / all servers)우리가 사용하는 총 서버의 수자와 비활성화된 서버의 숫자는 우리가 항상 알고 있어야 하는 정보입니다.운영체계별 서버 정보 (Linux / Windows / Unix)운영체계를 섞어 사용하는 경우에는 운영체계에 따라프로젝트가 나눠지기도 합니다. 그렇기 때문에 운영체계별로 서버의 총량과 비활성화된 서버 정보를 알면 도움이 됩니다. 프로세스 수프로젝트의 프로세스 수는 일정한 경우가 많습니다. 전체 프로세스의 숫자가 변경된다면 서비스의 운영 상황에 대해 의문을 가져야 합니다. 이벤트 개수24시간동안 발생한 전체 이벤트의 개수와 아직 해결하지 못한 이벤트의 개수를 보여줍니다. 하루동안 얼마나 많은 이벤트가 발생하는지 그리고 아직 해결하지 못한 이벤트가 있는지 알수 있습니다. 디스크 사용량/전체 용량디스크 사용량은 일반적으로 큰 변화를 가지지 않습니다. 디스크 사용량이 평소와 다르다면 서비스의 장애가 발생했거나 발생할 가능성이 높습니다. 메모리 사용량 / 전체 용량메모리 사용량은 일반적으로 큰 변화를 가지지 않습니다. 메모리 사용량이 평소와 다르다면 서비스의 장애가 발생했거나 발생할 가능성이 높습니다. 수치 데이터의 예 2. 서비스를 구성하는 인프라의 CPU 흐름 전체를 알아보자 CPU 사용량은 변화량이 많은 지표입니다. 변화량을 비교하는 챠트로는 라인 차트가 가장 많이 쓰이지만 라인 차트는 개수가 많아지면 전체 상황이 보이지 않는 문제점을 가지고 있습니다. 또한 실시간으로 추가되거나 삭제되는 인프라가 생기는 클라우드 인프라 상황에서 라인챠트는 표현의 한계를 가지고 있기도 합니다. 이런 문제를 해결하기 위한 방법으로 아래와 같은 온도 차트를 사용할 수 있습니다. 온도 차트는 단위 영역에 밀도에 따라 색상으로 깊이를 표현하는 방식입니다. 최근 많은 양의 데이터를 표현하는 방식으로 많이 사용되고 있습니다. 온도 차트의 예3. 경고가 발생했는지 또는 해결 되었는지 알고 싶다.  CPU 사용량이 설정치 이상으로 높아지거나 디스크 사용량이 높아지거나 프로세스가 사라지는 등 다양한 상황에 대한 이벤트가 발생할 수 있습니다 이런 상황을 쉽게 확인할 수 있다면 서비스 운영 상황에 도움이 됩니다. 이벤트 관리의 예이런 스토리를 기반으로 와탭랩스에서 대시보드를 기획하고 있습니다. 개발자와 디자이너가 함께 토론하고 논의하면서 화면과 스토리를 더 다듬게 되면 첫번째 화면이 나올 예정입니다. 아래는 기획과정에서 나온 화면 리소스 입니다. 아직 기획 단계이기는 하나 첫번째 대시보드가 완성되면 이 페이지가 메인으로 올라갈 예정입니다. 대시보드는 데이타의 종류와 위치등을 수정할 수 있으면 좋지만 우선은 고정형으로 개발하여 제공할 예정입니다. 이번 대시보드는 서비스 첫번째 의미가 강한 메인 화면의 성격에 더 초점을 맞추고 있습니다. 아직 몇몇 논의되는 사항이 많은 화면이지만 빠르게 개발하여 가능한 이른 시일에 소개드리도록 하겠습니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

1. What is BLE?스마트폰이 출시되어 대중화가 될 무렵, ‘스마트’한 개념의 밴드, 워치, 글래스 등이 출시되면서 웨어러블 디바이스 시장이 태동하기 시작했다. 그리고, 2015년 상반기, 애플워치의 등장으로 작은 생태계를 이루고 있던 웨어러블 디바이스들이 다시 한번 각광을 받게 되었다. 각기 생긴 모습은 다르지만 이들의 공통점은 스마트폰과 연동되어 작동한다는 것이었다. 과거부터 기기들간의 단거리 무선통신은 Bluetooth라는 기술이 이용되었다. Bluetooth가 공식적으로 등장한지 약 16년이라는 세월이 흘렀지만, 여전히 기기간의 무선통신에는 Bluetooth가 사용된다. 하지만, 지금 사용되는 Bluetooth는 기존과는 다른 방식이다. 바로 BLE라는 특징을 가진 Bluetooth인데, 바로 이것이 오늘날 다양한 종류의 웨어러블 디바이스들이 태어날 수 있었던 원동력이 되었다. 그렇다면 BLE라는 것이 도대체 무엇일까?그림1. BLE가 뭐지? 먹는건가?과거부터 기기들간의 무선 연결은 주로 Bluetooth라는 기술을 이용했는데, 이들은 기기간에 마스터, 슬레이브 관계를 형성하여 통신하는 Bluetooth Classic이라는 방식을 이용했다. 사람들이 이러한 기기들을 이용하면서 많이 염려했던 것은 ‘Bluetooth를 연결하면 베터리가 빨리 소모된다’, ‘사용하지 않을 때는 Bluetooth 꺼놓아야지’ 등과 같은 베터리 관련된 문제들이었다. 사실이었다. Bluetooth Classic은 다른 디바이스를 무선으로 연결을 하여 사용할 수 있는 편리함을 주었지만, 연결이 되는 동안에는 베터리를 빠르게 소모시켰기 때문에 사용하는 데에 많은 불편함이 있었다.2010년, 새로운 Bluetooth 표준으로 Bluetooth 4.0 이 채택이 된다. 기존의 Bluetooth Classic과의 가장 큰 차이는 훨씩 적은 전력을 사용하여 Classic과 비슷한 수준의 무선 통신을 할 수 있다는 점이었다. 이는 당시 Bluetooth의 최대 단점이었던 과도한 베터리를 소모 문제를 해결하는 기술이었기 때문에, Bluetooth 관련 업계에 큰 반향을 일으켰다. 이렇게 저전력을 이용하여 무선통신을 하는 특징을 Bluetooth Low Energy (이하 BLE) 라고 부르는데, Bluetooth 4.0 이후의 버전들은 이 용어로 대체되서 불리기도 한다. 최근 출시되고 있는 스마트 밴드, 워치, 글래스 등의 웨어러블 무선통신 기기들의 대부분은 이 BLE 방식을 이용하여 무선 통신을 한다.Bluetooth Smart Ready, Smart, ClassicBLE 기술이 등장하면서 Bluetooth 디바이스들은 아래와 같이 3가지로 분류 되었다.그림2. BLE 3가지 분류Bluetooth 4.0과 함께 새롭게 등장한 Bluetooth Smart Ready, Bluetooth Smart에 대해서 살펴보면,Bluetooth Smart Ready 디바이스는 Bluetooth Classic 및 저에너지 Bluetooth 무선통신 (BLE)을 지원하기 때문에 “듀얼 모드” 라디오라고 불린다. 따라서, 이들은 현재 시장에 나와 있는 수억 종의 Bluetooth 디바이스들에 대한 역방향 호환성을 가진다. 종류에는 스마트폰, 태블릿, PC, TV 그리고 셋탑박스 및 게임 콘솔 등이 있다. 이런 디바이스들은 클래식 Bluetooth 디바이스 및 Bluetooth Smart 디바이스들로부터 데이터를 받아, 이들을 유용한 정보로 변환시키는 Bluetooth 시스템의 허브라고 할 수 있다.Bluetooth Smart 디바이스 내에 있는 라디오는 “싱글모드” 라디오라 불리는데, BLE 연결만을 지원한다는 의미이다. 이들은 기존의 Bluetooth Classic 디바이스들과 호환이 되지 않고 듀얼모드 라디오를 가진 Bluetooth Smart Ready 디바이스 혹은 제조업체에 의해 호환성이 명시된 특정 Bluetooth 디바이스에만 연결이 가능하다. Bluetooth Smart 디바이스들은 ‘우리 집의 창문은 모두 잠겨 있는지’, ‘내 인슐린 농도는 얼마인지’, ‘오늘 내 몸무게는 몇 킬로그램인지’ 등과 같이 특정한 형태의 정보를 수집해, Bluetooth Smart Ready 디바이스로 보내기 위해 만들어진 디바이스이다. 종류에는 심박 모니터, 스마트 손목시계, 창문 및 현관 보안 센서, 자동차 키 체인, 그리고 혈압 팔찌 등이 있다.이 글에서는 BLE를 사용하는 디바이스들이 어떤 과정으로 서로 연결되어 통신을 하는지 그리고 이 과정들을 tracking 할 수 있는 장비인 Ubertooth 에 대해 내용을 정리해서 공유해보고자 한다.2. How they communicate?BLE를 지원하는 디바이스들은 기본적으로 Advertise(Broadcast) 과 Connection 이라는 방법으로 외부와 통신한다.Advertise Mode ( = Broadcast Mode)특정 디바이스를 지정하지 않고 주변의 모든 디바이스에게 Signal을 보낸다. 다시 말해, 주변에 디바이스가 있건 없건, 다른 디바이스가 Signal을 듣는 상태이건 아니건, 자신의 Signal을 일방적으로 보내는 것이라고 생각하면 된다. 이 때, Advertising type의 Signal을 일정 주기로 보내게 된다.Advertise 관점에서, 디바이스의 역할은 다음과 같이 구분된다.Advertiser ( = Broadcaster) : Non-Connectable Advertising Packet을 주기적으로 보내는 디바이스.Observer : Advertiser가 Advertise를 Non-Connectable Advertising Packet을 듣기 위해 주기적으로 Scanning하는 디바이스.그림3. Advertiser and ObserverAdvertise 방식은 한 번에 한 개 이상의 디바이스와 통신할 수 있는 유일한 방법이다. 주로 디바이스가 자신의 존재를 알리거나 적은 양(31Bytes 이하)의 User 데이터를 보낼 때도 사용된다. 한 번에 보내야 하는 데이터 크기가 작다면, 굳이 오버헤드가 큰 Connection 과정을 거쳐서 데이터롤 보내기 보다는, Advertise를 이용하는 것이 더 효율적이기 때문이다. 게다가 전송할 수 있는 데이터 크기 제한을 보완하기 위해 Scan Request, Scan Response을 이용해서 추가적인 데이터를 주고 받을 수 있다 (이에 대해서는 뒤에 자세히 설명한다). Advertise 방식은 말 그대로 Signal을 일방적으로 뿌리는 것이기 때문에, 보안에 취약하다.Connection Mode양방향으로 데이터를 주고받거나, Advertising Packet으로만 전달하기에는 많은 양의 데이터를 주고 받아야 하는 경우에는, Connection Mode로 통신을 한다. Advertise처럼 ‘일대다’ 방식이 아닌, ‘일대일’ 방식으로 디바이스 간에 데이터 교환이 일어난다. 디바이스간에 Channel hopping 규칙을 정해놓고 통신하기 때문에 Advertise보다 안전하다.Connection 관점에서 디바이스들의 역할은 다음과 같이 구분된다.Central (Master) : Central 디바이스는 다른 디바이스와 Connection을 맺기 위해, Connectable Advertising Signal을 주기적으로 스캔하다가, 적절한 디바이스에 연결을 요청한다. 연결이 되고 나면, Central 디바이스는 timing을 설정하고 주기적인 데이터 교환을 주도한다. 여기서 timing이란, 두 디바이스가 매번 같은 Channel에서 데이터를 주고 받기 위해 정하는 hopping 규칙이라고 생각하면 된다.Peripheral (Slave) : Peripheral 디바이스는 다른 디바이스와 Connection을 맺기 위해, Connectable Advertising Signal을 주기적으로 보낸다. 이를 수신한 Central 디바이스가 Connection Request를 보내면, 이를 수락하여 Connecion을 맺는다. Connection을 맺고 나면 Central 디바이스가 지정한 timing에 맞추어 Channel을 같이 hopping을 하면서 주기적으로 데이터를 교환한다.그림4. Central and Peripheral3. Protocol Stack디바이스들은 Bluetooth로 통신을 하기 위한 Protocol Stack을 가지고 있다. 일반적으로 네트워크 통신을 하기 위해서는, 통신을 위한 규약인 Protocol을 정의해야 되는데, 이렇게 정의된 Protocol들을 층층이 쌓아놓은 그룹이 Protocol Stack이다. Bluetooth Signal Packet을 수신하거나 송신할 때, 이 Protocol Stack을 거치면서 Packet들이 분석되거나 생성된다.그림5. Protocol Stack위 그림에서 볼 수 있듯이 Protocol Stack은 가장 아랫단부터 크게 Controller, Host, Application 로 나뉜다. 여기서는 Connection 과정에서 필요한 부분인 Physical Layer, Link Layer, Generic Access Profile(GAP), Generic Attribute Profile(GATT)에 대해서 알아볼 것이다.3.1 Physical LayerPhysical Layer에는 실제 Bluetooth Analog Signal과 통신할 수 있는 회로가 구성되어 있어서, Analog 신호를 Digital 신호로 바꾸어 주거나 Digital 신호를 Analog 신호로 바꾼다. 또한 Bluetooth에서는 2.4 GHz 밴드를 총 40개의 Channel로 나누어 통신을 한다. 40개 Channel 중 3개 Channel은 Advertising Channel 로써 각종 Advertising Packet을 비롯하여 Connection을 맺기 위해 주고 받는 Packet들의 교환에 이용된다. 나머지 37개의 Channel은 Data Channel 로써 Connection 이후의 Data Packet 교환에 이용된다.그림6. Channels3.2 Link LayerPhysical Layer의 바로 윗단에는 Link Layer이 있다. Link Layer은 하드웨어와 소프트웨어의 조합으로 구성되어 있다. 하드웨어 단에서는 높은 컴퓨팅 능력이 요구되는 작업들 (Preamble, Access Address, and Air Protocol framing, CRC generation and verification, Data whitening, Random number generation, AES encryption 등)이 처리되고, 소프트웨어 단에서는 디바이스의 연결 상태를 관리한다. 또한 통신하는데 있어서 디바이스의 Role을 정의하고 이에 따라 변경되는 State를 가지고 있다.RoleMaster : 연결을 시도하고, 연결 후에 전체 connection을 관리하는 역할.Slave : Master의 연결 요청을 받고, Master의 timing 규약을 따르는 역할.Advertiser : Advertising Packet을 보내는 역할.Scanner : Advertising Packet을 Scanning하는 역할. Scanner는 아래와 같은 2가지 Scanning 모드가 있다.Passive Scanning : Scanner는 Advertising Packet을 받고 이에 대해 따로 응답을 보내지 않는다. 따라서 해당 Packet을 보낸 Advertiser는 Scanner가 Packet을 수신했는지에 대해서 알지 못한다.Active Scanning : Advertising Packet을 받은 Scanner는 Advertiser에게 추가적인 데이터를 요구하기 위해 *Scan Request라는 것을 보낸다. 이를 받은 Advertiser는 *Scan Response로 응답한다.Scan Request, Scan Response : Advertising Packet type의 한 종류이다. 앞서, 31bytes 이하의 User data에 대해서는 Advertising Signal Packet에 넣어서 보낼 수 있다고 하였다. 하지만 31bytes보다는 크지만, Commection까지 맺어서 보내기는 오버헤드가 큰 데이터가 있을 때, Scan Request, Scan Response를 이용하면 두 번에 걸쳐서 데이터를 나눠 보낼 수 있게 된다. Advertising Packet을 받은 Scanner는 추가적인 User Data(예를 들어, Peripheral 디바이스의 이름)를 얻기 위해 Scan Request를 보내게 된다. Scan Request를 받은 Advertiser는 나머지 데이터를 Scan Response Signal에 담아서 보낸다.이들은 크게 Connection 전의 역할(Advertiser, Scanner), 후의 역할(Master, Slave)로 분류된다.StateLink Layer는 5가지 State를 가지고 있는데, 각 디바이스는 서로 연결이 되는 과정에서 이 State를 변화시킨다. 다음과 같은 5개의 State가 존재한다.Standby State : Signal Packet을 보내지도, 받지도 않는 상태.Advertising State : Advertising Packet을 보내고, 해당 Advertising Packet에 대한 상대 디바이스의 Response를 받을 수 있고 이에 응답할 수 있는 상태.Scanning State : Advertising Channel에서 Scaning하고 있는 상태.Initiating State : Advertiser의 Connectable Advertising Packet을 받고난 후 Connetion Request를 보내는 상태.Connection State : Connection 이후의 상태.아래 그림은 각각의 State를 Diagram으로 나타낸 것이다.그림7. Link Layer State3.3 Generic Access Profile (GAP)Generic Access Profile (GAP)는 서로 다른 제조사가 만든 BLE 디바이스들끼리 서로 호환되어 통신할 수 있도록 해주는 주춧돌 역할을 한다. 즉, 어떻게 디바이스간에 서로를 인지하고, Data를 Advertising하고, Connection을 맺을지에 대한 프레임워크를 제공한다. 그래서 GAP는 최상위 Control Layer라고도 불린다. Advertising Mode일 때, GAP에서 Advertising Data Payload와 Scan Response Payload를 포함할 수 있다.또한 GAP에서는 BLE 통신을 위해 Role, Mode, Procedure, Security, Additional GAP Data Format 등을 정의한다. 이들은 실제 API와 직접적으로 많은 연관이 있기 때문에 그 내용이 상당히 많지만, 여기서는 BLE Connection과 관련이 있는 Role에 대해서만 알아보겠다.RoleBroadcaster : Link Layer에서 Advertiser 역할에 상응한다. 주기적으로 Advertising Packet을 보낸다. 예를 들면, 온도센서는 온도데이터를 자신과 연결된 디바이스에게 일정주기로 보낸다.Observer : Link Layer에서 Scanner 역할에 상응한다. Broadcaster가 뿌리는 Advertising Packet에서 data를 얻는다. 온도센서로부터 온도데이터를 받아서 디스플레이에 나타내는 테블릿 컴퓨터의 역할이다.Central : Link Layer에서 Master 역할과 상응한다. Central 역할은 다른 디바이스의 Advertising Packet을 듣고 Connection을 시작할 때 시작된다. 좋은 성능의 CPU를 가지고 있는 스마트폰이나, 테블릿 컴퓨터들의 역할이다.Peripheral : Link Layer에서 Slave 역할과 상응한다. Advertising Packet을 보내서 Central 역할의 디바이스가 Connection을 시작할 수 있도록 하게끔 유도한다. 센서기능이 달린 디바이스들의 역할이다.3.4 Generic Attribute Profile (GATT)BLE Data 교환을 관리하는 GATT는 디바이스들이 Data를 발견하고, 읽고, 쓰는 것을 가능하게 하는 기초적인 Data Model과 Procedure를 정의한다. 그래서 GATT는 최상위 Data Layer라고도 불린다. 디바이스간에 low-level에서의 모든 인터렉션을 정의하는 GAP와는 달리, GATT는 오직 Data의 Format 및 전달에 대해서만 처리한다. Connection Mode일 때, GATT Service와 Characteristic을 이용하여 양방향 통신을 하게 된다. Service와 Characteristic에 대한 내용은 여기를 참고하길 바란다.GATT도 Data 처리와 관련해서 다음과 같은 역할을 정의한다.RoleClient : Server에 Data를 요청한다. 하지만 처음에는 Server에 대해서 아는 것이 없기 때문에, Service Discovery라는 것을 수행한다. 이 후, Server에서 전송된 Response, Indication, Notification을 수신할 수 있다.Server : Client에게 Request를 받으면 Response를 보낸다. 또한 Client가 사용할 수 있는 User Data를 생성하고 저장해놓는 역할을 한다.4. Packet TypeBLE 통신에서는 두 가지 종류의 패킷인 Advertising Packet, Data Packet만이 존재한다. Connection을 맺기 전에는 Advertising Packet type, 맺은 후에는 Data Packet type으로 Signal을 생성한다. Data Packet은 하나로 통일되지만, Advertising Packet은 특정 기준에 따라서 다음과 같은 성질들을 갖는다.ConnectabilityConnectable : Scanner가 Connectable Advertising Packet을 받으면, Scanner는 이를 Advertiser가 Connection을 맺고 싶어한다는 신호로 받아들인다. 그러면 Scanner는 Connection Request (이하 CONNECTREQ)를 보낼 수 있다. 해당 Connectable Signal을 보낸 Advertiser는 Scanner가 CONNECTREQ가 아닌 다른 타입의 Signal을 보내면 해당 Packet을 무시하고 다음 Channel로 이동하여 계속 Advertising을 진행한다.Non-Connectable : Non-Connectable Packet을 받은 Scanner는 CONNECT_REQ를 보낼 수 없다. 주로 Connection 목적이 아닌, Data 전달이 목적일 때 쓰인다.ScannabilityScannable : Scanner가 Scannable Advertising Packet을 받으면, Scan Request (이하 SCANREQ)를 보낼수 있다. Scannable Signal을 보낸 디바이스는 Scanner가 SCANREQ가 아닌 다른 타입의 Signal을 보내면 해당 Packet을 무시하고 버린다.Non-Scannable : Non-Scannable Signal을 받은 Scanner는 SCAN_REQ를 보낼 수 없다.DirectabilityDirected : Packet안에 해당 Signal을 보내는 디바이스의 MAC Address와 받는 디바이스의 MAC Address가 들어있다. MAC Address 이외의 데이터는 넣을 수 없다. 모든 Directed Advertising Packet은 Connectable 성질을 갖는다.Undirected : 해당 Signal을 받는 대상이 지정되어 있지 않다. Directed Advertising Packet과는 다르게, 사용자가 원하는 데이터를 넣을 수 있다.위의 내용을 종합하면, Advertising pakcet을 아래와 같이 4가지 type으로 나눌 수 있다.그림6. Advertising Packet Type5. How they really communicate?BLE 통신의 핵심은 ‘timing’이다.Before ConnectionConnection 전, 디바이스는 3개의 Advertising Channel을 이용해서 데이터를 주고 받는다고 했다. 이들은 이 3개의 Channel을 자신만의 time interval로 hopping한다. 서로의 hopping 규칙이 일치하지 않기 때문에 Channel이 서로 엇갈리는 경우가 많을 것이다. 예를 들어, Advertiser는 1번 Channel에 Advertising Packet을 보냈는데, 같은 시간에 Scanner는 3번 Channel에 대해서 Scanning을 하게 되면 데이터 전달이 되지 않는 것이다. 하지만 이러한 hopping이 빠르게 자주 일어나기 때문에, 두 디바이스가 같은 Channel에 대해 Advertising와 Scanning이 발생하는 경우도 많이 생긴다. 이 경우에 서로 데이터를 주고 받을 수 있다.After ConnectionConnection이 되면, Advertising은 종료되고 기기들은 Central, Peripheral 중 하나의 역할을 하게된다. Connection을 개시한 기기가 Central이며, Advertiser가 Peripheral이 된다. 그리고 두 디바이스는 엇갈렸던 hopping 규칙을 통일시킨다. 그렇게 함으로써, 매번 같은 채널로 동시에 hopping하면서 Signal을 주고 받을 수 있게 된다. 이는 둘 간의 Connection이 끊어질 때까지 지속된다.6. How they connect each other?디바이스간의 BLE 연결을 iPhone과 Zikto Walk와의 연결과정으로 설명하면 다음과 같다.1) Zikto Walk가 Advertising Channel을 hopping하면서 Advertising Packet을 보낸다.(Zikto Walk의 Advertising Packet 유형은 ADV_IND이다)2) iPhone Bluetooth를 켠 후, Zikto 앱에 Zikto Walk를 등록한다. iPhone은 Advertising Channel을 hopping하면서 Scan을 하다가 연결하려는 Zikto의 디바이스 이름 등의 추가적인 정보를 얻기위해 SCAN_REQ를 보낸다.3) SCANREQ를 받은 Zikto Walk는 SCANRSP를 보낸다.4) Pairing이 완료되고, Zikto Walk는 다시 Advertising Packet을 다시 일정 주기마다 보낸다.5) iPhone에서 Zikto Walk로부터 걸음 수 등의 Data를 받기 위해 Sync 버튼을 누른다. 이 버튼을 누르면 iPhone은 CONNECT_REQ를 보낸다.6) Zikto와 iPhone은 서로 Acknowledging을 시작하고, timing 정보 등을 동기화 한다.7) Connection이 완료된다.8) Connection이 완료된 후, Service Data, Characteristic Data 등에 대한 Data 교환이 일어난다.9) iPhone과 Zikto Walk간에 Data Sync가 완료되면, Connection이 해제되고, 다시 Advertising Packet을 보낸다. 이를 그림으로 표현하면 아래와 같다.그림6. Advertising Packet Type7. Ubertooth디바이스간 BLE를 이용한 통신 과정에 대해 알고나니, Bluetooth Signal Packet도 Capturing 할 수 있을 거라는 생각이 들었다. 검색을 해 본 결과, 오픈소스 Bluetooth Test tool인 Ubertooth라는 장치로 디바이스간의 BLE 통신을 tracking 할 수 있다는 사실을 알게 되었다. 가격은 100달러로 생각보다 저렴했지만 국내에서는 구매할 수가 없었다. 그렇다고 궁금한 것을 해보지도 않고 포기하는 것은 엔지니어의 마인드가 아니지 않겠는가. 직접 아마존 (www.amazon.com)에서 해외구매를 하였다. 이렇게 바다 건너 멀리서 날아온 Ubertooth를 사용했던 경험을 바탕으로, Ubertooth의 원리와 BLE 통신에 대해서 조금 더 자세히 설명을 해보고자 한다.Ubertooth는 10cm정도의 몸체와 그와 비슷한 길이의 안테나를 가지고 있는 매우 작고 귀여운 모양이다. 이것이 이름하여 Ubertooth!그림8. Ubertooth오픈소스이기 때문에 모든 소스가 공개되어 있고, 소스를 빌드하고 사용하는 방법도 Ubertooth Github 및 Ubertooth Blog에 잘 나와 있어서 사용하기가 수월했다.How it works?Ubertooth는 크게 Bluetooth Classic을 tracking하는 기능과 BLE를 tracking하는 기능으로 나뉘는데, 여기서는 BLE 통신을 tracking 하는 원리에 대해서 다루겠다.BLE는 앞에서 언급했다시피, Connection 전, 후로 통신하는 방법이 다르다. 그리고 위의 내용들을 꼼꼼히 읽은 독자라면 BLE 통신에서 가장 중요하다고 언급했던 timing 이라는 것을 기억할 것이다. timing 은 BLE 통신에서 굉장히 중요한 요소이기 때문에, 보다 더 자세하고 쉽게 설명을 해보겠다.종이컵 전화기를 사용하여 대화를 해야하는 두 사람이 있다. 종이컵 전화기는 총 40개가 놓여져 있다. 이 두 사람은 40개 전화기 중 하나를 사용해서 대화를 주고 받고, 일정시간 뒤에 다음번 전화기를 이용해야 한다. 이러한 커뮤니케이션 방식에서 소통을 하기 위해서는 한 전화기로 얼마만큼의 시간동안 통화를 할 것인지, 다음 전화기는 어떤 전화기를 사용할 것인지, 그리고 어떤 방식으로 자신들의 대화를 다른 사람들의 대화들로부터 구분할 것인지 등에 대해 알아야 할 것이다. 이것들이 위에서 말했던 timing 관련 정보이다.실제 BLE 통신에서 timing 과 관련된 정보들은 다음과 같다 : Access Adress, CRC Info, Hop Interval, Hop Increment (해당 내용들에 대한 자세한 설명은 여기를 참고하기 바란다). BLE 통신을 하는 디바이스들은 이 timing 관련 정보를 동기화하여, Connection이 맺어진 이후에 해당 규칙에 따라 Channel을 hopping하면서 데이터를 주고 받는다. Ubertooth는 바로 이 정보를 알아내어, Master, Slave와 같은 패턴으로 Channel을 hopping하면서 대화를 엿듣는다. 아까 말한 종이컵 전화기에 빗대어 말하면, 제 3자(Ubertooth)가 두 사람이 정한 대화 규칙을 알아내서, 매번 이들이 전화기를 바꿔가며 대화를 할 때 마다 해당 전화기의 대화 내용을 엿듣는 것이다. 굉장히 흥미로운 방법이 아닐 수 없다. 그렇다면 Ubertooth는 어떻게 이 정보를 알아낼까?Before Connection두 디바이스가 연결되기 전, Ubertooth가 timing 관련 정보를 알아내는 방법은 매우 간단하다. Scanner가 Advertiser에게 Connection을 맺기위해 보냈던 CONNECT_REQ을 기억하는가? 공교롭게도 해당 패킷에는 이 네 가지 정보가 전부 들어있다. Ubertooth는 그 정보를 추출해내어 저장해 두고, 그 규칙에 맞게 Channel을 hopping하면서 Signal Data를 전부 엿듣는다.그림9. Ubertooth로 Capture한 CONNECT_REQ packetAfter Connection이미 연결된 디바이스들은 CONNECT_REQ를 보낼 일이 없다. 그러면 Ubertooth는 Connection 이후의 상황에 대해서는 Signal Data를 엿듣지 못하는 것일까? 아니다. Connection 이후의 상황에 대해서 Ubertooth는 다음과 같은 방법을 이용한다.BLE Signal Packet은 Advertise Mode이든 Connection Mode이든간에 무조건 하나의 Signal Packet format만 존재하기 때문에, Packet마다 특정 정보가 존재하는 부분은 어느 Packet에서나 똑같다. 4가지 정보 중 Access Address라는 것은 모든 Signal Packet마다 존재한다. Access Address라는 것은 두 디바이스간의 Unique한 Connection을 나타내는 4bytes 크기의 Identifier로써, CONNECT_REQ를 보내는 디바이스에 의해 랜덤하게 생성된다. Ubertooth는 37개의 Data Channel을 hopping하면서 모든 Data Packet의 Access Address를 추출해내어 Look Up Table 형태로 저장해 놓는다. 그리고는 각각의 Access Address가 등장한 횟수를 세게 되는데, 가장 먼저 특정 횟수만큼 등장한 Access Address를 target으로 잡는다. 나머지 3가지 정보는 각각 추출해내는 방법 및 알고리즘이 따로 존재하는데 해당 내용도 위에 언급한 사이트에 잘 나와있다. 이렇게 해서 네 가지 정보를 알아낸 Ubertooth는 두 디바이스와 같은 패턴으로 Channel을 hopping하면서 Signal Data를 엿듣는다.그림10. Ubertooth로 Capture한 Aceess Address과 나머지 3가지 정보들이렇게 보면, Ubertooth로 모든 것을 할 수 있을 것처럼 보이지만, 몇 가지 한계점이 있기도 하다. Ubertooth가 timing 관련 정보를 얻어내는 과정에 대해 다시 한 번 생각해보길 바란다. 잘 모르겠다면, 직접 Ubertooth 구매하여 테스트를 해보는 것도 엔지니어로써 굉장히 좋은 경험이 될 것이다.8. ConclusionBLE 통신과 이를 tracking하는 Ubertooth에 대해서 알아보았다. 매우 장황한 내용처럼 보이지만 이것도 매우 압축해서 설명한 것이다. 하나하나 디테일하게 쓰기 보다는 BLE를 처음 접하는 사람이 최대한 이해하기 쉽도록 작성하는 것에 초점을 맞추었다. 위의 내용들을 바탕으로, 독자들이 BLE에 더 넒고 깊은 지식을 얻게 되었으면 하는 바램이다. 글을 읽으면서 Bluetooth Classic은 어떻게 통신하는지에 대해 궁금하신 분들도 있을거라 생각한다. 이에 대해서 간단히 언급하자면, Bluetooth Classic 통신 방식은 BLE보다 훨씬 더 복잡하다. BLE에 대해서 어느 정도 알게 되었다면, Bluetooth Classic에 도전해보는 것도 괜찮을 것이다. BLE내용과 관련해서 보충이 필요한 내용이나, 관련 경험 혹은 궁금한 점 등에 대해서 아낌없이 조이와 공유해주길 바란다.9. ReferenceAkiba, “Getting Started with Bluetooth Low Energy: Tools and Techniques for Low-Power Networking”, O’Reilly Media(2015)http://www.slideshare.net/steveyoon77/bluetooth-le-controllerhttp://www.hardcopyworld.com/ngine/aduino/index.php/archives/1132https://www.bluetooth.org/ko-kr/bluetooth-brand/smart-marks-faqshttp://trvoid.blogspot.kr/2013/05/ble.htmlhttp://blog.lacklustre.net/posts/BLEFunWithUbertooth:SniffingBluetoothSmartandCrackingItsCrypto/#조이코퍼레이션 #개발팀 #개발자 #개발환경 #업무환경 #인사이트 #경험공유

Overview브랜디는 현재 2.0 기반 Android 버전입니다. Main Thread와 Sub Thread 사이의 ANR를 방지하려고 Volley, Otto Bus Library를 사용해서 백엔드 서비스(back-end Service)를 연동하고 있습니다. 이제 3.0 개발로 더 좋은 백엔드 서비스 기능을 만들려고 합니다. (기반 작업은 이미 완료했습니다.) 다만 3년 동안 브랜디 앱을 개발하면서 느꼈던 고통과 피로를 ‘제발’ 줄여보고 싶어서 브랜디 3.0에서는 Retrofit2 와 RxJava, Lambda 표현식을 사용하기로 했습니다. RxJava(Reactive programming)는 가장 추천하고 싶은 것 중 하나입니다. 우리는 함수형 리액티브(반응형) 프로그램이라는 표현으로 자주 마주치곤 하는데요. 주로 옵저버 패턴(Observer pattern)을 대체하기 위해 사용합니다. 단순히 데이터를 넘기고 마무리하는 건 옵저버 패턴으로도 충분하지만 대부분의 문제는 이벤트들을 묶어서 사용할 때 생깁니다.1) RxJava는 이벤트에 대한 조건 처리나 실패 처리, 리소스 정리에 대비해 사용합니다. 기존 방식의 명령형 리액티브 접근 방식을 사용하면 복잡함이 지속적으로 증가하는 반면, 함수형 리액티브 프로그래밍은 효율을 크게 높일 수 있습니다. 몇 가지 예제와 함께 살펴보겠습니다. Android에 직접 사용해보기새로운 프로젝트를 생성한 후, 아래와 같이 build.gradle 파일을 수정해봅시다. (JDK 1.8 설치 필수) apply plugin: 'com.android.application' android {    compileSdkVersion 26   defaultConfig {        applicationId "kr.co.brandi.myapplication"        minSdkVersion 21        targetSdkVersion 26        versionCode 1        versionName "1.0"        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"    }    buildTypes {        release {            minifyEnabled false            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'        }    }   //추가된 부분 1      compileOptions {        sourceCompatibility JavaVersion.VERSION_1_8        targetCompatibility JavaVersion.VERSION_1_8   }  } dependencies {    implementation fileTree(dir: 'libs', include: ['*.jar'])       //추가된 부분2    implementation 'io.reactivex.rxjava2:rxandroid:2.0.1'    implementation 'io.reactivex.rxjava2:rxjava:2.1.3'      implementation 'com.android.support:appcompat-v7:26.1.0'    implementation 'com.android.support.constraint:constraint-layout:1.0.2'    implementation 'com.android.support:design:26.1.0'    testImplementation 'junit:junit:4.12'    androidTestImplementation 'com.android.support.test:runner:1.0.1'    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1' } 이제 람다 표현식과 RxJava를 사용할 준비가 되었습니다.Flowable.just("Hello World").subscribe(new Consumer() {    @Override   public void accept(String s) throws Exception {        Log.v(tag, s);   }  });   Flowable.just("Hello World !").subscribe(s -> Log.v(tag, s)); 간단한 생성자와 결과를 출력하는 부분입니다. 두 번째 subscribe는 람다 표현식으로 인터페이스를 생성하지 않더라도 첫 부분과 동일하게 결과물을 얻을 수 있습니다.2) 이제 RxJava에서 간단한 필터링으로 간편하게 데이터를 가공하는 능력을 확인해보겠습니다. 아래 코드는 기본적인 List 의 값을 출력하는 부분입니다.List valueList = Arrays.asList(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10);   for (int data : valueList) {    String result = "value " + data;    Log.v(tag, result);  } Flowable.fromIterable(valueList)        .map(new Function() {            @Override            public String apply(Integer data) throws Exception {                return "value : " + data;            }        })        //.map(data -> "value : " + data)        .subscribe(data -> Log.v(tag, data)); 위의 코드에 조건을 추가해 ’짝수’만 출력하겠습니다.for (int data : valueList) {    if ((data % 2) == 0) {        String result = "value " + data;        Log.v(tag, result);    }  } Flowable.fromIterable(valueList)        //.filter(data -> {        //      return (data % 2) == 0;        //})        .filter(data -> (data % 2) == 0)        .map(data -> "value : " + data)        .subscribe(data -> Log.v(tag, data)); 위와 같이 데이터 가공은 순차적으로 진행되고, 여러 함수로 간단하게 처리할 수 있습니다. 원하는 데이터 가공을 위해 filter, map 등의 함수들을 순차적으로 이어 붙일 수도 있습니다.위에서 보여드린 RxJava는 간단한 예시이기 때문에 RxJava 의 기능을 좀 더 보여드리겠습니다.String[] data1 = {Shape.HEXAGON, Shape.OCTAGON, Shape.RECTANGLE};  String[] data2 = {Shape.TRIANGLE, Shape.DIAMOND, Shape.PENTAGON};   Flowable source =        Flowable.combineLatest(                Flowable.fromArray(data1)                        .zipWith(Flowable.interval(100L, TimeUnit.MILLISECONDS), (shape, notUsed) -> Shape.getId(shape)),                Flowable.fromArray(data2)                        .zipWith(Flowable.interval(150L, 200L, TimeUnit.MILLISECONDS), (shape, notUsed) -> Shape.getSuffix(shape)),                (id, suffix) -> id + suffix);   source.subscribe(s -> Log.d(getThreadName(), s)); CombineLatest() 함수를 이용해 두 개의 스트림을 하나로 처리하는 방법을 보여 드렸습니다. 각각의 스트림은 interval 함수를 시간 간격으로 data1과 data2 배열의 개수만큼 반복하여 처리하는 로직입니다. 서로 다른 두 스트림은 마지막 데이터를 가지고 있으며 새로운 데이터가 나올 때마다 하나의 스트림으로 출력됩니다.마블 다이어그램 3)결과Conclusion만약 RxJava를 이용하지 않고 두 개의 TimerTask를 이용해서 코딩했다면 결과는 같았을지도 모릅니다. 이제 RxJava를 알기 때문에 다시는 TimerTask를 이용해서 코딩할 일은 없을 겁니다. 알면 알수록 다양한 기능을 갖추고 있는 RxJava! 이제 브랜디 상용화 버전에 사용할 수 있게 다시 개발의 숲으로 들어가겠습니다. 그럼 이만. 1)함수나 네트워크 호출의 비동기 응답 2)Java 8 람다 표현식 자세히 살펴보기, 2018.03.09. 3)RxJava on Android 글고재성 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

스푼을 만드는 사람들 여덟 번째 이야기마이쿤의 초창기 멤버 중 한 명인 'Charles' 를 인터뷰해보았다.그래서, 영어 유치원은 보내셨나요?https://brunch.co.kr/@mirr5510/17내가(Sunny) 처음 마이쿤에 입사하게 된 계기는 바로 Neil(대표)의 브런치 글과 마이쿤 관련 인터넷 기사를 읽고 나서였다. 많은 글 둘 중에 가장 궁금하고 특이하다고 생각했던 글이 바로 '영어 유치원' 보내자 였다.영어 유치원 보내자? 무슨 말이지? 하고 클릭해서 읽어보았다. 스푼 라디오라는 서비스 전 '만땅'이라는 배터리 공유 서비스를 시작할 때 첫 팀 빌딩에 관한 이야기였다. 닐의 주변 지인, 학교 후배들에게 함께 서비스를 만들자고 제안했을 때 유부남 팀원들에게 이렇게 말씀하셨다고 한다."우리, 아이들 영어 유치원 보내자"즉, 그만큼 잘하자. 우리 같이해서 성공하자라는 의미로 이렇게 말씀을 하신 것 같다. 그래서 찰스를 인터뷰할 때 가장 먼저 물어본 질문이었다. 그래서 아이들 영어 유치원은 보내셨는지 말이다.찰스 특징: 모자 좋아함"하하하.. 이미 저희 아이들은 많이 커서 유치원은 벌써 졸업했어요. 이제 테드랑 빅터의 차례가 아닐까 싶네요"찰스가 가장 좋아하는 맥주 'Charles' 당신이 궁금합니다.Q. 본인을 한 마디로 표현한다면?'동네형 또는 오빠' 저는 어색한 걸 싫어하고, 친화력이 좋은 편이기도 하고요. 사람들과의 편한 관계를 좋아해요. 그래서 먼저 보통 말을 먼저 잘 거는 편이에요"Q. 찰스도 혹시 딸 바보세요?"네, 저는 딸 바보예요. 아빠들은 딸 바보가 된다는 건 사실인가 봐요. 딸은 일단 아들과는 정말 달라요. 되게 예쁘고요.. 되게 애교가 많고요..(이때 눈이 반짝반짝하셨습니다) 아들은 보통 엄마를 찾던데, 딸은 항상 아빠를 찾더라고요. 아! 그리고 자다가도 아빠 들어오는 소리 들리면 나와서 뽀뽀해주고 다시 자러 가요. 6살인데 아빠한테 잔소리도 하고요. 마지막으로 하나만 더 자랑해도 돼요? 오늘 5일 만에 딸 얼굴을 봤는데 (안 자고 있을 때) 아빠가 엄~청 보고 싶었다면서 일주일치 뽀뽀를 엄청 많이 해줬답니다.. 이래서 다들 딸 바보가 되나 봐요."Q. 밀가루를 정말 좋아하신다고 들었습니다 feat. 코젤 다크"제 생각에 저는 탄수화물 중독자인 것 같습니다. 탄수화물을 정말 좋아해요. 특히나 칼국수를 정말 좋아하는데요. 맑은 거 말고 찐한 국물의 칼국수 있잖아요. 그거 너무 맛있어요. 제가 추천하고 싶은 칼국수집은, 논현동 영동시장에 있는 이름이 기억이 안 나는데.. 거기 진짜 칼국수 진짜 맛있습니다."P.S: 테드가 옆에서 조용히 슬랙으로 보내주셨습니다. 바로 이 칼국수 집이라네요. '손국시' https://m.blog.naver.com/PostView.nhn?blogId=rldudal0070&logNo=220165610372&proxyReferer=https://www.google.com/당신의 회사생활이 궁금합니다Q. 마이쿤의 초장기 멤버가 되신 계기를 더 알고 싶어요"저는 마이쿤에 입사하게 된 계기가 제 인생에서 가장 큰 결정이었어요. 저는 이 전 회사에서 9년 4개월 정도 근무를 했었어요. 그러던 어느 날 Neil이 회사에 놀러 오라고 하더라고요? 그래서 놀러 갔더니 보니까 이미 Yong 도 함께 일하고 있었고, 갑자기 닐이 사업 기획서를 보여주는 거예요. 이런저런 이야기 함께 나누다가 함께 일을 하자고 제안을 하더라고요. 정말 고민 많았어요. 마침 그때 제가 이직을 생각할 때였거든요. 그렇게 고민하고 와이프와 함께 의논을 했는데 고맙게도 와이프가 저를 믿어주고 응원해주었어요. 그리고 이런 생각을 했어요. "어차피 이직할 거라면 한 번 밑바닥에서 도전해보자!" 그리고 제 손으로 서비스를 함께 만들 수 있다는 것이 가장 큰 메리트이었고요. 드디어 내가 원하는 일을 하게 되었구나 생각했었죠. 무엇보다 서비스가 잘되면 우리 아이들에게 더 나은 미래와 경험을 줄 수 있다고 믿었고요. 무엇보다 잘 되지 않아도 살아가면서 나에게 정말 좋은 경험으로 남아 미래에 발판이 될 것이라고 생각했어요. 그렇게 저는 마이쿤의 초창기 멤버가 되었어요. 무엇보다 서비스에 대한 아이디어와 매력도가 높다고 느꼈고, 닐이 "영어 유치원 보내자!"라는 말에 혹했죠"Q. 첫 서비스를 실패했을 때 떠나지 않고 남았던 이유는?"제가 처음에 입사를 하자마자 와이프가 둘째를 임신한 걸 알게 되었어요. 근데 정말 너무 바빠서 집에도 못 들어가고 일을 했었어요. 가장으로서 남편으로서도 잘하고 싶었고, 일도 잘하고 싶었는데 마음처럼 쉽지가 않더라고요. 경제적으로 힘든 부분도 있었지만, 저는 이대로 이 팀이 헤어지기엔 너무나도 아쉬워서 남는 선택을 했어요. 저희 정말 열심히 했거든요. 진짜 정말 열심히 했는데 이대로 서비스가 잘 되지 않았다는 게 아쉬웠고, 이 일로 이 팀이 해체되는 게 너무 싫었어요. 그때 우리는 모두 정말 열심히 했지만 잘하진 못했었어요. 어떻게 가야 하는지 방향도 몰랐어요. 그래서 더욱 아쉬웠죠. 팀이 해체된다 할지 언정 후회 없이 헤어지고 싶었어요. 근데 저뿐만 아니라, 모든 사람들이 동의를 했어요. 우리 이번엔 열심히 하지 말고 '잘' 하자라고. 그리고 저는 외벌이에 유부남이라 팀원들이 저를 많이 배려해줬었죠. 와이프에게 가장 고마운 점이 그때 와이프가 그랬어요. "떠날 때 떠나더라도 후회 없이 해"이 말이 정말 큰 힘이 됐던 것 같아요. 와이프에게 많이 미안하고 고맙습니다."Q. 6년 동안 함께 해올 수 있었던 원동력은?"저는 정말로 솔직하게 여태 마이쿤에서 다른 곳으로 이직을 해야겠다는 생각을 해본 적이 없어요. 첫 번째 서비스가 망하고도 자발적으로 남은 이유도 이 팀과 함께 후회 없이 가고 싶다는 마음 때문이었어요. 저는 아직도 제가 성장하고 많이 배우고 있고, 배워야 한다고 생각하거든요. 어떠한 사람들과 일하느냐가 정말 중요한 것 같아요. 무엇보다 함께 시작하여 함께 실패하고 또다시 함께 일어났다는 점과 성장했다는 점이 기쁘고 뿌듯하고 더 큰 책임감을 느끼게 해 주거든요. 하지만 언젠가 제가 회사에 도움이 되지 않는 날이 온다면 그때는 스스로 떠날 생각입니다 (웃음)"Q. 리더로서의 삶은 어떤가요?"팀에 동료가 많아지게 되고 각각 다른 성격의 동료들이 생겨났어요. 각자 다들 일을 열심하 하고 잘하지만 팀으로서 하나가 되어 한 마음으로 커 나가는 건 다른 문제라고 생각해요. 각자의 개성을 살릴 수 있는 방법이 있을까? 내가 어떻게 하면 좋은 리더가 되어 후배들을 이끌어 줄 수 있을까? 하고 고민도 많이 해보고, 함께 이야기도 해보기도 하고요. 진심을 담아서 늘 말을 해요. 제 진심이 닿아야 팀원들도 저를 더 잘 따라 줄 테니까요. 면담을 통해서 불편한 것들을 해소해주려고도 노력하고 무엇보다 저도 그 들에게 많이 배우고 있어요. 아무리 신입이라도 해도 제가 생각하지 못한 부분을 배울 수 있거든요. 각자 살아온 환경과 경험이 다르고 본인이 잘하는 것들은 다 제 각각 다르니까요. 그래서 많이 노력하고 배우려는 리더가 되려고 노력 중입니다."Q. 새로운 서비스가 성장하면서 변한 게 있다면?Sunny 曰: "지난 만 5년 동안 마이쿤의 실패 그리고 재 도전 및 성장 과정을 모두 봐오셨잖아요. 뭐가 가장 많이 달라졌을까요? 정말 많은 것들이 변했겠지만요."Charles 曰: "저는 일단 스푼이라는 서비스가 성장하면서 좋아진 점이 정말 많아진 것 같아요. 그중 가장 큰 건 회사에 점점 더 전문적이고 실력 있는 분들이 입사하셨다는 겁니다. 물론 분위기는 예전하고 같을 수 없겠지요. 그때와 지금의 인원 차가 크니까요.분위기나 문화를 그때가 똑같이 유지를 한다는 건 불가능하다고 생각해요. 서비스의 규모에 맞게 함께 성장해 나가야 하니까요. 다양한 사람과 다양한 시선으로 보고 느껴야 회사 서비스가 더 성장할 수 있거든요. 그리고 서비스가 성장해야 우리 모두에게 좋은 일인 것이고요. 새로 입사하신 분들은 굉장히 능력자가 많으세요. 그분들에게 많이 배우려고 하고 있고 있고요"찰스가 좋아하는 진라면 + 파송송 + 계란탁 당신의 사생활이 궁금합니다Q. 좋은 아빠란 어떤 아빠라고 생각하세요?"내가 생각하는 좋은 아빠란?처음에는 애들과 재미있게 잘 놀아주면 그것만으로도 좋은 아빠라고 생각을 했었어요. 알고 보니 그것만으로는 부족하더라고요. 잘 놀아주는 것은 기본이고, 아이의 시선에서 세상을 바라봐 주고, 아이와 눈높이를 맞춰 주는 자세를 가져야 하고 제일 중요한 것은 아이의 마음을 공감해줘야 한다고 생각합니다. 이렇게 해야 정말 좋은 아빠가 아닐까?라고 생각합니다. 잘 놀아주는 것은 누구보다 잘한다고 생각합니다만 아직까지도 아이의 마음을 공감해주는 부분에서는  많이 부족합니다. 저도 모르게 아이를 혼내고, 반성하고 이 패턴이 반복이에요. 한때는 뱃속에 있을 때는 건강하기만을 원했는데, 막상 세상에 나와보니 어쩔 수 없나 봅니다."Q. 자녀분들이 개발자를 꿈꾼다면 추천하시나요?“개발자는 굉장히 매력적인 직업입니다.누구나 개발자가 될 수 있고, 즐길 수 있는 지금의 문화라면 저는 아이들에게 개발자가 되는 것을 추천해주고 싶어요. 성취감이라는 걸 얻을 수 있는 직업이기에, 그런 걸 느껴보게 해주고 싶기도 하고요.나의 재능으로 나를 포함한 누군가의 삶이 달라질 수 있는 경험은 좋은 경험이라고 생각해요. 무엇보다 개발자는 스스로 만들고 싶어 하는 욕구가 있는데요. 내가 개발한 서비스나 상품을 누군가가 사용하고 좋은 피드백을 준다면 정말 보람찬 일이거든요. 물론 부정적인 피드백을 받으면 상실감을 느낄 수도 있지만, 그 과정에서 또 성장해나갈 수 있기 때문에!”Q. 나중에 개발해 보고 싶은 서비스가 있나요?"있어요. 라면 서비스요. 저는 라면을 정말 좋아하거든요, 라면 중에서도 진라면을 가장 좋아하는데 진라면에 파 넣고 마늘 넣고 콩나물 넣고! 끓여먹으면 전 일주일 내내 먹을 수 있습니다. 그래서 '우리 함께라면'이라는 라면 서비스를 해보고 싶어요. 라면에 특화된 서비스죠. 제가 그래서 예전에 회사에서 사람들 한 명 한 명한테 혹시 라면 일주일 내내 먹을 수 있냐고 물어보기도 했었어요."Q. 만약 개발을 하지 않았더라면 지금 뭐하시고 계셨을 거 같으세요?"글쎄요. 저는 원래 사실 개발자가 되려던 마음은 없었어요. 군대 제대하고 우연히 한 번 해볼까? 했는데 시작하게 되어 업이 되었네요. 저는 아마 개발자가 아니라면 지금 공무원? 하지 않았을까 싶어요. 원래 저의 옛날 성향은 뭔가 모나지 않고, 평범한 사람이었거든요. 이렇게 큰 도전을 하기 전까지는요"당신이 마이쿤에서 우리와 함께 일해야 하는 이유는요저희는 정말 많은 실패와 역경을 거쳐왔고, 쓰러질 때마다 '함께' 일어났습니다. 이제서야말로 정말 본격적으로 성장하기 위해 달려야 하는 시점이에요.  해야 할 것도 정말 많고요. 회사와 서비스가 성장하는 경험을 할 수 있다는 것은 어디서 돈 주고도 못할 경험이라고 생각합니다. 지금 이 기회에 저희와 같은 배를 타신다면, 개개인이 노력한 만큼 서비스 성장에 기여하실 수 있고 본인 스스로도 성장하는데 많은 도움이 될 것이라고 생각해요. 이미 성장한 곳에서 경험을 하는 것도 분명 가치 있는 일이지만, 나 스스로가 성장에 기여할 수 있는 회사의 구성원이 될 수 있는 건 흔한 일이 아니라고 생각합니다.서비스 플랫폼 팀원들이 Charles를 한마디로 표현한다면?Kyu 曰:  '동네형' - 사실은 동네 아저씨에 더 가깝지만 마치 동네 형인 듯 다가와주는 사람.Sam 曰:  '장군님' - 어디서 자꾸 전리품(티셔츠, 스티커 등 )을 가지고 오신다.P.S 저희 어머님께서 NewRelic 티셔츠 편하다고 너무 좋아하십니다.Mark 曰:  '언니' - 가끔 삐지시는 거 같지만 언제나 잘 챙겨준다.

[맛있는 인터뷰 1] 잔디의 든든한 리베로, 백엔드(Back-end) 개발자 John을 만나다                                    잔디의 든든한 수문장, John         스타트업(Startup)의 경우, 구성원들과 회사가 그 운명을 같이하는 것 같다.         개개인의 발전이 곧 회사의 발전으로 이루어지기 때문이다.           – John Kang, 잔디 개발팀편집자 주: 잔디에는 현재 40명 가까운 구성원들이 일본, 대만, 한국 오피스에서 일하고 있습니다. 국적, 학력, 경험이 모두 다른 멤버들. 이들이 어떤 스토리를 갖고 잔디에 합류했는지, 잔디에서 무슨 일을하고 있는지 궁금해 하시는 분들이 많았습니다. 이에 잔디 블로그에서는 매주 1회 ‘맛있는 인터뷰’라는 인터뷰 시리즈로 기업용 사내 메신저 ‘잔디’를 만드는 사람들의 이야기를 다루고자 합니다. 인터뷰는 매주 선정된 인터뷰어와 인터뷰이가 1시간 동안 점심을 함께 하며 다양한 이야기를 나누며 진행됩니다. 인터뷰이에 대해 궁금한 점은 댓글 혹은 이메일([email protected])을 통해 문의 부탁드립니다.안녕하세요, John! 맛있는 인터뷰의 첫 대상자가 되셨어요. 오늘 저희가 먹을 ‘맛있는 메뉴’는 무엇인지 설명해주세요.– 생선구이 어떠세요? 고등어와 연어 요리가 맛있는 집이 국기원 쪽에 있는데요. 비즈니스 팀의 YJ가 버디런치*때 데리고 갔던 곳인데 테이스티로드에도 나오고 꽤 맛있어요.*버디런치(Buddy Lunch): 잔디에서는 매주 금요일 점심 제비뽑기를 통해 짝을 지어 점심을 먹는 버디런치를 실행 중이다                                맛있는 인터뷰 시작 전, 인증샷 한장~!자기소개 부탁드려요.– 잔디의 백엔드(Back-end)를 맡고 있는 John입니다. 잔디에 합류한 건 반년쯤 된 것 같네요. 2014년 9월에 합류했어요. 남중-남고-공대-군대-IT회사까지 소위 ‘솔로계의 엘리트 코스’를 밟고 있는 개발자입니다. 고향은 대구이구요, 서울말을 제 2외국어로 사용하고 있습니다. 회사에서는 서울말을 하고 있지만 고향 친구들을 만나면 자동으로 사투리가 나옵니다. (하하)잔디에는 어떻게 합류하시게 됐는지?– Justin(CTO)과 YB(COO)와 함께 패스트트랙에서 창업 관련 수업을 들었어요. 그때 Justin이 농담처럼 나중에 함께 일하자 했는데 정말 이렇게 부를 줄 몰랐네요.잔디의 어떤 점에 이끌리셨나요?– 잔디라는 서비스도 매력적이었고, 함께 일할 사람들도 매력적이었어요. 개발하면서 직접 만들어보면 재미있겠다고 생각을 한 것이 있었는데 잔디가 바로 그런 서비스였어요. 게다가 함께 일할 사람들이 너무 좋았어요. 프로덕트 아이디어도 중요하지만 함께 일할 동료도 정말 중요하다고 생각해요.  몇 년 전 사업을 구상했던 적이 있는데 아이템에 대한 이견차이로 결국 무산되었던 경험이 있어요. 그 당시 연애하다 헤어진 것과 맞먹는 상실을 겪었는데요. 이런 경험이 있다 보니 뜻이 맞는 동료들이 중요하구나를 뼈저리게 느꼈어요.잔디에서의 역할이 백엔드라 하셨는데 조금 더 자세히 설명해 주실래요?– 용어가 어렵죠? 제가 하는 백엔드 업무는 사용자가 직접 눈으로 보거나 경험하는 부분이 아닌 그 뒤의 처리 과정을 담당하는 일이에요.눈에 보이지 않는 부분이요?– 쉽게 말하면 잔디를 통해 메세지를 보내면 그게 끝이 아니거든요. 메세지를 서버에 저장하고 처리해서 받는 사람에게 잘 전달되도록 해야 해요 그걸 가능하게 만드는 거죠. 잔디에선 MK와 함께 일을 하고 있어요. 업무 특성상, 안드로이드 개발자, 아이폰 개발자와도 함께 일하고 있죠.성과가 눈에 잘 보이지 않는 업무인 것 같아요.– 사실 프론트엔드(Front-end)에 비해 그런 편이죠. 백엔드와 프론트엔드 업무를 모두 해봤는데 각기 장단점이 있어요. 백엔드는 성과가 잘 안 보이는 반면 프론트엔드는 누구나 오류를 지적 할 수 있거든요.둘 다 경험이 있다고 하셨는데 어떤 쪽이 더 재미있으세요?– 어렵네요. 백엔드를 하다 지칠 땐 프론트엔드가 생각나고 프론트엔드 일을 하다 지칠 땐 백엔드가 생각나요. 지금은 백엔드에 만족하고 있어요.지금 하고 계신 업무를 좋아하시는 것 같단 생각이 드네요.– 그래 보여요? 사실 적성에 맞는 것 같아요. 모든 일이 그렇겠지만 프로그래밍은 꾸준히 발전하지 않으면 도태되기 십상이에요. 그러다 보니 계속해서 공부하게 되는 것 같아요. 저뿐만 아니라 잔디의 다른 개발자 분들도 꾸준히 공부를 하고 있고 스터디도 열심히 참여하고 있어요.바쁜 가운데 꾸준히 공부를 하신다니 인상적이네요.– Startup의 경우 구성원들과 회사가 그 운명을 같이하는 것 같아요. 개개인의 발전이 곧 회사의 발전으로 이루어지니까요. 그러니 열심히 할 수밖에 없죠.                                 오피스 근처 커피숍에서 커피 한잔!취미가 있으시다면?– 몸으로 하는 활동을 즐겨서 하고 있어요. 헬스, 조깅, 윈드서핑을 좋아해요. 한동안은 등산도 즐겨했지만 친구들이 하나둘 결혼하고 나니.. 점점 모임이 뜸해지더라고요. 일을 하면서 체력관리는 필수인 것 같아요. 어릴 땐 몰랐지만 체력관리를 하지 않으면 자기도 모르는 사이 배가 조금씩 조금씩 나오는 것 같아서..주로 혼자 하는 운동들이네요.– 정말 그렇네요? 앞으로 여유가 생긴다면 다이빙이나 서핑, 암벽 등반을 해보고 싶어요. 그리고 가능할진 모르겠지만 올해 안에 휴가를 내서 발리에 가서 서핑도 즐겨보고 싶고, 돈을 많이 벌면 레이싱도 해보고 싶어요.시간이 벌써 이렇게 됐네요. 끝으로 레이싱 얘기가 나와서 여쭤보는데 혹시 드림카가 있으신가요?– 페라리요. 잔디가 성공해야 드림카를 소유할 수 있겠죠?1시간 동안 진행된 ‘맛있는 인터뷰’를 통해 좀 더 자세히 알게된 John. 이번 인터뷰를 음식에 비유하자면 진하고 담백한 사골국 같았습니다. 개발자로서의 자부심과 일에 대한 애정이 남다른 John을 보며 조금이나마 개발팀을 머리에 그려볼 수 있었습니다. 앞으로 매 주 진행될 잔디 멤버들과의 다른 인터뷰들도 기대해주세요!#토스랩 #잔디 #JANDI #개발자 #백엔드 #개발팀 #팀원소개 #팀원인터뷰 #팀원자랑 #조직문화 #기업문화 #사내문화

Overview안녕하세요. 저는 브랜디 R&D 본부 개발1팀의 기둥을 담당하는 이상근입니다. 오늘은 SQS(Simple Queue Service)와 Lambda를 간단한 예제와 함께 정리해보려고 합니다. 각 서비스에 대한 설명은 이미 매뉴얼로 쉽게 정리되어 있으므로, 이번 글에서는 서비스 간 구성을 집중적으로 살펴보겠습니다.1)SQS와 Lambda에 대하여SQS(Simple Queue Service)는 마이크로 서비스와 분산 시스템, 그리고 서버리스 애플리케이션을 쉽게 분리하고 확장할 수 있는 ‘완전관리형 메시지 대기열 서비스’입니다. 그리고 Lambda는 ‘이벤트 처리 방식의 서버리스 컴퓨팅 서비스’입니다. 아래 그림은 SQS와 Lambda Function을 이용해 메시지를 등록-조회-처리하는데 필요한 구성요소를 정리한 것입니다. SQS, Lambda ArchitectureProducer - 처리할 작업 메시지를 SQS에 등록Trigger - 큐(Queue) 대기열에 있는 메시지들을 조회하기 위해 CloueWatch의 스케줄 이벤트를 이용하여 매 분마다 Lambda Consumer 실행Consumer - Lambda Consumer는 큐 대기열에 있는 메시지 목록을 조회하여 각 메시지를 Lambda Worker에서 처리할 수 있도록 실행Worker - Lambda Worker는 메시지를 받아 작업을 처리하고 해당 메시지를 삭제큐 생성하기이번에는 큐 생성에 대해 살펴보겠습니다. ‘Create New Queue’를 클릭했을 때 지역(Region)에 따라 각각 다른 화면이 노출됩니다. Create New Queue Button타입 선택 화면항목 입력 화면두 번째 이미지와 같이 SQS에서는 Standard, FIFO 두 가지 타입을 제공하고 있습니다. 표준 대기열은 순서에 맞지 않게 메시지가 전송될 수 있습니다. 만약 순서를 반드시 유지해야 한다면 FIFO 대기열을 사용하거나, 순서 정보를 추가하고 사용해야 합니다. 하지만 FIFO 대기열의 경우 현재 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오레곤) 및 EU(아일랜드) 지역(Region)이서만 제공되고 있기 때문에 다른 곳에서는 사용할 수 없습니다. 2) 3) 1.Create New Queue ‘Create New Queue’에는 여러 항목이 있습니다. 우선 아래를 참조하여 각 항목에 적절한 내용을 기재합니다. Default Visibility Timeout : 대기열에서 조회한 메시지가 중복 조회되지 않기 위한 시간Message Retention Period : 메시지 보관 기간Maximum Message Size : 메시지 최대 사이즈Delivery Delay : 신규 메시지 전달 지연 시간Receive Message Wait Time : 조회된 메시지가 없을 경우, 사용 가능한 메시지를 기다리는 long polling 시간 설정Dead Letter Queue Settings : 정상적으로 처리되지 못한 메시지를 보관하기 위하여 메시지 수신 최대 수를 지정, 지정한 수신을 초과할 경우 지정한 큐에 메시지 저장2.큐 등록 확인 기본 값으로 설정한 큐 등록을 확인합니다. Queue List3.SQS 메시지 등록 import boto3, json sqs_client = boto3.client(     service_name='sqs',     region_name='xxxxxx' ) SQS 메시지 등록  response = sqs_client.send_message(     QueueUrl='https://sqs.xxxxxx.amazonaws.com/xxxxxx/sqs-test-1',     MessageBody='메시지 내용' )   print(json.dumps(response))   {"MD5OfMessageBody": "xxxxxxx", "MessageId": "xxxxx-xxxx-xxxxxx", "ResponseMetadata": {"RequestId": "xxxxxxx", "HTTPStatusCode": 200, "HTTPHeaders": {"server": "Server", "date": "Fri, 09 Feb 2018 08:01:13 GMT", "content-type": "text/xml", "content-length": "378", "connection": "keep-alive", "x-amzn-requestid": "xxxxxxx"}, "RetryAttempts": 0}} 4.AWS Console 메시지 등록 확인 View MessageDetail Message5.조회와 실행 1)SQS 메시지를 조회합니다.2)LambdaWorker 함수를 실행하고 > InvocationType으로 동기, 비동기 등의 실행 유형을 설정합니다. import boto3, json   def handle(event, context):     queue_url = 'https://sqs.xxxxxx.amazonaws.com/xxxxxx/sqs-test-1' sqs_client = boto3.client(         service_name='sqs',         region_name='xxxxxx'     )      lambda_client = boto3.client(         service_name='lambda',         region_name='ap-northeast-1'     )      # SQS 메시지 조회     response = sqs_client.receive_message(         QueueUrl=queue_url,         MaxNumberOfMessages=10,         AttributeNames=[             'All'         ]     )      print(json.dumps(response))      # {"Messages": [{"MessageId": "xxxxx-xxxx-xxxxxx", "ReceiptHandle": "xxxxx-xxxx-xxxxxx", "MD5OfBody": "xxxxxxx", "Body": "\uba54\uc2dc\uc9c0 \ub0b4\uc6a9", "Attributes": {"SenderId": "xxxxxxx", "ApproximateFirstReceiveTimestamp": "1518163931724", "ApproximateReceiveCount": "1", "SentTimestamp": "1518163466941"}}], "ResponseMetadata": {"RequestId": "", "HTTPStatusCode": 200, "HTTPHeaders": {"server": "Server", "date": "Fri, 09 Feb 2018 08:12:11 GMT", "content-type": "text/xml", "content-length": "1195", "connection": "keep-alive", "x-amzn-requestid": "xxxxxxx"}, "RetryAttempts": 0}}      for message in response['Messages']:         payload = {'message': message, 'queueUrl': queue_url}          # Lambda Worker 함수 실행         lambda_client.invoke(             FunctionName='lambda_worker',             InvocationType='Event',             Payload=json.dumps(payload)         ) 6.Lambda Consumer 함수 등록 Execution role : SQS ReceiveMessage, Lambda InvokeFunction, CloudWatchLogs7.확인-실행-삭제 1) 이벤트로 넘어온 메시지 내용을 확인하고2) 메시지 프로세스를 실행한 후3) SQS 메시지를 삭제합니다. import boto3, json   def handle(event, context):     sqs_client = boto3.client(         service_name='sqs',         region_name='xxxxxx'     )      message_body = json.loads(event['message']['Body'])      queue_url = event['queueUrl']     receipt_handle = event['message']['ReceiptHandle']      ###############     # 큐 메시지 처리     ############### # SQS 메시지 삭제     sqs_client.delete_message(         QueueUrl=queue_url,         ReceiptHandle=receipt_handle     ) 8.Lambda Worker 함수 등록 Execution role : SQS DeleteMessage, CloudWatchLogs9.CloudWatch의 Event Rule 등록 Event RulesCreate Rule10.1분에 한 번씩 지정한 Lambda 함수를 실행하여 SQS 메시지 확인 참고)이것만은 꼭 알아두세요! 여러 대의 서버에 메시지 사본을 저장하기 때문에 가끔씩 메시지 사본을 받거나 삭제하는 중엔 저장 서버 중 하나를 사용할 수 없을 수도 있다고 합니다. 이 경우, 해당 문제가 발생하면 사용할 수 없는 서버의 메시지가 삭제되지 않아, 메시지를 다시 가져와야 하는 문제가 생길 수 있습니다. 그러므로 애플리케이션에서 동일 메시지를 두 번 이상 처리하는 것도 대비해야 합니다.Conclusion지금까지 AWS 환경에서 SQS, Lambda, CloudWatch EventRule을 이용한 메시지 대기열 등록과 처리에 대한 기본 예제들을 실행해봤습니다. AWS의 다른 서비스들과 같이 아주 간단한 방법으로 메시지 대기열을 이용할 수 있었습니다. 오늘 살펴본 방법들을 활용하면 동영상 트랜스 코딩 등의 작업을 비롯해 분산 애플리케이션 간의 데이터 처리에도 유용하게 사용할 수 있을 겁니다. ps.아마존 형님들의 IT 인프라를 이용하여 편하게 개발에만 집중합시다. 참고 1) 각 서비스 매뉴얼은 아래 페이지 링크 참조하면 된다.SQSLambdaboto3 2)2018년 2월 기준이다. 3)표준 대기열과 FIFO 대기열의 특징은 아래와 같으며 자세한 내용은 매뉴얼에 정리되어 있다. 표준 대기열 : 무제한 처리량, 최선 정렬FIFO 대기열 : 높은 처리량, 선입선출 전송 글이상근 팀장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

다양한 언어 기반으로 개발 환경을 구축하여 만들다보면, 소프트웨어 버전관리 해야할 일이 흔히 생기곤 한다. 특히, 종종 대격변이 있는 버전의 판올림으로인해 충돌이 나거나 심볼릭 링크가 유실되는 경우들이 간혹 있는데 이번에도 그런 케이스였다.최근 node.js 기반으로 다양한 프로젝트 (vue.js, react.js등)를 진행하다가 이것저것 환경을 만지고 고치다보니 결국 node.js 를 완전히 클린하게 삭제해야 할 일이 생겼다.아마 이 환경에 결정타를 먹인 것이 OSX 환경에서 El Capitan에서 작업하던 Node.js를 그대로 high sierra로 OSX를 판올림 하면서 퍼미션 권한의 문제가 생긴건지, 노드 패키지 관리나 npm이 정상적으로 동작하지 않으면서 개발환경을 재 설정 할 수 밖에 없게 되었는데, 그 과정에 기름을 부어버리듯 당시에 brew로 설치한 노드가 brew로 삭제가 되지 않는 문제가 발생해버렸다.결국 환경을 처음부터 재 설치 해야하는 과정을 겪어야했는데 기존에 설치된 다양한 패키지 모듈의 찌꺼기들이 남아서 한방에 클린 설치를 할 수 있는 방법이 없을까 싶어 구글링을 해본 결과 앞서서 수많은 시행착오를 겪은 선배님들의 아주 좋은 작업 방식이 있어서 아래에 방법을 공유해본다.요세미티에서 nodejs 정리하는 법 [1]Uninstall nodejs from OSX Yosemite# 첫번째:lsbom -f -l -s -pf /var/db/receipts/org.nodejs.pkg.bom | while read f; do  sudo rm /usr/local/${f}; donesudo rm -rf /usr/local/lib/node /usr/local/lib/node_modules /var/db/receipts/org.nodejs.*# 완전히 nodejs + npm 을 날려버리는 방법 :# /usr/local/lib 경로로 가서 node 와 관련된 노드 모듈을 전부 삭제cd /usr/local/libsudo rm -rf node*# /usr/local/include 경로로 가서 node 와 관련된 노드 모듈 전부 삭제cd /usr/local/includesudo rm -rf node*# 만약 brew 로 인스톨을 했다면 아래와 같은 방법으로 삭제도 가능함. (저는 아래는 brew자체가 망가졌었는지 판올림으로 인한 권한 문제인지 brew로는 삭제 불가능했음.)brew uninstall node# home 디렉토리나 local, lib, include등의 폴더와 관련된 모든 파일은 아래의 경로에 있으니 찾아 들어가서 삭제cd /usr/local/binsudo rm -rf /usr/local/bin/npmsudo rm -rf /usr/local/bin/nodels -las# 아마 혹시 모르니까 클린하게 아래의 명령어도 한번 돌려주자sudo rm -rf /usr/local/share/man/man1/node.1sudo rm -rf /usr/local/lib/dtrace/node.dsudo rm -rf ~/.npmhomebrew를 사용하는 유저들 중에 npm이 제대로 동작하지 않으면 아래와 같은 방법으로도 처방이 가능하다. [2]rm -rf /usr/local/lib/node_modulesbrew uninstall nodebrew install node --without-npmecho prefix=~/.npm-packages >> ~/.npmrccurl -L https://www.npmjs.com/install.sh | sh클린하게 설치를 끝나고 react-native를 컴파일하는 과정에서 깃에 관련된 오류가 발생한다면 아래의 방법을 사용해보자. [3]오류메세지 :xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun솔루션 :xcode-select --install엘케피탄에서 하이시에라로 osx를 업데이트 하면서 homebrew의 링크가 깨졌다면 아래의 방법으로 다시 붙여준다. [4]sudo chown -R "$USER":admin /usr/localsudo chown -R "$USER":admin /Library/Caches/Homebrewbrew link libpng참고 출처 :[1] : https://gist.github.com/TonyMtz/d75101d9bdf764c890ef[2] : https://stackoverflow.com/questions/32893412/command-line-tools-not-working-os-x-el-capitan-macos-sierra-macos-high-sierra[3] : https://stackoverflow.com/questions/39778607/error-running-react-native-app-from-terminal-ios[4] : https://github.com/mikepurvis/ros-install-osx/issues/28 #더팀스 #THETEAMS #풀스택개발자 #Node.js #백엔드 #인사이트 #꿀팁