나 떨고 있니?

죽을죄를 지었나이다...

"실수해 본 적 없는 사람은 새로운 것을 시도해 본 적이 없다" - <알버트 아인슈타인>

 "안녕하세요, 사이트가 접속이 안 되는데요, 무언가 잘못된 건가요?"

고객사에서 급하게 메신저가 왔다. 연이어 업무용 메신저가 요란히 울려 대었다. 오늘 오전 11시 정도 된 시각, 우리는 영문도 모른 채 서버에 붙어 로그에 에러가 남아있는지, 콘솔에서 서버들의 Health 상태를 점검한 이후, 원인을 알 수 없는 일이 벌어졌다고 여기게 되었다.

"네, 딱히 이상한 점이 안 보입니다. 소스를 수정해서 올린 적이 없고, 트래픽도 모두 정상입니다. 수원에서만 안되시는 걸까요?" "네 저희도 되다 안되다 해서요, 허허 이거 난감하네요..." 고객도 난감해했다. 요새 한창 리뉴얼 중이라 다들 예민하다. "일단은 저희 쪽에서 확인을 드릴 부분이 없어요."라고 메신저를 치고 있던 중, 선배 한분이 나서서 메신저를 이어 나갔다. 'ㅇㅇㅇ님이 typing 중입니다...' "지금 모 통신사 장애가 나서 해당 통신사 유저들은 다 먹통이 되었다고 하네요? 유무선 가릴 거 없이 장애고 이로 인해 접속이 안될 가능성이 높아 보입니다." 조용히 타이핑을 멈추고 메신저를 지긋이 지켜보았다. '우리'를 지목하던 고객사에서도 이제는 '모 통신사'를 범인으로 지목할 수밖에 없게 된 것이었다. '내 탓이 아니다.라는 안도의 한숨'과 함께 무슨 일이 있었는지 뉴스를 보게 되었는데, 정말 대형 장애가 발생을 하였고, 특히 큰 영향 도로는 이번 장애로 인해 '각종 결재를 할 수 있는 페이들이 먹통이 되어 현재 어려움을 겪는 소 상공인들의 점심 장사를 망치는 주범이 되었다.'라는 내용의 기사들이 쏟아졌다. "김프로 님, 기사 봤어요? 결재가 안돼서 다들 큰일 이라네요" "그러게요 요새는 현금도 안 들고 다녀서 결재가 안돼 불편이 이만저만이 아니겠어요." "우리만 해도.. 모바일 사원증을 대부분 들고 다녀서 인터넷 안되면 출입이 안될 거 같은데.." "강제로 회사 밖을 못 나가게 될 수도 있겠네요.. 끔찍하다" 이런 이야기를 하며 점심을 먹으러 내려갔다.

---

"24365"

 무슨 말인지 아는 독자 분은 애석하게도 항상 전화와 메신저를 계속해서 바라보며 '비상연락'에 대비하시는 분일 가능성이 높다. 후보 직업군으로는 군인, IT시스템 운영자, 소방관 등등이 있다. 특히 나도 군대에서 장교 복무를 통해 '목욕탕을 갈 때에도' 휴대폰을 항상 챙기고 들어갔던 경험이 있기에 더더욱 이런 일의 고충을 잘 안다. 24시간 365일이라는 뜻의 '24365'는 상시 가동되는 서비스나 시스템을 모니터링할 때 주로 이야기하는 말이다. "계약 시 24365도 포함시키시겠습니까?"라는 말은 너희가 비용을 더 주면, 우리가 상시 대응 체계를 구축하겠다는 말과 같다. 보통 시스템 개발 및 운영 계약에 이를 포함시키는 편인데, 이 추가 계약이 성사되면 보통 이러한 옵션들이 더 붙곤 한다. "장애등급별로 발생 건당 정해진 금액에 대해 페널티를 부과합니다." 보통 이를 가리켜 SLA (Service Level Agreement, 서비스 수준 계약)라고 칭하게 된다. 즉, 어떠한 작업을 하더라도 '무장애'를 반드시 지켜내야만 하는 미션을 안고 서비스를 제공해야 하게 되는 것이다. 여기서부터 비극이 시작된다.

---

"기능 구현은 기본이고요, 장애도 없어야 해요"

 윗 단락에서 언급 한 SLA 계약이 체결된 이후, IT서비스를 제공해야 하는 우리에겐 서비스 모니터링과 동시에 서비스 개선이라는 임무가 떨어진다. 문제는 개선과 장애는 반비례성을 가진다는 것에 있다. '개선'은 무언가를 고치거나 새로 만들어 기능 혹은 성능을 향상하는데 목적이 있는 반면, '장애'는 변하지 않는 시스템에서는 오늘과 같이 외부 요인이 작용하지 않는 한 발생하기 어렵다. 그렇기에 수탁업체에서는 'Defense 모드'를 발동할 수밖에 없는 것이다. "이 기능 내일까지 구현 가능하시죠?" "개발/검증계에는 가능하나, 운영으로 올리기 위해서는 내부 리뷰를 거쳐야 합니다. 일정을 더 주셔야 해요" "이 기능 구현 가능할까요?" "기존 소스의 결합도가 매우 높아 잘 돌아가는 서비스에도 영향이 갈 수 있으니 시간이 오래 소요가 될 것 같습니다." 등과 같은 말들이 요구사항 발의 단계에서는 항상 오고 간다. 그렇다고 수탁업체라고 이런 사실이 마냥 좋을 리만 없다. 사실 더 해주고 싶었으면 싶지 안 해주려고 버티는 사람은 그리 많지 않기 때문이다. 하지만 저 SLA라는 발목에 잡혀서 드라마틱한 개선보다는 점진적 개선을 택할 수밖에 없는 것이 현실이다. 내가 총대를 매고 나섰다가 실수라도 해서 장애가 나면, 그 책임을 오롯이 개인과 그 팀이 져야만 하기 때문이다.

---

"도전보단 안정"

 상황이 이렇게 되니, 개발자와 운영자 모두 안정지향적이 된다. '가만히 있으면 중간은 간다'라는 분위기가 팽배해진다. 무언가를 개선하려는 시도보다 안정성을 더욱더 중요시하게 된다. 그러면서 조직은 점점 무기력해 갈 수밖에 없다. 의견 개진이 이루어 질리 없다. 의견을 낸 사람이 그 일을 맡도록 유도되는 일도 빈번하다. 조직에서 유능하다 인정받는 사람들은 다른 조직으로 그렇게 갈 수밖에 없고, '운영 안정성'이라는 명목 하에 한 조직에서 '오래' 근무한 히스토리를 잘 아는 소수 인력들이 그들만의 헤게모니를 구축한다. 이렇게 조직이 고이게 되면 다른 신규 인력들의 유입이 정체되어 조직은 더욱더 악순환이 된다. 즉, '한번 실수가 나락으로 떨어질 수 있는 위기'임을 알기에, 사람들은 더욱 도전할 생각을 하지 않게 된다.

---

"그럴 수도 있지"

  아직 우리나라는 실수에 관대하지 않다. 사실 실수의 크기가 어느 정도냐에 대한 잘잘못을 가리기 시작하거나 판단하면 끝도 없다. '금전적' 손해를 입혔을 수도 있고, 최악의 경우 '인명 피해'를 입혔을 수도 있다. 내가 이야기하는 것은 '잘하려고 시도했던 실수'에 대해서는 해당 조직 내부에서 만큼은 마녀사냥을 멈추고, 조금 너그러워져도 괜찮지 않을까 라는 생각을 갖고 있다. 오늘 실수한 통신사 직원은 지금도 엄청난 비난을 받으며 잠을 이루지 못할 정도의 스트레스를 받을 것이다. 물론 그 직원이 잘한 것은 아니지만, 실수를 하게 된 배경이 '도전'을 하다 이루어진 것인지, 분명 따져봐야 할 일이다. 어떠한 도전을 통해 조금 더 나아지기 위한 노력 중 이루어진 일이라면, 조직 내부에서 만큼은 감싸주고 위로해줄 필요가 있다고 생각한다. 그래야만 그런 도전정신을 갖는 사람들이 늘어나고 진일보한 미션들이 늘어나 한 단계씩 발전해 조직에 분명 도움이 될 수 있다고 생각한다.

---

"안전망"

맺음말로서, 한국사회가 촘촘한 '안전망'으로 구성된 사회로 가기를 기대한다. '사업 실패'가 자살로 이어지지 않고, '재 도전' 할 수 있다는 희망을 가질 수 있기를, '수능 실패'가 인생의 종말이 아닌, 나를 돌아보고 나의 본질을 '재 발견' 할 수도 있다는 용기를 갖기를, '도전'하다 실패하더라도 "내 그럴 줄 알았다" 등의 조롱 섞인 비아냥 대신 '박수' 받는 사회가 되길 간절히 기대해보며 오늘의 글을 마칠까 한다.