brunch

브런치북 오피스 게임의 법칙 Vol.2 09화

라이킷 138 댓글 12

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 초맹 Apr 18. 2024

자동 그리고 장애! 회사의 IT 길들이기

자동으로 만들었는데 장애가 왜 나!

장애는 극복 대상이 아니야! 함께 갈 뿐!

계속 잘 가고 있던 모니터 속 그래프 선이 멈췄다.

"비상! 긴급상황! 모두 이리 붙어! 빨리 살려야 돼!"

"죽은 것 같습니다! 새벽에도 좀 간당간당했어요."

"무조건 살려 내야 해! 긴급 장비 상태는 어때?"

"정상입니다. 스탠바이 완료했습니다!"

"좋아! 다시 이머전시 센터 가동하자구!"

"백업 스태프 모두 대기 중입니다."

손이 바빠진다. 땀이 흐른다. 그러나 쉴 틈은 없다. 지금이 골든타임이다! 초조하게 모니터를 응시한다. 멈춘 그래프가 다시 숨 쉬기를 바라는 마음뿐이다.

"어때? 살릴 수 있겠어?"

"사실 언제 죽어도 전혀 이상할 게 없는 상태였어요. 그렇지만 어떻게든 살려보겠습니다."

깜빡임 조차 없는 눈빛 사이로 땀방울이 흘러내린다. 바쁘게 움직이던 두 손이 잠시 멈춘다. 이제 할 일은 하나. 단 한 번으로 생사가 갈린다. 잠시 주춤한다. 뒤에서 보던 스탭들의 침 삼키는 소리가 들린다.

마침내 운명을 건 그의 마지막 손길이 떨어졌다. 사람들의 시선은 모니터로 옮겨간다. 잠시의 정적이 흐르고. 아. 움직인다! 모니터 속 그래프가 정상궤도에 올라왔다. 됐다. 살아났다. 모두 환호한다!

"수고했어! 역시 명의라니까! 어떻게 한 거야?"

"잘 안 돼서 그냥 껐다 켰는데요?"

"응?"

병원 응급실 풍경이 아니다. IT 부서의 시스템 장애 대응 현장이다.

시스템 장애가 나면 모두 몰려와서 계속 쳐다본다.

이들에게 가장 예민한 것은 바로 장애다. 시스템이 먹통 되면 회사가 마비되기 때문이다. 손실은 그야말로 막대하다. 은행 전산이 다운되면 돈이 멈춘다. 포털 사이트가 멈추면 검색도 할 수 없다. 결제 시스템이 멈추면 소상공인은 나락 간다. 브런치가 멈추면 작가들은 글도 발행 못한다. 모든 것이 IT로 연결된 현대 사회에서 IT 시스템 중단은 곧 재앙이다.

개발자에게 장애는 정말 숨이 넘어간다. 휴가 중에도 장애 알람 하나에 비상이 걸린다. 몸은 하와이에 있지만 머리는 프로그램 구조를 떠올린다. 급하게 노트북 열어 비상 접속을 한다.

장애는 언제 어디서든 발생할 수 있다. 장애 원인은 매우 다양하고 광범위해서 사실상 안 날 방법이 없다. 단지 최대한 신속하게 복구해 내는 것이 관건이다. 그러나 회사는 IT 장애를 절대 곱게 보지 않는다. IT 부서의 더욱 큰 난관은 바로 여기서 생긴다.

"냉장고도 한번 사면 10년도 넘게 쓰는데, 이건 왜 이렇게 고장이 잘 나? 뭔가 잘못 만들었겠지."

"우리 집 콤피타는 벌써 10년 넘었는데 쌩쌩해!"

"이거 자동이잖아! 자! 동! 근데 왜 고장이 나냐구!"

어르신들은 모든 장애 원인을 해이한 근무기강으로 돌린다.

그렇다. 윗선은 고정관념이 있다. IT란 자동이고 자동은 고장 나지 않아야 한다. 고장이 없어야 한다는 게 전제다. 그래서 IT는 어떤 경우라도 장애가 용납되지 않는 것이다. 으르신들의 심기가 불편해진다. 곧 불호령이 하달된다. 말은 매우 그럴싸하다.

"5 Why로 다섯 번 물어 근본 원인을 해결하라!"

"장애대책 긴급회의로 재발 방지책을 수립하라!"

"이번 손실을 추정하고 원인 제공자를 밝혀내라!"

"IT가 일을 적당히 대충대충 해서 그런다. 책임소재를 명확히 규명하고 엄중하게 신상필벌하라!"

IT팀은 심폐소생에 성공하고도 여기저기서 대륙간 탄도 미사일에 집중타를 얻어맞는다. 쏟아지는 미사일에 기술의 성지 IT 요새는 맥없이 무너진다. 어둠 속 불꽃이 터져댄다. 더 이상 피할 곳이 없다. 이러다 다 죽게 생겼다. 그래. 남은 건 정면돌파다.

함께 죽은 환자를 살려내며 생사고락을 같이 했던 이들. 방금 전까지만 해도 IT 요새를 지키기 위해 함께 방어했던 동지들이었다. 책임소재를 규명하라는 불호령에 잠시 눈치를 살핀다. 어쩔 수 없다. 이제 서로 개싸움을 벌인다.

"접속장애잖아. 이건 애플리케이션 책임이지!"

"무슨 소리에요? 이거 서버 재기동으로 살렸잖아요. 그럼 인프라 담당자 책임 빼박 아니에요?"

"다들 원인 제대로 아세요? 서버는 무슨.. 통신 프로토콜 이상했던 건데! 그럼 네트워크 쪽이죠."

"말 똑바로 해! 통신이면 다 네트워크 책임이야? 장난해? 프런트엔드 소스 코드 함 까 볼까?"

'더 싸워라. 찢어져라. 물어뜯어라! 그래 잘한다.'

그들이 뭉치지 못하게 회사는 분열의 판을 꾸민다.

팀장의 리더십은 보고를 위한 보고에서 진가를 발휘한다.

아. 안돼! 안돼! 이래서는 답이 나오지 않는다. 다들 그만!! 팀장의 리더십은 여기서 나온다. 팀장은 잽싸게 머리에 프로그램을 짜고 실행한다. 나의 리더십을 보여주마. 자! 자! 지금부터 5 Why 시이작! 의외로 개발자들은 순수하다. 하라면 또 한다. 개발자들은 5 Why에 따라 스스로 5번 질문을 던진다.

'왜 장애가 났을까?'

'왜 막지 못했을까?'

'왜 회사에 손실을 끼쳤을까?'

'왜 으르신들은 쌍심지를 켜는가?'

'왜 나는 이러고 사는가?'

현타가 진하게 밀려온다. 이런다고 해결되는 건 없다. 이렇게까지 해야 하나? 5 Why 기법이란 다섯 번 물어 근본 원인에 다가가는 방법론이라고 이론가들은 말하지만, 그냥 자아비판이자 고해성사다.

개발자는 늘 현타를 달고 산다.

이제 그다음, 손실을 메꿔야 한다. 우당탕탕 으랏차차! 대책 회의 한바탕. 벌써 두 시간 넘었다. 이번 장애 손실 분은 시스템 고도화로 운영 비용 줄이고, 실적 늘려 만회하는 거로 잡는다. 괜찮다. 실은 원래 하려던 거다. 이거 때문에 한다고 대충 아다리 맞춘다.

또 수습책이 또 뭐 있더라. 그래. 코드 리뷰를 해서 품질을 높인다고 하자. 기왕이면 오늘부터 시작했다고 보고하자! 모여 봐. 자! 자! 코드 리뷰 시이~작!

코드 리뷰란 개발자가 만든 프로그램 소스 코드를 낱낱이 해부하여 설명하고 동료 개발자들이 이를 피드백하는 것이다. 코드 품질을 높이고 상호 간에 배울 수 있어 장려한다고 교과서는 얘기한다. 현실은 그냥 인민재판이다. 내가 한 업무를 팀원들이 다 파헤쳐 태클 놓는다고 생각하면 된다. 선임들이 후임들을 대놓고 까게 해주는 아주 유용한 기법이다.

"그렇게 짜 놓으면 프로그램은 굴러가는데, 성능 제대로 나오겠어? 무슨 변수가 저렇게 많아?"

"기능에 비해 너무 복잡하네요. 데이터는 옆 시스템 거 끌어오면 100라인 안에서 끝날 것 같은데요.

반대로 후임이 기가 막힌 코드를 짜도 까이게 된다.

"신기술 쓰는 게 다가 아니야! 호환성은 체크했어?"

"우리도 몰라서 못하는 게 아니라구! 저러다 인터페이스 안정성 무너지면 또 장애야!"

개발자들은 또 한 번의 현타를 겪는다.