🔍 연구의 필요성

LLM이 생성한 코드가 개발, 교육, 평가 현장에 빠르게 유입되면서, 주어진 코드가 어디에서 왔는지 확인하는 provenance tracking(출처 추적)의 필요성이 커지고 있습니다. 코드 워터마킹은 코드에 검출 가능한 신호를 심어 이후 출처를 판별할 수 있게 하는 대표적인 방법입니다. 그런데 코드는 자연어와 달리 토큰 하나만 바뀌어도 동작이 달라집니다. 문장에서는 단어 하나를 바꿔도 의미가 크게 흔들리지 않습니다. 반면 코드에서는 n--를 --n으로 바꾸는 것만으로 반복 횟수가 달라져 오답이 됩니다. 그래서 코드 워터마크는 잘 검출되는가뿐만 아니라 기능을 그대로 보존하는가까지 함께 평가되어야 합니다.

이를 위해서는 프로그램의 동작을 바꾸지 않으면서 신호를 실을 수 있는 선택지가 필요합니다. 그런데 신뢰할 수 있는 코드 워터마크를 만든다는 것은 단순히 신호를 많이 심는다는 의미가 아닙니다. 워터마크가 모든 프로그램에서 같은 방식으로 반복되면, 워터마크 코드 몇 개만 모아도 패턴이 드러나 공격자가 흉내 내거나 지울 수 있습니다. 반대로 x += 1처럼 사람도 원래 자주 쓰는 형태를 워터마크 증거로 그대로 세면, 워터마크가 없는 코드까지 워터마크로 오판됩니다. 즉 코드 워터마크는 (i) 기능을 보존하면서 (ii) 프로그램마다 예측할 수 없고 (iii) 자연스럽게 쓰인 코드와 통계적으로 구분된다는 세 조건을 동시에 만족해야 합니다.

기존 코드 워터마킹 방법들은 이 조건 중 일부만 다룹니다. 생성 중 삽입 방식은 LLM의 토큰 확률을 조작해 신호를 심습니다. 이 방식은 디코딩 접근이 필요하고, 선택지가 거의 없는 low-entropy 구간에서 검출력과 정답률 사이의 trade-off를 피하기 어렵습니다. 생성 후 삽입 방식은 완성된 코드를 변환합니다. 이 중 고정 변환은 모든 프로그램에서 같은 선택을 반복합니다. 학습 기반 변환은 별도의 추출 모델이 필요하며, 변환 과정에서 코드 동작을 깨뜨리기도 합니다. 두 방향 모두 "어디에 신호를 심을 수 있는가" 에는 답하지만, "그 신호가 사람이 쓰는 자연스러운 코드 스타일 속에서 어떻게 구분되는가" 에는 답하지 못합니다.

우리는 이 공백을 메우기 위해 SEW를 제시합니다. SEW는 생성 모델이나 별도 학습 모델 없이 이미 생성된 코드의 스타일 선택만으로 워터마크를 삽입하고 검출합니다. 이때 두 질문을 분리해서 해결합니다. "어떤 스타일을 어느 방향으로 쓸 것인가"는 비밀 키와 프로그램의 구조적 문맥으로 정합니다. "그 선택이 우연히 나왔을 확률"은 사람이 쓴 코드의 스타일 분포로 보정합니다.

✨ SEW란?

SEW (Style-Encoded Watermarking)는 LLM이 생성을 마친 코드와 비밀 키 K만을 입력으로 받아, 코드 스타일 선택으로 워터마크를 삽입하고 검출하는 post-hoc, model-free 워터마킹 파이프라인입니다. 워터마크는 토큰 확률이나 신경망의 내부 표현이 아닙니다. a < b ↔ b > a, x += 1 ↔ x = x + 1처럼 동작은 같고 형태만 다른 스타일 variant로 표현됩니다. 이 스타일 표현에는 세 가지 장점이 있습니다. 적용 조건 아래에서 프로그램 동작과 분리되어 있고, 생성 모델이나 추출 모델 없이 키만으로 검출할 수 있으며, 이미 생성된 어떤 코드에도 사후적으로 적용할 수 있습니다.

SEW는 기존 방법이 하나의 변환 안에서 함께 처리하던 세 과제, 즉 어디에 신호를 심을지, 어느 방향으로 심을지, 어떻게 판정할지를 명시적으로 분리합니다.

1. Style Rule Library (신호를 실을 자리 정의하기)

<aside> 📌

• 스타일 가이드, linter 규칙, 선행 연구에서 대안을 수집해 Python 29개, Java 22개, C++ 19개 규칙 구축
• 규칙마다 variant 0/1 두 형태 간 양방향 변환 지원 (한 스타일로 정규화하지 않음)
• type·side-effect·구조 조건을 만족하는 위치에서만 변환 (예: x += y ↔ x = x + y는 x가 숫자형일 때만) </aside>

2. Context-Conditioned Embedding (키와 구조 문맥으로 방향 정하기)

<aside> 📌

• CST(공백·괄호까지 보존하는 구문 트리)와 def-use 분석(변수의 정의·사용 위치 추적)으로 변환 가능한 site 식별
• HMAC(K, siteID ‖ χ(C))로 site마다 target 스타일 결정 (siteID: 위치의 구조 정보, χ(C): 함수·루프 수 등 프로그램 문맥)
• 같은 구조 위치에는 같은 스타일 → 프로그램 내 일관성, 문맥이 다르면 다른 스타일 → 프로그램 간 비예측성 </aside>

3. Calibrated, Context-Aware Detection (자연 빈도로 보정해 판정하기)

<aside> 📌

• Calibration: 평가셋과 분리된 LeetCode 풀이에서 스타일별 자연 발생 확률 추정
• Aggregation: 같은 구조 위치의 반복 site를 하나의 grade로 묶어 1회만 집계
• Calibrated test: 흔한 스타일과의 일치에는 적은 증거를 부여해 p-value 계산 (syntax 규칙만의 검정을 Bonferroni 보정으로 결합) </aside>

평가 지표 (Metric)

<aside> 📌

• TPR@FPR5%: 워터마크 없는 코드의 오탐률을 5%로 고정했을 때 워터마크 코드를 검출한 비율. 낮은 오탐 구간에서의 실사용 검출력 측정
• AUROC: threshold 전 구간에서 워터마크 코드와 비워터마크 코드의 점수 분리도
• pass@1: CodeContests의 public·private·generated 테스트를 모두 통과한 코드 비율. 워터마크 없는 출력(Vanilla)과 같으면 기능 보존으로 판단 </aside>