[트러블슈팅] Supabase 의존성 주입 문제로 인한 API 오류 해결 과정

 

mission: main 브랜치를 고쳐라!

 

 

팀원이 main 브랜치에 이슈가 발생하여 개발 진행을 아예 못 하고 있다고 하였다.

이 문제를 진단하고 해결한 과정을 상세히 기록해본다!

 

올렸던 PR

 

 

첫번째 문제 상황: 500 응답 (SupabaseConnection 전역 모듈화)

먼저, 동작하지 않는 페이지에 접속하여 네트워크 탭을 확인하였다. 

브라우저의 네트워크 요청이 서버로 전달되지 않고 Network Error가 발생하고 있었다. 

주목해야 할 것은, 네트워크 탭에서 많은 API 요청이 Preflight에서 실패하고 있었다.

이에 따라 서버 응답에 문제가 있을 가능성이 있다고 생각했다. 

 

 

언제부터 이런 이슈가 발생했는가? - 롤백을 해보자 !

정상적으로 작동하던 main 브랜치에 갑자기 이슈가 발생했으니,

병합된 특정 PR에 문제가 있을 것이라 생각했다. 

PR과 커밋 기준으로 롤백을 진행하며 테스트해본 결과,

백엔드 팀원분의 대규모 유저 부분 리팩토링 PR 이후부터 동일한 이슈가 발생하는 것을 확인할 수 있었다.

 

 

로깅 코드 추가 - NestJS의 DI 문제

로컬로 프론트와 백을 실행한 후 백엔드쪽에 찍히는 로그를 확인해보았다.

Cannot read properties of undefined (reading 'connection') 에러가 찍히고 있었다.

 

좀 더 세부적인 오류의 원인으로는

1. JwtAuthGuard에서 undefined를 참조할 경우

2. 주입된 의존성 누락

3. 환경변수 또는 설정 문제

이렇게 추릴 수 있었다.

 

디버깅을 위해 로깅 코드를 추가하였다. 

 

성공적으로 주입되었다가, 다시 주입되지 않는다는 로그가 떴다.

SupabaseConnection 인스턴스 생성은 한 번만 생성되고 있으며, NestJS에서 정상적으로 초기화되고 있다.

근데 JwtAuthGuard에서 주입되지 않는다는 것.

DI (Dependency Injection) 설정의 스코프나 의존성 관리의 순서 문제일 가능성이 있다!

 

Dependency Injection (의존성 주입): 객체가 필요한 의존성을 직접 생성하거나 관리하지 않고 외부에서 주입받는 디자인 패턴. 이를 통해 객체 간 결합도를 낮추고 테스트 가능성과 코드 재사용성을 높인다.

 

SupabaseConnection을 전역 모듈로 설정하여 모든 곳에서 동일한 인스턴스를 참조하도록 수정하니

500 응답이 오는 문제는 해결되게 되었다!

 

 

두번째 문제 상황. 401 응답 (MockingUser 컴포넌트 렌더링 추가)

전역으로 처리해주니 500이 아닌 401 응답이 오게 된다. 

토큰이 undefined로 나오고 있다.

 

다른 프론트 팀원분의 이전 작업에서,

로그인 제거 작업을 하며

유저를 모킹하는 컴포넌트가 있었는데

해당 컴포넌트가 루트 페이지에서 렌더링되지 않아 토큰 생성을 하지 않는 것이었다. 

 

해당 컴포넌트를 렌더링하게 해주었다.

 

 

세번째 문제 상황. 404 응답 (API_PATH 변경)

이상한 점은, MockingUser 컴포넌트가 렌더링되는데도 token을 제대로 받아오지 못한다는 것이었다. 

curl 명령어로 확인해보니 404 응답이 반환되는 것을 볼 수 있었다. 

 

이에 따라 백엔드쪽 코드를 확인해보니, API path가 /auth가 아닌 /user로 변경되어 있었다.

백엔드 팀원분이 path를 변경하고 프론트쪽에 공유하지 않았던 것이다.

 

이에 따라 프론트의 API_PATH를 변경하였고,

응답 형식도 session에 담아 보내는 것으로 약간 변경되어 있어

응답 값에 맞게 토큰을 쿠키에 저장하도록 수정하였다.

 

 

 

네번째 문제 상황. 404 (데이터 테이블 초기화)

이제 token을 제대로 받아오는데, 회원을 찾을 수 없다는 오류가 발생했다.

/workspace 페이지에서 API 요청 시 user_metadatas 테이블에서 유저를 조회하는데,

supabase user_metadatas 테이블이 비어 있어 뜨는 문제였다.

이에 따라 모킹에 사용되는 데이터만 user_metadatas 테이블에 임시로 직접 추가해주었다. 

 

 

느낀 점

이번 문제는 꽤 긴 흐름을 따라 여러 단계를 거쳐야 해결할 수 있는 복잡한 문제였다.

문제를 해결하는 중간에 흐름을 끊을 수 없어서 ㅋㅋ 5시간 동안 연속으로 몰입하며 분석하고 디버깅했다.

 

특히, DI 문제는 NestJS 설계 초기 단계에서 서비스의 스코프와 전역 모듈 관리를 명확히 설계해야 한다고 느꼈다.

의존성 주입이 복잡한 환경에서는 서비스 간 참조 순서를 철저히 점검해야 한다!

 

NestJS의 Dependency Injection이 가장 큰 문제의 원인이었지만,

컴포넌트 렌더링, API path, 유저 데이터 테이블 등

다른 문제의 원인들도 꽤 중요한 문제의 원인들 중 하나였다!

 

백엔드 개발자는 변경 사항을 프론트 개발자에게 잘 공유하고, 

프론트는 백엔드의 변경사항이 프론트에 영향을 미칠 가능성을 꼼꼼히 확인하는 협업 과정이 필수적이라고 생각했다.

 

 

---

 

트러블 슈팅은 너무 재밌어

특히 이번 문제는 단계적으로 해결하는 문제라서 더 재밌었다!

중간에 문제 종류가 바뀌었을 때가 제일 짜릿해 😇