[펌]2013년에 하지 말아야 할 9가지 애플리케이션 개발 프로젝트

다른 프로젝트와 오픈소스에서 재사용할 수 있는 좋은 코드가 있거나 심지어 원하는 기능을 하는 상용 제품이 있는 경우라도, 많은 개발자가 직접 소프트웨어를 만들기를 좋아한다. 다른 누구도 자기만큼 그 일을 잘 하지는 못한다는 자부심이 원인일 수도 있다. 또는 시스템 레벨에서 코드의 작동 원리를 이해하기 위해 학생이 직접 컴파일러를 만들어야 하는 컴퓨터 과학 전공 프로젝트를 수행하면서 몸에 들인 습관 탓일 수도 있다.

 

이유가 무엇이든 자체 코드를 개발하다 보면 시간과 노력이 소모되고 버그가 발생할 소지도 있다. 새 코드는 검토와 테스트를 거친 기존 코드에 비해 버그가 존재할 가능성이 더 높다. 직접 시작하지 말아야 할 소프트웨어 프로젝트의 종류에는 다음과 같은 9가지가 있다. 순위가 높아질수록 피해야 할 생각임을 의미한다.

 

9. 부하 테스트 프레임워크(웹 애플리케이션용)

특히 웹 애플리케이션을 제외한 부분에서 극히 소수의 경우를 제외하고 부하 테스트 도구는 이미 존재한다. 새 도구를 만들 이유가 없다. WebPerformanceInc.com과 같이 대신 해주는 웹 사이트부터 로드러너(LoadRunner)와 같이 거추장스럽고 불편하지만 오랜 시간을 거쳐 숙성된 도구에 이르기까지, 부하 테스트를 위해 필요한 모든 것이 준비되어 있다. 셀레늄(Selenium), 테스트메이커(Testmaker)와 같은 오픈소스 도구도 있다. 자기만의 부하 테스트를 만들어야 하는 경우는 있겠지만, 웹 애플리케이션을 위한 자체 부하 테스트 도구를 만들어야 할 필요는 없으니 하지 말길 바란다.

 

8. 캐시(특히 분산 캐시)

NoSQL 전에는 자기만의 캐시를 만드는 것은 회사 사장에게서 연구 개발 자금을 확보하기 위한 좋은 수단이었다. 그렇게 해서 직접 벤처 기업을 시작해 타히티로 은퇴하기 전에 거대 기업에 매각되길 희망할 수 있었다. 그러나 오늘 새 프로젝트를 시작한다면 아마 자금을 구하지 못할 것이다. VC들은 지나간 유행에 자금을 대려 하지 않기 때문이다.

 

그래도 문제는 없다. 직접 캐시를 만들지 않아도 된다. 물론 기술적으로 캐시 만들기가 어려운 일은 아니지만, 잘못 만든 캐시는 부하가 큰 상황에서 시작할 때 데이터베이스를 죽이고 메모리를 누출시키거나 쓰레딩 문제를 일으키곤 한다. 젬파이어(Gemfire), 테라코타(Terracotta), 인피니스팬(Infinispan) 또는 코히어런스(Coherence)와 같은 기존 캐시 도구 중 하나를 위한 맞춤형 캐시 로더 또는 캐시 스토어를 만들어야 할 수는 있다. 게다가 이러한 도구들 중 일부는 오픈소스이므로 꼭 필요하다면 고쳐서 쓰면 된다.

 

7. 인벤토리 시스템

인벤토리 관리나 공공 도서관 운영이나 같은 개념이 적용된다(도서관은 전자책을 두려워한다는 부분을 빼면). 약간의 커스터마이즈 작업이 필요할 수는 있지만 오픈소스 OneCMDB, IBM의 Taddm, HP의 UCMDB 등 여러 가지 범용 인벤토리 관리 시스템이 이미 시중에 존재한다.

 

6. 워크플로 엔진

여전히 독자적인 워크플로 엔진을 만드는 사람들이 있다. 이들은 학교에서 상태 시스템에 대해 배웠지만 졸업 후 오픈소스 액티비티(Activiti), JBPM 등에는 관심을 두지 않은 사람들이다. 어떤 일이 발생하고, 상태가 발생하고, 상태를 저장하고, 그 상태를 사용해 그 지점에서 계속 진행한다. 그게 전부다. 이 기능을 하는 프로그램을 100개 더 만들어봤자 아무 필요도 없다.

5. e-커머스 스위트

 “e-커머스”의 “e”를 남겨둔 이유는 1990년대를 상기하기 위해서다. 무엇에든 앞에 “e”자만 붙이면 그럴듯해 보였던 때를 기억하는가?(적어도 CNN은 그렇게 생각했다.) 지금은 e 없이 그냥 커머스 스위트라고 하는데, 오픈소스 브로드리프(Broadleaf), 마그네토(Magento), 스프리(Spree), 젠카트(Zencart), 그리고 쇼피파이(Shopify)와 같은 SaaS 도구에서부터 ATG, 웹스피어, 웹로직 등 터무니없이 높은 가격의 폐쇄형 프로그램에 이르기까지 상당히 많다. 전통적인 오프라인 사업을 하지 않는다면 이러한 도구 중 하나를 커스터마이즈해야 할 것이다. 온라인에서는 무엇을 팔든 필연적으로 커머스 스위트를 올려야 하고, 지불 처리 프로그램에 통합해야 할 수도 있겠지만 새로 만들 필요는 결코 없다.

 

4. 리포팅 엔진

필자는 직접 리포팅 엔진을 만든 적이 있다. 변명하자면 당시에는 쓸 수 있는 것이 없었다. 필자는 여러 회사에서 자바로 리포팅 도구를 만들었는데, 그 회사들이 정확히 원하는 기능을 수행하는 기존 도구가 없었기 때문이다. 결국 이들은 엑셀에 적당히 숫자를 집어넣어 사베인 옥슬리 법안을 준수하는 모양새를 갖추었다. 그래서 필자는 아파치 POI 프로젝트를 시작했지만(마이크로소프트 파일 형식을 자바로 이식), 이후 JBoss에 들어가는 바람에 엑추에이트(Actuate)와 크리스탈 리포트(Crystal Reports)에 대처하는 원대한 오픈소스 계획을 위한 코드는 결국 한 줄도 쓰지 못했다. 그 사이 자스퍼리포트(JasperReports), BIRT, 펜타호(Pentaho)를 비롯한 도구들이 등장하여 공백을 채우기 시작했다. 이 중 하나를 사용하면 된다.

 

3. 메시지 버스

지난 10년 동안 많은 사람들이 만들고 또 만들 정도로 인기가 있었다. 느린 구닥다리 MQ 시리즈 웹스피어MQ로는 더 이상 만족할 수 없었기 때문에 메시징과 관련한 신생 업체들이 생겨났다. JBoss, BEA와 기타 자바 EE 벤더들이 저마다 하나씩 만들었고 이후 또 다른 식으로 만들어서 이전 것을 대체했다.

 

큐에 집어넣어 필요한 곳에 전달하는 일은 필요하다. 때로는 벽에다 써서 모든 것이 똑 같은 메시지를 집도록 해야 하는 경우도 있다. 그래서 호넷Q(HornetQ), 래빗MQ(RabbitMQ), 액티브MQ(ActiveMQ)를 비롯한 많은 옵션들이 존재한다. 갖가지 기능으로 치장한 무거운 프로그램도 있고, 가볍지만 강력한 프로그램도 있다. 이것을 직접 만들어 유지하는 고생을 할 필요 없이, 요구 사항을 충족하는 기존 프로그램을 분명히 찾을 수 있을 것이다. 

 

2. 싱글사인온(SSO) 구현

아직 이것으로 새로운 사업을 시작할 여지는 있을지 모르겠지만, 아마 상사가 여러분의 은밀한 파일럿 프로젝트를 중단시키고 피켓링크(Picketlink), ADFS, 오픈AM(OpenAM), 핑 아이덴티티(Ping Identity) 등을 사용하도록 지시할 것이다. 점대점 SSO 역시 만들어서는 안 된다.

 

오해는 말길 바란다. 이 영역은 표준화 측면에서 열악한 분야이기 때문에 커스텀 작업과 통합이 이루어질 것이다. IT 업체들은 모두 상호 운용성을 입버릇처럼 말하지만, 이들의 관심사란 결국 사용자가 자신들의 “플랫폼” 또는 제품 “스위트”를 구매하고, 거기 종속되어 다른 곳에서는 아무것도 구입하지 않도록 하는 것일 뿐이다. 아무튼 100개의 점대점 통합 프로젝트를 추진하거나 직접 결함투성이의 SSO를 구현하는 것보다는 전체적인 공급업체 하나를 선택해서 면밀한 통합을 추진하는 편이 비용 절감 측면에서 유리할 것이다.

 

1. 컨텐츠 관리 시스템

컨텐츠 관리 시스템은 세상에 넘쳐난다. 형태도 다양하다. 드루팔(Drupal)과 비슷한 것도 있고 인터우븐 팀사이트(Interwoven Teamsite )/어도비 CQ와 비슷한 괴물들도 있고 셰어포인트와 유사한 것도 있다. 일부는 세 가지 접근 방법을 통합한다(알프레스코(Alfresco) 등). 어느 정도는 모두 비슷하다. 

 

타일러 더든의 말을 빌자면 특별한 것은 없다. 어떤 CMS를 구현하든 이 세 가지 유형 중 하나에 포함될 것이다. 너무나 특이해서 이 유형에 모두 맞지 않는 컨텐츠를 찾기란 무척 어렵다. 잘해봐야 오픈소스 구현을 커스터마이즈하거나 새롭게 단장하는 정도면 충분하다. 직접 CMS를 만드는 것은 너무 90년대스러운 행동이다. 직접 만들지 말라!  

editor@itworld.co.kr

(http://www.itworld.co.kr/news/79569?page=0,1)