![]() |
|
||||||||
경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지 |
|
다음으로, 닷넷과 네이티브의 성능 문제에 대한 원론의 문제로 돌아가지요.
깔쌈보이님이 근본적으로 간과하고 있는 문제가 있습니다. 그건, 닷넷, 자바가 아닌 네이티브를 사용하고 있는 개발자들은 대부분 네이티브가 필요한 분야에서 일하고 있다는 것입니다. 물론 그 반대도 마찬가지입니다. 말씀하신 대로 자바나 닷넷이 더 유리한 부분도 있습니다. 생산성 외에도 짚을 부분은 적지 않을 것입니다. 그런데 그런 업계에 있고 그런 업무를 개발하고 있는 개발자는 거의 다 자바나 닷넷으로 다 넘어간 상태입니다. 거기에는 깔쌈보이님도 포함되겠지요. 저희 집사람도 90년대 말까지는 파워빌더와 VB를 주로 사용했었는데 99년쯤에 자바로 넘어갔고, 지금은 대기업 SI 회사에서 스카웃을 받는 나름 잘나가는 자바 아키텍트구요. 하지만 지금도 네이티브에 남아있는 개발자들은, 네이티브에 남아있을 여러가지 이유와 상황들이 있기 때문에 남아있는 것입니다. 물론 그 이유들에는 전반적인 속도와 성능의 문제도 있을 수 있고, 저수준으로 더 깊이 접근할 수 있는 접근성의 문제도 있겠고, 단지 가상과 네이티브의 차이가 아닌 기능적인 차이도 있을 수 있습니다. 또 무시할 수 없는 것이 기존의 광대한 코드베이스도 있겠고요. 흔히 단순한 생각만으로, 오래전의 코볼이나 포트란이 거의 퇴출되었으니(완전히 퇴출된 건 아니죠) 그 전철을 따라 C, C++, 파스칼 등의 네이티브 언어도 자바와 닷넷에 의해 대체될 것이다, 즉 이전의 것들은 항상 새로운 것으로 대체된다, 라는 단순한 생각을 하는 분들도 있습니다만, 새로운 것이 일반화된다고 해서 이전의 것이 반드시 없어지는 상황만 있는 것이 아니라 공존하는 경우도 흔히 있습니다. 닷넷과 자바의 가치는 네이티브를 완전히 대체할 수 있는 것이 전혀 아니기 때문에, 당연하게도 향후로도 오랫동안 양측이 공존하게 될 것입니다. 이것은 터치나 음성인식이 등장했다고 키보드가 단종되어버리지 않는 것과 마찬가지입니다. 터치와 음성인식이 아주 초보적이던 여러해 전에는 그런 예상을 한 분도 적지 않았겠지요. 터치와 음성인식이 실용화되면 키보드 따위는 바로 사라져버릴 거라구요. 하지만 현실은 전혀 다릅니다. 키보드가 언젠가는 사라질 수도 있겠지만, 그 시기는 아주아주 오랜 후여서 지금 우리는 미리 예측할 수도, 그럴 필요조차 없을 정도일 것입니다. 중요한 것은, 이 포럼에 계시는 분들은 어떤 이유로든 네이티브가 더 유리한 쪽의 개발을 하고 있는 분들이 절대다수입니다. 특히 깔쌈보이님은 업무개발 분야가 주업이신 것 같은데요, 우리나라의 전체 SW 업계를 다 털어본다면 업무개발에 종사하는 개발자가 압도적으로 많지만, 이 포럼에서는 아시다시피 업무개발 개발자는 많기는 해도 상대적으로 소수이고요. 업무개발이말로 닷넷과 자바의 강력한 생산성이 제대로 발휘되는 분야인데 말이지요. 개인적으로 제가 업무개발 업계 근처에 있기 때문에 깔쌈보이님이 닷넷의 강력함을 설파하는 말들은 무슨 말씀이신지 다 이해가 됩니다. 하지만 네이티브가 필요해서 네이티브 개발을 하는 개발자들이 모인 모임에서, 닷넷이 더 좋아, 해도, 그 이유는 달라도 각자 자신의 현실 경험에서 네이티브가 더 나았기 때문에 네이티브를 계속 고수하는 분들에게는 의미가 없는 외침이 될 뿐입니다. 키보드가 더 좋아서 키보드를 쓰는 사람에게 (일부가 아닌) 모든 작업을 터치로 하는 게 더 낫다고 설파해봤자 의미가 없는 것과 마찬가지죠. 어떤 측면에서는 닷넷이 더 낫다고 말씀하시지만, 그 말은 맞겠지만, 다른 많은 측면이 필요해서 네이티브를 쓰는 분에게는 의미가 없는 거죠. 하지만... 개인적인 측면에서 보면 좀 다릅니다.
앞에서도 썼다시피 저는 업무개발과 가까운 영역의 일을 합니다. 저는 화면 개발은 전혀 하지 않습니다만 업무개발을 위한 프레임워크와 아키텍처를 개발하는 게 주업입니다. 델파이와 C++빌더 자체는 업무개발에서 자바나 닷넷보다 생산성이 떨어진다는 것을 저는 충분히 잘 알고 있고, 제 프레임워크와 아키텍처의 목적이 성능 뿐만이 아니라 생산성에서도 자바와 닷넷을 따라잡도록 하는 것입니다. 물론 세세한 기능들을 따라가는 것이 아니라, 닷넷보다 많이 떨어지는 기능은 약간이라도 보완하고 앞선 부분은 더 앞서도록 해서 총체적으로 따라잡도록 하는 거죠. 사실 델파이를 포함해서 모든 네이티브 언어와 개발환경은 업무 개발에 절대적으로 필요한 생산성의 측면에서는 전혀 최적화되어 있지 않고, 자바와 닷넷은 거꾸로 업무개발에 가장 최적화된 환경이라고 할 수 있기 때문이죠. 그래서, 사실 업무개발이라는 것이 너무도 다양한 업계와 다양한 화면들, 목적들, 설계 의도가 있기 때문에 코드배틀이라는 게 현실적으로는 불가능합니다만, 저는 개인적으로 제 프레임워크를 가지고 깔쌈보이님과 코드배틀을 해보고 싶은 생각도 많이 들더군요. 그러니까, 네이티브를 선호하는 모든 업계를 상대할 것이 아니라 업무개발에 한정해서 논쟁을 하는 것이 적절하다고 보고요. 그래야만 생산적인 토론이 가능할 것입니다. 그리고 업무개발 업계에 한정해서 토론한다면, 깔쌈보이님께는 좀 허무한 일이겠지만, 저는 생산성 면에서 닷넷의 우위를 깔끔하게 인정합니다. ^^ 깔쌈보이님처럼 저도 닷넷을 좋아하는지라, 이번 논란을 흥미진진하게 관전하고 있었습니다.
잘 하지는 못해도 C#을 만지고 있으면 괜히 즐거워지더라고요... 지금 복기해보면... 간단하게 만드는 MP3 인코더? LAME 바이너리가 4초를 끊는데 C#이 0.4초?? 평소 지나가다님 글을 좋아하지 않았다면 거기서 이미 촉이 왔을텐데 말입니다. 세상에 잉여들이 얼마나 많은데, 혼자만 알고 있을거라 생각한데서 함정에 들어간거죠. 비슷한 일이 아주 오래전 델마당 게임란에서도 있었는데... (병규형님이 한 방에 정리해주셨던...) 그런 일을 경험하고도 정신연령이 어려서인지 가끔씩 이렇게 귀가 팔랑거리네요... ^^;; 임프님/
저는 civilian님의 말씀처럼 소잡을때 소잡는 칼을 쓰고, 닭 잡을 때는 닭잡는 칼을 쓰는 편입니다. 도살장 직원 입장에서 보자면 회사에서 소도 잡아라고 하고 닭도 잡아라고 하네요. 닷넷에 대한 표현을 많이 하다보니 많은 사람들이 당연히 저를 닷넷 개발자로 볼 것이라는 생각도 예상합니다. 프리랜서도 아니고, 회사 직원으로 존재하다보니 회사에서는 돈을 벌기 위해 다양한 형태의 일거리가 주어집니다. 저도 몇해전까지만 해도 제가 다니는 회사가 워낙 유별나서 그런줄 알았는데, 그게 아니더군요. 저와 같은 상황을 많은 다른 개발자들이 겪고 있고, 앞으로도 점점 더 요구받아 가고 있구요. 그래서 네이티브가 더 유리한 쪽으로 일을 할 지언정 네이티브만으로는 부족한 부분이 존재하는 개발거리가 더 많아지는 추세이고... 그런 관점에서 이젠 네이티브건 닷넷이건 자바건 간에... 어떨땐 소잡는 칼이 필요하고 어떨땐 닭잡는 칼이 필요한지 잘 이해를 한 다음 잘 사용하는게 좋다는 겁니다. 어휴~ 너무 닷넷 얘기를 많이 하는 바람에 제가 닷넷 전용 개발자로 인식되는 상황까지 오는군요 --; 아~ 솔직히... 제가 접할 수 있는 델파이 버젼들이 대부분 터보델파이를 비롯해서 개인적으로 구매한 이젠 강산도 변할수 있는 시간만큼 지난 버젼들이라... (솔직히 그 이후의 버젼들이 필요하지도 않지만...) 요즘의 델파이에 대해서 논 하라면 자신이 없습니다. --; 관련 글 리스트
|
Copyright © 1999-2015, borlandforum.com. All right reserved. |
코드배틀을 제안하던 글은, 내용만 보면 네이티브 코드를 올리면서 제안했으니까 마치 네이티브측에서 닷넷측으로 도전을 제기한 것처럼 보이는데요. IP 주소를 확인해보면 매번 '지나다가'님을 극찬하던 PC방과 동일한 인물입니다(동일한 PC방이 나옵니다). 그리고 매번 PC방에서만 올리는 걸 봐서는 이 PC방이 '지나다가'와 동일인이거나, 적어도 제 3자라도 '지나다가'와 유기적인 협조 아래에 맞장구를 쳐주는 가까운 지인이라고 보입니다.
즉 코드배틀 제안조차도 '지나다가'님의 공작이었고, 거기에 흥미진진하게 바라보던 우리 볼랜드포럼의 모든 회원들은 익명으로 이름을 바꿔가며 올리는 글들에 도매금으로 농락을 당한 것입니다. 자신이 네이티브 코드를 올려 배틀을 제안했는데, 며칠 후에 올린 C# 버전의 엔코더라고 올린 것은 실제로는 그 코드를 포팅한 것도 아닌 네이티브 GOGO.dll을 갖다 쓴 거죠.
저는 이 모든 게 사전의 시나리오였다고 의심합니다. 즉 GOGO가 자신이 익명으로 올린 다른 소스코드보다 훨씬 빠른 결과가 나온다는 것을 사전에 확인한 후에, 둘 중 느린 코드를 익명으로 올리면서 코드배틀을 걸고, 적당한 며칠 후에 다시 '지나다가'의 이름으로 GOGO를 이용한 버전을 (GOGO를 나름 철저하게 숨기고는) 올리고 자랑을 한 것입니다. 물론 이런 장난질이 가능했던 것은, GOGO가 빠른 성능에도 불구하고 개발자들에게 잘 알려져 있지 않기 때문이었죠.