Rev. 2.73

"야! 이 녀석들아 하라고 하면 할 것이지! 건방진 놈들..."

이런 학교는 더 이상 다닐만한 가치가 없다. 절차를 밟아 대화를 통한 내부적 문제로 조용히 풀어가려 했건만 돌아온 것은 교수의 폭언을 앞세운 무력화와, 억지뿐...

참고로 본인은 지방에 있는 w대학에 재학 중이며 전공은 '환경조각'이다. 수업진행 방식이 주로 완성된 하나의 작품을 만드는 것이라. 일부 건축 장비와 자제, 화학약품처리, 유해물질(석면) 등을 다루고, 자신의 작품에 필요하다면 위험을 마다하고 작품에 열정을 쏟는다.

졸업전시를 앞두고 나날이 바쁜 스케줄에 쫓기던 어느날(04년 8월 30일) 정규 수업을 마친 후 느닷없이 학과 전체회의가 있었다. 나에게는 직접 연락도 오지 않았고, 다른 학우를 통해 귀뜸으로 알기는 했지만 일정에 따른 중요한 작업(작품 만들기)으로 인해 회의에 참석 하지 못했다. 근심이 가득한 얼굴로 돌아온 동급생이 전해주기를... '졸업하지 못하게 생겼다'고 했다.

엉뚱하게도 대대적인 학과 정비를 해야 한다는 것이다. 방학기간도 학기말도 아닌 한창 학업생활에 열중해야 할 이 시기에 말이다. 회의내용을 정리해보면 아래와 같다.

1. 일주간 전공실 폐쇄
2. 진행중이던 작업(작품 만들기) 또한 일주간 중지
3. 일주간 순수 학과 학생의 노동력으로 전공실 정비

전달하는 과정에서 잘못된 점 :
1. 사전 공지가 없었음
2. 강제성을 띰
3. 학생들의 교양과목 시간표 갹출

왜!
학과를 폐쇄하면서 까지,
학과전체 학생들의 인력을 착취하면서 까지,
교양수업을 모두 공결처리 하면서까지
진행해야 하는가?
학과장 : '환경개선'

그렇다면, 꼭 이렇게 무리하게 진행해야 하는 이유는 무었인가?
학기말이나 학기 시작 전에 진행 할 수는 없었는가?
학과장 : '없었다'

알고 보니 중국 로신 대학에서 중요한 손님(?)이 찾아오기로 되어 있다고 한다. 이게 말이나 되는 소린가? 사립학교에서 비싼 등록금(약 300만원)을 내고 학교 청소나 하고 있으라니, 이를 어찌 받아 들여야 하는가? 당일 저녁 학생회장 및 4학년들은 긴급 대책회의를 열어 요구안을 마련하였다.

1. 폐쇄기간동안 학생측 불이익 대안마련
2. 정비시에 일어날 수 있는 안전사고 및 홰손 대안마련
3. 학생 반대 서명운동

이외에도 여러 부당한 내용을 밝히는 언급들이 있었으나, 불분명한 관계로 생략한다.

그리고 다음날 아침 9시, 학과 전체 학생들이 집합하여 정비작업에 착수하고자 학과장이 브리핑 중이었다. 모인 학생들은 서명하느라 정신이 없었고 학과장에게 거의 천체가 서명한 서명부와 위 요구안을 바로 전달 하였다. 이때부터 재미있는 사건이 전개된다.

학과장 : 불가피 하다. 너희들이 이해하고 따라와라.

위 요구안은 완전 묵살되고 있을 즈음 다른 이강x교수가 불쑥 나타서 학생에게 뭔가 잘못이라도 한 듯한 말투로 언성을 높여 추긍하기 시작했다. ‘태도가 불손하다’, ‘정신머리가 썩었다’, ‘이기주의자다’, '보험들어줄까?' 라는 인격모독을 미친개처럼 침을 튀어가며 한치의 주저도 없이 망언들을 내뱉었다.(이 과정에서 나는 이강x 교수에게 단도직입적으로 모독을 당한바 있다.) 도저히 말이 통하지 않을 것 같은 분노에 휩싸여 있었기에 학생들은 묵살해야만 했다. 그리고 이강x교수는 한분야의 전공과목 교수이다. 그이상도 그이하도 아니다.

교수라는 사람이 학과 모든학생들 앞에서 학생들에게 모욕을 주는 추태를 보인 것이다. 덩달아 학과장도 힘을 얻었는지 학생들을 다구치기 시작했다. 이렇게 억지식으로 내려진 결과는 다음과 같다.

1. 교양과목에는 들어가도 좋다.
2. 일주간 폐쇄 및 정비에는 변화가 없다.
3. 정비하는 기간동안 출석하지 않을 학생은 않해도 좋다.

정비기간에 출석 채크는 왜 하는 것인가?
불이익을 주겠다는 것인가? 더럽다....
학점을 무기로한 횅포 아닌가?

학교를 그만 두어야겠다.
더이상 저런 인간들에게 소중한 교육비를 낭비하고 싶지 않다.

Comments

256288.jpg

주소 : http://annlee.co.tv/
주제 : 미술 / 신앙 / 사람 / 이야기
내용 : 2004.05월 ~ (약 300개의 포스트)
리뷰 : 주로 미술에 관한 포스팅을 다룬 블로그이다. 전시회, 미술에 관한 여러 감상문과 정보 그리고 작품들을 주로 다룬다. 작가별, 갤러리별로 묶음지은 포스트 하나하나에 정성이 배어 있음을 한눈에 알 수 있다. 성경과 관련된 여러 이야기나 미술작품들 또한 적지 않다. 그녀의 세계에서 바라본 영화, 책, 미술작품 등의 이야기는 보는이를 사로잡는 매력을 가지고 있다.

블로그 이곳저곳을 방문하다 보면 혼자보기 아까울 정도로 정성이 들어있고 일괄된 포스팅으로 운영되는 블로그들이 있다. 내가 다녀본 훌륭한 블로그들을 '북마크 블로그'라는 제목으로 매주 1곳 이상 소개하는 포스트를 마련했다.

Comments

소프트웨어 개발팀을 운영하게 되면 여러가지 타입의 개발자들을 만나게 되는데 크게 두가지로 나눌 수 있었다.

한 부류의 개발자는, 개발자 자신의 창의성과 문제접근방식의 존중을 요구하고, 최소한의 간섭하에서 작업하는 것을 요구한다. 그들은 문제 자체의 요구사항에 대해서만 제시받기를 원하고, 문제의 구체적인 해결방법에 대해서는 요구받는 것을 꺼려한다. 왜냐하면 자기 자신의 디자인, 코딩 스타일이 있는데도 불구하고 다른 사람의 스타일에 맞춰서 작업하는 것은 부자연스럽고 비효율적이라고 생각하기 때문이다.

다른 부류의 개발자는 보다 적극적인 커뮤니케이션을 통해 문제의 요구사항과 해결방식 둘 다에 대해서 요구를 받아들이고, 다시 피드백한다. 자신의 스타일이 요구받은 스타일과 다르다고 판단하면 문제제기와 토론을 통해 타협선을 만들어낸다. 또한 세세한 요구사항을 간섭으로 여기지 않고 여러가지 방안의 선택의 폭을 넓히는 것으로 받아들인다.

필자가 같이 작업하면서 겪은 개발자중 첫번째 부류 (간섭을 싫어하는) 의 개발자들은 대부분 자발적으로 회사를 떠났다. 그들은 자신에게 필요한 것은 팀장으로서의 위치 또는 그에 상응하는 역할 (간섭을 받지 않을 수 있는) 을 원하고 자신의 스타일대로 작업을 해서 효율적으로 작업을 하는 것이라고 말했다. 팀 작업에 있어서 과연 어디까지 프로그래머에게 '자율'이 주어져야 하고, '간섭'을 받지 않아야 할 것인가?

필자가 그동안의 경험과 성과를 바탕으로 판단한 결론은, 이미 떠난 사람들에겐 섭섭한 말이 될지 모르겠지만, 팀작업 내에서 간섭을 받기 싫어하고, 자신이 원하는 스타일대로만 작업하려는 작업자는, 농구팀이나 축구팀에서 각자 자기가 알아서 공을 잡아서 플레이를 하겠다고 주장하는 것과 크게 다르지 않다. 아무리 베컴이나 지단이라고 할 지라도, 경기장에서 다른 팀원이나 감독의 간섭없이 자율적으로 공만 쫓아가서 차는 플레이를 해서는 절대 팀을 승리로 이끌 수 없다. 오히려 진정한 프로이기 때문에 이 감독과 팀을 할 에?이 감독의 스타일에 맞추고, 저 감독과 팀을 할 때에는 저 감독의 스타일에 맞추어야 하는 것이다. 물론 그것은 감독이 플레이어의 재능과 스타일에 맞는 포지션과 작전을 구상하여야 하겠지만 말이다.

올바른 팀웍의 힘은 팀원 개개인의 힘의 합보다 크다. 최고수준의 소프트웨어를 만들어내는 팀들은 특정 개인의 실력이나 스타일에 의존해서 만드는 경우는 드물다. 간혹 보는 사람중에는 소프트웨어 엔지니어링의 지혜를 무시하고 자기 스타일로 아는대로 짜는 것을 최선으로 여기는 개발자들도 있다. 그런 개발자들은 대부분 혼자서 작업하는 경우가 많다. 최소한 4-5 명이 한 팀이 되어 개발하고, 상당수준이상의 규모를 지녔으며 꾸준히 업데이트 되고 있는 소프트웨어는 서로간의 커뮤니케이션을 '간섭'으로 여기고 혼자 '자율적'으로 작업하기 좋아하는 사람들이 모여서 만들어질 수 없는 것이다.

전자에 속하는 개발자들은 작업을 디자인 할 때, 일을 기능단위로 나누기보다는 사람단위로 나눈다. 그 결과는 중복과 낭비의 초래이다. a 개발자가 만든 기능을 b 개발자가 비슷한걸 또 만드는 일이 흔하게 일어난다. 서로 어느정도까지 기능을 공유할지에 대한 큰 그림을 그리지 못했기 때문이다. 또한 사람단위의 작업분담은 작업량 부하의 불균등을 초래한다. a 개발자가 b 개발자보다 중요하고 더 시간이 걸리는 작업을 부담하게 되더라도 b 개발자는 a 개발자를 도와줄 방법이 없다. 따라서 a 개발자가 작업의 병목현상을 초래한다.

기능단위의 업무분담은 그런 문제들에 대해 더 잘 대처할 수 있는 능력을 만들어 준다.
서로 최소한의 간섭을 하면서 자율적으로 짠 사람들의 프로그램이 얼마나 적극적으로 재사용되고, 일반화되어 다른 요구사항에도 쉽게 적응하고 있는지, 얼마나 많은 규모의 팀원들이 유기적으로 일하고 best practice 가 축적되고 있는지 본다면 시간이 지날 수록, 팀이 커질 수록, 기술의 변화가 심해질 수록 차이가 드러날 것으로 확신한다.

진정한 발전을 꿈꾸는 프로그래머들이라면, 자신이 짜고 있는 코드만 보지 말고, 다른 사람이 짜고 있는 코드를 함께 살펴보고 더 개선점은 없는가 토의하는 습관을 들여보기 바란다.

- 김학규 님의 홈피에서 퍼온걸 창아님의 홈피에서 퍼옴

공감하는 글이다. 링크블로그로 만족하지 못해 완전히 퍼오고 말았다.(RSS Feed는 하지 않았다.) 개발자 뿐만아니라 개발을 추종(?)하는 모든 인력에 해당하는 공통된 내용인것 같다.

Comments