가을이었다…

시작은 슬랙의 모니터링 메세지로부터…

때는 22년 10월 27일 저녁 6시, 퇴근 후 한잔 할 생각에 신나있었다. 룰루 랄라 퇴근 준비를 하며 슬랙을 돌아보다, 배치 모니터링 채널에 쌓인 오류 알림들을 확인했다. 시작은 오후 4시부터였으며, 배치 작업은 내가 확인한 6시까지 단한번의 성공 없이 모두 실패했다. 가장 최근에 배치관련 코드 수정을 했던 나의 등에 식은땀이 흘렀다.

슬랙의 에러메세지는 502 코드 외에 도움이 되는 정보는 없었다. 배치 서버는 상품 검색과 관련해 주요한 기능을 담당하기에, 바로 CTO님을 호출했다. 몇 분 뒤, CTO님께서 배치 서버가 도는 instance의 ip가 외부 서비스로부터 차단 당해 문제가 발생한 것 같다는 진단을 내려 주셨다. 해당 외부 서비스를 우리 api 서비스로 우회하여 접근하면 빠르게 문제 해결 할 수 있을 것 같다는 조언도 함께 주셨다.

잔뜩 긴장했던 몸을 조금 추스르고, 알려주신 방법을 시도해 보았다. 문제가 된 부분들을 걷어내는게 귀찮은 반복 작업이긴 했지만, 일단 문제해결이 우선이라고 생각하며 묵묵히 수정했다. 그렇게 안심하고 production에 올리기 직전, 나는 확인 해버렸다. 에러가 사라지지 않는 현상을, 우리 api 서비스도 timeout이 나는 상황을.

“OO님! 썸네일이 안나와요!”

다급한 목소리에 떨리는 눈빛으로 우리 서비스에 접속했다. PC환경에서 상품의 정보는 나오지 않았고, 구매 화면이 나타나지 않았다. CTO 님께서 확인 결과, 불행 중 다행으로 모바일 결제는 가능했다. 하지만 상품 정보들은 볼 수 없어, 정상적으로 사용하기 어려운 건 마찬가지였다. CTO님과 협력해 7시 30분 경 api 서버가 떠있는 instance 중 2개가 차단당했다는 사실을 확인했다. CTO님은 외부 서비스 담당자에게 메일을 보냈고, 나는 GCP에 Cloud Function을 이용해 우회하는 방법을 시도해보기로 했다.

여기서 나의 얕은 지식이 발목을 잡았다. 막상 axios 없이 client를 짜본 경험이 없어, 순수 node로 외부 함수 호출을 어떻게 할지 몰랐다. 거기에 더해 Cloud Function도 잘 사용하지 못했다. CTO님께서 내 상황이 여의치 않음을 확인하시고, AWS lambda를 이용해 바로 코드를 배포하셨다. 나에게는 이것을 외부 api로 배포하는 미션을 주셨다. 하지만 여기서도 나란 놈은, 답을 몰랐다. 검색으로 시작해 AWS gateway를 알았고, 배포할 때 어떻게 할지 고민하기 시작했다.

10분 뒤, 아무것도 진척되지 않은 상황에 CTO님은 직접 API Gateway를 붙이겠다고 하셨다. 나는 api 서버 코드에 하드코딩 되어있는 url을 대체하는 역할을 맡아, 수행했다. 그렇게 몇몇 api들이 대체되기 시작했지만, 문제의 해결은 쉽지 않았다. query parameter가 encode 되지 않는 이슈, 기존과 다르게 http가 아닌 https로 호출해야 정상 응답했던 부분, 중간에 외부서비스가 잠깐동안 ip 차단을 해제시켜줘 정상 동작하는 줄 착각했던 상황 등이 발생해 결국 9시 50분쯤이 되서야 문제가 일단락 되었다. 정신 없고 배고팠던 4시간이 그렇게 마무리 되었다.

회고

느낌

착잡했다. 밤에도 쉽게 자지 못했다. 샤워를 하고 나왔음에도 왠지모를 찝찝함이 남아있었다. 오늘이 되서야 감정이 진정되었다. 왜 내가 그런 감정이 들었는지 고민해 봤다. 결과적으로 도움이 되고 싶기 때문이라고 생각했다. 인정받고 싶은 욕구도 있고, 내 가치를 증명하고 싶다는 욕구도 있고, 순수하게 돕고 싶다는 욕구도 있다. 아쉽지만, 받아드려서, 나아지는 수밖에 없다. 어제 느낀 씁쓸함을 만끽할 수 있어 다행이라 생각하자.

개선점

개선점 1 : 흥미 위주 우선순위 변동 대비

내가 생각하는 수치지점 1번은 GCP에 Cloud Function을 바로 띄우지 못한 부분이다. 자신있게 우회하는 방법으로 제안했는데, 정작 빠르게 구현해 문제를 해결하지 못했다. 순간적으로 나의 사고 회로가 문제 해결이 아닌, 구현 방법에 대한 궁금증으로 바뀌었던 것 같다. 우선순위를 맥락과 상관 없이 흥미가 동한 쪽으로 바꾸는 것은, 주의가 쉽게 산만해 질 수 있는 기질을 가진 나에게 발생할 수 있는 일이다. 발생을 막을 수 없다고 인정하고, 일단 지킨다는 마인드로 발생 전/후 전략을 세워보았다.

  • 발생 전
    1. GCP 혹은 AWS 학습하기
      • 자격증도 하고, 직접도 써보기
      • 나만의 예제를 많이 만들어 두기
    2. 왜 하는지 스스로 질문하기
      • 평소부터 해버릇 해야 급할 때도 함
    3. 상황인지 연습하기
      • 문제가 발생했을때, 주변 상황을 섣부르게 “판단"하면 위험
      • 사전 조건들을 사실그대로 기록하는 연습을 통해, 멘붕 대비
  • 발생 후
    1. 회고 꼭 하기
      • 이것도 이 전략의 하나.
    2. 꼭 기록해, 공개하기
      • 실수를 감추면 더 곪는다.

개선점 2 : 작업 목록 및 기대 결과 기록하기

내가 생각하는 수치지점 2번은 url 변환 과정을 여러번 반복한 부분이다. 조건을 기준없이 바꾸며 시도한 결과, 문제를 오히려 만들어 풀었다는 느낌이 든다. 이 습관은 이전부터 인지하고 있는 문제로, 일상 생활에서는 아침에 작업 목록을 작성해서 개선했었다. 이번 회고를 통해, 내가 어떤 문제를 맞닥드렸을때 이전 습관이 튀어나온다는 것을 인지했다.

앞으로는 아침에 작업 목록 작성 뿐만 아니라, 단위 작업 시작전에 할 일을 정리해야겠다. 이와 더불어 기대 결과를 기록해서, 정확히 해결된 상황을 검증하는 연습을 해야 겠다.

개선점 3 : 이슈 공유 하기

오늘 점심시간에 잠깐 동료분들과 논의하면서, 문제 상황이 공유되지 않았다는 것을 알게 되었다. 당시 함께 근무했던 회사 동료분들이 개발팀에서 들려오는 한숨소리에 신경쓰이지 않았을까, 죄송한 마음이 들었다.

앞으로는 상황 공유가 필요하다고 판단 시, 사후에라도 문제 상황을 공유해야겠다.

마무리 요약

문제

  • 외부서비스 터져서 우리 서비스 영향받음
  • 최초 할당된 작업들을 적시에 수행하지 못했음

느낌

  • 씁쓸, 착잡
  • 더 도움이 되었으면 좋겠다는 욕구 / 인정 욕구 / 증명 욕구
  • 오히려 좋아

개선점 정리

평소에 시도할 점

  1. GCP 혹은 AWS 학습하기
  2. 작업 전에
    1. 왜하는지 스스로 질문하기
    2. 일과 시작 뿐만아니라, 단위 작업 전에도 할일 목록 쓰기
      • 상황을 객관적으로 인지하고, 구조화 해보기.
      • 해결을 확인할 수 있게 최소 목표와 완성 목표를 분리해서 써보기
  3. 작업 후에
    1. 이슈 공유
      • 상급자에게 요청하기
    2. 회고 하기
      • 블로그 쓰기