Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 잡학다이너마이트 변규홍 님을 만나보세요:)PART1. About Skelter Labs사진1. 스켈터랩스의 소프트웨어 엔지니어, 변규홍 님Q. 간단한 자기소개를 부탁한다.A. 이름은 변규홍. 스켈터랩스에서 소프트웨어 엔지니어로 일하며, 컴퓨터에게 열심히 한국어를 가르치고 함께 배우고 있다. 대충 20년 전부터 컴퓨터 공부를 시작해서 컴퓨터 관련된 일이라면 사족을 못쓰는 덕후이기도 하다.Q. 현재 스켈터랩스에서 어떤 업무를 맡고있는가.A. 스켈터랩스의 인공지능 대화 엔진 개발 팀인 헤르메스(Hermes)에서 흔히 ‘챗봇’이라 부르는 인공지능 대화 엔진을 만들고 있다. 우리가 만드는 인공지능 대화 엔진은 ‘챗봇을 만들고자 하는 사람들이 누구나 쉽게 챗봇을 만들도록 돕는 편리한 사용'을 목표로 한다. 때문에 비개발자도 이해하기 쉽도록 효율적이고 간편한 UI와 구조로 개발하고 있다. 거기서 나는 어떻게 하면 컴퓨터가 사람이 하는 말을 더 잘 알아듣고 잘 대답할 수 있는지 연구하고 있다. 어떤 처리를 해야하는지, 언어의 어떤 패턴을 인식하는지 등 ‘자연어 처리(Natural Language Processing,NLP)’ 혹은 자연언어처리라고 불리는 기술 전반에 대한 연구를 진행하고 있다.Q. 자연어 처리라는 부분이 생소하다. 언어의 분석이나 처리에 대한 얘기를 더 해줄 수 있나.A. 챗봇 위주로 설명해 보자. 우리가 한국어 문장을 컴퓨터나 스마트폰에 입력할 때, 특히 채팅할 때는 문장의 변화가 심한 편이다. 띄어쓰기를 실수할 수도 있고 급식체같은 축약어를 사용하기도 한다. 같은 의도를 담은 문장이 아주 다르게 표현되는가 하면, 비슷한 문장이 어순이나 표현 한 두 가지만 바뀌어도 전혀 다른 뜻이 되기도 한다. 이러한 인간의 언어를 컴퓨터가 잘 알아들을 수 있도록 분석하고 처리하는 것이다. 입력된 문장에서 어떤 부분이 명사고 어떤 부분이 동사인지를 찾거나, 문장 속에서 어떤 형태소에 집중해야 하는지 분석한다. 그리고 은행 계좌나 전화번호처럼 규칙에 맞는 숫자가 다양하게 입력될 수 있는 경우를 찾아내기도 한다. 이런 과정을 거쳐 사람이 어떤 의도를 갖고 입력한 문장인지, 어떤 정보가 담겨있는지 식별해낼 수 있다.Q. 들어보니 기술에 대한 지식뿐만 아니라 언어학에 대한 조예가 필요한 분야로 보인다.A. 맞다. 이 분야를 전산학(컴퓨터공학)에서는 ‘자연언어처리’라고 하고 언어학에서는 ‘전산언어학(Computational Linguistics)’ 혹은 ‘계산언어학’이라고 한다. 학제 간 학문으로서의 성격이 강한 분야다. 초창기에는 언어학자들이 찾아낸 인간 언어의 구조, 규칙을 컴퓨터공학자 / 전산학자들이 프로그램으로 구현하는 연구가 많았다. 그러다가 애초의 예상보다 인간의 언어 구조가 훨씬 더 복잡하다는 것을 인식한 이후부터는 인간의 언어에서 규칙성을 찾는 과정도 통계적 방법 등을 통해 컴퓨터의 힘을 빌리게 되었다. 최근에는 요즘 화두인 머신러닝 기법을 적극적으로 적용하면서 연구 트렌드가 조금씩 바뀌고 있다. 다양한 규칙에 따라 문장을 분석하기보다, 빅데이터로 정리된 방대한 언어생활 자료를 컴퓨터 스스로 학습하여 문장 속에서 필요한 정보를 찾아내는 식으로의 전환이랄까. 하지만 여전히 좀 더 좋은 결과물을 내려면 언어학에 대한 지식과 규칙성에서 찾아낸 정보들이 필요한 것도 사실이다. 그래서 스켈터랩스에서는 규칙 기반 기법들과 머신러닝 기법 모두를 하이브리드 형태로 결합하여 대화 엔진을 개발하고 있다.Q. 아무리 다양한 형태로 기법을 결합하여 사용하더라도, 엔지니어가 언어학에 대해 연구하기는 쉽지 않아 보인다. 언어학을 별도로 공부하거나 혹은 언어학에 대한 관심을 이전부터 가지고 있었는지.A. 언어학이라기보다는 사실 나는 대학교에서 문학 동아리 활동을 오랫동안 했다. 자연스럽게 다양한 활동을 통해서 문학에 대한 얘기를 하다 보니 언어에 대한 관심도 꽤 높았던 것 같다. 무엇보다 구글코리아의 번역기 개발팀에서 인턴을 하며, 컴퓨터로 인간의 언어를 다루는 것이 굉장히 흥미롭다고 생각했고 꾸준히 관심을 이어왔다. Q. 구글 코리아 인턴 경험이 규홍님에게 여러모로 지대한 영향을 끼친 것으로 알고 있다. 그 얘기를 듣고 싶다.A. 대학에 처음 입학했을 때, 사실 실망감이 더 컸다. 합리적인 의사소통은 막혀있었고, 당시 학교의 학사제도 개편으로 인해 여러모로 시끄러운 상황이었다. 그러던 차에 마침 학교에 구글코리아에서 캠퍼스 리쿠르팅을 왔는데, 선배 중 한 명이 ‘왜 구글은 한국에서 인턴을 채용하지 않습니까' 라고 꽤나 당돌한 질문을 던졌다. 그렇게 구글 코리아 인턴 채용이 열려 면접 기회를 얻게 되었다. 당시 내 이력서에는 대학교 입학 후의 경력이라고는 연극동아리 공연 이력이 전부였기 때문에 일종의 두려움도 컸다. 하지만 일본어로 된 만화책을 컴퓨터에 넣으면 한국어로 번역된 만화책이 튀어나오게 하고, 컴파일(COMPILE) 사의 게임 중 미처 한국어로 번역되지 못한 게임들을 컴퓨터가 알아서 번역해 즐길 수 있게 하는, 그런 컴퓨터 프로그램을 직접 만들고 싶다는 꿈이 더 컸다. 마침 나의 면접관들도 구글 코리아 번역기 개발팀 분들이었다. 그렇게 구글 코리아 번역기 개발팀 인턴으로 입사하게 되었고, 그때의 경험이 나의 꿈의 실현 가능성에 대한 일종의 확신을 주었다.Q. 스켈터랩스에는 어떻게 입사하게 되었나A. 인턴 할 당시의 구글 코리아 사장이 지금 스켈터랩스 창업자, 조원규 대표님이다. 그리고 구글 코리아 면접관이었던 분이 우리 팀의 테크 리더(Tech Leader)를 맡고 있는 이충식 님이기도 하다. 작년 충식 님으로부터 어려운 문제를 풀어야 하는데 같이 한번 풀어보자는 연락을 받았다. 그 문제가 너무 어려울 것 같아서 답장을 망설이고 있었다. 그러다 이전 직장에 대한 염증과 새로운 일에 대한 호기심 등의 마음으로 충식님을 다시 만나 뵈니, 스켈터랩스에서 내가 어렸을 적 꿈꾸던 챗봇을 만들고 계셨다.Q.  스켈터랩스에서의 업무는 이전에 일했던 혹은 알고 있는 다른 개발자의 업무랑 어떻게 다른가. A. 사실 인공지능을 기반으로 한 스타트업에는 뛰어난 사람들이 많은 것 같다. 그러나 스켈터랩스가 다른 회사와 다른 점은 ‘내 동료가 누구인가'에 대한 인식의 범위가 조금 더 넓다는 점이다. 가령 디자이너는 디자이너끼리, 기획자들을 기획자끼리만 협력하고 부서에 따른 책임이나 업무 범위에 대해서 선을 긋는 문화가 흔히 있지 않나. 어떤 직장들은 수직적인 위계 구조를 강요하고 모든 걸 서류로 보고하게 만들기 때문에 일의 효율이 떨어지기도 한다. 그러나 스켈터랩스는 팀 간에, 직무 간에 서로의 업무 영역을 자로 재듯 규정하지 않고 넘나들며, 좀 더 활발한 소통을 추구한다. 덕분에 ‘하나의 공동체'라는 인식을 자연스럽게 가질 수 있다. 서로와 함께 일한다는 것에 대해 우리 스스로 가지는 자긍심도 대단하다. 사내에는 지인을 신규 입사자로 추천하는 채용 제도가 있는데, 그간 내가 일해왔던 회사 중 우리 회사만큼 열심히 지인들에게 추천하는 회사도 없었다. 사실 내가 일하는 회사가 별로면 친구에게 추천도 못 하지 않겠나. 그만큼 서로 만족하고, 자부심을 가지고 일한다는 것을 방증하는 면모인 것 같다.또한 스켈터랩스는 불필요한 서류 업무를 배제하는 대신, 아주 엄격한 코드 리뷰 시스템을 가지고 있다. 내가 과거에 근무했던 회사들은 많은 경우 상대적으로 지금 당장 작동하는 코드를 만들어 내는 것에 집중했다. 물론 이러한 방식이 때로는 실용적이다. 그러나 기능이 잘 작동되는지만 살피다 보니, 숨겨진 버그(Software Bug)가 남겨지고 이것이 뒤늦게 발견되어 더 큰 문제를 일으키기도 했다. 때로는 버그의 존재를 코드 작성자만이 알고 있기도 했다. 이렇듯 단기간 눈앞의 기능에만 집중하다가 코드의 품질이 저해되는 방식으로 개발이 진행되어 언젠가는 다시 수정해야 하는 일거리가 남겨지는 것을 ‘기술 부채(Technical Debt)’라고 부른다. 스켈터랩스의 코드 리뷰 문화는 사소한 영역까지 기술 부채를 남기지 않는다. 궁극적으로는 짧은 기간 완성도 높은 프로그램을 만들 수 있게 해주는 문화다. 엄격한 코드 리뷰가 가능한 것은 스켈터랩스의 개발자 역량이 높기 때문이기도 하다. 개발자들이 모두 기술에 대한 근본적인 이해와 최신 기술에 대한 섭렵을 두루 갖추었기에 타인이 작성한 코드도 바로 이해할 수 있다. 수준 높은 동료와 함께 일하며 피드백 받고 성장할 수 있다는 것은 회사의 굉장한 강점이라고 생각한다.사진2. 규홍 님과 다른 팀원 간의 코드 리뷰 모습.Q. 코드 리뷰 문화가 유익하기도 하지만, 일종의 압박감도 있을 것 같다. A. 압박감으로 여겨본 적은 없다. 한국 사회에서 개발자의 커리어에 대한 얘기를 나누다 보면 자연스럽게 ‘회사 일을 하다 보니 공부할 시간이 없어서 최신 기술을 알지 못해 뒤처진다.'라는 볼멘소리가 나온다. 그러나 스켈터랩스에서는 개발자 모두가 엄격한 코드리뷰를 거치는 과정에서 자연스럽게 더 나은 성능의 코드, 동료가 더 잘 이해할 수 있는 코드, 예상치 못한 예외 상황을 고려하는 코드를 작성하는 법을 실시간으로 배우게 되고, 때로는 그 과정에서 자연스럽게 코드 리뷰자가 제안하는 최신 기술에 대해 공부하고 습득하며 실력을 늘려나간다. 덕분에 코드 리뷰를 마치고 나면, 다음에 어떻게 해야 개선된 코드를 짤 수 있을지에 더 집중할 수 있고 실제로도 더 나은 코드를 작성할 수 있게 된다.물론 이런 문화가 신규 입사자로서는 다소 답답할 수 있을 것 같다. 나 또한 초반에는 ‘굳이 이런 디테일까지 다 잡아가며 이렇게 리뷰를 남겨야 할까'라는 생각을 해본 적도 있다. 그러나 스켈터랩스와 함께하는 시간이 점점 길어질수록, 꼼꼼한 리뷰로 기술 부채를 최소화하는 것이 팀 전체에도, 나의 성장에도 도움이 된다는 걸 느낀다.Q. 아무리 뛰어난 개발자가 있더라도 코드를 작성하는 사람은 한 명인데, 이를 함께 리뷰하다보면 작성된 코드를 이해하지 못하는 경우가 발생하지는 않나.A. 물론 그럴 수 있다. 때문에 스켈터랩스에서는 코드의 공동 소유, 공동 이해 개념을 깊이 이해하고, 잘 지킬 수 있게 만든다. 나만 이해할 수 있는 코드를 작성하면 장기적으로 다른 개발자들의 수정과 응용이 어려워진다. 그래서 스켈터랩스에서는 각 프로그래밍 언어별로 코딩 스타일 가이드를 준수할 것을 권장하고, 코드 리뷰 이전에도 가이드 준수 여부를 점검하는 도구를 활용하고 있다.Q. 스켈터랩스를 자랑한다면.A. 스켈터랩스는 아직 성장 중인, 그래서 ‘함께 만들어 갈 여지가 많은 회사'다. 나는 개인적으로 대기업부터 창업 초창기 단계의 스타트업까지 다양한 회사를 경험했는데, 이러한 과정에서 구성원 한 명 한 명이 회사의 문화와 기술적 원칙을 만들어가는데 얼마나 큰 영향을 주는지를 느꼈다. 스켈터랩스는 다양한 배경을 가진 개발자와 서로 영감을 주고받으며 함께 성장해가는 곳이다. 개발자 직군의 동료들과 비개발자 직군의 동료들이 끊임없이 소통하며 시행착오와 함께 점점 더 나은 기업문화를 만들어가고 있다. 그리고 실제로 이런 문화가 완성도 높은 프로그램을 만드는 데에 긍정적인 기여를 하고 있고, 현재는 성공 경험을 조금씩 안겨주고 있는 단계다. 역량 있는 인재들과 최신의 기술을 활용하여 새로운 결과물을 창출하는 것에 관심 있는 이들이라면 입사를 추천하고 싶다.#스켈터랩스 #사무실풍경 #업무환경 #사내복지 #기업문화 #개발팀 #팀원인터뷰 #팀원소개 #팀원자랑

주변 개발자들의 삶이 매우 행복을 추구하는 삶으로 변해가고 있다는 것을 느낀다. 주변의 개발자들의 모습을 몇 가지 정리해보자. 이를 '지속 개발을 위한 개발자 Life 스타일'이라고 정의하겠다.개발자#A10년 넘게 개발하던 패키지를 기반으로 필요 기능을 최소화하여 1인 개발기업에 성공하였고 제주도로 내려가서 지역에 속한 분들과 호흡하는 삶을 추구하면서도 소프트웨어 개발의 핵심을 잃지 않았다. 정말, MVP 기능에 최대한 집중하면서 필요한 시장 영역을 더 확대하지 않고, 소프트웨어를 개발하고 있는 개발자와 해당 소프트웨어를 사용하는 고객과 시장에 대해서 같이 합리적으로 지속할 수 있는 지속할 수 있는 소프트웨어 개발의 삶을 이루었다.그리고, 그러한 Life환경을 주변에 전파하면서 불과 얼마 전 또 한 명의 구 루급 개발자에게 비슷한 삶의 길을 가르쳐준다. 정말 부러운 개발자들...개발자#B복잡한 업무나 더 많은 보수를 위해서 더 좋은 회사를 찾기보다는 삶이 존재하는 근무시간을 위해서 재택근무를 찾고 있다. 비용도 최대한 낮추면서 생활을 위한 회사를 찾아다니고 있다. 아무래도, 외국계 개발회사를 선택할 것 같다.개발자#C오픈소스 진형에서 인정받는 개발자이다. 본인이 원하는 오픈소스 프로젝트를 추진하는 것을 보장받고 외국계 기업의 원격근무를 선택했다. 보수도 나쁘지 않고, 근무시간은 알아서 하는 것이지만, 원격으로 일하는 것이기 때문에 '능력'을 보여주기 위해 더 많은 시간을 소프트웨어 개발에 투자한다. 굳이, 서울 시내에 있을 필요가 없기 때문에 외각으로 집도 옮겼다.개발자#D일부러, 실리콘 벨리의 스타트업을 선택했다. 조만간 상장 예정인데 매우 큰 혜택을 받을 것 같다. 그 역시 지속 개발이 가능한 삶을 추구한다.2016년 올 초의 개발자 트렌드는 '지속 개발을 위한 Life'를 지향하는 개발자들이 늘어났다고 평가해본다.우리 모두 지속개발이 가능한 삶을 지향해 보는 것은 어떨까나...

와탭랩스 는 국내에서 보기드문 B2B SaaS 서비스 기업입니다. 그러다 보니 많은 도움도 받을 수 있었고 좋은 기업들도 많이 만날 수 있었습니다. 하지만 모든 것이 처음이다 보니 많은 실수들과 함께 커온 것도 사실입니다. 아래는 SaaS 기업들에게 꼭 필요한 내용들만 추렸습니다. 건너뛰거나 아직 진행 안한 내용들은 지금이라도 꼭 해보세요.  좋은 고객을 골라내세요. 와탭랩스는 서버 모니터링 서비스를 먼저 시작했습니다. 우리는 스타트업이 자사의 제품을 안정적으로 서비스하기 위해 우리의 제품을 사용할 거라 생각했습니다. 하지만 와탭에게 스타트업들은 생각처럼 좋은 고객은 아니였습니다. 그래서 우리는 서버 모니터링의 주요 고객층을 SMB 중에서 100대정도의 서버를 가진 기업으로 변경해야 했습니다. 우리는 초기에 좋은 제품을 만드는 일에 집중하고 좋은 고객을 찾는 과정을 허술히 생각했습니다만 그것은 큰 오판이였습니다. 우리는 우리가 만든 서비스를 사랑하는 사람들을 찾아 내는 데 최선을 다해야 합니다. 우리가 만든 제품의 가치를 지속적으로 발견해내는 고객들이 누군지 찾아 내야 합니다. 그러기 위해 계속 고객을 정의해 나가야 합니다."고객이 우리의 제품을 사는 것은 고객이 우리가 하는 일을 알아서가 아니라 우리가 고객이 하는 일이 무엇인지 알기 때문입니다." 계속, 끊임없이 고객을 분류하세요. 와탭의 서버 모니터링은 서비스에 가입하고 자사의 서비스에 에이젼트를 설치 한 후에 간단한 무료 모니터링을 시작으로 유료 기능까지 넘어가게 되어 있습니다. 반대로 와탭의 어플리케이션 모니터링은 가입 후 트라이얼 사용 후 유료 사용자로 넘어가게 구조화 되어 있습니다. 단계별 활성화 사용자와 비 활성화 사용자를 구별할 수 있어야 합니다. 단계별로 고객을 분류 할 수 없다면 분류할 수 있는 장치들을 마련해야 합니다.고객을 팬으로 만드세요. TV를 보면 많은 걸그룹과 남성그룹들이 나옵니다. 그리고 열성적이 팬들이 있죠. 그리고 팬들은 자신들만의 공간을 만들어 갑니다. 와탭도 그런 과정을 만들기 위해 노력하고 있습니다. 좋은 컨텐츠를 만들고 세미나를 열고 다양한 IT 행사를 지원합니다. 아직은 많이 어설프지만 와탭의 고객분들이 저희의 팬이 될 수 있도록 노력하고 있습니다. 와탭 사용자 분들은 앞으로 더 기대하셔도 좋습니다.  현재 줄 수 있는 가치로 고객을 유치하세요.항상 세일즈에게 당부드리는 이야기 입니다. 미래에 나올 기능으로 고객을 대하지 마라. 미래에 나올 A라는 기능을 대상으로 고객과 이야기 하면 고객은 A가 나올 때까지 기다립니다. SI 기술 영업인 경우에는 SI를 통해 제공 될 미래의 기능을 파는 것이지만 서비스를 파는 와탭랩스는 현재의 제공되는 서비스로 영업을 해야 합니다. 그렇기 때문에 현재 우리가 가지고 있는 제품이 고객에게 어떤 도움이 되는지 정확하게 이해하고 설명할 수 있어야 합니다. 이것은 와탭이 온라인 상에서 제공하는 마케팅에도 그대로 적용됩니다. 허황된 약속은 Churn Rate만 높일 뿐입니다. 우리가 고객에게 줄수 있는 가치를 정확히 전달해야 합니다. 이메일을 다양하게 사용하세요.와탭은 서비스를 오픈하고 처음에는 메일 서버를 만들어서 가입 인증 메일만 보냈습니다. 사용자가 쌓인 후에는 메일챔프를 사용해서 뉴스레터를 보내기 시작했죠. 이메일을 통해 튜토리얼을 보내거나, 교육 컨텐츠를 보내는 것도 좋은 방법입니다.Transactional Email을 사용하세요. 와탭도 이제 Transactional email을 추가하려고 준비 중에 있습니다. Transactional email은 가입 축하 / 유료 권유 / 패스워드 변경 등 가입 또는 사용 기간 및 상황에 맞쳐 자동으로 보내는 이메일 입니다. 대표적인 서비스로는 맨드릴 이 있습니다. Transactional Email을 사용해서 가입 축하 메일, 에이젼트 설치 튜토리얼 메일, 탈퇴 후 다시 돌아와 달라는 메일 등 다양한 메일을 보낼 수 있습니다.소셜 미디어를 사용하세요.제가 지금 사용하고 있는 브런치도 좋은 소셜 미디어 입니다. 제가 이 글 하나에 얼마나 많은 와탭링크를 남겼을까요? :) 유튜브 채널을 활용하는 것도 좋습니다. 페이스북은 이제 거의 필수죠. 회사마다 블로그도 운영하고 있을 것입니다. 슬라이드쉐어에 회사 관련한 많은 내용들을 올리는 것도 좋으며 큐오라도 적절하게 사용한다면 좋을 것입니다. 생태계를 배척하지 마세요. 와탭랩스는 클라우드협회의 회원사입니다. 클라우드 협외의 많은 분들이 다양한 경험을 바탕으로 국내 클라우드 사업과 SaaS 사업의 발전을 위해 노력하고 있습니다. 혹시 해외 사례와 비교하다보니 지엽적인 한계가 명확히 보일지도 모릅니다. 그럼 같이 들어와서 바꿔가면 됩니다. 와탭랩스가 서비스하는 IT 모니터링은 MSP(Managed Service Provider)와 영업을 전문으로 하는 리셀러사들이 복잡하게 얼켜있는 생태계를 구성하고 있습니다. 와탭은 좋은 솔루션을 제공하는 기업으로써 해당 생태계의 좋은 구성원이 되는 노력을 수년간 진행하고 있습니다. 자신의 생태계를 만들어 가세요. 최근 저희는 제2회 와탭 세미나를 개최했습니다. 이제 막 시작했지만 100명이나 모인 세미나였습니다. 규모를 키우다 보면 컨텐츠도 쌓일 것입니다. 와탭은 백엔드 서비스 기업들을 모인 백엔드클럽도 만들었습니다. 열심히 회원사로 활동도 해야겠지요. (아, 최근 열심히 못했습니다. 죄송합니다. ) 와탭은 성능 분석 전문가들이 모일 수 있는 플랫폼도 만들 계획입니다. 이처럼 직첩 다양한 생태계를 만들어 가는 것도 중요합니다. SaaS 세계에서는 이 모든 것들이 마케팅입니다. 회원 탈퇴를 숨기지 마세요.미국 엘리베이터에 닫음 버튼은 동작하지 않습니다. 장애인의 불편을 해소하고자 닫음 버튼을 막았지만 여전히 닫음 버튼이 엘리베이터에 있는 이유는 심리적 안정감(내가 엘리베이터의 문을 닫을 수 있다는)을 제공하기 위해서 입니다. 그런데 많은 서비스들이 회원 탈퇴를 숨기고 있거나 또는 애써 외면하고 있습니다. 숨긴다는 것보다는 신경을 안씀으로써 자연스레 숨겨지는 결과를 만들어 내는 것에 가까운것 같습니다. 이 또한 가입자에게는 심리적 압박감으로 다가올 수 있습니다. 그리고 사용하지 않는 사용자들만 사이트에 쌓이게 만드는 효과를 내기도 합니다. 차라리 탈퇴를 공개하고 탈퇴 시 이유를 묻는 과정을 넣는 것이 유리합니다. 탈퇴를 하는 이유를 조사하세요.정말 중요한 질문입니다. 왜 탈퇴를 하시는 건가요? 해당 질문은 탈퇴의 마지막 구간에서 집행하는 것이 좋습니다. 와탭랩스는 아직 해당 프로세스를 타고 있지 못합니다. 하지만 결국은 우리도 만들 예정인 프로세스입니다. 아쉽게도 한국은 서베이를 참 안해주는 국가로 알고 있긴 합니다. :)고객과 관계를 맺으세요.와탭은 무료 서비스와 트라이얼 서비스를 제공합니다. 물론 유료화가 최종 목표입니다. 그렇기 때문에 매일 아침 무료 고객과 트라이얼 고객의 서비스 이슈를 분석합니다. 알럿이 너무 많이 나온 고객에게 전화해서 이슈를 확인하고 도움을 드린다거나 설치에 곤란을 겪는 고객에게 전화를 드리고 시연을 진행하는 일들이 있습니다. 물료 유료 고객에게도 마찬가지입니다. 유료 고객에게는 성능 리포트를 무료로 제공해 드리기도 합니다. 신용카드를 통한 자동이체 프로세스를 만드세요. 대부부의 가맹점들이 공식적으로 지원하지 않는 것이 신용카드를 통한 자동이체 프로세스입니다. 특히 한국에서는 어떤 빌링사에서도 공식적으로 지원하고 있지 않습니다. 하지만 SaaS 서비스 기업이라면 꼭 진행하셔야 합니다. 혹 당장 안해준다면 고객을 조금만 모은다음에 다시 연결해 보세요. #와탭랩스 #와탭 #SaaS #인사이트 #운영 #SaaS서비스 #SaaS기업

친숙한 MVC 패턴개발자라면 누구에게나 친숙한 MVC (모델 - 뷰 - 컨트롤러) 패턴은 꽤 오랜 시간 동안 사용됐고 아직까지 많은 개발자들에게 사랑받고 있는 패턴이다. 그 이유로는 이 패턴이 일단 진입장벽이 낮기도 하지만 코드 재사용성, 동시 개발의 용이성 때문이다. 만약 당신이 초보 iOS 개발자라면 높은 확률로 MVC 패턴을 쓰게될 것인데 그 이유는대부분의 예제 및 튜토리얼이 MVC 패턴을 쓰고 있고iOS의 IDE인 Xcode에서 (Swift 는 예외지만) 클래스를 생성할때 기본으로 이름에 ViewController라고 들어간다.위와 같은 이유로 많은 iOS 개발자에 영향을 주리라 생각된다. (2011년도부터 iOS 세계에 빠진 저자도 사실 iOS에서는 software architectural design pattern으로는 MVC가 넘사벽이라고 생가하고 있었기에) 문제는 상대적으로 복잡도가 높아지거나 코드의 양이 많은 제품의 개발에서는 생산성이나 가독성에 그다지 도움을 주지 못하는 데 있다고 생각한다. 예를 들어, 한 페이지의 복잡도가 높아지면 ViewController 파일 한 개의 코드 라인이 기하급수적으로 증가한다. 또 (코드 관리에 매우 신경을 쓰지 않는 이상) 객체 간의 통신 및 데이터의 통일성이 없어져서 가독성이 떨어지기 쉽고, 기능을 추가할 때 생산성이 점점 떨어지게 된다.왜 MVC 패턴은 이렇게 문제가 생기는걸까라는 질문에서부터 시작해보자.MVC 패턴, 도대체 뭐가 문제인가?!그림 1. 보편적인 MVC 패턴의 구조보편적으로, MVC 패턴의 구조는 위의 그림과 같다. 그림을 간단히 설명하자면:뷰에서 이벤트가 발생하면 컨트롤러에 알린다컨트롤러는 그것을 처리하고 모델에 업데이트를 하라고 전달한다.모델은 업데이트를 하고 컨트롤러에 다시 알린다컨트롤러는 모델이 업데이트되었다는 것을 뷰에 알린다뷰는 모델의 업데이트된 값에 따라 다시 뷰를 그린다그림 1과 위의 설명만 놓고 보면 각각의 역할이 명확하다고 생각한다. 구조가 복잡하지 않기 때문에 초보자들도 쉽게 이해하고 적용 가능하다는 것이 장점이다. 하지만 MVC 패턴은 객체 간에 어떤 방향으로 커뮤니케이션 해야 하는지에 대해서는 강제하지 않기 때문에 파생된 패턴들이 많이 있다. 실제로 구글에서 “MVC pattern”이라고 검색을 하면 위 그림과 다른 MVC 패턴 이미지들을 볼 수 있다. 그 한 가지 예가 밑에 그림 2이다.그림 2. 또 다른 MVC 패턴의 구조그림 2를 보면 그림 1과는 다른 커뮤니케이션 방향을 나타내고 있다. 바꿔 말하면 개발자가 원하면 언제든지 세 가지 구조 안에서 방향을 유동적으로 바꿔 써도 무방하다는 것이 된다 (그것이 원하는 MVC 패턴이든 아니든지 간에). MVC의 변형으로써는 여러 가지가 있지만, 대표적인 것들은 아래의 그림과 같이 MVP, MVVM 같은 것들이 있다.그림 3. MVC, MVP, MVVM 패턴의 비교실제 저자도 MVC 패턴이 커뮤니케이션 방향을 강제하지 않는 것과 관련해 문제를 겪은 경험이 여러 번 있었던 것을 기억한다. 한가지 예를 들어보자.ViewA.swift (뷰)protocol ViewADelegate {       func updateA() }   class ViewA : UIView {        var delegate: ViewADelegate?       //update through protocol      func didClickOnA() {          self.delegate?.updateA()     }      //update through notification     //maybe same kind of update can happen in other views      func didClickOnAA() {         NotificationCenter.default.post(             name: NSNotification.Name(rawValue: “updateFromA”),              object: nil         )     }      func render(_ model: product) {         //update based on model      }  } ViewController.swift (컨트롤러)class ViewController : UIViewController, ViewADelegate {       Var viewA: ViewA?     Var product = Product()     func viewDidLoad() {         self.viewA = ViewA()         self.viewA.delegate = self         // ...         self.view.addSubview(self.viewA)     }      func updateA() {         self.product.update(name: “aa”, version: “123”)         self.viewA.update(self.product)         //re-render viewA     }  } Product.swift (모델)class Product {       var name = “”     var version = “”     init() {         NotificationCenter.default.addObserver(             self,             selector: #selector(self.doSomething),             name: “updateFromA”, object: nil)     }      deinit {         NotificationCenter.default.removeObserver(self)     }      func update(name: String, version: String) {         self.name = name         self.version = version     }      func doSomething() {          //do something…          //notify viewA or any objects through notification     }  } 조금 극단적인 예처럼 보이긴 하지만 실제 개발을 하다 보면 충분히 일어날 수 있는 상황이다. 코드에 대해 간략하게 설명하자면:ViewA에서는 delegate와 notification으로 각각 ViewController와 Product에 이벤트를 날리고 있고ViewController에서는 delegate method를 구현해서 Product를 업데이트 후, 다시 ViewA를 그리라는 로직을 가지고 있다.Product 에서는 객체를 업데이트 할 수 있는 메소드가 있고 notification을 통한 업데이트를 하고 있다.이건 아주 간단한 예이지만 프로젝트가 커진다면 특정 이벤트에 대해 데이터가 업데이트되는 경로가 달라질 수 있다. ViewA -> Product -> SubProduct -> Product -> ViewA 의 경로라던가, ViewA -> Controller -> Product -> SubProduct -> Controller -> ViewA 의 경로 등이 가능하다. 이처럼 특정 이벤트에 대해 여러 가지 체인형식으로 업데이트가 이루어질 경우 그 경로를 일일이 추적하는데 시간이 걸릴 수밖에 없는 구조를 가지고 있는 것을 볼 수 있다.(프로젝트의 크기가 어느정도 커지게 된다면 이렇게 될지도 ㅎㅎ)이런 케이스가 발생하는 근본적인 이유는 결국 MVC 패턴의 장점이라고도 말할 수 있는 유연성과 양방향 커뮤니케이션 때문이다. 이 패턴 자체가 문제가 있는 것은 아니지만 결국 코드는 사람이 작성하는 것이기에 생산성과 가독성을 떨어뜨리는 결과를 초래할 가능성이 높다. 여기에서 우리는 기존 웹 개발에서 쓰이고 있던 Redux 도입을 생각하게 된 것이다.Redux는 무엇인가?Redux 로고Redux는 Facebook의 Flux 를 모태로 삼고 있고 예측 가능한 상태를 자바스크립트 프로그램에서 구현하기 위한 애플리케이션 아키텍쳐이다. Redux는 본래 자바스크립트에서 시작한 오픈소스 프로젝트이지만 다른 개발자들에게 영감을 주었고 2015년 말쯤 iOS 플랫폼에서는 ReSwift(Redux + Swift)가 생겨났다. ReSwift는 결국 Redux랑 크게 다르지 않고 Redux의 세 가지 법칙을 따른다.Single source of truth — 애플리케이션의 전체 상태(State, 또는 데이터)는 트리 형태의 하나의 저장소(Store)로 저장된다.Changes with pure functions — 상태 트리를 변경하는 리듀서(Reducer)는 순수 함수(pure function)이어야한다.Read-only states — 상태는 오직 액션(Action, 어떤 일이 일어날 것인지 설명할 수 있는 객체)으로만 변화가 가능하다.쉽게 말하자면 “Redux는 한 개의 상태 저장소를 가지고 있고 그 안에 있는 데이터만이 신뢰할 수 있으며 저장소의 상태는 오직 순수 함수인 리듀서를 통해서만 변화가 가능하다” 라고 축약 할 수 있다.그림 4 Redux 패턴의 구조위의 그림 4을 보면 충분히 프로그램의 흐름이 어떤 식으로 흐르는지 감이 왔으리라 생각한다.이벤트가 뷰에서 생성되면 그에 해당이 되는 액션을 통해 알린다.액션은 특정 리듀서에서 처리한다.리듀서는 액션에 따라 저장소를 업데이트한다.저장소에 변화가 오면 구독(Subscribe)을 하고 있는 모든 객체에 알린다.이것이 Redux의 커뮤니케이션 사이클이다. Redux만으로도 충분히 여러가지 블로그 주제가 나올 정도로 할 이야기가 많지만 여기까지만 하고, 좀 더 자세한 디테일을 알기 원한다면 옆의 링크를 클릭하시면 된다. :) -> 리덕스 공식 링크Redux vs. MVCMVC와 Redux에 대해 소개를 했으니 간단히 비교해 보자.The Flow — Redux는 데이터 및 애플리케이션의 흐름을 강제한다. 저장소의 변화는 오직 액션을 통해서만 가능하기 때문이다. 이와 다르게 MVC는 강제성이 없기 때문에 여러가지 파생 패턴이 생길 수 있다.Unidirectional flow — Redux에서 흐름은 액션으로만 변화가 일어나기 때문에 오직 한쪽으로만 흐른다. MVC에서는 양방향이 될 수도 있고 한 방향이 될 수도 있지만 보통 양방향이다.Stores — Redux에서는 상태 및 데이터가 하나의 저장소에 있기 때문에 관리하기가 쉬운 반면, MVC에서는 여러 군데에 상태가 분리되어 있기 때문에 동기화에 신경을 써야 한다. (로컬 데이터 스토리지를 쓴다면 문제가 해결되기는 하지만 패턴 이외에 추가적인 노력이 필요함)그 이외에 여러가지 다른 점이 있겠지만, 위의 3가지가 가장 다른 점이라고 저자는 생각한다.채널 데스크 iOS에 Redux를 적용하게 된 이유이제 MVC와 Redux의 차이점을 알게 되셨으리라 생각한다. 우리 팀이 채널 데스크 iOS에 Redux를 적용한 이유를 소개하려고 한다. 아직 모든 부분에 완벽히 적용한 상태는 아니지만 (부분적으로 Notification, Delegate 그리고 Reactive를 쓰고 있다) 그럼에도 Redux를 적용함으로써 얻는 이점이 많다고 느끼고 있다.Explicit data flow — 새로운 개발자가 왔을 때나 여러 명이 작업을 할때 애플리케이션의 전체 흐름을 파악하고 이해하기 쉽다.Unidirectional flow — 데이터 관련 부분을 전부 Redux로 대체하니 모든 데이터 흐름이 한 방향으로 강제되었다. 덕분에 데이터가 어디에서 왔고 어디로 가는지를 파악하기 매우 쉽다.Single storage — 한 곳에서만 데이터를 관리하기 때문에 데이터에 관한 부분은 리듀서만 잘 짜 놓으면 관리하기 쉬워진 점이 있다. Redux를 적용하기 전에 CoreData를 데이터 저장소로 쓰고 있었는데, 어느 시점에 어떻게 저장되는지 눈에 들어오지 않아 불편한 점을 Redux를 사용함으로써 해결할 수 있었다.Immutability and data consistency — 변경 가능한(Mutable) 객체는 보통 iOS 개발에서나 다른 플랫폼 개발에서 장점일수도 있다. 하지만 데이터의 일관성이 깨지기 쉽다. 만약 A에서의 데이터와 B에서의 데이터가 다르면 어떤 것을 신뢰해야 하는지의 문제도 생길 수 있다. 우리는 Redux의 저장소에 있는 데이터를 모두 변경 불가능한 객체(Immutable, Swift에서는 Struct을 쓴다)로 구현하여 이 문제를 해결하였다. 이 부분은 코딩할 때 불편한 점이 조금 있지만, 그 불편함을 감수할만한 가치가 있다고 생각한다.Predictability — 저장소는 오직 액션을 통해서만 변경할 수 있다는 점이 무엇보다 장점인 것 같다. MVC와 같이 데이터를 어디서든 변경할 수 있다면 데이터와 관련된 버그를 찾는 데 소비하는 시간이 길어지곤 한다. Redux는 어떤 액션이 어디에서 불리는지 아는 것만으로도 그 시간을 비약적으로 단축할 수 있다.Maintainability — 저장소, 상태, 액션 그리고 리듀서로 역할과 레이어를 분리하게 되니 보통 코드 라인이 100줄을 넘지 않는다. 그만큼 유지보수 비용이 적어졌다.Organized Code — MVC 패턴에서는 비지니스 로직이 뷰에 들어가는 경우가 있기도 했었는데 Redux의 가이드라인을 따름으로써 자연스럽게 대부분의 뷰는 그저 데이터를 받고 시각화하는 dummy 뷰의 형태가 되었다. 비즈니스 로직이 완전히 뷰와 분리됨으로써 뷰의 복잡도와 코드를 관리하기가 쉬웠다.ReSwift 도입 시 주의할 점ReSwift 도입을 고려하는 분들을 위해 몇 가지 주의할 점을 소개하겠다.Performance — ReSwift에서는 저장소가 변경될 때마다 newState: 메소드가 호출이 되어 화면을 업데이트할 수 있게 되어있다. 채널 데스크 같은 경우는 실시간 애플리케이션(Real-time application)이라서 API 이벤트와 Socket 이벤트가 자주 발생해서 저장소가 변경되는데, 도입 초기 단계에 이 부분을 간과해서 화면이 거의 멈출 정도로 퍼포먼스가 나오지 않았었다. 만약 ReSwift를 적용했는데 퍼포먼스가 나오지 않는다면 newState: 함수 부분을 최적화하거나 미들웨어(middleware)를 만들어서 batch 형식으로 액션을 처리하는 방식을 고려해봐야 한다.Not thread safe — ReSwift는 thread-safe 하지 않아서 초반에 알 수 없는 crash들이 자주 발생했었다. 저자 같은 경우는 ActionWrapper를 만들어서 액션은 항상 메인스레드에서 처리되도록 강제했다.글을 마무리하며..Redux는 이미 자바스크립트 개발에서는 React와 함께 많이 쓰이고 있지만 iOS에서는 아직도 생소한 아키텍쳐이다. ReSwift는 아직 2년도 되지 않은 프로젝트이고 자바스크립트에서 처럼 유용한 Redux 미들웨어도 많지 않다. 또한 인지도도 MVC, MVVM, MVP에 아직 미비한 편이다. 프로덕션에 참고할 만한 예제도 찾기 어려웠기에 초기 러닝 커브는 조금 있었던 것으로 회상한다. 그럼에도 불구하고 우리 팀은 ReSwift를 적용해 보다 깨끗하고 유지보수하기 쉬운 프로그램을 만들 수 있었고 만족하며 사용하고 있다. 기존 MVC의 불편함을 아시는 분들은 충분히 도입할 가치가 있다고 생각한다.#조이코퍼레이션 #개발자 #개발팀 #인사이트 #경험공유 #일지 #Redux

크래커나인 팀에서는 사용자의 의견을 적극 반영하기 위해서 안드로이드 개발자 박형일님의 크래커나인 사용기 인터뷰를 해보았습니다.개발자 박형일님본인 소개를 부탁 드려요~저는 에이치나인에서 안드로이드 개발 파트를 담당하고 있는 박형일 입니다. 개발 경력은 12년 정도 됐구요.에이치나인에 입사한지는 4년 정도 됐습니다. 주로 외주 안드로이드 앱 개발 업무를 하고 있습니다.개발일을 꽤 오래 하셨네요. 시니어 개발자들은 코드를 직접 작성하는 것을 선호 하시는 것 같던데, 형일님은 어떠신가요?저도 코드를 직접 작성하는 것을 선호 하는 편입니다. 툴에서 생성되는 코드를 별로 신뢰하지 않아요. 제가 원하는 대로 안 나온다는 느낌을 많이 받거든요.그럼 크래커나인의 첫인상은 어떠셨나요? GUI 로 부터 코드를 생성해 주는 툴인데..처음엔 아이디어는 괜찮은데, 이게 과연 제대로 된 코드를 생성 해 줄까? 라는 의심이 들었죠. 꼭 사용 해 보고 싶은 프로그램은 아니었어요.크래커나인을 사용하신지는 얼마나 되셨죠?올해 6월쯤에 처음 접하여 2달 정도 된 같아요.어떤 프로젝트에 적용 해 보셨나요?회사에서 회의실 예약 시스템이 필요하다고 해서 회의실 예약 앱을 만들었어요.그 때 처음 사용 했죠. 공식 프로젝트가 아니라 디자이너 없이 웹에서 무료로 사용할 수 있는 Sketch 파일로 된 디자인 샘플을 받아서 혼자서 만들었어요.앱을 구성하는 화면은 대략 5~6개 정도로 간단한 프로젝트여서 가능 했죠. 지금은 외주 과제를 하고 있는데, 크래커나인을 사용 해서 하고 있어요.외주 같으면 주로 파워포인트로 작성된 GUI 가이드라인 문서를 보고 개발 하잖아요. 크래커나인을 사용하기 전에는 디자이너와 무엇을 통해서 개발에 필요한 디자인 정보를 얻으셨어요? 에이치나인에 있으면서 거의 대부분 GUI 가이드라인 문서를 보고 개발 했죠. 최근에 다른 프로젝트 팀에서 GUI 가이드라인 문서 없이 제플린을 쓰더라구요. 그래서 그것도 조금 써봤어요.제플린과 같은 기존의 유사 서비스와 비교해서 크래커나인은 어땠나요?GUI 가이드라인 문서를 보면서 개발을 하다 제플린을 써보니까 너무 편리하더라구요. 문서에서 원하는 정보 찾는게 불편했거든요.그래서 사실 처음 크래커나인을 사용 했을 때는 제플린과 큰 차이를 못 느꼈어요.근데 프로젝트를 진행 하다 보니 크래커나인의 코드 생성 기능이 있어서 좀 더 편리하다고 느껴지는 순간이 오더라구요. 제플린을 보고 개발 할 때는 코드나 수치를 직접 입력하다 보니 실수를 할 때도 있었고, 여전히 XML 작성하는 수고로움이 남아 있었거든요.근데 크래커나인의 레이아웃 코드 생성 기능을 사용해서 나온 XML 코드가 100% 는 아니지만 70~80%는 작업을 안해도 될 수준이더라구요. 그래서 XML 작성하는데 들이는 시간이 많이 줄어 들었어요.크래커나인을 익히는데 어렵지는 않으셨어요?타 서비스를 사용한 경험이 있어서 많은 부분 기능을 따로 매뉴얼로 보지 않아도 파악이 됐는데요.사용하는데 크게 문제는 없었던 거 같아요. 직관적으로 파악이 안 되는 기능은 사용하지 못한 것 같지만 따로 매뉴얼은 찾아보지 않았습니다.Cracker9의 어떤 기능이 가장 편리하셨나요?당연히 레이아웃 코드 자동 생성 기능이었습니다.손으로 직접 코딩 하지 않고 View들의 관계를 맺으면 자동으로 View의 관계와 속성을 xml 코드로 생성해주는 기능이 개발하는 데에 상당히 많은 도움이 되었습니다.Cracker9을 사용하면서 불편했던 점이나 개선했으면 하는 부분이 있었나요?Asset 이름이나 리소스(문자열, drawable) 이름이 해쉬값이나 text1, text2 이런 식으로 되어 있어 나중에 다 변경을 해 주어야 되었습니다. 이 부분은 개선이 되었으면 좋겠습니다.※ 위의 내용은 Cracker9 0.9.5 에서 개선되었습니다.Cracker9의 정식 버전으로 출시가 되면 사용할 의향이 있으신가요?네, 사용할 것 같아요. 가격만 너무 비싸지 않으면 전 무조건 사용하겠습니다.App을 만들거나 디자이너와 소통해야 하는 다른 개발자들에게 알려주고 싶은 Cracker9 사용 Tip이 있다면 알려주세요~디자이너가 텍스트나 이미지 단위로 View를 만드는데요. 개발자가 원하는 모든 View를 만들진 않기 때문에 Custom Layout 활용은 필수입니다.Custom Layout을 잘 활용하시면 원하시는 레이아웃 작업이 모두 가능합니다. 그리고, 오른쪽에 Tree Structure 패널이 있는데요.View의 트리 구조 순서로 레이아웃 xml 코드가 생성되기 때문에 어떻게 코드가 만들어질지 예상할 수 있어요. 물론 View의 순서나 부모/자식 관계는 마우스 드래그로 편집할 수 있습니다.마지막으로 Constraint Layout의 관계를 맺을 때, View가 작으면 정확하게 클릭하여 작업하기 어려울 수 있는데요. 당연하지만 View를 확대해서 연결 지으면 쉽게 작업할 수 있습니다.마지막으로 Cracker9에게 한 말씀해주세요~저는 안드로이드 App을 개발하면서 레이아웃 작업은 초반에 하는 시간 잡아먹는 노가다 작업이라고 생각을 했는데요.레이아웃을 자동으로 생성해주는 Cracker9을 사용하면서 더 이상 노가다라는 생각을 하지 않게 되었습니다. 아직은 Beta 버전이라 부족한 부분이 보이지만, 개선될 것이라고 믿고 계속 사용할 거 같아요.앞으로 발전하는 모습 기대하겠습니다 파이팅!#에이치나인 #디자이너 #개발자 #협업툴 #크래커나인 #솔루션기업 #팀원인터뷰 #기업문화 #조직문화 #팀원자랑

1. What is BLE?스마트폰이 출시되어 대중화가 될 무렵, ‘스마트’한 개념의 밴드, 워치, 글래스 등이 출시되면서 웨어러블 디바이스 시장이 태동하기 시작했다. 그리고, 2015년 상반기, 애플워치의 등장으로 작은 생태계를 이루고 있던 웨어러블 디바이스들이 다시 한번 각광을 받게 되었다. 각기 생긴 모습은 다르지만 이들의 공통점은 스마트폰과 연동되어 작동한다는 것이었다. 과거부터 기기들간의 단거리 무선통신은 Bluetooth라는 기술이 이용되었다. Bluetooth가 공식적으로 등장한지 약 16년이라는 세월이 흘렀지만, 여전히 기기간의 무선통신에는 Bluetooth가 사용된다. 하지만, 지금 사용되는 Bluetooth는 기존과는 다른 방식이다. 바로 BLE라는 특징을 가진 Bluetooth인데, 바로 이것이 오늘날 다양한 종류의 웨어러블 디바이스들이 태어날 수 있었던 원동력이 되었다. 그렇다면 BLE라는 것이 도대체 무엇일까?그림1. BLE가 뭐지? 먹는건가?과거부터 기기들간의 무선 연결은 주로 Bluetooth라는 기술을 이용했는데, 이들은 기기간에 마스터, 슬레이브 관계를 형성하여 통신하는 Bluetooth Classic이라는 방식을 이용했다. 사람들이 이러한 기기들을 이용하면서 많이 염려했던 것은 ‘Bluetooth를 연결하면 베터리가 빨리 소모된다’, ‘사용하지 않을 때는 Bluetooth 꺼놓아야지’ 등과 같은 베터리 관련된 문제들이었다. 사실이었다. Bluetooth Classic은 다른 디바이스를 무선으로 연결을 하여 사용할 수 있는 편리함을 주었지만, 연결이 되는 동안에는 베터리를 빠르게 소모시켰기 때문에 사용하는 데에 많은 불편함이 있었다.2010년, 새로운 Bluetooth 표준으로 Bluetooth 4.0 이 채택이 된다. 기존의 Bluetooth Classic과의 가장 큰 차이는 훨씩 적은 전력을 사용하여 Classic과 비슷한 수준의 무선 통신을 할 수 있다는 점이었다. 이는 당시 Bluetooth의 최대 단점이었던 과도한 베터리를 소모 문제를 해결하는 기술이었기 때문에, Bluetooth 관련 업계에 큰 반향을 일으켰다. 이렇게 저전력을 이용하여 무선통신을 하는 특징을 Bluetooth Low Energy (이하 BLE) 라고 부르는데, Bluetooth 4.0 이후의 버전들은 이 용어로 대체되서 불리기도 한다. 최근 출시되고 있는 스마트 밴드, 워치, 글래스 등의 웨어러블 무선통신 기기들의 대부분은 이 BLE 방식을 이용하여 무선 통신을 한다.Bluetooth Smart Ready, Smart, ClassicBLE 기술이 등장하면서 Bluetooth 디바이스들은 아래와 같이 3가지로 분류 되었다.그림2. BLE 3가지 분류Bluetooth 4.0과 함께 새롭게 등장한 Bluetooth Smart Ready, Bluetooth Smart에 대해서 살펴보면,Bluetooth Smart Ready 디바이스는 Bluetooth Classic 및 저에너지 Bluetooth 무선통신 (BLE)을 지원하기 때문에 “듀얼 모드” 라디오라고 불린다. 따라서, 이들은 현재 시장에 나와 있는 수억 종의 Bluetooth 디바이스들에 대한 역방향 호환성을 가진다. 종류에는 스마트폰, 태블릿, PC, TV 그리고 셋탑박스 및 게임 콘솔 등이 있다. 이런 디바이스들은 클래식 Bluetooth 디바이스 및 Bluetooth Smart 디바이스들로부터 데이터를 받아, 이들을 유용한 정보로 변환시키는 Bluetooth 시스템의 허브라고 할 수 있다.Bluetooth Smart 디바이스 내에 있는 라디오는 “싱글모드” 라디오라 불리는데, BLE 연결만을 지원한다는 의미이다. 이들은 기존의 Bluetooth Classic 디바이스들과 호환이 되지 않고 듀얼모드 라디오를 가진 Bluetooth Smart Ready 디바이스 혹은 제조업체에 의해 호환성이 명시된 특정 Bluetooth 디바이스에만 연결이 가능하다. Bluetooth Smart 디바이스들은 ‘우리 집의 창문은 모두 잠겨 있는지’, ‘내 인슐린 농도는 얼마인지’, ‘오늘 내 몸무게는 몇 킬로그램인지’ 등과 같이 특정한 형태의 정보를 수집해, Bluetooth Smart Ready 디바이스로 보내기 위해 만들어진 디바이스이다. 종류에는 심박 모니터, 스마트 손목시계, 창문 및 현관 보안 센서, 자동차 키 체인, 그리고 혈압 팔찌 등이 있다.이 글에서는 BLE를 사용하는 디바이스들이 어떤 과정으로 서로 연결되어 통신을 하는지 그리고 이 과정들을 tracking 할 수 있는 장비인 Ubertooth 에 대해 내용을 정리해서 공유해보고자 한다.2. How they communicate?BLE를 지원하는 디바이스들은 기본적으로 Advertise(Broadcast) 과 Connection 이라는 방법으로 외부와 통신한다.Advertise Mode ( = Broadcast Mode)특정 디바이스를 지정하지 않고 주변의 모든 디바이스에게 Signal을 보낸다. 다시 말해, 주변에 디바이스가 있건 없건, 다른 디바이스가 Signal을 듣는 상태이건 아니건, 자신의 Signal을 일방적으로 보내는 것이라고 생각하면 된다. 이 때, Advertising type의 Signal을 일정 주기로 보내게 된다.Advertise 관점에서, 디바이스의 역할은 다음과 같이 구분된다.Advertiser ( = Broadcaster) : Non-Connectable Advertising Packet을 주기적으로 보내는 디바이스.Observer : Advertiser가 Advertise를 Non-Connectable Advertising Packet을 듣기 위해 주기적으로 Scanning하는 디바이스.그림3. Advertiser and ObserverAdvertise 방식은 한 번에 한 개 이상의 디바이스와 통신할 수 있는 유일한 방법이다. 주로 디바이스가 자신의 존재를 알리거나 적은 양(31Bytes 이하)의 User 데이터를 보낼 때도 사용된다. 한 번에 보내야 하는 데이터 크기가 작다면, 굳이 오버헤드가 큰 Connection 과정을 거쳐서 데이터롤 보내기 보다는, Advertise를 이용하는 것이 더 효율적이기 때문이다. 게다가 전송할 수 있는 데이터 크기 제한을 보완하기 위해 Scan Request, Scan Response을 이용해서 추가적인 데이터를 주고 받을 수 있다 (이에 대해서는 뒤에 자세히 설명한다). Advertise 방식은 말 그대로 Signal을 일방적으로 뿌리는 것이기 때문에, 보안에 취약하다.Connection Mode양방향으로 데이터를 주고받거나, Advertising Packet으로만 전달하기에는 많은 양의 데이터를 주고 받아야 하는 경우에는, Connection Mode로 통신을 한다. Advertise처럼 ‘일대다’ 방식이 아닌, ‘일대일’ 방식으로 디바이스 간에 데이터 교환이 일어난다. 디바이스간에 Channel hopping 규칙을 정해놓고 통신하기 때문에 Advertise보다 안전하다.Connection 관점에서 디바이스들의 역할은 다음과 같이 구분된다.Central (Master) : Central 디바이스는 다른 디바이스와 Connection을 맺기 위해, Connectable Advertising Signal을 주기적으로 스캔하다가, 적절한 디바이스에 연결을 요청한다. 연결이 되고 나면, Central 디바이스는 timing을 설정하고 주기적인 데이터 교환을 주도한다. 여기서 timing이란, 두 디바이스가 매번 같은 Channel에서 데이터를 주고 받기 위해 정하는 hopping 규칙이라고 생각하면 된다.Peripheral (Slave) : Peripheral 디바이스는 다른 디바이스와 Connection을 맺기 위해, Connectable Advertising Signal을 주기적으로 보낸다. 이를 수신한 Central 디바이스가 Connection Request를 보내면, 이를 수락하여 Connecion을 맺는다. Connection을 맺고 나면 Central 디바이스가 지정한 timing에 맞추어 Channel을 같이 hopping을 하면서 주기적으로 데이터를 교환한다.그림4. Central and Peripheral3. Protocol Stack디바이스들은 Bluetooth로 통신을 하기 위한 Protocol Stack을 가지고 있다. 일반적으로 네트워크 통신을 하기 위해서는, 통신을 위한 규약인 Protocol을 정의해야 되는데, 이렇게 정의된 Protocol들을 층층이 쌓아놓은 그룹이 Protocol Stack이다. Bluetooth Signal Packet을 수신하거나 송신할 때, 이 Protocol Stack을 거치면서 Packet들이 분석되거나 생성된다.그림5. Protocol Stack위 그림에서 볼 수 있듯이 Protocol Stack은 가장 아랫단부터 크게 Controller, Host, Application 로 나뉜다. 여기서는 Connection 과정에서 필요한 부분인 Physical Layer, Link Layer, Generic Access Profile(GAP), Generic Attribute Profile(GATT)에 대해서 알아볼 것이다.3.1 Physical LayerPhysical Layer에는 실제 Bluetooth Analog Signal과 통신할 수 있는 회로가 구성되어 있어서, Analog 신호를 Digital 신호로 바꾸어 주거나 Digital 신호를 Analog 신호로 바꾼다. 또한 Bluetooth에서는 2.4 GHz 밴드를 총 40개의 Channel로 나누어 통신을 한다. 40개 Channel 중 3개 Channel은 Advertising Channel 로써 각종 Advertising Packet을 비롯하여 Connection을 맺기 위해 주고 받는 Packet들의 교환에 이용된다. 나머지 37개의 Channel은 Data Channel 로써 Connection 이후의 Data Packet 교환에 이용된다.그림6. Channels3.2 Link LayerPhysical Layer의 바로 윗단에는 Link Layer이 있다. Link Layer은 하드웨어와 소프트웨어의 조합으로 구성되어 있다. 하드웨어 단에서는 높은 컴퓨팅 능력이 요구되는 작업들 (Preamble, Access Address, and Air Protocol framing, CRC generation and verification, Data whitening, Random number generation, AES encryption 등)이 처리되고, 소프트웨어 단에서는 디바이스의 연결 상태를 관리한다. 또한 통신하는데 있어서 디바이스의 Role을 정의하고 이에 따라 변경되는 State를 가지고 있다.RoleMaster : 연결을 시도하고, 연결 후에 전체 connection을 관리하는 역할.Slave : Master의 연결 요청을 받고, Master의 timing 규약을 따르는 역할.Advertiser : Advertising Packet을 보내는 역할.Scanner : Advertising Packet을 Scanning하는 역할. Scanner는 아래와 같은 2가지 Scanning 모드가 있다.Passive Scanning : Scanner는 Advertising Packet을 받고 이에 대해 따로 응답을 보내지 않는다. 따라서 해당 Packet을 보낸 Advertiser는 Scanner가 Packet을 수신했는지에 대해서 알지 못한다.Active Scanning : Advertising Packet을 받은 Scanner는 Advertiser에게 추가적인 데이터를 요구하기 위해 *Scan Request라는 것을 보낸다. 이를 받은 Advertiser는 *Scan Response로 응답한다.Scan Request, Scan Response : Advertising Packet type의 한 종류이다. 앞서, 31bytes 이하의 User data에 대해서는 Advertising Signal Packet에 넣어서 보낼 수 있다고 하였다. 하지만 31bytes보다는 크지만, Commection까지 맺어서 보내기는 오버헤드가 큰 데이터가 있을 때, Scan Request, Scan Response를 이용하면 두 번에 걸쳐서 데이터를 나눠 보낼 수 있게 된다. Advertising Packet을 받은 Scanner는 추가적인 User Data(예를 들어, Peripheral 디바이스의 이름)를 얻기 위해 Scan Request를 보내게 된다. Scan Request를 받은 Advertiser는 나머지 데이터를 Scan Response Signal에 담아서 보낸다.이들은 크게 Connection 전의 역할(Advertiser, Scanner), 후의 역할(Master, Slave)로 분류된다.StateLink Layer는 5가지 State를 가지고 있는데, 각 디바이스는 서로 연결이 되는 과정에서 이 State를 변화시킨다. 다음과 같은 5개의 State가 존재한다.Standby State : Signal Packet을 보내지도, 받지도 않는 상태.Advertising State : Advertising Packet을 보내고, 해당 Advertising Packet에 대한 상대 디바이스의 Response를 받을 수 있고 이에 응답할 수 있는 상태.Scanning State : Advertising Channel에서 Scaning하고 있는 상태.Initiating State : Advertiser의 Connectable Advertising Packet을 받고난 후 Connetion Request를 보내는 상태.Connection State : Connection 이후의 상태.아래 그림은 각각의 State를 Diagram으로 나타낸 것이다.그림7. Link Layer State3.3 Generic Access Profile (GAP)Generic Access Profile (GAP)는 서로 다른 제조사가 만든 BLE 디바이스들끼리 서로 호환되어 통신할 수 있도록 해주는 주춧돌 역할을 한다. 즉, 어떻게 디바이스간에 서로를 인지하고, Data를 Advertising하고, Connection을 맺을지에 대한 프레임워크를 제공한다. 그래서 GAP는 최상위 Control Layer라고도 불린다. Advertising Mode일 때, GAP에서 Advertising Data Payload와 Scan Response Payload를 포함할 수 있다.또한 GAP에서는 BLE 통신을 위해 Role, Mode, Procedure, Security, Additional GAP Data Format 등을 정의한다. 이들은 실제 API와 직접적으로 많은 연관이 있기 때문에 그 내용이 상당히 많지만, 여기서는 BLE Connection과 관련이 있는 Role에 대해서만 알아보겠다.RoleBroadcaster : Link Layer에서 Advertiser 역할에 상응한다. 주기적으로 Advertising Packet을 보낸다. 예를 들면, 온도센서는 온도데이터를 자신과 연결된 디바이스에게 일정주기로 보낸다.Observer : Link Layer에서 Scanner 역할에 상응한다. Broadcaster가 뿌리는 Advertising Packet에서 data를 얻는다. 온도센서로부터 온도데이터를 받아서 디스플레이에 나타내는 테블릿 컴퓨터의 역할이다.Central : Link Layer에서 Master 역할과 상응한다. Central 역할은 다른 디바이스의 Advertising Packet을 듣고 Connection을 시작할 때 시작된다. 좋은 성능의 CPU를 가지고 있는 스마트폰이나, 테블릿 컴퓨터들의 역할이다.Peripheral : Link Layer에서 Slave 역할과 상응한다. Advertising Packet을 보내서 Central 역할의 디바이스가 Connection을 시작할 수 있도록 하게끔 유도한다. 센서기능이 달린 디바이스들의 역할이다.3.4 Generic Attribute Profile (GATT)BLE Data 교환을 관리하는 GATT는 디바이스들이 Data를 발견하고, 읽고, 쓰는 것을 가능하게 하는 기초적인 Data Model과 Procedure를 정의한다. 그래서 GATT는 최상위 Data Layer라고도 불린다. 디바이스간에 low-level에서의 모든 인터렉션을 정의하는 GAP와는 달리, GATT는 오직 Data의 Format 및 전달에 대해서만 처리한다. Connection Mode일 때, GATT Service와 Characteristic을 이용하여 양방향 통신을 하게 된다. Service와 Characteristic에 대한 내용은 여기를 참고하길 바란다.GATT도 Data 처리와 관련해서 다음과 같은 역할을 정의한다.RoleClient : Server에 Data를 요청한다. 하지만 처음에는 Server에 대해서 아는 것이 없기 때문에, Service Discovery라는 것을 수행한다. 이 후, Server에서 전송된 Response, Indication, Notification을 수신할 수 있다.Server : Client에게 Request를 받으면 Response를 보낸다. 또한 Client가 사용할 수 있는 User Data를 생성하고 저장해놓는 역할을 한다.4. Packet TypeBLE 통신에서는 두 가지 종류의 패킷인 Advertising Packet, Data Packet만이 존재한다. Connection을 맺기 전에는 Advertising Packet type, 맺은 후에는 Data Packet type으로 Signal을 생성한다. Data Packet은 하나로 통일되지만, Advertising Packet은 특정 기준에 따라서 다음과 같은 성질들을 갖는다.ConnectabilityConnectable : Scanner가 Connectable Advertising Packet을 받으면, Scanner는 이를 Advertiser가 Connection을 맺고 싶어한다는 신호로 받아들인다. 그러면 Scanner는 Connection Request (이하 CONNECTREQ)를 보낼 수 있다. 해당 Connectable Signal을 보낸 Advertiser는 Scanner가 CONNECTREQ가 아닌 다른 타입의 Signal을 보내면 해당 Packet을 무시하고 다음 Channel로 이동하여 계속 Advertising을 진행한다.Non-Connectable : Non-Connectable Packet을 받은 Scanner는 CONNECT_REQ를 보낼 수 없다. 주로 Connection 목적이 아닌, Data 전달이 목적일 때 쓰인다.ScannabilityScannable : Scanner가 Scannable Advertising Packet을 받으면, Scan Request (이하 SCANREQ)를 보낼수 있다. Scannable Signal을 보낸 디바이스는 Scanner가 SCANREQ가 아닌 다른 타입의 Signal을 보내면 해당 Packet을 무시하고 버린다.Non-Scannable : Non-Scannable Signal을 받은 Scanner는 SCAN_REQ를 보낼 수 없다.DirectabilityDirected : Packet안에 해당 Signal을 보내는 디바이스의 MAC Address와 받는 디바이스의 MAC Address가 들어있다. MAC Address 이외의 데이터는 넣을 수 없다. 모든 Directed Advertising Packet은 Connectable 성질을 갖는다.Undirected : 해당 Signal을 받는 대상이 지정되어 있지 않다. Directed Advertising Packet과는 다르게, 사용자가 원하는 데이터를 넣을 수 있다.위의 내용을 종합하면, Advertising pakcet을 아래와 같이 4가지 type으로 나눌 수 있다.그림6. Advertising Packet Type5. How they really communicate?BLE 통신의 핵심은 ‘timing’이다.Before ConnectionConnection 전, 디바이스는 3개의 Advertising Channel을 이용해서 데이터를 주고 받는다고 했다. 이들은 이 3개의 Channel을 자신만의 time interval로 hopping한다. 서로의 hopping 규칙이 일치하지 않기 때문에 Channel이 서로 엇갈리는 경우가 많을 것이다. 예를 들어, Advertiser는 1번 Channel에 Advertising Packet을 보냈는데, 같은 시간에 Scanner는 3번 Channel에 대해서 Scanning을 하게 되면 데이터 전달이 되지 않는 것이다. 하지만 이러한 hopping이 빠르게 자주 일어나기 때문에, 두 디바이스가 같은 Channel에 대해 Advertising와 Scanning이 발생하는 경우도 많이 생긴다. 이 경우에 서로 데이터를 주고 받을 수 있다.After ConnectionConnection이 되면, Advertising은 종료되고 기기들은 Central, Peripheral 중 하나의 역할을 하게된다. Connection을 개시한 기기가 Central이며, Advertiser가 Peripheral이 된다. 그리고 두 디바이스는 엇갈렸던 hopping 규칙을 통일시킨다. 그렇게 함으로써, 매번 같은 채널로 동시에 hopping하면서 Signal을 주고 받을 수 있게 된다. 이는 둘 간의 Connection이 끊어질 때까지 지속된다.6. How they connect each other?디바이스간의 BLE 연결을 iPhone과 Zikto Walk와의 연결과정으로 설명하면 다음과 같다.1) Zikto Walk가 Advertising Channel을 hopping하면서 Advertising Packet을 보낸다.(Zikto Walk의 Advertising Packet 유형은 ADV_IND이다)2) iPhone Bluetooth를 켠 후, Zikto 앱에 Zikto Walk를 등록한다. iPhone은 Advertising Channel을 hopping하면서 Scan을 하다가 연결하려는 Zikto의 디바이스 이름 등의 추가적인 정보를 얻기위해 SCAN_REQ를 보낸다.3) SCANREQ를 받은 Zikto Walk는 SCANRSP를 보낸다.4) Pairing이 완료되고, Zikto Walk는 다시 Advertising Packet을 다시 일정 주기마다 보낸다.5) iPhone에서 Zikto Walk로부터 걸음 수 등의 Data를 받기 위해 Sync 버튼을 누른다. 이 버튼을 누르면 iPhone은 CONNECT_REQ를 보낸다.6) Zikto와 iPhone은 서로 Acknowledging을 시작하고, timing 정보 등을 동기화 한다.7) Connection이 완료된다.8) Connection이 완료된 후, Service Data, Characteristic Data 등에 대한 Data 교환이 일어난다.9) iPhone과 Zikto Walk간에 Data Sync가 완료되면, Connection이 해제되고, 다시 Advertising Packet을 보낸다. 이를 그림으로 표현하면 아래와 같다.그림6. Advertising Packet Type7. Ubertooth디바이스간 BLE를 이용한 통신 과정에 대해 알고나니, Bluetooth Signal Packet도 Capturing 할 수 있을 거라는 생각이 들었다. 검색을 해 본 결과, 오픈소스 Bluetooth Test tool인 Ubertooth라는 장치로 디바이스간의 BLE 통신을 tracking 할 수 있다는 사실을 알게 되었다. 가격은 100달러로 생각보다 저렴했지만 국내에서는 구매할 수가 없었다. 그렇다고 궁금한 것을 해보지도 않고 포기하는 것은 엔지니어의 마인드가 아니지 않겠는가. 직접 아마존 (www.amazon.com)에서 해외구매를 하였다. 이렇게 바다 건너 멀리서 날아온 Ubertooth를 사용했던 경험을 바탕으로, Ubertooth의 원리와 BLE 통신에 대해서 조금 더 자세히 설명을 해보고자 한다.Ubertooth는 10cm정도의 몸체와 그와 비슷한 길이의 안테나를 가지고 있는 매우 작고 귀여운 모양이다. 이것이 이름하여 Ubertooth!그림8. Ubertooth오픈소스이기 때문에 모든 소스가 공개되어 있고, 소스를 빌드하고 사용하는 방법도 Ubertooth Github 및 Ubertooth Blog에 잘 나와 있어서 사용하기가 수월했다.How it works?Ubertooth는 크게 Bluetooth Classic을 tracking하는 기능과 BLE를 tracking하는 기능으로 나뉘는데, 여기서는 BLE 통신을 tracking 하는 원리에 대해서 다루겠다.BLE는 앞에서 언급했다시피, Connection 전, 후로 통신하는 방법이 다르다. 그리고 위의 내용들을 꼼꼼히 읽은 독자라면 BLE 통신에서 가장 중요하다고 언급했던 timing 이라는 것을 기억할 것이다. timing 은 BLE 통신에서 굉장히 중요한 요소이기 때문에, 보다 더 자세하고 쉽게 설명을 해보겠다.종이컵 전화기를 사용하여 대화를 해야하는 두 사람이 있다. 종이컵 전화기는 총 40개가 놓여져 있다. 이 두 사람은 40개 전화기 중 하나를 사용해서 대화를 주고 받고, 일정시간 뒤에 다음번 전화기를 이용해야 한다. 이러한 커뮤니케이션 방식에서 소통을 하기 위해서는 한 전화기로 얼마만큼의 시간동안 통화를 할 것인지, 다음 전화기는 어떤 전화기를 사용할 것인지, 그리고 어떤 방식으로 자신들의 대화를 다른 사람들의 대화들로부터 구분할 것인지 등에 대해 알아야 할 것이다. 이것들이 위에서 말했던 timing 관련 정보이다.실제 BLE 통신에서 timing 과 관련된 정보들은 다음과 같다 : Access Adress, CRC Info, Hop Interval, Hop Increment (해당 내용들에 대한 자세한 설명은 여기를 참고하기 바란다). BLE 통신을 하는 디바이스들은 이 timing 관련 정보를 동기화하여, Connection이 맺어진 이후에 해당 규칙에 따라 Channel을 hopping하면서 데이터를 주고 받는다. Ubertooth는 바로 이 정보를 알아내어, Master, Slave와 같은 패턴으로 Channel을 hopping하면서 대화를 엿듣는다. 아까 말한 종이컵 전화기에 빗대어 말하면, 제 3자(Ubertooth)가 두 사람이 정한 대화 규칙을 알아내서, 매번 이들이 전화기를 바꿔가며 대화를 할 때 마다 해당 전화기의 대화 내용을 엿듣는 것이다. 굉장히 흥미로운 방법이 아닐 수 없다. 그렇다면 Ubertooth는 어떻게 이 정보를 알아낼까?Before Connection두 디바이스가 연결되기 전, Ubertooth가 timing 관련 정보를 알아내는 방법은 매우 간단하다. Scanner가 Advertiser에게 Connection을 맺기위해 보냈던 CONNECT_REQ을 기억하는가? 공교롭게도 해당 패킷에는 이 네 가지 정보가 전부 들어있다. Ubertooth는 그 정보를 추출해내어 저장해 두고, 그 규칙에 맞게 Channel을 hopping하면서 Signal Data를 전부 엿듣는다.그림9. Ubertooth로 Capture한 CONNECT_REQ packetAfter Connection이미 연결된 디바이스들은 CONNECT_REQ를 보낼 일이 없다. 그러면 Ubertooth는 Connection 이후의 상황에 대해서는 Signal Data를 엿듣지 못하는 것일까? 아니다. Connection 이후의 상황에 대해서 Ubertooth는 다음과 같은 방법을 이용한다.BLE Signal Packet은 Advertise Mode이든 Connection Mode이든간에 무조건 하나의 Signal Packet format만 존재하기 때문에, Packet마다 특정 정보가 존재하는 부분은 어느 Packet에서나 똑같다. 4가지 정보 중 Access Address라는 것은 모든 Signal Packet마다 존재한다. Access Address라는 것은 두 디바이스간의 Unique한 Connection을 나타내는 4bytes 크기의 Identifier로써, CONNECT_REQ를 보내는 디바이스에 의해 랜덤하게 생성된다. Ubertooth는 37개의 Data Channel을 hopping하면서 모든 Data Packet의 Access Address를 추출해내어 Look Up Table 형태로 저장해 놓는다. 그리고는 각각의 Access Address가 등장한 횟수를 세게 되는데, 가장 먼저 특정 횟수만큼 등장한 Access Address를 target으로 잡는다. 나머지 3가지 정보는 각각 추출해내는 방법 및 알고리즘이 따로 존재하는데 해당 내용도 위에 언급한 사이트에 잘 나와있다. 이렇게 해서 네 가지 정보를 알아낸 Ubertooth는 두 디바이스와 같은 패턴으로 Channel을 hopping하면서 Signal Data를 엿듣는다.그림10. Ubertooth로 Capture한 Aceess Address과 나머지 3가지 정보들이렇게 보면, Ubertooth로 모든 것을 할 수 있을 것처럼 보이지만, 몇 가지 한계점이 있기도 하다. Ubertooth가 timing 관련 정보를 얻어내는 과정에 대해 다시 한 번 생각해보길 바란다. 잘 모르겠다면, 직접 Ubertooth 구매하여 테스트를 해보는 것도 엔지니어로써 굉장히 좋은 경험이 될 것이다.8. ConclusionBLE 통신과 이를 tracking하는 Ubertooth에 대해서 알아보았다. 매우 장황한 내용처럼 보이지만 이것도 매우 압축해서 설명한 것이다. 하나하나 디테일하게 쓰기 보다는 BLE를 처음 접하는 사람이 최대한 이해하기 쉽도록 작성하는 것에 초점을 맞추었다. 위의 내용들을 바탕으로, 독자들이 BLE에 더 넒고 깊은 지식을 얻게 되었으면 하는 바램이다. 글을 읽으면서 Bluetooth Classic은 어떻게 통신하는지에 대해 궁금하신 분들도 있을거라 생각한다. 이에 대해서 간단히 언급하자면, Bluetooth Classic 통신 방식은 BLE보다 훨씬 더 복잡하다. BLE에 대해서 어느 정도 알게 되었다면, Bluetooth Classic에 도전해보는 것도 괜찮을 것이다. BLE내용과 관련해서 보충이 필요한 내용이나, 관련 경험 혹은 궁금한 점 등에 대해서 아낌없이 조이와 공유해주길 바란다.9. ReferenceAkiba, “Getting Started with Bluetooth Low Energy: Tools and Techniques for Low-Power Networking”, O’Reilly Media(2015)http://www.slideshare.net/steveyoon77/bluetooth-le-controllerhttp://www.hardcopyworld.com/ngine/aduino/index.php/archives/1132https://www.bluetooth.org/ko-kr/bluetooth-brand/smart-marks-faqshttp://trvoid.blogspot.kr/2013/05/ble.htmlhttp://blog.lacklustre.net/posts/BLEFunWithUbertooth:SniffingBluetoothSmartandCrackingItsCrypto/#조이코퍼레이션 #개발팀 #개발자 #개발환경 #업무환경 #인사이트 #경험공유

안녕하세요. 스타일쉐어에서 서버사이드 개발을 하고있는 김현준입니다. 스타일쉐어의 엔지니어링 블로그의 첫 글에서는 저희 서비스의 스택을 소개하도록 하겠습니다. 사실은 Instagram의 스택과 유사한 면이 많아 글 또한 많이 유사할 것 같네요.서버먼저 스타일쉐어는 서버의 운영 체제로 Ubuntu 12.04 (Precise Pengolin)를 사용합니다. 모든 서버는 아마존 웹 서비스(Amazon Web Services)의 Elastic Compute Cloud(EC2) 위에서 돌아가고 있습니다. 스타일쉐어는 EC2 이외에도 Simple Storage Service(S3)와 같은 AWS의 다양한 서비스를 사용하고 있는데요, AWS를 사용하는 가장 큰 이유는 유연한 확장성(Scalability)이라 말할 수 있을 것 같습니다. EC2의 서버는 모두 가상 머신이기 때문에 관리 콘솔에서의 쉬운 조작으로 서버를 끄고 켤 수 있을 뿐만 아니라, 장애가 생겼을 때도 간편하게 장애가 생긴 서버를 내리고, 새로운 서버로 대체할 수 있는 이점이 있습니다. 이 모든 기능은 API로도 제공되고 있기 때문에, 자동화도 가능합니다. 실제로 스타일쉐어에서도 웹 요청을 처리하는 웹 서버들과 작업을 처리하는 워커들에 대해서 오토-스케일러를 구현해 사용하고 있습니다.로드 밸런싱스타일쉐어의 웹 서버들은 AWS의 Elastic Load Balancing(ELB)에 등록되어 있어서 ELB가 수많은 요청들을 여러 서버들에게 차례로 나누어 보냅니다. 보내어진 요청들은 각각의 서버에서 nginx를 거치며 또 한번 여러 개의 프로세스로 분배되어 처리됩니다.웹 어플리케이션스타일쉐어의 웹 어플리케이션은 Werkzeug 기반의 웹 프레임워크 Flask와 ORM 프레임워크인 SQLAlchemy 위에서 Python으로 구현되어 있습니다.데이터스타일쉐어의 대부분의 데이터는 PostgreSQL에 저장되고 있습니다. 여러 대의 PostgreSQL 인스턴스의 풀링(Pooling)을 하기 위해서 pgpool을 사용합니다. 서비스의 성능 향상을 위한 캐싱 도구로는 Memcached를 사용합니다.스타일쉐어에 올라오는 사진들을 비롯한 대부분의 이미지들은 Key 기반의 스토리지인 AWS S3에 저장하고, 관리합니다. S3의 가장 큰 장점은 사용자가 용량 제한과 파티셔닝에 대해 신경쓰지 않아도 된다는 점일 것입니다. 앞으로도 무한히 많은 사진이 올라올 서비스를 만드는 저희로서는 아주 유용하답니다. 이미지 뿐만 아니라, 서비스를 배포할 때마다 만드는 패키지와 매일매일 데이터베이스 백업 모두 S3에 저장되어 있습니다.작업 관리대부분의 서비스와 마찬가지로, 스타일쉐어도 웹 어플리케이션 서버와 별개로 무거운 작업(Task)을 처리하기 위한 워커(Worker) 서버를 따로 구동하고 있습니다. 여기서 작업이란 계속해서 쏟아지는 웹 요청을 처리하기도 벅찬 웹 어플리케이션에서 처리하기에는 비교적 오래걸리는, 예를 들면 알림(푸시)과 메일을 보내거나, 이미지 프로세싱과 같은 일들을 이야기합니다. 이러한 작업들을 비동기적으로 처리하기 위해 저희는 Celery와 RabbitMQ를 사용합니다. Celery는 Python으로 구현된 비동기 작업 워커이고, RabbitMQ는 워커로 넘길 작업을 관리하는 AMQP 프로토콜 기반의 브로커(Broker) 큐입니다.오픈 소스?스타일쉐어 서버는 비동기 네트웍(asynchronous I/O)을 구현하기 위해서 gevent를 사용합니다. 그 외에 배포(deploy)를 위한 Fabric과 boto나, 내부 문서화를 위해 사용하는 Sphinx 등이 스타일쉐어에서 주로 사용하는 라이브러리/프로젝트 입니다.오픈 소스.위에 적은 것처럼, 스타일쉐어의 구현의 많은 부분이 오픈 소스 프로젝트에 크게 의존하고 있습니다. 훌륭하고 건강한 오픈 소스 생태계 덕분에 우리는 스타일쉐어를 훨씬 더 수월하게 만들고 지탱할 수 있었습니다. 그래서 저희도 도움을 받은 만큼 기여하고, 구성원으로서 더 나은 생태계를 만드려 합니다. 그 중 하나가 바로 이 스타일쉐어 엔지니어링 블로깅 활동이고, 다른 하나가 저희 팀의 오픈 소스 프로젝트 활동입니다. 스타일쉐어 팀의 오픈 소스 활동들은 StyleShare’s GitHub에서 살펴보실 수 있답니다. 여러분들의 관심어린 피드백과 기여도 언제나 감사히 환영합니다.그 외의 도구들스타일쉐어 실 서비스에서 발생하는 오류와 버그를 추적하기 위해 사용하는 Exceptional도 매우 유용합니다. Flask 프레임워크에서 Exceptional 서비스를 쉽게 이용할 수 있도록 도와주는 Flask 확장 모듈인 Flask-Exceptional이 공개되어 있습니다.함께해요저희와 비슷한 환경에서 개발하시는, 같은 도구를 사용하시는, 저희에게 도움을 주고 싶으시거나, 저희에게 (저희가 도와드릴 수 있다면) 도움을 받고 싶으신, 또는 그저 많은 이야기를 나누고 싶은 분들까지 많은 분들과의 소통과 교류가 많았으면 좋겠습니다. IRC를 하시는 분들은 오징어 네트워크(irc.ozinger.org)의 #styleshare-tech 채널로 놀러오세요.#스타일쉐어 #개발 #서버개발 #서버환경 #업무환경 #개발자 #인사이트

Hexlant는 Blockchain 전문 개발 팀으로, 다양한 기관들의 스마트 컨트랙트 코드를 검수하는 업무도 진행하고 있습니다.지금까지 다양한 컨트랙트 코드들을 리뷰하면서 나왔던 문제점들을 공유하고, 더 나은 방법으로 개발 할 수 있는 방법들에 대해 이야기 해보고자 합니다.transferFrom에 대한 이해ERC-20 표준에 보면, transferFrom 이라는 함수가 있습니다. 일반적으로 많이 쓰이는 기능이 아니다 보니 잘 모르고 넘어가는 경우가 많습니다.function transferFrom(address _from, address _to, uint256 _value) public returns(bool)transferFrom은 남이 가지고 있는 토큰을 누군가에게 보내는 기능입니다.그 누군가는 내가 될 수도 있습니다.이 설명만 보면, 아래와 같은 의문이 생기실 겁니다.어? 남의 토큰을 내 마음대로 옮길 수 있다고??당연히 마음대로 옮기면 안되겠죠.그래서 approve 함수를 통해, 내 토큰을 사용할 수 있는 사람을 지정할 수 있습니다function approve(address spender, uint256 _value) public returns(bool)토큰의 holder는 approve함수를 호출하여 spender에게 일정량 만큼을 사용할 수 있게 허용을 해 줍니다. 그럼 spender는 허용된 범위 안에서 토큰을 마음대로 옮길 수 있습니다.허가되지 않은 토큰의 이동많이 쓰지 않는 기능이다 보니, 이 부분에 대해 고려하지 않고 개발 하는 경우가 있을 수 있습니다.아래는 저희가 리뷰했던 코드 중 일부입니다function approve(address _spender, uint256 _value) public returns (bool success) { require(_spender > address(0)); allowed[msg.sender][_spender] = _value; Approval(msg.sender, _spender, _value); return true; }function transferFrom(address _from, address _to, uint256 _value) public { require(_from > address(0)); require(_to > address(0)); require(balances[_from] >= _value); require(balances[_to] + _value > balances[_to]); balances[_from] = balances[_from].sub(_value); balances[_to] = balances[_to].add(_value); Transfer(_from, _to, _value); }approve 함수를 우선적으로 보면, allowed 테이블에, msg.sender가 _spender에게 얼마만큼 토큰사용을 허용해 주었는지 저장하는것 말고는 특별한 기능은 없습니다.allowed[msg.sender][_spender] = _value;이제 transferFrom 함수를 확인해 보겠습니다.transferFrom은 실제 토큰이 전송되는 부분이니 예가 필요할 것같습니다.Alice에게 10000개의 토큰이 있을 때, Bob이 transferFrom을 다음과 같이 호출했다고 합시다.transferFrom(Alice, Bob, 10000)자 이제 transferFrom코드를 따라가며 토큰이 어떻게 전송이 되는지 확인해 봅시다.require는 안에 들어간 조건이 만족해야만 다음 라인을 실행 할 수 있다는 명령어 입니다. require를 만족하지 못하면, 해당 트랙잭션은 수행되지 않고 실패로 처리됩니다.require(_from > address(0)); require(_to > address(0));위의 두 줄의 조건은 입력된 주소_from, _to는 각각 Alice와 Bob의 지갑 주소이기 때문에 0x*****형태로 0x0000…0000이 아니기에 해당 조건들을 모두 만족합니다.require(balances[_from] >= _value); require(balances[_to] + _value > balances[_to]);Alice의 지갑에는 10000개의 토큰이 있고 _value는 10000개이니까 저 require를 실제 숫자로 대입하면require(10000 >= 100000); require(0+10000 > 0);조건을 충분히 만족합니다.그 다음부분들을 실제로 Alice의 주소에서 Bob의주소로 10000개의 토큰을 옮기는 작업입니다.balances[_from] = balances[_from].sub(_value); balances[_to] = balances[_to].add(_value); Transfer(_from, _to, _value);Alice의 잔액에서 10000개만큼이 빠지고,Bob의 잔액에 10000개가 추가됩니다.balances[Alice] = balances[Alice].sub(10000); balances[Bob] = balances[Bob].add(10000); Transfer(Alice, Bob, 10000);이로서 Bob은 Alice의 토큰 10000개를 자신의 지갑으로 이동시켰습니다.일련의 과정을 요약하면1. 주소 오류 검증 2. 보내려는 토큰이 Alice가 가진 잔액보다 작은지 검증 3. 받았을때 Overflow가 발생하는지 체크 4. Alice의 잔액에서 보내는 만큼의 토큰 수량을 뺀다 5. Bob의 잔액에 보내는 만큼의 토큰 수량을 더한다과정을 보면 Bob이 Alice로 부터 토큰 사용을 허락받았는지 체크하는 부분이 없습니다.따라서 누군가가 보유한 토큰을 다른 사람이 제멋대로 쓸수 있게됩니다.오류수정transferFrom이 정상적으로 동작하려면 어떻게 수정되어야 할까요?function transferFrom(address _from, address _to, uint256 _value) public { require(_from > address(0)); require(_to > address(0)); require(balances[_from] >= _value); require(balances[_to] + _value > balances[_to]); require(allowed[_from][msg.sender] >= _value); balances[_from] = balances[_from].sub(_value); balances[_to] = balances[_to].add(_value); allowed[_from][msg.sender] = allowed[_from][msg.sender].sub(_value) Transfer(_from, _to, _value); }첫 번째로는 당연히 transferFrom을 호출한 사람이 권한이 있는지 확인해야 합니다.require(allowed[_from][msg.sender] >= _value);이 조건을 통해 허용된 수량안에서만 토큰을 옮길 수 있게 만들 수 있습니다.두번째는, 토큰을 옮긴 후 허용량을 줄여주어야 합니다.allowed[_from][msg.sender] = allowed[_from][msg.sender].sub(_value)만일 Alice가 Bob에게 10000개의 토큰을 허용해 주고, Bob이 그중 100개를 사용했다면, 그 다음번에 Bob은 9900개 안에서만 사용할 수 있어야 합니다.#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심 #실수담

안녕하세요. 타운컴퍼니 R&D 파트의 백대현입니다.타운컴퍼니는 단체들를 위한 공동구매 플랫폼인 타운어스를 운영하는 스타트업입니다. 기술블로그를 시작하며 최근 오픈한 타운어스 2.0에 대한 소개, 타운컴퍼니 기술조직인 R&D 파트에 대한 소개를 드리려 합니다.타운어스는 대학생들이 학교 내에서 자주 진행하는 공동구매가 굉장히 복잡하고 만족하기 어렵다는 문제를 해결하기 위해 시작되었습니다. 수작업으로 진행하던 공동구매를 플랫폼화 시켜 편하게 공동구매를 진행할 수 있게 만들고, 전국단위로 공동구매를 진행하여 최저가로 구매할 수 있도록 하였습니다.2014년 9월 오픈베타서비스인 캠퍼스샵을 시작하였고 이어서 2015년 6월 정식서비스 타운어스를 런칭하여 2년 넘게 폭발적으로 성장해왔습니다.사실 그 동안 타운어스 사이트에 대한 아쉬움이 많았습니다. 사이트가 초기에 린(Lean)하게 만들어진 이후에 몇차례 업데이트를 거쳐 타운어스 비즈니스를 받쳐주고 있었지만 내부 개발팀의 부재, 인력부족으로 유지보수가 잘 되지 않고 있었습니다. 그 와중에 몇 차례의 비즈니스 전략 변경(Pivot)을 거치면서 기술과 비즈니스의 괴리가 점점 벌어지게 되었습니다.타운어스 신규플랫폼타운컴퍼니에서는 여러 고민을 거쳐 한층 업그레이드 된, 이제 대학생 뿐만 아니라 모든 단체를 위한 공동구매 커머스 플랫폼으로 거듭나고자 타운어스 2.0 프로젝트를 시작하며 기획팀, 디자인팀, 개발팀으로 이루어진 R&D 파트를 출범하고 기술조직을 구성하였습니다.새로 출범한 타운컴퍼니 R&D 파트에서는 물려받은 기존 코드베이스를 유지하며 플랫폼을 개선할 것인지, 부채를 청산하고 새로운 코드베이스를 쌓을 것인지 많은 고민을 했습니다. 결론적으로 새로운 코드베이스로 프로젝트를 진행하기로 하였는데 대표적인 이유는 아래와 같았습니다.타운어스 2.0에서 변경되어야할 기획이 상당히 많아 재설계가 필요함비즈니스적 전략 변경을 서비스에 반영하기 위해 변경해야할 기획이 상당히 많고 그 동안 기술에 반영되지 않은 비즈니스 요구사항이 많아 여려 요구사항이 복합적으로 고려되어야함서비스 아키텍처가 연속성이 없음초기에 MVP로 시작된 코드베이스가 연속적인 기술조직이 발전시키지 못하고 외주 개발과 인력 변경을 거치다 보니 일관적이지 않고 누수가 많음버그 빚더미인력부족으로 인해 그 동안 유지보수가 되지 않아 해결해야할 버그가 복합적으로 존재함 (해결되지 않은 리포팅된 이슈 450여개 OMG)위 외의 여러 이유로 타운컴퍼니 R&D 파트에서는 기술부채 파산을 선택하고, 새로운 코드베이스에서 프로젝트를 시작하기로 하였습니다.신규플랫폼 간략 소개결론적으로 타운어스 신규플랫폼은 전체적인 일정과 인력을 고려하여 우선 부분적으로 오픈하게 되었습니다. 가장 많은 사용자들이 사용하는 단체의류공동구매에 대한 서비스를 먼저 개발하게 되었고 그 외 카테고리의 공동구매는 기존플랫폼에서 서비스하고 있습니다.이렇게 시작한 타운어스 신규플랫폼의 현재 오픈한 변경 사항은 크게 아래와 같습니다.전체적인 UX/UI 업데이트공동구매를 더 편하게 시작하고 진행하고 마무리할 수 있도록 개선“공동구매방”을 친숙하게 사용할 수 있도록 유도하였습니다.단체의류 커스터마이징 기능 강화커스터마이징 의류 종류 확장 : 과잠, 코치자켓, 티셔츠 (점진적으로 확대할 예정)커스터마이징 예상가격 계산 기능편하게 단체의류 디자인을 미리 해볼 수 있는 서비스를 제공합니다.최근 오픈을 시작으로 타운컴퍼니 R&D 파트에서는 지속적으로 서비스를 발전시켜 세상 모든 단체활동을 위한 공동구매, 타운어스에 걸맞는 공동구매 커머스 플랫폼으로 만들어갈 예정입니다.기술 스택과 조직 문화타운컴퍼니 R&D 파트의 기술에 대해서는 꾸준히 소개를 드리려 합니다. 때문에 오늘은 조직 문화와 기술 스택에 대해서 간단하게 소개를 드리겠습니다.프로젝트 진행협업툴로 JIRA, Confluence, Slack을 사용하고 있습니다.프로젝트는 Agile Kanban 방식으로 테스트 주도 개발, 코드 리뷰, 페어프로그래밍을 통해 진행하고 있습니다.서비스에 대한 충분한 고민 이후에 개발을 진행하려 노력합니다.기술 스택Back-End는 Django 1.11 (DRF) 기반으로 개발하며, AWS, MySQL, Vagrant, Docker 같은 기술을 사용하고 있습니다.Front-End는 Angular 5.1을 사용해서 개발하고 있으며 Less, RxJS, Webpack 등의 기술을 사용하고 있습니다.UX/UI에 Sketch와 Zeplin을 주로 사용하고 있습니다.CI(Continuous Integration)로 Travis-CI, 배포 관리로 Fabric과 AWS CLI, 버그 리포팅으로 Sentry.io, 플랫폼 모니터링으로 ELK(ElasticSearch, Logstash, Kibana)를 사용하고 있습니다.지향하는 조직 문화 및 지원자유롭고 주도적인 조직 환경시간에 쫓겨 비루한 코드를 생산하지 않도록유연한 리모트 근무지시가 아니라 스스로 할 일을 찾는 자율 속에서 책임을 다하는 문화자유롭게 의견을 제시할 수 있는 편한 분위기건강한 비판과 토론을 장려하는 커뮤니케이션 문화이상을 추구하되 비즈니스에 기반한이상적인 기획, 디자인, 개발을 지향하지만 비즈니스 영역에 기반한 의사결정회사 모든 조직들이 더 부가가치가 높은 업무에 집중할 수 있는 환경 조성을 위해 노력TOY TIME매주 금요일 4시부터 7시까지 3시간 자유로운 주제로 프로젝트 진행세미나, 컨퍼런스 참가 적극 장려 및 도서 지원저희는 아직 성장하고 있는 만큼 개선할 점도 많고 배워야하는 부분도 많이 있습니다. 그 만큼 기술블로그를 통해 저희가 고민하고 겪었던 기술을 공유하고 소통하며 서로 성장할 수 있는 기회가 되었으면 합니다.잘 부탁드립니다.#타운컴퍼니 #서비스소개 #기업문화 #사내복지 #조직문화 #원격근무 #디지털노마드 #재택근무

지난 시간에 이어 오늘은 챗봇에게 지능을 주는 방법에 대해 알아본다. 공부를 해보시면 아시지만 공부란 어느정도 양이 많아지면 가속이 붙는다는 것을 학창시절에 경험 하셨을 것이다. 즉, 공부를 잘하는 사람은 조금만 해도 더 잘한다. 아무것도 아는게 없는 상황이라면 무조건 머리에 넣는 것도 방법이다. 물론 그 후에는 외운 지식의 의미에 대해 깊은 사고가 필요하지만.  챗봇한테도 이런 사람에 통하는 방식이 그대로 적용된다.지도학습은 규칙이나 사례를 구조화된 형식으로 표현하고 이를 컴퓨터에 입력해 놓는 방식이다. 단점은 한 분야의 지능을 다른 분야에 재사용할 수 없기 때문에 분야별로 다시 개발해야 한다는 데 있다. 아! 주입식 교육의 한계.한편, 자율학습은 인간의 뇌처럼 컴퓨터도 동일하게 데이터간의 연결 상태와 강도로 지식을 보유하도록 하는 방식이다. 이 방식의 대표적인 예가 인공 신경망(Artificial Neural Network)으로 스스로 학습할 수 있다는 점이 가장 큰 장점이다. 대량의 데이터에서 스스로 특징을 추출한다. 최근에는 딥러닝(Deep Learning)이라는 방법을 이용하여 자연어 인식, 영상인식, 음성 인식 등에서 과거엔 손도 못 대던 일을 하고 있다.인공신경망 활용을 위한 두 가지 조건인공신경망의 장점을 살리기 위해선 두 가지 큰 장벽을 넘어야 한다. 첫째는 자율학습 알고리즘을 개발하는 것이다. 둘째는 필요한 양질의 데이터를 대규모로 확보하는 것이다. 인공신경망 개발툴은 구글이나 마이크로소프트 등이 무료로 공개하고 있으므로 데이터 공학자, 프로그래밍 전문가, 응용수학자, 기획자 등과 함께 팀을 구성하면 개발을 시작할 수 있다. 그러나 실제에 있어서 가장 큰 난관은 두 번째로 지적한 대규모 데이터의 확보에 있다. 데이터를 가진 자가 승자라는 말이 있을 정도로 데이터가 중요하지만 이를 확보하는 것은 쉽지 않다. 학습 알고리즘이 있어도 데이터의 질이 떨어지거나 데이터의 수량이 적다면 자율학습이 제대로 될 수 없기 때문이다. 아! 머리에 든게 충분히 있어야 딥러닝이 가능하다.기술력보다는 기획력이 중요한 챗봇챗봇은 텍스트 형식의 글자를 통해 사람과 기계가 소통하는 방법이므로 앞에서 언급한 머신러닝 기술 중 자연어 처리(NLP)와 자연어 인식(NLU)이 필요해진다. 아! 정말 알아야 할 게 많다. 간단히 설명하면 NLP에는 형태소분석, 구문분석이 포함되고 NLU는 여기에 사용자 의도 해석과 실제 상황처리가 필요한 문맥이해까지 포함된다. 누구나 알다시피 조사, 접사 등이 발달한 한국어는 텍스트 처리가 영어에 비해 쉽지 않다고 한다. 로봇한테 사람처럼 말귀를 알아듣게 하는 작업이란 이렇게 어려운 일이다.실무에서의 챗봇 서비스는 기술력도 중요하지만 어떤 컨텐츠를 가지고 어떻게 서비스 할지에 대해 더 고민해야 한다. 역시 대화란 사람에 대한 이해가 중요한 만큼 초기단계에서 좋은 데이터 축적을 위해 규칙기반의 룰을 잘 선정하고 이를 머신러닝 기법과 잘 융합하는 유연성이 필요하다. 또 데이터 크기가 작을 때에는 딥러닝 보다 SVM(Support Vector Machine)류의 머신러닝이 더 좋은 성능을 보인다. 또 오버피팅 문제로 인해 학습 시 많은 데이터 사용이 꼭 성능증가로 이어지지도 않는다. 오히려 도메인 지식과 기획력 및 간단한 세션관리로도 좋은 품질의 챗봇을 만들 수 있다고 본다. 아울러 초기기술을 계속적으로 축적하면서 차근차근 지속적으로 업그레이드 해 나간다면 누구나 그 컨텐츠 영역에서 훌륭한 챗봇 친구를 얻을 것이다.맺는말이상으로 간단하게 챗봇에 대해 지극히 개인적인 의견을 올려봤다. 깊이 들어가면 한이 없는 분야지만 제 4차 산업혁명을 맞이하여 필연적으로 우리와 함께 살아갈 수밖에 없는 스마트폰 안에 있는 로봇인 챗봇에 대해 모든 사람들이 더욱더 관심을 가졌으면 한다.

EOS Smart Contract 를 위한 준비와 토큰 발행 그리고 C++를 활용해 토큰의 간단한 기능을 개발해 보겠습니다.환경 구성 및 지갑 생성은 SAM 님의 아래 2글을 참고해 주시기 바립니다.EOS — 설치 및 실행 (1/2)EOS — 동작구조 및 환경설정(2/2)지갑 생성하기SAM 님의 포스트를 참고 하셨다면 아마 다음과 같이 ‘default’ (별도의 이름을 지정하지 않았을 시) 지갑을 생성 하셨을 겁니다.이 지갑을 사용하여 계정을 Create 한 후 Key 를 Import 하겠습니다.Key 생성하기$ cleos create key위 명령을 실행 하시면 다음과 같은 화면을 얻을 수 있습니다.create key 명령의 결과**주의 : Private Key는 Public Key의 소유를 증명하는 중요한 개념으로 절대 타인에게 노출하면 안됩니다.AdditionalKey 생성 후 지갑에 import 하기 귀찮으시다면 생성된 지갑에서 바로 Key 를 생성하셔도 됩니다.$ cleos wallet create_key위와같이 key가 생성 됩니다. 하지만 public key 만 보이기 때문에 하단 명령 입력 후 지갑 key를 입력하면 private key를 확인할 수 있습니다.$ cleos wallet private_keys지갑에 Key import하기지갑은 Public Key — Private Key를 저장하는 저장소 입니다. 생성된 키를 지갑에 저장하기 위해 다음과 같은 명령어를 입력합니다.$ cleos wallet import-n : 옵션을 사용하면 지갑의 이름을 지정합니다. 지정하지 않는다면 기본 생성된 default 지갑으로 지정됩니다.위 명령을 입력 하면 key 가 임포트 되었다는 결과를 확인 할 수 있습니다.** 만약 지갑을 Unlock 한 상태가 아니라면 ‘private key: Error 3120003: Locked wallet’ Exception 이 나옵니다.unlock 을 위해 다음 명령을 실행한 후 wallet 생성시 저장했던 Key를 입력하여 Unlocked 상태로 만들어 줍니다.$ cleos wallet unlock password: Unlocked: default(Optional) 지갑에 저장된 Key 리스트 확인다음 명령어를 입력하여 지갑에 key 가 잘 import 됐는지 확인합니다.$ cleos wallet keys계정 생성eosio.token 이라는 이름으로 계정을 생성하도록 하겠습니다.** 지갑과 Key 그리고 계정에 관해서는 Hexlant 미디움에 게재될 예정입니다.$ cleos create account eosio eosio.token EOS63kstp8kthzJY3rAotp1LAxUDbWk4MywReG578R2ddbktrDHYKcreator : eosioaccount name : eosio.tokenowner key : 지갑에 import 된 keyAdditional본 포스팅은 local 환경에서 빌드 후 System Contract 들이 적용되지 않은 상황을 가정하였습니다. 만약 Public Network 환경에서 접속 시 eosio 와 eosio.token을 사용할 수 없습니다.또한 계정이름은 다음과 같은 규칙을 따릅니다.- 12문자- 12345abcdefghijklmnopqrstuvwxyz 만 사용 가능** 만약 ‘Error 3090003: provided keys, permissions, and delays do not satisfy declared authorizations’ 에러 발생 시 eosio 에 대한 key 를 지갑에 import 해야 합니다.eosio 에 대한 정보는 다음과 같습니다.public key: EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CVprivate key: 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3위 과정을 모두 마쳤다면, EOS 지갑과 키 그리고 계정에 대한 권한을 모두 가지고 있는 상태가 됩니다. 다음 포스팅에서는 이 계정을 사용 하여 Token 을 발행하는 방법을 알아보도록 하겠습니다.감사합니다#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심

학교에서 배우는 소프트웨어 공학이 왜? 실제 업무에서 사용이 안되는가?그동안 후배들에게 멘토링을 할 때에 가장 많이 받았던 질문 중의  하나이다. 평소에 답변하던 것들을 글로 옮겨 본다.소프트웨어를 전공하는 많은 후배들은 대학생활 4년 동안 배우는 다양한 이론들과 소프트웨어공학들의 수많은 이론을 배운다. 하지만. 대부분의 선배들은 사회생활의 실제 프로그래머로 취업을 한다고 해도, 프로그래밍을 실제 업무에서 하지만, 실제 관련된 이론과 기술. 수많은 가이드라인과 품질 관련 이슈에 대해서 실제 적용하기 어렵거나, 거의 사용하지 않는다고 선배들에게서 이야기를 듣는다.물론, 이 경향은 많이 바뀐 것은 사실이다. 이제 대부분 공학적인 접근법을 사용한다. 하지만, 그럼에도 불구하고 실제 현장에서는 이 현상이 그다지 바뀌지는 않았다.과연 우리가 학창 시절 배우는 그 많은 이론들은 도대체 왜? 만들어졌는데, 실제 사용이 안 되는 이유는 무엇인가? 학창 시절에는 자바나 C와 같은 프로그래밍 스킬만 높이면 되는 것인가? 도대체, 학생 시절 배우는 그 많은 이론과 공학, 품질 관련 이슈들은 실제 업무에서 그렇게 쓸모없는 것이라고 대부분의 선배들이 이야기하는가?실전과 대한민국의 현실. 그리고. 소프트웨어 프로그래밍에 대해서 학생들에게 삽질의 대가가 한마디 하려 한다. 왜? 우리는 학교에서 배우는 이론을 실제 사용할 기회가 없는 것일까?필자는 소프트웨어 공학을 학창 시절 배운 것이 아니다. 오히려, 실제 소프트웨어 개발 활동을 하면서, 공학적인 것이나 소프트웨어의 시각화를 해야만, 소프트웨어의 품질을 관리할 수 있다는 것을 몸으로 느끼고, 이것이 실제 소프트웨어를 상품이나 서비스의 명목으로 사용자들에게 제공하는 경우에 정말 필요하다는 것을 20년의 실제 개발자 생활을 하면서 그 필요성에 대해서 처절하게 느껴왔다.차라리, 필자가 핵심 서비스와 중요한 개발 내용을 직접 코딩하는 개발자의 역할을 할 때에는 이러한 공학적인 것이나, 작은 규모의 소프트웨어를 개발할 때에는 이러한 필요성을 느끼지 못했었다. 대부분의 작은 규모의 소프트웨어를 개발할 때에는 단기적인 일들이 많았다.사용자의 요구사항에 맞추어서 그 시기에 그때에 맞추어서 소프트웨어를 개발하였고, 해당 소프트웨어를 다시 유지 보수한다던가, 다시 수정 작업을 하지 않는 식의 작업을 하는 경우에는 이러한 공학적인 개념이나 그 배경으로 디자인하고 설계한다는 것에 대해서 매우 귀찮게 생각했었다.과거 첫 경험이었던 코볼이나 클리퍼 시절에는 해당 소프트웨어의 규모가 크지도 않았으며, 데이터의 구조 설계 또한 대부분 파일 중심의 데이터였었고, 화면의 구조 또한 수십 개를 넘지 않는 정도의 규모였다.오히려, 고속의 인덱스를 걸기 위한 테이블 접근법이나, 고속으로 화면에 출력하는 방법. 데이터를 조금 더 빠르게 구성하는 방법들에 집중할 시기에는 굳이 플로우 차트를 왜? 그리는 것이며, 파일 구조에 대해서 디자인해야 하는지에 대해서 의아함을 똑같이 가지고 있었으며, 굳이 설계나 디자인 없이 바로 코딩과 개발을 하던 시절이었다.하지만, 대규모 시스템을 주로 구사하는 웹서비스의 시대에 있어서, 단순한 로그 정보하나를 시리얼라이즈화시키는 것만 봐도 그 사람의 수준을 파악할 수 있고, 텍스트 중심의 구성 설계를 보면 향후 시스템의 성능에 대해서도 예측이 되는 경험을 축적하게 되면, 가장 중요한 것은 역시... 공학적인 접근법이다.필자가 소프트웨어 공학의 첫 번째 개념에 대해서 눈을 뜨고, 그 필요성을 절감하던 첫 번째가 바로, 고객에게 제공되는 소프트웨어가 지속적인 유지보수성을 가지기 시작할 때에 그 필요성을 처음으로 인지하기 시작하였다.처음의 요구사항이 변화되면서 사용자의 업무 흐름이 소프트웨어의 구조와 데이터베이스의 구조를 계속 변화하여 나가고, 이러한 상황을 미리 설계된 자료를 통해서 예측하거나, 소프트웨어 아키텍처적인 관점으로 조금 더 세밀한 환경에 대해서 메모가 되어있고, 그 구성에 대해서 서술해두었다면, 상당히 고속 개발을 하고, 소프트웨어 품질을 향상시키는데 매우 중요한 첫 번째 개발 행위가 되었을 것이라고 느꼈었다.또한, 개발자가 수십, 수백 명 단위로 소프트웨어의 설계가 대단위로 변화하고, 그 개발 품질에 대한 통제와, 적정한 수준의 개발 수준을 형성하게 하는 방법에 대해서 고민할 때에도 똑같이 이러한 소프트웨어 개발의 시각화에 대해서 인지하기 시작한 것이다.당시에는 공학적인 개념 없이 유사한 방법이나 표현방법을 고안하였으나, 관련된 내용을 찾아보고, 전문가들에게 조언을 구해보니, 상당 부분 그 부분에 대해서 전문가들 간의 협의가 있었고, 그 표준화되는 시각화 방법들과 방법론들이 매우 많이  연구되었다는 것을 알게 되었다.필자는 오히려, 이러한 개발과정에 있어서 필요한 것들을 개발하다가, 공학적인 베이스나 방법론들이 어떻게 실제 개발에 사용되어야 효과적인가에 대해서 실전에서 터득하고, 실전에 배치되는 것에 대해서 이해를 넓혔다.또한, 미국에서 개발되어진 개발 방법론이 국내의 실정이나 환경에 적합하지  않은다는 것을 깨닫고, 그러한 부분들을 어떻게 지식을 바꾸어야 하며, 실제 실천해야  하는지에 대해서 아키텍트 포럼이나 모임에서 역설하기 시작하였고, 그 부분을 실제 개발에 접목하려 애써왔다.그리고, 그 경험을 중심으로 소프트웨어 아키텍팅과 관련된 경험을 늘려왔고, 모바일과 웹서비스를 중심으로 하는 기업에서 개발 총괄을 하는 경우에는 그동안 축적한 소프트웨어 개발의 경험을 바탕으로 소프트웨어 형상관리 SCM(Software Configuration Management)을 중심으로 이슈관리, 개발, 테스트, 배포의 단계를 자동화하는 소프트웨어 개발의 비주얼라이제이션을 어떻게 실현할 것인가에 대해서 고민하고, 그 환경을 보다 쉽게 전파할 수 있는 공정과 형태를 미국 중심의 CMMI체계와 국내의 SP의 기준을 배경으로 상당 부분 고민하고 있다.그런데, 가끔 만나는 후배들이나 이제 막 개발자의 생활을 시작하려는 친구들에게서 많이 받은 질문 중의 대표적인 질문이 ‘도대체, 학교에서 배우는 소프트웨어 공학은 언제 사용하나요?’, ‘도대체, 대학 4년 동안 배우는 그 많은 이론들은 언제쯤 사용할 수 있는 것일까요?라는 질문들을  그동안 수십 번, 수백 번 받아왔다.심지어, 소프트웨어 개발 생활을 몇 년정도 한 후배들에게서 마저도 듣게 되니, 이 부분에 대해서 한 번쯤은 글로 남겨 두어야 하겠다고 생각하였다.과거, ‘서울 행복 직업박람회’에서  질문받은 내용은 이러했다.그 당시 필자에게 찾아온 대학생이 질문한 내용은 매우 간단하지만, 매우 어려운 답변일 수 있었다. 그것은, ‘왜 대학교 때 배우는 이론이나 원론과 같은 기본적인 내용들이 실제 사회생활 나가면 필요 없다고 자기의 선배들이 이야기하는 것일까요?. 실제. 취업하면 정말 그런가요?’이 질문은 이번 이야기의 주제이며, 필자가 20년을 넘게 소프트웨어 개발자 생활을 하면서 받아온 질문 중에 가장 빈도수가 높은 질문이라고 하겠다. 필자가 자부해온 삽질의 대가라는 점에서 그 친구는 그 친구는 정말 그 이야기를 잘 해줄 사람을 찾아온 것이라고 생각하면서 다음과 같이 설명했다.결과론적으로 '필요하지만, 필요없는 곳도 있다. 하지만, 가능한 필요한 곳을 찾아봐라.'라는 식의 이야기를 해주었다.자, 그렇다면. 필자가 이런 선문답 식의 답변을 하게 된 내용을 하나씩 풀어서 설명해보자. 도대체, 대한민국의 소프트웨어 개발을 하는 곳에서 왜? '소프트웨어 공학'적인 개념이나 이론들이 사용이 안되고 있는 것일까?물론, 정답은 간단할 수 있다. 국내의 대부분의 소프트웨어 개발회사의 경우에는 소프트웨어 공학쯤은 없어도, 아무런 문제(?) 없이 소프트웨어 개발이 가능한 경우이다.실제, 그런 회사도 그런 개발 조직도 상당히 많다는 것을 필자는 경험으로 알게 되었다. 그렇다면, 그렇게 소프트웨어 공학쯤은 필요 없는 기업이나 개발 조직은 어떤 곳들일까? 그곳들부터 알아보자.개발 총괄 책임자의 대우가 형편없는 회사필자는 개발자의 생활을 시작하는 어린 친구들이 첫 번째 직장을 가지는 곳에 대한 선택에 대해서 조언을 해왔을 때에 가장 먼저 해주는 조언은 이것이다. 면접을 보려는 회사의 개발 총괄 책임자나 리더에 대한 대우와 회사 내에서의 위치를 먼저 살펴보라는 것이다.대부분 대우가 형편없거나, 매일 야근과 반복된 개발 일정의 반복이 계속되는 회사의 경우에는 그 대우가 형편없는 것 이상으로 개발의 공정이나 개발의 방법이 정형화되어있지 못할 가능성이 매우 높다.물론, 소프트웨어 개발이 시각화가 되면, 요구사항의 변동폭이 보이게 되고, 해당 정량적인 지수가 도출되므로, 해당 부분에 대해서 대응이 가능하지만, 개발 총괄 책임자의 지위가 낮거나 대우가 형편없다는 이유는 다음의 두 가지의 경우에 해당이 된다.하나. 공학적인 방법이나 정형화된 방법을 제안하는데, 회사의 최고책임자가 인정하지 않는 경우이다.이 경우에는, 보통은. 제대로 알고 있는 소프트웨어 개발자들은  해당되는 조직을 빠르게 떠나고, 별로 기대할 수 없다는 것에 대해서 자괴감이나 패배감과 같은 분위기가 개발 조직 내에 흐른다는 것을 곧 감지할 수 있을 것이다.둘. 실제 이러한 공학적인 방법 따위의 개발 방법론으로 통제할 수 없는 고객이 '슈퍼갑'인 경우이다.실제, 소프트웨어 개발 활동을 해당 '슈퍼갑'에서 영업적인 능력으로 얻어낸 경우의 회사의 경우에는 아무리, 옳은 이야기, 옳은 방법론으로 대응한다고 해도, 개발 막판에 개발의 방향성 자체를 손 뒤집듯이 바꿔버리는 상황이 빈번한 경우이다.대부분 이런 경우에는 소프트웨어 개발 총괄 책임자가 오히려, 공학적인 것을 알고 있거나, 똑똑한 사람이라면 멘붕에 빠지거나, 자괴감에 빠져서,  대충대충 소프트웨어 개발을 하거나, 자기가 먼저 자리를 뜨는 경우가 대부분이다. ( 버티는 사람은 몰라서 버틸 수 있다고 설명하는 것이 더 바람직하겠다. )물론, 이 경우에도 그런 것을 당연시하면서, 공학적인 개념도 모르는 리더가 고객과 같이 동조하는 경우가 오히려, 업무가 수월해지는 경우가 많은 것 또한 현실이다. 고객과 개발 책임자가 같이 '닭짓'을 하는데, 개발 조직이 온전할 리 없다. 공학 따위는 집어치우고, 프로세스나 정량화된 목표, 자동화된 방법과 같은 소프트웨어 품질은 그냥, '책'에만 나오는 단어이며, 개념일 뿐이다.실제, 똑똑하고 말 잘하고, 올바른 방향으로 이끄는 리더가 이 조직에 리더가 된다고 하더라도. 어쩔 수 없이, 버티지 못하고, 떠나게 되는 것을 흔히 보게 된다.그리고, 이러한 조직에 있는 대부분의 개발자들은 '소프트웨어 공학'따위의 '장난'은 실제 개발이 필요 없다고 역설하고, 이것을 당연하게 여긴다. 보통, 이렇게 만들어지는 소프트웨어의 품질은 보장할 수 없고, 이 보장할 수 없는 소프트웨어를 통해서, '슈퍼갑'에서 꾸준한 유지보수 비용과 일거리가 발생하는 방법은.. 아마도, '4대 강'처럼. 한번 만들어 두면, 끊임없는 유지보수 업무를 발생시키는 식의 문제 정의와 처리방법이라고 할 수 있겠다.당연한 것이지만, 결론적으로 이야기하자면, 이런 개발 조직에서 개발 총괄 책임자의 대우는 형편없고, 일정 조절이나 개발에 대해서 지휘할 수 있는 권리나 인사권 같은 것도 매우 부족한 상황으로 변화한다.그래서, 이런 회사일 수록, 소프트웨어 공학은 그냥, 뜬구름 잡는 이야기가 되는 경우가 일상다반사이다.실제, 소프트웨어 개발을 하지 않는 회사소프트웨어 개발 조직이 있지만, 실제 소프트웨어는 개발하지 않고, 심지어. 소프트웨어 유지보수마저도 관련 업체에 일임하거나 위임하는 경우의 조직이 해당되는 경우이다. 대부분의 슈퍼갑인 회사와, 어설프게 소프트웨어를 개발하는 기업들의 전산실에  해당하는 곳이 이런 환경에 해당된다.이 경우 소프트웨어의 공학적인 배경이나, 개발에 대한 스킬과 협조보다는, 일반 회사의 기획과 경영, 회계와 관리에  해당하는 업무들이 가장 중요하므로, 소프트웨어 개발의 시각화나 공정에 대해서는 그다지 관심이 없는 경우이다. 오히려, 제품을 선택하고, 유지보수 업체를 어떻게 관리하고 운용할 것이냐에 핵심과 초점이 있기 때문에, 소프트웨어 공학적인 배경은 가장 중요한 선택의 포인트가 되지 못한다.오히려, 투입 대비 효과에 대한 경영학적인 관점의 스킬과 개념이 더욱더 중요하다고 하겠다. 필자는 개인적으로 대부분의 대학에서 이러한 관점으로 교육을 하지 않는 것에 대해서 매우  불만족스럽다.분명, 소프트웨어 개발과 소프트웨어를 개발, 유지보수, 운영 및 관리한다는 것은 매우 연관성이 높기 때문에, 이와 관련된 과정이나 소통방법, 그리고. 윤리체계와 운영방법 등에 대해서도 충분하게 소프트웨어 관련학과에서 교육이 필요하다고 생각한다.이러한 회사에 입사하게 되는 개발자의 경우에는 소프트웨어 개발자가 된다기 보다는, 소프트웨어 개발과 운영을 관리하는 회사를 관리하는 업무를 더욱더 많이 배우고 경험하게 되므로, 소프트웨어 개발공학 따위의 뜬구름 잡는 이야기는 경력이 쌓여갈수록 더더욱 필요 없게 된다.사장이 직접 개발하는 소규모 개발회사이러한 경우도 몇 가지의 사례로 나눌 수 있지만, 대부분의 구성 형태는 정말 비슷해지는 점이 매우 특이하다. 그것은, 소프트웨어 개발회사에 있어서 개발 총괄 책임을 '사장님'이 직접 통제를 하는 경우이고, 실제, 중요한 코딩도 '사장님'께서 직접 하는 경우이다.이 경우에는 '소프트웨어 공학'적인 콘셉트보다는, '사장님'의 경험적인 바탕에 의해서 소프트웨어 개발의 시각화가 만들어지고, '사장님'의 지극히 개인적인 경험과 지식의 배 경위에서 '정량적'지수들이 결정되는 경우이다.이 경우에는 '사장님'의 스킬이 높은 파트의 경우에는 매우 느슨할 수도, 매우 강하게 조일 수 있고, 사장님의 경험이 부족하거나 어색한 지식을 가진 파트의 경우에는 매우 불완전하고, 매번 변경된다는 것을 개발 조직 전체가 느낄 수 있다.이러한 조직의 특성은 상당 부분 필요한 소프트웨어 품질을 유지하고 있기는 하지만, 특정 버그나 특정 형태, 특정 상황에 대해서는 포기하는 경우가 많다는 점이다. 또한, 개발 조직의 구성역시 특정한 방향으로 구성되어진 기형적인 개발 조직이 만들어진다는 것이다.물론, 이 방향이 완전히 틀린 것이 아니라는 점 또한 매우 중요한다. 해당 업무나 설루션, 패키지에 적합한 방향에 대해서 '사장님'의 경험에 의해서 구축되었기 때문에, 특정 공학적인 지식을 가지고 있거나, 개발의 경험이 풍부한 사람이 해당 조직에 들어와서 보기에는 매우 어색한 점이나, 매우 이상한 형태를 느끼게 된다.대부분 이러한 소프트웨어 개발 조직은 보통, 수년 이상 설루션이나 서비스를 진행해오고 있고, 특정한 형태로 발전되어 있고, 적당한 개발자들이나 서비스 운영조직과 내재화된 자체들의 경험들이 중첩되어 있어서, 정말 세밀하게 분석하고, 환경을 조절하기에는 정말 어려운 환경으로 진화된 경우가 많다.대부분, 급여와 업무, 직원들의 잦은 이탈과 특정 개발 조직에 대한 '사장님'의 편애가 눈에 뜨일 정도로 보이는 경우가 많다. 그것은, 해당 소프트웨어와 서비스가 그 환경에 가장 적합한 구조를 가지고 있기 때문에 발생하는 경우이기 때문에, 냉정하게 분석해보면, 그 조직의 형태가 매우 적합한 구조인 경우가 많다.그래서, 이러한 조직에 들어가는 경우에는 '이론적'인 소프트웨어 공학은 잠시 뒤로하고, '경험적으로 구축되어진 개발 프로세스'에 익숙해져야만 그 조직과 프로세스를 이해할 수 있게 된다. 이러한 회사의 경우에는 필요한 경험과 지식에 대해서 매우 제한적이기는 하지만, 나름대로의 규칙과 개발 철학, 향후. 발전방향에 대해서 어느 정도 구축하고, 이를 따라서 개발 조직을 운영하고 있다는 점이기 때문에, 어설픈 개발공학적인 개념으로 이러한 환경을 이해한다는 것은 매우 어려울 것이다.초보 개발자들의 경우에는 이러한 개발 조직에서 수년 이상을 지내야만, 이러한 방법을 이해하는 경우가 대부분이다. 그래서, 초기에는 '공학'따위는 없다고 푸념하거나, 필요 없다고 이야기하는 경우이다.소프트웨어 공학은 해당 개발 조직과 개발자들의 수준, 축적된 시각화 방법들을 종합화하여 보이는 활동이기 때문에, 이러한 개발 조직은 이러한 정착된 패턴에 대해서 한 번쯤은 시각화를 위한 종합진단과, 형태에 대해서 정립하고 자신들만의 개발 문화를 선언하는 방법을 택하는 것이 좋다. 그래서, 공학적인 방법에 대해서 고민하고, 품질에 대해서 조금은 더 발전적인 방법으로 진화할 수 있게 하는 방법이 될 것이다.하여간, 잘 모르는 사람들에게는 이러한 개발 조직은 매우 이상하게 보인다. 단, 이 조건에 가장 적합한 회사의 경우는 '적당한 수익을 시장에서 얻고 있으며, 그 시장에 맞추어 개발 조직과 문화가 발전한 회사의 경우'를 의미하는 경우이다.당연한 것이겠지만, 이러한 환경으로 '시장'에서는 버티기 매우 어려울 것이고, 곧 망할 가능성이 높은 경우이다. 물론, 영업적은 능력으로 개발 조직이나 회사가 운영되고 있다면, 자연스럽게, '개발 총괄 책임자의 대우가 형편없는 기업'으로 변화되기 때문이다.특정 개발 조직이 관습화 된 인사권을 행사하는 경우보통은 이러한 회사를 게임회사에서 잘 찾아볼 수 있다. 특정 서버의 기술이나 클라이언트의 개발팀에서 사람을  구인하는 데 있어서, 일반적인 구인의 방법보다는 인맥이나, 특정 방법에 의해서 인력을 수급하는 경우이다.이 경우에 중요한 개발 공정이나 프로세스와 개발경험들은 내부의 팀에서 내부의 팀원들을 통해서만 서로 간에 운영되는 형태이며, 보통은 게임회사나 특정 하드웨어 기술을 가진 업체들에게서 이러한 환경들이 빈번하게 나타난다.한편으로는 이러한 방법이 개발 조직 내에서의 테두리가 제한되기는 하지만, 어느 정도 회사가 성장하거나, 회사의 규모 이상이 되지 않는다면, 그렇게 문제가 되지 않는 경우가 된다. 필자의 경험에 의하면 매출 1조 원을 넘기는 기업이 되는 경우의 하드웨어 업체이거나, 매출 1천억을 넘기는 소프트웨어 기업의 경우에 이러한 개발 조직의 문화가 가장 큰 걸림돌이 되는 경우를 많이 보아왔다.이런 경우에 대부분의 중심 개발 조직이 아닌 조직에서는 자신들이 공정을 변화시키거나 제품의 중요 기능을 다룰 수 없고, 반복적인 유지보수나 무의미한 행위들이 연속되는 경우를 계속 경험하게 되므로, 소프트웨어 공학에 대해서 많은 의아심을 가지게 되는 경우이다.이상의 몇 가지 기업의 형태를 살펴보면서 필자가 알게 된 것은 소프트웨어 개발의 형식은 역시 무형식이며, 그 상황과 형태에 따라서 변화되고 진화한다는 것이다. 또한, 위에서 이야기한 몇 가지의 경우의 공통점은 바로, ‘소프트웨어의 품질’이 그다지 중요하지 않은 기업의 경우에 해당한다고 이야기할 수 있다.위에서 언급한 회사들의 공통점은 ‘소프트웨어의 품질’ 때문에 개발 조직을 변화시키거나, 개발 문화에 대해서 고민할 필요가 없는 회사라는 점이다. 당연한 것이겠지만, 소프트웨어 공학은 ‘뜬구름 잡는 이야기’를 하는 학창 시절 때에나 이야기한다고 이야기를 하는 선배들을 대부분 만날 것이다.대한민국에서 만날 수 있는 대부분의 소프트웨어 개발 활동들은 소프트웨어의 품질이 그다지 중요하지 않은 경우가 참 많다는 것이다.일단, 가동을 시작한 서비스가 죽게 되면 크게 문제가 되는 경우이거나, 해당되는 소프트웨어가 작은 문제로 인해서, 실제 비즈니스와 업무에 크게 문제가 되는 경우가 아니라면, 소프트웨어의 품질에 대해서는 그 중요성이 떨어지게 되는 것이 당연하다.충분한 소프트웨어 가치를 인정받을 수 있는 평가와 방향성에 대해서 충분하게 고민하고 있지 않은, 회사이거나 소프트웨어 개발 조직의 경우에는 당연한 것이겠지만, ‘소프트웨어 공학’은 그다지 중요하지 않다는 것이 결론이라고 하겠다.소프트웨어 품질이 정말 필요한 곳인가?이렇게 답변을 정의할 수 있다.소프트웨어 품질이 중요한 가치를 가지는 곳에서는 충분하게 소프트웨어 공학적인 이론과 배경이 가장 중요한 것이 될 것이다. 필자가 아는 어느 회사의 경우에는 소프트웨어의 기본적인 행위하나 가 실제 큰 비용으로 계산되는 경우가 있었다.단순한 하나의 물류이지만, 어떤 물류를 크레인을 사용하여 한 번 잘못 이동하게 되고, 해당되는 물품이 전혀 엉뚱한 나라에 가있거나, 해당 물품이 적재되고 내려지는 과정이 중첩되면서 만들어지는 비용을 단 한번 행위의 가치로 평가하였을 때에 1번 펑션이 1억 원 정도의 비용으로 계산되는 경우라면, 소프트웨어 개발의 펑션이나 개발 프로세스에 대해서 얼마나 고수준으로 설계하고 평가될 것인가에 대해서 생각해보면 될 것이다.이미, 은행에서 자금이 이체되고, 움직이는 과정에 대해서도 개별적인 가치에 대해서 평가를 할 수 있을 것이다. 과연, 내가 만드는 소프트웨어의 기본가치는 어떻게 되는 것일까? 에 대해서 생각해보면, 우리가 만드는 소프트웨어에 얼마나 고품질이 필요한 것인가에 대해서 설명할 수 있을 것이다. 그렇지만, 필자는 이렇게 이야기하겠다.슬프지만, 대한민국의 IT 중에서 소프트웨어 개발 분야에 있어서, 정말 고품질이나 고성능을 요하는 수준으로 요구하는 곳이 거의 없기 때문에 이러한 문제는 계속 발생할 것이며, 계속 이러한 질문은 만들어질 것이다.대부분의 학생 시절에 우리가 배우는 기본과 이론들은 쉽게 설명해서 죽지 않는 서버와 데몬을 만들고, 가능한 정해진 규칙 하에서는 다운되지 않는 웹서비스를 만들려고 그런 기본과 이론을 배운다.하지만, 대부분의 서비스들은 죽으면, 서버의 데몬 프로세스를 죽였다가, 다시 동작하면 되는 수준의 업무면 충분한 경우가 대부분이다. 더군다나, 외국에서 만들어진 프레임웍이나 만들어진 소프트웨어 위에서 동작되는 소프트웨어를 만드는 환경에서라면, 이러한 공학이나 이론 따위야 그다지 중요한 것이 아니게 될 것이 아니라는 점이다. ( 그 책임은 비싸게 구매한 DBMS나 프레임웍이 해결해야할 책임이라고 떠넘긴다. )결론적으로 마지막 이야기를 한다면, 과연 이러한 소프트웨어 가치를 충분하게 만들어 낼 수 있는 소프트웨어 개발 활동을 내가 하고 있는가에 대해서 고민해보자. 그리고, 그러한 행위를 할 수 있고, 발전 가능성이 있는 곳이야말로, 이러한 고수준의 품질활동이 필요한 곳이 될 것이다.그리고, 이러한 고수준의 소프트웨어 품질활동이 필요한 곳은, 바로. 아직은 단 한 번도 이러한 소프트웨어나 서비스가 만들어지지 않은 곳에서 이러한 활동이 더 많이 필요하다. 그것은 바로, 스타트업이나 이제 서비스를 개시하려는 곳일수록, 적절한 소프트웨어 품질활동이나 시각화가 필요하다고 이야기할 수 있겠다.소프트웨어 활동을  시각화한다는 것은 결론적으로 소프트웨어 개발자가 투입하는 행위에 대한 가치에 대해서 얼마나 고수준으로 끌어올린 것이며, 어느 정도 적절한 품질 수준을 고려할 것인가에 대한 활동을 의미한다.그러므로, 현재 스타트업을 꿈꾸고 있거나, 적적할 소프트웨어의 개발비용을 고민하고 있는 곳이라면, 소프트웨어 공학은 매우 중요한 활동이나 방향성에 대해서 정답에 근접하도록 도움을 줄 것이다. 소프트웨어 고품질의 세계와 소프트웨어 공학의 세계는 소프트웨어 개발자들이 어떤 생각을 하고, 개발에 참여하느냐에 따라서 결정되어진다. 그 선택은 역시, 각자가 하는 것이다.