Skip to content
isdnetworks
Go back

검색이 만든 목록과 요구사항의 거리

옛 시스템을 새로 만들게 되어 기능 목록을 코드에서 뽑았다. 컨트롤러의 공개 함수를 세니 백여든 개가 넘었고 그것을 다 옮기면 되는 줄 알았다.

Table of contents

Open Table of contents

코드에서 뽑은 목록의 한계

목록을 보이자 절반은 안 쓴다는 답과 여기 없는 것이 하나 있다는 답이 함께 왔다. 코드에서 뽑은 목록은 만들어진 것을 말할 뿐 쓰이는 것과 필요한 것을 말하지 않는다.

두 방향으로 어긋난 셈이다. 목록에는 있는데 안 쓰는 것과 목록에 없는데 필요한 것이 동시에 있었다.

로그가 센 실제 사용

접속 로그로 경로별 호출을 세니 자주 쓰는 것과 가끔 쓰는 것과 여섯 달 동안 한 번도 안 불린 것으로 갈렸다. 마지막 부류가 백 개를 넘었고 전부 옮겼으면 절반이 헛일이 될 뻔했다.

다만 그 백여 개를 하나씩 훑어보니 셋은 남겨야 했다. 연말 정산과 장애 대응과 분기 보고처럼 주기가 로그 기간보다 긴 것들이었다.

사람의 일로 남아 있던 요구

목록에 없다던 기능은 월말에 엑셀로 정리해 보내는 일이었다. 코드에 없는 것이 맞았고 관리자가 화면을 여러 번 조회해 붙여 넣고 계산하는 방식으로 반나절씩 걸리고 있었다.

옆에서 하루를 지켜보니 그런 것이 더 있었다. 목록 화면의 결과를 복사해 다른 화면에 붙이고 두 화면을 번갈아 열어 값을 비교하고 화면 밖에서 계산기를 쓰고 있었다.

안 쓰인 것과 필요 없는 것은 다르다

셋을 살린 것은 사용 빈도만으로 자르지 않았기 때문이다. 여섯 달치 로그는 주기가 반년을 넘는 기능을 구조적으로 못 잡는다.

로그가 일 년치였으면 그대로 나왔을 것이므로 이것은 판단의 문제가 아니라 관측 기간의 문제였다. 관측 기간보다 주기가 긴 것은 관측으로 존재를 증명할 수 없다.

확인받은 목록과 옮기는 순서

옮길 것과 안 옮길 것과 새로 만들 것을 목록으로 만들어 확인을 받았다. 안 옮긴다에서 둘이 더 나왔으므로 내 판단을 그대로 실행하지 않은 것이 그 둘을 살렸다.

옮기는 순서는 사용 빈도로 정해서 자주 쓰는 것부터 넣었다. 순서를 안 정하면 만들기 쉬운 것부터 하게 되고 그러면 오래 지나도 옛 시스템을 계속 쓰게 된다.

옛 시스템은 바로 끄지 않고 조회 전용으로 반년을 두기로 했다. 실제로 두 번 열어 본 기록이 남았고 둘 다 옮겼어야 할 것이었으므로 그 기간이 빠진 것을 알려 줬다.

정리


Share this post on:

Previous Post
다시 하려면 무엇이 0이어야 하나
Next Post
화면에 없고 전송에는 있던 값