## 소개 이번 주에는 정보보호 업무 위키를 단순히 “자료를 모아두는 곳”에서 한 단계 더 밀어봤습니다. 목표는 여전히 같습니다. > 정보보호 업무에서 반복되는 판단을, 봇이 안전하게 참고해서 답할 수 있는 형태로 쌓기. 지난주까지는 큰 골격을 만들었습니다. - 원본 → 출처 노트 → 승인된 판단 레이어를 분리 - 봇이 인용 가능한 문서와 인용하면 안 되는 초안을 구분 - 업무 메신저 공개 채널에서는 내부 경로·원문·운영 정보를 노출하지 않도록 제한 - 법령 조문은 원문 대조 후에만 근거로 쓰도록 설정 이번 주에 새로 한 일은 “자료를 더 넣기”보다, 실제 운영하면서 부딪힌 질문을 통해 구조를 조금 더 정교하게 만든 것입니다. 특히 고민이 컸던 부분은 세 가지였습니다. 1. **서비스·데이터·처리행위 같은 메타데이터를 위키에 어떻게 붙일 것인가** 2. **업무 메신저에서 들어오는 요청을 어디까지 자동 처리할 것인가** 3. **내부식별값·AI 로그·스크립트 자동화 같은 실제 정보보호 이슈를 어떻게 판단 초안으로 바꿀 것인가** ## 만든 것 / 이번 주 결과물 이번 주에 정보보호 업무 위키에는 크게 네 종류의 변화가 있었습니다. ### 1. 앱·웹 이벤트 로그 내 내부식별값 기준 초안 `payment_attempt_id`, `device_identifier`, `session_identifier` 같은 값은 이름·전화번호처럼 직접 식별 가능한 정보는 아닐 수 있습니다. 하지만 내부 테이블과 결합하면 특정 개인, 기기, 거래, 행동 이력과 연결될 수 있습니다. 그래서 이번 주에는 “이벤트 로그에 이런 내부식별값을 적재할 수 있는가?”를 다루는 정책 초안을 만들었습니다. 처음에는 단순히 “민감한 정보는 이벤트 로그 적재 금지”처럼 쓰면 될 것 같았는데, 실제로는 그렇게 간단하지 않았습니다. - 직접식별정보/고위험 민감한 정보는 적재 금지로 잡을 수 있음 - 내부식별값은 정보보호 관리 대상 식별값으로 관리해야 함 - 하지만 분석·장애대응·퍼널 분석상 필요한 경우가 있음 - 해시나 대체키도 안정적으로 조인되면 정보보호 관점의 식별 가능성이 사라지지 않음 - 자유입력값이나 원문 형태의 로그 값는 이미 로그 구조에 섞여 있을 수 있어, 일괄 금지보다 별도 고위험 관리가 현실적임 정리하면, 이번 초안의 핵심은 이겁니다. > 내부식별값은 “민감한 정보가 아니다”가 아니라 “정보보호 관리 대상 식별값으로 보되, 목적·필요성·보호조치·보유기간·downstream 제한을 붙여 조건부 검토한다.” 여기서 중요했던 건 접근권한이나 다운로드 통제 같은 기본 보안조치를 길게 나열하지 않는 것이었습니다. 그런 통제는 이미 플랫폼 전체에 적용되는 전제에 가깝기 때문입니다. 대신 정보보호 판단에서 진짜 갈리는 지점 — 목적 적합성, 대체수단, 조인 가능성, 보유기간, 재활용 제한 — 을 중심으로 정리했습니다. ### 2. AI 입력·출력 보호 로그 모니터링 초안 주간 업무 회의에서 AI 입력·출력 보호 장치와 관련된 로그·대시보드 이야기가 나왔습니다. 이 내용을 위키에 바로 “정답”으로 넣지는 않고, 판단 초안으로 분리했습니다. AI 입력·출력 보호 로그는 일반적인 시스템 로그와 다르게 볼 필요가 있습니다. - 프롬프트나 응답에 민감한 정보가 섞일 수 있음 - 탐지 결과, 요청자, 서비스 ID, 메시지 타입 등이 운영 점검에 쓰일 수 있음 - 룰 튜닝이나 품질 개선 목적으로 재활용하고 싶어질 수 있음 그래서 초안에는 “로그가 있다/없다”보다 다음 질문을 남겼습니다. - 메시지 원문이 저장되는가? - 원문이 저장된다면 보관기간은 얼마인가? - 보호 장치 개선 목적으로 재활용하는가? - 접근 권한은 운영 목적상 필요한 사람으로 제한되는가? - 서비스별 책임자나 요청자가 후속 조치를 볼 수 있는가? 이건 아직 승인된 기준이 아니라, 이후 검토할 쟁점을 놓치지 않기 위한 초안입니다. ### 3. 현업 자동화·스크립트·업무 테이블 관련 주간 업무 회의 주제 인입 이번 주 주간 업무 회의 회의록도 위키에 넣었습니다. 회의록 자체를 공식 판단 판단으로 올린 것이 아니라, 반복 판단으로 바뀔 수 있는 주제를 분리했습니다. 예를 들면: - 현업이 직접 만드는 자동화나 스크립트처럼 현업이 직접 만드는 자동화에서 정보보호 검토를 어떻게 통제할 것인가 - 클라우드 문서·스프레드시트 연동이나 업로드 파일이 있을 때 탐지·모니터링을 어떻게 볼 것인가 - 특정 업무 테이블이나 내부 사용자 식별자만 있는 테이블을 정보보호 관리 대상 테이블로 볼지 여부 - 계약서 OCR·AI 자동화가 위수탁 범위 안에 들어오는지 여기서도 원칙은 같았습니다. > 회의록은 출처이고, 위키의 자산은 “반복해서 답할 수 있는 판단 구조”다. 그래서 회의록을 그대로 복사해 넣기보다, 각 주제별로 policy 또는 faq 초안 후보를 만들었습니다. ### 4. 문서 메타데이터를 온톨로지로 바로 가지 않고, 문서 메타데이터로 먼저 붙이는 방향 이번 주에 제일 오래 고민한 건 이 부분입니다. 처음에는 “서비스 ID를 위키에 넣자” 정도였습니다. 예를 들어 특정 검토가 어떤 서비스와 관련 있는지, 어떤 동의서나 계약과 연결되는지 추적하고 싶었습니다. 그런데 조금 생각해보니 서비스만으로는 부족했습니다. 실제 정보보호 판단은 보통 이런 식입니다. - 어떤 서비스가 - 어떤 데이터 항목을 - 어떤 시스템에 저장하거나 제공하고 - 어떤 목적과 법적 근거로 처리하며 - 어떤 조건과 보호조치가 붙었는가 이건 거의 온톨로지 구조에 가깝습니다. Service, DataElement, Processing, Purpose, Control, Decision을 노드로 두고 관계를 연결하면 예쁘게 표현할 수 있습니다. 하지만 바로 지식 그래프를 만들지는 않기로 했습니다. 이유는 단순합니다. - 지금 단계에서 ontology vocabulary를 먼저 정하면 운영이 무거워짐 - 사람이 매번 relation을 정확히 쓰기 어렵고, 위키 작성 속도가 떨어짐 - 아직 어떤 필드가 진짜 반복적으로 필요한지 검증되지 않음 - Markdown 기반 위키의 장점은 가볍게 쓰고 고치는 데 있음 그래서 지금은 “온톨로지 지향 문서 메타데이터” 정도가 맞다고 봤습니다. 예시는 이런 식입니다. ```yaml service_refs: - service_id: null service_name: "공통" role: "policy_scope" id_confidence: "not_applicable" data_refs: - data_id: "payment_attempt_id" classification: "privacy_identifier" role: "example" processing_refs: - system: "event_log" action: "store" purpose: "payment_funnel_analysis" decision_rule: "conditional_review_required" control_refs: - type: "retention" value: "5y_then_delete" - type: "approval" value: "identifier_review_process" ``` 아직 이 필드를 정식 스키마로 확정한 것은 아닙니다. 이번 주에는 “이런 방향이 맞다”는 판단까지만 했습니다. 핵심은, 지금 위키를 문서 중심으로 운영하되 나중에 그래프로 바꿀 수 있게 흔적을 남기는 것입니다. ## 진행 과정 ### 1. 위키에 무엇을 넣을지보다, 어떤 상태로 넣을지를 먼저 구분했다 이번 주에 계속 반복한 구분은 네 단계입니다. - **원문 보관**: 원문이 들어온 상태 - **색인 완료**: 출처 노트나 index로 찾을 수 있는 상태 - **판단 초안**: 정보보호 판단 초안으로 재구성된 상태 - **승인 완료**: 사람이 검토해서 봇이 인용해도 되는 상태 이 구분이 없으면 “인제스트했다”는 말이 너무 위험해집니다. 예를 들어 정부 가이드 PDF 100개를 넣었다고 해서, 봇이 그 내용을 공식 답변처럼 말해도 되는 것은 아닙니다. 그건 원문 보관 + 색인 완료일 뿐입니다. 실제 답변에 쓰려면 정보보호 판단으로 합성하고, 근거를 검증하고, 사람이 승인해야 합니다. 이번 주에 새로 들어온 주간 업무 회의나 앱로그 논의도 대부분 `판단 초안` 전후 단계입니다. 즉, “위키 안에 들어왔지만 아직 공식 답변 근거는 아닌” 상태입니다. ### 2. 업무 메신저 요청은 편하게 받되, 쓰기 권한은 좁혔다 운영하면서 업무 메신저에서 들어오는 요청이 생각보다 중요했습니다. 실제 업무 질문은 업무 메신저에서 오고, 회의록이나 스레드도 업무 메신저에 많이 남기 때문입니다. 하지만 업무 메신저 공개 채널에서 봇이 마음대로 로컬 위키를 수정하거나 문서 도구에 쓰기 시작하면 위험합니다. 그래서 기본 원칙은 이렇게 잡았습니다. - 공개/공유 채널에서는 Q&A 중심 - 내부 경로, Git 상태, 원본 저장 위치, 미승인 초안 세부내용은 노출하지 않음 - 위키 저장·승격·외부 발행은 기본적으로 관리자/관리자 컨텍스트에서 처리 - 다만 정보보호 담당팀의 좁은 주간 회의록 추가 요청처럼 범위가 명확한 반복 업무는 예외적으로 허용 이 예외도 무제한이 아니라, “기존 위클리 페이지의 사람/요청자 섹션 아래에 좁게 append” 정도로 제한했습니다. 새 페이지를 만들거나 다른 Notion을 수정하는 것은 별도 확인이 필요합니다. 이번 주의 교훈은 봇의 편의성을 높일수록, 쓰기 범위는 더 좁고 명확해야 한다는 것이었습니다. ### 3. 봇이 틀린 답을 한 뒤, 규칙을 다시 고쳤다 이번 주에는 봇 운영상 실수도 있었습니다. 업무 메신저 링크를 읽을 수 있는 상황인데도 실제 스레드를 읽지 않고 “읽을 수 없다”는 식으로 답하거나, 위클리 등록 요청을 엉뚱한 위치로 보낸 일이 있었습니다. 이건 모델의 지능 문제가 아니라 운영 규칙의 문제로 봤습니다. 그래서 규칙을 더 명시적으로 바꿨습니다. - 업무 메신저 링크가 주어지면 먼저 읽기 도구를 시도한다 - 접근 실패가 확인된 경우에만 “초대 또는 본문 paste 필요”라고 말한다 - 위클리 등록 요청은 어느 페이지/섹션에 append할지 제한한다 - 저장이 막히는 경우 “못 한다”로 끝내지 않고, 등록 가능한 초안을 제공한다 개인적으로 이 부분이 LLM Wiki 운영에서 꽤 중요하다고 느꼈습니다. 위키가 아무리 좋아도, 봇이 실제 업무 채널에서 잘못된 행동을 하면 신뢰가 바로 깨집니다. 그래서 지식 구조와 운영 룰을 같이 다뤄야 합니다. ## 실제 사용 예시 이번 주에 제가 봇과 나눈 질문은 이런 식이었습니다. ```text 지금 구조와 온톨로지 구조와는 어떤 차이가 있어? ``` 이 질문을 통해 정리된 답은 다음과 같았습니다. - 지금 구조는 문서 중심: “이 문서가 어떤 서비스와 관련 있는가”를 문서 메타데이터로 표시 - 온톨로지 구조는 관계 중심: “서비스가 어떤 데이터를 생성하고, 어떤 시스템이 저장하고, 어떤 결정을 통해 허용됐는가”를 entity-relation으로 표현 - 현재 단계에서는 full ontology보다 `service_refs + data_refs + processing_refs` 정도의 온톨로지 지향 문서 메타데이터가 현실적 이 답이 좋았던 이유는, 단순히 개념 설명으로 끝나지 않고 위키 스키마의 다음 진화 방향을 정하는 데 도움이 됐기 때문입니다. ## Before vs After ### Before - 질문과 판단이 업무 메신저, 문서 도구, 회의록, 스프레드시트, 법령 검색 결과에 흩어져 있음 - “인제스트했다”는 말이 원문 저장인지, 초안 작성인지, 공식 답변 가능 상태인지 불명확함 - 서비스 ID, 데이터 항목, 처리행위 같은 메타데이터를 어떻게 남길지 정해지지 않음 - Slack 봇이 읽기/쓰기 경계를 헷갈리면 잘못된 답변이나 잘못된 등록이 발생할 수 있음 ### After - 위키 안의 상태를 원문 보관 / 색인 완료 / 판단 초안 / 승인 완료로 구분 - 회의록과 업무 메신저 논의를 바로 공식화하지 않고, 출처와 초안 후보로 분리 - 이벤트 로그 내부식별값, AI 입력·출력 보호 로그, 현업 자동화 검토 같은 반복 주제를 정책/FAQ 초안로 전환 - 서비스·데이터·처리행위 추적은 바로 온톨로지로 가지 않고, 문서 메타데이터 확장 후보로 정리 - 업무 메신저 링크 읽기와 주간 업무 회의 append의 운영 경계를 더 명확히 함 ## 결과와 배운 점 ### 1. LLM Wiki는 검색보다 “상태 관리”가 먼저다 자료를 많이 넣는 것보다, 그 자료가 어떤 상태인지 표시하는 게 더 중요했습니다. 같은 문서라도 원문 보관 상태와 승인 완료 상태는 전혀 다릅니다. 봇이 답변에 인용해도 되는 것은 승인 완료뿐입니다. 나머지는 힌트, 초안, 검토 후보입니다. 이 구분이 없으면 위키는 금방 “그럴듯한 자료 더미”가 됩니다. ### 2. 온톨로지는 나중에, 흔적은 지금부터 서비스, 데이터, 처리행위, 목적, 통제, 결정은 분명히 관계형으로 관리하고 싶어집니다. 하지만 지금 바로 지식 그래프를 만들면 작성 부담이 너무 큽니다. 그래서 이번 주 결론은 이렇습니다. > 지금은 Markdown 위키의 가벼움을 유지하되, 나중에 ontology로 바꿀 수 있는 문서 메타데이터 흔적을 남긴다. 이 방식이 좋았던 이유는, 위키를 쓰는 사람의 부담을 늘리지 않으면서도 미래 확장성을 닫지 않기 때문입니다. ### 3. 정보보호 도메인의 봇은 “답변 품질”만으로 평가하면 안 된다 정확한 답을 하는 것도 중요하지만, 그보다 먼저 봇이 다음을 지켜야 합니다. - 검증 안 된 법령 조문을 만들지 않기 - 미승인 초안을 공식 근거처럼 말하지 않기 - 공개 채널에 내부 원문이나 운영 정보를 흘리지 않기 - 쓰기 작업은 허용된 범위에서만 하기 - 실패했을 때 회피하지 않고, 가능한 초안이나 다음 액션을 제시하기 이번 주 실수와 수정은 이 기준을 더 분명하게 해줬습니다. ## 다음에 해볼 것 다음 단계는 크게 세 가지입니다. 1. **문서 메타데이터 확장 후보를 작은 범위에서 실험** - `service_refs`, `data_refs`, `processing_refs`를 바로 전체 스키마로 확정하지 않고, 이벤트 로그/AI 로그 같은 1~2개 초안에 먼저 붙여봅니다. 2. **승인 완료로 올릴 후보를 더 엄격하게 고르기** - 초안는 늘어나고 있지만, 봇이 인용 가능한 문서는 아직 제한적입니다. 검증 병목을 줄이되, 사람 승인 게이트는 유지하려고 합니다. 3. **Slack 운영 실패를 평가셋처럼 모으기** - 봇이 틀린 답을 한 사례는 단순 장애가 아니라 좋은 테스트 케이스입니다. “다음에는 같은 요청에 어떻게 답해야 하는가”를 룰과 스킬에 반영하면 운영 품질이 올라갑니다. ## 마무리 이번 주에 가장 크게 느낀 건, 정보보호 업무 위키는 “지식을 많이 넣는 프로젝트”가 아니라 “봇이 어떤 지식을 어떤 권한으로 말할 수 있는지 정하는 프로젝트”라는 점입니다. 자료는 계속 늘어납니다. 하지만 진짜 자산은 원문 사본이 아니라, 검증된 판단과 그 판단이 만들어지는 절차입니다. 그래서 당분간은 큰 인프라보다 작은 원칙들을 더 단단하게 만들 생각입니다. - 원본과 판단을 섞지 않기 - 초안과 승인본을 섞지 않기 - 내부 운영 정보와 공개 답변을 섞지 않기 - 문서 태그와 지식 그래프 사이에서 너무 빨리 무거운 쪽으로 가지 않기 이 네 가지를 지키는 것만으로도, LLM Wiki가 업무에서 실제로 쓸 수 있는 형태에 가까워지고 있습니다. [확인 필요] - 공개 글로 올릴 때 회사명, 제품명, 내부 시스템명은 더 일반화하는 것이 안전합니다. - 숫자 지표나 시간 절감 효과는 아직 측정하지 않았으므로 넣지 않았습니다. - `service_refs/data_refs/processing_refs`는 아직 확정 스키마가 아니라 실험 후보로 표현했습니다.
