Talk with Hani

cf) 물조리개, 새싹 이미지 from naver 이미지

팀장의 고백 목차

• 게으른 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 관계에 놓여 있다는 것을 전반적으로 인식했을 때 “고객은 품질에 관심이 많다”라고 말할 수 있습니다.

Rails의 새로운 Application, RightCart.com이라는 post를 올렸는데, jungtime님이 RightCart.com 아이디어를 RevU + 리뷰 블로거에 적용하면 좋을 것 같다는 댓글을 남겨 주셨다. 오~ 정말 괜찮은 아이디어라는 생각이 들었다. 이 아이디어를 제안서 형식으로 정리하는게 어떨까라는 생각이 들었다.

보통 SI 프로젝트에서 좋은 아이디어라도 고객을 설득하거나, 개발팀을 움직이기 위해서는 제안이나 혹은 기획 작업을 해야 한다. 이런 작업을 통해서 제안서나 기획안이 나오고 presentation을 통해서 고객과 관계자들을 설득하는(혹은 꼬시는) 작업을 한다. 물론 내 job은 기획이 아니기 때문에 기획서를 직접 작성해 본 적은 없으나, 새로운 프로젝트의 런칭을 위한 제안서는 많이 작성해 보았다.(하지만 많이 작성한다=잘한다는 의미는 아니다.) 그래서 RightCart와 정타임님의 아이디어를 합쳐서 제안서 비슷하게 작성해 봐야겠다고 생각했다. 그러나, 재미 삼아서 이 작업을 할려고 회사에서 사용한 제안서 작성 방식을 적용하면서, 암묵적으로 머릿 속에 있는 제안서 작성 방법을 정리해 보자는 생각이 들었다.

내가 사용하는 제안서 Agenda는 배경, 목적, 내용, 효과, 기간, 비용으로 구성 되어 있다. 회사에서 일반적으로 받아들여지는 잘된 제안서는 목차 별 핵심되는 문장을 뽑아서 한 문단 정도의 글로 만든 후, 제한된 시간동안 제안서의 메시지를 전달해서(엘리베이터 스피치 or 엘리베이터 테스트) 고객을 설득할 수 있어야 한다. 사실, 엘리베이터 스피치를 할 정도로 시간이 없다면 현실에서는 제안 발표 시간을 옮긴다. 하지만 엘리베이터 스피치가 중요한 이유는 제안서 내 시나리오를 발표자가 완벽하게 이해하고 있어야 한다는 것을 뜻한다. 결국 100페이지가 넘는 기획서나 수 십장의 제안서도 전달하고 싶은 것은 몇 문장으로 요약할 수 있기 때문이다. 즉, 실현 방법이 난해한 프로젝트라 하여도, 그 프로젝트를 통해서 얻을 수 있는 가치는 매우 간단하다.

글의 주제=제안서 핵심 가치

좋은 글을 쓰기 위해서는 많은 것들이 필요하다. 알맞은 단어 선택, 쉽게 읽을 수 있는 문장, 흥미를 유발 시키는 적절한 소재 선택 등등 좋은 글을 결정 짓는 요소는 무척이나 많다. 좋은 글을 작성하는 여러가지 요소 중 어느 하나 소홀히 다룰 수 없지만, 좋은 글을 쓰는 출발점은 글의 핵심인 좋은 주제를 선택하는 것이다. 한 문장으로 쓰여진 주제에 살을 덧붙여서 단편 소설이 탄생하기도 하고, 필력이 된다면 탄탄한 주제는 장편 소설이 되기도 한다. 마찬가지로 좋은 제안서의 출발점도 고객에게 전달할 가치다.(=제안서의 주제) 고객에게 줄 수 있는 가치가 명확하다면 발표자의 어깨에는 더 많은 자신감이 실리면, presentation 자료는 더욱 빛나게 된다.

계속…

Rails Day 2006이 시작 되었습니다. 총 183개 팀이 열혈 코딩 중입니다. 여기서 팀별 subversion의 실시간 changeset을 확인하실 수 있습니다. 지금 현재는 monkey patching 팀이 117번 변경으로 changeset 부분 1위입니다.(많이 바꾼다고 1등하는 것은 아니지만요.) 역시 참가팀 대부분이 미국이군요. 이런 (Rails만의, Rails Day 형식의)행사가 우리나라에서도 열리길 바라는 마음으로 눈팅하고 있습니다.