1년 회고: 잘한 결정 하나, 후회 결정 하나
2026년 기준, 1년 전 결정 중 진짜 남은 것과 진짜 아쉬운 것 하나씩.
가장 잘한 것: 온콜 로테이션에 “백업 지명” 강제
1년 전 어느 새벽 2시, 주담당이 해외여행 중이라 슬랙 알림을 아무도 못 봤다. 그 사건 이후 룰을 하나 박았다.
- 온콜 시트에 Primary / Backup 두 칸 모두 채워야 배포 승인 가능
- Backup 이 비어 있으면 CI 파이프라인이 실제로 막힘 (슬랙 경고만으론 사람들이 안 고침을 알았기 때문)
- README 첫 줄:
oncall: @mings (backup: @jisoo)
처음엔 “형식적 절차 하나 더 생겼다”는 반응이었다. 막상 3개월 후 Primary 가 코로나로 쓰러졌을 때, Backup 이 아무 말 없이 받았다. 그게 전부였다. 이슈 없음, 공백 없음.
잘한 이유는 백업 지명 자체가 아니다. 자동화로 강제했기 때문이다. “지켜주세요” 는 두 번째 사건까지만 유효하다. 파이프라인이 막혀야 사람이 움직인다는 걸 그때 다시 배웠다.
비슷한 맥락으로, LLM API 붙일 때 첫날부터 cache_control + max_retries=3 을 기본값으로 박아둔 것도 잘한 결정이다. 초반엔 귀찮았는데, 두 달 후 업스트림 레이트리밋 사건 때 우리 서비스만 조용했다. 남들이 급하게 재시도 로직 붙이는 동안 우리는 대시보드만 봤다.
가장 후회한 것: 레거시 서비스 “나중에” 결정
1년 전, 5년 된 배치 서비스 하나를 어떻게 할지 논의했다. 트래픽 거의 없음. 담당자 퇴사 후 사실상 무주공산. 결론은 “당장 문제 없으니 Q3 때 다시 보자”였다.
Q3 가 됐고, 아무도 꺼내지 않았다. Q4 도 마찬가지였다.
올해 초, 그 서비스가 새벽에 조용히 죽었다. 의존하는 외부 API 가 deprecated 됐기 때문이다. 사용자 리포트로 알았다. 내부 알림 없음. 왜냐면 아무도 모니터링을 붙여두지 않았으니까.
수습하면서 코드를 열었더니 Python 3.7, 라이브러리 전부 EOL, 로컬에서도 안 뜸. 그냥 새로 짰다. 이틀.
“나중에” 가 문제가 아니다. 나중에를 캘린더에 안 박은 게 문제다. 그 회의에서 2026-Q3 레거시-batch 검토 라고 지라 티켓 하나만 만들었어도 달랐을 거다. 말로만 “Q3 때 보자” 는 기억에서 사라진다. 사건이 나기 전까지.
사후 보고서도 마찬가지다. 그 새벽 사건 이후 보고서를 쓰기로 했는데, 결국 사건 72시간 후에야 초안이 나왔다. 24시간 룰은 여전히 지켜지지 않는다. 매번 “수습 끝나고 기운이 없어서” 라고 합리화한다. 사실은 그냥 미루는 거다.
다음 한 가지
“나중에” 가 나오는 순간, 그 자리에서 티켓 하나 만들고 날짜 박는다 — 회의 끝나기 전에.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.