사용자 도구

사이트 도구


사이드바

메뉴:

블로그:

기타:


연락처:


안내:

blog:emergency

비상체제 개발

비상 체제로 개발할 필요가 없는 프로젝트를 시작부터 비상 체제로 개발시키면 팀을 제어할 방법을 처음부터 없앤 채로 시작하게 됩니다. 비상 체제가 그 이름대로 동작하려면 다른 때는 비상 체제가 아니어야 하고 이를 선언할 때는 종료조건을 명시해야 하며 이 선언의 원인과 앞으로 같은 상황이 일어나지 않도록 할 것임을 구성원들에게 정확히 전달해야 합니다.

의료 체계 일부가 비상 체계로 돌아가고 있다는 글을 봅니다. 약국들은 평소같으면 안 해도 됐을 업무를 하고 덕분에 아주 많은 사람들이 몰려든 상황을 제어하기 위해 노력하고 있습니다. 의료진들은 특별재난지역으로 선포된 지역에 들어가 자비로 체류하며 장시간 노동을 감수하고 있습니다. 엄청나게 늘어난 배달물량을 처리하는데 수많은 분들이 일하고 있습니다. 저는 다행히도 여러 사람들의 배려로 딱히 굶지 않고, 또 병원에 갈 일을 만들지 않도록 조심스럽게 지내고 있습니다. 그러다가 문득 이 비상 체계가 언제까지 유지될 수 있을지를 생각해보고 잠깐 우울해졌습니다.

수많은 의료진들이, 의료계 관련자들이 긴 노동시간을 마다하지 않고 일합니다. 진단 업무를 맡은 분들이 쪽잠을 자 가며 24시간 일하는 이야기를 읽었습니다. 이렇게 글로 만들어지지 않은 얼마나 많은 분들이 이런 상황에 놓여있을지를 생각해봤습니다. 이분들께 필요한 것은 일단은 격려와 응원히지만 그 다음은 시스템화 혹은 하다못해 시스템화할 수 있으리라는 신호라고 생각합니다. 이런 비상체계는 영원히 운영할 수 없고 누군가 더이상 견딜 수 없는 상태가 되면 기능을 다 하지 못하고 무너질 것이기 때문입니다.

문득 이전에 겪었던 다른 양선형 모바일 게임 팀에서 항상 비상 체계로 일하다가 마지막에 비상의 비상 체계를 선언하고 나서 아주 빠른 속도로 팀이 붕괴한 경험이 떠올라 이 상황을 이야기해보려고 합니다.

놀이

개발을 시작하고 시간이 조금 흘러 뭔가 굴러가는 바이너리 덩어리가 생기기 시작하자 외부 사람들은 그걸 완성된 상태라고 생각했는지 제가 '대표놀이'라고 부르는 행동을 하기 시작했습니다. 이 대표놀이를 하는 사람들의 특징은 게임이 양산에 들어갈 시스템을 갖췄는지 아닌지를 구분하지 못하고 오직 실행되는 바이너리 덩어리로 게임의 개발 진척상황을 평가하는 점입니다. 이들은 이 기능이 기술 부채를 얼마나 지고있는지 따위에 별 관심이 없고 이를 설명해도 절대로 이해하거나 납득하려 하지 않으며 이 자세를 유지하기에 충분한 위치와 권한을 가지고 있습니다. 기능이 눈앞에서 동작하는데 뭐가 문제냐는 식입니다. 이 때 프로젝트를 제대로 관리하지 않으면 개발팀의 의지와 아무 관계 없이 순식간에 회사 내부 테스트 일정이나 포커스 그룹 테스트 일정이 잡혀버립니다. 이 상황을 모면하기 위해 또다시 거대한 기술부채를 만들기를 반복하며 프로젝트가 망가져갑니다만 지금까지 단 한번도 이 상황에서 프로젝트의 위험을 관리하는 경우를 보지 못했습니다. 프로젝트를 관리할 스탭 역시 우리들과 마찬가지로 아무런 권한도 없는 파리목숨이기 때문입니다.

비상

거대한 기술부채를 아무렇지도 않게 끌어다 써 실제 제품 생산과는 상대적으로 관계가 적은 테스트 일정이나 시연 일정을 소화하려면 기술부채를 적정한 수준으로 관리하며 개발할 때보다 극적으로 많은 자원이 필요합니다. 예쁘게 말해서 자원이고 있는 그대로 이야기하면 모든 사람들의 초과근무가 필요하다는 이야기입니다. 팀 전체가 항상 '비상 체제'로 운영되기 시작하며 이때부터 본격적으로 위협에 의한 팀 운영을 시작합니다.

한동안은 이 상태로 동작합니다. 업계 어디를 가도 이런 체제로 개발하지 않는 곳을 찾기는 아주 어렵기 때문입니다. 만약 비상 체제와 위협에 의해 개발하지 않는 팀을 극적으로 발견했다 하더라도 단 한 명의 대표놀이에 어이없이 무너지거나 업계 종사자들에게 이런 팀이 있음을 이야기하기에는 그 비율이 너무나도 적어 차마 입에도 올리기 어려운 수준입니다. 스탭들은 체념하고 위협을 받아들입니다. 하지만 여전히 개발 상황과 아무 관계없이 설정된 일정은 스탭들이 항상 더 근시안적이고 더 나쁘고 중기적으로만 봐도 더 비싸고 뒤에 수습이 필요한 선택을 하게 만듭니다. 그렇게 마일스톤을 몇 번은 지속할 수 있겠지만 이제 팀은 만성적인 패배감, 무력감, 부족한 신뢰, 사고능력의 상실을 겪습니다. 이제 뚜렷하게 생산성이 떨어지며 외부에서 보면 구성원들이 더이상 '열심히' 일하지 않는 것처럼 보입니다. 그렇다고 마일스톤 달성 후에 위에서 이야기한 '비상 체제 개발'이 종료되는 것도 아닙니다.

비상의 비상

이전의 어떤 프로젝트에서는 이 상태를 보고 외부에서 개입해 두번째 '비상 체제'를 선언했습니다. 어느 날 팀원들을 회의실에 모아놓고 위에서 이야기한 놀이를 즐기는 분이 들어와서는 이 상태로는 개발을 지속할 수 없다고 판단해 - 여기까지는 맞는 판단입니다만 - '비상 체제'를 선언하며 앞으로 일정 기간 내에 이번 마일스톤 목표를 달성하고 또다른 유저 테스트를 시행하지 않을 경우 프로젝트를 드랍하겠다고 말했습니다. 드랍은 우리 모두의 실직을 의미합니다. 아마도 그 분은 이제부터 팀원들이 본격적으로 위기의식을 느끼고 자발적인 초과근무를 일삼으며 이 상황을 해결해 나갈 수 있으리라 판단한 모양입니다.

결과는 이랬습니다. 그 시점부터 한달에 걸쳐 3명/일의 속도로 팀원들이 회사를 그만뒀고 팀은 붕괴했으며 프로젝트는 예정대로 드랍됐습니다. 우리는 이미 지난 모든 기간동안 비상 체제로 개발해왔습니다. 비상 체제의 비상 체제를 선언하고 야근의 야근을 하고 기술부채의 기술부채를 질 수는 없었습니다.

교훈

이 이야기의 교훈은 사실은 위협을 통해 비상 체제로 개발할 필요가 없는 프로젝트를 시작부터 비상 체제로 개발시키면 팀을 제어할 방법을 처음부터 없앤 채로 시작하게 된다는 것입니다. 비상 체제가 그 이름대로 동작하려면 다른 때는 비상 체제가 아니어야 하고 비상 체제를 선언할 때는 종료조건을 명시해야 하며 이번 비상 체제의 원인과 앞으로 시스템화를 통해 같은 상황이 일어나지 않도록 할 것임을 구성원들에게 정확히 전달해야 합니다. 이들 중 어느 하나가 빠지면 비상 체제는 성공적으로 마무리되지 못하거나 이번에는 어떻게든 마무리됐더라도 다음 비상 체제가 동작하지 않을 것입니다.

잠깐 업계 이야기로 빠졌습니다만 비상 체제 속에서 일하시는 모든 의료 관계자분들과 이분들을 지원하시는 모든 분들께 응원과 존경과 감사를 보냅니다. 제 스스로는 제가 병원에 갈 일을 만들지 않도록 각별히 노력하고 또 이 비상 체제 끝에는 이번의 모든 노력이 시스템화되어 다음번 비상 체계가 의미있게 동작하기를 진심으로 기원합니다.

blog/emergency.txt · 마지막으로 수정됨: 2020-03-15 22:02 저자 neoocean