1리터의 눈물(1リットルの淚)

이번에도 일본 드라마다.

(요즘 일본어 공부도 할겸 일본 드라마 보는데 재미를 들였다-_-

일본어 공부를 좀 하고 나니까 예전 보다는 문장이 잘 들리긴 하는데…

여전히 간단한 문장외에는 잘 안 들린다-_-;)

불치병에 걸린 15세 소녀가 10년간의 투병생활 동안 쓴 일기를 출판한 책을

원작으로 한 드라마이고, 영화로도 제작이 되었다고 한다.

주인공이 걸린 병은 ‘척수 소뇌 변성증’ 이라는 건데…

척수와 소뇌의 신경세포가 서서히 사라지면서 점점 걸을 수도 없게 되고,

말도 하기 힘들어 지고, 몸을 움직이기가 점점 힘들어 지다가

결국에는 거의 움직이지도 못하고, 말도 못하고, 누워만 있게 되는 병이란다.

거기다 면역력이 약해져서 작은 병에도 쉽게 죽을 수 있고,

정신은 말짱하기 때문에 자기 마음대로 몸을 움직이지 못한다는걸

아~주 잘 자각할 수 있어서 정신적 고통도 장난이 아니다.

결정적으로 원인도 모르고, 치료법도 없어서 한 번 걸리면

서서히 몸이 말을 듣지 않게 되는걸 손 놓고 볼 수 밖에 없다.

생각만 해도 끔찍한 병이 아닐 수 없다.

(주인공의 말처럼 하루하루가 지날수록 오늘 할 수 있던 무언가를

내일 할 수 없게 된다는 두려움에 내일이 온다는게 두려워 지는 병이다.)

이제 절반 정도 봤는데… 주인공이 자신의 병을 알게 되고,

현실을 받아 들이고 인정하게 되는 과정에서 많은 것을 잃고, 포기하는 걸 보면서..

‘살면서 저런 일은 안 겪어야 할 텐데..’

라는 생각이 들었다. 역시 이 드라마를 본 사람들이 다들 하는 말 처럼

‘건강한게 최고다’; 라는걸 느낄 수 있다.

이제 드라마에서 남은 부분에서는 아마 주인공의 병이 점점 더 심해지면서

주인공과 가족들이 겪게 되는 고통이 더 부각 될꺼 같은데…

마냥 슬픈 내용은 아니었으면 좋겠다.

나머지 감상은 다 보고 난 다음에~

개발과정에서 사용자의 적극적인 참여

개발 과정 중에 사용자가 얼마나 적극적으로 참여하는냐는 아주 중요하다.

특히 SI의 경우 그 특성상, 사용자의 요구가 충분히 반영되지 않은 채

시스템이 구축되면 문제는 심각해진다.

개발된 프로그램이 처한 운명은 두 가지 중 하나가 될수 밖에 없다.

창고 속에 처박히거나, 대대적으로 수정되거나…

산업기능요원 시절에  참여했던 모 프로젝트는 후자의 경우였다.

(최종적으론 전자의 운명을 맞긴 했지만… 기획상의 미스랄까.. 그런거였다..)

온갖 고생을 하면서 간신히 만들어 놓은 시스템이

준공이 다되서 ‘못쓰겠다’ 라는 판정을 받았다-_-

그래도 프로젝트를 실패로 만들수는 없는지라…

검수 완료 후 수정을 하겠다는 약속을 하고 무사히 검수를 받았다.

그리고… 서브 시스템 하나가 전면적으로 ‘재개발’ 되었다.

무슨 낙후 지역 재개발 하는 것도 아니고..-_-;

그 후에 PM 한 분이 그 프로젝트와 관련해서 해주신 말씀이 있었는데,

‘사용자를 개발 초기 부터 끌어 들여서 적극적으로 참여하게 해야 한다’

는 거였다.

그 이전에 다른 프로젝트가 있었는데, 개발 과정에서 실사용자가

별 다른 관여를 안 하다가 실제 사용 하면서 계속 해서 요구 사항을

쏟아 내는 바람에 유지보수 하느라 무지하게 고생했던 적도 있었다.

그래서 옳은 말이라고 생각했는데…

사용자가 너무 적극적으로 참여하는 것도 문제인거 같다-_-;

물론, 사용자가 만족할 프로그램을 만드는게 최우선이다.

(열심히 만들었는데 아무도 사용하지 않는건 참으로 씁슬한 일이다.)

사용자는 물론이고 개발자도 만족할 수 있는 프로그램,

필수적인 기능은 물론이고, 온갖 편의 기능으로 장식되어 있는 프로그램을

만들어야 하는 것이다.

그러나 그건, 시간이 무한정있고 그와 함께 돈을 무한정 받을 수 있을 때 얘기다-_-

돈은 쪼금 받고, 일은 무진장 많이 해야 되는 상황은 그야 말로 피해야 될 상황이다.

그런데, 사용자가 너무 적극적으로 나오면, 그렇게 될 수 밖에 없다.

이번에는 최근에 했던 다른 프로젝트를 예로 들어 보자.

이 프로젝트는 정말 고난의 연속이었는데…

수 많은 원인이 있었지만, 그 원인 중의 하나는 지날칠 정도록 적극적인 사용자였다.

프로젝트 초기 부터 제안서는 무시한 요구 사항이 계속 되었고,

중반에 접어들면서 부분적으로 프로그램을 쓸수 있게 되자

그에 대한 온갖 수정 사항, 추가 개발 요구 등이 쏟아 졌다.

심지어는 다 만들어 놓은 기능을 보고, 이렇게 하면 안된다라고 하기도 하고…

(이미 요구사항 분석 단계에서 확실히 말해 줬어야 할 내용도 다수 포함되있다)

이런게 더 필요하다… 이건 이렇게 저렇게 고쳐라… 이 기능은 빼라.. 아니다 다시 넣어라,

다른 X 프로젝트에서는 이렇게 했더라, 우리도 이렇게 하자… 등등

프로젝트가 후반으로 접어들고 막바지가 되서 까지…

그 적극적(?)인 요구는 그칠줄을 몰랐다.

이럴땐 정말이지… 나중에 프로그램이 쓰이든 말든…

사용자는 좀 잠자코 얌전히 있어 줬으면 하는 바램뿐이다.

====

이제는 정말이지 개발중에 사용자가 적극적으로 참여하는게 좋으냐 아니냐는

판단하기 어려운 문제가 되버렸다-_-

무엇이든 적당히가 좋긴 한데… 그게 쉽지가 않으니 문제다…

전차남(電車男)

간단히 얘기하면 한 오타쿠가 네티즌들의

도움을 받아 퀸카를 꼬시는 이야기랄까..-_-

원작은 실화를 바탕으로한 소설이고,

만화에, 드라마 영화까지 나왔대니까…

일본에서도 꽤 인기가 있었는지도…

암튼 여기저기서 종종 ‘전차남’에 대한 얘기가 보이길래

한번 다운 받아서 봤는데, 꽤 재밌는 드라마였다.

종종 감동스럽기도 하고… 웃기기도 하고..

주인공 외에 조연들의 사이드 스토리도 꽤 많이 나오는데…

(카즈야는 진지한 역인줄 알았는데 끝까지 코믹 캐릭터고-_-)

자잘한 즐거움을 많이 준거 같다.

주인공은 처음에 나올때 보면 딱! 오타쿠 같은 외모에 맨날 질질 짜고…-_-

여자 앞에서 말도 심하게 더듬고….

내가 봐도 한 대 때려 주고 싶은 녀석인데…

여자 주인공 땜에 스스로를 바꾼 탓도 있지만…

드라마 후반으로 가면 꽤 귀여운 구석도 있어 보인다-_-

이 드라마의 또 한가지 볼거리는 오타쿠들의 생활인데..

(물론 과장된 면도 있겠지만) 이 드라마를 보면 일본 오타쿠들의

생활을 엿볼수도 있고,

일본의 일반적인 사람들이 오타쿠를 어떻게 생각하는 지도 알수 있다

(들리는 얘기로는 애니 얘기만 해도 오타쿠 취급에, 오타쿠는 기피 대상이라나..)

보다가 문득든 생각인데…

지난 번 우리나라 드라마에서도 비슷한 상황의 주인공이 나오는 드라마를 한적이 있다

(우리나라 드라마의 경우 오타쿠는 아니고, 못생기고 가난하고,

볼품없는 설정의 주인공이 아나운서랑 결혼에 골인하는 이야기였다)

이들의 하나 같은 특징은 어리한듯하면서도 생각도 깊고 말도 잘한다는 것이다

(물론 매우 더듬기도 하지만-_-)

몇 마디 말로 사람의 마음을 돌려 버리는 재주들이 있달까…

역시 사람은 말빨이 좋아야 한다는.. 이상한 결론을 내면서…;;;

감상은 여기까지…

Borland C++ Builder

윈도우 세계에서는 마이크로소프트 사의 Visual C++ 과 쌍벽을 이루는 C++ 개발툴이다

(사실 윈도우에는 그외에 C++ 개발툴이 잘 없기도 하지-_-;)

난 MS를 썩 좋아하지 않으면서도 그와는 별개로 윈도우에서 개발할때는

주로 MS의 개발툴들을 써왔는데…

D시의 B 프로젝트를 하면 처음으로 C++ Builder 6.0 이라는 놈을 써보게 됐다.

첫 인상은.. 글쎄… 그닥 나쁘지 않았다. C++을 쓰면서도 4GL 처럼

쉽게 프로그램을 개발할 수 있는 개발툴이니… VB와 C++의 장점을

합쳐 놓은 듯한 느낌이었다. 더군다나, 고유의 VCL 컴포넌트 뿐만 아니라

ActiveX 컴포넌트도 가져다 쓸수 있고, 델파이 같은 다른 언어로 만든

컴포넌트도 끌어다 쓸 수 있고… 암튼 쓸만한 툴이구나 했다.

그. 러. 나.

계속해서 쓰다보니 점차 짜증이 났다.-_-

가장 문제가 되는건 툴이 너무 무거웠다. 예전에 J Builder도 굉장히

무거웠던 기억이 있는데… 이놈도 마찬가지 였다.

개발하던 프로그램 덩치가 좀 커진 탓도 있겠지만…

풀 컴파일을 하려면 10 여분은 족히 걸리고…

개발한 프로그램을 디버거로 실행하고 종료하는 데도 몇분씩 걸린다.

VB로 더 덩치가 큰 프로그램을 돌릴때 보다도 더 느린거 같았다.

이 땜에 개발 시간이 몇 배는 소요되니… 이건 정말 치명적이다;;

당최 예상했던 일정을 맞출수가 없다-_-;

더군다나.. 디버깅을 하다보면 지 혼자 자꾸 죽는다. 툴자체가 말이다.

어떨때는 디버거가 꺼지지도 않는다-_-; 또, 어떨때는 디버거를 띄워도

break point에서 멈추지를 않는다… 이럴땐 리부팅을 해주면 다시 잘된다-_-

또, 4GL 스럽다 보니… 별도의 런타임 환경이 필요하다. RTL이던가…

VB의 VB 런타임에 대응되는 넘인데… C++ Builder의 경우에는 프로그램에

static 하게 링크 할수도 있다.(대신 파일 크기는 좀 더 커진다. 속도는… 잘 모르겠다.)

좀 불편한것 중에 하나는 VC++이나 기타 다른 IDE에서 처럼 프로젝트 설정을 여러개로

둘수가 없다는 것이다. debug용 release용을 구분해 둘 수가 없으니,

릴리즈 할때 설정 바꿔서 새로 컴파일하고, 디버깅할때 설정 바꿔서 새로 컴파일 하고…

정말 귀찮다..-_-(거기다 DLL 여러개로 쪼개나서 일일이 바꿀려면 더 귀찮다-_-)

마지막으로… 결정적으로 내가 이 툴을 싫어하게 된 이유는…

순수 C++이 아니라는 것이다! managed C++이라는 이름으로 C++이 C++이 아니게

만들어 놓은 MS에 치를 떨었었는데… 이넘은 그 보다 앞서 C++을 지멋대로 바꿔놨다.

(나중에 알고 보니 C++ Builder 만들었던 개발자가 MS로 가서 .NET을 만들었드만-_-)

(물론… 이건 그냥 개인적인 취향이고, 개인적인 생각이다-_-)

찾아보면 더 있겠지만… 내가 직접 확인한건…

폼의 이벤트 핸들러가 생성자 보다도 먼저 호출 될수도 있다는것.

(만들어 놓은 폼을 상속한 폼의 경우 이렇다)

도대체 어떻게 객체를 만들지도 않고 이벤트 핸들러를 호출 한단 말인가!

또 한가지는 pure virtual function을 가진 클래스의 객체가

인스턴스화 될수 있다는거다. 대신 해당 function을 호출하면 런타임 에러가 난다-_-

쩝… 아무튼…

C++ Builder를 신봉하시는 분들께는 대단히 죄송한 말씀이지만…

내 개인적인 생각으로는… 좀 ‘아니다’ 싶은 툴이다. 다음 프로젝트 부터는 회피대상-_-

볼랜드에서 개발툴 사업부를 매각한다는 얘기도 있고, 개발퉁에서 손뗀다는 얘기도

있었던거 같은데… 얼마전에 보니 새로운 버전이 나오긴 했던데… 좀 괜찮을 라나 모르겠다.