안녕하세요 "사운들리"입니다 :)오늘은 사운들리의 코드 품질 관리에 대해 이야기 해보려 합니다.몇몇 개발자에게는 지루하고 악몽같은 이야기일 수 있겠네요.제 경우에는 예전에는 이런 품질이라는 단어를 멀리했지만 결국 제가 작성한 코드에 발목을 많이 잡히다 보니, 자연스레 관심을 갖게 되었습니다.일단, 어떤 소프트웨어가 좋은 품질의 소프트웨어일까요?좋은 품질이란? 책에 나올법한 내용을 보면, 아래와 같은 항목을 토대로 소프트웨어 품질을 판단한다고 합니다.ISO/IEC 9126 : Software engineering - Product qualityFunctionality: 명시된 요구사항을 잘 충족했는지Reliability: 명시된 조건과 시간 아래에서 일정 성능을 유지 하는지Usability: 사용하기 위해 어느정도의 노력과 자원이 필요한지Efficiency: 소모 자원과 성능간의 효율Maintainability: 수정하기 위해 어느정도의 노력이 필요한지Portability: 다른 환경에서도 사용 할수 있는지출처: https://en.wikipedia.org/wiki/ISO/IEC_9126 뭔가 복잡해 보이지만, 결국 개발자라면 위의 항목은 누구나 추구하게 되는 가치라고 생각 합니다.그런데 말입니다. 이런 좋은 내용을 마음 속으로만 간직한 채 코드를 작성하면 정말 좋은 소프트웨어를 만들 수 있을까요? 저는 객관적인 방법으로 코드를 평가한다면 좋은 피드백이 될 것이라고 생각합니다. (물론 이 성적표를 남에게 보여주는 것과는 다른 문제에요 ㅎㅎ)어떻게 품질을 체크하는가 소프트웨어의 품질을 체크하는 데에 다양한 방법과 툴이 제시되고 있는데요, 저는 크게 두 가지로 분류 해보겠습니다.유저 입장의 품질: 유저의 요구사항에 맞는 소프트웨어인지 체크개발자 입장의 품질: 내가 지금 이 코드를 의도한 대로 잘 작성하고 있는지 체크 유저 입장의 품질은 언급하지 않아도 중요함을 누구나 알고 있습니다. 이 부분이 만족이 되지 않으면 제품이 아니죠! 그래서 저는 개발자 입장에서 스스로 챙길수 있는 품질을 사운들리는 어떻게 챙겨보고 있는 지 이야기 해보도록 하겠습니다. 실은 제가 개발자 입니다 ㅎㅎ사운들리 개발자의 코드는 아래와 같이 흘러갑니다.<그림1> 사운들리 코드 개발상의 품질 관리 순서도간단히 각 항목을 훑어 보겠습니다.Local Machine 각자 갖고 있는 맥북으로, 다양한 IDE를 사용해 코딩합니다. 그리고 git 을 이용해 commit 하고, github 에 push 하죠.Github push 된 수정사항은 pull request 를 통해 동료에게 알려집니다. 이후 코드리뷰를 통해 merge 하게 됩니다. 코드리뷰는 많은 사람들에 의해 그 중요성이 부각되고 있습니다. 사운들리는 같은 모듈을 만드는 개발자끼리, 그리고 다른 모듈에 영향을 주는 코드일 경우에는 해당 모듈의 개발자도 리뷰를 합니다. 코드리뷰를 통해 다른 사람이 어떤 기능을 작성했는지 보고, 오류도 찾고, 더 좋은 방법이 있으면 공유도 하고, 칭찬도 하고, 훈수도 두고 합니다. 참고로 사운들리는 git-flow 정책에 따라 git branch를 운영하고 있습니다.Jenkins  Github 에 commit 이 등록되면 Jenkins 는 자동으로 빌드를 시작 합니다. Jenkins 는 단순 빌드 성공 실패를 떠나서, 코드 품질에 대한 몇가지 report 를 발생 시킵니다. 아래에서 좀더 자세히 다뤄보겠습니다.SonarQube Jenkins 에서 빌드하면서 SonarQube 에 포함된 분석 기능을 사용하게 됩니다.그렇다면, 코드 품질의 지표는 무엇일까요?Jenkins가 발생시키는 레포트를 통해서 알 수 있는 내용은 아래와 같습니다.코딩 스타일 체크 결과: 작성된 코드가 미리 정의된 코딩 스타일에 맞게 작성되어 있는지?Unit Test 결과: 유닛 테스트 결과 (당연히 전부 pass 해야겠죠)Test code coverage 결과: 테스트 코드가 전체 코드의 몇 % 를 커버 하고 있는지 (우리의 최종목표는.. 60%.. 덜덜덜)정적 분석 결과: 코드를 실행하지는 않지만, 코드 그 자체에서 발생할 수 있는 결함을 찾아줍니다. 이 네 가지 레포트는 객관적 수치를 나타내주기 때문에 일종의 코드 품질 지표로 삼을 수 있습니다. 물론 이 지표만 잘 관리 했다고 해서 좋은 코드를 작성했다고 말할 수는 없습니다. 다만 좋은 코드를 작성하기 위한 기초 중의 기초라고 볼 수 있겠죠 :)품질 체크를 위한 툴(tool)은 개발 언어에 따라 다를 수 있습니다. 사운들리에서는 다양한 언어로 소프트웨어가 작성되어 있습니다. 따라서 언어마다 위의 결과를 얻기 위해서 서로 다른 툴을 사용하고 있습니다. AndroidJavaJavascriptC/C++코딩 스타일checkstylecheckstyle jshintcppcheckUnit testjunitjunitmochagoogletestCode coveragejacococoberturamocha-covgcov정적 분석sonarqubesonarqube sonarqubecppcheck 각 개발자는 위의 네 가지 결과를 얻기 위해서 빌드 시스템에 툴을 포함하여 개발하고 있습니다. 제가 주로 개발하고 있는 java 언어에 해당하는 툴들을 좀 더 자세히 살펴보겠습니다.checkstyle코딩 스타일을 체크 해줍니다. xml 파일로 미리 정의 되어있고요. 매번 빌드할때마다 스타일이 틀린것을 지적해 줍니다.코딩 스타일은 중요합니다. 같이 개발하는 개발자와 코딩 스타일이 같다면 마치 내가 작성한 코드처럼 쉽게 읽을 수 있죠.junitjunit 은 자바 유닛 테스트 프레임워크 입니다. 유닛 테스트 코드를 편하게 작성하게 해주고, 쉽게 테스트 결과를 볼 수 있습니다.유닛 테스트 코드를 작성하면 내가 작성한 모듈을 작은 단위로 테스트 해서, 작은 로직에서 발생하는 시시콜콜한 문제를 방지 할 수 있습니다. 테스트 코드를 작성해서 검증한 부분은 스스로도 신뢰가 갑니다.기능 수정간에 유닛 테스트에서 fail 이 나는 경우가 발생하는데, 모르는 사이에 다른 모듈에 영향을 준 것을 알게 됩니다. 다른 모듈에 모르고 영향을 주게 되면 뒷처리가 어려워지잖아요~coberturacode coverage 를 계산해 주는 툴입니다.유닛 테스트 코드가 실행되면, 작성된 코드의 각 부분을 실행하게 됩니다. cobertura 는 이때 각 코드의 어느부분이 실행되었는지 확인해서 통계를 내줍니다.주로 line coverage / branch coverage 두 지표를 보는데요, line coverage 는 해당 라인이 한번이라도 실행 되면 check 되고, branch coverage 는 각 라인에 있는 조건문을 다 따로 check 합니다. 당연히 branch coverage 를 달성하는게 어렵겠죠?sonarqube소나큐브는 다양한 plug-in 을 통해서 정적 분석을 하고, 시각화를 해주는 툴입니다.사운들리는 주로 정적 분석 용도로만 소나큐브를 사용하고 있습니다. (지원하는 plug-in 을 보면 젠킨스와 기능이 겹치는 부분이 있습니다.)정적분석으로 실제 문제가 되는 부분을 찾는 경우도 있고, minor 한 부분에 대한 지적을 하는 경우도 있습니다. 그러나 이런 minor 한 부분도 꼼꼼하게 잘 챙겨야 좋은 개발자가 된다고 믿고 있습니다.마치며 여기까지 사운들리의 코드 품질 관리에 대해 이야기 해보았습니다. 품질 관리를 해보신 분은 아시겠지만, 이런 툴을 쓰다보면 항상 행복하게 코드 품질을 관리할 수는 없습니다. 매달 세워놓은 목표를 달성하기 위해서 뼈를 깎는 노력으로 테스트 코드를 작성해야 되고, 당장 기능 수정해서 배포해야 되는데, 작성해 둔 테스트 케이스가 Fail 되어 말썽을 부릴 수도 있습니다. 그렇지만 객관적 기준으로 코드 품질을 관리하다보면 어느샌가 큰 노력없이 좋은 코드를 작성하는 개발자가 되지 않을까 생각해 봅니다. 코드 졸면서 막 짜도 style warning 0건/ 정적분석 오류없음 / 테스트 코드 기본 탑재 뭐 이런 개발자 말입니다 ㅎㅎ 다른 개발자분들은 어떻게 자신이 작성한 코드의 품질을 관리하고 있는지 궁금하네요.알고 계신 좋은 방법이 있다면 언제든지 공유 부탁드리겠습니다~!#사운들리 #개발자 #개발 #인사이트 #조언 #개발후기 #후기

2018년에도 그랬듯이 우리는 항상 시간이 부족합니다. 많은 시간을 들여 높은 수준의 성과를 만들어 내야 하지만, 그 성과를 이루기 위해 필요한 학습에는 충분한 시간을 할애할 수 없습니다. 우리의 현장은 학교가 아니니까요!2019년 업무에 앱 어트리뷰션이 골치거리가 될 것 같다면 지금 이 글이 도움이 될 것입니다. 북마크 해놓고 틈틈이 읽어보세요. 어트리뷰션의 기본적인 개념, 전체적인 흐름, 각 부분이 연결되어 동작하는 매커니즘을 습득할 수 있습니다. 그리고 더 깊이 있는 학습이 필요하다면, 각 챕터 마지막에 있는 ‘+ 더 알아보기’를 참고해 보세요.1. 시작 – 광고 클릭위와 같은 광고를 클릭하면 랜딩 페이지로 이동하게 됩니다. 거의 대부분 플레이 스토어 또는 앱스토어로 이동하게 될 것입니다. 그런데 어트리뷰션이 가능하기 위해서는 이런 광고들에 조금 특별한 URL이 세팅되어 있는데 이것을 ‘트래킹 URL’ 또는 ‘트래킹 링크’ 등으로 부릅니다.http://ads.wisetracker.co.kr/wa/wiseAdw.do?_wtno=502&_wthst=trk.wisetracker.co.kr&_wts=P1535606238444&_wtc=C1535606305460&_wtm=C0000013&_wtaffid={wff_id}&_wtbffid={wffsub_id}&_wtcid={clk_id}&_wtgpid={GAID}&_wtidfa={IDFA}&_wtdl=http://www.wisetracker.co.kr&_wtp=2트래킹 URL은 위 예시처럼 길고 심란하게 생겼습니다. URL을 봐도 이해가 되지 않으니 긴 설명은 하지 않겠지만 이것만은 꼭 기억해 주세요. 유저가 광고를 클릭하면 1)유저에 대한 정보를 URL에 싣고서, 2)URL이 바라보고 있는 트래킹 서버로 연결됩니다.+ 트래킹 URL 자세히 알아보기2. 경유 – 정보 수집광고를 클릭하면 스토어로 즉시 이동하는 것이 아닙니다. URL이 가리키는 트래커 서버를 잠깐 스치고 스토어로 이동합니다. 트래커 서버를 스치는 그 잠깐의 순간에, 트래커는 URL에 실려있는 정보들을 수집한 다음 유저를 스토어로 리다이렉트 시킵니다.만약 광고에 트래킹 URL이 없다면? 트래커 서버를 스쳐갈 일도 없으니 아무런 정보도 수집되지 않고, 결과적으로 어트리뷰션이 불가능하겠지요.3. 스토어 – 앱 다운로드광고를 클릭한 유저의 단말기가 Android 라면 플레이 스토어, iOS 라면 앱 스토어에 랜딩되어 앱을 다운로드 하게 됩니다. 더 이상 설명할 것이 없으니 넘어가시죠.4. 앱 실행 – 2차 정보 수집드디어 다운로드된 앱이 처음으로 실행 되었습니다. 앱이 실행되면 앱에 미리 삽입되어 있던 분석 SDK도 함께 실행되면서 분석 기능을 수행합니다. 분석한 정보는 트래커 서버로 전송하지요. 여기에서 중요한 사실은 앱이 실행 되어야만 분석이 동작한다는 점입니다. 분석 SDK는 앱과 한 몸입니다. 앱이 실행되어야 분석 SDK도 실행되면서 기능을 시작할 수 있습니다. 따라서 단말기에 다운로드 되었지만 실행되지 않은 앱은 분석도 불가능합니다.5. 어트리뷰션 & 포스트백위의 모든 과정을 거치며 트래커 서버에는 두 종류의 데이터가 수집되어 쌓이게 됩니다. ‘2. 경유’ 단계에서 수집한 데이터와 ‘4. 앱 실행’ 단계의 데이터가 그것입니다. 트래커는 이 두 데이터를 대조합니다. 광고를 클릭한 유저와 앱을 실행한 유저가 동일한지를 살펴보는 것입니다.두 데이터가 일치한다면 광고를 통해 1 건의 설치가 발생했다는 것으로 판단합니다. 이 판단 행위를 ‘인스톨 어트리뷰션’이라고 부를 수 있겠네요. 1건의 어트리뷰션이 이뤄지기 위해서 앞의 과정들이 필요하다는 것을 이해할 필요가 있습니다.이렇게 어트리뷰트 된 데이터를 광고 매체로 보내는 것을 포스트백이라고 합니다. 예를 들어 어트리뷰션 결과 ‘ABC’라는 매체를 통해서 인스톨이 발생했다면, 트래커는 해당 매체에게 ‘ABC 광고를 통해서 인스톨 1건 발생’했다는 것을 포스트백 합니다. 이렇게 되면 ‘ABC’ 매체는 포스트백 데이터를 근거로 비용을 청구할 수 있고, 광고 효율을 최적화 할 수 있습니다.+ 어트리뷰션 메소드 더 알아보기+ 포스트백 더 알아보기다음 글에서는 웹 환경에서 집행하는 CPC 키워드 광고를 통한 앱 유입 분석에 대한 내용을 다뤄보겠습니다.

디자이너는 대단하다.디자이너가 대단한 이유는 매우 탁월한 능력을 가지고 있기 때문이다. 디자이너 스스로도 그 역량을 잘 인식하지 못하기 때문에 타인들에게 잘 어필하지 못하기도 하지만, 이 능력은 분명 무시무시한 역량이다. (스스로 잘 인식하지 못한다는 의미는 누구나 디자이너처럼 그 능력을 가지고 있다고 믿기 때문일지도 모른다)그 탁월한 능력이란생각을 언어와 이미지로 동시에 구체화할 수 있다는 것이다.언어와 이미지로 동시에 생각할 수 있다는 것은 추상적 개념의 단계에서 구체적 구상의 단계로 넘어가는 과정을 동시에 프로세싱 할 수 있다는 것이다. 뿐만 아니라 머리속 상상을 세상이 인식할 수 방식으로 민첩하게 표현할 수 있기 때문이기도 하다.이 능력을 갖지 못한 사람들은 그것이 어떤 파워를 가질 수 있는지 상상하지 못한다. 그렇기 때문에 디자이너가 다른 이들에게 그 위상이나 가치를 쉽게 인정받지 못하는 것이다. 그 능력을 상상하지 못하기 때문에 인정받기도 힘들다는 의미이다.이런 확신은 아주 최근에 더 강해졌다.디자이너로의 경험을 바탕으로 브랜드 영역의 업무를 하다보니, 브랜드의 컨셉을 text로 정리하는 업무와 text를 비주얼로 표현하는 업무에 상당한 프로세스가 존재한다는 것을 알게 되었다. 업계에 verbal의 영역과 visual의 영역을 담당하는 전문 분야가 당연히 나눠져 있겠지만, 그 간극은 꽤 멀다. 멀기 때문에 복잡해지고, 갭이 존재할 수 밖에 없고, 커뮤니케이션의 오류가 생길 수밖에 없다.만일 이 두 가지를 동시에 할 수 있다면, 그것은 대단한 힘을 가질 것이다. 마치 시나리오를 쓰는 작가가 직접 영화를 연출하거나, 작곡을 하는 뮤지션이 직접 노래를 부르는 것과 같은 '의도와 표현의 일치 효과'를 보여줄 수 있다.인간의 언어는 세상을 표현하기엔 너무나 낮은 해상도를 가지고 있다. 동일한 언어를 각기 달리 해석하는 이유도 그 때문이다. A라는 사람이 특정 의도로 정리된 verbal을 B라는 누군가가 시각적으로 표현한다면 당연히 자의적인 해석이 개입될 수밖에 없으며, 초기의 생각과 다른 방향으로 표현됨으로써 오류가 발생될 수 밖에 없다. 기획자가 디자이너와 갈등하는 이유이기도 하다.좋은 디자이너란, 특정 생각(컨셉)을 verbal의 낮은 해상도 단계를 거치지 않고 곧바로 현실 세계에 표현할 수 있는 능력 때문에 존중되어야 한다. 그리고 그 능력 때문에 조직에서 복잡한 프로세스를 현격히 줄일 수 있다. 때문에 디자이너의 아이디어가 올바른 방향이라면 이 능력은 조직에서 엄청난 생산성과 창의적 결과를 발휘한다. 디자이너가 CEO 역할을 하는 배달의 민족이나 에어비앤비가 그런 예시가 될 수 있을 것이다.하지만,왜 그런 일들이 빈번히 일어나지 않을까?곳곳에서 역량을 발휘하는 디자이너들이 늘상 자신의 능력과 재능을 인정받지 못하고, 조직 내에서 늘상 을의 입장에 놓여야만 하는가? 감각이 뛰어난 디자이너조차 조직에서는 크게 다르지 않다. 디자이너라면 공감할 것이다.왜 그럴까?이유는 이미 앞에서 언급되어 있다.디자이너가 아닌 사람들이 이미지를 구체화하기 어렵듯이 디자이너는 이미지를 언어로 표현하는데 어려움을 겪는다. 혼자서 일하지 않는 한 타인과 생각을 공유해야 하는데, 이미지라는 포맷으로만으로는 다양한 전문가들을 일일이 상대하지 못한다. 때문에 디자이너의 verbal 표현 능력이 매우 중요하다. 조직에서 일하기 위해서는 말이다.그동안 내가 경험했던 훌륭한 디자이너들은 뛰어난 감각과 자신의 생각을 매력적으로 표현하는 능력을 동시에 가지고 있었다. 그들은 예외없이 뛰어난 프레젠테이션 능력을 가지고 있다. 화려한 언변이 아니라, 매력적인 단어 선택 능력과 핵심을 끄집어내는 표현 능력을 가지고 있다. 낮은 해상도의 언어를 통해서이지만 전체를 이해할 수 있게 표현한다.디자이너는 verbal 표현 능력을 키워야 한다. 꾸준히 훈련해야 한다. 그것도 감각이다. 그걸 통해서 반쪽짜리 디자이너에서 벗어나야 한다.특히 조직에서 제대로 인정받기 위해서는 verbal 커뮤니케이션 능력을 월등히 키워야 한다. 생각을 글로 표현하고, 함축적 언어로 기술할 수 있어야 한다.그럼 점점 주위에서 자신을 인정하기 시작할 것이다. 인정받지 못하는 것은 당신의 언어가 아니라 타인이 인식할 수 있는 언어로 표현하지 못했기 때문이다.그 덕분에 주변의 조직이 디자이너의 창의적 아이디어를 꽃 피울 수 있기를 기대한다. 또한 덕분에 디자이너들이 조직에서  점점 더 주체적으로 일할 수 있기를, 그리고 없어서는 안될 사람으로 인정받을 수 있기를 기대한다.아깝지 않은가?그 탁월한 능력이....

"한 사람의 삶에서 무엇이 영향을 미쳤고, 어떻게 시간을 보내며 살아가고 있을까? "집에 방문해보면 그 사람이 어떤 사람인지 더 깊이 알 수 있다."궁금해서 여행 다녀오겠습니다" 누군가의 책장을 살펴보면 관심분야와 생각을 알 수 있고, 가지고 있는 물건들을 보면 취미나 취향을 알 수 있다. 그렇게 한 사람을 좀 더 잘 파악할 수 있게 된다. 그렇다면 사람들, 인류 전체 역사에서 무엇이 중요한 영향을 미쳤고, 사람들(인류)은 어떻게 시간을 보내며 살아가고 있을까? 앞으로 우리는 어떻게 살게 될까?  이 질문에 대한 답을 찾으려면 사람들이 살고 있는 곳을 방문해야했다. 사람들이 살고 있는 도시에 가서, 역사와 흔적을 찾아보면 사람들(인류)을 더 잘 파악할 수 있을거라 믿었다. 그렇게 나의 500일에 걸친 도시 관찰 일기가 시작됐다.Prologue : 관찰 여행의 시작 사실 대학 입학 후, 나의 목표는 졸업 전까지 5대양 6대주를 다 보는 것이었다. 국제적인 이벤트에 지원받아서 참가할 수 있는 기회를 계속 찾고, 방학이 되면 해외로 나가기 위해 학기 중에 돈을 모았고, 그렇게 남미, 북미, 유럽, 중동, 동남아, 동북아를 하나하나 여행해 나갔다. 본격적으로 관찰 여행을 시작하게 된 것은 졸업 후 회사를 다니면서다. 언젠가는 창업을 하리라 라는 마음이 있었기에 스타트업에 계속 관심을 가지고 있었고 아이폰이 세상에 등장한 이후, 실리콘밸리에 대해 궁금증은 커져갔다. 그래서 회사를 다니는 동안, 휴가를 활용하여 세계적인 스타트업 허브들을 방문하기로 마음먹은 것이 첫 번째 관찰 여행의 시작이었다. 가서 어떻게 더 많은 것을 얻어올 수 있을까 라는 고민을 하면서 본격적으로 나만의 글로벌 탐방 여행을 기획하기 시작했다. 미국의 실리콘밸리, 이스라엘의 텔아비브 (이스라엘은 미국 나스닥(한국 코스닥에 해당)에 가장 많은 기업을 상장시켰다), 중국의 선전, 싱가폴 등 주요 도시를 목표로 기획서를 작성하고 차례로 방문하기 시작했다. 처음 실리콘밸리에 갈 때는 매일매일의 점심, 저녁 시간에 인터뷰 약속을 잡아놓고 출발했다. 인터뷰를 하면서 meetup을 통해 현지 event 에 참가하는 방법을 배웠고, 기회가 닿아 회사에도 방문하게 되었다. 그렇게 점점 기획하는 능력이 개선되어서, 텔아비브 방문 시에는 개인 인터뷰뿐만 아니라, meetup 등 현지 이벤트 참가, 기업 방문(startup, 대기업, VC, 엑셀러레이터) 등을 조합하여 기획해서 다니게 되었다. 결과적으로 이렇게 다닌 여행은 기존의 여행과는 다른 경험이 되었다. 다녀와서 생각이 달라지기도 했고, 세계의 흐름을 조금 더 이해할 수 있었다.To be Continued 

시뮬레이션은 실제로 실행하기 어려운 실험을 간단히 행하는 모의실험을 뜻하며, 특히 컴퓨터를 이용하여 모의실험을 할 때는 컴퓨터 시뮬레이션이라고 일컬어집니다.  시뮬레이션은 특수한 하드웨어를 사용하는 3D 가상현실이나 비행 시뮬레이션 등 다양한 분야에 사용되고 있으며, 이벤트 중심의 로그를 다루는 프로세스 마이닝에서는 이산 사건 시뮬레이션을 중심으로 연구가 이뤄지고 있습니다.이산사건(discrete event) 시뮬레이션은 시간이 경과함에 따라 시뮬레이션 이 진행되는 것이 아니라 시스템 외부 혹은 내부에서 사건이 발생했을 때만 모델을 실행시킵니다. 이산사건 시뮬레이션에서 사건이란 시스템의 외부 혹은 내부에서 발생하는 추상적인 신호를 말하며, 이산 사건이란 임의의 시각에 불규칙으로 일어나는 사건을 의미합니다.이산 사건 시뮬레이션 모델을 잘 만들기 위해서는 사건 시간과 사건에 대한 정확한 기술이 필요한 데, 이를 위해 프로세스 마이닝이 사용될 수 있습니다.[그림] 프로세스 마이닝 기반의 시뮬레이션 모델 도출 (Discovering Simulation Model, Rozinat et a l., 2009)이것은 기존에 시뮬레이션 모델링이 현실 세계에서의 관찰 및 수작업에 의해 이뤄졌다면, 좀 더 쉽고 정확한 모델링을 위해서는 데이터 기반의 AS-IS 프로세스 파악에 능한 프로세스 마이닝을 사용해 볼 수 있지 않을까 하는 의문에서 출발합니다.아래 표와 같이 프로세스 마이닝과 시뮬레이션은 AS-IS 모델과 TO-BE 모델 각각의 영역에서 서로 보완하는 역할을 담당하고 있습니다. [표] 프로세스 마이닝과 시뮬레이션 단계별 역할 비교단계프로세스 마이닝 (AS-IS)시뮬레이션 (TO-BE)프로세스 설계프로세스 마이닝을 통해 도출한 실제 프로세스 모델을 바탕으로 프로세스 (재)설계다양한 대안 모델에 대한 검증 수행구현 및 실행구현하고자 하는 프로세스 모델의 표준 모델 준수 여부 확인시뮬레이션을 통해 테스트 및 검증 완료된 프로세스 모델 구현모니터링 및 분석표준 모델 준수 모니터링 및 병목 지점, 재작업 구간 분석시뮬레이션을 통한 병목 개선 구간 및 자원 수요 예측, 작업 시간 효율화 효과 분석 이러한 연구들을 바탕으로 최근에는 생산 공정 내 작업 현황 파악 및 성과 측정을 위해 생산 시스템의 이벤트 로그를 저장하고 분석하여, 제조 공정에 대한 시뮬레이션 모델 요소를 도출하려는 연구가 진행되고 있습니다. 이를 통해 프로세스 마이닝에서 찾은 병목 구간 등 문제점을 바탕으로 어떻게 개선할 것인지, 프로세스 변경 혹은 개선이 어떤 결과로 이어질지 What-if 분석을 통해 의사 결정을 위한 예측 방법이 제공되고 있습니다. 시뮬레이션 수행의 결과로 많은 수행 결과가 출력되며, 좀 더 나아가 사건과 이벤트에 대한 상세 기록들이 로그 데이터 형태로 나올 수 있습니다. 시뮬레이션이 가상 현실이라는 관점에서 현실에 대한 프로세스 마이닝 분석은 가상 현실에 대해 마찬가지로 유효합니다. 실제로 시뮬레이션 모델링을 하고 나서 시뮬레이션 모델링이 현실을 반영할 수 있도록 잘 되었는지 검증할 필요가 있는데, 시뮬레이션 로그에 대한 프로세스 마이닝 분석을 통해 해당 프로세스 모델을 도출할 수 있습니다.  얻어진 모델을 현실 세계에서 얻어진 프로세스 모델과 동일한 기준에서 비교하고 이에 대한 차이를 다시 시뮬레이션 모델이 반영하는 순환적 구조를 통해 좀 더 정확한 시뮬레이션 모델을 얻게 됩니다.  [참고 문헌]https://en.wikipedia.org/wiki/Simulation#퍼즐데이터 #개발팀 #개발자 #개발후기 #인사이트

* 이 글은 Next.js의 공식 튜토리얼을 번역한 글입니다.** 오역 및 오탈자가 있을 수 있습니다. 발견하시면 제보해주세요!목차1편: 시작하기  - 현재 글2편: 페이지 이동3편: 공유 컴포넌트4편: 동적 페이지5편: 라우트 마스킹6편: 서버 사이드7편: 데이터 가져오기8편: 컴포넌트 스타일링9편: 배포하기개요요즘은 싱글 페이지 JavaScript 애플리케이션을 구현하는게 꽤 어려운 작업이라는 것을 대부분 알고 있습니다. 다행히도 간단하고 빠르게 애플리케이션들을 구현할 수 있도록 도와주는 몇 가지 프로젝트들이 있습니다.Create React App이 아주 좋은 예시입니다.그렇지만 여전히 적당한 애플리케이션을 구현하기까지의 러닝 커브는 높습니다. 클라이언트 사이드 라우팅과 페이지 레이아웃 등을 배워야하기 때문입니다. 만약 더 빠른 페이지 로드를 하기위해 서버 사이드 렌더링을 수행하고 싶다면 더 어려워집니다.그래서 우리는 간단하지만 자유롭게 설정할 수 있는 무언가가 필요합니다.어떻게 PHP로 웹 애플리케이션을 만드는지 떠올려봅시다. 몇 개의 파일들을 만들고, PHP 코드를 작성한 다음 간단히 배포합니다. 라우팅에 대해 걱정하지 않아도 됩니다. 그리고 이 애플리케이션은 기본적으로 서버에서 렌더링됩니다.이것이 바로 우리가 Next.js에서 수행해주는 일입니다. PHP 대신에 JavaScript와 React를 사용하여 애플리케이션을 구현합니다. Next.js가 제공하는 유용한 기능들은 다음과 같습니다:기본적으로 서버 사이드에서 렌더링을 해줍니다.더 빠르게 페이지를 불러오기 위해 자동으로 코드 스플릿을 해줍니다.페이지 기반의 간단한 클라이언트 사이드 라우팅을 제공합니다.Hot Module Replacement(HMR)을 지원하는 Webpack 기반의 개발 환경을 제공합니다.Express나 다른 Node.js HTTP 서버를 구현할 수 있습니다.사용하고 있는 Babel과 Webpack 설정을 원하는 대로 설정할 수 있습니다.설치하기Next.js는 Windows, Mac, Linux와 같은 환경에서 동작합니다. Next.js 애플리케이션을 빌드하기 위해서는 Node.js가 설치되어 있어야 합니다.그 외에도 코드를 작성하기 위한 텍스트 에디터와 몇 개의 명령어들을 호출하기 위한 터미널 애플리케이션이 필요합니다.Windows 환경이라면 PowerShell을 사용해보세요.Next.js는 모든 셀과 터미널에서 동작하지만 튜토리얼에서는 몇 개의 특정한 UNIX 명령어를 사용합니다.더 쉽게 튜토리얼을 따르기 위해서는 PowerShell 사용을 추천합니다.맨 먼저 다음 명령어를 실행시켜 간단한 프로젝트를 생성하세요:$ mkdir hello-next$ cd hello-next$ npm init -y$ npm install --save react react-dom next$ mkdir pages그런 다음 hello-next 디렉토리에 있는 "package.json" 파일을 열고 다음과 같은 NPM 스크립트를 추가해주세요.이제 모든 준비가 끝났습니다. 개발 서버를 실행시키기 위해 다음 명령어를 실행시키세요:$ npm run dev명령어가 실행되었다면 브라우저에서 http://localhost:3000 페이지를 여세요.스크린에 보이는 출력값은 무엇인가요?- Error No Page Found- 404 - This page could not be found- Hello Next.js- Hello World404 Page다음과 같은 404 페이지가 보일 것입니다.첫 번째 페이지 생성하기첫 번째 페이지를 생성해봅시다.pages/index.js 파일을 생성하고 다음의 내용을 추가해주세요:이제 http://localhost:3000 페이지를 다시 열면 "Hello Next.js" 글자가 있는 페이지가 보일 것입니다.pages/index.js 모듈에서 간단한 React 컴포넌트를 export 했습니다. 여러분도 React 컴포넌트를 작성하고 export 할 수 있습니다.React 컴포넌트가 default export 인지 확인하세요.이번에는 인덱스 페이지에서 문법 에러를 발생시켜봅시다. 다음은 그 예입니다: (간단하게HTML 태그를 삭제하였습니다.)http://localhost:3000 페이지에 로드된 애플리케이션은 어떻게 되었나요?- 아무일도 일어나지 않는다- 페이지를 찾을 수 없다는 에러가 발생한다- 문법 에러가 발생한다- 500 - Internal Error가 발생한다에러 다루기기본적으로 Next.js는 이런 에러들을 추적하고 브라우저에 표시해주므로 에러들을 빨리 발견하고 고칠 수 있습니다.문제를 해결하면 전체 페이지를 다시 로드하지 않고 그 페이지가 즉시 표시됩니다. Next.js에서 기본적으로 지원되는 웹팩의 hot module replacement 기능을 사용하여 이 작업을 수행합니다.You are Awesome첫 번째 Next.js 애플리케이션을 구현하였습니다! 어떠신가요? 마음에 드신다면 더 많이 배워봅시다.마음에 들지 않는다면 우리에게 알려주세요. Github 저장소의 issue나 Slack의 #next 채널에서 이야기 할 수 있습니다.#트레바리 #개발자 #안드로이드 #앱개발 #Next.js #백엔드 #인사이트 #경험공유

뭐 그렇습니다. 항상 모든 일은 빨리 하는 게 좋죠. 너에게도 좋고 회사에게도 좋습니다. 나에게만 안좋죠. 이걸 빨리 쳐낸다고 집에 빨리 가는 것도 아니니. ASAP는 As soon as possible 의 약자입니다. '가능한 빨리' 라는 오더입니다. 사실 이 만큼 애매모호한 오더가 또 있을까요? 가능한 빨리. 란 말을 분석해보면 아래와 같습니다.가능한 = 내가 생각하는 시간안에빨리 = 내놔라그렇군요.  ASAP는 '내가 원할 때 내놔라' 라는 뜻이었습니다. 문제는 "니가 언제 원하냐" 는 겁니다. 게다가 보통은 내놓으라는 게 한 두개가 아니죠. 대부분 모든 것이 ASAP로 처리되므로 실무자 입장에선 도대체 모드 한날한시에 끝내라는 건지 아니면 뭐부터 먼저하란 건지 고구맙니다.ASAP는 '내가 원할 때 내놔라' 목이 강하게 막혀오고 명치가 답답해진다고 '뭐 부터 처리할까요?' 라고 되물으면, '일단 급한 것부터 해' 라는 더욱 난해한 대답이 돌아오지요. 아니 그러니까 일단 급한 게 뭐냐고. 우리는 무료 고구마를 안고 자리에 돌아와 머리카락의 윤기를 손가락사이로 느끼곤 합니다.물론 그 정도는 실무자인 니가 센스껏 알아서 해야하는 거 아니냐? 라고 할 수 있습니다. 사실 일정부분 그걸 스스로 정하는 것도 중요하긴 하지요. 실제로 실무자중에선 본인이 일을 못해서 어버버 하는 경우도 꽤나 있습니다. 이에 대해 스티븐 코비 박사는 '성공하는 사람들의 7가지 법칙'에서 중요도의 우선순위를 분류하는 방법을 제시했습니다.네, 이렇게 생긴 것이죠. 사실 뭔지 읽을 필요는 없습니다. 대부분의 리더쉽 강의에선 이와 같은 사분면 매트릭스로 일의 우선순위를 정해서 챡챡 하라고 감동적으로 알려주지요. 큰 돌 먼저 넣고 자갈을 넣기도 하고, 막 뻔한데 그럴싸한 퍼포먼스로 한 떨기 끄덕거림을 자아내기도 합니다. 저 매트릭스는 이론적으로 전혀 틀리지 않았습니다. 매우 정석적이고 저리 하는 게 옳죠. 근데 문제는 이겁니다. 근데 나 혼자만 저리하고 있음 뭐합니까? 내가 중요하다고 생각하는 것과 상사가 중요하다고 생각하는 부분이 다른데.  이론적으로 2사분면이 최우선입니다만, 그냥 쫄리거나 외부압박이 있거나, 돈이 더 크거나, 친분관계가 있거나, 그냥 내 판단에 의해서 4사분면을 먼저 하라는 오더를 받을 때도 있습니다. 사실 그런 경우가 더 많죠. 우리는 매우 의아하고 내 업무스케쥴이 몽땅 꼬이는 것을 느낍니다. 이렇게 담배세와 주류세를 성실히 납부하는 시민이 되었습니다.소주는 트럼펫처럼 뿌우뿌우우 후우우 휘오오오오그러니 오늘은 ASAP는 언제까지 해야하는 것이며, 여러개의 ASAP가 있을 땐 어떻게 판단해야 하는 지 알아보도록 합시다. 물론 도움이 될 지 안될 지는 스스로 판단하실 수 있으리라 생각됩니다.ASAP는 언제까지 하는걸까?1. 오늘이 월요일 점심 이후 라면 수요일까지 입니다.2. 오늘이 화요일이라면 수요일까지 입니다.3. 오늘이 수요일이라면 금요일 오전 입니다.4. 오늘이 목요일이라면 금요일 오전까지 입니다.5. 오늘이 금요일이라면 토요일 오후까지입니다.(응?)6. 오늘이 토요일이라면 토요일까지 입니다.7. 오늘이 일요일이라면 월요일 오전까지 입니다.8. 오늘이 월요일 오전이라면 점심 전까지입니다.보통 큰 건의 경우엔 위와 같습니다. 수요일이 기준이 되는 이유는 심리적으로다가 뭔가 컨펌을 해서, 다른 일을 진행하기에 충분한 분기점이기 때문이죠. 그래서 대부분 팀장이나 대표들은 수요일을 기점으로 다 됐어? 라고 물어보는 경우가 많습니다. 그래야 수요일날 수정을 하던 컨펌을 하던 해서 다른 오더를 내리니까요. 그리고 그 오더는 금요일까지 주로 진행되죠. 대신 오전중에 컨펌이 나야 오후에 뭔가 다른 오더를 업체에 보내든 다른 팀에 보내든 어쩌든 하니까 대부분 금요일 오전중에 끝내겠지....라고 (혼자) 생각합니다.그리고 한가지 중요한 건 ASAP는 주말을 치지 않습니다.  보통 나의 시간은 주5일이지만, 너는 주7일을 살고 있으니까요. 우리는 이토록 지랄맞은 평행세계에 살고 있습니다. 상사님들의 자택은 죄다 시간과 공간의 방입니다. 그곳의 시간은 느리게 흐르죠. 만약 자잘한 일일 경우엔 ASAP가 더 세분화됩니다. 잘잘한 수정건이나 서칭 건이라고 해봅시다.1. 9시에 시켰다면 점심전입니다.2. 10시에 시켰다면 점심전입니다.3. 11시에 시켰다면 2시까지입니다.4. 12시에 시키면 개자식입니다.5. 오후 1시에 시키면 4시까지 입니다.6. 오후 2시에 시키면 5시까지 입니다.7. 오후 3시에 시키면 5시까지 입니다.8. 오후 4시에 시키면 퇴근 전까지 입니다.9. 퇴근 전에 시키면 밤9시까지 입니다.10. 밤9시 시키면 내일 아침9시까지 입니다.등이 있겠군요. 보통 인간은 3의 프레임에 굉장히 익숙합니다. 수요일도 그러하고, 3시간도 마찬가지죠. 보통 1시간은 인간적으로 너무 짧다 생각하고, 2시간은 애매하고, 3시간이면 다 끝나겠지? 라고 (지 맘대로) 생각합니다. 문제는 그 마지노선이 5시정도라는 건데, 6시가 되면 지켜지진 않지만 퇴근시간이라는 심리적압박이 있어서 일단 그 전에 끝내야 내가 컨펌하고 뭔가 수정을 내리겠다.....라는 생각을 하는 겁니다. ASAP중 어떤 걸 먼저 해야할까?ASAP처럼 모호한 표현은 함의를 잘 살펴봐야 합니다. 미간의 찌푸림이나, 쓰읍..하는 입다심, 머뭇거리는 침묵 등에서 업무의 중요도를 파악할 수 있거든요. 일단 글로 표현할 수 있는 수준을 살펴보겠습니다. 참고로, 미간찌푸림, 쓰읍, 하아.. 음, 침묵, 어..이건.. 등의 고민끝의 ASAP는 후순위일 가능성이 높습니다. 대부분 진짜 급한 건 기껏 하란거 하고 있는데 갑자기 와서 "이것 먼저 처리해줘 급한거야!" 라고 급직구로 오는 경우가 많거든요. 1. '이거 먼저 처리해줘.''이거, 그거' 등 가까운 느낌의 대명사가 있는 경우가 더 먼저입니다. '저거, 말한 거' 등 거리가 먼 that계열의 대명사를 쓸 땐 심리적으로 중요도가 떨어져 있는 상태입니다. 좀 더 구체적으로 가면 그거보다 '이거'가 우선입니다. 그러니 영어로 말하던가, 아니면 손에 들고 정확하게 짚으라고 하면 좋을 것 같습니다. 시바(개의 품종입니다.) 2. '그때 그거 빨리 돼나?'과거의 일이라고 해도 '그거' 라는 대명사를 쓰면 중요도가 올라갑니다. 과거의 일을 현재로 끌고와서 내 품안에 안고 얘기하는 것이죠. '그때 그거' 를 먼저 합시다. (이거보다 우선입니다.)3. 음... 될 수 있는 대로'빨리' 라는 말대신 위와 같이 풀어말하면 중요도가 떨어지는 겁니다. 사실 해도 언제 내 마음이 바뀔 지 몰라서 본인도 아리까리 한 상태죠.4. 진짜 급해진짜 급한 겁니다. 1,2번보다 더 급합니다. '진짜, 대박, 제발, 얼른, 존나' 등이 붙으면 그게 최우선입니다.5. 이것도 아삽으로 해줘'~도' 라는 건  보통 문장상에선 앞 문장과 동등한 지위를 지니지만, 실생활에선 그렇지 않습니다. 먼저 나온 말이 중요합니다. "이것도~" 라는 문장은 부연에 속합니다. 보통 이런 말은 본인도 딱히 언제까지 해야할 지 잘 모르겠을 때 그냥 빨리 하라고 하는 경우거든요.6. 이거 ASAP면 좋을 것 같은데네, 저는 안좋습니다. 라고 말할 순 없겠죠. 중요도가 한참 떨어지는 겁니다. 7. 하아..그거? 음..ASAP이건 분명히 내일 되면 "어 그거 안해도 된대." 라는 소리가 나올 겁니다. 위에서 말했다시피 언제까진지 명확치않은 것은 항상 ASAP이므로 그 중 중요도가 떨어지는 것은 사라질 위험이 높습니다. 보통 업무에서 데이라인이 명확하지 않은 것들은 소리소문없이 사라지거든요. 8. A 먼저 해주고, 그리고 이건... ASAP1번에서 '이거' 가 붙으면 우선순위라고 했지만, 그 문장앞에 '그리고' 라는 순접접속사가 붙으면 부사절로 변하고 맙니다. 영문법에선 접속부사라고 하죠. 중요도에서 밀리므로,  A일을 먼저 처리합니다.9. 근데, 이것도 ASAP다.애매한 경우죠. 이것이라고 했으니 중요한데, ~도 가 붙었으니 밀립니다. '근데'라는 역접접속사가 붙었으니 문법적으론 이걸 먼저 처리하는 게 맞습니다.  매우 헷갈리죠. 이럴 땐 말투가 중요합니다."근데, 이것도 ASAP다!!!!' 라고 깜박했다는 느낌이면 이게 먼저고"근데, 이것도 ASAP네..' 라고 종결어미가 엄마 품처럼 부드러우면 후순윕니다.10. 그냥 다 ASAP야안되겠소, 쏩시다.죄다 온통 모든 것이 ASAP인 이유는 정작 본인도 뭐가 중요한 지 잘 모르고 있다는 반증입니다. 그러니 다시 뭐가 중요한 지 되물어봐도 소용없습니다. 상사입장에선 "어?...잘 모르겠는데..(긁적)" 하긴 싫고 일단 뭘 시키긴 해야겠으니 "그 정돈 알아서 해야하는 거 아냐?" 라는 이상한 질책이 돌아오는 거죠. 소소한 팁을 알려드리자면 이렇습니다.보통 큰 일을 먼저 하고, 잘잘한 것을 집어넣는 것이 맞다고 합니다만, 이러한 무한아삽이 있는 곳에선 그 공식이 잘 통하지 않습니다. 일단 자잘하고 빨리 "끝낼 수 있는" 것들을 끝내는 게 더 중요합니다. 그러니 작은 일을 빨리 쳐내서 끝내버리고 큰 일은 업무분장 조정을 하던, 배를 째던 합시다. 상사입장에선 어차피 크든 작든 다 작아보입니다. 상사는 빅픽쳐를 보고있기에 그 목표를 향한 업무들을 모두 '과정의 일부' 일 뿐이거든요. 그래서 작은 일 10개를 못하고 큰 일 1개를 해도, 그냥 일 1개를 한 겁니다. 별 것도 아니지만 일 10가지를 못하면 그냥 10가지를 못한 무능력자 되는 거죠. 그러다보면 얼토당토 않게 "넌 손이 느린 것 같아?" 라고 쿠사리도 먹고 뭐 그렇습니다.(억울뿌앵)그냥 눈치봐서 조정하는게 너무 답답하다면, 그냥 엑셀로 리스트를 만들어서 들이밀며. 순서 정해주세요. 라고 말하는 게 제일 속편하긴 합니다.(근데 대부분 순서 못정함)대부분의 ASAP은 실질적인 근거에 의해서 내려지는 오더가 아닙니다. 기분에 따라 내려지는 경우가 대다수죠. 그냥 대표 마음이 급해지면 모든게 ASAP인 겁니다. 뭔가 하나가 잘풀려서 여유로워지면, '어 그건 담주에 해도 돼.' 가 되기도 하고 말이죠. 그러니 그 오더를 100% 믿지 마세요. ASAP은 업무우선순위가 아닌 '내가 원할 때' 라는 사실을 곰곰히 되새겨 보면 도움이 되실지도...(사실 별 도움은 안됨)아니면 그냥 정신승리...이도저도 아니면 그냥 귀여운 탓인가..라고 정신승리를 합시다.

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

 최근의 스타트업 기업들은 100% 오프라인으로 서비스를 진행하는  서비스보다는 많은 부분을 온라인으로 서비스하는 분들이 많습니다. 그리고 온라인 서비스를 제작하기 위해선, 기본적으로1. 서비스 기획: 서비스를 설계하고, 철학을 담고 기능 등을 추가하고 설계하는 일2. 서비스 개발: 서버 안에서 진행되는 알고리즘을 수립하고, 구조를 설계하고 개발하는 일  3. 서비스 디자인: 서비스를 심미적으로 아름답고 직관적 있게 구현해 주는 일이렇게 기획, 개발, 디자인 세 가지 파트를 기본으로 필요합니다. (이외에도 마케팅이나, 경영 등의 부분들도 많지만, 이런 것들은 나중에 또 설명해 드리도록 하겠습니다.) 그리고 서비스를 만들기 위해서는 적어도 한 가지 또는 두 가지의 업무 정도는 수행할 수 있는 인원을 기반으로 시작하는 것이 옳다고 생각합니다. 그리고 처음부터 끝까지 제작하는 서비스인 만큼, 마음이 맞는 팀원들을 모아서 시작하는 것이 굉장히 중요한데요, 그렇다면 어떻게 팀원들을 모아야 할까요? 물론, 지인들과 주변 사람들과 함께 시작할 수 있는 경우라면 굉장히 좋겠지만, 모르는 사람들과 서비스를 시작할 경우, "어떻게 만나서 시작하느냐"가 중요합니다. 새롭게 알게 되는 분들과 스타트업을 시작하시는 분들은 아무래도 금전적 문제가 팀원을 모으는 것이 가장 먼저 겪는 문제일 것이고, 특히 개발자가 아니신 분들은 "개발자가 없다!!!!!!!!!"라는 것이 엄청나게 고민이실 겁니다(다 압니다. 저도 그랬으니깐요…. 하하하). 그리고 관심이 있는 개발자분이나, 기획자분, 또는 디자이너분이 있다고 하더라도 확실한 설득력이 없다면, 팀으로 모아서 시작하는 것이 굉장히 힘들죠. 그래서 스타트업이 인원을 충원할 때는 "서비스가 어떤 것인지를 나 말고 다른 사람들에게 명확하게 표현할 수 있을 때." 가 팀원을 모으는 가장 최적의 시기라고 생각합니다. 나중에 설명해 드리겠지만, 서비스 대하여 광고 문구 같이 "심금을 울리는" 그런 한마디가 아니라, 서비스에 대하여 육하원칙에 따라 명확하게 설명할 수 있는 상태가 제가 말한 명확하게 표현한다는 의미이고요. 이유를 설명해 드리자면, 스타트업이라는 기업의 특성상, 100%의 성공을 절대로 예측할 수 없고, 장애요소들이 너무나 많으므로, 서비스에 확신을 가지고 있는 사람들도 쉽게 시작을 할 수 없는 것이 스타트업이라고 생각합니다. 그러므로 감성을 털어 재끼는 표현보다는, 듣는 사람에게 확실하게 어떤 서비스 인지 보여주는 워딩을 할 수 없다면, 팀원을 모으는 것이 굉장히 힘들 겁니다. 개발의 경우, 어떤 서비스를 어떻게 하겠다는 명확한 근거가 없으면 제작을 하는 과정에서 많은 장애요소를 만나기 때문에 더 주저할 수밖에 없습니다. 여기서 팁을 드리자면, 개발자 분들을 팀원으로 설득하시기 위해서는 조금 더 디테일 한 설명을 필요로 하실 겁니다. "이런이런 서비스를 만드려고  한다."라는 것도 중요하지만, "어떤 기능을 기반으로 한, " 또는 "어떤 기능들이 주요 기능들인 서비스를 만드려고  한다."라는 것을 잘 설명해야 하고, 만약 구현하고 싶은 서비스와 비슷한 서비스가 있다면 직접 "이러한 것들을 해보고  싶다."라는 것을 집 적적으로 보여드리는 것을 추천드리고 싶습니다. 아예 기획하시는 분이 스토리 보드와 사이트 맵핑을 완료해서 가져가신 다면 더할 나위 없겠지만, 이제 시작하시는 분들에게 이것부터 시작해라 라고 하는 것은 무리가 있을 것 같아서, 조금 나중에 스토리보드와 사이트맵 같은 것들은 말씀드리겠습니다. 즉, 개발자와 기획자들은 언어의 표현이 다르기 때문에 비주얼 라이징 된 설명이 매우 중요합니다. 제가 창업을 시작했었던 2012년도 많은 스타트업이 있었지만, 요즘 들어 더 많은 스타트업들이 생겨나고 있고, 더 많은 분들이 창업을 생각하고 있으므로, 스타트업을 시작하기 위하여는 그때보다 더 확실하고 명확한 서비스의 근거나 비전을 제시할 수 있어야 할 것이라고 생각합니다. 그리고 팀원들에게 제공했던 것들도  이야기해 드리겠습니다(제가 이 부분에 있어서 가장 못 했다고 생각되어서 참 죄송하다는 생각을 많이 하고 있습니다). 스타트업을 시작하는 분들이 서비스를 같이 시작하는 사람들에게 가장 먼저 제시하는 부분들이 "지분"을 먼저  이야기할 수밖에 없다고 생각을 합니다. 서로의 업무에 책임감을 느낄 수 있고, 보다 능률적 있게 제작할 수 있다는 점에서 좋은 방법이라고 생각은 합니다만, 100% 효율적이라고는 이야기하지 못할 것 같습니다. 말씀드리는 이유는 서비스를 제작하는 시간은 깁니다. 처음부터 서비스를 원하는 시간에 만드는 것은 거의 불가능하다고 생각합니다(다양한 장애요소들이 워낙 많으므로). 이렇게 긴 시간 동안, "우리는 의협심 하나로 똘똘 뭉친 사람들이기 때문에 충분히 기다릴 수 있어."라고 생각하시는 분들도 있긴 하겠지만, 그렇게 업무를 진행하기에는 너무나도 힘들죠. 그리고 현실적으로 서비스 제작 기간 동안 먹고 사셔야 하기 때문에.... 하지만 그렇다고 100% 월급제로 고용하기에도 정말 부담스러운 부분들이 있다는 것은 저도 인정하는바 입니다. 그래서 공동 창업가들과 제가 했던 방법은 "지분+ 일종의 성과금" 정도였습니다. 지분을 어느 정도 제시하고, 서비스(알파 서비스/ 베타 서비스) 등의 제작 동안 소정의 감사비를 드리는 정도였죠. 지금도 생각하면 저무나 고생했었던 우리 디자이너 형, 개발자 동생에게 너무나도 미안한 마음입니다. 분명히 같이 창업을 했던 사람들이지만 말이죠. 이제 와서 생각해보면, 이것저것 다 가지고 시작하는 건 스타트업도 아니긴 하지만, 이도 저도 없는데 사람들 고생시킬 수 있는 것도  스타트업입니다. 신중하게 생각해서 시작하시는 걸 정말 다시 한 번 말씀드립니다. 그래도 요즘은 위시켓이나 로켓펀지 등에서 스타트업을 지원하는 인적 또는 물적 인프라가 많이 발전해서 많이 좋아졌다고는 하지만, 아직도 스타트업에 대한 관념이나 생각이 "음식점 같은 거 창업이나 하겠지...(창업은 치킨이  짱이죠...)"라고 생각하시는 분들도 많고, 또 이 작은 시장에서도 사기를 치시는 분들이 있어서 항상 조심히 하나하나 진행하시는 게 무조건적으로 중요하다고 생각합니다. (참 힘들죠…. 하하 아 그리고 프리랜서를 만나서 하시는 분은 주변  개발/디자이너/기획하시는 분을 꼭! 꼭꼭 대동하시기를 적극적으로 추천해 드립니다! 이 부분에 대해서는 나중에 기회가 있으면 알려드리겠습니다) 그래서 세줄 요약하자면(너무 멀리 돌아왔네요...;),1. 서비스에 대하여 머릿속에서가 아닌 다른 사람들에게 확실하게 정의할 수 있고, 금전적으로 안정이 될 때,2. 서비스에 대한 이야기를 듣고 서비스에 대하여 구현하고, 또 같이 발전할 수 있는 인원과,3. 100% 임금으로 상황이 좋지 않다면 약간의 지분과 적더라도, 확실한 임금지급을 기반으로,하는 것이 가장 이상적인 방법이라고 생각합니다.말하고 싶은 부분들이 너무나도 많은데 필력이 너무나도 딸려서 죄송스럽네요 ㅠ 궁금하신 부분들은 댓글 달아주시면 최대한 빨리 자세하게 설명하겠습니다!#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트 #팀빌딩 #팀플레이

타인 기준의 삶이 아닌, 제 기준의 삶을 살기 시작했어요.사내 인터뷰를 진행하면서, 본인 스스로의 취향, 선호도를 이만큼 확고하게 아는 사람은 아마 'Henie'뿐이라고 생각했다. 어떠한 질문도 한치의 망설임 없이 대답하던 해니에게 물었다.Q. "해니는 대체 어떻게 그렇게 스스로를 잘 알아요?"해니의 노트"예전엔 주로 타인의 취향과 성향에 맞춰서 살았던 것 같아요. 그래서 제가 무엇을 좋아하는지 어떤 사람인지 저만의 기호를 모르고 살고 있더라고요. 그리고 1년 전부터 노트에 모든 걸 적기 시작했어요. 제가 좋아하는 색깔, 좋아하는 성향의 사람들, 영화 등 모든 것을 쭉쭉 적어가면서 스스로를 알려고 노력하게 되었어요. 그러다 보니 사소한 거 하나까지 제가 무엇을 좋아하는지, 싫어하는지를 알게 되더라고요! 남에게 맞추고 의지하는 생활을 버리고 제 스스로가 좋아하는 것들을 스스로에게 해주려고 하다 보니 가장 저 다운 모습이 되었어요."(개인적으로 정말 좋은 습관이자 배울 점이라고 생각합니다! 멋있어요)헤니 아니고 해니!"헤니라고 하면 너무 연예인 다니엘 헤니 같잖아요. 그리고 해니가 훨씬 더 예뻐요. 그리고 혜니는 너무 본명 하고 비슷해서요 해니가 좋아요 저는! 호주 워킹홀리데이에 갔을 때 지은 이름이에요. 원래 Henney라고 이름을 지으려고 했는데 뜻이 아기 암탉이라고 하더라고요. 그래서 Henny 대신 Henie가 되었어요. 앞으로 '헤니' 말고 'ㅎH니'라고 불러주셔야 해요 알았죠?"점심시간 자고 있는 Neil(대표)과 셀카 찍는 해니와 체리 씨*Neil과 Cherish의 동의하에 올리는 사진입니다.듣고 싶은 당신의 스푼 라이프최연소 감독에서 콘텐츠 디자이너로"저는 원래 방송국 출신이에요. 4년 반 정도 방송국에서 일을 했었어요. 저는 초등학교 5학년 때부터 피디가 꿈이었어요. 그때부터 그냥 영상이 좋았거든요. 좋아하는 언니들이 영화 동아리 멤버여서 따라다니면서 프리미어를 배우기 시작했어요. 초등학교 5학년 때 청소년 영화제 최연소 수상을 하기도 했었고요. 중고등학교 내 내도 방송부 소속이었어요. 커서 피디가 될 줄 알았는데,  막상 앞에 다가가니 너무 문 턱이 너무 높다고 느꼈어요. 그래서 독립 기술을 배워서 편집 전문가가 되기로 마음먹고, 대학교 때 CG아르바이트를 시작으로 SBS 궁금한 이야기Y에 데뷔를 했어요. 24살 땐 KBS 최연소 CG 감독이 되어보기도 했고요. 방송국 편집일이 너무 재미있고 행복했지만, 뭔가 모를 붕 떠있는 기분이랄까요? 안정감과 소속감을 느끼고 싶단 생각을 많이 하게 되었던 것 같아요. 그때 선배들이 제게 취업을 제안해주시더라고요. 어딘가에 속해 보는 것도 굉장히 좋은 경험이라고 해주셔서 취업을 준비하게 되었고 그때 스푼이 콘텐츠 디자이너를 모집 중이라는 것을 알게 되었어요. 원래 스푼 라디오를 잘 알고 있었고 공고에 복지 및 회사에 대한 설명을 읽어보고 마이쿤(스푼 라디오)에 호감을 가지게 되어 지원을 하게 되었어요. 그리고 현재는 무한 소속감을 느끼며 스푼 라디오 한국 마케팅팀에서 콘텐츠 디자이너로서 스푼 라디오 광고를 제작하는 업무를 맡고 있습니다!"스푼에서 일하는 거 어때요?"저의 첫 회사생활, 너~무 좋아요! 제가 상상했던 그대로예요 이곳은. 아니 어쩌면 상상 이상 인 곳인 것 같아요.  저의 작업 스타일을 많이 존중해주시고, 제가 생각했던 '회사'라는 곳보다 훨씬 유연한 것 같아요. 그래서 일하러 오는 게 행복해요. 처음엔 영어 호칭에 대해서 별 다른 생각을 해본 적이 없는데, 막상 사용해보니까 이게 정말 좋더라고요. C-level분들과 말을 더 편하게 할 수 있는 것 같아요. 만약 대표님, 이사님, 부대표님 이런 식으로 호칭을 불러야 한다면 이만큼 편하게 커뮤니케이션하기 쉽진 않았을 것 같아요. 저는 스푼에 대한 애정, 스푼 사람들과 하고 싶은 것들이 많아요. 수평적인 문화뿐만 아니라, 디자이너를 존중해주시는 작업 분위기 때문인 것 같아요.그리고 저는 사내 브런치가 제겐 너무 도움이 되었어요. 브런치를 읽게 되면서 다른 부서 구성원분들에게 더 편하게 다가갈 수 있게 되었어요. 무슨 업무를 하시는지 알 수 있고, 관심사는 무엇인지 교류가 쉬워졌거든요. 특히 저는 Hugh의 대해서 되게 궁금했는데, 브런치를 읽고 어떤 사람인지 미리 알게 되었고 인터뷰가 정말 인상 깊었어요! 그 후 휴와 대화하는 데도 정말 편해졌어요. 마이쿤에는 정말 다양하고 멋진 사람들이 많다는 걸 글로 알게 되었어요"우리와 함께 일해요저는 한국 마케팅팀 분위기가 정말 좋아요.현재 분위기에 자연스럽게 잘 스며들 수 있는 사람과 함께 일하고 싶어요.첫째도 소통, 두 번째도 소통! 소통이 잘 되는 사람이요!해니를 잘 표현하는 야구장과 향수알고 싶은 Henie의 이야기야구 덕후! 향수 덕후 해니"맞아요. 저는 스포츠 중에 야구를 제일 좋아하고 NC Dinos 덕후예요! 그래서 직관은 최대한 많이 가려고 해요. 근데 시즌의 반이 여름이다 보니까 봄, 가을에만 직관을 가는 편이에요. 제가 더위를 조금 많이 타서 여름엔 휴대폰으로 본답니다! 야구 덕후가 된 이유요? 재미있잖아요! 보고 있으면 엔도르핀이 돌아요. 사람들과 다 같이 함께 소리를 지르고 응원하는 그 순간이 너무 좋아요. 그 쫀~쫀한 긴장감 있잖아요!제가 NC 팬인 이유는, 제가 마산 사람이거든요. NC Dinos 연고지가 마산이랍니다! 그래서 그때부터 좋아하게 된 것 같아요. 한참 야구에 빠졌을 땐 친구들도 만나지 않고 야구를 보러 갔던 것 같아요. 제 삶의 낙이에요 야구는!그리고, 저는 향수를 굉장히 좋아하는데요. 특히 조 말론 향수를 좋아해서 집 진열장에 쫙 나열되어 있어요. 제가 후각이 되게 발달되어 있어서 사람을 향으로 기억할 정도로 향을 좋아해요. 기분이 좋지 않은 날엔 향수를 뿌리고 잘 정도로 향을 좋아하다 보니 향수 수집가가 되었어요"나를 표현하는 한마디 스펀지 - "어디서든지 잘 적응하고 밝은 저를 나타내는 단어인 것 같아요. 중학교 1학년 때 담임 선생님이 저의 롤링페이퍼에 적어주신 별명인데 아직도 기억이 나고, 마음에 드는 단어예요"해니의 끼와 텐션의 비밀"저의 끼는 아마 부모님으로부터 물려받은 것이 아닐까 싶어요. 엄마 아빠가 두 분 다 실용음악을 하셨던 밴드 출신이세요. 엄마는 기타리스트이자 보컬이셨고, 아빠는 키보드 담당이셨어요. 집안 자체가 흥이 많다 보니 가족들끼리 명절에 노래방을 가면 3시간 내내 춤추고 노래를 부를 정도로 텐션이 높아요. 저는 아마 방송국에서 감독생활 아니었으면 음악 쪽으로 진로를 선택하지 않았을까 싶어요. 제18번이요? 사실 매번 바뀌긴 하지만, 어디 가서 든 잘 부를 수 있는 노래들이 있어요. '1. 박기영 - 나비 2. 박효신 - 그곳에서 서서'이 두곡은 언제 어디서나 불러도 잘 부를 수 있어요. 저는 일하다가도 꽂히는 노래가 생기면 점심시간이나 퇴근 후에 꼭 코노(코인 노래방)에 가야 해요. 스푼 멤버들 중 코노 좋아하시는 분들 많은데 같이 가면 좋겠어요 (스푼 라디오 내, 발라드파들 모이세요)그리고, 저의 높은 텐션은 사실 제가 스스로 만들어내는 것이기도 해요. 사실 보기보다 저는 덜 가벼운 사람이거든요. 사람을 너무 좋아해서 생각도 많고, 걱정도 많은 사람이에요. 기분 나쁜 일이 있어도 회사 올 때는 그런 모습을 보이고 싶지 않아서 고민과 걱정을 집에 놓고 출근을 하는 편이에요. 그리고 퇴근 후 한강을 걸으면서 잡생각을 버리려고 노력하기도 하고요."Henie는,1. '오이를 싫어하는 모임'에 가입되어 있을 정도로 오이를 싫어합니다.(오이, 토마토, 수박, 참외, 멜론을 못 먹는데요!)2. 찜닭, 들깨칼국수, 일식을 사랑합니다3. 스푼 라디오가 들으면 누구나 아는 서비스, 마이쿤이 누구나 입사하고 싶은 회사가 되었으면 합니다.4. 새로 입사하신 Ethan의 이야기가 궁금하다고 합니다. (조만간 인터뷰 요청드려야 할 것 같아요)팀원들이 Henie를 한마디로 표현한다면?Jay 曰: 김삿갓 - "그녀의 자유로운 영혼과 예술 감각 때문"Ted 曰: 보석 - "반짝반짝 빛이 나는 강한 존재감, 분위기 또한 반짝임"Sunny 曰: 거울 - "나와 비슷한 점이 많은 친구라서 보면 정감 가면서 동시에 걱정(?)도 되는 많은 것들이 고마운 친구"Summer 曰:  PO붙임성 WER -"붙임성의 끝판왕!"Chloe 曰: 수원 갈비 통닭 - "지금까지 이런 캐릭터는 없었다. 아이인가 어른인가! 마케팅 팀의 독보적인 캐릭터! 어린아이 같은 해맑음과 때론 진지한 두 가지 매력을 가졌다!"William 曰: 미뇽 - "미뇽처럼 귀여운 외모와 부드러운 성격의 소유자, 닐까지 녹이는 능력을 지닌 포켓몬"Cherish 曰: 도라에몽 - "처음 봤을 때 주먹이 동그랗고, 하얀 사람이었다. 도라에몽 주머니에서 뭐 나오듯이 자꾸 가방에서 뭘 꺼내서 준다."Ceci 曰: 비타민 - "밝고 상큼한 그녀의 목소리가 들리면 자동으로 기분이 좋아진다"

나는 후배들에게 스타트업과 관련하여 어떻게 성공하는 가에 대해서는 이야기할 성공 경험과 성공을 말할 능력은 없다. 다만, 무수히 많게 도전한 대부분의 사업의 실패 경험만 있을 뿐이다. 그래서, 성공하는 법은 이야기할 수 없고, 다만, 실패하거나 망하는 방법을 피하는 방법에 대해서만 이야기한다.'바둑은 운의 기예이다.'라는 말이 있다.사업과 성공, 승부에 대한 단어를 생각하기에 가장 좋은 비유는 바둑인것 같다. 알파고와 이세돌 9단의 대국을 보면서 사업에 대한 여러가지 생각이 떠올랐다. 보통, 바둑은 기예의 대결이라고 한다. 기량만이 신뢰할 수 있는 최상의 무기라고 바둑을 아는 사람들 대부분 그렇게 이야기한다.하지만, 승부의 결과는 꼭 그렇지 않다. 기량과 관계없이도 승부는 갈릴 수 있다. 이론으로 설명 안되고, 인력과 기량을 초월한 그 무엇으로 승부는 갈린다. 그러한 것을 많은 사람들은 '운'이라고 이야기한다. 물론, 그런 '운'도 기량의 하나라고 이야기하는 사람들도 있다.일단, 사업 성공의 비밀은 '운(運)'이 좋아야 한다. 시대적인 배경이건, 주변 인맥의 힘이건, 전쟁이건, 태어난 나라의 혜택이건... 일단, '운(運)'이 필요하다. 하지만, 이것은 어떻게 선택하거나 원한다고 생기는 것이 아닌, 외부의 효과이기 때문에 그런 천운을 받은 사람은 말 그대로 복 받은 사람이다. 그리고, 대부분은 '운'이 없다.그리고, 팀을 구성하고 팀원들이 세팅되는 것도 대부분 '운(運)'이 좌지우지한다. 그것 또한 어떻게 할 수 없는 외부 요인이다. 사업은 개인의 노력으로 어떻게 해결되지 못하는 것이 대부분이다. 그것을 알고 시작하도록 하자.다만, 이러한 '운'을 제외하고 통제할 수 있거나 판단할 수 있는 것들에 대해서 이야기하려 한다. 창업을 하고 싶은 사람에게 이야기해줄 키워드는 몇 가지밖에 없다.하나. 하늘이 내린 운...둘. 만들어진 제품이나 서비스를 구매할 시장, 마켓의 존재 유무셋. 너무 빨리 만들면 안 된다. 적당하게 시간을 맞추어야 한다.넷. 너무 많은 기능이 들어가거나 너무 적게 들어가면 안 된다. 적절한 비용으로 만들어진 적절한 제품이어야 한다.영어 키워드로 나열하면. Lucky, Market, right timeing/product, 실제 계산할 수 있거나 통제할 수 있는 것은 시장에 대한 판단과 적절한 시기와 적절한 기능에 대한 통제이다. 물론, 절대적인 것은 '운'이라고 생각하자.물론, 운은 있었으나 너무 빨리 만들거나, 너무 많은 기능으로 구현된 제품과 서비스를 내놓으면 실패한다. 내가 그러했다. 결국, 운을 기회로 만들고, 성공이라는 키워드로 바꾸는 것은 결국 '기량'과 '실력'의 차이라고 생각한다.뭐, 더 냉정하게 이야기한다면. 대한민국에서 사업에 성공하려면 '땅'이나 '부동산'을 사는 것이 최선이었다. 미래는 어떻게 될 것인지 모르겠지만, 최소한 2016년도까지는 그러한 것이 맞는 것 같다. 국내 벤처회사들 중에 우연인지 아닌지 모르겠지만. 대부분 '건물'과 '땅'을 구매했던 회사들은 살아남아있다. 아니, 그렇게 행동할 수 있는 결정을 내린 똑똑한 임원들이 그 회사를 살린것인지도 모르겠다.다만, 스타트업을 만들고 제대로 된 회사를 만든 다는 것이 얼마나 많은 고통 이상의 것들을 경험해야 하는 것인지 잘 아는 필자이기 때문에 '사업'에 대해서 진지하게 고민하라고 이야기하고 싶다. 이번 글의 주된 내용은 '사업'을 시작하기 전에 그런 것들을 고민해 보라는 것이다.성공과 성취에 대한 형이상학적은 뜬구름 잡는 이야기가 아니라, 조금은 현실적인 부분에 있어서 충분하게 생각하고 고민하고, 정말 자기가 하고 싶은 일이 의미가 있는 것인지에 대해서 생각해보았으면 하는 마음에서 그동안의 경험을 기반으로 몇 가지를 정리해본다. 그다음에 사업을 시작하는 생각을 결정해도 충분히 늦지 않을 것이다.일단, 창업을 꿈꾸는 사람들이 다음과 같은 이유로 회사를 그만둔다는 것이라면 다시 한번 창업을 생각하기 바란다.첫 번째. 사업이라는 것이 경영과 영업이 그렇게 대단해 보이지 않는다. 경영진과 영업이 하는 일이 그렇게 많아 보이지 않는다. 더군다나, 잘하고 있는 것 같지도 않다. ( 경영이나 사업, 영업이 쉬워 보일 때가 있다. )회사에서 열씨미~~ 일을 하는 직원들은 정신없는데, 경영진이나 영업진들이 하는 일은 명쾌하게 보이 지를 않는다. 다들 노는 것 같고, 무슨 일을 하는지 잘 모르겠다. 당장 물건을 만들 거서 서비스에 집중하기보다 뜬구름 잡는 이야기만 하는 사람들만 많은 것 같이 보인다.특히, 소프트웨어를 개발하고 있는 내가 보기에는 회사의 경영진이 제대로 고객과 대응하지 못하고, 잘못된 대응을 하면서 소프트웨어 개발자인 내 일이 점점 더 힘들어지고 있다. 그래서, 내가 직접 하는 것이 현명하다고 생각을 자주 하게 된다.쉽게 이야기해서 ‘경영진은 제대로 경영을 못하고, 영업팀은 제대로 고객 응대를 잘 못하고 있는 것 같다는 생각이 드는 때에, 스타트업을 생각하는 개발자의 경우에는 필자는 말리고 싶다.이런 생각을 하고 있는 개발자라면 아직은 '소프트웨어 개발'에 대해서 밖에 잘 모르는 상황이므로, 아직은 '창업'을 꿈꿀 때가 아니라고 필자는 창업을 만류하겠다. 아직은 언제나 자신이 하는 일이 더 커 보이고, 더 어렵게 생각되는 것은 매우 당연한 것이고, 일반적인 사람들의 입장에서는 그렇게 보이는 것이 매우 당연한 것이다. 그래서, 너무 자신의 좁은 시야만을 가지고 있기 때문에 창업을 하거나 스타트업을 하는 것에 대해서 깊이 있게 생각하기 바란다. 그렇게 너무 일반적인 '직장인'의 시선으로 밖에 회사의 업무를 파악하지 못한 것이기 때문에 아직은 '창업'을 할 때가 아닌 것 같다.두 번째. 아주 멋진 아이디어가 있고, 이 아이디어에 대해서 회사에서 받아들여지지 않는다. 정말 획기적인 아이디어인데... 이 아이디어는 분명, 누군가가 이 서비스가 만들어지면 열광할 것이다라는 믿음을 가지고 있을 때이다.누군지는 잘 모르겠지만, 내 아이디어를 필요로 하는 그 누군가를 위해서 이 아이템과 이 아이디어를 실현하고 싶다는 생각을 자꾸 떠올리게 한다. 다만, 이 아이템 와 아이디어가 쓸모 있을 것이라는 확신은 약간 부족한 정도일 뿐이다.하지만. 그 아이템과 아이디어가 '돈'을 주고 구매할 대상이 정말 존재할 것인지에 대해서 먼저 의심을 가져야 한다.조금은 구체적인 아이디어를 통해서, 실제 구매할 대상이거나, 아니면. 최소한 내가 '돈'을 내고 살 수 있는 아이디어가 구체화될 때까지 창업을 뒤로 미루라고 조언을 주고 싶다.언제나 기술이나 아이디어가 실제 실현되고 시장에서 제 역할을 하기 위해서는 실질적인 '구매자'가 분명하게 존재해야 한다. 단지, '아이디어'와 '서비스'의 아이디어만 가지고 실제 사업을 수행한다는 것은 매우 쉽지 않은 일이다.세 번째. 아이디어를 충분하게 구현을 하지 않았지만, 이 아이디어는 분명하게 성공할 수 있는 가능성이 있다. '돈'만 있으면, 충분하게 사람을 구하고, 서비스를 준비해서 시작할 수 있을 것이다.만일 이런 생각을 가지고 있다면, '작은 서비스'나 '작은 프로토 타입'이라도 실제 개발하여 보는 것을 먼저 하라고 권하고 싶다.어떤 아이디어이건 실제 구현을 하다 보면, 실제 머릿속으로 구상했던 것과는 전혀 다른 의미를 가지거나, 많이 부족하거나, 구체적인 실현 아이디어들이 덜 생각되어진 경우가 많다. 대부분의 성공적인 스타트업을 수행한 사람들의 사례를 살펴보면, 작은 것부터라도 실제 구현하고 실제 만들어본 후에 일을 시작한 경우가 많다는 것이다.이 외에 에도 내가 만들고 싶은 무언가를 위해서 창업과 비즈니스를 꿈꾸고 있는 개발자가 있다면, 이번 칼럼에서 몇 가지를 조언하고 싶은 것 중에 가장 큰 것은 '꿈'을 실현하는 데 있어서 '현실적인 일'에 대해서 너무 무시하거나, 너무 작게 생각하지 않기를 바란다.필자 역시 무언가를 만들고 싶어서 창업을 시작했을 때에는 정말 신났던 기억이 난다. 내가 만들고 싶은 제품에 대한 아이디어를 구상하고 구현하고 싶은 무언가를 만들고 테스트하고, 하고 싶은 것을 위해서, 만들고 싶은 것만을 위해서 그 이야기만을 나누는 사람들을 모으고, 그 꿈에 대해서 이야기할 때에 정말 즐거웠다.하지만, 나중에 알게 되었다. 실제, 사람을 모으고, 사람과 호흡하면서 실제 무언가를 만들어 나가는 '이익'을 위한 조직인 회사라는 곳과 공동작업이라는 것을 위해서 얼마나 많은 부수적인 작업들과 생각, 비전과 프로세스, 목표 등에 대해서 제품 개발 업무 이외의 수많은 작업들과 필요한 행정적인 업무들이 정말 많다는 것, 그러한 업무들이 정말 많다는 것을 나중에야 알게 된다.물론, 이러한 일을 대신해주고, 도와줄 사람을 구하는 것도 방법일 것이다. 하지만, 그 역시 사람이 투입되게 되면 '비용'이 들어가는 것이고, 어떤 사람이라고 하더라도, 자신과 똑같은 생각을 일치하게끔 가지는 것은 정말 매우 어려운 일이다.현재 시점에서 필자가 생각하는 무언가 목표로 하고 있는 서비스를 개발하는 것과, 다른 부수적인 업무들을 구분하고, 그러하게 만들어진 '가치'를 실제 시장에 내어 놓고, 실현하는 것을 퍼센트로 구분한다면 필자는 이렇게 정의한다.무언가를 만들어 내갈때에는 처음에는 개발이 50%, 다른 잡스러운 업무가 50%라고 생각할 수 있다. 순수하게 소프트웨어를 개발하고 구성하고 테스트하는 업무가 50이고, 다른 잡스러운 행정적인 것들의 업무가 50%를 넘어서는 수준으로 발생한다.은행을 찾아가는 법, 세금에 관련된 것, 직원을 고용하는 것에도 규칙이 있다는 것, 사람을 뽑고 관리하고, 시간을 조절하고, 근무장소에 대한 것, 사무실 청소부터 작은 소모품에 대한 관리까지 정말 많은 것이 있다.사람들과의 트러블은 매우 당연하게 발생하고, 별것 아닌 것 같지만 시간을 끊임없이 소모하게 되는 수많은 서류들이 '업무'로써 존재한다.정말 제품과 서비스를 만드는 것 이외의 전혀 상관없다고 생각하는 것들에 대해서 생각해야 하고 아이디어를 가져야 하고, 경험을 가져야 한다. 그런 업무에 대해서 생각하고 고민해야 하고 투자해야 한다.그리고, 실제 '서비스'나 '제품'이 나왔다면, 이러한 것들을 유지하기 위한 개발업무가 30%, 기타 잡스러운 업무가 30%, 해당 제품과 서비스를 관리를 하고, 유지 보수하는 업무가 전체의 40%에 해당한다.실질적으로 소프트웨어를 개발하는 업무는 전체적인 업무의 30%이며, 실제 아이디어를 구현하는 것보다 더 어려운 40%의 비용과 시간을 수정 유지 보수하기 위해서 시간과 비용을 소모하게 된다.처음에 잘 만들지 않은 소프트웨어라면, 이 유지보수 비용은 기하급수적으로 증가한다. 그리고, 대부분이 처음 만들어진 것을 다시 만든다. 그것이 소프트웨어 기업이고, IT기업인 것이다.개발자라면 창업이건, 기업을 만들건 몇 가지를 착각하면 안 된다. 그리고, 기억해야 한다. 대중 매체와 미디어에서 이야기하는 정말 성공한 사람들이 제대로 이야기를 해주지 않는구나라고 생각하는 것이 가장 현명하다.정말 뛰어나게 성공한 사람들은 자신들의 '운'에 대해서 잘 설명하기 어렵다. 그리고, 자신들이 가지고 있었던 배경과 기회에 대해서 잘 설명하지 못한다. 그래서, 대부분 사람들은 자신의 진정한 성공 스토리를 이야기하기보다는 자신이 생각하는 멋지고, 폼난 부분들만 설명할 뿐이다.'그 사람들은 좋은 부분만 이야기하고 있는 것이구나'라는 것을 한참 후에야 느끼고 이해할 수 있는 것이 실제 창업을 하고 사업을 하면서 알게 될 것이다.여기까지 느끼게 되면 이제야 '소프트웨어 개발을 하고 유지보수를 할 수 있으며, 행정적인 것을 끌어 갈 수 있게 된다. 하지만, 가장 어려운 것이 남아 있다. 여기까지 왔으면, 이제 사업가가 될 준비가 30%가 된 것이다.그것은 내가 만들고 싶은 사업 아이템을 위해서 자본을 끌어들이는 것을 고민하고 설득할 준비를 하는 것과 물건을 팔기 위해 고객을 찾아가는 것을 이제 시작해야 한다. 사실, 이제부터 본격적으로 '사업'에 대해서 구상해야 한다.그리고, 내가 생각한 아이디어와 서비스, 비즈니스를 손쉽게 시장과 고객에게 설득하기 위한 논리와 쉬운 설명방법을 생각해야 한다. 소비자와 투자자들은 언제나 '돈'을 가지고 있다. 그리고, 자신들이 필요한 서비스들에게 '유료'로 돈을 지불하고 구매할 용의가 있으며, 투자자는 '성공할만한 아이디어'에게 투자할 준비가 되어 있다.정말 필요하고 매력적인 제품과 서비스라면 '소비자'와 '투자자'를 찾는 것이 어렵지 않을 것이다. 실제, 시장에 '돈'은 정말 풍부하다.하지만, 대부분, 소비자에게 필요한 서비스를 매력적으로 설명하는 것이 얼마나 어려우며, 투자자에게 이 아이디어가 얼마나 매력적인지에 대해서 설명하는 것이 얼마나 어려운 것인가에 대해서 나중에야 느끼게 된다.자신이 혼자서 흥분하고, 자신만 좋아서 무언가를 만드는 행위는 그냥, 자신의 '개발 놀이', '사업 놀이'에 가깝다. 물론, 이러한 '놀이'를 했는데, 자신의 '놀이'의 파격적인 아이디어와 미래적인 가치를 발견한 소비자와 투자자를 바로 찾는 다면, 그것은 정말 대단한 행운을 얻은 것이다.그래서, 보통은 '창업'과 '사업'을 하려고 하는 사람이 있다면, 자신의 아이디어를 어떻게 정리하고 어떻게 설명하고, 어떻게 시장에 선을 보일 것인가에 대해서 충분한 연습과 충분한 준비를 하는 것이 정말 중요한 것이다.개인적으로는 대한민국의 창업과 관련된 수많은 프로세스들이 이러한 '최소한의 과정'을 위해서는 나름 정제되어 있는 프로세스를 가지고 있다고 생각한다. 물론, 이 제도들의 유용성이나 가치에 대해서는 이번 이야기에서 장황하게 설명하기에는 부족하기 때문에 단편적인 측면에서 '사업'을 준비하는 사람의 입장에서 어떤 방법으로 무엇을 먼저 '문서화'해야 하는지에 대해서 명쾌하게 가르쳐준다.굳이, 정부과제를 신청하지 않는다고 하더라도, 내가 하고 싶은 일과 내가 하고 싶은 것에 대해서 종이로 작성이 불가능하고, 단어로 설명할 수 없고, 구체적으로 무엇을 만드는지에 대해서 기술할 수 없다면, 그 사업과 아이템은 처음부터 다시 생각하는 것이 현명하다고 하고 싶다.물론, 이 프로세스를 통해서 수백 페이지의 문서를 만든다고 프로젝트가 성공하는 것은 아니다. 또한, 이러한 문서를 잘 만든다고 서비스와 아이템이 실현되는 것도 아니다.실제, 필자가 본 정말 자신의 생각을 잘 정리하는 사람은 이 프로세스에 맞추어서 내가 만들고자 하는 서비스의 정의와 이 서비스는 어떻게 만들어지며, 어떤 기술들이 필요하고, 어떤 시장과 어떤 환경을 예측하고 있는지에 대해서 많지 않은 문서로 충분하게 설명을 할 수 있다.그것이 이런 사업계획서를 작성하는 주목적이 된다. 그러니, 사업과 창업을 꿈꾸는 개발자라면 창업이나 프로젝트의 사업계획서를 꾸준하게 작성해보는 것이 어떨까 한다. 특히나, 기업 내부에 있다면 이러한 문서를 만드는 방법이나 표현법에 대해서 가감 없이 평가해줄 수 있는 유경험자들이 충분하게 있으니, 이런 도전을 한번 이상은 꼭 해보기를 바란다.물론, 그렇다고 해서, 성공하는 것도 아니다. 다만, 실수를 줄여주고, 내가 생각한 아이디어를 좀 더 구체적으로 표현하는 방법을 터득한 것뿐이다.회사를 만든다는 것은 정말 다른 것이다.회사를 만든다는 것은 정말 어렵다거나 쉽다거나의 문제가 아니다. 정말, 그동안 해온 일과 다를 것이다. 특히, 회사를 만든다는 것은 제품만 만든다는 것과 얼마나 다른 것인가? 에 대해서 깊이 있게 생각해야 한다.회사라는 법인체는 분명, 법적으로 살아있는 인격체이다. 그러한 인격체가 어떻게 만들어지고, 그 내부에 속한 조직원들에게 어떤 목소리를 내어야 하고, 그 과정을 어떻게 이겨내고, 어떻게 찾아가야 하는가에 대해서 깊이 있게 생각해야 한다.복잡한 경영이론과 개론을 이야기하는 것이 아니라, 여러 사람이 모여서 어떤 목표를 이루어 나가는 것에 있어서 구체적인 목표와 비전, 그리고. 문화에 대해서 어떻게 가져갈 것인가에 대해서 기준을 세워야 한다.그리고 다시 자신에게 되묻는 것을 계속 반복해야 한다.'정말 만들고 싶어서 고른 것인가?''아니면, 팔릴 것 같아서 만든 것인가?'필자는 어는 것이 정답인지 잘 모르겠다. 실제, 만들고 싶어서 만들었는데 잘된 경우도 보았으며, 잘 팔릴 것 같다고 생각한 제품이 실제 운이 좋거나, 일부 기술이 잘 개발되어져서 성공한 경우도 많이 보았다.현재 대한민국의 스타트업의 세계를 보면, 매우 재미있는 현상이 있다. 그것은 중견기업의 IT기업이 스타트업의 아이템과 비즈니스 모델을 적절한 가격에 사들인다는 것이다. 저 멀리 실리콘 벨리에서 수천억, 수조 원에 팔리는 환상적인 이야기는 아니지만, 구체적인 사업모델과 수익모델이 만들어지고, 이익을 보고 있거나, 무료 앱이지만 충분한 다운로드 횟수가 100만 다운로드를 넘어선 앱들이, 적절한 가격에 회사가 통째로 팔리는 경우를 보고 있거나, 자문을 하고 있다.구체적은 한국형 M&A의 시장이 가동되고 있는 것을 볼 수 있다는 것이 매우 고무적인 일이다. 현재는 무료 앱이라고 하더라도, 수백만 다운로드와 수십만 이상의 사용자를 가지고 있는 앱의 경우에도 충분하게 가치가 있다는 것을 시장에서 반응하고 있다. 현재의 투자자나 투자기업들은 스타트업에게 '비즈니스 모델'과 '수익 모델'에 대해서 질문하고 유도하지만, 충분하게 사용자를 확보한 모델의 경우에는 그 가치를 인정한다는 것이다.오히려, 그러한 모델로 진행된 스타트업의 경우에는 적절한 비즈니스 모델을 가진 모기업을 찾아주거나, 필요한 모델들끼리의 결합을 유도하기 시작했다. 이제 한국도 충분하게 M&A 시장이 소프트웨어 기업에서는 시작된 것이다.소프트웨어 사업은 혁신이 필요한가?소프트웨어 개발기업에게는 '혁신'이라는 단어가 꼭 필요한가에 대해서 필자에게 질문이 들어온다면, 필자는 '혁신'이 꼭 필요하다고 대답한다. 특히나 소프트웨어는 '정보'를 다루는 것이고 '정보'가 필요한 곳으로 옮겨가게 하고, 변환되게 하는 것이 소프트웨어 기업의 역할이다. 아무리 사소한 정보라고 하더라도, 손쉽고, 빠르고, 필요한 형태로 제공되는 것은 분명, 현시점에 없는 것이기 때문에 '혁신'이라고 평가할 수 있다.하지만, 이러한 '없는 것이 만들어진다'는 것에 대해서 소프트웨어 개발자들에게 설명을 할 때에 매우 난처한 경우가 간혹 발생한다. 특히나, 개발 경력이 조금 축적된 개발자들의 경우에 몇 가지 정보들을 재가공하여 만들어진 비즈니스 모델이나 환경에 대해서 매우 폄하하는 식의 발언을 하는 경우가 많다.필자 역시 그러했다. 소프트웨어 개발자이기 때문에 복잡하고 어려운 것을 만들고, 무언가 대단하게 기술적인 내용을 연구하고 실현하는 것이 '혁신'이라고 착각했던 것이다.그냥, 그것은 '기술자'로써의 연구를 위한 과제이지, 현재 비즈니스의 세계나 소프트웨어의 세계에서 이야기하는 '혁신'하고는 거리가 있는 것이다. 정말, '연구만을 위한 기술개발'은 존재하지 않는다.만일 그러한 '연구만을 위한 개발'을 하고 싶다면, 필자는 '오픈소스'를 사용하여 세상을 위하여 재능기부를 하는 마음으로 연구하라고 권하고 싶다. 이렇게, 진행하다고 어느 정도 필요한 가치 이상을 가지게 되었을 때에 기회가 오는 경우도 종종 발견한다.다만, 이러한 '연구'를 위한 기업을 만들거나 조직을 만드는 것은 그냥 가상 기업의 형태로, 자신의 여유 있는 시간을 투자하는 것으로 만족하기를 바란다고 이야기하고 싶다. 물론, 그것 이상의 가치가 있다고 생각하여 개인이 투자하는 것은 전적으로 개인의 선택이기 때문에 말리지는 않겠지만, 굳이, 그렇게 어렵게 할 필요 있는가 싶다.기업을 창업하는 이유는 무언가 구체적인 서비스가 결정되고, 그것에 충분한 자금이나 인력, 시간을 투입하여 시장에서 빠르게 가치를 실현하기 위해서 기업을 만들고 조직을 만드는 것이다. 그 뿐이라고 생각한다.그렇다면, 소프트웨어 산업에서 혁신이란 무엇인가?없는 것을 새롭게 만드는 것은 무엇인가?기술이란 도대체 뭐지?혼동하지 말자. 소프트웨어 산업에서의 혁신은 분명, 없는 것을 만드는 것이다. 그리고, 그 없는 것을 사용하는 소비자가 나타나는 것이다. 그것이 소프트웨어 산업에 있어서의 혁신이다.가장 유명하게 혁신을 설명한 방법이 있다. 가장 혁신을 쉽게 설명한 사례는 Tom Peters의 이야기 중에 '또 다른 햄버거를 내놓지 않는 것이다'라는 말로서 그 내용을 설명해보겠다. 그 글에서는 햄버거로 '혁신'에 대해서 설명한다. '와퍼(Whopper)가 있는데 불고기 와퍼가 나온다고 이것은 혁신이 아니다'. 정형화된 Fast Food는 변하지 않는다. 단지, 그 내용물이 좀 바뀐 것은 혁신이 아니라는 것이다. '정형화되고 싸고 빠른 것'이라는 FastFood인데 그 프로세스는 그대로이며, 빠르고 간편하게 먹는 패스트푸드의 성격은 변하지 않았다.그래서, 와퍼 대신에 불고기 와퍼가 나온 것은 혁신이라고 볼 수 없다. 하지만, 이런 패스트푸드를 정면에서 다시 해석하게 되면 혁신이 된다. 바로 인 앤 아웃 버거이다.신선한 재료와 재료의 선도를 목표로 하고 싸구려 냉동감자 대신에 생감자 French Fried를 튀겨 주는 것이다. 햄버거를 만드는 데 신선하고 선도가 좋은 재료와 생감자를 사용하여 제품을 만든다는 혁신을 실현한 것 In-N-Out의 생각이다.이러한 것처럼 '혁신'이란 기존의 가치를 바꾼 것이다. 그것이 '혁신'이다.물론, 개발자들 간에도 논쟁이 있다. 골수 소프트웨어 개발자들의 경우에 스티브 잡스가 만들어 낸 아이폰의 혁신이 과연 혁신인가? 과거의 것을 합쳐놓은 것 아닌가?라는 식으로 평가할 수 있다. 이런 생각을 가지고 있다면, '혁신'에 대해서 제대로 이해할 수 없는 소프트웨어 개발자가 되어버린 것이라고 필자는 이야기하고 싶다.그래도 스타트업을 하고 싶다면회사를 그만두고 한 번 창업하라고 한다. 사실, 기업이란 작게 망해봐야 정말 제대로 된 경험을 가지게 된다. 그래서, 가능한 젊었을 때에 부담스럽지 않게 망했을 때에 사업을 해보는 것이 가장 현명한 것인지도 모르겠다.한편으로는 두려움이 없고, 그 결과에 대한 책임감에 대해서 잘 모르는 무모한 시절에 창업을 하는 것이 더 현명한 지도 모르겠다.필자는 20대의 무모함과 도전정신으로 창업과 스타트업의 무거운 무게감을 이겨냈다고 생각한다. 현재, 필자의 경우에는 성공보다는 성취감에 더 집중하고 있고, 필자가 하고 싶은 일을 충분하게 하는 것으로 만족한다.너무 많은 준비를 한다고 성공의 요소가 충족되는 것도 아니고, 너무 적은 준비를 한다고 실패의 가능성이 높아지는 것이 아니다. 필자가 경험한 20년의 시간들을 뒤돌아 본다면, 사업은 그런 것 같다.99가지의 필요 충분한 요건을 세웠지만, 1가지의 요소 때문에 실패하는 경우를 보았고, 99가지를 엉터리로 했지만, 1가지의 요소 때문에 성공한 사람들을 보았다. 심지어, 그냥 운으로 성공한 사람도 있었다.필자의 주변을 돌아보면, 현재 대한민국에서 성공적으로 스타트업을 한 사람이라고 평가받는 경우는 정확한 시기에 자신이 만든 서비스를 보유한 기업을 정당한 ‘가격’에 현금으로 팔았거나, 자신의 솔루션을 ‘현금’으로 큰 기업에 판매한 사람들이거나, 투자를 받은 이후에 ‘현금’으로 성공적으로 exit 한 경우를 ‘성공’한 사람으로 평가한다.하지만, 필자는 꼭 그렇게 성공하는 모델을 후배들에게 추천하지 않는다. 필자가 생각하는 성공한 스타트업은 ‘자신이 만들고 싶어 하는 서비스’를 만들고, 자신이 일하고 싶은 동료들과 어울려서 10년이 넘도록 자신의 서비스와 솔루션을 만들고 유지 보수하면서, 자신이 개척한 시장의 소비자들과 공존하는 방법을 터득한 사람들을 ‘성취’한 사람들이라고 평가하고 싶다.후배들은 ‘성공’한 현금을 가진 사람이 될 것인지? ‘성취’한 사람이 될것인이지에 대해서는 각자의 목표와 비전에 맞추어서 생각하기 바란다. 과연, 인생의 목표는 ‘성공’인가? ‘성취’인가?

녹음된 자신의 목소리를 들어본 사람이라면 알 것이다. 얼마나 어색하고 때론 거북하기까지 한지 말이다.다른 사람의 목소리는 직접 듣는 것과 녹음된 목소리 사이에 큰 차이를 느끼지 못하는 걸 보면 내가 알고 있는 나와 다른이가 인식하는 나와의 간극이 있다는 것을 미루어 짐작 할 수 있다.당연히 목소리 뿐만이 아닐 것이다.심지어 취미로 운동을 배우더라도 내가 의도하며 취하는 나의 자세와 실제 나의 모습 사이에는 꽤 큰 차이가 존재하는 걸 경험한다. 이 차이를 받아들이지 않는다면 일정 수준 이상의 실력이 늘지 않는다. 그 차이를 인식하고 간격을 조정하는 과정이 실력을 늘리는 방법이다.다시 목소리로 가보자.아니 소리가 아니라 언어로 가보자.내가 얘기하는 말들이 남들에게도 그대로 들릴까?소리가 아니라 '의미' 말이다.자신이 말하는 의도가 남들에게도 동일한 의도로 읽혀질까?언어는 우리가 사회생활을 영위하기 위한 가장 기초 도구이기도 하지만, 가장 전문적이고 강력한 무기이기도 하다.업무로 다양한 사람을 만나면서 느끼는 점은 상대방의 전문성은 특정 기술이나 행위를 통해서가 아니라 그 영역을 어떻게 표현하고 묘사하느냐의 차이에서 느껴진다는 것이다. 누구든 10분 정도 이야기해보면 상대방의 내공과 실력을 가늠할 수 있다.거꾸로 이야기하면 자신이 던지는 말 한마디 한마디가 나를 판단하는 중요한 단서라는 것이고, 자신이 전달하려는 의도와 상대방이 인식하는 내용이 일치하지 않다면 이건 매우 곤란한 상황을 야기할 수 있다. 아주 미묘한 차이이지만 그 차이가 누적될 경우에는 인생 자체가 잘 풀리지 않게 된다.주변에 이런 동료가 있었다. 사람이 워낙 좋고 업무에서도 경험도 많은 친구였는데, 직급이 올라갈 수록 조직에서 인정을 받지 못하는 것이었다. 일을 직접 같이 하지 않았던 타 부서 동료였는데, 실제로 같이 일할 기회가 생겨서 업무로  엮이게 되면서 문제가 무엇인지 알 수 있었다.아는 것은 많은데 이걸 명료하게 표현하지 못하는 것이다. 말이 길어지고 꼬리에 꼬리를 물며 부연설명이 계속 되는 것이다. 본인은 친절하게 자세히 얘기하고 있다고 느끼겠지만 듣는 사람은 도무지 무슨 이야기인지 이해가 안되는 것이다.세상 일은 항상 복잡하고 얽혀있게 마련이다. 문제를 해결한다는 것은 복잡한 현상을 명료하게 구분하고 이걸 일 단위로 나누어서 처리하는 과정이다. 말이 꼬인다는 것은 생각이 복잡하다는 것이고, 문제를 정확히 정의하지 못하기 때문에 해결책도 효과적으로 찾아내기 어렵다. 이런 리더와 함께 일하면 삽질의 연속일 가능성이 높아진다.이런 경우 특히 어려운 점은 보고의 순간이다. 요점 정리가 안되고 핵심을 집어내지 못하기 때문에 의사결정자에게 올바른 리포팅이 어렵다.더 심각한 문제는 자신의 문제를 잘 인식하지 못한다는 것이다. 자신은 최선을 다하는데, 상대방이 알아주지 못한다고 생각한다. 나는 충분히 얘기하는데 상대가 이해하지 못한다고 치부한다. 자신의 꾀꼬리같은 목소리가 상대에게 두꺼비같이 들린다는 것을 받아들이지 않는 것이다.사실 남의 얘기가 아닐 것이다.여전히 말은 어려운 영역이다.왜 국어시간이 중요한지 요즘 다시 깨닫게 된다.말은 평생 공부해야 하는 분야인 것 같다.나도 깊이 반성해 본다.