QASTUDIO: 쿠키 인증과 OAuth URI 충돌을 해결한 QA 자동화 서비스 개발기

1. QA 자동화 서비스에서 가장 먼저 부딪힌 문제

QASTUDIO는 QA 시나리오 작성과 반복 검증의 수작업 부담을 줄이기 위해 시작한 프로젝트였습니다.
AI가 시나리오를 생성하고, 이를 실제 자동화 흐름으로 연결하는 서비스였기 때문에 인증, 사용자 상태, 프로젝트 데이터가 꽤 복잡하게 얽혀 있었습니다.

저는 이 프로젝트에서 다음 영역을 맡았습니다.

이때 가장 어려웠던 것은 화면을 만드는 일보다, 인증 흐름을 실제 서비스처럼 안정적으로 연결하는 일이었습니다.

프로젝트 초기에 가장 먼저 고민한 것은 인증 저장 방식이었습니다.
구현 편의성만 보면 로컬 스토리지가 훨씬 단순하지만, 보안까지 생각하면 이야기가 달라집니다.

QASTUDIO에서는 보안 측면을 고려해 쿠키 기반 인증을 선택했습니다.
문제는 여기서부터 시작됐습니다.

겉으로 보기에는 SameSite, Secure 같은 속성 설정 문제처럼 보였지만, 실제 원인은 더 깊은 곳에 있었습니다.

한동안은 프론트엔드 localhost를 HTTPS로 바꾸고, 백엔드의 쿠키 속성을 조정하는 방식으로만 접근했습니다.
하지만 이 방법으로는 문제가 완전히 해결되지 않았습니다.

원인을 다시 추적해보니, Spring Security OAuth2 Client의 기본 URI와 팀 서버에서 사용하던 로그인 처리 URI가 충돌하고 있었습니다.

즉, 이 문제는 단순한 프론트 설정이나 쿠키 옵션 문제가 아니라,
백엔드 프레임워크의 라우팅 규칙과 로그인 리다이렉트 흐름까지 함께 봐야 보이는 문제였습니다.

해결은 두 단계로 진행했습니다.

소셜 로그인 URI를 /oauth2/authorization/{provider} 형태로 변경해 프레임워크 기본 매핑과 충돌하지 않도록 정리했습니다.

그다음에도 "로그인 직후 다른 API를 한 번 더 불러야 쿠키가 제대로 반영되는 것처럼 보이는" 문제가 남아 있었습니다.
그래서 /login/success에서 곧바로 사용자 정보를 조회하도록 흐름을 바꿨습니다.

이렇게 바꾼 뒤에는 로그인 이후 흐름이 훨씬 명확해졌고,
단순 성공/실패가 아니라 "현재 사용자 상태에 따라 어디로 보내야 하는가"를 기준으로 설계할 수 있었습니다.

쿠키 기반 인증은 브라우저 환경 영향을 크게 받기 때문에, 로컬 개발 환경에서도 검증 가능한 조건을 맞추는 것이 중요했습니다.
그래서 개발 스크립트에서 로컬 인증서를 사용하는 HTTPS 환경을 별도로 구성했습니다.

또 인증 관련 API는 한곳에 섞어두지 않고 역할별로 정리했습니다.

이렇게 분리해두니 인증 흐름을 수정하거나 디버깅할 때, 어떤 책임이 어디에 있는지 훨씬 명확하게 볼 수 있었습니다.

QASTUDIO의 또 다른 핵심은 시나리오 조회 페이지였습니다.
이 화면은 단순 목록이 아니라 프로젝트, 역할, 시나리오, 액션이 계층적으로 연결되는 구조였고, 여러 API 결과가 한 화면에서 함께 움직였습니다.

그래서 전역 상태는 Redux로 관리했습니다.

이 구조 덕분에 사용자, 프로젝트, 역할, 시나리오 관련 API를 여러 개 붙이더라도 상태 책임을 비교적 분리해서 다룰 수 있었습니다.

QASTUDIO를 하며 가장 크게 배운 것은 인증 이슈를 프론트엔드 화면 문제처럼만 보면 해결할 수 없다는 점이었습니다.

이 프로젝트는 단순히 로그인 화면을 구현한 경험이 아니라,
"서비스의 인증 구조를 어디까지 이해해야 프론트엔드가 제대로 동작하는가"를 배운 경험에 가까웠습니다.