주정섭님이 저를 일컬어 '지나친 델파이 옹호론자'라고 하시는 것의 기준은 무엇인지요?
주정섭님에 비해 지나치게 옹호한다는 것인가요? 아니면 주정섭님이 이해할 수 없는 정도라는 것인가요?

IME 버그는 말 그대로 IME의 버그입니다. 안시코드에서는 나타나지 않고 유니코드 프로그램에서만 나타나죠. MFC로 작성한 프로그램에서도 나타나는 것을 여러번 봤습니다. 한마디로 말하자면 윈도우 최근 버전의 IME 자체가 걸레입니다. 하지만 델파이 XE에서는 그것도 패치했습니다. 재미있죠. 윈도우의 버그를 델파이가 피해간다. 이런 사례는 예전에 델파이의 구버전에서도 여러번 있었습니다.

제네릭 하나를 예로 말씀드렸더니 제네릭 하나 때문에 최신 버전을 살 수는 없다, 라고 하시는군요. 다른 추가되고 개선된 기능들도 살펴보시지요. 저라도 카메라 해상도 하나만 나아진 기종이 나왔다고 핸드폰을 바꾸지는 않습니다.

클라우드니 웹서비스니 하는 것들이 의심스러우실 수 있습니다. 저도 사실 의심스럽습니다. 그런데 다른 언어들이 현실적으로 델파이보다 앞서간다고 알려져 있는 것들이 그런 것들이니 주정섭님이 맘에 드시든 말든 쓰시든 말든 엠바카데로가 그런 기능들을 델파이에 추가하는 것은 당연한 선택입니다. 다른 언어들의 대세를 따라가지 않는다면 그게 리스크겠죠.

매뉴얼이 빈약해서 데이터스냅을 판단할 수 없다고 하셨는데, 그럼 애용하시는 렘오브젝트는 데이터스냅보다 얼마나 문서화가 잘되어 있어서 애용하시는지요. 지금 얼마나 나아졌는지 모르겠습니다만 제가 kbmMW를 주로 쓰던 몇년 전에 렘오브젝트의 문서화는 kbmMW나 거기서 거기 수준이었고 kbmMW의 문서화도 너무나 초보적인 내용 일색이어서 실무적으로 활용할 수 있는 예제들은 사실상 문서 없이 제가 직접 다 파들어가서 공부했습니다. 지금 데이터스냅의 문서들이 아주 충분한 수준은 아니지만, 그래도 최근까지 누적되어 계속 나오고 있는 데이터스냅 문서들은 kbmMW보다는 훨씬 많습니다.

첫버전부터 허접한 기술을 내놔서 고생시킨다고 하셨는데, 경쟁사의 기술들은 더합니다. MS나 자바 관련 기술들도 초기 버전에서는 아주 허접한 경우가 흔하고, 오히려 중간에 단종시켜버리거나 개발자 미치게 어정쩡하게 유지하는 기술들이 델파이보다 훨 더 많습니다.


저는 온라인에서건 오프라인에서건 국내의 어느 누구보다도 더 많은 델파이 개발자들을 만나봤다고 자부합니다. 온라인에서는 말할 것도 없고 오프라인에서 직접 얼굴을 마주하고 얘기를 나눠본 개발자가 수천명 정도는 됩니다. 외국의 서드파티 개발자들과도 아주 자주는 아니지만 꽤 많이 연락을 주고받아왔습니다. 데브기어에 들어가기 전에도 그랬고 그 이후로는 물론 더 많은 개발자들을 만났습니다. 그리고 그중 정말 많은 분들이 델파이에 대해 불만을 토로하신 것을 모두 들었습니다. 별의 별 부분에 대해 불만을 가지고 있는 것을 들어왔고요. 그런데 주정섭님과 같은 케이스는, 아주 없지는 않았습니다만 아주 극소수였습니다. 주정섭님이 어떻게 다르냐구요.

주정섭님은 저를 델파이 광신자라는 선입견이 가득한 눈으로 보시니까 제게 "충성심 강요적 글이다"라는 말을 서슴없이 하시는군요. 저 자신도 델파이나 그 벤더에 충성하지 않습니다. 제가 아는 한 저는 제가 아는 누구보다 델파이 벤더에 더 쓴 소리를 많이 해왔고 지금도 다른 한편으로 계속 투쟁중입니다.

글쎄요, 제 글 어디에서 광신적으로 델파이에 몰두하는 모습이 있나요. 물론 제가 델파이에 대한 만족도가 평균보다는 상당히 높은 것은 사실입니다만, 제가 만나본 델파이 개발자들중에서는 저보다 더욱 열광하는 개발자분들도 많았지만 제가 말주변이 좀 있어 더 많은 말을 할 뿐입니다. 그럼 그런 분들은 저보다도 더한 짐승이나 정신병자 수준이라고 주장하시겠습니까. 어찌되었든 누군가가 결과적으로 주정섭님이 이해하지 못하거나 이해하기 싫은 주장을 하면 그 상대는 무조건 광신자가 되어야 하는 것이 주정섭님의 판단 방식입니까. 이쯤 하면 주정섭님의 이번 글은 너무 과했다는 생각이 드시지 않으시나요.

안티를 하시려면 제대로 파악하시고 안티를 하시는 것이 서로 논쟁이 하는 것이 즐겁습니다. 주정섭님의 이번 원문은 비관적인 현실 때문이 아니라 현실을 비관적으로 보셨기 때문이라고 보이니까 즐겁기는 커녕 맥이 빠집니다. 주정섭님이 이번에는 제게 세월의 무상함을 느끼게 만드시네요.



주정섭 님이 쓰신 글 :
: 박지훈씨가 지나친 델파이 옹호론자 인것은 나도 이미 알고 있지만, 그래서 이전글에 과거 박지훈씨의 지나친 델파이 즉 코드기어 옹호론에 대한 글을 쓸까 싶었지만, 그것은 보류했는데...
:
: 이왕 말이 나왔으니.. 질문한 것에 대해서 답변을 하자면..
:
: 지네릭 즉 씨뿔로 치면 템플리트 기능은 매우 강력한 기능이며, 따라서 아주 오래전부터 그 기능이 델파이에 포함되기를 매우 고대했지만, 무려 2009에 그 기능이 추가되었고, 정확히 말하면 템플리트의 잡다한 버그가 패치되어 제대로 동작하는 버전은 2010 버전입니다.
:
: 문제는, 이미 잘돌아가는 기존 프로그램을 템플리트 한번 사용해 보잡시고 확 바꾼다는 것은 말이 안되는 것이며, 그 기능을 쓴다고 해서 당장 프로그램 속도나 생산성에서 비약적인 향상이 있어 보이는 것도 아닌 바에야, 템플리트나 익명 메서드 하나 사용해보자고, 한두푼도 아닌 델파이 신버전을 사기는 힘들거  같고, 따라서, 델파이로는 템플리트 코딩을 할일이 앞으로 없을 것 같습니다.
:
: 또한, 템플리트를 쓰자면 델파이 2010 이상을 사야하고, 2010을 쓰자면, 기존 코드의 한글 문제 즉 유니코드 문제가 아주 골치 아프게 되고, 기존 델파이 버전에 없던 희안한 IME 버그 때문에 머리 아파해야 하고... 설마 템플리트 하나 쓰보자고, 유니코드 문제, IME 문제, 비싼 델파이 가격 문제 등을 모두 감당하라고 한다면, 한마디로 나는 전혀 그럴 생각이 없습니다. 새로 만드는 것 보다는 기존 소스 유지보수에 버거운 나로서는 말도 안되는 요구사항이올시다.
:
: 새로운 기능이나 기술을 추가하려면 적절한 타이밍이라는 것이 있는데, 다른 툴에서는 한참 전에 지원하는 기능을 한참 뒤에야, 그것도 개발자들 스스로 이미 편법이던 어떤 식으로던 간에 다 해결한 후에 추가하면 과연 기분이 좋겄습니까? 불행히도 델파이는 이런 한발 느린 기능 추가가 아주 빈번했습니다.
:
: 클라우드 컴퓨팅이니, 웹서비스니 하는 대용량 어플 서버 분야에서 과연 델파이가 제대로 위력을 발휘할 수 있는지는 사실 매우 의심스럽습니다. 64비트 문제와 빈약한 메모리 메니져, 빈약한 멀티스레드 기능 등 델파이가 대용량 어플 서버 분야에서 제대로 위력을 발휘할 수 있는지는 내 미천한 실력으로는 참으로 의심스럽습니다.
:
: 델파이 에반젤리스이시자 실력이 뛰어나신 박지훈씨께서 델파이로 대용량 웹서비스 혹은 클라우드 컴퓨팅 같은 부분을 구현해서 보여주시면 대단히 감사하겠습니다. 빈약한 델파이 매뉴얼로 봐서는 그거 어떻게 만드는지 매우 난해해 보입니다.
:
: 그리고 2010까지의 데이타 스냅에서 추가된 기능은 내가 자주 애용하던 렘오에 비하면 아주 형편없다고 생각했습니다만, 이 역시 빈약한 델파이 매뉴얼로는 판단이 애매하니 누군가 제대로 만들어서 한번 보여주시면 고맙겠습니다.
:
: 나 역시 콤포넌트가 버전마다 대폭 바뀌기를 원치는 않습니다, 그러나, 마이다스, 웹스냅이나 웹브러커 처럼 버전 1부터 허접하게 만들어서 개발자들을 고생시키게 하다가 버그패치 마저 포기하고 중단하는 행위는 더욱더 짜증나는 행위입니다. 확확 바꾸기를 원한 것이 아니라, 제대로 만들고 제대로 유지보수 해 주길 바란다 이말입니다.
:
: 내가 델파이계를 혼자 떠나는게 외로워서 동조자를 구하려고 이런 글을 올렸다고 생각했다면 이는 정말로 유치한 생각이라고 밖에 할수 없군요. 나를 그렇게 유치한 존재로 느꼈다면 할말 없습니다만, 솔직히 이야기해서 이미 한참전부터 델파이 개발자 수가 엄청나게 줄어들어 졸라 외로운 마당에, 이제와서 무슨 외로움을 더 느끼고 말고 할 건덕지가 있단 말입니까?
:
: 그 보다는 나도 아직은 다른 툴들은 어떤 면이 좋고 나쁜지 판단이 애매하니, 다 같이 함께 머리 맞대고 연구해 보자고 제안한 것이라고는 받아들이지 못합니까?
:
: 박지훈씨는 여전히 델파이 광신자입니까? 코드기어 옹호론자입니까? 개발자끼리 개발자를 위해서 어떤 것을 해야 할지에 대해서는 별다른 의견이 없습니까?
:
: 나야 말로 박지훈씨의 답글이 맹목적인 "델파이여 영원하라" 씩의 충성심 강요적 글로 밖에는 판단되지 않습니다.
:
: 충성심은 국가나 단체가 그 소속인들을 착취하는 것을 정당화하기 만든 개념일 뿐입니다. 국민이 있기에 국가가 있는 것이며, 델파이 개발자가 있기에 코드기어가 존재하는 것이지, 국가가 있으니 국민이 있고, 코드기어가 만든 델파이를 영원이 잘 사고 애용해주자를 정당화하지는 맙시다.
:
:
:
:
:
:
: 박지훈.임프 님이 쓰신 글 :
: : 주정섭님께서 모처럼 공력을 들여 길게 쓰셨는데.. 별로 주목되는 부분이 없네요. 몇년 전부터 델파이에 적지 않은 불만을 가지고 계신 것은 알고 있었는데, 주장은 강하지만 그런 주장을 뒷받침할 만한 강력한 근거가 보이지 않아 좀 실망스럽습니다.
: :
: : 주장의 근거가 강하지 못하니 그다지 반박할 마음도 들지 않네요. 물론 델파이의 초기 버전이 등장할 때만큼 센세이셔널하지는 않지만, 그렇다고 경쟁 툴들을 따라가지 못하는 것도 아니고 시장에서 주목하는 새로운 컨셉의 방법론들도 계속 추가되고 있는데.. 아마도 가지고 계신 개인적인 불만을 제대로 표현할 방법은 없고, 그에 더해서 델파이의 최근 버전들을 제대로 써보시지 않으셔서 개인적인 추정들이 확신으로 바뀐 것이 아닌가 싶습니다.
: :
: : 괜히 억지스러운 반박거리나 만들어드리는 걸 알지만, 뭐 한두 가지 예를 들어볼까요. 주정섭님은 제네릭이나 어노니머스 메소드를 쓰고 계신가요? 이론적으로만 듣고 실무에서 제대로 써보지 않으면 그 강력함과 유용함을 깨닫기 어렵습니다. 요즘 시장의 새로운 대세가 되어가고 있는 클라우드 개발은 해보셨나요. 웹서비스로 다른 언어들과 연동해보셨나요.
: :
: : BDE에 기술적으로 한계가 있어서 dbExpress로 대체되고 dbExpress는 계속 업그레이드되고 있는데 '후속 버전이 없거나 더 지원이 되지 않는' 기술이라고 주정섭님 임의로 이름표를 붙이셨네요. 저도 dbExpress가 딱 맘에 드는 건 아니지만 최소한 dbExpress가 가고 있는 방향은 제대로라고 봅니다만.
: :
: : 주정섭님의 주장을 나름 이해하려고 노력해보면, 한편으로는 BDE에 대해서는 '더 이상 지원하지 않는 것이 문제다' 라고 하면서, VCL의 기반이 획기적으로 바뀌지 않는 것이 문제라고 하시는군요. 주정섭님은 어떻게 생각하시는지 몰라도 제 생각은, 개발툴을 사용하는 개발자의 입장에서는 꼭 필요한 경우가 아니면 기존에 익숙했던 코드를 뜯어고치지 않도록 하는 것이 좋고, 한번 밑바닥부터 뜯어고치려면 그만한 필요가 있어야 한다는 겁니다. BDE와 dbExpress가 그 좋은 예라고 봅니다. 아마 BDE가 dbExpress로 대체되지 않고 그대로 남아있었다면 주정섭님은 또 그것조차 문제삼으셨을 것 같습니다만.
: :
: : 또, DataSnap은 2009 버전 이후로 매 버전마다 계속 폭발적으로 기능이 추가되고 성능이 향상되고 있는데 실무 프로젝트에서 써보시기나 하고 말씀을 하시는지요. 주정섭님이 구미에 당기지 않고 주위의 다른 개발자들도 잘 안쓰는 것 같다, 그러면 주정섭님께는 일단 델파이를 비난할 또 한가지의 이유가 되나봅니다.
: :
: : 일단 주정섭님 스스로 찬찬히 본인의 글을 되읽어보시는 것이 좋을 듯 합니다. 근거는 빈약하고 표현은 선정적이기만 합니다. 전성기때의 주정섭님의 공력을 보여주지 못하고 악플에 가깝다는 느낌밖에 들지 않습니다. 불만을 불만 그 자체로 풀지 않고 몇단계를 마구 건너뛰어 전체를 비난하고 계시는 주정섭님의 의도가 어디에 있는지 모르겠습니다만, 혼자 떠나기가 불안해서 동조자 군단을 이끌고 떠나실 요량이시라면 솔직히 그렇게 쓰시는 것이 좋지 않겠습니까?
: :
: :
: :
: : 주정섭 님이 쓰신 글 :
: : : 만일 내가 교회에 가서 성경의 허구성과 교회의 타락과 목사들의 이기주의와 독단을 논한다면, 아마도 교회신자 모두 나보고 사탄이라고 돌을 던질 것이다. 아마도 그런 논의 자체를 시작할 수도 없을 것이다.
: : :
: : : 이말은 이미 어떤 교리나 주의에 대해서 무비판적이며 오로지 찬양만이 일상화 되어버린 집단에서는 어떤 합당한 논리와 근거를 들이댄다 한들 그들을 납득시키기는 힘들다는 것이다.
: : :
: : : 델파이 커뮤너티에도 교회처럼 이런 비슷한 습성이 있다. 델파이에 대한 비판은 결코 용납되지 않는다. 대부분 개발자들은 의외로 보수적이며, 타 언어나 개발툴을 잘 받아들이려 하지 않는다. 그 이면에는 새로운 것을 배우기 싫어하는 게으름이거나, 변화를 싫어하고 현재에 안주하려 하기 때문일 것이다.
: : :
: : : 사실 나 스스로도 그런 변화를 받아들이기 싫어하고 새로운 것에 대한 배움이 귀찮아서, 지금까지 델파이 옹호에 앞장선지도 모르며, 때로는 객관적이고 타당한 델파이에 대한 비판마저 수용하지 못한 적이 많다고 본다.
: : :
: : : 델파이 개발자들이 인정하든 말던 간에 델파이는 겨우 명맥만 유지하는 소수 사용자 툴일 뿐이다. 과거에도 그랬지만 앞으로도 절대로 자바나 닷넷 같이 다수 사용자 툴은 될수 없을 것이다. 이렇게 된 원인에는 델파이 개발자들의 불법 복사본 사용 문제도 있지만, 더 심각한 것은 볼랜드 혹은 코드기어라고 일컫는 델파이 본사 차원에서 관료주의, 부폐와 무능, 게으름, 무원칙한 마케팅 방침. 제멋대로인 가격 정책, 웃기는 인사 정책 등등 그 원인을 들자면 끝이 없다.
: : :
: : : 이런 델파이 본사와 더불어 관련인들의 부조리가 앞으로 결코 해결될 것이라고는 보지 않는다. 더 심해지면 심해지지 개선될 조짐은 지금까지 거의 없다고 본다.
: : :
: : : 델파이 자체의 버전업 계획은 더욱 암울하다. 예를 들어, 델파이의 실수 연산 엔진은 초기에 486 급의 컴퓨터에 맞춰서 작성된 이래로 거의 수정이 없었다. 이런 식으로 초기 버전 이래로 수정이 거의 없는 부분은 한두가지가 아니다. 심하게 델파이를 혹평하는 자 중에는 안델스 헤이즐버그가 델파이를 떠난 이래로 델파이 버전업은 사실상 중단된 것이나 다름 없다고도 하고, 혹자는 3, 혹은 5 버전이 델파이의 실질적인 최종 버전이라고 말하기도 한다. 델파이의 모든 VCL 소스는 지나칠 정도로 오랫동안 별로 바뀐 바가 없다.
: : :
: : : 다음 열거하는 콤포넌트들의 공통점이 무엇인지 아시겠는가?
: : :
: : : 마이다스, 퀵리포트, 레이브 리포트, 웹스냅, 웹브로커, BDE, 디비익스프레스
: : :
: : : 이들 모두 사실상 버전 1만 존재할 뿐 버전 2 이상은 실제로는 없거나, 현재 대부분 폐기 혹은 앞으로 더 이상 지원 안하는 콤포넌들이라고 매뉴얼에 명시된 것들이다. 내 생각에 조만간 인트라웹과 인디도 저 목록에 포함될 것으로 보인다. 그리고 최근 추가된 DataSnap 역시 같은 운명을 밟게될 것이다.
: : :
: : : MS 가 미완성 제품을 판다고 욕을 많이 먹었다. 그렇다면 과연 델파이 자체 콤포넌트는 어떨까? 여러분들이 믿거나 말거나, 델파이의 자체 콤포넌트 역시 상당수가 미완성 버전에 버그 패치 지지부진하다가, 중간에 폐기된 경우 부지기수라는 것이다.
: : :
: : : 현재까지 만든 프로그램이 많은 개발자라면, 당장 델파이를 버릴 수는 없을 것이다. 현재 제품들의 유지보수를 위해서 델파이를 당분간 사용해야 할 것이다. 그러나, 개발자 생활을 계속 하고 싶다면, 지금부터라도 델파이를 대체할 만한 다른 툴이나 언어를 신중하게 모색해봐야 한다.
: : :
: : : 델파이만으로 앞으로 계속 개발자 생활을 하기에는 앞으로는 거의 불가능할 것으로 보인다. 왜냐하면, 델파이는 한때 가장 장점이 강했던 분야인 윈도우에서도 현재는 찬밥신세이며, 리눅스, 모바일 등의 환경에서는 더욱 별로 기대할 수 없어 보이기 때문이다.
: : :
: : : 델파이의 유일한 윈도우 플랫폼 탈출 시도작은 칼릭스였으나, 결과는 명백한 실패작이었다. 칼릭스는 안팔린 것이 아니라, 제대로 못 만들었기 때문에, 망한 것이다. 칼리스 역시 사실상 버전 1만 존재하는 제품이었다. 그리고, 델파이 닷넷 버전판 역시 실질적으로 망했다.
: : :
: : : 이제 델파이 커뮤너티에서는 델파이를 대신할 툴들에 대해서 논의해야 할 때가 되었다고 생각이 들지 않는가? 나의 예상이 전혀 틀려서 델파이가 더욱 더 기똥찬 인기있는 툴로 살아 남을지도 모른다. 그러나, 그렇다고 해도, 다른 언어나 툴에 대한 공부나 분석은 델파이를 편견이 아닌 객관적으로  볼 수 있게 하고, 더 나은 프로그램 방법이나 앞으로의 개발자로서 살아나가기에 중요한 자세라고 본다.
: : :
: : : 델파이 커뮤너티에서 추구해야 할 것은 델파이의 영광이 아니라, 델파이 개발자들 스스로의 미래나 발전이 아닌가? 간혹 델파이 커뮤너티에서, 볼랜드 혹은 코드기어의 영광과 번영을 위해서, 지나치게 델파이에 대한 맹목적 충성심만을 강조하는 것은 아닌지 의심스러울 때가 종종 있다.