AI 에이전트운영 AI의 기억과 실제 서버 상태의 구분
· 핀로그
- #Pico
- #Knowledge Graph
- #Operations
핀로그에서 인프라를 맡으며 다룬 정보에는 서로 다른 시간이 섞여 있었습니다. 배포 도구 Argo CD가 어떤 브랜치를 기준으로 배포하는지는 설정에 관한 정보입니다. 반면 어떤 Pod(Kubernetes에서 실행되는 단위)가 준비 완료(Ready) 상태였는지는 확인한 그 순간의 상태입니다.
운영 AI 피코의 운영 지식에는 둘 다 필요했습니다. 하지만 둘을 같은 방식으로 믿을 수는 없었습니다. 어제 정상이었다는 기록을 오늘의 정상 상태로 읽으면, 기록은 맞더라도 운영 판단은 틀릴 수 있으니까요.
문제
피코의 운영 지식에는 설정에서 확인한 구조와 특정 순간에 조회한 상태가 섞여 있었다. 과거에 정상이었다는 기록을 지금의 상태로 읽으면 운영 판단이 틀릴 수 있었다.
결정
관측과 구현 계약을 구분해 읽고, 원본(Raw)·지식 이력(events)·조회용 데이터(current)의 역할을 나눴다. 피코 지식 도구는 읽기 전용으로 두고, 지식 수집과 변경은 별도 저장소에서 따로 하게 했다.
결과
기억으로는 확인할 대상을 찾고, 현재 판단에 필요한 사실은 실제 시스템에서 다시 확인한다는 기준이 남았다. 읽기 전용으로 나눠도 과거 자료를 잘못 해석하는 문제는 남는다.
유효 시간이 다른 규칙과 상태
운영 정보를 읽을 때는 ‘관측’과 ‘구현 계약’을 구분해야 합니다. 관측은 특정 시점에 직접 조회한 값입니다. 구현 계약은 저장소 설정과 운영 문서에서 확인한 구조입니다.
관측
모니터링 workload(모니터링용으로 실행한 서비스들)가 Ready 상태였다.
그때의 상태를 설명합니다. 지금도 정상인지 알려면 다시 조회해야 합니다.
구현 계약
Argo CD가 main을 기준으로 배포를 조정한다.
운영 구조를 설명합니다. 이후 설정이 바뀌었는지는 따로 확인해야 합니다.
계약도 영원히 유효하지는 않습니다. 다만 순간마다 달라질 수 있는 health 값과 같은 종류의 정보는 아니에요. 검색 결과를 읽을 때 먼저 볼 것은 문장이 그럴듯한지가 아니었습니다. 어떤 시점의 무엇을 설명하는지였습니다.
원본·이력·조회용 데이터 분리
피코의 기억은 Pico Graph에 있었습니다. Pico Graph는 사람이 읽는 Wiki 화면이 아니었습니다. 피코가 운영 정보를 출처와 관계 중심으로 검색하는 내부 지식 저장소였습니다. 그 안의 데이터도 역할이 나뉘어 있었습니다.
불변 Raw
수집한 원본 근거events
추가 방식으로 남기는 정식 지식 이력current
이력으로부터 재생성 가능한 조회용 데이터
이 그림은 각 데이터의 역할 관계를 정리한 것입니다. 실제 서버 상태가 실시간으로 자동 동기화된다는 의미는 아닙니다.
store/events.jsonl이 정식 지식 이력이고, store/current.jsonl은 재생성 가능한 조회용 데이터였습니다. current라는 이름을 현재 운영 상태와 혼동하면 안 됩니다. 지식 저장소의 조회 결과가 최신이어도, 그 안에 담긴 관측은 과거의 것일 수 있습니다.
원본을 보존하고 조회 결과를 분리하면, 검색에서 찾은 설명의 근거로 돌아갈 수 있습니다. 하지만 출처가 있다는 것과 정보가 지금도 유효하다는 것은 별개였어요. 출처와 시점을 함께 읽어야 했습니다.
검색과 변경 권한 분리
Hermes에서 쓸 수 있게 열어 둔 피코의 지식 도구는 읽기 전용 조회만 할 수 있었습니다. 지식을 모으고 고치는 일은 별도 저장소에서 명시적으로 하도록 나눠 두었습니다.
이 경계에서는 운영 정보를 찾는 동작과 정식 지식을 바꾸는 동작이 같지 않습니다. 답변을 만들다 나온 추측이 검색 도구를 거쳐 곧바로 운영 기록을 고치는 구조는 아니었던 셈입니다.
그렇다고 읽기 전용이면 답변이 항상 정확해지는 것은 아닙니다. 과거 자료를 잘못 해석하거나 시점을 빠뜨리는 문제는 여전히 남습니다. 쓰기 권한을 나눈다고 정보의 정확성까지 대신할 수는 없었습니다.
"정상이었다"와 "정상이다"
“지금 모니터링이 정상인가요?”라는 질문을 예로 들어보겠습니다. 과거에 Ready였다는 기록은 확인했던 순간의 상태에 대한 근거입니다. 이것을 지금 상태를 묻는 질문에 그대로 답으로 쓰면, 확인 시점을 건너뛰게 됩니다.
질문의 시점 확인
과거 구조를 묻는지, 지금 상태를 묻는지 구분합니다.
기억에서 확인 대상을 찾기
저장된 구조와 근거를 통해 어떤 시스템과 항목을 조회할지 좁힙니다.
현재 판단은 원본에서 확인
호스트·Kubernetes·GitHub 등 실제 시스템의 상태를 확인합니다. 조회할 수 없다면 과거 기록만 있다는 한계를 밝힙니다.
이 세 단계는 제가 정한 사용 원칙입니다. 모든 질문에 실시간 조회가 자동으로 붙는 구조는 아니었어요. 운영 지식은 현재 조회를 없애기보다, 무엇을 조회해야 하는지 찾는 데 쓰는 편이 맞았습니다.
서버를 대신하지 못하는 기억
운영 기록을 다시 보면서 중요하게 본 것은 저장량보다 정보의 역할이었습니다. Raw는 근거를 보존하고, 이력은 지식의 변화를 남기고, 조회용 데이터는 검색을 돕습니다. 현재 상태에 대한 답은 여전히 실제 시스템에서 확인해야 합니다.
AI에게 기억을 주면 과거 맥락을 찾는 데 도움이 됩니다. 다만 그 기억이 지금의 서버를 대신하지는 않아요. 기억으로 확인할 대상을 찾고, 현재 판단에 필요한 사실은 다시 확인하는 것. 피코의 운영 지식에서 남기고 싶은 기준입니다.