개발자 VS 클라이언트, 그 사이에서

본질을 파악하면 보이는 제3의 길

또 다른 두 마리 토끼 딜레마

어느 프로젝트를 진행 중에 있었던 일이에요.

서비스 내에서 촬영일자를 선택하여 영상을 검색하는 기능에서 달력 UI가 필요했거든요.

클라이언트가 기획과 디자인을 담당하고, 저희는 프론트엔드 개발과 기능 구현을 맡은 프로젝트였어요.

그런데 이번에도 어김없이 등장한 두 마리 토끼 잡기 상황이었습니다.

이미 완성된 기획서의 키보드 입력 기능

클라이언트가 넘겨준 기획서를 보니 이런 내용이 있었어요.

"사용자가 키보드로도 날짜를 입력할 수 있어야 함"

디자인까지 이미 완료된 상태였거든요. 달력 UI 위에 텍스트 필드가 있고, 사용자가 직접 타이핑할 수 있도록 설계되어 있었어요.

개발 단계에서 터진 복병

그런데 막상 개발 단계에 들어가니 문제가 생겼어요. 프론트 개발자가 걱정하는 기색을 보이며 이런 말을 하더라고요.

"날짜 picker와 시간(HH:mm)을 모두 한 번에 동기화하면서 포맷마스킹까지 하는 건 복잡해요. 키보드 입력 기능은 제외되는 게 나을 것 같습니다."

이해되는 얘기였어요. 서비스 특성상 시간 단위까지의 탐색이 필요했거든요.

UI상에서는 날짜와 시간이 별도로 분리되어 있지만, 텍스트 필드에서 키보드 입력을 지원하려면 "2025-03-15 14:30" 같은 형태로 날짜와 시간을 묶어서 관리해야 했어요.

그렇게 되면 사용자 입력 검증, 포맷 변환, UI 간 동기화 등 예상보다 복잡한 로직들이 필요했던 거죠.

이미 기획과 디자인이 완료된 상황에서 핵심 기능을 제외하자고 하니까 난감했어요. 클라이언트 입장에서는 "뭐야, 기획대로 안 되는 거야?" 싶을 수도 있고요.

고민이 필요하지만, 이런 딜레마들을 해결하는 것은 늘 즐거운 일이다!

잠깐, 정말 원하는 게 뭐지?

그런데 여기서 한 걸음 뒤로 물러서서 생각해 봤어요.

클라이언트가 정말 원하는 건 "키보드 입력" 그 자체일까?

기획서의 그 한 줄을 다시 보니 답이 보이더라고요. 아마 이런 상황을 생각했을 거예요

가령 2020년 3월 영상을 찾으려면 달력을 몇 번이나 넘겨야 하는데, 그게 너무 불편하니까 키보드로 직접 입력하게 하자는 거였겠죠.

진짜 니즈는 "멀리 있는 날짜에 빠르게 접근하고 싶다"는 거였어요.

기획보다 더 나은 아이디어 발견

그래서 적극적으로 탐색해 봤어요. 키보드 입력 말고 다른 방법은 없을까?

그러다 발견한 게 연간 조작 기능이었어요.

"혹시 달력에서 연도를 빠르게 이동할 수 있는 기능이 있다면 어떨까요? 키보드 입력 대신 연간 조작 기능으로 해결할 수 있을 것 같은데요."

사실 생각해 보면 연간 조작이 키보드 입력보다 더 직관적이고 편리한 UX일 수도 있거든요.

키보드 입력: "2020-03-15" 정확한 포맷으로 타이핑

연간 조작: 클릭 몇 번으로 2020년 → 3월로 바로 이동

어쩌면 기존 기획보다 더 좋은 사용자 경험일 수도 있겠다 싶었어요.

기획의 의도의 본질이 무엇인 지 꼼꼼히 생각해 보자

개발자: 즉석에서 해결책 발견

제가 이 아이디어를 제안하자 개발자 반응이 180도 달라졌어요.

"아, 연간 조작 기능이 이미 지원되네요. 이거라면 훨씬 간단하게 구현할 수 있어요!"

직접 구글링 해서 달력 플러그인 문서까지 찾아보시더라고요. 아까 그 곤란한 기색은 어디 가고 적극적으로 협조해 주시는 모습이었어요.

클라이언트: 기획 변경에도 흔쾌히 수락

가장 걱정했던 건 클라이언트 반응이었어요. 이미 완성된 기획을 바꾸자고 제안하는 거니까요.

그런데 의외로 정말 깔끔했어요.

"아, 그게 더 좋네요! 그렇게 하죠."

별다른 설명이나 설득이 필요 없었어요. 본질적 니즈가 더 잘 만족되는 방향이니까 당연히 OK인 거죠.

본질을 꿰뚫을 때, 더 나은 소통 과정과 결과가 이루어진다.

기획을 개선한 PM의 역할

: 단순한 개발 이슈 해결이 아닌 기획 업그레이드

이번 경험에서 가장 뿌듯했던 건, 단순히 "개발이 어려우니까 타협하자"가 아니었다는 점이에요.

클라이언트: 원래 기획보다 더 좋은 UX 확보

개발팀: 복잡한 구현 대신 간단한 기능 적용

프로덕트: 더 완성도 높은 사용자 경험

적극적으로 본질을 파악해서 기획을 더 나은 방향으로 리드한 케이스였던 거죠.

완성된 기획서도 개선할 수 있다

그리고 깨달은 건, 이미 완성된 기획이라고 해서 무조건 그대로 따라야 하는 건 아니라는 점이에요.

PM이 해야 할 일은 기획서대로 개발하는 게 아니라, 기획의 본질을 이해하고 더 나은 방향이 있다면 적극적으로 제안하는 것이더라고요.

"클라이언트가 A를 기획했다"라고 할 때, 정말 A가 최선인지, 아니면 A를 통해 얻고 싶은 B를 더 잘 달성할 수 있는 C가 있는지 탐색해 보는 거죠.

두 마리 토끼를 잡으려다가, 한 마리 더 잡았다!

본질 파악이 만든 윈-윈-윈

요구사항의 표면에 매몰되어 "키보드 입력 vs 개발 공수"로 대립했다면, 결국 누군가는 양보해야 하는 제로섬 게임이 됐을 거예요.

하지만 "왜 키보드 입력을 기획했을까?"라는 본질을 파악하니까, 모두가 더 만족할 수 있는 제3의 길이 보였거든요.

적극적으로 탐색하는 PM

매 프로젝트가 새로운 도전이자 학습의 기회라고 생각해요.

이번 이슈를 통해 기획서에 "A를 구현해 주세요"라고 나와 있을 때, 바로 A를 만드는 게 아니라 "왜 A가 필요한지, A보다 더 좋은 방법은 없는지" 적극적으로 탐색해 보는 습관을 길렀어요.

때로는 그런 탐색이 기존 기획보다 더 나은 결과를 만들어낼 수도 있다는 인사이트를 얻었습니다.

다음에 또 비슷한 상황이 와도, 이제는 더 자신 있게 "이런 방법은 어떨까요?"라고 제안해 볼 수 있을 것 같아요.