일기장/2013-05-20

사실 이번 일이 좋은 점도 하나 있다. 내가 원하는 회사가 어떤 것인지에 대해 좀더 명확하게 정의할 수 있게 된 것. 지금까지 생각이 정리된 건 세 가지다.

1. 자신의 직관보다 사용자의 반응을 우선시하는 클라이언트(경영자)
2. 명확하지만 추상적인 미션
3. 실무자를 설득하는 경영자(manager)

1번은 전에 일기장/2010-05-16에 글을 써둔 바 있다. 외주의 관점에서 쓴 글이지만, 회사에도 똑같이 적용된다는 것을 이번에 알게 되었다. 어쨋거나 자신의 의견이 사용자의 반응보다 중요하다고 생각하는 클라이언트랑 일하는 것은 괴로운 일이다. 2번은 페이스북에 쓴 바 있다. 미션은 팀원들이 서로 다르게 이해하는 일이 없을 만큼 충분히 명확해야 하고, 미션의 틀 안에서 창발이 일어날 수 있을 만큼 충분히 추상적이어야 한다.

이번에 이야기할 것은 3번. 대부분의 회사는 신규 프로젝트를 진행할 때 실무자가 경영자를 설득해서 승인을 받으면 프로젝트를 진행한다. 하지만, 난 그 반대여야 한다고 생각한다. 경영자가 그 일을 해야 하는 이유, 혹은 하지 말아야 할 이유를 실무자에게 납득시켜야 한다.

난 사실 이게 당연해서 설명할 필요도 없다고 생각해왔고, 지금까지 딱히 그렇지 않다고 느낀 경우는 별로 없었기 때문에 이런 주제에는 관심도 없었다. 외주를 할 때도 클라이언트들은 신기하리만큼 열성적으로 그 기능을 왜 넣어야 하는지를 설명해주었다. 비록 그 이유가 납득이 안 가는 이유는 있을지언정, "그냥 해" 하는 식의 클라이언트는 별로 없었다. 적어도 "남들이 하니까" 같은 형편 없는 이유라도 설명해주려고 애썼다. 최근에 내가 일 하다가 빡쳐서 계약금 돌려주고 쫑낸 프로젝트에서조차도 하는 짓이 밉상이긴 했지만 그 일을 해야 하는 이유를 설명하는데 있어서 인색함은 없었다. 회사가 망해서 옮겨야 했던 첫 회사도 내 아버지뻘인 사장이 프로젝트의 당위성에 대해서 신입인 나에게 차근차근 설명을 해주었고, NHN에서도 납득이 안 가는 프랙티스들에 대해 이의를 제기할 때마다 창희형이 열심히 설명을 해줬다. 반대로 NHN에서 내가 주장해서 시작한 프로젝트들에 대해서는 별로 열심히 설득할 필요가 없었다. 프레임워크 만들 때도, 모니터링 툴 만들 때도, cron을 대체물 만들 때도 그냥 이거 하겠다고 하니까 알아서 해보라고 했었다.

그런데 이제 안 그런 회사도 있다는 걸 알게 된 것이다. 물론 NHN에서 당시에 내가 주장한 프로젝트들이 쉽게 승인된 것도 딱히 그런 문화가 있었기 때문이 아니라, 경영자들과 내 생각이 단순히 일치했기 때문일 뿐이라는 것도 이제 알았다. 생각해보면 그런 회사가 더 많을지도 모른다. 우연히 운 좋게 내가 12년 동안 그런 회사/상황을 피해다닌 것 뿐일 게다. 그러다 갑자기 일반적인 회사를 만나서 난 멘붕에 빠진 것이고. 그래서 설명할 필요를 이제 느낀다.

이건 복잡한 설명보다 그냥 내가 일하는 방식을 늘어놓는 게 나을 것 같다. 이를테면, 나는 팀장으로 프로젝트를 할 때 디자인에 대한 최종 결정권은 항상 디자이너에게 준다. 디자이너의 디자인에 내가 동의하지 않을 때도 많고, 그럴 때는 계속 의견 제시를 하지만, 그러면서도 결정권이 디자이너 당사자에게 있다고 생각하고, 그게 생각으로 그치지 않도록 명시적으로 말해주려고 애쓴다. 명시적으로 결정권이 본인에게 있다고 말해주는 것도 무척 중요하다. 내가 이걸 깨닫게 된 것은 오픈마루에서 ECUS할 때였다. 당시에도 나는 비슷한 마인드로 팀장질(?)을 했는데, 결정권이 디자이너에게 있다는 것을 명확하게 말해주지 못했다. 그냥 회의 때마다 열심히 디자인에 대해 딴지를 걸고, 마지막에 그래도 맘대로 하세요... 이렇게 마무리 짓곤 했는데, 그게 보기에 따라서는 마음대로 하라면서 맨날 딴지 건다고 받아들여질 수도 있을 것 같았다. 그래서 2~3개월 째부터는 결정권이 디자이너 본인에게 있다는 점을 좀더 명확하게 표현하려고 했는데, 잘 받아들여졌는지는 잘 모르겠다. 암튼, 그 이후로는 명시적으로 결정권을 이양하는 것이 매우 중요하다는 것을 알고 표현하려고 했고, 그 이후로는 그럭저럭 내 취지가 받아들여진 것 같다.

개발자도 마찬가지다. 나는 어떤 코드가 좋은 코드인지, 어떤 식으로 구현해야 할지, 어떤 아키텍처가 좋은지에 대해서 명확한 철학이 있고, 우리 팀이 그 철학에 맞게 개발하기를 바란다. 그래서, 기회가 생길 때마다 그런 의견을 제시하지만, 최종적인 결정은 실제로 키보드를 잡는 사람의 몫으로 남겨둔다. 실무자가 스스로 결정할 때 가장 좋은 결과물이 나온다는 것을 알기 때문이다. 결정권이 실무자 자신에게 있다는 것을 안다면 내 의견을 받아들일지 흘려들을지도 선택할 수 있고, 그럼 나도 더 부담 없이 의견을 제시할 수 있다. 내가  실무자를 설득하는데 실패하면 실무자의 뜻대로 가는 것이지 실무자가 나를 설득할 필요는 없다.

개발 뿐 아니라 서버 작업 같은 것도 마찬가지다. 여러 회사에서 다양한 서버 구성을 경험해봤기 때문에 나도 나 나름의 서버 구성에 대한 철학이 있고 노하우가 있다. 그래서, 누군가에게 서버 작업을 맡길 때 그런 방향성에 대해서 많이 표현한다. 서버에 대한 사용자로서의 요구사항도 많이 이야기한다. 하지만 최종적인 선택은 늘 터미널을 열고 들어가는 사람의 몫이다.

모든 사람은 자신이 납득하는 일을 할 때 더 높은 성과를 낸다. 여기에 이의를 제기할 수 있는 용감한 사람이 있을까? 실무자가 납득하지 않아도 일을 하게 만드는 게 어떤 결과를 가져오는지는 우리 모두 잘 알고 있다. 결정권이 없는 고객 서비스 담당자가 어떻게 대응하는지는 다들 많이 경험해봤을 것이다. 생활의 달인들도 자신이 납득하는 일을 원하는 방식으로 할 수 있었기 때문에 그런 기술들을 하나씩 착안해낸 것 아니겠는가? 단순해보이는 그런 일들도 정말 잘 해내기 위해서는 창의적인 발상이 필요하다. 그런데 자신이 납득하지도 않는 일에 사람들이 창의성을 발휘할까? 빵을 왜 비닐로 싸야 되는지 납득하지 못하는 직원이 번개같이 빵을 포장하는 기술을 개발해낼까? 창의성은 결정권이 있을 때 나오는 것이다. 자신의 결정에 대해서 매번 허락을 받아야 된다면 무슨 창의적 발상이 가능하겠는가. 소프트웨어 개발은 그런 일과 달리 창의성이 필요 없는 일이었나?

물론, 정치적으로는 좀 이야기가 다르다. 어쨋든 회사에는 소유주가 있는 거고, 그 소유주가 자기 마음대로 회사를 만들 권리가 있다. 그래서, "실무자가 경영자를 설득하는 문화"도 정치적으로는 올바르다. 왜 오너가 자기 마음대로 못하나? 하고 물으면, 대답할 말이 없다. 내가 자유롭고 평등한 회사를 만들려고 했던 것도 그 자체로는 내 마음대로 회사를 만드는 활동인 거였고. 그래서, 그런 걸 틀렸다고 할 수는 없다. 단지, 그게 회사의 크기를 오너 개인의 그릇에 한정하게 된다는 것 뿐이다. 물론 그 그릇의 크기가 스티브 잡스 쯤 되면 상관이 없겠지만, 그런 사람은 흔치 않다.

마지막으로 야망 패자에 나온 글귀 하나.

한 사람의 힘은 무리에 대적할 수 없고
한 사람의 지혜는 만물에 미치지 못한다.

하급의 인간은 자신의 능력을 남김없이 쓰고
중급의 인간은 사람들의 힘을 쓰며
상급의 인간은 사람들의 지혜를 쓴다.