개인정보 감별사가 된 AI (상대적 중요성-유출&비용)

IT 현장에서 보안 엔지니어로 일하다 보면 가끔 이런 생각이 듭니다. 신기술이 쏟아져 나오는 속도에 비해, 정작 기술을 다루는 사람들의 기본기는 그 속도를 따라가지 못하고 있다는 느낌 말이죠. 고민 없이 일단 굴리고 보는 시스템을 수습하다 보면, 조직 안에서는 항상 ‘시간과 속도의 상대적 중요성’을 이야기하는 사람들과 마주하게 됩니다. 비즈니스에서는 타이밍이 생명이니 보안이나 검증 같은 가치는 상황에 따라 타협할 수 있는 상대적 가치로 취급되곤 합니다. 그에 비해 보안 엔지니어로서 데이터 거버넌스와 시스템 안정성이라는 ‘절대적 가치’를 고집하다 보면, 가끔은 내가 시대의 흐름을 못 맞추는 꼰대인가 싶어 자괴감이 들 때도 있습니다.

AI 시대라 생긴 재미있는 현상 시리즈

1단계. 도입 초기 (무지·맹신과 오남용)

• 1화 | 유출 & 비용: 개인정보 감별사가 된 AI — 무분별한 데이터 주입과 비용 폭탄
  
• 2화 | 불신: 베테랑의 연차보다 강력한 ‘AI 피셜’ — 전문가 조언을 밀어낸 AI 맹신과 신뢰 균열
  

2단계. 확산기 (역할 파괴와 공헌도 갈등)

• 3화 | 착각: 관리자의 바이브코딩 망상 — 실무 난이도 과소평가와 섣부른 직접 코딩
  
• 4화 | 혼돈: DBA 채용공고에 코딩이 들어간 이유 — 전 직군 개발 요구와 직무 인플레이션
  
• 5화 | 폄하: “AI가 짰는데 넌 뭐 했어?” — 디버깅과 설계 기여도를 지우는 성과 평가 왜곡
  

3단계. 심화 및 말기 (기술 부채 폭발과 통제 상실)

• 6화 | 배신: 당신이 알던 그 AI가 아닙니다 — 컨텍스트 한계와 비결정론이 부른 최종 파국
  
• 7화 | 부채: 기획자의 코딩, 그리고 쌓이는 빚 — 아키텍처 없는 양산이 부른 거대한 기술 부채
  
• 8화 | 방심: 취약점? AI로 갈아 끼우면 그만? — 의존성 이해 부재가 부른 대형 보안 사고
  

문제는 최근 이 대열에 보안 엔지니어 타이틀을 달고 오직 행동력만 앞세우는 이들이 대거 합류하면서, 이 ‘상대적 중요성’이라는 명분이 기형적인 면죄부로 쓰이고 있다는 점입니다. 특히 대규모 언어 모델(LLM)이 본격적으로 엔터프라이즈 환경에 적용되면서 이러한 왜곡은 더욱 극심해졌습니다. “대용량 비정형 데이터에서 민감 정보를 사람이 일일이 찾을 수 없으니 LLM에 분석을 맡기자”는 취지 자체는 최신 트렌드에도 부합하고 표면적으로는 나무랄 데가 없습니다. 그러나 시스템 설계와 거버넌스를 들여다보면 실소가 나오는 구조가 적지 않습니다.

어떤 모델을 쓰고 있는지, 우리가 던지는 프롬프트와 페이로드가 누구의 인프라로 전송되는지, 토큰 소비 구조가 어떻게 잡혀 있는지에 대한 공학적 계산이 전혀 없습니다. 회사 내부의 식별 정보, 계좌 정보, 미공개 사업 기획서가 외부 API 엔드포인트로 실시간 전송되고, 파이프라인 한 번 돌렸을 때 발생하는 비용이 수백만 원에 달하는 상황을 보면서 ‘이건 기술 도입이 아니라 자원 낭비이자 규제 위반 폭탄’이라는 결론에 도달하게 됩니다.

초기 엔터프라이즈 AI 도입 단계에서 발생하는 데이터 유출 위험과 토큰 비용 폭탄 문제를 살펴보고, ‘상대적 중요성’을 명분 삼아 벌어지는 경영진, 마케팅형 엔지니어, 그리고 진짜 엔지니어의 시각 차이와 현실적인 왜곡 현상을 현장 관점에서 정리해 보겠습니다.

엔터프라이즈 AI 도입 초기의 맹점: 무지와 오남용의 공존

기술 도입 주기에서 초기 국면은 대개 기술 자체에 대한 환상과 맹신으로 시작됩니다. 비즈니스 경쟁력을 확보해야 한다는 압박감 속에서 거버넌스 프레임워크나 보안 통제 정책은 ‘상대적 중요성’이라는 논리에 밀려 부차적인 과제로 전락하기 일쑤입니다.

통제되지 않는 데이터 파이프라인의 실태

현장에서 자주 목격되는 가장 전형적인 문제는 비정형 데이터 정제 작업에 범용 외부 LLM API를 무비판적으로 연결하는 구조입니다. 데이터베이스 덤프 파일, 고객 상담 로그, 사내 메신저 아카이브 등 수십 기가바이트에 달하는 텍스트 데이터를 통째로 프롬프트에 밀어 넣고 “개인정보나 이상 징후를 식별 또는 대응 방안을 알려줘”라고 요청하는 식입니다.

이 과정에서 발생하는 아키텍처적 문제는 명확합니다.

• 엔드포인트 신뢰성 부재: 사내 프라이빗 네트워크 내부에서 처리되어야 할 민감 데이터가 외부 SaaS 기반 LLM 제공자의 퍼블릭 엔드포인트로 암호화 검증 없이 전송됩니다.
• 데이터 보존 정책(Retention Policy) 미확인: 사용 중인 API 플랜이 입력된 데이터를 모델 재학습(Fine-tuning/RLHF)에 사용하는지, 일정 기간 캐시 형태로 제3자 서버에 저장하는지 확인하지 않습니다.
• 비가역적 유출: 한번 외부 클라우드로 전송된 데이터는 데이터 삭제 권리를 온전히 행사하기 어렵고, 전송 로그 자체가 관련 법령상 국외 이전이나 제3자 제공 위반에 해당할 수 있습니다.

비용 산정의 실패와 토큰 경제학의 부재

LLM 아키텍처에서 비용은 연산 시간이 아니라 ‘입출력 토큰(Token)’ 단위로 책정됩니다. 그러나 전통적인 소프트웨어 라이선스 체계나 서버 호스팅 비용 개념에 익숙한 이들은 이 메커니즘을 제대로 이해하지 못합니다.

수백만 건의 비정형 로그를 분석하기 위해 수천 토큰 길이의 컨텍스트를 반복해서 호출하면, 호출당 비용은 미미해 보여도 일일 누적 비용은 기하급수적으로 증가합니다. 1회 배치 작업에 수백만 원이 소모되는 파이프라인을 구축해 두고, 이를 주기적인 크론(Cron) 작업으로 걸어두는 사고가 실제로 발생합니다. 출시 속도라는 ‘상대적 중요성’을 좇아 효율성을 명분으로 도입한 자동화 시스템이, 기존 인건비보다 몇 배는 더 큰 클라우드 비용 청구서로 돌아오는 역설적인 상황이 벌어지는 셈입니다.

최악의 시너지: 경영진의 조급함과 마케팅형 엔지니어의 야합

이러한 기형적인 시스템이 결재 라인을 무사히 통과해 프로덕션 레벨까지 일사천리로 배포되는 배경에는 조직 내 정치적 역학 관계가 깊숙이 자리 잡고 있습니다. 기술의 본질보다 ‘단기 속도와 대외 홍보의 상대적 중요성’을 우선시하는 경영진과, 말과 포장만 앞세워 이를 파고드는 마케팅형 엔지니어의 위험한 결합입니다.

                        경영진 (Executive)
   - "시장 선점과 출시 속도의 상대적 중요성이 최우선이다"
   - "복잡한 내부 보안이나 아키텍처 원리는 모르겠고, 화면에 데모를 띄워라"

                                    ▲
                   상대적 중요성의 왜곡된 일치 (정치적 공생)
                                    ▼

                     마케팅형 엔지니어 (Buzzword Engineer)
   - "속도의 상대적 중요성을 내세워 외부 상용 API로 며칠 만에 구현 완료"
   - 데이터 유출, 토큰 비용, 런타임 장애 위험은 고의로 은폐 및 축소

                                    │
                               배제 및 고립
                                    ▼

                    진짜 기술 엔지니어 (Real Engineer)
   - "보안과 비용 통제는 타협할 수 없는 절대적 가치다"
   - 사내 격리형 sLLM 및 전처리 규칙 엔진 제안 → "진행 방해자"로 낙인

전시 행정에 목마른 경영진의 오판

경영진의 주된 관심사는 디지털 전환(DX)을 넘어선 인공지능 전환(AX)의 성과를 시장과 주주에게 증명하는 것입니다. 그들에게 기술은 인프라의 안정성을 지탱하는 근간이라기보다 대외 홍보용 트로피에 가깝습니다.

• 가시성의 상대적 우위: 밑바닥 데이터 파이프라인 정비나 보안 거버넌스 수립처럼 눈에 보이지 않는 기본 작업에는 예산과 시간을 쓰기 싫어합니다. 당장 눈에 보이는 가시성이 훨씬 높은 상대적 중요성을 갖는다고 판단하기 때문입니다.
• 리스크의 사후 전가: “업계 1위 대기업 API를 쓰는데 뭐가 문제냐”, “사고 터지면 그때 가서 대처해라” 식의 안일함으로 엔지니어링 검증 과정을 건너뜁니다. DPA(Data Processing Agreement) 상의 데이터 처리 조항조차 읽지 않은 채 배포를 승인합니다.
• 단기 지표 중심: 초기 파일럿 단계에서 몇만 원 청구된 영수증만 보고 “비용 효율적인 혁신”이라 자화자찬하며 전사 확대를 지시합니다. 장기적 TCO(총소유비용)보다 당장의 성과 지표를 더 우위에 두는 편향입니다.

얕은 지식을 화려한 언어로 포장하는 마케팅형 엔지니어

경영진의 이러한 욕망을 정확히 파고드는 존재가 바로 마케팅형 엔지니어입니다. 이들은 복잡한 수학적 원리, 네트워크 패킷의 흐름, 리눅스 커널의 동작, 데이터베이스 락(Lock) 경합 같은 진짜 엔지니어링의 세계를 기피합니다. 대신 최신 트렌드 키워드와 프롬프트 테크닉 몇 가지를 익혀 “지금은 완벽함보다 속도의 상대적 중요성이 훨씬 중요한 시대”라는 논리로 경영진의 귀를 사로잡습니다.

• 도구 맹신과 책임 외주화: 정규표현식(Regex)이나 기존 형태소 분석기로 충분히 걸러낼 수 있는 단순 패턴 매칭 영역까지 무조건 고비용 상용 모델 API를 호출합니다. 복잡한 시스템을 직접 설계하고 튜닝할 역량이 없기 때문에 모델의 연산력에 모든 책임을 떠넘깁니다.
• 위험의 의도적 축소: 데이터가 외부로 나갈 때 발생하는 컴플라이언스 위반 가능성이나 비선형적으로 폭증할 토큰 비용을 알면서도 경영진 앞에서는 절대 언급하지 않습니다. 속도를 늦추는 위험 요소는 ‘지금 단계에서는 상대적 중요성이 낮은 사소한 문제’로 치부하며 자신의 입지를 다집니다.
• 포트폴리오 중심의 개발: 자신이 구축한 시스템이 훗날 어떤 운영 재앙을 불러올지에는 관심이 없습니다. “최신 대형 언어 모델 기반 사내 개인정보 자동 탐지 시스템 구축 완료”라는 이력서 한 줄을 챙겨 더 좋은 조건으로 이직하면 그만이라는 태도를 취합니다.

말 없는 진짜 엔지니어들이 발붙일 자리를 잃는 현실

이 둘의 결합이 완성되는 순간, 조직 내에서 시스템의 안정성과 보안을 묵묵히 고민하는 진짜 엔지니어들의 입지는 급격히 좁아집니다.

1. “혁신을 가로막는 걸림돌”이라는 낙인: 데이터 파이프라인의 보안 결함을 지적하고, 외부 API 전송 시 발생할 법적 과징금 리스크를 경고하며, 토큰 비용 폭탄을 수학적으로 증명하는 진짜 엔지니어는 ‘상대적 중요성의 균형을 모르는 보수적인 꼰대’ 혹은 ‘혁신의 발목을 잡는 훼방꾼’으로 몰립니다.
2. 소외되는 엔지니어링의 본질: 온프레미스 인프라를 구축하고, 오픈소스 모델을 파인튜닝하며, 정밀한 규칙 기반 전처리 엔진을 짜는 작업은 시간이 걸리고 공수가 많이 듭니다. 반면 마케팅형 엔지니어는 파이썬 코드 몇 줄로 외부 API를 호출해 단 사흘 만에 데모를 완성합니다. 속도와 가시성만을 따지는 조직 문화 속에서 진짜 기술을 갈고닦는 엔지니어의 노력은 무가치한 것으로 치부됩니다.
3. 결국 터지는 뒤처리 전담반: 화려한 스포트라이트는 마케팅형 엔지니어가 독식하고 승진까지 챙기지만, 몇 달 뒤 청구된 수천만 원의 토큰 청구서와 데이터 유출 감사 리포트라는 쓰레기를 치우는 일은 결국 구석으로 밀려나 있던 진짜 엔지니어들의 몫으로 돌아옵니다.

사실 제가 지금 이 늪에 빠져있다는 생각이 들어 이 글을 쓰게 된 것도 같습니다. 개인적인 이야기를 덧붙이자면, 처음에는 마케팅형 엔지니어들의 빠른 실행력과 포장 능력에서도 배울 점이 많다고 생각했었습니다. 기술에만 매몰되지 않고 비즈니스 관점에서 속도의 상대적 중요성을 고려하는 태도 자체는 필요하니까요. 하지만 1~2년이 지나고 나니 깨닫게 되었습니다. 기술적 기초가 없는 상태에서 그들이 조직의 권력을 잡기 시작하면, 결국 회사의 시스템과 아키텍처는 걷잡을 수 없이 무너져 내린다는 사실을요.

1회 분석에 300만 원? 현장에서 드러난 수치와 모순

실제 대용량 로그 검사 프로젝트에서 발생했던 아키텍처 실패 사례를 구체적인 수치로 짚어볼 필요가 있습니다. 특정 엔터프라이즈 환경에서 비정형 데이터 약 5,000만 줄을 대상으로 개인정보 및 내부 정보 식별 작업을 기획했던 사례입니다.

설계되지 않은 아키텍처의 파탄

단순히 최신 상용 대형 모델을 활용해 스크립트를 작성한 팀의 계산서는 참담했습니다.

[비정상 파이프라인 구성]
원시 로그 데이터 (100GB) 
  → 스크립트 분할 (Chunking) 
  → 외부 최상위 상용 LLM API 전송 (프롬프트당 4,000 토큰)
  → 결과 수신 및 DB 적재

• 입력 데이터 규모: 약 5,000만 줄 (단순 텍스트 환산 시 수억 토큰)
• 호출 구조: 원시 텍스트 그대로 고성능 다국어 지원 LLM 호출
• 1회 전체 검사 견적: 약 300만 원 ~ 450만 원 발생
• 주기 설정 계획: 매일 자정 배치 작업 실행 (기획안 기준)

매일 자정마다 수백만 원이 청구되는 파이프라인이 정상적으로 돌아갈 리 만무합니다. 한 달이면 단순 로그 검사 작업에만 1억 원 가까운 인프라 비용이 소모되는 구조였습니다. 이는 해당 작업을 위해 정규 보안 분석가 여러 명을 채용해 정밀 수동 감사를 진행하는 인건비보다 훨씬 비싼 수준이었습니다. 속도의 상대적 중요성을 핑계로 설계를 생략한 대가는 막대한 재정적 낭비로 돌아왔습니다.

데이터 컴플라이언스 위반의 실체

비용 문제보다 더 치명적이었던 것은 법률적 리스크였습니다. 해당 파이프라인을 통과한 로그 데이터에는 다음과 같은 정보들이 포함되어 있었습니다.

1. 고객 계좌번호 및 주민등록번호 뒤 7자리 등 고유식별정보
2. 시스템 접근용 API 시크릿 키 및 평문 비밀번호
3. 내부 인사 평가 및 신규 비즈니스 전략 문서

이 데이터들이 사외 퍼블릭 클라우드 인프라로 여과 없이 전송되었습니다. 개인정보보호법에 규정된 기술적·관리적 보호조치 기준 위반은 물론, 정보통신망법상 정보 유출 사고로 간주되어 수억 원 대의 과징금과 대외 신뢰도 추락으로 이어질 수 있는 명백한 보안 사고였습니다. 나중에 부랴부랴 공급사와 개인정보 처리 협약을 맺고 NDA(비밀유지계약)를 체결하긴 했습니다. 개발을 주도한 측에서는 “AI 성능이 좋아서 개인정보를 아주 잘 찾아낸다”고 자평하고 있었지만, 시스템 관점에서는 개인정보를 사외로 대량 유출하는 통로를 직접 구축한 것이나 다름없었습니다.

솔직히 현업에서 계약서와 NDA 하나만 믿고 무작정 데이터를 전송하는 행태를 볼 때마다 깊은 의문이 듭니다. 그 계약서가 클라우드 제공자의 내부 로깅과 잠재적 유출 사고까지 기술적으로 완벽하게 차단해 줄 수 있을까요? 보안 엔지니어의 눈에는 종이 위의 계약 문구보다 네트워크 경계선과 패킷의 물리적 흐름이 훨씬 더 본질적인 통제 수단으로 보일 수밖에 없습니다.

지속 가능한 AI 보안 파이프라인 아키텍처

그렇다면 대규모 비정형 데이터 분석이라는 비즈니스 요구사항을 충족하면서도 비용과 보안 문제를 동시에 해결하는 아키텍처는 어떻게 구성해야 할까요? 해답은 ‘속도의 상대적 중요성’과 ‘보안의 절대적 가치’가 균형을 이루는 하이브리드 필터링과 온프레미스 인프라의 결합에 있습니다.

[최적화된 보안 파이프라인 아키텍처]

[ 원시 데이터 (Raw Data) ]
           │
           ▼
[ Layer 1: 규칙 기반 전처리 엔진 ]
  - Regex 기반 정형 개인정보(고유식별정보, 카드번호) 마스킹
  - 기계적 엔트로피 분석을 통한 시크릿 키(Key) 1차 필터링
           │ (트래픽의 85% 필터링 및 토큰 절감)
           ▼
[ Layer 2: 사내 격리형 sLLM (On-Premises / VPC) ]
  - 8B 이하 경량 오픈소스 모델 적용
  - 비정형 민감 문맥(Context) 탐지 및 난독화 처리
           │
           ▼ (사외 반출 승인된 데이터만 격리 선별)
[ Layer 3: 고성능 상용 LLM (선택적 호출) ]
  - 최고 난이도의 복합적 법률 검토 및 최종 리포팅

1단계: 정규식과 사전 기반의 기계적 전처리

모든 문제를 지능형 모델로 해결하려는 시도를 버려야 합니다. 주민등록번호, 외국인등록번호, 신용카드 번호, 이메일 주소, 알려진 형태의 전화번호는 정규표현식(Regex)과 결정론적 알고리즘으로 99% 이상 검출이 가능합니다. 이 기본적인 패턴조차 정규식으로 걸러내지 못하면서 LLM을 도입하겠다는 것은 앞뒤가 맞지 않는 이야기입니다.

• 정규식 필터링 엔진을 파이프라인 최전선에 배치하여 명확한 정형 개인정보를 즉시 마스킹 처리합니다.
• 엔트로피 분석 알고리즘을 통해 소스코드 내 하드코딩된 API 토큰이나 비밀번호를 1차 선별합니다.
• 이 단계만 거쳐도 상위 모델로 유입되는 데이터 양을 80% 이상 줄일 수 있으며, 토큰 비용 역시 정비례하여 절감됩니다.

2단계: 프라이빗 환경 내 경량 오픈소스 모델(sLLM) 활용

문맥을 파악해야만 식별할 수 있는 비정형 개인정보(예: 대화 문맥 속에서 드러나는 개인 신상, 내부 프로젝트 암호명 등)는 외부 상용 API가 아닌 격리된 인프라에서 처리해야 합니다.

최신 오픈소스 모델 생태계에는 7B~8B 수준의 파라미터만으로도 특정 도메인 작업에서 뛰어난 성능을 발휘하는 모델들이 다수 존재합니다. 이 모델들을 사내 온프레미스 GPU 서버나 퍼블릭 클라우드의 격리된 VPC(Virtual Private Cloud) 환경에 배포합니다.

• 네트워크 완전 격리: 데이터가 외부 공용망을 경유하지 않으므로 데이터 주권과 컴플라이언스 요건을 완벽하게 충족합니다.
• 고정 인프라 비용: 토큰 호출당 과금 방식이 아닌 고정 서버 비용 체계로 전환되므로, 하루에 수억 건의 로그를 분석하더라도 추가 비용이 발생하지 않습니다.
• 도메인 특화 경량화: 사내 보안 규정집과 과거 보안 사고 패턴을 데이터셋으로 구축하여 LoRA 등의 기법으로 미세 조정(Fine-tuning)하면 상용 대형 모델 못지않은 정확도를 확보할 수 있습니다.

사실 이러한 경량화 모델을 발굴하고 튜닝하여 사내 인프라에 녹여낼 때야말로 진짜 엔지니어의 내공이 빛을 발합니다. 하지만 초기 단계에서 화려하게 반짝이는 상용 API 데모를 마케팅형 엔지니어들이 이미 선점해 버린 조직에서는, 이러한 근본적인 아키텍처를 설득하고 도입하기가 결코 쉽지 않은 것이 현실입니다.

3단계: 문맥 기반 데이터 익명화 및 제3자 전송 통제

불가피하게 최상위 상용 LLM의 분석 능력이 필요한 고난도 케이스(예: 복합적인 법률 컴플라이언스 해석, 다국어 교차 분석)에 한해서만 데이터를 선별적으로 외부로 보냅니다.

이 경우에도 원본 텍스트를 그대로 전송해서는 안 됩니다. 1단계와 2단계에서 완벽하게 난독화 및 가명 처리가 완료된 데이터만을 API 페이로드에 적재해야 합니다. 이때 기업 전용 계약(Enterprise Tier)을 통해 입력 데이터가 상대방의 모델 학습에 활용되지 않음을 보증받는 기술적·계약적 잠금장치가 반드시 수반되어야 합니다.

엔지니어링의 본질: 도구의 맹신을 넘어선 통제력

AI 도구가 고도화될수록 엔지니어에게 요구되는 진짜 역량은 코드를 빠르게 작성하거나 프롬프트를 화려하게 꾸미는 기술이 아닙니다. 시스템의 전체 라이프사이클을 조망하고, 각 구성 요소가 시스템 전체의 비용과 보안, 안정성에 미치는 영향을 통제하는 능력입니다.

상황에 따른 속도의 상대적 중요성도 물론 비즈니스에서 무시할 수 없는 요소입니다. 하지만 그 상대적 중요성이 시스템의 근간을 이루는 보안과 컴플라이언스라는 절대적 가치를 훼손하는 명분으로 악용되어서는 안 됩니다. 마케팅형 엔지니어들의 화려한 언변과 경영진의 조급함이 빚어낸 거품은 그리 오래가지 못합니다. 프로덕션 환경의 냉혹한 트래픽과 청구서, 그리고 감사의 칼날 앞에서는 오직 검증된 아키텍처와 제대로 작동하는 시스템만이 살아남기 때문입니다.

비즈니스의 속도 요구를 수용하면서도 데이터 자산을 안전하게 지켜내고, 한정된 인프라 예산 내에서 최적의 아키텍처를 설계해 내는 엔지니어들이 더 이상 조직의 구석으로 밀려나지 않아야 합니다. 도구 뒤에 숨어 생각하기를 멈추는 순간, 기술은 혁신이 아니라 감당할 수 없는 부채로 돌아옵니다. 다음 글에서는 이와 같은 무지와 오남용이 사내 개발 문화와 코드 저장소로 번져나갈 때 어떤 재앙이 벌어지는지 구체적인 코드 레벨의 사례로 이야기를 이어가 보겠습니다.