제공자 경계는 둘째 제공자가 들어올 때 결정해

쓸 만한 두 패턴과 성급한 한 선택

여러 제공자를 다루는 길은 두 가지야. 좁은 스트리밍 인터페이스를 각 제공자가 구현하게 하는 제공자 경계, 또는 한 제공자의 형식을 기준으로 삼고 나머지를 아래 계층에서 맞추는 기준 형식 변형이 있어. 둘 다 운영할 수 있지만, 첫 제공자만 있을 때 미래를 상상해 일반화부터 하는 건 대개 이르다.

cwkPippa는 기준 형식 변형을 골랐어

cwkPippa의 어댑터 ABC는 스트리밍 턴 경계만 다루고, 라우트·저장소·프런트엔드는 Claude 형식을 기준으로 봐. ChatGPT·Gemini·Ollama는 동격의 공통분모가 아니라 그 형식에 맞춘 변형 구현이야. 차이와 비용을 하류가 흡수해 상류를 억지 추상으로 만들지 않는 선택이야.

정말 바꿔 끼울 수 있을 때 경계가 빛나

능력과 비용 구조가 비슷하고 트래픽 중에도 교체해야 한다면 엄격한 제공자 인터페이스가 A/B 시험과 장애 전환, 새 구현 추가를 쉽게 해. 프롬프트 캐싱·에이전트 실행 장치·로컬 전용처럼 능력이 본질적으로 다르면 변형 구현이 차이를 더 정직하게 담아.

원칙: 구체적인 두 구현을 본 뒤 추상화해. 첫 제공자의 첫날은 경계를 확정하기에 너무 일러.

Code

cwkPippa-스타일 narrow ABC·python

from abc import ABC, abstractmethod
from typing import AsyncIterator, Any

class Adapter(ABC):
    """시스템에서 유일한 추상.
    Routes, store, frontend가 이게 반환하는 응답 모양 가정."""

    @abstractmethod
    async def stream_turn(
        self,
        *,
        conversation_id: str,
        messages: list[dict[str, Any]],
        system: str,
    ) -> AsyncIterator[dict[str, Any]]:
        ...

# claude.py가 canonical 구현;
# codex.py / gemini.py / ollama.py가 downstream에서 SPECIALIZE — 위로 abstract X.

Strict port (대안 패턴)·python

# 프로바이더가 정말 interchangeable일 때만 옳음.
class ModelProvider(ABC):
    capabilities: dict  # prompt_caching, files, agent 등 advertise

    @abstractmethod
    async def generate(self, req: GenerateRequest) -> GenerateResult: ...
    @abstractmethod
    async def stream(self, req: GenerateRequest) -> AsyncIterator[Event]: ...
    async def count_tokens(self, req: GenerateRequest) -> int: ...  # 선택

# Caller가 capabilities로 분기, common surface로 fall through.

쓸 만한 두 패턴과 성급한 한 선택

cwkPippa는 기준 형식 변형을 골랐어

정말 바꿔 끼울 수 있을 때 경계가 빛나

Code

External links

Exercise

Progress

댓글 0