Scarab Diagnostic Suite 현장 테스트 #011: LangChain 구조화된 출력 (Structured Output) 스트리밍

이번 현장 테스트는 LangChain을 대상으로 진행되었습니다.

문제는 LangChain #34818이었습니다:

https://github.com/langchain-ai/langchain/issues/34818

보고된 문제는 구조화된 출력 (Structured Output)이 활성화되었을 때 에이전트 스트리밍 (Agent Streaming)의 동작이 달라진다는 것이었습니다.

구조화된 출력이 없을 때, 에이전트는 도구 (Tool)를 호출하기 전에 자연어 (Natural Language)를 스트리밍할 수 있었습니다.

ToolStrategy를 통해 구조화된 출력을 활성화하면, 해당 중간 텍스트가 사라졌습니다.

이는 다음과 같은 일반적인 에이전트 경험을 깨뜨리기 때문에 중요합니다:

“지금 바로 확인해 보겠습니다...”

(도구 호출)

“찾은 결과는 다음과 같습니다...”

(최종 답변)

가시적인 증상은 다음과 같았습니다:

구조화된 출력이 중간 스트리밍을 차단함

하지만 유용한 진단 경계는 더 좁았습니다:

중간 에이전트 스트림 vs 최종 구조화된 출력 강제 적용

이것들은 에이전트 생명주기 (Lifecycle) 내에서 서로 다른 시점입니다.

중간 에이전트 턴 (Turn)은 도구 호출 전에 자연어를 스트리밍해야 할 수도 있습니다.

최종 답변은 구조화된 스키마 (Structured Schema)로 제한될 필요가 있습니다.

이 두 가지 요구 사항이 반드시 동일한 턴을 점유해야 하는 것은 아닙니다.

로컬 수정 후보 (Local Repair Candidate)는 ToolStrategy 경로에만 집중했습니다.

이는 LangChain의 스트리밍을 재설계하는 것이 아닙니다.

모든 구조화된 출력 동작을 변경하는 것도 아닙니다.

설계상 더 민감한 ProviderStrategy에는 손을 대지 않습니다.

이 수정은 최종 구조화된 출력 보호 기능을 온전하게 유지하면서도, 실제 도구를 사용할 수 있는 첫 번째 모델 턴에서 구조화된 출력 도구 선택을 너무 일찍 강제하는 것을 방지합니다.

쉽게 말해:

실제 도구 호출 전에는 에이전트가 에이전트답게 행동하도록 두십시오.

그다음, 최종 구조화된 답변을 생성해야 할 시점에 구조화된 출력을 강제하십시오.

집중된 회귀 테스트 (Regression Test)를 통해 수정 전의 실패를 증명하고, 수정 후의 통과를 확인했습니다.

또한 관련 응답 형식 (Response-format) 테스트, 에이전트 스트리밍 테스트, 포맷팅, 타입 체크 (Type Checking), 그리고 차이 검사 (Diff Checks)를 통해서도 검증을 통과했습니다.

현장 테스트 #011

• 프로젝트 (Project): LangChain
• 이슈 유형 (Issue type): 에이전트 스트리밍 (agent streaming) / 구조화된 출력 (structured output) 동작
• 경계 (Boundary): 중간 에이전트 스트림 (intermediate agent stream) vs 최종 구조화된 출력 강제 (final structured-output enforcement)
• 결과 (Result): 국소적인 ToolStrategy 수정 후보 및 회귀 테스트 (regression test) 도출
• 상태 (Status): PR (Pull Request) 전 이슈 스레드 댓글 권장

이번 현장 테스트의 중요한 부분은 수정(repair)의 형태입니다.

광범위한 증상은 다음과 같았습니다:

구조화된 출력이 스트리밍을 깨뜨림

더 좁은 수정 경계는 다음과 같았습니다:

구조화된 출력 강제가 한 턴 너무 일찍 소유권(ownership)을 가져감

이는 매우 다른 진단입니다.

이것은 수정 작업이 구조화된 출력을 약화시킬 필요가 없음을 의미합니다.

에이전트 스트리밍 (agent streaming)을 다시 작성할 필요도 없습니다.

모든 전략을 변경할 필요도 없습니다.

단지 첫 번째 실제 도구 사용 턴 (first real-tool turn)과 최종 구조화된 출력 턴 (final structured-output turn) 사이의 경계를 존중하기만 하면 됩니다.

이것이 이러한 현장 테스트들로부터 나타나고 있는 더 큰 패턴입니다.

Scarab Diagnostic Suite는 코드베이스가 스스로의 진실(truth)로부터 벗어나지 않도록 하면서 AI로 개발하기 위한 방법으로 시작되었습니다.

AI 에이전트는 빠르게 움직일 수 있지만, 빠른 코드가 곧 진실된 코드와 같은 것은 아닙니다. 리포지토리 (repo)에는 경계가 있습니다. 소유권 규칙 (ownership rules)이 있습니다. 계약 (contracts)이 있습니다. 진실이 머물러야 하는 장소들이 있습니다.

하지만 이러한 현장 테스트들은 더 광범위한 무언가를 보여주고 있습니다:

소프트웨어 시스템 또한 표류 (drift)한다는 것입니다.

단순히 AI뿐만이 아닙니다.

개발자도 표류합니다.

팀도 표류합니다.

성숙한 플랫폼도 표류합니다.

많은 까다로운 소프트웨어 버그들은 시스템의 한 부분은 여전히 하나의 진실 아래에서 작동하고 있는 반면, 다른 부분은 이미 다른 진실을 따르기 시작한 지점에서 발생합니다.

이번 현장 테스트에서 표류는 타이밍과 소유권 문제였습니다:

에이전트가 중간 도구 사용 단계 (intermediate tool-use step)를 완료하기 전에, 구조화된 출력 경로가 최종 답변 동작 (final-answer behavior)을 강제하기 시작했습니다.

이것이 바로 Scarab이 표면화하기 위해 구축된 종류의 경계입니다.

경계가 구체적이기 때문에 수정 범위는 작습니다.

그렇다고 해서 그것이 약한 수정이라는 뜻은 아닙니다.

그것을 더 안전하게 만듭니다.

많은 확산되는 소프트웨어 문제들은 타이밍 (timing), 소유권 (ownership), 또는 진실 (truth)이 잘못된 경계를 가로지르는 단 한 곳의 정확한 지점에서 시작됩니다.

그 지점을 찾아낸다면, 수리 범위는 증상이 시사하는 것보다 훨씬 작을 수 있습니다.