'궁시렁'에 해당되는 글 7건
- 2009.11.19 티스토리 검색 기능 유감
- 2009.10.21 개발자의 정체성 (포팅 엔지니어라구?) 4
- 2009.10.19 설계하기 적당한 작업규모 2
- 2009.10.15 과제가 끝나고 난 뒤 3
- 2009.10.14 설계하는 이유
- 2009.07.10 S/W 용역 사업에 대한 단상 (2) 3
- 2009.07.06 S/W 용역 사업에 대한 단상 (1) 2
내 블로그를 소개하면서 '웹킷 포팅 엔지니어가 정리한 웹킷 관련 블로그' 라고 소개한 표현을 봤다. 포팅 엔지니어라구? 이런... 쯧...
기분이 과히 좋지는 않다.
왜냐하면 '종합 예술인'이라는 홍서범의 싼티나는 표현의 표절이지만, 난 스스로를 '종합 개발인'이라고 표현하고 싶기 때문이다. 난 나의 영역을 '포팅'에 한정하고 싶지 않다.
비슷한 맥락에서 나는 '코더'라는 지칭을 극히 혐오한다.
'코딩'은 개발의 아주 미미한 부분이기 때문이다. S/W 개발자는 년차가 낮건 높건 '코더' 따위로 부르거나 불려서는 안된다. 개발은 분석, 설계, 구현, 테스트가 망라되는 종합 예술 분야다. 개발자는 그 모든 것을 책임져야 한다.
개발 현장에서 항상 반복되는 대화가 있다.
'이번 일, 설계부터 탄탄히 해봅시다.' 라고 말 하면, 매번
'이번 일은 일정이 급하니 다음 일부터 그렇게 하면 좋겠습니다.' 라는 답변이 돌아온다.
항상 일의 규모가 설계하기에는 너무 간단하고,
항상 일의 일정이 설계하기에는 너무 다급하다고 한다.
만약 진정으로 S/W 설계의 효용성에 대해 관심을 갖고 있다면,
한번 두눈 질끈 감고 설계를 제대로 하면서 작업해보라고 권하고 싶다.
설계하고 문서를 남기기에 너무 작은 규모는 없다.
설계하고 문서를 남기기에 너무 촉박한 일정도 없다.
두눈 질끈 감고 현재 맡겨진 일을 차근히 설계하고 차근히 문서를 남기며 작업해보라.
일이 잘못되는 최악의 경우, 현재 직장에서 짤리기 밖에 더하겠는가?
필자에게 얘기하라. 그래서 짤렸다면 기꺼이 모셔오겠다.
설계를 먼저하고,
필요한 문서를 먼저 만든 다음
(흔히 많은 사람들이 개발의 전부라고 오해하는) 코딩을 진행하면
생각보다 훨씬 수월하게, 더 빨리, 더구나 탄탄하게, 작업이 완료되는 것을 경험할 수 있을 것이다.
갑의 요구와 을의 입장을 조율하는 것, 개발진의 책임과 사기를 조율하는 것, 회사 업무와 가정의 평화를 조율하는 것, 어느 것 하나 만만한 일이 없다. 모두 도를 닦는 것만큼이나 어려운 일이다. 이땅에서 고생하는 모든 S/W 개발자들에게 행운 있기를...
설계하는 이유는 디버깅하지 않기 위해서다. 개발 현장에서는 디버깅 잘하는 사람에게 권력이 부여되곤 한다. 마감이 촉박한 시즌에 영웅이 되기 때문이다. 하지만 진정한 영웅은 설계를 통해 버그의 원인을 원천적으로 봉쇄하는 사람이다. 설계하는 이유는 디버깅 전쟁을 치르지 않고 평화롭게 개발을 마무리 하기 위해서다.
용역 사업을 통해 양질의 결과물이 나올 수 없는 이유가 하나 더 있다. 용역 사업이 시작될 때, 용역을 발주하는 "갑"이 자기가 바라는 결과물의 모습을 모른다는 것이다. 일을 시키는 "갑"과 일을 진행하는 "을"이 서로 다른 이미지를 머릿속에 넣고 일을 진행한다. 대개 과제 마감이 가까와서야 갑은 갑대로, 을은 을대로 결과물의 모습을 어렴풋이 그리기 시작한다. 그럴 경우 양질의 결과물은 언제 나올 수 있을까?
S/W 개발 방법론이란 분야는 10 년 넘게 결과물이 쌓여온 완성된 학문이다. 갑이든 을이든 RUP, XP, SCRUM 등등의 방법론을 한번쯤 공부하고 업무에 임하면 어떨까 생각해본다. 한국의 S/W 산업도 10 년 넘게 무르익은 산업인데 왜 맨날 이모양인가? 가끔 S/W 업계에 종사하는 사람들이 무식하다는 생각이 들 때가 있다. 지식이 없어 무식하다고 하는게 아니다. 자기가 모른다는 사실을 모르기에 무식하다고 하는 것이다. 모른다는 사실을 깨달아야 공부할 것 아닌가?
어째... 단상 시리즈를 이어나가면 내게 불이익이 닥칠 것 같은 소심한 걱정이 스친다. (3)을 이을지 말지 고민해봐야겠다.