"왜?"를 다섯 번 묻는 습관 - 개발자의 진짜 실력을 가르는 5 Why 원인 분석법 (2026)

장애가 나면 눈앞의 증상만 급히 수습하기 쉽고, 그러면 비슷한 장애가 다시 찾아옵니다. 빨간불만 끄고 근본 원인을 끝까지 묻지 않기 때문입니다.

이 글에서는 5 Why로 원인을 파는 방법과 흔한 함정, 그리고 업무 요청 자체에 같은 질문을 적용하는 방식까지 정리합니다.

📋 목차

1. 증상만 잡으면 같은 문제가 또 온다
2. 5 Why란 무엇인가 - 도요타 공장에서 나온 사고법
3. '5'는 정확히 다섯 번이 아니다
4. 표면 원인 vs 근본 원인, 무엇이 다른가
5. 실전 예시 - 장애 하나를 다섯 번 파고들기
6. 5 Why의 함정 세 가지
7. 제대로 쓰기 위한 조건
8. 다른 원인 분석 기법과의 비교
9. 이론이 아니다 - 쿠팡과 배민이 일하는 방식
10. 코드를 넘어 '일' 자체에 적용하기
11. 헛개발이 줄면 내 일의 총량이 줄어든다
12. 진짜 어려운 건 기술이 아니라 커뮤니케이션
13. AI 시대에도 살아남는 스킬
14. 오늘부터 해볼 수 있는 작은 습관

1. 증상만 잡으면 같은 문제가 또 온다

열이 난다고 해열제만 먹으면 잠깐 떨어지지만, 폐렴이 원인이라면 다시 오릅니다. 코드도 똑같습니다. NullPointerException이 떴다고 그 자리에 null 체크만 끼워넣으면 그 줄은 조용해지지만, 정작 null이 어디서 흘러들어왔는지는 그대로 남습니다. 그러면 다른 줄에서 또 터집니다.

증상을 막는 건 빠르고 기분이 좋습니다. 당장 빨간불이 꺼지니까요. 문제는 그게 해결이 아니라 미룸이라는 점입니다. 미뤄둔 원인은 사라지지 않고, 보통 더 안 좋은 타이밍에 더 큰 모습으로 돌아옵니다.

 

 

📌 핵심

같은 장애가 반복된다면,

십중팔구 지난번에 원인이 아니라 증상을 고쳤기 때문입니다.

"다시는 안 터지게" 하려면 빨간불을 끄는 손이 아니라,

그 불이 왜 켜졌는지 캐는 질문이 필요합니다.

 

2. 5 Why란 무엇인가 - 도요타 공장에서 나온 사고법

5 Why는 어떤 문제가 생겼을 때 해결책으로 바로 달려가는 대신, "왜?"라는 질문을 거듭 던져 근본 원인을 추적하는 방법입니다. 이 기법은 도요타 그룹 창업자인 도요다 사키치가 고안한 것으로, 훗날 도요타 자동차의 생산 방식인 도요타 프로덕션 시스템(TPS)에 자리 잡았습니다. "왜를 다섯 번 반복하면 문제의 본모습과 해법이 드러난다"는 그의 생각에서 출발했다고 전해집니다.

도요타 생산방식을 설계한 오노 다이이치는 이 5 Why를 두고 "도요타식 과학적 접근의 토대"라고 표현했다고 알려져 있습니다. 거창해 보이지만 실제 방법은 황당할 정도로 단순합니다. 문제가 생기면 "왜?"라고 묻고, 그 답에 다시 "왜?"라고 묻기를 반복하는 게 전부입니다. 도구도, 자격증도 필요 없습니다. 필요한 건 멈추지 않는 호기심과 약간의 끈기뿐입니다.

3. '5'는 정확히 다섯 번이 아니다

이름 때문에 오해하기 쉬운데, '5'는 "딱 다섯 번 물어라"는 규칙이 아닙니다. "적어도 그 정도는 반복해야 진짜 원인에 닿더라"는 경험칙에 가깝습니다. 세 번 만에 명확한 원인이 나오면 거기서 멈춰도 되고, 일곱 번을 물어야 할 때도 있습니다.

판단 기준은 횟수가 아니라 "여기에 대책을 세우면 재발을 막을 수 있는가"입니다. 그 지점에 도달하면 더 물을 필요가 없고, 사실 더 물어도 의미 있는 답이 안 나옵니다. 숫자 5에 집착하다 보면 억지로 다섯 번째 답을 쥐어짜게 되는데, 이게 오히려 엉뚱한 결론으로 빠지는 흔한 함정입니다.

4. 표면 원인 vs 근본 원인, 무엇이 다른가

둘의 차이를 한 문장으로 정리하면 이렇습니다. 표면 원인은 "지금 눈에 보이는 것"이고, 근본 원인은 "그걸 만들어낸 것"입니다. 표면만 고치면 그 증상은 사라지지만 같은 뿌리에서 다른 증상이 또 자랍니다. 근본을 고치면 그 뿌리에서 나오던 여러 증상이 한꺼번에 정리되는 경우가 많습니다.

반응형

구분	표면 원인	근본 원인
관점	지금 터진 현상	그 현상을 만든 구조
대응	그 자리만 막음 (패치)	재발하지 않게 고침 (구조 개선)
효과	빠르지만 일시적	느리지만 지속적
다음 결과	같은 문제 재발 가능성 높음	연관된 문제까지 동시 해소

5. 실전 예시 - 장애 하나를 다섯 번 파고들기

가장 유명한 예시는 도요타 공장의 일화입니다. 바닥에 물이 고여 있다는 단순한 문제에서 출발해 "왜?"를 거듭하니, 결국 어떤 부품이 정기 점검 목록에서 빠져 있었다는 진짜 원인까지 내려갔다고 합니다. 우리 업계 상황으로 바꿔서 가상의 장애 하나를 따라가 보겠습니다.

 

 

문제: 새벽에 결제 API가 응답하지 않았다.
└ 왜? → 커넥션 풀이 꽉 차서 더 이상 DB 연결을 못 했다.
└ 왜? → 특정 쿼리가 응답을 받지 못한 채 연결을 붙잡고 있었다.
└ 왜? → 그 쿼리가 인덱스를 못 타서 풀스캔으로 수십 초씩 걸렸다.
└ 왜? → 최근 늘어난 데이터량에 맞는 인덱스가 추가되지 않았다.
└ 왜? → 배포 전 데이터 증가에 따른 쿼리 영향 점검 단계가 우리 프로세스에 아예 없었다.

 

 

여기서 표면만 봤다면 "API 서버 재시작"이나 "커넥션 풀 사이즈 늘리기"로 끝났을 겁니다. 그럼 다음 달에 데이터가 더 쌓이면 똑같이 터집니다. 근본까지 내려가면 진짜 대책이 보입니다. 바로 "배포 전 쿼리 영향 점검 절차를 만든다"입니다. 마지막 한 줄이 보이느냐 마느냐가 같은 장애를 평생 막느냐 매달 겪느냐를 가릅니다.

로컬에서 재현한 502와 5 Why

§5의 가상 결제 예시 다음에, 실제 로컬 리버스 프록시에서 502를 재현한 기록입니다(실측 2026-10-19 KST). 앞단·뒷단을 나누는 구성은 Nginx·Apache·Tomcat 차이의 리버스 프록시와도 같은 뼈대입니다.

Nginx 1.26.3이 127.0.0.1:19201에서 /api/를 127.0.0.1:19200으로 넘기도록 둔 뒤, 백엔드가 살아 있을 때:

HTTP/1.1 200 OK
Server: nginx/1.26.3
Content-Length: 3

백엔드 프로세스를 종료한 뒤 같은 GET /api/x:

HTTP/1.1 502 Bad Gateway
Server: nginx/1.26.3
Content-Type: text/html
Content-Length: 157

2026/10/19 23:59:01 [error] ... connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, request: "GET /api/x HTTP/1.1", upstream: "http://127.0.0.1:19200/x", host: "127.0.0.1:19201"

이 502에 5 Why를 대입하면

1. 왜 502인가? → upstream 연결이 거부되었다(로그의 Connection refused).
2. 왜 거부되었나? → 19200에서 받는 프로세스가 없었다.
3. 왜 없었나? → 백엔드를 중지한 상태였다.
4. 왜 앞단만 떠 있었나? → 프록시와 백엔드의 수명주기가 분리되어 있고, 이 랩에는 헬스체크·기동 순서가 없었다.
5. 재발을 줄이려면? → 기동 순서·health check·upstream 다운 시 안내 페이지 같은 구조를 넣는 쪽이, "사람 실수"로 끝내기보다 맞습니다.

6. 5 Why의 함정 세 가지

만능 도구는 아닙니다. 오래 쓰다 보니 이 기법이 자주 빠지는 함정이 보이더군요. 크게 세 가지입니다.

하나, 단일 경로의 함정입니다. "왜?"를 한 줄로만 따라가면 원인이 하나뿐인 것처럼 착각하게 됩니다. 실제 장애는 여러 원인이 겹쳐서 터지는 경우가 더 많습니다. 한 갈래만 파다 보면 다른 진짜 원인을 놓칩니다.

둘, 답 유도의 함정입니다. 사람은 자기가 이미 의심하던 결론 쪽으로 질문과 답을 무의식적으로 끌고 갑니다. "역시 그 모듈이 문제였어" 같은 선입견이 있으면 다섯 번을 물어도 결국 그 모듈로 도착합니다.

셋, 사람 탓의 함정입니다. "왜?"를 잘못 굴리면 "누가 실수했나"로 흘러가기 쉽습니다. "왜 그 사람이 빼먹었지" 같은 답이 나오면 거기서 멈추게 되는데, 진짜 물어야 할 건 "왜 빼먹어도 걸러지지 않는 구조였는가"입니다. 원인은 사람이 아니라 구조에서 찾아야 재발을 막습니다.

 

 

💡 팁

답이 사람 이름으로 끝나면 한 번 더 물어보세요.

"그 사람이 실수해도 시스템이 못 걸러낸 이유는?"으로 질문을 바꾸면,

비난 대신 개선할 구조가 보입니다.

 

브라우저 에러와 섞지 않기

콘솔의 CORS 빨간 줄은 서버 502와 원인이 다릅니다. 응답을 스크립트가 못 읽는 문제와 upstream이 죽은 문제를 같은 "왜?"로 묶으면 경로가 엇갈립니다. 경계가 필요하면 CORS 글을 옆에 두세요. 범위를 줄이는 습관은 MVP 정리와도 맞닿아 있습니다.

7. 제대로 쓰기 위한 조건

5 Why가 힘을 발휘하려면 몇 가지 전제가 필요합니다. 첫째는 문제를 정확하고 구체적으로 적는 것입니다. "느려요"가 아니라 "새벽 2시 결제 API 응답이 평소 200ms에서 30초로 늘었다"처럼요. 출발점이 흐리면 다섯 번을 물어도 흐린 결론에 도착합니다.

둘째는 답할 때 정직해야 한다는 점입니다. 체면 때문에 "외부 요인이었다"로 둘러대기 시작하면 추적은 거기서 끝납니다. 셋째는 끝까지 가려는 의지입니다. 적당히 그럴듯한 답이 나오면 멈추고 싶어지는데, 그 유혹을 한 번씩 더 이겨내야 진짜 뿌리가 나옵니다.

8. 다른 원인 분석 기법과의 비교

원인 분석 기법이 5 Why만 있는 건 아닙니다. 상황에 따라 어울리는 도구가 다릅니다. 간단히 정리하면 이렇습니다.

기법	핵심 방식	어울리는 상황
5 Why	왜를 반복해 한 갈래씩 깊이 파고듦	원인이 비교적 단순·명확한 문제
피쉬본 다이어그램	여러 원인 후보를 갈래로 펼쳐 정리	원인이 복잡하게 얽힌 문제
파레토 분석	빈도가 높은 원인부터 우선순위화	자잘한 문제가 잔뜩 쌓였을 때

거칠게 말하면, 원인이 한 줄로 깊은 문제엔 5 Why가, 원인이 옆으로 넓게 퍼진 문제엔 피쉬본이 잘 맞습니다. 둘을 섞어 써도 좋습니다. 피쉬본으로 후보 갈래를 펼친 다음, 의심되는 갈래마다 5 Why로 깊이 파는 식이죠.

9. 이론이 아니다 - 쿠팡과 배민이 일하는 방식

"근본 원인을 찾으라"는 말이 교과서 속 구호처럼 들릴 수 있는데, 한국 대표 IT 기업들의 실제 일하는 방식이기도 합니다. 쿠팡에는 채용·평가·승진의 기준이 되는 15가지 리더십 원칙(Leadership Principle)이 있습니다. 그중 'Think Systematically'와 'Dive Deep'이 바로 이 정신을 담고 있어요. 단순히 눈앞의 결함을 고치는 데 그치지 말고, 비슷한 문제가 다시 생기지 않도록 프로세스와 시스템 차원에서 해결하라는 겁니다. 일회성 땜질이 아니라 지속되는 개선을 만들라는 거죠.

배민(우아한형제들)의 사례는 더 생생합니다. 2016년 배민이 치킨을 7000원 할인해주는 선착순 이벤트를 열었는데, 평소의 수십에서 수백 배에 달하는 트래픽이 몰리면서 서비스가 그대로 뻗어버렸습니다. 급한 불은 껐습니다. 원래 한 달로 잡아두었던 IDC에서 AWS로의 이전을, 다음 날 이벤트를 또 해야 하니 하루 만에 끝내는 일이 벌어졌으니까요. 그런데 여기서 멈췄다면 그건 증상만 막은 셈이었습니다. 사실 트래픽 폭증 앞에서 서버만 늘리는 대응은, 어느 서비스에서든 보통 이런 식으로 흘러갑니다.

 

 

이벤트로 트래픽이 폭증한다.
└ 프론트 서버가 못 버틴다 → 프론트를 늘린다.
└ 그랬더니 이번엔 백엔드가 못 버틴다 → 백엔드를 늘린다.
└ 그랬더니 이번엔 그 뒤의 결제(PG) 쪽이 못 버틴다 → 또 그쪽을 늘린다…

 

 

이런 식으로 한 곳을 막으면 병목이 그 다음 단으로 옮겨갈 뿐입니다. 서버를 계속 들이붓는 건 빨간불을 차례차례 끄는 것이지, 불이 왜 자꾸 켜지는지를 푸는 게 아닙니다. 배민의 진짜 원인은 트래픽 급증을 견디지 못하는 레거시 구조 자체에 있었고, 그래서 당장의 대응만으로는 장애가 때때로 다시 일어났습니다. 결국 배민은 시스템을 잘게 쪼개 한 서비스의 문제가 다른 서비스로 번지지 않게 하는 MSA(마이크로서비스 아키텍처)로 옮겨가는 길을 택했습니다. "왜 자꾸 터지지?"의 끝에서 만난 답이 서버 증설이 아니라 구조 전환이었던 셈입니다.

 

 

💡 인사이트

병목을 막을 때마다 그 다음 단으로 문제가 옮겨간다면,

지금 잡고 있는 건 원인이 아니라 증상일 가능성이 큽니다.

"어디를 늘릴까"가 아니라

"왜 매번 한계에 부딪히는 구조일까"로

질문을 바꿔야 진짜 답이 보입니다.

 

10. 코드를 넘어 '일' 자체에 적용하기

여기서부터가 제가 진짜 하고 싶은 이야기입니다. 5 Why는 장애 분석용으로 알려졌지만, 똑같은 사고법을 "내 업무" 자체에 돌려보면 효과가 꽤 큽니다. 일이 하나 떨어졌을 때 바로 키보드에 손을 올리는 대신 이렇게 묻는 겁니다.

 

 

"이 기능을 만들어 달라."
└ 왜 이 기능이 필요하지? → 고객이 데이터를 엑셀로 내려받고 싶어 해서.
└ 왜 엑셀로 내려받고 싶어 하지? → 받은 데이터를 따로 가공해서 보고하려고.
└ 왜 따로 가공하지? → 우리가 주는 화면엔 그들이 원하는 합계가 없어서.
└ 그럼 진짜 필요한 건? → 엑셀 다운로드가 아니라, 화면에 그 합계를 보여주는 것일 수도.

 

 

이렇게 한 번만 파봐도 "엑셀 내보내기 기능"을 며칠 들여 만드는 대신, 화면에 합계 한 줄 추가하는 걸로 끝날 수도 있습니다. 요청받은 그대로 만드는 것과, 요청 뒤의 진짜 목적을 찾아 만드는 것은 결과물의 양과 질이 완전히 달라집니다.

11. 헛개발이 줄면 내 일의 총량이 줄어든다

이 습관의 가장 현실적인 이득은 여기 있습니다. 요청의 진짜 목적을 먼저 캐고 들어가면, 엉뚱한 방향으로 개발할 확률이 확 줄어듭니다. 잘못 만든 기능은 다시 만들어야 하고, 그동안 쌓인 코드도 걷어내야 하고, 회의도 다시 해야 합니다. 헛개발 한 번이 만드는 일은 생각보다 어마어마합니다.

반대로 처음부터 맞는 걸 만들면 그 모든 뒷수습이 통째로 사라집니다. 즉 "왜?"를 묻느라 처음에 30분을 더 쓰는 게, 며칠짜리 재작업을 막아주는 셈입니다. 결과적으로 내가 실제로 쳐야 하는 코드의 총량이 줄어듭니다. 부지런해 보이려고 일단 만들고 보는 사람보다, 한 번 더 묻고 정확히 만드는 사람이 야근을 덜 합니다. 게으른 사람일수록 5 Why를 좋아해야 한다는 게 제 지론입니다.

 

 

📌 핵심

"왜?"를 묻는 데 드는 30분은 비용이 아니라 투자입니다.

헛개발 한 건을 막으면 며칠이 통째로 돌아옵니다.

일을 줄이는 가장 빠른 길은 더 빨리 만드는 게 아니라,

안 만들어도 될 걸 가려내는 것입니다.

 

12. 진짜 어려운 건 기술이 아니라 커뮤니케이션

그런데 여기에 함정이 하나 있습니다. 코드의 원인은 로그를 뒤지면 혼자서도 추적할 수 있지만, "일"의 원인을 추적하려면 반드시 사람을 거쳐야 한다는 점입니다. "이 기능이 왜 필요한지"의 답은 코드 안이 아니라 기획자, 디자이너, 영업, 고객의 머릿속에 있습니다.

그래서 5 Why를 업무에 적용하는 사람은 필연적으로 질문을 많이 하게 됩니다. "이거 왜 필요해요?"를 잘못 던지면 따지는 사람처럼 보이고, 잘 던지면 일을 줄여주는 사람으로 보입니다. 같은 질문도 표정과 맥락, 타이밍에 따라 전혀 다르게 받아들여집니다. 결국 근본 원인을 캐는 능력은 추적 능력이 절반, 사람들에게서 솔직한 답을 끌어내는 커뮤니케이션 능력이 절반입니다. 개인적으로는 후자가 훨씬 어렵다고 느낍니다.

13. AI 시대에도 살아남는 스킬

요즘은 코드 짜는 일의 상당 부분을 AI가 도와줍니다. 그래서 "이제 개발자는 뭘 해야 하나" 하는 불안이 큽니다. 그런데 한 발 떨어져서 보면, AI가 대신 못 해주는 영역이 점점 또렷해집니다. 바로 사람에게 "진짜 원하는 게 뭔지" 캐묻고, 흩어진 요구를 정리하고, 합의를 끌어내는 일입니다.

AI에게 "엑셀 다운로드 기능 만들어줘"라고 하면 정말 잘 만들어줍니다. 하지만 "그 고객이 실은 합계만 보고 싶었던 거 아닐까?"를 의심하고 사람에게 확인하는 건, 적어도 지금은 사람의 몫입니다. 흥미로운 건, AI 시대에 더 중요해진다는 이 역량이 결국 5 Why를 업무에 쓸 때 필요한 커뮤니케이션 능력과 같다는 점입니다.

그래서 개인적인 권유는 이렇습니다. 지금 시점에는 사람을 많이 만나고, 많이 묻고, 많이 부딪혀 보는 게 유리합니다. 혼자 코드만 파던 시절보다, 사람 사이에서 진짜 의도를 끌어내는 연습을 해둔 사람이 앞으로 더 오래 쓸모 있을 가능성이 큽니다. 물론 미래가 정확히 어떻게 흘러갈지는 누구도 단언 못 하지만, 적어도 손해 볼 투자는 아니라고 봅니다.

14. 오늘부터 해볼 수 있는 작은 습관

거창하게 시작할 필요는 없습니다. 다음 장애를 만났을 때, 고친 다음에 한 번만 더 물어보세요. "그래서 이게 애초에 왜 생겼지?"라고요. 그리고 다음에 일을 받았을 때, 키보드에 손 올리기 전에 딱 한 번만 물어보세요. "이걸 왜 하는 거지?"라고요.

처음엔 어색하고, 가끔은 답을 듣고 김이 빠질 수도 있습니다. 그래도 이 질문 하나가 쌓이면, 어느 순간 헛수고가 눈에 띄게 줄어든 자신을 발견하게 될 겁니다. 한 번에 되는 건 없었습니다. 저도 같은 장애를 몇 번이나 다시 겪고 나서야 이 습관이 몸에 붙었으니까요.

마무리

5 Why는 도구라기보다 태도에 가깝습니다. 눈앞의 빨간불을 끄고 만족하느냐, 그 불이 켜진 이유까지 내려가느냐. 이 작은 차이가 같은 장애를 평생 막느냐 매달 겪느냐를 가르고, 헛개발로 야근하느냐 정확히 만들고 퇴근하느냐를 가릅니다.

그리고 그 "왜?"를 끝까지 따라가다 보면 결국 코드가 아니라 사람에게 닿습니다. 진짜 원인은 거의 언제나 사람들의 의도 속에 숨어 있으니까요. 그래서 저는 잘 묻는 개발자가 잘 짜는 개발자보다 오래 간다고 믿습니다. 적어도 제가 지나온 13년은 그랬습니다.

AI 덕분에 무언가를 만드는 시간 자체는 확실히 줄었습니다. 예전 같으면 며칠 걸리던 작업이 몇 시간 만에 끝나기도 하니까요. 편해진 건 분명합니다. 그런데 이상하게 일은 줄지 않습니다. 오히려 늘 수밖에 없는 구조예요. 도구가 빨라진 만큼 주변의 기대치도 같이 올라가니까요. 그 속에서 사람을 가르는 건 결국 집요함이라고 봅니다. 똑같이 AI를 손에 쥐여줘도, 한 번 더 "왜?"를 묻고 끝까지 파고드는 사람과 나온 결과를 그냥 받아 쓰는 사람의 격차는 시간이 갈수록 벌어집니다. 사실 이 집요함은 옛날에도 필요했던 자질입니다. 다만 만드는 시간이 확 줄어든 지금은 그 아낀 시간을 어디에 쓰느냐가 더 도드라지면서, 이 습관이 한층 빛을 발하게 됐을 뿐이죠.

그래서 앞으로 누군가의 실력을 가늠할 때, 저는 손이 얼마나 빠른지보다 이걸 봅니다. 얼마나 집요하게 생각하고, 집요하게 만들고, 집요하게 표현할 수 있는가. 결국 차이는 거기서 납니다.

📚 함께 보면 좋은 글

MVP 최소 기능 제품 뜻, 적게 만들라는 말이 아니었습니다

CORS는 왜 항상 프론트 개발자만 잡을까 - 동일 출처 정책의 역사와 현장 이야기

CSRF란? 개념부터 방어까지 쉽게 정리

스펙 주도 개발 SDD가 API 개발 생산성을 비약적으로 높이는 이유

웹 API 서버 디도스 방어에 스로틀링 기술이 필수인 숨은 이유가 있습니다