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



블루 스크린... 앞으로도 종종 볼 듯하다. Safe로 시작하는 보안 프로그램 이름을 Unsafe ... 로 바꿔야 하지 않나 싶다.

화장실에 놓여있던 신문을 봤다. 보수성향 신문인데, 6월10일에 큰 충돌이 없었다고 한다. '여론을 의식해 경찰이 한 발 물러섰구나' 싶었다. 아무 일 없었다는 뉘앙스만 기어날 뿐, 구체적인 내용은 없었다. 미디어 몽구에서 아래 동영상을 보니, 신문 기사 목적이 사실 은폐가 아닌가 싶은 터무니 없는 생각이 들었다. 잠시 화장실과 이미지가 잘 들어났네 하는 엉뚱한 생각도 스쳤다.

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

via: Toby

지도 교수님 권유로 학부 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를 하려는 부분이 보였다. 전화번호가 아니라 전화번호부를 관리하는 프로그램을 짜려고 하는 것은 아닌 것으로 보인다고 확인해주었다. 가능하면 익숙한 개념을 빌어와야 균형 있는 클래스의 상호작용을 기대할 수 있다고 말해주었다. 이런 설명을 하는 와중에 스치고 지나간 생각이 있었다.

서울에서는 처음으로 열릴 예정이었던 SpringSource의 공식 교육이 3월에서 5월로 연기하더니만, 결국은 결국 취소했네요.


Dr. Paul Champman은 함께 최소된 서울과 도쿄의 Core Spring 과정 강사 예정자입니다.

소름이 돋을 정도로 섬뜩하다. 나 역시 이 아이들만한 시절에 친구따라 교회에 다녔다. 교회에서 만난 어른들의 모습은 흡사 당시 군사정부와 닮아 있었다. 이유도 가르쳐주지 않고 시키고, 암기하게 하고, 강제하고 ... 대학에 갈 때까지 드문드문 교회와 인연을 이어 갔지만, '성경'에 담긴 참 의미를 배우기 위해 위선적인 얼굴과 말투를 대하는 일이 여간 거북스럽지 않았다.

교인들과 무관하게 살다가 작년에 만난 YUST의 교수님들의 모습은 놀라웠다. 전도가 금지된 중국 땅에서 그들은 진정한 선교자였다. 어찌 되었든 우리 교회도 이제 역사가 있으니 발전이 있어야 하지 않은가. 저런 회괴한 모습은 너무하다.

출처:한국 교회의 아동학대