아래 글은 2006년 3월 24일에 내가 토필드 입사 후, 1달 남짓 지난 후 쓴 글이다.
블로그를 옮기면서 남기고 싶은 글을 옮겼다.
이제 토필드를 떠날 생각을 하고 있는데..
1년 5개월동안 아래 내용과 같은 고민을 매일 반복한 것 같다.
--------------------------------------------------------
회사 입사한지 한달 정도 지났다.
두어달 전부터 '조엘 온 소프트웨어'와 '실용주의 프로그래머'를 읽으면서
공감을 많이 하게 되었다.
회사에서 소스코드를 볼땐 더 심하게 위의 두 책의 내용에 공감하며 심취하게 되었다.
책을 읽으면서, 진짜 현실적으로 우리회사의 소프트웨어 개발의 예기를 하는구나..
라는 생각을 하게 되었다.
여기서 우리회사의 소프트웨어에 대해 잠깐 예기를 하자면,
너무 오래전 부터 많은 사람의 손을 거쳐 수정되어 덩치가 많이 커졌다.
(그러게 큰것도 아니지만, c파일 약 300개...헤더파일빼고..)
1. 전역변수가 엄청나게 많고, 객체지향의 개념도 없다.(c언어이긴 해도 흉내나 개념정도라도..)
무엇 하나를 수정하면, 어디서 side-effect가 날지도 모른다.
2. 주석이 전혀 없다. 그래서 요구사항 하나 들어오면, 그때 그때 소스를 다 뒤져서 최대한 다른 부분에 피해가 가지 않을 만큼 조심스러운 코드를 끼워 넣는다.
그래서 #ifdef #else #endif 이와 같은 프리프로세서 매크로 들이 엄청나게 많다.
이러게 하다보니 더 알아보기 힘든 코드가 점점 늘어난다.
그러나 이런 상황에서도 사람들은 계속 주석을 달지 않는다.
3. 위와 같은 문제점으로 영업쪽의 간단한 요구사항도 대응하기가 만만치가 않다.
이런 식으로 하다간, 경쟁사에서 신제품, 신기술을 출시해도, 우리는 끙끙 앓고 있어야 할 때가 올 것같다.
일예를 하나 들어보겠다.
입사 몇일 후, 영업쪽에서 날라온 버그 수정 요구사항이였다.
요구사항은, 우리 프로그램에서, 락걸린 파일(삭제하면안되는 파일)이 들어 있는 폴더를 삭제 하려고 하면 그냥 삭제가 된다는 것이다.
그래서 락걸린 파일이 들어 있는 폴더를 삭제 불가능 하게 만들어 달라는 것이였다.
나는 한 1~2시간이면 수정할 수 있을것이라 예상했다.
내가 생각한 해결법은 폴더 하위를 depth-first search 형태로 recursive하게 돌면서 락걸린 파일이 존재하면 폴더를 삭제하지 못하게 하는 것이다.
아주 간단한 해법이며, 내 생각에 더이상 의심의 여지가 없었다.
소스를 봤는데, 주석이 하나도 없고, 변수명도 뭔지 잘 모르겠고, 전역변수를 너무 많이 쓰고있어서 많은 어려움이 있다.
시간도 많이 걸리고, 어렵게 코드를 짜서 디버깅을 했다..
역시 생각한대로 동작하지 않았다.
그래서, 코드를 보니 기본적인 파일을 순차적으로 순환하는 함수, 디렉토리를 자식 디렉토리로 들어가는 함수 등이 전역변수를 공유하고 있어서 recursive 콜을 할 수 없는 형태로 작성되어있었다.
정말 난감하고 답답한 일이다.
주석이 하나도 없어서, 변수의 역할, 쓰임을 알 수가 없다.
그리고 하위 레벨의 함수 API가 있는데, 문서 조차 정확하지 않아 내가 볼 수도 없으며, 해결할 수도 없는 부분이다.
벽에 부닥치고 말았다.
도저히 recursive 콜을 할 수가 없었다. 그래서 그냥 아래와 같은 해결책으로 코드를 작성했다.
'삭제하려는 폴더 밑에 락파일이 있거나 자식폴더가 있다면 삭제를 함부로 못하도록 한다.'
별로 일관성이 없고, 직관적이지 못한 방법이다.
알면서도 위와 같이 해결했다.
더이상 소스코드를 이해 할 수가 없었다. 또한, 만약 가능하더라도 시간을 그러게 투자하고 싶지 않았다.
또한 recursive call을 하기엔, 함수의 수행 속도 또한 너무 느렸다.
위와 같은 절차를 겪는데 거의 하루가 걸렸다. 주석만 있고, 문서화만 제대로 되어 있어도, 훨씬 좋은 코드를 작성 할 수 있었을 것이다.
위의 예를 보아도, 분명 소스코드 레벨의 문제가 있다.
만약 API가 JAVA API의 Tree의 인터페이스 처럼 직관적으로 되어있었다면 이런 문제는 없었을 것이다.
외부로 노출되고, 재사용 가능성이 있는 함수는 그 prototype이 직관적이고 명확해야 한다.
매번 개발자들이 새로 입사하면, 교육도 없이 주석 없는 소스를 보면서 많은 시간을 낭비하고, 이와 같은 효율성 떨어지는 일들을 하고 있다.
이와 같은 인적 자원과 시간을 낭비하지 않아야 회사가 성공한다.
--------------------------------------------------------
그리고 몇일 후, 빌드해서 품질관리팀에 넘기는 것을 보자.
7개의 모델의 펌웨어를 품질관리 팀에 넘기는데, 왜 그런 많은 절차를 수작업으로 하는지 이해가 되지 않았다.
빌드 해서, 릴리즈 했다는 것을 남기는 폴더로 옮겨서, 날짜로 명명된 폴더를 만든 다음, 로더버전, 날짜, 펌웨어 버전 등을 섞어서 파일명을 만들어, 압축을 해서 그룹웨어를 이용한 전자결제를 한다.
나는 이날 7개 중에 2개는 실수를 했다. 하나는 파일명에 로더버전을 잘못 작성한 실수와, 또 하나는 다른 파일을 압축해서 보내는 실수를 범했다.
이건 일일빌드와 빌드 자동화가 있으면, 실수할 염려도 없으며 없어도 되는 절차다.
그런데 위의 작업을 하는데 몇시간을 소비했다. 그것도 실수와 함께....
--------------------------------------------------------
그래서 나는 위와 같은 두 경험을 하고, 회사에서 시간을 보내면서 이 회사가 잘 될 수 있는 방향을 생각했다.
조엘 온 소프트웨어에도 나와 있듯이, 네스케이프 웹 브라우저의 개발자 처럼 소스코드를 처음부터 새로 작성하는 오류를 범하지 않기 위해 이 소스를 계속 사용하는 방향의 해결책을 생각했다.
그래서 첫번째 문제를 해결하기 위해 doxygen을 이용하여 지금부터라도 주석을 달 것을 생각했고,
두번째 문제를 해결하기 위해서 한번에 빌드를 만들어 내는 시스템과, 일일 빌드를 생각했다.
doxygen은 한 일년은 개발자들이 함께 힘을 모아야 자료로 사용할 만큼 효용가치가 될 것이며,
두번째 문제는 누군가 하루정도 고생해서 쉘 스크립트를 작성하면 되고 백만원짜리 PC를 구입해서 빌드 서버(cron을 이용해서 매일 cvs에서 check-out해온 다음, 파일의 변화 검사 후, 릴리즈 파일을 폴더별로 정리)로 사용하면 된다. 요즘에 하드 싸고 큰데, 한 일년치 빌드 파일은 무리없이 보관 할 수 있지 않을까..생각한다.
밤 12시 정도에 check-out하고, 변화가 있다면 필요에 따라, doxygen을 이용한 새로운 문서 작업을 수행한다.
그리고 소프트웨어 개발자 전원이 하나의 cvs를 사용하고 doxygen을 이용하여 주석을 이용한 자동화 문서 도구를 사용을 하면 좀더 리펙토링과 구조적인 소프트웨어를 개발하는데 도움을 줄 것이다.
그리고 빌드서버(PC)에 모델 디렉토리 별로, 릴리즈 날짜와 버전 별로 릴리즈 파일을 매일매일 밤시간을 이용하여 자동으로 생성해 낸다면 개발자는 몇시간 동안 수작업을 하는 대신에 소스코드를 더 볼수 있는 여유를 누릴 수 있게 된다.
또한, 확실한 히스토리를 볼 수도 있다. 빌드 결과의 오류 발생시, 개발자들에게 전체 메일을 발송하게 하면, 더 훌륭한 시스템이 될 수 있지 않을까..
그래서 오늘은, 저녁먹고 회사에 들어와서 우리회사의 소프트웨어가 이런식으로 가면 안되겠다는 생각에 (요즘 항상 하는 생각임), Makefile을 만드는 작업, 쉘 프로그래밍을 이용한 자동화 에 대한 자료를 찾고, doxygen의 사용법을 익히는 등 작업을 하고있었다.
그런데, 쿵..ㅡㅡ;
연구소장님께서 오셔서, 갑자기 내 모니터를 보고 계셨다.
한참을, 내가 뭐 하고있는지 보시다가..
'이런 쓸때 없는거 하지말고, 소스코드나 봐라..'
'리눅스 좀 한다고, 이런거 하지 마라..'
'이제 아웃풋 낼때 되지 않았나? 얼른 소스보고 일해라 일!~'
난참,, 당황스럽고, 황당한 일이 아닐 수 없었다.
소스 보고있으면 일하고 있는줄 안다.
뭐 그냥 보기엔 많은 사람들이 다들 그러게 생각한다.
물론 이런 편견엔 나 또한 예외는 아니다.
정말,, 이런 현실이 한심스럽다.
난 객체지향 프로그래밍과 일다운 일을 하고싶다.(C언어 탓을 하는게 아니라 개념만으로도..)
이 회사는 전혀 그러지 못하다. 그런데 걱정은 다른데 가도 다 마찬가지 아닐까 하는 생각이다.
내가 연구소장을 하지 않는 이상, 내 생각대로 운영되는 회사는 찾기 힘들지도 모른다.
나는 소프트웨어의 개발 생산성과 업무 효율성을 중시한다.
그리고 나는 하루빨리 팀장, 연구소장이 되고 싶다.
희망사항일 뿐, 까마득히 먼 미래의 예기다.
이런 내 고민을 누가 알아줄까..??
휴,, 나 진짜 프로그래머고, 전산인이고, 개발자 인가보다 -_-;
더 하고싶은 예기는 많지만,, 휴, 그만해야지..
오늘 혼자 이 글을 쓰면서, 혼자 맥주 두캔을 마셨다.
답답해서.....