'기술'에 해당되는 글 5건

  1. 2015.06.05 기술 엘리트와 민주화
  2. 2014.12.29 기술의 배신
  3. 2014.08.12 기술과 인간
  4. 2013.11.25 문제와 해법
  5. 2012.07.09 사용자 지향 조직
Share           Pin It
일부 어리석은 자들이 오용하지만 민주화의 숭고함은 절대 훼손되거나 변질되지 않는다. 현재 민주주의가 완벽하다는 의미도, 더 나은 체제가 없다는 얘기도 아니다. 민주화는 그 자체로 숭고하다는 뜻이다.

민주화를 어떻게 정의할 수 있을까? 정치사회사적인 의미는 잘 모르겠다. 그런 것은 백과사전을 찾아보면 나올 것이다. 나의 옅은 지식으로 민주화는 접근권의 개방이라 생각한다. 정치에서 민주화는 일부 특권층이 아닌 모든 자격을 갖춘 시민들이 정치/투표에 참여할 수 있는 참정권을 얻은 것이고, 지난 대선에서 국민을 현혹시킨 경제민주화는 모든 대중들의 음식(부)에의 접근권, 즉 기본 생활을 보장하는 것이다. 같은 식으로 기술의 민주화는 기술, 이 글에서는 PC/모바일 또는 인터넷의 접속권을 뜻한다. 누구나 불평등없이 그리고 제한없이 인터넷에 접속해서 정보를 찾고 의견을 개진할 수 있는 것이 이 글에서 말하는 기술의 민주화다.

일전에 ‘해커스'라는 책을 읽은 적이 있다. 해커스는 디지털 컴퓨터 (메인프레임 등)이 처음 학계를 중심으로 전파되던 시절부터 PC가 번창했던 1970년대부터 8~90년대의 이야기를 다루고 있다. 이 글에서 주목한 것은 1970년대 MIT (맞을 거다)에서 벌어졌던 일이다. 초기에 컴퓨터가 대학교에 설치됐을 때 아무나 접근할 수 없었다. 전담 직원들만 겨우 사용할 수 있었기 때문에 학생들이 컴퓨터를 만지는 것은 상상이 불가능했다. 그러나 초기 해커/긱들은 직원들이 퇴근한 밤 시간을 이용해서 컴퓨터에 접근해서 초기 운영체계, 컴파일러, 응요프로그램 등을 만들었다. 요즘도 여전히 사용하는 많은 개념들이 그 천재 해커들의 열정의 산물이다.

1970년대 컴퓨터는 비싼 장비였고 희귀한 것이었다. 그래서 컴퓨터에 접근할 수 있는 이는 소수의 특권층만이 가능했다. 정치에서 일부 귀족만이 참정권을 독식하거나, 경제에서 부자들만이 빵/땅을 모두 소유해버리는 것과 같이, 기술/컴퓨터에서도 접근할 수 있는 특권층이 존재했다. 아무리 뛰어난 천재라고 해도 당시에 컴퓨터라는 존재 자체도 몰랐을 가능성이 높다. 어쨌든 그런 특권층 또는 엘리트들에 의해서 컴퓨터 산업이 태동했고, 현재 컴퓨터 체계가 완성됐다.

그러나 오늘날은 최소 전기가 통하는 전세계 모든 곳에서 모든 사람들이 다양한 형태로 컴퓨터를 사용할 수 있다. PC를 사용하는 사람도 있고 스마트폰을 사용하는 사람도 있고, 때로는 게임 콘솔을 사용하는 사람도 있다. 스마트워치나 웨어러블기기까지 포함한다면 더 넓은 사용자들이 컴퓨터에 접근할 수 있다. 그리고 컴퓨터에 접근할 수 있다는 의미는 인터넷을 사용하는 것과 거의 같은 의미다. 기술의 민주화를 이룬 셈이다.

물론 기술의 민주화 또는 대중 접근성을 이룩했다고 해서 모든 대중들이 기술에 골고루 접근가능하다는 얘기는 아니다. 단편적으로 웹의 컨텐츠를 만드는 것을 예로 들자면, 100명의 사용자가 있다고 가정했을 때, 실제 컨텐츠를 만들어내는 사람은 10%정도에 불과할 것이고 그리고 대부분의 컨텐츠는 단 1명에 의해서 만들어진다. 그 나머지 90명은 그저 그렇게 만들어진 컨텐츠를 소비하는 층이다. 그러나 대중화를 통해서 90명 중에 누구나 10명 또는 1명이 되는 통로는 마련됐다는 점에서 기술이 민주화됐다고 표현한 것이다. 뿐만 아니라, 나머지 90명이 만들어내는 like, 더 수동적으로 PV가 10명 그리고 1명이 새로운 컨텐츠를 만들어낸 원동력되 되기도 한다. 지금 적고 있는 글을 아무도 읽지 않는다면 내가 굳이 이 글을 적어서 블로그나 페이스북에 공유할 이유가 없다.

그런데 여기서 의문이 들었다. 기술의 발전은 소수의 엘리트들에 의해서인가 아니면 민주화된 대중에 의해서인가?라는 의문이다. 초기의 천재 엘리트들이 이룩한 성과와 오늘날 대중이 이룩한 성과를 단순 비교할 수는 없겠으나, 향후 이 분야의 발전은 누구에 의해서 이뤄질까?를 생각할 수 밖에 없다. 초기 엘리트들은 어쩌면 우리와 너무 동떨어진 존재인 듯하니, 요즘 인물로 페이스북의 저커버그나 구글의 페이지나 브린 같은 인물들이 현재 기술을 주도하고 있는 것일까 아니면 수많은 창의적인 컨텐츠를 만들어서 버즈시키는 대중들이 기술을 주도하는 것일까? 이 시대의 이 기술의 동인은 누구에게 있을까?

엘리트들에게 있다라고 말하기도 어렵고 대중에게 있다라고 말하기도 참 어렵다. 민주화된 사회에서도 여전히 엘리트가 필요하고, 엘리트도 대중이 없이는 엘리트의 지위를 얻지 못한다. 이 글을 통해서 결론을 내리고 싶지는 않았다. 그저 며칠 전에 모든 사람들이 컴퓨터를 사용하고 인터넷에 접근하는 기술 민주화가 이뤄진 것이 아닌가?라는 생각을 했고, 전에 읽었던 해커스의 천재들이 떠올랐을 뿐이다. 그래서 엘리트와 대중의 역할에 대해서 궁금했고, 이 궁금증에 대한 오픈 퀘스천을 던지려고 글을 적었을 뿐이다.

기술의 엘리트와 민주화라는 화두를 던진다. 이것이 좋은 생각거리가 되리라 믿는다.

===


댓글을 달아 주세요

기술의 배신

Gos&Op 2014.12.29 09:53 |
Share           Pin It

기술은 언제나 우리를 배신할 준비가 되어있다.

지난 금요일에 페이스북에 적었던 문구인데 왜 이걸 적었는지 그 순간이 기억나지 않습니다.

단순히 공상과학에서 그리듯이 암울한 미래를 의미하지는 않습니다. 스카이넷이나 빅브라더도 우리를 배신한 것인 하겠지만 어쩌면 그것보다는 더 소소하고 어쩌면 하찮은 형태로 우리를 배신할지도 모릅니다.

소위 말하는 창조적 파괴 (와해기술 disruptive technology)를 의미하기도 합니다. 하나의 플랫폼을 장악했다고 안주하고 있는 사이에 누군가 새로운 플랫폼을 가져와서 시장의 독점을 깨부수고 결국에는 이전 기술의 멸종에 이르게 할지도 모릅니다. 기술의 배신은 누군가에게는 치명상을 입히겠지만 또 다른 누군가에게는 밝은 미래를 약속합니다.

어쩌면 더 작고 소소한 형태일 수도 있습니다. 기존에 익숙하던 프로그래밍 언어가 새로운 것으로 대체될 수도 있습니다. 현재 늘리 사용되는 언어는 또 언젠가는 새로운 형태의 언어에 점령되기 마련입니다. 컴퓨터의 발전 방향에서 어쩔 수 없이 대체된 경우도 많았지만, 발전 방향과 별로 무관한 형태인 경우도 많습니다. 지금 어떤 분야에 특화된 전문가라고 자랑하는 순간 또 다른 형태의 기술이 나의 전문성을 퇴화시켜버립니다.

늘 패러다임의 변화를 겪으면서 역사가 발전합니다. 기술의 배신을 즐기시기 바랍니다.

==

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

기술과 인간

Gos&Op 2014.08.12 18:09 |
Share           Pin It
"길게 잡아서 2년 내에 당신이 하고 있는 일의 절반 이상을 자동화시킬 수 있어야 한다."

최근 함께 일하고 있는 친구에게 한 말입니다. 미디어다음에서 뉴스를 편집운영하면서 뉴스추천 프로젝트를 메인으로 기획한 친구입니다. 제대로 된 뉴스 편집 및 운영은 끊임없이 쏟아지는 모든 뉴스를 읽고 미담이나 다음탑에 노출시킬 것인가 말것인가를 계속 판단해야 하는 사람손을 많이 타는 일입니다. 그럼에도 불구하고 이 활동의 절반 이상을 단기간 내에 자동화시키고 그 친구는 다른 더 창의적인 생각에 집중해야 한다는 말입니다.

비단 이 친구에게만 들려주고 싶은 말은 아닙니다. 지난 글(참고. 기획에 대해서)에서처럼 함께 일하고 있는 모든 기획자들에게 같은 조언을 해주고 싶습니다. 물론 개발자라고 해서 예외는 아닙니다. 성격이 조금 다를 뿐 허투루 허비하는 많은 잡다한 일들은 자동 영역에 맡기도 늘 새롭고 창의적인 사고, 실행에 집중해야 합니다. 2년이란 시간도 길게 잡은 것입니다. 그만큼 절박한 생존의 문제입니다.

흔히 자동화를 통해서 기계 또는 컴퓨터가 사람을 완전히 대체해버리는 것을 생각합니다. 지구 상의 누군가는 그런 완전무결한 자동화를 꿈꾸고 실현하기 위해서 연구하고 있을 것입니다. 그들의 노력에 찬사를 보내고 좋은 결실을 맺을 것을 바랍니다. 설령 그렇게 되어 내가 할 수 있는 일이 없어진다고 해도 그런 현실을 받아들일 자세가 되어있습니다. 그러나 이 글에서 자동화란 사람을 완전히 대체하는 로봇을 얘기하는 것은 아닙니다.

데이터 마이닝이라는 파트에서 일하다 보니 사람들은 데이터 마이닝을 좀 경외의 대상으로 생각하는 것같습니다. 뭔가 복잡하고 어려운 분야라고 생각합니다. 그래서 회사에서 데이터마이닝/분석을 한다고 말하면 데이터마이닝에 대해서 조금 더 관심을 보이기 전에 손사레를 치고 외면해버립니다. 그러고선 이제껏 편하게 해왔던 일로 돌아섭니다. 그런 두려움과 미신이 저같은 허름한 분석가를 (분석가의 역할을) 보호해주는 것같아 내심 안도하면서도 조금 씁쓸하기도 합니다.

어떤 측면에서 학계를 중심으로 발전시킨 데이터마이닝은 조금 복잡하기도 합니다. 일상에서 전혀 들어볼 수 없는 어려운 용어들로 가득 차있고, 하나의 개념이나 알고리즘을 이해하기 위해서는 선행해서 알아야 하는 지식이 한가득입니다. 그리고 어떤 측면에서는 연구가들은 일부러 더 어려운 용어를 만들어내고 간단한 설명도 복잡한 수식으로 표현하는 것같습니다. 학교에서 농담삼아 얘기했던 건데, 복잡한 증명문제를 그저 'It's trivial'이라고 말하고 증명을 생략하는 경우도 있습니다. 논문 하나를 이해하기 위해서 엮인 많은 논문을 읽어야 하고, 그 참조 논문들을 이해하기 위해서 또 엮인 것들을 읽어야 합니다.

사무실이 조금 추운 것같아서 건물 밖을 한 바퀴 돌면서 생각했습니다. 어쩌면 정작 사람들에게 필요한 기술은 정교하고 복잡한 알고리즘이 아닐 수 있다는 생각입니다. 서두에 말한 자동화도 그렇습니다. 내가 하고 있는 일을 완전히 대체하는 개념의 자동화가 아니라, 내가 하고 있는 일을 더 빠르고 편하게 도와주고 그렇게 해서 절약한 시간을 다른 곳에 집중할 수 있게 해주는 그런 종류의 자동화입니다. 

데이터 기반의 기획이 그렇습니다. (당장은) 아무리 좋은 알고리즘을 개발하더라도 기획자의 역할을 완전히 대체할 수 없습니다. 그러나 적당한 데이터 가공만으로도 그들의 잡다한 수고를 덜어줄 수가 있습니다. 기획자가 자신의 일의 50%이상을 자동화해야 한다는 의미도 어떤 제품/서비스를 만들어낼 것인가만 고민할 것이 아니라, 어떤 도구나 데이터가 있으면 내가 만들고자 하는 서비스/제품을 미리 검증해보고 상상하는데 도움이 될 수 있을까를 고민하는 것입니다. 그런 고민으로 자신의 일을 경감시켜줄 데이터나 도구를 마련한다면 2년 후에는 한차원 높은 기획자가 돼있으리라 생각합니다.

서비스를 준비하면서 여러 논문을 다시 찾아봅니다. 참 읽기 어렵습니다. 인트로까지는 쉽게 읽게는데 그 이후는 내가 논문을 읽고 있는 것인지 아니면 그냥 시간을 보내는 것인지 분간할 수 없는 때가 종종 있습니다. 이런 경험이 쌓여갈수록 내가 만들어내는 알고리즘도 복잡한 수식으로 이뤄진 거창한 무언가가 돼야 한다는 헛생각에 사로잡히기도 합니다. 그러다 보니 간단하게 해결할 문제를 이것저것 새로운 요소들을 갖다붙여서 복잡한 솔루션으로 만들어 냅니다. 마치 알고리즘/솔루션의 복잡함이 나의 위대함을 나타내는 증거인양... 그렇게 해서 큰 효과가 있다면 다행이지만, 그저 간단한 수식이나 몇몇 요소로 해결했을 때보다 더 나아졌다는 보장이 없는 경우가 많습니다. 그래서 간단한 기술, 쉬운 알고리즘이 더 사람에게 필요한 것일 수 있다는 생각으로 다시 돌아왔습니다.

요즘 빅데이터 기술로 인해서 난해한 문제나 알고리즘을 사용할 수 있게도 됐지만 (예를들어 최근 많은 관심을 받는 딥러닝 Deep Learning같은), 오히려 간단한 더하기, 빼기, 곱하기, 나누기 즉 사칙연산만으로도 많은 문제들이 해결되고 있습니다. 그리고 간단한 알고리즘/연산으로 빠른 시간에 해결하는 것이 조금 더 정확한 예측보다 더 유용할 때가 많습니다. 엔지니어링이란 복잡함을 감추는 과정이지만 그것 자체도 굳이 복잡할 필요는 없습니다.

글을 적으면서 여러 논점이 섞였습니다. 기술은 필요에 따라서 복잡해질 수 있습니다. 그 복잡함을 재고하고 정작 인간에게 필요한 것이 뭘까를 고민하게 됩니다.

기술은 인간을 대체하는 것이 아니라 보완합니다. 미리 겁먹을 필요는 없습니다.

==
페이스북 페이지: https://www.facebook.com/unexperienced


댓글을 달아 주세요

문제와 해법

Gos&Op 2013.11.25 19:29 |
Share           Pin It

페이스북에 짧게 적었던 글을 좀 길게 적습니다.

---

지난 밤에 읽은 책에서 (전체 내용과 관계가 적으므로 책 제목은 생략합니다) "과학자는 해법을 찾은 뒤에 그것을 적용할 문제를 고민하는데 반해, 엔지니어는 문제를 규정한 이후에 해법을 찾는다는 차이가 있다"라고 적혀있었다. 순수학문과 응용학문의 차이를 잘 설명해준다.

똑같지는 않지만 비슷한 고민을 오랫동안 해왔다. 나는 또는 내가 속한 팀은 기술 스택에 집중해서 다양한 기술을 연마하거나 알고리즘을 개발해서 서비스 분야에 접목을 시켜야 할지 아니면 서비스 스택에 더 집중해서 도메인/비즈니스 지식을 쌓은 후에 다양한 기술/알고리즘을 차용해서 현재의 문제를 해결해야 할지를 결정해야 했다. 현재 이도저도 아닌 어중간한 상태에 머물러 있어서 갈피를 못잡고 표류하고 있는 듯하다.

인터넷 서비스 회사를 다니는 사람들이라면 비슷한 고민을 하고 있을 것이다. 매일 새로운 기술이 쏟아지고 트렌드는 급변하는 상황에서 기술적 완성도도 어정쩡하고 서비스의 디테일도 어정쩡한 상태에 이른 경우가 많을 것이다. 기술에 집중하자니 발등에 떨어진 불이 너무 커고, 그렇다고 발등의 불부터 꺼자니 시대에 뒤떨어지는 악순환이 이어진다. 작은 조직에서는 이 둘을 동시에 해결해야하기 때문에 어렵다. 그러나 웬만큼 큰 조직에서는 팀별로 성격을 나눠서 전문성을 가질 수 있고, 또 가져야 한다. 그래야지 기술 스택과 서비스 스택이 명확히 세워지고, 필요에 따라서 서로 결합해서 새로운 것을 창조할 수가 있다.

우리 팀의 핵심이 뭘까?를 항상 고민한다. 윗선에서 제대로 된 비전을 보여준다면 그것을 믿고 따르면 되겠지만, 최근 분위기가 녹록치가 않다. 그렇기에 혼자서 고민하는 것같다. 팀의 정체성은 팀이 맡고 있는 서비스일까 아니면 팀이 가지고 있는 기술/지식일까? 팀의 core competence가 뭘까를 고민하게 된다. 팀의 핵심 역량을 정하고 그것을 극대화시킨 이후에, 다른 영역에 적용을 하거나 아니면 다른 영역의 기술을 차용해야 방향이 잡힌다. 그러나 그러지 못하는 경우가 허다하다. 실질적으로 대부분이 그럴 것이다.

확실한 기술을 가지고 있으면 웬만한 문제에는 적용이 가능하고, 또 괜찮은 서비스/문제를 쥐고 있으면 또 다양한 기술들을 적용해볼 수가 있다. 그렇기에 (큰) 조직에서는 기술스택과 서비스스택을 명확히 구분해서 서브유닛별로 명확히 할 필요가 있다. 그리고 특화된 유닛끼리는 문제/상황에 맞도록 적절히 조화를 이뤄서 새로운 서비스를 만들어내거나 당면한 문제를 해결할 수가 있어야 한다.

(개인적으로) 스페셜리스트보다는 제너럴리스트를 더 선호하지만, 한두가지의 스페셜한 기술이 없는 제너럴리스트는 결국 허상을 쫓게 되고, 역으로 일반적인 시각이 없는 스페셜리스트도 그 길이 잘못되었다고 (늦게) 판명이 나면 필망에 이른다.

올바른 해답은 올바른 문제/질문에서 시작된다. 물론 문제가 옳다고 해서 옳은 해답을 찾는다는 보장은 없다. 그러나 잘못된 문제에서 옳은 해답을 찾을 수는 결코 없다. 그렇다면 올바른 문제부터 찾아야 하는 걸까? (기술에 특화된 조직이 아닌 또는 원천기술이 없는) 작은 조직이라면 문제를 먼저 찾아야 한다. 투명하게 정보 (지식)가 공유되는 요즘 시대에, 문제가 잘 정의되면 적당한 답을 찾는 것은 별로 어렵지가 않다. 그러나 그런 경우 자기만의 해답을 찾지 못할지도 모른다.

저의 개인적인 성향은 서비스 오리엔테이션입니다. 그리고 요즘은 데이터 사이언스라고 부르기도 하지만, 현실에서 데이터마이닝은 데이터 엔지니어링에 더 가깝고, 그래서 비즈니스/도메인 지식과 데이터 자체에서 오는 인사이트가 많이 필요합니다. 그러나 좀더 사이언스적인 접근을 해보고 싶다는 욕구도 있습니다. 팀 자체의 아이덴터티가 예전과 많이 바뀐 상황에서 여전히 한두개의 서비스에만 매여있으면 안 될 것같습니다.

글을 적다보니 논점이 자꾸 흐려진다. ... 어쨌든 현재 나 또는 우리 팀은 해법을 찾는 것에 집중해야 한다고 생각한다. 그러나 분위기가 그렇지 못 하다.

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

사용자 지향 조직

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에 대한 것도 아침에 생각했었는데, 일단 패스. 다음이라는 회사는 사용자 (대한민국 그리고 대한국민)들에게 어떤 가치를 주고 어떤 기여를 하고 있는가?에 대한 물음도 그냥 오픈퀘스쳔으로 남기자. 그리고 다음은 사용자를 팬으로 만들 여력이 될까? 그냥 궁금하다. 

댓글을 달아 주세요