처음 처음 | 이전 이전 | 1 | 2 | 3 | 4 | 5 | 다음 다음 | 마지막 마지막
소프트웨어 아키텍트가 알아야 할 97가지 
Richard Monson-Haefel 지음, Eva Study 옮김 / 지&선(지앤선) / 2011년 4월
평점 :
장바구니담기


아키텍트가 꿈인 저로썬 책 제목에 아키텍트가 들어간 책을 모른척하기엔 쉽지가 않은 편입니다. 새롭게 책이 나와서 보게 되었는데.
다 본 느낌은 대박입니다. ...추 -_-b

책은 유명 아키텍트들과 국내 아키텍트들이 자신의 생각을 모아놓은 한권의 아름다운 책입니다. 좋은 글에 줄을 그으면서 보다 보니 거의 장마다 줄이 그어져 있는 상황이 벌어졌습니다. 실제로 경험이 많은 아키텍트가 얘기를 해줘서 그런것인지 도움이 되는 글들이 참 많았습니다.

1. 아키텍트는 직접 실무를 담당해야 한다
 - 아키텍트는 보통 훌륭한 이력과 인상적인 경력을 갖고 잇습니다. 아키텍트는 비즈니스와 기술자들에게 깊은 인상을 줄 수는 있지만, 자신의 능력을 직접 실무에서 검증할 수 없다면 팀의 존경을 얻기 힘들며, 그 팀은 기술을 습득하기 어렵게 되고, 그 팀 멤버들은 원래 하려고 했던 일을 해내기가 거의 불가능하게 됩니다.

2. 일정을 지켜라
- 성급한 설계 스케줄 지시는(디자인 스케줄을 밀어붙이면) 저렴한 설계, 나쁜 문서, 그리고 품질 보증 또는 사용자 수용성에 문제가 생기게 합니다.
- 성급한 코딩이나 출시 일정은(코딩 또는 출시 일을 밀어붙이면) 사용자에게 제공되는 버그의 수와 직접적인 관계가 있습니다.
- 조급한 테스트 일정 지시는 완성도 낮은 테스트 코드 작성, 그리고 결함 발생률 증가와 직접적인 관계가 있습니다.
- 이상의 모든 지시에 의한 생산 문제를 해결하기 우해서는 훨씬 많은 비용이 들어갑니다.

3. 아키텍처적인 트레이드오프를 고려하라
- 높은 성능, 높은 가용성, 고수준의 보안 그리고 고수준의 추상화 모두를 동시에 충족하는 아키텍처를 설계하는 것은 사실상 불가능합니다.

4. 설계의 기준으로서 불확실성을 사용하라
- 어느 부분에서 자세한 사항을 미룰 수 있고, 또 어느 부분에서 설계 결정의 중요성을 감소시키기 위해 분할하고 추상화할지 불확실성을 기준으로 결정하십시오.
- 아키텍트는 둘 중 하나를 선택해야 하는 혼란스러운 상황이 오기 전에 미리 이런 상황에 빠져들 필요가 있습니다.

5. 재사용은 단지 아키텍처뿐 아니라 사람과 교육에 관한 것이다.
- 오직 다음에 언급할 사람들만 재사용합니다.
1) 재사용 요소가 있는 곳을 아는 사람
2) 재사용 요소를 사용할 수 있는 사람
3) 자신이 스스로 하는 것보다 재사용 요소가 낫다가 확신하는 사람

6. 범위는 성공의 적이다
- 고객이 실제 요구하는 것을 알아내십시오.
- 분할 후 정복하십시오.
- 우선순위를 두십시오.
- 가능한 결과가 나오자마자 전달하십시오.
- 복잡한 아키텍처는 간단한 아키텍처보다 훨씬 자주 실패합니다.

7. 쇼맨십을 넘는 가치 있는 청지기 정신
- 자신의 가치를 입증하는 것이 개인의 기술적 탁월함으로 팀을 좌절시키는 쇼맨십으로 이루어져야 한다고 오해하는 아키텍트들이 있습니다.
- 아키텍트는 확고한 리더십으로 팀의 존경을 얻어야만 하고 기술과 팀이 운영하는 비즈니스 도메인의 이해가 있어야 합니다.

8. 말하는 것에 대해서 말하다
- 유능한 아키텍트가 되기 위해서는 반드시 기본이 되는 아키텍처와 디자인 패턴들을 이해하고, 언제 사용되고, 적용할지 알아야 합니다. 그리고 다른 아키텍트.개발자와 대화하기 위해 패턴을 사용할 수 있어야 합니다.
- GoF의 기본 디자인 패턴들을 아는 것은 모든 소프트웨어 아키텍트에겐 필수적입니다.
- 이러한 패턴들은 아키텍트와 개발자 간에 효율적인 대화를 나누게 하는 표준 어휘의 일부입니다.
- 다양한 안티패턴들을 알고 이해하는 것 역시 ㅁ우 중요합니다.

9. 개발자에게 권한을...
- 개발자를 불필요한 업무에서 보호해야 합니다.

10. 패턴 중독
- 디자인 패턴들은 단지 되풀이되는 문제들에 대한 재사용 가능한 솔루션들입니다.

11. 견해, 취향보다는 원리, 원칙, 유추를 먼저 고려하라
- 아키텍트를 구성할 때에는 견해, 취향보다는 원리, 원칙, 유추를 먼저 고려하라
- 신기술을, 디자인패턴을 써보려고 두리번 거리고 있는 않는가?

12. 간단한 것은 간단하게 하라
- 간단한 것은 간단하게 유지해야 합니다.
- 복잡한 해결책으로 발생할 비용이 작을지도 모르지만 기회비용은 훨씬 많이 발생할 수 있습니다. 아키텍처 수준에서 오버 엔지니어링 문제는 개발 단계에서도 동일한 문제를 발생시키며 부정적인 영향은 배가 됩니다.
- 요구사항 이전에 아키텍처를 결정하고, 요구사항을 받아들인 후, 잘못된 것을 제거하는 것이 얼마나 어려운지 자문해 봐야 합니다.
- 미래 요구사항을 추측한다면 여러분의 50%가 틀렸을 겁니다. 그리고 나머지 49%는 완전히 틀린 요구사항일 것입니다. 오늘의 문제는 오늘 풀어야 합니다.

13. 설계하기 전에, 그것을 먼저 코드화할 수 있어야 한다
- 아키텍처 설계의 일부 구성 요소 중 여러분이 스스로 사용해본 적이 없는 구성 요소가 큰 비중을 차지한다면, 몇 가지 부작용이 일어나게 됩니다.

............................................

좋은 내용이 너무 많아서 다 못 옮기겠네요.. -_-;

좋은 책입니다.

아키텍트를 꿈꾸시는 분이라면 강추해드립니다. ^^

 
 
 
소프트웨어 아키텍트가 알아야 할 97가지 
Richard Monson-Haefel 지음, Eva Study 옮김 / 지&선(지앤선) / 2011년 4월
평점 :
장바구니담기


아키텍트를 꿈꾸신다면 정말 강추드립니다. ^^


 
 
 
웹 사이트 최적화 기법 - UI 개발자를 위한 필수 지침서, 웹사이트를 더 빠르게 만드는 14단계 
스티브 사우더스 지음, 박경훈 옮김 / ITC(아이티씨) / 2008년 6월
평점 :
장바구니담기


사다 놓은지 1년 좀 된것 같은데..  왜 안보고 있을까라는 생각에 단숨에 읽어버렸네요 'ㅡ' 

저자는 야후에서 성능 최적화 부서 팀장으로서 당장 써먹을 수 있는 내용을 많이 밝히고 있습니다.

보통 우리가 속도가 느리면 DAO쪽에만 치중을 하는데.. 웹쪽이 느려서 기껏 빠르게 해놓은 API가 무용지물이 될수 있으니.. 웹쪽도 잘 봐두어야겠습니다.

책에서는 14가지의 규칙을 내세우며 적용하는 법을 가르켜줍니다. 하나씩 찬찬히 보도록 하겠습니다.


규칙 1. HTTP 요청을 줄여라.

=> 우리가 웹에서 URL을 치면 html을 던져주는데 html안에 이미지가 총 5개라면 총 6번의 요청이 생기게 됩니다 html(1) + 이미지(5) = 6. 음 요청이 많으면 당연히 속도가 느려지겠죠? 그럼 어떻게 HTTP 요청을 줄일 수 있을까요? 젤 쉽게 할 수 있는 방법은 이미지 큰것을 하나를 주고 그것을 CSS로 나눠서 쓰는것입니다. 이것을 CSS Sprite라고 합니다.  그래서 요청을 줄이는것이죠.  또한 스크립트와 스타일시트도 인라인으로 하나의 페이지에서 부르면 속도가 더 빠릅니다. 헌데 인라인으로 호출하면 캐쉬에 들어가지 않기 때문에 자주 호출되는 것이라면 더 느려질수도 있습니다. 'ㅡ'

단 스크립트가 너무 잘게 쪼개져 있다면 크게 하나로 합치기를 권장해드립니다.

 
규칙 2. 콘텐츠 전송 네트워크를 이용하라.

=> 콘테츠 전송 네트워크는 한곳에 집중되는 콘텐츠 부하를(서버 하나) 전국(지방에 몇개)으로 나누는 것입니다.  미국에 있는 야후는 미국보다 당연히 한국이 느리겠죠. 왜 일까요? 그것은 접속하는 서버가 멀리 있기 때문입니다. 이런 문제를 해결하기 위해 콘텐츠 전송 서버회사들이 생겼고 이런 회사들은 CDN(Contents delivery network)이라고 합니다 참고로 얼마전 후배녀석을 만났는데 CDNetworks라는 회사를 다니고 있더군요. 규모는 400여명이고 현재 나스닥을 준비중이라고 합니다  한국에서는 CDN관련해서는 자기 회사가 꽉잡고 있다고 하더군요. ^^(
www.cdnetworks.com)

 
규칙 3. 헤더에 만료기한을 추가하라

=> 브라우져는 캐시를 이용하여 HTTP의 요청 수를 줄일 수 있습니다. 이때 웹서버는 헤더의 Expires 속성을 통해 브라우져가 캐시에 있는 구성요소의 복사본을 언제까지 사용할 수 있는 알려 줍니다. 자 그러면 당연히 잘 안바뀔 것 페이지는 Expires 속성을 오래두고 쓰는게 좋겠죠?

그리고 HTML/1.1에서는 Cache-Control이란것이 추가되었습니다. 이것을 이용해서 아래와 같이 캐시를 주고 안주고를 설정할 수 있습니다
 
보통 JSP에서는 아래와 같이 해서 캐시에 담지 않도록 하는데
response.setHeader("Cache-Control","no-cache"); //HTTP 1.1
response.setHeader("Pragma","no-cache"); //HTTP 1.0
response.setDateHeader ("Expires", 0);   // prevents caching at the proxy server

캐시를 준다면 아래처럼 할 수 있습니다
response.setHeader("Cache-Control","public");
response.setDateHeader(이름,날짜)="날짜(long)"를 String으로 변경하여 지정한 "이름(String)"의 헤더를 설정한다.(void)
예제로 하루를 준다면.
long lCurrentTime = System.currentTimeMillis();
long lTermTime = 60*60*24*1000 // 하루
response.setDateHeader("Expires", lCurrentTime + lTermTime);

 
Expires를 설정하지 않은 사이트
http://stevesouders.com/hpws/expiresoff.php
Expires를 설정한 사이트
http://stevesouders.com/hpws/expireson.php


규칙 4. Gzip 컴포넌트

=> 만약 브라우져가 압축한 파일을 인식할 수 있다면 서버에서 htrml이나 스크립트등을 압축을 해서 내려보낸다면 용량이 적으니깐 속도가 빨라지겠죠?
HTTP/1.1에서부터 웹 클라이언트(브라우져)는 Accept-Encoding 헤더를 이용해 압축의 지원 여부를 보내줍니다.
Accept-Encoding: gzip, deflate
이렇게 브라우져에서 보내주면 이 브라우져는 gzip과 deflate는 인식할 수 있구나라고 생각하고 서버에서는 아래처럼 압축을 해서보내주면 됩니다.
Content-Encoding: gzip
참고로 압축포맷에는 gzip과 deflate 두개가 있는데 gzip를 강추한다고 합니다. 

 그럼 무엇을 압축해야할까요?
html, 스크립트, css같은 파일은 해야할지 알겠는데 이미지도 가능할까요? 아쉽게도 이미지(gif, jpeg등)는 이미 압축을 한 상태이기 때문에 또 하면 안된다고 합니다.
보통 JSP/서블릿에서는 필터를 이용해서 gzip으로 압축을 하게 되죠. HeadFirst JSP/Sevet 에서도 필터에서 압축필터를 예제로 필터를 설명하고 있습니다.
여튼 gzip은 자바의 GZIPOutputStream을 이용해서 아래처럼 하실 수 있습니다.

 
.. 중략..
   response.addHeader("Content-Encoding", "gzip");
   gzipstream = new GZIPOutputStream(output);
.. 중략..

 

규칙 5. 스타일시트는 위에 넣어라

=> 왜 그럴까여? 그건 css가 다 다운받지 않으면 html의 랜더링이 안되고 그럼 빈화면이 계속 유지되기 때문입니다. 즉 css는 무조건 빨리 받아야 하는것이죠

헌데 이 css를 선언하는데에도 방법이 두가지가 있습니다. @import와 link태그가 그 주인공인데요  @import요소는 그 밖의 요소보다 앞서서 선언되어야 하고 또한 성능면에서도 link태그보다 떨어지므로 link 태그를 써야한다고 하는군요! 참고로 브라우져가 css를 젤 먼저 읽는 이유는 아래와 같다고 합니다


    스타일시트가 아직 로딩 중인데도 렌더링 트리를 구성하는 것은 상당히 비효율적이다. 스타일시트가 로드 완료되고 분석될 때까지 화면에 그리는 작업을 피하는 것이 좋기 때문이다. 그렇지 않으면 화면에 표시될 콘텐츠의 스타일 정보가 완전하지 않은데도 화면에 나타나는 FOUC(flash of unstyled content의 약어로 스타일이 적용되지 않은 콘텐츠가 나타나는 것) 현상이 나타난다. 
                                    - 데이비트 하이엇(Daive Hyatt)              ┛

 

1) CSS를 아래에 위치시킨 페이지 :
http://stevesouders.com/hpws/css-bottom.php
2) CSS를 상위에 시킨 페이지 : http://stevesouders.com/hpws/css-top.php
3) @import를 이용해서 선언한것 : http://stevesouders.com/hpws/css-top-import.php
4) 스타일이 뒤늦게 적용되는 것 : http://stevesouders.com/hpws/css-fouc.php 


규칙 6. 스크립트는 아래에 넣어라  

=> 스크립트를 페이지 아래로 이동시킨다는 것은 더 많은 콘텐츠가 점진적인 랜더링을 할 수 있게 만든다는 것을 의미합니다

1) 스크립트를 위에 넣었을 경우 :
http://stevesouders.com/hpws/js-top.php
2) 스크립트를 아래에 넣었을 경우 : http://stevesouders.com/hpws/js-bottom.php
3) 스크립트 위 vs 아래 : http://stevesouders.com/hpws/move-scripts.php

 보통 css와 함께 위에 넣고 쓰지죠? 밑에 넣는것이 더 좋다고 하니 한번 생각해보심이.. ^^
 

규칙 7. CSS Expression을 피하라

=> CSS Expression은 CSS 속성을 동적으로 설정하는 기능이다. 문제는 expression 메소드는 IE에서만 되고 다른 브라우져에서는 무시된다. 웹 표준화니 아예 안쓰는것이 상책입니다 -_-
 

규칙 8. 자바스크립트와 CSS를 외부 파일에 넣어라

=> 규칙 1에서도 얘기했지만 그냥 한번만 다운받는다고 치면 인라인이 더 빠릅니다 헌데 왜 외부로 넣어야 할까요? 그건 캐시가 되기 때문입니다다. 즉 자주 들어가는 페이지는 캐시가 되어야 함으로 외부로 빼는것이 합당하다는것이죠.  그리고 여기서 저자의 멋진 아이디어가 나옵니다 그것은 무엇이냐면 이 둘만의 장점을 모아서~ 인라인으로 뿌리되 만약 캐시에 없다면 element를 인위적으로 생성하는 것이죠 ^^


예제를 보면 바로 이해갈듯 합니다
<script type="text/javascript">
function doOnload() {
  setTimeout ( "downloadComponents()", 1000)
}
window.onload = doOnload;
// 자바스크립트를 이용하여 외부 구성요소를 동적으로 다운로드
function downloadComponents() {
 downloadJS("
http://stevesouders.com/hpws/testsma.js");
 downloadJS(http://stevesouders.com/hpws/testsm.css);
}
}
// 스크립트를 동적으로 다운로드
function downloadJS(url) {
 var elem = document.createElement("script");
 elem.src = url;
document.body.appendChild(elem);
}
// 스타일시트를 동적으로 다운로드
fuction downloadCSS(url) {
 var elem = document.createElement("link");
 elem.rel = "stylesheet";
 elem.type = "text/css";
 elem.href = url;
 document.body.appendChild(elem);
}
</script>

멋지죠?
헌데 보통 외부로 빼는것은 캐시를 쓰기 때문이기도 하지만 유지보수를 위해서라도 따로 빼야합니다. 하나의 jsp에 스크립트와 css가 다 들어가 있으면 토 나오기 쉽상이죠 -_-ㅋ  
 
규칙 9. DNS 조회를 줄여라  

=> 사실 이것은 좀 오버하는 경향이 있는듯 합니다 'ㅜ'; DNS 조회를 줄이기 위해 도메인을 줄이고 서버 아이피를 셋팅하라이겁니다 참고로 IP 주소를 조회하는데 20 ~ 120 ms정도가 소비되니 이것을 줄이기 위해서니깐 제 생각엔 가장 마지막에 해야할 작업이 아닐지 -_-

참고로 이 챕터를 보면서 DNS 캐싱도 있다는 것을 알게 됩니다. 이것은 우리가 쓰는 코넷이나 KT넷의 DNS 서버에서 해당 ip에 대한 캐싱을 해주는 것으로 이것은 우리가 핑할때 나오는 TTL(Time-lo-live) 값과 연관이 있고 이것은 또한 클라이언트에게 얼마나 오래 캐시에 저장할지를 말해줍니다.

ipconfig /displaydns 하면 
dna.naver.com
----------------------------------------
데이터 이름 . . . . . : dna.naver.com
데이터 유형 . . . . . : 1
TTL(Time To Live) . : 282
데이터 길이 . . . . . : 4
섹션 . . . . . . . : 응답
(호스트) 레코드 . . . : 202.131.28.60

kmlocal.alpensiaresort.co.kr
----------------------------------------
데이터 이름 . . . . . : kmlocal.alpensiaresort.co.kr
데이터 유형 . . . . . : 1
TTL(Time To Live) . : 86400
데이터 길이 . . . . . : 4
섹션 . . . . . . . : 응답
(호스트) 레코드 . . . : 127.0.0.1

이렇게 나옴을 알수 있습니다. 참고로 디폴트가 1일이라서 그런지 로컬에서 지정한것은 60*60*24 값임을 알수 있습니다. 네이버는 5분이 채 안되는군요.  참고로 이렇게 지정되어 있는것은 DNS 서버가 설정한 값을 우리 로컬에서 보여준것이고 이런 DNS 캐싱을 브라우져에서도 할수 있습니다

여기서 중요한 것은 keep-Alive 입니다 keep-alive가 1분이면 TCP 연결은 아무런 통신 내용이 없어도 1분까지는 유효하다는 뜻입니다. 즉 이 1분동안은 DNS 조회가 필요하지 않다는 뜻이죠 그러니 불필요한 DNS 조회를 줄일려면 Kepp_Alive를 사용하고 도메인 수를 줄여 DNS 조회수를 줄여야 합니다

규칙 10. 자바스크립트 최소화하라

=> 이것은 규칙 1에서 확장한 내용입니다. 요청을 줄일려면 요청도 적게 해야하고 파일의 사이즈도 줄여야 하니 말이죠. 자바스크립트를 줄이는것에는 크게 두가지 방법이 있습니다

최소화 - 코드의 불필요한 문자를 줄여서 파일 크기를 줄여 로딩 시간을 개선하는 것을 말합니다.

난독화(objfuscation) - 최소화처럼 주석과 공백을 줄여주지만 난독화는 코드 또한 변경하여 알아보기 힘들게 만듭니다

난독화가 더 사이즈를 줄여주긴 하지만 복잡하기 때문에 에러가 발생할 확률이 높고 또한 gzip을 이용하면 최소화나 난독화를 한것이나 같은 비율로 압축이 되기 때문에 저자는 난독화보다는 최소화를 권장하고 있습니다

요즘 jQuery나 Ext-js등 오픈라이브러리등도 다 이름.min.js 처럼 해서 최소화된 javascript를 제공하니 실제 운영시에는 min.js를 이용하면 될것 같습니다

 
일반 스크립트.
jQuery.fn.checkbox = function(options) {
 /* IE < 7.0 background flicker fix */
 if ( jQuery.browser.msie && (parseFloat(jQuery.browser.version) < 7) )
 {
  document.execCommand('BackgroundImageCache', false, true); 
 }
 /* Default settings */
 var settings = {
  cls: 'jquery-checkbox',  /* checkbox  */
  empty: 'empty.png'  /* checkbox  */
 };
최소화된 스크립트

jQuery.fn.checkbox=function(c){if(jQuery.browser.msie&&(parseFloat(jQuery.browser.version)<7)){document.execCommand('BackgroundImageCache',false,true)}

 
최소화 - 더글라스 크록퍼드(Douglas Crockford)
http://crockford.com/javascript/jsmin.html

1) 일반적인 큰 스크립트 - http://stevesouders.com/hpws/js-large-normal.php
2) 최소화한 큰 스크립트 - http://stevesouders.com/hpws/js-large-minify.php
3) 난독화한 큰 스크립트 - http://stevesouders.com/hpws/js-large-obfuscate.php
 

규칙 11. 리다이렉트를 피하라

=> 리다이렉트(redirect)는 사용자를 한 URL에서 다른 URL로 다시 보내는 것을 말합니다. 헌데 이 리다이렉트는 HTML 문서 자체의 다운로드를 지연시키기 때문에 가장 안좋다고 하는군요 저자가 가장 많이 일어나는 것은 주소 뒤에 슬래시(/)빼는 것이라고 합니다. 기존의 주소가 달라서 서버가 알아서 옮겨주는데 정확한 주소가 아니기때문에 301응답과 함께 서버가 /를 붙여서 해당 url로 리다이렉트된다고 합니다. 음 뭐 그렇다고 안 쓸수는 없으니 최소한으로 써야겠습니다

 
규칙 12. 중복되는 스크립트를 제거하라

=> 이건 뭐 당연히 중복시키면 안되겠죠 가뜩이나 지금 있는것도 줄이는 판국에 ㅎㅎ. 실수로 외부에서 가져오고 있는데 인라인으로 호출하고 있을지도 모르니 항상 체크해보아야 하겠습니다.

 
규칙 13. ETag를 설정하라

=>  ETag(Entity Tag)는 웹 서버와 브라우져가 캐시된 구성요소의 유효성을 확인하기 위해서 사용하는 매커니즘입니다. 브라우저의 캐시에 저장되어 있는 구성요소와 원본 서버의 구성요소가 일치하는 판단하는 또 다른 방법이죠 HTML/1.1에 새롭게 추가되었는데요 ETag는 구성요소의 특정 버전을 나타내는 고유한 문자열로 이루어집니다.

이런 복잡한것은 안쓰는것이 상책이죠! -_-

 
규칙 14. 캐시를 지원하는 Ajax 만들기

=> 속도를 빠르게 하는데 Ajax라고 빠질 수 있을까요? ㅎㅎ

저자는 Ajax 응답에 캐시를 적용하는데에는 퀴리 스트링의 파라미터를 이용하는 것이 최선의 방법이라고 말합니다. 만약 캐시를 쓰지 않는다고 하면 기존의 규칙중에서 응답을 압축하거나 DNS 조회를 최소화하거나 스크립트를 최소화하거나 하는 기존의 규칙을 잘 지켜달라고 말하고 있습니다.

 
웹 개발자라면 한번쯤 읽어 볼만한 책인것 같습니다. ^^

책 분량이 얼마 안되서 부담도 되지 않고

또한 책의 마지막에 미국 상위 10개 사이트에 대해서 속도 개선에 대해 분석을 는것도 좋네요

 
유용한 URL
저자가 만든것 같은데요 기존 책에 잇는 내용보다 살이 더 많이 붙어있네요.^^
http://developer.yahoo.com/performance/rules.html
 

유용한 툴
1. IE watch라고 Http요청을 보여주는 것이 있습니다. 쉐어웨어버전이니 알아서 잘~ 쓰세용
=> 
http://file.naver.com/pc/view.html?fnum=220668&cat=60
(접속사이트의 파일 상세정보를 보여주는 "IEWatch" v5.0.0.5 Professional)

2.  Http 패킷 분석 툴. HTML문서와 관련된 HTTP 요청을 보여주고 HTTP 차트는 구성요소 다운로드에서 생기는 병목지점을 쉽게 확인
http://alphaworks.ibm.com/tech/pagedetailer

3. 유용한툴을 모아둔 포스팅이 있네요 ^^
http://xmlangel.blogspot.com/2009/02/blog-post.html


 
 
 
회사가 붙잡는 사람들의 1% 비밀 
신현만 지음 / 위즈덤하우스 / 2009년 2월
평점 :
장바구니담기


동저자의 입사 후 3년을 상당히 재미있게 읽었던 터라  책이 나왔다고 해서 서슴없이 구입.
서점에서 열심히 밀어주고 있는것 보니 이기는 습관처럼 베스트셀러를 만들려고 판단.

책을 다 읽고 난 느낌은 기존의 책들과는 다른 느낌이다
다른 책들이 어느 정도 실력을 쌓으면 이직해야겠다라는 생각이 들었다면
이 책은 지금 직장에서 내가 최선을 다해봐야겠다는 생각이 들었다.

1%비밀 무엇이냐?
노력과 열정은 기본으로 상사의 비위를 잘 맞추고 아랫사람 잘 이루어주는 것.

그리고 깨달아야 할것은 무엇이냐?
연봉과 삶의 균형은 같이 가져 갈 수 없다.
(GE의 잭 윌치도.. 이혼해서 나중에 다른 분과 결혼하지 않았느냐)
돈 많이 받고 싶으면 야근 빡세게 하고 군말말고 일 열심히 하고~
삶의 균형을 지키고 싶으면 주는대로 받고 살아라 이거다.
돈도 많이 받으면서.. 삶의 균형도 지키고 싶다? 어림반푼이라 이거다.

학벌이 부족하면 어떡해야 하나?
사실 이 부분이 개인적으로 보고 싶었다. 지방대 출신으로 이 험난한 IT라는 곳에서 살아갈라면 영어나 학벌 둘중에 하나는 가지고 있어야 할것 같은데..  이걸 어떻게 메꿀수 있을까라는 생각이 계속 가지고 있었기 때문에.
저자는 단호히 말한다. 학벌에 신경 쓸바에는 이 악물고 영어와 희소성있는 자격증에 도전하라고.
어차피 지금 대학을 다시 나올 수도 없고 대학원 간다고 해도 석사정도면 별로 쳐주지도 않을테고..
그 열정으로 영어의 달인이 되고 또한 자신과 관계되는 자격증을 따라는 거다.
우리 IT계에서 가장 희소성있고 따기 어렵다면.. 아무래도 기술사! 바로 이거닷!
이 부분은 나에게 새로운 관점을 제시해주었고 이것이 별 5개를 주는 이유다. -_-
 
리더십은 어떻게 키우나?
배려와 희생이다. 닥치고 후배에게 양보하고 배려해라.
내가 팀장이니 넌 내 뜻대로 해야돼? 이런 군대식 마인드는 군대에서나 쓰시구요
팀원이 무엇을 원하는지 그것을 빨리 캐치해서 도와주는 일을 해주어야 한다.
팀원들의 평가목표 보단 학습목표에 더 신경쓰고 말이지(지혜롭게 일하는 직장인 심리학)

회사에서 성공할려면?
뽑을땐 학벌이지만 뽑고나면 충성도다.
회사에 충성을 다하라~ CEO처럼 일하고~
평론가처럼 옆에서 말로 다할려고 말고 실제 발로 뛰어라. 해결사만이 성공 할 수 있다
그리고 회사가 흔들리면 기회가 온다. 실력이 있어야 그 기회를 잘 활용할 수 있다.
한신처럼 꾸준히 실력을 쌓아놓자. 낭중지추.
그리고 결혼식이나 초상집, 회식, 위크샵 이런곳 빠지지 마라. 거기서 인간관계가 시작된다.

이직은 어떻게?
임원 가능성이 희박하면 부장이 되기 전에 옮겨야 한다
이직에 가장 좋은 직급은 과장이다. 입사 10년이면 더 이상 배울것이 없지 않겠는가?
과장급 지나고 나면.. 좋은 세월 다 가는거다 -_-
박수 칠때 떠나야 한다. 이것은 모든 캐리어관련 책들이 말해주고 있다.
인정받고 있을때 떠나야 서로 좋은거라고.
이직은 평생 2-3번이 적당하다고 한다. 너무 많으면 기업이 싫어한단다.
이직하기전에.. 회사에 충성을 다해 임원이 되는것을 노려보는 어떻까?
참고로 이직할때에는 회사의 브랜드를 보라. 연봉보단 직급, 직책에 신경을 더 쓰고.

좋은 책이다. 이 책을 읽고 난 나의 아끼는 동료들을 위해 4권을 구입했고 오늘 한권을 더 구입할 예정이다.
책이 너무 좋아 여러사람에게 알리고 싶고 권해 주고 싶다. ^^

성공하고 싶은가? 이책의 부제는 이거다.
"내가 직장 1년차에 이 책을 봤더라면 CEO가 되었을 것이다"
다 보고 나니 고개가 절로 끄덕여졌다. ^^


 
 
 
우리들의 행복한 시간 
공지영 지음 / 푸른숲 / 2005년 4월
평점 :
구판절판


여기엔 슬픈 사람들이 나온다.

집행일이 언제인지 모르고 기다리는 사형수인 한 남자.

어렸을때 나쁜 추억으로 인해 사는게 사는게 아닌 한 여자.

그 두 사람은 서로 세상 때문에 자신들이 불행하게 되었다고 생각했으나

결국엔 자신의 시선으로 그렇게 된것이 아닌가 서로 반성하며 새로운 관점으로 세상을 바라보게 된다.

왜 둘이 만나게 되었고 왜 그런 생각의 전환을 하게 되었는지는 글쎄.. 우연이라고 해두자.

우리는 누구나가 자신만의 고만고만한 슬픔을 지니고 산다.

그래서 부자 혹은 너무 잘난 사람들은 슬픔이 없을것 같지만 그들도 슬픔앞에서는 모두 공평하다고 말을 한다.

그 슬픔이.. 아무리 상대적인 가치로 별거 아닌것 같아 보여도 말이다.

책을 보며서 나 또한 사랑에 많이 굶주려 있다는 생각을 하게 되었다.

마음을 터 놓을 수 있는 친구, 고민을 상담할 수 있는 지인, 사랑한다고 말할 수 있는 그녀는 없지만 -_-a 여하튼 여러 좋은 분들이 내 주위를 포진하고 있지만 난 여전히 사랑에 굶주려 있다는 생각을 하게 되었다. 아니다. 어쩜 난 사랑에 굶주려 있는 것이 아니라 베품에 굶주려 있는지도 모르겠다.

언제나 받기에 익숙한 우리네들이.. 주기에 인색한 것처럼..

 

나 또한 곧 얼마후에 죽을 것이라면.. 세상을 달리 볼 수 있을까?

나에게 해를 입히고 나를 욕하던 이들을 나 또한 그 어렵고 어렵다는 용서를 할 수 있을까?

이에는 이 눈에는 눈. 그것이 옳다고 교육을 받아온 나는 과연 용서라는 크나큰 용기를 베풀 관용이 있을까?

책을 읽으면서 이러한 고민은 더욱 커져만 갔다.

"목사나 신부나 수녀나 스님이나 선생이나 아무튼 우리가 훌륭하다고 생각하는 사람들 중에 위선자들 참 많아. 어쩌면 내가 그 대표적 인물일지도 모르지...... 위선을 행한다는 것은 적어도 선한게 뭔지 감은 잡고 있는 거야. 깊은 내면에서 그들은 자기들이 보여지는 것만큼 훌륭하지 못한다는 걸알아. 의식하든 안 하든 말이야. 그래서 고모는 그런 사람들 안 싫어해. 죽는 날까지 자기 자신 이외에 아무에게도 자기가 위선자라는 걸 들키지 않음녀 그건 성공한 인생이라고 생각해. 고모가 정말 싫어하는 사람은 위악을 떠는 사람들이야. 그들은 남에게 악한 짓을 하면서 실은 자기네들이 실은 어느 정도는 선하다고 생각하고 있어. 위악을 떠는 그 순간에도 남들이 실은 자기들의 속마음이 착하다는 것을 알아주기를 바래. 그 사람들은 실은 위선자들보다 더 거만하고 더 가엾어......"

위선보다 더 나쁜것은 위악이란 말.

이 말이 책을 덮은 후에도 계속 귓가에 맴돈다.

ps

끝으로 이 책이 베스트 셀러라는 것을 보니 아직 우리나라는 따뜻한 것 같다.



 
 
 
처음 처음 | 이전 이전 | 1 | 2 | 3 | 4 | 5 | 다음 다음 | 마지막 마지막