Ins DevLog

자동 배포 환경 구축

Inseong2 — Mon, 31 Aug 2026 09:44:00 +0900

안녕하세요. 스타트업에서 프론트엔드 개발을 맡고 있는 inseong입니다

이번 글에서는 GitHub Actions 활용해 Next.js를 NHN Cloud에 자동 배포하는 방법을 정리해보려고 합니다.

이전에는 AWS 환경에서 S3와 CloudFront를 활용한 배포 자동화를 구성했었는데요. 이번에는 NHN Cloud + Nginx + Next.js
Static Export 환경에서 CI/CD를 구성하면서 AWS와는 어떤 점이 달랐는지도 함께 정리해보겠습니다.

배포 환경 구성도

Dev / Prod 브랜치 구성

▫️ 회사마다 브랜치 전략은 다를 수 있지만, 이 글에서는 개발 작업을 진행할 Dev 브랜치와 실제 배포를 위한 Prod 브랜치를 생성해 사용합니다.

▫️ Dev 브랜치에서 개발 및 테스트를 진행하고, 작업이 완료되면 변경 사항을 Prod 브랜치에 반영합니다.

Next.js Static Export 설정

React / Vite는 빌드 시 생성되는 dist/ 디렉터리를 Nginx에 바로 서빙할 수 있습니다.
Next는 기본적으로 .next/에 빌드되기 때문에, 정적 파일로 배포하려면 output : 'export' 설정을 통해 out/ 디렉터리를 생성해야 합니다.

▫️ NHN 서버에서 Node.js 서버를 상시 실행하는 방식이 아니라, Next.js의 정적 빌드 결과물을 Nginx가 직접 서빙하는 방식으로 배포합니다.

▫️ 따라서 next.config.ts에 output: 'export' 설정을 추가해 npm run build 실행 시 out/ 디렉터리가 생성되도록 구성합니다.

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  reactStrictMode: true,
  output: 'export',
  images: {
    unoptimized: true,
  },
}

export default nextConfig

NHN 서버에 프로젝트 배포

▫️ Next의 정적 배포 설정을 완료했다면, 이제 NHN Cloud 서버에 프로젝트를 배포합니다.

▫️ 이번 프로젝트에서는 NHN인스턴스에 SSH로 접속한 뒤 GitHub Repository를 Clone하고, 서버에서 직접 의존성 설치 및 빌드를 진행합니다.

▫️ 하나의 Cloud 서버에서 여러 프로젝트가 운영되고 있기 때문에 서버의 Node 버전을 전역으로 변경하지 않고 NVM을 사용해 프로젝트별 노드 버전을 관리합니다.

Nginx 파일 구성

▫️ /etc/nginx/sites-enabled 경로로 이동한 뒤, 해당 서비스에서 사용할 Nginx 설정 파일을 생성합니다.

# ① HTTP 요청을 HTTPS로 리다이렉트
server {
    listen 80;
    server_name dev.comfac.kr;

# HTTPS 인증서를 만든 경로
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    return 301 https://$host$request_uri;
}

# ② HTTPS 및 SSL 인증서 설정
server {
    listen 443 ssl http2;
    server_name dev.comfac.kr;

    ssl_certificate /etc/letsencrypt/live/dev.comfac.kr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/dev.comfac.kr/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;

    # ③ Next.js 빌드 결과물 지정
    root 파일경로/out;
    index index.html;

    # ④ Next.js 정적 페이지 라우팅
    location / {
        try_files $uri $uri.html $uri/ =404;
    }
}

가비아에서 도메인 연결

▫️ Nginx 설정까지 완료했다면, 이제 dev.comfac.kr이 NHN Cloud 서버를 바라보도록 DNS를 연결합니다.

▫️ 해당 메인 도메인의 DNS 관리로 들어가서 A타입의 서브도메인명, NHN 인스턴스의 아이피를 연결합니다.

HTTPS 적용

▫️ 도메인과 NHN Cloud 서버 연결이 완료되었다면, HTTPS 통신을 위해 SSL 인증서를 적용합니다.

▫️ 이번 프로젝트에서는 무료 SSL 인증서를 제공하는 Let's Encrypt와 Certbot을 사용했습니다.

1️⃣ Certbot 설치

sudo dnf install -y epel-release
sudo dnf install -y certbot

2️⃣ 인증서 검증에 사용할 경로 생성

sudo mkdir -p /var/www/certbot

3️⃣ Nginx 구성 파일

location /.well-known/acme-challenge/ {
    root /var/www/certbot;
}

4️⃣ 설정 확인 및 인증서 발급

sudo nginx -t
sudo systemctl reload nginx

sudo certbot certonly \
  --webroot \
  -w /var/www/certbot \
  -d dev.comfac.kr

5️⃣ 확인 및 갱신 테스트

curl -I "도메인 주소"
sudo certbot renew --dry-run

GitHub Actions로 자동 배포 구성

▫️ 지금까지는 NHN 서버에 직접 접속해 git pull, npm ci, npm run build를 실행하여 배포를 진행했습니다.

▫️ 이제부터는 Prod 브랜치에 Push 이벤트가 발생하면 GitHub Actions가 자동으로 실행되어 NHN Cloud 서버의 코드를 최신 상태로 동기화하고 빌드하도록 구성합니다.

처음 시도했던 방식

▫️ 처음에는 GitHub Actions의 GitHub-hosted Runner에서 SSH를 통해 NHN Cloud 서버에 접속하는 방식으로 자동 배포를 구성했습니다.

▫️이를 위해 Repository Secrets에 서버 접속 정보를 등록했습니다.

NHN_HOST
NHN_USER
NHN_SSH_KEY
NHN_KNOWN_HOSTS

ssh: connect to host *** port 22: Connection timed out

▫️ NHN Cloud의 보안 그룹을 확인해보니 22포트가 보안을 위해 회사 등 특정 IP에서만 접근할 수 있도록 /32로 제한되어 있었습니다.
▫️ GitHub-hosted Runner는 해당 허용 IP에 포함되지 않기 때문에 SSH 연결 자체가 NHN 보안그룹에서 차단되고 있었습니다.

해결 방향

▫️ GitHub Actions를 위해 SSH 포트를 모든 IP에 개방할 수도 있지만, 하나의 서버에서 여러 사내 서비스가 함께 운영되고 있기 때문에 보안상 해당 방법은 사용하지 않았습니다.

▫️ 대신 외부 GitHub Runner가 서버에 접속하는 구조가 아닌, NHN Cloud 서버에서 GitHub Actions 작업을 가져오는 Self-hosted Runner 방식으로 변경했습니다.

GitHub Runner 설치

mkdir actions-runner && cd actions-runner

Runner 패키지 다운로드

curl -o actions-runner-linux-x64-<VERSION>.tar.gz \
  -L https://github.com/actions/runner/releases/download/<VERSION>/actions-runner-linux-x64-<VERSION>.tar.gz
  
  tar xzf ./actions-runner-linux-x64-<VERSION>.tar.gz

깃허브 저장소 연결

./config.sh \
  --url https://github.com/<OWNER>/<REPOSITORY> \
  --token <RUNNER_TOKEN>

일회성 토큰 받는법

▫️Settings ➡️ Actions ➡️ Runners ➡️ New self-hosted runner

Self-hosted Runner 사용 시 주의점
Self-hosted Runner는 GitHub Actions의 명령을 실제 서버 내부에서 실행합니다. 따라서 외부 사용자가 임의의 Workflow를 실행할 수 없도록 Repository 권한을 관리하고, 신뢰할 수 있는 브랜치의 배포 Workflow에서만 Runner를 사용하는 것이 좋습니다.

설정 완료 후 테스트

▫️ ./run.sh로 Runner 연결을 확인한 뒤, SSH 세션이 종료되어도 Runner가 계속 동작할 수 있도록 서비스로 등록합니다.

sudo ./svc.sh install
sudo ./svc.sh start
sudo ./svc.sh status

깃허브 워크플로우 작성

▫️ Prod 브랜치에 Push 이벤트가 발생하면 Self-hosted Runner가 작업을 수신하고, NHN Cloud 서버 내부에서 Prod 브랜치 동기화 → 의존성 설치 → Next.js 빌드 → out/ 갱신까지 자동으로 수행하도록 Workflow를 구성합니다.

▫️ Nginx는 이미 파일경로/out을 바라보고 있기 때문에 빌드가 완료되면 별도의 Nginx 재시작 없이 새로운 배포 결과가 바로 반영됩니다.

name: Deploy Comfac Homepage

on:
  push:
    branches:
      - Prod
  workflow_dispatch:

permissions:
  contents: read

concurrency:
  group: comfac-homepage-dev-deployment
  cancel-in-progress: true

jobs:
  deploy:
    name: Deploy static site to NHN Cloud
    runs-on:
      - self-hosted
      - Linux
      - X64
      - comfac-homepage
    timeout-minutes: 30

    steps:
      - name: Sync Prod and build the static site
        run: |
          set -euo pipefail

          readonly project_dir='파일경로'
          readonly expected_node_version='v24.16.0'

          cd "$project_dir"

          git fetch origin

          if git show-ref --verify --quiet refs/heads/Prod; then
            git switch Prod
          else
            git switch --track -c Prod origin/Prod
          fi

          git reset --hard origin/Prod

          export NVM_DIR="$HOME/.nvm"
          if [ ! -s "$NVM_DIR/nvm.sh" ]; then
            echo "nvm is not installed for the deployment user." >&2
            exit 1
          fi

          . "$NVM_DIR/nvm.sh"
          nvm use

          actual_node_version="$(node -v)"
          if [ "$actual_node_version" != "$expected_node_version" ]; then
            echo "Expected Node $expected_node_version, but found $actual_node_version." >&2
            exit 1
          fi

          node -v
          npm -v

          nice -n 10 npm ci
          nice -n 10 npm run build

          test -f out/index.html
          test -d out/_next

          deployed_sha="$(git rev-parse HEAD)"

          {
            echo "## 컴팩 홈페이지 개발 서버 배포 완료"
            echo
            echo "- Branch: Prod"
            echo "- Commit: \`$deployed_sha\`"
            echo "- Target: https://dev.example.com
            echo "- Node: 24.16.0"
          } >> "$GITHUB_STEP_SUMMARY"

Next 프로젝트를 NHN + Nginx 환경에 배포하고, GitHub Actions를 이용해 자동 배포 환경을 구성하는 과정을 정리해보았습니다.

나만의 도메인 배포하기

Inseong2 — Tue, 18 Aug 2026 16:08:14 +0900

안녕하세요. 스타트업에서 프론트엔드 개발을 맡고 있는 inseong입니다

이번 글에서는 가비아에서 직접 구매한 도메인을 AWS 서비스를 활용해 프로젝트에 연결하고 배포하는 방법을 소개해 보겠습니다.

가비아 도메인 구매

▫️ 원하는 도메인을 구매한 뒤 가비아 > 서비스 관리 페이지에 접속하면 아래와 같이 구매한 도메인이 표시됩니다.

AWS Route 53 설정

호스팅 영역 생성

▫️도메인 이름 : 가비아에서 구매한 도메인 ( https:// 없이 )

▫️설명 : (선택) 도메인 설명

▫️유형 : 퍼블릭 호스팅 영역

가비아 네임 서버 등록

▫️ 전체 도메인 > 도메인 상세 > 네임 서버로 이동한 뒤, 네임서버 목록에 Route 53에서 생성된 4개의 NS 레코드를 등록합니다. (뒤에 온점은 삭제)

ACM SSL 인증서 발급

▫️ 미국 동부 : us-east-1에서 만들기

인증서 요청

구성 설정

▫️도메인 이름 : kickon.kr

▫️다른 이름 추가 : *.kickon.kr (*를 추가하면 www.kickon.kr, api.kickon.kr과 같은 서브도메인에서도 동일한 인증서를 사용할 수 있습니다.)

인증서 상태 확인 및 Route 53에서 레코드 생성

▫️ Route 53에서 레코드 생성을 클릭하여 2단계에서 생성한 레코드를 먼저 적용합니다. 이후 약 5분 정도 지나면 인증서가 자동으로 발급됩니다.

S3 버킷 생성

서울 리전으로 변경

▫️ 리전은 서비스 대상 지역과 가장 가까운 곳으로 선택하는 것이 좋습니다. 가까운 리전을 사용할수록 지연 시간이 줄어들어 사용자에게 더 빠른 서비스를 제공할 수 있습니다.

버킷 만들기

▫️ 버킷 이름 : 해당 프로젝트의 닉네임

▫️ 객체 소유권 : ACL 비활성화됨(권장)

▫️ 모든 퍼블릭 액세스 차단: true

S3 객체에 빌드 파일 업로드

▫️ React + Vite 프로젝트는 빌드(npm run build)를 수행하면 dist 폴더가 생성됩니다. 생성된 dist 폴더의 모든 파일을 앞에서 생성한 S3 버킷에 업로드해 주세요.

▫️ Next일 경우

Cloudfront 생성

플랜 선택

▫️무료 버전 선택

설명 옵션 선택

▫️ Distribution name : 프로젝트 닉네임

▫️ Description : (선택) 프로젝트 설명

▫️ Distribution type : Single website or app

▫️ Domain : 비워둠 ( 이미 ACM 인증서를 발급받았기 때문에 사용할 필요 X )

Origin type 설정

▫️Origin type : Amazon S3

▫️S3 Origin : Browse S3 클릭 → -admin 클릭

Enable security

▫️설정 그대로 유지 후 Next

Review and Create

▫️최종 설정 확인 후 Create distribution

▫️Add domain : 해당 되는 도메인 입력 ( 서브 도메인으로 관리자를 배포하기 위해 admin.kickon.kr 로 설정했습니다. )

▫️기본 루트 객체 : index.html

Route domains to CloudFront

▫️Route domains to CloudFront 누르면 Set up routing automatically 클릭

마이폿 앱을 만들면서

Inseong2 — Fri, 14 Aug 2026 13:40:59 +0900

안녕하세요. 스타트업에서 프론트엔드 개발을 하고 있는 inseong입니다.

요즘 제 취미는 앱 개발이에요. 여러분들은 머릿속으로만 생각했던 상상을 실제 앱으로 만들어보신 적 있으신가요?

지금의 생각과 고민들을 나중에도 생생하게 기억하고 싶어서, 제가 만들고 있는 마이폿이라는 앱의 개발 과정을 하나씩 포스팅해보려고 합니다.

마이폿 앱 개발의 첫 시작

사실 마이폿이 제가 처음 만든 앱은 아니에요.

제 첫 앱은 당당이라는 앱이었습니다.

당뇨가 있는 분들이 혈당을 기록하고, 당화혈색소 수치가 정상인지 높은지 한눈에 확인할 수 있도록 만든 앱이었어요.

부모님을 위해 시작한 앱이었는데, 감사하게도 이 앱이 계기가 되어 지금 다니고 있는 회사에 취업하는 데에도 많은 도움이 됐습니다.

그런데 취업하고 나니 자연스럽게 업데이트 횟수가 줄어들기 시작했어요.

회사에 다녀오면 피곤하기도 했고, 무엇보다 제가 직접 사용하는 앱이 아니다 보니 점점 당당이 개발에 대한 흥미도 떨어졌습니다.

그러다 문득 이런 생각이 들었어요.

"내가 실제로 사용하는 앱을 만들면 좀 다르지 않을까?"

내가 필요해서 쓰고, 불편하면 직접 고치고, 계속 사용하면서 키워나가는 앱이라면 개발에도 더 진심이 될 수 있을 것 같았습니다.

그렇게 퇴근 후 조금씩 개발하기 시작한 앱이 바로 마이폿입니다.

그렇게 등장한 마이폿

마이폿은 My Pocket의 줄임말이에요.

말 그대로 나의 주머니라는 의미입니다.

가족이나 연인, 친구처럼 소중한 사람들끼리 하나의 주머니를 만들고 사진, 영상, 음성, 글 등을 남기면서 우리끼리의 추억을 쌓아가는 앱이에요.

누군가 이 글을 읽게 된다면 한번쯤 제 앱을 추천해드리고 싶어요..!

마이폿 - Google Play 앱

오늘을 담아두면, 언젠가 추억이 되는 우리만의 주머니

play.google.com

마이폿 앱 - App Store

App Store에서 INSEONG JUNG의 마이폿 앱을 다운로드하십시오. 스크린샷, 평가 및 리뷰, 사용자 팁 및 마이폿 앱과 비슷한 다른 앱을 볼 수 있습니다.

apps.apple.com

처음에는 정말 신났습니다.

퇴근하고 집에 와서 기능 하나 만들고,

다음 날 또 버그 하나 고치고,

주말에는 하루 종일 앱을 만들기도 했어요.

그러다 결국 iOS 출시까지 욕심이 생겨버렸습니다.

그래서...

맥북까지 샀습니다

정말 큰맘 먹고 구매했어요.

그리고 첫 사용자 30명

출시했다고 사용자가 저절로 생기지는 않더라고요.

주변 사람들에게 열심히 부탁했습니다.

누나 주변에는 아기를 키우는 분들이 많아서

"지금 사용하는 앱 말고 마이폿에 아기의 어린 시절을 기록해보면 어떻겠냐"

열심히 영업(?)도 했습니다 그렇게 한 명, 두 명 사용자가 늘기 시작했어요.

지금 글을 쓴 기준으로 출시한지 1주일 만에 31명이 가입해주셨어요 물론 이 중 2/3이 제 지인이겠지만요

그런데 제가 직접 만든 앱에 가입한 사람이 한 명씩 늘어나는 걸 보고 있으면 정말 기분이 좋더라고요.

0명에서 시작했으니까요.

10명.. 20명.. 그리고 드디어 30명.

"오... 진짜 사람들이 쓰기 시작하는 건가?" 싶었습니다.

그런데 기쁨은 딱 여기까지였습니다.

30명이 가입했는데, 아무도 쓰지 않았다

저는 마이폿 관리자 페이지에서 사용자의 활동을 볼 수 있어요.

그리고 데이터를 보고 조금 충격을 받았습니다.

대부분 정말 가입만 해준 사람들이었습니다.

가입하고, 주머니 하나 만들고, 그 이후로 아무것도 하지 않았습니다.

다시 로그인하지 않는 사람도 있었고, 기록이 0개인 주머니도 많았습니다.

결국 꾸준히 마이폿을 사용하는 사람은... 우리 가족 4명 정도였습니다.

30명이라는 숫자를 보면서 좋아했는데 사실 제가 보고 있던 건 사용자 수가 아니라 가입자 수 였던거죠

많이 우울했어요...

열심히 기능도 만들었고 디자인도 계속 수정했고 버그도 정말 많이 잡았고 비슷한 앱들의 평점 1점들을 보면서 많이 개선했고

30명의 사용자들이 준 피드백들도 다 반영했단 말이죠 ?!..

계속 생각했어요...

기능이 부족한가 ?

UI가 불편한가 ?

뭔가 더 재미있는 기능을 더 넣어야 하나?

이렇게 계속 생각하다 보니 근본적인 질문 하나가 생겼습니다.

그래서 마이폿을 왜 써야 하는데 ?

친구들에게 매일 써달라고 홍보하면서 이 질문에 대답이 막혔습니다.

그래서 마이폿을 왜 써야 하는데 ?

마이폿을 한 문장으로 소개하면 항상 이렇게 이야기했습니다.

"소중한 사람들과 추억을 기록하는 앱이에요."

그래서 추억을 기록하면 뭐가 좋은데 ?

대답을 못하겠더라구요..

저도 회사에서 하루 종일 일하고 퇴근하면 힘들어요..

씻고 침대에 누우면 유튜브나 보고 싶고 그냥 아무것도 하기 싫을 때도 많습니다.

그런 사람들한테 앱 하나 설치하라고 해놓고 오늘의 소중한 추억을 기록해보세요 라고 하면... 저라도 안 할 것 같아요.

사진은 이미 휴대폰 사진첩에 있고

가족과 나눈 대화는 카카오톡에 있고

친구들과 있었던 재미있는 일도 단톡방에 그대로 남아 있어요

그런데 굳이 마이폿을 켜고 사진을 선택하고 글을 적고 저장까지 해야 할 이유가 뭘까요 ?

이때 처음으로 추억이라는 단어를 너무 쉽게 사용하고 있었다는 생각이 들었어요

다시 생각해보자

30명의 사용자를 모으고 나서 이런 고민을 하게 될 줄은 몰랐어요.

처음에는 앱을 출시하는 게 목표였고 그 다음에는 사용자를 늘리는게 목표였어요.

저는 30명이 설치하는 앱보다 우리 가족 4명이 계속 사용하는 앱이 더 중요해요.

그리고 이제 제가 풀어야 할 문제도 명확해진 것 같습니다.

어떻게 하면 사람들이 기록하게 만들까? 가 아니라, 어떻게 하면 기록한다는 느낌조차 들지 않게 만들 수 있을까 ?

그리고

오늘의 별 것 아닌 순간을 어떻게 미래의 소중한 기억으로 돌려줄 수 있을까 ?

지금의 평범한 이 일상이 어느 순간엔 추억이 되는 것처럼 말이죠

아직 답은 잘 모르겠어요.. 지금의 마이폿이 정답이 아닐 수 있겠죠

그래도 직접 만든 앱에 실제 사용자들이 들어오기 시작하면서 이제야 단순히 앱을 개발하는 것과 사람들이 사용하는 서비스를 만드는 것은

완전히 다른 문제라는 걸 조금씩 배우고 있습니다.

그 답을 찾아가면서 마이폿도 조금씩 바꿔보려고 합니다.

그 순간에는 평범하게 지나갔던 하루도
시간이 흐른 뒤 다시 꺼내보면
무엇과도 바꿀 수 없는 소중한 기억이 되곤 하니깐요

마이폿은 그런 생각에서 시작됐어요.
소중한 순간들을 조금 더 오래 간직할 수 없을까 ?

가족과 함께한 평범한 하루가 될 수도 있고,하루하루 자라나는 아이의 어린 시절이 될 수도 있어요.
사랑하는 사람과 함께한 추억,친구들과 나눈 시시콜콜한 이야기,혹은 누구에게도 보여주지 않는 나만의 일기장이 될 수도 있고요.

지금 마이폿에 담아두는 것들은 시간이 지나 다시 꺼내봤을 때 분명 내 인생의 소중한 한 페이지가 되어 있을 테니까요

그리고 그 과정을 앞으로 하나씩 기록해보겠습니다

디스코드 웹훅으로 알림 받기

Inseong2 — Tue, 28 Jul 2026 12:21:00 +0900

안녕하세요. 스타트업에서 프론트엔드 개발을 하고 있는 inseong입니다.

서비스를 운영하다 보면 고객의 1:1 문의, 오류 제보, 결제 실패와 같은 이벤트를 최대한 빠르게 확인하는 것이 중요합니다.

이번글에서는 디스코드 웹훅으로 고객으로 부터 오는 1:1문의 알림을 받는 방법에 대해서 소개해 보겠습니다.

1:1 문의 알림 흐름도

1️⃣ 사용자가 앱에서 제목, 내용, 사진을 입력해 1:1 문의를 작성합니다.

2️⃣ 사용자가 문의하기 버튼을 누르면 문의 제출 함수가 실행됩니다.

3️⃣ 문의에 사진이 포함되어 있다면 사진을 먼저 S3에 업로드합니다. 사진이 없다면 업로드 과정 없이 다음 단계로 넘어갑니다

4️⃣ 사진 업로드가 완료되면 제목, 내용, 사진 정보 등을 Firestore에 저장합니다. Firestore에서는 이를 새로운 문의 문서를 생성한다고 표현합니다.

5️⃣ Firestore에 문의 문서가 생성되면 Firebase Functions의 함수가 해당 생성 이벤트를 감지해 자동으로 실행됩니다.

6️⃣ 실행된 Firebase 함수는 Secret Manager에 미리 저장해둔 Discord Webhook URL을 가져옵니다.

7️⃣ Firebase 함수는 가져온 Webhook URL로 “새 1:1 문의가 도착했습니다.”라는 메시지를 HTTP POST 방식으로 전송합니다.

8️⃣ Discord Webhook이 전달받은 메시지를 지정된 Discord 채널에 게시하고, Firebase Functions에는 전송 성공 또는 실패 로그가 기록됩니다.

1:1 문의 작성

▫️ 사용자가 앱에서 1:1 문의를 작성합니다.

문의 제출

▫️사용자가 문의 보내기 버튼을 누르면 문의를 제출하는 함수가 실행됩니다.

▫️ 이 함수는 중복 제출을 방지하고 제출 상태와 오류 메시지를 관리한 뒤, 실제 문의를 생성하는 submitSupportInquiry() 서비스를 호출합니다.

  const submit = useCallback(
    async (input: SubmitSupportInquiryInput) => {
      if (!uid || isSubmitting) {
        return false;
      }

      setSubmitErrorMessage(null);
      setIsSubmitting(true);

      try {
        await submitSupportInquiry(uid, input);
        return true;
      } catch (error) {
        setSubmitErrorMessage(getSupportInquiryErrorMessage(error, 'submit'));
        return false;
      } finally {
        setIsSubmitting(false);
      }
    },
    [isSubmitting, uid],
  );

사진 업로드 & 문의 저장

▫️문의에 첨부된 사진이 있다면 사진을 하나씩 S3에 업로드합니다.

▫️모든 사진 업로드가 완료되면 업로드된 사진 정보를 포함하여 문의를 Firestore에 저장합니다.

export async function submitSupportInquiry(
  uid: string,
  input: SubmitSupportInquiryInput,
) {
  if (input.photoAttachments.length > 3) {
    throw new Error('문의에는 사진을 최대 3장까지 첨부할 수 있습니다.');
  }

  const photos = [];
  for (const attachment of input.photoAttachments) {
    photos.push(await uploadSupportInquiryPhoto(attachment));
  }

  return createSupportInquiry(uid, {
    activePocketId: input.activePocketId,
    body: input.body,
    photos,
    title: input.title,
    userDisplayName: input.userDisplayName,
  });
}

FireStore 문서 생성 및 저장

▫️사진 업로드가 완료되면 제목, 내용, 사진 정보 등을 포함한 문의 데이터를 Firestore에 저장합니다.

▫️Firestore에서는 데이터를 저장하는 단위를 문서라고 하며, 문의가 저장되는 순간 새로운 문의 문서가 생성됩니다.

▫️ 문의 문서는 해당되는 경로에 생성되며, 이후 Firebase Functions가 이 문서 생성 이벤트를 감지하게 됩니다.

Firebase Functions 실행

▫️Firestore에 새로운 문의 문서가 생성되면 Firebase Functions가 해당 문서 생성 이벤트를 자동으로 감지합니다.

▫️onDocumentCreated() 이벤트를 사용하여 문의 문서가 생성되는 순간 서버 함수가 실행되도록 구성했습니다.

▫️앱이 직접 Discord 알림을 호출하는 것이 아니라, Firestore의 문서 생성 이벤트를 계기로 Firebase Functions가 자동으로 실행됩니다.

① 함수 등록 : onDocumentCreated()

② 문서 감지 : document

③ 최대 동시 실행 개수 : maxInstances

④ 리전 설정 : region

⑤ Secret 사용 : secrets

⑥ 이벤트 데이터 확인 : event.data

⑦ Secret 값 읽기 : DISCORD_SUPPORT_WEBHOOK_URL.value();

⑧ Discord에 HTTP 요청 : await fetch

⑨ 전송하는 데이터 : content

export const notifyDiscordOnSupportInquiryCreated = onDocumentCreated(
  {
    document: 'users/{uid}/supportInquiries/{inquiryId}',
    maxInstances: 10,
    region: FUNCTION_REGION,
    secrets: [DISCORD_SUPPORT_WEBHOOK_URL],
  },
  async (event) => {
    if (!event.data) {
      logger.warn('Support inquiry created event had no snapshot.', {
        eventId: event.id,
      });
      return;
    }

    const webhookUrl = DISCORD_SUPPORT_WEBHOOK_URL.value();
    const response = await fetch(webhookUrl, {
      body: JSON.stringify({
        allowed_mentions: { parse: [] },
        content: DISCORD_SUPPORT_MESSAGE,
      }),
      headers: { 'Content-Type': 'application/json; charset=UTF-8' },
      method: 'POST',
    });

    if (!response.ok) {
      const responseText = await response.text();
      logger.error('Discord support inquiry notification failed.', {
        eventId: event.id,
        inquiryId: event.params.inquiryId,
        responseText: responseText.slice(0, 300),
        status: response.status,
      });
      throw new Error(
        `Discord notification failed with HTTP ${response.status}`,
      );
    }

    logger.info('Discord support inquiry notification sent.', {
      eventId: event.id,
      inquiryId: event.params.inquiryId,
    });
  },
);

Discord Webhook URL 불러오기

▫️Discord에서 문의 알림을 받을 채널을 생성한 뒤, 채널 설정 → 연동 → 웹후크(Webhook) 메뉴로 이동합니다.

▫️새 웹후크 만들기를 선택한 후, 웹후크 이름과 알림을 받을 채널을 지정합니다.

▫️이름 : 원하는 웹후크 이름

▫️채널 : 문의 알림을 받을 Discord 채널

Discord Webhook으로 알림 전송

▫️발급받은 Webhook URL은 코드에 직접 작성하지 않고 Firebase Secret Manager에 환경변수로 저장합니다.

▫️Firebase Functions가 실행되면 Secret Manager에서 Webhook URL을 불러옵니다.

▫️불러온 Webhook URL로 HTTP POST 요청을 전송하여 Discord 채널에 "새 1:1 문의가 도착했습니다."라는 알림 메시지를 보냅니다.

터미널로 Firebase Secret 등록

▫️환경변수명 : Firebase Secret에 등록할 환경변수 이름 (ex. DISCORD_SUPPORT_WEBHOOK_URL)

▫️Firebase 프로젝트명 : Secret을 등록할 Firebase 프로젝트 이름

▫️등록이 완료되면 Firebase Functions는 실행 시 Secret Manager에서 해당 Webhook URL을 안전하게 불러와 사용할 수 있습니다.

npx.cmd --yes firebase-tools@15.23.0 functions:secrets:set "환경변수명" --project "Firebase 프로젝트명"

알림 전송 결과 기록

▫️Discord Webhook으로 알림 전송이 완료되면 Firebase Functions에 성공 로그를 기록합니다.

▫️알림 전송에 실패한 경우에는 HTTP 상태 코드와 응답 내용을 함께 기록하여 원인을 빠르게 확인할 수 있도록 구성했습니다.

▫️또한 응답 본문은 최대 300자까지만 저장하여 불필요하게 긴 로그가 쌓이지 않도록 했습니다.

① 앱안에서 고객센터 문의

② PC 또는 모바일 디스코드 앱에서의 알림

③ 관리자 페이지의 문의 확인

이렇게 디스코드 Webhook을 활용하면 고객의 1:1 문의를 실시간으로 받아 빠르게 대응할 수 있습니다.

구현 자체도 비교적 간단하면서 운영 효율을 크게 높여주는 방법이기 때문에
고객 문의뿐만 아니라 서버 오류, 결제 실패, 신규 회원 가입 등 다양한 운영 알림에도 충분히 활용할 수 있습니다.

이번 글이 디스코드 Webhook을 이용한 운영 자동화를 고민하고 계신 분들께 도움이 되었길 바랍니다. 감사합니다.

GitHub Actions 배포 자동화

Inseong2 — Fri, 24 Jul 2026 17:36:40 +0900

안녕하세요. 스타트업에서 프론트엔드 개발을 하고 있는 inseong입니다.

AWS의 S3와 CloudFront, Github OIDC를 활용해 React 프로젝트의 CI / CD 환경을 구성한 경험을 정리했습니다.

AWS에 GitHub OIDC 공급자 등록

▫️ GitHub Actions가 발급한 OIDC 토큰을 AWS에서 신뢰할 수 있도록 GitHub를 ID 제공업체로 등록합니다.

▫️ IAM → 액세스 관리 → ID 제공업체

▫️ 공급자 유형 : OpenID Connect

▫️ 공급자 URL : https://token.actions.githubusercontent.com

▫️ 대상 : sts.amazonaws.com

GitHub Actions용 IAM 역할 생성

▫️ GitHub Actions가 AWS 리소스에 접근할 때 사용할 IAM 역할을 생성합니다.

▫️ IAM → 액세스 관리 → 역할 → 역할 생성으로 이동합니다.

▫️ 신뢰할 수 있는 엔터티 유형에서 웹 자격 증명을 선택합니다.

▫️ ID 제공업체에서 token.actions.githubusercontent.com을 선택합니다. (1단계에서 생성 완료)

▫️ Github organization : 본인의 깃허브 아이디

▫️ Github Repository : 본인의 깃허브 프로젝트 저장소

▫️ Github branch : 본인의 깃허브 프로젝트 브랜치

✅ S3와 CloudFront 배포 권한 추가

▫️ 역할의 이름까지 작성하고 역할을 만들었다면 아래와 같이 설정을 합니다.

▫️ S3_BUCKET_NAME : AWS 콘솔 → S3 → 버킷

▫️ AWS_ACCOUNT_ID : AWS 콘솔 오른쪽 위의 계정 메뉴를 누르면 표시되는 12자리 계정 ID

▫️ CLOUDFRONT_DISTRIBUTION_ID : AWS 콘솔 → CloudFront → 배포 → ID

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>"
    },
    {
      "Sid": "ManageObjects",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>/*"
    },
    {
      "Sid": "InvalidateCloudFront",
      "Effect": "Allow",
      "Action": [
        "cloudfront:CreateInvalidation"
      ],
      "Resource": "arn:aws:cloudfront::<AWS_ACCOUNT_ID>:distribution/<CLOUDFRONT_DISTRIBUTION_ID>"
    }
  ]
}

역할의 신뢰 정책 확인

▫️ IAM → 역할 → 배포 역할 → 신뢰 관계에서 역할의 신뢰 정책을 확인합니다.
▫️ 신뢰 정책은 역할에 AWS 권한을 부여하는 정책이 아니라, 어떤 외부 주체가 이 역할을 인수할 수 있는지 정의하는 정책입니다.

▫️ AWS_ACCOUNT_ID : AWS 계정 ID
▫️ GITHUB_OWNER : GitHub 사용자 또는 조직
▫️ GITHUB_REPOSITORY : 저장소 이름
▫️ DEPLOY_BRANCH : 배포 브랜치

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:<GITHUB_OWNER>@*/<GITHUB_REPOSITORY>@*:ref:refs/heads/<DEPLOY_BRANCH>"
        }
      }
    }
  ]
}

역할 ARN 복사

▫️ GitHub Actions에서 생성한 IAM 역할을 사용하려면 역할의 ARN이 필요합니다.

▫️ IAM → 액세스 관리 → 역할로 이동

▫️ 생성한 GitHub Actions 배포 역할을 선택

▫️ 역할 상세 화면의 ARN 옆 복사 버튼을 선택

GitHub Secret 등록

▫️GitHub 프로젝트 저장소에서 다음 경로로 이동

▫️Settings → Secrets and variables → Actions → Repository secrets → New repository secret

▫️ Name : AWS_DEPLOY_ROLE_ARN 또는 원하는 ARN 닉네임
▫️ Secret : 앞에서 복사한 IAM 역할 ARN

워크플로 파일 생성

push.branches : 지정한 브랜치에 코드가 반영되면 자동 실행
workflow_dispatch : GitHub에서 수동 실행 허용
contents: read : 저장소 코드를 Checkout할 수 있는 권한
id-token: write : AWS 인증용 GitHub OIDC 토큰 발급 허용
npm ci: package-lock.json 기준으로 의존성 설치
npm run build : 운영용 정적 파일 생성
configure-aws-credentials : OIDC 토큰으로 IAM 역할을 인수하고 임시 AWS 자격 증명 발급
aws s3 sync : 빌드 결과물을 S3에 동기화
create-invalidation : 배포 후 CloudFront에 남아 있는 기존 캐시 제거
concurrency : 이전 배포가 실행 중일 때 새로운 배포가 시작되면 이전 작업 취소

name: Deploy Production

on:
  push:
    branches:
      - <DEPLOY_BRANCH> // ex. Production
  workflow_dispatch:

permissions:
  contents: read
  id-token: write

concurrency:
  group: production-deployment // 임의로 정해도 됌
  cancel-in-progress: true

jobs:
  deploy:
    name: Build and deploy
    runs-on: ubuntu-latest
    timeout-minutes: 15

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Build production
        run: npm run build
        env: // Github Action에서 참고해야할 환경 변수들 
          VITE_FIREBASE_API_KEY: ${{ secrets.VITE_FIREBASE_API_KEY }}
          VITE_FIREBASE_APP_ID: ${{ secrets.VITE_FIREBASE_APP_ID }}
          VITE_FIREBASE_AUTH_DOMAIN: ${{ secrets.VITE_FIREBASE_AUTH_DOMAIN }}
          VITE_FIREBASE_MEASUREMENT_ID: ${{ secrets.VITE_FIREBASE_MEASUREMENT_ID }}
          VITE_FIREBASE_MESSAGING_SENDER_ID: ${{ secrets.VITE_FIREBASE_MESSAGING_SENDER_ID }}
          VITE_FIREBASE_PROJECT_ID: ${{ secrets.VITE_FIREBASE_PROJECT_ID }}
          VITE_FIREBASE_STORAGE_BUCKET: ${{ secrets.VITE_FIREBASE_STORAGE_BUCKET }}

      - name: Verify build output
        run: | // 프로젝트의 빌드 파일 경로 (아래는 React & Vite)
          test -f dist/index.html
          test -d dist/assets

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE_ARN }}
          aws-region: ap-northeast-2

      - name: Deploy static assets
        run: | // S3 버킷명
          aws s3 sync dist/assets "s3://<S3_BUCKET_NAME>/assets" \
            --delete \
            --cache-control "public,max-age=31536000,immutable"

      - name: Deploy HTML and public files
        run: | // S3 버킷명
          aws s3 sync dist "s3://<S3_BUCKET_NAME>" \
            --delete \
            --exclude "assets/*" \
            --cache-control "no-cache,no-store,must-revalidate"

      - name: Invalidate CloudFront cache
        run: | // CloudFront의 아이디
          aws cloudfront create-invalidation \
            --distribution-id "<CLOUDFRONT_DISTRIBUTION_ID>" \
            --paths "/*"

      - name: Deployment summary
        run: |
          echo "## 운영 배포 완료  " >> "$GITHUB_STEP_SUMMARY"
          echo "- Branch: \`${GITHUB_REF_NAME}\`" >> "$GITHUB_STEP_SUMMARY"
          echo "- Commit: \`${GITHUB_SHA}\`" >> "$GITHUB_STEP_SUMMARY"

Github 배포 자동화 테스트

▫️ 설정한 브랜치에 푸쉬 이벤트를 발생시키고 정상적으로 배포가 됐는지 확인

AWS SAA-C03 합격 후기

Inseong2 — Sat, 13 Jun 2026 10:29:08 +0900

안녕하세요. 스타트업에서 프론트엔드 개발을 맡고 있는 Inseong입니다

이번 글에서는 두 번의 시험 끝에 합격하면서 느낀 점과 실제 공부 방법을 공유해보려고 합니다.

시험 결과

AWS 시험을 처음 보러 가면 바로 시험을 시작하는 건 아니에요.

시험장에 도착하면 사진 촬영 → 신분증 확인 → 응시자 이름과 동일한 카드 확인 등의 절차를 거쳐 본인 인증을 진행하게 됩니다.

저도 처음에는 절차가 많아서 시간이 꽤 걸리는 거 아닌가 싶었는데, 생각보다 금방 끝났어요.

시험 시작 20분 정도 전에 도착했는데도 충분히 여유롭게 확인을 마치고 시험을 볼 수 있었습니다.

그리고 결과는...

734점으로 합격했습니다.

SAA-C03의 합격 기준이 720점이기 때문에 진짜 말 그대로 턱걸이였습니다.

시험을 보는 동안에도 확실하게 정답이라고 생각되는 문제보다는

"이것도 맞는 것 같은데... 이것도 가능한 거 아닌가?" 싶은 문제들이 생각보다 많았습니다.

시험 시간은 170분입니다.

저는 전체 문제를 모두 풀고 다시 처음부터 2번 정도 검토했는데도 시간이 남았습니다.

그래서 문제를 빨리 풀어야 한다는 부담보다는 애매한 문제에 표시를 해두고 나중에 다시 천천히 확인하는 방법을 추천하고 싶어요.

시험 결과는 당일 저녁에 확인할 수 있었고, 저는 오후 8시 이후 시험을 예약했던 사이트에서 직접 결과를 확인했습니다.

공부 방법

1️⃣ AWS 핵심 서비스 개념 공부

제가 가장 먼저 했던 건 AWS의 핵심 서비스들을 정리하는 것이었습니다.

문제를 풀다 보면 계속 틀리는 서비스가 있고, 분명 전에 봤는데도

"이게 뭐였지...?" 싶은 서비스들이 계속 생기더라고요.

그래서 문제를 풀면서 자주 틀리거나 헷갈리는 내용들을 따로 정리했습니다.

그리고 단순하게 서비스 이름 → 서비스 설명

이렇게 외우기보다는 문제에서 특정 키워드가 등장했을 때 관련 서비스를 바로 떠올릴 수 있도록 연결해서 공부했어요.

예를 들어 문제에서 UDP라는 단어가 등장했다고 해볼게요.

UDP를 보는 순간 UDP → Network Load Balancer 가 먼저 떠오르게 만드는 겁니다.

그다음에는 머릿속에서 가지를 뻗어나가듯 생각했어요.

"UDP니까 NLB일 가능성이 높겠네."

"그렇다면 ALB는 아니겠구나."

"CloudFront를 묻는 문제도 아니겠네."

이런 식으로 정답을 바로 찾기보다 보기에서 틀린 답을 하나씩 제거하는 방식으로 문제를 풀었습니다.

자격 증명이나 Secret 관리가 나온다면 보기를 읽기도 전에 AWS Secrets Manager 가 떠오르게 만들었고요.

처음에는 서비스 이름도 많고 비슷한 기능도 많아서 진짜 헷갈립니다.

그런데 계속 문제를 풀다 보면 특정 키워드와 AWS 서비스가 조금씩 연결되기 시작해요.

저는 시험을 보기 전까지 제가 정리해둔 개념을 하루에 한 번씩 소리 내서 읽었습니다.

출퇴근하면서 보기도 하고, 자기 전에 한번 훑어보기도 했어요.

계속 반복하다 보니까 나중에는 문제에서 특정 단어만 봐도 관련 서비스들이 자연스럽게 떠오르기 시작했습니다.

2️⃣ ExamTopics 문제은행

개념을 어느 정도 공부했다면 그다음부터는 문제를 정말 많이 풀었습니다.

제가 반복해서 풀었던 문제는 총 400문제 정도였어요.

하루에 약 100문제씩 풀면서 틀린 문제는 그냥 정답만 확인하고 넘어가지 않았습니다.

"왜 이게 정답이지?" 를 계속 확인했어요.

이 과정에서 AI도 정말 많이 활용했습니다.

예를 들어 문제를 틀렸다면 "왜 이 서비스가 정답이야?" 에서 끝내는 게 아니라

"다른 보기는 왜 틀렸어?"

"이 조건이 없었다면 정답이 달라질 수 있어?"

"문제에서 어떤 키워드를 보고 이 서비스를 선택해야 해?" 이런 식으로 하나의 문제를 가지고 계속 질문했습니다.

이렇게 공부하다 보니 SAA 시험에서는 정답을 외우는 것보다 출제자가 문제에 숨겨놓은 조건을 찾는 게 훨씬 중요하다는 걸 느꼈습니다.

제가 특히 많이 걸렸던 함정이 읽기 성능 문제, VPC Peering, 저장 데이터 암호화와 전송 중 암호화의 차이, 고가용성 같은 부분들이었어요.

문제 앞부분에서는 이것저것 많은 상황을 설명하지만 결국 마지막 문장에서 비용을 최소화해야 하는지 운영 부담을 줄여야 하는지

고가용성이 가장 중요한지 성능을 높이는 것이 중요한지 를 요구하는 경우가 많았습니다.

그래서 나중에는 문제를 읽을 때 "그래서 출제자가 결국 원하는 게 뭔데?" 를 먼저 찾으려고 했습니다.

시험 후기

이렇게 보니 진짜 많이 풀었네 나...

첫 번째 시험에서는 709점을 받았습니다. 합격 점수가 720점이니까 고작 11점 차이로 불합격한 거죠.

그리고 두 번째 시험에서 734점으로 합격했습니다. 이번에도 여유롭게 합격한 점수는 아니라서 어느 정도 운도 따라줬다고 생각해요.

프론트엔드 개발자가 AWS 자격증을 공부한다고 하면 "프론트엔드랑 AWS가 그렇게 관련 있나?" 라고 생각하실 수도 있습니다.

저도 AWS 자격증이 당장 프론트엔드 개발 실력을 올려준다고 생각하지는 않아요.

하지만 저는 언젠가 제가 직접 만든 서비스를 운영해보고 싶다는 목표가 있습니다.

단순하게 화면만 만드는 것이 아니라,

내가 만든 서비스를 직접 배포하고 서버가 어떤 구조로 동작하는지 이해하고, 트래픽이 늘어났을 때 어떤 구조가 필요한지까지 알고 싶었어요.

그래서 AWS를 공부하기 시작했습니다. 물론 그런 멋있는 이유만 있었던 건 아닙니다.

첫 번째 시험에서 떨어졌을 때는 정말 좌절했어요.

한 달 동안 일을 마치고 집에 돌아와서 매일 저녁 방 안에서 개념을 외우고 문제를 풀었습니다.

주말에도 공부했고요.

그런데 결과 화면에 불합격이라는 결과가 나오니까 그동안 공부했던 시간이 전부 헛수고가 된 것 같은 기분이 들었습니다.

그래도 다시 시험을 신청했습니다.

그리고 두 번째 시험에서 합격이라는 결과를 확인했을 때는 첫 번째 시험에서 떨어졌을 때와 완전히 다른 감정이 들었습니다.

이번 시험을 준비하면서 하나 배운 게 있어요.

며칠이 걸리든, 몇 번 실패하든 결국 해내면 된다는 것.

첫 번째 시험에서 떨어졌던 순간에는 실패라고 생각했지만, 지금 돌이켜보면 그때 틀렸던 문제들과 다시 공부했던 시간들이 있었기 때문에 두 번째 시험에서 합격할 수 있었던 것 같습니다.

성공했을 때 느끼는 감정을 직접 경험하고 나니까 실패했던 과정까지도 결과를 만들기 위한 하나의 과정이었다는 생각이 들더라고요.

그래서 이번 AWS 시험은 단순히 자격증 하나를 취득했다는 것보다 저에게 조금 더 의미 있는 경험으로 오래 기억에 남을 것 같습니다.

지금 SAA-C03을 공부하고 계신 분들도 문제를 풀다 보면 "이걸 어떻게 다 외워..." 싶은 순간이 분명 올 거예요.

저도 그랬습니다.

그래도 하나씩 반복하다 보면 어느 순간 문제에서 키워드가 보이기 시작하고 AWS 서비스들이 조금씩 연결되기 시작합니다.

한 번 떨어졌다고 해도 괜찮습니다.

결국 합격하면 되더라구요.. (응시료가 비싸서 눈물은 조금 날꺼에요..)

지금 준비하고 계신 분들도 끝까지 포기하지 않고 도전해서 좋은 결과 얻으셨으면 좋겠습니다.

Cloudflare & Nginx 배포 정리

Inseong2 — Thu, 11 Jun 2026 11:37:05 +0900

안녕하세요. 스타트업에서 프론트엔드 개발을 맡고 있는 inseong입니다

이번 글에서는 React 프로젝트, React Native 프로젝트들을 Cloudflare와 Nginx를 이용해서 배포하는 방법에 대해 정리해볼려고 합니다.

배포 환경 및 순서

현재 서비스는 NHN Cloud 인스턴스에서 운영되고 있으며, Cloudflare를 통해 DNS 및 HTTPS(SSL) 구성을 관리하고 있습니다.

순서 크게 7단계로 진행이 됩니다.

① NHN Cloud 인스턴스 접속

② 프로젝트 Clone

③ Cloudflare DNS 레코드 생성

④ Nginx 설정 파일 생성 및 수정

⑤ Node.js 버전 확인 및 설치 빌드

⑥ Ngnix 설정 반영

⑦ 도메인 접속 및 서비스 확인

NHN Cloud 인스턴스 접속

▫️ 배포할 서버의 인스턴스를 선택한 후, 해당 인스턴스에 연결된 Key Pair를 이용하여 접속합니다.

▫️ 접속은 CMD 또는 Git Bash를 사용하며, Key Pair 파일이 위치한 경로에서 명령어를 실행합니다.

프로젝트 Clone & Pull

▫️ 프로젝트를 최초 배포하는 경우, 프로젝트를 관리하는 디렉터리에서 Git Clone을 진행합니다.

▫️ 이미 배포된 프로젝트를 재배포하는 경우, 배포 대상 브랜치를 확인한 후 Git Pull을 진행하여 최신 소스 코드를 반영합니다.

Cloudflare DNS 레코드 생성

▫️ Cloudflare DNS 설정을 위해 DNS → Records 메뉴로 이동합니다.
▫️ A 레코드를 생성한 후, Name에는 연결할 서브도메인을 입력하고 IPv4 Address에는 NHN Cloud 인스턴스의 Public IP를 입력합니다.
▫️ 설정 저장 후 DNS 전파가 완료되면 해당 도메인이 지정한 서버를 가리키게 됩니다.

Nginx 설정 파일 생성 및 수정

▫️ /etc/nginx/sites-enabled 경로에 Nginx 설정 파일을 생성합니다.
▫️ 기존에 운영 중인 서비스의 설정 파일이 있다면 cp 명령어를 이용해 복사한 후 필요한 부분만 수정하여 사용할 수 있습니다.
▫️ server_name에는 Cloudflare에서 생성한 서브도메인 주소를 입력합니다.

▫️ root에는 프로젝트의 빌드 결과물이 위치한 경로를 입력합니다.
▫️ Nginx가 해당 설정 파일을 읽을 수 있도록 include 설정이 필요하며, 해당 경로는 /etc/nginx/nginx.conf 파일에서 확인할 수 있습니다.

server {

    client_max_body_size 10M;
    listen 80;
    listen 443 ssl http2;
    server_name Cloudflare에서 만든 서브 도메인 주소;

    ssl_certificate     /etc/ssl/beauty/origin.crt;
    ssl_certificate_key /etc/ssl/beauty/origin.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    index index.html;

    access_log /var/log/nginx/hama/beauty/access.log main;
    error_log /var/log/nginx/hama/beauty/error.log error;

    location / {
        root /home/rocky/beautyhama.pc/dist;
        try_files $uri $uri/ /index.html;
    }
}

Node.js 버전 확인 및 설치 빌드

▫️프로젝트마다 사용하는 Node.js 버전이 다를 수 있으므로 현재 버전을 확인합니다.
▫️서버의 Node.js 버전과 프로젝트에서 요구하는 버전이 다를 경우 nvm을 설치한 후 필요한 버전의 Node.js를 설치합니다.
▫️Node.js 버전 변경 후 의존성을 설치하고 프로젝트를 빌드합니다.

▫️이번 프로젝트는 Vite 기반 프로젝트로 Node.js 20 이상이 필요했지만,서버 환경은 Node.js 18이 사용되고 있어 빌드 과정에서 오류가 발생했습니다.

// 1. nvm 설치
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash

// 2. 파일에 추가된 설정을 현재 터미널에 즉시 반영
source ~/.bashrc

// 3. nvm 24버전 node 설치
nvm install 24

// 4. nvm 24버전 node 사용
nvm use 24

// 5. 터미널 접속 시 기본 Node 버전을 24로 설정 (선택)
nvm alias default 24

// 6. 설치 및 빌드
npm install
npm run build

Ngnix 설정 반영

▫️ Nginx 설정 파일 수정이 완료되면 nginx -t 명령어를 실행하여 설정 파일에 문제가 없는지 확인합니다.

▫️ syntax is ok, test is successful 메시지가 출력되면 정상적으로 적용 가능한 상태입니다.
▫️ 설정에 문제가 없다면 systemctl reload nginx 명령어를 실행하여 변경된 설정을 반영합니다.

sudo nginx -t
sudo systemctl reload nginx

도메인 접속 및 서비스 확인

▫️ 설정이 정상적으로 적용되었다면 등록한 도메인으로 서비스에 접속할 수 있습니다.

KCP 본인인증 V2 가이드

Inseong2 — Wed, 20 May 2026 15:32:05 +0900

안녕하세요. 스타트업에서 프론트엔드 개발을 맡고 있는 inseong입니다

이번 글에서는 NHN KCP 본인인증 버전 업그레이드를 프론트 시점에서 업데이트 하는 법과 막혔던 부분에 대해서 정리해볼려고 합니다.

V1에서 V2로 바꾼 이유

NHN KCP 본인확인 V2 서비스는 브라우저에 직접 전달되는 V1 방식과는 달리 인증이 완료되면 KCP가 인증결과를 암호화해서

서버로 직접 전달되며, 그 결과를 서버가 복호화해서 확인한 뒤 서버가 앱에 결과 전달하는 구조입니다.

✅ 기존 연동 방식(V1) : 인증 성공 시, 인증결과를 브라우저로 전달
✅ 기존 연동 방식(V2) : 암호화된 인증 결과를 Server-to-Server 방식으로 요청 및 전달

본인확인 버전별 인증 흐름도

본인확인 V2 업데이트 전 유의사항

⛔ 이 내용들은 필수 조건이며 무시할 경우 삽질의 늪으로 빠질 수 있습니다 ^^;

① 본인확인 테스트 서버에서 실제 PASS 앱 인증이나 인증번호 문자가 수신되지 않습니다.

② PASS로 진행하는 경우 실제 앱을 통한 인증은 생략 후 인증완료 버튼만 누르면 정상 진행 가능하며 인증번호는 "123456" 입력하여 진행이 가능합니다.

③ 백엔드에서 설정한 ret_URL가 KCP 상점페이지 로그인 → 부가서비스 → 휴대폰본인확인 → 인증결과URL 설정을 일치하도록 세팅해야 합니다.

본인확인 V2 서비스 흐름도

1️⃣ 본인인증 시작 API 호출

웹뷰를 통해서 KCP 본인인증 페이지를 열게 됩니다.

첫 진입 시 본인인증 시작 API를 호출하여 서버에게 본인인증 페이지 로드에 필요한 데이터를 받아오게 됩니다.

API 요청

const result = await certApi.register({ purpose });

응답 값 확인

1️⃣ callUrl
KCP 인증 화면 URL입니다.
기존 V1에서는 고정 URL로 본인인증 창을 열었지만,
V2에서는 서버에서 전달받은 callUrl 값으로 인증창을 열게 됩니다.

2️⃣ ordrIdxx
KCP 거래(주문) 번호입니다.
본인인증 요청 건을 식별하기 위한 고유 번호로 사용됩니다.

3️⃣ regCertKey
인증 요청 키입니다.
거래등록 완료 후 발급되며, KCP 인증창 호출 시 함께 전달되는 값입니다.

{
    "callUrl": "https://cert.kcp.co.kr/xxx",
    "ordrIdxx": "17xxxxxxxxxxxxx",
    "regCertKey": "20xxxxxxxxxxx"
}

2️⃣ 웹뷰와 CallUrl 연동 하기

응답 받은 값중에서 callUrl와 regCertKey을 이용하여 웹뷰와 연동시켜줍니다.

이때 연동은 일반 URL 이동 방식(GET)이 아닌 KCP에서 제공하는 Form Submit 방식으로 진행해야 합니다.

본인확인창 Form 방식 웹뷰 코드

아래 코드는 Form Submit 방식으로 WebView와 KCP 인증창을 연동하는 예시입니다.

실제 서비스에 적용할 때는 인증 완료 후 WebView 종료 시점 감지(onNavigationStateChange),
외부 앱 실행 실패, 인증 실패, 사용자 취소 등의 예외 처리를 반드시 함께 구현해야 합니다.

<WebView
  source={{
    html: `
      <html>
        <head>
          <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        </head>

        <body onload="document.forms[0].submit()">
          <form method="post" action="${callUrl}">
            <input type="hidden" name="reg_cert_key" value="${regCertKey}" />
            <input type="hidden" name="kcp_page_submit_yn" value="Y" />
          </form>
        </body>
      </html>
    `,
  }}
/>

본인확인창 호출 파라미터

1️⃣ reg_cert_key

거래등록 후 응답 받은 키

2️⃣ kcp_page_submit_yn

본인확인 인증 창 호출 방식

Y : 페이지전환 방식 호출

N : 팝업 방식 호출

3️⃣ 웹뷰에서 사용자 본인인증 완료 감지 하기

본인인증 완료 후에는 프론트가 결과값을 직접 받지 않고, 서버에 결과 조회 API를 polling 방식으로 호출합니다.

웹뷰의 옵션인 onNavigationStateChange를 이용해서 해당 URL 이동을 감지하고, 인증이 완료되었다고 판단합니다.

이후 ordrIdxx 값을 기준으로 백엔드 결과 조회 API를 반복 호출하여 최종 인증 결과를 확인합니다.

onNavigationStateChange로 종료 시점 감지

인증결과 return URL API : KCP 상점페이지에 등록되어 있어야 하며, 백엔드에서 지정한 ret_url

onNavigationStateChange={event => {
  if (event.url.includes('인증결과 return URL API') && !event.loading) {
    handleCertCompleted();
  }
}}

결과 조회 API 반복 호출

1️⃣ COMPLETED
인증이 완료된 상태입니다.
폴링을 중단하고 결과 값을 최종적으로 세팅한 뒤 성공 처리를 진행합니다.

2️⃣ FAILED / EXPIRED
인증이 실패했거나 만료된 상태입니다.
폴링을 중단하고 실패 처리를 진행합니다.

3️⃣ 그 외 상태 (Pending)
아직 인증이 완료되지 않은 상태입니다.
1초 간격으로 계속 결과 조회 API를 호출하며, 최대 폴링 횟수는 60회 ~ 90회(1분에서 1분30초)로 제한합니다.

프론트에서는 결과 조회를 하는 폴링 함수 구현이 제일 난이도가 있으며 V1에서는 주로 프론트 방식이였지만,
V2에서는 백엔드 방식으로 변경됨에 따라 받아오는 응답 값을 통해 화면을 열어주고 에러 / 성공 처리를 잘 해주면 정상적으로 구현이 가능합니다.

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

AWS 핵심 서비스 개념

Inseong2 — Wed, 20 May 2026 10:20:26 +0900

AWS SAA 시험에서 자주 등장하는 핵심 서비스를 정리했습니다.

데이터 분석 및 빅데이터

문제 1번

Kinesis Data Firehose ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

들어오는 데이터 양에 따라 자동 확장
여러 AZ에 분산 → 고가용성
완전 관리형 서비스 → 운영 오버헤드 ↓
실시간 데이터 스트리밍 수집에 최적
중앙 위치 S3 저장
Parquet 변환 가능

실시간 데이터 적재

문제 2번

Lake Formation ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

S3 기반 데이터 레이크 구축/관리 서비스
데이터 레이크 설정, 보안, 관리 자동화
AWS Glue와 연동 → 데이터 카탈로그화
중앙 집중식 권한 관리 (테이블/열/행 수준)
데이터 접근 감사 및 보안 관리 가능
모든 데이터를 한 곳으로 → 데이터 레이크 키워드

데이터 레이크

문제 3번

AWS Glue ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

서버리스 ETL 서비스 (Extract / Transform / Load)
다양한 데이터 소스(S3, RDS 등) → 데이터 변환 및 적재
데이터 파이프라인 구축
Firehose/Kinesis 이후 후처리 배치 작업에 사용

서버리스 ETL

문제 4번

Amazon Redshift ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

페타바이트 규모 데이터 분석
완전 관리형 데이터 웨어하우스
S3 데이터 분석 가능
대규모 BI/분석 워크로드

대규모 데이터 분석

문제 5번

Amazon Athena ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

S3 데이터 대상으로 SQL 쿼리 실행
서버리스 → 인프라 관리 필요 없음
일회성 / 임시 쿼리에 최적
Parquet 형식과 궁합 좋음

S3 SQL 조회

문제 6번

Apache Parquet ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

컬럼 기반(Columnar) 저장 포맷
대규모 데이터 분석 최적화
필요한 컬럼만 읽어서 성능 ↑
데이터 레이크 표준 포맷

컬럼 기반 저장

문제 7번

Amazon QuickSight ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

BI(비즈니스 인텔리전스) 서비스
Athena / S3 / Redshift 데이터 시각화
KPI 대시보드 생성

데이터 시각화

문제 8번

Amazon EMR ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

대규모 데이터 분석
Hadoop 기반 빅데이터 처리
로그 분석 → 클릭 스트림 데이터
S3 데이터 배치 처리
배치 분석에 최적

Hadoop 빅데이터 처리

문제 9번

Amazon Kinesis Data Streams ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

실시간 데이터 스트리밍 수집 서비스
대량의 스트리밍 데이터를 실시간으로 처리 가능
Shard 기반으로 확장
Producer가 데이터를 넣고 Consumer가 데이터를 읽는 구조
로그, 클릭 스트림, IoT, 실시간 분석에 자주 사용
데이터를 일정 기간 보관 가능 (기본 24시간 ~ 최대 365일)

자주 같이 나오는 서비스

Kinesis Data Firehose → 데이터를 S3, Redshift 등에 자동 적재
Kinesis Data Analytics → 스트림 데이터를 SQL로 실시간 분석
Lambda → 스트림 이벤트 실시간 처리

실시간 데이터 스트리밍, 실시간 처리

데이터베이스

문제 1번

DynamoDB ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

키-밸류 데이터베이스
높은 성능, 확장성, 가용성 (모바일, 게임, 쇼핑몰 등)
대용량 파일 저장 ❌ → 메타데이터 저장
DynamoDB PITR은 최대 35일 복구 지점을 제공하고, 현재 시점의 5분 전부터 설정된 복구 기간 내 특정 시점으로 복원할 수 있다.
DynamoDB Streams는 테이블에 새 항목이 추가/수정/삭제될 때 변경 이벤트를 따로 흘려보낸다.
Streams → 데이터 변경 실시간 감지 → Lambda 트리거
GSI → 기본 키 외 다른 속성으로 조회 가능
DAX → 읽기 성능 캐시 (마이크로초 단위)
DynamoDB TTL : 특정 시간이 지나면 DynamoDB가 항목을 자동 삭제하는 기능

초고속 NoSQL

문제 2번

Amazon RDS ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

관계형 데이터베이스, 완전 관리형 서비스 (서버리스 X)
최대 7일까지만 중지 가능
EC2 Auto Scaling Group처럼 컴퓨트 인스턴스 수를 자동 증감하는 구조는 아님. 하지만 RDS Storage Auto Scaling은 있음
사용하지 않아도 인스턴스가 켜져 있으면 비용이 발생
RDS Multi-AZ의 Standby는 장애 조치용이며 평소에는 직접 읽거나 개발/스테이징 DB로 사용할 수 없음
기존 DB 암호화 직접 변경 ❌ → 스냅샷 복사 후 복원 필요
같은 VPC인데 통신이 안된다면 RDS 보안그룹을 열어야 한다.
RDS 인스턴스는 암호화되지 않기 때문에 실행 중인 RDS에 암호화를 직접 켤 수 없다.
- 암호화된 스냅샷을 만든 뒤 복원해야 함

관리형 관계형 DB

문제 3번

RDS Proxy ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

서버리스 환경에서 DB 연결 폭주 해결
연결 풀링 제공
Lambda, ECS, EKS 환경에서 사용
고가용성 + 장애 조치 시간 단축
추가 비용 발생

DB 연결 풀링

문제 4번

Amazon Aurora ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

MySQL/PostgreSQL 호환 고성능 DB
클라우드 네이티브
DR 재해 복구, 다른 리전에 복제, 장애 시 승격, 빠른 복구를 의미한다.
MySQL 대비 최대 5배 / PostgreSQL 대비 최대 3배 성능
Aurora Clone : 원본 스토리지 참조, 필요할 때만 변경분 복사
Aurora Auto Scaling : 읽기만 자동 확장하며 쓰기 트래픽은 커버하지 못한다.
Amazon Aurora Serverless
- 특정 인스턴스 유형을 선택하지 않아도 된다.
- 드물게 액세스하는 패턴 (항상 사용되지 않고 사용량 변동이 큼)
- 자동 확장, 사용량 따라 자동 증감
Aurora Global Database
- 일반 RDS 읽기 복사본과 다르게 스토리지 레벨 복제를 사용한다.
- Secondary Region에 최소 1개 DB 인스턴스 필요
Aurora MySQL에는 DB클러스터 복제 / 클론 기능을 사용할 수 있음

고성능 클라우드 DB

문제 5번

RDS Custom for Oracle ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

기본 운영 체제(OS) 접근 가능
패키지 설치 및 OS 레벨 커스터마이징 가능
Oracle, SQL Server의 특수 설정 유지 가능
관리형 서비스의 장점과 OS 제어 권한을 함께 제공

기본 운영 체제에 대한 액세스 유지, OS 커스터마이징 필요

문제 6번

ElastiCache ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

자주 사용하는 데이터를 메모리에 저장 (캐싱)
응답 속도 향상
실시간 데이터 변화 많으면 부적합
비용은 구성에 따라 달라짐

인메모리 캐싱

문제 7번

Redis ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

다양한 자료구조 지원 (String, List, Hash 등)
Master-Replica → 고가용성
세션 저장, 랭킹, Pub/Sub

고급 캐시/세션

문제 8번

Memcached ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

단순 캐시
String만 지원
멀티스레드 → 성능 좋음
데이터 손실 가능 (휘발성)

단순 고속 캐시

문제 9번

ElastiCache (Session Store) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

중앙 집중식 세션 관리
Redis / Memcached 기반
인메모리 저장소 활용

중앙 세션 저장소

네트워킹 및 콘텐츠 전송

문제 1번

Application Load Balancer (ALB) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

HTTP/HTTPS (L7) 기반 라우팅
경로, 쿼리, 헤더 기반 라우팅 가능
HTTP 요청이 들어오면 ALB Listener Rule에서 HTTPS 리다이렉트 가능
SSL 때문에 EC2 CPU 사용률이 높아진다면 ALB에서 SSL Termination를 수행하고 ACM 인증서를 연결한다.

HTTP/HTTPS 라우팅

문제 2번

Network Load Balancer (NLB) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

TCP/UDP (L4) 처리
초고속 처리 / 낮은 지연 시간
고정 IP 지원

TCP/UDP 초고속, UDP를 지원하는 서비스

문제 3번

Gateway Load Balancer (GLB) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

방화벽, IDS/IPS 같은 네트워크 가상 어플라이언스를 투명하게 배포/확장하는 데 사용하는 로드 밸런서

방화벽 로드밸런싱

문제 4번

CloudFront ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

CDN 서비스
사용자와 가까운 위치에서 캐싱 → 지연 최소화
정적 콘텐츠 캐싱, 동적 요청 최적화
HTTPS (ACM) 지원
Cloudfront → Public ALB → Private EC2가 권장 아키텍처

CDN 캐싱

문제 5번

Origin Access Identity (OAI) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

CloudFront → S3 접근 제어
S3 직접 접근 차단
CloudFront만 접근 가능
CloudFront로 S3 직접 접근 차단: OAI(구방식), OAC(최신 권장)
S3 Origin 보호는 OAC 우선, OAI는 legacy

S3 직접 접근 차단

문제 6번

CloudFront Signed URL ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

특정 콘텐츠 접근 자체를 제한
일정 시간 동안만 접근 가능

기간 제한 접근

문제 7번

CloudFront Field-Level Encryption ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

민감 데이터 필드 암호화
엣지에서 암호화 → 오리진에서만 복호화 가능

민감 필드 암호화

문제 8번

Global Accelerator ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

글로벌 네트워크로 트래픽 최적화
TCP/UDP 지원
정적 IP 제공
자동 장애 조치

글로벌 네트워크 최적화

문제 9번

Internet Gateway (IGW) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

VPC ↔ 인터넷 연결
양방향 통신 가능

인터넷 연결

문제 10번

Site-to-Site VPN ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

온프레미스 ↔ AWS 연결
IPsec 기반 VPN
인터넷 통해 암호화 통신

온프레미스 VPN

문제 11번

VPC Peering ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

서로 다른 VPC 간 연결
사설 통신 가능
피어링 연결에는 보안 그룹이 없음, 그러므로 피어링 연결의 보안 그룹에 인바운드 규칙이 구성할 수 없음
전송 VPC : 여러 VPC를 중앙 허브처럼 연결할 때 쓰는 구조

VPC 간 사설 연결

문제 12번

PrivateLink ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

Interface Endpoint 기반이라고 구분
프라이빗하게 서비스 연결하는 기술
API Gateway는 Interface Endpoint만 지원한다.
SNS, SQS, KMS도 Interface Endpoint만 지원

사설 서비스 연결

문제 13번

Route53 Failover Routing 장애 조치 라우팅 ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

DNS 기반 장애 조치
Primary 장애 시 Secondary로 자동 전환

DNS 장애 조치

문제 14번

Route53 Multivalue Routing 다중 값 응답 라우팅 ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

여러 IP를 동시에 준다.
건강한 IP 여러개를 반환하고 클라이언트가 선택하게 된다.
Health Check가 가능

DNS 분산

문제 15번

VPC EndPoint ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

Gateway Endpoint와 Interface Endpoint가 있음
S3/DynamoDB에 인터넷 게이트웨이나 NAT 없이 접근하게 해줌
Gateway Endpoint는 보안 그룹이 없다.

NAT 없이 AWS 접근

문제 16번

NAT Gateway ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

프라이빗 서브넷의 인스턴스가 인터넷으로 나갈 수 있게 해주는 서비스
외부 인터넷 → 프라이빗 서브넷 직접 접근은 불가능
반드시 퍼블릭 서브넷에 생성해야 함
Internet Gateway와 함께 사용
프라이빗 라우팅 테이블에서 0.0.0.0/0 → NAT Gateway로 연결
고가용성을 위해 보통 AZ별 NAT Gateway 구성
완전 관리형 서비스 → NAT Instance보다 운영 부담 적음

자주 헷갈리는 포인트

NAT Gateway → IPv4 인터넷 outbound
Egress-Only Internet Gateway → IPv6 전용 outbound
Internet Gateway → 퍼블릭 서브넷 인터넷 연결
VPC Endpoint → NAT 없이 AWS 서비스(S3/DynamoDB) 접근

프라이빗 서브넷 인터넷 outbound

문제 17번

지연 시간 라우팅 Latency Routing ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

어디가 가장 빠른지
Route 53이 AWS 글로벌 네트워크 데이터를 이용해서 사용자와 AWS 리전 간 지연시간을 측정하고
가장 응답이 빠른 리전으로 보냄
AWS가 자동 판단하며, 사용자 위치보다 실제 네트워크 속도가 중요

가장 가까운 위치

문제 18번

지리적 위치 라우팅 ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

어디 사는 사람인지 사용자의 국가 또는 대륙 정보를 기준으로 직접 라우팅 규칙을 설정
직접 규칙을 작성하며 네트워크 속도를 고려하지 않고 국가별 서비스 분리

어디에 사는 사람인지

문제 19번

가중치 라우팅 ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

몇 %씩 보낼까 트래픽 비율을 직접 설정한다.
예를 들어 도쿄 서버에 80%를 보내고 싱가포르 서버에 20%를 보내는 방식이다.
카나리 배포, 블루/그린 배포, 신규 버전 테스트

가장 가까운 위치

보안 및 자격 증명 관리

문제 1번

Bastion Host ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

방어 목적으로 설계된 네트워크 내부의 특별한 서버
퍼블릭 서브넷에 위치
엄격한 인바운드 보안 그룹 설정

보안 SSH 진입점

문제 2번

KMS (Key Management Service) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

암호화 키를 생성하고 관리하는 서비스
키를 사용하거나 관리할 수 있는 IAM 권한 정책을 세밀하게 설정 가능
S3, RDS, EBS 볼륨 등 다양한 AWS 서비스의 데이터를 암호화하는 데 사용
KMS 고객 관리형 키로 암호화된 스냅샷은 KMS Key Policy에 대상 계정을 추가하고 공유를 해야한다.
고객 관리형 다중 리전 KMS KEY
- 여러 리전에 복제되지만 논리적으로 같은 키처럼 사용할 수 있다.
- 리전 A와 리전 B에도 키가 존재하며 같은 키 ID이고 각 리전에서 로컬 KMS로 암·복호화 가능
SSE-S3 (서버측 암호화)
- 가장 간단하며, 기본 암호화 용도, AWS가 키를 관리
- 별도 키 관리가 필요 없으며 검사 및 키 사용 추적 불가
SSE-KMS
- 누가, 언제, 어떤 키를 사용했는지 기록되며, 키 회전 지원
- 규정 준수 문제에서 자주 정답, IAM 기반 세밀한 권한 제어 가능
- Multi-Region KMS Key를 사용하면 여러 리전에서 동일한 논리적 키 사용 가능
SSE-C
- 고객이 키를 생성하며 AWS는 키를 저장하지 않습니다. (운영 오버헤드 ↑)
- 키 분실 시 복호화 불가

암호화 키 관리

문제 3번

Secrets Manager ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

자격 증명 관리 서비스
비밀번호를 자동으로 생성, 교체, 저장 가능
다중 리전 비밀 복제 지원
여러 리전에 걸쳐 자격 증명을 안전하게 동기화 가능
자동 비밀번호 회전(Automatic Rotation) 기능이 있습니다.

비밀번호 자동 교체, 데이터베이스 자격 증명 관리

문제 4번

AWS Inspector ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

인스턴스, 컨테이너 이미지, Lambda 함수 같은 워크로드의 취약점과 보안 위반 여부를 자동 검사
서버/코드의 취약점 점검에 사용
EC2 취약점을 스캔하고, CVE 탐지, 패치 누락 탐지 (정기적인 보안 스캔)

취약점 검사

문제 5번

AWS Macie ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

특히 S3에 저장된 데이터 중 민감 정보를 자동으로 검색, 분류, 보호
데이터(S3)의 민감 정보 검사에 사용

S3 민감정보 탐지

문제 6번

AWS Shield Advanced ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

대규모 DDoS 공격으로부터 보호하는 유료 서비스
Shield Standard보다 훨씬 강력
공격 대상이 큰 대규모 서비스에서 가용성 보장이 우선일 때 적합

(정교한) DDoS 방어

문제 7번

GuardDuty ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

잠재적인 위협 행위를 지속적으로 모니터링하고 탐지하는 서비스
비정상적이거나 악의적인 활동을 지속적으로 감시
완전 관리형이며 사용량에 따라 비용 부과

위협 탐지

문제 8번

AWS IAM Identity Center (구 AWS SSO) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

AWS Organizations 내 여러 계정 및 애플리케이션에 대한 단일 로그인(SSO) 액세스를 중앙에서 관리하는 서비스
여러 AWS 계정과 애플리케이션 접근을 통합 관리 가능

AWS SSO

문제 9번

AWS Network Firewall ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

VPC 경계에서 실제로 트래픽을 검사하고 필터링하는 방화벽 엔진
패킷 내용이나 도메인 이름(FQDN)을 분석해 트래픽을 차단하거나 허용
실제 보안 규칙을 적용하는 역할

VPC 방화벽

문제 10번

AWS Firewall manager ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

Network Firewall을 포함한 다양한 AWS 보안 서비스의 정책을 중앙에서 관리하는 도구
AWS Organizations와 통합되어 여러 계정과 리전에 걸쳐 보안 정책을 한 번에 설정 및 자동 배포
보안 일관성 유지와 운영 오버헤드 최소화에 사용

보안 정책 중앙관리

문제 11번

Active Directory ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

Microsoft가 개발한 디렉터리 서비스
Windows 기반 환경에서 사용자, 컴퓨터, 그룹 및 기타 네트워크 리소스 정보를 중앙 집중식으로 저장하고 관리
SSO, 중앙 권한 관리, 그룹 정책 등에 사용

Windows 중앙 인증

문제 12번

Task Role ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

컨테이너에 직접 권한을 부여하는 IAM 역할
IAM 역할을 생성한 뒤 ECS 작업 정의(Task Definition)의 taskRoleArn 파라미터에 지정
해당 작업을 실행하는 개별 컨테이너에 액세스 권한이 부여됨

컨테이너 권한 부여

스토리지

문제 1번

NFS ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

네트워크 파일 시스템
네트워크를 통해 서버나 스토리지의 디렉터리를 로컬 드라이브처럼 사용하게 해주는 분산 파일 시스템 프로토콜
주로 온프레미스 환경에서 사용

네트워크 파일 시스템

문제 2번

Amazon EFS (Elastic File System) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

수천 개의 인스턴스에서 동시 액세스 가능한 탄력적 파일 시스템
NFS 프로토콜 기반
주로 Linux/Unix 기반 인스턴스에서 사용
데이터가 다중 AZ에 걸쳐 중복 저장됨
Windows 파일 공유에는 부적절

Linux 공유 파일시스템

문제 3번

Amazon FSx for Windows File Server ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

Windows 기반 EC2 인스턴스 여러 대가 네이티브 SMB 프로토콜로 접근 가능한 공유 파일 시스템
Windows 파일 공유 환경에 적합
SMB 기반 워크로드 전용으로 자주 출제됨

SMB 공유 스토리지

문제 4번

Elastic ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

스스로 크기를 조절할 수 있는 유연한 특성 자체를 의미
수요 변화에 맞춰 용량이 자동 또는 유연하게 조절되는 개념
오토 스케일링은 이 특성을 구현하는 대표적인 방법 중 하나

자동 확장

문제 5번

S3 Standard ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

기본 스토리지 클래스
99.99% 가용성, 99.999999999% 내구성 제공
밀리초 단위의 빠른 접근 속도
데이터 검색 비용 없음
저장 비용은 다른 클래스 대비 가장 비쌈
자주 액세스하는 데이터에 적합
S3 요청자 지불 : 버킷 소유자가 아닌 데이터를 다운로드하는 요청자가 데이터 전송 및 요청 비용을 부담하도록 설정하는 기능
S3 Storage Lens
- 조직 전체 S3 사용 현황을 분석
- 객체 수, 용량, 액세스 빈도, 비활성 데이터등을 시각화 해준다.

자주 접근 데이터

문제 6번

S3 Intelligent-Tiering ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

접근 패턴을 알 수 없거나 변동성이 큰 데이터를 위한 클래스
접근 빈도를 자동 모니터링하여 비용 효율적인 계층으로 이동
검색 비용 없음
객체당 소액의 모니터링 및 자동화 비용 발생
접근 패턴 예측이 어려운 데이터에 적합

접근 패턴을 알 수 없는 액세스 패턴

문제 7번

S3 Standard-IA ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

자주 액세스하지 않지만 필요할 때 즉시 접근해야 하는 데이터용
Standard보다 저장 비용이 저렴
검색 비용이 발생
최소 30일 보관 및 128KB 최소 객체 크기 정책 존재
백업, DR 데이터, 드물게 보는 로그 파일에 적합

드물지만 즉시 접근

문제 8번

S3 One Zone-IA ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

Standard-IA와 유사하지만 단일 AZ에만 저장
저장 비용이 더 저렴
AZ 장애 시 데이터 유실 가능
재생성 가능한 데이터나 별도 백업본이 있는 경우 적합

단일 AZ 저비용

문제 9번

S3 Glacier Instant Retrieval ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

아카이브용 데이터이지만 밀리초 단위 즉시 접근 가능
Standard-IA보다 저장 비용이 더 저렴할 수 있음
검색 비용은 더 높음
최소 90일 보관 정책 존재
장기 보관하면서도 즉시 조회가 필요한 데이터에 적합

즉시 조회 아카이브

문제 10번

S3 Glacier Flexible Retrieval ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

접근 빈도가 매우 낮은 장기 보관 데이터용
검색 시 몇 분에서 몇 시간의 지연 허용
저장 비용이 매우 저렴
검색 비용 발생
최소 90일 보관 정책 존재

저렴한 장기보관

문제 11번

S3 Glacier Deep Archive ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

S3에서 가장 저렴한 스토리지 클래스
1년에 한두 번도 접근하지 않을 데이터용
데이터 검색에 12시간 이상 소요 가능
최소 180일 보관 정책 존재
규제 준수용 초장기 보관 데이터에 적합

최저가 초장기보관

문제 12번

S3 PutObjectLegalHold ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

S3 객체 잠금(Object Lock)의 법적 보존 기능과 관련된 권한
객체에 무기한 잠금을 설정 가능
삭제를 결정할 때까지 객체를 변경하거나 삭제하지 못하도록 제어
객체 삭제 권한을 세밀하게 통제할 때 사용

법적 객체 잠금

문제 13번

Amazon S3 Transfer Acceleration ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

S3 버킷 업로드/다운로드 속도를 가속화하는 서비스
장거리 전송에서 지연 시간을 줄이는 데 유리
CloudFront 엣지 로케이션을 활용
전 세계 사용자와 S3 버킷 간 전송 최적화에 적합

S3 글로벌 업로드 가속

문제 14번

Amazon EBS (Elastic Block Store) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

EC2 인스턴스의 하드 디스크 역할을 하는 지속적 블록 스토리지
볼륨과 스냅샷으로 구성
인스턴스 종료 후에도 데이터 유지 가능
기본적으로 단일 AZ에 종속됨
고가용성 파일 스토리지는 아님

볼륨 스토리지

문제 15번

IOPS (Input/Output Operations Per Second) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

1초 동안 스토리지가 처리할 수 있는 I/O 작업 수
값이 높을수록 더 많은 요청을 빠르게 처리 가능
스토리지 성능 지표로 자주 사용됨

스토리지 성능

문제 16번

Burst Credits ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

범용 SSD에서 일시적으로 높은 성능을 내기 위해 사용하는 성능 크레딧
평소에는 기준 성능 유지
트래픽 급증 시 크레딧을 사용해 최대 IOPS까지 성능 상승
크레딧 소진 시 다시 기준 성능으로 내려가며 지연 시간이 증가할 수 있음

일시 성능 증가

문제 17번

Provisioned IOPS SSD ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

사용자가 원하는 IOPS를 명시적으로 지정해 일관된 성능 보장
범용 SSD보다 비용이 높음
높은 I/O가 지속적으로 필요한 환경에 적합
예측 가능한 성능이 중요한 워크로드에서 사용

고정 고성능

문제 18번

S3 교차 리전 복제 (CRR, Cross-Region Replication) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

저장된 객체를 다른 리전의 대상 버킷에 자동으로 비동기 복사
한 리전 장애 시 데이터 보호 가능
원본/대상 버킷 모두 버전 관리 활성화 필요
두 버킷은 서로 다른 리전에 있어야 함
IAM 역할 설정 필요
설정 이후 새로 생성되거나 업데이트된 객체에만 적용

재해 복구(DR), 글로벌 사용자 속도 개선

문제 19번

S3 배치 복제 (Batch Replication) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

CRR 설정 이전에 이미 존재하던 객체까지 복제할 때 사용
기존 객체를 한 번에 복제하는 추가 작업 방식
과거 데이터 백필(backfill) 용도로 적합

기존 객체 복제

문제 20번

EBS Fast Snapshot Restore (FSR) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

스냅샷에서 생성한 볼륨의 성능을 즉시 최대 수준으로 사용할 수 있게 해주는 기능
초기 복원 지연 시간을 줄임
콜드 스타트 같은 초기 액세스 지연 문제를 해소
가용 영역별, 스냅샷 크기별 비용 부과

빠른 스냅샷 복원

문제 21번

Amazon S3 Event Notifications ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

S3 안에서 특정 이벤트가 발생하면 다른 AWS 서비스로 알림 전달
Lambda, SQS, SNS, EventBridge 등과 연동 가능
파일 업로드 후 자동 처리 워크플로에서 자주 사용
서버리스 이벤트 기반 아키텍처 핵심 기능
SageMaker Pipelines를 직접 대상으로 지정 불가

대표 이벤트

ObjectCreated → 파일 업로드됨
ObjectRemoved → 파일 삭제됨
PUT → 업로드/수정됨
COPY → 객체 복사됨
POST → 업로드됨

S3 이벤트 알림

컴퓨팅

문제 1번

온디맨드 용량 예약 (On-Demand Capacity Reservations) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

특정 시간 동안 원하는 인스턴스 타입과 수량만큼 EC2 용량을 선점
RI(예약 인스턴스)와 달리 장기 약정이 필요 없음
특정 AZ에서 용량 확보가 중요할 때 사용

EC2 용량 선점

문제 2번

AMI (Amazon Machine Image) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

EC2 인스턴스를 시작하는 데 필요한 설정과 데이터가 담긴 템플릿
루트 볼륨의 EBS 스냅샷을 포함
운영체제와 애플리케이션이 설치된 마스터 이미지 역할
동일한 환경의 인스턴스를 반복 생성할 때 사용

EC2 템플릿

문제 3번

Elastic Beanstalk ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

애플리케이션 코드를 업로드하면 배포, 용량 프로비저닝, 로드 밸런싱, Auto Scaling, 모니터링 등을 자동화
내부적으로 EC2, ELB, Auto Scaling, RDS 같은 AWS 서비스를 활용
애플리케이션 배포와 운영을 단순화하여 운영 오버헤드를 줄여줌
다만 완전한 서버리스 서비스는 아니며, 사용한 기본 리소스에 대한 비용은 별도로 발생

배포 자동화

문제 4번

EC2 Instance Store ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

EC2 호스트 머신에 직접 연결된 임시 블록 스토리지
매우 빠른 I/O 성능 제공
인스턴스가 중지되거나 종료되면 데이터가 사라질 수 있음
내구성보다 고성능 임시 저장소가 필요할 때 적합

초고속 임시 스토리지

문제 5번

Amazon ECS ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

AWS가 자체 제공하는 컨테이너 오케스트레이션 서비스
AWS 서비스와 통합이 쉽고 운영 복잡도가 낮음
Kubernetes 지식 없이도 컨테이너를 빠르게 배포 가능
AWS 환경에 최적화된 관리형 컨테이너 서비스
기존 애플리케이션을 최대한 유지하면서 AWS로 이전

AWS 컨테이너

문제 6번

Amazon EKS ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

AWS에서 관리하는 Kubernetes 서비스
Kubernetes 생태계의 유연성과 표준성을 활용 가능
멀티 클라우드 또는 Kubernetes 기반 운영에 적합
ECS보다 복잡하고 Kubernetes 지식이 필요함

Kubernetes 관리

문제 7번

AWS Fargate ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

컨테이너를 위한 서버리스 컴퓨트 엔진 (EC2 인스턴스가 없음)
EC2 인스턴스를 직접 프로비저닝하거나 관리할 필요 없이 컨테이너 실행 가능
ECS 또는 EKS와 함께 사용
운영 오버헤드를 크게 줄일 수 있음
지속적으로 일정한 트래픽이 있는 경우 EC2 기반보다 비용이 더 높을 수 있음

서버리스 컨테이너

문제 8번

EC2 Auto Scaling - Target Tracking ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

가장 일반적으로 사용하는 조정 방식
특정 지표를 목표값으로 유지하도록 자동으로 인스턴스 수를 조정
예: CPU 사용률 40% 유지
사용자가 복잡한 확장 규칙을 직접 만들 필요가 적음

자동 목표 추적

문제 9번

EC2 Auto Scaling - Simple Scaling ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

CloudWatch 알람 발생 시 고정된 수의 인스턴스를 추가하거나 제거
단순하고 직관적인 확장/축소 방식
쿨다운 이후 다음 조정 수행
세밀한 자동 최적화보다는 고정 규칙 기반 조정에 적합

고정 증감

문제 10번

EC2 Auto Scaling - Scheduled Scaling ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

특정 날짜나 시간에 맞춰 인스턴스 수를 미리 조정
트래픽 패턴이 예측 가능할 때 유용
예: 매주 평일 오전 9시에 트래픽 증가

예약 스케일링

문제 11번

Cluster Placement Group ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

인스턴스를 물리적으로 가까운 위치에 배치
단일 AZ 내에서 매우 낮은 지연 시간과 높은 네트워크 처리량 제공
HPC, 병렬 처리, 노드 간 초고속 통신이 필요한 워크로드에 적합
같은 하드웨어 장애의 영향을 함께 받을 수 있음

초저지연 HPC

문제 12번

Spread Placement Group ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

인스턴스를 서로 다른 하드웨어에 분산 배치
하드웨어 장애 격리를 통해 고가용성 확보
소규모 중요 인스턴스 그룹에 적합
Cluster 방식보다 네트워크 지연은 다소 증가할 수 있음

장애 격리

문제 13번

launchPermission ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

Amazon Machine Image(AMI)를 누가 실행할 수 있는지 정하는 권한
쉽게 말해 이 AMI를 어떤 AWS 계정이 사용할 수 있냐?를 설정하는 것
기본적으로 AMI는 내 계정에서만 사용 가능
다른 AWS 계정에 AMI를 공유하려면 launchPermission을 추가해야 함
특정 계정 ID를 지정하면 해당 계정만 AMI 실행 가능
AMI cross-account sharing 문제가 나오면 launchPermission을 떠올리면 됨

AMI 실행 권한 공유, 계정 간 AMI 공유

관리 및 거버넌스

문제 1번

AWS Systems Manager Patch Manager ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

OS 및 애플리케이션 패치 관리를 자동화
주로 OS 공급업체가 제공하는 패치를 대상에 적용
대규모 인스턴스 패치 운영에 적합

패치 자동화

문제 2번

AWS Systems Manager Run Command ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

여러 인스턴스에 동시에 작업을 수행할 때 적합
SSH 접속 없이 원격 명령 실행에 자주 사용됨

원격 명령 실행

문제 3번

Parameter Store ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

설정값, 환경 변수, 자격 증명 등을 저장할 수 있음
대규모 인스턴스 집합에 명령어나 스크립트를 즉시 실행 가능
자격 증명 저장소로 사용할 수 있음
하지만 Secrets Manager처럼 자동 교체 기능은 없음
자동 교체를 구현하려면 별도 Lambda 등을 직접 개발 및 운영해야 함

설정값 저장

문제 4번

AWS Cost Explorer ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

AWS에서 제공하는 비용 분석 전용 도구
별도 서비스 구축이나 추가 설정 없이 비용 분석 가능
필터링과 그룹화 기능으로 비용을 심층 분석할 수 있음
최소 운영 오버헤드로 비용 확인 가능

비용 분석

문제 5번

AWS CloudTrail ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

AWS 계정의 거버넌스, 규정 준수, 운영 감사 및 위험 감사를 지원
계정에서 발생한 API 활동을 기록 및 추적
누가 언제 어떤 API를 호출했는지 확인 가능
객체 삭제 자체를 막는 기능은 아님

API 감사 로그

문제 6번

Amazon CloudWatch ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

URL 공유를 통해 대시보드를 다른 사용자와 공유할 수 있음
지표, 로그, 경보를 통합적으로 모니터링 가능
운영 상태 시각화와 알림 구성에 핵심 서비스

모니터링

문제 7번

CloudWatch Composite Alarm ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

두 개 이상의 CloudWatch 경보를 논리 연산자(AND, OR, NOT)로 결합
여러 경보 조건을 조합해 더 정교한 알람 구성 가능
불필요한 알람 노이즈를 줄이는 데 유용

복합 알람

문제 8번

CloudWatch의 여러 임계값 모니터링 ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

하나의 메트릭에 대해 서로 다른 임계값의 경보를 각각 생성할 수 있음
예: CPU 사용률 50% 초과 시 Warning, 80% 초과 시 Critical
이는 같은 메트릭을 여러 수준으로 나누어 모니터링하는 방식
서로 다른 두 메트릭(CPU, IOPS 등)을 하나로 결합하는 기능은 아니며, 그런 경우는 Composite Alarm과 구분해야 함

단계별 경보

문제 9번

CloudWatch Logs Subscription ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

로그 그룹의 로그를 다른 서비스로 실시간 스트리밍 가능
OpenSearch Service는 공식 구독 대상 중 하나
로그 전달 파이프라인을 손쉽게 구성 가능
운영 오버헤드가 매우 적음

로그 스트리밍

문제 10번

AWS Config ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

AWS 리소스의 구성 상태를 기록하고 변경 이력을 추적
리소스가 어떤 상태였고 어떻게 변경되었는지 확인 가능
구성 규정 준수와 변경 관리에 중점
ACM 인증서 만료 관련 Managed Rule이 존재함
ACM 인증서가 지정한 기간 내에 만료되는지 검사
이 리소스에 특정 태그가 있는지, Owner 태그가 있는지 같은 규칙을 정의해서 자동으로 준수 여부를 검사할 수 있음

리소스 변경 추적

문제 11번

AWS Organizations ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

여러 AWS 계정을 중앙에서 관리하는 서비스
정책 기반으로 조직 전체를 제어 가능
통합 결제와 계정 관리에 유용
멀티 계정 환경에서 표준화된 운영에 적합

멀티 계정 관리

문제 12번

관리 계정 (구 마스터 계정) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

조직을 관리하는 중심 계정
결제와 정책 관리를 담당
Organizations의 관리 작업을 수행하는 계정

조직 중앙 계정

문제 13번

서비스 제어 정책 (SCP) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

IAM 정책과 유사하지만 최대 권한 범위를 정의
ㅇㅇ에서 허용되지 않은 작업은 계정 내에서 절대 수행할 수 없음
Organizations 단위로 권한 상한선을 설정할 때 사용

권한 상한 제한

문제 14번

AWS Trusted Advisor ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

AWS 환경이 모범 사례를 따르고 있는지 점검
비용 절감, 성능 개선, 보안 강화, 서비스 한도 등 권장 사항 제공
기본 점검은 무료
전체 점검은 비즈니스 또는 엔터프라이즈 지원 플랜 필요
기본적으로 리소스가 존재하는 계정에서 보는 게 원칙

AWS 모범 사례 점검

문제 15번

S3 Object Lock - Governance Mode ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

높은 수준의 보호를 제공하지만 일부 권한 사용자에게는 우회 가능
s3:BypassGovernanceRetention 권한이 있으면 잠금을 우회 가능
운영 유연성을 어느 정도 유지하면서 객체 보호 가능

우회 가능한 객체 잠금

문제 16번

S3 Object Lock - Compliance Mode ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

최고 수준의 불변성 제공
보존 기간 동안 어떤 사용자도 객체를 수정하거나 삭제할 수 없음
AWS 루트 사용자도 잠금 해제 불가
규제 준수와 강한 데이터 보호에 적합

절대 삭제 불가 잠금

마이그레이션 및 하이브리드

문제 1번

Snowball Edge ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

Snowball 패밀리 중 하나
페타바이트 규모 데이터를 AWS 클라우드로 물리적으로 전송하기 위한 휴대용 스토리지 및 컴퓨팅 디바이스
대규모 데이터 마이그레이션에 적합
네트워크 대역폭이 부족하거나 네트워크 전송이 비효율적일 때 사용

오프라인 대용량 전송, 네트워크 대역폭 부족

문제 2번

S3 File Gateway ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

AWS Storage Gateway의 한 유형
온프레미스 환경과 AWS 클라우드 스토리지를 연결
온프레미스 애플리케이션이나 파일 서버가 S3 버킷을 로컬 파일 공유처럼 사용 가능
자주 액세스되는 데이터는 로컬 디스크에 캐시되어 짧은 지연 시간 제공
실제 데이터는 S3 객체로 저장되어 높은 확장성과 내구성 확보
S3 수명 주기 정책과 연계 가능

온프레미스 S3 연결

문제 3번

AWS DataSync ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

온프레미스와 AWS 간 대규모 데이터 전송을 자동화하고 최적화하는 서비스
파일, 객체 스토리지 전송에 적합
온프레미스 환경에 에이전트 설치가 필요
원본(Source)과 대상(Destination)을 지정해 데이터 이동 수행
대용량 파일을 빠르고 안전하게 이전할 때 적합
파일 서버(NFS/SMB), S3, EFS 등 스토리지 간 대용량 파일과 객체 전송에 적합
파일 기반 비정형 데이터 이전에 사용
파일 전송 최적화 서비스

대용량 파일 전송

문제 4번

AWS DMS (Database Migration Service) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

데이터베이스 테이블을 마이그레이션하는 서비스
마이그레이션 중 변경 사항을 실시간으로 복제 가능(CDC)
서로 다른 DB 엔진 간 이전도 지원
정형 데이터 이전에 적합
지속적인 복제 서버를 생성해야 한다.

DB 마이그레이션

문제 5번

AWS Schema Conversion Tool (AWS SCT) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

데이터베이스 마이그레이션을 자동화하는 도구
서로 다른 데이터베이스 엔진 간 마이그레이션 시 사용
스키마, 저장 프로시저, 함수, 트리거 같은 코드 객체를 타겟 엔진 형식에 맞게 변환
이기종 DB 마이그레이션에서 핵심 역할 수행

DB 스키마 변환

기본 개념 및 아키텍처

문제 1번

다중 AZ (Multi-AZ, Availability Zone) 구성 ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

동일한 AWS 리전 내에서 물리적으로 분리된 두 개 이상의 가용 영역(AZ)에 서비스 구성 요소를 분산 배치하는 방식
고가용성을 높이기 위한 대표 아키텍처
하나의 AZ 장애가 전체 서비스 중단으로 이어지지 않도록 설계할 때 사용

고가용성

문제 2번

RDS 다중 AZ 구성 (RDS Multi-AZ) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

데이터베이스의 동기식 복제본을 다른 AZ에 자동 생성 및 관리
주 DB에 장애가 발생하면 AWS가 대기 복제본으로 자동 장애 조치 수행
데이터 손실을 최소화하고 서비스 중단 시간을 줄이는 데 적합
고가용성이 중요한 운영 데이터베이스에 자주 사용됨

DB 자동 장애조치

문제 3번

RTO (Recovery Time Objective) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

장애 발생 후 시스템을 정상 상태로 복구하는 데 허용되는 최대 시간
서비스 중단 시간 최소화와 직접 관련됨
복구 속도가 중요한 재해 복구 목표 지표

복구 시간 목표

문제 4번

RPO (Recovery Point Objective) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

장애 발생 시 허용 가능한 최대 데이터 손실량을 의미
백업 또는 복제 주기를 정하는 핵심 기준
예를 들어 ㅇㅇ가 15분이면 최대 15분 전 데이터까지만 손실 가능하다는 뜻

데이터 손실 허용치

문제 5번

팬 아웃 (Fan-out) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

하나의 메시지를 여러 목적지나 여러 수신자에게 동시에 복제해 전달하는 메시징 패턴
분산 시스템에서 병렬 처리와 다중 소비자 아키텍처에 자주 사용
하나의 이벤트를 여러 시스템이 동시에 받아야 할 때 적합

메시지 다중 전달

문제 6번

활성/대기 (Active/Standby) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

고가용성을 위해 한 서버는 실제 트래픽을 처리하고 다른 서버는 대기 상태로 유지하는 구조
대기 서버는 활성 서버 상태를 감시하며 필요 시 역할을 인계받음
장애 발생 시 빠르게 서비스 복구가 가능
데이터베이스, 메시지 브로커, 방화벽 등 핵심 인프라에 자주 사용

활성-대기 구조

애플리케이션 통합

문제 1번

Amazon SQS (Simple Queue Service) ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

MSA, 분산 시스템, 서버리스 애플리케이션 통합에 사용하는 메시지 큐 서비스
Producer가 메시지를 넣고 Consumer가 메시지를 가져가 처리하는 구조
시스템 간 결합도를 낮추고 비동기 처리를 가능하게 함

비동기 메시지 큐

문제 2번

SQS FIFO Queue ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

메시지 순서를 보장
중복 없는 처리를 지원
순서가 절대적으로 중요한 워크로드에 적합
처리량보다 정확한 순서 보장이 우선일 때 사용

순서 보장 큐

문제 3번

SQS Standard Queue ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

메시지 순서를 보장하지 않음
최소 1회 전달(at-least-once delivery)
매우 높은 처리량 제공
순서보다 확장성과 처리량이 중요한 경우 적합

고처리량 큐

문제 4번

SQS ReceiveMessage API ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

소비자가 메시지를 가져올 때 사용하는 API
장기 폴링(Long Polling)에 사용 가능
메시지가 올 때까지 일정 시간 기다리도록 설정 가능
빈 응답을 줄여 네트워크 트래픽과 비용을 절감

장기 폴링

문제 5번

SQS ChangeMessageVisibility API ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

메시지를 가져온 뒤 가시성 제한 시간을 연장할 때 사용
메시지 처리 시간이 기본 Visibility Timeout보다 길어질 때 유용
다른 소비자가 같은 메시지를 중복 처리하는 상황을 방지

가시성 연장

문제 6번

Amazon AppFlow ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

코드를 작성하지 않고 SaaS 애플리케이션과 AWS 서비스 간 데이터 이동 및 변환 가능
Salesforce, SAP, Zendesk, Marketo, Google Analytics 등과 연동 가능
S3, Redshift 같은 AWS 서비스로 데이터 전송 가능
운영 오버헤드는 낮지만 비용은 발생

SaaS 데이터 연동

문제 7번

Amazon MQ ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

AWS에서 제공하는 관리형 메시지 브로커 서비스
Apache ActiveMQ, RabbitMQ 같은 메시지 브로커를 쉽게 운영 가능
설치, 패치, 업그레이드, 장애 복구 같은 운영 부담을 AWS가 줄여줌
Multi-AZ 배포를 통해 고가용성 확보 가능

관리형 메시지 브로커

AI 및 머신러닝 서비스

문제 1번

Amazon Textract ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

스캔된 문서나 이미지에서 텍스트를 자동 추출
수기 문자도 인식 가능
양식 데이터의 키-값 쌍 추출 가능
테이블 구조를 분석하고 추출 가능
OCR을 넘어서 문서 구조 자체를 이해하는 데 강점이 있음

OCR 문서 분석

문제 2번

Amazon Rekognition ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

이미지와 동영상에서 객체, 사람, 활동을 감지하고 분석
얼굴 분석, 객체 탐지, 콘텐츠 검토 등에 사용
부적절한 콘텐츠 감지도 가능
이미지 및 비디오 분석 서비스로 자주 출제됨

이미지/영상 분석

문제 3번

Amazon Comprehend Medical ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

의료 기록, 처방전, 임상 시험 보고서 같은 비정형 의료 텍스트를 분석
질병, 약물, 복용량, 치료법 등의 의료 정보를 자동 추출
의료 데이터를 구조화된 정보로 변환하는 데 적합
일반 NLP가 아니라 의료 특화 텍스트 분석 서비스

의료 NLP

문제 4번

Amazon Cognito ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

회원가입 / 로그인 / 인증 / 권한관리까지 다 해주는 AWS 서비스
User Pool (유저 관리 ) , Identity Pool (권한 관리)

회원 인증 관리

기타

문제 1번

AWS Lambda ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

서버리스 컴퓨팅
이벤트 기반 실행
작은 코드 / Python / Node.js
운영 오버헤드 최소화
S3 이벤트 처리
API Gateway 뒤의 백엔드
서버를 프로비저닝하거나 관리하지 않고 코드를 실행하는 컴퓨팅 서비스

서버리스 실행, 운영 오버헤드 최소화

문제 2번

Amazon API Gateway ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

REST API / HTTP API / WebSocket API
Lambda 앞단
서버리스 API
인증, throttling, 모니터링

서버리스 API

문제 3번

Amazon EventBridge ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

이벤트 라우팅
여러 타깃으로 분기
SaaS / AWS 서비스 이벤트
S3 ObjectCreated 이벤트 후 여러 작업 실행
Lambda, Step Functions, SageMaker 등으로 연결
이벤트 버스 기반으로 여러 소스의 이벤트를 받아 타깃으로 라우팅하는 서버리스 이벤트 서비스
S3도 Object Created 같은 이벤트를 보낼 수 있어서, S3 이벤트를 여러 대상에 연결하는 문제에서 중요

이벤트 라우팅

문제 4번

AWS Transfer Family ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

SFTP / FTPS / FTP
파트너 파일 업로드
S3 또는 EFS 대상
운영 오버헤드 최소화

SFTP to S3, SFTP로 S3에 업로드

문제 5번

Amazon FSx for Lustre ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

HPC
수백 개 EC2 병렬 처리
초고속 공유 파일 시스템
S3와 통합
ML / 시뮬레이션 / 금융 모델링

HPC 파일 시스템, 고성능 파일 시스템

문제 6번

Amazon Transcribe ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

음성 → 텍스트
대본 생성
화자 분리
콜센터 녹음

음성 텍스트 변환, 여러 화자 인식

문제 7번

AWS Backup ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

장기 백업 보관
1년, 5년, 7년 보존
자동 삭제
중앙 백업 관리
Vault Lock

중앙 백업 관리 문제

문제 8번

S3 Lifecycle ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

30일 후 IA
90일 후 Glacier
일정 기간 후 삭제
접근 패턴이 명확함

자동 스토리지 전환

문제 9번

AWS Step Function ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

여러 작업을 순서대로 연결해서 흐름(워크플로)을 관리해주는 서비스

워크플로 orchestration

문제 10번

aws:PrincipalOrgID ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

AWS Organizations 전체 조직 접근 제한 조건 키
특정 Organizations에 속한 계정만 접근 허용 가능
S3 버킷 정책, KMS 정책 등에서 자주 사용
외부 AWS 계정 접근 차단에 유용

Organizations 전체 제한

문제 11번

aws:PrincipalOrgPaths ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

Organizations 내부 특정 OU(Organizational Unit) 기준 접근 제한
조직 전체가 아니라 특정 부서/OU만 허용 가능
세밀한 권한 제어 시 사용
멀티 계정 환경에서 자주 출제됨

특정 OU 제한

문제 12번

AWS Budgets ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

비용이나 사용량이 특정 임계값을 초과하면 알림 제공
예산 초과 감지에 사용
이메일 또는 SNS 알림 가능
비용 제어 및 운영 모니터링에 활용
Cost Explorer는 분석, Budgets는 임계값 알림 느낌으로 구분

비용 초과 알림

문제 13번

AWS Well-Architected Framework ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

AWS에서 권장하는 클라우드 아키텍처 모범 사례 프레임워크
안정적이고 효율적이며 안전한 시스템 설계를 위한 기준 제공
운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화, 지속 가능성 총 6가지 핵심 요소로 구성
아키텍처 리뷰 및 개선 방향 점검 시 사용

AWS 아키텍처 모범 사례, 아키텍처 검토, 비용/성능/보안 최적화

문제 14번

AWS Direct Connect ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

온프레미스 데이터센터와 AWS를 전용 네트워크 회선으로 연결하는 서비스
인터넷을 거치지 않음
더 안정적이고 낮은 지연 시간 제공
대용량 데이터 전송 및 하이브리드 환경에 적합
일반 인터넷 VPN보다 더 안정적인 연결 가능
금융, 기업, 대규모 엔터프라이즈 환경에서 자주 사용

AWS 전용 네트워크 회선, 전용선, 안정적 네트워크, 낮은 지연 시간, 하이브리드 연결

문제 15번

AWS Glue Job Bookmark ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

AWS Glue가 이전 실행에서 어디까지 처리했는지 기억하는 기능
다음 실행 시 이미 처리한 데이터는 건너뛰고 새 데이터만 처리
S3에 매일 새로운 파일이 추가되는 ETL 작업에서 자주 사용
오래된 데이터를 반복 처리하지 않도록 도와줌
증분 처리(Incremental Processing)에 적합

Glue + 이전 데이터 재처리 방지 + 새 데이터만 처리 = Job Bookmark

문제 18번

AWS Control Tower ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

AWS Organizations 기반 멀티 계정 관리 서비스
AWS 계정 생성 및 관리 자동화
보안, 규정 준수, 거버넌스 환경을 빠르게 구축 가능
Landing Zone을 자동으로 구성
Guardrail을 통해 조직 전체 정책 적용 가능
여러 AWS 계정을 중앙에서 관리할 때 사용

멀티 계정 + 보안 + 규정 준수 + 자동화

문제 19번

Pilot Light / Warm Standby ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

Pilot Light는 재해 복구에 필요한 핵심 인프라만 최소로 켜두는 방식
보통 DB 복제본, 네트워크, 설정 정도만 유지하고 애플리케이션 서버는 장애 시 확장/기동
평상시 비용이 낮지만, 복구 시 서버 확장 시간이 필요함
Warm Standby는 축소된 애플리케이션 환경을 항상 실행해두는 방식
평상시에도 작은 규모로 서비스가 동작 가능하며, 장애 시 빠르게 확장
Pilot Light보다 비용은 높지만 RTO가 더 짧음

비교

Pilot Light → 핵심만 켜둠 / 비용 낮음 / 복구 느림
Warm Standby → 축소 버전 실행 중 / 비용 중간 / 복구 빠름
Active-Active → 양쪽 리전 모두 트래픽 처리 / 비용 높음 / 복구 가장 빠름

시험 키워드

평소에는 부하 처리 필요 없음 → Pilot Light
축소된 환경이 항상 실행 중 → Warm Standby
두 리전 모두 평소에도 트래픽 처리 → Active-Active
백업에서 새로 복원 → Backup and Restore

Pilot Light는 최소 대기, Warm Standby는 축소 운영

문제 20번

AWS WAF ⬅️ 정답을 보려면 드래그 하세요.

핵심 정리

웹 애플리케이션을 보호하는 웹 방화벽 서비스
HTTP/HTTPS 요청을 검사하고 허용 또는 차단
SQL Injection, XSS 같은 웹 공격 방어
IP 주소, HTTP 헤더, URI, 쿼리 문자열, 요청 본문 등을 기준으로 필터링 가능
CloudFront, ALB, API Gateway, AppSync와 연동 가능
Web ACL을 만들어 보호 대상 리소스에 연결
AWS Managed Rules 사용 가능
Rate-based Rule로 과도한 요청 차단 가능
인바운드 웹 요청 보호용 서비스
EC2의 아웃바운드 인터넷 접근 제어는 불가능

자주 헷갈리는 포인트

AWS WAF → 웹 요청 HTTP/HTTPS 보호
AWS Shield → DDoS 공격 방어
AWS Network Firewall → VPC 네트워크 트래픽 방화벽
Security Group → 인스턴스/ENI 단위 인바운드·아웃바운드 제어
NACL → 서브넷 단위 네트워크 ACL

웹 공격 방어, SQL Injection/XSS 차단, HTTP 요청 필터링

16KB 페이지 크기 지원하기

Inseong2 — Wed, 3 Dec 2025 12:12:21 +0900

안녕하세요. 스타트업에서 프론트엔드 개발을 맡고 있는 inseong입니다

2탄에서는 구체적으로 어떤식으로 React Native 버전을 업데이트 시키고, 16KB 페이지 크기를 지원했는지에 대해 정리해볼려고 합니다.

React Native 버전 결정

▫️ 현재 사용 중인 RN 버전 : 0.73.0
▫️ 업데이트 예정 버전 : 0.79.7

React Native 릴리즈 노트를 보면 0.77 버전부터 16KB 페이지 크기를 완전히 지원한다고 안내되어 있습니다.
즉, Android 15 환경에서 안정적으로 테스트하고 배포하려면 최소 이 버전 이상으로는 올려야 하는 상황이였습니다.

작업 당시 최신 버전은 0.82까지 나와 있었지만, 0.80 이후부터는 레거시 아키텍처 제거와 내부 구조 변경 폭이 굉장히 커졌습니다.
특히 기존 프로젝트에서 사용 중인 라이브러리들이 한 번에 대응하지 못할 가능성이 높았기 때문에

① 16KB 지원 가능
② 레거시 구조 유지 가능
③ 라이브러리 대응 범위 확보 가능

3가지를 기준으로 0.79.7 버전을 선택하게 되었습니다.

구성 설정 파일 변경

React Native Upgrade Helper를 사용해서 프로젝트 전반의 설정 파일들을 새 버전에 맞게 하나씩 수정해줘야 합니다.

(왼) 현재 0.73의 package.json (오) 업데이트할 0.79.7의 package.json

실제로는 약 30개 가까운 파일들을 수정하게 됩니다.

여기서 중요한 건 코드보다 설정 파일 맞추는 작업이 더 오래걸릴 수도 있습니다 ^^..

라이브러리 충돌 확인

설정 파일 업데이트가 끝났다면

① node_modules 삭제
② package-lock 제거
③ npm install 재설치
⑤ npm run android 실행

이 순서로 진행하게 됩니다.

근데 이때부터 진짜 충돌 지옥이 시작됩니다

예전 RN 버전 기준으로 만들어진 레거시 라이브러리들이 최신 Android API 구조를 따라오지 못하면서 하나씩 터지기 시작합니다.

1️⃣ react-native-reanimated

대표적인 RN 애니메이션 라이브러리입니다.

RN 0.79 환경에서는 최소 Reanimated 3.x 이상 조합이 필요합니다.

특히 4.x는 New Architecture 기반이라 기존 프로젝트에서는 오히려 더 위험할 수 있어서 3.17 버전으로 갔습니다.

// 설치 방법
npm install react-native-reanimated@~3.17.4 --save

2️⃣ react-native-gesture-handler

터치/제스처 관련 라이브러리입니다.

RN 0.79.x에서는 최소 2.28 이상이 필요했습니다.

// 설치 방법
npm install react-native-gesture-handler@^2.28.0 --save

3️⃣ react-native-safe-area-context & react-native-screens

React Navigation 쓰는 프로젝트면 거의 필수급 라이브러리입니다.

최신 RN의 ViewManager / Fabric API 구조를 따라가지 못하면 바로 빌드 에러가 발생합니다.

// 설치 방법
npm install react-native-safe-area-context@latest react-native-screens@latest --save

4️⃣ react-native-svg

RN 내부 API 변경을 라이브러리가 인식하지 못해서 생기는 컴파일 에러였습니다.

// 설치 방법
npm install react-native-svg@^15.15.0 --save

5️⃣ react-native-webview

옛날 타입 정의 때문에 nullable 관련 에러가 발생했습니다.

// 설치 방법
npm install react-native-webview@^13.13.2 --save

6️⃣ react-native-snap-carousel

생각보다 여기서도 삽질했습니다…

deprecated-react-native-prop-types 패키지가 없어서 에러가 발생했습니다.

// 설치 방법
npm install deprecated-react-native-prop-types --save

기타 에러 확인

여기서 끝이 아닙니다

버전 충돌 말고도 RN 내부 구조 변경 때문에 각종 레거시 코드들이 추가로 터지게 됩니다.

1️⃣ LegacyArchitectureLogger

이건 react-native-gradle-plugin 버전이 서로 안 맞을 때 발생했습니다.

중요한 건 아래 3개 버전이 전부 동일하게 0.79.7 기준을 바라봐야 한다는 점입니다

① package.json
② react-native-gradle-plugin
③ react-android / hermes-android

2️⃣ Duplicate class

AndroidX와 구형 support 라이브러리가 동시에 들어오면서 발생한 문제였습니다.

// 강제로 support-compat 제거
configurations.all {
    exclude group: "com.android.support", module: "support-compat"
}

3️⃣ @Babel / runtime

JS 번들 단계에서 터졌던 에러입니다.

// 에러 로그
Error: Unable to resolve module @babel/runtime/helpers/interopRequireDefault

// 설치 방법
npm install @babel/runtime --save

4️⃣ ReactNativePublicAPI

예전 Babel preset 구조 때문에 생긴 문제였습니다.

결국 babel.config를 최신 RN 방식으로 교체해줘야 했습니다.

// babel.config.js
module.exports = {
  presets: ['module:@react-native/babel-preset'],
  plugins: [
    [
      'module:react-native-dotenv',
      {
        envName: 'APP_ENV',
        moduleName: '@env',
        path: `.env.${process.env.APP_ENV}`,
      },
    ],
    [
      'module-resolver',
      {
        root: ['./src'],
        extensions: ['.ios.js', '.android.js', '.js', '.json', '.ts', '.tsx'],
        alias: {
          '@': './src',
        },
      },
    ],
    'react-native-reanimated/plugin',
  ],
};

5️⃣ Recoil 오류

오류 내용 : Cannot read property 'ReactCurrentDispatcher' of undefined

Recoil 내부에서 React internals를 직접 건드리고 있었는데, 최신 React 구조에서 깨지는 상황이였습니다.

node_modules \ recoil \ native \ index.js에서 변경

// React 19에서는 어차피 useSyncExternalStore 지원 확실하니까
// 위험한 React internals 접근은 다 버리고, 함수 존재 여부만 본다.
function currentRendererSupportsUseSyncExternalStore() {
  if (typeof useSyncExternalStore === 'function') {
    // React 18+ / 19에서는 항상 true일 것
    return true;
  }

  // 혹시나 구형 렌더러인 경우만 false
  return false;
}

▫️ patch-package로 패치 고정

npx patch-package recoil

6️⃣ BackHandler 오류

이건 RN 오래된 프로젝트면 꽤 많이 볼 수 있는 오류입니다.

BackHandler.removeEventListener is not a function

RN 최신 버전에서는 removeEventListener가 제거되었는데, 레거시 라이브러리들은 아직도 이 방식을 사용하고 있었습니다.

그래서 앱 시작점에서 폴리필 방식으로 대응했습니다. 이런건 진짜 RN 마이그레이션 안 해보면 모르는 포인트 같습니다

// BackHandler removeEventListener 폴리필 (RN 0.65+ 이후용)
import { BackHandler } from 'react-native';

// RN 0.79+ 처럼 removeEventListener가 없는 경우에만 폴리필 적용
if (!BackHandler.removeEventListener) {
  // 원래 addEventListener 저장
  const originalAddEventListener =
    BackHandler.addEventListener.bind(BackHandler);

  // handler -> subscription 매핑
  const backPressSubscriptions = new Map();

  // addEventListener 래핑해서 등록된 handler 기억
  BackHandler.addEventListener = (eventName, handler) => {
    const subscription = originalAddEventListener(eventName, handler);

    if (eventName === 'hardwareBackPress' && typeof handler === 'function') {
      backPressSubscriptions.set(handler, subscription);
    }

    return subscription;
  };

  // removeEventListener 폴리필
  BackHandler.removeEventListener = (eventName, handler) => {
    if (eventName !== 'hardwareBackPress' || typeof handler !== 'function') {
      return;
    }

    const subscription = backPressSubscriptions.get(handler);
    if (subscription && typeof subscription.remove === 'function') {
      subscription.remove();
      backPressSubscriptions.delete(handler);
    }
  };
}

레거시 라이브러리 교체 및 확인

가장 위험한 건 몇 년째 관리 안되는 라이브러리였습니다.

대표적으로 react-native-responsive-linechart는 마지막 배포가 무려 5년 전이였습니다. RN 0.78 이상도 지원하지 않아서 결국 교체가 필요했습니다.

결국 react-native-gifted-charts로 교체 했으며 RN 버전 올릴 때는 최근 배포일 Github issue 활동 여부 최신 RN 대응 여부를 확인해야 합니다.

왼쪽 : 변경 전 , 오른쪽 : 변경 후

aab 파일 추출

최종적으로 aab 파일을 추출해서 Play Console에 업로드하면, 16KB 미지원 라이브러리 경고가 더 이상 나타나지 않는걸 확인할 수 있습니다.

여기까지 React Native 16KB 페이지 크기 대응 작업을 정리해봤습니다

처음에는 단순 버전 업데이트라고 생각했는데, 실제로 해보니까 정책 대응부터 Gradle, Babel, Hermes, 라이브러리 충돌까지 전부 같이 봐야하는 작업이였습니다.

특히 오래된 RN 프로젝트일수록 RN 버전 하나가 앱 전체를 흔들 수 있는 경험을 느꼈고 혹시 비슷한 상황에서 삽질 중인 분들이라면 조금이라도 도움이 되었으면 좋겠습니다.

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