방금 델마당 자유게시판에 델파이와 C# 중에서 어느쪽이 생산성이 높을까, 라는 글이 올라와서 댓글을 썼는데...
제 개인의 의견입니다만, 우리 포럼 분들께도 소개하고 싶어서 다시 퍼올립니다. 웃샤~

遠野 님이 올리신 글-----------------------
> 둘다 쓰고 있는데.. .net 플랫폼을 사용해도 전혀 문제가 없는상황이라면...
>
> Delphi-Win32 를 쓰는것과 C#.net 을 쓰는것중 어떤쪽이 생산성이 좋다고 생각되시나요?
>
> 델마당 여러분들의 의견을 듣고싶습니다


제 생각으로는... 생산성만 따지면 당연히 C#이 낫다고 생각합니다.
그리고 C#보다는 자바가 낫다고 생각하고요.

생산성은 해당 언어나 환경에서 지원하는 편의 기능이 얼마나 많으냐보다는 얼마나 개발자를 제한하느냐에 많이 좌우된다고 봅니다. 생산성을 극대화하자면 개별 개발자가 권장되고 일반적이고 예상되는 기법만 사용해서 개발하는 것이 좋지요.

델파이나 C#이나 편의 기능은 거의 비슷하다고 생각하지만, 닷넷 환경에서는 포인터처럼 여러가지 저수준 접근을 제한하고 있지요. 이런 저수준 접근의 가능성은 개별 개발자의 자유도를 높여줍니다. 이게 개발자 개인의 입장에서는 좋은 일이겠지만, 프로젝트 전체를 보면 일정 준수에 마이너스가 될 여지가 많습니다.

예를 들어 포인터를 잘 이용하면 멋지게 성능을 높일 수 있지만 대신 버그의 가능성은 그만큼 더 높아집니다. 딱 거기서 버그가 발생한 경우가 아니라도 일반적으로 저수준 접근은 코드가 더 길어지는 경향이 있으므로 리뷰해야 할 코드의 양도 더 많아지고요.

자바와 닷넷이 저수준 접근을 제한한 이유도 바로 이것입니다.
저수준 접근을 제한해서 개발자의 자유도를 제한하는 만큼 생산성이 더 높아집니다.

가비지 컬렉션 같은 기능은 개발자에게 메모리 리크의 걱정을 없애주므로 생산성 면에서는 좋지만,
개발자가 스스로 적절한 메모리 관리를 했을 때만큼 성능이 높아질 수는 없습니다.

업무 개발에서 디자인 패턴이 환영받는 것도 같은 이유로 볼 수 있습니다.
검증된 패턴을 이용해서 코딩하면 당장 코딩할 때의 생산성도 높아지고, 제3자가 코드를 보더라도 해당 부분의 버그 가능성을 금방 판단하고 넘어갈 수 있으니까요.

따라서 생산성만을 고려한다면 자바가 닷넷보다 더 나은 환경입니다.
닷넷의 경우에는 자바를 따라가면서도 개발자들을 끌어들이려고 자바보다는 저수준 접근을 열어주었기 때문에 역시 자바보다는 예상치 못한 버그의 가능성이 높습니다.

프로젝트 전체의 생산성만 따지자면 그렇지만... 역시 개별 개발자의 입장에서는 또 별개의 문제입니다. 자바나 닷넷처럼 생산성을 개발자의 자유도보다 우선한 환경에서는 개발자가 쉽게 코더로 전락합니다. 개발자가 구사 가능한 코딩의 방법이 한정되어 있기 때문에 정형화된 업무에서는 어느 개발자가 투입되더라도 코딩이 상당히 비슷비슷할 수밖에 없습니다. 개발자가 불만을 품고 튀어나가도 또 새 개발자를 뽑아서 채워넣으면 금방 땜빵이 가능하니 업체나 관리자의 입장에서 개발자를 중시할 이유가 없습니다. 당연히 개발자 대우는 꽝이 됩니다.

물론 델파이에서도 세부적인 개발 및 코딩 지침을 마련하고 잘 관리하면 같은 생산성을 낼 수 있을 겁니다.
하지만 그만큼 더 능력있는 관리자가 필요하거나 관리자의 노력이 더 많이 들어가겠지요.

또 성능 최적화의 문제는 더욱 더 그렇습니다.
자바나 닷넷에서는 상황에 따른 최적화 방법이 네이티브보다 제한되어 있기 때문에 성능 면에서 네이티브와 같은 수준이 될 수가 없습니다. 가끔 Hello world 예제 수준이나 단순한 for문 반복의 속도만 측정해서 네이티브와 같은 수준의 성능이다, 라는 식으로 개발자를 현혹하는 걸 보는데, 실무에서 매번 Hello world만 개발하는 것이 아니잖습니까. 보통 성능 최적화는 전체 코드에 대해 하는 것이 아니라 중요한 병목지점마다 적절한 최적화 코딩을 해주는 것인데, 여기서 저수준 접근이 이용되는 경우가 많습니다. 따라서 성능 최적화의 면에서 자바나 닷넷은 결코 네이티브를 따라올 수가 없습니다.

요약하자면, 생산성이 중요하기는 하지만 전부는 아니라는 겁니다.
그리고 관리자의 능력과 노력에 따라 델파이에서도 비슷한 생산성을 낼 수 있습니다.

극단적인 예를 들자면, 업무 프로젝트에서 일반적으로는 동적 할당 등 포인터의 사용을 개발자들에게 금지시키고, 꼭 필요한 경우 관리자의 사전 승인하에만 사용하도록 제한하는 것도 가능할 것입니다. 또 화면 작업에서 사용을 허용한 컴포넌트와 데이터 처리 방식을 세세하게 지정하고 다른 방법이나 컴포넌트를 사용할 때는 역시 사전 승인이 필요하도록 할 수도 있습니다.

개별 개발자의 입장에서 이런 극단적인 제한에서 개발하기가 갑갑하겠지만 델파이와 비교하자면 자바와 닷넷의 개발 환경이 실제로 그렇습니다. 그러니까 코더지요. 관리자의 승인 여부와 무관하게 환경의 제한 때문에 아예 사용 자체가 불가능한 경우가 더 많으니 더 나쁘지요.

굳이 엄밀히 따지자면, 자바와 닷넷이 어떤 경우에도 무조건 생산성이 높은 것이 아니라, 고만고만한 관리자와 고만고만한 개발자들, 고만고만한 개발 방법으로 대충대충 개발하는 경우에 생산성이 월등한 것입니다. 관리자와 개발자가 뛰어날 수록, 또 더 노력할 수록 그 차이는 줄어들 겁니다.