해결책 대신 문제를 공유하기
이전에 UX 디자이너와의 미팅 날이 아직도 기억난다.
그 디자이너분이 미팅 시작 전에 한 가지 부탁을 하셨다. “전문가 대 전문가로서 서로 존중했으면 좋겠다”라는 말과 함께, 그분이 생각하는 존중의 의미를 이야기해주셨다.
“문제 상황에 대해서 해결책을 제시하지 말고, 문제 상황을 공유해주세요.”
그 말을 듣는 순간 머리를 한 대 맞은 듯, “아! 이거다!”라는 생각이 들었다. 당시 나는 주니어 개발자였고, 설움도 많았던 터라 그만큼 디자이너분의 말씀이 더욱 공감되었다. 나 역시 주니어이지만 전문가로서 존중받고 싶었고, 그분의 이야기가 마치 내가 하고 싶었던 말을 대신해주는 것처럼 느껴졌다. 우리는 문제를 해결하는 전문가이지, 제시된 답안을 그대로 따라가는 사람이 아니다.
해결책이 아니라 문제를 공유해야 하는 이유
1. 전문가를 존중하는 태도
UX 디자이너의 예를 들어보자. 디자이너는 사용자의 불편함을 해결하는 역할을 한다. “상품 등록이 어렵다”와 같은 문제를 듣는다면, 디자이너는 다양한 관점에서 문제를 분석하고 최적의 해결책을 설계할 수 있다. 하지만, “버튼을 여기로 옮겨주세요”라는 식의 해결책을 제시받으면 이야기가 달라진다. 디자이너가 고민하고 기여할 수 있는 공간이 사라진다.
의사에게 가서도 마찬가지다. “배가 아파요”라고 말하면 의사는 진단과 처방을 통해 문제를 해결한다. 하지만 “OOO 약을 주세요”라고 하면, 의사가 개입할 여지가 없다. 마치 문제를 해결하는 전문가를 무시하는 것처럼 보일 수도 있다.
2. 문제 해결의 질이 높아진다
많은 경우 제시된 해결책은 진짜 해결책이 아니다. 단편적인 시각에서 나온 즉각적인 반응일 가능성이 크다. 눈앞의 문제를 해결하기 위해 내놓은 해결책이 오히려 문제를 더 복잡하게 만들 수 있다.
버그나 코드 리뷰 상황에서도 마찬가지다. 예를 들어 “이 코드 느린 것 같은데 캐싱을 추가해보세요”라는 식으로 해결책을 제시하는 경우가 많다. 하지만 진짜 문제는 캐싱이 필요한 게 아니라 데이터 구조나 로직에 있을 수도 있다. 문제를 해결할 사람에게 문제 상황만 공유하면, 더 나은 해결책을 발견할 가능성이 커진다.
문제 상황만 정확히 전달되면 해결책의 범위와 깊이가 달라진다. 각자의 전문성을 살릴 수 있고, 단기적인 임시방편이 아닌 장기적으로 유지 가능한 해결책을 도출하게 된다.
3. 신뢰가 쌓인다
문제를 공유하면 팀원 간 신뢰도 함께 쌓인다. 문제를 해결하는 과정에서 서로의 전문성을 인정하고 논의하다 보면 더 나은 협업이 가능해진다. 해결책이 아닌 문제를 공유하는 것은 상대방을 믿고 존중한다는 표현이기도 하다.
또한, 심리적 안정감이 형성된다. 이는 신뢰를 바탕으로 한 협업에 필수적이며, 솔직한 피드백이 오갈 수 있는 환경을 만든다. 심리적 안정감이 있는 팀은 문제를 투명하게 드러내고 함께 해결해 나가며, 결과적으로 더 나은 성과를 낸다.
구글의 연구에 따르면, 팀 내 심리적 안전감은 팀원들이 실수를 인정하고 새로운 아이디어를 탐색할 수 있는 환경을 제공하며, 이를 통해 학습과 혁신의 속도를 높인다. 특히 영업팀의 경우 심리적 안전감이 높은 팀은 목표를 17% 초과 달성한 반면, 낮은 팀은 19%나 부족한 실적을 보였다. 이는 심리적 안정감이 단순한 팀 문화의 요소가 아니라, 조직의 성과에 직접적인 영향을 미친다는 것을 보여준다.
문제를 공유하는 방법
문제를 공유하는 것은 해결책을 제시하는 것보다 더 어렵게 느껴질 수 있다. 다음과 같은 방법을 활용해보자.
- 문제의 원인과 상황을 명확히 설명하기
- 어떤 환경에서 어떤 행동을 했을 때 문제가 발생했는지를 구체적으로 설명하자. 예를 들어, “상품을 등록하려고 했는데, 단계가 너무 많아 중간에 포기하게 되었습니다.” 또는 “파이어폭스에서 구글 소셜 로그인을 했는데, 로그인이 안됩니다” 처럼 환경과 행동, 그 결과 발생한 문제를 차근차근 전달하면 상대가 상황을 이해하는 데 도움이 된다.
- 현재 경험한 불편함을 전달하기
- “이 기능을 사용하는 데 불편하다”가 아니라 어떤 부분이, 어떻게 불편한지 명확하게 전달한다.
- 목표나 기대를 공유하기
- 문제 상황과 함께, 이 문제를 해결함으로써 달성하고 싶은 목표를 공유하면 상대가 더 나은 해결책을 찾는 데 도움이 된다.
- 해결책이 아닌 질문 또는 제안 던지기
- “이런 상황인데 어떻게 해결하면 좋을까요?”와 같이 문제 해결에 대한 논의의 문을 여는 질문을 던지는 것도 좋은 방법이다.
- 코드 리뷰에서는 해결책을 단정적으로 제시하기보다는 제안을 하는 형태로 접근하자. 예를 들어, “여기서 데이터 구조를 다르게 하면 성능이 개선될 것 같은데, 어떻게 생각하시나요?”와 같이 상대의 생각을 물어보는 방식이 더 효과적이다.
+) 책임 소재를 따지는 태도의 문제
문제를 공유하는 환경에서는 누군가의 실수를 지적하기보다 함께 원인을 분석하고, 재발 방지를 위한 방법을 찾는 협력이 중요하다. 문제 상황이 발생했을 때 중요한 것은 어떻게 해결할 것인가와 앞으로 같은 문제가 발생하지 않도록 어떻게 개선할 것인가이지, 잘못을 추궁하거나 책임을 전가하는 것이 아니다.
책임 소재를 따지는 태도는 팀 내 신뢰를 깨고, 문제를 투명하게 공유하는 문화를 저해한다. 심리적 안정감이 형성된 팀은 이를 방지하며, 더욱 투명하고 건설적인 문제 해결 과정을 가능하게 한다.
결론
해결책을 제시하지 않고 문제를 공유하는 것은 상대방의 전문성을 존중하는 첫걸음이다. 버그가 발생했을 때, 코드 리뷰를 할 때, 협업을 할 때 문제를 해결할 전문가가 있다는 믿음을 바탕으로 문제를 명확히 전달하자. 그렇게 할 때 더 나은 해결책이 나오고, 팀원 간 신뢰가 쌓이며, 우리는 진짜 전문가로서 성장할 수 있다.
문제를 해결하는 것은 전문가의 몫이다. 문제 상황을 공유하고 그 해결을 함께 고민하자.
참고 링크
Team dynamics: Five keys to building effective teams
필자가 너무 예민하다고 느껴지는가?
이왕이면 다정하세요 ㅎㅎ
