최근 다음과 같은 고민이 깊어졌다."나는 잘하고 있을까?""내가 지금 해야만 하는 중요한 일은 무엇일까?""나의 역할은 어디까지고, 무엇을 위임해야 할까?""어떤 사람을 채용해야 할까?"팀의 구성원이 떠나기도 했고, 회사도 여러 가지 도전을 받고 있으며, 나 자신의 정체도 느끼는 것이 고민의 시작이다. 위 질문들의 공통된 뿌리는 “나의 일은 무엇인가?”라는 질문이다.'나의 일'이라는 것은 '스타트업 CTO의 일'이다. 하지만 모든 스타트업의 CTO가 하는 일이 나와 같지는 않다. 스타트업은 다양한 단계가 있고, 목표로 하고 있는 시장도 제각각이다. 가지고 있는 기술, 목표로 하는 기술도 다르고, 구성원 또한 제각각이기 때문이다. 하지만 어느 정도 공통점이 있을 거라 생각한다. 혹시 이 글을 어느 스타트업의 CTO가 읽으신다면 자신의 일과 비교를 해봐 주시길 부탁드린다.본격적으로 시작하기 전에 이 글은 내가 앞으로 겪을 경험에 따라 많이 바뀔 수 있음을 미리 알려둔다.CTO?Chief Technology Officer의 준말이다. 경영진 중의 한 명으로 회사에서 기술과 관련된 모든 일을 관리, 책임진다. 여기에서 '기술과 관련된 모든 일'이라는 모호한 것을  들여다보기 위해서는 CTO의 역할을 좀 더 나눠 볼 필요가 있다. 다음과 같이 나눠보고 각각에 대해서 살펴보자.Technical Leader - 최고의 엔지니어Technical Businessman - 기술조직과 사업조직의 가교Team Manager - 팀장Product Manager - 프로덕트 관리자Technical Leader보통 CTO라 하면 가장 먼저 떠올리게 되는 역할이다. 기술기업의 경우 핵심 기술역량을 보유하고 있거나, 서비스 기업의 경우 주도적으로 서비스를 개발/운영해본 경험이 있어야 한다. 다음과 같은 역할이 요구된다.1) 기술 비전과 로드맵회사의 기술 비전을 세우고, 그 비전을 달성하기 위한 로드맵을 정하고 실행해야 한다. 실행을 위해서 기술 조직에 비전을 전달하고 공감을 얻어 낼 수 있어야 한다.2) 아키텍트회사가 만드는 서비스 아키텍처를 만들고 발전시켜 나가야 한다. 동시에 이 서비스가 동작하는 인프라 아키텍처를 셋업하고 견고하게 만들어야 한다. 이를 위한 개발 스택들을 결정하고 적용해야 한다.3) 좋은 기술 코치팀이 기술적으로 성장할 수 있는 환경을 갖추고 코칭을 해야 한다. 팀의 구성원이 기술적 목표를 높게 유지할 수 있도록 해야 한다.4) 시니어 개발자시니어 개발자로 다음과 같은 역할을 해야 한다.· 팀이 현재 겪고 있는 가장 어려운 문제를 풀 수 있어야 한다.· 회사의 핵심 기술을 이해하고 높은 퍼포먼스로 제품을 만들어야 한다.· 개발 효율을 높일 수 있는 환경을 갖춰야 한다. (DevOps)· 문서화를 해야 한다.Technical Leader로서 위와 같은 일들을 잘 하게 되면· 고도화되더라도 효율이 떨어지지 않는 시스템· 높은 제품의 성능· 높은 기능적 완성도· 경쟁력 있는 기술과 그 기술을 갖춘 팀을 얻을 수 있다. 위 일들은 조직이 커지게 되면 팀의 시니어 개발자들이 점점 나누어 가지게 된다. (단, '기술 비전과 로드맵'을 제외하고) 다르게 말하면 반드시 위의 역할을 잘 나누어 가질 수 있는 사람을 시니어 개발자로 채용해야 한다.Technical Businessman대부분의 스타트업은 기술을 기반으로 시장의 문제를 해결(=사업)한다. CTO는 기술조직과 사업조직이 함께 잘 굴러가기 위한 가교 역할을 해야 한다. 이를 위해서는 회사의 사업에 대한 이해와 사업적인 센스가 필요하다.1) 기술적인 조언시장의 문제를 기술적으로 해결하고자 한다면, 기술조직에서 아이디어가 나와야 한다. CTO는 보통 가장 많은 아이디어를 사업조직에 제공해야 한다. 또한 회사가 새로운 일을 시작하고자 할 때, 그 일이 기술적으로 가능한 일인지, 어느 정도 크기의 일인지를 추정해야 한다. 비록 추정이 조금 부정확하더라도 추정이 있어야 사업적 판단을 할 수 있다. 그리고 회사에서 그 추정을 가장 잘 해야 하는 사람이 CTO다.2) 사업을 기술조직에 전파“나는 왜 이것을 개발해야 하는가?”에 대한 개발자의 질문에 답을 해주어야 한다.(정확히는 물어보기 전에 알려주어야 한다.) 이 일을 하는 사업적인 이유를 충분히 설명해 주어야 개발자는 동기를 얻고, 정해진 것 이상의 것을 만들어 낼 수 있다.3) 기술을 다른 조직에 전파회사가 가진 기술을 다른 조직에 전파해서 충분히 이해할 수 있도록 해야 한다. 그래야 기술이 아이디어를 만나 빛을 발하고 회사의 가치가 높아진다.Technical Businessman으로 위와 같은 일들을 잘하게 되면 회사가 가진 기술이 사업에서 효과적으로 사용된다. 그리고 사업을 위해 필요한 기술이 기술조직에서 발전하게 된다. 이 일들은 조직이 커지게 되면 역시 시니어 개발자와 프로젝트 관리자에 의해서 대체될 수 있다.Team Manager일반적인 팀장/조직장이다. 이 역할을 잘 수행하기 위해서는 커뮤니케이션 능력, 시간/리소스 관리 능력을 갖추어야 한다.1) 채용좋은 개발자를 채용해야 한다. 이를 위해서는 다음과 같은 기본적인 일을 해야 한다.· 채용 공고를 작성하고 올린다.· 면접을 진행하고 채용을 결정한다.· 좋은 사람을 소개받고 만난다.채용을 위해서는 장기적으로는 회사의 '기술 브랜드', '기업 문화'를 만들어 나가는 것이 도움이 된다. 물론 이런 것 보다 회사가 로켓처럼 날아가는 게 효과는 훨씬 더 좋다.2) 인력의 유지어렵게 뽑은 인력을 잘 유지해야 한다.  · 개인의 비전과 회사의 비전을 일치시키기 위해 노력한다. 다른 말로는 동기부여라고 한다.· 개인의 조직 내 성장을 돕는다.· 개인이 회사에서 만나게 되는 문제를 해결해 준다.물론 충분한 대우를 해주는 것도 중요하다.3) 자원의 산정과 확보프로젝트가 시작되기 전에 프로젝트에 필요한 인적, 물적 자원을 구체적으로 산정한다. (위의 Technical Leader가 하는 초기 결정을 위한 추정과는 다르다.) 대부분의 경우 어떤 사람이 어떤 일을 할 것인가를 결정짓는 일이다. 그리고 개발 혹은 운영에 필요한 추가적인 자원들을 준비한다. 장비가 될 수도 있고, 외부 서비스가 될 수도 있다.4) 일정의 계획과 관리일정을 계획하고, 관리한다. 다른 팀 혹은 외부와 의존성이 있는 경우 특히 이런 부분들을 잘 관리해서 일정이 차질 없이 진행이 될 수 있도록 한다. 프로젝트의 진행상황은 시각화하여 공개적으로 확인할 수 있도록 한다.5) 업무 프로세스 개선업무 프로세스를 개선해서 효율적으로 일할 수 있도록 해야 한다. 이를 위해서는프로젝트 관리 도구의 도입이슈 트래킹 시스템 도입스크럼/칸반등의 개발 방법론을 도입하고 운영등이 필요하다.3), 4), 5)는 우리가 일반적으로 프로젝트 관리자(PM)라 부르는 사람의 역할이기도 하다.이 일을 잘하게 되면회사에 필요한 인적 구성/역량을 갖춘 기술 조직을 유지할 수 있다.팀이 효율적으로 일할 수 있다.타 팀과 조화롭게 일할 수 있다.팀이 진행하는 프로젝트를 성공으로 이끌 수 있다.이 일들은 조직이 커지게 되면 중간 관리자, PM, HR 담당자가 생기면서 대체될 수 있다.Product Manager팀이 고객들이 원하는 제품을 전달하게 한다. 이 역할을 잘하기 위해서는 사업, 기술에 더해 UX에 대한 이해가 추가로 필요하다. (인터넷 서비스의 경우)1) 고객에 대한 이해고객을 보다 잘 알기 위한 노력을 해야 한다. 이를 위해서는 서비스에 관련된 지표들을 지속적으로 관찰해야 한다. 또는 인터뷰, 고객 대응 등을 통해 고객의 소리를 직접 듣는다.2) 고객의 대변자고객이 원하는 바를 명확하게 적은 스펙 문서를 작성해서 메이커에게 전달해야 한다. 또한 애매한 사항들이 있을 때 이를 최종적으로 결정해야 한다. 때로는 고객을 대신해서 제품에 대한 쓴소리를 해야 한다.3) 제품의 비전과 로드맵"우리는 어떤 제품을 만들어 갈 건가요?"라는 질문에 답을 할 수 있어야 한다. 즉, 제품의 비전을 구축해야 하고 이를 위한 구체적인 로드맵을 만들고 실행해야 한다. 이 비전을 조직에 전파하고 공감을 얻어야 한다.4) 우선순위의 결정사업, 고객의 측면에서 때로는 기술/디자인 부채를 없애기 위한 메이커의 입장에서 우선순위를 결정해야 한다.각 구성원 간의 이해관계가 부딪치는 부분이다. 효과적인 커뮤니케이션을 통해 슬기롭게 해결해 가야 한다.5) 제품의 퀄리티제품의 퀄리티를 책임진다. 직접 QA도 하고 디테일을 챙겨서, 구성원들이 높은 퀄리티를 목표로 할 수 있도록 해야 한다.이 역할을 잘하게 되면 좋은 제품을 만들어서 고객들의 호응을 이끌어 낼 수 있다. 또한 제품을 만드는 구성원들이 만족감을 얻을 수 있다. 이 역시 조직이 커짐에 따라 기획자, UX 디자이너가 일부 역할을 대체할 수 있으며 Product Manager를 뽑을 수도 있다.마치며스타트업의 CTO가 해야 하는 일은 이렇게 많다. 사실 스타트업 초기에는 위에서 말한 모든 것이 필요하지는 않다.(일단 컴퓨터를 사고, WIFI 설정도 하고..) 하지만 회사와 조직이 성장함에 따라 각각의 역할은 점점 중요해진다. 적당한 시기에 이 역할들을 위임하지 못하면 구멍이 생기기 시작하면서, 결국 여러 가지 중 하나도 제대로 챙기지 못하는 상황이 발생하게 된다. 이렇게 일을 정리하고 보니 지금의 내가 그런 상황이 아닌가 싶다.그럼 이제 내가 해야 하는 일은 동료들에게 적극적으로 도움을 요청해야 하는 것이다. 동료들도 내가 손을 내밀기를 기다리고 있을 거라 생각한다. :)  · 마지막으로 타이틀 이미지는 최근 프로덕트 그룹 워크샵에서 디자이너님의 타이포 세미나 때   제가 직접 그려 본 것입니다.#8퍼센트 #에잇퍼센트 #스타트업CTO #CTO #일상 #하루 #관리자

아키텍처적인 판단과 비기능적인 요소, 품질요소에 대한 것을 기준으로 우선순위를 결정하는 것은 차라리 간단하다. 아리송하고 판단하기 어려운 것은 따로 있다. 서비스를 어떤 기능이나 어떤 서비스, 어떤 영역을 먼저 시작해야 하는 가?. 아니면, 서비스가 개시되고 돌아오는 버그 리스트와 추가 요구사항 등의 사용자의 피드백을 통해서 유지보수의 순서를 정하는 것 등이 아리송한 것이다.이번에 중점적으로 이야기하는 것은 개발자들에게 요구되는 요구사항과 업무의 작업 단위들은 왜 이렇게 많이 변화하고, 이러한 요동치는 환경들은 무엇 때문에 발생하는 것인지에 대해서 생각해본다.대부분의 소프트웨어 개발자들은 시시각각 변화하는 요구사항과 유지보수 업무의 홍수 속에서 점점 무덤덤해지면서, 자신들이 할 수 있는 일만을 하려고 하는 경향으로 변화해 간다. 그렇게 변화하면서 개발 조직 내에서 무력감에 빠져드는 현상을 맞이 한다. 그 모든 이유의 대부분은 최고 경영자나 경영진, 리더층의 결정장애이거나 판단 미스인 것이 대부분이다.슬프게도 최고 경영진에게는 소프트웨어 개발팀에서 업무를 제대로 처리해주지 않는다는 영업과 기획 조직들의 푸념이 늘어나는 이유는 소프트웨어 개발팀에서는 제대로 된 요구사항의 정의가 되지 않았고, 작업의 우선순위가 불분명하기 때문에 이런 기술적 판단 미스와 잘못된 기술 부채가 누적되어지기 때문이다.기술적 부채에 대해서는 다음에 이야기하고, 이번 이야기에서는 '작업'의 우선순위를 결정하는 부분에 대해서만 이야기해보자.우선순위를 결정하는 기준이 없거나, 기준에 대해서 의사소통이 안 되는 경우가 발생할 수 있다. 그리고, 대부분의 스타트업들은 이런 현상을 맞이한다. 물론, SI현장에서는 너무도 비일비재하게 반복되는 경우가 많기 때문에 이런 현상은 지금 이 순간에도 반복되고 있다.도대체 왜 이런 상황을 만들었는가? 그리고, 누가 이렇게 만들었는가? 분명, 스타트업 초기에는 의기투합했던 CEO와 기술 총 책임자가, 어느 정도 기업이 성장하고 나니, 업무의 우선순위와 요구사항의 폭주 속에서 서로 일기토를 벌이는 대립된 상황이 되어버린 것은 무엇 때문일까? 도대체 이렇게 개발업무가 뒤죽박죽 되어버린 것은 누구의 책임인가?아키텍처가 부재하고, 아키텍트 역할을 담당하는 사람이 없는 경우에는 이런 현상은 매우 당연하다. 오히려, 발생되고 있는 것을 모른다면 그것은 더 위험하다. 개발자나 담당자가 현상을 숨길 가능성도 매우 크다. 언제나 개발 리소스는 부족한 것이 정상이다.개발 일정은 촉박하고 만들어야 할 것은 많으며, 버그는 언제나 발생한다. 이런 사항들을 어떻게 처리하는 것이 가장 합당한 것인가에 대해서 삐딱한 아키텍트의 시선으로 몇 가지 정의하여 보자.한편으로는 이러한 상황은 매우 당연한 것이다. 소프트웨어 개발을 할 때에 수많은 업무들이 밀려온다. 또한, 요구사항들은 급변하고 시장 또한 급속도로 변화를 일으키는 것을 간과해서는 안된다.‘냉정하게 ‘경영진’이나 ‘개발 총 책임자’의 능력이 부실해서 그런 경우가 태반이다.‘라고 필자는 이야기하고 싶다. 그런 상황을 피하게 해야 하고, 그런 문제를 해결하기 위해서 최선을 다해야 하는 것이 그들이 해야 할 일이다. 그래서, 고액 연봉을 받는다. 그러니, 이런 문제는 그들이 해결해야 한다.결론은 그러하지만, 그런 상황을 좀 더 세밀하게 분석해보자.보통 이러한 일이 발생하는 경우의 가장 대표적인 문제는 경영진의 ‘경영 목표’가 불분명하고, ‘프로젝트의 골’에 대해서 가치의 설정을 제대로 못하고, 이에 대해서 조직원들에게 의사전달이 불분명할 때에 이런 상황들이 대부분 발생한다. 그리고, 결과는 불을 보듯 뻔하게 된다. ( 의사소통이 안되었다고 판단하기도 하지만, 대부분 일방통행으로 전달되어지는 지시사항들이 대부분이므로, 의사소통의 문제는 아니다. 그러니, 개발자나 기획자, 디자이너의 책임이 아니다. 그냥, 지시가 잘못된 거다. )물론, 전통적인 제조업체와 전통적인 관료조직에서는 이러한 문제를 해결하는 다양한 방법들이 연구되었고, 차근차근 일을 풀어나가는 방법에 대해서도 많은 해결책과 솔루션들이 등장한다. 하지만, ‘지적 생산’을 주 업무로 하고 있는 소프트웨어 개발에 있어서는 이러한 방법들은 정말 바보스러운 프로세스를 만들 뿐이고, 인원이 비대해지며, 불필요한 회의와 불합리한 결정들이 도배되는 경우가 많은 관료조직을 비대하게 만드는 경우가 많다. 이런 문제를 해결하겠다고, 조직의 구성 방법이나 조직을 관료화하고, Tree구조로 만드는 바보 같은 짓을 필자도 그런 실수를 반복했었다. (ㅡ.ㅡ;)스타트업으로 빠르게 시작한 기업이 어느 정도 매출을 일으키거나, 서비스가 완성되어 갈 때에, 대규모 인원을 확충하면서 발생되는 문제들은 아이러니하게도 대부분 비슷하다. 그 문제의 핵심중의 핵심은 그 ‘문제’ 들을 어떻게 나열하느냐이다.그렇다면, 이러한 문제들을 어떻게 명확하게 해야 하는가? 그것을 조금 더 명확하게 개발업무에 있어서 정의한다면. 소프트웨어 개발에 있어서 가장 초보적이고 기본적인 ‘업무의 요구사항’을 제대로 결정하는 것이다. 그리고, 이러한 ‘요구사항’을 어떤 방법으로 중요한 ‘업무의 우선순위’를 잘 결정하는 것이다.이런 ‘우선순위’를 결정하기 위하여 ‘요구사항’을 어떻게 잘 정의하는가가 이 문제를 보다 명확하게 하는 방법의 가장 핵심중의 핵심이 되겠다. 물론, 똑똑한 경영자와 리더가 앞에 나서는 것은 당연한 것이겠이고, 그러한 리더는 ‘요구사항’을 정말 명확하게 정의하고, To-be에 대해서 명쾌하게 정의할 수 있다. To-be가 명확하고, 만들고자 하는 제품과 서비스가 명확하다면 이런 혼란을 발생하지 않을 것이다.하지만, 불분명한 목표와 불분명한 요구사항은 결국, 소프트웨어 개발을 파국으로 만들어 버리는 첫 번째 문제점이다. 훌륭한 리더는 작은 요구사항과 작은 결정사항부터 명확하게 정의한다.소프트웨어 개발 업무의 우선순위를 결정하는 방법물론, 이 내용은 소프트웨어를 중심으로 IT설루션이나 서비스를 개발하는 업체를 대상으로 설명하기는 하지만, 일반적인 기업들도 요즘은 대부분 중요한 의사결정과 지적 프로세스들을 갖추어야 하기 때문에 발생되는 문제들은 대부분 대동소이하다고 하겠다.또한, 경영의 목표에 대한 설정과 과학적인 접근 방법은 경영학적인 관점이기 때문에, 그 부분에 대해서도 이 글에서는 논외로 하자. 보통 조직이나 기업은 제한된 리소스와 자원과 일정을 가지고 최대의 이익과 목표를 도달하기 위한 경영자의 판단에 의해서 결정되어지고 움직여진다. ( 그래서, 사장이 똑똑해야 한다. )대부분의 조직과 회사는 이미, 시작부터 그 결과를 예측할 수 있다고 보는 것이 합당하다. 이처럼, 냉정하게 경영의 목표를 명확하게 하고, 조직의 비전과 한 해의 목표와 프로젝트의 목표에 대해서 얼마나 잘 결정하느냐가 핵심적인 성공요소들이다. 목표가 명확하면, 업무 순위도 명쾌하다.아무리 개발자가 똑똑하다고 해도, 경영진의 삽질을 버텨낼 수 있는 것은 거의 ‘기적’에 가까운 일이기 때문이다. 결정하고 업무의 우선순위를 정의하는 사항들이나 체크리스트에 대한 이야기인 경영진들이 판단해야 하는 내용에 대해서는 필자의 경험( 중견기업의 임원 노릇 )을 바탕으로 다음 기회에 이야기하도록 하겠다. 아마도, 스타트업과 중견기업의 임원으로 일해본 필자가 해줄 수 있는 이야기는 필자 주변에서 물어보듯이 생각보다 많은 듯하며, 브런치를 통해서 자주 언급하고 이야기하도록 하겠다.정말 중요한 소프트웨어 개발 기업에서의 업무의 우선순위는 무엇으로 결정되어지는가? 그것은 대부분의 기업과 대동소이하다. 그것은 ‘기업이 추구해야 할 이익’이다. 그리고, 그 이익을 위해서 어떠한 경영적인 지표와 목표를 설정하느냐에 따라서 결정되어진다.이러한 결정사항이 개발업무의 우선순위에 가장 지대한 영향을 준다. 앞서 이야기했지만 경영지표를 설정하는 것은 이 글에서는 논외이다. 일단, 여기서는 경영의 목표는 명확하다는 전제하에서 매일매일 요구사항에 따르는 업무의 우선순위가 요동치게 되는 상황을 생각해보자. ( 일단, 똑똑한 경영진이 제대로 된 목표 설정을 했다고 본다. )하지만, 그렇게 목표 설정이 되어도, 요구사항과 업무의 우선순위가 요동치는 경우는 똑같이 발생하게 되는 경험을 하게 된다. 도대체, 왜? 이런 현상들이 발생되는 것이고, 왜? 우리는 이러한 변동되는 상황 속에 노출되어 있는 것일까?대부분의 소프트웨어 개발 업무들을 보면, 생각 이상으로 매번 계획에 없던 일은 수시로 발생하고, 발생된 업무들은 아이러니하게도 중요한 업무 리스트로 추가되는 해괴한 현상이 수업이 되풀이된다. 도대체! 왜? 그런 현상이 일어날까?시장의 매우(!) 변화는 당연하다.물론 이러한 상황을 여러 가지 상황으로 해석할 수 있겠지만. 대부분의 이런 식의 업무의 우선순위가 요동치는 이유는 '회사 주변의 변화'가 극심해서 벌어지는 현상 중의 하나일 수 있다. 이러한 경우는 극히 당연하며, 이 요동치는 것을 어떻게 프로세스에 반영하는가가 관건이다. 그래서, 해당 프로세스의 분석과 반영에 집중하면 최고의 프로세스를 얻을 수 있다. 대부분이거나 특히, 일등 경쟁업체가 있고. 그 업체의 행동을 주시해야 하는 팔로워 정책을 사용하는 업체의 경우에는 이런 일은 거의 매번 발생하는 경우이니, 어떻게든 이러한 변화를 탄력적으로 운용할 수 있는 환경을 만드는 것이 중요하다.분명, 더욱더 극심하게 발생하는 것과 소프트웨어 개발과 환경, 조직을 그에 맞추어야 하니까 발생하는 것이다. 냉정하게 해당분야의 1등 기업이 아니고서는 대부분 이러한 현상을 비일비재하게 만나게 된다. ( 보통 기업들은 애플과 같은 선도적인 기업이 아니다. ) 그리고, 이런 요동치는 '변화'에 따라서, 보통은 이러한 변화에 따라서 세부적인 실행방안과 전략, 결과물들이 변동되는 것인 어찌 보면 당연하고 지당한 범위의 변동일 수 있다.당연하게도 이러한 ‘시장의 변화’를 내부 조직원들에게 어떻게 전파하고, 의사소통하는 것이 효과적인 것인가에 대해서 더 많은 투자를 해야 하고, 해당 정보들을 빠르게 전파할 수 있는 방법들을 고안해야 한다.하지만, 시장은 그대로인데? 요구사항은 요동친다?그렇지만, 시장의 변화도 없고, 경쟁기업의 변화도 그다지 없는데도, 부서와 부서원, 개발자와 영업 등에 있어서 주요한 우선순위가 요동치고, 기준점이 없는 상황에서 방황하게 되는 현상은 왜 일어나는 것일까?재미있게도, 대부분의 '우선순위'변동은 이러한 외부요인에 의해서 발생하지 않는다는 점이다. 보통은 이런 '외부요인'에 대한 대응방안과 충격은 대부분의 회사와 조직에서 반응할 수 있도록 대처가 되어있는 편들이다. 그리고, 경영이나 관리조직은 그러한 것들을 탄력적으로 운영할 수 있는 다각도적인 방법들에 대해서 이미 익히 알고 있기 때문에, 대부분은 소프트웨어 개발 조직에 이러한 여파가 가지 않도록 최선을 다한다. (* 만일 이런 상황이 아닌데도 개발 조직에 여파가 전해진다면, 전적으로 관리조직이나 리더십의 문제, 의사소통 등의 문제들이 그대로 드러난 것이다. )정말 대부분의 '우선순위'의 변동은 엉터리 같은 상황에서 발생되는 경우가 생각 이상으로 많다. 그것의 대부분은 납득하기 어려운 모호한 이유와 상사의 변덕, 사내 정치의 비합리적인 결정 등에 따라서 변화되는 경우가 많다.물론, 대한민국의 SI특성상 거지 같은(?) 고객의 불합리한 요청사항 때문에 거지 밥상을 뒤엎듯이 변화하는 것 또한 엄연한 현실이고 사실이다. 하지만, 냉정하게 이러한 현실에 대해서 잘 알고 있으면서 대응을 하지 못한다는 것 또한 분명 능력과 실력의 문제이기도 하다. 분명, 거지 같은(?) 고객과 시장이라면 그에 응당한 대응조직이나 프로세스를 갖추어야 한다. 하다 못해, 술말 마시는 술상 무라도 동원하는 것이 합당하다. 대한민국 공공 SI의 성패는 ‘술자리’에서 결정되는 경우도 많다. (ㅡ.ㅡ;)정말 중요한 것은 이런 상황을 파악하는 것 그 자체가 중요한 것이다. 이처럼 정말 중요한 것은 업무의 요구사항에 대한 본질을 정확하게 파악하는 것이다.분명, 자신의 조직과 회사에서 '소프트웨어 개발업무의 우선순위'는 어떤 식으로 결정되어지며, 어떤 것들이 정말 중요한 업무인지 파악하고 분석하는 것이 가장 핵심적으로 필요하다. 아주 세부적인 우선순위에 대해서는 실제 해당 업무를 분석하고 정의해야 하지만, 일반적으로 이러한 ‘요구사항의 본질’을 정의하는 데 있어서, 최소한 두 가지의 스텝으로 업무를 구분하고, 다음의 4가지 정도의 업무형태는 구분해야 한다고 생각한다.현재 팀에 적합한 소프트웨어 개발업무의 우선순위를 결정하자!그것의 첫 번째 스텝은 정말 필요한 '0순위의 업무'와 '쓸데없고 필요 없는 일'을 구분하는 것이다. 그리고 남은 요구사항과 업무들은 일반적인 업무들이며, 그 업무들은 다음 스태프의 분석과 정의에 따라서 ‘고품질이 요하는 업무’와 ‘적정 품질을 요하는 업무’를 구분하는 것이다.이처럼 0순위 업무, 불필요한 일, 고품질 업무, 적절 품질업무의 4가지 스태프로 구분하여 업무의 우선순위를 정하는 것이 요구사항 분석의 첫 번째 단계이다. 그리고, 그러한 기준과 성격에 대해서 조직원들에게 폭넓은 이해를 구해야 하며, 그 부분에 대해서 공감대를 형성해야 한다. 대부분 기업의 목표와 비전은 그러한 것을 전제로 구성되게 된다. 그렇다면, 이러한 해당 업무의 성격은 어떻게 구분하는지 하나씩 살펴보자. 요구사항들에 대해서 구분이 어렵다면, 필자가 사용하는 방법을 한번 사용해 보라. 아래의 표는 요구사항의 우선순위를 평가하기 위해서 필자가 사용하는 방법이다. 점수를 만들어서 사용하는 것이 가장 간단할 수 있다.표1, 요구사항에 대한 가중치 리스트위의 표를 이용하거나 적절하게 요구사항의 가중치를 조절하여 ‘수치화’하는 것도 일부분 가능하다. 하지만, 이렇게 정량적으로 판단하는 것보다 더욱더 중요한 것은 ‘요구사항’은 ‘정성적’인 판단을 제대로 하는 것이다.0 순의 업무를 찾고 정의하자가장 쉽게 이야기하면. ‘기업의 이익을 가져다주는 확실한 것’이 명확하게 드러난 것을 의미한다. 몇 가지 부연설명을 하자면, 기업이 사활을 걸어야 할 신기술이 들어간 서비스, 매출 증대를 위한 새로운 시장에 진입하는 비즈니스 모델을 갖춘 서비스, 수익모델을 만들고 실현하기 위한 일련의 서비스의 Back-office 작업들, 현재 서비스 중인 소프트웨어의 위기사항을 타개할 해결책을 찾는 것 등이 이러한 '0순위 업무‘에 해당한다.더 명쾌하게 이야기하자면 '업무의 가치'가 명확하고, '업무의 요구의 원천'이 명확하고 정확하게 드러난 요구사항들 중에 '수익'이 명쾌하게 보이는 일이 이에 해당한다. 이러한 '업무'들은 개발 조직뿐만 아니라, 영업이나 기타 조직에서도 발 빠르게 대응하는 것이 가장 중요하다.보통 이러한 일들에 있어, 가장 중요한 것은 '타이밍'이게 된다. 말 그대로, 발생한 시기와 해결되는 시기의 주기가 가장 짧아야 한다. 말 그대로, 고객이 원하는 제품과 서비스를 의미한다. 그래서, 0순위로 진행해야 한다.또한, 이러한 타이밍은 기업에게도 큰 기회를 주지만, 해당 업무를 추진하는 부서와 개인에게도 큰 이익과 인사고과의 결과를 선사하기 때문에 정말로 의미 있고 중요한 업무가 된다. 다만, 이러한 0순위 업무의 구분을 해야 하는 경우에는 해당 조직과 회사에 당연하게도 인사고과나 인사정책 또한 잘 구성되어 있는 경우에만 이러한 우선순위의 결정이 의미가 있다. 또한, 결정되어지는 긴급한 의사결정에 대해서 신속하고 명확한 의사전달과 의사소통이 가능한 집단의 경우에게만 이러한 ‘0순위 업무’에 대한 정의가 가능하다.앞서 이야기한 인사정책이나 의사소통이 불분명한 조직에서는 아무리 ‘고객’이 당장 원하는 ‘서비스’와 ‘제품’이라고 하더라도. 소프트웨어 개발 조직에서는 생뚱맞게 튀어나온 불특정 한 업무로 밖에 받아들이지 않는다.그러한 ‘문화’와 ‘환경’을 갖추고 있지 않는 기업이라면, 이러한 ‘0순위 업무’는 가능한 발생시키지 않는 것이 최선이다. 그리고, 다음의 ‘불필요한 일’을 구분하는 정도로만 진행하는 것이 더 효과적일 수 있다.하지만, 잘 갖추어지고 유연한 소프트웨어 개발 조직에서는 이러한 이벤트적인 최고 결정사항을 발 빠르게 대처할 수 있다. 이러한 일들은 말 그대로, 잘 수행된 이후에 기업도 이익이고 부서도 신바람 나고, 개인도 업무 고과에서 큰 영향을 받을 수 있는 일이므로, 기업에 가장 큰 이익과 긍정적인 효과를 매우 크게 안겨다 주는 업무가 된다.가장 중요한 ‘문화’가 성립되어진 기업과 조직은 어떻게든 이러한 ‘0순위 업무’를 정말 잘 필터링하는 것이 해당 기업의 점진적인 성공과 성패의 최우선적인 결정사항이 될 것이다.보통 이러한 결정은 어느 정도 회사의 서비스와 제품이 성공적으로 시장에 안착한 다음, 시장이 확대되거나 해외 수출 등의 매출이 급속도로 증가하는 시점에서 심각하게 고려해야 할 사항들이다.그렇다면, 이러한 요구사항이나 업무는 어떤 식으로 결정하는 것이 최선일까? 여러 가지 의견이 있지만, 크게 두 가지로 나눌 수 있다. 하나는 대부분 이러한 업무는 특정 체크리스트와 회의에 의해서 결정될 수도 있다는 점. 또 다른 하나는 리더십을 가진 사람이거나 경험이 풍부한 사람이 직감과 경험에 의존하는 것이다.과연 어떤 방법이 효과적일까? 프로세스로 이러한 0순위 업무를 결정할 것인가? 직감과 경험에 의존할 것인가? 두 가지 모든 것을 고려할 것인가에 대해서는, 각 조직과 기업의 성격에 따라서 조금씩 다르다.다만, 정말 중요한 것은 ‘0순위 업무’를 제대로 구분하고, 이를 정하는 일련의 작업들을 수행하고 있는가 하는 점을 먼저 판단하는 것이다. 보통 이런 ‘0순위 업무’들은 너무도 명확하기 때문에 잘 드러나서 경험과 직관으로 결정하는 것이 더 효과적인 경우가 많다. 경험이 풍부한 고급 개발자나 아키텍트와 같은 인력을 보유하는 절대적인 이유이기도 하다.하지만, 문화적인 형성도 힘들고, 고급인력도 없다면, 다음의 ‘쓸데없는 일’을 찾는 것에 중점을 두어보자.현재 상황에서 ‘쓸데없는 일’을 구분하자.대부분의 소프트웨어 개발 조직에서 가장 잘해야 하는 작업은 정말로, '쓸데없고 필요 없는 일'을 구분하는 것이다. 냉정하게 지금 당장 필요 없는 업무, 해도 그다지 성과가 없는 업무, 의미가 부족한 업무 등이 이에 해당된다. 대부분 이러한 업무들의 대부분은 '업무의 가치'가 불명확한 경우와, 누가 만들고 요구한 것인가? 에 대한 요건이 불명확한 경우가 많다.이 두 가지에 해당되는 내용들이라면, 대부분 쓸데없는 일이나 요구사항으로 구분하여 정리하고 처리해야 한다. 물론, 요구사항의 수집이 잘못되었을 수 있지만, 그것은 수집의 문제에 대해서 다시 논하기로 하자. 요구사항 수집 공학과 관련된 이야기도 칼럼 중에 한번 이야기해야 할 내용이다.하여간 이러한 ‘쓸데없는 일’들은 분명, 현재의 작업에 등록되어 있고, 누군가가 하고 있으며, 어떤 지시에 의해서 실제 수행되는 경우가 상당수 존재한다. 이러한 대부분의 일들과 요구사항들을 살펴보면, 현재 등록되어진 대부분의 업무들 중에 10가지 중에 1~2가지 일들은 대부분 타성적으로 흘러 지나가는 경우가 대부분인 경우가 많다. 냉정하게, 현재 등록되어진 요구사항이나 업무에 해당하는 것들의 10~20%는 정말 '쓸데없는 일'들이 많다. ( 지금 당장 업무의 Task를 살펴보면, 이런 쓸데없는 일들을 찾을 수 있다. 왜? 자신도 모르게 버퍼 삼아서 등록해 놓은 업무, 팀장이 버퍼로 등록한 업무까지 정말 많다. )또한, 그 이외에도 대부분이 비즈니스 환경이 변하거나, 업무를 지시한 상사의 변덕 등으로 사라지는 업무들도 이에 해당한다고 볼 수 있다. 이러한 업무들은 해당 이벤트와 상황에 따라서 후순위로 처리되거나 하지 말아야 할 것들에 해당한다. 그렇다면, 이러한 쓸데없는 일들을 어떻게 구분해 내는가? 가장 대표적으로 구분하는 방법은 ‘만들어진 보고서’와 ‘결과물’이 소홀하게 관리되는 경우가 대부분 이에 해당한다고 보면 되겠다.이러한 쓸데없는 일들의 결과들을 살펴보면, 정말 심한 경우 보고서나 결과물에 대해서 보고를 받는 시간 10~20분 정도의 대충하는 경우도 많은 것이 대부분이다. 그리고, 실제로 관료화된 조직에서는 이러한 많은 업무들이 필요 없는 업무들로 구성되어진다.소프트웨어 개발 조직이 관료화된다는 것이 얼마나 비효율적인가 하는 점은 굳이 첨언하지 않아도 대부분의 개발자들이 잘 알고 있을 것이다. 소프트웨어 개발 조직이 관료화되어있다고 생각한다면, 대부분의 '소프트웨어 개발 업무'들은 쓸데없는 일에 30~40%의 일을 소모하고 있는 경우가 대부분이라고 봐도 무방하다.그래서, 이러한 업무들을 구분하는 방법으로는, '업무가 추진되고 나온 결과물'을 검토하는 시간과 결과물에 대한 반응을 살펴본후, 그 반응이 어떻게 내재화되는지에 대해서 검토하여 보면 대부분 알 수 있다.또한, 해당 서비스나 라이브러라, 산출물들이 얼마나 재활용되고 있으며, 효과적으로 반영되고 있는지에 대한 평가도 같이 하면, 이러한 ‘쓸데없는 일’을 찾아낼 수 있다. 대부분 이러한 업무들의 대표적인 것들이 냉정하게 신입사원들 대부분의 업무가 그러하고, 선임 직원들은 관성에 따라서 만들어 내는 업무들이 대부분 이러한 경우가 많다. 또한, 습관적으로 중복적인 업무들도 많이 발생한다. 이러한, 업무의 누수를 어떻게 잘 검토해 내느냐가 관건이고, 정말 필요한 일을 잘 판단하는 기본적인 체크를 할 수 있는 방법을 만들어야 한다.이러한 분리된 스텝으로 정말 필요한 일과, 정말 필요 없는 일을 구분하는 것만 체크하고 점검하여 진행하여도, 업무의 우선순위는 대부분 정해지고, 불필요한 일과 쓸모없는 일들을 제거할 수 있다. 물론, 냉정하게 이러한 업무를 제대로 해야 하는 것이 중간관리자나, 팀장들이 일을 잘하는 경우에 해당되겠다. 또한, 효과적인 의사소통이 많아지고, 효과적으로 대응하는 경우에 이러한 업무의 구분이 보다 명확해진다. (* 그렇다고, 의사소통을 많이 하겠다고, 회의시간만 길게 잡는 것 또한 불확실한 일처리를 의미한다. 대부분 그 방법은 해당 조직들이 더 잘 알고 있다. 어떤 장소에서 어떤 시간이 더 많은 대화를 나누는 것인지 잘 알고 있다. )최소한의 이러한 구분이 가능하다면, 좀 더 업무의 우선순위를 좀 더 세분화하여 정의할 수 있게 시도할 수 있다. 그것은 소프트웨어 개발에 있어 정말 중요한 정말 고품질을 요하는 업무와 적정한 품질로 처리해야 하는 업무에 대한 구분이다. 필자의 경험에 따르면 정말 고품질을 요하는 소프트웨어 개발의 범위는 전체 프로젝트 범위의 30%를 넘어선 적이 없다. 대부분은 변화가 있으며, 단순 처리되는 내용들이므로, 적절한 품질로 대응이 가능하다.단순한 crud성 화면 프로그램에 엔진에서 검토해야 하는 품질 절차와 리소스를 투입하는 바보 같은 짓을 되풀이해서는 안된다. 전체적인 품질 테스트에서도 충분하게 검토될 내용과, 단위 테스트와 아키텍처적인 관점에서 접근해야 하는 고품질의 영역을 제대로 구분해 내는 것 또한 소프트웨어 개발의 요구사항을 효과적으로 대응하는 것이다.해야 할 일중에 정말로 고품질을 요하는 소프트웨어 개발업무를 구분하자성과가 명확하게 보이는 개발업무로써, 해당 소프트웨어의 개발된 서비스의 실체와 가치가 완벽하게 드러난 일이다. 또한, 해당 서비스나 소프트웨어가 다른 개발팀이나 다른 서비스에 많은 영향을 주는 영역의 개발이라면 당연하게도 ‘고품질’이 요구된다.다만, 0순위처럼 '그 이익'이 정량화되지는 않았으나, 정성적인 기준에 의해서 그 가치가 명확해진 개발업무들이라고 보면 된다. 대부분 이러한 일들은 '요구사항'의 변화가 거의 없을뿐더러, 관료조직의 극성인 변덕스러운 직장상사도 필요한 요구사항을 틀지 못하는 경우가 많은 서비스이거나 업무에 해당한다.또한, 이러한 대부분의 고품질 개발일은 이러한 '최선을 다해야 하는 일'인 경우이다. 하지만, 업무 순위를 결정할 때에 잘못하는 것 중의 하나가. 매일, 매번 이러한 '최선을 다해야 하는 일', ‘고품질’로 결정되어진다는 것이다. 그렇지만, 그렇게 결정된 ‘고품질 속성’은 잘못 결정된 판단일 가능성이 높다. 고품질은 많아야 전체 업무의 30% 정도이다. 그 이상으로 책정된다면, 평가기준부터 잘못된 것이므로 다시 살펴봐야 한다.물론, 정확하게 일에 대해서 살펴보면 이렇게 구분하는 것은 대단한 업무 처리능력을 가진 기업이나 조직일 수 있겠지만. 그런 식으로 제대로 관리하는 기업은 한 번도 본 적이 없다. 관리의 S기업도 그렇게 정의하지는 않고, 안전이 가장 중시되는 항공기 관련 소프트웨어 개발에 있어서도 그런 식으로 기준을 정하지는 않는다. 이런 식으로 대부분의 업무가 '고품질'로 책정된다면, '업무의 중요도'를 잘못 판단하고 있는 것이다. 그러므로, 기준 작업과 검증작업을 다시 해야 한다.다만, 개발업무내용에서 그 사용가치를 찾기 힘들고, 만들어진 결과물 또한 다른 서비스나 개발 조직에 별다른 기여를 하지 못할 것이 명백하지만, 최선을 다해야 하는 개발업무가 있다. 그것은 '사장님' 또는 개발 총괄 책임자가 만들어낸 업무이다. 그것은, 개발업무 우선순위에 있어서 '책임'은 윗분들이 결정한 것이기도 하지만, 고위층의 경영적인 판단에 의해서 움직이는 전략적인 업무일 수 있다.보통 이러한 사항들은 '경영진의 의사결정'이기 때문에, 우선순위를 중요하게 책정해야 한다. 그리고, 이러한 ‘업무의 성격’은 명확하게 ‘요구사항’이나 ‘업무’에 명시가 되어야 한다. 그래야, 개발 조직은 개발함에 있어서 주저함이 없을 것이다.대부분은 고품질이 아니며, 적절한 품질요건으로 만족하는 개발 영역대부분의 '쓸데없는 일'이 아닌 보통의 개발업무들의 경우에 이 4번째에 해당한다. 이 소프트웨어 개발업무는 고품질이 아닌, 해당 개발업무의 기본적인 완성도만 추구하면 되는 일이다.또한, 이러한 업무들은 대부분 QC와 QA의 업무가 구분되어져 있고, 해당 리소스를 투입하고 있는 경우에는 이 부분으로 처리가 되는 경우가 더욱더 많이 정의되게 된다. 가능한, 품질관리에 투입되는 리소스를 최소화하는 것이 전체적인 개발의 성과를 향상하게 된다. 소프트웨어 개발업무를 어떻게 하든 이 영역을 80% 이상으로 끌어올리는 것이 개발을 효과적으로 수행하게 하는 것이다. 필자의 경험에 따르면 ‘고품질’은 20%, ‘저품질’은 80%의 영역으로 설정하고, 고급 리소스는 ‘고품질’에 투입하도록 하는 것이 가장 합당하다.일반적으로 소프트웨어 개발업무의 대부분의 구성 업무들은 이러한 '적당하게 해야 하는 업무'이다. 이 업무에는 '에너지'와 '시간'을 낭비하면 안 된다. 말 그대로, 적정하게 해야 한다. 그리고, 개발자들에게 ‘잉여’를 공급하게 하고, 반복적인 테스트와 품질 검토는 품질관리 조직에서 다양한 방법으로 접근하고, 문제의 발생을 추적하여 통보하여, 품질관리를 분리하는 것이 최선이다.‘고품질’은 품질의 주요한 권한과 책임을 ‘개발자’에게 주는 것이고, ‘저품질’은 품질을 프로세스에서 검토하여 통보하는 방법으로 수행하는 것이다. 이는 개발 조직의 최대한의 역량을 ‘고품질’에 집중하게 하고, 단순 반복 테스트와 같은 업무를 소프트웨어 개발 조직에 있어서 가장 중요한 ‘개발 조직’을 효과적으로 활용하게 하는 것이다.물론, 이러한 품질 관련 업무의 가장 중요한 고려사항은 직장상사나 동료들과의 커뮤니케이션을 가장 중요시하게 된다. 이러한 업무의 대부분은 '신뢰'가 전제가 되어야 하기 때문이다. 또한, 여기서 가장 중요한 것은 '신뢰받는 직장상사'와 ‘신뢰받는 부서’의 업무지시가 가장 핵심이 되게 된다. 또한, 이러한 업무의 우선순위가 정치적/심리적 변화에 따라서 변화되는 요구사항은 제대로 된 업무가 아닌 것이 된다. 이 부분이 가장 중요하다.일반적으로 이해하고 있는 에자일의 핵심적인 요소는 위에서 잠시 설명한 ‘신뢰’를 어떻게 의사소통하느냐가 관건이다.결론적으로 이야기하자면 소프트웨어 개발업무에 있어서 ‘업무의 우선순위’를 결정하는 요구사항을 분석하는 데 있어서 최고의 핵심 요소는 다음의 5가지를 잘 정의하는 것이다.1) 업무의 가치2) 업무의 원천( 누가 만들고 요구한 것인가? )3) 기업의 가치 추구4) 직장상사와 동료의 가치 추구5) 고품질이 정말 필요한 업무의 구분이러한 4가지의 관점을 어떻게 정성적이고 정량적인 방법으로 도출하며, 이를 의사소통하여 공통 관심사를 형성하느냐에 달려있다. 하지만, 현대의 관료화된 조직의 대부분들은 쓸모없는 요구사항들이 상당수를 차지하며, 해당 조직의 스트레스에서의 핵심 요소가 된다는 점이다.이와 같이 업무의 요구사항들을 어떻게 구분하는 것인가부터 시작하는 것이 '요구사항 공학'의 기본적인 정의이다. 냉정하게, '업무의 가치'는 그 기업과 조직이 가지고 있는 '비전'과 '골'에 영향을 받는다.그러므로, 경영진이 가장 똑똑해야 그 기업의 가치가 증대된다. 언제나 이야기하지만 경영자의 삽질을 이길 수 있는 슈퍼 개발자는 존재하지 않는다. 그것은 기적이다.

Q) 안녕하세요 Juan Carlos(환 까를로스)님 자기소개 부탁드려요.네 안녕하세요. 지금 immersive 6기에서 개발자가 되기 위해 열심히 공부하고 있는 환 까를로스라고 합니다. 어쩌다보니 immersive 6기에서 전문 네비게이터로 생활하고 있어요.(웃음) 네비게이터는 페어프로그래밍을 할 때 드라이버가 코딩을 할 수 있도록 큰 그림을 그려주는 거라고 생각하시면 되요. 페어와 같이 코딩을 하면서 Immersive를 헤쳐나가고 있습니다.Q) 코드스테이츠 오시기 전에는 어떤 일을 하셨었나요?해외영업을 했습니다. 이 일을 선택한 이유는 조금 특별해요. 제가 취준생이었을 때 회사를 여러 곳을 지원을 했었습니다. 지원한 기업에서 합격 통보를 받았죠. 근데 막상 그 기업에 입사하려고 보니까 지방에서 근무를 해야 하는 거예요. 그전까지는 이런 것들을 생각도 안 하고 있다가, 막상 닥치니까 곰곰이 생각하게 되었어요.'내가 서울을 떠나서 잘 살 수 있을까?' 지방에서 산다는 거에 대해서 크게 생각하고 있지 않았었는데, 막상 닥치니까 고민이 많이 되더라구요. 제가 서울 토박이인데, 고향을 떠나서 사는 거는 제가 너무 힘들 것 같아서 포기하고 지금 현 직장(지금은 퇴사를 했죠)에 다니게 된 거예요. 그리고 제가 공대 출신인데 공대 출신이 서울에서 직장을 잡으려면 영업 밖에 없더라구요. 그래서 영업직을 선택했었습니다.Q) 그럼 직장을 나오게 된 계기가 있으신가요?새로운 것을 수용할 생각이 없는 경직된 조직문화가 너무 안 맞았어요. 저는 신입을 뽑는 이유는 조직이 시장의 흐름이나 세대의 변화에 맞춰 변하기 위해서라고 생각해요. 근데, 전에 팀은 변할 생각을 안 하더라고요. 야근까지 해가면서 업무개선을 해도 기존 방식을 고수하자는 피드백이 계속되니 열정이 사라지는 것을 느꼈죠. 제가 4년 정도 다녔는데, 퇴사를 고민하고 3시간 만에 결정하고 사표를 내고 나왔어요.저는 뭔가 다양한 경험을 하고 제 스스로가 발전하는 걸 좋아하는데, 발전한다는 느낌이 없었죠. 부서를 여러 곳으로 옮긴 이유도 제가 정확히 뭘 좋아하는지 모르니까 이것저것 해보면 알지 않을까 생각했어요. 영업 파트에서 일하면서도 기획부터 경영지원까지 다양한 일을 맡았었죠.Q) 3시간이면 정말 짧네요! 보통은 여러 번 고민하기 마련인데요. 그럼 퇴사하시고 나서는 무엇을 하셨나요?음... 사실 퇴사하고 나서 제가 맡았던 고객들이 경쟁사로 이직할 수 있게 도와주겠다고 하셔서 고민을 많이 했어요.  근데, 이왕 퇴사했는데 새로운 걸 해보고 싶었어요. 한 군데 계속 있으면 뭐랄까.. 나태해지는 것 같아서요.- 다른 분야의 직장을 잡으신 건가요?일단은 여행 가야지라고 생각해서, 스페인으로 떠났어요.  첫 번째로는 스페인의 순례길을 가기로 했죠. 1000km 정도 되는 길을 걸었던 것 같아요. 순례길을 걸으면서 다양한 사람들을 만나고 생각도 정리도 좀 하고 그랬어요. 거기에는 전 세계 퇴사한 사람이 다 모이는 것 같아요. 숙소에서 만난 친구들에게 물어보면 죄다 회사를 퇴사하고 왔다고 하더라구요(웃음) 그리고 그곳에서 개발자가 돼야겠다는 마음을 먹었습니다.Q) 어떤 경험을 하셨길래 그곳에서 개발자가 돼야겠단 마음을 먹으셨나요?먼저 이 얘기를 해야 하겠네요. 사실 제가 여행경비가 이렇게 많이 들지 몰랐어요. 순례길을 여행하다가 돈도 떨어져 가는데 직업이 있는 채로 순례길을 도는 사람들을 만나게 된 거예요. 세 명을 만났는데, 세 명 다 소프트웨어 엔지니어였습니다. 처음에는 브라질 개발자를 만났어요. 그때까지만 해도 별생각이 없었죠. 다음으로는 러시아 개발자를 만났습니다. 러시아 개발자 친구를 보면서 아 이런 게 디지털 노마드구나라는 생각을 갖게 되었죠. 그리고 마지막으로 스페인 개발자 친구를 만나니까 정말 개발자라는 직업이 부럽게 느껴지더라구요. Q) 디지털 노마드를 보고 개발자가 돼야겠단 결정을 하신 거네요! 그럼 코드스테이츠를 선택해주신 이유가 있으신가요? 아까 제가 생각보다 여행 경비가 많이 드는지 몰랐다고 했잖아요. 순례길만 여행하는데도 여행 경비가 다 떨어진거에요(웃음) 그래서 어쩔 수 없이 세계 여행의 꿈을 접고 한국으로 오게 되었죠. 그리고 한국으로 돌아오는 비행기 안에서 개발자가 되기로 결심을 했습니다. 내가 여행을 다니고 하고 싶은 것을 하면서도 일도 하고 그게 너무 좋아 보이는 거에요. 물론 한국의 현실은 많이 다르겠지만 그래도 개발자라면 가능하지 않을까라고 생각을 했습니다. 그리고 그 비행기에서 핸드폰으로 코딩 관련해서 검색을 하다가 코드스테이츠를 알게 되었어요. 알아보니까 교육철학도 좋고 저에게도 괜찮은 방식을 것 같아서 그 비행기 안에서 바로 결정을 하게 되었습니다. 퇴사할 때와 마찬가지로 일사천리로 결정을 했습니다.- 비행기 안에서 모든 결정이 이루어졌네요! 3시간 만에 퇴사를 결정하신 것 같이요!뭐 망설일 이유가 있나요. 자신감과 결단력 그게 제 장점이니까요(웃음)Q) 그럼 이제 Immersive 얘기를 해볼게요. Immersive에서의 생활은 어떠세요?생각했던 것보다 여유가 있어서 좋아요. 그전에는 되게 불안하고 빡빡하고 그럴 것 같은데 막상 해보니까 할만하더라고요. 그리고 일단 사람들이 너무 좋아요. 같이 지내는 사람들이 좋으니까 Immersive도 할만한 것 같아요.Q) 그러면 지금 Immersive에서는 어떤 것을 배우고 있나요?서버를 배우고 있어요. 프론트 쪽 하구요. 프로젝트를 하고 적용을 해봐야 완전히 내 것으로 만들 수 있을 것 같아요. 역시 직접 적용을 해봐야 정확히 알 수 있을 것 같습니다.서버를 배우고 있어요. 프론트 쪽 하구요. 자바스크립트라는 언어의 다양한 문법을 매일 체험해보고 있어서, 매일매일이 새롭습니다. (뭔가 이해할 만 하면 다른걸 배워서..) 프로젝트를 해봐야 완전히 내것으로 만들 수 있을 것 같아요.Q) 앞으로 어떤 개발자가 되고 싶으세요?거창하게 세상을 바꾸는 개발자! 이런 건 제 스타일은 아니에요(웃음) 저는 제가 하고 싶은 것을 하는 개발자. 만들고 싶은 것을 만드는 개발자가 되고 싶어요. 세상을 바꾸는 개발자도 내가 좋아하는 것, 내가 하고 싶은 것, 내가 만들고 싶은 것을 만드는 개발자가 되었을 때 가능하지 않을까요?Q) 프로젝트를 곧 하게 될 텐데 어떤 프로젝트를 하고 싶으신가요?제 경험에 기반한 프로젝트에요. 우리는 회사에서 주는 돈 그냥 받잖아요. 제가 회사를 나오고 받았던 돈들을 확인해보니 제대로 받지 못했다는 것을 알았어요. 그래서 사람들이 노동의 정당한 보상을 알고 받을 수 있도록 도와주는 프로그램을 만들고 싶어요. 주변만 봐도 대부분의 사람들이 이런 문제로 인해 문제를 가지고 있다고 생각해요.Q) 1년 후에 개발자가 되었다고 생각하면 어떤 모습일까요?개발자가 될 수 있을까요?(웃음) 아마 1년 후엔 야근에 쩔어있지 않을까요? 저는 이게 내 일이다라는 생각을 하면 엄청 파고드는 스타일이거든요. 개발자로 처음 들어간 직장에 남아 있거나 이직을 하고 있을 것 같아요. 사실 저는 계획을 잘 안 세우거든요. 그러니까 아무 준비 없이 퇴사하고 개발을 배우고 있죠. 설마 굶어죽기야 하겠어요?Q) 마지막으로 하고 싶은 말이 있나요?제가 퇴사하면서 방 정리도 같이 하게 됐어요. 정리를 하다 보니까 우연찮게 제 학창시절 생활기록부를 보게 되었습니다. 생활기록부에 장래희망을 적는 칸이 있잖아요. 근데 제가 깜짝 놀란 게 거기에 중학교 때부터 고등학교 때까지 줄곧 프로그래머로 적혀있던 거에요. 그동안 까맣게 잊고 살았는데 신기했어요.그리고 또 생각을 해보니까 대학교 때도 제가 컴공과는 아니지만 공대라서 C++을 해야했는데 그 과목에서 처음으로 A+을 받은 기억이 나더라구요. 이런 생각이 들면서 결국 나는 프로그래머를 선택할 운명이었나? 이런 생각도 들고. 결국에는 돌아돌아 이 길로 온 것 같아요. 그래도 돌아왔다고 해서 늦었다거나 아쉽지는 않아요. 제가 지금까지 걸어온 길이 분명히 프로그래밍을 하는데 도움이 된다고 생각하고 있으니까요.네 지금까지 환 까를로스님과의 인터뷰를 진행했었는데요. 정말 비하인드스토리가 엄청나네요. Immersive 성공적으로 수료하시고 원하시는 개발자가 되기를 바랍니다. 앞으로도 다양한 스토리를 가진 Immersive 수강생분들의 이야기로 찾아뵙겠습니다.

 안녕하세요. 크몽개발팀 입니다.오늘 포스트 주제는 Android Studio JCenter 이용하기입니다.JCenter????  JCenter에 대해 처음 들으시는분들도 있을거같은데요.JCenter는 라이브러리들이 모여있는 저장소라고 보시면 되겠습니다.그렇다면 JCenter를 이용하여 무엇을 할까요?바로 외부 라이브러리들을 가져와서 프로젝트안에 Import 할려고 합니다. JCenter 사이트 링크 : https://bintray.com/bintray/jcenterJCenter 페이지에 접속하시면 위와 같은 페이지를 볼 수 있는데요.여기서 사용하고 싶은 라이브러리를 검색해보겠습니다.제가 검색한 라이브러리는 ImageLoder 라이브러인 'Glide'를 검색했습니다.빨간색으로 표시되있는게 제가 찾던 라이브러리 입니다.검색한 라이브러리를 클릭하면 위와 같이 상세페이지를 볼 수 있는데요.라이브러리 Github 주소 와 버젼에 대한 정보를 확인할 수 있습니다.그럼 이제 검색한 라이브러리를  Android Studio Gradle에 Import 하겠습니다. Android Studio에서 프로젝트를 생성하게 되면 위와 같이 3개의 그래들 파일을 볼 수 있는데요.자주 사용할 그래들 파일은 app폴더에 있는 그래들 파일입니다.그래들 파일을 열어보면 낯익은 코드들이 보이는데요.ADT에서는 매니페스트에서 버젼관리를 햇었는데 Studio에서는 그래들로 빠진거같습니다.그리고 빨간표시를 해둔곳이 바로 JCenter에서 검색한 라이브러리를 Import 하시면 되겠습니다.  위에 JCenter에서 찾은 라이브러리명을 입력하고 뒤에 버젼번호도 같이 입력합니다.그리고 Sync 버튼을 눌러주면 라이브러리가 Import 됩니다. External Libraries를 확인해보시면 라이브러리가 추가된걸 확인할 수 있습니다.---------------------------------------------------------------------------------------이렇게 JCenter를 이용하여 간단하게 라이브러리들을 Import를 할 수 있습니다.그리고 그래들 과 JCenter를 이용하여 라이브러리를 적용할때 가장 좋은점은'com.github.bumptech.glide:glide:3.+' 이런식으로 버젼에대한 값을 주면라이브러리 상위버젼이 나올경우 자동으로 최상위 버젼으로 라이브러리를 Import 해준다는 점입니다.이로써 라이브러리 버젼관리도 많이 편해질거 같습니다.이것으로 Android Studio JCenter 이용하기 포스트를 마치겠습니다.#크몽 #개발팀 #인턴 #인턴생활 #인사이트

[LG CNS 채용 시리즈 3]LG CNS 입사에 대한 모든 것!신입사원 이열정씨가 입사할 수 있었던 비결은?▶ LG CNSer 가 되고 싶다면?https://goo.gl/fAUEYo#LG #LG그룹 #LGCNS #IoT #IT #IT채용 #LGCNS블로그 #LGCNS채용 #R&D #SW개발 #공채 #박사 #보안 #블록체인 #빅데이터 #석사 #스마트에너지 #스마트팩토리 #신입사원 #아키텍처 #인공지능 #인프라운영 #일터 #채용 #취업 #취직 #컨설팅 #클라우드 #플랫폼개발 #하반기공채 #하반기신입사원채용 #하반기채용 #학사

비트윈에서는 서비스 초기부터 HBase를 주요 데이터베이스로 사용하였습니다. HBase에서도 일반적인 다른 NoSQL처럼 트랜잭션을 제공하지 않습니다. HBase, Cassandra와 MongoDB는 하나의 행 혹은 하나의 Document에 대한 원자적 연산만 제공합니다. 하지만 여러 행에 대한 연산들을 원자적으로 실행할 수 있게 해주는 추상화된 트랜잭션 기능이 없다면 보통의 서비스 개발에 어려움을 겪게 됩니다. 비트윈 개발팀은 이런 문제를 해결하기 위해 노력했으며, 결국 HBase에서 트랜잭션을 제공해주는 라이브러리인 Haeinsa를 구현하여 실제 서비스에 적용하여 성공적으로 운영하고 있습니다. VCNC에서는 Haeinsa를 오픈소스로 공개하고 이번 글에서 이를 소개하고자 합니다.Haeinsa란 무엇인가?Haeinsa는 Percolator에서 영감을 받아 만들어진 트랜잭션 라이브러리입니다. HAcid, HBaseSI 등 HBase상에서 구현된 트랜잭션 프로젝트는 몇 개 있었지만, 성능상 큰 문제가 있었습니다. 실제로 서비스에 적용할 수 없었기 때문에 Haeinsa를 구현하게 되었습니다. Haeinsa를 이용하면 다음과 같은 코드를 통해 여러 행에 대한 트랜잭션을 쉽게 사용할 수 있습니다. 아래 예시에는 Put연산만 나와 있지만, 해인사는 Put외에도 Get, Delete, Scan 등 HBase에서 제공하는 일반적인 연산들을 모두 제공합니다.HaeinsaTransaction tx = tm.begin(); HaeinsaPut put1 = new HaeinsaPut(rowKey1); put1.add(family, qualifier, value1); table.put(tx, put1); HaeinsaPut put2 = new HaeinsaPut(rowKey2); put2.add(family, qualifier, value2); table.put(tx, put2); tx.commit(); Haeinsa의 특징Haeinsa의 특징을 간략하게 정리하면 다음과 같습니다. 좀 더 자세한 사항들은 Haeinsa 위키를 참고해 주시기 바랍니다.ACID: Multi-Row, Multi-Table에 대해 ACID 속성을 모두 만족하는 트랜잭션을 제공합니다.Linear Scalability: 트래픽이 늘어나더라도 HBase 노드들만 늘려주면 처리량을 늘릴 수 있습니다.Serializability: Snapshot Isolation보다 강력한 Isolation Level인 Serializability를 제공합니다.Low Overhead: NoSQL상에서의 트랜잭션을 위한 다른 프로젝트에 비해 오버헤드가 적습니다.Fault Tolerant: 서버나 클라이언트가 갑자기 죽더라도 트렌젝션의 무결성에는 아무 영향을 미치지 않습니다.Easy Migration: Haeinsa는 HBase를 전혀 건드리지 않고 클라이언트 라이브러리만 이용하여 트랜잭션을 구현합니다. 각 테이블에 Haeinsa 내부적으로 사용하는 Lock Column Family만 추가해주면 기존에 사용하던 HBase 클러스터에도 Haeinsa를 쉽게 적용할 수 있습니다.Used in practice: 비트윈에서는 Haeinsa를 이용하여 하루에 3억 건 이상의 트랜잭션을 처리하고 있습니다.Haeinsa는 오픈소스입니다. 고칠 점이 있다면 언제든지 GitHub에 리포지터리에서 개선에 참여하실 수 있습니다.Haeinsa의 성능Haeinsa는 같은 수의 연산을 처리하는 트랜잭션이라도 소수의 Row에 연산이 여러 번 일어나는 경우가 성능상 유리합니다. 다음 몇 가지 성능 테스트 그래프를 통해 Haeinsa의 성능에 대해 알아보겠습니다.아래 그래프는 3개의 Row에 총 6개의 Write, 3개의 Read연산을 수행한 트랜잭션의 테스트 결과입니다. 두 개의 Row에 3Write, 1Read 연산을 하고, 한 개의 Row에 1Read 연산을 한 것으로, 비트윈에서 가장 많이 일어나는 요청인 메시지 전송에 대해 시뮬레이션한 것입니다. 실제 서비스에서 가장 많이 일어나는 종류의 트랜잭션이라고 생각할 수 있습니다. 그런데 그냥 HBase를 사용하는 것보다 Haeinsa를 이용하는 것이 더 오히려 좋은 성능을 내는 것을 알 수 있습니다. 이는 Haeinsa에서는 커밋 시에만 모든 변경사항을 묶어서 한 번에 반영하기 때문에, 매번 RPC가 일어나는 일반 HBase보다 더 좋은 성능을 내는 것입니다.HBase 클러스터가 커질수록 트랜잭션 처리량이 늘어납니다. HBase와 마찬가지입니다.HBase 클러스터의 크기에 따른 응답시간 입니다. HBase와 다르지 않습니다..아래 그래프는 2개의 Row에 각각 한 개의 Write, 나머지 한 개의 Row에는 한 개의 Read 연산을 하는 트랜잭션에 대해 테스트한 것입니다. 각 Row에 하나의 연산만이 일어나기 때문에 최악의 경우라고 할 수 있습니다. 처리량과 응답시간 모두 그냥 HBase를 사용하는 것보다 2배에서 3배 정도 좋지 않은 것을 알 수 있습니다. 하지만 이 수치는 DynamoDB 상의 트랜잭션과 같은 다른 트랜잭션 라이브러리와 비교한다면 상당히 좋은 수준입니다.HBase보다 처리량이 떨어지긴 하지만, 클러스터가 커질수록 처리량이 늘어납니다.HBase보다 응답시간이 크긴 하지만 클러스터 크기에 따른 변화가 HBase와 크게 다르지 않습니다.프리젠테이션Haeinsa에 대한 전반적인 동작 원리와 성능을 소개하는 프리젠테이션입니다. 좀 더 자세히 알고 싶으시다면 아래 프리젠테이션이나 Haeinsa 위키를 참고해주세요.<iframe class="speakerdeck-iframe" frameborder="0" src="//speakerdeck.com/player/2d4b2bd00fc201314ae312fe4cd13937?" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true" style="border: 0px; background: padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 750px; height: 563px;">

최근의 가장 핫한 연구분야인 '자율주행'의 바탕에는 '컴퓨터 비전'이 필요하다는 사실을 아셨나요? 홍채인식, 스노우 어플도 '컴퓨터 비전'을 사용한 사례입니다. 우리의 가까이 다가와 있지만, 기술 자체에 대해서는 어딘가 생소합니다. 어반베이스의 CV개발자 대희님이 멀고도 가까운 컴퓨터 비전의 모든 것을 알려드립니다!멀고도 가까운 컴퓨터비전(CV)의 모든 것Q. 간단한 자기소개를 해주세요.네, 안녕하세요. 어반베이스에서 컴퓨터 비전(CV) 개발자 윤대희라고 합니다.Q. CV가 생소한 분들이 많을 것 같아요. CV에 대해 쉽게 설명 부탁드려요.CV는 컴퓨터비전(Computer Vision)의 약자에요. 쉽게 말해 컴퓨터가 인체라면 '눈'역할을 담당해요. 카메라를 사용해 입력받은 이미지나 영상을 프로세싱하면 '컴퓨터 비전 처리했다'고 말해요. 예를 들면, 카메라 어플 내에서 얼굴을 인식한 후에 안경을 달아준다거나, 눈을 크게 해준다거나 그런 것들을 컴퓨터 비전에서 처리할 수 있는 거죠. Q. 그렇다면 컴퓨터 비전의 시작은 언제부터인가요? 최근에 생긴 기술 같은데요. 그렇지 않아요. CV의 시작은 60년대부터 있었어요. (60년대요?) 네. 달 표면을 찍은 위성 사진의 화질을 개선하기 위해 디지털 이미지 프로세싱 분야가 탄생했어요. 그동안 기술력이 뒷받침되지 않아서 무언가를 할 수 없었을 뿐이에요. 하드웨어, 즉 카메라 장비나 처리 기술이 발전하면서 이제서야 붐이 일어난 거죠. Q. CV 개발이 활발히 이루어지는 분야가 있을까요?핸드폰 카메라 어플, 자율주행, 홍채인식 등에도 모두 CV가 필요해요.특히 요즘 떠오르고 있는 분야가 자율 주행이에요. 자율주행을 하려면 주행 시 주위 환경을 모두 살펴해야 해요. 차선이나 신호, 보행자와 차량도 봐야 하죠. 실시간으로 영상을 인식하고 처리하는 분야이니 CV 개발이 활발해요.의학 쪽에서도 많이 써요. MRI 사진을 찍은 후 세포의 영역을 볼 때, 의사가 그 모든 세포를 볼 수가 없으니까 CV 처리를 한 후 이상이 있는 세포의 특징만 뽑아내는 거죠. 아까 말씀드렸듯이 항공 쪽에서는 옛날부터 많이 썼어요. 최근에는 무인 우주선의 이미지 분석에 사용돼요. 무인 우주선에서 여러 가지 이미지 데이터를 보내오는데, 기상상황에 의해 이미지를 제대로 판단하지 못하는 경우가 있어요. 그래서 이런 이미지들을 보정하거나 특징을 뽑아내는, 전처리 과정을 CV 통해 해야 해요. 자율주행의 차량인식스노우 어플 (출처 : 스노우 앱 페이지)홍채인식 (출처 : 삼성전자 블로그)Q. 컴퓨터 비전에 대해 조금 더 자세히 알 수 있을까요?최근에 나온 명함인식 어플도 컴퓨터 비전을 사용해요. 명함에 사람의 사진이 붙어 있는 경우도 CV를 통해서 인식하게 될 거예요. 컴퓨터의 입장에서 사람의 얼굴은 공통적인 특징이 있어요. 눈 밑, 코 밑은 어두울 것이고 광대 이마 등은 밝을 거예요. 이런 패턴을 분석해서 명함 내의 얼굴을 인식하게 만드는 것이 CV에요.Q. 제가 알기론 머신러닝도 이미지를 인식하고 분류해주는 역할이라고 알고 있어요. 컴퓨터 비전과 머신러닝은 어떻게 다른 건가요?간단히 말해 컴퓨터 비전은 '눈', 머신러닝은 '뇌' 역할이죠.CV는 머신러닝에 앞선 전처리를 해주는 역할이에요. 앞서 말했듯 CV를 통해 사람 얼굴을 인식할 수 있어요. 우리 모두 눈 밑, 코 밑은 어둡고 광대 이마는 밝게 인식되겠죠. 하지만 사람마다 패턴이 미묘하게 다를 거예요. 또한 같은 사람이라도 각도나 조명에 의해 패턴이 달라질 거고요. 그래서 이런 패턴을 분석해주는 게 머신러닝이에요.'사람'을 분류해주는 건 CV로, 그 사람들 중 '홍길동'을 인식하는 것은 머신러닝인거죠.사람을 분류해주는 건 CV, '홍길동'을 인식하는 건 머신러닝CV 개발자, 어떻게 시작했나요?Q. 개발자가 되기까지의 과정이 궁금해요. 원래 컴퓨터공학을 전공하셨나요?아뇨, 기계설계를 전공했어요. 요즘은 기계 쪽에서도 공장 자동화를 기본 베이스로 하고 있어서 물건의 바코드 인식이나 라벨 색상 처리도 모두 CV의 영역이에요. Q.기계설계 중에서도 다양한 분야가 있는데, CV를 선택하신 이유가 있나요?저는 처음부터 CV를 생각했어요. 과 특성상 하드웨어 설계와 소프트웨어 설계를 동시에 하는데 저는 소프트웨어 쪽에서도 CV를 많이 했어요. CV는 다른 것에 비해서 확실히 재밌어요. 카메라로부터 받은 데이터들을 처리하는 과정이 눈으로 확실히 보이니까 훨씬 재미있게 느껴져요.Q. 운영하고 계신 블로그를 구경한 적이 있는데, 굉장히 정리가 잘 되어 있더라고요. 블로그 사이트는 어떻게 시작하게 된 거예요? 저는 누군가에게 무언가를 알려주고, 지식을 공유하는 걸 좋아해요. 제가 알고 있는 것을 함께 공유하고 공부하기 위해 블로그를 시작했어요. 어떤 것을 설명하는 방법이 그것에 대한 가장 좋은 공부법이라는 말도 있잖아요? 정보를 함께 공유하고 피드백도 받으면서 굉장히 도움이 많이 됐어요. 그래서 지금도 계속 쓰고 있어요.대희님의 블로그블로그의 강좌 목록Open CV 강좌많은 러브콜을 뒤로하고, 어반베이스에 합류하게 된 이유Q. 어반베이스의 합류 과정이 남달랐던 것으로 알고 있어요. 일종의 '스카웃 당했다'고 말할 수 있을 것 같은데요. 합류 과정을 알려주실 수 있을까요?제가 CV 온라인 강의를 진행하고 있었는데, 그때 저를 보시고 연락을 주셨어요. 강의하는 홈페이지에는 개인적인 연락처를 적어 놓지 않고 제 블로그 링크만 달아놨었어요. 그런데 제 블로그에 있는 메일 주소를 찾으셔서 연락을 주셨어요. Q. 어반베이스의 제안을 받고 어땠어요?좋았어요. 말씀해주신 업무를 제가 할 수 있을 것 같았고, 또 면접을 함께한 현우님에게 굉장히 좋은 인상을 받았어요. 부담을 안 가지고 편하게 얘기했는데 좋게 봐주셨던 것 같아요.Q. 여러 산업분야에서 CV로 할 수 있는 것들이 굉장히 많은데 어반베이스를 선택한 이유가 있을까요?확실하게 ‘사람’의 이유가 가장 컸던 것 같아요. 어반베이스에서 저를 믿고 먼저 연락을 주셨고, 함께 이야기를 나누다 보니 좋으신 분이라는 게 확실히 느껴졌어요. 사실 다른 곳에서도 연락이 많이 왔지만 일단 제 능력을 믿어주는 사람과 같이 일하고 싶었어요. 제 능력을 펼치고 싶어도 그렇게 할 수 없는 경우가 있잖아요. 하지만 어반베이스는 확실하게 제 의견을 반영해주시고 제가 하고 싶은 일을 할 수 있는 환경이라는 생각이 들었어요. 결국은 ‘사람’이 좋아서 선택한 거죠. 그게 가장 큰 이유에요. Q. 어반베이스는 VR, AR을 활용해서 공간데이터 사업을 하는 곳이잖아요. 어반베이스 비즈니스에 대한 첫인상은 어땠어요?저는 되게 좋았어요. 자동화한다는 것 자체에 메리트가 느껴졌어요.기계공학을 전공했지만 기계공학에서 건축과 닮은 부분이 있어요. 기계 도면 역시 2D로 그린 후 3D 파일을 또 만들고, 그 이후 텍스처를 설정하는 과정을 거쳐요. 분야만 다를 뿐 일련의 과정들이 건축과 굉장히 비슷해요. 그래서 막연히 '2D 도면을 3D로 바꿔주는 과정을 CV로 자동화 처리하면 괜찮지 않을까?'라는 생각을 했었어요. 분야가 기계에서 건축으로 바뀌었을 뿐, 제가 가지고 있었던 생각이랑 어느 정도 맞아떨어지더라고요. 그래서 어반베이스 비즈니스에 대한 생각이 굉장히 좋았어요. Q. 그렇다면 입사하신 이후 느꼈던 어반베이스의 개발 환경은 어때요? 굉장히 좋아요. 사람에 대한 믿음이 확실히 느껴져요. 맡은 일에 대해 믿어준다는 느낌이 있어요. 그리고 다른 분들에게 질문을 해도 항상 본인 일을 멈추고 먼저 알려주려고 하세요. 그런 모습을 보며 억압하는 분위기가 없고, 협업을 중시하고 사람을 중시한다는 걸 많이 느꼈어요. 물리적인 환경도 좋아요. 사양 좋은 맥북을 새로 사주셨거든요. 하하사양 좋은 맥북과 함께 일하는 대희님어반베이스 기술의 핵심, 도면 변환 알고리즘을 개발하다Q. 대희님이 하고 있는 일을 소개해주세요. 건축도면 이미지(2D)를 읽어서 3D 모델로 만들어주는 알고리즘을 개발하고 있어요.도면 변환에 가장 중요한 것은 좌표에요. 꼭짓점만 알면 벽을 그릴 수 있잖아요? 2D 도면상 좌표의 위치를 알아내서 벽, 문, 창문의 위치를 만들어내는 역할이에요. 좌표의 위치를 안다면 그 도면에 대해서 3D로 만들 수 있는 거죠. 3D로 만드는 과정까지 제가 담당하고 그 후의 렌더링은 3D 파트에서 담당하고 계세요. 대희님의 작업 과정Q. 업무 일과나 업무 스타일은 어때요?하루 종일 개발밖에 안 해요. 알고리즘 만든 후에 도면을 대입해서 처리가 되는지 확인하고, 오류가 있으면 수정하는 이런 패턴의 반복이죠. 어느 정도 완성이 됐다면 다음 단계로 넘어가는 거죠.제 업무 스타일은 목표한 게 있으면 끝까지 하는 스타일이에요. 해야 할 일을 정해놓고 그 일을 모두 마쳐야 퇴근해요. (막히는 경우가 생길 수도 있지 않나요?) 그러면 쉬지 않고 계속 개발하면 돼요. (웃음)Q.대희님은 어떤 분들과 협업을 많이 하나요? 2D에서 3D로 바꿔주는 도면 변환 부분, 즉 가장 베이스가 되는 부분을 만들고 있다 보니 개발 부문 대부분과 협업을 하고 있어요. 제가 만든 것을 사람들에게 보여줘야 하니까 UI/UX팀과 협업을 많이 해요. 제가 만든 API에 대해서도 이야기해야 하기 때문에 API, 백엔드팀과도 협업을 많이 하고요.Q. CV 개발자로 입사 후 가장 기뻤을 때는 언젠가요?제가 입사한 후 CV 코드 리뷰를 하고 코드를 개선해서 확실하게 좋아진 것이 보일 때 정말 좋았어요. 제 의견이 반영이 되어 바뀔 수 있었고, 결과적으로 결과도 좋았으니까요. 그 부분이 가장 좋았어요.제가 만든 알고리즘이 도면 인식을 잘 할 때도 기분이 좋죠. 도면을 넣었을 때 내가 생각한 대로 처리가 잘 되고 생각한 대로 오류가 잘 날 때 뿌듯해요.Q. 앞으로 어반베이스 내에서 개발 계획은 어떻게 되나요?이번 해에는 도면 변환 알고리즘이 구동될 수 있게끔 만들고, 내년 초부터 코드를 수정하면서 알고리즘의 정확도를 높이는 작업을 계속하려고 해요. 그다음엔 해외 도면을 처리하는 과정을 생각하고 있어요. 데드라인이 정해져있는 프로젝트는 아니지만 최대한 빨리 진행하려고 해요. 2D에서 3D로 도면을 변환하는 개발을 저 혼자 하고 있어서 제가 일을 쉬면 프로젝트 자체가 아예 멈춰 버리니까, 되도록 빨리해야죠. 그렇게 해야 수정하고, 피드백을 받고, 출시하는 모든 과정들이 빠르게 진행될 수 있으니까요.CV 개발자에게 가장 필요한 역량은 코딩 능력이 아니다.Q. 여러 분야의 개발자가 있지만 '컴퓨터 비전(CV) 개발자'는 많이 들어보지 못했는데 최근 들어 '컴퓨터 비전 개발자'의 채용이 굉장히 늘고 있는 것 같아요. 앞으로의 CV 시장을 어떻게 예측하세요?사실 이전까지는 기술력 부족으로 할 수 있는 것이 많이 없었어요. 카메라로 찍었을 때 화질이 안 좋으면 CV 처리하기가 굉장히 힘든데 최근에 카메라 성능이 최근에 굉장히 좋아져서 처리 과정이 수월해진 거죠. 그래서 'CV 개발자'에 대한 수요도 늘고 있어요. 이미지로 무언가를 한다면 무조건 CV 개발자가 필요해요. 요즘은 손쉽게 카메라를 설치하고 이미지/영상 데이터들을 얻을 수 있으니까, 더욱 많이 필요할 거예요. 모든 산업분야에서 CV와 관련된 더 많은 개발자, 더 많은 기술이 필요할 것이라고 생각해요.Q. CV 개발자에게 가장 필요한 역량은 뭘까요? 코드를 잘 짜는 것보다 수학을 잘 하는 게 중요해요. 대부분의 이미지 인식 과정에서 수학공식이 사용되기 때문에 후처리를 하려면 수학을 잘 해야 해요. CV는 공업수학, ML은 통계학이 많이 관련되어 있어요.Q. 그러면 코드를 짤 때 코드에서 막히기보다 수학 공식에서 막힐 때가 있잖아요. 그럴 땐 어떻게 해요?늘 거기서 막혀요. 학교를 최근에 졸업했으니 아직 공식이 머릿속에 많이 남아있어서, 막힐 때가 있으면 이런저런 다른 공식 적용을 시도하죠. 어반베이스의 알고리즘으로 전 세계 도면을 변환하다Q. 좋아하거나 롤모델로 삼고 있는 사람이 있나요?루카스 카나데 교수님이요. CV 분야의 세계적인 권위자이신 분이에요. 교수님의 이름을 딴 함수가 있을 정도로요. 그 정도의 명예와 재력이 있는데도 불구하고 꾸준히 공부하고 논문을 발표하시는 모습도 정말 멋있다고 생각해요.Q. 혹시 CV 외에 어반베이스 내에서 욕심나는 분야가 있어요?머신러닝이요. CV에서 전처리를 하고 머신러닝 후에 후처리에 또 CV가 필요해요. 그래서 중간 영역인 머신러닝을 배우면 모든 프로세스를 혼자서 처리할 수 있으니까 머신러닝을 공부해보고 싶어요.   Q. 어반베이스가 혁신적인 기술을 통해서 많이 이슈가 되고 있고, 많은 컨택이 오고 있잖아요. 스스로 어반베이스의 개발자로서 어반베이스의 가능성은 어떻다고 생각해요?확실히 굉장히 높다고 생각해요. CV로 처리해서 자동화한다는 것 자체가 굉장히 뜨고 있는 기술이고 앞으로 계속 발전할 기술이기 때문에 가능성도 굉장히 크다고 생각해요. Q. 대희님의 포부는 뭐예요?전 세계의 2D 도면을 어반베이스의 알고리즘을 통해 3D로 변환할 수 있게끔 만드는 거죠. 단기간은 국내, 중장기적으로는 해외 도면까지요.컴퓨터 비전. 그저 어렵게만 느껴졌던 단어인데, 이번 인터뷰를 통해 컴퓨터 비전과 많이 가까워진 느낌이 듭니다. 어반베이스의 핵심기술을 담당하고 있는 CV 개발자 대희님! 대희님이 만든 알고리즘으로 전 세계 도면이 3D로 변환될 날이 왔으면 좋겠습니다 :)출처: https://blog.naver.com/urbanbaseinc 

풀스택 개발자라는 용어가 가끔 등장한다. 죄송하지만, 한국에서는 이 용어가 정말 잘못 이해된 상태로 사용되고 있다. 처음에 만들어진 의미와 뜻이 한국에 들어오면서 변한 것을 보는 것이 이번만도 아니다.언제나처럼, 이 '단어'가 의미하는 뜻은 '귤이 회수를 건너면서 언제나 탱자가 되는' 한국적인 환경에서는 매우 이상하게 와전된 의미로 사용되고 있다. 특히나 비개발자들인 경영진들이 그러하고, 개발자들도 가끔 잘못된 의미로 사용한다.와전된 의미의 '풀스택 개발자(Full Stack Developer)'는 프런트엔드와 서버 엔드를 넘나드는 모든 것을 다 아는 전지전능한 개발자인 것처럼 쓰인다. 죄송하지만, 풀스택 개발자의 의미는 프런트-엔드부터 서버-엔드까지 모든 것을 다룰 줄 아는 개발자를 의미하는 것이 아니다.이 '용어'가 쓰이는 분야를 조금은 국한시켜야 할 필요가 있다.그것은 '웹'환경의 프론트 영역으로 국한시키는 것이 매우 현명할 것이다. 다음의 링크를 참조하기를 권한다.http://www.sitepoint.com/full-stack-developer/위의 사이트에 있는 이미지와 단어를 차용한다. 아래의 그림을 살펴보라.[이미지출처 : http://www.sitepoint.com/full-stack-developer/ ]OS부터 Database, WebServer, Server Side Code, Browser, Client Side Code를 아우르는 능력을 가진 사람을 Full-Stack Developer라고 부를 수 있다.좀 더 쉽게 이야기하자면, 'Web'환경은 서버사이드 코드와 클라이언트 사이드 코드를 모두 이해하고 작성되어야 한다. 브라우저( 특히나 변덕스러운 호환성 문제들.. )의 스크립트 환경이 효과적으로 가동되기 위해서는 웹서버의 API를 적절하게 디자인하고 구현된 상태에서 동작되어야 하며, 대부분의 코드들은 직접 Database에 영향을 주는 경우가 많다. 더군다나, 소프트웨어 개발을 하려면 형상관리부터 배포 처리를 위한 기술도 할 줄 알아야 한다.맞다. 'Web'개발 환경에서는 Full-Stack Developer가 되지 않으면 제대로 된 개발이 어렵다. 그래서, '웹'에서는 풀스택 개발자를 지향해야 하고, 매우 당연하게 해당 스킬들을 익숙하게 다루어야 한다.풀스택 개발자는 Web의 개발환경에서는 어쩔 수 없이 매우 당연한 기술적인 한계이고 해야 할 업무를 위해서는 필연적인 형태 인 것이다.이렇게 '웹 환경에서의 풀스택 개발자'는 한국에도 많이 존재한다. 상당수의 PHP개발자 분들이 그러한 '풀스택 개발자'인 경우가 많다.그렇지만, 이 풀스택 개발자의 용어는 '개발'이나 '소프트웨어'를 잘 모르는 경영자의 머릿속으로 잘못 들어가서 마치, iOS나 Android APP도 개발하고 Rest API 디자인이나 구현도 하면서, AWS의 분산 환경에 대한 이해나 개발도 모두 가능한 '전지전능한 개발자'와 같은 의미로 잘못 사용되기도 한다.( 더군다나, 디자인능력이 극도로 필요한 자바스크립트나 능동형 웹-UI를 만들어 내는 능력은 전혀 다른 능력이다 )원래 의미의 '풀스택 개발자'는 '혼자서 웹서비스 하나를 만들 수 있는 개발자'라는 좁은 의미로는 맞다. 하지만, 이를 과도하게 해석하거나 아전인수격으로 해석하는 것은 매우 곤란하다. 그것은 바로 한국적인 특수한 환경 때문에 그러하다.슬프지만, 한국적인 의미의 풀스택 개발자가 존재하기는 하고 있다.프로그래머가 기획도 하면서, 서버 구입부터 설치까지 다진 행하고, DB도 일부 다룰 줄 알면서, 웹이나 클라이언트 프로그래밍의 일부도 할 줄 아는 매우 한국적인 풀스택 개발자가 존재하기는 한다. ( 근데, 그런 개발자들을 풀스택 개발자라고 표현하지 않는다. 거의 기업의 잡부(?)처럼 부려지는 경우다. )노가다 - dokata, 土方 -'막일'을 하는 노가다를 하는 잡부가 한국형 풀스택 개발자라고 표현하겠다.하지만, 그런 테크트리로 형성된 한국형 풀스택 개발자들의 실력은 매우 볼품이 없는 경우가 대부분이다. 필자가 공공 SI현장에서 만난 수많은 한국형 풀스택 개발자들이 그러했다.그들은 컴파일러가 만들어내는 에러 메시지에 대한 이해는 없지만, 10년 넘게 업무를 배운 경험과 대충 Linux나 Windows Server의 기본적인 경험과 온통 스파게티 식으로 구성되어진 소스로 만들어진 더 이상 시장이 커지지 않는 한계가 다다른 시장에서 소프트웨어 개발을 하고 있다.태생적으로 '잡부'가 될 수밖에 없는 작업현장에서 진정한 의미의 풀스택 개발자는 거의 형성되기 어렵다. 이런 한국형 풀스택 개발자들은 실제 하나하나의 스킬들을 확인하거나 체크해본다면 거의 대부분 매우 부족하거나, 특정 기능에만 적합한 일반적으로 쓸모없는 기술들이 대부분일 가능성이 크다고 단언하겠다.이런 경향은 게임업계도 비슷하다. 한국형 풀스택 게임 개발자는 게임 기획부터 스프라이트의 2D부터, 포토샵이나 일러스트레이트도 다룰 줄 알며, 3D Max로 3D도 만들고, Auto-Cad로 도면 데이터도 다루고, DirectX에 Unity도 다루며, 서버나 iOS의 앱까지 만들 줄 안다고 하지만, 정작 그 어느 하나도 제대로 못 다루는 경우가 태반이다.물론, 전부 다루는 사람이 없는 것은 아니다. 있기는 있지만... 그분들 굉장히 유명하거나 특정 기술하나 가 대가의 수준이기 때문에 자신이 가진 다른 기술들을 포함해서 자신을 '풀스택 개발자'라고 포장하지 않는다.하지만, 한국에서 유독 '개발자 구인 광고'를 보면 '풀스택 개발자'를 찾는 곳이 많은 이유는 무엇 때문일까?그것은, 무지한 경영진이나 무지한 비즈니스 모델, 무지한 리소스 활용이 난무하는 헬게이트의 주인들이나 그런 단어들을 주로 사용한다고 보면 된다.100% 단언컨대 한 사람의 개발자가 완벽한 풀스택 개발자라고 하더라도, 요구사항이 발생하고 유지보수업무가 존재하는 업무를 하드웨어적인 서버 관리부터 서버 API, 앱 프로그래밍, 웹 프로그래밍을 하기 위한 스킬은 알 수 있다고 하더라도 그 복잡하고 어지러운 업무량은 모두 다룰 수 없다.만일 그런 것이 가능하다고 이야기하는 경영진이 있거나 무지한 영업맨이 있다면 정신 차리라고 조언해주자. 심지어 그렇게 만들 수 있는 서비스는 존재하지 않고, 존재한다고 하더라도.. 어마어마한 '기술적 부채'가 존재하며, 대부분의 가장 비싼 개발자의 리소스를 그 기술적 부채를 해결하기 위해서 사용되고 있을 것이라고.물론, 그렇게 동작하는 허접하고 쓰레기 같은 코드라고 하더라도, 특정 조건과 특정 환경에서는 서비스가 가능한 경우가 한국에는 많이 존재한다. 경영진이나 영업, 기획은 고객들을 설득하고 고객들이 해당 제품과 서비스를 사용하기 위해서 일부를 희생할 것이다. 그리고, 분명 다른 영역에서 누수가 발생하거나 희생되고 있는 것을 잊지 말자.특히나 경쟁이 없는 제품이거나 더 이상 리소스를 투입하기 어려운 소프트웨어나 서비스의 경우에는 이런 형태로도 동작은 할 것이다. 하루에 한두 번 서버의 Oracle 커넥션을 모두 종료하는 유지보수 행위를 하는 전산실의 업무가 그러한 경우 때문에 벌어진다.중견기업이거나 제조업체, 병원의 전산실에 '야간 당직'업무가 있고, 시스템 모니터링에 민감하다면 대부분 '기술적 부채'를 안고 허접하게 만들어진 것뿐이라고 판단하면 된다.말 그대로, 헬조선의 헬게이트, 헬(!)한 업무환경으로 소프트웨어 개발자로서 비전이 없는 영역이라고 생각하면 된다. 하지만, 그럼에도 불구하고... 스타트업 경영진이나 대기업, 중소기업 경영진들은 '풀스택 개발자'의 환상에 대해서 이야기한다.'모든 것을 다 하는 개발자'가 있으면, 복잡한 커뮤니케이션 비용도 안 들고, 인건비도 적게 들것이라는 착각을 한다. 다만, 이 부분만큼은 명쾌하게 이야기하겠다. '그런 회사 가지 말라'는 것이다.'풀스택 개발자'를 구인하고 있는 회사는 개발자의 무덤이라는 것이다. 대부분 그러하다. 그 이유를 다음과 같이 정리하겠다. 그들이 '풀스택 개발자'를 뽑고 싶은 이유는 간단하다. '돈'이 없어서다. 그리고, 다음의 이유들이 있는 경우이다.하나. 경영진이 요구사항 정의도 제대로 못하므로 개발자와 의사소통에 자신이 없다. 그래서, 풀스택 개발자를 구하려고 한다. 한 명 하고만 이야기하면 될 것이라고 착각한다.둘. 개발자의 인력이 몇 명이 투입되는지에 대해서 평가나 정의가 불가능하므로, 풀스택 개발자를 구하려 한다.셋. 개발자가 두 명, 세명이 있다면 팀 리더도 있어야 하고, 관리자도 있어야 하므로 그 비용을 줄이기 위해서 풀스택 개발자가 필요하다. 한마디로, 돈이 없다.넷. 현대의 웹서비스들을 가동하기 위해서는 최소한의 비용과 인건비가 투여된다. 이 비용을 투자할 정도로 비즈니스 모델에 가치가 없기 때문에 여러 명의 개발자를 고용할 수 없기 때문에 풀스택 개발자를 구하려 한다.다섯. 풀스택 개발자라면 막연하게 다 해줄 것 같은 환상을 가진 경영진이 있는 경우이다. 슬프지만, 전설의 개발자인 '제프 딘'을 고용한다고 하더라도, 삽질을 할 것이다.물론, 스타트업에 초기에 합류하면서 CTO의 역할을 부여받았다면 조금은 입장이 달라진다. 정당한 지분을 받고, 미래의 가치에 대해서 나눌 수 있다면, 해당 롤을 가진 사람은 알아서 '풀스택 개발자'가 될 가능성이 크다. 그러므로, 매우 당연하지만 CTO는 풀스택 개발자에 근접되면 좋기는 할 것 같다. 하지만, 현실적으로는 그렇게 세팅하지 못하는 경우가 대부분이다.그리고, 냉정하게 초기 개발이나 Lab수준, 시리즈 A를 투자받기 전의 '소프트웨어'나 '서비스'는 대부분 비즈니스 모델을 증명하는 수준에서 끝내는 것이 바람직하다. 굳이, 환상의 개발자나 풀스택 개발자가 아니라도 비즈니스 모델을 검토하고 증명하는 모델을 구현하는 것은 충분하게 가능한 경우가 대부분이다.사용자가 수백만 명도 아니고, 구현된 기능들도 수백 가지가 아니며, 아직은 스파게티 식으로 구성하더라도 무방하기 때문이다. 해당 기술적 부채는 서비스의 증명 후에 해당 코드는 버려지고, 다시 개발팀을 제대로 세팅하여 구현하면 되기 때문이다. 더군다나, 대부분의 스타트업은 고속 개발을 해야 하기 때문에 '풀스택 개발'이 가능한 '웹'만으로는 모든 것을 커버하기 어려울 것이다.좌우지간, 간단하게 이야기해서 '풀스택 개발자'타령하는 구인광고를 보게 된다면, 그 회사나 팀은 무언가 잘못 생각하고 있거나, '돈'이 없는 조직이라고 생각하면 된다. 거기에, '기술'이나 '개발'에 대해서는 아무것도 모르는 사람이 사장이 존재하는 곳이라고 생각하면 된다.헬게이트에 입성하고픈 개발자라면 '풀스택 개발자'를 구인하는 곳으로 가면 된다. 엄청난 '일'의 쓰나미를 경험하고, 인성이 피폐해지는 것을 경험할 것이다.필자는 국내 최고의 개발자들을 여럿 알고 있다. 하지만, 그분들은 자신들을 '풀스택 개발자'라고 이야기하지 않는다. 그 용어가 의미하는 것 자체가 '날림'이라는 것을 너무도 잘 알고 있기 때문이다. 물론, 10년 20년을 소프트웨어 개발을 하다 보면 얻어지는 경험과 지식들이 있다.궁극적으로는 풀스택 개발자가 이야기하는 비슷한 테크트리를 대부분 알고는 있게 된다. 하지만, 경력 20년 되고 하나의 도메인에 익숙하며, 특정 분야의 대가인 분들을 스타트업에서 고용한다는 것은 거의 불가능에 가깝다. 간혹, 그런 분들이 직접 스타트업을 하는 것이라면 모를까 말이다.이제 이야기를 마무리하겠다.'웹 개발'을 하려면 '풀스택 개발'을 지향하는 것은 맞다. 하지만, 그것 자체가 완벽한 풀스택 개발을 의미하는 것이 아니라는 것을 생각하기 바란다. 그리고, 경영진이나 비개발자들에게도 다시 한번 이야기한다. '풀스택 개발자'를 구인하겠다는 환상을 버리기 바란다.그런 사람 없고, 있다고 하더라도... '풀스택 개발자'를 구인하겠다는 발상으로는 절대 초빙하거나 모실 수 없다는 것을... 깨몽 하기 바란다.물론, '풀스택 개발자'처럼 이것 저것 다하는 정성스럽고, 일에 애정 넘치는 개발자들을 제대로 대우해주시기를... 기술로써의 풀스택 개발자가 아니라, 그 기업이 원하는 일을 풀스택 개발자처럼 일할 뿐이다. 그들에 대한 애정 넘치는 말한마디... 경영진들에게 부탁드린다.갑자기, '풀스택 개발자'에 대한 환상에 대해서 정리하고 싶어서 한 번에 글을 써 내려갔다. ~.~

오전 6시 30분. 휴대전화 알람이 울리기 시작한다. 부랴부랴 샤워를 끝내고, 나갈 채비를 하고 있으니, 5분 후 집 앞 버스 정류장에 회사로 향하는 100번 시내버스가 도착한다는 메세지가 나타났다. 버스에 몸을 싣고 사무실 근처 정류장에 내려서 걸어가는 도중, 필자가 즐겨 마시는 커피를 맛있게 내린다는 동네 카페에 대한 정보를 받았다. 어느새 다가온 점심시간에는 어제 이태원에서 과음한 것을 어떻게 알았는지, 휴대폰 잠금화면에 주변 해장국집 추천이 뜬다.그저 영화 속 이야기가 아니다. 실제 사용자의 취향과 행동 등을 분석하고, 시간, 날씨, 교통 등과 같은 외부적 환경요소를 정교하게 더한 시나리오다. 각 개인에게 필요하고, 일상을 윤택하게 만들 수 있는 유의미한 정보를 제공하는 것. ‘맥락인식’ 혹은 ‘상황인지 기술’이라고 불리는 ‘Context Recognition’의 궁극적인 목표 중 하나다.맥락인식 기술은 여러 센서로부터 수집한 데이터를 통해 사용자의 상황을 인지하고, 실시간으로 맥락을 이해하는 데 초점을 맞춘다. GPS, 와이파이, RFID, 모션 센서, 소리 등 여러 시그널을 수집해 분석하며, 사용자의 일정, 문자 메시지나 행동 정보 등을 가져와 ‘사용자가 어떤 사람인지’, 그리고 ‘현재 어떤 상황인지’ 등을 추론한다. 이와 같은 맥락인식 기술을 구현하기 위해 필요한 몇 가지 주요기술은 다음과 같다.1. 상황정보 수집사용자 인터페이스 또는 센서, 센서 네트워크 등를 통해 사용자의 위치, 활동, 생활 패턴 등 다양하고 복잡한 정보를 수집하는 기술.2. 상황정보 모델링상황정보를 가공, 저장 및 공유하는 모델링 기술.3. 상황정보 융합 및 추론사용자의 상황정보를 다른 기술과 융합해 높은 수준의 추론 기능을 제공하는 기술.4. 상황정보 교환센서, 장치 및 객체와의 상호작용을 지원하기 위해 이벤트 기반의 통신 메커니즘을 제공하는 기술.5. 지능형 에이전트사용자의 단순한 의도뿐만 아니라 감정이나 감성을 고려해 전체 상황을 자율적으로 판단, 사용자에게 적합한 서비스를 제공하는 기술.기업 입장에서 생각했을 때, 맥락인식 기술은 소비자 개인에게 특화된 서비스를 제공할 수 있는 날카로운 검이다. 간단한 예로 맥락인식을 활용한 맞춤형 광고에 대해 알아보자. 소비자 A와 소비자 B는 서울에 사는 30대 남성이고 스포츠를 좋아한다. 일반적인 검색이나 구매 히스토리에 기반한 광고와 달리 맥락인식 기술을 활용하면, 이들의 라이프스타일이나 행동패턴을 바탕으로 더 깊은 디멘션까지 분석해 세분화된 광고를 제공할 수 있다. 두 소비자 모두 스포츠를 좋아한다고 가정했을 때, A는 한강 근처에서 매일 저녁 7시 정도에 조깅하는 것을 좋아할 수 있고, B는 남산에서 새벽 6시부터 등산하는 것을 좋아할 수 있다. 미묘한 차이겠지만, 분명 다른 카테고리의 소비자로 정의할 수 있는 것이다.스켈터랩스에서 진행하고 있는 맥락인식 기술 프로젝트를 예로 들어보자. 앞서 언급한 것처럼 다양한 기기로부터 측정하는 저레벨 데이터를 수집하는 것으로 맥락인식 프로세스는 시작된다. 측정 데이터는 서버에 전송되어 시간 순으로 변경 및 취합되고, 기계학습을 통해 필터링 후 수집되며, 고레벨의 맥락으로 추상화된다. 시간, GPS, 와이파이, 모션센서, 소리, 문자메시지, 일정 등 여러 데이터를 처리해 사용자의 맥락을 이해한다. 이러한 일련의 과정 역시 맥락인식 기술의 한 부분인지라 메시지 스트림 프로세서를 기반으로 확장할 수 있는 인프라를 설계, 구축했다.실시간으로 데이터를 처리할 수 있는 파이프라인이다. 처리한 데이터는 좀 더 상위 레벨의 이벤트와 행동으로 인식되어 ‘의미‘를 지니는 데이터로 표현되는데, 예를 들어 GPS 정보를 와이파이 및 시간 등과 같은 다른 데이터와 결합하고, 방문 장소와 행동반경 등을 포함해 사용자의 장소를 식별하는 방식이다. 이러한 사용자의 행동 히스토리는 패턴인식 기술을 활용해 사용자 특정 행동을 학습하고, 이를 기반으로 ‘언제 집으로 돌아갈지‘, 혹은 ‘언제 식사를 하는지’ 등 행동을 예측할 수 있다. 결국, 맥락인식을 통해 사용자의 다음 활동을 예측할 수 있는 기술을 개발, 사용자에게 필요하고 유용한 정보와 서비스를 제공하는 것이 목표다.< 맥락인식 기술을 적용한 큐 앱 화면, 출처: 스켈터랩스 한지예, 이해연 디자이너 >얼마 전, 스켈터랩스의 맥락인식 기술 프로젝트 팀은 해당 기술을 활용해 사용자들이 일상 속에서 가볍게 사용할 수 있는 서비스가 무엇일까 고민하고, ‘큐(Cue)’라는 앱을 개발했다. 큐는 사용자가 직접 명령할 필요가 없다. 큐가 먼저 사용자의 생활을 돕기 때문이다. 날씨를 예를 들면, 사용자가 날씨를 알아보기 전에 비가 올 것 같으면 우산을 챙기라 알려주고, 덥거나 미세먼지가 많을 경우 도움 되는 정보를 알려준다. 사용자에게 전달하는 정보는 카드 메시지를 통해 잠금화면으로 표시된다.큐 프로젝트의 이민학 시니어 프로덕트 매니저는 큐를 통해 사용자가 ‘내'가 누구인지 파악할 수 있을 것이라고 말한다. 예를 들어, 나는 내가 운동을 좋아하는 액티브한 라이프스타일을 살고 있는 줄 알았는데, 실제로는 집에 누워서 영화보는 것을 더 좋아하는 사람에 가깝다는 것. 개인의 삶이 매우 중요해지는 시대이지만, 정작 내가 누구인지 확인하기 어렵기 때문에 맥락인식 기술은 다양한 용도로 사용될 수 있다.< 사용자 패턴을 분석한 유형 결과 예시, 출처: 스켈터랩스 한지예, 이해연 디자이너 >이민학 매니저는 맥락인식 기술에 대해 이렇게 말한다. 그는 “누가, 언제, 어디서, 무엇을, 어떻게, 왜로 구성된 사용자의 육하원칙을 파악하고, 더 나아가 ‘Next-육하원칙’을 파악하는 것이 진정한 맥락인식 기술입니다. 앞으로 기업 특히, 마케터들은 타겟 고객을 잡는데 굉장히 유용하게 사용할 것이라고 생각합니다”라며, “소비자 입장에서는 일상, 문화, 생활 등 세분화된 영역에서 자신의 삶을 더 윤택하게 영위할 수 있습니다. 맥락인식 기술이야말로 인간에게 정말 도움될 수 있는, ‘피부에 와닿는' 인공지능 기술이 아닐까 생각합니다”라고 설명했다.이호진, 스켈터랩스 마케팅 매니저조원규 전 구글코리아 R&D총괄 사장을 주축으로 구글, 삼성, 카이스트 AI 랩 출신들로 구성된 인공지능 기술 기업 스켈터랩스에서 마케팅을 담당하고 있다#스켈터랩스 #기업문화 #인사이트 #경험공유 #조직문화 #인공지능기업 #기술기업

커플 필수 앱 비트윈은 여러 종류의 오픈 소스를 기반으로 이루어져 있습니다. 그 중 하나는 HBase라는 NoSQL 데이터베이스입니다. VCNC에서는 HBase를 비트윈 서비스의 메인 데이터베이스로써 사용하고 있으며, 또한 데이터 분석을 위한 DW 서버로도 사용하고 있습니다.그동안 두 개의 HBase Cluster 모두 최적화를 위해서 여러 가지 설정을 테스트했고 노하우를 공유해 보고자 합니다. 아랫은 저희가 HBase를 실제로 저희 서비스에 적용하여 운영하면서 최적화한 시스템 구성과 설정들을 정리한 것입니다. HBase를 OLTP/OLAP 목적으로 사용하고자 하는 분들에게 도움이 되었으면 좋겠습니다. 아래 구성을 최적화하기 위해서 했던 오랜 기간의 삽질기는 언젠가 따로 포스팅 하도록 하겠습니다.HBaseHBase는 Google이 2006년에 발표한 BigTable이라는 NoSQL 데이터베이스의 아키텍처를 그대로 따르고 있습니다. HBase는 뛰어난 Horizontal Scalability를 가지는 Distributed DB로써, Column-oriented store model을 가지고 있습니다. 사용량이 늘어남에 따라서 Regionserver만 추가해주면 자연스럽게 Scale-out이 되는 구조를 가지고 있습니다. 또한, Hadoop 특유의 Sequential read/write를 최대한 활용해서 Random access를 줄임으로 Disk를 효율적으로 사용한다는 점을 특징으로 합니다. 이 때문에 HBase는 보통의 RDBMS와는 다르게 Disk IO가 병목이 되기보다는 CPU나 RAM 용량이 병목이 되는 경우가 많습니다.HBase는 많은 회사가 데이터 분석을 하는 데 활용하고 있으며, NHN Line과 Facebook messenger 등의 메신저 서비스에서 Storage로 사용하고 있습니다.시스템 구성저희는 Cloudera에서 제공하는 HBase 0.92.1-cdh4.1.2 release를 사용하고 있으며, Storage layer로 Hadoop 2.0.0-cdh4.1.2를 사용하고 있습니다. 또한, Between의 데이터베이스로 사용하기 위해서 여러 대의 AWS EC2의 m2.4xlarge 인스턴스에 HDFS Datanode / HBase Regionserver를 deploy 하였습니다. 이는 m2.4xlarge의 큰 메모리(68.4GB)를 최대한 활용해서 Disk IO를 회피하고 많은 Cache hit이 나게 하기 위함입니다.또한 Highly-Available를 위해서 Quorum Journaling node를 활용한 Active-standby namenode를 구성했으며, Zookeeper Cluster와 HBase Master도 여러 대로 구성하여 Datastore layer에서 SPOF를 전부 제거하였습니다. HA cluster를 구성하는 과정도 후에 포스팅 하도록 하겠습니다.HDFS 최적화 설정dfs.datanode.handler.countHDFS에서 외부 요청을 처리하는 데 사용할 Thread의 개수를 정하기 위한 설정입니다. 기본값은 3인데 저희는 100으로 해 놓고 사용하고 있습니다.dfs.replicationHDFS 레벨에서 각각의 데이터가 몇 개의 독립된 인스턴스에 복사될 것 인가를 나타내는 값입니다. 저희는 이 값을 기본값인 3으로 해 놓고 있습니다. 이 값을 높이면 Redundancy가 높아져서 데이터 손실에 대해서 더 안전해지지만, Write 속도가 떨어지게 됩니다.dfs.datanode.max.transfer.threads하나의 Datanode에서 동시에 서비스 가능한 block 개수 제한을 나타냅니다.과거에는 dfs.datanode.max.xcievers라는 이름의 설정이었습니다.기본값은 256인데, 저희는 4096으로 바꿨습니다.ipc.server.tcpnodelay / ipc.client.tcpnodelaytcpnodelay 설정입니다. tcp no delay 설정은 TCP/IP network에서 작은 크기의 패킷들을 모아서 보냄으로써 TCP 패킷의 overhead를 절약하고자 하는 Nagle's algorithm을 끄는 것을 의미합니다. 기본으로 두 값이 모두 false로 설정되어 있어 Nagle's algorithm이 활성화되어 있습니다. Latency가 중요한 OLTP 용도로 HBase를 사용하시면 true로 바꿔서 tcpnodelay 설정을 켜는 것이 유리합니다.HBase 최적화 설정hbase.regionserver.handler.countRegionserver에서 외부로부터 오는 요청을 처리하기 위해서 사용할 Thread의 개수를 정의하기 위한 설정입니다. 기본값은 10인데 보통 너무 작은 값입니다. HBase 설정 사이트에서는 너무 큰 값이면 좋지 않다고 얘기하고 있지만, 테스트 결과 m2.4xlarge (26ECU) 에서 200개 Thread까지는 성능 하락이 없는 것으로 나타났습니다. (더 큰 값에 관해서 확인해 보지는 않았습니다.)저희는 이 값을 10에서 100으로 올린 후에 약 2배의 Throughput 향상을 얻을 수 있었습니다.hfile.block.cache.sizeHBase 의 block 들을 cache 하는데 전체 Heap 영역의 얼마를 할당한 것인지를 나타냅니다. 저희 서비스는 Read가 Write보다 훨씬 많아서 (Write가 전체의 약 3%) Cache hit ratio가 전체 성능에 큰 영향을 미칩니다.HBase 에서는 5분에 한 번 log 파일에 LruBlockCache (HBase 의 Read Cache) 가 얼마 만큼의 메모리를 사용하고 있고, Cache hit ratio가 얼마인지 표시를 해줍니다. 이 값을 참조하셔서 최적화에 사용하실 수 있습니다.저희는 이 값을 0.5로 설정해 놓고 사용하고 있습니다. (50%)hbase.regionserver.global.memstore.lowerLimit / hbase.regionserver.global.memstore.upperLimit이 두 개의 설정은 HBase에서 Write 한 값들을 메모리에 캐쉬하고 있는 memstore가 Heap 영역의 얼마만큼을 할당받을지를 나타냅니다. 이 값이 너무 작으면 메모리에 들고 있을 수 있는 Write의 양이 한정되기 때문에 디스크로 잦은 flush가 일어나게 됩니다. 반대로 너무 크면 GC에 문제가 있을 수 있으며 Read Cache로 할당할 수 있는 메모리를 낭비하는 것이기 때문에 좋지 않습니다.lowerLimit와 upperLimit의 두 가지 설정이 있는데, 두 개의 설정이 약간 다른 뜻입니다.만약 memstore 크기의 합이 lowerLimit에 도달하게 되면, Regionserver에서는 memstore들에 대해서 'soft'하게 flush 명령을 내리게 됩니다. 크기가 큰 memstore 부터 디스크에 쓰이게 되며, 이 작업이 일어나는 동안 새로운 Write가 memstore에 쓰일 수 있습니다.하지만 memstore 크기의 합이 upperLimit에 도달하게 되면, Regionserver는 memstore들에 대한 추가적인 Write를 막는 'hard'한 flush 명령을 내리게 됩니다. 즉, 해당 Regionserver이 잠시 동안 Write 요청을 거부하게 되는 것입니다. 보통 lowerLimit에 도달하면 memstore의 크기가 줄어들기 때문에 upperLimit까지 도달하는 경우는 잘 없지만, write-heavy 환경에서 Regionserver가 OOM으로 죽는 경우를 방지하기 위해서 hard limit가 존재하는 것으로 보입니다.hfile.block.cache.size와 hbase.regionserver.global.memstore.upperLimit의 합이 0.8 (80%)를 넘을 수 없게 되어 있습니다. 이는 아마 read cache 와 memstore의 크기의 합이 전체 Heap 영역 중 대부분을 차지해 버리면 HBase의 다른 구성 요소들이 충분한 메모리를 할당받을 수 없기 때문인 듯합니다.저희는 이 두 개의 설정 값을 각각 0.2, 0.3으로 해 놓았습니다. (20%, 30%)ipc.client.tcpnodelay / ipc.server.tcpnodelay / hbase.ipc.client.tcpnodelayHDFS의 tcpnodelay 와 비슷한 설정입니다. 기본값은 전부 false입니다.이 설정을 true로 하기 전에는 Get/Put 99%, 99.9% Latency가 40ms 와 80ms 근처에 모이는 현상을 발견할 수 있었습니다. 전체 요청의 매우 작은 부분이었지만, 평균 Get Latency가 1~2ms 내외이기 때문에 99%, 99.9% tail이 평균 Latency에 큰 영향을 미쳤습니다.이 설정을 전부 true로 바꾼 후에 평균 Latency가 절반으로 하락했습니다.Heap memory / GC 설정저희는 m2.4xlarge가 제공하는 메모리 (68.4GB)의 상당 부분을 HBase의 Read/Write cache에 할당하였습니다. 이는 보통 사용하는 Java Heap 공간보다 훨씬 큰 크기이며 심각한 Stop-the-world GC 문제를 일으킬 수 있기 때문에, 저희는 이 문제를 피하고자 여러 가지 설정을 실험하였습니다.STW GC time을 줄이기 위해서 Concurrent-Mark-and-sweep GC를 사용했습니다.HBase 0.92에서부터 기본값으로 설정된 Memstore-Local Allocation Buffer (MSLAB) 을 사용했습니다. hbase.hregion.memstore.mslab.enabled = true #(default)hbase-env.sh 파일을 다음과 같이 설정했습니다. HBASE_HEAPSIZE = 61440 #(60GB) HBASE_OPTS = "-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps"GC log를 Python script로 Parsing해서 STW GC 시간을 관찰하고 있습니다. 지금까지 0.2초 이상의 STW GC는 한 번도 발생하지 않았습니다.그 밖에 도움이 될 만한 설정들hbase.hregion.majorcompactionHBase는 하나의 Region에 대해서 여러 개의 StoreFile을 가질 수 있습니다. 그리고 주기적으로 성능 향상을 위해서 이 파일들을 모아서 하나의 더 큰 파일로 합치는 과정을 진행하게 됩니다. 그리고 이 과정은 많은 CPU usage와 Disk IO를 동반합니다. 그리고 이때 반응 속도가 다소 떨어지게 됩니다. 따라서 반응 속도가 중요한 경우에는, 이 Major compaction을 off-peak 시간대를 정해서 manual 하게 진행하시는 것이 좋습니다.저희는 사용자의 수가 상대적으로 적은 새벽 시간대에 crontab 이 실행시키는 script가 돌면서 전체 Region에 대해서 하나하나 Major Compaction이 진행되도록 하였습니다.기본값은 86,400,000 (ms)로 되어 있는데, 이 값을 0으로 바꾸시면 주기적인 Major Compaction이 돌지 않게 할 수 있습니다.hbase.hregion.max.filesizeHBase는 하나의 Region이 크기가 특정 값 이상이 되면 자동으로 2개의 Region으로 split을 시킵니다. Region의 개수가 많지 않을 때는 큰 문제가 없지만, 계속해서 데이터가 쌓이게 되면 필요 이상으로 Region 수가 많아지는 문제를 나을 수 있습니다. Region 수가 너무 많아지면 지나친 Disk IO가 생기는 문제를 비롯한 여러 가지 안 좋은 점이 있을 수 있기 때문에, split 역시 manual 하게 하는 것이 좋습니다. 그렇다고 Table의 Region 수가 너무 적으면 Write 속도가 떨어지거나 Hot Region 문제가 생길 수 있기 때문에 좋지 않습니다.HBase 0.92.1 에서는 기본값이 1073741824(1GB)로 되어 있는데, 저희는 이 값을 10737418240(10GB)로 늘인 후에 manual 하게 split을 하여 Region의 개수를 조정하고 있습니다.hbase.hregion.memstore.block.multipliermemstore의 전체 크기가 multiplier * flush size보다 크면 추가적인 Write를 막고 flush가 끝날때까지 해당 memstore는 block 됩니다.기본값은 2인데, 저희는 8로 늘려놓고 사용하고 있습니다.dfs.datanode.balance.bandwidthPerSec부수적인 설정이지만, HDFS의 Datanode간의 load balancing이 일어나는 속도를 제한하는 설정입니다. 기본값은 1MB/sec로 되어 있지만, 계속해서 Datanode를 추가하거나 제거하는 경우에는 기본값으로는 너무 느릴 때가 있습니다. 저희는 10MB/sec 정도로 늘려서 사용하고 있습니다.dfs.namenode.heartbeat.recheck-intervalHDFS namenode에만 해당되는 설정입니다.Datanode가 응답이 없는 경우에 얼마 후에 Hadoop cluster로부터 제거할 것인지를 나타내는 값입니다.실제로 응답이 없는 Datanode가 떨어져 나가기까지는 10번의 heartbeat가 연속해서 실패하고 2번의 recheck역시 실패해야 합니다. Heartbeat interval이 기본값인 3초라고 하면, 30초 + 2 * recheck-interval 후에 문제가 있는 Datanode가 제거되는 것입니다.기본값이 5분으로 되어 있는데, fail-over가 늦어지기 때문에 사용하기에는 너무 큰 값입니다. 저희는 문제가 있는 Datanode가 1분 후에 떨어져 나갈 수 있도록 이 값을 15,000 (ms) 으로 잡았습니다.Read short-circuitRegionServer가 로컬 Datanode로부터 block을 읽어올 때 Datanode를 통하지 않고 Disk로부터 바로 읽어올 수 있게 하는 설정입니다.데이터의 양이 많아서 Cache hit이 낮아 데이터 대부분을 디스크에서 읽어와야 할 때 효율적입니다. Cache hit에 실패하는 Read의 Throughput이 대략 2배로 좋아지는 것을 확인할 수 있습니다. OLAP용 HBase에는 매우 중요한 설정이 될 수 있습니다.하지만 HBase 0.92.1-cdh4.0.1까지는 일부 Region이 checksum에 실패하면서 Major compaction이 되지 않는 버그가 있었습니다. 현재 이 문제가 해결되었는지 확실하지 않기 때문에 확인되기 전에는 쓰는 것을 추천하지는 않습니다.설정하는 방법은 다음과 같습니다. dfs.client.read.shortcircuit = true #(hdfs-site.xml) dfs.block.local-path-access.user = hbase #(hdfs-site.xml) dfs.datanode.data.dir.perm = 775 #(hdfs-site.xml) dfs.client.read.shortcircuit = true #(hbase-site.xml)Bloom filterBloom filter의 작동방식에 대해 시각적으로 잘 표현된 데모 페이지HBase는 Log-structured-merge tree를 사용하는데, 하나의 Region에 대해서 여러 개의 파일에 서로 다른 version의 값들이 저장되어 있을 수 있습니다. Bloom filter는 이때 모든 파일을 디스크에서 읽어들이지 않고 원하는 값이 저장된 파일만 읽어들일 수 있게 함으로써 Read 속도를 빠르게 만들 수 있습니다.Table 단위로 Bloom filter를 설정해줄 수 있습니다.ROW와 ROWCOL의 두 가지 옵션이 있는데, 전자는 Row key로만 filter를 만드는 것이고, 후자는 Row+Column key로 filter를 만드는 것입니다. Table Schema에 따라 더 적합한 설정이 다를 수 있습니다.저희는 데이터 대부분이 메모리에 Cache 되고 하나의 Region에 대해서 여러 개의 StoreFile이 생기기 전에 compaction을 통해서 하나의 큰 파일로 합치는 작업을 진행하기 때문에, 해당 설정을 사용하지 않고 있습니다.결론지금까지 저희가 비트윈을 운영하면서 얻은 경험을 토대로 HBase 최적화 설정법을 정리하였습니다. 하지만 위의 구성은 어디까지나 비트윈 서비스에 최적화되어 있는 설정이며, HBase의 사용 목적에 따라서 달라질 수 있음을 말씀드리고 싶습니다. 그래서 단순히 설정값을 나열하기보다는 해당 설정이 어떤 기능을 하는 것인지 저희가 아는 한도 내에서 설명드리려고 하였습니다. 위의 글에서 궁금한 점이나 잘못된 부분이 있으면 언제든지 답글로 달아주시길 바랍니다. 감사합니다.

응당 인덱스가 있으리라 생각한 칼럼에 인덱스가 없고 인덱스를 걸자마자 응답속도가 평균 10배 가까이 좋아지는 모습을 지켜보니 여러 생각이 들더라. 통계와 지표가 제공되는 곳은 주기적으로 검토하고 문제가 커지기 전에 손을 쓰는데 그렇지 않은 곳이 문제이다. 주기적으로 Slow query 로그를 훑어볼 수는 있다. 하지만 특정 시점에 일부 로그만 훑어봐서는 엉뚱한 문제를 해결하기 일쑤다. 예를 들어 1초짜리 쿼리보다 10초짜리 쿼리가 문제라고 생각하기 쉽지만 이 1초짜리 쿼리를 10초짜리 쿼리보다 1000배 많이 실행한다면 이야기가 달라진다. 요는 느린 쿼리를 지속적으로 수집하고 통계를 낼 필요가 있다는 것이다.이러한 모니터링 도구를 어떻게 구현할까? 우리 손에 있는 도구를 검토하는 일부터 시작했다.통계분석은 MySQL 또는 Elasticsearch 를 쓰면 된다.Elasticsearch를 쓴다면 Kibana를 이용해 시각화하기 편하다.느린 쿼리 로그를 Elasticsearch에 보내는 일은 Fluentd를 쓰면 된다.그러니까 Fluentd, Elasticsearch, Kibana 조합이라면 데이터를 눈으로 보고 문제를 해결하기 좋을 것이다. 그렇다면 어떻게 구현할 것인가?우선 RDS에서 느린 쿼리를 뽑아서 Fluentd에 보내는 방법을 찾아야 한다.Fluentd를 이용해 Elasticsearch에 데이터를 보내는 건 쉬우니 대시보드만 잘 구성하면 끝!문제는 RDS에서 느린 쿼리를 뽑아서 Fluentd에 보내는 것인데 크게 두 가지 방법이 있다. RDS 설정에 따라 느린 쿼리 로그를 테이블 또는 파일에 저장할 수 있는데 이에 따라 구체적인 구현방법이 달라진다. 하지만 기본적으로는 동일한 과정을 거치는데 대충 이런 식이다.느린 쿼리 로그를 읽는다.같은 쿼리라도 매개변수 값이 다를 수 있으므로 mysql_slow_log_parser 또는 pt-query-digest 같은 도구를 사용해 쿼리를 일반화한다.Fluentd를 통해 해당 로그를 ES로 보낸다.새로 추가된 로그만 읽어서 다시 ES로 보낸다.이와 관련해서는 AWS RDS Mysql SlowQuery monitoring on Kibana using Logstash 등의 글이 잘 설명한다.다행히 테이블에 저장한 로그를 읽어들이는 Fluentd 플러그인을 구하기는 쉽다. 변형체가 많은데 대부분은 kenjiskywalker/fluent-plugin-rds-slowlog에서 파생됐다. 파일에 저장한 로그의 경우는 in_rds_mysqlslowlog_stream.rb를 써서 처리하면 된다. 우리는 테이블에 저장하기 때문에 전자를 선택했다.이쯤 조사를 마치고 나니 진행방향은 매우 명확하다. 적당히 잘 만든 Fluentd 플러그인을 골라서 적용한 후에 ES에 대시보드를 만들면 된다. 물론 우리는 Kubernetes 위에 모니터링 도구를 띄워야 하니 Dockerize할 필요도 있다. 이쯤에서 또다시 구글링을 하니 무시무시한 게 나온다. inokappa/rds-slowquery-log-demo는 방금 설명한 모든 과정을 하나로 정리해서 제공한다. Docker로 만든 Fluentd와 ES 대시보드 설정을 한데 묶어놓았다. 거기에 파일 로그, 테이블 로그 둘 다 예제로 제공한다. 덕분에 일이 쉽게 끝날 줄 알았다. 하지만!개발한지 꽤 시간이 지난 지라 최신 버전의 Fluentd와 ES에서 계속 문제를 일으켰다. 문제점에 대해 구구절절 설명할 생각은 없고 DailyHotel/rds-slowquery-log-demo를 참고해서 적용하면 된다는 점만 이야기하고자 한다. 일어로 된 README 파일은 구글 번역기를 돌리면 적당히 읽을만해진다.삽질을 약간만 하면 아래와 같이 간지!나는 대시보드를 얻을 수 있으니 해볼만 할 것이다.참! DailyHotel/rds-slowquery-log-demo는 테이블 로그인 경우만 테스트했으니 파일 로그를 사용하는 경우라면 이 점을 주의해야 한다.더 읽을거리Collecting and Analying Slow Query Logs for MySQLRDS(MySQL) のスロークエリを EFK スタック + Docker で出来るだけ手軽に可視化する考察（2）〜 log_output: FILE の場合 〜#데일리 #데일리호텔 #개발 #개발자 #개발팀 #Elasticsearch #엘라스틱서치 #꿀팁 #도입후기 #일지

앞서 종합 모빌리티 플랫폼인 타다의 시스템 설계를 위한 많은 고민과 기술적 결정들에 대해서 서버팀에서 소개한 바 있습니다. 이번 글에서는 타다 서비스를 출시하기까지 타다 모바일 클라이언트를 개발하는 과정에서 내린 클라이언트 팀의 전략적 결정들과, 타다 클라이언트를 개발하는데 사용한 기술들을 공유합니다.시작 전 상황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여 가지나 되는 팀원들이 하고 싶은 백로그 목록이 여러분을 기다리고 있습니다. 타다가 성공적으로 런칭할 수 있었던 것은 훌륭한 팀원들이 있었기 때문입니다. 앞으로 저희와 함께 좋은 서비스를 만들어 나갈 멋진 분들의 많은 관심 바랍니다.