플랫폼 API에서 제공자 식별과 인증 경계를 나누는 법

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

플랫폼 API는 요청을 보낸 제공자가 누구인지 알아야 한다. 그 식별자에 따라 어느 제공자의 리뷰를 쓰고 읽을지가 정해지므로, 컨트롤러마다 같은 조회 코드를 반복하지 않고 비즈니스 흐름에 전달할 방법이 필요하다.

이 프로젝트의 방식은 의도적으로 단순하다. 호출자가 발급받은 두 키를 헤더에 담아 보내면 Spring의 HandlerMethodArgumentResolver가 이를 읽는다. 데이터베이스에서 제공자를 조회한 뒤 컨트롤러 인자로 Provider 객체를 넘긴다. 이후 비즈니스 흐름은 제공자 ID를 사용해 저장과 조회 범위를 구분한다.

Provider는 비즈니스 식별자다

‘제공자’라는 이름이 거창해 보이지만 여기서는 플랫폼 API를 사용하는 주체를 뜻한다. 두 가게가 같은 리뷰 기능을 사용하더라도 각 가게의 리뷰는 서로 섞이면 안 된다. 제공자 ID가 그 경계를 만든다.

이 서비스가 제공자를 등록하고 관리하므로 Provider는 도메인 객체로 다룬다. 컨트롤러가 이 객체를 인자로 받는다고 해서 현재 프로젝트의 의존 방향을 깨지는 않는다. API 계층은 이미 도메인을 알고 있고, 도메인은 컨트롤러를 거꾸로 알지 않는다.

프레젠테이션 경계를 더 명시하고 싶은 팀은 요청용 식별자를 먼저 만든 뒤 유스케이스 호출 전에 Provider로 변환할 수 있다. 계층을 넘어가는 순간을 타입으로 표현할 수 있다는 장점이 있다. 현재의 느슨한 규칙과 작은 규모에서는 그 구분이 필수는 아니므로 도메인 객체를 직접 넘긴다.

지금의 인증은 지금 규모만큼만 만든다

현재는 요청마다 데이터베이스를 조회한다. 트래픽이 크지 않아 이 정도면 충분하다. 조회 부하가 실제 문제가 되면 메모리 캐시를 검토할 수 있지만, 아직 없는 부하를 위해 먼저 넣을 이유는 없다.

서버 경계도 같은 기준으로 본다. 시스템이 커지면 게이트웨이 같은 앞단에서 인증을 끝내는 방식을 선호한다. 게이트웨이가 외부 자격 증명을 확인하고 식별된 사용자나 제공자 ID만 사설 백엔드 서버에 전달한다. 그러면 뒷단 서비스는 인증 호출이나 Spring Security 설정을 반복하지 않고 도메인 작업에 집중할 수 있다.

다만 조건이 있다. 백엔드 서버가 외부에서 직접 접근되지 않아야 하고, 선택한 네트워크 구조 안에서 내부 요청을 신뢰할 수 있어야 한다. 인프라 비용도 든다. 단순한 키 확인 하나 때문에 게이트웨이, 인증 서버, 도메인 API 서버를 모두 나누는 것은 작은 프로젝트에 과하다.

그래서 현재 프로젝트가 그런 구조인 척하지 않는다. 아규먼트 리졸버가 로컬 인증 경계 역할을 한다. 키를 읽고 제공자를 찾은 다음 요청을 이어간다. 문제가 작은 만큼 배포 구조도 작은 쪽을 택한 것이다.

같은 프로세스에서도 책임은 구분한다

식별과 비즈니스 행위는 한 애플리케이션에서 실행되더라도 다른 책임이다. 리졸버는 “누가 호출했는가”를 답하고, 비즈니스 코드는 “이 제공자가 무엇을 읽고 바꿀 수 있는가”를 처리한다. 이 구분을 코드에 남겨 두면 지금 당장 서버를 나누지 않고도 나중에 인증 경계를 앞단으로 옮길 수 있다.

좋은 구조는 눈앞의 시스템에 맞는 구조다. 이 플랫폼 API에는 헤더, 리졸버, 데이터베이스 조회면 충분하다. 규모나 배포 방식이 달라지면 인증 경계를 바깥으로 옮겨도 유스케이스는 같은 의미 있는 식별자를 계속 받을 수 있다.