약 한 달간 vscode로 개발하고 local에서 아무 문제없음을 확인하고 드디어 배포를 완료했다. 배포 방법도 여러가지가 있지만, 일단 배포 방법이 간단하고, 배포 후 수정해도 바로 깃헙 푸쉬로 연동이 가능한 netlify를 사용하기로 했다.

그리고... 배포 후 에러를 잡는 데 무려 3일이나 소요됐다.

내가 애를 먹었던 건 두 가지였다. 바로 라우팅 과 proxy

🤔 라우팅

netlify로 배포한 주소로 들어가서 nav에 있는 메뉴를 클릭하면 잘 이동하나, 내가 직접 url을 입력해서 이동하려고 하면 not found가 나타났다.

(예를 들어,https://playful-bublanina-62b212.netlify.app 자체는 잘 들어가지나, https://playful-bublanina-62b212.netlify.app/login 이라고 url 에 직접 입력하면 404가 나타남. 심지어 내가 만들어놓은 404페이지로 열리는 것도 아님)

☄️ 트러블 슈팅

_redirects 를 public 폴더 안에 추가하기

(적어야하는 파일형식 따로 없음, vscode에서 읽으려고 하면 txt로 설정해주면 됨)

/* /index.html 200

URL이 정적 에셋과 일치하지 않으면 모든 url에 대해 포괄적인 대체 경로인 /index.html을 보내겠다는 의미의 파일이다.

왜?

리액트의 경우 Single Page Application 이기 때문에 오직 하나의 페이지인 index.html만 렌더링하고, 복잡한 라우터 처리는 React Router 라이브러리의 도움을 받는다.

그리고 Netlify는 API와 통신하는 서버만을 가지고, 프론트엔드 스택의 파일로 정적 웹 페이지를 배포해주는 서비스이다. 즉, 라우팅은 서버가 아닌 사용자의 브라우저의 몫이고, 서버는 그냥 https://sheerios.netlify.app 요청이 들어오면 index.html 을 보내준다는 규칙밖에 모른다. 그런데https://sheerios.netlify.app/login을 들이밀면서 페이지 내놓으라고 하면 Netlify 입장에서는 당황하면서 경로를 어떻게 처리해야할지 몰라 404에러를 내뿜는 것이다.

그래서 이제 이런 주소가 들어오면 얘를 보내줘~ 라는 규칙을 알려줘야 하는 것이고, 그걸 _redirects 파일로 정의해주는 것이다.

😨 똑같은 실수하지 않기

위의 _redirects 파일 방법이 안될 경우 앱 내 최상위 경로에 netlify.toml 파일을 만들고 안의 내용을 아래와 같이 작성하면 된다.

  [[redirects]]
    from = "/*"
    to = "/index.html"
    status = 200

그런데, 나는 여러 방법을 찾아보다가 발견한 방법들을 모두 합쳐서 _redirects 와 netlify.toml 을 함께 만들었다... OMG...

작동을 안해서 .gitignore에 혹시 toml가 있는지 찾아보기도 하고, 여러 이유를 찾아보다가 결국 둘 중 하나는 삭제해보았더니 잘 작동했다...!
(netlify.toml을 삭제하고 _redirects만 남겨뒀음)

두 파일 모두 결론적으로 하는 말은 똑같지만, 두 파일이 같이 존재하다보니 뭔가 꼬여서 에러가 난 것 같았다.ㅠㅠ

🤔 CORS 에러

네이버 이미지 api를 사용해 갤러리에 사진들을 보여주는데 local에서는 http-proxy-middleware 라이브러리를 사용해 해결했었다.

const { createProxyMiddleware } = require('http-proxy-middleware');

module.exports = function (app) {
  app.use(
    '/api',
    createProxyMiddleware({
      target: 'https://openapi.naver.com/v1/search/image',
      changeOrigin: true,
    })
  );
};

그런데 배포하고 나니 적용이 안 되는 것 아닌가..!
이번에 처음 알았다. 프록시 서버 우회는 개발 환경에서만 가능하다는 것을...!

☄️ 트러블 슈팅

정말 애 많이 먹었는데, 해답은 공식문서에 있었다ㅠㅠ

내 sheerios 사이트가 외부 naver api 서비스에 프록시되도록 규칙을 정하는 방법이 나와있다.
아까 만들었던 _redirects 파일에 다음과 같은 코드를 추가한다.

/api/*  https://openapi.naver.com/:splat  200
/*  /index.html 200

:splat은 /* 와 같은 뜻으로, 이 이제 내가 코드에 쳤던 /api/...에 대한 모든 요청은 https://openapi.naver.com/ 새 경로로 리디렉션된다는 의미다.

그리고 이 api를 사용하는 곳의 코드는 다음과 같다.

const getPhotosPage = async (pageParam = 1, options = {}) => {
  try {
    axios.defaults.withCredentials = true;
    const response = await axios.get('/api/v1/search/image', {
      params: {
        query: '에드시런',
        display: 100,
        filter: 'small',
        start: pageParam,
      },
      headers: {
        'X-Naver-Client-Id': import.meta.env.VITE_NAVER_CLIENT_ID,
        'X-Naver-Client-Secret': import.meta.env.VITE_CLIENT_SECRET,
      },
    });
    return response.data.items;
  } catch (error) {
    console.error('An error occurred:', error);
    throw error;
  }
};

왜?

이 부분은 netlify가 이렇게 설정해둔거라 그냥 넵..! 하고 따를 수밖에 없는거라 따로 적을 부분이 없다ㅋ_ㅋ 그래도 이번 기회를 통해 이전에 proxy 공부해둔 링크를 보며 다시 공부했다.

😨 똑같은 실수하지 않기(1)

/api/*  https://openapi.naver.com/:splat  200
/*  /index.html 200

경로의 실행 순서는 위에서부터 입력한대로 실행되기 때문에 /api/를 제일 위에 입력해야 한다. 만약 둘의 순서가 바뀔 경우, 모든 경로는 index.html로 가기 때문에 proxy를 해결할 수 없게 된다ㅠ-ㅠ

😨 똑같은 실수하지 않기(2)

_redirects에 api 입력하는 곳을 다음과 같이 적고,

/api/*  https://openapi.naver.com/v1/search/image  200
/*  /index.html 200

getPhotosPage axios에서 get('/api', 블라블라)라고 적었는데,
제대로 작동하지 않았다. 아무래도 서브 도메인 없이 https://openapi.naver.com 메인까지만 입력하고 나머지는 :splat 처리해야 하는 것 같다.

회고

처음으로 기획, 디자인, 개발, 배포까지 혼자 다 해본 프로젝트였다.
약 1달간의 개인 프로젝트를 마무리하며 4L(Liked, Lacked, Learned, Longed for)에 따라 회고를 진행해보려고 한다.

Liked: 좋았던 점은 무엇인가?

매일 기록하기

거의 매일 프로젝트 진행상황을 기록함으로써 전반적인 프로젝트 흐름을 파악할 수 있었고, 트러블 슈팅을 적어둬서 나중에 비슷한 문제가 생겼을 때 그 때 어떻게 해결했더라? 하고 다시 볼 수 있었던 점이 무척 좋았다고 생각한다.

성능 최적화

또한 목표했던 기능구현에만 그치지 않고, 처음으로 lighthouse를 사용해서 code splitting이나 번들최소화 등의 개념을 학습하고 도입했던 점이 좋았다. LCP, FCP 등을 개념으로만 알다가 직접 눈으로 보며 사용자 입장에서 loading 속도를 체감하고 고쳐나가니 무척 도움이 되었다. ~~ 까지 향상시켰던 점을 칭찬하고 싶다.

Lacked:아쉬웠던 점, 부족한 점은 무엇인가?

일정 분배

전반적으로 일정 분배를 확실히 체계적으로 하지 않고 일단 프로젝트를 시작했다. 게다가 모든 걸 혼자 하는 상황이다보니, 코드 수정이 필요하거나 에러가 날 경우엔 당연히 하루이틀 조금씩 밀리기도 했고, 결과적으로 내가 계획했던 것보다 열흘 이상 더 걸렸다.

사전 조사

어떤 라이브러리를 사용하고, 어떤 걸로 배포할지도 좀 더 꼼꼼히 조사하고 시작했어야 했다. 막연히 생각해둔 라이브러리를 막상 사용하려고 했는데, 그 라이브러리가 더 이상 유효하지 않기도 했고 (ex. 멜론 음악 api), 원래 배포도 aws로 하려고 했다. 그런데 그 안에도 종류가 너무 다양해서 aws 종류, 사용법 공부만 하다가 하루 이상이 소요돼서 시간상 일단 netlify라도 배포하였다.

Learned:배운 점은 무엇인가?

제일 기억에 남는 (이라고 쓰고 제일 고생했던ㅋㅋ) 기억을 말하라고 하면, 두 개가 생각난다.

깃 명령어를 충분히 숙지하자.

git revert 잘못 쓰고 하루 온종일 멘붕상태로 다시 모든 코드 작성했던 걸 생각하면 아직도 끔찍하다. 심지어 main branch 하나만 사용했었다. 내 개인 프로젝트여서 망정이지, 만약 팀 프로젝트였다면...
깃 명령어는 신중하게, 충분히 숙지 후 사용하자!

배포할 때까지는 끝이 아니다.

배포 후 에러가 이렇게 시간을 오래 잡아먹을지는 생각을 못했다. 사실 빌드하다가 에러나기도 했고,,, local에서 개발하고 끝~! 이 아니라는 걸 반드시 다시 숙지숙지!!

Longed for: 앞으로 바라는 것은 무엇인가?

배포했다고 끝내지 말고, 유지보수해내가기

지금 당장은 내가 목표했던 기능은 담아 배포까지 완료했지만,
유저 입장에서 더 좋은 사이트를 생각한다면

• 당연히 사이트에서 좋아하는 가수의 음악도 듣고 싶을테고 ( ➡️ 음악api 연결)
• 회원들끼리 서로 가수에 대해 얘기할 수 있는 게시판이나 채팅기능도 있으면 좋을테고 ( ➡️ 웹소켓)
• 핸드폰으로도 이 사이트를 보고 싶을 것이다.( ➡️ 반응형)

계속해서 유지보수하면서 사이트를 발전시키고 싶다.

한 달뒤의 내가 봐도 이해할 수 있는 코드가 좋은 코드다

이전의 한 멘토님으로부터 들었던 말이다.

당장은 어찌어찌 굴러가게 만들었을지 몰라도, 한 달뒤에 이 코드를 보면 뭐지? 싶은 게 한둘이 아니라고. 한 달뒤의 내가 봐도, 내가 아닌 다른 사람이 봐도 이해할 수 있게 깔끔하게 작성하길 조언해줬다.

클린 코드를 생각하며 조금씩 리팩토링하며 한 달뒤의 내가 봐도 깔-끔하게 이해할 수 있도록 유지보수해야겠다.

---

참고사이트:
[React] Router 사용한 프로젝트 Netlify로 배포할 때 404 page not foundby zmin9
netlify 배포하기 위한 Redirects 설정by realzu