개발자를 대하는 태도 - 버그

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

 

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

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

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

 

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

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

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

이러한 방식의 질문은

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

 

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

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

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

 

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

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

무엇이 문제였는지보다

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

 

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

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

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

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

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

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

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

이 질문들은

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

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

 

해당 구조에서는

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

 

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

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

이 한 문장의 차이가

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

을 전부 바꿉니다.

 

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

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

 

맺는말

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

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

 

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

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

버그는 피할 수 없습니다.

 

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

 

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

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

 

다음 편에서는

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

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

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