SW품질에 대한 오해를 바로 잡고 보다 효과적인 대안을 제시합니다, SW개발 과정에서 품질을 저하시키는 주요 원인인 지킬 수 없는 "Deadline"의 문제점을 설명 하며 데드라인이 지켜지지 않는 이유와 이를 해결할 수 있는 방안을 제시합니다. 또한 좋은 품질의 소프트웨어를 개발하기 위해 필요한 조직 문화의 문제점과 해결책도 설명 합니다.

1. Riot Games
유석문
Inconvenient Truth
An

2. 이야기
Communication
Culture
Deadline
Conclusions

3. Deadline
추측할 수 밖에 없는 상황에서 정확성을 고집하지 않는 태도는 지식인의 표시다.
- 아리스토텔레스[Aristoteles, BC 384 ~ BC 322]

4. Uncertainty Principle - I

5. Uncertainty Principle - II
 QA 업무의 특징 및 문제점
• QA 범위와 QA 기간을 동시에 정확히 알 수 없다.
• QA 범위를 정의 하면 QA 기간이 불명확해 지며, QA기간을 확정하면
QA 범위가 불명확해진다.
• 아무리 노력해도 줄일 수 없는 QA기간의 임계값이 존재
• 초기 투입 인원 대비 인력을 늘리는 경우에도 Communication에 의한
손실로 인하여 줄일 수 있는 기간에 한계가 있으며 때로는 인력 투입으로
인해 기간이 더 늘어난다.

6. Uncertainty Principle - III
 Seok’s Suggestion(Not Suck !)
• 목표 QA 범위와 기간 중 하나를 선택 한다.
• 한가지가 고정되면 다른 한가지를 추정 하고 보정 할 수 있는 예측
시뮬레이션을 활용 한다.
• WBS 가중치 방법 등
• 업무의 규모 및 특성에 맞는 적당한 투입 입력수가 존재 한다
• 통계 데이터를 수집 하고 분석하여 최적의 값을 찾아야 한다
• 조직에 가장 잘 맞는 시뮬레이션 모델을 개발 하고 발전 시켜 나가야 한다

7. 적절한 QA 기간?? - I
 개발팀 설문 조사 결과
• 2주
 왜 2주일까?
• 1주라고 말하기엔 짧은 것 같고 빨리는 끝났으면 좋겠고….
• 제품 규모에 따른 기준 QA 기간 부재
• 개발팀은 QA 시작 시점에 QA가 자신들과 동등한 수준의 제품 정보를
가지고 있는 것으로 생각 하는 경우가 많음 (자신들이 알기 때문에 남들도
알고 있는 것으로 착각)

8. 적절한 QA 기간?? - II
 Seok’s Suggestion (Not Suck !)
• 제품 규모별 QA 기간에 대한 데이터 수집 및 제공
• Iteration을 통한 QA 기간의 수렴 값을 결정 하여야 한다
• 개발팀 또는 기획팀에 의한 QA 기간 산정 금지
• QA 기간은 품질 목표에 맞추어 추정 되고 변경 되어야 한다.

9. 적절한 QA 기간?? - II
 Seok’s Suggestion (Not Suck !)
• 개발 프로세스 끝 단에 한정된 QA 활동을 상위로 이동
(Moving Quality Upstream)
• 개발 과정 초기부터 참여 하여 개발자와 동등한 수준의 제품 정보를
가져야 한다.
• 제품 개발 단계에 맞추어 테스트가 수행 되어야 한다.
• 위의 모든 조건을 만족 시킬 경우 프로세스 끝 단의 QA기간이 2주일
수도 있다.

10. Deadline은 왜 지킬 수 없는가?? - I
 테스트 범위 및 품질 목표는 늘 변화 되며 상향 조정 되는
경향을 갖는다.
• 테스트 시작 후 이해도가 증가 할 수록 업무 범위가 늘어남
• 특정 오류로 인하여 추가적인 테스트가 불가능한 상태 발생
• 테스트 수행 중 오류 수정 모듈에 대한 Regression Test
수행 기간이 반영 되지 않음 (동시에 여러 개의 패치를
테스트 하고 있는 상황이 자주 연출 됨)
• Deadline은 고정이지만 요구사항은 고정되지 않는다.

11. Deadline은 왜 지킬 수 없는가?? - II
 Seok’s Suggestion (Not Suck !)
• Agile Practice인 Incremental Implementation을 이용
• 테스트 수행 결과를 이용하여 Deadline을 예측 하여 보정 하여 나감
• 최소한의 QA 기간이 보장 되어야 함

12. The Management Paradox - I
 프로젝트에 대하여 최우선적으로 파악 해야 할 것은?
• 일정

13. The Management Paradox - I
Data가 없을 때 선택 할 수 있는 관리 방법은?

14. The Management Paradox - II
 독재와 무의미한 칭찬 만으로 얻을 수 있는 것은 반감 뿐이다.
• 일정을 목표로 한 관리 방법 지양
• 적절한 방법을 통한 Data의 축적 및 활용 (예: Agile Practices)

15. Culture
No culture can live if it attempts to be exclusive.
- 마하트마 간디[Mohandas Karamchand Gandhi , 1869.10.12 – 1948.01.30]

16. 한국에는 너클볼 투수가 없다 - I
 너클볼의 정의
• 투수가 던진 공이 거의 회전하지 않고 홈플레이트(home plate)에서 예측
불가능하게 변하는 특성을 갖는 구질

17. 한국에는 너클볼 투수가 없다 - I
 너클볼의 장점
• 공을 세게 던질 필요가 없다 (세게 던지면 회전이 발생 하여 안됨)
• 정통파 투수에 비하여 피로가 덜하여 더 많은 이닝을 소화 하며 자주 등판 할 수 있다.
• 활동 기간이 길다 (40대에도 왕성 하게 활동 한다)
 너클볼의 단점
• 익히기가 어려우며 오랜 시간이 걸린다
• 너클볼을 받을 수 있는 포수가 드물다
• 기술이 완성 되기 이전에 사용 하면 난타를 당할 확률이 높다 (평균 구속 100Km 이하)
• 기술이 완성 되기 까지 기다려 주는 지도자가 드물다

18. 한국에는 너클볼 투수가 없다 - II
 QA 업무의 특징 및 문제점
• 긴박하고 짧은 Deadline 상황 에서 업무가 진행 된다
• 새로운 기술을 익히고 성숙 하게 만들 시간적 여유가 없다
• 새로운 기술에 대한 관리자의 믿음을 얻는 것에 실패할 확률이 높다
• 몸으로 때울 수 있는 다양한 방법이 있다
• 정말 부지런 하고 손이 빠른 사람이 많다

19. 한국에는 너클볼 투수가 없다 - III
• Seok’s Suggestion (Not Suck !)
• 신기술 습득을 장려 하는 조직 분위기 확립
• 신기술 적용에 의한 단기간의 실패를 인정 하고 실패로부터 배울 수 있는 문화
확립 (실패를 비난 하는 분위기에서는 절대 개선 불가능)
• 외부에 의하여 실현 불가능 하게 주어지는 Deadline이 아닌 QA 담당자가
현실적으로 가능한 Deadline을 잡을 수 있는 환경 및 프로세스
• 담당자들의 신기술 습득을 위한 끊임없는 노력 (빠른 손은 30대만 되어도
느려지기 시작 한다)
• “예전부터 이렇게 잘 해왔어” 이 말 제발 하지 맙시다.

20. Sinking Boat - I
 증상
• 급한 일을 진행 하느라 중요한 일을 하지
못함
• 인력을 늘려 보지만 급한 일은 더 빨리
증가 함
• 물 퍼내다 지쳐 멈추면 다 같이 빠져 버림

21. Sinking Boat - II
 Seok’s Suggestion (Not Suck !)
• 급한 일과 중요한 일 사이의 조화 필수
• 전체 업무에서 반드시 중요한 일을 진행 하는 비율 설정
• 중요한 일의 비율을 급한 일보다 작게 설정 할 수 있지만 0이 되어서는 안됨
• 급한 일이 일정 비율을 넘어서게 될 때 더 이상의 업무 할당이 되지 않는 문화 정착
• “이게 하던 방식이야” 말하지 않기

22. Negative Metrics - I
 정의
• 정의된 Metric 중 징벌적인 용도로 사용되는 모든 Metric

23. Negative Metrics - II
 영향
• QA의 업무를 Defect Detection 수로 관리 할 경우 QA는 Defect detection부분에 역량을 집중
하게 된다.
• 불행히도 Detection 에 집중 하면 개발프로세스에서 defect는 감소 하는 것이 아니라 증가 하는
경향이 있다.
• QA는 Quality에 집중 하지 않으며 Defect의 수에만 집중 하게 된다.
• 발견되기 쉬운 Defect들만 보고 되며 치명적인 Defect은 사용자가 발견 한다.
• 개발자들은 Defect을 은폐 하려는 경향을 갖게 된다 (코드 라인 수를 증가 시켜 오류 비율을 낮춤)
• 개발자들과 QA간의 상호 불신이 확대 된다

24. Negative Metrics - III
 Seok’s Suggestion (Not Suck !)
• 어떠한 Metric도 비난의 목표나 수단이 되어서는 안됨
• 특정 Metric의 수치적 개선을 목표로 삼지 않고 Metric의 본질적
목표를 이해 하고 이용 어떠한 Metric도 사용 의도에 따라 Negative
Metric이 될 수 있음을 명심

25. 눈치만 보는 - I
 경향
• 어떠한 의견도 개진 하지 않음
• 스펙 등 중요한 커뮤니케이션 내용이 잘 못 된
경우에도 이야기 하지 않음
• 잘 못 된 부분을 발견 하여도 절대로 이야기 하지
않음
• 자기 방어가 필요한 경우에만 열정으로 대화에
참여함

26. 눈치만 보는 - II
 원인
• 독재자에 의하여 지배 당할 경우
• 나만 모른다는 불안감
• 이야기 함으로써 자신이 공격의 대상이 되지
않을까 하는 불안감
• 추가적인 일을 더 만들게 되지 않을까 하는
불안감
• 자신과 관련된 업무가 아니기 때문

27. 눈치만 보는 - III
 Seok’s Suggestion (Not Suck !)
• There are no Dumb Questions
• 어떠한 의견도 경청되는 조직 문화 정착 (Freedom for Everyone)
• 개인이 의견을 표현 할 수 있는 다양한 채널 제공
• 내가 모르면 남들도 모른다. (자신감 필수, 집단 지성의 활용)

28. 압력, 야근 그리고 끓는 물 속의 개구리 - I
 압력과 납기일의 상관 관계에 대한 오해
• 압력을 가하면 납기를 어느 정도 단축 할 수
있다.
• 어느 정도의 효과 라는 것도 무시 하지 못할
정도의 수준이다.
• 그러므로 압력을 사용 하는 것은 적절한
방법이다.

29. 압력, 야근 그리고 끓는 물 속의 개구리 - II
 야근의 진실
• 압력이 가해지면 야근이 증가 한다.
• 야근이 많아 지면 정상 근무 시간을 낭비 하고 야근 시간에 해결 하려는 경향이 나타난다
• 야근을 통하여 업무 지연에 대한 책임을 회피 한다. (나 이렇게 고생 하니까 뭐라 하지마!)
• 야근을 통하여 추가적인 업무 할당에 저항한다.

30. 압력, 야근 그리고 끓는 물 속의 개구리 - II
 끓는 물 속의 개구리
• 업무가 과도 하게 주어지면 담당자는 추가
적인 업무 할당에도 반응 하지 않게 됨
• 할 수 있는 업무량을 벗어 났으므로 추가된
업무량이 아무리 많더라도 신경 쓰지 않게 됨
• 어느 순간 Burnout 되어 버림

31. 압력, 야근 그리고 끓는 물 속의 개구리 - II
 Seok’s Suggestion (Not Suck !)
• 근무 시간에 집중할 수 있는 환경 조성
• 야근을 근면과 혼돈하지 말 것
• 야근을 보상의 대상으로 삼지 말 것
• 야근은 필요 악이 아닌 그냥 악임을 인식할
것

32. Communication
The greatest problem in communication is the illusion that it has been accomplished.
- 조지버나드 쇼[George Bernard Show , 1856.07.26 - 1950.11.02]

33. Fortress - I
 정의
• 비밀 주의 또는 혼자 다해야 직성이 풀리는
특성을 가진 사람
 특징
• 단독 작업으로 인하여 업무에 오류 개입 될
확률 높음
• 협업 문제
• 당사자 이직 시 문제 발생

34. Fortress - II
 원인
• 강한 자의식
• 비난 받을 수 있다는 두려움
• 실패에 비난 하는 조직 문화에 의한 영향이 많음
• 독재자 밑에서 일을 하고 있는 경우
• 동료에 대한 신뢰 부족
• 협업 관계가 아닌 경쟁 관계로 인식
• 자신이 아는 것 만을 최고의 가치로 생각
• 나도 이렇게 배웠어…

35. Fortress - III
 Seok’s Suggestion (Not Suck !)
• 개인이 업무를 독점 하지 못하도록 제도화
• 협업에 대하여 보상하는 문화
• 실패를 비난 하지 않으며 실패로부터
배우는 조직 문화
• 상대방의 불안감을 인지 하고 공감
• 자발적으로 성 밖으로 나오도록 유도

36. Pair Programming - I
 안 하는 또는 못하는 이유
• 둘이 한가지 일을 하면 능률이 떨어질 것이라는 선입견
• 둘이서 한 가지 일을 같이 하면 논다는 주변의 인식
• 서로 감시 한다는 느낌
• 혹시라도 망신 당하지 않을까 하는 두려움
• Pair Programming을 할 수 없는 좁은 책상
• 대화를 하며 업무를 진행 하면 타인에게 방해가 되는 환경

37. Pair Programming - II
 Seok’s Suggestion (Not Suck !)
• Pair Programming을 할 수 있는 물리적 환경 지원
• Pair Programming 시간을 업무에 명시
• 협업에 대한 보상
• 팀원 간의 신뢰 및 비난 하지 않는 문화

38. Conclusions
There is no greater mistake than the hasty conclusion that opinions are worthless
because they are badly argued.
- 토마스 헉슬리[Thomas Henry Huxley , 1825 - 1895]

39. 사심이 많이 포함된 결론
• 무릎이 닿기도 전에 알 수 있는 방법은 없다.
• 성벽 허물기
• 소통하기
• 다양한 문화의 Melting pot
• 진화 하는 조직

40. Q&A