지금은 자동화보다 운영을 먼저 봅니다

LISA를 만들고, Obsidian에 기록을 쌓고, n8n과 상주 에이전트를 붙여보면서 처음보다 더 중요하게 보게 된 것이 있습니다.

자동화의 성패는 모델 성능만으로 결정되지 않는다는 점입니다.

자동화는 조용히 실패할 때가 가장 어렵습니다. 새벽에 돌아야 할 작업이 멈췄거나, 알림은 왔는데 상태가 바뀌지 않았거나, 결과는 만들어졌는데 외부로 내보내면 안 되는 정보가 남아 있는 경우가 있습니다.

예전에는 문제가 생기면 그때 고치고 지나갔습니다. 그러면 며칠 뒤 비슷한 문제가 다시 나왔고, 왜 전에 고쳤는지 찾는 데 시간을 썼습니다.

그래서 실패 기록을 남기기 시작했습니다. 작업이 무엇이었는지, 실패 유형이 무엇인지, 원인이 무엇이었는지, 어떻게 고쳤는지, 다음부터 어떤 규칙을 적용할지를 적습니다.

이 기준은 기술적인 오류에만 적용하지 않습니다. 라우팅을 잘못했거나, 민감한 내용을 외부로 보내기 직전에 멈췄거나, 검토 대상이 너무 오래 쌓이는 일도 모두 운영에서 배우는 실패입니다.

지금은 세 가지를 먼저 봅니다.

첫째, 외부로 나가기 전 확인입니다. 고객·계약·금액처럼 민감할 수 있는 정보가 외부 모델이나 메신저로 바로 나가지 않게 합니다.

둘째, 실패 로그입니다. 같은 일이 다시 생겼을 때 사람의 기억에만 기대지 않도록, 원인과 수정, 다음 규칙을 남깁니다.

셋째, 이벤트 기반 실행입니다. 모든 것을 계속 감시하는 대신 새 메일, 자동화 오류, 검토 대기처럼 조건이 분명할 때만 움직이게 하는 쪽이 지금 환경에는 더 안정적이었습니다.

현재 제 작업 환경은 LISA, Obsidian, n8n, 에이전트가 서로 연결된 형태입니다. 완성된 플랫폼이라기보다, 실제 업무를 덜 반복하기 위해 계속 고치고 있는 환경에 가깝습니다.

어떤 자동화는 문서와 정기 점검까지 정리됐고, 어떤 것은 실제 연결과 검증을 더 해야 합니다. 그래서 완료한 것과 실험 중인 것을 구분해서 기록하려고 합니다.

1년 전에는 새 도구가 나오면 무엇을 더 할 수 있을지부터 봤습니다.

지금은 먼저 묻습니다.

이 결과는 어디에 기록되는가. 문제가 생기면 누가 확인하는가. 다음 사람이 이 흐름을 이해할 수 있는가.

도구는 계속 바뀌겠지만, 이 질문들은 남을 것 같습니다.

제가 만들고 있는 것은 완벽한 자동화가 아닙니다. 사람이 같은 판단을 반복하지 않아도 되고, 문제가 생겨도 다시 찾아갈 수 있는 업무 구조입니다.

이 기준은 대시보드를 만들 때도 비슷했습니다. 숫자를 보기 좋게 보여주는 것보다, 그 숫자를 보고 다음에 무엇을 확인해야 하는지가 더 중요했습니다. 기록에 정정이 필요하면 정정한 이유도 남기려 했습니다. 그래야 다음 판단에서 이전 숫자를 그대로 믿고 넘어가지 않을 수 있습니다.

백업과 복원도 같은 맥락입니다. 자동화가 잘 돌아갈 때는 존재를 잊기 쉽지만, 문제가 생긴 뒤 원래 상태로 돌아갈 수 있는지가 실제 운영에서는 더 중요할 때가 있습니다.

그래서 지금도 새 도구나 새로운 에이전트를 붙일 때는 작은 범위에서 먼저 테스트합니다. 어디에 기록이 남는지, 실패하면 누가 알림을 받는지, 수동으로 되돌릴 수 있는지를 확인한 뒤 다음 단계로 넓힙니다.

이 방식이 가장 빠른 길은 아닐 수 있습니다. 하지만 업무와 고객 데이터가 연결되는 환경에서는, 한 번의 멋진 데모보다 오래 다시 사용할 수 있는 흐름이 더 중요하다고 생각합니다.