- Published on
가치관의 충돌
복잡도 높은 제품, 그 복잡도 높다가 단순히 기술적이거나 여러 정책들로 인한 나의 이해의 복잡도가 아니라 애초에 가능한 경우의 수가 너무 많고 통제 불가능한 동인 요소들이 많은 제품을 다루다보면 논리적 충돌이 생기면 정상적인 대화의 어려움이 생긴다. 어떤 하나의 기능이나 정책에 대해서도 이럴 수도 있지 않냐는 반문이 너무 쉽기 때문이다. 즉 엔트로피1가 높다. 콘웨이의 법칙2처럼 제품은 조직을 닮고, 조직은 제품을 닮아간다. 복잡도가 높아지면 인간에게 가장 쉬운 선택지는 변하지 않는 것이다. 아무것도 하지 않는게 지금의 엔트로피를 유지하는 것이라고 생각이 되기 때문이다. 사실 지금의 엔트로피가 복잡하지 않은 상태처럼 보이지만 우리가 보지 않았기 때문에 그 무질서함을 몰랐던 것 뿐이다. 이것과 연결된 무언가를 건드리려 쳐다보니 그 무질서가 눈 앞에 드러난 것이다.
어떤 선택지들이 있을까?
- 모든 경우의 수를 고려해서 결국 개발한다.
- 생각 가능한 수준에서 개발하고 이슈가 생기면 대응한다.
- 더 작은 범위로 축소해서 고려 가능한 경우의 수로 좁혀서 개발한다.
- 포기한다.
나는 1과 4는 싫어한다. 시간이 지체되면 우리가 쏟아야 할 비용의 크기가 기하급수적으로 증가한다. 하나의 정책 변경은 또 다른 곳에서 정책적 이슈를 가져온다. 비용이 늘어나면 우리가 개선된걸 내놓는 시간이 오래 걸린다는 소리이고 그만큼 고객의 고통은 쌓여간다. 그렇다고 포기하는 것은 개선하지 않겠다는 의미가 되어버린다.
그럼 남는 보기는 2와 3밖에 없다. 나는 이 둘을 케이스에 따라 나누어 선택한다. 다만 3이 우선순위이며 3으로 진행하는 과정에서 생각하지 못한 이슈들이 나올 때 그 케이스에 따라 2를 선택하게 된다. 예를 들어 우리 중 누구도 몰랐던 숨겨진 기능과 정책이 개발 중에 나타났다. 근데 정책 복잡도가 크고 사용하려는 사람이 충분히 잘 쓰고 많이 찾는 기능인지도 모르겠다. (그랬다면 그 전에 알았을 것이다.) 그럼 그냥 없애거나 UI 변경 없이 숨겨둔다거나 하는 식으로 처리한다. 엔트로피를 높이는데에만 일조하고 실상 필요없는 기능일 수도 있다. 그렇게 사라진 기능들이 제법 많다. 과거에 1과 2를 우선 순위로 해나갔던 경우 자주 발생하는 문제이다. 경우의 수를 줄일 수 있음에도 줄이지 않은 대가를 미래의 동료가 짊어지게 되는 것 뿐이다. 이건 부채라고 하기 어렵다. 부채로 쌓아두기 위해 얻은 이익이 없다. 그 당시에도 그로인해 늦어졌을 것이고 개발하느라 비용이 더 들어갔을테니 말이다.
엔트로피를 낮춰야 한다는 의미는 아니다. 엔트로피는 높아질 수 있다. 심플하고 단순했던 제품도 사용자가 늘어나고 그 사용자의 기대가 커지면 그만큼 제품도 부피가 커질 수 밖에 없다. 당연한 수순이고, 배워나가는 과정이다. 필요한 것은 답습하지 않고 불필요해진 경우의 수를 줄여나가며 적정 엔트로피를 유지해 다음으로 도약할 때 장애물을 줄이려는 현재의 관심정도이다.