앤트로픽 클로드 인증 시험: 에이전트 개발 안티패턴으로 성공 전략 제시

프랭크 코일(Frank Coyle)은 앤트로픽의 클로드 인증 아키텍트(Claude Certified Architect) 시험에 대해 설명하며, AI 에이전트 분야 경력에 관심 있는 이들에게 이 시험을 살펴보길 권했습니다. 그는 앤트로픽이 사람들이 시스템을 어떻게 사용하고 어떤 문제가 발생하는지 잘 알고 있다고 강조하며, 시험을 통해 이러한 지식을 습득할 수 있음을 시사했습니다.

이 시험은 단순히 기술적인 지식을 넘어 실제 시스템 사용 시 발생할 수 있는 문제점과 해결책에 대한 앤트로픽의 통찰력이 반영되어 있다고 덧붙였습니다.

프랭크 코일은 자매 카리타 켄트의 인용구 '실수는 없다. 이기고 지는 것도 없다. 오직 만드는 것만 있을 뿐이다.'를 언급하며 실험의 중요성을 강조했습니다. 그는 읽는 것뿐만 아니라 직접 만들고 실행하는 과정을 통해 배우는 것이 중요하다고 말했습니다. 또한, 토마스 에디슨의 '나는 실패한 것이 아니다. 단지 작동하지 않는 1만 가지 방법을 찾았을 뿐이다.'라는 말을 인용하며, 많은 시도가 제대로 작동하지 않을 수 있음을 인정했습니다.

그는 1990년대 객체 지향 프로그래밍의 디자인 패턴 운동을 언급하며, 에이전트 세계에서도 패턴뿐만 아니라 안티패턴이 존재한다고 설명했습니다. 안티패턴을 이해하는 것이 무엇을 하지 말아야 할지 파악하고, 결국 무엇을 해야 할지로 이끄는 핵심이라고 역설했습니다.

클로드 인증 시험은 올해 3월에 출시된 완전히 새로운 시험으로, 시나리오 기반의 문제들로 구성되어 있습니다. 이 시험은 시간이 정해져 있고 감독관이 있는 형태로 진행됩니다. 앤트로픽 에코시스템 내 기업뿐만 아니라, 개인도 99달러를 지불하고 6개월에 한 번씩 응시할 수 있습니다.

시험은 단순히 객관식 문제 은행식이 아니라, 현실적인 제약과 시나리오를 바탕으로 한 객관식 문제들을 통해 응시자의 실제 문제 해결 능력을 평가합니다.

이 시험은 에이전트 아키텍처(27%), 클로드 코드(20%), 프롬프트 엔지니어링, 툴 설계, 모델 컨텍스트, 프로토콜 통합, 컨텍스트 관리, 그리고 신뢰성이라는 다섯 가지 핵심 영역을 다룹니다. 각 영역의 비중 또한 명시되어 있습니다.

프랭크 코일은 이 주제들이 시험 응시 여부와 관계없이 에이전트 개발 분야에서 이해하고 알아야 할 필수적인 지식이라고 강조했습니다. 이 지식들은 에이전트 세상이 던져줄 모든 것에 대비하는 데 도움이 될 것이라고 덧붙였습니다.

클로드 인증 시험은 여섯 가지 생산 시나리오를 제공하며, 그중 네 가지가 무작위로 선택되어 모든 질문이 이 네 가지 시나리오를 중심으로 출제됩니다. 강연자는 이 생산 시나리오들을 소개하고, 각각에서 피해야 할 안티패턴들을 알려줄 것이라고 말했습니다.

문제를 해결하는 다양한 방법이 있지만, 무엇을 하지 말아야 하는지를 이해하는 것이 종종 정답을 맞히는 핵심이 될 수 있기 때문이라고 설명했습니다.

첫 번째 시나리오는 고객 지원 해결 에이전트로, 에이전트 루프에서 `stop_reason`을 제어하는 중요성을 강조했습니다. `stop_reason`은 클로드 코드에서 모든 일이 발생할 때마다 나타나며 많은 정보를 제공합니다. 두 번째는 코드 생성, 세 번째는 다중 에이전트 연구 시스템입니다. 이 시스템에서는 에이전트의 분산, 오케스트레이터의 역할, 정보량 등이 중요한 요소가 됩니다. 네 번째 시나리오는 코드와 함께 개발자 생산성을 높이는 것으로, 하위 작업을 분리하고 작은 우주 안에 유지하는 것이 핵심입니다. 이는 멀티스레드 프로그래밍에서 동기화 문제를 피하기 위해 작은 스레드를 독립적으로 유지하는 것과 유사합니다. 마지막으로 지속적인 통합을 위한 클로드 코드와 구조화된 데이터 추출 패턴을 살펴볼 것이라고 언급했습니다.

프랭크 코일은 보리스 처니와 피터 스타인버거 등 에이전트 개발자들이 루프에 대해 이야기하며 마치 새로운 개념처럼 들리게 하지만, 루프 자체가 새로운 것은 아니라고 설명했습니다. 보리스 처니는 코드를 작성하지 않고 루프를 작성하는 것이 그의 일이라고 말했으며, 오픈 클로드의 피터 스타인버거 역시 더 이상 코딩하지 않고 에이전트를 프롬프트하는 루프를 설계할 뿐이라고 언급했습니다.

이러한 발언들은 루프가 에이전트 개발의 핵심 요소임을 보여주지만, 본질적으로 새로운 개념은 아니라는 점을 시사했습니다.

초기 컴퓨터 프로그래밍 언어들은 더 나은 효율성을 위해 경쟁했지만, 1966년에는 튜링 완전성(turing completeness)을 위해서는 순차적 문장, 조건문, 그리고 루프(loop)라는 세 가지 요소만 있으면 충분하다는 것이 증명되었습니다. 이는 모든 계산 가능한 문제를 해결하는 데 필요한 최소한의 구조를 의미합니다.

이제 에이전트 세계에서 이러한 루프 개념이 다시 부활하여 강력한 기능을 제공하고 있습니다. 프랭크 코일은 이 지점에서 에이전트 기술이 매우 흥미로워진다고 언급하며, 루프가 현대 AI 에이전트 개발의 핵심적인 메커니즘임을 강조했습니다.

에이전트를 단순히 실행시켜 응답을 받는 것은 좋지 않은 안티패턴입니다. 대신 `stop_reason`이라는 메커니즘을 통해 루프를 효과적으로 제어하는 것이 중요합니다. 예를 들어, 모델을 호출하고 메시지를 전달했을 때, LLM이 '도구를 사용하겠다'는 `stop_reason`을 반환하면, 그제야 시스템이 도구를 실행하도록 루프를 진행하는 방식입니다. 중요한 점은 LLM 자체가 도구를 직접 실행하는 것이 아니라, 도구 실행에 필요한 매개변수만 설정해 준다는 것입니다. 이를 통해 개발자는 LLM의 의도를 파악하고 적절한 후속 조치를 취할 수 있습니다. `stop_reason`은 에이전트의 현재 상태와 다음 행동을 결정하는 데 중요한 단서를 제공하므로, 이를 무시하고 단순히 모델의 최종 답변만을 기다리는 것은 비효율적이며 예측 불가능한 결과를 초래할 수 있습니다.

LLM이 특정 도구를 사용하려는 의도를 `stop_reason`으로 전달하면, 에이전트는 해당 도구를 호출하고 결과를 다시 LLM에 전달하여 다음 단계를 진행합니다. 이러한 반복적인 과정을 통해 에이전트는 복잡한 작업을 단계별로 수행하며, 각 단계에서 `stop_reason`을 통해 제어 흐름을 명확하게 유지할 수 있습니다. 이는 에이전트의 동작을 예측 가능하게 만들고, 오류 발생 시 디버깅을 용이하게 합니다. 또한, 불필요한 LLM 호출을 줄여 비용 효율성을 높이는 데도 기여합니다.

`stop_reason`은 에이전트가 답변을 생성했을 때 인간 개입(human in the loop)의 기회를 제공하는 중요한 요소입니다. 에이전트가 내놓은 답변의 신뢰도를 확인하고, 문제가 없을 경우 그대로 사용하며, 그렇지 않을 경우 인간에게 개입을 요청하여 에스컬레이션할 수 있습니다. 이는 에이전트의 한계를 보완하고 최종 결과의 품질을 높이는 데 기여합니다.

또한, `stop_reason` 중 하나로 '토큰 부족(run out of tokens)'이 발생할 수 있습니다. LLM이 토큰이 부족하여 답변을 부분적으로만 생성했을 경우, 에이전트는 이에 대한 적절한 조치를 취해야 합니다. 예를 들어, 추가 토큰을 할당하거나, 컨텍스트를 압축하여 다시 시도하거나, 사용자에게 상황을 알리는 등의 대응이 필요합니다.

앤트로픽의 클로드를 이용한 코드 생성에는 `CLAUDE.md` 파일이라는 개념이 사용됩니다. 이 마크다운 파일에는 에이전트가 코드 생성에 필요한 모든 정보를 담을 수 있습니다. 앤트로픽은 `CLAUDE.md` 파일을 세 가지 레벨로 계층적으로 관리할 것을 권장합니다.

첫째, 프로젝트 최상위 레벨에 파일을 두어 전역적인 규칙을 정의합니다. 둘째, 프로젝트 폴더 내부에 파일을 배치하여 특정 모듈이나 기능에 대한 규칙을 설정합니다. 셋째, 디렉토리별로도 `CLAUDE.md` 파일을 지정하여 더욱 세분화된 제어가 가능합니다. 이러한 계층적 관리는 시스템이 어떻게 응답할지 제어하는 규칙을 효율적으로 적용하기 위함입니다.

멀티 에이전트 연구 시스템에서 하나의 에이전트에 모든 도구를 부여하는 것은 피해야 할 안티패턴입니다. 이는 마치 모든 종류의 도구를 가지고 '무엇이든 할 수 있다'고 말하는 목수를 부르는 것과 같습니다. 대신 우리는 특정 작업을 전문적으로 수행하는 목수를 원합니다. 기능형 프로그래밍(functional programming)의 아이디어와 유사하게, 에이전트도 하나의 일을 전문적으로 수행하고 한두 개의 도구만 사용하도록 설계해야 합니다.

이러한 전문화 전략은 에이전트 시스템의 성공으로 이끄는 길이며, 클로드 인증 시험에서도 중요한 평가 요소가 될 것입니다. 각 에이전트가 특정 역할에 집중하도록 하여 과부하를 방지하고 효율성을 극대화하는 것이 중요하다고 강조했습니다.

에이전트의 컨텍스트(context)가 메인 컨텍스트로 불필요하게 유출되지 않도록 하는 것이 중요합니다. 컨텍스트는 곧 토큰(tokens)의 사용량을 의미하며, 토큰은 직접적으로 비용과 연결되기 때문입니다.

따라서 컨텍스트 관리를 소홀히 하면 불필요한 비용 발생으로 이어질 수 있으므로, 에이전트 설계 시 컨텍스트 유출을 최소화하는 방안을 고려해야 합니다.

컨텍스트의 양이 많아질수록 LLM(Large Language Model)은 답변을 생성할 때 더 혼란스러워질 수 있습니다. 설령 백만 토큰에 달하는 방대한 컨텍스트 창이 제공되더라도, 모든 정보를 무작정 넣는 것이 능사는 아닙니다. 오히려 이는 LLM의 집중력을 흐트러뜨리고 정확성을 저해할 수 있습니다.

따라서 LLM에 입력하는 컨텍스트의 내용을 필요한 범위 내에서 제한해야 훨씬 더 정확하고 신뢰할 수 있는 시스템을 구축할 수 있습니다. 불필요한 정보는 노이즈로 작용하여 LLM의 판단을 흐리게 할 수 있기 때문입니다.

많은 에이전트들이 함께 협력하고 대화하는 시스템에서는 '집단사고(groupthink)'가 발생할 경향이 있습니다. 이는 모든 에이전트들이 특정 한 가지 아이디어로 수렴되는 현상을 의미합니다. 마치 파티에서 모두가 피자를 원할 때 자신은 원하지 않아도 분위기에 동조하게 되는 것과 유사하게, 에이전트들도 이와 비슷한 방식으로 작동할 수 있습니다.

이러한 집단사고를 방지하기 위해서는 각 에이전트에게 각자의 역할에 필요한 최소한의 정보만을 제공해야 합니다. 모든 에이전트가 모든 정보를 공유하게 되면, 독립적인 사고와 다양한 관점의 생성이 어려워져 시스템 전체의 효율성과 창의성이 저해될 수 있습니다.

개발자 생산성을 저해하는 안티패턴 중 하나는 모든 서브태스크(subtask)의 전체 출력을 주 스레드(main thread)에 그대로 덤프하는 것입니다. 이러한 방식은 주 스레드의 컨텍스트를 과도하게 압도하여 LLM(Large Language Model)의 성능을 저해합니다.

컨텍스트가 무제한으로 커지도록 두는 것은 좋지 않으며, 이는 앞에서 논의된 여러 이유들로 인해 비효율적입니다. 따라서 서브태스크 출력을 격리하고, 긴 세션의 내용을 압축하여 관리해야 합니다.

컨텍스트 오염을 방지하기 위한 서브태스크 처리 패턴은, 특정 작업을 수행하는 에이전트가 메인 컨텍스트를 오염시키지 않도록 별도의 스레드로 포크하는 것입니다. 예를 들어, 에이전트가 로그를 검토하고 문제점을 요약하는 작업을 수행한다고 가정해 봅시다. 이 경우 에이전트는 오류 컨텍스트를 위해 모든 로그를 스캔하는 작업을 독립적으로 진행합니다.

이때 에이전트가 무엇을 하든, 생각하든, 토큰을 추가하든 그것이 메인 컨텍스트에 직접적인 영향을 주지 않도록 격리합니다. 그리고 작업이 완료된 후에는 모든 로그 내용 대신, 에이전트가 생성한 요약본만 가져와 최상위 컨텍스트에 추가합니다. 이 방법은 컨텍스트를 간결하게 유지하고 LLM의 효율성을 높이는 데 기여합니다.

에이전트 시스템에서 토큰 수를 지속적으로 확인하고 특정 한도를 설정하는 것이 중요합니다. 예를 들어, 토큰이 15만 개를 넘으면 컨텍스트 압축을 실행하는 로직을 적용할 수 있습니다. 앤트로픽과 클로드(Claude)는 이러한 거대한 컨텍스트를 효율적인 형태로 압축하는 자체 알고리즘을 제공합니다.

비록 내부 구현 방식은 명확히 알려져 있지 않지만, 이러한 압축 기능을 활용하면 방대한 양의 정보를 처리하면서도 토큰 비용을 절감하고 LLM의 성능을 유지할 수 있습니다. 이는 컨텍스트 창의 한계를 극복하고 장기적인 대화나 복잡한 작업을 지원하는 데 필수적입니다.

Sam Bwata의 책 'LLM'에 따르면, 그의 회사는 컨텍스트 압축을 위한 커스텀 로직을 제공합니다. 이는 개발자가 자신만의 로직을 작성하여 컨텍스트를 압축할 수 있음을 의미합니다. 기본 클래스를 확장하고, 자신에게 중요하다고 생각하는 방식으로 데이터 압축을 구현함으로써, LLM에 전달되는 정보의 양과 질을 최적화할 수 있습니다.

이러한 커스텀 로직은 특정 애플리케이션의 요구사항에 맞춰 중요한 데이터만을 효율적으로 유지하고, 불필요한 정보는 제거하여 토큰 비용을 절감하고 LLM의 정확도를 높이는 데 기여합니다.

지속적 통합/지속적 배포(CI/CD) 파이프라인에서 클로드(Claude) 코드를 사용할 때 안티패턴은 항상 대화형 모드를 사용하는 것입니다. 대화형 모드는 클로드가 작업을 진행하다가 멈춰서 '이것을 하시겠습니까, 저것을 하시겠습니까, 허락해 주시겠습니까?'와 같이 사용자에게 질문하여 파이프라인의 흐름을 중단시키는 경향이 있습니다.

CI/CD 파이프라인은 자동화된 프로세스를 통해 중단 없이 연속적으로 실행되어야 하므로, 이러한 대화형 모드는 심각한 병목 현상을 유발합니다. 따라서 파이프라인에서는 클로드가 곧바로 실행되도록 설정하는 일괄(batch) 모드를 사용해야 합니다. 일괄 모드를 통해 사용자 개입 없이 작업을 완료할 수 있도록 설정하는 다양한 방법이 존재합니다.