3탄 오픈 소스와 품질
개발의 기수 :
2007. 9. 10. 16:30
얼마전 서점에 들러 오픈 소스에 관한 책을 찾아봤다.
프로그램 경력이 벌써 9년이 되었는데
부끄럽게도 오픈 소스가 뭔지 잘 모른다 -_-;
오픈 소스가 왜 생겼는지,
개발자들은 오픈 소스 개발에 왜 동참을 하는지...
기업 입장에서는 오픈 소스 소프트웨어가 왜 돈이 되는지...
뭐 궁금한게 많아서 웹을 뒤져보다가,
잘 정리된 책이 더 낫겠다 싶어 서점엘 갔는데 볼만한 오픈 소스책은 찾기 어려웠다.
원서 코너로 가서 구한 책이
"Perspectives on Free and Open Source Software"였다.
어느 개발자나 그렇겠지만
본인도 항상 진로를 고민한다.
당분간 회사를 옮길 생각은 없지만,
더 재미있는 주제와 더 나은 개발 환경이 주어진다면
못 옮길 이유 또한 없지 않나 생각한다.
더 재미있는 주제를 생각한다면
오픈 소스에 관심이 가기 마련이다.
오픈 소스 커뮤니티엔 다양한 주제의 프로젝트가 올라와 있고,
프로그래머가 자유로이 프로젝트에 동참할 수 있다는 점에서
"돈이 되는 프로그램만을 개발하는" 상업 소프트웨어 개발 환경과
가장 다른 점이 아닌가 한다.
개발자들이 오픈소스에 동참하는 첫번째 이유가
저 책에서 조사한바에 따르면 "enjoyment"라 했다.
창의적 유희는 분명 프로그래머들을 움직일 수 있는 첫번째 이유인 것이다.
상업용 소프트웨어 개발에 몸담은 개발자라면,
재미보단 회사의 비전, 연봉, 근무조건 등에 더 많은 비중을 둘 것이다.
"돈이 수십억씩 많다면..."이라는 가정은 술자리에서의 단골 주제이다.
친구들은 대부분 여행다니며 살거나 빌딩 사놓고 취미활동으로 여생을 보내겠다는
의견과 함께 오픈 소스 동참 의사를 밝혔다.
다들 한가닥하는 프로그래밍 실력을 지닌 친구들이다.
본인도 수십억까지가 아니더라도,
직장없이도 먹고살 여유가 된다면 미련없이 오픈소스의 세계로 뛰어들 것 같다.
강호의 실력가들의 리뷰를 받으며
재미난 프로젝트들을 찾아 모험을 떠나는 삶이야말로
개발자의 로망이 아니겠는가...
...
로망...
꿈 같은 얘기다.
오늘도 본인은 다음달에 넣을 펀드 자금을 마련하기 위해
릴리즈를 위한 valgrind 버그 패치 작업에 매진중이시다 ㅠㅠ
자...오픈소스에 대한 로망을 잠시 끄집어 냈긴했지만
오늘 글의 주제는 오픈 소스의 로망이 아니다.
개발자의 입장이 아닌 사용자의 입장에서
오픈 소스 소프트웨어 VS 상용 소프트웨어를 고민해보면
과연 미래가 오픈 소스가 대세가 될지에 대해서는...
"글쎄..."이다.
당장 본인도 리눅스 보단 윈도우 플랫폼을 더 좋아한다.
무엇보다도, 빠른 디스플레이 스피트, 미려한 폰트, 대중성, 안정성 등...
리눅스에 아무리 정 붙여볼래도 코딩 작업 외라면
밉지만 MS가 낫다-_-
오픈 소스 소프트웨어가 상용 소프트웨어를 따라올 수 없는 부분이
바로 '품질' 아닌가 싶다.
수많은 개발자가 버그 패치 작업을 한다지만,
돈이 아닌 '기호'에 근거한 참여엔 '재미없는 품질 관리'의 요소를 충족시키기가
근본적으로 힘들지 않을까 생각된다.
그만큼 재미없는 일엔 '돈'이라는 보상이 enjoyment를 대체해줘야 하기 때문이다.
당장 알티베이스 개발을 보더라도 그 논리는 증명된다.
분명 DBMS는 개발자가 느껴볼 수 있는 재미있는 주제임에는 틀림없다.
그렇다고 알티베이스 개발자가 항상 재미있는 일만 하는건 분명 아니다.
비율로 따지자면 재미있는 일 30%, 재미없는 일 70%쯤 되지 않을까...
뭐 개인별로 다 다르겠지만...
재미없는 일엔 품질 관리가 대부분이다.
(성과 평가를 위한 근거 자료 마련에도 비중이 크다)
3분이면 잡을 버그를,
브랜치별 소스에 커밋하랴, 커밋 전에 리뷰하랴,
버그 리포팅 하랴, 기술 지원팀에 피드백하랴...
스케쥴 관리하랴, 주간 진도 보고를 위해 리포트 작성하랴...
온갖 잡일들이 따른다.
과연 이런 귀찮은 작업들을 오픈 소스 소프트웨어 세상에선
어떻게 관리되고 있는지 궁금하다.
개발자의 입장에선 다소 귀찮은 작업일 지라도,
상업용 소프트웨어라면 당연히 밟아야 할 절차이다.
그런 노력 하나하나가 바로 품질의 밑거름이 되기 때문이란 걸 알기에...
우린 정성껏 단순 사무일에 가까운 작업들도 기꺼이 신경을 쓴다.
(그만큼 creative한 에너지를 발산해야 할 뇌세포들이
단순 쳇바퀴일로 지쳐갈 때면 또다시 10억 대박꿈이 꿔지게 마련이다.
...본인은 재미있는 회사 생활을 위해 연구 기간을 마련하자...고
몇번 주장을 했지만,
구현해야할 수많은 기능들의 스케쥴 압박에 묵살되고 만다..ㅠ 에혀~~
에고..자꾸 이야기가 딴 길로 새는데...
뭐 개발자의 욕심이 슬그머니 고개를 빼꼼히 내는데...
걍 푸념으로 봐주십사~~ 간청하는 바이고...)
말하고자하는 바는,
품질의 저변에 깔린 개발자들의 노력, 회사의 노력, 프로세스는
오픈 소스에 대항할 수 있는 상업 소프트웨어의 가장 큰 강점이 아닐까 한다는 점이다.
IBM이나 SUN사에서 자사의 하드웨어를 판매하기 위해
오픈 소스 전략을 구사한다는 얘기를 조엘 온 소프트웨어에서 읽은 적이 있다.
기업의 손을 떠난 소프트웨어가 경쟁력있는 품질을 갖추기 위해서
오픈 소스 진형은 어떤 전략을 구사할까?
단순히 자발적인 노력에 맡긴다면 오픈 소스 소프트웨어는
상용 소프트웨어를 이길 수 없을 게 분명한데 말이다.
이에 대해서는 본인이 오픈 소스에 대해 좀 더 공부해보고 다시 정리를 해야겠다.
그러면 이제
우리 알티베이스에서 품질이라는 요소를 위해 어떤 오리발질을 하는지 소개해보련다.
< 철저한 사용자의 관점 >
개발자들은 자신의 주관을 굽혀야 한다.
새로운 기능을 추가할 때, 조금 자존심 상하지만 사용자가 새로 배우는 불편을 없애기 위해
많이 팔리고 있는 DBMS의 인터페이스를 따라갈 때가 많다.
이 때문에 새로운 프로젝트를 하기에 앞서 경쟁사 제품 분석을 survey 작업으로
스케쥴에 포함시키는 관행은 어느덧 문화가 되어버렸다.
코딩을 해본 사람이라면 누구든 exception 단락에 현재 상황을 표현하는 에러 메시지를
출력하도록 해본 경험이 있을 것이다.
하지만 이런 개발자 중심의 에러 메시지는
사용자에게 실제적으로 거의 도움이 되질 않는다.
에러 코드 하나 추가할 때마다 그 에러를 내는 테스트 케이스를 작성해
그 테스트 케이스의 상황을 가장 잘 이해할 수 있는 에러 메시지를 작성한다.
코딩에서 exception 처리는 주 논리 줄기를 벗어난, 아주 희박한 가능성의
경우를 대비한 코드이기 때문에 신경이 덜 가지만,
DBMS에서는 그런 에러 상황 하나하나가 기술 지원 작업 10시간을 줄일 수도 있기에
exception 코드 작성에 몇 시간을 할애한다.
(사실 이런 관행이 몸에 베인 단계까진 아니고, 이런 움직임을 전파하는 단계이다.)
< 널 못믿어...그 아무도 믿지마... >
알티베이스에서 소스 커밋 사고를 가장 많이 일으키는 사람은
신입사원이 아니라, 팀장님 또는 본부장님이시다. (ㅋㅋ)
물론 경험이나 실력은 회사내에서 탑이겠지만
사람이란 실수를 하기 마련이거늘, 리뷰 절차를 생략한게 화근인 것이다.
그런 내력이 쌓인 지금은 그 누구도 리뷰없이 커밋을 못한다.
리뷰는 참 힘든 작업이다.
오전에만 커밋할 수 있도록 제도화 되어 있기에
오전에 수정을 마치면 점심전에 리뷰를 마쳐야 한다.
오전엔 너나할 것 없이 정신없이 바쁘다.
아무리 바빠도 리뷰 요청은 어김없이 찾아오고, 인터럽트에 의한 작업 전환 비용을
감수해야 한다.
그렇다고 리뷰를 대충할 수 있느냐...
한 사람이 모든 걸 알수는 없기에 또 다른 시각으로 코드를 보다보면
버그가 나오기 마련이거나, 심지어 심각한 로직의 오류도 발견된다.
리뷰 시간엔 진정한 딴지의 시간이 된다.
< 안정성, 안정성, 그리고 안정성... >
알티베이스 개발에 삽질중의 넘버원...
바로 전 테스트 케이스 수행이다.
아무리 사소한 소스 수정도 5시간짜리 모듈 테스트
또는 24시간짜리 전체 테스트 케이스
수행을 통과해야 한다.
버터 플라이 효과는 밀림의 나비에서만 생기는게 아니다.
내가 바꾼 플래그 하나가 select 실행 계획 변화로 1000% 성능 저하를
초래할 수도 있는 것이 DBMS 소스의 세상이다.
요정도는 괜찮겠지...하고 커밋한 소스는
분명 문제를 발생시키고 전 개발자들의 작업에 영향을 끼치거나,
혹은 문제가 고객에게까지 가서 큰 사고를 일으키는 경우가 있기에
1분 수정, 24시간 테스트도 허다하다.
고객은 사소한 문제 하나 수정하는데 뭔 하루씩이나 걸리냐 하겠지만,
알티베이스에선 아무리 사소한 문제도 아무리 빨라야 1일이 걸리고,
대부분 3일 이상은 걸린다고 봐야 한다.
< 플랫폼 독립적인 소프트웨어 개발의 애환 >
한 제품이 여러 플랫폼을 지원한다는 사실엔
정말 각고의 삽질, 오리발질 노력이 있었다는 사실을 인정해줘야 한다.
알티베이스에 입사한 초보 개발자들은 누구나 한번씩 하는 실수가 있다.
if (aNode != NULL && aNode->id == sValue)
누가봐도 문제가 없을 것 같지만
이렇게 작성한 개발자는 리뷰시간에 처절하게 빠꾸(?)를 맞게 된다.
if (aNode != NULL)
{
if (aNode->id == sValue) ...
...
}
물론 C 언어 스팩엔 && 연산자가 반드시 왼쪽부터 evaluation한다는 게 명시되어 있지만
안타깝게도 모든 플랫폼의 C 컴파일러가 이 스팩을 준수하지 않는다는 사실을
알티베이스는 경험적으로 알게 되었다.
컴파일 옵티마이징 과정에서 순서가 뒤바뀔 수도 있어
이런 사소한 구문이 NULL 포인터 참조에 의한 시스템 다운이라는 치명적인
상황을 초래할 수 있기에 보기에 싫지만 이중 if문으로 작성해야 한다.
(플랫폼은 모바일 환경도 포함한다.)
사용자들은 단지 테스트를 위해서 특이한 플랫폼 환경의 패키지를 요구한다.
가령 Suse Linux의 gcc 4.2.10에서 돌아가는 패키지를 요구한다면
프로젝트로 정신없는 와중에도
저런 급한 패키지 요청이 들어오면 프로젝트는 올 스탑되고
Suse linux를 구해 gcc부터 설치해야 한다.
그리고 대부분 한번에 빌드되는 일이 없다.
컴파일러 버그도 많으며 (의외로 옵티마이져 레벨을 높이면 예상치못한 버그가 발생되는 경우가 있다.)
운영체제마다 라이브러리나 쉘의 동작이 틀려 문제가 발생하는 경우가 많다.
패키징을 맡은 개발자들은 문제에 부딫힐 때마다 구글이나 동료 직원들에게
물어가며 문제들을 해결해 나가야 한다.
한참 복구 알고리즘을 디자인하다가도 'tail -3' 구문이 플랫폼 마다 틀리게 동작하는
문제를 심각히 고민해야 한다.
오픈 소스 프로그래머가 과연 그 고민을 '재미삼아' 해줄 지...의문이다.
< 기록은 기억을 지배한다 >
메멘토의 주인공은 단기 기억 상실이라는 희귀병에 대항해
온몸에 기록을 남긴다.
이건...결코 남의 일이 아니다.
우리 뇌는 기억을 오래 가지고 가지 못하고 더우기
정확하지도 않다.
우리가 하는 모든 작업 내역은 리포팅한다.
버그 리포트, 프로젝트 리포트, 패키지 리포트, 고객 문제 해결 리포트...
이것에도 저것에도 분류 하기 힘들면 task 리포트라는 것도 있다.
모든 작업을 할 때마다 리포팅이 수반되고
해결된 문제 하나하나가 내력이 쌓여 방대한 데이터베이스가 된다.
직원은 언제든지 퇴사할 수가 있기 때문에
한 직원이 퇴사해도 문제가 되지 않으려면 그 사람이 작업한 내역은
모두 기록되어야 한다.
혹은 심지어 자기가 1년전에 한 작업 내역이 지금의 작업에 절실할 때도 있다.
소스 수정 한줄을 설명하기 위해 10줄의 설명을 기술하는 것도
다 품질을 위한 노력에 포함된다.
이처럼 품질을 위해서는 보이지 않는 노력이 필요하고
그 노력이 몸에 체화되기까지, 문화가 되기까지 많은 시간이 걸리며
기업과 직원 사이 계약의 원천인 '돈' 없이 가능할지에 대해 의문을 가져봤다.
뭐 어찌되었건,
미래 소프트웨어 산업에서 오픈 소스의 행보는 어떻게 바뀌어 갈지
관심을 가지고 지켜볼 주제임에는 틀림없다.
프로그램 경력이 벌써 9년이 되었는데
부끄럽게도 오픈 소스가 뭔지 잘 모른다 -_-;
오픈 소스가 왜 생겼는지,
개발자들은 오픈 소스 개발에 왜 동참을 하는지...
기업 입장에서는 오픈 소스 소프트웨어가 왜 돈이 되는지...
뭐 궁금한게 많아서 웹을 뒤져보다가,
잘 정리된 책이 더 낫겠다 싶어 서점엘 갔는데 볼만한 오픈 소스책은 찾기 어려웠다.
원서 코너로 가서 구한 책이
"Perspectives on Free and Open Source Software"였다.
어느 개발자나 그렇겠지만
본인도 항상 진로를 고민한다.
당분간 회사를 옮길 생각은 없지만,
더 재미있는 주제와 더 나은 개발 환경이 주어진다면
못 옮길 이유 또한 없지 않나 생각한다.
더 재미있는 주제를 생각한다면
오픈 소스에 관심이 가기 마련이다.
오픈 소스 커뮤니티엔 다양한 주제의 프로젝트가 올라와 있고,
프로그래머가 자유로이 프로젝트에 동참할 수 있다는 점에서
"돈이 되는 프로그램만을 개발하는" 상업 소프트웨어 개발 환경과
가장 다른 점이 아닌가 한다.
개발자들이 오픈소스에 동참하는 첫번째 이유가
저 책에서 조사한바에 따르면 "enjoyment"라 했다.
창의적 유희는 분명 프로그래머들을 움직일 수 있는 첫번째 이유인 것이다.
상업용 소프트웨어 개발에 몸담은 개발자라면,
재미보단 회사의 비전, 연봉, 근무조건 등에 더 많은 비중을 둘 것이다.
"돈이 수십억씩 많다면..."이라는 가정은 술자리에서의 단골 주제이다.
친구들은 대부분 여행다니며 살거나 빌딩 사놓고 취미활동으로 여생을 보내겠다는
의견과 함께 오픈 소스 동참 의사를 밝혔다.
다들 한가닥하는 프로그래밍 실력을 지닌 친구들이다.
본인도 수십억까지가 아니더라도,
직장없이도 먹고살 여유가 된다면 미련없이 오픈소스의 세계로 뛰어들 것 같다.
강호의 실력가들의 리뷰를 받으며
재미난 프로젝트들을 찾아 모험을 떠나는 삶이야말로
개발자의 로망이 아니겠는가...
...
로망...
꿈 같은 얘기다.
오늘도 본인은 다음달에 넣을 펀드 자금을 마련하기 위해
릴리즈를 위한 valgrind 버그 패치 작업에 매진중이시다 ㅠㅠ
자...오픈소스에 대한 로망을 잠시 끄집어 냈긴했지만
오늘 글의 주제는 오픈 소스의 로망이 아니다.
개발자의 입장이 아닌 사용자의 입장에서
오픈 소스 소프트웨어 VS 상용 소프트웨어를 고민해보면
과연 미래가 오픈 소스가 대세가 될지에 대해서는...
"글쎄..."이다.
당장 본인도 리눅스 보단 윈도우 플랫폼을 더 좋아한다.
무엇보다도, 빠른 디스플레이 스피트, 미려한 폰트, 대중성, 안정성 등...
리눅스에 아무리 정 붙여볼래도 코딩 작업 외라면
밉지만 MS가 낫다-_-
오픈 소스 소프트웨어가 상용 소프트웨어를 따라올 수 없는 부분이
바로 '품질' 아닌가 싶다.
수많은 개발자가 버그 패치 작업을 한다지만,
돈이 아닌 '기호'에 근거한 참여엔 '재미없는 품질 관리'의 요소를 충족시키기가
근본적으로 힘들지 않을까 생각된다.
그만큼 재미없는 일엔 '돈'이라는 보상이 enjoyment를 대체해줘야 하기 때문이다.
당장 알티베이스 개발을 보더라도 그 논리는 증명된다.
분명 DBMS는 개발자가 느껴볼 수 있는 재미있는 주제임에는 틀림없다.
그렇다고 알티베이스 개발자가 항상 재미있는 일만 하는건 분명 아니다.
비율로 따지자면 재미있는 일 30%, 재미없는 일 70%쯤 되지 않을까...
뭐 개인별로 다 다르겠지만...
재미없는 일엔 품질 관리가 대부분이다.
(성과 평가를 위한 근거 자료 마련에도 비중이 크다)
3분이면 잡을 버그를,
브랜치별 소스에 커밋하랴, 커밋 전에 리뷰하랴,
버그 리포팅 하랴, 기술 지원팀에 피드백하랴...
스케쥴 관리하랴, 주간 진도 보고를 위해 리포트 작성하랴...
온갖 잡일들이 따른다.
과연 이런 귀찮은 작업들을 오픈 소스 소프트웨어 세상에선
어떻게 관리되고 있는지 궁금하다.
개발자의 입장에선 다소 귀찮은 작업일 지라도,
상업용 소프트웨어라면 당연히 밟아야 할 절차이다.
그런 노력 하나하나가 바로 품질의 밑거름이 되기 때문이란 걸 알기에...
우린 정성껏 단순 사무일에 가까운 작업들도 기꺼이 신경을 쓴다.
(그만큼 creative한 에너지를 발산해야 할 뇌세포들이
단순 쳇바퀴일로 지쳐갈 때면 또다시 10억 대박꿈이 꿔지게 마련이다.
...본인은 재미있는 회사 생활을 위해 연구 기간을 마련하자...고
몇번 주장을 했지만,
구현해야할 수많은 기능들의 스케쥴 압박에 묵살되고 만다..ㅠ 에혀~~
에고..자꾸 이야기가 딴 길로 새는데...
뭐 개발자의 욕심이 슬그머니 고개를 빼꼼히 내는데...
걍 푸념으로 봐주십사~~ 간청하는 바이고...)
말하고자하는 바는,
품질의 저변에 깔린 개발자들의 노력, 회사의 노력, 프로세스는
오픈 소스에 대항할 수 있는 상업 소프트웨어의 가장 큰 강점이 아닐까 한다는 점이다.
IBM이나 SUN사에서 자사의 하드웨어를 판매하기 위해
오픈 소스 전략을 구사한다는 얘기를 조엘 온 소프트웨어에서 읽은 적이 있다.
기업의 손을 떠난 소프트웨어가 경쟁력있는 품질을 갖추기 위해서
오픈 소스 진형은 어떤 전략을 구사할까?
단순히 자발적인 노력에 맡긴다면 오픈 소스 소프트웨어는
상용 소프트웨어를 이길 수 없을 게 분명한데 말이다.
이에 대해서는 본인이 오픈 소스에 대해 좀 더 공부해보고 다시 정리를 해야겠다.
그러면 이제
우리 알티베이스에서 품질이라는 요소를 위해 어떤 오리발질을 하는지 소개해보련다.
< 철저한 사용자의 관점 >
개발자들은 자신의 주관을 굽혀야 한다.
새로운 기능을 추가할 때, 조금 자존심 상하지만 사용자가 새로 배우는 불편을 없애기 위해
많이 팔리고 있는 DBMS의 인터페이스를 따라갈 때가 많다.
이 때문에 새로운 프로젝트를 하기에 앞서 경쟁사 제품 분석을 survey 작업으로
스케쥴에 포함시키는 관행은 어느덧 문화가 되어버렸다.
코딩을 해본 사람이라면 누구든 exception 단락에 현재 상황을 표현하는 에러 메시지를
출력하도록 해본 경험이 있을 것이다.
하지만 이런 개발자 중심의 에러 메시지는
사용자에게 실제적으로 거의 도움이 되질 않는다.
에러 코드 하나 추가할 때마다 그 에러를 내는 테스트 케이스를 작성해
그 테스트 케이스의 상황을 가장 잘 이해할 수 있는 에러 메시지를 작성한다.
코딩에서 exception 처리는 주 논리 줄기를 벗어난, 아주 희박한 가능성의
경우를 대비한 코드이기 때문에 신경이 덜 가지만,
DBMS에서는 그런 에러 상황 하나하나가 기술 지원 작업 10시간을 줄일 수도 있기에
exception 코드 작성에 몇 시간을 할애한다.
(사실 이런 관행이 몸에 베인 단계까진 아니고, 이런 움직임을 전파하는 단계이다.)
< 널 못믿어...그 아무도 믿지마... >
알티베이스에서 소스 커밋 사고를 가장 많이 일으키는 사람은
신입사원이 아니라, 팀장님 또는 본부장님이시다. (ㅋㅋ)
물론 경험이나 실력은 회사내에서 탑이겠지만
사람이란 실수를 하기 마련이거늘, 리뷰 절차를 생략한게 화근인 것이다.
그런 내력이 쌓인 지금은 그 누구도 리뷰없이 커밋을 못한다.
리뷰는 참 힘든 작업이다.
오전에만 커밋할 수 있도록 제도화 되어 있기에
오전에 수정을 마치면 점심전에 리뷰를 마쳐야 한다.
오전엔 너나할 것 없이 정신없이 바쁘다.
아무리 바빠도 리뷰 요청은 어김없이 찾아오고, 인터럽트에 의한 작업 전환 비용을
감수해야 한다.
그렇다고 리뷰를 대충할 수 있느냐...
한 사람이 모든 걸 알수는 없기에 또 다른 시각으로 코드를 보다보면
버그가 나오기 마련이거나, 심지어 심각한 로직의 오류도 발견된다.
리뷰 시간엔 진정한 딴지의 시간이 된다.
< 안정성, 안정성, 그리고 안정성... >
알티베이스 개발에 삽질중의 넘버원...
바로 전 테스트 케이스 수행이다.
아무리 사소한 소스 수정도 5시간짜리 모듈 테스트
또는 24시간짜리 전체 테스트 케이스
수행을 통과해야 한다.
버터 플라이 효과는 밀림의 나비에서만 생기는게 아니다.
내가 바꾼 플래그 하나가 select 실행 계획 변화로 1000% 성능 저하를
초래할 수도 있는 것이 DBMS 소스의 세상이다.
요정도는 괜찮겠지...하고 커밋한 소스는
분명 문제를 발생시키고 전 개발자들의 작업에 영향을 끼치거나,
혹은 문제가 고객에게까지 가서 큰 사고를 일으키는 경우가 있기에
1분 수정, 24시간 테스트도 허다하다.
고객은 사소한 문제 하나 수정하는데 뭔 하루씩이나 걸리냐 하겠지만,
알티베이스에선 아무리 사소한 문제도 아무리 빨라야 1일이 걸리고,
대부분 3일 이상은 걸린다고 봐야 한다.
< 플랫폼 독립적인 소프트웨어 개발의 애환 >
한 제품이 여러 플랫폼을 지원한다는 사실엔
정말 각고의 삽질, 오리발질 노력이 있었다는 사실을 인정해줘야 한다.
알티베이스에 입사한 초보 개발자들은 누구나 한번씩 하는 실수가 있다.
if (aNode != NULL && aNode->id == sValue)
누가봐도 문제가 없을 것 같지만
이렇게 작성한 개발자는 리뷰시간에 처절하게 빠꾸(?)를 맞게 된다.
if (aNode != NULL)
{
if (aNode->id == sValue) ...
...
}
물론 C 언어 스팩엔 && 연산자가 반드시 왼쪽부터 evaluation한다는 게 명시되어 있지만
안타깝게도 모든 플랫폼의 C 컴파일러가 이 스팩을 준수하지 않는다는 사실을
알티베이스는 경험적으로 알게 되었다.
컴파일 옵티마이징 과정에서 순서가 뒤바뀔 수도 있어
이런 사소한 구문이 NULL 포인터 참조에 의한 시스템 다운이라는 치명적인
상황을 초래할 수 있기에 보기에 싫지만 이중 if문으로 작성해야 한다.
(플랫폼은 모바일 환경도 포함한다.)
사용자들은 단지 테스트를 위해서 특이한 플랫폼 환경의 패키지를 요구한다.
가령 Suse Linux의 gcc 4.2.10에서 돌아가는 패키지를 요구한다면
프로젝트로 정신없는 와중에도
저런 급한 패키지 요청이 들어오면 프로젝트는 올 스탑되고
Suse linux를 구해 gcc부터 설치해야 한다.
그리고 대부분 한번에 빌드되는 일이 없다.
컴파일러 버그도 많으며 (의외로 옵티마이져 레벨을 높이면 예상치못한 버그가 발생되는 경우가 있다.)
운영체제마다 라이브러리나 쉘의 동작이 틀려 문제가 발생하는 경우가 많다.
패키징을 맡은 개발자들은 문제에 부딫힐 때마다 구글이나 동료 직원들에게
물어가며 문제들을 해결해 나가야 한다.
한참 복구 알고리즘을 디자인하다가도 'tail -3' 구문이 플랫폼 마다 틀리게 동작하는
문제를 심각히 고민해야 한다.
오픈 소스 프로그래머가 과연 그 고민을 '재미삼아' 해줄 지...의문이다.
< 기록은 기억을 지배한다 >
메멘토의 주인공은 단기 기억 상실이라는 희귀병에 대항해
온몸에 기록을 남긴다.
이건...결코 남의 일이 아니다.
우리 뇌는 기억을 오래 가지고 가지 못하고 더우기
정확하지도 않다.
우리가 하는 모든 작업 내역은 리포팅한다.
버그 리포트, 프로젝트 리포트, 패키지 리포트, 고객 문제 해결 리포트...
이것에도 저것에도 분류 하기 힘들면 task 리포트라는 것도 있다.
모든 작업을 할 때마다 리포팅이 수반되고
해결된 문제 하나하나가 내력이 쌓여 방대한 데이터베이스가 된다.
직원은 언제든지 퇴사할 수가 있기 때문에
한 직원이 퇴사해도 문제가 되지 않으려면 그 사람이 작업한 내역은
모두 기록되어야 한다.
혹은 심지어 자기가 1년전에 한 작업 내역이 지금의 작업에 절실할 때도 있다.
소스 수정 한줄을 설명하기 위해 10줄의 설명을 기술하는 것도
다 품질을 위한 노력에 포함된다.
이처럼 품질을 위해서는 보이지 않는 노력이 필요하고
그 노력이 몸에 체화되기까지, 문화가 되기까지 많은 시간이 걸리며
기업과 직원 사이 계약의 원천인 '돈' 없이 가능할지에 대해 의문을 가져봤다.
뭐 어찌되었건,
미래 소프트웨어 산업에서 오픈 소스의 행보는 어떻게 바뀌어 갈지
관심을 가지고 지켜볼 주제임에는 틀림없다.
