[태그:] 데이터 리니지

영업 담당자가 AI 에이전트에게 특정 고객의 가격을 물어봅니다. 에이전트는 접근이 제한된 가격 시스템, 사내 대화 기록, 보관해 둔 예전 견적서를 뒤져서 답을 만들어요. 에이전트 입장에선 정확해 보이는 결과죠. 그래서 두 번째 에이전트가 이걸 그대로 받아 제안서 초안을 씁니다. 두 번 넘어가는 동안 사람은 한 번도 확인하지 않았고요. 나중에야 제안서에 승인되지 않은 기밀 정보가 섞여 있었다는 게 드러납니다. 그런데 그 데이터가 어디서 끼어들었는지, 어떤 시스템과 파일과 에이전트를 거쳐 퍼졌는지는 아무도 되짚지 못해요. 사고는 났는데 경로가 없는 상황.

MIT 테크놀로지 리뷰의 커스텀 콘텐츠 조직 인사이츠가 에이전트 보안 리포트를 소개하면서 꺼낸 시나리오예요. 편집국이 쓴 기사가 아니라 커스텀 콘텐츠라는 점은 감안하고 읽는 게 맞습니다. 그 점을 빼고 봐도 이 장면이 던지는 질문은 꽤 구체적이에요. 에이전트가 일하는 회사에서 사고가 터졌을 때, 원인을 찾으려면 무엇을 미리 기록해 뒀어야 하느냐. 그 답으로 나오는 개념이 데이터 리니지, 우리말로 데이터 계보입니다.

리니지는 데이터에 붙는 택배 송장

데이터 리니지는 데이터 한 덩어리가 처음 생긴 곳에서 지금 있는 곳까지 거쳐 온 경로를 적어 둔 기록이에요. 택배 송장 추적을 떠올리면 편합니다. 출발지, 거쳐 간 물류 센터, 현재 위치가 순서대로 찍히잖아요. 리니지는 그런 이력을 데이터에 붙이는 일이고요. 어느 시스템에서 읽혔는지, 누가 혹은 무엇이 가공했는지, 가공한 뒤 어디로 넘어갔는지. 이게 중간에 끊기지 않고 이어져 있어야 해요. 한 칸이 비면 그 뒤로는 추적이 안 되니까요.

원래 이 개념은 데이터 분석 쪽에서 많이 쓰던 말이에요. 보고서 숫자가 이상하게 나오면 어느 테이블, 어느 집계 단계에서 틀어졌는지 거슬러 올라가야 하잖아요. 그렇게 분석가들이 쓰던 개념이, 에이전트가 업무에 들어오면서 보안 쪽 질문으로 넘어오는 중입니다.

인사이츠는 이 변화를 한 문장으로 정리해요. AI 보안은 도구의 문제가 아니라 데이터 가시성의 문제라는 것. 에이전트를 일상 업무에 쓰는 기업이 관리해야 할 대상은 가만히 놓여 있는 파일이 아니라고 봅니다. 끊임없이 수집되고, 복사되고, 요약되고, 변형되고, 재사용되고, 새로운 형태로 다시 배포되는 데이터가 관리 대상이라는 거죠. 파일 하나 잠가 둔다고 끝나지 않는 이유가 여기 있어요. 그 파일 내용이 요약본이 되어 다른 문서에 들어가 버리면, 잠금은 그 경로까지 따라가지 못하니까요.

견적 시나리오에서 추적이 끊긴 세 지점

앞의 시나리오를 단계별로 쪼개 보면 사고 자체보다 추적이 끊긴 자리가 먼저 눈에 들어와요.

• 첫 번째 에이전트가 출처를 섞는 순간: 제한된 가격 시스템, 사내 대화, 보관 견적이 답 하나로 합쳐져요. 각 조각이 어디서 왔고 어떤 등급이었는지, 그 꼬리표가 이 단계에서 답 안으로 녹아 사라집니다.
• 에이전트에서 에이전트로 넘어가는 순간: 두 번째 에이전트 손에 들어오는 건 결과물뿐이에요. 이 숫자가 승인되지 않은 사내 대화에서 나왔다는 정보는 따라오지 않습니다. 사람의 확인도 여기엔 없었고요.
• 제안서가 파일이 되어 퍼지는 순간: 초안이 문서로 저장되고 공유되면서 문제의 데이터는 또 다른 시스템, 또 다른 파일로 번져요. 여기까지 오면 원래 출처를 거꾸로 찾아가기가 훨씬 어려워집니다.

여기서 눈여겨볼 대목. 단계 하나하나만 떼어 보면 전부 정상 동작처럼 보였다는 점이에요. 첫 번째 에이전트에겐 결과가 정확해 보였고, 두 번째 에이전트는 받은 데이터로 맡은 일을 했을 뿐이죠. 에이전트가 원래 그 시스템을 읽을 수 있는 상태였다면, 접근 기록만 들여다봐서는 이상 징후가 드러나지 않았을 가능성이 커 보입니다. 결국 문제는 개별 행동이 아니라 행동과 행동 사이의 연결에 있었던 셈이에요. 시스템마다 기록을 꼼꼼히 남겨도, 그 기록들을 잇는 끈이 없으면 사고 경로는 보이지 않는다는 얘기고요.

네트워크·엔드포인트 보안이 놓치는 자리

지금까지 보안은 주로 애플리케이션, 시스템, 네트워크, 엔드포인트 단위로 설계돼 왔어요. 어느 서버에 누가 들어왔는지, 어떤 PC에서 파일이 밖으로 나갔는지 감시하는 식이죠. 인사이츠는 이것만으로 짠 보안 체계로는 에이전트를 대규모로 쓰는 환경을 지키기에 더 이상 충분하지 않다고 봅니다. 시나리오를 다시 떠올려 보면 수긍이 가요. 그 에이전트는 외부 침입자가 아니라 사내 업무 도구였습니다. 데이터를 읽은 것도, 문서를 쓴 것도 전부 회사 안에서 벌어진 일. 경계를 넘어오는 침입을 잡도록 만든 감시라면 포착할 장면 자체가 마땅치 않았을 거로 봐요.

구분	기존 보안 관점	데이터 리니지 관점
지키는 단위	애플리케이션·시스템·네트워크·엔드포인트	데이터가 움직이는 경로
데이터를 보는 방식	저장돼 있는 정적 파일	수집·복사·요약·변형·재사용·재배포되는 흐름
사고 후 첫 질문	어디가 뚫렸나	문제 데이터가 어디서 들어와 어디로 퍼졌나
에이전트 간 전달	시스템별 기록에 흩어져 있음	전달마다 출처와 함께 이어서 기록
적용 범위	개별 시스템	사람·에이전트·혼합 업무 흐름 전체

표의 오른쪽이 왼쪽을 갈아치운다는 얘기로 읽으면 곤란해요. 인사이츠가 문제 삼는 것도 기존 방식’만으로’ 짠 보안이거든요. 네트워크와 엔드포인트 보안은 여전히 필요합니다. 리니지는 그 위에 층을 하나 더 얹는 개념에 가까워요. 데이터 자체가 어디를 지나갔는지 보여 주는 층이요. 기존 보안을 걷어내고 리니지로 갈아타자는 결론은 이 논리에서 나오지 않는다는 점, 같이 기억해 두면 좋겠습니다.

출처부터 사람 검토까지, 리니지 기록의 다섯 칸

시나리오에서 추적이 막힌 지점을 거꾸로 따라가 보면, 적어도 아래 정보는 데이터에 붙어 다녀야 원인을 되짚을 수 있어 보여요. 도구마다 항목 이름은 제각각일 수 있습니다. 이름에 매달리기보다 이 질문들에 답할 수 있느냐를 기준으로 보세요.

1. 출처: 어느 시스템, 어느 파일, 어느 대화에서 읽었는지. 시나리오로 치면 가격 시스템인지, 사내 대화인지, 보관 견적인지가 구분돼 있어야 해요.
2. 민감도와 승인 상태: 그 조각이 제한 등급인지, 공식 승인된 값인지. 승인되지 않은 정보가 섞여 들어간 게 이번 사고의 핵심이었으니 빠질 수 없는 칸입니다.
3. 변형 이력: 그대로 복사했는지, 요약했는지, 다른 데이터와 합쳤는지. 요약을 거치면 겉모습이 원본과 달라져요. 연결 고리를 남겨 두지 않으면 같은 정보라는 걸 알아보기도 어렵습니다.
4. 전달 경로: 어느 에이전트, 어느 사람, 어느 파일로 넘어갔는지. 그중에서도 에이전트에서 에이전트로 넘어가는 지점이 특히 중요해요.
5. 사람 검토 여부: 전달 과정에서 사람이 확인했는지, 했다면 누가 했는지. 책임 소재를 가리려면 이 칸만큼은 비어 있으면 안 됩니다.

다섯 칸 중 하나만 고르라면 민감도 꼬리표예요. 이 꼬리표는 데이터와 함께 움직여야 하거든요. 제한 등급 데이터를 요약한 문장은 요약된 뒤에도 제한 등급이어야 합니다. 그런데 꼬리표가 원본 파일에만 붙어 있으면 요약하는 순간 떨어져 나가요. 인사이츠가 리니지의 목적으로 거버넌스, 책임성, 신뢰를 한데 묶어 꼽는 것도 같은 맥락으로 읽힙니다. 어디서 왔는지 모르는 데이터는 누가 책임질지 정할 수 없고, 그런 데이터로 만든 결과물은 믿을 근거가 없으니까요.

그룹웨어·메신저에 에이전트를 붙이면 바뀌는 일

이 리포트는 특정 제품이나 규제를 다루지 않아요. 그러니 국내에서 당장 바뀌는 제도가 있는 건 아닙니다. 다만 국내 기업도 그룹웨어, 사내 메신저, 영업·견적 시스템에 AI 에이전트를 붙이는 쪽으로 간다면 같은 구조의 문제를 만나게 될 거라고 봐요. 어디까지나 추측이긴 한데, 시나리오 속 재료가 가격 시스템·사내 대화·보관 견적이었다는 걸 생각하면 낯선 그림은 아니죠. 실무에서 달라질 만한 지점을 꼽아 보면 이렇습니다.

• 보안 점검 질문이 늘어난다: ‘누가 이 시스템에 접근했나’에 더해 ‘이 결과물의 이 문장은 어디서 왔나’를 물어야 해요. 내부 감사 자료도 접근 기록 중심에서 데이터 흐름 중심으로 넓어질 가능성이 있습니다. 이 부분은 추측이에요.
• 도입 검토 체크리스트가 길어진다: 에이전트 도구를 고를 때 공급사에 확인해 둘 게 생겨요. 결과물과 함께 참조한 출처를 남기는지, 에이전트끼리 주고받은 내용을 기록으로 내보낼 수 있는지, 원본의 접근 등급이 결과물에도 이어지는지.
• 현업 부서의 역할이 커진다: 어떤 가격이 승인된 값인지, 어떤 대화가 내부용인지는 보안팀보다 영업·기획 부서가 더 잘 알아요. 민감도 분류에 현업이 같이 들어와야 리니지 기록이 실제로 쓸모를 가집니다. 보안팀 혼자 등급을 매기면 칸은 채워져도 내용이 틀릴 수 있으니까요.

개인 직장인이라면 이것 하나는 의식해 두면 좋겠어요. 업무용 AI에 넣은 사내 자료가 요약·재가공돼서 다른 사람의 결과물에 들어갈 수 있다는 점. 퍼지는 건 내가 올린 파일이 아니라 그 파일의 요약일 수도 있거든요. 원본 파일의 공유 설정만 확인하고 안심하기엔 부족할 수 있습니다.

확인된 것과 아직 불확실한 것

확인된 것

• 리포트 제작 주체는 편집국이 아닌 커스텀 콘텐츠 조직 인사이츠
• 견적 시나리오는 개념 설명을 위한 예시로 제시됨
• AI 보안을 도구가 아닌 데이터 가시성의 문제로 규정
• 애플리케이션·시스템·네트워크·엔드포인트만을 중심으로 한 기존 보안은 에이전트 환경에 충분하지 않다는 주장
• 사람·에이전트·혼합 업무 흐름 전반의 거버넌스·책임성·신뢰를 위해 데이터 리니지 확립이 필요하다는 결론

아직 불확실한 것

• 리포트 전문에 담긴 구체적 권고안과 조사 데이터
• 에이전트 간 전달 기록에 대한 업계 공통 표준의 존재 여부
• 요약·변형된 데이터에 민감도 꼬리표를 자동으로 이어 붙이는 기술의 정확도
• 리니지 기록이 늘어날 때 생기는 저장 비용과 성능 부담 규모
• 국내 규제 기관의 에이전트 데이터 흐름 기록 요구 여부

솔루션 없이 화이트보드로 그리는 데이터 흐름 지도

리니지 솔루션을 들이기 전에도 할 수 있는 일이 꽤 많아요. 화이트보드 하나면 시작할 수 있습니다.

1. 에이전트가 읽을 수 있는 소스를 전부 적는다: 데이터베이스, 공유 드라이브, 메신저, 메일함, 보관 문서까지 빠짐없이요. 시나리오에서 보관해 둔 예전 견적이 출처 중 하나였던 걸 떠올려 보세요. 사람은 잊고 있던 저장소라도 에이전트에게는 똑같은 읽을거리입니다.
2. 소스마다 민감도를 표시한다: 공개, 내부용, 제한 정도로 단순하게 나눠도 괜찮아요. 등급이 아예 없으면 나중에 꼬리표를 이어 붙일 대상부터 없어집니다.
3. 에이전트 사이의 전달 지점을 화살표로 그린다: 에이전트 A의 결과가 B의 입력이 되는 곳마다 표시해요. 시나리오에서 사람이 확인하지 않고 지나간 곳이 바로 이런 전달 지점 두 곳이었습니다.
4. 화살표마다 출처 정보가 같이 넘어가는지 확인한다: 결과 텍스트만 넘어가고 출처 목록은 버려지는 구조라면, 거기가 바로 추적이 끊기는 자리예요.
5. 밖으로 나가는 결과물 앞에 사람 검토를 하나 둔다: 고객에게 가는 제안서처럼 회사 밖으로 나가는 문서는 최소 한 번, 사람이 출처 목록을 옆에 두고 확인하게 만드는 거죠.

물론 모든 화살표에 사람을 세우면 에이전트를 쓰는 의미가 줄어들어요. 현실적인 균형은 이쪽으로 보입니다. 기록은 모든 화살표에 남기고, 사람 검토는 위험이 큰 출구에만 둔다. 기록만 제대로 있으면 사고가 나더라도 문제의 데이터가 어디서 들어와 어디로 번졌는지 되짚을 수 있어요. 처음 시나리오에서 아무도 하지 못했던 바로 그 일. 리니지가 해 주는 일이 그겁니다.

출처: MIT Tech Review AI