에이전트가 스스로 고치게 만드는 로그 설계 (2026)

자동화가 멈추는 지점은 대개 코드가 아니라 기록이 부족한 자리입니다.

작업을 대신 수행하는 프로그램에게 가장 부족한 것은 지능이 아니라 상황 정보입니다.

사람은 화면을 보고, 이전 실행을 기억하고, 이상한 점을 눈치챕니다.

자동화된 실행기는 그 셋 중 아무것도 기본으로 갖고 있지 않습니다.

그래서 남긴 기록이 곧 그 시스템이 아는 전부가 됩니다.

매일 정해진 시각에 갱신되는 일정 데이터가 어떻게 정리돼 나오는지는 https://dinsightlab.com 의 캘린더 화면에서 볼 수 있습니다.

한곳에 모으는 것이 먼저다

로그가 여러 파일과 여러 서비스에 흩어져 있으면 원인을 찾는 데 대부분의 시간이 갑니다.

사람에게도 그렇지만 자동 실행기에게는 더 치명적입니다.

읽어야 할 위치를 모르면 확인 자체를 건너뜁니다.

그래서 실행, 오류, 외부 호출 결과를 한 흐름으로 모으는 것이 첫 단계입니다.

같은 요청에서 나온 기록에는 같은 식별자를 붙여 둡니다.

무엇을 남길 것인가

첫째, 무엇을 시도했는지입니다. 어떤 입력으로 어떤 작업을 실행했는지 남깁니다.

둘째, 결과가 무엇인지입니다. 성공과 실패뿐 아니라 부분 성공도 구분합니다.

셋째, 다음에 무엇을 해야 하는지입니다. 재시도 가능 여부와 대기 시간까지 적으면 자동 복구가 가능해집니다.

넷째, 언제 일어났는지입니다. 시각이 없으면 순서를 재구성할 수 없습니다.

사람이 읽는 로그와 기계가 읽는 로그

두 가지 목적을 하나의 형식으로 만족시키기는 어렵습니다.

사람은 맥락이 담긴 문장을 원하고, 자동 실행기는 구조가 명확한 항목을 원합니다.

실무에서는 구조화된 항목을 기본으로 남기고, 사람이 보는 화면에서 문장으로 변환하는 방식이 편합니다.

핵심은 오류 메시지를 요약하지 않고 원문 그대로 남기는 것입니다.

요약된 오류는 원인을 지우고, 지워진 원인은 같은 실패를 반복하게 만듭니다.

복구를 설계에 넣는다

기록이 잘 남으면 다음 단계가 가능해집니다.

실패한 작업을 다시 시도할지, 건너뛸지, 사람에게 알릴지를 규칙으로 정할 수 있습니다.

정해 둘 항목은 네 가지입니다.

재시도 횟수, 재시도 간격, 포기 조건, 알림 조건입니다.

이 네 가지가 없으면 자동화는 무한 반복이나 조용한 중단 중 하나로 끝납니다.

검증은 실패를 일부러 만들어서 한다

로그 설계가 제대로 됐는지 확인하는 방법은 단순합니다.

외부 호출을 일부러 실패시키고, 그 기록만 보고 원인을 찾을 수 있는지 봅니다.

찾을 수 없다면 남기는 항목이 부족한 것입니다.

같은 방식으로 데이터 지연, 빈 응답, 형식 변경도 시험해 봅니다.

실제 서비스에서 매일 갱신되는 화면은 이런 실패 처리 규칙 위에서 돌아갑니다. https://dinsightlab.com 에서 갱신 시각과 함께 확인할 수 있습니다.

정리

자동화의 품질은 실행 기록의 품질을 넘지 못합니다.

한곳에 모으고, 시도와 결과와 다음 행동을 함께 남기고, 오류는 원문 그대로 보존합니다.

재시도와 포기 조건까지 정해 두면 그때부터 자동 복구가 가능해집니다.

매일 자동으로 갱신되는 화면이 어떻게 보이는지는 https://dinsightlab.com 의 캘린더 화면에서 확인해 보시기 바랍니다.