PokeClip의 미디어 사이드카에는 조각을 색인하는 연결 풀과 되감기 재생목록을 발행하는 연결 풀이 있다. 오래된 파일을 정리하는 janitor도 별도의 DB 연결을 사용한다. RDS IAM 인증을 붙일 때 세 곳을 각각 수정하면, 토큰 생성뿐 아니라 TLS와 오류 처리 규칙까지 서로 달라질 수 있었다.
그래서 인증 전환과 함께 접속 정책을 media/internal/pgconf로 모았다. 나는 IAM 모드의 TLS 강제, CA 배포 방식, DB 권한 범위와 실험 RDS 검증 범위를 결정했다. 구현·시험 실행·리뷰에는 AI 에이전트를 활용했다. 아래 결과는 그 과정에서 남긴 코드와 실측 기록을 기준으로 정리했다.
공통화할 대상은 연결 문자열보다 정책이었다
RDS IAM 인증은 DB 비밀번호 대신 AWS 자격 증명으로 서명한 토큰을 로그인에 사용하는 방식이다. 공식 유효 시간은 15분이며, 이미 성립한 DB 세션의 수명을 15분으로 제한하는 것은 아니다. AWS 공식 문서
공통 모듈의 책임을 두 단계로 나눴다. FromEnv는 환경변수의 조합을 검증하고, PoolConfig는 CA 파일을 확인한 뒤 pgx 연결 풀 설정을 만든다. AWS 의존성은 iam.go에 모았다. 기존 DSN 조립 구현 두 벌은 제거하고, 두 서비스의 세 풀이 같은 정책을 사용하도록 연결했다.
| 항목 | 선택한 동작 | 이유 |
|---|---|---|
| 로컬 호환성 | 인증 모드가 비어 있거나 password이면 기존 경로 유지 |
개발 환경을 IAM 전환과 함께 바꾸지 않기 |
| IAM + 비밀번호 | 시작 단계에서 오류 | 잘못 섞인 인증 설정을 조용히 받아들이지 않기 |
| IAM의 TLS | verify-full만 허용 |
암호화와 접속 대상의 신원 확인을 함께 요구 |
| CA 경로 | POSTGRES_SSLROOTCERT 명시 필수 |
CA 선택을 배포 설정에서 확인할 수 있게 하기 |
| 연결 성공 로그 | Ping 뒤 실제 TLS 사용 여부 기록 | 설정값만 보고 보안 연결 성공으로 판단하지 않기 |
verify-full은 인증서 체인뿐 아니라 접속 호스트 이름도 검증한다. verify-ca와의 차이는 이 호스트 확인이다. 공용 RDS CA를 신뢰한다고 해서 내가 접속하려던 특정 DB의 신원이 자동으로 확인되는 것은 아니므로, IAM 모드에서 약한 설정을 허용하지 않았다. PostgreSQL SSL 문서
CA는 빌드할 때마다 내려받는 대신 검토한 AWS 통합 번들을 저장소에 포함하고 해시를 확인하도록 했다. 인증서 갱신이 코드 변경처럼 검토되게 하려는 선택이다. 비특권 프로세스는 번들을 읽을 수 있지만 바꿀 수 없도록 파일과 상위 디렉터리 권한도 확인했다. 그 대신 CA 갱신과 이미지 재배포는 운영 책임으로 남는다.
토큰 생성 시점은 풀 생성이 아니라 새 연결 직전
풀을 만들 때 토큰을 한 번 생성하면 첫 접속은 성공할 수 있다. 문제는 시간이 지난 뒤 풀에서 물리 연결을 새로 만들 때다. 처음 토큰을 계속 재사용하면 만료된 자격으로 다시 로그인한다.
이 때문에 pgx의 BeforeConnect에서 새 토큰을 만들도록 했다. 이 훅은 풀에서 연결을 빌릴 때마다가 아니라 새 물리 연결을 만들기 직전 실행된다. 기존 연결을 재사용하는 쿼리마다 토큰을 발급하는 구조는 아니다. pgxpool Config 문서
토큰 생성에는 자격 증명 조회를 포함해 자체 10초 제한을 뒀다. 풀의 보충 연결에서 호출자 요청의 기한이 그대로 전달된다고 가정할 수 없었기 때문이다. 이 10초는 토큰 생성 단계의 상한이고, TCP 연결이나 RDS 서버 인증 전체의 완료 시간을 보장하지 않는다. 실패 로그에는 토큰·DSN·AWS 오류 원문을 남기지 않았다.
실험 RDS에서 무엇을 확인했나
2026년 10월 22일 서울 리전의 PostgreSQL 17.11, db.t4g.micro 한 대에서 검증했다. 서명 주체는 실험용 로컬 IAM 사용자였으며 운영 EC2 인스턴스 역할 검증과 구분했다.
| 검증 조건 | 관측 결과 |
|---|---|
| 사이드카 IAM 연결을 44분 유지 | 프로세스 재시작 0, DB 권한 오류 0 |
| DB 백엔드 강제 종료 2회 | 새 연결로 재로그인 |
| 실제 연결의 TLS 조회 | TLS 1.3 사용 확인 |
| IP 주소 접속 / 다른 CA / 다른 리전 | 각각 연결 또는 인증 실패 |
IAM + require |
DB 왕복 전에 설정 오류 |
실제 RDS 시험과 별도로, Linux arm64·Go 1.27·PostgreSQL 17.10의 CI 등가 환경에서 모듈의 거부 규칙을 검증했다. 규칙을 의도적으로 망가뜨린 40개 변형을 각 3회 실행해 120/120을 검출했고, 음성 대조는 90/90을 통과했다. 이 변이 수치는 위 실험 RDS에서 얻은 결과가 아니다.
media_indexer는 대상 표의 SELECT·INSERT·UPDATE 중심으로 권한을 제한하고 DELETE와 DDL을 제외했다. 파일 정리 역할인 janitor까지 같은 권한이라고 묶지는 않았다. 권한 시험도 실제 PostgreSQL 역할로 실행했다.
토큰 만료 시험에서는 예상과 다른 결과가 있었다. 이 인스턴스는 서명 시각이 19분 30초 전인 토큰을 수용했고, 20분 30초 전인 토큰은 거부했다. 이 때문에 처음 잡았던 16분 30초 대기는 토큰 캐시 결함을 가려내지 못했고, 해당 실험의 대기를 21분 30초로 늘린 뒤 원본과 변이를 구분했다.
이것은 인스턴스 한 대에서 한 번 관측한 경계다. IAM 토큰을 20분 동안 재사용해도 된다는 보장으로 해석하지 않았다. 설계는 공식 유효 시간과 무관하게 새 연결마다 토큰을 생성하는 방식을 유지했다.
공통 모듈이 끝낸 일과 남긴 일
PR #314는 2026년 10월 23일 한국 시간 기준으로 develop에 머지됐다. 이 글이 다루는 완료 범위는 공통 접속 코드, 권한 시험, 실험 RDS 검증이다. 해당 검증에서 운영 서버의 모든 연결을 관찰한 것은 아니며, 새 토큰 생성은 같은 pgconf 경로를 사용하는 프로브로도 확인했다.
SDK 기본 자격 증명 사슬을 사용하는 만큼 정적 키 환경변수나 공유 자격 증명 파일이 운영 역할보다 먼저 선택되지 않도록 하는 일은 배포 설정에 남는다. 비밀번호 인증으로 되돌릴 때도 환경변수 하나만 바꾸면 끝나지 않는다. PostgreSQL의 rds_iam 역할과 DB 사용자 설정까지 함께 검토해야 한다.
공통화의 결과는 호출부가 짧아진 데서 끝나지 않았다. 어떤 설정을 거부할지, 언제 토큰을 생성할지, 연결 성공을 무엇으로 판정할지를 한 곳에서 수정하고 시험할 수 있게 됐다. 여러 서비스가 같은 DB 접속 정책을 따라야 할 때 공통 모듈을 둘 이유가 여기에 있었다.