에이전트가 고객에게 보내는 메시지의 문장을 조금 다르게 고르는 일은 대체로 큰 문제가 아니다. 그러나 그 차이가 recipient, path, amount, query 같은 도구 호출 인자로 옮겨가면 이야기가 달라진다. 올바른 도구를 호출했더라도 수신자나 조회 조건이 달라지면, 시스템은 기술적으로는 성공한 잘못된 작업을 수행할 수 있다.
LLM 워터마킹을 적용한 모델을 에이전트의 추론 엔진으로 검토하는 CTO와 개발 리드는 이 지점을 별도 평가 항목으로 다뤄야 한다. 워터마킹은 생성 텍스트의 출처를 기계적으로 식별하려는 기능이지만, 구현 방식에 따라 다음 토큰을 뽑는 과정에 개입한다. 따라서 모델 가중치와 프롬프트가 같아도, 워터마크 유무나 키에 따라 출력 경로가 달라질 수 있다.
핵심은 워터마킹이 모델 품질을 전반적으로 떨어뜨리는가가 아니다. 우리 에이전트가 허용할 수 없는 종류의 변화가 어디에서 생기는지 확인하는 일이다.
출처 표시는 기능이고, 토큰 선택 변화는 운영 변수다
생성형 텍스트 워터마킹에는 완성된 문장 뒤에 표식을 붙이는 방식도 있고, 모델이 토큰을 생성하는 순간 표식을 심는 방식도 있다. 후자는 출력 텍스트에 숨은 신호를 남기기 위해 후보 토큰의 선택 과정에 영향을 준다.
일부 워터마킹 기법은 많은 생성 결과를 평균냈을 때 원래 토큰 분포를 보존하도록 설계된다. 이를 두고 출력 행동까지 동일하다고 해석하면 안 된다. 평균적인 분포 보존과 한 번의 실행에서 같은 단어, 같은 JSON 값, 같은 함수 인자를 내놓는 일은 다른 주장이다.
특히 에이전트는 자유 형식 대화보다 작은 차이에 민감하다. 다음과 같은 출력은 문장 표현보다 실행 결과를 바꿀 가능성이 크다.
- 함수 이름, API 엔드포인트, 파일 경로처럼 선택지가 제한된 값
- 검색 질의, 필터 조건, 날짜 범위처럼 모델이 여러 표현 중 하나를 골라야 하는 값
- 수신자, 권한 범위, 금액, 상태 변경 조건처럼 실행 후 되돌리기 어려운 값
- JSON 닫힘 괄호, 열거형 값, 스키마 키처럼 형식 검증을 통과해야 하는 값
- 호출하지 말아야 할 상황에서의 도구 호출 여부
여기서 문제는 워터마크가 언제나 오류를 만든다는 뜻이 아니다. 특정 모델, 워터마크 설정, 키, 온도, 프롬프트, 도구 스키마의 조합에서 변화가 나타나는지를 측정해야 한다는 뜻이다. 텍스트 품질 평가만으로는 이 질문에 답하기 어렵다.
정확도 평균만 보면 놓치는 ‘호출 변화’가 있다
워터마크 적용 전후의 도구 호출 정확도가 거의 같더라도, 같은 테스트 항목에서 결과가 바뀌었을 수 있다. 어떤 항목은 워터마크 적용 뒤 맞게 되고 다른 항목은 틀리게 되면, 전체 정확도 변화가 상쇄된다. 운영팀에는 평균 점수보다 “어느 요청이 이전과 다르게 행동했는가”가 더 중요할 때가 많다.
그래서 비교 시험에서는 정확도와 함께 쌍 비교 불일치율을 기록할 만하다. 같은 프롬프트, 같은 도구 정의, 같은 시드와 실행 조건에서 워터마크 적용본과 비적용본을 실행한 뒤, 도구 선택·인자·호출 여부·형식 검증 결과가 달라진 요청의 비율을 따로 본다.
이 지표는 워터마킹의 절대 성능을 판정하는 점수는 아니다. 대신 다음 질문을 드러낸다.
- 평균 정확도는 유지되지만 특정 업무에서 결과가 흔들리는가.
- 변화가 설명 문구에 머무르는가, 아니면 외부 시스템 호출까지 이어지는가.
- 오류가 스키마 검증에서 막히는가, 아니면 정상 호출처럼 보인 채 실행되는가.
- 한 워터마크 키에서만 나타나는가, 여러 키와 샘플링 조건에서 반복되는가.
도구 호출 평가에서 가장 위험한 경우는 JSON이 깨지는 경우만이 아니다. 문법적으로 유효하고 권한도 통과하지만, 사용자의 의도와 다른 대상을 처리하는 호출이 더 까다롭다. 형식 검증은 통과했으므로 재시도나 오류 알림으로 발견되지 않을 수 있기 때문이다.
거부 성능과 프롬프트 인젝션은 따로 확인해야 한다
워터마킹이 토큰 샘플링에 영향을 준다면, 안전 거부 문구와 도구 호출 경계에도 영향을 줄 가능성이 있다. 특히 외부 문서, 이메일, 웹페이지, 티켓 내용을 읽는 에이전트는 프롬프트 인젝션에 노출된다. 모델이 악성 지시를 거부하던 경계가 조금만 달라져도, 도구 권한이 붙은 환경에서는 결과가 커질 수 있다.
여기서 확인할 대상은 유해 요청에 대한 답변 태도만이 아니다. 에이전트에 맞춘 시험 시나리오를 따로 구성해야 한다.
- 신뢰하지 않는 문서가 도구 호출을 유도할 때, 호출 자체를 막는가
- 호출이 필요하더라도 읽기 전용 도구와 변경 도구를 구분하는가
- 사용자 요청과 외부 콘텐츠의 지시가 충돌할 때 어느 쪽을 우선하는가
- 거부한 뒤에도 우회 표현으로 동일한 작업을 수행하지 않는가
- 무해한 정상 요청까지 과도하게 거부하지 않는가
안전성 변화는 한 방향으로만 나타난다고 가정하기 어렵다. 어떤 항목에서는 더 보수적으로 반응하고, 다른 항목에서는 원래의 거부 경로를 벗어날 수 있다. 따라서 유해 요청 거부율과 정상 업무 완료율을 같은 표에 놓고, 각 항목의 전후 불일치를 검토하는 편이 낫다.
도입 판단은 ‘워터마크 유무’가 아니라 허용 가능한 변화량으로 한다
출처 식별이 사업·정책·계약상 필요한 제품도 있다. 유럽연합 AI 법의 합성 콘텐츠 표시 관련 요구처럼, 생성 결과를 기계적으로 식별할 수 있게 하려는 규제 방향도 존재한다. 다만 규제 대응 필요성이 곧 모든 에이전트 경로에 같은 워터마킹 설정을 적용해야 한다는 결론은 아니다. 기술적으로 가능한 범위, 적용 대상, 제공자 구현 방식은 별도로 확인해야 한다.
의사결정자는 먼저 업무를 세 부류로 나눌 수 있다.
| 업무 유형 | 우선 확인할 기준 | 허용 범위를 좁혀야 하는 이유 |
|---|---|---|
| 대화·요약·초안 생성 | 문장 품질, 출처 식별, 응답 지연 | 표현 변화가 있어도 사람이 검토할 여지가 비교적 크다 |
| 검색·분석 보조 | 검색 질의, 필터, 인용 근거, 재시도율 | 작은 질의 차이가 조사 범위와 답변 근거를 바꿀 수 있다 |
| 변경 권한이 있는 실행 에이전트 | 도구 선택, 인자 일치, 승인 우회, 복구 가능성 | 정상 형식의 잘못된 호출이 금전·권한·데이터 변경으로 이어질 수 있다 |
이 분류는 워터마크를 적용할지 말지의 이분법보다 현실적이다. 예를 들어 사용자에게 보이는 최종 설명에는 출처 식별을 적용하되, 고위험 도구 호출을 결정하는 내부 단계는 별도 모델이나 결정 규칙으로 제한하는 설계를 검토할 수 있다. 반대로 제공 모델의 워터마킹이 모델 수준에서 적용돼 분리하기 어렵다면, 더 강한 스키마 검증과 승인 단계를 보완책으로 삼아야 한다.
출시 전에 만들 수 있는 최소 검증 묶음
새 모델이나 새 워터마킹 정책을 도입할 때는 일반 벤치마크 결과를 받아보는 데서 멈추지 말고, 자사 에이전트의 실제 실행 경로로 회귀 시험을 구성하는 편이 좋다.
첫째, 호출 기대 사례와 호출 금지 사례를 함께 넣는다. “정확한 도구를 골랐는가”만 보면 과잉 호출을 놓친다. 정보가 부족하거나 적절한 도구가 없는 상황에서 호출하지 않는지도 같은 비중으로 평가해야 한다.
둘째, 인자를 필드별로 비교한다. 함수명이 같다는 이유로 같은 행동으로 처리하지 말고, 경로·대상·기간·금액·권한 범위처럼 업무 결과를 바꾸는 필드를 따로 검사한다. 값이 달라져도 동등한 경우와, 한 글자 차이로 다른 객체를 가리키는 경우를 구분할 규칙도 필요하다.
셋째, 워터마크 적용 여부뿐 아니라 모델 제공자가 허용하는 설정, 키, 온도, 시드 조건을 나눠 기록한다. 관찰된 변화가 모델 교체 때문인지, 샘플링 조건 때문인지, 워터마크 설정 때문인지 나중에 추적할 수 있어야 한다.
넷째, 운영 비용을 함께 측정한다. 형식 오류가 늘면 재시도 횟수와 토큰 사용량이 늘 수 있고, 의심스러운 호출을 사람이 검토하면 승인 대기 시간도 길어진다. 워터마킹의 비용은 모델 API 단가에만 있지 않다. 검증 레이어, 재시도, 감사 로그, 예외 처리에 들어가는 비용까지 포함해 판단해야 한다.
테스트 결과가 좋지 않다면 곧바로 워터마킹을 포기할 필요는 없다. 우선 해당 모델을 실행 권한이 없는 단계에 한정할지, 도구 인자를 결정론적 규칙이나 별도 검증기로 재확인할지, 위험한 동작에 사람 승인을 붙일지를 검토할 수 있다. 반대로 결과가 좋더라도 모델 업데이트 뒤에는 같은 시험을 다시 돌려야 한다. 토큰 생성 경로에 관련된 특성은 모델 버전과 제공 조건이 바뀌면 함께 달라질 수 있다.
워터마킹을 출처 기능으로만 구매하거나 평가하면, 에이전트의 행동 비용이 나중에 나타난다. 다음 모델 검토 회의에서는 탐지율 질문 옆에 이 질문을 추가해 두는 편이 좋다. “이 설정이 우리 에이전트의 어떤 호출을 전과 다르게 만들며, 그 차이를 누가 어디서 막을 것인가?”
