대상: "최소가 어느 정도인지" 잘 모르는 1인 개발자와 소규모 운영자. 공격 절차는 없습니다 — 오직 업계 표준으로 여겨지는 토대를 우선순위 순으로. 각 항목은 더 깊은 글로 연결되니, 여기서 시작해 필요한 것만 읽으면 됩니다.
본 사이트의 견해: '다 하라'가 아니라 '이 순서로 채워라'
1인 또는 소규모 팀은 한 번에 모든 걸 할 수 없습니다 — 바로 그래서 순서가 전부입니다. 최상위 계층인 "왕국의 열쇠"가 탈취되면 그 아래의 모든 통제가 무의미해집니다(공격자가 당신인 척 전부를 재설정합니다). 토대에서 위로 채우면 가진 시간 대비 사고 확률을 가장 많이 줄입니다. 이 글은 망라적 지식이 아니라 다음에 무엇을 채울지 즉시 결정하게 해주는 지도로 쓰였습니다.
Tier 0 — 왕국의 열쇠
MFA · 도메인 · DNS · 이메일 · 결제
Tier 1 — 시크릿과 코드
시크릿을 git 밖에 · 커밋 전 탐지 · 키 분리/교체
Tier 2 — 앱 자체
입력 검증 · 인증/세션 · TLS/헤더 · 이메일 인증
Tier 3 — 패치·탐지·복구
의존성 CVE · OS 업데이트 · SSH/FW · 로그 · 백업
Tier 0 — 왕국의 열쇠를 지킨다(가장 먼저)
이것이 다른 모든 것의 전제입니다. 도메인, 이메일, 호스팅 패널이 탈취되면 다른 모든 통제가 무효화됩니다. 공격자가 당신인 척 비밀번호를 재설정하고, DNS를 다시 쓰고, 서버로 들어옵니다. 그래서 가장 먼저 잠그는 곳입니다.
피싱 저항 MFA를 건다
이메일을 '부모 열쇠'로 보고 가장 단단히 지킨다
복구·백업 코드를 안전하게 보관한다
계정을 분리해 단일 실패 지점을 줄인다
Tier 1 — 시크릿이나 코드를 누출하지 않는다
본 사이트의 창립 사고도, 세상의 많은 사고도 여기의 틈에서 옵니다: .env 파일과 API 키 같은 시크릿이 코드나 공개 저장소로 흘러드는 것.
시크릿을 소스와 문서에서 빼둔다
.env로 분리하고 git에서 제외하세요(.gitignore). 애초에 적지 않는 것이 가장 강한 통제입니다.커밋 전에 기계로 시크릿을 막는다
샜다면 전부 샜다고 가정 — 전부 교체한다
토큰을 좁게 범위 짓고 짧게 유지한다
Git을 자체 호스팅한다고? 더 조심하라
GitHub의 "실수로 공개"가 무서워 자체 호스팅한다고 해서 실수로 한 커밋이 사라지진 않습니다. GitHub의 내장 시크릿 차단이 전혀 없으므로, 자체 호스팅에서는 커밋 전 시크릿 훅이 필수입니다. 자체 호스팅 Git vs GitHub: 어느 쪽이 더 안전한가 참고.
Tier 2 — 앱 자체를 단단히 한다
노출하는 웹 앱의 최소선. 핵심은 새로운 공격을 막는 게 아니라 흔하고 잘 알려진 구멍을 막는 것입니다. 본 사이트는 각각을 용어집 페이지에서 방어로 재구성합니다.
인증·세션·접근을 제대로 잡는다
이메일 스푸핑을 막는다
Tier 3 — 패치·탐지·복구
"침해 후에도 피해를 작게 하고 빠르게 복구한다"는 토대. osv-scanner 같은 의존성 모니터링이 여기 있습니다.
의존성 CVE를 기계로 지속 모니터링한다
OS와 서버를 자동 업데이트한다
SSH와 방화벽을 단단히 한다
최소 권한으로 폭발 반경을 줄인다
3-2-1 백업 + 테스트된 복원
이상을 알아챌 수 있도록 로그를 남긴다
어디서 시작할까
"전부, 지금 당장"은 현실적이지 않습니다. 사람들이 흔히 택하는 순서와 본 사이트가 권하는 순서를 비교하세요.
사람들이 흔히 택하는 순서(비효율)
- 화려한 애플리케이션 취약점 작업부터 시작
- MFA를 "나중에"로 무한히 미룸
- 백업은 있지만 복원을 시도한 적 없음
- 시크릿은
.env에 있지만 탐지 훅이 없음
본 사이트가 권하는 순서
- Tier 0: 왕국의 열쇠를 먼저 잠근다(MFA, 이메일, 도메인)
- Tier 1: 시크릿 누출을 구조적으로 막는다(커밋 전 탐지 + 전부 교체 정책)
- Tier 2: 앱의 고전적 구멍을 막는다
- Tier 3: 의존성 모니터링, 업데이트, 복원 테스트된 백업으로 "복구 가능"에 도달
본 사이트도 이 순서로 방어한다
본 사이트는 이 같은 토대를 자신에게 적용합니다: 공동 입주 없는 전용 서버(폭발 반경 분리) / 호스트마다 별도 키 / 시크릿을 git이나 문서에 절대 두지 않음 / 모든 배포 전과 매일 의존성 CVE 모니터링 / 별도 서버로의 외부 백업 / 외부 요청은 안전 경계를 통과. 보안을 가르치는 사이트가 스스로 구멍을 가질 수는 없으므로 — 우리는 이 우선순위를 먼저 우리 자신에게 돌립니다. 우리의 창립 사고 역시 새로운 공격이 아니라 이 토대의 단 하나의 틈에서 왔습니다. 그래서 우리는 늘 말합니다: 화려한 작업보다 토대를 먼저.
다음으로 읽기
- 조직 / 팀 버전: 중대규모 조직을 위한 보안 베이스라인
- 자체 호스팅: 자체 호스팅 Git vs GitHub: 어느 쪽이 더 안전한가
- 의존성: osv-scanner 설치와 사용 · CVE를 놓치지 않기
- 시크릿: .env 파일과 시크릿 · 사고 키가 새어 부정 청구됨
- 도구: 보안 헤더 검사 · 이메일 인증 검사기 · CVE/KEV 조회
FAQ
Q1인 개발자가 가장 먼저 설정해야 할 보안 통제는 무엇인가요?
'왕국의 열쇠'를 보호하세요: 도메인 등록기관, DNS, 호스팅 패널, 이메일, 결제 계정에 피싱 저항 MFA(패스키/하드웨어 키)를 거세요. 그것들이 탈취되면 다른 모든 통제가 무효화되므로 — 가장 먼저입니다.
Q모든 베이스라인 통제가 똑같이 중요한가요?
아닙니다. 명확한 순서가 있습니다. 본 사이트는 이렇게 채우길 권합니다: 1) 왕국의 열쇠, 2) 시크릿과 코드, 3) 앱 자체, 4) 패치/탐지/복구. 자원이 유한할 때 위에서부터가 사고를 가장 많이 줄입니다.
Q의존성 CVE 모니터링도 베이스라인에 들어가나요?
그렇습니다. osv-scanner나 pnpm audit으로 의존성의 알려진 취약점을 지속적으로 기계 점검하는 것은 이제 업계 표준입니다. 심각한 침해는 대부분 새로운 공격이 아니라 방치된 알려진 구멍(CVE)에서 옵니다.