보안 설계 원칙과 리뷰

보안은 "나중에 추가"할 수 있는 게 아니고, 공짜도 아니야. 설계에 녹이고, 리뷰로 검증하는 것까지가 한 세트야.

이론은 다 배웠잖아. CIA, 위협 모델링, STRIDE, 암호화. 근데 실제 설계할 때 이걸 어떻게 녹이느냐가 문제야. 답은 간단해 — 보안 요구사항을 기능 요구사항처럼 관리하는 거야. 사용자 스토리에 "로그인한다"만 있으면 안 되고, "인증 실패 시 잠금 정책", "세션 만료 시간", "비밀번호 정책"이 함께 나와야 해. 백로그에 보안 항목이 있어야 하고, 우선순위가 매겨져야 하고, 추적되어야 해. "비기능 요구사항이니까 나중에"라고 미루면 결국 시간에 쫓겨서 빠져.

2장에서 만든 위협 모델이 설계의 입력이 돼야 해. 위협 모델 없이 보안 설계하면, 뭘 방어해야 하는지 모르는 상태에서 방어벽 세우는 거지. 완화 전략을 코드로 옮길 때는 검증된 프레임워크(Spring Security, Passport.js 같은)를 쓰고, 보안 로직은 비즈니스 로직과 분리해야 해. 직접 만든 인증 시스템은 수년간 쌓인 보안 패치를 모두 놓치는 거야. 그리고 각 보안 컨트롤이 실패했을 때 — 인증 서버 타임아웃, 키 로드 실패, 로그 저장소 풀 — 이 모든 시나리오에서 안전한 쪽으로 실패해야 해.

개인정보보호도 설계 원칙이야. Privacy by Design의 핵심은 "꼭 필요한 데이터만 수집하고, 수집 목적 외에 쓰지 말고, 필요 없어지면 삭제"하는 거야. "나중에 쓸지도 몰라"는 개인정보보호의 적이지. 데이터가 시스템 내에서 어디로 흐르는지 매핑해둬야 GDPR 삭제 요청에 대응할 수 있어.

그런데 보안은 항상 뭔가와 트레이드오프야. 보안 vs 사용성 — 2FA는 안전하지만 불편하고, 너무 불편하면 사용자가 우회해. 보안 vs 성능 — 암호화, 로깅, 검증은 다 자원을 먹어. 보안 vs 비용 — 스타트업이 대기업 수준의 보안을 갖추는 건 현실적으로 불가능해. 보안 vs 개발 속도 — 보안 검토, 침투 테스트는 시간이 걸려. 이 트레이드오프를 명시적으로 문서화하는 게 핵심이야. "보안보다 성능을 우선했다"는 결정을 내렸으면 그 근거와 수용한 위험을 기록해둬야 하지.

결국 이 모든 건 다시 단순성으로 돌아와. 복잡성은 보안의 적이야. 접근 제어 규칙 100개보다 10개가 관리하기 쉽고, 인증 흐름 7단계보다 3단계가 취약점 숨을 곳이 적어. 시스템이 작고 단순할수록 보안 분석이 가능하고, 분석이 가능해야 안전하다고 확신할 수 있어. 안전하다고 확신할 수 없는 시스템은 안전하지 않은 시스템이야.

설계를 다 했으면 이제 "진짜 안전한가?" 검증해야 하잖아. 보안 설계 리뷰는 코드를 한 줄도 쓰기 전에 아키텍처 수준에서 보안 결함을 찾는 과정이야. 코드 다 짜고 보안 문제 발견해서 뜯어고치는 것보다 비용이 압도적으로 적거든. 근데 리뷰가 효과적이려면 체계가 필요해. 무작정 회의실에 모여서 "보안 괜찮나?"라고 묻는 건 리뷰가 아니야. 범위를 정하고(전체 시스템? 변경된 부분?), 사전 자료를 공유하고(아키텍처 다이어그램, 데이터 흐름도, 위협 모델), 적절한 참여자를 모아야 해 — 보안 전문가, 아키텍트, 개발자, 운영 담당자가 함께.

프로세스는 5단계야. 시스템 이해 → 위협 식별(STRIDE 적용) → 완화 전략 검토 → 발견사항 문서화(심각도 분류 + 권장 조치) → 후속 조치 추적. 마지막이 핵심이야. 리뷰해서 발견사항을 문서화했는데 아무도 안 고치면, 리뷰 안 한 거랑 뭐가 달라? 이슈 트래커에 등록하고 담당자 지정해서 마감일까지 해결되도록 관리해야 해.

리뷰하다 보면 의견 충돌이 생기는 건 당연해. 보안 팀은 "위험하다", 개발 팀은 "과도한 요구다" — 이럴 때 위험 기반 의사결정으로 풀어야 해. "느낌상 위험하다"가 아니라 "이 취약점이 악용되면 몇 명의 데이터가 유출되고, 공격 난이도는 이 수준이다"라고 정량화하면 논쟁이 줄어. 모든 위험을 제거할 수 없으니 수용 가능한 위험의 기준을 조직 차원에서 합의하고, 결정을 문서화해야 해. 이건 기술적 판단이 아니라 비즈니스 판단이야. 그리고 리뷰가 "너 이거 잘못했어"라는 비난의 장이 되면 개발자들이 기피하게 돼 — 제안형 피드백이 협력을 이끌어내.

마지막으로 Kohnfelder가 강조하는 건 — 보안 설계 리뷰는 연습해야 느는 기술이라는 거야. 처음부터 완벽하게 할 수 있는 사람은 없어. 테이블탑 연습(가상 아키텍처로 위협 찾기 연습), 레드팀/블루팀(공격-방어 시뮬레이션), 타사 사고 사례 분석 — 이런 걸로 역량을 쌓아가면 돼. 체크리스트를 만들어두면 처음에는 빠뜨리는 걸 방지해주고, 경험이 쌓이면 체크리스트에 없는 것도 보이기 시작해. 중요한 건 시작하는 거야. 완벽하지 않은 리뷰라도 안 하는 것보다 압도적으로 나아.

---

정리

4장 읽고 기억할 거 세 가지:

1. 보안 요구사항을 기능 요구사항처럼 관리해야 해. 백로그에 넣고, 우선순위 매기고, 위협 모델을 설계 입력으로 써라. 트레이드오프는 명시적으로 문서화하고.
2. 리뷰는 발견에서 끝나는 게 아니라 후속 조치까지 추적해야 의미가 있어. 의견 충돌은 위험 기반으로 정량화해서 풀고, 수용한 위험은 반드시 문서화해.
3. 완벽하지 않아도 시작해. 보안 설계 리뷰는 연습으로 느는 기술이고, 복잡성은 보안의 적이니까 단순하게 만드는 데 집중해.