서비스 중인 웹에서 문자에 주소를 담아 보내면 자사의 특정 서비스 페이지로 이동시켜야 하는 상황이었다.
주소는 대략 domain.com/리스트/:id 이런 구성으로 되어있다. 주 연령대가 나이가 있는 편이고 주소가 신뢰가 가는 스팸처럼 보이지 않아야 하므로 한글 주소를 사용했다.
한글 주소를 처리하는 방법은 크게 두 가지가 생각났는데
페이지에서 next.js에서 제공하는 useRouter()로 주소 체크 후 routing 처리를 해주는 방법이다.
이 방법은 해당 페이지에서 다른 추가적인 api 작업이나 처리 등을 해야할 때 유용하다고 할 수 있다. 잠시 페이지가 렌더링 되는 장면이 사용자 경험을 해칠 수 있다. Loading 컴포넌트를 페이지에서 렌더링해 사용자 경험을 증대시키면 좋다.
next.config.js에서 redirects 처리로 redirect 시켜주는 것이다. next단에서 바로 redirect 시켜주는 것이므로 찰나의 렌더링 시간을 느끼지 않는다.
때문에 바로 원하는 페이지가 뜨는 걸 느낄 수 있고, 해당의 경우는 별도의 api 처리 등이 필요없기 때문에 사용자 경험이 routing보다 낫다고 느낄 수 있다고 생각해 redirect 처리를 해주었다.
module.exports = {
async redirects() {
return [
{
source: '/:slug/:id',
destination: '/routing-page/:id',
permanent: true,
},
]
},
}
source
요청 경로
destination
라우팅 경로
permanent
true또는 false- true클라이언트/검색 엔진에 리디렉션을 영원히 캐시하도록 지시하는 308 상태 코드를 사용하는 경우, false임시적이고 캐시되지 않는 307 상태 코드를 사용하는 경우(아직 이해가 되지 않아 공식 홈페이지에서 가져옴)
source 뒤에 :id
는 동적 라우팅으로 destination에도 :id
를 써주면 그대로 동적으로 가져갈 수 있다.
별로 대수롭지 않은 항목이라고 생각했으나, 그것은 나의 큰 오산이었다..
한글 페이지를 인식해서 redirect 해주려면 한글페이지가 오는 부분을 동적으로 인식하고 id 부분도 동적으로 인식해 /:slug/:id
이런 식의 source 설정이 만들어진다.
여기서 문제가 발생했는데, 내가 간과한 것이 있었으니 바로 기존 2deps 주소들도 몽땅 저기에 인식되어 redirect 된다는 것..
오류가 운영에 배포되고 나서 알게 되었다. 2deps 주소가 2개정도 밖에 없었고, 그 페이지도 이용자가 거의 없어 알기가 어려웠던 이유..
저런 내용의 오류가 검색 시에 잘 나와있지 않았다. 점점 조마해지는 찰나, 불현듯 내가 해왔던 코드들에서 깨달음을 얻은 듯 해결방법을 발견해내었다.
이미 문자메세지로 날리는 코드를 바꾸는 건 서비스 중인 상태에서 쉽지 않았고, 내가 2deps의 주소를 3deps로 바꾸는 등의 설계에 좀 더 신경쓰는 방향으로 오류를 해결했다.
물론 앞으로 2deps의 주소를 만들기는 어려울 것 같다.
설계의 중요성과 사전 지식의 중요성을 깨달았다. 물론 next.js로 운영을 해보는 게 처음이기 때문에 실전경험이 부족해서 어쩔 수는 없다지만 그래도 좀 더 주의가 필요한 부분이었다.
운영에 무언가를 배포하기 전에 좀 더 주의를 기울어야한다는 점.
이번 경험을 통해 다시금 깨닫는 계기가 되어서 소중하고 값진 문제해결 경험이었다.