사실 그것도 생각했는데요.

자기합리화로 받아들여지지 않게 이해관계자를 설득하기

"사실 그것도 생각했는데요."

기획을 끝내고 디자이너, 개발자에게 리뷰를 가질 때 자주 하는 말 중 하나다. (다른 말로는 "이렇게 한 이유는요.", "이해하셨을까요?" 등이 있다.)

변명 같지만 변명이 아닌, 괜히 뱉어놓고 나서 스스로 뭔가 억울한 느낌이 드는 말이다. 왜 이런 말이 자주 나오는 걸까?

이유는 간단하다. 각자 가지고 있는 정보량에 차이가 있기 때문이다. 기획자는 서비스의 전체 그림을 그리고, 그 안에서 발생할 수 있는 다양한 시나리오를 고려해 결정을 내린다. 반면, 개발자나 디자이너는 자신이 맡은 부분에 집중하게 되면서, 기획자가 이미 고려한 대안을 다시 제안하는 경우가 종종 발생한다.

예를 들어 이런 상황이 있을 수 있다.

기획자: 서비스 특성상 사용자가 다른 제품과 연동할 때 '본인인증'을 첫 번째 프로세스로 둬야 합니다. 본인인증 후 회원 DB에서 CI값이 존재하는지 여부에 따라 회원을 로그인 페이지로 이동시키거나 회원가입 페이지로 이동시켜야 해요.

개발자: 상상해 봤을 때 사용자가 불편할 것 같아요. 사용자가 제품 연동을 수락받는 건데 시중의 다른 서비스처럼 로그인을 먼저 시키면 좋겠습니다.

기획자: 사실 그것도 생각했는데요. 이렇게 한 이유는...

이 상황에서 기획자가 "사실 그것도 생각했는데요"라는 말을 하게 되는 이유는, 기획자가 이미 해당 대안을 충분히 고려했기 때문이다. 예를 들어, 로그인 화면으로 사용자를 바로 이동시키는 시나리오를 기획 단계에서 검토했을 때, 다음과 같은 이유로 선택하지 않았을 수 있다:

1. 대부분의 사용자들이 비회원일 가능성이 있다.

내부 데이터나 시장 조사를 통해, 제품 연동을 시도하는 사용자 중 다수가 서비스에 처음 방문하는 비회원이라는 사실을 발견했을 수 있다. 이 경우 로그인 화면으로 바로 이동시키면 사용자는 "내가 계정이 있나?", "저 제품의 계정으로 이 제품에 로그인해도 되나?" 등 다양한 문제를 생각하고 판단해야 한다. 이 과정에서 기획자는 사용자가 자신이 해야 하는 행동을 바로 유도하는 것이 더 적절하다 판단했을 것이다.

2. 로그인 실패 시나리오의 복잡성이 높다.

사용자가 로그인 화면으로 이동했을 때, 계정이 존재하지 않거나 계정을 잊은 경우 발생할 수 있는 다양한 예외 처리를 고려해야 한다. 이는 사용자 경험을 복잡하게 만들 수 있기 때문에 기획자는 더 간단하고 직관적인 플로우를 선택했을 것이다.

3. 공급자와 사용자, 양측의 이익을 고려했다.

기획자는 서비스 제공자와 사용자의 양측 이익을 모두 고려해 결정을 내린다. 로그인 절차를 간소화함으로써 사용자의 혼란을 줄이면, 사용자에게 더 나은 경험을 제공하고, 공급자의 CS 부담을 줄일 수 있다고 판단했을 것이다.

이처럼 기획자는 단순히 하나의 플로우만을 고려하는 것이 아니라 다양한 시나리오를 검토하고 그중 최선의 결정을 내린다.

정리해 보자. 기획자는 다양한 시나리오와 케이스를 고려한 후 최적의 결정을 내려야 한다. 그리고 그 결정을 이해관계자들에게 명확히 전달할 수 있어야 한다.

"사실 그것도 생각했는데요"가 이해관계자에게 변명이나 자기합리화로 전달되지 않게 소통하고, 실무자가 불필요한 생각에 휩싸이게 하지 않아야 한다.

이를 위해 나는 보통 아래의 3가지 전략을 사용한다:

1. 공통 목표를 확인한다.

위에 든 예시에서 개발자가 의견을 말한 이유는 분명하다. 사용자에게 긍정적인 경험을 주기 위해서다. 이는 기획자도 마찬가지다. 기획자와 개발자는 결국 '긍정적인 사용자 경험'을 최우선으로 둔다. 이 경우 논의의 출발점에서 서로가 추구하는 공통 목표를 다시 한번 확인하고, 그 목표에 따라 최선의 결정을 내리기 위해 논의한다는 점을 강조한다. 이를 통해 논의가 감정적으로 흐르지 않고, 건설적인 방향으로 진행될 수 있다.

2. 의사결정 과정을 틈틈이 공유한다.

기획자가 개발자를 설득하려면, 기획자가 어떤 이유로 특정 플로우나 대안을 선택하지 않았는지 명확히 설명해야 한다. 이를 위해 나는 의사결정이 일어나는 과정에서 중요한 단계마다 간단한 메모를 남겨둔다. 이를 바탕으로, 필요할 때마다 이해관계자와 함께 의사결정 과정을 돌아보며 논의할 수 있다. 단, 너무 많은 정보를 공유하지 않도록 주의하자. 너무 많은 정보는 실무자를 되려 혼란스럽게 만든다. 그들이 그들의 실무에 집중할 수 있게 만들어 주는 것도 기획자의 역할이다.

3. "나는 당신의 의견을 존중해요."

여러 대안을 고려해서 기획했다고 할지라도 개발자의 제안을 신중히 검토할 필요가 있다. 개발자는 실제 구현 측면에서 기획자가 미처 생각하지 못한 기술적인 제한이나 기회를 알 수 있기 때문이다. 나는 개발자의 피드백을 적극적으로 수용하고, 이를 반영해 기획을 더 나은 방향으로 조정하려고 노력한다. 예를 들어, 개발자가 제시한 플로우가 사용자 경험을 크게 개선할 가능성이 있다면, 나는 그 아이디어를 다시 검토하고, 기획에 반영할 수 있는 방법을 모색한다. 그리고 그들에게는 직접 이 점을 직접적으로 전달하자. "저는 당신의 의견에도 공감합니다. 한 번 더 검토해 볼게요"처럼 말이다.

소통에는 정답이 없다. 우리는 각자 다른 시각과 경험을 가지고 있다. 완벽한 소통을 기대하기보다 그때그때 상황에 맞게 조율해 나가는 것이 중요하다. 중요한 건 우리가 같은 방향을 바라보고, 소통하며 더 나은 결과를 만들어내는 것이다. 동시에, 내 생각이 남들에게 자기합리화처럼 받아들여지지 않도록 자신을 지키는 노하우를 터득하자.

ⓒ 327roy