티스토리 툴바

레거시(Legacy)라는 말을 쓰는 상황과 유산이라는 말을 쓰는 상황이 다르다 보니 통찰력 있게 이들을 돌아볼 수 있는 기회가 내게는 최근에야 주어졌다.

내가 얻는 것들. 가령, 도움을 주는 사람들, 지식, 직책, 사회적 위치, 경제적 위치, 그리고 지독하게 고착된 습관과 같은 것들의 다른 이름은 레거시이다.

컨설턴트라는 이름으로 새로운 기술이나 기법을 보급하려고 하면, 기존의 기술과 관행을 지닌 분들의 거부감을 만나게 된다. 더러는 논리적인 이유를 제시하기도 하지만, 대개는 언성을 높이거나 경직된 자세로 왜 바꿔야 하느냐고 묻는다.

J2EE 컨설팅에 소개된 다음 내용을 보면
 2.2 Java로 Batch Job 구현시 성능은 Pro*C에 대비해서 어느 정도인가?
 2.3 UI, 컴포넌트, 클래스, DB Table까지 포함된 비지니스 로직을 정의하는 산출물이 가능한가?
 2.4 Spring을 사용하지 않고 EJB + POJO 개발 방식을 사용할 수 있는가?


왠지 자신이 아는 것을 지키고 싶은 마음과 모르는 것에 대한 막연한 두려움이 느껴진다. 저러한 논의를 끌어낸 분들에 대해선 알 수 없지만, 적어도 내 마음 속에서 그런 마음이 존재하고, 저 글을 보면 그런 마음이 묻어 있다고 느껴진다.

사회의 기본 전제는 함께 산다는 것이다. 함께 산다는 것은, 내가 옳다고 믿는 것을 상대가 믿도록 강요하는 것은 아닌 듯 하다.

함께 사는 것의 의미를 진지하게 생각해본 적이 없다는 것은 놀라운 일이다.

어떻게 하면 변화를 거부하지 않을 수 있는가? 그리고, 어떻게 하면 변화하는 가운데서 다른 사람들과 공존할 것인가? 짧은 경험이지만 한가지는 분명한 것 같다. 나와 다른 주장을 하는 상대를 만나면 옳고 그름을 따지기 이전에, 상대를 그대로 인정해야 한다.

쉬운 일이 아니고 긴 훈련이 요구된다. 직감적으로 내가 찾아낸 훈련법은 무언가를 새로 만들고자 할 때 이미 존재하는 것들을 돌아보라는 것이다. 그래서 기존의 유산과 함께 진화하는 방안을 몸으로 익히는 것이다.

첫번째 시도로 블로그에 산재해서 정리했던 개발 관련 글을 위키로 옮기려 하는데, 완전히 새로운 위키 대신에 네이버 프레임워크 카페 위키와 융화하여 시작하기로 했다. 새로 시작하는 것에 비해 여러 고려 사항이 부가된다. 번거롭다 여겨지지만, 어쩌면 번거로움을 풀어가는 과정이 함께 사는 것의 진의에 대한 단초를 제공해줄지 모른다는 기대감을 갖게 된다.

설정

트랙백

댓글

토비님이 의미심장한 글을 올렸다. 사전에 들은 것이 있어서인지, 라는 제목이 토비님 스스로에게 던지는 도전적인 질문으로 느껴진다. 또한, 답변을 위한 질문이라기 보다 스스로 단련해가는 과정으로 보인다.

'선택과 집중'이라는 말이 오래동안 회자되었는데 이를 실천하기 위해서 피부에 와닿는 단어로 바꾸면 '용기 희생'이 된다. 선택하기 위해서는 스스로에 대한 믿음과 뒤를 돌아보지 않는 용기가 요구된다. 또, 선택한 길을 가려면 그 길을 가면서 마주하게 되는 수많은 다른 길을 포기해야 한다.

최근에 개발자로써의 진로를 고민하면서 두 가지 축을 보게 되었다. 직업직장. 직장 생황을 해보면, 하고 싶은 일을 고집하면서 안정적인 직장을 고집할 수는 없음을 알게 된다. 둘 사이에서 선택이 강제된다면 무엇을 택할 것인가?

직장을 택하면 직장이 제공하는 이미 준비된 많은 것들 즉, 사회 생활을 위한 인프라에 해당하는 것들을 제공받는다. 대신 자신이 하고 싶은 일, 좀 더 생기있는 말로 대신하면 꿈을 포기해야 한다. 커오면서 이미 많이 퇴색된 꿈인데 거기서도 더 포기해야 한다.

반대로 자신의 일을 택하려면 직장이 제공하는 일종의 인프라를 스스로 구축해야 한다.

모처에서 고객사 직원 한분이 동료한테 소개팅을 시켜주려고 여자 후배에게 말을 걸었다 퇴짜를 당한 이야기를 해준다. 그 이유가 '오빠랑 같은 회사면, 시간이 없어서 안된다'는 것이었다. 당연한 이야기라고 답변했더니, '그럼 결혼하려면 회사를 옮겨야 하냐'라고 묻는다.

차마 설익은 답변을 발설하지 못했다. 스스로 그렇게 해보지도 않고서 수많은 말들을 내뱉었던 지날 날이 있었지만...

설정

트랙백

댓글

프로젝트를 하다 보면 현행화라는 것이 중요시된다.

현행화란 실제 상황과 관리 장표나 관리 데이터가 일치하게 만드는 것을 의미한다.
관리조직/팀에서는 최고의 관심사 중의 하나다.
현행화를 위해서 추적성을 확인해야 하고, 형상관리도 요구된다.

가령, UML 모델이나 엑셀 파일 형태의 관리 데이터와
실제 소스 코드의 동기화가 요구되는 경우를 가정해보자.

소스 코드에 변경이 일어났을 때 모델에 어떻게 반영할 것인가?

현장 경험이 적다면 RTE(Round-trip Engineering) 같은 것을 떠올려 볼 수 있다.
작은 시스템이라면 도전해볼 수 있겠지만
대규모 시스템이라면 툴 지옥[각주:1]을 경험할 수 있다.

경험 많은 사람이라면 엑셀 시트나 코드 체계[각주:2] 같은 것을 떠올린다.

또 한번 그야말로 가상상황을 만들어보자.

만일, 어떤 시스템이 개발 과정에서 모델을 만들어 놓고서
일목요연한 관리표가 별도로 필요하다고 엑셀 시트를 별도로 만들었다고 하자.
엑셀 시트가 유지보수 주체에게 전달되었다.

운영환경에서 코드를 하나 고치려면 영향을 받는 다른 코드를 찾아내야 한다.
인간의 존재 이유가 따분함을 극복하기 위해서만은 아니기 때문에.. ^^
그때마다 일일이 엑셀 시트를 보면서 수정할 소스 파일을 찾아나갈 수는 없다.

IDE가 제공하는 의존성 추적(dependency trace) 기능을 쓰는 것이 생산적이다.
SM 업무를 하는 이대리[각주:3]는 IDE의 해당 기능을 사용하여 쌈빡하게 수정을 해내고 좋아라 퇴근을 했다.
금요일이라 한잔 걸치고 신나게 놀았다.

어느날 회의에 참석한 이대리.

고과장[각주:4]: 자네 산출물 관리 장표는 현행화 되었는가?
이대리: (오기 전에 확인은 안했지만, 평소 늘상 확인했기에) 네. 아마도...
고과장: 아마도가 뭐야? 기면 기고, 아니면 아니지.
이대리: 늘 확인했으니까 맞을 껍니다.

얼마 지나지 않아 팀내 다수의 개발자들이 원인 모를 문제로 고생하기 시작했다.
원인은 드러나지 않았지만, 팀원들의 불평과 고생이 늘어가던 어느날
이대리는 갑자기 불안감이 느껴졌다.

'헛..'. 장표 갱신을 누락시켰던 기억이 난다.
문제가 너무 커진데다가 다들 원인 모를 문제로 인식하고 있어서
선뜩 말을 꺼낼 수가 없었다.

가상상황이지만 충분히 발생할 법한 이야기고,
엑셀은 그렇다 쳐도 별도의 UML 모델과의 연계까지 관리하라면...
변경 자체를 어렵게 하는 일이다.

필연적으로 업무 변화를 빠르게 하자는 경영이론들이 쏟아져 나오는데
이를 가능하게 하는 정보시스템에서는 변경을 어렵게 한다면 심각한 문제다.

...

- 점심을 먹으러 식당을 찾아 가는데 건물밖에 간판만 있고 실제 식당이 없는 경우가 있었다.

- 더불어 학생 시절에 SCM(Supply Chain Management) 관련한 수업을 들을 때
강사가 '상물의 분리'라는 모호한 용어를 쓰면서 실제 정보와 정보 시스템의 데이터의 불일치에서 나오는 현상을 열올려 설명하던 기억이 떠올랐다.

- 겨울인데 어떤 식당에서 '봄맞이 냉이국 추가'라는 문구를 본 기억까지 쏟아져나온다.

정보 시스템 만의 문제는 아니다. 현행화.. 답은.. 꾸준히 열심히 하는 것.
변화에 기민하게 대응하는 것. 매직은 없다.

  1. '띄우는데만도 세월' 혹은 '무서워서 명령을 못내리는 경지' [본문으로]
  2. 모델 중심의 사고로 보면 모델이 엑셀 시트와 코드 체계 형태로 존재하게 되는 것이다 [본문으로]
  3. 소개도 없이 등장하는 이대리, 첫 등장 [본문으로]
  4. 우정 출연 [본문으로]

설정

트랙백

댓글

이너게임(또): 지상 최고의 세미나에서 언급한 것 처럼
이너게임기동성이라는 개념이 소개됩니다.

정확히 어떻게 정의했는지는 이제 기억에서 흐릿해졌지만
스스로는 "능동적으로 자신의 변화의 방향을 결정할 수 있는 능력"으로 정의합니다.
그리고, 스스로를 기동성 훈련단으로 임명합니다.
별도의 단원이 있는 것은 아니지만, 왠지 그럴싸한 기분이 들면 쉽게 지치지 않으니까.

일요일이 지나고 월요일을 맞이하는 밤이면
다가오는 한주에 대한 고민이 밀려오기도 합니다.
나는 그것을 떨쳐내기로 마음 먹어봅니다.
무슨 방법이 있을지 딱히 떠오르지는 않지만...

지난주에 기동성 강화를 위해 실시했던 훈련 하나를 소개하겠습니다.

Caps Lock 없는 생활에 익숙해지기에 쓴 것처럼
Ctrl에게 Caps Lock의 위치를 돌려주는 것은 논리적으로 바람직해보입니다.
그러나, 실천을 해보니 꽤나 짜증스러운 일이었습니다.
IBM ThinkPad를 쓰다가 후지쯔 Lifebook으로 옮겼을 때 키배열에 당황한 것처럼...

이틀 정도는 쉴새없이 실수를 연발했습니다.
복사(Ctrl+C/Ctrl+V)나 저장(Ctrl+S)은 안되고
대문자 C나 V가 화면에 쓰여지는 일을 수도 없이 반복했습니다.

잠시 '이게 과연 옳은 일이냐'
고민을 하게 됩니다.

그리고, 익숙한 것과의 결별에 한표를 던집니다.
마음을 먹자 생각보다 쉽게 적응이 되었습니다.
아직도 완전히 적응한 것은 아니지만, 3일 정도 지난 후부터는 실수가 현격히 줄었습니다.
10년 넘게 사용하던 Ctrl의 위치를 3일만에 바꾼 것이면... 나쁘지 않은 시도였던 것 같습니다.

설정

트랙백

댓글

사용자 삽입 이미지

가치관이 어떻게 성장하는지를 단순하게 그려보았다.
사회적 가치[각주:1]를 무비판적으로 수용하는 것을 레벨0라고 보면
레벨0의 사람이 사회의 다수를 이룬다.
어찌 보면 대중이라는 말은 각자의 가치관을 무시한 레벨0 상태와 묘하게 어울린다.

레벨0인 상태를 감지하는 법은
- 신문에 나오는 이야기를 마치 자기 생각인양 말하는 사람
- 뉴스에 나오는 사실을 자신의 소소한 일에 비해 중요하게 여기는 사람
- 무슨 일을 행하기 전에 지나치다 싶을 정도로 사전 조사를 하는 사람
- 부모님 말씀/목사님 말씀이 의무감으로 다가오는 사람
- 소속 단체/모임에 소홀한 사람을 왠지 용납하기 힘든 사람
- 종교나 학벌로 사람을 구분하는 것이 습관이 된 사람
- 경력 연수를 따지거나 초급/중급/상급이라는 말로 사람을 분류하는데 익숙한 사람

위와 같은 유형이 다 레벨0는 아니지만, 가능성이 농후하다.

레벨1에 이르면 세상을 보는 새로운 눈을 얻은 느낌을 받는다.
레벨1에서 보면 사회적인 이슈에 대해서
가치 평가를 하기 전까지는 무가치한 상태 즉, 객관적인 것으로만 인식한다.

레벨0에 있는 사람도 자신이 좋아하는 특정 항목에 대해서만 레벨1에 이르기도 한다.
이런 부류의 사람들은 고집이 무척 쌘 경향을 볼 수 있다.

모든 면에서 레벨1에 도달하면 아마도 레벨2를 지향하게 되는 것 같다.
레벨2는 내가 무언가에 대해 스스로의 가치 평가를 내리는 것처럼
다른 사람도 그러함을 인정하는 단계를 의미한다.
나는 아직 레벨1에 완전히 도달했는지 어쨌는지 모르겠다.
다만, 레벨2에 도달하려고 노력하고 있을 뿐이다.

이야기가 너무 추상적으로 흘러 재미 없게 보실 분들을 위해 에피소드를 하나 소개하겠다.

특정 분야에서 명저라고 하는 책들이 있다.
레벨0에서 보면, 그 책을 무조건 사서 봐야 한다.
레벨1의 관점에서 보면, 책을 사서 볼 수 있지만
본인이 평가하기 전까지 '명저'라는 허명은 큰 의미가 없다.

아무리 좋은 책도 어떤 이에게는 다음과 같은 반응을 줄 수 있다.
사용자 삽입 이미지
이것을 그대로 인정할 수 있는 상태라면 레벨2에 도달했다고 볼 수 있다. 나는 아직 모든 면에서 레벨2에 도달한 사람을 만나본 적이 없는 것 같다. 어쩌면 그것은 성인의 경지인지도 모르겠다.

내 경우에는 내가 중요한 것은 다른 사람도 중요하게 생각해야 한다는 감정이 자리잡고 있음을 느낀다. 그런 요소들이 주변 사람들과 다투게 되는 원인을 제공하기도 한다.

그러한 미성숙한 가치관을 지닌 사람들이 다수 모여서 단체를 형성하게 되면 다툼이 아니라 전쟁을 하게 되는 것을 역사가 보여주었다. 
  1. 내가 소속한 모든 집단 가령, 가족, 회사, 종교 단체, 기타 침목 모임이 공유하는 가치 혹은 매체를 통해 공유되는 여론 [본문으로]

설정

트랙백

댓글

LOC, 코드 행수를 헤아리는 일에 대하여라는 글을 쓴 적이 있다. 요즘에는 프로젝트 규모 산정을 위해 본(module)수 즉, LOC 대신 기능점수(FP)를 쓰는 곳이 많다. 조직적인 이유로 혼용해서 쓰는 곳도 종종 발견하게 된다.

모처에서 환상적으로 기능 점수를 환산한 엑셀시트를 볼 수 있었다. 내용은 잠시 접어두고 엑셀시트 자체만 보면 너무나도 환상적이다.
사용자 삽입 이미지

대충 이런 식의 와꾸가 나온다.

학교에서 프로젝트 관리를 배울 때 가장 중요하게 다뤄지고, 가장 어려웠던 것이 Estimation이었다. 변수가 많은 일에 대해서 답을 내려는 것은 지나친 일반화에 기대를 거는 것이 될 수 있다. 이론의 무용함 그리고 유용함에서 언급한 바처럼

사용자 삽입 이미지

프로젝트 관리를 위해서 Estimation이 반드시 필요하다는 관점에서 보면 어쩔 수 없는 일이다. 그래서, 어찌 보면 Estimation의 필요성 자체에 대한 고민이 더 유용해보인다. 최근에  성향 자체를 Agile로 변화시키려는 노력을 하다보니, 이런 무모해보이는 생각이 더 매력적으로 느껴진다.

무모한 생각을 한다고 바로 해결책이 나오는 것은 아니다. 다만, 어떤 일을 할 때 '내가 왜 그 일을 하는지'를 한번쯤 생각하는 훈련을 하다 보면, 보다 수월하고 즐겁게 일을 해낼 수 있다. 나는 저런 류의 엑셀시트를 보면, 거기에 투여된 노력이 보인다. 그 노력은 단순히 산출물을 만드는 것에 그쳐서는 안된다. 엑셀은 프로젝트의 목적이 아니니까...

설정

트랙백

댓글

나는 Agile 이야기가 나오면.. 저런 단어들이 떠오른다.
이너게임(또): 지상 최고의 세미나에서도 기동성을 대빵 크게 키워 놓았다.
이너게임을 읽으면서 가장 관심을 끄는 단어/개념이었다.

그림만 떠오는 그곳에 What our readers want you to read!라는 글과 함께
주옥 같은 그림이 올라왔다.

Keepingup1

Agile은 과잉 계획/과잉 Estimation의 경험에 대한 시행착오를 통한 교훈(Lesson learned)이기도 하다.

나는 요즘엔 왼쪽이 아니라 오른쪽에서 출발하기를 즐긴다.
최대한 가지치기를 하고 출발하려고 노력한다.
그래도 하다 보면 욕심으로 부풀려지는 경향이 있다.

분명한 것은 왼쪽의 책 무더기처럼 무거운 계획 하에 출발하는 것보다는
가볍게 시작하는 것이 기민함/유연성/기동성/민첩성에는 분명 강점을 지닌다는 점이다.


설정

트랙백

댓글

클래스 도출이 올바른지 확인할 수 있는 프로세스?도 같은 맥락이었지만
가끔 사람들은 일의 주인이 사람이라는 사실을 잊는 것 같다.
너무 지쳐서 그런 것일 수도 있겠지만
반드시 해야 할 것은 어떤 기법이 등장해도 사람의 몫이다.

고과장님의 말: 아까 밥먹다가.. 갑자기 DI에 대해서 생각하게 됐는데
고과장님의 말: 보통 UML에서 디펜던시면.. 로칼에서 다른 클래스 쓸때 디펜던시라고 하자너..
고과장님의 말: DI에서 세터방식같은 경우엔 프로퍼티로 잡으니깐.. UML 에서 보면 어쏘시에이션인데 말야
고과장님의 말: 엄밀하게 하자면 어쏘시에이션 인젝션이 아닌가 싶더라고.. ㅋㅋ

[永會]님의 말: Spring에서 말하는 dependency는 association을 포괄하는 개념이죠
[永會]님의 말: UML의 dependency보단.. 광범위한 해석일 껍니다.
고과장님의 말: 디펜던시는 그런가? 다시 한번 봐야겠네
[永會]님의 말: 네..그냥.. 평의한 의존의 개념이죠.  소프트웨어 아티팩트가..연관을 갖던 import를 하든
[永會]님의 말: include를 하던 그 대상이 없으면.. 컴파일이 안되잖아요. 바로 그 의존

고과장님의 말: 그쪽동네에서 이야기하는 디펜던시는 포괄적인 개념으로 봐서 그렇게 이름을 지은거 같어
고과장님의 말: 결국 다 의존 아니냐
[永會]님의 말: 맞죠.. 결국 의존을 줄이기 위해서
[永會]님의 말: UML에서도.. depend라는 약한 결합 관계를 정의한 것이니까

고과장님의 말: 디펜드라는게 있었나... ???  함 다시 봐야겠구만.. -_-;;
고과장님의 말: 스테레오 타입아니었나 싶은데..
[永會]님의 말: 아.. 물론 dependency가 정확한 이름이겠죠..^^
[永會]님의 말: 건.. 제가 줄여서 타이핑한건데
[永會]님의 말: 젠장.. 이럴땐.. 마이크가 필요한데
고과장님의 말: ㅋ
고과장님의 말: 요즘 음성 챗 메신져가 다들 지원되는데 말야 아무도 쓰는 사람이 없어서리
[永會]님의 말: 제껀 놋북이 내장 마이크가 없어서
고과장님의 말: 암튼 스프링 짜긴 잘 짠거 같어. 보면 볼 수록 말야
[永會]님의 말: 전..존경이라니까요. 한방에.. 무릎. 바로 존경
고과장님의 말: 하이버네이트는 솔직히.. 아직 좀 글코..
고과장님의 말: SQL을 객체로 만들어 버리다니 대단한 넘이여
[永會]님의 말: 대단한 넘이죠
[永會]님의 말: 것도.. 사장이 욱하게 만들어서 짠거라잖아요
고과장님의 말: ㅋ
[永會]님의 말: EJB 쓰기 싫다니까.
[永會]님의 말: 그럼.. 그거 안쓰고 니가 할 수 있냐?

고과장님의 말: 빌링 시스템 같은거 만들때 하이버네이트 같은거 잘 쓰면 와방이겠던데
고과장님의 말: 조건 졸라 복잡하고 옵션에 따라 계산 달라지는..
고과장님의 말: 잘못하면 SQL지옥에서 허우적 거릴 수 있는 그런데..
[永會]님의 말: 그럴수 있겠네요
고과장님의 말: 하이버네이트 모델 잘 만들어서..
고과장님의 말: 옵션을 객체로 만들고..
고과장님의 말: 체인 오브 리스펀스빌리티 패턴 써서..
고과장님의 말: 하면 대충 깔끔할거 같다는 생각이 들더라고

[永會]님의 말: 빌링쪽이었던가 모업체에서 룰 엔진 넣어서 O고생한다는 소식 전해들은 적 있는데
[永會]님의 말: 글게요.. 문제를 파악하고 나서
[永會]님의 말: 패턴을 쓰거나 솔루션을 써야 하는데
[永會]님의 말: 복잡한 룰 처리엔 룰엔진이라니까
[永會]님의 말: 사용법도 아무도 모르는 엔진 박아놓아서
[永會]님의 말: 다 걷어버리고.. if - else로 바꾸는 중이라는 영화같은 얘기가 들리더군요.

[永會]님의 말: 암튼.. 룰 엔진이 나쁜건 아닌데..
[永會]님의 말: 툴 탓하게 생긴거죠..
고과장님의 말: 룰엔진이야 사람이 if than else 해논거 돌리는거 밖에 더 있냐
[永會]님의 말: 그쵸..
고과장님의 말: 좀 편하게 할 수 있게 해논거 밖엔
[永會]님의 말: if else 얼마나 심플하게 가느냐니까
[永會]님의 말: 문제만 잘 분석해놓으면 있음 좋은 것일 뿐이죠
[永會]님의 말: 사람들이.. 할껀 안하고.. 자꾸 매직을 찾으니까
고과장님의 말: 그러게 말야

[永會]님의 말: 기본을 안하려는 사람들
고과장님의 말: 결국 사람이 해야 하는데 말야
[永會]님의 말: 그걸 알게 될 날이 이미 다가온거 같아요.. 요즘은..
고과장님의 말: 스마트 폭탄 있자너.. 종가 정확한 폭탄.. 걍 쏘면 10센티 이내로 맞는다는..
고과장님의 말: 그거 알고보면 특공대가 가서 숨어서 레이져로 조준해야 하는 거거덩
고과장님의 말: 사람들이 그걸 몰라요
[永會]님의 말: 고스트네
고과장님의 말: 맞어 고스트야.. ㅋ
[永會]님의 말: 고스트도 들키면 바로 죽잖아요
고과장님의 말: 특공대 죽으면 끝이여
[永會]님의 말: 발사도 못해보고
[永會]님의 말: 절묘한 비유네요..
고과장님의 말: 스마트 폭탄 사면 되는 줄 알고 말야
고과장님의 말: 근데.. 어차피 새로운 사람들이 계속 나타나고
고과장님의 말: 새로운 벤더들이 계속 나타나기 때문에

설정

트랙백

댓글

10년차도 넘은 분이고 개발에 대한 감각도 뛰어난 분임에도
프로세스 담당을 하게 되면 없는 것을 찾으려고 하는가?

나는 다음과 같이 대답했다.
'잘'
'업무에 대해 잘 아는 개발자(분석가)라면 어느 정도 익숙해지면 도출이 된다.'
'지침이라고 해봐야 하나의 클래스에 너무 많은 오퍼레이션을 두면 안된다 정도다.'

돌아오는 반응은
'프로세스는 잘하는 사람을 위한 것이 아니라...'

여기서 고전적인 대결구도가 떠오른다.
제국과 동맹
기계 대 인간
매트릭스와 네오

퇴근 길에 곰곰히 고민해본다.
입장을 바꿔서 프로세스 개발 차원에서...
아이러니 하게도 현재 떠도는 옵션 중에서
가장 흥미로운 것은 XP/Agile 진영에서 사용하는 기법이다. TDD

Acceptance Test > Functional Test > Unit Test 까지...
가오나는[각주:1] 프로세스의 필수조건인 계층화추적성이 고도로 확보된다.
그리고, 계량화에 있어서도 현재는 최선이다.

이른바.. Test Driven Quality Assurance

하지만, 방법이 없어도 문제지만, 있어도 문제는 전혀 해결될 것으로 보이지 않는다.
결국 방법/방법론은 사소하고도 사소한 것이다.
반드시 하겠다는 의지 혹은 오래된 습관의 누적이 만들어낸 Inertia에 비하면...
  1. '형식화 된'을 의미하는 별로 권장되지 않는 표현 [본문으로]

설정

트랙백

댓글

아래의 글은 2006년 10월 18일 모처의 모과장님과 나눴던 대화입니다.
1. 올리면서 할말
최근에 CS로 개발되었던 화면을 웹으로 통폐합하는 프로젝트가 많더군요.
이때는 괜히 유스케이스 중심으로 했다가 어려움을 겪는 모습을 볼 수 있습니다.
화면은 무척 민감한 부분이기 때문에 변화무쌍하게 변화합니다.
고객의 화면 요구에 의해서도 바뀌지만 UI 전문가의 견햬에 의해서도 수시로 바뀌죠.
그렇게 되면 미리 작업이 들어간 유스케이스 기술 역시 대폭 수정되거나 통폐합되어야 합니다.
대개 CBD라는 이름으로 수행되는 RUP류의 방법론과 객체지향 분석설계 기법을 사용하는 프로젝트의 가이드 방법도 이와 경우에는 유연하게 대처하지 않으면 소모적인 작업으로 몰아갈 수 있기에...

[永會] 말: pragmatism 행동주의

고과장님의 말: 요즘 같은 시대야 실용적인거로 흐르는 분위기라
고과장님의 말: 심지어 삐리리같은 공사도 그런 분위기더라고
고과장님의 말: 내가 가서 그랬거든 시스템 기능보강하는 프로젝인데
고과장님의 말: 화면을 재구성하고 통폐합.. 효율적으로 뒤바꾸는게 프로젝트 상당 부분인데
고과장님의 말: 그런 프로젝트에서 유스케이스 드리븐이 정말 맞는가?
고과장님의 말: 모든 프로젝트는 유스케이스를 반드시 써야 하는가
고과장님의 말: 정말 효과적인가?

[永會] 말: 유스케이스 기술에 시간을 낭비하는게 문제겠죠
[永會] 말: 전 유스케이스를 드라이버로 쓰는 것은 아주 효과적이라고 봅니다.
[永會] 말: 유스케이스는 이름만 있으면 되죠.
[永會] 말: 산출물의 존재 이유를 말해주는 용도니까

고과장님의 말: 유스케이스를 하다보면.. 요즘엔..  엑터가 더 중요한게 아닌가 생각이 많이 들더라고
고과장님의 말: 어떤 사람들이 이 시스템을 쓰는가

[永會] 말: 액터의 골이 유스케이스죠
[永會] 말: 이해도가 높지 않은 사람들이
[永會] 말: 유스케이스다 뭐다 하면.. 자꾸 어떤 형식에 매달려서 그런 것 같아요
[永會] 말: 프로젝트 성공과 유스케이스 드리븐이 뭐 그린 중요한건 아니잖아요..
[永會] 말: 실패랑도 마찬가지고..
[永會] 말: 결국은 어떻게 잘 하느냐는 건데

고과장님의 말: 예전엔 UP 안에서 어떻게 잘 하나.. 이런 생각을 주로 했는데..
[永會] 말: 도구를 도구로 써야 하는데.. 자꾸만 갇혀서 하려고 하는 습성이
[永會] 말: 저한테도 있는 것 같고..

고과장님의 말: 널린게 기법이고 방법인데...
[永會] 말: 그걸 넘어서는게 결국 프로패셔널로 가는 길이 아닐까요.
[永會] 말: 결국 컨설팅 받아라.. 일케 말해주시죠.. 프로패셔널이 필요하다

고과장님의 말: 결국 컨설팅 받아야지. ㅋㅋ
고과장님의 말: 돈 좀 제발 써라. 고쳐줄테니

[永會] 말: 글케요.. 전 제발 좀 사람한테
[永會] 말: 돈 좀 썼으면 좋겠어요
[永會] 말: 개발자도 좀 양질로 뽑고
[永會] 말: 플랫폼에 그만 꼴아박고

고과장님의 말: 모든 개발도구를 오픈소스로 사용하고
[永會] 말: 야근 좀 줄이게.. 여유있게 개발자 좀 운영하고
고과장님의 말: 그 돈을 개발자에게
[永會] 말: 그게 핵심인데.. 뭔놈의. EJB를 쓰니 마니
[永會] 말: EAI는 뭘쓰니
고과장님의 말: 개발프로젝에서 제일 삽질이.. 삐리리 툴 묶어서 같이 구매하는거...

[永會] 말: 요즘은글케 안하잖아요
고과장님의 말:그니깐
[永會] 말: 삐리리 묶어서는 좀 사던데
[永會] 말: 코메디죠
고과장님의 말:ㅎㅎ

[永會] 말: 전 삐리리로 모델링 한다는데가 젤 어이가 없어요
고과장님의 말: 어쩔수 없이.. 삐리리로 짜는 플젝같은경우는 삐리리 사야지
고과장님의 말: 그런거 아니면
[永會] 말: 그런 경우야.. 예외죠
고과장님의 말: 자바는 도구비용 0원
고과장님의 말: 대신 양질의 개발자

[永會] 말: 네.. 그게 답이고.. 언젠가 그리 가겠죠
[永會] 말: 아마.. 개방이 점차 확대대고 경쟁 심해지면
[永會] 말: 더 이상 어차구니 없는 구매 행태로는
[永會] 말: 버티기 힘들지 않을까요?

고과장님의 말: FTA 하고 나면
[永會] 말: 하루 아침에 바뀔 지도 모르잖아요
[永會] 말: IMF 당하듯이
고과장님의 말: 어떻게 될지 모르지
고과장님의 말: 아마 엄청난 파장이 있을거 같은데
[永會] 말: 결국 살아남기 위해서 일단 전 agile 해져야 할 듯..

[永會] 말: 나부터 살고보자 주의
고과장님의 말: 현찰 쌓아놔야지
고과장님의 말: 금도 좀 사놓고
[永會] 말: 보잉 같은데가 agile 방법 택한거 보면
[永會] 말: 대규모 개발자를 단일 팀으로 끌어가는 것 자체가
[永會] 말: 실패 이유가 되는 것 같아요
[永會] 말: 당장은 어쩔 수 없지만
[永會] 말: 결국은 다수의 시스템으로 나눠서 개발해야 할 것 같아요
[永會] 말: loosely coupled 하게

고과장님의 말: 그렇게 되야 컴포넌트화 시킬 수 있고
고과장님의 말: 전체적으로 관통하는 최소한의표준은 있어야 하지만
[永會] 말: 네.. 컴포넌트 개념 부터가.. 시스템 단위로 봐야 할꺼 같아요
[永會] 말: 갯수가 많지 않게
[永會] 말: 이미 ESB 같은게 나오면서
[永會] 말: 기반 기술은 그렇게 가고 있는 것 같아요

고과장님의 말: 2~5만 라인짜리 컴포넌트가 여기는 400여개니깐
고과장님의 말: 왤케 많은지 모르겠어
고과장님의 말: 몇천라인에서 부터 큰건 5만 라인정도

[永會] 말: 일부는 설계 중복도 있겠죠.
고과장님의 말: 코드 중복도 그렇고
[永會] 말: 아무래도 의사소통이 잘 안되는 우리의 개발자 문화를 보면
[永會] 말: 코드 중복을 피할 길이 없는 것 같아요

고과장님의 말: 요새 개발방법론을 하나 구상하고 있는게 있는데.. ㅋㅋ
고과장님의 말: XU라고 eXtreme User Interface
고과장님의 말: 디립다 화면만. 코딩은 프로젝트 기간 2/3 지난 시점부터

[永會] 말: 그런 방법도 괜찮은것 같아요
[永會] 말: 제 생각엔.. 분석/설계와 코딩이 오버랩 되게
[永會] 말: 할 수 있다면 최적인거 같아요
[永會] 말: 반복을 실현하기가 어렵긴 하지만

고과장님의 말: 소수 정예로 길게 프로세스 요구사항 화면.. 정리하고
고과장님의 말: 고객이 지겨워서 더 이상 못 바꾸겠다 뻣으면
고과장님의 말: 뻗어버리면. 그때 설계/구현 시작.. ㅋㅋ

[永會] 말: 저도 유스케이스에 화면을 바로 대응시키는게
[永會] 말: 지리멸렬한 문서화보다
[永會] 말: 더 효과적인 Use case driven이라고 생각해요
[永會] 말: 유스케이스 규모를 화면 갯수로도 산정할 수 있으니까

고과장님의 말: 영화세트마냥
고과장님의 말: 빠르고 신속하게 화면 만드는 기술 아나 찾고
고과장님의 말: 유스케이스가 나쁜게 아니라
[永會] 말: 사람들이 오용하는 것이죠
고과장님의 말: 유스케이스는 아주 좋은데... 유스케이스라는 단어만 나오면 시끄러워 지는게 문제야
[永會] 말: 말 좋아 하는 사람들을 배제하는 문화가 필요해요
고과장님의 말: 그렇다면 차라리 유스케이스를 꼭 써야 하는지.. 왜 사람들이 그 단어에 그리 각각의 개념이 그리 다양한지
고과장님의 말: 다시한번 생각해 봐야해

[永會] 말: 전.. 유스케이스 이전의 용어인 시나리오
[永會] 말: 그게 더 명확하고 좋은 이름인데
고과장님의 말: 글치 시나리오
[永會] 말: 야콥슨이 괜히 새 이름 내놓은거 아닌가 싶어요..

고과장님의 말: 알고보면 좋은데
고과장님의 말: 결국 사람들이 헷갈리고 논쟁을 불러 일으키니.. 그게 문제지 머
[永會] 말: 사용자 관점을 끝가지 견지한다는 것
[永會] 말: 그게 핵심인데
[永會] 말: 해보지 않은 사람들이 말이 앞서는게 문제 같아요
[永會] 말: 언쟁을 통해서 권위를 확보하려는 타입들도 많고..
[永會] 말: 지식기반이나 콘텐츠가 약할때 언쟁을 통해 주목을 끌고
[永會] 말: 언쟁에서 이기는 듯한 인상을 받아서 권위를 확보하는
[永會] 말: 언쟁 자체를 피하고 결과를 보여주는게
[永會] 말: pragmatist의 길인거 같아요..

설정

트랙백

댓글

메일 확인을 하다가 구글톡에 등록된 후배의 이름을 봅니다.
이 시간에 구글톡에 있다는 것은 야근을 의미하죠.
이 친구는 한동안 토요일은 물론이고 일요일마저 출근을 하고 있습니다.
내 일이 아니라고 한달째인지 두달째인지 감이 없네요.

그러면서도 스터디에는 왠만하면 꼬박꼬박 나오는 친구입니다.
일요일 오후에 하는대도 들렀다가 다시 사무실로 돌아가죠?
그 친구가 대한민국 최고의 소프트웨어를 만들기 위해 저렇게 열심히 하고 있는 것일까요?
일류를 외치는 회사와 일을 하고 있기는 합니다.

저는 어렴풋이 알 것 같습니다.
스스로 눈꼽만큼이라도 변해 나가지 않는다면 이러한 현실은 꿈쩍도 하지 않을 것이란 점을
푸념을 하려면 한번에 찐하게 한번 하고 말아야 합니다.
인생은 그리 길지 않다고들 하니까.

지금 야근을 하고 있고, 언제 야근을 끝낼 지 기약이 없는 저 친구는
이전 회사에선 밤샘을 자주 했으니까 견딜만 할 껍니다.

그래도 저 친구를 믿습니다. 조금은 변할 껍니다.
저와 스터디를 2년인가 유지해온걸 보면...
곧 자신의 변화를 살아내게 될 것입니다.

남자만 그런가? : 12시 8분 메신저의 여자 후배

설정

트랙백

댓글

나에겐 매우 험난한 길이다.
'기초가 중요하다'는 이야기는 수도 없이 듣고, 또 들은 바를 나불댄다.
하지만, 나에게 정말 기초가 중요할까? 아니 내가 실제로 그렇게 느끼고 행동하는가?
내 지각과 무관하게 기초가 없음으로 해서 살면서 많은 어려움을 마주하게 된다.

낯선 사람을 대할 때 할 말이 없어서 고통스러워 하는 것
호흡이 되지 않아서 수면 위로 뛰어 오르다가 물을 먹을 때
네트워크를 타고 패킷이 어떻게 흘러가는지를 몰라 API를 얼토당토 않게 사용할 때
삶의 모든 면에서 기초 없음의 흔적이 드러난다.

'기초가 중요하다'

결국은 나에게 하는 말이다.
그렇게 겪고도 미련과 욕심을 버리지 못하는 나에게...

내가 기초의 부족을 얼마나 절실하게 생각하고 있는지 어설프게 나마 측정하는 방법을 찾아냈다.
기초로 돌아가자는 마음으로 시작했던 스터디에서
전체 15장 중에서 8장을 넘어서고 9장에 다달으니까...
끈기있게 텍스트를 음미하지 못한다.

자각을 위해 이론화 하면 내가 기초를 중시하는 정도는 53%이다.
꾸준함과 리듬의 중요성에 언급한 바 있는 리듬을 잃지만 않으면...
장기적으로는 이보다 높은 수치를 가질 수 있다.

설정

트랙백

댓글

Rhythm method를 여느 때와 같이

Cardiacwavesmall
그림과

Life runs on a pulse: without that basic rhythm, you’re dead

한 줄의 문구만 보고 나름대로 상상의 나래를 펼친다.

심장 박동의 기본 리듬을 잃으면 사람은 죽는다.

간혹 사람 죽이는데도(?) 쓰이는 CMM을 떠올린다.
성숙도는 결국 리듬이다.
조직이 얼마나 리듬을 몸에 익히고 있느냐.

Continuous Integration도 마찬가지다.
통합의 문제를 뒤로 미루지 않고, 조기부터 몸으로 리듬을 익히려는 시도다.

이젠 수영으로 생각이 미쳤다.
접영을 처음 배울 때 강사는 '리듬이 안되면 접영은 안된다'는 말을 했다.
정말 리듬을 못 타면 접영은 세상에서 가장 힘들게 허우적거리기가 된다.

주식 시장에서도 리듬을 통해 매수와 매도의 시기를 결정하는 방안들이 많이 있다.
수많은 그래프들이 이를 증명한다.

생활의 리듬. 바이오 리듬....
리듬은 풍랑을 인정하는 것이다.
사람은 지속적으로 고양된 상태를 유지할 수 없다.
즉, 언젠가는 떨어져야 하는데
그걸 인정하고 꾸준함을 지키려는 것.

리듬을 잃고도, 할 수 있는 것은 아주 사소한 일 뿐이다.

설정

트랙백

댓글

벌써.. 6년도 더 지났구나.
나에게 자바를 배우겠다고 나선 용기 있는 여자 후배
터울이 다섯이니까 쉽게 말을 걸기도 어려웠을텐데

얼마전에 오랜만에 얼굴이나 보자고 메신저로 연락을 했다
얼마전이 도대체 얼마나 지났는지 감이 없지만...
가만 생각해보니 스페인 가기 전이니까 6월이었나 보다.
저녁에 퇴근을 마음대로 못해서 약속을 정하기가 힘들단다.

컴퓨터를 끄고 자려는데 메신저에 보여서 하이 날린다.
'남친이랑 채팅하는가'하고 막연히 생각한다.
아직 분당이란다. 사무실. 12시 8분.

독립운동하는 것도 아니고...
이게 무슨 짓인가?

너무 지친다.

귓가에 맴도는 메모... (메모의 정체는 곧 공개하겠습니다.)
아무래도 '너무 지쳐온' 그리고 '너무 지치고 있는'
동지들을 위해서 뭔가 행동해야 할 것 같다는 생각이 듭니다.
하지만, 일단.. 스스로를 좀 추스리고.. ㅡㅡ;

설정

트랙백

댓글

방명록에서 메일 주소를 물으시더니 프로젝트에 관한 조언을 구하시는 분이 있었습니다.
어찌 보면 조언을 드리는게 직업인 저로써는 대가를 받아야 합니다. 그 대가는 정보 공유로 받겠습니다. ^^
질문 일부를 첨부하고 문답식으로 답변하겠습니다.

수행중인 사업은 기관의 업무를 일부 웹으로 전산화하고,
해당 기능을 가입회원도 홈페이지에서 액세스 가능하도록 하는겁니다.

요즘 가장 많이 하는 프로젝트 유형인 것 같습니다.
SSOCS to Web(CS의 업무를 웹으로 이양하거나 웹 화면으로 CS에 접근하게 하는 것)

고객의 요구사항은 대충 전달받았습니다. 요구사항 이런거 없습니다.
사업 계획부터, 제안요청서 작성... 전부 우리가 정의하고, 만들고, 테스트 합니다.
아마 고객은 다~~ 만들고 난후에 시스템 죽~ 둘러보면서
"이건 안돼요? 이건 안돼요? 이것도 되야 되는데.." 할겁니다
프로젝트가 끝나고 다른 사람이 유지보수를 위해 해당 문서를 찾아볼때
Usecase Diagram 을 보면서 무엇을 원할지 기대가 안됩니다. 고객과 커뮤니케이션도 없는 상황이고 말이죠.

보통 방법론이라고 싸잡아 불러 버리는 '어떻게 일을 해야 할 것인가'에 대한 고민인 듯 합니다.
가끔 RUP나 CBD 방법론 같은 것만 있으면 문제가 해결되는 것으로 착각하는 분들이 있죠.

모델을 사용해서 체계적으로 프로젝트를 진행하려면 사실 많은 비용이 듭니다.
이런 방식에 적응하기 위해서는 프로젝트 수행 팀원들이
기존과는 다른 방식으로 일하고 유연하게 사고하고 의사소통 하는 법을 배워야 합니다.
결국, 방법론이나 UML 사용 여부에 우선해서 팀원에게 투자를 하신다는 생각이 필요하죠.

각설하고, 현재 상황을 보면 가벼운 틀 안에서 실제적인 문제에 초점을 맞출 수 있는 방법이 필요한 것 같습니다.
Use Case는 진화하는 산출물을 포용하기 위한 수단이지 기능 명세로 보긴 어렵습니다.
기능 명세로 쓰실 바에는 그냥 엑셀로 기능 목록 관리하시는 것이 좋다고 봅니다.

그리고, 저라면 전체적인 모델을 생략하고 몇 장의 주요 상황만을 표현한 다이어그램만 활용하겠습니다.
고객도 이해하려고 노력할만한 첨예한 사항만을 추려서 모델링하는 것이죠.

이기종 연계 혹은 연동이 필요한 프로젝트이기 때문에
업무 복잡도 보다는 기술적 위험도가 높다고 봅니다.
결국 모델링에 시간을 투자하기 보단 조기에 파일럿이나 POC(Prove of Concept)를 수행하시고
그 결과를 공유하는 차원에서 도식화 한 다이어그램을 사용하시는게 좋다고 봅니다.

웹응용에서 벌어지는 화면전화과 그 흐름을 정의하려면 즉, 스토리보드를 UML 로 옮기려면 Activity Diagram 이 낳을까요? 아니면 State Diagram 이 나을까요?
사실 둘의 차이도 정확히 모르겠습니다. 둘다 어찌보면 특정 이벤트들에 의해 상태가 변경되면서 특정 프로세스를 수행하게 되는 흐름을 나타내는면에서 동일한것 같기도 하고, Activity Diagram 의 경우에는 전에 수행하던 Business Process 분석 같은 냄새가 나기도 하고. 각각의 Activity 에 A1/A1.1 등의 프로세스 아이디만 붙이면 딱,비즈니스 프로세스 정의서가 될것 같기도 하고...

액티비티와 스테이트차트가 혼란스러운 것은 액티비티가 스테이트차트의 변종이기 때문이죠. 둘 간의 가장 큰 차이는 모델링 요소의 단위(unit)입니다. 액티비티는 말 그대로 행위를 단위로 그립니다. 하나의 행위에서 다른 행위로 넘어가는 이벤트/흐름을 화살표로 표기한 것이죠. 반면 스테이트차트는 상태가 단위입니다. 상태는 주인(owner)이 필요합니다. 객체지향에서는 객체의 상태가 되는 것이죠. 객체란 것은 프로그램 객체가 될 수도 있지만, 시스템, 부서, 서브 시스템, 컴포넌트 등이 될 수 있죠.

따라서, 업무 흐름을 표현하는데는 액티비티가 편리하고, 스테이트차트는 설계/구현시에 첨예한 부분을 명확하게 표현하는데 좋습니다. Business Process 분석에 액티비티나 시퀀스 다이어그램이 유용한 것도 맞습니다.

추가로 모델을 보내주셨는데 보편적인 조언이라는 것은 할 수가 없구요. 제가 그림을 봤을 때는 이것을 어디에 쓰려는 것인지 알 수가 없더군요. 결국, 작성하신 분도 아직 뚜렷한 용도를 찾지 못하고 다이어그래밍을 했음을 짐작할 수 있습니다.


설정

트랙백

댓글

요즘 저그 종족으로 빈틈을 허용 않는 플레이를 보여주는 프로게이머가 있다.
이름하여 마본좌. 마재윤에겐 본좌라는 별칭이 붙여졌다.
본좌의 의미가 무엇이냐는 skip 하겠다. 다만, 가오가 심하게 나오는 칭호라는 점이다.

간혹 벤더들은 고객을 봉으로 생각하는게 아니냐 하는 의구심이 든다.
영업을 해보지 않아서 그들의 입장을 잘 모르기에 그럴 것이다.

언젠가 한참 바쁜데 말도 안되는 툴을 팔려고 주요 관계자를 소집해서
회의를 빙자한 영업을 하는 일을 목격한 적이 있다.
이때 선정적인 말들(신기술, 재사용, 생산성)에 혹하면 바로 낚이게 된다.
잘 포장된 개념 수준에서 논의되는 내용에 한발씩 발을 들여놓기 시작한다.

그러나, 간혹 본좌급 PM을 만나면 다르다.
말하는 논조나 논리는 다르지만.. 다음과 같은 주제로 일침을 놓는다.

'지금 이런 회의를 왜 하냐?'
'장난하지 마라.'

욕심을 파고드는 것을 허용하지 않고
해야 할 일을 명확하게 인지하고 있는 것
이것만으로도 충분히 본좌라는 칭호를 얻을만큼.. 그것은 쉽지 않은 일이다.

설정

트랙백

댓글

이것은 순전히 가상 상황에 대한 기록이다.

회의실 밖에서도 분위기를 감지할 수 있을 정도로 고성과 갈등의 기류가 흘러 넘친다.
내용을 알 수 없다. 고객과 분석가 사이에서 요구사항을 놓고 실갱이를 하고 있다는 것이 짐작될 뿐.

고객측의 열혈 여과장과 개발업체측의 핏대 차장이 붙었다.
하이톤의 클라이막스를 맞은 분위기다.
잠시 쉬어주는 것이 좋을 것만 같다.
하지만, 그냥 간다.

다시 말하지만 이것은 순전히 가상 상황이다.
그럼에도 불구하고 매우 전형적인 모습이다.

시간이 흘러 첨예한 갈등을 일으켰던 사람들은
민망함을 달래기 위해 어색한 웃음을 연발한다.
정말 어색하다.

나이가 든다고 인격이 형성되는 것은 아니다.
윤리 시간에 인격도야를 답안으로 제출할 것을 종용 당하기 보다
인격도야가 무엇인지를 체험하기 위해 6 + 3 + 3년을 모두 할애했어도
학창 시절이 보람 있었을 것이라는 상념을 품어본다. 부질없는 시간 소모다.

나는 아직 전투적 자세에서 완전히 벗어나지 못했기 때문인지
종종 이런 모습을 만나게 된다.
여과장이 될 수 없다는게 천만 다행이라 생각된다.

어떤 이에게는 정치도 싸움, 개발도 싸움이다.
월급을 받는 일도 투쟁이고..

순전히 가상 상황이라서 그런지 현실감이 넘친다.

설정

트랙백

댓글

20명도 안되는 모임에서 한달에 고작 2만원 정도 되는 돈을 내고 쓰는 방법에 대해서
50일에 걸쳐서 11번에 걸쳐 53개 쓰레드가 달린 논의 끝에 합의를 이뤄가고 있다.
결과로 드러난 숫자의 나열만 놓고 보면 '참 한심하구나' 할 수 있다.

그러나, 애정을 가지고 긴 쓰레드를 함께 해온 입장에서는 무척 뿌듯하다.
어떤 모임에서나 내포된 문제... 하지만 아무도 솔직하게 자신을 드러내지 않는다.
우리도 오프에서보다는 온라인에서 더 허심탄회하게 의견을 제시했던 것 같다.

나는 한 가지를 분명히 인식했다.
논리적인 방안은 이해관계자의 솔직함에 비하면 아주 하찮은 것에 불과하다.
우리는 솔직함을 드러내는 방식에 대해서는 전혀 배우지 못했다.
오히려 예의라는 이름으로 완곡하게 표현하는 기법만 필요 이상으로 훈련받은 느낌이다.
이를 쉽게 확인해볼 수 있다. '~님'이라고 부를 때 그를 진심으로 존경하는가?

어제 점심에 부동산 정책에 대한 이야기가 튀어나왔다.
정책이 발표되자 마자 전문가들은 실패할 것이라고 나발을 분 모양이다.

얼마전에 어머니에게 이런 말을 한 적이 있다.
"엄마도 참 힘들었을 것 같아요. 어떻게 키워야 하는 지도 모른채
나이가 차면 결혼하고 아이 낳는 것이 당연한 시대였으니까."

중학교 1학년 사촌 꼬마애가 학원에서 9시까지 배운다고 한다.
농담 삼아 선생님한테 살살 좀 하자 그러라고 했다.
그말을 할 때 내 안에는 분노가 있었다.
우리는 어린 아이들에게 무엇을 가르쳐야 할지도 모른채
가르친다는 명목으로 돈을 벌어 먹고 살고 있는 것 같다는.. 생각에 화가 치밀었다.

개나 소나 다 자기가 솔직하다고 한다.
나는 정신없이 살다가 가끔 의식을 찾으면 솔직해지기 위해 노력을 한다.
그래도 난 내가 진짜 어떤 녀석인지 알기가 힘들다.

솔직함을 배우지 못한 세대가 주도하는 세상을 살아가면서
솔직함을 배우기란 기적에 가깝다.

그래서, 나는 스터디를 하고 있다는 것이 행복하다.
솔직하게 논의를 하는 방법을 배울 수 있는 흔치 않은 인큐베이터이기 때문이다.

설정

트랙백

댓글

재방송(원문 작성 일시:2006/06/07 (수) 23:24)

이바 야콥슨 컨설팅으로 국내에도 진출했던 이바 야콥슨이
Essential Unified Process (Ess UP) 라는 이름으로 UP를 간결하게 만든 버전은 내놓았다고 한다.

Agile Modeling의 저자 Scott Ambler가 정리한 글에 따르면
Ess UP의 특징은 다음과 같이 요약할 수 있다:
1. 사람들은 자세한 것을 읽지 않는 성향이 있기 때문에 간결한 기술과 핵심사항 요약 중심으로...
2. 문서 형태가 아닌 카드 형태로 의사소통

다른 사항도 있겠지만.. 위의 두 가지는..
길지 않은 기간동안이나마 내가 RUP를 적용한 프로젝트를 경험하면서
120% 공감할 수 있는 내용들이다.

문서질(?)은 프로젝트 성공의 최대의 적이라는 점...
그러나, 문서질은 괜히 하는 것은 아니다.
중요한 의사결정사항이 시간이 지나도 유실되지 않게 하고
공유가 되기 위한 의사소통의 목적이지만...
결정사항이 "문서"화 되면서 내용보다는 형식에 묻히게 되는 경향이 많다.

개인적인 생각으로는 일단 10장이 넘어가면 중요문서가 될수는 없다.
프로젝트를 수행하는 것은 고시공부가 아니기 때문이다. ^^;

Open UP
, Agile Unified Process (AUP) 와 더불어 Ess UP의 등장은
Agile의 반대편에 서 있었던 RUP에서도 차츰 Agile쪽으로 방향을 선회하고 있음을 말해준다.

지나치게 문서에 의존적인 절차들을 해소할 수 있는 유연한 프로젝트 관리 능력과
문서 대신에 중요 의사결정을 간략하게 묶어 둘 수 있는
아주 심플한 메모와 모델...
그리고, 위험요소들을 해결한 살아있는 모델인...
아키텍처 프로토타입이 프로젝트 초기부터 종료시점까지 존재할 수 있다면..

장담할 수 없지만 적어도.. 현재보다는 성공 가능성이 높아지지 않을까 생각해본다.

설정

트랙백

댓글

인터넷에서 좋은 글을 읽었다. 일부를 발췌한다.

디자인 패턴이란  바로 변화에 대한 대비이다.
우리가 학교에서 나온 숙제를 가지고 디자인 패턴을 적용할 필요는 없다. 마찬가지로 그 프로젝트가 일회성이고 스펙의 변화가 없다면 패턴이 적용될 필요가 없다. 그러나 우리는(제품 개발로 먹고사는 대부분의 소프트웨어 개발자가 여기에 속한다) 대부분 프로젝트 완료후의 매우 긴 기간의 유지 보수 기간을 가진다. 스펙은 심지어 개발기간에도 변하며 사용중에도 부지런히 변한다. 코딩을 하다가도 스펙의 잘 못된 점이 발견되기도 한다. 즉 스펙은 언제나 변할 수 있는 여지가 있다.

개발자들이 개발을 할때는 스펙이  문제 영역(Problem Domain)의 컨텍스트가 된다. 그안에서 최적화된 솔루션을 내놓는 것이 개발자의 할 일이다. 그러나 이 스펙은 계속 변하므로 개발자는 항상 이에 대비하여 디자인을 해야 한다. 바로 개발자의 연륜은 여기에서 판가름된다. 경험있는 개발자는 자신의 코드를 항상 일반적으로 만들려고 노력한다.

디자인 패턴은 변화되어야 할 클래스의 수를 최소화시켜 준다. 커스터마이징되는 부분과 뼈대가 되는 부분이 디자인때에 이미 분리가 되기 때문이다.  많은 디자인 패턴의 캐털로그를 하나 하나 음미해 보자. 모든 디자인 패터들의 일관된 주제는 바로 이 “변화”라는 것을 알 수 있을 것이다.

내용 자체보다는 디자인 패턴이 어떤 상황에서 필요한 것이라고 먼저 언급한 것이 더욱 인상적이다. 내가 디자인 패턴을 처음 접했을 때는 내용 자체에 매료되었던 것 같다. 그 참맛을 아는 것도 아니면서 무작정 파고 들어서... 이내 갈증만 느꼈다.ㅡㅡ;

이유와 목적이 중요하다는 사실을 누구나 알고 있다. 다만, 이해의 정도가 문제다. 내가 생각하는 이상적인 이해는 몸으로 실천하게 되는 것이다. 즉, 굳이 떠올리지 않아도 자연스레 그렇게 하는 것. 인지하는 것과 행동으로 옮기고 습관화 하는 것은 너무나도 다른 일이다. 그래서 이상적이란 수식어구를 붙인 것이기도 하다.

어떤 고객님이 처음으로 CBD 프로젝트를 진행하는 와중에 다시는 CBD를 하지 않겠다고 푸념을 했다. 참 안타깝다고 생각했는데, 다시 생각해보면 흥분할 일도 아니다. CBD 가 아닌 다른 방법론을 적용했다면 성공했을 것인가.ㅡㅡ;

한가지 정말 아쉬운 점은 많은 개발자들에게 CBD는 그냥 하도록 주어진 것이라는 점이다. 왜 그것을 해야 하는지에 대해선 Nothing 이다. 그런 태도에 대해 내가 할 수 있는 것이 무엇이 있을지는 잘 모르겠다. 다만.. 이런 생각이 든다.

우리가 삶의 이유를 알고 선택해서 태어난 것이 아니라 하더라도 우리는 필연적으로 삶의 목표를 떠올리게 된다. 왜냐하면 적어도 그래야만 발전이란 것을 할 수 있기 때문이다.


재방송(원문 작성 일시: 2005/09/24 (토) 01:53)

설정

트랙백

댓글

최근 들어 대립하지 않으려는 의지는 균형감을 자꾸 생각하게 한다.
합리적인 판단과 조화로운 결정 사이에는 많이 차이기 있지만
여기서 그것에 대해 긴 이야기를 늘어놓고 싶지는 않다.

최근 몇 차례 한 가지 기술적 이슈에 대해 자문 요청을 받았다.
자문을 할 수록 내가 정말 하고 싶은 말은
'나는 A라는 툴을 싫어한다.'에 가깝다는 것을 알았다.
(물론, 최대한 완곡하게 이야기 하면서, 내면에서는 그렇게 말하려는 욕구를 달래고 있다.)

기술과 툴 자체에 대해 공부하는 위치에 서면
스스로 세운 어떤 기준에 부합하지 못하는 기술/툴에 대해서는 비판적이 될 수 밖에 없다.
그것이 나를 위한 항변이지만...
반대 편으로 돌아서보자.
A가 아니라면 대체할 수 있는 뭔가가 있어야 한다.
사실 A에 완전한 비교 우위를 점하는 어떤 툴을 써보지 않은 이상
다른 어떤 툴도 지지하기는 힘들다.

또한, A라는 툴을 공급하는 업체와 그 직원들까지 생각하면 더 신중하게 발언해야 하기에
섣불리 A가 나쁘다라고 말할 수도 없다.

이런 류의 자문은 대개 급작스러운 순간에 구두로 물어오는 경우가 많아
말을 하면서 판단도 해야 한다.

여기서 최선 안은 무엇일까?

몇 차례 이런 경우를 겪으면서 내가 도출한 몇 가지는 아래와 같다.

1. 직접 해보지 않은 단순한 느낌이나 어디선가 들은 얘기는 언급하지 않는다.
모호한 지식을 풀어놓다 보면 스스로의 선호가 개입되기 쉽고
자칫 별 근거도 없는 주관적인 의견을 내놓을 수 있다.

2. 가능한 구체적으로 언급한다.
자문을 받는 의뢰인은 몰라서 묻는 것이다. 따라서, 오해의 소지가 존재한다.
구체적일수록 오해의 폭은 작고
추상적일수록 오해의 폭은 크다.

3. 차분하게 발언의 폭을 조절하여 리듬을 유지하라.
혹시 상대가 조급하여 질문 공세를 하게 되면
호흡 조절없이 정신없이 답변할 수 있다.
이렇게 되면 여유를 잃어 충분히 생각하면서 발언할 기회를 놓친다.
답변 와중에 한번 쯤 웃을 수 있는 여유를 갖을 수 있다면
분명 더 진솔한 답을 낼 수 있다.

설정

트랙백

댓글

InfoQ에 올라온 아티클에서 아주 인상적인 구절이 눈에 띈다.

"If the only tool you have is a hammer, then everything looks like a nail."

유명한 속담인 모양인데 재밌는 말이다.
망치만 사용하는 사람은 망치로만 모든 문제를 해결하려 들 수 있다.

예전에 UML/RUP를 처음 공부할 때
모든 것을 다 UML로 표현하고, 잘 정리된 공정에 기반하여 일하려는 생각에 집착했다.
이같은 현상은 별로 특이할 것도 없다.
새로운 기술을 막 익힌 사람들 사이에서도 쉽게 발견할 수 있는 현상이다.
다른 회사 사람과의 술자리에서 연구실 직원 한명이 너무 신기술 적용만 좋아해서
툴(내부 소스의 안정성)이 엉망이 되었다는 푸념을 하는 일을 들는 것은 나만의 일은 아니다.

망치라는 툴을 익힌 것이 주는 즐거움에
다른 것을 볼 수 없는 지경에 이르는 것은 단지 우화같은 일이 아니다.

또 다른 측면에서 보면 검증된 신기술이나 새로운 기법/정책을 보급하여 할 때
거부감을 보이는 사람들을 쉽게 만날 수 있다.

그들은 새로운 것을 새롭게 보지 않는다.
자신들의 경험과 지식에 기반해서만 해석하려고 든다.
못과 함께 니벳을 써야 하는 경우에도 망치로 할 수 있다고 말한다.
그런 류의 사상을 잘 드러내는 말이 '결국은 데이터 아니냐?' 같은 말이다.

결국은 조화사람이지... 결국은 객체지향도 데이터도 Spring도 Java도 Ruby도 다 아니다.^^
동료들이 드라이버 사용법을 배울 준비가 되어 있다면
드라이버를 함께 배워가야 하지만
최신식 전기 드릴이 아무리 좋아도(본인 눈에 좋아 보여도)

동료들의 성향/배경을 죄다 무시하고 드릴만 쓰라고 한다면
스스로도 상처를 받게 된다.(그런 압박을 가할 때 평정심을 갖고 동료들의 눈을 똑바로 볼 수 있는가에 답이 나오다..^^)

한편, 사람들은 향상되고자 한다. 향상은 자신의 한계를 넘어서는 것이다.
'좋긴 한데 현실적으로 어렵다.'
'난 원래 그런 방식은 좋아하지 않아.'
'지금 업무도 너무 바빠.'

이렇게 말하고 있을 때 한번쯤 생각해봐야 한다.
혹시 지금이 향상을 위한 도전을 해야 할 때가 아닌가 하고..

다 쓰고 나니.. 스스로에게 한 마디 하고 싶네.
'너나 잘하세요.' ㅋㅋㅋ

설정

트랙백

댓글

엠파스에서 2006/08/02 (수) 13:50에 썼던 글인데... 재방송입니다. :)

네거티브 전략 그리고 Spring의 경쟁자에 달렸던 토비님 답글 중에 이런 것이 있다.

일부 사람들이 Spring을 안쓰는 이유는 단순합니다.
무지하기 때문입니다

공감이 간다. 더하여 한가지 더 생각해보면
안쓰려고 하는 이유는 무지가 드러나는 것이 두렵기 때문이다.

자신의 무지를 대하는 태도

나는 그걸 개선해보고 싶다.
스스로 무지함을 드러내지 않기 위해
불필요한 에너지를 소모하는 경우가 많다.
그 습관을 고치려면 무지를 드러내야 하는 상황을 만들어야 한다.

아는 분이 프레임워크에 관심이 많아서
홈페이지를 통해 정보를 얻어 관련 회사에 입사한 일이 있다.
그리고, 이내 실망하여 다른 회사로 옮겼다.
그럴싸한 홍보자료의 이면에 과연 무엇을 준비했는가?

국내 SI 업계에서 부정적인 면들을 설명하는 것은 쉽다.
수많은 핑계가 존재한다. 환경적 요인이나 학교의 문제 등등
그러나, 그런 이유를 양파껍질 까듯이 파고 들어가 보면 무엇이 남는가?

오늘 모 프로젝트 입찰 경쟁과정에서
한 업체가 다른 업체에 대해 최소한의 예의를 지키지 않은 모욕적인 언사를 행한 소식을 들었다.
그리고 자사의 경쟁력이라고 내새운 한마디...
피해자쪽을 통해 들은 얘기이기에 감정적인 왜곡이 있을 수 있지만
참으로 딱한 일이다.

어차피... 나의 시간은 정해져 있다.
'단지 소모적인 개발자로 젊은 날을 살았구나'
그렇게 현재를 회고할 것인가?
먼저 내면의 두려움부터 제거해라.

FUD와 같은 네거티브 전략을 쓰는 쪽은
상대를 자신과 같은 주파수로 끌어들이길 원한다.
그래서 두려움과 증오심을 촉발시켜 내용면에서의 약점을 희석하려 드는 것이다.
두려움과 증오심이 줄어들 수 있다면.. ^^

나는 대단한 개발자가 되고 싶은 생각은 없다.
나는 당장 내일 무엇을 해야 한다는 확신도 가지고 있지 않다.
다만, 현실이 불합리하다고 느끼면 불합리를 개선할 수 있게 나를 바꾸면 된다.
나 역시 현실의 일부이고, 불합리의 일부이기에
최소한 나는 스스로 바꿀 수 있다.

개발자들도 마음에 싹을 틔울 때가 되었다.
조금 느리더라도.. 어차피 정해진 때를 살다 가는 것인데..
부담감 갖을 필요 없지 않는가?

힘을 내자!

2peaks  2006/08/02 16:16 
구글 서치하다 님의 블로그를 접하게 되었습니다. 님의 글을 읽을때마다 난 언제쯤 님에 버금가는 내공을 가지게될까 하고 머리를 뽑아봅니다..

나 2006/08/02 16:31 
쩝... 민망해지는 글이네요.. ^^;

아.. 갑자기 할말이 생각나지 않는데..
전 내공 운운할 대상이 아닙니다.
솔직히 제가 내공을 갖고 있는 분야는 춤(hiphop)뿐이죠..ㅋㅋ

다만, 그렇게 보신다는 것은
제가 블로그를 하고자 하는 의지를 강화하는 쪽으로 이용하고 있기 때문일껍니다. 스스로 한계를 넘어서기 위해서는 온갖 방법을 다 이용해야 하죠. 지쳐서 포기하지 않도록 스스로 자신감을 불어넣어주고, 달래주기도 하고...

머리 뽑지 마시고.. 시작해보세요. 뭐든지..
저도 오늘 저녁 수영장에 다시 도전합니다.
벌써.. 세번째인데 맨날 배우다 말아서..
이번에 꼭 접영까지 다녀야지.. ㅋㅋ

글 남겨주셔서 감사합니다.

Max  2006/08/03 09:20 
블로그에 자주 글이 올라오는걸 보면,
주인장은 정말 부지런한 사람이다라는걸 느낄수 있습니다.
그건 그만큼 열정이 있어야만 가능하죠.
열정이 지속된다면, 원치 않아도 대단한 개발자가 되지 않겠습니까?
내공이 높고 낮음 보다는 그 열정과 마음가짐이 대단한 사람임을 느끼게 합니다.
(물론 내공도 높습니다. 다른글 보시면 아시겠지만....^^ )

나 2006/08/03 09:20 
자주 글 남겨주셔서 감사합니다. ^^
결과보다는 과정을 중요시하려고 노력중이긴 합니다.
저처럼 게으른 사람이 부지런해보이는 것은 블로그까지 동원해서 천성적인 게으름을 이겨내려는 몸부림 탓이겠죠..ㅋㅋ

조진우  2006/08/03 09:44 
멋있고 공감가는 말입니다..다른 블로그에 다른 분은 Burning이란 말을 쓰셨더라고여..무엇인가 내 젊은과 시간을 위해 태울것이 있어야 한다고..어제부터 프로그램 하나잡고 고민하다 잠도 못자고..ㅋㅋ 아직 부족한 저를 알기에 오늘도 또 한번 부딪치러 갑니다..

나 2006/08/03 11:19 
역시.. ^^

사람마다 다양한 관점으로 세상을 보게 되는 것 같습니다.
사실 저 글은 열정에 대한 이야기라기 보다...
주위를 둘러볼 줄 아는 의식을 위해서 스스로를 더 차분히 다스렸음 하는 마음에서 쓴 글입니다. 워낙에 마구잡이로 글을 쓰다보니.. 전달이 안되길 하지만..ㅋㅋ

전에 소설가 박완서씨가 TV에서 평론가의 추측성 물음에 짜증을 내는 것을 본 적이 있습니다. 글을 읽는 것은 독자의 몫이라는.. ^^

오승택  2006/08/03 09:50 
'나는 대단한 개발자가 되고 싶은 생각은 없다.
나는 당장 내일 무엇을 해야 한다는 확신도 가지고 있지 않다.
다만, 현실이 불합리하다고 느끼면 불합리를 개선할 수 있게 나를 바꾸면 된다.
나 역시 현실의 일부이고, 불합리의 일부이기에
최소한 나는 스스로 바꿀 수 있다.'

참 공감이 가는 글입니다. 현재 저도 비슷한 딜레마에 허덕이는 시점입니다..
영회님 말씀처럼 힘을 낼 시기인것 같네요^^

ologist  2006/08/05 15:25 
다들 칭찬을 많이 하셔서 저도 합류해 봅니다.
비단, 개발에 대한 내공도 훌륭하지만, 액면도 생각보다 훌륭했다는...^^
여기 자주오시는 여자분들 관심 갖으셔도 되겠습니다.

초보  2006/08/06 00:39 
늦은 나이에 초보로 시작해 힘들어 허덕이고있답니다.
너무 하고 싶어서 시작한 일인데 제가 맡은 유지보수없무가 너무 별거아니게 느껴질때 가끔 영회님의 블로그를 방문합니다.
나도 언젠가는 저 경지에 이를수 있을까..
아니.. 이르러야지..
항상 여러 정보들 진솔한 글들.. 잘보고 있습니다.
이런 블로그를 운영해 주셔서 감사합니다.



설정

트랙백

댓글

가끔 사람들은 이렇게 묻곤 한다.
'그런 것들은 누구한테 배웠어요?'

누구한테 배웠는지 확실하지 않다.
보고 배운 것이라고 해도
경험을 통해 내 것으로 만들기 전에는 '배운 것'이라고 할 수 없다.
그것은 마치 수학 공식을 다 외워도 문제를 풀지 못하는 것과 같은 이치다.

예전에는 나의 식견을 훨씬 뛰어넘는 사람에게 배움을 얻게 되면
입에 침이 마르도록 그를 칭송했다.
그 즈음에는 내 것으로 만든 것은 아무 것도 없었다.
결국 배운 것이 없었다. 마치 TV의 등장 인물 대하듯... 주변의 스승을 대한 것이다.

최근에 쭉쭉빵빵 여자분 외에 뵙고 싶은 분이 있다. ^^
모처에서 프로젝트를 진행할 때
본인의 사고 틀에 맞춰서 작업을 하게 하여
주변 사람들에게 고통을 맛보게 한 분이다.
당시 회식 뒷풀이나 티타임/흡연시간에 단연 화제의 주인공으로 회자되던 분인데...

나는 그 분을 통해서 많이 성장했다.

만일 주변에 멘토가 없다고 아쉬워하는 분이 있다면
다시 한번 둘러보라고 얘기해주고 싶다.

스티브 잡스만이 인생의 스승이 되는 것은 아니다.
노력하면 스승을 찾는 법을 체득할 수 있다. :)

설정

트랙백

댓글

'경험 공유'라는 말을 어렵지 않게 들을 수 있다.
대개는 '경험한 바를 공유하겠다'는 의도일 것이다.

경험 공유의 전제 조건은 다음과 같이 생각해볼 수 있다.
1. 같은 혹은 거의 유사한 경험을 쌍방 모두가 갖고 있을 때
2. 전달하는 이와 같은 경험을 듣는 이가 갖고 있지 않지만,
듣고 나서 행동에 변화가 있을 때...

'행동하지 않으면 경험은 공유'될 수 없다.

설정

트랙백

댓글

Spring Forum의 알림 메일을 받았다.
보편적인 것이 아니라 valang을 취급한 탓에 오랜동안 답글이 없이 소외된 글을 올렸다.
(springmodules의 valang을 활용한 Validation 테스트 참조)

benjwarner라는 멤버가
내가 짠 코드에 하나의 메소드를 추가한 형태로 사용한다는 이야기를 전해준다.

다른 사람이 짠 코드..
같은 팀도 아니고, 같은 국민도 아니고.. 누군지도 모르는 사람의 코드를 수용하는 태도
이러하 태도는 과 같다.
단지 접하는 것만으로도 꽤 오랫동안 즐거운 기분을 유지할 수 있었다. ^^

설정

트랙백

댓글

그것을 벗어나야 성장할 수 있다.

개발자로 살다보면
내가 애써 익힌 개념들을 아는 것이 무척 중요하다고 믿게 되고
너무 기본적인 것인데 모르는 사람을
무의식적으로 혹은 농담꺼리로 비웃는 일이 생긴다.

하지만, 내가 아는 것은 단지 내가 아는 것일 뿐이고
내가 안다고 하는 것도 그저 내가 그렇게 인식할 뿐이다.
내가 중요하다고 보는 것은 단지 내가 중요하다고 볼 뿐이다.

다른 사람도 그래야 한다는 것은 일종의 폭력이다. (실제로 전쟁의 원인이 된다.)

붕어

너무 재미있는 글을 봤다.
'방충망'이라니...

지금.. 내가 만화의 주인공이 된 양
즐거운 마음으로 동화될 수 있다는 것은 다행스런 일이다.

아직도 한참 멀었지만, 내가 아는 것이 중요하다는 집착을 조금은 버린 것 같다. (아주 조금..ㅡㅡ;)

프로와 아마의 차이를 보면 이런 내용이 나온다.
프로페셔널은 동료를 관찰하고 그들로부터 테크닉을 흡수할 수 있는 것이 매우 중요합니다. 아마추어는 "저는 제 방식으로만 일합니다"라고 말할 수 있습니다. 프로페셔널은 "한동안 당신의 방식으로 해보고 어떻게 되는지 봅시다"라고 말할 수 있어야 합니다. ... 워드 커닝햄

내가 믿는 것을 내려 놓을 수 있어야  다른 것을 받아 들일 수 있다.
내게 없는 다른 것을 받아들여야 내가 성장하는 것은 당연한 것 아닌가?
하지만.. 몸으로 살아내는 것은 말처럼 쉽지 않다. ^^

마침 이런 글도 올라오는군
Garrett Smith: Agile is a means to an end, not the end itself

설정

트랙백

댓글

수영장에서도 회식이 있다.
금요일에 다 빠진다고.. 월요일부터 회식을 했다.
끝까지 함께 있다 보니..
허겁지겁 눈을 떠서 택시로 출근을 한다.

고객사 사무실에 벌건 얼굴로 들어간다.
다행히 지각은 안했다.
이런 일이 처음은 아니라... 나름 노련한 대처 경험이 있다.

아직 술이 덜 깼다.
이전 경험에 의하면 점심을 먹고 와야 해장이 된다.

약간의 취기가
다른 사람들에게 평소보다 열린 자세를 취하게 한다.
잡념과도 같은 치밀한 사고가 다소 흐릿해진다.
그래서 일처리가 잘된다.

술을 마시지 않고도
이성의 볼륨을 조절할 수 있다면...
나는 지금보다 훨씬 행복할 것이다.

어쨌든 지금은 행복하다.

설정

트랙백

댓글

복 있는 사람은 악인의 꾀를 쫒지 아니하며...
시냇가에 심은 나무가 시절을 쫓아 과실을 맺으며
그 잎사귀가 마르지 아니함 같으니
그 행사가 다 형통하리로다.

시편중에서


씨도 뿌리지 않고, 과실만 탐하는 일이 일상이 되어 버렸다.
굳이 사회가 그렇게 부축인다고 변명은 하지 말자.
농사를 지어본 적이 없어서 그렇다고도..ㅡㅡ;
무언가 얻고자 할 때는 씨를 뿌리고
끝임없이 보살펴주겠다는 의지를 지키려고 노력하면 된다.
그 외에 다른 것은 생각할 필요가 없다.
마음은 농부와 같을 수 있기를...


2005/03/20 (일) 엠파스에서

설정

트랙백

댓글

http://www.kbs.co.kr/1tv/sisa/dozagi/index.html


모처럼 휴일에 시간이 있어서 티비를 보다가
'도자기'라는 다큐를 보게 되었습니다.
스포츠 프로 이외에는 정해진 프로그램을 보지 않는 저로써는 인연으로 만난 것이죠. ^^;
아마도 6부작인 모양인데, 저는 5,6회를 보게 되었습니다.

처음에는 중국, 우리나라와 베트남만이 자기를 생산할 수 있었다는 사실과
유럽에서 자기를 열망했다는 점들에 은근히 자부심이 생기더군요.
하여튼 여기까지는 건성으로 티비를 보던 상태였죠.

그러다가 저를 자극한 부분은 임진왜란이 자기 때문에 일어났다는 사실이었습니다.
당시 일본의 사무라이들 사이에서는 조선의 자기가 성과 바뀔 정도였다는데
토요토미 히데요시가 전쟁을 일으켜 도공 천명을 납치해갔다고 합니다.
그 후 일본은 조선을 제침은 물론, 유럽에서도 최고로 평가받는 자기 생산국이 되었고,
일본에서 자기 생산에 성공한 조선의 도공 '이삼평'의 석상인지 동상이 규슈 지방에 있다고 합니다.

일시적으로 자부심과 허탈감, 작은 분노가 내면을 흔들었습니다.
5부에서의 일이었는데 마지막 회에서 진한 여운을 남기는 말은
'송나라에서 자기를 만드는 것이 우주왕복선을 만드는 것과 같다'는 말이었습니다.
자기는 항상 첨단 기술이었고, 현재도 우주왕복선의 외피를 구성하고 있습니다.

다큐를 보고 나서 저는 수렴과정에 들어가게 됩니다.
일종의 독후감을 머리속으로 쓰는 것이라고 볼 수 있죠.

먼저 일본의 치밀함을 배워야 한다는 점입니다.
비록 우리는 원조지만, 어떤 면에서 '원조'를 내새우는 것은 궁핍해보입니다.
품질에서 자신이 있다면, 원조냐 아니냐의 논란은 양념에 지나지 않습니다.
일본은 도공을 훔쳐다가 조선의 자기를 베낀 것에 만족한 것이 아니고
출발점으로 삼은 것이라고 할 수 있습니다.
이것은 우리나라에서 각종 기술이나 기법
예를 들어 CMM, CBD, EA 등을 들여오는 것만으로 뭔가 이루었다고 생각하고
벌써 안주하고, 다음을 생각하는 황당한 모습에 비춰보면 반드시 배워야 할 것입니다.

또 한가지 바로 기록하는 습관입니다. 저는 기록하는 습관을 기르려고 의식적으로 노력합니다.
다행히 어릴적에 어머니께서 일기를 쓰도록 강제하셔서
저는 쓰는 것에 대한 거부감이 없고, 오히려 말하는 것보다 쓰는 것을 좋아합니다. 고마운 일이죠.

우리나라는 쓰는 것을 좋아하지 않습니다. 어떤 기록을 남길 때는 단지 '써버리는' 경향까지 있습니다. 무언가 기록을 남길 때는 그 문서의 용도를 생각해야 합니다. 그래서, 읽혀질 수 있겠끔 써야 하겠죠. 또한, 제가 속한 소프트웨어 개발분야에서는 대개 지속적으로 갱신되어야 할 것들이 많습니다. 이런 것들을 기록할 때는 후일 갱신이 가능한 형태를 고려해야 합니다. 그렇지 않으면 그냥 '써버리는' 것이 아닐까요?

독일에서 자기를 생산하고, 전 유럽에 자기 생산 기술이 퍼지게 된 것은 바로 기록이 남겨져서입니다. 유럽이 중국을 넘어설 정도로 비약적으로 자기 기술을 발전시킨 계기는 바로 기록이라고 할 수 있을 것입니다. 자기뿐 아닌 기술발전의 계기가 기록이라고 할 수 있을런지도 모릅니다. 우리는 종이보다 더욱 훌륭한 기록수단을 갖게 되었습니다.

가치있는 지식을 기술하는 것을 장려하고, 기록하는 방법을 개발 및 보급하고, 효과적 기록하고, 저장 및 처리하고, 전달할 수 있게 하는 것. 어쩌면 이것이 소프트웨어 개발의 근본적인 사명일지 모르겠습니다.

2004/12/13 (월) 엠파스에서

설정

트랙백

댓글