계기
회사에서 일하다 보면 수많은 이슈를 마주하게 된다. 예를 들어 이미지가 안보인다거나 동시성 문제로 데이터가 이상하다거나… 그런 상황이 오면 당장은 DB를 수정하는식의 땜빵(?)처리를 해서 당장 해결할 수 있지만 그런식으로 문제해결을 반복하다보면 데이터 정합성을 지킬 수 없게 되고,똑같은 실수를 반복해서 DB 수정을 하고…의 악순환이 반복될것이다.
결국 중요한건 문제의 근본적인 원인을 찾아서 해결하고 재발방지가 중요하기 때문에 개발팀내에서 이슈 회고는 필수이다.
어? 이전에 비슷한 이슈는 어떻게 처리했지 😵💫?
전 직장에서는 슬랙으로만 이슈에 대한 히스토리를 남기고 따로 리뷰하는 시간은 없었다. 그러다 큰 규모의 프로젝트를 오픈하게되었고, 이슈가 한꺼번에 많이 발생하자 이 이슈는 예전에 어떻게 처리했었고, 저 이슈는 저번의 그 이슈랑 비슷했던것 같은데…어떤거였더라… 하는 상황이 많이 생겼다. 그 때 이슈회고의 필요성을 크게 느껴서 개발팀에서 일주일에 한 번씩 이슈회고하는 시간을 갖기로 했다. 그리고 이슈 회고할때 발표할 문서의 템플릿을 만들어 보게 되었고, 블로그에도 올리게 되었다.
이슈 문서
이슈 문서 만들기
템플릿은 아래와 같이 구성하였다. 이슈 최초 발견 시점부터 작성을 시작해 해결하기 전까지 모든 내용을 최대한 기록한다.
문제
발생한 문제를 설명한다. 최초 발견일을 같이 기록하면 더 좋다.
ex)
- 최초 발생일: 2022-04-26 17시 09분
- 에러 메시지: *** 목록 조회 중 에러가 발생
원인
-
가설
이 이슈가 발생한 원인에 대해 추측한다.
ex) a. federation에 실패했을 것이다. b. 불러오는 데이터가 많아서 타임아웃이 났을것이다. c. 쿼리를 잘못 보냈을 것이다. -
가설 증명
위에서 제시한 가설을 하나하나 증명해본다. 실험 보고서처럼 결과를 기록한다. 개인적으로 가설을 증명하는 과정에서 여러 자료들을 찾아보면서 배우는게 많았다.
ex) a. federation이 되는지 테스트 하기 위해 쿼리를 하나씩 넣어가면서 테스트함 → 테스트 결과, 아래 쿼리를 추가했을때 data가 null이 오는것을 확인함 ***-api에서 뭔가 문제가 있는것으로 추측됨 ... b. 불러오는 데이터가 많아서 타임아웃이 났을것이다. - 실제로 gateway에서 제한이 얼마인지 잘 모르지만 분명히 존재할 것이다. - 만약 타임아웃에러가 발생했다면 에러 로그가 존재할것이다. → 로그가 없음 ... c. 쿼리를 잘못 보냈을 것이다. - 쿼리를 잘못 보낸것이라면 page 1, page 2, ... 들도 작동되지 않아야함 -
결론
여러가지 가설을 증명하면서 문제의 진짜 원인을 찾는다.
ex) 존재하지 않는 content를 불러와서 federation에 실패했을 것이다.
해결
문제의 원인을 해결한 방법을 기록한다.
ex)
문제가 된 상품의 데이터를 삭제 처리
의문점
가설을 증명하는 과정에서 떠올린 의문점을 기록한다. 이렇게 의문점을 공유하면 다른 동료가 코멘트로 답변해줄수도 있다.
ex)
1. gateway에서 타임아웃이 나면 어떤 에러가 발생할까?
2. federation의 원리가 정확히 뭘까?
3. 방어 코드를 어떻게 만들 수 있을까?
...
느낀점
가설 증명 과정에서 느낀 좀 더 개선이 필요한 부분이나 반성한 점을 기록했다.
ex)
1. 로그를 좀 더 자세히 넣어야 할 것 같다.
2. 람다에서 query로 들고오는 과정 개선이 필요하다.
이슈 분류하기
이슈 회고를 작성하다보면 해결하지 못한 이슈도 있고, 해결한 이슈도 있다. 노션의 database 기능을 사용해 태그로 분류해주었다.
Completed: 해결한 이슈TODO: 인지하고 있지만 해결 못한 이슈
이슈 회고의 장점
이슈 문서를 많이 작성해본것은 아니지만 내가 느낀 장점은 크게 2가지이다.
- 이슈 회고 문서가 있으면 신규 개발자가 왔을때 히스토리 파악이 쉽다.
- 이슈 해결 과정을 팀원들과 공유하면서 최선의 결론에 더 가까워질 수 있다.