빈 주간 요약 보고서 때문에 자동화가 실패한 줄 알았네요

그 문장을 빈 초안이 아니라 트래커 확인 결과에 따라 조건부로 나오게 만들겠어. 상황은 여러 가지가 있지:

• 의도한 프로젝트/날짜 범위에 대해 풀(pull)이 완료되었고 결과가 0건임.
• 결과는 나왔지만 요약에 포함될 규칙을 충족하는 게 없음.
• 풀이 불완전하거나 실패함.

첫 번째와 두 번째 경우에만 '보고할 내용 없음'이 정당화돼. 검토자를 위해 초안 옆에 작은 영수증 같은 정보를 남겨두는 걸 추천해: 프로젝트/필터, 날짜 범위 및 시간대, 가져온 개수, 그리고 모든 페이지가 다 가져와졌는지 여부 같은 거. 이건 배포되는 요약본에는 안 들어가도 돼.

유용한 테스트 방법은 트래커 풀의 두 번째 페이지가 실패하게 만들어 보는 거야. 결과는 '요약본을 검증할 수 없음'이라고 나와야지, 아무 일도 없었던 주와 똑같은 안심시키는 문구가 나오면 안 돼.

자동화 시스템이 요약본과 함께 트래커 쿼리 상태도 포함하게 할 수는 없을까? '쿼리 성공, 이번 주 업데이트된 이슈 0건' 같은 식으로 나오면 검토자들이 빈 결과도 믿을 수 있을 텐데. '보고할 내용 없음'이라는 메시지만 달랑 있으면 데이터 풀이 제대로 완료된 건지 계속 의심하게 되거든.

나도 주간 보고서에서 똑같은 일을 겪었어. 내가 해결한 방법은 풀 과정에서 에러가 나면 아예 아무것도 보내지 않고 실패를 확실하게 알리는 거였어. 그래야 0건으로 나가는 요약본은 항상 진짜로 0건이라는 의미가 되니까. 지난주 수치랑 비교도 해봐? 바쁜 주 다음에 갑자기 0으로 떨어지면 보통 한 번 더 확인해 볼 필요가 있거든.

이건 사실 소프트웨어 공학에서 중요한 개념이야. Null 포인터와 같은 맥락이지. 질문에 대한 응답은 항상 모호하지 않아야 해.

예를 들어, 무언가를 제출하는 API 메서드를 설계한다고 치자. 실패하면 에러를 반환하고 성공하면 아무것도 반환하지 않게 설계할 수도 있겠지. 하지만 '아무것도 없음'이라는 응답이 진짜 성공했다는 걸 어떻게 확신하지? 어떤 오류 때문에 에러 메시지가 잘린 건 아닐까? 에러와 성공 사이의 어떤 유스케이스를 놓친 건 아닐까? 성공이나 실패 여부, 그리고 그 이유를 항상 반환함으로써 밤잠 설치게 만드는 문제들을 원천 차단할 수 있어. 로그에 Ack(확인 응답)가 찍힌 PUT 요청이 아무것도 없는 것보다 문제 해결하기 훨씬 쉽거든.

에이전트도 결국 소프트웨어일 뿐이야. 똑같은 공학 원칙이 적용되지.