Social Login + Strategy Pattern = 🚀

✏️ 작성자: 이현우
📌 작성자의 한마디: 처음 사용하는 프레임워크더라도 다 같은 프로그래밍이더라

Motivation

다이어터들의 외식 걱정을 줄여주는 다이어트 식당 지도 앱, 헬푸미의 소셜로그인 기능을 구현하면서 아래와 같이 로그인 서비스 제공자에 분기에 따라 분기 처리가 되는 것을 보았다.

// UserService.ts
import auth from "../config/auth";

export type SocialPlatform = "kakao" | "naver" | "apple";

const getUser = async (social: SocialPlatform, accessToken: string) => {
  try {
    let user;
    switch (social) {
      case "naver":
        user = await auth.naverAuth(accessToken);
        break;
      case "kakao":
        user = await auth.kakaoAuth(accessToken);
        break;
      case "apple":
        user = await auth.appleAuth(accessToken);
        break;
    }
    return user;
  } catch(error) {
    // ETC
  }
}

이 코드 스니펫에서 다음과 같은 문제점을 느낄 수 있었다.

• 만약 소셜 인증 과정이 한 줄에 처리가 될 수 있었다면 user를 가변변수가 아닌 불변변수로 관리하여 사용할 수 있지 않았을까?
• 소셜 로그인 제공자를 이후에 더 추가하거나 삭제한다면 auth 모듈에 있는 소셜 인증 코드도 수정해야하고 switch 분기처리에 관련된 코드도 수정해야한다. 기능을 수정할 때 최대한 수정을 덜 하는 방향으로 코드를 작성할 수 없을까?

이 문제점들을 해결하기 위해 전략 패턴(Strategy Pattern)을 적용하여 코드 리팩토링을 하기로 했다.

전략 패턴(Strategy Pattern)이란

전략 패턴
객체들이 할 수 있는 행위 각각에 대해 전략 클래스를 생성하고, 유사한 행위들을 캡슐화 하는 인터페이스를 정의,

객체의 행위를 동적으로 바꾸고 싶은 경우 직접 행위를 수정하지 않고 전략을 바꿔주기만 함으로써 행위를 유연하게 확장하는 방법

게임의 예시를 들어보자.

게임에서 특정 유닛의 공격 행위를 Attack이라고 하자. 어떤 유닛은 칼로 공격을 할 수 있고, 어떤 유닛은 총으로 공격을 할 수 있다. 그렇다면 무기로 공격을 하는 행위를 위의 정의에 따라 캡슐화를 해본다면

interface Weapon {
  // 공격력을 리턴한다.
  attack(): number;
}

무기로 공격을 하는 것이기에 위와 같이 할 수 있다. 그렇다면 칼로 공격하는 행위와 총으로 공격하는 행위를 위의 인터페이스를 구현한 클래스로 생각을 한다면 아래와 같이 구현을 할 수 있을 것이다.

interface Weapon {
  attack(): number;
}

class Gun: Weapon {
  attack(): number {
    return 5;
  }
}

class Swrod: Weapon {
  attack(): number {
    return 3;
  }
}

// 사실 위와 같이 행위의 이름/Input Parameter/return 타입 등을 다 맞췄다면
// Union Type 만으로도 전략패턴을 활용할 수 있다.
// 하지만 인터페이스를 활용하여 클래스의 구현 요소를 강제함으로써 
// 발생할 수 있는 Human Error를 줄일 수 있기에 인터페이스를 활용하고자 한다.

위와 같이 특정 행위를 추상화한다면, 다른 클래스에서 이 행위를 할 때, 행위에 관련된 코드를 전면 수정하는 것이 아니라 행위가 구현된 클래스만 교체를 해주면 되어서 코드 수정을 더욱 용이하게 할 수 있다.

// 만약 전략패턴을 적용하지 않았다면?
// 동일 코드의 반복

class Human {
  healthPoint = 100;
  constrctor(point: number) {
    this.healthPoint = point;
  }
  hurt(weapon: any) {
    if (weapon instanceof Gun) {
      healthPoint -= weapon.attack()
    } else if (weapon instanceof Sword) {
      healthPoint -= weapon.attack()
    }
  }
}

// 전략 패턴을 적용하였다면
class Human {
  let healthPoint = 100;
  hurt(weapon: Weapon) {
    healthPoint -= weapon.attack()
  }
}

UseCase - Social Login

우선 Auth 모듈에 있는 행위들을 추상화할 수 있는 인터페이스를 정의한다. 헬푸미의 경우 SocialAuthStrategy라는 인터페이스로 이 행위를 추상화하였다.

export interface SocialAuthStrategy {
  execute(accessToken: string): Promise<any>;
}

이제 각 행위들을 추상화하는 클래스들을 만들도록 하자.

class NaverAuthStrategy implements SocialAuthStrategy {
  execute(accessToken: string): Promise<any> {
    return auth.naverAuth(accessToken);
  }
}

class KakaoAuthStrategy implements SocialAuthStrategy {
  execute(accessToken: string): Promise<any> {
    return auth.kakaoAuth(accessToken);
  }
}

class AppleAuthStrategy implements SocialAuthStrategy {
  execute(accessToken: string): Promise<any> {
    return auth.appleAuth(accessToken);
  }
}

이제 이 구현체를 소셜로그인에 활용할 수 있게 Path에 딸려오는 소셜 로그인 제공자에 따라서 전략을 제공해줄 수 있는 객체를 만들어보도록 하자.

JS계열에서 객체는 기본적으로 Dictionary 타입이기에 JS 언어 특성에 맞춰서 Key가 SocialPlatform type("naver", "kakao", "apple"의 리터럴 유니온 타입)이고 value가 SocialAuthStrategy인 Mapped Type을 만든다면

// export type SocialPlatform = "kakao" | "naver" | "apple";

type AuthType = {
  [social in SocialPlatform]: SocialAuthStrategy;
};

아래와 같이 Key에 따라서 행위를 가져올 수 있는 객체를 만들 수 있다.

export const authStrategy: AuthType = {
  naver: new NaverAuthStrategy(),
  kakao: new KakaoAuthStrategy(),
  apple: new AppleAuthStrategy(),
};

이제 이를 실제 코드에 적용하면?

import { authStrategy } from "./SocialAuthStrategy";

export type SocialPlatform = "kakao" | "naver" | "apple";

const getUser = async (social: SocialPlatform, accessToken: string) => {
  try {
    const user = await authStrategy[social].execute(accessToken);
    return user;
  } catch (error) {
    // ETC
  }
};

위와 같이 분기를 처리하지 않고 소셜로그인 인증을 수행할 수 있다. 또한 소셜 로그인 제공자의 변동이 있더라도 SocialPlatform에 리터럴 타입을 추가/삭제 하고 SocialAuthStrategy를 구현하는 행위 클래스(물론 이에 따른 인증 기능도 구현해야한다)만 구현하면 되기에 고유 비즈니스 로직에 큰 변동 없이 기능을 수정할 수 있다.