[Spring] 전략 패턴으로 유저 별로 다른 서비스를 제공해보자

최재혁·2022년 10월 19일

Spring

🤨 들어가며...

Messages를 사용해서 url 하드코딩을 피해보자

를 읽고 오시면 더 이해가 쉬울 것 같습니다.

현재 LOL 전적 검색 서비스 개발 중에 있습니다. 알다시피 LOL은 전 세계적으로 많은 유저들이 플레이하는 게임이고, 제작사인 Riot에서는 유저들의 국가 별로 서버를 나누어 게임을 서비스하고 있습니다.

그렇기에, 전적을 가져오기 위한 Riot API는 유저들의 서버 별로 다르게 설정되어 있습니다.

한국 서버에서 소환사 이름으로 정보 가져오기

https://`kr`.api.riotgames.com/lol/summoner/v4/summoners/by-name/{소환사이름}

일본 서버에서 소환사 이름으로 정보 가져오기

https://`jp1`.api.riotgames.com/lol/summoner/v4/summoners/by-name/{소환사이름}

(깨알같이 https:// 바로 옆 부분이 다릅니다.)

처음 시도한 해결 방법

저는 API를 호출하는 url을 messages.properties에 저장하여 불러와서 사용하고 있는데, 처음에는 이 문제를 messages의 Locale 을 달리 설정하여 해결하려고 했습니다.

한국 서버를 디폴트로 두고, 사용자의 Locale마다 다른 message 파일을 인식하여, 그에 맞는 API를 호출하는 것입니다.

[한국 서버 용 messages.properties]

summoner.puuid.by-summoner-name=https://kr.api.riotgames.com/lol/summoner/v4/summoners/by-name/{0}
summoner.tier.by-accountid=https://kr.api.riotgames.com/lol/league/v4/entries/by-summoner/{0}
summoner.by-accountid=https://kr.api.riotgames.com/lol/summoner/v4/summoners/by-account/{0}

[북미 서버 용 messages_en.properties]

summoner.puuid.by-summoner-name=https://na1.api.riotgames.com/lol/summoner/v4/summoners/by-name/{0}
summoner.tier.by-accountid=https://na1.api.riotgames.com/lol/league/v4/entries/by-summoner/{0}
summoner.by-accountid=https://na1.api.riotgames.com/lol/summoner/v4/summoners/by-account/{0}

[한국 서버 용 api 호출 url 생성]
public SummonerDto summonerDtoByAccountId(String accountId) throws IOException{
        String urlStr = messageSource.getMessage("summoner.by-accountid", new Object[]{accountId}, null);
    ...
[북미 서버 용 api 호출 url 생성]
public SummonerDto summonerDtoByAccountId(String accountId) throws IOException{
        String urlStr = messageSource.getMessage("summoner.by-accountid", new Object[]{accountId}, Locale.ENGLISH);
    ...
messageSource.getMessage의 세번째 인자로, null 값을 전달하면, 기본값으로 인식하여 messages.properties 파일에서 값을 읽어오고, Locale.ENGLISH 를 전달하면, messages_en.properties에서 값을 읽어옵니다. (없으면 기본 messages.properties)

💥 여기서 문제 발생

하지만 이는 제가 잘못 생각한 것이, Locale 에 따라 정적 메세지를 내려주는 것이 아닌 그에 맞는 api를 "호출"해야 했던 것이었습니다. 즉, 비즈니스 로직 자체가 달라지는 것이기에 메세지 국제화 기능만으로는 해결할 수 없었습니다.

🩹 해결방법 고민

먼저 생각해봐야 하는 것은, 유저들이 어디 서버에 속해있는 플레이어인지 어떻게 구별할 것인가? 입니다. 지금까지는 HTTP 요청 메세지의 Accept-Language 헤더 정보를 가지고, Locale 값을 변경하도록 했습니다.

참고 (안 읽으셔도 됩니다)

이와 관련해서 제가 틀린 내용을 작성했던 부분이 있습니다. Messages를 사용해서 url 하드코딩을 피해보자 포스트에서, 다음과 같이 설명했습니다.

엄밀히 말하면 아주 틀린 말은 아닌데, 마치 저것밖에 방법이 없다는 듯이 작성을 해놨던 것이 문제입니다.

스프링은 기본적으로 Locale 선택 방식을 변경할 수 있는 LocaleResolver 라는 인터페이스를 제공합니다.
public interface LocaleResolver {
   Locale resolveLocale(HttpServletRequest request);
   void setLocale(HttpServletRequest request, @Nullable HttpServletResponse
           response, @Nullable Locale locale);
}
스프링은 LocaleResolver의 기본 구현체로, Http 요청 메세지의 Accept-Language 헤더를 Locale 선택에 활용하는 AcceptHeaderLocalResolver를 사용합니다. 그렇기에 별다른 설정 없이도, Accept-Language로 구분이 가능했던 것이죠.

Locale 선택 방식은 변경할 수 있습니다. 어떤 구현체를 사용할 것인지에 따라 원하는 대로 변경이 가능합니다.

구현체 설명
AcceptHeaderLocaleResolver 웹 브라우저가 전송한 Accept-Language 헤더로부터 Locale 선택합니다. setLocale() 메서드를 지원 하지 않습니다.
CookieLocaleResolver 쿠키를 이용해서 Locale 정보를 구합니다. setLocale() 메서드는 쿠키에 Locale 정보를 저장합니다.
SessionLocaleResolver 세션으로부터 Locale 정보를 구합니다. setLocale() 메서드는 세션에 Locale 정보를 저장합니다.
FixedLocaleResolver 웹 요청에 상관없이 특정한 Locale로 설정합니다. setLocale() 메서드를 지원하지 않습니다.

구현체	설명
`AcceptHeaderLocaleResolver`	웹 브라우저가 전송한 Accept-Language 헤더로부터 Locale 선택합니다. setLocale() 메서드를 지원 하지 않습니다.
`CookieLocaleResolver`	쿠키를 이용해서 Locale 정보를 구합니다. setLocale() 메서드는 쿠키에 Locale 정보를 저장합니다.
`SessionLocaleResolver`	세션으로부터 Locale 정보를 구합니다. setLocale() 메서드는 세션에 Locale 정보를 저장합니다.
`FixedLocaleResolver`	웹 요청에 상관없이 특정한 Locale로 설정합니다. setLocale() 메서드를 지원하지 않습니다.

이대로 진행했을 때 문제점

그런데 이런 사람이 있다고 생각을 해봅시다.

HTTP에 문외한인 Choi, 미국 유학 가게됨

미국 유학가서 하라는 공부는 안하고 북미 서버에 계정을 생성하여 롤만 하고 있음

분개하신 부모님께 등짝을 맞으며, 한국으로 강제 귀국

미국에서의 즐거웠던 게임을 잊지 못한 Choi는 한국에서 제 서비스에 북미 서버 계정의 전적을 검색

[400 Bad Request] 그런 유저 없습니다ㅋ

???: 엥? 공부나해야지

(해피엔딩)

Choi는 왜 즐겁게 게임했던 계정 정보가 사라진 것일까요? 사실, 계정 정보가 사라진 것이 아니라, 제 서비스의 결함 때문입니다. 한국 서버에서 북미 계정을 찾으려니 못 찾는 것이죠.

만약 API 요청을 보내는 서버를 사용자의 Accept-Language 값으로 판단하게 되면, 당연히 한국 지역에서의 기본 브라우저 Accept-Language 값은 ko-KR가 우선권을 가질 것이고, 그렇다면 자동적으로 디폴트 메세지 파일인 messages.properties의 api 호출 로직이 실행되는 것입니다. Choi는 HTTP 지식에 문외한인 사람이니, 헤더 값을 임의로 변경할 수도 없겠죠.

클라이언트가 임의로 변경하지 않으면 한국에서는 한국 서버로밖에, 북미에서는 북미 서버로밖에 API 호출이 안되는 것입니다.

😲비로소 떠올린 해결 방법

이 문제에 대해서, 며칠간 고민했습니다. Locale 값으로 유저의 서버를 구분할 수 없다면 도대체 어떤 방법을 써야하지? 브라우저가 보내는 요청 메세지에 Accept-Language 이외에 유저의 계정 서버 정보를 판단할 만한 근거가 있나?..

그런데, 해결 방법은 간단했습니다. 자꾸 IntelliJ 안에서만 해결하려다 보니 머리가 굳고 있었던 모양입니다.

그냥 유저가 자신의 롤 계정이 어디 서버인지 선택할 수 있으면 되잖아?

유저가 자기가 어디 서버에서 플레이하고 있는지 모를리도 없고, 이렇게 구현하면 쉬웠던 것을 며칠째 고민하고 있었던 제가 바보같았습니다. 실제로, 많은 전적 검색 서비스가 이와 같은 방식으로 구현하고 있었습니다.

😒 그래서 어떻게 구현할 건데?

유저가 직접 요청을 보낼 API 서버를 선택할 수 있는 것으로 결정한 것은 오케이. 문제는, 어떻게 제 서버단에서 필요할 때마다 요청 보낼 서버를 갈아끼우냐는 것이었습니다.

저는 전략 패턴을 사용해보기로 했습니다.

전략 패턴이란?

비슷한 동작을 하지만, 다르게 구현되어 있는 여러 알고리즘이 클래스별로 캡슐화되어 있고 이들이 필요할 때 교체할 수 있도록 함으로써 동일한 문제를 다른 알고리즘으로 해결할 수 있게 하는 디자인 패턴

직접 행위에 대한 코드를 수정할 필요 없이 전략만 변경하여 유연하게 확장할 수 있음

제 코드에서는 추후 등장할 SummonerKrApi, SummonerNaApi가 전략이 되고, SummonerService가 그 전략을 사용하는 클라이언트 코드가 됩니다.

저는 API를 호출하는 서비스를 한국 서버, 북미 서버 각각 다음과 같이 설계했습니다.

SummonerApi에는 api 호출 메서드들이 선언되어 있고, SummonerKrApi와 SummonerNaApi에는 전달받는 Message 파일을 다르게 하여 각각 한국 서버와, 북미 서버의 api를 호출하도록 구현하였습니다.

public interface SummonerApi {

    // 유저 AccountId로 소환사 정보 가져옴
    SummonerDto summonerDtoByAccountId(String accountId) throws IOException;

    // 소환사 이름으로 소환사 정보 가져옴
    SummonerDto summonerDtoBySummonerName(String summonerName) throws IOException;

    // 유저 puuId로 소환사 랭킹 정보 가져옴
    List<SummonerTierDto> summonerTierByAccountId(String accountId) throws IOException;
}

@RequiredArgsConstructor
@Component
public class SummonerKrApi implements SummonerApi {

    private final SummonerApiService summonerApiService;
    private final MessageSource messageSource;

    @Override
    public SummonerDto summonerDtoByAccountId(String accountId) throws IOException{
        String urlStr = messageSource.getMessage("summoner.by-accountid", new Object[]{accountId}, null);
        return summonerApiService.getSummonerDto(urlStr);
    }
......

@RequiredArgsConstructor
@Component
public class SummonerNaApi implements SummonerApi{

    private final SummonerApiService summonerApiService;
    private final MessageSource messageSource;
    @Override
    public SummonerDto summonerDtoByAccountId(String accountId) throws IOException {
        String urlStr = messageSource.getMessage("summoner.by-accountid", new Object[]{accountId}, Locale.ENGLISH);
        return summonerApiService.getSummonerDto(urlStr);
    }
....

보시다시피, 컴포넌트 스캔을 통해 각각 스프링 빈으로 등록하고 있습니다.

그리고 이 Api 빈들을, SummonerService에 주입해서 사용하고 있습니다. 이때, SummonerService는 유저가 등록된 게임서버에 맞게 SummonerKrApi, SummonerNaApi 중 하나를 선택해야 합니다.

저는 이를 Map 으로 구현하고자 했습니다.

@RequiredArgsConstructor
@Service
public class SummonerService {


    private final Map<String, SummonerApi> apiMap;

    public String getPuuidByAccountId(String accountID, String locale) throws IOException {
        log.info("소환사의 puuid: {} ", apiMap.get(locale).summonerDtoByAccountId(accountID).getPuuid());
        return apiMap.get(locale).summonerDtoByAccountId(accountID).getPuuid();
    }
....

private final Map<String, SummonerApi> apiMap;

필드 부분을 보시면, Map<빈의 이름, 빈의 타입> 형태로 주입받고 있습니다.

원래 스프링 컨테이너가 빈을 조회할 때, 타입이 중복되는 빈이 있으면 어떤 빈을 사용할지 불확실하니까NoUniqueBeanDefinitionException 에러를 내뱉게 됩니다. 하지만 중복되는 타입의 빈이 둘다 필요하다면? 이렇게 Map을 활용해서 구현할 수 있습니다.

apiMap.get(locale).summonerDtoByAccountId(accountID)

주입한 apiMap에서, locale 이라는 변수로 전략에 맞는 빈을 꺼냅니다. 여기서 전략은 유저가 어떤 서버를 선택할지겠죠? locale 변수에는 빈의 이름이 할당되어 있습니다. 예를 들어, SummonerKrApi 빈을 사용하고 싶으면 summonerKrApi처럼 빈의 첫 글자를 소문자로 만들면 빈의 이름이 됩니다.

사용하는 법은, 첫번째 인자로 소환사명, 두번째 인자로 사용할 빈의 이름을 전달하면 됩니다.

@Test
    void getPuuidBySummonerName() throws IOException {
        System.out.println(summonerService.getPuuidBySummonerName("hide on bush", "summonerKrApi"));
    }

결과 (puuid란 api key에 따라 변경되는 유저들만의 고유한 식별자입니다. 신경 안쓰셔도 됩니다.)

7dUcabFSQP6kM1SDnNqaCn2_j8YEa49aXfIAVuPVQpzsVaoqRN9jC1gYu0x9handyaMIdKRuqz1swA

만약, Bean으로 다른 전략인 SummonerNaApi를 전달하면 어떻게 될까요?

@Test
    void getPuuidBySummonerName() throws IOException {
        System.out.println(summonerService.getPuuidBySummonerName("hide on bush", "summonerNaApi"));
    }

java.io.IOException: Server returned HTTP response code: 400 for URL: https://na1.api.riotgames.com/lol/summoner/v4/summoners/by-name/hide on bush

북미 서버에는 그런 유저 없어요~ 라고 400 에러를 보여주네요.

전략을 달리함에 따라 내부 동작이 변한다는 것을 확인할 수 있었습니다.

마무리

이번에는 사용자의 요구에 따라 다른 로직을 제공하는 것을, 전략 패턴으로 구현해 보았습니다.

사실 이 지식은 정말 예전에 수강한 인프런에서 김영한 강사님의 스프링 핵심 원리 강의에서 나온 내용을 활용했습니다. (김영한 강사님 스프링 커리큘럼의 첫번째 강의입니다.)

그 당시에는 필기하면서도 언제, 어떤 방식으로 이런 기술이 사용될지 가늠도 안됐었는데, 배운 지식을 제 나름대로 실전에서 사용해 본다는 것이 이렇게 재밌는 일일 줄 몰랐습니다.

지금도 공부하면서 이게 왜 필요하지? 어떤 방식으로 사용이 되는거지? 궁금한 것들 투성이지만, 경험이 더 쌓이면 이해할 수 있겠죠? 차근차근 달려봐야겠습니다.

읽어주셔서 감사합니다. 틀린 부분 지적과 궁금한 점 댓글 환영합니다!

📚Reference

https://juntcom.tistory.com/8

인프런 김영한님 강의 - 스프링 핵심 원리

최재혁

잘못된 고민은 없습니다

이전 포스트

# 잘 안 읽히는 책 읽는 법: SQ3R

다음 포스트