Apex Code를 활용한 Gladly 작업(Task) 생성 효율화

핵심 요약 (Key Takeaways)

Gladly 작업(Task)은 단순한 할 일 목록 그 이상입니다 - 이는 마감일과 코멘트가 포함된, 구조화되고 할당 가능하며 고객과 연결된 후속 조치입니다. 이 모델을 이해하는 것이 API 통합을 단순히 기능적으로 작동하는 수준을 넘어 실제로 유용하게 만드는 핵심입니다.
래퍼 클래스(Wrapper class) 패턴은 번거로운 절차가 아닙. 요청 본문(Request body)에 중첩된 객체(Nested objects)가 있고, 통합 시스템이 호출하는 모든 것을 망가뜨리지 않으면서 시간이 지남에 따라 진화해야 할 때 Apex 코드를 유지 관리 가능한 상태로 유지하는 방법입니다.
**API 통합에서의 에러 핸들링(Error handling)**은 모두가 가장 마지막에 작성하고, 건너뛴 것을 가장 먼저 후회하는 부분입니다. 처음부터 구축하세요. 첫 번째 운영 장애(Production incident)가 발생했을 때 미래의 당신이 고마워할 것입니다.

고객 서비스 플랫폼에서 충분히 일해 보셨다면, 이 통합이 해결하고자 하는 문제를 알고 계실 것입니다.

Salesforce에서 예약 일정이 변경됩니다. 어딘가에서 Gladly 상담사는 이 사실을 알고 고객에게 후속 조치를 취하며 상황을 마무리해야 합니다. 자동화가 없다면 이는 수동 단계가 됩니다. 누군가는 작업을 생성하고, 올바른 세부 정보를 입력하고, 정확하게 할당하는 것을 기억해야 합니다. 때로는 수행하지만, 때로는 하지 못합니다. 때로는 고객이 이미 두 번이나 다시 전화한 3일 뒤에야 수행하기도 합니다.

Apex와 Gladly의 작업(Task) API는 그 간극을 메워줍니다. 후속 작업이 자동으로 생성되고, 정확하게 할당되며, 적절한 마감일과 고객 컨텍스트(Context)를 갖추게 됩니다. 아무도 이를 기억해서 수행할 필요가 없습니다.

이 가이드는 바로 그 과정을 안내합니다. 무엇이 가능한지에 대한 이론적인 개요가 아니라, 이를 실제로 작동하게 만드는 실제 코드 패턴을 다룹니다.

Gladly 작업(Task)이란 무엇인가?

코드를 작성하기 전에 Gladly 작업(Task)이 실제로 무엇인지 이해할 가치가 있습니다. 왜냐하면 이는 단순한 일반적인 할 일 항목이 아니기 때문입니다.

Gladly에서의 작업(Task)은 고객별로 특화되어 있습니다. 이는 고객의 타임라인(Timeline) 상에서 대화, 이메일 및 기타 상호작용과 함께 존재합니다. 작업은 무엇이 수행되어야 하는지를 설명하는 본문(Body), 마감일(Due date), 담당자(Assignee, 인박스(Inbox), 특정 상담원(Agent), 또는 둘 다), 그리고 댓글(Comments) 기능을 포함합니다. API를 통해 작업을 생성하면, Gladly는 이를 기존 고객 프로필(Customer profile)에 연결하거나, 고객이 아직 존재하지 않는 경우 새로운 프로필을 생성합니다.

이 마지막 부분은 통합(Integration) 과정에서 매우 중요합니다. 여러분은 단순히 추상적인 작업을 생성하는 것이 아니라, 실제 고객 관계의 맥락(Context) 내에서 이루어지는 후속 작업(Follow-up work)을 생성하는 것이기 때문입니다. API는 이를 반영하고 있으며, 이것이 바로 요청 본문(Request body)에 작업 상세 정보와 함께 고객 식별 정보(Customer identification)가 필요한 이유입니다.

이 모델을 미리 이해해 두면, 요청 스키마(Request schema)를 살펴보면서 "그저 작업을 생성하고 싶을 뿐인데 왜 고객 식별 정보가 필요한가"라며 혼란을 겪는 일을 크게 줄일 수 있습니다.

Gladly 작업을 생성하는 방법은?

Gladly는 작업 생성을 위한 POST 엔드포인트(Endpoint)를 제공합니다. 요청은 작업(Tasks) API로 전달되며, Gladly가 작업을 생성하고 할당하는 데 필요한 모든 정보를 담은 JSON 본문(Body)을 포함합니다. 이후 에러 처리(Error handling) 및 확인(Confirmation)에 사용할 수 있는 응답(Response)을 반환합니다.

다음은 이를 Apex에서 단계별로 구축하는 방법입니다.

요청 본문 스키마 (REQUEST BODY SCHEMA): application/json

{
  "id": "pOVVdzweSumI4bFxjlT8LA",
  "assignee": {
...

id
String <= 50 characters
작업의 ID를 지정합니다
...

Apex 래퍼 클래스(Wrapper Classes) 생성 - 작업 관리용 public class TaskWrapper

public class TaskWrapper {
        public String id;
        public AssigneeWrapper assignee;
...

필수 파라미터를 포함하여 요청 본문을 구성하는 메서드 생성

public static void createTaskToRescheduleAppointment(String customerEmail, String previousDate, String newDate) {
        String taskBody =
             '<strong>Appointment Rescheduled:</strong> <br>Your appointment has been rescheduled to ' +
...

POST 요청을 처리하기 위한 createTask 메서드 생성

public static void createTask(TaskWrapper task) {

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (task != null) {
...

결론 (Conclusion)

이 통합(Integration)을 통해 실제로 얻을 수 있는 것은 신뢰성입니다. 작업(Task)은 누군가가 수동으로 생성하는 것을 기억할 때가 아니라, 적절한 정보와 함께 적절한 위치에 할당되어 생성되어야 할 시점에 생성됩니다.

래퍼 클래스(Wrapper class) 패턴은 요구사항이 진화함에 따라 코드를 유지보수 가능한 상태로 유지해 줍니다. 메서드 분리는 관심사(Concerns)를 깔끔하게 유지합니다. 하나의 메서드는 작업을 구축하고, 다른 하나는 이를 전송하며, 호출하는 코드는 이 둘에 대해 알 필요가 없습니다. Gladly가 API의 무언가를 변경하거나, 인박스(Inbox) 할당에 관한 비즈니스 규칙이 변경되더라도, 정확히 어디를 수정해야 할지 알 수 있습니다.

이 시스템을 가동한 후 수행해야 할 진짜 작업은 이를 중심으로 구축하는 에러 핸들링(Error handling)과 관측성(Observability)입니다. 호출(Callout)이 실패하면 어떻게 될까요? Gladly가 예상치 못한 상태(Status)를 반환하면 어떻게 될까요? 작업 생성이 중단되면 어떻게 알 수 있을까요? 이러한 질문들은 이 시스템을 운영 환경(Production)에 적용한 후가 아니라, 적용하기 전에 답을 찾아야 할 가치가 있는 질문들입니다.

Innostax 소개

Innostax는 매니지드 엔지니어링 팀(Managed engineering teams)을 전문으로 하며, 2014년에 설립되어 매사추세츠주 프레이밍햄(Framingham)에 본사를 두고 있습니다. 우리는 스타트업과 기업 모두를 대상으로 책임감을 최우선으로 하는 엔지니어링 팀을 구축하여, 고객 이탈 없이 일관된 소프트웨어 속도(Software velocity)를 달성할 수 있도록 돕습니다.

더 읽어보기: Streamlining Gladly Task Creation with Apex Code