에러 처리와 실행 로그 모니터링

아무리 잘 설계된 자동화 시나리오라도 에러는 반드시 발생합니다. 네트워크가 불안정할 수 있고, 외부 API가 일시적으로 중단될 수 있고, 예상하지 못한 데이터 형식이 들어올 수 있습니다. 중요한 것은 에러가 발생하지 않는 시나리오를 만드는 것이 아니라, 에러가 발생했을 때 적절히 대응하는 시나리오를 만드는 것입니다.

에러 처리가 없는 시나리오의 문제점:

1. 데이터 유실: 에러로 중단되면 처리되지 않은 데이터가 사라집니다. 예를 들어 WordPress 새 글을 감지했지만 Slack 전송에서 에러가 나면, 해당 글에 대한 알림은 영영 전송되지 않습니다.

2. 연쇄 실패: 하나의 모듈 에러가 전체 시나리오를 중단시킵니다. 10개의 글을 처리하는 중 3번째에서 에러가 나면, 4~10번째 글은 아예 처리되지 않습니다.

3. 무인 장애: 에러가 발생해도 아무도 모릅니다. 며칠 후에야 "왜 Slack 알림이 안 오지?"라고 깨닫게 됩니다.

4. 디버깅 어려움: 에러 정보가 기록되지 않으면 원인 파악이 매우 어렵습니다.

Make.com에서 발생하는 에러는 크게 네 가지로 분류됩니다. 각 유형별로 원인과 대응 방법이 다르므로, 정확히 구분할 수 있어야 합니다.

401 Unauthorized: Application Password가 만료되었거나 변경된 경우. 새 비밀번호를 생성하고 Make.com 연결을 업데이트하세요.

403 Forbidden: 사용자 권한 부족. 연결 계정의 역할을 확인하세요.

404 Not Found: 삭제된 글이나 존재하지 않는 리소스에 접근. 필터로 사전 검증하세요.

429 Too Many Requests: API 속도 제한. 실행 간격을 늘리거나 요청 수를 줄이세요.

500 Internal Server Error: WordPress 서버 문제. 서버 로그를 확인하고, 재시도를 설정하세요.

503 Service Unavailable: 서버 과부하 또는 유지보수 모드. 일시적인 문제이므로 재시도로 해결됩니다.