Transformers Are Succinct, 검증 난이도의 이론적 경고

더 강한가보다 더 짧게 표현하는가가 중요하다

OpenReview에 공개된 ICLR 2026 논문 Transformers Are Inherently Succinct는 transformer 이론을 보는 렌즈를 바꾼다. 논문은 transformer가 어떤 언어를 인식할 수 있는가만 묻지 않는다. 같은 언어를 얼마나 작게, 즉 얼마나 succinct하게 표현할 수 있는가를 묻는다. 저자들은 고정 정밀도 transformer가 LTL과 RNN보다 지수적으로 더 간결할 수 있고, finite automata보다 이중 지수적으로 더 간결할 수 있다고 주장한다.

이 결과가 중요한 이유는 실무적이다. 짧은 모델이나 짧은 규칙이 단순한 모델이라는 뜻은 아니다. 오히려 작은 transformer 안에 매우 큰 상태 구조가 압축돼 있을 수 있다. 논문은 emptiness와 equivalence 같은 기본 검증 문제가 EXPSPACE-complete가 된다고 설명한다. 검증이 어렵다는 말은 단지 엔지니어가 게으르다는 뜻이 아니라 계산복잡도 차원에서 어려울 수 있다는 뜻이다.

딥러닝 최적화 글이 다시 뜬 이유, LLM에도 잠이 필요하다는 논문의 의미, Models.dev, 모델 선택을 데이터 문제로 바꾸다는 모두 모델 성능을 제품 지표만으로 이해하기 어렵다는 점을 다뤘다. 이번 논문은 그 난점을 이론적 언어로 설명한다.

succinctness는 제품 장점이자 안전 비용이다

Transformer가 성공한 이유 중 하나는 긴 문맥과 복잡한 패턴을 비교적 단일한 구조로 다룰 수 있기 때문이다. Attention Is All You Need 이후 transformer는 언어, 코드, 이미지, 멀티모달 모델의 기본 구조가 됐다. 그러나 표현이 간결하다는 장점은 검증할 때 비용으로 돌아온다. 작은 회로처럼 보이지만 실제로는 거대한 automaton을 압축한 것이라면, 모든 가능한 입력에 대한 동작을 확인하는 일이 폭발적으로 어려워진다.

이는 AI 안전과 에이전트 검증에 직접 연결된다. 어떤 기업이 에이전트에게 이메일, 파일, 결제, 코드 배포 권한을 준다면 단순한 벤치마크 점수보다 중요한 질문이 생긴다. 이 에이전트가 특정 금지 행동을 절대 하지 않는다고 증명할 수 있는가. 두 버전의 정책 모델이 같은 안전 경계를 지키는지 확인할 수 있는가. 논문은 이런 질문이 구조적으로 어렵다는 경고를 준다.

RNN과 state-space model 논쟁에도 함의가 있다

최근 모델 구조 경쟁에서는 transformer, RNN 계열, state-space model이 계속 비교된다. 논문은 fixed-precision 조건에서 RNN이 더 넓은 regular language를 인식할 수 있다는 기존 논의를 인정하면서도, transformer가 특정 언어를 훨씬 더 짧게 표현할 수 있다는 점을 강조한다. 즉 더 표현력이 넓은 구조가 항상 더 효율적으로 표현하는 것은 아니다.

이 구분은 제품 선택에도 중요하다. 온디바이스 모델, 장문 컨텍스트 모델, 코드 에이전트 모델을 고를 때 단순 파라미터 수나 벤치마크 평균만 보면 안 된다. 어떤 작업 구조를 얼마나 압축해서 표현하는지, 그 압축이 디버깅과 검증을 얼마나 어렵게 만드는지까지 봐야 한다. OpenReview ICLR 2026 목록 같은 학술 흐름은 앞으로 모델 아키텍처 평가가 성능 경쟁을 넘어 검증 가능성 경쟁으로 확장될 것임을 보여준다.

한국 AI 기업의 실무 시사점

첫째, 고위험 도메인에서 transformer를 쓴다면 테스트 케이스 통과와 형식 검증을 혼동하면 안 된다. 테스트는 샘플을 본 것이고, 검증은 모든 경우를 다루려는 시도다. 둘째, 작은 모델이 더 안전하다고 단정하면 안 된다. 작은 모델도 복잡한 행동을 압축할 수 있다. 셋째, 정책 모델이나 guardrail 모델을 업데이트할 때 동등성 검사를 가볍게 봐서는 안 된다.

한국 기업이 이 논문에서 얻을 실천 과제는 명확하다. 안전 요구사항을 자연어 정책으로만 두지 말고, 가능한 부분은 typed rule, test harness, symbolic check, red-team dataset으로 분해해야 한다. 모든 것을 증명할 수 없다는 사실은 포기를 뜻하지 않는다. 오히려 어느 부분을 증명하고, 어느 부분을 경험적 테스트로 다루며, 어느 부분은 인간 승인으로 남길지 나누라는 뜻이다.

자주 묻는 질문

Q1: 논문이 transformer가 모든 면에서 RNN보다 강하다고 말하나요?

A: 아니다. 표현 가능한 언어의 범위와 표현의 간결함을 구분한다. 핵심은 transformer가 특정 언어를 훨씬 작게 표현할 수 있다는 점이다.

Q2: EXPSPACE-complete는 실무에서 무슨 뜻인가요?

A: 기본 검증 문제조차 계산적으로 매우 어려울 수 있다는 뜻이다. 모든 입력에 대한 보장을 쉽게 만들기 어렵다.

Q3: 작은 모델은 더 검증하기 쉬운가요?

A: 항상 그렇지 않다. 작은 transformer 안에도 큰 상태 구조가 압축돼 있을 수 있다.

Q4: 에이전트 안전과 어떤 관련이 있나요?

A: 에이전트가 권한을 가질수록 금지 행동을 하지 않는다는 보장이 필요하지만, 모델 동작의 전체 검증은 구조적으로 어렵다.

Q5: 기업은 무엇을 해야 하나요?

A: 완전한 증명만 기다리지 말고 테스트, 규칙 기반 제약, 감사 로그, 인간 승인, 제한된 권한을 함께 설계해야 한다.