시스템의 동작 싸이클은 다음과 같다.
아마도 이 틀에서 거의 바뀌지는 않을 것이다.


int main() // Entry point
{
   init();  // H/W, 인터럽트, 모듈의 초기화

   while(1) {
       // 무한 동작
       // 모듈을 실행시킨다.
   }

   return TRUE;
}


// Interrupt Hander: callback 형태로 구현
int getFib() {

}

Aperios 운영체제는 Sony Research & Development Center에서 개발된 운영체제로서, (과거는 Apertos라고 불림) 자바의 기능중 Reflection을 운영체제 차원에서 제공하는 첫번째 운영체제라고 한다.
(ieeexplore.ieee.org/iel5/ 6433/17161/00792047.pdf?arnumber=792047 )
http://csdl2.computer.org/comp/proceedings/isorc/2003/1928/00/19280007.pdf
 
기존은 언어에 dependent한 부분이 존재했었다.
java는 Reflection이라는 기능이 있어서, 별도의 파일이 없이 클래스의 메타정보를 run-time시 얻을 수 있었다.
반면, C나 C++에서는 run-time시 메타정보를 얻을 수 없다. 따로 header 파일을 이용하여 메타정보를 얻을 수 있다.

객체 지향적으로 접근했을때, 정보의 은폐성은 C나 C++이 높다고 볼 수 있다. 자바는 실행시, 다 reverse engineering을 통해 정보를 얻어내는 단점이 잇다. 하지만, 실제 배포시에는 오히려 C나  C++ 어플을 소스를 이용하여 컴파일해야 하는 경우가 생기는 것을 발견할 수 있다.
특히 window 프로그램시 이유없이 배포한 binary 버젼이 실행이 안되서 SDK를 깔고 소스 빌드를 해야 동작되는 일이나 linux상에서도 이유를 알 수 없는 실행 실패로 인해서 소스를 가져다가 소스 빌드를 해야 안전하게 동작되는 일이 빈번했다.

이런 고민은 바로 운영체제로 스며 들고 있다. 언어에 dependent한 이런 부분을 운영체제상에서 지원하고, 해당 API를 제공하여 알 수 있게 한 것은 상당히 고무적이다.
추후, 관련 논문을 읽고 나서, 자세한 얘기는 블로그에서 해보려고 한다.

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", "기업의 현상금", "국가적 차원의 지원"등이 그 개발 동기일 것이다. 하지만, 그 외에는 무엇이 있을까?

결국 하고 싶은 얘기는 피플웨어인가 하는 생각이 들긴 하지만..
나는 Humanism 관리자가 되고 싶다. 야구의 김인식 감독같은 사람처럼 되고 싶다.

이 Article은 IEEE 2005년 6월호에 나온 인간 측면에서 본 학습 방법론이다.
사람이라는 게 자고로 경험에서 우러나와 적용하는 것이고, 자신의 직접적인 경험이든지, 직접적인 경험을 통해서 제품에 철학이 들어가게 된다. 이런 경험을 통해서 소프트웨어 개발 방법론을 제시한다.

문화적 배경, 프로그램 요구사항에 대한 이해도, 엔지니어의 생활패턴 및 성격, 프로그래밍 스타일, 경제관, 가치관에 따라서 소프트웨어 개발이 상당히 달라질 수 있다는 것이다.
신기하게도 개발자의 성격과 코드가 상당히 비례관계가 있다라는 것은 신기하다.

개발과 관련된 부분들이 존재하고, 이 존재한 부분들을 무엇을 통해서 하나의 제품이 나올 수 있게 방법론을 제시할 것인가하는 고민이 생기게 된다. 어떻게 공부를 시켜야 하고, 또는 어떻게 여러 개발자들의 생각을 하나의 생각이 되게 하는 것에 포커스를 잘 두어야 한다.

교육 방법은 다음과 같다.
1. 소프트웨어 개발자에게 조직에서 인재상을 실시하고, 실시하는 교육을 실시한다.
2. 소프트웨어 개발 프로세스를 적용할 수 있는 프로세스 교육을 실시하고 적용시킨다. (spiral, unified, extreme)
3. 교육이 되었으면, 개발 팀과 같이 팀웍으로 개발을 하며, 일부분을 교육시키고, 제품의 큰 그림을 그릴 수 있도록 한다.
4. 고객의 입장에서 바라본 제품을 상기시켜 고객이 원하는 제품이 무엇인지를 알도록 한다.
5. 추상화된 생각을 하도록 한다. 제품의 일반화된 프레임, 혹은 generic한 생각을 하여 common한 것을 발견하도록 한다.


이에 추가한다면, 조직에서 만드는 제품 및 앞으로 무엇을 만들 것인지에 대한 비젼을 보여준다. 각 단계에서 조직 구성원들에게 토의 와 토론을 하도록 유도하고, 앞으로의 개인적인 비젼, 조직의 비젼을 볼 수 있도록 하고, 목표를 설정한다. 또한 개별적 인간들에 대해서 성격, 품성, 가치관들을 인정하면서 guideline을 제시하여 남발되지 않은 자유로운 창조성을 발휘하도록 해야 한다.

관리자들에게 리더쉽은 바로 이런 것이라고 생각한다. 단순히 제품만 만드고 문제 없이 고객의 요구사항에 부합되는 것이 아니라, 인간적인 측면의 모습을 이해하고, 앞으로의 비젼을 보여주는 것이 중요하다고 생각한다.

사례를 바탕으로 하여 지적 재산권에 대해 체계적으로 설명이 되어 있다.
제품의 개발 단계에 따라 고려할 수 있는 여러가지의 법적 지식을 잘 설명해 놓았으며, 쉽게 이해가 가능하게 잘 쓰여져 있다.
변리사를 공부하기 위한 특허법이라는 책보다는 실용적인 이 책을 강추한다.

발명가에게 필요한 것은 바로 특허 출원 방식, 특허의 요건, 특허의 특허권 및 실시권 주장 및 직무 보상이다. 즉 단계별로 어떤 일이 일어나는 지 쉽고 간결하게 사용되었다. 또한 법적 문제에서 해결 방법에 대한 주요 내용이 상당히 인상적이었다.

특허 취득 절차는 잘 이해하고 있었다. 특허를 출원하고, 특허 심사관에 의한 등록 심사시 이의를 제기할 때마다 반박 자료를 만들어 설득을 시켜 등록한 경험을 가지고 있던 까닭에 취득 절차를 어렵지 않았다.
하지만, 효력, 소멸에 대해서는 잘 알지 못했다. 심사할 때에 돈이 꽤 들어가는 것도 잘 알 수 있었다.
특허를 취득하려고 할 때 단계적인 아이디어의 예제가 상당히 도움이 되었으며, 보호 및 침해에 대한 손해는 상당히 고무적이었다. 특허권을 이용하여 대출도 받을 수 있었다!!

특허 지식을 좀 더 확장하기 위해서 일부 내용을 발췌하였다.

특허 침해자에 대한 특허권자의 보호방법
1. 침해금지 청구
2. 침해예방 청구
3. 침해금지 가처분 신청
4. 손해배상 청구
5. 부당이득 반환 청구
6. 신용회복 조치 청구
7. 형사 고소

특허 권자의 공격에 대한 방어
1. 기술적 범위 검토
2. 특허를 무효화시킨다.
3. 특허권의 효력이 제한됨을 주장한다.


특허권에 대한 당사자들간의 분쟁
1.  다른 사람의 특허를 못 받게 하고 싶을 때
 (1)  특허 등록이 되지 않도록 정보제공을 한다.
  (2) 특허 이의 신청을 한다.
  (3) 특허 무효 심판을 한다.
2. 내 기술이 다른 사람의 특허권에 포함되지 않음을 확인받고 싶을 때, 특허에 침해 되지 않음을 증명한다.
3. 나의 특허권에 다른 사람의 기술이 포함됨을 확인받고 싶을 때, 권리 범위확인심판을 청구해서 이긴다.
4. 다른 사람의 특허를 실시하고 싶은데 특허권자가 허락하지 않은 경우 - 강제 실시권을 이용한다.
5. 회사에서 주는 직무발명 보상금이 너무 적을 때, - 법원에 보상금 지급 소송을 제기한다.
6. 타인의 상표권을 취소시킬 때
  (1) 상표권자가 정당한 이유 없이 3년간 계속해서 등록상표를 사용하지 않은 때
  (2) 상표권자가 등록받은 상표를 다르게 사용하여 수요자로 하여금 오인 혼동을 일으킨 때


특허청에 대한 요구 또는 불복
1. 특허받은 명세서를 고치고 싶을 때
2. 출원을 거절 당했을때
  - 거절 이유는  발명이 아닌 것/ 산업상 이용가능성, 신규성, 진보성이 없는 것 / 다른 사람보다 후출원인 때 / 공공질서와 선량한 풍속에 위반되는 발명/ 정당한 출원인이 아닌 때 / 명세서의 기재가 잘된 경우 이다.
  - 위의 거절 이유가 아닌 데도 거절 결정되면, 심판원에 거절 결정 불복 심판을 청구할 수 있고. 불복사항이 있으면 심결 취소 소송을 제기할 수 있다.
3. 국가에 수용당한 발명의 보상금이 너무 적을 때
4. 특허법원에의 소송 (심결 취소 소송)

올해 특허 한건을 출원했고, 하나가 곧 출원할 것 같고, 과거에 특허를 냈던 것이 PCT출원을 시작 할 예정이며, 아이디어가 2-3개가 있어, 곧 회의를 통해서 구체화할 생각이다.

나는 특허를 경력을 쌓는 일로, 아이디어를 생각하는 데 있어서 도움이 될 것이라고 생각하는 차원에서 하지, 매크로적인 사고에서는 보지를 못했다.
지식 재산권 (지적 재산권)을 비지니스 차원에서는 보는 것일까?

특허 프로세스, 변리가 되는 길, 상표권, 저작권, 비지니스로 보는 특허의 유용함을 잘 설명하고 있다.
발명한 것을 잘 특허로 등록시키는 것도 중요하지만, 이를 돈으로 만드는 것도 중요하다고 한다. 즉 쓰지 못해서 썩는 특허보다는 잘 사용하여 비지니스로 창출하고, 창출된 이익을 통해서 특허 발명자에게 일부 이익이 돌아가게 하는 비지니스를 설명을 한다.
또한 특허 침해 요소를 잘 파악하여 비즈니스를 할 수 있도록 하는 부분이 인상적이었고, 내가 먹고 있는 상표들이 다 등록되어 있다는 사실이 놀라웠다.
단순히 특허뿐 아니라, 실용실안, 의장, 상표 등록등 범위가 큰 범위의 특허가 있고, 각각마다 나름대로 룰이 있고, 이 룰을 어기는 사람에게는 이에 응당하는 실제적인 보수를 발명 및 등록자에게 그 이윤을 제공해야 하는 현실에 대해서 깜짝 놀랬다.

돈이 되게 할 수 있는 능력, 즉 비즈니스 창출 능력과 특허로 보호받는 원천 기술을 바탕으로 독점적인 힘을 길러 기업을 만드는 것도 재미있을 것 같다는 생각도 들었다. 무조건 특허 싸움보다는 적절한 타협도 건강에 좋다는 것도 중요한 것이라고 생각을 할 수 있었다~

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

자바와 MS진영 (비교자체가 약간 어색하지만, 일리가 있다. 자바는 어느정도 반 MS의 진영의 축을 담당하기 까닭에..)의 SDK에서 지원하는 리팩토링 기능을 조사해봤다.

Visual Studio 2005에서 드디어 리팩토링 기능이 지원되었다. 아직은 이클립스 수준까지는 아니지만, 어느정도 쓸만하다고 본다. 개인적으로 Visual Studio 6를 쓰면서 느끼는 점은 컴파일이 빠른 거 외엔 Eclipse를 넘어서기기 어렵다.( 사실 컴파일이 빠른 것은 언어적인 차원이라서 비교 대상 자체는 아니다. 표현자체가 좀 거시기하다.)

하여튼, MS에서 나온 SDK가 리팩토링의 기능을 SDK에 넣은 것 자체가 수요가 있었기에 이 정도라도 나온게 아닌가 싶다.

<Visual Studio 2005>

http://msdn.microsoft.com/vcsharp/default.aspx?pull=/library/en-us/dnvs05/html/vs05_refac.asp

Refactoring Technique Meaning in Life

Extract Method : This allows you to define a new method based on a selection of code statements.
Encapsulate Field : Turns a public field into a private field encapsulated by a .NET property.
Extract Interface : Defines a new interface type based on a set of existing type members.
Reorder Parameters : Provides a way to reorder member arguments.
Remove Parameters : As you would expect, this refactoring removes a given argument from the current list of parameters.
Rename : This allows you to rename a code token (method name, field, local variable, and so on) throughout a project.
Promote Local Variable to Parameter  : Moves a local variable to the parameter set of the defining method.


<Eclipse>

http://www.cs.umanitoba.ca/~eclipse/13-Refactoring.pdf

Type 1 . Physical Structure
. Rename
. Move
. Change Method Signature
. Convert Anonymous Class to Nested
. Move Member Type to New File
Type 2 . Class Level Structure
. Push Down
. Pull Up
. Extract Interface
. Generalize Type (Eclipse 3 only)
. User Supertype Where Possible
Type 3 . Structure inside a Class
. Inline
. Extract Method
. Extract Local Variable
. Extract Constant
. Introduce Parameter (Eclipse 3 only)
. Introduce Factory (Eclipse 3 only)
. Encapsulate Field

마이크로 소프트웨어 2006년 7월 자료입니다.

무어는 '더욱 집적되는 집적회로'라는 제목의 논문에서 앞으로 집적회로가 전자공학의 미래가 될 것이라는 글을 썼으며, 이 후, 이더넷을 만든 멧칼프의 법칙은 네트워크의 가치가 사용자 수의 제곱에 비례한다고 발표했다.

1975년 수천개-1만개의 집적이 10년후에 32비트 마이크로프로세서가 범용화되었으며, 다시 10년이 지나서, 네트워크가 안방까지 파고 들었을 뿐아니라 임베디드 시스템이 더욱더 활성화되었다.  이제는 유비쿼터스라는 말이 너무 쉽게 이해할 정도로 어디서나 항상 연결지향적인 생산적인 할 수 있는 시대가 왔다.
시스템의 비용은 인원수에 비례하여 증가하는 경향이 있지만, 네트워크의 가치는 사용자 수의 제곱에 비례한다고 생각했다.

그러면 얼마 후 네트워크의 가치는 투자비용을 상회하고 더 빠른 속도로 증가하며 그 이후에는 네트워크의 폭증이 있을꺼라 예측했다. 무어의 법칙, 멧칼프의 법칙도 모두 기하급수적으로 증가한다.

너무 급속도로 경사진 상황에서 사람들은 쉽게 공황장애에 빠질 것 같은 상황을 잘 버텨온 정도가 아니라 즐긱도 한다.
경쟁에서 이길 수 있다면, 1~2년 정도 남들부터 더 빨리 기술을 소유할 수 있다면, 기꺼이 위험을 감수한다.

그렇지 않으면 경쟁에서 지기 때문이다.
지적인 능력, 추진력, 엄청난 열정, 마지막으로 운이 있어야 한다.
세월이 점점 빠르게 진화되고, 변화의 폭이 가파르게 상승하고 성장하는 부분때문에 사람들의 정신을 산란하게 만들었다.

이런 세상에서 나는 무엇을 해야 하는 것일까? 후배들에게 어떤 길을 보여줘야 하는 것일까?
공병호의 10년 후 한국, 자기 경영 노트, 부자 아빠 / 가난한 아빠 의 글처럼 (이 분의 모든 글을 지지하지는 않음.) 자기 계발 정신을 가져야 한다. 변화의 흐흡에 몸을 타고, 변화의 폭에 맞춰 비즈니스를 창출할 수 있는 부분을 잘 캐취해야 한다.

1,2년이 늦은 것에 대해서 후회할 필요는 없다. 오히려 노력하지 않는 자신을 후회해야 한다. 항상 노력하고 공부하는 자세.. 이것이 변화에 대해서 살아 남을 수 있는 기본적 토양이라고 생각한다.

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

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

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

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

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

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

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