올해의 방향성을 논의하면서 여러가지 사업 기회나 제품의 방향성에 관한 아이디어들이 다루어진다. 어떤 것들은 새로운 것이 아니고 오랫동안 논의되어오고 그동안 중요하게 고려되어온 것들도 있다. 하나하나의 아이디어들을 보면 모두 좋은 기회들과 고객에게 전할 수 있는 가치들이 숨어있다.
이어서 얼마나 많은 자원이 투입되어야 하는가, 이를 둘러싼 비즈니스 환경이 어떠한가, 마일스톤 내에 가능한가와 같은 의견들이 개진된다. 물론, 여러가지 어려움이 있지만, 그러한 어려움을 헤쳐나간다는 가정 하에 어떤 것들은 실행가능해보인다. 어떤 것들은 그렇지 않다. 추가적인 투자가 필요하거나, 마일스톤 내에 성공이라고 부를만한 충분한 진척을 내기 어렵거나, 결코 녹록치 않은 경쟁 환경인 경우들이다.
그러한 기준들을 통과한 아이디어들에 대해서, 마지막으로 매우 구체적인 숫자로 표현된 회사 목표를 달성할 수 있는지를 검토한다. 여기서 많은 아이디어들은 ‘불확실’하다. 아마 누구라고 하더라도, 어떠한 사업이나 제품 방향성이 완벽하게 실행이 되었을 때, 100%의 확률로 구체적인 기한 내에 구체적인 매출이나 이익을 낼 수 있을거라고 장담하기 어렵다. 실은 50%의 확률로 그러하다고 장담하는 것도 쉽지는 않다.
자리로 돌아와서 모호하게 표현된 가능성에 대한 의견들을 수치화할 수 있는 방법에 대해서 생각한다. 구체적인 숫자로 표현된 회사 목표에 대해 잠시 눈을 감을 수는 없는가 생각을 한다. 좋은 아이디어들은 많이 있다. 분명히 회사의 가치에도 제품의 품질이나 고객의 만족에도 도움이 될 것이다. 구체적인 숫자는 잠시 무시하고 가장 커다란 가치를 줄 수 있는 것에 ‘도전’할 수는 없나 생각을 한다. 하지만, 곧이어 짧은 기간의 성공 가능성도 확신할 수 없다면, 어떻게 장기적인 성공 가능성에 주어진 자원을 모두 투자할 수 있는지, 또한 장기에 걸친 실행 자체도 구체적으로 표현된 마일스톤 없이는 위태로운 것이 아닌가 하는 생각으로 이어진다.
어렵다. 아마도 모든 회사의 대부분의 사업 기회들과 제품 아이디어들은 그러할 것이다. 기회들과 아이디어들은 대개 제어할 수 없는 요인들과 불확실성을 가지고 있다. 훌륭한 아이디어처럼 보이는 것들에 대해서 얘기하는 것도 그에 대해서 동의하는 것도 쉬운 일이다. 하지만, 실제로 그 훌륭하다고 말하는 아이디어에 가장 중요한 무언가를 걸고 헌신하는 것은 완전히 다른 문제이고 어려운 일이다.
그러한 불확실성 속에서 가장 좋은 결정을 할 수 있는 능력 만큼이나 용기도 중요한 것 같다. 어쩌면 그 둘은 같은 것일지도 모른다.
규칙과 규칙에 대한 보상과 벌을 설계하고 운영하는 일은 아주 어려운 일이다. 조직에서 어떤 부정적인 행동들이 관찰될 때 매니저로서 즉각적으로 드는 생각은 규칙을 만드는 것일지도 모른다. 하지만, 실제로는 많은 경우 가장 마지막에 고려해야 하는 방법이다.
‘9시 – 6시를 근무시간으로 한다’라는 규칙을 가진 회사를 가정해보자.
인간이 살아가는 세상이 늘 그렇듯이 9시보다 늦게 출근하는 사람들이 생겨나기 시작한다.
정시에 회사에 도착하려고 지하철역에서 뛰어왔지만 1분 늦어버린 사람, 그래도 아침에 맛있는 커피는 필수니까라고 생각하며 카페에 들르다보니 9시 10분에 도착한 사람, 어젯밤에 오랜만에 만난 친구들과 새벽까지 회포를 풀다보니 늦잠을 자버려 10시가 좀 지나서 출근한 사람.
약 20%의 사람들이 한달간 1번 이상 9시 정시 출근을 지키지 않았다. 반대로 정시에 출근하는 사람들의 20% (전체의 16%)는 늦게 출근하는 사람들로 인해 업무에 방해가 되거나 또는 불공평함을 느낀다고 생각했다.
조금 보수적인 회사의 인사부서에서는 이러한 현상을 막기 위해 9시 정시 출근하지 않는 사람들에게 직접적인 불이익을 주는 방법을 고려하다가 그 해의 인사고과에 정시 출근 여부를 반영하기로 했다. 또한, 한달 동안 시스템에 기록된 출근 시간 중에서 9시 이후인 시간이 한 번 이상 있다면 인사부서에서 매니저와 본인을 대상으로 규칙 위반을 통지하고 이는 인사고과에 반영될 것이라는 이메일을 보내기로 했다.
효과는 즉각적이었다. 정시 출근을 지키지 않던 그룹이었던 20%의 80% (전체 중 16%)가 정시 출근을 지키기 시작했다. 다만, 규칙을 지키기 시작한 20%-80% 중에서 다시 80% (전체 중 약 13%)는 다시 규칙을 지키기 시작했음에도 불구하고, 이러한 규칙에 대해 불만이 생겨났다. 살다보면 발생할 수 있는 여러가지 사고와 실수로 인해 10분 늦는 것에 대해 너무 과도한 불이익이 주어진다는 것이었다. 어떤 사람들은 자신은 아침마다 반드시 등교를 돕고 빠듯한 시간 내에 최선을 다해 출근을 하는데도 이러한 불이익은 너무 가혹하다는 논리를 폈다. 반대로, 그래도 정시 출근을 지키지 않던 그룹이었던 20%의 20% (전체 중 4%)의 출근 지연 시간은 평균 10분에서 평균 20분대로 더 늦어졌다. 어차피 불이익을 볼거라면 별 차이가 없지 않냐는 논리였다. 한편, 정시출근을 하지 않는 사람들에 대한 불만은 해소되었지만, 정시출근을 원래부터 지키던 80% 그룹 내에서도 20%의 사람들은 자신이 혹시라도 지키지 않았을 경우 발생하는 불이익에 대해 스트레스를 느꼈고 그것이 불만으로 이어졌다.
여러가지 경로로 이러한 문제점들을 들은 인사부서는 규칙을 조금 개선하기로 했다. 10분 지각까지는 경고를 하되 한달간 3회 누적이 되면 원래 대로의 불이익을 주기로 했다. 다시 규칙을 지키기 시작한 그룹 중에서 80%는 실수로 인한 위험이 줄어들어 어느 정도 만족을 했지만, 그 중 20%는 불만이었다. 그 이유는 다양했는데, 여전히 오는 경고 이메일은 두렵다는 것, 10분 이상의 지각이 일어날 수도 있는 가능성에 대한 불안, 3회 누적 시 불이익은 여전히 너무 강한 불이익이라는 것 등이었다. 정시 출근을 원래부터 지키던 80% 그룹 내에서 스트레스로 인한 불만이 줄어들었다고 대답했지만 여전히 그들 머리 속에는 불안이 자리잡고 있었다.
임원진으로부터 너무 불이익을 주는 방법만 생각하지말고 정시 출근을 하는 사람들에게 이익을 주는 방법도 생각해보자는 의견이 나와서 인사부서는 또 고민을 하게 되었다. 3년 동안 정시 출근을 빠짐없이 한 직원들을 개근 표창하고 보너스 20만원을 지급하기로 했다. 어차피 정시 출근을 하는 사람들이 80% 이상을 차지하고 있기에 3년 개근을 달성하는 것은 약 64%가 달성할 것으로 기대되는, 아주 어려운 일은 아니었다. 그래서 보너스 액수도 적을 수 밖에 없었다. 64%나 받는 표창이기에 어떤 뿌듯함 같은 것은 없었다. 어차피 정시 출근을 지키지 않던 그룹은 이 액수를 보고 마음을 바꾸지 않았다. 반대로 정시 출근을 하던 그룹의 사람들에 대해서 지각을 할 것 같으면 휴가를 사용하라는 웃지 못할 이야기도 돌았다.
‘9시 출근’이라는 어떤 회사에서 반드시 지켜야 하는 어떤 규칙을 사례로, 어떤 규칙을 지키도록 만들기 위해 어떤 일들이 일어나고 그런 과정이 얼마나 험난한지 이야기 식으로 풀어보았다. 어떤 규칙을 지키지 않는 사람들이 발생하고, 규칙을 더 많은 사람들을 지키도록 만들기 위한 과정에서 당근과 채찍을 동원하고, 규칙 그 자체에 대해 불만을 가진 사람들과 채찍에 대한 불안감을 가진 사람들, 당근에 대한 효과와 공정성에 의문을 가진 사람들이 발생한다.
사실 우리들이 모든 일에 대해서 규칙을 원하는 것은 아니다. 우리가 실제로 무엇을 원하는가를 잘 생각해보면, 실은 어떤 긍정적인 행동에 대해 여러 사람들에게 그것이 무엇인지, 그리고 왜 정당한지를 설명하고, 더 많은 사람들이 그러한 행동을 하도록 하고 싶은 것이 대부분이다. 더 좋은 단어가 있을지 모르겠지만 나는 보통 ‘규칙’ 대신 ‘가이드라인’이라는 단어를 쓴다. 가이드라인이라면, 일부가 그렇게 행동하지 않아도 큰 문제가 없다. 오히려 가이드라인이 제시하는 방식에 얽매이지 않고 다른 방식의 행동을 통해 새로운 돌파구를 찾아내는 길을 열어놓아야 할 때도 있다.
물론, 규칙이 필요한 경우도 있다. 모든 사람들이 같거나 비슷한 행동을 할 때 발생하는 시너지가 있다. 하지만, 규칙이라고 해도 여전히 이를 지키지 않는 사람들이 발생할 것이다. 처음에 규칙이 만들어질 때는 모두의 합의에 기초를 했더라도 시간이 흐르면서 또는 새로운 사람들이 들어오면서 규칙을 지키지 않는 사람들이 늘어나는 경우가 있다. 규칙을 지키지 않는 사람들이 너무 늘어나면 규칙이 유명무실해 지므로, 일정 비율 이하로 유지해야할 필요성이 있다.
그럼에도 불구하고, 규칙을 보상과 벌을 이용해 제어하려는 생각도 가급적이면 뒤로 미루는 것이 좋다. 모든 것을 규칙으로 제어하려고 하면 위에서 본 것처럼 규칙을 만드는 사람과 따르는 사람 모두가 그 규칙에 얽매여서 불행한 삶을 살아가야한다. 규칙에 대해 많은 제어를 하지 않기 위해서는 다음과 같은 고려들이 필요한 것 같다.
먼저, 많은 사람들이 현실적으로 지키기 힘든 규칙이어서는 안된다.
가능하다면 규칙의 설계 상 인간으로서 할 수 있는 실수는 어느 정도 허용해야 한다.
규칙을 운영하면서 발생하는 작은 위반들은 그냥 눈감아주되 정상적인 상태로 올 수 있도록 가벼운 자극을 주는 것이 좋다.
규칙의 목적에 반하는 매우 커다란 위반들에 대해서도 규칙을 만들지 말고 하나의 예외로서 처리하는 것이 좋다.
이러한 방식으로 규칙을 만들 때 나는 ‘정책’이라는 단어를 쓴다. ‘정책’은 조직을 운영해나가려는 의도를 통해서 조직의 방향을 제시해 사람들의 혼란을 방지할 수 있고, 규칙을 위반하는 사람들을 어느 정도 포용하면서 논의를 통해 더 나은 방법을 찾아나갈 수 있는 메시지를 준다고 생각한다.
나도 처음 매니저 역할을 경험하면서 명확한 규칙과 엄정한 실행이 답이라고 생각했던 적이 있었기에, 새롭게 매니저 역할을 하시는 분들에게 조금이나마 도움이 되기를 기대하면서 아침에 떠오른 생각들을 정리해봤다.
Facebook의 VP of Engineering인 Jay Parikh와의 자동화에 관한 인터뷰.
하드웨어의 실패에 따른 자동화된 진단과 복구를 위한 FBAR라는 자동화 시스템에 대해 이야기하고 있다. FBAR에 대해서는 조금 오래된 글 (2011년)이지만, 다음 글에서 조금 더 자세한 내용을 볼 수 있다. https://www.facebook.com/notes/facebook-engineering/making-facebook-self-healing/10150275248698920
We built a system we call FBAR, for Facebook Auto Remediation, to do a very basic set of hardware remediation tasks. Before, if a server had a hard drive failure or some hardware error, an alarm would go off and some human would have to log in, or walk to the computer, and try to debug or fix it. You’d do some things to try to fix it in software, you’d reboot the machine, you might try to reimage it. A lot of that software remediation and debugging is all automated now. No person has to be involved with that. The system will detect the error– it could be a disk drive, it could be a CPU, it could be a networking card or power failure—and can go ahead and do a bunch of things that it knows how to do.
당연한 이야기이지만, 자동화의 이점 중 하나는 휴먼 에러를 방지하는 것이다.
You don’t have to worry about that with automation, because work consistently gets done in the same way every time. And cluster turn-ups which used to take three or four months now can be done in the course of a week – sometimes in just a couple of days.
자동화를 통한 효율에 관한 이야기인데, 일반적인 IT 회사에서 200~500대의 서버당 1명이 일하고 있다면, Facebook에서는 25,000대당 1명의 효율을 가지고 있다고… 예전에도 들은 바가 있는 것 같지만, 2000대를 1명이 담당하는 정도가 되니 불안함을 느꼈던 것을 생각하면 대단한 것 같기는 하다.
So we have done a lot of work on the software automation side of this, to the point that we only need one technician in the data center for every 25,000 servers. That is a ratio that is basically unheard of. Most IT shops have ratios of one to 200, or one to 500.
이 인터뷰에서 자동화의 이점으로 가장 강조하고 있다고 느끼는 점인데, 상당히 단순한 부분들을 자동화하고 나면, 똑독한 사람들이 더욱 높은 수준의 일을 할 수 있고 미래에 대해서 생각할 수 있도록 한다는 것이다. 그리고, 그런 똑똑한 사람들이 오랜 시간에 걸쳐 평범한 일을 하게 된다면 결국 번아웃과 불행함으로 이어지고, 결국 이직을 하게 마련인데, 업무가 지루하고 반복적인 단순 업무가 되지 않도록 지속적으로 자동화를 하고 아키텍쳐를 바꿔나가야한다고 얘기하고 있다.
I think one of the major ways you do this is by continuing to keep them out of their comfort zone. If they end up doing “humdrum” work for a long time, they’re not learning anything, yet they’re spending a lot of time doing it. That leads to burnout and unhappiness, and then they’re going to go somewhere else. So, I think, if growing your company depends on keeping these brilliant technologists engaged, the necessity is that you have to keep automating and rearchitecting your systems so that things don’t become boring, monotonous, and repetitive. Automation serves your talent objectives.
변화를 위한 조직 구조에 대해 – 변화를 위한 팀과, 안정적이고 효율적인 운영을 위한 팀을 분리하는 것이 전통적인 접근.
Otherwise, you put them in a position where one team, in order to hit its goals, always wants to make changes, and another team only wants to make everything stable and cost-effective. Those two are completely opposed to each other. […] When I showed up at Facebook in 2009, this is what I saw and I thought is was perfectly reasonable. It was this way when I was at Akamai, it was this way when I got to Ning.
문제는 단기적인 비용에 기반해 의사결정을 하기 때문에, 미래를 위한 투자를 하지 않게 되고, 자동화는 작은 팀의 임무로 맡겨지기 때문에, 수많은 엔지니어들의 요구에 따라가지 못하게 되는 것.
Sometimes we were making decisions that were short-term cost based, when we should have been basing them on what we would need to be ready for a year from now. In other places, the focus on automation wasn’t there, because it wasn’t a team’s own responsibility. Questions about automation were being tossed to a small team of people who just weren’t going to keep up with this swarm of engineers that we were hiring.
Facebook에서는 이를 같은 팀에 묶고 변화와 운영을 동시에 하도록 하고 있다. 이 또한 쉬운 일은 아닌데, 인터럽트들이 장기적인 목표에서 벗어나도록 하기 때문. 데드라인에 대해서 조금 유연하게 대처할 필요가 있다고 얘기하고 있다.
No, we come up with what we call big bets as a team, planning the investments in technology that will take one or two or three years to build. For example, we built a new compiler that runs the front end of our site. It took us a couple of years to build and that R&D effort was done in parallel, in the same team that was maintaining the existing run time that was running the live Facebook.
이러한 방식의 장점에 대해서, 혁신을 위한 팀은 변화에 대한 성과에 대해서 걱정하고, 전선에서 뛰는 비즈니스 팀은 언제쯤 재미있는 일을 할 수 있는지에 대한 불만을 표하는 상황 등을 방지할 수 있다고 얘기하고 있다.
But meanwhile there are so many benefits — starting with the fact that it’s done in a much more open way. No one likes it when there’s a team working in some secure undisclosed location “doing something really cool that is going to replace what you’ve got.” It’s a tough thing to manage on both ends. The innovation team worries: “We’re not making any impact now – they’ve just stuffed us in a corner and told us go deliver something great.” And the core business team you’re depending on to deal with problems and customer support issues and all the urgent things that come up, is saying, “When do we get to work on something cool? Are we second-class citizens or something?”
의견
자동화의 이점에 대해서는 100% 동감하고 적어도 IT 업계의 일정 규모 이상의 회사라면 어떤 조직이라도 항상 중요한 목표가 되어야 한다고 생각한다. 변화팀과 운영팀을 통합하는 조직 구조에 대해서는 전반적으로는 동의하나, 아마도 VP 레벨의 입장에서는 통합된 조직일지는 몰라도 실무 수준에서는 이 글에서도 제시하듯이 인터럽트와 단기적인 비용에 기반한 요구들은 장기적인 관점에서의 업무에 매우 해롭기 때문에, 일정 규모 이상의 조직이라면, 정도의 차이는 있더라도 팀 내에서라도 어느 정도의 분리는 필요하지 않는가라고 생각한다. 다만, 변화팀과 운영팀이 서로 얼굴을 맞대고 이야기할 수 없을 정도로 서로 다른 조직의 바운더리로 분리되어 있다면, 이 글에서 지적된 것과 같은 부정적인 효과는 항상 발생할 것이다.
The best teams I have worked in and with are those that defy the traditional roles and responsibilities. Putting up artificial walls between extremely closely related disciplines can only be detrimental to getting great team work. Any given set of devs, testers and PMs working on a feature have a different set of skills and experience they bring to the team. Putting in place a structured set of expectations denies this fact. If the developer is more senior and experienced in an area, then you may want them leading more of the design of the feature, not just the implementation. Likewise if the PM is very senior and an experienced software architect, you may want them to have more of an input in the actual implementation decisions.
내가 함께 일했던 최고의 팀들은 전통적인 역할과 책임에 반하는 팀들이었다. 서로 밀접한 관련을 갖는 분야들 사이에 장벽을 세우는 것은 팀워크에 방해가 될 뿐이다. 하나의 기능을 위해 모인 개발자, 테스터, PM들로 구성된 팀은 서로 다른 기술과 경험의 집합을 보유하고 있다. 정해진 역할과 책임을 강제하는 것은 이러한 사실을 부인하는 것이다. 개발자가 해당 분야에 있어서 경험이 깊다면, 구현 뿐만 아니라 좀 더 많은 기능 설계를 이끌어가기를 바랄 것이다. 마찬가지로, PM이 매우 숙련된 소프트웨어 아키텍트라면, 실제 구현 결정에 있어서 좀 더 관여하기를 원할 것이다.
여러 가지 답이 있을 수 있겠지만, 그 중 하나는 아마도, ‘주어진 업무를 수행할 때, 업무의 목표가 무엇인지 정확히 이해하고 수행하는 사람’이다. ‘상위 조직의 목표까지 고려해서, 원래 업무의 방향을 수정하거나, 업무의 우선순위를 조정하거나, 적절한 새로운 업무를 추진할 수 있는 사람’이라면 더할 나위 없을 것이다. 역설적이게도, 어떻게 보면 관리가 필요하지 않은 사람이 바로 관리자의 이상형이다.
세상은 완벽하지 않다. 모든 동료들이 위에서 얘기한 조건을 만족하기란 어려운 일이다.
관리자 M이 보기에 동료 A는 지시하지 않은 세부 사항까지 알아서 척척 처리해, 손이 닿지 않는 곳의 가려움에서 벗어나는 기쁨을 안겨 주는 반면, 동료 B는 완료했다는 일이 처음부터 업무를 처리할 방식을 세세하게 다시 설명해 주어야 할 정도로 엉망이어서, 그 사람 얼굴만 보면 짜증이 나고, 잠도 안 올 정도로 고민거리다.
왜 그럴까? 동료 B는 멍청해서? 게을러서? 여자 친구랑 헤어져서? 에어컨이 고장 나서?
그런 것은 아닌 듯 하다. 동료 B는 업무 시간에 집중해서 성실하게 일하며 책임감도 높다. 여자 친구가 없으니 헤어질 일도 없다. 관리자 M의 옆자리니까 에어컨이 고장 난 것도 아니라는 것을 안다.
업무 경험이 많고 세심한 관리자 M이 보기엔, 한마디로 딱 잘라 말할 수는 없지만, 동료 A와 동료 B와 얘기를 해보면, 둘 사이에는 업무를 대하고 처리하는 방식에는 본질적인 차이가 있다.
관리자 M이 한마디로 딱 잘라 말할 수 없는 것을, 어떤 똑똑한 사람이 딱 잘라 말한 것 중 하나가 바로 Dreyfus Model이라는 것이다.
경험이 없기 때문에, 상황에 상관 없이 적용할 수 있는, 다시 말하면, 상황에 따라 적절하지 않을 수 있는, 조리법(recipes) 즉, context-free한 규칙이 주어졌을 때 효과적으로 과업을 수행할 수 있다.
Stage 2: Advanced Beginners
여러 가지 상황에서 의미를 가지는 요소에 대해 인지하게 되고, 이러한 요소를 context-free한 규칙에 더해서 활용하게 된다.
Stage 3: Competent
경험이 쌓이면서, 고려해야 할 요소들이 폭발적으로 증가한다. 불가피하게, 상황 하에서 어떤 요소를 중요하게 고려해야 할 지를 선택한다. 이러한 상황에 대한 모델 하에서, 상황을 분석하고 규칙에 따라 행동을 선택한다. 자신이 선택한 결과 – 성공이나 실패에 대해 책임감을 느낀다.
결과적으로 스스로 문제를 해결(troubleshoot)할 수 있다.
Stage 4: Proficient
Competent 단계에서 경험한 성공과 실패를 바탕으로, 상황에 따라 어떤 요소를 중요하게 고려해야 할 지를 결정한다.
어떤 요소들이 더 중요하고, 어떤 요소들이 무시해도 되는가는 경험이 추가됨에 따라 직관적으로 변화한다. 반면에, 실제로 어떤 행동을 해야 할 것인가에 대해서는 분석적인 사고를 필요로 한다.
Stage 5: Expert
의식적인 사고나 규칙의 필요 없이, 직관적으로 어떤 요소를 중요하게 고려해야 할 지와 어떤 행동을 해야 할 것인가를 안다.
동료 A와 동료 B의 ‘본질적인 차이’란 무엇인가? 동료 A는 아마도 Competent 이상일 테고, 동료 B는 Advanced Beginner 이하일 것이다. 이것이 ‘본질적인 차이’에 대한 본질적인 대답은 아니다.
드라이퍼스 모델이 제시하는 것은 겉으로는 5단계의 구분이지만, 마치 무협지의 주인공처럼 Novice가 어느 날 갑자기 기연을 얻어서 Expert가 될 수 없다는 사실을 내포하고 있다. 즉, 한 단계 높은 숙련도에 이르기 위해서는 충분한 경험과 고민, 트레이닝, 그리고 그것들을 위한 시간이 필요하다는 것이다.
드라이퍼스 모델이 5단계의 구분에서 제안하는 중요한 요소는 바로 직관이라는 요소다. 인간은 구체적인 경험으로부터 직관을 얻을 수 있고, 이것은 컴퓨터와 같은 기계로 추론해 내는 것은 대단히 힘들다는 것이다. 물론 이것은 인간에게도 쉽지는 않으며, 위에서 언급한 것들을 필요로 한다.
대학교 CS 과정에서 프로그래머의 생산성은 10배 이상까지 차이 날 수 있다는 사실을 배운다. 이러한 사실은 프로그래머라면 누구나 현장에서 느낄 수 있다.
하지만, 관리자로서 그러한 사실을 접하는 것은 완전히 다른 경험이다. 프로그래밍 과업의 결과물의 양적 또는 질적인 차이에서 뿐만 아니라, 업무를 얼마나 깊이 이해하고, 어떤 목표를 추구하는가, 그에 따라 어떤 과정을 선택하는가와 같은 일하는 방식의 문제로까지 확장되는 것이다.
당연하기도 하지만, 실제로 그렇다는 것을 깨닫고 나서 놀랐던 사실들이 있다.
일하는 방식에 있어서의 Competent 이상의 능력을 가진 사람은 정말로 소수에 불과하다.
특정 스킬, 이를테면 코딩 스킬이 뛰어나다고 해서, 반드시 커뮤니케이션 방식에 있어서 뛰어난 것은 아니다. 즉, 스킬에 따라 숙련도는 다르다.
경력이 오래 되었다고 해서, 반드시 일하는 방식에 있어서 뛰어난 것은 아니다. 반대로, 경력이 짧아도 일하는 방식이 뛰어난 경우가 있다.
개인 간의 차이는 생각보다 컸고, 기대하는 스킬과 실제 스킬의 차이의 간극도 역시 생각보다 컸다.
이제 나의 고민은, 관리자로서, 어떻게 하면 동료들이 한 단계 더 높은 스킬 숙련도에 이를 수 있도록 도와 줄 수 있는 가이다2. 우선, 자신과 함께 일하는 동료들의 주요 스킬의 숙련도가 어느 단계인가 파악해보자.
1 그의 저서나 이 모델에 관한 권위 있는 텍스트를 접해 본 적은 없으므로, 정확히는 알 수 없지만, 이러한 모델은 과학적인 검증을 거쳤다기 보다는, 인공 지능의 한계를 지적하기 위한 논의를 진행하기 위한 개념적인 모델일 뿐인 것으로 보인다.
2 Andy Hunt의 책에서도 언급하고 있지만, 모든 팀원이 Competent 이상의 단계가 되어야 할 필요는 없다. Andy Hunt는 숲을 보는 사람이 있으면, 나무를 보는 사람도 있어야 한다고 얘기한다. 나도 그러한 생각에 동의한다.
