에이전트 워크플로, 병렬 실행 전에 한 갈래부터 검증해야 한다
에이전트 워크플로를 설계한다고 하면 동시에 몇 개를 돌릴지가 먼저 떠오르기 쉽다. 그런데 코드팩토리의 Graph Engineering 실습을 정리하면서 내가 가져갈 기준은 그보다 앞에 있었다. 한 갈래를 끝까지 통과시켜 입출력과 실패 조건을 확인한 다음, 서로 독립된 일만 병렬로 넓히는 것.
영상은 숙소 자료를 찾는 흐름을 예시로 든다. 먼저 한 지역에서 수집부터 결과 검사까지 통과시키고, 그 절차가 안정된 뒤 강남·마포·종로로 확장한다. 각 지역의 수집과 검증은 서로 영향을 주지 않으니 병렬로 돌리고, 세 지역을 비교해 순위를 매기는 일은 결과를 모은 다음 진행한다.
처음부터 작업을 여러 갈래로 벌리면 같은 형식 오류를 여기저기서 반복할 수 있다. 한 갈래에서 입력과 출력, 실패 조건을 먼저 맞춰두면 병렬 작업은 오류를 복제하는 대신 독립된 결과를 모으는 역할을 한다. 영상에서 말하는 Graph Engineering도 별도의 신기술 하나라기보다, 분기와 합치기, 검증, 상태 전달, 사람 승인을 워크플로로 엮는 실무 관점에 가깝다고 봤다.
AI가 맡을 일과 코드가 맡을 일
폴더 만들기, JSON 해석, 필수 필드 확인, 지역·가격·주소 조건 검사처럼 답이 정해진 작업은 코드로 처리한다. 자료를 비교해 추천 이유를 설명하는 단계에 언어 모델을 쓰는 식이다. 모든 단계를 AI에게 맡기기보다, 기계적으로 판정할 수 있는 일은 코드에 맡기는 편이 결과와 비용을 예측하기 쉽다.
다만 코드 검사를 통과했다는 말은 형식과 규칙이 맞았다는 뜻이지, 자료가 현실과 맞다는 뜻은 아니다. JSON에 가격이 들어 있어도 실제 화면의 가격과 같은지, 검색에서 좋은 후보가 빠지지 않았는지, 후기가 최신인지까지 저절로 확인되지는 않는다.
그래서 원문 일부를 직접 대조하고 다른 수집 경로와 교차 확인하며, 누락률과 자료를 확인한 시각을 기록해야 한다. 언어 모델이 만든 추천 결과도 근거 링크와 수치를 다시 검사해야 하고. 구조 검증은 사실 검증을 대신하지 않는다.
병렬 작업 수도 무조건 크게 잡을 이유가 없다. 수집 API 요청 제한, 모델의 동시 실행 한도, 메모리, 대상 사이트 응답 속도, 결과를 합칠 때의 입력 크기 중 가장 작은 한도가 전체 처리량을 정한다. 3개에서 5개, 10개처럼 조금씩 늘리면서 성공률과 시간, 비용을 보는 접근이 현실적이다.
승인 지점은 외부 행동 바로 앞에
추천안을 만드는 것과 그 추천으로 예약하거나 결제하는 것은 다른 단계다. 회사 자료를 수정하거나 외부 이메일을 보내고, 결제·예약·공개 배포를 하기 전에는 사람에게 결과를 보여주고 승인이나 수정을 받는 지점이 필요하다. 중단된 상태를 저장했다가 승인 후 이어 가는 구조도 가능하다. 승인 전 단계에서 외부 효과가 생긴다면 재시도 때 중복 실행이나 원치 않는 변경이 생기지 않도록 설계해야 한다.
영상의 Airbnb 수집 예시는 그대로 실무에 옮기기 어렵다. 자료 메모에서 확인한 이용약관 내용은 자동 수집을 금지하는 것으로 정리돼 있었다. 수집 도구가 기술적으로 접근할 수 있다는 사실만으로 대상 서비스가 허용한다고 볼 수는 없다. 회사 자료든 공개 웹 자료든 공식 API나 허용된 이용 방식을 먼저 확인하고, 차단을 우회해야 하는 출처는 별도의 이용 조건 문제로 다루는 게 맞겠다.
내 작업에 대입해보면
내 Hermes 칸반은 부모·자식 작업을 연결하고 조사를 병렬로 진행한 뒤 검토 단계에서 결과를 모으는 흐름이 이미 있다. 새 도구를 들이는 것보다 각 작업 카드에 입력 자료와 결과 형식, 통과 조건을 분명하게 적는 일이 먼저다.
CDPM-Auto에서는 주간 보고서를 프로젝트 하나로 시험해볼 수 있다. Jira와 Confluence 자료를 모아 원본 JSON을 보관하고, 필수 필드와 날짜 범위를 코드로 확인한 뒤 언어 모델이 요약한다. 그다음 근거 링크와 수치를 다시 검사하고 PM 미리보기를 승인받은 뒤 이메일 초안이나 발송 단계로 넘긴다.
성공 기준도 보고서가 만들어졌다는 데서 끝나면 안 된다. 필수 항목 누락 0개, 근거 없는 문장 0개, 수치 오류 0개, 승인 전 외부 발송 0건을 확인하고 실패한 단계만 다시 실행할 수 있어야 한다. 영상에서 남길 만한 건 에이전트를 많이 띄우는 요령보다, 작업이 어디서 통과했고 어디서 막혔는지를 끝까지 추적하는 방식이었다.
참고한 영상
https://www.youtube.com/watch?v=RVEjyNyMchU
댓글
댓글 쓰기