달성되지 않은 목표에 대한 위기관리
항상 모든 마일스톤 목표를 달성할 수 있지는 않습니다. 또 달성한 목표가 성과로 연결되지도 않습니다. 이런 상황은 나중에 큰 위기로 찾아올 겁니다. 그럴 때를 어떻게 대비할 수 있을까요?
요즘은 간만에 행복한 나날을 보내고 있습니다. 가장 큰 이유는 중간관리자 역할을 하지 않고 그저 팀원으로 기여하고 있기 때문인데 중간관리자나 그 이상의 의사결정자 역할을 해야 할 때는 권한은 거의 늘어나지 않으면서 책임은 크게 늘어나 그 안에서 성과를 내기에 급급했기 때문이 아닐까 싶습니다. 실패할 수 없는 목표와 어쩔 수 없는 개발에서 뭔가 잘못 되었음을 감지했지만 이 일이 마일스톤 마감에 맞춰 성과로 평가되기를 모두가 원하기 때문에 그대로 개발을 계속해 나가고 그 다음 마일스톤에 지난번에 뭔가 잘못 되었다는 사실을 알면서도 어쨌든 개발을 강행한 바로 그 기능을 다시 뜯어 고치는 목표를 설정할 때가 있었습니다. 이럴 때 뭔가 잘못되었다는 상황을 감지했으면서도 개발을 강행 시키고 또 이 의사결정에 대해 이의를 제기하는 팀원님들, 그리고 협업 부서의 구성원님들을 설득하고 또 다독이는 일은 상당한 스트레스를 유발합니다. 하지만 아직 수습도 채 끝나지 않은 팀원 입장에서는 대강 프로젝트 전반이나 회사 전반에 걸쳐 무슨 일이 일어나고 있는지 정보를 파악하고 또 상황을 읽을 수는 있지만 그에 따라 제가 직접 뭔가를 해야 할 필요는 없거나 거의 없어 그저 아무것도 모른 체 팀원으로써 주어진 일에 집중하고 또 작은 도움으로 팀에 부여된 업무를 개선하는 수준으로 기여하고 있습니다.
종종 프로젝트에 고위 의사결정자들이 디렉션을 원활하게 도출하기 어려울 경우 의사결정에 큰 비용이 들기도 하는데 이런 상황은 고위 의사결정자들이 수많은 회의에 끌려 다니며 하루 종일 자리를 비우는 모양으로 나타나기도 합니다. 의사결정자들은 동시에 각자가 담당한 세부 조직의 중간관리자 역할을 동시에 수행해야 하기에 높은 의사결정 비용을 감당하기 위해 여러 회의에 하루 종일 끌려 다니다 보면 정작 세부 조직의 중간관리 역할에 소홀해져 팀원들이 큰 어려움을 겪도록 의도하지 않게 방치할 수 있습니다. 팀원 입장에서 이런 상황을 감지하는 가장 쉬운 방법은 내 직속 보스와 이야기 하기 위해 하루 중 아무 때나 보스를 찾아갈 때 보스를 만날 확률이 절반 미만이라면 의사결정 비용이 높은 상황과 구조라고 생각해도 크게 다르지 않을 겁니다. 사실 근본적으로 한 사람이 높은 의사결정비용을 지불하기 위해 지속적으로 여러 회의에 참여하고 그 결과를 따라잡으며 이에 따른 후속 조치를 취하고 팀에 지시하고 그 결과를 따라 다니고 또 그와 동시에 전체 프로젝트에서 우리 팀에 달성해야 할 임무를 관리하기는 거의 불가능하다고 생각합니다. 이는 한 사람에게 넓은 시야와 좁은 시야를 동시에 요구하고 또 태스크 스위칭 할 충분한 시간 여유 없이 의사결정자들이 모인 자리에서 비용이 높은 의사결정을 반복하고 이를 바로 팀에 태스크 모양으로 전달하기를 반복하기를 요구하는데 이를 원활하게 수행할 수 있는 사람은 없거나 거의 없을 겁니다. 어쩔 수 없이 크게 두 가지 업무 구분 중 어느 한 쪽은 느슨해지기 마련인데 고위 의사결정자들이 모인 비용이 높은 의사결정과정의 우선순위를 낮출 수 없기 때문에 나머지 업무 관리가 느슨해질 수밖에 없습니다.
이런 상황은 전혀 드물지 않습니다. 오히려 이런 상황은 여러 프로젝트에 걸쳐 아주 쉽게 일어나고 또 한 번 시작되면 마치 계획 없는 크런치처럼 멈출 수 없습니다. 탑 클래스 영화감독들이 계획 단계에 충분한 시간을 들여 의사결정의 아주 많은 부분을 미리 수행한 다음 실제 촬영을 시작해 촬영 중, 그리고 후반작업 중 필요한 의사결정을 최소화하는데 집중해 위험을 통제한다고 알려져 있습니다. 게임 소프트웨어 개발 역시 몇몇 디렉터나 프로듀서들은 이렇게 행동한다고도 알려져 있지만 프로젝트에 참여하는 연 인원이나 개발비용 규모가 훨씬 크고 이들을 지탱하는 중간관리자, 그리고 고위의사결정자가 훨씬 더 많은 상황 상 최고 의사결정자들이 미리 의사결정을 하고 또 개발 과정 내내 강력한 의사결정 권한을 행사하기는 결코 만만하지 않을 겁니다. 한국에서 프로젝트에 프로듀서가 있고 그 밑에 전통의 3팀장 체제로 구성된 개발팀을 별 고민 없이 구축하곤 하는 이유도 여기에 있습니다. 디렉터 역할을 수행할 만한 사람을 업계 내에서 구하기는 아주 어려운데 이런 역할을 해내도록 교육 받았거나 이런 역할을 해 낼 역량을 가지고 태어난 사람 역시 극히 드물기 때문입니다. 이런 상황에서 잘못된 사람에게 디렉터 역할을 맡겨 책임보다 권한이 큰 상태를 쉽게 만들어 프로젝트 전체를 위험에 빠뜨리기 보다는 전통의 3팀장 체제를 통해 모두로부터 사실상 권한을 제거해 의사결정비용을 높이더라도 심각한 문제를 일으키지 않는 편이 회사 입장에서 더 나은 결정일 수 있습니다.
전통의 3팀장 체제, 여러 팀에 걸친 협업을 요구하는 목표, 게임디자인의 분업이 만들어낸 비 존중 같은 문제들이 뒤섞이면 앞에서 언급한 실패할 수 없는 목표와 어쩔 수 없는 개발 상황이 일어납니다. 계획과 성과 평가 상으로는 아무것도 실패하지 않았지만 분명 한 마일스톤을 실패하지 않고 개발했음에도 저 멀리 있는 런칭 시점이나 사내 테스트 시점은 전혀 가까워지지 않는 이상한 상태에 빠집니다. 하지만 이 상태는 크게 이상하지 않다고 평가되기 쉬운데 방금 이야기한 것처럼 그 누구도, 그 무엇도 실패하지 않았기 때문입니다. 하지만 내부적으로는 모두가 이 상황에 뭔가 잘못 되었음을 알고 또 막상 개발되어 나온 결과가 그 누구도 원하지 않는 모양이라는 사실을 이전부터 예상하고 있었기 때문에 이 결과는 개발되기는 했지만 게임에 잘 사용되지 않거나 사용되더라도 사용될 때마다 관련된 사람들의 사기를 지속적으로 낮추기를 반복하는 슬픈 상황으로 귀결될 수 있습니다. 대량으로 컨텐츠를 입력해야 하는 어떤 기능이 개발되었지만 3팀장 체제에서 그 누구도 이 기능의 외부 고객을 대상으로 한 기능, 그리고 내부 고객을 대상으로 한 기능 요구사항을 적극적으로 어필하지 않으면 보통 외부 고객들을 대상으로 한 요구사항을 나열하며 기획서 작성을 마무리하는 주니어 디자이너님들, 그리고 자신이 개밥을 먹지 않기에 이 개발에 의한 결과가 내부 고객들을 얼마나 고통스럽게 만들지에 대해 별 관심이 없는 엔지니어님들이 협업한 결과 지독하게 생산성이 낮고 불안정한 시스템이 아무렇지도 않게 완성되어 성과로 평가됩니다.
어떤 기능이 마일스톤 목표 관점으로는 달성되었다고 평가했지만 내부 고객 관점에서는 그렇지 않은 평가를 받을 수 있습니다. 방금 언급한 대량으로 컨텐츠를 입력해 인게임에서 동작해야 하는 기능을 개발했지만 마일스톤 마감 즈음에 간신히 테스트 기능을 통과하고 개발 완료로 평가했지만 정작 남은 기간, 그리고 그 다음 마일스톤에 걸쳐 이 기능을 활용해 컨텐츠를 입력하려고 보니 기능은 간신히 테스트 수준을 통과했을 뿐 본격적으로 많은 사람들이 달라 붙어 기능을 사용하기 시작한 환경에는 잘 대응하지 못하고 있을 수 있습니다. 특히 엔지니어님들은 자신들이 시간이 흐르며 점점 더 발전된 지능적인 개발환경의 도움을 받으며 더 빠른 인터레이션과 더 강력한 실수 예측 기능 등의 도움을 받으며 개발하는 것과는 대조적으로 내부 고객들에게는 이런 기능을 제시하는데 인색할 때가 있습니다. 가령 잘못된 값을 입력해 일어난 작은 실수는 엔지니어님들이 사용하시는 코드 에디터 상에서는 즉시 밑줄이 그어지며 선언되지 않은 변수, 처리되지 않은 조건문, 안전하지 않은 값 핸들링 같은 사소한 문제를 확인할 수 있지만 우리들이 접하는 환경에서는 작은 실수에도 아무런 가이드 없이 서버와 클라이언트를 기동해 오동작을 접한 다음에야 ‘방금 입력했던 값들 중 어느 것 하나’가 잘못되었을 가능성이 있음을 짐작할 수 있는 수준에 그칠 때가 많습니다. 이런 상황에서 비 엔지니어 부서에서는 작은 문제를 찾아내기 위해 재기동에 몇 분 씩 걸리는 서버, 클라이언트 환경을 반복적으로 재실행 해 가며 문제를 찾아내는데 엄청난 시간을 소모하며 매우 낮은 생산성을 보이게 됩니다.
어떤 기능이라도 한 마일스톤 안에 완벽하게 개발하기 어렵습니다. 특히 비 엔지니어 조직으로부터 데이터를 입력 받아 인게임에서 동작하는 스크립트와 비슷한 동작을 하지만 스크립트 모양은 아닌 기형적 환경은 인게임에서 결과를 도출하는 사실상의 인터프리터를 개발하는 일과 비슷해지는데 어떤 엔지니어라도 결과를 CLI 환경으로 출력하지 않는 환경에서 적절한 생산성을 보이는 인터프리터를 한 마일스톤 안에 개발해낼 수는 없을 겁니다. 하지만 우리들의 마일스톤 계획은 이런 식으로 동작하지 않습니다. 처음부터 여러 마일스톤에 걸친 개발 계획을 수립하려고 하면 여러 사람들의 걱정과 관심을 불러일으키곤 합니다. 이는 이전에 여러 마일스톤에 걸친 큰 기능을 개발할 때 이 기능을 마일스톤 단위로 분할하지 않고 여러 마일스톤에 걸친 커다란 기능으로 개발하려 하다가 위험 관리에 실패해 여러 마일스톤이 지난 다음에야 개발이 제대로 진행되고 있지 않음을 눈치채 프로젝트 전체에 심각한 문제를 일으킨 사례가 여러 번 있어 왔기 때문입니다. 실제로 규모가 큰 기능을 개발하기 위해 한 번에 너무 큰 규모와 너무 긴 기간을 할당하면 종종 관리되지 않고 방치되는 상태에 놓이면서도 관리자들의 걱정을 피할 수 있게 되어 미래의 위험성을 크게 높입니다. 이전에 참여한 어떤 프로젝트에서는 처음부터 한 마일스톤보다 더 큰 기능은 애초에 개발을 허용하지 않았고 그런 기능이 반드시 필요하다면 반드시 기능 단위를 한 마일스톤에 맞는 수준으로 구분해 한 단계씩 진행하도록 해 위험을 관리하기도 했습니다.
이렇게 커다란 기능을 기간 별로 나눠 개발하는 접근은 분명 위험을 낮추고 개발 과정의 위험성을 관리하고 또 통제할 수 있게 해 주지만 당장 이 기능을 활용해 성과를 내야 하는 사람들을 이상한 상황에 빠뜨리기도 합니다. 스크립트와 유사하게 동작하지만 결코 스트립트 모양은 아닌 데이터를 작성해 서버, 클라이언트 기반에서 그 결과를 확인하는 개발 환경에서 주의깊게 개발되지 않은 기능은 쉽게 오동작합니다. 사실 엔지니어들이 사용하는 현대의 대단한 개발 보조 기능은 이들보다 훨씬 몸값이 비싼 똑똑한 사람들이 모여 오랜 시간에 걸쳐 개발하고 개선해 온 결과입니다. 반면 내부 고객들이 사용할 어설픈 데이터 입력 방법과 이를 반영해 동작하는 인게임 환경은 훨씬 열악한 환경에서 한 마일스톤에 맞춰 개발하기 위해 아슬아슬하게 노력한 결과물일 뿐입니다. 그래서 잘못된 값을 입력 받고도 아무 에러를 뱉지 않거나 엉뚱한 위치에서 에러를 표시하거나 인게임에서 예상하지 못한 방식으로 오동작해 오동작 자체와 이 오동작을 일으킨 원인을 결코 연결시키지 못하도록 동작해 데이터를 입력하는 비 엔지니어들을 고통스럽게 만듭니다. 하지만 이는 당연합니다. 한 마일스톤에 걸쳐 아슬아슬하게 기능이 구동되도록 하는데 집중하고 최소한의 테스트 시나리오를 달성하면 기능이 완성된 것으로 평가하기로 한 상황에서 이를 만족한 이상 기능이 개발되지 않았다고 평가할 수는 없습니다. 기능의 완성도가 좀 낮다고 평가될 여지가 없지는 않지만 이 역시 애초에 한 마일스톤 만에 개발할 기능이 아니기에 다음 마일스톤에 이어 개발하면 됩니다.
문제는 여러 마일스톤에 걸쳐 개발해야 할 기능이 첫 마일스톤 동안 개발되어 이미 내부 고객 손에 쥐어졌을 때 그 다음 마일스톤에 수행해야 할 정상적인 개발은 내부 고객들의 피드백을 받아 이들의 작업을 고통스럽게 만드는 요소를 줄이고 더 빨리 이터레이션 할 수 있도록 개선하며 인게임에서 알 수 없는 오동작을 일으키기에 앞서 테스트 이전에 기계가 잘못된 값을 평가해 미리 사람에게 알려주는 등 생산성을 올리기 위한 개발을 계속하는 거라고 생각합니다. 기능은 이제 겨우 한 마일스톤에 걸쳐 개발되었을 뿐이지만 일단 내부 고객 손에 쥐어진 이상 내부 고객들의 요구사항을 반영한 개발을 하지 않을 수 없습니다. 하지만 실제로는 이미 다음 마일스톤 계획은 이전 마일스톤에 일부만 개발한 기능의 나머지 부분을 개발하는 것으로 계획됩니다. 이 상황에서 이미 이 기능을 사용하기 시작한 비 엔지니어 조직은 극도로 낮은 생산성을 감수하고 또 이터레이션에 엄청난 시간을 소모하며 서서히 이 상태에 익숙해지며 마른 수건을 쥐어 짜는 최소한의 생산성을 내는데 도달하곤 합니다. 그러는 사이에 새 마일스톤의 개발이 지속되며 아마도 이 마일스톤이 끝날 때 즈음 이번에도 최소한의 테스트 시나리오를 달성하면 목표를 달성했다고 평가할 참입니다. 이 기능 개발을 담당한 엔지니어 집단이 이미 새 마일스톤 목표 달성에 집중하고 있다는 사실을 알고 있기에 이 기능을 사용하는 내부 고객들은 이번 한 마일스톤에 걸쳐 직접 개밥을 먹고 직접 고통 받아 가며 도출한 개선사항의 목록을 준비하고 있을 겁니다. 또 너무 늦은 시점에 이 목록을 엔지니어 그룹에게 전달하면 다음 마일스톤 목표에 포함되지 못할 가능성이 있으니 마일스톤 진행 중 종종 이 목록을 엔지니어 그룹에 전달해 당장 개선 가능한 항목을 개선하거나 다음 마일스톤 계획에 포함되기를 의도할 겁니다.
하지만 이런 방식의 개선 요청은 안타깝게도 우선순위가 그리 높게 평가되지 않아 마일스톤 목표에서 쉽게 빠질 수 있습니다. 이미 이 기능에 의해 고통 받던 내부 고객들은 이 상태에 어느 정도 익숙해져 처음보다는 그나마 나은 생산성을 보일 수 있게 되어 버렸고 이들이 지난 오랜 기간에 걸쳐 고통 받으며 도출한 개선 요청이 나열된 기나긴 목록은 엔지니어가 기능에 대한 요구사항으로 만들 만큼 정규화된 모양과는 거리가 멀기에 그 기능 하나하나에 대응해 개선하려고 보면 이미 개발된 기능의 많은 부분을 고쳐야 할 수도 있습니다. 그래서 엔지니어들은 개선 목록을 보고 내부 고객이 어떤 어려움에 처해 있는지 대략 짐작할 수는 있지만 막상 이 목록의 각 항목을 하나하나 개선할 엄두를 내기는 어렵습니다. 이쯤 되면 조직에 따라서는 다시 처음 요구사항을 냈던 시스템디자인 조직에 내부 고객의 요구사항을 반영한 새로운 요구사항을 정규화된 모양으로 작성해 달라고 요청할 수도 있습니다. 이는 틀린 방법은 아니지만 이미 내부 고객들 손에 쥐어져 인게임 컨텐츠를 채우고 있는 상황에서 다시 요구사항을 정규화하고 이를 다시 한 마일스톤, 혹은 그보다 더 긴 마일스톤 기간에 걸쳐 개발한 다음에야 문제를 개선할 수 있는 상황으로 만들어 버립니다. 그나마 이는 엔지니어 조직과 비 엔지니어 조직 사이에 서로 문제를 해결하려는 적극적인 의지가 있고 또 서로 문제에 공감하고 있을 때 가능합니다. 실제 세계에서는 일단 기능을 납품한 다음에는 기능의 실제 사용과 동작을 모니터링 할 업무 없이 바로 다음 마일스톤의 다른 업무에 할당되기 십상이어서 내부 고객들에 무슨 일이 벌어지고 있는지조차 모르고 있기 더 쉽습니다.
자. 그렇다면 위기는 언제 일어날까요. 이미 앞에서 소개한 의사결정자들이 하루 종일 하고 있는 회의에서 생산성이 충분히 나오지 않고 있으며 이를 해결해야 한다는 사실을 알고는 있을 겁니다. 하지만 이들은 실제 기능을 사용하는 내부 고객은 아니기에 문제가 있음을 알지만 문제를 구체적으로 규명하지는 못할 수밖에 없습니다. 이 자리에 모인 엔지니어 부문 고위 의사결정자 역시 뭔가 문제가 있음을 이해하지만 이 분 역시 기능을 실제로 사용해본 적도 없고 기능이 사용되는 모습을 지켜본 적도 없으니 문제가 있다는 사실에는 공감하지만 이 상황을 해결해줄 수는 없습니다. 이 상황을 개선하기 위해 이제 팀에는 앞서 속대한 그 동안 여러 차례 작성했던 기능을 사용하면서 기입하기 시작한 기나긴 개선 요청사항 목록을 요구합니다. 이미 오래 전부터 작성됭 업데이트 되고 심지어는 엔지니어 부서에 여러 번 전달되었지만 우선순위에 밀려 계속해서 실제 개선으로 연결되지 않으며 내부 고객들의 사기를 떨어뜨리던 바로 그 목록입니다. 이 목록이 어떻게든 고위 의사결정자들이 모인 회의에 전달되고 그 안에서 이야기가 진행된다면 그나마 이는 최악의 상황은 아닙니다. 이 자리로부터 이 목록을 바로 엔지니어 부서에서 받아들여 개선을 시작하거나 시스템디자인에 목록을 내려보내 이 목록을 정규화한 요구사항을 도출해 달라고 요청할 수 있고 고통이 당장 해소되지는 않겠지만 그나마 서서히 나아질 것을 기대할 수는 있습니다. 일단 고위 의사결정자 그룹으로부터 명령이 내려왔으니 우선순위를 마냥 낮게 평가하기도 어려울 겁니다.
위험은 이 상황에서도 기능의 우선순위가 오르지 않을 때 조용히 찾아옵니다. 이미 내부 고객들은 여러 마일스톤에 걸쳐 고통 받으며 극도로 낮은 생산성을 보이며 이를 개선할 방법을 오랜 기간에 걸쳐 제안하기를 반복했지만 개선되지 않는 상황 속에 사기가 떨어지고 있음을 모두가 알고 있습니다. 다음 마일스톤에는 정말로 자원을 집중해 이 문제를 해결해야 할 것 같다는 사실을 고위 의사결정자들 이 공감하고 있습니다. 그런데 바로 이 순간 이미 반 년 전에 경영진에게 보고해 별 문제 없이 개발하고 있음을 전달한 플레이어와 몬스터 간의 전투 메커닉을 경영진이 다시 점검하고 싶어한다면 이미 몇 달에 걸쳐 내부 고객들이 받던 고통을 해결하는 것보다 경영진의 점검 요구의 우선순위를 더 높여 대응할 수밖에 없게 됩니다. 경영진은 우리들이 이 프로젝트를 지속하며 급여를 받아 생계를 유지하게 만들어주는 원천입니다. 그래서 경영진의 요구를 거절하기는 거의 불가능합니다. 이전에 경험한 프로젝트에서는 경영진 이름을 영문 약자로 부르곤 했는데 가령 경영진 이름의 영문 약자가 ab라면 ‘ab가 이번 마일스톤 끝난 다음 PvE 전투를 점검하고 싶네요’ 같은 이야기가 회의 때 튀어나오고 이 말이 나머지 모든 개발 항목의 우선순위를 낮춰 버립니다. 만약 이 시점에 내부 고객들의 개선 요구사항이 기나긴 목록 모양이 아니라 시스템디자인의 손을 한번 거친 정규화된 요구사항 모양이라면 낮아진 우선순위에도 불구하고 어쨌든 마일스톤 계획에 밀어넣을 동력을 얻을 수 있겠지만 여전히 정규화되지 않은 목록 모양이라면 우선순위를 다투는 마일스톤 목표 설정 경쟁에서 또 다시 밀려날 수 있습니다.
이제 위험은 이 경영진 보고가 마무리된 다음 이번에는 경영진이 우리들이 지금까지 마일스톤마다 계속해서 우선순위가 낮아 뒤로 미뤄 왔지만 어쨌든 비 엔지니어 조직이 열악한 환경 속에서 피똥 싸며 처음에는 개선사항 목록을 만들기를 반복했고 그 다음에는 그 상황 속에서 생산성을 어떻게든 유지하는 방법을 찾아냈으며 그러기를 반복하다가 어느 순간 더 이상 개선사항 목록을 제출하기를 그만두고 낮은 사기와 낮은 생산성에 기반해 형식적으로 개발하고 있던 바로 그 기능에 대한 점검을 요청할 때 찾아옵니다. 이번 마일스톤이 종료될 때 인게임에서 바로 이 기능에 의해 개발된 결과물을 평가할 순간이 찾아오면 이제 우리들은 당장 무엇을 해야 하는지 알 수 없는 상황을 맞이하게 됩니다. 이미 이 기능에 대한 문제는 기나긴 개선사항 목록으로부터 몇 달 전부터 알려져 있었습니다. 어쩌면 이를 기반으로 정규화된 요구사항 모양의 시스템 기획서가 이미 오래 전부터 프로젝트에 돌아다ㅏ니고 있었을지도 모르며 이미 이걸 당장이라도 개발할 것처럼 브리핑 회의를 여러 번이나 가졌을지도 모릅니다. 하지만 그렇게 개발해서는 한 마일스톤 안에 기능 개발과 개선된 기능에 기반한 작업 방식 변경, 기능 개선에 따른 데이터 비호환이 발생해 이를 처리하는데 드는 기간 따위를 모두 커버할 수 있음을 그리 어렵지 않게 알 수 있습니다. 이제 진짜 위험이 찾아왔습니다.
예상대로 경영진은 연대장 마냥 실망하고 우리들은 이 상황을 빠른 시일 안에 개선하는 명령을 받겠지만 조직에서는 이 상황을 개선하는 것과 동시에 이 상황을 유발한 책임이 누구에게, 또는 어느 부서에 있는지 파악하려고 할 겁니다. 항공업계에서는 사고가 일어나면 커다란 인명 피해가 발생하기 때문에 항상 문제의 원인을 끝까지 추적해 사고 보고서를 작성하고 이를 바탕으로 같은 문제가 다시 발생하지 않도록 집중한다고 합니다. 현대의 여러 절차들은 그렇게 여러 사람들의 희생과 그 희생을 결코 헛되이 하지 않으려는 업계의 노력에 의한 것입니다. 우리들의 작은 실수가 인명 피해로 연결되지는 않지만 지난 여러 마일스톤 동안 특정 기능의 낮은 생산성이 방치된 원인을 찾으려고 할텐데 원인을 찾는 것은 분명 나쁘지 않은 행동이지만 이런 행동은 굉장히 쉽게 이 모든 잘못된 상황을 유발한 단 한 사람, 단 한 부서를 지목하는 방향으로 흐르기 쉬우며 이 상황을 정신 바짝 차리고 막기 위해 적극적으로 행동하지 않는 이상 누군가 너무 간단히 매달릴 수 있습니다. 그래서 개인적으로는 누군가 매달릴 그 상황 자체를 합리적으로 평가해 문제 해결에 집중하도록 가이드 하기 보다는 우리도 잘못의 일부에 기여했겠지만 우리, 또는 우리들 중의 누군가가 매달리지 않도록 하는데 집중할 필요도 있다고 생각합니다.
여기에 위기관리가 필요합니다. 어떻게 보면 이런 행동과 생각흔 위기관리라는 이름의 비겁한 책임회피로 보일 수 있습니다. 보일 수 있는 것이 아니라 그냥 그렇게 보일 겁니다. 인정합니다. 하지만 경영진으로부터 호되게 얻어 맞은 사람들의 정신 상태는 이미 온전하지 않고 그런 상태에서 모두가 합리적인 관점에서 자신들의, 그리고 자신들이 대표하고 있는 각 부서들의 잘못을 솔직히 이야기하고 문제 해결에 집중하기를 바라는 것은 현대를 살아가는 우리들에게 너무 이상적인 행동을 요구하는 일이 아닌가 싶습니다. 이런 관점에서 위기관리는 저 자신, 혹은 우리들 중 누군가가 매달리지 않도록 문제의 핵심 원인으로부터 약간 비켜 선 자리로 살짝 이동하는 것입니다. 이미 위기가 발생한 다음 이 행동을 하기에는 이미 늦습니다. 이전 여러 마일스톤에 걸쳐 문제가 발생해 왔고 이 오랜 기간에 걸쳐 위기 상황을 예상하고 준비 해 왔어야만 이 결정적인 순간에 매달릴 단 한 사람이 선택될 상황에 조용히 자리를 피할 수 있습니다.
이미 오래 전부터 모두가 뭔가 문제가 있고 문제를 완화할 개선사항 목록이 여러 차례 도출되었다는 사실을 알고 있습니다. 상황에 따라서는 개선사항 목록을 바로 마일스톤 목록으로 설정하기 쉽지 않기 때문에 시스템디자인을 거쳐 개선사항 목록을 정규화한 요구사항 문서를 만들어 놓았을 수 있습니다. 미래의 위기 상황에 준비하기 위해서는 비 엔지니어 부서의 관점에서 문제점을 계속해서 노출 시키고 명시적인 방법으로 이를 해결할 수 있는 부서, 해결할 수 있는 부서를 움직이는 관리 부서, 마일스톤 계획을 수립하는데 관여하는 여러 고위 의사결정자들에게 계속해서 주입해야 합니다. 매 주 회의마다 지겹게 계속해서 같은 의제를 들고 나와 사람들을 고통스럽게 만들고 매 주 회의록에 이 개선사항이 또 나타났지만 우선순위에 밀려 마일스톤 계획에 포함되지 못했다는 사실이 언급되도록 만들어야 하며 개선사항 목록 만으로는 마일스톤 계획에 포함하기 아주 까다롭다는 의견에 대응해 어차피 마일스톤 계획에 포함되기 어려울 거라는 사실을 알면서도 자원을 사용해 개선사항 목록을 정규화한 기획서를 작성해 마치 당장 개발해야 할 것처럼 브리핑 해야 합니다. 설사 당장 개발을 결정할 권한이 없더라도 이미 마일스톤 목표에 당장 포함시킬 수 있는 모양으로 만들어진 요구사항이 존재하고 브리핑을 마쳤으며 이를 들은 사람들의 공감대마저 이끌어낸 기능이 우선순위에 밀려, 다른 여러 이유 때문에 마일스톤 계획에 포함되지 못하고 있고 이에 따라 내부 고객들이 고통 받는 상태가 방치되고 있음을 계속해서 회의록에 기록으로 남겨야 합니다.
조직 구성원들의 사기가 떨어지고 아무리 말해도 개발되지 않으며 개선되지 않는 상황 속에 불만 가득한 소리를 듣게 되더라도 적어도 관리자 자기 자신은 지치지 않고 미래에 닥쳐올 위험 관리 관점에서 이 행동을 계속해서 하고 있었어야 합니다. 그러면 미래에 위기가 찾아왔을 때 분명 자기 자신이 문제의 원인이 아님에도 억울하게 광장에 매달려 화형 당하는 참사를 피할 수 있습니다. 또한 흑사병 창궐 이후 찾아온 르네상스 시기처럼 위기가 찾아오고 누군가가 큰 피해를 입을 수 있지만 우리들이 그 위기로부터 살아남는다면 뒤이어 우리들의 요구사항이 높은 우선순위로 개발되어 지금까지 오랜 기간에 걸친 울분을 털어버리고 생산성을 높일 수 있는 르네상스 시기가 찾아올 겁니다. 이 때 우리들 모두가 살아 있어야만 그 시기를 즐기며 즐겁게 일할 수 있습니다.
오늘은 좀 부끄럽고 지저분한 이야기를 해 보았습니다. 어떻게 회사에서 이런 식으로 일할 수 있을지 어처구니 없이 느껴지실 수 있고 제 스스로도 그런 평가를 깊이 이해합니다. 그런데 실제 조직은 처음 회사 밖에서 생각했던 것 만큼 합리적으로 동작하지 않으며 우리들의 지난 역사가 말해주듯 합리적으로 평가해 앞으로 나아가는 대신 문제의 원인을 단 한 사람, 단 한 조직으로부터 찾으려는 고약한 습성이 없지 않은 것 같습니다. 장기적으로는 교육을 통해 우리들 스스로가 더 합리적으로 판단하고 우선순위를 평가할 더 나은 방법을 사용해 프로젝트를 성공시키는데 집중하도록 변화해 가야 할 겁니다. 그런데 그런 시대에 도달하려면 당장 죽지 않고 살아남아야 하며 그러려면 이런 부끄러운 방법으로라도 현재의 위기에 대처해야 한다고 생각합니다.
이번 55호에도 지난 2주간 공유한 이야기를 함께 보내 드립니다.
최근 서해안에 적조가 나타나는데 이 적조 중 일부에 야광충이 포함되어 있어 밤에 빛난다는 소문을 들었습니다. 어느 금요일 밤 퇴근하자마자 서해안으로 두어 시간을 달렸습니다. 가는 동안 야광충이나 반딧불이를 만나려는 사람들이 모여 있는 채팅방에서 먼저 도착한 사람들, 그리고 근처에 사는 사람들이 야광충이 보이는지, 보인다면 얼마나 보이는지 리포트 하는 정보를 받아 그때그때 목적지를 수정했습니다. 처음에는 엉뚱한 항구 근처에 갔다가 잔잔한 바다에 뭔가 던지면 간신히 희미하게 반짝이는 모습을 볼 수 있는 수준이어서 좀 아쉬워하며 그만 돌아갈까 했습니다. 그러다가 근처 해안에 야광충이 잘 보이기 시작했다는 메시지를 보고 바로 달려갔습니다.
파도가 치는데 따라 야광충들이 반짝이는 모습은 정말 황홀하고 신기했습니다. 우리들이 물체에 반사된 가시광선을 통해 사물을 인식하기 때문에 물체가 흡수하는 색상 대신 물체가 반사하는 색상을 보고 있다는 사실을 알고 있었습니다. 하지만 우리는 평소에 사물이 흡수하는 색상을 볼 수 없기에 알고는 있지만 그런가보다 하고 지나갔습니다. 야광충은 밤에는 이렇게 파랗게 반짝이는 색상으로 보이지만 낮에는 반대 색상인 적조 모양으로 보입니다. 이거야말로 스스로 내는 색상과 가시광선을 반사하는 색상이 서로 반대임을 알 수 있는 훌륭한 사례다 싶었습니다.
한편 야광충이 서해안의 꽤 높은 지역에도 나타났다는 사실은 지구가 꽤 멸망하고 있다는 증거이기도 합니다. 이들이 나타났다는 말은 이 동네 바다가 이전보다 훨씬 더워졌다는 의미이기도 하니까요. 야광충을 바라보던 그 순간만큼은 이렇게 아름답게 멸망하는 것도 아주 나쁘지만은 않을 수 있겠다는 엉뚱한 생각을 잠깐 해봤습니다. 한편 야광충이 빛나는 원리에 대해서는 이 영상을 참고하세요.
그럼 다시 2주 뒤에 뵙겠습니다. :)
