Next.js에서는 클라이언트 환경 변수(NEXT_PUBLIC_)와 서버 환경 변수가 분리되어 있다는 것을 처음 알게 되었고, 배포 시 클라이언트 환경변수를 별도로 주입해야 한다는 점을 뒤늦게 인지.
해결: Dockerfile과 GitHub Actions에서 각각 환경변수를 주입하여 해결.
UI 생성이나 설계 초기에 GPT와 MCP(Figma에서 제공해주는 서버들)를 많이 의존했지만, 실제로는 디자인을 코드로 변환하는 과정에서 많은 어려움을 겪음.
아직 완벽하게 되지 않는다는 것을 느낌. dev_code MCP가 공식으로 운용하면 정말로 유용해지지 않을까 싶음.
기존에는 페이지나 컴포넌트 내부에서 데이터를 가공했지만, 현재는 store에서 데이터를 가공하도록 리팩토링하여 책임 분리를 명확히 함.
API lib를 작성하고 사용함으로써 응집도 있는 구조로 개선.
Next.js의 라우터를 이용해 프록시 방식으로 외부 이미지를 연동함. 이는 보안상 유리하고, 이미지 최적화나 접근 제어 측면에서도 의미 있는 선택이었음.
변화가 큰 페이지에서 스켈레톤을 컴포넌트 분리할지, 삼항 연산자 등 조건부 렌더링으로 한 페이지에 처리할지, 혹은 상태별로 각각 다른 컴포넌트를 만들지에 대한 많은 고민이 있었음.
이는 정답이 있는 문제라기보다는, 나만의 규칙을 정하거나, 룰을 이해하는 것이 중요할 거 같아 유지보수성, 재사용성, 협업 난이도를 기준으로 테스트해보고 개인 프로젝트에서 경험한 후 팀 프로젝트에 적용하고 싶음.
기존에는 직접 쿠키/세션 기반 인증이나 JWT 기반 인증 서버를 직접 구현해왔기에, OAuth는 처음이라 구조를 이해하는 데 시간이 걸렸음.
백엔드에서 OAuth에 토큰을 받아올 때 보내는 redirect_url param 페이지의 의미가 code를 받아온 페이지라는 것을 알아차리는 것이 늦었음.
[메인 창] ↓ 로그인 버튼 클릭 [팝업 창] → OAuth 로그인 → redirect_uri로 리디렉션 → code 수신 → postMessage로 code 전달 [메인 창] → code 수신 후 백엔드에 요청 [백엔드] → access token 발급 및 유저 정보 조회 → JWT 발급 및 응답 [메인 창] → 로그인 완료 처리
오랜만에 프레임워크를 사용한 프론트엔드 작업이었던 만큼 부족함도 느꼈지만, 그만큼 JSP, Thymeleaf에서 배웠던 것을 적용시킬 수 있었던 기간.
앞으로는 다음의 두 가지에 집중하고자 함: