이 문서는 멀티 에이전트 환경에서 크론잡 실행 시 실패 확률을 줄이고, 특히 목적지 정보 누락으로 결과가 다른 사람 또는 다른 세션에 잘못 전달되는 문제를 방지하기 위한 운영 기준 초안입니다.

크론잡은 정해진 시간에 자동으로 실행되는 만큼, 한 번 잘못 설정되면 같은 실수가 반복될 수 있습니다. 특히 멀티 에이전트 환경에서는 누가 실행하는가, 어디로 보내는가, 어떤 계정으로 동작하는가가 분명하지 않으면 결과가 엉뚱한 채널이나 다른 사용자에게 전달될 수 있습니다.

이 문서는 아래 위험을 줄이기 위해 작성합니다.

• 결과 메시지가 잘못된 채팅방으로 전송되는 문제
• 다른 에이전트 계정/설정을 참조하는 문제
• 실행은 되었지만 대상이 불명확해지는 문제
• 반복 실행으로 같은 오발송이 누적되는 문제

• 크론잡은 실행 주체와 전달 목적지가 명확해야 합니다.
• 목적지 정보가 없으면 전송하지 않는 것을 기본값으로 합니다.
• 애매하면 보내지 않는 편이 잘못 보내는 것보다 안전합니다.
• 계정, 채널, 세션 정보는 추론하지 않고 명시적으로 지정합니다.
• 멀티 에이전트 환경에서는 기본값 의존을 최소화합니다.

멀티 에이전트 환경에서 가장 위험한 유형 중 하나는 결과를 어디로 보내야 하는지 명확하지 않은 상태에서 크론이 실행되는 경우입니다.

예를 들어 아래와 같은 상황이 발생할 수 있습니다.

• 이전 실행의 컨텍스트를 잘못 재사용하는 경우
• 기본 채널/기본 계정으로 전송되는 경우
• 운영자가 예상하지 않은 세션이 활성 상태인 경우
• 특정 사용자용 크론이 공용 또는 타 사용자 채널로 전달되는 경우

따라서 목적지 정보는 선택값이 아니라 필수값으로 취급해야 합니다.

크론잡 설계 시 아래 항목이 빠지면 안 됩니다.

• 실행 에이전트 ID
• 전송 채널
• accountId
• 대상 chat_id 또는 세션 식별자
• 대상이 개인인지 그룹인지에 대한 구분
• 실패 시 재시도 여부
• 전송하지 말아야 하는 조건

권장 원칙:

• 채널만 알고 대상 세션을 모르는 상태에서는 보내지 않습니다.
• 사용자 이름만 알고 내부 식별자가 없는 상태에서도 보내지 않습니다.
• 마지막으로 사용한 대상 같은 암묵적 컨텍스트는 신뢰하지 않습니다.

목적지 정보가 하나라도 빠져 있으면 성공처럼 넘기지 말고, 명시적으로 실패 또는 보류 처리하는 것이 안전합니다.

권장 기준:

• chat_id 없음 → 전송 금지
• accountId 없음 → 전송 금지
• 채널 불명확 → 전송 금지
• 세션 식별 불가 → 전송 금지

멀티 에이전트 환경에서는 아래 방식이 특히 위험합니다.

• 최근 대화 상대를 목적지로 간주
• 마지막 사용 채널을 자동 재사용
• 다른 세션의 delivery context를 재활용
• accountId 없이 기본 계정에 의존

이런 방식은 단일 사용자 환경에서는 편해 보여도, 멀티 에이전트 환경에서는 오발송 가능성을 크게 높입니다.

크론잡은 가능하면 아래처럼 2단계로 나누는 것이 안전합니다.

• 1단계: 조회/분석/정리
• 2단계: 전송 대상 검증 후 발송

이렇게 분리하면, 조회는 성공했더라도 목적지 검증이 실패하면 발송만 막을 수 있습니다.

다음 정보는 한 파일 또는 한 변수에 뭉뚱그려 두기보다 구분해서 관리하는 것이 안전합니다.

• 사용자별 목적지
• 채널별 목적지
• 계정별 전송 권한
• 에이전트별 실행 범위

실제 발송 전에 최소한 아래를 검증합니다.

• 지금 실행 중인 에이전트가 맞는가
• accountId가 의도한 계정인가
• chat_id가 의도한 대상인가
• 이 작업이 개인 DM용인지 그룹용인지 맞는가
• 동일 메시지가 최근 이미 전송되지 않았는가

새 크론잡을 만들거나 수정한 직후에는, 바로 실전 발송하지 말고 한동안은 아래 방식이 안전합니다.

• dry-run으로 대상만 출력
• 실제 전송 대신 로그 파일에 기록
• 테스트 채널로만 발송

가능하면 이름보다 내부 식별자를 사용합니다.

• 사람 이름보다 sessionKey / chat_id / accountId 우선
• 채널명보다 실제 채널 식별자 우선

이유:

• 이름은 중복되거나 바뀔 수 있지만,
• 식별자는 훨씬 안정적입니다.

• 크론 목적을 한 문장으로 명확히 적습니다.
• 입력값과 출력값을 분리해 적습니다.
• 전송 대상 식별자를 명시합니다.
• 대상이 비어 있을 때의 동작을 명시합니다.
• 실패 시 재시도 여부를 적습니다.
• 중복 전송 방지 조건을 적습니다.
• 테스트 채널과 운영 채널을 분리합니다.
• 환경변수나 설정 파일의 의존 항목을 문서화합니다.

크론잡을 배포하기 전 아래를 확인합니다.

• 이 크론은 누가 실행하는가?
• 어떤 에이전트에서 실행되는가?
• 어떤 계정으로 메시지를 보내는가?
• 정확한 목적지 식별자가 있는가?
• 목적지 정보가 없을 때 안전하게 멈추는가?
• 테스트 채널에서 먼저 검증했는가?
• 중복 발송 방지 장치가 있는가?
• 오발송 시 빠르게 끌 수 있는가?

아래 방식은 멀티 에이전트 환경에서 지양합니다.

• 기본 채널에 자동 전송
• 마지막 활성 세션 재사용
• 사람 이름만 보고 목적지 결정
• accountId 없이 메시지 발송
• 실패 원인 기록 없이 자동 재시도 반복
• 테스트와 운영 목적지를 동일하게 사용

크론 설계 문서에는 아래 수준으로 명시하는 것이 좋습니다.

• 실행 에이전트: sungyong
• 채널: googlechat
• accountId: acc_sungyong
• 목적지 chat_id: googlechat:spaces/XXXXX
• 목적지 누락 시 동작: 발송하지 않고 오류 로그 기록
• 중복 방지: 동일 키 기준 1회만 발송
• 테스트 목적지: 별도 검증용 채널 사용

멀티 에이전트 환경의 크론잡은 잘 실행되는 것만으로는 충분하지 않습니다. 정확한 대상에게, 정확한 계정으로, 정확한 조건에서만 보내지도록 설계되어야 합니다.

특히 목적지 정보가 불명확한 상태에서는 보내지 않는 것이 기본 원칙이며, 이 원칙이 오발송과 운영 사고를 줄이는 가장 중요한 안전장치입니다.