일기 slecs

비밀번호 노출 제거, 정적 페이지를 SSR로 전환

목차

문서 저장소에 노출된 민감정보를 정리하고, 검색엔진 최적화가 필요한 페이지들을 정적에서 동적 렌더링으로 전환했다.

배경: 왜 이런 작업이 필요했나

프로젝트가 성장하면서 문서화 범위가 늘어나다 보니, 비밀번호나 API 키 같은 민감정보가 마크다운 문서에 평문으로 산재하기 시작했다. 이건 단순히 "실수"라고 보기 어렵다. 버전 관리 시스템의 성격상, 한 번 커밋된 건 이력에 영원히 남기 때문이다. 나중에 파일을 지워도 git log에는 그대로다. 결국 팀 리뷰 단계에서 이 정보들을 외부화(externalize)하고, 환경 설정 파일(secrets.env 같은)로 분리하는 게 맞는 접근이었다.

동시에 ssul, money, insurance 같은 비즈니스 핵심 페이지들이 정적 HTML로만 제공되고 있었는데, 이들이 동적 데이터(실시간 가격, 상태, 사용자별 정보)를 포함해야 한다는 요구사항이 점차 커지고 있었다. 정적 렌더링은 빌드 타임에 HTML을 고정시키므로 서버 검증(server validation)이 필요한 콘텐츠에는 부적합하다. SSR(Server-Side Rendering)로 전환하면 매 요청 시점에 최신 정보를 가져올 수 있고, 서버에서 권한을 검증한 후 렌더링할 수 있다.

작업 내용

민감정보 외부화

변경 대상:
- docs/ad-policy.md — 광고 정책 문서의 계약 관련 정보
- docs/hedvion-CLAUDE.md — 프롬프트 엔지니어링 관련 키
- docs/seo-infra.md — SEO 인프라 설정의 토큰/크리덴셜
- docs/sites-detail.md — 사이트별 상세 설정의 비밀번호

평문으로 남아있던 모든 민감정보를 찾아내고, "secrets.env 참조"라는 주석으로 대체했다:

- AWS_KEY=sk-1234567890...
- DB_password=***
+ # AWS_KEY, DB_PASSWORD는 secrets.env 참조

이렇게 하면 문서 자체는 공개 저장소에 올릴 수 있고(CI/CD 파이프라인에서 필요한 정보는 별도로 주입), 누군가 문서를 읽을 때 "이건 민감정보니까 환경에서 가져와야 한다"는 신호를 명확하게 줄 수 있다.

정적 → SSR 전환

페이지 이전 방식 변경 후 필요한 이유
ssul(쇼핑) 정적 HTML SSR 재고, 가격 등 실시간 동기화 필요
money(결제/정산) 정적 HTML SSR 트랜잭션 상태, 서버 검증 필수
insurance(보험) 정적 HTML SSR 사용자별 정책, 권한 검증 필수

이 세 페이지를 seo-infra.md에 SSR 대상으로 명시하고, 실제 구현에서는 서버에서 요청을 받을 때마다 데이터를 최신 상태로 가져온 후 렌더링하도록 바꿨다. 이렇게 하면 캐시 전략도 더 섬세해질 수 있다(민감한 금융 데이터는 캐시하지 않고, 덜 민감한 데이터는 5분 캐시 같이).

회고: 보안과 성능의 균형

이 작업을 하면서 느낀 점들:

  • 문서 자체가 보안 경계(security boundary)다. 내부 문서라고 해서 모든 정보를 마구 써도 된다고 생각하기 쉽다. 특히 팀이 작을 때는 "나중에 정리하면 되지"라는 느낌으로 진행하다가, 어느 순간 그 정보가 외부에 노출될 수 있는 상황(퍼블릭 리포, PR 링크 공유, 문서 스크린샷 등)이 생긴다. 아무리 의도가 좋아도 리스크는 줄어들지 않는다. 초반부터 "이 정보는 sensitive하다"고 명확히 인식하는 게 중요하다.

  • 정적과 동적의 선택은 단순히 '성능'만 아니라 '데이터 신선도'와 '검증'의 문제다. 정적 렌더링은 빌드 시점의 데이터를 고정시킨다. 블로그나 마케팅 페이지에는 완벽하지만, 금융이나 쇼핑처럼 "지금 이 순간의 상태"가 중요한 도메인에서는 맞지 않는다. SSR은 느릴 수도 있지만, 서버에서 권한을 검증할 수 있고, 데이터베이스의 최신 상태를 보장한다.

  • 팀 리뷰의 중요성. 이 작업은 한 사람의 판단이 아니라 팀의 보안 정책, 기술 스택, 성능 요구사항을 모두 고려한 결과다. 특히 "SSR로 바꾸면 성능이 떨어질 수 있는데, 정산 페이지에서는 정말 필요한가?"라는 논의를 통해 트레이드오프를 명확히 할 수 있었다.

앞으로 문서나 설정을 작성할 때마다 "이 정보는 어디까지 공개해도 되나", "이 페이지는 정적이 맞나, 동적이 맞나"를 한 번 더 생각하는 습관을 들이려 한다.

🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

이어보기

댓글 0

첫 댓글 달아줘.