“하지만 개인정보 보호는요?” – Agentic Work를 Information Flow 문제로 보기

AI 이야기가 나오기만 하면, 언젠가는 꼭 이런 말이 나옵니다.

“하지만 개인정보 보호는요?”

이 반론은 틀리지 않습니다. AI 시스템이나 Coding Agent를 기업 정보, 개인정보, 또는 보안에 민감한 시스템과 연결한다면 어떤 정보가 처리되는지 매우 신중하게 생각해야 합니다. 다만 이 문장 하나만으로는 아직 Risk Analysis가 아닙니다.

AI
↓
"개인정보 보호!"

는 기술적으로 대략 다음과 비슷한 수준의 말입니다.

Internet
↓
"Security!"

둘 다 실제로 존재하는 문제 영역을 가리킵니다. 하지만 둘 다 아직 구체적인 질문 하나도 답하지 않습니다.

논의가 의미를 갖기 시작하는 지점은 실제 Information Flow를 볼 때입니다.

Information
↓
Source
↓
Authorization
↓
Agent / Tool
↓
Context
↓
Processing
↓
Output / Artifact / Memory

어떤 정보가 어디로 흐르는가? 왜 그곳에서 필요한가? 누가 볼 수 있는가? 어떤 시스템이 처리하는가? 어떤 Trust Boundary를 넘는가? 그 정보로부터 어떤 추가 Artifact가 만들어지는가? 그리고 그 정보가 보여서는 안 되는 곳에서 보인다면 어떤 일이 생기는가?

바로 이 지점에서 논의의 성격이 달라집니다. Agentic Work는 단순한 개인정보 보호 문제가 아닙니다. Information Flow와 Trust Boundary의 문제이기도 합니다. 개인정보 보호는 중요한 한 축이지만, 전부는 아닙니다.

이것은 이 시리즈의 이전 글과 직접 연결됩니다. 이전 글에서는 Architecture를 Constraint로 보았습니다. 즉, Agent가 구조적으로 어떤 해결책을 만들어도 되는지를 Architecture가 제한합니다. Information Protection은 이 아이디어를 한 단계 확장합니다. Architecture가 무엇과 무엇을 연결해도 되는지를 답한다면, Information Protection은 누가 무엇을 볼 수 있는지, 무엇이 어디로 흐를 수 있는지, 그리고 그 정보에서 무엇이 만들어질 수 있는지를 추가로 묻습니다.

따라서 Architecture는 구조적 Solution Space를 제한하고, Trust Boundary는 허용된 Context와 Action Space를 제한합니다.

민감한 도메인이라고 해서 개발 Context까지 자동으로 민감한 것은 아니다

나는 약 15년 동안 기술적 리더십 역할을 해 왔고, 그중 상당한 기간을 의료와 Public Sector 같은 분야에서 일했습니다. 두 도메인 모두 강하게 보호되어야 한다는 데 거의 이견이 없는 정보를 다룹니다. 그런데도 나는 그동안 실제로 고도로 민감한 Production Data를 가지고 개발해야 했던 적이 없습니다.

이것은 명확히 개인적인 경험이며, 소프트웨어 개발이 어디서나 이렇게 조직되어야 한다는 일반론이 아닙니다. 실제로 Production-like Data나 실제 Production Data를 다루는 개발자와 조직도 분명 존재합니다. 그래도 이 경험은 나에게 중요한 한 가지를 보여 줍니다.

시스템 안에 고도로 민감한 데이터가 존재한다고 해서 그 데이터가 자동으로 일반적인 개발 또는 Agent Context의 일부가 되는 것은 아니다.

많은 AI 논의에서 이 구분은 놀랄 만큼 빨리 사라집니다. 의료 시스템이 건강 데이터를 처리한다고 해서 개발자나 Coding Agent가 실제 건강 데이터를 반드시 봐야 하는 것은 아닙니다. 개발 환경과 Production 환경은 분리할 수 있고, 개발 과정에서는 Synthetic Test Data, Anonymized Data, Pseudonymized Data, 또는 별도로 구축한 Test Dataset을 사용할 수 있습니다. 접근 권한도 개발자가 실제 Production Data를 전혀 보지 않고도 시스템의 큰 부분을 이해하고 변경할 수 있도록 설계할 수 있습니다.

독일 Datenschutzkonferenz 역시 AI 시스템 개발 시 해당 목적을 Synthetic Data나 Anonymized Data로 달성할 수 있는지 먼저 검토할 것을 권고합니다. 여기서 Pseudonymized Data와 Anonymous Data는 구분해야 합니다. 추가 정보를 통해 다시 특정 개인과 연결할 수 있다면 Pseudonymized Data는 원칙적으로 여전히 개인정보입니다. 반대로 실제로 익명화된 정보는 GDPR의 적용 대상에서 벗어납니다. [DSK – AI 시스템의 기술적·조직적 조치]

따라서 기술적 질문은 전체 시스템에 민감한 데이터가 있는가가 아니라 다음이어야 합니다.

이 데이터 중에서 이 구체적인 개발 과정이나 Agent가 실제로 필요로 하는 것은 무엇인가?

겉으로는 작은 관점 변화처럼 보일 수 있습니다. 하지만 실제로는 문제 전체를 바꿉니다. 더 이상 “이 도메인은 민감하다”는 추상적 이야기를 하는 것이 아니라, 구체적인 Data Flow를 다루게 되기 때문입니다.

개인정보 보호는 Information Protection의 한 축일 뿐이다

기술 논의에서는 개인정보 보호라는 말 자체가 실제보다 훨씬 넓은 의미로 사용되는 경우가 많습니다.

GDPR이 보호하는 것은 개인정보입니다. 즉, 식별되었거나 식별 가능한 자연인과 관련된 정보입니다. 이름이나 이메일 주소 같은 명백한 정보뿐 아니라, 상황에 따라 Identifier, Online Identifier, 고객번호, Log, IP Address도 포함될 수 있습니다. [GDPR, Art. 4 – EUR-Lex]

특정 정보에는 더 높은 요구사항이 적용됩니다. GDPR Art. 9는 건강 데이터, 유전 데이터, 특정 생체 데이터, 정치적 견해, 종교적 또는 철학적 신념, 노동조합 가입 정보, 성생활이나 성적 지향 관련 정보 등을 특별 범주의 개인정보로 규정합니다. [GDPR, Art. 9 – EUR-Lex]

하지만 개인정보와 아무 관련이 없어도 매우 강한 보호가 필요한 정보는 많습니다. Source Code, Architecture, 아직 공개되지 않은 제품, Algorithm, 연구 결과, 내부 전략, 계약, 가격 정책, Proprietary Process 등이 그렇습니다. 이런 정보의 일부는 일정한 조건을 충족하면 영업비밀로 보호될 수도 있습니다. 독일 영업비밀보호법은 예를 들어 해당 정보가 일반적으로 알려져 있지 않거나 쉽게 접근할 수 없고, 경제적 가치가 있으며, 적절한 비밀유지 조치의 대상인지 등을 봅니다. 그렇다고 모든 비공개 Source Code가 자동으로 영업비밀이 되는 것은 아닙니다. 다만 개인정보와 전혀 무관한 정보도 경제적 가치 때문에 독립적인 보호 필요성을 가질 수 있다는 점은 분명히 보여 줍니다. [§ 2 GeschGehG]

또 어떤 정보는 핵심 문제가 개인정보 보호도, 고전적인 영업비밀 보호도 아닙니다. API Key, Token, Private Key, Cloud Configuration, 내부 Network Structure, Security Architecture, 취약점 정보, 그리고 기타 Credential이 그렇습니다. 이런 정보에 대해 “개인정보가 들어 있는가?”만 묻는 것은 명백히 부족합니다.

개인정보 보호는 Information Protection의 한 축일 뿐이다.

Agentic Work에서는 이 점이 특히 중요합니다. Coding Agent가 다루는 정보는 개인정보보호법 관점에서는 별다른 문제가 없어 보이면서도 기업에는 매우 중요한 자산일 수 있기 때문입니다. 고객 이름 하나도 보지 않고도 Agent가 기업의 핵심 Intellectual Property에 접근할 수 있습니다.

하나의 Label보다 두 개의 축

그래서 나는 기술적 논의를 위해 간단한 모델을 사용합니다. 이것은 GDPR의 공식 분류도 아니고 법적 Classification Scheme도 아닙니다. 서로 다른 두 질문을 섞지 않기 위한 Engineering Abstraction입니다.

첫 번째 축은 개인정보 여부와 그에 따른 특별한 법적 보호를 대략적으로 봅니다.

개인정보 아님
↓
개인정보
↓
특별 범주의 개인정보

두 번째 축은 정보가 노출되었을 때 발생할 수 있는 피해를 봅니다.

공개
↓
내부
↓
기밀
↓
비즈니스 핵심
↓
기업 존립 위협 / 개인 위험

두 축은 반드시 함께 움직이지 않습니다. 회사 이메일 주소는 개인정보이면서도 상대적으로 낮은 보호 수준을 가질 수 있습니다. 반대로 아직 공개되지 않은 Algorithm은 개인정보를 전혀 포함하지 않으면서도 경제적으로 매우 중요할 수 있습니다. 물론 두 축 모두에서 높은 위치에 있는 정보도 있습니다.

의도적으로 극단적인 두 사례를 보면 차이가 더 분명해집니다.

한쪽에는 망명 절차에 있는 정치적 박해 피해자의 정보를 상상해 볼 수 있습니다. 정치적 견해만으로도 이미 GDPR Art. 9의 특별 범주 개인정보에 해당합니다. 사안에 따라 추가적인 고위험 민감 정보가 포함될 수도 있습니다. 여기서 무단 공개는 단순한 Compliance 문제가 아닙니다. 실제 사람에게 현실적인 영향을 줄 수 있습니다.

반대쪽에는 한 회사가 새로운 기술적 방법을 개발하고 있다고 가정해 봅시다. 고객 데이터도 없고, 이름도 없고, 이메일 주소도 없고, 사용자 식별자도 없고, 개인정보도 전혀 없습니다. 하지만 그 방법은 수년간의 연구 결과이고, 회사의 미래 핵심 경쟁력이 될 수도 있습니다. 공개된다면 경제적으로 치명적일 수 있습니다.

개인정보가 아니라고 해서 자동으로 중요하지 않은 것은 아니다.

따라서 기술적 Risk Analysis에 개인정보: yes / no 같은 단일 Label만으로는 부족합니다. 그 정보가 잘못된 Trust Boundary를 넘었을 때 무슨 일이 생기는지도 물어야 합니다. 바로 그 지점에서 개인정보 보호는 더 큰 Information Flow 문제의 일부가 됩니다.

Data Flow는 Marketing Label보다 중요하다

이 구분은 AI 제품 주변에서 매우 안심시키는 말처럼 들리는 몇 가지 표현을 이해하는 데도 도움이 됩니다. 대표적인 예가 다음입니다.

우리 데이터는 학습에 사용되지 않습니다.

이것은 제품의 중요한 특성일 수 있습니다. 하지만 정확히 하나의 질문만 답합니다. 처리 자체가 없다는 뜻도 아니고, 전송이나 저장이 없다는 뜻도 아니며, Log, Retention, 추가 서비스 제공자, Support Access, 특정 Region 밖의 처리까지 자동으로 없어진다는 뜻도 아닙니다.

GDPR에서 처리라는 개념은 훨씬 넓습니다. 개인정보의 수집, 기록, 저장, 조회, 열람, 사용, 전송, 제공, 결합, 삭제 등이 포함됩니다. 따라서 Training은 더 큰 기술 흐름 속에서 가능한 하나의 처리 단계나 목적일 뿐입니다. [GDPR, Art. 4 – EUR-Lex]

Datenschutzkonferenz도 예를 들어 입력과 출력을 Training에 사용하는 문제와 입력 기록을 저장하는 문제를 구분합니다. 시스템은 Training을 하지 않으면서도 데이터를 저장할 수 있습니다. [DSK – 인공지능과 개인정보 보호]

따라서:

No training is not the same as no processing.

이 말은 상용 AI나 외부에서 운영되는 AI 시스템이 자동으로 문제가 있다는 뜻이 아닙니다. 단지 No Training만으로는 전체 Data Flow를 설명할 수 없다는 뜻입니다. 계약, AVV 또는 DPA, Retention, Region, Subprocessor, 기술 설정, 그리고 실제 Information Flow를 함께 봐야 합니다.

반대 방향의 단순화도 성립하지 않습니다. 어떤 개인정보 처리가 개인정보보호법상 허용된다고 해서 그 정보를 자동으로 Prompt에 넣어도 된다는 뜻은 아닙니다. NDA가 외부 공유를 금지할 수 있고, 내부 Security Policy가 추가 제한을 둘 수 있으며, 해당 정보가 영업비밀일 수도 있고 계약 또는 규제 조건이 적용될 수도 있습니다. 사용자가 내부 시스템 안에서는 어떤 정보를 볼 권한이 있다고 해도, 그 정보를 외부 서비스에 전송할 권한까지 자동으로 갖는 것은 아닙니다. 개인정보가 전혀 없더라도 IP 보호 때문에 외부 전송이 완전히 부적절할 수도 있습니다.

개인정보보호법상 허용되는 처리가 조직적·보안적으로도 자동으로 허용되는 것은 아니다.

나는 소프트웨어 아키텍트이지 변호사가 아닙니다. 구체적인 처리가 허용되는지는 실제 Processing Context에 따라 달라지며, 필요하다면 개인정보 보호나 법률 전문가의 판단이 필요합니다. 하지만 Architecture의 역할은 그보다 앞에서 시작합니다. 누군가 Data Flow의 법적 허용 여부를 판단하려면, 먼저 기술적으로 어떤 Data Flow가 실제로 존재하는지가 명확해야 합니다.

Agent는 Information Surface를 넓힌다

전통적인 Chat에서는 보이는 상호작용이 비교적 단순합니다. 내가 Prompt를 쓰고, 시스템이 처리하고, 답을 받습니다. Coding Agent는 완전히 다른 활동 반경을 가질 수 있습니다.

시스템, 설정, Task에 따라 다음과 같은 환경의 일부에 접근할 수 있습니다.

Repository
Documentation
Tickets
Shell
File System
Environment Variables
Database
Logs
CI/CD
Cloud APIs
Secrets
Browser
External Search

모든 Agent가 이 모든 권한을 갖는 것은 아닙니다. 그렇기 때문에 “Coding Agent는 안전한가?”라는 질문은 너무 거칩니다. 하나의 Repository를 Read-only로 읽는 Agent와 Shell Command를 실행하고, 파일을 수정하고, 외부 서비스를 호출하고, Secret을 읽고, Deployment를 실행할 수 있는 Agent는 보안 관점에서 전혀 다른 시스템입니다.

Tool이 하나 추가될 때마다 Action Space뿐 아니라 Information Space도 커집니다. 독일 BSI는 Application-integrated Language Model과 관련해 추가 Integration이 문서, 웹사이트, Programming Environment, 기타 시스템에 대한 접근을 열 수 있고, 그 결과 Indirect Prompt Injection 같은 새로운 공격 경로가 생길 수 있다고 설명합니다. [BSI – Indirect Prompt Injections]

Agency가 커질수록 Information Surface와 Attack Surface도 커진다.

그래서 아주 오래된 Security Principle 하나가 Agentic Work에서 다시 핵심이 됩니다. Least Privilege입니다.

질문은 “이 Agent가 언젠가 무엇을 쓸 수도 있을까?”가 아니라 “이 Task를 위해 정확히 무엇이 필요한가?”여야 합니다.

Task
↓
필요한 Capability
↓
필요한 Information
↓
최소 Permission

Frontend Application의 문구를 고치는 Agent라면 일반적으로 Production Database, Cloud Admin 권한, Secret, 회사의 모든 Repository에 대한 접근은 필요하지 않습니다. 반대로 복잡한 Migration 분석에는 훨씬 더 큰 Context가 필요할 수 있습니다. 이것은 모순이 아닙니다. Least Privilege는 무조건 최소 권한을 뜻하지 않습니다. 필요한 만큼만, 그리고 가능한 한 적게를 뜻합니다.

여기서 이 전체 주제의 가장 중요한 규칙 중 하나가 나옵니다.

Relevant하다고 해서 자동으로 permissible한 것은 아니다.

Agent에게 기술적으로 유용한 정보라고 해서 그 정보를 자동으로 제공해야 할 이유가 되는 것은 아닙니다.

Authorization은 Retrieval보다 먼저 와야 한다

RAG 시스템에서는 이 차이가 특히 잘 보입니다. 아주 단순하게 RAG를 그리면 다음과 같습니다.

기업 지식
↓
Retrieval
↓
LLM

그 지식이 모델 자체에 Training되지 않는다는 점 때문에 처음에는 더 통제하기 쉬워 보일 수 있습니다. 실제로 더 통제하기 쉬울 수 있습니다. 하지만 권한 문제가 사라지는 것은 아닙니다.

Datenschutzkonferenz는 RAG 지침에서 Reference Document와 Vector Database에도 Rights & Roles Concept가 여전히 중요하다고 명확히 설명합니다. 또한 Access Control을 단순히 Language Model에 맡길 수 없으며, 적절한 Role이 Query 이전 단계에서 이미 고려되어야 한다고 설명합니다. [DSK – RAG 기반 생성형 AI 시스템의 개인정보 보호 특성]

Engineering 관점에서는 순서가 꽤 명확합니다.

Identity
↓
Authorization
↓
Retrieval
↓
Context
↓
LLM

모든 것을 먼저 찾고 Context를 만든 뒤, 사용자가 그 정보를 볼 수 있었는지 나중에 판단하는 순서가 아닙니다.

RAG는 Privacy Shield가 아니다.

Retrieval은 정보가 Context에 들어오는 기술적 경로를 바꿉니다. 기존 Authorization Boundary를 없애지는 않습니다. 정보가 기술적으로 검색 가능하다는 이유만으로 Agent에게 전달되어서는 안 됩니다.

“Agent가 원래 그곳에 들어가면 안 됐는데”

Coding Agent를 사용하면서 가장 흥미로웠던 경험 중 하나가 바로 이 가정과 관련되어 있었습니다.

이전에 오래된 대규모 시스템을 Audit한 적이 있는데, Source Code의 일부 특별히 보호해야 하는 영역은 Coding Agent에서 명시적으로 제외되어 있었습니다. Agent는 그 영역을 직접 분석해서는 안 됐습니다. 그런데 나중에 Agent가 만든 Audit Document 안에 그 영역에 관한 정보가 나타났습니다.

그 정보가 Indirect Dependency, Type, Alias, 다른 Module의 Reference, 이미 생성된 Documentation, Search, 아니면 전혀 다른 분석 경로를 통해 노출되었는지는 이제 확실히 말할 수 없습니다. 그래서 사후적으로 하나의 원인을 만들어 내고 싶지도 않습니다.

중요한 지점은 다른 데 있습니다.

기술적으로 제외된 영역이었지만, Agent에게 완전히 보이지 않는 것은 아니었던 것 같다.

이 경험은 “Agent가 원래 그곳에 들어가면 안 됐는데”라는 말이 신뢰할 수 있는 Security Description이 아니라는 사실을 매우 직관적으로 보여 줬습니다. 원래 안 됐는데는 기대하는 행동을 설명합니다. Trust Boundary는 기술적으로 강제된 경계를 설명합니다.

“Agent가 원래 그곳에 들어가면 안 됐는데”는 신뢰할 수 있는 Trust Boundary가 아니다.

보호 필요성이 낮은 정보라면 Soft Restriction으로도 충분할 수 있습니다. 하지만 보호 필요성이 높아질수록 나는 그런 기대에 덜 의존하고 싶습니다.

File Boundary는 자동으로 Information Boundary가 아니다

어떤 파일을 Agent가 읽지 못한다고 가정해 봅시다.

protected-module.ts
✕ direct access

이때 우리가 아는 것은 Agent가 이 파일을 직접 읽지 못한다는 사실뿐입니다. 보호된 영역에 대한 어떤 정보도 얻을 수 없다는 사실까지 아는 것은 아닙니다.

소프트웨어 시스템의 정보는 한 파일 안에 깔끔하게 머무는 경우가 드뭅니다. Contract, Type, Dependency, Stacktrace, Log, Test Report, Coverage, Static Analysis Finding, Architecture Documentation, Ticket, PR Description, Agent Summary, 기타 Generated Artifact를 통해 퍼집니다. Interface는 구현을 포함하지 않아도 보호된 영역에 관한 일부 정보를 드러낼 수 있습니다. Stacktrace는 Component 관계를 보여 줄 수 있고, Test Report는 Behavior를 설명하며, Architecture Diagram은 Dependency를 문서화합니다. Ticket은 특정 내부 메커니즘이 왜 존재하는지 설명할 수 있고, 이전 Summary는 나중에는 더 이상 접근할 수 없는 Context의 정보를 계속 전달할 수 있습니다.

그렇다고 Agent가 이런 정보만으로 원래 Source Code를 자동으로 복원할 수 있다는 뜻은 아닙니다. 그것은 전혀 다른, 훨씬 강한 주장입니다. 여기서 중요한 메커니즘은 더 단순합니다.

원본 파일 자체가 Trust Boundary를 넘지 않아도, 보호된 정보는 그 Boundary를 넘을 수 있다.

따라서 Source File에 대한 Access Control만으로는 완전한 Information-Flow-Control이 되지 않습니다. 이것은 GDPR의 특별 규칙이 아니라 Engineering 관점의 추론입니다. Agent는 다양한 Source의 정보를 결합하고 새로운 Artifact를 만들 수 있기 때문에 이 추론이 특히 중요합니다.

그래서 우리는 Agent가 어떤 파일을 읽을 수 있는지만 묻지 말고, 허용된 Source를 통해 어떤 정보가 보일 수 있는지, 그리고 그 정보에서 어떤 새로운 Artifact가 만들어지는지도 물어야 합니다. Information Flow는 Input에서 끝나지 않습니다.

이 지점은 내가 자주 다루는 다른 Architecture 주제와도 연결됩니다. Big Ball of Mud가 자동으로 개인정보 침해를 일으키는 것은 아닙니다. 하지만 High Coupling은 명확하고 이해 가능한 Boundary를 유지하기 어렵게 만듭니다.

명확한 Boundary
↓
이해하기 쉬운 Information Path

반면:

Big Ball of Mud
↓
암묵적 관계
↓
예측하기 어려운 Information Path

따라서 Clean Architecture 자체가 개인정보 보호 대책인 것은 아닙니다. 하지만 Ownership, Isolation, Dependency Control, 그리고 그 결과 Information Boundary를 기술적으로 강제하기 쉽게 만듭니다.

High Coupling은 Trust Boundary를 기술적으로 강제하고 검증하기 어렵게 만든다.

보호 필요성이 높을수록 “덜 주는 것”이 더 강할 수 있다

매우 민감한 정보에 대한 자연스러운 답 중 하나는 모델을 Local로 운영하는 것입니다. 이것은 충분히 의미 있는 Building Block이 될 수 있습니다. 특정 정보가 정의된 Trust Boundary를 떠나서는 안 된다면 Local 또는 On-Premise Model은 큰 차이를 만들 수 있습니다.

하지만 중요한 Architecture는 단순히 LLM local이 아니라 전체 Chain입니다.

LLM local
+
Retrieval local
+
Logs local
+
Tools local
+
Memory local
+
no cloud fallbacks
+
no unwanted telemetry

Local Model이 External Retrieval을 사용한다면 완전히 Local한 Trust Boundary가 아닙니다. Local Agent의 Tooling이 정보를 외부 API로 보낸다면 역시 마찬가지입니다. On-Premise Model에 알 수 없는 외부 Telemetry Path가 있다면, Inference가 Local에서 수행된다는 사실만으로 문제를 해결하지 못합니다.

Datenschutzkonferenz도 RAG 지침에서 On-Premise Architecture가 개인정보를 외부 Model Provider에게 전송하지 않도록 할 수 있다고 설명하면서도, 전체 Architecture를 함께 봐야 한다고 지적합니다. [DSK – RAG 지침]

결국 중요한 것은 전체 Data-Flow Model입니다.

보호 필요성이 정말 높다면 질문은 더 흥미로워집니다. 그때는 다음 질문을 먼저 해야 합니다.

왜 이 정보가 이 Trust Boundary를 넘어야 하는가?

Security Engineering은 위험한 Data Flow를 계속 더 안전하게 만드는 일만을 뜻하지 않습니다. 어떤 Risk는 Data Flow 자체가 생기지 않게 하는 편이 더 우아하게 해결됩니다. Synthetic Dataset이면 충분할 수도 있고, Anonymized 또는 축소된 일부 Data만 필요할 수도 있습니다. Contract 하나면 충분할 수도 있습니다. Local Service가 민감한 Operation을 캡슐화하고 Agent에는 덜 민감한 Result만 줄 수도 있습니다. Manual Boundary가 더 적절할 수도 있습니다. 그리고 어떤 Use Case에서는 Agent 자체가 올바른 도구가 아닐 수도 있습니다.

보호 필요성이 매우 높다면, 올바른 Architecture는 어떤 Data Flow 자체를 만들지 않는 것일 수 있다.

이것은 LLM 훨씬 이전부터 존재하던 원칙과 잘 맞습니다. Data Minimization과 Privacy by Design은 가능한 많은 개인정보를 모은 뒤 최대한 복잡하게 보호하라는 뜻이 아니라, 설계 단계부터 목적에 실제로 필요한 범위만 남기라는 뜻입니다. [GDPR, Art. 5 and Art. 25 – EUR-Lex]

Agentic Work에서 이것은 매우 생산적인 사고방식입니다. 어떤 정보를 Agent에게 어떻게든 더 줄 수 있는지보다, 이 Task를 위해 어떤 정보를 Agent에게 굳이 주지 않아도 되는지를 묻는 편이 낫습니다.

개인정보 보호는 AI 때문에 갑자기 생긴 문제가 아니다

아마 현재 AI 논의에서 나를 가장 답답하게 만드는 부분이 이 지점입니다.

조직들은 수십 년 동안 외부 시스템을 통해 정보를 처리해 왔습니다. Cloud, SaaS, API, Communication Platform, Support System, Analytics, 외부 서비스 제공자 등이 그렇습니다. 그 어떤 시스템도 자동으로 문제가 없었던 적은 없습니다. Purpose, Permission, Recipient, Storage Location, Retention, Contract, Technical Measure, Protection Requirement는 예전부터 고려해야 했고 지금도 그렇습니다.

AI는 일부 Risk Profile을 분명 크게 바꿉니다. 생성형 모델은 정보를 새로운 방식으로 조합합니다. RAG는 대규모 Knowledge Base를 Semantic Search 가능하게 만듭니다. Agent는 Tool을 받고 직접 Action을 실행할 수 있습니다. Prompt Injection은 새로운 공격 기회를 만듭니다. Memory와 Generated Artifact는 정보를 단일 Interaction 너머로 전달할 수 있습니다.

이 차이들은 실제입니다. 하지만 근본적인 질문, 즉 어떤 정보가 어디로 흐르는가는 새롭지 않습니다. GDPR은 기술중립적으로 설계되어 있습니다. 개인정보가 Classic SaaS, API, Language Model 중 무엇으로 처리되는지에 따라 기본 원칙이 달라지는 것은 아닙니다. [GDPR – EUR-Lex]

그래서 나는 두 극단 모두 도움이 되지 않는다고 봅니다. AI가 들어갔다고 갑자기 모든 것이 금지되는 것도 아니고, Enterprise Offering을 쓴다고 자동으로 모든 것이 해결되는 것도 아닙니다.

AI라는 단어가 등장했다고 개인정보 보호가 갑자기 절대적인 기준이 되어서는 안 된다. 실제 Data Flow와 실제 Risk가 존재하는 곳에서 구체적으로 다뤄져야 한다.

이것은 개인정보 보호를 줄이자는 주장이 아닙니다. 오히려 논의를 더 정확하게 만듭니다. AI → 개인정보 보호 문제라는 추상적 결론 대신 실제로 답할 수 있는 질문을 만들 수 있습니다.

Agent가 이 정보를 필요로 하는가?
↓
사용자가 접근할 권한이 있는가?
↓
Agent가 이 Task를 위해 처리해도 되는가?
↓
이 Trust Boundary를 넘어도 되는가?
↓
접근이 기술적으로 제한되는가?
↓
어떤 Artifact가 생성될 수 있는가?
↓
그 Artifact가 정보를 더 전달할 수 있는가?
↓
어떻게 검증할 것인가?

이 질문들이 전부 개인정보 보호 문제는 아닙니다. 어떤 것은 Security, 어떤 것은 Architecture, Governance, Contract Law, Compliance 문제입니다. 그래서 “하지만 개인정보 보호는요?”라는 반사적인 표현은 별로 도움이 되지 않습니다. 너무 많은 서로 다른 문제를 하나의 Label 아래 섞어 버리기 때문입니다.

개인정보 보호를 Constraint로 보기

이제 다시 이전 글로 돌아옵니다.

이전 글에서는 Agent의 구조적 Solution Space를 줄이는 방법을 다뤘습니다. 기술적으로 가능한 모든 Architecture가 허용되어야 하는 것은 아닙니다. Agent가 Presentation Layer를 Database에 직접 연결할 수 있다고 해서 그런 Solution을 받아들여야 하는 것은 아닙니다.

Architecture는 Constraint를 설정합니다.

Information Protection도 비슷합니다. Agent가 기술적으로 어떤 정보에 접근할 수 있다고 해서 그 정보가 Agent Context의 일부가 되어야 하는 것은 아닙니다.

Architecture Constraints
↓
어떤 구조적 Solution이 허용되는가?

여기에 다음이 추가됩니다.

Information Constraints
↓
어떤 Information과 Capability가 허용되는가?

나에게 이것은 Agentic Work의 개인정보 보호를 이해하는 훨씬 생산적인 방식입니다. Agent에는 실제 개인정보 보호 Risk도 있고, Confidentiality Risk도 있으며, Security Risk도 있습니다. Agency가 커질수록 더 많은 정보와 더 많은 Action이 가능해지므로 Risk도 커질 수 있습니다.

하지만 이 Risk는 신비한 것이 아닙니다. 분석하고 모델링할 수 있고 Architecture를 통해 영향을 줄 수 있습니다. Permission으로 제한하고, Monitoring하고, Verification할 수 있습니다. 그리고 어떤 Risk는 Information Flow 자체를 허용하지 않음으로써 완전히 피할 수도 있습니다.

개인정보 보호는 Agentic Work의 KO 기준이 아니다. 시스템의 Constraint다.

그렇다고 개인정보 보호가 해결됐다는 뜻은 아닙니다. 구체적으로 다룰 수 있다는 뜻입니다.

여기서도 특히 중요한 규칙 하나가 남습니다.

Relevant하다고 해서 자동으로 permissible한 것은 아니다.

중요한 질문은 Agent가 이론적으로 어떤 정보를 처리할 수 있느냐가 아닙니다. 이 정확한 Task를 위해 우리가 실제로 어떤 정보를 Agent에게 제공하고 싶은가입니다.

이 질문을 명확히 답할 수 있다면 “AI? 하지만 개인정보 보호는요?”는 이미 훨씬 더 나은 논의로 바뀝니다.

어떤 정보를 처리할 것인가, 누가 볼 수 있는가, Agent가 왜 필요한가, 어떤 Trust Boundary를 넘는가, 유출되었을 때 어떤 결과가 생기는가, 그리고 그 Boundary를 기술적으로 어떻게 강제할 것인가?

이것은 문제를 축소하는 것이 아닙니다. 문제를 구체화하는 것입니다. 바로 그 지점에 Demystification이 있습니다.

Requirements, Architecture, Information Boundary를 통해 허용된 Solution Space는 이미 상당히 작아졌습니다. 그렇다고 Deterministic해진 것은 아닙니다. 잘 정의된 Constraint 안에서도 Agent는 기능적으로도 기술적으로도 유효한 여러 Solution을 만들 수 있습니다.

그래서 다음 글에서는 이런 Variance를 단순히 견디는 것이 아니라 의도적으로 활용하는 방법을 다룹니다.

Diverge · Decide · Converge.

출처와 맥락

GDPR – Regulation (EU) 2016/679, EUR-Lex
개인정보, 특별 범주의 개인정보, 처리, Data Minimization, Privacy by Design, 처리 보안 및 기타 개인정보 보호 원칙의 주요 법적 근거입니다. 이 글의 두 축 모델이나 Coding Agent의 특정 Trust Boundary 모델을 정의하지는 않습니다.
https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679

독일 Datenschutzkonferenz – 인공지능과 개인정보 보호, 2024
AI 사용과 다양한 Processing Step의 구분에 관한 규제 가이드입니다. Training과 입력 저장 같은 문제도 다룹니다. 특정 AI 제품에 대한 일반적인 승인이나 금지 규칙은 아닙니다.
https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf

독일 Datenschutzkonferenz – AI 시스템의 기술적·조직적 조치, 2025
Data Protection by Design, Data Minimization, Risk Analysis, 그리고 AI 시스템 전체 Lifecycle에서 적용할 수 있는 Technical & Organizational Measure에 관한 가이드입니다.
https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf

독일 Datenschutzkonferenz – RAG 기반 생성형 AI 시스템의 개인정보 보호 특성, 2025
Rights & Roles Concept, Retrieval, Reference Document, Vector Database, On-Premise Scenario와 관련됩니다. “RAG는 Privacy Shield가 아니다”라는 표현은 이 글의 기술적 요약이며 DSK의 직접 인용은 아닙니다.
https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf

BfDI – 공공기관에서의 AI: 처음부터 개인정보 보호를 고려하기, 2025
독일 연방행정을 대상으로 LLM 사용과 개인정보 보호 문제를 다루는 지침입니다. 대상은 연방행정이며 모든 기업에 적용되는 일반 법규는 아닙니다.
https://www.bfdi.bund.de/SharedDocs/Downloads/DE/DokumenteBfDI/Dokumente-allg/2025/Handreichung-KI.pdf

독일 영업비밀보호법 – § 2 GeschGehG
영업비밀과 그 성립 요건을 정의합니다. 개인정보와 영업비밀은 서로 다른 보호 범주이며 겹칠 수 있습니다. 모든 비공개 Source Code가 자동으로 영업비밀 요건을 충족하는 것은 아닙니다.
https://www.gesetze-im-internet.de/geschgehg/__2.html

BSI – Indirect Prompt Injections
Application-integrated Language Model의 Risk와 External Content, Tool Integration으로 생기는 추가 Attack Vector에 대한 Technical Security Guidance입니다. 개인정보 처리의 법적 허용 여부를 판단하는 자료는 아닙니다.
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2023/2023-249034-1032.html

이 글의 Engineering Inference
개인정보 관련성과 잠재적 Disclosure Damage를 함께 보는 두 축 모델은 GDPR의 공식 Classification이 아닙니다. Identity → Authorization → Retrieval → Context → LLM, Task-specific Agent Permission에 Least Privilege를 적용하는 방식, 그리고 **“File Boundary는 자동으로 Information Boundary가 아니다”**라는 표현도 마찬가지로 이 글에서 사용하는 Engineering Model입니다. 추상적인 보호 요구를 기술적으로 논의하고 검증할 수 있는 Boundary로 변환하기 위한 모델입니다.