스토리 홈

인터뷰

피드

뉴스

조회수 1457

초보 창업가의 교훈

퇴사학교를 창업한지 1년이 넘었다. 3명에서 시작하여 어느새 2배가 넘는 동료들과 함께하고 있다. 삼성을 다닐 때는 100명~200명 짜리 조직에서 부서 막내 역할을 주로 했다. 당시에는 곁눈질로 훑어보던 부장님과 상무님의 입장이 잘 이해가 안 되었는데, 이제는 조금은 알 것도 같다. 리더란 정말 외로운 자리라는 것을. 그런 의미로 창업 후 1년, 아직은 초보 사업가이자 대표로서 그동안 나름대로 배운 점들을 나누고자 한다.첫째, 워크숍을 간다고 꼭 팀워크가 좋아지진 않는다. 지난 봄, 큰 맘을 먹고 창업 후 처음 제주도 워크숍을 다녀왔다. 보통 금토일 주말을 끼고 자비 부담이 있는 워크숍과는 달리, 무려 월화수라는 평일에 전액 회사 비용 부담이었다. 나는 경치 좋은 곳으로 워크숍을 다녀오면 사기도 진작되고 조직 문화도 좋아질 줄 알았다. 그러나 그것도 결국 일은 일이었다. 물론 나름대로 의미있는 시간이었지만, 결국 깨달았다. 조직문화는 한 두 번의 워크숍이나 회식으로 금방 좋아지는 게 아니라는 것을. 단발성 이벤트로 사기를 진작시키려는 것은 게으른 리더의 임시방편일 뿐.꾸준히 일상에서의 문화를 만들려는 노력이 더 중요하다.(그래도 가끔 날 좋은 날 좋은 곳에서 캐주얼한 금요일 브런치 회식 정도는 필요하다)둘째, 회사는 대표의 것이지 팀원의 것이 아니다. 많은 리더들이 착각한다. 왜 직원들이 주인 의식을 갖고 일하지 않느냐고. 그것은 당연하다. 그 직원이 회사를 창업하거나 지분을 소유한 게 아닌 이상. 주인 권리가 없는데 주인처럼 마음을 가지라고 말할 순 없다. 다만 그 사람의 성장과 책임을 위해자신이 맡은 '프로젝트'의 주인이 될 수 있도록 환경을 만들어 줘야 한다.셋째, 자율과 책임은 쌍둥이 형제이다. 많은 조직들의 병폐가 자율 없이 책임만 강요하거나 책임 없이 자율만 누리려는 것이다. 리더가 책임을 강요하려면 반드시 그에 따른 자유도 보장해야 하며, 직원 역시 자유를 누리기 위해 책임을 다하려는 문화가 형성되는 것이 가장 기본이라고 생각한다. (퇴사학교 같은 경우에는 선책임 후자율을 강조한다. 먼저 회사의 전체 비전과 방향성을 공유하고 이에 대해 개인의 비전과 성장 로드맵을 같이 그린다. 그리고 매 월간, 주간회의 때마다 각자 R&R에 기반하여 목표를 수립하고 이에 따라 약속된 납기/아웃풋을 정의하는 것을 책임의 과정이라고 본다. 물론 이렇게 매일 체계적으로 책임을 달성하고 관리하는 것이 결코 쉬운 일은 아니다. 하지만 최소한의 체계와 기준을 잡아 놓고 계속해서 지키려고 노력을 하고 있다. 다들 열심히. 대신에 그것에 대한 자율과 권한, 보상을 주는 것 역시 리더의 절대적인 책임이다.)넷째, 누군가 시켜야 하는 것이 가장 좋지 않다. 대표는 시키는 존재가 아니라, 팀원의 내적 동기를 끄집어 내주는 사람이다. 업무를 지시하거나 검사하지 말고, 개인과 회사의 비전이 겹칠 수 있도록 조정해 주는 역할을 해야 한다. (그럼에도 불구하고, 어쩔 수 없이 우리는 매 순간을 자가발전기처럼 스스로 일할 수는 없다. 그래서 리더가 '쪼아' 주는 역할로 총대를 매야 하지만, 끊임없이 자가발전할 수 있는 내적 동기를 불러일으키는 것 역시 리더의 책임이라고 해야겠다. 어렵다.)다섯째, 대표가 가장 많은 시간을 써야 하는 것은 채용과 코칭이다. 좋은 인재를 찾는 것을 업무의 1순위로 삼아야 한다. 또한 기존 인재들을 케어하고 피드백 주는 시간을 아까워하는 조직은 롱런이 힘든 것 같다. (6월 한달 중 절반 이상을 채용에만 할애한 것 같다. 그만큼 가장 중요하고 의미있는 일이라고 생각한다.또한 바쁜 업무에 치여서 우선순위가 자꾸 낮아지는데, 사실 매주 개인 코칭도 더 많이 하려고 노력해야 한다.)여섯째,조직문화가 잘 구축되면 관리비용이 줄어든다.많은 조직이 커질수록 인사관리 체계 를 구축하려고 한다. 그러나 관리 통제에 집중할수록 더 복잡한 구성원들의 관리 비용만 증대된다. 눈에 보이지 않는 그 회사만의 조직문화를 정의하고 공유하며, 거기에 맞는 사람들을 찾는 것이 관리비용을 줄이는 왕도이다.(최근의 채용 과정을 겪으면서 퇴사학교 역시 조직문화를 명문화하고 공유하려고 노력중이다. 사람이 한 명 늘어나는 것 조차도, 조직문화가 없다면 비용이 너무 커지는 것 같다.)일곱째, 야근을 안할수록 잘된다고 믿어야 한다. 필자 역시 창업 초기이다 보니 업무량이 매우 많다. 하지만 한 가지 원칙은 분명히 갈수록 야근을 줄이고 업무효율을 높이는 방향으로 가야 성장할 수 있다는 점이다. 고효율 고부가가치 방향으로 사업을 끌고가기 위해서는 여유와 휴식 시간을 더 많이 확보해야 한다. (이건 솔직히 아직 완전히 달성하고 있지 못하다. 아니 사실 거의 각자 집에서 밀린 일들을 하는 것 같다. 갓난 아기일 때는 손이 많이 가기 때문에 24시간 붙어서 보살펴야 하지만, 아이가 걷고 자라고 스스로 먹고 쌀 줄 알게 되면 이제 손이 줄어들겠지.. 그렇게 믿고 있다. 얼렁 회사를 키워서 스스로 돌아가게 만들자. ㅠ ㅠ)여덞째, 리더에게 가장 중요한 덕목은 '합리성'이라고 생각한다. 리더는 기본적으로 매 순간 실시간 의사결정을 하고 모든 상황을 판단해야 하는 존재이다. 사업에 정답은 없겠지만 적어도 합리성이라는 잣대가 있어야 팀원의 신뢰도 얻고 숱한 변수들을 헤쳐 나갈 수 있는 것 같다. (내가 스스로 합리적이라고 생각한다면, 아직도 나는 합리적이지 않은 것 같다. 합리적이라고 생각하는 것 역시 아직은 오만인 것 같다..)그런 의미에서 필자가 좋아하는 말은 '모든 건 리더 탓'이다. 예전에 상무님과 사장님을 보며, 또 나라의 리더들을 보며 모든 건 리더 탓이라고 말했었는데, 이제 와서 내가 대표라고 그 말이 바뀔 수는 없다. 리더는 모든 권한과 정보, 책임을 쥐고 있는 존재이다. 그런 리더가 남 탓을 한다면 그것보다 바보같은 일은 없다.http://www.hankookilbo.com/v/f825f431ee0744a38a98effaebd088ba최근 한국일보 칼럼에 쓴 내용입니다.위에는 이렇게 썼지만, 사실 리더란 자리가 많이 외롭습니다. 팔로워의 자리 역시 많은 고충이 있는 것을 알기에 리더의 외로움은 2순위로 생각하고 있습니다.그래도 가끔은 리더도 찡찡거리고 싶을 때가 있겠지요. 그런 의미로 조만간 <초보 창업가들을 위한 찡찡이의 날>을 한 번 만들어 볼까 합니다.#퇴사학교 #고민 #성장 #초기창업 #창업자 #스타트업 #스타트업창업
조회수 3077

챗봇과 인공지능 머신러닝 ㅡ Part 1/2

스타워즈를 보신 분이라면 거기에 나오는 난쟁이 로봇 R2D2와 키다리 로봇 C3P0를 아실 것이다. 친근한 R2D2는 전자음을 조정해 인간과 대화를 하며 주로 말 잘하고 박식한 로봇인 C3P0가 통역을 해준다.이런 충실하면서 똑똑한 친구들이 옆에서 항상 나를 도와준다면 어떨까? 정말 좋을 것이다. 만약 매일 보는 스마트폰 안에서도 나의 질문에 답해주는 이런 고마운 친구들이 있다면 얼마나 좋을까? 이런 저런 생각을 하다보면 우리는 대화형 로봇의 필요성을 느낀다.챗봇(Chatbot)이란?챗봇의 정의는 “대화형 인터페이스 상에서 규칙 또는 지능으로 유저와 소통하는 서비스”이다. 이 말을 하나하나 풀어보자.먼저, 대화형 인터페이스란 뭐지? 어렵다. 쉽게 설명해 보자. 인터페이스는 사람과 컴퓨터를 연결하는 장치라고 한다. 역시 어렵다. 아! 그냥 스마트폰 앱으로 보면 된다. 그럼 소통한다는 말은 대화한다는 것이므로 스마트폰 앱에서 일방향이 아닌 양방향이 가능하다는 얘기다. 어! 이상하다. 양방향이라면 나의 말에 응대하는 로봇은 뭐로 움직이는 거지? 궁금하다. 누가 일정한 규칙으로 만들어 논건지 아니면 우리처럼 지능이 있는 건지. 지능이 있다면 그런 지능은 뭐지? 점차 우리는 자연스럽게 인공지능에 다가간다.인공지능(Artificial Intelligence)이라는 용어는 1956년 미국 다트머스의 한 학회에서 존 매카시가 처음 사용했다고 한다. 원래 인공지능은 소프트웨어인 정신을 말하고 로봇은 하드웨어인 육체를 말하는 것이지만 정신없이 육체가 존재할 수 없는 것처럼 로봇을 얘기하면 당연히 인공지능은 따라간다.학자들은 인공지능을 강(强)인공지능과 약(弱)인공지능으로 구분한다. 간단히 얘기하면 강인공지능이란 자의식이 있는 인간에 가까운 지능이고 약인공지능은 자의식이 없다. 자아가 없으며, 명령받은 일만을 수행한다. IBM의 왓슨(Watson), 작년에 인공지능의 붐을 가져온 구글의 알파고(Alpha-GO) 등은 모두 약인공지능이다. 이런 인공지능을 구현하는 기술은 무엇인가? 바로 기계한테 학습을 시키는 머신러닝(Machine Learning)이다.1959년 아서 사무엘은 머신러닝을 "기계가 일일이 코드로 명시하지 않은 동작을 데이터로 부터 학습하여 실행할 수 있도록 하는 알고리즘을 개발하는 연구 분야"라고 정의했다. 여기서 학습이란, 입력 값을 받아 결과 값을 내는 모델을 만드는 표현과 표현을 통해 주어진 업무가 얼마나 잘 수행됐는지 알아보는 평가, 그리고 평가에서 설정한 기준을 찾는 최적화로 구성된 일련의 과정을 말한다. 중요한건 우리가 시키지 않은 일도 학습에 의해 자율적으로 처리한다는 것이다. 정말 신기하지 않은가?이제 챗봇이 뭔지 감이 잡힌다. 스마트폰 앱상에 존재하는 로봇인데, 물론 육체는 화면의 아이콘으로 밖엔 안보이지만 인공지능을 가지고 머신러닝에 의해 동작을 하면서 우리와 대화를 하는 그분. 그렇다면 이제 남은 건 이분의 지능이 어느 정도인지 또 얼마나 일을 잘하는 지로 판가름 난다.우리는 평생 공부를 한다. 이제는 학교를 졸업하고 나서도 항상 배워야 한다. 학습이 없다면 지능도 없다. 학습은 일일이 지도받는 지도학습과 알아서 공부하는 자율학습이 있다. 알아서 공부하려면 먼저 머리에 지식이 많아야 한다. 역시 기계도 사람과 비슷하게 배운다.  다음시간엔 챗봇에게 학습을 시켜 지능을 가지게 하는 방법에 대해 알아본다.> Part 2에서 계속
조회수 991

[블랭크코퍼레이션 상생스토리.04]전통 한과에 바질씨를 담다#소소반끼-유림푸드

제조사와 같이블랭크코퍼레이션은 좋은 기술과 제품을 보유한 제조사를 발굴하고, 그들과 함께 생활의 문제에 대해 고민하고 있습니다. 더불어 그 제품을 소비자와 더 효율적으로 연결할 수 있도록 함께 하고 있습니다. 우리의 고민이 단발성이 되지 않도록, 함께 성장할 수 있는 가치를 만들고자 노력하고 있습니다.이런 인터뷰는 처음이라며 무척 쑥스러워 하셨지만 한과에 대한 이야기하실 땐 누구보다 열정적으로 알려주신 유림푸드 김주형 대표블랭크의 식음료 브랜드 소소생활에는 눈에 띄는 다이어트 식품이 있다. 한과제조업체 유림푸드가 전통 다식제조 방법을 응용한 바질정을 개발해 만든 ‘소소반끼’가 그 주인공이다. 전통 방식을 고수해 만들던 한과가 ‘소소반끼’로 재탄생하기까지의 과정을 유림푸드 김주형 대표에게 들었다.유림푸드 로고가 들어간 조그마한 간판Q1. 유림푸드는? 1979년에 서울 종로구 창신동에서 가족기업 창신제과로 한과 사업에 첫발을 내디뎠습니다. 한과를 만들다 1997년 3월부터 유림한과로 독립해 현재 유림푸드로 사명을 변경해 사업을 이어오고 있습니다. 소소반끼를 비롯해 수제 약과, 다식, 강정, 넛츠바 등 10가지 제품을 생산합니다.Q2. 주요 제품과 특징은?전통방식의 수제제조로 제품을 만듭니다. 생산성이 좀 떨어지더라도 수작업을 고집하죠. 기계화가 필요한 부분은 받아들이되 맛과 관계된 부분에서는 수작업을 고수하고 있어요. 약 40년 동안 한과를 제조하면서 노하우를 쌓았습니다. 특히 강정과 넛츠바는 여름철이 되면 찐득찐득하게 변하기 쉬운데 이런 현상이 전혀 없는 제품을 만들고 있습니다. 일반적으로 한과 업체는 강정을 만들기 위해 물엿을 졸입니다. 그리고 강정의 형태를 유지하기 위해 다량의 설탕을 넣고, 일부 업체는 젤라틴이나 한천 같은 보조제를 넣기도 합니다. 단단한 경도를 유지하는 것이 기술이기 때문입니다. 그러나 요즘 소비자에게 딱딱하고 달달한 강정은 입맛에 맞지 않습니다. 경도는 유지되나 씹으면 쉽게 바스러지고 달지 않은, 쿠키 같은 식감의 넛츠바를 만들었습니다.공장에 들어가면 바로 깨끗하게 잘 정리된 기계들이 있는데 이렇게 깨끗하게 잘 관리되어 한과업체에서는 드물게 HACCP 인증을 받을 수 있었다.전통방식의 수제제조로 제품을 만듭니다.생산성이 좀 떨어지더라도 수작업을 고집하죠.기계화가 필요한 부분은 받아들이되 맛과 관계된 부분에서는수작업을 고수하고 있어요.반죽기계를 지나 다른 방으로 들어가니 많은 직원분들과 함께 한과를 제조 중에 있었다.많은 직원분들이 바쁘게 한과 생산에 몰두하고 있다.Q3. 같이 일하게 된 과정은? 전통 한과 시장의 주요 고객층은 60대 이상 노년층입니다. 젊은 세대의 눈높이에 맞지 않아 소위 ‘잊혀져 가는 식품’, 제사 때나 먹는 맛없고 비싼 음식으로 전락하고 말았습니다. 시장이 위축되다 보니 회사에도 어려움이 닥쳤습니다.그러던 중 지난해 5월경 블랭크에서 바질씨를 이용한 제품을 만들고 싶다는 의뢰가 들어왔습니다. 물에 닿으면 30배가 불어나는 바질씨의 성질을 이용해 포만감을 느낄 수 있는 제품을 만들어보자는 것이었습니다.바질씨는 성형하기 곤란한 물성을 가지고 있습니다. 반죽할 때 경화되는 속도가 빨라 캡슐에 바질씨만 넣어야 했습니다. 하지만 현행법상 의약품이 아닌 것은 캡슐에 넣을 수가 없습니다. 그래서 압력을 통해 압축하는 방식인 타정으로 만들어 달라는 요청이 있었습니다. 기존 업체에서 타정 방식으로 작업을 할 수가 없는 상황이었던 것 같습니다. 그래서 한과를 만드는 우리 회사에 의뢰가 들어온 것이죠. 그러나 바질씨는 반죽 후 20분이면 경화가 되어 타정을 할 수가 없었습니다. 이후 바질씨를 갈아 한약의 환 형태로 만들었습니다. 그러나 환 형태로 만드는 과정에서 수분에 노출되어 이미 부풀어오른 것을 반죽해야 했죠. 뱃속에서 부풀어야 하는데, 이미 부푼 것은 먹어도 효과가 없었습니다.다이어트 식품의 특성을 살려 미량의 쌀조청만으로 제품화하기까지 두 달이 걸렸습니다. 전통방식으로 제조해 특허 출원까지 따냈습니다. 만드는 것만이 전부는 아니라는 마음가짐으로 바로 HACCP 기준에 맞는 설비를 갖출 수 있게 준비했고, 2018년 4월 HACCP 인증을 받았습니다. 현재 한과업체 중 HACCP 인증을 받은 곳은 손에 꼽을 정도입니다. 소소반끼의 제품 품질을 위해 별도로 설치한 조명.Q4. 시장의 반응은?소소반끼 첫 출시 때 5,000세트 정도를 납품했습니다. 시장 반응은 그야말로 폭발적이었습니다. 첫 납품 후 일주일도 채 안돼 3만개의 추가 발주가 들어왔습니다. 한과 특성상 명절이 아닐 때는 한가했는데, 일이 크게 늘어나 즐거운 비명을 질렀죠. 주야간 3교대로 24시간 작업을 돌려 물량을 맞췄습니다. 인력이 부족해 소분을 할 여력이 없어 평소 친분이 있던 업체인 정과원의 도움을 받기도 했습니다. 현재는 자체적으로 설비를 선진화하여 HACCP 인증을 취득했고, 인력 확충을 통해 유림푸드 자체적으로 생산 및 소분까지 완제품을 만들고 있습니다.소소반끼 출시 이후 34만개를 생산해 약 34억원의 매출을 기록했습니다. 블랭크와 협업한 뒤 매출이 40% 정도 급성장했습니다.마침 한쪽에서는 소소반끼의 제품 포장이 이루어지고 있다. 이 기계는 불순물 검출기로 HACCP인증 기준 이상으로 준비한 기계라고 한다.Q5. 어떤 점이 달랐는지?HACCP 인증 설비를 갖추기 위해 기계를 장만할 때 블랭크가 큰 도움이 됐습니다. 기계 값이 한두 푼이 아닌데 블랭크의 선결제로 무사히 HACCP 인증을 받을 수 있었습니다. 블랭크는 ‘안 될 것 같은 것’을 ‘되게 하는’ 힘이 있습니다. 특히 요즘 젊은 층의 니즈에 부합하는 SNS를 통한 마케팅은 탁월하다고 생각합니다. 저희 업무는 한과 특성상 명절에 주로 작업을 하고 평소에는 한가한 편이었습니다. 이제는 성수기가 아니어도 쉬지 않고 작업할 수 있게 돼 회사 운영에 큰 도움이 되고 있습니다.식품업계에서 오래 종사하다 보니 ‘이건 이래서 안 될 거야’라는 나름의 저지선이 있었습니다. 그런데 감각적이고 도전 정신 넘치는 블랭크의 모습을 옆에서 지켜보면서 나도 뭔가 전통 한과에 새로운 것을 접목해야겠다는 도전 의식이 생겼습니다. 한과가 기존 것을 답습하는 것이 아니라 서양의 수많은 식품과 비교해도 경쟁력을 가질 수 있도록 발전시켜 나가고 싶습니다. 새로운 세대의 기호에 맞춰 한과 제품을 현대화하는 작업에 심혈을 기울이게 됐습니다. 전통 제품만이 아니라 우수한 건강식품으로 제품군을 넓혀 나가고자 합니다.소소반끼의 시작은 정과원의 홍권택 차장님의 소개로 공동개발되었다.(사진왼쪽)유림푸드 김주형대표 (사진오른쪽)정과원 홍권택 차장소소생활 - 소소반끼 홈페이지블랭크 코퍼레이션은 좋은 기술력의 기업과 함께더 나은 생활을 만들어 갑니다./Lifestyle needs solutionblank.
조회수 2491

어떻게 하면 더 와 닿을까?

2017년. 대한민국 기준 스마트폰 사용 인구 비율 88%(2016년 기준).스마트폰 사용자가 늘어난 만큼 스마트폰의 앱을 통해 손쉽게 상품을 구매하는 고객의 비율 또한 현저히 늘어났습니다. 이러한 현상은 새롭게 몇 가지의 포지션들에 주목하게 되었는데요. 그중 하나가 바로 '컨텐츠 디자인'입니다. 오프라인 또는 웹으로만 만날 수 있던 상품들을 이제는 앱으로 언제 어디서든 구매할 수 있게 되면서 그 상품을 매력적으로 보여주기 위한 '컨텐츠 디자인'의 영역이 너무나도 중요해진 것이죠.해서 이 글에서는 더욱 데일리스럽고, 고객에게 가독성이 좋은 '컨텐츠'를 전달하기 위해 노력하는 우리의 노력(!)을 보여드리려 합니다.문제의 시초다양한 형태로 표현되던 이벤트 페이지약 1여 년 전.. 위에 보시는 바와 같이 일관성 없이 과도하게 정보전달을 하고자 하는 성격이 컨텐츠에 녹아있었습니다. 더군다나 그렇다 한 데일리만의 일관성 있는 스타일도 없었죠. 해서 우리가 정말 고객에게 전달하고자 하는 방향이 무엇인지 생각하게 됩니다.데일리호텔 Creative LAB의 첫 번째 글(https://www.theteams.kr/teams/865/post/64504) '로고 제작기'에서도 확인할 수 있듯이 '더 나은 하루, 더 나은 삶을 위해'라는 사명 아래 '라이프 컨시어지 데일리'로 거듭나고자 하는 것이 우리의 목표였습니다. 해서 우리가 이 상품을 왜 추천하려 하는지의 감성적인 메시지와 그를 충분히 녹여낼 수 있는 부드러운 톤의 컨텐츠가 필요하다고 생각이 들었죠.컨텐츠 디자인첫 번째 리뉴얼.이벤트 페이지 첫번째 리뉴얼위 내용을 반영하여 이 같은 결과물이 나왔습니다. 기존보다는 훨씬 '라이프 컨시어지'에 가까운 성격의 컨텐츠 였지만 아직까지도 정보전달이 약하다는 피드백을 많이 받았죠. 그 이유는 바로 '가독성' 때문이었습니다. 첫 번째 리뉴얼을 진행할 당시 '가독성'의 영역보다는 비주얼을 좋게 개선해야 한다는 사명감 때문에 '심미성'에만 크게 신경을 쓰게 되어 디테일한 폰트 사이즈를 조정하지 못했던 이슈였습니다.때에 따라 달랐던 업장 설명 형태또한, 컨텐츠의 메인과 상단 부분은 개선이 되었다 쳐도 업장 설명 내용의 형태는 프로모션 성격에 따라 혹은 작업자의 취향에 따라 항상 변경되는 것도 큰 이슈였죠.더 나은 개선두 번째 리뉴얼.피드백에 힘입어, 폰트 사이즈와 컨텐츠 내에 적용되는 UI를 보완하는 두 번째 리뉴얼을 진행합니다. 분명 모니터에서 작업할 때는 충분히 크게 보이던 폰트 사이즈가 모바일로 확인했을 때는 작게 보였던 이슈를 해결하기 위해 폰트 사이즈 규정이 필요했습니다.그리고 앱 내에 들어가는 컨텐츠 디자인도 곧 UI의 일부이기 때문에 데일리호텔 앱 내에 사용되는 UI의 가이드를 반영해야 한다는 필요성을 느꼈습니다.실제 앱 구동시 UI개선된 이벤트 페이지 내의 업장 설명 부분이미지에서 확인할 수 있듯이 폰트 사이즈뿐만 아니라 업장과 업장 사이의 여백 부분과 CTA 버튼의 라운딩, 사이즈 등 디테일한 부분도 앱의 UI와 통일시켰죠. 이런 개선을 통해 앱을 사용하다가 이벤트 페이지로 들어왔을 때의 일관성을 유지시키고, 구매로 이어지는 경로의 어색함을 완충시켰습니다.현재 사용되어지는 컨텐츠 디자인의 톤앤매너더불어 앱내에서 고가의 호텔을 다루고 있기 때문에 진중하게 보다는 호텔도 쉽게 접할 수 있다는 느낌을 주기 위해서 톤도 한 층 밝게 리뉴얼 하였습니다.끝난 게끝난 게 아니다.말 그대로 끝난 게 끝난 게 아닙니다. 앞으로도 계속해서 고객의 새로운 니즈는 생길 것이고 그 니즈를 충족시킬 수 있도록 데일리는 끝없이 많은 부분을 업데이트하고 리뉴얼해야 할 것입니다.단순히 시각적으로 보기 좋은 디자인이 아니라, 사용자의 입장에서 이해하기 쉽고 편리한 디자인을 할 수 있도록 계속해서 노력하겠습니다! 감사합니다 :)기획/진행 : Creative팀작성자 : Creative팀 Blair Ahn#데일리 #데일리호텔 #디자인 #디자이너 #디자인팀 #고객중심 #인사이트 #경험공유 #후기 #일지
조회수 2908

타다 클라이언트 개발기

앞서 종합 모빌리티 플랫폼인 타다의 시스템 설계를 위한 많은 고민과 기술적 결정들에 대해서 서버팀에서 소개한 바 있습니다. 이번 글에서는 타다 서비스를 출시하기까지 타다 모바일 클라이언트를 개발하는 과정에서 내린 클라이언트 팀의 전략적 결정들과, 타다 클라이언트를 개발하는데 사용한 기술들을 공유합니다.시작 전 상황3달 반의 개발 기간: 타다는 VCNC가 SOCAR에 인수되면서 개발하게 된 서비스입니다. 빠르게 시장에 뛰어들어서 선점하는 것이 무엇보다 중요했기에 시간과의 싸움은 필수적이었습니다. 프로젝트는 6월에 시작되었고 1.0 출시는 추석 연휴 직전인 9월 중순으로 결정되었습니다. VCNC에서 오프라인 운영은 처음이었기 때문에 차량을 실제로 운행해보면서 사용성 경험을 테스트할 필요가 있었습니다. 그래서 8월 초에 사내 테스트용 알파 버전을 출시하기로 했습니다.클라이언트 팀 통합: 비트윈 때는 Android/iOS 팀이 나뉘어 있었습니다. 회사 인수 과정에서 발생한 조직 개편으로 인해 타다 클라이언트 개발자는 5명으로 이루어졌습니다. 전부터 다른 OS 개발도 경험하고 싶던 적극적이고 열정적인 5명의 멤버들은 과감하게 팀을 통합해서 Android/iOS을 함께 개발하기로 했습니다.3개의 앱 개발: 타다의 서비스를 위해서는 Android/iOS, 라이더/드라이버 총 4개의 앱을 제작해야 합니다. 하지만 시간과 일정을 고려했을 때 4개의 앱을 다 제작하기는 무리라고 판단을 했습니다. iOS에서는 내비게이션 앱을 사용 중에 드라이버 앱으로 손쉽게 전환하는 기능을 제공할 수 없고 내비게이션 앱으로 경로 안내를 요청하는 것도 제한적이기 때문에 iOS 드라이버 앱은 제작하지 않기로 했습니다.무에서 시작한 프로젝트: 타다는 코드 베이스가 없는 empty repository에서 시작했습니다. 언어도 바뀌었고 레거시 코드와도 엮이고 싶지 않았기 때문에 비트윈에서 어떠한 라이브러리도 가져오지 않고 전부 새로 만들기로 했습니다.클라이언트 팀의 5명의 정예 용사들. by Sam코드 아키텍처 - RIBs프로젝트가 시작되고 기획이 진행되는 동안 3주의 시간을 기반 작업에 쓰기로 했습니다. 가장 먼저 진행한 것은 코드 아키텍처 정하기입니다. 당시에 제가 SAA(Single-Activity Application)에 관심을 가지고 있었는데, 때마침 Google I/O 2018의 세션 중 Modern Android development: Android Jetpack, Kotlin, and more 에서도 비슷한 언급이 나와서 팀에 제안했고, 본격적으로 조사를 해보았습니다. 팀원들이 조사를 진행해보니 Uber, Lyft, Grab 등 굴지의 모빌리티 서비스 회사들이 전부 SAA 기반으로 앱을 개발했다는 것을 알게 되었습니다. 무거운 리소스인 지도를 중심으로 화면이 구성되기에 반복적인 지도 리소스 할당/해제를 피하기 위한 필연적인 선택으로 보입니다. 큰 기업들이 수년간 서비스를 하며 문제를 느끼고 내린 선택인 만큼 저희도 따라가기로 결정했습니다. 비트윈 때 Activity Stack으로 인해 굉장히 고통을 겪은 적이 있는지라 SAA를 원하는 공감대도 있었고요.SAA로 개발을 하기로 정한 이후에는 어떤 프레임워크를 사용해서 개발할지를 고민했습니다. 여러 개의 오픈소스를 비교할 때 Android/iOS 간의 통일된 아키텍처로 개발할 수 있는지를 가장 중점적으로 보았습니다. 대부분의 팀원이 한쪽 OS에만 익숙하기 때문에 초보임에도 빠르게 적응하고 개발하려면 비즈니스 로직을 구현하는 부분이 통일되어 있어야 한다고 생각했습니다. Uber의 RIBs는 저희의 이런 요구를 가장 잘 충족했습니다. 거기에 데이터의 scope와 전달 방식 명확해서 side-effect 없이 개발할 수 있다는 점, 그로 인해 효율적으로 협업이 가능하고 여러명이 개발한 RIB 을 레고 조립하듯 합쳐서 기능을 완성할 수 있다는 점에서 RIBs를 선택하게 되었습니다.RIBs는 아키텍처를 이해하는 것 자체가 굉장히 난해합니다. 오픈소스 상으로 공개가 되지 않은 부분들도 있어서 저희의 입맛에 맞게 변형하는 데 매우 많은 시간을 할애했습니다. RIBs와 관련한 내용은 Nate(김남현)가 Let'Swift 2018에서 발표한 RxRIBs, Multiplatform architecture with Rx 의 영상 및 발표자료를 참조하세요.추후 RIBs를 상세하게 다루는 포스팅을 해보도록 하겠습니다.서버와의 통신 프로토콜새로운 서버 API가 생길 때마다 해당 API의 명세를 문서화하고 전달하는 것은 굉장히 불편한 일입니다. 또한 문서를 작성할 때나 클라이언트에서 모델 클래스를 생성할 때 오타가 발생할 수도 있습니다. 타다에서는 서버 클라이언트 간 API 규약을 Protocol Buffer를 사용해서 단일화된 방법으로 정의하고 자동화하기로 했습니다. 모든 API의 url은 .proto 파일 이름으로 정형화되어 있고 POST body로 Params 객체를 JSON으로 serialization 해서 보내면 Result JSON이 응답으로 옵니다. 서버가 새로운 API를 개발할 때 .proto 파일만 push 하면 클라이언트에서 스크립트를 돌려서 Model 객체를 생성하고 해당 객체를 사용해서 호출만 하면 되는 아주 간단하고 편한 방식입니다.참고로 타다의 서버군에 대한 설명은 타다 시스템 아키텍처에 기술되어 있습니다.기반 작업타다는 빈 repository에서 시작한 깔끔한 프로젝트였기 때문에 Base 코드와 내부 라이브러리들을 전부 새로 개발했습니다.API Controller, gRPC Controller서버와의 통신에 필요한 모듈들을 개발했습니다. 모든 API는 Rx의 Single과 Completable로 wrapping 되어 있습니다.RIBs가장 자주 사용하는 Router 패턴들을 wrapping.Android에서 구현이 공개되어 있지 않은 ScreenStack 구현.SAA이므로 Android에서 Activity가 아닌 화면 단위의 로깅을 구현.Router의 기초적인 화면 Transition을 구현RIB 뼈대 코드용 template 파일 제작Prefs(Android)/Store(iOS)타다에서는 DB를 사용하지 않고 key-value store로만 데이터를 저장합니다. Android SharedPreference와 iOS UserDefaults의 wrapper를 만들었습니다. Object를 serialization 해서 저장하는 기능, Rx 형태의 getter, cache layer, crypto layer 등이 구현되어 있습니다.Design SupportAndroid에서 drawable을 생성하지 않고 layout.xml 상에서 border, corner-radius, masking을 쉽게 설정하기 위해서 제작했습니다.ButterKtAndroid에서 View Binding 처리를 위해 개발했습니다. 비슷한 기능을 하는 Kotter Knife, Kotlin Android Extension이 가지고 있는 lazy binding 문제를 해결하고 싶었고 가능하면 Butter Knife와 달리 apt 없이 동작하는 라이브러리를 만들고 싶었습니다. 이와 관련된 저희의 생각은 여기에 David(김진형)이 상세하게 기록해 두었습니다. 코드도 공개되어 있으니 잘 활용해 보시길 바랍니다.ToolsModel CompilerPBAndK, swift-protobuf를 수정해 .proto 파일을 저희가 원하는 형태의 kotlin data class와 swift codable struct로 변환하는 스크립트를 구현했습니다.Import ResourceUI/UX 팀에서 작업해서 Google Drive File Stream으로 공유하는 리소스를 프로젝트에 sync 하는 스크립트입니다. 타다에서는 기본적으로 벡터 포맷(Android xml, iOS pdf)을 사용하고 Android에서 벡터로 표현이 안되는 이미지들은 png를 사용합니다. 또한 애니메이션을 위한 Lottie json 파일도 사용합니다. 현재는 Android 용으로만 스크립트가 구현되어 있고 리소스를 프로젝트 내의 각각의 res 폴더에 sync 하는 기능과 svg로 전달받은 벡터 파일을 Android xml 형식으로 변환하는 기능을 포함합니다.sync Lokalise타다에서는 Lokalise로 문자열 리소스를 관리합니다. strings.xml, Localizable.strings 파일로 다운받아서 프로젝트에 sync 하는 스크립트 입니다.Code Template & Settings개발 편의를 위한 간단한 Android Studio Code Template과 코드 통일성을 위한 idea settings를 공유합니다.사용된 기술들OS 공통Firebase: Analytics, Crashlytics, Messaging, Storage 등 다양한 용도로 Firebase를 활용하고 있습니다.gRPC, ProtoBuf: 서버에서 실시간 Event를 받기 위해서 사용합니다.RIBs: 타다의 기반 아키텍처 입니다.Lottie: 애니메이션 요소를 표현하기 위해 사용합니다.Semver: 앱의 버전은 Semantic Versioning 규약을 따라 정의합니다. 버전을 파싱하고 관리하기 위해서 Nate(김남현)가 Kotlin 버전과 Swift 버전의 라이브러리를 제작하고 공개했습니다.Braze: CRM(Customer Relationship Management) 툴인 Braze는 유저를 타게팅해서 전면팝업을 띄우거나 푸시 알림을 발송하기 위해 사용합니다.TeamCity, Fastlane, Beta: CI/CD를 위해서 개발 초기에는 Jenkins를 사용했습니다. 출시 대응을 빠르게 하기 위해서 parallel build 및 우선순위 컨트롤을 하고 싶었는데 Jenkins의 Parallel build가 원하는 대로 동작하지 않아서 현재는 TeamCity로 이전했습니다. Beta를 사용해서 모든 브랜치의 빌드를 배포해서 QA 팀에서 테스트할 수 있게 했습니다. 출시용 빌드는 Android의 경우 아직은 수동 업로드를 하고 있고 iOS의 경우 Fastlane으로 배포합니다.git-flow: Git branching model로는 git-flow를 사용합니다. Branch의 종류에 따라서 TeamCity에서의 빌드 우선순위가 결정됩니다.AndroidKotlin: 당연한 선택이겠죠? 타다의 모든 소스 코드는 Fork 해서 수정한 RIBs의 클래스들을 제외하면 전부 Kotlin으로 구현되어 있습니다.AndroidX: 타다 개발을 시작하는 순간에 AndroidX가 공개되었습니다. 기존 Support Library를 사용하게 되면 언젠가는 migration 해야 할 것이기 때문에 알파 버전임에도 불구하고 처음부터 사용하기로 했습니다. ConstraintLayout, PagingLibrary, Material Component, KTX 등 다양한 Component를 사용합니다.Retrofit, OkHttp: 서버와의 HTTP 통신을 위해서 사용합니다.RxJava: 클라이언트 팀은 Rx 없이는 개발할 수 없을 정도로 적극적으로 Rx를 활용합니다.AutoDispose: Rx subscription을 dispose 하기 위해서 사용합니다. 관련해서 도움이 될만한 글을 읽어보시는 것을 추천합니다. Why Not RxLifecycle?RxBinding: View 이벤트를 Observable 형태로 바꿔주는 RxBinding은 굉장히 유용합니다.Moshi: JSON 라이브러리입니다. Kotlin data class와의 호환을 위해서 Gson 대신 선택했습니다.Glide: 이미지 로딩을 위해서 사용합니다.Detekt: Kotlin을 위한 static code analyzer 입니다. Detekt의 extension을 통해 ktlint도 활용하고 있습니다.Dagger: RIBs는 Dependency injection을 기반으로 합니다. RIBs에선 어떠한 DI system이든 사용할 수 있게 Builder가 분리되어 있습니다. RIBs에서는 Dagger로 설명이 되어 있고 저희도 마찬가지로 Dagger를 사용합니다.ThreeTen Backport: Java8의 날짜 및 시간 라이브러리인 JSR-310의 Java SE6 & 7을 위한 backport 라이브러리입니다. 문자열 파싱 및 시간 연산을 위해 사용합니다.iOSSwift: Kotlin과 마찬가지로 당연한 선택입니다. Swift4.2의 CaseIterable Swift5의 Result 등 항상 최신 버전의 Swift를 사용합니다.RxSwift: 역시나 reactive programming은 필수입니다.RxCocoa, RxGesture: iOS에서도 역시 모든 뷰 이벤트는 Rx 형태로 감지합니다.SnapKit: AutoLayout DSL을 제공하므로 코드상에서 편하게 Constraint를 조절할 수 있습니다.Moya/RxSwift, Alamofire: Http 서버와의 통신을 위해 추상화된 네트워크 라이브러리인 Moya를 사용합니다. 역시나 Rx로 wrapping 된 버전을 사용하고 있습니다.Codable: Swift4부터 제공된 프로토콜로 JSON Encoding, Decoding으로 사용중입니다.Hero: RIBs의 Router가 attach/detach 될 때의 Transition을 처리하는데 이용합니다.Kingfisher: 이미지 로딩을 위해서 사용합니다.KeychainAccess: Access Token 같은 중요 정보를 안전하게 저장하기 위해 사용합니다.Swiftlint: SwiftLint는 fastlane action으로 실행해서 code validation을 합니다.출시 후의 회고짧은 시간에 여러 개의 앱을 만들기 위해서는 시간 및 인원을 아주 효율적으로 배분해야 했습니다. 각 OS의 기존 개발자들이 먼저 프로젝트 기반을 닦는 동안 나머지는 스터디를 진행했습니다. 차량 운영 경험을 쌓는 것이 알파 테스트의 목적이었으므로 일정에 맞추기 위해 드라이버 앱도 개발해야 하는 Android로만 알파 버전을 개발했습니다. 대신에 iOS 알파 버전은 서버팀 YB(김영범)가 아주 빠르게 웹앱으로 개발해주었습니다(1.0은 Native입니다.). 알파 버전의 스펙도 호출-하차까지의 시나리오 외의 다른 부가 기능은 전부 제외했습니다.회사 구성원들이 전부 처음 도전하는 분야였기에 기획을 포함해서 모두가 지속적인 변화에 대응해야 했습니다. 특히 사내 테스트를 시작한 직후 실제 운영을 해보며 깨닫고 변경한 기획 및 UX가 상당히 많았습니다. 개발적으로는 익숙하지 않은 아키텍처인 RIBs를 이해하며 개발하는 것이 생각 이상으로 난도가 높았고 개발하는 중간에도 큰 리팩터링을 여러 번 해야 해서 힘들었습니다. 이러한 이유들로 1.0 출시도 시작 전 상황에서 언급한 것보다 2주 정도 미뤄졌습니다.실제 타다 프로젝트 타임라인하지만 저희는 성공적으로 타다를 출시했습니다! 아래는 팀 내에서 출시를 회고하며 나왔던 몇몇 의견입니다.OS 간 아키텍처가 통일되어서 한 명이 같은 기능을 두 OS 전부 개발할 때 굉장히 효율적이다. 비즈니스 로직의 경우 정말로 Swift <-> Kotlin간 언어 번역을 하면 되는 정도.결과적으로 앱 개발 순서를 굉장히 잘 정했다. 한쪽을 먼저 빠르게 개발하고 문제점을 느껴보며 정비해 나가니까 프로젝트 후반부에 빠른 속도로 기능을 개발하는 데 도움이 되었다. 큰 수정을 양쪽 OS에 하지 않아도 됐던 게 좋았다.짧은 기간 개발했음에도 앱 퀄리티가 굉장히 만족스럽다. 매 상황에서 기술적 선택, 인원 배분 등 경험에서 우러나온 아주 적절한 판단들을 했다고 생각한다.각자 독립적으로 개발하던 기능들이 쉽게 합쳐지고 큰 문제없이 잘 동작하는 하나의 앱이 되는 과정이 정말 신기했다. 아키텍처 설계에 쓴 많은 시간이 결코 아깝지 않았다.마치며아직 저희가 하고 싶고 도전해야 하는 과제들은 무궁무진합니다. 그 중 간략히 몇 가지를 소개합니다.테스트 코드 작성: 시간과의 싸움 속에서 테스트 코드 작성을 지금까지 미뤄왔습니다. RIBs의 Interactor 에 구현된 비즈니스 로직은 반드시 테스트 되어야 합니다.OS 간 구조 통일: 같은 화면임에도 OS 간 작업자가 다른 경우 많은 파편화가 일어났습니다. 1순위로 RIB tree 및 Interactor의 비즈니스 로직 통일하는 작업을 진행하고 있습니다. AlertController 같은 공통적인 컴포넌트들도 최대한 포맷을 통일하려는 작업을 지속해서 진행할 예정입니다.iOS DI: RIBs에서 Android에선 Dagger를 활용해서 쉽게 Builder 구현이 가능하지만, iOS에서는 좋은 방법이 없어서 수동으로 DI를 해결하고 있었습니다. 그래서 Uber가 개발 중인 Needle을 적용하려고 관심 있게 보고 있습니다.네트워크 에러 handling 개선: 중첩돼서 뜨는 Alert를 해결하는 것, global 하게 에러를 처리하는 좋은 구조 찾기 등의 이슈가 있습니다.String Resource 관리: 개발하면서 생성하고 아직 Lokalise에 동기화하지 않은 리소스 키를 체크해서 빌드 오류를 발생시키려고 합니다. 또한 iOS에서 "some_key".localize 형태의 extension으로 번역을 코드상에서 불러오는데 key 값 오타가 나면 런타임에서만 오류를 알 수 있습니다. 따라서 String resource를 enum 형태로 관리하려고 합니다.그 외 50여 가지나 되는 팀원들이 하고 싶은 백로그 목록이 여러분을 기다리고 있습니다. 타다가 성공적으로 런칭할 수 있었던 것은 훌륭한 팀원들이 있었기 때문입니다. 앞으로 저희와 함께 좋은 서비스를 만들어 나갈 멋진 분들의 많은 관심 바랍니다.
조회수 1936

인공지능 기업에서 프로덕트 매니저로 사는 법

프로덕트 매니저(이하 PM), 프로덕트를 관리하는 사람이다. 자신이 담당하고 있는 제품 또는 서비스를 누구보다 잘 알고 있어야 하며, 경쟁 업체 및 시장 트렌드를 파악해야 하고, 실제 프로덕트를 사용할 사용자 입장에서 기획하는 역할 등을 담당한다. 그리고 기술 기업의 경우 PM이 관여하는 범위는 이보다 더 넓다. 버그 발생 시, 가장 먼저 원인을 파악한 뒤 엔지니어들과 논의해 고치고, 프로덕트로서의 매력도와 기술 관점의 매력도 사이에서 중심을 잡아야 한다.기술 기업은 해당 기술의 기본 원리에 대한 이해 및 경험이 중요하기에, 엔지니어링 경험을 보유한 PM이 많다. 인공지능(AI) 관련 업체도 마찬가지다. 최근 인공지능(AI)에 대한 관심이 커지면서 AI 분야 개발자는 물론 프로덕트 매니저에 대한 수요가 늘어나고 있는데, 문제는 AI 전공자가 많지 않으며, 관련 분야에서 경험을 쌓은 PM 역시 찾기 어렵다. 이에 스켈터랩스에서 일하고 있는 정수익 책임 프로덕트 매니저(Staff Product Manager)와 이야기를 나눴다.PM의 역할은?PM은 담당 상품/제품에 대해 마치 대표와 같은 역할을 담당한다. 비전을 제시하고, 제품 전략과 실행에 영향을 미치는 다양한 요인을 이해하고, 균형을 맞춰 나가야 하는 것이 숙명이다. 이를 위해 시장 환경에 대한 객관적인 시선과, 매니징하는 모든 과정에 있어 적절한 시기를 파악하는 것 또한 빼놓을 수 없는 과제다. 고객 접점에서, B2B/B2C를 막론하는, 그들의 목소리에 귀를 기울여 원하는 바를 찾아내고, 이를 충족시킬 수 있는 최적의 방안을 모색해야 한다. 여기서 주의해야 할 점은 몇몇 고객의 목소리를 전체 의견이라고 판단하는 오류를 피해야 한다는 것이다.또한, PM은 팀 내 소통의 중심이어야 한다. 팀원들이 서로 다른 곳을 보지 않고 한 곳을 바라볼 수 있는 공동의 목표와 비전을 제시하고, 우리가 만들려는 제품이 무엇인지를 명확하게 정의해야 한다. 이에 회사 및 팀원의 역량에 대한 파악 등은 필수다.PM은 제품의 성공 또는 실패에 대해 책임져야 한다. 부담도 있지만, 그만큼 성취감과 자부심을 느낀다.인공지능 기업의 PM은 무엇이 다른가?과거 스타트업에서 경험을 쌓은 적이 있다. 대부분의 스타트업이 그러하듯, 한 가지 제품 또는 프로젝트에 총력을 다했다. 하지만, 스켈터랩스가 추구하는 인공지능 기술은 궁극적으로 인간과 같은 혹은 특정 분야에서는 인간보다 더 나은 판단할 수 있는, 무언가를 목표로 한다. 때문에 다양한 분야에 걸쳐 심도 깊은 연구와 개발이 필요하다. 자연스럽게 제품적인 시각은 물론, 다양한 기술에 대한 이해와 넓은 시야를 갖는 것이 중요하다. 특히, 이제는 특정 전문분야로 한정할 수 없고, 잠시도 안주할 수 없는 시대에 살고 있다는 것을 실감하고 있다.현재 담당하고 있는 프로젝트에 대해 소개해달라대화형 인공지능 프로젝트를 담당하고 있다. 스켈터랩스가 집중하고 있는 대화형 인공지능의 핵심은 크게 두 가지다. 첫번째는 실제 사용하는 사용자들을 위한 사용 편의성이며, 두번째는 사람과 대화하듯 복잡한 대화에 대한 인식률이다.기술이 거듭 발전해 글로벌 업체의 대화 엔진은 각 언어별로 보편적인 인식률을 보이기 시작했다. 그렇지만, 한국어와 같은 특정 언어에 대해서는 유독 고차원의 성능을 보이지 못하는 경우가 다수 발생한다. 글로벌 업체가 겪고 있는 딜레마는 간단하다. 비즈니스적인 측면이다. 특정 언어에만 과도하게 집중한다는 것은, 보편적이지 않은 언어를 지원하기 위해 많은 자원을 쏟아야 하기 때문이다.스켈터랩스의 대화형 인공지능 프로젝트는 특정 언어에 의존적이지 않으면서, 언어별 인식률을 높이는 연구를 병행한다. 결과적으로 타사 엔진과 비교해 높은 성능을 내는 대화형 인공지능 엔진을 개발하는 성과를 거두었다.하나 더 덧붙이자면, 스켈터랩스의 대화형 인공지능 프로젝트는 룰 기반과 머신러닝의 하이브리드 형태로 구성되어 있다. 기본적으로 봇이 학습할 수 있는 데이터를 제공하되, 봇을 생성하는 단계 및 운영하는 과정에 들어가는 노력을 최소화될 수 있도록 머신러닝을 통해 최소한의 데이터만으로 대화 인식 범위를 넓힐 수 있는 것이 핵심이다. 때문에 최근 국내 대기업으로부터 대화형 인공지능 엔진 적용 문의가 계속 이어지는 상황이라, 개발에 힘을 써준 모두의 노력 결과물이라고 생각한다.올 하반기 계획은?사용자 편의성을 고려해 보다 쉽고 더 높은 퀄리티의 대화형 엔진으로 고도화하는 것이 목표다. 이를 위해 특정 도메인을 정하는 것을 시작으로, 텍스트 기반 대화뿐만 아니라 음성인식 및 Text-To-Speech 결합 등을 고려 중이다. 이를 통해 실생활에서 사용자들이 그 동안 경험하지 못한 자연스러운 UX의 대화형 인공지능 시스템을 개발하고자 한다.인공지능 기업의 PM으로 힘든 점은?인공지능에 대한 막연한 기대를 가지고 있는 고객에게 설명하고, 설득하는 것이다. 종종 인공지능이 마치 별다른 노력 없이 모든 것을 다 해결하는 요술방망이와 같다고 기대하는 고객들이 있다. 이는 굉장히 잘못된 생각이다. 흔히 말하는 '인공지능 기술 적용 제품'이 실용화되어 우리의 삶을 편하게 바꿔주기 위해서는, 반드시 '학습'이라는 과정을 거쳐야 한다. 그리고 학습을 통해 똑똑한 결과를 내놓기 위해서는 양질의 유의미한 데이터가 제공되어야 한다.본인은 인공지능 전공자도 아니고, 스켈터랩스 이전에는 인공지능 분야에서 일한 경험도 없다. 스켈터랩스의 인공지능 분야 전문가들과 같이 고민하고, 함께 호흡하면서 보폭을 맞춰가고자 노력하는 학생에 가깝다.모두가 알고 있다시피 기술은 너무나 빠른 속도로 발전하고, 우리의 경쟁자라 하는 기업들도 쉬지 않고 기술 고도화를 위해 모든 것을 쏟아 붇는다. 이들과 경쟁하며 앞서가기 위해서는 쏟아지는 새로운 정보를 보다 빨리 접하고, 어떻게 하면 스켈터랩스의 프로젝트에 효과적으로 접목할 수 있는지 고민해야 한다.앞으로 기대하는 점은 무엇인가?스켈터랩스는 인공지능 분야 전문가가 다수 모여 있는 국내 몇 없는 업체다. 이 곳에서 팀원들과 이야기하고, 프로젝트를 진행하면서, 인공지능 분야의 무한한 가능성을 실감하는 중이다. 내부에서 준비하고 있는 '인공지능이 실세상에 반영되면서 펼쳐질 놀라운 경험'을 어서 빨리 모든 사람에게 선보일 수 있기를 기대한다.이호진, 스켈터랩스 마케팅 매니저조원규 전 구글코리아 R&D총괄 사장을 주축으로 구글, 삼성, 카이스트 AI 랩 출신들로 구성된 인공지능 기술 기업 스켈터랩스에서 마케팅을 담당하고 있다#스켈터랩스 #기업문화 #인사이트 #경험공유 #조직문화 #인공지능기업 #기술기업
조회수 2958

넌 어디에 있니? 스타트업 올래?

오늘로써 2017년 상반기(주)클린그린의 신규 채용공고 마감이다.이렇게 쓰니까 꽤 거창해 보이지만,작은 스타트업이 멤버를 꼬시는 미팅 수준이다.물론,공작새처럼 한껏 꼬리날개를 펼쳐화려함으로 유혹하지는 않는다.많은 지원자분들께내일이면 결과를 고지해야 하고그에 따른 메일 초안을 작성하고 있다.누군가에게는 아쉬움이 담긴 메일을,누군가에게는 함께 해 보고 싶다는 제안을진심을 담아 한 분, 한 분께 전하고자 한다.2016년 채용 때는 준비가 미흡하여첫 만남 자리부터 횡설수설하고,떨기도 하며,밤새 고민의 연속이었다.이번 채용에서는그때보다는 좀 나은 것 같다.지원해 주신 분들과 이야기를 나누며,우리 자신을 되돌아보게 되었다.참 좋은, 탐나는 분들이 많아내부적으로 난상토론도 이루어지고,우리에게 채용 가능한 한계가너무 아쉽고 미안하기도 하더라.올해에는 성장 속도를 좀 더 올려야 하는이유를 찾았다고 할까?우리가 선택한 주요 채용 사이트는로켓펀치, 오피스엔, 더팀스였다.그 외에더 많은 채용 지원 사이트(원티드, 위시켓) 등이 있지만,이전에 채용을 수행했던 사이트들에공고를 올려놓은걸 수정 작업만 살짝 해도 되기에 선택하였다.한 가지 이유를 덧붙이자면,우리가 일일이 관리하기 어려운 점에서채용 사이트를 한정할 필요가 있었다.다른 스타트업 채용 사이트가 더 좋고, 나쁘고의문제가 아니라 그냥 익숙함과채용 업무량을 줄이고자 정한 거일 뿐!오해하지 마시라~!잡코리아나 커리어, 사람인과 같은 채용사이트의 경우,스타트업에 특화된 인재를 찾기가 어렵더라.(물론 이건 개인적인 의견!)대체적으로 스타트업 채용에 특화된 사이트들을통해 지원한 분들은주위에 스타트업 경험이 있는 지인이 있다던가,스타트업에 관심이 있다던가,스타트업의 한계와 특성에 대해 어느 정도사전 지식이 있는 편이다.채용을 하는 데 있어지인 추천/소개도 있고,프리랜서 계약 후, 채용 제안을 하는 방법도 있다.이런 방법도 있다고 넌지시 오지랖 첨언~!다시 본론으로 돌아와서...채용을 진행하는 데 있어 사전 준비가 필요하다.특히나 우리 같은 스타트업 입장에서첫 단추를 잘 끼워야 하니 더더욱 신중해져야 한다.1) 신규채용이 왜 필요한가에 대한 타당성 확보단순히 사업 확장을 위해?아니면, 기존 멤버들이 업무로드 상태라서?확실한 채용 근거가 있어야 한다.예를 들어, 우리 회사에 부족한 부분이 마케팅이라면,이것으로 어떻게 해결할 것인가에 대한 논의가 필요하다.외주를 주는 것이 나을 것인가?그럼 어떻게 관리할 것이고 예상 소요 비용은 어떠한가?외주로 얻을 수 있는 것은 무엇인가?위의 질문들에 비해 신규채용으로 얻을 수 있는 이점이더 클 때, 신규채용을 고려할 수 있다.2) 어떤 동료를 원하는가: 이 부분은 개념을 넘어선 구체적인 인재상이 필요!막연하게창의, 도전, 비전이 있는 인재상!모두가 원한다.심지어 대기업 채용 인재상에도 빠지지 않고 나온다.근면하고, 성실하고 등등등~~~~~우리가 원하는 인재는구체화되어 있어야 한다.지원자와 만나서 묻고자 하는 바를미리 공부해야 한다.좋은 지원자는 회사에 대해 찾아보고,나름 공부하고 온다.채용 담당자는 지원자에 대해 공부해야 한다.지원자가 우리 인재상에 맞는지 알려면먼저 지원서에서 그러한 흔적을 찾아내는 노력을 해야 한다.잠깐 쓴소리 하나만 하자면...이력서나 지원정보 등은 좀 미리 메모라도 해 둬라하다 못해 이름 정도는 알아두는 게 최소한의 예의다.(출처: 영화 테이큰, 리암 니슨)이 정도는 하는데...딱 거기까지만 공부하면,딱 거기까지만 알 수 있다.미리 질문을 만들어야 한다.나이라던가, 외국어 성적이라던가그런 쓸데없는 거 묻지 말고...실제적인 질문!생각할 수 있는 질문!우려되는 질문!'우리의 컨셉은 이러이러한데이걸 어떻게 고객들에게 인지 시킬 수 있을까요?''우리의 제품은 이건대이게 고객에게 어떻게 하면 구매까지 이뤄질 수 있을까요?''우리가 해결하지 못한 문제는 이거고문제 해결을 위한 방법은 무엇이 있을까요?'"우리는 언제 언제쯤 이런 이슈가 있는데어떻게 해야 할까요?"등의 질문을 산정하고 이에 맞춰어떤 직무와 어떤 세부적인 방향을 추진할 수 있는지에대하여 리스트를 작성해야 한다.창의적인 거? 근면한 거? 도전적인 거?그거 알고 싶으면 그걸 알아낼 수 있는질문을 해야 지원자도 어필할 수 있는 거지.그런 질문 하나 없이 인재상을 어떻게 알아낼 수 있는가?또한, 자연스럽게 지원자의 입에서회사에 대한 질문이 나올 수 있도록 유도해야 한다.그래야 동등한 입장에서 커뮤니케이션이 된다.그리고 협상을 할 수 있다.협상에서 진짜 구체적인 인재상을서로 짜 맞출 수 있다.(출처: MBC 무한도전, 무도탐정사무소편)실제로 대화가 자연스레 이루어지면,카페에서 수다를 나누듯이 진행된다.우리 회사에서 줄 수 있는 급여는 이 정도고,근무환경은 이렇고, 복리후생은 이런 건데...그쵸? 많이 열악하죠?근데요. 이거는 약속드릴 수 있고요.지금 우리는 이렇게 하고 있는데그게 이 때는 완료할 거라 이렇게 저렇게 블라블라~~OOO 님은 어떻게 생각하세요?그럼 이건 이렇게 하면 어떨까요? 블라블라~~~이게 더 솔직하잖아.우리 스타트업에서 원하는 인재상이라는 건열악한 조건이고, 불안정함에도 불구하고,함께 읏샤읏샤 하면서, 잘 살아보세~웃으면서 행복하게 동행할 사람 뽑는 거잖아.인재상이라는 게...한 두 번 만나서 알 수 없는추상적인 개념은 지원자에게도,채용담당자에게도 곤욕스럽다.물론,이런 개념적인 인재상이 필요 없다는 것이 아니다.개념을 잡고 상세한 계획을 잡을 수 있으니까.내가 하고자 하는 말은 단지 개념만 잡고채용을 진행하지 말라는 것이다.3) 경력자와 신입 중 누구를 원하는가스타트업은 항상 경력자에 갈증을 느낀다.능숙한 경력자가 회사에 큰 힘이 되어준다는 점은부인할 수 없는 사실이다.하지만, 경력자로 채용을 채우는 것만이 능사는 아니다.경력자가 필요한 것인지,아니면,신입이 필요한 것인지에 대한 고민이 필요하다.경력자가 합류하였을 때,우리는 무엇을 기대하고, 무슨 리스크가 있는가.신입이 합류하였을 때,우리는 무엇을 지불하고, 무엇을 얻는가.보상의 문제는 오히려 단순한 셈법이다.기존의 구성원들과 충분히 논의하였는가,어떤 변화를 예상할 수 있으며,어떤 안정을 기대할 수 있는지에어느 정도 그림을 그려야 한다.우리 회사의 경우,좀 독특한 채용규정이 있다.신입은 수습이나 인턴기간이 없고,경력자에게만 3개월 수습기간을 둔다.급여나 업무 지원은 동일하다.그 이유는 경력자의 경험과 노하우가우리 회사에 적용될 수 있는지,기존 구성원들과 잘 융합될 수 있는지를가늠하기 위한 최소한의 방침이다.역으로 신입의 경우는..,어차피 제로베이스부터 시작이라는 가정하에굳이 수습기간이 필요 없다고 만장일치로 동의하였다.대신 경력자의 경우,3개월 수습기간 이후에 연봉과 직급에 대한협상을 다시 한다.4) 시간을 줄이는 것과 늘리는 것이 부분은 3)의 주제로부터 연장선에 있다.채용에 있어서우리는 시간을 잘 계획하여야 한다.충분히 교육과 대화를 나눠서키워야 할 사람을 채용할 것인지,바로 전장에서 싸워줄 사람을 채용할 것인지에 대한기준이 섰다면,적응이라는 시간에 대하여 고민하여야 한다.설령 경력자라 하더라도,회사의 문화와 비전, 가치관을 파악하고스며드는데 최소한의 시간이 필요하다.모든 일은 처음과 끝이라는 기한을 정해서진행해야 한다.그것이 기준이 되고, 지표가 되고,정량적으로 판단할 수 있는 근거가 된다.5) 역시나 손익을 계산해야 한다.채용에 앞서 손익이 빠질 순 없다.기업활동이라는 게 결국 비용과 수익이라는외줄 타기에서 합리적인 판단이 나오는 거니까.(출처: 영화 영웅본색, 주윤발)단지 연봉이 얼마, 월 실급여가 얼마라는계산 같은걸 말하는 게 아니다.멤버가 한 명 들어오게 되면,급여뿐만 아니라 각종 부대비용이 발생한다.그리고 시간이라는 비용과재교육이라는 비용도 발생한다.우리가 예상할 수 있는 수익은 무엇일까?회사에 내재되어있던 리스크의 감소다.약점이 되던 분야에 담당할 멤버가 생기고,발생하는 회사 업무의 총량에 대한 분할의 폭이 넓어져개개인의 업무 총량이 줄어들 수 있다.그리고 그만큼 외부에서의 활동 영역이 더 넓어진다.실제로지난해의 채용을 통해 나의 활동 반경이 꽤 넓어졌고,이전에는 엄두 못 내던 업무들도 하나씩 클리어할 수 있는여력이 생겼다.사실 업무가 밀리다 보면 우선순위에서 밀린 업무들은그냥 맘 편히 포기하는 경우가 많았었다.(말이 쉬워 "맘 편히"지... 포기란 건 항상 맘이 불편하다)회사 가치를 늘리는 효과도 크다.꾸준한 고용은 외형적으로도 기업이 성장하는 지표로 사용된다.이때, 4)에서 언급된 시간과 연계하여 생각해야 한다.최소한 6개월 정도의 앞날에 대한 큰 이슈들을 예상해야 한다.우리가 외부적인 요인으로 발생하는 이슈는 알 길이 없지만,내부적으로 계획된 올 한 해의 이슈들은 예상할 수 있다.예를 들어,전시회는 언제 갈 것이고, 제품 출시는 언제이며,사무실 임대 기간은 언제까지고연장을 할 것인지 이사를 할 것인지,진행하고 있는 프로젝트는 언제 끝나는지 등에 대한시점들은 오차가 있더라도 어느 정도 알아 두어야 한다.그래야 그 시점에 맞춰 신규 멤버가무엇을 준비할 것인가,어느 타이밍에 투입될 것인가,누구와 매칭 하여 수행할 것인가,지불하는 비용은 어느 정도 일 것이고,얻을 수 있는 수익은 무엇일 건지...가늠할 수 있다.6) 그 외의 이야기: 캐주얼 미팅(면담이랄까? 면접이랄까?)에서...채용 프로세스와 결과 발표 일정 등은 꼭 말해주자.-> 면접 후, 기다리는 사람은 신경이 곤두선다.급여와 복리후생에 대해서는 확실히 말해주자.-> 나중에 달라지면, 시작부터 불신이 생긴다.서로 동등한 위치에서 협상하는 자리란 걸 잊지 말자.-> 일방적인 질문 공세가 아니라 커뮤니케이션을 하는 자리여야 한다.-> 대화의 자리가 되어야 조율/협상을 할 수 있고,면접용 컨설팅 모범답안이 아니라 지원자의 진짜 답안을 얻을 수 있다.-> 상대방도 생각할 시간을 주어야 한다.솔직하라.-> 어차피 같이 일하게 되면 알게 될 일들을 굳이 숨길 필요 없다.오히려, 문제점과 우려되는 점을 까놓고 이야기하는 것에서부터 신뢰는 형성된다.가급적이면 일대다 면접을 하지 마라.-> 무슨 줄 세우기냐? 지원자들 경쟁시키는 것도 아니고...스타트업이 시간과 인력이 부족하다고 지원자들은 모아서 만나는 거...매우 안 좋다. 그리고 그 만남에서 얻을 수 있는 답변은 의미 없는 공허의 소리.메모를 하여 기록을 남겨라.-> 나중에 지원자에 대해 기억이 안 날 수도 있다.기억을 믿지 말고 기록을 믿어라.어정쩡한 기억은 좋은 지원자를 놓치게 만든다.(이건 내 경험담이다. 진짜 반성반성초초초반성!)면접이 끝나고... 꼭 결과 메일을 보내줄 것!-> 채용을 못 하게 된 분들께 꼭 메일을 보내주되,정성을 들여 메일을 써서 보내자.-> 이왕이면 대표가 직접 보내주는 게 좋다.채용 유무와 상관없이 우리 고객이다.예의를 갖추어서 대하고, 진심으로 대할 것!더... 생각나는 게 없어서 여기까지~~!위의 사항들은실제로 창업 이후부터 시행착오를 거쳐우리가 시행하고 있는 채용 규칙이다.처음엔 지원자보다 대표인 내가덜덜 떨면서 미팅을 가졌었다.질문이 두서없었고,한 이야기 또 하기도 하고...;;;지금 이 글을 쓰면서혼자 웃고 있다.'내가 이런 글을 남기게 될 줄이야...ㅎㅎㅎ'지금 동행하고 있는 동료들은이전의 나와 첫 만남을 기억한다.평생 기억할 거라더라.너무 초짜인 티가 확~나는 대표란다.우리 멤버들에게 진심으로 감사한다.참 좋은 분들이 합류해 주셨고,그 덕분에 회사가 성장하고,내가 월급을 받고 있다.이제 곧 만나게 될 새 멤버들에게미리미리 고마움을 전한다.앞으로 잘 부탁드립니다~~!#클린그린 #스타트업 #초기창업 #팀빌딩 #초기멤버 #인사이트 #조언 #성장
조회수 1049

급한 일 빠르게 해봐야...

결론적으로 '능력 부족한 개발자'소리를 듣는 것이 대부분이다.대부분 급하다고 일을 의뢰하거나 서비스 론칭을 위해서 급하게 요구하는 경우가 있다. 개발자의 선택은 매우 명쾌하다. 정해진 기간과 인원 숫자로 만들어야 하는 서비스가 특정한 시간 내에 동작하게 하는 방법은 동작시에 제약사항과 커버하지 못하는 품질 이슈를 만드는 것뿐이다.말 그대로 기술적 부채를 만들어 낼 수밖에 없으며, 이 기술적 부채는 결론적으로 반복적인 유지보수 업무와 처리하지 못하는 기능들에 대한 하소연을 만들어 낸다.슬프지만 그렇게 반복되는 과정에서 경영진은 해당 개발자를 신뢰하지 못하게 된다. 그리고, 그렇게 반복적인 유지보수 업무를 만든 것은 개발자의 능력 부족이라고 생각하게 되고, 이 관계는 보고서가 늘어나거나 주간회의시에 디테일하게 보고하라는 식의 결론으로 귀결된다.물론, 이런 상황을 만든 '착한 개발자의 결정'이 문제이기는 하다.대부분 경험이 풍부한 개발자들은 이런 과정들을 반복해 보았기 때문에 처음부터 거부하거나 거절하거나, 적정한 선에서 타협하는 방안들을 제시한다. 물론, 그 과정에서 무지한 경영진과 트러블이 발생하는 것도 다반사이다.이 경우 중간관리자가 개입해서 타협하는 경우가 분명 있다.단언컨대 해당 중간관리자는 둘 중 하나이다. 무지하거나 난파하려는 개발 조직을 재빠르게 떠날 사람이다.소프트웨어 개발에서 '급한 일'이란 없다.정해진 규칙과 기본에 충실하게 하고, 빠진 것 없는지 체크하고 디자인, 설계 후에 미래의 변화에 대해서 적절하게 해당 조직의 규모와 형태에 따라서 반영한 후에 '개발'하는 것이다.지금 이상황에도...'급한 일'이라면서 일을 가져다주는 경영진을 만나고 있을 슬픈 개발자들을 위해서...끄적끄적...
조회수 1880

제4차 산업혁명이라 불리우는 변화의 본질은 무엇인가

'제 4차 산업혁명’이 여기 저기서 화두가 되고 있다. 작년 다보스포럼에서 발표될 때만 해도 크게 주목받지 못했는데 방송에서 다뤄지고 클라우스슈밥이 다녀가면서 관심이 많아지기 시작했다. 때마침 창조경제를 대신 할 키워드가 필요했던 정부기관과 대선주자들의 관심이 겹치면서 그 정의의 모호함에도 불구하고 가장 많이 언급되는 용어가 된지도 모르겠다. 그래서 지금은 많은 사람들이 유행처럼 4차산업혁명 배우기에 빠져들었고, 반면에 또 많은 사람들이 실리콘밸리에서는 사용하지 않는 마케팅용어라며 그 모호함을 비판하고 있다. 난 이 두가지 시각이 다 불편하다. 유행이면 앞뒤없이 달려드는 가벼움도, 실리콘밸리에서 사용되지 않으면 아무것도 아니라는 편견도 모두 균형잡힌 시각은 아니라 생각하기 때문이다. 이것이 주류가 아니라 하더라도 분명히 변화라는 흐름속에서 바라 본 방향성이라는 것이 있을 것이다. 그래서 더 궁금했다. 진짜 이 뒤에 숨겨져 있는 변화의 본질은 무엇일까? 미래는 아직 발생하지 않은 시제이기에 어느 누구도 단정지을 수는 없는 불확실성을 내포하고 있지만, 통찰력있는 사상가나 비저너리들은 이것을 어떻게 바라보고 있을까? 어쩌면 다른 이름으로 불리우는 여러 변화들의 동인과 주장속에 우리가 알고자하는 제4차 산업혁명과 겹치는 본질을 알수 있지 않을까 하는 생각이 들었다. 여러 구루들의 인사이트에서 가려진 핵심동인을 읽어보기 위해 비교분석을 해보았다.기술의 변곡점을 바라보는 여러 관점과 해석들1. 클라우스 슈밥의 제4차 산업혁명슈밥은 우리가 전통적으로 산업혁명이라 부르던 증기기관으로 운영되는 기계적 생산설비의 출현을 1차 산업혁명으로 규정한다. 그리고 전기로 동작하는 모터와 컨베이어벨트가 출현하면서 본격적인 대량생산이 시작되는 것을 2차 산업혁명, 컴퓨터의 등장으로 생산의 수치제어 및 자동화가 본격화 된 것을 3차 산업혁명이라 구분한다. 그리고 센서들을 포함한 수많은 사물들이 인터넷에 연결이 되면서 물리적인 시스템과 연결된 가상의 정보지능공간이 융합이 되고 지능화된 생산시스템이 나타나는 것을 4차 산업혁명의 전조라 주장한다. 생산방식과 제조시스템의 진화가 만드는 변곡점을 주목하고 있다.2. 앨빈 토플러의 제4의 물결토플러의 첫번째 물결은 농업혁명으로 부터 시작한다. 그리고 두번째 물결로 화석연료를 기반으로 생산과 교통수단이 진화하는 산업혁명을 이야기 했으며 세번째 물결은 통신과 컴퓨터, 그리고 인터넷이 만드는 정보혁명을 말한다. 이때 생산량과 소비량이 비약적으로 증대되는 후기 산업혁명이 함께 일어났다고 언급하기도 했다. 제4의 물결은 다른 저서였던 부의미래를 통해 제시를 했는데 미래의 부를 결정 할 변화의 동인이 속도, 공간, 그리고 지식의 혁명으로 부터 비롯된다고 이야기한다. 시장을 만드는 생산혁명과 정보와 지식혁명, 그리고 시간과 공간을 와해시키는 기술적 진보가 만드는 가치의 변곡점을 읽는자가 부를 가진다 이야기한다.3. 제레미 리프킨의 제3차 산업혁명슈밥과 가장 유사한 구분이지만 각각의 혁명은 에너지 패러다임의 변동으로부터 기반한다고 주장한다. 그래서 제1차 산업혁명은 기계적동력과 석탄에너지, 제2차 산업혁명은 전기와 석유, 제3차 산업혁명은 인터넷과 재생에너지에 의해 진행된다고 구분을 했다. 특히 지금 진행되고 있는 3차 산업혁명에서는 데이터 교환을 기반으로 한 커뮤니케이션 인터넷, 물류와 물리적인 시스템의 연결을 의미하는 물류인터넷, 개인들이 생산하는 재생에너지까지 그리드에 연결하여 서로 주고받을 수 있는 에너지 인터넷, 이렇게 세가지 연결이 생산과 소비, 그리고 소유의 패러다임을 완전히 바꿀 것이라 주장한다.    4. 케빈 캘리의 제2차 산업혁명케빈 캘리는 이제서야 제2차 산업혁명이 시작되었다고 이야기한다. 다른 사람들이 주장한 이전의 모든 산업혁명은 다 하나인데, 증기기관, 내연기관, 전기모터등 인간이 만든 인공동력이 끊임없이 생산량을 증가시키는 방향으로 진화해 왔다고 주장하며 이 것이 제1차 산업혁명의 연장선상에 있었다고 이야기한다. 이제 제2차 산업혁명이 시작되는데 인공지능이 모든것과 결합이 되면서 생산량이 아닌 개인화, 다양화, 자동화, 최적화, 지능화등이 강화되는 방향으로 진화할 것이며 인류는 역사상 가장 지능적인 존재가 될 것이라 이야기 한다. 20년후에 모든 사람이 사용하고 있을 인공지능 제품이나 서비스는 아직 발명되지도 않았다고 주장한다.5. 에릭 브리놀프슨의 제2차 기계의 시대       에릭 브리놀프슨도 케빈 캘리처럼 두단계의 분류를 주장한다. 첫번째 생산혁명의 근간은 물리적동력의 혁명이고 두번째는 지능혁명으로 기계가 지능을 가지게 되면서 제2차 기계의 시대가 시작된다고 한다. 지능을 가지기 전의 기계시대와 가진 후의 기계시대로 나뉘는 것이다.이렇게 이들이 주장하는 산업혁명의 패러다임 변화는 기준과 해석하는 철학도 각각 다르다. 물론 정답이 존재하는 것도 아니다. 다만 이들의 주장속에 들어있는 변화를 견인하는 동인과 흐름의 방향, 그리고 변곡점을 규정하는 사건들은 해석의 견해차이에도 불구하고 공통적으로 바라보는 관점과 영역이 있다. 그리고 두번의 오버랩되는 구간이 있다. 첫번째는 18세기 생산의 기계화로 부터 시작된 산업혁명이며, 두번째가 바로 지금이다. 당장 몇년의 의미라기 보다는 21세기에 들어서면서 부터 스며들 듯 시작된 변화의 씨앗들이 현재를 기점으로 향후 이삼십여년정도의 기간을 거쳐가며 급격히 새로운 가치의 시대를 만들 것이다.이들의 이야기 속엔 연결의 진화, 캄브리아기 같은 수많은 센서들의 자각과 연결. 이어지는 데이터의 폭발, 비트와 아톰의 융합, 연결된 지능의 탄생, 그리고 새로운 에너지가 속도와 공간의 확장에 더해지면서 만들어지는 변화의 결이 담겨있다. 그리고 하나하나의 단일기술이 아닌 모든 기술적 동인들이 서로 영향을 주며 함께 파괴적인 혁신의 양상을 만들 임계점을 향해 진화하고 있는 것이다. 그리고 그 끝자락 어디쯤에는 레이 커즈와일이 예견한 특이점이 기다리고 있을지도 모른다. 그래서인지 필립코틀러는 시장의 가치 변화를 제시하며 기업과 시장이 지향해 나갈 새로운 시대를 마켓 4.0에 담아 이야기하고 있고, 롤프얀셴은 르네상스소사이어티를 통해 우리 사회가 탈문질경험과 감성이 중요한 시대로 접어들 것이라고 주장하고 있다. 위에서 언급한 기술적 동인들이 만들 사회와 시장이 기술적으로 엄청난 진보를 겪는 과정에서 결국은 가치와 따뜻한 인간적 감성, 그리고 사람들의 경험이 중요해지는 시대로 진화할 것이라 억지로 묶어 생각해도 사실 어색해 보이지 않는다.   시장과 사회의 변화가 의미하는 새로운 가치의 시대 이 변화의 동인들이 만드는 미래가 지금 우리가 이야기하는 제4차 산업혁명이냐 아니냐는 중요하지 않다. 거인들의 생각속에서 오늘 우리가 읽을 수 있는 것은, 엄청난 영향을 만들어 낼 변화는 이미 진행중이며 그 결과는 후대가 이름을 붙여야 비로소 완결된 의미를 가지게 될것이란 것이다. 모호한 경계와 다양성에 기반한 변화속에 만나게 될 미래를 위해 진위에 대한 논쟁보다는 우리가 준비하고 만들어 나갈 가치를 하나하나 실행 해 나가기 위한 의미있는 논의가 앞서길 희망한다.더 깊이있는 공부와 의미있는 토론이 될 수 있도록, 다른 의견, 다른 관점이 있다면 더하거나 제기 해 주시고, 더 다아간 생각의 지점들을 공유 해 주시길 바랍니다. 이미지출처: https://www.weforum.org/agenda/2016/06/leadership-challenges-of-the-fourth-industrial-revolution#라이프스퀘어 #스타트업 #창업자 #창업가 #마인드셋 #조언
조회수 12381

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

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

경험 부족한 스타트업의 devops 도입기 2편

출처 : 구글 이미지 검색그 동안 테스트코드작성, 코드리뷰를 집중적으로 수행했는데요. 아직은 엔지니어 모두가 걸음마 단계여서 실무리듬에 코드리뷰와 TDD를 끼워넣진 않았습니다. 대신 각자 리서치를 수행하고 매주 수요일 SW 세미나에서 lesson&learn 공유하는 식으로 devops를 공부했습니다.회고2주를 되돌아보고 느낌점을 한 문장으로 요약하면 다음과 같습니다.기술부채의 이자율은 고정 값이 아니다. 시간이 흐를수록 점점 더 높아진다.코드리뷰부터 말씀드리겠습니다. android와 iOS의 경우 앱 개발기간 3개월 동안 커밋한 어떠한 코드도 리뷰하지 않은 상황이었습니다. devops를 계기로 두 프로젝트 간의 코드리뷰를 드디어 시작했는데요. 방대한 코드를 빠르게 이해하기 위해 코드리뷰에 앞서 시각화된 자료를 준비해 아키텍쳐리뷰부터 수행하였습니다. 아니나 다를까 두 클라이언트의 유저스토리가 완벽하게 똑같음에도 불구하고 클래스 설계며 구현상의 코드며 개발 상의 내용이 완전히 갈라져 있음을 목도했습니다.출처 : 구글 이미지 검색iOS, android 환경적 차이로인해 어쩔 수 없이 코드의 다름이 나타나는 경우도 있었지만 대다수의 차이는 코드리뷰를 하지 않아서였습니다. 코드리뷰를 진행하면서 조금 신기했던 사실은 아주 간단한 요구사항(기능)도 개발자 개성에따라 구현법이 각양각생이라는 점입니다. 한 가지 문제에도 다양한 해결법이 존재하는만큼 각 구현법 마다 강점과 약점이 존재하기 때문에 코드리뷰의 필요성이 생각보다 더 크다는 점을 깨달았습니다. 앞으로 클라이언트에는 고도화된 유저스토리가 계속 추가될 예정인데 두 클라이언트간 갈라진 구현상의 설계는 분명히 피처 딜리버리에 병목지점으로 작용될 것입니다. 두 갈래로 나뉜 클라이언트를 어떻게 설계적으로 통합시켜 나갈지 지속적으로 고민해봐야 겠습니다. 또한 더 이상 차이가 벌어지지 않도록 지금부터 추가되는 피쳐들이라도 코드리뷰를 수행하는 환경에서 개발되도록 해야할 의무감도 느꼈습니다.테스트 코드도 마찬가지로 기술부채가 생각보다 많이 쌓였음을 깨달았습니다. 스위처의 클라이언트의 기술적 난이도는 낮은 편입니다. 그런데 그럼에도 불구하고 기존 코드에 테스트코드를 입혀 SUT로 만드는 일은 여간 까다로운 일이 아니었습니다. 기존 코드는 비즈니스로직과 I/O(DB,Network, BLE), UI 코드간의 커플링이 높아서 막상 어느것 하나 테스트코드를 입히기 쉽지 않았습니다. 테스트코드를 작성하기 위해서는 논리단위의 클래스들을 떼어내는 리팩토링이 병행되어야만 했습니다. 테스트코드 없이 작성한 코드는 시간이 지날 수록 테스트코드가 비집고 들어갈 틈 또한 점점 없애는듯 합니다. 그래도 이러한 현상들은 몸소 체험하면서 확신을 갖게된 사실도 있었습니다.테스트코드가 존재함으로서 SUT의 설계는 옳은방향으로 향한다.기존 코드에 테스트코드를 입히려고 이리저리 애쓰다보면 무관한 기능들이 뭉쳐있는 비대한 클래스는 발견하게 됩니다. 테스트코드를 입히기 까다로운 이 거대한 클래스를 쪼개야할 필요성을 느끼게 되는데요. 이 시점에서 개발자는 테스트코드가 있기 전에 절대 하지 않던 리팩토링 고민을 하게 됩니다. 치열하게 고민하는 과정에서 리팩토링에 실패하면 제대로된 테스트코드를 작성하기가 불가능해집니다. 즉, 테스트코드를 작성 했다면 분명히 설계상의 리팩토링이 일어 났을 확률이 높습니다.스위처 어플리케이션의 내 주변의 스위처 목록 페이지를 예를 들어보겠습니다. 해당 스크린에서는 유저가 여러개의 스위처를 확인하기 때문에 몇 가지 비즈니스 룰에 의해 스위처들의 정렬 순서가 결정됩니다. 그래서 유저는 여러개의 스위처가 검색되어도 내가 가장 사용할 확률이 높은 스위처를 최상단에서 만나는데요. 그 정렬 역할을 맡은 클래스가 switcher sorting(이름이 잘 기억안나네요..) 입니다.저희 안드로이드 개발자는 이 클래스를 첫 SUT로 만들기로 결정했고 일 주일간 테스트코드를 작성하려고 노력했습니다. 그러나, 생각보다 쉽지 않았습니다. SW세미나때 코드를 리뷰하면서 발견한 사실인데 swithcer sorting는 단순히 비즈니스룰에 사용되는 정보 뿐만 아니라 꽤나 무거운 무거운 switcher 클래스도 의존하고 있었습니다. 정작 sorting 우선순위를 결정하는데 필요한 정보는 switcher 클래스가 갖고있는 정보들 중 극히 일부분이었는데 말이죠. 이렇게 큰 클래스 때문에 테스트 코드를 짜려면 안드로이드 라이브러리인 BluetoothDevice와 Context 인스턴스를 공급하는 목업 클래스가 필요한 상황이 벌어질 수도 있었습니다. 더 큰 문제는 비대한 클래스로 인해서 test의 fixture를 구성하는데 수십 줄의 코드가 필요 했다는 사실입니다. 자연스럽게 테스크코드를 작성하면서 리팩토링의 필요성을 느끼게 되었습니다. 가까운 미래에 스위처 개발자가 성공적으로 switcher sorting 클래스를 SUT로 만들었다면 이 클래스의 설계 또한 분명 리팩토링을 거쳐 더 좋은 방향으로 거듭 났을 것 입니다.앞으로 2주간 할 일어떠한 일이든 균형이 중요하다고 생각합니다. 마냥 기술부채를 털어낸답시고 리서치와 공부만 하고 있을 수는 없습니다. 동아리가 아닌 회사이기 때문에 시장의 니즈에 맞춰서 분명히 다시 피쳐를 개발하는 속도를 높이는 가속 패달을 밟아야 할 시점이 올 것입니다.출처 : 구글 이미지 검색너무 이르지도 않게 그렇다고 너무 느리지도 않게 적절한 시점에 고객이 불만을 터뜨리지 않을 정도의 SW 안정성을 보장하는 최소한의 devops 수준을 달성해야합니다. 어느정도까지가 devops를 도입해야 오버엔지니어링이 아닌 기술부채를 탕감하면서 동시에 I/O 초중기 목표를 달성할 수 있는지 치열하게 고민하고 부딪혀보며 기민하게 대응해야 겠습니다.앞으로의 2주간 할 일은 다음 질문 두 가지에 대한 대답을 하면서 자연스럽게 도출될 것 같습니다.테스트코드 작성을 위한 TDD를 어떻게하면 엔지니어가 효과적으로 학습할 수 있을 것인가?코드리뷰를 스프린트 일과에 어떻게 자연스럽게 안착시킬 것인가?#스위쳐 #Switcher #개발 #개발팀 #문제해결 #인사이트 #DevOPS #데브옵스

기업문화 엿볼 때, 더팀스

로그인

/