비즈니스 팀에서 급하게 요청이 들어왔다.
"고객이 이 기능만 있으면 저희 제품을 쓴대요!
특정 고객 3명한테만 표시되게 할 거고요, 지금 UI 옵션에서 한 줄만 추가해 주시면 될 거 같은데 빠르게 만들어 줄 수 있나요? 고객이 웹만 써서 앱 말고 웹에만 기능을 추가해 주셔도 괜찮아요"
내가 생각해도 완전히 새 기능도 아니고, 복잡한 UX도 아니고
진짜 디자인으로는 한 줄만 추가되어서 디자이너의 디자인도 필요 없었다.
"간단할 것 같네요, 최대한 맞춰볼게요"
PRD를 쓰는데 10분도 안 걸렸던 것 같다.
문서를 작성하고 당당하게 백엔드 개발자를 찾아갔다.
비즈니스 팀에서 말한 것처럼 똑같이
"지금 옵션에서 한 줄만 추가하면 되고, 특정 고객한테만 표시할 거라서 기존 고객에게는 표시 안 해도 돼요!"
라고 말했지만 백엔드 담당자가 내게 한 대답은 내가 한 대답과는 달랐다.
"비즈니스 로직이 추가된 건가요?"
"특정 고객에게만 특정 기능을 여는 게 조금 더 로직이 복잡해요"
"이 옵션이 추가되어야 하는 이유는 뭔가요?"
UX적으로는 한 줄 추가라고 생각했는데 백엔드의 로직으로는 그렇게 단순한 작업이 아닌 것 같았다.
"아.. 백엔드 스코프는 그렇게 간단하지 않나 보네요.. 그럼 일단 프론트 개발자랑 이야기하고 다시 오겠습니다. 잠시만요..!"
곧바로 Web 프론트 개발자를 찾아갔다.
"프론트에서는 새 옵션 표시하는 건 그렇게 어렵지 않아요!"
"아 그런가요!! 너무 다행이에요ㅠ 제가 빨리 처리해야 해서요.. 혹시 특정 고객에게만 새로운 옵션을 표시하는 것도 프론트에서 처리해 주실 수 있을까요? "
"아.. 그럼 프론트에서도 하드 코딩처리를 해야 하는데 좋은 방법은 아니네요.. "
"그래도 어떻게 안될까요.. 백엔드가 하기엔 스코프가 좀 있대요"
"그럼 프론트에서 처리해야겠네요. 일단 알겠습니다."
그래서 Web 프론트에서 특정 고객에게 옵션 처리를 하고 백엔드에서는 새 옵션을 추가하는 API만 만들어서 일을 진행하고 생각보다 빠르게 테스트를 진행할 수 있었다. QA를 진행하다가 웹에만 기능을 추가했긴 했지만 앱은 어떻게 처리되는지 보려고 안드로이드 앱을 킨 순간 앱이 뻗었다.
정말 내 입에서 억 소리를 참을 수가 없었다.
일단 문제를 해결해야 하니 곧장 백엔드 담당자를 찾아가서
"앱에는 바꾼 게 없는데 앱이 터져요.. 왜 그럴까요ㅠ"
"앱에 호환성 문제가 있나 보네요, 안드로이드 개발자랑 같이 이야기해보시죠."
"안드로이드 앱을 만들 때 옵션이 추가된다는 가정을 안 하고 만들었어요. 모르는 옵션이 들어와서 해석을 못해서 터진 거 같아요"
"헉 그럼 어떻게 해결할 수 있나요?"
"일단 백엔드에서 앱버전 별로 터지지 않게 기존 옵션으로 대치하게 처리하고 안드로이드는 새 옵션이 들어와도 안 터지게 처리해놓을게요. 원하시는 옵션으로 표시하려면 안드로이드는 꼭 강제 업데이트를 해야 해요."
분명히 UX로써는 한 줄 추가였는데 그 기능을 구현하기 위해서는 내 생각보다 아주 많은 처리들이 들어갔다. 간단한 이슈라고 생각했던 부분에서 내가 놓친 부분은 3가지이다.
1. 디자인이 간단하다고 구현까지 간단할 것이라고 판단했던 것
2. 각 플랫폼 별로 구현 방법이 달라 난이도가 다를 수 있다는 것
3. 있던 기능이라도 새로운 기능이면 호환성 이슈가 생길 수 있다는 것
나도 모르게 디자인만 보고 구현의 난이도를 예측하고 있었던 것 같다.
디자인은 간단해도 구현의 난이도는 어려울 수 있고, 호환성 이슈가 일어날 수 있어 새로운 기능을 추가할 때는 플랫폼 별로, 백엔드 관점, 프론트 관점으로 개발자들과 충분히 대화 한 다음에 일을 처리하는 습관을 가져야 할 것 같다.
다시 한번 말하지만 디자인으로는 간단할 줄 몰라도
그 기능은 전체 시스템에 영향을 주는 변경일 수도 있다. 잊지 말자!