이슈와 위기 관리에 대한 허점

이슈(issue)와 위기(risk)는 말 그 자체로 상당한 의미로 해석됩니다. 이러한 단어를 프로젝트에서 언급한다는 것 자체로 금지어로 사용될 정도로 상당한 주목을 끄는 단어들입니다. 또한, 이슈와 위기에 속하는 문제들은 어느 한사람이나 한 팀에 의해서 해결되기 상당히 어려운 문제이기도 합니다. 즉, 전체 조직에 걸쳐 있는 문제인 경우가 대부분입니다.

하지만, 프로젝트에서 이러한 이슈와 위기는 반드시 어떠한 형태로든 해결해야 하며, 누가 맡든지 간에 응대를 해야합니다. 이슈와 위기를 해결하기 위해서 다양한 도구들을 사용하며, 수면 위로 끄집어내려는 노력이 필요합니다. 수많은 조직에서 이슈관리, 위기관리라는 용어들을 붙이는 도구들이 있음에도 불구하고 이러한 이슈와 위기가 수면 위로 떠오르지 않는 것은 결국 이를 관리하려는 태도에 문제가 있다라고 생각이 듭니다. 어쩌면 우리의 프로젝트 문화와도 상당한 관련이 있을 겁니다.

프로젝트에서 이슈나 위기라는 용어로 문제를 제기하는 문화에 대해서 생각해보면, 이를 대처해나가는 주체를 우선적으로 머릿속으로 생각을 합니다. 즉, R&R 이라는 관점에서 이를 구분하고자 합니다. 이슈나 위기를 R&R의 관점에서 구분하려는 태도는 결국 문제를 국한시키고, 그 누구도 그에 해당하는 문제를 스스로 끄집어내어서 자신에게 부담을 지우는 사태를 맞이하고 싶어하지 않은 문화를 만들어냅니다. 또한, 이슈나 위기가 실제적으로 풀리지 않는 문제나 예기치 못한 사태로 발생할 경우에 그 책임을 특정 팀이나 조직에게 돌리는 문화를 만들어냅니다.

Only in Egypt by mnadi

이번 'NEIS 사태'나 지난 번 '농협 사태'를 바라보는 시각에서 이러한 이슈나 위기 관리에 대한 프로젝트 내에서의 문화를 가늠해볼 수도 있을 것 같습니다. 프로젝트 내에서 이슈나 위기라는 분류로 문제를 제기하지 못하는 문화, 그러한 분류로 문제를 제기하면 이를 거론한 사람에게 그러한 해결책을 요구하는 문화, 상위 관리자에게 문제가 있다는 상태를 보고하지 못하는 문화, 문제가 발생되더라도 그 결과에 대해서 예상하지 못해서 그냥 무시하려는 문화 등등 우리가 프로젝트에서 흔히 보고도 그냥 지나치는 현상들이 결국 큰 문제들을 발생시키는 그 배경이 될 수도 있습니다.

물론, 그 원인은 아주 단순하거나 간단한 것일 수도 있겠지만, 이를 해결하는 과정에서 이러한 부담을 어느 한 개인이나 팀에게 전가시키려는 문화로 인해서 그러한 원인들이 프로젝트 수면 아래에서 묻혀버리는 경우들이 대부분입니다. 결국, 이슈나 위기는 이를 제기한 사람과 같이 해결하려는 누군가가 있다면 프로젝트에서 적극적으로 해결될 수도 있는 문제일 것입니다. 같이 고민을 하는 사람이 PM이 될 수도 있고, 조금 더 경험이 많은 사람이 될 수도 있고, 아니면 그 누구도 될 수도 있습니다. 이는 R&R이라는 관점에서 해결되기에는 너무도 광위의 문제일 가능성이 많습니다. 아키텍트, 인프라팀, PMO, 테스터, 개발자, 설계자 등이 같이 해결해야 하는 문제이기도 할 겁니다.

문제는 해결하기 위해서 생기는 것이며, 이를 결코 두려워해서는 안됩니다. 프로젝트는 문제가 많이 발견되면 될수록 더 많은 부분들이 완전하게 됩니다. 또한, 이를 공동으로 해결하려는 문화에서 더 탄탄한 팀웍이 발생됩니다. 이슈나 위기를 귀찮은 것으로 여기기 보다는 오히려 이에 대한 문제가 나타나지 않음을 더 두려워해야 합니다.

이슈나 위기를 처리하는 것 중에 이를 경험했던 경험치에 의해서 비중을 더 크게 잡는 경우도 있습니다. 하지만, 그 경험치가 유사한 개발 환경이나 아키텍처 상에서는 유용하겠지만, 전혀 다른 개발 환경이나 아키텍처에서는 오히려 그 비중이 낮아질 수도 있습니다. 예를 들어, 두개의 서로 다른 시스템 간의 연계는 다양한 문제를 만들어냅니다. 기술적인 문제들 뿐만 아니라, 비즈니스적인 문제들도 같이 포함되어 있어서 이를 해결하는 방법은 이전의 기술적인 문제를 해결한 경험치만으로 판단하기에는 전혀 다른 예상치 못한 문제를 발생시킬 수도 있습니다. 특히, 비즈니스적인 문제에 있어서는 숨어있는 문제들이 결국은 문제를 해결하기 더 어렵게 만들기도 합니다. 이러한 문제들을 비단 시스템 연계라는 관점에서만 해결해서는 안됩니다. 결국 시스템은 서로의 균형을 맞출 수 있는 상태로 양쪽에서 어느 정도는 그 부담을 나누어가질 수 밖에 없으며, 연계 지점은 이를 통로로만 사용해야 합니다. 즉, 시스템의 연계는 전체 시스템의 균형이라는 차원에서 봐야 하며, 단순히 연결되었다고 문제가 해결되었다고 볼 수는 없습니다. 특히나, 데이터에 대한 트랜잭션 문제, 서로 다른 코드 매핑 문제, 서로 다른 부하로 인해 네트워크 부하의 불균형 문제 등 연계 이외에 다른 문제가 더 많이 불거질 수 있습니다.

이러한 예기치 못한 문제들이 발생되면 결국 R&R 차원에서 접근하면 문제들을 밀어내거나 수면 밑으로 묻어버리는 경우들이 많습니다. 즉, 어느 한편에서도 이를 수용하거나 한발짝 뒤로 물러나서 같이 해결하려고 하지 않기 때문에 더 큰 문제들을 야기시킬 수 있습니다. 물론, PM이나 PL이 이를 중재하겠지만, 이러한 외부적인 압력이 없다면 결국 양 당사자의 문제로 불거질 가능성이 높아서 힘의 논리에 의해서 어느 한편 만이 이를 모두 떠안게 되는 불평등한 책임을 지게 됩니다. 그러한 상황에서는 올바른 해결책이 아닌 꼼수와 편법으로의 해결책을 만들어낼 수 밖에 없으며 (충분한 시간이 없는 경우에는 대략적인 방법으로 해결하여 표시 안나게만 해결을 하는 경우도 발생됩니다) 유지보수에도 상당한 영향을 미치기도 합니다.

이슈와 위기는 관리를 하냐 안하냐의 문제가 아니라 어떠한 방식으로 해결을 했느냐의 관점에서 접근해야 합니다. 근본적인 문제를 해결하려는 의식이 팀 전체에게 있어야 하며, 이를 위해서 서로 협조할 수 있는 태도를 가지고 있어야 합니다. 프로젝트에서 자신의 일에만 신경쓰겠다는 개인적인 태도는 이러한 이슈와 위기 해결 능력을 저해시키는 요소입니다. 충분히 해결할 능력이 있는 사람들이 프로젝트 내에는 있으며, 이들의 의견을 경청하고 도움을 요청하는 것도 큰 도움이 됩니다. 모든 것을 어느 한 팀이나 조직에게 맡긴다는 생각과 사고는 이제 달라져야 하며, 공동으로 해결하려는 의지를 가지도록 프로젝트 문화를 바꿔야 합니다.