MS에서 프로젝트 복잡성을 해결하기 위해서 개발도구 + 프로젝트 관리 도구를 포함한 제품을 출시했다.

보통 대형조직에서 의사결정과 의사소통이 어려운 편이다. 특히 말없이 작업하는 사람들에게 관리자가 일일히 체크하기도 힘들고, 역시 관리자에게는 항상 중요한 일정관리라는 관리포인트가 존재하기 때문에 일정이 현재 어느정도까지 왔는지 보면 상당히 좋을 수 있다.

또한, 문서작업용으로 잘 쓰는 엑셀을 통해서 관리자가 관리를 쉬울 수 있도록 해야 했었다.
여러가지 사용하고 있는 개발 툴과 1-n의 의사소통 문제로 개발 생산성은 떨어지고, 프로젝트의 관리는 어렵게 되었다.

이에 MS는 비주얼 스튜디오 팀 파운데이션 서버는 작업관리, 형상관리, 빌드 자동화, 프로젝트 관리 지원을 지원한다. 기존의 비주얼 소스 세이프 및 프로젝트 서버는 존해했었지만, 통합되진 않았다.
이를 자연스럽게 통합하여 어플리케이션 수명주기 관리를 지원 도구를 하나의 환경으로 통합하였다.
엑셀과 프로젝트로 연결이 되고, XML로 변환될 수 있고, SQL 서버와 연동이 쉽게 되며, 형상관리와 리포팅 기능이 제공되었으며, 매니저에게 현재 프로젝트의 상황을 보여줄 수 있도록 하였다.

장점
1. 개발 프로세스 전반에 걸친 커뮤니케이션과 협업의 가치 증대
2. 검증된 베스트 프랙티스와 방법론의 적용
3. 프로젝트 전반에 걸친 통찰론과 가시성 제공
4. 상대적으로 낮은 설치/운영/관리 비용
(위의 장점은 2006년 2월 마소에서 가져왔음)

단점
1. 높은 비용
2. 특정 운영체제와 특정 언어, 특정 DB와 결부
3. 다른 툴과의 결합하기 어려움

MS에서 이렇게 새롭게 시도하고 있는 모습에는 찬사를 보내며, 앞으로 많은 이들이 사용될꺼라 믿는다. GNU 쪽에서도 먼가 당찬 계획을 세울 수 있겠지만, 역시 표준화 문제가 존재하고, 이를 합치는 문제가 있다.
또한 현실의 프로젝트는 항상 하나의 툴로 다 표현하기 힘든 부분이 있다라는 사실이다. 개인적인 선호도 존재하고..

MS의 정책! 멋지다!

정보과학회논문지: 데이터베이스 32권 2호 (2005.4) - 김성진, 이상호

이 논문은 유명사이트 집합과 임의사이트 집합에 속한 웹 문서들을 100일동안 주기적으로 수집하여 변경 경향을 관찰하고 그 실험결과를 내어 뤱 로봇의 운용에 도움이 되도록 관찰연구지이다.

성공적으로 다운로드된 URL은 여전히 잘 다운로드되고, 내용의 변경이 없던 문서는 여전히 현재 상태를 유지하는 것으로 나타났다. 절반정도들이 규칙적으로 변경이 된다. 웹 데이터 베이스의 freshness을 높이기 위해서는 이런 확률적 수식을 통해서 알 수 있다.

웹 문서의 주기별로 자주 바뀌는 것이 반정도, 안바뀌는 것이 반정도 있으며, 바뀌는 것은 주기가 있기 까닭에 웹 로봇의 변화 분석이 필요하다. 웹 문서 변화에 대한 잘못된 예측, 판단으로 인하여 발생할 수 있는 커버리지 손실에 대한 연구가 필요하라는 것이 논문의 주요 요지이다.

DMB 방송에서는 BWS라 하여 방송사에서 웹 컨텐츠를 전송할 때 무작정 보내는 것보다는 dynamic 컨텐츠는 따로, static 컨텐츠는 따로 전송하여 실시간으로 구분하여 전송하면 수신기단에서 파일이 바뀐 dynmaic 컨텐츠만 변경된 것으로 판단하여 잘 보는 게 중요하다.

이 논문을 본다면, 생산자-소비자 : 웹문서 - 웹로봇 : BWS 송출 - BWS 수신 으로 확장할 수 있으며, BWS 송출이 자주 변경되는 것과 변경되지 않는 것으로 구분하여 전송이 되는 것에 대해서 따로 따로 전송이 되어야 함에도 불구하고 이런 나누어서 전송하는 방법은 현재까지 존재하지 않는다.

파일 전송에 대한 스케쥴링도 전혀 생각치 않되어 있기 까닭에 이런 부분이 필요하다.
수신기는 따로 따로 전송되는 파일들을 분석하여 항상 freshness정보를 얻을 수 있으며, 사용자의 만족을 극대화 할 수 있는 장점이 있을 것이다.

http://kangcom.com/common/bbs_review/bbs_read.asp?seqid=3164&fst_code=

http://www.devpia.com/forum/BoardView.aspx?no=958&ref=958&page=1&forumname=and_free&stype=
http://occam.n4gate.com/tt/index.php
http://www.artima.com/lejava/articles/designprinciplesP.html


위의 링크는 GoF의 디자인 패턴에서 나오는 문구 'Favor object composition over class inheritance. '에 대한 토론의 글이다. 번역자와 독자간의 번역에 대한 인식차이로 시작된 이 문구의 이해가 이 상황을 알고 있는 사람들에게 엄청난 이해도를 높였다.

즉, 'Favor A over B' 라는 숙어의 의미와 'over A'의 A 기반이라는 뜻의 의미가 모호해지면서 나름대로 토론이 되었다. 객체의 상속기반위의 상속을 선호하다 라는 의미인지, 클래스 상속대신 객체의 합성을 선호하라, 또는 더 낫다 라는 세 의미가 수반되는 모호한 의미를 가지게 되었다

inheritace가 inteface inheritace와 class inheritance의 두 의미로 나눠지게 되는 의미는 당시 GoF가 C++의 영향을 많이 받았다는 사실을 인지했어야 한다. 70-80년대에서 객체지향의 개념이 널리 알려지게 되고, 프로그래머들이 상속을 너무 남발하던 차에 GoF가 디자인패턴을 발표하였다.

C++을 기반으로 하는 GoF의 디자인 패턴이기 때문에 class나 interface의 모호한 상속이 GoF에게 영향을 미쳤고, 후에 자바에도 큰 영향을 미쳤으리라 생각이 된다. 자바처럼 interface와 class가 명확하게 나누어져 있기 까닭에 subclassing, subtyping이라는 상속개념이 명확했더라면, 지금처럼 토론이 되지 않을 수도 있다.

하여튼, 결론은 GoF의 디자인 패턴의 문구가 당시로서는 맞는 말이지만, 자바나 파이썬, 루비 객체 지향의 다양한 언어가 사용에 타이밍적으로 모호한 문구가 될 소지가 있음을 잘 발견하였고, 서로 유익한 정보들을 나누었으리라 생각이 된다.

임베디드 시스템 개발시 자주 할 수 있는 실수를 엮어보았다.
너무나 먼 하수의 길일런지~^^

#1 표준 문서의 내용에 대한 오해
개발시 가장 중요한 부분이다. 표준 문서, 또는 요구사항에 대해서 잘 못 이해하고 있는 부분은 치명적인 아픔(?)을 낳게 한다.
오해로 인해서 개발이 늦춰지게 되거나, 잘못된 인퍼페이스에 의해 디펀던스가 있는 주위 동료들에게 많은 폐를 끼치게 된다.
선임자 혹은 스펙을 이해한 사람에게 확인해 볼 수 있어야 한다.

#2 비동기 메소드 처리
비동시 메소드 처리시는 항상 메모리 릭이 없도록 해야 한다.

예를 들자면, 파일을 읽기 위해서, mount를 하고, 해당 파일 핸들에 대한 파일을 요청을 한다.
요청에 대한 callback을 처리하고 나는 것로 끝내는 것이 아니라, 각 단계에 대한 여러 시나리오를 생각해 볼 수 있어야 한다.
파일 요청에 대한 어플리케이션이 mount만 하고 종료할 수 있으며, callback이 불려지기 전에 어플리케이션이 종료할 수 있다.
여러 시나리오에 대해서 처리가 가능하도록 해야 한다.
즉, 어플리케이션 종료시에 대한 destroy를 염두하면서, 잘 못 생각하거나, 생각하지 못한 것에 대해서 메모리 릭이 생길 수 있는 소지는 항상 염두해야 한다.

#3 잘못 쓰인 주석
잘못된 주석, 과거에 사용되었던 코드가 불필요하게 남아있으면 안된다.
사람은 기본적으로 망각의 동물이라, 쉽게 잊기도 한다. 그래서 주석이 반드시 필요하다.
하지만, 원 의미가 변경된 경우에는 반드시 주석을 삭제하는 것이 중요하다.
또한 변경된 소스가 나중에 필요하지 않을 경우는 반드시 지울 수 있도록 한다.

#4 비적절한 naming convention.
올바르지 못한 naming 변수는 개발자 본인에게나 인수인계자에게 두려움을 줄 수 있다.
변수 이름만으로 변수의 symantics를 알지 못하고 다른 symantics로 이해한다면, 개발자 본인이 아닌 다른 이에게 잘못된 생각을 심어줄 수 있으며, 코드의 readibility가 떨어지게 된다.
시간을 들여서라도 변수의 설명이 되는 적절한 이름을 가질 수 있도록 한다.

#5 복잡한 코딩
복잡한 코딩은 혼자만 알게 하고, 인수인계자에게는 상당히 난해함을 전달할 수 있으므로 복잡성을 낮춰야 한다.
readibility가 좋아야 한다. 요즘 나온 모든 c 컴파일러는 optimizer를 포함하고 있기 때문에 걱정하지 않아도 된다.
int port;
while(port = getPort()) {
   if (port < 0) {
       break;
   }
}
보다는 다음의 코드가 훨씬 보기가 편하다.

int port;
for ( ; ; ) {
   port = getPort();
   if (port < 0) {
       break;
   }
}

#6 불필요한 코드
자바의 경우는 쓰지 않는 패키지를 import하지 않도록 하며, c언어의 경우는 쓰지 않는 header를 include하지 않는다.
또한 쓰지 않는 메소드나 함수는 오버헤드이다. 현재도 쓰지 않고, 앞으로 쓰지 않을 것이라면, 과감히 지워라. 코드는 심플한 것이 아름답다.

#7 로마에 가면 로마의 법을 따른다.
해당 프로젝트에서 정한 coding convention 및 naming convention은 지키도록 한다.
80 컬럼을 지키는 것이나, identation은 정신적인 건강을 제공하며 코드가 오랫동안 살 수 있다.
이외에도 아키텍트가 정한 룰은 반드시 지킬 수 있도록 한다. 싸우면 피곤해 진다.

#8 tribary statement 문 사용
if문대신 tribary statment 문 이용하여 코드를 최대한 줄인다. 물론 이는 readibility를 기준으로 한다.
복잡스러운 tribary statement는 절대로 쓰지 마라!

#9 체크 습관
해당 함수의 아규먼트는 타입 혹은 값이 절대적일 수 없다. 잘못된 값은 언제든지 들어 올 수 있으므로 null 체크와 길이 체크는 항상해야 한다.
if (l == null || l.length == 0) { 
   throw new IOException("Wrong Paramter");
}

 

http://bbs.kldp.org/viewtopic.php?t=69993&postdays=0&postorder=asc&highlight=void+%2Athis&start=40

요즘 KLDP에서 C를 C++처럼 사용하는 법에 대해서 토론중이다.
(OOP, 프레임웍, 패턴이라는 단어들이 사용하면서 긴장을 풀고 살았다라는 생각이 드는 것은 무엇일런지..
초심의 마음으로 다시 접근해야 겠다.)



#include <stdio.h>

struct _my_str;

void inc_one(struct _my_str *);
void dec_one(struct _my_str *);

typedef void (*void_func) (struct _my_str *);

typedef struct _my_str {
   int iLen;
   void_func inc;
   void_func dec;
} my_str;

my_str* init_my_str() {
   my_str *new_my_str = (my_str*) malloc (sizeof(my_str));
   new_my_str->iLen = 0;
   new_my_str->inc = &inc_one;
   new_my_str->dec = &dec_one;
   return new_my_str;
}

void inc_one(my_str *my) {
   my->iLen++;
}

void dec_one(my_str *my) {
   my->iLen--;
}

main() {
   my_str *a = init_my_str();
   printf("a->iLen = %d\n", a->iLen);
   a->inc(a);
   printf("a->iLen = %d\n", a->iLen);
}

함수포인터를 이용하여 구현한 것으로서, 자신의 객체를 내부에서 구현하고 참조하는 C++, java의 실제 내부 구현이기도 하다.
전역변수를 쓰지 않음으로서 메모리를 아끼고, 마치 객체처럼 편리하게 쓰일 수 있다. OOP의 encapsulation처럼 쓰일 수 있는 장점이 있다. 물론 structure의 변수들을 모두 접근한다는 부분이 걸리지만 말이다.
 
Herb Sutter 님의 Exceptional C++ 에서는 다음과 같이 c를 이용하여 OOP의 편리함을 이용하고 있다.

List of "foo.c" :

코드:

#include "bar.h" int main() {  BAR *bar = create_bar();  use_bar(bar);  remove_bar(bar);  return 0; }

List of "bar.c" :

코드:

#include "bar.h" struct BAR_ { int somedata1; int somedata2; void *memory; }; typedef struct BAR_ BAR; BAR *create_bar() { static BAR b; return &b; } void use_bar(BAR *) {  } void remove_bar(BAR *) { }

List of "bar.h" :

코드:

struct BAR_; struct BAR_ *create_bar(); void use_bar(struct BAR_ *); void remove_bar(struct BAR_ *);

2번까지 하면 다 될 줄 알았는데, 역시 그렇지 않다.
생전 처음하는 시스템 요구사항은 쉽게 만들어 지지 않는다.

사고의 전환을 잘 생각해야 한다. 즉 3차원적인 관점에서 보는 사고가 필요하다.
Layered Architecture를 생각해 보자. 벽돌이 층층이 쌓인 부분으로 이루어진 아키텍터를 3차원으로 봐야 한다.

1. 수직으로 보는 관점이 필요하다.
Dependent 모듈을 수직으로 세워서 층을 이루도록 한다.

2. 수평으로 보는 관점이 필요하다.
Service 관점에서 보며 수직으로 보는 모듈이 아닌 평등적인 관계가 무엇인지 바라본다.

3. 비지니스 관점이 필요하다.
바로 얘기하고자 하려는 부분이다.수직, 수평의 기술자가 보는 관점이 전부가 아니라는 사실을 잘 알아야 한다. 아무리 좋은 제품을 만들려 해도, 제품성을 가질 수 있는 비즈니스 관점을 잘 판단해야 한다.
모든 컴포넌트 모듈을 하나의 하드웨어에서 사용될 수 있다. 하지만 모든 제품을 하나의 하드웨어로 할 수 없는 이유는 성능이라고 많이 생각할 수 있겠지만, 꼭 그런 것만은 아니다.
때론 하드웨어와 소프트웨어를 잘 분리함으로서 얻는 비지니스 관점을 잘 알아야 함이다.

이중화 솔류션을 추가할 수 있을 수도 있고, 영업적인 관점에서 추가될 수 있는 부분을 잘 이해하고 요구사항에 반영하면 아주 좋을 것이다.

프로젝트의 성과를 위해서는 관리가 가장 중요하다.
프로젝트의 실패 이유는 일정의 지연, 비용 초과, 기대 효과에 대한 불만족이며, 이중 일정의 지연이 가장 높은 이유라고 한다. 하지만, PMO를 도입하면 성공률이 반정도로 높아진다는 사실이다.

PMO는 강력한 리더십, 목표 설정 및 정의, 일정 설정, 책임 설정, 이슈, 변경관리, 품질관리 등을 이끌 능력이 있어야 성공률이 높다고 하겠다. 좋은 말로 하면, 프로세스 절차, 통제가 잘 되는 것이 중요하다.
적절한 지원, 리더쉽, 원만한 대인관계, 정확한 분석 능력, 모니터링, 멘토링을 통해 프로젝트의 개발이 성공적으로 될 수 있도록 조직에서는 힘을 실어주어야 한다.

소프트웨어를 개발하는 이유는 오직 두가지이다.

세상에서 없는 것을 개발하는 것, 세상에 나와있는 것보다는 훨씬 성능이 좋은 소프트웨어를 개발하는 것이다.
특정 일을 해야하는 시스템이 구체화되기 위해서는 소프트웨어의 상세 요구사항을 발견하고 목록화해야 한다.

1. 개발하고자 하는 소프트웨어와 비슷한 소프트웨어의 벤치마크를 한다.
  SWOT및 경쟁력이 된다면 개발에 착수한다.
2. 해당 시스템이 당연히 해야할 일을 구체화 한다.
3. 점차 모듈로 구분한다.
4. 모듈의 업무를 세분화하여 요구사항으로 잘 나타낸다.
5. 각 모듈의 interface를 생각하여 요구사항으로 나타낸다.

위의 내용은 Top-down 식 디자인 방법이다. 개인적으로 주로 이 방법을 사용했었다.
하지만, 그 반대의 경우인 Bottom-up 식 디자인 방법이 필요하기도 한다.

하드웨어를 서버에 장착할 수도 있고, 표준문서 입장에서 보는 경우도 있다.
그럴 때에는 아래에서 위로 보는 관점을 가지는 것이 좋다.
본인은 일 자체가 규격문서 위주로 되어 있기 까닭에 규격문서를 위주로 요구사항을 정리하였다.
거의 low-level이기 까닭에 모듈의 세부 요구사항으로 정리가 될 수 있겠다.

하지만, 이것으로 만족스럽지 않다.

바로 고객(사용자)가 사용할 때의 시나리오를 통해서 요구사항을 보완해야 한다.

사용자가 어떻게 사용할 수 있는지 어떤 방법으로 접근하면 좋을 지를 잘 생각해 내고, 이러한 Iterative Thinking & Consideration을 잘 염두하면서 디자인의 첫번째 요소 요구사항을 잘 뽑는 것이 중요하다.

이런 과정을 통해서 설계 작업에 들어가게 될 때 큰 뼈대가 될 수 있다.

요구사항을 뽑아내는 일은 결코 쉽지 않다. 시스템의 중점 아이템을 꺼집어 내어 지금까지 나왔던 자사 및 모든 경쟁 제품보다 훨씬 뛰어난 제품을 만들어야 하는 요구사항을 뽑아내야 하기 때문이다.
지난번 요구사항을 파악하기 첫번째에 이어서 요구사항 파악하기 두번째를 써보게 되었다.

사용자 시나리오나 기능성을 기반으로 하는 모듈을 분리하여 요구사항을 얻어 내는 것만으로는 완벽히(!) 부족하다.
모듈단위의 기능을 파악하는 것 외에 무엇을 생각해야 하는가?

1. 완성된 컴포넌트 모듈은 자주 바뀌는 가? 아니면, 한 번 만들어지면 계속 바뀌지 않는가? 에 대한 깊은 고민이 필요하다. 모듈의 타입에 따라 유지 보수할 때 유지 보수성을 생각하며 깊게 생각해야 되는 부분이 존재한다.

소프트웨어의 생명 주기중 가장 긴 부분이 "유지보수"라는 것을 잘 생각해야 한다. 소프트웨어의 생명은  "디자인", "개발", "유지보수"라고 하는 큰 3단계의 단계가 있는데, 이의 비용(시간 포함) 비율은 3:2:5 라고 생각한다. 그만큼 유지보수적인 부분이 굉장히 소요되기 까닭에 디자인단계에서 잘 생각하여 유지보수의 비용을 최대한 낮추는 설계방법을 가져야 한다.
디자인이 한 번 잘 못되면, 시스템의 변경이 필요해지고, 변경에 따른 비용, 변경을 하지 않아서 생기는 비용을 잘 염두해야 한다. 컴포넌트 모듈중 static, dynamic한 부분을 잘 나누어 본다. 컴포넌트 모듈의 input, output을 잘 생각한다. 각 컴포넌트의 모듈의 연관(아직 기능적인 모듈간의 인터페이스만 생각!)을 머리 속에 그리며, input과 output의 고민을 잘 해야 한다.

시스템에서 가장 많이 사용될, 아니 상용화될 때 가장 많이 바뀌는 부분은 신경을 써서 요구사항을 잘 파악하는 것이 중요하다. 20:80의 이론처럼 전체 시스템의 20%는 전체 프로젝트의 80%를 차지하고 있다는 것을 염두해야 한다.

보통 데이터를 동적으로 받아서 처리하는 부분을 프로퍼티, XML형태로 받아들 일 수 있도록 해야 하며, 네트웍인 경우는 Push인지 Pull방식이 좋을지 고민을 잘 해야 한다.

2. 네트웍 환경에 맞는 모듈 설계를 고려해야 한다.
Closed  네트웍을 사용해야만 하는 경우도 존재하므로, 네트웍 환경까지 생각할 필요성이 있다.
public ip를 받지 못하는 환경을 쓸 수 있는 네트웍 환경이 주어지는 경우가 존재 할 수 있다. 그 가능성에 대해서 염두할 필요성이 있다.

특히 방송환경은 네트웍 환경에 맞는 요구사항을 파악하는 것이 중요하다. 방송 서버는 Closed 망을 쓰기 까닭에 바깥으로 패킷은 허용될 수 있으나, 들어오는 패킷은 막는 형태로 되어 있다. 그런 부분까지도 잘 감안해서 요구사항을 뽑아내야 한다.

요구사항을 뽑아내는 것은 무척 어려운 일이다. 즉 대략 설계를 들어가지 않는 다고 하지만, 설계를 염두하지 않은 요구사항은 프로젝트에 큰 영향을 끼치기 까닭에, 요구사항을 단순한 부분이 아닌, 설계를 염두한 세부 요구사항까지 파악할 필요가 있다.

집중해서 읽으면 금새 다 볼 수 있었는데도 천천히 읽혀 지더라구요. 리더의 고민, 리더로서 어떤 길을 가야 할 지, 리더의 책임, 리더로서 해주고 싶은 말들.. 꼭 제가 잘 아는 선배나 형이 알려 주는 것 같습니다.
나는 책을 통해서 인생의 한 선배를 다시 한 번 보게 되었습니다.

이 책을 읽은 이유는 책 표지 뒤의 안철수씨가 쓴 '기업의 목표'를 읽게 된 이유입니다. 저는 그 문구에 멍청난 충격을 받았습니다.

제가 한 서점에서 아르바이트를 할 때였습니다. 사장님 아들이 사장님, 직원, 아르바이트생을 모두 모아놓고 이런 말을 하였습니다. "우리 서점의 목표가 무엇이냐?" 저는 이렇게 말했습니다. "사회의 기여입니다. 책을 고객에게 파는 것이 아니라 친구와 선배를 그들에게 알려 주는 것입니다." 라고 말을 했더니, 사장님 아들이 "우리는 이윤을 추구하는 것이 목표야"하며 엄청 혼난 적이 있습니다. 그 옆에 계신 사장님도 맞다며 고개를 위 아래로 끄덕이며 맞다고 하시더군요. 저는 그 이후로 모든 기업과 상점은 모두 이윤추구가 최고의 목적이라고 생각해 왔습니다. 한번도 사회에 공헌하는 것은 말뿐인 허울이라고 생각해 왔습니다. 그냥 선전이며 위선이라고 생각했었습니다.

"CEO 안철수, 지금 우리에게 필요한 것은"에서 안철수씨는 기업의 존재의미에 충실하는 것이 그 목표라고 했습니다. 사회에 기여하는 것 자체에 보람을 느끼는 구성원이 모여 공동작업하는 것이 기업의 존재 의미라고 하였습니다. 이윤은 자연스럽게 따라온다고 생각한다며, 이윤추구가 목적이 되면 안된다고 했습니다.

우리 사회를 한 번 둘러봐 주십시요. 돈 버는 것이 잘 못된 것은 아니지만, 과연 정당하게 사회에 기여하면서 돈 버는 사람이 있나 돌아봐 주십시요. 어떻게 하면 사행성을 조장하여, 음성적인 것을 이용해서 돈을 벌 수 있을까 고민하는 사람들 잊지 않습니까? 아니, 저부터 그런 생각을 까닭인지 약간은 우울합니다.

하지만, 이 책을 통해서 많이 부끄러웠는지 모릅니다. 자신이 깨끗하게 자신의 펜으로 기업의 목표를 사회에 기여하는 것을 최우선 가치에 두고 있는 안철수씨를 존경하게 되었습니다. (이전에 그 분의 책을 읽었지만, 존경까지는 가지 않았습니다. 정말 존경스럽더군요. 한 개발자 아닌 선배로..)

조직문화를 제대로 세우고, 조직의 위부터 아래까지 의사 소통이 잘 되기 위해서, 개인의 이익보다는 조직의 우선을 최우선하며 조직의 역할을 감당하기 위해서 조직의 리더가 해야하는 책임과 임무, 조직 구성원이 해야하는 책임과 임무에 대해서 잘 알게 되었고, 지금의 제가 느끼는 조직문화의 중요성을 다시 한번 깨닫게 되었습니다.

올바른 양방향 커뮤니케이션, 원칙과 본질의 충실, 존중과 배려, 목표에 대한 치열함을 최고의 미덕으로 가지는 안철수씨의 의견에 공감을 하며, 저도 원칙과 본질에 충실하고 존중하고 배려하며 커뮤니케이션을 잘 할 수 있도록 최선을 다하며 치열한 노력을 다할 것입니다. 특히 조직문화에 대한 배움은 상당히 컸습니다. 조직문화를 잘 다루는 그런 리더를 꿈꾸어 봅니다.

http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200412160001#0