없는 생활 (2)

지난 (지라)없는 생활에서 제목 낚시를 한 다음 얼마 지나지도 않았는데 또 제목 낚시를 해도 괜찮은가 고민했었는데 한번 제목을 이렇게 붙이고 나니 비슷한 상황이 일어나자 다른 제목을 생각할 수 없었습니다. 하는 수 없이 이번에도 뉴스레터 없는 생활과 관계가 없는 글에 이 제목을 붙인 다음 이야기를 계속해 보려고 합니다. 지난번에는 마일스톤 마감에는 여러 가지 이상한 일이 벌어지곤 하는데 그 중에는 회사가 월말에 주로 맞이하는 여러 행정적인 경계선과 우리들의 마감이 겹쳐 바쁜 때에 황당한 일이 일어날 수도 있다는 이야기를 했습니다. 그런데 꼭 행정과 맞물린 곳에만 황당한 일이 일어나는 것은 아닙니다.

실은 여러 프로젝트 마감에는 마가 끼어 있습니다. 아니면 다른 평화로울 때가 아닌 가장 바쁠 때, 더 이상 일정을 미룰 수 없을 때, 몇 시간 뒤에 서비스를 시작해야만 하는 바로 그 때 온갖 이상한 일이 생기는 이유를 설명하기 쉽지 않습니다. 샤머니즘에 원인을 맡기고 쉬운 결론에 다다를 수도 있지만 여러 가지 문제로 작업을 진행할 수 없게 된 김에 잠깐 자리에서 일어나 밖에 나가 한밤중의 담배 연기 섞인 후텁지근한 바깥 바람을 좀 쐬면 좋을 것 같습니다.

사무실을 뒤덮은 야근의 냄새 대신 지역 스케일의 야근 냄새를 맡으며 냉정하게 지금 무슨 일이 일어났는지 생각해 보면 마감이니까 당연히 모든 사람들이 일하고 있고 모든 사람들이 일하고 있다는 것은 다시 말하면 모든 사람이 형상관리도구에 커밋을 해 대고 있다는 이야기이며 커밋이 일어난다는 이야기는 빌드머신이 계속해서 최대한으로 가동되고 있을 뿐 아니라 빌드를 분산해서 처리하는 모든 기계들로부터 풍부한 열이 발생하고 있다는 의미일 뿐 아니라 이 모든 동작을 기록하는 스토리지들 역시 최대한으로 데이터를 읽고 쓰는 중이라는 의미입니다. 그러니까 이런 상황에서 무슨 일이 일어나도 이상하지 않습니다.

한번은 C레벨 패닉에서 소개한 사례로 어느 프로젝트가 이제 곧 런칭을 준비하고 있었습니다. 정확히는 다음 주에 런칭 일정이 잡혀 있었는데 여러 가지 설명하기 복잡한 사정으로 인해 런칭 일정을 앞당기기로 합니다. 이 상황을 맞이한 여러 사람들이 평생 여러 게임을 개발하며 일정을 미룬 경험은 있지만 일정을 당긴 경험은 처음이라며 당혹스러워 했습니다. 하지만 우리는 일정을 당겨야만 했고 이를 위해 이번 주 까지 개발을 마무리한 다음 주말에 런칭 하기로 결정합니다. 주말 런칭을 위해 우리들은 정말 있는 힘껏 QA가 찾아내는 결함을 수정했고 이에 따라 각자의 컴퓨터는 언리얼을 실행할 때마다 굉음을 뿜어 댔으며 별 생각 없이 다른 사람 컴퓨터 뒤에 서 있으면 컴퓨터를 통과한 후끈한 공기를 바로 들이마셔 기침을 할 지경이었습니다. 한편 이런 상황에 갑자기 빌드가 끝나지 않고 빌드 상태를 표시하는 웹사이트를 새로고침 하자 서버가 응답하지 않는 상태가 됩니다.

대체 무슨 일이 일어난 것일까요. 당시 아이폰 버전을 빌드하기 위해 당시 맥 중 가장 강력한 맥프로를 사용하고 있었습니다. 물론 우리들은 이미 이 연탄맥의 발열 구조가 그들이 광고한 것에 비해 훌륭하지 않음을 어느 정도 알고는 있었지만 그저 온도가 좀 올라가 스로틀링이 좀 걸릴 뿐 빌드 자체는 무리 없이 수행해 내고 있었습니다. 하지만 지난번에 설명한 대로 주말 런칭 직전에 이 기계는 드디어 한계에 도달해 동작을 멈추고 연기를 뿜어내기 시작합니다. 사실 연기를 뿜어냈기 때문에 동작이 멈춘 것인지 그 반대인지는 잘 모르겠습니다. 다행히 더 심각한 화재로 이어지지는 않았지만 우리들은 당장 아이폰 빌드를 만들어낼 다른 기계를 재빨리 설정해 이 기계를 대신해야 했고 왜 하필 오늘, 왜 하필 지금 빌드머신을 사용할 수 없는 사건이 일어나는지 어이 없어 해야 했습니다.

또 한번은 어느 프로젝트에서 퍼포스를 사용하고 있었는데 마감이 가까워 오자 역시 모든 사람들이 미친 듯이 서밋을 하기 시작했습니다. - 퍼포스에서는 흔히 커밋이라고 하는 행동을 서밋(Submit)이라고 함 - 퍼포스 클라이언트로부터 잠깐만 눈을 돌렸다 다시 쳐다보면 체인지리스트 번호가 백 단위로 올라가고 있었는데 문득 누군가가 사무실 전체에 들리도록 큰 소리로 ‘다들 서밋 중지!!!!’ 라고 소리쳤습니다. 아니 지금 바빠 죽겠는데 무슨 헛소리인가 싶어 소리 난 방향을 바라보자 팀 기술 책임님이 크게 손을 휘저으며 ‘퍼포스 하드 꽉찼어!! 서밋 중지!!!’ 라고 외치고 있었습니다. 정신 없이 일하던 뇌는 상황을 인식하자 상황을 받아들이기 보다는 ‘아니 그게 뭔 개소리인가’ 상태가 됐지만 그렇다고 해서 작업물을 퍼포스에 올릴 수 없다는 사실이 달라지지는 않았습니다.

물론 요즘은 그렇지 않을 것 같지만 당시 우리가 사용하던 형상관리도구인 퍼포스는 서버에 스토리지가 가득 차는 상황을 그리 잘 대비하도록 개발되지 않은 것 같습니다. 아무도 신경 쓰지 않는 사이에 우리가 미친듯이 올려 댄 데이터에 의해 스토리지가 가득 찼는데 더 이상 스토리지에 쓸 수 없는 상황일 때 누군가가 서밋을 하면 서밋 한 클라이언트 관점에서는 마치 서브밋이 된 것처럼 행동합니다. 하지만 서버 쪽에서는 서밋 기록만 남고 서밋에 해당하는 파일을 기록하지 않도록 동작하고 있었습니다. 그래서 잠깐 동안 아무도 퍼포스 서버가 모두의 서밋을 받은 것처럼 동작하면서도 실은 아무 파일도 기록하지 않고 있었다는 사실을 몰랐습니다. 그러다가 누군가 업데이트 - 깃에서는 풀 - 를 시도할 때 실제 파일을 가져올 수 없어 에러를 냈고 이 에러를 살펴보는 과정에서 스토리지가 꽉 찬 상태를 발견한 겁니다.

일단 우리는 지난 몇 분 사이에 일어난 서밋을 모두 잃어 다시 작업해야 했고 마감 직전에 누군가는 회사 비품을 뒤져호환되는 스토리지 기계를 수배해야 했으며 스토리지를 증설하고 나서 한동안은 스토리지가 원래 속도를 내지 못해 모�� 사람들의 서밋이 가능하기는 했지만 극도로 느린 상황을 겪어야 했습니다. 사실 스토리지가 슬슬 부족해지는 상황을 그 전의 상대적으로 평화로운 시대에 눈치챘어야 했지만 마일스톤 마감으로 미친 듯이 일하던 우리들은 스토리지가 가득 찼다는 경고를 별 생각 없이 흘려 버렸고 가장 바쁜 순간에 문제가 일어났습니다. 파일이 좀 날아갔지만 퍼포스는 다시 모두의 서브밋을 ‘실제로’ 기록하기 시작했고 다시 빌드를 만들기 시작했으며 각자가 잃어버린 몇 분 동안의 작업은 다행히 일정 전체를 지연 시킬 만큼 대단하지는 않았습니다. 사실 이번에도 왜 하필 그 시점에 그런 문제가 일어났는지 어렴풋이 설명할 수 있긴 합니다. 하지만 도대체 정말 왜 하필 그 시점에 그래야만 했을까요? 누군가 하루라도 일찍 실수로 그래픽 작업 원본 파일을 올려 문제를 노출 시켜줄 수는 없었을까요?

그리고 지난 (지라)없는 생활에서 소개한 에피소드가 마일스톤 마감 기간에 일어나 모두의 작업을 몇 시간 동안 방해했지만 어쨌든 전체 일정에 영향을 주지는 않았습니다. 이윽고 서비스 직전이 됩니다. 그러니까 서비스 전날 이전과 비슷하게 모든 사람들이 있는 힘껏 결함을 수정하고 제한 시간 안에 수정할 수 없을 것 같은 결함을 우회하기 위한 방법을 결정해 적용하고 있을 때 누군가가 금지된 바로 그 단어를 내뱉고 맙니다. “어?” 사람들은 무슨 상황인지 파악하려고 모두의 기본 의사소통 수단인 슬랙을 쳐다보며 다들 한 마디 씩 하려고 했지만 같은 행동을 시도한 모든 사람들이 금지된 바로 그 단어를 말할 수밖에 없었습니다. 바로 우리 서비스 전날 오후에 슬랙 장애가 일어났고 이 장애는 각자에게 말을 입력했지만 말이 상대에 전달 되었는지 안 되었는지 확실하지 않은 상태로 나타났습니다. 누군가에게는 전송한 메시지가 여전히 회색으로 나타나 전송되지 않았음을 파악할 수 있었지만 다른 누군가는 전송한 메시지가 검정색으로 나타나 전송된 것처럼 보였지만 또 다른 사람 화면에는 나타나지 않았습니다.

이번에는 지난번 지라 사건처럼 돈을 안 낸 상황도 아니었습니다. 다들 킥킥대며 마감을 무사히 지나갈 리가 없다는 반응들이었는데 슬랙이 안 되는 정도야 뭐 지라가 없어져 당장 할 일이 뭔지 모르게 되거나 빌드머신에서 연기가 치솟거나 빌드머신이 갑자기 제멋대로 그동안 밀린 윈도우업데이트 몇 달 어치를 한 번에 강제로 수행하느라 수십 분 동안 사용할 수 없게 되는 상황들에 비해서는 약간 귀여운 느낌이었습니다. 처음에는 슬랙이 작동 하는지 안 하는지를 서로 다른 사람의 모니터를 바라보며 확인하던 사람들은 이내 슬랙을 신뢰할 수 없음을 확인하자 자리에서 일어나 큰 소리로 말하기 시작했고 사무실은 순식간에 슬랙 개발 채널이 됩니다. 하지만 그저 큰 소리로 말하면 누가 누구에게 말하는 것인지 잘 알 수 없어 일단 말을 전달하려는 사람 이름을 부르고 그 사람이 뒤를 돌아 보면 이어서 말하는 식으로 현대 인터넷 시대에 의사소통의 첨단을 달리던 팀이 순식간에 전화도 없는 벨 연구소처럼 행동했습니다.

Open

실제로 장애가 얼마나 지속됐는지는 잘 모르겠지만 우리가 느끼기에 슬랙은 거의 한 시간 가까이 사람들의 목청을 높이게 만들었고 지난번처럼 세 번째 모니터에 띄워 둔 슬랙 스테이터스는 서비스 일부에 문제가 있는 상태에서 훨씬 더 광범위한 서비스를 사용할 수 없는 상태로 상황이 악화됩니다. 실은 슬랙 스테이터스 페이지가 좀 더 심각한 상태를 표시할 때 즈음에는 텍스트를 주고 받는 기능은 정상화 되어 모두의 목 상태를 보호할 수 있었는데 여전히 파일 전송이나 검색에는 문제가 있었지만 일단 텍스트라도 주고 받을 수 있는 상태가 어디인가 싶어 여전히 장애 상태인 슬랙에 대한 불만은 순식간에 사라졌습니다. 시간이 지나자 슬랙의 여러 기능이 원래대로 돌아왔고 우리들은 계속해서 작업해 서비스를 무사히 시작할 수 있었지만 이번에도 왜 하필 다른 모든 순간을 놔두고 바로 그 날, 바로 그 순간에 장애가 발생했는지 모를 노릇입니다.

사실 이전의 몇몇 온프레미스 환경에서는 마감 때 하드웨어를 가장 가혹하게 사용하기 때문에 하드웨어 실패가 그 때 일어날 수 있다는 설명은 모두를 만족 시킬 수 있었습니다. 스토리지에 남은 용량을 모니터링하고 부족할 기미가 보이면 이를 담당자에게 알리도록 설정해 미래를 대비할 수도 있었고요. 하지만 하필 그 기간에 지라 이용요금을 납부하지 않아 지라가 끊기거나 하필 그 날 슬랙에 장애가 생겨 우리들의 마감과 서비스 준비에 영향을 끼치는 것은 온프레미스 환경처럼 쉽게 설명할 수 있을 것 같지는 않습니다. 한편 일론님이 X(구 트위터)를 인수하고 나서 슬랙에 돈을 안 내 슬랙이 끊기자 직원들이 당황스러워 했다는 이야기가 생각났는데 그들도 처음에는 그 날 우리들처럼 일어나서 큰 소리로 이야기하다가 목이 쉬어버리는 기분이나, 바로 그 결정을 회사의 새 소유주가 했다는 사실을 알게 된 순간의 기분을 생각해 보고 적어도 우리는 그런 상황보다는 낫고 어쨌든 바로 다음 날 서비스를 시작할 수 있다는 사실에 안도했습니다.

결론. 온프레미스는 그렇다 칩시다. 도대체 슬랙은 왜 마감날 장애인가요.