🤖
0 in / 0 out / 0 total tokens
미국 지역 조례 데이터와 정책 준수 에이전트 상태 관리가 오늘의 핵심이다.
📄 논문
Freeing the Law with LOCUS: A Local Ordinance Corpus for the United States
법률 AI에서 연방법이나 판례보다 더 지저분하고 덜 정리된 층이 지역 조례다. LOCUS는 미국 지방 조례를 대규모로 기계가 읽을 수 있는 코퍼스로 만들려는 시도다. 개발자 입장에서 보면 모델 성능 이전에 데이터 접근성과 정규화가 병목이라는 점을 다시 보여준다.
이게 왜 중요한지: 법률 AI는 똑똑한 모델보다 신뢰 가능한 원문 데이터 파이프라인이 먼저 필요하다.
게임 서버로 치면 권위 서버 없이 클라이언트 예측만 고도화하는 꼴이다. 조례는 지역마다 형식, 용어, 업데이트 주기가 다를 가능성이 높아서 단순 크롤링만으로 끝나지 않는다. 실제 제품으로 이어지려면 검색, 버전 관리, 출처 추적, 관할 구역 매핑 같은 인프라가 같이 붙어야 한다.
LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents
LedgerAgent는 고객지원 같은 도메인에서 도구 호출 에이전트가 여러 턴 동안 작업 상태를 구조적으로 유지하고 정책을 지키게 만드는 접근이다. 에이전트가 대화 중 확인한 사실, 식별자, 아직 필요한 정보, 정책상 금지된 행동을 상태로 들고 가는 쪽에 초점을 둔다. 이건 프롬프트를 길게 쓰는 문제가 아니라 런타임 상태 설계 문제에 가깝다.
이게 왜 중요한지: 실서비스 에이전트의 실패는 모델이 몰라서보다 상태를 잃거나 정책 경계를 헷갈려서 터지는 경우가 많다.
UE5에서 게임플레이 상태를 대충 문자열 로그로만 복원하지 않는 것과 같은 이유다. 주문 취소, 환불, 본인 확인, 권한 체크 같은 흐름은 상태 머신과 감사 가능한 기록이 있어야 안정적으로 굴러간다. Ledger라는 이름처럼 에이전트가 무엇을 알고 있고 왜 다음 액션을 골랐는지 남기는 구조가 중요해진다.
개발자 코멘트
오늘 두 논문은 겉으로는 법률 데이터와 고객지원 에이전트라서 달라 보이지만, 둘 다 AI 제품의 하부 구조를 다룬다. 하나는 모델이 참조할 권위 있는 텍스트 레이어를 만들고, 다른 하나는 모델이 도구를 쓸 때 상태를 잃지 않게 만든다. 결국 LLM 앱도 서버처럼 데이터 소스, 상태, 정책, 로그가 없으면 데모에서 제품으로 넘어가기 어렵다.
개인적으로는 LedgerAgent 쪽이 사이드프로젝트에 바로 적용하기 좋아 보인다. 에이전트가 매 턴 자연어 컨텍스트만 뒤지는 구조는 금방 비용과 오류가 커진다. 중요한 값은 명시적인 상태 객체로 빼고, 정책 체크는 도구 호출 전후에 검증하는 식으로 설계해야 유지보수가 된다.
LOCUS는 당장 법률 도메인을 하지 않더라도 배울 점이 있다. 특정 산업의 로컬 규칙, 정책 문서, 운영 매뉴얼을 모델이 읽을 수 있게 만드는 일은 거의 모든 B2B AI 제품의 출발점이다. 데이터셋을 만든다는 말은 결국 도메인 지식을 배포 가능한 인프라로 바꾸는 일이다.
오늘의 방향은 명확하다. 더 큰 모델보다 더 믿을 수 있는 데이터와 더 명시적인 상태가 제품 AI를 만든다.