'사용자'에 해당되는 글 2건

  1. 2012.07.09 사용자 지향 조직
  2. 2012.03.14 왜 서비스는 산으로 갈까?

사용자 지향 조직

Gos&Op 2012.07.09 13:24 |
Share           Pin It

오늘날 서비스를 만드는 회사가 어때야한다는 정형적인 기준이나 조건은 없다. 공개 Open이 최고의 덕목처럼 여겨지지만 애플의 고공행진을 설명해주지 못하고, 인터넷 시대에 영원한 베타가 맞는 것같지만 진짜 베타같은 서비스는 사용자의 주목을 받지 못한다. 공개 공유 공짜라는 3공의 패러다임이 현재를 설명해주는 것같지만 그 역트렌드에 편성해서 성장하는 기업/서비스들도 많이 본다. 정답이란 없는 이 세상에서 내 나름대로의 조직론을 펼쳐봐야할 것같다. 또 누군가의 요청도 있었던 터라... 그리고 요즘 계속 생각하는 다음이라는 회사는 뭔가?에 대한 고민에 대한 나름의 관점이라고 볼 수도 있다.

최근에 에런 샤피로의 <유저>라는 책을 읽었다. 그런데 책에서 뭔 말을 하는지 모르겠다. 아니 너무 어이없이 당연한 걸 가지고 장황설을 펼치니 몰입이 안 되었는지도 모르겠다. 어쨌던 서비스의 근간은 유저/사람이다. Serving이라는 것이 사람을 모시는 일이니 당연히 Service는 사람에 대한 것일터... 그러니 그런 서비스를 만드는 조직도 어쩌면 그 근간인 사람/유저에 초점을 맞춰서 분화되고 진화되어야할 듯하다. 그리고 인터넷 서비스라는 것이 기본적으로 기술적인 부분이 많이 가미되기 때문에 기술적인 요소도 무시할 수 없다. 그렇게 서비스와 기술과 사람을 어떻게 하나로 묶어서 또는 그런 조화를 잘 이루는 조직이란 어떤 모습일까?에 대한 여러 상상을 해본다. 이 글에서 밝히는 조직의 모습이 이상적일 수도 없고 어쩌면 현실적일 수도 없다. 그냥 각자가 처한 상황에 맞게 특화된 모습을 가지고 있을뿐이다.

Apple | iPhone 4 | Normal program | Pattern | 1/324sec | 3.9mm | ISO-80 | Off Compulsory | 2012:07:09 13:17:33그냥 글을 적기 전에 메모한 내용.

지금 생각하는 사용자 지향 조직 User-Oriented Organization (서비스지향아키텍쳐 Service-Oriented Architecture에서 차용한 용어다)은 3부분으로 나누어져있다. 3부분으로의 구분은 말 그대로 구분이다. 조직이 3개로 분리되어야 한다는 의미가 아니라, 기능이나 특성상으로 3개로 구분될 수 있을 것같다는 의미다. 그리고 회사라는 조직에 있는 지원부서들은 본 글에서 일단 생략한다. (그들까지 포함시키기에는 글이 너무 복잡해지고... 또 난 그들에게는 관심이 없다. 어느 사이엔가 그들은 스스로 회사의 갑이 되어버렸다. 지랄하고 있네.) 3개의 구분된 그룹을 MANA 그룹, PLOP 그룹, 그리고 TEKI 그룹이라고 이름붙이겠다. MANA 그룹은 말 그대로 management에서 따온 거다. 굳이 경영진을 뜻하는 것은 아니고, 일종의 전략적 판단을 내려야할 그룹을 뜻한다. PLOP은 Planning & Operation이다. 말 그대로 서비스를 기획하고 운영하는 그룹이라는 뜻이다. 그리고 TEKI는 발음에서 연상되듯이 Technical Asset을 담당하는 그룹이다. 처음에는 서비스중심의 회사를 생각하면서 기술기반을 만드는 그룹과 서비스를 기획하는 그룹으로 이원화를 생각했지만, 조금 부족한 것같아서 삼원화 조직을 생각했다. 앞서 말했지만 이들 3개의 그룹은 단순히 분리를 의미하는 것이 아니라, 그냥 구분을 의미하는 것이고, 또 이들이 특화된 기술을 가지고 분화될 것이 아니라 그들의 특화된 기술을 다른 그룹과 조화 Harmonizing시키는 것이 성공적인 사용자지향조직이 될 것인가 아닌가의 관건이다.

참고. 왜 3인가? 3은 최소의 숫자이고 최대의 숫자이다. 어떤 일에 대한 이유를 설명하기 위해서 최소 3가지 이유가 있어야 설득력이 있고, 또 최대 3가지 이유를 넘기면 설명이 구차해진다. 그래서 3이다. 조직이 구색을 맞출려면 3개의 서브 조직이 있어야하고, 또 3개를 넘어가면 조직이 너무 방대해진다. 또 다른 이야기. 로봇 시스템 등의 지능형 시스템 Intelligence System은 보통 3개의 기능/모듈로 구성된다. 여러 학자들이 다양한 용어로 시스템/아키텍쳐를 그렸지만 결론은 3의 기능이다. 주변환경을 관찰하고 정보를 수집하는 Monitoring 또는 Sensing, 그런 관찰된 내용을 바탕으로 의사결정을 내리는 Decision-making, 그리고 결정사항을 실행에 옮기는 Execution이 그거다. 일반 조직에서도 관찰하는 그룹, 의사결정을 내리는 그룹, 그리고 실행하는 그룹이 필요하다.

MANA 그룹. 이 그룹의 역할을 사용자를 비롯한 주변환경을 관찰하는 것이고 그리고 최종 판단을 내리는 그룹니다. 이들 그룹은 Seeing Outside다. 항상 외부를 보고 있어야 한다. 그리고 단순히 주변의 작은 움직임보다는 더 큰 움직임, 전체적인 모습의 변화에 민감해야 한다. 사업이나 기술상의 메가트렌드 Mega-trend를 파악해야 한다. 그리고 사용자들의 Macro-behavior를 늘 주시해야 한다. 전체 맥락을 항상 생각해야 하고, 그런 맥락 속에서 변화를 감지하고, 전략적 판단을 내려야 한다. 그런 판단의 결과가 다양한 투자일 수도 있고 완전히 새로운 서비스 Killing App일 수도 있고, M&A나 구조조정 등의 경영활동일 수도 있고, 때로는 회사정리/법정관리 등의 극단적인 판단일 수도 있다. 그러나 일단 이 글에서는 기술투자와 신규사업/서비스 런칭으로 국한하자. 어쨌든 이 그룹은 전략적 판단을 내려야 한다. 이들이 봐야만했던 메가트렌드는 소셜이나 큐레이션 등의 조금은 단기적인 트렌드의 변화일 수도 있고, 모바일/스마트 세상에서의 회사의 전략적 위치선정 등일 수도 있다.

PLOP 그룹. 이 그룹의 역할은 사용자와 직접적인 인터렉션을 하는 것이다. 사용자들과 늘 접점을 가지고 있어야 하고, 그래서 사용자들의 라이브 니즈를 늘 파악해서 그것을 어떻게 채워줄 것인가를 고민해야하는 그룹이다. 그런 고민의 결과로 여러 작은 새로운 서비스를 기획해내고 또 그것을 운영해나가야 한다. 이들의 주요 업무도 사용자를 관찰하는 (또는 사용자의 피드백을 접수하는) 것이고, 그들에게 피드백을 주는 것이다. MANA 그룹과는 달리 좀 더 단기적인 마이크로 트렌드를 파악하고, 사용자들의 micro-behavior에 늘 주목해야 한다. 그래서 이들의 업무를 Seeing Inside로 정의하겠다. 늘 내부의 서비스의 모습과 그것을 사용하는 사용자의 모습, 불만, 피드백에 초점을 둬야 한다는 얘기다. 전술적 판단과 실행이다. 단기적으로 발생하는 여러 서비스의 오픈이나 개편 등의 통상적인 업무는 이들이 해야할터... 새로운 블로그 서비스를 오픈/개편할 것인가? 아니면 커뮤니티 서비스에 어떤 기능을 더 추가하거나 빼버려야할까? 등의 고민 그리고 그 고민에 따른 실행.. 사용자 지향 조직에서 사용자와 가장 활발한 접점을 가지기 때문에 중요한 위치에 있다.

TEKI 그룹. 이 그룹의 역할은 말 그대로 기술기반을 다지는 거다. 마나그룹의 전략적 판단에 따른 기술기반을 다지는 것도 필요하고, 플롭그룹의 요청에 잘 대응하기 위해서 다양한 기술을 다지는 것도 중요하다. 그뿐만 아니라, 그룹 내에서의 판단에 따라서 여러 기술기반을 다지는 것이 어쩌면 더 필요할지도.. 그래서 난 이들의 Seeing Onside로 표현해볼까 한다. 언제나 준비된 상태여야 한다. 마나의 전략적 판단에서 효과적으로 대응할 수 있어야 하고 플롭의 전술적 판단에도 빠르게 대응할 수 있을려면 늘 준비된 상태여야 한다. 구체적인 예를들자면,빅데이터 기술을 준비해뒀다가 새로운 클라우드 서비스를 만들어낸다거나 아니면 여러 서비스에서 취합된 데이터를 빠르고 효과적으로 분석해서 피드백을 줄 수 있어야 할거다. 로부스트한 추천엔진/알고리즘을 미리 만들어뒀다가 다양한 새로운 서비스에 맞도록 추천시스템을 붙여주는 것도 예가 될 수 있을 듯하다.

T그룹의 덕목은 Uniformity다. 여러 다양한 전략적, 전술적 요구에 균등하게 대응해줘야 한다. 어떤 상황이 발생하더라도 안정된 기술을 지원해줘야한다. P그룹의 덕목은 Diversity다. 늘 사용자들의 다양한 새로운 요구사항을 파악하고 그에 따른 다양한 기능들을 제공해줄 수 있어야 한다. 그리고 M그룹의 덕목은 Intensity다. 즉,늘 초점을 맞춰야 한다는 거다. 그냥 시대의 흐름에 따라서 전략이 전술처럼 바뀌는 것이 아니라, 확고한 믿음을 가지고 있어야 한다. (다음의 경우... 요즘의 실패..왜? 마이피플의 실패..왜? 다음플레이스의 실패...왜? 난 적어도 M그룹의 무능이라 본다. 이디엇) 또 하나. M그룹은 have-to에, P그룹은 love-to에, 그리고 T그룹은 able-to에도 특화된다. 어쩌면... 설명생략.

앞서 말했지만, 위의 세개의 그룹은 단순 구분이지 분리가 아니다. 사람이나 팀을 기능에 따라서 분리해야 한다는 말이 아니다. 그냥 그런 마인드셋을 가진 이들이 필요하다는 거다. 다양한 그룹에 속한 사람들이 한 팀을 이루기도 해야 한다. 그리고 단순히 개발자는 T그룹이고 기획자는 P그룹이다라는 말이 아니다. T마인드셋을 가진 기획자, 운영자도 필요하고, P마인드셋을 가진 개발자도 필요하다. 제대로된 사용자를 위한 서비스를 만들기 위해서는 늘 그렇다. 그리고 M, P, T는 독립 그룹도 아니다. 항상 M-P, P-T, T-M의 조합 (믈론 MPT의 조화는 당연)을 유기적으로 만들어야 한다. MT의 조합으로는 빅데이터분석대응, 모바일환경을 위한 시스템아키텍쳐의 준비와 같은 장기/전략적 기술기반을 만들 수 있고 (기술로드맵), PT의 조합으로는 새로운 사용자 니즈에 맞는 서비스를 빠르게 개발/개변할 수가 있고 (온서비스), MP의 조합에서는 현재 사용자들의 필요뿐만 아니라 장기적인 서비스의 플랫폼화 또는 에코시스템화를 어떻게 준비할 것인가? 또는 그런 플랫폼/에코시스템에서 필요한 서비스는 무엇인가? 등의 다양한 전략전술적 대응을 만들어낼 거다 (서비스로드맵). Key is Connectivity.

사용자를 위한 새로운 서비스를 만들 때 고려해야할 사항은... 흔히들 사용자가 필요한 것을 제공하고 사용자가 원하는 것을 제공해야 한다고 말한다. 맞는 말이다. 필요성 need과 욕구성 want에 더해서 강제성 must이라는 항목도 넣어야할 것같다. 강제성이란 용어는 없다. 그냥 만든 용어다. 필요하기 때문에 그리고 원하기 때문에 그 이상의 또는 그 이하의 mandatory한 부분이 있다. 지금 당장 사용자가 필요로 하지 않더라도 또는 사용자가 원하지 않더라도 있어야만 하는 서비스가 있다. 그런 것은 ROI가 나오지 않더라도 개발하고 제공해야 한다. 적당한 예가 생각나지는 않지만... 사용자의 일상 생활에서의 필요를 충족시켜주기 위해서 다양한 생활정보를 제공하고, 그들의 엔터메인먼트적 욕구를 충족시켜주기 위해서 연예, 스포츠 뉴스를 제공해주듯이, 그들이 (특수계층이 아닌 일반적인 경우) 당장은 관심이 없고 재미없지만 정치경제 뉴스를 함께 제공해주는 것도 어쩌면 이런 이치다. 좌파에게도 가끔은 조중동의 논조를 읽어보도록적어도 기사는 제공해주는 것이 어떤 측면에서의 강제성이다.

암묵적 우연성 Implicit Serendipity와 명시적 우연성 Explicit Serendipity에 대한 것도 아침에 생각했었는데, 일단 패스. 다음이라는 회사는 사용자 (대한민국 그리고 대한국민)들에게 어떤 가치를 주고 어떤 기여를 하고 있는가?에 대한 물음도 그냥 오픈퀘스쳔으로 남기자. 그리고 다음은 사용자를 팬으로 만들 여력이 될까? 그냥 궁금하다. 

댓글을 달아 주세요

Share           Pin It
지금 인터넷에 회자되고 있는 발표자료가 있습니다. KTH의 분산기술Lab의 하용호님 (@yonghosee)이 작성한 '화성에서 온 개발자 금성에서 온 기획자'라는 자료입니다. 자세한 내용은 아래의 자료를 참조하세요. (내용은 그닥. 제목은 굿.) 자료의 제목은 존 그레이의 베스트셀러 <화성에서 온 남자 금성에서 온 여자>를 차용해서 정한 것입니다. 존 그레이가 그의 책에서 남성과 여성의 생각구조가 다르고 그래서 대화가 잘 통하지 않는다는 점을 화성과 금성에 비유해서 풀어나갔듯이, 서비스 개발에서 기획자와 개발자 사이의 소통의 어려움을 같은 식으로 금성과 화성에 비유해서 적고 말하고 있습니다. 화성은 영어로 Mars로 전통적으로 남성을 상징하고 있고, 개발자도 비슷하게 엔지니어링에 기반을 둔 남성적인 측면이 강합니다. 반대로 금성은 영어로 Venus로 여성을 상징하며, 기획자들이 더 인문적 배경을 가진 소프트한 여성적 측면이 강합니다. 그렇게 기획자와 개발자들의 백그라운드가 다르고 대화의 언어가 다르기 때문에 기획자와 개발자 사이의 소통이 어렵다는 것입니다. (자료는 기획자들에게 개발자들이 사용하는 언어/단어를 보여주는 측면이 강합니다.)

기획자와 개발자 사이의 소통이 부재하면 자연스럽게 그들이 기획한 또는 개발한 서비스가 엉망이 될 가능성이 높습니다. '사공이 많으면 배가 산으로 간다'라는 속담과 같이 많은 사람들이 서로의 의견만을 말하다 보면 초기 기획의도를 잊어버리고 영 엉뚱한 서비스가 만들어지기도 합니다. 각자의 요구사항을 맞춰주기 위해서 불필요한 기능들을 하나둘 추가하게 되고, 그렇게 되다보면 처음에 잡았던 서비스의 크기보다 덩치가 엄청나게 커지게 되고, 프로그램의 덩치가 커지면서 사용하는 리소스는 증가하고 속도는 떨어지고... 등등의 이상 현상들이 발생하게 됩니다. 결국은 사용자들이 해당 서비스를 잘 사용하지 않게 되면, 자연스럽게 그런 서비스는 또 다시 대표적인 실패사례라는 주홍글씨를 남긴채 기획/개발에 참여했던 이들에게 아픔을 남기게 됩니다.

그런데 제가 말하고 싶은 것은 과연 기획자와 개발자 사이의 소통부재가 서비스를 망친 직접적이고 결정적인 원인인가?에 대한 의문입니다. 분명 그들 사이의 의견불일치 및 합의부재가 서비스의 품질을 떨어뜨리는 중요한 역할을 하겠지만, 그런 것은 시간이나 리소스를 더 투자해서 합의의 과정을 거치면 다시 정상궤도로 올라올 수가 있는 부분입니다. 서비스가 엉망이 된 결정적인 이유는 기획자는 금성에서 왔고 개발자는 화성에서 왔기 때문보다는 그들이 기획/개발한 서비스를 사용하는 고객/사용자들은 '지구'에 살고 있다는 점입니다. 지구에 살고 있는 지구인 사용자들에게 화성의 언어로 말하고 금성의 생각을 전하기 때문에 서비스는 결국 지구인의 입맛에 맞지 않게 됩니다. 그래서 산으로 간 배를 다시 강/바다에 띄울 수 없게 됩니다. 

서비스의 기획이나 개발 단계에서 사용자는 전혀 생각지도 않고 개발되는 많은 서비스들을 보게 됩니다. 물론 기획자나 개발자들이 스스로 사용자가 되어서 그들의 불편사항을 제거하기 위해서 서비스를 만들 때는 성공하는 경우를 종종 목격하지만, 그렇지 않고 단순히 사용자가 아닌 다른 목적/이유를 가지고 시작한 서비스의 경우 사용자를 배제해서 제대로 성공한 경우를 볼 수가 없습니다. (다른 목적/이유라함은 사용자의 편의나 재미가 아니라, 사업자의 경제적 이득을 취하려는 목적.) 화성인과 금성인 사이의 자연스러운 소통은 단기간에 적은 리소스로 매끄러운 서비스의 개발을 가능하게는 하지만, 그것이 지구인들에게 적합한 서비스가 탄생되었다라는 보장은 할 수가 없습니다. 제대로 된, 그래서 사용자들에게 사랑받는 서비스는 화성인과 금성인 간의 소통보다도 더 화성인과 지구인, 금성인과 지구인 사이의 소통이 더 잘 이뤄졌을 때 가능합니다. 그런 소통 이후에 화성인과 금성인 간의 자연스러운 소통에 따른 결과 서비스는 분명 지구인의 사랑을 받을 것입니다.

지구인 소통하는 방식은 이미 많이 존재합니다. 흔히 많이 사용하는 방식으로 기획/개발 전단계에서 잠재 사용자들을 대상으로 설문조사나 심층인터뷰를 해서 사용자의 요구사항을 수집할 수도 있고, 아이데오 등의 혁신기업들처럼 사용자들의 행동패턴을 그냥 관찰만 하면서 핵심포인트를 찾아내는 경우도 있고, 잘 알려졌듯이 애플의 스티브 잡스처럼 인사이트가 충만해서 고객의 (잠재) 니즈를 바로 캐치하는 경우도 있을테고, 아니면 구글 및 인터넷 기업에서 자주 사용하는 알파/베타서비스와 같이 프로토타입보다는 나은 형태의 서비스를 빠르게 런칭한 이후에 사용자들이 해당 서비스를 이용하는 행동패턴을 분석하고 피드백을 받아서 점진적으로 서비스를 개선하는 방법 등도 있습니다. 어느 방법이 나은가는 각자의 상황에 따라 다르겠지만, 적어도 이상의 한가지라도 활용해서 항상 고객/사용자와 소통을 해야 합니다.

간단하게 요약하면 서비스가 산으로 가는 이유는 금성인 기획자와 화성인 개발자의 소통부재보다는 지구인 사용자를 배제했기 때문일 가능성이 가장 높다는 것입니다.
 

댓글을 달아 주세요