내가 주니어 시절에 있었던 일이다. 입사 한지 얼마 되지 않았던 상황에서 코드를 수정해야 할 일이 생겼고 수정한 코드를 운영에 배포했다. 그리고 일주일이 지난 후, 특정 옵션 상품이 장바구니에 담기지 않는다고 연락이 왔다. 배포 당시에 문제를 발견하지 못하고 일주일 간 장애가 발생한 것이었다.

다른 팀 기획자에게 전화가 왔으며, 추궁이 이어졌다. 황급히 문제를 파악하고 긴급 배포를 한 후 나에게 남은 일은 장애 보고서를 쓰는 일이었다. 기분이 착잡했다. 그것도 그럴 것이 장애를 오롯이 코드를 만든 개발자인 내 문제로 모두가 인식하고 있었기 때문이다.

최근 두 개 파트너사들과 함께 일하고 있다. 파트너사들도 장애를 겪는다. 개발자 뿐만 아니라 인프라 담당자의 단순 실수로 장애가 발생한 경우도 있다. 하지만 이 모두가 실수한 사람 개인의 문제일까?

장애는 크든 작든 모두가 기여하는 문제이다

비난 본능은 왜 안 좋은 일이 일어났는지 명확하고 단순한 이유를 찾으려는 본능이다.
(중략)
비난 대상에 집착하느라 정말 주목해야 할 곳에 주목하지 못한다.- 책 <팩트풀니스>

장애가 발생하면 비난 대상을 찾느라 정말 주목해야 할 곳에 주목하지 못한다. 바로 코드를 만든 개발자 혹은 실수 당사자 말이다.

내 생각에 장애는 크든 작든 모두가 기여하는 문제라고 생각한다. 도메인을 잘 모르던 내가 코딩을 할 때 도메인을 잘 알고 있던 시니어 개발자는 무엇을 했나? 기획자는 운영에 배포한 내용을 왜 확인 못했나? QA는 무엇을 했나? 팀장은 무엇을 했나? 더 나아가 상무는 무엇을 했나? CTO는?

혹자는 개인의 책임을 과대 포장하는 것 같다고 말할 수 있겠다. 하지만 김형준 님이 '이 버그는 개발한 너의 잘못이야?’ 글에서 언급한 것과 같이 코드를 만드는 것은 전체 중 아주 일부일 뿐이다. 소프트웨어를 만드는 일은 유기적이기 때문에 전체를 구성하고 있는 각 부분이 서로 밀접하게 관련을 가지고 있어서 떼어 낼 수 없는 것이다. 그렇기에 실수 당사자는 모든 것이 내 책임인 양 굴 것이 아니라 좀 더 당당해질 필요가 있다.

코드를 만드는 것은 전체 중 일부일 뿐 필자가 이렇게 주장하는 것은 하나의 기능이 배포되기 위해서는 많은 과정이 필요한데 그 과정 중에 코드를 만드는 것은 일부분이기 때문입니다. - https://www.popit.kr/이-버그는-개발한-너의-잘못이야/

시스템에 주목해야 한다

<KBS 스펀지>에서 방영했던 서울 지하철 공사 얘기를 보자. 서울 지하철 공사는 한 해에 껌을 80만 개를 샀다고 한다. 왜일까? 바로 기관사의 졸음운전 때문이다. 졸음운전으로 지하철 정거장을 안 서고 지나친 경우가 있었다고 한다. 그래서 해결책으로 껌을 사서 지급하기 시작했다는 것이다. 졸음운전을 한 기관사의 죄를 추궁했다면 문제는 해결되지 않고 반복되었을 것이다.

출처:KBS 스펀지TV

중요한 문제를 이해하려면 개인에게 죄를 추궁하기보다 시스템에 주목해야 할 때가 많다. - <팩트풀니스>

실수 당사자를 추궁해야 보아야 문제가 해결되지 않는다. 왜냐하면 문제가 반복되기 때문이다. 이것이 바로 시스템에 주목해야 하는 이유다. 시스템이란 하나의 복잡한 덩어리를 구성하는 상호적이거나 독립적인 구성 요소의 집합이다. 관계도 일종의 시스템이고 팀도 일종의 시스템이며, 조직도 일종의 시스템이다.[1]

문제의 근본 원인을 찾는 방법 중 실용적인 접근 방식은 도요타 TPS(Toyota Production System)를 설계한 오노 다이이치가 고안한 Five Whys이다. 왜 문제가 발생했는지 다섯 번 묻는 것이다.

우리의 문제로 받아들일 때

내가 개발자로 일을 시작했을 당시 보다 지금은 기술 스택이 복잡해졌고 직군이 세분화되었다. 그렇다 보니 통합에 대한 비용 또한 매우 커졌다. 단순하고 해결이 쉬운 문제는 지엽적으로 발생하지만 복잡하고 해결이 어려운 문제는 복합적으로 발생한다. 그래서 문제가 발생하면 내가 맡은 부분만 확인하고 나는 아니라는 식의 대응은 문제 해결을 어렵게 만든다.

문제를 이분법으로 단순하게 ‘내 것’과 ‘아닌 것’로 볼 것이 아니라 ‘우리의 문제’로 받아들여야 한다. 앞서 언급한 것과 같이 크든 작든 모두가 기여하는 것이기 때문이다. 우리의 문제이기에 함께 해결해야 한다. 우리의 문제로 받아들일 때 ‘안전한 공동체’를 만들 수 있다.

문제가 발생했을 때 개인에게 죄의식을 심어주면 그다음 부터 당사자는 어떻게 행동할까? 개발자라면 이렇게 생각할 수도 있다.

앞으로 문제가 없는 코드는 절대 고치지 말아야지.

사람은 실수와 실패를 통해 성장한다. 그러기에 안전한 공동체는 성장의 밑바탕이다. 같은 장애를 겪지만 누군가는 상처받고 누군가는 성장한다.

앞서 풍부한 피드백을 얻기 위해서는 사용 중인(혹은 운영중인) 시스템에 시도해야 한다고 언급했다. 하지만 경력과 무관하게 시도하는게 두려울 수 있다. 잘 못해서 실수하기라도 하면 그로 인한 여파를 무서워하는 것이다.
두려움에 용기를 내지 못하는 이들에게 ‘안전한 공동체’가 되어 줄 수 있다. 실수/실패하더라도 괜찮다는 믿음을 줄 수 있는 동료가 있다는 건 용기를 낼 수 있는 큰 힘이다. 부모는 아이가 태어나 성장할 때까지 안전한 공동체가 되어준다. 안전한 공동체 안에서 아이는 부모를 믿고 끊임 없이 실수하고 실패하며 그 속에서 배우고 성장한다. - https://www.popit.kr/개발자를-코칭하며-배운-7-가지/

마치며

코드를 만드는 개발자 위주로 썼지만 DevOps 담당자 건 DBA 건 다 똑같다. 문제없는 시스템은 없는 것이다. 상황을 어떻게 받아들이냐에 따라 축복이 되기도 하고 저주가 되기도 하는 것이다.

생각해보니 나의 역경은 정말 축복이었다. 가난했기에 <성냥팔이 소녀>를 쓸 수 있었고, 못생겼다고 놀림을 받았기에 <미운 오리 새끼>를 쓸 수 있었다. - 한스 안데르센

주석

[1] 책 <일의 99%는 피드백이다> 일부 발췌