May 2008 Archives

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

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

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

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

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

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

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

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

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

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

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

MySQL Replication은 MySQL이 기본적으로 지원하는 데이터 복제 방식입니다.

MySQL Replication은 read-write가 가능한 Master와 read-only인 Slave로 구성되는데, Master는 쿼리 로그에 해당하는 binary log를 남기고, Slave는 asynchronous하게 이를 가져가서 반영하는 역할을 합니다. 설정도 간단해, 1-3줄 정도의 설정만 해주면 됩니다. 간단한 동작 방식에 기초해서 Multi-slave, Multi-master, Replication chaining 등의 구성 등이 가능합니다.

MySQL Replication의 문제점들

Master와 Slave가 최소한의 정보만 공유하는 단순한 방식이 장점인 동시에 단점으로 작용합니다.

  1. Master-Slave pair 관리:서버들이 많아질 경우, Master와 Slave의 짝을 관리하는 것이 쉽지는 않습니다. Master와 Slave의 짝을 다른 어디선가 관리해주어야 합니다.
  2. 실패 상황에서의 복구:당연히 자동으로 복구한다든가 하는 기능을 MySQL이 제공하지는 않습니다. Master가 실패했을 경우, Slave를 Master를 바꾼다든가, Slave의 데이터를 Master로 복사해준다든가 하는 작업은 순전히 수작업이 됩니다. Slave가 실패했을 때도, 마찬가지 입니다. Slave의 일시적인 오류라면, Slave는 자신이 반영한 로그의 위치를 기억하고 있긴 하지만, 이에 따른 복구도 사람 손이 갑니다.
  3. binary log의 관리: Master는 Slave에 대해서 don't care이므로, 언제 binary log를 삭제할 지는 주기 등을 사용합니다. 물론 삭제하는 command가 있지만, Slave들의 정보를 반영해서 자동으로 삭제하는 기능은 없습니다.
  4. asynchronicity: Slave는 Master와 같은 데이터를 가지고 있다고 보장할 수 없으므로, Slave가 Master의 쿼리 처리량을 따라가지 못하게 되면, consistency 문제가 발생할 소지가 있습니다. 따라서, 애플리케이션에서 이러한 점을 신경써주어야 합니다. 이러한 점들 때문에, MySQL Replication을 백업으로 생각하지 말라는 조언들이 등장합니다.

1, 2, 3번의 경우에는 도구를 이용해서 극복할 수 있습니다. 1번, 2번에 대해서는 어느 정도 도구를 만들어 쓰고 있는데, 인터페이스를 웹 인터페이스로 개선하고 좀 더 자동화할 필요가 있습니다. Maakit이라든가 MySQL Replication Manager 등을 참고해볼만 합니다.

4번의 문제에 대해서는 MySQL Replication이 아닌 대안을 찾는 것이 옳을지도 모르겠습니다. 구글에서는 semi-sync 모드를 위한 패치를 내놓기도 했습니다.

MySQL Replication의 대안들

일반적으로 MySQL Replication을 얘기할 때는 다음과 같은 대안들을 함께 얘기합니다.

  • MySQL Cluster: MySQL이 직접 지원하는 것 중에는 MySQL Cluster가 있지만, 아직은 메모리 기반 엔진인 NDB만 지원하기 때문에 메모리의 크기에 제약을 받습니다.
  • DRDB: 디바이스 수준에서 디스크를 분산하는 DRDB를 MySQL과 함께 사용합니다. MySQL Replication보다 failure에 안전한 것은 아니지만, sync가 어긋난 상태는 최소화됩니다. 하지만, failover node (i.e. slave)는 MySQL 쿼리를 처리할 수 없다는 크나큰 제약이 있습니다. 백업의 용도로는 적절하리라고 생각합니다.

예전부터 관심을 두고 있던 Sequoia와 같은 데이터베이스 클러스터링 솔루션도 한번 써보고 싶고, 최근에 화제가 되고 있는 MySQL Proxy 와 같은 Proxy들(SQL Relay, dpm, Spock Proxy)을 사용해서 Replication을 잘할 수 없을까 생각이 들기도 하는데, 당장은 시간이 없다는 변명을 하렵니다.

드라마 수퍼내추럴(Supernatural)은 초자연적인 존재, 즉 유령, 괴물, 악마를 소재로 한 드라마 입니다.

주인공인 딘과 샘은, 아내가 초자연적인 존재에 의해 살해당한 후, 복수를 위해 그 존재를 뒤쫓는 아버지가 실종되어, 찾아나서는 것으로 이야기가 시작됩니다. 딘과 샘 또한 아버지에 의해 '사냥꾼'으로 길러졌지만, 샘은 로스쿨로 진학하고 여자친구와 결혼하는 평범한 삶을 원하고, 딘은 가족과 함께 어버니의 복수를 하고 싶어합니다. 아버지와 두 아들로 구성된 가족이라는 점은 같지만, 갈등이 거의 없어 밋밋한 넘버스(Numb3rs)의 가족 이야기보다는, 갈등과 화해의 이야기는 훨씬 매력적입니다.

20대의 훈남 형제가 AC/DC의 Back in Black과 같은 7-80년대 락을 배경으로 로드트립처럼 미국 전역을 돌아다닌다는 설정은, 멀더와 스컬리가 외계인을 조사할 수 없게 되자 초자연 현상들만 찾아다니던 시절의 엑스파일(The X-Files)보다는 활기차고 가볍지만, 10대 소녀 주인공에 학교를 배경으로 한 버피와 뱀파이어(Buffy the Vampire Slayer)와는 또 다른 분위기 입니다.

초자연적인 존재를 표현하기 위한 특수효과나 음향, 분장 등이 영화를 뺨칠 정도로 수준이 높습니다. 예를 들어, 유령에 의한 물건의 조작이라든가 뱀파이어의 목을 자를 때 피가 튀는 것이라든가, 유령이 출몰하는 흉가의 표현이라든가, 악령을 소환하기 위한 제단의 표현 같은 것들 말입니다.

이야기의 구성은 엑스파일이나 CSI와 같은 다른 드라마와 비슷합니다. 초자연적인 존재의 인간을 해치는 장면으로 시작해, 딘과 샘이 이 존재에 대해 조사하는 과정, 마지막으로 이 존재를 파괴하기 위해 격투하거나 사냥하는 단계로 이루어집니다. 엑스파일이나 CSI 처럼 이 드라마도 장수하게 되면, 여러가지 색다른 이야기 구조들을 보여주겠죠.

초자연적인 존재를 사냥하는 일반 에피소드들도 재미있지만, 메인 스토리는 역시 실종된 아버지를 찾는 것과 어머니와 샘의 여자친구를 살해한 존재를 추적하는 것입니다. Season 1의 마지막 두 에피소드에서 이 존재와의 흥미진진한 결전이 벌어집니다. 마지막에 등장하는 반전도 감동적이었구요. Season 2가 기대되네요.

Les Amants

| | Comments (2) | TrackBacks (0)

joyce님의 블로그를 읽다가 발견한 르네 마그리트(René Magritte)의 '연인들' (Les Amants)이란 작품입니다.

Stock Option

| | Comments (1) | TrackBacks (0)

캐서린 쉬퍼 인터뷰에서 인용:

스톡옵션을 비용 처리하지 않으니까 기업이 스톡옵션을 주는 것에 대해 아주 관대해진 겁니다. 현금으로 과도한 보수를 지급하면 당장 기업의 이익이 줄어들어 주가가 떨어질 뿐 아니라, 언론이나 정치권의 주목을 받게 되고 노조도 임금인상을 요구할 수 있습니다. 그런데 스톡옵션을 주면 이익도 줄지 않고, 주목도 받지 않으니 큰 부담 없이 스톡옵션을 준 겁니다. 이게 심각한 문제를 낳은 거죠. 예를 들어 회계부정을 저질러서 고의적으로 이익을 낮게 보고한 후 낮은 가격에 행사할 수 있는 스톡옵션을 받고, 다음에는 지난 기간에 낮게 보고한 만큼 이익을 부풀려서 주식 가격을 끌어올린 후 스톡옵션을 파는 것이죠.

스톡옵션이란 주식을 대상으로 하는 콜 옵션의 일종이며, 비현금성 보상으로 지급된다. (Wikipedia의 정의)

위의 인터뷰 토막에서 지적하고 있는 것은 스톡옵션이 스톡옵션을 지급할 당시의 회계기간에 비용 처리되지 않기 때문에, 단기적으로 주주를 속일 수 있을 뿐만 아니라, 극단적으로는 회계부정의 목적 또는 수단으로 악용될 수 있다는 것이다.

현재는 이러한 스톡옵션의 문제를 해결하기 위해서 미국 뿐만 아니라 한국에서도 스톡옵션을 비용처리하도록 되어있는 모양이다. 인터뷰에서도 언급되듯이, 미국과 한국은 세부적인 회계처리 방식에 대해서는 법으로 강제하기 보다는 표준적인 규정집(GAAP, 기업회계기준서)과 이를 규정하는 정부 위원회(FASAB, KASB)를 두고, 증권거래소(Stock Exchange)가 실질적으로 강제하는 방식을 채택하고 있는 것으로 보인다.

About this Archive

This page is an archive of entries from May 2008 listed from newest to oldest.

April 2008 is the previous archive.

June 2008 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 4.21-en