Reference

마소 2006년 2월 다시 생각해 보는 오픈소스 개발요인
Does Open Source Matter? (http://www.artima.com/forums/flat.jsp?forum=270&thread=149874)
Geir Magnusson on Geronimo, Harmony, Open Source (http://www.artima.com/weblogs/viewpost.jsp?thread=68447, http://mises.org/fullstory.aspx?control=1595)
Free Can Mean Big Money: The Open Source Economy(http://www.osnews.com/story.php?news_id=8054)

오픈 소스의 개발 동기는 대부분 "Just For Fun"이다. 우리 나라에서는 많이 활발하지 않지만, (이건 어디까지 지원여부이다. 쓰는 것은 거의 세계 수준이지 않을까 생각이 든다.) 외국에서는 잘 발달 되어 있다.

저작권 및 기부금 문화가 발달되어 있는 서양의 경우는 거리에서 음악을 연주하면 그 연주 비용중 일부를 저작권 단체에 기부한다고 한다. 또한 IT업체의 경우는 IT재단에 기부하거나, 이름이 새겨진 악세사리(음반, 도서, 옷등)를 팔아 그 수익금으로 IT업체의 수입을 충당하고 있다.

하지만, 이런 수입이 없는 경우 "Just For Fun"의 경우의 오픈소스 프로젝트는 1년이 안되서 더이상 패치가 없는 경우가 흔하다. 이런 경우를 쓰는 개발자는 쓰다가 패치가 안된 오픈소스를 향해 "Shit"이라는 단어를 사용하여 화를 내고 오픈 소스에 대한 전체적으로 불신하는 마인드를 갖고는 한다.


제품이라고 불리울 수 있는 오픈소스에 대한 생각을 다시 하게 된다.
오픈소스의 종류는 성당, 시장 이렇게 2개로 나눌 수 있다. 성당은 초기 단계이고, 시장은 그 다음 단계를 말한다. 활발한 단계를 시장이라고 생각하면 좋을 것이다. 성당과 시장의 오픈 소스를 경제학의 기본적인 관점, 생산 이윤의 극대화, 도구의 최대 효용의 측면을 봐야 한다.

생산자는 생산을 최대로 하여 이윤을 추구해야 하고, 소비자는 생산자가 만든 도구를 효용의 극대화 시키는 경제학적 관점에서 보았을때, 성당 타입의 오픈 소스의 경우는 잘 들어 맞지 않는다. 오히려 시장의 경우가 더욱 맞다.

이유는 이윤의 극대화의 생산자의 입장이 잘 설정되어 있지 않기 때문이다. 즉, 시장 타입의 오픈 소스가 성공할 확률이 높다는 것이다. Ubuntu 리눅스는 Canonical 회사의 현상금 덕택에 엄청난 개발이 되고 있다고 한다. 즉 생산자의 이윤을 극대화하여 이윤의 동기가 되는 것이다.

과연 이런 현상금외엔 돈이 될 수 없을까? 유토피아 사고의 사회학적 분위기의 "평등"를 추구하는 오픈 소스는 돈을 벌 수 없고, 공산주의 사회처럼 무너지는 것인가 하는 고민도 생기게 된다.

국가 중심의 오픈 소스 지원은 어떨까? 시장 지배력이 있는 상업 소프트웨어에 종속 될 경우, 해당 소프트웨어가 버전업 비용 및 과, 독점에 따른 지배적인 위치일 때, 오픈 소스는 큰 힘을 부여 받을 수 있다.
국가 단위의 지원이 오픈 소스 개발자에게 이윤의 동기가 될 수 있다.

3가지 요소, "Just For Fun", "기업의 현상금", "국가적 차원의 지원"등이 그 개발 동기일 것이다. 하지만, 그 외에는 무엇이 있을까?

1. 서론

의외로 전산학도의 많은 사람들이 ANSI C를 모르고 있었다. ANSI(American National Standard Institute)의 약자도 모르는 사람들도 종종 있다.
C는 알지만, C언어의 표준이 계속 바뀌는 것을 모르게 되었다. 어떻게 이렇게 변하게 되었을까?
나두 이와 멀리 동떨어진 사람이 아니다. 나도 그들이었고, 그들 속에서 성장해 왔다.

왜 이렇게 표준없이 c언어를 무작정 느낌으로 (?) 공부하게 되었을까? 아마도 c언어를 대충 배운 사람이 c언어를 대충 가르쳐 주기 때문이라고 생각한다. 표준을 이해하고, 표준을 설명하지 않고, 그냥 os-specific한 코드를 짜는 세상이 되고, 마치 가장 기본서인 표준 문서도 보지 않은 채, 고등학교 수학책처럼 외우게 되어버린 c언어책..

새롭게 마음 가짐을 가지고, C언어를 바라봐야한다. 왜 표준이 중요한지를 깨달으면서..


2. 표준
Javascript는 ISO 8601로, c#은 ISO/IEC 23270으로, 자바 언어에서는 Java Language Specification, MHP에는 DVB라는 표준 문서라는 것이 존재한다. 네트웍 표준은 FTP, NFS도 RFC로 존재하듯이 C언어에도 존재한다.

C언어 표준을 만든 ANSI(American National Standard Institute, 미국 표준 기관)는 ISO/IEC에 proposal을 제출하여 승인을 받아 국제 표준이 된다. ISO, IEC에서 일부 규정을 수정할 수도 있는데, 그 수정한 내용은 ANSI에도 반영시켜 표준이 되도록 한다.

1983년, ANSI에서 X3J11이라는 위원회가 표준화를 위해 조직되었고, 그 결과로 1989년 12월 4일, ANS X3.159-1989 라는 문서로 공개하였다. 이렇게 1989년 원래 ANSI C 표준 초안이 만들어졌고, 1990년 ISO 표준이 되었다. ANSI/ISO/IEC 9899:1990라고 불리운다. 이 때, 전혀 내용의 변경이 없었다고 한다.

그리고, C표준은 ANSI/ISO/IEC 9899:1995 으로 변경되었고, ANSI는 1999년 이를 받아들였다.
반면, C++은 ANSI/ISO/IEC 14882:1998으로 표준이 정해졌다.

현재 C는 C99이라는 표준이 완성되었고 채택되었다.

(재미있는 사실은 ANSI/ISO/IEC 14882:1998 C++ language standard 가 2.49Mbyte의 18불인 것에 비해 ANSI/ISO/IEC 9899:1990 C language standard은 17.74Mbyte의 135불이라는 사실이다.)


3. 표준의 중요성

왜 표준이 중요한가?

그것은 portable한 코드와 관련이 되어 있다.
8bit 프로세서부터 32bit 프로세서까지, 다양한 c compiler환경에서 어떤 코드만이 동작될 수 있는지 알려면, 오직 표준밖에 없다는 사실이다.

자바의 경우에 J2ME 어플리케이션이 한 번 만들어지면, J2ME 플랫폼에서 동작이 보장되듯이 c의 표준을 맞춰 작성한다면, 항상 portable한 코드가 될 수 있다는 사실이다.

portable하다라는 의미는 무엇일까? portable이다라는 말 뚯에 os-independent/compiler-independent라는 성격이 있다는 말이 포함된다. 즉, ISO규격에 맞는 코드가 가장 portable하다라는 말과 상통될 수 있다.
writing portable code라는 말은 (ANSI/ISO/IEC 일도 있고, de factor일 수도 있다.) 표준에 맞게 코드를 짠다는 말인 것이다.

os, compiler에 상관없이 규격에 맞게 짜는 일을 쉽게 하므로서, 플랫폼에서 independent하게 동작하기 위해서 표준이 필요하다.

4. 표준의 변화
표준도 변화하고 있다. ISO 9899 C를 이렇게 저렇게 바꾸고 있으며 표준화가 한창 진행중이다. Embedded C, New character types in C, Safer C library, Safer C library fuctions, Decimal floating point, Mathmatical special functions 등 여러 Techincal Report가 나오고 있다.

진화는 계속 된다.(역시 계속 공부해서 익숙해 지는 것외에 방법이 없는 듯~)

레퍼런스 :
http://www.eskimo.com/~scs/c-faq.com/ansi/ansi1.html
http://home.att.net/~jackklein/c/standards.html#inportant
http://www.open-std.org/jtc1/sc22/wg14/www/projects#18037

http://news.naver.com/news/read.php?mode=LSS2D&office_id=038&article_id=0000324096&section_id=103&section_id2=245&menu_id=103  

글을 써보는 연습은 상당히 중요하다. 실전에서 현장에서 사용될 글에서 문장력으로 인생이 좌지우지 할 정도로 중요한 부분임에는 틀림없다. 글이 왜 필요할까?

인류 역사 초기에는 글이라는 것은 필요가 없었다. 의사소통을 이유로 그림이 쓰여졌고, 자연스럽게 교류가 생기게 되었고, 멀리 있는 사람에게 정보를 알리기 위해서 글이라는 도구 통용되기 시작했다.

공간의 벽을 넘어선 글, 하지만 이런 글들이 점점 모여지다 보니 서서히 시간의 벽을 넘어서기 시작했다. 모아진 글중 중요한 것들은 시대를 넘어서서 경(經)이라는 형태로 전서되기 시작했다. 이런 전서를 통해서 새로운 철학이나 문화가 만들어 지기 시작하여 지금에까지 이르고 있다.

글의 힘은 위대하다. 한 치의 혀로 세상을 흔들 수 있는 것에 반해 하나의 글은 천년을 넘어 설 수 있다는 것은 상당히 고무적이 아닐 수 없다. 또한 기밀문서, 외교문서, 튜토리얼, 설명서, 교육문서등 다양한 기능을 하는 글들이 생겨 약속과 교육, 상대방과의 원만한 의사소통에서 큰 힘을 발휘할 수 있다.

문법에 맞으면서, 글의 목적에 맞게, 글을 보는 사람의 입장에서 쓰여진 글은 효력이 잇다. 하지만,  아무리 좋은 문장력으로 이루어진 글이라도, 상황에 따라 간결하게 보이는 것이 중요하다. 정확한 의사전달을 간단한 주제와 목적의식을 두고, 의도하는 내용을 상대방에게 설득할 수 있다면, 이보다 가장 더 좋은 글은 없다고 생각한다.

글을 쓴다는 것은 나의 주장이나 철학을 상대방에게 정확한 나의 의도를 알리는 것이다. 이를 위해서는 기본적으로 문법은 지켜야 하고, 상대방이 이해할 수 있는 시점에서 나의 의도를 상대방에 알리는 것이 그 목표가 될 것이다.
기본적은 문법이라던가, 물이 흐르듯이 자연스럽게 이어지는 문장력을 배우기 위해서는 많이 써보고 평을 받는 것이 중요하다. 그로 인해서, 차츰차츰 문장력과 단어 사용 능력을 키워 보다 자신의 가치를 높일 수 있는 기준으로 평가받는 시대가 오리라 생각든다.

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");
}

 

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 망을 쓰기 까닭에 바깥으로 패킷은 허용될 수 있으나, 들어오는 패킷은 막는 형태로 되어 있다. 그런 부분까지도 잘 감안해서 요구사항을 뽑아내야 한다.

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

요즘 지상파 방송사에서 방영하는 사회화와 관련된 동물 다큐멘터리를 보면, 똑똑한 동물이라 할지라도, 후손에게 가르칠 수 있는 지적 능력이 존재하지 않기에 후손에게 학습을 시키는 동물은 사람밖에 없구나 하는 생각이 든다.
후손에 가르칠 수 있는 능력은 인간에게 주어진 축복이구나 하는 생각이 든다.

머리가 뛰어나다는 원숭이와 개에게 꾸준한 반복된 학습의 효과는 그 개체에 한정되어 있다.
어느 조직이든 그 조직에서 뛰어난 사람은 자연스럽게 존재한다.하지만 뛰어난 사람을 통해서 조직 자체가 뛰어나기까지는 시간이 걸리는 듯 하다.

즉, 조직이 뛰어난 것은 뛰어난 사람이 많은 것보다는 조직의 비전을 위해서 조직원 하나하나가 뚜렷한 비전을 보고
성공적인 임무를 수행하는 것을 말한다.어떻게 하면, 뛰어난 조직이 될 수 있을까? 뛰어난 사람이 없다면, 조직이 뛰어나기는 힘들고,뛰어난 사람이 있으면, 조직이 뛰어난 사람에 의해서 좌지우지 할 수 있는 가능성도 많다. 뛰어난 사람이 나가버리면, 조직은 와해되는 경우도 많다는 것은 다들 아는 사실일 것이다.

대안의 하나로서, 커뮤니케이션을 기반으로 하는 학습이다.

뛰어난 조직을 이루기 위해서는 조직원 자체가 배운 것을 유지하고, 새로운 것을 학습하고, 학습된 지식과 경험을 공유하며, 커뮤니케이션 활발화를 통해서 타인의 경험을 조직원 각자에게 간접체험을 통해서 겪도록 하고, 새로운 것이나 해야할 업무에 두려움을 최소화시켜야 한다.

또한, 커뮤니케이션은 조직원 모두에게 친근감을 줄 수 있는 수단으로서 좋은 방법이 될 수 있다. 저녁에 술을 먹을 때 커뮤니케이션이 일어나는 것이 아니라, 일과 시간에 틈틈히 조직의 각자 구성원간에 편한 커뮤니케이션을 통해서 친근감을 최대한 가지도록 하는 것이 필요하다.

조직에 갓 들어온 소프트웨어 엔지니어가 회사에 적응하지 못하고 사라지는 이유는 일이 힘든 이유가 있겠지만,
당장 필요로 하는 일을 배우지 못해서 끙끙대는 이유가 많은 듯 하다. 개발하면서 부딪히는 문제에 대해서 처리하는 것을 선임자가 봐주지 못하고, 유닛 테스트, 컴파일 하는 법, 디버깅하는 법을 간단히 듣거나 혼자서 해결해야 상황이 자주 생기는 듯 하다. 최소 3개월정도는 현장에 투입하지 않고, 회사와 팀의 커뮤니케이션하는 주류에 끼도록 하고, 기본적인 대처방법을 가르쳐 주어야 한다.

또한, 초보 소프트웨어 엔지니어는 반드시 겸허한 마음으로 도그마에 빠지지 말고, 넓게 보는 시각을 보고, 팀에 빨리 적응해야 한다. 너무 수동적인 엔지니어일수록 주위의 도움을 받기 어려운 부분이 존재한다. 아주 잘하는 고수가 아닌 이상은 빨리 성격을 고쳐서 배우고 물어봐 실력을 쌓는 것이 중요하다.

이런 과정의 조직과 구성원간의 피드백을 통해서 커뮤니케이션이 자연스럽게 증가되고, 친밀감이 형성시켜 서로 돕고 도울 수 있는 자연스러운 관계가 되도록 노력해야 할 것이다.