oldserver 님의 블로그

AWS 다운사이즈 후 모니터링 — t3 버스터블 CPU 크레딧·Redis Evictions·RDS FreeableMemory

oldserver — Sun, 1 Nov 2026 15:02:31 +0900

INFRA · 모니터링

다운사이즈한 뒤가 진짜다

버스터블은 CPU%가 아니라 "CPU 크레딧"을 본다. 크레딧·Evictions·여유메모리 지켜보는 법.

14일차에서 AWS 인스턴스를 다운사이즈해 비용을 약 1/3 줄였다. 그런데 다운사이즈는 끝이 아니라 시작이다. 스펙을 내렸으면 "정말 그 스펙으로 버티는지"를 며칠 지켜봐야 한다. 특히 버스터블(t3/t4g)로 내린 경우, 평소 CPU% 그래프만 봐서는 위험 신호를 놓친다.

이 글은 다운사이즈 후 무엇을, 왜, 어떻게 보는지다. 핵심은 세 가지 — 버스터블의 CPU 크레딧, Redis의 Evictions, RDS의 FreeableMemory. (수치는 예시다.)

왜 "CPU%"가 아니라 "크레딧"인가

연산최적(c계열) 같은 비버스터블은 CPU%만 보면 된다. 그런데 버스터블(t3/t4g)은 다르다. "평소엔 적게 쓰고, 가끔 치솟을 때 크레딧을 꺼내 쓰는" 모델이다.

그림 1. 버스터블은 baseline 기준으로 크레딧이 적립/소진된다. 크레딧이 0이면 성능이 제한된다.

즉 버스터블에서 진짜 위험 신호는 "CPU 80%"가 아니라 "CPU 크레딧이 계속 줄어 0에 가까워지는 것"이다. CPU%만 보면 "아직 80%인데 왜 느리지?"에서 막힌다. 그래서 다운사이즈 후엔 CPUCreditBalance를 1순위로 본다.

① EC2 버스터블 — CPU 크레딧 (가장 중요)

# 대상 인스턴스들의 최근 6시간 크레딧 추이
for id in <INSTANCE_ID_1> <INSTANCE_ID_2>; do
  echo "=== $id ==="
  aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUCreditBalance \
    --dimensions Name=InstanceId,Value=$id \
    --start-time $(date -u -d '6 hours ago' +%Y-%m-%dT%H:%M:%SZ) \
    --end-time   $(date -u +%Y-%m-%dT%H:%M:%SZ) \
    --period 300 --statistics Average \
    --query "Datapoints[-5:].{T:Timestamp,Credit:Average}" --output table
done

판정 — 값이 유지되거나 증가 → ✅ 안전(CPU가 baseline 이하). 계속 감소하거나 0 근접 → ⚠ 피크에 CPU 초과 중, 지속되면 상향 검토. 실제로 다운사이즈 당일 72 → 86 → 97로 증가했고, 피크 후엔 상한에 도달해 있었다 — 이 워크로드엔 t3.medium이 충분했다는 뜻.

unlimited 모드 — 크레딧 0이어도 안 멈춘다

버스터블에는 unlimited 모드가 있다. CpuCredits=unlimited면 크레딧이 0이어도 성능을 유지하고 초과분만 소액 과금한다(서비스 중단 없음). 다운사이즈하면서 켜두면 "크레딧 소진 → 갑자기 느려짐"이라는 최악은 피한다. 대신 꾸준히 초과하면 과금이 쌓이니, 그럴 땐 unlimited로 버티지 말고 인스턴스를 상향하는 게 답이다.

② Redis — Evictions와 메모리

Redis를 작은 노드로 내렸다면 메모리가 관건이다. CPU는 거의 안 쓰니 볼 필요 없고, 메모리 사용률과 Evictions를 본다.

redis-cli -h <REDIS_ENDPOINT> -p 6379 info memory | grep -iE "used_memory_human|maxmemory_human"
redis-cli -h <REDIS_ENDPOINT> -p 6379 info stats  | grep evicted

판정 — used_memory가 maxmemory의 80%를 넘으면 주의. evicted_keys가 0이 아니면 메모리 부족으로 키가 쫓겨나는 중 → 상위 노드로.

Evictions가 핵심이다. 메모리가 꽉 차면 Redis는 오래된 키를 강제로 버리는데(eviction), 이게 캐시 미스·세션 유실로 이어진다. 다운사이즈 후 Evictions가 0을 유지하면 그 노드로 충분한 것이다. redis-cli가 없으면 CloudWatch의 DatabaseMemoryUsagePercentage로도 본다.

③ Aurora RDS — FreeableMemory

for id in <DB_INSTANCE_1> <DB_INSTANCE_2>; do
  echo "=== $id ==="
  aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name FreeableMemory \
    --dimensions Name=DBInstanceIdentifier,Value=$id \
    --start-time $(date -u -d '6 hours ago' +%Y-%m-%dT%H:%M:%SZ) \
    --end-time   $(date -u +%Y-%m-%dT%H:%M:%SZ) \
    --period 300 --statistics Minimum \
    --query "Datapoints[-5:].{T:Timestamp,FreeBytes:Minimum}" --output table
done

판정 (바이트 → GB = ÷ 1073741824): FreeableMemory가 1GB 밑으로 떨어지면 주의. 기준선 예시: share 약 6GB, log 약 3.5GB 여유 → 안전. RDS도 버스터블(t4g)로 내렸다면 EC2처럼 크레딧이 추가로 중요하지만, CPU가 한 자릿수로 꾸준하면 크레딧이 계속 적립돼 소진 걱정은 없다. 비버스터블(r계열)은 크레딧 개념이 없으니 CPU%와 FreeableMemory만 본다.

기준선을 기록해두는 게 핵심

모니터링에서 제일 중요한 건 "패치 당일 기준선"을 숫자로 적어두는 것이다. 나중에 "이게 정상인가?"를 판단하려면 비교 대상이 있어야 한다.

항목	패치 당일(예시)	피크 후(예시)	상태
EC2 크레딧	72 → 97 (증가)	상한 도달	✅
Redis 메모리	15% / Evictions 0	유지	✅
RDS share 여유	~6GB	~5.7GB	✅
RDS/EC2 CPU	한 자릿수	한 자릿수	✅

당일과 피크 후(트래픽 많은 시간대 지난 뒤)를 같은 명령으로 두 번 찍어 비교하면, "다운사이즈가 안전했다"를 데이터로 확인할 수 있다. 감이 아니라 숫자로.

이상 징후 시 조치 — 전부 즉시 롤백 가능

좋은 점은, 위험 신호가 보여도 타입 변경은 상위 타입으로 즉시 되돌릴 수 있다(데이터 손실 없음). 그래서 과감하게 내려보고, 지켜보다 아니면 올리면 된다.

신호	조치
EC2 크레딧 0 근접/지속 감소	인스턴스 유형 상향(t3.medium → t3.large)
Redis Evictions 증가 / 메모리 80%+	상위 캐시 노드로
RDS FreeableMemory 1GB 미만	해당 인스턴스 상향(즉시 롤백, 데이터 유지)

마치며

다운사이즈는 "줄이기"가 절반, "지켜보기"가 나머지 절반이다. 그리고 지켜볼 때 버스터블은 CPU%가 아니라 CPU 크레딧을 봐야 한다는 게 이 글의 핵심이다. CPU%만 보면 "80%인데 왜 느리지"에서 막히지만, 크레딧을 보면 "크레딧이 0이라 baseline으로 제한됐구나"가 바로 보인다.

세 지표 — EC2 CPU 크레딧, Redis Evictions, RDS FreeableMemory — 를 패치 당일과 피크 후로 두 번 찍어 기준선과 비교하면, 비용 절감이 안전했는지 숫자로 확인된다. 전부 즉시 롤백 가능하니 신호가 나쁘면 되돌리면 그만이다. 과감하게 줄이되, 며칠은 꼭 지켜보자.

AWS 비용 최적화 · 버스터블 운영 · 모니터링 문의

댓글로 편하게 남겨주세요.

Adjust 어트리뷰션 S3 BI 파이프라인

oldserver — Mon, 26 Oct 2026 10:15:46 +0900

DATA · 어트리뷰션 BI

Adjust 데이터를 S3로 받아 사내 BI 대시보드 만들기

Adjust는 pull이 아니라 S3 push. IAM 키를 업로더/리더로 나누고, gzip·헤더·키 함정을 넘은 기록.

10일차에서 AppsFlyer를 Pull API로 받는 배치를 만들었다면, 이번엔 Adjust를 붙였다. 그런데 접근 방식이 다르다. 우리가 API로 당겨오는(pull) 게 아니라, Adjust가 매시 정각 우리 S3 버킷에 CSV를 올려주고(push), 우리는 그걸 받아 DB에 쌓는다. S3가 중간에 끼는 구조다.

이 글은 Adjust 어트리뷰션 raw 데이터를 S3 경유로 받아 사내 BI 대시보드까지 잇는 파이프라인의 구축 기록이다. 전체 흐름과 함께, 실제로 시간을 잡아먹은 함정들 — IAM 키 역할 분리, ".csv.gz인데 평문", 헤더 중괄호, 업로더 키 AccessDenied — 과 멱등·소급 설계를 담았다. (식별자·수치는 예시다.)

그림 1. Adjust가 S3에 push, 배치가 pull. 업로더 키는 쓰기만, 리더 키는 읽기만.

핵심 설계 결정 하나 — Adjust 관련 전체(배치 + 대시보드)를 게임 서버와 분리한 독립 프로젝트로 만들었다. 왜 중요했는지는 아래에서 드러난다.

왜 pull이 아니라 "S3 push"인가

Adjust는 raw 데이터를 Cloud storage upload 기능으로 내보낸다. 우리가 API로 당기는 게 아니라, Adjust가 매시 정각 지정한 S3 버킷에 CSV를 던져넣는다. 파일명은 {app_token}_{날짜}T{시각}_{해시}_{seq}.csv.gz 형태. 이 push 모델의 장점은 Adjust API rate limit을 신경 쓸 필요가 없다는 것, 단점은 "S3에 뭐가 왔는지"를 우리가 관리해야 한다는 것(그래서 file_log 테이블이 필요하다).

함정 ① IAM 키를 "업로더"와 "리더"로 분리

S3를 사이에 둔 두 주체는 권한이 정반대다. Adjust는 쓰기만, 우리 배치는 읽기만 하면 된다. 그래서 IAM User를 둘로 나눴다 — 최소 권한 원칙.

IAM User	용도	핵심 권한
업로더	Adjust가 업로드	`s3:PutObject` (버킷 한정)
리더	우리 배치가 다운로드	`s3:GetObject` (버킷 한정)

겪은 함정 — 배치 config에 업로더 키를 넣었더니 GetObject AccessDenied. 업로더는 쓰기 전용이라 읽기가 안 된다. 배치에는 반드시 리더 키를 넣어야 한다. 외부에 넘기는 키가 새도 남의 파일을 못 읽고, 우리 배치 키가 새도 버킷에 못 쓴다 — 분리의 이점이다.

함정 ② ".csv.gz"인데 내용이 평문이다

배치가 gzip 해제를 하는데 어느 날 전량 SKIP됐다. 확장자는 .csv.gz인데 내용이 평문 CSV였다(데이터가 적을 때 압축 안 하고 올리는 경우). 해결은 확장자를 믿지 말고 gzip 매직넘버로 실제 압축 여부를 판별하는 것.

// 확장자(.gz)를 믿지 말고 파일 앞 2바이트로 gzip 여부 판별
$head = substr($content, 0, 2);
if ($head === "\x1f\x8b") {        // gzip 매직넘버 1f 8b
    $csv = gzdecode($content);     // 압축이면 해제
} else {
    $csv = $content;               // 평문이면 그대로
}

교훈은 분명하다. 파일 확장자는 "약속"일 뿐 "보장"이 아니다. 외부가 주는 파일은 확장자가 아니라 실제 바이트로 판별한다. 2바이트 체크 한 줄이 에러 폭탄을 막았다.

함정 ③ 헤더가 중괄호로 감싸져 있다

gzip을 풀고 파싱했더니 이번엔 모든 컬럼이 빈 값. 헤더가 {activity_kind},{created_at},...처럼 컬럼명이 중괄호로 감싸져 있었다(값엔 없음). activity_kind 키로 찾으면 실제 헤더 {activity_kind}와 안 맞아 전부 빈 값이 된 것.

// 헤더만 중괄호가 있으므로 헤더 파싱 시 제거
$header = array_map(function($h) {
    return trim($h, "{} \t\r\n");   // 양끝 중괄호+공백 제거
}, str_getcsv($headerLine));

추가로 반영한 Adjust CSV 특성:

시각이 유닉스 타임스탬프(초) — created_at=1792461704 형태. UTC로 변환해 저장.
environment — sandbox/production/빈값이 섞임. 실매출 집계는 production 기준만.
매체 전용 컬럼은 대부분 빈 값 — 매체 파트너(Google/Meta/TikTok) 연동 전이라 안 채워진다. 연동 후부터 채워지고 과거는 소급 불가(그래서 매체 연동은 빠를수록 좋다).

DB 설계 — raw + 집계 + file_log + app_map

10일차의 "raw + 집계" 패턴에 file_log(멱등)와 app_map(게임 구분)을 더했다.

테이블	역할
`raw`	CSV 1행=1레코드. 정규 컬럼 + 원본 JSON(소급용)
`dashboard`	일자×플랫폼×매체×국가×환경 집계(조회 전용)
`file_log`	처리한 S3 key + status. 멱등·중복방지
`app_map`	app_token→게임/플랫폼. 신규 게임은 2줄 추가

멱등 적재 — 같은 키를 DELETE 후 INSERT. 과거 파일을 재처리해도 중복이 안 쌓인다. file_log status='done'으로 미처리 파일만 집어간다.
소급 가능성 — S3 원본은 안 지운다(source of truth). raw에 원본 JSON을 보관해 나중에 "이 컬럼도 정규화"가 생기면 다시 뽑는다.
게임 자동 등장 — app_map에 app_token 2줄(AOS/iOS)만 넣으면 대시보드 필터에 자동으로 나타난다. 신규 게임 추가가 "코드 수정"이 아니라 "데이터 한 줄".

집계 정확도 — 가산 지표(설치·매출·결제 수)는 집계 테이블 SUM. 하지만 distinct 지표(DAU·결제자 수)는 집계를 SUM하면 차원 중복으로 과대 계산된다. 이건 raw에서 COUNT(DISTINCT adid)로 재집계해야 정확하다.

배치 & 대시보드

배치는 독립 PHP를 cron으로. UTC 기준(gmdate), DB NOW() 미사용. 미처리 파일만 처리하고 실패 파일은 error로 기록돼 다음에 재시도된다.

# UTC 21:00 = KST 06:00, 전날 올라온 파일 적재
0 21 * * * /path/to/php /path/to/adjust_daily.php >> /path/to/logs/adjust_daily.log 2>&1

겪은 함정 — cron은 돌았는데 데이터가 안 쌓였다. 로그 리다이렉트 경로의 logs 디렉토리가 없어서 cron이 공회전하고 있었다. 디렉토리를 먼저 만들어야 한다. "cron이 도는데 왜 결과가 없지?"로 한참 헤매게 만드는 전형적 함정.

대시보드는 순수 PHP + ECharts(CDN). 빌드 없이 기존 php-fpm 재사용. 접근은 사내 IP만 허용 + basic auth. 필터는 날짜 범위 / 게임(app_map 동적) / 플랫폼 / 환경(기본 production) / 국가 TopN, 지표는 설치·DAU·매출·플랫폼·국가 요약과 KPI 카드.

핵심 설계 — 독립 프로젝트로 분리한 이유

처음엔 Adjust 배치를 게임 서버 코드베이스 안에 뒀다. 그런데 게임 서버를 재배포할 때마다 Adjust용 config(S3 키 등)가 플레이스홀더로 덮여버리는 일이 생겼다. 배포 파이프라인이 config를 덮어쓴 것. 그래서 Adjust 전체를 독립 프로젝트로 분리했다.

게임 서버 재배포가 Adjust 쪽에 영향을 안 준다(config가 안 덮인다)
config는 gitignore로 서버에만, 샘플에는 플레이스홀더만
의존성(AWS SDK)도 이 프로젝트 composer로만 관리 → 게임 서버와 무관

한 번은 샘플 config에 실제 비밀번호가 치환돼 커밋될 뻔했다. HEAD로 복구하고 샘플엔 플레이스홀더만 유지하는 규칙을 세웠다. BI 파이프라인은 자격증명을 많이 다루므로 "실제 키는 gitignore config에만, 샘플엔 플레이스홀더만"을 처음부터 못 박는 게 안전하다.

겪은 함정 총정리

증상	원인	해결
gzip 전량 SKIP	.csv.gz인데 평문	매직넘버(1f8b) 판별
raw 전 컬럼 빈 값	헤더 `{컬럼}` 중괄호	헤더 파싱 시 중괄호 제거
cron 돌았는데 데이터 없음	로그 디렉토리 없음	logs 디렉토리 선생성
재배포 후 키가 덮임	게임 배포가 config 덮음	독립 프로젝트 + config gitignore
GetObject AccessDenied	배치에 업로더 키	리더 키로 교체

마치며

Adjust BI의 큰 틀은 10일차(AppsFlyer)와 같다 — 외부 어트리뷰션 데이터를 raw + 집계로 쌓고 대시보드로 본다. 다른 건 S3가 중간에 끼는 push 모델, 그래서 IAM 키를 업로더/리더로 나눠야 한다는 점이다.

실제로 발목을 잡은 건 큰 설계가 아니라 자잘한 형식 함정이었다. 확장자는 gz인데 평문, 헤더는 중괄호, 배치에 엉뚱한 키, 없는 로그 디렉토리. 외부가 주는 데이터는 "약속된 형식"을 믿지 말고 실제 바이트·실제 헤더로 확인해야 한다. 그리고 데이터 파이프라인은 자격증명을 많이 다루니, 처음부터 최소 권한 IAM 분리 + config gitignore + 독립 배포를 깔아두면 재배포·키 유출 사고에서 피해가 작다.

어트리뷰션 BI · 데이터 파이프라인 · S3/IAM 설계 문의

댓글로 편하게 남겨주세요.

EUR 결제 금액이 100배로 저장됐다 — 로케일 콤마(,) 소수점 함정과 데이터 보정

oldserver — Sun, 25 Oct 2026 10:24:27 +0900

TROUBLESHOOTING · 결제

EUR 결제 금액이 100배로 저장됐다

"22,99"가 2299로. 범인은 str_replace 한 줄과, 콤마를 소수점으로 쓰는 로케일이었다.

어느 날 매출 지표가 이상하게 튀었다. 특정 패키지 몇 건이 수천 달러로 집계된 것이다. 실제로 그렇게 팔렸을 리 없는 숫자. 추적해보니 EUR 결제 일부 건의 가격이 서버에 100배로 저장되고 있었다. 22.99가 2299로, 5.99가 599로.

이 글은 그 "가격 100배" 버그의 원인과 데이터 보정 과정이다. 범인은 결제 코드의 str_replace 한 줄이었고, 더 정확히는 소수점 구분자로 콤마를 쓰는 로케일이라는, 유럽·러시아 결제를 붙이면 반드시 만나는 함정이었다. (금액·건수는 예시다.)

그림 1. 같은 "콤마 제거" 코드가 점 로케일엔 무해하지만 콤마 로케일엔 100배 버그를 만든다.

현상 — 전부가 아니라 "일부만" 깨졌다

빌링 업데이트 이후부터 증상이 나타났다. 특징이 중요하다.

EUR 결제 일부 건만 100배: 22.99→2299, 5.99→599
전부가 아니라 일부라는 게 단서였다. 점(.)으로 온 건은 정상, 콤마(,)로 온 건만 깨졌다.
실제 결제·아이템 지급은 멀쩡. DB의 price 값과 매출 통계만 왜곡됐다.

"일부만 깨진다"는 건 거의 항상 입력 데이터의 형태가 둘 이상이라는 신호다. 여기선 그게 소수점 구분자(점 vs 콤마)였다.

원인 — 콤마를 "변환"이 아니라 "제거"

소수점 구분자로 콤마를 쓰는 로케일(독일·프랑스 등 유럽 다수)에서는 마켓이 가격을 "22,99"처럼 콤마로 내려준다. 영어권은 "22.99"로 점을 쓰고. 서버 코드는 가격에서 콤마를 제거하고 있었다.

// 콤마를 제거만 함 → "22,99" 가 "2299" 로 바뀐다
$price = !empty($row['price_str']) ? str_replace(',', '', $row['price_str']) : 0;
// 이후: UPDATE payment SET price = {$price} ...

str_replace(',', '')는 "천 단위 콤마 제거"를 의도한 코드였을 것이다(1,299 → 1299). 그런데 콤마가 천 단위 구분자가 아니라 소수점 구분자로도 쓰인다는 걸 놓쳤다. 같은 콤마 기호가 로케일에 따라 정반대 의미를 가진다.

수정 — 콤마를 소수점으로 정규화

핵심은 "콤마 무조건 제거"가 아니라 "이 콤마가 소수점인지 천 단위인지 판단"하는 것이다. 가장 단순한 규칙은 "문자열의 마지막 구분자(점이든 콤마든)를 소수점으로 본다"이다. 그 뒤 자릿수는 소수, 앞의 구분자는 전부 천 단위로 제거.

// "22,99"->22.99, "1,299.00"->1299.00, "1.299,00"->1299.00
$price = normalize_price_locale(trim($row['price_str']));
// 규칙: 마지막 구분자 = 소수점, 그 앞 구분자 = 천 단위(제거)

데이터 보정 — 조회 → 백업 → UPDATE

코드를 고쳐도 이미 100배로 저장된 과거 데이터는 그대로다. 실데이터 보정은 순서가 생명이다. ① 대상 조회 → ② 백업 → ③ UPDATE, 세 쿼리의 WHERE를 완전히 동일하게.

① 대상 조회 (UPDATE 전 반드시 확인)

SELECT idx, user_id, product_id, price, price/100 AS fixed_price, currency_code, reg_dttm
FROM payment
WHERE currency_code = 'EUR'
  AND status = 5
  AND reg_dttm >= '2026-10-22 00:00:00'
  AND price = FLOOR(price)      -- 소수점 없는 정수 = 콤마 제거로 깨진 건
ORDER BY reg_dttm DESC;

여기서 fixed_price가 전부 x.99 / x.49 같은 정상 가격으로 떨어지는지 눈으로 확인한다. 이게 보정의 안전장치다. 정상적으로 정수 가격인 EUR 상품이 섞여 있으면 그것도 1/100 되니, 조회 결과를 반드시 검토한다.

② 백업 (되돌릴 수 있게)

CREATE TABLE payment_bak_20261023 AS
SELECT * FROM payment
WHERE currency_code = 'EUR' AND status = 5
  AND reg_dttm >= '2026-10-22 00:00:00'
  AND price = FLOOR(price);

③ 보정 UPDATE (조회와 동일 조건)

UPDATE payment
SET price = price / 100
WHERE currency_code = 'EUR' AND status = 5
  AND reg_dttm >= '2026-10-22 00:00:00'
  AND price = FLOOR(price);

조회·백업·UPDATE의 WHERE 조건을 완전히 동일하게 두는 게 중요하다. 조회로 확인한 대상 = 백업한 대상 = 보정한 대상이 1:1로 맞아야 "본 것만 고쳤다"가 보장된다. 보정 후 매출 지표를 재집계해 숫자가 정상으로 돌아왔는지 확인한다.

짚고 갈 지점

price = FLOOR(price) 판별의 전제 — "정수면 깨진 것"이라는 가정이다. 정상 정수 가격 상품이 있으면 오판될 수 있으니 ①조회에서 fixed_price를 꼭 확인한다. 가정에 기대는 조건일수록 사람이 눈으로 검증한다.
시간 경계 — reg_dttm이 UTC/KST 무엇이든 그날 전체가 포함되게 00:00:00부터로 넉넉히. 경계에서 놓치는 것보다 범위를 넓게 잡고 조회로 거르는 게 안전.
영향 범위를 좁혔다 — 이 버그는 price와 통계만 왜곡했을 뿐 결제 승인·지급은 멀쩡했다. "price만, 통계만"이라고 선을 그어야 과잉 롤백을 안 한다.

마치며

교훈은 하나다. 같은 기호(콤마)가 로케일에 따라 정반대 의미를 가진다. 영어권에선 천 단위 구분자, 유럽 다수에선 소수점 구분자. "콤마 제거"라는 한 줄이 어떤 로케일에선 맞고 어떤 로케일에선 100배 버그가 된다.

통화·가격을 다룰 때는 문자열을 직접 자르지 말고 로케일을 의식해 정규화하거나, 처음부터 최소 단위 정수(센트)로 다루는 게 안전하다. 그리고 운영 데이터 보정은 언제나 조회 → 백업 → (동일 조건) UPDATE. 이 순서만 지키면 "본 것만 고친다"가 보장된다.

결제 연동 · 다국가 통화 · 운영 데이터 보정 문의

댓글로 편하게 남겨주세요.

PHP 긴급 취약점(PHP2Shell, CVE-2026-109618/109619) 운영 서버 대응기

oldserver — Sat, 24 Oct 2026 16:51:14 +0900

SECURITY · 긴급 대응

PHP 긴급 취약점(PHP2Shell) 운영 서버 대응기

어려웠던 건 취약점이 아니라 "서버마다 php.ini 경로와 FPM 서비스명이 제각각"이라는 운영 현실이었다.

PHP에서 치명적 보안 취약점 2건이 공개됐다. 통칭 PHP2Shell(CVE-2026-109618, CVE-2026-109619). 둘 다 인증받지 않은 외부 공격자의 원격 코드 실행(RCE)으로 이어질 수 있어 전 세계가 긴급 패치에 들어갔다. PHP로 웹 요청을 처리하는 거의 모든 구성(PHP-FPM, php-cgi, FrankenPHP, LiteSpeed)이 영향권이고, 특히 Apache mod_php가 위험하다고 알려졌다.

이 글은 운영 중인 여러 PHP 서버에 이 취약점을 대응한 실무 기록이다. 공격 방법이 아니라 우리 환경을 어떻게 점검하고 완화하고 패치했는지만 다룬다.

⚠️ 취약점 원인은 공개된 기술 분석·공식 공지 기반이며, 각 CVE의 정확한 조건은 공식 보안 업데이트 확인이 필요하다. 이 글은 공격 방법이 아니라 방어/대응 설정만 다룬다.

그림 1. 영향도 확인 → 경로·서비스 확인 → 완화(설정) → 패치(근본). 완화는 시간 벌기, 해결은 패치.

1. 공식 대응책 — 패치가 근본, 설정은 완화

조치	대상	성격
PHP 패치 버전으로 업데이트	둘 다	근본 해결
`session.upload_progress.enabled=Off` + 재시작	109619	임시 완화
`post_max_size` 축소 등	109618	임시 완화

패치 포함 버전: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35. (그 이하 EOL 버전은 공식 패치 없음) PHP 관리팀도 못 박았다 — 설정 변경만으로는 일부 공격 경로만 제한할 뿐 전체 안전을 보장하지 못한다. "완화책 = 시간 벌기, 해결 = 패치"다.

2. 영향도부터 — 끄면 뭐가 깨지나

설정을 끄기 전에 우리 코드가 그 기능에 의존하는지부터 확인했다.

코드가 session.upload_progress를 쓰는가? → 전 프로젝트에서 참조 0건. 꺼도 코드가 안 깨진다.
파일 업로드(multipart) 엔드포인트가 있는가? → 게임 클라이언트 API는 업로드 없음(공격자가 보낼 대상이 없음). 업로드는 사내 전용 어드민에만 있고 외부 비공개.

결론: 외부 공개 API는 공격 표면이 사실상 없고, 업로드받는 어드민은 사내 전용이라 외부 요청 자체가 안 온다. 어느 쪽도 session.upload_progress에 의존하지 않으니 꺼도 서비스 영향 없음 → 권고대로 비활성화.

3. 헷갈리기 쉬운 지점 — upload_progress는 "업로드 기능"이 아니다

설정	역할	끄면?
`file_uploads`	파일 업로드 허용	끄면 업로드 자체 안 됨
`session.upload_progress.enabled`	업로드 진행률을 세션에 기록	업로드 정상, 진행률 바만 사라짐

session.upload_progress는 PHP 기본값이 On이다("켠 적 없어도" 대부분 켜져 있음). 파일 업로드 기능과는 무관하고, 업로드 중 진행률을 $_SESSION에 기록해 진행률 바를 그리게 하는 부가 기능일 뿐이다. 그래서 Off 해도 $_FILES·move_uploaded_file() 같은 업로드 처리는 정상 동작한다.

4. 진짜 어려웠던 것 — 서버마다 환경이 다르다

작업 대상 서버들이 php.ini 경로·FPM 서비스명·PHP 버전이 제각각이었다. 추측하면 반드시 틀린다. 각 서버에서 먼저 확인하고 들어가야 한다.

# 실제 로드되는 php.ini 경로
php --ini | grep "Loaded Configuration"
# 멀티 PHP(Remi)면 버전 바이너리로
/opt/remi/phpXX/root/usr/bin/php --ini | grep "Loaded Configuration"

# FPM 서비스 실제 이름
systemctl list-units --type=service | grep -Ei 'fpm'

# PHP가 어떻게 도는지(fpm / mod_php / cgi)
ps aux | grep -E 'php-fpm|httpd|apache|nginx' | grep -v grep

실제로 겪은 함정 네 가지:

① 엉뚱한 php.ini를 고침 — /etc/php.ini를 고쳤는데 Remi PHP라 실제 로드 파일은 /etc/opt/remi/phpXX/php.ini. 파일은 바뀌었지만 런타임은 그대로 On.

② FPM 서비스명이 php-fpm이 아님 — Unit not found. 실제로는 php82-php-fpm, php72-php-fpm처럼 버전이 붙음.

③ php 명령이 PATH에 없음 — 멀티 PHP라 php82/전체 경로로 호출해야 함.

④ CLI와 FPM의 ini가 분리 — php -i가 On이어도 FPM은 Off일 수 있음(반대도). 웹이 실제 쓰는 값은 phpinfo()나 FPM 바이너리로 확인.

5. 적용 절차 — reload vs restart

session.upload_progress는 php.ini 값이라 FPM이 설정만 다시 읽으면(reload) 반영된다(무중단). 하지만 버전 업데이트(바이너리 교체)는 restart/재배포가 필요하다.

# 0) 경로·서비스·현재값 확인
php --ini | grep "Loaded Configuration"
systemctl list-units --type=service | grep -Ei 'fpm'
php -i | grep upload_progress.enabled        # 멀티PHP면 phpXX -i ...

# 1) 백업
sudo cp -a <ini경로> <ini경로>.bak.$(date +%Y%m%d)

# 2) On/주석 어느 쪽이든 Off로 치환 (그 한 줄만)
sudo sed -ri 's/^[[:space:]]*;?[[:space:]]*(session\.upload_progress\.enabled)[[:space:]]*=.*/\1 = Off/' <ini경로>

# 3) 파일 반영 확인
grep -n 'session.upload_progress.enabled' <ini경로>

# 4) 반영 (무중단 reload, 안 바뀌면 restart)
sudo systemctl reload <fpm-서비스명>

# 5) 런타임 최종값 확인 — Off => Off 면 완료
php -i | grep upload_progress.enabled

drop-in 대안 — php.ini 본문을 안 건드리고 /etc/php.d/99-disable-upload-progress.ini에 한 줄만 넣는 방법. 패키지 업데이트에도 보존되고 원복이 "파일 삭제"라 깔끔하다. 런타임 결과는 동일(나중에 로드되는 쪽이 이김).

6. 109618(요청 크기) 완화 — 서비스 특성을 보고

upload_progress Off는 109619만 막는다. 109618은 요청 크기 완화(post_max_size 축소) 또는 패치로 따로 대응해야 반쪽이 안 된다. 다만 서비스 특성을 봐야 한다.

어드민은 업로드가 실제 기능이라 post_max_size를 함부로 줄이면 업로드가 깨진다. 규칙은 post_max_size >= upload_max_filesize. 이미 작게 잡혀 있으면 유지하는 게 안전.
게임 API 서버는 큰 POST(배틀 결과, 직렬화 페이로드)가 있어, 줄이면 API가 깨질 수 있다 → 실제 최대 요청 크기 확인 후에만 조정.
memory_limit=-1(무제한)은 공식 완화책이지만 OOM 위험이 있어 운영/어드민엔 비권장. 임시·모니터링 동반 시에만.

7. 서버별로 갈린 결말 — 패치 가능 / EOL

서버(역할)	PHP	완화	패치
운영 API 서버 A	8.2.x	✅	8.2.35+로 패치 가능
개발 서버	8.2.x	✅	패치 가능(먼저 검증)
운영 API 서버 B(해외)	7.2	✅	EOL — 공식 패치 없음
운영 어드민(해외)	7.2	✅	EOL — 공식 패치 없음

8.2 서버: 8.2.20 → 8.2.35는 같은 마이너 안의 패치 업이라 호환성 깨짐(BC break) 걱정이 없다. 개발 서버에서 먼저 검증 후 운영 적용 → 두 CVE 근본 해결.
7.2(EOL) 서버: 공식 CVE 패치가 없다. 완화책 + 접근 통제(보안그룹/WAF)가 실질 방어. 중기적으로 버전 업 필수. "EOL 버전을 끌고 있으면 긴급 상황에서 선택지가 없다"를 다시 확인했다.

마치며

보안 공지는 "최신 버전으로 패치하세요" 한 줄이지만, 운영에서 시간을 잡아먹은 건 환경의 제각각임이었다. php.ini 경로가 서버마다 다르고(Remi면 /etc/opt/remi/phpXX/), FPM 서비스명에 버전이 붙고(php82-php-fpm), CLI와 FPM이 서로 다른 ini를 보기도 한다. 추측하지 말고 php --ini·systemctl list-units로 매번 확인하고 들어가는 것이 이번 대응의 핵심 교훈이었다.

그리고 둘을 다시 새겼다. 완화책은 시간 벌기, 해결은 패치(설정만 끄고 끝냈다 생각하면 109618과 EOL 서버가 그대로 남는다). 그리고 EOL 버전을 끌고 있으면 긴급 상황에서 선택지가 없다. 평소에 "우리가 PHP를 어디서 몇 버전으로 쓰는지" 목록을 유지하고, EOL 전에 올려두는 게 결국 가장 싼 보험이다.

참고: 이 글은 공식 보안 공지의 대응 수칙을 운영 관점에서 정리한 것이다. 실제 적용 시 서비스 호환성·안정성을 사전에 테스트하고, 최신 공식 공지의 안전 버전·권고를 따른다.

서버 보안 · PHP 운영 · 긴급 패치 대응 문의

댓글로 편하게 남겨주세요.

Unity 6 + AI(MCP)로 모바일 슈팅 게임 만들기 — 콤보·보스·오브젝트 풀링

oldserver — Wed, 21 Oct 2026 10:16:37 +0900

GAMEDEV · Unity + AI

Unity 6 + AI(MCP)로 슈팅 게임 한 편 만들기

콤보 배율, 봄, 단계별 보스, 오브젝트 풀링까지. AI에게 맡길 것과 사람이 잡아야 할 것의 선.

15일차에서 Unity 6 + AI(MCP) 환경을 붙이고 APK까지 뽑았다. 이번 16일차는 그 환경으로 실제로 게임 한 편을 만든 이야기다. 세로형 슈팅 게임인데, 단순 "적 쏘기"에서 멈추지 않고 콤보 배율, 봄(긴급회피), 단계별 보스, 아이템, 오브젝트 풀링까지 넣었다. 상당 부분을 AI 어시스턴트와 대화하며 만들었고, 그 과정에서 "AI에게 맡길 것 / 사람이 잡아야 할 것"의 선이 꽤 분명해졌다.

완성한 게임 — 세로형 슈팅

플레이어 기체가 아래에서 위로 적을 쏘는 고전적인 세로 슈팅이다. 여기에 핵심 재미 요소를 몇 개 얹었다.

플레이 화면 1

플레이 화면 보스

콤보 배율 — 적을 연속으로 잡으면 콤보가 쌓이고, 일정 콤보마다 점수 배율이 ×2 → ×3 → ×4 → ×5로 오른다. 약 2.2초 안에 다음 적을 못 잡으면 콤보가 끊긴다.
봄(긴급회피) — 위기 때 화면의 적 탄을 전부 지우고 모든 적에게 큰 데미지. 개수 제한이 있어 아껴 써야 한다.
단계별 보스 — 일정 점수마다 경고(WARNING) 후 보스 등장. 격파하면 다음 보스는 더 강해진다.
아이템 / 베스트 스코어 — 파워업·봄 아이템, 최고 점수는 PlayerPrefs로 저장돼 다음 판에도 남는다.

코드 구조 — 역할별로 쪼갠 스크립트

한 파일에 다 넣지 않고 역할별로 나눴다. AI와 작업할 때 이 분리가 특히 중요했다 — "GameController만 보고 콤보 로직 고쳐줘"처럼 범위를 좁혀 지시할 수 있기 때문이다. 중심은 GameController이고, 다른 스크립트가 static 메서드로 상태를 보고한다.

GameController 점수·콤보·봄·보스 상태 PlayerController 이동·발사 (New Input) Enemy / Spawner 적 생성·이동 Boss / EnemyBullet 단계별 보스·탄 ObjectPool 총알·폭발 재사용 연출 FX Explosion·Shake·Popup UIManager HUD (점수·콤보·목숨)

그림 2. GameController를 중심으로 한 모듈 구조 (총 20여 개 스크립트)

작은 게임에선 이렇게 중앙 상태(GameController의 static 필드)를 두고 GameController.EnemyKilled(pos) 식으로 보고하는 게 단순하고 빠르다.

핵심 ① 콤보 배율 — "재미"를 숫자로 설계

콤보는 카운트만 올리는 게 아니라 점수 배율로 연결해야 손맛이 난다. 처치할 때마다 콤보를 올리고, 구간별로 배율을 바꾼다.

void BumpCombo()
{
    Combo++;
    comboUntil = Time.time + comboWindow;   // 2.2초 안에 다음 처치해야 유지
    if (Combo >= 35) Multiplier = 5;
    else if (Combo >= 20) Multiplier = 4;
    else if (Combo >= 10) Multiplier = 3;
    else if (Combo >= 5)  Multiplier = 2;
    else Multiplier = 1;
}

public static void EnemyKilled(Vector3 pos)
{
    if (GameOver || Instance == null) return;
    Instance.BumpCombo();
    int gain = 1 * Multiplier;              // 배율 적용 점수
    Score += gain;
    ScorePopup.Spawn(pos, Multiplier > 1 ? ("+" + gain + " x" + Multiplier) : "+1");
}

설계 포인트는 피격 시 콤보 리셋이다. "안 맞고 연속으로 잡을수록 점수가 폭발한다"는 긴장감이 생긴다. AI에게 "콤보 유지 시간 지나면 리셋, 피격해도 리셋"을 말로 명확히 정의해주니 로직이 정확히 나왔다.

핵심 ② 오브젝트 풀링 — 모바일 성능의 핵심

슈팅 게임은 총알·폭발·적 탄이 초당 수십 개씩 생성·소멸한다. 매번 Instantiate/Destroy하면 GC가 몰려 폰에서 끊긴다. 그래서 미리 만들어두고 재사용하는 오브젝트 풀링이 사실상 필수다.

// 봄 발동 시: 적 탄을 "제거"가 아니라 "풀로 반환"
foreach (var eb in Object.FindObjectsByType<EnemyBullet>(FindObjectsSortMode.None))
    ObjectPool.ReturnObj(eb.gameObject);
// 폭발도 Destroy 대신 풀에서 꺼내 쓴다
ObjectPool.SpawnObj(explosionPrefab, pos, Quaternion.identity);

AI는 풀링 패턴 자체는 잘 짜준다. 다만 "이건 풀링으로, 저건 그냥 Destroy로"의 경계는 사람이 정해줘야 했다. 자주 생성되는 것(총알·폭발·적 탄)만 풀링하고, 가끔 나오는 보스·아이템은 일반 생성으로 둔 게 적절한 균형이었다.

핵심 ③ 입력 — 키보드 + 터치 동시 지원

15일차에서 데인 New Input System을 처음부터 적용했다. 그리고 키보드와 터치를 둘 다 받게 했다 — 에디터에선 키보드로 빠르게 테스트, 폰에선 터치로 플레이.

// 봄: B키(데스크톱) 또는 두 손가락 터치(모바일)
bool bombKey = Keyboard.current != null && Keyboard.current.bKey.wasPressedThisFrame;
bool bombTouch = Touchscreen.current != null && Touchscreen.current.touches.Count > 1
                 && Touchscreen.current.touches[1].press.wasPressedThisFrame;
if (!GameOver && (bombKey || bombTouch)) UseBomb();

Keyboard.current·Touchscreen.current가 null일 수 있으니 항상 null 체크를 넣는다. 그 입력 장치가 없는 환경에서 예외를 막기 위해서다. 이 체크를 빼먹으면 폰에서 키보드 참조로 죽거나 그 반대가 된다.

AI에게 뭘 맡기고, 뭘 직접 할까

AI가 잘하는 것

패턴이 분명한 코드 — 풀링, 콤보 구간 분기, static 상태
반복 작업 — 비슷한 적/탄 스크립트 여러 개
"이 함수 이렇게 바꿔줘" 식의 국소 수정

사람이 잡아야 할 것

재미 설계 — 콤보 유지 2.2초, 배율 구간(5/10/20/35)
경계 결정 — 뭘 풀링하고 뭘 static으로 둘지
최종 빌드·실기 테스트 (폰 플레이 느낌)

정리하면 AI는 "정해진 규칙을 코드로 옮기는 속도"를 압도적으로 높여줬고, 사람은 "무엇을 만들지, 어떤 느낌일지"를 정하는 데 집중했다. 콤보 배율 하나도 "35콤보에 ×5"라는 규칙만 주면 코드는 순식간에 나온다 — 그 규칙(=재미)을 정하는 게 사람 몫이었다.

마치며

AI(MCP)로 게임을 만든다고 하면 "AI가 다 만들어주겠네"로 들리지만, 실제로는 "사람이 재미를 설계하고, AI가 그걸 빠르게 코드로 구현"하는 협업에 가깝다. 콤보·봄·보스·풀링을 하루 만에 붙일 수 있었던 건 AI 덕이지만, "그 콤보가 2.2초인지 3초인지"는 결국 플레이해보며 사람이 판단했다.

15일차(환경·APK)와 16일차(게임 제작)를 묶으면, Unity 6 + AI로 아이디어에서 폰에 설치되는 게임까지 가는 한 사이클이 된다. 그 사이클이 생각보다 짧아졌다는 게 가장 큰 소득이었다.

Unity · AI 게임 개발(MCP) · 모바일 게임 문의

댓글로 편하게 남겨주세요.

Unity 6 공식 MCP로 AI(Kiro) 연동하고 Android APK까지 빌드하기

oldserver — Tue, 20 Oct 2026 10:45:12 +0900

GAMEDEV · Unity + AI

Unity 6 + AI(MCP)로 Android APK까지 빌드하기

씬 조작·스크립트는 AI에게, 최종 빌드는 사람이. 중간에 반드시 걸리는 함정 세 개를 넘은 기록.

오늘 Unity 6으로 간단한 모바일 게임을 만들어 Android APK까지 뽑았다. 특이한 건 씬 조작과 스크립트 작성을 상당 부분 AI 어시스턴트(Kiro)에게 시켰다는 점이다. Unity 6에는 공식 MCP(Model Context Protocol) Server 기능이 들어 있어서, 서드파티 플러그인 없이 AI를 Unity 에디터에 바로 붙일 수 있다.

이 글은 그 연동 설치부터 APK 빌드까지 전 과정이다. 중간에 반드시 걸리는 함정 세 개 — 에디터 버전(6000.3 미만이면 메뉴가 안 보임), New Input System, 그리고 MCP로는 APK 빌드가 끝까지 안 되는 문제 — 를 어떻게 넘겼는지까지 정리했다. (로컬 경로는 플레이스홀더다.)

연동 구조

먼저 그림부터. Unity 에디터가 "외부에 노출하는 MCP 서버"를 켜면, AI 클라이언트가 relay를 거쳐 거기에 붙는다. 에디터가 켜져 있어야 브리지가 돈다.

AI 클라이언트 mcp.json 설정 relay .unity/relay/ Unity 에디터 (켜져 있어야 함) Unity MCP Bridge (Start) 콘솔·스크립트·씬 도구

그림 1. AI 클라이언트 → relay → Unity 에디터의 MCP 브리지. 브리지는 에디터 안에서 돈다.

왜 Unity 공식 MCP인가

AI를 Unity에 붙이는 서드파티 방법은 예전부터 있었다(Python·uv 설치, 별도 브리지 등). 그런데 Unity 6부터는 공식 Assistant 패키지에 MCP Server가 내장됐다. 외부 런타임을 안 깔아도 되고, Unity가 직접 "에디터를 노출하는 MCP 서버"를 켜면 AI가 콘솔 읽기·C# 실행·씬 캡처 같은 도구를 바로 쓴다.

단, 에디터가 켜져 있어야 동작한다. 브리지가 에디터 안에서 돌기 때문에, 에디터를 닫으면 AI가 연결돼 보여도 명령이 안 먹는다.

함정 ① 에디터 버전 — 6000.3 미만이면 메뉴가 없다

제일 먼저 걸리는 지점이다. 공식 MCP 기능은 Unity 6.3(에디터 버전 6000.3) 이상에서만 나온다.

그냥 "Unity 6" = 6000.0을 깔면 MCP 메뉴 자체가 안 보인다. 버전 선택 때 반드시 6000.3 이상을 고른다.
6000.3(6.3 LTS), 6000.6(6.6) 등 6.3 이상이면 다 된다. 안정성을 원하면 LTS인 6.3이 낫다.
아직 Pre-release라 Package Manager에 Assistant가 안 보이면, Project Settings → Package Manager에서 Show Pre-Release Package Versions를 켠다.

Unity 6은 버전이 6000.x로 표기된다. "6"이 아니라 "6000"으로 보이는 게 정상이다. 이미 6000.0을 깔았어도 지울 필요 없이, Hub에서 6000.3 이상을 추가 설치하면 된다.

설치 흐름 — Hub → 에디터 → Assistant → MCP

1Unity Hub 설치 후 로그인 (개인/소규모는 Personal 무료)

2Hub → Installs → Unity 6.3 LTS 설치. 모바일이면 모듈에서 Android Build Support 체크

3프로젝트 생성 (3D 템플릿 무난), 에디터 버전이 6000.3 이상인지 확인

4Window → Package Manager → Unity Registry → Assistant 설치

5Project Settings → AI → Unity MCP → Bridge Start (권한 요청 허용)

헷갈리는 지점. 같은 AI 메뉴의 "MCP Client → MCP Servers"는 "Unity가 접속하러 가는 서버" 설정이다. 지금 쓰는 Unity MCP 페이지는 "Unity가 외부에 노출하는 서버"를 켜는 곳이다. 둘은 방향이 반대다.

AI 클라이언트 연결

Unity MCP 설정 페이지에서 Integrations → (클라이언트) → Configure를 누르면, 하단에 OS별 설정 파일 경로와 붙여넣을 JSON 블록이 표시된다.

{
  "mcpServers": {
    "unity": {
      "command": "<Unity 화면에 표시된 relay 실행 경로>",
      "args": ["<Unity 화면에 표시된 인자들>"],
      "disabled": false,
      "autoApprove": []
    }
  }
}

이 JSON을 AI 클라이언트의 mcp.json에 붙여넣는다. 전역이면 C:\Users\<사용자명>\.kiro\settings\mcp.json, 프로젝트 한정이면 워크스페이스의 .kiro/settings/mcp.json.

경로를 추측하지 않는다. command·args·relay 경로는 Unity 화면에 뜬 값을 그대로 복사한다. 버전마다 달라서 손으로 지어내면 relay를 못 찾아 연결이 실패한다. 그리고 "disabled": false인지 꼭 확인한다(일부 안내가 true로 쓰라는데, 실제로 쓰려면 false다).

연결되면 AI 쪽 MCP 패널에 unity Connected (N tools)로 뜬다. 가장 안전한 첫 테스트는 "현재 콘솔 로그 읽어줘" — 로그가 돌아오면 정상이다. 그다음 "원점에 큐브 만들고 Rigidbody 붙여줘" 같은 씬 조작을 시켜볼 수 있다.

함정 ② New Input System — 구형 Input API가 안 먹는다

Unity 6 신규 프로젝트는 기본이 New Input System 전용이다. 이 상태에서 구형 Input.GetKey() / Input.GetAxisRaw()는 동작하지 않는다. AI가 생성한 예제가 구형 입력을 쓰면 이동·발사가 전부 안 먹는 현상이 난다.

정석: 처음부터 New Input System API로 쓴다. Keyboard.current.spaceKey.isPressed 식, using UnityEngine.InputSystem; 추가.
비권장 대안: Player → Active Input Handling을 Both로 바꾸는 방법도 있으나, Both로 바꿔도 런타임에서 구형 Input이 안 먹는 경우가 있었다(재시작 후에도). New API로 바꾸자 즉시 정상. Both에 기대지 말 것.
디버깅 팁: 입력이 안 먹으면 매 프레임 입력값을 Debug.Log로 찍는 프로브를 붙여 확인. 그리고 키 입력은 Game 뷰에 포커스(화면 클릭)가 있어야 들어온다.

함정 ③ MCP로는 APK 빌드가 끝까지 안 된다

오늘의 핵심 교훈이다. 씬 조작·스크립트 작성은 MCP(AI)로 잘 됐는데, Android APK 빌드만은 MCP로 끝까지 안 됐다.

User interactions are not supported for MCP tool calls

BuildPipeline.BuildPlayer가 내부적으로 상호작용(SDK 라이선스 동의 등)을 요구하는데, MCP 도구 호출은 그런 대화형 입력을 지원하지 않아 막힌다. 모듈·설정이 전부 정상이어도 마찬가지다.

해결 — 빌드는 에디터에서 직접 한다. AI는 준비(스크립트·씬·설정)까지만 맡고, 최종 빌드 버튼은 사람이 누른다.

모듈 추가: Hub → Installs → 버전 ⚙ → Add Modules에서 Android Build Support + OpenJDK + Android SDK & NDK Tools 추가.
모듈 추가 후 에디터 재시작 필수: "No Android module loaded. Editor will need to be restarted" 경고가 뜬다. 껐다 켜야 Android 빌드가 활성화된다.
SDK/NDK/JDK 임베디드: 경로가 비면 Edit → Preferences → External Tools에서 Hub 동봉(embedded)으로 체크.
빌드 실행: File → Build Settings/Build Profiles → Android 선택 → Build → 출력 경로 지정. 처음엔 Gradle 다운로드로 수 분, SDK 라이선스 창이 뜨면 Accept.

이렇게 에디터에서 직접 빌드하니 APK가 정상적으로 떨어졌다.

모바일 입력 — 키보드 스크립트는 폰에서 안 돈다

APK를 폰에 올리기 전에 하나 더. 데스크톱에서 키보드로 테스트한 스크립트는 폰에서 그대로는 동작하지 않는다. 터치 입력을 따로 넣어야 한다. Touchscreen.current.primaryTouch로 터치(드래그 이동 + 자동 발사 등)를 처리하고, 화면 방향은 PlayerSettings.defaultInterfaceOrientation으로 고정한다.

보너스 — MCP로 씬 편집할 때 Play 모드 함정

MCP로 씬을 편집할 때 Play 모드 중에 가한 변경은 Play를 멈추면 전부 되돌아간다(오브젝트 생성, 컴포넌트 연결, 스프라이트 교체 등).

씬 편집은 반드시 에디트 모드(EditorApplication.isPlaying == false)에서 하고 EditorSceneManager.SaveOpenScenes()로 저장.
Play 모드에서는 저장 API가 예외나 "User interactions are not supported" 오류를 낸다. MCP 명령 전에 isPlaying을 먼저 로그로 확인하면 헛작업을 막는다.
스크립트 교체 직후엔 Unity가 재컴파일하느라 MCP 연결이 잠깐 끊긴다("Unity not detected"). 잠시 후 재시도하면 복구된다.

마치며

Unity 6의 공식 MCP는 "AI가 에디터를 직접 조작"하는 걸 플러그인 없이 가능하게 해준다. 콘솔 읽기·스크립트 작성·씬 구성까지는 AI에게 맡기고, 대화형 승인이 필요한 작업(APK 빌드의 SDK 라이선스 등)은 MCP로는 못 넘어가니 사람이 마무리한다. 이 경계만 이해하면 "AI가 밑작업, 사람이 최종 빌드"라는 분담이 꽤 자연스럽다.

가장 많이 데인 셋을 다시 정리하면 — 버전은 6000.3 이상(아니면 MCP 메뉴가 아예 없음), 입력은 New Input System으로(Both는 못 믿음), 빌드는 에디터에서 직접(MCP는 상호작용 못 함). 이 세 가지만 미리 알면 Unity 6 + AI로 APK까지 가는 길이 훨씬 매끄럽다.

Unity · AI 코딩(MCP) · 모바일 빌드 문의

댓글로 편하게 남겨주세요.

AWS 비용 절감 실행: 롤백 가능/불가 구분하고 예약 인스턴스는 맨 마지막에

oldserver — Mon, 19 Oct 2026 11:34:51 +0900

INFRA · 비용 최적화

AWS 비용 다이어트, 계획을 실제로 적용하기

Aurora 7대 → 5대. 삭제 순서, 되돌릴 수 있는 것과 없는 것, 그리고 예약 인스턴스를 맨 마지막에 사는 이유.

7일차에서 "AWS 청구서는 큰데 CPU는 놀고 있다"는 데이터를 근거로 다운사이징 계획을 세웠다. 이번 글은 그 계획을 실제 점검(서비스 차단) 중에 적용한 확정·실행편이다. 계획 글은 많지만, 막상 어떤 순서로, 어디까지 되돌릴 수 있게, 다운타임은 얼마나 잡고 실행하는지는 잘 안 다뤄진다. 그 실무 부분을 정리했다.

요지는 셋이다. 삭제는 순서가 중요하다(되돌릴 수 없으니까). 타입 변경과 삭제는 리스크가 다르다(전자는 롤백 가능, 후자는 영구). 예약 인스턴스(RI)는 맨 마지막에 산다. (모든 비용·수치는 더미 예시다.)

확정안 — 계획에서 "실제 적용값"으로

분석(어느 게 과잉인가)과 확정(그래서 뭘로 바꾸나)은 다르다. 특히 가격 역전 때문에 "최신 세대로 바꾸면 무조건 싸다"가 안 통하는 경우가 있었다.

RDS: 7대 → 5대

인스턴스	현재(예시)	변경
share(메인)	r계열 xlarge(32GB)	r계열 large(16GB)
game writer ×2	r계열 large	유지 (가격 역전)
game reader ×2	r계열 large	삭제 (HA 포기)
log ×2	r계열 large	버스터블 large(8GB)

함정 — 가격 역전. game writer를 더 최신 세대로 바꾸려 했는데, 해당 리전·시점에선 오히려 더 비쌌다. 세대가 올라간다고 항상 싸지는 게 아니라 리전별 실단가를 그때그때 확인해야 한다. 그래서 writer는 세대 교체 없이 유지하는 게 더 쌌다.

Redis / EC2

대상	현재(예시)	변경
Redis 메인	m계열 large	버스터블 t계열 medium
API 서버 ×2	연산최적 large	버스터블 t계열 medium
API 서버 ×1	연산최적 large	삭제
채팅 서버 ×1	버스터블 medium	삭제

API 서버를 메모리 4GB로 내리면 php-fpm의 pm.max_children를 함께 조정해야 피크 때 메모리가 안 터진다. 안전을 더 사고 싶으면 8GB로 두는 선택지도 있다 — 월 몇 달러 차이. "비용 최소"와 "여유" 사이의 트레이드오프를 의식적으로 고른다.

실행 순서 — 삭제는 순서가 생명

점검(서비스 차단) 중 아래 순서로 진행했다. 순서를 정한 이유는 전부 "되돌릴 수 없는 작업을 안전한 뒤에 두기"다.

1game writer 상태 확인 → 그다음 reader 삭제

2log ×2 → 버스터블로 타입 변경

3share → 한 단계 아래로 타입 변경

4Redis → 한 단계 아래로 타입 변경

5API 서버 2대 → 버스터블 변경, 나머지 1대 + 채팅 1대 삭제

6서비스 재개 → 24~48시간 지표 관찰 → RI 구매(마지막)

왜 reader를 먼저 안 지우고 writer 확인부터 하냐면 — reader는 writer 장애 시 자동 페일오버(HA) 대상이다. writer가 멀쩡한지 확인하기 전에 reader를 지우면, 그 사이 writer에 문제가 생겼을 때 받아줄 대상이 없다. 그래서 "writer 정상 확인 → reader 삭제" 순서가 안전하다.

reader 삭제는 곧 HA 포기다. 장애 시 복구가 1분에서 수 분으로 길어지는 것을 감수한다는 합의가 전제여야 한다.

되돌릴 수 있는 것 / 없는 것

실행 전에 이 구분을 명확히 하고 들어간다. 이게 "과감하게 줄이되 안전하게"의 핵심이다.

작업	롤백	안전장치
타입 변경(RDS/Redis/EC2)	상위 타입으로 즉시 복구, 데이터 유지	지표 이상 시 바로 원복
삭제(terminate)	복구 불가	삭제 전 ELB 제외·cron 확인·스냅샷

타입 변경은 마음 편히 한다 — 지표가 나빠지면 되돌리면 된다. 삭제만 신중하게 한다.

삭제 전 체크리스트는 세 가지다.

ELB 타겟에서 제외됐는지
그 인스턴스에만 걸린 cron/배치가 있는지
스냅샷은 떠뒀는지

불안하면 바로 terminate하지 말고 1~2주 정지(stop)로 운영해 본 뒤 삭제하는 방법도 있다. 정지 상태는 컴퓨팅 비용이 안 나가니, 비용은 거의 줄이면서 "진짜 안 써도 되는지"를 안전하게 확인할 수 있다.

예약 인스턴스(RI)는 맨 마지막

RI나 Savings Plan은 1년 약정으로 20% 이상을 더 깎아주지만, 반드시 다운사이징·안정화가 끝난 뒤 산다. 먼저 사면 그 타입에 묶여서, 나중에 더 줄이고 싶어도 약정 때문에 못 바꾼다.

그래서 순서가 "타입 확정 → 24~48시간 관찰 → 이상 없으면 그 최종 타입 기준으로 RI/SP 구매"다. 관찰 때 보는 지표는 CPU, FreeableMemory, ReadIOPS, Evictions. 메모리 급락·ReadIOPS 급증·Evictions 발생은 "너무 줄였다"는 신호라 상위 타입으로 되돌린다. 그 신호가 없을 때만 RI를 건다.

점검 운영 — 공지는 넉넉히, 작업은 짧게

공지 다운타임은 실제 작업 시간보다 넉넉히 잡는다. 실작업은 60~90분이어도, 공지는 검증·롤백 버퍼까지 포함해 몇 시간으로 잡았다. 작업이 예정대로 끝나면 일찍 열면 되지만, 문제가 생겼을 때 롤백할 시간이 공지 안에 들어있어야 하기 때문이다. "딱 맞게" 공지하면 롤백 중에 다운타임을 초과한다. 그리고 트래픽이 가장 적은 시간대(새벽 등)에 잡아 영향을 최소화한다.

결과 — 1차로 약 1/3, RI까지 가면 더

단계	월 비용(예시)	절감률
현재	~$5,000	-
타입 변경 + 삭제	~$3,300	~33%
+ RI 1년	~$3,000	~40%

1차(다운사이징·삭제)만으로 약 33%가 줄고, 안정화 후 RI까지 적용하면 40% 선이다. 더 내리려면 2차로 기타 비용을 정리한다 — 미사용 EBS/스냅샷/EIP, CloudWatch 로그 보존기간, NAT Gateway 구성, 상시 안 쓰는 dev 서버 정지. 1차가 "큰 덩어리(컴퓨팅)"였다면 2차는 "자잘하지만 쌓이면 큰 것들"이다.

마치며

7일차가 "줄일 수 있다는 근거"였다면, 이번은 "실제로 줄이는 법"이었다. 실행에서 중요한 건 절감액 자체보다 순서와 되돌림이다. 되돌릴 수 있는 것(타입 변경)은 과감하게, 되돌릴 수 없는 것(삭제·RI)은 뒤로 미루고 신중하게. 세대가 올라간다고 항상 싸지 않다는 것(가격 역전)도 실단가로 확인한다.

트래픽을 포기한 게 아니라 "안 쓰던 여유분"을 걷어낸 것이라 서비스 체감은 그대로다. "청구서는 큰데 CPU는 노는" 서버를 운영하면서 손대기가 겁나는 분께, 순서만 지키면 생각보다 안전하다는 이야기로 도움이 되면 좋겠다.

AWS 비용 최적화 · 다운사이징 · 인프라 운영 문의

댓글로 편하게 남겨주세요.

Rocky Linux에 PHP 8.5 + MySQL 8.4 LTS 설치하기

oldserver — Sun, 18 Oct 2026 11:31:45 +0900

INFRA · 서버 구축

Rocky Linux에 PHP 8.5 + MySQL 8.4 LTS 설치하기

데이터는 전부 /data 디스크에. 중간에 반드시 만나는 두 에러(GPG check FAILED, socket 불일치)까지 함께 정리했다.

게임 서버를 새로 올릴 때, OS에 PHP·MySQL을 어떤 버전으로 어떻게 설치하느냐가 이후 운영을 한참 좌우한다. 이번엔 Rocky Linux 10에 PHP 8.5(Remi) + MySQL 8.4 LTS를, 데이터는 전부 데이터 디스크(/data)에 두는 구성으로 세팅했다. 이 서버 하나를 이미지로 떠서 라이브 API·DB 서버를 찍어낼 베이스가 되므로, 처음에 깔끔하게 잡아두는 게 중요하다.

이 글은 그 설치 전 과정을 순서대로 정리한다. SELinux 방침, Remi로 PHP 8.5 올리기, MySQL 8.4의 datadir을 /data로 옮기기, 그리고 중간에 반드시 만나는 두 에러 — GPG check FAILED(키 만료)와 Can't connect through socket — 를 어떻게 넘겼는지까지. (모든 경로·주소는 예시다.)

데이터 레이아웃

먼저 구조부터. 소스·DB 데이터는 OS 디스크가 아니라 데이터 디스크(/data)에 두고, 접근은 홈 아래 심볼릭 링크로 한다. OS와 데이터를 분리해 두면 디스크 확장·이미지 복제가 깔끔하다.

그림 1. 홈 경로는 심볼릭 링크일 뿐, 소스·DB의 실제 저장은 데이터 디스크(/data)에 있다.

버전 선택 — 왜 PHP 8.5 / MySQL 8.4 LTS

PHP 8.5 — 기존 운영이 8.4였고 한 세대 올렸다. 8.4 → 8.5는 deprecated·동작 변경이 있을 수 있어, 이 베이스 서버에서 소스 구동 검증을 전제로 올린다(실패 시 Remi 모듈을 8.4로 내릴 수 있게).
MySQL 8.4 LTS — 8.0은 2026년 EOL이라 쓰면 안 된다. 8.4는 LTS라 다음 베이스로 적합하다. "지금 최신"보다 "오래 지원되는 LTS"가 서버 수명 관점에서 유리하다.

STEP 0. SELinux — 방침부터 정하고 간다

프로젝트 전 서버에서 SELinux를 Off로 통일했다. MySQL datadir을 /data로 옮길 때 SELinux가 켜져 있으면 컨텍스트 작업(semanage/restorecon)이 필요하고, 깜빡하면 기동이 실패한다. Off로 두면 그 변수를 없애 세팅이 단순해진다.

getenforce                                           # 현재 상태
sudo sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
sudo setenforce 0                                    # 재부팅 전까지 Permissive

완전한 Disabled는 재부팅 후 반영된다. SELinux Off는 커널 레벨 접근제어를 끄는 것이므로 보안그룹(방화벽)과 SSH 접근제어로 보완하는 전제에서만 택한다.

STEP 0-1. 호스트명 + 데이터 디렉토리

콘솔에서 만들면 호스트명이 VM-0-11-rockylinux 같은 식이라 서버 구분이 안 된다. 식별 가능한 이름으로 바꾸고, 소스는 /data에 두되 접근은 홈 아래 심볼릭 링크로 하는 구조를 잡는다(그림 1).

# 호스트명 (소문자 권장)
sudo hostnamectl set-hostname myapp-dev-01
exec bash

# 소스는 /data에 실제 저장, /home 아래에서 심볼릭 링크로 접근
sudo mkdir -p /data/myapp_dev/server_root
sudo mkdir -p /home/appsvr/myapp_dev
sudo ln -s /data/myapp_dev/server_root /home/appsvr/myapp_dev/server_root

STEP 1. 레포 추가 (EPEL + Remi)

PHP 최신 버전은 OS 기본 레포에 없으니 Remi를 쓴다.

sudo dnf -y update
sudo dnf -y install dnf-utils epel-release
sudo dnf -y install https://rpms.remirepo.net/enterprise/remi-release-10.rpm

remi-release-10.rpm은 Rocky 10(el10)용이다. OS 버전과 레포 버전(el8/el9/el10)을 꼭 맞춰야 한다. el10 패키지가 아직 없으면 Remi 사이트에서 최신 경로를 확인한다.

STEP 2. PHP 8.5 설치

Remi 모듈을 리셋하고 8.5를 활성화한 뒤, 기존 서버와 동일한 확장 세트를 깐다.

sudo dnf -y module reset php
sudo dnf -y module enable php:remi-8.5

sudo dnf -y install \
  php php-cli php-fpm php-common \
  php-mysqlnd php-pdo \
  php-mbstring php-xml php-gd php-gmp php-sodium php-bz2 \
  php-opcache php-pecl-msgpack php-pecl-redis6 php-pecl-igbinary \
  php-process php-sqlite3

# 개발 서버에만 Xdebug (운영 서버엔 금지 — 성능 저하)
sudo dnf -y install php-pecl-xdebug3

php -v    # 8.5.x
php -m    # 확장 목록을 기존 서버와 비교

실제로 PHP 8.5.x에 msgpack·redis·igbinary·mysqli·mbstring·sodium·gd·gmp·openssl 등 기존 8.4 구성이 전부 로드됐다. 설치 직후 php -m을 기존 서버와 비교하는 습관이 중요하다. 확장 하나가 빠지면 소스가 특정 기능에서만 조용히 죽는다. el10에서 패키지명이 다르면("No match") dnf search php-pecl-redis로 실제 이름을 확인한다.

STEP 3. MySQL 8.4 설치 — 첫 번째 에러 (GPG check FAILED)

MySQL 공식 레포를 추가하고 설치한다. el10 패키지가 없으면 el9로 받아도 호환된다.

sudo dnf -y install https://dev.mysql.com/get/mysql84-community-release-el9-1.noarch.rpm
sudo dnf -y install mysql-community-server

여기서 바로 막힌다.

Certificate B7B3B788A8D3785C ... Expired on 2025-10-22
GPG check FAILED

원인 — MySQL 서명 키가 2025-10-22에 만료됐고, 패키지 자체가 그 만료된 키로 서명돼 있다. 그래서 키를 최신으로 갱신해도(키서버 재수신, /etc/pki/rpm-gpg 키 파일 교체) 서명 검증이 통과되지 않는다. 구키 import, gpg --recv-keys, 키링 교체까지 다 시도했지만 "Expired"가 계속 떴다. 사용자 측에서 키로는 못 푸는, Oracle 쪽 서명 이슈다.

해결 — 공식 레포에서 받는 패키지가 맞으므로, 이번 설치 한 번만 서명 검증을 생략한다. 레포 전체를 gpgcheck=0으로 끄는 것보다 1회성이 안전하다.

sudo dnf -y install mysql-community-server --nogpgcheck
mysql --version    # 8.4.x

STEP 4. datadir을 /data로 — 두 번째 에러 (socket)

MySQL 데이터를 데이터 디스크(/data/mysql)에 두려 한다. 핵심은 최초 기동 전에 바꾸는 것이다. 이미 /var/lib/mysql로 초기화된 뒤면 서비스를 멈추고 데이터를 옮겨야 해서 번거롭다.

sudo mkdir -p /data/mysql
sudo chown -R mysql:mysql /data/mysql
sudo chmod 750 /data/mysql
sudo vi /etc/my.cnf

[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

# ↓ 이 [client] 섹션이 핵심 — 없으면 socket 에러가 난다
[client]
socket=/data/mysql/mysql.sock

기동 후 보안 설정을 하려는데 두 번째 에러가 난다.

sudo mysql_secure_installation
→ Can't connect through socket '/var/lib/mysql/mysql.sock'

원인 — 서버는 socket을 /data/mysql/mysql.sock에 만들었는데([mysqld] 설정), 클라이언트는 기본값 /var/lib/mysql/mysql.sock을 찾는다. 서버와 클라이언트가 서로 다른 소켓 경로를 보고 있는 것이다.

해결 — /etc/my.cnf에 [client] 섹션으로 소켓 경로를 명시한다(위 설정에 이미 포함). 서버 재시작도 필요 없이, 추가하자마자 다시 하면 된다.

sudo grep 'temporary password' /var/log/mysqld.log   # 임시 root 비번
sudo mysql_secure_installation                        # 익명계정/원격root/testDB 제거
mysql -u root -p -e "SELECT @@datadir, @@socket, VERSION();"
#   → /data/mysql/ , /data/mysql/mysql.sock , 8.4.x

SELinux를 STEP 0에서 꺼둔 덕에 /data/mysql 접근에 semanage/restorecon이 필요 없었다. 켜져 있었다면 여기서 datadir 접근 거부로 기동이 실패했을 것이다.

STEP 5. Nginx + SSL (개발은 Nginx가 직접 SSL 종료)

웹서버는 Nginx, php-fpm과는 유닉스 소켓으로 연결한다. 개발 서버는 앞단에 로드밸런서가 없으니 Nginx가 직접 SSL을 종료한다(와일드카드 정식 인증서).

server {
    listen 7222 ssl;
    server_name _;
    root /home/appsvr/myapp_dev/server_root;

    ssl_certificate     /etc/nginx/ssl/example.crt.pem;
    ssl_certificate_key /etc/nginx/ssl/example.key.pem;
    ssl_protocols TLSv1.2;

    index index.php;
    location / { try_files $uri $uri/ /index.php?$query_string; }
    location ~ \.php$ {
        fastcgi_pass unix:/run/php-fpm/www.sock;   # php-fpm listen과 짝 맞추기
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
    location ~ /\.ht { deny all; }
}

fastcgi_pass는 php-fpm의 listen 설정과 반드시 짝이 맞아야 한다(여기선 둘 다 소켓). 소켓/TCP가 어긋나면 502가 난다.

개발 vs 라이브 — SSL 종료 지점이 다르다. 개발 서버는 Nginx가 직접 SSL(listen 7222 ssl), 라이브는 CLB가 SSL을 종료하고 API 서버 Nginx는 평문으로 받는다. 같은 코드베이스라도 "SSL을 어디서 끊느냐"가 환경마다 다르다는 걸 처음부터 설계에 반영해 둔다.

STEP 6. 호환 검증 — 이 서버의 진짜 목적

이 베이스 서버의 목적은 설치 자체가 아니라 "PHP 8.5 + MySQL 8.4에서 기존 게임 소스가 그대로 도느냐"를 검증하는 것이다.

PHP 확장 전부 로드(php -m을 기존 서버와 대조)
MySQL 8.4 접속·datadir·socket 확인
Nginx + SSL + php-fpm(sock) 연동 → 실제 HTTPS 응답 확인
PHP 8.5에서 소스 구동 — deprecated/변경점(예: settype 사용부, mcrypt 제거 등) 점검 ← 가장 중요
AES-256-CBC 등 암호화 로직이 OpenSSL 3.x에서 정상 동작하는지

검증 실패 시 되돌릴 길을 미리 둔다. PHP는 Remi 모듈을 php:remi-8.4로 내리고, 그래도 안 되면 OS를 재설치하되 데이터 디스크(/data)는 보존한다. "앞으로 못 돌아가는 설치"는 베이스 서버에선 피한다.

마치며

설치 글은 명령어 나열이 되기 쉽지만, 실제로 시간을 잡아먹는 건 늘 두세 개의 함정이다. 이번엔 그게 MySQL GPG 키 만료(GPG check FAILED)와 datadir 변경 후 socket 불일치였다. 둘 다 "원래 그런 것"이 아니라 원인이 분명하다 — 전자는 패키지가 만료 키로 서명된 것(1회 --nogpgcheck), 후자는 서버/클라이언트 소켓 경로 불일치([client] 섹션 추가).

베이스 서버를 만들 땐 버전은 LTS로, 데이터는 분리 디스크로, 되돌릴 길은 남겨두고 간다. 이 세 가지가 이후 라이브 서버를 이미지로 찍어낼 때 그대로 자산이 된다.

Rocky Linux · PHP/MySQL 서버 구축 · 인프라 문의

댓글로 편하게 남겨주세요.

AWS Bedrock 모델 단종(EOL) 트러블슈팅 + 폴백 모델 + IAM 설정

oldserver — Fri, 16 Oct 2026 10:55:30 +0900

OPERATION · AI 운영

"모델이 수명을 다했다" — Bedrock EOL을 Converse로 복구하기

알람 메일의 AI 분석이 "This model version has reached the end of its life"로 멈췄다. 특정 모델에 안 묶이는 구조로 다시 짠 복구기.

11일차에서 CloudWatch 알람에 AI 분석을 붙였다. 에러가 터지면 Lambda가 로그를 긁어 Bedrock의 Claude에게 원인·영향·조치·심각도를 분석시켜 메일로 보내는 구조였다. 그런데 얼마 뒤 " AI 분석 결과" 칸에 이런 문구가 찍히기 시작했다.

(AI 분석 실패: This model version has reached the end of its life.)

이번 글은 그 "모델이 수명을 다했다(EOL)" 에러를 추적하고, 특정 모델에 묶이지 않는 구조로 다시 짠 실전 복구기다. 핵심은 Bedrock의 InvokeModel에서 Converse API로 전환해서, 앞으로 모델이 또 단종돼도 환경변수만 바꾸면 되게 만든 것이다. (모든 식별자·ARN은 예시다.)

전체 구성

먼저 전체 그림이다. 에러가 임계값을 넘으면 알람이 Lambda를 깨우고, Lambda가 로그를 조회해 Bedrock으로 분석한 뒤, 그 결과를 메일로 다시 보낸다. 이번에 고친 부분은 그림의 Bedrock 호출(Converse + 주/폴백 모델)이다.

그림 1. 알람 → Lambda(Logs Insights 조회 + Bedrock 분석) → SNS 재발행 → 메일. 보라색 블록이 이번에 고친 Bedrock 호출부.

증상 — 알람은 오는데 AI 분석만 실패

알람 자체(에러 임계값 초과 메일)는 정상이었다. 로그도 잘 붙어 왔다. 딱 하나, AI 분석 칸만 매번 실패로 떴다. Lambda 로그를 보니 Bedrock 호출에서 예외가 나고 있었고, 메시지는 아주 명확했다 — "이 모델 버전은 수명을 다했다."

원인 — Bedrock 모델이 EOL(단종)됨

11일차에서 쓴 모델은 anthropic.claude-3-haiku-20240307-v1:0이었다. 그런데 AWS Bedrock이 이 특정 모델 버전을 EOL 처리하면서 InvokeModel 호출이 더 이상 안 먹혔다. 여기서 두 가지 교훈이 나온다.

클라우드 AI 모델은 버전이 단종된다. 특정 모델 ID를 코드에 박아두면 그 모델이 사라지는 순간 기능이 죽는다. 모델은 "상수"가 아니라 "언젠가 바뀌는 값"이다.
AI 분석은 부가 기능인데 조용히 실패하고 있었다. 알람 메일은 왔으니 아무도 몰랐다. 부가 기능일수록 "실패해도 본체는 살아있게" + "실패를 눈에 띄게"가 중요하다.

해결 ① InvokeModel → Converse API로 전환

가장 중요한 결정이다. 기존 InvokeModel은 모델마다 요청/응답 body 포맷이 다르다. Anthropic은 anthropic_version·messages 구조를 쓰고 다른 벤더는 또 다른 포맷을 쓴다. 그래서 모델을 바꾸면 코드도 같이 바꿔야 했다.

Bedrock의 Converse API는 이 포맷 차이를 흡수한다. 어떤 모델이든 동일한 messages / content 구조로 호출된다. 즉 모델 교체가 코드 변경 없이 "모델 ID만 교체"로 끝난다.

import { BedrockRuntimeClient, ConverseCommand } from '@aws-sdk/client-bedrock-runtime';
const bedrockClient = new BedrockRuntimeClient({});

async function invokeConverse(modelId, logContent) {
  const prompt = `당신은 PHP 게임 서버 운영 전문가입니다.
아래 PHP 에러 로그를 분석해 한국어로 간결하게 답하세요:
1. 주요 원인  2. 영향 범위  3. 조치 방법  4. 심각도(높음/중간/낮음)

로그:
${logContent.substring(0, 4000)}`;

  const response = await bedrockClient.send(new ConverseCommand({
    modelId,                                   // ← 모델 ID만 바꾸면 끝
    messages: [{ role: 'user', content: [{ text: prompt }] }],
    inferenceConfig: { maxTokens: 1024, temperature: 0.2 },
  }));

  // Converse 응답: output.message.content[].text
  const blocks = response?.output?.message?.content || [];
  const text = blocks.map(b => (typeof b?.text === 'string' ? b.text : '')).join('').trim();
  if (!text) throw new Error('모델 응답이 비어 있습니다');  // 빈 응답도 실패로 → 폴백 유도
  return text;
}

InvokeModel 시절의 모델 전용 body 조립(anthropic_version 등)이 전부 사라졌다. Converse가 알아서 모델별 포맷으로 변환해준다.

해결 ② 주 모델 + 폴백 모델

EOL 사건의 교훈을 코드에 녹였다. 모델을 하나만 믿지 않기. 주 모델이 실패하면 폴백 모델로 1회 재시도한다.

// 환경변수로 모델 지정 — 코드 재배포 없이 교체 가능
const BEDROCK_MODEL_ID          = process.env.BEDROCK_MODEL_ID          || 'deepseek.v3.2';
const BEDROCK_FALLBACK_MODEL_ID = process.env.BEDROCK_FALLBACK_MODEL_ID || 'moonshotai.kimi-k2.5';

async function analyzeWithBedrock(logContent) {
  // 주 모델 → 폴백 순서, 중복 제거
  const candidates = [BEDROCK_MODEL_ID, BEDROCK_FALLBACK_MODEL_ID]
    .filter((id, i, arr) => id && arr.indexOf(id) === i);

  let lastErr;
  for (const modelId of candidates) {
    try {
      return await invokeConverse(modelId, logContent);
    } catch (err) {
      lastErr = err;
      console.log(`모델 ${modelId} 실패: ${err.message} → 다음 후보 시도`);
    }
  }
  throw lastErr || new Error('사용 가능한 Bedrock 모델이 없습니다');
}

Converse가 포맷을 흡수하니, 주 모델과 폴백 모델이 서로 다른 벤더여도 상관없다. 여기선 주 모델을 DeepSeek, 폴백을 Kimi로 뒀다. 둘 다 같은 invokeConverse 코드로 호출된다. 11일차처럼 Claude를 써도 되고 — 그냥 환경변수 값만 다를 뿐이다.

핵심 설계 — 모델 ID를 환경변수로 뺀 게 포인트다. 다음에 또 어떤 모델이 EOL 되거나 더 좋은/싼 모델이 나오면, 코드 재배포 없이 Lambda 환경변수만 바꾸면 끝난다.

해결 ③ IAM 권한을 두 모델 모두 허용으로

폴백을 넣었으니 IAM도 주 모델 + 폴백 모델 ARN을 둘 다 허용해야 한다. 하나만 열어두면 폴백이 권한 거부로 또 실패한다. 이번에 IAM 정책을 이렇게 다시 설정했다.

{
  "Effect": "Allow",
  "Action": "bedrock:InvokeModel",
  "Resource": [
    "arn:aws:bedrock:ap-northeast-1::foundation-model/deepseek.v3.2",
    "arn:aws:bedrock:ap-northeast-1::foundation-model/moonshotai.kimi-k2.5"
  ]
}

Converse API도 권한은 bedrock:InvokeModel이다(별도 Converse 액션이 아님). 헷갈리기 쉽다.
모델을 추가/교체하면 이 Resource 목록도 같이 갱신해야 한다. 환경변수로 모델만 바꾸고 IAM을 안 바꾸면 새 모델에서 AccessDenied가 난다.
Bedrock 콘솔의 Model access에서 해당 모델이 "액세스 허용(Access granted)" 상태인지도 먼저 확인해야 한다. IAM과 별개로 모델 자체 사용 승인이 필요하다.

함정 — 모델 ID와 리전 (on-demand vs inference profile)

마지막으로 데인 지점이다. 모델 ID를 넣었는데 이런 에러가 날 수 있다.

on-demand throughput isn't supported

그 모델이 해당 리전에서 온디맨드 호출을 바로 지원하지 않고, cross-region inference profile을 거쳐야 하는 경우다. 이때는 모델 ID 앞에 리전 접두사가 붙은 inference profile ID(예: apac.<model-id>)로 바꿔야 한다. 중요한 건 이것도 코드를 안 고쳐도 된다는 점이다. Converse 기반이라 환경변수 BEDROCK_MODEL_ID만 콘솔에서 확인한 inference profile ID로 바꾸면 된다. 정확한 호출 가능 ID는 Bedrock 콘솔 → Model catalog에서 확인한다.

결과 — 복구 + "모델에 안 묶이는" 구조

AI 분석 복구 — 알람 메일에 다시 원인·영향·조치·심각도가 정상 출력
모델 독립 — 어떤 모델이 EOL 돼도 환경변수만 교체. 코드 재배포 불필요
이중화 — 주 모델이 죽어도 폴백이 받아줌

가장 좋은 건 "급할 땐 환경변수만"이다. 다음에 또 "AI 분석 실패" 메일이 오면, 코드를 열 필요 없이 Lambda 환경변수 BEDROCK_MODEL_ID를 살아있는 모델로 바꾸면 즉시 복구된다.

마치며

이번 사건의 교훈은 하나로 요약된다. 클라우드 AI 모델 ID는 "상수"가 아니라 "언젠가 바뀌는 설정값"이다. 그래서 (1) 포맷을 흡수하는 Converse 같은 추상 API를 쓰고, (2) 모델 ID를 환경변수로 빼고, (3) 폴백을 두고, (4) IAM과 모델 액세스를 그에 맞게 열어두는 것. 이 네 가지면 다음 EOL이 와도 몇 분 만에 넘어간다.

부가 기능(AI 분석)이 조용히 죽어 있어도 본체(알람)는 멀쩡했다는 점도 다시 새겼다. 중요한 자동화일수록 "실패를 눈에 띄게" 만들어 두는 게 좋겠더라.

AWS Bedrock · AI 운영 자동화 · 트러블슈팅 문의

댓글로 편하게 남겨주세요.

CloudWatch 알람 메일에 AI 분석 붙이기 — Lambda + Bedrock Claude 파이프라인

oldserver — Thu, 15 Oct 2026 10:34:50 +0900

OPERATION · 모니터링 자동화

CloudWatch 알람에 AI 오류 분석을 붙이기

에러가 터지면 Lambda가 최근 로그를 긁어 AWS Bedrock의 Claude에게 분석시키고, 원인·영향·조치·심각도가 정리된 메일을 보내준다.

6일차에서 "PHP 에러 알람이 울려 공격을 잡았다"는 글을 썼다. 그 글을 읽고 "그 알람은 어떻게 세팅한 거냐"는 질문을 받았다. 이번 글은 그 알람 파이프라인을 처음부터 만드는 과정이다. 그리고 핵심은 단순 알람이 아니라, 에러가 터지면 AWS Bedrock의 Claude가 로그를 분석해 "원인·영향·조치·심각도"를 정리한 메일을 보내주는 부분이다.

소스 코드 변경 없이 설정만으로 되는 로그 수집부터, AI 분석 Lambda의 프롬프트 설계와 무한루프 방지까지 순서대로 정리했다. (모든 식별자·주소는 예시다.)

왜 "알람"만으로는 부족한가

CloudWatch 알람은 "PHP 에러가 분당 30건을 넘었다"는 숫자만 알려준다. 그런데 새벽에 그 메일을 받으면, 서버에 접속해 로그를 열어보기 전까지는 아무것도 모른다. 진짜 심각한 건지, 일시적 스파이크인지, 어느 API가 문제인지 매번 사람이 로그를 뒤져야 했다.

그래서 알람에 두 가지를 더 얹었다. 첫째, 알람 메일에 최근 에러 로그를 같이 붙여 접속 전에 뭐가 터졌는지 바로 본다. 둘째, AI가 그 로그를 분석해 원인·영향·조치·심각도를 요약한다. 결과적으로 메일 하나만 봐도 "지금 당장 일어나야 하나, 아침에 봐도 되나"를 판단할 수 있게 됐다.

전체 파이프라인

PHP 서버에러 로그 파일 → Agent 수집

CloudWatch Alarm임계값 초과 → ALARM

Lambda로그 조회 → AI 분석

이메일로그 + AI 분석 수신

그림 1. 로그 수집 → 알람 → Lambda(로그조회+AI분석) → SNS → 메일

Step 1. 로그 수집 — CloudWatch Agent

가장 좋은 점은 애플리케이션 코드를 안 건드린다는 것이다. EC2에 CloudWatch Agent를 설치하고, PHP가 이미 파일로 남기는 에러 로그를 그대로 수집하게 설정만 하면 된다. 설정의 핵심은 logs.logs_collected.files.collect_list다.

{
  "metrics": {
    "namespace": "MyGame/System",
    "metrics_collected": {
      "mem":  { "measurement": ["mem_used_percent"] },
      "disk": { "measurement": ["used_percent"], "resources": ["/", "/data"] }
    }
  },
  "logs": { "logs_collected": { "files": { "collect_list": [
    { "file_path": "/data/app/logs/php_errors.log",
      "log_group_name": "/mygame/live/php-errors",
      "log_stream_name": "{instance_id}", "retention_in_days": 30 },
    { "file_path": "/data/app/logs/exception_log_*",
      "log_group_name": "/mygame/live/exception",
      "log_stream_name": "{instance_id}", "retention_in_days": 30 }
  ] } } }
}

EC2에는 CloudWatchAgentServerPolicy가 붙은 IAM Role이 필요하다. 없으면 로그가 안 올라간다. 그리고 CloudWatch 기본 메트릭에는 메모리가 없어서(EC2는 CPU만 기본 제공), Agent를 깔아야 mem_used_percent를 볼 수 있다.

Step 2. 알람 — 임계값 초과하면 SNS로

로그가 올라오면 "분당 에러 N건 초과" 같은 조건으로 알람을 건다. 메트릭 알람은 CLI로 거는 게 재현·관리에 편하다.

REGION="ap-northeast-1"
SNS_TOPIC="arn:aws:sns:${REGION}:<ACCOUNT_ID>:mygame-live-alerts"

# SNS 토픽 + 이메일 구독 (최초 1회)
aws sns create-topic --name mygame-live-alerts --region $REGION
aws sns subscribe --topic-arn $SNS_TOPIC --protocol email \
  --notification-endpoint "alerts@example.com" --region $REGION

# 예: EC2 CPU 80% 초과 (5분 평균이 2회 연속)
aws cloudwatch put-metric-alarm --region $REGION \
  --alarm-name "mygame-live-ec2-cpu-high" \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=<INSTANCE_ID> \
  --statistic Average --period 300 --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions $SNS_TOPIC --ok-actions $SNS_TOPIC

PHP 에러 수 알람도 같은 방식이다(메트릭 필터로 로그에서 에러 건수를 메트릭으로 만들어 두고 임계값을 건다). RDS CPU·FreeableMemory·Connections, Redis Memory·Evictions도 같은 패턴으로 걸어둔다. 6일차에서 다룬 "임계값을 올리지 말고 평가 기간을 늘려라"가 여기 적용된다. --evaluation-periods로 순간 스파이크는 무시하고 지속되는 에러만 알람으로 만든다.

Step 3. AI 오류 분석 — 이 글의 핵심

여기서부터가 진짜다. SNS 알람을 사람이 받는 게 아니라 Lambda가 먼저 받아서 로그를 긁고 AI에게 분석시킨다. 흐름은 세 단계다.

3-1. Logs Insights로 최근 에러 로그 긁기

Lambda는 알람을 받으면 여러 로그 그룹(php-errors, exception 등)에 대해 최근 5분치 로그를 Logs Insights 쿼리로 가져온다.

const queryString = `fields @timestamp, @message
| sort @timestamp desc
| limit ${QUERY_LIMIT}`;

const { queryId } = await logsClient.send(new StartQueryCommand({
  logGroupName: groupName, startTime, endTime, queryString,
}));

// StartQuery는 비동기 — Complete 될 때까지 폴링
let status = 'Running';
while (status === 'Running' || status === 'Scheduled') {
  await sleep(1000);
  const res = await logsClient.send(new GetQueryResultsCommand({ queryId }));
  status = res.status;
  results = res.results || [];
}

함정 — Logs Insights의 StartQuery는 즉시 결과를 주지 않는다. queryId만 돌려주고, GetQueryResults로 Complete가 될 때까지 폴링해야 한다. 그래서 Lambda Timeout을 120초로 넉넉히 잡아야 한다(기본 3초면 무조건 실패).

3-2. Bedrock Claude에게 분석 요청

긁어온 로그를 프롬프트에 넣어 Bedrock의 Claude에게 던진다. 핵심은 "무엇을 답하라"를 구조화하는 것이다. 자유 서술로 두면 매번 형식이 달라 메일로 읽기 나쁘다.

const prompt = `당신은 PHP 게임 서버 운영 전문가입니다.
아래는 최근 발생한 PHP 에러 로그입니다. 다음을 한국어로 간결하게 답하세요:

1. **주요 원인** (에러 패턴 요약)
2. **영향 범위** (어떤 기능/API에 영향이 있는지)
3. **조치 방법** (즉시 조치 + 근본 해결책)
4. **심각도** (높음/중간/낮음)

로그:
${logContent.substring(0, 4000)}`;

const body = JSON.stringify({
  anthropic_version: 'bedrock-2023-05-31',
  max_tokens: 1024,
  messages: [{ role: 'user', content: prompt }],
});

const response = await bedrockClient.send(new InvokeModelCommand({
  modelId: 'anthropic.claude-3-haiku-20240307-v1:0',  // 빠르고 저렴
  contentType: 'application/json', accept: 'application/json', body,
}));

const parsed = JSON.parse(new TextDecoder().decode(response.body));
const aiAnalysis = parsed.content[0].text;

프롬프트 설계에서 신경 쓴 포인트는 다음과 같다.

역할 부여 — "운영 전문가"라고 역할을 주면 일반 설명 대신 운영 관점(어느 API가 영향받는지)으로 답한다.
출력 항목 고정 — 원인/영향/조치/심각도 4개로 못박아 메일에서 늘 같은 구조로 읽히게.
심각도 라벨 강제 — "높음/중간/낮음"으로 대응 우선순위를 한눈에.
로그 길이 컷(substring(0, 4000)) — 토큰 비용·한도 보호. 최근 로그만으로도 패턴 파악엔 충분.
모델 선택 — claude-3-haiku는 빠르고 저렴. 알람 요약엔 가벼운 모델로 충분하고, 깊은 분석이 필요하면 상위 모델로 교체.

3-3. 로그 + AI 분석을 합쳐 메일로

분석 결과와 원본 로그를 하나의 메일 본문으로 합쳐 SNS에 다시 발행한다. 그러면 이메일 구독자가 받는다. 실제 수신 메일은 이런 모습이다.

  PHP Error 임계값 초과 알림
━━━━━━━━━━━━━━━━━━━━━━━━
■ 알람: mygame-live-php-errors-high
■ 시각: 2026-10-xx 03:14 (KST)
■ 사유: Threshold Crossed: 42 > 30

  AI 분석 결과
━━━━━━━━━━━━━━━━━━━━━━━━
1. 주요 원인: 특정 유저 ID의 보상수령 API 반복 호출 →
   foreach 타입 경고 다수
2. 영향 범위: reward 관련 API. 정상 유저 영향은 적음
3. 조치: 해당 IP ALB 차단 + 입력 검증 보강
4. 심각도: 중간 (공격 패턴이나 서버 검증으로 차단 중)

  최근 5분 에러 로그
━━━━━━━━━━━━━━━━━━━━━━━━
[로그 원문 ...]

실제로 6일차에서 겪은 공격 때, 이 AI 분석이 "단일 유저의 반복 호출, 공격 의심, 심각도 중간"이라고 먼저 짚어줘서 상황 파악이 훨씬 빨랐다.

함정 — AI 알람이 자기 자신을 다시 트리거(무한루프)

이 구조에서 제일 조심할 건 무한루프다. Lambda가 SNS에 메일을 재발행하는데, 그 SNS가 다시 Lambda를 트리거하면 영원히 돈다(그리고 Bedrock 호출 비용이 폭발). 막는 방법은 간단하다. Lambda가 발행하는 메시지에 마커를 심고, 수신 시 마커가 있으면 즉시 스킵한다.

// 수신: Lambda가 보낸 메시지면 스킵
const attrs = event.Records?.[0]?.Sns?.MessageAttributes || {};
if (attrs.source?.Value === 'lambda-alert') {
  return { statusCode: 200, body: 'self-published, skip' };
}

// ... 처리 후 발행: 마커를 심어서 보냄
await snsClient.send(new PublishCommand({
  TopicArn: SNS_TOPIC_ARN, Subject: subject, Message: messageBody,
  MessageAttributes: { source: { DataType: 'String', StringValue: 'lambda-alert' } },
}));

추가 안전장치로 AlarmName이 없거나 JSON 파싱이 실패하면 스킵, ALARM 상태가 아니면 스킵도 넣었다. "내가 만든 메시지는 내가 처리하지 않는다"가 핵심이다.

필요한 IAM 권한

Lambda 실행 역할에 딱 세 가지만 주면 된다(최소 권한).

액션	용도
logs:StartQuery, logs:GetQueryResults	Logs Insights로 에러 로그 조회
sns:Publish	분석 결과 메일 재발행
bedrock:InvokeModel	Claude 호출

마치며

알람은 "숫자"지만, 운영자가 진짜 원하는 건 "그래서 이게 뭔데, 지금 일어나야 해?"에 대한 답이다. CloudWatch 알람 뒤에 Lambda + Bedrock을 한 겹 끼우면, 메일 하나에 로그 원문과 AI가 정리한 원인·영향·조치·심각도가 같이 와서 그 판단이 빨라진다.

핵심은 세 가지였다. Logs Insights는 비동기라 폴링 + 넉넉한 Timeout, 프롬프트는 출력 항목을 고정(원인/영향/조치/심각도), 그리고 SNS 재발행 무한루프를 마커로 차단. 가벼운 모델(haiku)로도 알람 요약은 충분하고, 비용도 알람당 몇 원 수준이다.

AWS 운영 자동화 · AI 로그 분석 · 모니터링 문의

댓글로 편하게 남겨주세요.