올해 새롭 게 꾸려진 우리 팀 은 Stable 버전 의 유지 보수 ( 버그 수정 ) 를 담당 하 고 있 다 . 개인 적 으로 오랫동안 유지 보수 일 도 해 왔 고 그 동안 쌓인 노하우 를 실험 해 보 고 싶 었 다 . 이런 저런 이유 로 새로운 목표 를 계획 했 는데 , 목표 를 그대로 적 기 에 는 배경 설명 이 길 어 지 니 요약 하 면 " 적 은 인원 으로 최대한 의 유지 보수 효과 내기 " 또는 " 유지 보수 비용 줄이 기 " 라 말 할 수 있 다 . 
 아래 는 목표 를 달성 하 기 위한 일부 내용 들 이 다 . 
 문제 재현 을 빨리 할 수 있 는 테스트 도구 를 만들 거나 현실 적 으로 고치 기 
 기존 에 만들 기 어려워 했 던 유닛 테스트 에 대해서 mock 을 활용 하 여 기본 틀 제공 하 기 
 이전 에 발생 한 주요 이슈 들 을 추적 해서 유닛 테스트 가 있 는지 검토 하 고 없 으면 신규 로 작성 하 기 
 주요 모듈 에서 발생 한 이슈 는 유닛 테스트 작성 을 강제 하 기 
 ( 잘 고쳐졌 는지 ) 코드 리뷰 하 기 , 테스트 하 기 , ( 유닛 테스트 가 작성 되 었 는지 ) 코드 리뷰 하 기 , . .. 
 나 는 유닛 테스트 를 맹신 하 는 편 에 속한다 . 테스트 코드 가 없 는 기능 들 에 대해서 테스트 코드 를 만들 다 보 면 코드 가 어떻게 동작 하 는지 더 자세히 이해 할 수 있 다 . 그 과정 에서 내재 되 어 있 던 문제 들 을 찾 은 경우 도 꽤 있 다 . Stable 코드 는 최소한 의 수정 으로 버그 를 고치 는 게 원칙 이 지만 문제 들 이 반복 적 으로 나타나 어쩔 수 없이 수정 을 많이 했 는데 결과 론 적 으로 는 꽤 잘 한 선택 인 것 같 다 . 
 제품 을 안정 화 하 기 위한 이런 한 시도 들 은 매년 어느 정도 는 계획 되 지만 우리 가 한 일 이 제품 에 어떤 영향 을 끼쳤 는지 정작 측정 을 하 지 않 는 것 같 다 . 그래서 이번 에 는 단순히 이슈 개수 를 줄이 는 것 을 넘 어 우리 가 노력 한 작업 들 이 긍정 적 인 결과 를 보여 주 고 있 는지 측정 하 기 로 했 다 . 
 mantis 이슈 트래커 
 우리 는 mantis 라는 이슈 관리 시스템 을 사용 한다 . mantis 는 이슈 를 등록 하 고 관리 하 는 데 좋 은 도구 이 지만 내 가 필요 한 통계 기능 들 은 부족 하 다 . 예 를 들 어 내 가 필요 한 정보 들 은 , 
 일 일 신규 이슈 개수 
 일 일 종료 된 이슈 개수 
 기간 에 따른 누적 신규 / 종료 이슈 현황 
 진행 중 인 전체 이슈 개수 현황 
 제품 버전 별 진행 중 이 슈 현황 
 팀 별 진행 중 인 이슈 현황 
 제품 버전 별 , 팀 별 진행 중 인 이슈 현황 
 이런 정보 들 인데 사람 이 일일이 수집 하 기 에 는 시간 이 아까운 작업 이 다 . 기간 , 신규 / 종료 된 이슈 , 팀 , 버전 이 통계 데이터 를 만드 는데 있 어 중요 한 단어 들 이 다 . 그 외 중요도 나 어떤 모듈 에서 발생 했 는지 를 더 하 게 되 면 조합 은 더 복잡 해진다 . MantisStats 이 란 plug - in 가 있 어 그걸 사용 해 볼까 했었 지만 결국 ElasticSearch 와 데이터 시각화 도구 인 Kibana 를 사용 하 게 되 었 다 . 내 가 적극 적 으로 Kibana 를 사용 하 는데 있 어 Elastic 을 이용 한 서울시 지하철 대시보드 글 이 동기 부여 가 되 었 다 . 
 또한 Inflearn 사이트 의 ELK 스택 ( ElasticSearch , LogStash , Kibana ) 로 데이터 분석 인터넷 강의 가 기본 감 을 잡 는데 충분 한 도움 이 되 었 다 . 댓글 에 도 남겨 두 었 지만 심심 한 감사 를 드린다 . 
 Elastic Search 로 데이터 수집 하 기 
 mantis 에서 필요 한 데이터 를 빼내 는 방법 은 어렵 지 는 않 았 지만 생각 만큼 쉽 게 풀리 지 도 않 았 다 . 당연히 RESTful webAPI 를 지원 하 나 했 지만 mantis 에서 는 SOAP webAPI 를 지원 한다 . 최신 버전 에서 도 SOAP 을 계속 지원 하 는 거 보 니 영원히 SOAP webAPI 만 을 지원 하 려나 보 다 . 
 그래서 , Python 으로 데이터 를 수집 할 수 있 는 스크립트 를 만들 었 다 . mantis 에 SOAP webAPI 로 접근 해서 필요 한 정보 를 가져오 는 동작 을 한다 . 또한 모든 이슈 정보 를 매번 가져올 수 없 으니 " Filter " 기반 으로 가공 된 데이터 만 갖 고 오 도록 설계 하 였 다 . 이 도구 는 github 에 등록 해 두 었 으니 필요 한 분 들 은 사용 하 시 길 . 
 https : / / github . com / morenice / mantisconnect - python 
 이렇게 가져온 데이터 는 REST webAPI 를 사용 하 여 ES ( Elastic Search ) 에 데이터 를 저장 한다 . ES 에 신규 이슈 / 해결 된 이슈 를 저장 하 기 위한 index 를 만들 었 고 , 별도 로 현재 진행 중 인 이슈 를 저장 하 기 위한 index 를 만들 었 다 . 매일 밤 11 시 에 오늘 신규 로 등록 된 이슈 와 해결 된 이슈 를 수집 해서 저장 하 고 , 현재 진행 중 인 이슈 를 따로 수집 해서 저장 하 도록 하 였 다 . 
 Kibana 를 사용 하 여 데이터 를 시각 화 하 기 
 첫 번 째 로 만든 대쉬 보드 는 " 일 일 이슈 정보 " 묶음 이 다 . 버전 별 , 팀 별 , 이슈 현황 에 대한 상세히 알 수 있 다 . 히트 맵 을 사용 하 면 특정 팀 이 어느 버전 이슈 가 많 은지 손쉽 게 식별 할 수 있 다 . 참고 로 팀 이나 제품 관련 된 용어 들 은 모자이크 처리 를 하 였 다 . 
 두 번 째 로 만든 대시보드 는 기간 별 로 살펴볼 수 있 게 만들 었 다 . 이 그래프 는 꽤 의미 가 있 다 . 우리 가 유지 보수 하 는 버전 의 이슈 개수 가 줄어들 고 있 고 , 신규 로 등록 되 는 개수 가 점차 적 으로 줄어들 고 있 어야 우리 가 계획 한 일 들 이 의미 있 는 일 인지 가늠 할 수 있 기 때문 이 다 . 
 우선 왼쪽 파란색 라인 그래프 를 보 면 " 진행 중 이슈 " 개수 가 꾸준히 줄 고 있 음 을 확인 할 수 있 다 . 
 오른쪽 누적 그래프 에서 는 노란색 부분 이 " 신규 등록 " 이슈 개수 를 의미 하 는데 점차 완만 해져야 한다 . 
 3 월 부터 도입 했으니 약 4 개월 정도 측정 한 것 인데 , 현재 까지 는 괜찮 은 결과 를 보여 주 고 있 긴 하 지만 생각 보다 측정 기간 이 짧 은 편 이 긴 하 다 . 올 하반기 까지 는 꾸준히 실험 하 고 측정 및 회고 를 통해서 최종 결론 을 내려야 하 지 않 을까 싶 다 . 
 Elastic 제품군 은 데이터 저장 과 시각 화 및 분석 을 무료 로 이용 할 수 있 다는 점 이 대단 한 것 같 다 . 네트워크 데이터 와 DB 정보 를 수집 하 여 시각 화 할 수 있 는 PakcetBeat 또한 제공 된다 . 무엇 을 저장 하 고 어떤 정보 를 시각 화 할 것 이 냐 에 대한 고찰 이 좀 필요 하 지만 나머지 부분 은 기술 적 으로 어렵 지 않 고 웹 에서 많 은 사례 와 예제 들 을 구할 수 있 는 장점 이 있 으니 실험 적 으로 도입 해 보 는 것 을 추천 한다 . 
 Elastic Search , kibana , Mantis