MUNSIK BLOG

SSAFY 16기 합격 후기

munsik22 — Sat, 11 Jul 2026 18:46:58 +0900

지원 동기

작년 말에 진행했던 SSAFY 15기 모집에도 서울캠퍼스 임베디드 트랙에 지원했었지만 면접에서 떨어진 적이 있었다. 이후 공백기 동안 뭐라도 해야겠다는 생각으로 올해 4월부터 내일배움캠프에서 진행하는 자바 부트캠프에 참가했다. 백준에서 주로 쓰던 언어는 파이썬이었고 스프링부트도 해 본 적이 없었지만 진도를 따라가는 데 어려움은 없었다. 단기심화 과정 특성상 정신 없이 온라인 강의 주입(?)과 프로젝트를 반복했고, 교육의 질에는 만족했지만 짧은 시간동안 비대면으로 진행하는 환경이다 보니 몰입도 측면에서는 아쉬웠다. 특히 크래프톤 정글의 대면 교육 환경에 긍정적인 기억을 가지고 있던 터라 더욱 아쉬움을 느꼈던 것 같다.

SSAFY라는 과정이 1년 동안 진행하는 것이다 보니 만만치 않을 뿐더러, 이번에 SSAFY에 들어가면 벌써 세 번째 부트캠프인데 이러다 부트캠프 낭인(?)이 되는 게 아닌가 하는 걱정도 들었다. 그럼에도 불구하고 삼성이라는 든든한 배경과 주변 지인들의 적극적인 추천, 무엇보다도 대면 환경에서 몰입하고 싶은 개인적인 열망 때문에 다시 한 번 지원하게 되었다. 다만 이번에는 임베디드 트랙이 아니라 자바 트랙으로 지원을 했다.

에세이

사실 지난 15기 지원 때도 에세이를 써 본 적이 있고 서류 심사는 합격했기 때문에 문제는 없었던 것 같다. 이미 다른 국비 교육 과정을 진행중이라는 사실이 합격 여부에 영향을 주지는 않을까 걱정을 하기는 했지만 지원 동기를 솔직하게 쓰기로 했다.

이실직고를 하자면 이번 에세이는 Claude가 대필해줬다 물론 글감과 초안은 내가 작성했고, 클로드에게 스스로 피드백 및 퇴고를 반복 진행하도록 시킨 이후에 최종 퇴고와 오탈자 검수는 내가 직접 했다.

코딩 테스트

코테 자체도 지난 번에 응시한 경험이 있기 때문에 별 걱정은 하지 않았다. 당연한 얘기지만 어떤 문제가 나왔는지는 대외비이므로 언급하기가 어렵다. 주관적인 의견이지만 지난번보다는 문제가 쉬웠던 것 같다.

면접

문제의 면접. 이번 16기 지원에는 면접 스터디를 구하려고 생각했지만, 진행 중이었던 부트캠프 과정과 겹쳐서 따로 시간을 내기 어려웠기 때문에 이번에도 혼자서 준비했다. PT 면접 준비는 모든 싸피 준비생들의 바이블인 강민혁 님의 PT 면접 영상을 참고했다.

IT 및 AI와 관련된 키워드들을 공부한 뒤, IT 업계와는 전혀 상관 없는 주제에 대해 PT를 하는 방식으로 준비를 했다. 모기를 예시로 들자면 다음과 같다. (양식 자체는 위 유튜브 영상을 참고했다.)

안녕하십니까 지원자 000입니다.

지금부터 모기의 스텔스 진화와 수면권 침해 해결을 주제로 발표를 시작하겠습니다. 순서는 문제인식, 방안제시, 예상되는 리스크와 해결방안 순으로 진행됩니다.

우선 결론부터 말씀드리면, LiDAR 센서와 열화상 카메라가 장착된 가정용 초소형 요격 드론을 도입하는 것을 제안합니다.

이러한 제안을 하게 된 문제 상황은 다음과 같습니다. 많은 현대인들이 모기들의 날개짓 소리로 인해 심각한 수면 장애를 겪고 있습니다. 모기들이 진화해서 불이 꺼졌을 때만 귀 근처에서 소리를 내고, 불을 켜면 바로 시야에서 사라져 사각 지대로 숨어 버리는 스텔스 회피 기동을 가지게 된 것이 문제의 요인으로 분석했습니다.

이러한 문제를 해결하기 위해 저는 인간의 육안을 뛰어넘은 초소형 요격 드론 도입을 제안드립니다. 실행 방안은 두 가지가 있습니다. 첫째, 드론에 LiDAR 센서와 열화상 카메라가 장착해 불이 꺼진 상황에서도 실시간으로 모기의 움직임을 감지합니다. 둘째, 드론에 온디바이스 AI를 탑재해 실시간으로 모기의 비행 궤적 데이터를 학습하고 위치를 예측합니다. 이로써 인간의 눈에 보이지 않은 위치에 숨은 모기를 한 번에 요격해 현대인들의 수면의 질을 보장할 것으로 기대됩니다.

물론 예상되는 리스크도 존재합니다. 초소형 하드웨어에서도 작동할 수 있는 온디바이스 AI가 시중에 존재하지 않을수도 있다는 것입니다. 이는 엣지 컴퓨팅 기술의 도입으로 모델 자체를 양자화해서 AI 모델을 가볍게 만드는 방식으로 해결할 수 있습니다.

지금까지 모기의 스텔스 진화 해결에 대해 초소형 요격 드론 도입 제안에 대해 발표했습니다.

면접을 떠나 실제 프로젝트를 하듯이 진지하게 고민을 했지만, 짧은 시간 동안 얕은 식견으로 제안한 것이라 최선의 설계가 아니라는 것을 압니다. 00 입사 후에 동료들과 선배님들의 피드백을 통해 더 실무적이고 핏한 의사결정 과정을 경험하고 싶습니다.

경청해 주셔서 감사합니다.

복장에 관해서 짧게 언급하자면 지난번에는 캐주얼 정장, 이번에는 풀 정장으로 입고 갔었지만 돌아와서 생각해보니 복장은 슬리퍼만 아니면 상관 없었을 것 같았다. 정장은 여름이라 괜히 덥기만 했고...

면접 진행 방식 자체는 역시 지난번의 경험 덕분에 알고 있어서 떨리지 않았다. 면접 질문은 준비한 내용에서 전혀 나오지는 않았지만, 떨지 않았기 때문인지 오히려 지난번보다 여유롭게 잘 볼 수 있었던 것 같다.

합격 및 입과 준비

면접에서 안 떨었던 덕분인지 다행히도 이번에는 합격을 할 수 있었다. 2번만에 합격한 SSAFY였지만 당시 내일배움캠프 최종 프로젝트 때문에 한참 정신 없이 바빴던 터라 그렇게 신나하지는(?) 못했다. 내일배움캠프 운영진 측에 개인 사정으로 인한 하차 의사를 밝혔고, 수료를 하지 못할 것을 감안하고 있었지만 다행스럽게도 출석 일자의 80%를 채워서 조기 수료를 할 수 있었다.

SSAFY 입과 전 자취와 셔틀버스 통근을 두고 내적 갈등을 겪었다. 월세 비용 지출 vs 매일 왕복 4시간 출퇴근이라는 트레이드오프를 두고, 대학 생활 때의 통학 지옥 경험을 떠올리며 자취를 선택했다. 그래도 구미는 월세가 싼 편이라 30~40만원 정도로도 좋은 방을 구할 수 있었다. ㄷㅂ부동산을 통해서 방을 계약했는데, SSAFY 교육생은 복비를 받지 않는다고 해서 좋았다.

입과 후에 셔틀버스를 타는 교육생 분의 말을 들어보니 자취방을 구하길 잘했다는 생각이 들었다. 내가 기상하는 시간에 버스를 타셔야 한다고...

SSAFY에서의 1주를 보내고

지난 화요일부터 SSAFY 16기의 교육과정이 시작되었다. 자세한 내용은 대외비이므로 언급하지는 못하겠지만 앞으로의 1년 동안도 열심히 해야겠다.

3주차 5일차 작업일지 (0703) 및 최종 회고

munsik22 — Fri, 3 Jul 2026 16:09:12 +0900

_deploy-wave.yml waiter 관련 (삽질 기록)

무슨 일이 있었나

_deploy-wave.yml이 AWS_MAX_ATTEMPTS를 export한 뒤 aws ecs wait services-stable을 쓰고 있는 걸 보고, 6/22~24 에서 이미 겪었던 "AWS_MAX_ATTEMPTS는 waiter 폴링 횟수에 영향을 안 준다"는 문제가 재발한 것으로 판단해 describe-services를 직접 폴링하는 wait_stable 커스텀 함수로 교체했다.

왜 쓸데없는 짓이었나

ai-service(wave-4)에 max_attempts: 120(30분)을 준 근거 자체가 잘못됐다. 6/24일자 작업 로그는 pgvector 초기화 + Gemini 연결 때문에 기동이 오래 걸린다고 진단했지만, 실제 원인은 환경변수 설정 누락으로 인한 컨테이너 크래시 루프였다. 크래시 루프는 대기 시간을 늘린다고 해결되지 않는다.
실제로 지금까지 배포에서 10분을 넘긴 적이 한 번도 없었다. 애초에 30분을 기다려야 했던 적이 없었다.
즉 max_attempts: 120이라는 설정도, 그걸 실제로 반영되게 만들겠다는 이번 수정도 처음부터 존재할 필요가 없는 문제를 고치려 한 것이었다.

처리

코드(_deploy-wave.yml)와 docs/CD.md는 원래 상태(aws ecs wait services-stable + AWS_MAX_ATTEMPTS export)로 롤백했다. wait_stable 커스텀 함수 도입은 진행하지 않는다.

config-server 중앙 설정 ddl-auto 정리

배경

Flyway 전환 당시 서비스 로컬 application.yml은 ddl-auto: validate로 바꿨지만 config-server 중앙 설정(config/*.yml)은 그대로 update로 남아 있는 것을 발견했다.

문제

Spring Cloud Config는 원격(config-server) 설정이 로컬 설정보다 우선한다. 즉 서비스가 로컬에서 validate로 바꿔도, config-server가 내려주는 update가 이겨서 실제로는 여전히 update로 동작할 수 있는 상태였다.

확인

config-server/src/main/resources/config/*.yml에서 ddl-auto 값을 모두 확인했다.

validate로 이미 맞음: ai-service.yml, auction-service.yml
update로 남아 있었음: user-service.yml, order-service.yml, payment-service.yml, notification-service.yml
bid-service.yml도 update였지만, bid-service는 build.gradle에 JPA 의존성도, JDBC 드라이버도, @Entity 클래스도 없어 datasource/jpa 설정 블록 자체가 죽은 값이다(Flyway 전환 대상에서도 원래 제외됨).

수정

Flyway 마이그레이션이 실제로 적용된 4개 서비스의 config-server 설정을 validate로 통일했다.

config-server/src/main/resources/config/user-service.yml
config-server/src/main/resources/config/order-service.yml
config-server/src/main/resources/config/payment-service.yml
config-server/src/main/resources/config/notification-service.yml

config-server/src/main/resources/config/bid-service.yml은 DB 연결 수단이 아예 없는 서비스라 spring.datasource/spring.jpa 블록 전체를 삭제했다.

최종 회고

개인 사정으로 오늘을 끝으로 최종 프로젝트에서 하차하게 되었다.

이번 프로젝트를 통해 인프라 아키텍처 설계와 배포 파이프라인 구축을 처음으로 전담했다. 프로젝트 요구사항에 최적화된 아키텍처를 도출하고 배포 과정의 예기치 못한 트러블슈팅을 해결하는 과정에서 DevOps 영역의 높은 복잡도를 체감했다. 결과적으로 밤샘 작업 끝에 안정적인 배포 환경을 구축해냈다. 이번 경험을 통해 단순히 기능 코드만 작성하는 개발자를 넘어 인프라 설계, 자동화 배포, 모니터링 기반의 장애 대응력까지 갖춘 백엔드 개발자로 성장할 수 있었다고 생각한다.

[Computational Thinking] 수와 표현

munsik22 — Thu, 2 Jul 2026 22:22:21 +0900

문제 1

문제 2

문제 3

컴퓨터 분야에서 로그의 밑은 항상 2이다.

문제 4

문제 5

후기

대학 1~2학년 때 배운 내용 같은데 수학이랑 벽 쌓고 지낸 지 좀 오래 되어서 다 까먹었다

그래도 전공 짬이 있어서 그런지 이해하는 데 어려움은 (아마도) 없었던 것 같다.

3주차 4일차 작업일지 (0702)

munsik22 — Thu, 2 Jul 2026 19:27:32 +0900

Redis 관리자 접근 허용

무엇을 했나

관리자가 Private Subnet에 있는 RDS와 Redis를 직접 조작하지 못하는 문제를 해결했다. RDS는 이미 모니터링 EC2를 거쳐 접근하는 길이 있었지만 Redis는 없어서, Redis에도 같은 방식의 길을 새로 열었다.

바꾼 파일 (sanji-infra 레포)

modules/network/main.tf
- redis_in_from_monitoring 보안 그룹 규칙 추가
- 모니터링 EC2에서 Redis(6379)로 들어가는 걸 허용
- RDS 규칙(rds_in_from_monitoring)과 같은 방식으로, dev/prod 구분 없이 동일하게 적용
- terraform validate 통과 확인
docs/DEPLOY.md
- 6-3 절에 관리자가 RDS/Redis에 접속하는 방법(SSM 포트포워딩) 추가
- 별도 Bastion 서버 없이 모니터링 EC2를 징검다리로 써서 aws ssm start-session으로 로컬 포트를 RDS/Redis 포트에 연결하는 명령 예시 포함

왜 이렇게 했나

처음에는 dev 환경에서만 여는 방식을 검토했으나, 검토 후 dev/prod 구분 없이 단순하게 열기로 결정
실제 접근 통제는 보안 그룹이 아니라 모니터링 EC2에 SSM 세션을 열 수 있는 IAM 권한으로 하기 때문에, SG를 dev/prod 구분 없이 열어도 안전함
새 Bastion 서버를 만들지 않고 이미 떠 있는 모니터링 EC2와 이미 붙어 있는 SSM 권한을 그대로 재활용

추가 작업: 접속용 쉘 스크립트 작성

RDS/Redis에 SSM 포트포워딩으로 접속하는 걸 매번 손으로 명령어를 치지 않도록 스크립트로 만들었다.

만든 파일 (sanji-infra 레포)

scripts/connect-rds.sh
scripts/connect-redis.sh

사용법

bash scripts/connect-rds.sh <dev|prod> [로컬포트]
bash scripts/connect-redis.sh <dev|prod> [로컬포트]

첫 번째 인자로 dev/prod 환경을 지정한다 (필수).
두 번째 인자로 로컬 포트를 바꿀 수 있다 (생략 시 RDS는 5432, Redis는 6379).
기존 scripts/db-init.sh와 같은 방식(aws.exe, 태그로 모니터링 EC2 조회 후 SSM 명령 실행)을 따라 만들었다.
동작 순서: 태그(Role=monitoring, Environment=<env>)로 모니터링 EC2 조회, RDS/Redis 엔드포인트 조회, aws ssm start-session으로 포트포워딩 시작
docs/DEPLOY.md 6-3 절도 수동 명령어 대신 이 스크립트를 쓰도록 갱신함

추가 수정: RDS 접속 안내 보완

실제 접속 시도에서 두 가지 문제가 확인되어 안내 문구를 보완했다.

-U, -d를 안 주면 psql이 OS 로그인 계정을 유저/DB 이름으로 써서 인증에 실패함 (실제 계정은 sanji)
RDS 기본 파라미터 그룹이 SSL을 강제해서 sslmode=require 없이는 no pg_hba.conf entry ... no encryption 오류 발생

scripts/connect-rds.sh 상단 주석과 docs/DEPLOY.md 6-3 절에 올바른 psql 접속 명령(sslmode=require 포함)과 SSM에서 비밀번호 조회하는 명령을 추가했다.

SSM 스크립트 파일명 변경

무엇을 했나

sanji-infra 레포의 SSM 스크립트 파일명과 관련 문서를 업데이트했다.

바꾼 파일 (sanji-infra 레포)

파일명 변경 (scripts/)

ssm-backup.sh -> ssm-pull.sh
- SSM 파라미터 값을 파일로 가져오는(pull) 스크립트
ssm-restore.sh -> ssm-push.sh
- 파일의 SSM 파라미터 값을 AWS에 적용하는(push) 스크립트

문서 업데이트

README.md
- 배포 가이드 섹션의 명령어 변경
- 파일 구성 섹션의 파일명 및 설명 업데이트
docs/DEPLOY.md
- 4단계(SSM 파라미터 값 주입)의 명령어 변경
- 10단계(SSM 파라미터 백업/복구)의 명령어 및 설명 변경

왜 이렇게 했나

backup/restore 보다 pull/push가 더 직관적이고 명확함
pull은 "AWS에서 로컬로 가져오기", push는 "로컬에서 AWS로 보내기"
전체 레포의 일관성을 위해 문서도 함께 업데이트

GitHub Actions Node.js 20 지원 종료 대응

배경

GitHub Actions에서 "Node.js 20 is deprecated" 경고가 발생. GitHub는 Node.js 20의 수명이 끝남에 따라
2026년 6월 16일부터 러너 기본 런타임을 Node24로 전환하고, 9월 16일에는 Node20을 완전히 제거할 예정.
현재 워크플로에서 쓰는 액션들의 태그를 실제로 확인한 결과, 아래 액션들이 아직 Node20 런타임으로 고정된 메이저 버전을 쓰고 있었음.

확인 방법

각 액션 저장소의 action.yml을 GitHub API로 직접 조회해서 runs.using 값이 node20인지 node24인지 확인했다.

변경 내역

액션	기존	변경 후
actions/checkout	v3, v4	v7
actions/setup-java	v4	v5
actions/cache	v4	v6
actions/setup-node	v3	v6
actions/github-script	v7	v9
aws-actions/configure-aws-credentials	v4	v6

변경 파일

.github/workflows/ci.yml
.github/workflows/gemini_review.yml
.github/workflows/deploy-ec2.yml
.github/workflows/deploy-ecs.yml
.github/workflows/_deploy-wave.yml

추가 작업: Gemini 리뷰 모델 환경변수화

gemini_review.yml에서 하드코딩되어 있던 모델명을 환경변수로 뺐다.

Run Gemini Review 스텝의 env에 GEMINI_MODEL: ${{ vars.GEMINI_MODEL || 'google/gemini-3.1-pro-preview' }} 추가
스크립트 안의 model: "google/gemini-3.1-pro-preview"를 model: process.env.GEMINI_MODEL로 변경
GitHub 저장소 변수(Repository variable) GEMINI_MODEL을 설정하면 그 값을 쓰고, 없으면 기존 기본값을 그대로 사용
변경 파일: .github/workflows/gemini_review.yml

별도 레포인 sanji-infra의 gemini_review.yml(Terraform 코드 리뷰용)에도 동일하게 적용했다.

Run Gemini Review 스텝 env에 GEMINI_MODEL: ${{ vars.GEMINI_MODEL || 'google/gemini-3-flash-preview' }} 추가
스크립트 안의 model: "google/gemini-3-flash-preview"를 model: process.env.GEMINI_MODEL로 변경
이 레포는 기본 모델이 google/gemini-3-flash-preview로, sanji-jk의 gemini_review.yml과는 기본값이 다름
sanji-infra/README.md, sanji-infra/docs/DEPLOY.md에는 모델명이 문서화되어 있지 않아 별도 수정 없음
변경 파일: sanji-infra/.github/workflows/gemini_review.yml

Langfuse 관리자 접근 허용

무엇을 했나

Langfuse(LLM 트레이싱 도구)가 모니터링 EC2 위에 3001 포트로 떠 있지만 보안 그룹에 열려 있지 않아 브라우저로 접근할 수 없던 문제를 해결했다. Grafana(3000)와 같은 방식으로 관리자 IP(admin_cidr)에 3001 포트를 열었다.

바꾼 파일 (sanji-infra 레포)

modules/network/main.tf
- monitoring_in_admin 보안 그룹 규칙의 포트 목록에 3001 추가 (["3000", "3001", "9090", "8080", "22"])
- terraform validate 통과 확인
modules/network/variables.tf, envs/prod/variables.tf, envs/dev/variables.tf
- admin_cidr 변수 설명에 Langfuse 추가
envs/prod/outputs.tf, envs/dev/outputs.tf
- langfuse_url 출력값 추가 (http://<모니터링 EC2 공인 IP>:3001)
docs/DEPLOY.md
- admin_cidr 안내 주석에 Langfuse 추가
- 접속 주소 표에 Langfuse 행 추가
- 트러블슈팅 표의 "Grafana 접속 안 됨" 항목을 "Grafana/Langfuse 접속 안 됨"으로 확장
envs/prod/terraform.tfvars.example
- admin_cidr 안내 주석에 Langfuse 추가

왜 이렇게 했나

RDS/Redis처럼 SSM 포트포워딩으로 접근하는 방법도 검토했으나, Langfuse는 모니터링 EC2 자기 자신에서 도는 서비스라 매번 SSM 세션을 여는 것보다 Grafana처럼 보안 그룹으로 상시 열어두는 방식을 선택했다.

추가 작업: kafka-ui 클러스터 조회 실패 수정

http://<모니터링 EC2>:8080/ui/clusters/prod/all-topics 페이지가 안 뜨는 문제를 진단하고 원인을 고쳤다.

진단 과정

모니터링 EC2 상태, 공인 IP, 보안 그룹의 8080 규칙을 확인 → 전부 정상 (네트워크 문제 아님)
루트 경로(:8080/)가 뜨면서 컨테이너 자체는 살아있음을 확인
SSM으로 모니터링 EC2에 접속해 docker ps, kafka-ui 로그, 컨테이너 실제 환경변수, SSM 파라미터 값을 조회
로그에서 Invalid url in bootstrap.servers: 10.0.1.153 에러 확인

원인

Kafka가 3-브로커 구성으로 바뀌면서 /sanji/prod/kafka/private-ip SSM 값이 10.0.1.153,10.0.1.58,10.0.1.191(콤마로 구분된 IP 3개)이 됐다. 그런데 docker-compose.monitoring.yml의 kafka-ui 설정은 이 문자열 전체 뒤에 :9092를 한 번만 붙이고 있어서, 실제 컨테이너에 주입된 값이 10.0.1.153,10.0.1.58,10.0.1.191:9092가 됐다. 앞의 두 IP에 포트가 없어 kafka-ui가 유효하지 않은 주소로 판단해 "prod" 클러스터 정보를 가져오지 못했다.

Prometheus 설정(scripts/deploy-monitoring.sh)은 이미 IP마다 포트를 따로 붙이는 루프 로직이 있어서 같은 문제가 없었다.

바꾼 파일 (sanji-jk 레포)

scripts/deploy-monitoring.sh
- IP마다 :9092를 붙여 KAFKA_BOOTSTRAP_SERVERS 변수를 새로 만들고 .env에 기록
- 기존 Prometheus용 IP 분리 루프(KAFKA_IPS)를 재사용하도록 위치 조정 (중복 제거)
docker-compose.monitoring.yml
- kafka-ui의 KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS를 ${KAFKA_PRIVATE_IP}:9092 대신 ${KAFKA_BOOTSTRAP_SERVERS}로 변경

bash -n으로 스크립트 문법 확인 완료

Gateway에 Swagger 라우트 추가

배경

배포 환경에서 swagger-ui에 접속할 방법이 없다는 문제가 있었다. ALB는 gateway(8000 포트)로만 트래픽을 보내고, 각 서비스 포트는 보안 그룹에서 ALB/모니터링 EC2 외에는 막혀 있어서 직접 접근이 불가능했다. 임시 방편으로 SSM 포트포워딩(모니터링 EC2를 발판 삼아 터널링)을 고려했지만, 어차피 재배포를 해야하는 것은 똑같았기 때문에 상시 접근 가능한 방식인 "gateway에 swagger 라우트 추가"를 선택했다.

무엇을 했나

gateway-server가 각 서비스의 OpenAPI 문서(/v3/api-docs)를 대신 가져와서, gateway 자체의 swagger-ui 한 화면에서 서비스를 드롭다운으로 골라볼 수 있게 구성했다. swagger-ui 화면 자체는 gateway가 직접 서빙하고, 문서 데이터만 각 서비스로부터 프록시해오는 방식이다. (Spring Cloud Gateway + springdoc 공식 연동 패턴)

바꾼 파일

gateway-server/build.gradle
- springdoc-openapi-starter-webflux-ui:2.8.9 의존성 추가 (gateway는 WebFlux 기반이라 webflux 버전 사용, 각 서비스가 쓰는 springdoc-openapi-starter-webmvc-ui와는 다른 아티팩트)
config-server/src/main/resources/config/gateway-server.yml
- springdoc 의존성을 가진 6개 서비스(auction, bid, order, payment, notification, ai)에 대해 /v3/api-docs/{서비스명} 라우트 추가. SetPath=/v3/api-docs 필터로 실제 서비스가 기대하는 경로로 바꿔서 전달
- springdoc.api-docs.enabled: false 설정 (gateway 자신은 REST API가 없으므로 자체 문서 생성 불필요)
- springdoc.swagger-ui.urls에 6개 서비스 문서 URL 목록 등록
- user-service는 springdoc 의존성이 없어 목록에서 제외
gateway-server/src/main/java/.../config/SecurityConfig.java
- /swagger-ui.html, /swagger-ui/**, /v3/api-docs/**, /webjars/** 경로를 permitAll로 열어서 JWT 없이 문서 화면에 접근 가능하도록 함

확인한 것

./gradlew :gateway-server:compileJava 성공 (새 의존성 정상 해석, 컴파일 문제 없음)

접속 방법 (배포 반영 후)

https://<ALB 주소>/swagger-ui.html 접속 후 화면 우측 상단 드롭다운에서 서비스 선택

LANGFUSE_AUTH_HEADER 운영 배포 연결

무엇을 했나

ai-service가 Langfuse로 트레이싱을 보낼 때 쓰는 LANGFUSE_AUTH_HEADER가 로컬 docker-compose.yml에만 연결되어 있고, 실제 운영 배포(AWS ECS Fargate)에는 전혀 주입되지 않고 있던 문제를 확인하고 연결했다.

확인한 문제

sanji-infra/bootstrap/main.tf의 secret_keys, sanji-infra/modules/ssm/main.tf의 app_secret_paths, sanji-infra/modules/ecs/main.tf의 ai-service 컨테이너 정의(secrets, extra_env) 어디에도 LANGFUSE_AUTH_HEADER/LANGFUSE_HOST가 없었다.
그래서 운영 ai-service 태스크는 application.yml 기본값(빈 문자열)으로 떠 있었고, Langfuse로 트레이싱이 전송되지 않는 상태였다.

바꾼 파일 (sanji-infra 레포)

bootstrap/main.tf
- secret_keys 목록에 "langfuse/auth-header" 추가
modules/ssm/main.tf
- app_secret_paths에 "langfuse-auth-header" = "/${var.project}/${var.environment}/langfuse/auth-header" 추가
modules/ecs/main.tf
- ai-service 블록의 secrets에 LANGFUSE_AUTH_HEADER = "langfuse-auth-header" 추가
- extra_env에 LANGFUSE_HOST = "http://${var.monitoring_private_ip}:3000" 추가
scripts/ssm-init.sh, scripts/ssm-push.sh
- 두 스크립트가 서로 존재하지 않는 파일명(ssm-restore.sh, ssm-backup.sh)을 안내하던 오류 수정 (실제 파일명 ssm-init.sh / ssm-push.sh에 맞게 정리)

진행 중 발견한 별개 문제와 해결

bootstrap 폴더에서 terraform apply를 시도하니 기존 시크릿 14개가 전부 삭제 대상으로 잡히는 에러가 발생했다. 원인은 이전 "dev/prod 환경 분리" 리팩터링에서 SSM 파라미터 키 형식을 keycloak/client-secret → prod/keycloak/client-secret처럼 바꾸면서 terraform state mv를 하지 않아 상태 파일과 코드가 달라졌던 것이었다.

기존 시크릿 14개에 대해 terraform state mv로 상태 파일 내 키 이름만 prod/ 접두사가 붙도록 옮겼고, 이후 terraform plan 결과 16 to add, 0 to change, 0 to destroy로 확인되어 기존 시크릿 값 유실 없이 정리되었다.

추가 수정: LANGFUSE_HOST 포트 오류, 보안 그룹 누락

LANGFUSE_HOST가 잘못된 걸 발견해 고쳤다.

포트 오류: http://${var.monitoring_private_ip}:3000으로 넣었으나, docker-compose.monitoring.yml에서 Langfuse는 "3001:3000"으로 호스트 3001 포트에 매핑되어 있다(컨테이너 내부만 3000). ai-service는 같은 호스트가 아니라 네트워크 너머로 접근하므로 호스트 포트인 3001을 써야 한다. :3001로 수정했다.
보안 그룹 누락: modules/network/main.tf의 monitoring 보안 그룹에는 3001 포트가 admin_cidr(관리자 접근용)에만 열려 있고 ECS 태스크에서의 접근은 허용되어 있지 않았다. monitoring_in_loki_from_ecs(Loki 3100, ECS→모니터링)와 같은 패턴으로 monitoring_in_langfuse_from_ecs 규칙을 추가해 ECS 보안 그룹에서 3001 포트로의 접근을 허용했다.
envs/prod에서 terraform validate 통과 확인.

발견한 개선 방향

Keycloak은 scripts/keycloak-setup.sh로 realm/client-secret을 자동 재설정하지만, Langfuse는 그런 스크립트가 없어서 RDS가 destroy/재생성될 때마다 사람이 직접 Langfuse UI에서 프로젝트를 새로 만들고 LANGFUSE_AUTH_HEADER를 재발급해야 하는 상태다.

찾아보니 Langfuse는 "Headless Initialization" 기능으로 LANGFUSE_INIT_ORG_ID, LANGFUSE_INIT_PROJECT_ID, LANGFUSE_INIT_PROJECT_PUBLIC_KEY, LANGFUSE_INIT_PROJECT_SECRET_KEY, LANGFUSE_INIT_USER_EMAIL, LANGFUSE_INIT_USER_PASSWORD 환경변수를 지원한다. 이 값들을 SSM에 고정값으로 미리 넣고 docker-compose.monitoring.yml의 langfuse 서비스에 주입하면, 컨테이너가 뜰 때마다 같은 프로젝트/키를 자동으로 재생성해서 Keycloak의 수동 스크립트 없이도 LANGFUSE_AUTH_HEADER 값이 영구 고정된다.

추가 작업: Headless Initialization 구현

위 개선 방향을 실제로 적용했다. Langfuse 소스 코드(web/src/initialize.ts, web/src/env.mjs)를 직접 확인해 LANGFUSE_INIT_PROJECT_PUBLIC_KEY/SECRET_KEY에 형식 검증이 없음(임의 문자열 허용)을 확인한 뒤 아래와 같이 반영했다.

sanji-infra/bootstrap/main.tf: secret_keys에 langfuse/public-key, langfuse/secret-key, langfuse/init-user-password 추가
sanji-infra/modules/ssm/main.tf: app_secret_paths에 동일한 3개 경로 추가
scripts/deploy-monitoring.sh: 위 3개 값을 SSM에서 조회해 .env에 기록하도록 추가
docker-compose.monitoring.yml: langfuse 서비스에 LANGFUSE_INIT_* 9개 변수 추가. 조직/프로젝트 ID는 sanji/sanji-ai로 고정, 관리자 이메일은 admin@sanji.local로 고정, 공개키/비밀키/비밀번호는 .env에서 주입
sanji-infra/docs/DEPLOY.md: SSM 파라미터 표에 3개 행 추가, "6-3. Langfuse 설정" 섹션 신설 (뒤 섹션 번호 6-3 -> 6-4로 밀림), 기존 "6-3단계" 오탈자를 "6-2단계"로 수정

terraform validate(bootstrap, envs/prod)와 bootstrap terraform plan(6 to add, 0 to change, 0 to destroy)으로 기존 값 손실 없이 반영됨을 확인했다.

ssm-push CHANGE_ME 확인 절차 추가

작업 내용

sanji-infra/scripts/ssm-push.sh에서 파라미터 값이 CHANGE_ME인 경우, 기존에는 그냥 건너뛰기만 하고 넘어갔다.
이제는 실제로 파라미터를 적용하기 전에 CHANGE_ME로 남아있는 파라미터 목록을 먼저 보여주고, 사용자가 yes를 입력해야만 다음 단계로 진행하도록 변경했다.

동작 방식

백업 파일(ssm-backup.json)을 한 번 먼저 훑어서 값이 CHANGE_ME인 파라미터 이름을 모두 수집한다.
하나라도 있으면 아래 형식으로 출력하고 입력을 기다린다.

아래 파라미터 값이 CHANGE_ME로 지정되어 있습니다.
- /sanji/prod/...

그래도 진행하시겠습니까?
- Only enter 'yes' to continue:

yes가 아니면 스크립트를 중단한다(종료 코드 1).
yes를 입력하면 기존 로직대로 파라미터를 하나씩 처리하며, CHANGE_ME인 파라미터는 여전히 건너뛴다(값을 실수로 덮어쓰지 않기 위함).

변경 파일

sanji-infra/scripts/ssm-push.sh

3주차 3일차 작업일지 (0701)

munsik22 — Thu, 2 Jul 2026 10:04:18 +0900

keycloak-setup.sh 자동화

작업 내용

keycloak-setup.sh를 메인 레포로 이동하고, Deploy EC2 워크플로우에 자동 실행 스텝을 추가했다.

변경 파일

생성

scripts/keycloak-setup.sh
- sanji-infra의 동일 스크립트를 가져와서 아래 사항 수정
- aws.exe -> aws (GitHub Actions runner는 Linux)
- tr -d '\r' 제거 (Windows 전용)
- REGION 환경변수 주입 지원 (REGION:-ap-northeast-2 폴백)
- INSTANCE_ID 환경변수 주입 지원 (없으면 AWS CLI로 자동 조회)
- 멱등 처리 추가: sanjijk realm이 이미 Keycloak DB에 있으면 SKIP:realm_exists 출력 후 종료

수정

.github/workflows/deploy-ec2.yml
- Setup Keycloak realm and client secret 스텝 추가
- 조건: inputs.target != 'kafka' (monitoring 또는 both 배포 시에만 실행, push 트리거 포함)
- 모니터링 EC2 배포 완료 직후 실행되어 realm-export.json 배포 순서 보장
sanji-infra/README.md
- 3번(재배포 절차)에서 수동 실행 안내 제거, 자동 처리 설명으로 교체
- 파일 구성 목록에서 keycloak-setup.sh 항목 삭제
sanji-infra/docs/DEPLOY.md
- 6-2 Keycloak 설정 절 수동 실행 → 자동 처리로 교체
- 체크리스트 9번 자동 처리로 교체

삭제

sanji-infra/scripts/keycloak-setup.sh

추가 수정 (코드 리뷰 반영)

scripts/keycloak-setup.sh
- [치명적 버그] STATUS=$((...)) → STATUS=$(...) (산술 확장 오용으로 스크립트 강제 종료됨)
- [보안] client-secret을 stdout에 평문 출력하던 방식 제거, EC2에서 SSM에 직접 저장하도록 변경
- [보안] admin 패스워드를 -d "password=..." 방식 → --data-urlencode 방식으로 변경 (특수문자 대응)
- [버그] aws ecs list-tasks에 --desired-status RUNNING 추가 (STOPPED 태스크 반환 방지)
- [유지보수] ECS_CLUSTER, KEYCLOAK_REALM, KEYCLOAK_CLIENT_ID, SSM_PARAM_ADMIN_PASSWORD 하드코딩 → 환경변수 + 기본값으로 변경
- [유지보수] TimedOut 상태 처리 추가, --timeout-seconds 600 send-command에 명시
scripts/keycloak-setup.sh (2차 리뷰 반영)
- [버그] CLIENT_UUID, NEW_SECRET null/빈 문자열 검증 누락 → put-parameter 전 방어 로직 추가
- [버그] 폴링 루프 seq 1 60 (300초) → seq 1 120 (600초)로 send-command 타임아웃과 동기화
- [개선] realm import HTTP 응답 코드 != "201" → < 200 || >= 300 (2xx 전체 허용)
sanji-infra/modules/iam/main.tf
- EC2 IAM 역할에 ssm:PutParameter 추가 (경로: /{project}/*/keycloak/client-secret)
- EC2 IAM 역할에 kms:GenerateDataKey 추가 (SecureString PutParameter에 필요)

추가 수정 (보안 그룹 누락 발견)

sanji-infra/modules/network/main.tf
- ecs_in_from_monitoring 규칙에 포트 18080 추가
- Keycloak은 ECS 퍼블릭 서브넷에 있고 포트 18080을 씀
- 기존 규칙에 18080이 빠져 있어 모니터링 EC2에서 Keycloak API를 호출할 수 없었음

멱등성 동작 정리

상황	동작
최초 배포 / destroy 후 재배포	realm 없음 → import + client-secret 발급 + SSM 저장
일반 main push (모니터링 재배포)	realm 이미 존재 → SKIP, SSM 건드리지 않음

Kafka Producer / 복제 계수 설정 추가

동료 코드 리뷰를 통해 Kafka 3중 브로커 구성에서 누락된 설정 두 가지를 발견했다.

발견된 문제

문제 1. Producer `acks`, `retries` 누락

영향 서비스: bid-service, auction-service

acks=all 없으면: 리더 브로커 1개가 응답하면 전송 완료로 간주. 팔로워 복제 전에 리더 장애 발생 시 입찰 이벤트 데이터 소실 가능
retries 없으면: 브로커 리더 교체 중 일시적 실패 시 재시도 없이 이벤트 발행 실패 (Kafka 3.7 기본값은 Integer.MAX_VALUE이나 명시적으로 설정하는 것이 안전)

현재 코드:

# bid-service, auction-service 공통 - acks/retries 없음
spring:
  kafka:
    producer:
      key-serializer: ...
      value-serializer: ...

문제 2. 복제 계수 환경변수 누락

영향 파일: docker-compose.kafka.yml, docker-compose.kafka-local.yml

KAFKA_DEFAULT_REPLICATION_FACTOR 미설정 시 토픽이 기본값 replication-factor=1로 생성됨
브로커 3대 구성의 의미가 없어지고, 해당 브로커 1대 장애 시 토픽 접근 불가
내부 토픽(__consumer_offsets, 트랜잭션 로그)도 동일 문제

작업 내역

bid-service producer 설정 추가

파일: services/bid-service/src/main/resources/application.yml

spring:
  kafka:
    producer:
      acks: all      # 추가
      retries: 3     # 추가

auction-service producer 설정 추가

파일: services/auction-service/src/main/resources/application.yml

spring:
  kafka:
    producer:
      acks: all      # 추가
      retries: 3     # 추가

프로덕션 Kafka 복제 계수 설정 추가

파일: docker-compose.kafka.yml

KAFKA_DEFAULT_REPLICATION_FACTOR: 3
KAFKA_MIN_INSYNC_REPLICAS: 2
KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 3
KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 3
KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 2

ECS 가중치(Fargate Spot) 조정

변경 내용

sanji-infra/modules/ecs/main.tf

aws_ecs_cluster_capacity_providers: FARGATE에 base=1 추가, FARGATE_SPOT weight=3 블록 신규 추가
aws_ecs_service.app (일반 서비스 9개): launch_type = "FARGATE" 제거 + capacity_provider_strategy 블록 2개 추가
- FARGATE base=1 weight=1
- FARGATE_SPOT weight=3
aws_ecs_service.bid, aws_ecs_service.keycloak: 변경 없음 (launch_type = "FARGATE" 유지)

결정 사항

bid: WebSocket 장기 연결 서비스라 Spot 회수 시 STOMP 세션 전체 끊김 -> On-Demand 고정
keycloak: 인증 서버라 태스크 중단 시 로그인 전체 불가 -> On-Demand 고정
일반 App 9개: desired_count=1이면 base=1로 On-Demand로 뜸, 향후 스케일아웃 시 추가 태스크부터 Spot 배분

비고

launch_type을 명시하면 클러스터 기본 Capacity Provider 전략을 우회해 Spot이 아예 쓰이지 않는다.
서비스 레벨에서 capacity_provider_strategy로 교체해야 실제 Spot이 적용된다.

코드 리뷰 반영 (Fargate Spot 구조 개선)

변경 내용

sanji-infra/modules/ecs/variables.tf

fargate_on_demand_base 변수 추가 (prod 기본값 1, dev는 환경 폴더에서 0으로 재정의)
fargate_spot_weight 변수 추가 (기본값 3)

sanji-infra/modules/ecs/main.tf

aws_ecs_cluster_capacity_providers: base/weight 하드코딩을 변수로 교체
aws_ecs_service.app: 서비스 레벨 capacity_provider_strategy 블록 제거 (클러스터 기본 전략 위임으로 중복 제거)
base 동작 설명 주석 추가

sanji-infra/envs/dev/variables.tf

fargate_on_demand_base = 0 (100% Spot)
fargate_spot_weight = 3

sanji-infra/envs/prod/variables.tf

fargate_on_demand_base = 1 (On-Demand 1대 보장)
fargate_spot_weight = 3

sanji-infra/envs/dev/main.tf, sanji-infra/envs/prod/main.tf

ecs 모듈 호출에 fargate_on_demand_base, fargate_spot_weight 전달

코드 리뷰 반영 2차 (서비스 레벨 명시 복원 + 100% Spot)

변경 내용

sanji-infra/modules/ecs/variables.tf

fargate_on_demand_weight 변수 추가 (기본값 1)

sanji-infra/modules/ecs/main.tf

aws_ecs_cluster_capacity_providers: FARGATE weight를 var.fargate_on_demand_weight로 교체
aws_ecs_service.app: capacity_provider_strategy 블록 재추가 (의도 명시 목적)

sanji-infra/envs/dev/variables.tf

fargate_on_demand_weight = 0 (FARGATE weight=0으로 100% Spot)

sanji-infra/envs/prod/variables.tf

fargate_on_demand_weight = 1

sanji-infra/envs/dev/main.tf, sanji-infra/envs/prod/main.tf

ecs 모듈 호출에 fargate_on_demand_weight 추가 전달

결정 사항

weight=0은 AWS ECS API 기준 유효한 값 (범위 0~1000, 단 전략 내 하나 이상은 weight > 0 필요)
dev: FARGATE weight=0 → 태스크 배치 대상 제외 → 100% FARGATE_SPOT
서비스 레벨 strategy는 클러스터 기본값과 동일하더라도 명시적으로 유지 (서비스 코드만 봐도 Spot 여부 파악 가능)

terraform apply 에러 수정 (bash 경로 + 스크립트 경로)

증상

envs/prod에서 terraform apply 실행 시 null_resource.db_schema_init local-exec 에러 발생

Error running command 'bash ./scripts/db-schema-init.sh': exec: "/bin/bash": executable file not found in %PATH%.

원인

interpreter = ["/bin/bash", "-c"] - Windows에 /bin/bash 경로 자체가 없음
command = "bash ${path.root}/scripts/db-schema-init.sh" - 모듈 안에서 path.root는 envs/prod/를 가리키므로 envs/prod/scripts/db-schema-init.sh를 찾지만, 실제 스크립트는 sanji-infra/scripts/에 있음

변경 내용

sanji-infra/modules/data/main.tf

interpreter = ["/bin/bash", "-c"] 제거 후 interpreter = [var.bash_path]로 교체
command = "bash ${path.root}/scripts/..." → command = "${path.module}/../../scripts/db-schema-init.sh" (path.module = modules/data/ 절대경로 기준으로 올바르게 위치 지정)

sanji-infra/modules/data/variables.tf

bash_path 변수 추가 (기본값 /bin/bash)

sanji-infra/envs/prod/variables.tf, sanji-infra/envs/dev/variables.tf

bash_path 변수 추가

sanji-infra/envs/prod/main.tf, sanji-infra/envs/dev/main.tf

module "data"에 bash_path = var.bash_path 전달

sanji-infra/envs/prod/terraform.tfvars.example

Windows 로컬 실행 방법 주석 추가

sanji-infra/docs/INTRODUCTION.md

section 9 코드 예시를 수정 후 코드로 업데이트, path.module vs path.root 차이 및 bash_path 사용법 설명 추가

sanji-infra/docs/DEPLOY.md

section 11 자주 겪는 문제 표에 /bin/bash 에러 + 해결법 항목 추가

조치

sanji-infra/envs/prod/terraform.tfvars에 아래 한 줄 추가 필요 (Windows 로컬 실행 시)

bash_path = "C:/Program Files/Git/bin/bash.exe"

Deploy EC2 kafka 배포 실패 수정 (SSM 다중 인스턴스 처리)

증상

GitHub Actions run #28494220661 Send deploy command via SSM 단계 실패

ValidationException: Value 'i-xxx\ti-yyy\ti-zzz' at 'instanceId' failed to satisfy constraint:
Member must satisfy regular expression pattern: (^i-(\w{8}|\w{17})$)

원인

send_and_wait 함수가 aws ec2 describe-instances --output text로 인스턴스 ID를 조회할 때 Kafka 3대의 ID가 탭 구분으로 한 변수에 들어온다.
aws ssm wait command-executed --instance-id 는 ID 하나만 받으므로 ValidationException 발생했다.

변경 내용

.github/workflows/deploy-ec2.yml

send_and_wait 함수의 인스턴스 ID 조회를 --output json | jq -r '.[]' + mapfile -t 배열로 변경
인스턴스별 wait/상태확인/로그출력을 루프(for iid in "${instance_ids[@]}")로 처리
어느 인스턴스라도 실패하면 overall_status에 기록 후 루프 완료 시 return 1

docs/CD.md

Kafka 다중 인스턴스 SSM 처리 방식 설명 추가
KAFKA_PRIVATE_IP SSM 포맷 설명 업데이트 (포트 없는 IP 목록)

Prometheus kafka 타겟 오류 수정 (bootstrap_servers → IP 전용)

증상

Grafana Prometheus 타겟 페이지에서 kafka job 전체 DOWN

Get "http://10.0.1.117:9092,10.0.1.137:9092,10.0.1.169:9092:9100/metrics":
dial tcp: too many colons in address

원인

SSM /sanji/prod/kafka/private-ip 파라미터에 kafka_bootstrap_servers 값(10.0.1.117:9092,10.0.1.137:9092,10.0.1.169:9092)이 저장되어 있었다.
deploy-monitoring.sh가 이 값을 단일 IP처럼 취급해 :7071, :9100을 덧붙이면서 잘못된 주소(IP:9092,...:9100)가 만들어졌다.

변경 내용

sanji-infra/modules/ssm/variables.tf

kafka_bootstrap_servers 변수명 → kafka_private_ips로 변경 (포트 없는 IP만 저장 의미 명시)

sanji-infra/modules/ssm/main.tf

aws_ssm_parameter.kafka_private_ip value: var.kafka_bootstrap_servers → var.kafka_private_ips

sanji-infra/envs/prod/main.tf, sanji-infra/envs/dev/main.tf

module "ssm" 호출: kafka_bootstrap_servers = module.compute_ec2.kafka_bootstrap_servers → kafka_private_ips = join(",", module.compute_ec2.kafka_private_ips)

scripts/deploy-monitoring.sh

envsubst를 제거하고 루프 + here-doc으로 prometheus.prod.yml 직접 생성
각 IP 주소에서 ${addr%%:*}로 포트를 벗겨냄 (SSM 포맷에 관계없이 안전하게 처리)

sanji-infra/docs/DEPLOY.md

"Prometheus kafka 타겟 Down" 문제 설명 업데이트

조치

envs/prod에서 terraform apply (SSM 파라미터 포맷 갱신)
Deploy EC2 워크플로우 재실행 (prometheus.yml 재생성)

참고: ecs-apps DOWN은 별도 이슈 아님

ECS 배포 직후 태스크가 새 IP로 교체되면서 ecs-targets.json에 예전 IP가 남아 "no route to host"이 발생했는데, ecs-discovery.sh cron이 5분마다 자동 갱신하므로 조금만 기다리면 UP으로 알아서 바뀐다.

Deploy EC2 실패 수정 (ecs:ListTasks IAM 권한 부족)

증상

GitHub Actions Deploy EC2 run #28491781498 에서 Setup Keycloak realm and client secret 단계 실패

AccessDeniedException when calling the ListTasks operation:
... is not authorized to perform: ecs:ListTasks
on resource: arn:aws:ecs:ap-northeast-2:598537771389:container-instance/sanji-prod-cluster/*

원인

modules/iam/main.tf의 EcsDeployService 정책이 ecs:ListTasks를 service/*, task/* ARN에만 허용한다.
aws ecs list-tasks --cluster ... --service-name keycloak 호출 시 AWS가 container-instance/와 cluster/ ARN에 대해서도 권한을 확인하는데, 이 두 ARN이 resource 목록에 빠져 있었다.

변경 내용

sanji-infra/modules/iam/main.tf

EcsDeployService statement의 resources에 두 항목을 추가했다.

arn:aws:ecs:...:cluster/${var.name}-cluster
arn:aws:ecs:...:container-instance/${var.name}-cluster/*

조치

envs/prod에서 terraform apply로 IAM 정책 반영 후 Deploy EC2 워크플로우를 재실행했다.

terraform plan 경고 제거 (cpu_core_count deprecated)

증상

envs/prod에서 terraform plan 실행 시 아래 경고가 발생했다.

Warning: Deprecated value used
  on ..\..\modules\compute-ec2\outputs.tf line 3, in output "kafka_instances":
   3:   value = aws_instance.kafka
The deprecation originates from module.compute_ec2.aws_instance.kafka[0].cpu_core_count

원인

kafka_instances output이 aws_instance.kafka 전체 객체를 그대로 내보내고 있었다.
aws_instance 객체 안에 AWS 프로바이더가 deprecated 처리한 cpu_core_count 속성이 포함되어 있어 경고가 발생했다.

변경 내용

sanji-infra/modules/compute-ec2/outputs.tf

kafka_instances value를 전체 객체 aws_instance.kafka에서 [for i in aws_instance.kafka : { id = i.id }]로 교체
호출하는 쪽(envs/dev/main.tf, envs/prod/main.tf)은 .id만 쓰고 있어 수정 없이 동작함

Deploy EC2 kafka 배포 실패 수정 (ec2:DescribeTags IAM 권한 부족)

증상

GitHub Actions run #28494525772 Send deploy command via SSM 단계 실패

An error occurred (UnauthorizedOperation) when calling the DescribeTags operation:
... is not authorized to perform: ec2:DescribeTags because no identity-based policy allows the ec2:DescribeTags action

원인

scripts/deploy-kafka.sh가 EC2 태그에서 KafkaNodeId 값을 읽기 위해 ec2:DescribeTags를 호출하는데, Kafka EC2 인스턴스 역할 sanji-prod-ec2-role에 해당 권한이 없었다.

변경 내용

sanji-infra/modules/iam/main.tf

ec2_grafana_ec2 정책의 Action 목록에 ec2:DescribeTags 추가

sanji-infra/docs/DEPLOY.md

자주 겪는 문제 표에 ec2:DescribeTags 에러 항목 추가

조치

envs/prod에서 terraform apply 후 Deploy EC2 워크플로우 재실행 (kafka 대상)

배포 환경에서 경매가 진행중 상태로 안 바뀌는 문제

증상

배포 환경(prod)에서 경매 시작 시간이 지나도 경매 상태가 READY(대기중)에서 PROGRESS(진행중)로 바뀌지 않았다.

원인 조사

코드 확인 내용

경매 상태를 시간에 맞춰 자동으로 바꾸는 코드는 services/auction-service에 있다.

AuctionScheduleManager: 경매 시작 시간이 되면 실행할 작업을 서버 메모리에 등록해두는 역할
AuctionSchedulerJobService.startAuction(): 실제로 READY를 PROGRESS로 바꾸는 함수
AuctionScheduleRecovery: 서버가 다시 켜졌을 때, 놓친 예약 작업을 다시 등록하는 역할. 다만 이미 시작 시간이 지난 READY 경매는 경고 로그만 남기고 다시 시작시키지 않음
AuctionRecoveryScheduler: 5분마다 도는 감시 작업. 그런데 이 작업은 종료 시간이 지난 PROGRESS 경매만 확인하고, 시작 시간이 지난 READY 경매는 확인하지 않음

이 부분(READY 경매를 감시하는 로직이 없음)은 코드상 확인된 사실이지만, 이번에 실제로 이게 원인인지는 아직 확인하지 못했다.

AWS 실제 상태 확인 (aws cli 사용)

auction-service는 ECS에 인스턴스 1개로만 떠 있음 (desiredCount=1). 여러 인스턴스 때문에 문제가 생긴다는 가설은 이걸로 배제됨
이 인스턴스는 오늘 03:56 UTC(12:56 KST)에 새로 시작됨
이 인스턴스 로그에 Kafka 서버 3대 전부에 연결이 안 된다는 경고가 계속 찍히고 있음
Kafka EC2 3대의 실제 사설 IP와 로그에 나온 IP는 일치함 (IP 설정 문제는 아님)
Kafka EC2 3대는 오늘 03:21 UTC에 새로 켜진 것으로 확인됨 (auction-service 재시작 35분 전)
코드상 경매 시작 시 Kafka로 직접 메시지를 보내지 않고 DB(Outbox 테이블)에만 저장하므로, Kafka 연결 실패가 상태 변경 자체를 막는 구조는 아닌 것으로 보임. 다만 아직 확정된 결론은 아님

원인 확정 (타임존 미설정)

재확인 계기

서버 재시작과 무관하게 경매 시작 시간을 몇 분 뒤로 바꾼 뒤에도 상태가 안 바뀌는 것을 확인했다. 이걸로 앞서 세운 "서버 재시작 때문에 예약이 사라짐" 가설은 폐기했다.

확인 방법

CloudWatch 로그에서 실제 경매 ID(019f1c1d-4654-7f4d-845d-71bc4ae69e7b)로 필터링해서 확인했다.

예약 등록 로그(AuctionScheduleManager)는 여러 번 찍힘. 가장 최근 건: 05:42:33 UTC에 등록, 목표 시간(scheduledAt)은 "14:43"
실제 실행 로그(AuctionSchedulerJobService)는 로그 전체 기록을 통틀어 단 한 번도 없음
확인 시점(05:45 UTC)은 목표 시간(14:43)을 이미 지난 상태였는데도 실행 안 됨

원인

배포 환경(ECS)에 타임존 설정이 없어서, 서버가 시간을 한국시간이 아니라 UTC로 인식하고 있었다.

로컬(docker-compose.yml)의 auction-service에는 TZ: Asia/Seoul이 설정되어 있음
배포 환경(ECS 태스크 정의)에는 TZ 환경변수가 없음
Dockerfile에도 -Duser.timezone 같은 설정이 없음
베이스 이미지(eclipse-temurin:21-jre-alpine)의 기본 시간대는 UTC

경매 시작 시간은 시간대 정보 없이 숫자만(예: "14:43") 저장된다. 로컬은 서버가 이걸 한국시간으로 알아서 맞게 처리하지만, 배포 환경은 서버가 이걸 UTC로 알아버려서 실제로는 한국시간 밤 23:43(9시간 뒤)로 예약된다. 그래서 사용자가 아무리 기다려도 경매가 시작되지 않는 것처럼 보인다.

조치

변경 내용

sanji-infra/modules/ecs/main.tf

common_env에 TZ = "Asia/Seoul" 추가 (일반 서비스 9개 + bid-service에 공통 적용)

발견한 문제: apply만으로는 실제 반영 안 됨

aws_ecs_service(app, bid)의 lifecycle { ignore_changes = [desired_count, task_definition] } 때문에, terraform apply로 새 리비전이 "등록"만 되고 실제 서비스는 여전히 옛 리비전을 쓴다. 서비스별로 aws ecs update-service --task-definition <새 리비전>을 직접 해줘야 반영된다.

결과

Wave 1(config-server, discovery-server, gateway-server): update-service로 새 리비전 전환 완료, wait services-stable로 안정화 확인
Wave 2 이후(user, auction, order, payment, bid, notification, ai, 총 7개): 권한 정책에 막혀서 진행 못함 ("CI/CD 파이프라인을 안 거치고 직접 update-service 반복 실행"이 사용자의 일반적인 승인 범위를 넘는다는 이유). 사용자와 다음 진행 방법 논의 중

CI/CD 배포 로직 구조적 결함 발견 및 수정

문제

_deploy-wave.yml의 배포 로직이 "서비스에 지금 붙어있는 태스크 정의"를 베이스로 복사해서 이미지 태그만 SHA로 교체하는 방식이었다. 이 때문에 Terraform이 환경변수(TZ 등)나 cpu/memory 같은 걸 바꿔도, 배포할 때마다 옛 정의(변경 전)를 계속 복제하게 되어 영원히 반영이 안 된다.

과거 작업일지 확인 결과, 이 방식은 "terraform apply가 CI/CD가 올려둔 최신 이미지 리비전을 옛 걸로 되돌리는 문제"를 막기 위해 일부러 만든 것이었다. 그 의도 자체는 맞지만, 구현 방법("현재 붙어있는 정의"를 베이스로 삼음) 때문에 이런 부작용이 생긴 것으로, 그때는 검토가 안 됐던 것으로 보인다.

변경 내용

.github/workflows/_deploy-wave.yml

deploy_one() 함수에서 aws ecs describe-services로 "서비스에 현재 붙어있는 정의"를 조회하던 부분을 제거
대신 family 이름(sanji-prod-{서비스명})으로 aws ecs describe-task-definition을 호출해서 "Terraform이 등록한 최신 리비전"을 베이스로 삼도록 변경
이제부터는 Terraform이 바꾸는 모든 설정이 다음 배포 때 자동으로 반영됨 (수동 동기화 불필요)

Kafka 브로커 3대 연결 불가 원인 조사 및 수정

증상

auction-service 로그에 Kafka 브로커 3대 전부 연결 실패(could not be established)가 계속 찍혔다. Deploy EC2(kafka 대상)를 재실행해도 컨테이너는 정상 기동됐지만 연결 실패 문제는 해결되지 않았다.

확인 과정

Kafka EC2 3대 모두 docker ps로 컨테이너 정상 기동 확인 (재시작 반복 없음)
9092 포트는 3대 모두 호스트에서 정상 리스닝 확인 (ss -tlnp, docker port)
컨테이너 로그 확인 결과, 3대가 서로 9093(RAFT 컨트롤러 포트)으로 계속 연결 실패 중
ss -tlnp에 9093 리스닝 자체가 없음 (호스트에 노출 안 됨)

원인

docker-compose.kafka.yml의 ports에 9092, 7071만 매핑되어 있고 9093이 빠져 있었다. 보안그룹은 9093을 이미 허용하고 있었지만, 실제 컨테이너-호스트 포트 매핑이 없어서 브로커 3대(서로 다른 EC2)가 RAFT quorum을 영원히 형성 못하는 상태였다.

변경 내용

docker-compose.kafka.yml

ports에 9093:9093 추가

Deploy ECS 서비스 선택 수동 배포 추가

변경 내용

.github/workflows/deploy-ecs.yml

workflow_dispatch.inputs.services 추가 (공백 구분 서비스 목록, 비워두면 전체 10개)
plan 잡 추가: 입력값을 받아서 전체 목록 + wave별 목록으로 나눠 출력
build 잡: 선택된 서비스 이미지만 빌드/push하도록 변경
wave 1~4 잡: 선택된 서비스가 하나도 없는 wave는 스킵, success() 조건 추가로 앞 wave 실패 시 이후 wave도 중단

[Computational Thinking] 논리와 증명

munsik22 — Tue, 30 Jun 2026 20:43:10 +0900

문제 1

문제 2

문제 3

문제 4

문제 5

문제 6

문제 7

문제 8

문제 9

문제 10

문제 11

문제 12

문제 13

문제 14

문제 15

문제 16

문제 17

문제 18

문제 19

문제 20

문제 21

문제 22

문제 23

3주차 2일차 작업일지 (0630)

munsik22 — Tue, 30 Jun 2026 15:04:47 +0900

로컬 Docker Compose를 이용한 KRaft 3-브로커 클러스터 동작 검증

작업 내용

로컬 테스트용 Docker Compose 작성: docker-compose.kafka-local.yml 생성
- apache/kafka:3.7.0 이미지 사용
- 브로커 3대(node 1, 2, 3) 구성
- KRaft 모드(Zookeeper-less) 설정 적용
클러스터 형성 검증:
- kafka-metadata-quorum.sh를 통해 3개 노드가 투표자(Voter)로 정상 등록됨을 확인
데이터 무결성 검증:
- 복제 계정(replication-factor) 3인 토픽 생성 및 메시지 발행/소비 성공
가용성(High Availability) 검증:
- 현재 리더 브로커를 docker stop으로 강제 종료
- 나머지 2개 브로커가 자동으로 새로운 리더를 선출함 확인
- 리더 장애 상황에서도 데이터 소비가 중단 없이 가능함을 확인

결과

로컬 환경에서 KRaft 3중화 설정이 올바름을 검증 완료
이를 토대로 AWS EC2 3중화 작업을 진행할 수 있는 기반 마련

생성 데이터

docker-compose.kafka-local.yml: 로컬 검증용 설정 파일 (프로젝트 루트)

AWS 환경 Kafka 3-브로커(KRaft HA) 구성

변경 사항 세부 내용

1. EC2 인스턴스 3대로 확장

파일: ec2.tf
기존: count 선언 없이 1대만 프로비저닝하고 태그 이름이 고정적(sanji-kafka)
변경: count = 3을 선언하여 인스턴스를 3대로 확장. 각 인스턴스의 태그를 인덱스를 사용하여 sanji-kafka-1, sanji-kafka-2, sanji-kafka-3 형태로 변경하고, 스크립트에서 컨테이너 ID를 파악할 수 있도록 KafkaNodeId 태그(1, 2, 3)를 추가 설정함

2. 보안 그룹(Security Group) 규칙 추가

파일: security_groups.tf
변경: 브로커 간 내부 통신용 규칙(kafka_in_self) 추가
- 프로토콜: all (-1)
- 소스: 자기 자신(kafka SG)
- 설명: Quorum(9093) 및 데이터(9092) 통신을 위해 3대의 브로커가 서로 통신할 수 있도록 내부 방화벽을 엶

3. SSM Parameter Store 변경

파일: ssm.tf
기존: private-ip를 단일 값으로 저장
변경:
1. kafka_private_ip: 애플리케이션 서비스들(Application.yml의 KAFKA_BOOTSTRAP_SERVERS)이 바라볼 수 있도록 3대의 IP 주소를 쉼표로 연결(ip1:9092,ip2:9092,ip3:9092 형태)하는 로직으로 변경
2. kafka_quorum_voters 파라미터 신규 추가: KRaft 컨트롤러 투표자 구성을 위해 1@ip1:9093,2@ip2:9093,3@ip3:9093 형태의 리스트 값을 만들어 저장

4. 배포용 스크립트 수정

파일: scripts/deploy-kafka.sh
변경: SSM을 통해 가져오는 파라미터 로드에 KAFKA_CONTROLLER_QUORUM_VOTERS 추가. 또한, 여러 개의 EC2에서 공통으로 사용되는 스크립트이므로, aws ec2 describe-tags 명령어를 추가해 자신의 InstanceId에 해당하는 KafkaNodeId 값을 읽어 .env의 KAFKA_NODE_ID로 기록하도록 수정

5. Docker Compose 파일 수정

파일: docker-compose.kafka.yml
기존: 브로커 1대 기준으로 KAFKA_NODE_ID: 1, KAFKA_CONTROLLER_QUORUM_VOTERS: 1@localhost:9093 설정 사용
변경: 배포 스크립트에서 자동 주입(KAFKA_NODE_ID: ${KAFKA_NODE_ID}, KAFKA_CONTROLLER_QUORUM_VOTERS: ${KAFKA_CONTROLLER_QUORUM_VOTERS})받아 동작하도록 변수 처리

코드 리뷰 반영

변경 파일: `scripts/deploy-kafka.sh`

1. 불필요한 MAC_MAC 변수 제거

기존: IMDS에서 MAC 주소를 조회해 MAC_MAC 변수에 저장
변경: 스크립트 내에서 전혀 사용되지 않는 변수이므로 해당 줄 삭제. 불필요한 네트워크 요청 제거

2. 필수 변수 Fail-fast 검증 로직 추가

기존: AWS 명령어 결과가 빈 문자열이거나 None이어도 그대로 .env에 기록한 뒤 컨테이너 실행
변경: .env 생성 전, KAFKA_PRIVATE_IP / KAFKA_NODE_ID / KAFKA_CLUSTER_ID / KAFKA_CONTROLLER_QUORUM_VOTERS 4개 변수를 순서대로 확인. 하나라도 비어 있거나 None이면 에러 메시지를 출력하고 즉시 exit 1로 배포 중단

3. KAFKA_NODE_ID Fallback 기본값 제거

기존: .env 작성 시 KAFKA_NODE_ID=${KAFKA_NODE_ID:-1} 형태로 조회 실패 시 기본값 1 강제 할당
변경: Fail-fast 검증 통과 후에만 .env를 생성하므로 기본값 표현식 불필요. KAFKA_NODE_ID=${KAFKA_NODE_ID} 로 단순화. 3-브로커 환경에서 중복 Node ID로 인한 클러스터 장애 예방

Terraform 모듈화

개요

Terraform 루트에 평평하게 펼쳐진 .tf 파일들을 6개 모듈로 분리했다.

만들어진 모듈 구조

root/modules/
  network/        VPC, 서브넷, IGW, 라우팅 테이블, 보안 그룹 전체
  edge/           ALB, 대상 그룹, HTTP/HTTPS 리스너
  data/           RDS(PostgreSQL), ElastiCache(Redis), DB 스키마 초기화
  compute-ec2/    Kafka EC2 3대, 모니터링 EC2
  ecs/            ECR, ECS 클러스터, 서비스 9개 + bid + keycloak
  observability/  CloudWatch 경보, SNS 알림

루트에 남은 파일

파일	이유
`iam.tf`	ECS, EC2, GitHub Actions 역할이 모두 얽혀 있어 루트에 유지
`ssm.tf`	compute-ec2, data 두 모듈 출력을 동시에 참조해서 루트에 유지
`locals.tf`	`name` 접두사 한 줄만 남음
`variables.tf`	변경 없음
`outputs.tf`	모듈 출력을 참조하도록 전면 재작성
`main.tf`	provider + data sources + 모듈 6개 호출

삭제된 루트 파일 (모듈로 이동)

network.tf, security_groups.tf, alb.tf, rds.tf, elasticache.tf,
ec2.tf, ecs_cluster.tf, ecs_services.tf, ecs_bid.tf, ecs_keycloak.tf,
ecr.tf, cloudwatch.tf

함께 수정한 버그

기존 코드에서 aws_instance.kafka.private_ip를 단일 값으로 쓰던 부분이 Kafka 3중화(count = 3) 이후 깨져 있었다. 모듈화하면서 compute-ec2 모듈의 kafka_bootstrap_servers output에서 3대 IP를 쉼표로 합쳐 출력하고, ecs 모듈이 이 값을 SPRING_KAFKA_BOOTSTRAPSERVERS 환경변수로 받도록 고쳤다.

검증 결과

terraform init -backend=false  # 성공
terraform validate              # Success! The configuration is valid.

코드 리뷰 반영

1. `modules/data/main.tf`: null_resource 트리거에 스크립트 해시 추가

db-schema-init.sh 파일을 수정해도 null_resource가 재실행되지 않는 문제를 수정했다.

triggers = {
  rds_id      = aws_db_instance.main.id
  script_hash = filemd5("${path.root}/scripts/db-schema-init.sh")
}

2. `modules/network/main.tf`: 보안 그룹 포트 범위 최소화

from_port = 0, to_port = 65535로 과도하게 열려 있던 모니터링 인바운드 규칙 2개를 수정했다.

ecs_in_from_monitoring: 실제 ECS 서비스 포트만 열도록 for_each로 교체

포트	서비스
8000	gateway
8761	Eureka
8888	Config Server
19091~19097	마이크로서비스, bid

Keycloak(18080)은 ecs-discovery.sh의 SKIP 목록에 있어 Prometheus가 스크레이프하지 않으므로 제외했다.

kafka_in_from_monitoring: 실제 사용 포트만 허용 (docker-compose.kafka.yml 기준)

포트	용도
9092	Kafka UI 브로커 연결
7071	JMX Exporter (Prometheus scrape)
9100	Node Exporter (EC2 메트릭)

dev/prod 환경 분리

새 폴더 구조

root/
  envs/
    dev/     (새 폴더)
    prod/    (새 폴더)
  modules/   (기존 유지)
  bootstrap/ (기존 유지)

envs/dev/와 envs/prod/ 모두 ../../modules/를 공유한다. 각 폴더에서 terraform init && terraform apply를 실행하면 된다.

상태 파일 분리

환경	S3 키
prod	`prod/terraform.tfstate` (기존과 동일)
dev	`dev/terraform.tfstate` (신규)

환경별 차이

항목	dev	prod
`environment`	dev	prod
`spring_profile`	dev	prod
`kafka_count`	1	3
`kafka_instance_type`	t3.micro	t3.medium
`kafka_volume_size`	20 GB	30 GB
`monitoring_instance_type`	t3.micro	t3.medium
`monitoring_volume_size`	30 GB	50 GB
`bid_min_capacity`	1	2
`bid_max_capacity`	2	6
`enable_github_oidc`	false	true
VPC CIDR	10.1.0.0/16	10.0.0.0/16

함께 수정한 파일

modules/compute-ec2/

count = 3이 하드코딩되어 있던 Kafka EC2를 count = var.kafka_count로 변경했다. 루트 변수 기본값은 3이다.

modules/data/main.tf + modules/data/variables.tf

filemd5("${path.root}/scripts/...") 경로가 실행 위치에 따라 달라지는 문제를 수정했다. 모듈이 직접 파일을 읽는 대신, 호출하는 쪽(각 env의 main.tf)에서 해시를 계산해 db_init_script_hash 변수로 넘긴다.

envs/prod/main.tf : filemd5("${path.root}/../../scripts/db-schema-init.sh")
envs/dev/main.tf : filemd5("${path.root}/../../scripts/db-schema-init.sh")
루트 main.tf : filemd5("${path.root}/scripts/db-schema-init.sh") (기존과 동일)

bootstrap/main.tf

SSM 파라미터를 환경별로 함께 생성하도록 수정했다. 기존에는 /sanji/prod/... 경로만 하드코딩되어 있었다. 이제 secret_keys 목록을 한 번 정의하고, merge()로 prod와 dev 경로를 모두 만든다.

검증 결과

terraform validate   # 루트(.terraform/)   - Success!
terraform validate   # envs/prod/          - Success!
terraform validate   # envs/dev/           - Success!

IAM s3:ListBucket 권한 범위 축소

코드 리뷰에서 지적된 ec2_ssm_read 정책의 s3:ListBucket 권한 범위 문제를 수정했다.

문제

s3:ListBucket이 버킷 전체(arn:aws:s3:::sanji-terraform-state)에 열려 있어 EC2와 GitHub Actions가 prod/terraform.tfstate 등 민감한 경로까지 열람할 수 있었다.

수정

s3:prefix 조건을 추가해 deploy/* 경로만 목록 조회가 가능하도록 제한했다.

condition {
  test     = "StringLike"
  variable = "s3:prefix"
  values   = ["deploy/*"]
}

aws s3 sync가 내부적으로 ListObjects를 호출하므로 s3:ListBucket 자체는 필요하기 때문에 조건만 추가했다.

수정 파일

파일	수정 위치
`.terraform/iam.tf`	`ec2_ssm_read`, `github_actions` 정책 각 1곳
`.terraform/envs/prod/iam.tf`	동일
`.terraform/envs/dev/iam.tf`	동일

검증 결과

terraform validate   # 루트(.terraform/)   - Success!
terraform validate   # envs/prod/          - Success!
terraform validate   # envs/dev/           - Success!

IAM / SSM 코드 중복 제거 (modules/iam, modules/ssm 추출)

envs/prod/iam.tf와 envs/dev/iam.tf가 100% 동일하고, ssm.tf도 마찬가지였다. IAM 정책 변경 시 두 파일을 모두 수정해야 하는 문제를 해결했다.

새 모듈

모듈	역할
`modules/iam/`	ECS 실행/태스크 역할, EC2 인스턴스 역할, GitHub Actions OIDC 역할
`modules/ssm/`	SSM 파라미터 생성(db_password, kafka_private_ip, kafka_quorum_voters) + bootstrap 시크릿 읽기

변경 사항

modules/iam/main.tf, variables.tf, outputs.tf 신규 생성
modules/ssm/main.tf, variables.tf, outputs.tf 신규 생성
envs/prod/main.tf, envs/dev/main.tf: module "iam", module "ssm" 호출 추가, 직접 리소스 참조를 모듈 output으로 교체
envs/prod/outputs.tf, envs/dev/outputs.tf: aws_iam_role.github_actions[0].arn → module.iam.github_actions_role_arn
envs/prod/iam.tf, envs/dev/iam.tf, envs/prod/ssm.tf, envs/dev/ssm.tf 삭제

검증 결과

terraform validate   # envs/prod/   - Success!
terraform validate   # envs/dev/    - Success!

SSM 시크릿 목록 단일화

bootstrap/main.tf의 secret_keys(14개)와 modules/ssm/main.tf의 app_secret_paths(9개)가 달라, ECS에서 쓸 새 시크릿을 추가할 때 두 파일을 모두 수정해야 했다.

변경 사항

modules/ssm/main.tf의 app_secret_paths를 bootstrap의 secret_keys 전체(14개)와 동일하게 맞췄다.

추가된 5개 키:

kafka/cluster-id
monitoring/grafana-admin-password
monitoring/slack-webhook-url
langfuse/nextauth-secret
langfuse/salt

이 키들은 secret_arns 맵에 포함되지만, ECS 태스크 정의가 명시적으로 참조하지 않으므로 컨테이너에 주입되지 않는다. 이제 새 시크릿을 추가할 때 bootstrap/main.tf와 modules/ssm/main.tf 두 곳을 수정하면 된다. 단, EC2 전용 시크릿은 bootstrap만 수정하면 된다.

검증 결과

terraform validate   # envs/prod/   - Success!
terraform validate   # envs/dev/    - Success!

루트 .tf 파일 삭제

envs/가 진입점이 된 이후에도 루트에 main.tf, iam.tf 등이 남아 있어 실수로 루트에서 terraform apply를 실행하면 state가 꼬일 위험이 있었다.

루트 versions.tf의 backend key가 prod/terraform.tfstate로 envs/prod/와 동일하므로, 삭제해도 envs/prod/가 같은 state를 그대로 이어받는다.

삭제 파일

main.tf, variables.tf, iam.tf, ssm.tf, locals.tf, outputs.tf, versions.tf

루트에는 이제 bootstrap/, scripts/, docs/, envs/, modules/만 남는다.

Flyway로 DB 스키마 버전 관리하기

munsik22 — Mon, 29 Jun 2026 14:36:09 +0900

Flyway란?

Flyway는 오픈소스 데이터베이스 마이그레이션 도구로, 일종의 데이터베이스를 위한 Git(버전 관리 시스템)이다.

코드는 Git으로 버전을 관리한다. "이 파일 언제 어떻게 바뀌었는지" 기록이 남고, 과거 버전으로 돌아갈 수도 있다.

그런데 DB 테이블 구조(스키마)는 어떨까? 보통은 직접 DB에 접속해서 ALTER TABLE을 치거나, JPA의 ddl-auto: update가 알아서 바꾸도록 내버려둔다. 이 방법은 "지금 DB가 어떤 상태인지" 기록이 없고, 팀원마다 DB 상태가 달라질 수 있다.

Flyway는 이 문제를 해결한다. SQL 파일에 "V1 초기 테이블 생성", "V2 컬럼 추가" 같은 변경 이력을 순서대로 적어두면, Flyway가 아직 적용 안 된 것만 골라서 DB에 실행해준다.

ddl-auto와 뭐가 다른가요?

Spring Boot JPA의 ddl-auto는 아래와 같은 선택지를 제공한다.

값	동작
`create`	앱 시작 때마다 테이블을 새로 만듦 (기존 데이터 삭제됨)
`update`	엔티티 코드를 보고 부족한 컬럼만 추가 (삭제는 안 함)
`validate`	엔티티 코드와 DB 스키마가 일치하는지만 확인, 변경 안 함
`none`	아무것도 안 함

update는 편하지만 다음과 같은 문제가 있다.

컬럼 삭제는 알아서 안 해준다. 코드에서 필드를 지워도 DB에는 남는다.
"이 테이블이 언제, 왜 바뀌었는지" 기록이 없다.
운영 DB에서 쓰면 예상치 못한 스키마 변경이 일어날 수 있어 위험하다.

Flyway를 쓰면 스키마 변경 내역이 SQL 파일로 남고, 어느 환경에서 앱을 띄워도 같은 순서로 마이그레이션이 적용되어 DB 상태가 일정하다.

어떻게 작동하나요?

flyway_schema_history 테이블

Flyway는 처음 실행될 때 flyway_schema_history라는 테이블을 만든다. 이 테이블이 "어떤 마이그레이션 파일까지 적용했는지" 기록하는 장부다.

version | description  | installed_on        | success
--------|--------------|---------------------|--------
1       | init         | 2025-01-01 00:00:00 | true
2       | add column   | 2025-02-01 00:00:00 | true

앱이 시작될 때마다 Flyway는 이 장부를 보고 아직 실행 안 된 파일만 골라서 순서대로 실행합니다. 이미 실행된 파일은 건너뛴다.

마이그레이션 파일 이름 규칙

파일 이름이 Flyway에게 "어떤 버전인지, 어떤 종류인지"를 알려준다.

V{버전}__{설명}.sql

예:

V1__init.sql          -- 1번 버전, 초기 테이블 생성
V2__add_index.sql     -- 2번 버전, 인덱스 추가
V3__alter_column.sql  -- 3번 버전, 컬럼 변경

V는 버전 마이그레이션(한 번만 실행)
_ 두 개임에 주의 (__)
버전 번호는 숫자뿐 아니라 V1.1, V1.2처럼 소수점도 가능

실행 순서

앱 시작
  -> Flyway 활성화
  -> flyway_schema_history 확인
  -> 아직 실행 안 된 V*.sql 파일 탐색
  -> 버전 순서대로 실행
  -> 완료 후 장부에 기록
  -> JPA ddl-auto: validate 실행 (엔티티 코드와 DB 일치 확인)
  -> 앱 정상 기동

Spring Boot에서 사용하는 방법

1. 의존성 추가 (build.gradle)

Flyway 10.x부터는 PostgreSQL 지원 모듈이 별도로 분리되어 있기 때문에 두 개 모두 추가해야 한다.

dependencies {
    implementation 'org.flywaydb:flyway-core'
    implementation 'org.flywaydb:flyway-database-postgresql'
}

MySQL을 쓴다면 flyway-database-postgresql 대신 flyway-mysql을 추가한다.

2. application.yml 설정

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/mydb
    username: myuser
    password: mypassword

  jpa:
    hibernate:
      ddl-auto: validate  # Flyway가 스키마를 만들어주므로 validate만 사용

  flyway:
    enabled: true
    schemas: my_schema        # 마이그레이션할 스키마
    create-schemas: true      # 스키마가 없으면 자동으로 만들어줌
    locations: classpath:db/migration  # SQL 파일 위치
    baseline-on-migrate: true  # 이미 데이터가 있는 DB에 처음 Flyway를 도입할 때 필요

3. SQL 마이그레이션 파일 작성

src/main/resources/db/migration/V1__init.sql:

CREATE TABLE IF NOT EXISTS p_users
(
    id         UUID         NOT NULL,
    username   VARCHAR(50)  NOT NULL,
    email      VARCHAR(255) NOT NULL,
    created_at TIMESTAMP    NOT NULL,
    PRIMARY KEY (id),
    CONSTRAINT uq_users_email UNIQUE (email)
);

이 파일 하나가 "V1 마이그레이션"이 된다.

주요 설정 옵션 정리

설정	기본값	설명
`enabled`	true	Flyway 활성화 여부
`schemas`	(없음)	마이그레이션할 스키마 이름
`create-schemas`	false	스키마가 없으면 자동 생성
`locations`	`classpath:db/migration`	SQL 파일 위치
`baseline-on-migrate`	false	기존 DB에 Flyway 처음 도입 시 true
`out-of-order`	false	순서가 뒤섞인 마이그레이션 허용 여부
`validate-on-migrate`	true	실행 전 체크섬 검증 여부

baseline-on-migrate가 뭔가요?

이미 테이블이 있는 DB에 처음으로 Flyway를 도입할 때 필요한 옵션이다.

Flyway는 기본적으로 "스키마는 비어 있어야 내가 V1부터 만들 수 있다"고 생각한다. 그런데 이미 운영 중인 DB에는 테이블이 잔뜩 있습니다. 이 상태에서 Flyway를 켜면 아래 오류가 난다.

Found non-empty schema(s) "my_schema" but no schema history table.
Use baseline() or set baselineOnMigrate to true...

baseline-on-migrate: true를 설정하면 Flyway가 "현재 DB 상태를 V1 베이스라인으로 등록하고, 그 이후 버전부터만 실행할게"라고 처리한다. 기존 테이블에는 손대지 않는다.

단, 처음 도입 이후에는 true로 두어도 문제 없다. 베이스라인은 flyway_schema_history가 없을 때만 동작한다.

로컬 개발 환경에서 H2 쓰는 경우

H2 인메모리 DB를 쓰는 로컬 환경에서는 Flyway를 끄는 것이 편하다. H2는 PostgreSQL SQL 문법과 달라서 마이그레이션 파일이 실행 오류를 낼 수 있다.

application-local.yml:

spring:
  flyway:
    enabled: false
  jpa:
    hibernate:
      ddl-auto: create-drop  # 로컬에서는 앱 시작/종료 때 테이블 자동 관리

마이그레이션 파일 수정하면 안 되는 이유

이미 DB에 적용된 파일(flyway_schema_history에 기록된 것)을 수정하면 Flyway가 체크섬 오류를 낸다.

Validate failed: Migration checksum mismatch for migration version 1

Flyway는 파일이 처음 적용될 때 내용의 해시값(체크섬)을 저장해두고, 다음 실행 때 파일이 변경됐는지 확인한다. 이미 배포된 마이그레이션 파일은 절대 수정하지 말고, 새 버전 파일(V2, V3...)을 추가해야 한다.

정리

항목	내용
Flyway 역할	SQL 파일을 버전 순서대로 DB에 자동 적용
핵심 테이블	`flyway_schema_history` (적용 이력 장부)
파일 이름 형식	`V{버전}__{설명}.sql`
ddl-auto 조합	Flyway 쓸 때는 `validate` 사용
이미 있는 DB 도입	`baseline-on-migrate: true`
로컬 H2 환경	`flyway.enabled: false`

3주차 1일차 작업일지 (0629)

munsik22 — Mon, 29 Jun 2026 14:19:10 +0900

SHA 이미지 태그 + Task Definition 방식 전환 작업 로그

변경 파일 목록

파일	변경 내용
`.github/workflows/deploy-ecs.yml`	빌드: SHA + latest 두 태그 push / 배포: task def 리비전 교체 방식으로 전환
`.terraform/ecs_services.tf`	`aws_ecs_service.app` lifecycle에 `task_definition` ignore_changes 추가
`.terraform/ecs_bid.tf`	`aws_ecs_service.bid` lifecycle에 `task_definition` ignore_changes 추가
`.terraform/variables.tf`	`container_image_tag` 설명 업데이트
`docs/INFRASTRUCTURE.md`	[7] 이미지 태그 전략 절을 "SHA 태그 채택"으로 업데이트

변경 상세

deploy-ecs.yml: 빌드 잡

전: docker build ... -t "${IMAGE}:latest"
    docker push "${IMAGE}:latest"

후: IMAGE_TAG="${GITHUB_SHA::7}"
    docker build ... -t "${IMAGE}:${IMAGE_TAG}" -t "${IMAGE}:latest"
    docker push "${IMAGE}:${IMAGE_TAG}"
    docker push "${IMAGE}:latest"

deploy-ecs.yml: 각 wave 배포 잡 (wave-1~4 공통)

전: aws ecs update-service --force-new-deployment

후: 1. describe-services → 현재 task def ARN 조회
    2. describe-task-definition → task def JSON 가져오기
    3. jq로 이미지 태그를 SHA로 교체 + 등록 불가 필드(taskDefinitionArn 등) 제거
    4. register-task-definition → 새 리비전 등록
    5. update-service --task-definition <새 리비전>

wave-4(ai-service)는 함수 없이 같은 흐름을 직접 작성.

Terraform: ECS 서비스 lifecycle

ecs_services.tf와 ecs_bid.tf 두 파일에 동일하게 적용:

전: ignore_changes = [desired_count]
후: ignore_changes = [desired_count, task_definition]

CI/CD가 task def 리비전을 직접 교체하므로 Terraform이 이전 리비전으로 되돌리지 않도록 막는 것이 목적.

주의 사항

Keycloak(ecs_keycloak.tf)은 공개 이미지(quay.io)를 쓰고 CI/CD 빌드 대상이 아니라 변경하지 않음.
wave 구조(vCPU 한도 대응)는 그대로 유지됨. 배포 명령만 교체.
container_image_tag Terraform 변수는 Terraform 최초 apply 시에만 쓰이고, 이후 운영에서는 CI/CD가 SHA 리비전으로 덮어씀.

wave deploy 중복 제거 (reusable workflow 추출)

변경 파일

파일	변경 내용
`.github/workflows/deploy-ecs.yml`	wave 잡: 재사용 가능 워크플로 호출로 교체
`.github/workflows/_deploy-wave.yml`	(신규) 재사용 가능 워크플로: SHA 태그 기반 배포 로직 통합

변경 상세

wave마다 반복되던 deploy 로직(50줄 × 4회)을 _deploy-wave.yml로 추출.

전: runs-on + Configure AWS credentials + Deploy 스텝 (함수 50줄 × 4회 반복)

후: uses: ./.github/workflows/_deploy-wave.yml
    with:
      services: '서비스 목록'
      max_attempts: 120  # wave-4만

vars.AWS_ROLE_ARN은 같은 레포의 재사용 가능 워크플로에서 자동으로 사용 가능(별도 전달 불필요).

Flyway DB 마이그레이션 작업 로그

작업 개요

기존 JPA ddl-auto: update 방식을 Flyway 기반 마이그레이션으로 전환

변경 사항

의존성 추가 (각 서비스 build.gradle)

Flyway 10.x는 PostgreSQL 지원 모듈이 분리되어 있어 두 라이브러리를 모두 추가해야 함.

services/user-service/build.gradle
services/auction-service/build.gradle
services/order-service/build.gradle
services/payment-service/build.gradle
services/notification-service/build.gradle

추가 내용:

implementation 'org.flywaydb:flyway-core'
implementation 'org.flywaydb:flyway-database-postgresql'

SQL 마이그레이션 파일 생성

각 서비스의 src/main/resources/db/migration/V1__init.sql 신규 생성

서비스	스키마	생성 테이블
user-service	user_schema	p_users
auction-service	auction_schema	p_products, p_auctions, p_auction_outbox, shedlock
order-service	order_schema	p_orders, p_order_outbox
payment-service	payment_schema	p_payments, p_payment_history, p_outbox
notification-service	notification_schema	p_notification_logs

설정 파일 변경

ddl-auto: update → validate 변경

파일	변경 전	변경 후
user-service/application.yml	update	validate
order-service/application.yml	update	validate
payment-service/application.yml	update	validate
notification-service/application.yml	create	validate
config-server/config/auction-service.yml	update	validate

Flyway 설정 추가 (각 application.yml)

spring:
  flyway:
    schemas: <서비스별_스키마명>
    create-schemas: true
    locations: classpath:db/migration

auction-service 로컬 프로파일 처리

application-local.yml은 H2 인메모리 DB를 사용하므로 Flyway 비활성화:

spring:
  flyway:
    enabled: false

추가 작업: ai-service Flyway 적용

services/ai-service/build.gradle - flyway-core, flyway-database-postgresql 의존성 추가
services/ai-service/src/main/resources/db/migration/V1__init.sql 생성 (p_chat_sessions, p_chat_messages)
services/ai-service/src/main/resources/application.yml - ddl-auto: create -> validate, Flyway 설정 추가 (ai_schema)
config-server/src/main/resources/config/ai-service.yml - 동일하게 반영

참고: vector_store 테이블은 Spring AI pgvector의 initialize-schema: true가 자체 관리하므로 Flyway 대상에서 제외.

keycloak, langfuse는 외부 서비스로 자체 스키마 관리 → 적용 불필요

추가 작업: db-init.sh / init-schemas.sql 정리

db/init/init-schemas.sql이 기존에 모든 스키마와 shedlock 테이블을 수동으로 만들던 역할을 하고 있었음.

Flyway 도입 후 역할 분리:

대상	기존 방식	변경 후
6개 서비스 스키마 생성	init-schemas.sql	Flyway `create-schemas: true`
각 서비스 테이블 생성	없음 (ddl-auto: update)	Flyway V1__init.sql
shedlock 테이블	init-schemas.sql	auction-service V1__init.sql
keycloak_schema	init-schemas.sql	init-schemas.sql 유지
langfuse_schema	init-schemas.sql	init-schemas.sql 유지

db/init/init-schemas.sql 에서 Spring 서비스 스키마 및 shedlock 항목 제거, keycloak/langfuse 스키마만 남김.

db-init.sh는 Keycloak, Langfuse가 시작하기 전에 스키마를 미리 만들어야 하므로 계속 사용.

추가 작업: db-init.sh 수동 개입 완전 제거

RDS가 private subnet에 있어 Terraform PostgreSQL 프로바이더 직접 연결 불가. 기존 SSM 방식을 Terraform null_resource로 통합.

변경 파일

.terraform/versions.tf - null 프로바이더 추가 (hashicorp/null ~> 3.0)
.terraform/rds.tf - null_resource.db_schema_init 추가
- depends_on: RDS + 모니터링 EC2 + SSM 비밀번호 파라미터
- triggers: RDS ID 변경 시에만 재실행 (매 apply마다 실행 방지)
- local-exec: env vars로 값 주입 후 db-schema-init.sh 호출
.terraform/scripts/db-schema-init.sh 신규 생성 - Terraform 자동 호출용
.terraform/scripts/db-init.sh - 비상 수동 복구용임을 주석으로 명시

동작 흐름

terraform apply
  → aws_db_instance.main 생성
  → aws_instance.monitoring 생성
  → null_resource.db_schema_init 실행
      → SSM Agent 준비 대기
      → 모니터링 EC2에 SSM Run Command 전송
          → EC2에서 SSM으로 DB 비밀번호 조회
          → psql로 keycloak_schema / langfuse_schema 생성
      → 완료 확인

이후 terraform apply에서는 RDS ID가 바뀌지 않는 한 재실행 안 됨.

null_resource란?

Terraform 리소스인데 실제 인프라를 만들지 않는 빈 껍데기 리소스. 리소스 생성 없이 셸 명령만 실행하고 싶을 때 사용.

일반 리소스: terraform apply 시 EC2, RDS 등을 실제로 AWS에 생성
null_resource: 아무것도 만들지 않고 local-exec 프로비저너로 명령(스크립트)만 실행

triggers에 적은 값이 바뀔 때만 재실행됨. RDS ID를 트리거로 걸었으므로 RDS가 새로 만들어질 때만 스키마 초기화 스크립트가 실행되고, 이후 apply에서는 건너뜀.

트러블슈팅: 컨테이너 재시작 루프

원인

기존 ddl-auto: update로 이미 테이블이 만들어진 DB에 Flyway를 처음 도입하면, Flyway가 flyway_schema_history 테이블 없이 스키마가 비어있지 않다는 것을 감지하고 오류 발생

Found non-empty schema(s) "user_schema" but no schema history table.
Use baseline() or set baselineOnMigrate to true to initialize the schema history table.

해결

모든 서비스 Flyway 설정에 baseline-on-migrate: true 추가.

기존 스키마를 version 1 베이스라인으로 등록하고 이후 마이그레이션만 실행하는 방식으로 전환.

변경 파일:

services/user-service/src/main/resources/application.yml
services/order-service/src/main/resources/application.yml
services/payment-service/src/main/resources/application.yml
services/notification-service/src/main/resources/application.yml
services/ai-service/src/main/resources/application.yml
config-server/src/main/resources/config/auction-service.yml
config-server/src/main/resources/config/ai-service.yml

주의사항

모든 서비스 Dockerfile이 빌드된 JAR을 복사하는 방식(COPY build/libs/*.jar)이라, yml 변경 후 반드시 아래 순서로 진행해야 함.

Gradle 재빌드 (./gradlew bootJar)
Docker 이미지 재빌드 (docker compose build)
컨테이너 재시작 (docker compose up -d)

auction-service는 Flyway 설정을 config-server에서 받으므로, config-server/config/auction-service.yml 변경 시 config-server JAR도 함께 재빌드 후 config-server를 먼저 재시작해야 auction-service에 반영됨.

코드리뷰 반영: V1__init.sql 수정

auction-service

p_products.quantity VARCHAR(255) → INTEGER
p_auctions.start_price / final_price / bid_unit INTEGER → BIGINT

order-service

p_orders.user_name VARCHAR(10) → VARCHAR(50)
p_orders.amount INTEGER → BIGINT
p_order_outbox 인덱스 추가: (status, created_at)

payment-service

p_payments.amount / original_amount / cancel_amount INTEGER → BIGINT
p_payment_history.amount INTEGER → BIGINT
p_payments.card_number: 마스킹된 번호만 저장한다는 주석 추가
p_outbox 인덱스 추가: (status, created_at)

ai-service

p_chat_messages 인덱스 추가: (session_id)

TABLES.md 검증 및 롤백

TABLES.md가 엔티티 코드 기반 명세서이므로 코드리뷰 반영 내용 일부를 롤백.

롤백 항목 (엔티티 코드와 불일치)

엔티티가 int 타입으로 선언되어 있어 DB를 BIGINT로 변경하면 ddl-auto: validate 단계에서 기동 실패.

auction-service: start_price / final_price / bid_unit BIGINT → INTEGER 롤백
order-service: user_name VARCHAR(50) → VARCHAR(10) 롤백, amount BIGINT → INTEGER 롤백
payment-service: amount / original_amount / cancel_amount BIGINT → INTEGER 롤백, p_payment_history.amount BIGINT → INTEGER 롤백
TABLES.md: 위 항목 모두 원복

유지 항목 (엔티티와 무관한 추가)

p_products.quantity VARCHAR(255) 유지 (TABLES.md: "100kg" 형식 문자열, INTEGER 변경은 잘못)
아웃박스 인덱스 3개 유지 (order, payment, ai-service)
p_payments.card_number 주석 유지

2주차 2~5일차 작업일지 (0623 ~ 0626)

munsik22 — Fri, 26 Jun 2026 19:31:36 +0900

6월 23일

AWS 인프라 전체 최초 구축

문제 서비스를 올릴 AWS 인프라가 전혀 없었다.

해결 Terraform으로 VPC, ALB, RDS(PostgreSQL 16.9), Redis(ElastiCache), ECS 클러스터, ECR, IAM, SSM Parameter Store, EC2(Kafka, 모니터링) 등 총 155개 리소스를 생성했다. RDS 버전 16.4가 ap-northeast-2 리전에서 미지원이어서 16.9로 교체 후 재시도했다.

결과 AWS 인프라 전체 구축 완료. SSM Run Command로 RDS 스키마 9개와 테이블을 초기화했고, EC2 Docker 설치 및 SSM Agent 연결, ECS 서비스 11개 배포까지 마쳤다.

Terraform EC2 AMI 교체 방지

문제 most_recent = true로 AMI를 조회하도록 되어 있어, 아마존이 새 AMI를 배포할 때마다 다음 terraform apply 시 Kafka EC2와 모니터링 EC2가 통째로 교체될 수 있었다. 두 서버는 디스크에 데이터를 보관하는 서버라 교체 시 데이터가 날아간다.

해결 두 EC2 리소스에 lifecycle { ignore_changes = [ami] }를 추가했다.

결과 AMI가 바뀌어도 Terraform이 기존 서버를 그대로 유지한다. 의도적으로 업그레이드할 때만 이 블록을 제거하고 apply하면 된다.

config-server 프로파일 설정 오류 수정

문제 ECS에서 SPRING_PROFILES_ACTIVE=prod로 컨테이너를 실행하면 config-server application.yml의 spring.profiles.active: native 설정이 덮어써진다. native 프로파일이 비활성화되면 Spring Cloud Config Server가 Git 백엔드로 폴백하고 URI가 없어서 크래시가 발생했다.

해결 Terraform ECS 태스크 정의에서 config-server에만 SPRING_PROFILES_ACTIVE=prod,native를 환경변수로 주입했다. (spring.profiles.include는 Spring Boot 2.4부터 profile-specific 파일에서 사용 불가라 앱 코드 수정 대신 이 방법을 택했다.)

결과 config-server가 prod + native 프로파일로 정상 기동. classpath의 설정 파일들을 읽어 나머지 서비스에 배포한다.

ECS wave 배포 도입 + waiter 타임아웃 수정

문제 11개 서비스를 동시에 롤링 배포하면 old 태스크 + new 태스크가 겹치며 Fargate vCPU 한도(30)를 초과해 일부 서비스가 배포되지 못했다. 또한 AWS_MAX_ATTEMPTS=80을 설정했지만 aws ecs wait services-stable의 폴링은 botocore 내부에서 40회×15초=10분으로 고정되어 있어 이 환경변수가 전혀 영향을 주지 않았다.

해결 서비스를 3개 wave로 나눠 순차 배포하는 방식을 도입했다. aws ecs wait services-stable 대신 wait_stable 커스텀 폴링 함수로 교체해 최대 20분(ai-service는 30분)까지 대기하도록 했다.

결과 Deploy ECS 워크플로우 최종 성공. wave별 진행 상황을 GitHub Actions UI에서 별도 job으로 확인할 수 있다.

Prometheus + Grafana 설정 수정

문제 1 prometheus.prod.yml에 ecs_sd_configs를 사용했는데, 공식 Prometheus는 ECS SD를 지원하지 않는 필드라 크래시가 발생했다. Prometheus 크래시에 depends_on으로 걸린 Grafana도 연쇄 실패했다.

해결 1 ecs_sd_configs 대신 file_sd_configs + 5분 주기 cron 스크립트(ecs-discovery.sh) 방식으로 교체했다. 스크립트가 AWS CLI로 ECS 태스크 IP를 조회해 JSON 파일로 저장하면 Prometheus가 이 파일을 읽는다. 서비스별로 포트가 다 달라 PORT_MAP을 스크립트에 추가했다. Prometheus 이미지를 latest에서 v2.55.1로 버전 고정했다.

문제 2 Grafana에 SLACK_WEBHOOK_URL이 주입되지 않아(빈 값) Slack contact point 초기화에 실패하며 재시작을 반복했다.

해결 2 deploy-ec2.yml에서 SSM Parameter Store 값을 조회해 환경변수로 주입하도록 수정했다.

결과 Prometheus, Grafana 모두 정상 기동. Spring Boot Observability 대시보드에 ECS 앱 지표가 표시된다.

로컬 Docker 환경 수정

문제 여러 서비스의 환경변수 설정이 누락되거나 잘못되어 있었다. user-service는 SPRING_DATA_REDIS_HOST가 빈 값으로 전달되어 Redis 연결 실패. payment-service는 Toss 환경변수 이름이 application.yml과 docker-compose.yml 사이에 달랐다. notification-service는 SLACK_BOT_TOKEN이 컨테이너에 전달되지 않았다. locals.tf의 Redis 플래그도 실제 코드와 맞지 않아 4개 서비스가 잘못 설정되어 있었다(user-service/payment-service/notification-service는 false, auction-service는 true로 반대로 되어 있었다).

해결 user-service에 Redis 호스트를 컨테이너 이름 redis로 직접 지정했다. payment-service에 Toss 환경변수 이름 매핑을 추가했다. notification-service에 SLACK_BOT_TOKEN 전달을 추가했다. locals.tf Redis 플래그를 코드 실제 사용 여부에 맞게 수정했다.

결과 로컬 Docker 전체 19개 서비스 정상 기동 확인.

AI 코드 리뷰 개선 (GitHub Actions)

문제 gemini_review.yml이 diff.txt만 AI에 전달해 파일의 전체 맥락을 볼 수 없었다. 이미 코드에 있는 내용을 AI가 누락됐다고 피드백하는 오탐이 발생했다.

해결 변경된 파일의 전체 내용도 프롬프트에 함께 전달하도록 수정했다. 500줄 이하 파일은 전체, 초과 파일은 선언부(1~80줄) + hunk 위치 기반 변경 구간을 추출한다. 추출 로직을 shell 스크립트로 작성했다가 Node.js로 전환했다(diff 1회 파싱으로 O(M+N) 달성, 겹치는 hunk 범위 병합).

결과 "이미 있는 코드를 추가하라"는 중복 피드백이 제거됐다.

6월 24일

db-init 실행 호스트 변경 (Kafka EC2 → 모니터링 EC2)

문제 DB 초기화 스크립트가 Kafka EC2에서 실행되도록 되어 있었다. Kafka가 다중 클러스터로 확장되면 어느 Kafka에서 실행하는지 특정할 수 없고, Kafka 브로커가 DB 초기화 책임까지 겸하는 역할 오염이 생긴다.

해결 단일 인스턴스로 유지되는 모니터링 EC2로 실행 호스트를 변경했다. RDS 보안 그룹 허용 출처도 Kafka → 모니터링으로 함께 변경했다.

결과 DB 초기화 책임이 단일 관리 서버로 명확하게 분리됐다.

deploy-ec2.yml 리팩터링

문제 워크플로우 안 단일 step에 SSM 환경변수 조회, .env 생성, 설정 파일 치환, crontab 등록, Docker Compose 실행 등 모든 책임이 몰려 있었다. REPO_DIR과 REGION이 4곳에 하드코딩되어 있어 경로 변경 시 모두 찾아 수정해야 했다.

해결 배포 로직을 scripts/deploy-kafka.sh, scripts/deploy-monitoring.sh로 분리했다. 공통 환경변수는 scripts/env.sh 한 곳에서 관리하고 각 스크립트에서 source해서 쓰도록 했다.

결과 워크플로우는 git pull + 스크립트 호출 두 줄만 남았다. 환경변수 중복이 제거됐다.

EC2 ECR 권한 제거

문제 EC2 인스턴스 역할에 AmazonEC2ContainerRegistryReadOnly 권한이 붙어 있었는데, EC2에서 실행하는 컨테이너는 전부 Docker Hub / ghcr.io 퍼블릭 이미지라 ECR에 접근할 일이 없다. 사용하지 않는 권한은 보안 원칙상 제거해야 한다.

해결 iam.tf에서 해당 권한 attachment를 제거했다.

결과 EC2 역할의 권한이 실제 필요한 것만 남았다. ECR은 ECS Fargate만 사용한다는 것이 코드와 IAM 모두에서 명확해졌다.

SSM Parameter Store bootstrap 마이그레이션

문제 terraform destroy 시 SSM 파라미터가 함께 삭제되어, 다음에 인프라를 다시 올릴 때 시크릿 값을 수동으로 모두 다시 입력해야 했다.

해결 자주 변경하지 않는 시크릿 14개를 bootstrap/main.tf로 이동하고 prevent_destroy = true + ignore_changes = [value]를 적용했다. bootstrap은 destroy 대상에 포함되지 않으므로 값이 AWS에 보존된다.

결과 terraform destroy 후 재구축 시 SSM 파라미터를 다시 입력할 필요가 없어졌다.

ai-service 배포 Wave 분리

문제 ai-service는 기동 시 pgvector 스키마 초기화 + Gemini API 연결 초기화가 추가로 일어나 다른 서비스보다 기동 시간이 훨씬 길다. Wave 3에서 다른 서비스와 함께 배포하면 ai-service 타임아웃이 같은 Wave 전체를 실패로 만들었다.

해결 ai-service를 Wave 3에서 분리해 Wave 4(단독)로 이동하고, 최대 대기 시간을 30분으로 늘렸다.

결과 ai-service 타임아웃이 다른 서비스 배포에 영향을 주지 않게 됐다.

db-init.sh / keycloak-setup.sh 버그 수정 (총 5차)

문제 여러 스크립트에 걸쳐 버그가 겹쳐 있었다.

SSM Run Command JSON 안에 리터럴 "가 삽입되어 파싱 오류 발생
레포 경로가 sanji-jk로 잘못 하드코딩되어 실제 경로 san-ji-jik-kyeng와 불일치 (여러 스크립트에 걸쳐)
keycloak-setup.sh 헬스 체크 URL이 관리 포트(9000)를 바라보고 있어 포트 포워딩(18080)과 불일치
SSM 포트 포워딩이 실제로 포트를 바인딩하지 않아 Keycloak에 접근 불가

해결 echo \"...\" → printf로 쌍따옴표 문제를 제거했다. 경로 오타를 전체 스크립트에 걸쳐 수정했다. keycloak-setup.sh를 SSM 포트 포워딩 방식에서 SSM Run Command로 모니터링 EC2에서 직접 Keycloak API를 호출하는 방식으로 전환했다.

결과 db-init 정상 실행 확인("완료. 스키마 초기화 성공."). Keycloak 설정 스크립트도 정상 실행.

EC2 IAM 권한 추가 (rds:DescribeDBInstances)

문제 deploy-monitoring.sh에서 aws rds describe-db-instances로 RDS 엔드포인트를 조회하는데, EC2 역할에 해당 권한이 없어 AccessDenied로 배포가 실패했다.

해결 iam.tf에 EC2 역할용 rds:DescribeDBInstances 권한 정책을 추가하고 Terraform으로 즉시 반영했다.

결과 deploy-ec2 워크플로우 정상 완료.

EC2 배포 S3 전환

문제 EC2 배포 시 git clone으로 레포를 받아오는 방식을 사용했는데, 이 레포의 기본 브랜치가 dev라서 git clone이 dev를 받아왔다. 배포 스크립트는 main에만 있어 exit 127로 실패했다. 또한 EC2가 JMX Exporter JAR를 직접 Maven Central에서 wget해오는 구조라 외부 인터넷 직접 의존이 생겼다.

해결 git clone 대신 GHA 러너에서 배포에 필요한 파일을 S3에 업로드하고, EC2는 aws s3 sync로 받도록 전환했다. JMX Exporter JAR도 GHA 러너에서 다운로드해 S3에 올리고, SHA256 무결성 검증 후 EC2에 배포한다.

결과 브랜치 문제 없이 항상 최신 main의 파일이 EC2에 배포된다. EC2의 Maven Central 직접 의존성이 제거됐다.

6월 25일

Keycloak 연결 오류 수정 (로컬)

문제 로컬에서 user-service가 Keycloak에 localhost:18080으로 연결을 시도해 Connection refused가 발생했다. Docker 컨테이너 내부에서 localhost는 자기 자신(user-service 컨테이너)을 가리키기 때문이다.

해결 .env의 KEYCLOAK_SERVER_URL, KEYCLOAK_ISSUER_URI를 localhost 대신 Docker Compose 서비스 이름 keycloak으로 변경했다.

결과 로컬에서 Keycloak 연동 정상 동작.

order-service outbox JSONB 타입 오류 수정

문제 p_order_outbox 테이블의 payload 컬럼이 jsonb 타입인데, OrderOutbox.java의 payload 필드에 @JdbcTypeCode(SqlTypes.JSON) 어노테이션이 없었다. Hibernate가 이 필드를 varchar로 바인딩해 PostgreSQL이 묵시적 형변환을 거부하면서 보증금 주문 생성 INSERT가 실패했다.

해결 OrderOutbox.java에 @JdbcTypeCode(SqlTypes.JSON) 어노테이션을 추가했다.

결과 보증금 주문 생성 시 outbox INSERT 오류 해소.

Kafka healthcheck 추가 (로컬)

문제 Kafka에 healthcheck가 없어 컨슈머 서비스들이 Kafka가 완전히 준비되기 전에 접속을 시도했다. 접속 실패 후 재시도할 때마다 __consumer_offsets 자동 생성 로그가 반복됐다.

해결 Kafka에 kafka-topics.sh --list를 사용한 healthcheck를 추가하고, Kafka에 의존하는 6개 서비스(auction, bid, order, payment, notification, kafka-ui)의 depends_on condition을 service_started → service_healthy로 변경했다.

결과 Kafka가 완전히 준비된 후에 컨슈머 서비스들이 기동해 불필요한 재연결 로그가 사라졌다.

Kafka 직렬화 타입 헤더 문제 수정 (핵심 버그)

문제 order-service outbox 릴레이에서 Object.class로 역직렬화하면 Jackson이 LinkedHashMap을 만들고, 메시지 헤더에 __TypeId__: java.util.LinkedHashMap이 붙는다. payment-service의 JsonDeserializer가 이 헤더를 보고 LinkedHashMap으로 역직렬화하려 하지만, 리스너가 기대하는 타입(예: WinningCreatedEvent)으로 변환할 방법이 없어 예외가 발생했다. 3번 재시도 후 DLT로 이동하면서 이벤트가 "전달되지 않은 것처럼" 보였다.

해결

order-service: deserializePayload() 메서드로 이벤트 타입별 DTO 클래스로 역직렬화하도록 수정. producer에서 JsonSerializer.ADD_TYPE_INFO_HEADERS = false 설정(마이크로서비스 간에는 producer 클래스가 consumer classpath에 없으므로 타입 헤더가 유해하다).
payment-service: JsonDeserializer → StringDeserializer + StringJsonMessageConverter로 교체해 리스너 파라미터 타입으로 직접 역직렬화.
order-service: payment-service 패턴으로 Kafka consumer 방식을 통일했다.

결과 Kafka 이벤트가 DLT로 빠지지 않고 consumer에서 정상 처리됨. order-service → payment-service 이벤트 전달 정상화.

보증금 결제 confirm 404 수정

문제 PaymentService.createDepositPayment()에서 tossOrderId를 내부 UUID(event.orderId().toString())로 저장했다. 그런데 Toss 위젯에 전달하는 주문 번호는 ORD-XXXXXXXX 형식의 orderNumber다. confirm 요청이 orderNumber로 들어오면 UUID가 저장된 레코드를 찾지 못해 404가 발생했다.

해결 이벤트 DTO(DepositCreatedEvent, WinningCreatedEvent)에 orderNumber 필드를 추가하고, PaymentService에서 tossOrderId를 event.orderNumber()로 참조하도록 수정했다.

결과 보증금 결제 confirm 정상 처리.

결제 완료 후 주문 상태 미업데이트 수정

문제 payment-service outbox 릴레이도 Object.class → LinkedHashMap 문제가 있었다. order-service의 PaymentEventConsumer가 LinkedHashMap을 PaymentCompletedEvent로 변환하지 못해 MessageConversionException 발생 → 3회 재시도 후 DLT 이동 → 결제 완료 후 주문 상태가 PAYMENT_SUCCESS로 업데이트되지 않았다.

해결 PaymentEventConsumer를 ConsumerRecord + objectMapper.convertValue() 방식에서 StringJsonMessageConverter 기반 타입 직접 수신 방식으로 교체했다. KafkaConsumerConfig도 payment-service와 동일한 구조로 통일했다.

결과 결제 완료 후 주문 상태가 PAYMENT_SUCCESS로 정상 업데이트됨.

6월 26일

모니터링 설정 버그 수정

문제 여러 모니터링 설정 버그가 겹쳐 있었다.

deploy-monitoring.sh에서 모니터링 EC2의 private IP를 IMDS에서 조회하는 코드와 envsubst 인자에 $MONITORING_PRIVATE_IP가 빠져, prometheus.prod.yml에 리터럴 ${MONITORING_PRIVATE_IP}:9100이 그대로 남아 Prometheus가 잘못된 주소를 타겟으로 읽었다.
Langfuse의 NEXTAUTH_URL: ${LANGFUSE_URL} 변수명이 배포 스크립트의 LANGFUSE_NEXTAUTH_URL과 달라 빈 값으로 기동됐다.
Grafana Spring Boot Observability 대시보드 PromQL에 Config Server 정규식 경로(profiles:)와 Spring Security가 URI 패턴을 못 잡은 UNKNOWN 요청이 노이즈로 표시됐다.
docker-compose.monitoring.yml에 Node Exporter 서비스가 없어 monitoring Prometheus job이 항상 DOWN이었다.

해결 IMDS에서 private IP 조회 코드와 envsubst 인자를 추가했다. Langfuse 변수명을 맞췄다. PromQL 전체에 uri!~".*profiles:.*", uri!="UNKNOWN" 필터를 추가했다. Node Exporter 서비스를 docker-compose.monitoring.yml에 추가했다.

결과 Prometheus가 Kafka, 모니터링 EC2, ECS 앱 지표를 정상 수집한다. Grafana 대시보드에서 노이즈가 제거됐다.

회원가입 500 에러 수정

문제 AWS에서 회원가입 API를 호출하면 Gateway가 Connection refused: /169.254.172.2:19091로 실패했다. ECS Fargate(awsvpc 네트워크 모드)에서는 컨테이너에 네트워크 인터페이스가 여러 개 붙는다. Spring Boot가 인터페이스를 스캔할 때 순서에 따라 ECS 링크-로컬 주소(169.254.172.2)를 먼저 집어오면 Eureka에 169.254.172.2:19091로 등록된다. 이 주소는 해당 컨테이너 내부에서만 유효해 다른 컨테이너에서 도달할 수 없다.

해결 spring.cloud.inetutils.preferred-networks: 10.0 설정을 config-server 공통 설정(config/application.yml)에 추가했다. Spring이 인터페이스를 스캔할 때 VPC CIDR(10.0.0.0/16) 대역을 우선 선택한다. 로컬 환경에서는 10.0 대역이 없으므로 자동으로 일반 인터페이스로 폴백한다.

결과 Eureka에 VPC 내부 IP(10.0.x.x)가 등록되어 Gateway 라우팅이 정상화됐다. 회원가입 500 에러 해소.