[LLM] Structured Output 는 얼마나 신뢰할 수 있을까 ?

Tae Jeong 2025. 12. 2. 16:29

2025. 12. 2. 16:29

728x90

배경

대고객 챗봇 개발 당시 hallucination 에 관한 기준이 엄격해 모르는 답변은 모른다고 답변하고 상담원 연결로 돌리는 로직으로 설계되어 있었습니다.

때문에 고객이 chain 구조에서 조금만 예상에 어긋나는 행동을 하면 답변을 회피(모르겠다 답변 후 상담원 연결) 해 상담 만족도가 떨어지는 문제가 발생했는데요, 그래서 질문에 유연하게 대응하기 위해 체인구조에서 ReAct agent 로 마이그레이션 하기로 했습니다.

체인에 도달할 때에는 정해진 DTO 를 지켜야 했는데 체인이 있는 Tool 까지 도달할 때에는 이미 LLM 에 의해 DTO 가 뭉개져 Tool 에 인자를 전달하지 못하는 문제가 발생했습니다. 이때 프롬프트로만 출력을 제어했었는데, 답변을 잘하는 것 처럼 보였지만 Langsmith 로 agent tool calling을 추적한 결과 내부적으로는 일부 데이터들을 누락되고 calling 을 반복 하는 문제가 발생했습니다. 아마 강력한 프롬프트를 쓰면 좀 나아졌겠지만 결과적으로 이 문제는 응답시간 지연과, 토큰 비용 증가로 이어졌습니다. 하지만 고객반응과 실제 비지니스 문제해결에는 문제가 없었기 때문에 우선순위에 밀려 기술부채로 남게되었습니다.

지금 회사에 오게 되면서 structured output 에 관한 개념을 접하게 되고 신뢰가능한지, 실제 대고객 업무에서 사용할 만큼 신뢰도 있는지 확인해보려고 합니다.

Structured Output 의 작동원리

먼저 structured output 은 LLM 의 output 을 Json 이나 Pydantic 혹은 dataclass 같은 형태로 받을 수 있는 기능입니다. 또한 에러처리가 가능한데, 모델이 범위를 어긋나게 응답하거나 자료형을 틀리게 매칭한다면 validation error 를 만들 수 있어 에러메시지 유도가 가능합니다.

이것을 잘 활용하면 특정 경우에만 (format 이 맞지 않는 경우, 필드에 값이 잘못 들어가는 경우) Error를 발생시킬 수 있습니다. 일반적으로는 재시도를 하게되고 재시도 하는 경우 대부분 잘 매칭이 됩니다. 가장 치명적인 것은 structure 에 맞게 데이터를 넣기는 하지만, 그 값이 실제로 맞는지는 보장하지 않는 다는 것을 고려해야합니다.

작동 순서

모델과 스키마를 입력받는다.
langchain 내부에서 전략을 선택함
1. toolcalling strategy : 모델이 structured output 지원하지 않는 경우
2. langchain 이 도구호출 JSON 형태로 반환하고 langchain 에서 파싱해서 스키마에 맞는 개체로 변환하는데 도구 호출 자체가 토큰을 더 쓰기때문에 비용증가/응답시간 증가가 발생합니다 https://platform.openai.com/docs/guides/structured-outputs
provider strategy : 모델이 structured output 지원하는 경우
langchain or agent 응답 생성
결과물 유효성 검증 : 스키마에 맞게 파싱이 되었는지 Pydantic 이나 json 기반 파서 사
파싱 성공하면 structured_response 에 넣어서 최종결과 반환

스키마입력 / 전략선택

스키마를 입력받는 부분부터 살펴보겠습니다. 아래의 예제가 있습니다.

Pydantic 스키마로 예시를 작성했는데 with_structured_output 메소드의 인자로 Pydantic 이 스키마로 넘어가게 됩니다.

class ReviewSummary(BaseModel):
    title: str = Field(..., description="리뷰 제목")
    sentiment: str = Field(..., description="긍정/부정/중립 중 하나")
    score: float = Field(..., description="0~1 사이의 감정 점수")
    
from langchain_openai import ChatOpenAI

# OpenAI API 또는 vLLM OpenAI 서버 URL로 자동 연결됨
model = ChatOpenAI(
    model="gpt-4o-mini",  # 아무 모델 가능
    temperature=0
)

structured_model = model.with_structured_output(ReviewSummary)

result = structured_model.invoke(user_input)

print(result)
print(type(result))
------------
title='영화 리뷰 요약'
sentiment='부정'
score=0.15
<class '__main__.ReviewSummary'>
------------

structured output 지원하는 일부 모델들은 아래처럼 벤더사가 지원하는 스키마에 맞게 변환하는 도구만을 bind 한 채로 끝나게 됩니다.

class ChatAnthropic(BaseChatModel):
#----------중략----------
	def with_structured_output():
	#----------중략----------
        if method == "function_calling":
            formatted_tool = **convert_to_anthropic_tool(schema)**
            tool_name = formatted_tool["name"]
            if self.thinking is not None and self.thinking.get("type") == "enabled":
                llm = self._get_llm_for_structured_output_when_thinking_is_enabled(
                    schema,
                    formatted_tool,
                )
            else:
                llm = self.bind_tools(
                    [schema],
                    tool_choice=tool_name,
                    ls_structured_output_format={
                        "kwargs": {"method": "function_calling"},
                        "schema": formatted_tool,
                    },
                )

@dataclass(init=False)
class ProviderStrategy(Generic[SchemaT]):
    """Use the model provider's native structured output method."""

    schema: type[SchemaT]
    """Schema for native mode."""

    schema_spec: _SchemaSpec[SchemaT]
    """Schema spec for native mode."""

    def __init__(
        self,
        schema: type[SchemaT],
    ) -> None:
        """Initialize ProviderStrategy with schema."""
        self.schema = schema
        self.schema_spec = _SchemaSpec(schema)

그리고 Provider 에 없는 모델은 ToolStrategy 를 사용하게 되는데 vllm 같은 로컬 서빙 프레임워크에서 작동시키는 모델들이 대체로 그러합니다.

class ChatOllama(BaseChatModel):
   #---중략----
   def with_structurd_output():
	   #---중략----
     if is_pydantic_schema:
            schema = cast("TypeBaseModel", schema)
            if issubclass(schema, BaseModelV1):
                response_format = schema.schema()
            else:
                response_format = schema.model_json_schema()
            llm = self.bind(
                format=response_format,
                ls_structured_output_format={
                    "kwargs": {"method": method},
                    "schema": schema,
                },
            )

@dataclass(init=False)
class ToolStrategy(Generic[SchemaT]):
    """Use a tool calling strategy for model responses."""

    schema: type[SchemaT]
    """Schema for the tool calls."""

    schema_specs: list[_SchemaSpec[SchemaT]]
    """Schema specs for the tool calls."""

    tool_message_content: str | None
    """The content of the tool message to be returned when the model calls
    an artificial structured output tool."""

    handle_errors: (
        bool | str | type[Exception] | tuple[type[Exception], ...] | Callable[[Exception], str]
    )

ToolStrategy 는 bind 메서드를 사용하여 러너블 객체에 접근하고 그 지점에 툴콜링을 하게 됩니다.

사람이 개입하여 벤더사의 툴을 호출할 수 있지만 전략선택의 결정적으로 큰 차이는 결국 with_structured_output 함수를 호출할 때 기본으로 선택되는 method 가 다르다는 것입니다.

모델이 structured output 지원하지 않는 경우

def with_structured_output(
        self,
        schema: dict | type,
        *,
        method: Literal["function_calling", "json_mode", "json_schema"] = "json_schema",
        include_raw: bool = False,
        **kwargs: Any,
    ) -> Runnable[LanguageModelInput, dict | BaseModel]:
        r"""Model wrapper that returns outputs formatted to match the

structured output 지원하는 경우

def with_structured_output(
        self,
        schema: dict | type,
        *,
        include_raw: bool = False,
        method: Literal["function_calling", "json_schema"] = "function_calling",
        **kwargs: Any,
    ) -> Runnable[LanguageModelInput, dict | BaseModel]:
        """Model wrapper that returns outputs formatted to match the given schema.

structured output 을 지원하는 경우에는 method 가 function_calling 으로 api 제공 벤더사의 function calling 형태로 처리하고

if method == "function_calling":
    formatted_tool = convert_to_anthropic_tool(schema)
    tool_name = formatted_tool["name"]
    if self.thinking is not None and self.thinking.get("type") == "enabled":
        llm = self._get_llm_for_structured_output_when_thinking_is_enabled(
            schema,
            formatted_tool,
        )
    else:
        llm = self.bind_tools(
            [schema],
            tool_choice=tool_name,
            ls_structured_output_format={
                "kwargs": {"method": "function_calling"},
                "schema": formatted_tool,
            },
        )

bind_tools 메서드를 사용하고 있습니다.

반대의 경우에는 json_schema 가 기본 선택되어 bind 메서드를 사용해서 tool calling 형태가 아니라 runnable sequence 에 새로운 객체를 만들어 호출 옵션을 재정의는 것입니다.

elif method == "json_schema":
            if schema is None:
                msg = (
                    "schema must be specified when method is not 'json_mode'. "
                    "Received None."
                )
                raise ValueError(msg)
            if is_pydantic_schema:
                schema = cast("TypeBaseModel", schema)
                if issubclass(schema, BaseModelV1):
                    response_format = schema.schema()
                else:
                    response_format = schema.model_json_schema()
                llm = self.bind(
                    format=response_format,
                    ls_structured_output_format={
                        "kwargs": {"method": method},
                        "schema": schema,
                    },
                )
                output_parser = PydanticOutputParser(pydantic_object=schema)  # type: ignore[arg-type]

##bind example
"""
        Example:
            ```python
            from langchain_ollama import ChatOllama
            from langchain_core.output_parsers import StrOutputParser

            model = ChatOllama(model="llama3.1")

            # Without bind
            chain = model | StrOutputParser()

            chain.invoke("Repeat quoted words exactly: 'One two three four five.'")
            # Output is 'One two three four five.'

            # With bind
            chain = model.bind(stop=["three"]) | StrOutputParser()

            chain.invoke("Repeat quoted words exactly: 'One two three four five.'")
            # Output is 'One two'
            
"""

자체적으로 response_format 을 세팅하고 있는 것을 볼 수 있습니다. 이렇게 스키마를 입력받고 전략을 선택하는 로직을 거치게 됩니다.

이제 전략별로 어떻게 structured output 을 만들어 내는지 살펴보겠습니다.

전략별 응답생성 과정

ToolcallingStrategy
```
class ToolStrategy(Generic[SchemaT]):
    schema: type[SchemaT]
    schema_specs: list[_SchemaSpec[SchemaT]]
    tool_message_content: str | None
    handle_errors: bool | ...
```
langchain 은 schema_spec 을 이용해서 fake tool schema 를 생성하고 이 fake tool 이름이 structured output 같은 형태로 모델에게 전달됩니다. 그럼 모델은 아래와 같은 형태로 응답합니다.이제 json 을 파싱해서 pydantic 이나 dataclass 검증을 하고 실패하면 Validation Error 을 뱉어내고 다시 모델에게 요청을 하게 됩니다.
```
{
  "tool": "structured_output",
  "arguments": {
      "title": "some text",
      "score": 0.82
  }
}
```
이 error 이후 다시 모델에게 요청하는 과정에서 만약 모든 컨텍스트를 포함한 체인이나 노드라면 정말 많은 토큰이 낭비되고, 응답시간이 지연되게 됩니다.모델이 native 하게 structured output 을 지원하지 않는 경우 Toolcalling strategy 를 선택하게 됩니다.
ProviderStrategy
```
@dataclass(init=False)
class ProviderStrategy(Generic[SchemaT]):
    """Use the model provider's native structured output method."""

    schema: type[SchemaT]
    """Schema for native mode."""

    schema_spec: _SchemaSpec[SchemaT]
    """Schema spec for native mode."""
```
langchain 은 스키마만 그대로 모델에게 전달하고 응답받아서 파싱만 수행합니다. openAI 와 anthropic gemini 의 응답은 안정적으로 다시 모델에게 요청하는 경우가 적습니다. 모델이 자체적으로 structured output 을 지원하는 경우입니다. 이때 langchain 은 각 벤더사에 맞는 형태로 변환/파싱을 수행합니다.

Structured Output 테스트

openai 의 structured otutput은 아래의 장점을 갖고 있는데, 특히 세번째 부분이 인상적이었습니다. 이전 챗봇 개발당시 레거시는 이 기능을 몰랐던것인지 프롬프트로 출력을 강제하고 있었는데, structured output 을 사용하면format 을 지키기 위해서 강력한 프롬프트를 하지 않아도 되기 때문입니다.

structured output 이 언제 지원되도록 포함되었는지 확인해보니 Toolcalling strategy 는 2023년 중후반쯤 그리고 ProviderStrategy는 2024년 8월 6일 gpt-4o 모델을 시작으로 openai 가 가장먼저 지원했습니다. 그 다음 anthropic 과 gemini 가 차례로 지원하기 시작했습니다.

langchain 스테이블버전이 2024년 1월에 배포되고, 그때부터 챗봇 레거시가 개발되기 시작했으니 최초 시스템 개발 이후 신기술 추적을 1년 6개월 가까이 하지 않았다는 것을 알 수 있었습니다.

그럼 실제로 프롬프트로 출력을 강제하는 것과 structured output 으로 output 형태를 파싱하는 것이 얼마나 다른지 확인해보겠습니다.

프롬프트 엔지니어링으로 output format 강제 테스트

system_prompt = """당신의 임무는 아래 Pydantic 모델 스키마에 정확히 맞는 JSON만 생성하는 것이다.

당신은 문제를 해결하기 위해 내부적으로 논리적 단계별 추론(Chain-of-Thought)을 수행해야 한다.

그러나 그 사고 과정은 절대 출력하지 말고, 최종 출력은 아래 스키마에 완전히 맞는 JSON만 생성해야 한다.

출력 형식 규칙:

1. 반드시 JSON 포맷으로만 출력한다.

2. JSON 바깥에 어떤 설명, 문장, 여분의 텍스트도 절대 출력하지 않는다.

3. 모든 필드는 반드시 포함해야 한다: name, age, address, phone_number

4. 필드 타입은 스키마와 100% 일치해야 한다.

- name: 문자열

- age: 정수

- address: 문자열

- phone_number: 문자열

5. 의미 없는 값, null, None, undefined 등을 넣지 말고 실제 값으로 채운다.

6. JSON 키 이름은 스키마와 완전히 동일해야 하며, 대소문자 변경 금지.

7. JSON 외부에 주석, 마크다운, 공백 라인도 출력하면 안 된다.

8. 예시는 절대로 설명하지 말고, 최종 출력도 예제와 동일한 형식의 JSON만 생성한다.

Pydantic 모델 스키마:

class Gender(str, Enum):

male = "male"

female = "female"

other = "other"

class Address(BaseModel):

street: str = Field(description="Street name and number")

city: str = Field(description="City name")

state: str = Field(description="State/Province")

postal_code: str = Field(description="Postal/ZIP code")

country: str = Field(description="Country name")

class UserProfile(BaseModel):

name: str = Field(description="The user's full name")

age: int = Field(description="The user's age")

gender: Gender = Field(description="The user's gender")

email: str = Field(description="The user's email address")

phone_number: str = Field(description="The user's primary phone number")

addresses: List[Address] = Field(description="List of user's addresses")

date_of_birth: date = Field(description="The user's birth date")

interests: List[str] = Field(default_factory=list, description="List of user's interests")

is_active: bool = Field(default=True, description="Whether the user is active")

bio: Optional[str] = Field(default=None, description="Short biography of the user")

friends_ids: Optional[List[int]] = Field(default_factory=list, description="List of friend's user IDs")

account_created: date = Field(description="Date when the user account was created")

[입력 예제 1]

나이는 27세이고, 성별은 남성입니다.

이메일 주소는 taejung.park@example.com이고, 휴대폰 번호는 010-1234-5678입니다.

주소는 서울 영등포구 영등포로 123번지와 서울 강남구 강남대로 456번지 두 곳입니다.

생년월일은 1996년 5월 14일이고, 관심사는 독서, 영화, 등산입니다.

활성 상태는 True이며, 자기소개는 "안녕하세요, 서울에서 개발자로 일하고 있습니다."입니다.

친구 ID는 101, 102, 103이고, 계정 생성일은 2020년 8월 1일입니다.

[출력 예제 1]

{

"name": "박태정",

"age": 27,

"gender": "male",

"email": "taejung.park@example.com",

"phone_number": "010-1234-5678",

"addresses": [

{

"street": "영등포로 123",

"city": "서울",

"state": "영등포구",

"postal_code": "07200",

"country": "대한민국"

{

"street": "강남대로 456",

"city": "서울",

"state": "강남구",

"postal_code": "06100",

"country": "대한민국"

}

"date_of_birth": "1996-05-14",

"interests": ["독서", "영화", "등산"],

"is_active": true,

"bio": "안녕하세요, 서울에서 개발자로 일하고 있습니다.",

"friends_ids": [101, 102, 103],

"account_created": "2020-08-01"

}

[입력 예제 2]

안녕하세요. 유저 김하나의 정보를 알려드릴게요.

나이는 30세이고, 성별은 여성입니다.

이메일은 kim.hana@example.com, 휴대폰 번호는 010-9876-5432입니다.

주소는 서울 강북구 미아로 11과 경기 성남시 분당구 삼평동 22번지 두 곳입니다.

생년월일은 1993년 9월 10일이고, 관심사는 요가, 영화, 여행입니다.

활성 상태는 True이며, 자기소개는 "안녕하세요, 프리랜서 디자이너입니다."입니다.

친구 ID는 201, 202, 203이고, 계정 생성일은 2019년 3월 15일입니다.

[출력 예제 2]

{

"name": "김하나",

"age": 30,

"gender": "female",

"email": "kim.hana@example.com",

"phone_number": "010-9876-5432",

"addresses": [

{"street": "미아로 11", "city": "서울", "state": "강북구", "postal_code": "01000", "country": "대한민국"},

{"street": "삼평동 22", "city": "성남시", "state": "분당구", "postal_code": "13500", "country": "대한민국"}

"date_of_birth": "1993-09-10",

"interests": ["요가", "영화", "여행"],

"is_active": true,

"bio": "안녕하세요, 프리랜서 디자이너입니다.",

"friends_ids": [201, 202, 203],

"account_created": "2019-03-15"

}

위 규칙과 예제를 모두 참고하여, 지금부터 어떤 입력이 들어오더라도 Pydantic UserInfo 스키마에 완전히 맞는 JSON만 출력하라.

사고 과정은 내부적으로만 사용하고 절대 외부로 노출하지 않는다."""

Structured Output Pydantic 파라미터 전달 테스트

structured output 은 공식문서에서도 “structured output 은 실수할 수 있다” , “최대한 스키마에 대한 정보를 잘 작성해라” 라고 말하고 있습니다. 그래서 따라서 LLM 이 분류하거나, 어떤 포맷에 입력을 강제해야한다면 Pydantic 사용하기를 권장합니다.

간단한 프롬프트의 경우 둘다 잘 뱉어내는 것을 볼 수 있습니다.

그럼 실무에서 발생하는 시나리오를 생각해보고 테스트 해보겠습니다. LLM 이 섭취하게 될 데이터는 생각보다 복잡할 수 있습니다. 특히 여러개 DTO 가 섞여있는 경우 DTO 가 기하급수적으로 커지게 되는데요 3개의 DTO를 예시로 하여 json 타입이 아닌 자연어로 데이터를 주었을 때 잘 파싱하는지 확인해보겠습니다.

class Gender(str, Enum):
    male = "male"
    female = "female"
    other = "other"

class Address(BaseModel):
    street: str = Field(description="Street name and number")
    city: str = Field(description="City name")
    state: str = Field(description="State/Province")
    postal_code: str = Field(description="Postal/ZIP code")
    country: str = Field(description="Country name")

class UserProfile(BaseModel):
    name: str = Field(description="The user's full name")
    age: int = Field(description="The user's age")
    gender: Gender = Field(description="The user's gender")
    email: str = Field(description="The user's email address")
    phone_number: str = Field(description="The user's primary phone number")
    addresses: List[Address] = Field(description="List of user's addresses")
    date_of_birth: date = Field(description="The user's birth date")
    interests: List[str] = Field(default_factory=list, description="List of user's interests")
    is_active: bool = Field(default=True, description="Whether the user is active")
    bio: Optional[str] = Field(default=None, description="Short biography of the user")
    friends_ids: Optional[List[int]] = Field(default_factory=list, description="List of friend's user IDs")
    account_created: date = Field(description="Date when the user account was created")

Input은 아래와 같이 했다.

박준호라는 사용자의 정보를 JSON으로 만들어주세요. 
나이는 24세, 남성이며, 이메일은 park.junho@example.com, 
전화번호는 010-1111-2222입니다.  
주소는 부산 해운대구 마린시티 5번지와 대구 수성구 범어로 88번지입니다.
생일은 2000년 12월 1일, 관심사는 게임, 코딩, 축구입니다. 
사용자는 비활성 상태(False)이며, 자기소개는 게임 개발자를 꿈꾸고 있는 대학생입니다.
친구 ID는 301, 302, 계정 생성일은 2021년 6월 20일입니다.

복잡한 구조적 데이터를 프롬프트로 형태를 강제한 것도 대체로 잘 파싱하는 것을 볼 수 있습니다. 하지만 결과물을 보면 postal code에 포함되어 있지 않은 데이터가 들어있습니다.

그렇다면 structured output 을 사용한 쿼리는 어떨까요?

찬가지로 잘 파싱합니다. DTO가 복잡해지더라도 좋은 모델인 경우에는 거의 다 파싱을 해내는 것을 볼 수 있었습니다. 하지만 한가지 차이점이 발생했는데요 with structured output 메서드는 postal_code 가 빈칸인 것을 볼 수 있습니다. 하지만 prompt 로 강제한 경우에는 실제 데이터에 postal code 가 없음에도 불구하고 dummy 데이터가 들어가있는 것을 볼 수 있습니다.

Structured Outpu는 신뢰할 수 있을까

지금까지 내용으로 structured output 을 사용할 때 조금 더 잘 파싱이 되는 것을 볼 수 있었는데요, 훨신 간결하고 성능이 좋으니 따라서 프롬프트로 강제하는 것보다 structured output 기능을 사용하는것이 훨씬 더 유리할 것 같습니다.

2025년 12월 2일 기준으로

https://llm-stats.com/

AI Leaderboards 2025 - Compare All AI Models

Comprehensive AI leaderboards comparing LLM, TTS, STT, video, image, and embedding models. Compare performance, pricing, and capabilities across all AI modalities.

llm-stats.com

실험에 사용한 gpt-4o 모델보다 괜찮은 로컬 모델들이 많은데요 30B 정도 되는 모델들을 사용한다면 로컬에서 돌리는 모델들도 잘 작동할 것이라 예상합니다. 그래서 성능측면에서 어떤 전략이 더 우월하다는 것은 큰 의미가 없어보입니다.

하지만 그럼에도 불구하고 Toolcalling Strategy 의 경우는 retry 가 자주 발생할 수 있기 때문에 structured output 지원되는 api 를 사용할 수 있는 환경이라면 ProviderStrategy 를 사용할 수 있는 방법으로 시도해야 한다고 생각합니다.

이제 출력 구조를 프롬프트로 강제하는 것보다 structured output 을 사용하는 것이 좋다는 것은 알게 되었습니다. 그럼 결정적으로 structured output 을 신뢰할 수 있을까? 에 대한 답을 구해야하는데, 최근 아래의 글을 읽게 되었습니다.

https://www.philschmid.de/why-engineers-struggle-building-agents

Why (Senior) Engineers Struggle to Build AI Agents

Traditional software engineering is deterministic, while AI agents operate probabilistically. This fundamental difference creates challenges for engineers accustomed to strict interfaces and predictable outcomes.

www.philschmid.de

시니어 개발자들이 주니어 개발자들보다 AI Agent 를 개발하는게 느리다는 주제로 시작한 글인데 그 이유를 생각하면 사뭇 철학적으로 받아들여야 할 부분이 있습니다.

이유는 전통적인 소프트웨어 엔지니어링(엄격한 제어, 결정론적) 그러니까 맞으면 맞는거고 틀리면 틀린거지, 틀리면 고쳐야지 라는 전통적인 엔지니어링의 철학과 습관이 AI 에이전트 개발에 방해가 되고 있다는 겁니다. 글의 저자인 Phillipp Schmid 는 시니어일수록 LLM 의 불확실성을 코드로 제거하려고 하는 경향이 있어 주니어보다 느려진다는 것입니다.

텍스트 데이터의 맥락을 구조화 된 것으로 강제하면 LLM이 잘하는것을 오히려 더 못하게 하면서 성능이 떨어지고 성능이 떨어지는 이유를 코드로 제거하려 하니 수렁에 빠지게 된다의 의미인 것 같습니다.

그래서 저자는 agent를 개발할 때 아래의 정신을 갖추어야 한다고 제안합니다.

텍스트가 새로운 상태(State)
- 함정: 자연어 입력을 구조화된 데이터(예: true/false)로 강제하면 맥락 상실.
- 해결: 피드백(예: “승인, 미국 시장 집중”)을 텍스트로 보존해 동적 조정 가능.
제어권을 넘겨라
- 함정: 흐름을 하드코딩(예: 구독 취소 루트)하면 비직선적 상호작용 대응 실패.
- 해결: 에이전트(LLM)가 맥락 기반으로 의도 판단하도록 신뢰.
에러는 그냥 입력이다
- 함정: 에러 발생 시 프로그램 중단(전통 방식)으로 고비용 실행 낭비.
- 해결: 에러를 피드백으로 제공해 에이전트가 자가 복구 시도.
유닛 테스트에서 Eval로
- 함정: 이진 테스트(TDD) 적용 시 확률적 시스템에서 무의미(무한 유효 답변).
- 해결: 신뢰성(Pass@k), 품질(LLM Judge), 추적(Eval)로 변동성 관리.
에이전트는 진화하고, API는 그렇지 않다
- 함정: 인간 중심 API(암묵적 맥락) 사용 시 에이전트 환각 발생.
- 해결: 상세 시맨틱 타이핑(예: “user_email_address”)과 독스트링으로 명확화. 에이전트는 도구 변화에 적응 가능.

결론은 엔지니어링 산물의 확률성을 받아들이고 edge case 들을 강제하는 것이 아닌 그 마저도 LLM 이 자기피드백을 할 수 있는 탄력적 시스템 구축으로 만들고 그 과정을 관리하라는 말 입니다.

그래서 다시 요점으로 돌아와 structured output 을 신뢰할 수 있는가? 에 대한 답은 신뢰할 수 있다에 가깝다. 인 것 같습니다. 그리고 신뢰할 수 있다 없다 로 판단하는것이 아니라 얼마나 신뢰할 수 있는가? 에 집중해야 하겠습니다.

기능은 대체로 잘 작동하니(gpt-4o 이상의 모델), 각자의 프로덕션 환경에서 테스트해보고 관리 가능한 edge case 인지 파악하고 사용하는 것이 좋을 것 같습니다.

이 부분에 대한 생각은 사람마다 많이 다를 것 같습니다. 다른 의견들을 댓글로 남겨주세요!

728x90

'Dev,AI > Langchain' 카테고리의 다른 글

LangChain 시작하기: 기본 LLM 체인 (Prompt + LLM) 이해하기 (3)	2025.08.12

💻 🧐