Hindsight의 공식 API에는 기억을 조회하고 관리하는 경로와 파생 관찰 결과를 지우는 별도 경로가 있습니다. 기억 관찰 결과 정리 API에 따르면 관찰 결과 정리는 기억 자체를 삭제하는 작업과 구분해야 합니다. 이번 주에는 먼저 바꾸려는 대상이 기억, 관찰 결과, 원본 문서 중 무엇인지 확인하고, 처리 뒤 같은 질의로 회수 결과를 다시 검수하세요.
이 글은 Hindsight를 적용한 AI 에이전트의 장기 기억 변경을 출시 전에 검수하는 기술 책임자와 백엔드 개발자를 위한 안내입니다.
잘못된 사실을 고치는 방법뿐 아니라, 변경 요청이 끝났는지 확인하는 절차까지 다룹니다.
기억 수정과 삭제의 범위
Hindsight에서 문제가 생겼을 때 먼저 확인할 것은 데이터가 놓인 층입니다. 원본 문서에는 사용자가 제공하거나 처리한 자료가 있고, 기억은 그 자료에서 추출해 관리하는 사실입니다. 관찰 결과는 기억을 바탕으로 정리한 파생 정보입니다. 각 층은 서로 연결될 수 있지만, 한쪽을 바꾸는 요청이 나머지까지 자동으로 바꾼다고 가정하면 안 됩니다.
기억 목록 API로 기억을 확인하고, 공식 기억 관리 문서에서 수정과 무효 처리 동작을 확인하세요. 원본 문서의 상태와 처리 방법은 문서 관리 안내에서 따로 살펴볼 수 있습니다.
실제 선택은 다음처럼 구분하면 됩니다.
| 선택 | 적용할 문제 | 변경 뒤 확인할 점 |
|---|---|---|
| 기억 수정 | 기억의 사실 자체가 틀렸거나 오래된 경우 | 새 내용이 목록과 회수 결과에 반영되는지 확인합니다. |
| 기억 무효 처리 | 해당 사실을 더 이상 사용하지 않게 해야 하는 경우 | 무효 상태와 재회수 여부를 확인합니다. 영구 삭제로 간주하지 않습니다. |
| 관찰 결과 정리 | 기억은 유지하되 그에 딸린 파생 정보가 잘못된 경우 | 원본 기억은 남아 있는지, 관찰 결과가 다시 만들어지는지 확인합니다. |
| 원본 문서 삭제 | 문서 자체를 더는 보유하지 않아야 하는 경우 | 문서와 그 문서에서 생긴 기억 및 관찰 결과를 각각 점검합니다. |
기억 무효 처리가 보존이나 감사 기록에 어떤 영향을 주는지는 버전과 실제 API 동작으로 확인해야 합니다. 무효 처리라는 표현만으로 데이터가 완전히 지워졌다고 판단하지 마세요. 기억 회수 API를 사용해 에이전트가 실제로 받는 결과도 확인해야 합니다.
잘못된 사실과 오래된 관찰 결과
잘못된 사실이 계속 회수된다면 먼저 대상 기억을 좁히세요. 기억 목록에서 내용과 연결 정보를 확인한 다음, 사실 자체가 틀렸는지 파생 관찰 결과만 부정확한지 판단합니다. 사실이 틀렸다면 기억을 수정하거나 무효 처리하는 쪽이 적절합니다. 기억은 맞지만 정리된 정보가 오래됐다면 관찰 결과를 별도로 정리하는 편이 낫습니다.
관찰 결과 정리를 요청한 뒤에는 바로 완료됐다고 단정하지 마세요. 비동기 작업 안내에서 작업 상태를 확인하고, 완료된 다음 기억 조회와 회수 시험을 이어가세요. 작업 요청에 성공했다는 API 응답과 실제 후속 처리가 끝났다는 상태는 서로 다를 수 있습니다.
기억 내용을 바꾸는 방식은 특정한 버전이나 API에 따라 달라질 수 있습니다. 공식 API 참고 문서의 현재 명세와 사용 중인 배포 버전을 함께 대조하세요. 문서가 설명하는 동작을 실제 환경에서 확인하기 전까지는 삭제 범위나 보존 여부를 확정적으로 안내하지 않는 것이 안전합니다.
원본 문서와 재처리 위험
기억을 수정하거나 무효 처리해도 원본 문서에 적힌 옛 사실이 자동으로 바뀌는 것은 아닙니다. 반대로 원본 문서를 정리했더라도 이미 만들어진 기억과 관찰 결과가 모두 없어졌다고 보장할 수는 없습니다.
따라서 원본 문서가 계속 남아 있는 경우에는 다음 순서로 처리하세요.
- 테스트 환경에서 원본 문서를 조회하고, 문제가 된 사실이 원문에 남아 있는지 확인합니다.
- 원본이 여전히 유효하다면 먼저 문서를 올바른 내용으로 수정하거나 삭제합니다.
- 공식 문서에 따라 문서 처리 작업을 요청하고, 작업 상태가 완료될 때까지 기다립니다.
- 연결된 기억을 조회해 옛 사실이 남았는지 확인한 뒤 필요한 기억을 수정하거나 무효 처리합니다.
- 파생 관찰 결과를 점검하고, 같은 질의로 에이전트의 회수 응답을 다시 시험합니다.
삭제 동작과 문서 처리 상태는 문서 삭제 API와 공식 API 참고 페이지를 기준으로 확인하세요. 문서를 다시 처리할 수 있는 구조라면, 수정하지 않은 원문에서 옛 사실이 재생성되는 상황도 시험에 포함해야 합니다.
변경 요청을 검수하는 체크리스트
테스트 환경에서 대상 사용자나 데이터 범위를 격리한 뒤, 아래 항목을 기록하세요. 결과를 화면에만 남기지 말고 API 응답과 작업 상태도 함께 보관합니다.
- [ ] 잘못된 기억의 식별 정보와 변경 전 내용을 기록했습니다.
- [ ] 원본 문서에 같은 사실이 남아 있는지 확인했습니다.
- [ ] 기억 수정, 무효 처리, 관찰 결과 정리 중 필요한 작업만 실행했습니다.
- [ ] 비동기 작업이 있다면 완료 상태를 확인했습니다.
- [ ] 기억 목록에서 변경 뒤의 내용을 조회했습니다.
- [ ] 같은 질의로 회수해 잘못된 사실이 다시 나오지 않는지 확인했습니다.
- [ ] 원본 문서 삭제를 요청한 경우 문서 상태와 연결된 기억 및 관찰 결과를 각각 확인했습니다.
- [ ] 작업 응답, 상태 조회, 회수 시험 결과를 검수 기록에 남겼습니다.
이 검수에서 중요한 것은 “삭제 요청이 성공했다”는 응답과 “에이전트가 더는 해당 사실을 사용하지 않는다”는 결과를 구분하는 일입니다. 문제가 남으면 먼저 작업 완료 여부와 원본 재처리 가능성을 확인하세요. 그 뒤 기억과 관찰 결과를 다시 조회하면 원인을 좁히기 쉽습니다.
자주 확인하는 기억 변경 문제
잘못된 기억의 재회수 차단
잘못된 기억이 다시 나오는 경우에는 수정 대상이 정확했는지부터 확인하세요. 관련 기억이 여러 개라면 하나만 바꿔도 다른 기억에서 같은 사실이 회수될 수 있습니다. 목록 조회로 관련 항목을 확인하고, 동일한 질의로 변경 전후 결과를 비교하세요. 관찰 결과가 원인이라면 기억 수정만으로 해결됐다고 판단하지 마세요.
무효 처리와 보존 여부
무효 처리는 다시 사용하지 않도록 관리하는 조치이지, 모든 저장 정보를 영구히 지웠다는 보증이 아닙니다. 보존 정보가 필요한 서비스라면 사용 중인 API 문서와 실제 응답을 기준으로 확인하고, 별도로 정한 보존 정책과도 대조하세요. 불명확한 점은 테스트 환경에서 확인한 뒤 출시 판단에 반영해야 합니다.
관찰 결과 정리와 원본 기억
관찰 결과를 비워도 원본 기억은 별도로 남을 수 있습니다. 정리 요청을 완료한 뒤 기억 목록에서 원본 상태를 확인하고, 관찰 결과가 새로 만들어지는지도 점검하세요. 원본 기억까지 없어져야 하는 요구라면 관찰 결과 정리만으로 완료 처리하지 말고 기억 관리 API의 삭제 동작을 따로 확인해야 합니다.
원본 문서 삭제 뒤의 검증
문서 삭제 뒤에는 문서 상태만 보지 말고 기억 목록과 회수 결과까지 확인하세요. 처리 중인 작업이 있다면 완료 상태를 기다린 뒤 시험해야 합니다. 원본 문서를 재처리할 수 있는 경로가 남아 있으면 옛 내용이 다시 유입되지 않는지도 확인하세요. 삭제 범위가 확실하지 않은 상태에서는 데이터가 완전히 제거됐다고 기록하지 마세요.
Hindsight 기억 삭제와 변경 검수는 재현 가능한 테스트 환경에서 진행할 때 판단이 명확해집니다. 현재 개발 환경을 여러 사람이 함께 쓰거나 데이터가 섞인 서버에서 시험하면, 변경 전후 차이를 분리하기 어렵고 원본 재처리 여부도 놓치기 쉽습니다. 지속적인 고정 부하나 물리 장치 연결이 필요하다면 장비를 직접 운영하는 편이 나을 수 있습니다. 다만 임시 검수 환경을 분리해 반복 시험하려는 경우에는 Hashvps의 맥 대여도 선택지로 비교해 보세요. 맥 이용 구성 안내에서 이용 조건을 확인하고, 에이전트 실행 환경을 함께 검토하려면 에이전트 운영 안내도 참고할 수 있습니다.
에이전트 검수 환경을 클라우드 맥에서 마련하세요
Hashvps의 전용 맥 미니에서 기억 수정과 삭제 뒤의 회수 결과를 반복해서 확인해 보세요.
애플 실리콘 기반 연산 자원으로 개발과 검수 작업을 이어가세요.