모듈 단위 경로 정리

인계받은 시스템의 URL 목록이 400줄이었는데 그 안에 어떤 규칙도 보이지 않았다. 새 기능을 추가할 때 어디에 넣어야 할지를 정할 근거가 없다는 것이 당장의 문제였다.

Open Table of contents

문제 — 규칙 없이 늘어난 400줄
대상별 집계와 도메인 묶기
옛 주소는 영구 이동으로 보낸다
못 옮긴 것과 그 조건
이름 규칙과 그것을 지키는 검사
정리

문제 — 규칙 없이 늘어난 400줄

이런 식이었다.

/list
/view
/edit
/user_list
/userView
/course/list
/getCourseInfo
/api/course
/ajax/course_list

같은 대상을 다루는 것이 흩어져 있고 이름 규칙도 셋이 섞여 있었다. 새 화면을 만들 때 어디에 넣을지 정할 수가 없어서 또 다른 규칙으로 넣게 된다.

그래서 목록을 정리하기 전에 지금 무엇이 몇 개나 있는지부터 세어 보기로 했다. 세어 보지 않고 묶으면 묶는 기준이 내 감에서 나오게 된다.

대상별 집계와 도메인 묶기

먼저 몇 개인지부터 셌다.

$ grep -oE "^\s*Route::[a-z]+\('([^']+)'" routes/web.php | wc -l
412

412개였고 대상별로 갈라 보니 이랬다.

과정(course)   88
사용자(user)   64
수강(enroll)   52
평가(quiz)     41
공지           22
그 외          145

「그 외」가 가장 많았고 열어 보니 어디에도 안 묶이는 것들이었다.

그 대상 이름을 URL 앞에 두는 방식으로 묶으니 목록이 덩어리별로 읽히기 시작했다. 새 URL 을 어디에 넣을지도 그 대상이 무엇인지만 정하면 자동으로 따라왔다.

옛 주소는 영구 이동으로 보낸다

URL 을 바꾸면 옛 URL 로 들어오는 요청이 끊기므로 그것을 새 URL 로 보내 주는 처리를 함께 뒀다. 302 가 아니라 301 로 보낸 것은 RFC 7231 이 301 을 기본적으로 캐시 가능이라 하고 링크를 고칠 수 있는 클라이언트는 참조를 새 URI 로 바꾸라고 하기 때문이다. 대신 잘못 보낸 301 은 캐시된 쪽에 오래 남으므로 매핑을 먼저 확정하고 내보냈다.

여기에 옛 URL 로 얼마나 들어오는지를 세는 것도 붙였다. 그 수가 0이 되면 그때 이동 처리를 지우면 되고 안 세면 언제 지워도 되는지를 영영 모른다.

못 옮긴 것과 그 조건

전부 옮기지는 못했는데 외부에 이미 알려 준 URL 몇 개가 그대로 남아야 했다. 이런 것은 우리 사정만으로 바꿀 수 없어서 상대 쪽 일정과 맞물린다.

못 옮긴 것들을 목록으로 적으면서 각각 왜 못 옮겼는지와 어떤 조건이 되면 옮길 수 있는지를 함께 적었다. 조건을 안 적으면 다음 사람이 그것을 옮기면 안 되는 것으로 읽는다.

이름 규칙과 그것을 지키는 검사

이름 규칙도 정했는데 URL 에는 무엇을 다루는지만 담고 무엇을 하는지는 GET · POST · DELETE 같은 HTTP 메서드가 말하게 했다. URL 에 동사가 들어가기 시작하면 같은 대상에 대해 표현이 여러 갈래로 늘어난다.

규칙을 문서에만 적으면 몇 달 뒤에 다시 어긋나므로 규칙에 안 맞는 URL 을 찾아내는 검사를 만들었다. 적어 두는 것만으로 지켜지는 규칙은 없다는 것이 이 작업에서 확인한 것이었다.

정리

URL 이 평면으로 늘어나면 새것을 어디에 넣을지 정할 수 없다
묶기 전에 무엇이 몇 개인지 대상별로 센다
도메인으로 묶어 URL 앞에 무엇을 다루는지를 둔다
옛 URL 은 301 로 보내고 유입을 센다
못 옮긴 것은 이유와 옮길 수 있는 조건을 적는다
URL 에는 대상만 담고 동작은 HTTP 메서드가 말한다
규칙에 안 맞는 것을 찾는 검사를 만든다
잘못 보낸 301 은 캐시된 쪽에 오래 남는다