조금 오래된 광고 카피라이트지만,뇌리에 박혀 버린 말이 있다.모두가 예스라고 답할 때, 노라고 말할 수 있는 사람!모두가 노라고 답할 때, 예스라고 말할 수 있는 사람!(2001년 동원증권 CF 중에서 카피라이트 문구)한 때는 그것이 멋져 보였다.왠지 자신만의 주관이 뚜렷하고,개성이 있는 인재상처럼 느껴졌고남들과는 다른 창의성, 혁신의 뉘앙스가묻어나는 행동처럼 비쳤다.그렇다고 믿었다.이것이 맞느냐!아니다 저것이 더 낫다!이건 안된다.아니다 된다라는 이분적인 회의는결론 도출이 안 되는평행선을 달리기가 될 수 있다.예, 그렇습니다, 맞습니다 또는 아니요, 그렇지 않습니다. 틀립니다라는 대답만으로는 부족하다.그 주장이 나오게 된 원인과그렇게 생각하는 근거는사람에 따라 다를 수 있다.그렇기에 더 많은 시나리오와그만큼 많은 대안과 출구전략들이나타나야 하는 게 정상이다. 그 이후에Yes와 No에 대하여, 더 명확하게는Go or Stop 사이에서 최종 결정은 마지막에 정리되어야 한다.(물론 Plan B와 Plan Z까지 첨부해서...)1. 시작은 Why로부터...어떠한 프로젝트 의제에 대하여생각은 다 다를 수 있다.탐탁지 않은 부분이 있어 반대할 수 도 있고,적극적으로 밀어붙이고자 찬성할 수 도 있다.적극적 반대도 있고, 어정쩡한 찬성도 있다.여전히 반반 사이에서 부동층을 형성할 수도 있다.이러한 고착상태에서 의견을 모을 수 있는 방법은 논리이다.논리는 순서이다.원인과 근거를 제시하는 것부터 시작이다.때문에모두가 Yes를 외칠 때, Why라고 묻는 것이다.모두가 No라고 외칠 때, Why를 묻는 것이다.어린아이가 성장하면서 호기심과 궁금증이 많아지면서 "왜요?", 왜 그래요?"라는 말의 빈도가 높아진다.마찬가지로한창 성장하고 있는 회사에는"왜"라는 질문이 매우 중요하다.문제를 진행할지 안 할지 이전에문제의 근본적인 원인을 되짚는 것이 우선이다.Why는 몇몇 리더들이 불편해하는 질문이기도 하다.특히 시간에 쫓기며,빠른 결정을 해야 할 때는 더더욱중간 단계를 skip 하길 원한다."그냥 하라면 해!""그건 이미 다 결정된 거야""지금 와서 돌이킬 순 없어."라는 식의 반응은 어디선가 많이 들어보지 않았을까?꼰대라고 여기던 직장 상사라던가,고압적인 교수님이라던가,고지식한 군대 선임에게서도...그러한 조직 내지는 리더에게Why라는 물음은 군말이 많다,대든다,오지랖이다,주제넘는다라는 핀잔으로 돌아오곤 했다.그렇게 하나둘씩 입을 다물기 시작하고,나중에는 거수기들만 남아있는 회의, 의사결정 자리가 되어버리지.2. 본론은 룰(Rule)로부터...일반적으로 스타트업의 의사결정은 동료들과 문제에 대한 해결방안, 대안을격렬하게 논의하면서 진행된다.스타트업에서회의의 진짜 묘미는바로 다양한 아이디어와 의견을 도출하되마지막은 결론이 정리될 수 있어야 한다는 점이다.중구난방으로 쏟아진 의견은 자칫 회의가 산으로 갈 수가 있다.정리되지 않은 아이디어들은 다음 날이 되면 우리가 뭣 때문에 회의를 한지 방향성을 잃게 만들기도 한다.역으로,제한적으로 과한 통제는시계 초침이 "똑딱, 똑딱" 느껴질 정도로지루하고, 숨 막히는 회의가 될 수도 있다.그렇기에 회의에는 룰이 필요하다.최소한 정해 놓아야 할 룰은 다음과 같다.1) 회의 전 사전검토에 대한 룰(회의 내용 사전 숙지 및 검토),2) 회의시간 한도의 룰(무한정 회의는 삼가자),3) 구성원 간의 발언 룰(발언자/사회자/경청자가 지켜야 할 룰),4) 결과 정리의 룰(의견을 정리, 취합하고, 다음 단계로 넘어갈 수 있도록 액션을 정할 것)적어도 위의 4가지 rule은 경험적으로,많은 시행착오를 거치면서 필수적이라고 깨달았다.  3. 결론은 How로부터...난 하와이를 좋아한다.가 본적 없는 여행지인 하와이가 아니라나름대로 이름 지은Howhy(하우 와이)!아재 개그인가....ㅠ.,ㅠWhy라는 질문으로 문제의 본질을 찾는다면,How는 질문으로 문제의 해결책을 찾는다.그래서 어떻게 할 건데!How는 육하원칙의 하나이지만,다른 단어들과 동등하다고 생각하지 않는다.How 안에는 언제 해야 할지,무엇을 해야 할지,누가 해야 할지,어디서 해야 할지를 포함한다.따라서,Why와 How는 문제 해결로 가는가장 중요한 열쇠이다.그럼에도(주)클린그린의 회의가 이상적이지는 않다.습관화가 덜 되어서인지,뭔가 간과한 부분이 있는 건지,아니면,회의 진행에 있어 여전히 미숙한 건지딱 하나 꼬집어 말하기는 어렵지만늘 100% 만족할만한 회의는 없었다.하지만 분명한 것은이전보다는 효율적이고,보다 다양한 의견과 정리된 결론으로진일보하였다는 점이다.제품이나 서비스만 피봇 되는 게 아니다.회사도,시스템도,업무도,사람도 피드백과 수정을 거쳐발전해 나가는 것이다.우리는 계속 발전하고 있는 중이다.#클린그린 #스타트업 #창업가 #창업자 #마인드셋 #조언

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

가장 애매한 전문가 : 기획자나는 기획자다.아마도 다양한 타이틀을 달고 있는, 나 같은 기획자들을 주변에 많이 볼 수 있을 것이다.특히, 대기업으로 갈 수록 업무가 세분화되어 있다보니, 상품기획, 서비스기획, 개발기획, 디자인기획, 광고기획, 사업기획 등등 왠만한 기능들의 뒤에 '기획'이라는 접미어를 붙여 마치 각 기능들을 앞에서 이끌 것 같거나, 아니면 각 기능들의 뒤치닥거리를 할 것 같은 그때 그때 다른(조직마다, 업종마다, 기능마다)느낌의 Job이다.사실, 가장 가까이에 있는 xx 기획자에게 한 번 물어보아라. "당신의 역할은 무엇인가요?" 한 마디로 쉽게 설명할 수 있다면, 그 사람은 꽤 유능한 기획자일 것이다.기획자의 역할 정의실제로 기획자의 역할은 대단히 폭넓고 다양하다. 당연히 어떤 산업에 종사하느냐, 어떤 부서에 누구와 일하느냐에 따라서 달라진다.어떤 곳에서는 핵심 '전략'을 담당하기도 하고, 어떤 회사에서는 '운영'을 담당하기도 하고, 어디에선 '리더'의 역할을, 다른 곳에선 '시다바리'의 역할을 맡기도 한다.어떻게 보면, 특정 기능(예를 들어 개발자, 디자이너, 영업, 재무 등 전문영역)을 전문적으로 수행하는 업무를 제외한 나머지 업무 모든것을 커버하는 Generalist 를 총칭한다고 볼 수도 있다.나는 디자인 기획자이다.대기업에서 상품을 구상할 때 필요한 신제품의 컨셉을 발굴하고, 디자인의 방향을 설정하고 사용자에게 유용한 기능들이 조화를 이루는지 꼼꼼히 확인하여, 디자인 목업과 프로토타입을 일정 내에 나올 수 있도록 매니징 하는 일을 하고 있다. (음... 뭔가 복잡하고 딱히 뭘 하는지 잘 이해가 안간다면...그게 바로 기획자의 실제 업무 들인 것이다 -_-)좀더 일반화해서 기획자의 업무를 크게 5가지로 구분해보겠다.정보 파악 기능 (searching): 팩트를 파악하고, 현황을 분석하여 올바른 판단을 할 수 있는 근거를 마련하는 업무문제 정의 기능 (defining) : 현황에 근거하여, 현재의 문제를 정확하게 파악하고 정의하는 업무자원 할당 계획 기능 (planning) : 과제를 언제, 얼마의 비용으로, 누구와 어떻게 하겠다는 계획을 수립하는 업무방향 설정 기능 (directing) : 목표를 명확히 정의하고, 집중 해야 할 방향을 선택하고 제안하는 업무운영/매니징 기능 (managing) : 설정된 계획에 차질없도록 관리 및 운영하고 커뮤니케이션 하는 업무기획자의 핵심은 '컨셉' 이다위에 나열된 업무들을 보면, 대게 경험이 쌓이면 조금씩 숙련도가 올라갈 법한 일들처럼 보인다. 자료를 조사하거나, 현황을 분석하거나, 자원을 할당하여 스케쥴과 예산을 산정하고, 무엇을 포기하고 어디에 집중할 것인지에 대해 제안하고, 차질없이 목표를 수행하는 기능들은 마치 직장인들이라면 마땅히 누구나 해야 하는 당연한 일쯤으로 보인다.하지만, 기획의 성공과 실패는 어디에서 나뉘어지는지 생각해보면, 위의 5가지 영역을 무리없이 처리한다고 하더라도 업무를 성공적으로 이끌긴 어렵다.창의력이 발휘되어야 하는 업무이기 때문이다.문제를 정의하고, 자원을 할당하고, 방향을 설정하는 단계가 창의적이거나 혁신적이지 않다면, 아마도 뻔~한 결과물로 일을 마칠 가능성이 높다. (그 일을 수행하는 전문가의 역량을 동일하다고 본다면...말이다)다시 말하면, 문제를 남다른 관점에서 정의하고, 전혀 다른 방식으로 방향을 이끌어 갈 수 있을 때, 새로운 해결책과 'wow' 요소가 나올 수 있다.하지만, 다시 현실로 돌아와보자.나와 한팀으로 같이 일하는 개발자, 마케터, 디자이너에게 우리가 상식적으로 알고 있는 상황을 전혀 새롭게 인식시키고, 전혀 다른 관점으로 문제를 풀어가자고 설득하는 일은 (게다가, 그들이 내 선배 또는 전문성과 경험으로 무장한 사람들이라고 한다면...-_-) 결코 만만치 않을 뿐만 아니라, 자칫 '그건 네 생각이고~', '난 아닌 것 같은데...' 몇 마디면, 보통 기획자들은 찌그러지게 되어 있다.기획자가 조직에서 '맨날 자기 세계에 빠져있는 자', 또는 '회의 소집하고, 회의록 정리하고 문서 작성하는 staff' 정도로 치부되는 경우가 적지 않은 이유이다.이 때 필요한 것이, 전체를 엮어나갈 '컨셉' 이다.현상을 다르게 바라보고, 문제를 새롭게 보고, 전혀 새로운 방식으로 해결책을 이끌어낼 수 있도록 하는 힘은 이것을 해야하는 '본질적인 이유'에 대한 질문과 그 답을 표현하는 '컨셉'에 달려있는 것이다.스티브잡스는 가장 위대한 기획자가만 보면, 주변에 꽤 뛰어난 개발자, 감각적인 디자이너, 열정적인 마케터, 지치지 않는 영업맨 들이 많다. 각 기능별로 뛰어난 훌륭한 전문가들은 마음 먹으면(비용은 좀 들겠지만...) 찾을 수 있다.만일 그런 전문가들로 구성된 드림팀을 만들면, 과연 세상을 깜짝 놀라게 하는 무언가가 자연스럽게 나올 수 있을까?그렇지 않다는 것을 직, 간접적으로 우리는 많이 보아왔을 것이다. 그런 논리라면 미국의 뉴욕 양키스 팀이나 스페인의 레알 마드리드 팀은 항상 우승을 해야하겠지만, 사실 어떤 감독과 어떤 작전을 펼치냐에 따라서 전혀 다른 결과물이 나온다.핵심은 전체를 한 방향으로 엮을 수 있는 리더쉽과 문제의 '본질'을 꿰뚫어 볼 수 있는 '컨셉'을 만들 수 있는 능력이다. 이 '컨셉'이라는 것은 총체적인 경험의 총합이어야 하며, 같은 팀원들에게 공유될 수 있도록 표현될 수 있는 무엇이어야 한다.그것이 기획자의 핵심 역량이어야 한다.Parameter Optimizer오케스트라의 다양한 악기들을 (각자 내로라하는 음악의 명장들이 포함된) 지휘자가 위대한 하모니를 만들 듯이, 각 기능의 전문가들이 때로는 양보하고 절제하고, 때로는 선두에서 힘을 발휘할 수 있도록 최적화 하는 일은 지휘지나 감독, 그리고 기획자들이 갖춰야 할 능력이다.단순히 보고서를 잘 정리하고, 꼼꼼하게 프로젝트의 일정을 챙기고, 문제가 발생하면 상부에 보고하고 프로세스를 잘 지키는 것이 중요한 것이 아니라, 이 프로젝트가 어떤 의미가 있고, 왜 이 문제를 해결해야 하는지에 대한 총체적인 질문에 답할 수 있고, 공감시킬 수 있어야 한다는 것이다.때로는 강력한 카리스마가 필요할 수도 있으며, 때로는 감성적인 부분으로 공감을 이끌어낼 수도 있어야 하며, 치밀한 숫자와 논리, 또는 은유와 비유로 총체적인 경험을 표현하는 '컨셉'을 공유할 수 있어야 한다.그런 측면에서 스티브잡스는 누구도 이루지 못했던 혁신적인 제품을 경영자이면서 동시에 '창의적 기획자'로서 세상에 선보일 수 있었다고 생각한다.쓸만한 기획자, 전략가가 없다요즘 linkedIn에 올라온 구직, 구인 정보들을 보면, 구체적인 직능을 수행하는 Expert들을 찾거나 또는 그런 Job을 찾는 내용들을 많이 볼 수 있다.특정 SW를 다룰 수 있는 소프트웨어 엔지니어를 찾거나, 5년 이상 IT 분야에서 종사한 UX 디자이너 또는 편집쪽 업무 경험이 있는 그래픽디자이너 등등 특정 기능을 수행하는 인력을 찾는 내용들은 많지만, 창의적인 사고와 남들과 다른 관점을 가진 '기획자'를 찾는 구인정보는 사실 흔치 않다.문제는 창의적인 사고를 평가할 수 있는 기준도 모호할 뿐만 아니라, 기획자의 입장에서도 자신의 '똘끼'나 창의력을 보여줄 수 있는 '포트폴리오'가 상당히 제한될 수밖에 없기 때문이다. 실제 직접 일을 하면서 과정을 같이 하지 않는 한, 훌륭한 기획자나 창의적인 사고를 구인/구직 시장에서 제대로 판별하기란 여간 쉬운 일이 아니다.설사 자신이 정말 창의적이고, 본질을 꿰뚫는 촌철살인의 혜안을 가지고 있다고 주장하더라도, 그것을 단시간 내에 입증하기도 사실 매우 어려운 것이 사실이다.물론, 이미 각 분야에서 성공적인 사례를 남긴 훌륭한 혁신가, 리더들이라면 이미 그 생각이 미디어를 통해 공유되고 성공사례를 통해 입증될 수 있다고 볼 수 있지만, 그런 인물은 소수일 수 밖에 없고, 이미 몸 값이 감당할 수준이 아닐 가능성이 높다.아마 회사의 터닝포인트를 가지고 싶거나, 혁신의 jump up을 모색하고자 한다면, 좋은 기획자를 다방면에 물색하여 찾으려는 노력이 반드시 따라야 할 것이며, 그 가치를 인정할 수 있는 내부의 안목 역시 뒷받침 되어야 할 것이다.기획자는 표현할 수 있어야 한다기획자는 오케스트라의 지휘자이어야 한다.바이올린과 첼로의 소리를 구분하고 조율할 수 있어야 하지만, 그렇게 만들어지는 소리가 전체적으로 어떤 '음악'이 되어야 하는지에 대한 Big Picture가 머리에 있어야 한다. 그래야, 그 큰그림을 나침반 삼아서 다양한 악기를 조율할 수 있는 것이다.다만, Big Picture가 자신의 머릿속에만 존재한다면, 같이 일하는 파트너들은 큰 그림을 볼 수 없는 상태에서 작은 지시와 조율된 내용만으로 전체 하모니를 만들어 낼 수 없다. 따라서, Big Picture, 즉 전체 스토리 '컨셉'을 파트너들에게 소개하고 공유하고 공감을 이끌 수 있도록 표현하고 설명할 수 있어야 한다.그것이 설득력 있는 보고서이건, 뛰어난 화술이건, 직관적인 비유이던 자신의 생각을 공유하고 소통할 수 없다면, 훌륭한 기획자를 기대하긴 어려울 뿐만 아니라, 하루라도 빨리 자신이 sales 할 수 있는 특정 기술(기능)을 배우는 것이 도움이 될 것이라고 생각한다.기획자는 그리 만만한 Job이 아니다.

백엔드 서비스로 Python을 사용한다면 만나게될 상황을보다 쉽게 해결하기 위한 와탭의 Python APM, 개발하게 된 이유입니다.파이썬은 배우기 쉽고, 어디서나 실행되는 언어라고 이야기되며, 인기도 높습니다. 생각보다 많은 곳에서 배울 수 있으며, 혼자 배우기도 좋습니다. 그런데, 이 규모가 확대되어서 스타트업의 경우에 Python을 사용하여 백엔드 서비스를 개발하는 경우를 찾는 것이 어렵지 않습니다. 또는, 수학적인 알고리즘이거나 ML(머신러닝)과 같은 영역이거나 블록체인등에서 Python을 사용하여 API geteway나 broker를 사용하는 경우에 한정한 상황을 고려하고 있습니다.Python으로 백엔드 서비스를 만들 때에는 성능과 설계 부분에 대해서 많은 걱정을 하게 됩니다. 이런 상황을 만나게되는 개발자는 여러가지 문제를 만나게 됩니다. 그 문제에 와탭은 집중합니다.!와탭은 백엔드 서비스를 Python으로 개발시에 만나게 되는 상황을 가장 최우선으로 생각하게 되었습니다.Python으로 '설계', '개발'되고 '테스트'된 후에 '배포'되는 상황에서 서비스의 불완전함과 속도상의 문제, 리소스의 불협화음등을 '유지보수'하는 단계를 '성능 튜닝'이라고 정의하고, 이를 고려한 상황을 보다 단순화하는 것이라고 생각하게 되었습니다. 이를 어떻게 처리하느냐가 와탭 Python의 핵심 가치라고 생각하였습니다.----- 이 부분은 Python korea 페이스북에서 '배권한'님이 지적하신 내용을 기반으로 일부 첨언되었습니다.----- python native 개발자들에게는 불필요한 설명에 해당됩니다.파이썬은 분명, 읽기 쉽고 사용하기 쉬운 것은 장점이며, 라즈베리파이 위에서 동작되는 기민함은 정말 매력적입니다. <- 원래 문장.(* 현재에는 jvm도 동작합니다. 하지만, 작고 기민하게 다양한 IoT 디바이스에서 폭넓게 활용되는 것은 파이썬의 장점은 분명하지 않나 합니다. 이 부분에 대한 지적이 있어서 첨언합니다. )내부 구성상 비동기식으로 쓰레딩이 아니라, 단일 이벤트 루프를 사용하는 비동기식 작성은 매우 효과적입니다. <- 원래 문장.(* 이 부분도 asyncio나 gevent등에 대한 이야기이고, CPython의 언어 구현상 GIL때문에 쓰레드가 비효율적이라는 이야기를 거론하고 싶었으나, 일반적으로 파이썬에 대한 언어를 사용할때에 대부분 사용하는 이유가 단일 이벤트 루프기반의 비동기식 작성이 매우 일반적으로 사용되기 때문에, 이렇게 서술되었습니다. 하지만, 이런 설명은 백엔드로 Python을 사용하는 경우에 대부분의 프레임웍들에서 처리되고 있기 때문에 서술이 불분명하다는 지적이 있었습니다. 당연, 백엔드 서비스를 개발할때에 사용되는 wsgi interface등에 맞추어서 서술되는 경우에는 이런 설명이 무의미합니다.다만, 이렇게 서술한 이유는 Java를 기반으로 APM이 개발되어졌기 때문에 이 부분에 대한 서술이나 설명이 필요하다고 생각한 저의 과도한 설명이 되겠습니다.이 부분은 Python Native개발자들에게는 불필요한 설명이 되겠습니다. 하지만, 백엔드 서비스를 개발하면서 만나게될 환경에서는 이 부분에 대한 이해가 어느정도 필요하다고 생각되어 서술된 내용이라고 생각해주시면 감사하겠습니다. )----------------------------------------------------------------------------------------------------------------------이 방식은 복잡한 자원 경쟁이나 교착상태를 발생하지 않게 되며, 기본 코딩과 유지보수를 정말 수월하게 만들어 줍니다. 그만큼 일관성이 높은 수학 알고리즘을 구현하는데 매우 적합합니다. 하지만, 냉정하게, 비즈니스 로직이나 분기가 많은 업무 로직에 적합한 언어는 아닙니다.하지만, 수학적 알고리즘 기반의 주요 모듈 위에 데이터베이스가 일부 필요하고, 웹서비스의 형태로 가동되는 구조라면 파이썬은 매우 훌륭한 선택이 되고 있으며, 생각보다 많이 사용됩니다.그런 이유 중의 하나는 파이썬의 멀티패러다임 구성과 같은 구성에서는 자바에서처럼 굳이 프린트를 위해서 객체지향 클래스를 만들 필요 없이 간단한 함수형 스타일도 가능하게 구성이 됩니다. ( 자바 8에서는 이런 함수 기능도 추가되었습니다. )단순한 구조와 방식 때문에 파이썬 개발은 요즘처럼 ML이나 AI 등의 기술적 요소들이 많이 사용되는 환경에서는 매우 효과적입니다. 백엔드 파이썬 개발이 많이 보이게 되는 이유이기도 하죠.또한, 파이썬 개발의 단점이라고 지적되던 문제들도 현재에는 실행 속도 문제는 사실상 큰 문제가 되지 않는 상황입니다. 일례로, 파이파이(PyPY)로 실행된 파이썬 코드는 웬만한 수준의 C 코드보다 빠르게 동작합니다.굳이 더 지적하자면, 모바일 컴퓨팅과 브라우저에 따른 웹 애플리케이션 클라이언트는 굳이 파이썬으로 작성할 필요성을 느끼지 못한다고 이야기하는 정도입니다.하지만, 이런 파이썬 개발에 가장 큰 문제가 있습니다.테스팅 없이는 동작하기 어렵고,실제 동작 환경에서만 등장하는 오류의 발생파이썬의 특성상 동적 입력 형태에 따르는 더 많은 테스팅을 필요로 하고 있으며, 실제 실행시간에만 나타나는 오류를 찾는 것이 가장 큰 문제가 있습니다. 이 부분은 수많은 파이썬 개발자들을 괴롭히고 있습니다.( 단편적으로 파이썬 개발환경이 매우 고도화되어있지 않으며, 파이썬으로 백엔드 서비스를 만들 것이라고 예측하지 못한 점도 있을 것입니다. 앞으로 파이썬 개발이 더 고도화 되기를 기원합니다. )이 가장 큰 문제를 잡기 위해서와탭은 집중하였습니다.파이썬 백엔드 개발 시의 문제 해결!물론, Python도 디버깅에 대한 지원 유틸리티가 존재합니다.pdb라는 파이썬 디버깅 모듈을 통해서 Step over/Step into, 중단점(breakpoint) 설정, 콜 스택 검사, 소스 리스팅, 변수 치환 등을 할 수 있습니다.‘Phthon -m pdb 파이썬 파일. py’의 형태로 디버그 동작 화면에서 세부적인 동작을 트레이스 해보는 방식을 사용하거나, pdb모듈을 import 한 후에 pdb.set_trace()를 중단하고 싶은 부분에 넣어서 사용하는 방식도 사용됩니다. 또한, 디버그 세션을 사용하는 방식이며, PDB를 사용하여 디버깅하는 방식들도 흔하게 사용됩니다.PyCharm, PTVS, Spyder 등의 IDE를 사용해서 디버깅을 하는 방법은 전통적인 개발환경과 동일하게 사용할 수 있습니다.하지만, 이 방식들은 백엔드 서비스에는 맞지 않게 되며 개발자들은 백엔드 서비스 동작시에 디버그 추적을 위한 로그를 거는 방식을 흔하게 사용하게 됩니다. ( 너무도 전통적인 방식이죠. )정말 백엔드로 파이썬을 사용하고 있다면, 오류 추적이나 동작 메커니즘을 추적한다는 것은 매우 귀찮고 번거로운 작업이 됩니다.만들어지는 파이썬의 모든 파일에 해당 로그를 넣었다가 빼었다가, 배포의 오류를 만나는 상황까지 매우 번거로운 작업들이 끊임없이 반복되게 됩니다. 이런 상황들을 추적하기 위한 APM의 추적 기능들을 찾게 됩니다.또한, Python의 특징상 수학 알고리즘으로 구성된 API 중개인의 형태를 취할 경우에 DB에 대한 접근을 위한 ORM에서의 추적과 외부 웹 호출들이 뒤섞이게 되면서 오류 추적은 매우 짜증스러운 단계로 진화되게 됩니다.Python으로 백엔드 개발을 하게 되면만나게 되는 매우 짜증스러운 상황이죠.그래서, 와탭의 Python APM은 이 문제에 집중하기 위해서 와탭 고유의 문제 해결 방식을 그대로  아키텍처로 적용하여서 개발시에 편하고 빠르게 성능을 추적할 수 있도록 제작되었습니다. Python 백엔드 개발을 위한 최선의 방향을 제시합니다.Python개발자는 와탭의 APM을 설치하면 매우 손쉽게 웹 트랜잭션의 단계, 에러 추적, 클래스 추적, DB의 형태 및 Slow Query추적, 외부 호출 메커니즘의 구성 등을 설치 이후부터 빠르게 추적할 수 있으며, 개발자의 실수이거나 다른 외부 호출의 문제, DB와의 관계 등을 빠르게 잡아낼 수 있습니다.에러를 추적하기 위한 로그를 동작한다던지, 실환경시에 배포를 다시 한다던가 하는 귀찮은 작업을 모두 제거하는 것뿐만 아니라, 매우 통계적으로 의미 있는 와탭의 트랜잭션 추적 메커니즘을 사용할 수 있게 됩니다.파이썬을 기반으로 백엔드를 구성하는 곳이라면,와탭 APM은 매우 의미 있는 결과를 도출할 수 있습니다.와탭 Python의 세부적인 기능을 조금 더 상세하게 설명드리겠습니다.가장 먼저, 실시간 트랜잭션 모니터링!5초 주기로 트랜잭션을 수집하는 와탭의 방식은 서버의 부하를 최소화하면서 가장 의미 있는 데이터들을 수집하고 데이터 기반으로 오류와 트랜잭션을 빠르게 추적할 수 있게 합니다.파이썬 개발 시의 동작성을 체크하기 위한 와탭만의 고유의 진행 중인 트랜잭션 실시간 모니터링 기능인 아크 이퀄라이져와 동작된 웹 트랜잭션의 종료시간을 기준으로 시각화하여 동작된 트랜잭션의 상황을 한눈에 파악할 수 있습니다.와탭 Python APM위의 그림을 보면, Active Transaction으로 불리는 원형( 아크 이퀄라이져라 함 )으로 실제 동작중인 트랜잭션의 개수와 동작속도 등을 체크할 수 있으며, Hitmap을 통해서 종료된 트랜잭션의 속도를 시각화하여 볼 수 있습니다. 이 두 개의 시각화 만으로도 느린 트랜잭션을 추적 관리할 수 있습니다.Python 트랜잭션 추적 및 분석개발자는 단지 APM을 동작시켰을 뿐이지만, postgreSQL 데이터베이스에 연결하고 SQL문장을 주고받는 부분들을 하나의 시각화된 관점으로 나열해서 확인할 수 있습니다.각각의 동작 시간을 추적하는 것은 물론이고, 이 내용은 ORM으로 매핑된 상태에서도 SQL의 동작 순서대로 시각화되기 때문에 순서가 꼬이거나 문제가 발생되는 부분들을 손쉽게 찾아볼 수 있게 합니다.이외에도 와탭 APM( Java, Node, PHP 등의 모든 APM)에 기본적으로 제공되는 트랜잭션 추적 모듈 이외에도 사용자가 원하는 모듈 추적에 대한 기능들을 플러그인 형태로 정의할 수 있습니다. 더 복잡한 추적을 위해서 와탭의 고유기능을 추가적을 확대 사용이 가능합니다.WHATAP_HOME 의 plugin.json파일에 적절한 내용을 수정하여 특정 모듈의 데이터를 추적할 수 있습니다. 특정 모듈의 데이터를 추적하거나, 사용자 별로 원하는 모듈을 추적할 수 있습니다.*사용 안내:•[module_name]: 추적하고자 하는 대상의 모듈 명. import 하는 모듈 명 이기도 하다.•[class_name]: 추적하고자 하는 대상의 클래스 명. 없다면 ‘’(empty string)으로 사용한다.•[def_name]: 추적하고자 하는 대상이다.•args_indexes: 추적하고자 하는 대상의 아규먼트 인덱스. 여러 개일 경우 , 로 구분한다.•kwargs: 추적하고자 하는 대상의 키워드 명. 여러 개일 경우 , 로 구분한다.Plugin 기능 사용위의 예제에서는 Plugin과 SQL update문장의 순차적인 실행,세부 Plugin 설정에서 사용자의 모듈명, 추적 클래스 명, 추적대상과 아규먼트 인덱스, 키워드 등을 추적할 수 있습니다.*사용 예:plugin.json{"[module_name]": {      "class_name": "[class_name]",      "def_name": "[def_name]",      "args_indexes": ", ",      "kwargs": ", "},"httplib2": {      "class_name": "Http",      "def_name": "request",      "args_indexes": "1",      "kwargs": "method"},"faker.providers.address": {      "class_name": "Provider",      "def_name": "street_address",      "args_indexes": "",      "kwargs": ""}}두 번째, 데이터베이스를 매핑한 ORM과 SQL의 순서와 속도, Slow Query!매우 당연하게 파이썬을 기반으로 백엔드 개발을 할 경우에 데이터베이스를 사용하게 되며, 이에 대한 Slow Query와 관련된 추적하는 것이 개발자에게 필요하게 됩니다. 향후, RDS기반을 사용하게 되면 Query추적은 대부분의 데이터베이스 처리에 기본이 될 것입니다.현재 지원되고 있는 mysql / postgresql에 대하여 SQL Query, Fetch Count, SQL Query수행 시간을 수집합니다.Python개발 시에 RDBMS(관계형 데이터베이스 관리 시스템)를 선택하면 거의 항상 ORM(객체 관계 매핑) 라이브러리를 함께 사용하게 됩니다.특히, 파이썬에서는 이런 ORM라이브러리가 다양하고 사용하기 쉽기 때문에, 매우 흔하게 사용하고 있습니다.ORM의 장점으로는 쿼리를 생성하거나 추상화하는 대신, 데이터 베이스 시스템에 대한 접근을 쉽게 할 수 있는 장점이 있습니다. 다만, 이러한 장점 때문에 실제 만들어진 쿼리가 어떠하고 쿼리 수행 시간이 얼마나 걸리는지에 대해서는 추적이 어렵다는 점이 있습니다.이처럼, 파이썬의 특징상 ORM(객체 관계 매핑) 라이브러리를 사용할 경우에 추상화된 쿼리가 어떻게 동작하고, 실제 어떤 상황으로 발생 및 동작되는지를 한눈에 파악할 수 있게 합니다.ORM으로 매핑된 SQL의 순차적인 동작 상태 파악그리고, 세 번째. 외부 호출 추적파이썬 백엔드 개발 시에 사용되는 외부 호출(request/httplib2)등의 외부 호출과 관련된 호출 정보 및 수행 시간 등을 수집합니다.외부 호출을 사용하는 경우에는 각각의 호출에 대한 지연시간에 대해서 세밀하게 추적해야 하므로, 이와 관련된 에러와 지연시간 등을 추적하는 것은 매우 중요한 개발 시의 관점입니다.Python 외부 호출 추적마지막 중요 관점 네 번째는, 튜닝을 위한 다양한 프로파일 데이터의 제공을 이야기할 수 있습니다.와탭의 파이썬 에이전트는 위에서 나열되는 성능 저하를 위한 요소들의 전체적인 관점에서 수집하고 그 데이터들을 시각화할 수 있습니다.데이터베이스를 효율적으로 사용하고 있는지, 사용하는 ORM툴과 매핑과의 관계, 쿼리와 쿼리의 수행 시간과 상태에 대한 추적, 외부 호출시간과 각각의 지연되는 외부 호출과의 관계와 순서 등이 전체적으로 백엔드로 개발되는 Python의 성능 튜닝에 영향을 주게 되는 것이죠.그 이외에도 전체적으로 백엔드 서비스의 TPS, 응답 시간, 서비스 리소스 사용량과 어떤 에러가 발생되고 있는지를 알 수 있습니다.서비스 사용자가 사용하는 상세한 정보들을 프로파 일릉 함으로써 이들의 연관관계를 한분에 파악하게 해줍니다. 와탭에서 관리되는 프로파일 정보는 - 트랜잭션, SQL Query, 외부 HTTP호출, Error, User Agent, Client IP 등의 상관관계들입니다.그리고, 덤으로... Python이 설치 운영되는 전체적인 패키지의 버전을 한눈에 파악할 수 있는 것은 너무도 당연한 기능입니다.설치된 Python 패키지 확인그리고, 와탭의 DNA를 그대로 이어받은 APM이기 때문에, 기본적인 APM의 기능들을 대부분 담고 있습니다. 처음 와탭 APM을 접하시는 분들을 위해서 간단하게 설명드리면 다음과 같습니다.CUBE 메뉴는 시간을 기점으로 와탭 Python APM이 설치된 이후부터 현재까지의 모든 상황들을 추적 관찰할 수 있습니다. 주말에 오류 간 난 상황이라던지, 특정 오류의 발생 시점을 알고 있는 경우에 빠르게 해당 문제가 발생한 위치나 SQL 등을 추적할 수 있습니다.상세한 일간, 주간, 월간 리포트나 MAU 등을 추적할 수 있는 리포트 기능들은 와탭만이 가지고 있는 장점에 해당됩니다.Python으로 백엔드 웹서비스를 개발하고 계시다면, WHATAP Python APM은 개발과 운용을 매우 풍요롭고 빠르게 해줍니다.파이썬 백엔드 서비스 개발자라면 와탭 APM!

안녕하세요 대한민국 셀러들의 성공적인 아마존 진출을 도와주는 컨설팅 회사이자 대행사인 컨택틱의 이이삭 대표입니다.아마존에 진출한다는 것은 실로 많은 업무들이 연관되어 있습니다. 컨택틱의 대표적인 서비스인 ‘운영대행’은 쉽게 말해 ‘인큐베이팅 또는 멘토링’ 서비스인데, 이 서비스를 받고 있는 고객사들의 경험을 살려서 말씀드리자면, 아마존 운영은 절대로 1명이 전담해서 관리하기에는 버겁습니다. 따라서 컨택틱은 ‘최적화된 아마존 운영’을 하기 위해서는 2명의 전담 인력이 필요하다고 여기고 있습니다. 이번 글에서는 이 중추적인 2명의 역할이 무엇인지를 말씀드리고자 합니다.첫 번째 역할은 실무 전담입니다 (Operations Specialist). 이 역할을 가진 사람은, 해당 기업이 아마존에 진출하는 것에서부터 아마존을 원활하게 운영하는 것까지 총괄적으로 관리한다고 보면 됩니다. ‘아마존 진출’이라 함은, 대표적으로 다음의 순서를 따릅니다: (1) 시장조사 및 상품 선정 (2) 아마존 입점 (3) 상품 등록 및 최적화 (4) FBA 입고 (5) 시장 반응 검증 (6) 마케팅 (7) 세일즈 모니터링. 그 뒤로부터는 3번부터 7번을 무한 반복하는 것입니다. 이 과정들을 한 번 겪어보신 분들은 아시겠지만, 대충 하려면 대충 할 수도 있습니다. 하지만 이걸 ‘완벽’하게 하는 것은 굉장히 많은 인력과 심력이 들어간다는 것 또한 알 것입니다. 완벽의 기준은 따로 없지만, 리스팅 하나만 놓고 본다고 하더라도 키워드 하나하나를 곰곰이 생각하면서 심사숙고 끝에 결정 및 적용하는 것을 말하며, FBA 입고 또한 어느 상품을 언제 어떻게 준비하여 FBA 창고에 입고할 것인지 계획할 뿐만 아니라 행동으로 옮기는 것 또한 굉장한 multi-tasking 능력을 요구합니다. 그렇게 진출시킨 상품의 실제 판매 실적이 어떠한지 모니터링하고 분석하는 것까지 고려한다면 심지어 1개의 SKU (상품)에 대해서조차 눈코 뜰 새 없이 바쁠 거라는 것을 짐작할 수 있습니다. 허나 이런 과정들을 단 1개의 SKU에 대해서 하는 게 아니라 기업 규모에 따라 10개, 100개, 심지어 1000개까지도 해야 할 수도 있습니다. 실무 전담 담당자는 그만큼 multi-tasking 재능이 뛰어나고, 매사에 세심하고 철저하고 꼼꼼한 성격인 사람이 제격입니다.두 번째 역할은 마케팅 전담입니다 (Marketing Specialist). 이 역할을 가진 사람은, 아마존에 출시한 제품들의 시장 반응이 최대한 잘 올 수 있도록 온갖 신경을 쓰는 것입니다. 실무 전담 담당자가 만약 아마존에 최대한 많은 상품을 출시하고, 관리하는 것에 목적이 있다면, 마케팅 전담 담당자는, 그 출시하는 상품들이 하나같이 전부 대박이 터질 수 있도록 할 수 있는 일을 최대한 하는 것에 포커스를 둡니다. 이 역할을 담당할 사람은 대표적으로 ‘센스’가 필요합니다. 여기서 말하는 센스는 디자인 센스뿐만 아니라, 고객들의 마음과 갈망을 파악할 수 있는 센스도 얘기하며, UI (user interface)와 UX (user experience)에 걸쳐서 고객들의 쇼핑 경험을 전문적으로 케어할 수 있는 재능을 종합적으로 얘기합니다. 실무 전담 담당자가 아무리 상품들을 원활하게 아마존에 진출시켰다고 해도, 마케팅 전담 담당자의 기여가 없으면 삭막하고, 건조하고, 감흥이 없는 리스팅들만 잔뜩 올라가게 될 것입니다. 제품이 아무리 좋아도, 구매의 욕구를 불러일으키지 않는 리스팅들만 잔뜩 있다면 시장 반응 검증조차도 의미가 없게 됩니다. 그러면 당연히 베스트셀러가 탄생하지도 않을 것입니다. 그런 의미에서 마케팅 전담자는 리스팅의 가장 중요한 (1) 이미지 (2) 강조 포인트 (3) 상세 설명 부분들을 특유의 ‘구매 욕구 불러일으키는 센스’로 장식하도록 재능을 기여해야 합니다. 실무 전담자는 키워드 인덱싱을 고려하면서 ‘이론’ 기반의 리스팅을 만드는 ‘뼈대’에 집중했다면, 마케팅 전담자는 그 내용에 ‘감성’ 기반의 요소인 ‘살’을 붙여줌으로써 비로소 리스팅이 완성되는 것이라고 볼 수 있습니다. 그 외에도, 시장 반응 검증을 통해 유력한 상품들이 걸러졌다면, 그 상품들은 마케팅 전담자의 역할로써 본격적인 홍보 활동과 판매촉진 작업을 해야 하는 것입니다. 역시, 그런 홍보 활동과 판매촉진 작업을 진행하면서 실적을 모니터링하고 분석하는 것은 다시 실무 전담자의 역할이 됩니다.이렇듯이, 아마존 운영은 중추적인 2개의 기둥을 통해서 운영하는 것이 가장 효과적입니다. 이 두 개의 역할을 한 사람이 전부 다 하는 것은 현실적으로 많이 버겁습니다. 따라서 1인 기업이나 스타트업이나, 초기 단계의 기업은 1명의 담당자가 최소한의 input으로 두 개의 역할을 소화할지언정, 나중에 아마존을 본격적으로 발전시키겠다고 결정한다면 반드시 역할을 분담해서 ‘이론’에 강한 논리적인 실무 담당자 최소한 1명과, ‘감성’에 강한 감각적인 마케팅 담당자 최소한 1명이 팀을 이루어서 아마존을 운영할 것을 권장합니다.컨택틱의 모든 교육은 파트너인 글로벌셀러 창업연구소와 접수하고 진행합니다. 교육 신청은 아래 링크나 글로벌셀러 창업연구소의 홈페이지를 통해 접수 가능합니다.오프라인 아마존 입문 과정오프라인 아마존 기초/심화 과정온라인 아마존 입문 과정그럼 오늘도 즐거운 글로벌 셀링 되세요!감사합니다.컨택틱서울특별시 서초구 서초대로 356, 606호(서초동, 서초지웰타워)대표 전화: 02-538-3939이메일: [email protected]홈페이지: https://www.kontactic.com네이버 블로그: https://blog.naver.com/kontactic카카오 브런치: https://brunch.co.kr/@allaboutamazon유튜브 채널: https://www.youtube.com/c/kontactic

일을 할 때는 반드시 업무분장이란 것을 합니다. 각자 일정파트의 업무를 담당하고 그것에 책임을 진다는 얘기이지요. 매우 행복하고 아름다운 얘기입니다. 그 큰 업무를 어떻게 다 해. 그러니 너는 디자인, 너는 발표, 너는 자료조사, 나는 글을 쓰는 것이죠. 어디서 많이 본 그림입니다. 그렇죠. 조별과제.조별과제전 대학교를 중퇴하고 때려쳤으니, 1년 좀 넘게 경험했고 여러분들은 4년 내내 경험하셨으니 더욱 잘 아시리라 생각됩니다. 조별과제. 공산주의가 망한 이유를 몸으로 체득할 수 있는 또 하나의 교양과목이자, 모두의 할머니 할아버지가 여러 번 돌아가시는 예토전생의 술법이죠. 이 조별과제가 나이를 좀 먹고 장소를 직장으로 옮기게 되면 '업무분장'이라는 이름으로 재탄생하게 되는데, 자꾸 지난 4년간 겪었던 호구의 추억이 되살아나는 듯한 기시감은 떨쳐내기가 힘듭니다.  오늘은 이 업무분장에 대해 알아보도록 하겠습니다. 브랜딩업무는 혼자 할 수 있는 수준의 업무량이 아닙니다. 게다가 그래서도 안되는 것이구요. 브랜딩은 기획단계부터 디자인, 실행, 회계까지 다양한 팀과 업무영역을 아우르게 됩니다. 그도 그럴 것이 브랜딩은 전사적인 단위의 액션이고, 단기적인 프로모션 따위가 아니기 때문입니다. 정체성에 관련된 문제이니 모두가 각 영역에서 하나의 가지를 담당해야 합니다. 그러니 전체직원이 30명이라면 30명이 함께하는 조별과제라고 볼 수 있겠네요. 우리의 경험상 4,5명만 단톡방에 있어도 그 중 한 두명은 반드시 잠수를 탑니다. 더불어 다른 한 명은 도무지 속도를 못 따라오고, 그나마 괜찮은 아이는 자꾸 집안에 무슨 일이 생깁니다. 나를 제외한 모두의 집안에 큰 우환이 생기는 무시무시한 프로젝트죠. 일단 이러한 집안의 큰 변고가 어째서 생기는 지 알아보도록 합시다.업무분장은 왜 항상 폭망인가.1. 방관자이론은 어디에나 적용된다. 내가 아니어도 누군가는 할 겁니다. 이거 못해도 월급은 받습니다. 혼나면 됩니다. 우리 중에 마피아가 있는거야..날로 먹2. 업무역량이 제각각이다.내 기대만큼 일을 잘하는 사람은 세상에 그리 많지 않습니다. 그리고 내가 생각하는 수준의 프로일잘러들은 이미 개인적으로 다 사업을 하고 있거나, 재야에 숨어있거나, 일하느라 바빠서 찾기 힘듭니다.고수들은 산 속에 숨어있다. 채용공고는 비둘기로 날리자.3. 누가 무슨 일을 하는 지 몰라.분명 회의시간엔 서로 나눈 것 같긴 한데 누가 무슨 일을 어떻게 맡고 있는 지를 정확하게 모릅니다. 옆 사람의 업무진행이 어디까지 되었고, 거기에 맞춰 나는 어느 수준까지 해야하는 지 등, 분장의 목표는 집단지성과 다수의 분업을 통해 효율적이고 높은 수준의 결과물을 내는 데에 있지만, 대부분 목표와는 다르게 집단게으름과 한 사람이 만든 것보다도 못한 혼란스럽고 괴이한 혼종이 탄생하는 경우가 많습니다. 느와르 영화 찍는 것도 아니고 도대체 왜 다들 자기 일을 숨기는 걸까요?그래서 나오는 괴이한 혼종...4. 사실은 커뮤니케이션을 못한다.사실은 숨기는 게 아니라, 말을 못하는 겁니다. 어떻게 말해야 할 지도 모르고, 서로 보고하는 것도 눈치보입니다. 솔직히 수평적관계라고 톰, 제임스, 하비 등 영어이름을 붙였지만 몸에 밴 수직적 마인드는 어쩔 수 없습니다. 1년차와 5년차인 내 명함에 똑같이 manager 라고 되어있는데다가 1년차가 자꾸 자기와 동등한 수준의 프로젝트를 맡는다면? 5년 차인 선배의 입장에선 각자의 역량의 차이가 있으니 당연하다. 라고 받아들이기는 여간 어려운 일이 아닐 것입니다. 그런데 자꾸 밖으로는 쿨한 척 해야하고, 속으론 '내가 니 위야' 라는 모순이 발생하면 입은 닫히고 가면만 늘어갑니다. 자꾸 가벼운 얘기들만 오고가고 진지한 싸움과 논쟁을 피하게 됩니다. 화를 내면 진다라는 묘한 명제는 분노의 진실성을 역설하고 있습니다. 먼저 진실을 내비친 사람이 패배하는 것이다라는 체면과 격식의 아이러니죠.눈치만 보는게지.5. 업무분장의 기준이 엉망이야.업무는 케이크쪼개듯 정확히 몇 등분으로 쪼개지지 않습니다. 반드시 많은, 중요한, 급한 일들이 발생하고 누군가는 그것을 떠맡아야 합니다. 업무분장의 기준은 대부분의 회사에서 '잘 하는 사람' 에게 집중되고, '손 빠른 사람'에게 과중됩니다. 직급높은 사람에게 책임직을 맡기고, 일 없는 사람들에게 자잘한 업무들을 던집니다. 그냥 상식선에서 이루어지는 분장이죠. 분장과정에서 이 사람의 역량이나 성향, 관심사나 이전 경험, 인맥과 인사이트가 고려되지 않습니다. 조장님 말씀6. 하던 사람이 계속 하는일이란 것이 참으로 그렇습니다. 사람뽑기가 세상에서 가장 힘든 것이 사업이죠. 그래도 회사에 나를 제외한 내 오른팔과 같은 존재가 한 명 정도는 있기 마련입니다. 대표도 사람인지라 당연히 열 손가락 깨물면 더 아픈 것이 있기 마련입니다. 그런데 대부분 그 아픈 손가락이 굉장히 일을 잘하는 사원이고 믿음이 간단 말이죠? 그러면 배려해주고 쉬게 해주는 것이 아니라, 더욱 많은 일을 맡깁니다. 이것은 상대적인 불신때문입니다. 이 사람이 잘하니까 일을 줘야지! 라고 생각하기 보단 실상 다른 직원에게 주려고 하다보니...고려할 사항이 너무 많습니다. 검증되지도 않았고 애매한 거죠. 그런데 일은 매번 중요한 것들입니다. 그르치면 손해가 막심할 것 같으니 믿음직한 사람에게 고개를 다시 돌립니다. 아이러니하게도 그 믿음직한 사람은 일이 과중되고 지쳐가기 시작합니다. 곧 그 믿음은 실수와 사고로 이어지기 마련이죠.7. 이해를 못함일을 잘하고 못하고를 떠나서 이것은 업무이해도의 문제입니다. 전체그림을 볼 수 있느냐의 문제죠. 브랜딩에 대해 얘기할 때 1화에서 '모든 직원이 내용을 알고 있어야 한다' 라고 꼭 찝었던 것은 이 때문입니다. 업무이해도가 떨어지면 레시피만 보고만든 믹스호떡처럼 괴생명체가 탄생하거나 도무지 처치곤란한 혼종이 등장하게 됩니다. 기껏 일은 일대로 하고 손해는 손해대로 보는거죠.뭐라는 거지...?8. 편가르기, 편애, 미운털, 관계가 망치는 업무특수한 경우라고 믿고싶지만, 은근히 많더군요. 이해는 갑니다. 사람 모인 곳에 어찌 당파가 없을 수 있겠습니까. 라인도 있고, 야당도 있고 여당도 있고 제3당도 있고 많죠. 문제는 자꾸 이러한 인간적관계가 업무에 영향을 미친다는 것입니다.  예를 들어 우리 팀장이 좀 호구같다고 칩시다. 난 오히려 옆 팀의 이사겸 팀장님이 더 좋습니다. 그래서 우리 팀장이 준 일은 미뤄놓고 옆 팀에서 부탁한 일 먼저 처리하고 있습니다. 우리 팀장이 나를 혼냅니다. 난 빡쳤습니다. 그래서 옆에 이대리랑 옥상에서 담배를 피며 말했죠."아 진짜 존나 일도 못하면서 성깔은..아놔"이대리는 거듭니다. 왜냐면 나와 친하니까요"진짜 저 사람은 어떻게 일할려나 모르겠음.. 이번 것도 분명 말아먹을 기센데." 우린 한 당파가 되어 팀장을 깝니다. 그리고 그의 지시를 자꾸 누락하고 미루고 안하죠. 대강하거나. 취합해야 하는 입장에선 자꾸 공백이 생긴 결과물들이 올라옵니다. 하지만 일을 만들긴 만들어야 하니 또 야근을 해야하죠. 야근을 하고 혼자 취합을 하게 되면 실수가 생깁니다. 실수는 문제를 야기하고 문제는 손해로 이어지죠. 손해의 책임은 간부가 1차 타격을 입습니다. 이것도 어불성설입니다. 사실. 수평적 문화라면 책임도 동등하게 가져가야 하는 것이 이치상 맞습니다.  내 기여도만큼의 보상을 받는 만큼, 내 손실분에 대한 타격을 입는 것 또한 수평적 문화의 특징입니다. 특히 성과지표가 분명한 프로젝트 기반의 업무에선 더욱 그러하죠. 어쨋든 팀장은 멘붕이 되고 윗 선에게 심하게 깨집니다. 직원들은 그걸 또 팀장의 탓으로 돌립니다.  물론 이 과정에서 팀장이 잘했다는 얘긴 아닙니다. 애시당초 팀 관리에 문제가 있기도 했겠죠. 하지만 그것을 마냥 팀장이나 간부에게 당신의 리더쉽 탓입니다라고 전가시키기엔 직원들도 결국 마찬가지 수준이었습니다.  업무분장은 어떻게 할까.업무분장의 문제가 해결된다면 전세계 모든 대학교의 조별과제의 악몽이 해결되는 기적이 일어날 수 있을 것입니다. 또한 대부분의 기업의 효율성이 개선되고 생산성이 극대화되어 이 지긋지긋한 장기침체가 끝날 지도 모르겠습니다. 심지어 저도 팀원들과 일을 했을 때, 직원이 있었을 때, 협력업체와 일할 때 등등... 여러 케이스를 겪어봤지만 정확한 정답을 찾지 못했습니다. 다만 소기의 성과와 부작용들을 체험하면서 이건 이럴 때 좋고 이럴 때 좋지 않구나...라는 정도를 짐작할 따름입니다. 그러니 업무분장의 옳은 방법이라기 보단, 뻔하지 몇 가지 유의사항을 중심으로 적어보겠습니다.1. 적어도 분장회의는 심각하게.프로젝트플랜을 짜고, 각자 업무를 나누는 회의를 할 텐데. 전 개인적으로 이 회의를 대충하지 말자는 주의입니다. 조금 과장해서 하루 전체를 그 업무분장 회의에만 써도 괜찮습니다. 하루는 정말 고생하겠지만, 이 후의 확인, 취합, 업무상황 진행 등 모든 전반의 업무효율이 극단적으로 올라갑니다. 다들 그 시트의 데드라인을 맞추기위해 노력하고, 모두가 어떤 상황이 어떻게 돌아가는 지 이해하고 있는 상황이 됩니다. 단, 그 하루동안 해야 할 일이 있습니다. 직원들의 성향파악현재 업무 재정리각자 업무속도 계산프로젝트 기간 내 개인사, 사내일정 스케쥴링정/부 인원 지정보고체계 확립프로젝트 개괄 프레젠테이션상세 업무공유개인별 목표설정 및 평가지표 설정개인별 업무일정 짜기취합 후 프로젝트 플랜시트 제작완성된 플랜시트 피드백적어도 이 부분들은 순서대로 아주 치밀하게 결론을 내는 회의시간이었으면 합니다. '너 일 뭐 있지? 너가 이거 할래?' 이런 식의 분장이 되지 않았으면 좋겠습니다.2. 미달성의 책임은 분명히실무자를 위한 것이기도 합니다. 방관자의 심리의 주된 원인은 책임의 분산입니다. 다수가 존재하는 만큼 해당 이슈에 대한 책임이 분산되며 나에겐 피자 위에 뿌려진 올리브만큼의 책임감만이 스윽 주어지게 되는데 그 정도는 그냥 자기합리화나 집안일핑계로 거뜬히 쳐낼 수 있는 수준의 것들입니다. 이런 식으론 어떤 것도 이루어지지 않습니다. 위 회의에서 개인별 목표설정, 평가지표 설정은 정말 중요한 데 해당목표의 미달성시 어떤 핸디캡을 받고 어떤 책임을 질 것인지도 명확하게 지정하는 것이 좋더군요. '반드시 해내야 한다'는 적당한 압박감은 실패시의 합리화나 책임전가를 막고 외부요인으로 부터 그 핑계를 찾는 사태를 줄여줍니다. 아킨(R.M.Arkin)과 바움 가드너(A.H.Baumgaerdener)의 셀프핸드캐핑 실험에서 증명된 것과 같이 말이죠.3. 업무량은 내 처리수준의 +15%, 데드라인은 항상 -1일긍정적인 마인드와 열정, 화이팅, 돈독한 애사심은 훈훈한 분위기에는 좋을 지 몰라도 업무처리능력과는 별개의 문제입니다. 업무를 완성시키고 직원들을 고무시키고 싶다면 편하고 쉬운 일을 주는 것이 아닙니다. 항상 내가 해결할 수 있는 한계치의 적당량 이상의 어려운 과제, 적당히 급한 데드라인의 선을 지키는 것이 중요합니다. 일의 속도감과 성취감은 '일을 끝냈다!' 에서 오는 것이 아니라 '그 일을 해냈다!' 에서 오는 것이기 때문이죠. 에드워드 데시와 리차드 라이언의 자기결정이론중 인지평가이론(Cognitive Evaluation Theory)을 참조해보면 좋을 듯 합니다.4. 일관성!!1번에서 그렇게 심각하게 회의를 했으면, 중간에 그걸 엎지마세요. 회사 일이란 게 워낙 심각하고 급박하게 돌아가는 것이 많으니 변동과 이슈가 많은 것은 사실입니다. 하지만, 급하니까 너 그거 다 멈추고 이것부터 해! 라고 하는 것은 그냥 파국급행열차 티켓을 끊어 손잡이에 매달린 채 목적지까지 달려가렴. 이라는 소리와 같습니다. 어차피 업무분장회의에서 나왔던 그 일도 해야 하잖아요?? 중간에 일이 들어오면 차라리 경매를 붙여서 스스로 업무량을 조절할 수 있게 하던가, 아니면 다시 전사회의를 거쳐 양해를 구하고 전체플랜에 대한 수정을 전사공지합니다. 정보의 제한과 이해의 부족은 아주 사소한 실수와 그냥 던지는 작은 일조차도 '불신의 씨앗'으로 변하게 합니다. 적어도 우리가 그 날 열심히 만들었던 그 회의는 결코 변하지 않는다라는 일관성과 고집이 있어야 추후에 평가, 책임, 보상 때도 신뢰감이 있는 것입니다. 중간에 자꾸 말바뀌고, 일 틀어버리고, 맡기겠다고 했으면서 계속 간섭하고, 불필요한 과정을 자꾸 삽입해서 보고를 위한 보고를 만들어내면 추후에 그 모든 책임은 다 관리자 본인이 지셔야 합니다. 5. 모든 과정은 결과후에 복기한다.불만이 쌓이는 것은 무서운 일입니다. 그러나 그 불만을 그 때 그 때 터뜨리는 것도 업무에선 그리 좋은 방향은 아닙니다. 물론 순간순간 해결될 수 있는 사안이라면 당장 커피와 함께 멱살을 잡든 엎어치면 되겠지만 대부분의 업무방향은 시스템적인 수정을 필요로 합니다. 때문에 실시간으로 문제해결을 하다간 일이고 나발이고 흐르는 물 막느라 아무것도 못하는 상황이 됩니다. 일단 프로젝트를 끝내는 게 급선무입니다. 단, 일 하나가 끝나고 업무분장된 결과물이 등장하고 난 후 반드시 평가회의를 하시길 추천드려요. 그리고 그간의 모든 일들을 하나하나 정리하면서 복기하셔야 합니다. '아 모두 수고했구요, 참치먹읍시다아~' 이게 아니고... 처음에 하루종일 회의하듯 정말 냉철하고 싸울 듯한 회의가 되어야 해요. 단 회의의 결과는 뭔가 명확한 솔루션을 들고 끝나야겠죠. 안 그러면 감정싸움만 될테니까요.업무분장은 대표입장에서도, 실무자입장에서도 정말 어려운 일입니다. 서로가 서로에 대한 이해가 없이는 일을 할 수도 나눌 수도 합칠 수도 없으니까 말이죠. 자유롭게 서로의 일을 그냥 알아서 하면 얼마나 좋을까요? 각자 일을 찾아서 하는 유토피아같은 사무실 말입니다. 인간은 자유라는 환경이 주어졌을 때 함께 공포를 느낀다고 합니다. 아무런 책임이 없는 상태에선 본능이 가장 먼저 튀어나오고, 애사심이나 업무에 대한 객관적인 판단보단 내 자존심과 타인에 대한 경계심, 심리적관계가 더 먼저입니다. 회사에 들어와서 책상에 앉아 일을 하고 있다고 해서 뭔가 갑자기 일하는 로봇이 되는 것은 아니니까요. 업무분장은 이러한 사람들의 특성을 충분히 고려해야 합니다. 배려할 부분을 배려하고 억압할 부분은 강력하게 억압해야 합니다. 책임과 도전에 따른 보상과 벌도 있어야 합니다. 납득할 만한 이해와 협의도 거쳐야 하며 먼 발치에서 어떤 식으로 누가 무슨 일을 하는 지 확인도 종종 해야합니다. 그냥 '너가 화장실 청소 해.' 라며 던진다고 끝날 문제는 아니라는 것이죠.우리 사무실의 화장실청소는 어떻게 분장되어 있나요? 누가 하고 있나요? 어떻게 그것을 담당하게 되었나요. 만약 그 사람이 청소를 하지 않는다면 한 달 뒤 화장실의 모습은 어떻게 될까요. 회사와 비즈니스는 모두의 손을 거쳐 만들어집니다회사와 비즈니스는 모두의 손을 거쳐 만들어집니다. 사무실부터 작은 앱아이콘, 메뉴텍스트까지 누구 하나의 손이 닿지 않은 곳이 없죠. 모두가 사람이 만들어야 하는 것입니다. 과연 우리 회사엔 누구의 어떤 손길이 얼마나 닿아있는 지 한 번쯤 돌아보는 시간을 가져보는 것도 의미있을 것 같습니다. :)

개인적으로 '컨텐츠 마케팅'의 정점이라고 생각하는 이메일 마케팅을 지난 9월부터 6개월째 진행하고 있습니다. 이메일에 담길 컨텐츠를 기획하고, 이메일 내용에 들어갈 이미지를 제작하고, 글을 쓰고, 이메일을 예약/발송하는 것까지 전반적으로 다 담당하고 있는데요, 오늘은 지난 6개월간 해왔던 일을 정리하는 겸 <이메일 마케팅 노하우 5가지>에 대해 이야기해보도록 하겠습니다.<스타트업 이메일 마케팅 노하우 5가지>메일침프로 이메일 마케팅 시작하기먼저, 이메일 마케팅을 할 수 있는 툴부터 소개해드리겠습니다. 저희 회사 같은 경우에는 '메일침프'를 쓰고 있습니다. 메일침프의 무료 계정은 한 달에 구독자 2,000명에게 12,000건의 메일 발송을 할 수 있습니다. 저희 서비스는 아직 12,000건이 넘는 대량 발송은 필요하지 않기 때문에 메일침프를 활용하기로 결정 (땅땅!)이메일 마케팅 노하우 1, 메일은 '제목'은 상상 이상으로 중요하다!사실 이메일 마케팅 하면 누구나 다 이야기하는 것 중 하나가 바로 '제목의 중요성'이지요. 그런데 막상 이메일 마케팅을 직접 집행해보니 이 '제목'은 상상 이상으로 중요했습니다. 같은 내용이어도 제목에 따라서 클릭률이 5%에서 많게는 10%까지도 차이가 났거든요.클릭을 부르는 메일 제목에는- 궁금증을 자극하는 질문형 문장- 타겟의 일상과 깊게 연관이 되는 공감형 문장- 객관성을 높여주는 숫자와 통계를 활용한 문장등이 있었습니다.메일을 받는 사람들이 클릭 후 '아 뭐야 낚였어'라는 생각이 들지 않을 정도로 내용과 연관성이 있으면서, HOOK! 할 수 있는 한 줄의 카피를 쓰는 센스! 그게 바로 메일 제목 쓰는 데에서 꼭 필요하더라고요.이메일 마케팅 노하우 2, 제목만큼이나 중요한 메일 보내는 '시간'!제목만큼이나 중요한 이메일 마케팅의 요소는 바로 '메일을 보내는 시간'입니다. 이것은 타겟의 행동 패턴을 잘 알아야 하는 요인인데요, 주말에는 메일을 확인할 확률이 떨어지는 것 같은 일반적인 요소와는 별개로 우리 서비스가 주로 타겟팅하는 소비자들의 특성을 반영하면 좋습니다.예를 들면 저희 자소설닷컴 같은 경우에는 취업 준비생들이 의욕 넘치게 '자기소개서를 써야겠다!!!!' 마음먹고 노트북 앞에 앉는 주중(특히 월~화 같은 초반)의 오전 시간대에 메일을 주로 노립니다 +_+ 역지사지해서 생각해보면 이렇습니다. 저녁 늦게 집에 가려고 하는데 취업 준비나 자기소개서 작성 팁이 메일로 온다면? 피곤하게 느껴져서 오히려 클릭을 안 하고 싶을 수도 있겠죠? 아니면 '내일 확인해야겠다..' 하고 미루거나 잊힐 수도 있고요!이메일 마케팅 노하우 3, 꼭 모바일 테스트도 해볼 것!이것은 모든 컨텐츠 마케팅에 적용되지만, 이메일 마케팅에서도 중요한 요소이기 때문에 이야기합니다. 바로 '모바일 최적화'!!! 메일 같은 경우에도 PC와 모바일에서 확인할 수 있다 보니 두 경우의 화면과 레이아웃 등을 비교해 보아야 합니다.보통 PC로 작업을 하기 때문에 PC 기준에서 잘 보이니 괜찮겠거니~ 하고 그냥 진행을 하는데, 모바일로 봤을 때 글자가 너무 많거나, 작거나, 이미지의 사이즈가 잘 안 맞거나 할 수 있거든요. 꼭 테스트 메일을 PC와 모바일 두 군데 다 확인해보고 메일을 보내야 합니다.이메일 마케팅 노하우 4, 계속 AB Test/결과 분석하기!마케터라면 본능적으로 할 작업이지만, 이메일 마케팅 역시 보다 높은 결과를 얻기 위해 AB Test 와 결과 분석, 비교는 필수입니다.AB Test 같은 경우는 다양한 요소를 기준으로 해볼 수 있겠습니다. 앞서 말한 것처럼 회원들에게 반응이 좋은 제목을 찾기 위해 메일 보내는 리스트를 절반으로 나누어 제목 1, 제목 2 다르게 보낼 수도 있고요. 아니면 회원이 많은 경우라면 회원들의 관심사에 맞게 메일을 보내며 어떤 관심사를 가진 회원들이 어떤 반응을 보이는지를 분석해 볼 수도 있겠지요.이메일 마케팅 노하우 5, 목표 / 기대효과 / KPI 잊지 말기!마지막으로 잊지 말아야 할 것! '우리가 왜 이메일 마케팅을 하는가?' 이메일 마케팅에 대한 목표, 기대 효과, 그리고 KPI 측정 방법과 결과 분석입니다. 사실 매일매일 일을 쳐내다 보면 이런 것을 잊게 되거든요 (슬프지만.. 현실.. ㅠ_ㅠ) 하지만 정말 정말 중요한 것이니 잊지 말아야 합니다.우리가 이메일 마케팅을 하려고 하는 이유가 무엇인가? 이메일 마케팅을 통해 어떤 효과를 기대하는 것인가? 이것을 어떻게 측정할 것인가?만약 이것에 대한 뚜렷한 답이 없다면, 그리고 이것에 대한 목표와 가설을 세우고 이메일 마케팅을 진행했는데 그만큼의 효과가 없다면, 과감히 그만두어도 좋다고 생각합니다. 리소스가 계속 들어가는데.. 효과가 없다면 어쩔 수 없는 것이니까요..ㅜㅜ 그리고 다른 사람들이 다 한다고 해서 우리 서비스에 맞지 않는 마케팅 방식을 고수할 필요도 없다고 생각합니다. 스타트업에게 시간과 인력은 아주아주 소중하잖아요..ㅠ_ㅠTip!정말 정말 깨알 꿀팁이지만 마지막으로 한 가지만 더 이야기하자면, 이메일 마케팅에서 꽤 중요한 요인 중 하나로 '리스트 관리'가 있다는 것입니다. 좀 더 반응이 좋은 사람들을 찾아내기 위해서, 그래서 원하는 마케팅 효과를 보기 위해서는 계속해서 결과를 분석하면서 최상의 반응을 얻을 수 있는 리스트를 뽑아내야 하는 것이죠. 이메일 마케팅을 시작한 이상 멈출 수 없는 작업이긴 하지만... 꼭 필요한 작업입니다!이상으로 제가 6개월 동안 이메일 마케팅을 하면서 알게 된 노하우에 관한 글을 마무리 지으려고 합니다. 위와 같은 내용들은 정말 기초적인 것이고, 각자의 서비스 성격과 목적에 따라 이메일 마케팅의 방식과 결과 또한 많이 달라지겠지요? :) 혹시 이 글을 읽으신 분들 중에서 다른 노하우를 가지고 계신 분이 있다면 댓글로 공유해주세요~ 더 공부하고 배우겠습니다!#앵커리어 #마케팅 #마케터 #이메일 #이메일마케팅 #노하우 #꿀팁 #인사이트

아마존과 알리바바는 각각 미국과 중국에서 온라인유통의 절대강자로 성장했다.알리바바는 중국판 월마트라 불리는 ‘선아트’ 지분 36.16%를 29억 달러에 인수했으며, 선아트는 중국에 446개의 할인매장을 가지고 있다.아마존은 미국 최대 유기농 식품업체인 홀푸트를 인수했고 홀푸드는 미국, 캐나다, 영국에 460여개의 매장을 가지고 있다.두 회사는 앞다투어 인공지능, 빅데이터, IOT 등 테크놀로지를 이용해서 온오프의 경계를 허물고 새로운 유통방식을 선보이고 있다. 이 두 회사는 이런 면에서 매우 유사한 것처럼 보이지만 두 회사의 성장전략과 철학에는 근본적으로 다른 것들이 있다. 아마존이 중앙집권적 제국의 전략이라면 알리바바는 성벽을 낮춰 탈중앙화된 생태계를 구축하는 전략이다. 아마존의 ‘아웃사이드 인’ 전략: 고객(아웃사이더)의 눈으로 기업활동을 점검하며 경영전략을 짜는 것이다. 알리바바의 ‘인사이드 아웃’ 전략: 기업 자체적으로 기업의 역량과 강점을 진단해서 어떻게 매출과 점유율을 높일지 접근하는 방식이다. 자, 그러면 이 두 가지를 비교해보자. 아마존의 아웃사이드 인 전략아마존은 철저히 ‘아웃사이드 인’ 전략이다. 고객이 모든 판단의 기준이다. 아마존은 고객과 직접적으로 관련되지 않는다면 아무 데도 시간과 비용을 쓰지 않는다. Customer Obession이 있을 정도다. 그게 그의 Ego이다. (2017. 4. 18 쿼츠)아마존은 모든 서비스에서 누가 우리의 고객인가.그들이 필요로 하는 것은 무엇인가를 따진다.기술 개발이 선행이 아니라 고객의 니즈가 먼저이고 기술은 고객의 니즈에 맞춰 개발된다.아마존의 서비스 개발방식을 보자! 서비스 개발 전 보도자료 작성: -      어떤 식으로 언론에 발표할지를 상상하면 작성한다. -      보도 자료 작성이 어렵다면 소비자들에게 어필하기 어렵다고 판된돼 프로젝트가 폐기된다.FAQ 작성-      소비자가 새 서비스를 이용할 때 궁금해 할 점, 어려운 점, 문제점 등을 미리 고민하는 단계, FAQ를 읽었는데도 궁금증이 해소되지 않으면 프로젝트가 폐기된다. 이렇게 해서 등장한 아마존의 서비스들은-      비용대비 이익성이 떨어진다는 반대에도 강행한 아마존 프라임-      신용카드 정보만 입력하면 클릭 한 번으로 주문. 결제하는 원클릭 시스템-      온라인 주문한 뒤 오프라인 매장에서 수령하는 ‘드라이브 스루’-      접근성을 높인 웨사이트 유저 인터페이스  등등등 수도 없이 많다! 아웃사이드 인은 아마존이 소비자를 대하는 태도였지만, 동시에 아마존 제국을 설명하는 말이다. 아마존은 아마존 밖( outside)의 모든 유통을 제국 안(in)으로 집어넣고 있다. 재고 관리부터 물류까지 아마존은 모든 것을 직접 통제한다. 온오프를 가리지 않고 유통에 있어서만큼은 모든 것이 아마존 안으로 들어간다. (2017. 11. 22 포브스)아마존은 밑지고 최저가에 팔면서 고객을 장악한 뒤 경쟁자들이 나가떨어지면 순식간에 시장을 장악한다. 번 돈은 다시 고객 경험에 투자하면서 더 많은 고객을 아마존 제국으로 흡수한다. 동시에 더 많은 경쟁자가 나가떨어진다.아마존은 소비자에 집착하면서 깍고, 덜 벌로, 대신 그 돈을 투자해서 시장을 파괴한다. 겨우 살아남은 유통업체들은 자신의 제국에 복속시킨다. 알리바바의 인사이트 아웃 전략알리바바도 소비자를 강조한다. 그러나 우선순위는 오픈마켓에 입점한 중간 판매자들이다. 빠르게 변하는 시장에서 고객 니즈에 대응하는 것은 판매 일선에 맡기는 게 낫다는 것이다. 그래서 알리바바 유통채널에서는 중간판매자의 권한이 강조된다. 한 마디로 알리바바와 관계를 맺은 모든 기업이 아마존이 되게하겠다는 것이 마윈의 계획이다. 그래서 알리바바는 상품등록, 주문, 결제, 배송으로 이어지는 온라인 유통 시스템을 구축하는데 힘을 기울였다. 그것은 다음과 같다.1.    물류시스템 차이나오 네트워크’(Cainiao Network)데이터 기반의 스마트 물류 플랫폼: 주문이 접수되면 어떤 창고에서 어떤 택배회사를 거치면 가장 효율적으로 배송될지 15초 안에 계산한다. 이를 바탕으로 차이냐오와 계약된 3,000 여개 물류회사에 배송물량이 할당된다. 2.    결제 시스템 알리페이(AlliPay)전자상거래에 대한 불안감을 해소하기 위한 제 3자 지급결제 서비스이다. 고객이 결제하면 배송되는 동안 알리페이가 대금을 보관하고 있다가 물건 수령 후 대금이 판매자에게 지급된다.3.    소상공인 금융지원 ‘안트파이낸셜’마이크로 파이낸스 회사. 알리바바 플렛폼에 합류하고자 하는 온라인 사업자들에게 저금리 대출을 해주는 등 금융서비스를 담당한다.알리바바가 이런 식으로 중소기업자들이 알리바바 시스템에 뛰어들 수 있도록 생태환경을 마련한 이유를 마윈은 아래와 같이 같이 말하고 있다. 2016년 알리바바 총거래액은 5,500억 달러를 넘었다. 우리가 판매하는 것을 우리가 직접 배달하려면 500만 명의 직원이 필요하다. 이 500만 명을 어떻게 고용해야 할까? 유일한 방법은 서비스 기업, 물류회사 등에게 자율권을 부여해 이들이 효율적으로 이윤을 낼 수 있도록 돕는 것 뿐이다. 알리바바의 기술혁신으로, 1,000만에 달하는 중소기업파트너들에게 마이크로소프트, IBM 등과 경쟁할 수 있는 힘을 부여하려는 것이다. 인터넷 기술을 통하면 모든 기업이 아마존이 될 수 있다는 것이 우리의 철학이다.(마윈. 2017. 2. 14 CNBC 인터뷰) 결국 마윈의 전략은 알리바바가 제국이 되는 것이 아니라 중소기업파트너들을 아마존으로 만들어주겠다는 철학이다. 이 글은 TTimes를 참고로 작성되었습니다.              

 패션블로그 웹뜰입니다어느새 웹뜰 10주년 워크샵을 다녀온지 한달이란 시간이 지나버렸네요 3월에 다녀온 여름나라 코타키나발루 3박5일 웹뜰 해외워크샵 마지막 이야기를 들고 왔습니다. 둘째날 워크샵을 마치고 세번째날은 오전에는 호텔에서의 자유시간이였습니다. 전날 워크샵으로 늦게까지 달린 웹뜰 직원들이 충분히 휴식을 취할 수 있는 시간이였어요 늦잠도 좋지만 일단 조식은 챙겨서 먹어야 하니깐 일어나 조식뷔페로 갔습니다. ㅎㅎㅎ 역시 어제 달려서인지 어제보다 많은 직원들이 보이지 않네요 식사를 하면서 수영장쪽을 보내 오늘도 날씨가 끝내줍니다. 정말이지 코타키나발루에서 계속 날씨가 좋았던거 같아요 웹뜰의 직원들의 워크샵이라 날씨운이 따라 준 것 같습니다. 날씨도 좋고 수영장도 예쁘고 자유시간이니 조식을 먹고 수영을 해보기로 합니다. :)조식을 먹고 배도 부르겠다 산책 겸 마젤란수트라하버리조트를 돌아 다녀봤습니다. 정말 안 예쁜 곳이 없는 마젤란수트라하버네요 구석구석 어디가도 인생샷스팟!여기저기 돌아다니며 사진찍고 놀다가 다시 리조트 방으로 돌아가서 수영복 갈아입고 수영장으로나왔습니다. 파란하늘에 파란 수영장 물 꺄!! 너무너무 예쁘네요 야자수까지 있으니 이국적인 느낌 물씬 수영장에선 역시 썬베드죠 ㅋㅋㅋ 수영보다 썬베드 썬베드에서 요렇게 요렇게 다들 아시죠? 요 허세샷 다들 찍어보셨을꺼예요 ㅎㅎ 수영장에서 수영도 하고 인생샷도 찍어보고 즐거운 오전시간을 보냈습니다. 마젤란수트라하버 골드카드 혜택으로 리조트 안에서 점심도 해결할 수 있었습니다.점심은 피자또는 파스타 중에 골라서 먹을 수 있었는데요 피자도 파스타도 다 맛있었어요 샐러드와 후식으로 과일까지 나오더라구요 수영하고 먹으니 더 꿀맛! 접시를 싹싹 비웠습니다. 세번째날의 오후 일정은 반딧불 투어였습니다. 반딧불 투어는 묵고 있는 마젤란수트라하버리조트에서 버스로 한참 나가야한다고 하더라구요 호텔로비에서 단체사진 한장 남기고 버스를 타고 갔습니다. 가는 중간에 휴게소라기보단... 음 화장실을 가기위해 잠시 들린 곳이라고 하는게 더 맞을 것 같습니다. 간이 매점같은곳이 있어서 간단하게 요기를 할 수도 있었습니다. 화장실은 좀... 열악했어요 물론 비용도 지불해야하고 비용 지불도 했는데 그다지 깨끗하지는 않았더라는.. 역시 어딜 가봐도 한국이 젤 깨끗한거 같아요  ㅎㅎ제가 좋아하는 옥수수도 있어서 옥수수를 사서 다른 직원과 나누어 먹었습니다. 역시 옥수수는 꿀맛이엿습니다. 넘나 맛있어서 버스에서 냄새 풍기는지도 몰랐네요 그리고 곧 도착한 식당입니다.  이 식당 뒤쪽으로 강이 흐르고 있고 배를 탈수 있는 곳이 있는데 그곳이 바로 이따 저녁에 저희가 반딧불 투어를 할 곳이라고 합니다. 식당 안쪽 인테리어는 이런 모습.. 말레이시아는 중국의 영향을 꽤나 많이 받았다고 하더니 이 식당도 흡사 중국 식당 같은 모습이네요 지금 든든히 먹어야 반딧불투어를 할때 배고프지 않다고 합니다. 반찬의 가지수는 여러가지 나쁘지 않습니다. 다만 양념에 향신료가 너무나도 듬뿍 들어가있어 입맛에 안 맞아 저희 직원들 중 대부분은 식사를 제대로 하지 못했네요 식사를 하는 웹뜰 직원들을 위해서(?) 인지 아니면 원래 시간마다 정기 공연이 있는지는 모르겠지만 막간을 이용해서 공연을 보여주는 원주민들 나름 임팩트있게 공연을 보여주고 홀연히 떠나더라구요 ㅎㅎ식당에서 밥을 다 먹고 또 차로 10분정도 이동해서 저녁노을을 보러 갔습니다. 이름모를 해변가였는데 풀어놓은 소랑 말, 그리고 개까지... 해변에 응가를 싸놓아서 발밑을 정말 조심히 걸어야했습니다. 그래도 노을지는 해변에서 각자의 인생샷과 웹뜰 직원단체로 인생샷을 건질 수 있어 너무 좋았던 곳 이였습니다. 그리고 다시 식당쪽으로 돌아가서 반딧불투어!반딧불이는 빛에 민감하기때문에 사진은 찍지 못하였습니다. 역시 가장 아름다운 자연은 눈으로 즐기는게 가장 아름답게 즐길 수 있더라구요 숲따라 흐르는 강을 배타고 가면서 까만밤 수많은 별들 그리고 크리스마스트리처럼 반짝이던 반딧불이들까지너무나도 낭만적이였던 반딧불이 투어였습니다. 반딧불이 투어를 마치고 다시 숙소로 돌아온 웹뜰 직원들 저녁식사가 부실하여 허기졌을 직원들에게 한국에서 가지고온 컵라면과  맛있는 간식을 준비해주신 대표님 짱짱! 너무나도 감사합니다. 그리고 마무리로 조니워커블루라벨과 시원한 음료까지!셋째날 밤도 불태워 보았습니다. 그리고 넷째날 아침이 밝았습니다. 오늘은 체크아웃을 하기 전까지 자유시간으로 주어진 날각자 시내투어나 키나발루산 트레킹 그리고 마젤란수트라하버 투어 등으로 시간을 보냈습니다. 마젤란수트라하버리조트는 어제 오전에 즐겼으니 오늘은 시내투어를 해보았습니다. 시내로 가는 셔틀버스는 마젤란수트라하버리조트에서 시간마다 있었습니다. 저희는 일찍 서둘러서 조식먹고 10시차를 타는 거루~!셔틀버스는 티켓을 구매해야지 이용이 가능하구요 리조트앞 셔틀버스타는 곳에서 표를 구입할 수 있었습니다. 표는 3.2링깃으로 약 1달러정도의 금액을 내면 됩니다. 조금 기다리자 수트라하버라고 쓰여진 버스가 왔네요 저희말고도 다른 한국인 관광객과 타국의 관광객들이 버스를 많이 이용하더라구요 셔틀버스를 타고 시내로 들어가자마자 젤 처음에 보이는 이마고쇼핑몰에서 내렸습니다. 가장 최근에 지어진 력셔리한 쇼핑몰이라고하네요 약간 백화점 같은 느낌의 쇼핑몰이였어요 시원하고 깨끗하고 좋더라구요 백화점 느낌인 만큼 물건도 좋긴했지만 비싼 기분도 있어서 일단 여기저기 둘러보다가 나갔습니다. 그리고 밖으로 나와서 하염없이 시내를 걷기 시작했습니다. 물론 택시나 그랩등의 교통수단을 이용해도 되었지만 일단 코타키나발루 자체가 크고 넓은 편도 아니고 일단 걸으면서 시내를 구경하는것도 좋을것 같아서였습니다. 날씨는 덥긴했지만 그래도 한국의 한여름 40도를 육박하는 조금만 서 있어도 타 들어가는 듯한 더위는 아니였던 날이여서 걷기 좋았습니다. 걸어 다니며 여기저기 쇼핑몰도 구경하고 이국적인 풍경도 구경하는 재미가 쏠쏠햇습니다. 더워서 시원한 망고쥬스라도 사먹고 싶었는데 길에서 파는 쥬스는 안보이더라구요 어느정도 돌아다니다가 KK플라자 지하로 갔습니다. 지하에 마트에서 기념품을 사기위해서죠 여기가 한국인지 말레이시아인지 ㅋㅋ 한국말로 쓰여진 네이버추천 카야잼이라는 표시 그리고 한국어를 유창하게하는 직원덕에 쇼핑을 잘 할 수 있었습니다. 지인들에게 줄 망고젤리와 달리치약등을 사서 이제 배가 고프니 근처 현지 맛집 식당까지 다녀왔답니다. KK마트에서 거의 근처에 있는 유잇청이라는 코타키나발루 맛집입니다. 네이버에 검색해보면 나오는 맛집이라서 그런지 손님들이 대부분 한국 손님이였답니다. 가게도 넓은 편이고 회전율도 좋아서 살짝 대기하고 바로 자리에 앉을 수 있었습니다.  저희는 국수 카야토스트 그리고 사태라는 말레이시아식 꼬치구이까지! 골고루 시켰습니다. 밖에서 돌아다녀서 시원한 음료가 땡껴 콜라도 시켰구요 현지식 음식이라 향신료 듬뿍이지만 향신료에 대한 거부감 거의 없는 저희는 아주 맛있게 싹싹 먹었답니다. 마젤란수트라하버 리조트로 돌아갈때도 셔틀을 이용해도 되지만 시간이 좀 많이 남아서 택시를 타고 편하게 갔습니다. 택시가 엄청 오래된 차라 에어컨이 안나와서 좀 덥긴했네요 ㅎㅎ 이번엔 키나발루산 트레킹을 한 팀의 사진을 소개시켜드리겠습니다. 키나발루산 트레킹은 막 걸어서 트레킹을 하는 느낌이라기 보단 차를 타고 이동하는 시간이 훨씬 많아서 힘들지는 않았다고 합니다. 키나발루산으로 가는 도중 마을이 있어 시장에 들려 열대과일 구경도 하구요 코타키나발루 까지와서 열대과일중 왕자라는 별명을 지닌 두리안도 안먹어볼수 없겠죠 냄새는 썩은 양파냄새 가 나서 냄새만 맡으면 못먹을 것 같았지만 의외로(?) 너무 맛있어서 다들 잘 먹었답니다. 특히 여직원들이 더 잘먹었다는 소리가 ㅎㅎ 산으로 가는 길에 만난 시원하게 흐르는 계곡물 날이 더워서 계곡물에 풍덩하고 싶은 심정을 뒤로하고 다시 키나발루 산으로 갑니다!가는 길에 히비스커스 꽃도 만났습니다. 히비스커스 꽃 말로만 듣고 말린걸 차로만 마셔봤지 이렇게 눈으로 보는건 다들 처음약간은 무궁화를 닮은 붉은 꽃잎이 너무나도 매력적인 꽃이였답니다. 그리고 울창한 열대 우림까지! 역시 자연이 젤 아름답고 위대한 것 같습니다. 키나발루 산에 올라오지 않았다면 이런 광경을 어디서 볼 수 있었을까요 키니발루산 캐노피 흔들다리도 건넜습니다. 총 4번정도 건너는 거 같은데 흔들흔들요거 은근히 덜덜 떨리더라구요 무서워서 아래를 보지도 못하고 앞만 보고 건넜답니다.  이렇게 자연풍경에 빠져서 길을 열심히 걷는 사이에 키나발루산 정상이 눈앞에 똭~!! 구름위로 보이는 산 정상에 다들 입이 똭~!!어찌나 아름다운 풍경인지 자연은 정말 위대하네요 동남아시아의 최고 높은 산이라고 들었던거 같습니다. 정상까지 갔다오려면 1박2일이 걸린다고 하더라구요 일부러 키나발루산 트레킹을 하려고 오는분들도 있다고 합니다. 저희는 정상까지는 가지 못하고 여기서 기념촬영을 하고 이제 다시 숙소로 돌아갔습니다. 시내투어팀도 키나발루산 트래킹 팀도 모두 숙소에서 잠깐의 휴식을 취하고 이제 짐을 모두 가지고 오후 6시 퇴실을 합니다. 원래 마젤란수트라 하버 퇴실시간은 11시인가 그랬던거 같은데 저희는 골드카드 혜택으로 레이트체크아웃이 가능해서 6시까지 일정을 즐기고 조금이라도 쉬다가 나올수 있어 좋더라구요 퇴실하고 시내에 나와서 야시장 구경을 하는 시간이 주어졌습니다. 야시장에서 가이드님께서 1링깃짜리 코코넛주스나 망고주스를 사주었습니다. 기대하고 먹었는데 시럽이 좀 섞여있는 맛 ㅎㅎㅎ100% 과즙은 아니라 조금 실망했지만 그래도 나름 맛있게 잘 마셨습니다. 이따 몇 시까지 어디로 모이라고 말한 뒤 이제 각자 야시장 구경 오전에 나왔을때의 시내와는 좀 다른 모습이네요 오전은 더워서 였을까요? 오전엔 사람이 많이 보이지 않았는데 오후가 되니 사람들도 많이 보이고 여러가지 장사들이 나와서 인지 좀 더 활기 띈 모습이였습니다. 그래도 위험할 수 있기 때문에 절대 혼자는 다니지 말고 가방은 꼭 앞으로 매고 다녀야 한다고 가이드님께서 신신당부하였답니다. 야시장의 꽃은 역시 열대 과일이죠 ㅎㅎㅎ맛보라고 맛만 보라고 자꾸 말하는 동남아 상인들맛보고 어떻게 안 사냐구요! 저희 밥 먹구 공항가야해서 과일은 못사요 쏘리~야시장구경은 근처의 수공예시장도 구경해봅니다. 우리나라 남대문이나 동대문 시장 정도 되는 느낌의 가게가 빼곡히 자리 잡고 있었구요 여기가 기념품 사기에는 야시장보다 좀 더 볼거리도 많았습니다. 다만 너무너무너무너~~~무 더워서 오래 있지는 못하고 후딱후딱 보고 딱 사야 할 것만 사가지고 나왔네요 저는 여기서 지인에게 줄 드림캐쳐를 샀답니다. 물론 공항에서도 팔지만 여기서는 흥정도 가능하고 더 싸게 살수 있었습니다 :D야시장 구경이 모두 끝나고 이제 저녁먹을 시간 만나는 장소로 다들 시간 맞춰서 잘 와서 식당으로 이동! 무브무브코타키나발루에서의 마지막 저녁식사는 씨푸드였습니다. 뭐 씨푸드 하면 다들 떠올리는 바닷가재 킹크랩 왕새우등의 요리는 아니였지만 생선과 생선탕수, 크림새우, 오징어튀김등 그래도 씨푸드는 맞았네요 마지막 식사이니 만큼 다들 맛있게 잘 먹었답니다. 그렇게 식사를 모두 마치고 이제 공항으로 이동!3박5일간의 짧고도 긴 여행이 끝이났네요 워크샵으로 코타키나발루를 다녀오게 되다니 정말 웹뜰 직원이여서 행복하고 즐거운 시간들이였답니다. 다녀와서 힐링의 시간이 되었던거 같아요 함께한 10년보다 함께할 10년에 더욱 기대감을 가지며 일할 수 있을 것 같습니다. 담번에 또 즐겁고 재밌는 소식으로 찾아뵐께요 웹뜰의 워크샵 첫번째 이야기와 두번째 이야기는 아래 참고하시면 됩니다:)[웹뜰 창립 10주년 해외워크샵] 3월에 다녀온 여름나라 코타키나발루 3박5일 이야기 (1)[웹뜰 창립 10주년 해외워크샵] 3월에 다녀온 여름나라 코타키나발루 3박5일 이야기 (2)#코타키나발루 #워크샵 #해외워크샵 #웹뜰 #웹뜰워크샵 #마젤란수트라하버 #키나발루산 #인천공항 #이스타항공 #시내투어

글목록1) 우리는 왜 애자일 하지 못할까 (현재 글)2) 우리는 애자일 하게 일하고 있을까?3) 나는 애자일 하게 일하고 있을까?소프트웨어를 만드는 회사, 그리고 스타트업들은 산업의 특성상,“빠르게 프로덕트를 만들고, 시장에서 프로덕트를 시험하고 지속적으로 발전, 또는 피봇 한다.” 라는 관점에서 린 스타트업, 익스트림 프로그래밍, 애자일 등의 방법론과 업무 프로세스에 대해 많은 사람들이 관심을 가지고, 이하 프로덕트 개발 방법론들을 도입하고 적용하기 위해 노력하고 있습니다. 그래서 많은 방법론 책, 애자일에 대해 신성시하는 글, 또는 애자일에 대한 부정적인 글들도 많이 나오고 있는데요,이런 많은 방법론들이 나오고 좋은 프로세스가 있음에도 불구하고 우리가 우리가 진짜 애자일(Agile)하게, 또는 린(lean)하게 일하고 있을까?라는 관점에서 봤을 때, 우리는 어떻게 일을 했었고, 우리가 일을 하는 방식이 정말 그런 방법론들이 이야기하는 방법으로 일을 하고 있는 건가에 대한 부분은 확인이 필요합니다. 제가 지금까지 다니며 많이 배운 회사들 그리고, 개발자, 디자이너 그리고 피엠분들과 이야기했을 때, “제가 다니고 있는 회사는 이런 부분에서 문제가 있었어요.”라는 이야기를 들을 때마다 공통적으로 느낀 점들은프로덕트를 사용할 “유저” 보다 생각하는 “기능”에 집중하고“무엇이 가장 중요한지”에 보다 “뭐든지 빨리” 만드려 하고우리가 들이는 시간과 노력을 “왜” 이 기능에 들여야 하는지에 대한 공감이 없고"기능"을 정확한 기간 안에 맞추기 위해 사람들이 시달리고, 팀 서로 간의 배려가 없어지고일을 하면서 소통을 위한 회고는 줄고, 업무의 피로도는 쌓이는등의 비슷한 상황들을 경험하시는 것을 확인했고, 이러한 불안정한 상황이 굉장히 애자일 하게(!) 돌아가는 상황들을 확인할 수 있었습니다. 그리고 이 부분을 개선할 수 있는 가장 기본적인 시작은 "프로덕트를 만드는 과정에서 우리는 어디에서부터 고민을 시작해야 할까"라는 생각을 했고, 이를 통해 빠르게 가치를 확인하는 프로덕트를 위해 무엇을 가장 먼저 고민해야 하는가라는 주제로 이야기를 좀 해보려 합니다.1. 처음 프로덕트를 만드는 건 우리지만, 결국 프로덕트를 사용하는 건 유저다. 애자일 프로세스에서 가장 기본적인 목표는 “Agility” 즉 빠르게 가치를 만들어 나가는 과정입니다. 그리고 빠르게 가치를 만들어 나간다는 것은 ”빠르게 프로덕트를 만든다.” 보단 “유저가 가치를 느낄 수 있는지 빠르게 확인하고 가치를 늘려나간다.”라는 부분이 더 중요하다고 생각해요.  그리고 빠르게 유저에게 가치를 줄 수 있는지는 실제 유저들과의 다양한 interation을 바탕으로, 빠르게 배포하고 빠르게 수정하는 과정이 애자일 프로세스의 가치입니다. 그래서 “어떤 기능을 어떻게 만들겠다.”라는 생각에 대해 어떤 유저가 사용할 것인지유저는 어떤 가치를 얻기 위해 사용할지가치를 얻기 위해 가장 먼저 해야 할 것은 무엇인지에 대한 고민이 우선되고, 가장 우선돼야 하는 일들부터 시작하는 것이 우선인데, 우리가 프로덕트를 만드는 과정에서는 “애자일, 스프린트”라는 이름에 갇혀 개발의 과정이 너무나도 가려져 온 것 같습니다. "어떤 기능을 만들어야 한다."라는 가치에 대한 제안(Value Proposition)이 나왔을 때, 가장 우선시 돼야 하는 것은 "이게 유저에게 얼마나 큰 가치가 있고, 이게 비즈니스 적으로 가장 중요한 일인가."라는 검증이 우선돼야 합니다. 정말 유저에게 좋은 프로덕트더라도 아무도 쓰지 않으면 의미가 없고, 가치를 통해 회사가 이윤을 얻을 수 없다면 좋은 기능이라고 판단할 수 없죠. 그렇다고 100% 검증된 기능을 만들 수 있다는 이야기는 더더욱 아닙니다. 그래서 우리는 더 작게, 유저가 가치를 얻을 수 있는 프로덕트를 만들고, 개선시켜 나감으로써 지속적인 배포를 가지고, 지속적으로 유저가 필요한 것들을 확인할 수 있습니다(파란색 줄). 그리고 이런 과정을 지속적으로 진행하면서 우리는 짧은 기간의 론칭 또는 배포 주기에 따라 유저의 성향에 맞춘 프로덕트를 만들고, 상대적으로 위험성을 낮춘 프로덕트를 만들 수 있습니다. 한 가지 기능을 위해서 내가 생각하는 모든 것들을 한 번에 100% 만들 필요는 없어요. 유저가  가치를 느낄 수 있는 가장 작은 범위부터 서비스를 만들고, "우리가 타케팅 한 유저는 어떤 걸 정말로 좋아하는지"에 대해 확인해 가면서 성장할 수 있으니까요.2. 프로덕트를 개발하는 과정은 “스프린트”가 아니라 "마라톤"이다. 애자일한 프로세스 진행 시 "정형화된 스프린트, " "목적이 명확한 이터레이션"에 막혀 릴리즈에 대한 압박들 때문에 스트레스를 느끼게 되는 경우가 많은데, 과연 이런 "정책"들이 "일하는 사람들"보다 중요할까요? 스프린트처럼 빠르게 진행되는 개발과 검증의 과정에서 일정한 움직임(Cadence)으로 빠른 속도(Velocity)는 굉장히 중요한 요소입니다. 비즈니스와 프로덕트의 목적에서 역시 계산 가능한 범위 산정 및 릴리즈 계획은 꼭 필요한 요소지만, 일정과 기능에 대한 기한 때문에 우리가 일하는 과정에서 정책, 개발론이 사람이 일하는 환경과 심리적 요소를 해친다면 결코 좋은 애자일 방법론이 아니라고 생각합니다.위 이미지와 같이 애자일 프로세스를 진행함에 따라, 일정한 개발 주기와 개발 속도를 따라감으로써 기술 부채와 러닝 커브를 줄이기 위해 노력하지만, 우리가 지금까지 일하는 방식에서는 - 정확한 이터레이션의 종점을 찍기 위해 - 정확한 개발 범위와 마커를 세우기 위해즉, "기계 같은 개발 속도와 빠른 론칭"을 얻기 위해 - 왜 무엇을 빌드해야 하는지에 대한 이해와 공감 없이 작업이 진행되고 - 팀원들의 심리적, 물리적 한계를 느끼게 되는상황들을 우리는 자주 볼 수 있었어요. 그리고 이런 공장 같은 프로세스에서는 지속 가능한 프로덕트보다는 만드는 과정에서 지치게 돼 사람들이 떠나는 아주 비 생산적인 프로덕트를 만들 수 있는 가능성이 커지게 되죠. 즉 프로덕트를 만드는 사람들이 숨도 돌릴 틈 없이 스프린트를(Sprint)하다가, 프로덕트가 결국 가야 하는 높은 레벨(High-level)을 가기 위한 기나긴 42.195km라는 길을 도착하기도 전에 지칠 수 있게 되는 거죠. 물론 비즈니스의 방향과 마일스톤, 그리고 프로덕트를 만드는 요소중 중요한 요소중 하나인 "일정"이란 부분은 절대적인 부분이기 때문에 거스를 수 없습니다. 그래서 프로세스와 정책이 있는 것이지만, 모든 프로세스와 정책은 결국 일하는 사람들이 어떤 가치를 위해 일할 때 이를 잘 이룰 수 있게 길을 제시하기 위해서 존재하는 것이라고 생각합니다. 오늘 말씀드린 이야기 두 가지를 한 번에 정리하자면, 프로세스는 유저와 팀원을 가두는 게 아니라, 그들을 기반으로 프로세스를 정립해야 한다는, "사람을 위한" 프로세스를 가져야 한다고 아주 간단하게 정리될 수도 있을 것 같아요. 이야기들이 조금 모호하고, 직접적인 내용들이 좀 부족해 다음엔 스토리엔 오늘 말씀드린 내용들을 중심으로기존에 제가 느꼈던 제가 했던 또는 들었던 프로덕트를 만들며 힘들었던 과정에 대한 자세한 설명유저 가치를 기반으로 작업함에 따라 힘들었던 과정을 지속적으로 수정하고 있는 업무 프로세스에 대해 설명하고 비교를 통해, 어떤 가치를 얻고 있는지 설명드리도록 하겠습니다!#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트

처음 창업팀에 조인할 때는 어떻게 해야 하는 걸까?아무도 가르쳐주지 않았다.이전에 스타트업 두 군데에서 일해본적이 있었지만, 둘 다 인턴이나 직원형태로 짧은 기간 동안만 일했기 때문에 공동창업자에게는 어떤 과정이 기다리고 있는지 전혀 알지 못했다.돈을 넣으라니까 돈을 넣으면 되는거겠거니...얼마까지 가능하세요?500까지는 가능할 것 같은데요...그럼 런칭하기 전에 하셔야 하니까 지금 바로 넣어주세요.???이거 뭐 경매도 아니고 그렇게 투자금을 넣었다.+아직도 7월 1일 처음 귀국해서 사무실을 방문했던 날이 기억난다.수서에 있는 작은 오피스텔이었는데 당시 팀원 3명이 각자 벽을 보고 앉아있는 형태였고, 가운데 둥그런 테이블과 화이트 보드가 있었다.공동대표 2명과 나와 동갑인 여후배 1명이 팀 구성이었고 거기에 나까지 4명이, 앞으로 위젠을 만들어 가야 할 팀이었다. (현 홍기대대표 JOIN 이전)어색한 인사를 마치고 맥주 한 잔을 하러 갔다.이전 스타트업에서의 경험이 영업팀이었던 까닭에, 매일같이 소주 회식은 기본이었는데환영 회식으로 가벼운 맥주라니 뭔가 외국 느낌이 물씬났.........다 ㅋㅋㅋㅋㅋ법인 카드는 따로 없었고 공용 비용은 대표 카드로, 식사는 각자의 카드로 해결했다.조인하자마자 여러 가지 사실을 알게 되었는데 좋은 소식들만은 아니었다1) 출시 일정이 7월이었는데, 외주 개발을 통해 맡기다보니 지연되어 8월로 예상됨2) 실제로 공동 대표 2명이 투자한 금액은 이미 상당금액 개발/디자인비로 소진함3) 서비스 출시 때 시작할 3개의 캠페인은 지인 위주로 정해졌으나 그 이후 캠페인이 잡혀있지 않은 상황4) 팀원들이 서로 친구이고 후배라 너무나 편하게 대한다는 점 (장점인 줄 알았는데 단점이었음) +여기에서 뭐부터 부딪히며 배웠다고 말해야 할지 모를 정도로 잘못한 것들이 정말 많았다.- 현재 재무상황과 각자 투자한 금액 등 제대로 알아보지도 않고 돈을 넣었다- 주주간계약서에는 베스팅도 안 걸려있었다- 돈도 없으면서 쓸데없이 돈을 많이 썼다 (고학력 디자이너 2명 고용 / 비싼 가구 구매 / 비싼 외주 개발)- 선후배와 친구끼리 창업했더니 진지한 토론보다 쉽게 싸움이 일어남- 런칭 외 향후 계획 없음말하자면 총체적 난국이랄까...................차차 다루게 되겠지만 우선 이 포스팅에서는 공동창업에 대해 배운 것들을 정리해보고 싶다친구와의 창업에 대하여일하는 관계로 만나 친해지는 건 괜찮다. 하지만 친한 관계로 만나 일하면서도 친구처럼 대해버리면, 때로 진지한 논의를 해야 할 때 대책이 없는 경우가 생긴다.선후배가 만나니 후배가 내는 의견은 '미숙한 의견'으로 묵살되기 일쑤.친구끼리 만나니 결정 권한이 없이 한 없이 싸우다가 관계가 틀어지기 일쑤.당연히 주변에 유능한 친구들이 있으면 무조건 끌어와야겠지만,최대한 일할 때는 성숙하게 서로를 대하고 결정체계는 명확하게 하는 것이 정.말. 중요하다고 느꼈다.*이후 나올 이야기이지만 미리 말하자면,이제는 기대대표님과 개인적으로도 정말 친하고, 대표님은 나보다 5살이 많은 오빠이지만대표님이 처음 조인했을 때부터 존칭을 사용해달라고 요청했고, 아직도 서로 존칭을 쓴다.호칭이나 존칭 여부가 토론에 있어 은근히 (많이) 중요하다.나이나 기존의 사회적 관계가, 프로페셔널하게 일할 수 없는 환경을 만드는 일은 사전에 꼭 방지하자.창업팀에 조인하게 된다면나는 멋모르고 학벌만 보고 조인했는데 (이후 생각보다 중요하지 않다는 것을 깨달았습니다)경험이 있는 사람이 단 한 명이라도 있으면 좋았겠다 싶다.안 그래도 맨땅에 헤딩인데, 다들 경험도 없을 뿐더러 경영학과조차 나뿐이라 정말 힘들었다 (...)또한 조인하는 당시의 상황 공유을 분명하고 투명하게 해달라고 요구했어야 했다.나는 당시 분명한 상황 공유를 받지 못했었고, 팀에 합류하기 이전에도 그랬다면 이후에도 그럴 가능성이 농후하기 때문이다. 실제로 그 이후에도 한동안 회사 사정에 대한 공유가 불투명했다.주주간계약서를 제대로 쓰자가장 뼈저리게 느낀 부분이다.스타트업 업계에서 베스팅, 베스팅 하는데, 솔직히 우리 다같이 굳건한 마음으로 시작했는데당장 앞도 안 보이는 상황에서 굳이 몇 년 베스팅 걸어가며 지분을 나눠야 하나?답은: 나눠야 한다. 무조건 나눠야 한다아무것도 모르고 베스팅 조건이 없는 동업계약서를 쓰는 바람에 런칭한 지 몇 달만에 팀을 나간 초기 창업자가 3년간 팀을 지킨 나보다 내내 훨씬 많은 지분을 갖고 있었다.만약 크게 성공이라도 했다면 이 얼마나 억울한 일인가(!)(도의상 양보해주지 않을까 했지만 그런 것은 없습니다. 물론 그랬던 분도 있음.)그러니 공동창업이나 창업팀 조인을 고려하시는 분이라면 기존에 창업한 선배들을 찾아가서 이것저것 구체적으로 많이 물어보고 결정을 하셨으면 좋겠다.당시 나는 너무 마음이 급했고, 치기어렸다.#라이비오 #스타트업 #창업 #스타트업합류 #스타트업조인 #스타트업이직 #마인드셋 #경험공유

잔디 이모티콘 디자인하면 빼놓을 수 없는 디자이너BX디자인팀 David을 만나다 반갑다, 데이비드 초이. 오늘 우리가 온 맛집은 어떤 곳인가? 꽤 유명한 집인 것 같다David: 반갑다. 맛있는 인터뷰를 평소 즐겨봤는데 나도 꼭 해봤으면 싶었다. 깊은 감사를 표하고 싶어 평소 즐겨 찾는 ‘역삼역 맛집’으로 왔다. 잔디 사무실 건너편에 있는 이곳의 이름은 ‘호타루’다. 일식 전문점으로 늘 먹어도 질리지 않는다. 명성이 자자해서 그런지 점심시간에는 조금 일찍 나와야 먹을 수 있다. 잔디는 어떻게 지원했나?David: 대학에서 시각 디자인과 애니메이션을 복수 전공했다. 자연스레 졸업 후, 디자인 회사나 애니메이션 회사 지원을 생각하던 중 두 분야 업무를 모두 할 수 있는 곳은 없을까 고민하게 되었다. 그러던 중 잔디 BX(Brand Experience)팀의 채용 공고를 보았다. 메신저 형태의 업무 커뮤니케이션 플랫폼이기 때문에 이모티콘뿐만 아니라 다양한 디자인 업무를 해볼 기회가 있을 거라 생각해 지원했다.▲ 캐나다 곰들이 연어를 즐겨 먹는 이유를 알 것 같다.여담이지만 디자이너라 그런지 디테일을 많이 본다. 잔디의 채용 공고 포스터는 다른 회사보다 더 정성을 다한 우주의 기운이 느껴져 지원을 결정하는데 영향을 미쳤다. 우주의 기운을 담아 잔디에서 맡은 역할을 소개해달라David: BX 팀에 소속되어 온라인 광고, 일러스트레이션, 이모티콘 등 다양한 크리에이티브 작업을 하고 있다. 최근 이모티콘 작업을 하고 있는데 이전에 발표했던 Day and Emily 세트에 이어 신규 이모티콘 세트를 발표할 예정이다. 이 자리를 빌려 잔디 블로그 독자들에게 처음 공개한다. 오! 그렇지 않아도 Daivd이 작업한 이모티콘이 인기가 많다. 새로 나오는 이모티콘에 대한 설명을 부탁한다David: Day and Emily 이모티콘은 ‘캐릭터를 만들어야지!’라는 일념으로 제작되었다면 새로 나오는 이모티콘은 업무 커뮤니케이션에서 적절하게 쓸 수 있는 목적을 달성하겠다는 생각으로 만들었다. 물론, 잔디의 브랜드 아이덴티티에 부합한 이모티콘을 만들고자 많은 노력을 기울였다. 최근 카카오 프렌즈나 라인 프렌즈 등을 보면 캐릭터 사업이 브랜드 인지도를 높이는 주요 전략으로 자리 잡은 것 같다. 전공자가 보기에 어떻게 캐릭터/이모티콘이 브랜드 연상까지 영향을 미치는지 궁금하다David: 음. 잔디를 예로 들어 설명하고 싶다. 우리 브랜드의 에센스는 ‘Lively Collaboration Enhancer’이다. 풀어보면 ‘Lively=유쾌한’, ‘Collaboration=팀워크’, ‘Enhance=개선하다’ 인데, 각 단어에 담긴 의미와 연관 키워드를 도출하고 모으면 MBTI로 하나의 인격체를 설정할 수 있다.▲ 곧 출시 예정인 잔디 신상 이모티콘 (메이드 바이 데이비드 초이)잔디 브랜드 에센스에서 추출할 수 있는 의미와 키워드를 조합하면 유쾌하고 친화력 있는 미래지향적 성향이 나오는데, MBTI에서는 ESTP(모험을 즐기는 사업가)와 매칭된다. 원피스 루피 같은 캐릭터라고 보면 이해가 쉬울지 모르겠다. 아무튼 이런 성향을 캐릭터/이모티콘에 녹아냄으로써 우리 브랜드가 갖고 있는 성격, 방향을 시각적으로 담아내 유저와 소통할 수 있다. 어릴 적 내 자아붕괴에 일조하던 MBTI가 캐릭터에 이용되다니 참신하다. 다른 질문을 하고 싶다. 좋은 이모티콘이란 무엇이라 생각하는지?David: 좋은 이모티콘. 어려운 질문이다. 개인적인 생각이나 이모티콘은 사용자의 커뮤니케이션에서 그들이 원하는 적절한 감정 표현을 제공하고, 대화를 풍성하게 만들어야 한다. 잔디 이모티콘도 제작 초기 단계부터 사람들이 직장 내에서 표현하고픈 감정을 리서치했었다. 또한 잔디 유저를 대상으로 ‘감정표현 공모 이벤트’를 통해 참신한 아이디어도 얻고 사용자의 니즈를 파악하는데 주력했었다. 이모티콘 말고 다른 이야기를 해보자. 이전 맛있는 인터뷰이였던 Harry가 남긴 질문이 있다. 잔디 멤버 중 남들 몰래 연애를 잘할 것 같은 사람은?David: 세일즈 팀의 Scott. 무언가 치밀하고 완벽주의자 같아 사내 연애를 해도 몰래 스르륵 잘할 것 같다. 스르륵.. 쉬는 날엔 무엇을 하는지?David: 이것저것 하는 편이다. 집에서 독서하거나 맛집, 전시회, 여행 다니는 걸 좋아한다. 피규어나 팬시용품에 관심이 많아 홍대 상상마당이나 오브젝트도 자주 가는 편이다. 그리고 힙합 음악 듣는 걸 좋아한다. 앞으로 하고 싶은 일이 있다면?David: 이모티콘을 더 집중해 연구해보고 싶다. 메시지 커뮤니케이션의 형태가 다양하게 변화해 왔듯 이모티콘도 함께 변화해 왔다고 본다. 따라서 이모티콘 분야는 앞으로도 많은 변화가 있을 거라 생각한다. 개인적인 목표라면 실제로 만나 대화하는 것 이상으로 풍부하고 다양한 감정 표현을 할 수 있도록 혁신적인 이모티콘을 만들어 보고 싶다. 마지막 질문이다. 다음 맛있는 인터뷰 대상자에게 하고 싶은 질문이 있다면?David: 예상컨대 다음 인터뷰이 분은 회사에서 어마무시한 존재감을 갖고 있는 분이 될 것 같다. 그분에게 어울릴만한 질문을 하고 싶다. ‘전생에 공주 또는 왕자였을 것 같은 사람은?’ ..고맙다.. 엄청난 질문이다 David: ^^#토스랩 #잔디 #JANDI #디자인 #디자이너 #디자인팀 #팀원 #팀원소개 #팀원인터뷰 #인터뷰 #조직문화 #기업문화 #회사문화 #사내문화