LangChain에서 에이전트 A가 에이전트 B에게 작업을 위임합니다. 에이전트 B가 실패합니다. 하지만 에이전트 A의 콜백 체인은 어쨌든 '성공(success)'을 발생시킵니다.

이것은 대부분의 빌더들이 에이전트 워크플로우(agentic workflows)에서 놓치는 관측 가능성(observability)의 사각지대인 **위임 마스킹 (delegation masking)**입니다. 서브 에이전트(sub-agent)는 조용히 실패하지만, 부모 에이전트의 콜백 레이어는 위임된 에이전트가 실제로 무엇을 했는지가 아니라 위임된 _호출(call) 자체_만을 감시하기 때문에 이를 알지 못합니다.

그 메커니즘을 살펴보겠습니다.

LangChain의 위임 패턴 (The Delegation Pattern in LangChain)

LangChain에서 에이전트 간 위임을 연결할 때, 일반적으로 tool 데코레이터를 사용하여 서브 에이전트 호출을 래핑(wrap)합니다:

@tool
def delegate_to_classification_agent(task: str) -> str:
    """분류 작업을 전문 서브 에이전트에게 위임합니다."""
...

부모 에이전트는 이를 단순히 또 다른 도구(tool)로 취급합니다. 호출하고, 결과를 받고, 다음 단계로 넘어갑니다. 부모 에이전트의 콜백 체인(성공/실패를 기록하고, 알림을 발생시키며, 지연 시간(latency)을 측정하는 레이어)은 서브 에이전트의 내부 상태가 아니라 **함수 반환 값(function return value)**만을 봅니다.

실패가 숨어있는 곳

다음과 같은 일이 발생할 수 있습니다:

1. 에이전트 B (서브 에이전트)가 유효한 출력을 생성하는 데 실패합니다. 내부 체인이 끊어지거나, 도구 호출(tool call)이 실패하거나, 출력 파싱(output parsing)이 깨지거나, LLM이 응답하지 않을 수 있습니다. 에이전트 B의 콜백 체인은 이 실패를 기록합니다.

2. 하지만 위임 함수는 여전히 무언가를 반환합니다. 빈 문자열, 캐시된 폴백(fallback), 또는 일반적인 에러 메시지를 반환할 수 있습니다. 예외(exception)를 발생시키지 않고 그냥 반환하는 것입니다.

3. 에이전트 A의 콜백 레이어는 HTTP 200을 봅니다. 위임 도구가 _무언가_를 반환했으므로, 콜백은 status: "success"와 함께 on_tool_end를 발생시킵니다. 부모 에이전트는 성공을 기록하고 다음 단계로 넘어갑니다.

4. 실제 실패는 두 단계 아래에 묻혀 있습니다. 에이전트 A의 모니터링은 "위임 성공"을 확인합니다. 누군가가 에이전트 B의 로그를 파헤쳐 보아야만 실패가 드러납니다.

이것이 바로 **콜백 가시성 경계 (callback visibility boundary)**입니다. 부모 에이전트의 계측(instrumentation) 레이어는 위임 실패를 포착하기에는 한 단계 너무 높게 위치해 있습니다.

이를 포착하는 신호

표준적인 토큰 카운팅 관측성 (Observability)은 이를 놓치게 됩니다. 왜냐하면 두 에이전트 모두 부분적인 토큰 사용량을 보고할 수 있기 때문입니다 (에이전트 B가 시작되어 일부 토큰을 소모한 후 실패한 경우). 성공 콜백 (Success callback)이 실행되었으므로, 지표 (Metrics)는 정상적으로 보입니다.

위임 실패를 실제로 포착하는 방법은 다음과 같습니다:

1. 위임 경계에서의 출력 검증 (Output validation)

위임 함수가 _실제로 반환한 것_을 추적하십시오:

@tool
def delegate_to_agent(task: str) -> str:
    """관측성을 포함하여 위임합니다."""
...

신호는 다음과 같습니다: 빈 값이나 변경되지 않은 입력을 반환한 위임입니다. 부모 에이전트의 콜백 (Callback)은 "성공"을 보지만, 관측성 (Observability)은 무언가 잘못되었음을 알고 있습니다.

2. 에이전트 간 실행 상관관계 (Cross-agent execution correlation)

에이전트 A가 에이전트 B를 호출할 때, 두 에이전트의 실행 트레이스 (Execution traces)를 연결하는 **상관관계 ID (Correlation ID)**를 로그에 남기십시오:

import uuid

correlation_id = str(uuid.uuid4())
...

이제 다음과 같이 쿼리할 수 있습니다: "상관관계 ID (correlation_id)는 있지만 빈 출력이나 에러 상태를 보이는 서브 에이전트 실행은 무엇인가?" 바로 그곳에 위임 실패가 숨어 있습니다.

3. 에이전트 쌍별 집계 성공률 (Aggregate success rate per agent pair)

단순히 에이전트별이 아니라, **위임 경계 (Delegation edge)**에서의 성공률을 추적하십시오:

delegation_success_rate = (
    parent_agent=A 이고 delegated_agent=B 이며 output_validation_passed 인 실행 횟수
) / (parent_agent=A 이고 delegated_agent=B 인 총 실행 횟수)

만약 에이전트 A에서 에이전트 B로의 위임이 부모 로그에서는 95%의 성공률을 보이지만, 출력 검증 (Output validation)을 통과한 비율은 70%뿐이라면, 콜백 마스킹 (Callback masking) 현상을 발견한 것입니다.

프레임워크가 이를 포착하지 못하는 이유

LangChain의 콜백 (Callback) 레이어는 호출된 에이전트의 내부 상태가 아니라, 호출하는 에이전트의 관점을 계측 (Instrument)하도록 설계되었습니다. 이는 설계 의도이며, 관심사의 깔끔한 분리 (Separation of concerns)입니다. 하지만 이는 위임 실패가 전파될 때까지 (혹은 전파되지 않을 때까지) 보이지 않는다는 것을 의미합니다.

대부분의 프레임워크가 동일한 경계를 가지고 있습니다. CrewAI의 작업 위임 (Task delegation), AutoGen의 서브 에이전트 호출 (Sub-agent calls) 모두 호출된 에이전트가 실제로 무엇을 했는지와 상관없이, _호출 자체_가 성공하면 성공 콜백 (Success callback)을 실행합니다.

관측성 해결책 (The Observability Fix)

당신은 한 단계 더 깊은 계층이 필요합니다:

1. 서브 에이전트 (sub-agents)를 독립적으로 계측 (Instrument) 하세요. 그들의 실행 상태, 출력 유효성 (output validity), 토큰 사용량 (token usage)을 기록하세요. 무슨 일이 일어났는지 알기 위해 부모 에이전트의 콜백 (callback)에만 의존하지 마세요.

2. 위임 출력 (delegation outputs)을 검증하세요. 위임 함수 (delegation function)가 값을 반환한다고 해서 서브 에이전트가 실제로 성공했다고 믿지 마세요. 출력을 확인하세요.

3. 에이전트 간의 상관관계 (Correlate)를 설정하세요. 부모 에이전트와 자식 에이전트의 실행을 연결하여, 실패가 로그에서 아래로만 흐르는 것이 아니라 관측성 대시보드 (observability dashboard) 상에서 위로 전파되도록 하세요.

콜백 체인 (callback chain)은 필수적이지만, 그것만으로는 충분하지 않습니다. 위임 가시성 (Delegation visibility)을 확보하려면 경계의 양쪽 측면을 모두 확인해야 합니다.

핵심 요약 (The takeaway): 에이전트가 다른 에이전트에게 작업을 위임할 때, 콜백의 성공이 곧 실행의 성공을 의미하지는 않습니다. 표준 모니터링은 침묵을 유지하는데, 이는 부모 에이전트의 콜백이 위임 호출 (delegation call)만 볼 뿐, 위임된 에이전트의 실제 작업은 보지 못하기 때문입니다. 출력을 검증하고, 에이전트 간의 실행을 상관 분석하며, 위임 경계 (delegation edge)에서의 성공률을 측정함으로써 이 문제를 포착하세요.