완성도를 높이는 일은 상당히 고되다.

소프트웨어나 기계나, 아니면 단순히 물건이거나, 무언가를 만들 때 완성도는 굉장히 중요하다.
그리고 기능에 큰 차이가 없더라도 완성도에 따라서 가격이 달라지곤 한다.

물건의 경우 마감의 품질이 달라질 수도 있고, 웹 서비스나 앱의 경우 의도한 그대로 완벽한 기능일 수도 있고, 디자인일 수도 있다.

내가 경험한 소프트웨어 개발의 경우, 고객이나 기획팀과 기능이나 버그에 대해 얘기를 나누다 보면 “이게 정말 중요해요”와 같은 우선순위 관련 얘기를 할 때가 있다.

그 이후 따라오는 얘기가, B는 A버그에 비하면 그렇게 중요하지 않으니 A버그를 해결해야 한다고 얘기한다. 이러한 요청이 앱의 완성도가 90%를 99%로 바꿔줄 때가 있고, 98%를 99%로 바꿔줄 때가 있다.
이런 과정을 자주 겪다 보면, 개발자 스스로 판단하게 되는 경우가 많다. 이건 98%에서 99%로 가는거라.. 사실 굳이 안 해도 될 것 같다거나, 분명 이전에는 B가 중요하다고 해서 한 건데. 라는 생각이 들기도 한다.

개발을 하다보면 분명 완성도가 떨어질 때가 있다. 개발자도 알고, 고객이나 기획자도 이미 알고 있다. 그리고 그런 부분을 보완하기 위해서 서로 논의하고 개발을 해 나간다.
이때 직접 개발하는 사람이 아니라면, 개발자를 위해 우선순위를 얘기하는데, 사실 대부분은 우선순위가 아니다. 어쨌든 이번 오픈에 A가 안 들어가고 B만 들어가도 된다고 타협할 수 없다면, A와 B 둘 다 높은 우선순위일 뿐이다.

핵심은 타협인 것 같다. 만약 돌을 구로 깎는다고 하면, 돌이 구가 될 때까지 깎다가, 타협하지 못하면 결국 돌은 없어져 버릴 것이다.

완성도”만” 쫓다 보면 이러한 점을 놓치기 쉬운 것 같다.