PHP vs .Net

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, 위키, 갤러리 등등...

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

맞는 말씀입니다. 그래서 현재의 필요를 잘 충족시키는 설계가 미래의 유지보수를 고려하는 설계보다 좋다고 주장하는 것이고 때문에 유지보수가 편해진다는 것은 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

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

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

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

<s:inputSuggestAjax binding="search.keyword" suggestedItemsMethod="search.suggestions"/>

<? $ajaxSuggest("search.keyword", "search.suggestion") ?>

자꾸 프레임웍 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에도 기술을 해줘야 하는 것으로 알고 있습니다. 웹 서비스보다는 여전히 할 일이 많은 것 아닌가요?

일반적으로 통용되는 '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 VS .net에서 php VS java로 건너왔는지 ㅋ;

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

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

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

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

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

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

개발 언어를 떠나서 개발환경(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에 비해 어떤 이득을 가져다 줄까요.

음. 제 글을 잘 안 읽고 있다는 느낌을 거듭 받습니다. Java Studio Creator는 제가 이름만 언급 안했다 뿐 처음부터 계속 이야기해왔습니다.

>JSF도 썬에서 비주얼하게 뚝딱 개발할 수 있는 멋진 도구를 내놓고 이제 그걸 오픈소스로 공개하겠다고도 하고

여기서 멋진 도구가 가리키는 게 뭐라고 생각하셨는지요.

그리고 전 웹 서비스가 PHP에서 쉽게 된다는 말은 한 적이 없습니다. 거듭해서 이런 오해를 하고 있으신데 제가 PHP 편을 들고 있는 것은 사실이지만 그렇다고 제 모든 주장이 PHP 편에 서 있다고 생각하실 필요는 없지 않습니까. 다시 봐도 그 부분의 문맥이 오해할 만한 것 같진 않은데요.

>'지금은 없지만 개발자가 알아서 만들면 된다'
이 부분도 좀 그러네요. 전 이런 말을 한 적이 없습니다.

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

지금 되는 IDE는 없는 것 같습니다만 그렇게 만드는 건 별로 어려운 일이 아닙니다. Java에 비해서 말입니다. 커스텀 태그는 끌어다 놓기로 삽입 가능하고 클래스는 삽입 불가능이라고 생각하시나요? 그렇다면 잠시 자바 스윙 디자이너를 떠올려보세요. 자바빈즈 규약만 지키면 다 컴포넌트로 만들 수 있습니다. PHP는 다이나믹 언어이므로 빈즈 규약 같은 게 필요 없죠. 그렇다면 PHP는 모든 클래스를 다 그렇게 만들 수 있다는 뜻입니다.

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

네, 그래서 대부분의 자바 개발자들이 EJB를 안 쓰는 것으로 알고 있습니다. 그 이유가 꼭 인터페이스 하나 때문은 아니지만 그 귀찮음이 큰 이유인 건 사실이죠. 그렇다고 JSP 하나만 열어서 하라는 말은 확대해석입니다. 프레임웍론자들이 흔히 저지르는 오류죠. 프레임웍의 단점을 이야기하면 꼭 나오는 이야기, "그럼 JSP 하나 안에서 전부 다해." 이건 합리적인 반론이라고 하기 어려운 것 같습니다.

말씀하신 EJB의 장점들이 있긴 합니다만 그렇다고 결함을 결함이라고 말하지 말라는 건 좀 그렇군요. 제가 아직 PHP는 넓게 알지 못하기 때문에 뭐뭐가 있는지 확답은 못 드리겠으나, 제 경험상 자바로 일주일 걸렸던 RBAC 기반 인증 모듈을 PHP로는 단 하루만에 만들었었고 JdbcTemplate과 비슷한 래퍼 만드는데 2시간 걸렸습니다. ORM까지 되진 않지만 말입니다. 우리가 막강한 컴포넌트라고 생각하는 것들이 의외로 필요한 부분만 구현하면 아주 짧은 시간 내에 만들 수 있다는 것입니다. 물론 그렇다고 죄다 만들어 쓰자..로 확대해석하진 말아주십시오. PHP에도 많은 컴포넌트가 있고 그냥 갖다 쓸 수 있는 건 자바와 별 다를 바 없습니다.

그리고 자바에서조차 인터페이스와 구현을 일부러 분리하는 것이 핵심이라는 주장은 동의하기 힘듭니다. 구현 클래스는 하나 밖에 없는데 인터페이스와 클래스가 따로 있어서 얻는 장점이 무엇입니까? orthogonality가 떨어지는 것은 명백한 사실입니다. 물론 EJB를 쓰지 말아야할 정도로 치명적인지 아닌지는 쉽게 말할 수 있는 문제가 아닐지도 모릅니다만 에초에 제가 말씀드렸던 것처럼 "EJB 3.0도 충분히 중복을 제거한 것이 아니다"라는 주장을 입증하기엔 충분하다고 봅니다.

마법 같은 것이 아니라 자바빈즈 규약이 존재하는 이유는 프로퍼티를 동적으로 엑세스할 수 있게 하기 위해서이기 때문입니다. 위지윅 디자이너는 결국 이런 프로퍼티를 동적으로 조작해서 조합하는 거구요. 그런데 다이나믹 언어는 빈즈 규약 없이도 프로퍼티를 동적으로 조작할 수 있기 때문에 빈즈 규약이 필요 없다는 것입니다. 그러니 아무 수정도 하지 않고 어디든 갖다 쓸 수 있는 것이죠. 클래스를 갖다 쓰는데 수정해야할 필요가 없는 것은 당연하지 않겠습니까.

JSF는 이런 정도의 유연성은 확보되지 않죠. 스윙에서 만든 리스너 클래스를 JSF에서 그대로 쓸 수는 없으니까요.

네, 물론 위지윅 디자이너가 지금 있는 건 아닙니다. 아니, 찾아보지 않아서 그렇지 있을지도 모르죠. HTML 위지윅으로 디자인하고 링크를 php 페이지랑 연결해주는 정도는 이미 있는 걸로 압니다. 하지만 이 정도의 이야기로도 "PHP에 컴포넌트 모델이 없기 때문에 IDE를 이용한 위지윅 디자이너는 만들 수 없다"라는 주장에는 충분히 반박된 것 같습니다.

그리고 거듭 말씀드렸듯 전 죄다 다시 개발해서 쓰자는 주의가 결코 아니며 PHP가 그렇다는 말도 한 적이 없습니다. 오히려 자바 프레임웍이 제공하는 많은 기능을 PHP는 다른 방식으로 제공하고 있다는 말씀을 드렸었죠.

그리고 아직 EJB의 보안이나 선언적 트랜잭션을 위지윅으로 할 수 있는 자바 개발툴은 없는 것으로 압니다만. 위지윅이 장점을 발휘하는 것은 UI 부분이지 다른 부분이 아니죠. UI 외의 부분을 갖다 쓰는 건 자바라고 더 쉽고 PHP라고 더 어려운 것일 수가 없죠. UI 부분 컴포넌트를 봐도 페이징이라든지 Ajax 컴포넌트, validator 등 PHP에도 다 있습니다. 위지윅으로 안된다 뿐이지 한두줄 추가로 가능한 건 똑같습니다.

>J2EE 플랫폼이 제공하는 것과 같은 기능은 PHP로 대부분 별로 공수 안들이고 만들어 쓸 수 있는데, 반대로 기존 프레임워크 없이 JSP/자바만 가지고 하는 것은 훨씬 번거롭고 복잡하다라고 생각하신다면
전 이렇게 주장한 바가 없습니다. "J2EE 플랫폼이 제공하는 것과 같은 기능"이 아니라 "비즈니스 니즈에 맞는 기능"을 구현하는데 PHP가 공수가 적게 든다는 주장을 했었죠. 그리고 프레임웍 없이 하는 것이 번거롭고 복잡하다고 말한 적도 없습니다. 어찌하여 제가 그렇게 생각한다고 생각하셨는지 궁금하군요.

그리고, 약간은 논외지만 이왕 나온 이야기니만큼 좀더 하자면 생각의 각도를 조금 바꿔볼 필요가 있는 것 같습니다. 이야기 중에 Acegi가 잠깐 나왔었죠? 제 친구가 이거 적용하려고 거의 꼬박 일주일을 매뉴얼 읽고 테스트해보고 했는데 아직도 이게 예전에 쓰던 모듈보다 나은지 판단이 안 선댑니다. 그런데 풀 RBAC이 아니라 조금 간소화한 RBAC을 annotation으로 지원하게 하는 걸 자바로 직접 만들면 사흘도 깁니다. 또, 위키의 창시자이자 XP의 창시자인 워드 커닝햄 같은 사람은 FIT 만들 때 XML 파서조차도 직접 필요한 부분만 만들어서 썼죠. 그러곤 인터뷰에서 그러더군요. 자기가 표준 DOM을 쓰지 않아서 분명 잃는 부분이 있겠지만 아직 그게 무엇인지 발견하지 못했다고. 때때로 가져다 쓰는 것이 정말 쉽고 빠른지 검토해 볼 일입니다.

정말 궁금해서 여쭤보는 것인데 제가 아무리 PHP에 무지하다고 해도 말씀하신 것 같은 자동화는 이해가 가지 않습니다. 아시겠지만 단지 프로퍼티를 '동적으로 조작' 하는 것 만이라면 자바에서도 리플렉션으로 다 됩니다. 자꾸 이야기가 도는 것 같으니 구체적인 예를 들죠.

자바빈즈를 통한 위지윅 디자인은 결코 성공한 예가 아닙니다만 JSF보다는 더 쉽게 이해할 수 있을 것 같아서 일반 IDE에서 빈즈 컴포넌트를 사용하는 법을 예로 들겠습니다.

만일 어떤 컴포넌트 회사에서 임의의 데이터를 받아 그래프를 그려주는 컴포넌트를 개발하고 이를 빈즈를 지원하는 어떤 IDE에서도 동작하도록 배포한다고 봅시다. 이 때 해당 컴포넌트가 빈즈 규약을 따를 경우 IDE는 다음과 같은 작업을 할 수 있습니다 :

(1) 해당 클래스에 대한 BeanInfo를 검색합니다. 즉, 컴포넌트의 아이콘, 설명, 또 커스터마이즈할 수 있는 속성, 이벤트 목록 등을 찾아서 적절하게 팔레트와 속성 창에 뿌릴 수 있습니다.

(2) 속성의 경우 설명은 물론 단순히 텍스트 입력이 아닌 어떤 특별한 편집이 필요한 경우 - 예를들어 글꼴을 고르기 위해 글꼴 창을 띄우는 등 - 임의의 속성 편집기를 선언할 수 있습니다.

(3) 또한 컴포넌트는 IDE가 디자인 타임인지 런타임인지 판단할 수 있습니다. 즉 디자인 타임에만 커스터마이즈 할 수 있는 컨트롤이 보인다던지 디자인 가이드를 보인다던지 하는 기능을 구현할 수 있습니다.

(4) 그리고 다른 컴포넌트와 동적으로 연결할 수 있습니다. 즉, 특정 컴포넌트의 속성이 바뀌면 자동으로 다른 컴포넌트의 어떤 메소드를 호출한다던가 하는 연동이 가능합니다.

대략 빈즈 규약을 따랐을 때 구현 가능한 기능은 위와 같습니다. 제가 아는 상식으로는 아무리 PHP가 동적이고 엄청난 기능이 있다고 해도 어떻게 어떠한 표준적 규약이나 스펙 없이도 아무 클래스나 IDE에 던져 주면 아이콘이 뭔지 설명이 뭔지, 또 어떤 속성을 어떻게 IDE 속성창에 뿌려야 하는 지 자동으로 처리할 수 있다는 건지 모르겠습니다.

JSF의 경우도 마찬가지입니다. 저도 PHP에도 validator가 있고 converter가 있고 하는 걸 모르는게 아닙니다. 제 이야기의 핵심은 예를들어 JSF 처럼 무슨 컴포넌트건 UIInput을 상속한 것이라면 Validator 인터페이스를 구현한 것이면 무엇이든 별도 코딩없이 가져다 붙일 수 있느냐 하는 차원의 이야기입니다. 그리고 정도의 연동이 가능하려면 당연히 'Validator'든 'UIInput'이든 어떤 공통된 스펙과 API가 있어야 한다는 겁니다.

그리고 말씀하시는 것이 '비즈니스에 맞는 기능'을 구현하는데 PHP가 공수가 적게 든다는 것이라면, 그럼 위에서 말한 선언적 트랜잭션이나 보안 등이 크리티컬하게 작용하는 비즈니스는 존재하지 않는다고 생각하시는 건지 반문하고 싶습니다.

왜냐하면 creativeidler님께서는 이러 저런 이유로 J2EE를 비롯한 자바 관련 웹 기술의 차별성으로 제시한 선언적 트랜잭션, 보안, IOC를 통한 DI, 컴포넌트 모델 등등에 대해 '쓸데 없이 복잡하다'거나 'PHP로도 구현할 수 있다'라는 식으로 반박하셨는데, 그렇다면 그런 기능들이 중요하거나 적합한 비즈니스 도메인은 존재 하지 않는 것인가요 아니면 자바에는 기본으로 있어도 PHP로 직접 구현하는게 더 생산성이 높다는 뜻인가요?

그리고 Acegi에서 제공하는 복잡한 ACL이 필요하지 않으시다면 굳이 쓰실 이유가 없을 것 같습니다. Acegi는 선언적 보안뿐 아니라 J2EE 없이 웹단과 서비스단에서 통합된 보안모델을 적용하고 싶거나 특히 도메인 객체에 까지 세세한 ACL 컨트롤을 하고 싶을 때 쓰는 라이브러리입니다. 개발하시는 사이트가 웹단과 서비스단 구분이 명확하지 않거나 도메인 객체 보안을 쓰지 않는 다면 별 필요가 없습니다.

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

한 가지 강력한 근거를 덧붙입니다.

http://www.jcp. org/en/jsr/detail?id=223

PHP 지원이 JSR에 올라오는 이색적인 현상, 커스텀 태그나 JSF에 비해 PHP가 비교우위를 가진 점이 있다는 점을 말해주는 것이 아닐까요?

소타님께 :

논지를 오해하실 까봐 말씀 드리지만, 제가 IDE에서 JSF를 사용해서 위지윅하게 개발하는 예를 든 것은 그것이 J2EE가 PHP보다 우월하다는 근거로서 제시한 것이 아닙니다. 또 PHP의 경우 코드 갤러리 같은 코드 재활용이 불가능하다고 이야기한 적도 없습니다.

'IDE는 그 언어의 프리미엄이지 그 언어의 우열을 나눌만한 요소는 아니다'라고 하셨는데 제 생각도 크게 다르지 않습니다. 제 논점은, creativeidler님의 프레임워크 무용론에 대해서 쉽게 말해 'JSF' 같은 프레임워크가 있는 건 자바가 PHP보다 기능이 떨어지거나, JSF 개발자가 바보라서 만든 게 아니라는 걸 강조하는 것일 뿐입니다.

즉, 프레임워크를 통한 개발 직접 구현하는 경우, 혹은 IDE를 사용한 개발이나 일반 편집기를 쓰는 경우나 모두 각각의 특성과 장단점이 있습니다.

제가 볼 때 JSF의 경우 그와 같은 컴포넌트 기반의 확장성을 제공하고 툴지원을 가능하게 해서 위의 데모 처럼 JSC 같은 개발툴에서 위지윅으로 개발할 수 있는 것은 분명 그와 같은 접근 방식이 가지는 고유한 장점이라고 봅니다.

물론 엔터프라이즈 시장에 주력하는 J2EE 진영의 경우 상대적으로 오버 디자인을 하는 경향이 있습니다. 특히 EJB 2.x나 어쩌면 JSF의 일부도 그 예가 될 수 있을 것입니다. 하지만 그 자체가 프레임워크의 유용함을 부정하는 근거로서는 미약하다고 생각합니다.

다시말해, 만약에 개발하는 특정 도메인에서 J2EE 같은 복잡한 프레임워크 없이 더 높은 생산성과 유지보수에도 뛰어난 결과물을 내놓을 수 있으면 그 언어를 쓰면 됩니다. 또 개인적으로 IDE를 안쓰고 편집기로 더 빠르게 개발할 수 있다면 그냥 편집기를 쓰면 됩니다.

하지만 그런 경우가 있다고 일반적으로 J2EE 플랫폼이나 각종 프레임워크, 혹은 JSF/웹폼즈 같은 컴포넌트 기반 접근 방식 들이 다 쓸모 없다고 생각하거나 별다른 구체적 근거 없이 그런 것들은 자바 언어가 PHP 보다 유연하지 못해서 필요한 것이라고 단정 짓는 것은 잘못된 편견이라고 생각합니다.

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

거듭 말씀드리지만 전 PHP vs Java의 관점에서 이야기하는 것도 아니고 PHP가 Java보다 우월하다는 이야기를 하고 싶은 것도 아닙니다. 제가 fender님이 제 글을 잘 안 읽는 것 같다고 말씀드린 것은 Java Studio Creator 때문만이 아닙니다. 그런 말을 한 적이 없습니다...란 말을 계속 하게 되는 상황 때문입니다.

>그런데 creativeidler님께서는 계속해서 '쉽고 빠르게'란 관점에서 PHP에서도 그런 프레임워크나 라이브러리 없이도 비슷한 걸 다 만들어 쓸 수 있기 때문에 그 부분의 장점은 존재하지 않는다고 주장하고 계신 걸로 이해합니다. 아닌가요?

네, 아닙니다. 이미 수 차례 이야기했든 PHP에도 비슷한 라이브러리들이 다른 방식으로 존재하고 있을 뿐입니다. 비슷한 걸 만들어 쓸 수 있다는 것은 아주 일부분 부족한 것에 대한 이야기입니다. 이해를 돕기 위해 숫자를 끌어온다면 자바 프레임웍의 90% 이상이 이미 PHP에도 다른 방식으로 구현되어 있지만 10% 정도는 없다, 대신 10% 정도는 자바에서 들여야 하는 노력보다 절반 이하의 노력으로 만들 수 있다. 이런 얘깁니다.

>그걸 선언적으로 하지 않고 프로그램적으로 했을 때 훨씬 복잡해 진다는 것도 부정하시겠습니까? 이해가 가지 않는 것은 인터페이스 하나 추가 되는 게 '중복'이라고 큰 결함 같이 생각을 하시면서 선언적인 처리를 프로그램 코드로 대신했을 때 증가하는 코드양과 복잡성은 애써 무시를 하시는 것 같군요.

네, 부정합니다. 선언적이 아니면 코드와 복잡성이 늘어난다는 것은 고정관념입니다. 전 Java에서 선언적인 방식을 다른 방식으로 바꾸어서 LoC와 readability가 오히려 높아지는 경우를 많이 경험했습니다.

>또 설계에 그리 능숙하지 않은 개발자도 따라하기 같은 걸 보고 그닥 나쁘지 않은 best practice를 구현할 수 있다는 장점도 있습니다.

서블릿에 익숙하지 않은 개발자가 Struts를 쓰면 갑자기 익숙한 것처럼 개발할 수 있을까요. Servlet을 그냥 쓸 때에 비해 Struts를 쓸 때 복잡도는 늘어나면 늘어났지 결코 줄어들지 않습니다. 학습 비용을 말하는 게 아니라 복잡도를 말하는 겁니다. 단지 web.xml에서 struts-config.xml로 내용이 옮겨가는 것에 불과합니다. Struts의 핵심인 controller 기능은 간단한 유틸리티 클래스 하나로 완전히 대체 가능하고 오히려 LoC도 줄고 복잡도도 줄일 수 있습니다.

그보다 더 중요한 사실은 실제 개발할 때 부딪히는 어려움은 서블릿 API를 직접 쓰는 불편함이라든가 그런 게 아닙니다. 비즈니스 로직을 구현하는 것이 가장 어려운 일이죠. 이 부분은 어떠한 프레임웍도 best practice를 제공하지 못합니다.

>그런데 creativeidler님께서는 프레임워크의 장점은 마치 그런 '틀'이 정한대로 따라하는 것인 데 틀대로 만들면 틀에서 동작하는 게 당연하다는 말로 이러한 장점을 부정하시고 계십니다. 그리고 기 개발된 어플리케이션의 프레임워크를 바꾸는 결코 일반적이지 않은 상황을 가정해서 프레임워크를 비판하고

역시 조금 확대해석하신 것 같습니다. 전 "인터페이스에 맞추면 어떤 컴포넌트든지 사용 가능하다"라는 주장에 대한 반박으로 "인터페이스에 맞추면 그 프레임웍에서 사용가능하다는 게 당연하지 않느냐"했던 것이지 프레임웍의 장점이 그거라고 보지도 않고 그 장점을 이 논리로 부정하려 하지도 않았습니다. 프레임웍을 바꾸는 것도 프레임웍을 비판하기 위한 논리가 아니라 마찬가지로 "인터페이스에 맞추면 어떤 컴포넌트든지 사용 가능하다"라는 논리가 별로 큰 장점이 아니라는 것을 말하기 위해 한 말입니다. 그리고 참고로 프레임웍을 바꾸는 것이 일반적이진 않지만 한 번 일어날 때의 고통은 적지 않더군요.

>또 공수나 최종 결과물에 관계 없이 프레임워크 사용 안해도 결과가 나온다면 마치 프레임워크의 존재 의미가 없는 것 같은 말씀을 하시는 데 저로서는 별로 납득이 안가는 주장입니다.

전 이런 말도 한 적이 없습니다. 오히려 정 반대의 이야기가 제 논지의 핵심입니다. 공수와 최종 결과물을 향상시키지 못한다면 프레임웍이 의미 없다는 것이죠.

>마지막으로 자바에 PHP 지원이 들어간 것이 PHP의 비교 우위를 말하는 강력한 근거라면 PHP에는 훨씬 이전부터 자바 지원이 있었다는 점을 지적하고 싶군요.

네, 그렇습니다. 자바도 PHP에 대해 비교 우위가 있죠. 그걸 부정한 적이 있었던가요? 전 프레임웍이 그 비교우위 가 아니라고 했을 뿐입니다.

그리고 다른 분에게 한 답글이지만...

>'JSF' 같은 프레임워크가 있는 건 자바가 PHP보다 기능이 떨어지거나, JSF 개발자가 바보라서 만든 게 아니라는 걸 강조하는 것일 뿐입니다.

전 자바가 PHP보다 기능이 떨어지기 때문에 JSF가 있다거나 JSF 개발자가 바보라거나 하는 말은 한 적이 없습니다. 계속 PHP의 입장에서 자바를 공격하는 걸로 인식하고 있으신데 처음부터 제 글을 한 번 읽어봐 주시겠습니까? 전 이번 논쟁에서 단 한 번도 일관성이 흐트러진 적이 없다고 생각합니다. 처음부터 끝까지 단 하나의 이야기, 자바나 .NET이 PHP보다 프레임웍 때문에 더 좋다고 말할 수 없다는 이야기를 하고 있고 제가 한 모든 이야기는 거기에 연결되어 있습니다.

물론 제 논지의 일부분에 반박을 하는 것이 잘못이라는 건 아닙니다. 하지만 fender님은 지금 절 PHP 진영에서 Java를 공격하는 걸로 인식하고 있으시기 때문에 거듭해서 제 글을 확대해석하고 있으신 겁니다. 이해 안 간다는 말씀을 하지 마시고 제 글을 이해하기 위해 조금만 더 노력해주시면 안될까요. 제 글이 그렇게 이해하기 어렵게 쓰여 있나요?

어쨋든 이 정도면 이 논쟁을 지켜본 대부분의 사람들은 PHP가 프레임웍 때문에 자바나 .NET에 꿇리는 건 아니라는 데 합의를 할 수 있을 것이라 생각합니다. 프레임웍 무용론에 대해서는 따로 쓰레드를 열어서 계속해보는 건 어떨까요? 전 한 때 프레임웍 광신도였다가 프레임웍 무용론자로, 그리고 이제는 설계 잘 된 프레임웍만 쓰자는 주의로 바뀌어가고 있기 때문에 이 문제에 대해서는 더 이야기할 의향이 있습니다. 전 여전히 JSF도, EJB도, Struts, Acegi도 별로 잘 설계된 프레임웍이 아니라고 보고 있고 더 나은 방법이 많다고 생각합니다. 참고로 javaservice.net에서도 비슷한 논쟁이 있었고 거기서 이어가는 것도 나쁘지 않을 것입니다.

제가 creativeidler님의 글을 읽지 않아서 이해를 못하는 것일까요?

그럼 도대체 creativeidler님의 생각에서 '자바의 비교 우위'는 어떤 건가요? WAS가 더 비싸니까 프로젝트 견적을 더 낼 수 있는 건가요? :)

상식적으로 특정 기술이 다른 기술보다 성능, 생산성, 유지보수성, 지원 라이브러리 등등 모두 우월하거나 최소한 대등하다고 주장하시면서 'PHP의 입장에서 J2EE를 비판하는 것이 아니다'라고 말씀하시는 이유를 모르겠습니다.

선언적 보안이 LOC를 줄인다는 걸 부정하셨는데 구체적인 예를 하나 들지요,

웹단에서 분리된 비즈니스 계층에서 호출자가 특정 Role에 속하는 지 판단해야 한다고 가정하겠습니다. 자바에서 선언적 보안이라면 해당 메소드 위에 "@Role(권한명)"을 붙이면 됩니다. 그럼 프로그램적인 방법으로 더 LOC를 줄이는 방법은 뭐가 있나요? PHP라고 if 한 줄 없이 그런 기능이 제공이 되던가요? 또 파라메터로 넘기지 않고 호출자의 신원을 확인할 수 있는 방법은 뭐가 있나요? 말씀 드렸지만 서비스에 보안을 적용하는데 호출자가 직접 '나는 관리자다'라고 말하는 건 제대로된 보안이 아니라고 봅니다만...

어쩌면 php에서도 메소드 하나에 if 3-4줄씩 더 붙여서 비슷한 구현이 될지는 모르겠습니다. 그런데 대규모 프로젝트에서 서비스 모듈이 하나만 있는 것도 아니고 모듈에 메소드가 하나만 있는 건 아니지 않습니까? 인터페이스 하나를 만드는 걸 '중복'된 기능으로 생각하신다면 보안 적용 때문에 같은 코드가 모듈마다 메소드마다 들어간 다는 건 중복으로 보지 않으신 건가요?

마지막으로 Struts의 MVC예를 드셨는데, MVC라는 개념이 왜 나오게 됐는지 이해하신다면 굳이 복잡도를 비교하려면 '서블릿 개발 vs 스트러츠 개발'이 아니라 '서블릿으로 커맨드 패턴 기반의 MVC 프레임워크를 만들어 쓰는 경우'와 '스트러츠로 MVC적 설계를 구현하는 경우'를 비교해야 된다는 건 설명 안드려도 납득 하실 것 같습니다. MVC 자체가 best practice가 아니라거나 잘못된 개념이라고 비판하시는 건 논거에 따라 유효한 주장이 될 수 있지만 MVC프레임워크의 유용성을 비교하면서 MVC프레임워크를 쓰는 경우와 아예 MVC를 채택하지 않는 경우를 비교하는 건 제대로된 비교가 아닙니다.

원하시면 글타래를 따로 뽑는 것도 괜찮을 것 같군요. 한참 토론을 하다 보니 게시판이 아니라 블로그네요 :) 주인장이신 맨발님께서 어떻게 생각하시냐에 따라 결정해야 할 것 같습니다.

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

상식적으로 생각해서 admin이란 관리자가 john이란 사용자를 지우는데 deleteUser("admin", "john") 이런 식으로 자기가 스스로 '내가 admin이다'라고 밝히는 게 제대로된 보안모델인가요? 물론 웹티어에 모든 로직이 다 들어있는 간단한 게시판이나 CMS 정도면 그 정도 보안으로 충분할지 모릅니다만 엔터프라이즈 수준의 어플리케이션에서는 상당한 제약이 됩니다.

MVC이야기로 넘어가서, 그럼 정말로 스트러츠를 안쓰고 MVC를 구현 하는게 스트러츠를 확장해 쓰는 것보다 훨씬 생산성도 높고 간단하다는 주장이신가요? 스트러츠를 써보셨으면 아시겠지만 프로세스 하나 작성하는 건, 라이브러리 카피하고 web.xml에 서블릿하나 등록한 다음에 바로 Action 구현하고 struts-config.xml에 매핑하면 끝입니다. 도대체 어떤 방법으로 구현하면 MVC 계층을 다 직접 작성해도 그 보다 쉽고 빠르게 하실 수 있다는 건지 저로서는 감도 잘 오지 않는 군요. 혹시 코드 샘플이 있으시거나 설명이 가능하시면 부탁드립니다.

두 언어의 비교우위에 대한 입장은 잘 알았습니다(물론 개인적으로 동의하진 않습니다 :)). 그런 입장이시라면 굳이 'PHP 편에서 J2EE'를 비판한다고 생각하진 않겠습니다. 어차피 제 관점도 자바가 우월하니 PHP가 우월하니를 따질 생각이 아닌 이상 그 부분에 대한 creativeidler님의 생각을 뭐라하고 싶진 않습니다. 따라서 앞으로의 이야기도 제가 자바의 비교우위라고 생각하는 프레임워크/플랫폼 지원에 국한시켜 이야기 하겠습니다.

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

creativeidler 님과 fender 의 유익한(? 제가생각하기에..) 토론 잘 보고 있습니다.
계속 이어주시면 감사하겠네요. ^^

두분의 입장차는 프레임웍의 범위(?)의 차이인것 같습니다.
creativeidler 님이 생각하기에는 프레임웍이 너무 군더더기(?)가 많다고 생각하시는 것같고,
fender 님은 프레임웍 없이 하는 것 보다는 프레임웍으로 하는 것이 더 좋다.(중복, 군더더기가 많음에도 불구하고..)

인것 같습니다.(간단히 요약할 수 있는 것은 아니겠지만요.)

이런 인식 차이는 프레임웍의 좋고 나쁨을 판단하기 어려울 것 같습니다. ^^

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

죄송하지만, 전 고수가 아닙니다만... 그리고 이 토론에 나오는 개념들을 이해하실 능력이 안되는 게 제 잘못은 아닌 거 같은데요? :)

전문용어를 안쓰고 'IOC Container'를 뭐라고 말해야 하나요... 김치하 교수님께 물어볼까요? 무슨 '뒤집어 잡아 움직이기 상자' 정도 되려나요? ㅎㅎ

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

그리고 anonymous에게..

잘 이해 안 가는 용어가 있으면 질문해주세요. 알아듣기 쉽게 설명해드리겠습니다.
말로 하는 것을 실제 코드로 구현해 내는 능력, 물론 중요합니다. 하지만 그건 그거고 이건 이거죠. 기술적인 토론을 하는데 꼭 비전문가가 알아들을 만큼 쉬운 용어들을 사용해야 하는 것은 아니지 않겠습니까.

음... 실력을 운운하고 싶은 생각은 전혀 없습니다. 그리고 뜬금없이 이런 토론 하다가 코딩 대결이라도 해서 누가 더 잘하느니 하고 결론 내리는 게 필요하다고 보지도 않구요.

제가 MVC/JAAS에 대해 정확한 개념을 오해하고 계시다고 판단한 근거는 제가 볼 때 말씀하신 예제가 요점을 완전히 벗어나 있기 때문입니다.

JAAS의 경우 인증시에 id/pw 같은 credential을 넘기는 거야 당연하지만, 제가 이야기한 identification을 넘겨야 한다는 게 그런게 아니지 않습니까? 오히려 JAAS를 잘 알고 계신다니 그렇게 반문하시는 것이 더 이해가지 않아서 그렇게 생각했을 뿐입니다.

어쨌든 처음에 선언적 보안, 그리고 JAAS 같은 프레임워크 이야기가 나온 것은 그러한 J2EE 플랫폼의 기능들이 불필요한 코딩을 줄여주고 보다 구조적으로 나은 결과물을 얻을 수 있게 한다는 단적인 예로 든 것입니다.

즉, 호출자의 identification을 개발자가 넘기건 플랫폼이 대신 알아서 해주건 상관이 없는 게 아니라 바로 그게 개발자가 할 일을 플랫폼을 사용함으로서 간소화 할 수 있는 예가 되는 것이고, 또 인증을 받을 대상이 스스로 인증 정보를 제공하지 않는 다는 점에서 더 나은 구조라는 것입니다. 구체적인 예를 들어야 할까요?

전형적인 다계층 구조의 어플리케이션에서는 계층을 넘나드는 호출이 흔하다는 것은 설명 안드려도 될 것 같습니다. 만일 프리젠테이션 계층의 특정 클래스가 비즈니스 계층의 특정 서비스를 호출하고 그 서비스가 다시 다른 서비스를 호출해서 프로세스를 처리 한다고 가정해 보겠습니다.

말씀하신 "나 마이클 잭슨이다. 비밀번호는 XXX다" 같은 절차는 이런 호출 구조와 아무런 관계가 없습니다. 그건 로그인 할 때 한 번만 일어나는 과정이지 로그인후 보안이 필요한 모든 메소드 호출마다 모조리 아이디와 비번을 넘겨서 인증을 할 수는 없는 거 아닙니까? 그렇다면 어떻게 계층간 호출에서 호출자의 신원을 넘기시겠습니까?

잘 아시겠지만, JAAS와 선언적 보안을 사용하게 되면 웹계층-비즈니스 모듈1-비즈니스모듈2의 호출간에 메소드 파라메터에 보안 관련한 어떤 정보도 넣을 필요가 없습니다. 다시 말씀드리지만 어차피 플랫폼이 넘겨 주는 거 아니냐고 반문하시는 건 의미가 없습니다, 이야기의 핵심은 그런 역할을 플랫폼에 위임하는 것이 불필요한 코드를 줄여주느냐 마느냐이지 정말로 어느 누구도 인증 정보를 넘기지 않느냐는 게 아니니까 말입니다. 제가 궁금한 것은 말씀하시는, 그런 플랫폼이 없는 경우라면 어떻게 처리하시는 가 하는 것입니다.

어쨌든 개발자가 직접 인증 정보를 넘기지 않는다는 말을 '그럼 id/pwd도 없이 로그인은 어떻게 하냐?'는 식으로 반문하시니까 JAAS를 잘 모르시는 게 아닌가 하고 의심을 한 것 뿐입니다. creativeidler님께서 이와 같은 주장에 반론을 하시고 싶으시면 JAAS같은 기능을 사용하지 않고 이를 더 편리하고 나은 구조로 구현하는 예를 드시면 되는 것입니다.

MVC가 웹에서만 쓰는 게 아니라는 건 저도 잘 알고 있습니다만, 보다 정확한 표현을 원하시면 말씀대로 Front-Controller라고 하셔도 좋습니다. 그렇다면 웹에서 쓰는 그런 프론트 컨트롤러는 커맨드 기반이 아니라는 뜻인가요?

스트러츠를 소스 레벨까지 파악하고 계시다면 제가 구체적으로 ActionServlet/Action/ActionForm 구분을 말씀 드려도 부연 설명 없이 이해 하시리라고 믿습니다. 말씀하신 단일한 서블릿이 임의의 뷰로 포워드 하는 모델에서 서블릿이 ActionServlet, 즉 컨트롤러의 역할이면 Action에 해당하는 건 뭔가요? 제가 아는 상식으로는 Action 객체가 커맨드가 맞습니다만, (이름이 왜 'Action'인지 잘 생각해 보시기 바랍니다. javax.swing.action과 연관 지으셔도 됩니다) 웹기반 MVC에서 서블릿과 액션이 하는 역할이 같다고 주장하시는 건 이해가 가지 않습니다.

커맨드 패턴을 잘 아신다고 가정을 하면, 일반적인 커맨드 패턴은 특정 조건에 따라 다양한 프로세스를 동일한 인터페이스로 구현한 각각의 개별 커맨드 객체가 존재한다는 건 더 복잡하게 말씀 안드려도 될 것 같습니다. 그런데 그럼 creativeidler님께서 말씀하시는 직접 만드신 'MVC' 프레임워크에서는 Action에 해당하는 게 없고 서블릿 자체가 커맨드 역할이라면 서블릿을 구현할 프로세스 수 만큼 만들어야 한다는 말씀이신가요? 말씀 하시는 프레임워크에 대해 어느 정도 구체적인 예를 들어 주셨으면 좋겠습니다.

그리고 제가 이미 전제 했듯이 스트러츠는 이미 낡은 기술이고 스트러츠에서 가능했던 것은 이미 스트러츠 없이도 대부분 '다른 라이브러리와 프레임워크로'가능하게 되었습니다. commons-validator 예를 드셨는데, 그 자체도 일종의 프레임워크라고 보지 않으시나요? 단순하게 '라이브러리'라고 생각한다면 필수값이나 이메일 체크 등 관련 정적 메소드를 잔뜩 모아 놓은 유틸 클래스 하나로 족합니다. 하지만 Validator 인터페이스를 구현해서 xml으로 설정하는 방법으로 확장할 수 있는 뼈대를 제공하는 것이 commons-validator입니다. 그래서 스트러츠 뿐 아니라 MyFace 다른 여러 프로젝트에서 보다 편하게 확장해서 쓸 수 있는 것입니다.

어쨌든 그런 '프레임워크'를 스트러츠와 분리해서 사용할 수 있다는 사실을 주장하시는 프레임워크 무용론에 대한 근거로 사용하시는 건 저로서는 상당히 의외입니다.

그리고 혹시라도 기분 상하셨을 까봐 말씀 드리는데, JAAS나 MVC를 잘 모르시는 것 같다는 것은 위와 같이 제가 볼 때 요점을 벗어나거나 정확하지 않은 주장을 하시기 때문에 말씀 드린 것이지 '이런 것도 모르냐'는 식의 면박은 절대 아닙니다. creativeidler님이 얼마나 유명하신지도 모르겠고 저보다 실력이 좋으신지 못하신지는 모르겠습니다만, 지금 토론 핵심을 떠나 논리가 아닌 그런 걸로 서로 누가 잘낫다를 가린다면 다른 분들이 유치하다고 놀릴 것 같군요 :)

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

음. 유명..이야기나 실력..이야기는 그냥 해본 소리입니다. 그냥 내가 잡지에다 MVC랑 IoC 강좌도 쓰고 그랬는데 MVC에 익숙하지 않아서 이런 소리를 한다는 이야기를 듣다니...하는 혼자만의 푸념으로 봐주시면 되겠습니다. 어떤 손님이 저에게 금칠을 해주셨는데 아직 그런 말씀을 듣기는 좀 민망합니다-_- 이런 걸로 우열을 가릴 생각은 추호도 없습니다. 다만 "니가 잘 몰라서 그런 소릴 하고 있어" 식의 이야기는 더 이상 나오지 않았으면 하는 바램입니다.

>이야기의 핵심은 그런 역할을 플랫폼에 위임하는 것이 불필요한 코드를 줄여주느냐 마느냐이지 정말로 어느 누구도 인증 정보를 넘기지 않느냐는 게 아니니까 말입니다.

이야기의 핵심이란 건 한쪽이 마음대로 정할 수 있는 건 아닌 것 같은데요.

제가 보안 문제에 대해 반론한 첫 글을 봐주시기 바랍니다. 제가 반박한 이유는 fender님이 글이 마치 인증 대상자의 정보가 아무 것도 없어도 프레임웍이 알아서 마술처럼 권한 처리를 해준다는 것처럼 쓰여 있었기 때문입니다. 지금 쓰신 글을 보니 다행히 그런 오해를 하고 있으신 것 같진 않으니 이 문제는 더 이야기할 필요는 없는 것 같습니다.

별로 길어질 필요가 없는 이 논의가 길어지게 된 요인으로 또다시 확대해석 문제를 들지 않을 수가 없습니다. 전 그저 정보를 넘겨줘야 한다는 말을 했을 뿐인데 fender님은 "개발자"라는 주어를 임의로 집어 넣으셨고 그래서 제가 J2EE 보안 모델도 모르면서 떠들고 있다고 생각하신 것 같습니다. 제발 제가 한 말 그대로로만 해석해주시기 바랍니다.

그리고 권한 처리에 대해 선언적이 아닌 방식에 대한 예는 이미 들었습니다. fender님이 드신 예, annotation을 활용하는 예에 대해 메소드 호출 한 줄 추가하는 것으로 똑같이 가능하다는 설명을 드린 바 있습니다.

그리고 스트러츠, 이렇게 말씀하셨는데...
>말씀하신 단일한 서블릿이 임의의 뷰로 포워드 하는 모델에서 서블릿이 ActionServlet, 즉 컨트롤러의 역할이면 Action에 해당하는 건 뭔가요?

전 "단일한 서블릿"이라는 말을 한 적이 없습니다. 대신에 이렇게 1:1로 대응을 시켜서 설명을 했었죠.
>action 객체와 서블릿 객체는 하는 역할이 MVC의 입장에선 거의 완전히 동등합니다.

즉, ActionServlet에 해당하는 것은 서블릿 엔진이고 Action에 해당하는 것이 서블릿입니다. 이러면 구체적인 예 없이도 제가 무슨 말 하는지 아실 것입니다.

>commons-validator 예를 드셨는데, 그 자체도 일종의 프레임워크라고 보지 않으시나요?
네, 그렇게 볼 수 있습니다. 전 어디까지나 필요 이상으로 복잡도를 증가시키는 프레임웍들, 그리고 그 예로 스트러츠를 비판하고 있는 것이지 프레임웍 무용론자는 아님을 이미 밝힌 바 있습니다. IoC도 처음 제가 언급할 때 어떻게 언급했는지를 살펴봐 주세요. 전 IoC 무용론자도 아닙니다. 꼭 필요한 상황이 아니라면 피하는 것이 좋다고 생각하는 정도이고 이 정도로 생각하는 저 외에도 개발자는 많이 만날 수 있을 것입니다.

그리고 pok님께서 제기하신 주제는 흥미 있는 주제입니다만 거기까지 가게 되면 이 쓰레드의 범위를 너무 벗어나게 될 것 같습니다. 이미 벗어나지 않았느냐-_- 하실 수도 있겠지만 아직은 연결고리가 있거든요.

그리고 사실 이렇게 오해가 많이 발생하는 것도 너무 다양한 화제가 등장한 때문이 아닌가 싶습니다. 돌이켜보면 제가 불필요하게 논의를 확대시킨 포인트가 몇 개 보이는군요. 역시 하고 싶은 말 전부 다 하면 토론이 필요 이상으로 길어지는 것 같습니다. long method만큼이나 긴 토론도 bad smell이 나겠죠.

생산적인 프레임웍의 조건.. 이 주제에 대해서는 따로 쓰레드를 여는 것이 어떻겠습니까? 그러면 저도 기쁜 마음으로 참여하겠습니다.

이번 쓰레드 자체는 fender님과 저 사이에 아직 몇 가지 오해가 남아 있는 것 같지만 제가 끼어든 목적 자체는 어느 정도 달성된 것 같습니다. 여기까지 다 읽으신 분이라면 "PHP는 프레임웍이 없으니까 .NET이나 자바랑은 비교 대상도 안돼!"라고 생각하실 분은 없겠지요. 그래서 이젠 fender님께서 반론하시는 것에 대한 응답 외에는 더 이상 논의를 확대시키지 않도록 노력하겠습니다.

다른 분들 말씀 처럼, 분위기도 너무 과열된 것 같고 해서 적당한 수준에서 이 글타래는 마무리를 하겠습니다.

보안이나 MVC 쪽에 대해서도, 솔직히 아직도 제가 뭔가 잘 의도를 전달 못한 게 아니라면 creativeidler님께서 오해를 하시는 부분이 있다고 생각합니다. 하지만 둘 다 어차피 프레임워크의 유용성에 대해 토론을 하는 중 나온 하나의 예에 불과하니까 이 쯤에서 접고 말씀처럼 혹시 별도 글 타래에서 다시 이야기할 기회가 된다면 그 때 다시 토론에 참여 하겠습니다.

저도 좀 토론의 길이나 전문성에 비해 생산적인 방향으로 가지 못한게 아쉽습니다만... 그래도 KLDP에서 이런 걸로 플레임 하는 게 황교수 사건 같은 걸로 싸우는 거 보단 낫지 않겠습니까? :)

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

두분의 열띤 토론에 .Net이 묻혀져 가고 있군요. :)

어떤 분께서 10위권 내 사이트에 닷넷이 안쓰인다고 하셨는데 그렇진 않습니다. 제가 참여했던 사이트가 10위권 내에 든 적이 있거든요... ;;;

.Net에 대한 소감 몇가지 적어보면...
ASP보단 확실히 고성능이며 MS-SQL쓰는 곳에선 제일 만만하게 쓸 수 있을 것 같습니다.
그리고 ASP보다 나은 개념도 많이 지원하더군요...

하지만... ( VS.Net 2003기준입니다 )
문제는 VS.Net의 IDE가 완전 무개념이었다는 겁니다.
HTML디자이너분께서 예쁘게 만들어 주신 HTML코드를 IDE가 다 깨먹어 버리더군요.
그래서 새로 입사하신분들께 HTML에디터의 스마트한 기능을 다 끄는 방법을 가르쳐 드리는 웃지 못할 상황이 발생합니다.

그리고 서버컨트롤 문제인데...
막상 실무에서 쓸만한 서버컨트롤이 몇개 없습니다.
HTML디자이너분의 코드를 수용 할 수 없는 경우도 다반사고 거의 쓸만한 건 리피터 밖에 없던데 이것 마저도 기능이 부실해서 리피터를 개량해서 만들어야 했습니다.
만드는 과정에도 복잡한 상속 계층과 여러가지 지켜야할 규약으로 인해 고생 했던 기억이 납니다.

거기다 협업의 문제인데...
이거 개인 PC에서 개발하려면 IIS설치하고 사이트 규모가 큰 경우에는 참 작업하기 짜증납니다.
그리고 나중에 또 서버에 올려야 하죠. 근데 서버에 올리는걸 체계적으로 지원해 주는 기능이 없습니다. ( 2005에선 생긴듯 하더군요 )

그리고 그 자랑하던 VIEWSTATE... 차라리 Ajax기능을 넣으라고 말해주고 싶군요...
쥐도새도 모르게 우리가 알지도 못하는 자바스립트 만들어 넣는거 보면 화부터 납니다.

아무리 생각해도 VS.Net2003의 ASP.Net지원은 테스트 사이트 만들기용으로 밖에 안보입니다.

그래도 역시 MS쪽 서버를 쓰면 선택의 여지는 없겠죠 ? :)
2005가 많이 좋아졌길 바랄 뿐입니다. (2003에서 작성한게 제대로 마이그레이션이 되는지도 잘 모르겠네요)

감히 php 가 java 나 .net 과 논쟁을 불러일으키다니..
..
얼마전만 해도 "하찮은" 스크립트 나부랭이 취급당했던거 같은데..
..
php 질로 밥먹고 사는 입장에서..
암튼 기분 좋네요..
..
..
내 부모님이 영화 드라마에 나오는 잘 생기고 교양있는 갑부들이 아니라
그냥 항상 돈에 쪼들려 아옹다옹하시는 연립주택 동네 아줌마 아저씨라도..
"정"이 들었다는 사실 하나만으로도 교체나 비교할 수 없듯이..
..
php 에 먼저 정이 들어서인지 충분히 만족합니다.
..
..
그보다도..
난 언제 vi 의 저주에서 벗어나서 ide 다운 ide 써보나...

=== 건달의 경지를 꿈꾸며 ===