💩😢 커리어 첫 빅똥을 싼 뉴비들에게 바치는 위로

서문

이 글은 뉴비였던 과거의 나와 현재의 뉴비들에게 드리는 글입니다. 누구나 똥은 쌉니다. 한 번쯤은 좀 큰 똥도 쌉니다. 개발자 커리어에서도 마찬가지입니다. 만약 그랬어도 너무 자책하지 말라는 말을 하고 싶습니다. 다음부터 안 그러면 돼요.

라이브 서비스가 다운되었을 때 개발자의 신체에 미치는 영향

회사에 들어오기 전에는 알 수 없는 것들이 참 많습니다. 사용자 분들께 돈을 받는 실제 서비스에서 장애가 난다는 것이 어떤 일인지는 상상하기 힘들 거예요. 학생 때는 프로젝트에 버그가 있거나, 뭔가가 잘 안 돼도 나 이외에 아무도 피해를 입지 않았어요. 하지만 이제는 달라요. 좁게는 우리 팀원부터 넓게는 우리의 서비스를 사용하는 모든 사람이 영향을 받을 거예요. 그런데 그런 실제 서비스에 내 실수로 장애가 일어난다면... 이 글을 읽고 있는 분 중에는 그 일을 막 처음으로 겪은 분들도 있겠죠. 고생 많으셨습니다. 정말이지 건강에 안 좋은 일이죠?

장애 발생의 징조

보통 그러한 장애는 자신감이 넘칠 때 일어나더라고요. 나는 우리 서버가 어떻게 되어 있는지 다 알고 있다. 이 코드는 내가 진짜 다 알고 있다. 이건 안전하다. 거기에 특히 무언가를 가라로 했을 때(PR 리뷰를 안 받았다든지, 테스트케이스를 작성 안 하고 코드를 올린다든지, etc.) 이런 일이 많이 발생합니다.

뇌정지

평소처럼 엔터키를 딱 눌렀는데, 뭔가가 다릅니다. 빌드 성공했다는 초록색 알림 대신, 빨간색 얼럿이 슬랙에 쭈루룩... 쏟아지고, 메일 알림 소리가 띵 띵 띵 울리는 게 아무래도 JWT됐습니다. 일단 본인이 평소 해 왔던 선에서 문제를 해결해 보려고 합니다. 하지만 자기 혼자서 이 문제를 해결할 수 없다는 것이 분명해지는 시점이 찾아옵니다. 이 시점에서 뭔가 단단히 잘못되었다는 걸 인지하고 세상이 온통 하얗게 변합니다. 시간이 영원에 가까운 시간동안 멈춘 것 같게 느껴지지만 10초밖에 지나지 않습니다. 저는 이걸 급성 뇌정지라고 부릅니다. 급성 뇌정지 발작이 풀리고 생각을 할 수 있게 되어도 뇌가 정지된 건 똑같습니다. 그때 뇌를 가지고 할 수 있는 거라곤 욕설, 좌절, 자책, 원망, 후회 뿐입니다.

수전증

그렇게 헛되이 시간을 허비하는 사이 선배들이 문제를 파악하려고 달려들기 시작합니다. 선배들의 표정은 심각하고, 내 마음도 심각합니다. 시니어 분이 뭐를 어떻게 해서 어떻게어떻게 해 보라고 하는데 손이 떨려서 오타때문에 처리 속도도 느려지고, 심란합니다. 어찌어찌 다 같이 달려드니 장애는 복구되었습니다. 마음이 조금 진정되고 슬랙을 쳐다보니, 라이브 서비스가 1시간 다운되어 있었다는 사실과, 불만 CS가 넘쳐난다는 것을 알게 됩니다. 그리고 시니어 분이 장애 보고서를 써서 공유하라고 합니다. 자리에 터덜거리며 앉았는데 갑자기 눈물이 나네요.

자책하지 마세요

위 섹션에서는 전형적인 인생 첫 장애 상황을 묘사해 봤습니다. 힘든 하루였죠? 부디 자책은 하지 마셨으면 합니다.

제가 말하는 자책이라는 것은 자기만 탓하는 것을 말합니다. 이러한 규모의 장애는 혼자만의 잘못으로 절대 일어나지 않습니다. 모든 장애는 보통 부주의가 직접적인 원인이긴 하지만, 대부분의 부주의는 CI/CD와 리뷰 등의 절차를 통해 걸러집니다. 그렇다면 큰 규모의 장애를 일으킨 부주의는 곧 현재의 시스템으로 걸러지지 못한 부주의가 있다는 것을 의미하는 것입니다. 그러므로 해당 장애의 책임은 본인에게만 있지 않습니다. 팀 전체에 있지요. 선배들은 그저 노련하기 때문에(좋은 패턴을 안다, 자신이 사용하는 툴을 상당히 잘 알고 있다, etc.) 그런 부주의를 저지를 확률이 높지 않았을 뿐입니다. 악한 의도를 가지고 한 일이 아닌 이상 응당의 책임을 넘어서는 자책은 할 필요가 없을 뿐더러 모두에게 해롭습니다. 팀 모두가 책임 의식을 느끼는 편이 시스템 개선에 도움이 되기 때문입니다.

장애는 최대한 피하는 것이 가장 좋은 것이 사실입니다. 하지만 100% 피할 수 있는 것도 아닙니다. 천하의 구글도 몇 시간동안이나 유튜브를 못 보게 하잖아요? 장애를 안 나게 하는 역량도 엄청 중요하지만 장애가 났을 때 잘 대응하는 역량도 많이 중요합니다. 적어도 이번에 경험해 봤으니 장애 대응 역량을 끌어올리는 데 필요한 실제 경험이 생긴 거예요. 신입 개발자로서 겪어 봐야 하는 경험이라고 생각합니다(보통 겪지 말라고 해도 겪을 겁니다).

하지만 보완해야 하는 것

장애를 겪고 나서 진짜 해야 하는 것은 후회가 아니라 보완입니다. 그러니 장애 레포트를 잘 작성해서 팀원들과 공유하고, 회고하는 시간을 갖는 것이 중요합니다. 레포트를 작성할 때는 다음과 같은 사항들을 잘 돌이켜 보세요.

• 무슨 일이 있었나?
• 원인이 무엇인가?
• 장애를 복구하기 위해서 어떤 액션을 취했나? (내가 한 일 뿐만 아니라 팀 단위로)
• 이 장애를 사전에 어떻게 예방할 수 있었을까?
  • 팀의 업무 프로세스의 빈틈을 점검한다.
  • 내가 한 부주의는 어쩌다가 일어났는가?
  • 어떻게 이런 실수를 개인적으로, 시스템적으로 막을 수 있을까?
• 나/팀이 어떻게 하면 더 빠르고 효율적으로 장애에 대응할 수 있을까?
  • 시스템 보완이 필요한 점이 있는가?

결국 가장 중요한 것은 '다음 번에 안 그러는 것'입니다. 이것이 팀 책임으로 확장되어 '어떻게 하면 이런 일을 시스템적으로 막을 수 있을까?'에 대한 고민을 해야 하는 것입니다. 또한 실제 했던 장애 복구 과정과 최적의 복구 방법을 비교함으로써 장애 복구 프로세스를 효율화할 수 있습니다. 올바르게 풀어 나간다면 이 경험이 꼭 나쁘기만 한 경험은 아닐 거예요. 오늘은 술도 좀 먹고 쉬도록 합시다. 고생했어요.