> ## Content Index
> Fetch the complete content index at: https://www.popit.kr/llms.txt
> Use this file to discover other available public pages before exploring further.

# 장애는 ‘우리의 문제’다
- URL: https://www.popit.kr/failure-is-our-problem/
- Published: 2022-10-18T01:20:47.000Z
- Updated: 2022-10-18T01:20:47.000Z
- Author: 유 영모
- Tags: #소프트웨어, 개발자, 버그, 장애, 오류, 운영

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

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

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

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

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

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

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

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

> **코드를 만드는 것은 전체 중 일부일 뿐** 필자가 이렇게 주장하는 것은 하나의 기능이 배포되기 위해서는 많은 과정이 필요한데 그 과정 중에 코드를 만드는 것은 일부분이기 때문입니다. - [/is-this-bug-your-fault/](https://www.popit.kr/is-this-bug-your-fault/)

![Untitled](https://www.popit.kr/content/images/wp/2022/10/Untitled-600x291.png)

# 시스템에 주목해야 한다

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

![출처:KBS 스펀지TV](https://www.popit.kr/content/images/wp/2022/10/Untitled-1-600x437.png)

출처:KBS 스펀지TV

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

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

문제의 근본 원인을 찾는 방법 중 실용적인 접근 방식은 도요타 [TPS(Toyota Production System)](https://en.wikipedia.org/wiki/Toyota%5FProduction%5FSystem?ref=popit.kr)를 설계한 오노 다이이치가 고안한 [Five Whys](https://en.wikipedia.org/wiki/Five%5Fwhys?ref=popit.kr)이다. 왜 문제가 발생했는지 다섯 번 묻는 것이다.

# 우리의 문제로 받아들일 때

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

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

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

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

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

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

# 마치며

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

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

# 주석

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