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