외주 SW 개발의 비극

열악한 소프트웨어 외주 개발 문제는 우리나라에서 소프트웨어가 3D 취급을 받는 주요한 원인 중 하나다. 

'갑을병'으로 이어지는 외주도 모자라 '갑을병정무'까지 3,4단계 외주를 주기도 한다. 하청에 재하청이 이어질수록 열악한 댓가와 무리한 일정 그리고 부정확한 요구사항은 외주 개발을 점점 구렁텅이로 내몰고 있다.
소프트웨어 외주 개발 문제를 얘기하면 할 말이 많은 사람들이 꽤 있을 것이다. 필자는 그 중에서 접해 본 사례를 중심으로 소프트웨어 공학과개발 문화적으로 문제점을 지적해보고자 한다.

A사는 새로운 서비스를 시작하면서 서비스 개발을 야심차게 인도에 외주를 줬다가 큰 낭패를 봤다. 

지금도 왜 인도에 외주를 줬는지 궁금하지만 추측컨데 실리콘밸리 외주 형태를 흉내를 낸 것이 아닌가 생각한다. 그런데 인도 개발사는 개발 완료 후 L사에서 기대한 것과 전혀 다른 것을 전달해왔다. 프로토콜도 완전히 다른 것이고 도저히 서비스에 사용할 수 있는 상황이 아니었다. 

이런 일이 벌어진 가장 큰 이유는 스펙을 제대로 전달하지 않았기 때문이다. 인도 개발사에 전달된 스펙은 간단한 기획서 수준이었고 프로토콜도 제대로 언급하지 않았다. 게다가 인도 개발사가 소프트웨어를 완성해서 전달할 때까지 중간에 제대로 점검을 하지 않았다. 

한국 업체 같으면 억지를 부려서 잔금을 안주면서 다시 개발을 강요 했겠지만 인도 개발사는 계약대로 개발을 했고 억지는 통하지 않았다. 잔금을 안줄 수는 없었다. 결국 인도 개발사가 개발한 소프트웨어는 모두 버리고 다급하게 한국업체를 통해서 다시 개발을 했다. 돈은 돈대로 더 들고 서비스도 뒤죽박죽이 되었다. 

B사는 1년이 넘는 꽤 긴 프로젝트를 제대로 된 스펙도 없이 외주를 주고 고치기를 반복한다. 

외주 개발사에는 핵심 기능을 정리한 한 두 페이지 정도의 요구 사항 문서가 전달된다. 외주 개발사는 전체 프로젝트 기간 중 20~30% 정도 기간 안에 소프트웨어를 만들어 보여줘야 한다. 남은 70~80% 기간은 B사의 요구대로 거의 매일 소프트웨어를 수정하고 보여주기를 반복해야 한다.

외주 개발사는 해당 분야의 전문 회사라 이런 부정확한 요구사항으로도 대충 B사가 원하는 것을 이해해 개발할 수 있었다. 개발사의 PM은 수시로 고객사에 불려가 요구사항 변경 회의를 해야 했고 소프트웨어를 계속 고쳐나가기 때문에 아키텍처를 제대로 유지하기가 어려웠다. 

심지어 막판에 요구사항이 크게 바뀌어서 다 버리고 다시 만드는 일도 발생했다. 외주 개발사는 비용도 과도하게 투입해야 하고 프로젝트 관리를 제대로 하기도 어렵다. 하지만 B사가 가장 큰 고객이므로 시키는 대로 할 수 밖에 없었다. B사는 이런 식으로 프로젝트를 진행하는 것을 아직도 당연하게 생각한다.

C사와 D사는 소프트웨어 개발 외주가 제대로 진행이 안돼 외주사 개발자를 회사 내부에 앉혀 놓고 같이 개발하는 형태로 개발을 한다. 

외주 프로젝트지만 옆에서 같이 개발하지 않으면 제대로 개발이 안되기 때문에 같이 일해야 한다. 옆에 앉혀 놓고 개발한다 뿐이지 개발 방식은 다른 외주와 별반 다를 바가 없다. 요구사항은 계속 변하고 애써 작성한 코드를 버리고 고치기를 반복해야 한다. 

외주사도 이런 방식이 비효율적이라서 원하지 않지만 고객사의 우월한 지위를 꺽을 수가 없고 이렇게 일하다 보니 외주 개발 내용 외에 그냥 직원처럼 부림을 당하는 경우가 많이 발생한다. 

D사는 외주를 줬다가 소스코드가 없어져서 소프트웨어를 버려야 했다. 

D사는 소스코드를 받을 수 없는 외주 계약으로 개발을 했다. 처음 몇 년은 유지보수를 잘 했지만 몇 년 후 외주 개발사는 망해서 없어졌다. 그 과정에서 소스코드가 D사로 제대로 전달되지 않아서 최신 소스코드를 찾을 수 없는 상황이 되었다. 결국 외주 개발한 소프트웨어는 모두 버리고 다시 개발해야 하는 상황이 되었다.

E사는 개발자가 해야 할 개발자 테스트를 외주업체에 맡긴다.

개발자는 열심히 코딩만 하고 옆에 앉아서 외주개발자가 기본적인 개발자 테스트를 해준다. 속된 말로 '따까리'라는 말이 적합하다. 비싼 자사 개발자가 너무 바쁘기 때문에 그렇게 한다고는 하지만 자칫하면 잘못된 개발 습관이 쌓일 수 있다. 

또한 이렇게 해서는 코드 품질을 보장하기 어렵다. 완벽한 로직의 코드인지는 개발자 본인이 가장 잘 확인 할 수 있는데 대충 만들고 발견된 문제만 해결하는 방식이 습관화 될 수도 있다. 개발자는 완벽한 소스코드를 적는데 최선을 다해야 하는데 이런 개발자의 의무를 망각하면 프로그래밍은 기초부터 흔들리게 된다. 

위에서 살펴 볼 수 있듯 외주 문제의 주된 원인은 부실한 스펙이다. 모호한 요구사항 정도로 계약을 하게 되니 중간에 요구사항이 계속 바뀌어도 어쩔 수 없고 프로젝트 종료 기준도 모호하여 담당자 맘에 안들면 잔금을 받기도 어렵다. 소송도 종종 일어나지만 시간도 오래 걸리고 소송을 해도 해결하기 쉽지 않다. 고객이 대기업인 경우 소송을 하기도 쉽지 않다. 스펙을 제대로 적는 것은 소프트웨어를 개발하는데 있어서 가장 어려운 일이기 때문에 한마디로 설명할 수는 없다. 

소프트웨어를 직접 개발하지 않고 외주 개발을 하는 주된 이유는 다음과 같다. 직접 개발할 수는 있는데 내부 인력이 부족할 때와 특정 요소기술을 내부에서 보유하고 있지 않을 경우다. 내부에서 개발할 수 없을 만큼 잘 모를 때는 외주를 주기도 어렵다. 모르는 상태에서 대충 외주를 주면 원하는 결과를 얻기도 어렵고 분쟁이 일어나기 쉽다. 

기술력이 뛰어나거나 전문 기술을 가지고 있는 외주 개발사와 협업을 잘하는 것은 소프트웨어 생태계를 만드는데 아주 중요하다. 제대로 외주를 주기 위해서는 고객도 스펙을 제대로 적을 수 있을 만큼 잘 알아야 한다. 

부품 업체 다 망하고 나면 자동차 회사도 망하듯이 수많은 전문 소프트웨어 회사들이 망하고 나면 우리나라 소프트웨어 업계도 망하는 것이당연한 수순이다. 대만이 자전거 산업에서 세계를 호령하는 이유는 자전거 부품회사와 꾸준히 상생을 해와서 대만에는 뛰어난 자전거 부품회사가 많기 때문이다. 그에 비해서 생산비 절감에만 몰두한 우리나라 자전거 산업은 전세계 자전거 산업에서 명함도 못 내밀고 있다. 이미 많은 중소 소프트웨어 회사들이 사라졌거나 고사 상태인 지금 자전거 산업과 비슷한 미래가 예상되는 것은 안타까운 일이 아닐 수 없다. 

이제 와서 말로만 베풀듯이 상생이라고 외치는 것은 들을 때마다 거북하고 막상 그 내용도 해결책의 핵심은 아니다. 우리나라에서 소프트웨어 개발이 3D라는 인식에서 벗어나라면 이런 열악한 외주 환경이 바뀌지 않으면 안된다. 

이글은 ZDNet Korea에 기고한 칼럼입니다.

고객이 SW를 망친다

우리나라는 고객이 소프트웨어와 개발사를 망치는 경우가 많다. 외국 소프트웨어 회사와는 다른 잣대로 우리 소프트웨어 회사를 대하는 이중성 때문에 우리나라 소프트웨어 회사는 더욱 어려움을 겪는다. 물론 이런 현상이 꼭 고객 탓만은 아니다. 

우리나라 소프트웨어 회사들이 미래는 생각하지 않고 당장 눈앞의 이익만 쫓다 보니 고객들은 여기에 길들여진 측면도 있다.

이렇게 고객이 소프트웨어 환경을 망치고 있는 실제 사례들을 알아보자. 

A사 고객들은 참을성이 없다. 

소프트웨어에 버그가 발견되면 당장 고쳐달라고 막무가내 식으로 요구한다. A사는 팩키지 소프트웨어를 만들기 때문에 개별 고객의 요구사항을 다 들어주지는 않는다. 하지만 이렇게 무리한 요구를 하는 고객이 많기 때문에 당장 고쳐주지 않을 수 없다. 

이렇게 계획되지 않는 급한 수정을 핫픽스(Hotfix)라고 한다. A사는 특정 몇몇 고객 때문에 핫픽스를 과도하게 많이 만드느라 계획된 개발 일정에 지장이 생겼고 소스코드도 지저분해졌다. 

하지만 A사 고객들도 외국 소프트웨어를 사용하면서는 그런 무리한 요구를 하지 않는다. 외국 소프트웨어 회사들은 대부분 그런 요구는 들어주지도 않기 때문이다. 

B사는 소프트웨어 버그로 인해서 개발자가 고객사에 방문 사과를 한적이 있다. 

B사 고객들은 소프트웨어 버그가 발견되면 개발자를 죄인 취급한다. 가끔은 심각한 버그가 발생하면 개발자의 방문사과를 요구한다. 이런 말도 안되는 요구에 B사는 상황을 쉽게 모면해 보려고 개발자에게 고객을 방문해서 사과할 것을 지시했다. 

개발자는 어쩔 수 없이 사과 방문을 했고 개발자로서 회의를 느꼈다. 사실 버그 없는 소프트웨어는 없고 버그가 개발자만의 책임도 아니다. 개발에 참여한 모든 사람의 공동 책임인데 아직도 버그의 모든 책임은 개발자에게 있다고 생각을 하는 경향이 있다. 

자동차를 타면서 문제가 발생하면 자동차 만든 사람이 와서 사과를 하라고 하는 경우는 없다. 개발자에게 버그에 대한 사과를 요구하는 일은 대한민국에서만 벌어지는 현상이 아닐까? 

C사는 개발자들이 고객 옆에서 개발을 해야 한다. 

C사는 솔루션 회사다. 자사 솔루션을 이용해서 고객 요구대로 커스트마이징해서 개발을 해준다. 그런데 주로 고객들은 자사 담당자 옆자리에서 개발을 할 것을 요구한다. 사실 개발자들은 다니는 회사에서 개발하는 것이 훨씬 더 효율적이다. 여러 동료의 도움을 받을 수도 있고 환경도 더 좋다. 

그런데 고객이 방문해서 개발을 할 것을 강력하게 요청하기 때문에 어쩔 수가 없다. 스펙도 정하지 않고 옆에 앉혀 놓고 이러쿵저러쿵내키는대로 요구사항을 말하면서 소프트웨어를 개발한다. 요구사항이 많이 바뀌어서 지우고 다시 만들기를 수없이 반복했다. 

물론 외국 경쟁회사는 이런 요구에 콧방귀도 안뀌기 때문에 C사는 이런 방문 개발 방식을 강점으로 내세워서 국내 시장에서 상당한 성공을 이뤄냈다. 하지만 성장은 한계에 다다랐고 과거의 방식을 버려야 더 점프를 할 수 있다는 것을 알아도 방식을 바꾸기에는 너무 늦어버렸다. 고객보다도 개발자들이 이 방식에 익숙해져서 내부 개발문화를 바꾸지 못하는 것이 더 큰 걸림돌이 되고 있다. 

D사도 고객사에 방문해서 개발을 해야 한다. 

하지만 이유가 약간 다르다. 고객이 보안을 너무 강조하다 보니까 고객사에 방문해서 개발할 수 밖에 없다. 고객사에서 아무것도 가지고 나올 수 없다. 개발은 모두 고객사에서 해야 하고 고객사를 나올 때는 몸밖에 빠져나올 수 밖에 없다. 사실 이 회사도 외국 소프트웨어 회사와는 이렇게 일하지 않는다. 고객의 이중성은 여기서도 드러난다. 

E사는 유지보수 비용을 제대로 받지 못했다. 

E사는 솔루션 회사인데 납품 후에도 지속적인 유지보수 비용이 들어간다. 버그 수정 및 기능 개선이 꾸준히 이루어진다. 하지만 고객은 무상 유지보수를 요구해서 유지보수 비용을 제대로 받지 못한다. 심지어는 버그를 고치는데 왜 돈을 받냐는 주장을 하기도 한다. 

E사의 고객들도 외국의 소프트웨어를 쓸 때는 군말 없이 유지보수 비용을 지불한다. 외국 소프트웨어를 쓸 때는 패키지 소프트웨어라 하더라도 워런티 계약을 따로 한다. 워런티 비용은 소프트웨어마다 다르지만 매년 소프트웨어 구매 비용의 10%~50%를 지불한다. 

1년간 아무런 요청을 하지 않아도 비용은 지불해야 한다. 3년간 워런티 계약을 하지 않다가 4년째 문제가 발생해서 지원을 요청하려면 4년치 워런티 비용을 모두 지불해야 한다. 이렇게 외국의 소프트웨어 회사에는 유지보수 비용을 지불하지만 대한민국의 소프트웨어 회사에는 매우 인색한 것이 현실이다. 

F사 고객이 말도 안되는 문서를 수십 종 요구한다. 

F사는 SI회사다. 대부분은 실제 소프트웨어 개발에 꼭 필요한 문서는 아니다. 단지 고객이 제시하는 방법론에서 필요한 문서일 뿐이다. F사는 실제로는 고객 프로세스대로 소프트웨어를 개발하지도 않는다. 그런 식으로는 소프트웨어를 주어진 시간에 개발할 수 없기 때문이다. 

개발은 그냥 평소대로 하면서 문서만 추가로 따로 만든다. 문서를 반복적으로 만들어내다보니 너무 번거로워서 나중에는 문서를 자동으로 생성하는 프로그램을 만들기도 했다. 이렇게 만들어진 문서는 프로젝트 도중에도 프로젝트 후에도 아무도 보지 않는다. 

그냥 검수를 통과하기 위한 조건일 뿐이고 검수 시에도 소프트웨어와 문서가 일치하는지 확인할 방법도 없다. F사는 고객의 이러한 과도한 문서 요구에 프로젝트 비용이 훨씬 많이 들어가고 정작 개발할 시간이 줄어 들고 있다고 하소연을 하고 있다. 

G사는 패키지를 수정해달라는 고객의 요구로 인해서 회사가 어려워졌다. 

G사 고객들은 패키지 소프트웨어를 바꿔달라는 요구가 많다. G사도 이런 고객의 요구사항에 빠르게 대응하다 보니 소스코드가 여러 벌이 생겼다. 소스코드도 그냥 복사를 해서 고객별로 관리를 해서 시간이 흐를수록 개발 속도는 점점 늦어졌다. 기능 하나를 수정해도 여러 벌의 소스코드에 적용을 해야 했다. 

이렇게 소스코드를 통합(Merge)하는 시간이 점점 길어졌고 나중에는 개발하는 시간보다 소스코드 통합에 더 많은 시간이 소요되었다. 결국 G사는 문을 닫았다. 이는 고객 탓만은 아니고 눈앞의 이익만 쫓는 G사의 무분별한 단기 대응도 문제였다. 

요즘 정부도 민간도 소프트웨어 환경을 개선해보고자 많은 노력을 기울이고 있지만 정작 돈을 내고 있는 고객들은 바뀌지 않고 있다. 물론 고객만의 탓은 아니다. 수십 년간 우리나라 개발회사들에 길들여진 것뿐이다. 

이렇게 소프트웨어 환경이 망가지면 결국 고객들도 손해를 본다. 우리나라 소프트웨어 회사들이 많이 망가지고 나면 제대로 쓸만한 국산 소프트웨어가 줄어들고 울며 겨자먹기 식으로 비싸고 문화도 잘 맞지 않는 외국의 소프트웨어를 써야 한다. 

법으로 바꿀 수 있는 것은 바꿔야 한다. 사실 별 뾰족한 답도 없는 문제지만 결국 고객을 바꾸는 것은 개발사들이다. 계획적인 개발을 하려고 해도 경쟁사에서 고객 밀착형 서비스를 한다고 하면 경쟁에서 밀리고 만다. 

결국 이런 소프트웨어 품질보다 노예식 개발을 장점으로 내세우는 전략은 모두를 다 망치는 일이라는 것을 인식하자. 특히 시장을 주도하는 선두 주자들부터 소프트웨어 환경을 건전하게 바꾸어 나가면 고객의 우리나라 소프트웨어에 대한 이중적인 인식을 바꾸는 것이 불가능하지는 않을 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

소프트웨어공학은 실전이다.

이 전글에 댓글을 달려다가 좀더 정리를 해야 할 것 같아서 본글로 올린다.

2013/02/27 - [프로젝트/품질관리] - 거의 다 만들었어요.

알파, 베타의 정의를 가지고 이렇게 강하게 주장하는 경우는 처음봐서 약간 당황스러웠다. 독자들은 알아서 판단하겠지만 혼란이 있을 수도 있어서 다시 한번 내 의견을 밝힌다.

나는 20년간 한국, 미국, 대기업, 벤처기업을 다 경험하고 이론과 실전을 다 경험하고 온 국민이 쓰는 소프트웨어 개발에도 다수 참여하고 수많은 소프트웨어 프로젝트를 성공시켰고 여러 소프트웨어의 회사의 역량 개선을 시키고 있고 이런 경험을 책(소프트웨어 개발의 모든 것)으로 쓰고 블로그를 통해서 공유하고 있다. 

소프트웨어 공학은 실전이다. 이론적으로 먼저 정립된 것이 아니라 실전적인 발전을 거듭해오다가 이론적인 정리가 된 것이다. 따라서 보편적인 이론과 원리가 있고 주장이 있으며 회사마다 그 응용이 있다. 물론 모든 회사의 응용이 효율적인 것은 아니다. 대부분의 우리나라 소프트웨어 회사들의 응용이 비 효율적인 이유는 그 원리를 모르고 응용만 해왔거나 스스로 방법을 생각해 냈기 때문에 한계가 있는 경우가 많다.

세상에는 수만가지 종류의 소프트웨어가 있고 그에 알맞는 라이프사이클도 약간씩 다르다. 다른 것이 잘못된 것은 아니다. 따라서 하나의 프로세스나 이론만 들이대고 이대로 따라하면 모든 소프트웨어에 알맞다고 주장하는 것은 틀릴 가능성이 매우 높다. 

이론서를 보거나 Wikipedia를 보더라도 "generally"라는 용어를 주로 사용하는 이유가 그것이다. 

알파, 베타라는 용어도 최초에 한사람이 이를 정의하고 모든 사람들이 이것을 따르라고 한 것이 아니다. IBM에서 최초로 A, B버전을 사용하였고 수많은 회사가 이런 용어를 따라했으며 Microsoft가 이후에 많은 영향을 미쳤으며 수많은 회사들이 이와 유사한 용어를 따라서 써오다보니 어느 정도 정립이 되었을 뿐이다. 각 회사의 프로세스 정의서에 알파, 베타에 대한 정의가 서로 다르며 이것이 틀린 것은 아니다.

제가 컨설팅했던 수많은 회사에서도 알파, 베타 버전의 용어가 비슷은 하지만 미묘하게 약간씩은 다르다. 회사마다 천차만별로 다른 것이 아니고 핵심적인 것은 비슷하지만 약간씩 다른 것이다. 이것이 틀린 것은 아니다. 회사마다 소프트웨어의 성격에 따라서 강조해야 하는 것이 다르고 프로세스가 다르다. 그렇다고 회사에서 개인마다 다르게 사용해서는 안된다. 회사내에서는 동일한 절차와 정의를 사용해야 한다. 회사마다 코딩컨벤션이 다른 것도 그 하나이다.

회사를 옮기면 그 회사의 조직, 프로세스, 규칙을 익혀야 한다. 대부분의 회사가 비슷한 프로세스와 정의를 사용하기 때문에 이를 익히는데 며칠도 걸리지 않는다. 대부분은 그냥 적응한다.

회사마다 다른 극단적인 예를 들면 5년이 걸리는 화상탐사선을 개발할 때와 간단한 Web application은 알파, 베타, RC를 다루는 방법이 다르다. 화성탐사선은 스펙이 완벽하게 정해지고 수정되는 법이 없고 스펙이 바뀐다면 엄청난 크로스체크와 절차가 필요하다. 하지만 간단한 Web application은 많이 다를 것이다.

모든 것은 어떻게 하면 소프트웨어를 가장 효율적으로 개발하느냐에 집중되어 있다. 소프트웨어의 성격에 따라서 회사의 조직, 프로세스, 시스템, 문화등이 비슷은 하지만 조금씩 달라진다. 어떻게 하면 효율적으로 개발할지 고민을 하다보니 여러 라이프사이클이 나오고 방법론도 매우 많다. 그 중에서 개발하는 소프트웨어에 가장 알맞는 방법을 선택해야 한다. 여기서 한가지만 옳다고 주장하는 것도 잘못된 것이지만 비효율적인 방법을 선택하는 것도 안좋다.

우리가 주의할 것은 하나의 경험이나 학습으로 세상의 모든 진리로 착각하면 안되겠다는 것이다. 그래서 나도 글을 쓸때 항상 조심하는 편이다. 또한 다른 사람의견에 빈정대거나 공격하지 않고 건설적인 토론을 하려고 노력한다. 하지만 대중을 상대로 하는 일이라 힘들때가 많다. 교양있는 여러분의 많은 경험을 같이 나누고 싶다.

Agile이 우리 회사 문제를 해결해 줄 수 있을까?

소프트웨어 공학이라는 용어는 사용하기가 상당히 꺼려진다. 소프트웨어 공학이라는 용어를 듣는 사람들이 많은 오해를 하기 때문이다. 일단 듣는 순간 거부감을 가지는 사람들도 상당히 많다.

소프트웨어 공학이 무엇인지 사람마다 서로 다르게 생각하고 있다. 그럼 스스로 소프트웨어 공학을 어떻게 생각하고 있는지 골라보자. 소프트웨어 공학이란?

1. 소프트웨어를 체계적으로 개발하기 위한 방법이다.

2. 고객이 만족하는 소프트웨어를 개발하는 방법이다.

3. 소프트웨어를 여러 사람이 효과적으로 개발하기 위한 방법이다.

4. 유지보수가 용이한 소프트웨어를 개발하기 위한 방법이다.

5. 프로세스를 따라서 소프트웨어를 개발하기 위한 방법이다.

6. 품질이 좋은 소프트웨어를 개발하기 위한 방법이다.

7. 성능이 좋은 소프트웨어를 개발하기 위한 방법이다.

8. 야근을 하지 않고 소프트웨어를 개발하기 위한 방법이다.

9. 소프트웨어를 빠르게 개발하기 위한 방법이다.

소프트웨어 공학을 정확하게 이해하고 있지 못하다면 이중에서 하나를 고르는 것은 여간 헷갈리는 것이 아니다. 정답은 9번이다. 

소프트웨어 공학은 소프트웨어를 가장 적은 비용으로 가장 빠르게 개발하기 위한 방법을 모아 놓은 것이다. 

어디서 많이 듣던 얘기다. 소프트웨어를 빠르게 개발하자고 하는 것은 Agile이 아닌가?

옛날에는 소프트웨어를 늦게 개발했는데 Agile이라는 것이 나와서 그때부터 빨리 개발해야 하겠구나 해서 빨리 개발하기 시작한 것이 아니다. Agile 이전 몇십년 전부터 소프트웨어를 빨리 개발하는 방법에 집중 되어 왔었다. 즉 Agile이라는 용어가 나오기 전부터 Agile하게 개발을 해왔는데 용어를 만들고 그럴듯하게 포장을 하고 상품화를 한 측면이 있다. Agile에서 사용하는 수많은 기법들도 대부분 그 훨씬 이전부터 해오던 것이다. 

유사한 것 중에 UML이 있다. UML 탄생 이전에도 UML의 내용은 거의 다 있었지만 UML은 이들을 모으고 종합해서 상품화를 한 것이다. UML이 기여한 것은 툴을 제공하고 기법의 표준을 정리했지만, 많은 개발자들이 설계는 UML로 하는 것이라는 착각을 일으키게 해서 오히려 소프트웨어 업계를 혼란에 빠뜨린 경향이 있다.

소프트웨어 공학에서는 특정 기법이나 방법론을 써야 한다고 강요하고 있지 않다. 기법은 회사나 프로젝트의 성격에 알맞은 것을 취사선택 하면 된다.

가끔은 Waterfall과 비교를 하면서 Waterfall의 비효율성을 강조하는데 실제 Waterfall을 적용하여 개발하는 곳은 하나의 없다. 개발할 수도 없는데 비교를 하는 것이다. Waterfall은 99.9% 기업에서 적용은 못하지만 여러 방법론 또는 라이프사이클의 모델이 되는 것이다. 비교 대상이 아니다. 전세계적으로도 Waterfall대로 개발하는 프로젝트는 0.001%도 되지 않고 그렇게 할 필요도 없고 그럴 역량도 대부분 없다.

소프트웨어 개발을 잘하기 위해서 즉, 빠르게 개발하기 위해서 방법론만 적용한다고 되는 것은 아니다. 방법론은 소프트웨어 공학의 일부분일 뿐이다. 소프트웨어를 빨리 개발하기 위한 소프트웨어 공학에서 다루는 분야는 방법론 이외에도 분석, 설계, 구현, 테스트, 유지보수, 형상관리, 프로세스, 툴, 품질 등 많다.

특히 분석 즉, “스펙 작성”은 기법 좀 배워서 잘 할 수 있을 것으로 생각하면 오산이다. 수많은 소프트웨어 전문가가 스펙이 소프트웨어 개발에서 가장 어렵고 중요하다고 하는데 괜히 하는 소리가 아니다.

소프트웨어 개발에 문제를 깨닫고 Agile 등 새로운 것에 희망을 걸고 시도를 해본 많은 사람들이 있을 것이다. 그 성과는 어땠는가? Agile 등의 세미나를 많이 쫓아 다니면서 들어서 정말 회사에서 소프트웨어 개발 문제가 사라졌고 소프트웨어가 빨리 개발되고 있는지 스스로에게 물어보자. 그렇지 않다면 그 동안 Silver bullet을 쫓아다닌 것이다.

Silver bullet이란 늑대인간을 한번에 확실하게 죽일 수 있는 전설로 내려오는 탄환이다. 소프트웨어도 많은 사람들이 한방에 모든 문제를 해결해 줄 수 있는 전설의 탄환이 있을 것으로 생각해왔다.

개발 경력이 몇 년 안된 개발자는 잘 모르겠지만 경력이 20년이 넘은 개발자들은 Silver bullet의 역사를 잘 알 것이다. 20여 년 전에는 OOP가 소프트웨어 문제를 모두 해결해 줄 수 있을 줄 알았는데 그렇지 못했다. 그 뒤 CBD, XP가 지금은 Agile이 우리를 유혹하고 있다. 

확실한 것은 이 모두가 전혀 잘못된 방법이 아니라는 것이다. 단지 너무 맹목적으로 믿을 경우 문제가 되는 것이다.

과거에 ZDNet Korea에 기고한 "소프트웨어 개발방법론의 함정"이란 글도 참고하기 바란다.

우리나라에서는 특히나 Silver bullet 열풍이 더 거셌다. 이미 소프트웨어 공학과 개발문화가 정착된 소프트웨어 선진국에서는 필요한 것들을 쉽게 적당히 접목했는데 항상 목마른 우리나라 개발자들은 새로운 것이 나오면 그냥 다 해결 해 줄 것 같이 매달려오기를 벌써 20년이 넘었다.

앞으로 10년 후에도 또 새로운 방법론이나 기법을 가지고 이러고 있어서는 안된다. 기법이나 방법론이 잘못된 것은 하나도 없다. 적용하는 우리의 자세가 중요하다.

소프트웨어 공학은 배울 수가 없다. 경험으로 익히는 것이다. 그런데 방법론 전문가에게 배울 수 있을까? 배우는 것이 의미는 있다. 하지만 얻는 것은 크지 않다. 1%을 배운다면 실제 프로젝트에 적용해서 오랜 경험과 합쳐져야 100%가 된다. 방법론 전문가는 1%는 가르쳐 줄 수 있지만 100%는 본인은 실전 경험이 없거나 적기 때문에 알지도 못한다. 물론 그 1%가 없으면 방향을 못잡고 100%에 영원히 이르지 못할 수가 있다.

방법론이나 기법 전문가가 소프트웨어 전문가가 아니고 우리 개발자가 소프트웨어 전문가이다. 방법론 전문가는 결코 소프트웨어 전문가가 될 수 없다. 대부분은 실전 경험이 부족하기도 하고 실전 프로젝트를 할 시간도 없기 때문이다. 피아노는 치는 것은 초보인데 이론과 방법은 전문가인 사람이 피아니스트를 교육 시키거나 세미나에서 가르치는 격이다. 모르던 이론과 방법을 한번 듣는 정도의 의미가 있지 그 이상을 가르쳐줄 수 있다고 생각하면 착각이다. 또한 배운 그대로 따라 해야 하는 것도 아니다. 원리를 깨닫고 스스로 알맞게 적용해야 한다. 방법론 전문가는 방향과 기법을 알려주는 역할만 할 수 있을 뿐이다.

여러분들보다 소프트웨어 개발에 대해서 잘 모르는 방법론 전문가에게 해답을 구하다가는 "주화입마"를 입을 수 있다. 원리보다 이론이나 기법을 쫓다가 마를 입을 수 있다.

그럼 어떻게 해야 할까?

Silver bullet을 쫓지 말고 근본 원리를 깨닫기 위해서 노력해야 한다. 기법은 익히되 기법이 해결해 줄 것으로 너무 큰 기대를 하지 말아야 한다. 인식을 바꾸고 개발 문화를 정착 시키는데 더 큰 노력을 기울여야 한다. 방법론 전문가에게는 그런 관점으로 방법론을 배우고 소프트웨어 개발은 소프트웨어 전문가에게 배우는 것이다. 보통은 선배 개발자들이 소프트웨어 전문가이다. 하지만 우리나라에서는 회사 내부에 소프트웨어 전문가가 부족하니 외부에서 자꾸 찾으려는 경향이 있는데 방법론 전문가를 소프트웨어 전문가로 착각해서 너무 큰 것을 기대해서는 안 되는 것이다. 진짜 소프트웨어 전문가를 찾던지, 소프트웨어 전문가가 많은 회사로 옮기던지, 스스로 해나가는 수 밖에 없다.

요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다.

소프트웨어 개발 프로젝트에서 스펙을 제대로 적지 않는 회사들에게 그 이유를 들어보면 여러가지가 있다.

1. 프로젝트 기간이 너무 짧아서 스펙을 적을 시간이 없다.

2. 프로젝트가 너무 복잡해서 적어야 할 것이 너무 많아서 적을 수 없다.

3. 요구사항을 계속 바꿔서 스펙을 적을 수가 없다.

위의 어떠한 이유도 적절한 이유가 되지는 않는다. 오직 한가지 이유가 될 수 있다면 다음과 같은 것이 있을 수 있다.

"우리는 분석역량이 떨어져서 스펙을 적을려고 해도 제대로 적을 수 없다. 그래서 그냥 개발한다."

위 1,2,3번의 이유 때문에라도 스펙을 적어야 하는 것이다.

이중에서 3번 "요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다"에 대해서 얘기를 해보고자 한다.

99%의 소프트웨어 프로젝트는 분석 기간은 당연하고 설계, 구현 중에도 요구사항이 계속 바뀐다. 단지 프로젝트마다 바뀌는 정도의 차이가 있을 뿐이다.

스펙을 제대로 적었다는 전제하에 스펙을 결정한 후에도 요구사항이 계속 바뀌는 이유는 다음과 같은 것들이 있다.

1. 시장 상황의 변경

2. 경쟁 업체의 신제품 출시

3. 기술 환경의 변화

4. 미처 파악하지 못한 비즈니스 요구사항 발견

5. 예상치 못한 개발 상의 난관 봉착

6. 경영진의 변덕

7. 영업, 마케팅 부서의 끊임 없는 요구

이런 저런 이유로 요구사항 변경 요구는 계속 되기 마련이다. 스펙을 제대로 적어 놓지 않으면 이러현 변경 요구가 관리되지 않는다. 또한, 변경 프로세스를 적용하면 좀더 합리적인 변경 관리가 가능한다.

프로세스라고 하니까 뭔가 매우 부담스러워하고 특히, 영업과 마케팅 부서는 싫어하는 경향이 있다. 과거에는 코딩 중이라고 하더라도 친한 개발팀장에게 추가로 요구를 하면 잘 들어 줬는데 변경 프로세스를 밟으라고 하면 싫어하기 마련이다. 하지만 중요한 프로젝트의 일정과 품질에 영향을 줄 수 있는 결정에 큰 Risk를 안으면서 그냥 결정할 수는 없다.

변경 프로세스의 핵심은 "변경 영향 평가"이다. 이것도 그렇게 거창한 것은 아니다. 새로운 요구사항이 프로젝트에 어떠한 영향을 주는지 정량화하는 것이다. 일정이 더 필요할 수도 있고, 오히려 줄어들수도 있다.(드물지만) 또한 기술적인 위험이 증가할 수도 있다. 짧게는 10분, 길면 몇시간 걸리는 일이다. 스펙을 제대로 적어 놓지 않았다면 요구사항 변경으로 인해 아키텍처에 어떠한 영향을 주는지 파악하기 어렵고, 일정에 미치는 영향도 판단하기 어렵다. 그래서 스펙이 필요한 것이다.

변경 영향 평가가 되었다면 이러한 영향이 있는데도 불구하고 새로운 요구사항을 반영해야 하는지 투명하게 판단을 해야 한다. 어떤 요구사항은 정말 간단한 것 같은데 프로젝트에 큰 악영향을 주는 것도 있고, 커보이는 요구사항이 프로젝트에 문제 없이 포함될 수 있는 것도 있다. 즉, 요구사항 변경이 합리적으로 결정될 수 있다.

변경이 쉽지 않다는 것을 잘 알기에 스펙을 제대로 적고 철저히 리뷰하는 문화가 더욱 견고해지는 것이다.

이러한 프로젝스와 문화가 정착된다면 개발자들도 터무니없는 기능 추가 요청에 일정은 절대 안바꿔주는 비합리적인 요구는 줄어들게 된다. 스펙을 제대로 적고 변경을 관리하는 것이 회사에도 이익이지만 개발자에게는 더욱 좋은 문화임에도 많은 개발자들이 거부하는 경향이 있다. 이는 개발자들 탓이 아니다. 그동안 개발환경이 근거없는 일정 강요와 야간에 내몰리다보니 하루라도 빨리 코딩을 해야 한다는 생각에 내몰린 것이다.

또한, 무리한 요구사항 변경 요청에 "아키텍처를 너무 많이 바꿔야 한다". "몇달이 더 필요하다"라고 하면 개발자들은 항상 안된다고 주장한다고 치부를 해버리곤 한다. 그래서 무리한 변경 요구에 개발자들이 주로 약자가 되곤 한다.

스펙이 잘 작성된다면 일정, 리스크, 비용 등 모든 것에 근거가 생기고 합리적으로 결정할 가능성이 훨씬 높아지게 된다. 

스펙은 프로젝트가 끝날 때까지 계속 바뀌게 되어 있다. 그래서 스펙은 계속 업데이트가 되어야 한다. 하지만 합리적으로 변경 관리가 되어야 한다.

내가 소스코드를 몰래 고치는 이유

여러 소프트웨어 회사를 분석해보면 소스코드를 공유하는 정도에서 정말 많은 차이가 난다.

여기서 소프트웨어 회사란 소프트웨어를 개발하고 있는 회사로서 흔히 얘기하는 팩키지 소프트웨어 회사가 아니다.

SI회사, 가전회사, 산업로봇회사, 반도체장비회사, 인터넷회사, 게임회사, 금융회사 등의 다양한 회사를 모두 말한다.

이들 회사 중에서는 개발자가 소스코드를 몰래 고치고 공유도 하지 않는 회사들이 의외로 많다.

개발자가 소스코드를 몰래 고치는 이유에는 이건 것들이 있다.

내 소스코드는 나만 알아야 회사에서 나의 파워가 유지된다.

일부 일리가 있는 이론이다. 내가 없으면 내가 작성한 소스코드를 이해하지도 고치지도 못하면 나는 절대로 짤릴 수가 없다. 문제가 있을 때마다 나에게 달려와서 이것 좀 고쳐달라고 하면 내가 좀 대단한 사람이 된 것 같은 생각도 든다. (이전에 블로그에 포스트한 글 참고)

2009/04/28 - [사람과 기술] - 과거의 개발자 vs. 미래의 개발자

실제로 실력이 있는 개발자들이 이런 행동을 하기도 한다. 하지만 이런 행동은 본인의 성장에 방해가 된다. 더 어렵고 가치있는 해야 할 사람이 과거의 소스코드에 발목잡혀서 휴가도 마음대로 못가게 된다. 개발자의 파워 및 가치는 과거에 있는 것이 아니고 미래에 회사에 필요한 가치에 있다는 것을 알아야 한다. 그것이 회사와 개발자의 상생의 기초이다.

내가 작성한 소스코드의 품질이 형편없어서 보여주기 창피하다.

어떤 천재 개발자도 공유하지 않고 혼자 개발을 해서는 좋은 코드를 작성하기 어렵다. 꾸준히 공유를 하면서 다른 사람들과 의견 교환을 통해서 점점 나아진다. 혼자 개발한 코드는 이상한 코드로 가득차 있기 마련이다. 

세 사람이 걸어가면 그 중에는 꼭 스승이 있듯이 신입사원과 코드 리뷰를 해도 배울 것이 나오게 된다.

소스코드를 보여주는 것을 창피해 할 것이 아니라 자꾸 보여주고 교류를 해야 나아진다.

엄청 어려운 것을 개발하고 있는 것처럼 행동했는데 소스코드를 보면 별 것 아니라는 것이 들통날 것 같다.

종종 접하는 문제다. 심지어는 오픈소스코드를 가져다가 동료들에게는 자기가 개발한 것 같이 자랑하는 경우도 있다. 이것은 회사입장에서 더 큰 문제가 될 수도 있다. 오픈소스 라이센스 규정을 어겨서 소송을 당할 수도 있다.

스펙을 적절하게 작성하고 설계를 하는 과정들에서 서로 리뷰를 적절하게 한다면 서로 어떤 컴포넌트를 어떤 Technology를 이용해서 개발하는지 다들 알게 된다. 어떤 것은 어렵고 어떤 모듈은 신입사원이 구현해도 될 만큼 쉬운 것인지 모두 알게 된다. 

SRS를 제대로 작성하게 된다면 모든 프로젝트 관련자가 프로젝트가 어떻게 구성되어 있고 어떻게 진행되고 있는지 훤히 할게 된다.

너무 바빠서 공유할 시간도 없다.

이미 불끄기 모드로 들어간 회사는 단기적인 해결책이 없다. 이런 회사에서는 서로 자기일 하기 바빠서 점점 서로 더 단절되게 된다. 또 다시 악순환이 진행된다.

2011/01/03 - [개발문화] - 매일 불난 호떡집 같은 회사 (중요한 일 vs. 시급한 일)

시간이 좀 걸리겠지만 악순환의 고리를 끊어야 한다.

공유를 해봤자 관심도 없다. 다들 바쁜데...

공유문화가 정착되지 않은 회사이다. 이런 회사에서 코드리뷰는 별 의미도 없다. 

시도를 해봤자 시간 낭비일 것이다. 내용을 모르는데 코드리뷰를 해도 기껏해야 Syntax 검사밖에 못할 것이다.

SRS리뷰를 먼저 시작하는 것이 좋다. SRS가 리뷰를 해야 할 것도 더 많고 SRS가 제대로 작성되어야 다음 단계인 설계, 구현이 제대로 진행되며 리뷰를 해도 내용을 알고 리뷰를 할 수 있게 된다.

이렇게 되면 "바쁜데..."라는 핑계가 조금씩 줄어들만큼 시간을 절약할 수 있게 된다.

결론

개발자가 작성하는 모든 소스코드는 기록이 남아야 하고 남게 된다. 물론 분석, 설계도 마찬가지이다.

Baseline에 포함되는 소스코드와 문서들은 소스코드 관리시스템에 들어갈 때 설명을 적절하고 충실하게 달아야 한다. 이때 이 소스코드를 누가 리뷰했는지 기록을 남기기를 권장한다. 리뷰를 했다는 의미는 소스코드 작성자와 같이 이 소스코드에 대해서 공동책임을 진다는 의미이기도 하다. 이것이 부담스러워서 리뷰를 하지 않는다면 아무도 리뷰를 하지 않을 것이다. 서로 리뷰를 해주는 것은 모두에게 도움이 되는 것이다. 이것은 규칙으로 강요를 해서는 효과가 없고 분위기가 조성되어서 오랫동안 시행을 하여 문화로 자리를 잡아야 한다.

소스코드관리시스템에 소스코드를 올릴때는 버그ID(이슈ID)가 꼭 있어야 한다. 개발자가 원한다고 아무때나 마음대로 소스코드를 고치면 안된다. 개발자가 스스로 발견한 버그를 고칠 때도 버그관리시스템에 등록을 하고 고쳐야 한다.

이렇게 개발자가 생성한 모든 소스코드는 투명하게 모두가 볼 수 있게 한다면 이 혜택은 회사 뿐만 아니라 모든 개발자 그리고 본인에게도 돌아한다.

위기는 내부로부터 온다.

우리나라에서 소프트웨어 회사를 운영하기에 외적인 어려움들은 이미 많은 분들이 얘기를 해주셨습니다.

• 정권이 바뀔 때마다 급변하는 환경, 특히 대통령 따라 왔다갔다하는 여건들...
• 대기업과 중소기업간의 공정하지 못한 거래
• 대형 SI업체들의 횡포
• 공공기간을 포함한 고객들의 무리한 요구 및 낮은 가격

이런 것들은 천천히 얘기를 하고 오늘은 소프트웨어 내부적인 문제로 인해서 발생하는 위기에 대해서 얘기를 해보고자 합니다. 지금 소프트웨어 회사를 다니시는 많은 분들은 회사에서 항상 "위기다"라고 하는 말들을 들을 겁니다. 하지만 그 대부분의 원인을 "외부"에서 찾고 있는 경우가 많습니다. 물론 외부 환경도 기업을 잘 운영하는데 매우 중요하지만, 대부분 내부 원인은 간과하기 쉽습니다. 또한 말뿐인 위기가 아닌 진짜 회사가 어려워졌을 때 문제의 원인을 외부로 돌리는 경우가 많습니다.

단적인 예로 "티맥스"라는 국내 굴지의 소프트웨어 회사가 외부 요인때문에 어려워졌을까요? 나는 아니라고 봅니다. 내부 요인이 훨씬 더 컸다고 생각합니다.

우리나라 소프트웨어 회사들은 넘을 수 없는 벽이 앞에 존재하는 것처럼 보입니다. 강연이나 세미나에서 이런 문제를 얘기하면 작년만해도 "티맥스"라는 회사가 이 벽을 넘었다라고 주장하는 사람들이 있었지만, 이제는 그렇게 주장하는 사람이 없습니다. 우리가 기억하는 유명했던 수많은 소프트웨어 회사들 중에서 지금도 건전하게 꾸준히 성장하면서 글로벌 경쟁에서 뒤지지 않는 회사는 찾아보기 어렵습니다. 어떤 시기에 꼬꾸라졌거나 근근히 버티고 있거나 썩 나쁘지는 않지만 비전은 별로 없거나 합니다.

나는 이런 대한민국 소프트웨어 회사들이 맞닥드리는 "넘을 수 없는 벽"의 원인을 주로 소프트웨어 회사 내부에서 찾습니다. 소프트웨어 회사들이 주로 겪는 문제는 회사 조직이 커지면서 발생합니다. 조직이 커지면 이런 문제들이 발생합니다.

• 새로 채용한 개발자들에게 지식과 경험의 전달이 안됩니다.
• 개발자 인원은 많이 늘었는데, 생산성은 점점 떨어지고 야근만 늘어 납니다.
• 프로젝트 규모는 점점 커지는데 관리가 안됩니다.
• 국내에서는 꽤 경쟁력이 있는 소프트웨어였는데, 해외에서는 맥을 못춥니다.
• 초창기에는 좋은 아이디어들이 많았는데, 더이상 창의적인 아이디어가 나오지 않습니다. 
• 시장은 점점 레드오션으로 바뀌어서 수익성이 악화됩니다.

  이 모든 부작용이 거의 내부에서부터 나옵니다. 애초에 구멍가게 밖에 할 수없는 회사가 대부분이지만, 스스로는 그러한 사실을 알지 못합니다. 

개발자들도 스스로는 뛰어난 개발자라고 생각하지만, 코딩이나 좀 할 줄 알지 진짜 개발자들이 갖춰야할 능력이 무엇인지 모르는 경우가 태반입니다. 또한 관리자나 경영자는 소프트웨어에 대한 이해가 부족하여 마구 만들어서 많이 팔면 되는 것으로 착각을 합니다.

이러한 상황에서 우리나라에서 글로벌 경쟁력을 갖춘 소프트웨어 회사가 나오는 것은 거의 불가능합니다. 

하지만, 조금만 생각을 바꾸면 그리 어려운 일은 아닙니다. 소프트웨어 회사들이 조금씩만 바뀌고 좋은 저변이 확대가 되면 그중에서 분명히 성공하는 회사가 나올 겁니다.

소프트웨어를 잘 이해하고 있는 경영자가 점점 많아지고, 아무리 작은 회사라도 소프트웨어를 개발하는데 꼭 필요한 프로세스, 시스템, 문화등을 적절히 도입하고 이러한 환경에서 성장한 개발자들이 서로 혼합되면서 전체 소프트웨어 산업을 끌어올릴 수 있을 것으로 생각합니다.

그 첫걸음이 경영자와 개발자들의 소프트웨어 공학에 대한 이해입니다. 소프트웨어가 왜 그냥 마구 개발하면 안되는지, 어떻게 해야 적은 비용으로 짧은 시간에 품질 좋은 소프트웨어를 만드는지 이해를 하는 것이 시작입니다. 모든 경영자와 개발자가 이런 것에 관심을 가져줄 것으로 생각하지는 않습니다. 단지 그 비율이 조금씩 증가하기를 기대합니다.

Hotfix에서의 소스코드관리

아래 글에 차우차우님께서 Hotfix에 대한 질문을 해 오셔서 Hotfix에 대해서 좀더 자세히 설명하고자 합니다.

2010/05/03 - [기반시스템/소스코드관리] - 혼자서 개발을 하면 소스코드의 브랜치/머지가 필요없을까?

차우차우

2010/05/03 22:49

좋은글 잘 봤습니다. Hotfix가 많아질때의 대쳐방법이 궁금한데요 각 fix마다 해당하는 문제에 대한 fix만 만들면 될지 아니면 나중에 있는 Hotfix에 이전에 나온 hotfix를 모두 포함시켜야할지 판단하기가 어려울때가 있습니다. 그리고 각 Hotfix를 만들때도 버전관리시스템에 Hotfix에 대한 태깅을 해야하는지도 궁금합니다.

우선 Hotfix의 정의부터 알아봅시다. 회사마다 용어는 조금씩 다르게 쓰고 있으니 절대적인 정의는 아닙니다.

Hotfix란 "미리 계획되지 않은 긴급한 패치"를 말합니다.

계획된 일정이라는 것이 1년전부터 계획된 것인지 1주일된 계획인지는 회사마다 상황마다 다르고 Hotfix의 긴급도도 10분안에 해결을 해야 하는지 1주일 안에 해결해야 하는지 또 다릅니다. 하지만 이렇게 계획되지 않았지만 긴급하게 수정을 해야 하는 것을 hotfix라고 합니다.

일반적으로 Crash, Block, Security 이슈등으로 긴급하게 Hotfix를 내보냅니다.

Crash란 프로세스가 멈추거나 Database를 망가뜨려 시스템에 더이상 동작되지 않거나 데이터가 파손되는 상태를 말합니다.

Block은 설치가 안되거나 로그인이 안되는 등의 장애로 아무런 일도 못하는 상황을 말합니다. 

Security이슈는 보안에 문제가 생겨서 외부의 침입이 발생하고 있거나 위험한 상황을 말합니다.

여기서 Hotfix의 긴급성에 대해서 얘기를 하는 이유는 수많은 회사들이 긴급하지도 않은 버그(이슈, 기능)을 해결하고 Hotfix 형태로 릴리즈하는 것이 관행화되어 있기 때문입니다. 즉, Patch 일정을 계획하여 진행하지고 않고 그날 그날 개발자가 버그 수정해서 빌드한 후 그냥 고객에게 전달하거나 업데이트 서버에 올리는 것이지요.

그럼 Hotfix와 정식 패치의 차이점은 무엇인지 알아보죠.

Hotfix	정식 Patch
계획되지 않은 긴급한 패치 보통 충분히 테스트 되지 않고 릴리즈 또다른 문제를 일으킬 가능성이 매우 높음 다른 개발일정에 영향을 줌 고객은 수정된 버전을 바로 받아볼 수 있음	미리 계획됨 계획된 테스트를 수행하고 릴리즈 일상적인 수준의 리스크를 가지고 있음 계획된 일정대로 개발이 가능 고객은 개발사의 일정을 기다려야 함

즉 Hotfix 상황이 아닌데 Hotfix처럼 릴리즈를 하는 것은 정식 Patch의 장점은 모두 버리고 단점만 취하게 되는 겁니다. 유일한 장점은 고객이 개발사에 오전에 전화를 하면 오후에 새로운 버전을 보내준다는 것인데, 이것이 고객에게 장점일지는 생각해 봐야 합니다.

매일 정식 Patch를 내거나 하루에 몇차례 정식패치를 내는 회사도 있습니다. 대표적인 예가 Anti-virus 회사입니다. 이렇게 매일 릴리즈를 해도 정식 계획을 가지고 테스트를 수행하면서 릴리즈를 합니다. 따라서 매일 패치를 내보낸다고 Hotfix는 아닙니다.

개발사는 소프트웨어의 릴리즈 일정을 계획하여 진행을 해야 개발 일정을 안정적으로 가져갈 수 있으며 소프트웨어의 품질 수준을 일정하게 유지할 수 있습니다. 그렇지 않고 호떡집에 불난 모양으로 문제가 생기면 언제나 Fire fighting mode로 개발자가 알아서 불끄고 배포하고 하면 일정도 계획하기 어렵고 개발자들은 항상 야근에 시달리면서도 항상 품질 리스크를 안고 있으며 툭하면 더 큰 폭탄이 터지곤 합니다.

정식 패치 일정은 회사마다 다르므로 성격에 맞게 정의를 해야 합니다. 정식 패치 일정을 계획하여 실천하는데 최대의 "적"은 영업부서입니다. 영업부서에서는 이러한 Hotfix의 위험성을 잘 모르기 때문에 고객의 요구는 바로 들어주기를 원합니다. 따라서 정식 패치 일정은 회사의 규정으로써 정의를 해 놔서 무조건 따르게 하는 것이 좋습니다.

또한, Hotfix를 결정하는 위원회를 두는 것이 좋습니다. 위원회라고 하니까 거창하지만 개발의 대표들과 영업의 대표가 참석을 하면 됩니다. 거기서 영업은 Hotfix의 필요성을 주장하고 개발은 Hotifx의 문제점을 주장합니다. 그래도 Hotfix가 무리하게 나가게 될 경우 나중에 생기는 문제점의 상당부분 영업에게 도의적인 책임이 돌아가게 됩니다. 하지만 이러한 논의도 없이 그냥 Hotifx가 나가고 문제가 생기면 항상 모든 것은 개발자들이 독박을 쓰게 되어 있습니다.

Hotfix 소스코드관리

일단 Hotfix에 대해서 설명을 하느라고 사설이 길었습니다. 이제부터 Hotfix를 내보낼 때 소스코드 관리를 어떻게 하는 것이 좋을지 설명하도록 하겠습니다.

질문은 크게 두가지입니다.

1. 새 Hotfix에 기존 Hotfix를 포함해야 하는지?

2. Hotfix도 태깅을 해야 하는지?

정답을 먼저 말씀드리면 

1. 그때 그때 다르다.

2. Absolutely - 절대적으로

일단 2번이 답이 간단하므로 먼저 설명을 드리겠습니다. Tagging은 Baseline설정의 한 방법인데, 개발팀 바깥으로 나가는 모든 릴리즈는 Baseline이 설정되어야 합니다. 즉, 태깅이 되어야 합니다.

Baseline은 모든 변경의 기준선으로서 모든 릴리즈는 Baseline(태깅)으로 통제가 되어야 합니다.

그럼 개발팀 바깥이란 무엇일까요? 

테스트팀에게 테스트를 부탁하기 위해서 만들어 내는 빌드도 태깅을 해야 한다는 의미입니다.

이렇게 만들어진 버전은 버그 관리시스템에 등록이 되며 모든 버그, 이슈의 발생지의 이름이 되며 버그 수정의 기준이 됩니다. 

과거 CVS나 VSS등 1세대 소스코드 관리시스템은 Tagging(Label등)이 상당히 부담스러운 작업이었습니다. Tagging을 하면 소스코드를 그대로 복사를 하기 때문에 소스코드가 수백MB짜리 프로젝트를 할 때는 Tagging하는데 시간도 오래 걸렸고, 오래 쓰다보면 디스크 용량도 엄청나게 차지하곤 했습니다. 지금이야 Tera바이트 디스크를 쓰지만 과거에는 수백MB짜리 소스코드를 자주 태깅하는 것이 쉬운 일은 아니었습니다.

하지만 Subversion은 Tagging을 하는데 HDD 용량을 거의 쓰지 않습니다. 시간도 아무리 커다란 소스코드도 몇초면 끝납니다. 그래서 Tagging하는데 아무런 부담을 느낄 필요가 없습니다. 모든 정식빌드에 대해서 태그를 남길 수 있습니다. 여기서 말하는 정식 빌드란 개발자가 개발하면서 테스트를 하기 위해서 IDE(통합개발환경)에서 빌드하는 것을 제외한 공식적인 빌드를 말합니다. 엄밀히 말하면 공식빌드는 개발자의 일이 아니며 빌드팀의 업무입니다. 또한 별도의 빌드장비에서 이루어 집니다. 하지만 작은 회사라면 개발자가 겸업을 할 수는 있습니다. 그렇다고 하더라도 빌드장비는 필요합니다. 개발자 시스템은 더러운 환경(Dirty environment)이기 때문에 항상 일정한 빌드를 만들어 낼 수 있다는 보장이 없기 때문입니다. 개발자에게 이러한 일에 신경을 쓰게 하는 것보다 시스템을 하나 사주는 것이 훨씬 비용이 싸게 먹힙니다.

그럼 두번째 Hotfix간의 포함관계입니다.

Hotfix를 해야할만한 심각한 버그가 발생하면 Hotfix를 평가해야 합니다. 평가 항목은 다음과 같습니다.

1. 상세한 버그 내용
2. 버그에 영향을 받는 고객의 범위. 한 고객에게서만 발생한 것인지? 모든 고객에서 발생하는지?
3. 버그로 인해서 발생하는 고객의 예상 피해
4. 버그를 얼마나 빨리 해결해야 하는지
5. 고객의 피해로 인해서 발생하는 회사의 비즈니스적인 손해
6. 버그 수정에 투입해야 하는 인력 및 자원
7. 기존 개발일정에 미치는 영향

여기서 기술적으로 가장 신속하고 심각하게 고민해야 하는 것이 빨리 버그를 분석하여 광범위한 버그인지 특정 상황에서만 발생하는 버그인지 판단을 해야 합니다. 

Hotfix라는 것은 태생적으로 또다른 문제를 발생시킬 가능성이 대단히 높기 때문에 한 사이트에서만 발생하는 버그를 고치기 위해서 모든 고객에게 Risk가 있는 Hotfix를 배포하는 것은 좋지 않습니다. Hotfix가 미치는 범위는 가능하면 좁게 가져가는 것이 좋습니다.

이렇게 되면 결론은 나왔습니다. 

Hotfix들이 모든 고객이나 특정 고객 집단에서 광범위하게 발생한 것이라면 합쳐지는 것이 좋겠습니다.

그렇지 않고 소수의 고객에게만 서로 다르게 발생하는 문제라면 별도의 Hotfix를 만들어서 각각 배포를 하는 것이 좋겠습니다. 

또한 Hotfix를 배포한 후에 정식버전에 앞서 배포한 Hotfix를 모두 포함해야 하는지도 판단해봐야 합니다. 이또한 회사마다 상황이 다르기 때문에 입니다. 따라서 Hotfix를 일으킨 버그의 성격과 제품의 상황을 보고 판단해야 합니다.

소스코드관리시스템을 제대로 쓰지 않으면 이러한 여러 Hotfix의 관리도 불가능합니다. 하지만 소스코드관리시스템을 제대로만 사용한다면 매우 쉬운 일입니다.

Hotfix를 작성할 때 Branch및 Tag를 어떻게 만드는지 간단한 예입니다. Hotfix를 만들기 전에 Hotfix용 브랜치를 만든 후에 작업 완료후 Release할 때는 꼭 Tag를 만듭니다. 그리고 Hotfix간의 Merge는 Hotfix와 Trunk간의 Merge는 3Way Merge를 이용해서 거의 자동으로 할 수가 있습니다.

여기서는 소스코드관리시스템 관점으로만 설명을 했는 위의 모든 활동들이 버그관리시스템(이슈관리시스템)과 긴밀하게 연동이 되어서 진행이 되게 됩니다.

마무리

오늘 얘기 중에서 가장 중요한 메시지는 Hotfix는 함부로 남발하지 말자는 겁니다.

지금 모든 릴리즈를 Hotfix처럼 하고 있다면 Release 정책을 세워야 합니다. 

Hotfix남발은 비용이 더 많이 들뿐만 아니라 제품의 품질을 떨어뜨리고 개발자를 혹사하고 회사의 이미지도 깍아먹습니다. 영업이나 고객이 Hotfix에 너무 길들여져 있어서 바꾸기 어렵다면 정식 릴리즈 일정을 현재의 Hotfix일정과 비슷하게 가져가고 그 간격을 차차 정당한 수준으로 늘려가는 것이 좋습니다. 그래야 일주일에 몇번이라도 집에가서 식구들과 식사를 할 수 있지 않겠습니까?