누구를 탓할지보다 중요한 건 세 가지다.
감정을 덜고, 재발을 막고, 회복을 보장하는 것.

긴급 대응은 헌신이나 책임감의 문제가 아닙니다.

지속 가능성의 문제입니다.

새벽 호출, 주말 호출 그 자체보다

개발자를 더 소진시키는 것은

긴급 상황 이전과 이후의 태도와 구조입니다.

그리고 긴급 대응에 감정 압박이 더해지는 순간,

그 사람은 다음 호출을 버텨내기 점점 힘들어집니다.

긴급 대응은

헌신이나 책임감의 문제가 아닙니다.

그 상황을 다음에도 다시 감당할 수 있는가의 문제입니다.

존중

긴급 대응에서 가장 먼저 지켜야할 것은

'얼마나 빨리 고치느냐'가 아니라

누가, 어떤 상태로 그 자리에 서 있었는가 입니다.

국경을 지키고 있는 군인,

치안을 지키고 있는 경찰,

안전을 지키고 있는 소방수처럼

긴급 대응 이전에

누가, 어떤 상태로 그 자리에 서 있었는지에 따라

긴급 상황이 발생했을 때,

대응이 크게 갈릴 것입니다.

그리고 긴급 상황에서

휘말리는 감정적인 여파를 어떻게 다루느냐에 따라

다음 긴급 상황에 있어

소명감을 가지고 임하는 개발자가 될지

상황을 회피하고 싶은 개발자가 될지가

판가름나게 됩니다.

존중에 대한 프로세스

단지 긴급 대응을

사람의 책임감으로 버티기 시작하는 순간,

이미 그 조직은 위험합니다.

긴급 대응은 영웅을 만드는 시간이 아닙니다.

한 사람이 반복해서 그 자리에 서게 되는 구조는
단기적으로는 안정처럼 보이지만,

시간이 지날수록
조직이 대응 방식을 점검할 기회를 잃게 만듭니다.

존중은 태도의 문제라고 생각하기 쉽습니다.

하지만 운영에서는 결국 프로세스의 문제로 귀결됩니다.

아무리 존중하는 말을 건네더라도

그 다음 호출이 똑같은 방식으로 반복된다면,

그 존중은 오래 가지 못합니다.

그래서 긴급 대응에서의 존중은

말이 아니라 프로세스로 확인되어야 합니다.

그래서 긴급 대응 이후에

조직이 해야 할 프로세스는 명확합니다.

• 누군가를 탓하지 않는 것
• 감정을 덜어내는 것
• 다음 상황을 대비하는 것

이 세가지가 없으면

긴급 대응 반복될수록 개발자를 갉아먹게 됩니다.

그렇게 다음 상황을 대비할 때에는

• On-Call이 특정 인원에게 고착되지는 않았는지
• 대체 휴무나 회복 시간이 보장되었는지
• 같은 상황이 다시 발생할 여지가 있는지

를 반드시 확인해야 합니다.

당연하게도 확인한 것들을 바로 적용할 수는 없을 것입니다.

다만 확인하는 것 만으로도

고칠 수 없는 상태가

고칠 수 있는 상태로 바뀌게 됩니다.

구성원들이 고칠 수 있는 방향성을 생각하게 됩니다.

맺는말

긴급 대응을 견디는 조직은 많지만,

긴급 대응을 지속 가능하게 다루는 조직은 많지 않습니다.

중요한 것은 다음 호출이 올 때 같은 사람이 같은 방식으로 다시 서게 만드는 것이 아니라,

그 상황을 조직 전체가 어떻게 감당할 수 있을지에 대한 기준을 남기는 일입니다.

이전글

"누구의 잘못인가?"
or
"어떻게 수습할 것인가?"

• 실력 부족으로 생기는 버그
• 실력이 있어도 생기는 버그

실무에서는 둘을 구분하지 않습니다.

왜냐하면 결과는 동일하게 장애로 연결되기 때문입니다.

버그를 책임 소재로 보는 조직

이러한 접근은 다음의 질문으로 시작합니다.

• "왜 이런 버그가 나왔죠?"
• "누가 이 코드 짰어요?"
• "테스트 안해보셨어요?"

이러한 방식의 질문은

문제해결보다는 책임 규명이 먼저일 때 튀어나옵니다.

그리고 이러한 질문이 반복되면

개발자는 문제 해결 모드가 아니라

상황 설명을 최소화하는 모드로 전환됩니다.

이 전환은 감정의 문제가 아니라,

정보가 흐르는 방식을 바꿉니다.

무엇이 문제였는지보다

어디까지 말해도 되는지가 먼저 계산되기 시작합니다.

개발자 개인의 책임으로 돌리는 것은

단기적으로 감정이 해소될지 몰라도

구조적 안정성을 확보할 수는 없습니다.

버그를 시스템 이벤트로 보는 조직

버그를 시스템 이벤트로 보는 접근법은

다음의 질문으로 이어집니다.

• "사용자 영향 범위는 어떻게 돼요?"
• "롤백이 빠를까요, 핫픽스가 빠를까요?"
• "재발 조건에는 뭐가 더 있을까요?"

이 질문들은

수습 > 원인 > 구조 개선 순서를 만듭니다.

그리고 이 순서가 유지되는 조직에서는
버그 하나가 조직의 판단 기준을 갱신하는 계기로 작동합니다.

해당 구조에서는

"다음엔 더 빨리 잡자"라는 학습이 일어납니다.

"이거 왜 이렇게 했어요?"

"지금 빠르게 수습하려면 어떻게 해야하죠?"

이 한 문장의 차이가

• 팀 신뢰
• 장애 대응 속도
• 개발자의 성장 방향

을 전부 바꿉니다.

운영에서 가장 중요한 관점은

조직이 무엇을 학습하느냐 입니다.

맺는말

이 글은 개발자를 위로하기 위한 글이 아닙니다.

조직이 손해를 보지 않게 하기 위해 작성한 글입니다.

버그를 잘못 다루는 조직은 결국

• 개발자를 잃고
• 품질을 잃고
• 고객을 잃습니다.

버그는 피할 수 없습니다.

다만 그 버그가
한 번의 사고로 끝나는지,
아니면 조직의 판단을 갱신하는 계기가 되는지는
전적으로 조직이 버그를 다루는 방식에 달려 있습니다.

버그를 사람의 문제로 처리하는 조직은
같은 문제를 다른 형태로 반복하게 되고,

버그를 흐름의 문제로 다루는 조직은
점점 같은 문제를 더 빨리, 더 작게 만납니다.

다음 편에서는

개발자를 대하는 태도 - 긴급 대응편에서

더 극단적인 상황을 다뤄볼 수 있도록 하겠습니다.