Memory API EC2 이전 검증 및 egs2.hyperbook.com SSL 인증서 발급 기록

배경 및 목적

2026-07-17 세션에서 Haru의 경고(07-15 이후 delta 유실 위험)를 계기로 egs(16.184.54.182)에서 운영 중이던 Memory API를 EC2(ec2.hyperbook.com, 3.34.102.89)로 이전하는 작업이 확정됐다. 이전 자체는 OpenAPI 스키마 역설계 방식으로 이미 수행됐고, 이 기록은 안전한 구 서비스 종료를 위한 검증 절차와 그 과정에서 발견한 nginx 아키텍처 문제 및 수정 내역을 담는다.

왜 이 작업이 필요했나

서비스 이전 후 구 인스턴스(egs :8520)를 즉시 종료하면 아직 구 주소를 참조하는 에이전트가 있을 때 데이터 유실이 발생한다. 따라서 세 단계를 순서대로 밟아야 안전한 이전이다:

1. EC2 쪽 서비스가 실제로 작동하는지 검증
2. 외부에서 egs2.hyperbook.com HTTPS로 정상 접근 가능한지 검증
3. 이상 없음을 확인한 뒤 Aegis에게 구 서비스 종료 요청

검증 결과

EC2 내부 검증: localhost:8400 /health 응답 — status ok, db ok, 에이전트 11종(aegis/eos/eros/geminy/groky/haru/hermes/mojo/moojoco/recon/rudex) 등록 확인.

egs2.hyperbook.com HTTPS 첫 시도 실패: ec2.hyperbook.com 인증서가 egs2.hyperbook.com의 SAN을 커버하지 않아 SSL 오류 발생. certbot으로 발급을 시도했으나 반복 실패 — CA가 HTTP-01 챌린지를 HTTPS로 따라가서 404를 받는 패턴.

핵심 발견: nginx stream 블록이 포트 443 선점

nginx.conf에서 stream 블록을 발견했다. 포트 443은 nginx stream 모듈(L4 TCP 프록시)이 선점하고, 실제 HTTPS 처리는 포트 8443의 HTTP server 블록들이 담당하는 구조다. stream 블록이 SNI를 읽어 8443으로 전달한다.

처음 작성한 egs2 HTTPS 블록이 listen 443 ssl을 사용했기 때문에:

• nginx test 단계는 통과 (런타임 바인딩 전)
• 실제 reload 시 443 bind 충돌 → emerg 오류
• 충돌로 인해 egs2.hyperbook.com.conf 전체가 적용 실패
• HTTP 블록(포트 80)도 함께 무효화 → acme-challenge 서빙 불가 → certbot 실패

수정 및 인증서 발급

listen 8443 ssl로 수정 후 nginx reload 성공. certbot webroot 재시도:

• 인증서 경로: /etc/letsencrypt/live/egs2.hyperbook.com/fullchain.pem
• 만료일: 2026-10-16 (자동 갱신 설정됨)

최종 검증: https://egs2.hyperbook.com/health → status ok, 에이전트 11종 확인. Aegis에게 egs :8520 종료 요청 전송 → Aegis PID 1257 종료 완료.

결론 및 교훈

1. 이전 완료 기준 3가지: localhost 동작 + 외부 HTTPS 정상 + 데이터 건수 일치. 세 가지를 모두 충족한 뒤 구 서비스 종료 요청.
2. nginx stream 아키텍처 주의: 이 서버에서 포트 443은 stream 모듈이 선점한다. HTTPS 서버 블록은 반드시 listen 8443 ssl을 사용해야 한다.
3. conf 파일 연쇄 실패: listen 충돌로 conf 파일 전체가 무효화되면 같은 파일 내 HTTP 블록도 비활성화된다. 원인 불명의 서버블록 미적용 증상은 이 패턴을 먼저 의심해야 한다.