자동화에는 통로와 기억이 필요했습니다

메일에서 필요한 정보를 읽고 내부 DB에 반영하는 자동화를 만들 때, 처음에는 n8n 하나로 끝낼 수 있을 거라고 생각했습니다.

메일 감지, 첨부파일 읽기, 텍스트 추출, 날짜와 금액 파싱, DB 조회, 매칭, 승인, 업데이트까지 노드를 계속 붙였습니다.

처음에는 잘 보였습니다. 그런데 로직이 늘자 화면을 스크롤하는 것도 어려워졌습니다. 메일 양식이나 DB 구조가 조금만 바뀌어도 어디가 문제인지 찾는 데 시간이 더 들었습니다.

결국 질문을 바꿨습니다.

“이 작업은 연결의 문제인가, 판단의 문제인가?”

메일을 받고 파일을 옮기고 정해진 시간에 신호를 보내는 일은 n8n이 잘했습니다. 반면 내부 데이터와 여러 조건을 비교하고, 예외를 처리하고, 결과를 검증하는 일은 코드와 테스트가 있는 쪽이 편했습니다.

그래서 n8n은 필요한 정보를 모아 넘기는 통로로 두고, 복잡한 매칭과 검증, 내부 DB 업데이트는 LISA 쪽에서 맡도록 구조를 나눴습니다. 확신이 없는 경우에는 자동 업데이트 대신 검토 대상으로 남겼습니다.

역할을 나누고 나서야 수정할 곳도 분명해졌습니다. 메일 수신이 문제인지, 텍스트 추출이 문제인지, 매칭 규칙이 문제인지, DB 업데이트가 문제인지 따로 볼 수 있었습니다.

그런데 자동화 구조가 커질수록 다른 문제가 생겼습니다. 해결 방법과 작업 기록이 여기저기 흩어졌습니다. 어떤 것은 대화창에 있었고, 어떤 것은 특정 컴퓨터에만 있었습니다. 다음 작업을 시작할 때마다 같은 배경을 다시 설명해야 했습니다.

그래서 Obsidian에 기록을 쌓기 시작했습니다. 오늘 한 일, 잘 안 된 일, 다음에 확인할 일을 Markdown으로 남기고, 프로젝트 문서와 자동화 문서를 같은 볼트에서 보게 했습니다.

여러 컴퓨터와 여러 AI를 연결하는 과정도 순탄하지 않았습니다. 동기화 경로를 잘못 잡기도 했고, 도구마다 읽는 설정 파일이 달라 MCP 연결이 안 붙기도 했습니다.

그래도 이 과정을 거치며 알게 됐습니다.

자동화에는 통로가 필요하고, 그 자동화를 계속 고치려면 기억이 필요합니다.

Obsidian은 제게 메모 앱이 아닙니다. 다음 사람이, 그리고 다음 AI가 다시 처음부터 설명을 듣지 않고 일을 이어가기 위한 업무의 기억입니다.

다음 글에서는 이 기록 위에 상주 에이전트를 붙이면서, 에이전트 수보다 역할과 창구가 중요하다는 것을 배운 이야기를 적어보겠습니다.

기록을 쌓으면서 문서의 내용만큼 파일의 위치와 이름도 중요하다는 것을 알게 됐습니다. 날짜와 주제를 남기고, 운영에 필요한 기록과 외부 참고 자료를 분리하니 나중에 문제를 찾는 시간이 달라졌습니다.

이전에는 “전에 비슷한 작업을 했던 것 같은데”라는 상태에서 대화 기록과 폴더를 뒤졌습니다. 지금은 작업이 끝난 뒤 그날의 판단과 다음 확인 사항을 남기기 때문에, 다음 작업이 완전히 새로 시작되지 않습니다.

AI에게도 같은 방식이 필요했습니다. 모델에게 기억력을 기대하기보다, 읽을 수 있는 문서와 규칙을 남기는 편이 더 현실적이었습니다. 맥락이 쌓일수록 브리핑과 초안의 품질도 조금씩 좋아지는 것을 봤습니다.

물론 기록이 많아지면 정리 비용도 생깁니다. 그래서 모든 것을 남기기보다는, 다음 판단과 복구에 도움이 되는 기록을 남기려 합니다. 업무의 기억은 많이 쌓는 것보다 다시 쓸 수 있게 쌓는 것이 더 중요했습니다.