시는 걸작이 아닐 바에는 아예 존재하지를 말아야 해.

그래서 최고의 작품을 만들어 낼 소질이 없는 사람은 예술의 길을 단념하고 예술을 해보고 싶다는 유혹에 빠지지 않도록 각별히 조심해야 해. 물론 사람은 누구나 자신이 본 것은 무엇이든 따라해 보고 싶은 막연한 충동을 느끼지. 하지만 그건 정말 욕망일 뿐이지 실제로 그런 능력이 자신에게 있다는 뜻은 아니거든.

그런데 줄타기 묘기를 부리는 광대들이 마을에 오기만 하면 온갖 판자나 목재 위를 왔다 갔다 하면서 몸의 평형을 잡아보는 아이들을 생각해 봐. 다른 자극을 받아서 그것과 비슷한 장난으로 옮겨 가기 전까지는 그 짓을 그만두지 않아.

그리고 유명한 연주가가 연주회를 열 때마다 그 악기를 배우기 시작하는 사람들이 꼭 생긴단 말이야. 얼마나 많은 사람들이 이런 식으로 인생의 길을 잘못 드는지, 자신의 소망을 재능으로 착각했다는 사실을 일찍 깨닫는 사람은 그나마 행복한 편이라니깐.

빌헬름 마이스터의 수업시대 2권 2장에서 발췌

한동안 니체의 글만 탐독하다가 괴테로 넘어온지 며칠 째.

괴테는 따뜻하게 느껴진다.

그런데 머리를 안감았네요.. -_-;

소나티네 앨범 7번 Kuhlau Op.55-1

소나티네 앨범 10번 Kuhlau Op.20-1

디지털 피아노의 장점을 살려 audio in/out 케이블로 녹음하여 깔끔한 소리를 제공하면 더 좋겠지만, UCC 기분을 잘 표현하기 위해 계속 디캠으로만 찍습니다. 헤헤.

이 방법은 몇가지 면에서 대단히 효율적인 방법이었다. 요구사항 미팅이 끝나면 머리속에 설계안이 완성되기 때문에 미팅이 끝나자마자 바로 코딩으로 돌입할 수 있는 장점도 있고, on the fly로 설계를 하기 때문에 첫 미팅 자리에서 효과적인 질문을 꺼내놓을 수 있기 때문이다. 게다가 후 설계작업을 위한 생동감 넘치는 문서를 작성할 필요가 없었다. 그저 기억이 왜곡되는 것을 방지하는 메모 정도면 충분하기 때문이다. 

그런데 이 방법에는 몇가지 단점이 있다. 

첫째, 그는 바로 바로 설계를 해야하기 때문에, 요청사항을 듣고 바로 설계를 할 수 없을 경우 ‘고민하는’ 표정이 고객에게 노출된다. 고객은 이 자가 바로바로 설계하기 때문에 표정이 일그러졌다고 생각하지 않는다. 오해를 양산한다. 

두번째, 고객이 말한 어떠한 항목이 자신의 캐퍼에 속하기는 하지만 고객이 세부사항을 지정하지 않았고, 각 세부사항에 따라 설계안이 꽤나 바뀔 경우 이 설계자는 고객에게 세부사항을 요구하고 싶어진다. 그래서 종종 미팅 자리에서 세부사항을 고객에게 묻곤 하는데, 고객이 당황스러워하지 않을 수 없다. 때로는 고객의 자존심이 쎈 바람에 세부항목에 대한 답변을 미루지 않고 그 자리에서 답해주는 경우도 있다. 이러한 답변은 충분한 사고과정을 거치지 않았기 때문에 정확도가 산으로 갈 수 밖에 없다. 고객이 완벽하리라는 상상을 했으니. 

세번째, 설계자 본인의 model pool이 확장되기 어렵다. 대화 중 incremental로 model pool에서 select를 하고, 데이터가 존재하지 않을 경우 자신이 가진 model 중 가장 근접한 것을 선정하여 요구사항을 자신의 model에 맞춰가기 위해 고객과 협상을 시도할 경향이 높기 때문이다. 위험한 점은 이미 잘 써오던 model 을 끄집어내서 협상을 시도하기 때문에 고객이 넘어갈 확률이 높다는 것이다. 결국 이 설계자가 자신의 model pool을 확장하려면 스스로가 정한 별도의 훈련 기간을 거쳐야만 한다. 왠지 부자연스럽다.  

철저히 소비 위주의 설계자라 할 수 있겠다. 큰 소비에는 큰 생산이 뒤따른다. 자연스러움을 잃은 행동을 일삼는 그는 고수준의 자기관리가 뒷받쳐지지 않는한 쉽게 지칠 것이다.

Software Creativity 2.0

아휴 버릴 게 없다. 버릴 게 없어. 

Effective Java 1판 이후로 이렇게 임팩트 넘치는 책을 읽어본 적이 없다. 

저자의 의도를 떠나서, 이 책을 읽다보면 여러가지 side effect (긍정적인) 도 얻을 수 있다. 내가 얻은 가장 큰 이점은 이 책의 내용들 중 일부분이 내가 프로그래밍할 때 피하지 못하고 견뎌내기만 해야했었던 많은 부정적인 느낌들을 말끔하게 패치해줬다는 데에 있다. 

이렇게 진지한 측면을 포함하고 있으면서도, 책을 읽는 중간중간 웃고 울고.. 

이 책을 구매토록 인도해주신 gEEkInsIdE님의 포스팅에게 무한한 감사를. 

인용구 몇개 건질 수 있지 않을까 하며 이 포스트를 여신 분들을 위해 레퍼런스 아티클 몇개와 인용구 몇개를 준비한다. 

 비자아적 프로그래밍 (ego-less programming) 십계명

 우수한 설계자는 하향식이 아니라 편의적으로 설계한다 하지만 설계자가 아닌 사람은 설계 과정에서 창의적이고 편의적으로 넘나드는 사고의 흐름을 이해하지 못한다. 그래서 우리는 설계를 하향식으로 위조해서 기술한다. 문서를 읽는 사람에게 설계를 이해시키는 유일한 방법이기 때문이다. 

 문제는 고 파루틴 문제가 있고 저 파루틴 문제가 있다. 해법은 고 파루틴 해법이 잇고 저 파루틴 해법이 있다. 사람은 고 파루틴 사람이 있고 저 파루틴 사람이 있다. 마지막으로, 프로젝트도 고 파루틴 프로젝트가 있고 저 파루틴 프로젝트가 있다. 

“내 말은 정형주의가 우리의 가능성을 제한한다는 뜻이다. 우리는 정형 기법을 넘어서 조직 안에서 그리고 소프트웨어 설계 안에서 서로 소통하는 방법을 익혀야 한다. 불분명하고, 부정확하고, 정형화가 불가능한 접근 방식, 즉 우리가 일상적으로 활용하는 접근 방식에 관심을 기울일 때가 왔다.” 

Better Is The Enemy of the Good Enough

흔히 복잡성과 모호성을 능숙하게 처리하는 인물은 약자로 여겨지는 반면 흑백논리를 강하게 펼치는 인물은 강자로 여겨진다는 사실이 흥미롭다고 테트락은 지적한다. 물론 그는 오히려 반대라고 주장한다. 

내가 아는 한 프로젝트가 성공하는 방법은 단 하나다. 능력 있는 팀장과 팀원을 확보해서 문제를 정확히 이해하게 만든다. 문제를 명세할 필요는 없다. 별도로 시나리오를 작성할 필요도 없다. 문제를 해결할 당사자들이 요구사항을 정확히 이해하면 그만이다. - Frosch 1969 

다시 말하겠다. 중요하니 집중하기 바란다. 상위 CASE 도구 대다수는 표현 활동을 도와주는 도구일 뿐 표현을 생성하는 지적 활동을 도와주는 도구가 아니다. 두 가지는 전혀 다른 활동이다. 하나는 문제를 이해하고 설계를 수행하는 활동으로, 상당히 지적이다. 다른 하나는 도표를 그리고 명세와 설계를 저장하는 활동으로, 대체로 사무적이다. 

학계 사람들에게는 흥미를 추구하는 태도가 윤리다. 업계 사람들에게는 유용성을 추구하는 태도가 윤리다. 

그리스인은 작성할 문서를 최소로 줄이고, 로마인은 최대로 늘이며, 야만인은 문서를 안 만든다는 사실에 자부심을 느낀다. 

흡족하다.

아무리 IDE가 좋아졌다할지라도 라디오 버튼, 체크 박스, 콤보 박스, 텍스트 필드가 적절히 섞여 30여개의 입력 필드가 한 화면에 펼쳐져 있다면.. 유쾌하지 않다.

여기에 한 필드라도 고쳐지면 ‘Save’ 버튼이 활성화되어야 하고 그렇지 않다면 비활성화 되어야 한다는 요구가 들어온다면?

부들부들.

리플렉션의 이름으로 그대를 처단하겠다.

이 글은 스프링노트에서 작성되고 살짝 고쳐졌습니다.

코딩을 하고 있다는 것은, 프로젝트의 신경써야만 하는 수많은 이슈들을 잠시 가방에 넣어두고 한순간에 하나씩 집중하여 달리는 것을 말한다. 적어도 내게 코딩하고 있다는 것은 그런 것을 의미한다. 한번에 하나에 집중. 나머지 사항들은 머리속에 있지만 주의력은 전혀 할당되지 않는 그런 상태.

기술 관련 서적을 보거나, 자기관리 책을 보거나, 책들은 ‘좋은 책’이라는 뱃지도 받아야하기 때문에 한 우물만 파는 경우가 별로 없다. 그래서 양서를 보거나 기사를 보면 주의력의 범위가 아-주 넓어진다. 마치 완벽하지 못하지만 열등감에 휩쌓인 완벽주의자처럼. (이라고 쓰고 산만해진다고 읽는다)

그래서 코딩을 하려고 딱 앉으면,

자각하고 있던 모든 것들을 버려야 하기 때문에 (파울로 코엘료의 소설에 나온 열정은 과거에 속하는 모든 것들을 파괴해버린다 가 생각나기도) 코딩에 제대로 몰두하기 어려워진다.

나의 경우 집중이 아주 잘되어, 흔히 ‘Flow’ 상태에 빠지게 된 경우를 생각해보면 다음과 같다.

• 몸이 아플 때 (여러가지 ‘하면 좋은 것들’에게 신경을 쓸 여력이 없다)
• 코딩해야하는 어떤 기술이 잘 안풀려서 화가 아주 많이 나 있을 때 (코딩에 집중하도록 마음이 알아서 움직여준다)
• 코딩해야하는 그 대상이 재미있을 때 (와이프랑 노는 것이 더 재미있다)
• 안하면 안될 때 (안하면 안된다는 긴장감이, 신경써야하는 다른 모든 것들을 잊게 해준다. 왜, 긴장하면 평소에 잘 하는 것들도 다 까먹지 않는가!)

코딩은 너무 마이크로 하다.

그렇기 때문에 쉬운 개발 언어들이 속속 등장하는게 아닐까 싶다. 마이크로한 곳에 오래 집중하고 있으면 개인 생활이 제대로 돌아갈리 없으니까.

그런데 실력이 미천한 탓인지, 아무리 프로그래밍 언어가 센스있고 API가 잘 설계되어있고 학습 코스트가 0에 가깝자 할지라도, 코딩은 코딩이다. 신경을 써야 한다. 관심과 관리가 없으면 말라죽는 화초처럼, 신경쓰지 않으면 시름시름 앓다가 죽어버린다.

그래서 나의 선택은 코딩 작업을 좀 더 추상적으로 만들기보다는, 마이크로와 매크로 레벨을 넘나들 수 있는 인간이 되는 것이였다. 쉽지 않다. 마이크로 해지면 성질도 더러워지고… 매크로 해지면 자잘한 버그들도 못잡고.. 확장성이나 유연성도 고려하지 못하고..

그럼 결국 나는 열정을 가지고 코딩을 한다는 얘긴데, 이것 상당히 위험한 일이 아닐 수 없다. 열정이 있을 때는, 그것이 없는 사람과는 비교할 수 없을 정도로 좋은 퍼포먼스를 내주겠지만, 만약 상황이 좋지 않아 마이크로 레벨로 돌입할 수 없다면 일 진행을 거의 못하기 때문.

분명히 마이크로 레벨에서 하던 일들을 ‘정보화’ 시켜서 매크로 레벨의 인간인 나에게 자습시킬 수도 있을텐데,

이상하게도 나의 국어실력이 부족해서인지, 마이크로 레벨 상태에서 내가 발산하는 메시지들을 매크로 레벨의 내게 전달할 방도를 찾지 못하고 있다. 분명히 이 둘은 다른 사람이다. 이 두 종단간의 메시징은 어떻게 처리해야 하는 것일까.

SOAP? -_-

이 글은 스프링노트에서 작성되었습니다.

나름 퇴행이 아니라 이것이 진정 성숙하고 지혜로워진 것이라고, 실수를 통해 Not TODO 목록을 만든 것이라며 자위했을 뿐이다.

요즘 무언가에 열중하다보면 묘한 기시감을 느끼게 된다. 발전하고 성장한 짜릿한 기분인데도 불구하고, 언젠가 느껴본.
16년전에 이뤘던 것을 되찾고, 8년전에 깨달은 것들.

종합평가를 한다면 그동안 헛짓했음이 발각된 사건일뿐이겠지만, 나는 잠시 분열하여 스스로를 평가하는 사람이기 이전에 현재를 살아가고있는 사람이라 기분이 좋다.

다시 비평가로 변신해보면,
개개인의 인생에 정답따위 없는데 뭐그리 호들갑.

마치 영향력있는 누군가가 자신에게 “이런 기능 구현 가능한가요??” 라고 물었을 때 자존감을 올리기 위해 앞뒤 안보고 구현하는 아가 마인드를 떠올려보라.

이런들 어떠하고 저런들 어떠하리.

코드가 지저분해서 짜증이 올라오기 시작할 때부터 고쳐도 늦지 않다.

개발 도중 동료나 상사가 코드를 보며 부정적 메시지를 가할 때면, ‘겉멋만 신나게 들었구만’ 하며 비웃으면 땡.

프리랜서 프로젝트 하나를 진행중이라 swing질을 하고 있는데, 이녀석은 어떻게 된일인지 아직도 Generic 지원할 생각이 없다.  그나마 하나 찾은게 JTree 클래스에 있는 Enumeration<TreePath> getExpandedDescendants( TreePath ) 뿐이다. DefaultMutableTreeNode의 set/getUserObject 정도는 제네릭 지원해줘도 되는거 아닌가. 

그렇게  투덜거리다 미투데이에 투덜거리는 글을 올렸고, 친구들이 SWT/JFace로 넘어오라는 댓글들에 힘입어,

The Definitive Guide to SWT and JFace 

를 질렀습니다! (하지만 정작 SWT/JFace 에도 Generic 지원은 없음; )

그런데 SWT 랑 JFace API 문서만 보려니 어딨는지 모르겠어서..

cvs -d :pserver:anonymous@dev.eclipse.org/cvsroot/eclipse co org.eclipse.jface 
cvs -d :pserver:anonymous@dev.eclipse.org/cvsroot/eclipse co org.eclipse.swt 
vim build.xml, … <javadoc … excludepackagenames=”org.eclipse.swt.internal.*” … >

한 곳으로 묶어봤습니다.

이에 공유합니다.

다운로드는 여기(4.8M)서.

Cost(total) = Cost(develop) + Cost(maintain)

Cost(maintain) = Cost(understand) + Cost(change) + Cost(test) + Cost(deploy)

마이크로 레벨로 생각해보게 됐다. 나는 initial development 주기에 change, test, deploy는 꽤 신경쓰는 편이지만, understand는 신경쓰지 않는다는 것을 깨달았다. 왜냐하면 코드를 작성하는 시점에서는 모조리 이해하고 있으니까.

Learning what the current code does is the expensive part. (Location 627 [Kindle location])

일단 이해를 하면 (여기에 코딩하던 순간의 context를 머리속에 로드하는 것까지 합쳐서) 고치고 고친 것을 테스트하고 (테스트도 딱히 신경쓰는 것은 아니지만) 배포하는 것은 쉬운 일이다. 하지만 understand context는 선행조건일 뿐이고.

내 코드를 보며 이해하는데 시간을 많이 쏟은 사람들에게 이 자리를 빌어 사과의 메시지를.