기업용 AI에서 출처는 중요한 신뢰 장치입니다. 답변 아래 문서 이름을 붙이는 것만으로도 사용자는 근거가 있다는 인상을 받습니다. 그러나 링크가 존재하는 것과 그 링크가 답을 충분히 뒷받침하는 것은 다른 문제입니다.
업무에서 필요한 것은 문장에 대한 안심만이 아닙니다. 어떤 규정과 이력이 적용됐는지 확인하고, 서로 다른 자료의 충돌을 해석하고, 책임 있는 사람이 다음 행동을 선택해야 합니다. 출처 기반 AI의 품질은 이 전체 흐름을 얼마나 잘 이어주는지로 평가해야 합니다.
출처는 결과가 아니라 인터페이스입니다
좋은 출처 표시는 문서 제목과 링크만 나열하지 않습니다. 답변의 어느 문장이 어느 근거에서 왔는지 연결하고, 사용자가 원문의 앞뒤 문맥을 확인하며, 문서의 날짜와 적용 범위를 판단할 수 있게 해야 합니다. 근거가 부족한 문장은 부족하다고 드러내야 합니다.
Wissly 공식 소개는 답변 근거가 되는 문서를 중앙에 표시하고 발췌 내용을 하이라이트하는 기능, ERP와 그룹웨어 데이터 연동, 연결된 데이터의 변경 사항을 동기화하는 기능을 설명합니다. 출처를 답변 아래 작은 각주가 아니라 탐색의 중심에 두는 제품 방향입니다.
이 인터페이스의 목적은 AI가 맞다고 설득하는 것이 아닙니다. 사용자가 AI를 검토할 수 있게 만드는 것입니다. 특히 계약, 품질, 규제, 행정처럼 오류의 영향이 큰 업무에서는 빠른 답보다 검증 가능한 답이 먼저입니다.
업무로 이어지려면 네 연결이 필요합니다
출처 기반 답변이 실제 업무가 되려면 네 가지 연결이 끊기지 않아야 합니다. 질문은 올바른 데이터 범위에 연결돼야 하고, 답변 문장은 정확한 근거에 연결돼야 하며, 근거는 사용자의 판단 기준에 연결돼야 하고, 판단은 후속 행동과 담당자에게 연결돼야 합니다.
한 연결이라도 빠지면 사용자는 다시 기존 시스템을 찾아가야 합니다. 답은 빨리 받았지만 원문을 처음부터 읽거나, 최신 버전을 다시 찾거나, 누구에게 확인할지 묻는다면 AI가 업무 시간을 다른 위치로 옮겼을 뿐입니다.
질문과 데이터
질문의 업무 맥락에 맞는 시스템, 문서 유형, 권한 범위를 먼저 좁힙니다.
답변과 근거
각 핵심 주장에 실제로 대응하는 원문 구간을 보여주고 근거 없는 요약을 분리합니다.
근거와 판단
날짜, 버전, 적용 대상, 예외 조항을 함께 보여 사용자가 유효성을 검토하게 합니다.
판단과 행동
확인, 수정, 승인, 보고서 작성, 담당자 전달 등 다음 업무로 이어지는 경로를 설계합니다.
공공 행정에서는 범위 자체가 품질입니다
탈린시 실증은 법령 정보 시스템 Teele, 공공 집회 정보 시스템 AKIS, 문서 관리 시스템 Postipoiss를 연동하고 에스토니아어와 영어 질문으로 검색과 출처 확인을 검증하도록 설계됐습니다. 모든 정보를 한 번에 열지 않고 지정된 내부 공무원과 공개 데이터를 대상으로 제한된 환경에서 진행합니다.
공개된 설명에서 출처 우선 방식은 답변의 모든 정보에 원본 문서 직접 링크를 매핑하는 접근으로 정의됩니다. 여기서 중요한 것은 링크의 수가 아니라 행정 정보 오류에 따른 위험을 줄이기 위해 데이터와 사용자를 제한했다는 점입니다.
이 구조는 기업에도 적용할 수 있습니다. 전사 데이터를 한꺼번에 연결하는 대신 한 업무의 승인된 소스와 사용자부터 시작하고, 질문 로그와 실패 원인을 검토한 뒤 범위를 넓히는 편이 안전합니다. 출처가 많아질수록 신뢰가 자동으로 높아지는 것은 아닙니다.
한 문서를 찾는 검색에서 교차 판단으로 갑니다
현업 질문은 한 문서 안에서 끝나지 않는 경우가 많습니다. 이전 프로젝트의 설계와 현재 사양을 비교하거나, 시험 결과와 품질 이슈를 함께 보거나, 규정과 예외 기록을 교차해야 합니다. 이때 출처 기반 시스템은 관련 문서를 찾는 수준을 넘어 서로 다른 근거의 관계를 드러내야 합니다.
테크로스 실증은 설계 이력, 시험 결과, 품질 이슈, 규제 대응 자료를 통합 분석해 제조 업무에 적용할 수 있는지 확인하는 데 초점을 두었습니다. 복합 질의를 하위 과제로 나누고 여러 문서를 교차 분석하는 방식이 공개돼 있습니다.
교차 분석에서는 결론보다 차이를 보여주는 일이 중요합니다. 문서마다 같은 용어가 무엇을 가리키는지, 기준 시점이 다른지, 값이 충돌하는지, 누락된 근거가 있는지를 답변 구조에서 분리해야 사용자가 책임 있게 판단할 수 있습니다.
| 확인 대상 | 좋은 상태 | 위험 신호 |
|---|---|---|
| 범위 | 승인된 데이터와 사용자 경계가 명확함 | 무엇을 검색했는지 설명할 수 없음 |
| 근거 | 핵심 주장과 원문 구간이 직접 연결됨 | 문서 링크는 있으나 답을 지지하지 않음 |
| 충돌 | 버전과 값의 차이를 숨기지 않고 표시함 | 여러 문서 중 하나를 임의로 정답 처리함 |
| 후속 업무 | 확인과 승인에 필요한 다음 경로가 보임 | 사용자가 기존 시스템에서 다시 시작함 |
자동화보다 행동 경계를 먼저 설계합니다
출처를 확인할 수 있다고 해서 AI가 바로 업무를 실행해도 되는 것은 아닙니다. 검색, 초안, 비교처럼 되돌리기 쉬운 행동과 승인, 발송, 시스템 변경처럼 영향이 큰 행동은 다른 통제가 필요합니다. 답변의 신뢰와 행동 권한은 분리해 설계해야 합니다.
호반건설 실증에서 공개된 검증 분야는 계약 조건 검토, 공정 현황 확인, 기술 자료 탐색, 보고서 작성입니다. 이 목록은 모두 같은 자동화 단계가 아닙니다. 탐색과 초안은 AI가 넓게 지원할 수 있지만 계약 해석이나 공정 판단의 최종 책임은 업무 담당자의 확인 절차와 함께 설계해야 합니다.
따라서 각 기능에는 AI가 할 일, 사용자가 확인할 일, 시스템이 기록할 일을 함께 적어야 합니다. 무엇을 자동화할 수 있는지보다 어디에서 사람의 확인을 요청할지를 명확히 하는 것이 운영 가능한 자동화의 출발점입니다.
출처 품질을 묻는 여섯 질문
출처 기반 AI를 검토할 때 기능 목록만으로는 품질을 판단하기 어렵습니다. 실제 데이터와 대표 질문을 놓고 아래 질문에 답할 수 있는지 확인하는 편이 낫습니다. 답을 설명할 수 없다면 아직 운영 조건이 정의되지 않은 것입니다.
무엇을 검색했는가
답변에 사용한 데이터 범위와 제외된 범위를 사용자가 확인할 수 있는가.
왜 이 근거인가
인용 구간이 핵심 주장을 직접 지지하고 문서의 앞뒤 문맥을 확인할 수 있는가.
언제의 정보인가
문서 날짜와 버전, 최신성 기준이 보이고 개정 전 자료와 충돌을 구분하는가.
누가 볼 수 있는가
원본 시스템의 권한과 답변에서 노출되는 범위가 일치하는가.
모르면 어떻게 하는가
근거 부족, 충돌, 범위 밖 질문을 정상 답변처럼 포장하지 않는가.
다음 행동은 무엇인가
사용자가 확인, 수정, 승인, 전달을 이어갈 수 있고 그 과정이 기록되는가.
마치며
출처는 생성형 AI의 불확실성을 완전히 없애는 장치가 아닙니다. 대신 불확실성을 사용자가 보고 판단할 수 있게 만드는 장치입니다. 데이터 범위, 문장별 근거, 충돌, 권한, 행동 경계를 함께 설계해야 출처는 실제 업무의 품질 기준이 됩니다.
StepHow가 지향하는 것은 답변을 많이 만드는 AI가 아닙니다. 조직이 근거를 확인하고, 필요한 사람에게 책임을 연결하며, 다음 업무를 더 안전하게 끝낼 수 있는 제품입니다.