2013.01.03

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

Andrew Oliver | InfoWorld
다른 프로젝트와 오픈소스에서 재사용할 수 있는 좋은 코드가 있거나 심지어 원하는 기능을 하는 상용 제품이 있는 경우라도, 많은 개발자가 직접 소프트웨어를 만들기를 좋아한다. 다른 누구도 자기만큼 그 일을 잘 하지는 못한다는 자부심이 원인일 수도 있다. 또는 시스템 레벨에서 코드의 작동 원리를 이해하기 위해 학생이 직접 컴파일러를 만들어야 하는 컴퓨터 과학 전공 프로젝트를 수행하면서 몸에 들인 습관 탓일 수도 있다.
 
이유가 무엇이든 자체 코드를 개발하다 보면 시간과 노력이 소모되고 버그가 발생할 소지도 있다. 새 코드는 검토와 테스트를 거친 기존 코드에 비해 버그가 존재할 가능성이 더 높다. 직접 시작하지 말아야 할 소프트웨어 프로젝트의 종류에는 다음과 같은 9가지가 있다. 순위가 높아질수록 피해야 할 생각임을 의미한다.
 
9. 부하 테스트 프레임워크(웹 애플리케이션용)
특히 웹 애플리케이션을 제외한 부분에서 극히 소수의 경우를 제외하고 부하 테스트 도구는 이미 존재한다. 새 도구를 만들 이유가 없다. WebPerformanceInc.com과 같이 대신 해주는 웹 사이트부터 로드러너(LoadRunner)와 같이 거추장스럽고 불편하지만 오랜 시간을 거쳐 숙성된 도구에 이르기까지, 부하 테스트를 위해 필요한 모든 것이 준비되어 있다. 셀레늄(Selenium), 테스트메이커(Testmaker)와 같은 오픈소스 도구도 있다. 자기만의 부하 테스트를 만들어야 하는 경우는 있겠지만, 웹 애플리케이션을 위한 자체 부하 테스트 도구를 만들어야 할 필요는 없으니 하지 말길 바란다.
 
8. 캐시(특히 분산 캐시)
NoSQL 전에는 자기만의 캐시를 만드는 것은 회사 사장에게서 연구 개발 자금을 확보하기 위한 좋은 수단이었다. 그렇게 해서 직접 벤처 기업을 시작해 타히티로 은퇴하기 전에 거대 기업에 매각되길 희망할 수 있었다. 그러나 오늘 새 프로젝트를 시작한다면 아마 자금을 구하지 못할 것이다. VC들은 지나간 유행에 자금을 대려 하지 않기 때문이다.
 
그래도 문제는 없다. 직접 캐시를 만들지 않아도 된다. 물론 기술적으로 캐시 만들기가 어려운 일은 아니지만, 잘못 만든 캐시는 부하가 큰 상황에서 시작할 때 데이터베이스를 죽이고 메모리를 누출시키거나 쓰레딩 문제를 일으키곤 한다. 젬파이어(Gemfire), 테라코타(Terracotta), 인피니스팬(Infinispan) 또는 코히어런스(Coherence)와 같은 기존 캐시 도구 중 하나를 위한 맞춤형 캐시 로더 또는 캐시 스토어를 만들어야 할 수는 있다. 게다가 이러한 도구들 중 일부는 오픈소스이므로 꼭 필요하다면 고쳐서 쓰면 된다.
 
7. 인벤토리 시스템
인벤토리 관리나 공공 도서관 운영이나 같은 개념이 적용된다(도서관은 전자책을 두려워한다는 부분을 빼면). 약간의 커스터마이즈 작업이 필요할 수는 있지만 오픈소스 OneCMDB, IBM의 Taddm, HP의 UCMDB 등 여러 가지 범용 인벤토리 관리 시스템이 이미 시중에 존재한다.
 
6. 워크플로 엔진
여전히 독자적인 워크플로 엔진을 만드는 사람들이 있다. 이들은 학교에서 상태 시스템에 대해 배웠지만 졸업 후 오픈소스 액티비티(Activiti), JBPM 등에는 관심을 두지 않은 사람들이다. 어떤 일이 발생하고, 상태가 발생하고, 상태를 저장하고, 그 상태를 사용해 그 지점에서 계속 진행한다. 그게 전부다. 이 기능을 하는 프로그램을 100개 더 만들어봤자 아무 필요도 없다.
 



2013.01.03

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

Andrew Oliver | InfoWorld
다른 프로젝트와 오픈소스에서 재사용할 수 있는 좋은 코드가 있거나 심지어 원하는 기능을 하는 상용 제품이 있는 경우라도, 많은 개발자가 직접 소프트웨어를 만들기를 좋아한다. 다른 누구도 자기만큼 그 일을 잘 하지는 못한다는 자부심이 원인일 수도 있다. 또는 시스템 레벨에서 코드의 작동 원리를 이해하기 위해 학생이 직접 컴파일러를 만들어야 하는 컴퓨터 과학 전공 프로젝트를 수행하면서 몸에 들인 습관 탓일 수도 있다.
 
이유가 무엇이든 자체 코드를 개발하다 보면 시간과 노력이 소모되고 버그가 발생할 소지도 있다. 새 코드는 검토와 테스트를 거친 기존 코드에 비해 버그가 존재할 가능성이 더 높다. 직접 시작하지 말아야 할 소프트웨어 프로젝트의 종류에는 다음과 같은 9가지가 있다. 순위가 높아질수록 피해야 할 생각임을 의미한다.
 
9. 부하 테스트 프레임워크(웹 애플리케이션용)
특히 웹 애플리케이션을 제외한 부분에서 극히 소수의 경우를 제외하고 부하 테스트 도구는 이미 존재한다. 새 도구를 만들 이유가 없다. WebPerformanceInc.com과 같이 대신 해주는 웹 사이트부터 로드러너(LoadRunner)와 같이 거추장스럽고 불편하지만 오랜 시간을 거쳐 숙성된 도구에 이르기까지, 부하 테스트를 위해 필요한 모든 것이 준비되어 있다. 셀레늄(Selenium), 테스트메이커(Testmaker)와 같은 오픈소스 도구도 있다. 자기만의 부하 테스트를 만들어야 하는 경우는 있겠지만, 웹 애플리케이션을 위한 자체 부하 테스트 도구를 만들어야 할 필요는 없으니 하지 말길 바란다.
 
8. 캐시(특히 분산 캐시)
NoSQL 전에는 자기만의 캐시를 만드는 것은 회사 사장에게서 연구 개발 자금을 확보하기 위한 좋은 수단이었다. 그렇게 해서 직접 벤처 기업을 시작해 타히티로 은퇴하기 전에 거대 기업에 매각되길 희망할 수 있었다. 그러나 오늘 새 프로젝트를 시작한다면 아마 자금을 구하지 못할 것이다. VC들은 지나간 유행에 자금을 대려 하지 않기 때문이다.
 
그래도 문제는 없다. 직접 캐시를 만들지 않아도 된다. 물론 기술적으로 캐시 만들기가 어려운 일은 아니지만, 잘못 만든 캐시는 부하가 큰 상황에서 시작할 때 데이터베이스를 죽이고 메모리를 누출시키거나 쓰레딩 문제를 일으키곤 한다. 젬파이어(Gemfire), 테라코타(Terracotta), 인피니스팬(Infinispan) 또는 코히어런스(Coherence)와 같은 기존 캐시 도구 중 하나를 위한 맞춤형 캐시 로더 또는 캐시 스토어를 만들어야 할 수는 있다. 게다가 이러한 도구들 중 일부는 오픈소스이므로 꼭 필요하다면 고쳐서 쓰면 된다.
 
7. 인벤토리 시스템
인벤토리 관리나 공공 도서관 운영이나 같은 개념이 적용된다(도서관은 전자책을 두려워한다는 부분을 빼면). 약간의 커스터마이즈 작업이 필요할 수는 있지만 오픈소스 OneCMDB, IBM의 Taddm, HP의 UCMDB 등 여러 가지 범용 인벤토리 관리 시스템이 이미 시중에 존재한다.
 
6. 워크플로 엔진
여전히 독자적인 워크플로 엔진을 만드는 사람들이 있다. 이들은 학교에서 상태 시스템에 대해 배웠지만 졸업 후 오픈소스 액티비티(Activiti), JBPM 등에는 관심을 두지 않은 사람들이다. 어떤 일이 발생하고, 상태가 발생하고, 상태를 저장하고, 그 상태를 사용해 그 지점에서 계속 진행한다. 그게 전부다. 이 기능을 하는 프로그램을 100개 더 만들어봤자 아무 필요도 없다.
 

X