소프트웨어 명언들

시렌의 이미지

높은 사람에게 데모를 할수록 데모의 성공률은 낮아진다.
- Dan

프로그래밍상의 문제점을 편법으로 해결해 놓고 나면 그 편법을 사용했던 부분을 원칙적으로 수정해야 하고 그러는 도중 그 프로그램은 더 이상 쓸모없게 된다. - Thoreau

늦어지고 있는 프로젝트에 추가로 인원을 투입시킴은 개발을 더욱 지연 시킬뿐이다. - Brooks

시간에 맞추어, 주어진 예산범위 내에서 시작했던 인원이 끝마무리까지 하는 주요 프로젝트란 역사상 없었다. 당신의 프로젝트라고 예외일줄 아느냐 ?
- Putnam

납기일이 가까워 질수록 남은 업무량은 증가한다.
- Bove

오늘 소프트웨어공학 시간에 교수님께서 소프트웨어 세계에서의 명언들을 잠깐 소개해주시더군요.그 중에서 기억나는 것들을 적었는데...다른 명언들도 있지 않을까요? :D

File attachments: 
첨부파일 크기
Image icon hangingmonkey.jpg75.38 KB
Image icon dday.JPG4.66 KB

댓글

sh.의 이미지

소프트웨어는 소프트하지 않다

이거 누가 한 말이죠?

스티브 맥코넬 책에서 본것 같은데...

ddoman의 이미지

KISS( Keep It Simple, Stupid )

유닉스 철학의 모든것을 담은 멋진 말이라고 생각합니다.

youlsa의 이미지

제일 중요한 K.I.S.S는 누군가 언급하실테니까... 재미있는 말들을 많이 하고 다니는 리누스의 말을 좀 인용할께요. ^^

Quote:
커널 작업을 할때 가장 중요하게 여기는 디자인 이슈가 뭐냐고요? 음...어... 그러니까... 재미있으면 된다는거죠. - Linus Torvalds

Quote:
이게 돌아갈지 안돌아갈지 제가 어떻게 알겠어요? 그건 베타 테스터들이 알아서 할 일이구요, 전 그냥 코딩만 했을 뿐이예요 - Linus Torvalds

Quote:
진짜 남자들은 백업같은건 받지 않죠. 걍 ftp 사이트( kernel.org죠. ^^ )에 올려서 다른 사람들이 받아서 백업받게 만들어야죠 - Linus Torvalds

=-=-=-=-=-=-=-=-=
http://youlsa.com

leigh의 이미지

We all know what "undefined" means: it means it works during development, it works during testing, and it blows up in your most important customers' faces.

- Scott Meyers, Effective C++

...

ㅡ,.ㅡ;;의 이미지

손발이 고생하고 있으면 머리가 나쁜것이고
프로그래머가 고생하고 있으면 팀장이 실력없는것이다.
- ㅡ,.ㅡ;; -


----------------------------------------------------------------------------

theone3의 이미지

Quote:
KISS( Keep It Simple, Stupid )

1. 간결하고 간단하게 만들어라.

2. (내가 알아볼수 있게) 쉽게 해, 멍청한 것아!

어떤게 맞는가요? :twisted:

당신은 사랑받기 위해 태어난 사람.

버려진의 이미지

dongyuri wrote:
Quote:
KISS( Keep It Simple, Stupid )

1. 간결하고 간단하게 만들어라.

2. (내가 알아볼수 있게) 쉽게 해, 멍청한 것아!

어떤게 맞는가요? :twisted:

Keep It Simple and Stupid

1번이 맞을겁니다.

2번이라고 생각하고 화내는 분들이 계시던데 :)

찬밥의 이미지

Hello World - Unknown

kmsr819의 이미지

우왕 굳 ㅋㅋㅋ

M.W.Park의 이미지

KISS 는 뒤에 "MY ASS"가 생략된 것입니다. :twisted:

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

soul의 이미지

dongyuri wrote:
Quote:
KISS( Keep It Simple, Stupid )

1. 간결하고 간단하게 만들어라.

2. (내가 알아볼수 있게) 쉽게 해, 멍청한 것아!

어떤게 맞는가요? :twisted:

RTFM 과 마찬가지로 약간의 joke가 가미된 의미로 알고 있습니다.

null

lovethecorners의 이미지

Good programmers know what to write.
Great ones know what to rewrite.

-- 성당과 시장 에서...

불량도ㅐㅈㅣ의 이미지

ddoman wrote:
KISS( Keep It Simple, Stupid )

유닉스 철학의 모든것을 담은 멋진 말이라고 생각합니다.

Keep It Simple and Stupid.

이렇게 써야 하지 않나요?

Keep It Simple and Small.

이것도 가능하지요. ^^

문근영 너무 귀여워~~

dragonkun의 이미지

Quote:
컴퓨터가 이해할수 있는 코드는 어느 바보나 다 짤수 있다.
좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. - 마틴 파울러

개인적으로 굉장히 좋아하는 말입니다..

Emerging the World!

지리즈의 이미지

굴지의 금융권 업체의 시스템 도입시 시스템 외국 본사쪽에서
작성한 미들웨어 소프트웨어 개선작업차 소스를 우연하게 보았는데,
소스 초기 작성자에 관련된 기본 주석을 제외하고는 주석이 하나도 없습니다.

단지 파일명, 함수명, 변수명 이 셋으로 모든 것을 이해할 수 있도록 짜여 있더군요.

군더더기라고는 조금도 없는 눈물이 날정도로 아름다운 코드였습니다.

몇해전에 다른 회사에서 업무지원을 나가게 되었는데,
묘령의 여자 프로그래머가 있더군요.
경력은 얼마 되지 않았지만, 학원을 아주 착실히 다녔다고 하고,
장차 학원강사가 꿈이라고 하더랍니다.
스스로 경력이 미천한 관계로 매우 겸손했는데요.(사실은 자신감이 없다고 할까요?)
그 분의 코드를 보는 순간 전의 외국계회사의 그 소스코드를 볼 때 느꼈던 충격을 다시 받았습니다.

청혼할 뻔 했습니다. ㅠ.ㅠ.

그전에는 여성프로그래머에 대해서 안좋은 선입관이 있었는데,
지금은 오히려 남성분들보다 더 훌륭한 코드를 작성하는 분들이 많을지도 모른다는 생각마저 들더군요.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

ㅡ,.ㅡ;;의 이미지

dragonkun wrote:
Quote:
컴퓨터가 이해할수 있는 코드는 어느 바보나 다 짤수 있다.
좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. - 마틴 파울러

개인적으로 굉장히 좋아하는 말입니다..

저는 그말에 거의 동의할수가 없습니다.
컴퓨터가 이해할수있는 코드를 어느바보나 다짤수 있을것 같지도 않고.
아니 그어떤바보중의 한명이라도 짤수 있는사람이 있다는게 신기할정도겠죠..

두번째 좋은프로그래머가 사람이 이해할수 있는 코드를 짠다..
이말은 사람이 이해하기쉬워야한다 즉, 어떠한 프로그램언어적인 특징을무시하고 또한 효율또한 고려하기보다 우선적으로 사람이 이해하기 쉬워야한다는뜻인데.. 유닉스철학과 는 많이 빚나가는 입장이군요..

예를들어 그렇다면 코볼로짜든 C로짜든 어셈블로짜든 언어적인 특징을고려하기보다 사람이 이해하기쉽도록 거의 비슷하게 짜야되겠지요..
저는 작은나무심는데는 삽을삽답게 쓰고 우물을 팔때는 포크레인을 포크레인답게 쓰고 싶은데
어떤이가 말하길 무조건사람이 일하기 편해야된다..라는입장이면..
무조건포크레인달고 살아야겠지요..기름값이고 포크레인 굴러오는데 걸리는 시간이고머고 필요 없이 말이죠..


----------------------------------------------------------------------------

hansolo의 이미지

너무 극단적으로 생각하신거 아닐까요?

인용 :
즉, 어떠한 프로그램언어적인 특징을무시하고 또한 효율또한 고려하기보다 우선적으로 사람이 이해하기 쉬워야한다는뜻인데.. 유닉스철학과 는 많이 빚나가는 입장이군요..

원문이 그정도로 "가독성" 을 최우선 과제로 삼으라는 말은 아니라고 봅니다.

sDH8988L의 이미지

ㅡ,.ㅡ;; wrote:
dragonkun wrote:
Quote:
컴퓨터가 이해할수 있는 코드는 어느 바보나 다 짤수 있다.
좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. - 마틴 파울러

개인적으로 굉장히 좋아하는 말입니다..

저는 그말에 거의 동의할수가 없습니다.
컴퓨터가 이해할수있는 코드를 어느바보나 다짤수 있을것 같지도 않고.
아니 그어떤바보중의 한명이라도 짤수 있는사람이 있다는게 신기할정도겠죠..

두번째 좋은프로그래머가 사람이 이해할수 있는 코드를 짠다..
이말은 사람이 이해하기쉬워야한다 즉, 어떠한 프로그램언어적인 특징을무시하고 또한 효율또한 고려하기보다 우선적으로 사람이 이해하기 쉬워야한다는뜻인데.. 유닉스철학과 는 많이 빚나가는 입장이군요..

예를들어 그렇다면 코볼로짜든 C로짜든 어셈블로짜든 언어적인 특징을고려하기보다 사람이 이해하기쉽도록 거의 비슷하게 짜야되겠지요..
저는 작은나무심는데는 삽을삽답게 쓰고 우물을 팔때는 포크레인을 포크레인답게 쓰고 싶은데
어떤이가 말하길 무조건사람이 일하기 편해야된다..라는입장이면..
무조건포크레인달고 살아야겠지요..기름값이고 포크레인 굴러오는데 걸리는 시간이고머고 필요 없이 말이죠..

흠... 유닉스의 철학과 어떤 면에서 빚나가는 지는 잘 모르겠네요...

물론, 유닉스가 작고 효율적인 것을 지향하고는 있지만, 그렇다고 2번을 우습게 보라는 말이 절대 아닙니다...

효율의 한계 내에서 2번과 같이 하라는 걸로 이해해야죠...

한 사람이 처음부터 끝까지 모두 처리하고 한번 코드를 만드는 것으로 끝나는 '아주~~~ 아주 간단한' project인 경우라면 몰라도 대부분의 중요 Project는

십중팔구 다른 사람의 손을 거치거나 수정이 이루어지게 됩니다...

그 때, 다른 사람이 이해하기 힘들게 되어 있다면, 그건 좋은 프로그램이 아니죠... 예전에 주석 하나 없는 2만 라인 Code를 들여다 보는데, 그거 처음에 짠

사람 아주 죽이고 싶더구만요...

복잡해 보이는 모든 일은 인간과의 인터페이스가 가장 중요하다고 봅니다...

codebank의 이미지

ㅡ,.ㅡ;; wrote:
dragonkun wrote:
Quote:
컴퓨터가 이해할수 있는 코드는 어느 바보나 다 짤수 있다.
좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. - 마틴 파울러

개인적으로 굉장히 좋아하는 말입니다..

저는 그말에 거의 동의할수가 없습니다.
컴퓨터가 이해할수있는 코드를 어느바보나 다짤수 있을것 같지도 않고.
아니 그어떤바보중의 한명이라도 짤수 있는사람이 있다는게 신기할정도겠죠..

두번째 좋은프로그래머가 사람이 이해할수 있는 코드를 짠다..
이말은 사람이 이해하기쉬워야한다 즉, 어떠한 프로그램언어적인 특징을무시하고 또한 효율또한 고려하기보다 우선적으로 사람이 이해하기 쉬워야한다는뜻인데.. 유닉스철학과 는 많이 빚나가는 입장이군요..

예를들어 그렇다면 코볼로짜든 C로짜든 어셈블로짜든 언어적인 특징을고려하기보다 사람이 이해하기쉽도록 거의 비슷하게 짜야되겠지요..
저는 작은나무심는데는 삽을삽답게 쓰고 우물을 팔때는 포크레인을 포크레인답게 쓰고 싶은데
어떤이가 말하길 무조건사람이 일하기 편해야된다..라는입장이면..
무조건포크레인달고 살아야겠지요..기름값이고 포크레인 굴러오는데 걸리는 시간이고머고 필요 없이 말이죠..


말을 그대로 본다면 그리 틀린 의견은 아닙니다만...
말뜻을 생각해보시면 그렇지 않다는 것을 아실것 같은데...

꼭 '바보'를 지칭해서 한말은 아닙니다. 즉, 프로그램을 하는 어느누구나를 지칭한것
이겠죠.(물론 같은 언어를 이해하거나 공부한 사람으로 한정지어서...)
즉, 첫번째 구절의 컴퓨터만 이해하는 이란 구절은 코드자체를 너무 어렵게 만들어서
컴파일러가 기계코드를 만들어서 실행할 때는 상관없지만 이 코드를 보는 사람
입장에서는 이해하기 위해서 그에 관련된 코드를 되집어서 공부해야하는 쓸데없는
시간낭비를 하지 말라는 소리입니다.

물론 예전처럼 CPU의 속도가 느렸을 때에는 단 1초를 줄이기 위해서 2 * 8이라고
써도되는 부분에 2 << 3이라고 쓰고 꼭 비트계산을 해서 * 8이라는 것을 이해시키는
사람이 있었죠.
하지만 지금처럼 CPU의 속도가 빨라졌을때는 체감속도가 그렇게 다르다고 생각하지는
않습니다. 하지만 아직도 * 8대신에 << 3이라고 써놓고 그 코드를 다른 사람에게
넘겨주면서 '내가 짠부분인데 이해하기 쉬울거야.'라고 말하는 사람들을보면... :evil:
sDH8988L님도 말씀하셨듯이 혼자만이 관리하는 프로그램이라면 어떠한 형태로
프로그램을 작성해도 누가 뭐라고 할 사람은 없습니다. 다만 여러사람이 같이 프로젝트를
할 경우라면 '사람이 이해할 수 있는 코드를 짠다'는 것은 상당히 중요한 일이라고
생각합니다.

------------------------------
좋은 하루 되세요.

dude7853의 이미지

불량도ㅐㅈㅣ wrote:
ddoman wrote:
KISS( Keep It Simple, Stupid )

유닉스 철학의 모든것을 담은 멋진 말이라고 생각합니다.

Keep It Simple and Stupid.

이렇게 써야 하지 않나요?

Keep It Simple and Small.

이것도 가능하지요. ^^

에릭 레이몬드의 Art Of UNIX Programming에는 Keep It Simple, Stupid! 라고 되어있더군요.

저는 개인적으로 "간단하게 만들어, 바보야!" 정도로 해석하고 있습니다만...
(이쪽 사람들이 말장난을 좀 좋아해야 말이죠 8) )

madhatter의 이미지

ㅡ,.ㅡ;; wrote:
dragonkun wrote:
Quote:
컴퓨터가 이해할수 있는 코드는 어느 바보나 다 짤수 있다.
좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. - 마틴 파울러

개인적으로 굉장히 좋아하는 말입니다..

저는 그말에 거의 동의할수가 없습니다.
컴퓨터가 이해할수있는 코드를 어느바보나 다짤수 있을것 같지도 않고.
아니 그어떤바보중의 한명이라도 짤수 있는사람이 있다는게 신기할정도겠죠..

두번째 좋은프로그래머가 사람이 이해할수 있는 코드를 짠다..
이말은 사람이 이해하기쉬워야한다 즉, 어떠한 프로그램언어적인 특징을무시하고 또한 효율또한 고려하기보다 우선적으로 사람이 이해하기 쉬워야한다는뜻인데.. 유닉스철학과 는 많이 빚나가는 입장이군요..

예를들어 그렇다면 코볼로짜든 C로짜든 어셈블로짜든 언어적인 특징을고려하기보다 사람이 이해하기쉽도록 거의 비슷하게 짜야되겠지요..
저는 작은나무심는데는 삽을삽답게 쓰고 우물을 팔때는 포크레인을 포크레인답게 쓰고 싶은데
어떤이가 말하길 무조건사람이 일하기 편해야된다..라는입장이면..
무조건포크레인달고 살아야겠지요..기름값이고 포크레인 굴러오는데 걸리는 시간이고머고 필요 없이 말이죠..

주석이라도 잘 달라는 얘기로 이해하면 안될까요?

soungno의 이미지

프로그램밍 작업는 혼자 하는 작업이 아니죠.
팀단위 또는 많은 사람들의 이해 관계가 있는 복잡한 조직 속에서 이루어 지는 작업 입니다.
그러므로 개발자의 유일한 산출물인 코드 자체가 다른이에게 의미를 전달할수 있어야 한다는 것 아닐까요?
KISS 자체도 코딩의 줄수나 명령어수를 말하는게 아니겠죠.
누구나 이해 할수 있게 최대한 단수하게 프로그램밍을 하라는 말이 아닐까요?

잘 가야지.

너굴사마의 이미지

Q: What has been the most valuable lesson you have learned in the last couple of decades in this field?
-- June Kim
A: I have learned the art of simplification. It is not easy. One must understand a problem deeply in order to choose what need not to be said. Also, one must not be afraid of criticism from people who confuse silence with unknowing.
-- Ward Cunningham

----------------------------------------------------------------------------
"It is more important to know where you are going than to get there quickly"
- Mabel Newcomber

myduck의 이미지

소프트웨어 명언은 아니지만
성당과 시장에서도 인용된 글인

"완벽한 설계는 더 이상 추가할게 없는게 아니라, 더 이상 제거할게 없는것이다."

항상 프로그램짜다 보면 쓸데 없는 변수와 코드들이 들어 가는걸 보면
아직 이대로 못하고 있는거죠.

envia의 이미지

Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth

좋은 프로그래머는 사람이 이해할 수 있는 코드를 짜는 것도 맞는 말이라고 생각합니다... Knuth의 경우 자기가 짠 코드를 그냥 단행본으로 내 버렸지요. 이에 관해서는 http://wiki.kldp.org/wiki.php/ComputerProgrammingAsAnArt를 참고하십시오.

----

It is essential, if man is not to be compelled to have recourse, as a last resort, to rebellion against tyranny and oppression, that human rights should be protected by the rule of law.
[Universal Declaration of Human Rights]

jeamvfs의 이미지

소소한 것에서 만족을 느끼게 하는 글은 언제 봐도 즐겁습니다.

사랑_성공은 여행

사랑_성공은 여행

LispM의 이미지

ㅡ,.ㅡ;; wrote:
dragonkun wrote:
Quote:
컴퓨터가 이해할수 있는 코드는 어느 바보나 다 짤수 있다.
좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. - 마틴 파울러

개인적으로 굉장히 좋아하는 말입니다..

저는 그말에 거의 동의할수가 없습니다.
컴퓨터가 이해할수있는 코드를 어느바보나 다짤수 있을것 같지도 않고.
아니 그어떤바보중의 한명이라도 짤수 있는사람이 있다는게 신기할정도겠죠..

두번째 좋은프로그래머가 사람이 이해할수 있는 코드를 짠다..
이말은 사람이 이해하기쉬워야한다 즉, 어떠한 프로그램언어적인 특징을무시하고 또한 효율또한 고려하기보다 우선적으로 사람이 이해하기 쉬워야한다는뜻인데.. 유닉스철학과 는 많이 빚나가는 입장이군요..

예를들어 그렇다면 코볼로짜든 C로짜든 어셈블로짜든 언어적인 특징을고려하기보다 사람이 이해하기쉽도록 거의 비슷하게 짜야되겠지요..
저는 작은나무심는데는 삽을삽답게 쓰고 우물을 팔때는 포크레인을 포크레인답게 쓰고 싶은데
어떤이가 말하길 무조건사람이 일하기 편해야된다..라는입장이면..
무조건포크레인달고 살아야겠지요..기름값이고 포크레인 굴러오는데 걸리는 시간이고머고 필요 없이 말이죠..

효율이라는 것이 꼭 readability를 떨어뜨리는 것은 아닙니다. 마틴의 글에 주석을 달자면, '컴퓨터에서만 돌아가는 프로그램은 아무나 작성할 수 있지만 사람에게도 의미가 있는 프로그램은 아무나 작성하지 못한다'라고 할 수 있습니다.
대개의 경우 효율과 readability를 둘다 잡을 수 있지만, 간혹 매우 가끔 둘중에 하나를 희생해야 하는 경우 역시 있습니다. 이런 경우 커맨트를 많이 달기도 하죠. 하지만, 오늘날 하드웨어 발전으로 대부분의 경우 readability 쪽을 택하는 것이 옳다고 생각합니다.

극단적으로 readability와 효율중 하나만 택한 프로그램 중 어떤 프로그램이 살아남을 것인가 생각해보면 의외로 답은 간단하지 않을까요?

http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임

krisna의 이미지

ㅡ,.ㅡ;; wrote:
dragonkun wrote:
Quote:
컴퓨터가 이해할수 있는 코드는 어느 바보나 다 짤수 있다.
좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. - 마틴 파울러

개인적으로 굉장히 좋아하는 말입니다..

저는 그말에 거의 동의할수가 없습니다.
컴퓨터가 이해할수있는 코드를 어느바보나 다짤수 있을것 같지도 않고.
아니 그어떤바보중의 한명이라도 짤수 있는사람이 있다는게 신기할정도겠죠..

두번째 좋은프로그래머가 사람이 이해할수 있는 코드를 짠다..
이말은 사람이 이해하기쉬워야한다 즉, 어떠한 프로그램언어적인 특징을무시하고 또한 효율또한 고려하기보다 우선적으로 사람이 이해하기 쉬워야한다는뜻인데.. 유닉스철학과 는 많이 빚나가는 입장이군요..

예를들어 그렇다면 코볼로짜든 C로짜든 어셈블로짜든 언어적인 특징을고려하기보다 사람이 이해하기쉽도록 거의 비슷하게 짜야되겠지요..
저는 작은나무심는데는 삽을삽답게 쓰고 우물을 팔때는 포크레인을 포크레인답게 쓰고 싶은데
어떤이가 말하길 무조건사람이 일하기 편해야된다..라는입장이면..
무조건포크레인달고 살아야겠지요..기름값이고 포크레인 굴러오는데 걸리는 시간이고머고 필요 없이 말이죠..

제 생각에는 그 말 뜻은 "컴파일 된다고 다 코드가 아니다" 라는 뜻정도로 생각하는게 좋을것 같군요. 많은 분들이 효율성문제를 이야기 하셨는 데, 효율성과 관계없이 문제를 정확히 파악하지 못해서 복잡한 코드를 작성하는 경우가 있을 수 있습니다.

아래와 같은 코드를 생각해보죠.

printf("%s:%s", name, itoa(value));
printf("%s:%d", name, atoi(str));

꼭 효율성을 위해서만 이상한 코드가 나오는 것이 아니고 문제를 제대로 이해하지 못하거나, 자기가 사용하는 코드가 어떤 의미를 가지는지 제대로 이해하지 못한다면 위와 같은 코드를 만들 수 있습니다.

이것은 어떤 문제 해결을 방식을 선택하느냐의 문제입니다.
이것을 잘 나타낸 그림이 전에 나왔던 그네 그림입니다.
정확한 링크는 모르겠는데, 아시는 분이 링크해 주실 거라 생각합니다.
문제를 잘 이해하면 간단한 그네를 만들수 있음에도 결과물은 복잡하고 위험한 그네였습니다.

warpdory의 이미지

제가 가장 중요시 하는 말은 ..
"백업을 안하면 3대가 내리 흉하다."

입니다.

제 자손을 흉하게 하지 않기 위해서도 백업은 꼭 해둡니다.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

ed.netdiver의 이미지

일부만 발췌하려다 전문을 옮겨봅니다.^^;

----------------------------------------------------------------------------------------

===============================================================================
THEㅤTAOㅤOFㅤPROGRAMMINGㅤ
===============================================================================

이 글은 월간 마이크로 소프트 1,2 월호에 실린 것으로,
원래 인터넷 유모란에 있는, Geoffrey James 가 영역하고,
Seth Robertson 이 필사한 < The Tao of Programming > 이란 글을,
윤태원(서울대 대학원 섬유공학과)씨가 한역한 것입니다.

===============================================================================

[ 프로그래밍의 도(道) ]
- The Tao of Programming

「 도사 프로그래머 가라사대, 숨겨진 에러 코드를 찾아내는 방법을 익혔
다면 하산할 때가 온 것이니라. 모름지기 프로그램에는 도가 존재하나니
바로 프로그래밍의 도란 것이니라.」

목차
제 1권 : 무(無)
제 2권 : 고대(古代)의 도사(道士)들
제 3권 : 설계(Design)
제 4권 : 코딩(Coding)
제 5권 : 유지(Maintenance)
제 6권 : 관리(Management)
제 7권 : 운용의 묘
제 8권 : 하드웨어와 소프트웨어
제 9권 : 에필로그

===============================================================================
무(無)

제 1권
===============================================================================

도사 프로그래머 가라사대 :

「 숨겨진 에러 코드를 찾아내는 방법을 익혔다면 하산할 때가 온 것이니
라. 」

===============================================================================

1.1

무(無)에서 이상스러운 기운이 생겨났도다. 그 기운은 홀로 외로이
움직이지 않았다. 그 기운은 움직이지 않았으나 동시에 끊임없이 움직이고
있었다. 그것이 바로 모든 프로그램의 소스이다. 나는 이름을 알지 못하느니,
그것을 '프로그램의 도(道)'라고 부르게 되었다.

도가 위대하다면 운영체제(OS)도 위대하다. 운영체제가 위대하다
면 COMPILE러도 위대하다. COMPILE러가 아주 위대한 것이라면 애플리케이션
또한 아주 위대하다.

사용자는 만족하고 그리하여 세상은 조화로 충만하도다. 프로그
래밍의 도는 멀리까지 미치며 아침 바람과 함께 돌아온다.

===============================================================================

1.2

도는 기계어를 낳았다. 기계어는 어셈블러를 낳았다. 어셈블러는 COMPILE
러를 낳았다. 그리하여 세상은 만(萬)가지도 넘는 언어로 가득하게 되었다.

모든 언어는 아무리 비천한 것일지라도 그 뜻한 바가 있다. 모든
언어는 소프트웨어의 음(陰)과 양(陽)을 나타낸다. 모든 언어는 도 안에
그 자리가 있는 법이다. 하지만 할 수만 있다면 코볼(COBOL)로는 프로그래
밍하지 말지어다.

===============================================================================

1.3

처음에 도가 있었다. 도는 시간과 공간을 낳았다. 그리하여 시간과 공간
은 프로그래밍의 음과 양을 이루게 되었다.

도를 깨닫지 못한 프로그래머는 언제나 프로그램을 짤 시간과 공
간이 모자라는 법이다. 도를 깨달은 프로그래머는 언제나 목적을 달성할
수 있는 충분한 시간과 공간이 있다. 세상의 모든 이치가 그러한 법이
니....

===============================================================================

1.4

현명한 프로그래머는 도를 듣고 따른다. 보통 프로그래머는 도를 듣고 찾
아본다. 멍청한 프로그래머는 도를 듣고 웃어 넘긴다. 그 웃음이 없었더라
면 도는 존재하지 않았을 것이다.

가장 높은 음이 가장 알아듣기 힘든 법. 앞으로 나아감은 바로 후
퇴하는 법. 위대한 재능은 인생의 후반에야 나타나는 법. 가장 완벽한 프
로그램에도 버그는 존재하는 법.

===============================================================================
고대(古代)의 도사(道士)들

제 2권
===============================================================================

도사 프로그래머 가라사대 :

「 사흘간 프로그래밍을 하지 않으면, 삶에 아무런 의미도 없어지느니라. 」

===============================================================================

2.1

고대의 프로그래머들은 신비롭고 심오하도다. 우리는 그들의 사상을 감히
측정할 수 없도다. 그리하여 우리는 그들의 외양을 묘사할 수 밖에 없도
다.
그들은 물을 건너는 여우처럼 빈틈이 없다. 전장에 나선 장군처럼
방심하지 않는다. 손님을 맞는 여주인처럼 친절하다. 조각하지 않은 나무
토막처럼 단순하다. 어두운 동굴 속의 검은 연못처럼 불투명하다.
누가 감히 그들의 마음과 생각에 담긴 비밀을 알아낼 수 있으리
요? 답은 오직 도 속에 있을 뿐이다.

===============================================================================

2.2

위대한 도사 튜링(Turing)은 어느날 그가 기계가 된 꿈을 꾸었다. 잠에서
깨어난 튜링이 탄식하며 가라사대 :

「 나는 기계가 된 꿈을 꾸는 튜링인지, 튜링이 된 꿈을 꾸는 기계인지 알지
못하노라! 」

===============================================================================

2.3

아주 큰 컴퓨터 회사에서 온 프로그래머가 소프트웨어 전시회에 다녀와 상
사에게 이렇게 말했다.

「 다른 회사에는 어떤 프로그래머들이 일하고 있습니까? 그들은 멋대로 행
동하고 외관에는 신경쓰지 않습니다. 그들의 머리는 길고 덥수룩하며, 그
들의 웃은 낡고 구겨졌습니다. 그들은 숙소에서 만취해서 돌아다니며 제가
발표할 동안에 야유를 해 댔습니다. 」

상사가 가로되
「 너를 전시회에 보내지 말았어야 했다. 그 프로그래머들은 세상사를 초월한
사람들이니라. 그들은 삶을 어리석은 것으로여기며, 우연의 일치로 생각한다.
그들은 아무런 거리낌없이 다닌다. 그들은 아무 것에도 신경쓰지 않으니,
그것은 그들이 프로그램만을 위해살기 때문이다. 왜 그들이 사회적인 관습 따위에
신경을 쓰겠느냐? 」
「 그들은 도 속에 살고 있느니라. 」

===============================================================================

2.4

제자가 스승에게 묻기를
「 저 프로그래머는 설계도 않고, 문서 작성도 않
으며 자기 프로그램을 테스트해 보지도 않습니다. 하지만 모두 그를 세계
에서 가장 뛰어난 프로그래머라고 칭송합니다. 그 이유가 무엇입니까? 」
스승이 답하기를
「 그 프로그래머는 도를 깨달았느니라. 그는 더 이상 설계할 필요성을 느끼지
않는다. 그는 시스템이 다운되어도 화내지않으며 그저 우주의 질서를 거리낌
없이 받아들이기 때문이다. 그는 더 이상 문서를 작성할 필요가 없다. 그는
다른 사람이 자기가 짠 코드를 이해하건 말건 신경쓰지 않기 때문이다. 그는
테스팅할 필요가 없다. 그가 작성한 프로그램은 모두 그 자체로 완벽하며,
고요하고 또 우아하다. 그의 프로그램은 모두 그 목적이 스스로 뚜렷하기 때문
이다. 아, 그는 진정으로 도를 깨달은 사람이니라.」

===============================================================================
설계(Design)

제 3권
===============================================================================

도사 프로그래머 가라사대 :

「 프로그램을 테스트하고 있을 때는 설계를 변경하기엔 이미 늦은 다음이
니라. 」

===============================================================================

3.1

옛날에 컴퓨터 전시회에 참석한 사람이 있었다. 그는 매일 전시장에 들어
가면서 문 앞에 선 경비원에게 이렇게 말했다.

「 나는 상점을 터는 기술로 유명한 도둑이오. 미리 경고하지만 이 전시회
도 내 손길을 벗어나진 못할 것이외다. 」

그의 말에 경비원은 무척 신경이 쓰였다. 전시회에 출품된 컴퓨터
장비의 가치들이 가히 수십억원에 이르렀기 때문이다. 경비원은 자칭 도둑
의 일거수일투족을 감시하였다. 하지만 그는 휘파람을 불면서 전시장에서
전시장으로 돌아다닐 뿐이었다.
자칭 도둑이 전시회장을 나갈 때 경비원은 그를 옆으로 데려가 몸
수색을 실시하였다. 하지만 몸에는 아무 것도 없었다.
다음날, 그는 다시 돌아와 경비원의 약을 올렸다.
「 나는 어제 엄청난 수확을 올렸소. 오늘은 더 많은 것을 훔치고 말테요.」
경비원은 그를 더욱 철저히 감시하였다. 하지만 아무런 소득도 없었다.
전시회가 끝나는 날, 경비원은 호기심을 도저히 억누를 수가 없었
다.
「 도선생, 나는 도저히 이해할 수 없소. 궁금증으로 인해 나는 밤잠을
이룰 수 없을 것 같군요. 제발 나를 깨우쳐 주시오. 당신이 훔친 것은
대체 무엇이요? 」
도둑은 가볍게 미소를 지었다.
「 나는 아이디어를 훔치고 있소. 」

===============================================================================

3.2

옛날에 한 스승 프로그래머는 늘 구조화되지 않은 프로그램을 짰다. 한 제
자가 그를 흉내내기 위하여 구조화되지 않은 프로그램을 짰다. 제자가 스
승에게 자신의 성장을 평가해 달라고 하자, 스승은 프로그램이 구조화되지
않았다며 꾸짖었다.
「 뱁새가 황새를 따라가면 가랑이가 찢어지는 법이다. 구조를 초월하기
전에 먼저 도를 깨달아야 하느니라. 」

===============================================================================

3.3

위(魏)나라의 조정에 한 프로그래머가 있었다.
위후(魏候)가 프로그래머에게 묻기를
「 회계 프로그램과 운영체제중에 설계하기 쉬운 것은 어느 쪽이요? 」
「 운영체제이옵니다.」
하고 프로그래머가 답했다.
위후는 믿을 수 없다는 표정으로 반문하였다.
「 어찌 회계 프로그램처럼 하찮은 것이 운영체제의 복잡함을 능가한다는
말이요? 」
「 그렇지 않사옵니다. 회계 프로그램을 설계할 때는 프로그래머가 서로
다른 생각을 지닌 사람들을 조율해야만 하옵니다. 회계 프로그램이 어떻게
작동해야 하며, 보고서는 어떤 양식으로 출력되어야 하며, 세법에는 어느
정도로 충실해야 하는지 각양각색으로 떠들기 마련이옵니다. 반면에 운영체제의
외양에는 아무도 신경쓰지 않사옵니다. 운영체제를 설계할 때는 프로그래머는
기계와 아이디어의 가장 단순한 조화만 추구하면 되옵나이다.
이것이 운영체제가 설계하기 쉬운 까닭이옵니다. 옛말에는 이를
일컬어 사공이 많으면 배가 산으로 간다고 하옵니다. 」
크게 감탄한 위후가 미소를 지으며 다른 질문을 던졌다.
「 그렇구려, 그런데 어느 쪽이 더 디버깅하기 쉽소? 」
프로그래머는 아무런 답도 하지 못했다.

===============================================================================

3.4

관리자가 도사 프로그래머를 만나 새 애플리케이션의 요구사항을 담은
문서를 건네주었다.
관리자가 묻기를
「 다섯명의 프로그래머를 투입한다면 시스템을 설계하는 데 얼마나 걸리겠소? 」
「 일 년이 걸릴 것입니다. 」
도사가 간단하게 대답하였다.
「 하지만 우리는 이 시스템이 지금 당장 필요하단 말이요! 프로그래머를 열명
투입하면 어떻겠소? 」
도사는 인상을 지푸렸다.
「 그렇다면 이 년이 걸릴 것입니다. 」
「 프로그래머를 백명 투입한다면 어떻겠소? 」
도사는 가볍게 한숨을 쉬며 답하였다.
「 그 경우에는 시스템이 결코 완성되지 않을 것입니다. 」

===============================================================================
코딩

제 4권
===============================================================================

도사 프로그래머 가라사대 :

「 잘 짠 프로그램은 그 자체로 천국이며, 못 짠 프로그램은 그 자체로
지옥이니라. 」

===============================================================================

4.1

프로그램은 작고 민첩해야 하며, 그 서브 루틴은 마치 진주 목걸이처럼
연결되어 있어야 한다. 프로그램의 내용과 정신은 일관적이어야 한다. 프
로그램은 너무 작아도 너무 커도 아니되며, 필요없는 루프나 필요없는
변수가 있어서는 더 더욱 아니된다. 또한 구조가 없어도 아니되며 지나치
게 경직되어도 아니된다.
프로그램은 < 최소 놀람의 법칙 > 을 따라야 한다. 이 법칙이 무엇
이냐고? 프로그램은 사용자를 최소로 놀라게 하는 방향으로 반응해야 한다는
뜻이다.
프로그램은 아무리 복잡하더라도 하나의 객체처럼 동작해야 한
다. 프로그램은 외관보다는 내부의 논리에 따라 작성되어야 한다.
프로그램이 이러한 요구를 따르지 못하면 무질서와 혼란이 발생
한다. 이를 고치는 유일한 방법은 프로그램을 다시 작성하는 것 뿐이다.

===============================================================================
4.2

제자가 스승에게 묻기를
「 프로그램을 짰는데 때로는 작동하고 때로는 작동하지 않습니다. 프로그래밍
법칙을 모두 따랐는데 왜 이런 일이 생기는지 도무지 알 수가 없습니다.
이유가 무엇입니까? 」
스승이 답하기를
「너는 도를 깨닫지 못했기에 당황하는 것이니라. 사람들이 이성적으로
행동하리라 믿는 것은 오직 바보뿐이다. 너는 어찌하여 사람이 만든 기계로부터
이성적인 행동을 바라느뇨? 컴퓨터는 결정론을 흉내내는 것 뿐이다. 오직 도만이
완전하다.
프로그래밍의 법칙은 일시적이며, 오직 도만이 영원하다.
따라서 너는 깨달음을 얻기 위해 도를 명상해야 할 것이니라. 」
「 하지만 제가 깨달음을 얻었는지 어떻게 알 수 있습니까? 」
제자가 물었다.
「그 때가 되면 프로그램이 제대로 돌아갈 것이다. 」
스승이 말했다.

===============================================================================

4.3

스승이 도의 본질을 제자에게 설명하고 있었다.

「 도는 아무리 사소한 것일지라도 모든 소프트웨어 내에 존재한다. 」
스승이 말햇다.
「 휴대용 계산기에도 도는 존재합니까? 」
제자가 물었다.
「 그러느니라. 」
스승의 대답이었다.
「 비디오 게임에도 도는 존재합니까? 」
제자가 물었다.
「 비디오 게임에도 도는 존재하느니라. 」
스승이 말했다.
「 PC의 도스에도 도는 존재합니까? 」
스승은 불편한 듯 헛기침을 하더니 자세를 조금 바꾸었다.
「 오늘의 수업은 여기까지다. 」
스승이 말했다.

===============================================================================

4.4

프라이스 왕의 프로그래머가 소프트웨어를 짜고 있었다. 그의 손가락이 키
보드 위에서 춤을 추었다. 프로그램은 에러 메시지 하나 없이 COMPILE되었
고 마치 봄바람처럼 가볍게 실행되었다.
「 기가 막히군! 당신의 기술은 완전무결하구려! 」
프라이스가 감탄하며 말했다.
「 기술이라구요? 」
프로그래머가 터미널에서 몸을 돌리며 말하기 시작했다.
「 내가 따르는 것은 모든 기술을 넘어선 도입니다. 내가 처음
프로그램을 작성하기 시작했을 때는 프로그램 전체가 한 덩어리로
보였습니다. 삼년이 지나자 나는 더 이상 덩어리가 보이지 않았습니다.
그 때부터 나는 서브 루틴을 사용하기 시작했지요. 하지만 이제는 내게는
아무 것도 보이지 않습니다. 내 존재는 형태없는 무 속에 존재합니다.
나는 아무런 감각도 느낄 수 없습니다. 내 정신은 아무런 계획도 세우지
않고 자유롭습니다. 그저 본능의 지시에만 따를 뿐. 간단히 말해 내 프로그램은
스스로 작성되는 것입니다. 가끔 어려운 문제가 발생하는 것은 사실입니다.
어려움이 다가오는 것을 느끼면 속도를 늦춥니다. 그리고 조용히 관찰합니다.
그리곤 코드에서 한 줄만 바꾸면 어려움은 마치 연기처럼 사라지고 말지요.
그리고 나선 프로그램을 COMPILE합니다. 나는 조용히 앉아 일의 즐거움이 내 존재를
가득 채우는 것을 느끼며 즐깁니다. 나는 잠깐 눈을 감고 명상한 다음 터미널을
끕니다. 」
프라이스 왕이 가로되,
「 내가 고용한 모든 프로그래머들이 그대처럼 현명하기를! 」

===============================================================================
프로그래밍의 도(道)
- The Tao of Programming
===============================================================================

「 조심스레 사용한 문의 경첩에는 기름을 칠 필요가 없다.
흐르는 물에는 이끼가 끼지 않는다.
소리도 생각도 진공을 지나갈 수는 없다.
사용하지 않은 소프트웨어는 똥된다.
이들은 모두 위대한 미스터리들이다. 」

「 훌륭한 농부가 자신이 심은 쌀 한 톨을 소홀히 하는 것을 보았는가?
훌륭한 선생이 반에서 가장 어리석은 학생이라고 무시하는 것을 보았는가?
훌륭한 아버지가 아이를 굶주리게 하는 것을 보았는가?
훌륭한 프로그래머가 코드를 고치는 것을 거부하는 것을 보았는가? 」

목차
제 1권 : 무(無)
제 2권 : 고대(古代)의 도사(道士)들
제 3권 : 설계(Design)
제 4권 : 코딩(Coding)
제 5권 : 유지(Maintenance)
제 6권 : 관리(Management)
제 7권 : 운용의 묘
제 8권 : 하드웨어와 소프트웨어
제 9권 : 에필로그

===============================================================================
유지

제 5권
===============================================================================

도사 프로그래머 가라사대 :

「 프로그램의 길이가 세 줄밖에 안되더라도 언젠가는 손볼 필요가 생기느니
라. 」

===============================================================================

5.1

조심스레 사용한 문의 경첩에는 기름을 칠 필요가 없다. 흐르는 물에는 이
끼가 끼지 않는다. 소리도 생각도 진공을 지나갈 수는 없다. 사용하지 않
은 소프트웨어는 똥된다. 이들은 모두 위대한 미스터리들이다.

===============================================================================

5.2

관리자가 어느 날 프로그래머를 불러 물었다.
「 지금 짜고 있는 프로그램이 언제 끝나겠소? 」
프로그래머가 즉시 답하기를
「 내일까지 끝내지요. 」
「 좀 비현실적인 얘기같군요. 정말로 언제까지 끝낼 수 있습니까? 」
관리자가 다시 물었다.
프로그래머는 잠깐 생각을 하더니 말했다.
「 사실은 약간 추가하고 싶은 기능이 있습니다. 그걸 다 하려면
2주는 걸리겠는데요. 」
「 그것도 기대하기 힘든 것 같군요. 그냥 프로그램이 완성되면 알려 주시오. 」
관리자가 툴툴대며 말했다. 프로그래머는 그러마고 답했다.
많은 해가 지나 관리자는 은퇴하게 되었다. 은퇴식장에 가던
도중 그는 프로그래머가 터미널 앞에서 잠들어 있는 것을 보게 되었다. 그는
어제 밤을 새워가며 프로그래밍을 했던 것이다.

===============================================================================

5.3

어느 날 제자 프로그래머가 간단한 회계 프로그램을 짜라는 지시를 받았
다. 제자는 많은 날을 열심히 일했다. 스승이 그의 프로그램을 훑어보니
스크린 에디터와 그래픽 처리 루틴 몇 가지, 그리고 인공지능을 응용한
인터페이스가 구현되어 있었다. 하지만 어디에도 회계와 관련된 기능은
없었다.
스승이 이에 대해 묻자, 제자가 시큰둥하게 대답했다.
「 그렇게 급하게 재촉하지 마세요. 언젠가는 회계에 관련된 기능을 넣을
테니까요. 」

===============================================================================

5.4

훌륭한 농부가 자신이 심은 쌀 한 톨을 소홀히 하는 것을 보았는가? 훌륭
한 선생이 반에서 가장 어리석은 학생이라고 무시하는 것을 보았는가? 훌
륭한 아버지가 아이를 굶주리게 하는 것을 보았는가? 훌륭한 프로그래머가
코드를 고치는 것을 거부하는 것을 보았는가?

===============================================================================
관리

제 6권
===============================================================================

도사 프로그래머 가라사대 :

「 프로그래머는 많이 고용하고 관리자의 수는 줄여라. 생산성이 절로 향상
될 것이다. 」

===============================================================================

6.1

관리자가 끊임없이 회의를 하면 프로그래머는 게임을 짠다.
회계사가 사분기 이익에 대해 불평하면 개발 예산은 삭감될 위기에 처한다.
수석 과학자가 푸른 하늘을 논하면 바라 구름이 몰려든다.
아, 이것은 진정한 프로그래밍의 도가 아니다.
관리자가 결론을 내면, 게임 프로그램은 잊혀진다.
회계사가 장기 계획을 세우면 조화와 질서가 회복된다.
수석 과학자가 신경 쓰기 시작하면 문제는 곧 해결된다.
아, 이것이 진정한 프로그래밍의 도이다.

===============================================================================

6.2

프로그래머는 왜 생산성이 낮은가?
그들의 시간이 회의로 낭비되기 때문이다.
프로그래머가 왜 툴툴거리는가?
관리자가 지나치게 참견하기 때문이다.
프로그래머가 왜 하나씩 회사를 떠나는가?
지쳤기 때문이다.
무능력한 관리자 밑에서 일하는 프로그래머는 자신의 직업을 소중히 여기지 않는다.

===============================================================================

6.3

관리자가 해고될 위기에 처했다. 하지만 그 밑에서 일하던 프로그래머가
새로운 소프트웨어를 개발하여 큰 성공을 거두었다. 결과적으로 관리자는
자리를 지킬 수 있었다.
관리자는 보너스를 주려고 했지만, 프로그래머는 거절했다. 프로
그래머 가로되,

「 나는 이 프로그램이 재미있다고 생각했기 때문에 작성했을 뿐입니다.
그러므로 나는 아무런 보상도 바라지 않습니다. 」

이 말을 들은 관리자가 말하기를
「 이 프로그래머는 비록 비천한 자리에 있으나, 종업원의 맡은 바 책무가
무엇인지 잘 알고 있다. 그를 보조 관리자로 승진시키도록 하라. 」

그러나 이 말을 들은 프로그래머는 다시 한 번 거절하였다.

「 나는 프로그램을 짤 수 있기 때문에 존재합니다. 만일 승진한다면
다른 사람의 시간을 갉아먹게 될 뿐입니다. 이제 가도 됩니까?
지금 짜고 있는 프로그램이 하나 있거든요. 」

===============================================================================

6.4

관리자가 프로그래머를 찾아가서 말하기를
「 당신의 출근 시간을 조정하기로 했소. 이제부터 아침 9시에 나오고
5시에 퇴근하도록 하시오. 」
이 말을 들은 프로그래머들은 모두 분노하였고, 몇몇은 즉석에서
회사를 그만두었다. 그래서 관리자가 말하기를
「 좋아요. 그렇다면 작업 시간을 자유롭게 정하도록 하시오. 맡은 프로젝트를
스케줄에 맞게 끝내기만 하면 상관하지 않겠소. 」
만족한 프로그래머들은 이제 정오에 출근하여 이른 새벽까지 일했다.

===============================================================================
운용의 묘

제 7권
===============================================================================

마스터 프로그래머 가라사대 :

「 사장에게 컴퓨터 프로그램을 보여줄 수는 있다. 그러나 그가 컴퓨터 문맹에서
벗어나게 할 수는 없다. 」

===============================================================================

7.1

제자가 스승에게 묻기를
「 동방에는 본사라는 이름의 거대한 트리 구조가 있습니다. 그 트리 구조는
부사장과 관리자들로 지나치게 비대해졌습니다. 트리 구조는 < 이리 가라>
또는 < 저리 가라 > 는 메모를 무수히 내려 보냅니다. 하지만 아무도 그 메모의
진정한 뜻이 무엇인지는 이해하지 못합니다. 그 가지에는 매년 새로운 이름들이
나붙지만 결국엔 아무런 소용도없지요. 어떻게 이렇게 부자연스러운 존재가 있을
수 있습니까? 」
스승이 답하여 가로되,
「 너는 이 방대한 구조의 존재를 깨닫고,거기에 아무런 이성적인 목적도 없다는
사실에 당황하고 있는 것이다. 본사의 그 끊임없는 방향 전환에서 아무런
즐거움도 느끼지 못하겠느냐? 우리를 보호하는 가지 아래서 아무런 방해도 받지
않고 프로그래밍할 수 있는 즐거움을 깨닫지 못했느냐? 왜 본사의 존재가
무가치하다는 데 신경을 쓰는 것이냐? 」

===============================================================================

7.2

동방에는 어떤 물고기보다도 더 큰 상어가 있다. 이 상어는 대붕이라는
이름의 새로 변한다. 이 새가 일으키는 바람은 하늘을 가득 채우는 구름과도
같다. 대붕이 땅을 가로지르면 본사에서 보내는 메시지를 가져온다. 이
메시지는 갈매기가 해변에 떨어뜨리는 똥처럼 프로그래머의 수중에 떨어
진다. 그후 대붕은 바람을 타고 푸른 하늘을 등에 업은 채 집으로 돌아간다.
초보 프로그래머는 놀란 눈으로 대붕을 바라본다. 이해할 수 없기
때문이다. 보통 프로그래머는 대붕을 두려워한다. 대붕이 가져오는 메시
지가 무섭기 때문이다.
도사 프로그래머는 터미널 앞에 앉아 일을 계속한다. 대붕이 다녀
간 것을 알아차리지 못하기 때문이다.

===============================================================================

7.3

상아탑에 사는 위대한 마법사가 새로운 발명품을 스승 프로그래머에게 가
져왔다. 마법사는 거대한 검은 상자를 밀며 스승의 사무실로 들어왔다. 스
승은 조용히 그를 지켜볼 뿐이었다.

「 이것은 통합적으로 분산된 다목적 워크스테이션이요. 」
마법사가 자랑스레 말하기 시작했다.
「 인간 환경공학적으로 설계된 독점 운영체제와 제 6세대 언어, 그리고
복수의 최신 사용자 인터페이스를 탑재하고 있지요. 이 워크스테이션을
제작하기 위해 수백 명의 조수들이 몇 년이나 일해야 했소이다. 멋지지
않습니까? 」
스승은 눈썹을 약간 치켜 뜨며 대답했다.
「 정말 멋지군요. 」
「 본사에서는 모든 사람들이 이 워크스테이션을 이용해서 새로운
프로그램을 개발해야 한다고 지시했소이다. 그러시겠습니까? 」
「 물론이지요. 워크스테이션을 즉시 컴퓨터실로 옮겨 겠습니다. 」
스승이 말했다.
마법사는 만족하여 자신의 탑으로 돌아갔다.
며칠 후 제자가 스승 프로그래머의 사무실로 들어와서 물었다.
「 새로 짠 프로그램의 리스트가 어디 있는지 모르겠어요. 혹시 어디 있는지
아세요? 」
「 물론이지. 컴퓨터실에 있는 검정색 상자 위에 있다. 」
스승이 말했다.

===============================================================================

7.4

도사 프로그래머는 프로그램에서 프로그램으로 아무런 두려움 없이 옮겨
다닌다. 관리자가 어떻게 변해도 그의 위치는 변하지 않는다. 그는 프로젝
트가 취소되더라도 해고되지 않는다. 왜 그럴까? 도사 프로그래머는 도로
충만하기 때문이다.

===============================================================================
하드웨어와 소프트웨어

제 8권
===============================================================================

도사 프로그래머 가라사대 :

「 바람이 불지 않으면 풀은 움직이지 않는다.
소프트웨어가 없으면 하드웨어는 쓸모가 없다. 」

===============================================================================

8.1

제자가 스승에게 묻기를
「 한 컴퓨터 회사는 다른 회사들에 비해 월등히 큽니다. 난쟁이들 사이에
선 거인처럼 보입니다. 이 회사의 한 부서만으로도 산업을 일으킬 수 있을
정도입니다. 왜 그렇습니까? 」
스승이 답하여 가로되
「 왜 그런 어리석은 질문을 하는가?
그 회사는 크기 때문에 큰 것이니라. 만일 그 회사가 하드웨어만 만들었다면
아무도 사지 않았을 것이다. 그 회사가 시스템의 유지보수만 했다면,
사람들은 그 회사를 하인처럼 다루었을 것이다. 하지만 그 회사는 이 모든 일을
하기 때문에 사람들은 그 회사를 신으로 여기는 것이다! 그들은 남들과 경쟁하려
들지 않기 때문에 아무런 어려움 없이 세상을 정복하는 것이다. 」

===============================================================================

8.2

어느 날 스승이 제자의 곁을 지나치고 있었다. 스승은 제자가 휴대용 게임
기에 열중해 있음을 알았다.
「 미안하지만 내가 좀 볼 수 있을까? 」
스승이 물었다.
제자는 깜짝 놀라 게임기를 스승에게 건네주었다.
「 이 게임은 Easy, Medium, Hard 등 세 단계로 이루어져 있구나.
하지만 이런 게임기에는 또 다른 레벨이 더 하나 존재하고 있다.
이 레벨에서는 게임기가 사람을 정복하려 들지 않으며, 사람도
게임기를 정복할 수 없다. 」
스승이 말했다.
「 대단하십니다, 스승님. 」
제자가 탄성을 질렀다.
「어떻게 게임기에 또다른 레벨이 있다는 사실을 알아 내셨나이까? 」
스승은 게임기를 땅에 떨어뜨리더니 발로 밟아 버렸다.
그러자 갑자기 제자는 깨달음을 얻었다.

===============================================================================

8.3

개인용 컴퓨터로 작업을 하는 프로그래머가 있었다. 어느 날 그는 자신의
작업실에 놀러 온 메인프레임 프로그래머에게 자랑하기 시작했다.
「 나를 좀 보라고. 나혼자만 쓸 수 있는 운영체제와 하드 디스크도
있어. 컴퓨터 용량을 다른 사람과 나누어 쓸 필요도 없지. 소프트웨어는
성능이 우수할 뿐 아니라 쓰기도 편해. 왜 메인프레임처럼 불편한 환경에서
일하는 거지? 」
그러자 메인프레임 프로그래머는 자신의 시스템을 친구에게 설명하기 시작
했다.
「 메인프로그램은 컴퓨터실에서 명상하는 고대의 현인처럼 앉아 있다네.
그 디스크 드라이브는 마치 거대한 기게의 바다처럼 서로 연결되어있지.
소프트웨어는 다이아몬드처럼 다양한 면을 지니고 있으며, 원시림처럼
서로얽혀 있네. 각각 독특한 프로그램들은 마치 거세게 흐르는 강물처럼
시스템으로 들어왔다 나가지. 그게 내가 메인프레임을 좋아하는 이유라네. 」
개인용 컴퓨터 프로그래머는 이 말을 듣고 할 말을 잃었다.
하지만 두 프로그래머는 죽을 때까지 친하게 지냈다.

===============================================================================

8.4

갠지즈강으로 가던 하드웨어가 소프트웨어를 만났다. 소프트웨어 가로되,
「 너는 음이요 나는 양이로다. 우리가 함께 여행한다면 크게 유명해지고
많은 돈을 벌 수 있음에 틀림이 없도다. 」
그리하여 그들은 한 쌍이 되어 세상을 정복할 야심을 품게 되었다.
그들은 찢어진 누더기를 입고 가시나무 지팡이를 집은 채 절름거리는
펌웨어를 만나게 되었다.
펌웨어가 그들에게 가로되
「 도는 음과 양을 넘어 존재하느니라.
도는 호수의 물처럼 조용하고 움직이지 않느니라.
도는 명성을 구치 않으며, 따라서 아무도 그 존재를 알지 못하느니라.
도는 부를 구치 않으니,도는 그 자체로 완전하기 때문이니라.
도는 시간과 공간을 넘어 존재하느니라. 」
크게 부끄러워진 소프트웨어와 하드웨어는 집으로 돌아가고 말았다.

===============================================================================
에필로그

제 9권
===============================================================================

마침내 도사 프로그래머 가라사대 :

「 하산하거라. 」
===============================================================================

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

iamt의 이미지

내용에 놀랐습니다!
실컷웃었습니다! 고맙습니다
---------------------------------------------------------------------------------
C(++)과 php 펄등을 공부하고있습니다.
반갑습니다! 리눅스 :-)

---------------------------------------------------------------------------------
C(++)과 php 펄등을 공부하고있습니다.
반갑습니다! 리눅스 :-)

zootyguy의 이미지

siren99 wrote:
높은 사람에게 데모를 할수록 데모의 성공률은 낮아진다.
- Dan

프로그래밍상의 문제점을 편법으로 해결해 놓고 나면 그 편법을 사용했던 부분을 원칙적으로 수정해야 하고 그러는 도중 그 프로그램은 더 이상 쓸모없게 된다. - Thoreau

늦어지고 있는 프로젝트에 추가로 인원을 투입시킴은 개발을 더욱 지연 시킬뿐이다. - Brooks

시간에 맞추어, 주어진 예산범위 내에서 시작했던 인원이 끝마무리까지 하는 주요 프로젝트란 역사상 없었다. 당신의 프로젝트라고 예외일줄 아느냐 ?
- Putnam

납기일이 가까워 질수록 남은 업무량은 증가한다.
- Bove

오늘 소프트웨어공학 시간에 교수님께서 소프트웨어 세계에서의 명언들을 잠깐 소개해주시더군요.그 중에서 기억나는 것들을 적었는데...다른 명언들도 있지 않을까요? :D

경희대 학생이신가보네요? 저도 소프트웨어 공학 듣는데, 교수님께서 이거 보여주셨거든요 ^^

지금의 채찍질로 남는 상처는 결국 나 자신을 위한 것이다

irondog의 이미지

Premature Optimization Is The Root of All Evil.

- Donald E. Knuth

wather의 이미지

품질은 검사되는 것이 아니라, 계획되는 것이다.

체스맨의 이미지

wather wrote:
품질은 검사되는 것이 아니라, 계획되는 것이다.

이건 누구 말인가요? 지난 번 딱 이 문장하나로 요약되는 주장으로 팀장님과 의견을 좀 달리한 경우가 있었는데.

Orion Project : http://orionids.org

서지훈의 이미지

찬밥 wrote:
Hello World - Unknown

이건 저작권이 있는 걸로 알고 있는데...
저작권자 이름은 생각이 잘 나진 않지만...ㅋㅋ

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

creativeidler의 이미지

임시로 행한 결정이 가장 오래 간다.

체스맨의 이미지

wather wrote:
품질은 검사되는 것이 아니라, 계획되는 것이다.

찾아보니 누가 한 말이 아니라 품질관리의 신조라는군요. 매우 좋은 말이라 생각됩니다.

http://cybil.tafe.tas.edu.au/~andym/projects/pmbok/project8.htm#Chapter 8

Quote:

The quality planning techniques discussed here are those used most frequently on projects. There are many others that may be useful on certain projects or in some application areas. The project team should also be aware of one of the fundamental tenets of modern quality management—quality is planned in, not inspected in.

Orion Project : http://orionids.org

yielding의 이미지

Quote:
Hello world

트리나 폴러스의 "꽃들에게 희망을" 이라는 책에보면 옛날에 줄무늬진 작은 애벌레 한 마리가 오랫동안 자기의 둥지였던 알을 깨고 세상에 나올때 "Hello world"는 인상적인 대사를 합니다.
제 추측으로는 볼랜드의 터보(파스칼,C)시리즈 팀의 예제를 맡은 사람이 이 책의 애벌레의 대사가 좋아서 .. 무단으로 인용한게 아닌가 생각됩니다.. (아이디어나 의미로 봤을때 제 추측이 상당히 유력하다고 생각합니다만.. :D) )

아 요즘 취침이 늦습니다. 아들이 잠을 늦게 자서..

Life rushes on, we are distracted

Prentice의 이미지

이 글을 읽고 11년 가까이 궁금했었는데 원조(?) 출처는 다른 만화일 가능성이 높겠습니다.

http://forbesindia.com/interview/special/brian-kernighan-no-one-thought-c-would-become-so-big/29982/1

세벌의 이미지

ddoman wrote:
KISS( Keep It Simple, Stupid )

유닉스 철학의 모든것을 담은 멋진 말이라고 생각합니다.

Keep It Simple and Small 로 알고 있었는데 :?:

Prentice의 이미지

sebul wrote:
ddoman wrote:
KISS( Keep It Simple, Stupid )

유닉스 철학의 모든것을 담은 멋진 말이라고 생각합니다.

Keep It Simple and Small 로 알고 있었는데 :?:


http://en.wikipedia.org/wiki/KISS_principle

"Keep it simple, stupid." 여기서 컴마 이후는 호칭어입니다. And를 붙여서 stupid가 형용사임을 나타내는 것이나 and도 붙이고 stupid를 small로 바꾸는 것은 완곡어법(?)이 필요할 때 사용됩니다. RTFM에서 F를 fine으로 풀이하는 것과 유사하게 보시면 됩니다.

Prentice의 이미지

yielding wrote:
Quote:
Hello world

트리나 폴러스의 "꽃들에게 희망을" 이라는 책에보면 옛날에 줄무늬진 작은 애벌레 한 마리가 오랫동안 자기의 둥지였던 알을 깨고 세상에 나올때 "Hello world"는 인상적인 대사를 합니다.
제 추측으로는 볼랜드의 터보(파스칼,C)시리즈 팀의 예제를 맡은 사람이 이 책의 애벌레의 대사가 좋아서 .. 무단으로 인용한게 아닌가 생각됩니다.. (아이디어나 의미로 봤을때 제 추측이 상당히 유력하다고 생각합니다만.. :D) )

아 요즘 취침이 늦습니다. 아들이 잠을 늦게 자서..


위키피디아에는 브라이언 커니헌이 B에 대한 매뉴얼을 작성하면서 사용한 것이 hello world 프로그램의 시초라고 하는 것 같았습니다. 그게 1973년의 일이예요.

"꽃들에게 희망은"은 1973년 5월 1일에 나왔습니다만, 그 전에도 hello world의 용례가 없지는 않을 것 같습니다.

cdpark의 이미지

myduck wrote:
소프트웨어 명언은 아니지만
성당과 시장에서도 인용된 글인

"완벽한 설계는 더 이상 추가할게 없는게 아니라, 더 이상 제거할게 없는것이다."

항상 프로그램짜다 보면 쓸데 없는 변수와 코드들이 들어 가는걸 보면
아직 이대로 못하고 있는거죠.

KLDP에서의 제 서명이죠. :)

덤으로 최근에 본 멋진 말은..

Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

cinsk의 이미지

sugarlessgirl의 이미지

Quote:
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

우와화하아화하화화홧하화하!!!! 최고의 말입니다!!

zienie의 이미지

TAO of Programming 을 다시 한 번 쭈욱 훑어 보다가...

지금 제 상황을 대변해주는 말이 있길래.......

무능력한 관리자 밑에서 일하는 프로그래머는 자신의 직업을 소중히 여기지 않는다.

##########################################################
넘어지는건 아직 괜찮다.
하지만 넘어질때마다 무언가를 주워서 일어나자.

impactbar의 이미지

최적화에 관해

1. 하지마라

2. 꼭해야 된다면 최대한 미뤄라.

자바 이펙티브 ^^;

버려진의 이미지

impactbar wrote:
최적화에 관해

1. 하지마라

2. 꼭해야 된다면 최대한 미뤄라.

자바 이펙티브 ^^;

마음에 드는 말이에요. :lol:

pool007의 이미지

납기는 생명이다. - 국내 모 SI 대기업 회사

--
Passion is like genius; a miracle.

cooper의 이미지

impactbar wrote:
최적화에 관해

1. 하지마라

2. 꼭해야 된다면 최대한 미뤄라.

자바 이펙티브 ^^;

이게 제 철학인데...
현재 제 위에 관리자로 있는 그 분의 철학과 정면 위배 됩니다.

우째야 하나...
-------------------------------- 평상심...

sirjanus의 이미지

pool007 wrote:
납기는 생명이다. - 국내 모 SI 대기업 회사

맨날 듣는 소리가 납기는 생명이고 품질은 자존심이다....입니다.
우리 회산가 ㅡㅡㅋ

열한시면 이른 퇴근이지.

Yuricube의 이미지

아주 오래 전에 프로젝트에 실패한 선배가 자기 위안을 위해서 인지...
이런 말을 하더군요.

개발에 실패한 개발자는 용서해도, 백업에 실패한 관리자는 용서 못한다.

다음 날 그 선배는 사장실에서 이런 말을 했다 하더구요.

사장님 용서해 주세요...

그 시절, 나의 말은 노래였고, 나의 걸음걸이는 춤추고 있었다.
하나의 리듬이 나의 사상과 나의 존재를 다스리고 있었다.
나는 젊었던 것이다.
- 지이드 -

violino의 이미지

"Never joke close to due date"

- 김규만

엊그제 동료랑 같이 퇴근하려고 일어섰는데 보스가 가는 사람을 멈춰세우고 묻더군요.

"Is there any progress?"

제가 장난기가 동해서 이렇게 대답했지요.

"Sure, we've got exception"

"What?"

"There's exception in communication."

맨날 진행상황을 물어보는 인도인 보스한테 장난 좀 쳐 볼까 하고 한 말인데,
그만 그 말을 아주 심각하게 받아들이는거예요.
집에 가려고 일어난 우린, 지나가던 백인 사장까지 합세해서,
그 에러에 대한 질의와 자기가 생각한 해결 방안및 대안까지
한 20분동안 서서 듣고 대답해야 했어요.
엄청 후회했죠. 릴리즈 기일이 다가오는데 이런 말을 하다니..
보통 미국 회사에서는 평소에 농담을 무지 많이 하거든요.

지금도 원숭이 인형 하나가 천장에서 내려온 줄에 목매달려 있어요.
줄에는 이렇게 붙어있고요. "This rope/cord is VC++"

암튼 오늘 동료랑 이야기하면서 내가 그랬죠.
어제 그 일에서 큰 교훈을 얻었다고요.

"Never joke when it's close to due date"

그랬더니 미국 친구들이 이 말을 넘 좋아하네요.
자기 칠판에 전부 적어놓고 난리났어요.
암튼 프로젝이 잘 끝나야 할텐데...
오늘도 무사히..

[/img]

댓글 첨부 파일: 
첨부파일 크기
Image icon 0바이트
idlock의 이미지

riot의 이미지

Quote:
There is no silver bullet.
dotri의 이미지

Keep it Simple and Short 으로 알고 있는 전 이상한건가요..

최대한 짧고 간결하게!

dawnsea의 이미지

푸르스름한 표지의 시스템 프로그래밍 책 머릿말에서 본 기억이..

백문이 불여일RUN.

오래된 책인데;;

dotri의 이미지

dawnsea wrote:
푸르스름한 표지의 시스템 프로그래밍 책 머릿말에서 본 기억이..

백문이 불여일RUN.

오래된 책인데;;

가남사의 터보C정복으로 기억합니다.
"백문이 불여일견, 백견이 불여일행" 이라고..

marzok의 이미지

'자칫 trial and error를 조장하는건 아닐까?'라고 걱정 해봅니다.

코드를 작성할때 논리적인 오류가 없는지 깊은 생각을 해야 할때가 있는데 일단 돌리고 보자 식으로 나올수도 있으니 말이죠.

물론 일단 돌리고 보자식으로 쓴 표현은 아니겟지만, 그렇게 오해 할까봐 두렵습니다.

dawnsea의 이미지

dotri wrote:
dawnsea wrote:
푸르스름한 표지의 시스템 프로그래밍 책 머릿말에서 본 기억이..

백문이 불여일RUN.

오래된 책인데;;

가남사의 터보C정복으로 기억합니다.
"백문이 불여일견, 백견이 불여일행" 이라고..

그 말도 있었네요.
제가 본 건 지금 책꽂이를 디벼보니.
정보문화사의 PC시스템 프로그래밍. 이라는 책이군요.
너무 오래된 책이라;; 뭐 허클리스, 마우스, 인터럽트.. 이런거 조작하는 어셈, C 책..

napro의 이미지

"Nine women cannot make a baby in one month."
- Kent Beck :idea:

cppig1995의 이미지

프로젝트 관리의 10대 명제 wrote:
언제나 납기일은 코 앞이요,
완성은 오리무중이리라.

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

binul의 이미지

It's confusing because it's confused -- Petzold

--------------------------------
그래날아보자꾸나

totohero의 이미지

파레토 법칙을 SW에도 적용하자면,

코드의 80%를 완성하는데 초반 20%의 노력이 필요하며 나머지 20%를 완성하는데 마지막 80%의 노력이 필요하다.

alone의 이미지

내일은 내일일뿐.....
1. 안되는거 없다. 시간과 돈이 들뿐.. 전직장동료1
2. 컴퓨터는 거의 거짓말 안한다.. 전직장동료2

내일은 내일일뿐.....

magingax의 이미지

...

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

shint의 이미지

퍼갑니다. ㅇ_ㅇ''

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

semmal의 이미지

"아름 다움은 첫번째 테스트다. 이 세상에는 못생긴 수학이 영원히 차지하고 들어 있을 자리가 없다". G.H. 하디 <어느 수학자의 변명>
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

hmmhoho의 이미지

개인용 컴퓨터의 메모리는 640KB면 충분하다...

e^(pi*i) + 1 = 0 이 얼마나 아름다운 공식인가?!

jeamvfs의 이미지

저.. 댓글 삭제 버튼은 어디 있나요??

사랑_성공은 여행

사랑_성공은 여행

kmsr819의 이미지

"아이를 낳는 일에는 9개월의 시간이 걸린다. 아무리 많은 여자들이 동원된다 하더라도." - The Mythical Man-Month (Addison-Wesley, 1975)

kmsr819의 이미지

하고...

백문이 불여일run
백문이 불여일타(직접 쳐보란거죠)

pinebud의 이미지

Anything can go wrong goes wrong..

A rose is a rose is a rose..

icebird의 이미지

배터리가 있어서 전원이 나가도 안꺼지니까...

-자작...

거기 돌던지지 마세요 ㅠㅠ

rubenz의 이미지

고객은 인공지능보다 이쁜 버튼에 더 감동한다.

零Rei의 이미지

Quote:
고객은 인공지능보다 이쁜 버튼에 더 감동한다.

처음에는 이런 기능들이 필요하다고 설명하지만

가면 갈수록 보는건 UI밖에 없는듯 합니다.

특히 전산과 멀면 멀수록

직위가 높으면 높을수록..

그런의미에서

Quote:
높은 사람에게 데모를 할수록 데모의 성공률은 낮아진다.

이것도 정답인듯.

zeemeen@kldp.org의 이미지

student personal id를 간단히 만들어야 나중에 삽질하지않는다. 대략 이른 뜻이 아닐까?

jjjajh의 이미지

1소대3중대24번훈련병03-760749051대대todqud
386zjavbxj sjsms286zjavbxj sksms?~~!!
거기까지..~~!
ㄲㄴ?
전화번호
난하는데 넌 모(n..~~?m)한다??~~!
rkwkrndy
ㄲㄲㅆ?????
별들의전쟁
세계의별들의전쟁
누군가의전쟁
나의전쟁
그분의전쟁
1

1소대3중대24번훈련병03-760749051대대todqud

jjjajh의 이미지

누구시죠?

1소대3중대24번훈련병03-760749051대대todqud

dptmrns852의 이미지

싱클레어용 마이크로 이맥스를 짜셨다고요? 멋지군요, 여기 오백원입니다, 가서 맛있는 거라도 사 드십시오.

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.