💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며 — 왜 지금 이 주제인가

2026년의 기술 커뮤니티에서 감시(surveillance)는 더 이상 음모론자의 단어가 아닙니다. 최근 몇 달 사이 GeekNews와 Hacker News의 상위권을 차지한 세 가지 흐름이 이 주제를 정면으로 끌어올렸습니다.

첫째, Oracle 공동창업자 Larry Ellison의 발언이 다시 회자되고 있습니다. AI 기반 감시 시스템을 논하며 그는 이렇게 말했습니다. "시민들은 최선의 행동을 하게 될 것이다. 우리가 일어나는 모든 일을 상시 녹화하고 보고하기 때문이다." 치안 향상의 약속으로 포장됐지만, 많은 이들에게 이 문장은 프라이버시 침식에 대한 디스토피아적 경고문처럼 읽혔습니다. 그리고 Oracle은 실제로 그런 인프라를 팔 수 있는 회사입니다.

둘째, coveillance.org의 "시애틀 감시 인프라 도보 투어" 글이 Hacker News에서 큰 화제가 됐습니다. 평범한 길거리를 걸으며 CCTV, 차량 번호판 자동 인식기(ALPR), 교통 센서, 사설 초인종 카메라가 어디에 어떻게 박혀 있는지를 안내하는 이 글은, 감시가 추상적 담론이 아니라 물리적으로 존재하는 도시 기반시설임을 보여줬습니다.

셋째, 여러 국가에서 진행 중인 연령 인증 의무화 입법입니다. 미성년자 보호라는 명분 아래, 성인 사이트와 SNS 접속에 신원 확인을 요구하는 법들이 확산되고 있습니다. 보호의 목적은 정당하지만, 구현 방식에 따라 "모든 시민의 인터넷 사용에 실명 꼬리표를 다는" 인프라가 될 수 있다는 점에서 기술 커뮤니티의 논쟁이 뜨겁습니다.

이 세 흐름의 공통점은 무엇일까요. 그 시스템들 전부, 우리 같은 개발자가 만든다는 것입니다. 카메라 펌웨어, 영상 분석 모델, 위치 데이터 파이프라인, 연령 인증 API — 어느 것도 저절로 생겨나지 않습니다. 이 글은 "감시 기술이 나쁘다"는 선언문이 아니라, 그 기술을 만드는 자리에 앉은 개발자가 가져야 할 판단 기준과 실무 도구(프라이버시 엔지니어링)를 정리하는 글입니다.

2026년 감시 논쟁의 지형

논쟁의 축을 먼저 정리합니다. 감시 기술을 둘러싼 입장은 단순한 찬반이 아니라 대략 네 사분면으로 나뉩니다.

안전 우선

(A) 전면 도입 | (B) 조건부 도입

"기술이 범죄를 | "효과 입증 + 영장주의

예방한다" | + 감사 가능성 전제"

국가/기업 통제 ------+------ 시민 통제

"감시 인프라는 | "만들더라도 최소화/

존재 자체가 | 분산화/투명성을

위험" | 기술로 강제"

자유 우선

개발자 관점에서 현실적인 자리는 대부분 (B)와 (D) 사이입니다. 우리는 보통 시스템 도입 여부를 결정하는 자리에 있지 않지만, 어떻게 만들지는 상당 부분 우리 손에 있기 때문입니다. 같은 요구사항이라도 "전 국민 위치 이력을 중앙 DB에 평문으로 5년 보관"과 "단말 내 처리 + 집계만 전송 + 90일 자동 파기"는 완전히 다른 시스템입니다.

감시 기술의 스펙트럼 — 무엇이 어디까지 와 있나

도보 투어 글이 보여주듯, 감시는 단일 기술이 아니라 겹겹의 레이어입니다.

| --- | --- | --- | --- |

중요한 통찰은 위험이 레이어 단독이 아니라 결합에서 온다는 것입니다. ALPR 한 대는 도난 차량을 찾는 도구지만, 도시 전체의 ALPR 기록을 시간순으로 연결하면 특정 시민이 언제 병원, 집회, 종교 시설에 갔는지 복원할 수 있습니다. 데이터 브로커 생태계는 이런 결합을 상업적으로 수행합니다. 그래서 프라이버시 엔지니어링의 핵심 질문은 "이 데이터가 유출되면?"이 아니라 "이 데이터가 다른 데이터와 결합되면?"입니다.

개발자가 마주치는 순간들 — 윤리는 추상이 아니라 티켓으로 온다

윤리적 선택은 대개 거창한 회의가 아니라 평범한 업무 티켓의 모습으로 도착합니다. 실제로 마주치게 되는 장면들을 봅시다.

장면 1: 로깅 과수집

"디버깅을 위해 요청 전체를 로깅해 주세요"라는 티켓. 요청 본문에는 사용자의 검색어, 위치, 때로는 건강 관련 키워드가 들어 있습니다. 전체 로깅은 디버깅에 편하지만, 그 로그는 사실상 그림자 프로필이 됩니다. 접근 통제가 허술한 로그 시스템은 회사에서 가장 큰 비공식 감시 인프라인 경우가 많습니다.

장면 2: 트래킹 SDK 추가 요청

마케팅팀이 전환 측정을 위해 서드파티 SDK 추가를 요청합니다. SDK 문서를 읽어 보면 광고 ID, 설치 앱 목록, 정밀 위치까지 수집합니다. "우리는 전환 데이터만 쓸 건데요"라고 해도, 데이터는 SDK 벤더의 서버로 가고 그들의 약관에 따라 재사용됩니다. 여러분이 한 줄 추가한 SDK가, 사용자의 위치를 데이터 브로커 생태계로 보내는 첫 관문이 될 수 있습니다.

장면 3: 다크패턴 요구

"동의율이 낮으니 거부 버튼을 두 단계 안쪽으로 옮겨 주세요"라는 요청. 법적으로 동의는 받았다고 주장할 수 있을지 몰라도, 설계 의도 자체가 사용자의 진의를 우회하는 것입니다. GDPR과 한국 개인정보보호법 모두 형식적 동의가 아닌 실질적 동의를 요구하는 방향으로 집행이 강화되어 왔고, 다크패턴 자체를 제재한 사례도 쌓이고 있습니다.

장면 4: "일단 다 모아두자"

"나중에 뭐가 필요할지 모르니 일단 다 수집해서 데이터 레이크에 넣어 두자"는 아키텍처 결정. 머신러닝 시대의 흔한 유혹이지만, 목적 없는 수집은 대부분의 개인정보 법제에서 그 자체로 위법 소지가 있고, 보안 사고 시 피해 범위를 무한정 키웁니다. 2026년 npm 공급망 공격 사례들이 보여주듯, 침해는 "당할지"가 아니라 "언제 당할지"의 문제입니다. 가지고 있지 않은 데이터는 유출되지 않습니다.

프라이버시 엔지니어링 실무 1 — 데이터 최소화 설계

원칙은 한 문장입니다. **목적에 필요한 최소한만, 필요한 기간만, 필요한 사람에게만.** 이를 코드와 스키마 수준에서 강제하는 것이 프라이버시 엔지니어링입니다.

수집 시점 최소화 — 스키마로 강제하기

-- 나쁜 설계: "일단 다 저장"

CREATE TABLE user_events_bad (

id BIGSERIAL PRIMARY KEY,

user_id BIGINT,

raw_request JSONB, -- 요청 전체 덤프 (검색어, 위치, 모든 것)

ip_address INET,

user_agent TEXT,

created_at TIMESTAMPTZ

);

-- 나은 설계: 목적별 칼럼 + 가명화 + 보존 기한 내장

CREATE TABLE user_events (

id BIGSERIAL PRIMARY KEY,

user_pseudo TEXT NOT NULL, -- 일방향 가명 ID (원본 매핑은 분리 보관)

event_type TEXT NOT NULL, -- 정의된 이벤트만 (자유 텍스트 금지)

coarse_geo TEXT, -- 시/도 수준으로 절삭된 위치

created_at TIMESTAMPTZ NOT NULL DEFAULT now(),

expires_at TIMESTAMPTZ NOT NULL -- 행 단위 보존 기한을 데이터에 내장

DEFAULT now() + INTERVAL '90 days'

);

-- 파기를 운영 절차가 아닌 시스템 동작으로

CREATE INDEX idx_user_events_expiry ON user_events (expires_at);

포인트는 expires_at입니다. 보존 기한을 정책 문서에만 적어 두면 아무도 지키지 않습니다. 행 단위로 만료 시각을 박아 두고, 삭제 작업이 그 칼럼만 보고 동작하게 만들면, 보존 정책이 코드가 됩니다.

보존 기한 자동화 — 파기를 기본값으로

retention_worker.py — 보존 기한 자동 집행 워커

from datetime import datetime, timezone

RETENTION_POLICIES = {

테이블: (보존 근거, 파기 방식)

"user_events": ("서비스 품질 분석, 90일", "hard_delete"),

"access_logs": ("보안 감사, 180일", "hard_delete"),

"payment_records": ("세법상 의무 보존 5년", "archive_then_delete"),

"support_tickets": ("분쟁 대응 3년", "anonymize"), # 삭제 대신 익명화

}

def enforce_retention(db, now=None):

now = now or datetime.now(timezone.utc)

report = []

for table, (basis, method) in RETENTION_POLICIES.items():

if method == "hard_delete":

n = db.execute(

f"DELETE FROM {table} WHERE expires_at < %s", (now,)

).rowcount

elif method == "anonymize":

n = db.execute(

f"UPDATE {table} SET user_pseudo = 'expired', "

f"free_text = NULL WHERE expires_at < %s", (now,)

).rowcount

else:

n = archive_then_delete(db, table, now)

report.append((table, basis, method, n))

logging.info("retention: table=%s purged=%d basis=%s", table, n, basis)

return report # 이 리포트 자체가 컴플라이언스 증적이 된다

세 가지를 강조하고 싶습니다.

1. **파기 로그가 곧 증적입니다.** "우리는 90일 후 파기한다"는 주장은 파기 작업의 실행 기록이 있을 때만 의미가 있습니다.

2. **법정 보존 의무와의 충돌을 정책 테이블에 명시하세요.** 결제 기록처럼 세법상 보존해야 하는 데이터는 "왜 남기는지"의 근거를 코드 옆에 적어 둡니다.

3. **백업까지 추적하세요.** 운영 DB에서 지워도 백업에 7년치가 남아 있으면 파기가 아닙니다. 백업 로테이션 주기와 보존 정책을 정합시키는 것까지가 일입니다.

목적 제한 — 데이터에 용도 꼬리표 달기

data-catalog.yaml — 데이터셋별 목적 제한 선언 예시

datasets:

- name: user_events

purpose: ["service_quality", "abuse_prevention"]

prohibited: ["ad_targeting", "sale_to_third_party", "model_training"]

legal_basis: "정당한 이익 (이용약관 7조)"

owner: data-platform-team

review_cycle: quarterly

- name: precise_location

purpose: ["delivery_routing"]

prohibited: ["analytics", "retention_beyond_delivery"]

legal_basis: "명시적 동의 (위치기반서비스 동의)"

owner: delivery-team

review_cycle: monthly

이 카탈로그가 있으면 "이 데이터를 추천 모델 학습에 써도 되나요?"라는 질문에 감으로 답하지 않게 됩니다. 접근 요청 시 purpose 매칭을 자동 검사하는 데이터 플랫폼까지 가면 이상적이지만, YAML 한 장과 분기별 리뷰만으로도 무단 용도 확장(purpose creep)의 상당 부분을 막을 수 있습니다.

프라이버시 엔지니어링 실무 2 — 익명화와 차등 프라이버시의 기초

익명화는 생각보다 어렵다

이름과 주민번호만 지우면 익명이라는 생각은 오래전에 깨졌습니다. 생년월일 + 성별 + 우편번호 조합만으로 미국 인구의 대다수가 유일하게 식별된다는 고전적 연구가 있고, 넷플릭스 시청 기록 같은 행동 데이터는 몇 개의 포인트만으로 재식별이 가능했습니다. 위치 이력은 더 심각해서, 서너 개의 시공간 포인트면 대부분의 개인이 특정됩니다.

그래서 실무 익명화는 "식별자 삭제"가 아니라 결합 공격을 가정한 설계입니다. k-익명성(같은 속성 조합을 가진 사람이 최소 k명), 절삭(위치를 시/도 수준으로), 집계(개인 행이 아닌 통계만 보관) 같은 기법을 조합합니다.

차등 프라이버시 — 개념과 한계

차등 프라이버시(differential privacy)는 "어떤 개인이 데이터셋에 포함되든 빠지든, 분석 결과가 거의 달라지지 않게" 노이즈를 주입하는 수학적 프레임워크입니다. 직관을 코드로 보면 이렇습니다.

dp_count.py — 라플라스 노이즈를 이용한 차등 프라이버시 카운트 (개념 예시)

def dp_count(true_count: int, epsilon: float) -> float:

"""epsilon이 작을수록 프라이버시 보호 강함, 결과는 더 부정확.

카운트 질의의 민감도(sensitivity)는 1: 한 사람의 유무가

결과를 최대 1만큼 바꾼다."""

sensitivity = 1.0

noise = np.random.laplace(loc=0.0, scale=sensitivity / epsilon)

return true_count + noise

사용 예: "지난주 A 기능 사용자 수"를 외부 리포트로 낼 때

true_value = 1843

print(dp_count(true_value, epsilon=1.0)) # 예: 1841.7 — 충분히 유용

print(dp_count(true_value, epsilon=0.05)) # 예: 1812.3 — 보호 강함, 오차 큼

알아둘 한계도 분명합니다.

1. **프라이버시 예산(epsilon)은 소모품입니다.** 같은 데이터에 질의를 반복할수록 누적 노출이 커집니다. 예산 회계 없이 "노이즈 좀 섞었으니 안전"이라고 말하는 것은 차등 프라이버시가 아닙니다.

2. **소규모 데이터에는 가혹합니다.** 사용자 수십 명 단위의 분석에 충분한 노이즈를 넣으면 결과가 무의미해집니다. 대규모 집계 통계에 적합한 도구입니다.

3. **DP는 출력 보호이지 수집 면죄부가 아닙니다.** 원본을 과수집해 놓고 출력에만 DP를 적용하는 것은 절반의 해법입니다. 수집 최소화가 항상 먼저입니다.

프라이버시 영향 평가(PIA) — 경량 템플릿

정식 PIA는 무겁지만, 기능 단위의 경량 버전은 스프린트 안에서 소화할 수 있습니다. 설계 리뷰 템플릿에 아래 한 페이지를 추가하는 것부터 시작해 보세요.

=== 경량 프라이버시 영향 평가 (기능 단위, 30분 버전) ===

1. 무엇을 수집하는가

- 새로 수집하는 데이터 항목:

- 그중 개인정보/민감정보 해당 항목:

- 미성년자 데이터 포함 가능성: 예 / 아니오

2. 왜 필요한가 (목적 명세)

- 이 기능의 목적:

- 각 항목이 그 목적에 필수인 이유 (항목별 한 줄):

- 더 적은 데이터로 같은 목적을 달성하는 대안 검토 결과:

3. 어디로 가는가 (흐름)

- 저장 위치와 암호화 여부:

- 서드파티 전송 여부 (SDK/API 포함):

- 다른 데이터와 결합될 가능성:

4. 언제 사라지는가

- 보존 기한과 그 근거:

- 파기 방식 (자동/수동, hard delete/익명화):

- 백업 내 잔존 기간:

5. 무엇이 잘못될 수 있는가

- 유출 시 최악 시나리오:

- 결합 공격 시나리오 (다른 데이터와 합쳐지면?):

- 내부자 오남용 시나리오와 접근 통제:

6. 결정

- 진행 / 수정 후 진행 / 보류

- 수정 조건:

- 검토자(개발/보안/법무) 서명:

이 템플릿의 진짜 가치는 5번입니다. "유출되면?"만이 아니라 "결합되면?"과 "내부자가 악용하면?"을 묻는 순간, 평가의 질이 달라집니다. 그리고 6번의 기록이 쌓이면, 조직은 "우리가 그때 무엇을 알았고 무엇을 결정했는지"를 입증할 수 있게 됩니다.

거절의 기술 — 조직 안에서 이견을 말하는 법

윤리적 우려를 느끼는 것과, 그것을 조직 안에서 효과적으로 제기하는 것은 다른 기술입니다. 순서가 있습니다.

1단계: 사실과 비용의 언어로 번역하기

"이건 비윤리적입니다"는 토론을 닫는 문장입니다. 같은 내용을 비용과 리스크의 언어로 번역하면 토론이 열립니다.

- 나쁜 화법: "사용자를 몰래 추적하는 건 잘못됐어요."

- 나은 화법: "이 SDK는 정밀 위치를 벤더 서버로 전송합니다. 동의 화면에 그 사실이 없으므로 개인정보보호법 위반 소지가 있고, 적발 시 과징금과 신뢰 손실이 예상됩니다. 전환 측정이 목적이라면 집계 기반 측정 API로 같은 지표를 얻을 수 있습니다."

핵심 구조는 **사실 (무엇이 일어나는가) + 리스크 (법적/보안/평판) + 대안 (목적을 달성하는 다른 방법)**입니다. 대안 없는 반대는 거부권 행사처럼 들리지만, 대안 있는 반대는 엔지니어링입니다.

2단계: 기록을 남기는 이견 제기

구두 반대는 증발합니다. 설계 문서의 리뷰 코멘트, 티켓의 우려 사항 란, 회의록의 반대 의견 기록처럼 추적 가능한 채널에 남기세요. 이는 자기 보호이기도 하지만, 조직이 나중에 "그때 누군가 경고했었다"는 학습을 할 수 있게 하는 공공재이기도 합니다.

3단계: 에스컬레이션 경로 — 사다리를 한 칸씩

1. 직속 리드와 1:1 -- "이 설계에 우려가 있습니다 + 대안"

| 해소 안 되면

2. 설계 리뷰/아키텍처 회의 -- 공식 안건으로 상정, 기록 남김

| 해소 안 되면

3. 보안/프라이버시/법무 채널 -- DPO, 보안팀, 컴플라이언스에 자문 요청

| 해소 안 되면

4. 윤리 신고 채널/옴부즈맨 -- 익명 채널이 있다면 활용

| 해소 안 되면

5. 개인의 선택 -- 프로젝트 이동 요청, 이직, (최후) 내부고발

사다리를 건너뛰지 않는 것이 중요합니다. 1~3단계에서 해결되는 문제를 5단계로 가져가면 조직과 개인 모두 비용이 커집니다. 거꾸로, 1단계에서 묵살됐다고 멈추는 것도 직업적 책임을 다한 것이 아닙니다.

내부고발의 현실 — 신중하게

3~4단계까지 모두 실패했고 사안이 공중의 안전이나 법 위반에 관련된다면, 내부고발이라는 선택지가 남습니다. 다만 현실을 직시해야 합니다. 내부고발자 보호법제는 나라마다 강도가 다르고, 보호가 있어도 경력과 생계의 비용은 흔히 고발자가 치릅니다. 그래서 권고는 보수적입니다. 첫째, 변호사와 먼저 상담하세요(언론보다 먼저). 둘째, 회사 기밀 자료의 무단 반출은 그 자체로 법적 리스크이므로 증거 수집 방식도 법률 자문을 받으세요. 셋째, 한국의 공익신고자 보호법, 각국의 보호 제도 등 공식 경로를 우선 검토하세요. 내부고발은 윤리적 영웅담이 아니라, 모든 다른 경로가 실패했을 때의 마지막 수단으로 남겨 두는 것이 맞습니다.

ACM 윤리강령 — 개발자를 위한 발췌 해설

ACM Code of Ethics는 소프트웨어 직군에서 가장 널리 인용되는 직업윤리 강령입니다. 감시 기술과 직결되는 조항만 추려 봅니다.

| 조항 | 원칙 요지 | 감시 기술 맥락에서의 의미 |

| --- | --- | --- |

| 1.1 | 사회와 인간 복리에 기여하라 | 시스템의 영향 평가는 주주가 아니라 영향받는 모든 사람 기준 |

| 1.2 | 해악을 피하라 | 의도된 기능만이 아니라 오용 가능성까지 설계 책임에 포함 |

| 1.6 | 프라이버시를 존중하라 | 최소 수집, 명확한 고지, 목적 외 사용 금지를 명시적으로 요구 |

| 1.7 | 비밀을 존중하라 | 직무상 알게 된 정보의 취급 — 단, 법과 윤리 위반의 은폐에는 적용되지 않음 |

| 2.5 | 철저한 영향 평가를 하라 | PIA 같은 평가는 권장 사항이 아니라 전문가의 기본 의무 |

| 3.1 | 공공선을 중심에 두라 | 리더는 구성원이 윤리적 우려를 제기할 수 있는 구조를 만들 책임 |

1.6 조항은 특히 구체적입니다. 개인정보의 수집은 정당한 목적에 필요한 최소한이어야 하고, 당사자가 알 수 있어야 하며, 수집 목적 외 사용은 동의 없이는 안 된다고 적시합니다. 이 글에서 다룬 데이터 최소화, 목적 제한, 보존 기한이 그대로 강령의 요구사항인 셈입니다. 윤리강령은 장식이 아니라, "전문가라면 이 정도는 기본"이라는 직업적 기준선입니다.

균형 — 안전 대 자유, 양쪽의 논거를 정직하게

이 주제는 한쪽 논거만 듣기 쉬우므로, 양쪽을 정직하게 요약합니다.

**안전 우선 측의 논거:**

1. 감시 기술이 실제로 범죄 해결에 기여한 사례는 부정하기 어렵습니다. 실종자 수색, 차량 도난, 강력범죄 수사에서 CCTV와 ALPR은 일상적 도구입니다.

2. 연령 인증 논의의 출발점인 미성년자 보호 문제는 실재합니다. 알고리즘 피드가 아동에게 끼치는 해악에 대한 증거가 쌓이면서, "아무것도 하지 않기"도 윤리적 선택지가 아니게 됐습니다.

3. 공적 공간에서의 프라이버시 기대는 본래 제한적이라는 법리도 오래된 것입니다.

**자유 우선 측의 논거:**

1. 감시의 해악은 적발이 아니라 위축 효과(chilling effect)에서 옵니다. Ellison의 "최선의 행동" 발언이 정확히 보여주듯, 상시 관찰되는 인간은 합법적인 행동(집회, 취재, 상담)조차 자기검열하게 됩니다.

2. 인프라는 정권과 함께 이동합니다. 선한 정부 아래 구축된 감시망은 다음 정부에게 그대로 상속됩니다. 시스템 설계는 최악의 운영자를 가정해야 합니다.

3. 오남용은 가설이 아니라 기록입니다. 경찰관의 ALPR 사적 조회, 데이터 브로커를 통한 영장 우회 구매 등 문서화된 사례가 이미 많습니다.

4. 효과 검증이 약합니다. 감시 카메라 확대가 범죄율에 미치는 효과 연구는 결과가 엇갈리며, 특정 범죄(주차장 차량 범죄)에서만 유의미하다는 메타 분석이 많습니다.

정직한 결론은 이렇습니다. 안전과 자유는 제로섬이 아니지만 공짜 점심도 아닙니다. 그래서 개발자의 역할이 중요합니다. **같은 안전 목표를 더 적은 자유 비용으로 달성하는 설계**가 존재할 때가 많고, 그 설계를 아는 것은 정치인이 아니라 엔지니어이기 때문입니다. 영장 기반 접근 통제, 짧은 보존 기한, 단말 내 처리, 감사 로그의 공개 — 이것들이 (D) 사분면, 즉 "설계로 견제"의 도구상자입니다.

개발자 행동 체크리스트

마지막으로, 내일 출근해서 바로 쓸 수 있는 체크리스트로 정리합니다.

[ 설계 단계 ]

[ ] 새 데이터 수집 항목마다 "이게 없으면 기능이 불가능한가"를 물었다

[ ] 경량 PIA를 설계 리뷰 템플릿에 포함시켰다

[ ] 보존 기한을 스키마(행 단위 expires_at)에 내장했다

[ ] 위치/생체/미성년자 데이터는 별도 승인 절차를 거치게 했다

[ 구현 단계 ]

[ ] 로그에서 개인정보 필드를 기본 마스킹하는 미들웨어를 깔았다

[ ] 서드파티 SDK의 데이터 수집 범위를 문서로 확인하고 기록했다

[ ] 파기 워커의 실행 결과가 모니터링/알림으로 이어지게 했다

[ ] 내부자 접근에 감사 로그와 알림(누가 누구를 조회했나)을 붙였다

[ 조직 단계 ]

[ ] 데이터 카탈로그에 목적/금지 용도를 선언했다

[ ] 우려 제기를 기록 가능한 채널(리뷰 코멘트, 티켓)로 했다

[ ] 에스컬레이션 사다리의 다음 칸이 어디인지 알고 있다

[ ] ACM 강령 1.6을 팀 온보딩 문서에 링크했다

[ 개인 단계 ]

[ ] 내가 만드는 시스템을 적대적 운영자가 가졌을 때의 시나리오를 상상해 봤다

[ ] "결합되면 어떻게 되나"를 습관적으로 묻는다

[ ] 거절할 때 사실 + 리스크 + 대안의 구조로 말한다

한국·일본 컨텍스트 — 우리 동네의 감시 지형

마지막으로 한국과 일본 개발자에게 특히 가까운 쟁점을 짚어 둡니다.

**한국**은 세계적으로 CCTV 밀도가 높은 나라이고, 공공 CCTV 통합관제센터가 지자체 단위로 운영됩니다. 개인정보보호법은 고정형 영상정보처리기기에 대한 안내판 설치와 목적 제한을 요구하며, 2023년 개정으로 이동형 영상기기(드론, 자율주행차) 규정도 정비됐습니다. 개발자 관점에서 중요한 변화는 개인정보보호위원회의 과징금 상한이 전체 매출 기준으로 바뀌었다는 점과, 가명정보 제도로 데이터 활용과 보호의 균형점을 코드로 구현해야 할 일이 늘었다는 점입니다. 주민등록번호 체계라는 강력한 전 국민 식별자가 존재하는 환경에서는, 결합 공격의 위력이 다른 나라보다 크다는 사실을 설계 전제로 삼아야 합니다.

**일본**은 개인정보보호법(APPI)이 3년 주기 재검토로 갱신되며, 얼굴 인식 데이터 취급과 가명가공정보 제도가 정비되어 왔습니다. 방범 카메라 화상의 수사 활용에 대한 가이드라인 논의, 마이넘버 카드의 활용 확대와 그에 따른 우려 등 한국과 평행한 쟁점이 많습니다. 양국 모두에서 공통된 실무 교훈은 같습니다. 법이 허용하는 범위와 사용자가 기대하는 범위 사이에는 항상 간극이 있고, 그 간극에서 평판 리스크가 자랍니다. 적법성 검토만으로 멈추지 말고, "사용자가 이 사실을 알면 놀랄까?"라는 놀라움 테스트(surprise test)를 설계 리뷰에 추가하는 것을 권합니다.

자주 나오는 질문

**Q1. 우리 회사는 B2B인데도 이런 게 필요한가요?**

필요합니다. B2B SaaS가 처리하는 최종 사용자 데이터의 책임은 계약상 위탁 구조로 흐르지만, 침해 사고의 평판 비용과 수탁자 의무는 그대로 남습니다. 오히려 B2B는 고객사의 보안 실사(security review)에서 데이터 최소화와 보존 정책을 점점 더 깊게 검증받는 추세입니다.

**Q2. 스타트업이라 전담 프라이버시 인력이 없습니다. 어디서 시작하나요?**

이 글의 순서대로면 됩니다. 첫째 주에 데이터 카탈로그 YAML 한 장, 둘째 주에 보존 기한 칼럼과 파기 워커, 셋째 주에 경량 PIA를 설계 리뷰 템플릿에 추가. 이 세 가지가 비용 대비 효과의 대부분을 차지합니다.

**Q3. 감시 기술 회사의 채용 제안을 받았습니다. 받아도 되나요?**

개인의 가치관 문제이지만, 판단 프레임은 제공할 수 있습니다. 그 회사의 제품이 위 사분면 중 어디를 지향하는지(영장주의·감사 가능성·보존 제한을 제품에 내장하는지), 내부 이견 제기 구조가 있는지, 판매처 제한 정책(수출 통제, 권위주의 정권 판매 금지)이 있는지를 면접에서 물어보세요. 질문에 대한 반응 자체가 가장 좋은 데이터입니다.

마치며 — 만드는 손의 책임

시애틀 도보 투어 글의 힘은 고발이 아니라 가시화에 있었습니다. 늘 거기 있었지만 보이지 않던 인프라를 보이게 만드는 것. 이 글이 하려는 것도 같습니다. 감시 인프라는 어딘가의 악당이 만드는 것이 아니라, 평범한 스프린트에서 평범한 티켓을 처리하는 우리 손에서 만들어집니다.

그렇기에 비관할 필요는 없습니다. 만드는 손에 책임이 있다는 말은, 만드는 손에 힘이 있다는 말이기도 합니다. 보존 기한 한 줄, 마스킹 미들웨어 하나, 설계 리뷰의 질문 하나가 수백만 사용자의 데이터 노출 면적을 바꿉니다. Ellison이 말한 "모든 것이 녹화되는 세계"가 온다 해도, 무엇이 얼마나 오래 누구에게 보이는 형태로 녹화되는지는 여전히 설계의 문제이고, 설계는 우리의 일입니다.

기술 윤리는 결국 직업적 탁월함의 한 형태입니다. 좋은 엔지니어가 장애 시나리오를 상상하듯, 좋은 엔지니어는 오남용 시나리오를 상상합니다. 그 상상력이 2026년의 개발자에게 요구되는 새로운 기본기라고 생각합니다.

참고 자료

- [TechRadar — Larry Ellison의 상시 녹화 발언 보도](https://www.techradar.com/pro/quote-of-the-day-by-oracle-co-founder-larry-ellison-citizens-will-be-on-their-best-behavior-because-were-constantly-recording-and-reporting-everything-that-is-going-on-a-dire-warning-on-the-erosion-of-privacy)

- [coveillance.org — 시애틀 감시 인프라 도보 투어](https://coveillance.org/a-walking-tour-of-surveillance-infrastructure-in-seattle/)

- [ACM Code of Ethics and Professional Conduct](https://www.acm.org/code-of-ethics)

- [EFF — 차량 번호판 자동 인식기(ALPR) 해설](https://www.eff.org/pages/automated-license-plate-readers-alpr)

- [GDPR 25조 — Data Protection by Design and by Default](https://gdpr-info.eu/art-25-gdpr/)

- [NIST Privacy Framework](https://www.nist.gov/privacy-framework)

- [한국 개인정보보호위원회](https://www.pipc.go.kr/)

- [일본 개인정보보호위원회 (PPC)](https://www.ppc.go.jp/)

- [Damien Desfontaines — 차등 프라이버시 입문 시리즈](https://desfontain.es/privacy/differential-privacy-awesomeness.html)

- [EFF — Street-Level Surveillance 프로젝트](https://www.eff.org/issues/street-level-surveillance)

- [Hacker News](https://news.ycombinator.com/)

- [GeekNews](https://news.hada.io/)