시멘틱 ID와 LLM 기반 이벤트 중개 패턴

AI가 소프트웨어 생태계의 중심 컴포넌트로 자리 잡으면서, 우리가 관습적으로 설계해 온 백엔드 아키텍처에도 변화가 요구되고 있습니다.
특히 Large Language Model을 연동하거나 AI 기반의 에이전트 시스템을 구축할 때, 기존의 설계 방식이 AI에게 거대한 장벽이 되는 경우가 많습니다.

AI 아키텍처를 설계할 때 가장 이상적인 구조 중 하나는 이벤트 기반 설계입니다.
마이크로서비스 아키텍처의 관점에서 볼 때, 이벤트 기반 설계는 AI가 한 번에 파악하고 컨텍스트를 유지해야 할 범위를 하나의 애그리거트 수준으로 제한해 주기 때문입니다.
복잡한 전체 시스템을 다 이해할 필요 없이 단일 엔티티와 그 변화를 담은 컨텍스트만 집중하면 되므로 AI의 연산 효율과 정확도 측면에서 매우 유리합니다.

그러나 이벤트 기반 설계 역시 치명적인 약점을 안고 있습니다. 분산된 세계에서 엔티티 간의 연결성을 파악하려면 결국 이벤트를 추적할 수 있는 정체성, 즉 ID 기반의 연결이 필수적입니다.
이 과정에서 기존의 전통적인 식별자 시스템이 가진 문제점과 이벤트 페이로드 간의 강한 결합문제가 발생합니다.
이 두 가지 핵심 문제를 해결하기 하는방법을 학습하기위해 포스팅하게되었습니다.

1. 기존 식별자의 한계와 AI의 치명적 약점

마이크로서비스로 시스템을 분리하거나 아무리 애그리거트 내부에 값 객체를 잘 내포시켜도, 정체성을 통한 외부 엔티티와의 연결은 완전히 배제할 수 없습니다.
데이터베이스 관점이나 시스템 통합 관점에서 우리는 흔히 무작위 문자열, 숫자 조합형 ID, 또는 UUID를 식별자로 사용해 왔습니다.

이러한 식별자는 시스템 간의 유일성을 보장하는 데는 탁월하지만, AI 친화적인 관점에서는 심각한 문제를 야기합니다.

비토큰문자열과 할루시네이션

기존의 무작위 ID나 단순 난수 문자열은 토크나이저 입장에서 유효한 의미를 가진 단어로 해석되지 않습니다.
LLM이 텍스트를 처리할 때 단어 수준이 아닌 파편화된 비토큰 문자로 인식하게 되며, 이는 다음과 같은 문제를 발생시킵니다.

• 어텐션 희석: 컨텍스트의 길이가 길어질수록, 의미가 없는 무작위 문자열은 AI의 어텐션 메커니즘 내에서 쉽게 희석됩니다.
  AI가 특정 엔티티의 식별자를 끝까지 기억하지 못하고 놓치게 되는 원인이 됩니다.

• 낮은 복원력: 일반적인 텍스트 컨텍스트에서 할루시네이션이 발생하면 문맥상 유의어나 비슷한 단어로 대체되어 전체적인 의미가 통하는 경우가 많습니다.
  그러나 ID 시스템에서는 단 한 글자, 혹은 마침표 하나만 잘못 생성되어도 완전히 다른 엔티티를 가리키거나 유효하지 않은 식별자가 되어 시스템 전체가 붕괴됩니다. 즉, 할루시네이션의 영향도가 지나치게 치명적입니다.

2. 대안으로서의 시멘틱 ID

이 문제를 해결하기 위해 메이저 기술 기업들과 프론티어 진영에서 연구하고 적용 중인 개념이 바로 시멘틱 ID입니다.
핵심은 식별자를 무의미한 난수가 아닌, LLM이 인지할 수 있는 유효한 토큰의 집합으로 구성하는 것입니다.
의미론적 규칙을 가진 토큰들의 조합으로 ID를 발행하면 AI 내부에서 어텐션이 훨씬 더 오래 유지됩니다.

대표적인 사례 연구

• What3Words: 전 세계의 위도와 경도라는 비토큰적이고 복잡한 숫자를 표현.면허증.가벼운 또는 삼켰다.심히.예약과 같은 3가지 임의 단어 조합으로 치환한 시스템입니다.
  숫자로 구성된 좌표값은 한 자리만 틀려도 완전히 다른 지역이 되거나 복원이 불가능하지만, 단어 기반의 시스템은 계층적 구조와 조합 규칙이 존재하기 때문에 단어의 순서가 약간 바뀌거나 오타가 발생해도 문맥적으로 올바른 식별자를 추론하고 복원해 낼 수 있습니다.

• GitHub 및 Heroku의 자동 레포지토리 명명법: 개발자가 레포지토리를 생성할 때, 플랫폼이 임의의 무작위 문자열 대신 clandestine-refuge-49120과 같은 형태소 조합형 이름을 자동으로 부여하는 것을 보았을 것입니다.
  레포지토리의 고유 식별자를 비토큰이 아닌 해석 가능한 토큰 기반으로 발행하려는 일종의 시멘틱 ID 접근 방식입니다.

백엔드 구현 전략과 효율성

시멘틱 ID를 시스템 내부적으로 구축하는 방법은 생각보다 간단하며, 성능적으로도 뛰어납니다.

1. 토큰 풀 정의: 개발자가 임의로 좋아하는 단어를 고르는 것이 아니라, 타깃으로 삼는 LLM 모델의 토큰 사전에 명확히 등재되어 있는 유효 토큰 예를들어 중학생 수준의 영단어 200~300개을 풀로 정의합니다.

2. 조합을 통한 고유성 보장: 영단어 200개만 확보하더라도 3자리 단어 조합을 만들면 $200 \times 200 \times 200 = 8,000,000$개의 고유 ID를 생성할 수 있습니다.
   단어 풀의 크기와 조합 자릿수를 조절하면 대규모 시스템에서도 충분히 고유성을 확보할 수 있습니다.

3. 생성 및 검색 성능: 복잡한 연산이 필요한 UUID 생성 알고리즘보다 정해진 단어 사전에서 무작위로 인덱스를 추출해 조합하는 방식이 연산 속도 면에서 훨씬 더 빠릅니다.
   DB 저장 시 고유 키 제약조건을 활용하고, 충돌 발생 시 이미 부여된 시드를 배제하고 재조합 하는 알고리즘을 타더라도 성능적 병목이 거의 발생하지 않습니다.

4. 오류 복원 룰셋 반영: 키의 토큰 순서나 일부 단어가 할루시네이션으로 인해 변형되더라도, 조합 규칙이나 계층 구조를 사전에 명시해 두면 아키텍처 수준에서 키 복원이 가능해집니다. 결과적으로 AI 환경에서 엔티티 간의 ID 연결성을 비약적으로 향상시킵니다.

3. 이벤트 메쉬의 지옥과 페이로드 의존성 문제

이벤트 기반 아키텍처의 또 다른 고질적인 아킬레스건은 페이로드 파편화에 따른 간접 의존성 지옥입니다.

표준적인 클라우드 이벤트 스펙을 도입하여 이벤트의 메타데이터 예를들어 type, source, time, subject 등 규격을 통일하더라도, 정작 비즈니스 데이터가 담기는 내부 페이로드는 이벤트의 종류마다 제각각입니다.

{
  "type": "com.shop.payment.success",
  "source": "/payment-service",
  "time": "2026-06-12T00:20:20Z",
  "payload": {
    "orderId": "TXT-OR-99812",
    "amount": 55000,
    "currency": "KRW",
    "paymentMethod": "CARD"
  }
}

이 상황에서 수신 측 서비스가 페이로드를 해석하려면 발행 측의 세부 데이터 스펙에 종속될 수밖에 없습니다.
만약 A팀이 비즈니스 요구사항 변경으로 인해 페이로드 내의 필드명을 orderId에서 order_id로 바꾸거나, 대문자 OrderID로 변경하면 이를 구독하던 B팀의 이벤트 파서 코드가 전부 박살나게 됩니다.
이로 인해 이벤트 스펙 변경 시마다 유관 부서들이 모여 회의를 하고 코드를 동기화해야 하는 거대한 간접 의존성이 발생합니다.

4. LLM을 활용한 유연한 이벤트 중개 패턴

과거에는 이러한 페이로드 변화에 대응하기 위해 엄격한 스키마 레지스트리를 관리하거나 어댑터 레이어를 수없이 작성해야 했습니다.
하지만 현재의 아키텍처는 페이로드를 해석하는 엔트로피 자체를 LLM에게 위임함으로써 이 의존성을 완전히 끊어낼 수 있습니다.

수신된 이벤트 페이로드에 내가 원하는 정보가 대략적으로 존재할 것이라는 비즈니스적 기대치만 있다면, 구체적인 스펙을 모르는 상태에서도 LLM을 중개자로 두어 데이터를 가공할 수 있습니다.

작동 매커니즘 및 프롬프트 전략

수신 서비스가 필요한 데이터 스펙은 자체적으로 정의한 단일 스펙 예를들어 주문 완료 일시와 주문 번호 확보 이라고 가정해 본다면..
상대방의 페이로드 구조가 어떻게 바뀌든, 수신한 원본 JSON 데이터 전체를 LLM에게 전달하고 유연한 파싱을 요청하는 방식을 취합니다.

[LLM 파싱 프롬프트 구조 예시]
당신은 시스템 간의 이벤트를 변환하는 미들웨어 엔진입니다.
입력된 JSON 데이터는 상점에서 결제 완료(payment success) 후 발송된 이벤트 페이로드입니다.

내가 수신측 시스템에서 최종적으로 필요로 하는 정보는 아래의 스펙입니다:
1. 주문 완료 일시 (Target Key: completion_date)
2. 주문 번호 (Target Key: target_order_id)

입력된 JSON 내부를 분석하여 이 두 가지 정보에 가장 부합하는 값을 찾아 지정된 키로 매핑된 JSON만 출력하십시오.
정확히 일치하는 명시적 키가 없는 경우, 시스템 메타데이터 중 발급일시(time) 등을 최선의 대안으로 삼아 추출하고, 어떤 대안 논리를 적용했는지 메타 필드에 기술하십시오.

아키텍처적 이점

이 패턴을 적용하면 아키텍처는 다음과 같은 강력한 유연성을 얻게 됩니다.

• 완전한 Decoupling : 발행 팀이 페이로드의 키 이름을 임의로 변경하거나, 심지어 특정 날짜 필드를 누락시켜 시스템 메타데이터의 time 값으로 대체해야 하는 상황이 오더라도 수신 측 코드는 아무런 수정 없이 비즈니스 로직을 계속 수행할 수 있습니다.
  LLM이 문맥적으로 가장 타당한 최선의 대안을 찾아 스스로 매핑해 주기 때문입니다.

• 유지보수 비용의 획기적 감소: 필드 포맷 변경이나 단순 리팩토링으로 인해 연쇄적으로 발생하던 타 팀의 시스템 장애가 원천 차단됩니다.
  개발자가 일일이 상대방 팀의 API 규격서나 이벤트 명세서를 보며 파싱 코드를 방어적으로 작성할 필요가 없어집니다.

AI 친화적 아키텍처의 핵심 요약

엔티티 간의 직접적인 연결이 가질 수 있는 아키텍처적 약점은 시멘틱 ID를 통해 데이터 구조 자체를 AI 친화적으로 보완함으로써 극복할 수 있습니다.

또한, 분산 이벤트 환경에서 발생하는 복잡하고 변화무쌍한 의존성 지옥은 LLM 기반의 유연한 파싱 레이어를 구축하여 해석의 부담을 모델에게 밀어버리는 구조로 해결할 수 있습니다.

이러한 접근법들은 단순한 기술적 트릭이 아니지만 시스템의 복잡성과 엔트로피를 인간 개발자의 수작업 코딩이 아닌 AI 메커니즘을 통해 완화하고 제어하는, 진정한 의미의 AI 네이티브 백엔드 아키텍처로 나아가는 이정표가 될 것이라 생각이듭니다.