디지탈 사시미 전략과 소프트웨어 개발

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

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

보통 소프트웨어의 품질 보증 과정에서 사용성 테스트는 개발 후 임의의 사용자들에게 특정 작업을 수행하게 하면서 이를 녹화하거나 기록하여 문제점을 찾은 후 사용성을 개선한다. 또한 기능상의 버그는 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% 믿지 않는다. 소프트웨어의 특성상 시간이 지날 수록 많은 사용자의 요구사항이 반영되고 버그를 수정하는 작업 등을 통해 코드는 보기에 지져분 해 질 수 있다. 그러나 이 코드는 그 만큼 버그가 적으며 안정화된 코드이다. 일반적으로 다시 개발된 코드는 같은 시간 많큼의 안정화 기간을 거쳐야 비슷한 품질을 제공하는 수준에 도달한다. 소프트웨어도 사람이기 때문이다. 물론 그렇기 때문에  많은 편차도 존재한다.

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