결론은 Visual Studio 가 좋다!! 이군요. ^^

언어에 IDE 는 이제 필수사항으로 여겨지나 봅니다. (이미 필수인가?)
버전관리 는 이미 필수 인것 같고...

F/OSS 가 함께하길.. (F/OSS서포터즈,F/OSS서포터즈그룹)

.Net 이전에는 사실 Visual Studio, 그리 좋은 환경은 아니었습니다.
통합환경 좋기론 볼랜드 계열이 예전부터 유명했죠.
그에 비하면 MS는 .Net 에 와서야 볼랜드 계열과 유사한 통합환경을 제공한 셈이구요.
그전까지 통합환경이 아무리 좋아도 볼랜드 제품을 쓰지 않던 분들이 .Net 통합환경을 보고 혹하는 모습을 보면 역시 MS의 영향력이 대단하단 생각을 하곤 합니다.

어쨌든 각설하고 PHPeclipse 프로젝트가 있군요.
http://www.phpeclipse.de/
Mono 역시 eclipse에서 사용할 수 있다니 eclipse 기반의 개발 환경도 괜찮아 보이네요.
===========================================================================
Shocky Han
Seoul, Korea.
===========================================================================

ASP는 정말 상상도 하기 싫은 언어였습니다.
몇주전에 아는 후배가 도와 달라고 해서 잡았는데,
간단한 SQL 정렬문 만들고 조건식 거는데도
분노게이지를 맥스화 시켜준 최고(?)에 언어였습니다.

그렇지만 ASP.Net은 그나마 괜찮더군요.
제대로 써보지 않아서는 모르겠지만 말입니다.

인생은 전쟁
http://my.blogin.com/unleashed

어떤 제품의 Upgrade는 사용하는 사람의 요구를 얼마만큼 적용시켜주느냐에 달려있습니다.
지금까지(앞으로도 계속 ?) LINUX가 발전할 수 있었던 원동력이기도 합니다.
(성당과 시장에서도 비슷한 의견이 있었던 것 같은데... :))

.NET이 좋아졌다면 그만큼 유저의 의견을 받아들였기 때문이겠죠. 예전에도 버그리포트가
있으면 차후버젼에서 고쳐져서 나오곤 했지요.
문제는 바로 돈이죠. .NET을 돌리기 위해선 그에 맞는 H/W도 있어야하지만 S/W도
만만찮게 들어가니까요.

결론은 .NET이 좋아져도 저같은 빈민층에게는 별로 흥미가 가지 않는다는 거죠. :)
------------------------------
좋은 하루되세요.

웹쪽일을 하고 있습니다만.. 프로젝트 규모에 따라 나름 장단이 있는것 같아요.. 물론 IDE쪽 이야기는 아니지만, 요즘에 php는 pear를 쓰면서.. 상당히 편한것 같아서 좋습니다..

mono로 ASP.NET되나요? 그래도 재미있을 텐데.

힘없는자의 슬픔

저는 별 경험은 없지만 개인적으로 규모가 큰 프로젝트에서는 PHP가 조금 그렇다는 생각입니다. 그리고 .NET쪽은 모르겠네요.. 하지만 J2EE쪽은 약간의 경험많으로도 괜찮다는 생각을 많이 했습니다.

그런데 요즘에는 루비가 뜨는 추세더군요.. 루비 온 레일스와 함께하면 적당한 규모의 프로젝트를 빠르게, 즐겁게 할 수 있다는 말을 들었습니다. 사실 진위 여부는 아직 모르겠습니다만.. 많이들 좋아하니까 그럴만도 하겠지요. 그래서 저도 입문을 고려하고 있습니다..

근데 웬지 모노는 관심이 별로 안가더라구요... GCJ가 미덥지 않게 느껴지는 것처럼이라고나 할까요... (이건 자바가 여러 플렛폼으로 나와있기 때문일수도 있겠네요..)

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.xo.st

개인적으로 제일 좋아하는 언어는 C++이고 C나 자바, PHP도 좋아합니다.
PHP개발환경은 PHP이클립스가 1순위고 jEdit PHPParserPlugin을 사용합니다.
(물론 vi도 정말 좋아합니다)

C++은 언어자체를 좋아해서 쓰고 자바나 PHP는 런타임환경이나 배포환경을 좋아해서 씁니다. 닷넷의 핵심을 보면 결국 자바나 스크립트 언어의 런타임환경의 장점을 취해보자 인데, 그게 (현재) 윈도우 환경으로 제한된다면 상당히 떨어진다고 생각합니다.

언어적인 측면에서 보자면, 고수준의 언어가 결코 쉽다고 생각하지 않습니다. 오히려 정해진 고수준의 자료형을 공부하려면 배워야되는게 참 많더군요.

어쨌든, C#이 매력적이고 어떻고를 떠나, C++ 자바 PHP 조합이 너무 강력하군요. C#이 이 세개를 모두 섭렵할 수 있을꺼라고 절대 생각되지 않구요.

.net과 php는 비교대상이 될수가 없지요.
php는 웹사이트를 개발할때 사용하기 편하고 생산성이 높은
단지 스크립트 언어에 불과합니다. 그 부분만 놓고 보더라도
c#과 asp.net 환경에서 개발방식은 하늘과 땅차이입니다.
asp.net의 유저컨트롤, 서버컨트롤.. 이거 하나만 놓고봐도
얼마나 다른지 극명하게 나타나지요. 더구나 rdbms를 비롯
다양한 데이터들의 사용에 있어 ado.net의 역할까지 포함하면
.net 개발자의 입장에선 perl, php, asp와는 비교를 거부합니다. -_-

비교 대상이 될 수 없다고 할 정도는 아닌 것 같습니다. 스크립트 언어냐 아니냐, 유저 컨트롤, 서버 컨트롤이 가능하냐 아니냐 같은 문제보다 더 중요한 것은 그것으로 뭘 만들 수 있느냐죠. 같은 일을 PHP로는 스크립트 언어처럼 간단하게 할 수 있는데 .NET은 복잡한 기술 써가면서 한다면 그건 오히려 .NET이 안 좋다는 뜻이 아닐까요?

사실 도구의 장단점을 논하는데 "사용하기 편하고 생산성이 높은"이라는 말보다 더 좋은 수식어가 뭐가 있나요? 개발 방식이 하늘과 땅 차이라서 그래서 .NET으로 만들면 더 적은 man/month로 개발할 수 있나요? 여기에 yes라고 대답하지 못한다면 그 어떤 기술적인 가치도 의미 없는 것입니다.

유지보수가 얼마나 용이한지, 또 결과물의 구조가 얼마나 유연하고 확장성이 있는지, 늘어나는 부하따라 쉽게 적응 가능하고 안정적으로 동작하는지, 부차적으로 관련 기술 인력을 얼마나 쉽게 구할 수 있는 지 등등도 고려할 수 있습니다. 경우에 따라선 반드시 '빠르고 쉽게' 만드는 것만이 능사가 아닐 수 있으니까요.

[서명] 그놈 한국 사용자 모임 -
그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

PHP 는 얼마 사용해보지 않았지만^^;...뭐 어쩼거나 한번 예를 들어서 이야기해보면
디비 쿼리 결과를 간단하게 캐시하는 기능을 넣는다고 하죠. PHP에서 가능한 시나리오는

1. 퀴리 결과를 가져온다.
2. "파일 !!!" 로 저장한다.
3_1. 결과에 대한 요청이 있을 경우 쿼리를 날리지 않고 파일을 읽어 응답 한다.
3_2. 업데이트하는 요청이 있을 경우 디비 업데이트 후 파일을 삭제, 재생성한다.

여기서 문제는 우선 캐시를 저장할 수 있는 방법이 "파일" 밖에 없다는 겁니다. PHP에서는 메모리에 결과를 저장할 방법이 없지요. 큰 차이일지는 알 수 없지만 퍼포먼스가 떨어집니다. 그리고 동기화 문제도 있지요. 여러 업데이트 요청이 있을 경우에 적절하게 동기화해 캐시해야 하는데, PHP에서는 역시 방법이 없습니다. 동기화를 위해 일종의 mutex 역할을 할 파일을 또 하나 따로 사용한다던지 해야 하죠. 그리고 저장할 때 사용할 양식에 따라 저장 내용을 생성하고 거꾸로 파싱하는 코드도 짜야겠군요. 구현이 복잡해질 수 밖에 없습니다.

자바나 .NET 에서는 "위 시나리오 그대로 작성할 수도" 있고

1. 퀴리 결과를 가져온다.
2. 쿼리 결과를 적절한 자료구조에 저장하고 레퍼런스를 유지한다.
3_1. 결과에 대한 요청이 있을 경우 쿼리를 날리지 않고 캐시를 사용해 응답한다.
3_2. 업데이트하는 요청이 있을 경우 디비 업데이트 후 캐시를 재생성한다.

일단 파일을 사용하지 않으므로 IO 가 없으니 퍼포먼스가 더 좋을 "가능성"이 있습니다. 뭐 하드웨어적인 캐시나 기타 여러 문제가 있으므로 얼마나 빠를지는 알 수 없지만 일단 더 빠를거라 기대할 수 있고, 여의치 않으면 파일로 캐시를 생성하는 것도 "가능합니다." 그리고 메모리에 저장하든 파일로 저장하든 언어 자체에서 제공하는 동기화 메커니즘을 이용해 동기화 문제도 쉽게 처리할 수 있습니다.

간단한 예이지만 PHP로는 한계가 있고 자바, .NET 에서는 어렵지 않게 가능한 예를 들어봤습니다....

cleol님이 드신 예는 너무 단편적인 것 같고,
fender님의 유지보수 이야기는 언어의 문제라기 보단 설계의 문제 인 것 같습니다.

우선 특정 기능을 두고 지원하느냐? 안하느냐를 두고 판단을 한다면, 오픈소스인 PHP가 유리할 것입니다. 필요하면 보다 쉽게 만들거나 구할 수 있기 때문입니다. 그 것이 상용이든 오픈소스이든지요. 그리고 실제로 많은 부분들이 개발자들의 노고에 의해서 만들어 져있기도 하구요. 그리고 저 생각으로는 말씀하신 기능은 데이터베이스가 해야 옮은 일 일 것 같습니다. 우리의 - 엄청난 속도로 발전하고 있는 - MySQL이 그 기능을 가지고 있는듯 합니다만, 혹은 그 페이지 자체를 캐싱 해버리는 것도 생각 할 수 있을 테고요...

둘째로 유지보수가 얼마나 용이한지, 또 결과물의 구조가 얼마나 유연하고 확장성이 있는지, 늘어나는 부하따라 쉽게 적응 가능하고 안정적으로 동작하는지, 부차적으로 관련 기술 인력을 얼마나 쉽게 구할 수 있는 지 등등은 설계에 문제가 없다면 PHP나 ASP.NET이나 JSP나 웹에서는 거의 동일 한 것 같습니다.

우리는 설계단계, 시스템 구조와 구현할 목록들을 정할 때, 그 기능에 가장 적합하고 코스트가 적게 드는 언어를 택하면 되는 것입니다. 시스템 마다 회사마다 상황들, 사람들(특히 사람들)이 너무도 다르기 때문에 우리는 언어에 연연하기 보다는 그 때 그 때 상황에 맞추어서 택하는 것이 옮은 것이 아닌가 라는 생각이 듭니다.

그리고 얼마나 .NET을 좋아하시면 비교를 거부하신다니. PHP를 사랑하시는 분들도 좀 생각을 ㅡㅜ;

자신의 것을 진정 사랑하게 되면 될 수록 남의 것이 얼마나 소중한지 알게 되는 것이 세상이치...

그리고 하나더! 계속 사용하다보니깐 PHP는 웹전용으로 구현된 C 프레임 웍이 아닌가 라는 생각이 드는 군요...

serialize도 있군요.

저게 안되나 한참 생각했었는데, 행복한 고니님이 답을 주셨군요. 감사합니다.

물론 설계의 문제이기도 합니다만, 윗 분께서 말씀하신 웹폼즈나 이에 대응하는 J2EE의 JSF같은 개념들이 바로 그런 문제를 해결하기 위해 나왔다는 점을 지적하고 싶은 것입니다.

예를들어 J2EE 스펙에는 웹관련 쪽만 봐도 커스텀 태그, 필터, 리스너 등이 있습니다만 비슷한 기능을 언어 차원의 지원 없이 개발자의 코딩으로만 구현하는 것은 결코 쉽지 않습니다. 또 그렇게 개발한 결과물이 잘 정의된 스펙과 API에 따라 구현하는 것 만큼 이해하기 쉽고 유지보수, 확장이 가능하게 만드는 것도 역시 쉬운 일이 아닙니다.

하다못해 말씀하신 캐슁의 경우만 봐도 자바 처럼 oscache, ehcache, jboss-chache, tangosol 등등 수 많은 관련 라이브러리가 지원되는 상황에서 맘에 드는 걸 골라 쓰는 경우하고, 개발자가 비슷한 기능을 일일이 구현하는 경우 결코 퀄리티나 생산성이 같을 수 없겠죠. 특히 분산 캐쉬 같은 건 필요하다고 PHP로 쉽게 짤 수 있는 건 아닙니다.

자바의 경우 정말 수 없이 많은 MVC 프레임워크 들이나 요즘 각광받는 JSF 같은 이벤트 드리븐 컴포넌트 기반 프레임워크 들이 PHP에서 못하는 기능을 할 수 있게 하지는 않습니다. 또 어쩌면 위지윅이 되는 IDE를 쓰지 않는 한 생산성이 그닥 차이가 안나거나 떨어질 수도 있습니다. 하지만 '쉽고 빠르게', 그리고 '다른 언어에 없는 기능'이라는 기준 두 가지만 가지고 그런 기술들을 평가하는 것은 공정하지 못하다고 봅니다.

[서명] 그놈 한국 사용자 모임 -
그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

PECL에서 제공하는 캐싱 관련 확장입니다.
http://pecl.php.net/package/APC
http://pecl.php.net/package/memcache

예전 Turck MMCache 프로젝트를 포크한 eAccelerator도 캐싱을 지원하는 것 같군요.

전 유지보수와 신규 개발이 별로 다른 이슈가 아니라고 봅니다. 개발 기간이 6개월만 되도 웬만한 유지보수 이슈는 다 발생합니다. 전 우리나라의 자바 기술의 발전이 더딘 결정적인 이유로 유지보수와 개발을 다른 것으로 생각하는 문화라고까지 보고 있습니다. 도대체 개발을 쉽고 빠르게 할 수 있는데 같은 방법으로 유지보수가 어려운 이유가 무엇이 있겠습니까.

빠르게..의 기준을 페이지 하나로 보면 fender님의 말씀처럼 그럴 수도 있습니다. 하지만 그 대상이 1년 짜리 프로젝트라면요? 1년 짜리 프로젝트를 6개월만에 할 수 있다면 단지 막코딩 빨리 하는 것만으로 가능할까요? 아닐 것입니다. 충분히 높은 수준의 코드 퀄리티가 확보되지 않으면 대규모 프로젝트를 빨리 해내는 것은 불가능합니다.

유지보수를 잘한다는 건 뭘까요? 변경 사항이 발생했을 때 빠르게 적용하는 것 아닌가요? 좋은 유지보수를 위해서라면 미래에 일어날 변경사항을 예측해서 복잡하게 만드는 것보다 단순하게 만들어놓고 변경사항의 발생 때도 쉽고 빠르게 개발할 수 있게 하는 것이 더 좋지 않겠습니까.

결국 비즈니스는 돈이고 돈은 man/month입니다. 개발이든 유지보수든 결국 비용을 줄여주지 못하면 어떤 기술도 더 낫다는 평가를 받을 수 없습니다.

덧붙여, 전 자바 개발자고 자바 프레임웍만 3년 넘게 만졌고 PHP는 딱 두 달 정도 해본 게 다입니다. 그리고 자바란 언어도 PHP보다 훨씬 좋아합니다. 하지만 PHP를 들여다볼수록 PHP는 지나친 편견을 받고 있다는 생각입니다. 초기에 막코딩으로 만든 PHP 코드가 널리 퍼져서 PHP 코드는 유지보수 불가!란 딱지를 붙였지만 사실 초기에 만든 JSP 코드들은 훨씬 심합니다. 개발자 숙련도의 차이일 뿐 "clean code that works"에 다가서는데는 PHP가 자바나 .NET에 비해 조금도 부족한 언어가 아니라고 봅니다.

구체적인 이야기에 대해서도 좀 언급하면, 위에 캐시를 언급하면서 퍼포먼스가 높을 가능성이 있다는 말씀을 하신 분이 있는데 가능성은 그럴지 모르나 현실은 PHP가 우세입니다. PHP가 자바보다 훨씬 높은 scalability를 갖는다는 건 이미 많은 자료로 드러났고 네이버 같은 포탈 사이트에서 페이지뷰가 많은 페이지들은 PHP로 구현되어 있다는 사실이 그것을 뒷받침합니다. 게다가 위에 또 어떤 분이 PHP 캐시들을 소개해주셨네요. .NET은 10위권 사이트는 커녕 100위권 사이트 중에도 쓰는 곳이 없는 걸로 알고 있구요. 자바는 10위권 안팎에 많이 분포하고 있습니다.

그리고 이벤트 드리븐에 대해서도 잠깐 이야기를 하면, 이벤트 드리븐이 더 좋고 편리한 개발 방식인 것처럼 많이 이야기됩니다만 이벤트 드리븐, callback, IoC 등의 방식은 개발자의 사고의 흐름을 끊어 놓는 경우가 많기 때문에 꼭 필요한 경우가 아니라면 별로 바람직한 방식은 아니라고 봅니다. IoC의 개념을 퍼트리는데 일조한 마틴 파울러도 IoC는 꼭 필요할 때만 쓰라고 하고 있죠. 때때로 중복을 효과적으로 제거할 수 있는 방법이긴 하지만 이해하기 힘든 코드를 만듭니다.

JSF도 썬에서 비주얼하게 뚝딱 개발할 수 있는 멋진 도구를 내놓고 이제 그걸 오픈소스로 공개하겠다고도 하고 있지만 여전히 대세는 JSF가 아니라 Struts나 Spring입니다. 이거야말로 처음 간단한 페이지를 만들 때는 금방 뚝딱 만들 수 있지만 그렇게 생성된 코드들에 뭘 수정하려면 참 골치아프고 IDE만 벗어나면 왕짜증 프레임웍이 되고 말죠.

그리고 사실 PHP 먼저 배운 사람들이 JSP 할 때 제일 불평하는 것이 바로 include입니다. JSP에 커스텀 태그도 tiles나 sitemesh 같은 것도 있고 하지만 PHP에는 그런 게 없어서 못 쓴다기보다 필요가 없기 때문에 안 쓴다고 보는 것이 맞을 겁니다. 실제로 뷰단 작업하다보면 온갖 프레임웍과 커스텀태그 다 갖다 쓴 JSP보다 그냥 PHP 쓰는 게 훨씬 편합니다. 사실 자바도 JSP 불편하다고 velocity 갖다 쓰는 사람들 많지 않습니까. J2EE도 온갖 화려한 기술들로 포장되어 있지만 결국 점점 다른 기술들은 묻혀가고 Servlet/JSP, Web Service만 활용되는 것을 봐도 화려한 기술이 실제 가치로 연결되지 못하면 의미 없다는 사실을 잘 말해주는 것이라고 봅니다.

유지보수와 신규개발은 분명 다릅니다. 항상 개발한 본인이 자기가 개발한 코드를 관리하게 되는 것도 아니고, 또 새로운 요구사항이나 예측 못한 문제점이 발생할 수 있습니다. 여기에 도움을 주는 건 초기 생산성 만이 아니라 설계 자체의 유연성이 크게 작용합니다.

creativeidler 님께서는 유지보수를 잘하기 위해서는 '복잡하게 만드는 것보다 단순하게 만들어놓고 변경사항의 발생 때도 쉽고 빠르게 개발할 수 있게'해야 한다고 말씀하시지만, 일반적으로 유연성을 확보하는 설계의 전체 구조는 오히려 복잡해지는 경향이 있습니다.

그리고 'PHP가 자바보다 훨씬 높은 scalability를 갖는다'는 건 동의하기 어렵군요. '가볍다'와 'scalable 하다'가 동의어가 아님은 설명 드리지 않아도 잘 아실 것으로 믿습니다. 설사 'scalability'가 아니라 'performance'만을 놓고 봐도 솔직히 풀스택 J2EE 서버에 이런 저런 프레임워크를 올리는 게 아니라 단순 2-tier 구조로 디비를 쓰는 웹어플을 놓고 보면 아파치/PHP 조합이 예컨대 Tomcat 보다 특별히 빠르다고 생각하지 않습니다. 혹시 주장을 뒷받침 하실만한 구체적인 자료가 있으면 제시해 주셨으면 좋겠습니다.

IOC를 지원하는 (요새는 DI라고 많이 부릅니다만) 경량 컨테이너를 예를 들면서 '지나치게 복잡하다'라고 말씀하셨는데, 그렇다면 스프링 컨테이너가 기본적으로 지원하는 선언적 트랜잭션, 커넥션 관리, 보안, 원격호출, 웹서비스, ORM 연동 등등을 PHP에서 직접 구현하면 훨씬 덜 복잡하게 할 수 있다는 뜻인가요? 아니면 그런 기능들은 별 쓸 모가 없다고 생각하시는 지요?

또 어떤 근거로 JSF/웹폼즈 같은 컴포넌트 기반 이벤트 드리븐 개발 방식이 PHP 같이 직접 html 태그를 작성하는 것보다 불편하고 복잡하다고 생각하시나요? 예를들어 흔히 쓰는 페이징이 가능한 테이블 형태의 목록의 경우 이런 컴포넌트 기반 개발이라면 IDE에서 그리드 컴포넌트를 끌어다 놓거나 직접 치더라도 태그 몇 개로 끝나는 일입니다만, PHP에선 그 보다 훨씬 쉽고 간단하게 그런 구현이 된다는 뜻인가요? 혹은 ADF나 MyFaces의 Tomahawk 같은 컴포넌트를 가져다 쓰는 것보다 개발자가 직접 파일 단위로 include하거나 복사 붙여넣기 하는 게 재활용 성이 높다고 보시나요?

그리고 J2EE에서 Servlet/JSP/WebService만 남고 다른 기술이 묻혀 간다는 것은 EJB를 말씀하시는 걸로 짐작 됩니다만, EJB는 J2EE 스펙의 일부분일 뿐이고, 경우에 따라서는 EJB와 같은 본격적인 분산 처리가 반드시 필요한 곳이 있습니다. 또 그런 부분은 절대로 PHP로 대체할 수 없는 도메인입니다. 참고로 EJB 3.0에서는 EJB 2.x에서 문제가 되었던 복잡성이 대폭 개선되었더군요. 오히려 스프링보다도 단순하다는 느낌이 들 정도입니다.

제가 이야기하는 것은 J2EE가 적용 분야와 프로젝트 성격에 관계 없이 PHP보다 우월하다는 것이 아닙니다. 두 기술 모두 장단점이 있고 적합한 분야가 있습니다만, 제가 볼 때 creativeidler님의 J2EE 비판은 마치 PHP에 없는 J2EE의 기능은 PHP에 없다는 이유만으로 모두 불필요하고 쓸데없이 복잡하다고 단정 지으시는 것 같아서 별로 공감이 가질 않습니다.

[서명] 그놈 한국 사용자 모임 -
그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

fender님께서 말씀하신 캐싱엔진, MVP 프레임웍들 PHP에서도 난무합니다. 자바가 일부 항목(개인적 견해 : 객체지향의 개념과 그 실현)에서 상당히 우세할테고, PHP도 일부 항목(개인적 견해 : 대중화 오픈소스와 미시적 관점에서의 유연성)에서 상당히 우세 할 것입니다.

님께서 말씀 하신데로 "몇가지 항목"으로 기술을 평가하는 것을 옮지 않은데, 님께서는 PHP를 이미 아래로 보고 말씀 하시는 것 같군요. 많은 분들이 태생이 다르다 하여 PHP나 MySQL등을 아래로 보는 경향이 있는 것 같습니다.
한번 PHP쪽도 둘러보심이...

궁금합니다. 10년후의 JSP와 PHP의 위상이 어떨지...

>일반적으로 유연성을 확보하는 설계의 전체 구조는 오히려 복잡해지는 경향이 있습니다.

맞는 말씀입니다. 그래서 현재의 필요를 잘 충족시키는 설계가 미래의 유지보수를 고려하는 설계보다 좋다고 주장하는 것이고 때문에 유지보수가 편해진다는 것은 Java가 낫다는 근거로 부족하다는 것입니다.

scalability는 제가 아는 바로는 더 많은 사용자를 안정적으로 커버하는 능력입니다. 때때로 code maintainability, fault tolerance 등을 포함하기도 하지만 언제나 빠지지 않는 개념은 퍼포먼스죠.

예전에 static html, php, jsp, asp 등의 퍼포먼스를 벤치마크한 자료를 봤었는데 다시 찾으려니 찾을 수가 없군요. 이건 좀더 찾아보고 다시 올려드리겠습니다. 이외에 제가 과거에 fastcgi를 쓰지 않고 PHP랑 JSP의 퍼포먼스 벤치마크를 해본 적이 있었는데 PHP가 두 배 정도 빨랐습니다. 2년 정도 전인데 그 사이 자바도 많은 발전을 했지만 PHP도 fastcgi를 사용하면 결국 차이는 그대로가 아닐까 싶습니다. 주위에도 직접 PHP와 JSP를 비교해본 사람들은 한결 같이 PHP가 빠르다고 이야기합니다. 그리고 대형 포탈 사이트에서 JSP를 쓰지 않는 것도 간접 근거가 될 수 있겠지요.

그리고 IoC. 같은 기능을 다른 방식으로 구현할 수 있다면 IoC는 피해야 한다고 생각합니다. 선언적 트랜잭션, 아주 편리할 것 같은 표현이지만 별로 LoC를 줄이지도 못하고 code의 readability가 올라가는 것도 아니고 에러 발생 확률을 줄여주는 것도 아닙니다. Java에서도 선언적 트랜잭션을 쓰지 않고 얼마든지 높은 퀄리티를 확보할 수 있고 PHP도 마찬가지죠. 웹 서비스는 이미 PHP에서도 가능합니다. ORM 연동? 분명 PHP의 약점 중 하나이긴 합니다만 IoC와 직접 관련이 있는 부분은 아닌 것 같군요. 그리고 여기에 관한 재미 있는 시도도 있는 것으로 알고 있습니다.

무엇보다 자바가 XML 지옥에 빠지게 만드는 주범이 바로 이 IoC이기 때문에 XML 없이도 readability 높은 코드를 만들 수 있는 PHP가 오히려 나은 점이 있다고 보는 것입니다.

>또 어떤 근거로 JSF/웹폼즈 같은 컴포넌트 기반 이벤트 드리븐 개발 방식이 PHP 같이 직접 html 태그를 작성하는 것보다 불편하고 복잡하다고 생각하시나요?

불편하다는 주관이 많이 들어간 개념이죠. 이런 주관적인 것을 객관으로 주장할 수 있는 방법은 바로 많은 사람들의 의견일 것입니다. JSF가 나온지 3년? 정도 된 걸로 알고 있고 Java Studio Creator 같은 편리한 툴도 있습니다. JSF는 JSR에도 올라와 있죠. 그리고 비슷한 개념의 Tapestry란 프레임웍도 나온지 6년 정도 되었습니다. 그런데 얼마나 쓰이고 있나요?

컴포넌트. 좋은 얘깁니다. 하지만 그 컴포넌트, 만들기 얼마나 쉽습니까? 제가 프레임웍 일을 하는 동안 커스텀 태그 참 많이 만졌는데 짜증스러운 점이 한두 가지가 아닙니다.

자바는 만들어놓은 컴포넌트를 태그 몇 개 써서 쓸 수 있다고 생각하시면서 PHP는 copy&paste를 해야 한다고 생각하시는 이유가 무엇일까요. PHP도 얼마든지 컴포넌트 갖다 쓸 수 있습니다. 페이징 같은 거 커스텀 태그 쓰는 것만큼, 혹은 그보다 더 간단하게 붙여 넣을 수 있는 컴포넌트도 있습니다.

PHP도 이제 OOP 언어입니다. 파일 단위 include나 copy&paste가 중복을 제거하는 유일한 방법인 것은 아닙니다. 프레임웍이란 결국 중복을 효과적으로 제거하는 방법 중 하나이고 PHP에서도 당연히 그렇게 할 수 있습니다.

그리고 EJB. 분산 처리는 이제 웹 서비스를 기반으로 한 SOA가 대세인 것으로 보입니다. EJB 3.0에서도 여전히 그 많은 중복들은 사라지지 않았습니다. 그리고 JMS 같은 기술도 참 많이 각광 받았고 분명 꼭 필요한 곳이 있는데도 그리 널리 대중화되지 않았습니다.

전 J2EE와 많은 프레임웍들의 기능이 PHP에 없기 때문에 비판하는 것이 아닙니다. 전 자바 개발자고 오히려 줄곧 자바 개발자로서 이런 프레임웍에 대한 비판을 가해 왔습니다. 요즘 자바도 경량화 바람이 강하게 불고 있지 않습니까? 가볍지도 않은 Spring까지 경량화를 내세우고 있습니다.

"프레임웍은 문제가 발생하기 전에 존재하는 것이 아닙니다. 프레임웍은 문제를 해결한 결과로서 만들어집니다. 우리가 미리 생각해서 만들어지는 과정을 생략해 버린다면 그 결과는 그냥 문제 해결 이전의 상태로 되돌아오는 것 뿐 입니다." - David Heinemeier Hansson

PHP가 JSP보다 월등히 빠르다는 건 구체적 근거가 없으면 믿기 힘들군요. 자료를 제시하시지 않으면 그 문제에 대해선 그냥 저나 creativeidler님이나 검증되지 않은 상반된 의견을 가진 것으로 정리하고 넘어가야 할 것 같습니다.

참고로 scalability는 fault tolerance나 code maintainability와는 상당히 다른 개념입니다 (우리말로 scalable/extensible을 둘다 '확장성' 있다라고 표현해서 헷갈리긴 합니다). 어쨌든 성능 관련해서는 저 역시 어떤 구체적 자료가 없는 한 더 이상 언급은 피하겠습니다.

제가 볼 때 creativeidler 님께서는 예컨대 어떤 기능을 안써서 웹 사이트를 구축할 수 있고 그 기능을 배우기가 어려우면 불필요하다는 주장을 하시는 것 같습니다. 위에서 언급한 기술들이 매우 유용하게 쓰이는 경우는 수 없이 많지만, 딱 하나만 구체적 예를들어 보자면, 말씀하신 '선언적 트랜잭션'을 들겠습니다.

물론 선언적 트랜잭션 없이도 코딩할 수 있습니다. 또 아무리 EJB 컨테이너나 IOC 컨테이너가 지원을 해줘도 어느 정도 배우는데 시간은 걸립니다. 그렇다면 이는 쓸 데 없는 기능일까요?

솔직히 게시판, 방명록을 만드는 데 선언적 트랜잭션 따위는 필요 없습니다. 하지만 비즈니스 로직이 복잡해지는 기업용 사이트에서는 트랜잭션 관리가 상당히 복잡합니다.

어느 정도 규모 있는 사이트 구축을 해보셨으면 아시겠지만, 그런 규모에서는 대부분의 모듈이 비즈니스적으로 의미 있는 단위로 잘게 쪼개져 있고 경우에 따라선 복잡하게 모듈 간 상호 호출을 하기도 합니다. 그럴 때 선언적 트랜잭션이 없으면 어떻게 처리 하실 건가요?

예를들어 업무에 따라 한 트랜잭션 안에서 여러 독립적인 트랜잭션을 처리해야 하는 경우도 있고 어떤 경우는 단위 트랜잭션이 실패하면 전체 트랜잭션이 롤백되어야 하는 경우도 있습니다. 그런 경우 메소드마다 'isTransactionStarted' 따위의 플래그를 넘겨주고 넘겨받고 하는 것 보단 메소드 레벨에서 트랜잭션 타입을 지정해 주는 것이 매우 유용합니다.

선언적 트랜잭션은 도메인 자체가 그런 복잡한 트랜잭션을 요구하는 경우를 손쉽게 해결하려는 개념인데, 이를 PHP를 많이 쓰는 단순한 도메인에서 별 쓸모 없다고 쓸데 없는 기능이라고 생각하시는 건 분명 공정한 비교가 아닙니다.

그리고 '가볍지도 않은 스프링이 경량 프레임워크를 내세우고 있다'고 하셨는데 그건 '경량 프레임워크'라는 말뜻을 오해하고 계신 것 같습니다. 그리고 만일 스프링을 제대로 활용해 보셨다면, 자동으로 커넥션/트랜잭션을 관리하고 checked exception을 해석해주는 등 만으로 얼마나 코드가 간결해지는 지 잘 아실 것 같습니다. ORM까지 안가도 JdbcTemplate 정도만 해도 커넥션 풀 사용해서 쿼리 결과 얻어 파싱하는 데 단 두 줄로 가능합니다. 물론 커넥션 해제나 예외처리, 트랜잭션 관리 모두 자동으로 됩니다.

웹서비스 물론 PHP에서 됩니다만, 스프링에서는 그냥 '이 인터페이스가 웹서비스다'라고 마크만 해주면 다른 코드 하나 없이 웹서비스 연동이 됩니다. 요즘엔 자바 기본으로 제공되는 관련 라이브러리에선 어노테이션으로 훨씬 간결하게 처리 됩니다.

이런 식의 기능들이 PHP에서 얼마나 편리하게 제공되는 지 모르겠습니다만, 저런 기능을 쓰기 위해 xml 설정 파일 하나 만드는 게 말씀 처럼 'XML 지옥'을 유발하고 가독성을 떨어뜨려 손으로 직접 짜는 게 낫다라고 말씀하시는 건 상당히 과장된 주장이라고 봅니다.

그리고 JSF 컴포넌트 만들기가 그렇게 쉬운 건 아닙니다만 개발을 할 때 개발자가 직접 컴포넌트를 만드는 일은 일반적이지 않습니다. 그게 복잡해서 컴포넌트 모델이 무용하다면 ActiveX 컴포넌트 제작하기 귀찮으니 VB로 폼디자인 못한다는 말도 성립할 수 있을 겁니다.

기본 JSF 컴포넌트 이외에 ADF만 해도 100여개의 기본 컴포넌트가 있고 MyFaces의 확장 컴포넌트, 그리고 최근 많이 나오는 Ajax 기반 컴포넌트 들만 해도 어지간한 개발은 쉽게 할 수 있습니다.

PHP에서도 컴포넌트 기반 개발보다 훨씬 쉽게 할 수 있다고 주장하시는 데 한 가지만 구체적인 예를 들어 봤으면 좋겠군요.

네이버 검색 같은 Ajax 기반 자동완성을 PHP에서 재활용 가능하게 사용하려면 어떻게 해야 하나요? 참고로 JSF라면 IDE를 안써도 "<s:inputSuggestAjax binding="search.keyword" suggestedItemsMethod="search.suggestions"/>" 이렇게 한 줄만 붙이면 됩니다.

PHP에서도 얼마든지 컴포넌트를 가져다 쓸 수 있다고 하셨는데, JSF나 웹폼즈와 비슷한 개념으로 컴포넌트 차원에서 재활용할 수 있는 널리 쓰이는 기술이 있다면 한 가지만 예를 들어 주셨으면 좋겠군요.

마지막으로 EJB 3.0에서 중복이 사라지지 않았다고 하시는 건 이해가 안가는 군요. 실제 EJB 3를 사용해 보셨는 지 모르겠습니다만, 예컨대 일반 자바 클래스와 EJB 세션빈의 차이는 '@Local'이란 어노테이션 한 줄입니다. 더 이상 얼마나 간편화 시켜야지 중복이 제거 되고 'PHP 만큼' 편리하게 될른지 모르겠군요. 또 과연 EJB 3를 쓸 수 있는 도메인에 모두 PHP를 대체해서 같은 결과를 얻을 수 있을 지 의문입니다.

[서명] 그놈 한국 사용자 모임 -
그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

scalability의 개념은 쓰는 사람마다 다르긴 하지만 fender님의 정의는 말씀하지 않으시면서 이건 아니다..라고 말씀하시니 좀 당혹스럽군요. onjava.com이나 javalobby 등 여러 자바 사이트에서 나온 article에는 대부분 scalability의 첫째 요건으로 performance를 들고 있고 그 다음으로 많이 나오는 게 fault tolerance입니다. 어차피 자의적 정의 아니냐 하실 수도 있겠지만 언어는 사람들이 많이 쓰는 방향으로 가는 것 아니던가요. scalability의 핵심이 performance임을 부정하는 사람은 아직 별로 본 적이 없는 것 같습니다.

그리고 전 배우기 어렵다는 것을 이유로 제시한 적이 없습니다. 배우기 어렵기 때문에, 러닝 커브가 크기 때문에 프레임웍들에 이의를 제기하는 것이 아니고 프레임웍의 설계가 별로 좋지 않은 것들이 많기 때문에 이의를 제기하는 것입니다. Spring의 JdbcTemplate은 쉽고 편합니다만, 그보다 더 편하게도 만들 수 있습니다. JSF를 IDE에서 사용하는 것은 편하지만 IDE를 벗어나면 기능 하나 추가할 때마다 스트레스 팍팍 받죠.

여러 가지 예를 많이 드셨는데 PHP는 마치 모듈화가 불가능한 언어인 것처럼 말씀을 하시는 것 같습니다. OOP 언어이기만 하면, 아니 SP만 가능해도 컴포넌트 기술은 가능합니다. 이를테면 다음과 같은 코드는

자꾸 프레임웍 vs 수작업을 비교하고 있으신데 전 그런 비교를 하는 게 아닙니다. 프레임웍 vs OOP적으로 잘 모듈화된 코드를 이야기하는 것이죠. 한 줄 추가로 선언적 트랜잭션을 가능하게 하는 것? 전 여기서 선언적이란 방식에 이의를 제기할 뿐이지 간단하게 트랜잭션을 가능하게 하는 것을 반대하진 않습니다. PHP도 웹에서의 영향력은 자바 못지 않고 이미 많은 라이브러리가 있습니다. Ruby on Rails가 블로그 15분만에 만들 수 있다면 PHP는 수많은 웹 사이트 템플릿 덕에 간단한 쇼핑몰 정도는 3분 커스터마이즈로 만들 수 있는 솔루션도 많습니다.

요컨대, PHP도 이미 문법적으로 컴포넌트 기술을 구현하기에 별로 부족함이 없으며 자바와 방식은 다를지언정 이미 많은 비즈니스 니즈를 소화하는 컴포넌트가 있고 활용하기도 자바보다 불편하지 않다는 것입니다. 두 언어의 방식은 분명히 다르고 분명 장단점도 있겠습니다만 자바에는 프레임웍이 많은데 PHP는 아니다..라는 것은 부적절한 비판이라고 봅니다. 단지 방식이 다를 뿐 PHP에도 많은 라이브러리가 있으니까요.

제가 PHP의 라이브러리들은 별로 찾아본 적이 없어서 이게 있다 없다를 확실하게 말씀드릴 수 없는 점은 안타깝습니다만 말씀하신 것들은 대부분 PHP에서 방식은 다르지만 대체 가능한 것들이라고 봅니다. 그렇게 생각하는 결정적인 이유는 말씀하신 모든 기술들을 자바에서 그 프레임웍을 사용하지 않고도 어렵지 않게, 아니 오히려 더 나은 방식으로 구현할 수 있었고 PHP란 언어는 자바에 비해 언어 자체의 파워가 떨어지는 것은 아니라고 보기 때문입니다. 사실 보안 같은 것도 EJB의 장점으로 많이들 내세우지만 RBAC 정도 지원하는 권한 프레임웍 만들어서 갖다 붙이는 게 EJB의 보안 기능 쓰는 것보다 편합니다.

물론 자바에는 있는데 PHP에선 다른 방식으로도 대체하지 못하는 그런 것들도 있을 것입니다. 하지만 대신 PHP는 자바보다 좀더 agile하기 때문에 그런 요구사항들을 빨리 빨리 컴포넌트로 만들어낼 수 있기 때문에 결국 대규모 프로젝트를 하다보면 컴포넌트를 안 만들 수 없는 상황에서 PHP가 불리할 것은 별로 없다는 생각입니다.

EJB 3.0은 제가 착각했는지도 모르겠군요. 제가 기억하기로는 여전히 interface와 implementation을 분리해야하고 dependency injection도 xml에 써넣어야 하고 EJB 서버의 web.xml에도 기술을 해줘야 하는 것으로 알고 있습니다. 웹 서비스보다는 여전히 할 일이 많은 것 아닌가요?

벤치마크 자료를 몇 찾았네요.

PHP, ASP, Coldfusion, JSP의 비교
http://www.linuxdocs.org/HOWTOs/PHP-HOWTO-13.html

fastcgi, cgi, servlet, jsp
http://www.cse.iitb.ac.in/~varsha/allpapers/softwarePerformance/web_comp...

fastcgi가 서블릿보다 많이 빠르다는 자료는 이것 말고도 꽤 많이 본 것 같습니다만. 어차피 벤치마크란 것도 상황에 따라 다른 것이니 직접 증거라 할 만한 것은 아닙니다만 강력한 간접 증거는 될 것입니다.

단순히 문자열 몇 개 찍는 페이지 만들어서 MS의 스트레스 툴로 테스트해보면 차이가 꽤 많이 납니다. 믿을 수 없다면 직접 Hello World 정도 찍는 걸 만들어서 테스트해보셔도 될 듯.

일반적으로 통용되는 'scalablity'에 대한 개념은 알고 계신다고 생각했기 때문에 굳이 부연을 안했을 뿐입니다. 그리고 뒤에 코드의 유연성을 말씀하시기에 혹시 'extensible' 한 것과 혼동하시는 것이 아닌가 싶어서 다시 언급한 것입니다. scalability와 단순한 raw performance가 다른 것은 전자의 경우 무엇보다 성능 그래프가 예측가능하게 선형으로 비례해서 증가하는 걸 뜻합니다. 즉, 성능이 딸리면 딸리는 만큼 하드웨어만 가져다 붙이면 계속해서 확장된 부하를 버틸 수 있는 걸 뜻합니다.

제가 원하는 것은 creativeidler님의 주장을 뒷받침하는 구체적인 근거입니다. 단순하게 'PHP도 훨씬 편하게 할 수 있다'가 아니라, 만일 말씀하신 것처럼 JDBCTemplate보다 더 편하게 할 수 있다면 예를들어 PHP에는 그보다 더 편한 어떤 방식이 있는지 제시해 주시기를 바랍니다.

또 JSF가 IDE를 벗어나서 코드를 수정하려면 스트레스를 많이 받는 다고 하셨는데 구체적으로 어떤 경우가 그렇던가요? 웹폼즈는 모르겠습니다만 JSF의 경우 IDE 가 없으면 불편하긴 하지만 최소한 손으로 코딩하는 것보다 불편하진 않다고 생각합니다. PHP에 JSF 같은 컴포넌트 모델이 있는지, 혹은 컴포넌트 모델이건 수작업이건 구체적으로 어떤 면에서 PHP보다 JSF가 크게 불편하다고 보시는 지 예를 들어 주셨으면 좋겠습니다.

(아마 컴포넌트를 사용하지 않고 재활용을 하는 예제를 들으신 것 같은데 코드를 잘못쓰셨는지 안보이는군요. 수정 부탁드립니다).

EJB의 선언적 보안 기능을 말씀하셨는데, 그런 류의 선언적 보안 프레임워크의 핵심은 호출의 '컨텍스트'를 알 수 있다는 점입니다. 즉, 메소드/함수 호출 때 메소드 수준에서 '이 메소드는 이런이런 권한이 있는 사람만 호출 가능하다' 하고 마크하면 굳이 호출자 정보를 파라메터로 넘기지 않아도 (사실 호출자가 자기가 관리자인지 아닌지를 플래그로 넘기는 것 자체가 보안상 말이 안되는 설계 아닌가요?) 별도 코드 없이 자동으로 보안 관리가 되는 개념입니다. Acegi 같은 경우는 여기에 더해서 fine grained한 ACL 까지 지원합니다. PHP에선 이런 방식보다 분명 편하다고 하셨는데 그럼 PHP에선 보안을 어떻게 처리 합니까?

좀 다른 이야기지만 단적인 예로 웹상에 php가 아닌 정적인 컨텐트가 있고 여기에 대한 접근 제어를 동적으로 해야 한다고 가정하면 PHP에서 그런 요구 자체를 처리 할 수 있나요? 자바의 경우 서블릿 필터로 구현하면 간단하게 처리할 수 있습니다만 PHP의 경우 '필터'라는 개념 자체가 있는 지 잘 모르겠군요.

시스템 설계를 하시면 잘 아시겠지만 인터페이스와 구현을 분리하는 것은 제약이 아니라 구현하려는 대상이 EJB 건 뭐건 올바로된 객체지향적 설계의 기본입니다. 그렇지 않으면 인터페이스라는 개념 자체가 필요 없습니다. 참고로 dependency injection은 그냥 변수만 선언하고 @EJB라고 붙이면 끝입니다. 웹단에서는 아직 그 정도 통합은 안되어 있습니다만, 잠재적으로 원격지에 있는 컴포넌트에 대한 참조를 얻어 오는데 그 이상 극단적으로 편리한 방법이 있을 지 의심스럽긴 합니다. J2EE에서 JSP/Servlet 등을 빼고는 침체되어 있는 것처럼 말씀 하셨지만 실제로는 반대입니다. 오히려 JSP/Servlet 쪽이 최근들어 RoR등의 도전을 받고 있지만, EJB3나 JSF등 다른 스펙에 비해 특히 어노테이션의 활용 등에서 획기적인 개선을 보여주지 못하면서 비판 받는 실정입니다.

어쨌든 생산적 토론을 위해서 뭐든지 PHP로 더 편리하게 할 수 있다, 혹은 무조건 J2EE가 우월하다는 식이 아니라 구체적인 사례를 들어서 이야기를 했으면 좋겠습니다.

[서명] 그놈 한국 사용자 모임 -
그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

음... 코드를 고치셨군요 :) 물론 PHP든 무슨 언어든 직접 함수를 짜면 비슷하게는 만들 수 있습니다. 하지만 이벤트 기반 컴포넌트 모델과의 차이는 :

(1) JSF와 같은 표준 컴포넌트는 개발자가 직접 작성하는 것이 아닙니다. 말씀드렸듯이 표준 컴포넌트 이외에도 오라클, 아파치 등에서 수많은 컴포넌트를 제공하고 있습니다.

(2) 모두 JSF라는 표준적인 API를 통해 공통된 인터페이스를 제공합니다. 즉, 찾아보면 PHP에도 이런 저런 기능들을 편리하게 할 수 있는 여러 라이브러리가 있겠지만 사용법은 모두 다를 것입니다. 그리고 표준적인 JSF 컴포넌트라면 예를들어 JSF 기본 컨버터나 validator 등을 어느 써드 파티 컴포넌트에도 그대로 붙여서 쓸 수 있습니다.

(3) (2)와 관련해서 툴지원이 가능합니다. 위에서 직접 $ajaxSuggest("search.keyword", "search.suggestion") 같은 함수를 만드는 경우를 가정하셨는데 그런 함수를 IDE에서 위지윅하게 디자인하거나 자동완성을 하거나 혹은 프로퍼티 속성을 바꾸는 등의 일은 가능하지 않습니다.

(4) 함수를 만들어 쓰는 것과 컴포넌트 모델이 있는 건 근본적인 구조 자체가 다릅니다. 즉, 컴포넌트의 경우 잘 정의된 라이프 사이클이 있고 계층 구조가 있습니다. 또한 예를들어 특정 컴포넌트에서는 하위의 자식 컴포넌트들을 참조해서 조작할 수 있는데, 임의로 함수를 짜서 '컴포넌트'처럼 만들면 '하위'에 있는 다른 '컴포넌트'를 일관되게 조작할 수 있는 방법있을 것 같지 않습니다.

벤치마크에 대해선 저도 평소 fastcgi가 서블릿보다 빠르다는 이야기는 많이 들었습니다. 하지만 PHP와 비교해서 크리티컬한 차이가 난다고 보지는 않습니다.

2002년 자료라는 것을 감안하고 봐야 하지만, 이런 벤치 마크도 있습니다 :
http://www.dmst.aueb.gr/dds/pubs/conf/2002-SANE-DynCont/html/dyncont.htm...

위에서 이야기한 'scalability'와 'raw performance'의 차이를 단적으로 보여 줍니다.

"Also, one of PHP rumored weaknesses, scalability, turned out to be true as shown in the average diagram. The performance of the servlet technology placed it in the middle of our results league. Resilience does not seem to be one of the servlet applications strong points, although, in contrast to PHP, the servlets application exhibited a linear performance degradation"

"The results of PHP were not what we expected... It did not scale well (see BENCH4) and exhausted system processing power when it run, leaving it unusable. Servlets on the other hand, behaved exactly as we expected. They run smoothly, Tomcat performed fast enough for a two year old project in the face of a complete redesign, and their behavior was predictable to some extend, and thus easily profilable."

물론 탐캣 사이트나 레진 사이트 같은 데 있는 벤치 자료에서는 FastCGI나 심지어 정적인 컨텐트를 서비스할 때 아파치 보다 빠르다는 결과도 있지만, 사실 저도 그 정도로 빠르다고 믿지는 않습니다 :)

[서명] 그놈 한국 사용자 모임 -
그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

어쩌다 php VS .net에서 php VS java로 건너왔는지 ㅋ;

커스텀 태그로 어떤 기능을 구현하는 것은 콤포넌트에 기반한 개발 방법입니다. 어떤 기능의 콤포넌트가 언어별로 존재한다면 인터페이스 역시 거의 동일할 것이고 가져다 쓰는 방법만 언어마다 틀릴텐데요. PHP에서 그런것이 되지 말라는 법은 없습니다. 단지 한줄로 되냐 두줄로 되냐의 차이라면 비교할 가치가 없겠죠. 꼭 비교되어야 한다면 python같은 더 간단한 문법을 제공하는 언어 얘기까지 나올듯 싶습니다;; 이길수 있을까요 -.-;

공학적으로만 따져서 가져다 쓰는 방법으로써 프레임웍을 선택해야 한다면 자바와 PHP 모두 고를 수 있는 선택의 폭이 꽤 넓다고 생각합니다. 그리고 다른 언어는 또 어떻습니까? 오히려 자바나 PHP보다 더 많은 라이브러리를 가진 언어들도 있습니다. C같은 언어는 어떻까요? 재활용이나 유지보수는 누가 만드느냐에 따라 달라집니다. 배우기 어려운 건 두분께서도 배제하고 계시니; 자바나 PHP보다 재활용이나 유지보수에 대해 전혀 부족할 리 없습니다.

재활용이 잘 된다 함은 결과물이 다른 결과물의 부속이 될 수 있고 또 다른 새로운 결과물에도 쉽게 쓰일 수 있어야 합니다. 그럼 이런 부속을 더 쉽게 만들 수 있는 언어는 무엇일까요? 이것 역시 다른 언어는 어떻습니까? 어느 언어고 특별히 문법이 지능적이어서 개발자의 의도를 알아서 결과물로 만들어 주지 않는 이상에는 개발하는 과정이나 방법이 다를 뿐 한줄 더 쓰고 덜 쓰고 아무 관계 없다고 생각합니다. 좋은 IDE는 그 언어의 프리미엄 아닐까요?

아 그리고;
다른 이야기지만 단적인 예로 웹상에 php가 아닌 정적인 컨텐트가 있고 여기에 대한 접근 제어를 동적으로 해야 한다고 가정하면 PHP에서 그런 요구 자체를 처리 할 수 있나요? 자바의 경우 서블릿 필터로 구현하면 간단하게 처리할 수 있습니다만 PHP의 경우 '필터'라는 개념 자체가 있는 지 잘 모르겠군요.
php 인터프리터가 요청을 넘겨받기 전에는 php가 정적 컨텐츠에 대한 접근을 제어할 수 없습니다. 하지만 아파치의 기능 중 .htaccess 나 , Rewrite모듈 설정을 이용해 특정 경로의 컨텐츠들에 대한 접근을 php로 제어를 넘겨서 처리할 수 있습니다.

C, python 개발자 정도가 이 글타래에 뛰어든다면 꼬리에 꼬리를 무는 언어 우월성 얘기로 발전될까 걱정됩니다; 언어때문에 스트레스 받거나 한줄 더 쓰는게 싫으면 언어를 갈아야죠~ 자바도 나름대로, PHP도 나름대로 특성이 있고 충분히 훌륭한 언어들입니다. 잘 아실텐데들;;;

음... 전 사실 자바 하다가 PHP 쓰면서 느낀 것이 디비 쓰는 것이 훨씬 편하다는 것이었습니다. 이 점은 많은 PHP 프로그래머들도 공감하고 있을 것입니다. 그래서 그런 느낌을 자바에서도 갖고 싶었기 때문에 JdbcTemplate과 거의 같은 것을 따로 만들어 썼었죠.(원래는 오픈소스화하려고 했는데 Spring도 나오고 Jakarta DBUtil도 나오고 해서 오픈할 생각은 버렸죠-_-) 그냥 일반적으로 PHP에서 MySQL을 사용하는 방식보다 JdbcTemplate이 많이 편리하다고 생각하시나요?

컴포넌트 기술에 대한 이야기는 두번째 반론에 대해서만 말씀드려도 되겠죠? 1번은 PHP 역시 마찬가지입니다. 이건 기술의 문제가 아니죠. 2번 마찬가지입니다. PHP 클래스는 어떤 PHP 페이지에서도 불러올 수 있는 게 당연하겠죠. 3번 역시 가능합니다. 현재 그런 구현이 없을 뿐이지 불가능할 이유는 아무 것도 없습니다. 오히려 자바처럼 구질구질하게 빈즈 규악 같은 거 지킬 필요도 없습니다. 4번은 AOP의 특성과도 일치하는데 PHP에서도 AOP가 가능합니다. 개인적으로 AOP를 별로 좋아하진 않지만 어쨋든 PHP도 가능합니다.

그리고 보안은 PHP의 보안이 더 편하다는 말은 한 적이 없고 EJB의 보안 모듈 대신에 RBAC 정도 지원하는 모듈 만들어서 갖다 붙이는 것이 더 편하다는 말은 한 적이 있죠. 그리고 선언적 보안 역시 PHP에서 AOP를 이용하면 가능합니다.

그리고 PHP에는 필터가 필요 없죠. 아파치에 붙여서 쓰니까요. 오픈소스의 특징이 뭐겠습니까. 더 잘할 수 있는 다른 녀석이 있으면 붙여서 쓴다는 것이죠.

인터페이스와 구현의 분리가 EJB에 말씀하신 그 이유로 되어 있진 않습니다. 단지 클라이언트 객체와 서버 객체가 다르기 때문에 그렇게 하는 것이죠. 그리고 그게 객체지향 설계의 기본이란 것은 동의할 수 없습니다. 파이썬 같은 언어는 interface도 없고 접근 제한자도 없는데 자바보다 더 OOP적인 언어로 평가받죠. 사실 자바는 자바이기 때문에 interface란 키워드가 필요한 것이죠. event handler 같은 것도 메쏘드만 필요한데 메쏘드만 넘길 수가 없으니까 interface 상속해서 메쏘드 하나 달랑 있는 걸 넘기곤 하지 않습니까. 리팩토링의 관점에서 봐도 다른 구현체가 존재하지 않는 인터페이스와 클래스의 쌍은 하나의 클래스로 합치는 것이 바람직합니다.

그리고 제 경험에 의하면 EJB 3.0보다도 웹 서비스가 더 쉽습니다. 클라이언트 쪽에서는 단지 주소만 알면 되고 아무 것도 등록하거나 만들 필요가 없죠. 서버에서도 POJO에 descriptor 하나면 충분하고 이것도 자동화 가능합니다. 게다가 대부분의 메이저 언어에서 지원하기 때문에 아무 추가 노력 없이 다언어 시스템이 가능하죠. 게다가 웹서비스는 약간의 노력으로 Ajax에서 바로 활용할 수도 있구요.

침체냐 아니냐는 실제로 쓰느냐 아니냐가 말해주는 것이라고 봅니다. 어쨋든 Servlet/JSP는 여전히 대다수의 자바 개발자들이 쓰고 있지만 EJB를 쓰는 자바 개발자는 소수에 지나지 않습니다. Java 책이나 JSP 책은 불티나게 팔리지만 요즘 EJB 책은 참 안 팔리죠. Servlet/JSP가 발전하지 않고 있는 것은 분명하지만 가장 널리 쓰이는 기술이란 점 또한 부인할 수 없는 사실입니다.

[서명] 그놈 한국 사용자 모임 -
그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

저도 처음 포스팅하신 분의 의견에 무척이나 공감합니다.

개발 언어를 떠나서 개발환경(IDE)가 무척이나 중요하다고 생각합니다. 예를 들자면 eclipse 가 뜨자, Sun 에서 부랴부랴 넷빈즈를 같이 릴리즈하는 것을 들 수 있겠습니다.

제가 윈도우 개발자라서 그런지 VS.NET 과 msdn 을 주로 이용하는데 무척이나 편리합니다. 게다가 Visual Assist 같은 환경까지 되면 정말 코딩이 즐거워질 정도니까요.

어떤 책에서보니 manpage 가 빈약한 것은 linux 쪽은 대부분 소스가 공개되어 있기 때문이라더군요. 하지만 요새 초보 개발자들이 소스를 들여다볼까요. 이런면에서 msdn 전략(?)은 무척이나 파워풀한것 같습니다. 일단 초기 진입이 쉬우니까요.

개발자에게 편리한 환경은 결국 해당 개발자들의 인원을 늘리고, 거기서 다시 커뮤니티가 활성화되며, 다시 개발자들을 대상으로 한 상업적인 이용 - 데브피아의 광고라든지 서드파티 개발툴의 개발 - 으로 이어진다는 생각을 해봅니다. 그리고 작업 환경은 더더욱 쉬워지죠.

위의 과정을 거치기 위해서는 역시 OS 벤더에서 밀어주기 - MS 의 Visual Studio 의 개발과 무료로 뿌리기 - 가 선행되면 좋겠죠.

아무래도 아직 리눅스에서의 개발은 힘든면이 있다는 것도 IDE 의 역할이 크다고 생각합니다. 개발을 할 때도 역시 개발툴을 깔기 힘들고, 데비안에서도 조차 의존성을 해결해주는데도 실제 빌드를 하면 몇몇 패키지들이 없다고 나오더군요. 그리고 배포를 하기도 힘듭니다 ( 물론 이건 제가 윈도우에 익숙해서 일 수도 있으나, 배포판들의 난립은 이런면을 확실히 가지고 있다고 생각합니다 )

아직 php 프로그래머분들이 많으시긴 하지만 역시 IDE 의 편리함을 맛보면 앞으로 어떻게 될지 모르겠다는 생각을 해봅니다. 그리고 MS 에서 VS Express 시리즈를 통해서 이미 무료로 IDE 를 뿌리고 있는 상황이기도 하구요. 개발자는 개발을 할 생각을 하지 서버 구축 비용이라든지는 잘 생각하지 않기도 하죠. 특히 학생분들이 간단히 홈페이지 아르바이트를 한다면 이런건 더욱 심각해지기도 합니다.

앞으로 충분히 지켜볼만 할 것 같습니다.

http://www.wimy.com

논점이 아주 좁혀졌군요.

>무슨 방식이든 재활용 가능하게 배포하는 라이브러리를 말하는 것이 아니라 실제로 '동일한' 모델과 인터페이스를 가진 좁은 의미에서 '컴포넌트'를 이야기하는 것입니다.

그런데 사실 "동일한 인터페이스"란 자바이기 때문에 필요한 것입니다. PHP나 파이썬처럼 다이나믹한 언어는 어떤 객체든 이름으로 바로 메쏘드를 호출할 수 있기 때문에 동일한 인터페이스란 것이 필요가 없습니다. 그래서 파이썬 같은 언어도 풍부한 컴포넌트를 가지고 있지만 자바와 같은 방식의 컴포넌트 모델은 없습니다. 자바에서는 GUI 빌더 만드려면 자바빈즈 써야 하지만 파이썬은 그런 규약 없이도 GUI 빌더를 만들 수 있죠. 없어도 손해보지 않는다면 없는 것이 더 좋은 것 아니겠습니까.

우리가 초점을 맞춰야 하는 부분은 그런 컴포넌트 모델로 무엇을 달성할 수 있는가가 아닐까요. 더 빨리 만들게 해준다든지, 더 가독성이 높아진다든지, 더 쉽다든지 등등 말이죠. 자바의 컴포넌트 모델이 다이나믹한 언어의 일반적인 OOP에 비해 어떤 이득을 가져다 줄까요.

PHP로 MySQL을 사용하는 경우 http://kr.php.net/manual/kr/ref.mysql.php 이러한 로우레벨의 API를 지원하는 것으로 알고 있습니다. 하지만 자바의 경우 디비에 관계 없이 동일한 API로 데이터베이스에 접근 가능합니다. PHP에도 JDBC에 비견되는 추상화 계층이 있는지 모르겠습니다만, 일반적인 방법으로 예컨대 같은 코드를 MySQL에서 Oracle이나 DB2로 바꾸었을 때 코드 수정이 없다는 건 큰 장점입니다.

어쨌든 MySQL로 국한해서 이야기해도 기본적인 접속/쿼리 관련 API는 부족함이 없이 제공하고 있지만 JdbcTemplate의 경우 커넥션풀/트랜잭션 처리/커넥션 해제 등을컨테이너 차원에서 자동으로 해결할 뿐 아니라 기본적인 ORM 기능을 제공합니다. 또한 SQL 관련 예외의 경우도 알기 쉽게 해석을 해주는 기능이 있습니다.

컴포넌트나 선언적 보안 모두 '만들면 가능하다'라고 하셨는데 저는 PHP로 비슷한 작업이 '근본적으로 불가능'하다고 주장한 적은 없습니다. 기본 스펙에 포함이되어서 이를 준수하는 모든 어플리케이션 서버에서 똑같이 사용 가능하다는 것과 '지금은 없지만 개발자가 알아서 만들면 된다'는 생산성이나 유지보수 차원에서 상당한 차이가 있다고 생각하는데 어떻게 보시는 지 궁금하군요.

그리고 잘 아시겠지만 '컴포넌트 규약' 같은 걸 말씀 처럼 '구질구질' 하게 만드는 이유는 표준화와 툴지원 때문에 그렇습니다. 물론 PHP 클래스로 만들면 다른 PHP에서 개발자가 직접 불러 쓸 수 있겠지만 제가 이야기하는 건, 예를들어 PHP IDE 같은 거에서 아까 작성하신 AJAX InputSuggest '컴포넌트'를 패키징 해 설치하면 팔레트에 나타나서 위지위그하게 디자인이 되냐는 차원의 이야기입니다.

이미 보셨는 지 모르겠지만, JSF 컴포넌트 기반 개발의 유용함을 보여주는 제품 데모입니다 :
http://developers.sun.com/prodtech/javatools/jscreator/overview/tours/in...

인터페이스가 없다고 OOP가 아닌 건 아니지만, 반대로 언어 패러다임 자체가 인터페이스를 통한 확장을 지원하는 언어에서 인터페이스와 구현의 분리는 핵심적입니다. EJB를 쓰지 않더라도 최소한 자바 세계에서는 다계층 구조의 웹어플에서 비즈니스 계층에서 인터페이스를 사이에 두고 설계를 하는 것은 기본 중에 기본입니다. EJB 2.x의 Remote/Local/Home 인터페이스 같은 걸 상상해서 그런 말씀을 하셨는 지 모르겠지만 EJB 3.0 스펙에서 강제하는 인터페이스와 구현의 분리는 일반적인 설계 관행과 일치합니다.

그리고 솔직히 인터페이스 하나 빼는 게 싫다고 하면 그냥 EJB 안쓰면 됩니다; 3티어고 뭐고 간단한게 좋다면 애초에 EJB 볼 이유도 없고 그냥 JSP 열어서 DbUtil이든 뭐든 써서 include 해서 페이지 단위로 스크립팅 하면 되는 문제입니다. EJB의 효용 자체를 부정하시는 게 아니라면 PHP 등에서 EJB와 동일한 도메인을 훨씬 편리한 방법으로 구현 할 수 있는게 아닌한, 인터페이스 하나 더 만들어야 된다는 걸 설계상의 결함으로 주장하시는 건 좀 납득이 어렵습니다.

그리고 웹 서비스가 PHP에서 더 쉽다고 하셨는데, 다시 한 번 말씀 드리지만 구체적인 사례를 들어 주셨으면 좋겠습니다. 참고로 J2EE 5 기준으로 말씀 드리면 자바에서 웹서비스는 클래스에 "@WebService"라고 쓰고 메소드에 "@WebMethod"라고 붙인 다음에 패키징해서 배포하면 끝입니다. 클라이언트의 경우는 해당 인터페이스에 "@WebServiceRef(wsdlLocation="http://localhost:8080/
helloservice/hello?wsdl"와 같이 WSDL 레퍼런스를 명기하면 그걸로 끝입니다.

과연 PHP에서 이보다 훨씬 쉽게 웹서비스 구현이 된다는 말씀이신가요? 그리고 설사 더 편하다고 쳐도 위에서 든 예들이 그렇게까지 복잡해서 J2EE 플랫폼 자체의 결함이라고 이야기 할 정도로 심각한 문제인지 모르겠습니다.

제가 볼 때 윗 분 말씀대로 한 줄로 되건 두 줄로 되 건 큰 차이가 아니라고 생각합니다만. creativeidler님께서는 어떻게 보시는 지 모르겠군요.

[서명] 그놈 한국 사용자 모임 -
그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...