말도 많던 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라는 직업으로 뭘 해야 하나? ^-^. 관리자인가 개발자인가..직원인가 임원인가..