|
|
||||||||
| 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지 |
|
김형준님,
닷넷 자체에서 지원하지 못하는 기능은 거의 없다...라고 하시면, 대략 난감한데요. 스스로 말씀하신 바와 같이 Win32와 동일한 레벨의 기능을 다 지원하지 못하지 않습니까. 닷넷에서 제공하는 Win32 해당 기능이 상당히 많을 수는 있어도, 그게 충분한지 아닌지는 마이크로소프트가 판결하는 것이 아니라 프로젝트 성격에 따라 천차만별이 되는 거 아닌가요. 성격에 따라 닷넷에서 제공하는 해당 기능이 한참 모자라는 프로젝트도 흔히 있을 수 있다는 거죠. 'Win32 기능 중에서 단 하나만 빼고 다 지원한다' 뭐 이런 수준도 아니고 말이죠. 그리고 Win32 API를 쓰면 된다고 하셨지만, 제가 보기엔 PInvoke를 통해서 호출해야 하는 건 뭐죠? PInvoke 방식을 스스로 '삽질'이라고 표현한 것을 여러번 봤는데요. PInvoke를 정확히 이용하는 방법을 소개한 PInvoke.NET라는 영문 위키 사이트까지 있고, 이 사이트가 많은 닷넷 개발자들의 추천 사이트더군요. 한마디로 따로 공부를 해야 할 정도라는 얘기 아닌가요. 그럼 VB 6에서도 Win32 호출을 할 수 있다! 라고 말하는 거나 별로 차이가 없어보이는데요. 게다가 포인터를 사용하는 API 호출을 하려면 그냥 컴파일하면 에러가 나고 프로젝트 설정에서 '안전하지 않은 코드 블록 허용' 옵션을 설정해야 하는 건 어떤가요. 안전하지 않은 코드를 허용한다면 닷넷은 Win32 네이티브에 비해 무슨 이점이 있는 건가요. 이 옵션을 설명하는 문서마다 다들 '가능하면 사용하지 말라'고 하는 건 무엇 때문인가요. 참고로 델파이의 현재 버전인 2006은 1.0이 아니라 1.1을 지원하고 있습니다. 2.0 지원 버전은 작년부터 베타 테스팅중이고, 저도 참여하고 있습니다. 닷넷에는 별로 관심이 없습니다만. Orcas도 출시된 제품이 아닌 현재 베타 버전이죠? 그럼 지금 닷넷의 최신 버전은 3.0이라는 건데, 이건 사실 2.0의 다음 버전이라는 개념이 아니라 2.0에 추가되는 플러그인 형태로 알고 있습니다만. 3.5도 그런 형태일 거 같은데, 아닌가요. 그리고, 코드기어가 닷넷 2.0 지원 버전을 내놓는 것이 늦어진 것은 김형준님이 생각하신 것과는 다른 이유 때문입니다. 말씀드렸다시피 델파이 닷넷의 2.0 지원 버전인 2007 버전은 작년부터 베타테스트가 진행되고 있는데, 원래는 올해 초에 출시 예정이었죠. 그런데 소비자인 개발자들이 최신 버전의 닷넷 지원은 별로 중요하지 않으니, Win32 지원 버전을 더 강화해달라고 빗발치게 요구했었습니다(저도 그중의 한명이었구요). 그래서 그런 요구대로 코드기어가 계획을 전면 수정해서 닷넷 버전 출시를 연기하고 Win32 버전을 강화해서 내놓은 겁니다. 그 결과로 나온 델파이 Win32 2007과 C++빌더 2007을 단적으로 설명하자면, 개발툴 자체의 기능과 성능, 안정성이 대폭 향상되었고, 게다가 비스타의 글래스 효과를 현재 버전의 비주얼스튜디오보다도 더 잘 지원하고 있으며, 더불어 한번 빌드한 단일 실행 파일을 비스타와 이전 버전의 윈도우 어디에서도 실행시킬 수 있다는 겁니다. 제가 보기에는 MS에게 비주얼베이직의 Win32 버전을 계속 출시해달라는 청원 운동이 아직도 계속되고 있는 걸 보면 정말 안스럽습니다. MS가 자사의 전략을 수정해가면서 개발자들의 요구를 받아준 적이 있는지요. 지금도 Win32 기반에서 비주얼 C++, 비주얼 베이직의 옛 버전들을 가지고 개발하는 경우를 흔히 보는데, MS가 개발자를 존중하기는 하는 건가요. 이런 이유로, 델파이에서 닷넷 2.0 지원이 늦어지고 있는 것은 아쉽기는 커녕 개발자들의 열렬한 지지를 받고 있습니다. 바로 개발자들이 원했던 거거든요. 닷넷 매니아들의 입장에서는 MS가 버린 플랫폼에 집착한다는 생각을 하실지 모르겠습니다만, MS가 버렸든 말든 실제 시장은 아직 닷넷보다는 Win32로 돌아가고 있는 것이 현실이죠. 솔직히 닷넷이 주도하게 되는 시절이 올지, 저는 정말로 의심스럽습니다. 뭐 세월이 많이 흘러서 언젠가는 닷넷이 주도하는 시대가 올 수도 있습니다만, 델파이가 MS보다 닷넷 지원이 반발짝 정도씩 늦어지고는 있어도 충실히 따라는 가고 있고, 게다가 기존의 Win32 소스를 약간만 수정하면 닷넷 바이너리를 얼마든지 만들 수 있는 만큼, 델파이 개발자들은 닷넷 시대에 대해 준비조차 필요가 없습니다. C++빌더에서도 그런 지원이 준비되고 있고요. 그러니 델파이 개발자를 안타까워하실 필요는 조금도 없답니다. 오히려 제가 닷넷 개발자들이 안타까운데요. 그렇지 않은가요? 말씀하신 것처럼 닷넷에서 Win32를 호출하기 위해서는 비베처럼 호출하고자 하는 Win API 함수의 프로토타입(선언)을 해줘야 합니다. 하지만 Win API의 개수가 수천개나되니 일일이 선언하는것은 큰 일이구요. 그래서 나타난 것이 말씀하신 PInvoke.NET 사이트입니다. 모든 Win API의 선언문이 C#이나 VB.NET 등에 맞게 프로토타입을 제공해주고 있으니까요. 닷넷에서 지원하지 않는 기능(하지만 추후엔 분명이 지원하게 되겠지만)에 대해서 Win API를 사용해야 되는데, 이때 그 기능을 위한 API만을 선언해주면 되는 것이지요. "VB 6에서 Win32 호출을 할 수 있다!"라고 말하는 거나 차이가 없는게 아니라 .NET도 비슷한 방식으로 Win32 API를 호출할 수 있습니다. 분명 VB6도 Win API를 호출할 수 있습니다. 구차하게 호출을 원하는 API에 대해서 포르토타입을 선언해줘야 하므로 VB 6가 Win API를 호출은 뭔가 비정상적이다라고 할수 없습니다. 델파이 역시 windows.pas 파일 안에 수천개나 되는 Win32 API의 프로토타입을 일일이 선언하고 있는데요. 단지 볼랜드라는 회사가 일반 개발자들의 노가다성 코드를 대신해줬다고 볼수도있겠지요. 이건 그 C나 파이션 등과 같은 어떤 언어도 마찬가지입니다. 하지만 비베나 .NET언어에서는 델파이처럼 MS에서 모든 Win API에 대한 프로토타입을 지원하고 있지 않은데.. 그 이유는 기존의 기능을 개발자들이 남용하지 않고 지양하도록 유도하기 위함이라고 생각합니다. 기존의 Win API는 객체지향이 아닌 함수지향입니다. 이부분에 대해서는 참 말이 많았지요. 그래서 기존의 기술을 지양하고 새로운 기술을 통해 문제 해결을 제안하고 그렇지 못할 경우 버전업을 통해 개선을 하고자 함입니다. 하지만 경우에 따라서는 기존의 기술을 사용할 여지를 열어 놓은 것이라고 할수있지요.
또한 어떤 Win APi를 사용하기 위해서는 '안전하지 않은 코드 블록 허용' 옵션을 활성화시켜야 한다는 말씀에 대한 설명입니다. 이것은 ActiveX에 대한 문제점과 같은 맥락으로 이해할 수 있습니다. 무분별하게 모든 API를 사용할 수 있는 전지전능한 ActiveX와는 다르게 .NET에서는 어떤 기능, 즉 시스템의 보안에 문제가 있는 것 등에 관한 기능의 수행에 있어서는 안전하지 않는 코드 불록 허용 옵션의 활성화가 필요합니다. 이것은 추후에 .NET용 컨트롤을 만들때 "안전한 코드 불록"만을 사용해서 개발했을시 이 컨트롤은 절대로 시스템을 위해하지 않는다는 보장이라고 생각할 수 있습니다. '안전하지 않는 코드 블록 허용'은 C/S에서는 문제가 크게 않습니다. 바로 웹에서 문제가 되는 것이지요. 그리고 .NET3가 단지 .NET2위에 설치되는 것이 문제점이라고 하셨는데.. "이게 뭐..?"라고 대답하고 싶군요. 기존의 프레임워크를 기반으로 해서 새로운 프레임워크가 설치되는 것, 말씀하신 플러그인 방식(?)이라는 것이 새로운 버전을 배포하는 방식에서 문제가 된다는 것인가요? 닷넷1에서 닷넷2로의 버전업은 기능면에서도 많은 개선이 있었지만 안정성의 면이 더 컸다고 생각합니다. 하지만 닷넷3은 완전이 새로운 개념의 프레임워크와 개발방식입니다. WPF, WCF, WF 등과 같은 프레임워크를 한번 접해 보신후에 말씀을 하시고.. 단순이 기존 기술 위에 새로운 기술을 덮었다는 점이 문제다.. 라는 말씀은 옳지 않다고 봅니다. 이것은 오히려 닷넷2로 개발된 것은 닷넷3에서 그 어떠한 코드의 수정, 단 1바이트 문자도 수정 없이 그대로 사용할 수 있다는 점입니다. 완벽한 호환성의 지원이지요. 델파이의 windows.pas 파일에 API 함수 프로토타입을 선언해놓은 것과 PInvoke를 비교하는 건 좀 무리인 듯 싶은데요. 델파이의 windows.pas 파일에 선언된 Win32 API 프로토타입들은 C++의 헤더 파일과 역할이 똑같고 C++과 접근 레벨과 접근 방식 등 모든 면에서 똑같습니다.
말씀하신대로라면, 닷넷에서 PInvoke를 통해 Win32 API를 호출하는 것이, 단지 프로토타입을 미리 선언해놓지 않았을 뿐 C++에서 Win32 API를 호출하는 것과 똑같은 레벨에 똑같은 방식이라는 말씀이신데요. 과연 그렇습니까? 제가 여러 사이트를 통해 알고 있는 것과는 완전히 아와 어가 다른 말씀이신데요. 만약 그렇다면, 말씀하신 것처럼 windows.pas와 같은 파일 하나만 달랑 닷넷 개발자들 사이에 공유하면 그만이지, PInvoke.NET와 같은 위키 사이트가 닷넷 개발자들 사이에 '추천 사이트'로 인기를 끌 이유가 뭐가 있나요? 먼저 Win32 API를 거론하신 걸 보면 Win32 API에 상당히 익숙하신 듯 한데요. 그 엄청난 콜백 함수들과 복잡한 구조체 매개 변수들, 이런 API들을 C++에서 호출하는 것과 같은 수준의 편리함과 에서 호출이 가능하다는 말씀이신가요. 그런데 그게 삽질이라는 이유로 C++ 인터롭으로 dll을 만들어서 C#에서 호출하는 게 낫다는 닷넷 개발자분도 있군요. MSDN에서 PInvoke를 사용하면 성능이 떨어진다고 되어 있는 것은 또 뭐죠. "PInvoke는 한 번 호출할 때마다 10개에서 30개의 x86 명령을 실행하는 오버헤드가 발생합니다. 이러한 고정적인 성능 비용 이외에도 마샬링을 사용하면 오버헤드가 추가로 발생합니다. ... 성능을 향상시키려면 호출별로 데이터를 더 적게 마샬링하는 호출을 더 많이 사용하는 것보다 많은 데이터를 마샬링하는 PInvoke 호출을 가능한 한 더 적게 사용해야 합니다." 그래서 PInvoke를 쓰는 대신 C++ 인터롭을 쓰도록 권하고 있군요. 게다가 어떤 인터롭을 쓰던 썽킹 때문에 성능이 저하된다고 써있네요. 뭐 굳이 이런 걸 뒤져보지 않아도 닷넷에서 win32 콜이 성능이 떨어질 것은 닷넷의 특성상 상식적으로 짐작이 가능한 부분이 아닙니까. 뒤적거리다보니, 포팅 과정에서 잦은 GDI 호출을 PInvoke로 처리하려고 노력하는 딱한 초보 닷넷 개발자도 있더군요. 그렇게 드문 케이스도 아니겠죠. 하긴 닷넷에 네이티브만큼의 고성능을 요구하는 자체가 너무 과도한 바램이긴 합니다. 아마도 닷넷 애플리케이션이 Win32에 비해 성능이 떨어지지 않는다는 MS의 주장을 곧이 곧대로 믿는 닷넷 매니아분들도 적지 않겠지만, 이건 기본적으로 스캇 맥닐리가 자바가 C++보다 성능이 떨어지지 않는다고 허풍을 쳐댔던 것과 조금도 다르지 않은 겁니다. OS를 만든 MS니까 자바보다는! 낫겠지, 라고 말하면 어느 정도 맞을 수 있겠지만, 어떻게 돌려서 말해도 네이티브가 아닌 pcode에 가까운 것이 닷넷인데 네이티브 Win32 애플리케이션만큼 성능이 나온다고 하면 말 자체가 어색해지지 않습니까. 이런 종합적인 배경에서 제가 닷넷의 Win32 API 지원을 닷넷 이전의 VB와 비슷하다고 한 겁니다. 알아보면 알아볼 수록, VB에서의 경우보다 더 심하면 심했지 전혀 나은 거 같지는 않은데요. 참고로, 같은 비주얼스튜디오 개발자들 사이에서도 C++ 개발자들이 VB 개발자들의 삽질을 비웃는 것을 아주 자주 봤었는데, VB에서 Win32 API를 충분히 지원한다고 말하면 다들 웃었었죠. '안전하지 않는 코드 블록 허용' 옵션에 대해서도 한마디 더 하죠. 제가 그 옵션을 문제삼은 것은 어떻게 문제가 되고 안되고가 아니라, 전체에서 비중이 크지 않은 몇줄의 코드 때문에 안전하지 않은 코드를 허용하려면 왜 굳이 성능도 떨어지는 닷넷을 선택할까요? 네이티브보다 안전하다는 것이 닷넷의 가장 큰 강점이 아닌지요. 그래서 자바와도 경쟁이 가능한 거고요. 그런데 안전하지 않은 코드를 허용한다, 몇줄의 코드 때문에 개발자를 예상치 못한 에러로부터 안심시키지도 못할 거 같으면 그냥 다른 강점들이 많은 네이티브를 선택하는 게 상식적인 판단일 거 같은데요. 게다가, 웹에서만 문제가 된다고 하셨지만, 설명하신 논지대로라면 웹이 아닌 씬 클라이언트나 실버라이트에서도 똑같이 적용되어 문제가 되겠군요. 인터넷을 통해 배포하니까요. 그런데 이 두가지는 모두 MS가 상당한 공을 들여서 밀고 있는 기술인데... 어떡하죠? 그럼 닷넷 개발자들에게 실제로 자주 영향을 미치겠군요. 마지막으로.. 다시 읽어보시면 아시겠지만, 저는 닷넷 3.0이 닷넷 2.0 위에서 돌아가는 것이 문제라고 말하지 않았죠? 제가 말한 의미는 델파이 닷넷에서 VCL.NET의 닷넷 지원 코드를 엎지 않아도 되고, 기존의 닷넷 2.0 지원 코드는 그대로 두고 새로운 3.0 지원 코드만 추가하면 그만이기 때문에, 1.1에서 2.0 지원으로 넘어가는 지금 단계보다는 상대적으로 3.0 지원이 쉬울 거라는 의미의 얘기를 한 것 뿐입니다. 사소한 부분을 너무 심각하게 읽으신 듯 하네요. 쓰고 나서 보니, 나름대로 진지하게 쓴다고 노력했습니다만 좀 신랄하게 된 것 같습니다. 지금 자야 할 시간이라 고치지는 못하고, 너무 무례했다면 양해를 부탁드립니다. 반론은 얼마든지 환영입니다만, 제가 닷넷의 장점을 무시하는 것도 아니고, 제 개인적인 생각에는 장단점의 구분이 명확한 닷넷을 가지고 단점을 단점이 아니라고 너무 주장하신 듯 합니다. 닷넷의 장점은 저도 분명히 알고 있습니다만, 적어도 제가 개발하는 환경에서는 닷넷의 장점보다 단점이 더 크거든요. 지금 닷넷으로 가기를 거부하고 Win32 환경에서 개발하는 다수 개발자들도 같은 이유일 겁니다. 제가 보기에 MS의 주장과는 달리 자바/닷넷과 네이티브는 상호 보완적인 것이지 대체 가능한 것이 아닙니다. C#이 C++을 계승한 게 아니듯이 말입니다. 그래서 닷넷 환경에서 Win32 네이티브와 장단점 면에서 경쟁할 필요도 없습니다. 그런 경쟁을 시키려는 것은 하루빨리 더 많은 Win32 개발자를 닷넷으로 옮겨놓고 자바와 박치기를 시키려는 MS의 바램일 뿐이지, 개발자나 고객들의 입장과는 무관하죠. 관련 글 리스트
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright © 1999-2015, borlandforum.com. All right reserved. |
또한 말씀하신 것 중에 닷넷 자체에서 지원하지 못하는 기능은 거의 지원 불가능하다는 말씀에 대해서 한말씀 드리면.. 닷넷 자체에서 지원하지 못하는 기능은 거의 없는 듯하구요. ^^; 또한 지원하지 못하는 기능에 대해서 기존의 Win API를 .NET에서 사용하면 됩니다. 꼭 닷넷이라고 해서 기존의 기술을 완전 무시하는것은 아닙니다. MS가 그래왔듯 기존의 기술에 대한 호환성을 최대한 살려왔기에 .NET 역시 Win API를 섞어서 개발할 수 있습니다.
그리고 델파이는 현재 .NET 1.0만을 지원하고 있는데요. 추후 2.0을 지원한다는 계획을 가지고 있다고 합니다. 하지만 문제는 .NET의 최신 버전은 3.0을 지나 3.5가 최신 개발툴(코드명: Orcas)와 함께 배포되고 있습니다.
극히 주관적인 생각입니다만.. 닷넷을 지원하는 델파이에서 항상 느끼는 안타까운 점이 바로 이점입니다. 어쩔수없이 MS를 따라가야만 하는 상황말이지요..
이상입니다.