thumbnail

법무가 원하는 건 결국 ‘표 1장’이다: 증거 포맷을 팀이 직접 만드는 법

오전에 법무가 슬랙을 보냈다. “고객사 실사 들어옵니다. 우리가 안전하다는 ‘근거’ 정리해 주세요.”

처음엔 다들 익숙한 답을 꺼냈다. 아키텍처 그림, 보안 설정 문서, 지난 분기 사고 보고서.

법무는 잠깐 멈췄다가 말하더라. “그런데 이건… 읽는 사람이 다 해석해야 하네요.”

조달 쪽도 비슷한 얘기를 했다. “우리는 선택지를 비교해야 해요. 같은 포맷으로요.”

그 순간 깨달았다. 이건 ‘보안 설명’이 아니라 ‘증거 포맷’ 싸움이다.

그리고 그 포맷은 생각보다 단순하다.

그 말은 결국 “표 1장”이다. 항목/검증방법/검증일/담당자/증거 링크.

표로 못 내놓으면, 팀이 아무리 열심히 해도 상대는 “그럼 누가 언제 확인했죠?”를 다시 묻는다.

그때부터 회의가 시작된다. 기능 얘기는 사라지고, 사람마다 다른 ‘정상’의 정의만 남는다.

그래서 나는 그날 오후에 결심했다. 기능을 더 붙이기 전에 표를 만든다. 안전하냐의 문제가 아니라, 안전을 ‘같은 모양’으로 보여줄 수 있냐의 문제였으니까.

표 1장에 들어가는 3개 줄

표 1장은 글이 아니다. 줄 세 개로 끝나야 한다. (그래야 조달이 읽고, 법무가 붙이고, 보안이 유지한다.)

1) Transparency 페이지(무엇/언제/누가)

무엇: 공개할 항목을 3~5개로 줄인다. 보안/가용성/정책 변경 같은 “이벤트가 생기는 것” 위주.
언제: 주기나 트리거를 명시한다. 매주 업데이트인지, 릴리스 때만인지, 사고 발생 시인지.
누가: 오너를 이름(팀)으로 박는다. “보안팀” 말고 “SecOps 온콜” 같이.
표에서 중요한 건 ‘완벽’이 아니라 ‘비교 가능’이다. 지난달과 이번달을 같은 칸에서 볼 수 있어야 한다.
Cloudflare Radar가 주는 힌트는 이거다. 멋진 대시보드가 아니라, 바깥 사람이 같은 방식으로 확인할 수 있는 고정된 창구. (참고: Cloudflare Radar)

2) 경로/연쇄 로그(최소 필드 스키마 1개)

여기서 말하는 경로는 거창한 네트워크만이 아니다. “어떤 단계로 처리됐나”의 체인이다.
ASPA가 흥미로운 이유도 ‘누가 시작했나’가 아니라 ‘경로가 맞나’를 보려는 시도라서다. (참고: Cloudflare ASPA)
최소 스키마는 과감히 줄인다. 그래도 빠지면 안 되는 필드는 있다.
예: time / actor / action / resource / policy_version / evidence_ref
이 여섯 개가 있으면, 나중에 “왜 그렇게 됐죠?”를 최소한 ‘추적’은 할 수 있다.

3) 승인 레터(한 장: 범위/예외/만료)

승인 레터는 기술 문서가 아니다. 조달/실사가 붙일 수 있는 한 장짜리다.
범위: 어디까지 승인인지(제품/환경/데이터 등급)를 한 문단으로.
예외: “이 경우는 제외”를 두세 줄로. 예외가 없으면 나중에 예외가 생긴다.
만료: 이게 중요하다. 승인에는 유효기간이 있다(다음 분기 재검토 등).
NATO의 사례는 과장할 필요 없다. ‘승인/인증 문서가 조달 결정을 움직인다’는 사실만 충분하다. (참고: NATO iOS 기사)

오늘 바로 만들 수 있게: 샘플 템플릿

아래는 “표 1장”을 실제로 만드는 데 쓰는 최소 양식이다. 복붙해서 시작하고, 맞는 항목만 남겨도 된다.

채우는 규칙은 세 가지다: (1) 증거는 링크 여러 개 말고 evidence_ref 하나로 고정, (2) 검증일은 비우면 그 항목은 ‘미검증’으로 친다, (3) 담당자는 팀 이름이 아니라 온콜/오너로 쓴다.

(A) Transparency 표(5행)

항목	검증방법	검증일	담당자	evidence_ref
암호/키 관련 운영 상태	주간 점검 + 자동 리포트	YYYY-MM-DD	SecOps On-call	TICKET-123
라우팅/경로 보안 상태	주간 점검 + 외부 기준 대비	YYYY-MM-DD	NetOps On-call	TICKET-456
접근권한 변경 이력	PR/티켓 기반 검토	YYYY-MM-DD	Platform Eng	(내부 링크)
데이터 처리 위치/보관 정책	분기 정책 리뷰	YYYY-MM-DD	DPO/보안	(내부 링크)
사고/중단 공지 프로세스	드릴(연습) 결과 기록	YYYY-MM-DD	SRE	(내부 링크)

(B) 최소 로그 스키마(코드블록)

# evidence-log v1
- time: "2026-03-01T01:00:00Z"
  actor: "svc/agent-runner"        # 사람/서비스 계정
  action: "deploy.requested"       # 무엇을 했나
  resource: "prod/api"             # 대상
  policy_version: "policy-2026-03" # 적용 규칙 버전
  evidence_ref: "TICKET-123"       # 증거(티켓/PR/리포트) 1개로 고정

AWS의 COBOL 현대화 글이 계속 떠오르는 이유도 이 지점이다. 생성/변경 자체보다 “이게 왜 이렇게 됐는지”를 다시 따라갈 수 있어야 프로젝트가 산다. (참고: AWS COBOL modernisation)

결론: 팀이 싸우는 시간을 줄이는 건 기능이 아니라 포맷이다

표를 만들기 전엔, 질문이 늘 같은 데로 돌아왔다. “누가 확인했죠?” “최신이 맞나요?” “이건 예외인가요?”

표를 만든 뒤엔 질문이 바뀐다. “이 항목은 다음 주에 업데이트되나요?” “증거 링크가 비었네요.”

덜 멋진 질문이다. 대신 더 건강한 질문이다.

기능을 더 붙여서 해결되는 일이 아니다. 포맷이 없어서 싸우던 시간을, 포맷 덕분에 줄이는 거다.

그리고 웃기게도, 이게 제일 빠른 보안 개선처럼 느껴질 때가 있다. 적어도 ‘증거를 남기는 습관’이 생기니까.

참고자료

Cloudflare Blog — Bringing more transparency to post-quantum usage, encrypted messaging, and routing security
- https://blog.cloudflare.com/radar-origin-pq-key-transparency-aspa/
Cloudflare Blog — ASPA: making Internet routing more secure
- https://blog.cloudflare.com/aspa-secure-internet/
Computerworld — NATO approves iPhone and iPad to handle classified info
- https://www.computerworld.com/article/4137985/nato-approves-iphone-and-ipad-to-handle-classified-info.html
AWS ML Blog — Learnings from COBOL modernization in the real world
- https://aws.amazon.com/blogs/machine-learning/learnings-from-cobol-modernization-in-the-real-world/

zzodosa life

이 블로그 검색

법무가 원하는 건 결국 ‘표 1장’이다: 증거 포맷을 팀이 직접 만드는 법

법무가 원하는 건 결국 ‘표 1장’이다: 증거 포맷을 팀이 직접 만드는 법

표 1장에 들어가는 3개 줄

1) Transparency 페이지(무엇/언제/누가)

2) 경로/연쇄 로그(최소 필드 스키마 1개)

3) 승인 레터(한 장: 범위/예외/만료)

오늘 바로 만들 수 있게: 샘플 템플릿

(A) Transparency 표(5행)

(B) 최소 로그 스키마(코드블록)

결론: 팀이 싸우는 시간을 줄이는 건 기능이 아니라 포맷이다

참고자료

댓글

댓글 쓰기