Anthropic의 효율적인 에이전트 개발(4)-실전에서의 에이전트 활용

고객들과 협업한 결과, 앞서 소개한 패턴들이 실제로 AI 에이전트의 실용적인 가치를 잘 보여주는 두 가지 유망한 활용 사례를 확인할 수 있었다. Coding Agent 와 Computer Use 사례는 대화와 실행이 모두 필요한 과업, 명확한 성공 기준, 피드백 루프의 가능성, 그리고 의미 있는 인간의 감독이 통합되어 있는 과업 등 에이전트가 가장 큰 가치를 창출함을 보여준다. 이에 실전에서의 에이전트 활용하는 사례에 대해 노트에 기록한다.

1. 고객 지원 (Customer Support)

• 기존의 챗봇 인터페이스에도구(tool) 통합을 통해 강화된 기능을 결합한 형태 보다 개방적인 에이전트 구조에 자연스럽게 어울리는 사례

  • 고객 지원은 대화 흐름을 따르며, 외부 정보 및 실행 작업 접근이 필요함
  • 고객 데이터, 주문 내역, 지식 베이스 문서 등을 가져오는 도구를 통합할 수 있음
  • 환불 처리, 티켓 업데이트 등의 작업은 프로그래밍 방식으로 자동 처리할 수 있음
  • 해결 성공 여부는 사용자가 정의한 기준을 통해 명확히 측정할 수 있음

• 몇몇 기업은 성공적인 해결에 대해서만 요금을 부과하는 사용량 기반 과금 모델을 도입함으로써, 자사의 에이전트 효과에 대한 높은 신뢰를 보여주고 있음

2. 코딩 에이전트 (Coding Agents)

• 소프트웨어 개발 분야는 LLM 기능이 코드 자동 완성에서 자율적인 문제 해결로 진화하며 놀라운 가능성을 보여줌

• 코딩 에이전트가 효과적인 이유

  • 코드 솔루션은 자동화된 테스트를 통해 검증할 수 있음
  • 에이전트는 테스트 결과를 피드백으로 활용하여 반복적으로 개선할 수 있음
  • 문제 영역이 명확하고 구조화되어 있음
  • 출력 결과의 품질을 객관적으로 측정할 수 있음

• 에이전트가 PR 설명만으로 실제 GitHub 이슈를 해결하며,SWE-bench Verified 벤치마크에서도 좋은 성과를 보여주고 있음

• 자동화된 테스트가 기능 구현 여부를 검증해줄 수는 있지만,해결책이 전체 시스템 요구사항과 잘 부합하는지를 판단하기 위해서는 인간의 리뷰가 여전히 매우 중요함

3. 도구를 위한 프롬프트 엔지니어링

• 어떤 종류의 에이전트형 시스템을 구축하든, 도구(tools)는 대부분의 경우 에이전트의 핵심 구성 요소가 됨

  • 도구는 Claude가 외부 서비스나 API와 상호작용할 수 있도록 하는 수단이며, 도구의 정확한 구조와 정의는 API를 통해 명시됨
  • Claude가 응답을 생성할 때, 도구를 호출하려는 계획이 있으면 응답에 도구 사용 블록(tool use block)을 포함
  • 도구는 에이전트의 작동 방식에 있어 중요한 역할을 하므로,도구의 정의와 명세도 전체 프롬프트 못지않게 프롬프트 엔지니어링에 신경 써야 함

• 동일한 작업을 여러 방식으로 명세할 수 있는 경우

  • diff 형식으로 수정 부분만 제공
  • 전체 파일을 다시 작성

• 구조화된 출력을 생성할 때

  • 마크다운 형식의 코드 블록(````python`)
  • JSON 내부에 코드 문자열을 삽입

• 소프트웨어 엔지니어링 관점에서는 이러한 차이는 표면적인 형식 차이(cosmetic)일 뿐이며, 한 형식에서 다른 형식으로 손실 없이 변환이 가능함

  • LLM 입장에서는 어떤 형식은 작성하기 훨씬 더 어려운 경우
    • diff를 작성하려면, 새로운 코드가 무엇인지 쓰기 전에 수정될 줄 수(line count)를 chunk header에 먼저 명시해야 함
    • JSON 내부에 코드를 작성하려면, 줄바꿈 문자나 따옴표를 추가로 이스케이프 처리해야 하기 때문에 마크다운보다 더 복잡함

• 도구 형식을 결정할 때 제안하는 권장 사항

  • 모델이 스스로 막다른 길에 몰리기 전에 “생각할 여유”를 가질 수 있도록 충분한 토큰을 제공하라

  • 형식은 인터넷 상에서 모델이 자연스럽게 접해왔던 텍스트와 최대한 유사하게 유지하라

  • 수천 줄의 코드 줄 수를 정확히 세야 하거나, 작성한 코드를 문자열 이스케이프해야 하는 등 불필요한 형식적 부담(formatting overhead)이 없도록 하라

4. 에이전트-컴퓨터 인터페이스(ACI) 설계

• 모델의 입장에서 생각해라.
  • 도구 설명과 파라미터만 보고 사용 방법이 직관적으로 떠오르나요? 아니면 신중히 고민해야 할 정도로 모호한가요? -> 사람이 헷갈리면 모델도 마찬가지
  • 좋은 도구 정의 요소
    • 사용 예제
    • 엣지 케이스
    • 입력 형식 요구사항
    • 다른 도구와의 명확한 경계
• 파라미터 이름이나 설명을 더 명확하게 바꿀 수는 없을까?
• 모델이 도구를 어떻게 사용하는지 테스트하라
• 도구에 포카요케(Poka-yoke, 실수 방지 장치)를 적용하라.