배포 및 운영

1. 배포 구성

프론트는 Vercel, 백엔드와 AI 서비스는 AWS EC2 한 대 위의 docker compose다. 둘 다 트리거는 같다 — main 머지. 파일은 브라우저가 S3 로 직접 올려 서버를 거치지 않고, 메일은 API 가 n8n 웹훅으로 넘긴다.

인스턴스를 세 번 올렸고, 이유는 매번 메모리였다

t3.small(2GB)에서 t3.medium(4GB)으로 올린 것은 거짓말 탐지 서비스가 분석 1건에 574MiB 를 써서 api 와 같이 못 돌았기 때문이다(월 +$17). 그 다음 t3.large 까지 간 것은 실시간 면접 STT 였는데, 원인은 인스턴스 크기가 아니라 코드 기본값 하나였다 — faster-whisper 가 CPU 에서 float32 로 잡혀 로드에만 3,835MB 를 썼다. int8 을 명시하자 891MB(1/4)로 내려갔고 전사도 2.3배 빨라졌다. 메모리를 다섯 번 올리고 인스턴스를 옮긴 뒤에야 찾은 값이다. 디스크는 빌드 캐시와 컨테이너 이미지 때문에 EBS 를 29GB 에서 50GB 로 온라인 확장했다(무중단, 여유 27GB). 현재 타입은 단정하지 않는다 — 운영 문서에 남은 기록이 t3.medium 과 t3.large 로 갈려 있어, 확인되는 것은 위의 증설 이력까지다.

GPU 는 구성도에 없다 — 켜고 끄는 전제이기 때문이다

운영 EC2 에는 GPU 가 없고, 상시 GPU 가 필요한 경로도 없다. 거짓말 탐지는 CPU 로 돌고 (MediaPipe · scikit-learn), 실시간 전사는 ADR-0038 로 기본이 OpenAI API 가 됐다. GPU 는 로컬 STT 와 Qwen 어댑터를 실제로 돌려 볼 때만 켠다 — lie-detection 을 VIT_DEVICE=cuda 로 옮긴 T4 실측이 STT 275ms/3초 음성 · ViT 75ms/crop 이고, CPU 에서 7.5초 걸리던 전사가 약 1초로 줄며 8명 동시 접속에도 대기줄이 생기지 않았다. 그런데도 상시로 두지 않은 이유는 예산이다(위 표 — 24시간이면 월 ≈$470). 그래서 이 장의 구성도에는 GPU 가 없다 — 심사 서빙에 항상 떠 있어야 하는 것만 그렸다.

인프라 이전 — 개인 명의에서 역할 기반으로

2026-09-02 팀장 이탈 시점에 AWS 루트·IAM·GitHub org·Vercel·도메인·API 키·서버 .env 의 AWS 키가 전부 한 사람 개인 명의였다. 그가 빠지면 배포·메일·업로드가 멎고 아무도 고칠 수 없는 구조였고, 실제로 09-02 저녁 팀장 개인 키가 폐기되자 AI 기능이 전면 중단됐다 — /health 는 200 이고 읽기 API 도 200 인데 요약 호출만 0초에 422 로 떨어졌다. 0초는 LLM 호출이 시작조차 안 됐다는 뜻이다. 09-04 에 개인 AWS(서울)로 전체를 이전하고 IAM 을 suvisdev(관리) · arda-viewers(팀 열람) · arda-server(서버 키) 세 갈래로 나눴다. 키가 새면 서버 유저 하나만 재발급하면 된다.

AWS 표면적을 8종에서 3종으로

예산이 $400 · 2026-10-27 까지라, 그 이후에도 서비스가 이어 돌 수 있어야 했다. ADR-0031 로 EC2 · S3 · IAM 세 개만 남기고 나머지는 self-host 대안 뒤로 물렸다. 폐기가 아니라 스위치로 둔 것이 요점이다 — 코드에 이미 갈림길이 있어 값 하나로 갈아탄다.

앵커 게시만은 이전 대상이 아니다. 서명 개인키가 서버가 아니라 GitHub Actions Secret 에 있어서, AWS 를 떠나도 그 경로는 그대로 돈다(2절).

온프레미스 3대를 구축했고, 심사 직전에 닫았다

AWS 예산 만료에 대비해 09-16 ~ 09-18 학원 PC 3대로 온프레미스 스택을 실제로 구축해 운영했다 — Cloudflare Tunnel 로 외부 노출, Ollama 로 Qwen 어댑터 3갈래 서빙, S3 자리에는 MinIO. 읽고 끝낸 검토가 아니라 돌아가는 물건이었다. 그런데 AWS 에서는 나지 않던 오류가 심사 직전에 누적됐다.

2. CI/CD 파이프라인

CI 와 CD 는 목적이 다르다. CI 는 깨진 것을 보이게 하고, CD 는 초록인 것을 사람 손 없이 운영에 올린다. 둘을 잇는 규칙이 하나다 — CI 빨간불이면 머지할 수 없고, 머지되면 2분 안에 배포가 시작된다.

CI — 게이트가 아니라 "깨졌다는 사실만 즉시 보이게"

도입 계기는 명확하다. 2026-09-01 하루에 깨진 main 을 두 번 발견했고 둘 다 우연이었다(d7fdd10 · d96749e). 사람 승인 게이트를 세우는 대신 깨진 사실만 즉시 보이게 하는 쪽을 택했다 — 도메인 오너제에서 리뷰 게이트는 곧 병목이기 때문이다. push 와 PR 마다 5개 잡이 돈다.

같은 브랜치에 연달아 push 하면 앞의 실행을 취소한다(cancel-in-progress) — 무료 러너 분을 아끼기 위해서다. 머지 경로는 2026-09-04 에 하나로 좁혔다: main 직접 push 와 force push 는 GitHub 브랜치 보호가 차단하고, 브랜치 → PR → CI 초록 확인 → 자체 머지다. 사람 승인 게이트는 없다. CI 빨간불 = 머지 불가가 오너제의 유일한 안전망이므로, 테스트를 주석 처리해 통과시키는 것은 금지돼 있다.

CD — main 머지가 곧 프로덕션 배포

서버의 systemd 타이머 arda-deploy.timer 가 2분마다 origin/main 을 확인하고, 새 커밋이면 deploy-arda.sh 를 돌린다. 빌드 포함 총 5~10분. 로그는 ~/deploy.log. 스크립트 전체가 set -euo pipefail 이라 중간에 실패하면 거기서 멈추고 돌던 컨테이너는 계속 산다. "배포해 주세요"라는 요청이 사라진 것이 이 장치의 실제 효과다.

빌드와 up 을 분리한 것은 규칙이다. 빌드가 깨져도 돌던 컨테이너가 안 죽는다 — up -d --build 한 번으로 가면 빌드가 깨질 때 서비스가 같이 내려간다. 디스크 고갈로 api 를 실제로 내려야 했던 배포(다운타임 약 6분)를 겪고 스크립트에 박았다. 시연 직전에는 sudo systemctl stop arda-deploy.timer 로 배포를 잠시 멈출 수 있다. 프론트는 별도로 Vercel 이 main 머지 후 1~2분 내 자동 배포하고, 앱은 flutter build apk --dart-define=API_BASE=<API 주소> 로 굽는다.

3. 모니터링 및 로그 관리

설계가 아니라 사고에서 나왔다. 앵커 cron 이 이틀 죽었는데 아무도 못 봤고(09-05~06), "주 1회 ~/status.sh 를 본다"는 습관은 까먹는다. 그래서 사람이 안 봐도 되게 만들었다 — 임계를 넘으면 메일이 온다. 전체 비용은 0원이다(무료 구간 안).

안에서 보는 눈 — CloudWatch + SNS

서버 cron 이 10분마다 push-metrics.sh 로 숫자를 CloudWatch 에 보낸다(네임스페이스 Arda, 차원 Host=arda-api). 관측 에이전트를 따로 설치하지 않았다 — 이미 있는 aws-cli 만 쓴다. 알람은 6개이고 전부 SNS 주제 arda-alerts 로 메일을 쏜다. 알람 정의는 CloudFormation 템플릿 파일 하나(infra/cloudwatch-alarms.yml)다 — 콘솔 클릭 30번 대신 파일 업로드 한 번이고, 지우려면 스택을 지운다.

비용이 0인 근거는 CloudWatch 상시 무료 구간(사용자 지정 지표 10개 · 알람 10개 · API 100만 건/월)과 SNS 메일 월 1,000통 무료 안에 전부 들어가기 때문이다. 비용 0

밖에서 보는 눈 — GitHub Actions 헬스체크

서버 안에서만 보면 서버는 멀쩡한데 밖에서 안 닿는 경우를 못 잡는다. 그래서 GitHub 러너가 15분마다 공개 주소 두 개(api…/health · 프론트)를 밖에서 찌른다. 30초 간격으로 두 번 실패해야 알린다 — 한 번 삐끗한 것으로 알리지 않기 위해서다. 실패하면 이슈를 열거나 열린 이슈에 코멘트하고, 복구되면 코멘트를 달고 자동으로 닫는다.

자동 경보와 별개로 사람이 보는 계기판도 있다. ~/status.sh 는 디스크 · 컨테이너 · 마지막 배포 · 마지막 백업 · 헬스 응답을 한 화면에 낸다. 읽기 전용이고, 주 1회 눈으로 훑는 용도다.

로그 관리 — 디스크가 차면 배포가 멈춘다

로그 관리가 운영 과제가 된 것은 29GB 디스크에서 로그 하나가 수 GB 로 부푼 사고 때문이다. compose 에 로그 드라이버 옵션을 걸어 서비스당 20MB × 3개 로 상한을 뒀다. 운영 로그는 목적별로 나뉜다 — 배포 ~/deploy.log · 백업 ~/backup.log · 지표 ~/metrics.log(10분마다 disk=..% backup_age=..h api=1 이 찍힌다).

가장 컸던 디스크 사고는 로그가 아니라 컨테이너 쓰기 레이어였다. 재배포 빌드가 No space left on device 로 죽었는데(디스크 97%, 590MB 남음), 원인은 컨테이너가 뜰 때마다 venv 를 쓰기 레이어에 다시 설치하고 있던 것이었다. 이미지는 382MB 인데 컨테이너 둘이 10.8GB 를 먹고 있었고, 게다가 런타임에 받은 것은 CPU 가 아니라 CUDA torch 였다. CMD 를 /app/.venv/bin/… 직접 호출로 바꾸자 — 기동이 곧 실행이라 재설치가 일어나지 않는다:

"배포 직후 502 가 계속되면 기다릴 게 아니라 로그를 본다" 가 이 수치에서 나온 규칙이다 — 2분을 기다리는 것이 정상이던 시절이 끝났기 때문이다.

백업 — 서버가 털려도 백업은 못 지우게

EC2 한 대, EBS 볼륨 하나다. 인스턴스 사고 한 번이면 지원자 개인정보와 무결성 원장이 같이 사라지고, 앵커 증명은 잃으면 다시 만들 수 없다. 그래서 매일 04:00 KST 에 pg_dump | gzip 으로 뜨고 gzip -t 로 검증한 뒤 전용 S3 버킷에 올린다. 로컬에는 최근 3개만 두고, S3 수명주기로 30일 뒤 자동 삭제해 스토리지 비용에도 상한을 뒀다. n8n 볼륨도 같은 cron 이 함께 올린다.

사고가 남긴 장치

아래는 전부 먼저 터진 뒤에 생긴 것이다. 설계 단계에서 예상해 넣은 것이 아니라, 한 번 당하고 규칙으로 승격시킨 것들이다.