인프라 · 총괄 | AI 채용 자동화 플랫폼

1. 미션

전원이 딛는 바닥이다. AWS · 배포 · CI/CD와 스키마 이행을 책임지고, 총괄로서 마일스톤 · 범위 합의 · 서버 자원과 비용 · 통합 · 발표를 잡는다. 총괄은 리뷰 게이트가 아니다 — 도메인 안의 판단과 머지는 08. 28. 리뷰 게이트 폐지 이후 각 오너 몫이다.

이 도메인은 다른 어떤 도메인에도 의존하지 않는다. 그래서 반대로 전부의 선행 조건이 된다 — 여기가 지연되면 그것이 곧 나머지 네 도메인의 대기다. 이 도메인의 큐 우선순위가 사실상 팀 전체의 임계경로다.

2. 범위

도메인 업무

AWS — 계정 · IAM 최소 권한 · S3 버킷 · EC2 배포. W1~W2에 세운 SES · SQS는 예산 만료(10. 27.) 대비로 물러났다(ADR-0031 · 0036)
로컬 실행 환경 — Docker Compose (API · DB · 워커)
CI/CD — GitHub Actions (테스트 · 프론트 빌드 → EC2 배포)
GitHub 설정 — 브랜치 보호 · 코드 소유자 · 리포 권한. 09. 04. 부터 브랜치 보호가 main 직접 push를 실제로 막는다
Vercel 프로젝트 연결 (빌드 설정은 프론트와 협업)
스키마 이행 — alembic 리비전이 자동 CD의 upgrade head로 따라오게 한다. ERD · API 문서 갱신은 각 오너가 코드와 같은 커밋에서 직접 하고 사후 공지한다

총괄 업무 (도메인 밖 상시)

인터페이스 합의는 두 오너 사이의 PR로 처리한다 — 팀장은 머지 주체가 아니다. CI가 초록이면 오너가 스스로 머지한다(09. 04. 개정)
주간 다이제스트 — 금요일에 그 주 변경 요약과 칸반 done 열을 훑는다. 검수가 아니라 파악용이라 여기 걸리기를 기다릴 PR은 없다
마일스톤 · 범위 합의 — 도메인 안 판단은 오너 자율이고, 범위 자체가 움직일 때만 조율한다. 다른 도메인이 대기 중인 의존은 팀 채널에서 우선순위를 다시 잡는다 — 밀리면 받는 쪽이 일주일을 논다
서버 자원 · 비용 — 예산 $400 · 10. 27. 까지(GPU 포함)
주간 계획서 — 주 마감 게이트 · 충돌 방지
도메인 간 조정 · 통합 리허설 · 발표 총괄(원고 프레이밍 통일) · 게이트 판정(09. 04. 초기 버전 · 09. 30. 1차 완성)

사람별 작업 큐는 총괄이 쥐지 않는다. 도메인 오너제로 전환하면서 각 로드맵으로 이관했고, 주간 계획서에는 주 마감 게이트와 도메인 간 충돌만 남겼다.

3. 인터페이스 계약

제공 — 데이터베이스 접속 문자열과 AWS 자격 · 리소스명은 전부 .env(git 제외)와 .env.example(키 이름만)로 전달한다. 리소스가 준비되면 .env.example 갱신 PR이 곧 공지다 — 별도 안내 없이도 받는 쪽이 무엇이 생겼는지 알 수 있게 했다.

의존 — 없음.

4. 주간 계획

초기 버전 게이트(09. 04.)의 정의에 배포가 들어가므로, 게이트 판정의 집행자가 이 도메인이다.

주차	마일스톤	내용	완료 기준
W108. 24. ~ 28.	M1 선행조건 풀기	AWS 계정 · S3 · SES 발신 도메인 신청 · 앱 뼈대 머지 · 목업 머지 → ERD 확정 · 스키마 합의 2건 결정 · Docker Compose · 브랜치 보호와 코드 소유자 갱신	ERD 문서 상단이 "확정 vX.X · 날짜". `docker compose up` 한 줄로 기동. 백엔드 큐의 선행이 전부 해소됨
W208. 31. ~ 09. 04.	M2 실배포 1차 초기 버전	IAM 최소 권한 정리 · SQS 큐 생성 · SES 샌드박스 해제 확인 · EC2에 API와 워커 수동 배포 · Vercel 연결 · 환경변수 체계 확정 · 09. 04. 초기 버전 게이트 판정	외부 URL에서 `/health` 200. 프론트 프리뷰가 실 API를 바라본다. 초기 버전 정의 4항목 전부 충족 판정
W309. 07. ~ 11.	M3 CI/CD	PR마다 테스트 + 프론트 빌드 · main 머지 시 EC2 배포 자동화 · 헬스체크와 로그 확인 경로	push → 테스트 → 배포가 사람 손 없이 돈다. CI 빨간불 = 머지 불가가 오너제의 안전망으로 작동 시작
W409. 14. ~ 18.	중간 통합 점검	QA 시나리오로 전 도메인 가로지르는 1차 통합 점검 · 막힌 도메인 식별과 조정 · 모니터링 · 로그 경로 정리	중간 점검 결과가 주간 계획서에 기록되고 W5 계획에 반영됨
W509. 21. ~ 25.	M4 통합 · 리허설	QA 시나리오 전 항목 통합 리허설 · 데모 환경 동결 · 발표용 역할표 최종 확정	데모 시나리오가 프로덕션 URL과 실기기에서 끊김 없이 돈다. 리허설 2회
버퍼09. 28. ~ 30.	1차 완성 판정	잔여 버그 뒷처리 · 발표 자료 총괄 착수	09. 30. 1차 완성 선언 — 필수 기능 전부 프로덕션에서 동작

5. 리스크 및 대응

리스크	대응
자체 머지가 깨진 main을 만든다	팀장 병목은 도메인 오너제(08. 24.)와 리뷰 게이트 폐지(08. 28.)로 없앴고, 09. 04. 부터는 승인 없이 자기 PR을 자기가 머지한다. 그래서 "main은 항상 동작한다"는 책임이 리뷰어에서 머지하는 사람에게 넘어왔다. 남은 안전망은 CI 빨간불 = 머지 불가 하나이고, main 머지는 2분 뒤 프로덕션이라 깨진 main은 묻지 않고 고치거나(fix-forward) revert한다.
메일 발송 — SES에서 물러났다	W1에 걸어둔 신청은 08. 27. 한 번 거절돼 검증된 수신자(팀원 메일)로만 테스트했고, 재신청이 09. 01. 프로덕션 승인(5만 통/일)으로 풀렸다. 그래도 예산 만료(10. 27.) 뒤에도 서비스가 돌아야 해서 SES 경로 자체를 접었다(ADR-0031). 09. 08. 부터 `MAIL_DISPATCH=n8n`이 기본이고 n8n이 팀 지메일 SMTP로 실발송하며, 놀고 있던 SQS 메일 워커는 09. 14. 폐기했다(ADR-0036). 남은 리스크는 SES 해제가 아니라 발송 담당이 한 곳으로 좁아진 것이라, n8n이 멈추면 API가 5분마다 SMTP로 재발송한다.
ERD 확정이 늦으면 전 도메인 대기	목업 머지 직후 즉시 확정한다. 확정 시점을 앞당기는 결정을 W1에 내려 유지 중이다.

6. 발표 포인트

배포 파이프라인을 어떻게 설계했는가 — Docker → EC2 → Actions 자동화까지의 단계와 각 단계에서 무엇을 사람 손에서 뗐는가.
권한 모델 — 클라우드의 IAM 최소 권한과 애플리케이션의 역할 3종을 어떤 기준으로 나눴는가.
5인 팀의 리뷰 병목을 구조로 풀었다 — 작업 풀 + 팀장 지시서 체계에서 도메인 오너제로 전환한 과정. 조직 설계도 아키텍처다.