거래소 관리자 콘솔을 전수 점검하면서 어디까지 화면으로 진입할 수 있는지를 알아야 했다. 메뉴 정본 menu.json 에 등재된 항목 수와 @GetMapping("/admin/…") 으로 실제 구현된 화면 수를 각각 셌다.
Table of contents
Open Table of contents
측정 — 구현 수와 등재 수
grep -rc '@GetMapping' src/main/java/**/admin/ 로 세어 보니 구현된 화면이 menu.json 에 등재된 항목보다 마흔 개 넘게 많았다. 그 두 숫자의 차이가 이번 점검의 출발점이 됐다.
차이가 없으면 볼 것이 없고 차이가 있으면 그만큼이 조사 대상이 된다. 어디를 봐야 하는지를 세어 보는 것만으로 정할 수 있었다.
원인 — 메뉴에 없으면 첫 진입을 못 한다
등재되지 않은 화면은 사람이 화면을 통해 처음 들어갈 방법이 없다. /admin/staking/rewards 처럼 주소를 직접 입력해야만 열리는 상태로 남아 있는 것이다.
구현돼 있다는 것과 쓸 수 있다는 것이 갈리는 자리이고 코드만 보면 그 차이가 안 보인다. 확인 중에 서로만 링크하는 화면 둘도 발견했는데 둘 다 menu.json 에 없으면 어느 쪽으로도 못 들어가는 닫힌 순환이 된다.
검증 — 두 방향으로 확인한 여덟 개
두 가지 방법이 있었다. 코드 대조 결과를 그대로 보고하는 것과, 마흔 몇 개 중 스테이킹 계열 여덟 개만이라도 실제 화면의 사이드바에서 확인하는 것이다. 뒤쪽을 골랐다. 이유는 코드 대조만 하면 menu.json 을 잘못 파싱했을 가능성이 남아서다. 대신 나머지 서른 몇 개는 미확인으로 남는 것을 감수했다.
화면을 직접 봐야 확정되는 것이라 두 방향에서 결과를 맞춰 봤다. 여덟 개 모두 sidebar 컴포넌트에 없었다.
조치가 정본 갱신인 이유
원인을 보니 나중에 추가된 스테이킹 계열이라 화면은 만들었는데 menu.json 만 갱신이 빠진 것이었다. 화면 코드는 이미 있으므로 로직에서 고칠 것이 하나도 없었다.
menu.json 에 항목 여덟 줄을 추가하면 끝나는 작업이었다. 무엇을 고칠지가 코드인지 데이터인지에 따라 작업의 성격이 완전히 달라진다.
차이 수와 문제 수
나머지는 확인하지 못했고 그것이 전부 진입점 부재인지 다른 화면 안에서 열리는 하위 화면인지 모른다. 회원 상세 안에서 열리는 /admin/members/{id}/sanctions 같은 하위 화면은 메뉴에 없는 것이 정상이다.
그래서 확정된 여덟 개와 아직 세기만 한 나머지를 나눠서 적었다. 차이 수를 그대로 문제 수로 보고하면 실제보다 과장이 되기 때문이다.
정리
@GetMapping구현 수와menu.json등재 수의 차이가 커버리지 점검의 출발점이다- 차이가 어디를 봐야 하는지를 정한다
menu.json미등재분은 사람이 화면으로 첫 진입을 못 한다- 구현돼 있다는 것과 쓸 수 있다는 것이 갈린다
- 서로만 링크하는 화면은 닫힌 순환이 될 수 있다
- 조치가 로직 수정이 아니라 정본 갱신일 수 있다
- 차이 수는 문제 수가 아니라 조사 대상 수다
- 확인한 것과 세기만 한 것을 나눠 적는다