다녀오세요♡

개인적으로 올해 읽었던(절대 나왔던이 아니고) 이쪽 분야 책 중에서 미처 독후감을 적지는 못했던, 하지만 마음에 들었던 책 몇 권을 적어봅니다.

제프리 리처의 Windows via C/C++
윈도우 프로그래머라면 별 네개. 거기에 C/C++프로그래머라면 별 한 개 추가.

제가 하드코어한 윈도우 개발자가 아닌 것은 분명하지만 일단 윈도우에서 돌아가는 프로그램들을 만들고 있기 때문에 윈도우API가 어떤 식으로 돌아가고 있는지 알아두는 것도 도움이 될 것 같더라구요.
그런 의미에서 이 책은 정말 단비와도 같은 책이었다고 할 수 있을 것 같습니다. 몇몇 하드코어[...]한 부분은 대략 제꼈지만 그때그때 필요한 부분만 참조하는 것 만으로도 충분히 제값을 하고 있습니다.


HARD CODE 하드 코드 : 나잘난 박사의 IT 정글 서바이벌 가이드
개발론에 관심있다면 별 네개. 거기에 MS 빠라면 별한개 추가. MS 까라면 별한개 제거.

드리밍 인 코드와 묶어 읽었으면 더 재밌었을 법했던 책입니다. MS도 이런데 우리라고 별수 있냐 ^ㅁ^ 라고.
역자분 홈페이지에서 했던 예약 인증 이벤트에 응모해 초난감 기업의 조건[...] 책도 덤으로 얻고, 에이콘출판사 부사장님 친필 예약 감사글도 받았었기 때문에(내게 카드를 써 준 여자는 부사장님이 첨이에요! ...-_-;;),
아무튼 그래서 완독하자마자 이 책에 대해 찬양하는 글도 적어 판매에 기여하고 싶었는데 어찌된게 회사 마감도 있고 이래저래 타이밍을 놓쳐버려 죄송할 따름입니다. 흑흑ㅠㅠ
드리밍 인 코드와 마찬가지로 '쟁쟁한 실력자도 아닌 내가 일정을 못 맞추는 것 역시 당연한 일'이라는... 그런 기본적인 교훈(?)에, 개발자들 간의 커뮤니케이션이나 개발론의 존재 의의, 덤으로 왜 MS가 아직도 그 많은 추격자들을 따돌리고 킹왕짱으로서 버티고 있을 수 있는지 알 수 있는 내용이 가득 담겨 있는, 가벼운 마음으로 읽을 수 있지만 결코 가볍지 않은 멋진 책이었습니다.
올해에도 이런 책 좀 나와줬으면 좋겠어요.
이 책을 구입해 덤으로 받았던, '초난감 기업의 조건'도 재밌었습니다. 쓰여있는 비슷한 삽질을 하고 있는 회사를 몇군데 아는데...
그 가운데 우리 회사도 포함..읍...으읍!! (끌려간다)


소프트웨어 크리에이티비티 + 컨플릭트 2.0 세트
고전에 관심있다면 별 다섯개. 관심 없다면 별 네개.

고전에 속하는 책이고 해서 오래전부터 읽어보고 싶었었는데 마침 책이 리뉴얼되면서 새끈한 표지에 가격도 저렴해졌길래 읽었던 책입니다. 요즘도 가끔 펴서 읽고 있으면 참 재미있는게, 그리고 예나 지금이나 변한게 없다는 사실이 마음을 찌릅니다-_-;;;
정말 고전은 시간이 지나도 빛이 바래지지 않는 모양이에요.
프로그래머라면 꼭 읽어야 할 조엘 온 소프트웨어 정도의 필독서!! 아니 그것보다 더 짱인 책임!!
이라고 추천사를 날리고 싶지만 나는 그런 권위 있는 레벨의 사람이 아니니 조용히 있겠습니다[...]


Effective C++ (이펙티브 C++) (3판)
C++ 프로그래머라면 별 네개. 농담 따먹기 싫어하면 별 한개 삭제. 농담 따먹기 좋아하면 별 한개 추가.

작년엔 상대적으로 프로그래밍 언어에 대한 책은 의외로 덜 샀다는 느낌입니다만, Effective C++는 대림 판(2판)을 이미 갖고 있었었기 때문에, 그리고 원서도 선물을 받은 적이 있기 때문에(참 좋은 내용이더군요, 물론 영어 혐오증 때문에 읽지는 않았습니다),
솔직히 그다지 땡기지는 않았...습니다만 그래도 나온지 좀 된 책이어서 저렴해졌기 때문에 구매했었던 것 같네요.
편역, 이라는 것을 개인적으로 좋아하지는 않기 때문에 게다가 이렇게 심한 편역은 차라리 직접 집필하시지 그러셔쎄여 하는 느낌...이 들어서 좀 그런게 있었습니다. 차라리 대림판이 번역이 잘됐다고 느껴지게 만드는 것도 나름 기술입니다. 네-_-;;;
너무 기계적인 번역을 했다는 느낌이 드는 것도 물론 좋지 않지만, 이렇게까지 할 필요가 있었을까 하는 생각도 들었더랬습니다. 적절한 밸런스를 유지한다는게 쉽지 않은 거겠지만... 뭐 Effective STL/More Effective C++ 때 나름 독자층에게 신선하게 받아들여졌었기 때문에 더욱더 파워업시키신 것이었겠거니 하고는 있습니다.
어차피 이 시점에 이런 불평해봐야, 이긴 합니다. 역서도 읽힐만큼 다 읽힌 책이고 하니까...


Head First Design Patterns : 스토리가 있는 패턴 학습법
별 두개. 자바 배우는 중이라면 별 한개 추가. 그림책 좋아하면 별 한개 더 추가.

자바와 도해를 이용한 패턴 책입니다. 친절하게 설명한 것 같으면서도 애매한 설명이 이 책의 백미.
성안당의 만화로 배우는 아무개 시리즈의 실사판....일리가 업자나!!


프로그래밍 수련법

제목에 낚여서 산 책...이긴 합니다.
작년 말에 막 사서 뭔가 적기가 애매하네요. 그런데 이것도 원서는 나온지 좀 된 고전인가봐요.
실은 출퇴근하면서 차근차근 읽다가 자료구조 부분에서 졸려서 넘어가지 못하고 있습니다 어흐흐흐흫


2009년 시리즈 두번째가 끝났습니다. ...이제 또다시 포스팅 거리가 없어ㅠㅠ 엏거두ㅠ두ㅠㅏ듀

겸손한 개발자가 만든 거만한 소프트웨어
신승환 지음 / 인사이트
나의 점수 : ★★

어쩌다보니 최근에 지난 5월에 주문한 책이 또 개발론에 대한 책이 되었습니다.
뭐랄까 개발론에 꽂혀서...라기보다는, 이 책 역시 서평들이 의외로 괜찮았고, 저자 분이 개인 블로그에 올리고 계시는 글들을 꾸준히 애독해왔기 때문에, 눈팅하는 팬으로서(片思い같은거려나요), 어쨌거나 저술하신 모든 책은 아니더라도 가끔은 하나 사드리는 것이 그간의 감사함에 대한 말 없는 독자의 보답이라고 생각했기 때문이었습니다.

뭐 그건 그렇고요. 저자 분에 대한 제 개인적인 짝사랑과는 별도로, 책은 책이기 때문에 책에 대해서는 그다지 좋은 이야기를 적지 않으려 합니다. 이 점 미리 양해를.

이전 직장에선 대형 서점이 5분 거리였었는데, 이제는 지하철 한 정거장 정도의 거리를 걸어가야만 서점에서 책을 살펴볼 수 있게 된 것도 이 책을 구입하는데 한 몫을 했습니다. 즉 내용을 안 보고 목차만 훑어보고, 저자 이름 한번 보고, 웹 상에서 그냥 우왕 하고 구입한. 이른바 포샵처리된 사진만 보고 몇통의 전화 통화만으로 신부와 결혼하기로 해버린 신랑과도 같은?! (비유가 이상하다)
... 뭐 서점에서 책 내용을 좀 훑어볼 수 있었다면 조용히 다시 책장에 책을 꽂아놨을텐데 하는 생각도 들었다는 이야기입니다. 네.

책 두께가 꽤 되어서 처음 받았을 때는 꽤 많은 내용을 기대했습니다만, 책을 펴보니 글씨도 진짜 크고 줄간격도 널찍널찍하더군요. (어쩐지 대놓고 비교해보지는 않았지만 저번 개떡 책보다 비슷하거나 더 넓은 느낌? -_-;;;) 책 읽으면서 자신의 생각을 책 중간중간에 적어보라는 친절한 배려 내지는 컴퓨터 오래하는 독자들의 시력을 보호하려는 출판사의 배려라고 생각하겠습니다. 게다가 책 내내 적혀 있는 친절하고도 한결 같은 존댓말도 인상적이네요. 페이지 수 늘리려고 고생한 편집자의 수고가 눈에 아른가려 하품의 눈물이 눈 앞을 가릴 지경입니다.

물론 얇고 비싼 책은 사람들이 당연하다는 듯이 기피하고는 있다지만...;;; 그래도 이건 좀 너무 좀;;; 음;;;
설마 이런 식의 초딩소설책 스러운 호쾌한 편집이 요즘 IT출판업계 트렌드인걸까; 내가 그 대세를 못 따라가고 있는걸까...;;

다시 이야기를 돌려서,

그런데 뭐랄까 하필이면 얼마전에 읽은 책이 '드리밍 인 코드'. 라는 것이 마음이 아프다고 해야할지.
뭐랄까 하필이면 작년 이맘 때 즈음에 읽었던 책이 '소프트웨어, 누가 이렇게 개떡같이 만든거야' 라는 것이 마음이 아프다고 해야할지.

언급한 두 책들을 읽지 않은 상태에서 이 책을 접했다면 좀더 좋은 평가를 내릴 수 있었을지도 모르지만, 일단 전 비슷한 성격의 다른 책을 이미 최근에 읽어버렸다는 것이 좀 문제인 것이겠지요...
이 책을 '드리밍 인 코드'와 비교하면 '드리밍 인 코드'가 서운해 할 겁니다.
그렇다고 '소프트웨어, 누가 이렇게 개떡같이 만든거야'와 이 책을 비교하자니, 같은 출판사에서 나온 책 아니랄까봐, '개떡' 책을 '거만'책이 좀 자주 인용하고 있어요.
뭐랄까 어떤 면으로는 '개떡' 책을 한국 개발자 실정에 맞게 적당히 고쳐 쓴 느낌이었다고 해야 할까요.
책 내용을 보면 '거만'라는 표현보다는 '개떡'이라는 표현이 더 눈에 띄고 자주 나오는 것 같기도 하구요.

책 내용을 훑어보면, 책 타이틀에서 눈에 확 들어오는 '거만한 소프트웨어' 자체에 대한 내용은 전반부에 집중되어 있고,
후반부에는 팀을 어떻게 짜고 팀원을 어떻게 구성하고 하는 종류의 '겸손한 개발자'를 어떻게 부려먹으면 좋은가, 하는 부분이 주를 이루고 있습니다.

내용 전개 역시 '개떡' 책보다는 짜임새가 있는 편이긴 하지만(내용이 그렇게 겹치는게 많지는 않은데 자꾸 개떡 책과 비교하게 되는 감이 있어서 좀 죄송하네요-_-;;) , 이 책 역시 한번에 너무 많은 내용을 두리뭉실하게 풀어나가다가 두리뭉실하게 꼬인 상태로 제공하는 느낌이 있습니다.

장 끝에 잊지 말자? 였던가 아무튼 그런 타이틀로 어떤 형태의 요점 정리를 하고는 있지만, 그 정리된 내용을 보고나면, 아 그렇구나, 하는 산뜻한 생각이 들면 좋은데, 어째서? 그랬었어? 웬 급결론? 같은 느낌이 드는 항목들도 좀 있다는건 제가 독해력이 떨어져서겠지요.

뭐 그런건 아무래도 좋다고 치고, 무엇보다도 개인적으로 아쉬웠던 것은 뭔가 전에 생각지 못하던 관점을 기대하고 책을 집어 들었는데, 이쪽 분야에 관심 가진 사람이라면 한번 이상은 들어본 적은 있을 다른 책/다른 사람들이 하던 이야기의 적당한 각색 리바이벌이 대부분인 것이었다는 점이겠지요. (이런 면에서의 개발론 요점정리집[..] 같은 느낌이 들기까지 합니다-_-)

저자 분의 경험도 조금씩은 소개가 되고는 있지만, 모종의 갑 측과의 계약이라든가 때문에...이신건지 구체적인 사례 언급은 잘 안되고 있구요(독자 재밌으라고 적으셨겠지만 프로그램 배경 시원해서 조아따 같은건 아무래도 좋은데...; 그런 내용을 읽자고 책을 산게 아닌데...;).

어쩌면 이 책을 읽으신 분들 중, SI 쪽에서 근무하신 경험이 없으신 분 중에선 덜컥 겁부터 내실 분도 계실 수도 있겠다는 생각도 들었습니다. 실제 개발때 저런식으로 한단 말이야? 하고. ..
고맙습니다 경쟁자가 제거되었....

농담이구요, 사실 프로젝트 규모나 스타일이나 접근 방식에 따라 SI 업무 스타일도 모두 천차만별이기 때문에 이 책에 언급되어 있는픽션(..)은 어디선가 있을법~도한 픽션 정도로만 여기시고 겁부터 내실 필요는 없을 것 같습니다. 프리랜서 시절부터 지금에이르기까지 왜인지 모르겠지만 아직은 저는 저런 식의 설계나 기획 방식으로 프로젝트를 진행해본  적이 없는 것 같거든요. 물론짧게 치고 빠지는 소규모 프로젝트 위주로만 뛰어봤었기 때문인지 모르겠지만요.

개발 분야에만 머무르지 않고 영업이나 초기 설계 같은 부분도 적잖은 지면에 다루고 있기 때문에, 주 예상독자층인 디지탈유목민(...)들 뿐만 아니라 프로젝트를 이끌어가는 관리자 분이라면 한번쯤 읽어보실 만한 책일지도 모르겠습니다.
그렇지만 적혀 있는 대부분의 내용들이 이미 어느정도 몸으로 체득하셨을 내용일 것 같기도 합니다.; 대부분 발생하는 문제들의 원인을 모르는 것이 아닌데, 어떠어떠한 식으로 하면 개선될 것 같다는 느낌이 드는데도 쉽사리 어느날 갑자기 체제를 전환한다는 것은 사실 쉽지 않은 문제거든요.

전체적인 소프트웨어 개발 프로세스를 조망하고 해결책을 제시한다는 느낌으로 볼 때는 국내에서 보기 드문 상당히 잘 쓰여진 책일 수도 있습니다만, 제 개인적으로 읽길 원했던 내용의 비중은 상당히 낮았던 탓에(+다른 책에서 봤었던 내용들의 비중이 의외로 적지 않았기 때문에-_-) 별점은 좀 소극적으로 남겨놓겠습니다.


PS: 이 글을 두드리기 시작만 했던게 서두 언급대로 5월초 경이었습니다. 적어놓은게 아까워서 일단 올리기는 하는데; 지금 다시 책 내용을 떠올리려니 어떤 내용이었는지도 가물가물해서 내용 보충하기가 상당히 애매하네요. 이 점 고려하시고 가려 읽어주시면 감사하겠습니다.
PS 2: 저 인사이트 까 아닙니다 살려주세요.

굳이 그 유명한 나무 아래 그물침대 이미지를 붙여두지 않더라도,
다른 사람이 요구하는 것을 만드는 경우에는 언제나 각자 그리고 있는 것이 다르기 마련입니다.

게다가 일반적으로 프로그래밍...을 한다고 한다면
삽질을 하다보면 뭔가 요구서에서 있었어야 하는데 빠진 것이 보이는 경우도 있곤 하죠.
이럴 때 어떻게 해야 할지, 에 대해 생각해봅시다.

일단 베스트 선택지 세개를 준비해보았습니다.

1. 덮어두고 간다
2. 맘대로 만든다.
3. 요구명세서 작성자한테 쫓아간다.

1. 덮어두고 간다

다른 작업을 하다가도 자꾸 떠올라서 이거 해야 되는거 아닐까, 어쩌지 어쩌지 하는 뇌내 천사소녀와 악마소녀의 다툼을 구경하느라 시간 가는 줄 모르게 됩니다만, 그래도 짜는 것보다는 아무래도 ^_^?
(게다가 뇌내망상이라지만 귀여운 소녀가 둘이나 등장하니 기분도 좋고-_-)

언니야 : 어라라? 왜 이거 안되나요?
멋진나 : HA.HA.HA. 님이 준 문서에 그 내용 없었다능 ^ㅁ^
언니야 : 이런건 말 안해도 당연히 넣어야 하는 기능 아닌가요?
멋진나 : 어, 어어? 그동안 잘 테스트하고 아무 얘기도 없었잖아요...
언니야 : 으아아아앙, 이거 없으면 안된단 말예요 넣어주셈넣어주셈넣어주셈 으아아아앙ㅠㅠ
멋진나 : ... ㅠㅠ...

라는 대화 전개가 처음 넘겨줄 때는 전혀 나오지 않다가 납품 이틀 전에 나올 가능성이 .. .. .. -_-
뭐, 이틀 전에 나왔다면 그나마 다행입니다. ^ㅁ^) 당일 얘기 나오면 답이 없잖아요?


2. 맘대로 만든다

어렸을 때부터 게임기획자를 꿈꿔왔던 나, 나의 기획자로서의 적성은 과연?
을 평가받고 싶을 때 선택할 수 있는 선택지입니다.
그렇게 맘대로 구현한 결과물을 모두가 납득하면?
기획자가 쓴 요구명세서가 워낙 잘 쓰여져 있었기 때문입니다.
기획자 하난 제대로 뽑았다니깐? 사장님도 흡족해하십니다.

그런데 전혀 다른 결과물이 나와버렸다면?

언니야 : 시킨 짓이나 잘 할 것이지 쓸데 없는 짓으로 아까운 시간 낭비한 니가 머저리입니다.

라는 이야기가 나오게 됩니다.
그 이야기를 듣고 난 후에는
만든 소스 다 날리는, 그야말로 제살을 도려내는듯한 슬픔 크리가 작렬합니다.
기획자가 다시 보충한 명세서대로 다시 짜야 하는 분노 크리도 작렬합니다.
물론 이 명세서에는 작성자가 나중에 떠올린 플러스 알파의 요구사항이 가미됩니다.
안 시킨 짓 한건 크나큰 죄입니다. 가중처벌 크리도 대작렬합니다.


3. 요구명세서 작성자한테 쫓아간다

이제야 올바른 선택지를 고른 것 같습니다. 어쨌거나 쫓아가는 것이 답이었네요 ^_^

멋진나 : ~가 빠진 것 같은데 ~ 안 들어가도 되는 건가요?
언니야 : 으음... 네, 뭐 필요 없을 것 같은데요.
멋진나 : 아하 그렇구나 안 만들어도 된다 신난다~
언니야 : 멋진나 님의 멋진 프로그램, 기대할게요♡
멋진나 : HA. HA. HA. 맡겨만 주시라구요~
언니야 : 그럼 수고하세요~

이렇게 멋진나는 멋지게 언니야에게 이 기능이 과연 필요한가, 에 대한 확답을 받았습니다.
확답을 받았습니다. 확답을 받았습니다. 확답을 받았을 텐데...
지금 필요 없을 것 같은데요, 라고 했죠? 필요하게 될지도 모른다는 의미입니다. -_-
아마도 며칠 뒤 그녀는 "으아앙 필요해요 필요해요 필요해요" 하고 쫓아올 것입니다.
물론 납품 하루 전에 발견하고서 이야기하겠지요.

이 상황에서 "필요 없다고 하셨잖아요!!" 라고 항변해봤자 의미가 없습니다.
그녀는 십중팔구 '제가 언제 그랬는데요, 증거를 대세요', 라는 두툼한 오리발내밀기 스킬을 시전할 것입니다.
그와 함께 '지금 책임 소재를 따질 때가 아닙니다. 우리 함께 어서 이 문제를 헤쳐나가봐요'라고 말하며
일단 문제는 터졌지만 당신을 도와 이 시련을 극복해내겠다는 난데 없는 동료감 또한 보여줄 것입니다.
물론 문제 극복은 당신혼자 합니다.


4. 요구명세서 작성자한테 쫓아간다 ii

하우우, 그나마 구원의 길이었다고 생각했던 3번째 선택지 역시 죽음의 길이었어요, 하우우.
하지만 죽음을 반복하면서 우리는 더욱더 강해지지. 걱정 마-_-

멋진나 : ~가 빠진 것 같은데 ~ 안 들어가도 되는 건가요?
언니야 : 으음... 네, 뭐 필요 없을 것 같은데요.
멋진나 : 아하 그렇구나 안 만들어도 된다 신난다~
언니야 : 멋진나 님의 멋진 프로그램, 기대할게요♡
멋진나 : HA. HA. HA. 맡겨만 주시라구요~
언니야 : 그럼 수고하세요~

그 이야기와 함께 자리를 뜨는 언니야. 뭐, 뭐지 이 느낌은?
아...안돼, 이대로 언니야를 보내게 되면 어쩐지 좋지 못한 일이 벌어질 것만 같다. 언니야를, 언니야를 지금 붙잡지 않으면!!

멋진나 : 아직 하지 못한게 남아 있어요!!
언니야 : ㅇㅅㅇㅅㅇ? 뭐... 뭔데요?
멋진나 : 아직, 문서를 문서를 남기지 않았다구요!!

언니야 양의 엔드리스 오리발을 막을 수 있는 처절한 몸부림, 문서 내놔 스킬을 시전하는 멋진나.
언니야는 경악합니다.

언니야 : 그, 그런건 남기지 않아도 되잖아요? 그런 사소한 것까지 문서를 남겨야 하나요?!
멋진나 : 아뇨, 반드시 남겨야 합니다. 반 드 시.

세번이나 철야의 고통에 의해 잔인하게 살해당하는 경험을 해서인지,
이번에야 말로 살아남겠다는 의지가 멋진나 군의 온 몸을 강렬하게 퍼져나가고 있습니다.
눈동자를 번뜩이며 단언하는 그의 어조에 언니야도 몸을 수그려 뜨립니다. 살짝 겁을 먹었는지 금방 울음이라도 터뜨릴 것 같습니다.

언니야 : 아... 알았어요. 남기면 되잖아요.

작업용 위키를 열어 "[x월 x일 멋진나x언니야 회의] : xxx는 구현하지 않기로 함." 이라고 기록을 남깁니다.
이번에야 말로, 살아남을 수 있어요.
살아남을 수 있다구요!
는 천만에.
와타나가시의 밤에 그녀는 울먹이는 목소리로 축제 분위기를 즐기고 싶었던 당신에게 전화를 걸겁니다.
"으아앙 필요하게 됐어요, 흑 ㅇㅇ가... ㅇㅇ가 왜 그게 안 들어갔냐고... 흑... 당장 넣으라고... 흑..."
이 상황에서 필요 없다고 하셨잖아요!! 라고 항변해봤자 의미가 없습니다.
그와 함께 '지금 책임 소재를 따질 때가 아닙니다. 어서 문제를 헤쳐나가야 해요'라고 말하며
일단 문제는 터졌지만 당신을 도와 이 시련을 극복해내겠다는 난데 없는 동료감 또한 보여줄 것입니다.
물론 문제는 당신이 해결해야 합니다.
위의 엔딩 복붙편집했다는 느낌이 드신다면, 복붙한 거 맞습니다.
님 눈치 좋으시네요. 님의 눈치가 부럽습니다.


5. 추가될 것을 예상하고 여지는 남겨둔다

하우우 기록을 남기는 것도 의미가 없다면 도대체 어떻게 해야 하는 것일까요, 하우우.
옛말에 피할 수 없다면 즐기라는 말이 있잖아? ... 아무리 생각해봐도 옛말이 아닌 것 같지만 어쨌든.

프로그래머라면 당연히 갖춰야 할 덕목으로서
확장될 여지를 늘 고려해두고 설계와 코딩을 진행하라, 는 이야기를 본 적이 있습니다.
물론 일전에 필요 없다는 이야기를 듣고서 발주 전날 갑작스레 그 이야기를 듣게 됐다면
발주 전날에 삽질을 해야 하는 것은 변하지 않겠지요. 하지만 마음 가짐은 달라질 수 있을 것 같습니다.
즉, 언니야가 "그거 필요 없어요~♡"라고 이야기해준다 하더라도 절대 안심하지 않고
"네가 그렇게 말하고는 있지만 곧 그 기능이 필요하게 될거라는 것을 알고 있지, 후훗 두고봅시다."
식의 간지대사를 날려줄 수 있다는 것입니다. (물론 그렇게 말하면 정신감정 받고서 자칫하면 해고당할 수 있으니 주의-_-)

그리고 작업을 할 때 미리 그 기능이 추가될 경우에 어떻게 할지 마음의 준비를 하면서 코딩을 진행합니다.
그리고 축제의 그 날 밤이 돌아오면 울먹이는 그녀에게 싱긋 상큼한 미소를 짓고서
이미 예상했던 죽음의 전장으로 뛰어드는 겁니다.
와~~!! 어쩜 이렇게 멋질 수가!!
물론 죽는 것은 변함 없지만요. ^ㅁ^


5. 그리고...

지금 이 편지를 읽고 계실 즈음에는 저는 아마도 이 세상에 업겠지여.
부디 밝혀주시기 바랍니다. 이 사건의 진상을...
- 멋진남 올림.

프로그래밍 담당자가 기획자에게 언제나 완벽한 명세서 내놓으라고는 하고 있지만
처음부터 완벽한 요구서가 나온다는 건 사실상 불가능하다는 걸 현실적으로 인정은 하고 넘어가야겠지요.
그렇게 따지면 프로그래머 역시 완벽한 프로그램 처음부터 내놔줘야 합니다. 하지만 절대로 불가능하잖아요?
...라고 따지면 완벽한 명세서가 완벽한 프로그램 만들기보다는 난이도가 낮기는 하겠네.
...라고 얘기했더니 저 기획자 아가씨, 전체개발기간내내 명세서만 만들 기세입니다.


★ 좌담회

멋진나 : 물론 이 사건의 진짜 진상은 얼굴만 이쁘고 할 줄 아는 거 없는, ... 언니야 씨랑 발주처인 것은 잘 알고 있습니다. -_-
언니야 : 아아잉, 너무해요. 으음 만약 "어라 빠졌네, 명세서 내용 보충해 드릴게요."라는 전개였다면 이렇게 일이 심하게 틀어지지는 않았겠죠?
멋진나 : 그런데, 또 무작정 그렇게 되는 것도 곤란해요. 일전에 기껏 추가돼서 힘들게 구현해놨더니 필요 없다고 빼달라고 한 적도 있었잖아요?
언니야 : 아, 그건 그랬어요. 그거 다 만들고서 버그 잡는 것도 한참 걸렸었는데. 그걸 걷어낸다고 하니까 대통곡을 하셨었지요?
멋진나 : 그런건 부디 잊어주세요.
언니야 : 멋진나 씨 그런 모습 처음이어서 절대 잊을 수 없었어요. 사진도 찍어놨는걸?
멋진나 : ... 시간은 한정되어 있고 그 시간을 더 중요한 기능들을 작업하는데 사용할 수도 있는데, 힘들게 만든 기능을 없애는 건 정말 참담하다니까요.
언니야 : 그래요, 제가 멋진나 씨를 여러모로 힘들게 했던 것 같아요.
멋진나 : 잘 아시는군요? ... 그, 그럼 사과하는 의미에서 이번 주말 데이트 어때요?
언니야 : 아... 데... 데이트라구요? 그런 걸로 데이트 신청이라니 치사해요. 생각해볼게요... 으음, 아, 아니. 좋아요. 이제야 얘기하는 거지만 실은 저, 멋진나 씨 예전부터 좋아했는걸요.
멋진나 : 정말요?

아시발쿰.