PHP vs .Net

맨발의 이미지

예.. 압니다.
.NET의 비교 대상은 JAVA이지 적어도 PHP는 아니라는 것을요..
하지만 저는 PHP와 .NET을 사용하고 있고..
적어도 웹 애플리케이션 제작 하나만을 가지고 본다면 어떤 비교가 가능할 것 같아서 갑자기 든 생각을 이렇게 적어봅니다.

PHP를 한 5년 정도 사용 했습니다.
무척 유연하면서도 좋은 언어라고 생각합니다. PHP는..
웹 프로그램을 하는 저는 더 이상 다른 언어에 대한 공부에 필요성을 느낄 수 없었고..
무척 만족하며 사용하고 있었습니다.
그러던 와중에..
업무로 ASP.NET을 해야 할 기회가 생겼습니다.

저도 다른 LINUX유저들과 같이.. M$에 그닥 좋은 인상을 가지지 않고 있던 터였고..
최악의 언어라 말하길 서슴치 않는 ASP에 점과 NET이 붙어 있었던지라 전혀 관심이 없었던 터라
정말 달갑지 않았더랬습니다.

그런데.. 이거..
막상 써보니까..
어랏?! 괜찮은데..?! 이지 않겠습니까..?
하지만 적어도 제겐 .NET 1.1은 PHP보다 훨씬 불편한 언어 였습니다.

그러던 중에 대대적인 마케팅과 함께.. 닷넷 2.0 발표가 있었습니다.
정말이지 신기할 정도로 '불편해!' 라고 생각 했던 많은 부분들이 개선 됐더군요..!!

특히 제겐 ASPX파일을 ASPX.CS파일에서 선언해 줘야 한다는건 역시 닷넷은 쓸만한게 못돼!! 라고 생각될만큼 불편한 부분이었는데.. 2.0에서는 Class Patial이라는 방식으로 시원하게 해결 했더군요.
마스터 페이지도 정말 사용자의 귀를 많이 기울인 부분이라고 생각합니다.
(그래도 역시 이부분은 PHP의 Smaty 같은 템플릿 사용 보다는 못한거 같습니다. ㅎㅎ)

여하간 점점 .NET을 사용하다보니 PHP보다는 .NET이 더 좋다!! 라고 느껴지는 겁니다.
허.. 이거 왜 이렇지?!
라고 곰곰히 생각해 보니..

아마도 그건 VS.net이라는 IDE존재 때문이 아닌가 합니다.
PHP로 제작을 마치고 한 달쯤 뒤에 보면..
$foo <- 이 변수 녀석이 도데체 어디서 출현한 녀석인지.. 도무지 찾을 길이 없습니다.
EditPlus등에서 전체 파일에서 찾기 라던지.. include등을 일일이 따라가면서 찾는 수 밖에는요..
특히나 나름데로의 룰을 벗어나.. 남의 소스를 분석이라도 해야 될 판이면..
이거.. 스트레스 죠..

하지만 VS에서는 변수명에 대고 오른쪽 클릭을 한 다음 Go To Definition 만 클릭해주면 변수 선언부로 사샥~ 하고는 이동 합니다.
그게 상속을 타고 타고 타고~ 내려온 다른 행성에(파일에) 정의 되어 있더라도 말이죠.

저는 하나의 프로그램이 만들어 지면.. 유지 보수가 그 소프트웨어의 완성으로 가는 길의 반이라고 생각합니다.
그 아무리 잘 만들었다고 자기 만족을 느껴 봐도 클라이언트의 심사대에 오르면 어딘가 모자란 녀석이 되고 말고..

누군가의 말처럼, 클라이언트 - 남자, 여자 .. 그리고 또 한 부류 - 라는 사람들은 애플리케이션을 다 만들고 나서야 자기가 원하는게 뭔지,
기획 단계에서 모자랐던 부분이 무엇이었는지 아는 부류 이니까요.
그런 의미에서 Debug등의 유지 보수는 분명 VS의 장점이라고 생각합니다.

하지만 여태까지 PHP로 홈페이지를 제작하면서 EidtPlus와 DreamWearver만 써오다가
얼마전 우연히 Zend Studio를 써보니.. - 네.. 어둠의 경로를 통했습니다.. ㅠ_ ㅠ - 못지 않게 유지보수에 많은 기능을 보유하고 있더군요.
include파일 바로 찾아가기도 있고.. 또 Debugging 기능까지..
PHP프로그래머에게 무척 고무적인 툴이라 생각됩니다.

여하간 닷넷2.0을 써오면서 점점 .NET이 좋아지긴 하지만
도저히 이해 해줄 수 없는 부분은..
닷넷으로 제대로 사이트를 하나 돌리려면 다른 M$제품군과 마찬가지로
돈 삽질을 해야 한다는 거죠.
일단 서버 Window제품군을 갖춰야 하고..
DB도 최고의 궁합을 위해.. MsSQL로.. >ㅁ

비싸.. 비싸.. 비싸다곳..!!!
역시.. 이딴건 버리고 Java를 해야해... 라고 맘 먹어 보지만..
역시나 닷넷의 스마트 클라이언트는 모든 언어를 통틀어 매력적인 부분 입니다.
플래쉬처럼 브라우져에 묶여 있지도 않고.. 자바처럼 느리지도 않죠..

그러던 와중에 만난 것이 바로 MONO 입니다.
역시.. OSS사람들 대단합니다. ^ㅁ^
그닥 눈에 띄는 IDE는 없지만 별로 신경쓰이지 않더군요.
VS로 개발해서 MONO로 컴파일 해주자~ 라는 어이없는 발생에 기인하긴 합니다만.. ㅎㅎㅎ

댓글

1day1의 이미지

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

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

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

F/OSS 가 함께하길..

shockyhan의 이미지

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

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

===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================

PSG-01의 이미지

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

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

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

-----------------------------------
Playlist :

맨발의 이미지

업무상 기존에 ASP로 제작된걸 수정해야 할 때마다
직업의 회의를 느낍니다.

도데체 어떤 생각으로 만든 언어인지.. >ㅁ<);

--------------------------------------------
:: 누구보다 빠르게 남들과는 다르게

codebank의 이미지

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

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

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

------------------------------
좋은 하루 되세요.

maddie의 이미지

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

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

힘없는자의 슬픔

힘없는자의 슬픔

맨발의 이미지

모노는 M$가 .NET은 완죤 공개다!
우리는 .NET에 대한 라이센스를 가지지 않겠다!!
그리고 그것은 어디서든 구동된다!!!!

...라고 해놓고는 Windows 용으로'만' 만들자..
Ximian에서(지금은 Novel에 합병됐다네요..)
'그럼 우리가 만들어 주꾸마!!' 라며 만들어낸 Framework 입니다.
기본적으로 .NET을 골격으로 하고 있습니다만..
조금 차이는 있습니다..

요즘 서서히 알려지기 시작했으며.. 이번에 나오는 Fedora에는 기본 탑재를 한다는 군요..
Novel에서 나오는 LINUX 배포판인 SuSE에는 기본 탑재 되어 있습니다.

M$에서는 C#과 비베를 주요언어로 밀고 있습니다만,
모노쪽에는 GTK#이라는 언어를 밀어주는 추세 입니ㄷㅏ

--------------------------------------------
:: 누구보다 빠르게 남들과는 다르게

익명 사용자의 이미지

GTK# 은 언어가 아닙니다. MONO 에서 역시 주요 언어는 C# 입니다. 하지만 닷넷의 GUI 를 리눅스상에서 구현할 방법이 마땅치 않으므로(와인 기반으로 winform 을 구현하기는 했지만 에뮬레이션이라 좀 그렇지요...) GUI 를 위해서 gtk+ 의 C# 바인딩을 만든게 GTK# 입니다.

개인적으로는 기술적인 면에서는 MONO 에 관심이 있지만 아무래도 불안합니다. MS의 닷넷 구현이 오픈 소스는 아니더라도 최소한 자바의 JCP 만큼이라도 사용자 커뮤니티의 의지가 개입될 수 있도록 되지 않는 한 모노가 현업은 물론 오픈 소스 커뮤니티에서 널리 쓰이기는 힘들거라고 생각합니다.

PHP는 아무래도 프로그램 짜기가 불편합니다. PHP5 는 아직 사용해보지 않았지만 서로 다른 request 사이에 객체를 공유할 방법이 serialization 밖에 없기때문에 웹 프로그램이 간단히 디비에 쿼리날리고 결과를 예쁘게 보여주는 역할만 하는 경우가 아니라면 아무래도 적합치 않다고 생각합니다. .NET 이나 자바처럼 미들티어(?)의 역할을 하기에는 많이 부족하지요.

이한길의 이미지

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

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

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

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

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

pok의 이미지

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

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

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

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

_Anonymous의 이미지

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

creativeidler의 이미지

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

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

맨발의 이미지

삭제

--------------------------------------------
:: 누구보다 빠르게 남들과는 다르게

fender의 이미지

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

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

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

cleol의 이미지

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

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

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

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

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

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

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

행복한고니의 이미지

방법은 있습니다.

1. 쿼리결과를 가져온다.
2. shared memory function 을 이용해서 결과를 저장한다.(객체라면 serialize)
3-1. 결과에 대한 요청이 있을 경우 쿼리를 날리지 않고 캐시를 사용해 응답한다.
3-2. 업데이트하는 요청이 있을 경우 디비업데이트후 캐시를 재생성한다.

문제는 할 수 있다/없다가 아니라 어디에 적절하느냐..의 차이라고 생각합니다.
사실... 어느 정도의 시간이 흐르고 나면 "가능한" 방법들은 어떻게든 생기기 마련이죠. ^^;;

__________________________________
나는 세상에서 가장 중요한 사람이다.

Kurt77의 이미지

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

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

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

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

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

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

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

Kurt77의 이미지

serialize도 있군요.

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

fender의 이미지

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

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

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

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

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

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

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

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

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

Quote:
eAccelerator is a free open-source PHP accelerator, optimizer, encoder and dynamic content cache.

http://eaccelerator.net/
creativeidler의 이미지

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

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

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

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

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

creativeidler의 이미지

구체적인 이야기에 대해서도 좀 언급하면, 위에 캐시를 언급하면서 퍼포먼스가 높을 가능성이 있다는 말씀을 하신 분이 있는데 가능성은 그럴지 모르나 현실은 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만 활용되는 것을 봐도 화려한 기술이 실제 가치로 연결되지 못하면 의미 없다는 사실을 잘 말해주는 것이라고 봅니다.

fender의 이미지

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

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

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

Kurt77의 이미지

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

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

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

creativeidler의 이미지

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

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

fender의 이미지

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

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

creativeidler의 이미지

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") ?>

꼭 커스텀 태그로 갖다 붙여야 컴포넌트 기술인 것은 아니지 않습니까. 커스텀 태그 자체는 컴포넌트 기술이라기보다 scriptlet 대신 태그를 쓰게 해주겠다는 것 뿐입니다. Ajax 라이브러리도 아마 PHP가 더 많을껄요.

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

creativeidler의 이미지

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

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_comparison.pdf

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

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

fender의 이미지

일반적으로 통용되는 '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, 위키, 갤러리 등등...

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

fender의 이미지

음... 코드를 고치셨군요 :) 물론 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.html

위에서 이야기한 '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, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, 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도 나름대로 특성이 있고 충분히 훌륭한 언어들입니다. 잘 아실텐데들;;;

creativeidler의 이미지

음... 전 사실 자바 하다가 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가 발전하지 않고 있는 것은 분명하지만 가장 널리 쓰이는 기술이란 점 또한 부인할 수 없는 사실입니다.

marzok의 이미지

자바(spring)를 쓰면서 가장 귀찮은 것중 하나가 간단한 페이지 하나 만드는데 너무 많은 설정을 해야 한다는거더군요.
그래서 간단한 페이지를 만들 경우 jsp + jstl을 사용합니다.
xml, sql tag를 이용하면 아마 php와 용법이 차이가 별로 없을겁니다.

이와 비슷한 이유로 파이썬 대신 groovy를 사용합니다. 오라클 mysql을 사용 할 때 드라이버 설정 이거 무지 귀찮거든요.
그런데 groovy를 사용하면 자바 처럼 쉽게 db, xml사용을 할수있어서...(굴비도 자바이긴하지만)

spring framework을 무지 좋아라하고 많이 사용하지만 간단하게 사용할 만한 건 못되는거 같습니다.
조그만 운영툴 만들때는 jsp+jstl+jquery를 주로 쓰는데 이마저도 grails로 갈아타려 하고있네요.

fender의 이미지

Quote:
커스텀 태그로 어떤 기능을 구현하는 것은 콤포넌트에 기반한 개발 방법입니다. 어떤 기능의 콤포넌트가 언어별로 존재한다면 인터페이스 역시 거의 동일할 것이고 가져다 쓰는 방법만 언어마다 틀릴텐데요. PHP에서 그런것이 되지 말라는 법은 없습니다

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

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

물론 잘 알고 있습니다 :) 다시 강조하지만 저는 J2EE가 PHP보다 무조건 우월하다고 주장하는 것도 아니고 실제로 그렇게 생각하지도 않습니다. 다만 '쉽고 빠르게'라는 기준이 프레임워크나 언어를 판단하는 척도의 전부가 아니고, J2EE의 경우 특히 그 이외의 부분에서 많은 장점을 가지고 있다는 걸 이야기하고 싶을 뿐입니다.

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

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

zelon의 이미지

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

개발 언어를 떠나서 개발환경(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

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

설지운 (랩퍼 투혼)@Google의 이미지

좋은 서비스 개발해주셔서 감사합니당! ^-^

creativeidler의 이미지

논점이 아주 좁혀졌군요.

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

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

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

fender의 이미지

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/index.html

인터페이스가 없다고 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, 위키, 갤러리 등등...

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

소타의 이미지

DB추상화는 http://pear.php.net/manual/en/package.database.db.php 여기 PEAR에 포함된 놈을 보시면 되겠습니다.
PEAR에 포함된 다른 패키지들도 있습니다.
http://pear.php.net/manual/en/packages.php
PEAR는 PHP에 기본으로 포함됩니다. 이 외에도 DB추상화라면 ADODB, phplib, dbx등이 있습니다.

PHP가 함수들과 절차형 인터프리터만 제공하던 시기는 꽤 오래됐죠;
IDE도 zend studio라고 꽤 좋은 놈(상용 -.-)이 있습니다. 보통의 다른 언어의 IDE와 더 나을것 없지만 절대 뒤지지 않는 놈입니다..

PHP도 객체지향 언어들의 특성을 가지고 있습니다. 특히 PHP5의 경우는 더욱 그렇습니다. PHP의 그것과 자바의 그것의 차이를 말로 명확히 당장 썰 풀긴 힘들지만;; 좀 더 융통성 있는건 PHP쪽이고 견고하게 느껴지는건 자바쪽 이었습니다.

에.. 여튼 요지는 어느쪽이 좋다 나쁘다가 아니라 말씀하신 특성들이 약간씩 다르지만 자바만의 특성은 아니라는 것 입니다. 루비나 파이썬도 있고요..

이건 꼭 mysql vs oracle/pgsql 같은 논쟁 같습니다. 어떤 상황에 있어 필요한 도구를 선택해야 하는데 이 도구는 맥가이버횽아 같은 거니까 어떤 상황이든 OK는 좀;; 자바는 어떤곳에 알맞다. PHP는 어떤곳에 더 알맞다 이런 예들이 나와서 자신이 생각하는 특화된 영역에 대해 얘기해보는게 나을것 같습니다.
음.. 그 영역이 중복되서 이렇게 흘러온건가요?;;;

fender의 이미지

음... 서로 포스팅 하는 시간이 묘하게 어긋낫네요 :) 먼저 올리신 글에 대한 답을 더 늦게 쓰게 되었습니다...

Quote:
자바에서는 GUI 빌더 만드려면 자바빈즈 써야 하지만 파이썬은 그런 규약 없이도 GUI 빌더를 만들 수 있죠. 없어도 손해보지 않는다면 없는 것이 더 좋은 것 아니겠습니까.

손해보지 않는 다면 없는 것이 좋다에는 동의합니다. 다만 제 입장은 JSF 같은 컴포넌트 모델이나 EJB 등이 '없어도 손해보지 않는' 영역에 속하는 게 아니라는 것 뿐입니다. 우선 EJB는 도메인이 다르니 그렇다 쳐도 솔직히 제 기술적 지식으로는 어떻게 어떠한 규약도 없이 '임의의 컴포넌트'를 위에 링크한 데모와 같이 위지윅 하게 활용할 수 있는 지 모르겠습니다.

자바빈즈로 데탑어플을 만들 때 GUI 디자이너를 말씀하셨는데, 실제 자바빈즈 스펙을 보셨으면 아시겠지만 디자이너에서 컴포넌트 정보를 가져오고 커스터마이즈하는 데 필요한 최소한의 제약을 제외하고 군더더기랄 게 많지 않습니다.

그 정도의 제약이 아니라면 어떻게 임의의 써드 파티가 만든 컴포넌트에 어떤 속성과 이벤트가 있는지 알고 또 디자인 타임/런타임 behavior를 구분하고 또 어떤 커스터마이저를 지원하는 지 알아올 수 있나요? 그런 제약은 '자바이기 때문에' 필요한 제약이라고 생각하지 않습니다.

덧말 : 음... 이건 정말 노파심에서 확인하는 것이지만 제가 이제까지 말한 '컴포넌트 모델'이 자바 빈즈를 말하는 게 아니라는 건 알고 계신 거지요? Java Server Faces나 .NET의 웹폼즈와 같은 웹에서 쓸 수 있는 이벤트 기반의 컴포넌트 모델 말하는 겁니다.

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

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

creativeidler의 이미지

음. 제 글을 잘 안 읽고 있다는 느낌을 거듭 받습니다. 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도 충분히 중복을 제거한 것이 아니다"라는 주장을 입증하기엔 충분하다고 봅니다.

fender의 이미지

아뇨, 글을 안읽은 게 아닙니다; 그래서 '이미 보셨는 지 모르겠지만'이라고 전제를 했습니다만... 굳이 그 링크를 다시 단 이유는 creativeidler 님께서 JSC가 단순히 '멋진 툴'이다라고 만 생각하실 뿐 그런 툴 지원을 가능하게 하는 컴포넌트 모델에 까지 확장해서 생각하시지 못하는 것 같아서 입니다.

어쨌든 creativeidler님의 주장은 PHP는 언어 자체가 자바에 비해 다이나믹 하기 때문에 JSF 같은 스펙이 없어도 위의 데모 같은 컴포넌트 재활용이 가능하다는 것으로 이해했는데 맞나요? 어떤 약속도 없이 임의의 PHP 클래스 하나 가지고 어떻게 그 '컴포넌트'가 어떤 커스터마이즈할 수 있는 속성이 있고 또 그걸 어떻게 기존 코드와 자동으로 바인딩 하시겠다는 건지, 또 한 컴포넌트에 적용될 수 있는 validator나 converter 등을 다른 '컴포넌트'에 수정없이 똑같이 적용할 수 있다는 건지 모르겠습니다.

그리고 설사 PHP에 어떤 마법 같은 기능이 있어서 그런 문제가 다 해결될 수 있다고 해도 지금 당장 IDE에서 위지위그로 가져다가 붙여 쓸 수 있는 컴포넌트 컬렉션은 없는 게 사실 아닌가요? 또 creativeidler 님의 주장대로 PHP 개발자는 그런 것 쯤 컴포넌트 없어도 쉽게 만들어 쓸 수 있다고 해도, 정작 중요하게 생각하시는 '쉽고 빠르게'측면에선 분명 다운받아 바로 IDE에 넣고 위지위그로 가져다 쓸 수 있는 게 더 쉬운 거 아닌가요? 이건 언급되었던 선언적 트랜잭션이니 보안이니 모두 해당되는 이야기입니다. PHP가 얼마나 자바보다 생산성이 높고 유지보수가 편한지(?) 모르지만 기본으로 제공하는 것보다 직접 만들어 쓰는 게 더 쉬울 수는 없는 거 아닌가요?

대부분의 개발자가 EJB를 사용하지 않는 건, 만약 EJB를 쓰지 않고 해당 프로젝트를 성공적으로 수행할 수 있었다면 애초에 EJB가 필요한 도메인이 아니었다는 뜻입니다. 물론 EJB 3.0 부터 상당히 발상전환이 필요할 만큼 간편해져서 심지어 SEAM 같은 프레임워크에서는 사소한 이벤트 핸들러 조차 세션빈으로 구현할 것을 권장할 정도지만 2.x까지 기준으로는 본격적인 분산환경이 아니라면 애초에 EJB를 도입한 것 자체가 잘못입니다. 사실 SI에서 주로 쓰는 자바의 특성상 이력서에 채워 넣기 위해, 혹은 큰 업체들이 지원하는 WAS에 EJB를 제대로 이해도 못하면서 남용했던 것이 사실입니다. 하지만 이 걸 모두 EJB 자체의 결함이라고 이야기할 수는 없다고 봅니다.

그리고 creativeidler님 개인적 경험에 비춰보아 J2EE 플랫폼이 제공하는 것과 같은 기능은 PHP로 대부분 별로 공수 안들이고 만들어 쓸 수 있는데, 반대로 기존 프레임워크 없이 JSP/자바로 그런 기능을 만들어 쓰는 건 훨씬 번거롭고 복잡하다라고 생각하신다면 저는 전혀 동의하지 않습니다. 어쨌든 객관적으로 논증할 수 있는 근거가 단지 개인적 경험이라면 이 문제에 대해서도 역시 입장 차이를 확인 하는 선에서 이야기를 매듭 지어야 할 것 같군요.

마지막으로 자바에서 인터페이스/구현의 분리에 대해, 향후에라도 구현이 여럿 나올 수 있는 경우라면 당연히 인터페이스를 사이에 두는 것이 정상적이라는 것은 아실 것입니다. 물론 절대로 구현이 하나 이상 안나오는 경우라면 그냥 단일 클래스로 해결할 수 도 있습니다. 하지만 단순 유틸 클래스가 아닌 다음에야, 보통 EJB로 구현하는 비즈니스 위임 클래스의 경우 그 정도의 유연성을 고려하는 것은 상식이고 또 기본적으로 원격/로컬 구분 없이 사용 가능한 EJB의 성격상 서비스와 구현은 구분하는 것이 맞습니다.

이걸 'EJB를 쓰기 때문에 어쩔 수 없는 제약'이라고 해석하시는 것에 동의할 수 없는 것은, 설사 EJB를 안쓰더라도 만일 어떤 서비스 클래스를 원격/로컬에서 동일하게 사용할 수 있고 잠재적으로 다양한 프리젠테이션 계층 구현이 가능하다면 당연히 구분을 해줘야 하는 것이기 때문입니다.

그리고 다 떠나서, 잘 아시듯 인터페이스를 뽑는 것이 그렇게 복잡한 게 아닙니다. 더구나 IDE라도 쓰면 구현에 메소드 스텁 만들어 주는 것까지 자동으로 되는데 그걸 구조적 문제점이라고 생각하시는 건 확실히 지나친 과장입니다.

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

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

creativeidler의 이미지

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

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을 쓰지 않아서 분명 잃는 부분이 있겠지만 아직 그게 무엇인지 발견하지 못했다고. 때때로 가져다 쓰는 것이 정말 쉽고 빠른지 검토해 볼 일입니다.

creativeidler의 이미지

>마지막으로 자바에서 인터페이스/구현의 분리에 대해, 향후에라도 구현이 여럿 나올 수 있는 경우라면 당연히 인터페이스를 사이에 두는 것이 정상적이라는 것은 아실 것입니다. 물론 절대로 구현이 하나 이상 안나오는 경우라면 그냥 단일 클래스로 해결할 수 도 있습니다. 하지만 단순 유틸 클래스가 아닌 다음에야, 보통 EJB로 구현하는 비즈니스 위임 클래스의 경우 그 정도의 유연성을 고려하는 것은 상식이고 또 기본적으로 원격/로컬 구분 없이 사용 가능한 EJB의 성격상 서비스와 구현은 구분하는 것이 맞습니다.

이 부분은 다시 수정해서 추가하신 내용인 것 같아 따로 답글을 달겠습니다.

우선 전 여기 동의하지 않습니다. 일단 EJB의 경우 interface가 따로 존재하는 이유는 향후에 다른 구현이 나올 수 있기 때문이 결코 아니지 않습니까. 단지 서버 객체와 클라이언트 객체가 다르기 때문에 구분해주는 것 뿐입니다. 심지어 직접 implement하지도 않습니다.

게다가 향후에 다른 구현이 나올 수 있다는 것은 미래의 일입니다. 미래의 일 때문에 현재의 디자인에 orthogonality를 떨어뜨리는 것은 좋지 못한 일이라고 봅니다. 여기에 관해서는 XP의 철학을 소개하고 싶군요. http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork

XP의 철학은 "그런 일이 발생하면 그 때 변경한다"입니다. 앞서 fender님께서도 말씀하셨듯 미래에 유지보수 쉽게 만들려고 하면 현재가 필요 이상으로 복잡해지죠.

>이걸 'EJB를 쓰기 때문에 어쩔 수 없는 제약'이라고 해석하시는 것에 동의할 수 없는 것은, 설사 EJB를 안쓰더라도 만일 어떤 서비스 클래스를 원격/로컬에서 동일하게 사용할 수 있고 잠재적으로 다양한 프리젠테이션 계층 구현이 가능하다면 당연히 구분을 해줘야 하는 것이기 때문입니다.

이것도 사실이 아닙니다. 거듭 말씀드리지만 웹 서비스에선 이런 제약이 없으니까요.

>그리고 다 떠나서, 잘 아시듯 인터페이스를 뽑는 것이 그렇게 복잡한 게 아닙니다. 더구나 IDE라도 쓰면 구현에 메소드 스텁 만들어 주는 것까지 자동으로 되는데 그걸 구조적 문제점이라고 생각하시는 건 확실히 지나친 과장입니다.
이거 리팩토링 잘 안되는 걸로 알고 있는데 지금은 어떤지 모르겠군요. 빈 클래스가 interface를 직접 implement한 게 아니라 바로 리팩토링되지 않는 걸로 압니다만. 결국 메소드 이름 바뀌면 두 클래스는 물론이고 쓰는 곳마다 찾아다니면서 바꿔줘야하는 것 아니던가요?

fender의 이미지

정말 궁금해서 여쭤보는 것인데 제가 아무리 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 컨트롤을 하고 싶을 때 쓰는 라이브러리입니다. 개발하시는 사이트가 웹단과 서비스단 구분이 명확하지 않거나 도메인 객체 보안을 쓰지 않는 다면 별 필요가 없습니다.

Quote:
빈 클래스가 interface를 직접 implement한 게 아니라 바로 리팩토링되지 않는 걸로 압니다만. 결국 메소드 이름 바뀌면 두 클래스는 물론이고 쓰는 곳마다 찾아다니면서 바꿔줘야하는 것 아니던가요?

설마요;; EJB 3.0에선 그냥 implement 하면 끝입니다. 그래서 일반적 설계하고 동일하다고 한 것이구요. 그리고 저도 XP나 Agile은 모르는 바가 아닙니다만, 인터페이스하나 만드는 게 orthogonality까지 나올 문제가 아니라는 것 뿐입니다. 그리고 웹서비스는 같은 차원의 예가 아닌 것 같군요. 또 설사 EJB없는 원격호출로 충분한 도메인이면 원하면 자바에서도 EJB안쓰고 웹서비스 쓰면 그만 아닌가요?

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

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

creativeidler의 이미지

먼저 오해 하나를 짚고 넘어가면, 처음부터 끝까지 계속 fender님이 오해해서 제가 정정하고 있는 포인트가 있는데, fender님은 지금 제가 EJB와 JSF를 비롯한 모든 자바 기술을 PHP의 관점에서 비판하고 있다고 생각하고 있으신 것 같습니다. 이번에 그 오해가 나타난 것은 다음입니다.

>자바에서도 EJB 안 쓰고 웹서비스 쓰면 그만 아닌가요?

전 자바가 PHP보다 나쁘다고 한 것이 아니라 "자바에 EJB를 비롯한 프레임웍이 있기 때문에 PHP보다 낫다"라는 주장에 반박을 하고 있는 것입니다. 제 입장에서는 자바의 많은 프레임웍이 PHP보다 낫다는 근거가 될 수는 없다는 사실만 입증하면 그만이고 굳이 PHP가 자바보다 낫다고 주장할 생각은 없습니다. 처음에 제가 끼어든 포인트부터 제 논지의 일관성을 살펴봐 주시기 바랍니다.

그러니 이 이야기는 제 입장에서는 반박할 필요가 없는 이야기입니다. 네, 쓰면 그만입니다. "EJB가 있으니까 자바가 더 나아"라고 말할 만한 거리가 안된다는 것만 동의를 하신다면 저야 더 할 말이 없는 거니까요.

말씀처럼 EJB의 무수한 장점에 비하면 작은 중복 하나, 별 거 아닐 수도 있습니다. 제가 말하고 싶은 것은 여전히 중복이 남아 있다는 것이지 그 중복 때문에 EJB 죄다 갖다 버려! 하자는 얘기는 아닙니다. 그게 중복이라는 사실 자체도 인정할 수 없으신가요? orthogonality가 "...까지"라는 말을 할 정도로 대단한 개념인 것도 아니고 그냥 duplication의 다른 표현 정도를 크게 벗어나지 않습니다. coupling이라고 하면 좀더 와닿을까요.

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

제가 말씀드린 것은 그런 부분이 아닙니다. 그런 것도 다 쉽게 가능합니다. 제가 단순화시킨다고 한 부분은 RBAC 부분이지 도메인 모델의 Access Control은 annotation으로 쉽게 지원하게 할 수 있습니다. 필터 하나 추가하는 건 또 뭐 어렵겠습니다. RBAC의 모델이 복잡해서 간소화시키는 것 뿐이죠. 말씀처럼 굳이 쓸 이유는 없는 것으로 보입니다.

>선언적 트랜잭션이나 보안 등이 크리티컬하게 작용하는 비즈니스는 존재하지 않는다고 생각하시는 건지 반문하고 싶습니다.
네, 존재하지 않습니다. 트랜잭션이 크리티칼하게 작용하는 비즈니스는 있습니다. 보안이 크리티칼한 비즈니스도 있습니다. 하지만 선언적 트랜잭션이나 선언적 보안이 크리티칼한 비즈니스는 없습니다.

그리고 자바빈즈 이야기. 네, 제가 잘못 이야기한 부분이 있는 것 같습니다. 이 부분을 반박하게 된 이유는 "PHP로는 그런 IDE를 만들 수 없다!"라는 주장에 반박하기 위함인데 하다보니 저도 잠시 착각한 것 같습니다. 네, 공통 API까지는 아니라도 최소한 네이밍 룰은 필요합니다. 어쨋든 그런 것만 정하면 PHP도 위지윅으로 컴포넌트를 추가하는 것이 가능하다는 것입니다.

스윙 예를 드셨으니 스윙을 생각해보시면 될 것입니다. 스윙 에디터에서 컴포넌트를 추가하면 코드에 객체가 추가되고 프로퍼티를 수정하면 필드 내용이 수정됩니다. 그런 식으로 동작하게 만드는 메커니즘은 자바빈즈의 introspection, 곧 리플렉션에서 오는 것이죠. 이 리플렉션이란 것이 PHP나 파이썬 등의 다이나믹 언어에서는 훨씬 쉽기 때문에 더 쉽게 만들 수 있다..이런 말을 하려던 것이었습니다.

그리고 사실 interface에 맞추면 사용가능하다는 게 왜 장점인가 하는 의문도 제기하고 싶습니다. JSF 인터페이스에 맞추면 JSF에서 사용가능한 것은 당연한 것 아닌가요? 오히려 JSF를 전혀 고려하지 않고 만든 컴포넌트를 JSF에서 자유롭게 컴포넌트로 사용할 수 있어야 무언가 장점이라고 말할 수 있는 것 같습니다만. 자바의 컴포넌트 모델이란 것도 해당 프레임웍 안에서만 재사용 가능한 것이지 프레임웍을 옮겨가버리면 아무리 비슷한 프레임웍이라도 소용 없지 않습니까? Struts에서 만든 Action 클래스들 WebWork로 바꾸면 죄다 뒤엎어야 합니다. 그래서 Action 클래스를 작게 만들려고 BO니 뭐니 만들려고들 하는 것이죠.

Dependency Injection이란 것도 프레임웍이 바뀌어도 POJO는 그대로 두고 XML만 새 프레임웍에 맞게 수정하면 된다지만 그건 클래스로 해도 마찬가지입니다. 어댑터 클래스만 새로 만들어주면 되는 거랑 같은 이야기죠. 결국 PHP에서도 같은 수준의 컴포넌트 기술은 가능하다는 것입니다.

제가 거듭 PHP가 자바에 비해 프레임웍이란 점에서 떨어진다고 할 수 없다고 주장하는 근저에는 PHP가 아니라 자바가 있습니다. 자바에서도 IoC 스타일의 프레임웍 없이 잘 추상화된 설계를 할 수 있기 때문에 언어 자체의 유연성이 더 높은 PHP에서도 당연히 가능할 것이라고 생각하는 것입니다. PHP에 대한 경험이 많지 않음에도 이렇게까지 PHP를 지지하는 이유는 거기에 있습니다.

fender님도 언어 자체가 PHP가 좀더 유연하고 편하다는 점을 부인하시진 않으실 것입니다. 그렇다면 문제는 이미 구현된 것이 어느 쪽이 많은가..인데 자바에는 IoC 방식의 프레임웍이 많은 대신 PHP에는 다른 방식의 라이브러리가 많다..라고 말하고 싶습니다.

creativeidler의 이미지

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

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

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

소타의 이미지

규약이 없어도 IDE에서 인터페이스 빌딩, 런타임 코딩이 자유롭고 fender님이 말씀하신 IDE의 특성을 다 가질 수 있습니다. 델파이가 그렇습니다. 물론 템플릿화 시키는 부분이 있지만 객체 자체가 어떤 표준이 있어야 한다거나 그렇지 않습니다.
왜 규약을 가져야만 IDE에서 그런 것들이 다 된다고 생각하시는지 모르겠습니다. PHP는 그런 IDE가 있는지 모르겠습니다. 전 뭘 만들어도 IDE종류를 잘 쓰지 않아서요. 아직 못 봤습니다. C로 만들때도 그렇고 자바할 때도 PHP할 때도 그냥 에디트 플러스랑 vim만 씁니다;;

IDE가 밷어내는 코드를 100% 그대로 사용해서(즉 콤포넌트들의 조합만으로) 완성할 수 있는 프로덕트는 거의 없습니다. 개발자가 커스터마이징 할 수 밖에 없는데 오히려 내용이 은닉된 콤포넌트가 발목을 잡을 때도 있습니다. 라이센스가 맞지 않는다거나 원하는 프로덕트를 위해 2% 부족하다거나; 이것저것 고르는 시간도 꽤 낭비됩니다.
끌어다 놓고 조합해서 프로토타입을 만든 후에 원하는 결과물로의 구체적인 다듬기가 생산성에 있어 좋다는 말씀은 저도 인정합니다. 하지만 이건 자바만의 특성이 아니라 PHP에는 그만의 방식인 code gallery라는 코드 템플릿 모음이 IDE에 들어가 있습니다. 이것은 온라인 커뮤니티와 자동으로 연결되고 커뮤니티를 통한 코드의 사용과 갱신등을 바로 할 수 있습니다.

자바와 PHP가 특성이 다른데 같은 방식의 IDE가 있어야 할까 싶네요. PHP는 컴포넌트들을 가져오는 것은 include 한 라인이면 되고 필요하다면 객체를 생성하고 사용하는 몇 줄 더 써주면 됩니다. 메모장으로도 되는 작업이 IDE가 굳이 필요할까요? PHP라는 언어가 가지는 생산성이 부각되는 부분은 그 다음부터라고 보시면 됩니다. IDE켜는동안 코딩을 몇 줄 더 할 수 있습니다;;

fender님께서 말씀하신 종류의 IDE는 인터페이스 빌딩과 런타임 코딩이 동시에 일어나는 경우입니다. 하지만 PHP는 처리결과를 XML/XHTML로 표시하거나 division에 맞게 html으로 표시만 하면 됩니다. 그 후에 또는 동시에 디자이너가 CSS나 템플릿 태그로 스타일링 하면 됩니다. PHP의 특성에 맞게 디비전 단위의 템플릿으로 동작하는 IDE는 PHP쪽에도 많습니다. 오히려 PHP의 특성에 잘 맞춘 것이죠. PHP쪽에도 그런 좋은 IDE가 있으면 좋겠다고 새삼 생각이 들긴 합니다만 그렇다고 부럽지는 않습니다 -.- IDE는 통합 개발환경인데 PHP에 환경을 맞춰야지 자바에 그런 기능이 있다고 따라할 필요는 없으니까요;

윈도우 계열 개발자 중에도 VS쓰지 않고 일반 편집기로 다 짜고 컴파일만 VS에서 제공하는 걸로 쓰는 사람도 많이 봤습니다. 좋은 IDE는 생산성을 올려줄 수도 있지만 거창한 IDE가 필요 없을만큼 가볍고 융통성 있는 언어들도 있습니다. PHP나 파이썬 처럼요. IDE는 그 언어의 프리미엄이지 그 언어의 우열을 나눌만한 요소는 안된다고 생각합니다.

그리고 규약이라는 것은 특정한 목적을 위해서 생겨나는 것 입니다. IDE를 개발하는 써드파티들을 위해 규약을 정할 필요가 있어야만 그런 규약이 생겨나겠지만 그런게 필요가 없는데 그런 규약을 누가 만들겠습니까. 필요할 때가 되면 자연히 생겨나 있는것이 이런 것 들이죠. 자바는 썬에서 전략적으로 그런 부분까지 생각해서 미리 잘 해놓은 케이스입니다.

맨발의 이미지

윗 분중 한 분의 말씀대로..

PHP vs .NET 이 PHP vs JAVA 로 주제가 싹~ 바뀌어 있군요..
@ㅁ@

게다가 언어의 특성보다는 IDE에 대한 얘기 였다고 생각하는데...
(쿨럭..)

어쨌든 저는 JAVA쪽으로 정말이지 '맛만' 본 상태라서
평소에 궁금하던 점들에 대한 얘기가 재밌네요.. ㅎㅎ :)

--------------------------------------------
:: 누구보다 빠르게 남들과는 다르게

fender의 이미지

논지를 잘 이해 못하겠군요. 처음부터 제 입장은 J2EE와 PHP는 주력하는 분야가 다르고 특히 J2EE의 경우 수 많은 프레임워크와 라이브러리가 산재해 있는 건 J2EE가 널리 쓰이는 분야에서 나름의 장점이 될 수 있다는 것입니다. 그런데 creativeidler님께서는 계속해서 '쉽고 빠르게'란 관점에서 PHP에서도 그런 프레임워크나 라이브러리 없이도 비슷한 걸 다 만들어 쓸 수 있기 때문에 그 부분의 장점은 존재하지 않는다고 주장하고 계신 걸로 이해합니다. 아닌가요?

선언적 보안, 트랜잭션이 필요한 비즈니스 영역을 부정하신다면 말을 바꿔 보겠습니다. 보안이나 트랜잭션이 크리티컬한 분야는 인정을 하셨는데, 그렇다면 그걸 선언적으로 하지 않고 프로그램적으로 했을 때 훨씬 복잡해 진다는 것도 부정하시겠습니까? 이해가 가지 않는 것은 인터페이스 하나 추가 되는 게 '중복'이라고 큰 결함 같이 생각을 하시면서 선언적인 처리를 프로그램 코드로 대신했을 때 증가하는 코드양과 복잡성은 애써 무시를 하시는 것 같군요.

그리고 프레임워크는 말 뜻 그래도 정해진 '틀'입니다. 즉, 핵심은 해당 프레임워크에서 제시하는 방법을 사용해서 개발하면 해당 프레임워크가 지향하는 구조의 개발을 보다 적은 노력으로 할 수 있다는 것입니다. 초기에 스트러츠 같은 MVC 프레임워크들이 쏟아져 나온 것도 MVC라는 디자인 패턴을 최소의 노력으로 구현하려고 있는 것입니다. 또 설계에 그리 능숙하지 않은 개발자도 따라하기 같은 걸 보고 그닥 나쁘지 않은 best practice를 구현할 수 있다는 장점도 있습니다.

그런데 creativeidler님께서는 프레임워크의 장점은 마치 그런 '틀'이 정한대로 따라하는 것인 데 틀대로 만들면 틀에서 동작하는 게 당연하다는 말로 이러한 장점을 부정하시고 계십니다. 그리고 기 개발된 어플리케이션의 프레임워크를 바꾸는 결코 일반적이지 않은 상황을 가정해서 프레임워크를 비판하고 또 공수나 최종 결과물에 관계 없이 프레임워크 사용 안해도 결과가 나온다면 마치 프레임워크의 존재 의미가 없는 것 같은 말씀을 하시는 데 저로서는 별로 납득이 안가는 주장입니다.

그런 논리라면 VS.NET에서 작성한 프로그램은 리눅스에서 안도니까 별 소용이 없고 루비온 레일즈도 어차피 ROR이 정한 컨벤션에 맞춰서 개발하면 그대로 되는 거니까 당연한 거고, ROR로 만들 수 있는 건 PHP로도 AR따위 안배우고 다 할 수 있으니까 별 필요가 없다는 주장도 성립할 수 있는 거 아닌가요?

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

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

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

fender의 이미지

소타님께 :

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

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

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

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

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

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

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

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

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

소타의 이미지

넵. 잘 알겠습니다 :)
오해하는 것은 아닙니다. 자바라는 언어의 장점에 대해서는 잘 알고 있습니다. 다만 제가 경험이 한정적이라 그런 프레임웍이나 IDE를 아직 써 보지는 못 했습니다;; UI쪽까지 나갈일이 적어서 -.-
PHP에도 그런 방식의 IDE가 있었으면 좋겠네요; 필요해지면 누군가 만들고 있던데 ㅋ;

creativeidler의 이미지

거듭 말씀드리지만 전 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에서도 비슷한 논쟁이 있었고 거기서 이어가는 것도 나쁘지 않을 것입니다.

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

앞에서 PHP의 DB 추상화 얘기가 나왔는데 PHP 확장으로 아예 이걸 지원하려고 하는 것 같더군요. (PHP5부터는 기본 포함인 것으로 보입니다.)
http://kr.php.net/manual/en/ref.pdo.php

다음은 위 URL에서 가져온 예제 코드입니다.
<?php
try {
$dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
foreach ($dbh->query('SELECT * from FOO') as $row) {
print_r($row);
}
$dbh = null;
} catch (PDOException $e) {
print "Error!: " . $e->getMessage() . "
";
die();
}
?>
PHP 5부터 들어간 반복자(Iterator)나 예외(Exception)을 잘 활용할 수 있겠군요. :)

fender의 이미지

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

Quote:
자바 프레임웍의 90% 이상이 이미 PHP에도 다른 방식으로 구현되어 있지만 10% 정도는 없다, 대신 10% 정도는 자바에서 들여야 하는 노력보다 절반 이하의 노력으로 만들 수 있다.

creativeidler님께서는 이미 언어적으로 PHP가 자바보다 훨씬 유연하고 생산성도 높다고 주장을 하셨고, 유지보수도 자바가 나을게 없다고 하셨으며, 퍼포먼스에 대해서도 PHP가 훨씬 낫다는 입장이었습니다. 그리고 위의 인용에서 프레임워크나 라이브러리도 사실상 '자바로 할 수 있는 건 PHP로 다 할 수 있다'라고 말씀하시는 게 아닌지요?

그럼 도대체 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, 위키, 갤러리 등등...

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

creativeidler의 이미지

구체적인 이야기부터 하면...

말씀하신 예, 아주 간단합니다. 메쏘드 위에 @Role(권한명)이라고 붙이는 대신에 메쏘드 첫 머리에 assertRole(권한명)이라고 쓰면 됩니다. 왜 PHP는 로직을 죄다 매번 copy&paste로 갖다 붙여야 한다고 생각하시나요? 이 차이점에 대해 많은 토론을 접했지만 그 누구도 선언적 방식이 왜 나은지 제대로 설명하지 못했습니다. 저는 그래도 선언적 방식이 장점이 있는 부분이 있다고 보긴 하지만 말입니다.

>말씀 드렸지만 서비스에 보안을 적용하는데 호출자가 직접 '나는 관리자다'라고 말하는 건 제대로된 보안이 아니라고 봅니다만...

이렇게 말씀하셨는데, '나는 관리자다'라고 말할 필요는 없지만 내가 누군지 identification은 밝혀야 하죠. 그러면 권한 모듈이 그 identification으로 권한 정보를 검색해서 어떤 권한이 있는지를 판단해서 실행할 건지 말건지 처리하는 것이구요. 이런 게 가능하지 못할 이유가 뭐가 있겠습니까.

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

이런 말씀을 하셨는데... 전 MVC를 채택하지 않는 경우랑 비교한 적은 없습니다. MVC에 대해서는 한 마디도 안했는 걸요. 그러니까 제가 자꾸 확대해석이라고 하는 것 아니겠습니까. 허수아비를 세워놓고 두들겨 패면 그 허수하비는 넘어지겠지만 전 안 넘어집니다. 전 오히려 Struts 없이 MVC를 하는 경우를 염두에 두고 비교한 것입니다. 왜 Struts를 안 쓰고 그냥 서블릿을 쓰는 것을 MVC도 안 쓴다고 생각하셨나요?

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

이렇게 말씀하셨는데...
글쎄요. 어느 언어 하나가 다른 것보다 낫다고 말할 수 있으려면 정말 종합적인 비교가 이루어져야 합니다. 제가 이번 쓰레드에서 비교했던 부분은 성능, 생산성(유지보수성은 생산성과 별개의 개념이 아니라고 주장한 바 있습니다. 그리고 이 생산성은 언어 자체, 곧 문법과 기본 API만을 고려한 생산성입니다), 지원 라이브러리 세 가지입니다. 이것으로 어느 언어가 더 낫다고 말하기는 충분치 않다고 봅니다. 그럼 뭐가 더 필요하냐.

그 점에 대해서는 제가 생각하는 자바의 비교우위를 들면 좋을 것 같습니다. 가장 자바가 비교 우위를 가지는 점은 사용자가 많다는 것입니다. 때문에 접할 수 있는 정보의 양이 방대하고 보다 중요한 것은 좋은 레퍼런스가 많다는 것입니다. PHP는 오픈소스의 세계에서는 자바보다 높은 영향력을 보이고 있지만 고급 레퍼런스라고 할 만한 것이 드뭅니다. 반면 자바는 여러 가지 패턴에서(GoF 뿐 아니라) 고급 레퍼런스가 많이 있습니다. 이 점이 현실적으로 개발자의 역량에 큰 영향을 주고 있습니다. 단순히 지원 라이브러리만 놓고 보면 PHP에도 웬만한 거 다 있지만 괌벙위한 infra로 생각하면 자바가 절대 우세입니다.

그리고 자바는 클라이언트에서도 꽤 폭넓게 사용됩니다. 서버 자체를 개발하는데도 사용됩니다. PHP가 웹 바깥으로 나가면 거의 쓰이지 않는 점을 고려하면 큰 차이죠. 또한 이것은 개발자가 애플리케이션의 영역이 바뀔 때마다 언어를 바꿀 필요가 없다는 것을 의미하기도 합니다. 사실 웹 애플리케이션을 개발하는 업체도 어드민 같은 걸 만들 때는 스윙으로 만들기도 하고 자신을 위한 자동화 툴은 또 커맨드라인으로 만들고 하는 일이 많죠.

이 외에도 패키지 개념, 클래스패스 개념은 초기 학습자들이 조금 어려움을 겪긴 하지만 다른 언어의 유사 개념보다 강력하고 편리하다고 보고 있습니다. 그리고 자바엔 이클립스가 있죠! 제가 IDE 매니아라 온갖 IDE 다 써봤지만 자바 계열의 IDE가 가장 품질이 높은 것 같습니다. 그 외에도 작은 이유들은 많지만 사실 infra의 차이에 비하면 크게 중요한 차이는 아니라고 봅니다.

그래서 PHP가 언어 자체도 좀더 유연하고 라이브러리도 있을 꺼 다 있다고 봄에도 불구하고 자바보다 낫다고는 말하지 않는 것입니다.

그래도 아마 그런 생각을 하실 것입니다. "자바의 장점이 고작 저거 밖에 안돼?" 거기까지는 제가 무어라 할 입장이 아니라 더 말씀 못 드리겠습니다만, 어쨋든 이 정도만 해도 제가 PHP가 Java보다 우월하다고 주장하는 것이 아니라는 점은 납득하실 수 있을 것입니다.

한 언어가 다른 언어보다 나은가 아닌가를 말한다는 것이 부질 없는 짜장면 짬뽕 논쟁과는 분명히 다릅니다. 비즈니스의 세계는 결국 선택을 해야하기 때문에 어느 것이 더 나은가는 분명 중요하고 가치 있는 논쟁이죠. 하지만 어느 한 쪽의 손을 들어주려면 굉장히 광범위한 차원의 비교가 이루어져야 합니다. 전 그렇게까지 이번 쓰레드를 확대시키고 싶은 생각은 없습니다. 그래서 그저 "프레임웍 때문에 자바 or .NET 우세"라는 주장만 충분히 반박할 수 있으면 만족입니다.

fender의 이미지

Quote:
이렇게 말씀하셨는데, '나는 관리자다'라고 말할 필요는 없지만 내가 누군지 identification은 밝혀야 하죠. 그러면 권한 모듈이 그 identification으로 권한 정보를 검색해서 어떤 권한이 있는지를 판단해서 실행할 건지 말건지 처리하는 것이구요. 이런 게 가능하지 못할 이유가 뭐가 있겠습니까.

위에서 잠깐 언급했지만 플랫폼 차원의 보안 서비스는 당연히 호출의 컨텍스트를 지원합니다. 당연히 identification도 호출자가 넘기는 게 아닙니다. 설사 말씀 하신 것처럼 'assertRole'이란 펑션을 만들어서 모든 펑션에 다 붙인다고 가정해도 그럼 모든 펑션 마다 호출자의 id를 넘겨야 합니다. 이는 자바의 플랫폼 보안을 사용하는 것에 비해 코드가 더 지저분해질 뿐 아니라 기본적으로 제대로된 보안모델이라고 할 수 없습니다.

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

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

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

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

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

creativeidler의 이미지

컨텍스트란 것도 결국 사용자가 가진 정보를 다른 방식으로 넘기는 것에 불과합니다. 컨텍스트든 뭐든 직접이든 간접이든 사용자가 identification을 주지 않고 인증하는 것은 불가능합니다. 구체적으로 생각을 해보세요. 웹에서라면 쿠키에 인증 정보가 있든 사용자가 패스워드를 입력하든 해야 합니다. 그런 정보들이 컨텍스트라는 운반 수단을 통해서 전달될 수는 있지만 전달되지 않는 것은 아니죠. 여전히 방법의 차이일 뿐 보안의 근본 개념과는 무관합니다.

거듭 보안 정보를 넘기지 않는다는 말씀을 강조하시는데 그렇다고 로그인도 안하고 쿠키도 없는 사용자가 클릭하는데 알아서 귀신같이 누군지 알아낼 수는 없지 않겠습니까. 어찌되었건 인증 정보가 필요합니다.

이 부분은 구체적인 사례로 이야기하면 훨씬 쉽게 다가올 것 같습니다.

스트러츠 안 쓰고 그냥 서블릿 쓰면 web.xml에 서블릿 등록하고 서블릿 만들면 끝입니다. struts-config.xml도 필요 없고 라이브러리 카피도 필요 없습니다. execute에서 ActionForward를 리턴하는 대신 포워드할 대상 페이지를 써주고 직접 포워드시키면 땡입니다. 포워드 시키는 게 두 줄이라서 귀찮다면 유틸리티 클래스로 간단히 줄이면 되는 문제죠. 서블릿의 service와 액션의 execute, web.xml의 servlet-mapping과 struts-config.xml의 action-mapping, 이렇게 대응시켜보면 제가 무슨 말을 하고 있는지 아실 수 있을 것입니다. 결국 모델과 뷰는 변하지 않고 컨트롤러만 action에서 servlet으로 바뀌는 것입니다. LoC가 줄고 건드려야할 파일도 줄고 성능도 빨라지는 것은 당연한 일이죠.

물론 struts를 포기함으로써 무언가 잃는 것이 있을 것입니다. 하지만 전 아직 그게 뭔지 발견하지 못했습니다. ^^

1day1의 이미지

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

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

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

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

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

F/OSS 가 함께하길..

fender의 이미지

J2EE 쪽의 보안 기능을 써보시지 않은 것 같군요. 자바의 보안 '플랫폼'의 핵심은 그런 컨텍스트가 '자동으로' 넘겨지고 플랫폼을 해킹하지 않는 한 아이덴티티를 바꾸거나 할 수 없습니다.

J2EE의 보안모델을 잘 모르시는 것 같아 자세히 설명 드리겠습니다. 서블릿을 어느 정도 써보셨다니 request에 getUserPrincipal이라는 메소드와 isUserInRole이라는 메소드가 있는 것을 알고 계실 것입니다. 혹시 그 메소드에서 넘어오는 아이덴티티가 어디에서 나오는 지 알고 계시나요? 그건 web.xml에 기술한 security-constraint에 따라 인증절차를 밟았을 때 플랫폼에서 자동으로 처리해 줍니다.

어쨌든, 서블릿 인증을 사용했을 때 인증된 사용자의 아이덴티티가 request에 자동으로 넘어오는 것 같이 만약 이러한 서블릿을 EJB가 프론트엔드로 쓰고 있다면 역시 자동적으로 EJB의 메소드 안에서 동일한 정보를 얻을 수 있습니다. 즉, 웹에서 EJB를 호출할 때 호출자의 신원에 대한 어떠한 정보도 개발자가 직접 넘기지 않아도 EJBContext에서 HttpServletRequest의 경우와 동일하게 getCallerPrincipal와 isCallerInRole 메소드를 제공합니다. 물론 선언적 보안이 가능하다면, 그런 프로그램적 방법이 아니라 그냥 '이메소드는 관리자만 호출가능', 혹은 '이 메소드는 누가 부르던지 관리자 권한으로 실행' 같은 선언을 어노테이션 한 줄로 처리할 수 있고, 그런 편의성이 플랫폼 차원에서 보안 기능이 제공되기 때문에 가능한 것입니다.

그리고 말씀하신 Acegi도 호출 컨텍스트와 관련해서 이와 비슷한 기능을 제공합니다.

또한 RBAC 모듈을 말씀하셨는데 위와 같은 보안 모델을 지원하는 컨테이너에는 벤더가 제공하는 플러거블 한 로그인 모듈들이 있습니다. 예컨대 썬 WAS의 경우 RBAC 모듈이 있고 대부분의 컨테이너의 경우 간단한 디비 기반 인증의 경우 전혀 코드를 작성하지 않고 처리할 수 있습니다. (물론 서블릿에서의 JAAS 연동 자체가 무지 허접스럽긴 합니다만 이건 다른 문제겠군요).

컨테이너의 자동화된 트랜잭션 관리도 마찬가지 편의 기능을 제공하고 예컨대 스프링 같은 경우 커넥션 관리도 역시 비슷한 개념으로 개발자가 직접 리소스를 관리하고 관련 API를 호출하는 번거로운 작업을 대신해줍니다. (물론 여기에 대해서도 구체적인 예를 원하신다면 충분히 들어드릴 수도 있습니다).

MVC이야기로 넘어가자면, 서블릿을 하나 만들어서 등록하면 끝이라고 하셨는데, 죄송한 말씀이지만 MVC의 핵심 개념 자체를 잘못 이해하고 계신 것 같습니다. MVC 프레임워크의 핵심은 쉽게 말해 흔히 쓰는 디자인 패턴에서 커맨드 패턴을 웹에 맞도록 구현한 것입니다. 말씀하시는 구조는 호출받은 서블릿이 임의의 뷰로 포워드를 한다는 건데 설사 서블릿을 MVC의 '컨트롤' 역할로 인정한다 쳐도 커맨드에 대해서는 어떤 언급도 없군요. J2EE 쪽에선 패러다임 자체가 순수 MVC보다는 컴포넌트/이벤트 기반으로 넘어가는 추세지만, 어쨌든 'MVC'라고 이름 붙은 어느 프레임워크를 보셔도 그 핵심은 커맨드 패턴임을 아실 수 있을 것입니다.

그리고 사실 말씀하신 서블릿-JSP 구조라면 왜 굳이 jsp에서 모든 작업을 하지 않고 서블릿을 쓰시는 지 자체가 잘 이해가 가지 않습니다. 그리고 스트러츠를 얼마나 쓰셨는지는 잘 모르겠습니다만, 말씀 하신 서블릿-JSP 구조에서는 커맨드 패턴 뿐 아니라 파일 업로드 지원, validation, actionform 등 다양한 스트러츠의 여러 부가 기능이 있습니다. 스트러츠가 이미 낡은 기술 취급을 받으며 입지가 점점 좁아지고 있긴 하지만 최소한 그냥 날코딩하면 더 빠른 전혀 쓸데 없는 기능을 굳이 복잡하게 xml로 얼기설기 엮어 놓은 정도는 아니라고 봅니다.

이제까지 JSF 컴포넌트 모델, 선언적 트랜잭션이나 보안, 혹은 MVC 등 여러 예를 들었습니다만, 제가 볼 때는 creativeidler님께서 해당 기술들을 충분히 활용할 만큼 익숙하지 않으셔서 필요성을 못느끼시는 것이 아닌가 싶군요.

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

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

Anonymouse의 이미지

fender님과 creative님은 보는 사람은 뭔소린지도
모르게 계속 이빨만 까고 계실게 아니라 각자가 실제로
만든 프로그램을 예로 들어서 자기 주장을 증명을 해주세요.

고수와 하수의 구분법
하수 : 이러쿵 저러쿵 아는건 엄청나게 많은데 실제로
짜놓은 프로그램은 한개도 없거나 대부분 허접 투성이
특히 뭔가를 설명할 때 자기가 나중에 봐도 모르는 온갖
전문용어를 마구 섞어씀
고수 : 말없이 묵묵하게 일하면서 엄청난 프로그램을
만들어 놓고 사람들을 깜짝 놀라게 만듬
어떤 설명이든지 듣는 사람의 눈높이에 맞게 이해하기
쉬운 비유를 들면서 가급전 전문용어를 자제하면서
귀에 쏙쏙 들어오게 설명함

1day1의 이미지

익명뒤에서 그런말을 하는 당신보다 훨씬 낫습니다.

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

F/OSS 가 함께하길..

fender의 이미지

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

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

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

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

creativeidler의 이미지

J2EE의 보안 모델은 저도 잘 알고 있습니다. 2002년부터 서블릿에서 제공하는 보안 모델을 썼고 제가 쓴 한글 문서도 돌아다니고 있는 게 있을 겁니다. 지방국토관리청에 JAAS로 구축한 사이트도 잘 돌아가고 있고 다음 링크도 그 증거가 될 수 있을 겁니다.

http://youngrok.com/wiki/wiki.php/%C0%DA%B9%D9%C0%A5%C7%C1%B7%CE%B1%D7%B7%A1%B8%D3%C0%C7%B1%E2%BA%BB
제가 마소에 연재했던 기사입니다.

전 개발자가 identification을 넘겨야 한다는 말은 단 한 마디도 하지 않았습니다. 이런 말 좀 안해도 되게 해주시면 안되겠습니까-_- 제가 이의를 제기하는 것은 fender님이 인증 받는 사람이 인증 정보를 넘길 필요가 없다고 말씀하신 것입니다. JAAS의 용어로 말하자면 인증 받는 사람은 authentication에 필요한 credential은 넘겨 줘야 합니다. 그걸로 authorization을 하는 것은 권한 모듈이지만요. 우리가 문을 열고 들어가려면 들어가는 사람이 열쇠를 가지고 열어야 합니다. 홍채 인식 장치가 있으면 들어가는 사람이 눈을 들이대야 하고 지문 인식기가 있으면 들어가는 사람이 지문 인식기를 대야 합니다. 비록 사용자가 "나 관리자다", "나 일반 사용자다"라고 말하는 것은 아니지만 "나 마이클 잭슨이다. 비밀번호는 XXX다."라든지, "나 몽키 D 루피고 의심나면 DNA로 확인해."라고는 해야 인증이 가능하다는 것입니다. fender님도 이런 걸 모르시진 않으실 텐데 표현을 하다보니 실수하신 것 같아서 제가 정정하려 했던 것입니다. 그 어떤 보안 프레임웍도 사용자의 identification이 없는데 인증해주진 않습니다.

MVC 이야기로 다시 가면...
참고로 스트러츠, 저 0.9 버전부터 썼습니다. 스트러츠에 message 부분이 자바 properties를 사용하기 때문에 한글 문제가 복잡한 것을 부분적으로 해결한 소스도 제가 올린 게 꽤 돌아다니고 있는 걸로 압니다. 스트러츠 소스 안 열여본 부분이 별로 없고 꽤 빠삭하게 알고 있다고 생각하는데요. 충분히 활용할 만큼 익숙하지 않다는 말을 듣기에는 너무 오랫동안 써왔습니다.

MVC를 이해 못하고 있다라. 허허, 이런 말을 들을 정도로 제가 모르고 있는 것 같진 않습니다. 제가 스트러츠와 서블릿을 비교하기 위해 MVC를 설명해야 제가 MVC를 아는 것이 되나요? 커맨드 패턴이라.. 설마 action 객체를 커맨드 객체라고 말씀하시는 것은 아니겠죠? 그런 거라면 서블릿도 커맨드 객체입니다. action 객체와 서블릿 객체는 하는 역할이 MVC의 입장에선 거의 완전히 동등합니다. 서블릿 자체가 이미 프레임웍이라는 걸 모르시진 않겠죠?

그렇다면 J2EE 패턴에서 말하는 BO를 커맨드 객체라고 생각하고 있으신 게 아닌가 하는 생각이 듭니다. 하지만 J2EE의 그 패턴은 Anemic Domain Model이라는 비판을 받고 있습니다. 모델 부분을 커맨드패턴으로 구현하는 것보다는 도메인 모델(PEAA) 패턴으로 구현하는 것이 좀더 OOP적이라고 봅니다.

어느 쪽이든 MVC를 커맨드패턴으로만 이해하는 것은 그렇게 바람직한 시각은 아니라고 봅니다. 글고 사실 MVC는 웹보다 클라이언트의 GUI를 위해 나온 프레임웍이란 사실을 아십니까? 원래 MVC에서 더 중요한 패턴은 옵저버 패턴입니다. 뷰와 모델이 옵저버 패턴으로 엮여 있어서 모델이 업데이트되면 뷰에 notify가 되죠. 웹에서는 이게 잘 안됩니다. 그래서 JSF가 나온 겁니다. JSF는 MVC가 아닌 게 아니라 오히려 MVC에 더 가깝게 다가가게 해주는 것입니다.

스트러츠 자체가 보여주고 있는 패턴은 MVC이기도 하지만 Front Controller(PEAA)라는 용어가 좀더 정확합니다. 그리고 이 Front Controller 패턴은 사실 알고보면 서블릿 자체가 Front Controller입니다.

그리고, 거듭 말씀드리지만 전 날코딩(?) 지지자가 아닙니다. 왜 그렇게 생각하시나요? 이번엔 꼭 좀 답해주세요. 전 단 한 번도 이미 있는 거 냅두고 죄다 코딩하는 것이 좋다는 말을 한 적이 없는 것 같은데요. validator. 그 말씀 하실 줄 알았습니다. 이미 반론도 준비되어 있죠. ^^ commons validator로 이미 분리되어 있어서 스트러츠 없이도 쓸 수 있습니다. 꽤 오래된 이야기 아니던가요. actionform. 스트러츠 메일링 리스트에서 actionform으로 거친 토론이 오갔던 게 생각나는군요. 결국 DynaActionForm이란 게 탄생하게 된 것도 스트러츠의 actionform이 구리기 때문입니다. 스트러츠의 치명적인 단점으로 actionform을 꼽는 사람도 많답니다. Tiles도 괜찮은 기능이지만 요즘은 또 SiteMesh가 좀더 나은 것 같습니다.

저도 나름대로 자바계(?)에서는 이름이 알려져 있다고 생각했었는데 실력을 의심하는 말까지 듣는 걸 보니 아직은 별로 유명하지 않은가 보네요. 흑 ㅠ.ㅠ 좀더 커뮤니티 활동에 신경을 써야겠다는 생각이...쿨럭-_-;;

제 실력이 의심나신다면 코딩 대결도 환영합니다. 같은 문제를 fender님은 J2EE의 기능들을 활용해서 만들고 전 non-IoC 도구들을 엮어서 만들고 pmd 같은 걸로 코드 퀄리티를 측정해볼 수도 있겠죠. 아직 PHP로 하자!라고 말할 정도의 PHP 실력이 안되는 것은 안타깝지만 자바로는 충분히 보여줄 수 있습니다.

creativeidler의 이미지

그리고 anonymous에게..

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

Anonymouse의 이미지

흐흐 저도 이바닥에서 먹고사는데 creativeidler님 실력과 명성은
모를리가 있겠습니까~ 근데 fender님은 어떤 분인지 잘 모르겠어서
걍 creativeidler님까지 도매급으로 떠다 넘긴거니깐 이해해 주세요. ㅎㅎ
fender님이 creative님보다 더 유명한 분이었다면 지송합니다~

fender의 이미지

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

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

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

pok의 이미지

두분 토론 매우 잘 보고 있네요, 그런데

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

놀릴려구요. 토론에 비방이 감초라는것은 알고 있지만, 두분다 조금 도를 넘으신것 같아서요.(-_-)

그리고 저는 좀더 토론이 확대되었으면 좋겠는데요, 두분의 가장큰 차이가 프레임워크의 생산성의 문제인것 같거든요.

무슨말이냐면, fender 님의 주장은
1. 프레임워크는 (특정분야에서) 생산성을 올려준다
2. 자바는 PHP보다 프레임워크가 잘 발달되어 있다.
3. 따라서 PHP보다 (특정분야에서) 자바의 생산성이 좋다.

이고 creativeidler 님께서는
1. 프레임워크가 생산성을 올려주는 것만은 아니다.
2. 자바의 프레임워크에 의한 장점은 PHP의 다른것으로도 구현이 가능하다
3. 따라서 프레임워크로 인해 자바가 우수하다는것은 옳지 않다.

인것 같거든요.

그래서 저는 생산성 있는 프레임워크의 조건에 대해 이야기 해봤으면 좋겠습니다.

저같은 경우는 MVC모델과 PHP와의 관점에서 본다면, PHP는 View 면에서 아주 우수하다고 생각합니다만, 모델과 컨트롤에서는 불만인데요,

첫째. 강력한 모델계층의 부제
제일 불만인것은 고수준의 자료형과 관련된 라이브러리입니다. 조금만 로직이 커져도 잘 정의된 ADT의 위력이 절실한데, PHP로 연산이 많은 모델을 구현하려면 Python의 list나 C++의 STL, Java의 컬렉션이 많이 그리워지더군요. PHP 자체로 list형같은게 생겨도 좋겠지만, C++과의 효율적인 연동(단순히 forking하는것에 그치지 않는)등이 됐으면 참 좋겠습니다.

둘째. 요청에 대한 컨트롤에서 일관적인 인증문제
사실 웹에서만의 문제라면 세션과 시리얼라이즈만으로도 충분하겠지만, 모델계층이 약한 PHP에서 외부의 인터페이스와 연계되려면 좀더 나은 보안모델이 만들어 졌으면 좋겠습니다. 특히, xml-rpc를 이용하면 보통 한번의 요청때마다 ID와 비밀번호등의 인증키를 보내는것이 일반적인데(MetaBlog나 NaverAPI 등) 개선되었으면 합니다.

그런데 사실 이것은 PHP만의 문제는 아니라고 생각합니다. 자바의 모델계층으로는 역부족인 경우도 많은데요, 특히 게임서버등의 경우가 그러합니다. 이러한 외부 모델과의 연동까지 고려한 자바프레임워크는 전무한것 같거든요. 또한 xml-rpc등도 같은 문제인것 같구요.

결론적으로 PHP의 프레임워크는 MVC를 모두 가지려하지 말고 확실히 잘 떠넘기는(?) 프레임워크가 나왔으면 하는데, 여러분은 어떤 프레임워크를 원하시나요?

----
http://end.kldp.net ::함께하는 게임개발

creativeidler의 이미지

음. 유명..이야기나 실력..이야기는 그냥 해본 소리입니다. 그냥 내가 잡지에다 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님께서 반론하시는 것에 대한 응답 외에는 더 이상 논의를 확대시키지 않도록 노력하겠습니다.

cleol의 이미지

저도 creativeideler 님과 fender 님 토론 잘 읽고 있습니다. 그런데 한편으로는 pok 님 말씀처럼 토론이 더 확대됬으면 좋겠다는 생각도 들지만 두 분다 조금만 쉬시는게 좋지 않을까...하는 생각이 더 큽니다 :)
이번 글타래는 일단 마무리하고...기회가 된다면, 얼마 후에 조금 정리된 주제를 가지고 다시 말씀들 나누시는게 좋겠다는 생각이 듭니다. 지금은 토론 대상이 되는 명제(?)가 좀 불분명한 상황이라 더 이상 생산적이 되기는 어려울 것 같습니다.
며칠 좀 쉬시고 후에 관심있는 누군가가, 아니면 두 분 중에 한 분이 토론 주제를 정리해서 새 글타래에서 이어나가면 좋을 것 같습니다. 프레임웤에 대한 부분 또 한편으로 agile한 개발(agile 언어?)이 요새 많은 사람들의 고민거리이니 조만간에 또 이야기가 나오지 않겠습니까?

fender의 이미지

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

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

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

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

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

pung96의 이미지

원래 전문가 둘이서 이렇잖아요, 그렇죠 이렇죠 하구 한두방에 끝나면 배울게 많이 없습니다.
두분이 서로 이해의 차이가 있어서 이해의 폭을 좁히려고 노력하는 순간(실제로 좁혀지는 것과는 상관없이) 우리는 주워들을께 늘어나는거죠.. ㅎㅎ.

감사합니다. 많이 배웠네요.

corba의 이미지

두분의 열띤 토론에 .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에서 작성한게 제대로 마이그레이션이 되는지도 잘 모르겠네요)

익명사용자의 이미지

현재로썬 .NET만큼 윈도우 프로그래밍 하기 좋은 환경은 없을겁니다.
그리고 이 주제의 제목은 PHP vs ASP.NET으로 해야했습니다.

결론은 간단합니다. 클라이언트가 PHP로 만들어도 된다고 했고 내가 PHP를 잘하면 PHP로 만들면 됩니다.
일반적인 웹개발의 경우 PHP가 훨씬 쉽고 빠르게 결과를 낼수있습니다.
요즘에 PEAR와 Smarty를 써보니 ASP.NET은 손도 대기 싫을정도입니다. (전 닷넷 개발자-_-)
하지만 요구사항이 간단하지 않은 경우엔 .NET으로 진행하는게 나을수 있습니다.
누가 그랬다는군요. .NET이나 JAVA를 선택해서 실패한 프로젝트는 없다고..

PHP로 http://www.fpoint.com 의 스프레드와 같은 컴퍼넌트나 그보다 훨씬 다양한 컴퍼넌트(http://http://www.componentsource.com/features/net-components/index.html)를 구현할수있거나
돈을 주고도 살수있다면 어느경우에서도 PHP가 우세할겁니다.

익명사용자의 이미지

아직은 부족한 면들이 있지만, 강력하더군요.

몇년 안에는 IDE때문에 .net이 좋더라 이런 의견은 힘을 잃을 듯 합니다.

number3의 이미지

creativeidler 님이 인용한 이 문구가 정답이라고 생각합니다.

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

덧붙이자면 프로그래밍과 프로그래밍 언어 또한 문제를 해결하기한 지식체계이고, 그 지식체계들의 모음을 방법론이라고 하거나 프레임워크라고 하는 것이겠죠. 문제나 과제가 있고, 그에 대한 해결과 경험이 있기 때문에 하나의 체계를 형성할 수 있겠죠. 이런 지식체계는 상위 레벨에서 오랫동안 써오거나 고안한 사람에게는 단순한 ABC나 1+1의 문제이겠지만, 처음 접하는 사람들에게는 E=mc^2 같은 문제이겠지요. 자바가 처음 나올 때 누구나 쉽게 배울 수 있다고 했지요. 거의 모든 언어들이 처음 나올 때 어느 하나라도 쉽지 않다고 하지는 않죠. 댓글들에 나오는 내용을 이해하고 적용해서 개발할 수 있으려면 날밤까고 월화수목금금금 해서 최소 4-6개월정도 해야 되지 않나요? 제 추정에는 그렇습니다만.

우리가 프로그래밍이나 프레임워크를 이야기하면서 혹시나 잊고 있는 것이 있지 않을까 돌아보면 어떨런지요. 아마도 PHP, Java, Framework, sprint, MVC 같은 것을 고객은 원하지도 않고 알 필요도 없습니다. 고객은 처한 상황을 해결해주는 해결방법을 최우선으로 평가하겠지요. 개인적으로 고객이 바라는 업무가 무엇인지, 그리고 그 업무는 어떻게 흘러가야 하는 것인지를 이해하고, 고객의 언어로 설명해주고, 빠르고 명확하게 개발하는 것이 제일 좋지 않나 생각합니다. 빠르게 처리하려고 주로 php를 쓰고 있습니다. 단 하나, 필요로 하는 업무를 이해하고 해결과제에 집중하는 것입니다.

Quote:
저는 프로그래머들에게 말합니다. "여러분은 가정용 드릴을 설계하는 사람들과 같습니다. 그런데 여러분은 여기서 볼 베어링이냐 롤러 베어링이냐 아니면 에어 베어링냐 같은 내부 사항에 대해서만 얘기하며, 고객이 이런 것들을 다른 어떤 것보다도 중요하게 생각할 것이라고 주장하고 있습니다. 틀렸습니다. 고객은 드릴 자체에 대해서는 신경 쓰지 않습니다. 신경 쓴 적도 없고 앞으로도 계속 그럴 겁니다. 고객은 드릴을 원하기 때문에 드릴을 구입하는 것이 아닙니다. 구멍을 내기 위해 드릴을 사는 것입니다. 만약 벽에 걸 수 있는 구멍이 있다면 아마 그걸 살지도 모릅니다. 드릴에는 손도 대지 않고 훨씬 만족할지도 모릅니다. 여러분의 드릴은 구멍을 내기 위한 필요악일 뿐입니다. 이제 가슴에 손을 얹고 솔직하게 답해보기 바랍니다. 사용자가 진정으로 원하는 구멍은 어떤 것일까요? 어떻게 여러분의 프로그램이 더 빠르고 더 적은 비용으로 사용자가 원하는 더 좋은 구멍을 내게 할 수 있을가요?
소프트웨어, 누가 이렇게 개떡 같이 만든 거야 - 데이비드 S. 플랫, 인사이트, 60페이지
nonots의 이미지

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

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


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

marzok의 이미지

php는 써본적은 없지만 이클립스 플러그인에 많이 보이더라구요.
이번 기회에 이클립스의 매력에 빠져 보심이?

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.