플랫폼 소프트웨어는 왜 실패할까?

Abstract (요약문)

Why is developing a good platform software difficult? It is because developing a platform software is a procedure that solves two problem domains; business domain and platform software API design domain. The biggest problem is that recognizing and fixing an API design problem is very diffucult to overcome as long as a platform software developer doesn't recognize the problem by his own self due to the nature of the problem, while the lack of business domain knowledge can be pointed out and fixed easily.

훌륭한 플랫폼 소프트웨어를 개발하기가 왜 어려운가? 플랫폼 소프트웨어 개발은 두 개의 영역 - 업무 영역과 플랫폼 API 디자인 영역 - 을 동시에 해결하는 과정이기 때문이다. 문제는 업무 영역에 대한 이해 부족은 개발 과정에서 쉽게 드러나고 극복되는 반면, 플랫폼 API 디자인 영역에 대한 문제 제기와 해결은 영역 자체의 특성상 플랫폼 소프트웨어 개발자 스스로가 인식하지 못하는 이상 극복하기가 어렵다는 데 있다.

---

Getting praised for building a platform software is as difficult as hitting the jackpot.

플랫폼 소프트웨어를 만들어 칭찬받기란 신개념 웹 서비스를 오픈해 대박을 치는 것 만큼 어렵다.

If I am a user of the platform software, I can satisfy a set of required functionality at least.

만약 내가 그 플랫폼 소프트웨어의 사용자라면 적어도 필요한 기능을 충족시킬 수는 있다.

But, almost always, I am not the only user. There are many voices as more users are involved. There's always a voice of unsatisfaction even if we did our best. It's really inevitable.

하지만 플랫폼 소프트웨어의 사용자가 나 혼자뿐인 경우는 보통 없다. 많은 사용자가 개입될수록 플랫폼 소프트웨어에 대한 다양한 목소리가 생겨난다. 아무리 최선을 다 해도 그 중에 불만의 목소리가 없을 수는 없다. 정말 어쩔 수 없다.

Wait, wait. Didn't we satisfy all functional requirements?

하지만 기능적 요구 사항을 다 만족하지 않았는가?

A platform software can't exist if it doesn't satisfy functional requirements. It's the indispensable condition of its existance. That's exactly why people have meetings, sum up a report, and implement every single feature.

기능적 요구 사항을 만족하지 못하는 플랫폼은 존재할 수 없다. 그것은 플랫폼 존재의'필수 조건'이다. 누구나 다 아는 사실이다. 그래서 관련자들이 모여 회의를 하고, 요구 사항을 취합해 보고서가 작성되고, 하나 하나 기능이 구현되는 것이다.

However, it is impossible for a platform software to get acknowledged as a good platform software only because of satisfaction of funational requirements. It is because a platform software have to satisfy ambiguous non-functional requirements.

그러나, 이런 기능적 요구 사항에 대한 만족만으로 좋은 플랫폼 소프트웨어로 인정받는 것은 불가능하다. 플랫폼 소프트웨어는 비기능적이면서 평가 기준 또한 모호한 척도를 함께 만족시켜야 하기 때문이다.

It might be controversial, but the most important non-functional requirement of a platform software is that 'it has to be easy'.

논란의 여지가 있겠으나, 내가 생각하는 플랫폼 소프트웨어의 가장 중요한 비기능적 요구 사항은 '쉬워야 한다'는 것이다.

'To be easy' means a lot of thing. It has to be easy to learn. It has to be easy to use once learned. It has to be easy to extend once got used to it. It has to be easy to migrate from the previous version when it is major-upgraded. Then what does 'easy to learn' mean? What about 'easy to use'? By the way, doesn't making something easy mean that we can't implement more advanced features? We become surrounded by endless questions.

쉽다는 것은 정말 많은 것을 의미한다. 배우기 쉬워야 한다. 한 번 배웠으면 쉽게 쓸 수 있어야 한다. 어느 정도 익숙해 지면 쉽게 기능을 확장할 수 있어야 한다. 플랫폼이 메이저 업그레이드 되었을 때는 쉽게 마이그레이션이 가능해야 한다. 그렇다면 배우기 쉽다는 건 무엇인가? 쉽게 쓸 수 있다는 것은? 그런데 쉽게 하다 보면 고급 기능을 구현하지 못하는 것은 아닐까? 끝도 없는 질문에 둘러싸이게 마련이다.

We have to answer all the questions, and they can't be answered without tremendous effort, which is sometimes called 'fastidius'.

우리는 그 질문에 정확히 대답하지 않으면 안된다. 그리고 그 대답은 결벽증에 가까운 노력 없이 얻을 수 없다.

The typical example of such an effors is perfect understanding and proficiency of the programming language the platform software depends on, convention and style of the language, every feature that standard SDK provides. It is different from understanding business domain. This means developing a platform software is a procedure that solves two problem domains; business domain and platform software API design domain.

그러한 노력의 대표적인 예가 플랫폼이 기반한 언어와, 그 언어의 상황에 따른 컨벤션과 스타일, 표준 SDK가 제공하는 모든 기능에 대한 완벽한 이해와 숙달이다. 이는 업무 도메인에 대한 숙지와는 다르다. 즉, 플랫폼 소프트웨어 개발은 두 개의 영역 - 업무 영역과 플랫폼 API 디자인 영역 - 을 동시에 해결하는 과정이다.

The biggest problem is that recognizing and fixing an API design problem is very diffucult to overcome as long as a platform software developer doesn't recognize the problem by his own self due to the nature of the problem, while the lack of business domain knowledge can be pointed out and fixed easily. That's why a great application developer often creates an over-complex platform software which causes ironically declining productivity.

문제는 업무 영역에 대한 이해 부족은 개발 과정에서 쉽게 드러나고 극복되는 반면, 플랫폼 API 디자인 영역에 대한 문제 제기와 해결은 영역 자체의 특성상 플랫폼 소프트웨어 개발자 스스로가 인식하지 못하는 이상 극복하기가 어렵다는 데 있다. 유능한 어플리케이션 개발자가 사용하기 불편한, 그래서 오히려 생산성을 저하시키는 플랫폼 소프트웨어를 만들어 내는 일이 심심찮게 발생하는 것은 그런 이유에서다.