만약 여러분이 어떤 제품의 개발 책임자라고 상상해 보자!

불행하게도 이미 경쟁 제품은 시장에서 발표가 되어 선풍적인 인기를 끌고 시장을 잠식하고 있는 상태이다. 경쟁 상대가 새로운 제품을 출시하기 전까지 여러분은 경쟁 제품을 출시해야 만 한다. 주어진 시간은 턱없이 짧고 준비도 완벽하지는 않다. 품질을 고민하면 개발 기간은 턱없이 부족하고 , 시장을 생각하면 무리수를 두더라고 짧은 기간 내에 제품 개발을 완성해야 한다.

아마 이러한 상황은 국내에서 작던 크던 다양한 규모의 개발 조직을 이끄는 많은 분들이 겪는 어려움일 것이다. 물론 정답이 있는 것은 아니지만 분명 국내와 국외의 문화와 정서는 무척 다른 것 같다. 필자의 경험상 국내의 경우 품질 보다는 빠른 상품 출시를 위한 속도를 더 중요하게 생각한다. 여러 이유가 있겠지만 사회.문화적으로 과거 압축 성장을 통해 한강의 기적이라는 경제 성장을 경험했던 기성세대가 구축한 기업들 입장에서 시간이라는 변수 다시 말해 속도전은 의지를 통해 충분히 극복할 수 있다 라는 환상이 가장 큰 이유가 아닐 까 싶다.

과거 2년 전 쯤 , 고려대학교 장세진 교수 의 "삼성과 소니" 라는 책을 읽은 적이 있다. 이 책을 보면 과거 삼성전자의 윤종용 부회장이 주창한 디지털 사시미 전략이라는 것이 눈에 띈다. 디지털 사시미 전략은 한 마디로 “사시미에서 휴대폰에 이르기까지 모든 일상제화에 공통적으로 적용되는 핵심으로 아무리 비싼 사시미라도 시간이 지나면 가격이 떨어지듯이 디지털 제품의 재고는 치명적이기 때문에 스피드가 모든 것이고 가장 중요한 것”이라는 얘기다. 제품 생산에서 부터 판매에 이르기까지 속도를 강조한 전략이다.

그렇다면 온라인 서비스나 소프트웨어 제품에 있어서 스피드는 과연 어떤 요소일까? 특히, 품질과는 어떠한 상관 관계가 있을까?

물론 다른 제품과 마찬가지로 소프트웨어와 서비스에게 품질과 스피드는 모두 중요한 경쟁 요소이다. 아무리 잘 만든 소프트웨어도 이미 다른 제품이 시장을 선점했다면 시장 진입시 어려울 수 밖에 없다. 따라서 치열한 경쟁을 위해서는 속도전을 펼칠 수 밖에 없다. ( 물론 이러한 소프트웨어의 속도전 이면에는 품질 문제와 개발자의 희생이라는 문제가 숨어 있을 수 밖에 없다. 마치 과거 한강의 기적이라는 압축 성장의 이 면에 많은 사람들의 희생이 있었듯이 말이다. )

그러나 이러한 속도전과 더불어 가장 중요한 부분은 품질 문제이다. 아무리 빨리 시장에 서비스와 제품을 출시해도 품질 상에 문제가 있다면 결코 성공할 수 없다. 그렇다면 소프트웨어와 서비스를 개발하는 데 있어 어떻게 품질을 만족 시켜 내면서 속도전을 펼칠 수 있을까? 특히, 소프트웨어와 서비스에 있어 품질이라는 것은 단순히 버그나 오류같은 기능적 결험 수준만을 말하는 것이 아니다. 기능적 품질외에 제품의 사용성(Usability)이라는 아주 중요한 것을 포함하고 있다. 사용성은 사용자 입장에서 원하는 기능과 서비스를 손쉽게 찾아서 활용할 수 있도록 제공하는 가를 말한다.

일반적으로 소프트웨어의 품질보증 과정에서 사용성 테스트(Usability Test)는 개발 후 임의의 사용자들에게 특정 작업을 수행하게 하면서 이를 녹화하거나 기록해 문제점을 찾은 후 사용성을 개선한다. 또한 기능상의 버그는 개발자의 1차 단위 테스트 후 빌드가 나오면 이를 전문 품질관리팀을 통해 검사한 후 일정 수준까지 반복적으로 품질을 개선한다. 이러한 복잡한 과정들과 많은 비용과 시간을 투자한 후 제품을 출시한다.

최근 들어서는 이러한 품질과 사용성 테스트에도 변화가 있다. 바로 알파 공개, 베타 공개(테스트)란 형태를 통해 공개적으로 진행되고 있는 것이다. 최초 소수의 매니아를 대상으로 한 알파 단계를 통해 해당 서비스의 사용성과 품질을 향상 시킨 후, 이를 베타 수준으로 공개한다. 이 후, 주 단위나 심지어 일 단위로 품질과 사용성을 개선하여 사용자에게 최적화된 서비스와 소프트웨어를 제공한다.

스피드와 품질은 이러한 소프트웨어 사업의 숨은 경쟁력이다. 현 상황에서 스피드가 늦은 소프트웨어와 서비스는 절대 성공할 수 없다. 경쟁없는 상황은 상상할 수 없다. 경쟁이야 말로 발전의 원동력이다. 경쟁을 가장 잘 활용하고 있는 분야가 바로 스포츠다. 축구나 야구에서 특정 포지션의 주전 경쟁은 경쟁하는 사람에게는 피말리는 일이겠지만 전체 팀장 입장에서는 팀원의 능력을 배가 할 수 있는 가장 적극적인 방법이다.

물론, 이 과정을 통해 경쟁하는 사람도 발전을 한다. 한 사람의 페이스가 떨어지거나 다른 사람이 치고 올라오면 기회를 잃게 된다. 이 과정에서 중요한 것은 바로 스피드다. 빠른 시간내에 자신의 능력을 보여주어야만 경기에 출전을 할 수 있다. 출전 기회를 못 잡으면 경쟁에서 멀어지게 되고 결국은 낙오하게 된다.마찬가지로 온라인 서비스나 소프트웨어 분야에서도 마찬가지다. 경쟁업체보다 빠르고 신속하게 제품과 서비스를 업데이트 해야 하며, 신규 기능과 서비스를 지속적으로 보여줘야 한다. 보여주지 못한다면 결국은 낙오하게 된다.

서비스와 소프트웨어 개발에 있어 시간을 줄일 수 있는 방법에 대해 고민해 보자. 물론 시간을 줄인다고 해서 품질까지 떨어뜨린 다는 것은 절대 아니다. 품질과 사용자의 관심을 유지하는 것이 바로 스피드의 효과이다.

- 초기 지나친 인프라 구축 및 관리에 드는 비용과 시간을 줄여야 한다.

일반적으로 하나의 서비스를 개발하고 운영하기 위해서는 하드웨어 구매/설치/셋팅/튜닝, 개발 환경 셋팅, 서비스 오픈 후 시스템 모니터링 환경 구축,장애 조치 등 많은 인프라에 대한 투자가 필요하고 이를 안정시키는 데 많은 시간이 소요된다.

그러나 이렇게 많은 시간과 자본을 투자하는 것은 바보짓이다. 제대로된 S/W 아키텍쳐와 개발 플랫폼을 사용한다면 개발과 운영에 있어 큰 문제가 발생하지 않으며 이후 시스템을 확장할 때도 손쉽게 할 수 있다. 이런 사고는 과거 2000년 초반 닷컴 버블로 많은 투자 자금을 갖고 있었을 때의 이야기이다. 닷컴 버블 당시도 실제 돈을 번 업체는 썬마이크로시스템즈같은 하드웨어 판매업체와 망한 닷컴 회사들의 장비를 인수하여 중고로 매매하는 회사들이었다.

따라서 개발 환경과 운영 환경에 드는 비용과 시간을 최소화하는 것이 유리하다. 냉정하게 생각해 보면 성공 여부를 판단할 수 없는 제품과 서비스에 막대한 초기 투자를 하는 것은 어리석은 일이다. 아울러 일단 개발된 서비스는 서비스가 가능한 범위내에서 단계별(알파와 베타)오픈을 통해 안정화와 검증을 통해 단계별로 인트라에 투자하는 것도 방법이다.

현재 가장 좋은 방법은 바로 클라우드 컴퓨팅( Cloud Computing )을 이용하여 서비스를 구축하는 것이다. 아마존의 EC2 같은 IaaS(Infrastructure As A Service)나 구글 앱스 서비스 같은 PaaS(Platform As A Service) 을 이용하면 많은 투자를 하지 않더라도 안정적인 플랫폼에 서비스 등을 구축할 수 있다.

- 오픈 소스를 적극 활용한다.

제품 개발시 반드시 선행 작업으로 사용가능한 오픈소스와 이에 대한 사용 정책을 수립하는 것이 좋다. 경험적으로 볼 때 개발하고자 하는 제품에 필요한 많은 기반 라이브러리와 프래임웍 중 상당수는 오픈소스를 통해 얻을 수 있다.

오픈소스 활용시 반드시 점검해야 할 점은 첫째 , 오픈소스 커뮤니티의 활동 상황을 점검해야 한다. 해당 오픈소스 솔루션이 필요하더라도 커뮤니티를 통해 적극적으로 업데이트 되지 못한다면 현재 기능적으로 조금 부족하더라도 활성화된 오픈소스 솔루션을 선택하는 게 안정적이다. 또한 오픈소스의 경우 각기 다른 라이선스 정책을 갖고 있기에 패키지로 개발하여 배포할 경우와 서비스로 할 경우 등에 맞춰 미리 라이선스 문제를 검토하고 예상되는 문제를 해결해야 한다.

- 알파 및 베타 오픈을 적극 활용하며 개발의 라이프사이클을 줄여야 한다.

결코 한번에 완벽한 서비스와 패키지를 개발할 수 없다. 완성도를 높이기 위해서는 당연 시간이 필요하다. 이 때, 시간을 최소화하기 위해 단계별로 서비스를 오픈하면서 사용자의 불편함과 완성도를 높여야 한다.

가장 좋은 방법은 알파 오픈시 최소한의 얼리 아답터에게 서비스를 공개하고 이들로 부터 냉정한 평가를 받는 것도 좋은 방법이다. 단, 이렇게 얻어진 개선 사항은 최대한 빨리 개선해야 한다. 이런 방법으로 사용자를 확대하면서 서비스를 고도화함으로써 개발 시간을 단축하고 품질을 확보할 수 있다. 패키지도 마찬가지이다.메이저 버전과 마이너 패치 버전을 병렬적으로 수행할 수 있는 팀을 구성하여 운영하는 것도 시간을 줄여 경쟁력을 갖을 수 있는 방법중 하나이다.

- NIN 신드롬을 버려야 한다.

개발자는 누구나 NIH(Not invented here) 신드롬을 갖고 있다.

다시 말해 내가 직접 개발한 것 이외에는 신뢰하지 않는 다는 것을 말한다. 실제 특정 업무를 인수인계 받은 개발자들과 인터뷰를 해보면 이구동성으로 하는 말이 있다. – ” 정말 선임자가 거지 같이 코딩을 했네요. 다시 개발하는 게 낫겠어요”.

필자는 이런 말을 100% 믿지 않는다. 소프트웨어의 특성상 시간이 지날수록 많은 사용자의 요구사항이 반영되고 버그를 수정하는 작업 등을 통해 코드는 보기에 지저분 해 질 수 있다.그러나 이 코드는 그 만큼 버그가 적으며 안정화된 코드이다. 일반적으로 다시 개발된 코드는 같은 시간 만큼의 안정화 기간을 거쳐야 비슷한 품질을 제공하는 수준에 도달한다. 소프트웨어도 사람이 하는 작업이기 때문이다. 물론 그렇기 때문에 많은 편차도 존재한다.

개인적으로는 현재가 있어야 미래도 있다고 생각한다. 필자는 현재 많은 문제를 안고 있는 서비스와 소프트웨어 제품의 책임자들이 경쟁에서 승리하기 위해 현재의 문제 해결을 위해 주력해야 한다고 생각한다. 그것도 가장 스피드 있게. 그래야 미래도 있기 때문이다. 지금까지 언급한 내용이 정답은 아니더라고 소프트웨어와 서비스 개발시 스피드와 경쟁력, 그리고 품질 등에 대해서는 생각해 봐야 한다고 생각한다. 사용자는 기다려주지 않기 때문이다. 더불어 필자는 이러한 모든 작업이 개발자들의 자발적 참여를 전제로 한다고 생각한다. 만일, 개발자들의 비자발적 참여를 전체로 한다면 이 또한 다시 생각해야 할 것이다.

2010/03/21 - [ZDnet 컬럼] - 디바이스와의 대화
2010/04/10 - [ZDnet 컬럼] - 왜 개인용 클라우드를 주목하는 가?
2010/05/26 - [ZDnet 컬럼] - 웹의 관점에서 본 TV 시장의 미래
2010/08/27 - [ZDnet 컬럼] - 자동차에도 서비스 플랫폼이 필요하다.
2010/03/21 - [ZDnet 컬럼] - 디바이스와의 대화

[ 본 글은 ZDNet 컬럼에 기고한 글 입니다. ]

컴퓨팅 파워와 하드디스크 용량이 증가함에 따라 개인의 노트북과 데스크탑에 존재하는 정보의 양도 기하급수적으로 함께 늘고 있다.  현재 개인적으로 사용하고 있는 노트북의 경우 200G HDD인데 거의 80% 정도 데이타가 쌓여 있다. 사실 이들 정보 중 찾지 못해서 제대로 이용하지 못하는 정보도 상당수 존재한다. 이러한 문제를 해결할 수 있는 방법으로 구글이나 네이버 같은 검색 업체는 데스크탑 검색 프로그램을 무료로 제공하고 있다. 개인적으로 이들 프로그램이 유용하기는 하지만 색인 과정에서 발생하는 CPU의 Load와 색인 파일의 크기 때문에 별로 선호하지는 않는다.

- 디렉토리와 폴더에 의한 파일 검색

과거 가장 유용하게 파일을 분류.활용하는 방법이 바로 사용자가 자신의 입맛대로 폴더와 디렉토리를 생성하고 이를 잘 분류하여 사용하는 것이었다. 가장 손쉬운 방법이지만 정보가 많아지면 원하는 정보를 찾기가 만만치 않다. 아마도 얼마지나지 않아 "  아니 그 파일이 그게 어디 있더라?" 내지는 기억하지 못해 다시 관련된 정보를 인터넷에서 검색하는 경우가 반복될 가능성이 크다. ( 나만 이런가? ^-^ )  이러한 방법은 실제 정보를 물리적인 분류(디렉토리와 폴더)로 매핑시키고 이를 통해 찾는 것이다. 과거에 기억으로 지식관리 시스템에서 이를 물리적인 맵(Physical Map)이라고 하고 개발했던 적이 있었는데 그다지 감동적인 방법은 아니었다.

- 태그 등 논리적인 방법에 의한 파일 분류 및 검색

보통 하나의 정보는 그 의미에 따라 여러 분류를 갖는다.  가령, Voip 기술이 모바일 시장에 미치는 영향 이란 보고서는 [ 기술 -> Voip ] 디렉토리에 속할 수도 있지만 [ 시장 동향 -> 모바일 시장 ]에 속할 수도 있다. 이 경우, 물리적인 맵으로는 파일을 복사하여 두 개의  폴더에 중복해서 둘 수 밖에 없다. 이러한 것을 피하기 위해 과거 지식관리 시스템에서 하나의 물리적인 파일(정보)에 여러 논리적인 맵을 매핑하는 1 :   N 매핑을 사용하였다. 이러한 방법을 맵 형태로 구현할 경우 논리 지식맵이 되고 , 일반 텍스트 나열 방식으로 구현하면 흔히 말하는 태그라 말 할 수 있다.

이러한 물리적인 방법과 논리적인 방법은 혼합되어 사용되어 질 경우 정말로 대량의 파일을 관리할 때 편하게 사용할 수 있다. 실제 , 이 방식으로 크게 성공한 회사는 바로 애플과 구글이다.
 
- 애플의 소프트웨어의 사용성은 검색에서 시작해서 검색으로 끝난다.

애플이 제공하는 소프트웨어는 대부분 스마트 분류와 검색을 제공한다. 여기서 스마트 분류와 검색이란 파일은 하나만 존재하지만 여기에 다양한 분류 기준과 검색 기준을 제공하여 논리적인 폴더를 구성하게 해주는 기능을 말한다.

가령, 애플은 윈도우의 탐색기에 해당하는 파인더라는 유틸리티를 제공한다. 파인더는 스마트 폴더라는 것을 제공하는 데 , 스마트 폴더는 특정 범위에 있는 문서의 제목이나 내용 중 특정 내용을 포함하는 문서들만을 논리적으로 구성하여 디렉토리처럼 관리할 수 있다. 가령, 아래 그림 처럼 파일 중  thinkfree가 제목이나 내용에 포함되어 있는 파일들만을 논리적으로 구성하여 왼편의 맵(사이드바)에 추가하여 파일을 활용할 수 있다.


또한 메일에서도 스마트 메일 상자라는 기능을 제공하는 데 수신되는 메일 중 특정 조건에 해당하는 메일을 논리적으로 분류하여 관리할 수 있다. 가령, 외부 웹2.0 관련된 그룹에서 오는 메일들을 분류하여 관리할 수 있다.



사진 또한 마찬가지 이다. 스마트 앨범이라는 기능을 제공하여 사진의 속성별(앨범,모든 텍스트,....,제목)로 기준을 정해 놓고 이들을 논리적으로 구분하여 관리할 수 있다.


이러한 사용성이 가장 극대화하여 효과를 본 프로그램은 아이튠이다. "아이튠의 스마트 재생 목록"은 39개의 음악 파일의 속성을 AND 나 OR로 조합하여 검색한 음악 파일을 가상 폴더를 만들어 분류하여 관리할 수 있다. 이렇게 분류한 가상 폴더를 아이팟에 바로 동기화하여 휴대할 수 있으니 사용자 입장에서는 대량의 음악 파일을 관리하는 데 있어 기존의 폴더 폴더 방식 보다 편리할 수 밖에 없다. 그냥 연결하면 자동으로 원하는 파일이 항상 동기화가 된다.


- 구글 서비스의 사용성은 검색에서 시작해서 검색으로 끝난다.

애플이 데스크탑상에서 검색 기능을 활용해서 멋진 소프트웨어를 개발했다면 웹에서는 구글이 이러한 기능을 자사 서비스에 적극 채용하여 사용자를 감격하게 만든다.

G메일은 대용량 메일을 제공한다. 사용자는 대용량 메일을 마치 메일 아키이브로 사용한다. 나도 거의 모든 메일을 Gmail로 포워딩한 후 이를 저장해 둔다. 이렇게 보관된 메일을 분류하여 찾는 것은 무척 어려운 일이다. 그러나 G 메일에서는 너무도 쉽다. 라벨(태그)을 만들고 이를 이용하여 수신된 메일에 대한 필터를 만들면 해당 메일이 자동으로 분류되기 때문이다. 애플의 스마트 메일상자와 동일한 기능을 제공한다.


구글 리더 또한 마찬가지이다. 태그를 명시하고 구독하는 블러그에 태그를 명시하면 모든 분류가 해결된다.


구글 Docs 또한 "Search Options"이란 기능을 통해 문서에 대한 검색을 하고 이를 가상 폴더로 만들 수 있다.


특히, 웹 서비스의 경우 Ajax 프로그래밍은 이러한 기능을 구현하는 데 아주 적합하다.  구글의 서비스들이 그러한 사실을 잘 증명한다. Ajax를 마치 윈도우 프로그래밍이나 자바 스윙 프로그래밍처럼 생각할 경우 심각하게 이기적인 서비스를 개발하게 된다. 이후에 Ajax를 사용하여 개발한 이기적인 서비스에 대해서는 다시 언급하기로 한다.

- 새로운 소프트웨어 개발에서 사용성은 검색에서 시작해서 검색으로 끝나야 한다.

현재의 소프트웨어와 서비스는 대량의 정보를 생성,분류,검색,공유 하는 기능을 효율적으로 제공하고  있다. 이미 과거의 경험에서 우리는 대용량 정보 분류와 검색에서 더 이상 물리적인 폴더와 디렉토리 만으로는 만족할 수 없다는 사실을 알았다. 따라서 이들 방법외에 논리적인 분류와 검색 방법을 효과적으로 제공해야 한다. 개인적으로 이들 기능은 모든 소프트웨어와 서비스들의 기본 기능 중의 하나라고 생각한다.

실제, 다음의 항목들은 정보의 속성들이다. 이러한 속성을 이용하여 다양한 논리적인 검색과 가상의 폴더를 만들어 활용할 수 있다.

파일 타입 , 파일 명, 파일 크기 , 작성 일, 최종 수정일 , 태그 , 작성자 , (협업 시) 공동 작업자 ,버전 정보 , 코멘트 , 중요도 그리고 본문 , 폴더 명, 폴더 위치(웹 또는 데스크탑 또는 모바일 ),...

예를 들어,  C 드라이브에 있는 정보중 파일 타입은  HWP 이고 2008년에 작성한 문서들 중에서 박재현과 그의 패밀리들이 작성한 파일을 모으되 웹 오피스와 씽크프리가 들어가 있는 문서들. 이런 기능은 오피스 프로그램에 반드시 필요한 것이다. 마찬가지로 다른 분야에서도 기본적으로 필요하다.

이러한 생각을 아주 제대로 반영한 훌륭한 프로그램이 있어 소개한다. Leap가 바로 이러한 생각을 가장 잘 반영한 프로그램이다. 지난 주 사용하던 맥의 파일 시스템이 깨져서 시스템을 새로 정리하던 중에 발견한 프로그램으로 사용하면 할 수록 감탄이 나왔다. 아쉽게도 맥버전만 제공하기 때문에 윈도우에서는 이용할 수 없다.


물리적인 맵과 태그,  파일 속성에 기반한 논리적인 맵을 기준으로 한 실시간 검색을 제공한다. 기존의 데스크탑 검색 프로그램처럼 전문 검색을 위해 비싼 색인 과정도 없다. 파일 타입 등의 속성과 태그 그리고 물리적인 위치 등을 조합하여 바로 원하는 문서를 찾을 수 있다. 화면의 오른쪽에 위치한 태그 생성기는 파일을 드래그하여 놓으면 관련된 태그를 입력하는 창이 나온다. 이 창에 태그를 입력하면 태그가 생성된다. 다소 아쉬운 것은 이렇게 찾은 문서를 논리적인 폴더로 구성(저장)할 수 없다는 것이다. 이 점을 제외하고는 직관적인 UI를 포함하여 아주 멋진 소프트웨어이다. 개인적으로는 웹 서비스 또는 응용 프로그램의 기획자나 개발자가 꼭 한번 사용해 보고 기억해 두는 것이 좋은 사례라 할 수 있다. 아마도 당분간 새로운 충격이 없는 한 새롭게 구상하는 프로그램은 이러한 프레임웍 기반으로 하게 될 것 같다^^.

Why software sucks... and what you can do about it

이 책에서 주장하는 것을 간략히 정리하면 ,
S/W에 있어 사용성은 무척 중요하다. 그런데 괴짜들인 개발자는 사용자를 위한 사용성에 크게 신경쓰지 않는다. 자기가 만족하면 OK다. 사용성 개선을 위해 사용자들은 개발자와 회사에 무엇이 불편한지 이야기를 해야 한다고 시종일관 강조하고 있다. 심지어 자신이 만든 suckbusters.com에 의견을 모아 집단적으로 의견을 전달하자고 말하고 있다. 

책을 한마디로 평가하면 제목만큼 올해 읽은 책중 가장 개떡(?,책의 제목을 인용한 것이니 오해마세요^-^)같은 IT 관련 서적이 아닌가 싶다. 일반 사용자들이 읽기에는 다소 전문적인 반면, 개발자들과 관련자들이 읽기에는 너무 평이한 내용이 아닌가 싶다. 아니 기대했던 내용을 전달받지 못했다. 이러한 생각이 들기까지 책을 정독하고 나중에 다시 한번 읽으면서 내가 잘못 이해하는 부분이 있나? 라고 반문을 했었다.

처음 책을 접하고 기대했던 내용은 말 그대로 S/W와 서비스들중 개떡같이 만든 것들을 좀 열심히 비판(내지 비난)하고 많은 생각을 하게 만드는 것을 기대했는데 원하는 것은 접할 수 없었던 것 같다. 물론 책의 초반부에 언급된 개떡같은 소프트웨어들의 사용성에 대한 문제에 대해서는 동의한다. 당연하고 일반적인 이야기이기 때문이다. 그러나 중반 이후 저자는 소프트웨어 개발자가 괴짜고 그러하기 때문에 이러하다라는 것을 시종일관 말하고 있다.  두서없는 전개에 주제에 집중할 수 없는 복잡한 내용들이 무척 혼란스럽다.

가십과 관심을 끌기위한 책인가 ? 아니면 숨어있는 어떤 통찰력이 뛰어난 멋진 서술인가? 라는 판단을 좀 더 하기 위해 블로그를 뒤져 보았다. 여러 평가들이 보인다.

긍정적인 평가
http://inuit.co.kr/1457
http://www.buggymind.com/127
http://dobiho.com/?p=945
http://ggaman.com/tt/900

부정적인 평가
http://www.cozydev.com/51, 행복한 개발을 위한 블러그
http://wisefree.tistory.com , ^-^

아마 나도 부정적인 평가를 내린 사람중의 하나인 것 같다.

과거 죠엘의 블러그를 읽으면서 그의 해박한 경험을 전달받으며 느꼈던 감정을 기대했었는데 좀 아쉽다.  혹 , 개발자로서 사용성에 대한 경험이 필요한 분들은 죠엘의 블러그를 참고하길 바란다. 그리고 사용성에 대한 정보가 필요한 개발자나 기획자는 Jakob Nielsen의 블러그가 많은 도움이 될 것이다. 그리고 번역서로는 스티브 크룩의 『Don't Make Me Think 2/e』의 한글판인 상식이 통하는 웹사이트가 성공한다(2판) 상세보기 가 많은 도움이 될 것이다. 출판된 책보다는 온라인 블러그가 보다 현실적인 정보를 제공하는 것 같다. 아마도 이 책이 나오기까지의 시간동안 웹이 너무도 빨리 변하는 듯하다.

그리고 나는 소프트웨어 개발자를 괴짜라 생각하지 않는다. 그저 평범한 사람이다. 물론 개중에는 본인이 특별하다고 생각하는 개발자가 있을 수 있지만 소수라고 생각한다. 단지 새로운 것을 좋아하고 이를 받아들이는 데 일반인보다 적극적인 사람들이 개발자가 아닌가 생각한다.  힘들어도 평생 새로운 기술을 접해야만 먹고 살 수 있는게 바로 개발자란 직업이다. 오히려 이 책의 저자가 지적한 사용성의 문제는 개발자들의 문제가 아니라 소프트웨어를 포함한 모든 재화(commoditization)에 해당하는 것 같다. 항상 최초의 재화는 부족하고 모자라다. 문제는 얼마나 빨리 이것을 채우는 것인가가 경쟁력이고 이러한 회사들 만이 살아남는다.

고려대학교 장세진 교수 의 삼성과 소니 라는 책을 보면 디지탈 사시미 전략이라는 것이 눈에 띤다.  디지탈 사시미 전략은 삼성전자 윤종용 부회장이 주창한 이론으로 "사시미에서 부터 휴대폰에 이르기까지 모든 일상제화에 공통적으로 적용되는 핵심으로 아무리 비싼 사시미라도 시간이 지나면 가격이 떨어지듯이 디지털 제품의 재고는 치명적이기 때문에 스피드가 모든 것이고 가장 중요한 것이다" 라고 말한다.


그렇다면 온라인 서비스나 소프트웨어 제품에 있어서 스피드는 어떤 요소일까? 개인적인 생각으로 품질과 스피드야 말로 현재 시점에서 가장 중요한 경쟁 요소라고 생각한다. 물론 품질에서 가장 중요한 요소는 사용성이라고 생각한다.

보통 소프트웨어의 품질 보증 과정에서 사용성 테스트는 개발 후 임의의 사용자들에게 특정 작업을 수행하게 하면서 이를 녹화하거나 기록하여 문제점을 찾은 후 사용성을 개선한다. 또한 기능상의 버그는 QA(Quality Assurance) 과정을 통해 수정된다. 이러한 복잡한 과정들을 통해 제품이 출시된다. 그러나 실제 QA에 비해 사용성 테스트는 제대로 진행되지 않는 것이 현실이기도 하다. 실제 사용성 테스트를 보다 잘하는 회사는 개발 후가 아니라 개발 전 단계에서 이를 수행한다고 한다. 또한 품질 관리는 개발자의 1차 단위 테스트 후 빌드가 나오면 이를 전문 품질 관리팀을 통해 검사한 후 일정 수준까지 반복적으로 품질을 개선한다.  이러한 사용성 테스트와 일정 수준 이상의 품질을 확보하기 위해서는 많은 시간과 비용이 발생한다. 최근 들어서는 품질과 사용성 테스트에도 변화도 있어 보인다. 바로 알파 공개, 베타 공개(테스트)란 형태를 통해 공개적으로 진행되고 있고 있는 것이다.  최초 소수의 매니어를 대상으로 한 알타 단계를 통해 해당 서비스의 사용성과 품질을 향상 시킨 후 , 이를 베타 수준으로 공개한다. 이 후 , 주단위나 심지어 일단위로 품질과 사용성을 개선하여 사용자에게 최적화된 서비스와 소프트웨어를 제공한다.

스피드는 이러한 소프트웨어 사업의 숨은 경쟁력이다. 현 상황에서 스피드가 늦은 소프트웨어와 서비스는 절대 성공할 수 없다.

경쟁없는 상황은 상상할 수 없다. 경쟁이야 말로 발전의 원동력이다. 경쟁을 가장 잘 활용하고 있는 분야가 바로 스포츠다. 축구나 야구에서 특정 포지션의 주전 경쟁은 경쟁하는 사람에게는 피말리는 일이기겠지만 전체 팀장에서는 능력을 배가 할 수 있는 가장 적극적인 방법이다. 물론, 이 과정을 통해 경쟁하는 사람도 발전을 한다. 한 사람의 페이스가 떨어지거나 다른 사람이 치고 올라오면 기회를 읽게된다. 아주 앞서기 까지는 이러한 경쟁이 계속된다. 이 과정에서 중요한 것은 바로 스피드다. 빠른 시간내에 자신의 능력을 보여주어야 만 출장할 수 있다. 출장 기회를 잡지 못하면 경쟁에서 멀어지게 되고 결국은 낙오하게 된다. 참고로 아래 사진은 프로야구 투산 베어스의 유격수 자를 놓고 경쟁하고 있는 선수들이다. 분명 어디선가 이들 자리를 노리는 신인이 지금도 땀을 흘리고 있을 것이다.^-^



이는 마찬가지로 온라인 서비스나 소프트웨어 분야에서도 마찬가지이다. 경쟁업체보다 빠르고 신속하게 제품과 서비스를 업데이트 해야 하며 , 신규 기능과 서비스를 지속적으로 보여줘야 한다. 보여주지 못한다면 결국은 낙오하게 된다. 

서비스와 소프트웨어 개발에 있어 시간을 줄일 수 있는 방법에 대해 고민해 보자. 물론 시간을 줄인다고 해서 품질까지 떨어뜨린 다는 것은 절대 아니다. 최대한 스펙과 시간을 줄여 사용자의 관심을 유지하는 것이 바로 스피드의  효과이다.

- 초기 지나친 인프라 구축 및 관리에 드는 비용과 시간을 줄여야한다.
일반적으로 하나의 서비스를 개발하고 운영하기 위해서는  하드웨어 구매/설치/셋팅/튜닝, 개발 환경 셋팅 , 서비스 오픈 후 시스템 모니터링 환경 구축,장애 조치 등 많은 인프라에 대한 투자가 필요하고 이를 안정하시키는 데  많은 시간이 소요된다. 그러나 이렇게 많은 시간과 자본을 투자하는 것은 바보짓이다. 제대로된 S/W 아키텍쳐와 플랫폼을 사용한다면 개발과 운영에 있어 큰 문제가 발생하지 않으며 이후 시스템을 확장할 때도 손쉽게 할 수 있다. 이런 사고는 과거 닷컴 버블로 많은 투자 자금을 갖고 있을 때의 이야기이다. 당시도 실제 돈을 벌은 업체는 선 마이크로시스템즈같은 하드웨어 판매업체와 망한 닷컴 회사들의 장비를 인수하여 중고로 매매하는 회사들이라고 한다. 따라서 개발 환경과 운영 환경에 드는 비용과 시간을 최소화하는 것이 유리하다. 냉정하게 생각해 보면 성공 여부를 판단할 수 없는 제품과 서비스에 막대한 초기 투자를 하는 것은 어리석은 일이다. 아울러 일단 개발된 서비스는 서비스가 가능한 범위내에서 단계별(알파와 베타)오픈을 통해 안정화와 검증을 통해 단계별로 인트라에 투자하는 것도 방법이다. 또 하나의 방법으로 최근 들어 각광받고 있는 PaaS(Platform As A Service)를 이용하여 서비스를 개발하는 것도 좋은 방법이다. 가령, 구글의 PaaS 서비스인 구글 앱스 앤진을 이용하면 왠만한 서비스는 최소한의 비용과 시간으로 서비스를 개발 운영할 수 있다. 

2008/05/23 - [SaaS] - 무비용 창업 노하우 , PaaS
2008/06/12 - [SaaS] - Platform As A Service 리뷰
2008/05/22 - [SaaS] - 차세대 웹 애플리케이션 개발 플랫폼 , PaaS


- 오픈 소스를 적극 활용한다.
제품 개발시 반드시 선행 작업으로 사용가능한 오픈소스와 이에 대한 사용 정책을 수립하는 것이 좋다. 경험적으로 볼 때 개발하고자 하는 제품에 필요한 많은 기반 라이브러리와 플랫폼중 상당수는 오픈소스를 통해 얻을 수 있다. 이 때, 함께 생각해야 할 점은 이들 오픈소스의 경우 각기 다른 라이센스 정책을 갖고 있기에 패키지로 개발하여 배포할 경우와 서비스로 할 경우 등 에 맞춰 미리 라이센스 문제를 해결해야 한다. 개인적으로도 한참 시간을 들여 개발중인 모듈이 오픈 소스 라이브러리로 대체되면서 우울했었다^-^. 다시는 생각도 하기 싫타.. 그 시간에 다른 걸 했으면...

- 알파 및 베타 오픈을 적극 활용하며 개발의 라이프사이클을 줄여야 한다.
결코 한번에 완벽한 서비스와 패키지를 개발할 수 없다. 완성도를 높이기 위해서는 당연 시간이 필요하다. 이 때, 시간을 최소화하기 위해 단계별로 서비스를 오픈하면서 사용자의 불편함과 완성도를 높여야 한다. 가장 좋은 방법은 알파 오픈시 최소한의 얼리 아답터에게 서비스를 공개하고 이들로 부터 냉정한 평가를 받는 것도 좋은 방법이다. 단 , 이렇게 얻어진 개선 사항은 최대한 빨리 개선해야 한다. 이런 방법으로 사용자를 확대하면서 서비스를 고도화함으로써 개발 시간을 단축하고 품질을 확보할 수 있다. 패키지도 마찬가지이다. 메이저 버전과 마이너 패치 버전을 병렬적으로 수행할 수 있는 팀을 구성하여 운영하는 것도 시간을 줄여 경쟁력을 갖을 수 있는 방법중 하나이다. 


- NIH 신드롬을 버려야 한다.
NIH(Not invented here)신드롬은 내가 개발한 것 이외에는 신뢰하지 않는 것을 말한다. 개인적으로 특정 업무를 인수인계 받은 개발자들과 인터뷰를 해보면 이구동성으로 하는 말이 있다. - " 정말 선임자가 거지 같이 코딩을 했네요" . "다시 개발하는 게 낳겠어요". 나는 이런 말을 100% 믿지 않는다. 소프트웨어의 특성상 시간이 지날 수록 많은 사용자의 요구사항이 반영되고 버그를 수정하는 작업 등을 통해 코드는 보기에 지져분 해 질 수 있다. 그러나 이 코드는 그 만큼 버그가 적으며 안정화된 코드이다. 일반적으로 다시 개발된 코드는 같은 시간 많큼의 안정화 기간을 거쳐야 비슷한 품질을 제공하는 수준에 도달한다. 소프트웨어도 사람이기 때문이다. 물론 그렇기 때문에  많은 편차도 존재한다.

개인적으로는 현재 성공을 해야 미래도 있다고 생각한다. 나는 현재 많은 문제를 안고 있는 서비스와 소프트웨어 제품의 책임자들이 경쟁에서 승리하기 위해 현재의 문제 해결을 위해 주력해야 한다고 생각한다. 그것도 가장 스피드 있게. 그래야 미래도 있기 때문이다. 지금까지 언급한 내용이 정답은 아니더라고 스피드와 경쟁력에 대해서는 생각해 봐야 한다고 생각한다. 사용자는 기다려주지 않기 때문이다.