AI가 프로젝트를 지속적으로 팔로업하게 하면서, 중복 알림은 줄이고 변화를 놓치지 않으려면?

AI가 생성한 개념 삽화이며, 내용은 가상의 예시입니다.

당신이 AI에게 금요일 납품 예정인 프로젝트를 지켜보라고 시켰다고 가정해 봅시다. 월요일에 AI는 고객이 아직 자료를 확인하지 않았다고 알려줍니다. 화요일에는 거의 같은 요약을 다시 보냅니다. 수요일이 되자 고객은 이미 이메일로 연기를 요청했는데, 프로젝트 보드에는 여전히 금요일 납품이라고 적혀 있습니다. 어시스턴트는 두 날짜를 모두 보고서에 넣고, 마지막으로 “지속적으로 주의 깊게 지켜보라”고 권합니다.

당신은 여전히 이메일을 열고, 보드를 확인하고, 담당자에게 다시 물어봐야 합니다.

지속적인 팔로업은 지난번의 판단을 보존하고, 이번에 무엇이 달라졌는지 설명할 수 있어야 합니다. 매번 실행할 때마다 모든 자료를 다시 요약하면, 어시스턴트는 오래된 메시지를 새로운 진전으로 잘못 쓸 수 있고, 아직 확정되지 않은 제안을 이미 발효된 일정으로 오해할 수도 있습니다.

한 번 요약한 뒤에도 남겨야 할 것

여러 앱에 걸쳐 정보를 정리하려는 시도는 이미 적지 않습니다. Composio의 가족 일간지 사례는 캘린더, 날씨, 흥미로운 내용을 모아 그날의 작은 신문을 만듭니다. Lindy의 AI teammate 소개는 지속적인 컨텍스트와 능동적인 팔로업을 논의합니다. 이런 내용은 그날의 정보를 어떻게 정리할 수 있는지는 보여주지만, 더 구체적인 질문에는 답하지 않습니다. 즉, 연속된 두 번의 확인 사이에 이미 확인된 어떤 판단을 남겨야 하는가입니다.

그날의 요약은 눈앞의 일정을 이해하는 데 도움이 됩니다. 지속적인 팔로업 작업은 여기에 더해, 지난번에 비해 상황이 어떻게 달라졌는지 설명할 수 있어야 합니다.

프로젝트 납품을 예로 들면, 처음 자료를 정리한 뒤 남길 만한 내용은 많지 않습니다. 현재 확정된 납품 날짜, 아직 기다리는 자료, 팔로업을 담당하는 사람, 그리고 이런 판단을 뒷받침하는 출처입니다. 또한 이번 확인이 어느 시점까지를 포함하는지, 어떤 출처를 읽지 못했는지도 기록해야 합니다.

이 기록이 다음 확인의 출발점입니다. 앱 데이터베이스, 작업 기록, 또는 통제된 문서에 저장할 수 있으며, 구체적인 형식은 어시스턴트 시스템이 결정합니다. 중요한 것은 이후 실행이 실제로 이 기록을 읽을 수 있고, 그중 어떤 내용이 이미 확인된 것이고 어떤 것이 단지 추측인지 아는 것입니다.

지난번에 “프로젝트 진행 정상”이라는 한 줄만 있었다면, 다음번에 어디가 달라졌는지 설명하기 어렵습니다.

새 메시지가 반드시 일의 진전을 의미하지는 않는다

같은 자료가 그룹에 전달되고, 메일함에 “확인했습니다, 감사합니다”가 한 통 더 오고, 보드에서 누군가 작업 설명을 수정합니다. 이들은 모두 새로운 기록이지만, 납품에 미치는 영향은 다릅니다.

작업과 관련해 관심 있는 사실을 중심으로 비교할 수 있습니다. 이 프로젝트에서 당신이 진짜 알아야 할 것은 자료가 완비되었는지, 납품 날짜가 바뀌었는지, 누가 할 일을 맡았는지, 새로운 장애물이 생겼는지입니다.

다음은 가상의 상황들입니다.

이번에 읽은 내용	어떻게 이해해야 하는가	어떻게 알리는 것이 적절한가
동료가 월요일의 자료 요청을 전달함	같은 사안이며, 아직 새로운 납품 정보는 없음	같은 알림을 반복推送하지 않고, 기한이 되면 여전히 알림
고객이 이전에 없던 첨부 파일을 보냄	자료는 받았지만, 요구 사항을 충족하는지는 여전히 확인 필요	무엇을 받았고 무엇이 아직 빠졌는지 설명
고객이 다음 주 월요일로 변경 가능한지 문의함	일정 변경 요청이 발생함	결정 대기로 표시하고, 현재 확정된 날짜를 유지
담당자가 명확히 일정 변경에 동의함	새로운 확인 기록이 발생함	원래 날짜, 새 날짜, 확인 출처를 설명

같은 기록을 식별할 때는 소스 시스템이 제공하는 식별자를 사용할 수 있습니다. 서로 다른 기록이 같은 일을 설명하는지 판단하려면 프로젝트, 참여자, 내용을 함께 고려해야 합니다. 제목만 같다고 두 이메일을 안정적으로 병합할 수는 없습니다. 텍스트가 다르다고 해서 프로젝트가 한 걸음 더 나아갔다고 생각해서도 안 됩니다.

이미 명확한 필드는 직접 비교하는 것이 적합하고, 의미를 이해해야 하는 부분은 모델에 맡깁니다. 예를 들어 날짜 필드가 변경된 작업을 먼저 찾고, AI에게 관련 논의를 읽게 해서 이번 변경이 이미 확인된 것인지 설명하게 합니다.

이메일과 보드가 일치하지 않을 때는 불일치를 남겨 둔다

수요일 이메일은 다음 주 월요일 납품을 제안했지만, 보드에는 여전히 금요일이라고 적혀 있습니다. 어느 쪽이 유효할까요?

“더 늦게 업데이트됨”은 기록 시간만 설명할 뿐, 발언자가 일정을 바꿀 권한이 있다는 것을 의미하지는 않습니다. 이메일은 요청일 수 있고, 보드는 아직 업데이트되지 않았을 수도 있으며, 다른 작업의 날짜를 인용한 것일 수도 있습니다.

팀은 미리 기준을 정할 수 있습니다. 예를 들어 납품 날짜는 지정된 담당자의 확인을 기준으로 하고, 보드는 확인된 일정을 기록하는 데 사용합니다. 그러면 어시스턴트가 일정 변경 이메일을 보았을 때 이를 확인 대기 항목으로 분류할 수 있고, 담당자가 동의한 것을 보면 보드도 동기화해야 한다고 지적할 수 있습니다.

합의가 없을 때는 어시스턴트가 두 기록을 함께 제시하고 불일치를 설명하여 담당자가 결정하도록 해야 합니다. 다음은 가상의 알림 예시입니다.

고객이 오늘 이메일에서 납품을 다음 주 월요일로 변경해 달라고 요청했습니다. 프로젝트 보드는 여전히 이번 주 금요일입니다. 현재 읽을 수 있는 기록에서는 담당자의 일정 변경 확인을 아직 찾지 못했습니다. 요청을 수락할지 확인해 주세요.

출처를 인용할 때는 실제로 열 수 있는 링크를 제공해야 합니다. “고객 이메일” 또는 “보드”라고만 쓰면 담당자는 여전히 확인할 수 없습니다.

여기서는 사람이 결정해야 하며, 요구 사항은 명확합니다. “프로젝트 위험을 지속적으로 주의하세요”보다 담당자는 무엇을 답해야 하는지 알고, 근거를 바로 열 수 있습니다.

변화 없음, 확인 실패, 기한 도래는 분리해서 처리한다

지속적으로 실행되는 어시스턴트는 조용한 결과를 허용해야 합니다. 지정된 출처 확인이 정상이고 일도 변하지 않았다면, 확인 결과를 기록하고 약속대로 중복 요약을 보내지 않을 수 있습니다.

하지만 이메일 읽기에 실패했을 때는 같은 결론을 내릴 수 없습니다. 어시스턴트는 자신이 확인을 완료하지 못했다는 것만 알 뿐입니다. 마지막으로 성공적으로 읽은 위치를 보존하고, 이번에 누락된 출처를 설명해야 합니다. 접근이 복구된 후에는 누락 기간의 기록을 보충 확인해야 합니다. 인터페이스가 증분 커서를 제공하면 그 규약에 따라 이어 읽을 수 있고, 그렇지 않으면 누락 시간을 포함하는 쿼리를 설계해야 합니다. 복구된 당일만 조회하고 그 사이에 변화가 없었다고 가정해서는 안 됩니다.

Viktor의 자동화가 조용히 실패하는 이유는 장기 실행 작업이 실패한 뒤 알아차리기 어렵다는 점을 설명합니다. 팔로업 작업도 마찬가지입니다. 알림이 오지 않을 때, 당신은 그것이 지난번에 실행되었는지, 어떤 출처를 확인했는지 조회할 수 있어야 합니다.

또 한 가지 경우가 있습니다. 새 메시지가 없어도 알림이 필요한 경우입니다. 약속된 기한이 도래한 것입니다. 고객이 계속 답장하지 않아 양측이 합의한 팔로업 시간이 되면, 이 일은 다시 나타날 가치가 있습니다.

따라서 알림은 실제 변화에서 올 수도 있고, 사전에 합의된 시간 조건에서 올 수도 있습니다. 작업이 종료, 취소 또는 담당자에게 인계된 후에는 해당 알림을 중지해야 합니다. 그렇지 않으면 이미 완료된 작업이 매일 당신에게 주의를 요구할 것입니다.

OOMOL은 팔로업 작업에 앱 연결을 제공한다

두 번의 확인 사이의 변화를 비교하려면 어시스턴트가 실제 시스템의 기록을 읽어야 합니다. OOMOL에서 Connector SDK는 이미 승인된 연결 계정을 선택하고 해당 앱 작업을 호출하는 방법을 설명합니다. 게이트웨이는 자격 증명을 보유하고 실제 요청을发起합니다.

예를 들어 프로젝트 팔로업을 위해 업무 이메일과 프로젝트 관리 도구를 연결하고, 이들이 필요한 검색, 상세 읽기, 업데이트 시간 필드를 제공하는지 확인합니다. 서비스마다 쿼리 범위, 기록, 증분 기능이 다르므로 구체적인 인터페이스에 따라 확인해야 합니다.

지난번 확인한 상태, 서로 다른 출처 간의 연관, 알림 조건과 중지 조건은 어시스턴트나 비즈니스 프로세스가 저장하고 실행합니다. 연결이 성공한 뒤에도 이러한 작업 규칙은 여전히 구현해야 합니다.

첫 버전에서는 필요한 읽기 작업만 개방하고, 변화 보고를 담당자에게 맡길 수 있습니다. 보드를 동기화하거나 고객에게 답장해야 할 때는 권한 제어 가이드에 따라 해당 작업을 구성하고, 실행 대상과 확인 방식을 명확히 합니다.

팀이 연결 서비스를 직접 관리해야 한다면 OOMOL의 오픈 소스 프로젝트 OpenConnector를 사용하고, 자체 배포 가이드에 따라 자격 증명, 작업 정책, 실행 기록을 관리할 수 있습니다.

같은 프로젝트로 두 번 연속 확인하기

OOMOL Connections에서 작업에 필요한 앱을 연결하고, 연결 기능 호출을 지원하고 작업 상태를 저장할 수 있는 어시스턴트에게 범위가 명확한 요청을 처리하게 할 수 있습니다.

이 프로젝트의 납품 날짜와 제출할 자료를 팔로업해 주세요. 먼저 지정된 이메일 스레드와 프로젝트 작업을 읽고, 현재 확정된 상태, 확인 대기 항목, 출처를 정리하여 이후 비교의 근거로 저장하세요. 이번에는 결과만 저에게 전달하고, 소스 시스템은 수정하지 마세요. 다음 확인 때는 이번에 비해 무엇이 달라졌는지 설명하세요. 변화가 없으면 요약을 반복하지 말고, 읽기에 실패하면 누락을 설명하세요. 알림 시간과 중지 조건은 제가 확인한 뒤 설정하세요.

첫 번째 확인에서는 프로젝트, 이메일, 담당자를 올바르게 선택했는지 검토합니다. 두 번째는 테스트 자료로 중복 전달 한 건, 일정 변경 요청 한 건, 공식 확인 한 건을 추가하여 어시스턴트가 세 가지를 구분하는지 관찰합니다. 그런 다음 한 출처를 일시적으로 사용할 수 없게 만들어, 읽기 실패를 “진전 없음”이라고 말하지 않는지 확인합니다.

이런 판단이 기대에 부합하면 정기 실행을 예약합니다. 다음에 받는 알림은 구체적인 질문에 답할 수 있어야 합니다. 지난번 확인한 상태에 비해, 지금 당신이 처리해야 할 것은 무엇인가?