모델 투명성
Model Transparency
개념
AI 가 관여했다는 사실과 그 답이 무엇에 근거했는지를 사용자에게 드러내 두는 제품 설계 원칙입니다.
등장 배경
제품에 AI 기능을 처음 붙이던 무렵에는 결과만 잘 나오면 된다고 여겼습니다. 사용자는 요약문이 잘 쓰였는지만 보지 누가 썼는지는 궁금해하지 않을 것 같았고, 기계가 만들었다고 굳이 적으면 오히려 덜 믿을 것 같았습니다. 그래서 자동 생성된 문장이 사람이 쓴 문장과 똑같은 모양으로 화면에 놓였습니다.
페이지덱에서 회의록 자동 요약을 내보낸 뒤 첫 사고가 그렇게 왔습니다. 한 고객사가 요약문에 적힌 일정을 그대로 믿고 협력사에 공유했는데, 회의에서는 그런 날짜가 나온 적이 없었습니다. 고객이 어디서 나온 문장이냐고 물었을 때 수아도 지현도 답하지 못했습니다. 그 화면에는 그 문장이 자동으로 만들어졌다는 표시도, 원본 회의록의 어느 대목에서 나왔는지도 없었습니다. 결국 사람이 40분짜리 녹취를 다시 들어 그런 대목이 없다는 것만 확인했습니다.
모델 투명성은 이 사고를 제품 쪽에서 막으려고 세운 원칙입니다. 결과의 품질을 높이는 문제와 결과를 의심할 수 있게 만드는 문제를 따로 놓고 본 것이 출발점입니다. 기계는 틀릴 수 있으니, 틀렸을 때 읽는 사람이 알아챌 수 있는 재료를 화면에 같이 얹어 두자는 쪽으로 정리됐습니다.
작동 방식
세 가지를 드러내는 것으로 이뤄집니다. 관여했다는 사실, 답의 근거, 그리고 무엇을 어떻게 썼는지의 기록입니다.
- 관여 표시입니다. 이 문장이 사람이 아니라 AI 가 만들었다는 것을 결과 옆에 적습니다. 요약문 머리에 자동으로 생성된 초안이라고 붙이고, 검토 없이 그대로 쓰지 말라는 한 줄을 같이 둡니다. 작아 보이지만 이 표시 하나가 읽는 태도를 바꿉니다.
- 근거 제시입니다. 요약문의 문장마다 원본 회의록의 어느 대목에서 나왔는지를 짚어 줍니다. 페이지덱은 문장을 누르면 녹취의 해당 구간으로 이동하게 만들었습니다. 근거로 이어지지 않는 문장은 표시가 붙지 않으므로, 앞의 일정 사고 같은 문장은 눌러도 갈 곳이 없어 그 자리에서 드러납니다.
- 기록입니다. 어떤 모델에 무슨 입력이 들어가 무슨 결과가 나갔는지를 남깁니다. 사고가 난 뒤에 재현하려면 이 기록이 있어야 하고, 규제 대응이 요구하는 것도 대개 이것입니다.
이 셋이 필요한 이유는 환각 때문입니다. 환각은 모델이 사실이 아닌 내용을 그럴듯한 문장으로 내놓는 현상인데, 틀린 답과 맞는 답이 똑같이 자신 있는 어조로 나옵니다. 사람이 쓴 글이라면 어물거리는 문장, 근거 없는 단정 같은 단서가 남지만 모델의 출력에는 그런 단서가 없습니다. 읽는 사람이 어디를 의심해야 할지 스스로 알 수 없으니 제품이 대신 짚어 주는 것입니다.
수위는 기능마다 다르게 잡습니다. 초안 작성처럼 사람이 어차피 고쳐 쓰는 자리는 관여 표시만으로 충분하고, 고객 문의에 자동으로 답하는 자리는 근거까지 붙입니다. 어느 수위로 갈지는 결과가 틀렸을 때 사용자가 무엇을 잃는지를 보고 정합니다.
쓰이는 곳
세 자리에서 실제로 요구받습니다. 법, 고객사의 구매 심사, 그리고 우리 팀의 사고 수습입니다.
법에서 먼저 옵니다. AI 규제법은 AI 를 쓰는 방식마다 위험 수준을 매기고 수준에 따라 다른 의무를 지우는 법제인데, 가장 가벼운 층의 의무가 바로 이 표시입니다. 요약이나 초안 작성처럼 결과가 가벼운 자리에서는 AI 가 만들었다는 사실만 밝히면 됩니다. 채용 서류를 거르거나 대출 여부를 정하는 자리로 올라가면 표시에 더해 어떤 자료로 만들었는지와 판단 기록까지 요구받습니다.
고객사의 구매 심사에서도 걸립니다. 기업 고객은 계약 전에 보안과 개인정보 문항이 든 질문지를 보내는데, 최근에는 AI 기능에 대한 문항이 거기 붙습니다. 어느 모델을 쓰는지, 생성된 결과에 표시가 붙는지, 고객 문서가 모델 학습에 쓰이는지 같은 것입니다. 마지막 항목은 학습 데이터 권리가 다루는 문제로, 학습에 쓴 자료의 저작권과 이용 범위를 가리킵니다. 답을 못 적으면 계약이 그 자리에서 멈춥니다.
마지막은 사고가 났을 때입니다. 앞의 일정 사고에서 근거 표시가 있었다면 고객이 문장을 눌러 갈 곳이 없다는 것을 보고 5분 만에 끝났을 일이었습니다. 사람 개입과 짝으로 쓰이는 것도 이 때문입니다. 사람 개입은 결과가 무거운 판단에 사람이 확인하고 누르는 단계를 남겨 두는 설계인데, 확인할 사람에게 근거가 보이지 않으면 그 단계는 그냥 승인 버튼을 누르는 절차로 굳습니다.
실무 용례
"이 요약문에 자동 생성 표시 붙었나요? 안 붙었으면 출시 못 합니다."
규제와 사내 기준에서 요구하는 최소 표시가 빠졌다는 지적입니다.
"고객사 질문지에 모델 관련 문항이 새로 들어왔어요. 우리 답변 문서 업데이트해야 합니다."
계약 심사 자료로 쓰이니 제품의 실제 동작과 맞춰 두자는 말입니다.
"출처 링크까지는 이번 분기에 어렵고, 일단 표시부터 답시다."
수위를 낮춰 단계적으로 가자는 제안입니다.
페이지덱에서는 AI 기능을 새로 만들 때 규원이 한 장짜리 점검표를 요구합니다. 무슨 모델을 쓰는지, 사용자에게 무엇을 표시하는지, 결과가 틀렸을 때 사용자가 무엇을 잃는지, 기록을 얼마나 보관하는지 네 줄입니다. 기능을 다 만든 뒤가 아니라 설계 단계에서 씁니다. 나중에 붙이려면 이미 돌아가는 화면을 뜯어야 하고, 그때는 표시 하나 넣는 일이 분기 일정으로 커집니다.
흔한 오해
모델 내부를 공개하라는 요구로 읽는 경우가 많습니다. 투명이라는 말이 안이 비쳐 보이는 상태를 가리키니 자연스러운 연결입니다. 하지만 이 원칙이 요구하는 것은 알고리즘이나 학습에 쓴 가중치를 내놓는 일이 아니라, 사용자가 결과를 판단하는 데 필요한 정보를 주는 일입니다. 실제로 요구받는 것은 대개 셋뿐입니다. AI 가 관여했는가, 무엇에 근거했는가, 어디까지 믿으면 되는가. 공개 범위를 크게 잡아 두면 회사는 영업 비밀 때문에 못 한다는 결론으로 가고, 정작 붙일 수 있었던 표시까지 안 붙게 됩니다.
표시만 붙이면 끝났다고 읽는 것도 흔합니다. 화면 아래에 회색 작은 글씨로 AI 가 생성했다고 적어 두는 쪽입니다. 그 한 줄은 책임을 사용자에게 넘길 뿐 무엇을 의심해야 할지는 알려 주지 않습니다. 앞의 일정 사고에서 그 표시가 있었더라도 고객은 똑같이 잘못된 날짜를 공유했을 것입니다. 표시는 시작이고, 판단을 바꾸는 것은 문장 하나하나가 어디서 왔는지 보여 주는 쪽입니다.
같이 보면 좋은 페이지
마지막 업데이트 2026-09-16