SECURITY.md — 보안 규칙 (루트)

website: SECURITY.md 구조 개선 및 개인정보 보호 강화

멋사 경희대 웹사이트 개발 프로젝트에서 보안 문서를 체계화하고 개인정보 보호를 강화한 PR입니다.

요약

이 PR은 기존에 흩어져 있던 보안 관련 내용을 SECURITY.md라는 새로운 문서 구조로 재정비하고, 개인정보가 포함될 수 있는 pm/applicants/ 디렉토리가 .gitignore에 누락된 점을 수정하여 보안 체계를 강화했습니다. PR은 dev 브랜치에 성공적으로 병합되었습니다.

배경 및 목적

기존에는 보안 관련 내용이 CLAUDE.md에 혼재되어 있어, 각 도메인별(백엔드, 프론트엔드, 인프라, PM) 특화된 보안 규칙을 찾거나 적용하기 어렵다는 문제가 있었습니다. 또한, 보안 규칙이 항상 로드되어 불필요한 오버헤드를 발생시킬 수도 있었습니다. 더불어, 지원자의 개인정보가 포함될 수 있는 pm/applicants/ 디렉토리가 .gitignore에 포함되지 않아 실수로 커밋될 위험이 있었습니다.

이 PR은 다음과 같은 목적을 가지고 진행되었습니다.

1. 보안 규칙 구조화: 도메인별 특성에 맞는 보안 규칙을 명확히 분리하여 관리하기 용이하게 합니다.
2. Lazy Loading 도입: 필요한 경우에만 보안 문서를 로드하여 성능 효율성을 높입니다.
3. 개인정보 보호 강화: 민감한 개인정보가 포함된 디렉토리를 .gitignore에 추가하여 실수로 커밋되는 것을 방지합니다.

구현 내용

주요 변경사항은 다음과 같습니다.

새로운 SECURITY.md 구조 도입

기존 CLAUDE.md의 보안 섹션을 분리하여 다음과 같은 상속 구조를 가진 SECURITY.md 파일들을 새롭게 생성하고 구성했습니다.

• SECURITY.md (루트): 모든 도메인에 공통으로 적용되는 보안 규칙을 담고 있습니다. 시크릿, 개인정보(PII) 취급 관련 내용을 포함하며, CLAUDE.md는 이 문서로 연결되는 레이지로드 포인터만 남게 됩니다.
• pm/SECURITY.md, infra/SECURITY.md, backend/SECURITY.md, frontend/SECURITY.md: 각 도메인별 특화된 보안 규칙을 담는 파일들입니다. 현재는 아직 구체적인 사고나 결정이 없었기에 규칙 내용은 비어 있지만, "언제 채워지는지"에 대한 명확한 안내를 추가하여 추후 관련 이슈 발생 시 즉시 규칙을 추가할 수 있도록 트리거를 명시했습니다.

이 구조는 마치 객체지향 프로그래밍의 상속처럼, CLAUDE.md에서 필요에 따라 루트 SECURITY.md를 읽고, 거기서 다시 해당 도메인의 SECURITY.md를 읽는 방식(Lazy Loading)으로 동작합니다.

.gitignore에 pm/applicants/ 추가

커밋 메시지에서 언급된 것처럼, pm/applicants/ 디렉토리가 .gitignore에 누락되어 지원자의 실명, 연락처 등 개인정보가 실수로 커밋될 위험이 있었습니다. 이번 PR에서 해당 디렉토리를 .gitignore에 추가하여 구조적으로 개인정보 유출 위험을 차단했습니다.

변경된 파일 목록

• .gitignore
• CLAUDE.md
• SECURITY.md
• backend/SECURITY.md
• frontend/SECURITY.md
• infra/SECURITY.md
• pm/SECURITY.md

핵심 코드 설명

.gitignore 파일에 /pm/applicants/ 라인이 추가되었습니다.

--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@
 /node_modules
 /dist
 /.next
+/pm/applicants/

새롭게 생성된 SECURITY.md 파일들은 다음과 같이 내용이 구성되었습니다.

SECURITY.md (루트)의 일부:

## 이 문서는 무엇인가

전 도메인에 공통으로 적용되는 보안 규칙. "이 레포에서 일할 때n무조건 지켜야 하는 것"만 담는다. 도메인 특화 규칙(예: 백엔드 인증 방식, 인프라 시크릿 관리 방식)은 여기 넣지 않고 각 도메인 `SECURITY.md`로 보낸다.

## 왜 이 레포에서 특히 중요한가

**이 레포는 public.** 코드·커밋·PR·이슈가 전부 공개다. 사고가 나면 "삭제"로 안 끝난다 — git 히스토리에 영구히 남는다.

## 시크릿 — 어떤 추적 파일에도 평문으로 쓰지 않는다

`CLAUDE.md` 포함, 어떤 파일에도 GitHub 토큰·API 키·DB 비밀번호 등을 쓰지 않는다. 커밋되는 순간 공개 유출이고, revert 해도 히스토리에 남는다.

- `gh`/`git` 인증이 필요하면 **명령 실행 시점에만 인라인으로** 전달하고 끝나면 버린다 (예: `GH_TOKEN=... gh issue list`, 1회성 `git push https://user:TOKEN@github.com/...`). 어떤 파일에도, `git remote set-url`에도 저장하지 않는다.
- `gh auth login`으로 전역 계정을 바꾸지 않는다 — 사람의 다른 세션(회사 계정 등)이 쓰는 `gh` 기본 계정을 건드리게 된다. 필요하면 사람에게 먼저 물어본다.
- 토큰을 어디에라도 이미 썼다면(파일 커밋·설정 저장 등) **push 전에 반드시 되돌린다.** 실수했으면 바로 알리고, 필요시 토큰 재발급을 사람에게 요청한다.
- 자동 방어망: `.gitleaks.toml` + `.githooks/pre-commit` (커밋 시점 시크릿 스캔 — 최초 1회 `git config core.hooksPath .githooks` 필요, 로컬 설정이라 레포에 커밋해도 자동 적용 안 됨). 이건 최후의 그물이지 1차 방어가 아니다 — 애초에 안 쓰는 게 먼저다.

## 개인정보(PII)

지원자 실명·연락처 등 실제 개인정보(`pm/applicants/` 등)는 **커밋하지 않는다.** 발견하면 사람에게 알린다. QA·보안 검증 문서에 재현 정보를 남길 때도 실제 개인정보는 요지만 적고 상세는 비공개 채널로 전달한다.

## 도메인별 규칙 (레이지로드)

작업 중인 도메인에 해당하는 문서만 그때 읽는다:

| 도메인 | 문서 |
|---|---|
| PM/운영 | [`pm/SECURITY.md`](./pm/SECURITY.md) |
| 인프라 | [`infra/SECURITY.md`](./infra/SECURITY.md) |
| 백엔드 | [`backend/SECURITY.md`](./backend/SECURITY.md) |
| 프론트엔드 | [`frontend/SECURITY.md`](./frontend/SECURITY.md) |

## 이 문서에 언제 내용을 추가하나

- 보안 사고·취약점이 발생했고 재발 방지 규칙이 **모든 도메인에 공통으로** 적용될 때
- 한 도메인에서 정한 규칙이 사실 전 도메인에 적용돼야 한다고 판명될 때(도메인 문서에서 승격)

도메인 한정 규칙은 여기 말고 해당 도메인 `SECURITY.md`에 남긴다.

배운 점 및 개선점

이번 PR을 통해 GitHub 저장소 내에서 보안 문서를 체계적으로 관리하는 방법론에 대해 배울 수 있었습니다. 특히, 공통 규칙과 도메인별 특화 규칙을 분리하고, 필요할 때만 문서를 로드하는 Lazy Loading 방식은 코드 베이스의 복잡성을 관리하는 데 유용하다는 것을 알게 되었습니다. 또한, .gitignore 설정의 중요성을 다시 한번 깨닫고, 개인정보와 같은 민감한 정보는 저장소에 커밋되지 않도록 사전에 방지하는 것이 얼마나 중요한지 실감했습니다.

앞으로 개선할 점은 다음과 같습니다.

• 각 도메인별 SECURITY.md에 실제 적용될 수 있는 보안 규칙을 구체적으로 작성하는 작업이 필요합니다. 이는 팀원들과의 논의를 통해 진행될 수 있습니다.
• Lazy Loading을 위한 CLAUDE.md의 포인터가 제대로 작동하는지, 그리고 실제 보안 관련 작업 시 자연스럽게 해당 문서가 로드되는지 테스트 및 검증이 필요합니다.