요즘 AI 에이전트를 보면 여러 모델이 기획하고, 개발하고, 서로의 결과를 검토한다. 각자 역할을 나눈 가상의 팀이 사람처럼 협업하는 모습은 꽤 인상적이다. 하지만 이렇게 만든 데모가 잘 동작한다는 사실로 이 구조가 실제 업무에도 적합하다고 말하기는 어렵다.
실 환경에서는 결과의 정확도외에 비용, 응답 시간, 오류 추적, 권한 관리도 함께 고려해야 한다. 에이전트가 많아지면 각 역할을 정의하고, 작업을 나누고, 결과를 합치는 과정도 설계해야 한다. 이 과정이 작업의 품질을 높일 수도 있지만, 전달 과정에서 정보가 빠지거나 잘못 해석될 가능성도 존재한다.
실무에서 중요한 것은 '단일 에이전트와 멀티 에이전트 중 무엇이 더 좋은가?'가 아니라, 어떤 업무에서 추가적인 에이전트가 실제로 더 나은 결과를 만드는가?라고 생각한다.
복잡한 구조가 항상 더 나은 결과를 만들진 않는다.
멀티 에이전트 구조에는 장점이 분명히 있다. 서로 독립적인 하위 작업을 병렬로 처리하거나, 서로 다른 전문 지식과 도구를 분리해 관리할 수 있다. 한 에이전트에 너무 많은 도구와 맥락을 넣으면 성능이 떨어지는 문제를 줄이는데도 도움이 된다.
반면 작업이 순차적으로 이어지고, 각 단계의 결과가 다음 단계에 필요한 경우에는 조율 비용이 커질 수 있다. 앞 단계의 요약이나 판단이 다음 에이전트에게 전달되는 과정에서 조건이 누락되거나 의미가 바뀔 수 있기 때문이다. 에이전트가 만든 결과를 다시 다른 에이전트가 검토한다고 해서 오류가 자동으로 사라지는 것도 아니다. 잘못된 전제가 여러 단계에서 그대로 받아들여지면 오류가 이어질 수 있다.
그러나 이를 근거로 멀티 에이전트 전체를 실패한 방식이라고 단정할 순 없다.
Anthropic은 에이전트를 쓰지 말라고 얘기하진 않는다.
Anthorpic의 Building Effective Agents가 강조하는 핵심은 단순하다. 처음부터 복잡한 에이전트 시스템을 만들기보다, 가장 단순한 해법에서 출발하고 성능 개선이 확인될 때 복잡성을 더하라는 것이다.
정해진 순서대로 처리할 수 있는 업무라면 코드가 전체 흐름을 통제하는 워크플로우가 예측이 가능하다. 반대로 필요한 작업 순서를 미리 정하기 어렵고, 환경을 관찰하며 다음 행동을 선택해야 한다면 에이전트의 자율성이 유용할 수 있다. 단일 LLM 호출에 검색이나 예시를 보태는 것으로 해결되는 문제도 있다.
따라서 실무적인 출발점은 “단일 에이전트만 사용하자”가 아니라 다음과 같다.
- 먼저 기존 코드와 규칙으로 해결할 수 있는지 살핀다.
- 부족한 부분에 LLM 호출이나 도구 사용을 추가한다.
- 단계가 불명확하고 판단이 필요한 작업에 에이전트를 적용한다.
- 작업을 나누거나 병렬 처리할 때 이점이 확인되면 멀티 에이전트 구조를 검토한다.
이 순서는 단일 에이전트가 언제나 우월하다는 뜻이 아니다. 시스템의 복잡성을 성능/비용/운영 이점으로 정당화하자는 뜻이다.
에이전트의 성능은 모델만으로 결정되지 않는다.
에이전트가 일을 잘 수행하려면 모델 외에도 작업 환경과 도구가 중요하다. 파일을 읽고 쓰는 방법, 명령을 실행할 수 있는 범위, 오류가 났을 때 받는 피드백이 성능과 안전성에 영향을 준다.
Anthropic은 도구의 입력과 출력 그리고 사용 조건을 명확히 설계하고 실제 사용을 반복해서 평가할 것을 권한다. 자율적으로 동작하는 시스템에는 비용과 오류가 누적될 여지가 있으므로, 반복 횟수에 제한을 두고 샌드박스와 안전장치를 마련하는 것도 중요하다.
예를 들어 코드를 수정하는 에이전트라면 “코드를 작성하라”는 지시만으로는 부족하다. 수정 가능한 디렉터리를 제한하고, 테스트 명령을 정해두며, 실패 로그를 에이전트가 확인하게 해야 한다. 반대로 실제로 실행되지 않는 검증 절차를 완료 기준에 적어두면, 문서는 그럴듯해도 품질은 보장되지 않는다.
SKILL.md 는 매뉴얼이면서 실행 자료를 연결하는 형식이다.
최근에는 업무 절차와 참고자료, 실행 스크립트를 에이전트가 필요할 때 불러 쓸 수 있도록 묶는 방식이 쓰인다.
Agent Skills의 SKILL.md가 그 예시다. 이 표준에서 스킬은 SKILL.md를 포함한 디렉터리이며, 필요한 경우 관련 문서나 스크립트도 함께 둘 수 있다. 파일에는 스킬의 이름과 사용 시점을 설명하는 메타데이터가 들어간다.
이 방식의 장점은 지침을 한 번에 모두 읽지 않아도 된다는 데 있다.
에이전트가 작업에 맞는 스킬을 선택하고, 필요한 세부 자료를 더 불러올 수 있다.
다만 SKILL.md가 에이전트의 정확성을 보장하는 것은 아니다. 지침이 모호하거나 오래됐을 수 있고, 설명만으로 실제 실행이 통제되는 것도 아니다.
그래서 스킬에는 역할 선언만 넣기보다, 업무에 필요한 절차와 예외, 사용할 도구, 완료 조건을 실제 운영 환경에 맞게 적어야 한다. 실행 가능한 부분은 스크립트나 프로그램 코드로 분리할 수 있다. SKILL.md는 시스템 전체를 대신하는 만능 프롬프트라기보다, 에이전트가 필요한 지식과 절차를 찾아 쓰도록 돕는 작업 안내서에 가깝다.
검증 가능한 완료 기준을 먼저 정한다.
에이전트가 결과를 냈다는 사실과 작업이 끝났다는 사실은 다르다. 코드 작업이라면 테스트와 정적 분석, 문서 작업이라면 형식 검사와 필수 항목 확인처럼 결과를 판정할 기준이 필요하다.
이 기준을 자동화할 수 있으면 에이전트는 실패 결과를 보고 다시 시도할 수 있다. 다만 재시도 횟수와 실행 권한은 통제해야 한다. 모든 작업을 무인 자동화로 끝내야 하는 것도 아니다. 비용이 크거나 되돌리기 어려운 조치에는 사람의 승인을 남겨두는 편이 안전하다.
좋은 검증 루프는 단순히 “테스트 100% 통과”를 선언하는 데 그치지 않는다. 테스트가 실제 요구사항을 검증하는지, 테스트 자체가 부족한 조건을 빠뜨리지 않았는지까지 살펴야 한다. 자동 검증은 사람의 판단을 전부 없애기 위한 장치가 아니라, 반복적으로 확인할 수 있는 품질 기준을 실행하는 방법이다.
결론: 단순한 구조에서 시작하고, 근거를 보며 확장하기
멀티 에이전트는 끝난 유행이라기보다, 잘 맞는 문제와 그렇지 않은 문제가 분명한 설계 선택지다. 병렬화가 중요한 리서치나 서로 구분되는 전문 업무에서는 여러 에이전트가 효과적일 수 있다. 반면 흐름이 명확한 업무라면 프로그램 코드와 단일 에이전트만으로 더 이해하기 쉽고 관리하기 쉬운 시스템을 만들 수 있다.
SKILL.md도 마찬가지다. 잘 정리된 작업 지침은 에이전트의 행동을 일관되게 하는 데 도움이 되지만, 도구의 권한 통제나 테스트를 대신하지는 않는다. 운영 가능한 시스템은 지침, 실행 환경, 도구, 검증 기준이 함께 맞물려야 한다.
결국 중요한 것은 에이전트의 수가 아니다. 작업을 얼마나 명확히 정의했는지, 실패를 얼마나 쉽게 발견하는지, 그리고 추가된 복잡성이 측정 가능한 이점을 주는지다.
가장 좋은 아키텍처는 가장 화려한 구조가 아니라, 실제 업무에서 결과를 내고 그 결과를 확인할 수 있는 구조다.
Sources:
0 Comments:
댓글 쓰기