오늘의 퀴즈) 점진적 면접 역량 강화 과정 보기(5Why) + 오늘을 마치며

Q1. 5Why는 단순히 “왜?”를 많이 묻는 기법이 아니라, 무엇을 찾기 위한 방법인가요?

- 문제의 명확한 정의와 근거에 기반한 해결 방법을 도출하기 위함.

 

◾현재 답변의 장점

• '근본 원인'이라는 핵심을 정확히 짚음.
• 해결책보다 문제 정의가 중요하다는 PM 관점이 들어감.
• 단순 기법이 아니라 사고방식으로 이해하고 있음.

◾ 보완하면 좋은 부분

• 약간 정의 암기형 답변 같음. 면접에서는 '왜 이걸 중요하게 생각하는지'까지 드러나면 좋음(근본 원인에 가까워지기 위한 도구).

◾ 개선된 면접 답변

• 5Why를 단순히 '왜'에 대해 반복하기보다는, 문제의 근본적 원인에 가까워지기 위한 과정이라고 생각합니다. 서비스 문제는 다양한 관점으로 분석한 뒤 방향을 설정해야 보다 정확한 문제 파악이 가능하다고 생각합니다. 해당 구간에서 사용자 이탈이 발생하더라도 UI/UX적 문제라고 단정 내리기 어렵고, 다른 원인이 존재할 가능성도 함께 고려해야 하기 때문에 근본적인 원인을 단계별/구조적으로 확인하는 과정이 중요하다고 생각합니다.

 

Q2. 왜 바로 해결책보다 5Why 접근이 더 좋은가요?

- 가설 중심이 아닌 데이터 기반 의사결정으로 설득력이 증가함.

 

◾현재 답변의 장점

• 데이터 기반 의사결정 관점이 좋음.
• 성급한 해결책 제시를 경계하는 흐름이 좋음.
• 문제 원인을 먼저 본다는 사고가 드러남.

◾ 보완하면 좋은 부분

• 좀 딱딱함. '왜 위험한가'에 대한 정의를 자연스레 풀어주면 좋음.

◾ 개선된 면접 답변

• 사용자 이탈이라는 결과만 보고 반영을 하기엔 실제 원인과 다른 방향으로 대응하게 될 가능성이 있다고 생각합니다. 실질적인 문제가 디자인적인 요소가 아니라 기능적 결함이었을 경우, 그에 상응하는 비용(시간 포함)이 발생할 수 있습니다. 그래서 데이터 기반으로 정확히 어느 구간에서 왜 이탈이 발생하는지 확인하고, 왜 그런 현상이 발생했는지를 단계적으로 확인하는 과정이 중요하다고 생각합니다.

 

Q3. 5Why를 할 때 가장 조심해야 할 점은 무엇인가요?

- 일부의 내용을 전체 내용의 문제로 정의 내리는 것(데이터 중심 사고 필요)

 

◾현재 답변의 장점

• 일부 현상을 일반화하면 안 된다는 포인트가 좋음.
• 데이터 중심 사고 방향이 맞음.
• 추측을 경계하는 관점이 있음.

◾ 보완하면 좋은 부분

• 답변이 너무 압축됨(실제 상황을 설명하기엔 다소 약함). 흔히 발생할 수 있는 상황을 짧게 섞어 표현할 것.

◾ 개선된 면접 답변

• 가장 조심해야(경계해야) 하는 부분은 일부 사례만 보고 전체 문제라고 단정하는 것이라 생각합니다. 명확한 근거 없이 추측만으로 Why를 이어가는 건 위험한 접근이라고 봅니다.
  예를 들어, 리뷰 데이터 몇 개만 보고 판단할 경우 해당 서비스에 대한 개개인의 일시적인 감정이나 개인 성향이 반영될 수도 있다고 생각하기 때문에 실제 데이터 흐름과는 다소 다를 수 있다고 생각합니다.
  그래서, 저는 하나의 의견만 보기보다는 다양한 지표(퍼널, 로그, 실사용자 인터뷰 등)를 크로스체크하며 사실과 가설을 분명하게 구분 지어 결론을 도출하고자 합니다.

 

꼬리질문 1. 추측에 빠지는 걸 실무에서 어떻게 방지하시겠어요?

- 한 가지 지표만 보지 않고 해당 사항과 관련된 여러 지표를 보며 크로스체크하여 문제 정의를 뾰족하게 설정한 뒤 추측이 아닌 정답에 가까운 답을 도출해냄

 

◾ 개선된 면접 답변

• 이 역시 한 가지 지표만 보고 판단하기에는 복합적인 문제가 있을 수 있다고 사료되어, 관련된 퍼널 지표나 유저플로우 데이터를 함께 보며 크로스체크하는 것이 좋다고 생각합니다.
  그리고 퍼널, 로그, 실사용자 인터뷰 등 상이한 근거 데이터를 함께 보며 '단순 가설'에 그치는 문제인지, '실제 데이터 기반 문제인지' 계속해서 확인하려 합니다.
  비단 PM뿐 아니라 모든 직군에서 통용되는 말이지만, 경력이 쌓이더라도 트렌드 변화/시장 변화 등 환경적인 요소가 작용하기 때문에 완벽한 결과물을 만들 수도, 결과 도출을 해내기도 어렵습니다. 그보다는 불확실성을 줄여가며 더 근거 있는 방향으로 데이터 기반 의사결정을 해나가는 역할에 가깝다고 생각합니다.

 

꼬리질문 2. 모든 문제에 5Why를 적용하는 게 항상 좋은가요?(영향도, 시급성, 구현 난이도)

- 내부 운영적 반영 한계라든지, 유관부서와의 협의 문제, 의사결정자 문제 등 다양한 제한 지점이 존재할 가능성이 큼. 그리고 모든 문제에 5why를 적용하기보다는 핵심 문제에 집중적으로 5why를 적용하는 게 훨씬 효율적.

 

◾ 개선된 면접 답변

• 모든 문제에 5Why를 적용하는 게 모두 효율적으로 작용한다고 보장하긴 어렵습니다.
  실무에서는 시간이나 기존 레거시 코드나 기존 시스템 구조 등 구현 제약이 있고, 여러 유관 부서와 사전 협의가 필요한 경우도 많기 때문입니다.
  그래서, 저는 서비스 핵심 지표에 직접 영향을 주는 핵심 문제나 반복적으로 발생하는(그러나 현실적으로 개선 가능한) 문제를 우선적으로 활용하는 게 현실적으로도 유관 부서를 설득하기 좋은 접근이라고 생각합니다.

 

꼬리질문 3. 실제 우선순위는 어떻게 정하시겠어요?

- 영향도(Impact) : 사용자 이탈이 어느 지점에서 크게 발생하는지를 우선적으로 파악, 해당 문제가 지속적으로 크게 지표적 영향을 끼치고 있을 경우 우선순위로 설정
- 시급성(Urgency) : 결제/로그인 문제와 같은 서비스 핵심 기능에서 문제가 발생한 경우
- 구현 난이도(Effort) : 내부 운영 문제/발생 비용 문제/시간적 제한 등 내부 사항도 고려해야 함. 구현 난이도 또한 개발자들의 의견을 충분히 들은 뒤, 시간이 얼마나 소요되는지, 어디까지 구현 가능한지 여부를 확인한 뒤 진행할 필요가 있음

(Quick Win*부터 실행)

 

* Quick Win : 적은 비용/시간으로 빠르게 효과를 낼 수 있는 개선 작업을 의미(영향도는 높은데 구현도는 낮은 작업)

 → 빨리 적용 가능한데 체감 효과도 좋은 것

ex 1. 로그인 버튼 안 눌리는 버그 수정(Quick Win 여부 : O) → 개발 난이도 낮고 사용자 영향 큼

ex 2. 결제 페이지 로딩 속도 1~2초 개선(Quick Win 여부 : O) → 이탈 감소 효과 가능성 높음

ex 3. 서비스 전체 UX 구조 전면 개편(Quick Win 여부 : X) → 영향은 클 수 있지만 시간/비용 큼

ex 4. 추천 알고리즘 새로 개발(Quick Win 여부 : X) → 구현 난이도 높음

 

☑️ 영향도가 크면서도 비교적 빠르게 개선 가능한 Quick Win 영역부터 우선적으로 대응하려고 합니다

→ 현실적인 실행 감각/리소스 고려/'무조건 큰 거부터'라기보다는 근거 기반 사고가 실무형 사고로 적절한 방향

 

 

유지(Keep) 해도 좋은 표현

• 불확실성을 줄여가며
• 단계적/구조적으로 확인
• 다양한 지표를 크로스체크
• 현실적으로 개선 가능한 문제
• 유관 부서를 설득

 

유지(Keep) 해도 좋은 포인트

• 무조건 UX 탓 안 하는 점
• 비용/시간 고려하는 점
• 개발자 협업 언급하는 점

 

---

 

오늘을 마치며

 

평소 ‘왜?’라는 생각을 많이 하는 편이다.

왜 저렇게 하는가, 저게 정말 효율적인 방법인가, 더 나은 방향은 없을까.

 

사회적 이슈 역시 단순히 받아들이기보다는,

조금 다른 시선으로 바라보면 오히려 문제 자체를 새로운 기회로 활용할 수 있지 않을까 생각하곤 한다.

 

ex. AI가 인간의 일자리를 대체하는 경우에 관하여,

나는 뚱뚱한 모니터 → MP3/MP4 → 폴더/슬라이드폰 → 스마트폰/태블릿 → AI까지

그 흐름의 변화를 꽤 가까이서 직접 보고 경험해 왔다.

(너무 나이가 추측되는 발언이지만...ㅋㅋㅋㅋㅋ)

 

개인적으로 AI에 대체되지 않는 사람은,

결국 변화하는 환경에 얼마나 빠르게 적응하고 활용할 수 있는 사람인가에 달려 있다고 생각한다.

 

이처럼 끊임없이 ‘왜?’를 고민하고,

그 고민 끝에 앞으로 어떻게 행동할 것인지,

스스로 옳다고 생각하는 방향을 정하고 나아가려 한다.

내일의, 그리고 먼 미래의 나를 위해.