Rasmus의 특강 : Simple is Hard

PHP 창시자 Rasmus Lerdorf 의 특강이 2009년 4월 21일, 그러니까 어제 야후 코리아 사무실에서 있었습니다. 보다 많은 사람들과 공유하고자 간단하게 내용을 정리해봤습니다. 강의 자료는 http://talks.php.net/show/korea09 를 참고하세요.

슬라이드
슬라이드

강의는 전체 두 개 세션으로 진행되었습니다.

첫번째 세션에서는 단순함(Simplicity)을 강조했고, 두번째 세션에서는 보안(Security)을 강조했는데 XSS에 대한 내용이 주였습니다. 시간이나 진행 내용으로 봤을 때 Rasmus씨가 강조하고 싶었던 것은 전자인 듯 합니다.

아래는 제 기억에 의존해서 Rasmus씨의 강의를 대충 재구성해봤습니다(앞의 번호는 슬라이드 번호입니다). 아무래도 강의가 영어로 진행되다보니 전부 다 들은 것은 아니라 빠진 부분이 있을 수도 있습니다. 슬라이드를 참고해서 보시면 도움이 되리라 생각합니다.

  1. 어느 복잡한 어플리케이션의 구조. 뭐가 뭔지 알아보기 힘들다.
  2. 경험이 증가할수록 더욱 단순하게 만들려고 노력하지만, 대부분의 웹은 중간단계(복잡도가 증가하는)에 머물러 있다. 점점 더 복잡해지는 추세다. 야후에서 다른 사람들이 나에게 문제가 생겼다고 도움을 요청할 때마다 내가 하는 일은 코드를 지우는 것이었다.
  3. 복잡성이 증가함으로써 우리가 잃게 되는 것. Scalability, Performance, Security
  4. 어떤 것도 공유하지 않는 구조가 좋다. HTTP를 처음 봤을 때 그 단순함에 매료됐었다. 사람들이 Stateless한 HTTP에서 세션, 쿠키 등을 요구했었다. PHP에 그 기능을 추가하면서, 나는 그 부분을 아예 위임할 수 있도록 했다. "좋은 외부 솔루션이 많은데, 왜 내가 직접 만들어야 하지?" 그랬더니 사람들이 알아서 DB에도 붙이고(특히 단순한 MySQL이 많이 사용됐다) 그랬다. MVC 패턴은 정말 좋지 않은 생각이다. 왜 모든 것을 Controller가 제어해야 하는가? 야후 메일은 각각의 서버가 독립적으로 통신하도록 만들어져있다. (이 부분에서 특히 많은 말을 "빨리" 해서 놓친 부분이 많습니다. T^T)
  5. 웹 브라우저 자체가 이미 훌륭한 Front controller이다. 독립적으로 요청하고, 독립적으로 데이터를 수신할 수 있다.
  6. (지금부터는 Performance 얘기) 사용자들에게 0.2초 안에 어떤 반응이 일어나지 않으면 그 웹사이트는 문제가 생길 수 있다. 반응이 없어 클릭을 여러번 하면 여러번의 요청이 생긴다. 한번만 발생해야할 요청이 여러번 발생한다는 것이다. PHP는 느리지 않다. 대부분의 병목현상은 프론트엔드(front-end)에서 발생한다. (YSlow 시연 - 야후코리아, ㅈ신문사)
  7. Siege를 사용한 퍼포먼스 테스트
  8. APC를 사용한 성능 개선
  9. 웹 서버의 call 프로세스를 체크하고, System call을 줄인 사례(Directory index 순서를 조절하거나 적게 지정하도록)
  10. System call을 줄이기 위해 include 패스를 조절한 사례(.을 뒤로 두면 보안상 좋다는 것 같기도... -_-;;)
  11. 다시 벤치마킹
  12. apc 파라미터값 조정. stat는 파일의 변경을 자동으로 체크하도록 하는 인수
  13. include 구조를 파악할 수 있는 툴(솔루션의 복잡성을 파악하는데 도움이 된 듯)
  14. 의존성 제거
  15. Callgrind를 사용한 병목구간 체크 방법(직접 시연을 해주었는데 꽤 유용한 툴이었습니다. rasmus씨가 사용한 것은 kcallgrind라는 GUI 툴이었습니다)
  16. XDebug를 사용한 병목구간 체크 방법(XDebug에서 Callgrind를 지원해서 실은 거의 같았어요)
  17. 불필요한 코드 제거(여기서는 과도한 XMLWriter 호출 제거)
  18. 본인이 작성한 Twit
  19. Twit의 성능 - 1
  20. Twit의 성능 - 2
  21. Twit의 구조 (그러니까 빠르다... 이런 느낌?)
  22. Callgrind 체크
  23. 휴식

휴식 시간 이후로는 XSS에 대한 내용이었는데, 슬라이드만 봐도 어느 정도 이해할 것이라 생각합니다. 처리해야 할 게 너무 많더군요. -_-;;

그 외 기타사항으로는... Entry 포인트를 나누어라(index.php에서 다하려고 하지말고, 파일을 나누어라. 그게 웹 어플리케이션이 작동하는 방식이다), 클래스 구조를 과도하게 작성하는 것은 컴파일되는 언어에서나 해라(스크립트 언어는 그렇게 쓰라고 있는게 아니다), 클래스 상속구조가 어떻게 프레임웍이 어떻고 그건 개발자들의 자기 만족일 뿐(사용자들은 신경쓰지 않는다. 사용자들이 관심있는 것은 이 사이트가 얼마나 빨리 반응해주냐이다)... 정도가 있었습니다.

마지막에는 자신이 만들었다는(제가 듣기론?) XSS 스캐너 프로그램인 scannus 시연 장면을 보여주었습니다만, 검색해보니 공개된 것은 아닌가 봅니다. ^^;; 대신 예전에 ajaxian.com에서 봤던 XSS Rays라는 스캐너 프로그램을 링크합니다.

Slides: http://talks.php.net/show/korea09
YSlow:http://developer.yahoo.com/yslow
Siege:http://www.joedog.org/JoeDog/Siege
Xdebug Profiling: http://xdebug.org/docs/profiler
XHProf Profiling: http://pecl.php.net/xhprof
sla.ckers.org: http://sla.ckers.org/forum/list.php?3
Filter: http://php.net/filter

그리고 아래는 제가 아주 잘 나온 인증샷~

Rasmus의 특강 경청중!
Rasmus의 특강 경청중!

  1. PHP의 창시자 Rasmus Lerdorf를 만났습니다...

    PHP 언어의 창시자인 Rasmus Lerdorf 의 개발자 세미나에 다녀왔습니다. 진행을 해주신 정진호님의 소개에 따르면 게시판을 만드는데 필요해서 만든것이 PHP의 시작이 되었다고 하네요. 참 소박한 ...

  2. 아흑! 부럽습니다! 멋진 강의 듣고 오셨군요.

    내용 중에 간결함과 성능에 대해서는 저도 찬성입니다. 프로그래밍 편의을 위한 프로그래밍이냐, 아니면 성능을 위한 프로그래밍이냐 이야기들이 많지만, 개발자를 위하기 보다는 성능, 즉 사용자를 위하는 게 맞다고 생각합니다.

    물론 구조적으로 작성되어야 하고, 다음에 봐도, 또 누가 봐도 이해가도록 적절히 주석을 달아준다는 것이 전제되어야 하겠지만요.

    좋은 내용 잘 보고 갑니다!
    아흑 부러워 ...

  3. @mooo
    제 생각도 그렇습니다. ^^
    자기 만족에서 하는 프로젝트가 아니라 "프로"로서 하는 작업이라면, 사용자에게 만족을 줄 수 있는 방향으로 만들어지는 것이 맞다고 생각합니다. 강의 중간에 보여준 어떤 프로젝트는 정말 구조 지향적인 듯 하더군요. 개발자"만" 행복했을 것 같았습니다.

  4. @정진호
    중간중간 놓친 부분도 꽤 있습니다. 영어가 절 싫어해서... orz
    좋은 기회 마련해주셔서 정말 고마웠습니다. 다음에도 기회가 된다면 꼭 참석하도록 하겠습니다. ^^

  5. 반갑습니다.
    왼쪽에서 비몽사몽 듣느라 스크립쳐가 많이 비었는데
    덕분에 다시 강의를 한번 더 듣게 됩니다.

    많이 배우고 갑니다

  6. PHP 창시자 rasmus를 만났다...

    PHP의 창시자 rasmus를 만났다. 내가 아주 즐겨쓰는 언어인 PHP. PHP의 창시자를 만난다는 느낌이 마치 내가 한글을 쓰고 있는데 세종대왕님을 본다는 느낌이랄까. 이건 좀 오반가. 그렇다면, 내가...

댓글을 남겨주세요

This site uses Akismet to reduce spam. Learn how your comment data is processed.