생산성 높은 MSA 환경 구성하기 : 2편

1편: 15년 PHP 모놀리스를 MSA로 전환하며 마주한 현실과 인프라 자동화 해법

들어가며: 1편에서 이어지는 여정

안녕하세요, 아임웹의 생산성 팀에서 백엔드 엔지니어링을 담당하고 있는 최성국입니다.

1편에서는 15년 된 PHP 모놀리스를 MSA로 전환하면서 마주한 현실적인 문제들과 인프라 자동화를 통한 해결 과정을 다뤘습니다. 인프라 구성 시간을 일주일에서 20분으로, 99% 단축하는 성과를 거두었죠.

하지만 여전히 해결해야 할 중요한 문제들이 남아있었습니다.

• 인증 구현의 파편화: 각 팀마다 다른 방식으로 인증을 구현
• 공통 기능의 중복 구현: 로깅, 모니터링, CORS 등을 30개 서비스가 각자 구현

2편에서는 JWT 기반 인증 시스템 표준화와 Kong Gateway 도입을 통해 이 문제들을 어떻게 해결했는지, 그리고 최종적으로 신규 서비스 론칭 시간을 2주에서 하루로 단축한 과정을 상세히 다루겠습니다.

인증 시스템의 파편화, 그 심각성

기존 인증 방식의 한계

아임웹은 PHP 세션 기반의 전통적인 인증으로 시작했습니다. 세션은 서버에 사용자 정보를 저장하고 관리하는 방식으로, 모놀리스 환경에서는 문제없이 동작했습니다.

MSA 전환 과정에서 OAuth로 전환을 시도해봤지만, 예상과 다른 결과를 맞았습니다.

각 팀의 독자적 구현

각 팀이 독자적으로 인증을 구현하다 보니 다음과 같은 상황이 벌어졌습니다.

• A팀: OAuth2.0 직접 구현
• B팀: Passport 라이브러리 사용
• C팀: JWT를 자체 구현

파편화의 실질적인 문제점

이러한 파편화는 단순한 기술적 다양성을 넘어서 실질적인 문제를 야기했습니다.

1. 높은 학습 비용: 신규 입사자가 프로젝트를 옮길 때마다 새로운 인증 방식을 학습
2. 유지보수 부담: 각 인증 방식별로 다른 버그 패턴과 보안 이슈
3. 일관성 부족: 사용자 경험과 보안 수준의 편차

이런 상황에서 “마이크로서비스 인증 흐름을 자동화하고, 클라이언트 SDK와 서버 모듈로 제공하자”는 목표를 세웠습니다.

JWT 기반 인증 서버와 SDK/모듈 개발

핵심 설계 원칙

인증 문제를 근본적으로 해결하기 위해 두 가지 핵심 원칙을 세웠습니다.

1. 인증 서버의 상태 중앙화: 인증 관련 상태를 한 곳에서 관리
2. 서비스의 스테이트리스 구현: 각 서비스는 토큰에 담긴 정보만 사용

JWT 선택의 이유

MSA 환경에서 최적의 솔루션은 JWT(JSON Web Token) 기반 인증이었습니다.

JWT: 사용자 정보를 인코딩된 토큰에 담아서 주고받는 방식으로, 서버가 상태를 저장할 필요가 없어 MSA에 적합

인증 서버 구축

별도의 인증 서버를 구축하여 다음과 같이 동작하도록 했습니다.

• PHP 세션 연동: 기존 시스템과의 호환성 유지
• 토큰 발급 및 갱신: JWT 토큰의 라이프사이클 관리
• 중앙화된 인증 로직: 모든 인증 결정을 한 곳에서 처리

프론트엔드 SDK 개발

토큰 발급/갱신 요청을 자동으로 수행하는 프론트엔드 SDK를 배포했습니다. 개발자는 복잡한 토큰 관리 로직을 신경 쓸 필요 없이 SDK가 제공하는 간단한 API만 사용하면 됩니다.

백엔드 NestJS 모듈 개발

백엔드에는 NestJS 가드 및 데코레이터 모듈을 제공했습니다.

데코레이터: 함수나 클래스에 추가 기능을 부여하는 문법

가드: 요청을 처리하기 전에 인증을 검증하는 미들웨어

@SiteAuth({ ...: [...] })  // 인증 검증 데코레이터
@Get('profile')
getProfile(
  @XCode() xCode: XCode,  // X 코드 추출
  @MemberCode() memberCode: SiteMemberCode,  // 사용자 코드 추출
) {
  // 비즈니스 로직만 구현하면 됨
}

이렇게 간단한 데코레이터 몇 개만으로 토큰에서 사용자 고유 코드를 꺼내올 수 있습니다. 모든 팀이 동일한 방식으로 인증을 처리할 수 있게 되었습니다.

보안 이슈: JWT 검증의 딜레마

하지만 여기서 새로운 문제가 발생했습니다. JWT가 유효한지 판단하려면 토큰의 암호화 키가 각 애플리케이션에 공유되어야 하는 상황이었습니다. 이는 보안상으로도, 관리상으로도 좋은 방법이 아니었습니다.

이 문제가 네 번째 해결책인 API Gateway 도입의 계기가 되었습니다.

API Gateway 도입의 필요성

공통 기능 중복 구현 문제

네 번째 문제였던 “공통 기능의 중복 구현”을 해결하기 위해 API Gateway 도입을 결정했습니다. 동시에 JWT 검증 키 공유 문제도 함께 해결할 수 있었습니다.

API Gateway는 모든 API 요청이 거쳐가는 관문 역할을 합니다. 여러 마이크로서비스의 앞단에서 인증, 로깅, 라우팅 등의 공통 기능을 처리하죠.

아키텍처의 변화

API Gateway 도입으로 인한 아키텍처 변화는 다음과 같습니다.

• 이전: 각 서비스가 JWT 검증 로직 구현 (30개 서비스 = 30번 구현)
• 이후: API Gateway에서 토큰 검증, 각 서비스는 비즈니스 로직만 처리

인증 서버와의 연동

인증 서버가 발급한 토큰을 검증하는 플러그인을 개발했습니다. 이제 각 서비스는 JWT 검증 로직을 구현할 필요가 없고, API Gateway를 통과한 요청은 이미 인증된 것으로 신뢰할 수 있게 되었습니다.

30개 서비스의 중복 구현 → 1개의 Gateway에서 처리

각 스쿼드는 비즈니스 로직 API만 구현하면 되는 환경이 구성되었습니다.

Kong Gateway 선택과 구현

API Gateway 솔루션 비교

API 게이트웨이로 활용할 수 있는 플랫폼 3가지를 비교 검토했습니다.

1. Istio (쿠버네티스 네이티브 서비스 메시)

• 장점: 쿠버네티스와 완벽한 통합
• 단점: 높은 학습 곡선, 클러스터 외부 서비스 연결 불가

아임웹은 쿠버네티스로 전환 중이지만 아직 외부에 남아있는 서비스들이 있어 제외했습니다.

2. nginx/caddy (전통적인 리버스 프록시)

• 장점: 검증된 안정성
• 단점: 복잡한 설정 유지보수, 백엔드 개발자의 높은 학습 부담

location 블록, upstream 설정 등 백엔드 개발자가 알아야 할 것이 너무 많았습니다.

3. Kong Gateway (API 게이트웨이 솔루션)

• 장점: DB-less 모드, YAML 기반 설정, Git 형상 관리 가능
• 단점: 상대적으로 새로운 기술

Kong Gateway 선택 이유

Kong을 선택한 가장 큰 이유는 “선언형 설정”이 가능하다는 점이었습니다.

DB-less 모드는 Kong이 설정을 데이터베이스가 아닌 파일로 관리하는 방식입니다. 이를 통해 설정을 Git으로 버전 관리할 수 있었습니다.

선언형 설정의 장점

선언형 설정이 중요한 이유:

1. 인프라 엔지니어와 백엔드 엔지니어 간 커뮤니케이션 비용 절감
2. 라우팅 관리 주체를 개발자에게 이전
3. 모든 설정 변경 사항을 Git으로 추적

Kong DB-less 모드 구현

Kong은 DB-less 모드에서 YAML 매니페스트를 통해 Route, Service, Plugin 등의 리소스를 정의합니다.

services:
  - name: my-service
    url: <http://my-service.default.svc.farm.imweb>
    routes:
      - name: my-route
        paths:
          - /api/v1/users
        plugins:
          - name: x-auth  # JWT 검증 플러그인

누가 봐도 이해할 수 있는 직관적인 구조입니다.

설정 관리 프로세스

1. 애플리케이션 단위 파일 정의: 각 서비스별로 Kong 설정 파일 작성
2. decK를 통한 통합: Kong이 제공하는 YAML 빌드 플러그인으로 설정 통합
3. Gateway 적용: 통합된 설정을 Kong Gateway에 적용

decK: Kong의 선언적 설정 관리 도구

API Gateway가 첫 진입점이 되면서 인증·로깅·CORS 등 공통 체계를 표준화할 수 있었습니다.

최종 결과 및 성과

정량적 성과

이 전체 과정을 거쳐 현재 약 30여개의 마이크로서비스가 운영 중이며, 매주 새로운 애플리케이션이 추가되고 있습니다.

• 신규 서비스 론칭 준비 시간: 약 2주 → 하루 (93% 단축)

• 개발 환경 구축: 일주일 → 20분 이내 (99% 단축)

• 인프라·인증 작업: 98% 이상 자동화

문제별 해결 성과

정성적 성과

수치로 측정되지 않는 중요한 변화들:

• 개발자 만족도 향상: “이제 정말 코드에만 집중할 수 있어요”
• 조직 전체 ROI 증가: 인프라 작업에서 비즈니스 로직으로 리소스 이전
• 신규 입사자 온보딩 시간 단축: 표준화된 개발 환경

교훈 및 베스트 프랙티스

1. 근본 원인 분석이 핵심

“왜 느린가?”에 대한 근본 원인 분석이 핵심입니다.

MSA 자체가 느린 것이 아니라, MSA를 구성하는 과정이 느렸던 것이었습니다. 기술 자체보다는 프로세스와 도구의 문제였죠.

2. 점진적 접근법의 중요성

모든 것을 한 번에 바꾸려 하지 마세요.

작은 영역에서 자동화를 검증한 뒤 점진적으로 확대해야 합니다. 저희도 처음엔 단 하나의 서비스로 시작했습니다.

3. 시스템화를 통한 중복 제거

시스템을 구성하면 애플리케이션별 중복 작업을 제거할 수 있습니다.

인증, 로깅, 모니터링 같은 공통 기능들은 한 번만 잘 만들어두면 모든 서비스에서 활용할 수 있습니다.

4. 개발자 경험(DX) 투자의 비즈니스 가치

개발자 경험(DX)에 투자하는 것은 결국 비즈니스 가치로 돌아옵니다.

생산성 향상은 곧 더 빠른 기능 출시와 더 나은 품질로 이어집니다. 단순한 개발 편의가 아닌 비즈니스 경쟁력의 문제입니다.

마무리: MSA는 도구이지 목적이 아니다

핵심 메시지

이 긴 여정을 통해 얻은 가장 중요한 깨달음은 다음과 같습니다.

자동화와 표준화 없이는 MSA는 오히려 복잡도만 올라갑니다.

MSA는 조직 생산성의 도구이지 목적이 아닙니다.

레거시를 MSA로 전환하는 것 자체가 목표가 되어서는 안 됩니다. “왜 전환하는가?”에 대한 명확한 답이 있어야 하고, 그 답은 결국 “개발 생산성 향상”이어야 합니다.

독자들에게 드리는 조언

만약 여러분도 비슷한 여정을 앞두고 있다면:

1. 문제를 정확히 정의하세요. 기술이 문제인지, 프로세스가 문제인지 구분하세요.
2. 작게 시작하세요. 전체 시스템을 한 번에 바꾸려 하지 마세요.
3. 자동화에 투자하세요. 반복 작업은 반드시 자동화할 수 있습니다.
4. 표준화를 추진하세요. 팀별 다른 방식은 결국 기술 부채가 됩니다.

지속적인 개선

현재도 아임웹의 여정은 계속되고 있습니다. 완벽한 시스템은 없습니다. 중요한 것은 지속적으로 문제를 발견하고 해결해 나가는 자세입니다.

이 글이 비슷한 도전을 하고 계신 분들에게 도움이 되기를 바라며, 더 나은 개발 경험을 만들어가는 여정에 작은 인사이트를 제공할 수 있기를 바랍니다.

아임웹은 이런 도전적인 문제들을 함께 해결하고 더 나은 개발 경험을 만들어갈 엔지니어분들을 기다리고 있습니다.

밀도 있는 경험을 원하신다면 아임웹에 합류하셔서, 저희와 함께 깊이 있는 경험을 만들어 갔으면 좋겠습니다.

긴 글 읽어주셔서 감사합니다.