[카테고리:] 스치는 생각들

• 파생 클래스 생성에 부담이 느껴진다면, 여전이 클래스 계층에 대한 추상화가 덜 되어 있다는 증거다.

 

• 속성 맴버 변수를 외부로 노출시키지 말고 get/set 함수를 두어 접근하도록 하는 것이, 클래스간의 독립성을 유지하는데 도움이 된다. get/set 함수를 만드는 수고로움에 대한 보상으로 말이다.

• Class Diagram의 작성은 “인터페이스의 정의”로 시작된다.

12월 6일 오전 9시 56분

 

• 데이터베이스에서 한번 정의된 스키마의 변경에 많은 소요비행이 발생한다면, 소프트웨어 개발에서는 클래스 관계도와 같은 UML 설계문서가 아닌 “전제조건”의 변경에 많은 소요비용이 발생한다. 여기서 말하는 전제조건이란, 어떤 기능을 실행하기 위해 준비되어야할 조건이다.

  11월 27일 오후 5시

   

• 두렵다. 구현 단계에서 결국은, 비록 길지는 않은 시간이지만, 짧지만도 않은 시간 동안 설계한 내용을 폐기해야할지도 모른다는 생각에…. 그래서 분석 설계는 최대한 간결하게 하라고 했나보다. “어차피 내일은 변하다”니말이다. 하지만 최소한 설계 단계가 의미있는 이유는 실제 구현단계에서 마주치게 될 위험요소를 미리 파악할 수 있다는 큰 장점이 있다는 점이다. 그래서 인지… 설계를 하면 할 수록 두렵다….

10월 4일 오전 11시 36분

• 영업인력이 고객에게 기술적으로  감동을 줄 수 있도록 개발인력은 소프트웨어를 설계하고 개발해야 한다.

9월 19일 14시 55분

 

• 예를들어, Base라는 클래스로부터 상속받은 Derived라는 클래스가 있다고 할때, Base의 생성자의 인자가 (int a, int b, int c, int d)라고 하면, Derived 클래스의 생성자도 Base의 생성자를 실행하기 위해 인자로써 (int a, int b, int c, int d)를 최소한 가져야 하는데.. 만약 Base의 생성자의 인자가 하나 추가되면 Derived의 생성자의 인자도 동일하게 추가되어야한다. 하나의 변경으로 두개 이상의 변경이 발생하는 이 문제를 해결하기 위해 Derived의 생성자의 인자로 바로 Base를 받아 해결할 수 있다.

 

• 서술식 글쓰기도 설계 방법 중의 하나.. UML과 글쓰기의 적절한 결합이 필요하다..
  9월 18일 12시 49분

   

• 어디 쓸만한 꽁짜 UML 툴없나… 지금 쓰고 있는 StarUML은 결과는 그런대로 산뜻하긴 한데, UML 스펙을 지원하지 않는게 넘 많다. 지원하는 척… 하곤 결국 완벽이 지원하지 않는 그런 모습. 언제 쓸만한 공짜 UML 툴 찾아봐야겠다.

  9월 14일 12시 57분

   

 

• 소프트웨어 설계라는 것이 유지보수와 소프트웨어의 생명주기를 길게 하는 효과는 있으나, 소프트웨어의 성능에 오히려 방해가 되는 것 같다는 생각이 든다.

  9월 13일 9시 54분

   

 

버그를 잡다가, IDE도 덩달아 죽는 모습을 보면서.. 평소에는 그냥 의식하지 않던 위의 오류보고창의 글귀를 읽어보았습니다. “품질을 향상시키는데 도움이 됩니다”. 소프트웨어의 품질에 대해 생각을 하게 만듭니다. 소프트웨어의 품질이란 무엇일까? 품질… 얼마나 안정적인가? 또 일정한 수행 속도 퍼포먼스를 제공하는가? 딱 떠오르는게 이 두가지 항목입니다…

사실 위의 창을 캡쳐하여 블로그에 올리는 이유는, 오늘 잡았는지, 잡았다고 착각을 하고 있는지 확실하지도 않은….. 버그 2개를 잡으면서였습니다. 전부터 잡아야겠다고 버르고 있던 버그였는데, 이 버그가 영향을 미치는 새로운 기능 몇가지를 추가하기에 앞서… 이 버그를 잡아야 했던 까닭였지요. 9시에 출근해서 지금까지 이 두마리의 버그에 씨름을 했는데, 사실 한마리는 그냥 쉽게 해결되었고 또 다른 한마리 때문에 고생을 했습니다. 이런 버그는 잡기가 어렵다… 걍 포기할까? 꽁수를 부려볼까? 하는 유혹이들 무렴에.. 고맙게도 IDE가 죽으면서 위의 창이 뜨더군요. 품질향상은 단박!에 되는것이 아니고… 릴리즈된 이후에도 지속적으로 사용자의 피드백을 받아 향상되어야 한다는 MS의 가르침이랄까요?

아무튼, 오늘은 기능추가 하나 없이… 달랑 버그 2마리 잡았습니다. 그것도 정말 잡았는지, 잡은 듯 보이는지.. 애매하긴 하지만 말입니다. 여튼, 결론은 “단박에 버그 잡기는 희망 사항일뿐이므로, 너무 오늘 하루에 목매지마라” 입니다. 음… 끝으로 너무 피곤합니다………

암으로 투병 중이던 성균관대 법학과 이기용(李起勇.50) 교수는 2007년 12월 5일 마지막 수업을 마친 뒤 오후 2시45분께 쓰러져 인근 병원으로 옮겨졌으나 숨졌다. 이 교수는 암 발병 사실을 알게 된 뒤에도 “강의를 모두 마치고 입원치료를 받겠다”며 수술 날짜를 종강 이후로 미뤄왔던 것으로 전해져 안타까움을 더하고 있다.

이 교수는 2개월 전 우연히 대장 내시경 검사를 받은 뒤 직장암 3기 판정을 받았지만 맡은 강의를 중단할 수 없다며 입원 치료를 거부한 채 병원을 오가며 방사선 및 항암 치료를 받았다. 그는 항암 치료를 받으며 2학기 대학원 강의와 학부 2과목 수업을 계속해 체력이 바닥난 상태에서도 성실하게 강의에 임했다. 쓰러지기 직전까지 담보물권법 마지막 강의를 마치기 위해 3시간 연속 수업을 했던 것으로 전해졌다.

또 2007년 9월 미국 카네기멜런대의 랜디 포시(47세, 컴퓨터공학) 교수는 삶이 몇 개월 남지 않았다는 시한부 판정을 받은 췌장암환자로서 마지막 강의를 해 주위를 감동시켰다. 포시는 이 날 전공 대신 인생 이야기를 중심으로 강의를 했으며, 그는 사람들이 자신들의 잠재력을 허비하고 있다며, 이를 일깨우라고 촉구했다. 그는 “어떤 성취든 이루는 과정에서 벽에 부딪히지만 벽이 있는 이유가 다 있다”며 “그 벽은 우리가 무언가를 얼마나 절실히 원하는지를 시험하는 기회”라고 말했다.

필자는 이 두 교수의 죽음에 대한 기사를 보면서 필자의 저서 <행복한 변화>에 적었던 글귀가 떠올랐다. ‘만약 내 생애 일주일을 남겨두고 있다면 나는 과연 무엇을 할 것인가?’에 대해 적어놓은 부분이 있었는데, 남은 일주일 중 이틀은 ‘내가 해오던 일’을 하고 싶다고 했다. 만약 돈벌이의 수단으로써 일을 선택했다면 도저히 불가능한 일이었을 것이다. 우리는 삶의 2/3를 일하면서 보내게 된다. 자신이 해오던 일을 하면서 죽음을 맞이할 수 있는 삶, 나는 가장 멋진 삶이라 생각한다.

만약 이런 죽음의 순간이 당신에게도 찾아온다면 과연 당신은 무엇을 하겠다고 말하겠는가?

죽음을 앞에 두고 자신이 하던 일을 계속하겠다는 사람이 과연 몇이나 될까? 자신이 하는 일에 대한 소명의식이 있지 않는 한 참으로 어려운 질문이 아닐 수 없다.

최근에 창조경영이 화두가 되면서 21세기에 가장 불쌍한 사람은 ‘근면성실하기만 한 사람이다’라는 말까지 나오고 있다. 왜냐하면 근면성실해서 되는 일들은 이제 기계가 모두 대신해주고 있기 때문이다. 무조건 참고 인내하는 방식으로는 성공할 수도 없을뿐더러 삶이 지루해진다. 지금은 20세기가 아니다. 21세기를 살아가는 우리는 일하는 게 기뻐서 날뛰어야 한다. 일 자체가 목적이 될 수 있어야 한다. 그러면 저절로 근면해지고 성실해진다. 땀에 젖게 하는 인내도 중요하지만 그보다는 즐거움에 젖게 하는 것이 먼저다.

사람은 각자에게 주어진 길이 있다. 그 길을 모른다고 외면하지 마라. 그 길이 쉽게 찾아지지 않는다고 포기하지 마라. 찾지 못하는 가장 큰 이유는 절실하게 찾지 않기 때문이다. 우리 모두에게는 자신이 생각하는 것보다 훨씬 큰 잠재능력이 있다. 이미 태어날 때부터 가지고 태어난다. 그것을 찾아내어 완성해가는 것이 삶에 대한 우리의 책임이고 임무이다.

남들이 간 길만 쫓아가지 마라. 남의 발자국을 밟으며 가는 사람들은 자신의 발자국을 남기지 못한다. 먼저 앞서간 사람들의 길을 참고삼아 당신만의 새 길을 만들어 가라. 그것이 후회 없는 참다운 인생이다.

2007/12/13 12:45에 처음 작성했고 오늘에 다시 마음에 세겨봅니다……….