728x90

웹 사이트 최적화 기법: UI 개발자를 위한 필수...
카테고리 컴퓨터/IT
지은이 스티브 사우더스 (아이티씨, 2008년)
상세보기

200페이지도 안되지만 꽤나 유용한 책이다.
아래는 책에서 이야기 하고 있는 내용을 다시 정리할겸 요약한 내용이다.

1. HTTP 요청을 줄여라.
- 웹페이지에 접근하면 웹브라우저(익스플로러, 파이어폭스등) 에 보여지는 모든 화면들이 HTTP 요청에 의해서 나타나는 것이다. HTML 코드는 물론이고 이미지 하나하나 모두 HTTP 요청이다.
아래 이미지 에서 보이는 것 처럼 GET 방식을 통한 HTTP 요청에 대한 응답이다.

각 요청마다 짧게는 0.008초에서 길게는 3초까지의 요청에 대한 시간이 나타나고 있는데, HTTP 요청이 줄어들면 줄어든 만큼 당연히 이 시간도 짧아지기 때문에 웹페이지 로딩속도가 짧아진다.

2. CDN을 사용하라.
브라우저가 웹서버에 요청을 하게 되면 웹서버가 살아있는한 응답을 한다. 보통 서버가 위치한 곳과 응답을 요청한 곳과의 거리에 따라서 응답속도가 달라지는데 물론 이 응답속도는 이 둘의 위치가 가까울수록 더 빠르다. (A와 B가 어떤 대화를 하는데, 이 둘이 직접적으로 이야기는 못하고, 중간에 꼭 어떤 사람을 거쳐야 한다면, 다섯명을 거치는것이 빠를지, 열명을 거치는것이 빠를지 생각해보면 쉽겠다.)

A라는 업체의 서버가 서울에 있다. 이 서버에 대한 응답요청을 제주도 에서 하는것보다 서울에서 하는게 빠르다는거다.
그런데 이 A라는 업체가 제주에서 응답요청을 하는 사람에게 좀 더 빠른 응답속도를 제공하기 위해서 제주에 서버를 두는건 일종의 낭비이다. 그래서 이런 역할을 CDN이 해주는 것이다.

물론 거의 대부분이 유료이다.

3. 헤더에 만료기한을 추가해라
이는 곧 브라우저캐시를 사용하라는 말이다. 사용자가 웹페이지에 접근할 때마다 매번 이미지를 새로받고, HTML을 새로 받는다면 사용자에겐 시간이 낭비되고, 서비스 제공업자에겐 트래픽이 낭비된다. 그래서 사용자브라우저에게 이 페이지는 앞으로 한달간 변경이 되지 않을 테니 서버에서 새로 가져갈 필요가 없다고 알려주는 것이다.
이렇게 되면 HTTP요청이 줄기 때문에 응답시간이 절약되고, 여기에 서버에서 데이터가 전송되지 않기 때문에 트래픽이 줄어든다. 사용자는 온라인으로 데이터를 가져오지 않고, 자신의 컴퓨터에서 가져오기 때문에 서비스이용속도가 올라간다.

4. 데이터를 압축해라.
gzip 컴포넌트를 사용하여 데이터를 압축한다.
참고자료 링크

5. 스타일시트의 위치
스타일 시트는 head 태그 사이에 넣어라. 다른곳에 스타일시트가 위치할 경우 페이지 로딩이 점진적이지 않고 멈춘 후 한꺼번에 보여진다.

6. 스크립트는 아래에 넣어라
페이지 하단에 스크립트를 위치시키는 것이 웹페이지 로딩에 빠르다고 한다.
하지만 난 head 사이에 넣고 있다.

7. CSS Expression을 피하라.
background-color: expression( (new Date()).getHours()%2 ? "#FFF" : "#000" );
IE에서는 위와같은 표현식이 가능하다. 하지만 쓰지말라고 한다. 어차피 쓸일이 없을것 같다.

8. 자바스크립트와 스타일시트는 외부파일로 빼라.

9. DNS조회를 줄여라.
결국 외부도메인 참조하는 것을 줄이라는것. keep-alive를 사용한 적절한 캐시도 좋다.

10. 자바스크립트를 최소화 해라
압축등을 사용해서 자바스크립트의 용량을 줄여라. 물론 CSS도 줄일수 있으면 줄여라.

11. 리다이렉션을 줄여라
리다이렉션할 주소 끝에 "/" 슬래시를 붙이지 않는다면 슬래시(/)을 붙여서 리다이렉트가 발생한다. 그 외에도 document.location 과 같은 자바스크립트 코드의 사용을 줄여라.

12. 중복스크립트를 없애라.
자바스크립의 코드의 중복을 제거하라. 모듈화 하여 적절하게 사용하라. 프로그램의 크기가 커져서 관리가 어려울 경우 별도의 hash 함수를 만들어서 스크립트를 관리하라. <- php 창시자인 rasmus 는 html코드를 php가 생성하는 것에 대해 부정적이었다. 어느 것이 좀 더 효율적인지는 직접 체크해봐야 할듯하다.

13. ETag를 설정하라.(또는 삭제하라.)
ETag는 웹서버와 브라우저간의 캐시유효성을 체크하는 메커니즘이다. 대부분은 기본설정을 이용하면 되지만 여러대의 웹서버를 가진 웹어플리케이션의 경우는 기본설정이 성능저하의 요인이 된다.
설정을 변경하든가 삭제하라. 아파치의 경우는 설정파일에 FileETag none 한줄을 추가해주면 된다고 한다.


위 13가지 내용들은 파이어폭스 플러그인인 YSlow를 사용하여 체크해볼 수 있다.있다.
Posted by onionmen

댓글을 달아 주세요

  1. Favicon of http://jagto.tistory.com BlogIcon 작토 2012.12.12 14:55  댓글주소  수정/삭제  댓글쓰기

    컴퓨터쪽 전문가가 아니면 좀 어려운 내용이네요..;; 지금 제 사이트가 느려서 고민중이에요 ㅠ

    • Favicon of https://onionmen.kr BlogIcon onionmen 2012.12.12 22:59 신고  댓글주소  수정/삭제

      안녕하세요. 반갑습니다. ^^
      작토님 블로그에 들어가보니, 평균 블로그 로딩시간이 5~6초 정도 되더군요.

      간략하게나마 확인 해보니 페이스북 위젯에서 약 2초 정도 딜레이가 생깁니다.

      그 외에도 플러그인들 몇몇개가 사이트 로딩을 지연시키는 요인이 되고 있네요.

      티스토리는 별도 서버설정을 할 수 없으므로 속도를 향상시킬 수 있는 방법은 플러그인을 제거하고, 스킨을 가벼운 것으로 바꾸는 것입니다.

      블로그 초반에 사진들이 많이 나오는데, 그것도 사이트 로딩에 1초 정도 딜레이를 주고 있습니다.

      우선 페이스북 위젯만 제거해도 큰 성능 향상이 있을것으로 보이네요. ^^

728x90
위기극복상황 보다는 팀내 스크럼 도입에 대한 내용을 써볼까 합니다.

 그렇다할 개발 방법론을 갖고 있었던 것도 아니고, 그렇다고 굳이 도입의 필요성을 느낀것도 아니었지만, 미래를 위해서는 유명한 방법론이든, 우리만의 독자적인 방법론이든, 아니 방법론을 떠나서 조금은 정형화 된 틀을 만들어 문화를 형성하는것이 어떻겠냐는 의견이 들어왔다.

'개발자들 모두 각자의 개성이 강하다., 개성이 강한만큼 틀을 만드는 것 보다는 자유롭게 풀어주는 것이 좋다.' 라는 것에는 모두 동의하지만, 울타리가 없으니 도가 지나친 경우도 있었다.

개발자들이 모두 모여 방법론에 대한 이야기를 했는데, XP와 같이 급진적인 방법론을 갑자기 채용하기엔 무리가 있었다. 린, XP, 스크럼등 애자일방법론에 대한 이야기가 주류를 이루었는데, 역시 그래도 큰 어려움 없이 적용할 수 있는 스크럼이 어떨까 하는데 결국 입을 모았다.


스크럼
카테고리 컴퓨터/IT
지은이 켄 슈와버 (인사이트, 2008년)
상세보기

10명 남짓한 개발자들을 3팀으로 쪼개서 각각 스크럼을 도입하여 업무 외 미니 프로젝트를 진행해보기로 하고, 우선 스크럼 책 10권을 구매했다. 그리고 스크럼마스터를 별도로 정하지 않고 스프린트와 백로그만을 도입하여 진행하기로 하였다.

우리팀은 스프린트기간을 이주일로 잡고, 매일 회의를 진행하였다. 하지만 매일 회의를 진행해 나간다는게 생각보다 쉽지는 않았다. 하루나 이틀 빼먹는 것은 기본이었고, 서로 각자의 업무를 처리하느라 미니프로젝트에 신경을 쏟는다는 것이 쉽지가 않았다. 또한 강제적 제약이 없었기 때문에 누구도 크게 부담을 갖지 않았다. 아무래도 실패의 시작은 여기였던 것 같다.

스크럼회의가 제대로 이루어지지 않았고, 스크럼마스터가 따로 없다보니 백로그 또한 제대로 작성되지 못했다. 

안되겠다 싶어서 강제로 스크럼 마스터를 정했지만, 문제는 공유가 제대로 되지 않는다는 점 이었다. 우선 회의가 제대로 진행되지 않는 것이 가장 컸고, 스크럼마스터가 일일이 업무상황을 체크하는 것도 무리가 있었다.

각각의 업무 내용을 매일 엑셀파일로 정리하고, 이를 공용저장소에 업로드 하자 고 결정 하였지만 문제는 파일접근문제였다. 문서에 SVN을 적용하자는 이야기까지 나왔었으니 사태는 심각한 수준이었다. 그래서 나온 대안이 구글닥스였다. 실시간으로 누구나 편집할 수 있기 때문에 탁월한 선택이었지만, 팀원들이 매번 접속하여 백로그를 작성하고, 완료되고 완료되어가는 작업을 수정하는 것이 귀찮은 일이었다. 스크럼을 위한 스크럼을 또 진행해야 할 판이었다. 백로그에 작성된 일정에 완료체크를 하고, 완료까지 남은 시간을 수정하면서 드는 생각은 "이걸 왜 해야 하나" 였다. 여기에 강제성도 없었기 때문에 제대로 진행되지 않았고, 일주일에 한번 있는 개발자들간의 회의에서는 크게 할말도 없게 되었다. 

업무파악을 잘 하고, 매일짧은 회의를 통해서 문제점을 제거해 가자 라는 기본적인 약속을 이행하기 위해 해야 할 일들이 너무 많았다. 다른팀들도 크게 다르지 않았다. 

때문에 스크럼 도입에 대한 부정적 결정이 암묵적으로 도입되었고, 스크럼 도입은 실패로 끝나고 말았다.
강제성이 없다는 점. 업무에 적용하기 힘들었다는 점. 귀찮다는 점. 이런것들이 가장 큰 실패의 원인이 아닐까 싶다. 도입하고자 하는 사람의 강력한 의지와 팀원들의 협조가 없다면 역시 새로운 방법론에 대한 도입은 그룹웨어 도입만큼 힘들지 않을까 싶다.

큰 어려움이 없을 것 같아 시작한 스크럼은 작은 어려움들이 모여 실패하게 되었습니다.
방법론 도입에 성공하신적이 있으신가요? 



Talk about Software with hani 라는 블로그가 있습니다. Hani님이 운영하시는 블로그인데 아래 책의 저자이십니다.


도와주세요 팀장이 됐어요
카테고리 자기계발
지은이 신승환 (위키북스, 2008년)
상세보기


제목을 보고 아직은 저와 어울릴것 같지 않아 읽어보지 않았지만, 언젠가 한번 읽어볼 생각입니다.
첫번째 책을 아직 읽어보지도 않았는데, Hani님의 두번째 책이 출간되었습니다.



"겸손한 개발자가 만든 거만한 소프트웨어" 라는 도서입니다. 회사소장도서로 잽싸게 구매신청 하였습니다. 제목부터 흥미있습니다.  여기 가보시면 자세한 추천사도 볼 수 있습니다. 슬슬 입질이 오시나요?

이 책의 출판사인 인사이트에서 관련도서 이벤트를 진행하고 있습니다. 책을 구매하지 않아도 참여할 수 있는 이벤트 인데요. 좀 더 자세한 내용은 아래 링크 참조하시는게 좋겠습니다.


'Etc..' 카테고리의 다른 글

구글 애드센스 코리아의 트위터  (0) 2009.07.31
레뷰 마스코트, 레뷰걸 등장.  (0) 2009.07.01
스크럼의 적용과 실패.  (5) 2009.04.17
레뷰 블로그 인증글 입니다.  (0) 2009.01.02
WoC 2008 이 열립니다.  (2) 2008.11.20
trojan vundo 를 치료하자.  (6) 2008.10.05
Posted by onionmen

댓글을 달아 주세요

  1. duru 2009.04.20 11:18  댓글주소  수정/삭제  댓글쓰기

    저희 이벤트에 참여해주셔서 감사합니다. 성공도 중요하지만 실패의 경험은 더 중요하다 하지요. 그런 의미에서 전혀 손색 없는 좋은 글이었습니다. 개발자 여러분들이 공유하면 좋겠다는 생각이 드는 군요. 감사합니다.

    • Favicon of https://onionmen.kr BlogIcon onionmen 2009.04.20 17:29 신고  댓글주소  수정/삭제

      댓글 감사합니다.^^
      비록 스크럼을 도입하지는 못했지만, 그 덕분에 팀원들 모두 좋은 경험을 한 것 같습니다.

      스크럼은 아니지만 그래도 덕분에 문제 해결방식은 예전보다 좋아졌습니다. 그런 점에서는 성공했다고 볼 수도 있겠네요 ㅎㅎ ^^

  2. Favicon of http://blog.naver.com/stallon72 BlogIcon 스탈롱 2009.04.25 00:30  댓글주소  수정/삭제  댓글쓰기

    저는 진도의 가시성이 떨어지고 혼란스럽던 과제 중간에 스크럼을 도입하여 과제가 슬슬 정상화되고 있는 것을 목격하고 있습니다. 역시나 스크럼의 도입에 있어서 성공의 열쇠는 "공감대"인 것 같습니다. 추가적으로는 진행을 공유할 수 있는 시스템의 도움도 중요하구요.

    저는 개발 10년차인데, 최근 경험한 스크럼이 개발 방법(론)중에서 가장 현실적이고 효과적이라는데 백만표 던지고 싶습니다. 마침 오늘 블로그에 지금까지의 경과를 러프하게 정리해 두었는데 참고하실 수 있을 듯 합니다.

    http://blog.naver.com/stallon72/10046272171

    • Favicon of http://blog.naver.com/stallon72 BlogIcon 스탈롱 2009.04.25 00:49  댓글주소  수정/삭제

      스크럼에 필요한 프러덕트/스프린트 백로그는 엑셀을 사용하여 작성했습니다. 작성도 편하지만 우선 순위에 의한 정렬 기능을 사용해야 했고, 번다운 차트도 그려야 했는데 엑셀 만큼한 문서가 없네요.

      사실 공유는 위키 등의 시스템이 훨씬 편하겠지만, 저희 회사는 SharePoint로 문서 공유 시스템이 구축되어 있어서 엑셀 공유가 어렵지 않았습니다.

      개인적으로도 공유와 소통의 문제가 제일 중요한 것이 맞다고 봅니다. 팀원들이 직접 백로그를 작성하고 추정하고 공유하는 작업이 성공하려면 서로 믿고 의지하는 팀 분위기는 필수인 듯 합니다.

    • Favicon of https://onionmen.kr BlogIcon onionmen 2009.04.26 02:27 신고  댓글주소  수정/삭제

      앗. 안녕하세요. 스탈롱님.
      스크럼에 대한 상세한 댓글 감사합니다. ^^
      스크럼 적용에 성공하시고 효과도 톡톡히 보신것 같습니다. 어떤면에서는 굉장히부럽네요. 다음주 개발자 회의때 스크럼 도입을 다시한번 제안해 봐야겠습니다.
      가장 큰 걸림돌로 생각했던 문서 공유도 sharepoint에 대한 검색을 하다가 엑셀 통합문서공유라는 것을 알게되어 다시한번 제안해볼 생각입니다.

      감사합니다. 그럼 좋은 주말 되세요 ^^

728x90
디지털로 저장되어 있는 사진을 실물 사진으로 인화하기 시작한건 2004년도 쯤입니다. 당시 친구의 추천으로 찍스(zzixx) 라는 사이트를 이용했는데, 품질을 비롯해 전체적으로 나쁘지 않아서 지금까지도 계속 이용 중입니다.

아직까지 다른 사이트를 검색하거나, 일부러 찾으려고 노력하지 않았었는데, 얼마전 레뷰(링크) 에서 진행하는 프론티어에 선정이 되어 처음으로 다른 인화 사이트를 가입해 이용해보았습니다.

이 리뷰는 아래 보이시는 차례로 진행되며 추후 내용 수정이 있을 수 있습니다.


Posted by onionmen

댓글을 달아 주세요

이전버튼 1 이전버튼

블로그 이미지
손을 따뜻하게 만들어 주고 싶은 애인이 있습니다.
onionmen

달력

 « |  » 2009.4
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
DNS Powered by DNSEver.com

최근에 올라온 글

Yesterday19
Today9
Total1,694,596