
누구를 탓할지보다 중요한 건 세 가지다.
감정을 덜고, 재발을 막고, 회복을 보장하는 것.
긴급 대응은 헌신이나 책임감의 문제가 아닙니다.
지속 가능성의 문제입니다.
새벽 호출, 주말 호출 그 자체보다
개발자를 더 소진시키는 것은
긴급 상황 이전과 이후의 태도와 구조입니다.
그리고 긴급 대응에 감정 압박이 더해지는 순간,
그 사람은 다음 호출을 버텨내기 점점 힘들어집니다.
긴급 대응은
헌신이나 책임감의 문제가 아닙니다.
그 상황을 다음에도 다시 감당할 수 있는가의 문제입니다.
존중
긴급 대응에서 가장 먼저 지켜야할 것은
'얼마나 빨리 고치느냐'가 아니라
누가, 어떤 상태로 그 자리에 서 있었는가 입니다.
국경을 지키고 있는 군인,
치안을 지키고 있는 경찰,
안전을 지키고 있는 소방수처럼
긴급 대응 이전에
누가, 어떤 상태로 그 자리에 서 있었는지에 따라
긴급 상황이 발생했을 때,
대응이 크게 갈릴 것입니다.
그리고 긴급 상황에서
휘말리는 감정적인 여파를 어떻게 다루느냐에 따라
다음 긴급 상황에 있어
소명감을 가지고 임하는 개발자가 될지
상황을 회피하고 싶은 개발자가 될지가
판가름나게 됩니다.
존중에 대한 프로세스
단지 긴급 대응을
사람의 책임감으로 버티기 시작하는 순간,
이미 그 조직은 위험합니다.
긴급 대응은 영웅을 만드는 시간이 아닙니다.
한 사람이 반복해서 그 자리에 서게 되는 구조는
단기적으로는 안정처럼 보이지만,
시간이 지날수록
조직이 대응 방식을 점검할 기회를 잃게 만듭니다.
존중은 태도의 문제라고 생각하기 쉽습니다.
하지만 운영에서는 결국 프로세스의 문제로 귀결됩니다.
아무리 존중하는 말을 건네더라도
그 다음 호출이 똑같은 방식으로 반복된다면,
그 존중은 오래 가지 못합니다.
그래서 긴급 대응에서의 존중은
말이 아니라 프로세스로 확인되어야 합니다.
그래서 긴급 대응 이후에
조직이 해야 할 프로세스는 명확합니다.
- 누군가를 탓하지 않는 것
- 감정을 덜어내는 것
- 다음 상황을 대비하는 것
이 세가지가 없으면
긴급 대응 반복될수록 개발자를 갉아먹게 됩니다.
그렇게 다음 상황을 대비할 때에는
- On-Call이 특정 인원에게 고착되지는 않았는지
- 대체 휴무나 회복 시간이 보장되었는지
- 같은 상황이 다시 발생할 여지가 있는지
를 반드시 확인해야 합니다.
당연하게도 확인한 것들을 바로 적용할 수는 없을 것입니다.
다만 확인하는 것 만으로도
고칠 수 없는 상태가
고칠 수 있는 상태로 바뀌게 됩니다.
구성원들이 고칠 수 있는 방향성을 생각하게 됩니다.
맺는말
긴급 대응을 견디는 조직은 많지만,
긴급 대응을 지속 가능하게 다루는 조직은 많지 않습니다.
중요한 것은 다음 호출이 올 때 같은 사람이 같은 방식으로 다시 서게 만드는 것이 아니라,
그 상황을 조직 전체가 어떻게 감당할 수 있을지에 대한 기준을 남기는 일입니다.
이전글
개발자를 대하는 태도 - 버그
"누구의 잘못인가?"or"어떻게 수습할 것인가?" 실력 부족으로 생기는 버그실력이 있어도 생기는 버그실무에서는 둘을 구분하지 않습니다.왜냐하면 결과는 동일하게 장애로 연결되기 때문입니다.
chessire.tistory.com
'Notes > 개발 운영 노트' 카테고리의 다른 글
| 개발자를 대하는 태도 - 버그 (0) | 2026.01.06 |
|---|---|
| 개발자를 믿는 조직과 프로세스를 믿는 조직의 차이 (0) | 2025.12.26 |
| 무분별한 프로젝트 수주가 개발 프로세스를 어떻게 망가뜨리는가 (0) | 2025.12.17 |