개발자는 도대체 어떻게 되는 거고 누가 되는 거야?코드스테이츠가 가장 많이 받아온 질문 중 하나입니다. 그래서 준비한 특급 연재! 개발자 커리어 전환기! 매주 Immersive를 수강하고 있는 수강생 한 분과 인터뷰해서 어떻게 개발을 시작하게 되었는지, 또 현재 무엇을 배우고 있는지에 대한 인터뷰를 포스팅하려고 합니다.아무것도 모르는 비전공자 출신 분들이(물론 전공자 분도 계십니다!) 개발자가 되어가는 과정을 생생하게 보실 수 있습니다. 그럼, 첫 번째 포스팅의 주인공 이야기를 시작하겠습니다.코드스테이츠 코딩 부트 캠프, Immersive 6기 과정이 시작되었습니다. 지난 5기 데모데이를 들뜬 마음으로 지켜보던 Pre-course 수강생들이 어느덧 새로운 Immersive 과정의 주인공이 되었는데요.오늘은 하드웨어 개발자 출신으로서 커리어 전환을 위해 코드스테이츠를 찾아온 6기의 전한길님을 만나봤습니다. Q) 한길님 반갑습니다. Precourse 수료를 축하드리며 간단한 자기소개 부탁드려요.- 안녕하세요! 전한길입니다.Q) 정말 간단하네요! 보통은 인터뷰어를 위해 좀 더 길게 합니다만...- 아... 전 대학에서 전자공학을 전공했고요. 어쩌다 보니 전자회로 설계일을 하게 되었어요. 원래는 소프트웨어 쪽에 관심이 있었는데 하드웨어 쪽으로 일을 했습니다. 사실, 당시에는 집 가까운 회사를 찾다보니..(웃음) 어쨌든! 커리어 전환을 위해 코드스테이츠에 오게 되었습니다.Q) 원래 이쪽에 관심이 있으셔서 소프트웨어 엔지니어로 커리어 전환을 하시는 건가요?- 자신만의 기술을 가질 수 있다는 점이 좋아서 소프트웨어 엔지니어를 하기로 결심했어요. 저는 회사생활을 6년 동안 했는데요. 하루하루 똑같은 업무와 일상이 지루하더라구요. 직급이 올라간다고 해서 더 나아질 거 같지도 않았고...사실 깊이 생각하는 성격이 아니에요. 무작정 회사를 나와서 고민했죠. 그러다가 "나만의 기술을 가질 수 있는 매력적인 직업을 갖자"는 저만의 원칙을 고수한 끝에 소프트웨어 엔지니어가 되기로 결심했어요.Q) 그러면 특별히 코드스테이츠를 선택하신 이유가 무엇인가요?- 처음에는 국비지원과정도 알아봤어요. 국비지원과정에서 공부를 할까 하다가 우연히 친구 소개로 코드스테이츠를 알게 되었죠.'자기 주도적 학습'이라는 단어에 끌렸어요. 전 코딩이 언어랑 비슷하다고 생각하거든요. 문법을 잘 안다고 영어를 잘하는 건 아니잖아요. 아는 것도 중요하지만 습관이 중요하다고 생각해요. 지름길을 가면서 스스로 코딩을 많이 해볼 수 있을 거 같아서 코드스테이츠를 선택하게 되었죠.코딩은, 아는 것도 중요하지만 습관이 중요하다고 생각해요Q) 이건 개인적으로 매우(?) 긴장되는 질문인데, 실제로 Pre-course는 어땠나요?- 코드스테이츠 학습 방식 자체가 강의식이 아니다 보니 생각한 대로 '자기 주도적 학습 위주'고, 특히 실제로 코딩을 많이 해봐서 좋았어요.그리고 위에서 얘기한 것처럼 저는 지름길이 필요했는데요. 방향을 잘 잡아주셔서 좋았어요. 단계별로 공부할 수 있는 내용이 잘 정리되어있더라구요. 시간을 효율적으로 쓸 수 있었습니다.Q) 담당자로서 매우 뿌듯한 답변이네요. :) 특히 어떤 프로젝트가 가장 기억에 남나요?- *twittler 를 만들었을 때가 가장 기뻤어요. 뭐라고 말로 표현하기는 어려운 감정인데, 실제로 눈에 보이는 걸 만들었을 때 성취감이 크더라구요. 그 성취감이 동기부여가 되어서 더 열심히 했던 거 같습니다.*twittler: 코드스테이츠 Pre-course과정에서 수행하는 프로젝트로, 트위터의 일부 기능을 구현한 프로그램한길님이 구현한 twittlerQ) 이제 막 Immersive 과정이 시작되었는데요. 과정에서는 어떤 걸 기대하나요?- 코드스테이츠의 체계적인 커리큘럼과... 웹 개발자로 취업하는 거??Q) 교과서 같은 답변이네요.^^ 3개월 뒤면 웹 개발자가 되어있을 거라고 믿습니다. 그렇다면 어떤 개발자가 되고 싶나요?- 기술을 잘 아는 개발자가 되고 싶어요. 개인적으로 호기심이 많아요. 블록체인부터 빅데이터까지.. 새로운 기술과 관련된 단어들을 들으면 호기심이 생기죠. 이렇게 호기심이 생겼을 때 그 기술에 대해 이해하고 실제로 기술을 잘 구현하는 개발자가 되고 싶어요. 소위 말하는 백엔드 쪽에 더 관심이 있는 거 같아요. 앞으로도 이 방향으로 나아가고 싶구요.음.. 그리고 하나만 덧붙이면, 제 생활도 잘 지킬 수 있는 개발자가 되고 싶어요. 일도 일이지만.!Q) 마지막으로 코드스테이츠를 다른 사람에게 추천한다면?소프트웨어 엔지니어가 되고 싶으신 분들에게 꼭 추천하고 싶어요. 독학을 해도 좋은 점이 있겠지만.. 체계적인 커리큘럼을 따라가면서 방향성 있는 공부를 하면 효율적일 거 같아요. 시간을 아낄 수 있죠. 커리어 전환을 고민하시는 분들에게도 적합하구요.그리고 무엇보다 같은 길을 가는 사람들과 커뮤니티를 형성하고 함께 공부할 수 있다는 점이 코드스테이츠의 가장 큰 장점이라고 생각합니다.

냉정과 열정 사이라는 소설이 있다. 대학교 때 읽었던 소설인데 두 사람의 여정을 각자의 시선에서 다룬 소설이다. 에잇퍼센트에 인턴으로 입사해 9개월간 일하고 훨훨 날아간 병훈님과 나도 이 소설처럼 각자의 시선에서 지난 9개월을 되돌아보려 한다. (경고한다. 로맨틱하지 않다.)병훈님이 떠나는 날. 아마 여러분이 보는것과 내가 이 사진을 보는 느낌이 많이 다를거다.1. 만나기까지- 소병훈 이야기2015년 대학교 3학년이 시작될 때부터 졸업 이후에 대한 고민이 생겨났다. 대학원 진학과 취직은 수많은 대학생들의 공통된 고민이기에 수많은 조언이 넘쳐나지만 결론은 '나에게 맞는 길'을 선택하는 것이다. 내 인생 내가 선택해야지 언제까지 남들 좋다는 길로만 가겠는가. 둘 다 겪어보고 내가 선택하겠다고 다짐했다.졸업을 위해서는 대학원에서 과제연구를 1년 해야 했기에 대학원은 겪어 볼 수 있었다. 그러면 취직도 경험해보고 싶은데 어떻게 하지? 대기업에서 1~2개월 인턴을 했던 친구들에게 물어보니 한결같이 '놀고먹다 보니 월급이 나온다'는 경험담을 늘어놓았다. 하지만 정말로 취직해서 놀고먹으면 잘리겠지. 대기업 인턴은 패스. 스타트업 관련 세미나에서 한 VC의 '스타트업은 망해도 스타트업 인턴은 망하지 않는다'는 말을 들었다. 창업에 생각이 있으면 스타트업에서 인턴을 해보라는 말이었다. 그래서 '스타트업에서 일해보자'라고 결정했다.수많은 스타트업 중에서 왜 에잇퍼센트를 선택했다고 물으신다면, 빠른 속도로 성장하면서 변하고 있는 스타트업 속에서 일해보기를 원했기 때문이다. 그리고 당시의 나는 CTO의 멋진 말 한마디에 눈을 반짝이며 '이 회사에서 이 사람과 일하고 싶다'라고 생각하면 앞뒤 안 가리고 지원하는 이상주의자였다. 그래서 페이스북에서 호성님의 글을 읽고 '이 회사가 내가 생각하던 회사구나'라는 생각이 들어서 먼저 지원했던 회사를 포기하고, 에잇퍼센트 입사를 간절히(?) 원하게 되었다.- 이호성 이야기2016년 1월의 첫 번째 근무 날. 대표님이 모두를 불러 모았다. 그리고는 회사의 투자 유치 소식을 알려 주었다. (무슨 투자 유치 소식을 "오늘 저녁에는 치킨을 시켜 먹기로 했어요." 수준으로 재미없게 이야기하는지 모르겠다.) 투자를 받는 것이 확정되었으니 대표님이 내게 전달해 주신 미션은 개발자를 채용해서 제품 개발의 속도를 높이라는 것이었다. 사실 에잇퍼센트에 오기 전에 한 회사에만 오래 있기도 했고 개발자들과의 네트워킹도 게을리했던 터라 당장 좋은 개발자를 뽑을 수 있는 방법이 없었다.그래서 블로그에 회사를 알리는 글을 쓰기 시작하면서 주위 분들께 추천을 부탁드렸다. 그중 JDLab의 양주동 대표님이 괜찮은 학교 후배를 추천해 주신다고 해서 속으로 쾌재를 불렀다. 하지만 추천해 주신 친구가 애매하게 9개월만 일할 수 있는 상황이라고 하니 고민이 되었다. 주니어가 실제로 일을 잘 하게 되려면 꽤 긴 시간이 필요한데, 실제로 일을 잘할 수 있게 되었을 때쯤 회사를 떠나는 게 아닐까 하는 생각이 들었기 때문이다. 하지만 인력(당시 4명)에 비해 해야할 일이 너무나도 많았기에 누군가의 손이라도 빌려야 할 판이었다. 그래서 일단 병훈님을 만나 보기로 했다.2. 면접- 소병훈 이야기에잇퍼센트에 들어가는 과정은 상당히 길다.처음에 간단한 티타임을 시작으로 실제 코딩 문제를 풀어보게 하고, 그 뒤에서 다시 1대 n으로 토론하는 과정, 그리고 대표님과의 이야기로 면접이 이어진다. 요즘은 논술 문제도 있다고 들었다. (역시 취직은 어려워)내 경우는 '면접 보려는 것은 아니니 그냥 커피 한잔 하자'는 부님의 간단한 속임수에 넘어가 티타임을 가졌다. 카페에서 커피 한잔 하면서 부님과 에잇퍼센트는 어떠냐고 물어보려고 왔는데, 어느새 내 앞에는 호성님이 앉아 있었고, 메일로 코딩 문제를 받는 것으로 커피 한잔이 끝났다. 이 티타임은 면접보다는 나에게 회사를 소개하고 회사가 나에게 적합한지 보는 과정이었다.코딩 문제는 성호님의 글로 유명해진 pingpong을 포함한 take-home 과제였다. 문제를 받은 다음날 다른 회사 면접을 보고 온 뒤 밤샘으로 문제를 풀었던 것과 제출할 때 pingpong 문제만큼은 자신 있어했던 기억이 난다. 그때의 기억을 떠올리며 당시에 제출했던 코드를 보니 'Assignment를 쓰지 말 것'이라는 조건이 깨져있었다. 자신감 넘치던 과거의 내가 부끄러워지는 순간이다.마지막 면접 과정도 조금은 숨 막히는 경험이었다. 가볍게 대화하는 분위기 속에서 대학에서 들었던 전공과목 별로 하나하나 물어가며 내 지식의 바닥을 확인했다. 대학에서 3년간 들었던 전공과목은 많지만, 질문 들어오는 족족 '모르겠습니다' 밖에 할 수 없었다. 내가 답할 수 있는 수준을 찾으시려는지 점점 질문의 난이도가 낮아졌고, 마지막으로 스택과 큐를 물어보는 질문에 답하면서 '이 회사는 못 들어가겠구나'라는 생각이 들었다.동시에 진행했던 다른 회사에서 합격 메일이 왔기에 에잇퍼센트에 '0월 0일까지 합격/불합격 결과를 알려주세요'라는 당당한 요구를 한 뒤 떨어졌다는 메일을 기다리고 있었다. 하지만 예상치 못한 합격 메일을 받았고, 그 메일에는실력에 대해서는 회사에 오셔서 보여주세요라는 잊지 못할 문구가 있었다.그리고 첫 출근, 4월 4일 9시 20분에 출근해서 잠긴 문을 보며 에잇퍼센트의 첫 날을 맞이했다.- 이호성 이야기병훈님이 왔다고 하셔서 학교 선배인 부님과 함께 회사 옆 '피어나' 카페로 갔다. (당시만 해도 사무실에 회의실이 없어서 모든 미팅을 회사 옆 카페에서 해야만 했다.) 병훈님의 첫인상은 “꺼벙이"였다.공대에서 흔히 볼 수 있는 스타일. 하지만 말하고 이야기하는 것은 번뜩이는 느낌은 크게 들지 않았다. 아마 나정도로 평범한 느낌이었던 것 같다. 이야기를 하다 보니 다른 곳에 면접을 이미 본 상태였다. 일단 우리 회사와 나에 대해서 좋은 감정을 갖게 하는 것이 좋겠다 싶어서 이래저래 약을 팔았다. 그리고 면접 문제를 메일로 전달하겠다고 하고 첫 번째 만남을 마쳤다.며칠 뒤 제출한 과제를 가지고 다시 한번 병훈님을 만났다. 전공에 관련된 기본적인 질문들을 던졌다.(정확히는 졸업한 지 10년이 지나서 그냥 내가 기억나는 것들을 물어보았다.) 그런데 10개의 질문을 던지면 8개의 질문 은 원하는 답을 듣지 못했다. 실망했다. 겸손하고 배움의 자세가 갖춰져 있는 친구라는 생각은 들었다. 하지만 이렇게 모르는 친구를 뽑아도 될까 하는 생각이 들었다.하지만 뽑았다. 솔직히 그냥 학벌을 보고 뽑았다. 좋은 학교에 다니고 있는 친구이니 지금까지 최소한 한 번쯤은 최선을 다해 본 적이 있겠지 라는 생각을 했다. 무엇보다 당시 나는 꽤 급했다.합격 메일에는 ‘실력에 대해서는 회사에 오셔서 보여주세요'라는 내용을 적어서 보냈다. 부족한 만큼 회사에 와서 최선을 다해주었으면 하는 마음이었다. 그리고 입사할 주에 있을 워크숍 준비에 대한 요청도 함께 드렸다.지금 와서 이야기하는 것이지만 최근에 병훈님을 면접 봤다면 떨어뜨렸을 거다. 생각해 보면 이게 면접, 특히 주니어 면접의 어려움이다. 그 사람이 입사해서의 2주 정도는 예상해 볼 수 있지만 그 뒤는 예상하는 것은 너무나 어려운 일이다.3. 들어와서 처음 했던 일- 소병훈 이야기들어와서 처음으로 했던 일은 나를 대학생에서 직장인으로 바꾸는 일이었다.회사에 들어온 지 1~2개월이 지났을 때 외부 업체와 전문 통신을 개발하는 작업을 맡았다. 대학교에서 두 PC 사이의 전문 통신 프로젝트를 만들었던 기억이 있어 충분히 혼자서(그리고 짧은 기간에) 만들 수 있으리라 생각하고 작업을 시작했다. 기존의 코드를 조금씩 수정하고 추가하던 이전의 작업들과는 다르게 처음부터 만들어내는 일이었다.이 일을 하면서 지금까지 '하나의 동작을 하는 무언가'를 100% 혼자서 만든 적이 없다는 것을 깨달았다. 항상 기본 틀을 받아서 코딩하고, 어려울 때는 모범 답안을 보면서 힌트를 얻었으며, 그러고도 힘이 부치면 7~80%만 완성하고 (시간이 없었다는 핑계를 대면서) 넘어갔었다. 회사에서는 이 일이 '소켓 통신의 이해를 확인하기 위한 프로그래밍'이라고 설명되어 있지 않았고, 어디서 버그가 발생했는지 힌트를 얻을 수 없었다.대학 강의로 들었던 내용들과 전혀 다른 지식들이 필요했지만, 필요한 기초적인 요소들은 구글에서 찾을 수 있었다. 하지만 어떤 키워드를 검색해야 하는지부터가 문제였다. 검색해야 하는 단어를 알아내려고 시니어 개발자님들께 돌아가면서 물어봤다. (너무 자주 물어야 해서 한 분에게만 묻기 죄송했다.) 처음에는 학교에서 배운 내용은 쓸모없다고 생각했었는데, 지금 생각해보니 그마저도 없었으면 구글과 위키의 내용도 이해 못했을 것 같다.웹 개발에 대한 기초도 없고, 어디가 끝인지 확신도 없어서 개발 시간이 길어졌다. 야근을 반복했다. 노력한다고 해서 없던 능력이 생기지는 않았고, 결과로 커다란 똥덩어리 같은 코드가 만들어졌다. 다행히도 (달리는 중간에 몇 개의 부품을 갈아 끼운 이후에) 최소한의 기능은 정상적으로 돌아갔다.그렇지만 이 코드가 12월까지 구린 냄새를 피우고 있었다. 에러를 만들지는 않지만 가독성이 떨어지고 창의적인 구조 때문에, 유지/보수를 할 때마다 과거의 내 실력을 확인하는 좋은 지표가 되었다.- 이호성 이야기시간이 많다면 병훈님을 옆에 앉혀 두고 차근차근 알려주고도 싶고, 같이 스터디도 하고 싶었지만 내게는 당장 해야 하는 일이 쌓여 있었다. 다행히 팀에 계신 시니어 개발자 분들이 병훈님일 이래 저래 잘 돌봐 주었다. (20살이 넘는 청년에게 "돌봐 주었다"라는 표현이 적당한 가에 대해서 곰곰 생각해 보았는데, 흠. 역시 적절하다.) 병훈님께 처음 한 달 동안은 조각을 고치는 일, 작지만 급한 일 들을 맡겼다. 덕분에 시니어 개발자들이 다른 일들에 집중을 할 수 있었다. 그리고는 한 달이 지나자 하나의 일을 떼어서 맡겨볼 수 있겠다는 생각이 들었다. 단순히 개발하는 일뿐만 아니라 다른 회사 개발자들과 커뮤니케이션을 직접 하면서 일을 할 수 있도록 했다. 병훈 님은 잊어버렸을지는 모르겠지만 외부 업체로 처음 전화를 걸었을 때 우리 팀의 시니어 개발자들은 모두들 키보드에서 손을 놓고 병훈님의 대화를 노심초사하면서 듣고 있었다.이 프로젝트는 곧 병훈님이 예상한 일정을 넘어섰고, 얼마 이후에는 내가 예상한 일정도 넘어섰다. 병훈님이 끙끙 앓고 있는 게 보였다. 그 일을 다른 사람에게 넘겨야 하는가의 고민도 여러 번 했다. 병훈님이 만들어 낸 창의적(이라고 말하고 싶겠지만 상식을 벗어난)인 코드들을 뜯어고치고 싶다는 생각도 했다. 하지만 시간은 지났고 테스트를 통과한 코드는 에잇퍼센트 프로덕트의 한 자리를 차지했다.4. 무엇을 배웠을까?- 소병훈 이야기첫 번째로 회사가 어떻게 돌아가는 지를 배웠다. 작은(?) 스타트업이었기에 개발팀 외 다른 팀원들과도 친하게 지낼 수 있었고, 회사 내에서 생기는 사건들을 전부 들을 수 있었다. 그렇게 아이디어가 나오는 순간부터 제품으로 완성되는 과정을 볼 수 있었다. 또한 회사의 크고 작은 의사 결정 과정을 지켜볼 수 있었는데, 모든 의사 결정들에 원인과 논리적인 과정이 따른다는 점이 재밌었다.내가 알지 못하는 원인들과 다른 사람들이 결정하게 된 이유가 궁금해서 여기저기 물어보았고, 모두들 숨기지 않고 말해 주었다. 대표님과의 티타임에 찾아가서 묻기도 하고(모두에게 열려있었는데 단 2명이 왔었다), 퍼포먼스 마케팅이 궁금하다며 점심시간에 옆에 앉아 이야기하고, 전화 응대를 어깨너머로 들어보기 했다. 글로 적어보니 처음 초등학교에 들어간 8살 아이 같기도 하지만, 에잇퍼센트에 있으면서 물어보는 만큼 알 수 있었고, 그만큼 이전과는 다른 세상을 알 수 있었다. (그리고 그만큼 야근을 했다.)두 번째는 개발자가 되는 과정을 배웠다. 당연히 개발 실력도 늘었지만, 조금 더 보태서 개발자가 되는 과정을 배웠다고 말하고 싶다. 누구라고 말할 것 없이 남는 시간을 조금씩 쪼개 공부하고 있는 사람들, 새벽 4시가 넘었음에도 꼼꼼히 기록을 남기며 마무리하는 야간작업, 그리고 혼자서는 만들 수 없는 거대한 코드를 점진적으로 만들어가는 개발팀을 보면서 개발자라는 직업을 만날 수 있었다. 내가 본 개발자는 (에잇퍼센트의 개발자만의 특징일 수도 있지만,) 모든 결과를 '우연'으로 넘기지 않고 원인을 찾았고, 원하는 분야를 찾아서 스스로 공부하고, 삶의 즐거움을 하나씩 가지고 있는 사람들이었다.마지막으로 나 되돌아보기. 나는 내 실력을 과대평가하고 있었다. 회사에 들어오면서 '열심히 하겠다'라고 말했지만 몇 개월 '열심히' 뛰어서 갈 수 있는 거리에는 한계가 있었다. 다른 사람들이 불가능하다고 말해도 혼자서 '노력하면 할 수 있다'라고 생각하면서 오기로 붙잡고 있다가 결국 기한을 넘긴 적이 많았다. 시간이 지나면서 '할 수 있을 것 같다'는 자신감이 아니라 완성된 결과물을 보면서 실력을 확인했다. 항상 자신감이 넘치다 보니 매번 내 생각보다 실력이 뒤에 있었고, 그런 생각이 들 때마다 기숙사에서 공부를 했다.그렇지만 나를 과대평가했던 것처럼 나의 목표도 과대평가 했었다. 내가 도달하려고 했던 목표도 꾸준히 달리면 도달할 수 있는 거리에 있었고, 생각보다 멀리 있지 않았다. 다만 '꾸준히'의 기준이 몇 주, 몇 개월이 아니라는 것을 배웠을 뿐이다.- 이호성 이야기내가 입사하기 전에 에잇퍼센트에 여러 명의 개발 인턴이 있었다고 했다. (commit log에서만 만날 수 있는 그대들이여. 왜 버그를 내게 주고 갔는가.) 그리고 한 명을 제외하고는 회사를 모두 떠났다. 처음에 대표님이 인턴 채용 제안을 몇 번 하셨을 때 개발팀에는 인턴을 채용하지 않겠노라고 말했었다. 사람이 전부인 개발팀에서 떠나는 것이 예정된 사람을 뽑고 싶지 않은 마음이었다. 하지만 병훈님은 이런 내 생각을 바꿔 놓았다.연말 평가에서 성장에 대한 상을 받을 만큼 병훈님의 성장은 눈부셨다. 이제 좋은 주니어는 무엇인가에 대해서 병훈님을 기준으로 생각을 할 수 있게 되었다. 주니어 채용에 대한 성공체험을 했다고도 할 수 있겠다.상은 병훈님이 받는데 주는 사람이 더 좋아하네?좋은 주니어는 당연하게도 일정 시간이 지났을 때 높은 곳에 올라갈 수 있는 사람이다. 높은 곳에 올라가기 위한 조건은 다음과 같은 것들이 있다.1) 상대적으로 이미 높은 곳에 있을 것 전설 속에만 존재하는 시니어 같은 주니어 되시겠다. 고등학교, 대학교 때 많은 지식과 경험을 쌓아서 이미 현업에서 잘할 수 있는 친구들이다.2) 인지능력, 학습능력문제를 이해하고 정의하는 능력이 뛰어나고 논리적인 사고를 한다. 속칭 똑똑한 친구들이다. 문제를 자세하게 설명해 주지 않아도 문제의 본질을 이해할 수 있고, 답으로 가는 길을 빠르게 찾아낼 수 있다. 새로운 것을 빠르게 익히고 배움에 대한 두려움이 없다.3) 지적겸손배움에 대해 열린 자세를 가지고 있어야 한다. 나는 개인적으로 주니어의 경우 이 능력을 "내갈굼력"이라고도 부른다. 다른 사람들에게 지적과 갈굼을 받으면서도 그것이 배움으로 이어진다면 감사한 마음으로 받아들인다. 감사한 마음은 다시 지식을 전해주는 사람에게 긍정적인 피드백이 되어 더 많은 것을 알려주게 되는 선순환 구조를 만들어 간다.4) 태도긍정적이고 도전적인 태도를 갖추어야 한다. 자신의 인생을 발전적으로 개척해 나갈 태도. 그리고 자신을 둘러싼 환경에 감사하는 태도. 이 태도는 팀에도 많은 영향을 미친다.병훈님을 면접 볼 때의 나는 1) 만을 중요하게 생각했기에 병훈님을 떨어뜨려야 하나 하고 생각했다. 하지만 이제 와서 뒤돌아 보니 병훈님은 2), 3), 4)을 모두 갖추고 있는 인재였다. 아마 몇 년 뒤에는 1)도 충분히 갖추게 되리라.5. 어떻게 일했나?- 소병훈 이야기 9개월 동안 에잇퍼센트를 다니면서 항상 내 능력으로 조금 힘들지만 불가능하지 않을 만큼 업무가 들어왔다. 스프린트(2주) 단위로 업무를 나눠가지는데, 일방적으로 업무를 할당받지 않고 팀 회의로 업무를 나눠갖는다. 호성님이 업무를 강요하지도 않고 업무 일정도 각자가 정하지만, 모두가 보고 있다는 느낌과 '스스로를 과대평가하는 나' 때문에 매번 촉박한 일정에 시달리게 되었다. 그렇게 나는 손을 들고 해당 업무의 책임자가 된다. 초반에는(전문 개발할 때까지)는 아예 질문하지 않아서 혼자 끙끙 댔는데, 너무 안쓰러워 보였는지 옆에 앉은 연태님이 먼저 도와주셨다. 시간이 지나면서 길이 명확하게 보이지 않을 때는 시니어 개발자(대부분 연태님)에게 물어보면서 일을 진행했다. 어느 날 호성님이 에잇퍼센트처럼 '실패하면서 성장할 수 있는 환경'이 다른 회사에서는 없다고 말했었다. 생각해보니 내가 자유롭게 개발해도 테스트와 코드 리뷰를 거치면서 문제를 잡아낸다. 그러고도 버그가 생기면 실서버에서 디버깅해서 문제를 해결한다. 심적으로 매우 죄송한 마음이 들지만 추가적으로 다른 벌은 받지 않았다. 일을 시작하기 전부터 지레 겁먹을 필요는 없었다. 그 뒤로 길이 희미하더라도 우선 걸어가 봤다. 그러다가 도저히 길이 보이지 않을 때, 조언을 받는 방식으로 일을 진행했다. 시간이 더 오래 걸리면서 최종 결과물의 수준이 떨어지는 상황이 발생했지만, 코드 리뷰를 받으며 최소한의 수준은 맞춰졌다. (그러면서 시간은 더 오래 걸린다.) 최대한으로 생각해서 만들어도 항상 놓치는 부분이나 더 간단한 해결 방법이 있었고, 그때 느끼는 아쉬움과 안타까움이 다음 개발할 때 잊지 않고 기억나서 내가 성장한다는 느낌이 들었다. 막바지에는 개발을 시작하기 전에 항상 의자를 들고 해당 업무를 요청한 사람 옆으로 갔다. 말로 이야기면 Slack이나 Trello로 이야기하는 것보다 빠르고, 해당 문제를 직접 보면서 자세한 설명도 들을 수 있었다. 요청사항을 받아 개발하는 느낌이 아니고 함께 문제를 해결한다는 느낌으로 이야기하면서 실시간으로 여러 해결방안을 제시하면서 생각을 주고받았다. 문제를 해결하면서 회사에 장기적으로 도움이 되는 방향을 고민하다 보니 '주인의식을 가지고 일한다'는 느낌이 들었다. (정확히는 이왕 만드는 거 아름답게 만든다는 생각이었다.)- 이호성 이야기회사에서 병훈님의 별명은 '아기새'였다. 업무를 하면서도 사람들의 보살핌을 필요로 했지만 그것 외에도 이런저런 허술한 면을 많이 보여줘서 누가 붙였는지 기억이 나진 않지만 모두의 입에 착 붙어 있는 별명이었다. (개발팀 내에서는 간혹 '아. 이런. 손이 많이 가는 친구'로 불리기도 했다.)에잇퍼센트에는 퇴사하면 털린다. 다들 떠나지 마라.병훈님을 연태님 옆자리에 앉게 했다. 회사 내에서 스위퍼(스프린트 내의 개발 잡일들을 처리하는 담당) 팀도 연태님과 같이할 수 있도록 했다. 경험과 인내심이 많고 상냥한 언니 같은 연태님(남자)은 병훈님의 좋은 파트너가 되어 주었다. 그리고 세바님은 어려운 문제를 함께 해결해 주고 코드의 퀄리티에 대한 감시자(갈굼자)가 되어 주었다. 언젠가 병훈님이 개발자의 길을 가게 되어 첫 월급을 받게 되면 이 두 분에게는 빨간 내복을 사드려야 할 거다.처음에는 아기새의 Pull Request(반영하고자 하는 코드 뭉치)에는 코멘트가 수십 개가 달렸다. 그것들을 꾸역꾸역 고치고 나면 다시 그 절반 정도의 코멘트가 달리곤 했다. 하지만 병훈님이 떠날 때쯤에는 내 코드에 "이렇게 저렇게 고치는 게 더 좋은 것 같은데요?"라고 코멘트를 달곤 했으니 발전하지 못한 나는 부끄러울 따름이다.그리고 병훈님은 다른 팀일에도 참 관심이 많았다. 그러고 보면 나도 처음에 스타트업에서 일하기 시작했을 때 다른팀 일들도 왜 그렇게 재미있었는지 모르겠다. 하지만 분명한 것은 작은 조직에서는 다른 팀에 대한 관심이 개발을 잘하는 데 많은 도움이 된다.6. 떠나기 이주일 전- 소병훈 이야기정해졌던 퇴사일이 가까워지면서 새로운 업무는 들어오지 않았다. To-do list는 사라지고, 대신 '인수인계'라는 일이 생겨났다. 지금까지 했던 일들을 문서로 남기면서 새로운 책임자에게 넘겨주는 일이었다. 큰 그림을 그렸던 것들이 있는데 완성을 하지 못한다는 아쉬움이 컸다.호성님께 1,2월 프리랜서 제안서를 받게 된 건 우연이였다. 다 같이 점심을 먹을 때 우연히 호성님과 같은 테이블에 있었고, 1,2월에 남은 일정을 이야기하다 농담처럼 나온 제안이었다.제안서를 받은 날, 기숙사에서 많은 계산을 했다. 개발하는데 어느 정도 시간이 걸릴지, 제안서의 업무 기한을 변경한다면 일정이 어떻게 될지, 그렇게 받은 돈으로 어느 정도 도움이 될지. 충분히 가능한 일정이었다. 못해서 아쉬워하던 일이기도 했다. 그렇기에 더 고민했다.긍정적으로 고민하던 제안을 거절한 이유는 '여행 도중에도 계속 개발을 생각할까 걱정되어서'였다. 이번 여행에서 아쉬움이 남으면 다음은 언제가 될지 모른다는 생각이 들자, 내 시간이 더 귀하다는 생각이 들었다.그러면서 내가 조금이라도 더 필요하다고 말해주는 점이 고마웠다. 내가 생각해보지 못한 선택지를 받아서, 나의 가치관을 되짚어 본 느낌이었다.- 이호성 이야기병훈님과 같이 식사를 했다. 병훈님은 복학하기 전 유럽으로 여행을 다녀온다고 했다. 밤에 돌아다니면 위험하니까 숙소에서 코딩이나 하라고 살살 꼬셨다. 밤에 코딩하고 그 아르바이트비로 낮에 럭셔리하게 맛있는 것 먹고 다니면 얼마나 즐거운 여행이 되겠냐고. 제안서를 하나 작성해서 해야 할 일과 보수를 적어서 병훈님께 주었다. 왠지 넘어올 것만 같은 느낌이었다.병훈님이 하루 정도 생각해 보더니 "어정쩡한 상태가 될 것 같아요. 생각해보니 이런 제안을 주신 것만으로도 정말 감사합니다."라고 했다. 실패했다.회사 입장에서 업무를 잘 알고 있는 병훈님이 조금이라도 일을 더 해주면 하는 마음이었다. 하지만 다시 생각해보니 인생의 후배에게는 좋지 않은 권유였던 것 같다. 돈이 중요할 때가 아니라 세상에 대한 경험과 자신을 뒤돌아 볼 시간이 필요했던 거니깐.7. 떠나는 날케익이나 먹고 떠나랏!- 소병훈 이야기떠나는 날도 크게 다르지 않았다. 코드도 살펴보고 pull request도 적으면서 이전과 같은 하루를 보냈다. 그리고 마지막 날, 혹시 작별 인사를 하면서 내가 울지 않을까 걱정했지만 괜한 걱정이었다. 2달 전부터 작별 인사(라 쓰고 갈굼이라 읽는다)를 받아서 그런지 마지막 인사가 특별한 느낌이 들지 않았다.그렇지만 그 뒤로 며칠간 회사를 나왔다는 묘한 홀가분함과 그동안 했던 일들이 내 손을 떠난 공허함이 있었다. 내가 없으면 회사가 바뀌지 않을까 하는 조그만 기대도 있었지만, 다들 나 없이 잘 지내나 보다. 나는 조금 아쉬웠는데.- 이호성 이야기9개월이라는 시간이 참 금방 지났다. 남은 기간 동안 여행을 떠나는 병훈님에게 사람들이 "에이 그거 여행 가면 뭐해. 그냥 회사에서 일해"와 같은 장난을 수도 없이 했던 것 같다. 하지만 떠날 시간은 정해져 있었고 병훈님은 사람들의 박수를 받으며 떠났다. 마치 80분을 열심히 뛴 축구선수가 교체를 위해 떠날 때 받는 박수처럼.8. 떠나고 난 후- 이호성 이야기며칠 간은 아침 데일리 미팅이 왠지 허전하고, 슬랙으로 말을 걸면 대답을 할 것만 같았다. 하지만 또 새로운 사람이 회사에 들어오고 바쁘게 회사가 돌아가면서 금방 잊혀지긴 하더라. 아 그러고 보니 병훈님이 만든 코드에서 버그가 나올 때마다 우리는 회사에 남은 아기새 인형을 괴롭히긴 했다.병훈님이 떠나고 나서 같은 학교의 후배인 선희님이 회사에 마케팅 인턴으로 들어왔다. 선희님이 자기소개 시간에병훈 선배와 같은 동아리에..라고 말하자마자 전 직원이 다 뒤집어졌다. 그렇다. 우리에게 "병훈"과 "선배"는 함께할 수 없는 단어였다.여행을 갔다가 돌아온 아기새 병훈님이 와인을 하나 물어왔다. 그리고는 파닥파닥.군대 문제가 있기에 당분간 병훈님과 함께 오래 일할 수 있는 기회는 찾아오지 않을 것 같다. 아쉬운 마음이 든다. 에잇퍼센트에서의 병훈님을 "막 알에서 깨어나 호기심을 가지고 세상을 바라보는 아기새"로 기억해야겠다. 그리고 그 모습을 기억하며 나 또한 초심을 되새겨야지.우리가 다시 만날 그날까지 병훈님이 더 큰 날갯짓으로 더 넓은 세상을 여행하길 바란다. 9개월간 함께 해준 병훈님께 감사한다. 안녕!덧, 그나저나 난 또 어디에서 찾아야 하나. 이 다음 아기새를.#8퍼센트 #에잇퍼센트 #인턴 #조직문화 #후기 #팀워크 #팀플레이

Overview새로운 사용환경 구축에 도전하는 건 개발자의 운명과도 같습니다. 오늘은 여러 장점을 가지고 있는 Vue (프론트엔드 자바스크립트 프레임워크)를 도전해보겠습니다. Vue는 다른 프레임워크에 비해 가볍고, 개발하기에 편합니다. 그럼 우선 Vue를 설치합시다! Vue 설치CDNhttps://unpkg.com/vue 주소를 script 태그에 직접 추가 Vue.js 파일다운개발용, 배포용 버전을 다운 받아 script 태그에 추가개발용 버전은 개발에 도움이 되는 모든 경고를 출력하기 때문에 개발 중에만 사용하고, 실제 서비스에서는 배포용 버전으로 사용해야 한다. NPM 설치규모가 큰 프로젝트 경우 컴포넌트별 독립적으로 관리할 수 있는 싱글 파일 컴포넌트 방식 추천 Vue를 설치하는 방법은 여러 가지가 있습니다. 각자 특성에 맞게 편리한 방법으로 설치해주세요. 이번 글에서는 싱글 파일 컴포넌트 방식을 사용할 것이므로 NPM vue-cli 를 설치해 프로젝트를 구성하겠습니다. # vue-cli 전역 설치, 권한에러시 sudo 추가 $ npm install vue-cli -global vue-clivue-cli를 사용하면 뷰 애플리케이션을 개발하기 위한 초기 프로젝트 구조를 쉽게 구성할 수 있습니다. 다만, 싱글 파일 컴포넌트 체계를 사용하려면 .vue 파일을 웹 브라우저가 인식할 수 있는 형태의 파일로 변환해 주는 웹팩(Webpack)이나 브라우저리파이(Browserify)와 같은 도구가 필요합니다. vue-cli 설치 명령어 vue init webpack : 고급 웹팩 기능을 활용한 프로젝트 구성 방식. 테스팅，문법 검사 등을 지원vue init webpack-simple : 웹팩 최소 기능을 활용한 프로젝트 구성 방식. 빠른 화면 프로토타이핑용vue init browserify : 고급 브라우저리파이 기능을 활용한 프로젝트 구성 방식. 테스팅，문법 검사 등을 지원vue init browserify-simple : 브라우저리파이 최소 기능을 활용한 프로젝트 구성 방식. 빠른 화면 프로토타이핑용vue init simple : 최소 뷰 기능만 들어간 HTML 파일 1개 생성vue init pwa : 웹팩 기반의 프로그레시브 웹 앱(PWA, Progressive Web App) 기능을 지원하는 뷰 프로젝트여러 설치 명령어 중에 특성에 맞는 초기 프로젝트를 생성하세요. 1) vue init webpack 실행# 해당 프로젝트 폴더에서 실행 $ vue init webpack   # 현재 디렉토리에서 프로젝트 생성 여부 ? Generate project in current directory? (Y/n) # 프로젝트 이름 ? Project name (vue_ex) # 프로젝트 설명 ? Project description (A Vue.js project) # 프로젝트 작성자 ? Author (곽정섭 ) # 빌드 방식 ? Vue build (Use arrow keys) # vue-router를 설치 여부 ? Install vue-router? (Y/n) # 코드를 보완하기 위해 ESLint를 사용 여부 ? Use ESLint to lint your code? (Y/n) # ESLint 사전 설정 선택 ? Pick an ESLint preset (Use arrow keys) # 단위 테스트 섧정 ? Set up unit tests (Y/n) # 테스트 러너 선택 ? Pick a test runner (Use arrow keys) # Nightwatch로 e2e 테스트를 설정 여부 ? Setup e2e tests with Nightwatch? (Y/n) # 프로젝트가 생성 된 후에`npm install`을 실행해야합니까? ? Should we run `npm install` for you after the project has been created? (recommended) (Use arrow keys) 2) 고급 웹팩 기능을 활용한 프로젝트 구성 방식으로 설치3) 설치완료4) package.json 파일에 설정된 라이브러리 설치$ npm install 5) 개발모드 실행# 해당 프로젝트 폴더에서 실행(소스수정시 자동 새로고침) $ npm run dev 6) http://localhost:8080/ 브라우저 실행7) Yeah, You got it!!!!추가 도구: Vue Devtools(크롬 확장 플러그인)Vue Devtools(크롬 확장 플러그인)은 Vue를 사용할 때, 브라우저에서 사용자 친화적으로 검사하고 디버그할 수 있습니다.크롬 개발자 도구에 Vue 탭이 추가됨ConclusionVue를 설치하는 여러 방법 중 고급 웹팩 기능을 활용한 프로젝트 구성을 알아봤습니다. 다음 글에서는 Vue 인스턴스 및 디렉티브(지시문) 사용법을 다뤄보겠습니다.참고설치방법 — Vue.js 글곽정섭 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유 #Vue

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

다음 중 몇 개나 해당하시나요?1~5명 규모의 작은 개발팀에서 일한다.DevOps 조직이다.우여곡절 끝에 서비스는 런칭했지만, 개발과 동시에 운영을 해야하는 상황이다.서버 인프라 지식이 별로 없다.무중단 서비스 운영 경험이 별로 없다.팀 내에 시스템 엔지니어(SE)와 데이터베이스 전문가(DBA)가 없다.하나라도 해당한다면 이 글이 도움이 될 지도 모릅니다.누구나 쉽고 빠르게 앱을 만들고 서비스를 런칭할 수 있는 시대가 되었지만 문제는 런칭 이후입니다. 런칭 이후에는 고객이 100명이라도 안정적인(High Availability) 서비스를 운영해야 하는 것이 백엔드 개발자의 임무이기 때문입니다.안정적인 서비스를 운영하기 위해서는 체계적인 모니터링 필수라고 하는데 그마저도 쉽지 않습니다. 가장 큰 문제는 (장애가 터지기 전까지) 무엇을 모니터링 해야 하는지조차 모른다는 것이고, 당장 개발해야할 것들이 산더미처럼 쌓여있는데 사람도 부족한 것도 문제입니다.그렇지만 누군가는 해야하는 일입니다. 리디북스 역시 모니터링이 전혀 없던 시절이 있었으나, 크고 작은 실패와 좌절을 겪으며 조금씩 경험을 쌓아가고 있습니다. 이번 글에서는 우리가 모니터링과 관련하여 고민해 온 내용들을 소개해볼까 합니다.어떻게 모니터링할 것인가시스템의 안정성을 높이기 위해 투입해야 하는 노력은 지수적으로 증가합니다. 아래 표에서 보듯이 SLA 를 99.999% 에서 99.9999% 로 높이려고 한다면 1년에 약 5분의 가용시간을 얻을 뿐이지만 이를 위해 수백시간 이상의 노력을 들여야 합니다.가용성연간 장애 시간주간 장애 시간99.995%26.28 분30.24 초99.999%5.26 분6.05 초99.9999%0.525 분0.6048 초완벽함을 추구하면 할 수록 얻을 수 있는 고객 만족은 미미한 것에 비해 이를 위한 개발자의 노력은 기하급수적으로 증가합니다. 따라서, 먼저 대응의 적정선을 찾고 효율적으로 움직이기 위한 계획을 세워야 합니다.리디북스에서는 해야할 일을 4가지로 분류하여 중요한 일부터 처리하는 아이젠하워 매트릭스에서 그 대응 원칙을 차용하였는데, 그 이유는 시사하는 바가 동일하기 때문이었습니다. 즉, 중요한 것은 대부분 긴급하지 않고, 긴급한 것은 대체로 중요하지 않다는 점입니다. 그리고 매트릭스의 두 축은 아래와 같습니다.얼마나 급한가?사무실의 무선 인터넷이 안된다면 서비스에 큰 문제는 아니지만, 당장 해결해야 하는 급한 일입니다. 반대로 백업 스크립트가 며칠째 동작하지 않아서 최근 데이터의 스냅샷이 없다면, 이는 당장 해결할 필요는 없겠지만 매우 중요한 일입니다.그리고 장애란, 단순히 “고장”을 의미하는 것이 아니라 서비스 이용에 지장이 없더라도 어떤 수치나 결과가 예상과 다른 상황을 의미해야 합니다. 예를 들어, 웹서버의 평균 CPU 사용률이 70%가 넘는다거나 네트워크 대역폭을 90% 이상 사용하는 상황은 정상이 아닙니다. 조금만 트래픽이 몰려도 문제가 발생할 가능성이 매우 높기 때문에 잠재적인 장애로 간주해야 합니다.우리는 급한 문제를 우선적으로 처리하는 경향이 있어서, 덜 급하지만 더 중요한 일을 놓치는 경우가 많습니다. 이를 피하려면 장애의 그 심각도에 따라서도 구분해야 합니다.얼마나 심각한가?심각도를 처음부터 너무 상세하게 구분할 필요는 없으며, 크게 서비스 이용에 치명적인 것과 그렇지 않은 것으로 나누어 생각하면 됩니다. “치명적”의 의미는 서비스마다 다를 수 있지만 대개 아래에 해당합니다.사업에 지장을 초래한다.고객을 잃는다.만약 웹페이지의 로딩 속도가 매우 느려서 나쁜 이미지를 준다면 이 역시 치명적일 수 있습니다. 실제로 아마존에서는 로딩 속도가 100ms 지연될 때마다 눈에 띄는 매출 하락이 발생했다는 테스트 결과가 있습니다. 따라서 속도에 대한 매트릭을 모니터링 지표에 추가하는 것은 좋은 선택입니다.이상을 토대로 장애 종류에 따른 대응 원칙을 정리하면 아래와 같습니다. 급함안급함심각함➀ 즉각 대응, 즉각 인지➁ 평소 보완, 항상 경계안심각함➂ 빨리 대응, 최소 대응➃ 대응하지 않기이 중에서 항상 의식하고 놓치지 말아야 하는 것은 안급하지만 잠재적으로 심각한 장애(➁)입니다. 그리고 모니터링은 한 번 시작하게 되면 관리를 위한 비용이 꾸준히 투입되어야 하기 때문에 사소한 문제(➂, ➃)를 굳이 파헤치는 것은 오히려 독이 될 수도 있습니다.모니터링 측면에서 본다면 발생중인 장애는 최대한 빨리 발견하는 것이 중요하며, 잠재적인 장애는 상태의 변화를 최대한 빨리 감지하는 것이 중요합니다. 예를 들어, 디스크의 여유공간은 완전히 바닥나기 전까지 어떠한 경고도 나타나지 않지만 부족한 상황이 발생하면 어떤 부작용이 생길지 예측할 수 없습니다.필수 모니터링 갖추기모니터링을 해야할 대상은 기술 스택과 코드 구현에 따라 달라지겠지만, 빼놓을 수 없는 것들이 몇 가지 있습니다. 리디북스에서는 서버의 프로비저닝과 동시에 아래 내용들을 함께 준비하고 있습니다.1. 리소스 및 시스템 모니터링각종 시스템 리소스 및 하드웨어 상태는 필수 모니터링 대상입니다. 모니터링 툴을 설치해보면 측정해주는 항목들이 너무 많아서 당황스러운 경험을 하게 되는데요. 그 중에서도 우리가 주목하고 있는 항목들은 아래와 같습니다.CPU UsageLoad AverageDisk UsageDisk Utilization (iowait, IOPS)Swap Memory Usage (사용시)Temperature (인프라 직접 구축시)RAID Status (인프라 직접 구축시)S.M.A.R.T Errors (인프라 직접 구축시)이 중 몇가지는 New Relic 에서 무료로 지원하므로 당장 여력이 없다면 이를 이용하는 것도 좋은 방법입니다.클라우드 환경이 아닌 데이터센터에서 인프라를 직접 구축하여 운영하고 있다면 좀 더 많은 노력이 필요합니다. 하드웨어적인 장애를 직접 신경써야 하기 때문입니다. 실제로 팬(fan)이 고장나거나 케이블이 환풍구를 막아서 서버의 온도가 비정상적으로 높아지다가 기기가 오동작하는 어처구니없는 상황도 발생합니다.Disk서버 환경에서 SSD 사용이 점점 대세가 되어가고 있는데, 최근 구글이 공개한 정보에 따르면 SSD에서 배드블럭이 발생하는 일은 매우 흔하며, 시간이 오래될 수록 안정성이 떨어진다고 합니다.따라서 디스크와 관련된 RAID나 S.M.A.R.T 오류는 가능한 빨리 대응해야 합니다. 특히 RAID 장비를 구성할 때에는 같은 공정에서 출하된 같은 벤더의 제품을 일괄적으로 구매해서 사용하기 때문에, 동일한 하드웨어 결함을 지니고 있거나 평균 수명도 비슷하므로 결코 안이하게 대응해서는 안됩니다.리디북스에서는 전자책 원본을 보관하는 스토리지에서 4개의 사본(replica) 중 3개가 연달아 깨지는 끔찍한 사고를 경험한 이후로, 디스크 오류는 1순위로 대응하고 있습니다. 참고로 스토리지 서버를 구축한지 3년째가 되는 해였고, 모두 S사의 제품이었습니다.iowait 은 CPU가 유휴(idle) 상태로 I/O를 대기하는 시간을 나타낸 수치입니다. 이를 통해 현재 시스템이 I/O 병목을 겪고 있는지 판단할 수 있기 때문에 중요합니다. 이 수치가 너무 높다면 블록 디바이스나 네트워크가 너무 느린 상황이거나 포화 상태일 수 있으므로, 더 높은 IOPS 장비로 업그레이드하거나 부하를 분산해야 합니다.단, CPU 성능에 영향을 받는 수치이므로 고성능 CPU를 사용할수록 평균 iowait이 높게 측정됩니다. (따라서 성능을 평가하기 위한 지표로는 IOPS도 함께 분석해야 합니다.)Load AverageLoad Average(평균 부하)는 마치 서버의 종합 성적표 같아서, 이 역시 주목할 필요가 있습니다. Load Average에 변동이 생긴다면 평소와는 다른 처리량(throughput)을 내고 있다는 뜻입니다. 요청량이 증가하여 수치가 올라갔다면 서버 증설과 튜닝에 대비해야 하지만, 그렇지 않다면 어딘가 병목이 발생하여 처리 효율이 낮아졌다는 신호입니다.아직 Load Average를 모니터링하고 있지 않다면 주요 서버군부터 아래 규칙을 참고하여 초기 기준치를 설정하기를 권장합니다. 물론 어디까지나 초기 설정 값이며, 실제 상황에 적합하지 않을 수 있습니다.Warning Level : 0.7 * number of cores Critical Level : 1.0 * number of cores간혹 커널 자체에 문제가 있거나, 커널 모드에서 예외가 발생하는 경우에는 syslogd 데몬이 남기는 로그를 파악해야 합니다. Papertrail, Splunk, Loggly 등의 서비스는 크리티컬 수준 이상의 syslog 에 대해 알림을 설정할 수 있을 뿐 아니라, 텍스트 형태로 남겨지는 모든 로그에 대한 관리를 쉽게 도와줍니다. 비록 유료지만 커널 모니터링 용으로만 사용한다면 비용이 많이 들지 않습니다.2. 응용프로그램 모니터링앱이나 서버에서 발생하는 크래시와 예외를 수집하는 도구 역시 장애 예방에 필수입니다. 해당 기능을 실시간으로 제공하는 다양한 서비스들이 존재하는데 많이 쓰이는 것으로는 Sentry, Rollbar, Airbrake, NewRelic APM 등이 있습니다. 대부분 5분만에 설정이 가능한데다 어느것을 선택하더라도 핵심 기능에는 부족함이 없습니다.단, 현재까지 가성비로는 Sentry가 제일 뛰어납니다. Python의 Flask와 Jinja의 개발자로 유명한 Armin Ronacher가 팀에 합류했기에 발전가능성 측면에서도 많은 기대가 됩니다.Sentry의 실시간 에러 대시보드3. 데이터베이스 모니터링팀에 DBA가 있나요? 모든 서버 개발자들이 인덱스와 스토리지 엔진의 특징에 대해 잘 이해하고, DB를 능숙하게 다루나요? 그것도 아니라면 개발자들이 작성한 모든 스키마와 쿼리에 대한 검증 과정을 거치고 있나요? 만약 그렇지 않다면 슬로우쿼리 모니터링은 필수입니다.우리가 서비스 초기에 겪은 문제의 대부분은 인덱스를 잘 다루지 못하거나 새로 도입한 ORM에 대한 이해도가 낮아서 발생한 문제였습니다. 그 중에서도 특정 쿼리가 너무 많은 I/O를 유발하던 것이 주된 원인이었으며, 작고 가벼운 쿼리가 너무 많이 호출되어 문제가 된 경우는 거의 없었습니다.잘못 설계된 스키마나 쿼리는 평소에는 드러나지 않다가 사용자가 몰리기 시작하면 큰 부하를 발생시켜서 기어이 서비스를 마비시키곤 합니다. 문제가 커지기 전에 그 조짐을 감지할 수는 없을까, 고민 끝에 우리가 시도한 방법은 “2초 이상 수행되는 쿼리에 대해서 로그를 남기고, 초당 3개 이상 로그가 발생할 경우 알림”을 받도록 하는 것이었습니다.MySQL에서는 아래 설정으로 로그를 활성화시킬 수 있습니다.[mysqld] long_query_time=2 # 2초 이상 수행되는 쿼리에 대해서 slow_query_log=1 # 로그를 남겨주세요 쿼리 분석에는 Percona의 pt-query-digest 를 추천합니다. VividCortext 혹은 MONyog 등의 솔루션은 시각적으로 화려하고 실제로도 강력한 기능을 갖추고 있지만, 유료라는 큰 단점이 있습니다.모니터링을 통해 알림을 받게 되면 문제가 더 커지기 전에 해당 기능을 수정하거나 중단시킬 기회가 생깁니다. 특히 새롭게 추가한 기능을 배포할 때 서비스가 불안해 질 수 있는데, 퍼포먼스 문제를 미리 발견하고 롤백을 서두를 수 있다는 것도 장점입니다.물론 가장 이상적인 상황은 n초 이상 수행되는 쿼리를 모두 없애는 것입니다. 하지만 현실은 튜닝을 포기하고 테이블을 풀스캔하도록 두는게 나은 선택일 수 있으며, OLAP/ETL 인프라가 별도로 구축되어 있지 않은 상황에서는 어쩔 수 없이 슬로우쿼리가 발생하게 됩니다. 우리가 초당 로그 갯수로 판단을 하게된 것도 이러한 이유 때문이었습니다.자동으로 슬로우 쿼리를 받아보면 문제해결에 도움이 됩니다.4. 배치 작업(scheduled task) 모니터링매일 백업 스크립트를 돌리고는 있는데, 백업이 정상적으로 완료가 되었는지는 어떻게 판단하면 될까요? 에러는 위에서 설명한 도구들로 확인이 가능하겠지만 스크립트가 수행도중 멈춰버렸거나, 서버의 전원이 꺼졌다면? 게다가 크론 작업(crontab)이 수십개가 넘어가면 이를 수동으로 체크하는 것도 일이므로, 반드시 자동화해야 합니다.이러한 상황에서 활용할 수 있는 유용한 도구가 PushMon 입니다. PushMon은 정해진 시간에 ping을 보내지 않으면 이메일이나 SMS로 알림을 주는 서비스로, 원리는 매우 단순하나 없어서는 안될 기능을 “무료”로 제공합니다.모니터링에 대응하기모니터링을 효율적으로 하기 위한, 즉 서비스 안정성을 높이기 위한 핵심 원칙은 “필요한 인원이 필요한 알림만 받는것”입니다.알림이 너무 많이 와서 음소거(Mute)를 하고 싶은 생각이 든다면 모니터링 체계에 문제가 있다는 신호입니다. 불필요하게 많은 경고는 안전 불감증을 낳을 뿐더러 정작 중요한 경고를 놓칠 확률을 높이기 때문입니다. 치명적인 알림은 모든 채널로 즉각 수신하고, 경고성 알림은 메일로 수신하되 정기 리포트나 메일함 자동분류 기능을 이용하여 중요한 정보를 놓치지 않는 습관이 중요합니다.불필요하게 많은 인원이 알림을 받는 상황도 문제입니다. 알림 수신자를 늘리면 모니터링의 퀄리티가 높아질 것이라고 생각하지만 절대 그렇지 않습니다. 오히려 방관자 효과가 발생하여 아무도 알림에 대응하지 않는 상황이 발생하게 됩니다. 따라서 알림이 발생했을 때에는 1차, 2차 담당자를 사전에 지정하고 운영할 필요가 있습니다.방관자 효과의 적절한 예팀에서 Slack을 사용한다면 기능 연동을 통해 실시간으로 이슈를 파악할 수 있고, 담당자 지정을 보다 쉽고 명확하게 할 수 있습니다. 특히, 별것 아닌 이모티콘(emoji) 만으로도 방관자 효과를 크게 줄일 수 있는데, 예를 들면 아래와 같습니다.👀 - 확인중 ✅ - 확인 완료 😱 - 확인은 하였으나 나는 해결을 못하겠음Sentry를 Slack에 연동한 모습또한, 모니터링 시스템에 대한 모니터링도 중요합니다. SaaS를 이용하는 경우에는 최악의 경우 해당 서비스의 점검기간에 대비할 수 없으며, 심지어는 점검중이라는 사실 조차 인지하지 못할 수 있습니다. 이에 대비하기 위해 리디북스에서는 Server Density로 모니터링을 모니터링하고 있습니다.맺음말장애를 얼마나 꼼꼼하게 예방하는지, 그리고 얼마나 즉각적으로 반응하는지는 팀 구성원의 실력으로 정해지는것이 아니라 팀의 문화와 원칙에 따라 정해집니다. 아직 팀에 뚜렷한 대응 원칙이 없다면 먼저 상황에 맞는 기준과 척도를 결정하고 공유해볼 것을 추천합니다.무엇보다 DevOps를 수행하는 것은 사람임을 잊지 말아야 합니다. 인간은 99.99% 가용성이나 24/7 을 보장하지 못하며, Uptime은 하루도 되지 않습니다. 최근 DevOps가 대세가 되어가지만 Ops에서의 인간적인 측면은 진지하게 고려되지 않고 있습니다. 이러한 환경을 개선하기 위한 HumanOps에 대한 소개와 함께 글을 마칩니다.     HumanOps 계명시스템을 만들고 고치는 것은 인간이다.인간은 지치고 스트레스를 받으며, 행복과 슬픔을 느낀다.시스템은 아직 감정이 없다. 오로지 SLA만 있다.인간은 스위치 온/오프 상태를 반복해야 한다.시스템을 운영하는 인간의 행복이 시스템의 안정성에 영향을 준다.빈번한 알림 == 인간의 피로최대한 자동화하고, 최후의 수단으로 인간에게 이관하라.문서화하고, 훈련하고, 시간을 아껴라.창피 주지 마라.인간의 문제는 시스템의 문제다.인간의 건강은 사업의 건강에 영향을 준다.인간 > 시스템#리디북스 #개발 #DevOPS #모니터링 #인사이트 #서버개발 #운영 #꿀팁

요즘 Software architecture 라는 단어를 들으면 아마도 Client engineer 분들은 MVC, MVP, MVVM 이 먼저 떠오를 것이고, Server engineer 분들은 Microservice architecture 를 먼저 떠오를 것 같네요. Clean architecture 나 Event-driven architecture 등을 떠올리는 분들도 계실 것 같구요. Software architecture 를 어떻게 정의할 수 있을지에 대해서는 Software architecture: The important stuff 에 적어 봤으니 여기에선 넘어가도록 하죠. https://mherman.org/blog/developing-microservices-node-react-docker/ Microservice architecture 는 대세라고 말할 수 있습니다. Netflix, Amazon 등 굴지의 기업들이 성공적으로 적용해서 운영하고 있고, 국내 기술적으로 뛰어난 많은 기업들 역시 이미 적용했거나 시도하고 있습니다. “남들 다 하는데 이러다 도태 되는거 아냐?” 라는 생각이 들 정도로 말이죠. 그러나 이전 글에서 얘기했듯이 정답은 없으며, Microservice architecture 역시 예외는 아닙니다. 모든 선택에는 Tradeoff 가 있고, Microservices 는 다른 architecture 에 비해 어떤 장점이 있는지 살펴봐야 합니다. 이와 관련하여 정말 많은 좋은 글들이 이미 있으니, 이 글에서는 몇 가지 Software architecture 들을 가볍게 정리 및 비교해 보도록 하겠습니다. Monolithic Architecture Monolithic architecture 는 Microservice architecture 의 장점을 얘기할 때 반드시 언급될 정도로 대척점에 있는 architecture 입니다. Monolithic architecture 는 하나의 큰 덩어리로 구성되어 있고, 모든 기능이 하나의 프로젝트에 집중되어 있습니다. 쉽게 구성이 가능하고 초기에 기능을 빠르게 추가하기에 용이하나, 복잡도가 늘어날수록 기능 추가 속도가 느려지고 문제가 발생할 가능성이 높습니다. PoC(Proof of Concept)를 위한 가벼운 프로젝트나 아주 초기 프로젝트에 적용 가능합니다. Semi-Monolithic Architecture Monolithic architecture 보다는 작지만, 여전히 기능들이 몇 개의 프로젝트에 집중되어 있는 architecture 입니다. 예를 들어 frontend 와 backend 프로젝트를 나누었지만 각 프로젝트가 monoliths 인 경우 semi-monolithic architecture 라고 볼 수 있습니다. 다만 Semi-monoliths 의 경우 몇 군데에서 언급한 것을 볼 수 있지만, 일반적으로 사용되는 architecture 용어는 아닌 듯하고, Semi-monoliths 로 구분될 수 있는 경우 Monolithic architecture 라고 분류할 수 있을 듯합니다. 단순 frontend / backend 보다 좀 더 많은 수의 service 로 분할된 architecture 를 구성하더라도 각 service 가 monoliths 로 구분될 수 있다면 여전히 monolithic architecture 를 구성하고 있다고 할 수 있습니다. Service-Oriented Architecture 여러 조직이 다수의 application 사이에서 로직과 데이터를 공유하기 위해 제안된 architecture 입니다. Monolithic architecture 와 달리 기능을 나눠서 여러 개의 서비스로 구성하고, 서비스 사이는 API 를 통해서 통신합니다. Microservice architecture 와 Service-oriented architecture (SOA) 를 비교하기 위해 Enterprise Service Bus (ESB)가 많이 언급됩니다. ESB는 Enterprise Application Interface (EAI) 와 대조적으로 가볍고 흔한 통신을 위해 제안되었으나, 통제와 관리를 위해 점점 무거운 방향으로 진행되면서 최초의 의도와 달라졌습니다. SOA 가 무거워짐에 따라 최초의 의도였던 빠른 적용, 민첩한 개발 및 적은 통합 비용과 멀어지게 되면서 자연스럽게 도태되었습니다. 서비스 사이에 데이터베이스를 공유할 수 있느냐 아니냐로 Microservice 와 구분을 짓는 의견도 있습니다만, SOA의 정의가 넓어서 이 부분에 대해서는 이견들이 있습니다.   https://dzone.com/articles/microservices-vs-soa-2 SOA가 넓은 범위에서 정의됐기 때문에 ESB 나 DB 공유 여부로 SOA 를 규정 짓기는 어렵습니다. 정의 상으로 보면 Microservice architecture 역시 SOA 의 일종이라고도 볼 수 있습니다. Microservice 의 예시로 자주 등장하는 Netflix 와 Amazon 역시 Microservice 라는 단어가 사용되기 전에는 스스로의 시스템을 SOA 라고 지칭했습니다. Microservice Architecture: The O’Reilly Book 의 공동 저자 Matt McLarty 는 Learn from SOA: 5 lessons for the microservices era 라는 글에서 SOA 와 Microservice architecture 가 같은가 다른가는 그다지 중요한 것이 아니며, 우리가 SOA 로부터 어떤 것들을 배웠는가가 중요하다고 강조합니다. Microservice Architecture Microservice architecture는 규모가 빠르게 커져도 제품 생산 속도를 빠르게 유지하고 안정성을 가질 수 있는 architecture 입니다. 충분히 작은 서비스들이 서로 통신하면서 기능을 수행합니다. Microservice architecture 를 SOA의 잘 구현된 형태라고 보는 시각도 있지만, micro 라는 단어가 SOA 에서 정의하는 서비스보다 작은 크기의 서비스임을 명시적으로 표현하기 때문에 매우 다르다는 의견 역시 있습니다. Microservice architecture 는 각 서비스의 크기를 작고 가볍게 유지함으로써 더 깔끔하고 명확하게 서비스를 유지할 수 있습니다. 잘 구성될 경우 특정 서비스에 장애가 생겨도 다른 서비스에 영향을 적게 미치거나 유연하게 대응할 수 있기 때문에 전체 시스템 오류(e.g Single Point of Failure)를 방지할 수 있습니다. 각 서비스는 독립적으로 배포 및 확장 가능하기 때문에 기능 배포가 빠르고 많은 트래픽에 유연하게 대처할 수 있습니다. 한편 Microsoft architecture 는 구조적인 면에서 복잡도가 증가하며, 많아진 서비스 및 서비스 간 통신에 대한 유지 보수 비용이 추가됩니다. 이를 대응하기 위해서 충분히 자동화되고 잘 구성된 시스템이 필수적으로 필요합니다. Conclusion 판단과 결정은 근거를 필요로 합니다. 가끔 감을 믿고 밀어붙여야 할 때(e.g 오늘 점심은 해장국을 먹어야 한다던가)도 있다는 점은 인정합니다. 하지만 그 역시 설득력을 가지지 못하면 하나의 목표를 향해 모두가 미친듯이 달려가기는 어렵겠죠. Software architecture 를 결정하기 위해서는 추구하는 비전과 비지니스를 이해하고 그에 맞는 근거 하에 모든 팀원을 판단하고 설득해야 합니다. 버즈빌 에서는 더 빠르고 큰 성장을 위해 Architecture Task Force 팀을 구성하였습니다. ATF 팀은 버즈빌에 최적인 Software architecture 를 판단하고, 구성하고, 실행하기 위해 바쁘게 움직이고 있습니다. Buzzvil Services Characteristic:  제품이 다양하고 제품별로 제공해야 할 기능이 많다. 각 제품이 공통적으로 필요로 하는 기능이 많다. 서비스 혹은 기능별로 대응해야 하는 트래픽이 다르다. 전체 서비스 장애 발생 시 많은 후속 문제가 발생한다. 트래픽 변동이 특정 이벤트에 의해 크게 일어날 수 있다.  Buzzvil 의 제품과 비지니스는 위와 같은 성격을 가지고 있습니다. 이를 바탕으로 우리는 Microservice architecture 가 가장 적절하다고 판단하였고, 현재 microservices 의 장점을 살리면서 안정적이고 빠르게 우리가 원하는 목표에 도달할 수 있도록 다양한 방면에서 변화를 가져가고 있습니다. References  Learn from SOA: 5 lessons for the microservices era Microservices vs. SOA On monoliths, service-oriented architectures and microservices Microservices.io Microservices Resource Guide Design Microservice Architectures the Right Way Developing Microservices – Node, React, and Docker    *버즈빌에서 개발자를 채용 중입니다. (전문연구요원 포함)작가소개 Whale, Chief Architect “Keep calm and dream on.”

오후 두 시의 회의실. 개발자들의 스터디하는 소리로 뜨겁다. 국내 최고의 추천 기술을 보유했다는 데이블. 10년 이상의 경력을 가진 노련한 시니어 개발자들 사이에서, 스쳐 지나가는 단어 하나하나 놓치지 않으려 귀 기울이고 있는 주니어 개발자들을 만났다.안녕하세요? 간략한 소개와 두 분의 업무에 관해 설명해주세요.형주: 안녕하세요? 저는 데이블 개발팀 최형주입니다.저는 백앤드 개발팀의 신입 개발자로서 데이블의 인프라 관리, 백앤드 개발 그리고 가끔 데이터 분석을 하고 있습니다. 주로 사용하는 서버는 클라우드 플랫폼인 AWS(Amazon Web Service)과 Nodejs 이고, MySQL, Redshift, Python을 사용하여 데이터 처리와 분석을 하고 있어요.성현: 안녕하세요. 저는 데이블 개발팀 이성현입니다.제 메인 업무는 데이블 위젯의 스타일링과 관련 문제 해결입니다. 고객사 페이지를 분석해서 위젯 디자인을 만들고, 추천 결과가 안 나오는 경우에 문제를 수정하는 작업입니다. 특별한 기능이 필요한 위젯이 있으면 스크립트 작업도 하고요. 작업 도구는 회사 내부 시스템이 있어서 그 안에서 직접 작업하고, CSS로 작성합니다.위 업무가 메인이지만 다른 영역과 겹칠 때도 잦아서 회사에서 사용하는 여러 시스템을 만질 수 있어야 합니다. 도구는Html+CSS+js 외에 Node, gulp, react, angular angularJS, PHP, 젠킨스, AWS, MYSQL, git를 사용하고 있습니다.두 분 다 신입 개발자이신 만큼 회사를 선택하는 데 있어 신중했을 것 같아요.데이블을 선택한 이유는 무엇인가요?형주:  저는 대학원에서 빅데이터 처리관련 연구를 주로 했었어요. 졸업할 때쯤 제 전공과 관련된 회사에 지원했었고 많은 면접을 보았습니다. 여러 회사에서 면접을 봤지만 데이블에서 봤던 면접 경험이 만족스러웠고 특히 개발자들의 실력과 내공이 느껴져 신입으로서 많은 것을 배우고 싶어서 입사하게 되었습니다. 복지 또한 여느 알려진 회사들에 비해 부족하지 않아서 굉장히 만족하고 있습니다.성현: 처음 데이블에 호감을 느끼게 된 건 기술 중심 스타트업이라는 점이었습니다. 도전하는 자세, 유연한 사고, 성장 가능성, 복지 등 여러 가지 기준들이 있겠지만, 내가 재미를 느낄 수 있는가, 개발자로서의 성장 이 두 가지로 압축되었어요. 저 같은 경우에는 블로그를 보면서 회사 분위기를 대략 파악했던 것 같네요. 자유로운 분위기도 잘 느껴지고, 서로를 배려하면서 열심히 일하는 것을 간접적으로 경험할 수 있었어요. 면접 보러 갔을 때, 블로그에서 보던 사람들이 블로그 글과 비슷한 느낌으로 편하게 얘기하는 걸 보면서 마음을 굳히게 됐어요.데이블의 분위기는 어떤가요?형주: 분위기는 실제로 굉장히 수평적입니다. 서로 존댓말을 사용해서 존중받는 기분이 들어요.성현: 저는 데이블 오기 전에 잠시 다른 회사에 있었는데, 거기서는 과한 예절이나 눈치를 보는 분위기가 있었어요. 데이블은 수평적인 분위기이다 보니 스트레스 받지 않고 일에 집중할 수 있어 좋아요.형주: 저 같은 경우, 잠에 굉장히 민감한 편인데 출퇴근이 탄력적이어서 지각에 대한 스트레스가 없어서 좋아요. 그래서 저는 보통 9시 넘어서 일어나서 10시쯤 출근하고 7시쯤 퇴근하는 편입니다. 그리고 식대도 지원해주고 있어요~성현: 매일 4시쯤 회사가 지원하는 간식 타임이 있어요. 오랜 시간 앉아서 일하다 보면 집중력 떨어질 때 쯤 다 같이 모여 대화를 나누면서 간식을 같이 먹습니다. 만약 생일이 있으면 간식 타임과 더불어 생일 파티를 해요.형주: 간식과 음료수가 항상 냉장고에 갖춰져 있어서 먹을 것을 좋아하는 사람에게 최고인 것 같아요. 저는 살이 잘 안 찌는 체질인데 입사 후 2킬로가 쪘어요.성현: 거의 슬랙과 트렐로 위주로 업무를 하는데 간식 타임에는 여러 사람과 대화를 할 수 있어 좋습니다. 서로 대화도 같이하고, 같이 활동할 수 있는 시간을 마련하기 위해 ‘플레이 데이’ 도 2개월에 한 번씩 열고 있어요! 회사-집, 집-회사를 반복하다가 다 같이 뭔가를 하니 신선했어요. 업무 외적으로 같이 활동하면서 사람들과 친밀감을 느낄 수 있어서 좋았어요.데이블을 선택했던 이유 중 개발자로서 성장 가능성도 있었는데 이것은 어떻게 채워지고 있나요?성현: Dabler, Be The Expert 프로그램(이하 BTE 프로그램)이 있고 업무 관련 스터디도 활발히 진행하고 있어요.자세히 설명해주세요. 성현: BTE 프로그램의 경우 장기목표를 정하고 반기별로 관련 학습 계획을 세워요. 그 안에서 책도 사고 강의도 신청하고 하는 거지요. 스스로 목표를 잡고 자유롭게 계획을 세울 수 있어서 좋아요. 본인이 정말 원하는 것을 배울 수 있고, 필요한 자금은 회사가 지원하는 거죠. 단, 업무에 관련된 성장 계획이어야 한다는 가이드라인이 있어요.이 외에도 백엔드 개발자들과 함께 AWS 사용법을 주제로 스터디도 해요! 보통 프론트엔드를 담당하지만, 백엔드 영역도 경험할 수 있어요. 본인 스스로 영역을 넓히기 위해 공부하고 능력이 된다면 활동 범위가 굉장히 넓어져요. 회사 차원에서도 그런 시도를 장려해요. 빨리 성장해야겠다는 욕심이 있어요.형주: 전 회사에서 일주일에 2번 모여서 스터디도 하고 있고 MOOC 강의를 수강하거나 책을 사고 싶을 때 눈치 볼 필요 없이 신청하면 돼요. 그리고 반기별로 자기 개발을 잘한 직원에게 인센티브를 줘요.※BTE 프로그램이란?그럼 두 분은 BTE 프로그램을 통해 어떤 것들을 배우고 계시는가요?형주: 저는 Coursera에서 Recommender System 수업을 듣고 있어요. 아무래도 우리 회사의 핵심기술이 추천 기술이다 보니까 이쪽 분야를 깊게 공부해야겠다는 생각이 들었습니다.성현: 저는 웹을 능숙하게 다루고 싶어서 상반기에는 인프라, 자바스크립트, 웹 표준, node 등 기본을 다시 챙기고 하반기에는 웹 최신 기술을 공부하려고 해요.지금은 자바스크립트 관련 책 3권과 강의 2개를 신청해서 주로 퇴근 후 또는 주말에 듣고 있어요. 업무와 관련된 것을 공부하고 나서 코드를 작성하면 대충 넘어갔던 부분들이 보여요. 그 부분을 놓치지 않고 수정하고 개선하다 보면 예전보다 나은 결과물이 나오고 뭔가 아는 게 늘었구나! 하는 보람을 느낍니다.데이블에서 개발자로 일하며 느끼는 점형주: 저의 경우에는 신입 개발자 관점에서 경험 많은 개발자분의 피드백을 통해 노하우를 전수하는 점이 좋았어요. 그러면서 기존에 놓치고 있던 부분이나 실무와 이론 사이의 괴리감을 좁히는 경험이었습니다. 저도 학부, 대학원 시절 많은 코딩을 했지만 제가 작성한 코드가 잘 작성된 코드인지 잘 읽히는 코드인지는 스스로 공부하기 힘들었는데 이러한 피드백을 통해 성장함을 느꼈습니다.어려웠던 점은 우리 회사는 애드테크 회사이다 보니 광고 용어를 굉장히 많이 사용하는데 광고에 관해 얘기할 때 처음에는 광고 용어를 몰라 답답했었는데, 스터디를 만들어서 어려운 점을 조금은 해소할 수 있었어요.성현: 자기만 할 수 있으면 얼마든지 여러 프로젝트에 참여할 수 있는 문화가 좋아요. 예를 들면 저는 위젯 담당이지만, 위젯 업무 틈틈이 데이블 시스템 페이지 수정을 할 수도 있고 내부 DB를 이용해서 사업팀에게 도움이 되는 통계 페이지를 만들기도 해요. 얼마 전에는 커뮤니티에 데이블 추천 기능을 직접 넣는 프로젝트를 했습니다. 보통 추천 연동은 고객사가 하고 저는 위젯만 만들고 있었거든요. 이번에 고객사 입장에서 서버 쪽을 만져본 거죠.미래의 데이블은 어떤 모습일까요?형주, 성현: 세계 No. 1 콘텐츠 디스커버리 플랫폼! 경영진이 자기 개발 지원이나 복지에 신경을 많이 쓰고 있어서 계속 나아질 것 같아요.데이블의 개발자가 되기 위해 어떤 것들이 필요할까요?형주: 제가 생각하기에 시니어 개발자분들이 가장 중요하게 여기는 부분은 CS 분야의 기본기였던 것 같습니다. 이 기본기를 통해 자주 사용하는 툴이나 오픈 소스가 내부적으로 어떻게 구성되어 있고 동작하는지에 대한 공부를 하면 도움이 될 것 같습니다.성현: 저는 주도적인 자세요! 스스로 일하고 배우는 자세가 필요합니다. 다른 개발자와 소통하면서도 자기 일의 진행 관리나 조율은 스스로 해야 해요. 다음 일을 직접 찾아야 할 때도 있고요. 또 전부를 물어볼 수는 없으니 어느 정도 혼자 찾아 공부하는 습관도 필요해요. 그리고 자기가 지원하는 포지션에서 사용하는 핵심 기술 하나는 능숙하게 사용할 수 있어야 해요. #데이블 #팀원 #개발자 #개발팀 #개발 #팀원소개 #인터뷰 #기업문화

Overview브랜디 랩스를 사랑해주시는 여러분, 안녕하세요. 개발자 오-연주입니다. 지난 4월, Brandi Back-end 개발자 분들과 코엑스에서 열렸던 AWS Summit(04.18 - 04.19)에 다녀왔습니다!여러 세션을 듣는 와중에 우연히 AI machine learning 를 쉽게 도와주는 Cloud Machine learning Flatform인 Amazon SageMaker에 대해 들었습니다. 듣던 중 머닝러닝에서 학습을 시켜 그 데이터로 ‘Brandi 서비스와 연관지으면 어떨까’ 라는 생각을 했는데요. 그래서 오늘은 많은 분들의 관심사인 머신러닝 학습관련 Amazon Amazon SageMaker에 대한 글을 쓰려고 합니다.sage는 마법사, 현자라는 의미입니다.sageMaker를 create하자!“자, 퐈이팅 넘치게 신나게 sagemaker를 create해볼까요!” 했는데…Seoul Region이 없다!현재 지원되는 리전은 아직 네 군데입니다. 저는 제일 있어 보이는 미국 동부의 버지니아를 선택하겠습니다.1] EU (Iceland) 2] US West (Oregon) 3] USEast (N. Virginia) 4] US East (Ohio)SageMaker를 create하기 전에는 학습할 데이터와 학습 모델을 저장할 S3 Bucket이 필요합니다.1. Default 값으로 S3를 만드세요.중요한 점은, bucket 이름이 “sagemaker-” 로 시작되어야 한다는 것입니다. 그래야 나중에 notebook instance가 어느 곳에 데이터를 저장할지 알 수 있습니다.Next, Create bucket 버튼을 누르다 보니, S3 Bucket이 생성되었습니다.2. Create notebook instance 버튼을 눌러 SageMaker를 만들어 봅시다!원하는 이름을 지어줍니다. 저는 machineLearningTest 라고 지었어요. IAM role 선택하는 부분에서 None을 눌러 Default 값으로 sageMaker를 만듭니다.인고의 Pending 시간3. Pending이 끝나고 “open” action을 선택하면 Jupyter가 열립니다.Jupyter(Jupyter Notebook)는 오픈 소스로 라이브 코드, 등식, 코드에 대한 시각화를 위해 사용됩니다. 또한 description을 위한 텍스트 문서(마크다운 등)를 지원하는 웹 어플리케이션입니다. 이렇게 하면 코드에 대한 문서화가 가능합니다. 이 글에서는 Jupyter Notebook을 통해 데이터를 학습하고, 그 데이터를 테스트하겠습니다. 제가 진행한 전체 코드 스크립트(entire script)는 이 글의 마지막 부분에 기술있으니 참고해 주세요.자, 이제 드디어 머신러닝 학습을 시킬 차례입니다. 머신러닝 학습에 꼭 필요한 키워드 두 가지를 뽑아봤는데요. - Dataset: 정제된 데이터와 그 데이터에 대한 label을 정리해 놓은 데이터 모음      - Machine learning Algorithm: 기계학습 알고리즘 우리는 MNIST 데이터셋을 k-means 알고리즘으로 학습시킬 겁니다.1)MNIST Dataset기계학습 알고리즘을 사용할 때 가장 기본적으로 테스트하는 데이터셋으로 MNIST 데이터셋이 있습니다. 이것은 사람이 0부터 9까지 숫자 중 하나를 손글씨로 쓴 이미지 데이터와, 해당 이미지에 대한 레이블(0 - 9)이 6만 개 들어있는 학습 데이터셋입니다. 각 이미지는 가로와 세로가 각각 28 픽셀로서, 각 픽셀은 0부터 255 사이의 숫자가 있습니다. 다시 말해, 하나의 이미지는 28 x 28 = 784개의 숫자로 이루어진 데이터입니다. 하나의 이미지를 나타내는 데이터의 array > length가 784라고 표현할 수 있겠네요.MNIST dataset2)k-means지금 만든 SageMaker 학습 알고리즘은 AWS 튜토리얼에서 제시한 K-means를 사용할 예정입니다. k-means는 label 없이, 즉 정답을 모르는 상태로 학습을 하는 비지도 학습 (unsupervised learning) 알고리즘 중 가장 쉽고 많이 쓰입니다. 정답을 모르니, ‘비슷한 애들끼리 뭉쳐봐’ 라고 하고, 알고리즘은 비슷한 친구들끼리 뭉쳐 놓습니다. k-means에서 k는 ‘k개 덩어리로 뭉쳐주세요’라고 제시하는 숫자입니다. 우리는 0부터 9까지 비슷한 친구들끼리 모이게 하고 싶으니 k=10을 쓸 겁니다.지금부터 해야 할 TO DO!1. MNIST 데이터셋을 다운로드받고, 우리가 학습시키기 좋도록 정제하기(preprocessing)2. Amazon SageMaker를 통하여 데이터 학습시키기(training job)3. Amazon SageMaker를 통하여 학습된 데이터를 배포하기(Deploy the model)4. 배포된 모델에 요청을 보내 테스트 데이터에 대한 예측값을 받아오기(inference)4. Jupyter 노트북 인스턴스 생성하기Jupyter에 New Notebook(conda_python3)을 선택해 새로운 노트북을 생성합니다.5. 학습시키기 위한 기본 셋팅드디어 코딩 시작입니다! (의욕활활) 초기 설정해두었던 IAM role, S3 Bucket, MNIST 다운로드, 다운받은 데이터 등을 확인하세요. 글보다 코드로 주석을 보는 게 가독성이 더 좋습니다. 아래 노트북을 통해 마크다운, 주석처리를 통해 description을 해두었으니 참고 바랍니다.외부에서 MNIST 다운로드가 쉽도록 한 url로 MNIST를 다운받는데 성공했습니다. MNIST 데이터셋 내용물 중 하나를 jupyter notebook에 그려서 제대로 다운 받았는지 show_digit() 함수를 작성해 확인하겠습니다.서른 번째 데이터는 누군가 3을 손글씨로 쓴 이미지입니다.6. 머신러닝 학습하기이 세션에서는 기계학습 알고리즘 설정, 학습할 데이터 경로를 지정하겠습니다. 그 후 MNIST 학습 데이터를 S3 버킷에 옮겨 저장합니다.kmeans.fit() 함수를 호출해 직접 학습을 시켜볼까요? 학습 과정은 상당히 오래 걸린다고 했는데 다행히 4분 만에 학습이 끝났습니다.여기서 잠깐! 여기서 k = 10에 대해서 조금 더 알아보도록 할게요. cluster란 한 지점에 점을 찍고 데이터 분석을 한 뒤, 비슷한 데이터들의 군집을 만들어 주는 것입니다. k-means가 진행되면서 각 cluster의 중심이 서로가 잘 뭉치는 방향으로 이동합니다. 직접 그려봤어요(부끄).7. 학습된 모델을 배포하기학습을 시키면 테스트를 하거나 사용할 수 있어야겠죠? 학습된 모델을 배포해 주세요.8. 배포된 모델 테스트 진행하기배포된 모델에 valid_set 데이터로 검증 데이터를 진행합니다..predict() 함수를 호출하면 새로운 이미지가 어떤 cluster에 속했는지 예측 결과를 알려줍니다. 가장 가까운 cluster가 0번이라고 예측 결과를 반환했네요. 또한 cluster 중심과의 거리는 5.85라고 알려줍니다. 여기서 중요한 점은 cluster 번호와 실제 숫자는 일치하지 않는다는 겁니다. 알고리즘은 임의로 cluster 중심에 번호를 매기는데, 꼭 0번 클러스터가 숫자 ’0’을 뭉쳐놓은 건 아니에요!9. 데이터 예측해보기더 많은 데이터를 예측해볼까요? valid set에 있는 100개 데이터를 예측해봅시다! 각 cluster에 가까운 데이터들이 쭉 선정되었습니다. 정확하지는 않지만 비슷한 숫자 모양들이 서로 군집되어 나타납니다. 0과 2같은 숫자들은 잘 표현되지만, 알고리즘이 9랑 4를 헷갈리거나 5와 3을 헷갈리는 듯 하네요.FASHION MNIST로 SageMaker 머신러닝 학습 및 예측해보기자, 이제 몸도 풀었으니 제가 하고 싶었던 패션 관련 머신러닝 학습 및 예측을 진행해볼게요. 마침 옷 그림으로 MNIST와 매우 비슷한 데이터를 만들어 놓은 fashion-MNIST라는 데이터셋을 발견했어요!1. 패션 관련 MNIST 다운로드 받기패션 MNIST 데이터셋을 우선 다운받아 볼게요! 다운로드는 여기에서 받을 수 있습니다. 총 네 개의 파일을 다운로드 받으세요.- train-images-idx3-ubyte.gz : train set 이미지  - train-labels-idx1-ubyte.gz : train set 레이블  - t10k-images-idx3-ubyte.gz : test set 이미지  - t10k-labels-idx1-ubyte.gz : test set 레이블  다운로드 받은 패션 Mnist의 label은 아래와 같이 되어 있습니다. 숫자 0부터 9 대신에 각 이미지가 어떤 이미지인지 텍스트로 표현되어 있어요.LabelDescription0T-shirt/top1Trouser2Pullover3Dress4Coat5Sandal6Shirt7Sneaker8Bag9Ankle boot2. Fashion-MNIST 데이터셋을 이전에 사용했던 mnist.pkl.gz 와 같은 형태로 변환해주는 스크립트 작성해주기위에서 연습할 때는 mnist.pkl.gz 한 개 파일만 사용했는데요!?! 그래서 다운로드 받은 네 개의 파일을 똑같은 형식의 파일 하나로 만들어주는 파이썬 스크립트를 작성해 fashion-mnist.pkl.gz 파일로 만들었어요.import gzip import pickle import numpy as np # MNIST 데이터셋은 train, test 셋이 각각 image, label로 나누어 저장되어있는 4개의 파일로 구성 test_image_path = 't10k-images-idx3-ubyte.gz' test_label_path = 't10k-labels-idx1-ubyte.gz' train_label_path = 'train-labels-idx1-ubyte.gz' train_image_path = 'train-images-idx3-ubyte.gz' out_file_name = 'fashion-mnist.pkl.gz' # train label / images 추출 with gzip.open(train_label_path, 'rb') as train_label_f:     train_label = np.frombuffer(             train_label_f.read(), dtype=np.uint8, offset=8).astype(np.int64)   with gzip.open(train_image_path, 'rb') as train_image_f:     train_imgs = np.frombuffer(             train_image_f.read(), dtype=np.uint8, offset=16).reshape(-1, 784).astype(np.float32)   # test label / images 추출 with gzip.open(test_label_path, 'rb') as test_label_f:     test_label = np.frombuffer(test_label_f.read(), dtype=np.uint8, offset=8).astype(np.int64)   with gzip.open(test_image_path, 'rb') as test_image_f:     test_imgs = np.frombuffer(             test_image_f.read(), dtype=np.uint8, offset=16).reshape(-1, 784).astype(np.float32)   # 기존 60000개 training set에서 50000개는 train set으로 사용하고, 10000개는 valid set으로 활용 train_label, valid_label = train_label[:50000], train_label[50000:]  train_imgs, valid_imgs = train_imgs[:50000], train_imgs[50000:]   # train set, validati on set, test set을 튜플 자료형으로 저장 out_data = ((train_imgs, train_label),             (valid_imgs, valid_label),             (test_imgs, test_label))   # pickle file로 dataset 데이터 포맷 맞춰주기 with gzip.open(out_file_name, 'wb') as out_f:     pickle.dump(out_data, out_f) 이 과정을 통해 나온 결과물, fashion-mnist.pkl.gz 를 Jupyter Notebook이 있는 경로에 업로드합니다.fashion-mnist.pkl.gz가 업로드 되었습니다!3. 머신러닝 학습하기아까 사용했던 활용했던 숫자 MNIST 스크립트를 그대로 사용하겠습니다. show_digit()을 이름만 바꾼 show_fashion()으로 데이터를 살펴보니 드레스가 보입니다.조금 전에 했던 숫자 MNIST와 똑같은 과정을 SageMaker를 이용해, 학습 → 테스트 → 예측해보니 아래와 같은 예측 결과를 얻을 수 있었습니다. 신발은 신발끼리, 바지는 바지끼리, 가방은 가방끼리 분류된 게 너무나 신기합니다. (아까 진행한 숫자보다 더 학습이 잘 된 것 같은건 기분 탓일까요…?)머신러닝이라고 겁내지 않아도 됩니다! 유저들에게 더 좋은 서비스 제공할 수 있으니까요. 지금까지 브랜디 개발2팀의 단아한 개발자 오연ㅈ….참사를 막아주세요.앗, 잠시만요!! 중요한 것을 놓칠 뻔 했네요.저처럼 테스트를 하면 그냥 지나치지 마세요. 자동 결제로 출금되는 뼈 아픈 경험을 할 수도 있습니다. 반드시 이용했던 서비스들을 stop 하거나 terminate 해주세요. (Clean-up단계) 자세한 내용은 여기를 클릭하세요.지금까지 Brandi 개발 2팀, 단아한 개발자 오연주였습니다!# entire script (숫자 Mnist) # 오호 드디어 coding start! # 이제부터 Brandi의 단아한 개발자, 저를 따라오시면 됩니다 :) # 노트북 Block을 실행하는 방법은 Shift + Enter 입니다 from sagemaker import get_execution_role role = get_execution_role()  # 초기에 설정해 뒀던 IAM role 가져오기 bucket = 'sagemaker-julie-test' # 초기 단계에 만들었던 S3 Bucket 이름 적기 %%time import pickle, gzip, numpy, urllib.request, json   # 여기서 잠깐, 생소한 라이브러리 설명을 드릴게요! # pickle: python식 데이터 압축 포맷 # numpy: 수치 계산을 하기 위한 python package # Load the dataset urllib.request.urlretrieve("http://deeplearning.net/data/mnist/mnist.pkl.gz", "mnist.pkl.gz") with gzip.open('mnist.pkl.gz', 'rb') as f:     train_set, valid_set, test_set = pickle.load(f, encoding="latin1")     # matplotlib로 그리는 그림이 jupyter 노트북에 바로 보여줄 수 있도록 설정 %matplotlib inline import matplotlib.pyplot as plt # 도표나 그림을 그릴 수 있게 해주는 라이브러리 plt.rcParams["figure.figsize"] = (2, 10) # 그림의 크기 지정 def show_digit(img, caption='', subplot=None):     if subplot is None:         _,(subplot) = plt.subplots(1,1)         imgr = img.reshape((28, 28))     subplot.axis('off')     subplot.imshow(imgr, cmap='gray')     plt.title(caption)   # train_set의 그림과[0] 데이터 이름[1]을 예시로 보여준다 show_digit(train_set[0][30], 'This is a {}'.format(train_set[1][30]))   # 학습을 하기 위해 학습 알고리즘 및 데이터 경로 설정! from sagemaker import KMeans data_location = 's3://{}/kmeans_highlevel_example/data'.format(bucket) output_location = 's3://{}/kmeans_example/output'.format(bucket)   print('training data will be uploaded to: {}'.format(data_location)) print('training artifacts will be uploaded to: {}'.format(output_location))   kmeans = KMeans(role=role,                 train_instance_count=2,  # 장비 2대를 사용하여 학습하겠어요!                 train_instance_type='ml.c4.8xlarge',                 output_path=output_location,                 k=10,  # 아래 그림을 참고해 주세요!                 data_location=data_location) %%time   # 학습 시작! kmeans.fit(kmeans.record_set(train_set[0]))   %%time # 모델을 만든 후 사용하기 위하여 배포하기 kmeans_predictor = kmeans.deploy(initial_instance_count=1,                                 instance_type='ml.m4.xlarge')                                  # valid_set에 30번째 sample을 테스트 해보기 result = kmeans_predictor.predict(valid_set[0][30:31])  print(result)   %%time   # vaild_set에 있는 0번부터 99번까지의 데이터로 cluster를 예측 해보자 result = kmeans_predictor.predict(valid_set[0][0:100])   # 예측 결과에 대한 cluster 정보를 수집 clusters = [r.label['closest_cluster'].float32_tensor.values[0] for r in result]   # 각 cluster별 예측된 이미지 출력 for cluster in range(10):     print('\n\n\nCluster {}:'.format(int(cluster)))     digits = [ img for l, img in zip(clusters, valid_set[0]) if int(l) == cluster ]     height = ((len(digits)-1)//5)+1     width = 5     plt.rcParams["figure.figsize"] = (width,height)     _, subplots = plt.subplots(height, width)     subplots = numpy.ndarray.flatten(subplots)     for subplot, image in zip(subplots, digits):         show_digit(image, subplot=subplot)     for subplot in subplots[len(digits):]:         subplot.axis('off')     plt.show() 출처Getting Started - Amazon SageMaker CodeOnWeb - 머신러닝 초보를 위한 MNIST fashion-mnist 글오연주 사원 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

블록체인에서 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 코인원 슈퍼크루를 소개합니다 :-)올 한해도 모든 크루가 각자의 분야에서 최선을 다했어요.슈퍼크루는 그 중에서도 특히 다른 크루들에게 좋은 영향을 준 크루들을 선정한 것인데요, 이 분들에게는 코인원의 특별한 추가 보상이 제공될 예정이랍니다. :-)코인원은 앞으로도 크루들이 즐겁게 일하면서 성장할 수 있는 여러가지 재밌고 유익한 도전들을 해보려고 합니다. 코인원이 크립토 세상에서 어떤 즐거운 도전들을 하고 있는지, 앞으로도 코인원 공식 블로그를 통해 지켜봐주세요! :-)#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트 #기업문화 #조직문화 #사내복지 #업무환경 #팀원소개

기업의 슬로건은 기업의 이미지를 좌우할만큼 중요하다고 할 수 있습니다.나이키의 'Just Do It' 이나 아디다스의 'Impossible Is Nothing'과 같이 대중의 머릿속에 이미지 그 자체로 각인될 수 있기 때문이죠. 어반베이스가 3D 공간데이터 플랫폼으로서 전 세계의 모든 실내공간정보를 자유롭게 활용할 수 있는 코어 기술과 서비스를 런칭하게 되면서 미래를 향한 메시지를 내포할 수 있는 새로운 슬로건을 만들게 되었습니다. 어반베이스는 과연 어떤 방법으로 새로운 슬로건을 만들었을까요?슬로건도 '어반베이스'답게 만들다어반베이스는 IT 기술 기반의 스타트업인만큼 직원 중 절반 이상이 개발자입니다.그렇다보니, 출퇴근기록 계산기부터 점심알람봇(bot)까지 일상에서 조금이라도 불편한 점이 있다면 개발자분들이 출동하여 프로그램을 만들어 주시곤 합니다.  이러한 문화를 가지고 있는 어반베이스는 슬로건 만드는 방법 또한 '어반베이스'답게 만들어 냅니다. 슬로건에 대한 다양한 아이디어를 얻기 위해 어떤 방법이 좋을지 고민하다가, 진우님(진우님=대표님=건축가 출신 프로그래머)께서 룰렛 하나를 만들었습니다. 같이 살펴볼까요?만들어 공유해 주신 링크를 타고 들어가면 이렇게 깔끔한 룰렛하나가 나오는데요참여방법은 간단합니다.1. 랜덤버튼을 2회 누르면 문장이 완성됩니다. 마음에 드는 문장이 나타나면 아래의 세이브 버튼을 누릅니다. 그 리고 그 문장은 저장되어 하단의 그래프로 반영이 됩니다. 'RANDOM'버튼을 한 번 눌러보았더니 클릭 두번에 슬로건 하나가 탄생합니다.'We Generate Urban'조금 더 나은 슬로건을 위해 RETRY 해 봅니다.이번엔'We Reform The Next World' 가 탄생했습니다.2. 그래도 마음에 드는 문장이 안나오면 보라색 '후리스타일' 버튼을 누르셔서 직접 입력해주시면 우측 리스트에 반영됩니다. (무기명입니다)'후리스타일' 버튼을 누르고 입력한 문장들입니다.이렇듯, 룰렛을 사용해 간단하고 간편하게 많은 문장들을 만들어냈습니다. 몇몇 단어를 가지고 고민하는 것보다, 룰렛을 최대한 많이 돌려서 저장하는 방법을 선택했습니다. '이런식으로도 슬로건을 만들 수 있다니' 재미 반 진지 반으로 어반피플들이 모두 참여하여 슬로건 짓기에 동참했습니다.그러하여 나온 최종 두 가지 안 입니다. We Invent the Next WorldWe Reinvent the World우리는 이 최종 두 가지 안을 가지고 다시 투표를 하였습니다. (다수결의 원칙) 그 결과, 아주 근소한 차이로 우리의 슬로건 탄생!어반베이스의 새로운 슬로건'We Invent The Next World'4차 산업혁명의 시대, 국내 뿐 아니라 전 세계적으로 공간데이터의 높은 활용 가능성에 주목하고 있습니다.3D 공간데이터 플랫폼 어반베이스는 앞으로 “We Invent The Next World” 라는 모토 아래, 보다 앞선 새로운 삶의 모습을 제시하고자 합니다. 2D 도면 이미지를 단 몇 초만에 3차원 공간으로 자동 변환해주는 기술부터가상의 인테리어를 돕는 3D HomeDesign, 3D데이터를 증강현실로 경험할 수 있는 AR Viewer, 머신러닝과 인공지능을 이용한 공간 기반 추천 서비스까지. 전 세계의 모든 실내공간정보를 하나의 플랫폼 안에서 자유롭게 활용할 수 있는 코어 기술 및 서비스를 선보이고자 하오니 많은 기대 부탁드립니다.*2019.01 어반베이스 개발자 사이트 런칭 예정 *2019.02 AR SCALE 런칭 예정출처: https://blog.naver.com/urbanbaseinc 

안녕하세요?크몽(www.kmong.com) 개발자SEAN입니다.오늘은 요즘 말이 많이 나오고있는 IT용어중에서 사물인터넷(IOT)에 대해서 적어 봅니다. 위키피디아의 사물인터넷의 정의는 '사물 인터넷(Internet of Things, 약어로 IoT)은 각종 사물에 센서와 통신 기능을 내장하여 인터넷에 연결하는 기술을 의미한다. 여기서 사물이란 가전제품, 모바일 장비, 웨어러블 컴퓨터 등 다양한 임베디드 시스템이 된다. 사물 인터넷에 연결되는 사물들은 자신을 구별할 수 있는 유일한 아이피를 가지고 인터넷으로 연결되어야 하며, 외부 환경으로부터의 데이터 취득을 위해 센서를 내장할 수 있다.모든 사물이 해킹의 대상이 될 수 있어 사물 인터넷의 발달과 보안의 발달은 함께 갈 수밖에 없는 구조이다.'라고 정의가 되어있습니다.예를 들자면 아침에 집에서 알람이 울리면 그와 동시에 토스트기계가 반응하여 저절로 빵이 구워진다든지 집을 나서기 직전 문앞에서 오늘의 날씨를 알려준다든지, 모든 전자기기에 접목을 시킬수있습니다. 또다른 예를 들자면 카페의자에 센서를 달아서 카페마다 자리가 몇자리 남았는지 몇명이 있는지 등을 파악하여 굳이 찾아가지 않아도 내가 쉽게 자리가 있는 카페를 찾을 수 있습니다.  사물인터넷은 매우 좋지만 쉽게 대중화 되지 못하는 점은 위의 정의와 같이 보안에 매우 취약합니다.예를 들어 위의 카페의 정보를 잘못 보이도록하여 그 카페에 못가게 한다든지, 집안의 기계를 다른사람이 조종을 한다든지의 개인 프라이버시 침해가 발생 할 수있다는 것이겠지요. 그리고 또다른 문제점으로는 비용이 많이 든다는 겁니다. 이 점도 무시를 할 수없겠지요. 조그마한 장비라도 여기저기 붙여야하고 그 기기를 연결도 시켜야하고 쉬운 문제는 아닐 듯합니다.언젠가는 대중화 되는 날이 있겠지요?저도 기대해봅니다.이상 크몽 개발자 SEAN이었습니다.#크몽 #개발자 #개발팀 #팀원소개 #기업문화 #조직문화

김경만님은 오픈서베이의 미들레벨 안드로이드 개발자이자 오베이 시스템 PM(이하 조셉)입니다. 지인 추천으로 2명의 개발자 채용을 도운 오픈서베이 전도사기도 하죠. 이런 조셉은 지원할 때만 해도 오픈서베이가 어떤 회사인지 잘 몰랐다고 합니다. 병특 중인데 TO가 있길래 지원한 게 크죠. 그렇게 덜컥 입사한 오픈서베이를 다니며 잘 갖춰진 업무 환경, 조직 문화, 좋은 구성원에 반해버렸다고 합니다. 병특 복무를 마친 뒤에도 오픈서베이의 훌륭한 구성원으로 5년 차 개발자의 커리어를 쌓아가고 있죠. 조셉에게 오픈서베이에 반한 이유와 개발팀의 업무 문화에 대한 이야기를 들어봤습니다.            오픈서베이 김경만(조셉) 안드로이드 개발자 겸 오베이 앱 PM   조셉, 안녕하세요! 안녕하세요(웃음). 오픈서베이의 미드레벨 안드로이드 개발자 조셉입니다. 올해부터는 오베이 앱 PM으로 역할이 확대됐어요. 오베이는 오픈서베이 패널로 활동할 수 있는 설문조사 앱입니다.   세부적으로는 안드로이드 오베이 앱 개발, 오베이 회원계 시스템, 타겟팅 설문을 위한 유저 세그멘테이션 시스템을 개발·운영하고 있어요. 5년 차 개발자로 오픈서베이에는 17년 12월에 입사해서 벌써 1년 반 정도 일하고 있네요.    입사 계기가 독특하더라고요. 고백하자면 그렇죠. 전 직장에서 병특 복무 중에 이직을 결심하고 원티드에서 오픈서베이를 처음 알게 됐어요. 사실 뭐하는 회사인지도 잘 몰랐고 병특 TO가 있으니까 그때부터 찾아본 거예요.  잡플래닛을 검색해보니 ‘리서치 업계의 게임 체인저’라는 리뷰가 뜨더라고요. 실은 그 말이 정확히 무슨 의미인지도 잘 몰랐어요. 그냥 리서치란 단어가 주는 스마트하고 긍정적인 느낌이 있었는데 “그런 리서치 시장의 게임 체인저라니!”라며 면접을 본 거에요.   그럼 오픈서베이를 다니면서 긍정적인 면을 발견하신 거군요. 일단, 개발 업무 환경이 수준급이라 놀랐어요. 규모가 좀 있는 기업에서나 볼 수 있는 인텔리제이(intellij)도 너무 당연하게 구비돼 있더라고요. 이게 꽤 비싼 툴이거든요. 그래서 스타트업은 개발자 채용 공고에 인텔리제이 구매해서 사용한다고 일부러 적어놓기도 할 정도예요.  그런데 오픈서베이는 입사 때 따로 이야기해 주지 않아서 몰랐는데 떡하니 있길래 놀랐죠. whatap, jenkins, graylog 등을 이용한 배포·운영·모니터링 환경도 체계적으로 갖춰져 있었고요.  사실 이런 개발 환경을 갖춘 스타트업은 정말 흔치 않아요. 그래서 많은 개발자 꿈나무들이 큰 기대를 갖고 스타트업에 입사했다가 좌절해요. 앞에선 기술 중심의 혁신을 외치는데 그만큼의 투자가 없거나 여건이 마련돼 있지 않아서요. 여전히 많은 스타트업 개발자가 수작업으로 일일이 버그 모니터링을 하거나 업데이트 배포를 하는 경우도 많아요.  그런데 구비된 툴을 보면서 오픈서베이 개발팀은 생산성을 위한 비용 투자를 아끼지 않고 구조적인 개발 시스템에 노력하는 회사라는 인상을 받았어요. 개발 입문서 같은 데서 정석이라는 시스템을 그대로 갖추고 있으니까 제가 배운 이론을 현장에 바로 적용할 수도 있는 것도 좋았고요.   무엇보다 일에 집중할 수 있는 환경이군요.  이건 좀 개인적이긴 한데, 입사 전에 업무용 랩탑 선택권을 주는 것도 좋았어요. 사실 랩탑은 일할 때 제일 자주 많이 쓰는 도구잖아요. 업무에 가장 중요한 요소라고도 말 할 수도 있는데, 각 랩탑 사양을 정말 세부적으로 알려주고 원하는 걸 직접 선택할 수 있게 해주는 부분도 인상적이었어요.   그런데 후보 중에 제가 꼭 사고 말겠다고 생각했던 꿈의 랩탑 ‘델 XPS 15’이 있더라고요. 벌써 1년 반이나 지났는데 아직도 이 랩탑으로 일할 때는 괜히 기분이 좋아요.    “업무용 랩탑 선택권을 주는 것도 좋았어요. 사실 랩탑은 일할 때 제일 자주 많이 쓰는 도구잖아요.”   세세한 부분에서도 감동을 받으셨군요(웃음). 이렇게 디테일한 요소까지 챙기는 회사의 모습에 감동하는 거죠. 저는 오픈서베이가 3번째 직장이라서, 회사가 업무 환경에 디테일하게 신경 쓰는 게 얼마나 힘든지를 몸소 경험해서 알고 있거든요. 그런 면에서 오픈서베이는 개발 환경도 잘 갖춰져 있고, 업무를 위한 투자도 많고, 배울 사람도 많아요.   원티드에는 오픈서베이가 어떻게 소개되고 있을까요?   여건만 좋다고 다 좋은 회사는 아닐 수 있잖아요. 물론이죠. 근데 오픈서베이는 여건뿐만 아니라 성장 기회가 많아요. 의욕만 있다면 아직 주인을 찾지 못한 일들을 자신의 것으로 만들 수 있죠. 저는 주도적으로 일할 의지가 있는 구성원이 마음껏 역할을 늘려 갈 수 있는 조직이 긍정적인 면이 많다고 생각해요. 하고 싶은 사람이 그 일을 맡는 거니까요.   이런 면은 주니어나 미들레벨 개발자에게는 좋은 성장 기회가 되는 것 같아요. 제가 오베이 안드로이드 개발자에서 PM으로 역할이 확대되는 과정도 그랬어요. 처음에는 진짜 딱 개발만 했거든요. 운영 장애가 생겨도 저는 제가 개발한 요소의 코드만 아니까 다른 분야는 해결법도 모르고 제 역할도 아니니까 어쩔 줄 몰라 하며 지켜만 봤어요.  그런데 매번 아무것도 할 수 없는 상황에 놓이니까 제가 직접 문제를 해결할 수 있는 사람이 되고 싶어졌어요. 그때부터 오베이 앱 관련 코드를 다 까보면서 시스템 흐름을 파악했고, 장애가 발생했을 때 제가 해결할 수 있는 범위를 차근차근 늘려갔어요. 나중에는 노후한 시스템을 제가 만든 시스템으로 교체까지 했고요. 그러다 오픈서베이 CTO인 폴의 제안으로 올해부터 PM을 맡게 됐습니다.    조셉이 오베이 PM이 된 배경에는 그런 성장 스토리가 있었군요! 주도적으로 일하는 경험은 다른 회사에선 쉽게 얻기 힘든 기회라는 점은 정말 동의해요. 맞아요. 빠른 성장을 원하는 분에게 지금 오픈서베이는 딱 좋은 규모의 회사인 것 같아요.  정말 개발 인력이 적고 여건이 좋지 않아서 어쩔 수 없이 역할을 확대한 게 아니라, 좋은 여건과 환경에서도 빠르게 역할을 확대할 수 있는 단계에 이른 것 같아서요. 더 규모가 크고 탄탄한 회사에서는 사실 주도적으로 일하고 싶어도 환경이 따라주지 않는 경우도 많으니까요.  물론, 역량과 성취에 따라 합당한 보상을 해줘야 구성원들이 적극적이고 주도적으로 일하고 싶은 의욕이 생긴다는 생각도 하는데요. 제 경험에 비춰보면 오픈서베이는 일이 늘어나는 만큼 보상도 확실한 것 같아요(웃음).    “주도적으로 일할 의지가 있는 구성원이 마음껏 역할을 늘려 갈 수 있는 조직이 좋아요. 하고 싶은 사람이 그 일을 맡는 거니까요”     그런 좋은 경험 덕에 병특 이후에도 오픈서베이를 지켜주시는 거군요. 잘 몰랐는데 병특 복무가 끝나면 곧장 이직하는 게 훨씬 흔하다면서요?  맞아요. 더이상 그 회사에 묶여 있을 필요가 없으니 더 처우 좋은 회사를 찾아 떠나는 거죠. 저는 일부러 남았다기보다는 딱히 이직할 이유가 없어서 이직을 고려하지 않았다는 게 맞는 말인 것 같아요. 개발 업무 환경도 잘 갖춰져 있고 회사도 성장하고 있고, 무엇보다 보상 기준도 체계적이라고 생각하니까요.   보상 기준이 체계적이라고 생각하는 이유가 있나요? 개발팀에서 상하반기를 나눠서 1년에 2번씩 이뤄지는 성장진단을 해요. 단순한 연봉 협상이 아니라 정말로 제가 한 일을 돌아보면서 얼마나 성장했고 성취를 이뤘는지 상급자와 점검해보는 시간이에요. 사실 전 제 개인 블로그에 매달 1번씩 업무 성과 회고를 하거든요. 아무래도 명확한 독자가 없으니까 좀 캐주얼하게 쓰는 편이에요. 근데 회사 성장진단 문서는 내용은 같아도 독자가 다르니까 자연스럽게 자기객관화를 하면서 성과와 시행착오를 정리할 수 있는 시간이라 좋더라고요. 특히, 폴(이건노 CTO)은 이스트소프트에서 개발 조직을 오래 리딩하셔서 확실히 조언의 깊이가 달라요. 저는 아무래도 시야가 아직 넓지 않아서 개발 업무를 성능과 기술 중심으로만 대해요. 그런데 폴은 방대한 시각으로 비즈니스나 운영 관점에서 서비스가 확장될 때를 미리 계산해서 조언을 해주셔서 좋았습니다.   오픈서베이와 스타트업 얼라이언스가 함께한 ‘2018 스타트업 트렌드 리포트’를 보면, 재직자들이 스타트업에 가장 만족하는 요인은 ‘빠르고 유연한 의사결정 구조’였어요. 조셉 생각에 오픈서베이는 어떤가요? 자의적으로 해석할 여지가 많은 요소네요. 빠르고 유연한 의사결정 구조를 개발자 맘대로 하는 거라고 생각할 수 있으니까요. 그렇게 생각한다면 오픈서베이는 전혀 그런 회사는 아닌 것 같아요. 모든 의사결정은 전후 사정이나 논리적인 타당성을 따져보고 함께 결정하니까요.  대신 결정할 사안에 대한 논의는 정말 빠르고 유연하게 이뤄져요. 최고 결정권자인 하이(황희영 대표이사)와 논의가 필요하다고 생각되면 물어봐서 일정만 잡으면 얼마든지 1:1 미팅을 할 수 있어요. 대표실이 따로 있는 게 아니라 한 공간에서 같이 일하니까 몇초 걸어가서 바로 물을 수도 있고요. 대표이사와 이렇게 쉽게 이야기 나눌 수 있다는 점도 오픈서베이의 장점이죠.    “빠르고 유연한 의사결정 구조를 개발자 맘대로 하는 거라고 생각한다면, 오픈서베이는 그런 회사는 아니예요. 모든 의사결정은 전후 사정이나 논리적인 타당성을 따져보고 함께 결정하니까요.”   업무 영역을 넓힐 기회뿐만 아니라 발언 기회도 열려있다는 의미일까요? 정확해요. 개발팀에 ‘세미나’라는 제도가 있어요. 주간 회의와 별도로 팀에 공유하고 싶은 내용이 있는 구성원이 자발적으로 발표를 하는 시간이에요. 특정 프로젝트를 하면서 깨달은 점이나 노하우를 공유하는 식이죠. 저는 이런 세미나가 특히 주니어에게는 아주 좋은 발언 기회라고 생각해요.  사실 작년에 제가 ReactiveX와 Reactive System을 좋아해서 공부하고 있었어요. 당연히 오픈서베이 개발팀에도 도입하고 싶었죠. 근데 팀에 리액티브X를 다루던 분이 없어서 도입 시 이득에 대한 공감대가 없었어요. 그래서 세미나를 활용해서 , <리액티브 시스템으로 설문 서비스 구축하기>라는 주제로 두 차례 발표했어요.  당시에는 발표한다고 진짜 리액티브 시스템을 도입할 수 있을까 생각했어요. ‘필요하니 돈 내고 사자!’라며 간단히 설득할 수 있는 사안이 아니었거든요. 리액티브 시스템은 말하자면 개발 패러다임, 업무 방법론이에요. 개발 업무를 아무도 하지 않았던 새로운 방법으로 바꾸자는 얘기니까 팀 차원에서는 훨씬 복잡하고 신중한 의사결정이 필요한 사안이었죠.    조셉에게 세미나는 그런 중요한 사안을 건의할 기회의 장이었군요. 결국 도입은 성공했나요? 네(웃음). 덕분에 오베이 앱은 RxJava를 활용해 개발했어요. 이후 설문 서비스 개발을 담당하는 테리(이한별 개발자)는 리액티브한 방식으로 내부 파일 관리 시스템을 만들었어요. 정말로 저 혼자만 아니라 팀에서도 활용 가능한 개발 방법론이 된 거죠. 생각해보면 입사한 지 1년도 안 된 개발자가 팀에 새로운 업무 방법론을 도입하자는 발언권을 가질 수 있다는 점 자체가 오픈서베이 개발팀의 업무 문화와 일하는 방법을 단적으로 보여주는 예시 아닐까 싶어요.    마지막으로 오픈서베이의 예비 구성원분들께 한마디 부탁드립니다.  저는 오픈서베이를 다니면서 좋은 구성원들에게 자극을 받고 더 성장하기 위해 노력하게 된 것 같아요. 사실 제가 학창시절 때 꿈이 프로게이머였을 정도로 게임을 좋아해요. 회사 다니면서도 다른 시간 다 줄여도 게임하는 시간은 못 줄였을 정도로요.  그런데 좋은 업무 환경과 동료들, 성장 기회, 그리고 확실한 보상까지 고루 갖춘 회사에 다녀보니 더 좋은 사람이 되고 싶다는 생각이 들더라고요. 다른 동료들처럼 훌륭한 사람이 되고 싶어서 말이죠. 그래서 요즘은 그 좋아하던 게임도 접어두고 자기 계발에 몰두하고 있어요.  단순히 높은 연봉이나 좋은 복지가 아니라 함께 성장하고 싶은 예비 구성원분들의 많은 지원을 기대합니다!      “조셉과 함께 일하고 싶으시다면 지금 바로 오픈서베이 입사 지원을 해보세요”