연재: AI에게 일자리를 빼앗길 불안으로부터 시작하는 하네스 작성 입문

| 회차 | 타이틀 | 상태 |

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

| 제1회~제19회 | (기간행) | ✅ |

| 제20회 | 프롬프트 투입 전 마스킹·복원 플로우를 설계한다 | 📖 |

| 제21회 | 하네스 작성을 포트폴리오화하는 방법 | ─ |

| 제22회 | Qiita 연재와 GitHub 리포지토리를 연동하는 운용 | ─ |

| 제23회 | AI 하네스를 부업·수탁·사내 개선에 전용하기 전에 생각할 것 | ─ |

| 제24회 | 12주간의 하네스 연재를 되돌아보며, 다음에 만들 AI 기반을 결정한다 | ─ |

AI 하네스를 만들다 보면, 언젠가 반드시 부딪히는 문제가 있습니다. "이 데이터, LLM에 전달해도 괜찮을까?"라는 질문입니다.

SE 경험이 있는 분이라면, 운영 환경의 데이터를 다룰 때 주의를 기울여 온 경험이 있을지도 모릅니다. 그 감각은 AI 활용에서도 변하지 않습니다. 오히려 외부 API에 데이터를 보내는 행위는 기존의 사내 시스템 운용 이상으로 신중함이 요구되는 상황이 있습니다.

이번에는 LLM에 프롬프트를 투입하기 전에 데이터를 마스킹(Masking)하고, 결과를 받은 후에 복원하는 "마스킹·복원 플로우"의 설계 패턴을 생각합니다.

LLM의 API를 이용할 때, 송신한 데이터가 어떻게 다뤄지는지는 제공처의 정책에 의존합니다. 판단이 어려울 때를 위해 리스크 관점을 정리해 두도록 합시다.

포인트는 "모든 것을 금지하는" 것이 아니라, 무엇을 지켜야 하는지를 명확히 하여 지켜야 할 것만 마스킹하는 것입니다.

다음과 같은 분류로 생각하면 대상을 좁히기 쉬워집니다.

필수 마스킹: 개인 이름, 이메일 주소, 전화번호, 신용카드 번호 등 -
권장 마스킹: 사내 프로젝트명, 고객사명, 내부 API 키 등 -
불필요: 일반적인 기술 용어, 공개 정보, 샘플 데이터

다음의 Mermaid 플로우도는 마스킹·복원 파이프라인의 전체상을 보여줍니다.

이 설계의 포인트는 3가지가 있습니다.

마스킹 처리: 기밀 데이터를 플레이스홀더(Placeholder)로 치환하고, 매핑 테이블(Mapping Table)을 생성 -
LLM API 호출: 마스크 처리된 데이터만 외부로 송신됨 -
복원 처리: 매핑 테이블을 사용하여 플레이스홀더를 원본 데이터로 되돌림

import re
from dataclasses import dataclass, field
@dataclass
...

# 마스킹→LLM 투입→복원의 흐름
masker = DataMasker()
original_prompt = """
...

주의: 위의 인명 검출은 정규 표현식(Regular Expression)만으로는 어려울 수 있습니다. 실제 운용에서는 사전 기반이나 형태소 분석 라이브러리의 병용을 검토하십시오.

프로젝트마다 지켜야 할 데이터는 다릅니다. 커스텀 패턴을 추가할 수 있는 설계로 해두면 하네스의 범용성이 높아집니다.

# 커스텀 패턴 추가 예시
masker = DataMasker()
# 사내 프로젝트 코드를 마스킹 대상으로 추가
...

마스킹·복원 플로우를 하네스에 포함할지 여부는 다음 판단 기준으로 생각해 보십시오.

"지금 당장 필요하지 않다"라고 판단한 경우라도, 장래의 확장을 고려하여 마스킹 처리의 삽입 포인트만은 확보해 두는 선택도 있습니다.

매핑 테이블 자체가 기밀 정보를 포함하므로 다음 사항에 주의하십시오.

메모리 상에서 관리: 가능한 한 파일로 쓰지 말 것 -
처리 완료 후 파기: 복원이 끝나면 매핑을 삭제 -
로그에 출력하지 않음: 디버깅 시에도 원본 데이터의 노출에 주의

정규 표현식만으로 모든 기밀 데이터를 검출하는 것은 어렵습니다. 다층 방어의 사고방식으로 대책을 세웁시다.

정규 표현식: 이메일 주소나 전화번호 등 정형 패턴 -
사전 매칭: 사명 리스트나 인명 리스트와의 대조 -
육안 확인: 초회 운용 시에는 마스크 처리된 프롬프트를 사람이 확인

여기까지 읽고 "이것은 데이터베이스의 마스킹 (Masking)과 사고방식이 같다"라고 느낀 분도 계실지 모릅니다. 그 감각은 정확합니다.

테스트 환경의 데이터 마스킹 (Data Masking) → LLM 투입 전의 마스킹 -
암호화와 복호화 (Encryption and Decryption) → 마스킹과 복원 -
액세스 제어 (Access Control) → 마스킹 대상의 분류

SE(시스템 엔지니어) 시절에 배양한 보안 감각은 AI 활용에서도 그대로 활용할 수 있습니다. 새로운 기술이라고 해서 처음부터 다시 배울 필요는 없습니다.

이번 포인트들을 되돌아봅니다.

• LLM에 데이터를 보내기 전에,
  무엇을 보호해야 하는지를 명확히 하는 것이 출발점 -
  마스킹 → API 호출 → 복원의
  **3단계 파이프라인 (Pipeline)**으로 안전성을 확보 -
  정규 표현식(Regular Expression) + 사전 + 육안 확인의
  **다층 방어 (Defense in Depth)**로 누락을 방지 -
  SE 경험의 보안 감각은
  그대로 전용할 수 있음

다음 제21회 "하네스 작성을 포트폴리오화하는 방법"에서는, 지금까지 만들어 온 하네스를 Qiita와 GitHub에 축적하여 커리어 자산으로서 보여줄 수 있는 형태로 정리하는 방법을 소개합니다. 기술력을 "시각화"하는 README 구성 템플릿도 함께 전달해 드립니다.

이 기사는 연재 시리즈 『AI에게 일자리를 빼앗길 불안으로부터 시작하는 하네스 작성 입문』 제20회입니다.

연재에 대한 피드백이나 질문은 댓글란 또는 Qiita의 DM으로 편하게 남겨주세요.