Younghoe.Info v3

한 지인으로부터 받은 편지


후다닥 정리한 회신

어제 들은 말 중에 가장 인상적인 말인데, 역시 여제 읽은 채수원님의 글과 엮어서 기억을 뱉어두고 싶어서 글을 쓴다.


이 말을 듣는 순간 어쩌면 한글을 만든 일보다 이를 보급한 업적이 더 뛰어날지도 모른다는 생각이 떠올랐다. 채수원님의 글 중에 이런 구절이 있다.


이론/기술이 놓인 맥락이 실험실일 때와 현장인 경우는 이야기가 다르다. 처한 환경이나 맥락이 다르니까 당연한 소리다. 연구실의 기술이 현장에서 가치를 발현하기 위해서는 (실험실에서 발현했던) 본래 기술을 만들 때와는 다른 또 다른 노력이 필요하다. 당연한 이치인데 종종 우리는 잊어버린다.

InfoQ 기사(A Crash Course in Project Management) 내용에서 내공이 느껴져서 원 블로그에 가보니 테스트와 개발 원칙에 대해서도 좋은 글이 많다. 정리할 시간은 없어서 일단 올려두기만...

• Principles 1: The Essence of Driving – A Crash Course in Project Management
• Principles 2: Principles of Software Testing
• Principles 3: Principles of Software Development

1. 군(群) over 그룹
- 효율 좋음
- 오류 유발 가능성 낮음: 그룹, 구룹, 그릅, ...
- 그룹은 외래어
- 참조: 아름다움은 왜 진리인가에서 group을 군으로 번역

2010. 8. 12 밤부터
개체매니페스토라고 뱉어놓은 말이 있어서 즉흥적으로 실천함

세미나 혹은 강의중에 TDD(Test Driven Development)를 배우면서 익힌 교훈은 비단 프로그래밍에서만 효과를 발휘하지 않는다고 주장했다. 두서없이 일하는 모습을 감지했을 때 내 말을 부메랑으로 사용해서 Test-driven development cycle 을 적용해보았다. 무슨 소리냐? 작업범위에 대한 합의를 하기 위해 문서작업을 하려고, 진행 전에 구글 카렌더에 일정을 등록하며 목표와 작업 시간을 설정했다. 그런데 이전에 작업했던 파일을 찾기가 힘들었다. 디렉터리 관리를 엉망으로 해두었기 때문이다. 자연스럽게 디렉터리를 바꿔두려던 나에게 제동을 걸었다. Test-driven development cycle 을 떠올렸다. 지금 당장 목표한 작업(Test case)을 완수(Green Bar)하기 위한 일을 빠르게 먼저 수행하고, 업무 효율을 높이기 위한 일종의 리팩터링에 대항하는 디렉터리 변경은 그 후에 즐기기로 했다. 앗! 이 글도 빠르게 생각을 메모하려고 중간에 치고 들어온 행위(Interrupt)인데, Sepration of concerns의 위력을 믿기로 하자.

(진행중.. 생각의 흐름이 정결하지 못하고, 몸에 뵌 중복처리 습관 잠념 탓에... 인단 무지막지하게 어렵다.)

위 그림과 같이 프로젝트나 목적에 빠라 카렌더를 만들고 색깔을 주면 일정을 한 눈에 구분할 수 있다. 최근 추가한 개선은 미계획작업 카렌더다. 그림에서 회색인데, 인터럽트(전화, 갑작스런 요청)에 의해 벌어진 일을 추적한다. 당장은 효과가 없지만 점차 인터럽트의 비중을 시각화해서 보면 패턴이 보이고, 다시 하루 계획을 세울 때 도움을 준다.

두 번째는 다음에 읽어볼 글(URL을 즐겨찾기 하는 대신 일정을 잡아둔다)이나 메일(G메일 기준)의 경우 일정을 훗날 만들어두고 내용에 URL을 복사했넣는다.

문득 실험실 아이콘을 눌렀더니 활용해볼 소재가 등장한다.

일정 첨부 파일

원래도 메일이나 기사 URL을 내용에 붙여두는데... 구글닥스나 로컬 파일을 올릴 수(폴더는 뭐지?)가 있다니 유용할 듯하다. ^[각주:1] URL 삽입이나 메일 연계도 별도 필드로 추가하면 좋겠다.



일년 보기

InfoQ 기사(Designing Agile Spaces) 발췌

그리고 I love design thinking and the d.school space

협업이 아니더라도 즉, 혼자 일할 때도
넓은 공간이 효과를 발휘하는 경우가 있었다.
서로 다른 체계에 속한 개념을 서로 연결짓는 일을 할 때
색이 다른 포스트잇으로에 개념의 이름을 쓰고 서로 다른 벽면에 붙였다가
다시 새로운 벽면에 이들을 합칠 때... 넓은 벽면과
90도로 접하는 두 개의 벽면을 쓰니 근거리에서도 한 눈에 들어오면서도 양분되는 공간이 주는 효율은 대단했다.

어제 쓴 글은 투자한 시간 대비해 엉성하고 전달력도 의심스럽지만 소재를 떠올리는 시간이 즐거웠다. 블로그를 쓰면서 의무감(?)이나 경제성에 대한 강박관념(?)을 오랜만에 완전히 벗어난 경우다. 자연스레 생각이 '왜 블로그를 쓸까?'에 머물렀다. 최초 의도처럼 나중에 보기위한 메모 용도는 오래전에 지났고 어느 정도는 읽히기 위한 글을 쓴다. 이분법으로 구분지었을 때 단순히 '독자 위주냐 아니면 내 위주냐?'도 묻게 되고, '신변잡기냐 아니면 주제를 한정한 블로그냐?'도 묻게 되고, '진화를 생각하느냐 아니냐?'도 묻게 된다. 그러다가 적어도 일년 넘게는 본 적이 없던 블로그 통계를 보다가 흥미로운 사실을 찾았다.

2007년은 어림잡아 월평균 10만명이 방문했다. 그러다가 2008년부터는 급격한 하향세를 보였는데 추측컨대 티스토리의 방문자 통계 로직 보완이 이때쯤 일어난 듯도 하다. 일민형 분석에 따르면 국내외를 막론하고 트위터/미투/버즈 등의 등장으로 블로그는 급격한 사양세라고 하는데 십분 동의하고, 내 블로그의 사용자 감소 현상도 같은 맥락이라고 본다. 하여튼 2008년 중반부터 월 2만명선이던 방문자는 2009년 5월을 기점으로 만명이하로 떨어졌다. 그 추이는 그대로이어져서 현재 대략 9천명대이다.

블로그 구독자 이탈이 혹시 유명 블로거와의 온라인 충돌 행적탓은 아닐까 싶어 추적해보았지만, 뚜렷한 흔적은 보이지 않는다. 흥미로운 부분은 KSUG 행사 과정에서 마찰이 있었던 분이 유명 리눅스 커뮤니티의 리더격임에도 공방전은 블로그 흥행(?)에 별로 영향을 주지 않은 반면, SoC 개념을 가지고 자극적인 글을 써서 촉발한 닷넷쪽 유명 블로거와의 갈등을 전후해서는 방문자 통계에 굴곡이 선명했다. 아마 내 블로그 구독자 중에 닷넷 개발자는 많은 반면 리눅서는 상대적으로 드문 탓이 아닐까 싶기도 하다.

통계때문에 살짝 샛길로 빠졌는데... 요즘 좀 고민이긴 하다. 일상의 생각에 대한 메모는 버즈에 쓰기 시작한지 오래이니 블로그 대신 정제된 글을 드문드문 쓰는데 더 투자하는게 나을지... 뭐, 사실 이제는 블로그에 글도 자주 안 쓰지만..

일민(토비)형이 홍보대사라며 홍보를 종용하는 이유도 있기 하지만... 좋은 책이니까 그리고 얼마나 고생해서 만든 책인지 아니까 그렇다. 마침 이를 보여주는 글을 저자가 직접 쓰고 있다. :)

토비의 스프링 3이 나오기까지 (1)
토비의 스프링 3이 나오기까지 (2)
토비의 스프링 3이 나오기까지 (3)


토비의 스프링 3 -
이일민 지음/에이콘출판

얼마전에 밝힌대로 요즘 책을 사는 패턴은 매우 정형화되어 있다. 프로그래밍 서적은 보통 원서 이북을 사는데 내 기준으로 마틴 파울러급(?) (1) 명사가 추천하는 책은 일단 사고, (2) 매닝 MEAP 프로그램 홍보 전단을 받아보다가 맘에 드는 목록이 있으면 이북으로만 냉큼 산다. 반면 교양서는 대부분 유정식님 블로그에 실리는 책 소개를 보고 산다. 목록을 쓱 훑다가 너무 어렵지 않고 느낌이 괜찮다 싶으면 바로 지른다. 몇 번이나 그랬는지 모르지만 대부분 성공했다. 예전에 책 읽을 계획 올리다가 그리운(?) 노OOO에게 질타 당한 일도 있지만, 유정식님 사례를 생각해보면 독서 전후기는 매우 유익하다. ^^


딸랑 서론만 읽고 삘(?) 받아서 글을 쓴다. 대한민국 개조론 이후에 가장 인상깊은 서론을 만났다. 책을 살 때는 몰랐는데^[각주:1] 이유없이 오래전부터 좋아하던 대칭을 본격적으로 다루고 있다. ^[각주:2] 서론을 읽다가 형광펜을 찾게되는데는 얼마 걸리지 않았다. 서론 시작 바로 다음쪽에 다음과 같은 내용이 나온다.


이 부분을 읽을 때 사고의 화학반응이 일어났다. 내가 통합적 사고라고 표현하는 바로 그 작용, 켄트벡이 여러 곳에서 언급한 은유(Metaphor), 미루어 짐작하기 등등 연관해서 기억하는 개념들이 동시다발로 튀어나왔다. ^[각주:3] 다음 쪽에도 시선을 끄는 글이 바로 나왔다.


수학과 물리를 거론하던 책이 반전을 암시하고 있다. 이 부분에서는 먼저 일민 형이 올린 집필과정 후기가 떠올랐다. 후기로 쓰고 있지만 이 책의 서론과 비슷하게 흥미진진하다. 실랄할 후기에 내가 곧 등장할 시점이라 긴장이 되긴 하지만, 매우 흥미로운 기록으로 남을 듯하다. 다시 책으로 돌아오면 개념이란 단어에서 개체매니페스토를 떠올렸다. 순전히 착시현상일 수 있지만 entity, indivisual을 나타내는 낱 개(個)자 대신에 손님 객(客)으로 정의한 휴우증은 소스코드에 고스란히 남은 듯하다. 굳이 사전을 찾아서 분석해보면 논리가 빈약하지만, 여하튼 개체를 정의할 때 하나의 고유성을 지닌 개별 존재로서, 응집력을 갖춘 특성을 모으려는 노력은 없이 과거 절차와 데이터를 구분하던 프로그래밍 방식의 유산까지 이어받아 "수동적인" 구조+행위체로 정의하는 데에는 왠지 객체라는 작명의 과실도 기여를 하지 않았나 싶다. 그렇다고 객체가 온전히 잘못된 작명이란 생각은 아니다. 오히려 개체로 새로 인식함으로써 개체스러움(?)으로 돌아가자는 문화운동^[각주:4]이랄까?

딸랑 2쪽 지나서 또 다른 화학반응이 이어졌다.


이럴수가 싶었다. 바로 어제 업무 회의때 고객의 질문이 떠올랐다. 일반화한 클래스를 사용하여 유관한 로직을 하나로 압축하는 방법을 쓰는 경우 설계 산출물은 어찌 하느냐는 물음이었다. 문서 산출물을 중시하는 국내 SI 경험이 있는 사람만 이해할 수 있는 상황이고, 많은 사람이 어려움에 겪는 경우다. 이런 상황에서 문제 해결을 위해 사용하는 방법은 개별적으로 정의해야 하는 경우와 일반화 하여 "군group"으로 묶을 수 있는 경우를 나누어 처리하는 방법이다. 이런 행위에 대해 '대칭 계산법'이란 생소한 표현이 딱 들어맞는 느낌이었다. ^[각주:5]

또 2쪼 후에... 작렬


통찰, 직관, ... 등등의 단어가 떠오름과 함께. 밥 삼촌 카타가 보여주는 테스트 케이스 선정의 예술성, 요구사항은 경험에 기반한 직관으로 (고객이 아닌 넓은 의미의) 개발자가 창조(?)해야 한다는 신념이 떠올랐다.

관련 글: “중요한 것은 시스템의 속도가 아니라 통찰력의 속도다.”


매우 함축적 글이라 전달하는 바는 적지만, 오랜만에 한 시간 가까이 투자한 글이다. 이렇게 긴 글을 쓴 동기는 일민형이 어제 아침 올린 글의 나비 효과?