실험제품을 만드는 네이티브 개발자의 고충 (확장성)
뚝딱뚝딱..
오늘도 어느 iOS개발자는 유저의 니즈를 검증하기 위해서 실험제품을 만들고 있었다.
그러던 와중 PM이 찾아와서 개발자에게 물었다.
- 이전에 실험했었던 A제품을 다른 유저 타겟에게 확장하고 싶어요.
- 이전에 실험했었던 B제품에 기능을 더 추가하고 싶어요.
개발자는 머리를 굴려보았고, 돌아오는 답은
- “기술적으로 이러쿵 저러쿵해서 확장 및 추가하기가 쉽지 않아요"
이러쿵 저러쿵의 내용의 정답은 무엇일까?
정답은!
“기획상 실험을 목적으로 시작했던 제품이기 때문에 확장성을 설계상 고려하지 않았어요…"
아니 다~ 방법이 있다.
그렇다면 이런 상황에서 어떻게 네이티브 개발자와 타협을 해서 확장해 나갈 것이며, 초기에 어떻게 설계해야지 확장성 있게 유저에게 실험과 동시에 가치를 전달할 수 있을까에 대해서 다뤄볼려고 한다.
아끼면 💩 된다
이전에 실험한다고 제품만드는데 쏟은 시간과 코드들이 아까운거 보단 사이드 이펙트 없이 안정적인 상태로 제품을 유지하는게 최우선이다. 불안정한 실험제품에 기능을 추가하거나 다른 유저대상에게 우려먹는건 “젠가”와 큰 차이점이 없다.
즉, 엔지니어링/개발관점을 배제하고 사용자 관점을 생각해서 무작정 확장하면 결국 제품은 무너지고, 원치않는 피해를 받는 유저가 생기게 되고 결국 개발자에겐 버그를 만든 손목을 자르고 싶은 자괴감?이라는 선물을 선사하게 될 것이다. 여기서 가장 중요한 포인트는 확장한다는건 실험이 기대한 만큼 잘 동작했기 때문이기 때문에, 기존 실험은 그대로 두고 확장가능한 형태의 제품을 새로만들어서 출시하는게 바람직할 것이다.
아끼지말자… 💩된다… 계속 고도화하면 누군가가 거대한 💩을 치우겠지?
처음부터 개발자분들이 확장가능하게 만들면 안되는 일이 였을까요? 🥲 개발자가 이전에 말한 것을 되짚어보자,
“기획상 실험을 목적으로 시작했던 제품이기 때문에 확장성을 설계상 고려하지 않았어요…”
이 말은 애초에 기획적인 측면에서 커뮤니케이션 당시에 확장성을 고려하지 않았기 때문에 개발자는 확장성을 고려하지않고 빠르게 최소스펙으로 제품을 작성하고 목표를 실현하는데 집중을 했을 것이다.
기획자여.. 만약 실험당시 확장까지 꿈꾸고 있었다면 개발자에게 확장가능성에 대해서 정확하게 의사를 전달하면 된다. 그러면 개발자는 확장성을 고려한 형태와 최소스펙을 고려하면서 빠르게 설계를 하게 될 것이고, 당신에게 큰 선물을 안겨다 줄 것이다. 요즘엔.. 앞만 보고 달리기엔 너무 험난한 세상이다…
🤔 흠 하지만… 확장성 고려할 정도로 예측하기 어려운 실험이에요.. 이런경우엔 그럼 어찌하나요?
개발자는 기획과 목표를 엔지니어링을 통해서 실현 함과 동시에 안정적인 상태로 제품을 유지하는데 신경을 많이쓰고 있습니다.
특히, “안정적인 상태로 제품을 유지”의 표현이 추상적일 수도 있는데 풀어서 말하자면 아래와 같다.
실험의 변화가 다른 기능에 의도하지 않는/원치않는 동작이 일어나지 않도록 노력하는 부분 기존 기능이 실험으로 인해서 구조적으로 많은 변화를 주지 않도록 신경을 씀. (쉽게 비유하자면, 파란색에 빨간색 50%만 영향을 줘도 파란색이 보라색(기존과 전혀다른 기능)으로 바뀌는 현상을 방지하기 위해 머리를 굴리는 행위)
위 내용과 함께 정리해서 답을 하자면, 다른 기능에 영향을 최소화 함과 동시에 언제든 파괴하고 새로만들 수 있는 방향을 고려해서 개발자와 커뮤니케이션 하는 것이다.
머리가 복잡할 때 복잡한 생각의 범위를 벗어나 새로운 것을 생각해서 빠르게 문제를 해결듯이, 빠르게 유저에게 가치를 전달하고 싶다면 이전 허물은 과감히 벗어 던지고 새로 만드는 것이 빠를 수도 있다.
결국 엔트로피는 증가한다.
기능을 확장하다보면 당연히 엔트로피는 증가한다.
지라 컨플루언스에 작성했던 깔끔했던 기획서도 시간이 지나면 복잡해지고 무질서해지기 마련이고,
코드도 마찬가지로 시간이 지나면서 복잡해지고 무질서해지고 이로 인해서 cs에 버그 리포트는 점점 늘어날 것이다.
우리가 궁극적으로 지향하는 건, 유저에게 좋은 가치를 줌과 동시에 튼튼한 제품을 선사하는 것 아닌가?
즉, 엔트로피가 높아지면 낮추기 위한 노력은 개발자 뿐만 아니라 제품과 실험을 기획한 당사자들도 함께 노력해야하는 부분이다.
마무리
유저관점도 중요하지만 기존 제품 설계 관점도 중요하고 이것은 결코 개발자만 고려하거나 생각해야하는 부분이 아님을 다시 재강조 하면서 이 글을 마무리할려고한다.