지난번 글에서, 닷넷의 윈32 API 독점 기도 음모론과, 델파이의 장점인 자유로운 윈32 API 호출이 조만간 제한당할지도 모른다는 우려를 표명한 바 있다. 혹시 이글을 보고, 델파이를 사용하면서 VCL 메서드 호출보다, 윈32 API를 직접 호출하는 방식의 코딩이 더 바람직한 것이라고 오해하지 말아 주셨으면 한다. 예를 들어 리스트 박스에 아이템 하나를 추가하기 위해 vcl의 Add 함수를 호출하는 대신에, 윈 32 API를 호출하는 방식의 코드를 말한다.

델파이를 사용하면서 윈 32 API 호출을 쓸데없이 남발하는 방식으로 코딩하면 후일 무지 곤란하다. 실무 작업자들의 코드를 받아서 보면, 의외로 이런 황당한 윈 32 API 호출을 남발하는 경우를 많이 본다. 월등히 더 쉬운 델파이적 방법이 있음에도 불구하고, 윈 32 API 호출을 마구 한다는 것은 델파이 매뉴얼을 제대로 보지 않았다는 것 밖에는 달리 이유가 없다. 

혹자는 델파이 VCL호출보다 윈32 API 호출이 실행 속도가 더 빠르기 때문에, 속도 최적화적인 이유로 윈32 API 호출을 선호한다고 우기기도 한다. 그러나, 델파이 VCL호출과 윈32 API 호출의 속도 차이는 매우 미미하다. 이는 델파이의 네이티브 컴파일러 방식의 장점이기도 하다. 윈32 API 의 직접적인 호출과 델파이 VCL호출 사이의 미미한 차이를 고려해야만 할 정도로 속도 최적화가 필요한 프로그램은, 달나라에 로켓트를 보내는 프로그램 같이, 어떤 루틴의 실행속도가 나노 세컨드 이하의 초미세  단위로 실행 속도가 보장되어야 할 경우이다. 이런 초절정 속도 실행 보장 루틴은 지극히 드물며, 이런 루틴이 있다고 한들, 과연 윈 32 API의 직접적인 호출이 속도 최적화에 크게 도움이 될지는 매우 의심스럽다.

속도 최적화를 초절정 과제로 삼는 사람들의 소스를 받아보면, 의외로 전혀 엉뚱한 부분에 속도 최적화를 하고, 정작 중요한 루틴에는 최적화 꽝인 경우를 많이 본다. 아주 미미한 효과를 주는 속도 최적화는 실제 코딩에서는 대부분 말짱 꽝이다. 단순히 실수 대신 정수를 사용하면 더 빠르다라는 식으로는, 최적화가 제대로 이뤄지지 않기 때문이다.

윈 32 API의 직접적인 호출이 반드시 필요한 경우는, VCL에 그러한 기능이 없을 때만으로 제한해야 한다. VCL에 이미 동일한 기능이 있음에도 불구하고 윈 32 API를 마구 남발하면 후일 윈도우 버전이 바뀌면 무지 곤란해진다. 이는 VCL이 윈 32 API의 래퍼 역할을 해주는데, 직접적으로 윈 32 API를 호출해버리면 VCL의 이 좋은 장점을 고스란히 버리는 꼴이 되기 때문이다.

일반적인 VCL 방식으로 짠 델파이 어플 프로그램은 윈 95에서 윈 엑수피, 비스타까지 바로 실행되거나, 최악의 경우라 해도 컴파일만 새로 한번 더해주면 새로운 오에스에서 돌아가도록 하는데 별 문제가 없을 것이다. 그러나 윈 32 API를 마구 남발하는 식으로 개발하면 후일 새로운 윈도우 오에스가 나왔을 때, 모든 테스트틀 다시 해서 그 호출들이 제대로 동작하는지 필히 검사해야만 할 것이다.

VCL의 장점은 델파이 개발자에게 윈 32 API의 복잡성을 매우 단순화 해주는데 있다. 이 장점을 버리고 직접 윈 32 API를 호출해야 할 경우는 그리 많지 않다. 여러번 반복해서 이야기 하지만, 델파이 개발자들의 최우선 참고서는 델파이 매뉴얼이다. 다른 책을 봐야만 할 때는 델파이 매뉴얼에서 도저히 원하는 기능을 찾을 수 없을 때이다. 델파이 매뉴얼을 제쳐두고 윈도우 API나 다른 델파이 관련 서적을 먼저 보게되면 매우 곤란하다.