언젠가부터 티스토리 블로그의 검색 기능에 문제가 생겼다. 
블로그 페이지에 있는 검색창을 통해 검색어를 치면, 제목이 일치하는 글만 찾아 준다. 
검색어가 본문에 포함된 글은 찾아내지 못한다. 
블로그를 개인 컨텐츠 아카이브로 사용하려던 내 입장에서는 치명적인 장애다. 
다른 블로그 서비스로 이전할지. 티스토리 블로그를 유지할지... 고민이다.
그래도 꽤 정든 구석이 있기 때문이다.
Posted by ingeeC
,
여기저기 웹서핑하고 다니다가,
내 블로그를 소개하면서 '웹킷 포팅 엔지니어가 정리한 웹킷 관련 블로그' 라고 소개한 표현을 봤다. 포팅 엔지니어라구? 이런... 쯧...

기분이 과히 좋지는 않다.
왜냐하면 '종합 예술인'이라는 홍서범의 싼티나는 표현의 표절이지만, 난 스스로를 '종합 개발인'이라고 표현하고 싶기 때문이다. 난 나의 영역을 '포팅'에 한정하고 싶지 않다.

비슷한 맥락에서 나는 '코더'라는 지칭을 극히 혐오한다.
'코딩'은 개발의 아주 미미한 부분이기 때문이다. S/W 개발자는 년차가 낮건 높건 '코더' 따위로 부르거나 불려서는 안된다. 개발은 분석, 설계, 구현, 테스트가 망라되는 종합 예술 분야다. 개발자는 그 모든 것을 책임져야 한다.


Posted by ingeeC
,

개발 현장에서 항상 반복되는 대화가 있다.
'이번 일, 설계부터 탄탄히 해봅시다.' 라고 말 하면, 매번
'이번 일은 일정이 급하니 다음 일부터 그렇게 하면 좋겠습니다.' 라는 답변이 돌아온다.
항상 일의 규모가 설계하기에는 너무 간단하고,
항상 일의 일정이 설계하기에는 너무 다급하다고 한다.

만약 진정으로 S/W 설계의 효용성에 대해 관심을 갖고 있다면,
한번 두눈 질끈 감고 설계를 제대로 하면서 작업해보라고 권하고 싶다.
설계하고 문서를 남기기에 너무 작은 규모는 없다.
설계하고 문서를 남기기에 너무 촉박한 일정도 없다.

두눈 질끈 감고 현재 맡겨진 일을 차근히 설계하고 차근히 문서를 남기며 작업해보라.
일이 잘못되는 최악의 경우, 현재 직장에서 짤리기 밖에 더하겠는가?
필자에게 얘기하라. 그래서 짤렸다면 기꺼이 모셔오겠다.

설계를 먼저하고,
필요한 문서를 먼저 만든 다음
(흔히 많은 사람들이 개발의 전부라고 오해하는) 코딩을 진행하면
생각보다 훨씬 수월하게, 더 빨리, 더구나 탄탄하게, 작업이 완료되는 것을 경험할 수 있을 것이다.

Posted by ingeeC
,
힘들었던 용역 과제 하나가 정리단계에 들어섰다. 평일이고 주말이고 힘을 다해 매달렸던 일이라, 끝나고 나면 마냥 편하고 좋을 줄만 알았는데, 그렇지가 않다. 전투 후, 황량한 풍경만 남아있다. 게다가 이런... 계절마저 가을이다. 황량함의 제곱이다.

갑의 요구와 을의 입장을 조율하는 것, 개발진의 책임과 사기를 조율하는 것, 회사 업무와 가정의 평화를 조율하는 것, 어느 것 하나 만만한 일이 없다. 모두 도를 닦는 것만큼이나 어려운 일이다. 이땅에서 고생하는 모든 S/W 개발자들에게 행운 있기를...
Posted by ingeeC
,

설계하는 이유

궁시렁 2009. 10. 14. 09:07

설계하는 이유는 디버깅하지 않기 위해서다. 개발 현장에서는 디버깅 잘하는 사람에게 권력이 부여되곤 한다. 마감이 촉박한 시즌에 영웅이 되기 때문이다. 하지만 진정한 영웅은 설계를 통해 버그의 원인을 원천적으로 봉쇄하는 사람이다. 설계하는 이유는 디버깅 전쟁을 치르지 않고 평화롭게 개발을 마무리 하기 위해서다.

Posted by ingeeC
,
용역 사업은 돈을 주고 일을 시키는 측과 돈을 받고 일을 하는 측 사이에 간격이 있을 수 밖에 없다. 문제는 두 당사자가 일을 바라 보는 관점이 오로지 경제 논리 뿐인 경우다. 일을 시키는 측은 가능한 돈을 적게 주고 많은 일을 시키는 것을 최고선으로 여기고, 일을 하는 측은 정해진 계약 금액을 받으면서 가능한 적게 일하는 것을 최고선으로 삼는다. 그럴 경우 양질의 결과물은 누가 만들 수 있을까?

용역 사업을 통해 양질의 결과물이 나올 수 없는 이유가 하나 더 있다. 용역 사업이 시작될 때, 용역을 발주하는 "갑"이 자기가 바라는 결과물의 모습을 모른다는 것이다. 일을 시키는 "갑"과 일을 진행하는 "을"이 서로 다른 이미지를 머릿속에 넣고 일을 진행한다. 대개 과제 마감이 가까와서야 갑은 갑대로, 을은 을대로 결과물의 모습을 어렴풋이 그리기 시작한다. 그럴 경우 양질의 결과물은 언제 나올 수 있을까?

S/W 개발 방법론이란 분야는 10 년 넘게 결과물이 쌓여온 완성된 학문이다. 갑이든 을이든 RUP, XP, SCRUM 등등의 방법론을 한번쯤 공부하고 업무에 임하면 어떨까 생각해본다. 한국의 S/W 산업도 10 년 넘게 무르익은 산업인데 왜 맨날 이모양인가? 가끔 S/W 업계에 종사하는 사람들이 무식하다는 생각이 들 때가 있다. 지식이 없어 무식하다고 하는게 아니다. 자기가 모른다는 사실을 모르기에 무식하다고 하는 것이다. 모른다는 사실을 깨달아야 공부할 것 아닌가?

어째... 단상 시리즈를 이어나가면 내게 불이익이 닥칠 것 같은 소심한 걱정이 스친다. (3)을 이을지 말지 고민해봐야겠다.
Posted by ingeeC
,
대한민국에서 S/W를 업으로 삼고 있는 회사들은 대부분 용역사업으로 생계를 꾸린다. 나는 어떤 S/W 결과물을 내놓을 때마다 그것을 내 자식이라고 생각한다. 내 자식이 어디 가서 똘똘하다는 이야기를 들어야 부모된 마음이 편하다. 대부분의 부모는 자기 자식이 똘똘해질 때까지 무한 애정을 쏟을 용의를 갖는다. 사실 애 하나 키우는 일이 쉬운 일이 아니다. 세상에 나가서 자기 몫을 충분히 하는 인재를 키워내려면 무척 많은 시간 동안 정성을 쏟아야 한다. 그런데, 용역 사업은 말하자면 자식을 낳아서 다른 곳에 입양시키는 사업이다. 게다가 제대로 키울 틈도 없이 낳자마자 입양시키는 사업이다. 용역이 끝나면 용역 결과물에 대한 모든 권리를 용역 발주처가 갖는다. S/W 개발자 입장에서 보면 무척 슬픈 사업 방식이다. 대한민국 S/W 사업 생태계가 질적으로 도약하려면 이런 사업 방식이 바뀌어야 한다. 할말이 무척 많아서 제목에 '(1)'을 달았다. 또 다른 생각이 정리되면 '(2)'를 달아서 글을 올려야겠다.
Posted by ingeeC
,