델파이2005도 좋은 툴이긴 하지만...
사실 Win32 개발만을 목적으로 하는 경우에는 델파이7에 비해 추가된 기능은 별로 없으면서 로드 속도가 너무 느립니다.

반면 델파이2006(BDS2006)의 로드 속도는 획기적으로 빨라졌습니다. 툴에 추가된 기능이 훨씬 많은데도, 풀 로드를 해도
델파이7과 로드 속도가 별로 차이나지 않습니다. 게다가 BDS2006의 프로그램 그룹에는 BDS2006을 모두 띄우는 아이콘
외에 델파이 Win32, 델파이 닷넷, C++빌더, C#빌더의 아이콘이 따로 만들어져 있는데 이들 분리된 아이콘들을 클릭해서
실행시키면 해당 퍼스낼리티에 필요한 dll/bpl만 로드되기 때문에 로드 속도가 더 빨라집니다.

로드 속도가 빨라진 것은  FastMM을 적용한 결과이고 이것은 델파이로 만든 런타임에도 똑같이 적용되기 때문에
로드 속도 뿐 아니라 델파이로 만든 애플리케이션의 실행 속도도 빨라졌습니다. 뭐 기존 메모리관리 방식에서도 델파이
애플리케이션도 충분하다고 할 만큼 빠르기 때문에 웬만한 규모의 일반적으로는 체감하기 힘들겠지만 덩치가 아주 크거나
속도에 민감한 애플리케이션이라면 빨라졌다는 것이 느껴질 겁니다. (델파이2006 자신이 그 대표적인 예죠)

그리고... 델파이2006에서 추가된 컴포넌트가 몇개 있는데요. 카테고리버튼이라는 컴포넌트는 꽤 쓸만한 UI를 보여줍니다.
이걸 쓰면 한마디로 델파이2005나 델파이2006의 툴팔레트 UI를 만들 수 있는데요. 많은 기능의 아이콘들을 그룹별로
나누어 몽땅 때려박아야 할 경우에 아주 멋지게 구성할 수 있을 거 같더군요. 그 외에도 그리드패널 등의 몇몇 컴포넌트가
더 있는데 자세히 테스트해보진 못했습니다.

단점도 없는 것은 아닙니다. 일단 델파이7까지 익숙했던 전통적인 UI와는 모양새가 많이 바뀌어서 처음에는 불편을
느낄 수 있습니다. 그리고 VCL이 바뀌면서 주의해야 할 점도 몇군데는 있습니다. 예를 들면, TADOQuery의 SQL이던가
속성이 TStrings에서 새로운 타입인 TWideStrings로 바뀌었습니다. 이런 경우 TADOQuery의 SQL을 직접 액세스하는
경우라면 별 문제가 없겠지만, 이 속성의 경우 서드파티 등 컴포넌트에서 액세스하려고 한다면 직접 코드를 추가해줘야
하는 불편이 생길 수 있습니다. 이런 VCL 자체의 변경은 많지는 않지만 신경쓰지 않고 작업하다보면 하나씩 마주치게
되는 정도입니다.

결론으로 말하자면, 델파이6/7에서 델파이2006으로 업그레이드하는 것은 꽤 괜찮은 선택이라고 생각됩니다.
UI와 라이브러리의 업그레이드로 불편한 점도 없지는 않지만, 업그레이드 과정에서 어쩔 수 없는 부분일 거구요.
그리고 다음 버전으로 업그레이드를 미룬다고 해도 UI가 이전으로 다시 돌아가는 일도 없을 거고 또 VCL의 변경은
더 많아질 뿐일 것이므로 업그레이드를 지금 하느냐 미루느냐 고민할 필요는 없을 듯.

그럼...


양용성 님이 쓰신 글 :
: 안녕하세요
:
: 전 델파이 개발자인데요 ^^ 모두 그렇겠지만..
:
: 그동안 델파이6만 죽어라 한 3년 넘게 썼는데, 바꿔야 할 때가 된듯 해서 ..
:
: 왜냐 하면 보통 써드파티 프로그램들이 기술지원을 6까지 하더라구요.. 조금만 더 2006 지나면
:
: 델6에 대해 서드 파티 지원을 안할것 같은 예감이 듭니다.
:
: 사실 서드 파티 개발자들도 델6,7,8,2005,2006 다 테스트 할려면 시간이 많이 걸리쟎아요.
:
: 그래서 이번 신규 개발건에 델파이 버전을 바꿀려고 하는데 사실 닷넷은 거의 사용 안하니깐,
:
: 현재는 델7을 가장 유력시 생각하고 있는데 델2005나 2006으로 사용시 윈32만 개발할려구 한다면
:
: 너무 무겁지 않나 싶어서 여쭤뵙니다.
:
: 기존 델6,7 로 개발하던 것들은 델2005,2006 으로 작업시에 컴포넌트 변경 작업 외에 로딩 속도나
: 기타 컴파일 속도 등 개발환경에 대해 직접 사용해 보신 분들의 소감을 듣고 싶습니다.
:
: 사실 델6만 너무 오래 잡고 있으니깐 좀 뒤떨어지는 감 ^^ 도 있고해서 최신 버전을 사용할까 하는데
:
: 여러분 많은 조언 부탁드립니다.