AI 서브 에이전트를 위한 단일 책임 원칙 (Single Responsibility Principle)

빠른 답변: 멀티 에이전트 (multi-agent) AI 시스템을 구축할 때, 광범위한 책임을 가진 인간 페르소나 (persona)를 할당하는 것은 함정입니다. 대신, 단일 책임 원칙 (single-responsibility principle)을 적용하세요. 복잡한 작업을 전용 파일 검색기나 격리된 코드 작성기와 같이 고도로 집중된 서브 에이전트 (sub-agents)로 분해함으로써, 컨텍스트 고갈 (context exhaustion)을 줄이고 디버깅을 훨씬 더 쉽게 만들 수 있습니다.

저는 AI 서브 에이전트를 설계할 때 우리가 빠지기 쉬운 함정을 발견했습니다. 우리는 에이전트를 사람처럼 상상하는 경향이 있습니다. 에이전트 파일을 작성할 때, 자연스럽게 직함을 부여하고 싶은 유혹을 느낍니다. 예를 들어 "전문 풀스택 개발자 (expert full-stack developer)"와 같은 페르소나를 할당하고, 그 단일 엔티티가 코드베이스 검색부터 최종 구현 작성까지 모든 것을 처리하기를 기대할 수 있습니다. 하지만 저는 그러한 사고방식이 우리의 발목을 잡는다고 생각합니다. 에이전트는 일반화된 인간의 정체성이 아니라, 단일한 책임을 가질 때 가장 잘 작동합니다.

왜 다목적 AI 에이전트는 복잡한 작업에서 실패하는가?

다목적 에이전트가 실패하는 이유는 대규모 언어 모델 (LLM)이 중첩된 책임 사이에서 컨텍스트 (context)와 주의력 (attention)을 유지하는 데 어려움을 겪기 때문입니다. 에이전트에게 여러 유형의 작업을 동시에 수행하도록 강요하면, 필연적으로 컨텍스트 윈도우 (context window)가 고갈되고, 초기 지침을 놓치며, 부정확한 출력을 생성하게 됩니다.

표준 백엔드 애플리케이션을 구축한다고 가정해 봅시다. 데이터베이스 마이그레이션 (database migrations), 사용자 인증 (user authentication), 외부 API 파싱 (parsing external APIs)을 모두 동일한 프로세스에서 직접 처리하는 단일 모놀리식 (monolithic) 함수를 배포하지는 않을 것입니다. 이는 확장하고 유지 관리하기에 악몽이 됩니다. AI에도 동일한 논리가 적용됩니다. 제가 에이전트에게 파일 시스템을 탐색하고, 더 넓은 아키텍처 컨텍스트를 이해하며, 동시에 정확한 구문 변경 사항을 출력하도록 기대할 때, 저는 LLM에 모놀리스 (monolith)를 강요하고 있는 것입니다.

여기서 발생하는 기술적 병목 현상은 어텐션 메커니즘 희석 (attention mechanism dilution)입니다. 만약 "코딩 에이전트 (coding agent)"가 디렉토리를 검색(grep)하는 방법, 비즈니스 로직을 분석하는 방법, 그리고 Python 출력을 포맷팅하는 방법까지 상세히 담긴 시스템 지침을 가지고 있다면, 프롬프트는 과부하 상태가 됩니다. LLM은 어떤 행동을 취할지 결정하는 것과 그 행동을 어떻게 잘 실행할 것인지 사이에서 어텐션 (attention)을 나누어야만 합니다.

서브 에이전트에 단일 책임 원칙 (Single Responsibility Principle)을 어떻게 적용할까요?

단일 책임 원칙을 적용하려면 인간의 페르소나 (persona)를 제거하고 원자적 기능 (atomic functions)에 완전히 집중해야 합니다. 일반적인 "코딩 에이전트"를 만드는 대신, 검색, 분석, 작성을 완전히 격리된 단계로 처리하는 개별적인 서브 에이전트들을 설계하는 것입니다.

이는 한 가지 일을 잘 수행하는 도구를 만들라는 고전적인 유닉스 철학 (Unix philosophy)과 매우 유사합니다. 하나의 에이전트에게 방대한 도구 세트를 주는 대신, 저는 작업을 별개의 연산으로 분해합니다.

광범위한 페르소나를 매우 효과적이고 단일 목적을 가진 서브 에이전트로 재구성하는 방법은 다음과 같습니다:

전통적인 페르소나	작업 기반 서브 에이전트	핵심 책임
"풀스택 코더 (Full-Stack Coder)"	파일 검색기 (File Searcher)	디렉토리를 빠르게 스캔하고 특정 쿼리와 관련된 파일 경로만을 검색함.
...

이러한 집중된 에이전트들 사이에 상태 (state)를 전달함으로써 컨텍스트 윈도우 (context window)를 타이트하게 유지할 수 있습니다. 상태 그래프 (state graph) 패턴을 사용한다면, 라우팅 (routing) 로직은 단순하고 모듈화된 상태로 유지됩니다:

def code_update_workflow(state):
    # 1. 검색기가 엄격하게 관련 파일 경로를 찾음
    paths = file_searcher_agent.invoke(state.query)
...

레이저처럼 집중된 AI 서브 에이전트의 기술적 장점은 무엇인가요?

레이저처럼 집중된 서브 에이전트는 디버깅을 단순화하고 컨텍스트 고갈 (context exhaustion)을 방지하는, 재사용성이 높고 모듈화된 빌딩 블록 (building blocks)을 제공합니다. 범위가 제한되어 있기 때문에, 이들은 개별 작업에서 탁월한 성능을 발휘하며, 실패하더라도 예측 가능하고 추적 가능한 방식으로 실패합니다.

범용 에이전트 (generalized agent)를 디버깅하는 것은 악명 높을 정도로 어렵습니다. 만약 저의 "전문 개발자 에이전트 (expert developer agent)"가 잘못된 코드를 작성한다면, 저는 어디에서 문제가 발생했는지 추측해야만 합니다. 잘못된 디렉토리를 검색했나요? 기존 로직을 오해했나요? 아니면 단순히 구문 (syntax)을 틀렸나요?

이러한 책임들을 서브 에이전트 (sub-agents)로 분리하면 관찰 가능성 (observability)이 향상됩니다. 저는 file_searcher_agent의 출력을 보고 어떤 파일들을 검색했는지 정확히 확인할 수 있습니다. 만약 검색된 파일들이 정확한데 코드만 틀렸다면, file_analyzer_agent나 file_writer_agent가 실패했다는 것을 알 수 있습니다. 거대하고 취약한 시스템 프롬프트 (system prompt)를 다시 작성할 필요 없이, 격리된 단계에 해당하는 특정 프롬프트만 미세 조정하면 됩니다. 결과적으로 거의 모든 워크플로우 (workflow)에 끼워 넣을 수 있는 범용적인 능력을 갖춘 서브 에이전트들을 얻게 됩니다. 이는 제가 더 깊이 파고들어 보고 싶은 아키텍처적 전환 (architectural shift)입니다.

자주 묻는 질문 (Frequently Asked Questions)

여러 개의 단일 작업 서브 에이전트를 어떻게 오케스트레이션 (orchestrate) 하나요?

메인 라우팅 에이전트 (main routing agent) 또는 상태 그래프 프레임워크 (state graph framework)를 사용하여 오케스트레이션합니다. 오케스트레이터는 워크플로우 실행을 관리하며, 한 서브 에이전트의 특정 출력(예: 파일 경로 목록)이 다음 에이전트의 직접적인 입력이 되도록 보장함으로써 각 에이전트의 컨텍스트 (context)를 완전히 격리된 상태로 유지합니다.

작업을 서브 에이전트로 나누면 API 비용이 증가하나요?

여러 번의 API 호출 사이에 컨텍스트를 주고받아야 하므로 토큰 사용량이 증가할 수 있습니다. 하지만 저는 이러한 비용이 일반적으로 단일 구조의 에이전트 (monolithic agent)가 집중력을 잃었을 때 발생하는 재시도 (retries), 오류 루프 (error loops), 그리고 낭비되는 토큰의 감소로 인해 상쇄된다는 것을 발견했습니다.

서브 에이전트의 프롬프트는 실제로 얼마나 세밀해야 하나요?

프롬프트는 에이전트가 단 하나의 명확한 목표와 출력 형식만을 갖도록 충분히 구체적이어야 합니다. 만약 시스템 프롬프트에서 "파일이 존재하면 분석하고, 그렇지 않으면 다시 검색하라"와 같은 조건문 (conditionals)을 사용하고 있다면, 해당 작업은 너무 광범위한 것이며 분리되어야 합니다.