지난 주 오랜만에 대학원 시절 , 랩에서 함께 생활하던 식구들을 만났습니다.  벌써 2008년 이니 16년 전 일인것 같습니다. 같이 랩에서 세미나를 하고 , 짬짬히 마시던 우유팩으로 컵차기를 하던 동료들이 벌써 다들 고참 개발자가 되어 있었습니다.

저는 랩을  졸업하고 대기업을 거쳐 창업의 길을 걸었고 , 랩 식구들은 석.박사 과정을 마치고 의기투합 1999년 7월 포항공대 창업교육센타내에서 넷쓰루라는 회사를 창업하였습니다. 벌써 2008년 이니 창업한 지 9년이 된  고참 솔루션 벤처가 되었고  국내에서 웹 로그 분야에서는 자리를 잡은 것 같습니다.

넷쓰루의 멤버들은 본래 랩에서 인공지능과 마이닝, DBMS 를 전공했기 때문에 로그 분석이나 마이닝에 대해서는 국내에서는 뛰어난  기술을 갖고 있습니다. 이들이, 국내에서 로그 분석기와 마이닝 엔진을 개발,출시하고 외산에 맞서 경쟁을 한 지 9년이 되었습니다. 지난 9년 이란 세월동안 겪은 벤처 생활을 소주잔을 기울이며 오가는 말속에서 가슴깊이 느낄 수 있었습니다. 다행히다 이미 몇년 전에 손익분기점을 넘고 이제 솔루션 만으로 흑자를 내는 회사가 되었습니다.

그래도 공통적으로 갖는 고민은 다 똑같은가 봅니다.

한국 시장은  너무 좁아서...     
새로운 제품을 출시해서 수익원을 찾고...
개발자는 찾기 힘들고...
그냥 내가 직접 개발해야지...

최근에 나이든 웹 개발자들이 다시 각광을 받는 것 같습니다. 그 만큼 새로운 개발자들이 없다는 이야기겠죠! 웹 이라는 플랫폼으로 바뀐 세상에서 , 네트웍과 전산 지식을 기본 바탕으로 갖고 있으며 영어를 원활히 구사하는 개발자가 절실해 보입니다. 너무 어려운 이야기 일까요? 요즘 의대를 꿈꾸는 아이들중에 일부라도 컴퓨터에 꿈을 갖는다면..하고 생각만 해 본다. 만일 제 아이가 저에게 전산을 하겠다면 언듯 대답을 하지 못하는 게 또 현실이기 때문입니다.

넷쓰루의 건투를 기원합니다 !!

미국 대기업에서 인력 개발 팀장과 부사장 등을 역임했던 신시아 샤피로의 "회사가 당신에게 알려주지 않는 50가지 비밀" 이란 책을 읽다보면 회사  생활에 대해 많은 생각을 하게 된다. 결론은 회사 생활이란게 그렇치! 라는 생각과 더불어..

내용 중 반복적으로 나오는 주요 대상 중 하나가 직원과 인사부의 관계와 매니저와 직원간의 관계에서 발생하는 이야기가 많다. 그 중, 직원과 인사부의 관계에서 저자는 인사부는 직원을 위해 존재하는 것이 아니라 회사를 위해 존재하며 ,  그 활동 목표도 회사에 피해가 안가도록 지원을 관리하는 데 있다고 규정한다. 맞는 이야기 일까?

매니저와 직원간의 관계에 있어서는 나의 생각과 동일한 것 같다. 매니저의 기본 역할은 담당자들이 본인의 업무를 잘 수행할 수 있도록 지원해서 전체의 목표를 달성하도록 만드는 것을 말한다라고 말한다. 여기에 전적으로 동의한다. What을 중심으로 담당자에게 How를 찾아가면서 목표를 달성하도록 하고 여기에 발생하는 위기 관리는 하는 것..

반복해서 읽을 때 마다 많은 생각을 하게 해준다....
아마 일생에 있어 회사 생활을 그만두는 순간까지 힘들때마다 한번씩 읽어 보게 될 것 같다...느끼는 사람에게만 좋은 책!

27일 기술표준원에서 열린 OOXML의 ISO 표준안 표결에서 찬성했다고 합니다. 아직까지 각 나라들의 결과가 집계되어 공식 발표가 되지 않았지만  OOXML의 ISO 표준 통과는 대세인 것 같습니. 이제 문서 표준을 둘러싼 논쟁은 정리하고 오피스 시장에서 OOXML과 ODF가 가져다 줄 기회와 이를 잡기 위한 노력과 준비가 필요하다고 생각합니다.

다음과 같은 기회들이 가능하지 않을까요!

- mashup 문서가 일반화된다.
Youtube의 동영상 , 플리커의 이미지 등 외부의 컨텐트가 매쉬업된 문서가 일반화된다. 마찬가지로 기업내부에서도 CRM,ERP  등 기업 기간 시스템과 연계된 오피스 문서, 외부 DB 등이 연계된 문서가 일반화된다.특히, 이들 문서는 정적인 문서가 아니라 동적으로 매쉬업된 문서가 변경되고 관리되어 질 것이다.

- 기업내에서도 컨텐트 재사용이 일반화된다.
회사의 머리말,붙임말,로고 등 공통 컨텐트를 중앙에서 관리, 공유한다.

- 문서에 정책과 룰등을 부가하는 등 정책과 규칙을 통해 문서를 검사하고 정제하는 게 일반화된다.

- 문서의 DB화가 일반화된다.
기존 XML DB 가 기업의 문서 관리 DB 로서 각광받게 되며 이에 따라 기존의 파일 관리 위주의 문서 관리 시스템은 변화해야 만 한다.

- 문서 자체의 교환뿐만 아니라 문서의 의미,스타일 등 구성요소간의 교환이 일반화된다.

- 기존 리거시 문서(100경)를  XML문서화하고 이를 정제(매쉬업)하여 재활용하여 부가가치를 만들어 내는 사업이 각광받는다.

문서 DRM, EDMS,문서 백업 등 다양한 분야에서 새로운 변화에 대한 준비가 필요해 보입니다.

어도비 시스템즈에서 온라인 포토샵 버전을 발표하겠다는 소식을 들었을 때  두가지 생각을 했었습니다. 하나는 기존의 킬러 패키지중의 하나인 포토샵의 매출에 어떤 영향이 있을 까? 라는 것과 데스크 탑용 포토샵의 기능 중 어느 정도까지 지원이 될까? 라는 것 이었습니다.

기대반,호기심반

27일 발표한 어도비의 Photoshop Express 서비스를 가입하여 사용한 순간, 궁금했던 것들에 대한 답을 어느 정도 스스로 정리할 수 있었습니다.

2Gbyte의 저장공간과 페이스북, 피카사, 포토버켓 사이트에 대한 매쉬업을 통해 해당 사이트등의 사진을 자동으로 import해줍니다. 또한 갤러리를 구성하고 다른 사람들과도 공유하게 해줍니다. 사용자마다 고유한 갤러리 URL을 제공해 줍니다.


또한 편집 기능에 있어 해당 사진에 대한 URL  추출 기능과  데스크탑 포토샵의  기본 기능  정도를 제공합니다.  앞으로도 계속 추가되겠지만 초보자인 제 수준으로는 크게 부족함이 없어 보입니다. 텍스트 입력 기능을 아무리 찾아도 없네요...

MS의 오피스 라이브를 보면 실제 오피스는 서비스로 제공하지 않습니다. 기존 데스크탑 상의 오피스와 웹상의 오피스 라이브(소프트웨어 + 서비스)라는 하이브리드 모델입니다. 이런 모델의 이면에는 온라인으로 오피스를 제공할 경우 기존 데스크탑용 오피스의 판매에 영향이 있기 때문입니다.

그런데 어도비에서 온라인용 포토샵을 제공하는 이유가 무엇일까요?
MS와 달리 어도비는 고가의 데스크탑용 포토샵과 온라인 포토샵은 서로를 잡아 먹는 식인종 관계로 생각하지 않는 것은 분명합니다. 온라인 포토샵 버전은 고가의 데스크탑 버전에 부감스러워하는 사용자에게 또 다른 선택의 자유를 준다고 생각합니다.

윈도우용 포토샵 버전 , 맥용 포토샵 버전 ,  웹용 포토샵 버전
이 중 가장 많이 판매될 버전이 웹용 포토샵 버전이 될 수도 있을 것 입니다.

최근 들어, MS에서도 오피스의 웹 버전을 만들어 발표한다는 소식이 들리는 것을 보면 조만간 오피스의 온라인 버전도 멀지 않아 선보일 것이 분명해 보입니다. 더구나 저가의 가격으로 !

말도 많던 OOXML과 ODF의 표준화를 둘러싼 논쟁이 일단락되고 있습니다. 아마 어제 기술표준원에서 국내 투표를 통해 의견이 결정되었을 것이기 때문입니다. 이를 둘러싸고 국내에서도 반대 서명이 진행되는 등 많은 관심사가 다양하게 분출되었습니다.

ODF (Open Document Format) 진영을  대표하는 IBM과  OOXML의 MS간의 치열한  표준 전쟁도 있었습니다. 지난 26일은 ODF (Open Document Format) 진영의  후원을 받아 운영되는 문서 자유화 단체의 Document Freedom day 가 결선 투표를 앞두고 열린 것을 보면 역시 기술 표준화라는 것은 기술 전쟁이다라는 생각을 갖게 됩니다.

MS는 이번 투표를 통해  ISO표준화에 실패해도 계속해서 OOXML의 ISO 표준화를 추진할 것 입니다. MS의 전략상 OOXML은 포기할 수 없는 중요한 요소이기 때문입니다.

2008/02/28 - [Office2.0] - MS의 오피스 전략 이해해보기(1/2)
2008/02/29 - [Office2.0] - MS의 오피스 전략 이해해보기(2/2)

또한 기존 오피스와 운영체제의 지배력을 바탕으로 OOXML을 계속해서 확산시킬 것 입니다. 결국 업체 입장에서는  사업을 위해서는 OOXML , 표준을 위해서는 ODF를 모두 지원해야 하는 사항을 피할 수 없을 것 입니다.

아마 대부분의 기관 등에서 아래와 같이 오피스 도입에 대한 요구사항이 나오지 않을까요? ---기본적으로 도입하는 오피스는 ISO 표준인 ODF를 지원해야 한다. 또한 기존  MS Office  및 HWP 파일과의 호환도 100% 지원해야 한다.....

하여간 결국에는 다 해야 한다... 피곤한 일이다...하나만 할 수 없을까!

데스크탑용 소프트웨어 중 오피스가 꽃이라면 운영체제를 제외하고 DBMS는 서버 기반 소프트웨어의 꽃이라 할 수 있습니다. 개인적으로도 DBMS가 전공이고 1994년 부터 3년간 객체지향 DBMS를 개발한 경험이 있습니다. 돌이켜보면 아주 작은 프로토타이핑 수준이었지만 당시 객체지행 개념이 새롭게 나타나 주류가 되는 시점에시 기존 관계형 DBMS 의 한계와 단점을 극복하기 위한 노력은 아주 의미가 있었던 작업이었습니다.

DBMS는 초기 네트웍 DBMS, 현재 주류인 관계형  DBMS , 객체지향  DBMS 등 데이타를 다루는 모델에 따라 구분이 됩니다. 이러한 모델에 따라 각기 관계형  DBMS 는 SQL,  객체형 DBMS는 OQL등 데이타베이스에서 데이타를 꺼내는 언어를 제공하고 있습니다.  그러나 최근 들어, 인터넷  DB 또는 문서 기반  DB , REST DB 라는 개념의 데이타베이스 서비스와 클라이언트측에서 기존의 파일 시스템을 대체하며 손쉽게 쓸 수 있는 클라이언트측 DBMS가 등이 새롭게 나타나고 있습니다. 이러한 새로운  DBMS 의 키워드에 대해 정리해 봅니다.

1. 경량 DBMS

DBMS는 일반적으로 대용량의 데이타를 고성능으로 처리하기 위해 사용되는 고가의 엔진으로 알려져 있습니다. 이러한 엔진으로는 오라클, IBM DB2, MS SQLServer, Sybase등 외산이 주를 이루고 있습니다. 물론 국내의 경우 한국 컴퓨터 통신의 Unisql이 최초의 RDBMS이고 최근 들어,  Tmax 등이 RDBMS를 발표하여 판매를 하고 있습니다. ( 1990년 후반 당시, 제 기억으로는 이들 대용량 관계형 DBMS 엔진을 설계,개발할 수 있는 아키텍쳐가 몇몇 되지 않는 것으로 알고 있습니다. 그 중 Unisql은 그 분중 한분이자 한국의 김원 박사께서 개발한 제품입니다. )

개발자 입장에서 이러한 DBMS의 장점은 SQL(Structured Query Language)을 통해 원하는 데이타의 타입을 정의하고 , 값을 조작할 수 있다는 것 입니다. 이러한  SQL은 흔히 말하는 집합 개념(Set Theory)에 기초합니다. 쉽게 차집합, 합집합 등 집합 개념을 통해 원하는 집합을 얻어내는 것 입니다.  DBMS를 사용하지 않는다면 개발자는 직접 플랫 파일을 처리하거나 B-Tree같은 색인 시스템을 통해 직접 데이타를 처리해야 하며 , 데이타의 무결성을 지켜내야 합니다.

특히, 최근 들어 이러한 DBMS의 경량 버전이 각광받고 있습니다. 특히, 각종 임베디드 디바이스에서 데이타 관리나 모바일에서 오프라인 관리, 그리고 부하가 크게 없는 서비스에서 각종 사용자 데이타 관리 등에 경량 버전이 많이 사용되고 있는 상황입니다.

- Derby
자바 개발자에게 가장 좋은 경량 DBMS로는 Derby를 들 수 있습니다. 2MB 정도의 클래스 파일에 자바 힙 메모리도 4M 정도로 아주 작습니다. Derby는 본래 IBM에서 개발한 경량 DBMS로 Cloudscape라는 이름으로 개발되던 것을 2004년 8월에 Apache 재단에 contribution하면서 오픈소스화된 경량 DBMS입니다.  SQL92표준와 SQL99 표준의 일부를 지원하며 JDBC 기능을 제공하기 때문에 손쉽게 자바 프로그램내에 내장하여 사용할 수 있습니다. 특히, SQL 질의 최적화 또한 가격 기반으로 처리하는 등 첨단 DBMS의 최적화 기능을 제공하고 있습니다.

Cost-based query optimizer: join order, index selection, bulk fetching, join strategies (nested loop or hash), sort avoidance, lock escalation, subquery flattening, transitive closure, and many other query transformations. It uses a unique sampling technique that requires no intervention for statistical gathering, and also provides query plan overrides and statistics on actual query results.

내부 색인 구조는 멀티 컬럼 기반의 B-Tree 색인을 사용하기 때문에 대용량 지원은 가능한 구조입니다. 주요한 특징으로는 자바 언어로 트리거 , 스토어드 프로시져 그리고 SQL내에서 직접 자바 함수를 호출 할 수 있다는 것입니다. 더비는 자바 기반의 경량이지만 경량 이상의 기능과 성능을 제공하는 라이브러리보다는 경량 엔진으로 보입니다.

- SqlLite
자바 개발자에게 더비가 유용한 경량 DB 엔진이라면 TCL이나 C/C++개발자의 경우 SqlLite가 가장 좋은 경량 DBMS로 보입니다. SQL 최적화는 가격 기반이 아니라 SQL구문을 규칙에 의하여 최적의 상태로 변경하여 처리하는 방법을 사용하고 있습니다. 색인은 B-tree 를 사용하며 성능 최적화를 위해 페이지 단위의 캐싱을 합니다. 과거 제가 학생일 때 교제로 경량 DBMS 구축하는 과정을 소스코드 차원에서 가르쳐 주는 Requiem이라는 교제로 배웠었는데 실제 소스가 무척 유사하네요^-^(확인해 보니 Prentice Hall - Relational Database Management , M.Papazolou의 책입니다.). Sqllite의 아쉬운 점으로는 개발측면에서 ODBC나 JDBC 등을 지원하지 못한다는 점이지만 그 만큼 더 경량으로 데이타를 처리할 수 있다라는 장점도 있지 않나 싶습니다. 모바일이나 임베디드 H/W 장비 등에 사용할 경우 유용해 보입니다. 단, 기업용 응용 프로그램 처럼 너무 복잡한 모델에 적용하거나 대용량 처리를 바라는 것은 넌센스같습니다.

2. 서비스로서의 DBMS

SQL 방식이 아니라 기존의 REST나 SOAP 등 표준 웹 프로토콜에 기반하여 원하는 데이타를 구성하고 조작할 수 있는 방법은 없을까? 바로 이 방법이 서비스로서의 DBMS이다. 현재 이러한 방식으로 이용할 수 있는 것은 오픈 소스인 CouchDB 와 아마존의 SimpleDB가 있습니다. 이들 데이타 관리 서비스의 기능을 보는 것보다는 기본 모델을 이해하는 것이 중요하고 할 수 있습니다. 앞서 SQL이 행과 열의 관계로 구성된 테이블 이라는 2차원 구조에 기반한 모델인 데  반해 , 데이타 관리 서비스는 문서에 기반한 모델입니다. 하나의 문서를 만들고 이 문서에 필드를 생성하고 , 여기에 값을 넣고 수정하고 삭제하는 것을 가능하게 해주는 모델입니다. 예를 들어, 하나의 게시판 문서를 만들고 여기에 작성자, 제목, 본문, 작성일 등의 필드를 만들고 여기에 값을 다루는 것을 상상하면 됩니다. 과거 이러한 모델로 크게 성공한 시스템으로 현재 MS의 CTO인 레이 오지가 만든 로터스 노츠가 있습니다. 이 모델의 단점은 하나의 파일에 데이타와 뷰, 컨트롤러가 함께 있기 때문에 유지 보수 등에 있어 여러 문제들이 있다는 것 입니다. 한편으로는 게시판, 블러그, 각종 웹 폼 , 설문 등 현재 웹상에서 XML 등의 문서 기반의 응용에 적합한 모델입니다. 특히, 문서라는 특성으로 인해 버전 관리 등이 용이하기 때문에 이러한 특징을 살린 서비스 개발에 유리 합니다.  또한 검색엔진을 내장하여 대용량 문서에 대한 검색이 기존 DBMS 보다 강력하게 수행할 수 있습니다. 현재에도 CouchDB 에는 루씬 검색엔진이 통합되어 있습니다.

3. 검토 의견

실제 엔진의 기능으로 보면 Derby가 보다 성숙되었다고 할 수 있습니다. 그러나 SqlLite는 말그대로 아주 초경령이고 C로 개발되어 Derby에 비해 고성능을 내기 때문에 모바일 등의 하드웨어 등에 내장하여 사용하기에는 가장 적합하다 할 수 있습니다. 이 때문에 애플 아이폰 SDK를 비롯하여 모질라 등 여러 업체에서 이를 내장하고 있습니다. 이러한 엔진으로서의 DBMS가 보다 경량화되고  고가의 제품에서 일반화되는 것과 더불어  문서 기반의 DBMS 서비스 또한 다양한 용도로 사용될 것으로 보입니다. 게시판을 만드는 데 더 이상 복잡한 관계형 DBMS를 사용하는 것보다 REST 방식의 서비스를 사용하는 것이 보다 편리하고 쉬우며 가격도 저렴하기 때문입니다.

2008/03/23 - [SaaS] - 빌링 시스템에서 빌링 서비스로 II
2008/01/27 - [SaaS] - 빌링 시스템에서 빌링 서비스로! - Amazon DevPay

서비스로서의 소프트웨어(SaaS)가 확산되면서 다양한 방면에서 새로운 강자들이 태동하고 있습니다. 지난 번에 아마존 DevPay를 소개하면서 빌링 서비스에 대해 소개한 적이 있습니다만 아마존 외에도 여러 빌링 관련 서비스 업체들이 출현하고 있습니다. 많은 온라인 서비스 업체 입장에서 보면 빌링 시스템이야 말로 생존을 위해 꼭 필요한 시스템이기 때문에 가장 중요한 SaaS 인프라 라고 생각합니다. 특히, 기존의 빌링 시스템의 경우 고가의 작업이자 많은 구축 기간이 소요 때문에 빌링 서비스의 필요성은 더욱 중요하다 할 수 있습니다.

최근 SaaS 분야에서 주목을 받고 있는 빌링 서비스 업체를 정리해 봅니다.

Zuora.com

Salesforce와 WebEx의 멤버들이 창업한 회사로서 올 해 3월 , 벤치마크 캐피탈로 부터 6천5백만불을 시리즈A 라운드에서 투자를 받아 기염을 토한 회사입니다. 아직 서비스가 개시되지 않았지만 사용자의 가입에서 부터 빌링, 관리에 이르기까지 전 과정을 지원해주는 서비스를 제공할 예정이며 , Salesforce의 AppExchange의 업체들에게 서비스를 제공할 예정이라고 합니다. 

ariasystems.com

고객관리와 마케팅 툴, 그리고 빌링 서비스를 온라인으로 제공하고 있습니다.





lecayla.com

현재까지 제공되는 빌링 서비스 중에서는 가장 구체적으로 현실적인 것 같습니다. SOAP과 REST방식으로 제공되는 API를 이용하여 빌링 서비스를 연동하며 , 웹 브라우져를 통해 가격 메트릭스와 각종 빌링 파라메터를 설정할 수 있습니다.



특히, 방화벽 내부에 있는 서비스들을 안전하게 통합하기 위해 내부에 설치할 수 있는 에이전트를 제공해 줍니다. 이 에이전트는 해당 서비스의 사용자 정보 및 사용 정보 등을 전달합니다.


빌링 시스템은 웹 비지니스에 있어  가장 기본이 되는 중요한  인프라입니다.  지금까지 이러한  빌링 시스템을 구축하는 것은 많은 비용과 기간이 드는 것으로 인식되고 있습니다. 구축 과정을 곰곰히 돌이켜보면 실제 빌링 시스템 구축을 위한 정형화된 템플릿도 부재하며 , 구축 자체가 거의 SI 이기 때문에 구축 뿐맘 아니라 유지보수에도  많은 비용이 듭니다.  물론 , 아주 복잡한 빌링 시스템 구축에는 기존 빌링 시스템이 필요할 지 모르지만 가입비를 주로 받는 전문 서비스 입장에서는 위와 같은 빌링 서비스가 보다 유리할 것 입니다. 국내 빌링 업체들도 빌링 시스템에서 빌링 서비스로 적극 전환을 해야 할 시점이 아닌가 싶습니다^-^.

2008/01/27 - [SaaS] - 빌링 시스템에서 빌링 서비스로! - Amazon DevPay

로버트 L.글래스의 우리가 미처 알지 못한 S/W공학의 사실과 오해(Facts and fallacies of software engineering)에서 ...

구매한지 몇 달이 지난 책인데 이제서야 정독을 하고 있습니다. 개발에 있어 참고할 만한 재미난 통계 정보들이 있어 정리해 봅니다. 이 책은 소프트웨어 개발에 있어 관리, 개발 생명 주기, 품질 그리고 각 과정상에 발생하는 오류에 대해 정리하고 있습니다 .특히, 가장 개발자들이 싫어하는 유지보수에 대해 참고할 의견들이 많은 것 같습니다.

1. 관리에 대해

- Al Davis , "뛰어난 관리가 뛰어난 기술보다 중요하다."

- 소프트웨어 개발에 있어 가장 중요한 요소는 프로그래머의 자질이다"
무척 중요한 사실입니다. 사람중심의 개발에 반대되는 것이 아마 프로세스 중심의 개발이라고 할 수 있습니다. 어떤 것이 중요할까요? 물론 사람중심이 정답일 것입니다. 그러나 만약 사람 중심의 시각에서 해당 개발자가 충분한 자질을 갖지 않는다면 어떻데 될까요? 결국 이러한 문제 상황에 봉착했을 때 할 수 있는 방법은 프로세스를 만들고 이를 규정화하는 것 입니다. 물론 프로세스 기반의 개발의 경우 이를 이해시키고 강제시키는 것이 가장 어려운 일이지만요.. 자질있는 프로그래머... 참 요즘은 찾아 보기 어렵죠..!

- 최상의 프로그래머는 최악의 프로그래머보다 28배 더 뛰어나다.
- 지체된 프로젝트에 사람을 추가 투입하면 프로젝트가 더 지체된다."
역설적으로 우리나라 SI의 경우 이러한 사실에 정반대로 프로젝트를 관리하죠. 납기일에 맞추기 위해 막판 개발자 추가 투입.... ^-^

2. 개발 생명 주기에 대해

- 개발 생명 주기의 비율은?
요구분석 20% , 설계 20% , 코딩 20% , 오류 제거 40%

- 위기의 프로젝트의 가장 흔한 원인 2가지 중 하나는 불안정한 요구사항이다.

3. 유지보수에 대해

전체 소프트웨어 공정 비용 중 60%가 유지보수 비용이고 그중 60%가 기능 강화(enhancement)에 드는 비용이랍니다.  나머지는 17% 오류 수정 , 18%는 다른 플랫폼 지원들을 위해 드는 적응성 유지(adaptive maintenance) 비용 , 그리고 마지막 5%는 리팩토링 비용이라고 합니다.

이러한 유지보수를 위해서는 기존 시스템을 이해하는 게 정말 중요합니다.  실제 기존 시스템을 이해하는 게 유지보수에서 가장 어려운 작업입니다. 다른 사람이 설계하고 개발된 시스템을 코드를 통해 역으로 이해해야 하기 때문입니다. 평균적으로 기존 시스템을 이해하는 데 걸리는 시간은 전체 유지보수 시간중 대략 30% 정도라고 합니다. 아마 이 경우 , 기존 시스템을 잘 이해할 수 있도록 문서나 코드 들이 잘 정리돼어 있어야 겠죠.  이렇치 않을 경우 제 경험한 전체 유지보수 시간이 기하급수적으로 늘고 결국 다시 짜야 합니다 라는 담당자의 보고를 받게 됩니다 ^-^.  참고로 Fjelstedz 와 Hamlen가 정의한 유지보수의 생명주기는 다음과 같습니다.
 
-수정 사항의 정의와 이해(15%) - 시스템 문서 검토(5%)-로직 추적(25%)-수정사항 구현(20%)-테스트와 디버깅(30%)-문서 업데이트(5%)

4. 품질에 대해

소프트웨어 품질의 7개 속성 - 이식성, 신뢰성, 효율,사용편의성, 테스트 용이성, 이해 용이성, 수정 용이성

여기서 효율이란 S/W가 실행 시간과 사용 공간에 있어 얼마나 효율적인지를 의미하는 것이며 이해 용이성과 수정 용의성은 유지보수 담당자가 얼마나 쉽게 이해하고 수정을 할 수 있는지를 말하는 것입니다.  어차피 정답은 없지만 개발자로서 내가 개발하고 있는 소프트웨어가 얼마나 높은 품질을 갖고 있는 가는 의미있는 일 입니다. 물론, 생각해 보면 좌절할 수도 있겠지만요^-^.

오류의 발견 위치
- 오류의 반이 모듈의 15%에서 발견된다.
- 오류의 80%가 단지 모듈의 2% 이내에서 발견된다.
- 대락 80%의 결함이 모듈의 20%에서 나오고 모듈의 절반정도는 오류가 없다.

결국 소프트웨어는 여러 개발자가 모듈을 나눠서 개발하기 때문에 특정 모듈을 맡은 개발자에 의해서 대다수의 오류가 만들어진다고 생각할 수 있습니다. 결국 오류를 완벽하게 제거할 수 없기 때문에 모듈 개발시 난위도를 조절하여 개발 역할을 나누고 , 오류 수정은 심각한 것을 수정하는 전략이 필요하겠죠...

5, 후기
소프트웨어 분야에 있어 관리자가 아니라 개발자로 오래 남는 다는 것은 결국 자신이 그 일에 매우 능숙하게 된다는 것과 동시에 다른 부분의 사람들이 갖지 못하는 권력(?)을 갖는 것이기도 합니다. 이를 악용하는 사례들도 많이 있지만 대다수의 개발자들은 오래 동안 개발자로 남길 원할 것 입니다. 정말 코드로 승부하려는 개발자들 에게 다시 한번 격려를 보냅니다.  요즘은 그런 생각이 드네요 CTO라는 직업으로 뭘 해야 하나? ^-^. 관리자인가 개발자인가..직원인가 임원인가..

교조주의[敎條主義]
1 특정한 교의나 사상을 절대적인 것으로 받아들여 현실을 무시하고 이를 기계적으로 적용하려는 태도.
2 과학적·합리적인 증명을 하지 않고 신앙이나 신념에만 기초한 사고방식으로 사물을 설명하려는 태도. 종교에서 권위자가 말한 것을 깊이 이해하지 않고 기계적으로 추종하려는 태도로, 중세의 스콜라 철학·독단론·정설주의(定說主義) 따위가 있다.
제가 포스팅한 지난 글에서 주고받은 의견들입니다.

 ㅋㅋㅋ - 마소의 개가 되려고 하면 ooxml 밀겠죠.. 리눅스에서도 사용하기 힘든 문서... 모든 운영체제에서 사용 가능한 odf로 가야 한다고 생각 합니다. 이제 마소의 개에서 벗어 날때가 되지 않았나요?

박재현-기술적 교조주의는 보다 넓은 시각에서 기술을 이해하는 데 걸림돌만 될 뿐입니다. MS의 개라는 시각에서 모든 것을 본다면, 현재 구글을 이용하면 구글의 개, 네이버를 쓰면 네이버의 개라는 말과도 같지 않을까요? ...... 물론, MS의 시장 지배력을 바탕으로 많은 정의롭지 못한 일을 한 것도 사실입니다. 그렇다고 MS의 기술에 대해 긍적적인 면을 이야기 한다고 개라고 보는 것은 아주 위험합니다 ^-^.

OOXML과 ODF의 표준화에 대한 글을 포스팅하면서 제가 느낀 기술적 교조주의에 대한 위험성에 대해 말해 보고자 합니다.  노동자와 빈민들을 챙기는 의견을 낸 사람을 좌익이라고 부르는 것은 아주 극단적인 정치,경제,사회적 교조주의입니다. 이러한 교조주의 시각을 갖은 분들이 소프트웨어 업계에도 많은 것 같습니다. 특히, 경력이 많지 않은 분들의 경우 이러한 시각이 더욱 강한 것 같습니다. 아마 자신의 기술에 대한 애착이 그 만큼 크게 느껴지기 때문이라는 생각도 합니다.^-^

과거 저의 경험을 돌이겨 보더라도 그랬던 것 같습니다.  과거 저는 학교에서 유닉스 웍스테이션을 지금의 PC처럼 사용했었습니다. 여기서 GCC Compiler로 프로그램도 짜고 , Latex으로 문서도 작성했었습니다.  심지어 발료자료도 만들었으니까요. 학교를 졸업하고 직장인 현대전자에서 DBMS를 개발할 1994년 당시에도 선웍스테이션에 C Compiler로 개발을 했고 , 1996년 부터 javac 컴파일로러 자바를 다룬 후 지금까지 자바를 사용하고 있는 것을 보면 완전히 MS 플랫폼과는 거리가 있어 보입니다. 물론 현재에는 하드코딩은 하지 않습니다 ^-^. 90년대 후반 당시에도 자바와 MS 기술에 대해 밤새도록 개발자들과 소주잔을 기울이며 토론하던 때가 있었습니다. 그 토론은 서로의 기술에 대한 비판이었지 비난은 아니었던 것 같습니다.

"인터프리팅 방식의 자바는 너무 느리다"라는 비판에 "하드웨어의 발전과 더불어 바이트 코드의 수행 속도는 계속해서 개선되고 있다. 심지어 바이트코드를 직접 어셈블러로 바꾸는 기술도 있다." , "윈도우 API와  MFC는 오직 윈도우 플랫폼만을 위한 것이 아니냐? 다른 플랫간의 통신을 위한 기능이 약하다" 이에 대해 DCOM이란 기술이 준비중이다..." 

이런 대화들이 주를 이뤘던 것 같습니다. 실제 내가 익히고 사용하는 기술에 대해 자부심과 애착을 갖는 것은 당연합니다. 그렇치만 다른 기술에 대한 분석과 비판, 그리고 장점을 이해하고 이를 통해 보다 넓은 시각을 갖는 것은 중요하다고 생각합니다. 이러한 시각이  S/W 개발에 있어 중요한 것은 S/W는 사람이 만드는 것이고 그 사람의 생각과 경험, 그리고 제가 가장 중요하다고 생각하는 의지의 결과이기 때문입니다.

리처드 스톨만의 GNU 소프트웨어는 Free Software 입니다. 무료 소프트웨어가 아니라 자유 소프트웨어로서 소프트웨어를 자유롭게 실행, 복사, 배포, 연구, 변경하고 배포시킬 수 있다는 것을 말합니다. 이러한 GNU의 사상은 중심에는 사람있다고 생각합니다.  소프트웨어는 창조한 사람에 의한 창조물이고 이 창조물이 더욱 발전하기 위해서는 다른 사람이 창조한 것을 보다 자유롭게 공유하는 데 있다는 것 입니다. 보다 창조적인 개발자가 되기 위해서는 교조주의를 버리고 보다 유연한 시각을 갖어야 할 것 입니다.

이를 위해 몇가지 제가 하는 방법을 소개하면 다음과 같습니다.

- 자바 외에 MS, Apple, Adobe 등 다양한 개발 기술에 장단점을 분석해 본다.
- 경영,경제,문화,철학 등 주요한 사회적 이슈들에 관한 책을 읽고 분석해 본다.
- 주요한 컨퍼런스의 주제들을 보고 분석해 본다.
- 주요 관련 서비스들에 대해 모니터링을 하며 이를 분석해 본다.
- 망한 사이트와 기술에 대해 주기적으로 살펴본다.

미국 경제가 악화되면서 실리콘밸리와 웹2.0 이라 불리는 회사들이 망하는 일이 많이 발생한다고 합니다. 그나마 이미 펀딩을 받아 놓거나  M&A 등을 통해 기회를 유지하고 있는 업체들을 제외하고는 힘든 시기인 것 같습니다. 우리나라도 마찬가지는 아니라고 생각합니다. 그나마 열악한 웹 서비스 회사들은 더욱 어려워질 것이고 , 개발자도 더욱 어려워 질 것 입니다. 개발자의 처우 개선이라는 것과 더불어 편협되지 않고 건강한 개발자로 발전하는 것도 아주 중요합니다.

봄이 오는 모양입니다.오늘 온 비는 봄비가 맞겠죠!  계절의 변화와 더불어 새로운 여러가지 변화를 두려워하지 말고 준비해야 할 때가 아닌가 싶습니다. 오늘 서울대 신문사에서 학생 기자 한분이 전화가 왔습니다. "왜 블러그를 하죠?" "언제 어디서나 내가 원할 때 쓰고 싶은 글을 쓸 수 있기 때문이죠"이라고 대답했습니다. 누가 뭐라하든 요즘은 아무 생각 없이  글을 쓸때가 가장 행복한 것 같습니다. 오늘은 문서 작성 서비스에 대해 정리해 보겠습니다.

워드프로세스 서비스

더 많겠지만^-^ 14개의 서비스가 눈에 띠입니다. 기존 워드 프로세스 수준의 편집기로는 씽크프리의 Write이 단연 선두입니다. 그러나 자바 등 RIA기반이 아니라  Ajax 플랫폼기반의 서비스로는  Zoho Writer  , ThinkFree Note , Google Documents 등이 우수합니다. 기타 UI 측면으로는 어도비의 Buzzword를, 위키 같이 공동 저작의 경우 Writeboard 가 유용한 서비스를 제공하고 있는 상황입니다. 결론적으로 Ajax 기반의 웹 에디터의 편집 기능은 실제 거의 대동소의 합니다. 중요한 것은 사용자의 편의성과 기존 MS 문서와의 호환성 , 대용량 처리 등이 중요하다 할 것 입니다.  호환성과 대용량 지원 측면에서는 자바 기반의 씽크프리의 Write이 가장 뛰어나다 할 수 있습니다.

ThinkFree Write

두 말할 나위 없이 자바로 개발되어 기존 MS Office와 동일한 UI와 80%에 달하는 강력한 편집 기능과 렌더링 호환 기능을 제공하고 있다. 웹 상에서 애플릿과 자동 싱크 기능을 활용한 데스크탑 버전을 모두 이용할 수 있다. PDF,RTF,OOXML등 다양한 포맷간의 양방향 호환을 제공한다.

ThinkFree Note

씽크프리의 Write이 자바 기반의 강력한 편집 및 렌더링 기능을 제공하는 데 반해 Note는 Ajax기반의 웹 에디터이다. 노트는 Youtube,Flickr,clipart 등 강력한 매쉬업 기능을 통해 문서를  HTML 문서를 손쉽게 작성하고 이를 블로그에 포스팅하게  해준다.

Zoho Writer

DOC,ODT,OOXML 등 다양한 문서의 import,export 제공하며 고급 수준의 웹 에디터 기능을 제공한다. 구글 기어를 이용하여 오프라인시 로컬 저장 기능을 제공하는 것이 특징이다.

Google Documents

과거 Writely를 인수하여 업데이트를 계속하고 있습니다. 500K  크기의 문서까지 업로드와 생성을 지원합니다. 웹 에디터 수준의 편집 기능에 리비전, 스펠체커, 공유 및 공동 편집, 블러그 퍼블리싱 등의 기능을 제공합니다.  문서 생성 후 doc,ODF,pdf,rtf 등으 문서로 export 가 가능하지만 기존 doc 문서의 import 기능은 미약한 편입니다. 웹 상에서 간략한 문서를 작성하는 데는 큰 문제가 없어 보입니다만 고급 문서를 편집하기에는 문서 크기와 편집 기능이 다소 약한 편입니다.

AjaxWrite

AjaxWrite은  UI면에서 MS Word 2003을 닮았고 특징으로는 Doc 문서의 import/export입니다. 그러나 테스트를 해보면 import/export 모두 제대로 되지 못합니다^-^. 제약사항으로는 Firefox browsers 1.5 이상에서만 작동된다는 것 입니다. 무료라는 것외에 그다지 쓸모있어 보이지는 않습니다.

Buzzword

Adobe AIR의 기술을 사용하여 UI가 아주 멋집니다. 특히, 메뉴의 다이나믹한 부분이 특징적이고 문서 중간중간에 코멘트를 넣을 수 있는 기능이 마음에 듭니다. 최근 들어 , OOXML로  Export하는 기능을 추가했네요!! 기존 에이작스보다 마우스 반응이 뛰어나 사용성은 뛰어나 보입니다.

아래는 버그워드의 메뉴바입니다. 단일 메뉴바와 하단 팝업으로 제공하는 모든 기능을 제공해 줍니다. 모바일 처럼 작은 화면에 메뉴를 표현하는 데 아주 유용해 보입니다. 기능은 특별한 부분은 그다지 눈에 띠지 않습니다.



FlySuite.com

맥에서는 자바로 개발된 워드프로세스를 제공합니다. 그런데 윈도우에서는  Exe 프로그램으로 제공하네요. 정체가 모호한 제품..온라인으로는 애플릿으로 오프라인으로는 패키지 형태로 제공하며 1 GB 의 온라인 저장공간을 제공해주고 있습니다. MS Offic97에서 2003까지 양방향 호환이 되는 것 같은데 유료 가입을 해야 저장할 수 있어 확인은 해보지 못했습니다. 29$에 무제한 라이센스로 제공한다고 합니다.  그다지 썩 멋지진않네요.. 돈내고 가입하는 일이 없기를...

iNetWord.com

웹 에디터 수준에서 제공할 수 있는 편집 기능은 충실히 제공하고 있습니다. 블러그와 FTP서버상에 퍼블리싱을 제공하고 있으며 폴더 및 문서 공유와 변경 이력관리(Track Change) 등이 주요한 특징입니다. 전체적으로 기본 편집 기능과 문서, 폴더 관리 등이 하나의 화면에서 제공되다 보니 UI측면에서 무척 협소해 보입니다.

J2E.com 

Just 2 Easy는 자바로 개발된 에디터로 학생들이 과제를 수행하고 해당 과제의 URL을 선생님과 친구들에게 공유하도록 해준다. 문서 작성- 공유- Learn 이라는 모토로 서비스를 하고 있다. 어린 학생들을 주요한 사용자로 설정한 것이 이채롭다. 그 만큼 요즘 어린 세대들이 웹 에디터같은 온라인 오피스 환경을 편하게  받아 들인다는 것의 반증이기도 하는 것 같습니다.

Nevrocode Docs

.Net3.0 기반으로 개발된 데스크탑 오피스 프로그램인데 작성된 파일을 웹상에 저장하고 접근할 수 있는 기능을 제공합니다. 계정이 만들어 지지 않아 직접 편집 등의 기능을 테스트해보지는 못했지만 아직 알파 버전 수준이라 많은 노력이 필요할 것 같습니다. 윈도우 환경하에서 사용가능한 워드프로세스라고 보는 게 맞을 것 같습니다.

Peepel.com

DOC와 ODF의 import와  export , 협업, 오프라인 기능 등을 지원한다. 특색있는 기능으로 가상의 웍스페이스를 만들어 여러 문서를 열어 처리할 수 있게 해준다. 물론, 대용량 문서의 처리는 불가능하다.

Solodox.com

솔루션도큐멘트의 약자로 보이는 이름에서 느껴지듯이 일본에서 개발된 서비스로서 문서작성 기능 외에 프로젝트 관리 기능을 제공하고 있다.

TheOpenDoc.com

Go-Write이라는 이름으로 바뀌었네요. 웍스페이스를 만들고 여기에 문서를 작성하고 연관된 토론과 업무 관련 정보를 정리할 수 있는 기능을 제공하고 있습니다. PDF,DOC로의 저장을 제공하고 있습니다.

Writeboard

편집 기능 보다는 협업 기능에 중점을 둔 서비스 이다. 공동의 위키 페이지를 하나 만들어 공유한다고 생각하면 쉽게 이해할 수 있다. 편집도 위키 문법을 사용한다

2008/02/17 - [Office2.0] - 2008 온라인 오피스 서비스 정리- 오피스 문서 UCC