천 리 길도 한 걸음부터 RSS FEED

소비자의 품질 요구가 높아졌고 소프트웨어의 복잡도가 증가해서, QA가 어느때보다 더 중요해졌다. 왠만한 조직에는 다 QA 부서가 있고 그들의 목소리도 과거보다 커졌지만 여전히 품질은 개판인 경우가 많다. 물론 독보적인 품질의 제품을 출시하는 회사들도 분명히 있다. 이 차이는 어디서 오는걸까?

여러가지 원인이 있고 조직마다의 특수성도 있겠지만, 나는 QA를 All or Nothing으로 보느냐 아니면 부분으로 떼어 놓고 보느냐 하는 차이에 있다고 생각한다. 보통 QA 과정은 적용에 차이가 있겠지만, 다음과 비슷하다.

1. 테스트
2. 결과 리포트
3. 오류 수정

테스트 과정은 기능별로 자잘하게 잘려서 수천에서 수만개가 넘는 경우도 있다. 그리고 그 중에서 분명히 오류가 발견된다. 1000개중 1개의 오류가 발견됐다고 하자. 그리고 그 한 개의 오류를 수정했다. 그 다음 과정은 뭘까?

만약에 고친 오류 1개만 테스트하고 나머지 999개는 그냥 넘긴다면 그 조직은 탁월한 품질의 소프트웨어를 출시하기보다는 똥을 싸지를 확률이 높다. QA는 All or Nothing의 세계다. 999개 중에 단 1개라도 통과하지 못한다면 그건 전체의 실패이며, 전체가 실패했으니까 1개를 수정한 후에 다시 전체를 테스트하는게 맞다.

그러나, 이러한 전체의 실패 정책을 계속 고수하는 건 쉬운 일이 아니다. 특히나 외부의 압박이 심한 경우에는 더욱 더 그러하다. 게임 오베를 하면서 치명적 버그가 발견되면 그것만 고쳐 패치하고 싶은 마음이 안들면 그게 사람이겠는가? 누구나 그런 생각을 하지만 원칙이 아니라 기억을 더듬어 봐도 그런 경우는 언제나 더 큰 문제를 발생시켰다. 하나 패치했더니 두 개의 버그가 새로 생기는 그 아찔한 경험 말이다. 단 1초도 더 방치할 수 없는 치명적인 문제라면 코드를 최소한으로 건드려 (데이터만 수정해서 그 기능을 무력화 시킬 수 있다면 최고) 그 기능을 차단해서 일단 패치하고, 제대로된 과정을 거쳐 패치하는게 맞다.

이렇게 급한 상황에서 원칙을 지키려면 QA 부서는 절대로 타협을 해서는 안되고, 구성원 모두가 QA 부서를 존중해줘야 한다. 그렇지않다면 위에서 말한데로 똥만 싸지르다가 망하게 된다.

나로호 발사 연기가 사소한 소프트웨어 결함때문었다고 한다. 어제 9시 뉴스를 보니 사소한 소프트웨어 결함이고 이를 고치는데 3일정도가 걸려서 순식간에 다시 발사를 할 수 있다고 한다. 상식적으로 생각해도 우주선 발사 프로세스가 그리 간단할리가 없고 몇 백개의 테스트만 거치면 모두 통과하는 단순한 과정은 절대 아닐 것이라고 믿고 싶다.

첫 번째 우주 발사체 발사에 대한 주변의 압박은 매우 심할 것이다. 5000억 이상이 소요됐고 이미 7년이 걸렸다. 며칠 더 걸리는 것은 문제도 아니다. 압박에 굴복해 성급하고 축소된 QA로 발사를 단행해 진짜 큰 문제를 만들지 않기를 간절히 기원한다.

스크럼을 쓰다보니 그 기저에 깔린 사상은 예전에 도덕인지 윤리인지 모를 과목에 나왔던 북한의 자아비판과 다를게 없다는 생각을 하게 된다(요즘에도 도덕이라는 과목이 있을려나).

공개적인 자리에서 하찮은 이유로 일을 못했음을 알리는 수모와 굴욕은 자아비판과 다를게 없다. 그러나 세상 모든 일에 예외가 있듯이 이 굴욕적인 자아 비판이 대수롭지 않게 변할 수 있는 간단한 방법이 있다.

그것은 모든 참여자가 이 공개적인 자아비판을 단순한 과정으로 여기는 것이다. 못한 것도 과정, 그걸 자랑스럽게 말하는 것도 과정 그리고 어색하게 웃으면서 넘어가는 것도 한 과정이 되는 것이다. 모든 것이 이렇게 매너리즘의 한 요소가 돼 버리면 스크럼은 끝이라고 봐야하고, 데일리 미팅은 그저 시간 때우기에 불과하다.

우리가 보는 스크럼 책(애자일 관리서 포함)에는 이런 경우가 없다. 모든 참여자는 다 능력있고 책임감이 넘치며 자신의 무능력과 실수를 부끄럽게 여긴다. 그래서 그들의 스크럼에는 실패가 없지만, 현실은 그렇지가 않다. 처음에는 분명히 자신의 실패를 부끄럽게 여기지만 실패가 반복되면 더 이상 숨길 것도 없고 부끄러울 것도 없다. 그리고 그 과정을 바라보고 있는 동료들에게도 면죄부를 대량으로 발행하게 된다.

팀장(스크럼 마스터든 PM이든 뭐라고 부르든간에)이라면 이러한 과정의 진행을 그냥 바라보고 있어서는 안된다. 실패는 부끄러운 일이고 팀에 큰 악영향을 주고 있다는 사실을 계속해서 팀원들에게 주입 시켜야한다. 물론 이게 너무 공개적이 되면 비난이 되니 그 정도도 관리가 필요하긴하다.

클라이언트 테스터는 전형적인 producer-consumer 구조로 되어 있다. Consumer가 producer보다 몇 배나 빠르도록 설계 되어 있어 producer가 consumer를 압도하는 시나리오는 상상해보지도 않았고, 당연히 그에 대한 처리도 하지 않았다. 그런데 어제 테스트를 하고 있는데 부하가 심해지면 producer가 consumer를 압도하면서 queue를 가득 채워 뻑나는 황당한 경우가 발생했다.

Multi-thread 구조에 문제가 있는건 아닌지, 코드에 오류는 없는지를 하나하나 확인하고 있는데 원인은 황당하게도 printf 에 있었다. Consumer가 자기 할 일을 하고 간단한 정보를 출력하는데 그 일을 하면서 출력을 동기화하고 그 과정이 producer의 속도를 따라가지 못하게 된 것이다. printf를 빼니 모든 문제가 사라졌다-_-;;

(사실 printf로 console에 출력하는 행위 자체가 많이 느리기 때문에 printf에서 사용하는 lock이 문제였는지 출력 자체가 문제였는지는 정확하지 않다. 프로파일링을 해봐야 정확하지만 해서 도움도 안되고 시간만 잡아먹을게 뻔한 짓을 하고 싶지는 않다)

그러고 보니 예전에는 printf를 사용해서 출력하면 동기화가 안되서 출력이 섞이곤 했는데 - 그렇다고 기억이 되는데 정확하진 않음 - 최근에는 본적이 없다. 모르고 있었는데, 좀 황당하네.

결론: printf는 원래 성능이 구린데다가, 동기화하는데 성능이 구리다.
환경: VS2008SP1, Vista64

프로젝트를 진행하다보면 굴곡이 있게 마련이다. 잛게 보면 스프린트(이터레이션), 좀 더 길게 보면 마일스톤마다 작업 진행이 출렁거리게 된다. 바닥인 시작 지점에서 출발한 작업 효율(혹은 양)은 계속해서 상승하다가 대부분 종료 직전에 급강하하게 된다. 일을 정리하다가 그럴 수도 있고 큰 일 하나를 끝내 놓고 멍한 상태가 지속될 수도 있다. 그리고 다시 조이기전까지 그냥 시간을 보내는 경우가 허다하다. 현재 내가 참여하고 있는 있는 프로젝트는 스프린트가 끝나고 다시 시작하기 전의 리뷰/회고/계획 단계가 그렇다.

프로젝트를 진행하면서 낭비를 줄이고 효율을 높이는 다양한 방법을 논의 하지만 이 자투리 시간은 간과하고 넘어가기 쉽다. 그런데 이 시간이 결코 작지 않아서, 효율적으로 일해 번 시간을 여기다 다 날리는 경우도 종종 있다. 새 일을 벌리기에는 어중간하고 놀기에는 긴 이 시간을 어떻게 사용하면 좋을까?

난 스터디를 권한다. 그룹도 좋고 개인적인 공부도 좋다. "난 이 시간을 이용해서 1,000 페이지가 넘는 The C++ Programming Language를 다시 볼거야" 같은 장기적인 계획만 아니면 된다. 논문이나 짧막한 기사 한 두편 집중 공략하는게 가장 효과적이고 결과를 팀과 공유할 수 있다면 더욱 더 좋다.

스프린트에 혼신의 힘을 기울여 꿈틀거릴 힘도 안남아 있다면 모르겠지만 자투리 시간을 잘 활용하면 정말 많은 것들을 할 수 있다. 물론 이렇게 블로그에 글을 올리는 것도 가능하다. 중요한건 절대로 그냥 날려버리면 안된다는 것이다. 회사도 손해지만 결국엔 자기 손해니까.