회사가 한 직원의 글, 회의 기록, 업무 방식, 판단 기준을 AI 에이전트에 계속 넣어 왔다고 해보자. 그 직원이 퇴사한 뒤에도 에이전트는 남아 비슷한 문체로 글을 고치고, 과거 결정을 참고하고, 동료에게 업무 맥락을 설명한다. 이제 퇴사 절차는 계정을 닫고 노트북을 반납받는 것으로 끝나지 않는다. 그 사람에게서 만들어진 디지털 업무 기억을 회사가 어디까지 계속 보유하고 사용할 수 있는가라는 문제가 남는다.
최근 한 인터뷰에서는 개인의 과거 글을 읽힌 글쓰기 에이전트가 편집자처럼 작동하고, 블로그 전체를 넣는 과정이 1~2분에 끝났다는 사례가 소개됐다.[^1] 여기서 말하는 ‘학습’은 보통 거대한 모델의 가중치를 다시 훈련하는 것과는 다르다. 현재의 에이전트 메모리는 대화와 문서를 요약하고, 임베딩으로 색인하고, 사실·선호·규칙을 장기 저장한 뒤 필요할 때 검색해 컨텍스트에 다시 넣는 방식으로 구현할 수 있다. Oracle의 최신 Agent Memory 문서도 장기 메모리를 사용자 선호, 학습된 규칙, 과거 사실을 세션 사이에 보존하는 계층으로 설명한다.[^2][^3]
이 구조가 보편화되면 회사가 얻는 자산의 성격도 달라진다. 직원이 만든 문서만 남는 것이 아니라 그 문서를 어떻게 읽고, 어떤 예외를 중요하게 보고, 어떤 순서로 판단했는지를 압축한 운영 메모리가 남을 수 있다. 이때 “에이전트의 소유권은 회사인가 직원인가”라는 질문 하나로는 부족하다. 에이전트 안에는 법적 성격이 다른 자산들이 섞여 있기 때문이다.
하나의 에이전트 안에는 서로 다른 자산이 겹쳐 있다
직원 기반 에이전트를 하나의 복제본처럼 보면 문제를 지나치게 단순화하게 된다. 실제 시스템은 여러 층으로 나뉜다.
회사가 제공한 매뉴얼과 업무 문서가 있고, 직원이 고용관계 안에서 작성한 보고서와 코드가 있다. 직원 개인의 공개 글이나 말투가 들어갈 수도 있다. 고객정보, 가격정책, 소스코드처럼 영업비밀에 가까운 정보도 섞인다. 그 위에 시스템이 자동으로 만든 요약, 임베딩, 메모리 카드, 선호 추정, 작업 규칙이 쌓인다. 마지막으로 이 정보를 불러오는 프롬프트, 검색기, 도구 권한, 평가 데이터와 하니스가 있다.
따라서 에이전트를 자산으로 관리하려면 최소한 다음을 구분해야 한다.
| 층 | 예시 | 퇴사 시 핵심 질문 |
|---|---|---|
| 원본 업무산출물 | 보고서, 코드, 회의록 | 회사가 계속 사용할 권리가 명확한가 |
| 개인 자료 | 개인 블로그, 공개 글, 개인 선호 | 어떤 목적으로 가져왔고 계속 보존할 근거가 있는가 |
| 회사 기밀 | 내부 정책, 고객정보, 가격, 기술 | 접근권한과 비밀관리 조치가 유지되는가 |
| 파생 메모리 | 요약, 임베딩, learned rules, preference | 어떤 원본에서 만들어졌는지 추적 가능한가 |
| 실행 계층 | 프롬프트, 스킬, 도구 권한, 하니스 | 퇴사자의 자격증명이나 권한을 계속 상속하고 있지 않은가 |
이 구분이 필요한 이유는 ‘회사 데이터로 만들었으니 전부 회사 것’도, ‘한 사람의 업무 스타일을 배웠으니 전부 개인 것’도 정확하지 않기 때문이다.
저작권은 일부만 설명한다
미국 저작권 제도에는 고용 범위 안에서 만든 저작물이 work made for hire에 해당하면 고용주가 저자로 간주될 수 있다는 오래된 원칙이 있다. 미국 저작권청도 직원이 직무 범위 안에서 만든 글은 이 원칙이 적용될 수 있다고 설명한다.[^4] 회사 업무로 작성한 보고서나 코드의 권리관계를 생각할 때 중요한 출발점이다.
하지만 이 원칙을 그대로 “직원으로부터 만들어진 에이전트 전체는 회사 저작물”이라고 확장하기는 어렵다. 에이전트의 메모리에는 저작권이 보호하는 표현뿐 아니라 사실, 업무 절차, 통계적 표현, 요약, 검색용 벡터가 함께 들어간다. AI가 새로 생성한 결과물도 별도 문제다. 미국 저작권청은 생성형 AI 결과가 보호되려면 충분한 인간의 창작적 기여가 있어야 하며, 프롬프트를 제공했다는 사실만으로는 일반적으로 충분하지 않다고 정리하고 있다.[^5]
반대로 회사의 핵심 업무 노하우는 저작권이 아니라 영업비밀이나 계약, 보안정책의 문제일 수 있다. 미국 연방법은 공개되지 않은 방법·절차·프로세스·프로그램 같은 정보가 경제적 가치를 가지고 회사가 합리적인 비밀유지 조치를 취했다면 영업비밀이 될 수 있도록 정의한다.[^6]
즉 같은 에이전트 안에서도 원본 보고서는 저작권 문제, 내부 절차는 영업비밀 문제, 직원의 개인적 대화는 개인정보 문제, 자동 생성된 임베딩은 데이터 거버넌스 문제로 갈라질 수 있다. 실제 권리관계는 국가와 계약에 따라 달라지므로 법적 판단은 별도로 필요하지만, 기술 설계 단계에서부터 이 층을 섞지 않는 것이 중요하다.
메모리는 ‘복사본’보다 관리하기 어렵다
문서 한 파일은 출처가 비교적 명확하다. 누가 만들었는지, 어디에 저장됐는지, 언제 수정됐는지 확인하기 쉽다. 에이전트 메모리는 그렇지 않다.
예를 들어 직원과의 수백 번의 대화에서 “이 고객에게는 먼저 숫자를 보여준다”, “이 보고서는 금요일 오전에 보낸다”, “이 팀은 이런 표현을 싫어한다” 같은 규칙이 추출됐다고 하자. 이 정보는 원문 한 곳에 존재하지 않을 수 있다. 여러 대화를 요약하고, 시스템이 중요하다고 판단해 장기 메모리로 승격한 결과일 수 있다.
Oracle은 최근 에이전트 메모리를 별도의 엔터프라이즈 계층으로 다루면서 단기 요약과 장기 기억을 분리하고, 장기 메모리에 사실·선호·학습된 규칙을 저장하도록 설계했다. 동시에 실제 애플리케이션이 사용자 인증, 권한, 올바른 메모리 범위 설정을 책임져야 한다고 명시한다.[^3] 메모리가 유용해질수록 출처와 범위를 관리하는 일이 애플리케이션 책임으로 남는다는 뜻이다.
이 때문에 직원이 떠난 뒤 단순히 원본 계정을 비활성화해도 문제가 끝나지 않는다. 이미 요약된 메모리, 벡터 인덱스, 컨텍스트 카드, 스킬 설명에 그 직원의 정보가 남아 있을 수 있다. 반대로 전부 삭제하면 회사가 합법적으로 보존해야 하는 업무 기록과 운영 노하우까지 함께 사라질 수 있다.
퇴사 절차에 ‘메모리 인벤토리’가 들어가야 한다
기존 IT 오프보딩은 비교적 명확하다. 이메일과 SaaS 계정을 회수하고, 인증키를 폐기하고, 회사 장비를 반납받는다. 에이전트가 직원의 업무 맥락을 장기간 저장하는 환경에서는 하나의 단계가 더 필요해진다. 이 사람이 남긴 에이전트 메모리의 출처와 보존 근거를 다시 확인하는 것이다.
먼저 원본을 구분해야 한다. 회사 업무로 만든 문서인지, 직원이 개인적으로 가져온 자료인지, 공개 웹에서 읽은 자료인지, 고객이나 동료의 정보가 포함됐는지를 기록해야 한다. 다음으로 파생 메모리가 어느 원본에서 만들어졌는지 연결해야 한다. 그래야 원본을 삭제하거나 접근권한을 바꿨을 때 파생 메모리도 함께 재평가할 수 있다.
권한은 즉시 끊어야 한다. 퇴사자의 OAuth 토큰, 메일 접근, 개인 캘린더, 개인 드라이브 연결을 에이전트가 계속 쓰게 두면 메모리 보존과는 전혀 다른 보안사고가 된다. 남겨야 할 업무 메모리가 있더라도 실행권한을 그대로 상속할 이유는 없다.
개인정보가 들어간 경우에는 보존기간도 별도의 문제다. EU GDPR의 기본 원칙은 개인정보를 명시적 목적에 맞게 처리하고, 필요한 범위로 제한하며, 필요한 기간보다 오래 식별 가능한 형태로 보관하지 말 것을 요구한다.[^7] 모든 직원 메모리에 GDPR이 그대로 적용된다는 뜻은 아니다. 다만 “나중에 쓸 수도 있으니 계속 기억한다”는 운영 관행은 개인정보 거버넌스 관점에서 설명하기 어려운 설계가 될 수 있다는 점은 분명하다.
회사가 얻는 것은 사람의 복제본보다 ‘조직 메모리’에 가깝다
이 기술의 가장 큰 가치는 직원 한 명을 그대로 복제하는 데 있지 않을 수 있다. 더 현실적인 효과는 그동안 사람 사이의 인수인계로만 전달되던 작은 운영 규칙을 회사가 구조적으로 보존할 수 있다는 데 있다.
예전에는 베테랑이 퇴사하면 왜 특정 고객에게 다른 절차를 쓰는지, 어떤 장애는 어떤 로그부터 확인해야 하는지, 회의에서 누가 무엇을 결정했는지가 함께 사라지기 쉬웠다. 문서화를 잘해도 실제 업무의 예외처리까지 전부 적기는 어렵다. 장기 메모리를 가진 에이전트는 이 중 일부를 지속적으로 축적할 수 있다.
AIEngin의 Agent Memory 워크숍도 모델 자체보다 storage, memory engineering, semantic layer, context engineering, continual learning을 하나의 하니스로 다룬다.[^2] 모델을 교체해도 남는 것은 데이터와 메모리 구조라는 관점이다. 조직 입장에서 보면 AI 자산의 중심이 특정 모델에서 누적된 업무 맥락과 이를 다시 꺼내 쓰는 체계로 이동할 수 있다는 뜻이다.
다만 이 변화는 인센티브 문제를 만든다. 직원이 자신의 경험을 세세하게 남길수록 회사의 조직 메모리는 좋아진다. 동시에 직원 입장에서는 자신이 만든 절차와 판단법이 퇴사 후에도 그대로 재사용될 수 있다. 회사가 이를 단순히 “업무를 문서화한 것”으로만 취급하면 지식 공유에 대한 거부감이 커질 수 있다.
그래서 좋은 제도는 소유권 선언 한 줄보다 기여와 사용범위를 명확하게 만드는 쪽에 가깝다. 무엇이 회사 업무산출물인지, 개인 자료를 가져올 때 어떤 동의를 받는지, 어떤 메모리를 얼마나 오래 보관하는지, 퇴사 후 이름·말투·개인적 페르소나까지 계속 사용할지 등을 미리 정해야 한다. 핵심 인력의 전문성을 회사의 장기 자산으로 전환하려면 기술뿐 아니라 신뢰 가능한 규칙이 필요하다.
앞으로의 오프보딩 질문은 ‘무엇을 기억하고 있는가’다
직원 기반 에이전트가 아직 모든 기업의 표준은 아니다. 지금도 많은 시스템은 대화기록을 길게 보존하지 않거나, 사람마다 독립된 메모리를 만들지 않는다. 이런 환경에서는 기존 계정 회수와 문서 인수인계만으로 충분할 수 있다.
하지만 장기 메모리가 제품의 기본 기능이 되고, 스킬과 선호·예외처리가 지속적으로 축적되면 상황은 달라진다. 직원이 떠나도 그 사람이 남긴 판단 흔적은 검색 가능한 상태로 남고, 다른 에이전트와 직원이 이를 계속 사용할 수 있다.
그때 중요한 질문은 “AI가 직원을 대체하는가”보다 조금 더 구체적이다. 회사는 직원의 어떤 지식을 조직 메모리로 전환할 수 있고, 그 변환과정을 얼마나 투명하게 설명할 수 있는가.
이 문제를 제대로 다루려면 에이전트 메모리를 단순한 대화 로그나 편의 기능으로 보면 안 된다. 출처가 있고, 보존기간이 있고, 접근권한이 있고, 때로는 삭제하거나 재분류해야 하는 운영자산으로 봐야 한다.
앞으로 퇴사 체크리스트에는 계정 회수 다음에 새로운 질문이 하나 더 들어갈 가능성이 높다.
이 직원에게서 만들어진 에이전트는 지금 무엇을 기억하고 있으며, 우리는 그것을 계속 기억할 근거가 있는가.
[^1]: 티타임즈, 그 직원 학습한 에이전트만 남기고 직원 해고한다면, 그 에이전트는 누구의 것인가? (김서준 해시드 대표), YouTube, 2026-09-19. https://www.youtube.com/watch?v=ejtSOizIcjQ [^2]: AI Engineers, Total Recall: Agent Memory and Harness Engineering — Ignacio Martinez, Oracle, YouTube, 2026-09-18. https://www.youtube.com/watch?v=xs-ob87TTzg [^3]: Oracle, About Agent Memory, Oracle AI Agent Memory 26.6. https://docs.oracle.com/en/database/oracle/agent-memory/26.6/guide/about.html [^4]: U.S. Copyright Office, What Writers Should Know about Copyright — A Note on Works Made for Hire. https://www.copyright.gov/engage/writers/ [^5]: U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability, January 29, 2025. https://www.copyright.gov/newsnet/2025/1060.html [^6]: U.S. Code, 18 U.S.C. §1839, Definitions — Trade Secrets. https://uscode.house.gov/view.xhtml?edition=2023&num=0&req=granuleid%3AUSC-2023-title18-section1839 [^7]: European Union, General Data Protection Regulation, Article 5 — Principles relating to processing of personal data. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679