ProjectWith의 Amplify 적용을 통한 운영 효율성 개선 사례

ProjectWith는 블록체인 기반의 스포츠 데이터 자산화 회사입니다. 팬, 아마추어, 유소년 등 스포츠 시장에서 기존에 주목받지 못한 대상들의 데이터를 수집하고, 이를 통해 새로운 가치를 창출하고 참여자들에게 환원하는 서비스 기획 및 운영에 특화되어 있습니다. 현재 한국프로축구연맹, 대한축구협회 등 다양한 스포츠 유관 기관과 함께 축구 팬 및 선수를 대상으로 흥미롭고 다채로운 데이터 자산화 서비스를 제공하고 있습니다.

ProjectWith는 지난해(2023년) Google Cloud Platform(GCP) 환경에서 컨테이너를 이용해 운영하던 서비스를 Amazon Web Services (AWS)의 Amazon Elastic Container Service (Amazon ECS)로 마이그레이션 했습니다 [별첨 1]. 서비스의 다른 영역에서는 계속해서 Firebase의 푸시 알림, 데이터베이스, 스토리지, 분석 기능을 잘 활용하고 있었지만, GCP와 AWS를 동시에 운영하는 비효율성을 고려해 이 기능들을 AWS Amplify로 이전하기로 했습니다.

이번 블로그 포스팅에서는 Google Firebase에서 AWS Amplify로 마이그레이션을 한 ProjectWith의 경험을 공유하고자 합니다.

AWS Amplify 소개

AWS Amplify는 클라우드 기반의 웹 및 모바일 애플리케이션을 빠르고 쉽게 구축할 수 있도록 지원하는 개발 플랫폼입니다. Amplify는 프런트엔드 개발자가 AWS 서비스를 활용하여 다양한 기능과 혁신적인 애플리케이션을 구축할 수 있도록 돕는 도구와 서비스로 구성됩니다. 예를 들어, Amplify CDK를 사용하면 간단하게 앱의 백엔드를 구성할 수 있을 뿐 아니라 인증 등의 기능도 쉽게 추가할 수 있습니다. 또한 Amplify는 웹 및 앱 개발을 위한 다양한 개발 언어를 지원하며, 서버리스 방식으로 운영 및 관리가 용이합니다.

Amplify 도입 시 고려했던 사항

1. 운영 포인트 감소

마이그레이션 전에는 Firebase와 AWS를 동시에 사용하면서, 모든 개발자가 GCP와 AWS 두 개의 클라우드 계정을 관리해야 했습니다. 이에 따라 같은 기능을 제공하는 클라우드 상품이더라도 각 CSP에서 제공하는 서비스를 별도로 학습하고 사용할 필요가 있었습니다. Firebase를 AWS Amplify로 마이그레이션 하면서, 함께 사용하던 일부 GCP 서비스들도 AWS로 마이그레이션 하면, 이를 통해 분산되어 있던 개발 환경과 서비스 운영 환경이 모두 AWS로 통합되어 운영 부담이 줄어들 것으로 판단했습니다.

2. Firebase의 기능 대체 여부

Firebase에서는 푸시 알림 기능과 데이터베이스 기능을 활용해 사용자 맞춤 푸시 알림 및 알림톡 서비스를 운영해 왔습니다. AWS Amplify로 마이그레이션하기 위해서는 이러한 기능들을 반드시 지원해야 했으며, 기존의 타겟 푸시 대상 그룹을 더욱 세분화하고자 하는 개발 & 운영적 요구사항도 있었습니다. Amazon Pinpoint를 활용해 맞춤형 메시지 발송이 가능하고, AppSync와 DynamoDB를 통해 사용자 맞춤 푸시 알림 및 알림톡 기능을 충분히 구현할 수 있을 것이라 판단하였습니다. 또한, Pinpoint의 Endpoint 속성을 활용해 기존보다 더욱 세분화된 유저 그룹 관리가 가능할 것으로 예상했습니다.

3. 기존 개발 스펙 유지 가능성

ProjectWith는 Firebase에서 Spring(Kotlin), Flutter(Dart), React.ts(Typescript)를 이용해 서비스를 개발하고 있었습니다. 만약 Amplify에서 이러한 개발 프레임워크를 지원하지 않는다면, 서비스의 구조적인 변경이 불가피했기에 이에 대한 지원여부가 매우 중요한 의사결정 포인트였습니다. 다행히 AWS Amplify에서는 ProjectWith가 사용하는 개발프레임워크 뿐만 아니라 그 외에도 다양한 개발 프레임워크를 지원하고 있었기 때문에 기존 서비스의 구조적인 변경없이 마이그레이션이 가능할거라 판단했습니다.

4. 서비스 영향 최소화

Firebase에서 Amplify로 마이그레이션 해야 하는 기능은 크게 앱에서 사용하는 이미지, 정적 웹페이지 등이 포함되어 있는 Firebase Storage, 디바이스로 맞춤형 푸시 알림을 전송하는 Firebase Cloud Messaging(FCM), 결제 상태 정보등을 저장하는 Firebase Database 세가지였고, 이 세 기능이 유기적으로 통합되어 있어 마이그레이션을 진행할 때 서비스 영향에 대한 사전 검토가 필요했습니다.

Amplify 마이그레이션 과정에서의 어려움

마이그레이션을 진행하는 것으로 결정한 후 실제로 진행하면서 몇 가지 어려운 점들이 있었습니다.

첫 번째로, Firebase 마이그레이션에서 가장 어려운 과정이라고 생각했던 부분은 Firebase Storage(Cloud Storage)였습니다. 하지만 ProjectWith는 지난해 이미 Firebase Storage의 부분을 S3 Bucket으로 마이그레이션을 완료한 상태였기 때문에 Firebase Storage 마이그레이션에 대한 부담은 조금 덜어낼 수 있었습니다.

두 번째로 어려웠던 점은 맞춤형 푸시 기능을 Firebase에서 Pinpoint로 마이그레이션 하는 과정이었습니다. 기존에는 Firebase의 FCM 토큰을 기반으로 맞춤형 푸시 기능을 구현해 사용하고 있었습니다. 이 기능은 FCM에 맞춰 설계된 기능이었기 때문에 Pinpoint에 맞게 재설계가 필요했습니다. 특히 메시지를 전달받는 유저 그룹이 점차 세분화되면서 FCM 토픽이 늘어나며 관리에 어려움을 느끼고 있었는데요. 이 문제는 Amplify Pinpoint의 Endpoint 속성에 FCM 토큰값과 유저 그룹을 주입하는 방식으로 해결했습니다. 이를 통해 기존 FCM 토큰을 그대로 활용하면서도, 유저 특성에 따른 다양한 속성을 Endpoint에 주입해 그룹별 특화된 푸시 메시지를 프로덕트 서버에 부담을 주지 않고 구현할 수 있었습니다.

마지막으로 Firebase의 Firestore Database의 데이터를 GraphQL과 AWS AppSync로 마이그레이션 하는 작업은 앞의 두 작업에 비해 비교적 간단했습니다. Firestore Database는 Document기반이었고, 이는 GraphQL 기반 방식과 데이터 모델에 차이가 있습니다. 하지만 다행히도 ProjectWith는 Firestore Database도 정해진 Document 구조에 따라 데이터를 저장하고 관리했기 때문에 큰 어려움 없이 마이그레이션을 진행할 수 있었습니다.

그 외에 서비스 영향을 줄 가능성이 크지 않았던 유저 통계 기능은 모바일 애플리케이션 코드 및 웹 코드에 Amplify 기능을 추가하기만 하면 쉽게 적용할 수 있었기 때문에 간단하게 마이그레이션을 완료할 수 있었습니다. 현재는 AWS Lambda 등과의 연결을 통해 Amplify의 유저 통계 수집 및 분석을 고도화하고 있습니다.

Amplify 아키텍처 구성

1. Amplify Data

현재 ProjectWith에서는 KFA 챌린지와 K리그 판타지 두 가지 서비스에서 유저 결제가 이루어지고 있습니다. 이 두 서비스의 결제 처리는 ProjectWith의 전용 결제 서버를 통해 이루어지며, 결제 데이터는 Amplify Data를 통해 저장 및 관리됩니다. 만약 저장 중 실패가 발생하거나 이상 결제 데이터가 감지될 경우, AWS Lambda와 별도로 구축한 SMS 서버를 통해 관리자에게 즉시 알림이 발송됩니다

2. Amplify Analytics

ProjectWith의 모든 모바일 및 웹 서비스에서 수집된 유저 데이터는 Amplify Analysis를 통해 분석됩니다. Amplify를 사용하여 유저 속성을 관리하고 있으며, 이를 바탕으로 타깃팅 된 푸시 메시지가 전송됩니다. 또한 유저 행동 데이터는 AWS Amplify, Amazon Pinpoint, Amazon Kinesis를 통해 관리되며, Lambda를 이용해 분석 가능한 형태로 재가공된 후 주기적으로 Amazon S3에 저장됩니다. 앱 크래시와 같은 이상 데이터는 Event Bridge를 통해 수집 및 처리됩니다.

3. Amplify에서 제공하는 CI/CD

ProjectWith의 웹 기반 서비스는 Amplify 마이그레이션 이전 GitHub Action과 AWS CodePipeline을 이용해 CI/CD 구성하고 있었는데요, Amplify에서 제공하는 CI/CD 기능을 사용하는 것으로 변경했습니다.

Amplify 적용 후기

좋았던 점

1. AWS 서비스와의 통합으로 운영 효율성 증대

기대했던 것처럼 마이그레이션 이후에는 ProjectWith가 활용하고 있는 다양한 AWS 서비스와 쉽게 연동할 수 있어 운영에 대한 부담이 많이 줄었습니다. 기존에 매 주 목요일 오전에 진행했던 기술 세션에서 GCP와 AWS 두 CSP 서비스 학습에 많은 시간을 소요했는데, 마이그레이션 이후에는 이를 절반으로 줄이고 AI, 블록체인 등 회사의 중심 기술에 세션 시간을 할애할 수 있게 되었습니다. 특히, 기술적으로 높은 성숙도를 지닌 AWS의 다양한 서버리스 서비스를 함께 연동하여 활용함으로써 서비스에 대한 안정성과 신뢰도를 향상시킬 수 있었습니다.

2. 데이터에 대한 접근 권한을 정교하게 설정하여 보안 강화

AWS는 AWS Identity and Access Management (AWS IAM)을 사용하여 API 수준의 세분화된 권한 관리가 가능합니다. AWS Amplify도 역시 AWS IAM 역할과 연결하여 보다 세밀한 DB 접근 권한 관리를 할 수 있어 보안 수준이 크게 향상되었습니다.

3. Github action의 ARM 인스턴스에 대한 빌드 이슈 해결

기존에는 특정 코드의 Github action의 ARM 인스턴스에서 Docker 이미지 빌드가 정상적으로 실행되지 않는 이슈가 있었습니다. ProjectWith 개발팀은 그 이슈를 해결하기 위해 오랜시간 고군분투했지만, 해당 이슈에 대한 원인을 찾지 못해 CI/CD 파이프라인에서 일부 작업을 수동으로 처리하고 있었습니다. 하지만 Amplify Build로 전환 후에는 이 빌드 문제가 바로 해결되어 CI/CD 파이프라인의 모든 작업이 자동 처리될 수 있었습니다. 이를 통해 CI/CD 배포 시간을 30% 정도 감소시켰습니다. 그리고 그 시간만큼 개발자는 비즈니스 로직을 개발하는 작업에 집중함으로써 업무의 효율성이 증대되었습니다.

4. 보다 세분화된 푸시 메세지 제공

기존 유저 타겟 푸시는 두 가지 방식으로 나누어 진행되었습니다. 첫째는 완전 개인화된 푸시 메시지, 둘째는 그룹별 타겟 푸시 메시지였습니다. 이 중 그룹별 타겟 푸시 메시지 구현을 Amazon Pinpoint의 속성 부여 기능을 통해, 기존보다 손쉽게, 그리고 서비스 로직에 부담을 주지 않도록 구현할 수 있게 되었습니다. 특히 ProjectWith 서비스는 스포츠 경기나 축구 아카데미 이벤트 시 다양한 유저 그룹에 푸시 메시지를 보내야 하는데, 마이그레이션 이후 이러한 작업을 데이터베이스가 아닌 Amplify와 연결된 별도 서버에서 전담하게 하여, 경기 시 데이터베이스 사용량을 5~10% 정도 줄일 수 있었습니다. Flutter (모바일) 에서 Endpoint 유저 속성을 부여하고, 유저 속성에 따라 푸시메시지를 보내는 과정은 아래 별첨 2를 통해 더 자세히 확인하실 수 있습니다.

아쉬운 점

AWS Amplify를 처음 접했을 때, 콘솔 화면에서 기능 선택 시 간단한 활용 예시와 상세한 설명을 제공하지 않는 부분에서 UI의 편의성이 조금 아쉽다는 생각을 했습니다. 이 문제는 AWS Amplify의 Document에 충분히 잘 설명이 되어있었고, ProjectWith 개발팀은 linux 터미널 환경에서 프로그래밍 방식으로 작업하는 것에 더 익숙했기 때문에 큰 문제는 되지 않았지만 개선이 되면 더 좋을 것 같습니다. 그리고 모바일 애플리케이션의 충돌이나 버그리포팅을 제공하는 서비스인 Firebase Crashlytics의 부재도 조금 아쉬웠습니다. 다행히 ProjectWith는 Firebase Crashlytics에 대한 의존도가 높지 않아 Amazon Pinpoint, Amazon Kinesis, Amazon EventBridge와의 연동을 통해 버그리포팅 기능을 대체할 수 있었습니다.

마무리

이렇게 ProjectWith는 AWS Amplify 도입을 통해 클라우드 서비스에 대한 관리 포인트를 줄이고, 더 효율적이고 안정적인 서비스를 사용자에게 제공할 수 있게 되어 마이그레이션 결과에 매우 만족하고 있습니다.

별첨 1

별첨 2

ProjectWith가 서비스하는 유소년 개인 기량 인증제 “KFA 챌린지”는 축구 아카데미를 관리하고, 태권도의 띠 시스템처럼 유소년의 축구 기량을 인증해 주는 서비스입니다. 한 아카데미 안에는 여러 소규모 학급이 있고, 이 학급별로 푸시 알람을 보내주어야 하는데요, Flutter와 Amplify를 활용하여 위 기능을 구현하는 예제를 간단히 준비해 보았습니다.

1. Amplify Pinpoint 엔드포인트와 사용자 연결을 위한 유저 속성 주입

타깃 푸시 메시지 전달을 위해 다음과 같이 Flutter 코드에서 유저 속성을 주입했습니다.

// Example Code : Identifying a user profile using AWS Pinpoint 

final userProfile = AWSPinpointUserProfile(
  name: userName,
  email: userEmail,
  /// User attributes are shared per userID
  userAttributes: {
  'academy' : [academyID],
  'class' : [classID],
},
/// endpoint attributes can be set differently for each device.
customProperties: CustomProperties()
..addStringProperty('deviceToken',deviceToken),
);

await Amplify.Analytics.identifyUser(
  userId: academyID (아카데미 유저의 경우)/ chieldID (아이 유저의 경우),
  userProfile: userProfile,
);

2. 아카데미 속성을 가진 유저들을 세그먼트로 생성

3. 캠페인 생성

표준 캠페인(일정 또는 이벤트에 따라 일괄 처리) / AB 캠페인(AB 집단별 다른 처리)
액션 선택 (이메일, 인앱 메시징, 푸시 알림, 사용자 지정)
샘플은 표준 캠페인 – 푸시 알림

4. 세그먼트 설정

2번 작업에서 생성한 세그먼트 선택

5. 메시지 생성

푸시 알림 템플릿 선택 / 새 푸시 알림 생성

6. 캠페인 시작 시점 선택

특정 시간 / 특정 이벤트 트리거 선택 가능
이외에 다양한 설정 가능(실행 시각, 기간, 메시지 수 등)

AWS 기술 블로그