ai

FACET의 역사와 근거

발행: (2025년 12월 17일 오전 09:01 GMT+9)
9 min read
원문: Dev.to

Source: Dev.to

번역할 전체 텍스트를 제공해 주시겠어요?
텍스트를 주시면 원본 형식과 마크다운을 유지하면서 한국어로 번역해 드리겠습니다.

이 문서의 목적

이 문서는 FACET의 설계 결정 뒤에 있는 역사적 맥락, 아키텍처 동기, 그리고 근거를 기록합니다.
이는 반복적으로 제기되는 미래의 질문에 답하기 위해 존재합니다:

왜 FACET은 이렇게 설계되었으며, 다르게 설계되지 않았는가?

이는 변경 로그도 아니며 로드맵도 아닙니다.
대상 독자는 다음과 같습니다:

  • 미래 유지보수자
  • 표준 검토자
  • 엔터프라이즈 아키텍트
  • AI 인프라스트럭처 역사가

1. Pre‑FACET 시대 (≈ 2018–2022)

1.1 프롬프트 엔지니어링의 안티패턴

Early LLM systems treated prompts as:

  • 불투명한 문자열
  • 변경 가능한 런타임 아티팩트
  • 비공식 계약

As systems grew, prompt engineering evolved into:

  • 복사‑붙여넣기 템플릿
  • 즉석 재시도
  • 정규식 기반 JSON 추출
  • 사후 검증

Failures were handled after generation, not prevented.
This era established a false assumption:

LLM의 신뢰성 부족은 본질적이며 피할 수 없다는.

1.2 구조화된 출력은 핵심 문제를 해결하지 못했다

Later approaches introduced:

  • 프롬프트 내 JSON 스키마
  • 함수/도구 호출 API
  • Pydantic 스타일 검증기

However:

  • 스키마는 권고사항일 뿐이며 강제되지 않았다
  • 제공자마다 제약 조건을 다르게 해석했다
  • 여전히 잘못된 상태가 생성되었다
  • 검증은 모델이 응답한 후에 이루어졌다

The system still allowed invalid intermediate states.

2. FACET v1.x (2022–2024): 교훈

FACET v1.x는 결정론적 프롬프트 템플릿 시스템으로 시작되었습니다. 다음을 도입했습니다:

  • 구조화된 블록
  • 조건부 로직
  • 초기 렌즈 파이프라인
  • 정규화된 JSON 출력

2.1 v1.x가 잘한 점

  • 결정론이 중요했습니다
  • 정규화된 JSON 덕분에 캐싱 및 차이점 비교가 가능했습니다
  • 구성(composition)이 단일 프롬프트보다 우수했습니다

2.2 v1.x가 해결하지 못한 점

  • 타입 시스템 부재
  • 실행 모델 부재
  • 잘못된 상태에 대한 공식적인 개념 부재
  • 도구 호출 실패 방지 미흡

FACET v1.x는 혼란을 감소시켰지만 완전히 없애지는 못했습니다.

3. 전환점 (2024–2025)

2024년까지 여러 시스템적 실패가 불가피해졌다:

  • 다중‑도구 에이전트가 비결정적으로 실패
  • 공급자‑별 도구‑호출 규칙으로 인한 무음 파손
  • 스트리밍 vs. 비스트리밍 분기
  • 컨텍스트 절단으로 논리 손상
  • 재시도가 정확성 버그를 가림

대규모에서는 이러한 실패가:

  • 비용이 많이 듦
  • 재현 불가능
  • 감사 불가능

산업계의 대응은 여전히 반응적이었다:

재시도 추가. 검증기 추가. 가드레일 추가.

이 접근 방식은 수렴하지 않았다.

4. 핵심 통찰

FACET v2.0은 단일 기본 인식에 기반합니다:

비결정론적 계약 위에 신뢰할 수 있는 시스템을 구축할 수 없습니다.

문제는 LLM이 아니었습니다.
문제는 계약 계층의 부재였습니다.

5. FACET v2.0 (2025): 구조적 재설정

FACET v2.0는 의도적으로 다음과 같이 설계되었습니다:

  • 컴파일러이며, 템플릿 엔진이 아니다
  • 계약 시스템이며, 헬퍼 라이브러리가 아니다
  • 실행 모델이며, 런타임 패치가 아니다

5.1 시스템 속성으로서의 결정론

FACET는 모델을 결정론적으로 만들려고 시도하지 않습니다. 대신:

  • 잘못된 상태가 상류에서 방지됩니다
  • 계약이 실행 전에 강제됩니다
  • 출력이 정규화됩니다

결정론은 아키텍처에 의해 달성되며, 확률 제어에 의해 달성되지 않습니다.

5.2 중간 표현으로서의 Canonical JSON

FACET는 Canonical JSON을 IR로 도입했습니다:

  • 제공자 중립적
  • 해시 안정적
  • diff 친화적
  • 재생 가능

이는 다음을 분리합니다:

  • 작성
  • 실행
  • 제공자 렌더링

그리고 공급자 종속성을 방지합니다.

5.3 실행 단계와 R‑DAG

FACET는 실행을 다섯 단계로 공식화했습니다:

  1. 해결
  2. 형식 검사
  3. 반응형 계산 (R‑DAG)
  4. 레이아웃 (Token Box Model)
  5. 렌더링

이로 인해 다음이 제거되었습니다:

  • 암시적 실행 순서
  • 숨겨진 부작용
  • 런타임 추측

5.4 Token Box Model

컨텍스트 처리가 다음과 같이 재정의되었습니다:

  • 자원 할당 문제
  • 명시적 우선순위와 함께
  • 결정론적 압축 규칙

다음으로 대체되었습니다:

  • 잘림 휴리스틱
  • “최선 노력” 패킹
  • 중요한 데이터의 무음 손실

5.5 순수 변환기로서의 어댑터

어댑터는 의도적으로 제한되었습니다:

  • 논리 없음
  • 추론 없음
  • 복구 없음

다음이 보존됩니다:

  • 감사 가능성
  • 재생 가능성
  • 장기 안정성

6. 거부된 대안 (설계상)

FACET는 명시적으로 다음을 거부했습니다:

  • 확률적 재시도
  • 자체 치유 프롬프트
  • 적응형 프롬프트 재작성
  • 런타임 스키마 복구

이러한 기술은 실패를 제거하기보다 가립니다.

7. 장기 포지셔닝

FACET는 다음과 같이 오래 지속되도록 설계되었습니다:

  • LLVM
  • SQL
  • JSON Schema

다음과는 다르게:

  • 에이전트 프레임워크
  • 벤더 SDK
  • 프롬프트 툴킷

다음과 같은 특성을 유지하도록 의도되었습니다:

  • 지루함
  • 엄격함
  • 예측 가능함

수십 년 동안.

8. 역사적 기여

FACET — 결정론적 계약 레이어 (2025년부터)

작성자: Emil Rokossovskiy (rokoss21)

핵심 아이디어는 업계 합의보다 먼저 존재했습니다. 결정론이 급박해졌을 때, 이미 해당 아키텍처가 구축되어 있었습니다.

Status

This document is informative.
It does not define new requirements, but explains why the requirements exist.

End of document.

Back to Blog

관련 글

더 보기 »