'소스생성'에 해당되는 글 1건

  1. 2007.03.29 소스생성기술에 의존하지 마라 (2)

소스생성기술에 의존하지 마라

엔터프라이즈 자바 2007. 3. 29. 20:32 posted by 엔트웍스
요즘 세상에 소스생성기술은 새삼스러운 것이 아니다.
Rose나 Together 같은 모델링 도구의 forward engineering 기술은 물론이며,
Eclipse만 해도 상위 클래스의 생성자 정보를 토대로 생성자를 생성해 주기도 하고, property에 대한 getter/setter를 만들어 주기도 한다.
또 프로그래밍을 잘 하는 사람(혹은 귀차니즘이 심한 사람)은 한 두가지 쯤 사제 소스(혹은 SQL) 생성 툴을 가지고 있을 것이다.
프로그래머 입장에서 소스생성은 귀찮고 반복적인 작업을 꽤나 줄여주고, 경우에 따라서는 생산성을 높이는데 공을 세울 수도 있다.

그러나 프로젝트 관점에서는 소스생성은 아주 잘 써봐야 수% 비용밖에 절감할 수 없다는 것이 내 생각이다. 오히려 소스생성기술을 잘못 적용하면 절감은 커녕 비용이 증가할 위험이 더 크다.

우선 프로그래머가 프로젝트 전체에서 소스생성기가 생성해 주는 소스를 타이핑하는데 걸리는 시간은 아주 많아야 1%(본문에서 등장하는 수치는 모두 주관적이고 직관에 의한 수치이다)도 안되는 경우가 대부분일 것이다. 물론 %는 업무가 단순하고 소스 생성기가 좋을 수록 높기는 할 것이다.
나머지는 업무를 분석하고 이해하고 어떻게 프로그래밍할 지 고민하고 실행하고 오류 원인을 찾고 코드를 고치는 시간이다.
과연 이렇게 얻어지는 시간이 소스생성기의 구매/개발/학습/사용부담에 드는 비용을 상쇄할 수 있을까?

문제는 잘못 적용하면 소스 생성 기술이 오히려 독이 되는 경우가 있다는 것이다.

생성되는 소스가 오히려 잘못된 설계를, 잘못된 동작을 유도한다면?

또 아키텍처 혹은 정책이 변경되었는데 이 부분이 소스생성기술에 의존하고 있었다면, 기존에 생성되었던(게다가 십중팔구 추가/수정이 발생된) 소스 들은 어떻게 하는가?
어떻게 하긴... 모조리 찾아 내서 고치는 수밖에 없다.

더 심각한 경우는, 소스생성기가 아예 생성된 소스의 수정은 원천봉쇄하는 경우이다.
그런 경우를 못 본 사람이 더 많겠지만 최근 그러한 소스생성기의 존재를 확인할 수 있었다.
이 경우는 완전히 소스 생성기에 의존할 수 밖에 없으므로, 소스생성기 작성자(혹은 업체)는 100% 프로젝트 병목이 될 수 밖에 없다. 그리고 첨언하면 이 소스생성기는 상당히 안좋은  설계의 클래스와 엄청난 중복 코드를 생산하며, 보도 듣도 못한 제약사항 들이 곳곳에 숨어 있어서 하다보면 하나둘씩 머리를 쳐 든다.
(옛날에도 이러한 도구가 있었으나 곧 망했다고 한다. 그리고 현재에는 다른 도구가 이와 유사한 모습으로 작동하고 있다.)

소스생성기술은 잘만 선택(혹은 개발)하면 나름대로 괜찮은, 특히 프로그래머의 귀차니즘을 날려버려서 의욕을 북돋는 기술이 될 수 있다.
그러나 조금만 부주의하게 선택(주로 벤더의 부추김에 의해)한다면 아마 프로젝트는 생산성은 커녕, 그나마 얻는 수%의 생산성보다 훨씬 많은 비용을 지불하며 숨어 있던 위험과 제약사항에 빠져 허우적 댈 것이다.

프로젝트에서 다음의 원칙을 지킨다면 아마 이러한 위험은 피할 수 있을 것이다.
  • 소스생성기능을 강력히 자랑하는 도구는 피하라.
  • 소스생성기능이 없으면 개발자체가 불가능한 도구는 절대 잊으면 안된다. 깜빡하면 나중에 또 소개자료를 읽는 엄청난 손실이 생긴다.
  • 소스생성기술을 가지고 엄청나게 생산성을 높이려는 생각은 버려라. 잘만 적용한다면 수십%도 얻을 수 있겠지만, 일반적으로 5%만 얻어도 엄청난 생산성이라고 믿는 편이 낫다.


  1. Commented by Favicon of http://cbiscuit.info BlogIcon cbiscuit at 2007.03.31 01:00

    혹시... HOORO HOOREM 아니야?

    일부 지각있는 개발자들이 보고는 치를 떤다는.. 그..