써니의 一生牛步行

이런 건 카테고리를 정하기 좀 어렵습니다만... 일단 history (잡담?)로 분류하겠습니다.

어제 대학 동아리 게시판에서 후배들과 '신입생 교육 과정' 개선에 대한 토론을 했습니다. 매년 컴퓨터공학과 동아리에 신입 회원들이 들어오면, 관례에 따라 먼저 C 언어를 가르칩니다. 그리고, 여름 방학이 되면 하나씩 주제를 정해서 미니 프로젝트를 수행하게 하죠. 대략 10년 넘게 변함없는 커리큘럼을 유지하다 보니 도저히 시대에 뒤떨어진 것 같아서, '개혁'의 필요성을 제기 했는데 여러가지 의견들이 나왔습니다.

커리큘럼 구성에 대한 의견 뿐만 아니라, 어떻게 가르쳐야 좋은지, 배우는 입장에서 아쉬운 점은 무엇이었는지 다양한 의견이 오고 갔습니다. 좀 더 밀도 높고 체계적인 강의를 해야 한다는 주장을 했는데 찬성하는 의견도 있고, 대학 1학년 때 너무 많은 것을 가르치면 안된다는 의견도 나왔습니다. 무엇보다 '흥미'를 느낄 수 있어야 한다는 주장도 강하게 제기 되었죠. 저는 '재미'라거나, '아마추어로서 느끼는 즐거움', '퍼즐을 푸는 듯한 가벼운 느낌' 만으로 프로그래밍 기술을 배우기는 어렵지 않느냐는 반론도 내 놓았습니다.

무엇이 옳은 걸까요? 각자의 경험과 상황, 그리고 의지가 다르기 때문에 정답을 찾기는 어렵겠지요. 그래서, 후배들 개개인에게 스스로를 돌아볼 수 있는 설문을 적어 봤습니다. 아래 항목들에 대해서 주욱 답을 쓰고, 스스로 적은 답을 몇번이고 다시 읽어 보라고 했습니다. 춤을 배우는 사람들이 거울 앞에서 춤을 추고, 자신의 모습을 돌아보면서 자세를 교정하듯이... 자신의 현재 생각을 적어놓고 객관적으로 들여다 보면서, 진심을 파악해 보는 것도 괜찮지 않을까 생각합니다.

지난 주말 MT를 가서 새벽까지 술을 마시며, 젊은 친구들의 생각들을 들어볼 기회가 있었습니다. 성적에 따라 전공을 선택하기도 했고, 공부를 더하면 무언가 찾을지 모르다는 막연한 생각 혹은 창작하는 즐거움을 따라, 각자 다른 이유 때문에 동아리에 가입한 후배들입니다. 한 배를 타고 가면서도 어디로 가는지 무엇을 향해 가는지, 관성에 따르거나 혹은 혼란스러운 친구들에게 별 다른 얘기를 해줄 수는 없더군요. 자신을 돌아보라고 할 밖에요.

1. 왜 프로그래밍을 공부하는가? Just for fun or Make money, To be a star?

2. 장차 어떤 것들을 만들고 싶은가? 게임, 서비스, 어플리케이션, 보안 등

3. 프로그래밍을 공부하면서 어떨 때 재미 혹은 흥분을 느끼는가?

4. 프로그래밍이 지겨울 때는 어떻게 자신을 달래는가?

5. 만일 전공을 다시 선택할 수 있다면 컴퓨터공학과를 선택하겠는가?

6. 프로그래밍 기술을 연마해서 성공(돈, 명예, 지위, 권력 등)할 수 있다고 보는가?

7. 만약, 성공한다면 어느 정도의 성과(돈, 명예, 지위 기타)를 얻을 수 있다고 보는가?

8. 자신에게 프로그래머 로서의 재능(talent)이 있다고 보는가?

9. 재능이 없다면, 어떻게 보완을 하고 있는가?

10. 먼 훗날 컴퓨터 관련 일을 하지 않게 된다면 어떤 일을 하고 있을까?

11. 프로그래밍을 공부하면서 스스로가 자랑스럽게 느껴진 적이 있는가?

12. 스스로 제대로 나아가고 있다고 생각되는가?

13. 불안하다면 어떤 식으로 개선해야 한다고 보는가?

14. 이런 설문은 의미가 있는 것일까? 혹은 의미 없는 것일까?

15. 공부하면서 가장 어렵다고 느껴지는 기술은 무엇인가?

16. 당신은 낙천적인 사람인가, 아니면 회의론자인가? 혹은 현실주의자인가?

17. 혼자서 공부하는 것이 편한가 아니면 함께 토론하는 것을 좋아하는가?

18. 새로운 것을 만들어 내는 것에 흥미를 느끼는가 아니면, 남이 만든 것을 즐겁게 사용하는가?

19. 돈과 여유 중에서 어느 쪽을 선호하는가?

20. 질문이 많아서 짜증나는가 혹은 흥미로운가?


절대로, 답변의 내용이 중요한게 아닙니다.
모든 질문에 답을 내놓은 후에 자신의 감정 상태가 어떤지 가슴에 손을 놓아 보시길 바랍니다.
답답하다면, 뭔가 해법을 찾아야 겠지요. (알고 보면 프로그래머 전용 심리 테스트 이거든요. ^^;)

블로그를 통해 알게된 산골 님이 OOP에 대한 에세이를 쓰신다고 해서, 여러가지 주제를 가지고 의견을 나누고 있습니다. 제가 아는 것도 별로 없고, 독학으로 공부한 것들이 많아서 체계적이지는 못합니다. 그러니 틀린 내용도 있을 수 있습니다. 지적해주시면 감사하겠습니다. 추상화에 대해서 메일로 주고 받은 내용을 올려 봅니다.

산골님이 앞서 추상화에 대한 이야기를 블로그에서 언급하신 적이 있지요.

추상화의 고수가 되자. http://mckdh.net/213

 

저는 몇달 전에 소프트웨어 개발자 블로거들과 추상화에 대한 이야기를 나눈 적이 있습니다.

추상화와 실용주의 by 아시모프 http://silverktk.tistory.com/341

 

아시모프님 글도 초보자에게는 약간 어려운 편인데, 핵심은 소프트웨어 개발에서 있어서 '추상화 개념은 실용주의를 실천하는 것'이라는 것입니다. 좀 풀어서 이야기 해 보겠습니다.

 

추상화를 영어 단어로 표현하면, abstraction 입니다. 영어사전을 찾아보면 '비현실적 개념'이라는 설명이 첫번째로 나오는데 초보 개발자들은 추상화라는 단어를 읽고 비현실적이다, 모호하다라는 인상 혹은 느낌을 먼저 떠올리게 됩니다. 하지만, abstraction이라는 단어의 해석을 보면, '분리 혹은 제거'라는 설명이 따라 붙어 있습니다.

그리고, abstraction은 '요약'이라는 뜻도 가지고 있습니다. 석사 논문이나 박사 논문을 읽어보면 본문이 시작되기 전에 전체 논문을 요약한 글이 나오는 법인데 이것을 abstraction이라고 부릅니다. 이렇듯 추상화라는 단어는 한편으로 '모호함' 혹은 '불명확함'을 나타내지만 다른 면에서는 '단순화'라는 뜻도 가지고 있습니다. 적어도, 소프트웨어 공학 혹은 기술 영역에서 추상화라는 단어는 후자의 뜻으로 사용되고 있습니다. 그런데, 전자의 뜻으로 해석하면 추상화라는 개념을 받아들이기 곤란할 수 밖에 없습니다.

 

소프트웨어 개발 분야에서 '추상화'라는 단어 혹은 개념를 사용하게 된 계기는 무엇일까요? 아마도 '소프트웨어 위기(software crisis)'라는 사태가 벌어진 이후에 소프트웨어의 '재사용성'을 강조하게 된 시대부터 부각되었다고 추정하고 있습니다.

 

소프트웨어의 부품이 재사용 될 수 있으려면, 단순해야 하며, 여러 모듈에서 공통적으로 사용되지 않는 불필요한 코드들이 제거 혹은 분리 되어야 합니다. (단순함, 제거, 분리 등의 개념을 모두 포함하는 단어가 바로 추상화 인 것이죠.) 철학이나 예술에서의 추상적 개념은 구체적인 현실에서 벗어나는 것이지만, 소프트웨어 공학에서의 추상화 개념은 오히려 현실을 보다 완벽하게 수용하는 것이라고 생각합니다. (소프트웨어 공학자들은 단순한 것일수록 완벽하다는 사상을 가지고 있습니다.)

 

그렇다면, 위에 설명한 개념을 소프트웨어 코드 작성 시에 어떻게 적용해야 하는 것일까요?

 

상위 클래스를 제작하거나, 추상 클래스를 만들 때, 혹은 인터페이스를 제작할 때 개발자는 가급적 구상 클래스(concrete class)들을 최대한 많이 예측 혹은 작성 해봐야 합니다. 상위 클래스를 먼저 작성하는 경우가 많은데 저는 반대로 접근해야 한다고 생각합니다. 최대한 다양한 기능과 변화들을 열거해본 후에, 그중에서 공통적인 것들을 추출해서 상위 클래스 혹은 추상 클래스에 선언하는 것이 유리하다고 보는 것이죠. 즉, 변화하는 것들은 분리(제거)한 결과로서 남는 것이 상위 클래스라는 것이지요. 변하는 것들을 많이 포함할 수록 상위 클래스는 무너지기 쉽습니다. (fragile base class issue라고도 하지요.)

달리 말해서 '추상화'는 변하지 않는 것들을 도출하는 것이다라고 정의할 수 있을 것 같습니다. 구체적인 클래스들을 나열하는 것이 번거롭거나 투자할 시간이 부족하다면, 가급적 상위 클래스 혹은 인터페이스에 최소한의 기능 만을 선언하는 것이 좋다고 생각합니다. (나아가 추상 클래스 보다는 합성(has-a relation) 기법을 사용하는게 나을 수 있습니다. 상위 클래스 남용에 따른 문제는 다른 글을 통해 의견을 제시하겠습니다.)

 

변하지 않는 함수들을 상위 클래스에 선언한다고 해도, 함수들의 실제 동작은 하위 클래스에서 변화할 수 있는 겁니다. 그래서 더 강한 추상화 기법이 나오게 된 것이고, 인터페이스(interface)라고 합니다. (인터페이스에 대해서는 다음과 같은 글을 쓴 적이 있습니다.  http://sunnykwak.egloos.com/2911825)

 

이렇듯 추상화는 '변하지 않는 핵심'을 도출한다는 개념으로 이해하면 보다 쉽게 받아들일 수 있다고 생각합니다.

 

하지만, 여전히 추상화는 어렵습니다. 왜냐하면, '재사용 극대화'이라는 목표를 달성할 지라도 소프트웨어는 시간의 흐름에 따라 변화하는 것이기 때문에, 아무리 잘 만든 추상 클래스 혹은 인터페이스라고 할지라도 언젠가는 변경되지 않을 수 없는 것이죠. 어찌 보면 가장 완벽한 추상화를 달성하는 것은 미래를 예측하는 것과 같은 일입니다. 그러니, 지나치게 완벽한 추상화를 이루려고 애쓰는 것보다 적절한 수준의 '재사용'을 목표로 하는 것이 타당하다고 생각합니다.

훌륭하신 기획자 분들도 많이 알고, 정말 기획 하시는 분들 열심히 전략 수립한다는 거 아는데...
가끔 어이 없는 기획서를 받아들고 머리를 싸매는 일도 있다.
도대체 이 따위 기획서 던져 놓고, 나중에 안팔리면 프로그램을 개떡 같이 만들어서
그렇다고 책임 전가할 게 뻔한 잡다한 기획서 말이다.

작년에 한 건 당했고, 어제도 또 괴이한 기획서가 하나 날아 들었다.
이사 양반 왈, 그래도 아는 사람이 고심해서 만든 거니까 의견 좀 달아서 회신 해달란다.
이틀 동안 짬짬이 쳐다보다가... 도저히 안되겠다고 두 손 들고 기획서를 던져 버렸다.
괜히 잘못 손대면 혹 떼려다 혹 붙일게 뻔하기 때문이다.

일단 '사업 배경'이라는 이야기를 써왔다.

TV 광고 시장이 침체 되고 있고, 단방향 매체로서는 소비자의 흥미를 자극할 수 없다...
뭐 이런 건 길 가던 초등학교 학생한테 물어봐도 다 안다.
너 광고도 열심히 보니, 차라리 컴퓨터로 다운받아 보니?
라고 물으면 열에 아홉은 광고 없는 걸 선호한다...
그리고 구글을 깐다. 문맥형 광고는 '소비자의 감성'을 자극하지 못한다는 둥...

아.. 여기까지는 좋다. 그리고 광고 형태를 이야기 한다. 새로운 대안이 'PC Wall Paper'란다.
이게 도대체 언제 적에 써먹던 기법이냐고... 내가 90년대부터 IT 업계에서 종사해 왔는데
개발자도 단물 다 빠진 깡통인줄 아는 아이템을 가지고, 신선하다고 들이 밀다니...
게다가 특허도 출원하신 단다... 님아 쫌 자제 염...

그리고, 수익 모델이 빠질 수 없다.
네티즌들이 광고주가 제공하는 프로그램을 다운로드 받으면 포인트를 준단다.
광고주는 광고 노출 횟수에 따라 돈을 낼 것이고... 사용자는 돈을 번다.
이거 어디서 많이 본 사업 모델 아닌가? Gold Bank 가 문득 떠오르더라...

이게 기획안의 전부는 아니고, 컨피덴셜한 건 빼고 얘기하는 거지만...
그래도 이런 맥락으로 기획을 전개하는데 참 뭐랄까... 읽어주는 시간이 아깝더만...

내가 보는 문제는 대략 다음과 같은 것들이다.

1. 프로그램만 만들어 놓으면 네티즌들이 좋다고 다운로드 받냐?

- 소비자를 자극할 만한 컨텐츠를 어떻게 제작할 건데...? 헐벗은 여인네들 사진 올리면 다들 좋다고 다운로드 할까? 그런걸 사무실에서 배경 화면으로 쓸수는 없을 거고... 동영상 같은 거 제작하려면 드는 돈은 또 얼마인지 언급도 안한다.
- 좀 큰 회사 다닐 때, 우리 보스는 열심히 효리 만나러 다녔다. 효리 이름 걸고 쇼핑몰 하나 만들자고 말이다. 뭐든지 흥행을 하려면 사람들이 주목하는 '스타'라던가, '흥미거리'를 깔아줘야 하는거 아닌가?
- 요즘 대세는 소녀시대이니까, 소녀 시대 미공개 핫팬츠 전신 사진 같은 거라도 배경으로 깔아준다면 좀 흥행할지 모르겠다만, 그러면 SM의 대굇수 아저씨를 어떻게 설득할건가... 뭐 이런 진짜 알찬 얘기가 없다는 것이지...

2. 광고주는 어떻게 모을 것인가?

- 이게 또 만만치 않은 일인거라... 요즘 불황이네 어쩌네 하면서 PR 예산 다들 삭감한다는데...
- 앞서 제기한 문제를 해결하면 자연스럽게 몰려들지도 모르지만, 광고주가 많아야 사용자들도 포인트를 많이 받을 수 있고 그래야 또 흥행하는 문제인거라, 닭이 먼저냐 달걀이 먼저냐 문제가 아닐까? 이런 계획도 없으면 어쩌라고...

길게 얘기할 것도 없이 이런 문제들이 확연히 보이니 이건 기획서가 아니라, '광고판 설명서'라고 여겨진다. 모든 기획자 분들이 이런 것도 아니고, 기획자 분들을 비난하려고 쓰는 글도 아니다. 전략도 없이 그저 그런 전술만 가지고, 대단한 것이냥 부풀리는 사람들이 종종 있으니 조심하자는 얘기다.

세상 물정 모르는 초보 개발자들이 작은 회사에 들어가서 이런 사업 아이템에 대한 이야기를 들으면 분명 기술적으로 아무런 문제가 없고, 구현 가능한 것이니 개발해보고 싶다는 생각도 한다. 그리고, 잘하면 콩고물이라도 떨어질까 싶어서 젊음을 바쳐서 일하기도 한다. 그런데, 대체로 이런 기획은 설사 제대로 만들어져도 돈 못 번다.

다시 얘기하지만 이건 기획자들을 욕하는 얘기가 아니다. 오히려 개발자라고 하는 사람들이 너무 순진해서 빠지기 쉬운 함정이니 잘 피해가라고 하는 얘기다. 사실, 기획 좀 제대로 하시는 분들이 위 사례를 보면 저건 기획도 아니라고, 저런 걸 예시로 내세우면 안된다고 하실게 뻔한데... 그래도 의외로 저런 얼토당토 않은 얘기에 혹해서 젊음을 허비하는 친구들이 꽤 있다는 것도 현실 아닌가... 뒤집어서 얘기하면 해본 적도 없으면서 다 할줄 안다고 떠드는 개발자도 있는거고... 누가 누굴 욕하느냐가 중요한게 아니라, 어디에서나 사기꾼을 볼 수 있는 법이고 조심해야 하는 거지..

코드만 열심히 짤게 아니라, 세상 돌아가는 이치도 공부하길 바라는 마음에서 몇마디 지껄여 봤다. 요즘에는 삼국지나, 초한지를 읽어본 친구들 보기도 어려워서... 나는 개발자도 마키아벨리를 꼭 읽어 봐야 한다고 생각한다. 스티브 잡스나 빌 게이츠의 삶을 이해하려면 그렇다. 물론 리누스 토발즈나 제임스 고슬링 같은 양반을 닮고 싶다면 또 모르지만...

1. 국내 최고 수준의 강의

어쩌다보니 구독하는 메일링리스트에 모 협회에서 제공하는 '소프트웨어 개발자 무료교육 안내'가 포함되었는데,
국내 최고 수준의 강의를 해준다고 하는데 커리큘럼을 보면 눈물이 흐를 뿐이다.

웹 프레임워크 활용 - Struts 2, Ajax
객체지향 메커니즘 - 객체지향 프로그래밍 개요, J2SE 기본
임베디드 시스템 - ARM architecture 이해, 임베디드 프로그래밍 이해

부디 이런 교육을 하지 말라는 건 절대 아니고....
교육 대상이 '아키텍트와 설계자'란다.. 학부생도 아니고, 초보자도 아니고... OTL

WebKit 포팅, 안드로이드 폰 개발, 아이폰 어플리케이션 제작,
Cocoa 라던가, 분산 서버 시스템 구축, Objective-C,
루비, 그루비 뭐 이런 거 강의하는 곳은 찾아보기 힘들다.

저 강의를 왜 까는거냐 하면, 무려 '중소기업 무료' 교육이기 때문이다.
세금 가지고 운영 하는건데 어째 수준이 이러냐 싶고,
직원 교육 좀 보내고 싶어도 보낼만한게 없다는 것이 짜증스럽다.

2. WebKit 포팅을 준비하다보니..

한국 개발자들이 정리한 자료가 거의 없다. 이유는 무얼까 잠시 생각해 보니...

- 다수의 대기업에서 WebKit을 다루고 있다는 정보는 몇몇 루트로 얻었다.
업무 상 보안 문제로 외부에 노출하지 않거나, 포스팅할 시간이 없거나...

- 고급 개발자들은 영어 문서에 익숙해서 굳이 한국어로 번역할 필요성을 느끼지 못하거나...

- 어차피 번역해서 올려봐야 피드백도 없고, 토론도 없고... 기껏해야 '좋은 글이네요'라는
짤막하고 허탈한 덧글들이 올라올 게 뻔해서 안 쓰거나...

대체로 위 3가지 이유가 복합적인게 아닐까 싶다.

3. 미네르바 이야기

한국 사회는 뭐든지 빠르게 잊어 버린다.
새로운 이슈가 하나 터지면 과거의 문제들은 더 이상 논의의 대상이 되지 않는다.
이런 현상을 만들어낸 건 어느 정도 언론의 영향이겠지만...
인터넷이라는 새로운 매체를 통해서 과거의 사건들을 다시 되집어 볼 수 있다는 것이 다행이다.

대산님의 주장이 정말 옳은지는 모르겠지만, 결코 쉬이 잊혀져야할 사건은 아니라고 본다.

4. 동아리 MT

나이를 먹으니 밤새도록 술 먹는게 쉽지 않다. 그래도 새벽 5시까지 버텼음. T.T

5. 날씨와 예비군

무지하게 더운데 예비군 훈련 통지서가 날아 들었다. 7월 10일이라고... 어흑...

6. 레이 오지

Ray Ozzie. 그리고 10년 전 집나갈때 들고 나간 것들..

우리나라 개발자들에게는 약간 낯선 인물이지만...
그만큼 우리나라 IT 분야가 '우물 안 개구리'라는 반증으로 소개할만한 인물.
마이크로소프트 사의 제 2대 수석 아키텍트. 빌 게이츠의 후임자.

인터넷을 서핑하다 이런 글을 만날 때 마다, 묘한 흥분을 느낀다.
다른 자료를 검색하다가 정말 우연히 놀라운 글들을 만나게 되는데...

7. 오늘의 블로그 추천

카이스트 정보미디어 경영대학원 [KAIST KSIM] BLOG

소프트웨어 개발자 및 기획자 모두에게 추천합니다.

"학교 다닐 때 열심히 공부 안하면 나이 먹어서 고생한다..."

이런 말을 많이들 하고, 또 많이 듣고 살아 오기는 했는데...
잔소리 들을 때는 괜한 반항심도 치솟고, 인생 스스로 선택하는거지
꼬뚜레 꿰어서 살면 무슨 의미가 있나 하는 생각도 했더란다.

그런데, 막상 나이 먹고 보니 어려서 공부 안한걸 후회한다.

제목이랑 내용이 좀 매치(match)가 안되시는가?
요즘 주변 분들이 SOLID 원칙이라는 말을 하시는데 그게 뭔지도 몰라서 찾아보고
공부한다는 얘기인거지... 대학 다닐 때도 OOP 관련 서적이 나오기는 했는데...
당시 공부하던 원서 중에서 기억 남는 건 '모든 것이 객체다 (everything is object)' 라는
부처님 말씀 비스므레한 이야기들 밖에 없다.
졸업하고 나서는 밥벌이 하느라 바빠서 OOP를 체계적으로 공부 못했고...
(첫 직장에서 OODB 기술지원을 하기는 했지만, 그 때는 추상화도 제대로 이해 못했으니...)

각설하고~ 마이크로소프트웨어(잡지)에서 연재되는 기사를 zdnet 코리아
홈페이지에서 찾아볼 수 있다. 그런데 zdnet 내부에서 찾기는 어렵고...
(zdnet 코리아는 정말 '기술 정보 사이트'라면서 기술적인 완성도가 최악이다.)

다행히 어떤 분이 SOLID 원칙에 대한 강좌 링크를 모아 두셨다.

객체지향 SW 설계의 원칙

그런데, '원칙' 이라는 열심히 공부하고 달달 외우는게 꼭 좋은 건 아니다.
원칙만 알고 응용할 줄 모르면 아무 소용이 없는 것이고...
꼭 원칙을 책으로 공부하지 않아도 경험이 많이 쌓이면, 원칙을 자연스럽게 체득하기 때문이다.

다만 내가 원칙(원리)를 체계적으로 학습하려는 이유는
같이 일하는 동료 및 후배, 고객들과 대화하는데 있어서 좀 더 효율적인 대화 수단을 찾으려는 것이다.

독설가이신 어느 분은 다스베이더 왈, 'Luke, Use the Source!' 이라 했다며,
지나치게 장황한 이론은 불필요하다 말씀 하셨지만...
(스타워즈 패러디인데, 허락없이 인용해 봤습니다. 패러디 창작자가 지적하시면 빼겠습니다.)

그렇다고 서로 멀뚱멀뚱 쳐다 보다... 코드 만들어 보고 나서 '이게 아냐!'
하고 휴지통에 던져넣는 소모적인 작업을 반복할 수는 없지 않는가?

개발자들이 코드를 통해 소통하는 방식은 상대가 나와
경험과 이해력, 코딩에 대한 철학이 비슷하다면 별 무리 없겠지만...
자칫 서로의 자존심과 '가치관'까지 들먹이면서 감정 싸움으로 번지는 사태가 벌어질 수도 있고...
각자의 코딩 스타일에 대한 논쟁을 하느라 불필요한 시간을 낭비하게 될 수도 있다.

긴 설명과 코드 보다, 어느 원칙, 어떤 원리, 누구의 기법이라는 식으로 전달하면
소통하는데 드는 시간을 많이 절약할 수 있다.
만일, 적용한 원칙에서 문제가 발견된다면 '원칙의 블랙 리스트'를 만들면 된다.

주의해야 하는 건 '교조주의'에 빠져서는 안된다는 것이지만,
교조주의에 물든 바보를 상대 할 때는 오히려 편하다.
우리가 쓰는 기법은 무려 '유명하신 어느 대가' 분이 설파하신 '절대 진리'요, '절세 무공'이라고...
툭 한미디 던지면 더 이상의 불필요한 논쟁을 피할 수 있다.

덧붙여, 임백준 님의 글을 권해 드린다.

개발자의 초식, 디자인 패턴「그러나…」

마지막 한 줄 만 인용하겠다.

"프로그램의 ‘완성도’와 ‘미학’은 패턴 자체에 놓여있는 것이 아니라,
 그 패턴을 이용하는 프로그래머의 능력과 자세에 달려있는 것이다."

P.S.

이런 포스트에는 '누구를 계몽하려 드느냐! 네가 얼마나 잘났다고?' 라는 덧글이 붙기도 하는데...
'주장'과 '가르침'을 혼동하시면 안된다. '나는 왜 원리를 학습하는가'라는 주제의 자술서인걸...

보고 싶은 것만 보는 사람이 많아서, 참 여러가지로 눈치보며 산다. 국어가 어렵나?