참조 문헌

안드레아스 젤러(Andreas Zeller) 저, Why Programs Fail:프로그램은 왜 실패하는가?. 류 광역, (주)사이텍미디어 p.036 ~ p.071

참조 링크

2장, 문제점 추적 내용

프로그램 문제점을 보고하고 , 관리 방법에 대한 설명과 문제점 관리 도구 소개가 주된 내용이다.

문제점이란 무엇인가?

프로그램 문제점이란 프로그램 결함의 결과이다. 내 경험으로 볼 때, 문제점 수정을 결함 수정에서 끝내지만, 책에서는 사용자에게 배포하기 까지를 문제점 수명 주기로 보고 있다. 또한 이게 맞다고 생각된다. 왜냐하면, 유저에게 전달하는 것 자체가 또 다른 문제이기 때문이다.

문제점에는 보고 ~ 해결 까지의 처리 공정을 가지고 있다. 이러한 처리 공정 때문에, 체계적으로 정리할 필요가 있다.

문제점은 어떻게 보고 하는가?

문제점을 보고 할 때는 말로 전달(보고)하는 것 보다 글로 전달(보고) 하는것이 더 체계적이다. 보다 체계적으로 전달 할 때는 문제점에 필요한 내용들만 포함 시키는것이 효과적인데, 보통 다음과 같은 정보이다.

  • 프로그램 릴리즈
    - 프로그램의 어떤 버전을 뜻한다.

  • 프로그램 운영 환경
    - OS를 뜻한다.

  • 시스템 자원
    - 프로그램이 실행된 환경의 램, 하드디스크, CPU 등을 뜻한다.

  • 문제 발생 과정
    - A 버튼을 누르고, B 버튼을 누르니까 문제가 발생됬다. 등의 재현 과정을 뜻한다.

  • 기대되는 결과
    - 일어났어야 하는 것들을 서술해야 한다.

  • 실제 결과(증상)
    - 미사일이 나가야 하는데, 안나간다.

  • 요약
    - 책에선 요약이 필요하다고 했는데, 경험적으로 그렇게 까지는 필요가 없더라. 하지만 유저가 쓴 내용을 정리 할 땐, 필요 하더라.
추가적으로 코어 덤프(core dump)나 로그 파일 등을 첨부 하면, 더 효과적이다. 이러한 파일 정보들을 유저가 제공해야 할 땐, 유저 동의를 꼭 구해야 한다. 왜냐하면 추가 파일 정보들을 제공하기 꺼려하는 유저도 있으며, 개인정보가 포함될 수도 있기 때문이다.

문제점은 어떻게 관리 하는가?

문제점이 많아지게 되면, 단순히 문서로 관리하는것은 불가능에 가깝다. 내가 보기에 제일 큰 이유는 기존 문제 찾기가 매우 어렵기 때문이다. 그러므로 이슈 트레커를 사용해야 한다. 대표적으로 무료로는 redmine, mantis, trac,bugzilla 등이 있다. 이외에도 무수히 많이 있이므로 "이슈 트래커" 라고 검색하자. 개인적으로 redmine 이 많이 쓸만했다.

그리고 문제점은 보다 체계적으로 관리하기 위해서 다음과 같은 기능들이 필요하다.
  • 심각도
    - 개선 요청(이런 기능이 있으면 좋겠다.), 사소함(오타, 정렬 등), 부차적(밑줄이 안거진다는 등), 보통(일반적으로 안되는 증상), 주요(주요 기능 안됨), 치명적(메모리 누수, 크래쉬), 차단(작업 자체가 안됨) 등이 있다.

  • 우선순위
    - 대체로 심각도에 따라 우선순위가 달라지지만, 기획이나 개발 공정에 따라 달라지기도 한다. (A 가 해결되어야 B를 할 수 있으므로, A 부터 해결해야 하는 경우가 비일비재하다)

  • 식별자
    - PR 번호, 즉 문제점 ID 를 뜻하는데, 문제를 바로 접근할 수 있어야, 전달이 용이하다.(그래야 메일/문제 연결 등이 용이해진다.)

  • 주석
    - 보고된 문제점에 더 추가할 수 있는 정보가 있다면, 더 좋기 때문이다.

  • 자동 통지
    - 문제점 변화에 따라 이 문제점에 관여한 사람에게 자동으로 전달 된다면, 변화 체크가 용이해진다.
대부분의 이슈트레커가 위에서 언급한 기능들을 지원하고 있다.

문제점은 어떻게 처리 되는가?

문제점이 보고 되면, 보통 다음과 같은 처리 과정을 거친다.
  1. 미확인:Unconfirmed
    - 문제점이 보고만 된 상태를 뜻한다. 

  2. 새로운 문제:New
    - 문제가 중복되지 않은 새로운 문제일 때, 이 상태로 변한다. 

  3. 할당:Assigned
    - 문제가 담당자에게 할당된 상태를 뜻한다. 

  4. 해결:Resolved
    - 문제가 해결된 상태를 뜻하는데, 해결에는 수정 완료, 문제 아님, 중복, 수정 불가 등으로 나뉠 수 있다.

  5. 재현 불가:works for me
    - 해보니까 난 잘되는데... 상태를 뜻한다.

  6. 해결 확인:Verified
    - 문제점 해결 된 것을 확인 완료 한 상태를 뜻한다.

  7. 닫기(종료):Close
    - 문제가 더 이상 존재하지 않는 상태를 뜻한다.

  8. 재발생:Reopened
    - 수정 완료 후 다시 문제가 재발한 상태를 뜻한다.
내 경험적으로는 3단계만 사용되며, "문제 보고, 문제 할당, 문제 해결" 이다. 위에서 언급한 나머지 상태는 3단계의 세부 항목으로 포함되거나, 사용되지 않는다. 상세하게 단계가 있는 것은 이슈 트래커 사용자에게 매우 부담(복잡)스러워, 사용하기에 불편하다.

문제점 추적 관리는 어떻게 하는가?

이슈 트래커 도입 후 사용하지 않는다면 이슈 트래커 도입 자체가 생산력을 매우 소모하게 된다. 이러한 경우는 중복된 문제점들이 무수히 올라오는 경우, 처리되지 않는 이슈들이 쌓이는 경우를 뜻한다. 그러므로, 각 단계별로 담당자를 정하는 것이 좋다.
  • 이슈 트래커 버전/기능 관리 담당자
  • 문제점 보고 정리 담당자
  • 문제점 심각도 분류 담당자
  • 문제점 우선순위 분류 담당자
  • 문제점 할당 담당자
  • 문제점 종료 담당자
  • 문제점 수명 주기 담당자
보통 내 경험적으로, 몹시 큰 규모가 아니라면, 이슈 트래커 관리자를 제외하고, 프로젝트 대표나 팀장이 책임자가 되고, 모두 다 하는게 좋다. :)

요구사항도 문제점으로 처리할 수 있는가?

아직 개발이 되지 않은 요구사항을 문제점으로 간주하고, 위에서 언급한 체계적인 분류로 나뉘면 된다. 이는 추적이 가능하고, 현재 상태를 확인 할 수 있으므로, 요구사항 진행 상태 추적에 매우 효과적이다.

실제로 이렇게 일을 처리해 보았다. 현재 어떤 일이 있고, 어떤 상태인지 확인이 쉬워서 매우 좋았다.

이슈 트래커와 SCM(형상 관리)과 연동 되는 것이 무엇을 의미 하는가?

어떠한 문제가 발생 했을 때, 그 문제를 재현 할 수 있는 실행 파일을 만드는 소스가 반드시 필요하다. 이슈 트래커가 SCM 과 연동 한다는 것은, 문제점에 대한 재현에 필요한 최소한의 도구가 존재한다는 것을 뜻한다.

경험적으로 이 연동을 해보지 못해, 불/편한지 모르겠다. 책 내용으로는 문제점과 수정코드를 연결하여, 자동화 하면, 이슈 트래커를 좀 더 효과적으로 사용 할수 있다고 나와 있다.(예를 들어 코드 수정 할 때, 주석으로 pr1000 해결 남기고 commit 하면, 자동으로 문제점 상태가 변하는 등)

여담
경험적으로 이슈 트래커는 반드시 필요하기에 최소한의 생산력 소모로 사용할 수 있는 방법을 꾸준히 생각해야 한다. 

:wq

  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 라이프코리아트위터 공유하기
  • shared
  • 카카오스토리 공유하기