시스메틱 데일리코딩 못해도 AI로 자동화 시스템 만드는 법
AI 도구

지침 말고 기억 — 에이전트 메모리 서버 등장

지침 파일이 1,000줄로 부푸는 이유와, 알아낸 것을 남기는 다른 방법

인공지능 에이전트가 작업 중에 알아낸 것을 세션이 끝나도 남겨 두는 메모리 서비스가 등장했다. 노운베이스(Knownbase)라는 이름의 이 서비스는 MCP 서버 형태로 붙어, 에이전트가 스스로 기록하고 다음 에이전트가 검색해 꺼내 쓰는 구조를 만든다. 이 서비스가 내건 대비는 선명하다 — 깃(Git)은 무엇이 바뀌었는지 기억하지만, 왜 그렇게 했는지는 기억하지 못한다.

무슨 일인가 / 배경

에이전트를 오래 써 본 사람이라면 익숙한 장면들이 있다. 대화가 길어져 맥락이 압축되는 순간, 두 시간 전에 겨우 알아낸 원인이 한 줄 요약으로 뭉개진다. 지난달에 이미 폐기한 접근법이 이번 달에 다시 제안된다. 한 도구에서 밝혀낸 사실이 다른 도구로 옮기면 통째로 사라져 처음부터 설명해야 한다.

그러다 보면 알아낸 것을 둘 곳이 지침 파일밖에 없어 그 파일이 계속 부푼다. 지침 파일이 1,000줄을 향해 자라는 프로젝트가 드물지 않은데, 이 서비스는 그 비대화를 지식을 넣을 자리를 따로 만들지 않은 결과로 진단한다.

핵심 짚어보기

제안하는 구분은 간단하다. 지침 파일은 '이 저장소에서 어떻게 행동할 것인가'를 담는 규칙이고, 메모리는 '이 프로젝트에 대해 무엇을 알아냈는가'를 담는 축적이다. 성격이 다르니 다루는 방식도 달라야 한다는 것이다.

지침 파일은 세션마다 통째로 읽히기 때문에 길어질수록 매 차례 비용이 붙고, 짧게 유지될 때만 쓸모가 있다. 반면 메모리는 필요할 때 검색해 관련된 조각만 꺼내므로 양이 늘어도 꺼내는 비용이 함께 늘지 않는다. 작성 주체도 다르다. 지침은 사람이 편집기로 쓰지만, 메모리는 에이전트가 일하면서 쌓는다.

저장 대상으로 제시된 항목은 여섯 가지다. 아키텍처 결정의 근거, 디버깅 과정에서 밝혀낸 원인, 이미 시도했다 실패한 접근, 배포와 환경의 함정 같은 운영 제약, 오류 처리나 이름 짓기 같은 프로젝트 관례, 그리고 세션 인계 메모다. 이 가운데 만든 쪽이 가장 값어치 있다고 꼽은 것은 실패한 접근의 기록이다. 성공한 코드는 저장소에 남지만 무엇을 시도했다 왜 접었는지는 어디에도 남지 않기 때문이다.

연결은 MCP 표준을 쓰는 도구라면 어디서든 붙는다. 노트는 프로젝트 단위로 묶이고 버전이 관리되며 서로 연결할 수 있다. 벡터 데이터베이스를 직접 운영하거나 저장소 구조를 바꿀 필요는 없다.

1인기업 실전 적용 포인트

  • 실패 기록부터 만들어라. 도구를 도입하지 않더라도 오늘 당장 할 수 있다. '시도한 것 / 안 된 이유 / 대신 택한 것' 세 줄이면 충분하고, 이 기록 하나가 몇 달 뒤 같은 삽질을 통째로 막는다.
  • 지침과 기억을 물리적으로 분리하라. 지침 파일이 길어졌다면 그 안에서 규칙이 아닌 문장을 골라내 별도 파일로 옮긴다. 규칙만 남은 지침 파일은 에이전트가 훨씬 잘 지킨다.
  • 세션 끝에 인계 세 줄을 남겨라. 끝낸 것, 진행 중인 것, 다음 한 걸음. 하루 뒤의 자신도 남이라는 전제로 쓰면 다음 작업 시작이 몇 분 단축된다.
  • 도구를 바꿀 때 무엇이 사라지는지 세어 보라. 다른 에이전트로 옮겼을 때 다시 설명해야 하는 항목이 곧 기록해야 할 목록이다.

전망 / 주의점

외부 서비스에 프로젝트 지식을 맡기는 일에는 대가가 따른다. 결정 근거와 운영 제약은 그 자체로 회사의 자산이므로, 어디에 저장되는지와 나중에 통째로 내려받을 수 있는지를 먼저 확인해야 한다. 계정 정보나 접속 키, 고객 개인정보가 메모에 섞여 들어가지 않도록 하는 규칙도 처음부터 필요하다. 기억을 남기는 일 자체가 유출 경로를 하나 더 만드는 일이기도 하다. 서비스를 쓰든 안 쓰든, 알아낸 것을 남기지 않으면 같은 문제를 계속 다시 푼다는 지적만은 유효하다.

출처: 노운베이스 공식 사이트 (https://knownbase.dev/)
← 전체 기사 보기