Talk about Software with hani

팀장의 고백 목차

• 게으른 PL이 프로젝트 일정을 지연시킨다.
• 개발명세서? 그 귀찮은 짓을 왜 하지?
• 개발계획은 팀장의 것? 팀원의 것?
• 팀장! 당신은 진정한 Nego를 할 수 있는가?
• 형상 관리, 그까이거 그냥 폴더에 보관하면 되지 1부
• 형상 관리, 그까이거 그냥 폴더에 보관하면 되지 2부
• Trac을 통한 품질 관리
• UnitTest! 미완의 시도
• 인수테스트, 북치고 장구치고 1/2 (오늘의 post)
• 인수테스트, 북치고 장구치고 2/2
• 진정한 프로젝트의 가치는 어디에서 오는 것일까?

테스트를 대하는 우리의 자세

개발이 시작되면, 수 많은 테스트를 합니다.(정확히 말하면 해야 한다고 말하죠.) 단위 테스트, 통합 테스트, 성능 테스트, 부하 테스트, 인수 테스트 등등… 제 경우를 보면 프로젝트를 진행하면서 직접 해 본 테스트도 있고, 하면 좋지만 여건상 해 보지 못한 테스트도 있습니다. 이 글을 읽는 여러분들도 정도의 차이가 있을 뿐, 해 본 테스트도 있고 해 보지 못한 테스트도 있을겁니다. 여기서 질문 하나 하겠습니다. “우리는 왜 테스트를 해야 할까요?” 너무 뻔한 질문인가요? 어떤 질문이 뻔하다는 생각이 들 때는 크게 두 가지 경우로 나누어 볼 수 있습니다.

1. 질문 수준이 낮다.
2. 일반적인 상식을 갖춘 사람이라면 똑같은 대답을 한다.

1의 카테고리에 속한 것은 “1 더하기 1은 몇이지?”와 같이 초등학생에게 물어 볼만한 질문입니다. 이에 반해 2의 카테고리에 속한 질문은 (제가 처음에 드렸던) “우리는 왜 테스트를 해야 할까요?”처럼 특정 분야에 속한 사람들에게는 1의 카테고리에 속한 것 같은 질문입니다. 즉, 중급 개발자에게 “왜 테스트를 하시죠?”라는 묻는 것은 고등학생한테 “1 더하기 1은 몇이지?”라는 물음을 던지는 것과 비슷합니다. 따라서 ego가 강하거나, 성격이 급한 개발자에게 이런 질문을 했다가는 넋나간 PL 취급 받기 쉽습니다.

• 질문자 : 1 더하기 1은 몇이지?
• 답변자 :  2
• 질문자 : 해는 서쪽에서 뜰까? 동쪽에서 뜰까?
• 답변자 : 동쪽에서 뜨지
• …
• 질문자 : 테스트는 왜 할까?
• 답변자 : 버그를 찾기 위해서
• 답변자 : 도대체 이런 걸 왜 묻죠?

그러나 조금만 더 고민해 보면 1, 2 카테고리를 나누는 기준은 답변자의 수준을 나누는 것일 뿐, 두 카테고리를 관통하는 공통된 화두가 있음을 알 수 있습니다. 즉, ’당연함’입니다. 해가 동쪽에서 떠서 서쪽으로 지는 것을 당연하게 여기고 물이 높은 곳에서 낮은 곳으로 흐르는 것을 자연스럽게 받아 들이는 것처럼, 개발팀은 개발 기간동안 테스트를 하는 것을 당연하게 여깁니다. 그러나 이런 인식 속에서 현실을 한꺼풀만 베껴 보면, 우리가 테스트에 대해서 갖고 있는 당연함은 허울뿐인 인식이였음을 알게 됩니다… 단위 테스트를 한 객체보다 안 한 객체가 더 많고, 부하 테스트는 오픈 후 사용자를 대상으로 하고, 인수 테스트는 한 두 명의 고객에게 시스템을 설명한 것으로 넘어갑니다…  즉, 개발 프로젝트에서 테스트의 현실과 인식 사이에는 “테스트는 당연히 해야하는 것”이라는 믿음의 크기만큼 큰 괴리가 놓여져 있습니다.

뻔한 질문에 뻔한 대답, 그러나…

이런 현실과 인식의 부조화는 어디에서 생긴걸까요? 많은 원인을 찾을 수 있겠지만, 아래와 같이 크게 네가지 정도로 원인을 grouping해 볼 수 있습니다.

1. 고객이 요구하는 품질 수준이 낮다.(혹은 기준이 없다.)
2. SI회사에서 S/W 품질 인식 수준이 낮다.
3. 프로젝트 수주 단가가 낮다.
4. 테스터는 전문 직업이 아니다.(테스트는 개발자의 부업무다!)

위의 각 항목은 항목간의 연관성이 높습니다. (대부분은 아니지만)고객은 “되냐 안되냐”에 높은 관심을 보이는 반면, 품질에는 관심이 거의 없습니다.[주1] 따라서 고객의 품질 수준이 낮기 때문에 프로젝트를 수주한 회사 입장에서 자연스럽게 프로젝트의 품질보다는 “되냐 안되냐”에 높은 우선 순위를 부여합니다. 또한 프로젝트 수주 단가도 낮고, 갑을병정으로 하청이 내려 가다 보면 실제 프로젝트에 투입되는 공수로는 전문 테스터를 팀원으로 둘 수 없습니다. 따라서 테스트는 개발자의 부업무가 됩니다. 그러나 단위 테스트나 통합 테스트를 제외하고, 나머지 테스트는 전문 테스터가 수행해야 하는 전문 분야임을 누구나 다 알고 있습니다. 그러나 현실의 프로젝트 비용으로는 제대로된 개발자를 구하기도 쉽지 않습니다. 이런 현실 속에서 품질을 지키는 테스트는 개발의 언저리로 밀려 나가고, “되냐 안되냐”의 사명을 부여 받은 개발자는 제대로된 검증 한번 받지 않은 코드를 양산해 냅니다.(물론 이런 현실은 SI 프로젝트에서 더욱 드라마틱하게 연출되는 면이 있음을 부정할 수 없습니다.)

그렇다면 이런 암울한 현실 속에서 우리가 할 수 있는 일은 무엇이 있을까요? 결국 한 그루의 사과 나무를 심는 스피노자가 될 수 밖에 없습니다. 상자 안에 자갈과 모래를 많이 담기 위해서 자갈부터 넣어야 하듯이, 문제 해결 시 효과를 극대화하기 위해서는 문제의 핵심 원인을 해결해야 합니다. 그러나 프로젝트 팀원이 테스트를 하기 위해서 반드시 확보해야 하는 리소스는 상자 밖의 문제입니다. 즉, 프로젝트 수주 단가를 현실화해야 하고, 갑을병정으로 이어지는 하도급 관행을 개선해야 하며, S/W 품질에 대한 인식을 높여야 합니다. 그러나 이런 큰 문제점들은 하루 아침에 해결할 수 있는 문제가 아닙니다. 그렇다고 이런 문제점들이 해결될 때까지 아사 상태에 놓여 있는 프로젝트의 품질을 방치해 둘 수도 없습니다.

따라서 프로젝트 팀원으로써, 품질을 높이기 위해서 실천할 수 있는 작은 practice를 하나씩 풀어가는 꾸준한 인내가 필요합니다. 귀찮더라도 단위 테스트를 하고, 고객이 거부한다는 이유로 몇 마디 설명회로 넘어가던 인수 테스트를 해야 합니다. 하루에 1cm씩 앞으로 나가는 진보 속에서 멀게만 보이던 상자 밖의 문제에 접근할 수 있기 때문입니다.

다음 post “인수 테스트”를 기약하면서, 오늘의 post를 마칩니다.

[주1] : ”높은 품질이면 좋다”는 “고객은 품질에 관심이 많다”와 같은 의미가 아닙니다. 품질을 높이기 위해서는 비용이 수반되고, 높은 품질은 기능 수와 (어느 정도) trade-off 관계에 놓여 있다는 것을 전반적으로 인식했을 때 “고객은 품질에 관심이 많다”라고 말할 수 있습니다.

This entry was posted on Wednesday, June 21st, 2006 at 11:36 am and is filed under software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.