스토리 홈

인터뷰

피드

뉴스

조회수 2149

스켈티인터뷰 / 스켈터랩스의 스테로이드 서종훈 님을 만나보세요:)

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 스테로이드 서종훈 님을 만나보세요:)사진1. 스켈터랩스 스테로이드 서종훈 님Q. 진부한 첫 번째 질문, 자기소개를 부탁한다.A. 스켈터랩스에서 소프트웨어 엔지니어로 일하고 있는 서종훈이다. 연세대학교 컴퓨터과학과에서 HCI(Human-computer interaction)와 컴퓨터 비전(Vision)쪽 연구로 박사 학위를 받았다. 그리고 L모 기업의 AI연구소에서 일을 하다가 최근 스켈터랩스에 입사했다.Q. 어떻게 스켈터랩스에 입사하게 되었는지 궁금하다.A. 지인을 통해서 스켈터랩스의 여러가지 프로젝트에 대해 듣게 되었다. 스켈터랩스의 Inno Lab에서 진행 중인 프로젝트가 HCI와 가장 연관성이 깊고, 재미있는 디바이스를 구현하고 있어서 눈여겨 보다가 입사를 지원했다. 물론 프로젝트의 방향성이 나의 관심 분야와 일치하는지 뿐만 아니라, 함께 일하는 사람이 어떤 사람인지 알아보는 과정도 필요했다. 다행히 스켈터랩스에 지인이 있었고, 그의 소개로 하드웨어 엔지니어팀을 이끌고 있는 재경 님을 비롯하여 다른 팀원들을 미리 만날 수 있었다. 긴 대화 끝에 회사의 조직문화나 방향성의 결이 나와 맞는다는 생각을 했다. 뛰어난 개발자가 많기 때문에 내가 계속 성장해나갈 수 있는 환경이라는 점도 입사 결심을 굳히게 된 큰 요소 중 하나다.Q. 스켈터랩스에서는 어떤 업무를 맡고 있는가. A. 스마트 거울 샘(Samm)의 제스처 인식을 담당하고 있다. 이미지 인식을 기반으로 하는 작업이기 때문에 카메라로 구현을 하는게 맞을 지, 혹은 센서를 사용하는 것이 좋을지를 테스트하며 최적의 답을 찾아내려 하고 있다. 또한 엔도어 솔루션(Endor Solution, 공정 과정에서 부품의 결함을 자동으로 검출하는 솔루션)이 더욱 뛰어난 성능을 발휘할 수 있도록 개발에 참여하고 있다. 기존의 팀원들 모두가 딥러닝 경험이 풍부하다. 반면 전통적인 비전(Vision) 쪽 경험은 상대적으로 내가 더 풍부하기 때문에, 데이터처리나 고전적인 방법을 적용한 개발을 통해 엔도어 솔루션을 탄탄하게 보완하려고 한다. 텐서플로우(Tensorflow) 기반으로 기존의 팀이 일해왔다면, 나는 OpenCV를 통해 선행 데이터를 처리한다.사진2. 영화 <마이너리티 리포트>에 등장하는 G-SpeakQ. 비전 기술에 관심을 갖게 된 특별한 계기가 있었는지 궁금하다.A. 글쎄, 계기라고 말하기는 힘들다. 그냥 자연스럽게 HCI쪽에 관심을 가지게 되었고, 그러다보니 다양한 인터페이스를 구현하는 일을 맡아왔다. 당시 HCI가 붐이었고, 아이폰이 이제 막 세상에 등장한 시기이기도 했다. 그런데 HCI 분야의 개발을 지속할수록, 사람들에게 편리한 방식으로 원하는 것을 제공할 수 있는 분야에서 비전 기술은 필수라는 생각이 들더라. 웨어러블 디바이스를 사용하지 않고서도, 개개인의 행동을 관찰하고 그에 맞게 적절한 가이드를 제시하는 것은 모두 비전을 바탕으로 한다. 스티븐 스필버그 감독의 톰 크루즈 주연 영화 <마이너리티 리포트>를 보면, 톰 크루즈가 특수장갑을 착용한 채 스크린을 제어하는 장면이 등장한다. 양손을 사용하여 자유자재로 허공에 활성화시킨 스크린을 제어하는데, 이 장면은 단지 영화 연출이 아닌 실제로 개발된 기술에서 영감을 얻은 장면이다. 기술의 명칭은 ‘G-스피크(G-Speak)’. 이 혁신적인 기술을 개발한 존 언더코플러(John Underkoffler)는 영화 자문 이후, ‘오블롱 인더스트리즈(Oblong Industries)’라는 회사를 설립했다. 사실 ‘G-스피크'를 구현하기 위한 개별 기술들은 당시에도 굉장히 많았다. 오블롱의 차별점은 이 다양한 개별 기술을 하나로 통합한다는 점이다. 오블롱의 행보를 관찰하며, 비전 기술의 활용도에 대해 일종의 확신을 강하게 품게 되었다. NUI(Natural User Interface) 기술이 보편화되면, 기존 오퍼레이션 시스템 환경은 크게 변화할 것이다. 그때 일반 소비자에게 편하게 와닿을 수 있는 새로운 인터페이스를 선도하는 회사가 시장의 선도자가 될 것이고, 비전 기술은 시장 선도자의 핵심일 것이라고 생각하고 있다.Q. 여러 프로젝트에 동시에 참여하고 있기 때문에, 각 팀마다 업무 방식이 어떻게 다른지를 경험했을 것 같다. 그 이야기를 듣고싶다.A. 기본적으로 분위기가 굉장히 다르다. 엔도어 솔루션은 기업의 사설연구소의 느낌이랄까, 굉장히 학구적인 느낌이 강하다. 딥러닝과 관련된 많은 논문을 읽고 깊이 있게 연구하고자 한다. 많은 실험도 필수적으로 병행되는데, 내부적으로는 각 논문과 실험을 통해 얻은 인사이트를 정리하고 공유하고자 노력하고 있다. 이러한 과정을 통해 기존의 다양한 모델을 조합하고 자체적인 모델 개발을 통해 최적의 결과물을 구축하려고 한다. 반면 Inno Lab의 다양한 프로젝트는 오히려 내가 기대했던 스타트업스러운 느낌이 있다. 기존에 없던 디바이스를 만들어 내기 위해 다같이 아이디에이션 과정을 진행했다. 그리고 빨리 구현하고 피드백을 취합한 후, 다시 개발에 들어가는 과정이 꽤 다이나믹하게 이뤄진다. 현재 개발 중인 샘 덕분에 주변의 신기하고 재미있는 디바이스를 검색해보고, 직접 써보고 있는데 덕분에 굉장히 얼리어답터가 된 듯한 느낌이다.사진3. 종훈 님의 일하는 모습을 몰래 촬영해보았다Q. 동시에 결이 다른 두 개의 프로젝트를 진행하기가 어려울 것 같다.A. 어렵다. 그래서 나는 아예 프로젝트마다 기한일을 설정한다. 한 분야에 몰입해서 쭉 끌고 나가는 것이 내게는 더 맞는 느낌이라, 각 프로젝트의 PM과 상의하여 샘 개발에 15일까지 참여한다면, 월 말까지는 엔도어 솔루션에 참여하는 식으로 조정한다.Q. 이전 직장과 스켈터랩스의 업무가 어떻게 다른지도 궁금하다.A. 이제 스켈터랩스에 합류한지 3개월이 좀 지났는데, 크게는 두 가지가 가장 다른 점이자 만족스러운 점인 것 같다. 첫 번째는 일단 개발 환경이다. 스켈터랩스는 개발 환경이 굉장히 빠르고 선진적이다. 개발을 워낙 잘 하시는 분들이 많기 때문에 협업하면서 배울 점도 많고 협업을 통한 시너지도 강하다. 여러가지 툴을 똑똑하고 빠르게 잘 활용하는 것도 업무 효율을 크게 향상시키는 부분이다. 구글 드라이브, 깃허브(GitHub) 뿐만 아니라, 유트랙(Youtrack)과 같은 이슈트래커(Issue Tracker)도 적극 활용한다. 클라우드 환경, 빌드 환경 등도 모두 유연하게 잘 갖춰져있다. 이전 회사가 폐쇄적으로 운영되었던 부분이 있어서 상대적으로 이런 부분을 더 만족스럽게 생각한다. 스타트업인 만큼, 신기술에 대해서 팔로우하고 적용시켜 보려는 과정이 빠르게 일어나고 있는 점도 좋다. 두 번째는 ‘함께 하고 있다'라 느낌이 강하다는 것이다. 이전에는 워낙 프로젝트의 규모도 컸기 때문에, 각자 맡은 업무의 경계선이 분명하게 그어져있었다. 그러나 스켈터랩스는 잦은 미팅을 통해 함께 기획부터 참여하기 때문에 ‘우리의 것'을 만들어낸다는 느낌을 준다.Q. 스켈터랩스에서 가장 애정하는 조직문화가 있다면?A. 맥주를 먹으면서 일할 수 있다는 것(스켈터랩스에는 맥주 디스펜서가 구비되어 있다)! 다이어트를 하고는 있지만 워낙 맥주를 좋아하는 나로서는, 개발이 잘 안풀릴 때 맥주를 먹으면서 일을 할 수 있다는 것 자체가 만족스럽다. 매주 금요일마다 함께 모여서 회사의 여러 프로젝트 진행 상황을 듣고, 구성원에 대해서 알아보는 시간인 올핸즈(All-hands)도 좋아한다. 보통 다른 회사의 경우 정보가 총체적으로 전달되지 않고, 쪼개진 정보만이 내려오는 경우가 많다. 하지만 올핸즈 덕분에 회사의 정보들이 모두에게 공유될 수 있고, 또한 참여할 수 있다고 생각한다.Q. 비슷한 질문이지만 회사 자랑을 위해 하나 더 묻고싶다. 스켈터랩스에서 가장 자랑하고 싶은 점을 꼽는다면 무엇일까.A. 두 가지를 꼽고 싶다. 먼저 자유로운 문화라는 점. 한국에서 정말 몇 안되는 실리콘밸리의 분위기를 풍기는 곳이라고 생각한다(단순히 나만의 의견이 아니라, 실제 실리콘밸리에서 근무하는 친구가 사무실에 놀러왔을 때 ‘실리콘밸리 같다'라고 표현했다). 겉으로는 허름한 창고같은 사무실이지만, 문만 열리면 다른 세계가 펼쳐지는 듯한 느낌을 받을 수 있다. 자유롭게 의견을 내고 토론을 하는 문화도 이 사무실의 분위기와 일맥상통한다. 두 번째는 개개인의 실력이 높아서 정말 배울 것이 많다는 점이다. 그게 한편으로는 스트레스기도 하다. ‘내 밑천이 바닥나면 안될텐데'라는 생각에 책과 다양한 소스를 통해 끊임없이 자발적으로 공부하게 만든다. 실제 개발자 중 몇 분은 구글에서 개발자 레벨의 최고 등급을 받은 것으로 알고있다. 개발 실력은 당연히 코드에 묻어나온다. 다른 개발자의 코드를 보면서도 많은 영감을 얻을 수 있고, 코드 리뷰에 참여하는 것 만으로도 개발 실력이 향상될 수 있다.Q. 자유로운 출퇴근 문화지만, 종훈 님은 꽤 일찍 출근하는 편으로 알고 있다. 하루 일과가 궁금하다.A. 집에서 아침 시간을 여유롭게 즐기는 편이다. 여섯시에 일어나 아침 밥을 집에서 챙겨먹고 출근하고 있다. 일찍 출근할수록, 그 날 내가 목표로 한 업무를 빨리 마치고 퇴근할 수 있기 때문에 너무 늦게는 출근하지 않으려 한다. 덕분에 규칙적으로 일곱시 쯤에는 퇴근을 마치고 운동을 한다. 주말에도 주로 운동을 즐기는 편인데, 요즘에는 토요일마다 꼬박 꼬박 딥러닝 스터디를 하고있다. 나는 전통적인 비전(Vision) 연구를 해왔기 때문에, 딥러닝 쪽은 바탕 지식이 얕은 편이다. 업무를 진행하는데 큰 어려움은 없지만, 회사 프로젝트의 좋은 결과물을 내기 위해서는 딥러닝을 썼을 때 효율적인 부분이 크다. 때문에 많은 시간을 공부에 할애하는 것 같다.Q. 스켈터랩스 헬스동호회 스켈터 스테로이드의 수장으로 알고있다. 동아리를 소개한다면?A. 동호회를 만들게 된 계기는 단순하다. 새 회사에 왔으니, 새로운 몸을 만들겠다는 마음이었다. 사실 헬스는 누군가랑 같이 하는 운동은 아니지않나. 그래도 동호회원들 덕분에 ‘오늘은 그냥 좀 운동을 쉴까’ 싶다가도 누군가가 먼저 나서면 ‘그래도 빠지지 말아야지'란 생각에 꼬박꼬박 운동을 가게된다. 일주일에 두 번이니, 부담스럽지 않은 양이기도 하다. 내가 수장인 만큼 본보기로 열심히 나가야한다는 일종의 책임감도 꾸준히 운동을 이어나가는 원동력이 되었다. 날씨가 추워지면서, 다들 몸을 만들겠다는 의지가 약해져서인지 최근에는 참여률이 떨어지고 있다. 실내에서 할 수 있는 다양한 운동 종목을 더해, 참여를 높이는 방법을 고민 중이다. Q. 운동을 꾸준히 해오고 있는데, 헬스 동호회를 통해 목표했던 성취는 이루었는지 궁금하다.A. 동호회 소개를 하며 ‘이틀 밤을 새도 지지않는 체력을 얻어갈 수 있습니다'라고 공표했는데, 변명이지만 목표가 너무 거창했던 것 같다. 이틀 밤을 새도 지지않는 체력이 갖기 위해 갈 길이 멀다. Q. 이제 인터뷰를 마무리할 단계다. 스켈터랩스가 어떤 회사가 되면 좋겠는가.A. 앞서 말했던 오블롱 인더스트리즈나 센스타임(Sensetime)처럼, 확고한 기술력으로 시장의 선두주자가 되었으면 한다. 이를 위해서는 논문도 많이 내야할 것이고, 더욱 많은 개발자와 함께 기술을 더 깊게 파고드는 과정이 지속되어야 한다. 또한 스타트업으로서 시장의 성패와 상관 없이 가치있고 재미있는 개발을 많이 하면 좋겠다. 현재로서는 Inno Lab이 이러한 성격을 띠고 있다. 그래서 일단은 프로젝트 중 하나인 샘을 성공적으로 런칭하는 것이 나의 목표다.Q. 진짜 마지막 질문. 앞선 질문과 비슷하지만, 개인적인 꿈이 있다면?A. 오래 일하고 싶다. 나이가 들어서도 시장의 흐름을 읽고, 새로운 기술에 대한 충분한 이해와 개발력을 갖춘 사람으로 오래오래 일하고 싶다. 사실 일반적으로 개발자의 수명은 길지 않다. 그래서 창업에 대한 욕심도 품고 있다. 스켈터랩스의 CEO인 테드 님을 보면서 한편으로는 기업 운영 노하우를 배워나간다는 생각도 있다. 향후에는 스켈터랩스의 경쟁사를 내가 세울 수도 있지 않을까(테드 님이 이걸 보면 뭐라하실지 걱정이긴 하다).#스켈터랩스 #사무실풍경 #업무환경 #사내복지 #기업문화 #팀원인터뷰 #팀원소개 #팀원자랑
조회수 2276

개발자에게 필요한 좋은 개발도구들

안녕하세요. 크몽 개발팀 입니다~ 개발자는 무엇인가 개발하기 전에 준비해야될게 있습니다. 바로 개발도구들 과 자신에게 잘 맞는 셋팅이 필요하죠.그래서 이번에 개발환경을 셋팅하면서 알게 된 정보를 공유하기위해 이번 포스트를 작성하게 되었습니다.첫번째 개발도구는 'ampps' 입니다.  ampps는 개발에 있어서 필요한 다양한 개발도구들을 제공해주고 있는데요. 정석대로 하나씩 개발도구들을 설치하게 된다면 많은 시간을 투자해서 설치 및 셋팅을 해야하지만ampps는 한번의 설치만으로 Apache, MySQL, PHP, Python, MongoDB 등등 기본적인 셋팅을 통해 초보개발자이더라도 쉽고 편리하게 사용할 수 있다는점이 가장 큰 장점이라고 생각하고 있습니다.지원되는 운영체제는 Windows, Mac, Linux 모두 지원하기때문에 어느 운영체제는 지원이 안되는 불편함은 없겠네요.사이트 :http://www.ampps.com/ 두번째 개발도구는 'WebStorm' 입니다.  WebStorm은 비쥬얼스튜디오나 이클립스와 같은 통합 개발환경을 제공하고 있습니다.그리고 현재 자바스크립트 프로그래밍에서 절대적인 최고의 에디터로 개발자 사이에서 유명하고 많은 개발자들이 사용하여 개발하고 있습니다. WebStorm의 좋은점은 작성한 코드에서 에러가 있다면 JSHint가 에러부분 밑에 워드프로세서 철자법검사기처럼 빨간 줄로 에러를 표시해 주기때문에 개발자의 실수들을 바로 잡아줄 수 있어서 정말 좋습니다. 그러나 사용자는 30일 평가기간이 끝나면 추가비용을 지불해야 사용할 수 있는데요. 비용을 지불할 만큼 좋은 에디터인점은 변함이 없습니다.  사이트 : https://www.jetbrains.com/webstorm/  앞으로도 공유할 정보들이 생길때마다 크몽팀 블로그에 업데이트 할 예정입니다.포스트 내용에서 찾으시는 정보들을 찾으셨으면 좋겠고 크몽팀 개발자이야기에 많은 관심 부탁드립니다. :)이상 포스트를 마치겠습니다. #크몽 #개발팀 #인턴 #인턴생활 #경험공유
조회수 830

웹기반 컨텐츠 저작 도구 셀프(XELF) v1.0 GS인증 획득

웹기반 컨텐츠 저작 도구 셀프(XELF) v1.0 (Web-based Contents Authoring Tool XELF v1.0)이 한국정보통신기술협회(TTA) 소프트웨어 시험인증연구소로부터 GS인증 1등급을 획득하였습니다.  셀프(XELF)는 별도의 프로그램 설치 없이도 접속만으로 웹브라우저 상에서 다양한 용도의 콘텐츠를 저작할 수 있는 디자인 플랫폼입니다. 디자인 전문가가 아니어도 누구나 손쉽게 프리젠테이션, 웹브로셔, 유저 인터페이스, 문서 등 비즈니스 및 교육환경에 필요한 다양한 콘텐츠를 디자인할 수 있습니다. 또, 이렇게 제작된 콘텐츠는 클릭만으로 SNS에 공유하거나 이메일로 전달하는 등 간편하게 활용할 수 있는 장점을 가지고 있습니다.   GS인증은 엄격한 시험을 통해 품질이 우수한 소프트웨어를 인증해주는 국가공인 소프트웨어 품질인증제도로 공공기관에서 우선 구매 대상으로 지정되기도 합니다. ISO 국제표준을 기준으로 SW의 기능성, 신뢰성, 효율성, 사용성, 유지보수성, 이식성, 성능 등을 평가하고 검증을 거쳐 부여되었습니다. ㈜그로비스인포텍은 이번 GS인증을 계기로 디자인 플랫폼으로서의 기술성과에 자신감을 가지고 향후 계획된 베타서비스 준비에 최선을 다하고 있습니다. 더 나은 사용성과 기술적 안정성을 목표로 다양한 환경에 적용하고 테스트를 진행하고 있습니다. 곧이어 더 향상된 성능과 기능으로 찾아뵙길 기대하겠습니다. 감사합니다.
조회수 2266

스포카에서 쓰는 오픈소스와 오픈소스 라이센스 (1)

안녕하세요. 스포카 프로그래머 박종규입니다. 이번 시간에는 스포카에서 쓰고있는 클라이언트 측 오픈소스와 그 오픈소스가 어떠한 라이센스가 적용이 되었는지 알아 보겠습니다.오픈소스(Open Source)먼저 간략하게 오픈소스의 정의에 대해서 짚어가도록 하겠습니다. 오픈소스는 소스코드를 외부에 공개하여 누구든지 제한없이 소프트웨어를 쓰고 소스코드를 볼 수 있는 소프트웨어를 말합니다. 통상적으로 오픈소스 소프트웨어를 오픈소스라고 부르기도 합니다. 대표적인 오픈소스로는 우리가 많이 쓰는 안드로이드OS와 크로미움 브라우저를 볼 수 있죠.프로젝트에 오픈소스를 적용?그렇다면 오픈소스의 정의도 알았고 제한없이 쓸 수도 있다고 하고 이렇게 많은 장점이 있는 오픈소스를 우리회사 프로젝트에 한 번 도입해볼까?라는 생각을 가지신 분들이 있겠지만 잠시만 기다려 주시길 바랍니다. 이러한 오픈소스는 오픈소스 라이센스라는 일종의 저작권이 적용이 되어 있어서 그 라이센스를 준수 해야합니다.오픈소스 라이센스(Open Source License)오픈소스 라이센스의 정의를 간략하게 보면오픈소스 라이센스는 오픈소스SW 개발자와 이용자간에 사용 방법 및 조건의 범위를 명시한 계약을 말한다. 따라서 오픈소스SW를 이용하기 위해서는 오픈소스SW 개발자가 만들어놓은 사용 방법 및 조건의 범위에 따라 해당 SW를 사용해야 하며, 이를 위반할 경우에는 라이선스를 위반함과 동시에 저작권 침해로 인해서 이에 대한 처벌을 받게 된다.라고 나와 있습니다. 즉 오픈소스이긴 하지만 오픈소스에 적용된 라이센스를 준수하지 않는다면 법적인 처벌을 받는다는 거죠. 그렇기 때문에 프로젝트에 오픈소스를 적용하려면 제일 먼저 라이센스를 확인해야 합니다.스포카 클라이언트에서는 어떠한 오픈소스를 쓰고 있을까?현재 스포카의 클라이언트측에서 사용하고 있는 오픈소스는 다음과 같습니다.jQueryLESSBackbone.jsD3.jsDataTables.js그럼 간략하게 이 오픈소스가 어떠한 역할을 하는지 간략하게 알아보겠습니다.jQueryjQuery(제이쿼리)는 브라우저 호환성이 있는 HTML 속 자바스크립트 라이브러리이며 클라이언트 사이드 스크립트 언어를 단순화 할 수 있도록 설계되었습니다. 즉 자바스크립트를 좀 더 편하게 쓸 수 있도록 개발된 라이브러리이죠.LESSLESS는 css를 동적으로 쓸 수 있게 해주는 자바스크립트 라이브러리 입니다. 기존 css에서 제공하지 않는 변수 및 연산식을 제공하기 때문에 코드를 재사용 할 수 있을 뿐만 아니라 개발시 소요되는 시간을 줄여줍니다. *.less로 개발된 코드는 less 컴파일러를 통해 *.css로 변환이 되어 클라이언트 페이지에 적용됩니다.Backbone.jsBackbone.js는 자바스크립트를 MVC 패턴으로 개발할 수 있게 도와주는 자바스크립트 라이브러리입니다.D3.jsD3.js는 데이터를 우리가 쉽게 볼 수있게 다양한 차트, 표, 그림으로 표현 할 수 있도록 기능을 제공해주는 자바스크립트 라이브러리입니다.DataTables.jsDataTables.js는 table를 만들어주는 기능을 제공하는 자바스크립트 라이브러리입니다.그렇다면 위 오픈소스에는 어떠한 라이센스가 적용되어 있을까?위의 오픈소스에 적용되어 있는 라이센스를 살펴보면jQuery : MIT, GPLv2LESS : apache license 2Backbone.js : MITD3.js : BSDDataTables.js : BSD, GPLv2같은 라이센스가 적용이 되어 있습니다. 그럼 하나씩 살펴보도록 하죠.듀얼라이센스먼저 jQuery와 DataTables.js에는 다른 오픈소스와 다르게 라이센스가 두개가 적용이 되어 있는 것을 볼 수 있습니다.이것을 흔히 듀얼라이센스라고 하는데 이 라이센스는 오픈소스를 쓰는 사용자가 두개의 라이센스중에서 하나를 선택해서 쓸 수 있는 라이센스입니다. 예를 들면 jQuery를 쓰는 사용자는 GPL 라이센스를 적용을 할 수도 있고 MIT 라이센스를 적용해서 쓸 수 있다는 뜻이죠.GPL 라이센스jQuery와 DataTables.js에 적용되있는 GPL라이센스에 대해서 알아 보겠습니다. GPL라이센스는 오픈소스에 가장 많이 적용된 라이센스 중에 하나입니다. 이 라이센스는 자유소프트웨어재단에서 만든 라이센스로 이 라이센스를 가진 오픈소스를 이용하여 응용 프로그램을 개발하는 경우에는 GPL라이센스가 적용이 됩니다. 그리고 GPL라이센스는 3가지의 버전이 있습니다.GPLv1GPL의 버전 1은 1989년 1월에 발표되었다(GPLv1 전문). 이것은 자유 소프트웨어에서의 두 가지 중요한 자유를 보장해 주었는데, 하나는 프로그램의 소스코드를 공개하지 않은 채 바이너리 파일만 배포하는 것을 막는 경우로 이것을 막기 위해 GPLv1에는 프로그램을 GPLv1로 배포할 때는 사람이 이해하기 쉬운 소스 코드를 같이 배포해야 한다는 조건이 들어갔다. 두 번째 문제는 프로그램에 추가적인 제약을 걸 가능성이 있다는 점이었고, 이를 막기 위해 GPLv1 프로그램을 수정한 프로그램은 원래 프로그램과 마찬가지로 GPLv1을 따라야 한다는 조건이 들어갔다.GPLv2자유 소프트웨어 재단(OSF)에서 만든 자유 소프트웨어 라이선스다. 미국의 리처드 스톨만(Richard Stallman)이 GNU-프로젝트로 배포된 프로그램의 라이선스로 사용하기 위해 작성했다. ‘① 컴퓨터 프로그램을 어떤 목적으로든지 사용할 수 있다 ② 컴퓨터 프로그램의 복사를 언제나 프로그램의 코드와 함께 판매 또는 무료로 배포할 수 있다 ③ 컴퓨터 프로그램의 코드를 용도에 따라 결정할 수 있다 ④ 변경된 컴퓨터 프로그램 역시 프로그램의 코드와 함께 자유로이 배포할 수 있다’라는 네 가지 조항을 명시하고 있다. 대부분의 소프트웨어에 대한 라이선스는 소프트웨어를 공유하거나 수정할 수 있는 자유를 금지하기 위 고안되었다. 반면에 GNU 일반 공중 라이선스는 자유 소프트웨어를 공유하고 수정할 수 있는 자유를 보장하기 위해 의도되었다. 즉, 소프트웨어가 사용자 모두에게 자유롭게 이용될 수 있도록 하는 것이다. 이 일반 공중 라이선스는 자유 소프트웨어 재단의 소프트웨어 대부분을 비롯하여, 저작자가 이 라이선스의 사용을 지정한 기타 모든 프로그램에 적용된다. (자유 소프트웨어 재단의 소프트웨어 중 일부는 이 라이선스 대신 GNU 라이브러리 일반 공중 라이선스가 적용된다.) 누구나 자신의 프로그램에 이 라이선스를 적용시킬 수 있다.GPLv3자유 소프트웨어 재단(FSF)과 이 재단의 GNU 프로젝트에 의해 배포되며 GNU 소프트웨어에 적용되는 공개 소프트웨어의 대표적인 라이선스 체계. GNU GPL이라고도 하며, 저작권(COPYRIGHT)의 반대라는 의미로 카피레프트(COPYLEFT)라고도 한다. 라이선스 사용료나 사용상의 제약 조건을 자유롭게 하여 소프트웨어 유통을 활성화하기 위한 의도에서 출발한 것으로 GNU 소프트웨어로 공개되는 원시 부호는 누구나 변경 또는 일반 공중 라이선스(GPL)로 재배포하고, 이를 이용하여 상업적 웹 사이트를 구축할 수도 있다. 그렇다고 저작권의 완전한 포기를 의미하는 것은 아니어서 GPL의 기본 원칙과 공개하는 측이 정의한 바를 충실하게 따르도록 되어 있다. 1990년대에 마련된 GPL V2.0에 이어 2005년에 V3.0이 발표되었다. GPL 버전 3은 2007년 6월 29일에 발표되었다. 2005년 후반에 자유 소프트웨어 재단에서 GPL의 세번째 판을 개발할 것이라고 발표했다. 바뀐 점 중에서 가장 중요한 4가지를 말하자면, 소프트웨어 특허에 대처하는 것, 다른 라이선스와의 호환성, 어떤 부분의 원시 코드와 무엇이 GPL이 포함되어야 하는 원시 코드를 구성하는지와 디지털 제한 관리(DIGITAL RESTRICTIONS MANAGEMENT)에 신경을 썼다.※참고GPL 라이센스가 적용된 오픈소스를 사용했다고 무조건 소스코드를 공개해야 하는 것은 아닙니다. 예를 들면 MySQL db를 이용하여 웹서비스를 개발해서 직접 서비스만 운영하는 경우 이것은 다른 곳에 배포하는 것이 아니므로 GPL 라이센스 의무사항이 적용되지 않습니다. 하지만 다른 곳에 제공하거나 파는 경우(쇼핑몰을 제작해서 파는 경우)에는 배포하는 것이 되므로 GPL라이센스가 적용이 됩니다. 따라서 이런 경우에는 상용라이센스를 구매해서 써야 합니다.MySQL에서 정의한 배포하는 대표적인 예는 다음과 같습니다.MySQL을 포함하고 있는 소프트웨어를 고객에게 팔아 그 소프트웨어를 고객이 소유한 장비에 설치하는 경우고객이 소유한 장비에 기본적으로 MySQL을 설치해야하는 소프트웨어를 파는 경우MySQL을 포함하고 있는 하드웨어 시스템을 고객에게 팔아서 고객이 있는 곳에 설치하는 경우MIT 라이센스MIT 라이센스는 MIT 공과대학교에서 학교 학생들의 소프트웨어 학습을 돕기 위해서 개발한 허가서입니다. 이 라이센스는 강력한 조항이 없어서 MIT 라이센스가 적용된 오픈소스를 이용하여 응용 프로그램을 개발할 시에 응용 프로그램을 오픈소스로 해야할 필요도 없고 소스코드를 공개할 의무가 없습니다. 또 상업적인 제한도 없습니다. 다만 응용 프로그램에 MIT 라이센스라고 표시와 라이센스 사본을 첨부만 해주면 됩니다.BSD 라이센스버클리의 캘리포니아 대학에서 배포하는 공개 소프트웨어의 라이선스입니다. BSD 라이센스는 자유소프트웨어 자작권의 하나로 BSD 계열 소프트웨어를 포함한 많은 프로그램에서 사용하고 있습니다. 이 라이센스는 라이센스라고 할 수 없을 만큼 미약해서 아무나 수정하고 배포하고 소스코드를 공개해야 할 의무가 없습니다. MIT 라이센스와 마찬가지로 라이센스 표시만 해주면 됩니다.Apach license 2아파치 라이센스는 아파치 소프트웨어 재단에서 만든 라이센스입니다. 이 라이센스 또한 MIT,BSD와 마찬가지로 소스코드 공개의 의무는 발생하지 않습니다. 하지만 “Apache”라는 이름에 대한 상표권을 침해하지 않아야 한다는 조항이 있어서 BSD라이센스보다 법적으로 완결된 내용을 담고 있습니다. 라이센스의 표시와 아파치 소프트웨어 재단에 개발된 소프트웨어라는 것을 밝혀야 합니다.참고한국저작권위원회위키백과KLDPwikiGNU공개SW포털MySQL KOREAKLDP 오픈소스라이센스가이드오픈소스 라이센스 비교표#스포카 #운영 #개발 #오픈소스 #개발자 #개발팀 #꿀팁 #인사이트 #조언
조회수 1031

코인원 크루의 채굴 현장을 포착했다! - ‘코인원 작업증명(PoW)’을 소개합니다

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

P2P금융에서 고도의 엔지니어링이 필수적인 이유

지난 8월30일, 매일경제신문이 주최하고 과학기술정보통신부와 금융위원회, 금융감독원이 후원한 매경핀테크어워드2018에서 렌딧이 최우수상을 수상했다. 렌딧이 굳이 이런 경연대회에 참여를 한 이유는 ‘P2P금융산업에서 기술력과 고도의 엔지니어링 파워가 얼마나 중요한 지’를 널리 알리고 싶기 때문이었다.매경핀테크어워드 수상 소식을 들은 후, 엔지니어링팀 렌딧맨들과최근 렌딧은 개발자 채용에 그 어느때보다도 열심이다. 많은 개발자들과 만나 P2P금융산업의 미래와 우리 회사가 하는 일에 대해 설명하고 좋은 개발자를 영입하기 위해 노력하고 있다. 그런데 생각보다 훨씬 더 개발자들에게 P2P금융기업이 어떤 일을 하고 있고, 왜 개발자가 도전할 만한 분야인지 알려져 있지 않다는 사실을 알게 되었다. 이번 글에서는 렌딧이 하는 일을 바탕으로 P2P금융회사에서 왜 고도의 소프트웨어 엔지니어링이 필수적으로 필요하고, 개발자 여러분이 어떤 일에 도전해 볼 수 있는지에 대해 설명해 보려고 한다. 우선 대출과 투자 등 모든 서비스가 기존 금융회사와 달리 온라인 상에서 이루어진다. 특히 렌딧이 집중하고 있는 개인신용 P2P금융의 경우, 대출 심사와 집행, 투자 모집과 운용 등 서비스 전 과정을 100% 온라인, 비대면 서비스로 구축하고 있는 디지털 금융 플랫폼이다.대출 서비스에서는 머신러닝 기반의 대출자 심사평가모델 개발이 핵심적이다. 렌딧이 자체 개발한 렌딧 개인신용평가시스템(Lendit Credit Scoring System)을 예로 들어 보겠다. 신용평가사에서 제공하는 250여가지의 금융 데이터를 순식간에 분석해 모든 대출 신청자마다 개인화 된 적정금리를 산출해 내는 시스템이다. P2P금융기업인 렌딧이 개발한 심사평가모델을 기존 금융권의 심사평가모델과 비교할 때 가장 큰 차이점은, 머신러닝 기법을 사용해 각종 금융 데이터의 최근 12개월 간 트렌드를 분석한다는 점. 이를 통해 보다 정교하게 개인의 신용을 평가해 낸다. 여기에 추가적으로 신용평가사에서 제공하는 사기정보공유(Fraud Bureau)데이터, 직장 신용정보, 상환 정보 등을 종합적으로 반영하고 있다. 최근에는 대출자가 제출하는 신분증 확인 과정에 머신러닝을 적용해 자동화해 나가기 시작했다. 투자 서비스에서는 실시간으로 분산투자 포트폴리오를 추천해 주는 알고리듬이 돌고 있다. 투자자가 투자할 금액을 입력하면 눈깜짝할 사이에 현재 투자 가능한 채권을 조합해 분산투자 포트폴리오를 추천해 주는 시스템이다. 포트폴리오에 조합된 모든 채권에 투자금을 일정한 비율로 고르게 나누어 분산투자할 수 있도록 추천해 주는 것이 특징이다. 렌딧이 개발한 분산투자 시스템은 투자자 1인이 수백~수천개의 채권에 분산하는 것과 동시에, 채권 1개도 평균 1,303명, 최대 3,814명(기준 2018년 6월30일 현재)이 나누어 리스크를 분산하도록 개발되어 있다. 이렇게 분산투자를 시스템적으로 활성화 시키고 있는 덕분에, 현재까지 렌딧의 모든 투자자가 하고 있는 분산투자의 총 누적 건수는 거의 800만 건에 육박하는 수준이다. 점점 더 많은 데이터가 축적되고 있기 때문에, 이러한 데이터를 바탕으로 고객에게 제공할 수 있는 서비스 아이디어도 하루 하루 쌓여 가고 있는 중이다.P2P금융산업이 가장 발전한 시장인 미국의 경우, 최대 규모인 렌딩클럽 한 회사가 미국 개인신용대출 시장 전체의 약 1.5%이상을 차지할만큼 금융 시장을 혁신해 나가고 있다. 렌딧 역시 지난 3년간 빅데이터 분석에 기반한 정교한 신용평가를 통해, 대출 고객의 이자를 총 100억원이 넘게 절약해 드리는 성과를 만들어 냈다. 그간 기존 금융회사들이 만들어 내지 못한 중금리 대출 시장을 스타트업인 렌딧이 활짝 열어낸 것이다.렌딧에서 우리 렌딧맨들과 함께 한국의 금융을 혁신하는 금융 플랫폼을 만들어 가실 엔지니어 여러분을 기다립니다. 관심있는 분은 주저없이 [email protected] 로 연락 주세요. 많은 엔지니어 여러분과 만나뵙고 싶습니다. 
조회수 984

디지털 노마드를 꿈꾸며

들어가며웹 서비스를 운영하는 여느 회사들처럼 엘리스의 엔지니어링 팀도 ‘프론트엔드’ 팀과 ‘백엔드’ 팀으로 이루어져 있습니다.‘프론트엔드’는 앞쪽에서 유저와 직접 맞닿아 있는 부분을 말합니다. 엘리스와 같은 웹 서비스에서는 웹 브라우저에서 유저들에게 보이는 웹페이지를 HTML/CSS/Javascript를 이용해 만드는 사람들이 프론트엔드 엔지니어라고 할 수 있습니다.‘백엔드’는 유저의 눈에 보이지 않는 뒷부분을 말합니다. 백엔드는 프론트엔드에서 보내는 요청을 처리하고 데이터를 보내주는 역할을 하는데요, 엘리스는 현재 프론트엔드 엔지니어 3명과 백엔드 엔지니어 2명이 서비스 개발을 담당하고 있습니다.한 가지 놀라운 점은, 엘리스의 엔지니어링 팀을 비롯해 디자인 팀, 운영팀 등이 모두 한 곳에 모여있지 않다는 것입니다. 국내에서는 이러한 형태의 원격 근무를 도입한 회사를 찾아보기 어렵지만, 기술의 발전으로 변화한 환경에서 ‘디지털 노마드’를 하나의 생활 양식으로 도입하고자 하는 목소리는 증가하고 있습니다. 디지털 노마드는 쉽게 말하면 어디든 자신이 일하고 싶은 곳에서 원격으로 근무하는 사람을 뜻합니다. 엘리스는 회사 구성원 전체가 원격 근무가 가능한 디지털 노마드 회사를 꿈꾸고 있습니다.엘리스의 모든 개발 과정은 디지털 노마드의 꿈에 걸맞게 원격으로 이루어집니다. 물론 원격으로 함께 일하기 위해서는 효과적인 툴의 도움이 필요할텐데요, 디지털 노마드를 실현하기 위해 엘리스에서는 어떤 도구들을 사용하고 있을까요? 이 글에서는 프론트엔드 팀의 관점에서, 엘리스 웹사이트에 기능이 추가되는 과정과 사용되는 협업툴을 2017년 초에 개발된 ‘헬프센터’를 예로 들어 이야기해보겠습니다.엘리스의 프론트엔드 개발 싸이클엘리스에서 기능이 개발되는 대략적인 흐름은 다음과 같습니다.기획 - 디자인 - 구현 - 테스트 - 배포 & 모니터링여기서 각 단계는 엄밀히 나눠져있거나, 무조건 한 방향으로 흐르지는 않습니다. 구현을 하다가도 기획을 수정해야 하면 다시 처음으로 돌아가기도 합니다. 각 단계를 좀 더 자세히 살펴보도록 하죠.기획 단계어떤 기능이 왜 필요한지, 필요하다면 일의 중요도와 걸리는 시간은 어떤지 등을 엘리스의 연간 로드맵과 비전에 맞춰 논의하고 계획하는 단계입니다. 거의 모든 논의는 Slack이라는 온라인 협업 툴의 화상채팅에서 이루어집니다. 엘리스에는 ‘기획자’라는 역할이 명확하게 주어진 사람은 없습니다. 기본적으로 팀 리더가 의견을 취합하고 방향성을 제시하지만, 엔지니어링팀, 운영팀, 디자인팀 모두가 의견을 자유롭게 제안할 수 있습니다.2017년은 엘리스가 처음으로 대학교, 기업 등 기관 고객이 아닌 일반 사용자에게 수업을 제공하기 시작한 해입니다. 우리는 프로그래밍 학습을 하는 데 있어서 아주 중요한 요소 중 하나가 실습을 빠르게 많이 해보고 막혔을 때는 선생님에게 도움을 받을 수 있게 하는 것이라고 생각했습니다. 특히 프로그래밍을 한 번도 접해보지 않은 분들이 엘리스에서 처음으로 코딩학습을 시작하는 경우가 많았기 때문에, 이러한 사람들에게 효과적으로 도움을 줄 수 있는 기능이 무엇일지에 대한 많은 논의를 나눴습니다. 논의의 결과 개발하기로 결정한 것이 헬프센터입니다.Google Presentation으로 만들어진 초기 헬프센터의 컨셉 디자인 일부거시적 관점에서의 논의가 어느 정도 정리된 후에는 위 그림과 같이 구글 프리젠테이션으로 빠르게 만든 저수준(Low Fidelity) 디자인이 유용하게 쓰입니다. 이러한 저수준 디자인을 통해 개별 페이지의 상세한 디자인에 착수하기 전에 사용자 인터페이스와 경험(UI/UX)을 미리 설계해서 피드백을 주고받을 수 있습니다.기획 단계에서는 기능 요구사항이 현재 서비스 구조와 잘 어울리는지, 무엇이 가능하고 무엇이 하기 어려운지 등을 미리 잘 정해두어야 합니다. 그래야 개발 도중에 뒤엎는 일이 적기 때문입니다. 프론트엔드 엔지니어는 기획 단계의 요구사항을 잘 파악한 뒤에, 새로 기능을 개발하는 데 있어서의 제약사항이나 기존 구조에 대한 변경사항 등의 디테일을 백엔드 엔지니어와 함께 논의하면서 자세하게 정의해 나갑니다. 따라서 다른 팀의 사람들과 소통하는 능력은 프론트엔드 엔지니어에게 특히 중요한 역량이라고 할 수 있습니다.기획 단계에서 주고받은 논의 결과는 엘리스의 위키 페이지에 정리되고, 이슈 관리 도구인 Jira에 등록됩니다. 엘리스의 모든 팀원들은 위키 페이지와 Jira를 통해서 논의된 결과를 확인하고 일의 진행 상황을 파악하게 됩니다.주 사용 도구: Slack, Google Presentation, Confluence Wiki, Jira디자인 단계기능 개발에 필요한 각 페이지의 디자인이 고수준(High Fidelity)으로 만들어지는 단계입니다. 자세한 디자인에 들어가보고 나서야 파악되는 문제도 있기 때문에 디자인 단계에서도 기획에 대한 논의와 수정은 계속됩니다.디자인 단계에서의 논의 역시 Slack 채널에서 이루어집니다. 프론트엔드 팀과 디자인 팀은 온라인에서 디자인 페이지를 함께 보며 디자인에 대한 논의를 진행합니다.엘리스 디자인 팀에서는 주로 Sketch로 페이지 디자인을 합니다. Sketch로 디자인이 되고 나면 페이지 단위로 Invision에 업로드되는데, Invision에서는 다른 페이지로 넘어가는 링크뿐만 아니라 페이지 안에서의 인터랙션(스크롤 내리기, 클릭하기 등.)도 어느 정도 표현할 수 있습니다. 또한 각 요소의 색깔, 크기, 다른 요소와의 간격 등을 개발자가 볼 수 있어서 이를 토대로 페이지를 구현하게 됩니다.Invision에 업로드된 헬프센터 페이지 디자인새로운 페이지를 만들 때 중요한 것 중 하나는 기존 페이지에서 사용자가 경험했던 것을 비슷하게(Consistent) 유지하는 것입니다. 이는 사용자 경험 측면에서도 좋고, 엔지니어 입장에서도 비슷하지만 조금 다른 코드를 자꾸 만들 필요가 없어서 좋습니다. 엘리스 프론트엔드 팀에서는 일관성 있는 디자인을 돕기 위해 비슷한 상황에서 쓰이는 요소들을 모듈화하여 가져다 쓸 수 있는 elice-blocks라는 것을 만들었습니다.elice-blocks의 버튼에 대한 스타일 가이드실제 elice-blocks의 다양한 종류 button들이 구현된 예시요즘은 디자인 팀에서 elice-blocks를 최대한 활용하여 페이지 디자인을 하기 때문에 전보다 코드 품질도 올라가고 개발 속도도 더 빨라졌습니다.새로운 페이지에 대한 디자인이 나오면 프론트엔드 팀과 디자인 팀은 Slack에서 스크린 공유를 통해 Invision 페이지를 함께 보며 elice-blocks가 어떻게 사용되었고 어떻게 업데이트되어야 하는지도 논의합니다.주 사용 도구: Slack, Sketch, Invision구현 단계Jira에 기술된 기능 요구사항과 Invision 페이지를 보며 실제 코딩을 하는 단계입니다. 기획과 디자인 단계에서 충분한 논의가 되었다면 구현 단계에서 걸리는 시간이 많지 않을 수도 있습니다.현재 엘리스 아카데미에서 사용되고 있는 헬프센터의 모습현재 프론트엔드 팀은 3명뿐이라서 보통은 한 사람이 기능 하나씩을 맡아서 개발합니다. 이렇게 할 경우 개발 속도는 좀 빨라질 수 있으나 코드의 품질과 안정성이 떨어질 수 있다는 단점이 있습니다. 이를 보완하기 위해 각자가 할 일을 하면서도 짧은 시간 페어 프로그래밍을 하기도 하고, 완료된 기능에 대해서는 코드 리뷰를 진행합니다.페어 프로그래밍 역시 원격 상황에서 이루어집니다. 하지만 원격으로 안정적인 진행이 쉽지는 않았는데요, 여러 가지를 시도해본 결과 가장 안정적인 것은 Slack으로 화상채팅을 하면서 TeamViwer로 호스트의 컴퓨터를 함께 컨트롤하는 것이었습니다. 3명의 팀원 모두가 함께 진행한 적도 있었는데 무척 재미있더군요.코드 리뷰는 방대한 기능을 개발했을 경우에 팀 차원에서의 리뷰를 위한 화상 회의를 통해 진행됩니다. 또는 해당 기능을 이용하는 개발을 페어로 하기도 합니다. 기본적으로는 엘리스에서 소스코드 관리 도구로 사용하는 Gitlab 안에서 코드 리뷰가 이루어집니다.코드 리뷰 이외에 코드 품질을 높이는 비교적 쉬운 방법 중 하나는 팀의 코딩 스타일 가이드를 잘 정하고 이를 따르는 것입니다. 프론트엔드 팀은 Airbnb의 Javascript 스타일 가이드를 입맛에 맞게 수정해서 사용해왔습니다. 지금은 이를 좀 더 엄밀하게 적용할 필요성을 느껴 Javascript에 대해서는 eslint를, CSS에 대해서는 scss-lint를 이용하여 스타일을 맞추고 있습니다. 이 중 eslint는 후술할 테스트 단계에서도 사용됩니다.참고로 엘리스 프론트엔드는 React 로 구현되어 있는데 페이스북에서 React를 내놓은 아주 초반부터 React를 사용해왔습니다. 그래서 React의 최신 기술이 아닌 오래된 레거시 코드라고 할 만한 부분이 꽤 많습니다. 신규 기능 개발과 더불어 이전 코드를 리팩토링하고 자잘한 버그를 수정하는 것 또한 프론트엔드 엔지니어가 할 일입니다.주 사용 도구: Jira, Invision, Slack, TeamViwer, Gitlab, eslint, scss-lint테스트 단계구현된 기능이 실제로 사용자에게 전달되기 전에 다양한 테스트를 거치는 단계입니다. 가장 기본적인 테스트는 엔지니어가 직접 개발하면서 여러가지 경우의 수에서 의도한 대로 작동하는지 확인하는 것입니다. 여기에 자동화 테스트와 사람이 직접 하는 테스트가 추가됩니다. 엘리스에서 수행하는 자동화 테스트의 종류는 다음과 같습니다.빌드 테스트: 코드가 에러 없이 잘 빌드되는지 확인스타일 테스트: 코드가 엘리스 프론트엔드 팀의 스타일 가이드와 잘 맞는지 확인 (eslint)유닛 테스트: 개별 기능이 잘 동작하는지 확인통합 테스트: 기능의 추가가 전체 시스템에 영향을 미치지는 않았는지 전체 시스템의 동작을 확인자동화 테스트는 Gitlab의 지속적 통합(CI, Continuous Integration) 도구에 연결해두었기 때문에 Gitlab에서 새로운 커밋이 올라오면 자동으로 해당 테스트들이 통과하는지 확인합니다. 즉 코드 리뷰를 시작하기 전에 이미 자동화 테스트는 수행된 것이라고 볼 수 있습니다. 다만 아직까지 엘리스의 코드 규모에 비해 자동화 테스트가 커버하지 못하는 부분이 많기 때문에 이것을 차차 추가해나가고 있습니다.Gitlab의 CI 파이프라인이와 같이 구현과 자동화 테스트는 단계를 나누기 모호할 정도로 긴밀하게 연결되어있지만 굳이 단계를 나눈 이유는 사람이 직접 하는 테스트 때문입니다.자동화 테스트와 리뷰가 끝난 기능은 엘리스의 베타 서버에 올리고, 이를 Slack 채널을 통해 엘리스 팀원들에게 알립니다. 그러면 기획 단계에 참여한 사람들은 베타 서버에서 구현된 기능의 실제 동작을 확인하고 최초의 요구사항을 만족하는지 확인합니다. 확인한 사항에 대한 피드백은 Slack 채널에서 이루어지고 이때 미비한 점이나 버그가 발견되었다고 하면 다시 구현 단계로 돌아가게 됩니다. 요구사항이 잘 만족되었다면 이를 해당 기능에 대한 Jira 이슈에 표시하고 그 기능은 배포가 가능한 상태가 됩니다.주 사용 도구: Slack, Gitlab, Jira배포 및 모니터링 단계구현된 기능이 포함된 버전을 실제 프로덕션 서버에 올리고 확인하지 못한 버그가 발생하지 않는지 모니터링하는 단계입니다. 엘리스는 일주일에 한 번 배포를 기본 원칙으로 하는데, 개발된 것을 목요일까지 베타 서버에 올리고 테스트를 거쳐 목요일 밤이나 금요일에 배포합니다.2017년 11월 3주차의 두 번째 배포. 모든 이슈가 Resolved 상태다.모니터링을 위해 엘리스에서 사용하고 있는 Sentry는 Google Analytics(GA)와 같은 사용자 로그 수집 도구인데, GA와 다른 점은 에러 로그에 특화되어있다는 것입니다. 사용자가 경험한 자바스크립트 에러는 사용자가 어떤 과정을 거쳐 그 에러를 경험하게 되었는지와 함께 기록되고 리포트됩니다. Sentry로 기록되는 에러를 포함하여 다른 모든 종류의 로그는 자체 개발한 elice-logger를 통해 기록되고 있습니다.또한 엘리스에서는 Intercom이라는 사용자 소통 도구를 통해 피드백을 수집합니다. 로그인한 사용자라면 누구든지 ‘문의하기’로 엘리스 운영팀에게 메시지를 보낼 수 있습니다. Intercom에서 들어온 메시지는 Slack을 통해 엘리스 팀 전체에게 공유되고, Sentry에서 들어온 메시지 또한 그렇습니다.Slack으로 사용자 문의가 들어오면 이를 확인한 후에 고쳐야 할 버그라면 수정 작업에 들어갑니다. 버그 수정은 기획-디자인 단계가 문제 제기 단계로 바뀌는 것을 제외하면 기존의 기능 개발 싸이클과 동일합니다.소프트웨어 환경 A에서 권한 B를 가진 계정으로 행동 C를 할 때 원래 예상되는 결과는 D1이지만 현재는 D2가 일어난다라는 포맷으로 문제가 제기되면 이를 개발자가 확인한 후에 문제의 심각성을 파악하여 마찬가지로 구현, 테스트, 배포 및 모니터링을 단계를 진행합니다.주 사용 도구: Jira, Sentry, Intercom, Slack마치며이번 글에서는 디지털 노마드를 꿈꾸는 회사로서 엘리스가 어떤 도구들을 이용하여 기능을 추가하고 버그를 수정하는지를 이야기했습니다. 저는 엘리스가 언젠가 겨울에는 호주에서, 여름에는 캐나다에서 개발할 수 있는 회사가 되기를 소망하고 있습니다. 원격근무가 활성화된 것으로 유명한 회사들이 외국에는 많은데(Gitlab, Basecamp 등) 한국에서는 어떤 회사들이 어떤 도구를 이용하여 디지털 노마드를 실현하고 있는지 궁금하군요.photograph by Marco Verch위와 같은 개발 과정을 잘 해나가기 위해 엘리스의 프론트엔드 엔지니어들에게 필요한 역량은 이런 것들입니다.거시적 관점에서 회사의 비전/로드맵과 현재 하는 일이 잘 맞는지 판단하기기획자 역할을 하는 사람의 의도를 파악하고 이를 토대로 백엔드 엔지니어와 소통하여 개발 스펙 산출하기엘리스 프론트엔드의 스타일 가이드와 React의 좋은 패턴을 이용하여 고품질의 코드로 기능 구현하기각자의 일하는 방식을 존중하고, 함께 하는 세션에 적극적으로 참여하기자신이 구현한 기능을 책임지고 테스트와 유지보수하기여러가지 도구를 익숙하게 사용하며, 새로운 도구를 두려워하지 않고 빠르게 학습하기elice-blocks와 같이 작지만 유용한 내부 프로젝트들을 구현하기사용자의 메시지에 귀를 기울이지만, 그것을 있는 그대로 받아들이기보다 진짜 문제를 찾아서 해결하기물론 현재 저를 포함한 엘리스 팀원들 역시 이 모든 것을 유지하고 더 잘하기 위해 열심히 노력하는 중입니다. 본인에게 이러한 역량이 있거나, 그런 주변 사람을 알거나, 함께 디지털 노마드 회사를 만들고 싶거나, 또는 이 글을 읽고 엘리스의 프론트엔드 팀에 관심이 생기셨다면 주저없이, 연락주시기 바랍니다. 읽어주셔서 감사합니다.#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개 #채용 #프론트엔드 #개발자 #리모트 #재택근무
조회수 1341

레진 기술 블로그 - 모두를 위한 설계. 레진 웹 접근성 가이드라인.

레진엔터테인먼트는 글로벌(한국, 일본, 미국) 서비스를 운영하고 있기에 다양한 사람들의 재능과 욕구에 관심이 있습니다. 우리는 웹 접근성에 관심을 기울여 조금 특별한 욕구를 가진 사람들의 문제를 해결하려고 합니다. 소수의 특별한 욕구는 모두의 욕구와 연결되어 있다고 생각하기 때문입니다.조금 특별한 욕구를 가진 사람WHO는 세계 인구의 15%에 해당하는 사람들이 장애가 있는 것으로 파악하고 있습니다. 그리고 보건복지부 장애인 실태조사에 따르면 후천적 장애 발생률은 90% 수준입니다. 이런 통계에 따르면 한 개인이 일생을 살면서 장애인이 되거나 일시적으로 장애를 체험하게 될 확률은 무려 13.5%나 됩니다.저는 적록 색약입니다. 약한 수준의 장애로 분류할 수 있죠. 채도가 낮은 상태의 적색과 녹색을 쉽게 구별하지 못합니다. 충전 중 적색이었다가 완충이 되면 초록색으로 변하는 LED가 박혀있는 전자제품은 전부 망했으면 개선하면 좋겠어요. 전 세계 남성의 8%가 색약이고, 여성은 0.5%가 색약입니다. 대부분 적록 색약이고 마크 저커버그도 적록 색약입니다. 만화가 이현세 선생님도 적록 색약이고요. 한편 색약인 사람은 빛의 밝고 어두움을 구별하는 능력이 뛰어난 것으로 밝혀져 있어 저격과 관측에 탁월한 능력을 발휘합니다. 숨어있는 저격수 빨리 찾기 게임을 해 보세요. 위장 사진 1, 위장 사진 2, 위장 사진 3. 색약인 사람이 이길 것입니다.전맹 시각장애인은 마우스 포인터와 초점을 볼 수 없으므로 키보드만을 사용해서 웹을 탐색합니다. 키보드와 음성 낭독에 의존하지만, 키보드 기능을 정말 잘 다루죠. 그래서 키보드 접근성 문제를 해결하면 시각장애인뿐만 아니라 키보드를 능숙하게 사용하는 사람들의 사용성이 높아집니다. 소수의 특별한 요구사항을 해결하는 것이 모두를 위한 설계와 연결되어 있습니다.결국, 누구에게나 특별히 다른 측면이 있고 그것을 고려할 때 "모두를 즐겁게 하라!"라는 우리의 좌우명에 한 걸음 더 가까워질 수 있다고 믿습니다.도저히 풀 수 없을 것 같은 숙제웹 접근성을 소개할 때 많이 듣는 질문이 있습니다.장애인이 우리 서비스를 이용해요?매출에 도움이 돼요?시간과 비용이 많이 필요하지 않아요?이 질문에 대한 제 대답은 다음과 같습니다.이용한다면 기쁠 것 같아요.큰 도움은 안 될 거예요.조금은 그렇죠. 하지만 반환이 있어요.레진코믹스와 같이 이미지 기반의 콘텐츠를 서비스하는데 웹 접근성을 준수하려고 노력한다는 것은 무모한 도전에 가깝습니다. 왜냐하면, 현재로서는 전맹 시각장애인 고려가 없고 논의조차 쉽지 않기 때문입니다.하지만 달에 갈 수 없다고 해서 일찌감치 체념할 필요는 없겠지요. 쉬운 문제부터 하나씩 풀어 나아가길 기대합니다. 로켓에 올라탔으니까 금방 갈 수 있지 않을까요?W3C 표준을 우리 언어로W3C에서는 WCAG 2.1이라는 웹 콘텐츠 접근성 지침을 제시하고 있고요. 국내 표준 KWCAG 2.1 또한 있습니다. 국내 표준은 W3C 표준에서 중요도가 높은 항목을 우리 언어로 정리한 것이기 때문에 결국 어떤 지침을 선택해서 따르더라도 괜찮습니다.하지만 표준 문서는 너무 장황하고 전문 용어가 많아 다양한 분야 전문성을 가진 직원들과 함께 보기에는 한계가 있다고 생각했습니다. W3C 표준을 근간으로 하되 비전문가도 15분 정도면 읽고 이해할 수 있을 만큼 정리된 문서가 필요했고 레진 웹 접근성 가이드라인 사내 표준을 제안하고 공개하게 됐습니다.의미를 전달하고 있는 이미지에 대체 텍스트를 제공한다.전경 콘텐츠와 배경은 4.5:1 이상의 명도 대비를 유지한다.화면을 400%까지 확대할 수 있다.키보드만으로 조작할 수 있다.사용할 수 있는 충분한 시간을 제공한다.발작을 유발하는 콘텐츠를 제공하지 않는다.반복되는 콘텐츠 블록을 건너뛸 수 있다.모든 문서의 제목은 고유하고 식별할 수 있다.링크와 버튼 텍스트는 콘텐츠의 목적을 알 수 있다.섹션에는 의미있는 마크업과 헤딩이 있다.문서의 휴먼 랭귀지 속성을 제공한다.문맥 변경은 예측할 수 있다.폼 콘트롤 요소에 설명을 제공한다.실수를 예방하고 정정하는 것을 돕는다.HTML 문법을 준수한다.WCAG 2.1 지침의 1.1.1 항목 예를 들어 볼게요.All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. 사용자에게 제공되는 모든 텍스트 아닌 콘텐츠는 아래 나열된 상황을 제외하고 같은 목적을 수행하는 대체 텍스트를 제공한다.원문 표현보다 아래와 같이 다듬은 표현이 좋다고 보는 것이죠.의미를 전달하고 있는 이미지에 대체 텍스트를 제공한다.물론 사내 지침은 너무 단순하게 표현했기 때문에 지침마다 ‘부연 설명, 관련 예시, 기대 효과, 관련 표준, 평가 도구’ 텍스트와 링크를 간략하게 제공하고 있습니다. 사실상 W3C 표준에 대한 링크 페이지라고 생각해도 괜찮습니다. 사실이 그런걸요.맺음말레진 웹 접근성 가이드라인은 사내 유관 부서 담당자분들께 공유하고 동의를 얻어 사내 지침으로 결정하고 공개할 수 있게 됐습니다. 긍정적으로 검토해 주신 사우님들 감사합니다.레진 웹 접근성 가이드라인은 W3C 표준을 요약한 버전에 불과하므로 누구라도 복제(Fork), 개선 요청(Pull Requests), 문제 제기(Issues)할 수 있습니다."Design for all, amuse everyone!"
조회수 1350

소프트웨어 엔지니어 용현님을 소개합니다

Read in English같이 일하고 있는 직장 동료들에 대해 얼마나 알고 계시나요? 엑스브레인처럼 작은 팀의 경우에는 함께하는 한 분 한 분이 팀 전체 분위기에 끼치는 영향이 상당하답니다. 또한, 머신러닝 툴 ‘다리아’로 저희가 꿈꾸는 데이터 사이언스계의 변혁을 일으키려면, 이를 위해 일하는 팀 또한 서로 잘 알고, 협력할 줄 알아야겠죠.각각 개성이 넘치지만, 서로 모여 엑스브레인의 매일매일을 풍족하고 즐겁게 만들어가는 팀을 소개합니다! 각 멤버들의 일상과 엑스브레인에서의 직무에 대해서도 알아보고, 또 뉴욕타임즈에 실린 “상대방과 사랑에 빠질 수 있는 36가지 질문” 중 직장 동료에게 할 수 있을 만한, 가장 흥미로운 질문들을 추려서 진행한 인터뷰를 통해 엑스브레인 팀 멤버 개개인의 색다른 매력을 만나보세요.(그렇다고 진짜로 사랑에 빠지시면 곤란합니다…)올해 8월에 합류하신 용현님은 종민님과 함께 다리아의 소프트웨어를 책임지고 있는 엑스브레인의 엔지니어이십니다. 자칭 노잼이라고 하시지만, 사실 VR의 미래와 축구에 관심이 정말 많으신 분이죠. 가끔 모니터에 코드 대신 축구게임을 띄워놓고 계신 걸 목격하기도 했답니다…액티브한 엑스브레인을 지향하는 용현님을 만나보세요!창밖을 바라보는 용현님은 무슨 생각을 하는걸까요…(궁금)안녕하세요 용현님! 엑스브레인에서의 용현님의 역할에 대해서 얘기해주세요용현: 저는 소프트웨어 엔지니어로서 종민님과 함께 소프트웨어 인프라를 개발하고 테스팅하는 역할을 하고 있습니다.용현님의 엑스브레인에서의 하루 일과는 어떻게 되나요?용현: 요즘은 점심 때쯤 나와서, 그때그때 관련된일을 합니다. 오늘은 MS SQL이라는 다른 데이터베이스에서 데이터를 가져오는 테스팅을 했습니다. 가끔은 산책을 즐기기도 하고, 주로 저녁 식사 후 작업을 하다가 퇴근합니다.용현님의 직무 중 가장 즐기는 일은?용현: 머신러닝 모듈을 클라우드 시스템에 분산처리 하기 위해서는 수진님이 개발하신 걸 스파크로 바꾸고, 코드를 보고 변형해가면서 분석해 보는게 제일 재밌는 것 같아요.반대로, 가장 하기 싫은 일은?용현: 시스템을 테스트하기 위해 환경을 구축하는 일이 가장 어렵습니다. 가끔 지시대로 해도 잘 안되는 경우가 발생하거든요.용현님 책상에 있는 물건 중 용현님을 가장 잘 대변한다고 생각하는 아이템은?용현: 책상에 있는게 별로 없어서…아마 랩탑이겠죠? 입사할 때 회사에서 제공해준 거대한 랩탑.“거대한 랩탑"어떤 계기로 소프트웨어 엔지니어가 되셨는지?용현: 원래는 전공으로 역사를 정했는데, 주변의 컴퓨터 공부를 하는 사람들을 보면서, 직접 결과물을 고안해내고 만드는 과정이 신기했어요. 내가 생각하는 대로 아웃풋을 만들 수 있다는 점이 매력적이어서요.왜 엑스브레인인가요?용현: 일단 신입 개발자로서 아직 개발되고 있는 단계의 제품 개발에 합류할 수 있는 기회를 얻고 싶었어요. ‘다리아’ 개발 과정을 초기부터 일련으로 지켜볼 수 있다는게 신기하고. 또 프로그래밍 공부를 늦게 시작한 편이라 수학적인 배경이 부족하다고 느낀 적이 많았는데, 작업을 하면서 그런 쪽으로도 많이 배울 수 있어서 좋고요.팀 내 가장 최근 합류한 멤버 중 하나로서, 용현님이 생각하시는 엑스브레인의 비전을 말해주세요.용현: 엑셀처럼 일상에서 쉽게 접하고 쓸 수 있는 머신러닝 툴의 대명사가 되는게 목표이지 않을까요?작업할 때 주로 듣는 플레이리스트 top 3 공유해 주세요용현: 코딩할 때는 주로 EDM을 듣는 편입니다. 집중이 잘되기도 하고요. Hardwell On Air이라는 스테이션을 자주 듣습니다. 최근에 나온 에픽하이 트랙도 자주 듣고 있고요.씨네마 소사이어티 때 추천하고 싶은 영화가 있다면?용현: 와치맨 (2009). 빌런이기도 한 주인공 로셱이 매우 매력적이고, 재미있습니다.10년 뒤 지금, 용현님은 어떤 모습일까요?용현: 일하는 건…지금의 모습만 유지되었으면 좋겠네요. 데드라인에 크게 쫓기지 않고, 공부도 하면서 자기계발할 시간도 갖고, 시간이 나면 친구들과 축구도 할 수 있는 사람이 되어 있었으면 좋겠어요.이 세상의 어떤 사람과도 저녁 식사를 할 수 있다면, 누구와 같이 먹고 싶나요?용현: 딱히 생각이 나지는 않지만… 주커버그? 세상에 대한 다양한 비전이 있는 거 같아서요.만약에 한 명의 엑스브레인 멤버와 식사를 해야 한다면 누구와 하실 건가요?용현: 새로 오신 정갑님과 친해질 겸 식사 같이 하고 싶네요. 이야기도 잘 하시는 것 같고 재밌을 것 같아요.유명해지고 싶나요? 어떤 방법으로요?용현: 아니요.용현님에게 “완벽한” 날이란 어떤 날인가요?용현: 일과를 끝내고 침대에 들어가서, 내일의 일을 걱정하지 않고 잠들 수 있을 정도로 보람찬 하루일 것 같아요.90살까지 살 수 있고 마지막 60년을 서른 살의 마음, 혹은 서른 살의 몸으로 살 수 있다고 해봅시다. 몸과 마음 중 어느 쪽을 택할 건가요?용현: 30살의 몸이요. 마음이란게 젊을수록 꼭 좋은 건 아닌 거 같아요.용현님의 인생에서 가장 감사하게 생각하는 것은 무엇인가요?용현: 이때까지 하고 싶은 것, 배우고 싶은 것을 할 수 있었던 배경이 아닐까요? 또 전공을 바꾼다거나 진로를 선택할 때 독립적으로 정할 수 있었던 부분…그런 특권에 감사하고 있습니다.내일 아침 눈을 떴을 때 어떤 능력이나 특성을 가지게 된다면 어떤 것이었으면 좋겠어요?용현: 하려고 마음 먹은 일을 끝까지 해나가는 행동력, 추진력!오랫동안 하고 싶었던 일이 있나요? 왜 그 일을 하지 않았나요?용현: 요리를 늘 배우고 싶었어요. 학교 다닐 때는 기숙사에 살아서 그럴 기회가 없었고.. 지금이라도 시작하고 싶네요 :)지금까지 용현님 인생에서 가장 잘해낸 일은 무엇인가요?용현: 무언갈 배우는데 최선을 다한 것일 것 같아요..학교 내에서든 밖에서든.엑스브레인에서 가장 기억에 남는 일이 있다면?용현: 주로 야외에서 했던 이벤트? “규원 산악회”라던지, 함께 축구한다던지… 팀빌딩도 되는 것 같고요.1년 뒤 갑자기 죽을 것이라는 사실을 알게 된다면 지금 용현님의 삶의 방식 중 어떤 걸 바꿀 건가요? 왜 그렇죠?용현: 요즘 푹 쉬지를 못했는데…잠을 더 많이 잘 것 같네요.상대방과 가까운 친구가 되기 위해 상대방이 나에 대해 알아야 할 것을 말해보세요.저는 성격이 무던한 편이라, 누구와도 잘 지내는 편입니다.혹시 농담의 대상으로 삼아서는 안 된다고 생각하는 것이 있다면 어떤 것들이 있을까요?용현: 약자에 관한 농담, 그리고 상대방의 약점에 관한 농담은 삼가야 된다고 봅니다 .내가 생각하는 엑스브레인의 엑기스는?용현: 자율, 배려, 배움….너무 진지한가요?#엑스브레인 #팀원소개 #팀원인터뷰 #기업문화 #조직문화 #팀원자랑
조회수 1255

깃발 올려, Git Effect!

안녕하세요, 개발 2팀에서 단아함을 맡고 있는 오연주입니다. 평소에 관심이 많았던 깃(Git)을 공부하면서 알게 된 내용들을 글로 쓰려고 합니다. ‘어떤 닝겐이 만들었나’ 궁금할 정도로 천재적인 깃은 도대체 누가 만든 것일까요? 바로 리누스 토발즈(Linus Torvalds)입니다. 이름에서부터 OS의 느낌이 가득합니다. 네, 맞습니다. 그는 리눅스(Linux)의 창시자이기도 합니다. 리누스는 말했죠. “My name is Linus, and I am your God.” 리누스 토발즈 (Linus Torvalds)그가 깃을 만들기 전에는 보통 중앙집중식 VCS(Version Control System)를 사용했었습니다. 예를 들면 다음과 같은 도구들로요. CVSSVN(Subversion)…반면에 깃은 분산 버전 관리 시스템(DVCS, Distributed Version Control System)입니다. 그렇다면 중앙집중식의 대표주자인 Subversion(VCS)에 비해 무엇이 더 좋을까요? 속도가 빠르다. snv log svn diff -rN svn commit 등 대부분의 명령어가 네트워크 연결이 되어야 실행 가능한 명령어입니다. 그러나 git push git clone 등 몇몇 명령어를 제외하고는 네트워크에 연결되어 있지 않아도 로컬에서 실행할 수 있습니다. 용량이 적다. Mozilla의 SVN Repository는 126GB인데 반해 Git Repository은 420MB입니다. 왜냐하면 해쉬, 스냅샷을 이용한 효율적인 파일 변화 관리가 가능하기 때문입니다. 브랜치를 만드는 작업이 수월하다. SVN은 diff를 전부 적용해서 파일을 생성한 뒤 네트워크에서 내려받는 반면, 깃은 스냅샷을 가리키는 링크(Commit Object)만 만들면 됩니다.어떠한 특징을 가지고 있길래 이런 차이점이 생기는 걸까요?분산 저장소로, 로컬에서도 중앙 저장소와 연결되지 않은 상태에서 지지고 볶기가 가능하다니! 여러 개의 다른 저장소를 생성할 수 있고 서로서로 연결되어 독립적으로 개발 프로젝트를 진행할 수 있고 유기적인 업데이트가 가능합니다. 델타 기법이 아닌 스냅샷 방식을 사용합니다. SVN의 경우 파일 변화를 diff로서 추적한 반면, Git은 각 시점의 파일 상태를 모두 스냅샷을 찍어 관리합니다.변화를 기억했던 기존 방식변화된 소스를 커밋할 때 스냅샷을 찍는 방식두 가지 특징을 살리려면 깃이 여타 다른 VCS와는 다른 방식으로 정보를 관리할 필요가 있습니다. 예를 들어 Revision number로 히스토리를 관리했던 Subversion으로 분산된 저장소의 히스토리를 관리하려고 하면 ‘시점 충돌’ 문제가 발생합니다.그..그려봤습니다..금융 프로젝트에 참여했을 때의 일입니다. VCS 중 H사 툴을 사용하였는데 한 소스의 버전을 받고 개발하는 과정에서 커밋의 횟수가 많아지니 중앙 저장소 입장에서는 ver 1 → ver 9로 갑자기 타임워프하는 일이 생겼습니다. 그래서 개발자 스스로 본인의 버전을 모두 삭제한 후 ver 9였던 파일을 수동으로 ver 2로 바꿔주는 것이 관례였습니다. 소스가 모두 날아가는 경우가 있어 소스 commit 과정이 공포스러웠죠. 깃은 해쉬(hash)를 이용한 정보 관리를 통해 이런 문제를 말끔하게 해결합니다.Git의 핵심, 정보 Hashing! git reset --hard 3269aecad9ffea81763a42b9fff34c76a0aa4cf0 브랜디 소스 코드를 pull 했는데 특정 시점으로 돌아가 할 일이 생겨 위의 명령어를 입력했던 적이 있습니다. 명령어로 깔끔하게 원하는 시점으로 되돌아올 수 있었죠. 뒤에 붙는 40자리의 기괴한 문자열은 바로 깃이 정보를 관리하는 데에 사용하는 해쉬값입니다. 해쉬값이 제일 많이 보이는 곳은 git log 가 아닐까 싶은데요. commit 옆에 나열된 일련번호같은 문자열이 궁금하진 않으셨나요?깃은 소스 코드를 포함해서 히스토리를 관리하는데 필요한 모든 정보를 이런 해쉬로 저장 및 관리합니다. 이 해쉬값은 40자리 16진수 숫자이며 SHA-1 알고리즘으로 생성됩니다. SHA-1 알고리즘은 보안 표준 해쉬 알고리즘 중 하나입니다. 충돌할 확률은 1 / 10^45로, 매우 매우 낮기 때문에 수많은 정보를 저장 및 관리하기에 안전하고 적합합니다. 4GHz CPU로 SHA-1 해쉬 중복값을 찾아내려면 4000년이 걸린다.앞서 SHA-1 해쉬값으로 모든 정보를 저장한다고 말씀드렸는데, 과연 어떤 정보를 어디에, 어떻게 저장하고 있는 것일까요? 각 해쉬 값은 깃이 내부적으로 저장하는 파일 이름이 되기도 하는데, 이 파일들은 .git/objects 경로에서 전부 찾아볼 수 있습니다. 해쉬값 40자리 중 앞 2자리를 디렉토리 이름으로 따고, 뒤 38자리를 파일 이름으로 지정합니다. 각 파일 안에는 서로 다른 정보가 담겨 있습니다. 해쉬값으로 표현되는 이 파일들은 정보의 종류에 따라 3가지 객체로 분류됩니다. Blob ObjectTree ObjectCommit Object폴더나 파일명이 어떤 오브젝트인지 힌트를 주지 않기 때문에 세 가지의 오브젝트 파일 내용의 캡처를 위해 복불복으로 열어봤는데요, 하나의 파일을 열 때마다 포춘쿠키를 까듯 심장이 쫄깃쫄깃했습니다. Blob Object란 실제 파일을 뜻하며, 실제 소스파일을 가지고 있는 실세 오브젝트같은 느낌입니다. Blob Object - 열어보면 내가 작성한 소스 코드가 들어있다.Tree Object 내부에는 프로젝트 구조의 각 디렉토리에 대한 정보가 담겨 있습니다. 하위에 어떤 폴더와 파일을 가지고 있는지 알려주고, 객체 해쉬 값을 저장하고 있습니다. 이 Tree Object의 제일 상위 객체는 root이며, 프로젝트의 최상위 폴더에 대한 정보를 담게 됩니다.앞서 깃은 각 시점별 스냅샷을 찍어 관리한다고 했습니다. 스냅샷을 찍는 행위는 새로운 Root Tree Object를 만들고, 각 시점에 가지고 있는 Tree Object와 Blob Object로 새로운 트리 구조를 만드는 과정입니다. Tree Object - 하위에 php라는 폴더와 README.md라는 파일이 들어있는 것을 볼 수 있다.Commit Object는 커밋 시점의 Repository Root Directory의 해쉬 값을 가지고 있는 녀석입니다. Parent는 내 커밋 전에 커밋이 누구인지를 뜻하는데요. 또한, 커밋할 때의 committer(user), commit message등의 정보도 가지고 있습니다.Commit Object - 해당 commit 시점의 root tree object와 이전 커밋, 작성자 등에 대한 정보를 담고 있다.세 종류의 객체는 깃이 분산된 Repository 간의 소스 히스토리를 쉽게 관리하도록 도와줍니다. 해쉬값으로 관리되기 때문에 특정 스냅샷에 이동하거나, 히스토리를 변경 또는 추가하는 데에 적은 리소스만 필요합니다. 또 분산된 저장소 사이에 상호 시간 순서에 대한 모호함도 해결할 수 있었습니다. 이 정도면 갓누스….깃을 공부하기 시작한 이유는 Git UI Tool을 쓰면서 습관적으로 commit, push 버튼을 눌렀기 때문입니다. 깃에 대한 이해도가 있는 상태에서 사용한다면 실수가 줄어들 거라 생각합니다. 다음 글은 Git branching Model을 다루겠습니다. ps. Git, 협업과 원활한 커뮤니케이션을 위해 알고 씁시다! 우리 함께 깃빨 받읍시다!! 참고 Scott Chacon and Ben Straub, ⌈Pro Git, 2nd Edition⌋, Apress(2014)Schneier on SecurityProbability of SHA1 collisions, stack overflowSVN 능력자를 위한 git 개념 가이드, Insub Lee, Slide Share글오연주 사원 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 8274

Node.js로 Amazon DynamoDB 사용하기

DynamoDB 로컬 설정 (다운로드 버전)실제 DynamoDB 웹 서비스에 액세스하지 않고 로컬에서 애플리케이션 작성 및 테스트를 할 수 있음1. 다운로드 링크에서 DynamoDB 무료 다운로드2. 압축 해제 후 해당 디렉터리에서 아래의 명령어로 실행java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb* Ctrl+C로 중지할 수 있고 중지하기 전까지 수신 요청을 처리함* 기본적으로 8000번 포트를 사용Node.js 용 AWS SDK 설치1. 설치npm install aws-sdk2. 실행// app.jsvar AWS = require("aws-sdk");var s3 = new AWS.S3();// 버킷 이름은 모든 S3 사용자에게 고유한 것이어야 합니다.var myBucket = "dynamodb.sample.wonny";var myKey = "myBucketKey";s3.createBucket({ Bucket: myBucket }, function(err, data) {  if (err) {    console.log(err);  } else {    params = { Bucket: myBucket, Key: myKey, Body: "Hello!" };    s3.putObject(params, function(err, data) {      if (err) {        console.log(err);      } else {        console.log("Successfully uploaded data to myBucket/myKey");      }    });  }});node app.js테이블 생성// CreateTable.jsvar AWS = require("aws-sdk");AWS.config.update({  region: "us-west-2",  endpoint: "http://localhost:8000"});var dynamodb = new AWS.DynamoDB();var params = {  TableName: "Movies",  KeySchema: [    { AttributeName: "year", KeyType: "HASH" }, // Partition key    { AttributeName: "title", KeyType: "RANGE" } // Sort key  ],  AttributeDefinitions: [    { AttributeName: "year", AttributeType: "N" },    { AttributeName: "title", AttributeType: "S" }  ],  // 다운로드 버전인 경우 아래 코드 무시  ProvisionedThroughput: {    ReadCapacityUnits: 10,    WriteCapacityUnits: 10  }};dynamodb.createTable(params, function(err, data) {  if (err) {    console.log(      "Unable to create table. Error JSON: ",      JSON.stringify(err, null, 2)    );  } else {    console.log(      "Created table. Table description JSON: ",      JSON.stringify(data, null, 2)    );  }});node CreateTable.js샘플 데이터 로드1. 이곳에서 샘플 데이터 파일 다운로드데이터 형태는 아래와 같음[    {        "year": 2013,        "title": "Rush",        "info": {            "directors": ["Ron Howard"],            "release_date": "2013-09-02T00:00:00Z",            "rating": 8.3,            "genres": [                "Action",                "Biography",                "Drama",                "Sport"            ],            "image_url": "http://ia.media-imdb.com/images/M/MV5BMTQyMDE0MTY0OV5BMl5BanBnXkFtZTcwMjI2OTI0OQ@@._V1_SX400_.jpg",            "plot": "A re-creation of the merciless 1970s rivalry between Formula One rivals James Hunt and Niki Lauda.",            "rank": 2,            "running_time_secs": 7380,            "actors": [                "Daniel Bruhl",                "Chris Hemsworth",                "Olivia Wilde"            ]        }    },    ...]- year 및 title을 Movies 테이블을 위한 기본 키 속성 값으로 사용- info의 나머지 값들은 info라는 단일 속성에 저장- JSON을 DynamoDB 속성에 저장2. 샘플 데이터 Movies 테이블에 로드// LoadData.jsvar AWS = require("aws-sdk");var fs = require("fs");AWS.config.update({  region: "us-west-2",  endpoint: "http://localhost:8000"});var docClient = new AWS.DynamoDB.DocumentClient();console.log("Importing movies info DynamoDB. Please wait.");var allMovies = JSON.parse(fs.readFileSync("moviedata.json", "utf8"));allMovies.forEach(function(movie) {  var params = {    TableName: "Moves",    Item: {      year: movie.year,      title: movie.title,      info: movie.info    }  };  docClient.put(params, function(err, data) {    if (err) {      console.error(        "Unable to add movie",        movie.title,        ". Error JSON:",        JSON.stringify(err, null, 2)      );    } else {      console.log("PutItem succeeded:", movie.title);    }  });});node LoadData.js테이블에 항목 추가// PutItem.jsvar AWS = require("aws-sdk");var fs = require("fs");AWS.config.update({  region: "us-west-2",  endpoint: "http://localhost:8000"});var docClient = new AWS.DynamoDB.DocumentClient();var table = "Movies";var year = 2017;var title = "The Big Wonny";var params = {  TableName: table,  Item: {    year: year,    title: title,    info: {      plot: "Nothing happens at all.",      rating: 0    }  }};console.log("Adding a new item...");docClient.put(params, function(err, data) {  if (err) {    console.error(      "Unable to add item. Error JSON:",      JSON.stringify(err, null, 2)    );  } else {    console.log("Added item:", JSON.stringify(data, null, 2));  }});node PutItem.js- 기본 키가 필요하므로 기본 키 (year, title) 및 info 속성 추가항목 읽기// GetItem.jsvar AWS = require("aws-sdk");var fs = require("fs");AWS.config.update({  region: "us-west-2",  endpoint: "http://localhost:8000"});var docClient = new AWS.DynamoDB.DocumentClient();var table = "Movies";var year = 2017;var title = "The Big Wonny";var params = {  TableName: table,  Key: {    year: year,    title: title  }};docClient.get(params, function(err, data) {  if (err) {    console.error(      "Unable to read item. Error JSON:",      JSON.stringify(err, null, 2)    );  } else {    console.log("GetItem succeeded:", JSON.stringify(data, null, 2));  }});node GetItem.js항목 업데이트// UpdateItem.jsvar AWS = require("aws-sdk");var fs = require("fs");AWS.config.update({  region: "us-west-2",  endpoint: "http://localhost:8000"});var docClient = new AWS.DynamoDB.DocumentClient();var table = "Movies";var year = 2017;var title = "The Big Wonny";var params = {  TableName: table,  Key: {    year: year,    title: title  },  UpdateExpression: "set info.rating = :r, info.plot=:p, info.actors=:a",  ExpressionAttributeValues: {    ":r": 5.5,    ":p": "Everything happens all at once.",    ":a": ["Larry", "Moe", "Curly"]  },  ReturnValues: "UPDATED_NEW"};console.log("Updating the item...");docClient.update(params, function(err, data) {  if (err) {    console.error(      "Unable to update item. Error JSON:",      JSON.stringify(err, null, 2)    );  } else {    console.log("UpdateItem succeeded:", JSON.stringify(data, null, 2));  }});node UpdateItem.js- 지정된 항목에 대해 수행하고자 하는 모든 업데이트를 설명하기 위해 UpdateExpression을 사용- ReturnValues 파라미터는 DynamoDB에게 업데이트된 속성("UPDATED_NEW")만 반환하도록 지시원자성 카운터 증가시키기update 메서드를 사용하여 다른 쓰기 요청을 방해하지 않으면서 기존 속성의 값을 증가시키거나 감소시킬 수 있음 (모든 쓰기 요청은 수신된 순서대로 적용)실행 시 rating 속성이 1씩 증가하는 프로그램// Increment.jsvar AWS = require("aws-sdk");var fs = require("fs");AWS.config.update({  region: "us-west-2",  endpoint: "http://localhost:8000"});var docClient = new AWS.DynamoDB.DocumentClient();var table = "Movies";var year = 2017;var title = "The Big Wonny";// Increment an atomic countervar params = {  TableName: table,  Key: {    year: year,    title: title  },  UpdateExpression: "set info.rating = info.rating + :val",  ExpressionAttributeValues: {    ":val": 1  },  ReturnValues: "UPDATED_NEW"};console.log("Updating the item...");docClient.update(params, function(err, data) {  if (err) {    console.error(      "Unable to update item. Error JSON:",      JSON.stringify(err, null, 2)    );  } else {    console.log("UpdateItem succeeded:", JSON.stringify(data, null, 2));  }});node Increment.js항목 업데이트(조건부)UpdateItem을 조건과 함께 사용하는 방법조건이 true로 평가되면 업데이트가 성공하지만 그렇지 않으면 수행되지 않음// ConditionalUpdateItem.jsvar AWS = require("aws-sdk");var fs = require("fs");AWS.config.update({  region: "us-west-2",  endpoint: "http://localhost:8000"});var docClient = new AWS.DynamoDB.DocumentClient();var table = "Movies";var year = 2017;var title = "The Big Wonny";// Increment an atomic countervar params = {  TableName: table,  Key: {    year: year,    title: title  },   UpdateExpression: "remove info.actors[0]",  ConditionExpression: "size(info.actors) > :num",  ExpressionAttributeValues: {    ":num": 3  },  ReturnValues: "UPDATED_NEW"};console.log("Attempting a conditional update...");docClient.update(params, function(err, data) {  if (err) {    console.error(      "Unable to update item. Error JSON:",      JSON.stringify(err, null, 2)    );  } else {    console.log("UpdateItem succeeded:", JSON.stringify(data, null, 2));  }});node ConditionalUpdateItem.js다음과 같이 작성하면 아래와 같은 에러 메시지가 표시 됨The conditional request failed"영화에는 3명의 배우가 있는데 배우가 3명보다 많은지를 확인하고 있어 에러가 발생다음과 같이 수정하면 정상적으로 항목이 업데이트 됨ConditionExpression: "size(info.actors) >= :num",항목 삭제// DeleteItem.jsvar AWS = require("aws-sdk");var fs = require("fs");AWS.config.update({  region: "us-west-2",  endpoint: "http://localhost:8000"});var docClient = new AWS.DynamoDB.DocumentClient();var table = "Movies";var year = 2017;var title = "The Big Wonny";var params = {  TableName: table,  Key: {    year: year,    title: title  },  ConditionExpression: "info.rating <= :val",  ExpressionAttributeValues: {    ":val": 5.0  }};console.log("Attempting a conditional delete...");docClient.delete(params, function(err, data) {  if (err) {    console.error(      "Unable to update item. Error JSON:",      JSON.stringify(err, null, 2)    );  } else {    console.log("DeleteItem succeeded:", JSON.stringify(data, null, 2));  }});node DeleteItem.js다음과 같이 작성하면 아래와 같은 에러 메시지가 표시 됨The conditional request failed특정 영화에 대한 평점이 5보다 크기 때문에 에러가 발생다음과 같이 수정하면 정상적으로 항목이 삭제 됨var params = {  TableName: table,  Key: {    year: year,    title: title  }};데이터 쿼리- 파티션 키 값을 지정해야 하며, 정렬 키는 선택 사항- 1년 동안 개봉한 모든 영화를 찾으려면 year만 지정, title을 입력하면 2014년 개봉된 "A"로 시작하는 영화를 검색하는 것과 같이 정렬 키에 대한 어떤 조건을 바탕으로 일부 영화를 검색할 수도 있음한 해 동안 개봉한 모든 영화// QueryYear.jsvar AWS = require("aws-sdk");AWS.config.update({  region: "us-west-2",  endpoint: "http://localhost:8000"});var docClient = new AWS.DynamoDB.DocumentClient();var params = {  TableName: "Movies",  KeyConditionExpression: "#yr = :yyyy",  ExpressionAttributeNames: {    "#yr": "year"  },  ExpressionAttributeValues: {    ":yyyy": 1985  }};docClient.query(params, function(err, data) {  if (err) {    console.error("Unable to query. Error JSON:", JSON.stringify(err, null, 2));  } else {    console.log("Query succeeded.");    data.Items.forEach(function(item) {      console.log(" -", item.year + ": " + item.title);    });  }});node QueryYear.jsExpressionAttributeNames는 이름을 교체함. 이를 사용하는 이유는 year가 DynamoDB에서 예약어이기 때문. KeyConditionExpression을 포함해 어떤 표현식에서도 사용할 수 없으므로 표현식 속성 이름인 #yr을 사용하여 이를 지칭ExpressionAttributeValues는 값을 교체함. 이를 사용하는 이유는 KeyConditionExpresssion을 포함해 어떤 표현식에서도 리터럴을 사용할 수 없기 때문. 표현식 속성 값인 :yyyy를 사용해 지칭* 위의 프로그램은 기본 키 속성으로 테이블을 쿼리하는 방법. DynamoDB에서 1개 이상의 보조 인덱스를 테이블에 생성하여 그 인덱스로 테이블을 쿼리하는 것과 동일한 방식으로 쿼리 작업 가능. 보조 인덱스는 키가 아닌 속성에 대한 쿼리를 허용하여 애플리케이션에 더 많은 유연성을 부여함한 해 동안 개봉한 모든ㄴ 영화 중에 특정 제목을 지닌 영화year 1992에 개봉한 영화 중에 title이 "A"부터 "L"까지의 알파벳으로 시작하는 영화를 모두 조회합니다.// QueryTitle.jsvar AWS = require("aws-sdk");AWS.config.update({  region: "us-west-2",  endpoint: "http://localhost:8000"});var docClient = new AWS.DynamoDB.DocumentClient();console.log(  "Querying for movies from 1992 - titles A-L, with genres and lead actor");var params = {  TableName: "Movies",  ProjectionExpression: "#yr, title, info.genres, info.actors[0]",  KeyConditionExpression: "#yr = :yyyy and title between :letter1 and :letter2",  ExpressionAttributeNames: {    "#yr": "year"  },  ExpressionAttributeValues: {    ":yyyy": 1992,    ":letter1": "A",    ":letter2": "L"  }};docClient.query(params, function(err, data) {  if (err) {    console.error("Unable to query. Error JSON:", JSON.stringify(err, null, 2));  } else {    console.log("Query succeeded.");    data.Items.forEach(function(item) {      console.log(        " -",        item.year + ": " + item.title + " ... " + item.info.genres + " ... ",        item.info.actors[0]      );    });  }});node QueryTtiel.js스캔테이블의 모든 항목을 읽고 테이블의 모든 데이터를 반환선택 사항인 filter_expression을 제공할 수 있으며 그 결과 기준이 일치하는 항목만 반환하지만 필터는 테이블 전체를 스캔한 후에만 적용됨// Scan.jsvar AWS = require("aws-sdk");AWS.config.update({  region: "us-west-2",  endpoint: "http://localhost:8000"});var docClient = new AWS.DynamoDB.DocumentClient();var params = {  TableName: "Movies",  ProjectionExpression: "#yr, title, info.rating",  FilterExpression: "#yr between :start_yr and :end_yr",  ExpressionAttributeNames: {    "#yr": "year"  },  ExpressionAttributeValues: {    ":start_yr": 1950,    ":end_yr": 1959  }};console.log("Scanning Movies table.");docClient.scan(params, onScan);function onScan(err, data) {  if (err) {    console.error(      "Unable to scan the table. Error JSON:",      JSON.stringify(err, null, 2)    );  } else {    // print all the movies    console.log("Scan succeeded.");    data.Items.forEach(function(movie) {      console.log(        movie.year + ": ",        movie.title,        "- rating:",        movie.info.rating      );    });    // continue scanning if we have more movies, because    // scan can retrieve a maximum of 1MB of data    if (typeof data.LastEvaluatedKey != "undefined") {      console.log("Scanning for more...");      params.ExclusiveStartKey = data.LastEvaluatedKey;      docClient.scan(params, onScan);    }  }}node Scan.jsProjectionExpression은 스캔 결과에서 원하는 속성만 지정FilterExpression은 조건을 만족하는 항목만 반환하도록 조건을 지정. 다른 항목들은 모두 무시됨테이블 삭제// DeleteTable.jsvar AWS = require("aws-sdk");AWS.config.update({  region: "us-west-2",  endpoint: "http://localhost:8000"});var dynamodb = new AWS.DynamoDB();var params = {  TableName: "Movies"};dynamodb.deleteTable(params, function(err, data) {  if (err) {    console.error(      "Unable to delete table. Error JSON:",      JSON.stringify(err, null, 2)    );  } else {    console.log(      "Deleted table. Table description JSON:",      JSON.stringify(data, null, 2)    );  }});node DeleteTable.js#트레바리 #개발자 #안드로이드 #앱개발 #Node.js #백엔드 #인사이트 #경험공유 #데이터베이스 #DB #개발 #AWS #아마존 #NoSQL 
조회수 12357

개발자가 이직에 대해 생각할 때...

‘이직’이라는 화두는 샐러리맨에게는 매우 무섭게 다가온다. 평생직장이라는 의미가 사라진 현대 시대에 있어서 직장생활 중에 많이 만나게 되는 단어이다. 더군다나, 소프트웨어 개발자들에게는 매우 일상적으로 발생한다. 그러니, 이직을 너무  두려워하지 말자. 오히려 평소에 이직에 필요한 스킬과 준비를 매우 당연하게 해야 한다.개인적으로 소프트웨어 관련 학과에서는 '이직'과 관련된 커리큘럼을 하나 만들어 두거나. 아니면, 교양과목이라도 있어야 하나 가르쳐야 한다고 생각한다.필자도 여러 기업에 입사하고 이직을 고민하는 과정을 똑같이 경험했다. 더 큰 경험으로는 기업을 창업하고 직원을 채용하고, 퇴사하는 과정도 같이 경험했다. 돌이켜 생각해 보면 직원의 입장과 중간관리자의 입장, 경영진과 최고 경영진의 입장에서의 ‘이직’을 바라보는 관점이 정말 매우 다르다.이번 이야기에서는 이런 ‘이직’의 관점을 ‘소프트웨어 개발자’의 입장에서  이야기해보자.이직이란 단어는 언제 만나게 될까? 이직이라는 단어를 머릿속에 떠올리게 되면서 당연하게 고민할 것이다. 더 좋은 조건을 제시하는 회사로 자리를 옮기거나, 또는. 현재 있는 직장에서 하는 일이 마음에 들지 않거나, 특정한 사람이나 환경 때문에도 이직이라는 단어는 언제나 떠올릴 수 있다.소프트웨어 개발자들이 이직을 고민하고  생각할 때에 어떤 부분들을 고민하고 생각해야 하는지 알아보자. 물론, 이번 이야가의 내용은 전적으로 필자의 주관적인 경험을 바탕으로 만들어진 내용들이기 때문에 매우 주관적이라는 것을 먼저 이야기해야겠다.다만, 작지 않은 경험을 적은 기업의 신입직원이었을 때부터, 벤처기업의 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가지 내용 중에 한 개 이상으로 해당되는 회사나 조직에 있다면, ‘이직’을 고려하는 것이 정말 당연하다 하겠다. 하지만, 자신의 능력과 이직에 대한 준비가 되어 있지 않다면, 어쩔 수 없다. ‘샐러리맨’의 기본자세로 돌아가서, 내 능력에 합당한 현재의 자리에 만족하는 법을 배워야 할 것이고, 처세술이나 그 조직에서 버티기 위한 정치력을 발휘해야 할 것이다. 이러한 글들은 주변 서점에 널려있으니, 그런 책 한두권 읽어보기를 권장한다.‘이직’은 소프트웨어 개발자 생활을 하면서 계속 유혹과 한계를 경험하게 할 때마다 머릿속에 떠오를 것이다. 그때에 실수하지 않고, 좋은 판단을 하기 바라며. 가장 중요한 것은 ‘후회’ 하지 않고, 이미 결정한 것은 잊어버리는 것이 속 시원하다는 것이다.마지막으로 좋은 스타트업을 골라달라고 조언하는 경우에는 다음과 같이 답한다.스타트업은 좋은 동료가 될 생각이 있을 때에 들어가라는 것이다. 스타트업은 초기 멤버로서 합류하면서 고생도 같이 하고, 이익도 같이 나누는 동업자가 되는 것이다. 샐러리맨으로써 직장을 택하는 것과는 정말 다른 것이다.물론, 스타트업이 투자를 받고, 초기 멤버가 아닌 경우에는 위에서 언급한 내용과 별로 차이가 없다고 설명할 수 있다. 어느 규모나 별로 차이가 없었다.'이직'은 소프트웨어 개발자들에게는 매번 경험하게 된다. 그리고, 그 경험을 좋은 결과로 얻기를 바란다. 그리고, 언제나 좋은 선택이  필수이며, 인생 선배나 동료에게 좋은 조언을 구해보자.

기업문화 엿볼 때, 더팀스

로그인

/