안녕하세요, Hyper-X에서 AI Camera Picai를 개발 중인 Android 개발자, Trent 입니다. 저는 지난 5월 8일부터 5월 10일까지 JH 님, Evan 님과 함께 다녀온 Shoreline Amphitheatre 에서 열렸던 Google I/O 2018 에 대해서 전하려고 합니다. Google I/O는 Mountain View, California에서 매년 6월에 열리는 Developer Festival로서, Sundar Pichai의 Google Keynote를 시작으로 Google의 새로운 기술들과 프로덕트를 선보이는 Session들이 3일에 걸쳐 진행되었습니다. 놀라운 AI 기술의 발전이 돋보였던 올해의 행사였습니다.SessionsKeynoteSundar Pichai의 Keynote로 시작된 올해의 행사에선 AI 기술의 발전과 그 활용이 단연 돋보였습니다. Google Duplex 가 Keynote의 가장 큰 화제였는데요, Google Assistant가 직접 헤어샵이나 식당 같은 업체에 전화하여 예약을 수행해주는 기능입니다. ‘음…‘같은 소리들을 포함하며 매우 자연스럽게 종업원과 전화를 하는 모습을 보였는데요, 어려운 질문들도 척척 대답하는 모습이 놀라웠고, Google의 ML 기술에 놀라움을 금치 못했습니다.또한 Google의 독보적인 AI 기술은 Google의 기존 서비스들에도 큰 변화와 개선점들을 가져왔는데요, Gmail 의 Smart Compose 기능이 그 중 하나입니다. 이메일 작성 시 문장 전체를 AI가 autocorrect 해주는 기능인데요, 반복적인 이메일 업무를 획기적으로 줄일 수 있을 것으로 기대되었습니다. 역시 Google의 엄청난 양의 데이터를 통해 이뤄낸 기술로 보입니다. 그 외에도 Google News의 자동 뉴스 큐레이션 시스템, Google Lens를 활용한 Google Maps의 AR 기능 등으로 기존 서비스들에 큰 변화를 선도해가는 면모를 보였습니다.Android P는 Adaptive Battery, Adaptive Brightness, App Actions, App Slices 등의 새로운 AI 기반 기능들을 Android에 가져왔습니다. 배터리를 30% 절약하고, 밝기를 자동으로 조절해주며, 시간 및 행동에 따라 연관된 앱들을 추천해주는 등 전반적으로 Android가 매우 똑똑해지는 부분을 보여 줬습니다. 이런 직관적인 AI 를 활용한 API 를 활용하면, 앱 개발자가 효율적으로 자기 앱의 접근성을 높일 수 있을 것으로 보입니다.또한 Android P 는 소소한 UX 개선 점들과 더불어 스마트폰 중독 방지 기능들을 탑재했습니다. 서양에서는 과도한 스마트폰 사용이 많은 사회적 문제가 되고 있는데요, 이를 방지하기 위해 App들에서 보낸 시간을 트래킹하고, App 시간 제한을 스스로 설정한다던가, 핸드폰을 뒤집어서 중요한 연락처의 전화가 아니면 받지 않는 등의 기능을 탑재하였습니다.What’s new in AndroidAndroid App Bundle 이 소개되었습니다. 하나의 패키지를 Google Play에 업로드 함을 통해 Android 디바이스가 필요한 리소스만 다운받을 수 있게 해주는 시스템인데요, 이미 Twitter, LinkedIn 등의 어플리케이션에 적용되어 20% 가 넘는 APK 사이즈 개선을 이뤄냈다고 합니다. 저희 팀이 개발 중인 Picai에도 APK 사이즈 문제가 있는데, 이를 통해 해결 가능할 것이라 생각하고 큰 기대를 하는 중입니다. 차후 버전인 Android Studio 3.2 버전부터 지원합니다.Android Jetpack 이 소개되었습니다. Support Library, Architecture Components, KTX 등의 라이브러리를 통합한 모양새 인데요, 이와 함께 AndroidX 로의 패키지 명 변경이 이뤄지었습니다. 그 외에도 새로운 Navigation 라이브러리, WorkManager 라이브러리 등이 소개 되었습니다. Google의 새로운 Android 개발 Best Practice 제시라고 할 수 있겠습니다. Picai에서 이미 적극적으로 사용하던 기술들이라 큰 감흥은 없었는데요, Google이 직접 나서서 Android 개발자 에코시스템을 정리하려는 노력은 좋았습니다.또한 Kotlin의 전반적인 지원 확대와 다양한 라이브러리들에 대한 소식, Android Studio 의 많은 내부 변경 및 Energy Profiler, Google Assistant와 관련된 다양한 API 들 제공, Android P에 변경된 Background 카메라 및 마이크 권한 제한 및 ImageDecoder 등에 대한 뉴스 및 다양한 안드로이드 최적화에 관한 세션이 있었습니다. 특히 Android Testing 관련 세션이 매우 인상깊었는데요, 모든 Android 테스팅에 관련된 불편함을 해결해 줄걸로 기대했지만 아쉽게도 런칭이 아직 안됬는지, 컨퍼런스 밖에서는 자취를 찾을 수 없었습니다... And MoreFirebase ML Kit 및 TFLite(TensorFlow Lite) 에 대한 발표가 인상깊었습니다. 머신러닝에 대한 접근성을 높여 어떤 개발자라도 ML을 활용한 콘텐츠를 쉽게 만들게 할 수 있도록 노력하는 모습이 돋보였습니다. 컨퍼런스 후 팀원들과 함께 자세하게 검토를 해보았으며, 아직 여러가지 제약사항이 있어 적극적으로 쓰고 있진 않지만, 앞으로의 간편한 ML 활용에 대한 기대를 불러일으키는 세션들이었습니다.Google의 새로운 Cross-Platform Framework Flutter 에 대한 세션도 참가하였는데, 개발 난이도가 쉬워 보이고 좋은 애니메이션의 UI Component 들이 제공됨은 동의 함에도 기능 분리 적인 면에서 노력이 많이 필요하겠다는 생각이 들었습니다. Hyper-X의 여러 팀들에서 도입을 검토로 하고 있지만, 아직 실무에서 적용하기는 시기 상조로 보였습니다.Snapchat Camera API 에 대한 설명을 들었는데, 기기 및 유저 데이터 기반으로 두 버전의 Camera API 및 캡쳐 메커니즘을 전부 지원하는 백엔드를 세세히 설계한 부분이 매우 인상 깊었으며, 차후 Picai에 직접 적용해보고 싶다는 생각을 가지게 되었습니다. 특히 관련하여, Fragmentation이 심한 Android Camera의 Testing을 어떻게 진행하나 궁금하여 강연 후 연사에게 찾아가 여쭤보았는데요, 만족할 만한 수준의 대답은 아니었지만 향후 Picai를 개발 함에 있어 자신감을 가질 수 있게 하는 답변을 받았습니다.Office Hour개인적으로 Google I/O 참가하면서 기대했던 것은 Office Hour 인데요, Jake Wharton, Kotlin 개발팀, Flutter 팀, TFLite 팀 등을 직접 만나서 질문을 할 수 있었다는 것이 기대되었습니다. Kotlin 개발팀과 바람직한 Kotlin 코드 스타일(Effective Kotlin 유무) 및 Jetbrains가 지향하는 패러다임(FP vs OOP), Kotlin Native의 런칭 일정 및 Coroutine 후 추가 목표 피쳐 등에 대해 토의하였으며, Flutter 팀에게는 Dart 채택 이유와 Flutter가 적합한 어플리케이션 타입이 무엇이냐에 대해 물었고, TFLite 팀에게는 회사 동료의 ML에 관한 질문을 슬랙으로 전달하고 답변 받는 등 뜻깊은 시간을 보냈습니다. Google I/O TipsUber 사용법을 숙지하라Silicon Valley 답게 차를 렌트하지 않은 경우 Uber를 통해 대부분 이동하게 되는데, Shoreline Amphitheatre 근처에서는 주차가 금지되어서 특정한 Uber 존으로 이동하여 차를 잡아야 합니다. 이 위치를 인지 못하고 앱만 보면서 돌아다니게 되면 길을 잃기 쉬우니, 주의하여 미리 탑승 존을 인지하면 좋습니다. 특히 야간에는 사람이 몰려서, 주의하여야 합니다. 오히려 더 아래쪽으로 내려와서, Google Campus 내에서 잡는 게 좋을 수도 있습니다.또한 Uber 운전사한테 얻은 정보인데요, Ride-sharing을 하는 Uber 플랜을 사용하면 운전사들이 쉽게 취소한다고 하니, 조금 비싸더라도 개인으로 탑승하는 Uber 플랜을 사용하는 것이 좋다고 합니다.복장을 조심하라(?)캘리포니아는 6월에 더울때는 엄청 덥고, 추울때는 엄청 춥습니다. 특히 야외에서 오래 돌아다녀야 하기 때문에, 충분한 대비가 필수 입니다. 후디같은 옷을 입으시거나, 얇은 외투를 입는 등 충분히 준비해가면 좋습니다. 저는 행사장에서  CODE 가 젹혀진 후디를 구입해서, 매일 입고 다녔는데요, 매우 유용했습니다. 선크림 같은게 제공되긴 하지만, 그래도 제때 실내에서 휴식을 취하고 물을 많이 마시는 것이 좋습니다.마치며행사장을 돌아다니며 구글의 생태계에 푹 빠져 볼 수 있었던, 뜻깊은 경험이었습니다. 특히 그들이 곧 완성되고 릴리즈 된다고 자신하는 새로운 기능들은 상상하지 못했던 것들이라 놀라웠고, 이 시점에 직접 볼 수 있다는 것이 감사했습니다. Hyperconnect에서도 Mobile AI의 심화된 적용을 위해 많은 노력을 하고 있는데요, Azar 및 새로 시도하고 있는 Picai 같은 앱들을 통해 더 특별한 가치를 제공할 수 있도록 노력하고 있으니, 많은 기대 바랍니다!링크Android PApp BundleAndroid JetpackAndroidXML KitTFLiteFlutter#하이퍼커넥트 #개발자 #이벤트 #구글 #참여후기 #꿀팁 #인사이트 #이벤트참여 #미국 #캘리포니아

오랜만에 돌아온 크로키닷컴 인터뷰!요즘 채용이 활발하게 진행 중인 크로키닷컴의 [프론트엔드 개발자] 에 관해 궁금해하시는 분들을 위해, Dev.팀에서 근무하고 있는 프론트엔드 개발자 두 분! 영준님, 케빈님을 모셨습니다.Chapter 1. 저를 소개합니다!Q. 영준님, 케빈님 반갑습니다! 간단하게 자기소개 부탁드릴게요.영준 저는 프론트엔드 개발자 김영준이고요, 지그재그의 또 다른 신사업 서비스를 만들어가고 있습니다. 프론트엔드 개발은 5년 정도 했고, 요즘은 신사업 서비스에 새로운 기능이 들어갈 예정이라 그 작업을 열심히 하고 있습니다! 참, 원래 저는 공대 출신은 아니고 디자인과를 졸업했어요.(우와.. 디자이너에서 개발자로 전향하신 특별한 계기가 있으셨나요?)그때 당시 어도비 플래시가 잘 되던 시기였는데, 플래시가 좋아서 그쪽 수업을 많이 들었거든요. 그때부터 관심을 갖게 돼서 첫 회사에는 플래시 개발자로 입사했었어요. 이후에 플래시 사용률이 점차 줄어들면서 프론트엔드 개발 쪽으로 전향하게 되었습니다.케빈 어.. 제 본명은 성훈이고요.(웃음) 저는 원래 풀스택 개발자로 2년 정도 일을 했었어요. 본격적으로 프론트엔드 쪽으로 전향한 지 2년 정도 된 것 같아요. 저도 영준님이랑 비슷하게 공대는 아니고 영상그래픽을 전공했어요. 3D나 특수효과 같은 거? 교양수업으로 HTML 수업을 듣다가 개발에 관심이 생겨서 시작하게 됐습니다!(그렇군요! 케빈님 곧 있으면 입사 100일을 맞이하시게 되는데 소감이 어떠신가요?)프론트엔드 포지션에 온전히 집중해서 일을 해본 건 처음이에요. 이전에 바라 왔던 업무환경에 많이 근접한 것 같고 점차 적응 중에 있습니다.Q. 어떠한 연말을 보내고 계신가요?영준 어! 저 얘기할 거 있어요. 얼마 전부터 회사에서 전세자금 대출 이자를 지원해주기 시작한 덕분에 난생처음으로 독립을 하게 됐거든요. 이자를 지원받게 되니 집도 더 잘 구하게 된 것 같아요! 그래서 요즘은 자취 초년생으로서 이것저것 해보고 있어요. 요리도 해보고 그동안 해보고 싶었던 것들? 하지만 집에서 부모님이 해주시는 게 얼마나 감사한 지도 알게 됐어요. (그래도 다시 돌아가긴 싫으시겠죠?)영준 네, 독립해서 진짜 좋아요. 그래서 요즘 일하는 시간 외에는 인테리어 고민을 많이 하고 있어요. 지금 집에는 아무것도 없거든요. 곧 영준님만의 감성으로 채워질 집!케빈 아.. 저는 딱히 뭐가 없는데..영준 아 아직 입양 안 받았어요?케빈 아! 맞아요. 제가 동물을 입양하려고 준비하고 있어요. 그 동물에 대해서 공부 먼저 하고 제대로 알게 된 다음 입양하려고요. (입양이요? 강아지? 고양이?!) 케빈 페럿이라고 아세요? 페럿을 입양하려고 공부하고 있어요. 돈도 많이 든다고 해서 모으고 있기도 하고요. 그것 빼고는 하는 게 없어요 아직.키우는 분이 별로 없는 희귀한 동물, 페럿! 애교가 많은 동물이라고 하네요 :-)Chapter 2. 직잭러가 되어가는 과정Q. 지그재그로 이직하고 싶었던 특별한 계기나 이유가 있었나요?영준 이직할 때 개발자로서 성장이 가능한 회사를 찾으려고 했어요. 이전 회사가 에이전시이다 보니 코드 리뷰 문화가 없었거든요. 코드 리뷰는 프로덕트에도 좋은 영향을 끼치지만 개발자 개개인의 성장에 더 영향을 많이 끼친다고 생각했거든요.(실제로 겪어본 이후로는 확신합니다!)프로덕트에 대한 이해를 높이는 것은 물론 양질의 코드를 실컷 볼 수 있고, 또 어느 코드 하나 허투루 작성할 수 없어요. 그래서 꼭 코드 리뷰가 있는 회사로 가려고 했는데, 지그재그가 딱 그랬습니다!케빈 저도 코드 리뷰 문화에 한 표! 저는 프론트엔드 분야에서는 늦게 공부를 시작했기 때문에 배울 수 있는 환경이 매우 중요하다고 생각했거든요. 아 그리고 저는 이직을 고려할 때, 그 회사에 대해서 미리 프레스나 github을 다 찾아보는데, 그러다 보면 이 회사는 '이렇게 근무를 하는구나'가 어느 정도 보이더라고요. 근데 지그재그 팀을 찾아보면서 여기서 꼭 같이 일해보고 싶다고 생각했어요. 찾아보시면 지그재그 개발 문화와 관련된 소스코드나 오픈소스 프로젝트가 공개되어 있는데요, 왜 이런 코드를 썼고 이런 규칙을 정했는지 오픈해두고 같이 생각해볼 수 있게끔 되어 있어요.영준 저는 기술 블로그도 재밌게 봤어요.케빈 맞아요. 특히 주니어의 입장에서는 발전에 대한 욕망이라고 해야 하나?(웃음) 욕심이 클 수밖에 없는데 기술 블로그가 지그재그 팀에 대한 궁금증을 풀어주는데 많은 도움이 됐어요.나름 활발한 (?) 지그재그 기술 블로그에도 놀러 오세요! https://devblog.croquis.com/ko/Q. 입사 전 인터뷰 때 가장 인상 깊었던 질문이나 에피소드가 있으신가요?영준 일단 면접 절차 진행이 너무 친절해서 당시 기억이 엄청 좋았어요. 또 정해진 질문지에 대한 뻔한 대답보다, 저에게 fit된 인터뷰를 진행했던 것도 좋았고요. 전 회사에서는 인터렉션 관련된 작업을 많이 했었는데, 쟈니님(CEO)이 인터렉션이 프로덕트에 어떤 도움을 줄 수 있을까에 대한 질문이 되게 참신하고 좋게 다가왔습니다. 물론 제가 답한 것 들 이외에도 어떤 영향을 끼칠 수 있는지 말해주어서 더 좋았어요! 아, 재밌는 에피소드가 하나 있는데.. 쟈니님이 '영준님은 친구들 사이에서 어떤 사람이에요?'라고 질문을 하셔서 '먹는 것 좋아하는 사람이요.'라고 대답했더니, 쟈니님이 '그럼 안 되겠네요. 저희는 밥을 다 사드리기 때문에 영준님이 오시면 거덜 날 것 같아요'라고 하셨어요.(빅웃음) 쟈니님은 워낙 장난이 많으신 분이라 재밌었어요.케빈 저는 2차 인터뷰 때 엄청 떨었어요. 그래서 어떤 질문이 나왔고 어떻게 대답을 했었는지 하나도 기억이 안 나네요. 입사 후 수습기간이 끝나갈 즈음에 쟈니님과 미팅을 한 번 더 했었는데, 쟈니님이 제가 인터뷰 때 떨었던 것과는 너무 다르게 업무 커뮤니케이션을 잘한다는 팀원들의 반응이 많아서 놀랐다고 하셨어요.영준 케빈님 1차 인터뷰 때에도 엄청 긴장되시지 않았어요?케빈 맞아요. 그땐 그래도 기술적인 질문이 많아서 나름 덜 떨었답니다.(?) 그리고 아까 영준님이 답해주셨듯이, 저도 마찬가지로 제가 경험한 것을 중심으로 질문을 많이 해주셔서 수월하게 대답할 수 있었던 것 같아요. 입사한 지 얼마 되지 않아 interviewer로 몇 번 참석했었는데, 지원자분의 경험을 중심으로 대화를 나누는 게 실제로 지원자분에 대해서 더 잘 알아갈 수 있는 좋은 방법인 것 같아요!Q. 입사 전 기대했던 지그재그의 모습과 실제 겪어본 지그재그의 모습은 어때요? 많이 다른가요?케빈 저는 기대했던 것과 크게 다르지 않았어요. 많은 개발자들이 기술적으로 더 성장할 수 없다고 느껴질 때 상실감을 크게 느낄 거예요. 전 직장에서도 서로 토론하고 의견을 공유하는 문화가 있었는데 바쁘다 보니 그 문화가 점점 사라지게 되어 많이 안타까웠죠. 그래서 지금은 지그재그 개발팀의 좋은 문화가 유지될 수 있게, 계속 활발하게 운영이 될 수 있도록 적극적으로 참여하려고 노력하고 있어요. 영준 사실 전 지그재그 팀이 딱딱한 분위기에서 업무를 할 거라고 생각했었어요. 워낙에 빠르게 성장하고 있는 회사이다 보니? 근데 막상 들어와 보니 이만큼 같이 일하는 게 재밌고 캐릭터가 독특한 사람들이 많은 회사는 처음이에요. 그리고 저희가 매주 월요일에 전 직원이 모여서 주간 미팅을 하잖아요. 거기서 팀별로 프로젝트 진행상황을 공유하는데 정확한 데이터 수치를 기반으로 꼼꼼하게 분석하고 리뷰하는 모습에 놀랐어요. 추가적으로 개발에 대한 열정이 있는 동료들이 많았으면 하는 소망도 있었는데, 실제로 만난 지그재그는 개발 욕심 가득한 사람들의 모임이라 매일매일 자극받으며 근무하고 있어요.매주 월요일 전직원이 참여하는 주간 미팅!Q. 지그재그 팀에 들어온 후에서야 비로소 알 수 있었던 좋은 문화나 제도가 있을까요?영준 사내 스터디가 많은 거? 아마 우리 회사가 다른 어떤 회사보다 스터디가 많을걸요? 원한다면 누구든 만들어서 모집할 수 있거든요. 다들 매우 적극적입니다.(그럼 영준님은 몇 개의 스터디에 참여하고 계세요?) 저는 1월에 새로 시작할 스터디까지 하면 두 개요!케빈 개발자들에겐 스터디도 큰 요소일 거예요. 다양한 스터디가 지속적으로 운영되는 게 쉬운 일은 아니라, 기술 블로그를 보면 '진짜 이만큼이나 공부한다고?'라고 의문이 들 수밖에 없으니까요. 아! 그리고 스터디는 아니지만 개발 미식회라는 프로그램이 있어요. 다른 사람들과 함께 의논해보고 싶은 코드가 있거나 혹은 본인이 만든 코드를 공유하고 싶은 사람이 자발적으로 신청자를 받아서 점심을 함께 먹으면서 발표도 하고 의견도 나누는 시간이에요. 한 달에 1-2회 정도 진행이 되고 있어요. 다음 주에 저도 발표하기로 했거든요. 신청자가 없어서 못하게 되면 안 되는데..영준 그리고 발표를 했던 사람은 다음 개발 미식회의 점심 메뉴를 선정할 수 있는 특혜가 주어집니다.(웃음)케빈 오! 그건 몰랐어요. 그리고 저는 저번에 영준님이 발표하실 때에도 신청해서 들었어요. 영준 다들 서로 발표를 하고 싶어서 바쁜 와중에도 열심히 공부해요. 바쁠 땐 듣는 게 좀 부담스러울 텐데도, 다들 적극적으로 들어주려고 하니 고맙죠.영준 님의 개발 미식회 모습! 제가 더 떨리네요 @.@Chapter 3. Dev. 팀은 이런 분을 찾아요!Q. 먼저 Dev. 팀은 어떤 방식으로 일을 하나요?영준 백엔드에 계시는 분들도 그렇고 다른 포지션에 계신 분들도 프론트엔드에 관심이 많으셔서 도와주실 때가 많이 있어요. 아무래도 다들 공부를 많이 하다 보니 그런 것 같아요. 그러다 보니 업무 할 때 같이 고민할 수 있어서 좋죠. 그리고 프로젝트를 일정에 맞추어 진행하다 보면 포기해야 될 부분이 생기기 마련인데요, 지그재그 팀은 유저의 사용성 향상을 위해 기획했던 것들을 최대한 포기하지 않고 가져갈 수 있는 방향을 모색하는 편이에요. 포기하면서 잃는 것도 생각하고 얻게 되는 것도 생각해야 하니 항상 신중해야 합니다.케빈 프로젝트를 진행하면서 문제가 생기면 다 같이 의논해서 풀려고 해요. 그리고 그 과정에서 여러 가지 다른 의견이 나오면 합의점을 찾으려고 하고요. 이건 팀 내에서 뿐만 아니라 유관부서랑 함께 일할 때도 같아요. 팀원들 모두가 개인적인 관점이 아닌 product 관점과 사용자 관점으로 생각하려고 하기 때문이죠. 또 프로젝트를 통해 유저분들에게 더 좋은 경험을 전달해주고자 노력하고 있어요. 그래서 유저분들의 기대에 부응한 부분과 그렇지 못한 부분이 무엇인지에 대해 사용자 데이터를 기반으로 회고하는 과정도 함께 진행하고 있습니다.Q. 회사 안에서 해보고 싶은 특별한 프로젝트가 있으신가요?영준 저는 직잭버디를 뽑는 시스템을 만들고 싶어요. 그리고 의류, 패션에 관련된 새 프로젝트도 해보고 싶네요. (*직잭버디는 신규 입사자의 빠른 적응을 도와드리는 멘토링 프로그램입니다!)케빈 저는 개인적으로 점심시간 메뉴 고르는 룰렛을 만들고 싶어요. 회사 주변에 밥집이 너무 많아서 오히려 메뉴를 고르기가 어려워요. 만들면 잘 쓰지 않을까요? 의견을 받아서 다 같이 만들어봐도 재밌을 것 같아요.Q. 요즘 [프론트엔드 개발자] 채용이 한창인데요, 어떤 분과 함께 일하고 싶으신가요?케빈 개발 환경을 기반으로 여러 개발 항목들을 유저의 관점에서 대조해 봤을 때, 깊게 생각해보고 경험해 본 분이면 좋겠어요. 유저의 관점에서 더 생각해보고 적용하시는 분이라면 지그재그 서비스에 대해 애정을 가지고 일할 수 있을 것 같아요.영준 요구사항에 맞게 동작하는 프로그램을 만드는 것은 물론, 유저의 사용성을 생각하는 개발자였으면 좋겠어요. 예를 들면 모바일 기기에서의 최소 터치 영역을 생각한다든지... 유저를 직접 만나는 최접점에 있는 개발이다 보니, 사용성에 관해서는 가장 관심이 많아야 한다고 생각하거든요. 또 프론트엔드 개발 자체가 빠르게 발전하고 있는데, 왜 이렇게 바뀌고 있는지를 생각하는 개발자면 좋을 것 같아요. 그리고 회사가 커지면서 여러 가지 새로운 서비스들도 생기고 새로운 경험도 많이 하게 될 텐데요, 새로운 걸 만들어 보고 겪어보고 싶은 분이라면 지원해주세요!케빈 평소에 업무를 하실 때 깊이 있게 고민하면서 선택하신 본인의 라이브러리, 도구들에 대해 왜 이런 선택을 했는지.. 또 코드 한 줄 한 줄을 어떤 의도로 작성했는지에 대해 생각해보신 분이라면 어렵지 않게 인터뷰를 진행하실 수 있을 거예요. 또, 그런 분들이 계시다면 저희도 꼭 모시고 싶어요!Chapter 4. 마무리Q. 올해 지그재그 팀에 합류하면서 개인적으로 성장한 부분, 그리고 2020년의 목표나 버킷리스트가 있으신가요?영준 지그재그 서비스가 이커머스가 되어가는 과정을 함께 하면서 성장했다고 느꼈어요. 내년 목표는 신사업 성공시키기! 업무 외적으로는 운동을 열심히 해서 바다에서 사진 찍는 거예요. (몸짱 영준)케빈 저는 Z결제 서비스가 오픈되면서 마케팅 이벤트를 위한 개발을 많이 했는데요, 이벤트에 대한 유저의 반응이 폭발적인 걸 보면서 더 유저의 입장에서 생각하려고 하는 스스로를 보며 성장하고 있다고 느꼈어요. 더 공부하려고 하기도 하고요. 그리고 개인적으로는 내년에 영어공부를 열심히 하고 싶어요. 제가 즐겨하는 PC게임이 있는데, 외국인 유저와 더 편하게 대화하면서 게임하고 싶어서요.(웃음)Q. 다음 인터뷰는 어느 팀에서 하면 좋을까요? 그 팀에 특히 궁금한 것이 있다면요?영준 저는 서버 개발자 또는 데이터 팀이요! 지그재그 서비스의 서버 개발자들은 각자 태스크를 부여받아서 진행하는 방식으로 업무를 한다고 들었는데, 구체적으로 R&R이나 업무 프로세스가 어떤 방식으로 이루어지는지 궁금해요. 그리고 데이터 팀에는 수많은 데이터들을 앞으로 지그재그 서비스의 발전을 위해 어떻게 활용할 수 있을지, 그리고 데이터팀에 계시는 인성님께 어떻게 그렇게 매일 웃으며 즐겁게 지내실 수 있는지 여쭤보고 싶어요.케빈 저는 디자인 팀! 지그재그의 다양한 디자인들을 작업하고 의사결정을 내리기까지의 논의 방식이 궁금해요. 그리고 디자인 팀에도 인원이 늘었는데, 그로 인해 어떠한 변화가 생겼는지도 궁금합니다.지그재그에서는 웹 프론트엔드 개발자를 포함하여 활발하게 채용을 진행하고 있습니다. 지그재그 팀과 함께, 수면 아래 숨겨진 가치를 찾아내는 경험에 동참할 팀원을 꼭 모시고 싶습니다 :-) 궁금하신 점은 언제나 [email protected] 또는 http://facebook.com/zigzagcareer로 연락 주세요!지그재그 [웹 프론트엔드 개발자] 포지션을 소개합니다!이런 일을 합니다.이런 분을 모십니다.이 중 하나라도 가능하시다면 더더욱 좋아요 :)지원 방법채용 절차혜택과 복지   더 많은 공고는 채용 사이트에서 확인 가능합니다! >>> 채용 사이트 바로가기

독학을 시작했습니다. 스터디를 가려고 했는데 수많은 전문용어들이 제 영혼을 피폐하게 만드는 바람에 정신건강이 염려되었거든요. 포토샵도 혼자 배웠으니 이것도 못할까! 라고 자신있게 책을 폈는데 못할 것 같습니다.......그래도 산 책 값이 아까우니 읽고 공부한 내용들을 하나하나 정리해보고자 합니당! 블록체인 전문가님들이 혹시 이 글을 보신다면 노잼과 지루함내지는 유치함을 느끼실 수 있으니 엄빠미소로 지켜봐주시면 감사하겠습니다. 잘못된 부분이 있다면 바로 잡아주세요!!글을 쓰면서 5가지 원칙을 지킬겁니다.1. 꼭 써야하는 고유명사가 아닌 이상 어려운 단어는 쓰지 않습니다. 중학생 정도가 이해될 수준이길 제발 바랍니다...저는 블록체인을 이제 이틀 째 공부하고 있거든요.2. 가급적 팩트체크된 내용만 쓸겁니다.3. 제대로 공부하려면 경제사, IT기술, 코딩 등등..수많은 요소가 복잡하게 들어가지만 여기선 꼭 필요한 쏘옥 뽑아서 얘기할 겁니다. 4. 짧게 쓸 겁니다.5. 가끔 쓸 겁니다.(자주 쓰기 힘든 주제임..)시작합니당 :)블록체인이 왜 태어났는지 얜 뭔지부터 알아야 할 것 같아요. 그러자면 시간을 조금 되돌려서 우리는 어떻게 사고파는 경제활동을 해왔는지 살펴볼께요.1. 아주 오래전 = 기억하기종이란게 나타나기도 전 우리는 사과5개를 빨간집에서 해가 질 무렵에 씨앗10개와 교환했다. 는 걸 기억해야 했어요. 문제는 서로가 잘못 기억하거나 한 쪽이 다르게 우겨버리면 할 말이 없다는 거죠..철저히 신뢰와 기억에 의존한 거래였어요.2. 오래 전 = 나무나 가죽에 새기기원래 사람은 두 발로 직립보행 하기 전부터도 그림을 좋아했어요. 동굴에도 그리고 돌에도 그리고, 나무나 땅에도 곧잘 그림을 그렸죠. 뭔가 주고받는 물품이 많아지면서 기억하기가 힘들어지자, 이젠 가죽이나 나무 등등에 갯수를 남기기 시작했죠. 문제점은 그 가죽이나 나무가 훼손되거나 도난당하면 증명할 방법이 없다는 거에요.'동쪽 언덕 마을에서 온 또박이가 가죽3개를 사갔다.'3. 조금 오래전 = 종이에 적기(단식부기)종이가 발명되고 아라비아 숫자와 알파벳, 한글, 한자, 인도어 등등이 발달하기 시작하면서 문서를 남길 수 있게 되었어요!!! 문서를 남긴다는 건 굉장했죠!!!오랜 시간이 지나도 기록들을 잘 보관할 수 있었어요!! 거래를 할 때에도 수입과 지출을 한 번에 (가계부처럼) 적으면서 작은 종이에 많은 내용을 남길 수 있었답니다. 하지만..여전히 문제는 사람이었어요. 이를 위조하거나 없애버리면...? 또는 불에 다 타서 없어지면??4. 얼마 전 = 적은 걸 나눠가지기(복식부기)그래서 서로 함께 같은 내용을 공유하기로 했어요. 너 하나 나 하나. 그리고 그 과정을 감시하는 회계사. 이런 과정은 우리 조선시대에서도 아주 엄격했답니다. 특히 계문화가 발달했던 우리나라는 다양한 장부를 기록했는데 '용하기'라는 계의 장부기재는 정말 엄격한 원칙이 있었답니다!!1. 임시장부를 2부 작성해요. 이 때 회계담당자 이외 심지어 2명이 더 감시하고 있어요.2. 기재를 시작해요.3. 계원들이 다 모여야 하고 적은 내용을 크게 읽어요. 이 때 의심스러운게 있으면 이의제기나 수정을 해요.4. 계장과 두 명의 감시원이 있는 상태에서 최종수정해요. 그리고 계장이 서명해요.5. 중복된 장부가 있는지 확인하고 새 장부를 넣어 보관해요.엄청나죠???..놀라운 건 현재의 블록체인의 원리도 위와 비슷해요!! 다만 사람이 일일이 적고 감시하는 게 아니라 명령어에 의해 챡챡 처리되는 것 뿐이랄까요. 하지만 이것도 결국 '물질' 이다 보니....화재나 전쟁으로 인해 소실되어 버리면 그걸로 끝이었어요.5. 요즘 = 기관이나 중앙에 맡기기왕정체제가 아니라 민주주의와 시장경제가 도입되면서 은행이나 보험사, 카드사와 같이 경제활동을 담당하는 기업과 중앙기관이 생겨나기 시작했어요! 엄청나게 거대한 정보를 크으으은 서버나 금고에 보관할 수 있었어요. 그것은 영원해보이고 사람들은 오래도록 보관할 수 있다고 생각하니 관심을 끄기 시작했죠. 내 돈은 금고에 잘 있을 거니까요.하지만, 자본주의는 그런게 아니었어요. 은행은 내 돈을 다른 사람에게 대출로 빌려주고 그 이자로 돈을 벌어요. 그리고 다른 사람이 갚은 돈으로 다시 내 예금을 채우죠. 졸라 돌려막기인 거에요. 사람들이 끊임없이 돈을 빌리고 다시 갚을 수 있게 다양한 상품들을 만들어요. 이 방식은 굉장히 효율적이고 아무 문제가 없을 것 같이 보였어요.하지만, 해킹을 당했어요.은행을 털렸어요서브프라임 모지기론 사태처럼, 무리한 상품의 실패는 수백개의 기업을 무너뜨렸어요. 수많은 사람들의 돈이 한 순간에 날아갔어요.서버가 먹통이 되어 거래가 안되는 경우도 있어요.지진 등의 천재지변이 나면 내 기록은 사라지고 말아요.단순히 큰 사옥을 지닌 곳이니까 영원불멸할 것 같았던 중앙기관도 하루 아침에 무너질 수 있단 사실을 우린 수 차례 경험했어요. 그럼에도 우린 뭘 어떻게 해야할 지 몰랐어요. 우리가 할 수 있는 건 사고가 터지면 변호사를 써서 소송을 하는 것 뿐이었어요. 우린 은행의 상품이 정확히 어떤건지, 보험약관이 뭔지... 카드사는 어떤 원리로 움직이는지...내 세금은 어떻게 쓰이고 있는지...우리 돈이 어떻게 거래되고 내 돈을 가지고 그들이 무엇을 하는지 하나도 몰라요. 그냥 속수무책으로 그들만 믿고 있는 거예요. 6. 블록체인의 탄생 = 모두가 장부를 가질 수 있게그래서 생각해봤어요. 한 곳에 모여있으니 문제가 생긴다면, 쪼개면 되지 않을까? 은행 한 곳을 터는 것은 쉽지만 1,000여명을 한꺼번에 터는 것은 불가능할테니까. 계모임에서 쓰던 그 장부를 엄청나게 많이 만들어서 모두가 가지면 어떨까? 누굴 못 믿거나 위조하거나 털리거나 불나서 사라질 일이 없을 거 아냐?? 라는 생각을 말이죠. 그런데 친구가 질문을 하네요!!친구 : 그런데 어떻게??나 : 인터넷이 있잖아!! 내가 온라인상에서 거래하면 그 기록이 남잖아~ 그걸 모두가 공유하는거지! 친구 : 모두가 누군데?나 : 응 그건 이제부터 모아야해!!친구 : 그럼 어쨌든 모인 사람들에게 모두 공유하면 내가 어제 김치한포기 시킨것도 다른 사람이 알게 되는거야??나 : 아니지;;; 니가 뭘 시켰는지 그딴 건 관심없어..그냥 얼마 거래를 언제 몇시몇분몇초에 어떻게 했는가만 기록에 남는거야! 그리고 다른 사람은 그걸 직접 눈으로 볼 수 있는 게 아냐.생각해봐. 넌 브런치 로그인한 기록을 눈으로 다 볼 수 있어? 며칠 몇시에 얼마나 로그인했는지 알 방법이 없지? 하지만 그 기록이 있을까 없을까? 그렇지, 반드시 있다구. 범죄수사할때도 그러자나. 우리 화면에는 시간/내용밖엔 안뜨는 문자메시지지만, 실제로 서버에는 발신위치, 수신위치, 번호정보 등등이 모두 숨겨져 있잖아. 또 하나! 너가 네이버에서 틴트를 검색하면 나중에 페북에서 틴트광고가 뜨지 않아? 우리의 방문기록이나 클릭한 기록들이 모두 남아있기 때문이야.이렇게 우리가 눈으로 보는 화면 뒤에는 수많은 정보들이 컴퓨터만의 전기신호로 저장되어 있어. 우리가 말하는 장부도 이런 식으로 저장되어 있는거라구.  물론 필요하다면 그걸 화면으로 띄울 수 있는 명령어를 만들 수도 있겠지.친구 : 그건 이해했어, 내가 직접 볼 순 없지만 마치 사이트 방문기록처럼 어딘가에 거래내역이 다 남아있다는 얘기지?... 그런데 아까 지금부터 모아야 한다는 사람들은 어떻게 모으는거야??나 : 그건!!..바로!!!! 다음에 설명해줄께!!또 공부해서 돌아올께용!!

Overview이전까지는 단일 테이블에서 INDEX를 적용하는 효과적인 방법들을 살펴봤습니다. 아직 못 본 개발자를 위해 친절히 링크도 준비했습니다. 이 글을 보기 전에 아래의 글들을 먼저 보는 것이 좋습니다.단일 TABLE을 SELECT하자!: 올바른 SELECT문 작성하기순서대로 척척, ORDER BY: ORDER BY 조건 처리 알아보기원하는 대로 뭉치는 GROUP BY: GROUP BY 조건 처리 알아보기이번 글에서는 테이블에서 컬럼을 추가 또는 삭제하고, 테이블을 분리하는 방법까지 알아보겠습니다.Let’s do it먼저 아래의 컬럼을 추가해봅시다.ALTER TABLE test.TB_MBR_BAS ADD COLUMN AREA_NM    VARCHAR(10)    COMMENT '지역 명'; 그리고 테스트 자료를 넣습니다.UPDATE test.TB_MBR_BAS SET     AREA_NM =         CASE FLOOR(RAND()*15)             WHEN 0    THEN '서울특별시'             WHEN 1    THEN '부산광역시'             WHEN 2    THEN '인천광역시'             WHEN 3    THEN '대전광역시'             WHEN 4    THEN '대구광역시'             WHEN 5    THEN '광주광역시'             WHEN 6    THEN '울산광역시'             WHEN 7    THEN '경기도'             WHEN 8    THEN '강원도'             WHEN 9    THEN '충청남도'             WHEN 10    THEN '충청북도'             WHEN 11    THEN '전라남도'             WHEN 12    THEN '전라북도'             WHEN 13    THEN '경상남도'             WHEN 14    THEN '경상북도'             WHEN 15    THEN '제주도'         END WHERE AREA_NM IS NULL ; 자료를 확인하면 아래와 같이 나옵니다.SELECT     * FROM test.TB_MBR_BAS ; AREA_NM 컬럼을 추가해 지역이 나오도록 했습니다. AREA_NM을 보면 중복되는 지역명이 있습니다. 이럴 때 보통 AREA_NM을 별도의 테이블을 만들어 ID OR 코드를 부여해 처리합니다. 위의 UPDATE 문을 참조하여 ID를 만들면 아래와 같이 만들 수 있습니다.0    : ‘서울특별시’1    : ‘부산광역시’2    : ‘인천광역시’3    : ‘대전광역시’4    : ‘대구광역시’5    : ‘광주광역시’6    : ‘울산광역시’7    : ‘경기도’8    : ‘강원도’9    : ‘충청남도’10    : ‘충청북도’11    : ‘전라남도’12    : ‘전라북도’13    : ‘경상남도’14    : ‘경상북도’15    : ‘제주도’먼저 AREA_NM과 ID를 다룰 테이블을 만들겠습니다.CREATE TABLE test.TB_AREA_BAS  (     AREA_ID        TINYINT UNSIGNED NOT NULL    COMMENT '지역 아이디 '     ,AREA_NM     VARCHAR(10)             NOT NULL    COMMENT '지역 명'     ,PRIMARY KEY (AREA_ID)  ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='TB 지역 기본' ; 테이블을 만들었으면 자료를 넣어줍니다. INSERT INTO test.TB_AREA_BAS  (     AREA_ID      ,AREA_NM  ) VALUES (0,'서울특별시')  ,(1,'부산광역시')  ,(2,'인천광역시')  ,(3,'대전광역시')  ,(4,'대구광역시')  ,(5,'광주광역시')  ,(6,'울산광역시')  ,(7,'경기도')  ,(8,'강원도')  ,(9,'충청남도')  ,(10,'충청북도')  ,(11,'전라남도')  ,(12,'전라북도')  ,(13,'경상남도')  ,(14,'경상북도')  ,(15,'제주도')  ; 자료를 확인하면 아래와 같이 나옵니다.SELECT     * FROM test.TB_AREA_BAS ; 테이블을 만들었다면 test.TB_MBR_BAS 테이블에 AREA_ID 를 추가하여 자료를 넣은 후 AREA_NM 컬럼을 삭제하면 됩니다.이제 AREA_ID를 추가합니다.ALTER TABLE test.TB_MBR_BAS ADD COLUMN AREA_ID TINYINT UNSIGNED NOT NULL COMMENT '지역 아이디'; AREA_NM을 참조하여 AREA_ID를 넣습니다.UPDATE test.TB_MBR_BAS SET     AREA_ID =         CASE AREA_NM             WHEN '서울특별시'    THEN 0             WHEN '부산광역시'    THEN 1             WHEN '인천광역시'    THEN 2             WHEN '대전광역시'    THEN 3             WHEN '대구광역시'    THEN 4             WHEN '광주광역시'    THEN 5             WHEN '울산광역시'    THEN 6             WHEN '경기도'    THEN 7             WHEN '강원도'    THEN 8             WHEN '충청남도'    THEN 9             WHEN '충청북도'    THEN 10             WHEN '전라남도'    THEN 11             WHEN '전라북도'    THEN 12             WHEN '경상남도'    THEN 13             WHEN '경상북도'    THEN 14             WHEN '제주도'    THEN 15         END ; 자료를 확인하면 아래와 같이 나오는데요.SELECT     * FROM test.TB_MBR_BAS ; 최종적으로 AREA_NM 컬럼을 삭제합시다.ALTER TABLE test.TB_MBR_BAS DROP COLUMN AREA_NM; 삭제했다면 자료를 확인해봅시다.SELECT     * FROM test.TB_MBR_BAS ; 이제 두 개의 테이블을 연결해서 조회해보겠습니다. JOIN을 사용하면 되고, Quey 문은 아래와 같습니다.SELECT     T101.MBR_ID      ,T101.MBR_INDFY_NO      ,T101.MBR_NM      ,T101.AGE      ,T101.AREA_ID      ,T102.AREA_NM FROM test.TB_MBR_BAS T101      INNER JOIN test.TB_AREA_BAS T102          ON T102.AREA_ID = T101.AREA_ID  ; 정리하며위에서 보여드린 예시는 두 가지 다른 점이 있습니다. 첫째는 TABLE 뒤에 T101, T101 과 같은 얼라이스를 준 것, 둘째는 INNER JOIN 문장이 들어간 것입니다.만약 테이블이 2개 이상이라면 사용할 테이블 컬럼을 써야 하는데 테이블명을 그대로 쓴다면 너무 길어집니다. 그래서 얼라이스로 테이블을 간단하게 표시하는 것이죠.INNER JOIN은 JOIN 중 가장 기본이 되는 문장입니다. 플랜을 보면 T101 즉 test.TB_MBR_BAS를 차례대로 전부 읽는데, 그때마다 T102인 test.TB_AREA_BAS 를 AREA_ID 를 기준으로 값을 읽습니다. T101에 해당하는 내용과 T102에 해당하는 내용을 보여주는 것이죠. 저는 Database를 쓰는 이유가 바로 JOIN 때문이라고 생각하는데요. 여러분의 생각은 어떤가요. 조금 헷갈린다면 다음에는 JOIN에 대해서 알아보도록 하겠습니다. (자연스러운 결말..!)글한석종 부장 | R&D 데이터팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

개발과 운영을 함께 devops - 출처당분간의 일기 내용앞으로 몇 개월 간 신생 스타트업 I/O가 어떻게 devops를 자기네만의 스타일로 조직에 안착시켜 나가는지 그 시행착오를 생생하게 공유하는 일기를 쓰려고 합니다.첫 번 째 편인 오늘의 이야기는 두 가지 내용을 다룹니다.devops 도입배경: 어떻게 하다가 devops를 도입하기로 했는지 그 배경에 대에서 이야기 합니다.devops 필요성 인지: 가장 먼저 소프트웨어팀이 devops 필요성을 느끼도록 시도한 스터디 세미나에 관한 이야기를 합니다.devops 도입 도중에 실패할 수 있습니다. 그래서 1편이 마지막 연재일 수 있습니다. 혹은 온갖 개고생을 해가면서 결국 devops를 성공적으로 조직에 안착시켜 tech기업다운 모습을 갖출 수 도 있습니다. 정답은 시간이 얼마간 흐른 뒤에야 알 수 있겠죠? 무언가를 조직에 도입하는 스토리를 사후적으로 그러니까 프로젝트가 끝난 후에 쓰게된다면 프로젝트 과정의 생생함이 퇴색됩니다. 힘들었던 추억도 되돌아보면 미화되듯이 그 당시에 골치아팠던 일들을 그 당시에 써놓지 않으면 까먹을 때가 꽤나 많습니다. 한 편으로는 이렇게 칼자루를 뽑아놔야 반드시 devops를 성공시키기 위해 제가 더 처절해질 수 있을 것 같습니다. 제 나약한 마음이 바뀌지 않기 위해 devops 시작과 동시에 연재물도 함께 시작하겠습니다.devops 도입배경스위처 M 앱이 출시된지 약 한 달 정도 되었습니다.경영을 해오면서 항상 위기의식을 느끼고 있지만 이번에는 조금 심상치 않았습니다.“아.. 라이브서비스를 하기엔 현재 I/O의 소프트웨어 역량이 심각하게 부족하구나! 하드웨어 역량이 Critical Path일 줄 알았는데 되려 소프트웨어가 우리의 발목을 잡고 있구나..”그동안 하드웨어 멤버들은 초심자의 마음과 책임감을 동시에 갖고 무서운 속도로 성장해왔습니다. 새로운 버전의 스위처(M)에 적용된 기구설계 수준, Supply chain 관리 능력, 블루투스 모듈 성능은 이전 버전(W) 비할바가 안됩니다. 놀랄만큼 일취월장 했습니다. 단적인 예로 현재 스위처M의 블루투스 연결 거리는 오픈필드에서 70m이상 나옵니다. 이전 세대인 스위처W의 연결거리가 약 20m 미만임을 감안하면 연결성이 300%이상 좋아졌다고 볼 수 있습니다.반면 소프트웨어팀은 여전히 초보적인 수준을 벗어나지 못하고 있습니다. 전공분야라는 자만심에 소프트웨어를 밑도 끝도 없는 구렁텅이에 밀쳐 넣고있는 제 자신을 발견 했습니다. 창피했습니다. 가장 중요하다고 볼 수 있는 초기고객으로부터 어처구니없는 버그 리포팅을 받을때면 쥐구멍으로라도 숨고 싶었습니다. Customer Service역할까지 도맡아하는 마케터가 수 많은 컴플레인을 대응하느라 정말 고생이 많았습니다.심각한 문제는 소프트웨어팀이 문제의 원인이 무엇인지 조차 잘 모르고 있다는 사실이었습니다. 그저 열심히 다음 피쳐를 개발하기 위해 코드를 짜내는 데에만 자신을 몰아붙이고 있었습니다.그 모습은 한 편의 코메디 영화를 보는 것 같았습니다.<디버깅루프>(1) 배포한 기능에 버그가 처음으로 발견됩니다.(2) “엇 이상한데? 그럴리가 없는데?” 일단 현실을 부정하고 지켜봅니다.(3) 한 두 명의 문제가 아니라는 버그리포팅이 들어옵니다.(4) 부랴부랴 원인을 추측하고 핫픽스 코드를 짜기 시작합니다.(5) 개발을 마치고 일단 배포해 봅니다.(6) 그런데 해결될 줄알 았던 버그가 다시 보고됩니다.그렇게 상황은 2번으로 돌아가 이 디버깅루프를 몇 바퀴 돌고난 후에야 잠잠해집니다.하하… 개판이구나 — 출처:구글 이미지 검색허나 이미 많은 고객들이 불쾌한 UX를 겪고 난 뒤… 이대로는 도저히 구상하는 I/O의 큰 그림에 도달할 수 있을 것 같지 않아, 당분간 제가 CTO역할을 도맡아서 하려고 합니다. 벤 호로위츠가 쓴 Hardthing에서 C-level의 포지션이 비어있을 경우 진짜 적임자가 나타나기 전까지는 그 역할을 CEO가 직접 수행하기를 권장합니다. 이제까지 바쁘다는 핑계로 조직 부채, 기술 부채를 안고왔었는데 최근 Event3 사고를 겪으면서 이젠 이 부채들을 털어내고 나아가야 겠구나 결심하게 되었습니다. 직접 현장으로 다이빙해서 소프트웨어 엔지니어들과 함께 악전고투하기로 했습니다.린스타트업에서 말하는 5-why기법을 적용해보니. 근본적인 원인은 이것이였습니다.주먹구구식으로 Product Live service가 운영(operation)된다.엔지니어들의 코드 퀄리티가 낮아서가 아니었습니다. 알고리즘을 몰라서가 아니었습니다. 디자인 패턴을 몰라서도, 함수형 패러다임을 이해하지 못해서도, 동시성 문제를 몰라서도가 아니었습니다. 되려 I/O의 소프트웨어 엔지니어들의 CS 기본기는 나쁘지 않습니다. 저희는 엉클밥, 켄트백, 마틴파울러를 존경합니다.바보야, 문제는 코딩이 아니야!문제는 경제가 아니야, 바보야!저희 팀의 제일 큰 문제점은 그냥 예전 처럼 새로운 feature 코드를 찍어내는일이 Product Live service operation의 전부라는 사고방식입니다. 배포되는 코드가 얼마나 신뢰할만한지에 대한 고민은 전혀 없고 밀어내기식으로 다음 기능을 추가하는 데만 몰두했습니다. 실상 지금의 스위처에는 새로운 기능을 추가하기위해 코딩을 할때가 아니었는데 말이죠. 쿼리 속도를 높이기 위해 인덱싱을 고민 할 때가 아닌데 말입니다. 정작 Product Live service operation에 필요한 일들(tasks)을 수행하고 있지 않았기 때문에 이 문제가 발생한건데 말이죠.린스타트업의 MVP 관점을 포기하고 완벽한 제품을 내보낸다는 의미가 아닙니다. 그 Minimum Viable Product 조차 제대로 작동이 못시키는 문제를 바로잡기 위해서 입니다. 스크럼으로 조직 tasks를 관리해왔지만 소프트웨어팀은 devops로 거듭나야할 때가 왔음을 느꼈습니다.최소한의 검증 절차도 없이 버그가 담긴 소프트웨어가 고스란히 고객에게 전달되는 악몽을 더 이상 마주해선 안됩니다. 불편함을 겪는 고객을 위해서라도 경쟁력을 잃어가는 조직을 위해서라도 곁에서 힘들어하는 동료들을 위해서라도 소프트웨어팀은 변해야만 했습니다.devops 필요성 인지멤버들에게 제가 방금까지 이야기한 문제점을 전달하고 각자 devops가 무엇인지 공부하기로 했습니다. 일주일간 리서치를 마친 후 한 명씩 돌아가면서 devops가 무엇인지 발표하는 세미나를 진행했습니다. 결론부터 말해 devops 필요성에 대한 공감대 형성은 성공적으로 첫 걸음을 뗀듯 합니다. 모두들 세미나를 준비하면서 그동안 무엇이 문제인지 조차 모르는 상황은 벗어나 보였습니다. 한 명쯤은 “devops는 필요없습니다. 지금처럼 해도돼요!”라는 반응을 예상하기도 했는데, 모두가 겸손의 자세로 지금까지의 문제를 반성하고 변화의 필요성을 절감했습니다. 끊임없이 성장하려는 자세를 가진 I/O 멤버들에게 참 고맙습니다.우린 여기에서 어디쯤..?펌웨어 개발자는 우리의 현재 모습이 위의 그림에서 나오는 원숭이조차 안되는 것 같다고 고백 하기도 했습니다. 그만큼 I/O 소프트웨어팀은 변화를 갈망하는 단계로 무사히 넘어왔습니다. 성공적으로 devops의 필요성 공감대를 형성 시킬 수 있었던 요인은 slow-start 덕분인듯합니다. 초기 고객분들이 실험대상이 된것 처럼 말해 죄송하지만, 작은 규모로라도 Live를 진행하고 거기서 작게나마 사고를 치도록 내버려둔 환경이 devops의 필요성을 받아들이는 데 큰 역할을 했습니다.만약 처음부터 무리해서 스케일업을 시도했다면 그래서 감당할 수 없는 수준의 사고가 동시다발적으로 터졌다면 저희는 자멸하고 말았을 겁니다. 아니, 기다리는 많은 고객들의 기대감에 지레 겁먹고 최대한 소프트웨어 출시 일정을 늦췄겠죠. 그리고 그렇게 절벽에서 등 떠밀리듯이 제품을 출시해서 줄을 잇는 버그 리포팅을 받아보며 평정심을 잃고 말았을 것입니다. 그러나, 감당할 수 있는 수준으로 제품 판매수량을 조절했기 때문에 개발자가 문제를 직시해볼 기회를 가졌고 devops의 필요성은 조직에 쉽게 받아들여질 수 있었습니다.물론 devops 세미나를 진행하면서 안좋은 냄새(징조)를 맡기도 했습니다. 저에게는 행운이죠. 사전에 미리 문제를 파악할 수 있어서. 그 냄새는 도구만능주의 였습니다. devops 도달하기 위해서는 시중에 존재하는 다양한 tool들을 최대한 빠르게 도입해야 할것만 같은 느낌을 말합니다. devops tool들만 제대로 구축한다면 devops도 저절도 실현될것 같은 기대감에 젖습니다. 이 도구만능주의가 만연해지면 devops의 본질은 보지 못한 채 최신 tool 사용에만 집착하게되는 오류를 범하고 맙니다.다행이 I/O의 도구만능주의는 심각한 수준까진 아니고 누구나 초기에 충분히 실수할 수 있는 미약한 수준이었습니다. 사실 제가 예전 스타트업에서 스크럼을 도입할 때도 빠졌던 도구만능주의가 묘하게 겹쳐보여서 낌새를 비교적 빠르게 눈치 챌 수 있었습니다.출처 : 구글 이미지 검색devop는 문화와 운동(movement)입니다. 즉, 무형에 가까운 개념입니다. tool이 아니라 행위(action)와 사상(idea)에 역점을 둬야 합니다. tool은 그저 거들 뿐이죠.간단한 사고실험을 해보겠습니다. 모든 microservices의 설정들을 chef와 puppet으로 관리하고 뱀부나 젠킨스로 빌드-배포-리포팅 파이프라인까지 구축한 devops팀이 있다고 가정해 보겠습니다. 달리 말해, 이 팀은 커맨드 입력 한 번으로 방금 짠 코드를 고객에게 배포할 수 있습니다. 어느날 이 팀에 속한 개발자 A가 지난 일주일간 개발해온 피쳐를 지금 막 마무리 지었습니다. 이어서 A는 devops tool로 구축한 배포 파이프라인 이용해 아주 간단하게 새로운 기능을 업데이트 하기로 했는데요. 과연 괜찮을까요? 최신 devops tool로 중무장 했으니 문제가 없을 것 같습니다. 잠시 후 그렇게 배포된 기능을 써본 고객들이 컴플레인을 걸어옵니다. 잠시 화장실을 다녀온 엔지니어는 허겁지겁 hotfix 코드를 다시 짭니다. 그래도 괜찮습니다. A가 속한 팀은 최신 devops tool이 구축되어 있기 때문에 금방 hotfix를 재배포할 수 있으니까요. 그런데 이장면 어디서 익숙하지 않나요? 앞에서 소개한 디버깅루프와 비슷해 보입니다.출처 : 구글 이미지 검색과연 이게 devops일까요? tool들을 전부 사용하는게 진정 devops의 실현일까요?코드를 리뷰하지도 자동화된 테스트 코드를 실행해보지도 않은 상태에서 지속적 배포는 그저 똥을 더 자주 고객에게 전달하는 것과 다르지 않습니다.높은 품질의 제품은 보장할 수 없습니다. 그렇다면 우리는 무엇부터 해야할까요?Next Iteration저는 장황한 계획을 혐오합니다. 계획을 짜내느라 쏟는 에너지와 시간이 너무 아깝고 무엇보다 계획대로 진행될 확률이 낮기 때문입니다. 대신 저는 스타트업 환경에 맞는 방식으로 일하기를 선호 합니다. 비교적 긴 시간이 필요한 프로젝트 성격의 일을 할 땐 북극성의 위치만을 기억합니다. 쉽게 말해 우리가 산출해야하는 프로젝트 결과물만 생각합니다. 북극성까지 도달하는 정해진 길 따위는 없다고 가정합니다. 혹시 있었다 해도 그냥 잊어버립니다. 스타트업의 리스크는 워낙 변화무쌍하거든요.계획 대신 무던히 아래 두 가지 행동을 반복합니다.(1) 고개를 들어 몸이 북극성 향하도록 합니다.(2) 고개를 숙여 한 발짝 전진합니다.출처 : 구글 이미지 검색프로젝트가 끝날 때 까지 위의 두 가지 과정만을 반복하려고 합니다. 저는 이 과정을 baby step이라고 하는데요. 욕심내지 않고 작게 작게 한 번에 하나씩 차근차근 진행하는 방식입니다. 지금 내 딛은 한 걸음이 틀릴 수도 있습니다. 그러나 괜찮습니다. 한 걸음 나아간 다음에는 반드시 고개를 들어 내가 북극성과 가까워졌나 멀어졌나 확인하면 되거든요. 방향이 맞다는 판단이 서면 한 걸음 더 나아가고 틀린 예감이들면 방향을 조절하면됩니다. 만약 판단이 애매하면 더 끌리는 쪽을 택하면 됩니다. 단, 절대 바닥만을 주시한채 두 걸음 이상 걷지 않습니다.devops까지 도달하는 데 지름길은 전혀모릅니다. 하지만, devops라는 북극성은 저에게 명료하고 분명한 목표입니다. devops에 조금이라도 가까워지기 위해 지금 당장 해야하는 가장 중요한 일이 무엇인지 세미나를 진행하면서 그리고 세미나를 돌아보면서 치열하게 고민했습니다. 그렇게 집중하고나니 당장해야 하는 일 3가지는 다음과 같았습니다.(1)코드리뷰(2)테스트코드 작성(3)이슈 관리 프로세스이 세 가지의 일이 정답이 아닐 수 있습니다. 정답인지 아닌지는 얼마간 시간이 흐른 후에야 알 수 있겠죠? 다만, 저희는 늘 저희가 하던 방식대로 용기를 갖고 baby step을 무던히 수행해 나갈 것입니다. 다음화는 위의 세 가지 일을 진행하면서 겪은 시행착오를 공유해 보도록 하겠습니다.긴 글 읽어 주셔서 고맙습니다.#스위쳐 #Switcher #DevOPS #데브옵스 #개발자 #개발 #개발문화 #디버깅 #버그수정 #인사이트

EOS Smart Contract 를 위한 준비와 토큰 발행 그리고 C++를 활용해 토큰의 간단한 기능을 개발해 보겠습니다.환경 구성 및 지갑 생성은 SAM 님의 아래 2글을 참고해 주시기 바립니다.EOS — 설치 및 실행 (1/2)EOS — 동작구조 및 환경설정(2/2)지갑 생성하기SAM 님의 포스트를 참고 하셨다면 아마 다음과 같이 ‘default’ (별도의 이름을 지정하지 않았을 시) 지갑을 생성 하셨을 겁니다.이 지갑을 사용하여 계정을 Create 한 후 Key 를 Import 하겠습니다.Key 생성하기$ cleos create key위 명령을 실행 하시면 다음과 같은 화면을 얻을 수 있습니다.create key 명령의 결과**주의 : Private Key는 Public Key의 소유를 증명하는 중요한 개념으로 절대 타인에게 노출하면 안됩니다.AdditionalKey 생성 후 지갑에 import 하기 귀찮으시다면 생성된 지갑에서 바로 Key 를 생성하셔도 됩니다.$ cleos wallet create_key위와같이 key가 생성 됩니다. 하지만 public key 만 보이기 때문에 하단 명령 입력 후 지갑 key를 입력하면 private key를 확인할 수 있습니다.$ cleos wallet private_keys지갑에 Key import하기지갑은 Public Key — Private Key를 저장하는 저장소 입니다. 생성된 키를 지갑에 저장하기 위해 다음과 같은 명령어를 입력합니다.$ cleos wallet import-n : 옵션을 사용하면 지갑의 이름을 지정합니다. 지정하지 않는다면 기본 생성된 default 지갑으로 지정됩니다.위 명령을 입력 하면 key 가 임포트 되었다는 결과를 확인 할 수 있습니다.** 만약 지갑을 Unlock 한 상태가 아니라면 ‘private key: Error 3120003: Locked wallet’ Exception 이 나옵니다.unlock 을 위해 다음 명령을 실행한 후 wallet 생성시 저장했던 Key를 입력하여 Unlocked 상태로 만들어 줍니다.$ cleos wallet unlock password: Unlocked: default(Optional) 지갑에 저장된 Key 리스트 확인다음 명령어를 입력하여 지갑에 key 가 잘 import 됐는지 확인합니다.$ cleos wallet keys계정 생성eosio.token 이라는 이름으로 계정을 생성하도록 하겠습니다.** 지갑과 Key 그리고 계정에 관해서는 Hexlant 미디움에 게재될 예정입니다.$ cleos create account eosio eosio.token EOS63kstp8kthzJY3rAotp1LAxUDbWk4MywReG578R2ddbktrDHYKcreator : eosioaccount name : eosio.tokenowner key : 지갑에 import 된 keyAdditional본 포스팅은 local 환경에서 빌드 후 System Contract 들이 적용되지 않은 상황을 가정하였습니다. 만약 Public Network 환경에서 접속 시 eosio 와 eosio.token을 사용할 수 없습니다.또한 계정이름은 다음과 같은 규칙을 따릅니다.- 12문자- 12345abcdefghijklmnopqrstuvwxyz 만 사용 가능** 만약 ‘Error 3090003: provided keys, permissions, and delays do not satisfy declared authorizations’ 에러 발생 시 eosio 에 대한 key 를 지갑에 import 해야 합니다.eosio 에 대한 정보는 다음과 같습니다.public key: EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CVprivate key: 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3위 과정을 모두 마쳤다면, EOS 지갑과 키 그리고 계정에 대한 권한을 모두 가지고 있는 상태가 됩니다. 다음 포스팅에서는 이 계정을 사용 하여 Token 을 발행하는 방법을 알아보도록 하겠습니다.감사합니다#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심

Kafka 도입 이후에 점진적으로 모니터링을 개선해나간다. Kafka와 그 제반 환경에 대해 이해한만큼 모니터링을 구성하고 모니터링 시스템에서 피드백을 받아 다시 학습하고 그렇게 배운 것을 토대로 다시 모니터링을 구성한다. 그 과정을 따라 나가며 Kafka 를 어떻게 모니터링하면 좋을지 알아보자.프로세스 모니터링아무래도 가장 기초적이면서 중요한 지표는 Kafka 프로세스가 잘 살아 있는지 확인하는 것이다. 다섯 대로 구성한 클러스터라면 상시 Kafka 프로세스가 확인되어야 한다. 만약 Kubernetes의 StatefulSet으로 Kafka 클러스터를 구성한 경우라면 Kafka 프로세스 다섯과 프로세스 모두를 엮는 서비스, 그러니까 로드밸런서 하나를 포함해 총 여섯 개의 프로세스를 확인해야 한다. DataDog(통칭 멍멍이)을 이용해 모니터링하는 경우라면 다음과 같이 설정하면 된다.Monitoring Kafka ClusterKafka는 Zookeeper를 이용하므로 ZooKeeper 역시 동일하게 모니터링하면 된다.DataDog을 이용한 메트릭 모니터링`dd-agent는 Kafka 관련 메트릭을 Broker, Consumer, Producer 세 측면에서 수집한다.Monitoring Kafka with DatadogMonitoring Kafka performance metrics위의 두 문서가 Kafka 모니터링의 상세한 측면을 기술하는데 멍멍이를 이용하지 않더라도 꼭 한번 읽어볼만하다. 두 문서가 매우 훌륭하므로 이 글에서는 Kubernetes 환경에 초점을 맞춰 주목할 점만 살펴본다.Kubernetes 환경에서 멍멍이 에이전트는 보통 PetSet으로 구성한다. 말인즉 Kubernetes Worker 한 대마다 에이전트를 한 대씩 띄워서 Worker 안에서 작동하는 모든 도커 인스턴스의 메트릭을 수집한다. 일단 에이전트를 설정하고 나면 아래와 같이 Kafka 모니터링이 정상 작동하는지 확인하면 된다.kube exec -it dd-agent-17vjg -- /opt/datadog-agent/agent/agent.py info kafka ----- - instance #kafka-kafka-0.broker-9999 [OK] collected 46 metrics - instance #kafka-kafka-1.broker-9999 [OK] collected 46 metrics - instance #kafka-kafka-2.broker-9999 [OK] collected 46 metrics - Collected 138 metrics, 0 events & 0 service checks Emitters ======== - http_emitter [OK]Broker의 경우는 설정하기가 비교적 쉽다. Kubernetes에서 Kafka 같은 Stateful cluster는 StatefulSet으로 구성하게 되는데 이때 호스트 주소가 kafka-0, kafka-1 같이 예측 가능한 이름으로 정해지기 때문에 kafka.yaml을 미리 작성해두기 쉽다.instances: - host: kafka-0.broker port: 9999 # This is the JMX port on which Kafka exposes its metrics (usually 9999) - host: kafka-1.broker port: 9999Producer와 Consumer 모니터링은 이와는 다르다. 구현하기 나름이지만 Producer 또는 Consumer가 되는 응용프로그램은 Stateless cluster일 때가 많고 그런 경우에는 Kubernetes에서 Deployment로 클러스터를 구성한다. 이때는 StatefulSet인 경우와 달리 호스트 주소가 worker-903266370-q3rcx와 같이 예측하기 힘들게 나오므로 에이전트에 미리 설정을 넣을 수가 없다. 상당히 까다로운 문제이다.Consumer 모니터링Kafka의 설계는 매우 단순하면서도 강력해서 감탄하곤 한다. 하지만 복잡한 문제를 단순하게 풀어냈다고 해서 이를 둘러싼 환경을 제대로 모니터링하는 것도 쉽다는 뜻은 아니다. 특히 Consumer groups이 제대로 제 몫을 하고 있는지 파악하기는 더 어렵다. Consumer group마다 모니터링 체계를 갖추자니 번거롭다. 게다가 그런 번거로움을 극복하더라도 Kafka에 문제가 있는 경우를 탐지하기는 여전히 어렵다. 예를 들어 Consumer에게 가야 할 메시지 중 5%가 실제로는 전달되지 않는다 하면 이를 Consumer가 알기는 어려울 것이다. 이 외에도 Consumer 측 모니터링이 엄청나게 까다로운 문제임은 Burrow: Kafka Consumer Monitoring Reinvented에서 잘 밝혔다.Burrow: Kafka Consumer Monitoring Reinvented에 등장하는 Burrow는 Kafka를 세상에 내놓은 LinkedIn 엔지니어링 팀이 개발한 Kafka 컨슈머 모니터링 도구이다. 커뮤니티에서는 대체로 현존하는 가장 뛰어난 모니터링 도구라고 인정하는 분위기이다. 그러니 다른 도구도 많지만 우선 Burrow로 모니터링을 강화하기로 한다.Burrow로 Consumer 모니터링하기Burrow는 Dockerize가 잘 되어 있기 때문에 사용하기 어렵지 않다. LinkedIn이 공식 도커 이미지까지 제공했더라면 더 좋겠으나 GitHub에 Dockerfile과 docker-compose.yml을 올려놓아서 도커를 잘 아는 사람이라면 큰 어려움 없이 바로 설정하고 설치할 수 있다. 컨테이너 환경의 관례대로 주요 설정을 환경변수로 미리 빼놨으면 더 좋았겠지만 …알람 받기Burrow는 문제가 생겼을 때 알람을 발송하는 기능이 있다. 위키에는 이메일 알람과 HTTP 알람(Webhook)을 어떻게 설정하는지 설명한다. 그런데 Burrow 소스코드를 살펴보면 문서화되지 않은 알람 기능도 있으니… 바로! Slack 알람을 제공한다. 아직 공식 문서가 없고 소스코드도 godoc 관례에 맞춰 설명해놓은 부분이 전혀 없기 때문에 소스코드를 읽거나 GitHub 이슈에서 논의된 내용을 토대로 설정해야 한다.[slacknotifier] enable=true url=https://hooks.slack.com/services/xxxx/xxxxxxxxxx group=local,critical-consumer-group group=local,other-consumer-group threshold=0 channel="#general" username=burrower interval=5 timeout=5 keepalive=30멍멍이로 메트릭을 꾸준히 수집하고 이슈가 생겼을 때 알람을 받고자 한다면 packetloop/datadog-agent-burrow를 이용하면 된다.This plugin will push the offsets for all topics (except the offsets_topic) and consumers for every kafka cluster it finds into Datadog as a metric.멍멍이 에이전트에 필요한 파일과 설정을 넣고 나면 아래와 같이 메트릭이 수집된다.kafka.topic.offsets 와 kafka.consumer.offsets 이렇게 두 개의 메트릭만 수집하지만 각 메트릭을 cluster, topic, consumer 세 개의 토픽으로 세분화하기 때문에 실제로는 꽤 다양한 지표를 멍멍이에서 확인하고 이용할 수 있다.알`람 설정하기앞서 살펴봤지만 프로세스 모니터링 등은 어렵지 않다. 클러스터에서 한대라도 빠지면 바로 알람을 받는다. 끝!하지만 그 외의 지표는 알람의 기준을 설정하기가 힘들다. 예를 들어 Burrow의 kafka.topic.offsets 값이 600이면 정상인가? 그렇다면 700은? 또는 400은? 도무지 감을 잡을 수가 없다. 이럴 때는 멍멍이가 제공하는 Outlier detection기능으로 알람을 걸면 쉽다. 이 기능은 쉽게 말해 평소와 다른 행동을 감지했을 때 알람을 보낸다. 그러므로 정상의 범위를 확실하게 모를 때 아주 유용하다.설정 자체는 DBSCAN 또는 MAD라는 알고리즘이 등장하는 것만 빼곤 여타의 모니터링과 다르지 않기 때문에 매우 쉽다.참고 문헌How to Monitor KafkaCollecting Kafka performance metricsOriginally published at Andromeda Rabbit.#데일리 #데일리호텔 #개발 #개발자 #개발팀 #인사이트 #기술스택 #스택소개 #Kafka

오늘 만나본 앵커리어의 팀원은!바로 앵커리어의 숨겨진 하드캐리어 개발자 노선빈(a.k.a 메-쓰:수학)군 입니당!컴퓨터와 대화하는 것을 가장 좋아하는 줄 알았던 그와인터뷰를 빌미로 오랜시간 이야기를 나누었습니다!그 결과... 의외로 수다떨기를 좋아하는 타입의 선빈씨!(나 촉 되게 좋아~~~ 선빈씨 다 들켰어~~~)그럼 앵커리어랩 네번째 인터뷰 시작합니다!(ps. 내일(10월 13일)이면 예비군을 떠나시는 선빈씨에게 이 포스팅을 바칩니다! 예비군 화이팅!)INTRO. 인사밍케터) 간단한 자기소개 부탁드려요^^메-쓰) 자기소개? 이럴 수가.어려워요. 아무렇게나 하면 되나요? 양식이..? 음….팀에서 개발을 하고 있으며, Front-end를 맡고 있고, 아주 약간의 Back-end를 맡고 있습니다.밍케터) 임하는 각오는요?메-쓰) 각오는… 각오라기보다는 지금의 마음 상태가 무섭네요.밍케터)) 마케팅팀이 무서우신 건가요?!메-쓰) 아니 아니 아닙니다.인터뷰가 무서운 거죠.아시다시피 저는 말을 많이 하는 사람이 아니라서. 이런 자리가 익숙하지 않죠. 제1장. 안경_★po코딩wer★밍케터) 하시는 일 소개 부탁드려요.메-쓰) 앵커리어에서의 저의 업무!위에서 한 것 같지만, 다시 하죠. 조금 더 구체적으로.웹 사이트를 만들고, 페이지를 구성하는 일을 합니다.디자이너께서 결과물을 만들어 냈을 때,실제로 웹 사이트를 그렇게 보이게 만드는 일을 하고 있습니다. 밍케터) 선빈 씨는 코딩 언제부터 시작하셨나요?메-쓰) 음. 그게 초 6 때죠.대표께서 초 5 때부터 혼자 코딩을 했었어서, 근데 제가 친구 였어서, 저를 꼬셔서,'같이 해보지 않을래?' 해서 하게 됐죠?(선빈씨 음성지원 中)6학년 때 정보 올림피아드 나가고 하면서 컴공과에 가서 프로그래머를 해야겠다라고 생각했었는데, 고등학생때 수학이 재미있어서 물리학과로 진학했습니다.그런데 올해 초에 새해를 맞아 오랜 친구인 대표께 전화를 했는데, ‘새해 복 많이 받아라’라는 말씀과 함께 '개발자 필요한데 같이할래?' 이러셨죠.그래서 올해부터 갑자기 다시 직업으로 삼게 되었습니다.   밍케터) 공백기가 길었는데 감을 잃지는 않으셨나요?메-쓰) 예전이랑 컴퓨터 언어도 다르고 분야도 달라서 “완전 능숙해” 이 정도는 아닙니다.밍케터) 코딩이 가장 즐거운 순간은 언제인가요?메-쓰) 1. 버그 없이 잘 돌아갈 때.2. 어떻게 해야 할지 바로 떠올랐을 때.3. 알 수 없는 버그가 날 괴롭히지 않을 때.밍케터) 물리 vs 코딩. 어떤 것이 더 재미있나요?메-쓰) 물리가 재밌습니다…아 각각의 재미가 다르죠(다급).물리는…..네이쳐를 알아가는 것은 흥미롭잖아요? 안 그렇습니까?밍케터) (.....전 아닌 것 같습니다만….)메-쓰) 개발은 문제를 해결해 나가는 재미가 있습니다. 이런 방식으로 하고 싶은데 이럴 때는 어떻게 해야 할까 같은 문제들이요. 둘 다 재미있습니다. 흥미롭죠. 밍케터) 게임 좋아하신다고 하던데, 인생게임 있나요?메-쓰) 인생게임이라…. 도타라는 게임이 있는데, warcraft3 라는 게임의 mod 같은 건데…밍케터) 그럼 이 인터뷰는 어떠세요? 핵심을 찔러서 평가해주세요.메-쓰) 분위기는 좋습니다. 굉장히 자유롭네요. 자유분방. 편한 분위기. 밍케터) 모드요? 모드…???메-쓰) 스타크래프트를 해봤으면 유즈맵이라고 하면 딱 아실텐데… 뭐 어쨌든.DOTA(‘디-오-티-에이’라고 친절하게 풀어서 읽어주는 선빈 씨)라는 게임이 있습니다. 지금 롤과 같은 장르의 AOS의 시초가 된 게임입니다. 밍케터) 가장 자랑하고 싶은 코딩 결과물 알려주세요.메-쓰) 없으면 안 되는 거죠?밍케터) 웬만하면 있으시면 좋겠습니다.메-쓰) 제가 솔로로 만든 것 중에 ‘오 굉장해. 오 훌륭해’ 이런 것은 없고, 참여한 것 중에 훌륭한 것은 지금 만든 자소설닷컴이죠?개인 작업물 중에 생각나는 것은…예-엣날에 코딩 처음할 때. 야구게임이라고 아시나요?야구게임 프로그램 예시(feat.다른 개발자).jpg고1 때 굉장히 유행했는데 옛날에 하던 코딩이 생각나 심심할 때 만들어서 학교에서 풀었죠.사실 코딩하는 사람들이 보면 굉장히 별거 아닌데 학생들이 “오 신기해. 쩔어. 있어보여” 이랬던 기억이 나네요. 밍케터) 대표님과 친구인지 얼마나 되셨죠?메-쓰) 18년 이죠.밍케터) 네 그리고 초, 중, 고 계속 같이 다니셨고 한 공간에서 코딩하시고...혹시 라이벌 의식…?메-쓰) 아, 전혀 없습니다.저는 예전부터 라이벌 의식 뭐 이런 것을 가져본 적이 없어서. 좀 있었어야 할 것 같은데.밍케터) 근데 굳이 필요가 없어 보이네요. 다 잘하시니까…알아서 좋은 학교에 입학하시고...(...조용히 먼 산을 바라보며 반성하는 마케터들)제2장. 입_난 핵심만 찌른다밍케터) 팀원들이 선빈 씨에 대해 핵심을 찌른다는 평가를 했습니다. 혹시 본인만의 남다른 기준이 있으신가요?메-쓰) 팀에 합류했을 때, 대표님이 저에게 날카로운 평가를 많이 기대하는 것 같았는데... 합류하고 보니 이미 굉장히 잘하는 분이 있으셔서. (조용히 pm님을 쳐다본다.) 서로 뿌듯해하는 하드캐리어들.jpg메-쓰) 하드캐리어 이십니다. 굉장히 날카로운 분이세요.상위 호환이 가능합니다.밍케터) …...네? 상위호환이요? 그게 뭐죠?메-쓰) 음…..밍케터)(상위호환을 이해하지 못하는 것은 나의 잘못일까, 선빈씨의 잘못일까, 고급언어를 사용할 줄 아는 능력의 차이인가….또 다시 먼 산을 바라보는 밍케터...)메-쓰) 여기저기서 쓸 수 있는 성격이라는 말입니다. 더 나으신 분이죠.상위 호환이 가능한 pm님) 선빈씨 시사잡지도 계속 주기적으로 사서 보시잖아요?메-쓰) 주기적이진 않지만 내킬 때…?상위 호환이 가능한 pm님) 주변에 보면 시사 잡지를 구독하는 이공계생을 본 적이 별로 없어요.시사에 관심이 많으신가요? 나아가서 정치 사회적인 부분까지 관심이 많으신가요?메-쓰) 음, 관심이 없진 않죠. ...왜 관심이 생겼을까요?시사주간지는 딱히 주기적으로 사진 않지만 내킬 때 사는데...지하철 편의점 지나다니다 보면 ‘이번 주는 저런 이슈가 있군.. 사볼까?’ 이럴 때 삽니다.뭔가 인생, 삶에 있어서 충실함이 떨어지거나 나태함이 차오를 때?열심히 사는 사람의 느낌을 낼 때 사는 것 같네요.밍케터) 그럼 이 인터뷰는 어떠세요? 핵심을 찔러서 평가해주세요.메-쓰) 분위기는 좋습니다. 굉장히 자유롭네요. 자유분방. 편한 분위기.제3장. 피카츄_개발팀의 핵심멤버밍케터) 선빈 씨 방에는 피카츄 친구들이 많잖아요? 혹시 피카츄가 최.애.캐(최강 애정 캐릭터)인가요?메-쓰)  캐릭터로 말할 것 같으면... 딱히 딱 떠오르는 것은 없습니다.밍케터) (당황… 최.애.캐인줄 알고 질문을 준비했는데…!)메-쓰) 피카츄는 포켓몬에서 상품 제작이 많이 되고 프로모션이 많잖아요?그래서 가보니까 귀여워서 사온거죠.밍케터)그럼 질문을 좀 바꿔서 드립니다.만약 살아있는 피카츄를 얻을 수 있다면 대표님과 피카츄 중 누구를 선택하시겠어요?세상에 단 하나 뿐이고, 100만 볼트도 쓸 줄 아는 피카츄라면?그런데 살아있는 피카츄를 얻으려면 대표님과 연을 끊어야 한다면?메-쓰) 이게 직장이 걸린 문제라서 다른 직장을 찾을 수 있는가가 문제인데요.밍케터) 그럼.. 대표님 자리에 앉아서 일하다가 퇴근할 때면 고개를 돌려 “피카!!!”하고 인사를 해주는 피카츄라면요?퇴근하는 직원들에게 인사하는 대표님_피카츄.jpg상위 호환이 가능한 pm님) 전 피카츄요.인터뷰 당일 대표님께 명품 벨트를 선물받은 문케터 ) 아 저도 피카츄로 하겠습니다. (대표님보다 피카츄)메-쓰) 음… 대표님이 양산에서 잘 살고 계시는 상태에서 연을 끊는 거라면…. 제4장. 마요 시리즈_에너지의 원천밍케터) 선빈 씨의 점심엔 항상 빠지지 않는 것이 있습니다. 한솥 마요네즈 시리즈.특별히 좋아하시는 이유가 있나요?메-쓰) 좋아해서가 아니라 싸서 먹고 있습니다.밍케터) (당황… 마요 시리즈를 좋아하는 줄 알고 질문을 준비했는데…이 인터뷰 호락호락하지 않다)그래도 가장 베스트 마요 하나만 말씀해주세요.인터뷰 당일 대표님께 명품 벨트를 선물받은 문케터 ) 그러지 마요.메-쓰) (무시) 제가 먹어본 것들이 치킨, 치킨샐러드, 닭가슴살 샐러드 등이 있는데 다 그놈이 그놈입니다.재료가 아니라 마요 맛이에요.싼 것을 먹어야 돈을 모을 수 있으니까 싼 걸 먹는 거죠.그래야 건물을 사서 임대를 줄 수 있고 ‘난 이렇게 돈이 많은 남자다’ 이러면서 사치도 부리는 거죠.빅치킨마요를 사 먹는다던가.밍케터) 그럼 우리 점심시간때 빅 치킨마요 사 먹는 분들은 선빈 씨 기준에서 사치 하는 사람이네요? ㅋㅋㅋㅋㅋ인터뷰 당일 대표님께 명품 벨트를 선물받은 문케터 ) 주연 씨? ㅋㅋㅋㅋㅋ상위 호환이 가능한 pm님) 선빈씨 “쟤는 건물 있나?”이러겠네요. ㅋㅋㅋㅋㅋ메-쓰) 최신게임도 풀 옵션으로 돌리고, 뭐 농담이고 돈 많으면 좋잖아요?   밍케터) 평소 과자 간식, 마요 시리즈, 콜라 등등 고칼로리를 즐겨 드시는데 날씬한 몸매 유지 비결이 무엇이죠?메-쓰) 마요가 고칼로리인가요? 먹을 때 칼로리 생각 안 하는데, 왜 살이 안 찔까...많이 안 먹어서 그런 것 아닐까요?저는 사실 먹을 만큼 먹는데 옆에서는 잘 안 먹는다 이런 평이 있긴 하더라고요.메-쓰) 그리고 저는 신체와 관련해서 그런 것을 해보고 싶긴 해요. 마사지? 교정? 교정이겠네요.요가라던가. 필라테스?이것들을 하면 나의 오랜 신체 불균형이 좀 개선되지 않을까 이런 생각이 있습니다.어멋_뒷사람을 못가렸네.jpg  제5장. 키. 손. 팔. 속눈썹… 메이비 전신_가장 자신 있는 부위밍케터) 마지막으로 가장 자신 있는 부위 알려주세요.메-쓰) 부위? 신체? 허….글쎄요.저는 막 몸이 이렇게 자신있는 스타일은 아닌데…그런데 살면서 들어본 신체에 대한 칭찬이 몇 가지가 있는데.밍케터) 몇 가지? (분명 몸이 자신 있는 스타일은 아니라 해놓고 천역덕스러우시군) 메-쓰) 네 몇가지는 누구나 있죠.우선, 키가 크다. 근데 이건 부위라고 하기엔 뭐하네요.왠지 전신을 이야기하는 것 같아서. "너는 손이 이쁘네. 손가락이 이쁘네. 손톱이 이쁘네."이런 이야기도 좀 들어 봤구요. 팔이… 이건 칭찬인지 모르겠지만, "여자들이 원하는 팔 형태네." 아니면 "속눈썹이 기네."  상위 호환이 가능한 pm님) 맞아요. 선빈씨 속눈썹 꼭 찍어야 해. 진짜 길어요. 장난 아니죠.메-쓰) 중학교 때 부터 여자애들이 “어우 속눈썹 굉장하다.” 이런 이야기를 몇 번 들었습니다. 메-쓰) 추가로 다리가 길다 정도?결론. 앵커리어 공식질문 1. 나에게 앵커리어란?뭐. 직장이죠.2. 자소설닷컴을 한 마디로 표현하자면?뭐. 우리 회사 서비스죠.#앵커리어 #팀원소개 #인터뷰 #팀원자랑 #기업문화 #조직문화

맛있는 인터뷰 : 안드로이드 개발자(Android Developer) Gary 편집자 주잔디와 함께 하는 멤버는 총 35명. 국적, 학력, 경험이 모두 다른 이들이 어떤 스토리를 갖고 잔디에 합류했는지, 무슨 일을 하고 있는지 궁금해하는 분들이 많습니다. 잔디 블로그에서는 이 궁금증을 해결해 드리고자 ‘맛있는 인터뷰’를 통해 ‘잔디’ 멤버들의 이야기를 다루고 있습니다.인터뷰에서 가장 기초적인 질문. 예상하신 자기소개 부탁한다.G : 잔디 개발자 중 제일 어린! 핵심 키워드다. 강조 부탁한다. 가장 어린! 안드로이드 플랫폼 개발을 맡은 Gary다(이하:G). 잔디 입사한 지는 9개월 되었다. 특별한 일 없이 정말 열~! 심히 개발만 했다. 일주일 전부터 식당 선택을 강요(?)했다. 이 식당을 선택한 이유는 무엇인가?G : 음식이 푸짐하게 나오기도 하지만 조명이 좋다. 인터뷰 중 사진을 찍는다고 들었는데 그 사진이 예쁘게 나올 것 같아서 선정했다. 게다가 음식이 정갈하다. 안에 룸도 있어서 회식하기도 좋다. 내 입이 복잡하질 않아서 뭘 먹어도 다 맛있다. 어차피 다 맛있는 거 사진이라도 잘 나와야 한다 싶어서 선택하게 되었다. 잔디에 들어오게 된 계기는?G : 모집 공지가 뜨길래.. 농담이다^^; 전 직장과의 시스템이 다른, 자체 서비스를 하는 회사에 가보고 싶었다. 전 직장에서는 기획, 서버, 디자인, 개발을 각각 다른 회사에서 진행했다. 내가 속한 회사는 개발만 진행했다. 처음부터 끝까지 한 곳에서 서비스하는 회사를 가보고 싶었다. 또한, 기술 스택이 너무 좋았다. 이를 통해 앞으로 나의 실력이 일취월장할 수 있겠다는 생각이 들었다. 9개월 동안 많이 발전한 것 같은가?G : 상당히 많이 발전했다. 어떤 부분에서 발전한 것 같은가?G : 이전 회사에서는 일정에 쫓기다 보니 개발 자체에서 설계라는 게 없었다. 손 가는 데로, 일단 만들고 보자라는 식으로 신기술이고 뭐고 공장처럼 찍어내는 것이 일이었다. 하지만 잔디는 다르다. 2주 단위로 생각을 통해 설계도 해보고 ‘객체지향 설계 5대 원칙’ 등 다양한 사항을 고려해보며 많은 고민 끝에 개발하는 것이 너무 좋다. 이를 통해 개발자로서 더욱 성장한 것이 느껴진다. 이전 회사보다는 일찍 퇴근하는 편인가?G : 이전 회사는 철야, 야근 거의 매일 했다. 입사한 지 9개월 정도 되었는데 이제야 사람답게 사는 것 같다. 그동안은 짐승인 줄 알았다. 일어나면 출근하고 퇴근하면 자고. 9개월 동안 사람답게 살면서 잠도 푹 잤다. 몸이 편해지면 사람 얼굴이 확 산다고 하던데 생긴 건 나아지지 않더라. 옛말도 틀린 말이 있나 보다. (하하) 주말엔 뭐하시는가?G : 집돌이 성향이라 집에 있는 경우가 많다. 밖에 나가면 이웃 주민들과 소통하기도 한다. 지금 사는 곳은 취업한 지 얼마 안 된 사회초년생들에게 국가에서 주는 ‘행복주택’이라는 곳이다. 그곳엔 대부분 사회초년생이라 연령대가 20대 후반에서 30대 초반 정도 된다. 그분들과 소통을 하며 지내고 있다. 나이가 비슷하니 공감대 형성도 되고 행복주택에서 행사 같은 걸 많이 해서 문화생활 영위하는 듯하다. 말 그대로 사람 사는 듯한 느낌이다. 서울 집값이 너무 비싸다. 행복주택은 저렴한 편인가?G : 다른 원룸에 비교하면 저렴한 편이다. 보증금이 들어가지만, 월세는 10만 원 전후다. 서울에서 월세 10만 원 전후라면 저렴한 편 아닌가? 사회 초년생분들께 추천한다. 이웃들도 좋고 문화생활도 하고. 엄청나지 않은가? 신청 후 당첨이 되어야 하지만 당첨되기 쉬운 편이다. 꼭 한번 도전해봐라. 처음 들어왔을 때 잔디는 어땠는가?G : 사실 처음 들어왔을 때 사무실이 시끌벅적하며 소통이 아주 활발할 줄 알았다. 그런데 딱 들어오니 어?! 음? 오?!… 조용하다. 진짜 활발한 곳은 따로 있었다. 목소리가 아닌 손가락으로 얘기하는 곳. 잔디 앱이었다. 사무실 자체는 너무 조용한데 잔디 앱 안에서 매우 활발하다. 아이러니하지만 의사소통은 아주 활발했다. 잔디의 생활 중 가장 마음에 드는 문화는?G : 영어 이름을 사용하며 상호 간에 존중하는 문화다. 30년 동안 한글 이름으로만 살았는데. 회사만 오면 Gary라고 부른다. 첨엔 이게 날 부르는 건지도 잘 몰랐지만 익숙해지니 너무 좋다. 수평적인 관계의 시작이 무엇인지 알게 되었다. 이전 회사와는 다르게 잔디에서는 수평적인 관계여서 의견 개진이 편했다. 의견을 나눌 수 있다는 것이 너무 좋았다. 물론 손끝으로 얘기하지만:D 감정표현도 이모티콘으로 한다. 표정은 무표정이지만 손가락은 웃고 있달까? 내 얼굴은 무표정인데 프랑키 (파랑몬스터 캐릭터)가 웃어준다. 이젠 오프라인으로도 소통이 되었으면 한다. 사무실 밖에선 말이 많으신 분들인데. 사무실만 들어오면 조용하시다. 손으로 말하고 계시니까. (웃음) 회식은 자주 하는가?G : 팀마다 다른 것 같다. 팀 내에서 석 달 치 회식비를 모아서 한 번에 하던가 쪼개서 자주자주 하던가. 어차피 쓰는 돈은 같으니까. 이루고 싶은 꿈이 있다면?G : 백수가 되고 싶다. (비장) 충분한 불로소득이 있는. 소득과 상관없이 내 맘대로 살 수 있는 그런 백수가 되고 싶다. 회사를 가고 싶으면 회사를 가고 사업을 하고 싶으면 사업을 하는 그런 백수(하하). 사실 프로그래머로서 직업을 정했을 때는 최고의 프로그램을 만들어보는 게 꿈이었다. 또한, 안드로이드로 시작했으니 구글에서 종지부를 찍자! 이런 꿈을 꾸었다. 그런데 이전 직장이 너무 힘들었나 보다. 꿈이 변했다. 백수로. 하루는 7개월 정도 만에 칼퇴근하고 집에 갔더니 어머니께서. “너 잘렸냐?”라고 물어보시더라. 그땐 내 회사 생활에 문제가 있구나 싶었다. 백수는 아니지만 일과 삶의 밸런스가 맞는 삶을 살고 싶다. 다음 인터뷰어에게 하고 싶은 질문이 있나?G : 회사 내에 다른 팀원들과 지금 먹고 있는 음식을 같이 먹을 수 있다면 누구랑 같이 먹고 싶은가?#토스랩 #잔디 #JANDI #팀원소개 #인터뷰 #기업문화 #조직문화 #사내문화 #팀원자랑

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

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

올해 2월에 썼던 글을 이제야 올려봅니다. 태블로는 아직 잘 사용하고 있습니다. : )“아무개 님, 지난번에 요청한 자료 언제까지 받을 수 있죠?”다행이다. 꿈 이었다.가벼운 발걸음으로 출근하던 중 일감 하나가 떠오른다. 간밤의 꿈이 꿈 만은 아니었던게다.아뿔싸, 아직 시작도 못했는데.오늘 할 일을 내일로 미룬 자의 아침은 발걸음이 무겁다.Business Intelligence 라는 것이 있다. 뭔가 멋드러진 단어의 조합처럼 보이지만, 현실은 그리 아름답지 않다. 대부분의 시간을 비슷한 일을 반복하며 숫자를 맞춰야하고 엑셀과 SQL 에 빠져 살기 일쑤다. 잘못된 데이터라도 발견되면 이걸 어디서부터 수습해야 하나 고민해야 한다. (끝이 없는 재귀호출)반복, 반복, 반복. 비용을 줄이자.반복은 비용이다. 한두번 반복되는 일을 최적화 하는 것은 최적화 자체가 비용 이겠지만, 매일같이 반복되는 일, 주기적으로 찾아야 하는 데이터들은 그 자체만으로도 최적화의 대상이다.특히나, 아직 성장하고 있는 ‘스타트업’ 이라면 회사의 데이터가 잘 정리되어 있을리 만무하다. 몇몇 데이터는 잘 관리되고 있겠지만, 상당수는 흩어져 있을 것이다. 어느 순간을 지나면 이들을 모으는 게 일이 되어버린다. 임계점을 넘어서버린 일을 한다는 것은 손을 더럽히는 일이 된다는 뜻이기도 하다. 아무쪼록 그대에게 이 임계점을 분간할 지혜가 있기를.시간 비용을 절약하자스타트업의 구성원들에게 가장 중요한 것은 무엇일까? 나의 짧은 생각으로는 사람과 시간이라고 생각된다. 이 중에서 BI 툴이 해결해 줄 수 있는 것은 무엇일까?나 스스로에게 질문해보니 이런 답이 나온다. ‘사람은 쉽게 바뀌지 않는다’ 그럼 시간은? 다행히, 시간은 모두에게 공평하게 주어진다.‘그럼 이 시간을 아껴보자!’여기에 하나 더, 내가 모르는 것이 있었다.앞으로 회사가 데이터를 다루는 스펙트럼을 얘상할 수 없다는 것이다.Zeppelin무엇을 사용할까 고민하던 중 가장 먼저 떠오른 것은 다름 아닌 제플린 이었다.< 이 형님들 말고 >(출처 : http://fortune.com/2016/07/26/led-zeppelin-stairway-heaven-appeal/)아파치 제플린은 한국에서 시작해 아파치 인큐베이터에 들어간 오픈소스 데이터 분석 및 시각화 툴 이다.장점은 개발자에게 익숙한 노트북 기반이라는 것과 강력한 인터프리터를 통해 다양한 데이터 소스에 접근할 수 있다는 것이다.나프다 팟캐스트에서 들은 내용인데, 트위터의 경우 태블로에서 제플린으로 갈아탔다는 이야기도 있었다.기본적으로 프로그래밍이 가능하기 때문에 어떤 형태의 데이터를 요구해도 제공할 수 있다는 장점도 있다.물론, 단점도 있다. 먼저 시각화 부분이 약하다는 것이다. D3.js 를 같이 사용하면 보완할 수 있지만 개발자의 꾸준한 지원이 있어야 할 것이었다.더불어, 비개발자들에겐 노트북 형태로 데이터를 가공하는 것에 진입장벽이 있다고 생각 했다.한번쯤 사용해보고 싶었지만 개발 리소스가 부족한 우리 상황에는 맞지 않다고 생각했기에 다음을 기약해본다.Spotfire, Amazon Quicksight, Google Data Studio다음으로 찾아본 툴 들은 바다 건너에서 잘 사용 되는 몇가지 것들 이었다.Spotfire 는 레퍼런스도 충분했지만 다음에 등장한 강력한 후보로 인해 제외됬다.아마존 퀵사이트는 잠깐 사용해봤지만 회사의 요구사항을 맞추는데 부적절해 보였다.구글의 데이터 스튜디오 역시 기능에 제약이 많았다.아마존과 구글의 솔루션은 무료로 사용할 수 있거나 가격이 합리적이라는 장점도 있었다.Spotfire 역시 비싸지 않은 가격이었다.태블로, 그리고 plotly태블로는 동료 직원의 지인 중 사용해본 분이 있어서 직접 만나서 여러가지를 물어볼 수 있었다. 나중에 알았지만 한국에 공식 총판이 있어서 메일로 문의하면 다양한 안내를 받을 수 있었다.태블로는 장점이 많은 툴이다. 다양한 데이터 소스를 지원하며, 강력한 시각화를 통해 데이터를 분석할 수 있다.데이터를 유연하게 다룰 수 있어서 여러가지 인사이트를 얻는데 도움을 줄 것이라 생각됐다.온라인 튜토리얼도 잘 되어있고, 한국에서 오프라인으로 기초교육도 받을 수 있다.종합적으로 비교해 본 결과 비슷한 성격의 툴 중에선 가장 강력한 툴 이었다.유일한 단점이라면 가격이다.plotly 는 리서치 중 가장 마지막으로 접했는데 대시보드로도 사용할 수 있고 노트북에도 붙일 수 있는 라이브러리 형태로 제공되는 툴 이었다.데이터 분석에 주로 사용되는 파이썬, R, 매트랩에 모두 사용 가능했고 훌륭한 시각화도 가능했다. 학생이라면 아주 저렴한 가격으로도 이용이 가능하다.단점이라면, 개발자에게 더 친화적 이라는 것과 데이터 커넥터가 태블로에 비해 부족하다는 것 이었다.BI 툴, 개발자와 분석가 중 누구에게 더 쉬워야 할까?회사마다 개발자의 비중이 다르다. 스타트업 이라고 해서 개발자들로만 이루어진 것도 아니고, 이미 안정적으로 비즈니스를 운영하는 회사라고 해서 개발자가 적은 것도 아니다.각 회사가 처한 상황에 따라 어떤 툴을 사용할 지는 다를 것이다.나는 우리 회사가 어떤 BI 툴을 써야 최적일지 생각해 봤다.같은 작업을 하는데 있어서 시간을 줄여줄 수 있어야 하고, 앞으로의 변화에 유연하게 대응할 수 있는 툴이었으면 했다.개발자의 지원을 최소화 하면서 비즈니스를 이해하는 분들이 적극적으로 사용하는데 어려움이 없었으면 했다.가격적인 면도 중요했지만, 국내에서 사용하는데 참조할 수 있는 레퍼런스, 교육이 풍부한 것도 선택에 한 축이 되었다.모든 것을 종합해 본 결과 태블로 만한 것이 없다고 생각됐다.< 이제 데이터와 사랑에 빠져 볼까? >(출처 : https://www.youtube.com/watch?v=2onPdVj5zgQ)여러분들의 상황은 어떤가.지금 사용중인 툴이 충분한 효과를 가져다주고 있는가? 혹시 기존에 익숙하던 것을 습관적으로 사용하고 있지는 않나?대부분의 스타트업은 부족한 인원으로 복잡한 이슈를 해결하기 위해 고군분투 중일 것이다.특별히, 데이터를 들여다보고 최적화를 해야하는 업무를 담당하는 사람이라면 지금 이 순간도 머리를 싸메고 고민에 빠져 있을 것이라 생각된다.데이터 때문에 잠이 부족한 그대에게, 비슷한 고민을 하는 분들에게, 아무쪼록 이 글이 조금이나마 도움이 되었기를 바란다.#8퍼센트 #에잇퍼센트 #협업 #업무프로세스 #팀워크 #수평적조직