작은 것이 아름답다.

“이 기능을 넣어, 말어?”

소프트웨어를 만들면서 쉽게 빠지는 딜레마다. 소프트웨어 피드백(feedback)을 듣기 위해 사용자들을 만나보면, 꼭 마무리는 “이런 기능을 넣어주세요”로 끝나는 것 같다. 문제는 사용자들이 원하는 기능이 사용자가 정말로 원하는 것이 아닌 경우가 많다는 것이다. 애써 기능을 구현해서 넣었는데, 이 기능이 잘 안쓰이면 마음이 상하는 것도 있지만, 사실 이보다 큰 문제점이 슬슬 발생한다.

먼저, 품질(quality)이 저하된다. 소프트웨어는 그 형태가 패키지가 되었든, 또는 서비스가 되었든, 결국은 작은 기능(feature)들의 집합니다. 이 기능들은 독립적으로 존재하는 것이 아니라, 각각이 유기적으로 연결되어, 소프트웨어가 달성하고자 하는 목적(mission)을 위해 동작한다. 때문에 하나의 기능은 다른 기능에 의존적일 수밖에 없다. 프로그래머가 기능을 하나 추가할 때, 그 기능 하나로서는 온전하더라도, 다른 기능하고 부조화를 이루거나 모순이 되면서 사용자를 혼란스럽게 만들기도 한다. 소프트웨어 규모가 커지고, 모듈마다 담당자가 다르게 되었을 때, 리더가 잘 신경쓰지 않으면 흔히 볼 수 있는 현상이다.

그리고, 테스트 관점에서도 적잖히 부담히 된다. 기능을 1개 추가할 때 사용 시나리오(user scenario) 1개가 더해지는 것이 아니다. 다른 기능과의 관계에 따라 차이가 있겠지만, 기본적으로 전체 기능의 수에 어느정도 비례하여 증가한다. 따라서, 테스트 해야할 경우(test case)도 전체 기능 수에 비례해서 증가하고, 버그가 생길 가능성도  마찬가지다.

또 진화적인 관점에서도 문제가 될 수 있다. 나는 소프트웨어는 시장 상황에 맞게 변해가야만 하는 운명을 짊어지고 있다고 생각한다. 기술 트렌드는 시시각각 빠르게 변화하고 있고, 사용자들의 원하는 것은 항상 변화한다. 웹 서비스나 소프트웨어 솔루션, 심지어 임베디드 소프트웨어까지도 빠르게 사용자의 요구사항을 반영하는 것을 당연시하게 여기고 있으며, 이를 못하면 도태된다. (일부 휴대폰 제조사에서 안드로이드 platform 업그레이드를 차일피일 미루다가 블로거들과 사용자들로부터 뭇매를 맞은 것을 보라) 그런데 기능이 많다보면, 사용자들의 요구사항을 빠르게 반영하기가 힘들다.  새로운 기술을 이용하여 기존의 기능들을 변경한다던지, 새로운 개념을 도입하는데 걸리는 시간과 난이도는 분명 그 기능의 수와 복잡도에 비례하기 때문이다.

결국은 소프트웨어는 그 목적(mission)을 명확히 하고, 그것을 달성하기에 필요한 기능들만 가져야 한다. 이 기능들을 품질 속성(quality attribute-usability, performance, availability, reliability 등)을 만족시키면서 구현할 때, 사용자로부터 지속적으로 사랑받을 수 있을 것이다. Google, Facebook, Twitter 등은 이를 분명히 인식하고 서비스를 만들어서 성공하고 있는 것이 아닐까 한다.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s