‘이직’이라는 화두는 샐러리맨에게는 매우 무섭게 다가온다. 평생직장이라는 의미가 사라진 현대 시대에 있어서 직장생활 중에 많이 만나게 되는 단어이다. 더군다나, 소프트웨어 개발자들에게는 매우 일상적으로 발생한다. 그러니, 이직을 너무  두려워하지 말자. 오히려 평소에 이직에 필요한 스킬과 준비를 매우 당연하게 해야 한다.개인적으로 소프트웨어 관련 학과에서는 '이직'과 관련된 커리큘럼을 하나 만들어 두거나. 아니면, 교양과목이라도 있어야 하나 가르쳐야 한다고 생각한다.필자도 여러 기업에 입사하고 이직을 고민하는 과정을 똑같이 경험했다. 더 큰 경험으로는 기업을 창업하고 직원을 채용하고, 퇴사하는 과정도 같이 경험했다. 돌이켜 생각해 보면 직원의 입장과 중간관리자의 입장, 경영진과 최고 경영진의 입장에서의 ‘이직’을 바라보는 관점이 정말 매우 다르다.이번 이야기에서는 이런 ‘이직’의 관점을 ‘소프트웨어 개발자’의 입장에서  이야기해보자.이직이란 단어는 언제 만나게 될까? 이직이라는 단어를 머릿속에 떠올리게 되면서 당연하게 고민할 것이다. 더 좋은 조건을 제시하는 회사로 자리를 옮기거나, 또는. 현재 있는 직장에서 하는 일이 마음에 들지 않거나, 특정한 사람이나 환경 때문에도 이직이라는 단어는 언제나 떠올릴 수 있다.소프트웨어 개발자들이 이직을 고민하고  생각할 때에 어떤 부분들을 고민하고 생각해야 하는지 알아보자. 물론, 이번 이야가의 내용은 전적으로 필자의 주관적인 경험을 바탕으로 만들어진 내용들이기 때문에 매우 주관적이라는 것을 먼저 이야기해야겠다.다만, 작지 않은 경험을 적은 기업의 신입직원이었을 때부터, 벤처기업의 CEO, 중견기업의 CIO의 역할을 해보고 느낀 점 들을 몇 가지 정리하여 본 것이다.자, 이 글을 읽는 독자들은 ‘이직’을 고민하는가?혹은 이직이라는 단어에 대해서 어떻게 생각하는가?일단, 직장은 너무 쉽게 바꾸거나, 특정한 이유에 너무 집착하여, 너무 쉽게 결정하지 않기를 바란다. 일반적으로 한 회사에서 정년퇴직한다는 전설을 만난다는 것은 이제 거의 불가능에 가깝다. ( 필자역시, 딱 한사람 만났다. )소프트웨어 개발자들은 한 회사에 오래 근무할 수 있는 여건이 되는 사람들은 매우 극소수에 해당된다고 생각해야 한다. 대부분은 프로젝트가 종료되거나 의미가 없어지면서 이직에 대해서 고민을 시작 하게 된다.너무도 자주 만나게 되는 이 단어에 대해서 사람들마다 각자의 의미와 나름대로의 기준점을 잡아두는 것이 매우 좋다고 설명하겠다. 각자 자신이 걸어가야 할 로드맵이나 기본적인 원칙을 한, 두 가지쯤은 정해 두는 것이 좋다. 이 기준은 정말, 개인적인 기준들이다. 이 기준을 각자 가져야 한다.필자의 경우에는 초보때에 세웠던 원칙이 몇 가지 있었고, 나름 경험이 많아지면서  이러한 원칙들은 조금씩 그 기준을  추가하게 된다. 필자의 사례를 들어보자필자는 가장 먼저 사회생활 초년병의 시작을 병역특례로 시작하였다. 그래도. 나름 기준은 있었다. 그것은 앞으로 소프트웨어 개발일을 계속하기 위해서 내가 어떤 기준으로 회사를 찾아야 하는가에 대한 것이었다. 내가 세운 대원칙은 딱 하나였다. 하드웨어 작업을 병행하는 일을 한다는 것을 원칙으로 했다.그래서, 선택한 기업에서 처음 내게 할당된 일은 Z80으로 음성보드를 만들고, 적외선 센서로 터치스크린을 만드는 파트에서 Z80과 i8051의 크로스 어셈블리로 프로그래밍하는 일이었다. 내가 세운 큰 대원칙에는 맞는 일이었고, 일 자체에 대해서도 매우 큰 매력을 가졌다.하지만, 그 업체에서 병역특례 일을 하다가 부당한 노동현장(?)의 부조리를 맞이 하게 되면서 회사를 그만두게 됐다. 그 당시 얻은 경험 중의 하나는 ‘부조리한 노동현장’은 빨리 떠나라는 개인적인 원칙도 세웠다. 그 기준은 나중에 기업을 운영하면서도 가장 부끄러워할 경영진의 몫이라는 것을 인지하게 된 것도 가장 큰 경험이었다고 하겠다. ( 이런 경험은 차라리 초보나 신입 때에 경험하는 것이 그나마 불행 중 다행이며, 사회의 쓴맛을 제대로 보았다고 하겠다. 무료 법률상 담도 해보았고, 노무담당 문의도 해봤다. )그 후에 경력직 프로그래머로써 제대로 된 취업을 할 때에도 나름대로 원칙을 세웠다.병역특례 일을 하다가 그만두고 군대를 다녀왔을 당시에는 윈도우즈 애플리케이션의 개발이 매우 어렵던 시절이었기 때문에 나름 몸값을 요구할 수 있었다. 그래서, 프로그래밍을 하는 데 있어서 조금은 특이한 솔루션을 활용하는 경험을 하고 싶었고 그것을 중요한 원칙으로 삼았다.당시에 선택할 수 있는 기업은 3곳이었다. 하나는 용산 근처의 게임 개발사. 건대 부근의 한국전력에 소프트웨어를 개발해서 판매하던 회사, 그리고. 하나는 건축 소프트웨어 개발을 하는데 Auto-Cad의 ARX아키텍처 기반의 프로그래밍과 윈도즈 개발을 하는 일이었다.3군데의 회사에 면접이 다 통과된 이후에 고민하였다. 가장 적극적이었던 회사는 게임회사였다. 지금 기억으로도 90년대 중반에 팔레트 애니메이션을 능숙하게 조작하는 내 스킬을 보고 매우 탐을 내었던 게임업체의 사장이 기억난다. 그 먼 거리에서 인천의 집까지 나를 태워다 주면서, 같이 일하자고 차를 타고 오는 도중에 많은 이야기를 나누면서, 같이 일하자고 설득했다.하지만, 결정적으로 그 당시에 결혼을 한 필자의 입장에서는 ‘급여’가 가장 큰 걸림돌이었다. 전혀 엉뚱하게도 ‘급여’를 가장 많이 준다는 ‘회사’를 선택했다. 바로, 건축 소프트웨어 개발회사였다. ( 당연하지만, ‘급여’는 언제나 샐러리맨에게는 최고의 선택 기준이 될 것이다. )아마도, 필자가 그 당시에 급여는 매우 적지만, 그 게임업체에 들어갔다면 운명이 매우 많이 바뀌었을 것으로 생각한다. 당시, 병역특례를 하다가 군대를 다녀오면서 네트워크 프로그래밍에 대한 스킬까지 겸비한 필자가 게임업계로 들어갔으면 나름 재미있는 미래가  진행되지 않았을까 한다.하지만, 그래도 그 당시에 급여도 나름 가장 많았지만. 최고의 선택 기준은 ‘독특한 기술’에 대한 호기심이었다. 더군다나, 윈도즈 개발자로서 나름 이름을 알리기 시작하던 시기였기 때문에 필자의 선택은 옳았다고 생각한다.이때 중요한 화두는 ‘급여’와 ‘윈도즈 개발환경’, ‘독특한 콘셉트’이었다. 당시, 그 회사는 AutoCad에서 동작되는 한글 소프트웨어와 설계용 지원 유틸리티를 개발하는 업체였기 때문에, 선배 개발자들과의 경험이 매우 좋았다. 선배 개발자와 개발실장으로 계시는 분들이 20대 중반이었던 필자를 매우 아껴주었던 기억이 난다.최소한 그 계통에서 5년 이상 일을 했던 선배들이 몇 분 계셨고,  그분들에게 생각보다 많은 것을 얻을 수 있었다. 정말, 훌륭한 선배들은 언제나 초보와 신입들에게는 큰 도움이 된다.필자가 신입시절에 크게 결정한 것은 ‘장래성’도 아니고, 오히려 찾은 것은 ‘독특한 개발’을 경험할 수 있는 환경을 찾았고. 그것은 또 하나, 새로운 개발환경을 초기서부터 세팅하는 것도 포함되어 있었다.‘개발자가 이직을 결정해야 할 때’는 언제 인가하고 후배들이 가끔 질문을 해오거나 자문을 구해올 때가 있다. 그렇다면, 소프트웨어 개발자가 이직을 생각하는 때에 대해서 어떤 것을 고민해야 하고, 이직을 결정하기 위하여 중요한 사항은 어떤 것이 있을까?물론, 이직은 모든 분야에서 공통적으로 발생하는 요소이기 때문에 전부를 이야기할 수 없겠지만, 가장 좋은 이직이란 무엇인지 필자의 경험을 중심으로 이야기해보자. 다음에 나열하는 요소들은 ‘이직’을 고민하게 될 가장 큰 가능성을 가지고 있다.첫째. 자신의 전문성에 대해서 고민하기 시작할 때...보통은 자기계발에 충실한 사람의 경우에 자신이 제대로 된 전문성을 확보하고 있는지에 대해서 의문점이 생기는 시점에 '이직'을 고민하게 된다. 이 일을  계속하는 것이 미래에 ‘전문성’을 가질 수 있느냐에 대해서 의문을 가지기 시작할  때부터이다.둘째. 조직원들 간에 트러블이 발생하거나, 말도 안 되는 상사의 권위에 질렸을 때이 부분은 일반 직장과 동일하다. 아무리 전문성이 보장되고, 일이 괜찮다고 하더라도. 동료들과의 문제가 발생되는 부분은 어느 직종이나 동일하다.필자는 소프트웨어 개발일을 하면서도 벤처기업의 경영진 역할과, 중견병원그룹의 CIO생활을 하면서 다양한 직종의 사람들과 일을 해보고 인사권을 가지고 있었지만. 모두 동일하게 문제가 발생하는 것은 ‘직원들’ 간의 문제나, 중간 관리자의 전횡 등이 가장 큰 이유가 되었다.셋째. 프로젝트가 종료되었을 때에생각보다 하나의 프로젝트가 종료되면서, 소프트웨어 품질이나 개발에 대한 연속성이 제대로 이어지지 않는 경우에는 이직을 생각하게 된다.재미있고 즐거운 개발을 필자가 주창하는 이유 중의 하나가 이러한 ‘프로젝트 종료’ 시의 이직에 대한 고민을 하지 않기 위해서이다. 하지만, 대부분의 프로젝트들은 실패하거나 어려움을 겪는 경우가 다반사이기 때문에, 프로젝트가 종료될 때에 이런 충동을 느끼게 된다.이상 3가지의 기본적인 이슈들은 직장생활을 하면서 매번 만나게 되는 고민이고. 3가지의 고민이 모두 발생한다면, 당연하게 ‘이직’을 오히려 권해야 할 사항이 될 것이다.자, 이직에 대해서 고민하고, ‘이직’을 결정하였다면, ‘미련’없이 ‘이직’을 준비하자.‘이직’을 준비하는 것에 있어서 가장 중요한 것은 옮겨갈 회사를 잘 고르는 것이 가장 큰 것이다. 그리고. 퇴사를 하는 회사의 경우에는 최소한 1개월 정도의 업무 인수인계 작업은 당연하게 고려하자. 물론, 제대로 된 체계가 있는 회사는 당연하지만, 직원들의 이직 프로세스가 잘 잡혀있기 때문에 너무 걱정할 필요 없다.대부분의 조직은 누구 한 사람이 나간다고 하더라도, 그 프로젝트가 잘못되는 경우는 거의 없다. 그냥, 본인의 마음이 떠난다면 ‘이직’을 진행하는 것이 맞을 것이다.너무 걱정하지 말고 이직을 결심하고 진행하라고 조언하고 싶다.다만, 필자는 ‘이직 시에 적합한 회사’를 찾기보다는, ‘이직 시에 안 좋은 회사’를 피하는 방법을 먼저 터득하라고 조언하고 싶다.이직 시에 안 좋은 회사를 피하는 방법개발자들이 이직을 고려하고, 이직을 결심하게 되었을 때에는 신입의 입장과는 매우 다르다. 어느 정도 경력도 생겼고, 일에 대한 경험도 풍부해지고, 나이도 한두 살 더 먹었으며, 사람들과의 스킨십이나 커뮤니케이션 능력도 좋아지기 시작하는 시기가 된다.또한, 과거에는 ‘취업’과 ‘작은 목표’가 중요하였지만, 이제는 같이 일할 동료들에 대해서도 생각하게 되고, 일하는 회사의 비전이나 다른 부분들도 같이 고님할 것이다. 이런 어느 정도의 경험과 시야가 생겼을 때에 ‘이직 시에 좋지 않은 회사’를 골라내는 방법은 어떤 것들이 있을까?필자의 경험으로는  다음의 사항들을 고려하여 ‘이직’하려는 회사들을 평가했다.하나. 고급 개발자가 있는가?회사의 CTO나 개발실장이 고급 개발자이며, 그 분야의 '구루'급에 해당되는 사람인가? 존재한다면,  그분들이 회사 내부에서 '존경'받으며, '대우'를 받고 있는지 확인해보라. 그 회사에서 꾸준하게 엔지니어로 성장한다면..  그분들과 같은 대우를 받을 수 있는 인사 환경을 갖추고 있는지 확인하면 된다.대부분 허접한 회사이거나 일반 기업체에서 전산실의 역할이 부실한 경우라면 IT기술을 최고로 습득해도 계장 이상 올라갈 수 없는 곳이라면, IT기술을 중요시하는 기업이 아니라는 것이다. 이런 경우에는 '직장인'으로써의 비전만을 따지면 된다. ( 정치적인 것이 아니면, 급여, 복지일 것이다. )'개발자'로써의 삶이나 목표, 비전과는 전혀 상관없는 기업이기 때문에 일반적인 '직장생활'에 충실한 것이 좋을 것이다. 이와 관련된 처세술이나 비교자료는 인터넷에 많으니 검색해서 참조하자.둘. 개발자들이 오랫동안 근무한 사람들이 있는가?회사가 성장하고 발전하는 과정에서 사람들이 들어오고 나가는 것을 반복한다. 이런 경우에 회사에 오랫동안 근무한 개발자나 엔지니어가 존재하는지 확인해보는 것이 좋다. 대부분 경력이 올라가면 '급여'가 오르게 되고, 이렇게 경험이 풍부한 사람들이 많이 존재하는 개발 조직이나 회사가 발전 가능성이나 시장을 가지고 있는 경우가 많다.하지만, 회사는 충분하게 돈을 벌고 있지만, 회사 경력에 비해서 적은 경력의 개발자들이 2~3년 차들로 대부분 도배되어 있다면, 특정 시점에 직원들이 물갈이가 되거나, 개발자들이 죄다 못 버티고 나간 경우라는 뜻이다.'소프트웨어 개발자'들도 대부분 '직장인'에 가깝다. 이 회사가 정말 좋은 곳이고, 계속 다닐만한 가치가 있는 회사라면. 오래된 개발자들이 많이 있을 것이다. 이런 오래된 개발자가 없는 곳이라면 분명, 인사 문제나 처우에 문제가 있는 회사이다.셋. 사무실의 환경을 살펴라.큰 사무실이건 작은 사무실이건 '실제 일하는 사람들'이 사용하는 '책상'이라면 사용하는 흔적들이 있다. 공간은 있지만, 빈 책상에 사용되지 않는 물품들만 있다면. 인력파견업체가 대부분일 것이고, 처우나 사무실의 환경은 그다지 좋지 않을 것이다.대부분 팀장이고 이사이고 아웃소싱 일을 대부분 하고 있는 사람들일 것이고, 당연하지만, 근로환경도 최악이고, 월급이 때인다던 지, 프로젝트 진행이 개판이 되는 경우가 많다.넷. 신입직원 연수나 트레이닝 프로그램이 있는지 확인하라대부분, 이직 시에 이러한 것들을 고려하지 않는다. 하지만, 대부분의 중소기업이나 대기업들의 경우에 자체적인 솔루션이 있거나 나름 시장 지배력이 있는 회사의 경우에는 ‘사전에 교육’ 해야 할 내용들이 많아진다.당연하지만, 신입직원들에게 짧으면 2주, 길면 4주 이상의 트레이닝 코스가 존재하게 된다. 나름 시장 지배력이 있는 회사라면 이러한 코스가 당연하게 있다. 만일 이러한 코스가 없다면, 해당 기업은 의미 있는 솔루션을 만들거나, 의미 있는 서비스를 하고 있는 회사라고 보기 어렵다.그것은 중소기업들은 대부분 적당한 인력을 구인해서 적당하게 사용한다고 보면 된다.이처럼 소프트웨어 개발자가 이직을 생각할 때에 이러한 조건들도 있지만, 오히려 개발 경력이 3~4년 차를 넘기는 개발자에게 필자가 가장 중요하게 질문하는 것이 있다. ‘소프트웨어 개발이 적성에 맞는가?’라고 묻는다.굳이, 소프트웨어 개발이 아니더라도 자신의 자아실현이나 사회생활이 충분하게 실현되는 경우도 많다. 억지로, 소프트웨어 개발자의 길을  걸어가면서 주변을 괴롭히거나, 오히려. 안 좋은 중간 관리자가 되면서 IT업계의 원흉이 되는 것도 이 시기에 잘못 결정한 선배들이나 후배들도 많다.필자가 만난 여러 후배 개발자 중에는 소프트웨어를 설계하고 만드는 일이 그다지 적성에 맞지 않는 경우도 상당수 있었다. 또는, 저 사람은 아예 소프트웨어 개발을 하지 않았으며 좋겠다는 생각을 하게 된 사람도 있었다. 그래서, 오히려 조언을 하거나 유도를 해서 다른 일을 선택하고 그 길을 잘 걸어가는 후배들도 여럿 있다.하지만, 대한민국의 SI개발에만 있었다면 다른 직종도 가능할까?라는 질문에는 사실, 정답이 없다고  이야기한다. 갑을병정 이무기라고 불리는 먹이사슬의 과정 속에서 SI현장에서 다른 분야로 진출하는 것은 정말 어려운 일이다.대기업이나 중소기업의 SI에 입사해서, 프로젝트 관리자의 길을 걸어가는 사람이 아니라면, 매우 어려운 자리가 될 것이다. 하지만, SI나 SM의 이직 시에도 제대로 된 선택을 하면 매우 수월하고 편안한 자리로 이직을 할 수 있다.실제 후배들 중에는 많은 급여보다는 안정적인 자리를 원하는 도메인이 특화된 SM자리를 잘 차지하고 편안하게 일하는 개발자들도 간혹 발견할 수 있다. 하지만, 그런 환경이 아니라면 필사적으로 이직 시의 조건을 따져봐야 한다.최소한 ‘피해야 할 회사의 조건’을 따져봤다면, 이제는 가장 현실적인 ‘조건’을 나열하여 회사와 조직의 환경을 살펴보자. 다음의 조건들을 살펴봐라.야근수당을 받는가?2015년을 기준으로 나이 30세 초반에 연봉 3000~4000이라면 소프트웨어 개발자로서 만족하는 삶을 살 수 있을까? 하지만, 사회생활에 있어서 야근수당을 받거나 주말에 근무하면 추가 페이를 계산받는가? 냉정하게 계산하고 매일 야근과 주말근무를 하고 있다면, 실질적인 연봉은 무려 5~6000만 원을 받아야 정상이다.필자가 중견그룹의 CIO 역할을 하던 시절에 인사팀에서 가장 많은 경고와 안내를 받았던 것 중의 하나가 '야근'근무를 가능한 하지 않도록 유도하는 안내였다. 야근을 하게 되면 자연스럽게 지출되는 야근을 위한 식사와 연장근로수당, 그리고. 주말까지 일하게 되면 2배를 넘어가는 수당의 지급은 상당히 부담스러웠던 것이기 때문에, 인사팀에서는 이러한 근무를 하지 않도록 유도하는 것이 최선의 방법이었을 것이다.대부분 괜찮은 기업들은 '야근'근무를 유도하지 않는다.단지, 근무조건이 탐나는가?냉정하게 SI는 전문성이 매우 높은 분야인데, 대한민국에서는 그러하지 않고, 거의 막장에 가까운 환경을 가지고 있다. 매우 슬픈 일이다. 일본이나 미국과 같은 선진국에서 근무하는 SI 개발자들의 처우나 근무조건은 매우 좋은 조건들이고, 연봉 또한 매우 높다.제대로 된 SI분야의 경우에는 대체인원이 그렇게 많지 않고, 어느 정도 경력을 가진 개발자로 성장하기 매우 어려운 분야이기 때문에 경력자와 경험자를 매우 우대한다. 하지만, 대한민국의 SI현장은 정말 열악한 환경으로 변화하였고, 그 현장은 매우 절망스러운 곳들도 많다.대한민국의 SI가 이렇게 된 이유에 대해서는 여러 가지 이유와 근거와 설이 존재하는데, 필자가 생각하는 몇 가지 이유는 다음과 같다.하나. 대기업의 전산실에서 분리된 IT조직의 태생적 한계둘. 전산/IT를 제대로 전공으로 한 '선배'들이 실제 부재하다.셋. 대정부의 SI 관련 프로젝트가 갑을병정 프로세스만으로 진행되면서 만들어진 흑역사넷. 소프트웨어 품질을 모르는 PM/PL들이 아직 수두룩하다. ( 이론만 아는 방법론자들 투성이다. )다섯. 책임지는 소프트웨어 개발 조직과 개발인력이 그다지 SI현장에 없다.여섯. 소프트웨어 개발은 '자격증'과 아무 상관없고, 개발 경력과도 그다지 연관성이 없다.그래서, 대한민국의 SI현장은 주변에 잘 수소문하여 ‘괜찮은 곳’을 찾아가는 센스를 발휘하지 못하면, 암흙의 이직을 경험할 수 있다.물론, 이렇게 이야기하는 ‘이직’의 대부분은 ‘스타트업’이나 ‘도전적인’ 기업을 선택하는 것과는 다른 기준들이다. 대부분은 ‘조직’이라는 틀에서 움직이는 ‘작업자’들을 구인하고 그 공간이 나에게 맞는지에 대해서 잘 따져야 하는 것이다.결국, '조직'의 틀로 생각한다면, 일반 샐러리맨의 회사 선택의 기준과 그다지 차이가 없을 것이다.하지만, 소프트웨어 개발자의 세계에서 '이직'을 제대로 할 수 있는 방법은 말 그대로 '스카우트'을 받고 이동하는 것이다. 그런 대우를 받으려면, 제대로 평가된 ‘나의 인식’과 ‘나의 브랜드’가 있어야 가능하다는 것을 염두에 두자.결론적으로 '이직'을 제대로 하려면, 자신의 '브랜드'를 만들 수 있어야 한다. 그것이 핵심이다.그렇다면, 성공적인 이직을 하려면 무엇을 갖추어야 하는가? 그것은 다음의 6가지로 정리할 수 있다.하나. 자기만의 장점을 가져야 한다.둘. 자신만의 전문성을 가져야 한다.셋. 절대다수는 하지 못하는 희소성을 가져야 한다.넷. 내 경력과 전문성을 증명할 프로젝트를 가져야 한다.다섯. 포트폴리오를 구성하라여섯. 외부활동과 내 브랜드를 만들어라이 6가지 중에 2~3가지만 충족한다고 하여도, 소프트웨어 개발자는 제대로 된 대우나 평가를 받으면서 즐거운 이직을 경험할 것이다. 말 그대로 헤드헌팅이나 개발자 커뮤니티에서 당신에 대한 평가가 좋을 것이다.매우 당연한 것이지만, 준비된 사람에게는 언제나 기회가 만들어진다. 기회가 만들어지지  않는다는 것은 ‘준비가 부족하기 때문이다’라고 이야기할 수 있다.직업 이직을 권유받았는가? 아니면. 이직을 꿈꾸는가?그렇지만, 그렇게 브랜드나 명성을 얻기 전에 권유를 받았건, 상사가 괴롭혀서 떠나건, 이직에 대해서 고민하고 결심했다면 다음의 몇 가지를 고민하자.후배들에게 이야기하는 몇 가지 충고의 이야기가 있다. 이것은 정말 최소한의 기준이다.최소, 이 기준에 대해서는 고민하고 '이직'을 결심했으면 좋겠다.하나. 소프트웨어 개발자들이거나 SI현장에 있는 개발자라면 최소한 하나의 도메인이나 전문분야를 택했다면 최소 5년은 버텨야 한다.둘. 프로젝트나 포트폴리오는 5년 이하 경력은 세상이 제대로 인지하거나 인식하지 않는다.셋. 직장이 중요한 것이 아니라, 직업과 도메인이 중요하다.넷. 경력과 브랜드는 ㅇㅇ회사의 누구가 아니라. 누가 다니는 ㅇㅇ회사가 더 좋다는 평가를 받아야 한다.SI현장에 있건, SM현장에 있건, 대기업이나 중견기업은 파견 나온 개발자를 좋아한다. 어떤 분야이건 어떤 특수하거나 일반적인 분야이건 대부분은 교육이 필요하고, 경험이 필요하다. 그리고, 그 조직과 회사에 적응하는 기간이 필수적이다. 대부분 이러한 '비용'은 기업을 운영하는 입장에서는 어떻게든 최소화하기를 원한다.대부분 이런 신입 비용을 어떻게 줄이느냐가 관건이기 때문에, 대부분의 회사들은 가능한 '경험'자와 '경력자'를 선호하는 것이 매우 당연하다. 특히나, 관련된 일과 조직에 익숙한 사람이라면 회사 입장에서는 신입의 교육비용이 들어가지 않는 파견된 개발자들을 선호하게 된다.바로 업무에 투입하고 결과물을 얻을 수 있기 때문에, 이러한 파견된 개발자들을 선호할  수밖에 없다. 그래서, 보통 갑, 을의 조직들은 자신의 일을 위해서 파견 나온 SI, SM개발자들을 참 매력적으로 인식한다.특히나, 이렇게 일하는 SI, SM 개발자들은 함께 일하고, 같은 조직에서 일하는 사람들이기 때문에 눈으로 확인한 이러한 사람들을 좋아할  수밖에 없다. 당연한 것이지만, '면접'을 통해서 사람을 뽑는 것보다 직접 함께 일한 사람을 뽑는 것이기 때문에 해당 기회비용과 교육을 위한 시간 비용들이 모두 절약된다.그래서, 대부분은 고객 회사에서 이런 개발자들에게 먼저 이직을 권유하게 된다. 고객의 입장에서는 바로 실전에 투입할 수 있는 개발자를 얻을 수 있고, 권유를 받은 개발자 역시 중소기업이나 파견직에서 일하다가 더 높은 연봉과 복지제도를 제공하는 기업으로 옮겨갈 수 있는 기회를 얻는다.다만, 이러한 권유를 받는 것은 '인력파견'업체를 통해서 SI현장에 나가서 일하는 경우에는 이러한 '기회'를 얻기 어렵다. 실제, 이러한 '제의'를 받는 경우는 '고객'의 기업에 직접 나가서 일하는 경우를 의미한다고 봐야 한다.물론, 이러한 것을 중소기업 입장에서는 인력 빼가기?라고 볼 수 있다. 필자도 중소기업을 운영해봤지만, 중소기업에서 4~5년 이상 일을 하고 있는 직원이 아니라면, 이러한 이야기도 하기 힘들것이고, 실제, 중소기업의 일이라는 것이 '일을 배우고 가르치는 이유가 어느 정도 업무에 필요한 수준'까지만 가르치기 때문에, 이를 중소기업의 인력 빼가기라고 이야기하기 어렵다. 가르친 것도 없이 일만 시켰는데 무슨 ‘인력 빼가기’인가?다만, 가장 최악의 이직 회사를 피하는 방법은 정말 고려하다. 하지만, 이직을 할 때에 순간적인 선택에 의해서 정말 좋지 않은 선택을 하는 경우가 종종 있다. 하지만, 아래와 같은 회사로 이직을 하였다면, 재빠르게 '사표'를 내는 것이 가장 현명하다. 필자의 경험을 기반으로 이런 회사는 빨리 떠나야 한다고 생각한다.하나. 회사의 사무실의 인테리어가 영 허접하다현재의 소프트웨어 개발자들의 인테리어는 대부분 훌륭하다. 특히, 이제 막 시작한 스타트업의 경우라면 직원이 아니라, '동료'의 입장으로 참여하는 것이기 때문에 이 조건은 해당이 안될 것이다. 하지만, '직원'의 입장에서 그 회사에서 일을 하는 경우라면 '회사 인테리어'는 매우 중요하다.그것은 초라한 사무실에 초라한 책상에 기본적으로 제공되는 도구도 깔끔하지 않다면, 정말 간단하다. 그 회사에서 직원들에 대한 처우나 근로환경은 최악이라고 보면 된다. 아마도, 입사를 한지 한 달 후에 바로 급여나 근로형태에 대해서 불만이 생길 것이다.대부분 이런 회사의 특징은 인력파견 회사일 확률이 높다. 당연한 것이지만, 내부에 축적된 지식도, 솔루션도 없는 조직이다. 그냥, 싼 개발자를 구하고, 파견을 보낼 개발자를 구했을 것이고, 그것에 당신이 걸려들은  것뿐이다. 빨리 탈출하는 것이 현명하다.둘. 직원들의 얼굴 표정이 매일 야근한 것 같다.근무조건과 처우에 대해서는 그 회사에서 근무하는 직원들의 모습을 보면 된다, 깔끔한 복장에 자유롭고, 자신에 찬 얼굴을 하고 있는 경우라면 상관없다. 하지만, 세탁한지 며칠 된 복장에 연일 야근에 찌든 듯한 얼굴, 사무실에 난로도 제대로 안 때워서 매번 감기에 걸려있는 상태인듯한 모습이라면, 그 회사도 빨리 탈출하는 것이 현명하다.필자는 개인적으로 소프트웨어 개발자들을 제대로 처우하는 곳이라면 키보드와 마우스, 그리고. 의자는 최대한 자신이 원하는 도구를 구해주는 곳이라고 생각한다. 그리고, 최소한의 근무환경을 구성해줄 수 있어야 한다. 다만, 같이 고생하고 같이 나눌 동료가 아니라면 이런 회사는 빨리 탈출하다.셋. 오래된 선배 개발자의 경력이 얼마나 되는가?좋은 조직과 좋은 회사. 그런 곳은 좋은 회사다. 고로, 당연하게 좋은 회사는 계속 다닐만한 가치가 있기 때문에 오래된 개발자들이 존재한다. 회사 업력이 10년이 넘었다면, 10년을 다닌 개발자가 있을 것이고, 5~6년 차 개발자들이 여러 명 존재해야 한다.하지만, 회사 경력이 10년을 넘었는데도 그 회사 경력 2년 차가 팀장이고, 병특들로 모두 구성되어 있는 회사라면, '결코 좋은 회사는 아니다'.분명하게 회사의 사장에게 문제가 있거나, 똘아이 같은 개발이사가 있거나, 막 나가는 팀장이 있을 수 있다. 또는, 처우나 급여문제 등등 문제가 분명 존재할 것이다.넷. 가족과 같다는 이야기를 반복하는 사장의 이야기회사는 '이익'을 위하여 존재하는 곳이고, '돈'을 벌어야 급여가 나오는 회사이다. 회사는 '가족'이 아니다. 그리고, '사장'처럼 일하라고 반복하는 '사장'들이 가끔 있다. 그럼, 이렇게 반문해보자, '사장'같이 일하면, '그 회사'를 물려줄 것인가?아니다. 처우는 '노예'처럼 하면서 일은 '사장'처럼 하기를 원하는 것이다. 이런 회사도 떠나라. 또 이런 회사의 특징은 이렇다.'회사 사정이 어려워서...', '요즘 경기가 안 좋아서...', '다음에...', '이거 끝나면 뭔가 있을 거야...'부끄럽지만 필자도 이런 이야기들을 20대 후반 사장 시절에 반복했었다. 결론적으로 '지키지 못할 약속'을 그냥 반복할 뿐이다. 이런 이야기의 99%는 뻥이고, 그냥.  '립서비스'일뿐이다. 포상은 합리적이어야 하는 것이다. 또한, 엄청난 투자를 받는다고 해서  밀어붙인 일일 경우도 많다. 하지만, 언제나 '과실'중에 '이익'은 경영진만이 가지고 간다는 것을 잊지 말자.다섯. 인건비는 무조건 싼 개발자만 찾는 회사.간단하다. 경력 10년 차 개발, 고급 개발자가 할 수 있는 일을 하거나, 품질이 높은 일이 필요 없는 일이 대부분이다. 임금이 비싸고 경력이 풍부한 사람이 비싼 이유는 당연하게 있다. 하지만, 단지 급여가 싼 사람을 찾는 이유는 간단하다.'일'에 대한 가치를 알지도 못하고, '개발자'에게만 탓을 돌리는 사장이나 경영진일 경우에 대부분 이렇다. 경력 1년 차가 할 수 있는 일이라고만 생각하기 때문에, 경력 4~5년 차도 그에 합당한 급여를 줄 수 없는 것이다.당연한 것이지만, 실제 일은 단순 SM이기 때문에 그런 경력을 가진 개발자가 필요 없다고 인지하기 때문이다. 이런 회사들이야말로 정말 비전이 없다.여섯. 급하게 뽑는데 면접도 제대로 안보는 회사정말 엉터리 같은 인력파견업체의 경우가 이렇다. 자신들이 면접을 보는 것이 아니라, 고객사로 보내서 면접을 본다.만일 위에 언급한 6가지 내용 중에 한 개 이상으로 해당되는 회사나 조직에 있다면, ‘이직’을 고려하는 것이 정말 당연하다 하겠다. 하지만, 자신의 능력과 이직에 대한 준비가 되어 있지 않다면, 어쩔 수 없다. ‘샐러리맨’의 기본자세로 돌아가서, 내 능력에 합당한 현재의 자리에 만족하는 법을 배워야 할 것이고, 처세술이나 그 조직에서 버티기 위한 정치력을 발휘해야 할 것이다. 이러한 글들은 주변 서점에 널려있으니, 그런 책 한두권 읽어보기를 권장한다.‘이직’은 소프트웨어 개발자 생활을 하면서 계속 유혹과 한계를 경험하게 할 때마다 머릿속에 떠오를 것이다. 그때에 실수하지 않고, 좋은 판단을 하기 바라며. 가장 중요한 것은 ‘후회’ 하지 않고, 이미 결정한 것은 잊어버리는 것이 속 시원하다는 것이다.마지막으로 좋은 스타트업을 골라달라고 조언하는 경우에는 다음과 같이 답한다.스타트업은 좋은 동료가 될 생각이 있을 때에 들어가라는 것이다. 스타트업은 초기 멤버로서 합류하면서 고생도 같이 하고, 이익도 같이 나누는 동업자가 되는 것이다. 샐러리맨으로써 직장을 택하는 것과는 정말 다른 것이다.물론, 스타트업이 투자를 받고, 초기 멤버가 아닌 경우에는 위에서 언급한 내용과 별로 차이가 없다고 설명할 수 있다. 어느 규모나 별로 차이가 없었다.'이직'은 소프트웨어 개발자들에게는 매번 경험하게 된다. 그리고, 그 경험을 좋은 결과로 얻기를 바란다. 그리고, 언제나 좋은 선택이  필수이며, 인생 선배나 동료에게 좋은 조언을 구해보자.

어플리케이션 성능 분야에서 평균 응답 시간은 어플리케이션 서버가 사용자에게 요청 결과를 반환하는 데 걸리는 시간을 말합니다. 어플리케이션 서버의 응답시간은 일반적으로 밀리세컨드에 가깝지만 부하량에 따라 많은 시간이 걸리기도 합니다. 고객이 기다리는 시간 3초인터넷 초창기인 1999년 전자 상거래 사이트의 최적로드 시간은 8초 였습니다. 2006년도에 들어서는 4초까지 줄어들었습니다. 그리고 지금은 3초를 고객을 떠나게 만드는 시간으로 이야기 합니다. 구글 이 운영하는 더블클릭(https://www.doubleclickbygoogle.com/articles/mobile-speed-matters/)은 모바일 페이지가 로드되는데 3초가 지나면 사용자의 절반 이상이 서비스를 포기한다고 조사결과를 발표했습니다. 3초라는 시간 속에는 웹페이지의 렌더링 시간과 네트웍이 사용하는 시간등이 포함되어 있기 때문에 웹 어플리케이션이 소모해야 하는 시간은 실제로 밀리세컨드에 가깝습니다. 하지만 실제 서비스의 장애가 발생하면서 웹 어플리케이션의 평균 응답시간은 점점 길어지게 됩니다. 성능분석에서 평균 응답시간부하가 늘어나면서 임계치가 넘어가면 초당 처리량은 더이상 증가하지 않게 됩니다. 논리적으로 생각 해보면 초당 처리량이 더이상 증가하지 않은 상태에서 사용자만 늘어나면 TPS와 인지시간이 상수처럼 동작하므로 응답시간이 사용자에 비례하여 늘어나게 됩니다. [응답시간(Respons Time) = [동시사용자수 / 초당 요청수(TPS)] - 인지시간(Think Time)하지만 일반적인 상황에서 응답시간은 밀리세컨드 단위의 값이데 비해 인지시간은 3초에서 10초 이상의 값을 가지고 됩니다. 그럼 이번에는 성능을 분석하는 스토리를 만들어 보겠습니다. 우리가 영어 문장을 한글로 번역하는 웹 서비스를 만든다고 해 보겠습니다. 우리는 동시 사용자 100명을 예상하고 서비스를 만들고 있습니다. 여기서 서비스 특성상 사용자가 한번 번역을 요청하고 다음번 요청을 보내는데 평균 30초의 시간이 걸립니다. 마지막으로 최대 응답시간은 0.5초를 넘지 않도록 설계하려고 합니다. 이런 경우 우리가 목표로 하는 초당 요청수는 서비스를 동시에 사용하는 사람들의 요청을 시간으로 나누므로 계산식은 동시사용자수(100명)/(응답시간(0.5초) + 인지시간(30초)) 이고 결과값은 약 3.27이 됩니다.     초당 요청수(TPS) = 동시사용자수 / [응답시간(Respons Time) + 인지시간(Think Time)]이렇게 성능을 계산하는 과정에서 서비스의 처리시간 즉 응답시간은 인지시간에 비해 매우 적기 때문에 인지시간이 커지면 커질수록 TPS에 관여하는 비율이 0에 수렴하게 됩니다. 결론적으로 성능을 설계하는 시점에서 응답시간은 별로 중요한 이슈가 아니게 됩니다. 대신 인지시간이 중요해 집니다.인지시간(Think Time)이란?웹 서비스를 사용하는 사용자는 자신의 요청을 확인하는 시간이 필요합니다. 이렇게 이전 요청과 다음 요청 사이의 시간을 인지 시간이라고 합니다. 인지 시간은 사용자나 서비스 유형에 따라 다릅니다. 예를 들어 시스템 간 상호 작용은 사람이 관여하는 웹 서비스 상호작용에 비해 매우 낮은 인지 시간을 포함합니다. 또는 블로그 서비스에 비해 사전검색 서비스의 인지시간은 매우 짧을 것입니다. 서비스의 도메인을 분석하여 인지 시간을 결정하는 것은 매우 중요합니다. 인지시간을 사용하여 분당 완료해야 하는 요청 수는 물론 시스템에서 지원할 수 있는 동시 사용자 수를 계산할 수 있습니다. 튜닝 지표로서의 평균 응답시간현실에서 웹 서비스의 응답시간은 수식과 다르게 나타나게 됩니다. 그래서 많은 성능 분석 도구가 평균 응답시간을 보여주고 있습니다. 실제 성능 분석 도구들이 알려 주는 평균 응답시간은 수집 주기 동안에 수집된 트랜잭션의 응답 시간을 합산하여 평균한 값입니다.와탭의 서비스는 5초 간격으로 트랜잭션의 평균 응답시간을 계산합니다. 응답시간이 성능 지표보다 튜닝지표로서의 의미를 가집니다. 예를 들어 사용자가 적은 밤 시간에 배치잡과 같은 일부 응답시간이 길어짐으로써 사용자가 많은 낮보다 평균 응답시간이 더 길수도 있습니다. 하지만 실제 성능을 올리기 지표로써 응답시간은 매우 직접적입니다. TPS와 상관없이 평균 응답시간이 길어지는 요소가 있다면 주변 요소와 함께 평균 응답시간을 살펴봐야 합니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

개발자와 개발 조직에게 소스코드 리뷰는 필수적이다. 팀간의 협업과 대화를 보다 원활하게 만들어 주는 매우 필요한 절차이다. 슬랙과 같은 협업도구가 명쾌하게 의미 있게 활용되려면 개발팀 간의 소스코드 리뷰는 필수적으로 수행되는 것이 좋다.매우 당연한 이야기이지만, 소스코드 리뷰는 거북하고 불편하고 어렵고 힘들다. 그럼에도 불구하고 필수적인 이벤트가 되어야 하는 이유가 너무도 많다. 개발자들에게 코드리뷰에 대한 이슈를 설득하고 실제 행위를 발생시키는 것은 정말 어려운일이다. 더군다나 뜬금없이 코드리뷰 이야기를 회사나 팀리더에게서 갑자기 듣는다면 개발자는 매우 불편해 한다. 그것은 매우 당연한 반응이다. 그러므로, 가능하다면 팀 세팅 초기 시부터 이 소스코드 리뷰 문화는 만들어질 수 있게 노력하는 것이 최선일 것이다.초기에 세팅된다면 그 후에 들어오는 팀원들은 자연스럽게 그 문화에 익숙해진다. 이런 일련의 작업들은 결국 조직과 팀의 단결과 협력, 향후 유지보수에 매우 긍정적인 효과를 준다.매우 당연하지만 개발자들은 팀에 소속되고 빠져나가기를 반복한다. 이를 두려워하지 않는 방법 중에 가장 먼저 선택할 수 있는 것이 바로 코드 리뷰라는 행위다. 인수인계와 유지보수를 위해서 소스코드 리뷰를 각 단계별에 배치해두고, 그 시간을 투자하는 것을  아까워하지 않도록 하자.그렇다면, 소프트웨어의 본체인 소스코드를 타인이 리뷰한다는 것이 왜 어려울까? 그것은 소스코드는 언제나 완성상태가 아니라는 점 때문이다. 개발자의 생각은 무언가 다양한 변화를 예측하고 있고, 그 상세한 준비를 담고 있다. 언제나 소스코드는 완성 상태가 아니라, 변화되어야 하는 시간의 축을 담고 있기 때문이다.하지만, 소프트웨어 품질이 중요한 현재의 시점에서 본다면, 코드 리뷰라는 행위는 정말 필수 불가결한 행위에  해당한다고 생각한다.이런 필수적인 코드리뷰는 그 형태와 범위에 대해서 팀 내부에 잘 정의되어야 한다.그래서, 보통 이 코드리뷰를 어떻게 할 것인가에 대해서 조직이나 담당하는 사람의 경우에는 명쾌한 판단 기준이 있어야 한다. 그러한 ‘판단기준’을 가져야만 명확한  리뷰될 수 있다.이를 두고, 디자이너에게는 크리틱(critique-비평)이 있고, 개발자에게는 코드리뷰가 있다고 정의한다.좋은 비평을 받고 좋은 리뷰를 하려면 다음의 3가지 원칙이 필수이다.1. 리뷰는 언제나 상호 합의가 되어진 상황에서 진행되어야 한다.2. 리뷰어의 해당 결과물에 대해서 객관성을 가지고 서로 인지해야 한다3. 개발자 자신의 작업물에 대해서 정말 객관적으로 바라볼 수 있는 작성가가 선정되어야 한다.특히, 소프트웨어 코드는 정량적인 검토와 정성적인 검토를 구분해야 한다. 이 영역의 구분이 모호해지면, 리뷰는 그 방향성을 상실하게 된다. 그중에 특히, 정량적인 검토와 기본적인 규칙들은 가능한 자동화하고, 소스 형상관리 도구에서 기본적인 것들의 규칙들을 지키도록 권장하여야 한다. 최소한 이 정량적인 것만 자동화하고  규칙화해도 소프트웨어의 품질은 급상승한다.하지만, 코드는 논쟁을 발생시키고, 어떤 것이 우선적인지에 대해서 서술하기 매우 어렵다. 이러한 점은 정성적인 부분에 대해서 검토할 때에 고민하자.코드리뷰의 정도는 어느 정도 해주어야 하는가?그 전부터 주목하는 개발 방법론의 추세는 ‘테스팅’을 주로 하고, SRS와 같은 요구사항에 집중하기 보다는, TDD와 같은 방법으로 완성 산출물을 높이는 방법을 현재에는 주로 사용하고 있다.그것은 과거에는 요구사항을 통해서 결과물이 완성되는 SI성 개발이 주로였다면, 현재에는 요구사항은 계속 변화하고 버그 없는 결과물이 중요시되는 테스트를 얼마나 더 집중적으로 하느냐에 따른 웹서비스의 시대이기 때문에 그 방향성은 시대에 따라서 변화를 많이 하였다. 그래서, 슬프지만, 당장의 성과물을 위해서라면 코드리뷰보다는 테스팅에 집중하는 것이 더 효율적이다. 빠르게 고속 개발하고 테스트를 통해서 버그를 찾은 다음 수정하는 것이 ‘특정 기능들을 나열하고 기능을 만족하는 소프트웨어’의 경우에는 테스트 주도 개발 방법이 가장 적합하다고 할 수 있다.물론, 이러한 방향성이나 전체적인 틀에 대해서는 아키텍트가 잘 결정하여야 한다. 내가 속한 개발 결과물이 어떤 결과물이냐에 따라서 이 방법은 혼용되어져서 사용되어야 하기 때문이다.하지만, 이번 글의 주목적은 코드리뷰. SRS중심이건, TDD중심이건. 코드리뷰는 중요하다는 것을 강조하고 싶다. 특히, 코드리뷰는 ‘기능 나열’이 아닌, 어느 정도 이상의 복잡도나 코드 품질이 필요한 경우에는 필수적으로 수행하는 것이 매우 현명한 행동이다.물론, 코드리뷰 행위가 불필요한 업무들도 많다. 정해져 있는 단순한 업무를 수행하는 경우에는 굳이 할 필요 없다. 국내에서 SI를 하는 경우에는 대부분 코드리뷰가 필요 없는 업무를 하는 소프트웨어 개발자들이 절대 다수인 경우도 많이 보았다.일반적인 SI의 형태라면 워크 스루의 형태만 적합하다. 특정 도메인에 매몰되어 있고, 처리방법이 명쾌하기 때문에, 해당 경험들을 교환하는 것으로도 충분하기 때문이다. 그리고, 자동화된 테스트 수행방법을 최대한 갖추어두는 것이 가장 현명하다.그러므로, 코드리뷰는 어느 정도 솔루션이나 서비스 등을 고려하고 있는 곳에서 더욱 적합하다고 정의한다.코드리뷰는 특정 제품이나 서비스를 발전적으로 지향하고 있는 경우라면 필수적으로 선택해야 한다. 하지만, 일부 제품의 경우에는 발전적인 지향이 굳이 필요 없는 제품 라인업을 가진 경우에도 굳이 수행할 필요 없다.그 경우에는 선택적인 코드리뷰를 지향하면 된다. 비용상의 문제 때문에 굳이 코드리뷰를 억지로 진행할 필요는 없는 경우도 많다. 대부분의 소프트웨어 개발은 테스트 케이스를 잘 만들고, 통과시키는 것으로써 충분한 신뢰를 가지면 충분한 경우가 대부분이다.특히, 시장이 고착상태이거나, 특별한 변화의 폭이 없다면, 그 정도로 충분한 경우가 된다. 다만, 글로벌 서비스나 웹서비스 등의 지속적인 확장이 필요한 경우라면, 코드리뷰는 필수라고 할 수 있다.코드리뷰가 필요 없는 경우 체크리스트는 다음의 5가지 정도를 체크해보자.1. 특정 도메인만 다루는 팀이나 회사의 개발팀인가?2. 지난 2~3년 정도 솔루션이 크게 변한 것이 없으며, 향후로도 기업이나 팀에서 투자가 없을 예정이다.3. 현재 개발자들이 해당 솔루션에 대한 개발일을 5년 이상하고 있다.4. 기능 위주의 SI성 업무를 주로 처리하고 있으며, 복잡한 알고리즘은 존재하지 않는다.5. 비용과 일정상 개발팀에게 리소스 투여가 불가능하다위의 사례에서 1개 이상이라도 체크된다면, 코드리뷰는 성립하기 힘들다. 대부분 단념하고, TDD나 테스트 케이스를 가능한 많이 축적하여 소프트웨어 품질을 올리기를 권장한다.코드리뷰가 필요한 경우의 체크리스트도 다음의 5가지 정도를 체크해보자.1. 다국어와 시장이 다변화된 환경에서 소프트웨어가 구동되어야 한다.2. 코드의 복잡도가 높으며, 단순 기능 나열의 요구사항이 아니라, 소프트웨어 아키텍처가 별도로 구성되기 시작하였다.3. 사용자의 경험성을 증가하기 위하여 매우 많은 변화가 예측된다.4. 현재 개발 중인 서비스는 중단 없이, 지속적으로 발전되어야 하는 서비스이다.5. 목표 요구사항이 계속 변화하고 있고, 프레임워크를 지향하여 소프트웨어 품질의 요구사항이 매우 중요하다.위의 케이스에서 하나라도 해당이 된다면, 코드리뷰는 매우 효과적으로 소프트웨어에 의미 있는 결과물들을 얻어 내기 위한 좋은 방법이 된다.하지만, 다음과 같은 경우도 같이 고려하여야 한다.코드리뷰의 정도와 질에 대한 검토 리스트의 최소 체크리스트는 다음의 3가지이다. 물론, 이 정의는 조직 내의 아키텍트나 아키텍트 롤을 하는 사람이 결정하는 것이 좋다.1. 실험적인 코드인가?2. 1~2명 이상이 공동으로 작업하는 코드인가?3. 향후 버려질 가능성이 높은 코드인가?코드리뷰를 하지 않는 경우에는 해당 코드의 repository나 디렉터리를 완전하게 분리하고, 리뷰가 안된 코드를 명쾌하게 구분할 수 있어야 한다. 그리고, 그 정보는 팀 전체에게 공개되어야 한다.가장 첫 번째는 코딩규칙 가이드라인의 준수 여부를 체크하는 것이다.개발자들 간의 상호 중요한 것은 스타일 가이드이다. 하지만, 정말 지키기 어려운 것 또한 스타일 가이드라고 할 수 있다. 하지만, 스타일 가이드는 가능한 준수해야 한다. 하지만, 100% 준수하려는 것은 매우 비효율적인 상황을 만들 수 있다. 하지만, 이 경우에 최소한 리뷰어가 제시하는 기준이나 변경 방향에는 대부분 수긍하는 것이 가장 현명하며, 이 부분은 해당 팀의 가장 경험이 풍부한 사람이 리드하는 것이 좋다.그래서, 소프트웨어 개발에는 경험이 풍부한 아키텍트의 역할과 선임의 역할이 가장 중요하다. 소셜에서 이야기하는 가장 중요한 포인트는 이런 경험이 풍부한 선임 개발자가 있다면, 돈이 얼마가 들더라도 ‘개발팀’에 모셔야 한다! 가 정답일 것이다.아직까지 이 부분은 ‘공학’으로 해결할 수 없고, ‘엔지니어링’과 ‘경험’에 의존할  수밖에 없다.주석의 경우에도 ‘가독성’이 충 부한 코드에는 서술할 필요 없다. 이 부분에 대해서는 꾸준한 팀원들 간에 코딩 문화에 대해서  커뮤니케이션하면서 주석의 범위에 대해서 공론화하는 것이 현명하다. 그래서, 소프트웨어 개발은 대부분이 ‘커뮤니케이션’이고 ‘소통’이다. 그래서, ‘팀워크’이 가장 중요한 것이고. 변수의 명칭에 대해서도 ‘명확’하다는 선에서 합의해야 한다.테스트가 쉽지 않은 구조는 다른 문제를 야기한다. Junit과 같은 단위 테스트 도구로 손쉽게 정의가 가능한 구조가 아니라면, 변경해야 한다.코드리뷰 후에 분명하고 타당한 지적에도 고집이 세서 변화가 없는 경우에는 한두 번 이야기하고 더 이상 변화가 없다면, 포기하고. 해당 코드를 격리하여 관리하는 것이 현명하다.  팀원들 간에 감정이 상하는 것이 더 위험하다. 사람은 변하지 않는다 감정에 대한 다툼이나 기대를 할 필요가 없다.UI가 중요한 코드는 해당 코드들이 급변할 가능성이 농후하다. 처음부터 공을 들여서 추상화를 실현하지 않으면, 해당 코드 때문에 프로젝트가 심각해질 수 있다. 사용자에게 더 좋은 경험을 전달하려고 하면, UI코드는 계속 변화를 일으킨다.테스트 코드 여부? 로직에 대한 검토, 변수 네이밍 검토와 레이아웃에 대한 것들? 에 대해서는 다음과 같이 판단하고 체크해보자.코드리뷰는 대부분 ‘직관’에 의존한다. 그래서, 정말 어렵고. 경험이 풍부한 사람이 할  수밖에 없다. 다만, 이러한 코드 리뷰 시의 체크리스트 항목을 몇 가지 간단하게 정리할 수 있다. 최소한의 2가지는 꼭 지키자.코드 리뷰 시의 필수 내용 두 가지는 다음과 같다.1. 코드 검토는 1시간 이내에 끝낼 분량으로 검토한다.2. 코드는 200라인 이상을 한 번에 검토하지 마라이 기준이 어겨지면, 리뷰어는 제대로 된 리뷰를 하기 어려울 것이다.  그리고, 이러한 리뷰를 하는 동안 기능에 대한 검토 체크사항에 대해서 나열해 보면 다음과 같이 나열이 될 수 있을 것이다.1. 시스템의 요구사항이 제대로 반영되었는가?2. 시스템의 설계의 규격대로 구현되었는가?3. 과도한 코딩을 하고 있지 않는가?4. 같은 기능 구현을 더 단순하게 할 수 있는가?5. 함수의 입출력 값은 명확한가?6. 빌딩 블록들( 알고리즘, 자료구조, 데이터 타입, 템플릿, 라이브러리, API )등이 적절하게 사용되었는가?7. 좋은 패턴과 추상화( 상태도, 모듈화 )등을 사용해서 구현하고 있는가?8. 의존도가 높은 함수나 라이브러리 등의 의존관계에 대해서 별도 기술하고 있는가?9. 함수의 반환(exit)은 한 곳에서 이루어지고 있는가?10. 모든 변수는 사용 전에 초기화하고 있는가?11. 사용하지 않는 변수가 있는가?12. 하나의 함수는 하나의 기능만 수행하고 있는가?또한, 스타일과 코딩 가이드에 대해서고 검토하고 리딩을 해야 한다.1. 코딩 스타일 가이드를 준수하고 있는가?2. 각 파일의 헤더 정보가 존재하는가?3. 각 함수의 정보를 코드에 대해서 설명하기에 충분한가?4. 주석은 적절하게 기술되어있는가?5. 코드는 잘  구조화되어있는가? ( 가독성, 기능적 측면 )6. 헤더, 함수 정보를 도구로 추출해서 자동으로 문서화할 수 있는 구조인가?7. 변수와 함수의 이름이 일관되게 기술되어 있는가?8. 프로젝트의 가이드를 통한 네이밍 규칙을 준수하고 있는가?9. 숫자의 경우 단위에 대해서 기술하고 있는가?10. 숫자를 직접 서술하지 않고, 상수를 사용하고 있는가?11. 어셈블리 코드를 사용하였다면 이를 대체할 방법은 없는가?12. 수행되지 않는 코드는 없는가?13. 주석 처리된 코드는 삭제가 되었는가? ( 버전 체크가 되었는가? )14. 간결하지만 너무 특이한 코드가 존재하는가?15. 설명을 보거나 작성자에게 물어봐야만 이해가 가능한 코드가 있는가?16. 구현 예정인 기능이 있다면, ToDo주석으로 표시되어 있는가?가장 중요한 아키텍처에 대한 검토를 잊으면  안 된다.1. 함수의 길이는 적당한가? ( 화면을 넘기면  안 된다. )2. 이 코드는 재사용이 가능한가?3. 전역 변수는 최소로 사용하였는가?4. 변수의 범위는 적절하게 선언되었는가?5. 클래스와 함수가 관련된 기능끼리 그룹화가 되었는가? ( 응집도는 어떤가? )6. 관련된 함수들이 흩어져 있지 않는가?7. 중복된 함수나 클래스가 있지 않는가?8. 코드가 이식성을 고려하여 작성되었는가? ( 프로세스의 특성을 받는 변수 타입이 고려되어있는가? )9. 데이터에 맞게 타입이 구체적으로 선언되었는가?10. If/else구분이 2단계 이상 중접되었다면 이를 함수로 더 구분하라11. Switch/case문이 중첩되었다면 이를 더 구분하라12. 리소스에 lock이 있다면, unlock은 반드시 이루어지는가?13. 힙 메모리 할당과 해제는 항상 짝을 이루는가?14. 스택 변수를 반환하고 있는가?15. 외부/공개 라이브러리 사용하였을 경우에 MIT 라이선스를 확인했는가? GPL의 경우에는 관련된 영역에서만 사용해야 한다.16. 블로킹 api호출시에 비동기적인 방식으로 처리하고 있는가?당연하겠지만, 예외처리 관련 체크리스트도 제대로 검토해야 한다.1. 입력 파라미터의 유효 범위는 체크하고 있는가?2. 에러코드와 예외(exception)의 호출 함수는 분명하게 반환되고 있는가?3. 호출 함수가 어려와 예외처리 코드를 가지고 있는가?4. Null포인트와 음수가 처리되는 구조인가?5. 에러코드에 대해서 명쾌하게 선언하고 처리하고 있는가?6. switch문에 default가 존재하고, 예외처리를 하고 있는가?7. 배열 사용시에 index범위를 체크하는가?8. 포인트 사용시에 유요한 범위를 체크하는가?9. Garbage collection을 제대로 하고 있는가?10. 수학계 산시에 overflow, underflow가 발생할 가능성이 있는가?11. 에러 조건이 체크되고 에러 발생 시 로깅 정보를 남기는가?12. 에러 메시지와 에러코드가 에러의 의미를 잘  전달하는가?13. Try/catch 에러 핸들링 사용방법은 적절하게 구현되었는가?요즘 프로그램은 대부분 이벤트성으로 구동되지만, 시간의 흐름에 대한 체크는 프로그램의 뼈대를 이루게 된다. 이 부분에 대해서도 제대로 검토해야 한다.1. 최악의 조건에 대해서 고려하였는가?2. 무한루프와 재귀 함수는 특이사항이 아니라면 없어야 한다.3. 재귀 함수 사용시에 call stack값의 최댓값이 고정되어 있는가?4. 경쟁조건이 존재하는가?5. 스레드는 정상 생성, 정상 동작하는 코드를 가지고 있는가?6. 불필요한 최적화를 통해서 코드 가독성을 희생하였는가?7. 임베디드의 경우에도 최적화가 매우 중요하지 않다면, 가독성을 더 중요하게 해야 한다가장 중요한 검증과 시험에 대해서도 제대로 인지하여야 한다. 그리고, 테스트를 위해서 가능한 최대한 자동화를 하기 위한 방법들을 이용해야 한다.1. 코드는 시험하기 쉽게 작성되었는가?2. 단위 테스트가 쉽게 될 수 있는가?3. 에러 핸들링 코드도 잘  테스트되었는가?4. 컴파일, 링크 체크 시에 경고 메시지도 100% 처리하였는가?5. 경계값, 음수값, 0/1등의 가독성이 떨어지는 코드에 대해서 충분하게 경계하고 있는가?6. 테스트를 위한 fault 조건 재현을 쉽게 할 수 있는가?7. 모든 인터페이스와 모든 예외 조건에 대해서 테스트 코드가 있는가?8. 최악의 조건에서도 리소스 사용은 문제가 없는가?9. 런타임 시의 오류와 로그에 대비한 시스템이 있는가?10. 테스트를 위한 주석 코드가 존재하는가?간혹 등장하는 하드웨어에 대한 테스트도  마찬가지이다. 다음과 같은 기준들을 통해서 검토해야 한다.1. I/O 오퍼레이션 코드에 대한 테스트로 하드웨어가 정상적인 동작을 보장하는가?2. 최소/최대 타이밍 요구사항에 대해서도 하드웨어 인터페이스가 충족하는가?3. 멀티 바이트 하드웨어 레지스터가 read/write오퍼레이션 중에도 값이 바뀌지 않음을 보장하는가?4. 시스템이 잘 정의된 하드웨어 상태로 리셋하는 것을 S/W가 보장하는가?5. 하드웨어의 전압이 떨어지거나 전원이 차단되는 경우에 잘 처리하는가?6. 대기모드 진입 시와 빠져나 올 때에 시스템이 옳게 동작하는가?7. 사용하지 않는 인터럽트 벡터가 에러 핸들러에 연결되어 있는가?8. EEPROM손상(데이터 깨짐)을 막기 위한 메커니즘이 있는가? ( 쓰기 동작 중 powe loss)등구체적으로 코드리뷰를 하고자 한다면, 다음의 코드리뷰에 대한 기법과 적당한 방법을 다음과 같이 설명할 수 있다.이러한 코드 리뷰를 위한 몇 가지 방법들이 알려져 있다. 그것들을 몇 가지 정리하여 보면 다음과 같다. 코드 인스펙션은 가장 정형화된 기법으로 전문화된 코드리뷰팀을 통해서 구분하는 방법이다. 이 방법은 리소스가 풍부하고, 일정에 여유가 있는 경우에만 사용이 가능하다. 대부분 대기업이나 대형 포털에서 구현 가능한 방법이라고 할 수 있다. ( 이런 곳에 있다면 행복해 하자. ~.~ ) 하여간, 비용과 일정 등이 있다면 이 방법이 현명하다. 그리고, 코드리뷰에 대한 품질에 대해서 정량적인 보고와 구성을 만들어 낼 수 있다는 것은 코드 인스팩션의 가장 좋은 장점이다. 이 코드 인스팩션을 하기 위한 롤을 구분하면 다음과 같이 4가지 롤로 구분할 수 있다.1. ModeratorA. 실질적인 매니저로 팀 간의 인터페이스와 리소스, 인프라를 확보하고, 프로세스에 대한 정의와 산출물의 정리를 담당한다.2. ReaderA. 각 산출물을 읽고, 리뷰하고, 방향성을 제시한다. 보통, 지식이 많은 사람이 담당한다.3. Designer/CoderA. Reader의 지시에 따라서 코드를 검증하고 잠재적인 발견 등의 수정 방안을 만든다.4. TesterA. 진행 중인 코드와 권장 수정 코드에 대해서 검증한다.그리고, 코드 인스펙션은 다음과 같은 6단계로 진행된다.1. PlanningA. 계획 수립2. OverviewA. 교육과 역할 정의3. PreparationA. 인터뷰와 필요한 문서 습득, 툴 환경 구축4. Meeting(Inspection)A. 각자의 역할대로 수행5. ReworkA. 보고된 Defect 수정6. Follow-upA. 보고된 Defect가 수정되었는지 확인이러한 절차를 통해서, 코드 인스팩션이 수행되면, 상당히 명쾌한 리뷰가 진행되게 된다. 하지만, 일정과 비용 문제 때문에 이 작업은 대부분의 스타트업에서는 선택하기 어렵다. 그래서 사용하는 방법 중의 하나가 팀 리뷰이다.팀 리뷰는 일정한 계획과 프로세스만 따르는 방법으로, 코드 인스펙션보다는 좀 덜 정형화된 방법으로 진행한다. 보통은 일주일에 한번 정도 팀 리뷰를 수행하거나, 특정 모듈이나 기능이 완료되는 시점을 기준으로 테스트 결과를 가지고 리뷰를 하는 방법을 사용한다.또한, 위험하거나 의견이 필요한 경우에도 팀 리뷰는 유용하다. 일반적인 팀에서 사용하는 방법이다.하지만, 이 역시. ‘리뷰’에 대한 제대로 된 인식이 없다면, 적용하기 어렵다. 그래서, 가끔 사용되는 방법이고, 과거 국내 SI업체들이 주로 사용하던 방법 중의 하나가 ‘웍쓰로’이다.웍 쓰루(Walkthrough)는 단체로 하는 코드 리뷰 기법 중에 비정형적인 방법으로, 발표자가 리뷰의 주제나 시간을 정해서 발표하고 동료들로부터 의견이나 아이디어를 듣는 시간을 가지는 방법으로써 주로 사례에 대한 정보 공유나 아이디어 수집을 위해서 사용하는 방법이다.이 방법은 ‘특정 도메인’에 종속된 코드를 만들거나, 비슷한 SI성 형태의 업무를 수행하는 경우에 적합하다. 그래서, 국내의 SI업체에서는 적극적으로 사용되면 좋겠지만. 이 ‘시간’마저도 부정확하고, 갑을병정의 SI체게에서 ‘정보공유’나 ‘아이디어 수집’과 같은 커뮤니케이션이 자유롭게 일어나는 것은 매우 힘들다.이 웍 쓰루는 동일한 조직 내에서 동일한 목적의식이 분명한 팀에서나 활용이 가능한 방법이다. 웍 쓰루를 SI에서 시도한 경우에는 대부분 실패했거나, 목적의식이 다르기 때문에 불분명한 결론들이 대부분 도출되었다.대부분의 국내 스타트업이나 IT 전문기업들은 ‘리뷰’에 대해서 상급 관리자들이 제대로 허락을 해주지 않는다.대부분은 팀내에서 어떻게든 자체적으로 해보려고 한다. 그래서, 팀장의 권한 선에서 적절하게 리뷰를 하는 방법 중의 하나가 Peer review or over the shoulder review방법이다. 이 방법은 보통 2~3명이 진행하는 코드리 뷰로 코드의 작성자가 모니터를 보면서 코드를 설명하고, 다른 한 사람이 설명을 들으면서 아이디어를 제안하거나 Defect를 발견하는 방법이다.또한, 이 방법은 신입사원이나 인턴사원의 경우에 업무 이해도를 높이면서 해당 코드를 사용할 수 있는 수준으로 활용할 경우에 의미 있는 방법이다. 문제는 이 방법은 개발자의 인력 투입이 거의 두배 이상으로 증가하는 것으로써, 고품질의 영역을 개발하거나, 빠른 시간 안에 신입 개발자의 업무 이해도를 높이는 경우가 아니라면 시행하지 않는다.이렇게도 리뷰가 진행이 되지 않으면, Passaroud는 돌려 보기 방법을 사용한다. 이 방법은 원래 상세한 리뷰 방법은 아니다. 온라인이나 실시간성이 아니라, 리파지토리나 이메일 등을 사용하여 천천히 리뷰하는 방식에 해당하는데, 속도는 느리지만, 중요한 코드이거나, 제품의 기능 개선이 필요한 경우에는 아주 의미가 있다. 보통은 제품의 기능 개선을 위하여 사용하는 방법이다.이처럼 리뷰의 방법에는 다양한 방법이 있지만, 결론적으로는 어느 정도 개발 조직이 서로  커뮤니케이션하고, 목적의식을 통일하고, 적절한 시간 분배를 통해서 리뷰를 할 수 있는 시간을 만들어 내느냐가 리뷰의 핵심이라고 할 수 있다.리뷰를 통해서 소프트웨어의 품질을  끌어올리고, 개발자들과 소통하고, 방향성을 만들어 내며, 새로운 기능 개선 작업을 위해서 리뷰는 다양하게 활용된다. 어떤 관점으로 리뷰를 할 것이고, 어떤 관점으로 리뷰라는 프로세스를 개발 프로세스에 탑재할 것인가에 대해서 진지하게 고민하는 것. 그것이 아키텍트의 첫 번째 역할 아닌가 한다.

지난 주에는 학생들이 서로 간의 과제를 채점해주는 방식의 과제 채점 방법인 동료 평가에 대해 알아보았습니다. 동료 평가는 강의에 크기에 거의 무관하게 사용될 수 있고, 학생들은 다른 학생들이 제출한 과제를 채점하면서 자기가 생각하지 못했던 새로운 아이디어를 발견하거나, 자신이 했던 것과 유사한 실수를 하는 친구에게는 자신의 경험을 바탕으로 건설적이고 유용한 피드백을 줄 수 있는 등의 장점도 있었습니다.엘리스 시스템에서 코드 공유 기능을 이용하면 동료 평가를 진행할 수 있습니다.그러나 동료 평가가 항상 만능인 것만은 아닙니다. 프로그래밍 수업에서 동료 평가는 크게 보면 “다른 사람의 프로그래밍 코드를 이해”하고, “이해한 것을 바탕으로 알맞은 평가”를 하는 두 단계로 이루어진다고 볼 수 있는데, 프로그래밍에 익숙하지 않은 대다수 학생에게는 “다른 사람의 코드를 이해”하는 첫 번째 단계부터가 큰 고난으로 다가오기 때문입니다. 이는 비단 학생의 문제일 뿐만이 아니라 실제 현장에서 일하고 있는 숙련된 프로그래머에게도 마찬가지입니다. 선행 연구에 따르면 다른 사람의 코드를 코드 그 자체만 보고 이해하는 것은 숙련된 프로그래머에게도 어려운 일이며, 그중에서도 특히나 해당 코드를 작성한 저자의 의도를 이해하는 것이 어렵다는 설문 결과가 있습니다. 몇 년이 넘는 시간 동안 수많은 코드를 읽어보았을 숙련자에게도 어려운 일인데, 프로그래밍에 전혀 경험이 없는 학생들에게는 얼마나 더 큰 어려움으로 다가올지 예상해보는 것은 어려운 일이 아닌 것 같습니다.그렇다면 프로그래밍 교육의 혁신을 추구하는 연구팀으로써 이를 두고만 볼 수는 없는 것은 당연지사. 동료 평가를 성공적으로 완수하기 위해 학생들에게 필요한 것은 무엇이고, 또 프로그래밍 교육 툴의 일부로서 제공해 줄 수 있는 것은 어떤 것들이 있을지 고민해보게 되었습니다. 그리고 본 연구팀은 다양한 대학교 전산 과목에서 조교로서 활동했던 경험과 프로그램 개발자로서 Git 등의 코드 버전 관리 도구, GitHub와 같은 오픈소스 커뮤니티에서 경험 등을 바탕으로 다음과 같은 접근을 해보았습니다.숙련된 오픈소스 개발자들도 리뷰를 위해 코드를 한 줄 한 줄 비교해가며 차근차근 읽어나가야 하는데, 왜 프로그래밍에 익숙하지 않은 학생들에게는 이 과정을 전부 생략한 채 마지막 결과(제출된 코드)만 보여주고 평가를 하게 하는 걸까? 오히려 숙련된 개발자들보다는 학생들에게 “한 줄” 단위 로, 아니면 이보다 더 세세하게 “한 글자” 단위로 코드가 처음부터 끝까지 완성되는 과정을 보여주는 것이 더 효과적이지 않을까?Eliph: Effective Visualization of Code History for Peer Assessment in Programming Education백문이 불여일견, 위의 이미지는 실험을 위해 제작된 프로그래밍 교육용 동료 평가 시스템 Eliph의 실제 사용 모습입니다. 프로그래밍에 익숙하지 않은 학생들이 동료 평가 과정에서 다른 학생의 코드를 이해하는 데에 어려움을 겪는 것은, 마지막으로 제출된 코드만 보아서는 문제 풀이 과정 전반에 대한 이해가 어렵기 때문이라는 것을 가설을 바탕으로, “그렇다면 문제 풀이 과정을 최대한 세세하게 보여주자!”는 아이디어를 구현한 것이 위의 보이는 Eliph 시스템입니다.Eliph는 학생이 프로그래밍 문제를 푸는 과정을 처음 시작부터 마지막으로 제출할 때까지의 키보드 입력, 코드 실행 결과, 중간 채점 결과 등을 모두 기록한 뒤, 나중에 다른 사람이 자신의 코드를 평가할 때 되돌려볼 수 있는 기능을 제공합니다. 그리고 이를 통해 (1) 평가를 받는 학생은 자신이 작성한 코드에 대한 의도를 평가자에게 더 잘 전달할 수 있고, (2) 평가를 하는 학생은 저자의 생각의 흐름을 함께 따라가며 코드를 더 쉽고 명확하게 이해할 수 있어 양쪽 모두가 동료 평가를 더 효과적으로 활용할 수 있습니다.본 연구팀은 Eliph 시스템을 효과를 검증하기 위해 실제 대학교 전산학과 수업에서 수강생 60명의 학생을 대상으로 시스템을 검증해보았습니다. 그 결과, 평가자가 Eliph 시스템을 사용해서 다른 사람의 코드를 평가할 때 코드 저자의 의도를 더 잘 파악할 수 있어 평가에 도움이 되었다는 것을 확인할 수 있었습니다(좌측 그래프). 또한, Eliph 시스템을 사용하여 진행된 동료 평가로부터 제출된 피드백이 기존의 방식으로 진행된 동료 평가로부터 제출된 피드백들보다 저자들에게 더 높은 만족도의 준다는 것을 확인할 수 있었습니다(우측 그래프). 좀 더 자세한 결과와 분석은 아래의 참고 문헌의 Eliph 논문에서 직접 확인해보실 수 있습니다.마치며이번 글에서는 프로그래밍 교육에서 동료 평가의 중요성과 실제로 수업에서 동료 평가를 사용하기 위해 넘어야 할 난관들을 소개해보았습니다. 그리고 프로그래밍에 익숙하지 않은 학생들이 동료 평가를 효과적으로 활용할 수 있도록 도와주는 시스템 Eliph를 간략하게 소개해드렸습니다. 아직 Eliph 시스템은 프로토타입으로만 개발되어 연구용으로만 사용되고 있지만, 조만간 엘리스 교육 플랫폼에서 사용해보실 수 있도록 열심히 준비하고 있으니, 기대해주시면 감사하겠습니다.참고 문헌Park, Jungkook, et al. “Eliph: Effective Visualization of Code History for Peer Assessment in Programming Education.” Proceedings of the 2017 ACM Conference on Computer Supported Cooperative Work and Social Computing. ACM, 2017.#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개

버즈빌에서는 미국과 일본을 비롯한 전 세계 30개국에서 1,700만 이상의 유저의 행동에 대한 데이터를 수집하고 있습니다. 이 데이터에는 유저들이 잠금화면에서 어떤 Action을 수행하는지부터 잠금화면에 어떤 광고가 노출되고 유저들이 어떤 광고를 클릭 하는 지 등의 정보들이 포함되는데요. 이러한 데이터는 여러 종류의 다른 소스로부터 오고 각기 다른 종류의 DB (MySQL, DynamoDB, Redis, S3 등등) 에 저장됩니다. 하지만 데이터를 분석하고 활용하기 위해서는 이렇게 흩어져서 저장된 데이터들을 한 곳으로 모으는게 필수적입니다. 그래서 저희 팀에서는 이렇게 다양한 소스로 부터 발생해서 다양한 DB에 저장된 데이터를 어떤 과정을 통해 한 곳으로 모을 것인가에 대해서 고민하게 되었습니다. 그리고 고민 끝에 각각의 DB에 저장된 데이터를 하나의 큰 데이터 스토리지에 모을 수 있는 ‘데이터 파이프라인’을 구축하는 계획을 세우게 되었습니다. 하지만 다양한 소스로부터 수집된 수많은 데이터들을 잘 유지해가며 하나의 큰 DB에 모을 수 있는 데이터 파이프라인을 구축하는 것이 쉽지 않았는데요. 이 포스팅을 통해서 버즈빌에서는 어떻게 각각의 데이터들을 수집하고 저장하는지 또 이런 데이터들을 통합하기 위한 파이프라인을 어떻게 구축했는지 공유하고자 합니다. 본격적인 이야기에 앞서 현재 버즈빌에서 모든 데이터가 모이는 데이터 스토리지로 사용 중인 RedShift에 대해 이야기하고 싶습니다. 개인적으로는 정말 쓰면 쓸수록 감탄이 나오는 데이터 스토리지라고 생각합니다. Redshift는 AWS에서 관리하는 SQL기반의 열기반 스토리지(SQL based columnar data warehouse)이며 복잡하고 대규모의 데이터 분석에 적합합니다. 고객들로부터 생성된 수많은 종류의 데이터를 기반으로 다양한 인사이트를 얻고자 하는 많은 기업들(Yelp, Coursera, Pinterest 등)이 사용하고 있는 솔루션 이기도 합니다. 버즈빌에서는 여러가지 특징을 고려하여 Redshift를 도입하게 되었는데요. 그 이유는 아래와 같습니다.  Performance Performance Performance.     Column 기반 스토리지 -> 필요한 Column에만 접근한다.   Join이나 aggregation이 많은 복잡한 쿼리도 쉽게 계산할 수 있다.   분산 저장 방식 (Distributed Storage)   Date Ingestion이 빠르다. (Ingest first, index and clean later)     Horizontal Scalability   sharding이나 clustering에 추가적인 complexity가 필요하지 않다. 데이터가 원래 노드에 저장되기 때문에 horizontal scaling을 위해서는 그냥 추가적인 노드만 붙이면 된다. 다른 AWS서비스들과 쉽게 연동이 가능하다. (장점 이자 단점)    하지만 몇 개의 아쉬운 점들도 있습니다. :  다른 RDBMS와 달리 Mutilple indice를 지원하지 않는다.  1 Distribution Key and 1 Sort Key   MySQL이나 다른 RDBMS처럼 uniqueness나 foreign key constraint를 걸 수 없다.     모은 데이터를 어떤 방식으로 Redshift로 옮겨야 할까요? 버즈빌이 구축한 데이터 파이프 라인은 크게 3갈래의 메인 루트가 있습니다.   1) Athena Preprocessing Batch job을 통해서 (잠금화면 활동, 광고 할당) Why? 전처리 작업(Preprocessing)이 필요한 가장 큰 이유는 들어오는 데이터의 어마어마한 크기 때문입니다. 또 어떤 데이터들은 너무 raw하기 때문에 애널리스트나 데이터 사이언티스트가 분석에 활용할 수 있는 형태로 바꾸기위해 전처리가 필요하기도 합니다. 버즈빌에서는 이런 데이터들을 처리하기 위해서 AWS Athena를 사용하고 있습니다. Athena는 과금 방식이 Athena 쿼리로 읽은 데이터의 사이즈를 기반으로 하기 때문에 다른 EMR이나 MapReduce solution들을 사용했을때보다 상대적으로 적은 비용으로 활용할 수 있다는 장점이 있습니다. How?  먼저 S3로 데이터를 보냅니다. 그 후, Athena를 활용하여 데이터를 가공/처리합니다. 가공된 데이터를 읽어서 Redshift로 보냅니다. (COPY command 활용)  Pros?  서버를 따로 가질 필요가 없습니다. (EMR 클러스터나 서버를 관리할 필요가 없음) 경제적입니다. (S3에서 1TB를 읽을때마다 $5 정도의 비용)  Cons?  사용량이 몰리는 시간대 (12:00 AM UTC)에는 일부 쿼리가 실패할 수 있습니다. -> 중요하고 필수적인 데이터는 Athena가 아닌 다른 방법을 통해 처리하는것이 적합합니다. PRESTO DB의 기능을 (아직은) 온전히 활용할 수 없습니다.     2) Firehose를 통해서 (Impression, Clicks, Device, Events) Why? Kinesis Firehose는 Redshift, Elasticsearch, S3와 같은 최종 목적지까지 다양한 데이터들을 안정적으로 옮길 수 있는 파이프라인을 제공할 뿐 아니라 Fluentd와 매끄럽게 잘 연동된다는 점에서 굉장히 뛰어난 서비스 입니다. Fluentd는 서버로부터 firehose까지 데이터가 안정적이고 꾸준하게 전달 될 수 있도록 도와줍니다.  따라서 firehose와 fluentd의 연동을 통해서 따로 두개의 파이프라인 ( SERVER -> S3, S3 -> Redshift) 을 관리할 필요 없이 데이터 소스부터 최종 저장소까지 이어지는 하나의 파이프 라인만 관리할 수 있게 됩니다. How?  (https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)  적절한 data format과 원하는 ingestion period를 설정하여 Firehose delivery stream을 만듭니다.   conf["user_activity"] = { "DataTableName": "user_activity", "DataTableColumns": "user_id, app_id, activity_type, timestamp", "CopyOptions": "FORMAT AS JSON "s3://buzzvil-firehose/sample/user_activity/jsonpaths/user_activity_log-0001.jsonpaths" gzip TIMEFORMAT AS "YYYY-MM-DDTHH:MI:SS" ACCEPTINVCHARS TRUNCATECOLUMNS COMPUPDATE OFF STATUPDATE OFF", "jsonpaths_file": "buzzvil-firehose/sample/user_activity/jsonpaths/user_activity_log-0001.jsonpaths", } configuration = { "RoleARN": "arn:aws:iam::xxxxxxxxxxxx:role/firehose_delivery_role", "ClusterJDBCURL": "jdbc:redshift://buzzvil.xxxxxxxxx.us-west-2.redshift.amazonaws.com:5439/sample_db", "CopyCommand": { "DataTableName": sample_table, "DataTableColumns": conf[type]["DataTableColumns"], "CopyOptions": conf[type]["CopyOptions"], }, "Username": db_user, "Password": db_password, "S3Configuration": { "RoleARN": "arn:aws:iam::xxxxxxxxxxxx:role/firehose_delivery_role", "BucketARN": "arn:aws:s3:::firehose_bucket", "Prefix": "buzzvil/user_activity/", "BufferingHints": { "SizeInMBs": 64, "IntervalInSeconds": 60 }, "CompressionFormat": "GZIP", "EncryptionConfiguration": { "NoEncryptionConfig": "NoEncryption", } } }  2. Fluentd docker containers을 각각의 서버에서 세팅하고 실행합니다.  @type tail path /var/log/containers/buzzad/impression.json pos_file /var/log/containers/td-agent/impression-json.pos format none tag firehose.impression @type kinesis_firehose region us-west-2 delivery_stream_name "prod-buzzad-impression-stream" flush_interval 1s data_key message  3. Firehose에서 데이터를 잘 모아서 Redshift 문제없이 보내고 있는지 모니터링 합니다.  Pros?  빠르고 안정적인 데이터 전송이 가능합니다. 모니터링이 편합니다.  Cons?  Schema가 자동으로 바뀌지 않습니다.( Redshift의 Schema를 수동으로 일일히 변경해주어야 합니다.)     3) MySQL Asynchronous Loads를 통해 (Ads, Contents, Ad Provider, Ad Publishers) Why? 여러대의 RDS MySQL DB로부터오는 데이터간의 sync를 맞춰가며 Redshift로 데이터를 복제하기 위해서는 3가지의 테크닉을 활용해야만 합니다. (이 방법은 소개하고 있는 세 메인 루트 중에서 가장 매력도가 떨어지는 방법입니다..) How?  FULL_COPY  MySQL 테이블 전체를 복사해서 SQL insert를 통해서 Redshift에 복사합니다.     INCREMENTAL_COPY  이전에 복사한 가장 마지막 Primary key부터 시작해서 새로생긴 row들을 읽어서 Redshift로 복사합니다.     UPDATE_LATEST_COPY  이전에 복사한 가장 마지막 타임스탬프부터 시작해서 새로 생성되거나 업데이트된 row들을 Redshift로 복사합니다.(중복된 값은 삭제).    Pros?  데이터의 특징에 맞게 잘 조정된 방법입니다. binary log를 통한 Replication보다 훨씬 다루기 쉽습니다.  Cons?  MySQL을 잘 조정하기 위해 여러대의 서버나 lambda를 다루어야만 합니다. -> Redshift sync task를 위해서 안정적인 schema altering을 할 수 있을 만큼 Redshift의 ORM이 발전된 상황은 아닙니다..    어떤 데이터를 다루는지에 따라서 위에서 소개한 3가지 방법 중 어떤 방법을 활용해야할지가 달라진다고 할 수 있습니다. 예를 들어 Transactianl log 같은 데이터들의 경우에는 firehose를 통해 전달하는 방법이나 먼저 aggregate하는 과정을 거친 후에 Redshift에 저장하는 식으로 처리를 해야 합니다. 그리고 MySQL에 저장된 fact table같은 데이터들은 CDC (change data capture) sync method를 통해서 Redshift에 데이터를 전달하고 동기화를 하는 과정이 필요합니다. 버즈빌에서는 위에서 소개해드린 3가지 방법을 적절히 조합해가면서 BD 매니저나 애널리스트들이 서비스간 플랫폼간의 데이터분석을 쉽게 할 수 있는 데이터 환경을 구축하기 위해서 노력하고 있습니다.

레진코믹스의 서버 시스템은 잘 알려진대로 Google AppEngine에서 서비스되고 있지만, 이런저런 이유로 인해 최근에는 일부 컴포넌트가 Amazon Web Service에서 서비스되고 있습니다. AWS 에 새로운 시스템을 셋업하면서, 기존에 사용하던 PaaS인 GAE에서는 전혀 고민할 필요 없었던, 배포시스템에 대한 고민이 필요했습니다. 좋은 배포전략과 시스템은 안정적으로 서비스를 개발하고 운영하는데 있어서 필수적이죠.초기에는 Beanstalk을 이용한 운영에서, Fabric 을 이용한 배포 등의 시행착오 과정을 거쳤으나, 현재는 (스케일링을 위해 어차피 사용할 수밖에 없는) Auto Scaling Group을 이용해서 Blue-green deployment로 운영 중입니다. ASG는 여러 특징 덕분에 배포에도 유용하게 사용할 수 있습니다.ASG를 이용한 가장 간단한 배포는, Instance termination policy 를 응용할 수 있습니다. 기본적으로 ASG가 어떤 인스턴스를 종료할지는 AWS Documentation 에 정리되어 있으며, 추가적으로 다음과 같은 방식을 선택할 수 있습니다.OldestInstanceNewestInstanceOldestLaunchConfigurationClosestToNextInstanceHour여기서 주목할 건 OldestInstance 입니다. ASG가 항상 최신 버전의 어플리케이션으로 스케일아웃되게 구성되어 있다면, 단순히 인스턴스의 수를 두배로 늘린 뒤 Termination policy 를 OldestInstance 로 바꾸고 원래대로 돌리면 구버전 인스턴스들부터 종료되면서 배포가 끝납니다. 그러나 이 경우, 배포 직후 모니터링 과정에서 문제가 발생할 경우 기존의 인스턴스들이 이미 종료된 상태이기 때문에 롤백을 위해서는 (인스턴스를 다시 생성하면서) 배포를 다시 한번 해야 하는 반큼 빠른 롤백이 어렵습니다.Auto scaling lifecycle 을 이용하면, 이를 해결하기 위한 다른 방법도 있습니다. Lifecycle 은 다음과 같은 상태 변화를 가집니다.기본적으로,ASG의 인스턴스는 InService 상태로 진입하면서 (설정이 되어 있다면) ELB에 추가됩니다.ASG의 인스턴스는 InService 상태에서 빠져나오면서 (설정이 되어 있다면) ELB에서 제거됩니다.이를 이용하면, 다음과 같은 시나리오로 배포를 할 수 있습니다.똑같은 ASG 두 개를 구성(Group B / Group G)하고, 그 중 하나의 그룹으로만 서비스를 운영합니다.Group B가 라이브 중이면 Group G의 인스턴스는 0개입니다.새로운 버전을 배포한다면, Group G의 인스턴스 숫자를 Group B와 동일하게 맞춰줍니다.Group G가 InService로 들어가고 ELB healthy 상태가 되면, Group B의 인스턴스를 전부 Standby로 전환합니다.롤백이 필요하면 Standby 상태인 Group B를 InService 로 전환하고 Group G의 인스턴스를 종료하거나 Standby로 전환합니다.문제가 없다면 Standby 상태인 Group B의 인스턴스를 종료합니다.이제 훨씬 빠르고 안전하게 배포 및 롤백이 가능합니다. 물론 실제로는 생각보다 손이 많이 가는 관계로(특히 PaaS인 GAE에 비하면), 이를 한번에 해주는 스크립트를 작성해서 사용중입니다. 대략 간략하게는 다음과 같습니다. 실제 사용중인 스크립트에는 dry run 등의 잡다한 기능이 많이 들어가 있어서 걷어낸 pseudo code 입니다. 스크립트는 사내 PyPI 저장소를 통해 공유해서 사용 중입니다.def deploy(prefix, image_name, image_version): '''Deploy specified Docker image name and version into Auto Scaling Group''' asg_names = get_asg_names_from_tag(prefix, 'docker:image:name', image_name) groups = get_auto_scaling_groups(asg_names) # Find deployment target set future_set = set(map(lambda g: g['AutoScalingGroupName'].split('-')[-1], filter(lambda g: not g['DesiredCapacity'], groups))) if len(future_set) != 1: raise ValueError('Cannot specify target auto scaling group') future_set = next(iter(future_set)) if future_set == 'green': current_set = 'blue' elif future_set == 'blue': current_set = 'green' else: raise ValueError('Set name shoud be green or blue') # Deploy to future group future_groups = filter(lambda g: g['AutoScalingGroupName'].endswith(future_set), groups) for group in future_groups: asg_client.create_or_update_tags(Tags=[ { 'ResourceId': group['AutoScalingGroupName'], 'ResourceType': 'auto-scaling-group', 'PropagateAtLaunch': True, 'Key': 'docker:image:version', 'Value': image_version, } ]) # Set capacity, scaling policy, scheduled actions same as current group set_desired_capacity_from(current_set, group) move_scheduled_actions_from(current_set, group) move_scaling_policies(current_set, group) # Await ELB healthy of instances in group await_elb_healthy(future_groups) # Entering standby for current group for group in filter(lambda g: g['AutoScalingGroupName'].endswith(current_set), groups): asg_client.enter_standby( AutoScalingGroupName=group['AutoScalingGroupName'], InstanceIds=list(map(lambda i: i['InstanceId'], group['Instances'])), ShouldDecrementDesiredCapacity=True ) def rollback(prefix, image_name, image_version): '''Rollback standby Auto Scaling Group to service''' asg_names = get_asg_names_from_tag(prefix, 'docker:image:name', image_name) groups = get_auto_scaling_groups(asg_names) def filter_group_by_instance_state(groups, state): return filter( lambda g: len(filter(lambda i: i['LifecycleState'] == state, g['Instances'])) == g['DesiredCapacity'] and g['DesiredCapacity'], groups ) standby_groups = filter_group_by_instance_state(groups, 'Standby') inservice_groups = filter_group_by_instance_state(groups, 'InService') # Entering in-service for standby group for group in standby_groups: asg_client.exit_standby( AutoScalingGroupName=group['AutoScalingGroupName'], InstanceIds=list(map(lambda i: i['InstanceId'], group['Instances'])) ) # Await ELB healthy of instances in standby group await_elb_healthy(standby_groups) # Terminate instances to rollback for group in inservice_groups: asg_client.set_desired_capacity(AutoScalingGroupName=group['AutoScalingGroupName'], DesiredCapacity=0) current_set = group['AutoScalingGroupName'].split('-')[-1] move_scheduled_actions_from(current_set, group) move_scaling_policies(current_set, group) 몇 가지 더…Standby 로 돌리는 것 이외에 Detached 상태로 바꾸는 것도 방법입니다만, 인스턴스가 ASG에서 제거될 경우, 자신이 소속된 ASG를 알려주는 값인 aws:autoscaling:groupName 태그가 제거되므로 인스턴스나 ASG가 많아질 경우 번거롭습니다.cloud-init 를 어느 정도 최적화해두고 ELB healthcheck 를 좀 더 민감하게 설정하면, ELB 에 투입될 때까지 걸리는 시간을 상당히 줄일 수 있긴 하므로, 단일 ASG로 배포를 하더라도 롤백에 걸리는 시간을 줄일 수 있습니다. 저희는 scaleout 시작부터 ELB에서 healthy 로 찍힐 때까지 70초 가량 걸리는데, 그럼에도 불구하고 아래의 이유 때문에 현재의 방식으로 운영중입니다.같은 방식으로 단일 ASG로 배포를 할 수도 있지만, 배포중에 혹은 롤백 중에 scaleout이 돌면서 구버전 혹은 롤백 버전의 인스턴스가 투입되어버리면 매우 귀찮아집니다. 이를 방지하기 위해서라도 (Blue-green 방식의) ASG 두 개를 운영하는게 안전합니다.같은 이유로, 배포 대상의 버전을 S3나 github 등에 기록하는 대신 ASG의 태그에 버전을 써 두고 cloud-init 의 user-data에서 그 버전으로 어플리케이션을 띄우게 구성해 두었습니다. 이 경우 인스턴스의 태그만 확인해도 현재 어떤 버전이 서비스되고 있는지 확인할 수 있다는 장점도 있습니다.다만 ASG의 태그에 Tag on instance 를 체크해 두더라도, cloud-init 안에서 이를 조회하는 경우는 주의해야 합니다. ASG의 태그가 인스턴스로 복사되는 시점은 명확하지 않습니다. 스크립트 실행 중에 인스턴스에는 ASG의 태그가 있을 수도, 없을 수도 있습니다.굳이 인스턴스의 Lifecycle 을 Standby / InService 로 전환하지 않고도 ELB 를 두 개 운영하고 route 53 에서의 CNAME/ALIAS swap 도 방법이지만, DNS TTL은 아무리 짧아도 60초는 걸리고, JVM처럼 골치아픈 동작 사례도 있는만큼 선택하지 않았습니다.물론 이 방법이 최선은 절대 아니며(심지어 배포할때마다 돈이 들어갑니다!), 현재는 자원의 활용 등 다른 측면에서의 고민 때문에 새로운 구성을 고민하고 있습니다. 이건 언젠가 나중에 다시 공유하겠습니다. :)

우선 EOS BP 투료를 한 번쯤 해보신 분들은 매번 새롭게 등장하는 BP 후보들은 넘쳐나고 그들의 이름과 공약을 확인하는 것이 귀찮다고 느끼셨을 수 있습니다.또한 어렵게 공약을 확인하고 정말 이 팀이 EOS를 위해 무엇을 할 수 있는지 다른 팀들과 어떤점이 다른지 꼼꼼하게 비교하여 선거한 여러분의 소중한 투표권 파워는 시간이 지날수록 가치가 줄어들게 됩니다.그렇다면 나 대신에 꾸준히 선거를 대신해줄 사람이 있다면 얼마나 좋을까요?사실 이런 문제에 대해 EOS도 알고 있었으며, 어떤 해결 방법이 있을지 생각해왔습니다.그래서 바로 만들어진 것이 EOS Proxy Voting입니다.Proxy란 ‘대리인’이란 의미를 갖고 있습니다.따라서 EOS Proxy Voting은 EOS BP 대리 투표 시스템을 뜻합니다.이 대리인 투표권을 신청하게 되면 여러분은 더 이상 투표에 대해 고민하실 필요가 없게 되는 거예요!이제 이 Proxy 시스템을 어떻게 이용하는지 방법을 소개하고자 합니다.1. 어떻게 Cleos를 통해 다른 사람에게 나의 투표 권한을 넘길 수 있나요?나의 투표 권한을 Cleos를 통해 다른 사람에게 넘기기 위해선 다음과 같은 명령어를 입력해야합니다.간단하지요? 이 명령어는 eosaccount12가 자신의 투표 권한을 proxyvoter34에게 넘기겠다는 의미를 갖고 있습니다.2. 어떻게 툴킷을 통해 다른 사람에게 나의 권한을 넘길 수 있는 건가요?대표적으로 https://eostoolkit.io/vote/setproxy에서 Proxy를 설정하는 방법을 안내해드릴게요! (참고로 https://www.myeoskit.com/#/tools/proxy/https://eosvoter.eosphere.io 에서도 가능합니다. )나의 proxy를 툴킷을 통해 다른 사람에게 넘기기 위해선 먼저 Scatter 구글 확장 프로그램을 설치해야 합니다.Scatter 설치 후 EOS 계정 및 접속 정보를 Scatter에 등록하셔야 합니다. (Scatter에 정보를 등록하는 방법은 곧 업데이트 하도록 하겠습니다.)그렇다면 등록을 다 하셨을 테니 다음으로 넘어가겠습니다.우선 EOStoolkit에 접속하셔서 스캐터 계정으로 로그인하셔야 합니다.로그인 하셨다면 이제 왼쪽 카테고리에서 [Manage Voting] 항목을 보실 수 있을거에요![Manage Voting]를 클릭하시면 Voting에 관한 여러 항목이 촤르르 나오게 되는데 그 중에 [Set Proxy]를 눌러주세요!자 그럼 아래 화면에 나온 대로 그대로 따라하신 후 저장만 해주시면 됩니다.드디어 투표 권한을 지정 Proxy에게 넘기게 되었습니다.3. 어떻게 내가 설정한 Proxy를 해제할 수 있나요?Proxy 지정을 하고 며칠동안 투표에 신경을 쓰지 않았다가 오랜만에 들어간 투표 사이트에서 내가 지정한 대리인이 행사하는 나의 투표권이 마음에 들지 않을 땐 어떻게 해야할까요?해제를 해야겠지요!그렇다면 지금 내가 지정한 Proxy가 마음에 안들어서 해제하고 싶을 때는 어떻게 할지도 알아보겠습니다.Proxy 설정을 했다면, 저 네모박스에 체크되어 있을겁니다. 그 체크를 해지 하면 간단하게 내가 설정한 Proxy를 해제하게 되는 것입니다.아주 간단하네요.그럼 이제 다음은 내가 직접 Proxy가 되기 위해선 어떻게 할 수 있을지 알아보겠습니다.그 방법도 마찬가지로 Cleos 또는 Toolkit 과 Scatter를 통해 할 수 있습니다.4. Cleos를 통해서 내가 직접 Proxy가 될 수 있는 방법은 어떤게 있나요?내가 직접 Cleos를 통해 Proxy가 되기 위해선 다음과 같은 명령어를 입력해야합니다.이 명령어는 proxyvoter34는 Proxy로 지정되었는 의미를 갖고 있습니다.5. 어떻게 툴킷을 통해 내가 직접 Proxy가 될 수 있는 건가요?우선 툴킷을 통해 Proxy로 등록하기 위해선 가장 먼저https://eostoolkit.io/vote/setproxy 에 나의 Scatter 계정으로 로그인해야 합니다.(참고로 https://www.myeoskit.com/#/tools/proxy/https://eosvoter.eosphere.io 에서도 가능합니다. )로그인 하셨다면 왼쪽 카테고리에서 [Manage Voting]을 찾아주세요!찾으셨다면 해당 항목의 아래 항목에서 [Create Proxy] 를 클릭해주세요. 그럼다음과 같은 화면이 나오게 됩니다.아래 나와있는 설명 그대로 적어주시고 저장해주시면 됩니다. 다 완료하셨으면 드디어 Proxy가 되셨어요!6. 더이상 Proxy로 활동하고 싶지 않으면 어떻게 해야 하나요?더 이상 Proxy로서 활동을 하고 싶지 않다면 마찬가지로 [Manage Voting]를 통해 Proxy 철회를 할 수 있습니다.[Manage Voting]를 클릭 후 아래 항목에서 [Resign Proxy]을 누르시면 됩니다. 첫 번째 Resign 버튼은 Proxy 등록을 해지하는 것이고 두 번째 Unregister 버튼은 등록한 정보를 삭제하는 버튼입니다.각각의 버튼을 눌러 그대로 진행하시면 Proxy 철회가 완료될 거예요!자 여기까지 이제 EOS Proxy Voting을 하기 위해Proxy 설정하는 방법을 알아보았습니다. 어렵게 보이지만 Scatter 연동만 하면 Proxy를 설정하거나 내가 직접 Proxy가 되는 것은 어렵지 않습니다!아 참고로, 현재 등록된 모든 Proxy 리스트를 Aloha EOS Proxy Research Portal에서 확인할 수 있습니다.또한 해당 사이트에서 Proxy들이 자신들이 Proxy로 활동하면서 어떻게 투표를 행사할 것인지에 대한 공약도 자세히 나와있으니 한 번쯤 들어가서 보시면 Proxy를지정하는 데에 있어서도, 내가 직접 Proxy가 됨에 있어서도 도움이 될 거예요!#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심

이 포스팅에 실린 실습은 AWS CLI가 설치되어 있고, AWS credentials이 설정되어 있는 상태에서 진행했습니다. 서버와 하드웨어 사이의 TCP 연결을 구현하지 않고 AWS IoT를 이용해 MQTT 프로토콜로 데이터를 송수신하는 환경을 구성해보겠습니다. 진행을 위해 AWS IoT와 NodeJS가 필요합니다.1.AWS IoT Core로 접속해 사물을 생성합니다. 테스트로 1개만 사용할 것이므로 “단일 AWS IoT 사물”로 등록합니다.2.‘인증서 없이 사물 생성’을 클릭합니다. 인증서는 사물 등록 후에 생성할 예정입니다.3.사물이 정상적으로 등록되었는지 확인합니다.4.루트 CA 인증서를 생성합니다. 4-1.개인키를 생성하기 전, openssl 설정 파일을 추가해 아래 내용으로 저장합니다. 아래와 같이 진행하는 이유는 basicConstraints = true로 설정하기 위해서입니다.4-2.개인키를 생성합니다.openssl genrsa -out rootCA.key 2048 4-3.루트 인증서를 생성합니다.openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem -config rootCA_openssl.conf -extensions v3_ca 5.인증서를 생성합니다. 5-1.AWS IoT 등록 코드를 확인합니다.aws iot —region=ap-northeast-1 get-registration-code 5-2.개인키를 생성합니다.openssl genrsa -out verificationCert.key 2048 5-3.CSR을 생성합니다. 앞서 5-1에서 확인한 등록코드를 Common Name 항목에 입력합니다.openssl req -new -key verificationCert.key -out verificationCert.csr 5-4.인증서를 생성합니다.openssl x509 -req -in verificationCert.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out verificationCert.pem -days 500 -sha256 5-5.CA 인증서와 개인 인증서 파일들을 확인합니다.5-6.AWS에 인증서를 등록합니다.aws iot register-ca-certificate —ca-certificate file://rootCA.pem —verification-cert file://verificationCert.pem —region=ap-northeast-2 5-7.AWS에 인증서를 활성화합니다.aws iot update-ca-certificate --certificate-id 인증서 등록 후 응답으로 오는 certificateId 값 --new-status ACTIVE --region=ap-northeast-2 예)aws iot update-ca-certificate —certificate-id AAAAAABDADFDF1ABADFDFDFDF### —new-status ACTIVE —region=ap-northeast-2 5-8.AWS에 인증서 자동 등록 활성화를 켭니다.6.AWS 콘솔에 접속해 CA 인증서 등록을 확인합니다.7.AWS 콘솔에서 인증서를 생성합니다.7-1.원클릭 인증서 생성을 클릭합니다.7-2.활성화를 클릭하면 완료됩니다.8.인증서와 사물을 연결합니다.9.상호 작용 탭에서 디바이스를 연결합니다.10.환경에 맞게 선택하여 다운로드합니다.11.압축을 해제해 srart.sh를 실행하고, 연결 대기합니다.12.AWS IoT 테스트 접속 후, topic 1으로 메시지를 게시합니다.13.터미널을 확인합니다.이것으로 AWS IoT 로컬 환경이 구성되었습니다. AWS IoT를 사용하면 서버와 하드웨어를 제어하는 클라이언트 간 통신을 쉽게 하도록 다양한 구성을 할 수 있습니다. 모든 포맷은 JSON 포맷으로 송수신하며, MQTT(Message Queueing Telemetry Transport) 방식이라 양방향 통신을 쉽게 처리하고 전송할 수 있을 겁니다.참고자세한 MQTT - Publish/Subscribe 모델은 여기를 클릭하세요.글장현준 팀장 | R&D 개발3팀[email protected]브랜디, 오직 예쁜 옷만

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 N잡러 엄단희 님을 만나보세요:)사진1. 스켈터랩스의 N잡러 엄단희 님Q. 자기소개를 부탁한다.A. 스켈터랩스에 입사한 지 이제 8개월 정도 된 신입 소프트웨어 엔지니어, 엄단희다.Q. 스켈터랩스에서 어떤 업무를 맡고 있는가.A. 현재는 아이리스(Iris) 팀에 소속되어있다. 아이리스 팀은 맥락 인식(Context Recognition) 기술을 기반으로 SDK를 비롯한 여러가지 서비스 출시를 준비하고 있는데, 사실 지금은 레고(L.ego)팀이 준비하는 신제품인 스마트 미러 샘(Samm) 개발 업무가 주요 업무이다. 샘은 스켈터랩스가 가지고 있는 맥락 인식 기술 뿐만 아니라 음성, 얼굴, 제스처 인식을 비롯한 대화형 엔진이 모두 집약된 인텔리전트 디바이스(Intelligent Device)다. 여러 기능이 하나의 디바이스에 구현된 만큼, 샘은 다양한 모듈로 나누어져있다. 예를 들어 센서 정보를 모으는 모듈과 그 정보를 처리하는 모듈, 처리한 내용을 보여주는 UI 모듈 등이 있는데, 나는 이러한 모듈들을 gRPC 또는 bluetooth 등을 통해 서로 통신할 수 있도록 해주는 작업을 주로 진행했다. 최근에는 샘의 구매자에게 필요한 샘 어플리케이션 개발을 진행하고 있다. 아이리스 팀 관련해서는 파이어베이스(Firebase) 관련 작업을 서포트한 적이 있고, 얼마 전에는 스켈터랩스 웹사이트 개발에 참여하기도 했다.Q. 맡고 있는 업무의 가짓수가 많아 보인다. 한번에 여러 개의 프로젝트를 진행하는 것이 어렵진 않나.A. 쉽다고 말하기는 힘든 것 같다. 여러 업무에서 동일한 지식이 요구될 때도 있지만, 기본적으로 하나의 일을 처리하기 위해 집중하고 있다가 다른 업무로 전환할 때, 그 업무를 위한 나의 베이스를  바꾸는 등의 일들이 녹록치 않다. 처음에는 무엇보다 일의 우선순위를 정하는 것이 가장 버거웠다. 사실 업무마다의 기한이 정해져 있으면 당연히 급한 업무를 먼저 처리할텐데, 우리 회사는 그보다는 본인이 직접 업무량을 조정해서 기한을 정하고 처리하는 편이다. 그래서 하나의 일을 쪼개고 쪼개어, 그 중에서도 가장 빨리할 수 있는 일부터 먼저 처리하는 나만의 업무 프로세스를 만들고 있다. ‘빨리 할 수 있는 일'이라고 해서 마냥 쉬운 일을 말하지는 않는다. 그 때마다 내게 가장 맞는 일, 내가 가장 준비되어 있는 일을 자연스럽게 추려내어 업무 효율을 높이려고 한다.Q. 스켈터랩스에 어떻게 입사하게 되었는지 궁금하다.A. 재작년, 앤드비욘드라는 회사에서 인턴으로 근무했다. 당시 스켈터랩스가 앤드비욘드와 함께 개발중이던 스마트 포스(POS)기, GABE 프로젝트를 진행하며 한남동에서 같은 사무실을 쓰고 있었다. 그 프로젝트 팀에서 파견직처럼 일을 하게 되었는데, 가장 놀란 점은 ‘사람'이었다. 이렇게 누구 하나 빠짐 없이 개발을 잘하는 사람들이 모여있는 곳에서 개발하는 것은 처음이었다. 학교에서는 나름 ‘나도 잘하는 편이지 않을까’ 생각했는데 여기 와서 한없이 부족하다는 걸 깨달았다. 그런데 그렇게 부족한 신입 인턴임에도 불구하고 모두가 나를 평등하게 대해주셨고 개발 관련해서도 많이 배울 수 있었다. 덕분에 스켈터랩스는 내게 아주 좋은 이미지로 남아있었는데, 작년 스켈터랩스의 CTO인 조성진님께 오퍼를 받아서 스켈터랩스 인턴으로 일과 학업을 병행하다가 올해 정직원으로 입사하였다.Q. 인턴으로 일을 하며 학업과 병행했는지 몰랐다. A. 학교 스케줄을 우선시할 수 있도록 회사가 많이 배려해주었다. 다행히 학교가 회사와 멀지 않은 거리에 위치하기도 한다. 그래서 학교 수업은 주 2-3일 정도, 오전 타임으로 몰아서 구성했다. 시험기간이라고 하면 팀원들이 모두 나서서 ‘어서 집에 가서 공부부터 해라'라며 조언해주시고 업무적으로도 많이 도와주신 덕에 학업에 대한 지장 없이 일을 할 수 있었다.Q. 인턴을 마치고 정직원으로 입사했다면, 인턴 시절과 현재를 비교할 때 업무적으로 무엇이 가장 다른가.A. 우리 회사는 매 분기마다 분기의 목표 설정과 유사한 OKR(Objectives and Key Results)을 정하고, 이를 완료하는 방식으로 일을 진행한다. OKR에서 중요도가 높은 업무는 P0로, 가장 중요도가 낮은 업무는 P2로 표기한다. 인턴으로 처음 입사했을 때는 P1~P2 레벨의 자잘한 이슈들을 처리하는 업무가 많았다. 정직원이 되고 나니, 그만큼의 지식과 스킬이 쌓인 만큼 P0의 업무들을 조금 더 맡게되었다. 그러나 전반적인 업무의 결은 유사하다. 다만 확실히 책임감은 늘어났다고 생각한다. 인턴일 때는 ‘난 인턴이니까 몰라도 괜찮겠지?’와 같은 마인드가 있었는데, 정직원이 된 지금은 ‘정직원이 이 정도는 알고 있어야겠지?'라고 생각한다. 덕분에 공부하는 양도 이전보다는 늘어났다.사진2. 파워 코딩 중인 단희 님Q. 최근 스켈터랩스가 여러 학교의 커리어페어에 다녀오면서 많이 들었던 질문 중 하나가 ‘인공지능을 전문적으로 공부하지 않았는데, 일을 할 수 있을까요?’였다. 혹시 이 질문에 대한 답변을 해줄 수 있을까.A. 나도 입사 때 면접을 보며 같은 질문을 던졌다. 입사해서 느끼는 점은 정말 인공지능에 관련된 개발 외에 다른 영역에서도 개발해야 하는 일이 정말 많다는 점이다. 때문에 인공지능 분야를 잘 모른다고 해서 (물론 알면 좋지만) 막연한 두려움은 갖지 않아도 좋다. 물론 좀 더 코어한 부분을 개발할수록 인공지능 공부의 필요성을 점점 느끼게 된다. 이러한 기술적 갈증은 사내에서 열리는 테크톡(Tech Talk)과 같은 세미나를 통해 어느 정도 해결할 수 있으며, 업무를 위해 관련 공부가 필수적이라면 팀별로 스터디가 진행되기도 한다. 실제로 다른 팀에서는 주기적으로 관련 논문을 스터디하고 그 지식을 공유하는 세션이 진행되고 있다.Q. 스켈터랩스 입사 후 가장 뿌듯했던 순간과 힘든 순간을 꼽는다면?A. 나는 내가 무언가를 직접 만들고, 그 결과물을 선보이는 과정을 좋아한다. 그래서 가장 뿌듯한 순간으로는 회사 웹사이트를 런칭했을 때를 꼽고 싶다. ‘웹' 특성 상 내가 짠 코드들의 결과를 바로 눈으로 확인할 수 있기 때문에 개발하는 재미도 있었고, 아무래도 회사를 대표하는 사이트라 많은 사람들에게 보여질 것이라 생각하니 더욱 자부심을 갖고 일할 수 있었던 것 같다. 그런 측면에서 나중에 샘을 런칭하게 될 날도 기대된다. 반면 가장 힘들었던 순간은 작년 블루투스 개발 관련 디자인 문서 작업을 진행할 때 였다. 일단 블루투스 기술도 잘 모르는 데다가 디자인 문서 자체도 제대로 써본 적이 없어 생소했다. 사실, 개발이 안 풀리고 막혀있을 때는 그 순간만 힘들 뿐 어떻게든 해결책을 찾고 결과물을 낼 수 있었다. 그런데 디자인 문서 작업은 내가 어떤 방향성을 취해야 하는지, 지금 하고 있는 과정이 맞는 것인지가 계속 의구심이 들었다. 하루종일 컴퓨터 앞에 앉아 있어도 결과물이 없으니 마음만 조급해지는 일도 많았다. 다행히 당시 리뷰를 해주신 조성진님 등 기타 다른 개발자분들의 도움으로 문서는 마무리지을 수 있었는데, 내 한계에 대해 반성하기도, 많이 배우기도 했다.Q. 스켈터랩스 게임동호회 회장을 맡은 것으로 알고있다. 게임동호회를 소개하자면?A. 먼저 오류부터 수정해야할 것 같다. 나는 현재 게임동호회 회장은 아니다. 사내 게임동호회인 ‘Game of Troll’은 한달에 한 두번 모여서 게임을 함께 하는데, 그 게임에서 꼴찌를 한 사람이 회장이 된다. 나의 경우 저번 달 클래시로얄 게임에서 꼴찌를 하여 회장을 맡았었다. 하지만 회장이 정한 게임으로 다음 회장을 뽑기 때문에 내가 자신있는 게임인 오버워치를 9월 게임으로 선정했고, 현재는 정태형 님에게 회장 자리를 넘겨주었다. 게임은 종류에 따라 사내 블루룸 또는 PC방에서 진행한다. 블루룸에는 플스와 닌텐도 등의 각종 게임기가 완비되어 있어, 토너먼트 식으로 철권을 하거나 마리오카트를 했었다. 또 휴대폰으로는 클래시 로얄을 함께 플레이하기도 한다. PC게임인 경우에는 저녁에 함께 피씨방에 가는데, 재미있는 점은 원래 저녁을 먹고 피씨방에 가다가, 피씨방에 가서 저녁을 먹는 걸로 바뀌었다는 점이다. 저녁먹는 시간이 아까워서다. 이렇게 피씨방에서 플레이한 게임들은 스타1, 스타2, 카운터 스트라이크 온라인2, 오버워치, 히어로즈 오브 스톰 등이 있다.처음 게임 동호회에 들어올 때만 해도 ‘같은 회사 사람끼리 게임을 하는 것이 과연 재미있을까'란 생각을 했다. 그런데 막상 게임을 같이 해보니, 회사에서 일할 때는 보이지 않았던 그 사람의 의외의 면을 발견하는 재미도 있는 것 같다. 개인적으로는 초등학교 때부터 게임을 워낙 많이 했던 탓에 스스로 ‘내 인생을 게임에 너무 낭비한 것이 아닐까'란 자괴감을 느낀적도 있는데, 다른 훌륭한 개발자의 게임 덕후스러운 면모를 보면서 ‘나만 이렇게 게임에 빠진 것은 아니었구나'하는 위안도 받을 수 있었다.사진3. 스켈터랩스의 게임동호회 Game of Troll의 뒷풀이 모습Q. 와우, 플레이하는 게임이 정말 많다. 단희님이 가장 좋아하는 게임을 그 중 꼽는다면?A. 나는 단연 오버워치다. FPS게임을 선호하는 편인데 그 중에서도 오버워치를 주로 플레이한다. 개인적으로 스토리가 재미있기도 하고, 팀플레이를 진행하며 합을 맞춰가는 맛이 있다. 무엇보다 사람끼리 대결하는 PVP로 진행을 하면 정말 짜릿함이나 즐거움이 배가 되는 것 같다. 물론 협동 게임인 만큼 팀플레이가 제대로 되지 않는다거나 비매너 유저들과 붙을 때는 기분이 아주 다운되는 경우도 있지만 말이다. 그럴 때는 ‘GTA5’ 또는 최근에 시작한 ‘데스티니 가디언즈'에서 PVE를 하며 마음을 진정시킨다. 물론 이것만 하면 지루하겠지만 오버워치와 적절히 번갈아가면서 하다보면 고유의 재미가 느껴진다.Q. SNS에 웹툰도 연재하고 있는 것으로 알고있다. 어떻게 웹툰 연재를 시작하게 되었는지.A. 어렸을 때부터 만화 그리는 것을 좋아했다. 내가 상상하는 이야기들을 만화로 풀어내는 것도, 그 날 있었던 일을 재미있게 연출해서 일기 대신 그림으로 하루의 기록을 남기는 것도 좋아했다. 그렇게 학교에서 있었던 재미있는 에피소드를 글과 그림으로 남기다 보니, 이걸 모두에게 공개하면 재미있지 않을까란 생각을 했다. 때마침 한창 페이스북 페이지가 유행이었는데, 그때부터 노트에 끄적거린 짧은 만화들을 올리기 시작하면서 현재의 인스타그램 웹툰까지 오게되었다.   사진3. 단희 님이 연재 중인 <초코롤의 코딩일기>, 인스타그램과 페이스북에서 만나볼 수 있다Q. 웹툰 소개를 부탁한다.A. 인스타그램에선 @sw_chocoroll, 페이스북에서는 <초코롤의 코딩일기>라는 제목으로 게재하고 있다. 취미생활 겸 하다 보니 정기연재는 아니다. 제목에서 드러나 듯 주로 코딩(개발) 이야기를 다루고 있는 생활툰이다. 생활툰의 특성상 어쩔 수 없이 주변인들에 대한 묘사가 많고, 에피소드가 없을 때면 웹툰을 그리기도 쉽지 않다. 약간 과장하더라도 실제 있었던 일들을 중심으로 작업하기 때문에, 업로드 전 꼭 등장 인물들에게 검수를 거치기도 한다. 웹툰 그리는 것이 생각보다 집중도를 요하는 작업인지라 보통 주말에 진행하는데, 그래서 평일에는 에피소드를 꼼꼼히 기록해두는 습관이 생겼다. 무엇보다 웹툰을 그리며 가장 많이 느꼈던 점은 내 인생에 대해서 조금 더 알게됐달까, ‘나’를 다시 보게 된 느낌이 있다. 내가 기록한 에피소드가 대부분 게임과 개발에 편중되어 있는 점을 보면서, 인생에서 많은 지분을 ‘게임', ‘개발' 이 두 가지에 할애하고 있다는 것을 새삼 알게되었다.  Q. 재능 부자, N잡러로 보인다. 게임에도 웹툰에도 이렇게 관심이 많았는데 어떻게 개발자의 진로를 선택하게 되었나.A. 이유는 생각보다 단순하다. 위에 웹툰에서도 그렸듯이 영화를 보면 꼭 대형 모니터를 여러 개 띄워놓고 멋지게 주인공을 돕는 해커들이 등장하지 않나. 게임을 많이 하게 되면서 자연스럽게 컴퓨터에 친숙해지기도 했고, 영화를 보면서 ‘나도 컴퓨터 관련 전공을 택하면 저렇게 멋있는 사람이 될 수 있지 않을까’라고 생각했던 것 같다. 다만 어떤 분야의 개발자가 될 것인가에 대한 고민은 많았다. 영화처럼 정보보안 쪽도 잠깐 발을 담갔지만 지금 당장 할 수 있는 분야는 아니라는 생각을 했고, 그 다음은 게임 개발자에 관심을 가졌다. 그런데 당장 게임 회사에 들어간다고 해도 꼭 내가 만들고 싶은 게임만 만들 수는 없다는 것을 알게 되서 보류했다. 나는 일단 스토리가 탄탄하고 재미있는 게임을 정말 사랑한다. 예를 들어 <화이트데이>라는 공포 게임을 정말 재밌게 플레이했었는데, 공포 요소도 한국 정서에 맞게 잘 구현되었으면서 미연시(미소녀 연애 시뮬레이션) 요소도 가미되어 신선한 느낌을 주었었다. 제일 중요한 스토리도 배경 시나리오부터 인게임 진행까지 반전에 반전을 거듭하며 게임이 끝나고도 생각해볼 여지가 많았다. 이런 게임을 만들고 싶지만 우선 희망 사항으로 남겨둔 상태이다. 그러다 우연히 입사한 스켈터랩스에서 훌륭한 선배 개발자들을 보며 ‘개발' 자체의 즐거움을 느꼈고 당장은 어떤 특정 분야에 국한하지 않고 순수한 개발 능력을 향상시키기 위해 노력하고 있다. 스켈터랩스에서 중요하게 다루는 인공지능은 특히 기술적으로 미래의 변화를 주도하고 있기에, 여러 방면에서 매우 배울 점도 많고 발전할 수 있는 것 같다.Q. 최근 몰두하고 있는 것이 있다면?A. 여전히 웹툰과 게임이다. 웹툰을 그릴 수록 기초적인 그림 실력이 부족하다는 것을 많이 느꼈다. 전문적으로 그림을 배워볼까 싶다. 그리고 유튜브에 게임 채널을 열어보려고 한다. 내가 관심있었던 모든 일은 기본적으로 ‘창작'과 ‘기록'의 맥락을 가지고 있다. 개발 또한 어떻게 보면 내가 짜는 코드를 통해 하나의 프로그램을 만들어 내는 역할이지 않나. 웹툰도 내 일상에 대한 기록이다. 나의 일상에서 가장 큰 관심사 중 하나인 게임을 기록하는 방법에 대해 고민했는데, 역시 동영상이 최고라는 결론에 도달했다. 유튜브에는 게임 영상을 편집하여 조금씩 선보이고 있다.Q. 진부할 수 있지만, 이 인터뷰의 마지막 질문이다. 개인적인 꿈을 얘기해줄 수 있나.A. 언젠가는 접어두었던 게임 개발자의 꿈을 꾸려고 한다. 1인 개발자로서 스토리와 작화, 개발을 모두 맡은 개발자 말이다. 그러기 위해서는 그림 뿐만 아니라, 유저의 마음을 사로잡을 수 있는 스토리와 촘촘한 개발력 또한 갖추어야 한다. 개발력은 일단 스켈터랩스에서 빵빵하게 키워놓고, 스토리와 작화에 관련된 역량을 조금씩 갖추어간다면 1인 개발자로서 내 이름을 건 게임을 출시할 날이 조만간 올 수 있지 않을까.#스켈터랩스 #사무실풍경 #업무환경 #사내복지 #기업문화 #팀원인터뷰 #팀원소개 #팀원자랑

함수와 이벤트에 대한 내용이 이렇게 간략할지 몰라 따로 파트를 나누어 포스팅을 진행하였는데 불필요한 나눔이 되었네요. 하지만 곧 더 간략하고 직관적으로 볼 수 있도록 기초 문법 총 정리 포스팅을 하도록 하겠습니다. 혹여 참고 문서로 본 포스팅을 보시는 분들은 곧 올라오는 총정리 포스팅을 참고하시면 좋을 것 같습니다.함수function 함수명() {    실행문;    return 데이터;}참조 변수 = function() {    실행문;}function 함수명() {(매개 변수1, 매개 변수2)    실행문;}   이벤트<button id="btn" onclikc="alert('event!')">버튼></button>이벤트 종류onmouseover - 마우스가 지정한 요소에 올라갔을 때 발생.onmouseout - 마우스가 지정한 요소에 벗어났을 때 발생.onmousemove - 마우스가 지정한 요소를 클릭했을 때 발생.ondvlclick - 마우스가 지정한 요소를 연속 두 번 클릭했을 때 발생.onkeypress - 지정한 요소에서 키보드가 눌렸을 때 발생.onkeydown - 지정한 요소에서 키보드를 눌렀을 때 발생.onkeyup - 지정한 요소에서 키보드를 눌렀다 떼었을 때 발생.onfocus - 지정한 요소에 포커스가 갔을 때 발생.onblur - 지정한 요소에 포커스가 다른 요소로 이동되어 잃었을 때 발생.onchange - 지정한 요소의 하위 요소를 모두 로딩했을 때 발생.onunload - 문서를 닫거나 다른 문서로 이동했을 때 발생.onsubmit - 폼 요소에 전송 버튼을 눌렀을 때 발생.onreset - 폼 요소에 취소 버튼을 눌렀을 때 발생.onresize - 지정된 요소의 크기가 변경되었을 때 발생.onerror - 문서 객체가 로드되는 동안 문제가 발생되었을 때 발생.참고문헌:Do it! 자바스크립트+제이쿼리 입문 - 정인용JavaScript 튜토리얼 문서 (http://www.w3schools.com/js/default.asp)티스토리 블로그와 동시에 포스팅을 진행하고 있습니다.http://madeitwantit.tistory.com#트레바리 #개발자 #안드로이드 #앱개발 #Node.js #백엔드 #인사이트 #경험공유

Overview반복적인 테스트에 지쳐가고 있던 무렵, TDD방법론을 접하게 되었습니다. TDD(Test Driven Development)는 테스트 주도적인 개발로 소스코드 작업 전에 테스트 코드를 먼저 작성해 소스수정에 대한 부담을 덜고 디버깅 시간을 줄일 수 있습니다. TDD 장점소스코드의 품질이 높다.재설계 및 디버깅 시간이 절감된다.TDD 단점단기적 코드일 경우 생산성이 떨어진다.실제 코드보다 테스트 케이스가 더 커질 수 있다.파이썬에서 TDD가 필요한 이유1) 파이썬에는 정적 타입 검사 기능이 없다. (Python 3.6 에서는 정적 타입 선언 가능)2) 동적언어이기 때문에 TDD를 하기에 적합하다.3) 파이썬은 간결성과 단순함으로 생산성이 높은 반면 런타임 오류가 발생할 수도 있다.4) 파이썬을 신뢰할 수 있는 유일한 방법은 테스트를 하는 것이다.파이썬 테스트 모듈 unittest이번 글에서는 unittest를 사용해 단위 테스트를 해보겠습니다. unittest는 이미 내장되어 있어 따로 설치하지 않아도 되는 표준 라이브러리입니다. 사용방법1) import unittest 2) unittest.TestCase 상속받는 하위 클래스 생성3) TestCase.assert 메소드를 사용하여 테스트 코드를 간략화4) unittest.main() 실행그럼 간단한 예제로 단위 테스트를 해보겠습니다.1.사칙연산 함수를 추가합니다.def add(a, b):     return a + b   def substract(a, b):     return a - b   def division(a, b):     return a / b   def multiply(a, b):     return a * b 2. unittest.TestCase 상속받아 테스트 클래스를 생성합니다. 아래는 각각의 함수 결과값을 비교해 텍스트를 출력하는 코드입니다.import unittest class TddTest(unittest.TestCase): def testAdd(self):         result = lib_calc.add(10, 20)         if result == 30:             print('testAdd OK')      def testSubstract(self):         result = lib_calc.substract(20, 30)          if result > 0:             boolval = True         else:             boolval = False if boolval == False:             print('testSubstract Error')      def testDivision(self):         try:             lib_calc.division(4, 0)         except Exception as e:             print(e)      def testMultiply(self):         result = lib_calc.multiply(10, 9)          if result < 100>             print('testMultiply Error') if __name__ == '__main__':     unittest.main() 3.결과: 해당 조건에 만족해 작성한 텍스트가 출력됩니다.이번에는 unittest에서 지원하는 TestCase.assert 메소드를 사용해 간략하게 소스를 수정해보겠습니다.TestCase.assert 메소드1) assertEqual(A, B, Msg) - A, B가 같은지 테스트2) assertNotEqual(A, B, Msg) - A, B가 다른지 테스트3) assertTrue(A, Msg) - A가 True인지 테스트4) assertFalse(A, Msg) - A가 False인지 테스트5) assertIs(A, B, Msg) - A, B가 동일한 객체인지 테스트6) assertIsNot(A, B, Msg) - A, B가 동일하지 않는 객체인지 테스트7) assertIsNone(A, Msg) - A가 None인지 테스트8) assertIsNotNone(A, Msg) - A가 Not None인지 테스트9) assertRaises(ZeroDivisionError, myCalc.add, 4, 0) - 특정 에러 확인1. TestCase.assert 메소드 사용TestCase.assert 메소드를 사용하여 에러를 발생시켜 보겠습니다.import unittest class TddTest(unittest.TestCase): def testAdd(self):         result = lib_calc.add(10, 20)          # 결과 값이 일치 여부 확인         self.assertEqual(result, 31)      def testSubstract(self):         result = lib_calc.substract(20, 10)          if result > 10:             boolval = True         else:             boolval = False # 결과 값이 True 여부 확인         self.assertTrue(boolval)      def testDivision(self):         # 결과 값이 ZeroDivisionError 예외 발생 여부 확인         self.assertRaises(ZeroDivisionError, lib_calc.division, 4, 1)      def testMultiply(self):         nonechk = True result = lib_calc.multiply(10, 9)          if result > 100:             nonechk = None # 결과 값이 None 여부 확인         self.assertIsNone(nonechk) if __name__ == '__main__':     unittest.main() 2. 결과1) 테스트가 실패해도 다른 테스트에 영향을 미치지 않음2) 실패한 위치와 이유를 알 수 있음다음으로 setUp(), tearDown() 메소드를 사용하여 반복적인 테스트 메소드 실행 전, 실행 후의 동작을 처리해보겠습니다.TestCase 메소드1) setUp() - TestCase클래스의 매 테스트 메소드가 실행 전 동작2) tearDown() - 매 테스트 메소드가 실행 후 동작 1. setUp(), tearDown() 메소드 사용- setUp() 메소드로 전역 변수에 값을 지정- tearDown() 메소드로 “ 결과 값 : ” 텍스트 출력import unittest class TddTest(unittest.TestCase): aa = 0     bb = 0     result = 0 # 매 테스트 메소드 실행 전 동작     def setUp(self):        self.aa = 10        self.bb = 20 def testAdd(self):         self.result = lib_calc.add(self.aa, self.bb)          # 결과 값이 일치 여부 확인         self.assertEqual(self.result, 31)      def testSubstract(self):         self.result = lib_calc.substract(self.aa, self.bb)          if self.result > 10:             boolval = True         else:             boolval = False # 결과 값이 True 여부 확인         self.assertTrue(boolval)      def testDivision(self):         # 결과 값이 ZeroDivisionError 예외 발생 여부 확인         self.assertRaises(ZeroDivisionError, lib_calc.division, 4, 1)      def testMultiply(self):         nonechk = True self.result = lib_calc.multiply(10, 9)          if self.result > 100:             nonechk = None # 결과 값이 None 여부 확인         self.assertIsNone(nonechk)      # 매 테스트 메소드 실행 후 동작     def tearDown(self):         print(' 결과 값 : ' + str(self.result))   if __name__ == '__main__':     unittest.main() 2. 결과- setUp() 메소드로 지정한 값으로 테스트를 수행 - tearDown() 메소드로 각각의 테스트 메소드 마다 “ 결과 값 : ” 텍스트 출력실행 명령어 여러 옵션을 사용하여 실행 결과를 출력해보겠습니다.실행 명령어python -m unittest discover [option]1. -v : 상세 결과 2. -f : 첫 번째 실패 또는 오류시 중단3. -s : 시작할 디렉토리4. -p : 테스트 파일과 일치하는 패턴5. -t : 프로젝트의 최상위 디렉토리1. 상세 결과테스트 메소드명 및 해당 클래스명 출력 2. 첫 번째 실패 또는 오류시 중단첫 번째 테스트에서 오류 발생하여 중단3. 여러 옵션 실행현재경로 디렉토리 안에 tdd_test*.py 패턴에 속하는 모든 파일의 상세 결과Conclusion지금까지 파이썬에서 unittest 모듈을 이용한 테스트 코드를 작성했습니다. 처음에는 귀찮고 번거롭지만 테스트 코드를 먼저 작성하는 습관을 길러보세요. 분명 높은 품질의 소스코드를 만들 수 있을 겁니다!참고Python 테스트 시작하기파이썬 TDD 101글곽정섭 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #파이썬 #Python

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 조깨비 조경희 님을 만나보세요:)사진1. 스켈터랩스의 조깨비 조경희 님Q. 자기소개를 부탁한다.A. 이름은 조경희, 아이리스 팀에서 소프트웨어 엔지니어로 일하고 있다. 2016년 8월에 입사했으니 이제 스켈터랩스에 합류한 지도 2년이 훌쩍 넘었다.Q. 맡고있는 업무를 설명한다면?A. 우리 팀은 일종의 실시간 맥락 인식(Context Recognition) 기술을 개발하고 있다. 다양한 종류의 맥락 인식이 있겠지만, 현재 우리는 모바일 기기를 주요 디바이스로 삼고있다. 핸드폰을 통해 사용자의 다양한 정보를 수집하고, 우리의 기술이 알아서 사용자의 취향이라던지 성향, 좋아하는 음식부터 음악까지 다양한 정보를 여러 시그널을 바탕으로 추론하고자 한다. 이후에는 사용자에 딱 맞는 ‘추천'까지 제공하는 기술을 개발하는 것이 목표다.Q. 핸드폰 하나로 사용자의 다양한 정보를 수집하고 추론할 수 있다는 부분이 신기하다. 조금 더 자세히 얘기해줄 수 있나.A. 가령 내가 안드로이드 사용자라고 가정해보자. 우리가 택시를 부를 때 흔히 사용하는 것 처럼 내가 현재 위치한 곳을, 즉 장소 정보를 핸드폰은 알아서 수집하고 있다. 우리는 장소를 비롯하여 와이파이나 사운드, 배터리, 자이로센서 등으로부터 시그널을 수집하고, 스트리밍 프로세싱 엔진에 송출한다. 그럼 그 엔진에서 실시간으로 이러한 스트림(정보)를 받고, 받은 데이터를 조합하여 새로운 데이터로 변환한 후 다음 단계를 추론하다. 내가 만일 아침 9시쯤에는 항상 일정한 A라는 장소로 이동하고 있고, A 장소로 이동하는 길목에서 카페에 들러 커피를 한 잔 사는 일과를 가지고 있다면, ‘A는 사용자의 회사이고, 사용자는 출근하기 전 커피를 마시기를 즐기는 사람이다'라고 추론할 수 있다. 우리는 이러한 상황에 대한 추론을 바탕으로, 조금 더 고차원적인 추론을 하거나, 사용자의 취향 및 패턴을 찾는 기술을 개발하고 있다. 궁극적으로는 <아이언맨>에 등장하는 자비스(JARVIS)와 같은 퍼스널 어시스턴트(Personal Assistant)를 세상에 내보이고 싶다. 사실 자비스는 어디까지나 영화 속의 상상이 많이 묻어있고, 현재로서는 갈 길이 멀기도 하다. 하지만 현재 스켈터랩스는 음성 인식이나 이미지(Vision), 챗봇과 같은 다양한 프로젝트를 동시에 진행하고 있으며 각각의 기술력도 뛰어나다. 이 여러가지 기술이 총체적으로 구현된 서비스가 탄생한다면, 일상을 혁신적으로 바꿀 것이라고 생각한다. Q. 지금까지의 개발 상황을 살짝 공개하자면?A. 시장에 공개한 것을 기준으로 하자면, 일단 베타 버전으로 런칭한 앱 서비스 ‘큐(CUE)’ 이야기를 하고 싶다. 간단한 상황 인식을 통해 사용자에게 추천을 제공한다. 가령 강수량이 높게 예고된 날에는 ‘우산 챙겨가'라고 카드를 띄워준다거나, 라면을 즐겨 먹는 사용자에게 ‘오늘은 라면 대신 건강한 샐러드 어때?’라고 말해주기도 한다. 사실 큐에 대한 사용자의 의견은 정말 가지각색이었다. 날씨 예보를 기반으로 한 추천의 경우 ‘너무 뻔해서 의미가 없는 것 같다’ 라고 생각하는 사용자가 있는 반면, 출근 직전과 같은 적시에 카드가 알아서 추천해주니 매우 편하게 느꼈다는 사용자도 있었다. 결국 나는 상황 인식이 사용자에게 유용한 서비스로 와닿기 위해서는 ‘정확성'이 큰 척도라고 생각한다. 적시에, 적절한 장소에서, 나에게 꼭 맞는 추천을 해주는 것, 이를 위해서는 사용자를 정확하게 파악하는 것이 우선되어야 하기 때문이다. 지금까지의 개발이 상황 정보를 적절하게 받을 수 있는 플랫폼 구축 중심이었다면, 현재는 더 자세한 상황을 찾는 쪽으로 초점이 맞추어져 있다. 가령 사용자가 ‘지하철을 타고 이동한다'가 아니라, ‘어느 역에서 지하철에 탑승하여 어느 역에서 내렸다'까지 인식할 수 있는 것이다. 음악도 마찬가지다. 음악과 같이 엔터테인먼트 컨텐츠의 경우 단순히 ‘음악을 듣고 있다'라는 정보가 아니라, 취향 정보가 중요하다. 때문에 ‘어떤 가수의 어떤 음악을 들었다'까지 인식하여 이를 조합한 추론을 만들려고 한다.사진2. 사내 Tech Talk 세미나를 진행하고 있는 경희님Q. 큐의 베타 서비스를 런칭하며 팀원들끼리 자축하던 장면이 떠오른다. 굉장히 뿌듯한 경험이었을 것 같다.A. 나는 사실 뿌듯함 보다는 ‘갈 길이 멀다'라는 생각을 먼저 했다. 베타 버전이기도 했고, 개발한 우리 스스로도 정확성이 기대에 미치지 못하고 있다고 생각했다. 그럼에도 불구하고 런칭을 결정한 이유는 명확하다. 다양한 사용자가 큐를 통해 어떤 경험을 얻고, 어떻게 느끼는지 들어야만 더욱 사용자의 핏에 맞는 정식 버전을 제대로 개발할 수 있을 것이라고 판단했기 때문이다. 모든 서비스가 마찬가지겠지만 나는 큐야 말로 많은 사용자와 함께 만들어가는 서비스라고 생각한다.Q. 경희님 개인의 이야기를 들어보고 싶다. 스켈터랩스에 어떻게 합류하게 되었는가.A. 스켈터랩스의 CTO인 조성진 님과 같은 연구실에서 일했다. 연구를 마친 후 나는 전문연구요원으로 다른 회사에서 일을 했고, 성진님은 구글에 입사한 것으로만 알고 있었는데, 구글을 나와서 회사를 차렸다는 얘기를 듣게되었다. 그때만 해도 대기업이 주는 안정감을 놓칠 수 없어 대기업에 머물러있었다. 하지만 성진님을 자주 만나 스켈터랩스의 프로젝트가 어떠한 방향으로 구체화되고 있는지 들을수록 매력적으로 와닿았다. 대기업의 경우 조직의 구조 때문에 어쩔 수 없이 쪼개진 일에 집중하게 된다. 하지만 스켈터랩스는 구성원들 모두가 자발적으로 참여하여 방향성을 결정 짓고, 개발 환경을 선진적으로 꾸리고 있다는 점도 좋았다. 이러한 요소가 결국 스켈터랩스로의 이직을 결정지었던 것 같다.Q. 스켈터랩스로 이직하여 얻은 가장 큰 성취를 꼽자면?개인적으로 코드리뷰 문화를 통한 개발 실력의 발전을 꼽고 싶다. 다른 조직에서는 다른 사람이 내 코드를 봐주고, 평가하는 것이 마치 자존심 싸움처럼 여겨지곤 했다. 타인의 코드는 일종의 침범할 수 없는 ‘불가침 영역'으로 인식되었다. 하지만 스켈터랩스에서는 코드리뷰가 너무나도 당연하다. 다른 사람에게 코드를 보여주고, 내 코드가 더욱 효율적으로 작동할 수 있도록 바꾸어주는 것이 자연스럽게 이루어지고 있다. 이 과정을 통해 코드를 리뷰하는 사람도, 리뷰받는 사람도 모두가 윈윈(win-win)할 수 있다. 코드리뷰 문화가 익숙하지 않은 사람에게는 이 문화가 마치 일의 효율을 저해하는 것 처럼 여겨질 수 있다. 그러나 결론적으로는 목표에 닿기 위한 가장 빠른 방법이라고 생각한다. 확실히 여러 개발자의 리뷰를 거칠수록, 버그는 적어지고 개인의 실력이 향상될 뿐더러 시야도 넓어질 수 있기 때문이다. 나 또한 같은 경험을 했다. 스켈터랩스에서 몇 개월 근무한 후, 내가 이전에 짜놓은 코드를 보면 ‘어떻게 이렇게 짜놓았지' 싶을 때가 있다. 개발 실력에 관한 이러한 성취를 정량적으로 판단할 수 는 없지만, 회사와 개인이 모두 발전할 수 있는 가장 의미있는 성취라고 생각한다.Q. 반대로 스켈터랩스에서 개발을 하며 가장 어려운 점은 무엇이 있을까.개발 자체에 대한 어려움보다는 방향성에 대한 어려움이 있다. 인공지능이라는 분야는 워낙 넓기도 하고, 상황인식 기술의 경우 근래에 크게 발전하고 있는 것은 맞지만, 세부 기술에 대해서는 시장 자체가 뚜렷하지 않다. 참고할만한 제품도, 경쟁사도 없기 때문에 새로운 시장을 만들어내는 것에 대한 부담이 있다. 언뜻 보기에는 경쟁사가 크게 없는 니치마켓(Niche market)처럼 여겨질 수 있지만, 기술을 쪼개고 쪼개어 들여다보면 하나의 기술을 바탕으로 각각 다른 사용자와 상황을 타깃으로 변주한 다양한 서비스가 등장하는 상황이다. 이러한 기술을 마냥 뭉뚱그린다면 기술에 대한 깊이가 얕아질 수 있고, 특정 상황과 사용자에게만 집중한다면 타깃이 좁아질 위험이 있다. 때문에 시장과 사용자에 대해 매 순간 유추하며 적절한 균형을 가지고 개발을 진행할 수 있도록 노력하고 있다. 사진3. 프로젝트 별 Sync-up 미팅, 짧은 미팅을 통해 업무 효율을 높이고 있다Q. 스켈터랩스의 개발 문화가 타 기업과 확고하게 다르다고 느낀 사례가 있다면, 그 이야기를 구체적으로 듣고싶다.A. 두 가지를 꼽고 싶다. 첫 번째는, 다른 분들도 많이 얘기했을 것 같지만 역시 와 다. 각각 상반기와 하반기에 한 번 씩, 하는 일을 모두 멈추고 일주일 간 원하는 개발에 집중하는 일종의 해커톤이다. 내가 입사한 날이 Demo Days 시작 이틀 전이었다. 입사하자마자 부랴부랴 팀을 만들고, 아이디어를 구체화하여 개발에 매달렸다. Demo Days 기간 내내 팀원들이 밤을 새워가며 개발에 매달리는데, ‘매일 이렇게 일하는 곳인가' 라는 두려움과 ‘이렇게 뛰어난 개발자들이 집중하니까 뚝딱 서비스가 나올 수 있구나'라는 재미를 동시에 느꼈다. 그 기간이 끝나고 보니 역시 매일 그렇게 일하는 것은 아니었다. 일주일 간 그토록 밤을 세워 개발을 할 수 있는 원동력은 ‘내가 원하는 서비스를 직접 만들어볼 수 있다'라는 흥미와 ‘최종 발표일에 어설픈 개발로 쪽팔리고 싶지 않다'라는 감정인 것 같다. 매일 하는 업무에서 벗어나 리프레쉬 할 수 있는 재미요소도 크다. 그 기간의 우리 성과를 돌아보면, 이토록 개발을 사랑하고 기대 수준이 높은 사람들이 모여있으니, 뭘 하던 성공할 것이라는 일종의 확신을 얻을 수 있다. 두 번째는 ‘빠르다'라는 점이다. 새로운 아이디어나 기술에 대해 흥미가 생겼을 때 쉽고 빠르게 팀을 꾸릴 수 있다. 그렇기 때문에 자연스럽게 자신의 흥미와 역량에 맞는 팀을 찾아 이동하는 것도 매우 자발적으로, 빠르게 이루어진다. 오픈 소스 사용도 빠르다. 새로운 기술이나 제품을 들여다보고 싶다면, 그냥 진행해 볼 수 있다. 기존의 큰 회사들은 수직적으로 팀장 급에서 업무를 할당하고 시일에 맞추어 개발을 진행하다 보니, 속도 자체는 빠를 수 있지만 허술한 부분이 생기기 마련이고 새로운 기술을 도입에 있어서도 조심스럽다. 하지만 스켈터랩스에서는 ‘빨리 도입하고 빨리 경험해보자’ 라는 의식을 공통적으로 가지고있다.Q. 개발자는 개발이 막히는 순간도 종종 맞닥뜨릴 것 같다. 그럴 때 어떻게 해결하는지 자신만의 팁을 공유한다면.A. 고민의 양이 아니라, 그저 고민의 끈을 놓지 않고 있는 것이 중요한 것 같다. 나는 개발이 막혔을 때 스트레스를 꽤 많이 받는 편이다. 한 번 막히면 맥주를 마시면서도, 밥을 먹으면서도 항상 머리 한 구석에는 개발 고민을 이어간다. 꿈에서도 하도 코딩을 한 탓에, 와이프가 어느 날 “어젯 밤에도 ‘테스트 코드는 이렇게 해야지’ 라는 잠꼬대 하던데?”라고 말할 정도다. 그러다 신기하게도 개발을 아무 것도 모르는 제 3자와 얘기하다가 번뜩 방법이 떠오르곤 한다. 지극히 일상의 순간, 가령 샤워를 한다거나 멍하니 지하철을 타다가 해결책을 찾기도 한다. 이 방법이 훌륭한 팁은 아닐 수 있지만, 포기하는 것이 아니라 개발에 대한 고민을 놓지않는 것이 중요하다는 얘기를 전하고 싶다.사진4. 경희 님과 아내 분의 투샷Q. 경희님이 회사에서 종종 드라마 얘기를 하는 것을 들었다. 드라마를 많이 보는 편인가, 하루 일과를 듣고 싶다.A. 예전에는 <와우>라는 게임을 정말 많이했다. 덕분에 게임 동호회에도 가입해있는데, 요즘에는 <오버워치>나 <클래시로얄> 정도만 즐기고 있다. 결혼하고 와이프와 시간을 함께 보내면서, TV 시청이 늘었다. 와이프가 워낙 TV를 좋아하기도 하고 함께 집에서 시간을 보낼 수 있는 가장 편리한 방법인 것 같기도 하다. 하루 일과는 그래도 일찍 시작하는 편이다. 와이프는 일곱시 쯤 일어나 출근하는데, 나도 보통은 맞춰서 함께 일어난다. 재택근무를 할 수 있는 환경이다보니, 오전에는 주로 집에서 코딩을 하며 개발에 집중한다. 보통 점심 때 출근을 하거나, 미팅에 맞추어 출근하는 편인데, 오후 시간은 미팅과 개발 모두를 병행해서 꽤 정신 없이 하루가 흘러가는 것 같다.사진5. 게임동호회에 가입하면, 회사의 지원을 받아 게임을 즐길 수 있다.Q. 스켈터랩스에서 이루고 싶은 것을 듣고싶다.A. 나의 꿈이 원래 ‘내가 개발한 기술이나 제품이 최대한 많은 사람에게 편리함을 주는 것'이었다. 우연히도 스켈터랩스의 미션인 “언제 어디서나 우리의 일상을 이해하고, 도와주고, 더 나아지게 하는 머신 인텔리전스의 혁신을 이룬다”와 일치하더라. 덕분에 내 꿈을 이루어나가는 것과 스켈터랩스가 혁신적인 기술을 바탕으로 성장하는 것은 궤를 같이한다. 그것이 내가 스티브잡스 처럼 특정 분야의 스타가 되는 것을 뜻하지는 않는다. 연속성이 있고 확장성이 있는 기술로 우리의 일상을 조금씩 더욱 편리하게 가꾸어나가고 싶다.Q. 마지막 질문이다. 스켈터랩스에 바라는 점이 있다면 무엇인가.A. 내가 입사했을 때만 해도 20명 정도에 불과했던 인원이 현재는 70여 명으로 늘었다. 체감상 인원이 조금씩 느는 것이 아니라 순간적으로 확 늘어나는 시기가 있는 것 같다. 그 때마다 약간의 침체기랄까, 분위기가 변하는 모습이 감지된다. 예전에는 사람이 적기 때문에 자연스레 커뮤니케이션이 자율적이이었지만, 사람이 늘어난 만큼 제한적인 커뮤니케이션 모습을 종종 발견할 수 있었다. 이러한 문제 의식의 발로로 컬쳐커미티(Culture Committee)가 생겨났다. 커미티의 활동 덕분에 매주 1:1로 커피를 마실 수 있는 커피믹스와 같은 제도도 신설되었다. 이렇듯 지속적으로 우리만의 모습을 유지하기 위한 노력이 지속되었으면 좋겠다. “우리는 답을 찾을 것이다. 늘 그랬듯이”, 흔한 명대사지만 스켈터랩스 또한 내부적으로도, 외부적으로 늘 답을 찾아가길 바란다. 물론 나 또한 그 답을 찾는 여정에 함께할 테지만 말이다.