나는 변화,대의,열정,야망,신념,신뢰,사명감과 같은 단어를 참 좋아한다.  내가 지향하는,목표하는 꿈에 이와 같은 것이 반드시 포함되게 하려 애쓴다. 변화를 일으키는 꿈,대의가 있는 꿈,열정이 있는 꿈,그것이 나의 야망이며 신념이고 나 자신에 대한 신뢰라고 여겨왔다.  그리고 그 꿈은 나 자신만을 위한,나 자신의 만족감을 위한 꿈이 아닌 세상을 위한,어떤 무언가에 기여할 수 있는 영향력이 되어야 한다는 일종의 사명감도 가지고 있다. '나는 변화한다',  '나는 다르다' 이것이 나의 모토이며 인생관이다.  그런데 누군가 내게 변할 수가 없다고 말했다. 변할 수 없는게 사람이라고 했다. 화가 너무 나서 한동안 벙쩌있었다. 아무말도 할 수 없었다. 그때 깨달았다. 아,나와 가치관이 많이 다른 사람이구나. 우리는 서로 다른 꿈을 꾸고 있구나. 나는 그 사람의 꿈을 존중했지만 동의는 하지 않았다.  그러나 시간이 지난 후,나는 그러한 생각을 가진 사람이 주변에 의외로 많다는 것을 알게 되었다. 예전,트위터에서 잠깐 대화를 나눈 사람도 내게 이렇게 말했다,인간은 절대 변하지 않는다고, 물론 대부분의 사람들은 변하지 않는다,하지만 변할 수 있다. 뼈를 깎는 노력을 하고 항상 의식하면 변할 수 있다고,변화할 수 있는 잠재성이 있는 사람은 시간이 오래 걸리더라도 언젠가 변화할 수 있다고-나는 그렇게 주장했다.  아무리 얘기를 계속해도 토론 진도에 진전이 없자, '그래 알았다'라고 대화를 종료하였지만,나는 이렇게 생각했다. '절대 변할 수 없다고 생각하기에 당신은 절대 변할 수가 없는거다'하지만 그래 맞긴 맞다,그사람들 말이 전부 틀린 것은 아니다. 인간은 절대 쉽게 변하지 않는다,하지만 사람은 절대 변하지 않는,변할 수 없는 사람과 변할 수 있는 가능성이 있는,변화하려 노력하는 사람,두분류로 나뉜다고 나는 믿고 있다. 물론 변화하는 사람은 극소수다.  인간의 성향,성질,근성에 있어서 관성의 법칙은 정말 잔인할 정도로 독하고 끈질기다.  변화는 마치 나 자신의 허물을 한꺼풀 한꺼풀 뜯어 벗겨내버리는 것과 같다.   ①변화정말 변화를 일으키려면,변화를 만들어내려면,어떠한 영향력을 끼치는 사람이 되고 싶다면,그럼 나부터 변화하자고.  성격,성향부터 시작해 생각하는 가치관,태도,말투,눈빛,표정까지 바꾸려 갖은 애를 썼다.  생각의 변화,가치관의 변화,행동의 변화,감정의 변화,성적의 변화...이 것은 그야말로'정신'성형이었다. 나의 정신 성형은 유학을 가고나서부터 시작되었다. 대입 시절2년간,내가 어떻게 생활하였는지는 오로지 내 가족만이 알고 있다. 뼈를 깎아내는 듯한 인고의 시간을 버텨냈기에 지금의 내 모습이 있지 않나 생각한다. 그런데 그런 내게,변할 수 없다?나는,나의 존재를 부정당한 것만 같았다. 그럼 내가 지금까지 보여줬던 모습은 무엇이었단 말인가. 그래서 다시 한번 제대로 보여주고 싶었다. 나라는 존재 자체가 제대로 변화의 본보기가 되고 싶었다.   자 보라,이런게 바로 변화라고. 그러나 그 말을 입 밖으로 내고 싶어도 참을 수 밖에 없었다. 대신 행동으로 보여주고 싶었다.이와 같은 생각을 한건,지금 이 시점으로부터,무려1년전, 2009년 때의 일이다.  ②대의꿈.나는 무엇이 되고 싶다-라고 쉽게 말하는 사람을 별로 좋아하지 않는다. 애널리스트가 되고싶다. 금융인이 되고싶다,컨설턴트가 되고 싶다. 선생님이 되고 싶다, CEO가 되고 싶다...그런 말을 하는 대부분의 사람들의 꿈에 대의가 없기 때문이다. 도대체 왜 컨설턴트가 되고 싶은가,왜 금융인이 되려 하는가,왜 디자이너가 되고 싶은가,왜 경영인이 되려 하는가,무엇을 위해서?단 한번이라도 자기 자신의 목적과 이익,개인의 만족,명예가 아닌 대의를 위한 꿈을 꾸어본 적이 있는가.③신념연 매출100억을 바라보고 있는 태양열에너지 벤처기업의25살CEO가 말하길,본인은 고 정주영 현대그룹 창업주의 말씀처럼‘국가경제에 기여하는 기업이 돼야 회사가 발전할 수 있다’는 신념을 갖고 있다고 말했다. 어느 신문 기사 일부분이다.기사를 읽어내려가면서 당연하다고 생각했다. 경제학,경영학을 공부한다면,  단순히 학교에서 이론을 배우는 것으로 그치는 것이 아니라,어떻게 하면 사람들이 경제적으로 기본권을 보장받으면서 잘 살 수 있게 할까,조금이라도 내가 국가경제 발전에 보탬이 되고 싶다.  그러면 나는 어떤 일을 해야할까-라고 고민하는 것이 이 시대의 젊은이들의 책임감이라고 생각한다. 그런데,현실은 취업하기 위해 경영학,경제학을 공부하고 심지어 타전공생들도 상경계열 학과를 이중전공한다고 한다.  경영학도로서,씁쓸한 현실이다. 대학에서의 배움의 중요성은 무엇을 배울지가 아니라,  또 그것을 얼마큼 어떻게 배울지가 아니라,무엇을 위해 나 자신은 그것을 배우려 하느냐-라는 깨달음을 얻는 것이라고 생각한다.④ 사명감다큐 풀빵엄마를 보고 많이 울었던 기억이 난다.  좋은 대학가서 취직 잘되는것이 인생의 정답은 아니다. 이제 우리 시대는 사회적 영향에 대한 사명감을 가져야하는 시대라고 생각한다.서울대 물리학과의 장회익 명예교수가 말하기를,참된 공부란 자기 자신만이 아닌 세상을 위한 공부라고,자아실현 못지 않게 아니 그보다 더 중요한 게 자신만의 출세,명예만을 위한 공부보다는 세상의 문제점과 맞서는 공부야말로 학문의 길이라 했다. 우리가 생각해야 하는 것은 할 수 있다 없다가 아니라 어떻게 해야 하는 것인가 이다. 어떻게 성공할 것인가,그 성공을 어떻게 유지할 것인가-그것만을 생각하는 사람과는 다르다.  무엇을 위해 성공할 것인가 그 성공을 누굴 위해 쓸 것인가.⑤열정Have a visionIt is to have a long-term view of where you are going and what you want to achieve.  Most of us live in a three-month window- just seeing what we did three months ago and what we need to do in the next three months.  By enjoying a longer perspective you are being strategic and strategists are the clever people amongst us. 당신이 진정 누구이며 무엇이 되고 싶은지,그 길을 알려 주는 것이 바로 비전이며,꿈의 크기가 성공의 크기를 결정한다. 나 자신에게,모두에게 가치 있는 일을 찾아라. 그리고 자기성찰의 시간을 가져라.난 어렸을 때부터 식탐도 많았고 갖고 싶은 물건에 대한 탐욕도 많았다.  "니인생에욕심을가져,돈욕심가지지말고.  그럼돈이절로따라오게돼있어"어머니께서 어렸을 적 부터,해주신 말씀이다. 나는 내 인생에 대한 욕심이 있다.  허나 그 인생에 대한 욕심이란, 돈을 잘 버는 것도 아니고 성취, 성공, 명예의 욕구도 아니다.  나는농도 진한 인생을 살고 싶다. 나는 쓸모 있는 사람이 되고 싶고 사람들에게 영향을 끼치는 사람이 되고 싶다.  그들의 삶이 어떠한 형태로든, 질과 양적인 차원을 벗어나 좀더 나은 삶이 되기를그들이 좀더 나은 생활을 영위할 수 있기를 바란다.  그동안 나는 여태까지 무엇을 했는가.  무엇을 위한 준비의 기간이었는가.  그렇다면, 그 준비는 완벽한가, 그 준비는 완료되었는가. ⑥  야망Ambition, 초등학교 3학년,이 단어를 처음 접한 때부터 쭈욱 좋아하는 단어 중의 하나다.  남들과 경쟁에서 No.1을 하던지, 남들에게 없는 것을 갖고 Only 1을 하던지.눈에 보이는, 꿈을 이루기 위한 밝고 힘찬 기운이 열정이라면, 야망은보이지 않는, 드러내지 않는 꿈이다.  본색을 드러내지 않는 꿈이 야망이라고 생각한다. ⑦  신뢰이제 나는, 누군가가 나를 따라잡고 싶어한다 해도, 한때 나를 성가시게 굴었던, 열등감 덩어리 그자체인 사람들이 여전히 나를 향한 열등심으로 가득해 할지라도 전혀 개의치 않는, 신경조차 쓰이지 않는 위치에 이르렀다, 실력으로도, 정신적으로도, 시간적으로도, 그리고 꿈의 크기로도.  제빵왕 김탁구에서 구마준이 김탁구의 상대가 되지 않는 이유와 같다. 구마준은 누군가를 이기기 위해 빵을 만들지만, 김탁구는 누군가를 위해 빵을 만든다.그리고이제는그들을안쓰럽게 생각할 줄, 불쌍하게 생각할 줄 알게 되었다. 이제서야 나의 어머니가1년 반전,해주신 말씀을 이해할 수 있게 되었다. “너에게 열등감을 가진 사람들을 불쌍하게 여길 줄 알아야 한다".이제 나는, 아무도 그들을 따라올 수 없는 자들과 함께, 나와 비슷한 가치관을 가지고 있고, 자기 꿈,목표가 뚜렷한 사람들과 서로 힘을 합해 앞으로 나아갈 것이다.  그리고 나와 그러한 사람들과의 시너지 효과는 어마어마할 것이다.  이것은 자만심도 자부심도 자신감도 아니다.  나 자신에 대한 신뢰,나와 함께하는 사람들과의 신뢰이자 현실이며 사실이다.   #넷뱅 #신념 #목표 #꿈 #창업가 #창업자 #마인드셋

안녕하세요 협업툴 플로우입니다.2021년 2분기가 지나고 어느덧 8월입니다. 벌써 2021년의 반이 지나갔습니다. 다들 올해 정한 개인의 목표는 얼마큼 이루셨나요? 저는 상반기에 수영을 배우려고 했지만 코로나로 인해 아직 시도조차 못했습니다. 개인의 목표와 마찬가지로 회사에서도 매년 목표를 정하고 달성률을 체크하는데요. 이번 포스팅은 기업 목표를 달성하기 위해 필수 조건인 협업툴에 대해 알아보려 합니다.협업툴이란 무엇인가?협업툴이란 여러 사용자가 별개의 작업 환경에서 하나의 프로젝트를 동시에 수행할 수 있도록 만들어주는 소프트웨어입니다. 새로운 개념 같아 보이지만 협업을 위한 솔루션은 이전부터 존재했는데요. 전화, 팩스 그리고 우리에게 익숙한 이메일도 커뮤니케이션을 위한 툴이나 협업툴의 한 축으로 볼 수 있습니다. 이후 무선 인터넷과 개인 모바일 기기의 보급이 가속화 되면서 협업툴에도 변화가 생기기 시작했는데요. 바로 우리가 가장 많이 사용하는 메신저 형태 협업툴의 출현입니다.협업툴하면 메신저 형태의 소프트웨어라고 생각하시는 분들이 많습니다. 협업툴을 영어로 하면 콜라보레이션 툴인데요. 단순히 커뮤니케이션만 가능한 메신저의 협업툴이 아닌 파일과 문서를 주고받고 음성/화상 회의가 가능하고, 업무를 등록하고 (To-Do-List) 관리하는 콜라보레이션 툴이 진정한 협업툴이라고 할 수 있습니다. 단순한 사내 메신저가 협업툴이라고 생각하면 큰 오산입니다!왜 협업툴을 도입해야 하나요?이메일과 USB, 외장 하드로 업무를 주고받으며 잘 쓰고 있는데, 왜 번거롭게 협업툴을 도입해야 하냐고요? 코로나로 인해 재택근무를 하면서 파일이 회사에 있어 곤란했던 적이 있으셨을 겁니다. 갑자기 USB와 외장하드가 뻑나서 자료가 날아간 경험도 있으실 거고요. 이메일을 찾다가 담당자에게 결국 통화를 해서 재전송을 요청했던 일, 카카오톡에서 파일 다운로드 기간이 지나 자료를 날려먹은 경험도 있으실 거고요. 만약 협업툴을 사용하고 있었더라면 어땠을까요?클라우드(SaaS)에 보관된 파일을 언제 어디서나 안전하게 확인할 수 있고 편집할 수도 있었을 겁니다. 정신없게 아무런 규칙 없이 쌓여있는 이메일에서 벗어나 업무별로 분리된 자료를 쉽게 찾아볼 수 있고요.오픈서베이의 업무툴 트렌드 리포트 2021을 살펴보면 연령대가 높을수록 개인 메신저인 카카오톡으로 업무 소통을 하는 경우가 많았습니다. 나이가 낮을수록 사내 메신저를 쓰는 경우가 많았고요. 요즘 젊은 사람들은 일과 개인 생활을 분리하는 걸 중요시한다는 리포트 결과가 아닐까 생각합니다. MZ 세대와 함께 일하기 위해서 앞으로 채용 페이지 한편에 "협업툴을 사용합니다."라는 문구가 꼭 필요할지도 모릅니다. 사족이 길었습니다. 협업툴을 써야 하는 가장 큰 이유는, 일이 편해지고 성과가 올라가기 때문입니다. 업무 성과뿐만 아니라 직원의 만족도도 대폭 올라갑니다.어떤 협업툴을 도입해야 하나요?코로나19가 터지고 난 뒤 국내, 해외 할 것 없이 협업툴이 우후죽순 생겨났습니다. 앞서 협업툴의 개념에 대해 이야기해 드렸는데요. 단순히 메신저 기능을 지원하는 협업툴이 많이 생겨났습니다. 메신저만 지원하는 협업툴의 경우에는 의사소통을 하기에 개인용 메신저보다 편할지 모르지만, 기업의 목표 달성과는 거리가 있습니다. 협업툴을 도입할 때 프로젝트 차원의 관리가 되는지 꼭 한번 확인해보셔야 합니다.✅ 메신저형 협업툴슬랙, 팀즈, 카카오워크, 네이버웍스, 플로우, 잔디✅ 프로젝트형 협업툴지라, 아사나, 트렐로, 플로우또 한 가지 고려해야 할 점은, 우리 회사의 정책에 맞는가입니다. 대기업이나 금융사, 법률사무소 등 개인 정보가 중요시되거나 별도의 보안 정책이 있는 기업의 경우 해외 협업툴을 사용할 수 없습니다. 사내에 있는 서버에 설치를 해서 내부망에서만 운용을 해야 하죠. 흔히 말하는 인트라넷만 가능한 대기업에서는 협업툴을 사용하기 어려웠습니다. 하지만 협업툴 플로우의 경우에는 서버 설치형 (온프레미스)가 가능하기 때문에 많은 기업에서 사용 중에 있습니다.일의 효율과 생산성을 증가시키고, 직원들의 스트레스를 줄일 수 있는 방법 중 하나는 협업툴의 도입이 아닐까 생각합니다. 백 번을 설명해도 한 번 써보고 체험해보는 게 중요합니다. 협업툴을 도입해서 2021년 하반기에는 꼭 목표 달성을 하시면 좋겠습니다.협업툴 플로우 바로가기

스타트업의 생존에 가장 중요한 소프트웨어의 품질에 대해서 이야기를 시작해보자.스타트업의 모든 역량은 소프트웨어와 그것을 기반으로 한 서비스의 안정적인 동작으로 모든 것이 표현된다. 모든 소프트웨어는 단계별로 개발되고 빠르게 개발되기 위해서 기술적 부채가 쌓이게 된다.가장 첫 버전이거나 시리즈 A의 투자를 받기 전까지는 아이디어를 빠르게 구현하는 것에 모든 것이 집중되므로 엄청난 기술적 부채로 인해서 서비스가 동작된 이후에 빠르게 소프트웨어를 거의 대부분 재개발하는 것이 매우 당연하게 된다.아이디어가 구현되고 만들고 있는 소프트웨어의 품질요소에 대해서 누군가는 관리하고, 누군가는 체크하고, 누군가는 기술적 부채의 리소스 자산관리를 취급해야 한다.소프트웨어 개발현장에서는 소프트웨어를 끊임없기 개발하고, 그 개발되어진 소프트웨어와 서비스에 대한 품질에 대해서고 끊임없이 체크하는 것은 정말 당연한 일이다. 그리고, 필자처럼 경험이 풍부하다고 하더라도, 실제 프로젝트의 일부분에 관여해서 프로젝트를 깔끔하게 마무리하거나 부드럽게 진행시킨다는 것은 정말 매우 어렵고 힘든 일이라고 할 수 있다.더군다나, 대부분의 프로젝트들은 시간상의 문제나 기획상 부족한 점들이 계속 드러나게 되는데다가, 개발자의 능력 부분의 문제까지 매우 다양한 변수들이 존재한다. 이런 매우 다양한 문제점들이 발생되어지는 상태에서 소프트웨어 개발일들은 계속 진행되어진다.대부분의 소프트웨어 공학이나 개발 방법론, 요즘 대두되고 있는 소프트웨어 시각화와 같은 이슈들의 핵심은 문제를 도출하고, 그 문제를 어떻게 해결할 것인지를 인지하고 인식하게 하는 것부터 출발한다. 그리고, 대부분 이런 문제들이 진행이 잘 안 되는 이유는 대부분의 개발 조직이 가지고 있는 시스템상의 문제이거나, 다른 이유 때문에 발생할 수 있다는 것을 미리 전제하여야 한다.하지만, 소프트웨어의 품질 부분은 계속되는 문제를 일으키는 것은 매우 당연한 것처럼 발생되어지고, 이런 문제들은 언제나 개발 조직에게 계속되는 이슈를 제기하게 된다. 이렇게 계속되는 문제점들, 계속되는 문제 상활들에 있어서, 이러한 소프트웨어의 품질 부분에 대해서 과연 누가 책임져야 하는 것일까?보통, 성공적인 소프트웨어 개발을 하는 경우에 몇 가지 원칙이 있다. 그것은 소프트웨어 개발을 성공적으로 만드는 매우 중요한 원칙들의 하나이다. 특히, 리더가 되는 경우에는 다음과 같은 부분들을 최대한 조절하는 것들은 매우 당연한 것이고, 이러한 것들에 대해서는 계속적인 관심을 보이게 된다. 그것을 몇 가지 살펴보면 다음과 같다.1. 소프트웨어 개발시에 필요한 요구사항이 계속 변화하는 것을 어떻게 대응할 것인가?2. 어떻게 하면 소프트웨어 개발자들이 특정 부분의 반복적인 작업을 어떻게 가능한 최소화 할 것인가?3. 사용자가 요구한 기능보다 좀 더 효과적으로 소프트웨어를 개발하는 방법은 어떤가?요구사항에 꾸준하게 대응하고, 특정 부분의 반복 작업을 방어하고, 좀 더 개선된 방향으로 소프트웨어 개발을 이끄는 것, 그것이 프로젝트 리더가 해야 할 일중 가장 중요한 일들이다.하지만, 소프트웨어 개발시에 이러한 목적과 방향성은 많은 부분에서 가장 극심한 것은 사용자의 변덕과 요구사항의 변덕스러움이다. 심지어 별거 아니라는 이유로 화면상에 표시되는 문구와 색상을 변경하는 것을 상시 요구하는 것은 어찌 보면 매우 당연한 것일 수 있다.물론, 이 경우에 소프트웨어 개발의 리더는 개발자들에게 이 수정 작업이 시스템과 소프트웨어의 품질을 향상시키고, 고객이나 사용자들에게 매우 의미 있다는 메시지와 신호를 계속 전달하여야 하는데, 대부분 어느 정도 시점에서 이것들을 포기하게 되는 경우가 있게 된다는 점만 주의한다면, 대부분의 개발 조직의 리더들은 이 부분에 대해서 버퍼링을 가장 확실하게 하는 편이다.또한, ‘설계’ 작업이라는 기간 동안에 일어나는 무수한 변동들은 ‘종이’상에서와 ‘개념’상으로만 변경되는 요소이기 때문에, 가능한 이 작업과 ‘기획’ 작업이 진행되는 상황에서 가능한 많은 부분을 처리하는 것이 좋다.소프트웨어 개발 조직의 문제와 시스템의 문제는 어떻게 인지해야 하는가?PM이나 PL이나, 보통 경험이 풍부한 사람들은 새로운 조직이나 새로운 프로젝트, 새로운 사람들과 만나면 관련된 업무의 진행방법이나 소통방법에 대해서 초기에 협의하거나 그 단어의 의미에 대해서 긴밀하게 이야기를 나누지 않으면 매우 힘든 상황들을 경험하게 된다.특히, 영업이나 프로젝트를 기획하는 파트에서 서비스나 소프트웨어의 개발 부분에 대한 이해능력이 조금 떨어지는 경우에는 이러한 단어의 선택이나 의미가 매우 중요해진다. 초기의 요구사항을 도출하고 그 완성 형태에 대해서 어떠한 방법으로라도 기술해야만 이 부분에 대해서 작업 후반부에 이질적인 상황이 발생하지 않는다.소프트웨어 개발 조직이 효과적으로 동작될 때에는 이 부분에 대해서 누가 통제를 하는 것이 아니라, 시스템이 이 부분을 커버하고 있거나, 이 부분에 대해서 인지하고, 시스템이 이해당사자들에게 이 정보를 꾸준하게 제공해주는 방법을 제공해야 한다.시스템의 요구사항과 완성 형태에 대해서 개발 조직과 이해당사자들에게 어떻게 시각화되어져서 보이며, 그 상황들에 대해서 기술하고 있는지, 그리고. 그 목적에 맞도록 개발이 진행되고 있으며, 일정이나 다른 리소스 상의 문제가 없는지에 대해서 꾸준하게 보여야 한다.하지만, 대부분 이러한 상황들은 완성 형태에 대해서 이질적인 서로의 이해도 때문에, 그 결과를 예측하기 어려운 상황으로 빠지는 경우가 있다. 특히, 완성 형태에 대해서 구체적인 모습을 서로 간에 이해를 같이 하고 있지 않는 경우가 대부분이고, 이런 부분들 때문에, 실제 소프트웨어 개발 조직에서는 후반부에 이 문제 때문에 격론을 벌이게 된다.보통, 이러한 완성 형태에 대해서 소프트웨어 개발 조직은 PM(Product Manager)라는 담당자가 그 부분을 통제한다. 프로덕트의 완성 형태를 생각해서 전체적인 상황을 이끄는 것이다. 하지만, 이 역할이 부재하거나, 개발자에게 이 기능이 내려가는 경우에는 소프트웨어 개발시에 시각화되는 부분이 극소로 변해버리거나, 초기에 Task하나만 존재하던 것이 막판에 서브 시스템 이상의 것으로 거대화 되는 경우가 비일비재한다.이러한 것은 PM의 기능적인 요소가 하위나 개발 조직으로 내려가게 되면, 은연중에 개발시에 들어가는 공수나 일정에 대해서는 조금은 야박하게 평가하면서도, 눈에 띄는 기능이나 주된 기능들에 비해서 저평가되는 경우가 많다.그리고, 기술적인 요소라고 평가를 받지 못하는 요소의 경우에도 이러한 경우가 있다. 또한, 개발자가 현재 인지하고 있는 개발의 방법이나 시스템적인 상황에 대해서 일부 유도하고 있는 방향으로 시스템 개발을 이끌면서 이러한 부분들이 극대로 평가받게 되고, 주도적이지 않거나, 신경 쓰지 않는 업무와 기능들은 작은 Task의 하나의 형태로 존재하게 되는 경우가 비일비재한다.물론, 이러한 것들을 해결하기 위한 다양한 기법들이 있으니, 이를 차용하면 좋겠지만. 현재처럼 고속 개발과 적은 팀원들이 움직이는 개발 방법론과 환경에서는 이러한 기법들을 모두 해당 조직에서 체크하기 매우 어렵게 된다.작은 개발팀을 지속적으로 유지시키고, 효과적인 팀으로 꾸려가려면, 가능한 기획단계에서 이런 부분에 대해서 충분하게 체크하고, 세부적인 부분에 대해서 ‘시각화’된 방법으로 개발 조직이 인지할 수 있게 해야 한다.이 부분에 대한 전파가 잘못되거나 완성된 제품의 형태에 대해서 제대로 인지시키지 못하면, 현재의 고속 개발 방법들의 대부분은 실패하게 되거나, 의미 없게 된다. 당연한 것이겠지만. 우연하게 뛰어난 능력의 소유자이거나, 현재처럼 손쉬운 소프트웨어 개발이 가능한 시대에서는 생각 이상으로 소프트웨어를 고속으로 개발하면서, 뛰어난 품질을 유지하는 경우도 많다.당연한 것이지만, 실제 소비자나 고객이 원하는 서비스의 형태로 나오지 않아서, 기능은 동작하지만 아무도 사용하지 않는 서비스를 만드는 경우는 당연하게도 실패한다.소프트웨어 개발의 품질 문제는 누가(Who) 책임져야 하는가?위에서도 여러 가지 언급하였지만, 대부분의 문제들은 시스템에 드러나며, 그 시스템을 만들고 유지하는 내부 조직의 다양한 문제들이 악순환되면서 하나의 문화로 정착되어진 경우를 종종 볼 수 있다. 이는 대기업의 형태이건, 중소기업이나 스타트업이건 나름 내부의 형태로 어떻게든 정착되어진다. 물론, 이러한 문제들이 없는 아주 깔끔한 조직이나 프로세스가 만들어지면 얼마나 좋을까라고 생각하겠지만. 그러한 환경을 만들기 위해서 필요한 리소스는 상당히 크다는 것을 잊지 않으면 좋겠다.언제나처럼 적당한 시스템을 만들고, 그 시스템을 보완할 수 있는 형태를 갖추는 것이 가장 효과적이라고 할 수 있다. 이 경우에 시스템을 통제하거나 통제를 하려는 사람에게 중요한 것은 ‘책임’을 지는 것이고, 그 책임에 맞추어서, 가장 최선의 시스템을 구성할 수 있게 하는 것이다.가장 중요한 것은 시스템의 문제를 확인하고, 그 확인된 문제를 통해서, 더 진보할 수 있는 방향으로 점진적으로 변화하고 있다는 것을 이해당사자들에게 모두 전달할 수 있는 시스템이 되어야 한다. 하지만, 이러한 ‘진보’가 실패하는 경우에는 결국, 대형사고를 만들게 되고, 그 대형사고는 그러한 환경을 만들지 못했거나, 품질관리에 실패한 경우라고 생각하면 된다. 대부분의 조직들은 대형사고들이 터지면, 해당 대형사고를 통해서, 시스템이 개선될 수 있도록 고민하고, 그 해결책을 찾는 것에 상당 부분 리소스를 투입한다.대부분의 문제들은 그 문제가 중첩되어졌거나, 그 문제를 일으킬 수밖에 없는 원인들을 알 수 있게 한다. 이미 문제가 생겼다면, 그 문제를 최대한 조직에 효과적이고 효율적인 환경을 만들 수 있는 배경지식으로 활용하는 것이 그 문제를 해결하는 첫 번째이다. 그러므로, 대형사고가 발생하거나 문제점이 발생하면, 그 문제를 올바르게 인식하는 것부터가 첫 번째 해결방법의 주된 키워드이다. 다음의 유명한 미국의 사례를 예를 들어서, 시스템적인 문제가 발생하였을 경우의 대처상황을 예시로 알아보자.미국 공항 관제사의 졸음 근무가 벌어진 이후에 미국의 시스템이 어떻게 바뀌었는지 보자.2011년 4월 15일 국내 방송사의 뉴스 코너에서 이야기가 나온 간단한 기사를 간단하게 소개하면 다음과 같다. ‘공항 관제사들이 한밤중에 조는 바람에 항공기가 착륙 안내를 받지 못하는 일이 빈번하게 발생하였고, 응급 항공기가 착륙 유도를 받지 못하는 사고도 있었다. 새벽 2시의 미국 네바다 주의 리노 국제공항에서 일어난 일이다.-조종사 : 리노 관제탑, 샤이언 라이프가드 20TN항공기다.응급환자를 태운 이 항공기는 긴급 착륙을 요청하지만 관제탑은 묵묵부담이었다. 이에 무선을 듣고 있던 다른 공항의 관제사가 대신 전화연락을 취하지만, 이 내용에도 아무런 응답이 없다.-LA관제사 : 우리가 그 관제탐에 전화해 보겠다.-조종사 : 중환자가 타고 있어 어쨌건 착륙을 해야겠다.이런 관제사의 졸음으로 인한 사고가 2011년에 교신 중단이 되는 사고가 6건이나 발생하였다는 이 사고에 대해서, 당시 라우드 미 교통장관은 다음과 같이 이야기한다.‘말도 안 되는 일입니다. 이 같은 행동을 용납하지 않겠습니다’.라는 이야기와 함께, 미 전역의 관제를 책임을 지고 있는 연방항공청의 책임자는 매우 당연하게 사퇴하게 되고, 업무의 부담과 실수를 줄이기 위해서 관제탑의 야간 근무자를 2명으로 늘리게 된다.실수를 통해서 시스템이 개선되는 사례는 미국과 같은 선진국에서는 매우 당연한 결과이다.이 사건의 내용을 조심히 살펴보면, 가장 중요한 것은 시스템과 프로세스에 대한 내용이며, 이러한 시스템과 프로세스를 관리하고 정책을 결정하는 일에 대한 책임감과 중요성에 대해서 얼마나 인식하고 있느냐의 문제이다.이런 문제에 가장 큰 책임을 져야 하는 것은 그런 정책과 결정 과정을 만들고, 유지하는 사람들의 몫이라는 것이다. 물론, 이와 유사한 사례의 사고도 몇 건 더 있었다. 리노의 사건 이후에도 발생한 미국 마이애미 공항에서 관제사가 깜빡 잠드는 사례가 있었으나, 당시 12명의 관제사가 함께 근무 중이었기 때문에, 별다른 사고가 없었고, 그 문제의 관제사에게 정직처분이 내려졌다는 것이다.앞서 이야기한 사건 때문에 FAA에서 관제시스템의 운영방식의 전반적인 재검토작업을 통해서, 관제사 노조 측은 수면부족과 과로로 인해 문제가 발생하고 있다는 점과, 야간 교대 근무일 정의 조정이 필요하다는 주장도 같이 이어졌지만, 가장 중요한 것은. 단 한 명의 야간 관제사만 근무하게 되면 대형사고를 발생시킬 수 있다는 점을 시스템에서 대응을 하지 않았고, 이를 금지하지 않았기 때문에, 미국 네바다주 리노에서는 사고가 발생할뻔한 것이다.당연한 것이지만, 이런 경우에는 이 문제를 사전에 예측하지 못한 시스템의 총괄 책임자가 그 책임을 지는 것은 매우 당연하다.하지만, 이러한 식의 책임을 지는 곳은 ‘시스템’을 계속 업그레이드하거나, 발전적인 방향으로 시스템을 진화시킬 수 있다. ‘문제’가 발생되는 이유와 근본적인 부분에 대한 대응책을 마련하기 때문에, 한 번의 실수를 통해서 시스템은 언제나 보완되어갈 수 있기 때문이다.하지만, 한국에서 KTX 3중 추돌 사건이나 세월호 사건을 생각해보자.결론만 이야기하자. 뉴스에 발표된 내용을 참고로 한다면, ‘대구역을 통과하는 서울행 KTX를 무궁화호 열차가 출발 신호보다 빨리 운행하면서 서울행 KTX측면을 접촉해 선로를 이탈시켜 하행선 KTX와 접촉한 사고’라고 공식적으로 발표가 되었다.관제실, 기관사, 여객전무 등 ‘3각 체제’가 부실했을 가능성과 신호체계의 오류 가능성을 염두에 두었다고 한다. 하지만, 철도 운행에는 최소 4단계 이상의 안전조치가 규정되어 있으며, 중앙관제실의 자동 전산 제어시스템, 대구역 관제실의 제어시스템, 출발 신호기, 여객전무의 수신호와 무전, 기관사의 확인 및 복명의 절차와 프로세스가 있다고 한다.그런데? 왜 사고가 발생하였을까?가장 큰 문제는 비숙련 대체 투입인력이라는 것에 대해서 먼저 이해하고, 시스템적인 문제에 대해서 생각하자. 이와 같은 사고의 핵심이 인재에 있건, 시스템의 구조적인 문제이건, 하다못해 테러라는 이야기까지 공통점을 하나 체크하자면, 그것은 시스템에 대한 부분에 검증 부분이 허술했다고 이야기할 수 있다.드러난 몇 가지 사실 들을 나열해본다면, ‘매뉴얼’을 무시해서 일어난 사고라고 생각할 수 있다. 지난달에 스페인에서 고속열차의 탈선사고 또한 이러한 기본적인 매뉴얼을 제대로 지키지 못했기 때문에 대부분 발생한다.당연하지만, ‘인재’가 발생되거나 ‘인적과실’이 발생하는 경우에 가장 중요한 것은 ‘시스템’과 ‘서비스’, ‘인프라’에 그 책임을 일차적으로 물어야 한다. 그런 상황을 발생시키게 근로자를 제대로 교육하지 않았거나, 숙련된 전문인력을 제대로 배치하지 못하였거나, 관련 프로토콜의 오류나, 점검이 되어야 할 테스트 케이스가 부족해서 발생한 것이거나. 특이사항에 대한 대처가 되지 않았던 것이기 때문에, 1차적으로 ‘담당자’에게 책임을 묻기 이전에, 시스템을 관장하고 운영하는 책임자가 그 책임을 지어야 한다.스페인 산티아고 고속열차 탈선사고와 문제점도 같이 살펴보자.스페인 산티아고 데콤프 스텔라에서 발생한 사고 뉴스를 살펴봐도, 분명. 전적으로 기관사에게 책임이 있을 수 있지만, 이런 사고가 발생하지 않도록 많은 안전 대책 매뉴얼과 시스템이 제대로 작동하지 않았다고 평가를 해야 한다. 이런 심각한 상황에 대한 모든 책임을 ‘기관사’에게 부여하는 것은 매우 무책임한 행동 아닐까?기사에 언급되었던 대로 시속 80킬로미터 주행구간에서 190킬로미터로 주행했다고 하는데, 만일 해당 기차 시스템에서 그런 부분을 제대로 파악해서, 시스템이 보호했다면, 이런 사고는 아예 일어나지 않았을 것 아닌가? ( 누가 해당 시스템의 구간단속 부분에 대해서 허가한 것이고, 소프트웨어 품질 요소를 평가한 것일까? )당연한 것이지만, 현대의 최신 소프트웨어와 시스템들은 대부분 엄청 복잡하다. 당연스럽게도 인간의 한계에 대해서 제대로 인식한 형태로 디자인되어야 한다. 결론적으로 스페인 시스템은 비록 80킬로미터 제한 구간임에도 불구하고, 최대속도 200킬로미터 이하에서는 ‘인간’이 그 부분을 제어해야 하는 어처구니없이 황당한 시스템을 만들고 허가를 준 것 아닌가 한다.결론은 간단하다. 80킬로미터 구간을 설계하고 허가한 당국도 책임을 지어야 하며, 해당 구간에서 속도를 자동으로 체크하거나 조절할 수 있는 시스템을 설계하고 만들지 못한 제작사도 책임져야 하며, 이런 전체적인 부분을 감리하지 못한 감리기관도 책임져야 하고. 더 중요한 것은 이런 상황에서 기차를 운행하게 한 관리당국 또한 책임을 져야 한다.단언컨대 인간의 실수만으로는 사고는 발생하지 않는다. 하지만, 인간의 실수를 방어하기 위한 안전장치들이 있어야 하며, 이런 것에 대해서 시스템에 반영하지 않는 것들에 대해서는 시스템의 책임자들은 인지하고 그 안전장치들을 만들어야 한다. 하지만, 가장 안전에 신경을 많이 쓰고 있는 유럽에서 벌어진 일이기에, 도대체 이런 사고가 왜 발생하였는가는 정말 의아하다.필자가 유럽여행 중에 느꼈던 안전에 대한 경험필자가 유럽에 산업 계분들과 같이 시장개척단으로 유럽에서 프랑스를 갔을 때의 경험이다. 관광버스를 대여하여 운행을 하였는데, 관련 일정이 수정되면서 방문하려는 지역이 변경되었을 때에, 해당 관광버스의 운전기사는 거리가 멀어지고 운행시간이 길어진 것에 대해서 매우 난색을 표명했다.그것은, 관광버스의 운행시간이 하루 6시간으로 제한되어 있으며, 해당 기록은 관광버스의 블랙박스를 통해서 통제받으며, 더 이상 운행할 수 없다고 하였다. 그래서, 필자의 일행들은 별도의 다른 버스를 임대하여 운행을 했던 기억이 있다.이처럼, 안전이란 ‘프로세스’를 얼마나 철저하게 지키느냐의 관점이다.소프트웨어 개발에서 꼭 필요한 시스템과 서비스가 없는가?현재의 소프트웨어 개발과 관련된 프로세스들은 생각 이상으로 자동화가 되어 있고, 꽤 많은 시스템들이 공개 소프트웨어로 만들어져 있다. 현재 내가 속한 기업과 조직이 다음과 같은 환경을 갖추고 있는지 확인해보자. 아래에 나열한 시스템이 빠져있거나, 구성되어 있지 않고, 그러한 시스템을 구축하려 준비나 계획도 없는 기업이라면 해당 기업은 소프트웨어 개발에 있어서 품질이나 책임에 대해서 명확하게 구분할 능력도, 그럴 마음도 없는 기업이라고 예측하기 좋다.하나. 소프트웨어 개발은 하는 버전 컨트롤도 하지 않는다소프트웨어 개발회사에서 가장 귀중한 자원은 ‘소스’이다. 그 ‘소스’를 어떻게 관리하고, 대우하느냐가 가장 중요한 것이라고 생각하는 것은 매우 당연한 것이지만, 생각 이외로 이러한 ‘소스’를 제대로 된 시스템에서 관리하지 않는 기업이 많다.‘소스’를 제대로 관리하지 않는다면, 그 ‘소스’를 개발하는 개발자들에 대한 대우나, 처우는 얼마나 엉터리 인 것인지 잘 알 수 있을 것이다. 그리고, 대부분 기업은 하나의 서비스나 설루션에 집중하는 경우가 많은데, 이러한 ‘버전 컨트롤’을 하지 않는다는 것은, 그러한 ‘지식’과 ‘경험’을 제대로 관리하지 않는다는 것이고, 결론적으로는 상품이나 서비스를 개발하는 회사가 아니라, 전형적인 ‘SI’에 집중하거나, 당장의 돈벌이에 집중하는 회사일 가능성이 매우 높다.둘. 자동으로 빌드하고, 자동으로 테스트하는 시스템이 있는가?대부분의 자동화가 가장 효과적으로 그 능력을 발휘하는 경우는 요즘과 같은 환경에서는 자동으로 빌드하고, 자동으로 테스트하는 환경을 구축하는 것이다. 필자가 보기에는 개발자의 업무 중의 20% 정도는 이러한 빌드와 테스트하는 시간에 상당 부분 반복적인 작업을 할당하여 사용하고 있다.개발자들을 우대하고, 개발자들의 리소스를 귀중하게 생각하고 있다면, 개발자들이 반복적으로 투여하고 있는 업무를 어떻게든 자동화하는데 집중하는 것은 매우도 당연한 것이다.셋. 전체적인 소프트웨어 개발을 모니터링하고 있는가?현재의 단계, 문제가 있는 상황. 그리고. 개발자들 간의 소통과 경험들, 고객과의 업무나 지시, 요구사항들에 대한 내용들이 단편적인 종이들과 개개인의 기억에 의존하는 경우인가를 확인해보면 된다. 전체적인 모니터링을 하지 않는다는 것은, 각각의 업무에 대해서 통제도 불가능하고, 업무의 기능별 분화나, 업무들을 공동 작업하는 상황들을 만들기도 매우 어렵다.넷. 테스터의 롤이 별도로 있거나 테스팅 환경을 구축하고 있는가?특정한 사람이 있거나 하는 것이 아니라, 소프트웨어 개발은 개발자가 테스트를 하면, 버그를 찾기 매우 어렵다는 점이다. 자신이 코딩하였기 때문에 해당 룰로만 테스트를 진행하고, 의미 없는 테스트 시간만 허비하는 경우가 많다. 가장 잘되어있는 조직은, 크로스 체크를 하는 테스팅 규칙이거나, 테스팅의 업무의 중요성을 잘 알고 있는 경우이다.다섯. 버그 트랙킹 시스템을 구축하고 있는가?문서화의 척도나, 소프트웨어 개발회사의 이슈, 버그 등의 상황들을 전체적으로 관리하고 있느냐와, 관리하고 있지 않느냐의 차이는 정말 크다. 특히, 관리자의 경우 이런 문서화나 시스템이 존재하지 않게 되면, 실질적인 통계나 환경에 대한 정보보다는, 개인적인 감에 의해서, 시스템의 프로세스나 경험을 반영하는 경우가 많아지게 된다.그리고, 개발자들 간에도 서로 간에 유의미한 대화나, 경험들이 축적되게 된다. 또한, 버그가 발생되어지고, 버그를 수정하는 과정들이 투명하게 되면서, 해당된 정보들에서 파생되는 지식과 경험들을 더 많이 얻게 된다.이상의 과정들의 기본도 갖추고 있지 않는 회사라면, 특정 문제가 발생하였을 때에 그 원인을 추적하거나, 그 문제를 알기 위해서는 별도의 작업을 수행해야 하고, 실제 조직원들이 그 문제를 찾기도 어렵다. 대부분의 제대로 된 기업과 조직은 이러한 문제들을 방어하기 위해서 프로세스나 업무를 시각화하려고 하는 것이고. 그 시도를 통해서, 프로세스를 개선하려 한다.마지막으로 소프트웨어 개발의 책임은 누가 질 것인가?소프트웨어 개발에 있어서, 성공적인 소프트웨어가 개발되어지는 것 이외에, 실패를 하게 되었을 때에 소프트웨어 개발에 대한 책임은 누가 져야 하는가? 결국, 책임은 이해당사자들 모두가 지게 되지만, 가장 큰 책임을 지게 되는 것은, 그 소프트웨어의 프로덕트를 요구했으나, 제대로 된 제품을 받지 못하게 된 고객이 가장 큰 책임을 지게 될 것이다.제대로 된 시기나 제대로 된 제품이나 서비스를 받지 못하게 되는 것이 가장 큰 책임이다. 대부분의 소프트웨어들은 이런 고객들에게 최대한 서비스나 제품들이 효과적으로 개발되고 수행되고, 서비스되는 가에 대해서 끊임없이 경고하고, 정보를 제공해주는 방법들을 얼마나 많이 시각화하느냐에 집중되어져 있다.소프트웨어의 개발시에 시각화는 이런 부분들을 전반적으로 포괄하고 있다. 소프트웨어의 품질은 꾸준하게 요구사항에서 발생되어질 문제와 최종 제품의 모습을 어떻게 상상하고, 그것을 대응할 것인가에 대해서 계속적인 활동을 하는 것이다.소프트웨어 방법론이나 필요한 수많은 기능들과 체크하는 방법들은 이러한 것들을 어떻게 게 효과적으로 진행하면 가능한 것인가에 대한 수많은 테스트 자료일 뿐이다.최종적으로 이야기하자면, 소프트웨어 개발이 실패한다면, 그것에 대한 책임은 그 소프트웨어를 개발한 모든 사람에게 있는 것이라는 점이다. 가장 훌륭한 소프트웨어 개발 조직은 똑같은 실패를 다시 경험하지 않는 것이다.문제가 있는 상황을 인지하고, 그 상황을 해결하고, 그 상황을 변화시키려는 조직은 언제나 유기적이고, 유동적으로 그 문제를 해결할 수 있게 한다. 다만, 내가 속한 조직이 그러한 방향으로 진화하고 있는 조직인지? 그러한 문화나 방향성을 이해하고 있는 조직인지에 대해서는 또 다른 고민을 하게 할 것이다.소프트웨어 개발의 가장 근본적인 원칙은 ‘특정 형식에 얽매이는 행위야 말로 삽질이다’라는 말로 이번 이야기의 마무리 말로 정리하겠다.

Overview지루한 작업은 저와 어울리지 않습니다. 한마디로 귀차니즘이 가득한 개발자입니다. 반복적인 일을 하고 있으면 딴 생각이 많이 떠오릅니다. 특히 개발 과정은 쿼리를 작성하고, 프로그램에 적용하고, 검증하는 일이 자주 발생하는데 필요 이상으로 내 시간을 낭비한다는 생각이 들었습니다. 매번 다시 작업해야 하는 쿼리의 조합을 책상 서랍에 착착! 정리해둔 물건처럼, 코드도 언제든 쓸 수 있게 착착! 준비해두면 시간도 절약되고, 업무도 편리해지지 않을까요. 도대체 최종 결과는....?개발언어를 PHP로 전향하면서 제일 오래 걸리는 부분은 프로그램에서 발생하는 쿼리를 다시 조합하고, 검증하는 작업이었습니다. 프로그램에 사용하는 조건을 체크하고, 대입되는 변수들을 체크하고, 치환할 부분에 넣어주는 작업을 반복해야 하고, 야근하고, 건강 잃고… 쿼리가 정상적으로 조합되지 않으면 어느 부분이 틀렸는지 매번 확인해야 합니다. 이 번거로운 작업을 안드로이드 개발에서 사용하는 logcat 같은 기능으로 만들면 좋을 것 같았습니다. 그래서 PHP용 Log 프로그램을 간단하게 만들기 시작했습니다.Logcat 화면, 한결 보기 편해 보인다. ㅂㄹ개발 컨셉손으로 쓱쓱 그려 보았습니다.PHP 쿼리 요청 코드// sql 디버깅 코드: 쿼리 시작 if (ENVIRONMENT == 'testing') {     if(function_exists('localDebugger')) localDebugger( 'sql_start', "0,".$sql);  } // Run the Query if (FALSE === ($this->result_id = $this->simple_query($sql)))  {     // 소스 생략     if ($this->db_debug)      {              // 소스생략 ...            $this->trans_complete();              // sql 디버깅 코드: 쿼리 에러           if (ENVIRONMENT == 'testing') {               if(function_exists('localDebugger'))  localDebugger( 'sql_error', '0, -- Error  Number: '.$error_no  ."\n--  message: ".$error_msg."\n");           }              // 소스생략 ...      }     return FALSE;  } // 소스 생략 // sql 디버깅 코드: 쿼리 종료 if (ENVIRONMENT == 'testing')  {     if(function_exists('localDebugger')) localDebugger( 'sql_done', ($em + $es) - ($sm + $ss).",");  } PHP 디버그 서버에 요청 코드$callNo = time();           /**           *로컬서버에 디버깅 메세지           * 지정된 서버에 디버깅 메세지 전달           * @access public           * @author BoseungChun           * @param string $message   디버깅할 메세지           */ function localDebugger( $type, $message ) {           global $callNo;           //debugger server           $url = 'http://127.0.0.1:3000';           $ch= curl_init($url);            // 요청 파일 분석           $trace= debug_backtrace();           $fileName= substr( $trace[1]['file'],strrpos($trace[1]['file'], '/') );           $line= $trace[1]['line'];           $fileName2= substr( $trace[2]['file'], strrpos($trace[2]['file'], '/'));           $line2= $trace[2]['line'];             // POST로 로깅 서버에 메세지 전달            curl_setopt($ch, CURLOPT_POST, 1);           curl_setopt($ch, CURLOPT_POSTFIELDS, $callNo.' '.$type.' '.uri_string().' '.$fileName2.':'.$line2."\n".$fileName.':'.$line.' '.$message);           curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);           $response = curl_exec($ch);           curl_close($ch);     } nodejs 일부 코드 // 서버 기동 const http = require('http');   const hostname = '127.0.0.1';  const port = 3000;   const server = http.createServer((req, res) => {       res.statusCode = 200;       res.setHeader('Content-Type', 'text/plain');       var body = '';       req.on('data', function (chunk) {           body += chunk;       }).on('end', function () {           var pos = body.indexOf(' ');           var no = body.substring(0, pos);           body = body.substring(pos+1);           pos = body.indexOf(' ');           var type = body.substring(0, pos);           body = body.substring(pos+1);           pos = body.indexOf(' ');           var uri = body.substring(0, pos);           body = body.substring(pos+1);           pos = body.indexOf(' ');           var file = body.substring(0, pos);           body = body.substring(pos+1);           pos = body.indexOf(',');           addSqlBlock( no, uri, file, body.substring(pos+1), body.substring(0, pos), type );      })      res.end('');  });   server.listen(port, hostname, () => {       console.log('Server running at http://${hostname}:${port}/');   }); // 코드 생략   function addSqlBlock( no, uri, file, sql, ms, type ) {      // UI를 구성해서 코드 블럭를 관리하는 태그에 붙여준다.   } 코드는 위의 코드와 같이 간단한 것들을 사용했습니다. 아래의 이미지는 nodejs를 이용해서 디버깅 메시지를 받을 서버를 만들고, 포트를 열어둔 것입니다. 정리하면 PHP 코드에서 발생하는 쿼리의 최종 내용을 디버깅 서버에 HTTP post 방식으로 전달해주는 구조입니다. 코드는 몇 줄 안 되지만, 꽤나 강력한 도구가 만들어졌습니다."어때요. 참 쉽죠?"짜란~~~ Logger 베타 버전이 도구는 페이지를 요청하는 즉시 쿼리가 잡힙니다. 어떤 페이지 요청에서 어떤 쿼리가 발생하는지 쉽게 분석할 수 있으니 번거롭게 쿼리를 조합하는 과정은 자연스럽게 사라졌습니다.색상으로 쿼리의 속도를 표현했다.이 프로그램의 제작자이지만, 유일한 사용자이기도 합니다. 불편한 게 느껴지면 바로 수정해야 했습니다. 어렸을 때 학습지 좀 풀었던 실력으로 알아서 척척척 스스로 기능을 보강했습니다. 위의 이미지처럼 색상만 추가해도 쉽게 분별할 수 있습니다. 쿼리 실행시간을 추가해 어떤 쿼리가 병목을 잡는지도 빠르게 찾을 수 있습니다.PHP 요청 패스를 넣었더니 개 이득!디버깅에 유용한 정보까지 추가했습니다. 요청된 경로, 쿼리가 실행된 파일의 이름, 라인 위치 모델을 요청한 상위 파일의 이름과 라인 위치를 추가해 트래킹을 보강했습니다. 이쯤 되니 거의 절대반지급입니다. 쿼리 이즈 마이 프레셔스..개발에 필요한 정보들이 노출되니 기쁘지 아니한가!이외에도 현재까지 아래의 기능들을 추가했습니다.쿼리 카피 기능과 신텍스 하이라이트, 쿼리 라인쿼리 에러 메시지 로깅url 요청 단위로 쿼리 묶어주기시간이 지난 쿼리 자동 지우기키워드 검색 기능필요한 걸 직접 만들어 사용하는 것이 귀찮을지도 모릅니다. D.I.Y도 아닌데 말입니다. 하지만 자신의 개발 능력을 활용해 업무 환경을 개선하고, 개선된 만큼의 시간을 다시 투자해 선순환 구조를 만든다면 행복한(?) 개발이 될 거라 생각합니다. (=더 많은 일을 하게 되는 건 안 비밀)오늘은 업무 전, 반복 작업을 개선하면 어떨까요. 참고(사용기술)nwjsPHP (codeigniter)CSS3 + HTML5JQuery글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #기업문화 #조직문화 #업무환경 #인사이트 #경험공유

Story #22. 매일 새로운 삶을 사는 라이더라이더 '저스틴'을 소개합니다.간단한 자기소개를 해줘!음... 한국에서는 주관식이 어렵다니까;;나는 30살 늦각지에 독립해서 자유를 만낀하며 살고있는! “저스틴” 이라고해저스틴이란 사람은 굉장한 열정을 가지고 항상 새로운 분야에 도전하려하고 많이 부딪치고어려움을 겪기도 하지만 많은 어려움속에서 경험을 통해 새로운것을 하고자 하는 사람이야.아띠는 어떻게 알게 되었어?아띠 인력거는 2013년. 10월 kbs파노라마에서 방영된 김난도 교수 내일이라는 프로그램에서 아띠인력거가 소개되면서 처음 알게 되었어. 언젠가 한번은 꼭 인력거를 타봐야겠다는 생각에 손님으로 인력거를 체험한 이후 손님이 아닌 직접 라이더가 되서 북촌 방문하는 사람에게 북촌 곳곳 숨은 명소와 재미난 이야기를 소개하고 싶어서 라이더를 지원하게 되었어왜? 손님으로  먼저 인력거를 탔어? 바로 지원해도 되잖아?간접적으로 느끼는거랑 직접적으로 느끼는거에 차이가 있었어! 경험했을때 생각보다 훨씬더 인력거의 매력에 매료되더라고. 매력이 무엇이었어? 내가 강남사람이라 그런지 모르겠는데 종로라는 공간이 너무 매력적이었어.서울이란 곳이 도시화되어 옛 정취를 느끼기 어려운지만 도시화된 사회속에서 새로운 역사와 . 한옥을 느낄 수 있고. 옛것을 느낄 수 있는곳으로 많이 놀러왔었어손님으로 탔을때 어떘어?아띠 라이더랑 북촌을 둘러보니 평소에 그냥 지나갔던 곳도 다시 보게 되었고, 정말 숨은 명소가 많다는 걸 알게되었어. 그래서 나같은 사람들에게 소개해 주고 싶어서 라이더가 되게 되었지저스틴을 손님으로 태웠던 라이더가 포레스트였다는데?응 포레였어. 그때 너무 궁금한게 많아서 포레에게 질문을 많이 했었지. 나중에 안 이야기지만 내가 혼자와서 혼자타서. 코치코치 많은걸 물어봐서 내가 스파이인줄알고 조심스럽게 이야기 했다고 하더라구포레랑은 언제 탔던거야? 2014년 2월~3월 정도 되었던거 같은데.  전화로 예약을 했을때 전화로 ij에게 인력거를 타고 싶다고 했어. 근데 ij가 지방출장중이라 새로지정된 포레로 타게 되었지. 면접은 누가 봤어?IJ랑 1:1로 면접을 봤어. IJ가 이러더라구 “잠깐 나가실까요? 걸으면서 면접 보시죠”IJ의 첫인상은 어땠어?이사람 뭐지? 뭘까? 티비에서 보던 그분이구나. 그 사람이구나.인터뷰를 이어가면 이어갈 수록 일반적인 사람이랑 다른 생각을 가지고 있구나. 상식을 깨는 사람이구나.면접은 어땠어?보통 인터뷰 볼때에는 지원사유 여러가지를 물어보지만. IJ의 인터뷰 내용은 자기가 추구하는 인생의 가치를 집중적으로 물어보았던거 같아.직장은 아니지만. 우리가 같이 일했을때 어떤 역할을 하고 기여가치에 대해 집중적인 질문을 받는데. 각 개인이 추구하는 인생의 목표나. 가치에 대해서 많이 물어보았던거 같아.그런것들을 물어봐서 정말 다르구나 느끼게 되었지.  첫 라이딩 어떘어?첫 라이딩은 사실 기억이 잘 안나. 처음에 북촌을 많이 소개시켜주고 싶었는데. 시작하고 나니까. 사람과 사람이 만나는거. 그런것 접점. 사람을 만나면서. 사람들에게 긍정적인 영향을 전파한다 생각했는데. 얻어가는게 많고. 사람들 사는 방식이 매우 다양하구나. 라이딩 하면서 기억에 남는 에피소드는 뭐가 있어?내가 R-3인데 R-3 등급이 되려면 100번 라이딩을 해야 되잔아. 생각해보면 100번 라이딩은 하루를 1번당 평균으로 7팀을 태웠으니 700팀을 태운거야. 1400명을 만난거지.근데 그중에서 기억에 남는 라이딩은대전 여자 태워서 돈 대신 스팸 받았던 이야기인데재작년 추석 연휴 시작되는 날이였어. 잭슨이랑. 야간 라이딩을 하던 중이였는데 지나가는 여성 한분이 짐을 많이 들고 있어서 태워줬어. 그런데 그분이. 고맙다면서 추석 선물 세트. 스팸 3호. 스팸 2개를 꺼내서 팁으로 주셔서 돈 대신 스팸을 받은 적이 있었지 그리고 예전에 아줌마 2분은 태웠었는데  그런데 그 후에 또 다시오셨는데  혼자 오셔서는 1시간 인생 푸념을 하셔서 듣어 드린 적도 있었구그리고 이 인력거가 한국분이 많이 타시지만  해외 이민가신지 20-30년 되신 분들이 오랜만에 고국을 방문하셔서 북촌에 오셔서 한국의 옛 모습을 보시고 감동받고 돌아가시는 모습이 너무 좋았어.마지막으로 북촌 사시는 할머니였는데. 인력거 타고 가는데 할머니가 짐을 무겁게 짊어지고 가시길래. 행선지를 물었는데. 북촌 근처였어. 그 분이 한사코 사양하셨는데. 모셔다 드렸어. 1주일인가. 뒤에 딸을 통해서 할머니가 이런 고마움을 받았다 해서. 음료수 한잔을 전달해 달라해서. 전달 받았던 경험이 이었지저스틴! 몸도 좋고 얼굴도 잘생겼는데 라이딩 하면서 로맨스는 없었어?(그게 쉽지가 않은게.) 많은 사람을 만나며 사사로운 감정을 가질 수 있지만 아띠라는 이름을 달고 하는것이기 때문에 사람들을 만나며 개인적인 감정을 가질 수 있는것을 만들지 않았던거 같아 아띠에 피해를 끼치고 싶지 않고 사람들을 아띠를 통해 만나지만 사람들은 아띠를 만나는 것이기 때문에 아띠에 영향을 끼치고 싶지 않았던거 같아. 나의 오지랖이지. 잡생각이 많았지. 본인은 어떤 라이더인거 같아? 인력거를 타는 동안. 본인이 느낄 수 잇는 가장 편안함? 안좋은 감정, 스트레스를 모두 날려버리고, 인력거를 타는 동안은 가장 편안한 상태가 되는 것 같아아띠가 변화되는 과정을 보았잖아. 어때? 어땠어?뭔가 젊은 친구들이 모여서 열정과 에너지를 쏟는 것을 보면서 감동도 받았지만. 성장하면서. 어려운 부분도 많고. 어려운 점도 많았을텐데. 50명이라는 라이더로 성장한게. 아띠인력거라는 회사가 사람들에게 좋은 인식과 윤리적인 행동을 하고 있다는 것을 느꼈어. 하지만 앞으로 가야할 길이 많다는 거. 노력해야 할게 많아.변화되는 모습에 항상 놀라워. 2년. 3년 시간에 많은 라이더가 일하고 있고. 무엇보다도 라이딩하는 친구들이회사 정규인원으로 속해 일하는게 아님에도 불구하고. 라이더 한명 한명이 아띠에 대한 애정과 애착을 가지고 있는 것을 보면 더 많은 성장을 할 수 있는 아띠라고 생각해.  아띠가 어떤 영향을 준거 같아?사회생활 하면서. 되게. 로직한. 제너럴한 삶을 살뻔 했는데. 아띠를 만나면서. 정말 내가 인생에 있어서 추구해야할 가치가 무엇인지 되돌아 보게 한. 단순히 내가 돈을 벌며 일을 하는 것 이상으로 내가 무엇을 해야 행복할 수 있고. 가치 있는 삶인지 일깨워 주는 곳. 저스틴에게 아띠란?1.o2. 산소다. 일상생활 속에 지쳐있을 때 숨 쉴수 있는 공간. 활력소가 되는.인력거를 타는 순간 원 없이 즐기고, 한 없이 웃고, 행복할 수 있는.2. 행복한 놀이터다. 원없이 즐기고 갈 수 있는. 무언가. 힐링과 재미를 느낄 수 있는. 마지막으로 아띠에게 바라는 점?사람들한테 앞으로도 계속 좋은 인상과 좋은 경험을 전달할 수 있는 아띠의 처음 모습 그대로 끝까지 남아있었으면 좋겠어. 아띠 화이팅이야!!아띠의 원년멤버로써 아직도 힘차게 페달을 밟고 있는  매일매일 새로운 삶을 사는 라이더, 저스틴의 스토리였습니다:)아띠를 직장이 아니라 행복한 놀이터라고 생각하는 저스틴이검은 머리 파뿌리 될때까지 힐링과 재미를 느낄 수 있는 아띠는 그런 공간이 되고 싶습니다!!

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

IoT의 관점과 함께 최근에 주목을 받는 시계열 DB들이 있다. OpenTSDB나 인플럭스 DB, Graphite와 같은 것들이다. 신기한 것은 최신의 기술이나 플랫폼이라고 불리는 것들은 국내에서는 거의 등장하지 않는다. 대부분 미국이나 유럽, 이제는 중국이나 러시아에서 등장한다. 물론, 일본에서는 새로운 언어도 많이 등장했다.집안의 전기 사용량을 측적하건, 공기 측정이 되었건 1초에 한번 측정하는 센서에서 만들어지는 데이터를 자세하게 분석하려면 이 데이터를 수집하고 모아야 한다. 그리고, 최소 연단 위 정도는 모아서 무언가를 분석하거나 추이를 살펴보아야 할 것이다.더군다나, 센서가 하나가 아니라 여러 개 라면 모여지는 데이터의 량은 상당할 것이다. 기존의 RDB에 축적하는 것은 이런 경우에 좀 맞지 않는다. 데이터가 계속 용량을 늘려나가는 구조이기 때문에 NoSQL형태의 데이터 스토어를 생각하게 된다. 코치이건 하둡이건 몽고이건 여러 가지가 생각난다. 실시간으로 추적 분석하려면 Apache Storm이나 spark도 생각날 것이다.일단, 센서가 시간의 추이에 따라서 데이터를 모으는 형태에 적합한 시계열 DB에 적합한 방법들에 대해서 나름 적합한 형태로 개발되는 구조를 가진 DB들을 어렵지 않게 찾아볼 수 있다. 이 글 가장 앞에 언급한 것들이다.관련 자료를 찾아보고 싶으면, OpenTSDB는 http://opentsdb.net , InfluxDB는 https://influxdb.com을 찾아보라. 나름 매력적으로 시계열 형태의 데이터를 모으기 좋은 구조로 디자인되는 설루션을 만날 수 있다.오늘 글에서 언급하고 싶은 것은... 이러한 특정 요점에 맞는 설루션들이 왜? 국내에서는 나타나지 않는가에 대해서 끄적거려 보고 싶어서이다. 과연, 이러한 태도와 행동, 행위가 특정 개발자의 탁월함 때문일까? 아니면, 국내에 있는 개발자들이 게으르고, 자신의 이익만을 위해서 일하는 것 때문일까?삐딱한 아키텍트는 그 부분을 이렇게 해석한다.하나. 잉여가 없는 부가가치가 적은 일을 매번 수행하는 국내의 경영자들의 문제.둘. 반복적인 작업이나 자신의 일의 미래에 대해서 큰 관심 없는 개발자의 자세셋. SI형태로만 진행되는 국내 프로젝트이기 때문에 만들어진 플랫폼이나 유틸리티 성의 서비스를 외부에 오픈하지 못하는 경우가 빈번함.이 3가지의 가장 큰 이유 때문에 국내에서는 특정 용도나 특정 의미의 환경에 잘 어울리는 설루션들이 오픈소스로 발전되고, 더 넓게 쓰이는 플랫폼까지 진화하지 못한다고 생각한다. 하나씩 나름대로 이유를 이야기해보자.하나. 잉여가 없는 부가가치가 적은 일을 매번 수행하는 국내의 경영자들의 문제일단, 부가가치가 높은 소프트웨어나 서비스를 개발한다면, 적절하게 배분되어진 팀과 일정, 부가가치가 높기 때문에 피드백을 통해서 품질을 높이기 위한 시도들이 반복되어진다. 하지만, 대부분 1회성으로 끝나거나, 단기적인 일거리를 해결하기 위해서 소프트웨어를 개발하는 경우가 대부분이기 때문에 사소한 잉여도 발생하기 어렵다.고품질을 지향하는 소프트웨어 개발을 추구한다면 매우 당연하게 잉여시간과 잉여 일정, 잉여인력이 투입되는 것이 정상이다. 매우 당연하게 소프트웨어 개발자들은 게으르기 때문에 반복적인 일을 싫어하고, 게으르기 때문에 소프트웨어의 품질을 높이기 위해서 공을 들인다.이런 게으른 소프트웨어 개발자들이 품질 높이기를 포기하는 이유는 간단하다. 그 소프트웨어가 재사용될 가능성이 거의 존재하지 않고, 또다시 요구사항에 따라서 난도질을 해야 하는 경우에 품질 높이기를 시도하지 않는다.결론적으로 소프트웨어 개발자들이 고품질을 만들지 않는 이유는 처음부터 비즈니스 기획과 부가가치에 대한 이윤과 투입되는 비용에 대해서 잘못된 비즈니스 모델을 만든 기획자나 경영자가 그 책임을 져야 한다. 물론, 그런 환경을 주었더라도 잘못된 개발자를 뽑은 '인력관리'의 미스에 대해서도 그 역시... 경영자가 책임져야 한다.대부분 고품질의 소프트웨어가 나타나지 않거나, 잉여가 만들어지지 않는 이유는 경영자가 미 숫하고, 비즈니스 모델을 잘못 디자인해서 그러하다.둘. 반복적인 작업이나 자신의 일의 미래에 대해서 큰 관심 없는 개발자의 자세하지만, 경영자의 잘못과 거의 비슷한 수준의 개발자의 관심 없는 자세인 경우가 문제가 되는 경우도 많다. 잉여가 주어졌음에도 빈둥거리거나, 자신만의 놀이를 위해서 그 시간과 비용을 투자하는 경우도 간혹 있다. 하지만, 필자가 만나본 대부분의 개발자들은 그런 자세가 된 소프트웨어 개발자의 행태 또한 그 소프트웨어 개발자가 걸어온 그 전회사의 경영자의 문제라고 지적하고 싶다.반복적인 일을 줄이고, 미래의 코드에 대해서 신경 쓰는 자세는 소프트웨어 개발자가 기본적으로 갖추어야 하는 자세임에도 불구하고, 이러한 자세를 파괴하는 형태의 업무 구조와 생각 자체를 파괴하는 형태로 일을 구성하는 경영진과 같이 일한 개발자들은 슬프게도 잉여를 빈둥거리게 하는데 익숙하게 된다.필자가 개발자 구인 시에 가장 주목하고, 관심을 가지면서 걸러야 하는 개발자는 그러한 회사를 거쳐왔거나 그러한 프로젝트에 매몰되었던 사람들은 피하는 것이다. 한번, 그런 자세가 파괴된 개발자는 다시 자세를 정상으로 복구하는데 엄청난 리소스와 시간이 투입된다.냉정한 사람들이라면 이러한 사람들을 '동료'로 받아들이는 것을 싫어할 것이다.셋. SI형태로만 진행되는 국내 프로젝트이기 때문에 만들어진 플랫폼이나 유틸리티 성의 서비스를 외부에 오픈하지 못하는 경우가 빈번함.슬프지만, 3번째의 경우가 사실은 한국에서는 50% 이상 의미 있는 형태로 개발되었음에도 불구하고, 사장되거나 외부에 노출될 수 없는 형태가 되는 경우를 빈번하게 경험했다. 필자 역시, WebService개발 초기에 3 Tier개발에 어려움을 겪는 개발자들을 위해서 SQL 문장을 그대로 WebService에서 CRUD형태로 전송하고 데이터셋과 DB커서를 2 Tier의 형태로 손쉽게 개발할 수 있는 플랫폼과 컴포넌트를 개발했지만, 이 역시, SI에 종속된 결과물이 되면서 외부에 오픈할 수 없는 경우가 되는 것을 빈번하게 경험했다.슬프지만... 이 3가지의 큰 이유 이외에도 '잉여'가 없는 개발 일정이나 개발자에게 여유가 없어지면서, 정말 더럽게 재미없는 소프트웨어 개발이 반복되는 경우를 많이 보았다. 하지만, 필자의 경험은 그럼에도 불구하고 개발을 총괄하고 있다면, 자신의 팀에 있는 개발자에게 약간의 잉여와 고품질을 위한 리소스에 대한 배려를 취하면서 동료직원이 오픈소스를 창출하거나 외부에 오픈할 수 있는 정도의 다듬는 여유를 만들어 줄 수 있다고 생각한다.가장 훌륭한 CTO나 개발 총괄의 역할은 그 시간을 정말 즐겁다고 생각하는 동료 개발자에게 약간의 잉여와 여유를 허가하는 것이며, 그 잉여가 결론적으로 자신이 속한 개발 조직의 효율이 향상되고, 개발 문화가 부드러워지는 아주 의미 있는 개발 조직으로 완성되어가는 첫 번째 단추라는 것을 알기를 바란다.현재 훌륭한 개발 조직일수록, 카페와 같은 공간만을 만드는 것만으로 끝나는 것이 아니라, 개발 공정이나 개발 프로세스 상에 리뷰와 의미 있는 문서화 작업, 피드백과 리팩터링과 같은 시간을 배분하는 이유도 그 때문이라는 것을 잊지 않기를 바란다.훌륭한 하드웨어 적인 공간 위에 재미를 추구하고 의미를 추구하는 잉여가 존재하는 개발 공정을 탑재한 개발 조직이야말로 성공할 수 있는 전제조건을 하나 더 갖춘 곳이라는 것을...

나는 앞으로 무엇을 할 것인가스위처는 더 큰 도약을 위한 준비과정에 있습니다.제가 맡은 마케팅도 아웃바운드/인바운드 라는 2가지 분야로 나뉘어 업무를 진행하고 있습니다.제가 앞으로 쓰려는 분야는 아웃바운드(outbound)로 "어떻게 고객을 유치할 것인가?"에 대한 주제 입니다.목적은 제가 하는일을 복기를 통해 같은 실수를 반복하지 않고 6월30일까지 계속 성장을 하기 위함입니다. (그리고 미래의 마케팅 팀원 안뇽. 나중에 이걸 읽고 우리가 어떻게 일했는지, 어떻게 이런 결과값을 가지게 되었는 지 알아가면 좋을거 같아요.)What그냥 고객을 유치하는것은 아니고, 우리가 생각한 고객 'target 이라고 생각한 고객'을 어떻게 데려오냐가 핵심입니다. product market fit을 맞는지 보는것이죠.난 너만 조진다. (출처 : google image)이를 이루기 위해 저와 광국씨는 6월 30일까지 다양한 아이디어로 컨텐츠를 제작하려 합니다. 가능한 많은 컨텐츠를 가능한 많은 광고를 집행하여 어떤 컨텐츠가 우리가 생각한 target에게 먹힐지 보려합니다.Why현재 스위처는 많은 사람들에게 사랑을 받고 있습니다. ('많다'의 기준은 비밀) 하지만, 저희가 이 많은 분들의 사랑에 대한 보답을 할 순 없습니다. (저희는 작은 스타트업이거든요.) 저희가 할 수 있는 일의 범위는 한정되어 있고 이 한정된 자원을 어떻게 분배해야 하는가는 정말 중요한 문제이죠.Target먼저, 저희가 생각한 target은 '1/2인 가구' 입니다. 1/2인 가구도 엄청 다양하겠죠. 예를 들어) 사는 지역, 주거 형태, 취향, 소득수준, 직업 분야, 결혼유무 등등 엄청나게 다양합니다. 그 중에 핵심은 1/2인 가구. 그 뒤에 붙는 수식어구 역시 저희가 채워나가는 과정에 있다고 볼 수 있습니다.Target Fit Contents그래서 저희는 저 Target에 맞는 컨텐츠를 만드려구요.(그걸 Target Fit Contents, TFC라 부를거에요.) 작게 작게 하나씩 해보면서 어떤 컨텐츠가 1/2인 가구들의 관심을 받는가? 를 확인합니다. 물론, 이러한 컨텐츠의 근거는 다 고객의 목소리입니당. ( 더하기, 저희의 인사이트 겠죠)페이스북을 통해 다양한 사용 환경/목적을 말해주셔서 감사합니다.(이러한 고객의 목소리는 광고 제작뿐만 아니라 제품 개발에도 필수인 것은 그냥 한번 말해봅니다. 워낙 중요하니깐..)이러한 의견을 통해 "A란 주제로 컨텐츠를 만들어 봅시다.", "그 A란 주제에서 포인트는 ~가 있으니 이것들을 나눠서 광고를 집행하고 결과를 지켜 봅시다." 란 식으로 컨텐츠 생산의 방향을 잡고 진행합니다.이미 2주가 늦은 상황이라, 부지런히 쓸게요. 뭐든 처음이 쉽지 꾸준함이 어려운거니깐요.#스위처 #Switcher #콘텐츠 #콘텐츠마케팅 #마케팅 #마케터 #인사이트 #일지

지난 5월, 세계 최대 P2P금융 컨퍼런스인 렌딧 컨퍼런스(Lendit Conference)의 창업자 제이슨 존스(Jason Jones)가 필자의 회사인 렌딧 사무실에 방문했다 (필자의 회사 렌딧은 이 컨퍼런스와는 무관하다). 아시아의 P2P금융 산업 동향을 살피기 위해 일본, 중국, 싱가폴을 방문하는 일정 중에 한국 시장 환경 파악을 위해 서울 을지로입구에 위치한 렌딧 본사에 방문한 것이다.제이슨 존스, 출처: LendAcademy.com매년 미국과 영국, 중국에서 개최되는 렌딧 컨퍼런스에는 전세계에서 5천명 이상의 업계 전문가들이 모인다. 4차 산업혁명의 대표 주자인 P2P금융은 영국에서 시작된지 12년이 지난 지금도 아주 빠른 속도로 성장하며 발전하고 있다. 이러한 변화와 산업 동향을 가장 빨리 파악할 수 있는 곳이 바로 렌딧 컨퍼런스다.제이슨과의 대담 중, 그가 한국 P2P금융 시장 환경에 대해 날카롭게 지적한 3가지의 통찰은 다음과 같다 :1. 자기자본 대출을 허용해야 한다.이야기를 나누며 제이슨이 가장 놀라워 한 사실 중 하나는 한국에서 P2P금융 기업이 자기자본 대출을 하는 것이 금지되어 있다는 사실이었다. P2P금융 회사가 자기자본으로 대출하는 것을 금지한 국가는 한국이 유일하다. 미국 P2P금융 시장에서는 대출의 30% 가량이 자기자본 대출(balancesheet lending)로 이루어진 뒤 유동화(securitization)를 통해 시장에서 소화된다.해외의 유수 P2P금융사들이 자기자본 대출을 하는 가장 주요한 이유는 대출고객과 투자고객 모두를 보호할 수 있기 때문이다. 자기자본 대출이 이루어지면 대출자는 심사에 통과한 후 투자자들에 의해 대출금이 모이는 시간을 기다리지 않고 곧바로 대출을 받을 수 있다. 중금리 대출을 받을 수 있는 사람이 대출금이 모이는 시간을 기다리지 못해 고금리 대출로 향하게 되는 상황을 막을 수 있는 것이다. 투자자 역시 대출이 집행된 다수의 채권으로 이루어진 자산에 투자금을 잘게 쪼개어 분산 투자할 수 있어 투자 안정성을 높일 수 있다. 이와 같은 이유로 2010년 이후 등장한 세계적인 P2P금융 기업 중에는 100% 자기자본 대출 방식으로만 운영하고 있는 곳들이 다수 존재한다.2. 전문 사모펀드의 대리 투자를 허용해야 한다.각국의 P2P금융 시장에서 개인신용대출의 비중이 절반 이상을 차지하는 것은 전세계 공통적인 현상이다. 제이슨은 한국에서만 유독 PF 대출의 비중이 높은 것은, 전문 사모펀드의 본격적인 P2P 투자가 이루어지지 않고 아직까지 개인 투자자들이 주요한 시장 참여자이기 때문인 것으로 분석했다. 개인 투자자들은 전문 금융 기관에 비해 투자 위험도 분석 능력이 떨어질 수 밖에 없다. 따라서 개인 투자자 보호를 위해서 전문적인 금융기관의 대리 투자가 허용되어야 한다는 것이 그의 지적이었다.3. 자산 특징에 맞는 세분화된 규제가 필요하다.제이슨은 한국에서 P2P금융 산업이 본격적으로 발전한 지 2년 반 만에 전체 시장 참여 규모가 1조원이 넘었다는 사실을 듣고 상당히 놀라워했다. 하지만 더욱 놀라워한 사실은 이렇게 급속히 발전하고 있는 시장을 하나의 획일화 된 방식으로 규제하고 있다는 점이었다. P2P금융에서 대출 자산은 은행의 그것과 같이 매우 다양하다. 따라서 은행 및 다른 금융업체들의 대출 자산과 마찬가지로 대출 자산의 특징에 따라 세분화된 규제가 필요하다. 동일한 투자 금액을 1,000개의 채권에 분산 투자할 수 있는 개인신용 대출 자산과, 10개의 채권에 분산 투자할 수 있는 법인 혹은 부동산 대출 자산을 동일한 기준으로 규제하는 것은 논리적이지 않다. 당연히 투자자 보호의 측면에서도 취약할 수 밖에 없다.해가 갈 수록 가계부채가 심각해 진다는 뉴스가 흘러 나오고 있다. 정부에서도 이를 해결하기 위한 대책 마련에 힘쓰고 있다. 이와 같은 때에 P2P금융은 이미 제2금융권과 비교했을 때 약 10% 이상의 낮은 금리로 대출을 제공하며 가계부채 질적 개선의 새로운 방편으로 떠오르고 있는 중이다. 반면 매우 빠르게 발전해 시장이 비대해지고 있다는 측면에서 P2P금융 산업에 대한 강한 규제가 필요하다는 사실은 부정할 수 없을 것이다. 그러나 P2P금융은 여신과 중개가 융합된 새로운 금융 산업이다. 4차 산업혁명 시대의 대표 주자로 손꼽히는 P2P금융을 전통적인 금융의 시각에서 규제하는 데에는 한계가 분명히 있을 것이다. 규제의 당위성에 앞서, 새로운 산업이 올바르게 성장하기 위해서는 산업의 본질에 맞춤화된 세밀한 규제 도입이 시급하다.

글을 시작하며, 제가 이 글을 쓸까 말까? 망설였던 이유에 대해 이야기하고자 합니다. 저는 마케팅이 좋아서 대학교 때부터 본격적으로 마케팅 관련 공부와 활동을 시작했고, 지금도 그것을 꾸준히 이어오고 있으며, 현업에서 마케팅 담당을 한 지 4년을 넘어가고 있는 사람입니다. 다시 말해 지금까지 쌓아왔던 경험과 시각은 학생과 사원-대리급에 지나지 않고 많이 부족하다는 것을 잘 알고 있으며, 그래서 함부로 다른 서비스의 마케팅 사례들을 속단해서는 안 된다는 것도 알고 있습니다. 그럼에도 불구하고, <컨텐츠 마케팅의 한계와 극복 방법에 관하여>라는 글을 쓰려고 하는 이유는, (1) 그만큼 마케팅, 그리고 컨텐츠를 사랑하기 때문에 (2) 이렇게 컨텐츠 마케팅을 생각하는 사람도 있다는 것을 보여주고 싶기 때문입니다. 이 점을 먼저 이야기하면서 글을 시작하겠습니다. 난리를 치른 직방과 한국 일보, 무엇이 문제인가? 최근 페이스북을 보다가 경악스러운 (정말 경악스럽다는 표현밖에는 할 수가 없음) 컨텐츠를 두 개 보았는데, 하나는 직방에서 올린 웹툰이었고, 또 다른 하나는 한국 일보에서 올린 동영상이었습니다. 먼저 직방의 컨텐츠를 대략 요약하자면 아래와 같습니다. 인터넷에 돌고 있는 '자취방 썰'을 브랜드가 노출될 수 있도록 웹툰으로 재가공한 컨텐츠였는데, 문제는 (1) 이 컨텐츠를 보고 브랜드에 대해 일말의 긍정적인 느낌 (유용하다, 직방을 써야겠다 등)을 주지도 않고 (2) 브랜드 컨텐츠에 쓰기에는 내용과 표현 방식이 적절치 않았다는 점입니다. (풀 내용은 관련 기사 ◀링크 참고) 이에 직방은 사과문을 올렸지만, 돌아선 소비자들의 마음까지 어루만지지는 못했습니다. (직방의 사과문 ◀ 이것도 링크 참고)이 동영상도 페이스북을 보다가 경악했던 영상인데, 한국일보에서 올라왔던 <중국 놀이기구 사고> 영상입니다. 현재는 영상을 삭제한 것으로 보이는데, 이것에 대해 문제제기를 하면서 캡처를 해둔 것이 있어 위에 첨부했습니다. 문제가 되는 지점은 (1) 자극적인 카피 → 사고가 난 것인데, '한 소녀가 놀이기구에 대.롱.대.롱 매달린 채 돌아가고 있다"는 너무한 문구이며, (2) 실제로 놀이 기구가 고장이 나서 소녀가 사고를 당해 사망을 하였는데, 이 장면을 모자이크 없이 그대로 올렸고 (3) 무엇보다 이것을 '한국일보' 페이지가 올렸다는 점이 충격적이었습니다. 이것은 우리에게 경각심을 주는 내용도 아니고 (단지 사고가 이렇게 났다, 는 사실을 보여줄 뿐) 페이스북은 미성년자도 볼 수 있기 때문에 사실 전달 이외에 큰 교훈이 있는 것도 아닌 영상을 이렇게 올리는 것은 분명 잘못된 일이었습니다. 왜 이런 일이 일어났을까? 이 두 케이스를 보면서 "왜 이런 일이 일어났을까?"를 생각해보았을 때 크게 3가지 요인이 있는 것 같았습니다.첫 번째는 컨텐츠의 특성을 간과했기 때문입니다. '사람들에게 긍정적인 반응을 불러일으키는, 좋은 컨텐츠'라 함은 감동, 재미, 정보 3가지 요소가 들어갑니다. 그리고 이러한 좋은 컨텐츠들은 제가 굳이 예시를 들지 않아도 이젠 너무나도 쉽게, 많이 볼 수 있습니다. 그러나 위 2가지 사례(직방과 한국일보)에서는 이 3가지 요소를 찾아볼 수 없습니다. 어떠한 감동도 없고, 재밌지도 않고, 정보도 없습니다. 두 브랜드에서는 이 점을 간과했던 것 같습니다. 두 번째는 SNS의 특성에 관한 이야기입니다. SNS 세상은 "내가 공유하는 것 = 나"인 세상입니다. 자신의 전문 분야에 관련된 정보를 많이 공유하면 '전문가'로 금방 인식되는 경우를 많이 보셨을 것입니다. 이걸 다른 말로 하면 감동적인 컨텐츠를 많이 공유하면 '나 이렇게 감수성이 풍부한 사람이야'를 보여주는 것이고, 웃긴 컨텐츠를 많이 공유하면 '나 이렇게 재밌는 사람이야'로 포지셔닝된다는 것이지요. 이렇게 '내가 공유하는 것 = 나'로 인식되는 세상에서 무섭고, 잔인하고, 자극적인 컨텐츠를 공유하면서 '나 이렇게 잔인한 걸 봐도 아무렇지 않은 졸라 쎈 사람이야'이라고 자신을 표출하는 사람은? 사이코패스가 아닌 이상, 그럴 리가 없을 것입니다. 나의 실명과 이름, 행동 로그가 공유되는 SNS, 특히 페이스북에서 대놓고 이런 행동을 하기는 매우 어렵죠. 이런 관점에서 봤을 때도 직방과 한국일보는 SNS 세상의 특성을 잊어버렸던 것으로 보입니다. 마지막으로 지나친 성과주의를 이야기하고 싶습니다. 다른 나라에서 안 살아봐서, 일해보지 않아서 우리나라만의 특성인지 모르겠으나, 우리나라에서는 SNS 운영에도 성과주의가 적용되는 경우를 심심치 않게 봅니다. '결과만 잘 나오면 뭐든 올려도 된다'는 생각이지요. 위에서 쪼아서, 달성해야 하는 목표가 있어서, 등등 나름의 이유는 있겠습니다만 무엇이든지 '숫자'로 보이는 것을 좋아하는 조직이라면 SNS 운영을 할 때에도 이런 성과주의에서 벗어나기 힘듭니다. 왜냐면 SNS야말로 숫자로 눈에 드러나기 딱 좋은 곳이니까요. 공유 수 몇 건, 동영상 재생 수 몇 회, 이런 게 외부에 보이다 보니 뭐가 됐든 일단 반응만 많이 나오게 해보자, 고 맘만 먹으면 그렇게 하기 쉽죠. 아마 위 두 케이스도 성과주의에서 자유롭지는 못했을 것 같습니다. 그렇다면 어떻게 해야 할까? 첫째는 SNS 운영을 잘 한다고 해서 다가 아니라고 생각해야 합니다. 아이러니하게 들릴지 모르지만, 페이지 팬 수가 10만이 되든 20만이 되든, 동영상 재생이 5만 건 되든, 10만 건이 되든, 좋아요가 1만 개든 10만 개든. 그것만 보고 있으면 안 된다는 말입니다. 이 브랜드에서 컨텐츠 마케팅을 하는 이유가 무엇인가? SNS 운영을 통해 무엇을 얻을 것인가? 다음 단계, 합의가 있어야 합니다. 그런데 이다음 단계를 규정할 때에는 '브랜딩' 혹은 '인지도 상승'처럼 두루뭉술하면 안 됩니다. 그런 목표라면  앞서 말한 성과주의에 빠지기 쉽습니다. "SNS를 통해 우리 브랜드를 인지시키고 사이트에 유입시킨다, 혹은 회원 가입시킨다" 같이 SNS 운영 다음의 구체적인 마케팅 목표가 있어야 합니다. 이것을 다양한 요소로 SNS 여기저기에 녹여야 하며, 그 결과가 어떤지도 추적해야 합니다. 예컨대 SNS 컨텐츠를 보고 앱을 다운 받는 게 목표라면 SNS 컨텐츠에 앱 다운로드 유도 장치가 있어야 하며, 이것에 대해 사람들이 얼마나 반응을 했는지 SNS 컨텐츠 자체의 결과와 대비해서도 봐야겠지요. 둘째는, SNS 운영 특히 컨텐츠를 만드는 사람에게 '소명의식'이 있어야 합니다. 온라인에 컨텐츠를 올리는 그 순간 누군가 저장할 수도 있고, 캡쳐를 할 수도 있다, 그리고 이것은 내가 알지 못하는 제 2, 3의 공간에 남을 수도 있고, 계속해서 복사될 수도 있다는 생각을 해야 합니다. (이게 되게 무서운 일이고, 스트레스받는 일이지만 감내해야 할 부분이라 생각합니다 ㅠㅠ) 내가 만드는 컨텐츠는 우리 브랜드가 낳은 알이라고 생각하며 이것은 평생 죽지 않는다고 여기는 것이지요. 또한 내가 만든 컨텐츠가 상상 이상의 영향력이 있다는 점을 명심해야 합니다. 나는 개인 타임라인에 내 프로필로 포스팅을 하는 게 아니다, 내 이름의 블로그에 글을 쓰는 게 아니다, 좋아하든 싫어하든 우리 브랜드에 관심이 있는 사람들이 쳐다보고 있는 공개 게시판에 우리 브랜드의 이름으로 컨텐츠를 만들어 올리는 것이다, 라고 늘 자각하고 있어야 합니다. 내가 쓴 글 한 줄로 사람들이 감동을 받기도 하고 상처를 받을 수도 있고요, 힘이 나게 만들 수도 있고 인생을 포기하고 싶어 지게 만들 수도 있습니다. 이런 생각을 하면 결코 쉽게 컨텐츠를 만들 수도, 올릴 수도 없습니다.마지막으로, 내 브랜드 고민, 경쟁사 견제를 하기 전에 사람에 대해 먼저 생각해야 합니다. 우리 브랜드의 컨텐츠를 만드는 것이니까 누구보다 잘 알아야 하는 것 맞습니다. 경쟁사가 하고 있는 마케팅과 차별화되어야 하니까 그들이 무엇을 하는지도 알아야 합니다. 하지만 그전에 어떤 사람들이 우리 브랜드를 좋아하는가? 어떤 사람들이 우리 브랜드를 좋아하게 만들고 싶은가? 그들은 무슨 특성을 가지고 있고, 어떤 이유로 우리 브랜드를 좋아하는가? 어떤 컨텐츠를 좋아하는가? 어떤 음악을 듣고 어떤 글에 반응하는가? 어떤 생각을 가지고 우리 서비스를 쓰는가? 컨텐츠 마케팅 담당자라면 이런 질문에 충분히 고민하고 나름대로의 답을 갖고 있어야 한다고 생각합니다. 컨텐츠를 만드는 사람이 브랜드가 되기보다는 유저가 먼저 되어야 하는 것이죠. 그러다 보면 함부로 컨텐츠를 만들 수 없습니다. 우리 브랜드를 좋아하는 사람들은 이런 거 싫어해, 이런 컨텐츠엔 반응하지 않을 거야, 라는 감이 있기 때문입니다. 글을 시작하면서 말했듯이 저는 아직 많이 부족하고, 그동안 경험한 것보다 앞으로 경험할 일이 더 많은 사람입니다. 하지만 그동안 다양한 브랜드의 SNS를 운영해보고, 현재는 스타트업에서 컨텐츠를 만드는 일을 하면서 제가 해왔던 일, 하고 있는 일에 대해 나름대로 깊은 고민을 해왔습니다. 그리고 애정도 각별하죠. 어디 가서 부끄럽지 않게 SNS 운영을 하려면 어떻게 해야 할까, 다른 사람들은 어떻게 컨텐츠를 만드나, 무엇이 좋다고 느껴지는가, 무엇을 우리 브랜드에도 적용해볼 수 있을까, 매일매일 관찰하고 적용도 해보고 더 나아지려고 노력해왔습니다. 그렇기 때문에 앞서 이야기한 두 브랜드의 사례가 더욱 안타까웠습니다. 내부의 사정은 모릅니다. 대행사 직원이 그랬는지, 담당자가 그랬는지, 인턴이 그랬는지, 팀장이 그랬는지 아무것도 모르죠. 그러나 뭐가 됐든 너무나도 마음이 아픈 사례라고 생각했습니다. 대행사 직원이 그랬다면, 담당자가 그랬다면, 인턴이 그랬다면, 팀장이 그랬다면, 뭐가 됐든 다 안타깝습니다. '포스팅' 버튼을 누르기 전에 한 번만 더 생각했다면, 기획 아이디어를 내기 전에 한 번만 더 생각했다면, 이런 일이 생겼을까 싶고요. 특히나 직방은 스타트업계에서는 소위 성공 사례라고 불리는 브랜드이기 때문에 더더욱 애정 어린 시선으로 보고 있었습니다. 아니 정확히 말하면 부러운 게 많았죠. 설현도 광고 모델도 쓰고, 좋겠다. 하면서요. 그래서 더욱 잘 했으면 좋겠다, 고 기대했던 것도 있습니다. 하지만 이미 일은 일어났고 되돌릴 수 없으니, 이제 와서 할 수 있는 것이라곤 과거의 실수를 복기하고 되풀이하지 않을 방법을 찾을 수밖에 없게 되었네요. 그래서 기록하고 싶었습니다. 아프지만 잊지 말아야 하니까요. 부디 이런 진심을 알아주시길 바라며 글을 마칩니다. SNS 운영도, 컨텐츠 마케팅도 다 좋을 순 없겠지만 지금보다 더 좋을 수 있을 거란 믿음으로.#앵커리어 #마케팅 #마케터 #콘텐츠 #콘텐츠마케팅 #인사이트 #조언 #경험공유

안녕하세요. 스포카 디자인팀 인턴 박소연입니다. 이번 글에서는 사용자 경험User Experience 디자인 과정 중 프로토타이핑Prototyping에 대해 설명해보도록 하겠습니다.Prototyping이란,Prototype이란 “처음”을 뜻하는 그리스어 protos와 “느낌”을 뜻하는 typos가 합쳐져 “원본”, “초기”를 뜻하는 prototypos가 되었고, 이것에서 발전한 “초기 형태”인 prototypon에서 유래하였습니다. (출처: 위키피디아)프로토타이핑의 주목적은 UX 컨셉을 구체화하여 사용자에게 직접 실험을 하기 위한 것입니다. 먼저 조사한 결과를 토대로 아이디어와 컨셉을 도출합니다. 그 이후 실제 모델을 제작하고, 해당 모델에 해당하는 사용자와 전문가에게 사용하게 한 후 의견을 기록합니다. 프로토타입을 제작할 시에는 사용자가 구현될 시스템에 대하여 어느 정도 명확한 심상을 얻을 수 있을 정도의 디테일을 유지하여 제작합니다. 실험 시, 최대한 실제 환경이나 그와 비슷한 상황에서 실험하는 것이 중요합니다. 또한, 실험 중에 전체적인 서비스의 감성의 흐름과 피드백을 기록해야 합니다.프로토타이핑은 크게 두가지로 나누어질 수 있습니다.첫째는 아날로그 프로토타이핑으로, 종이에 연필로 쉽고 빠르게 스케치하는 것이 관건입니다. 두 번째는 디지털 프로토타이핑입니다. Low fidelity 혹은 high fidelity로 제작할 수 있는데, low fidelity는 최소한의 구성요소는 다 갖추고 있는 정도를 뜻합니다. 주로 보여주기용인 파워포인트, 키노트 등으로 구현할 수 있습니다. 발사믹과 같은 프로그램을 사용하여 간단한 인터랙션을 구현할 수도 있습니다. High fidelity는 완성에 거의 가까운 형태로, 장식적인 요소도 모두 포함하여 정확히 제작하게 됩니다. 실험에 적합한 형태를 선택하는 것이 중요한데, 장단점을 표로 정리해서 보여 드리겠습니다.다양한 프로토타이핑 유형:프로토타이핑특징장점단점아날로그프로토타이핑연필과 종이.빠르고 간단하다.수정이 쉽다.구체적이지 않다.구현할 항목이 많을 시오래 걸린다.디지털프로토타이핑-low fidelity보여주기 혹은인터랙션 가능.하나 혹은 다수의프로세스를 표시.수정이 비교적 간단.시스템의 특징을 살리기어려울 수 있다.디지털프로토타이핑-high fidelity인터랙션과 장식적요소까지 구현.가장 구체적이고이해가 빠르다.특징을 모두 구현할수 있다.제작에 오래 걸린다.수정이 힘들다.프로토타입을 제작하고 난 후에는 제작한 모델을 사용하여 실험을 진행 할 수 있습니다. 실험 종류 역시 여러 가지가 있지만, 이번에는 세 가지만 추려서 소개해 드리겠습니다.Desktop Walkthrough말 그대로 책상 위에서 구현할 수 있는 작은 모형을 말합니다. 레고와 같은 3D모형을 이용하여 실제상황의 특징들을 구현합니다. 이를 무대로 삼아, 사용자의 페르소나Persona를 구현한 모형을 직접 움직이며 사용자 경험을 재현합니다. 간단한 모형으로 다양한 사람들이 이해하기 쉽고, 전체적인 프로세스를 포괄적으로 검토할 수 있습니다. 또한, 모형을 여기저기 움직이면서 문제점을 수정하기에 쉽습니다.Service Prototype서비스 프로토타입은 소품과 물리적인 목업mock-up을 이용하여 상세한 서비스를 재현하게 됩니다. 주로 해당 제품을 사용하는 실제 환경과 최대한 비슷한 곳에서 사용자가 직접 사용하고 역할극 등을 진행하게 됩니다. 사용자가 직접 사용하고 만져볼 수 있는 모델이 있기 때문에 사용자가 서비스에 대해 좀더 깊은 이해를 할 수 있습니다.Service Staging서비스 스테이징은 좀 더 많은 인원이 필요합니다. 여러 이해관계자가 지켜보는 가운데 디자이너와 사용자가 함께 프로토타입을 사용한 시나리오scenario를 재현합니다. 역할을 바꾸어 여러 번 반복 재연하면서, 다양한 이해관계자의 피드백을 받을 수 있습니다.프로토타입 실험 요약:DesktopWalkthroughService PrototypeService Staging장소LEGO 모형실험실, 스튜디오, 실제상황실험실, 스튜디오, 실제 상황대상LEGO 모형사용자사용자, 디자이너 등목적시범, 설명이해 도모,사용성 파악사용성 파악, 이해관계 정립,시나리오 점검Conclusion이제까지 UX Design의 과정 중 한 가지인 프로토타이핑에 대해 간략히 설명해보았습니다. 프로토타이핑의 가장 중요한 목적은 사용자들이 직접 체험하고 이해할 수 있도록 최대한 실제와 가깝게 재현하는 것입니다. 하지만 프로토타이핑으로 다양한 실험을 했다고 디자인이 완료된 것은 아닙니다. 수집한 의견을 반영하여 수정과 보완을 거쳐 새로운 프로토타입으로 다시 실험하는 등 응용 범위는 다양합니다. 프로토타이핑은 UX Design에 필수적인 과정입니다. 보통, 디자이너와 개발자들은 사용자들이 자신이 생각한 대로 움직일 것이라고 일종의 “착각”을 하게 되는데, 이는 프로토타이핑을 통해 적절히 조정할 수 있을 것입니다.참고자료 및 이미지 출처:· 서비스 디자인 교과서, 안그라픽스, 2012· http://www.enginegroup.co.uk/site· http://www.loop-ux.com· http://www.davidarno.org/2009/09/17/napkee-converting-balsamiq-mockups-into-flex-views-just-became-a-complete-breeze/· http://inspirationfeed.com/inspiration/25-examples-of-wireframes-and-mockups-sketches/#스포카 #디자인 #디자이너 #디자인팀 #인턴 #인턴생활 #인사이트 #꿀팁 #경험공유

편집자 주: 함께 보면 좋아요!애플리케이션 개발부터 배포까지, AWS CodeStarOverview: 작성 환경AWS CodeStar를 사용하면 애플리케이션의 서버, 언어 , 형상관리, 배포, 빌드까지 한꺼번에 관리할 수 있습니다. AWS를 사용하는 개발자라면 꼭 필요한 도구이기도 합니다. 이번 글에서는 CodeStar를 초기 설정할 때의 도움이 될 내용들을 소개하겠습니다.-서비스: AWS CodeStar-템플릿: Python Webservice, AWS Lambda목차파라미터 바인딩람다 환경변수 설정람다 레이어 설정xray 모니터링 설정람다 함수명 설정Global 섹션로컬 개발환경에서의 SAM 실행CodeStar 프로젝트 생성 후CodeStar로 프로젝트를 생성하면 소스코드와 배포를 위한 Code 시리즈 리소스들이 함께 만들어집니다. CodeCommit, CodeBuild, CodePipeline 등이 있습니다. 우선 기본으로 구축된 파이프라인부터 살펴보겠습니다.CodeCommit 리포지토리의 마스터 브랜치 코드를 변경하면 CodeBuild와 CloudFormaton 서비스를 통해 빌드, 테스트, 배포를 진행할 수 있게 설정되어 있습니다. 생성된 리포지토리의 template.yml 파일을 이용하면 프로젝트 리소스도 관리할 수 있는데, 특히 template.yml을 통해 CloudFormation으로 관리하는 리소스까지도 관리가 가능합니다.기본으로 생성된 template.yml 파일을 자세히 살펴보겠습니다.AWSTemplateFormatVersion: 2010-09-09 Transform: - AWS::Serverless-2016-10-31 - AWS::CodeStar Parameters: ProjectId: Type: String Description: CodeStar projectId used to associate new resources to team members CodeDeployRole: Type: String Description: IAM role to allow AWS CodeDeploy to manage deployment of AWS Lambda functions Stage: Type: String Description: The name for a project pipeline stage, such as Staging or Prod, for which resources are provisioned and deployed. Default: '' Globals: Function: AutoPublishAlias: live DeploymentPreference: Enabled: true Type: Canary10Percent5Minutes Role: !Ref CodeDeployRole Resources: HelloWorld: Type: AWS::Serverless::Function Properties: Handler: index.handler Runtime: python3.7 Role: Fn::GetAtt: - LambdaExecutionRole - Arn Events: GetEvent: Type: Api Properties: Path: / Method: get PostEvent: Type: Api Properties: Path: / Method: post LambdaExecutionRole: Description: Creating service role in IAM for AWS Lambda Type: AWS::IAM::Role Properties: RoleName: !Sub 'CodeStar-${ProjectId}-Execution${Stage}' AssumeRolePolicyDocument: Statement: - Effect: Allow Principal: Service: [lambda.amazonaws.com] Action: sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole PermissionsBoundary: !Sub 'arn:${AWS::Partition}:iam::${AWS::AccountId}:policy/CodeStar_${ProjectId}_PermissionsBoundary' 파라미터 바인딩Parameters 섹션에서는 ProjectId, CodeDeployRole, Stage 등 템플릿에서 사용할 파라미터를 지정할 수 있습니다. yml 파일 안에서는 ${ProjectId} 와 같이 사용할 수 있고, CodePipeline 환경에서 파라미터를 전달할 수 있습니다.CodePipeline → Deploy → GenerateChangeSet → Advanced → Parameter overrides람다 환경변수 설정람다 함수에서 사용할 환경변수를 설정할 수 있습니다. 아래와 같이 람다 환경변수 TZ(timezone)를 지정하면 실행 환경의 표준 시간대 설정이 가능합니다.Resources: HelloWorld: Type: AWS::Serverless::Function Properties: Environment: Variables: TZ: 'Asia/Seoul' 람다 레이어 설정람다 레이어를 적용하면 패키지 관리가 훨씬 편리해집니다. 함수의 패키지 크기가 3MB를 넘지 않으면 콘솔에서 코드를 직접 확인 및 수정할 수 있습니다. 람다 레이어는 zip 파일로 관리되고, /opt 폴더에 압축 해제되며 생성됩니다.람다는 250MB의 제한이 있습니다. 만약 레이어를 사용해 분리하더라도 람다함수패키지와 람다 레이어의 합으로 걸려있으므로 크기 제약에서 벗어날 수는 없습니다.Resources: HelloWorld: Type: AWS::Serverless::Function Properties: Layers: - arn:aws:lambda:{region}:{id}:layer:{layer-name}:{version} xray 모니터링 설정Tracing Property를 이용하면 람다 함수의 Enable active tracing 설정을 할 수 있습니다. CloudFormation 템플릿 메뉴얼엔 TracingConfig로 안내하고 있어도 빌드에 실패하여 확인해보니 SAM 템플릿의 AWS::Serverless::Function 의 스펙에선 Tracing으로 안내되고 있는 걸 볼 수 있었습니다.Resources: HelloWorld: Type: AWS::Serverless::Function Properties: Tracing: Active 람다 함수명 설정람다 함수는 기본적으로 아래와 같은 이름을 부여합니다.awscodestar-{brandi-test(프로젝트명)}-lambda-{HelloWorld(template함수ID)}-{NZ6YXLZ8XD0O(RANDOM_ID)}만약 함수 간의 호출이 필요할 때는 아래와 같이 함수 이름의 지정도 가능합니다.Resources: HelloWorld: Type: AWS::Serverless::Function Properties: FunctionName: !Sub '${ProjectId}-HelloWorld-${Stage}' Global 섹션Global 섹션을 이용하면 리소스마다 동일하게 적용할 항목들을 관리할 수 있습니다.Globals: Function: Runtime: python3.6 Environment: Variables: TZ: 'Asia/Seoul' VpcConfig: SubnetIds: - subnet-a1111111 - subnet-b2222222 SecurityGroupIds: - sg-c2222222 로컬 개발환경에서의 SAM 실행API Gateway 환경 실행sam local start-api 람다 함수 직접 실행echo ‘{}’ | sam local invoke —parameter-values=‘ParameterKey=ProjectId,ParameterValue=brandi-test’ HelloWorld Conclusion지금까지 CodeStar 초기 설정에 도움이 될 내용들을 살펴봤습니다. 강력한 기능들과 함께 업무를 진행한다면 조금이라도 더 나은 개발 환경을 구축할 수 있을 거라 생각합니다.글이상근 실장 | R&D DO실[email protected]브랜디, 오직 예쁜 옷만