리브랜딩으로 관리자 콘솔을 새로 만들게 되어 기능 목록을 코드에서 뽑았다. grep -c '@GetMapping\|@PostMapping' 으로 컨트롤러의 공개 함수를 세니 백여든 개가 넘었고 그것을 다 옮기면 되는 줄 알았다.
Table of contents
Open Table of contents
증상 — 코드에서 뽑은 목록의 한계
@GetMapping 목록을 보이자 절반은 안 쓴다는 답과 여기 없는 것이 하나 있다는 답이 함께 왔다. 코드에서 뽑은 목록은 만들어진 것을 말할 뿐 쓰이는 것과 필요한 것을 말하지 않는다.
두 방향으로 어긋난 셈이다. 목록에는 있는데 안 쓰는 것과 목록에 없는데 필요한 것이 동시에 있었다.
측정 — 로그가 센 실제 사용
Kibana 에서 nginx 접속 로그를 경로별로 세니 자주 쓰는 것과 가끔 쓰는 것과 여섯 달 동안 한 번도 안 불린 것으로 갈렸다. 마지막 부류가 백 개를 넘었고 전부 옮겼으면 절반이 헛일이 될 뻔했다.
다만 그 백여 개를 access.log 와 함께 하나씩 훑어보니 셋은 남겨야 했다. 연말 정산과 수사 협조 자료 추출과 분기 보고처럼 주기가 로그 기간보다 긴 것들이었다.
원인 — 사람의 일로 남아 있던 요구
목록에 없다던 기능은 월말에 xlsx 로 정리해 보내는 일이었다. 코드에 없는 것이 맞았고 운영자가 화면을 여러 번 조회해 붙여 넣고 계산하는 방식으로 반나절씩 걸리고 있었다.
옆에서 하루를 지켜보니 그런 것이 더 있었다. 회원 목록 화면의 결과를 복사해 제재 화면에 붙이고 두 화면을 번갈아 열어 값을 비교하고 화면 밖에서 계산기를 쓰고 있었다.
판단 기준 — 안 쓰인 것과 필요 없는 것은 다르다
셋을 살린 것은 사용 빈도만으로 자르지 않았기 때문이다. 여섯 달치 로그는 주기가 반년을 넘는 기능을 구조적으로 못 잡는다.
Kibana 의 로그가 일 년치였으면 그대로 나왔을 것이므로 이것은 판단의 문제가 아니라 관측 기간의 문제였다. 관측 기간보다 주기가 긴 것은 관측으로 존재를 증명할 수 없다.
조치 — 확인받은 목록과 옮기는 순서
두 가지 방법이 있었다. 로그 기준으로 내가 자른 목록을 그대로 Jira 에픽으로 만드는 것과, 옮길 것과 안 옮길 것과 새로 만들 것을 목록으로 만들어 운영팀 확인을 받는 것이다. 뒤쪽을 골랐다. 이유는 관측 기간 밖의 기능은 사람만 알아서다. 대신 확인에 한 주가 드는 것을 감수했다. 안 옮긴다에서 둘이 더 나왔으므로 내 판단을 그대로 실행하지 않은 것이 그 둘을 살렸다.
옮기는 순서는 사용 빈도로 정해서 자주 쓰는 것부터 Jira 에픽에 넣었다. 순서를 안 정하면 만들기 쉬운 것부터 하게 되고 그러면 오래 지나도 옛 콘솔을 계속 쓰게 된다. 옛 콘솔은 바로 끄지 않고 조회 전용으로 반년을 두기로 했다. 실제로 두 번 열어 본 기록이 남았고 둘 다 옮겼어야 할 것이었으므로 그 기간이 빠진 것을 알려 줬다.
정리
- 코드에서 뽑은 목록은 만들어진 것이지 요구사항이 아니다
- 목록에 있는데 안 쓰는 것과 없는데 필요한 것이 동시에 있다
- 실제 사용은
nginx접속 로그를Kibana로 경로별로 센다 - 코드에 없고 사람이
xlsx로 손으로 하는 것이 요구사항이다 - 옆에서 지켜보면 화면 사이를 사람이 잇는 것이 보인다
- 관측 기간보다 주기가 긴 것은 로그로 존재가 안 잡힌다
- 판단한 목록을
Jira에 넣기 전에 확인받으면 빠뜨린 것이 나온다 - 옛 콘솔을 바로 끄지 않으면 열어 본 기록이 빠진 것을 알려 준다