포스트모템 #1. 커밋 실수로 인한 서비스 장애

🦦 hoonyland

Published in

KimJimin & Company

7 min readSep 23, 2017

0. 포스트모템

평소 건강하고 효율적인 조직 문화에 관심이 많던 나는 지난달 말 즈음 “12. 사고를 쳐도 혼나지 않는 회사” 를 읽고 장난스러운 말과 함께 전체 직원들이 읽을 수 있도록 공유했다.

이렇게 가볍게 공유하고 난 뒤 일주일이 지난 어느 날 정말로 한 직원으로부터 “혼내지 마세요!”라고 할 수 있는 일이 일어났고 지민님은 나에게 “그래서 포스트모템 문화를 실제로 실행해 보셨어요?"라고 물었다. 이렇게 시작된 김지민앤컴퍼니 회사의 포스트모템 첫번째는 한 직원이 테스트 도중 필수 코드를 ‘주석 처리'를 한 채 커밋한 내용을 운영 서버에 반영하여 발생한 서비스 장애에 대한 내용이다.

알고 보니 지민님은 당일 오전 나의 오타로 인해 서비스가 30분 지체됐던 일을 생각하고 나를 혼내지 말라는 뜻으로 글을 공유한 줄 알고 있었다고…

1. 배경

서비스 A: 사용자들이 직접 특정한 주제의 사진들을 업로드하고 서로의 사진들에 투표하는 서비스
직원 가: 경력 개발자, 원래의 서비스 A 담당자
직원 나: 신입 개발자, 새로운 서비스 A 담당자
대표 다
클라이언트 담당자 라

2. 경위: 커밋 기록 순

9월 4일 오후 4시 5분 커밋
> 나는 중복 투표를 거르는 예외 처리 코드를 테스트를 위해 주석처리 한 뒤 다시 복구하지 않고 (10~20분쯤 뒤) master 브랜치에 병합 후 운영 서버에 반영
9월 4일 오후 5시 3분 커밋
> 나는 위 커밋의 문제를 인지하고 주석 처리된 코드를 수정한 커밋을 운영 서버에 반영
> 1번 커밋이 반영된 3~40분 동안 194건의 중복 투표 발생
9월 4일 오후 10시 12분
> 라로부터 실제 서비스에서 중복 투표 데이터가 발견되었고 이에 대한 확인을 부탁한다는 메시지 수신
9월 4일 오후 10시 15분
> 가 는 메시지를 수신한 뒤 이를 확인하겠다는 답변을 보냄
9월 4일 오후 10시 33분
> 다는 이와 관련한 이슈를 확인해보라는 메시지를 슬랙에 공지
9월 4일 오후 10시 37분
> 나는 슬랙의 개인 메시지를 통해 가에게 자신이 오후에 실수로 서버에 반영한 커밋 때문인 것 같다는 내용을 알림
> 메시지 수신이 안되자 전화로 보고
9월 4일 오후 10시 56분
> 나는 슬랙 채널에 자신이 오후에 반영한 커밋에 대한 내용 보고
9월 4일 오후 10시 58분
> 가는 클라이언트에게 위 경위를 전달하고 사후 대처
이후
> 사후 대처 과정에서 문제의 커밋이 몇시에 정확히 서버에 반영되었는지 파악하는데 어려움
> 다가 쿼리로 추출한 내용을 바탕으로 로그인/미로그인 사용자 중복 여부 확인 및 어드민 페이지에서 삭제 처리 진행

3. 문제 / 대처 과정에서의 미흡했던 원인

커밋 실수
> 가장 근본적인 원인으로 나는 문제의 커밋을 서버에 반영하는 시점에 해당 주석처리를 인지하지 못함
> 현재 회사 내 직원의 비중이 대표를 포함하여 경력자 5명, 신입 4명으로 구성되어 있고 이 중 신입 3명은 올해에 들어온 직원들. 따라서 아직은 깃 브랜치 전략이나 소스코드 관리에 있어서 조직 내 통일된 정책이 잡혀 있지 않은 것도 한 원인.
스스로 문제를 인지한 시점인 5시 3분에 커밋 실수 인지한 시점에 보고 누락
> 나는 이 커밋으로 인한 문제를 과소평가하였고 실제 이 코드가 반영된 3~40분 동안 미칠 영향을 예측하지 못함.
최초 중복 투표 관련 메시지 수신 후 보고 미흡
> 최초 중복 투표 관련한 메시지를 수신한 뒤나 본인이 직접 수정을 시도하려고 하였으나 다른 담당자가 수정하고 있으리라 판단하여 최초 보고까지 25분 소요.
> 텔레그램을 통해 문제가 발생한 것을 인지하자마자 본인의 커밋이 원인이라는 것을 스스로는 인지하였으나 잘못된 판단으로 25분 동안 문제 원인을 본인만 인지하고 담당자 및 동료들과 공유하지 못함.
사후 대처 과정에서 문제 발생 시점 파악이 어려움
> 깃과 깃헙을 활용하는 과정에서 미흡한 정책으로 서버에 문제의 커밋이 정확히 몇 시부터 몇 시까지 반영되었는지 판단이 힘듦.

4. 재발 방지를 위한 대책

커밋 실수
> 소스코드 관리나 깃을 활용하는 것에 대한 가장 기본적인 원칙. 첫째, 하나의 커밋에는 하나의 기능 혹은 하나의 버그가 명확히 매칭되도록 주의하며 둘째, 커밋 메시지에 어떤 기능/버그 수정이 담겼는지 명시한다.
> 이 기본적인 원칙은 자신의 소스코드를 커밋에 반영하고 커밋을 원격 서버에 푸시하는 시점에 기초적인 실수를 방지하도록 도와줄 것이다.
최초 인지 시점에서 보고 누락
> 본인이 반영한 소스코드에 대해 섣부른 판단보다는 결과를 눈으로 직접 확인할 때까지 판단을 보류하고 실제 어떤 문제 상황이 발생한 경우 예외 없이 해당 상황에 대하여 담당자나 동료들과 함께 공유한다.
> 개발자는 기본적으로 본인이 작성한 코드에 대한 불신이 좋은 마음가짐이라고 생각한다. 내가 console.log(1)이라고 짰더라도 화면에 1이 뜨기 전까지는 어떤 결과가 뜰지 예상할 수 없는 것처럼.
문제 상황에 대해 클라이언트가 인지한 이후에 원인 공유 미흡
> 자체 프로젝트가 아닌 클라이언트의 의뢰를 받아 프로젝트를 진행하는 경우에는 특히 문제가 발생했을 때 팀 단위에서 인지하고 해결하는 것과 클라이언트가 인지하고 팀에서 수정하는 것은 큰 차이가 있다.
> 클라이언트가 인지한 시점에서는 문제의 심각성을 깨닫고 최대한 빠르게 본인이 알고 있는 정보와 문제 상황을 팀 단위로 공유하고 전파하는 것이 바람직할 것이다. 물론 위 2번처럼 문제가 발생한 시점 직후 공유하는 것이 더 좋지만.
커밋을 통한 문제 발생 시점 파악
> 첫 번째 방법은 서버에 코드를 반영하는 시점 즉, master 브랜치에 병합을 하는 시점에 시만틱 버저닝 룰에 따른 깃Tag를 달고 특정 버전의 소스코드가 몇 시부터 몇 시까지 서버에 반영되었는지 판단이 용이할 수 있도록 한다.
> 두 번째 방법은 좀 더 까다로운 깃 브랜치 전략을 활용하여 master 브랜치에 병합되는 시점에 병합 커밋이 꼭 남도록 기록하여 병합 시점을 통해 운영 서버에 반영된 시간을 파악할 수 있도록 한다.

5. 에필로그

(에필로그에 담긴 생각은 김지민앤컴퍼니의 의견과 일치하지 않을 수 있음을 미리 밝힙니다)

사고가 난 당일 오후 곧바로 포스트모템을 동료들과 함께 공유하고 3주가 지났다. 이 글을 정리하면서 그간 나의 고민을 이 에필로그로 덧붙여보자면 ‘개발회사의 자유도만큼 엄격한 룰은 더욱 중요해지는 것 아닐까?’ 하는 생각이다. 이 글의 가장 첫 마디에 언급했던 ‘건강하고 효율적인 조직 문화’, 그리고 이번 사고의 가장 첫 번째 원인으로 생각한 ‘조직 내 통일된 정책의 부재’는 결국 엄격한 룰과 직결되는 문제이다.

‘자유로운 회사에 무슨 엄격한 룰?’이라고 생각할 수 있지만 엄격한 룰이 있기 때문에 각 개인은 그 룰 아래 자유롭게 근무할 수 있다. 다수의 직원이 하나의 프로젝트를 두고 유연하게 협업하고, 하나의 서비스가 지속적이고 안정적으로 운영되고, 이러한 과정에서 각 개인의 습관과 성향은 최소한으로 반영되며 소스코드 한 줄, 하나의 커밋, 운영상에 반영 등 일련의 활동을 모두가 엄격한 룰에 따라 모두가 움직인다면 예상치 못한 사고의 가능성은 훨씬 줄어드는 것이다. 엄격한 룰은 선임자가 후임자의 활동을 일일이 체크하지 않아도, 후임자는 자신이 취하는 일련의 활동을 하나하나 확인받지 않도록 만들어준다.

반대로 이러한 룰이 존재하지 않고 각 개인의 성격과 성향이 룰보다 앞선다면, 위 사고처럼 기초적이면서도 예상치 못한 사고가 일어날 확률은 높아진다. 각 개인의 경험과 판단력, 실력의 차이가 그 결과물의 차이로 이어질 수밖에 없고 1. 사고가 일어나거나 2. 결과물의 퀄리티가 중구난방이거나 3. 대부분 작업을 선임자가 맡게 될 것이다. 결국, 이러한 사고를 방지하기 위해 후임자는 자신의 행동에 대해 자신감을 잃을 수 있으며, 선임자는 후임자에게 맡길 수 있는 선택지가 줄어들거나, 후임자의 작은 행동에 대해 간섭하게 될 수밖에 없다. 서로가 신뢰와 자유를 잃는 것이다.

평소 지민님이 가진 대표로서의 생각은 각자의 역할 안에서 최대한 자유롭게 책임을 다하는 것이다. 나는 아마 국내에서는 김지민앤컴퍼니가 그 어떤 회사보다 자유로운 문화를 가졌다고 생각한다. 그게 지민님이 가진 회사 운영의 원칙이기도 하고. 이번 사고는 회사의 구성원이 3명에서 8~9명으로 갑작스럽게 늘어나서 겪고 있는 과도기일 것이다. 특히 경력자보다 신입 구성원이 늘어나면서 인원이 적었을 때 미처 고민하지 못했던 조직 문화와 엄격한 개발에 관한 룰의 부재가 조금 더 적나라하게 드러난 사고였다. 이번 실수의 당사자였던 신입 나와 나를 포함해 이를 함께 지켜본 다른 동료들에게도 이번 사고가 개인으로서도, 팀으로서도 좋은 약이 되었기를 바란다.