-
반응형
팀 동료들과 이슈에 대한 이야기를 하면서 갑자기 이런 생각이 문득 들었다. 이슈를 분석하는 절차나 노하우를 정리하면 어떨까? 정리를 잘해놓으면 체크리스트처럼 이슈 분석시 시간을 많이 줄여줄 수 있지 않을까? 그래서 그 동안 사람들에게 배운 지식과 경험하면서 알게된 것을 토대로 정리를 하려고 한다. 물론 절대적인 기준이 있을거라 생각하지는 않지만 말이다.
여러가지 이유로 신규 개발건보다 제품 이슈 해결을 꽤나 오랫동안 해결해왔고 지금도 그 굴레에서 벗어나고 있지 못하고 있다. 어떤 면에서 재미도 있다. 문제의 원인을 찾았을 때의 짜릿함과 성취감이 크기 때문이다. 이슈 해결은 참 재미있는 문제 풀이지만 해결하지 못하면 야근의 요정을 만나는 지름길이다.
서론이 길었지만 이슈 해결을 하려면 일단 준비 단계가 필요하다.
준비단계: 이슈 트래커를 사용하고 있는가?
이슈 트래커에는 언제 어떠한 문제점이 발생했는지, 버전은 무엇인지 그리고 특이사항은 주로 무엇인가가 잘 기록되어 있어야 한다. 개인적인 생각으로는 1인 개발자라도 관리해야 한다. 나중에 1인이 2인이 되고 3인이 될 가능성이 있지 않은가. 이전에 생겼던 문제점이 다시 발생했을 때 똑같은 해결 아이디어가 떠오르긴 할까? 예전 발생한 문제점들에 대해서 고민을 했던 생각들과 기술 노하우들을 손쉽게 열람할 수 있게 되면 시간을 절약할 수 있다.
이슈 트래커에는 많은 정보들이 필요하지만 최소한으로 필요한 것들이 있다.
- 이슈 요약
- 날짜와 제품 버전
- 기대했던 동작과 현재 동작(문제점)
- 재현 시나리오
참고로 내용을 작성할 때 일어난 사실과 본인의 의견을 구별해서 적어야 한다. 사실과 의견을 섞어서 적어 놓으면 원인을 찾는 과정에서 길을 잃기 딱 좋다.
먼저, 이슈가 버그인지 아닌지를 판가름 해야 한다.
고객이 문제라고 바라보는 모든 것이 버그는 아니다. 자세히 살펴보면 우리가 가야할 방향과 맞지 않을 수도 있다. 버그가 아닌 것으로 판가름된다면 바로 고쳐야할 문제점이 아닌 다른 시점으로 이슈를 바라봐야 한다. 기능 추가 및 개선으로 다시 재 분류하고 회의를 열어서 논의를 해야 하기 때문이다. 고객이 생각하는 문제가 중요하지 않다는 것이 아니다. 기능 추가와 개선은 제품 컨셉, 방향성이 맞는지등을 고려해야 하기 때문이다.
버그인지 아닌지를 구별하기 위해서는 제품의 컨셉 그리고 제공되는 기능과 동작을 잘 알고 있어야 한다. 때론 제품 방향성과 맞지 않다면 거절할 수 있는 용기도 필요하다. 이래저래 전부 들어주고 고치게 되면 다른 고객이 와서 기능이 이상하다며 또 고쳐달라고 할 것이다.
일반적으로 버그가 아닌 것들은 당장 고쳐야할 사항은 아니다. 다른 기능추가/개선건들과 함께 일정을 잘 조율한다.
두번째로 중요한 것은 문제 재현이다.
모든 이슈는 문제 재현이 되면 대부분 쉽게 풀어나갈 수 있다. 지인 중에서 "재현만 된다면 문제는 이미 해결된 것이다"라고 말하는 사람이 있을 정도로 이는 매우 중요하다. 사실 재현만 되면 디버깅 코드를 넣어도 되고 이래저래 해볼 수 있는게 많다.
세번째, 다양한 로그를 수집하자.
원인을 파악할 수 있는 데이터는 많으면 많을 수록 좋다. 시스템 자원, 시스템 로그, 어플리케이션 로그를 특정 기간이상 보관하고 문제시 이를 수집하여 검토해보자. 갑자기 문제 시점에 cpu i/o가 치솟고 있었을지도 모른다. 간단한 문제들은 대부분 로그나 시스템 자원에서 원인을 찾을 수 있다.
네번째, 잘 동작하는 경우와 비교해보자.
문제 시점에 발생한 로그들을 분석해도 원인을 찾지 못했다면 그 다음으로는 잘 동작하는 경우와 비교하는 방법을 사용하자. 문제를 쉽게 풀어갈 수 있을 것이다. 문제들은 생각보다 특정 조건에서만 일어나는 경우가 꽤 많은 편이다. 패킷 덤프, 시스템로그, 클라이언트 또는 서버 조건을 수집해서 비교해보자. 그 안에 문제의 원인이 있을 것이다.
마지막으로 문제 해결 방법이 한개가 아니라는 것을 고려해야 한다.
문제를 해결하는 방법은 생각보다 다양하다. 100점이 아닌 80점짜리로 문제를 해결할 수 있다. 문제를 우회하도록 기능을 변경하는 것도 좋은 선택이 될 수 있다. 문제를 해결하는데 2~3달 걸리는 것보다 우회하도록 만드는게 문제를 더욱 빨리 해결하는 방법일 수도 있다. 물론 이렇게 생겨난 기술 부채들은 꼭 갚아야할 문제이다. 이런 문제점을 잘 관리하는 것도 개발팀의 역량이라 생각한다.
제품의 버전 관리를 잘하는 것 또한 필요하다. 생각해보면 운영 중 갑자기 문제가 일어나는 것도 있겠지만 버전 업그레이드(또는 기능 추가)를 한 이후에 이슈들이 많이 발생한다. 문제를 최대한 빨리 해결하면 좋겠지만 당장 수정이 어렵다면, 안정적인 이전 버전으로 되돌리는 것도 한가지 방법이다. 버전 관리에 대해서는 리눅스 커널 전략을 추천한다. 리눅스 커널에서는 mailline/stable/longterm으로 운영한다.
반응형