단일 요청, 워크플로우, 또는 에이전트

여러분의 제품에 지원 티켓이 들어오고, 각 티켓에 대한 답변을 Claude가 작성해주기를 바란다고 가정해 봅시다. 무언가를 만들기 전에, 얼마나 많이 만들지 먼저 선택하세요. 더 큰 빌드는 종종 더 나은 결과를 가져오지만, 비용도 더 들고 고객을 더 오래 기다리게 하는 경향이 있습니다.

단일 요청을 보내거나, 코드가 정한 순서로 여러 요청을 실행하는 워크플로우를 돌리거나, 스스로 단계를 선택하는 에이전트를 사용할 수 있습니다. 가장 단순한 것부터 시작하고, 테스트에서 더 단순한 쪽이 부족하다는 것이 드러날 때만 다음 단계로 넘어가세요.

누가 다음 단계를 결정하는지 물어보세요

세 가지 옵션은 Claude가 답한 후 무슨 일이 일어나는지를 누가 결정하느냐에 따라 다릅니다.

• 단일 요청에서는 다음에 아무 일도 일어나지 않으며, Claude의 답변이 곧 결과입니다.
• 워크플로우에서는 여러분의 코드가 결정합니다. 미리 작성해 둔 순서대로 다음 요청을 보냅니다.
• 에이전트에서는 Claude가 결정합니다. 각 다음 단계와 어떤 도구를 사용할지 스스로 선택합니다.

세 가지 옵션 중에서 선택하려면, 먼저 좋은 결과가 어떤 모습인지 적어두세요. 지원 티켓의 경우, 좋은 답변이란 고객의 질문에 답하고, 환불 정책을 따르며, 내보내기 전에 가벼운 수정만 필요한 답변일 수 있습니다. 이를 적어두면, 가장 단순한 옵션을 그 기준에 비추어 테스트하고 부족한지 확인할 수 있습니다.

단일 요청부터 시작하세요

단일 요청은 하나의 Messages API 요청이며, 답변도 하나입니다. 티켓과 함께, 코드가 해당 티켓을 위해 찾아낸 도움말 문서와, 따라야 할 예시로 마음에 들었던 과거 답변 몇 개를 함께 전달할 수 있습니다. 많은 기능에서는 이렇게 구성한 단일 요청만으로 보통 충분합니다.

단일 요청이 여러분의 티켓에 충분한지 확인하려면, 지난달의 실제 티켓으로 실행해 보세요. 적어두었던 좋은 답변 기준에 비추어 각 답변을 채점하세요. 그런 다음 부족했던 답변들을 읽고, 어떤 종류의 티켓에 대한 답변이었는지 살펴보세요. 실제 입력과 결과를 채점하는 방법이 있는 이런 테스트를 eval이라고 합니다.

답변이 적어둔 기준과 일치한다면, 단일 요청을 그대로 출시하고 거기서 멈추세요. 기준에 못 미치는 부분이 있다면, 다음 단계로 넘어가기 전에 요청의 지시문, 문서, 예시를 개선하세요.

단일 요청이 충분하지 않다는 한 가지 신호는, 한 종류의 티켓에 대한 수정이 다른 종류를 더 나쁘게 만드는 경우입니다. 예를 들어, 프롬프트에 환불 규칙을 추가했더니 기술 질문에 대한 답변이 나빠지는 경우입니다. 이렇게 한 수정을 다른 수정과 계속 맞바꾸게 된다면, 워크플로우를 시도해 보세요.

단계를 나열할 수 있다면 워크플로우로 넘어가세요

단일 요청이 부족하다는 것이 드러나면, 첫 티켓이 도착하기 전에 단계를 적어둘 수 있는 경우 워크플로우를 선택하세요. 워크플로우는 고정된 단계로 깔끔하게 나뉘는 작업에 적합합니다.

지원 티켓을 위한 워크플로우는 두 단계로 실행될 수 있습니다:

1. 첫 번째 요청이 티켓을 환불, 기술 질문, 일반 질문 세 가지 중 하나로 분류합니다.
2. 여러분의 코드가 해당 종류의 티켓에 맞는 프롬프트와 도움말 문서와 함께, 두 번째 요청으로 티켓을 보냅니다.

이제 각 종류의 티켓마다 고유한 프롬프트가 있으므로, 환불 프롬프트를 변경해도 기술 답변에는 영향이 없습니다.

작업을 여러 요청으로 나누면 단계 사이에 무엇이 나오는지도 볼 수 있습니다. 각 단계가 독립된 요청이므로, 다음 단계가 실행되기 전에 기록하고, 채점하고, 확인할 수 있습니다. 예를 들어, 여러분의 코드는 첫 번째 요청이 세 가지 종류 중 하나를 반환했는지 확인하고, 그 외의 답변은 사람에게 보낼 수 있습니다.

이 워크플로우는 두 번째 요청이 첫 번째 요청이 끝날 때까지 시작될 수 없기 때문에 고객을 더 오래 기다리게 합니다. 여러분은 더 정확한 답변을 얻기 위해 그 대기 시간을 받아들이는 것이며, 테스트를 통해 실제로 그렇게 된다는 것을 보여줘야 합니다.

단계를 미리 적어둘 수 없을 때는 워크플로우가 더 이상 적합하지 않습니다. 예를 들어, 답변을 위해 Claude가 고객의 주문을 조회해야 하고, 다음에 무엇을 확인할지가 거기서 찾아낸 내용에 따라 달라지는 경우입니다.

그럴 수 없을 때만 에이전트로 넘어가세요

Claude가 제공받은 도구로 각 다음 단계를 스스로 선택해야 하는, 열린 결말의 작업에 대해서만 에이전트를 선택하세요. 열린 결말이란 작업에 몇 단계가 필요한지 예측하기 어렵거나 불가능하고, 단계를 미리 적어둘 수 없다는 것을 의미합니다.

예를 들어, 고객이 자신의 소포가 도착하지 않았다고 씁니다. Claude는 먼저 고객의 주문 내역을 조회하고, 소포가 예전 주소로 배송되었다는 것을 발견합니다. 그래서 Claude는 다음으로 잘못된 주소에 관한 정책 문서를 읽습니다. 그런 다음 환불을 처리하거나 티켓을 업데이트합니다.

에이전트는 비용이 더 많이 들고, 그 실수는 서로 쌓일 수 있습니다. 에이전트를 유용하게 만드는 선택의 자유는 동시에 테스트를 더 어렵게 만듭니다. 에이전트는 여러 단계에 걸쳐 실행될 수 있으므로, 그 판단에 어느 정도 신뢰가 필요합니다.

에이전트를 선택하기 전에, 작업에 대해 다음 질문들에 답해 보세요:

• 더 나은 결과가 더 높은 비용과 더 긴 대기를 감수할 만한 가치가 있습니까?
• Claude가 이런 종류의 작업을 잘 수행합니까?
• 잘못된 단계를 테스트, 검토, 또는 롤백으로 포착하고 되돌릴 수 있습니까?

이 중 어느 하나라도 답이 "아니오"라면, 워크플로우나 단일 요청에 머무르세요. 지원 티켓의 경우, 이는 단계를 나열할 수 있는 종류의 티켓에는 워크플로우를 유지하고, 나머지는 사람에게 보낸다는 뜻입니다.

에이전트는 조회와 환불의 순서가 티켓마다 달라지는 티켓에만 적합합니다. 사람이 각 환불을 승인하므로, 세 번째 질문에 대한 답은 "예"입니다.

몇 가지 기능 아이디어로 시도해 보세요

세 가지 옵션에 각 기능 아이디어를 적용해 보고 어떤 일이 일어나는지 확인하세요.

다음으로 할 일

Claude로 어떤 기능이든 만들기 전에, 좋은 결과가 어떤 모습인지 적어두고, 단일 요청부터 시작하고, 테스트에서 부족하다는 것이 드러날 때만 다음 단계로 넘어가세요. 지금 계획하고 있는 기능에 대해 같은 선택을 해보세요. 선택을 점검하려면, 여러분의 기능에서 누가 다음 단계를 결정하는지와, 다음 단계로 넘어가게 만들 테스트 결과가 무엇인지 적어보세요.

언제 다음 단계로 넘어갈지 알려주는 테스트가 바로 eval입니다. 다음으로, Introduction to evals를 수강해서 여러분 자신의 데이터로 작은 eval을 만들어 보세요.

선택을 마친 후에는 두 페이지가 더 도움이 됩니다. 여러분의 기능이 Claude에게 도구를 제공한다면, Tool use with the Messages API에서 도구 사용을 신뢰할 수 있고, 응답이 빠르고, 실행 비용이 저렴하게 만드는 방법을 보여줍니다. 에이전트를 선택한다면, What is Claude Managed Agents?에서 에이전트와 그 도구를 실행해 주는 관리형 환경을 다루므로, 여러분이 직접 그 부분을 만들 필요가 없습니다.