Two Actors, one agent, and the three ways my chain broke

개요

Apify 플랫폼에서 두 개의 Actor를 연동하여 위험한 판매자를 식별하는 과정에서 발생한 세 가지 체인 오류와 해결 방안을 제시하며, Actor 설계 및 Agent 연동 시 고려사항을 설명합니다.

주요 내용

• Actor 설계의 분리 이유: 판매자 목록을 스크랩하는 Actor와 각 판매자의 법인 정보를 기반으로 위험 점수를 계산하는 Actor는 각기 다른 기술 스택(브라우저 필요 여부, HTTP 요청 위주)과 실행 주기를 가지므로 분리하는 것이 효율적입니다.
• 체인 오류 1: 참조 전달 방식의 문제: Actor 간 데이터 전달 시 sourceDatasetId를 사용할 경우, 동일 계정 내에서는 접근 가능하나 다른 계정 간에는 표준 권한으로 데이터셋을 읽을 수 없어 "Insufficient permissions" 오류가 발생합니다. 해결책은 items와 같이 데이터를 직접 값으로 전달하는 방식을 사용하고, 스키마에서 sourceDatasetId를 우선순위가 낮은 대체 입력으로 설정하는 것입니다.
• 체인 오류 2: 입력 스키마 불일치: 첫 번째 Actor가 모든 판매자에 대해 세금 ID(INN)를 반환하지 않는 경우, 해당 정보가 누락된 레코드가 두 번째 Actor의 입력으로 전달될 때 문제가 발생합니다. 해결책은 첫 번째 Actor가 각 레코드에 checkable 및 checkableReason 필드를 추가하여 후속 단계에서 처리 가능한지 여부를 명시하고, 두 번째 Actor는 INN이 없는 경우 lookupStatus: "skipped_no_inn"와 함께 riskScore: None을 반환하도록 수정하는 것입니다.
• 체인 오류 3: 스키마 유효성 검사 오류: 두 번째 Actor의 출력 스키마에 정의되지 않은 새로운 위험 요인(예: procurement blacklist)이 추가되었을 때, 해당 데이터를 push_data로 저장하려 하면 스키마 유효성 검사 오류가 발생합니다. 이 경우 실행은 계속되지만 해당 데이터는 데이터셋에 저장되지 않아 결과가 잘못될 수 있습니다. 해결책은 스키마에 새로운 값을 포함시키고, 스키마 유효성 검사 실패를 전체 실행 실패로 간주하며, 새로운 값을 생성하는 파서와 스키마 업데이트를 동시에 커밋하는 것입니다.
• Agent의 컨텍스트 한계 및 요약: Agent는 수백 개의 판매자에 대한 상세한 위험 정보를 모두 컨텍스트에 유지하기 어렵기 때문에 요약 기능을 사용하게 되며, 이 과정에서 정확성이 저하될 수 있습니다. 이를 해결하기 위해 Agent가 핵심 결정 필드(INN, riskScore, riskLevel, topFactors, lookupStatus)만 포함된 압축된 모드(compact mode)로 데이터를 받아 전체 상세 정보는 별도의 데이터셋에 저장하도록 설계했습니다.
• 중복 실행으로 인한 비용 증가 방지: Agent가 체인을 재시도할 때 동일한 회사에 대해 이미 계산된 위험 점수를 다시 계산하여 불필요한 비용이 발생할 수 있습니다. 이를 방지하기 위해 위험 점수 계산 Actor는 동일한 실행 내에서 중복된 INN을 식별하고 처리 횟수를 보고하며, 이미 계산된 회사에 대해서는 다시 계산하지 않도록 구현했습니다. 또한, 각 레코드에 checkedAt 필드를 추가하여 Agent가 오래된 데이터를 재확인하도록 합니다.
• 초기 설계 시 고려했어야 할 사항: Actor를 처음부터 Agent와의 연동을 염두에 두고 설계했다면, 각 레코드의 처리 가능 여부 및 사유 명시, 누락 값과 0 값의 구분, 쓰기 실패 시 실행 중단, 압축된 출력 형태 제공 등을 고려했을 것입니다.

시사점

Agent 기반의 자동화된 데이터 처리 파이프라인 구축 시, Actor 간의 데이터 전달 방식, 스키마 설계, 오류 처리, 데이터 요약 등 세부적인 부분에서의 견고성이 시스템의 정확성과 효율성에 결정적인 영향을 미치며, 각 Actor가 자신의 작업 범위와 한계를 명확히 인지하고 전달하는 것이 중요합니다.