달력

062009  이전 다음

  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  •  
  •  
  •  
  •  
어제 모임이 있었는데, 파워블로거로 소개받는 순간 민망한 생각이 들었다. 최근 몇 주 동안만 보면 파워 블로거는 둘째치고, 블로거라 할 수 있을까에 대한 의문이 들 정도다. 주장만 하지 말고, 다른 사람 이야기도 좀 듣자는 취지에서 의식해서 줄이기도 했다. 또, 여친을 비롯한 주변 사람에게 마음을 더 쓰자는 반성 탓도 있다. 하지만, 가장 큰 요인은 게으름 탓이 아닌가 싶다.

가만히 자신을 돌아보면 올라갔다 내려갔다 한다. 하루에도 여러 차례 혈압(?)이 오르락내리락한다. 몇 시간 안에도 기분이 좋아졌다가 나빠졌다 한다. 몇 년을 걸쳐서 보면 의지를 가지고 추진하던 시절이 있었고, 반대로 시류에 따라 맡은 바에 충실한 시절도 있다. 무엇이든 빠져서 열심히 할 때가 있었지만, 도피 혹은 안식을 갈구하면 가라앉던 시절도 있다.

굳이 뻔한 깨달음으로 시간과 지면을 낭비할 필요가 있나 싶지만, 2003년 처음 블로깅을 할 때부터 메모와 반성이 목적이었다. 요즘에는 자신을 내세우는 일을 거두고, 현실에 충실하자는 생각을 했다. 그러다 잘못 흘러서 표류하고 있음을 느꼈다. 깨어 있음과 순응을 대비로 놓아 행한 어리석은 짓에 대한 대가가 꽤 크다.

이제 다시 여유를 만들고, 사소한 가치라도 찾아서 존재 근거를 만들어 의지를 샘솟게 하고, 한계에 부딪혀 쓰디쓴 배움을 얻는 일상을 향해 머뭇거리지 말고 나아가야 할 때다.

Posted by 영회
근 2년 만에 노트북에서 블루 스크린을 만났다. 확신할 수는 없지만 최근 보안 프로그램 설치 이후 하루 한 번 정도는 노트북을 강제 종료하고 재부팅해야 했다. 더구나 어제는 오피스가 먹통인 현상까지 경험했다. 지난 프로젝트에서는 보안 프로그램이 비스타 지원을 하지 않아 보안 프로그램을 설치하지 않는 행운(?)을 맛보았다. 

http://weblogs.newsday.com/sports/football/bob_blog/bluescreen.png

블루 스크린... 앞으로도 종종 볼 듯하다. Safe로 시작하는 보안 프로그램 이름을 Unsafe ... 로 바꿔야 하지 않나 싶다.
Posted by 영회
화장실에 놓여있던 신문을 봤다. 보수성향 신문인데, 6월10일에 큰 충돌이 없었다고 한다. '여론을 의식해 경찰이 한 발 물러섰구나' 싶었다. 아무 일 없었다는 뉘앙스만 기어날 뿐, 구체적인 내용은 없었다. 미디어 몽구에서 아래 동영상을 보니, 신문 기사 목적이 사실 은폐가 아닌가 싶은 터무니 없는 생각이 들었다. 잠시 화장실과 이미지가 잘 들어났네 하는 엉뚱한 생각도 스쳤다.

작년에 본 명박산성이 생각났다. 폭력이라곤 찾기 힘들던 '축제'[각주:1]가 두려워 명박산성을 쌓은 모습에 기가 차던 그 날. 명박산성이 마치 타임머신인양 한 쪽에선 21세기에 걸맞는 시위 문화가 다른 한 쪽에는 반공방첩을 외치던 시절이 공존하는 듯했다. 블로그에서 '명박산성'을 검색해보니 작년에도 6월 10일이었다. 현 정부가 가져온 새로운 풍토는 유시민 전 장관이 잘 집어낸 듯 하다.

  1. 새벽에 있던 과격 시위는 명박산성이 불렀다고 해도 과언이 아니다. 당연한 요구를 하는데 폭도로 매도하는 모습은 영화에서나 보던 모습이다. 더구나, 전체 행사 모습에 비춰볼 때 본질은 아니었다. [본문으로]
Posted by 영회


via: Toby
Posted by 영회
TAG OSI
지도 교수님 권유로 학부 2학년을 대상으로 객체지향 프로그래밍 강의를 했다. 이제 두 번의 수업만 남았다. 새로운 경험이었고 여러 가지를 배웠다.

비현실적인 시간 강사 수입
소문을 들어 짐작은 했지만, 액수를 확인하니 '돈은 기대하지 않았다.'라는 생각이 100% 진실은 아님을 깨달았다. 회사나 프로젝트에 양해를 구해야 하는 탓에 우여곡절 끝에 한 학기는 맡았지만, 앞으로 다시 하기는 어려울 듯하다.

수동적인 수업 분위기
08학번이면 10년도 더 차이 나는 친구들이다. 강산은 변했지만, 수업을 받는 태도는 그대로다. 처음엔 분위기를 꽤 고무적으로 유지했다. 하지만, 오랜 습성은 쉬이 바뀌지 않았다. 시험을 통해 확인해보니 역시 일방적인 교육의 효과는 높지 않았다. 그래서, 중간고사 이후에는 발표 위주로 양방향 교육을 시도했다. 애초부터 계획한 내용이 아닌 터라 강의 진행이 좀 어수선했지만, 효과는 기대보다 좋았다.

폼 나는 주제
물론, 첫 발표 시간은 기대 이하였다. 실망한 이유는 아이들의 주제 선정 탓이다. 고작 지난 학기에 프로그래밍 언어 문법을 배우고, 이번 학기 비로소 객체, 클래스나 상속 개념을 익힌 친구들이다. 그런데 대부분 화려한 UI로 무장한 프로그램이나 보드 게임 등을 주제로 들고 나다. 일단, 시행착오 역시 배우는 과정이라 믿고 그대로 두었다. 단지 첫 발표를 마칠 즈음에 수업 초점에 대해서 덧붙여줬다. 클래스를 정의하고 균형감 있게 조직화하는 과정을 배우는 것 이외에는 모두 수업 범위 밖이라고 강조했다. 덧붙여서 (수업 시간에 배운) TDD를 통해 주어진 시간을 영리하게 쓰는 방법을 익히라고 했다.

진화 혹은 자가 개선
두 번째 시간에 효과를 확인했다. Swing을 익혀가면서 과제를 진행하던 친구가 일주일 만에 '일이 너무 커져서 수업 이후 면담을 요청한다.'라고 발표했다. 반가운 소식이었다. 공유할만한 내용인 탓에 수업 중에 모두를 향해 답해주었다. 그 친구가 정한 주제는 '소모임 정산 프로그램'이었다. 무리를 이루어 다니면서 쓰는 돈을 공평하게 정산하여 분쟁을 없애겠다는 깜찍한 발상을 실현할 프로그램이다. UI부터 작업하다 보니 수업시간에는 다루지도 않은 Swing을 써서 UI 컴포넌트를 배열하느라 고전하고 있었다. UI보다는 그 친구가 개념으로 포착한 '자원', '지출', '정산' 등을 클래스로 정의하고 역할에 맞춰서 적절하게 코드를 분배하고 효과적으로 호출하는데 초점을 맞춰보라고 충고했다. UI 버튼이 만들어내는 이벤트는 테스트 메소드 안에서 코드로 대신할 수 있다고 예를 들어서 알려주었다.

용어 남용 자제하다 얻은 보너스
다음에 발표한 학생이 작성한 코드는 더욱 구체적인 조언을 할 수 있는 기회를 주었다. testCreate() 라는 이름의 테스트 메소드 안에 최초로 작성한 두 개 클래스에 대한 테스트를 모두 담고 있었다. 이 코드에서 개선할 사항이 있느냐고 물었다. 어떻게 설명을 하면 좋을까?


만일 이제 갓 프로그래밍을 배우는 학생이 아니라 리팩터링 정도는 아는 사람을 대상으로 했다면 아마도 긴 메소드(Long Method)의 냄새가 난다고 설명했을지도 모른다. 혹은 단일책임원칙(Single Responsibility Principle)은 테스트 메소드에 대해서도 유효하다고 간편하게 설명했으려나?

배경지식이 없는 학생에게 이해할 수 있게 설명해 보려는 시도는 '이미 안다고 느꼈던 내용'에 대해 '다른 시각'으로 볼 기회를 주었다. 내 설명은 대략이랬다. 솔직히 나도 즉석에서 한 답변이라 상세한 내용은 기억 못 한다. 

"이 정도 분량이라면 심하게 부담스럽지는 않지만, 만일 코드가 매우 많다고 생각을 해보자. testCreate() 메소드 안을 보면 사용자가 입력한 데이터를 표현하는 PhoneBook 객체를 생성하는 코드(1)가 있다. 또, PhoneBook을 관리하는 PhoneBookManager 객체에 추가(2)하는 코드도 있다. 거기에 더하여 특정 값을 이용하여 다시 객체를 꺼내는 코드(3)도 있다. 코드를 작성하고 시간이 흘렀는데, 어느 날 갑자기 셋 중 일부를 고쳐야 했다.

작성하고 얼마 지나지 않았다면 금세 찾겠지만, 남이 작성한 코드이거나 자기가 작성했어도 긴 시간이 흘렀다면 찾기가 쉽지 않을 수 있다. 한 번 고생하고 나서 훗날을 위해 코드 바로 위에 친절하게 주석을 달아줄 수 있다. 그렇다고 해도 전체 코드를 훑어봐야 하는 점은 바뀌지 않는다. 그런데 만일 testCreate() 외에 다른 기능을 테스트하는 코드를 각기 testAddPhoneNumber()와 testFindByNumber() 로 구분하면 어떨까? 아무리 코드가 길어도 스크롤 할 필요 없이 이클립스에서 Ctrl+O 키를 눌러서 단박에 찾을 수 있다."

상당수 학생이 교감하는 눈치였다.

또 코드를 보면 기계적으로 ~Manager로 CRUD를 하려는 부분이 보였다. 전화번호가 아니라 전화번호부를 관리하는 프로그램을 짜려고 하는 것은 아닌 것으로 보인다고 확인해주었다. 가능하면 익숙한 개념을 빌어와야 균형 있는 클래스의 상호작용을 기대할 수 있다고 말해주었다. 이런 설명을 하는 와중에 스치고 지나간 생각이 있었다.

Posted by 영회