보안 가드의 적정 강도 — 위협 모델링으로 결정한 회고

화면 readonly 처리 후, 가드의 적정 강도를 결정해야 했습니다

운영 중인 SaaS의 매장 관리 화면을 정비하다가 결정 사안이 있었습니다.

외부 동기화 정보(메뉴·운영 시간 같은 항목)는 본사·매장 관리자 모두 수정할 수 없어야 했습니다. 화면에서는 readonly 처리가 끝났어요. pointer-events-none + opacity-70으로 입력 자체가 막히고, "외부에서 동기화되는 정보. 직접 수정 불가" 안내 박스도 띄웠습니다.

여기서 결정해야 할 사안이 남았습니다.

"백엔드 가드의 강도를 어떻게 가져갈 것인가?"

옵션은 세 가지였습니다.

화면 readonly만 유지하고 백엔드는 평소대로 동작

백엔드에서 페이로드를 받으면 해당 필드는 무시 (ignore)

백엔드에서 명시적으로 400 에러로 거부 (block)

다층 방어 원칙(Defense in Depth)으로 보면 백엔드 가드를 같이 깔아두는 게 보통 맞습니다. 그런데 가드 강도를 결정하기 전에 위협 모델을 먼저 그려보기로 했습니다. 어떤 위협을 어디서 막을지가 명확해야 가드 강도가 적정 수준으로 잡힙니다.

이번 글은 그 위협 모델링 과정과 일반화 가능한 의사결정 프레임을 정리한 회고입니다.

다층 방어의 적정 깊이를 어떻게 결정할까

보안 가드를 결정할 때 두 가지 사고 흐름이 있습니다.

사고 흐름 A — 일반 원칙 적용

"Defense in Depth — 다층 방어는 보안의 기본"

"Fail-Safe Defaults — 기본은 거부"

"막을 수 있는 자리에는 가드를 둔다"

이 원칙들은 일반적으로 맞습니다. 보안 설계의 기본 원칙이고, 대부분의 경우 이대로 따라가도 됩니다.

사고 흐름 B — 위협 모델링 기반 조정

"실제로 가능한 공격 시나리오는 무엇인가"

"이미 깔린 안전장치가 어디까지 막아주는가"

"이 자리의 가드가 막아주는 추가 위험은 얼마나 큰가"

"가드 추가 비용 vs 추가 보안 이득"

위협 모델링은 일반 원칙을 현재 시스템 조건에 맞게 조정하는 도구입니다. 원칙을 부정하는 게 아니라, 원칙을 어떻게 적용할지 정밀하게 결정합니다.

두 흐름을 합치면 이렇게 됩니다.

1. 일반 원칙으로 기본 방어 설계
2. 위협 모델링으로 적정 깊이 조정
3. 조건이 바뀌면 가드 강화 (재평가)

이번 케이스에서 다섯 가지 안전장치가 이미 깔려 있는 상태였습니다. 인증(JWT), 권한 검증(관리자 타입), 화면 readonly, 안내 박스, 외부 시스템 동기화. 여기에 백엔드 가드를 더 깔지를 위협 모델링으로 결정했습니다.

같은 시스템에서 다른 영역(LLM 출력)에는 4단계 가드를 깔았어요. 영역마다 위협이 다르니 적정 강도가 달라지는 게 자연스럽습니다.

위협 모델링 4가지 질문

위협 모델링에서 던진 네 가지 질문을 정리하면 이렇습니다.

1. 어떤 공격 시나리오가 실제로 가능한가

이 매장 관리 화면은 JWT 인증 + 관리자 타입 검증을 통과해야만 호출 가능합니다. 인증 없이 외부에서 API를 직접 때리는 시나리오는 인증 레이어가 차단합니다.

남는 시나리오는 두 가지였습니다.

인증을 통과한 내부 관리자가 의도적으로 우회

토큰 탈취 후 정상 권한자로 가장

토큰 탈취 시나리오는 별도 보안 정책(토큰 만료·갱신·IP 제한)에서 다루는 영역이고, 이번 결정의 범위를 벗어났습니다. 이번 가드가 막아야 할 위협은 인증 통과한 내부 관리자의 의도적 우회 시나리오로 좁혀졌습니다.

2. 이미 깔린 안전장치가 어디까지 막아주는가

인증 (JWT) — 통과한 사람만 진입

권한 검증 (관리자 타입) — 권한 없는 사람 차단

화면 readonly — 일반 흐름에서 입력 자체 차단

안내 박스 — 수정 불가임을 명시적으로 알림

네 단계가 이미 깔려 있었습니다. 일반 흐름에서 수정 가능성은 차단된 상태였어요.

3. 우회 시 영향이 어떻게 지속되는가

여기서 결정적인 정보가 있었습니다. 이 데이터는 외부 시스템에서 주기적으로 동기화되는 정보였습니다.

내부 관리자가 일부러 API를 우회해서 메뉴를 수정했다고 가정해봅니다.

T 시점: 내부 관리자가 우회해서 메뉴 변경

T+1 시점: 외부 동기화 작업이 돌면서 변경된 메뉴를 다시 덮어쓰기

결과: 우회로 변경한 데이터가 자동 정정

우회의 영향이 다음 동기화 주기에 자동 복구되는 구조였습니다. 영구 변경이 아닌 일시적 우회입니다.

4. 이 가드가 막아주는 추가 위험은 얼마나 큰가

세 질문의 답을 종합했습니다.

외부 공격은 인증·권한이 막음

토큰 탈취는 별도 정책 영역

내부자 의도적 우회는 외부 동기화로 자동 정정

화면 readonly + 안내 박스로 일반 흐름은 차단

백엔드 가드가 막아주는 추가 위험은 "내부 관리자가 의도적으로 우회해서 메뉴를 잠깐 바꿔놓은 상태(다음 동기화 전까지)"입니다. 이 위험의 비즈니스 영향이 가드 추가 비용과 비교해 어느 쪽이 큰지를 봤어요.

가드 추가 비용 — 코드·테스트·이해 부담, 향후 외부 동기화 정책 변경 시 가드 위치 재조정 부담.

추가 보안 이득 — 다음 동기화까지의 일시적 데이터 일관성.

저울질했을 때 이번 조건에서는 가드 없이 가는 게 적정 수준이었습니다. 단, 반례 조건이 발생하면 즉시 가드를 강화한다는 전제가 함께 갔습니다.

3가지 옵션의 트레이드오프

가드 강도 옵션 세 가지의 트레이드오프를 정리하면 이렇습니다.

이번 케이스는 옵션 A를 선택했지만, 다른 영역에서는 옵션 C가 맞습니다. 같은 시스템 안에서도 영역마다 적정 강도가 다릅니다.

예를 들어 같은 시스템의 결제·정산 영역은 옵션 C로 갑니다. 영구 변경 데이터고 감사 추적이 필요하기 때문입니다. 외부 동기화로 정정되지 않는 영역에는 백엔드 가드를 명시적으로 둡니다.

이 결정이 다른 조건에서는 정반대가 됩니다

이번 결정은 특정 조건에서만 적정 수준입니다. 반례 조건이 발생하면 가드를 즉시 강화한다는 전제가 같이 갔습니다.

가드 강화가 필요한 조건

인증·권한 강도가 약해진 경우 — 토큰 정책이 약하거나, 인증 우회 가능성이 발견되면 백엔드 가드 강화

외부 동기화가 사라지는 경우 — 동기화 정책이 바뀌어서 영구 변경 데이터가 되면 가드 추가

감사 추적 요구가 추가되는 경우 — 컴플라이언스 변경이나 도메인 확장(금융·의료)으로 모든 변경 추적이 필요해지면 명시적 거부 필수

외부 공격 가능성이 생기는 경우 — 인증을 거치지 않는 새로운 API 경로가 추가되면 가드 필수

팀 규모가 커지는 경우 — 1인 운영이면 위협 모델이 단순하지만, 팀 규모에서는 "다른 사람의 실수" 시나리오가 추가됨

이 조건들이 발생하면 옵션 A는 더 이상 적정 수준이 아닙니다. 위협 모델링은 한 번 하고 끝이 아니라 조건 변화에 따라 재평가하는 도구입니다.

의사결정자가 점검할 4가지

보안 가드·검증 로직·접근 제어의 적정 강도를 결정하실 때 점검할 일반 체크리스트입니다.

1. 일반 원칙으로 기본 방어를 설계합니다

Defense in Depth, Fail-Safe Defaults 같은 보안 원칙으로 기본 방어를 설계합니다. 위협 모델링은 원칙을 부정하는 게 아니라, 원칙을 어떻게 적용할지 결정하는 도구입니다.

2. 위협 모델링으로 적정 깊이를 조정합니다

실제 공격 시나리오, 기존 안전장치 커버리지, 우회 영향의 지속성, 가드 추가의 비용·이득을 분석합니다. 위협 모델링이 깊을수록 가드 강도가 정밀해집니다.

3. 영역별로 다른 강도를 가져갑니다

같은 시스템 안에서도 영역마다 위협이 다릅니다. 외부 동기화 영역은 가벼운 가드로, 결제·정산·인증 영역은 무거운 가드로. "한 시스템 = 한 강도"가 아닙니다.

4. 조건 변화 시 재평가 절차를 만듭니다

위협 모델링은 한 번 하고 끝이 아닙니다. 인증 정책 변경, 동기화 정책 변경, 컴플라이언스 추가, 팀 규모 확장 같은 조건 변화가 있으면 가드를 재평가합니다. 변화 시그널을 누가 감지하고 어떻게 재검토할지 절차로 둡니다.

비슷한 발상이 다른 운영 결정에서도 흐릅니다. 일반 원칙을 출발점으로 두되 현재 조건에 맞게 정밀 조정하는 것, 영역마다 다른 강도를 인정하는 것, 조건 변화에 따라 재평가하는 것. 운영 환경에서 보안과 효율의 균형을 맞추는 핵심 기준입니다.

마무리

매장 관리 화면의 외부 동기화 정보에 백엔드 가드 강도를 결정해야 했습니다. 다층 방어 원칙으로 시작해서 위협 모델링으로 적정 깊이를 조정했고, 이번 조건에서는 화면 readonly + 안내 박스 + 외부 동기화 자동 복구가 적정 수준이라는 결론에 이르렀습니다. 단, 조건이 바뀌면 즉시 가드를 강화한다는 재평가 전제가 같이 갔습니다.

핵심 교훈은 세 가지입니다.

원칙은 출발점, 위협 모델링은 조정 도구 — Defense in Depth를 적용하되 영역 조건에 맞게 깊이를 정밀 조정

같은 시스템 안에서도 영역마다 가드 강도가 다르다 — 외부 동기화 영역과 결제·정산 영역의 위협이 다름

조건 변화 시 재평가가 필수 — 위협 모델링은 한 번 하고 끝이 아니라 조건 변화 시그널에 따라 재검토하는 도구

보안 가드·접근 제어·검증 로직의 강도를 검토하신다면, 이번 글의 4가지 체크리스트(기본 방어 설계 / 위협 모델링 / 영역별 강도 / 재평가 절차)를 한 번 살펴보시길 추천합니다. 일반 원칙과 현재 조건을 함께 보면 가드가 적정 수준에서 잡힙니다.