Paper: Dotted version vectors: Logical clocks for optimistic replication (Part 2)

Paper: Dotted version vectors: Logical clocks for optimistic replication (Part 1)

A Kernel for Eventual Consistency

인과성을 이용하는 분산 스토리지의 동작에 있어서 논리적 시계 집합에 대한 sync 와 update 2개의 오퍼레이션이 핵심을 이루고 있다고 주장하고 있다.

먼저 sync 오퍼레이션의 경우에는 두 개의 시계 집합을 취해서 두 집합의 원소들인 논리적 시계들 사이에 인과성의 관계가 있다면 이전에 해당하는 시계를 모두 버리고, 남아있는 원소들로 구성된 집합을 반환하는 오퍼레이션이다. 결과적으로 반환되는 집합은 동시적 (concurrent)인 관계에 있는 시계들로만 이루어지게 된다.

sync는 클라이언트와 서버 도는 서버의 노드들 사이의 동기화가 필요한 시점에 논리적 시계에 기반해서 과거의 값들을 버리기 위한 오퍼레이션이라고 볼 수 있다. 여기서 재미있는 것은 sync는 논리적 시계가 실제로 어떻게 구현되어있는지에 상관없이 시계들 사이의 부분순서 (partial order)만을 이용해서 일반적으로 정의할 수 있다는 것이다.

sync_defined_by_partial_order

 

update 오퍼레이션은 어떤 시계 집합 (통상적으로 클라이언트)과 서버의 어떤 노드의 시계 집합, 서버의 식별자를 취하고 하나의 시계를 반환하는 오퍼레이션이다. 이 시계는 클라이언트 시계 집합 내의 모든 시계들을 dominate하고, 시스템 내의 시계들의 어떤 join에 의해서도 dominate되지 않아야 한다. (즉, dominate하거나 concurrent 해야한다.)

인과적인 이력 (causal histories)의 경우, update 오퍼레이션은 다음과 같이 정의할 수 있다. 시스템 전체에서 고유한 사건 식별자를 얻어서 클라이언트 시계 집합의 각 시계에 추가하는 방식이다.

update_operation_of_causal_histories

이어서 분산 스토리지의 get/put 오퍼레이션에서 위에서 정의한 sync/update 오퍼레이션을 이용해서 논리적 시계를 어떻게 다루는지에 대해서 설명하고 있으나 여기서는 생략하기로 하자.

Dotted Version Vectors

버전 벡터가 (id, m)의 형태로 표기된다면 dotted version vector는 (id, m, n)과 같이 표기할 수 있다. 버전 벡터가 연속적인 인과적인 이력을 표현하고 있다면, dotted version vector는 그 연속적인 이력에 n에 해당하는 독립적인 사건을 추가한 것을 표현할 수 있다.

dotted_version_vector_definition

 

예를 들어, {(a,2),(b,1),(c,3,7)}이라는 dotted version vector는 {a1, a2, b1, c1, c2, c3, c7}와 같은 인과적인 이력을 표현하고 있다.

dotted version vector를 인과적인 이력으로 정의했다면, 부분순서가 어떻게 정의되는 지를 살펴볼 때다.

dotted_version_vector_partial_order

 

 

dotted version vector를 인과적인 이력으로 변환해서 생각하면 당연한 결과라고 할 수 있다.

부분순서가 정의되어있으므로 sync 오퍼레이션은 추가적으로 정의할 필요가 없으나, update 오퍼레이션은 dotted version vector에 대해 정의할 필요가 있다.

dotted_version_vector_update_function

 

이 간결한 식에 매우 많은 의미를 담고 있는데, 합집합(union)의 좌항의 경우, 클라이언트의 시계집합(S)에 속하는 노드의 식별자들 중 파라미터에서 제공한 노드의 식별자 (r)가 아닌 것들에 대해서,  각각의 식별자와 클라이언트 시계집합에서 해당 식별자에 대한 가장 큰 sequence를 pair로 하는 버전 벡터들을 나타낸다. 우항의 경우에는 파라미터에서 제공한 노드의 식별자(r)에 대한 dotted version vector를 구성하고 있는데, 좌항의 경우와 유사하게 첫번째 정수는 클라이언트의 시계집합에서 해당 식별자에 대한 가장 큰 sequence가 된다. 양쪽 모두 클라이언트의 문맥을 표현하는 것이라고 볼 수 있다. 두번째 정수는 조금 특이한데, 파라미터에서 제공한 노드의 시계 집합에서 역시 해당 노드의 식별자에 대한 가장 큰 sequence를 얻은 후 1만큼 증가시켜준 값으로 설정된다. 이는 노드 상의 문맥에서 업데이트로 인한 새로운 사건을 기록한 것이라고 볼 수 있다.

이러한 update 오퍼레이션을 그대로 적용하면 다음과 같이 아름답게 움직이는 시스템이 된다.

dotted_version_vector_operations

 

논문에서는 dotted version vector에 대한 correctness에 대해서 설명하고 있는 듯 하나 생략하도록 한다. 이 논문을 여러번 다시 읽어보았지만 dotted version vector가 어떻게 문제를 해결하는지에 대한 직관적인 설명을 하는 것이 아직도 어려운 것 같다.

dotted_version_vector_reason_of_correctness

Related Work

  • Lamport clock
    • L. Lamport, “Time, clocks and the ordering of events in a distributed system,” Communications of the ACM, vol. 21, no. 7, pp. 558–565, Jul. 1978.
      • http://blog.lastmind.net/archives/720
  • Version vector
    • D. S. Parker, et al., “Detection of mutual inconsistency in distributed systems,” Transactions on Software Engineering, vol. 9, no. 3, pp. 240–246, 1983.
  • Vector clock
    • C. Fidge, “Timestamps in message-passing systems that preserve the partial ordering,” in 11th Australian Computer Science Conference, 1989, pp. 55–66.
      • http://blog.lastmind.net/archives/736
    • F. Mattern, “Virtual time and global clocks in distributed systems,” in Workshop on Parallel and Distributed Algorithms, 1989, pp. 215–226.
  • Dynamic creation and retirement of vector entries
    • R. A. Golding, “A weak-consistency architecture for distributed information services,” Computing Systems, vol. 5, pp. 5–4, 1992.
    • K. Petersen, et al., “Flexible update propagation for weakly consistent replication,” in Sixteen ACM Symposium on Operating Systems Principles, Saint Malo, France, Oct. 1997.
    • P. S. Almeida, et al., “Interval tree clocks,” in Proceedings of the 12th International
      Conference on Principles of Distributed Systems, ser. OPODIS ’08. Berlin, Heidelberg: Springer-Verlag, 2008, pp. 259–274.
  • Scalability problems
    • B. Charron-Bost, “Concerning the size of logical clocks in distributed systems,” Information Processing Letters, vol. 39, pp. 11–16, 1991.
    • D. H. Ratner, “Roam: A scalable replication system for mobile and distributed computing,” Ph.D. dissertation, 1998, uCLA-CSD-970044.
    • R. Prakash and M. Singhal, “Dependency sequences and hierarchical clocks: Efficient alternatives to vector clocks for mobile computing systems,” Wireless Networks, pp. 349–360, 1997, also presented in Mobicom96.
    • P. Mahajan, S. Setty, S. Lee, A. Clement, L. Alvisi, M. Dahlin, and M. Walfish, “Depot: Cloud storage with minimal trust,” in OSDI 2010, Oct. 2010.
    • D. Malkhi and D. B. Terry, “Concise version vectors in winfs,” in DISC, ser. Lecture Notes in Computer Science, P. Fraigniaud, Ed., vol. 3724. Springer, 2005, pp. 339–353.
    • V. Ramasubramanian, et al., “Cimbiosys: a platform for contentbased partial replication,” in Proceedings of the 6th USENIX symposium on Networked systems design and implementation. Berkeley, CA, USA: USENIX Association, 2009, pp. 261–276.
    • F. J. Torres-Rojas and M. Ahamad, “Plausible clocks: constant size logical clocks for distributed systems,” Distributed Computing, vol. 12, no. 4, pp. 179–196,
      1999.
  • Trade-off
    • B. B. Kang, R. Wilensky, and J. Kubiatowicz, “The hash history approach for reconciling mutual inconsistency,” in Proceedings of the 23nd International Conference
      on Distributed Computing Systems (ICDCS). IEEE Computer Society, 2003, pp. 670–677.

 

Spotify's Engineering Culture

Spotify engineering culture (part 1) from Spotify Labs

이미 잘 알려진 서비스인 Spotify는 2008년에 창업해 2010년에 어느 정도 규모의 서비스 (1000만 사용자)에 도달, 2013년 연간 활성 사용자가 2400만명인 서비스이고, 현재 회사의 규모는 1200명 수준의 조직으로, 이제는 어느 정도 성숙해져가고 있는 엔지니어링 조직을 가지고 있는 회사라고 말할 수 있을 것 같습니다.

현재 몸을 담고 있는 회사의 문화와도 닮은 부분이 많이 있어서 공감도 되고, 두고두고 엔지니어링 문화의 지향점에 대해서 생각할 수 있는 기회가 되는 듯 해서 정리를 한번 해둡니다. 불과 10분 남짓한 비디오이므로, 엔지니어링 문화에 관심이 있다면 비디오를 반드시 한번 쯤은 시청해두면 좋을 듯 합니다.

1. Make Rules Optional

초기에는 Scrum을 사용하는 팀 문화를 가지고 있었다고 하나, 어느 순간 이러한 프랙티스들이 오히려 방해가 되었다고 합니다.

make_rules_optional

그래서, 규칙을 강제하지 않고, 프랙티스 보다는 원칙, Process Master보다는 Servant Leader를 강조하는 문화를 도입했다고 합니다.

principles_over_practices

2. Autonomous Squad

Scrum Team이었던 조직을 Squad라고 이름을 바꾸었다고 하는데요. (이름이 참 마음에 드네요!) Squad의 핵심은 자율성(autonomy)입니다. Squad는 보통 8명 이하의 작은 조직이지만, cross-functional한 조직으로 디자인, 개발, 디플로이, 유지보수, 운영에 이르기까지 end-to-end responsibility를 가지고 있다고 합니다.

autonomous_squads

Squad는 미션이나 관련된 제품에 대한 전략 등의 장기적인 미션을 가지고 있으면서도, 무엇을 어떻게 개발할 지(what to build, how to build)에 대한 단기적인 목표도 분기별로 정해진다고 합니다.

사무실은 협력을 최대한 도와줄 수 있도록 최적화되어있다고 합니다. Squad 내에서 팀원들은 서로의 모니터를 쉽게 볼 수 있도록 배치되어있으며, 계획 등을 할 수 있는 라운지가 있고, 모든 벽은 화이트보드로 되어있다고 하네요.

3. Autonomy vs. Alignment

자율성이 중요한 이유로 2가지 이유를 들고 있습니다. 하나는 동기부여(motivating)이고 다른 하나는, 결정이 내부에서 이루어지고, 의존 관계나 조율 등을 위해 다른 조직을 기다릴 필요가 없기 때문에 빠르다(fast)는 것입니다.

그렇다고 해서 회사와는 아무런 상관도 없이 흘러가는 조직이 아니라, Loosely coupled, Tightly aligned squads를 지향합니다. (Aligned autonomy!)

Autonomy와 Alignment가 서로 반대 극에 있는 개념이 아니라, 아래와 같이 다른 차원의 문제로 해석하고 있고, 오히려 Alignment로 인해 Autonomy가 가능해진다고 얘기하고 있습니다.

리더의 책임은 무엇이 해결해야할 문제이고, 왜 해결해야하는지에 대해 커뮤니케이션하는 것, Squad의 책임은 가장 좋은 해결책을 찾기 위해 서로 협력하는 것이라고 얘기하고 있습니다.

alignment_vs_autonomy

4. Cross-pollination over Standardization

pollination이란 식물의 (생식 수단으로서의) 수분을 말하는 것인데요. 어떠한 프랙티스나 도구를 전체 조직으로 표준화해버리기 보다는 하나의 조직에서 좋은 프랙티스를 도입하거나 도구를 개발하고, 이를 다른 조직에서도 채용하기 시작하고, 그것을 지원하고, 결국 de facto 표준이 되는 문화를 얘기하고 있습니다. 일관성(consistency)와 유연성(flexibility) 사이의 좋은 trade-off를 찾는다고 하네요.

cross_pollination

5. Internal Open-source Model

Spotify 내의 각각의 시스템들은 가능한한 작고 서로 decouple되도록 유지하려고 한다고 합니다. 각 시스템들은 하나 또는 몇몇 squad가 담당하고 있다고 하는데요.

만약 어떤 squad가 다른 squad가 담당하고 있는 시스템의 개선이 필요하다면 그 squad에 부탁하면 되지만, 만약 그 squad가 너무 바쁘다면 이를 기다릴 필요가 없다고 합니다. 오픈 소스 모델로 직접 수정을 하고 peer review를 받으면 되는 것 같습니다.

internal_open_source_model

6. People over *

동기부여(motivation)에 집중을 한 이후에 만족도 조사가 상승했다는 결과를 얘기하고 있습니다.

7. Community over Structure

Squard들은 위에서 얘기한대로 cross-functional 팀이지만, 역량 분야 (competency area)에 따른 Chapter라는 조직이 있는 매트릭스 조직 (matrix organization)으로, 자신의 팀장을 바꾸지 않고도 Squad를 바꿀 수가 있다고 합니다.

그리고, Squad나 Chapter와는 상관없이 서로 관심사를 공유하는 사람들은 Guild라는 가벼운 레벨의 interest group을 구성한다고 합니다.

tribe_structure

계층적인 조직 구조(structure)보다는 좀 더 커뮤너티(community)와 같은 문화를 지향하는 것을 다음과 같은 말로 요약하고 있습니다.

“If you need to know exactly who is making decisions, you are in the wrong place.”

8. Small, Frequent, Decoupled Release

릴리즈가 정말로 힘들었다라고 하는 경험을 돌아보면 많은 경우 장기간에 걸친 커다란 릴리즈였던 경우였기 때문에, 저도 작은 릴리즈를 굉장히 선호하는 편인데요. 이제는 이러한 방식이 여러 회사들에서 자리잡고 있는 것 같습니다.

small_frequant_releases

여러 squad의 결과물이 하나의 제품 화면을 구성하는 경우에도, 이를 별도로 릴리즈할 수 있도록 하고 있다고 합니다. UI 또는 시스템적으로 먼저 의존 관계를 제거화고 이를 유지할 수 있어야만 가능한 이야기라고 생각하기 때문에 굉장히 놀라운 이야기로 들리네요.

decoupled_releases

9. Self-service model

하나의 조직에서 다른 조직으로 서비스를 제공하는 방식으로 다른 조직으로 책임을 완전히 넘기는 것이 아니라, 방법을 마련해주고 실제로 실행은 그 조직에서 하는 방식입니다. 커다란 회사에서는 오히려 생존을 위해서 내부 제품을 개발하는 조직도 내부 서비스 조직으로 탈바꿈하는 경우가 있었는데, 다시 생각해볼 문제인 것 같네요. 조직이 커져가는 과정에서 어떤 형태로든 내부 서비스에 대한 concern의 분리는, 그 품질에 나쁜 영향을 준다고 생각하고 있는데, Self-service model도 그 대안 중 하나가 될 수는 있겠네요.

self_service_model

10. Release trains + Feature toggles

개발 완료되지 않은 기능들을 릴리즈에 포함하지만 이를 서비스에 나타나지 않도록 기능을 on/off할 수 있다고 합니다. 완료되지 않은 기능을 릴리즈하는 것이 조금 이상하게 생각될 수 있겠지만, 이를 통해 좀 더 일찍 통합 문제 (integration problems)를 발견할 수 있고, 적지 않은 개발 비용이 발생하는 code branch를 최소화할 수 있다고 얘기합니다.

release_train

11. Trust > Control

최근 수년간 ‘Agile at scale’이 유행하고 있었는데, 이를 위해서는 ‘Trust at scale’이 필요하다고 얘기하고 있습니다. 두려움은 단지 신뢰를 없애는 것이 아니라, 혁신도 불가능하게 만든다고 얘기하고 있습니다. (fear doesn’t just kill trust, it kills innovation.)

trust_over_control

ext2 attributes

특정 리눅스 배포판 (e.g. CentOS 5) 의 중요 파일에는 (e.g. /etc/sudoers) ext2의 immutable attribute가 설정되어 있다.

ext2 파일시스템 내부적으로는 ext behaviour control flags이라고 부르는 것으로 보인다.

lsattr, chattr을 사용해서 ext2 attributes를 조회하거나 설정할 수 있다.

대규모 장비에 대한 환경을 운영해야 한다면, immutable attribute를 활용해보는 것도 괜찮을 것 같다. (e.g. 계정 공통 bash이나 vim 설정)

@ 그나저나 요즘은 리눅스 커맨드도 위키피디아에 나오는군.

Movable Type 4.2 Upgrade

Movable Type 4.2로 업그레이드 했습니다. 4.2에서 변경된 점들 가운데, 가장 마음에 드는 것은 Threaded Commenting인데, 이 때문에 Comment 쪽 템플릿을 수정해 줘야 했고, 결국 템플릿을 모두 4.2 디폴트 템플릿으로 바꾸고 다시 손봐야 했습니다.

Movable Type의 템플릿/위젯 시스템은 깔끔하긴 하지만, 업그레이드 할 때마다 손으로 바꿔 주어야 하는 점이 좀 불편한 것 같습니다. 뭐, 이런 걸 신경 안 쓰려면 서비스 형 블로그를 쓰면 되는 일이긴 하지만요.

다음의 언론사와 기사 광고 매출 배분 Daum Shares News Ad Revenue With News Provider

다음에 대한 뉴스 공급 중단

지난 7월 7일 조중동이 다음에 뉴스 공급을 중단했으며, 8월 1일에는 경제지인 매경, 한경도 뉴스 공급을 중단할 예정이다.

조중동의 뉴스 공급 중단 이후, 7월 15일자 코리안클릭의 통계를 바탕으로 한 분석 기사를 보면, 다음 뉴스 트래픽은 크게 변동이 없었고 조중동의 트래픽은 의미있는 수준으로 감소했다고 한다. 중앙일보의 PV가 50% 이상 감소한 것을 예외로 보고, 조중동의 트래픽 감소분은 원래 방문자 비중이 10~20% 사이였던 것을 생각해보면, 예상가능한 수준이라고 보면 된다.

조중동이 애초에 뉴스 공급을 중단한 배경에는 다음 아고라 등을 통한 조중동 광고중단 운동에 따라, 다음 측에 요구한 서비스 중단 또는 검열 요구가 받아들여지지 않은데에 있지만, 뉴스 공급 중단이 가능했던 이유에는 트래픽의 감소가 크지 않을 것이라는 판단이 있을 듯하다.

뉴스 공급 중단을 통해 조중동이 잃는 것은 다음에 뉴스를 공급함으로써 얻는 수익과 다음으로부터 유입되는 트래픽으로 인한 자체 광고로부터의 수익에 불과한 반면, 다음이 뉴스 품질 저하로 인해 잃는 것은 뉴스 서비스 뿐만 아니라 서비스 전반에 영향을 미치는 트래픽 저하와 이에 따른 광고 수익 감소이다. 조중동을 비롯한 신문사와 온라인 서비스를 위한 자회사의 수익구조를 정확히 알지 못하므로 단정지을 수는 없지만, 신문사에서 온라인 매출이 주요 수익원 중 하나가 된지는 얼마되지 않았다. (‘언론사 입장에서 포털은 수익모델 입장에서 큰 유통창구’로 보는 견해도 있다.) 다음의 경우에는 광고 수익이 주요 수익원이므로 그 중요성이 전혀 다르다고 볼 수 있다.

조중동 기사 제외가 사용자의 이탈을 야기할 정도로 서비스 품질에 영향을 미칠 것인가는 쉽게 판단할 수 있는 문제는 아니다. 다음 사용자들의 평균적인 연령, 정치적인 성향 등에 따라서 다를 수 있기 때문인데, 말하자면, 중요한 것은 ‘인식되는’ 서비스 품질인 것이다. 한편, 8월 1일로 예정된 몇몇 경제지의 기사 공급 중단은 중요한 영향을 미치는 것이 아닌가 하는 생각이 든다. 정치적 성향과 달리 경제적 합리성은 품질의 저하를 참아낼 수 없기 때문이다.

당장 통계 분석 기사에서는 큰 감소분이 나타나지 않았지만, 역시 기사에 언급된대로 일주일은 사용자가 뉴스의 품질 저하를 인지하고 사용하는 서비스를 바꾸는 데에는 짧은 시간이고, 정확한 판단은 수개월 간 지켜본 다음에야 가능할 것이다.

뉴스 기사에 대한 배너 매출 배분

이러한 시점에서, 다음은 언론사가 제공한 뉴스 기사에 의한 배너 매출을 언론사에 배분하는 방식을 도입하겠다고 발표했다.

서명덕 기자는 이에 대해 ‘명백한 굴복’이라며, 이러한 발표가 미디어로서의 다음의 위치를 기존 언론사들에게 양보한 것이라고 평가했다. 다음에 미치는 영향에 대해서도 서 기자는 ‘수익에 악영향이 있을 것’이라는 점과 이는 ‘불가피한 선택’이라는 점을 분석하고 있다. 서명덕 기자의 평가와 분석은 어느 정도 수긍은 가지만, 다음의 선택이 일방적으로 잘못된 것만은 아니라고 본다.

다음이 발표한 비즈니스 모델은, 컨텐트로의 링크를 통해 트래픽을 제공하거나, 컨텐트에 대한 비용을 지불하고, 광고로부터 수익을 얻는 일반적인 포탈의 비즈니스 모델에 비해 언론사에 더 많은 이익을 주는 모델이다. 언론사로서는 인링크 방식을 사용해 접근성이나 컨텐트 외적인 서비스 품질을 얻으면서도 아웃링크의 수익을 유지할 수 있다. 아직도 오프라인 미디어 기반의 언론사들이 온라인 미디어 – 포탈과의 공존에 대해 회의적으로 여기는 상황에서 이러한 방식은 오프라인 미디어들이 포탈에 대해 가지는 경계심을 어느 정도 해제해주는 효과가 있으리라 생각한다.

아무래도 기존의 모델에 비해 다음의 수익을 희생해 언론사의 수익을 늘려주는 것이므로, 조중동의 다음으로의 뉴스 공급 중단과 연계해서 생각하지 않을 수는 없다. 조중동을 비롯한 오프라인 미디어로서는 소규모의 수익은 희생할 수 있다는 입장이었겠지만, 다음이 더 많은 기대수익을 보장한다면, 이에 대해 다시 생각해보지 않을 수 없다.

다른 중요한 한가지는 새로운 비즈니스 모델이 기존의 비즈니스 모델을 구축할 가능성이다. 이러한 모델은 수익을 창출하기를 원하는 언론사들과, 뉴스를 적은 비용으로 유치하기를 원하는 소규모 포탈에게는 강력한 유인이 될 수 있으리라고 생각한다. 하지만, 네이버가 시장지배력을 확보하고 있는 상황에서 언론사의 기사 공급을 강제할 수 있는 힘을 가지고 있으므로, 네이버 또는 시장 전체가 이러한 모델로 교체되는 일은 없을 것이다. 2위 사업자인 다음의 입장에서도 같은 이유로 새로운 모델이 필연적인 방향은 아니라고 생각해 왔겠지만, 역시 뉴스 공급 중단 등의 사태로 인해, 그러한 가정이 깨어진 점, 그리고 언론사와의 문제를 해결하는 방법으로서 이러한 모델의 이점이 돋보였을 수 있다.

더 나아가서 만약 이러한 모델이 성공한다면, 즉 뉴스 제공에 보수적인 언론사의 뉴스를 유치하고, 같은 비즈니스 모델을 가지는 온라인 미디어들이 충분히 시장을 점유한다면, 기존의 모델을 오랫동안 고수할 네이버와의 경쟁에서 승리할 수 있는 요인이 될 수도 있다. 하지만, 역시 이러한 성공은 네이버가 지배적인 위치를 점하는 상태에서는 상당히 불확실한 것이다.

한편, 뉴스 공급 중단에 대한 대책으로, 비즈니스 모델에 변화를 주는 방법 만이 존재하는 것은 아니라는 점에서, ‘불가피한 선택’으로만 보기는 힘들지 않을까 싶다. 사실 회사에서 일어나는 중요한 결정들은 대부분 여러가지 안들 중에서 여러가지 이점을 취할 수 있는 것을 선택하지, ‘굴복’하거나 ‘불가피한 선택’을 하는 경우는 매우 드물다. 그러한 오해들은 회사의 문제나 해결 과정을 마치 개인의 것처럼 보는 시각에서 나오는 것이 아닌가 싶다.

아스트랄계 전생 테스트

아스트랄계 전생 테스트라는 것인데, 비교적 평범한 삶을 살았군요.

아스트랄계에서 추출한 당신의 전생 정보 내역을 분석해본 결과,
당신은 레이리안력 234년 라이시안대륙의 작은 마을 에 살았던 자경단이 습니다.
그 당시에, 당신은 라이시안대륙의 작은 마을 에서 주민들을 몬스터로부터 보호했 었습니다.
당신이 인생에서 가장 행복했던 때는, 첫째를 아내가 임신했을 때 이고,
당신이 인생에서 가장 불행했던 때는, 이계의 인물의 등장에 징집당했을때 였으며,
당신의 죽음은, 검강의 폭풍에 아내의 이름을 부르며 사망하며 이루어졌습니다.

Empowerment, Competency and Evaluation

요즘 열독하는 가난뱅이 님의 블로그 글에서 인용:

사실 독일군의 강점은 무기나 지휘관의 전술전략보다는 각 제대단위에서의 전술적 역량이 더 컸었다. 즉 일일이 다음행동에 대해 구체적인 명령을 내려보내야 했던 다른 연합군의 제대와는 달리, 독일군은 일정한 전술적 목표만 제시되고 나면 그 다음의 행동에 대해서는 지휘관의 재량을 인정했다. <중략> 그래서 실제 전장에서 독일군의 각 제대는 상급부대의 간섭에서 벗어나 자유롭게 현지 상황에 맞는 전술적 선택을 할 수 있었는데, 그럼으로써 특히 경험많은 하사관들의 역량이 개별전투에서 극대화될 수 있었다.

문제는 이 임무형 지휘체계라는 게 그렇게 간단한 게 아니라는 거다. 당장 사단에서 어디에서 어디로 이동하라는 명령이 내려졌을 때 그 명령 안에서 제대로 재량권을 발휘하려면 먼저 그 명령을 이해해야 한다. <중략> 바로 여기서 빛을 발한 것이 프로이센 시절부터 계몽주의를 내면화하여 발전해 온 독일의 국민교육이었다.

독일군의 임무형 지휘체계는 현대의 경영(management) 또는 리더십(leadership)에서 얘기하는 위임(empowerment)이라는 것이다. 독일군의 위임이 제대 단위에서 하사관들에게 이루어졌다면, 현대에는 지식 노동자 수준까지 적용되는 것이라고 볼 수 있다.

독일의 국민 교육이 독일군의 임무형 지휘체계를 가능하게 하는데에 기여했다는 것은, 위임이 가능하기 위해서도 어떤 조건이 충족되어야 함을 의미한다.

가난뱅이 님도 말씀하셨듯이 임무형 지휘체계가 가능하기 위해서는, 명령을 이해하기 위한 커뮤니케이션 능력, 전술적 상황을 파악하기 위한 능력, 전투 경험으로부터 전술적 지식을 축적할 수 있는 능력, 상황과 전술적 지식에 기반해 명령을 실행하기 위해 합리적으로 전술적 판단을 내리는 과정과 같은 능력이 필요하다.

지식 노동의 위임에서도 마찬가지다. 위임이 가능하기 위해서는 위임의 대상이 되는 업무를 처리하는데 필요한 기본적인 지식과 능력, 커뮤니케이션 능력, 합리성과 같은 기본적인 역량(competency)들이 전제가 되어야한다.

그리고, 기본적인 역량을 갖추었다고 해도, 누구에게나 어떤 책임과 권한을 부여하더라도서 위임이 동작하는 것은 아니다. 예컨대 처음 들어와 아무것도 모르는 신입사원에게 당신은 어떤 일을 위임할 것인가? 아마도 처음에는 최소한의 지식과 경험으로 수행할 수 있는 업무를 맡겨, 책임과 권한을 최소화할 것이다. 위임을 위해서 어떤 업무에 대한 책임과 권한을 부여할 때는 그 업무를 수행할 수 있는 역량을 가지고 있어야 한다. 다시 말하면, 역량에 따라 위임의 정도도 달라진다는 것이다.

역량에 따른 위임에 실패한다면 어떻게 될까? 업무에 비해 낮은 역량을 가진 사람에게 너무 커다란 책임과 권한을 맡긴다면, 실질적으로 그 사람은 주어진 책임과 권한을 충족시킬 기회도 적을 것이고, 실패할 확률은 높아질 것이다. 높은 역량을 가진 사람에게 너무 작은 책임과 권한을 맡긴다면, 그는 재미를 느끼지도 못할 것이고 성장하지 못한다고 느낄 것이다. 어느 경우라도 개인과 팀에 모두 나쁜 영향을 주고, 실질적으로 위임을 하지 않는 것과 같은 것이 된다.

위임에 있어서 역량은 전제에 불과하고, 동기 부여의 정도나 일의 재미, 교육의 기회, 공동체 의식과 같은 요소들도 배제할 수는 없다. 하지만, 역량에 따른 위임에 실패한다면 다른 요소들에도 나쁜 영향을 미칠 수 있고, 결국은 위임 자체를 실패하게 만들 수 있다.

역량에 따른 위임은 다시 역량에 대한 정확한 평가를 전제로 하는 것이다. 평가의 문제는 그 자체로 어려운 문제라서 더 이상 언급하진 않겠지만, 전에 언급한 신뢰의 문제와 어느 정도의 연관성도 보이는 것 같다. 즉, 신뢰의 정도는 실질적인 역량과 대조되는, 인식되는 역량에 영향을 미친다. 너무 신뢰하거나, 신뢰하지 않는 상황은 실질적인 역량을 파악하기 위한 눈을 가리는 가리개와 같은 것이다.

What Really Matters is What You Write in Text

Microsoft Word로 문서화를 수없이 해봤지만, 문제는 접근이 힘들다는 것이다. 문서의 참조도 그리 쉽지 않고, Microsoft Word 문서는 프로그램이 실행되기까지 2-3초는 기다려야 한다. 처음 Wiki를 도입했을 때, Wiki는 이러한 문제들을 말끔하게 해결해주었다. 문서의 참조와 조회가 늘어났고, 자연히 문서의 수명은 늘어났다.

회사에서는, 잘 알려진 상용 Wiki 구현 중 하나인 Confluence를 사용하고 있는데, 웹 에디터의 한계상 Rich Text 에디터가 그리 편하지는 않다. 웹 에디터의 영역은 이상하리만치 발전이 더딘 영역 중 하나다. 오프라인 클라이언트나  Microsoft Word 플러그인을 찾아보았으나, 쉽고 편하게 쓸 수 있는 것들은 아닌 것 같다. 쉽고 편한 에디팅 방법들을 찾아본 이유는, 정보의 생산 비용이 줄어야 좀 더 많은 정보의 유통이 가능할 것이라고 생각했기 때문이다. Original Wiki를 비롯한 모든 Wiki 구현들이 버튼만 누르면 바로 수정할 수 있도록 되어있는 것도 바로 그러한 맥락이라고 볼 수 있다.

하지만, Why Wiki Works를 읽어보면, 역설적이게도 Wiki가 WysiWyg이 아닌 것을 장점으로 내세우고 있다. 이유는 아무 생각없이 위키 페이지를 수정하는 사람들(VideoAddicts)이 참여하는 것을 막기 때문이라고 한다.

이 사실을 떠올리고 나서, 일상사에 대한 블로깅이나, 잡담류의 댓글이 아니라면, 쉽게 에디팅하는 것이 중요하지 않을 수 있다는 생각이 들었다. 문서의 내용들을 표현하는데 있어서 오프라인 클라이언트나  Microsoft Word가 중요한 역할을 하지 않을 수도 있다는 것이다. 표라든가 차트 같은 것들은 이미지로 저장하거나 그대로 첨부하면 될 것이다. 복잡한 표나 차트가 핵심적인 내용인 경우는 매우 드물고, 핵심적인 생각을 표나 차트로 읽기 쉽게 나타내어야 한다면 이미지를 따로 저장해 첨부하는 정도의 비용은 들일만하다. Microsoft Word로 문서를 작성해야만 하는 경우도 물론 존재하지만, 기본적으로 문서화에 있어서 정말 중요한 것은 텍스트 형태의 내용이 아닐까하는 생각이 든다.

한편, 그동안 Windows의 파일 공유 기능을 이용해, Microsoft Office 문서들을 공유해왔는데, 앞으로는 SharePoint Server를 사용할 것 같다. Confluence에 SharePoint와의 연동 기능이 있지만, SharePoint의 Wiki 구현이 그리 나쁘지 않다면 이런 고민을 할 필요없이 SharePoint로 갈아타는 것도 나쁘지는 않을 것 같다.

NHN vs. Daum

어떤 것을 경제적인 가치를 평가할 때 가장 좋은 방법은 숫자로 나타내보는 것이다. 주식이 실제로 어떤 기업의 미래 가치를 반영한다면, 그 기업의 주가총액은 그 기업의 미래 가치를 평가하는 척도가 될 수 있다.

국내 인터넷 서비스 업계에서 선두 주자라고 할 수 있는 NHN의 시가총액은 현재 97,467억이다. 10조라고 보면 된다. 반면 2위라고 볼 수 있는 다음의 시가총액은 10,447억, 즉 1조다. 일반적인 사용자들이 인지하는 것과는 반대로, 다음은 NHN의 1/10 규모에 불과한 것이다. 매출액이나 영업이익 등의 지표를 확인해봐도 마찬가지다.

NHN의 직원 규모나 채용 규모를 보면 다음은 역시 점점 뒤로 쳐지고 있는 것을 알 수 있다. 현재 직원 수가 2000여명이지만, 앞으로의 채용 규모를 보면, 그리고 NHN의 해외 진출 전략 등을 고려해보면, Microsoft나 Google 처럼 1만명 이상의 직원이 되는 소프트웨어 기업이 되는 것도 시간 문제로 보인다.

양 뿐만 아니라 질에 있어서도 떨어지지 않는다. NHN에 채용되는 개발자들의 수준이 적어도 평균적인 수준보다는 높다고 생각한다. 게다가 예전에 같이 일했던 능력있는 분들이 모두 NHN에 모이는 느낌이 들 정도로 NHN은 소위 말하는 ‘인력의 블랙홀’이 되어가고 있는 것 같다. 이러한 현상은 물론 개발자에 국한된 현상이 아닐 것이다.

인터넷 서비스 회사의 경쟁력은 사업 방향이나 아이디어, 환경 등의 요소등도 있겠지만 기초가 되는 경쟁력은 일하는 사람들의 질과 양에 있다고 봐도 무방하다. 인적 자원의 질과 양을 확보한 NHN은 해외진출의 벽만 뛰어넘는다면 미래가 밝아보인다. 이제 국내 시장을 넘어 아시아 시장에서 구글과 야후를 경쟁 상대로 인식하기 시작한 것으로 보인다. 최근에 내가 NHN에 투자하겠다고 판단한 근거도 바로 그러한 판단에 기초한 것이다.

이쯤 되면, 윤석찬 님이 다음과 NHN을 ‘다윗과 골리앗의 싸움’으로 비유하며 자조하는 것을 어느 정도 이해할 수 있다.

애초에 다음이 NHN의 경쟁자일까라는 질문에 대해서, 다음은 스스로에게 그 질문을 해보면 될 것이다. 적어도 최근의 다음의 행보들을 보면, 노골적으로 자신이 NHN의 경쟁자임을 자처하고 있다. 네이버와 거의 동일한 탑 페이지 구조 (원래도 비슷했지만, 최근 리뉴얼에서 더 비슷해졌다), NHN의 그린 윈도우 브랜드에 대응하는 블루 윈도우(?), 네이버 지식인 검색의 대체로서의 다음 카페 검색을 내세운 것이 그러하다. 그것이 상위 결정자들의 전략이 아니라고 하더라도 다음의 직원들은 NHN을 경쟁상대로 생각하고 있는 것이다. 다음이 NHN을 경쟁자로 생각하고 NHN과 같은 분야에서 경쟁하는 것이 다음에게 좋은 것인지 나쁜 것인지는 모르겠다. 설령 나쁘다고 하더라도 다음이 현재의 캐시 카우인 포탈 사업을 접을 수는 없을 것이다. 어쨌거나 확실한 것은 NHN을 뛰어넘으려면 지금보다는 잘해야 된다는 것이다.

한편, 독점에 대해서, 독점이 나쁘다라는 기본적인 내 입장에는 변함이 없다. 독점은 의도적이든 아니든, 불법적이든 아니든 공정한 경쟁을 방해한다. 결과적으로 사용자들이 얻을 수 있는 더 좋은 서비스를 얻을 수 없게 되는 일이 발생한다. 독점을 막는 마지막 방법은 Microsoft의 경우와 같이 반독점법에 의한 규제를 하는 것 이겠지만, 그것은 말그대로 마지막 방법이다. 기업은 법의 틀 내에서 공정한 경쟁을 해야하지만, 기본적으로 사용자에게 가치를 제공하고, 수익을 얻을 수 있어야 한다. 규제가 동작하기 이전에 다른 경쟁자가 사용자에게 더 나은 가치를 제공하고 수익을 창출함으로써 독점자의 이익을 빼앗아 가질 수 있어야 하는 것이다.

특히 미국이든 한국이든 인터넷 서비스 업계의 역사를 보면 영원한 1등은 없다는 것이 정설이다. 인터넷 서비스 업계의 특성상 독점자가 플랫폼이나 인프라를 장악함으로써 진입장벽이나 서비스 고착 (lock-in)현상을 만들기가 힘들기 때문이다. 규모의 크기가 문제가 된다고 생각하지는 않는다. 그러한 예로는 싸이월드, 마이스페이스, 페이스북을 보면 된다. 다음 또는 또 다른 누군가가 좀 더 열심히, 좀 더 잘 해주었으면 하는 마음이 항상 든다.