전 직장 이야기를 NDA 깨지 않고 쓰는 법 — 식별자 전수 대조 익명화 워크플로

이름을 지워도 남는 정보가 있다

이 블로그의 실무 글을 정리하면서 회사명과 내부 주소를 지우는 것만으로는 부족하다는 점을 확인했다. 사건의 시점, 담당자의 역할, 정확한 수치가 겹치면 특정 회사나 사람을 떠올릴 수 있다. 나는 이런 단서의 조합을 이 글에서 '서사 지문'이라고 부른다.

예를 들어 “입사 첫 주에, 세 명이 특정 시스템을 두 달 만에 교체했다”는 가상 문장을 보자. 회사명은 없지만 당시 일을 아는 사람에게는 시점과 인원, 사건이 단서가 될 수 있다. 회사명 같은 직접 식별자와 이런 정황을 함께 살펴야 했다.

공개 범위는 식별 가능성만으로 정할 수 없다. 비밀유지계약(NDA, Non-Disclosure Agreement)이 보호하는 내용과 공개 허용 범위는 계약에 따라 확인해야 한다. 영업비밀도 일정 요건을 갖춘 기술상·경영상 정보를 포함하므로, 이름을 바꿨다고 기술 내용까지 공개 가능한 것은 아니다. 이 글의 익명화는 노출 위험을 줄이는 편집·검수 절차를 뜻하며, 계약 준수를 보증하는 방법은 아니다. 부정경쟁방지법 제2조

내 기여와 설명에 필요한 정보부터 남긴다

먼저 글에서 전달하려는 판단과 내가 직접 한 일을 정한다. 다른 사람이 설계한 전체 구조를 내 성과처럼 쓰지 않고, 내가 구현하거나 분석한 범위를 구분한다. 독자가 그 판단을 이해하는 데 필요하지 않은 조직 관계, 사건의 날짜, 내부 운영 규모는 덜어낸다.

동료가 알아볼 수 있는지를 생각해 보는 것도 점검 방법이다. 다만 “누구도 알아보지 못한다”는 것을 내가 확인할 수는 없다. 블로그의 다른 글이나 공개된 경력과 연결했을 때 대상이 좁혀지는지도 함께 읽어야 한다. 식별자를 지운 한 문장만 보아서는 이런 연결을 놓치기 쉽다.

세부 정보를 줄인다고 경험 자체를 바꾸지는 않는다. 실제로 측정하지 않은 성능 수치를 만들거나, 맡지 않은 역할을 덧붙이면 기술 글의 근거가 달라진다. 설명용으로 만든 수치와 코드는 재구성 예제라고 밝히고 실제 관측 결과와 구분한다.

코드는 이름만 바꾸지 않고 최소 예제로 재구성한다

회사명이나 내부 코드명은 일반적인 표현으로 바꾸고, 설명에 필요 없는 식별 정보는 삭제한다. 비밀번호와 인증 키는 예제에도 넣지 않는다. 유효한 비밀정보의 노출을 발견했다면 글에서 지우는 일과 별개로, 권한 있는 담당자가 폐기·재발급 등 대응 필요성을 확인해야 한다.

회사 코드는 변수·테이블·함수명을 바꾸는 것만으로 재구성이 끝나지 않는다. 고유한 처리 규칙이나 데이터 관계가 그대로 남을 수 있기 때문이다. 전달하려는 기법에 필요한 조건만 남기고, 별도의 가상 데이터로 설명할 수 있는 예제를 새로 작성한다.

다음 SQL은 고객과 주문 항목을 키로 연결하는 방식만 보여 주는 가상 예제다. 실제 회사 코드나 스키마를 옮긴 것이 아니며, 원본과의 일대일 대응도 제시하지 않는다.

-- 설명용 가상 테이블을 조인하는 최소 예제
SELECT c.id, o.amount
FROM customer c
JOIN order_line o ON c.id = o.customer_id;

이름이 평범하다고 모든 예제가 안전한 것은 아니다. 반대로 id처럼 흔한 이름이 원자료와 겹쳤다는 이유만으로 유출이라고 단정할 수도 없다. 어떤 정보가 남았는지, 그 조합이 원자료의 고유한 내용을 드러내는지를 검토해야 한다.

추출한 목록 전체를 대조하되, 추출의 한계도 남긴다

처음에는 떠오르는 회사명이나 내부 용어를 검색했다. 이후에는 원자료에서 식별자 후보를 추출한 목록을 만들고 글과 대조하는 방식으로 검수를 보완했다. 이 반복 작업에는 블로그 운영을 돕는 AI 에이전트와 스크립트를 사용했다. 무엇을 공개할지 판단하는 역할과 문자열을 비교하는 작업을 나눈 것이다.

여기서 '전수 대조'는 정한 목록의 모든 항목을 정한 검사 대상에 대조한다는 뜻이다. 원자료에 있는 민감한 정보를 빠짐없이 추출했다는 뜻은 아니다. 소스 코드, 실행계획, 문서는 구조가 달라 같은 추출 규칙으로 모두 읽을 수 없고, 이미지 속 글자는 일반 텍스트 검색에서 빠진다.

목록에는 회사명, 내부 도메인, 고유한 객체명처럼 직접적인 식별자 후보를 담는다. 대조할 때는 대소문자나 표기 차이, HTML 인코딩 등으로 같은 값이 다르게 보일 수 있는지도 확인한다. 검색 방식도 구분해야 한다. 단순 부분 문자열 검색은 조사나 흔한 단어까지 잡을 수 있고, 경계를 엄격하게 잡으면 변형된 이름을 놓칠 수 있다.

따라서 결과에는 검사한 파일과 목록의 범위, 적용한 비교 규칙, 확인된 일치 항목과 예외 사유를 남기는 편이 좋다. 도구가 읽지 못한 파일은 '일치 없음'으로 처리하지 않고 검사 누락으로 표시해야 한다. 새로 지은 예제 이름이 원자료와 겹치는지도 이 과정에서 확인하되, 우연한 일치인지 민감한 식별자인지 사람이 판단한다.

원자료를 더 많이 모으는 것 자체가 목표는 아니다. 접근과 사용이 허용된 자료만 필요한 범위에서 다루고, 민감한 원문이나 실제 식별자 목록을 공개 저장소·검사 로그에 남기지 않는다. 외부 AI 서비스로 보내는 것도 별도의 정보 전달이므로 허용 범위를 확인해야 한다. 검수를 위해 만든 목록이 또 다른 노출 경로가 되지 않게 해야 한다.

공개 전에 검사하고, 배포 뒤에는 반영 결과를 확인한다

본문을 고친 뒤에도 빌드 과정에서 요약과 검색 색인이 만들어진다. 이미지나 첨부 파일에는 본문 검색으로 찾을 수 없는 정보가 남을 수 있다. 그래서 초안만 읽는 데서 끝내지 않고 다음처럼 검사 대상을 나눈다.

공개 저장소라면 푸시한 순간부터 파일을 볼 수 있다. 따라서 배포 뒤 검사는 최초 유출을 막는 관문이 될 수 없다. 푸시 전에 공개할 범위를 검사하고, 배포 뒤에는 이미 검수한 파일과 공개 결과가 일치하는지 확인해야 한다. 화면에 보이는 본문만 읽어서는 검색 색인이나 첨부 파일의 내용을 확인할 수 없다.

수정 전 커밋에 민감한 내용이 있다면 현재 파일에서 지웠다는 사실만으로 해결되지 않는다. Git 이력과 다른 공개 사본에 남았는지까지 확인해야 한다. 이 글에서 다루는 절차는 이런 확인 지점을 정리한 것이며, 모든 유형의 정보가 자동으로 탐지된다는 보장은 아니다.

검사 결과 0건의 의미를 좁혀 기록한다

목록과 대조해 일치 항목을 찾지 못했다면, 확인한 사실은 그 목록과 검사 범위 안에서 일치가 없었다는 것이다. 정황을 연결한 추론이나 목록에 넣지 못한 정보까지 사라졌다고 말할 수는 없다. NIST도 비식별화가 위험을 줄일 수 있지만 일부 비식별 데이터는 다시 식별될 수 있다고 설명한다. NIST IR 8053

방법을 공개해도 역추론이 불가능하다는 주장 역시 검증할 수 없다. 원본과 수정본의 대응표를 공개하지 않더라도 사건의 조합이나 다른 글이 단서가 될 수 있다. 영국 ICO의 익명화 지침도 독자가 가진 배경지식과 접근 가능한 다른 정보를 함께 고려한다. 이는 개인 식별 위험을 살피는 참고 관점이며, 특정 회사와의 계약 위반 여부를 판정하는 기준은 아니다. ICO의 식별 가능성 검토 지침

이 워크플로에서 얻은 것은 위험이 0이라는 증명보다 검수의 근거를 남기는 방식이었다. 기억에 의존하던 검색에 목록 대조를 더하고, 글에서 빠진 식별자가 빌드 산출물에도 없는지 확인했다. 면접에서도 같은 공개 범위를 지켜야 한다. 비공개 대화라는 이유로 블로그에서 제외한 기밀을 설명해도 되는 것은 아니다.

학습

• 식별 정보와 공개 가능한 기술 내용을 함께 검토해야 한다. 이름을 지워도 고유한 처리 규칙이나 사건의 조합이 남을 수 있다.
• 목록 대조는 검수 범위를 분명하게 만든다. 추출 누락과 오탐은 별도로 확인하고, 결과 0건을 전체 정보의 안전성으로 확대하지 않는다.
• 공개 전 검사와 배포 후 확인의 역할은 다르다. 전자는 노출을 막기 위한 검토이고 후자는 검수한 결과의 반영 확인이다. 어느 파일과 버전을 봤는지 남겨야 수정 후에도 같은 기준으로 확인할 수 있다.