C레벨 패닉

마일스톤 마감 후 제한된 범위의 고객분들께 서비스 할 때까지 이제 200시간도 채 남지 않았습니다. 하지만 지난 2주 동안 쉬는 날 없이 일해 이번 주말은 좀 쉬는 중입니다. 항상 이 기간에는 지금까지 경험한 적 없는 온갖 이상한 결함이 새롭게 등장하곤 합니다. 지금까지 서로 다른 브랜치에서 평화롭게 개발되던 작은 기능들이 종종 메인 브랜치에 통합 되어 테스트 되기는 했지만 마감 기간만큼 집중적으로 메인 브랜치에 온갖 기능이 머지되고 또 이 기능에 기반한 온갖 데이터가 빌드의 동작 시나리오에 맞춰 커밋되는 상황이 일어나지는 않기 때문입니다.

마감 기간의 메인 브랜치는 아주 난리가 나는데 수 십 명이 하루에도 수 십 번 커밋과 머지를 반복하고 있기 때문입니다. 비 엔지니어 관점, 그리고 바이너리 파일을 주로 다루는 언리얼 엔진 환경에서 개발하며 깃에 대해 여러 번 불평을 해 왔는데 특히 마감 기간에 바이너리 파일이 메인에 대규모로 머지되면 아주 난리가 나곤 합니다. 이 난리에는 서로 같은 바이너리 에셋을 편집한 다음 커밋 하려다가 나중에 커밋 한 사람이 충돌을 해결해야 하는 나름 기초적인 일부터 시작해 서로 다른 기능과 통합된 상태를 크게 고려하지 않고 개발하다가 같은 브랜치에 머지 된 다음 빌드에서 서로가 서로에게 큰 영향을 끼쳐 이전에는 경험한 적 없는 강렬하고 웃긴 오동작을 일으키는 것도 있습니다.

보통 마일스톤 마감은 주로 월말과 일치할 때가 많아 회사의 자금 집행 시스템과 연결된 이상한 문제가 일어나기도 하는데 종종 회사에서 자금을 집행하는데 사용하는 법인카드의 단위기간 별 한도가 초과되어 우리가 사용해야 하는 서비스나 소프트웨어 라이선스 비용 지불이 이루어지지 않아 바빠 죽겠는데 갑자기 서비스를 사용할 수 없는 상황이 발생하기도 합니다. 갑자기 빌드가 느려진 문제를 살펴보니 빌드를 여러 기계에 분산해 수행하는 소프트웨어 라이선스가 업데이트 되지 않았다든지 이슈트래커 소프트웨어 라이선스가 업데이트 되지 않아 모든 사람들이 갑자기 자기가 할 일을 모르게 되는 일이 일어나기도 하는데 후자에 대해서는 없는 생활에서 따로 소개하겠습니다.

이 난리에는 소프트웨어적인 문제만 일어나는 것은 아닙니다. 이전의 한 프로젝트에서는 회사가 역 주변에 있던 여러 작은 오피스 빌딩에 흩어져 있었는데 각 오피스 빌딩 사이에 네트워크는 건물 옥상에 설치한 레이저 기반의 통신 장비를 통해 물리적인 선을 시공 하지 않고 빠른 인트라넷 속도를 유지하고 있었습니다. 하지만 이 장비는 맑은 날에는 잘 동작했지만 비 오는 날에는 속도가 아주 느려졌는데 당연하게도 광학 장비에 기반한 통신은 신호를 주고 받는 직선 상에 나타난 물방울에 큰 영향을 받았기 때문이었을 것 같습니다. 한번은 서비스 개시 직전에 강한 비바람으로 이 시스템이 중단돼 인트라넷이 극도로 느려졌고 여러 오피스빌딩 중 한 건물의 지하에 있던 데이터센터와 통신이 거의 안 되는 상황이 벌어져 전전긍긍한 적이 있습니다.

또 다른 모바일 프로젝트에서는 런칭 직전에 아이폰 버전을 빌드하는데 사용하던 연탄맥이 수 십 시간에 이르는 연속 빌드로 인한 과부하를 견디다 못해 메케한 탄내와 함께 연기를 피워올리는 사고가 일어나기도 했습니다. 소화기를 손에 쥐고 전원이 끊긴 채 연기를 뿜아내는 연탄맥을 걱정스러운 눈으로 보라보기는 했지만 불꽃이 일어나지는 않았고 소화기를 분사할 일도 일어나지는 않았지만 이 사고는 두고두고 ‘빌드머신에서 불 나는 거 본 적 있어요?’ 라는 무용담으로 발전했습니다.

한편 마일스톤 마감에는 이런 소프트웨어적, 하드웨어적 문제 말고도 사람에 의한 문제도 종종 일어나곤 하는데 이제 드럼통이 구를 때 소리가 완벽히 납니다에서 잠깐 소개한 것처럼 마일스톤이 진행되는 몇 주 동안에는 우리들의 시간과 피와 땀을 갈아 넣어 만들고 있는 빌드에 별 관심을 가지지 않다가 마일스톤 마감 5일 전 월요일이 되면 갑자기 그때서야 몇 주 만에 처음으로 빌드를 만져보고는 본인이 생각한 모습과 실제 빌드 사이에 차이가 있음을 발견하고 이를 심각한 문제로 여겨 갑자기 이 괴리를 해결하고자 난리를 치는 상급자들로부터 일어나는 문제가 있습니다.

개인적으로는 개발팀에 소속되어 있는 이상 지위 여하를 막론하고 누구라도 자기 컴퓨터에 형상관리시스템을 설치하고 항상 그 시점의 최신 빌드에 접근할 수 있어야 한다고 생각합니다. 개발팀 내에서 지위가 올라갈 수록 빌드에 대한 익숙하지 않은 감각을 유지하기위해 의도적으로 빌드를 멀리하기도 하는데 이는 의미 있는 행동이라고 생각합니다. 하지만 그런 행동을 하면서도 빌드의 현재 상황을 파악하는 것 역시 어느 정도 이상의 지위를 획득한 사람에게 부여된 임무라고도 생각합니다. 이 두 가지 서로 상반된 임무를 수행해야 하기 때문에 지위가 올라갈 수록 돈을 더 많이 받는 거라고 생각하며 이들 중 어느 한 쪽이라도 잘 하지 못한다면 받은 돈을 토해 내야 할 겁니다.

그런데 지금까지 겪어 본 ‘개발팀에 속한’ 고위 의사결정자 거의 대부분은 심지어 자리에 형상관리도구 환경을 설치하지도 않곤 합니다. 그래서 이 분들에게 개발 현황을 공유하기 위해서는 항상 일상적인 개발환경 내의 커밋과 빌드가 아니라 개발환경과 어느 정도 독립된 빌드 환경을 통해 실행 환경을 준비해야만 합니다. 현대에 이 과정들은 당연히 자동화 되어 있지만 팀의 나머지 스탭들은 그냥 빌드 끝나면 형상관리도구를 통해 바로 받아 실행할 수 있어 짧은 시간 안에 최신 빌드에 접근할 수 있지만 이 분들께 빌드를 제공하려면 추가 시간을 사용해야만 하고 또 이 과정에서만 발생하는 문제를 해��하는데 시간을 추가로 사용해야 할 때도 있습니다.

그리고 보고가 이루어지고 나면 이 분들은 종종 갑자기 지금까지 단 한 번도 한 적 없는 이상한 소리를 토해내기 시작할 때가 있는데 어릴 때는 종종 이 사람들이 미친 것 아닐까 의심한 적도 있지만 시간이 흘러 이런 상황을 여러 번 겪어 보니 갑자기 이상한 소리를 토해 내는데는 다 이유가 있었습니다. 마일스톤 초반에 계획을 승인하고 계획의 세부 구성요소에 집중하기도 하며 시간을 보낸 팀에 속한 고위 의사결정자들은 이 시점에 완성된 빌드의 모습을 머릿속에 그리고 있습니다. 자신의 머릿속을 스탭들에게 더 잘, 더 자주 공유하거나 그렇지 않거나가 고위 의사결정자가 같은 개발팀으로부터 더 나은 결과를 이끌어내느냐 그렇지 않느냐가 결정되는데 종종 이 분들은 머릿속에 그린 빌드가 그대로 개발될 거라고 예상하고는 몇 주 동안 빌드에 별 관심을 가지지 않곤 합니다. 그저 이슈트래커를 살펴보며 어떤 기능이 개발 기한을 어기고 있는지, 누가 기획서를 늦게 작성하거나 누가 데이터를 늦게 입력하는지 살펴보고 이 문제를 해결 하는데만 집중하기도 합니다.

그러다가 마감 주 월요일에 몇 주 만에 처음으로 실제 빌드를 실행해 보는 겁니다. 너무 당연하게도 이 빌드는 지난 몇 주에 걸쳐 상상하던 모습과는 여러 모로 다를 수밖에 없습니다. 먼저 머릿속 상상은 외부에 기록하지 않는 이상 계속해서 바뀌는데 이 변화는 특별히 신경 쓰지 않는 한 자기 스스로 눈치채기도 어렵습니다. 우리들 모두는 매일을 살아가며 다양한 정보를 입력 받으며 기억이 왜곡되는데 마일스톤 초반에 개발팀의 마일스톤 계획을 보고 머릿속에 상상한 완성된 빌드의 모습 역시 마찬가지입니다. 개인적으로 종종 말하는 기계에 의한 검색 서비스와 웹사이트 사이 관계 변화 예상이나 트위터 대안 분산 서비스에 대한 회의적 의견처럼 나중에 가서 틀린 것으로 판명될 수도 있는 의견을 굳이 기록해 두는 이유는 이렇게 기록하지 않으면 과거의 제가 올바른 예상을 했다고 착각하기 때문입니다.

이런 상황 속에서 그 동안 누구에게도 이야기하지 않고 또 스스로도 머릿속 바깥에 기록해 두지 않은 빌드에 대한 상상은 그 동안 충분히 왜곡되어 훨씬 더 그럴듯한 모습으로 바뀌고 이에 기반해 회사의 더 높은 분들께 보고할 시나리오마저 이미 만들어 놓고 있었는데 이 생각과 실제 빌드 사이에 차이가 있다는 당연한 사실을 발견하는 순간 괴로운 일이 시작됩니다.

어떤 팀에서는 이런 상황이 일어날 것을 미리 예상하고 이 의사결정자로부터 ���오는 적어도 지금까지 몇 주에 걸쳐 개발해온 개발팀 관점에서는 완전히 이상한 요구사항을 철저하게 통제하기도 하지만 종종 팀의 권력관계 구축이 잘못 되어 의사결정자를 통제하지 못하는 상태가 되면 의사결정자의 머릿속에서 지난 몇 주에 걸쳐 충분히 왜곡된 이상한 요구사항이 팀에 최우선 지시 모양으로 도착해 개발팀 전체를 당혹스럽고 또 고통스럽게 만듭니다. 지난 마감 때는 중요한 목표로 개발하던 기능이 시각적으로 충분히 훌륭하지 않다는 이유로 기능 자체를 제거한 상태로 마일스톤을 마무리하기도 했는데 이런 일은 다른 마일스톤, 다른 프로젝트, 다른 회사에서도 항상 비슷하게 일어났습니다. 이 상황에서 개발팀은 종종 예상보다 무능한 평가를 받게 되는데 의사결정자의 머릿속에서 숙성된 상상을 만족 시키지 못했기 때문입니다.

더 어릴 때는 이 상황을 이해하지 못했지만 시간이 흐르며 이는 그저 팀 내 권력관계에 의해 종종 일어나는 어쩔 수 없는 예측 가능한 상황이며 이 상황을 회피하기 위해 더 자주 현재 개발 진척을 이슈트래커 모양이 아니라 실제 빌드 모양으로 계속해서 의사결정자 목구멍에 직접 밀어 넣어야 한다는 점을 배웠습니다. 종종 ‘그분들을 절대 놀라게 해서는 안돼’라고 말하기도 하고요. 목구멍이라고 표현했지만 실제로는 눈구멍입니다.

표현이 좀 거칠다는 점을 이미 알고 있지만 다른 분들께 설명할 때도 똑같이 설명하는데 개발팀에 속한 고위 의사결정자는 사실 빌드를 관찰하는 것 말고도 할 일이 아주 많습니다. 온갖 자잘한 의사결정을 해야 하고 팀과 회사에 일어나는 온갖 황당한 상황을 해결해야 하며 시시각각 개발팀의 모든 행동에 의심을 품어 프로젝트를 취소하고 우리들을 모두 해고하려고 혈안이 된 회사를 달래기도 해야 합니다. 이런 상황 속에서도 여전히 마일스톤 계획을 점검하고 또 앞에서 설명한 빌드에 대한 적당히 낯선 상태를 유지해야 합니다. 실은 정말 보통 일이 아닙니다.

개인적으로는 마감 주 월요일 오전에 회의실에 모여 심각한 분위기로 고위 의사결정자의 상상 속 빌드의 모습과 실제 빌드 사이의 차이를 해결할 대책을 논의하는 회의가 일어나는 이 상황을 글 제목처럼 ‘C레벨 패닉’이라고 부르는데 C레벨은 보통 C로 시작하는 아주 높은 분들을 의미하고 뒤의 패닉은 우리가 알고 있는 바로 그 패닉 맞습니다. 고위 의사결정자들이 한동안 개발 진척을 이슈트래커를 통해서만 지켜보다가 이슈트래커가 보여주지 못하는 실제 빌드의 모습을 처음으로 마주하고 분노와 부정의 감정을 개발팀에 발산하는 바로 그 순간을 말합니다.

아마도 우리들이 업계의 저 대단한 네임드들과 일하지 않는 이상은 이 상황을 회피할 수 없으리라 생각합니다. 다만 위에서 잠깐 이야기한 시시각각 빌드의 현재 상태를 고위 의사결정자의 눈구멍에 직접 밀어 넣어 미리 말해주면 참 좋을 것 같은 머릿속에서 충분히 숙성되어 왜곡이 진행되고 있는 상상과 우리들의 현실 사이 괴리를 줄이고 이 과정에서 그분들이 유지해야 할 빌드에 대한 낯선 상태가 방해 받는 결과에 대해서는 그 분들이 알아서 하라고 애써 무시하는 자세가 필요합니다.

결론. 다른 소프트웨어 개발 분야는 어떤지 모르겠지만 게임 개발에서는 개인적으로 ‘C레벨 패닉’이라고 부르는 현상이 항상 발생합니다. 몇 주에 걸쳐 빌드에 별 관심 없이 지내던 고위 의사결정자들이 마감 주 월요일에서야 실제 빌드를 만져보고 머릿속에서 몇 주에 걸쳐 충분히 왜곡된 상상과 현실 사이의 괴리를 부정하고 분노하는 과정입니다. 서로의 역할을 고려하면 이 상황을 완전히 회피할 방법은 없어 보이지만 마일스톤 진행 중 종종 ‘눈구멍에 빌드를 억지로 밀어 넣는 행동’을 통해 어차피 찾아올 패닉에 의한 부정과 분노, 그리고 이에 의한 어처구니 없는 요구사항을 완화할 수는 있어 보입니다.