메모리도 하네스도 없다면: 데이터베이스가 최후의 방어선인 이유 — Kay Malcolm, Oracle

URL: https://www.youtube.com/watch?v=jA_x7F8caHI 날짜: 2026-09-15 채널: aiDotEngineer 원문 제목: No Memory, No Harness: Why the Database Is the Last Line of Defense — Kay Malcolm, Oracle

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==확률적이고 망각하는 모델을 실제 기업에서 작동시키려면, 모델 주변의 하네스(Agent Harness)와 그 중심의 공유 메모리를 어디에 안정적으로 저장해야 하는가?==

• AI는 개인의 코드 작성 속도를 높여도 팀 전체 생산성을 높이지 못할 수 있다.
• Git은 코드는 기록하지만 인간의 의도와 에이전트의 컨텍스트는 기록하지 않는다.
• 단기·장기·에피소드·절차·의미 메모리를 서로 고립된 저장소에 나누면 에이전트가 진실의 원천을 찾느라 토큰을 소모한다.
• JSON, 관계형(Relational), 그래프(Graph), 벡터(Vector), 공간(Spatial) 데이터를 한 데이터베이스 안에서 다루는 구조가 하네스의 중앙신경계가 된다.

1. AI가 개인을 빠르게 만들고 팀을 느리게 만든 이유

AI 도입의 병목은 코드 생성에서 컨텍스트 공유와 인간 의도 보존으로 이동했다.

1.1. Kay Malcolm과 Oracle 팀

1. 발표의 출발점

   1. Kay Malcolm은 자신을 은퇴한 힙합 강사라고 소개하며 청중에게 더 큰 에너지를 요구했고, Oracle에서 20년 동안 일해 왔다고 말했다.
   2. Oracle 입사 시점을 12살이라고 농담하며 나이를 계산하지 말라고 했다.
   3. Oracle에서 아웃바운드 데이터베이스 제품 관리(Outbound Database Product Management) 팀을 이끌고 있다.

2. 팀의 구성

   1. 플랫폼 개발 그룹은 실행 플랫폼을 만든다.
   2. 콘텐츠 개발 그룹은 라이브 랩(Live Labs)용 콘텐츠와 Kay가 직접 작성한 플랫폼을 만든다.
   3. QA 그룹은 품질 검증을 담당한다.
   4. 프런트엔드 개발 그룹은 AI를 활용해 사용자 인터페이스를 만든다.

1.2. 2025년 토큰 극대화의 역설

1. 개인 속도와 팀 생산성의 분리

   1. 2025년의 ‘토큰 극대화(token maxing)’ 분위기에서 AI는 팀원 개개인을 더 빠르게 만들었다.
   2. 개인이 빨라졌는데도 팀 전체 생산성은 올라가지 않았고, 2026년에는 책임 있는 AI(responsible AI)가 새로운 화두가 됐다.

2. 네덜란드 팀과 미국 팀 사이의 단절

   1. 팀의 절반은 AMIA 지역에, 나머지 절반은 미국에 있어 시차를 두고 협업했다.
   2. 네덜란드 팀이 오전 4시에 코드를 커밋했지만 Codex에서 사용한 작업 컨텍스트는 함께 커밋하지 않았다.
   3. 미국 팀이 일어났을 때 받은 것은 코드뿐이었고, 그 코드가 왜 그렇게 만들어졌는지에 대한 정보는 없었다.

3. AI가 만든 문제를 AI로 해결하는 순환

   1. GitHub는 코드 변경은 추적했지만 에이전트가 어떤 컨텍스트와 의도로 작업했는지는 기록하지 않았다.
   2. 저장소가 서로 다른 방향으로 갈라졌고, 관리자는 팀이 왜 더 빨라지지 않는지 물어야 했다.
   3. 토큰과 AI에 돈을 쓰면서도 테스트와 검증에 계속 시간이 들었고, 투자 대비 순생산성은 제대로 작동하지 않았다.
   4. 코드 생성은 더 이상 병목이 아니었지만 협업과 조정이 새로운 병목이 됐다.

4. 협업 계층이 필요한 이유

   1. “Git은 코드가 아니라 인간의 의도를 기록해야 한다”는 문제가 핵심으로 드러났다.
   2. AI라는 새로운 팀원이 들어오면서 진행 상황과 다음 단계, 에이전트의 의사결정 근거, 충돌하는 질문을 해결한 과정까지 추적해야 했다.
   3. 코드를 공유하는 것만으로는 부족하며, 사람이 가진 작업 맥락과 에이전트가 만든 맥락을 함께 공유해야 한다.

2. 엔터프라이즈 에이전트의 실제 구성

에이전트는 모델과 워크플로만으로 완성되지 않으며, 도구·컨텍스트·메모리·보안 가드레일이 함께 있어야 한다.

2.1. 모델과 하네스의 구분

1. 모델과 워크플로만으로는 부족하다

   1. 에이전트를 모델과 워크플로의 결합으로 보는 관점은 엔터프라이즈 요구사항을 지나치게 단순화한다.
   2. 도구(Tools)는 에이전트가 실제 행동을 수행하는 수단이다.
   3. 컨텍스트(Context)는 실제 프롬프트에 들어가는 정보이며, 한 번의 추론이 무엇을 근거로 하는지 결정한다.

2. 메모리와 검색

   1. 메모리는 과거 정보를 저장하는 기능만이 아니라 필요한 정보만 다시 꺼내는 검색(Retrieval) 기능을 포함한다.
   2. 모든 기록을 되돌려 주면 컨텍스트가 불필요하게 커지므로, 에이전트가 현재 작업에 맞는 정보만 찾아야 한다.

3. 보안과 가드레일

   1. 엔터프라이즈 에이전트는 보안(Security)과 가드레일(Guardrails)을 갖춰야 한다.
   2. 개발자가 보안을 신경 쓰지 않는다는 농담과 달리, 기업 데이터와 권한을 다루는 에이전트에서 보안은 선택 사항이 아니다.

2.2. 하네스와 메모리를 신체에 비유하기

1. 모델은 유리병 속 뇌다

   1. 모델은 유리병에 떠 있는 작은 뇌와 같고, 하네스는 그 뇌가 바깥 세계에서 행동할 수 있게 만드는 몸이다.
   2. 도구·실행 루프·보안·권한은 몸이 움직이고 일을 끝내는 방식을 구성한다.

2. 메모리는 중앙신경계다

   1. 중앙신경계는 뇌와 팔·다리를 연결하며, 메모리는 모델의 판단과 하네스의 행동 사이에 컨텍스트를 전달한다.
   2. 컨텍스트가 전달되지 않으면 모델이 아무리 똑똑해도 하네스가 무엇을 해야 하는지 일관되게 판단할 수 없다.

3. 에이전트 메모리의 다섯 종류

기업 에이전트는 하나의 메모리가 아니라 서로 다른 시간 범위와 의미를 가진 다섯 종류의 메모리를 필요로 한다.

3.1. 시간과 경험에 따른 메모리

1. 단기 메모리(Short-term Memory)

   1. 한 세션 안에서 유지되는 작업 메모리다.
   2. Chat, Claude Code, Codex 같은 도구에서 진행 중인 대화와 현재 작업의 상태가 여기에 해당한다.

2. 장기 메모리(Long-term Memory)

   1. 세션이 끝나도 다음 세션으로 지속되는 정보다.
   2. 프로젝트 규칙과 조직의 사실처럼 반복적으로 참조되는 지식이 장기 메모리로 남는다.

3. 에피소드 메모리(Episodic Memory)

   1. “지난번에 특정 대상과 상호작용했을 때 무슨 일이 있었는가”를 기록한다.
   2. 과거 실행의 결과와 실패·성공의 상황을 다시 이용하게 해 준다.

4. 절차 메모리(Procedural Memory)

   1. 어떤 도구를 어떤 순서로 사용했고 어떤 단계를 밟았는지를 보존한다.
   2. 반복 작업을 매번 처음부터 추론하지 않고 검증된 절차로 이어 가게 한다.

5. 의미 메모리(Semantic Memory)

   1. 개별 사건이 아니라 사실과 개념의 의미를 저장한다.
   2. 기업 에이전트가 조직의 데이터와 용어를 이해하는 바탕이 된다.

4. 여러 데이터베이스로 쪼개진 기억의 비용

고립된 저장소가 늘어날수록 에이전트가 진실의 원천을 찾는 일이 어려워지고 토큰 비용과 오류 가능성이 커진다.

4.1. Southern Company에서 겪은 데이터베이스 분열

1. SQL 튜너로 시작한 경력

   1. Kay는 애틀랜타의 전력회사 Southern Company에서 일했고, SQL 쿼리를 한계까지 튜닝하는 성능 전문가였다.
   2. 지원팀이 기록하지 말라고 한 init.ora 파라미터까지 작은 수첩에 적어 두고 활용했다.
   3. 당시 데이터 세계는 행과 열이 중심이었고, Kay는 이를 옛날 시트콤의 Al Bundy 시대라고 농담했다.

2. 비정형 데이터 요청을 미룬 대가

   1. 개발자가 비정형 데이터를 저장할 방법을 물었을 때 Kay는 알아보고 돌아오겠다고 했지만 실제로 돌아가지 않았다.
   2. Southern Company에서는 DBA가 관리하는 데이터베이스 시스템마다 매주 보안 회의와 패치 회의에 참석해야 했다.
   3. 개발자가 비정형 전용 데이터베이스를 설치하자 회의 수가 두 개에서 네 개로 늘었다.

3. 생명과 안전이 걸린 전력 복구 시스템

   1. 폭풍으로 전력이 끊겼을 때 송전탑과 나무에 올라가 전력을 복구하는 작업자에게 상태를 알려 주는 Nokia 휴대전화 같은 시스템이 있었다.
   2. 시스템이 거짓 양성(False Positive)이나 거짓 음성(False Negative)을 내면 작업자가 위험에 노출되거나 복구가 늦어질 수 있었다.
   3. 주변 지역의 다른 전력 폴(pole) 상태를 함께 조회해 오탐을 줄이는 관계를 만들어 달라는 요청이 들어왔다.

4. 그래프의 전신이 된 SQL 쿼리

   1. Kay는 다섯 겹으로 중첩된 UNION ALL SQL 쿼리를 작성해 주변 상태를 연결했다.
   2. 쿼리 실행에는 약 20분이 걸렸지만, 관계를 계산한다는 점에서 그래프 데이터베이스의 전신 같은 작업이었다.
   3. 이후 조직이 Neo4j를 설치하면서 데이터베이스가 하나 더 늘었고, Kay가 참석할 회의는 여섯 개가 됐다.
   4. 결국 Kay는 이 문제가 반복될 것이라고 판단해 Southern Company를 떠나 Oracle로 이동했다.

4.2. 에이전트가 진실의 원천을 찾아야 하는 문제

1. 서로 다른 네 저장소

   1. Oracle 관계형 데이터베이스에 데이터가 있고, 비정형 JSON 데이터베이스에도 같은 데이터가 있으며, 그래프와 벡터 데이터베이스에도 관련 정보가 나뉘어 있을 수 있다.
   2. 에이전트가 어떤 저장소가 최신이고 권위 있는지 스스로 판단해야 하면 때때로 맞히지만 대체로 틀린다.
   3. 잘못된 검색과 재질문은 막대한 토큰을 태우고, 답변의 신뢰도도 떨어뜨린다.

2. 파일 기반 메모리의 한계

   1. 메모리를 파일 시스템에 저장하거나 Claude·ChatGPT의 memory.md 같은 파일에 저장할 수 있다.
   2. 단일 에이전트가 혼자 일할 때는 작동할 수 있지만, 여러 에이전트와 팀으로 확장하면 최신성·권한·동시성 문제를 해결하기 어렵다.

5. 데이터베이스 네 명의 자원봉사자와 단일 진실의 원천

관계형·비정형·그래프·벡터 저장소를 따로 두면 간단한 사실 하나도 어느 곳에 보관할지 합의하기 어렵다.

5.1. 청중 참여 실험

1. 네 데이터베이스 역할 배정

   1. 첫 번째 자원봉사자는 전통적인 관계형 데이터베이스가 됐다.
   2. 두 번째 자원봉사자는 비정형 데이터베이스가 됐다.
   3. 세 번째 자원봉사자는 관계를 저장하는 그래프 데이터베이스가 됐다.
   4. 네 번째 자원봉사자는 벡터 데이터베이스가 됐다.

2. “소가 달을 뛰어넘었다” 실험

   1. 네 사람에게 “The cow jumped over the moon”이라는 문장을 속삭여 어떻게 저장할지와 단일 진실의 원천을 정하라고 했다.
   2. 자리에서 일어날 수 없고 서로 속삭여야 하며, 크게 말하면 토큰 비용이 다섯 배가 된다는 규칙을 붙였다.
   3. 네 저장소가 서로 대화할 수 없는 상태에서는 단순한 문장조차 일관되게 저장되지 않는다는 결론이 나왔다.

5.2. Oracle AI Database의 통합 주장

1. 데이터 타입의 동시 저장

   1. Oracle AI Database 26ai는 같은 테이블과 같은 파티션 안에서 JSON, 그래프, 벡터, 공간(Spatial) 데이터를 네이티브로 저장할 수 있다.
   2. 메모리를 불변(Immutable)하게 보존해야 하는 경우 블록체인 데이터도 같은 데이터베이스 안에서 다룰 수 있다.
   3. AWS, GCP, Azure, OCI, 온프레미스 어디서든 어떤 워크로드든 선택성과 유연성을 유지한다.

2. 메모리 종류와 저장 형태의 연결

   1. 장기 메모리와 절차 메모리는 관계형 또는 JSON 구조에 보관할 수 있다.
   2. 그래프는 단계와 관계를 표현해 절차적 맥락과 연결 구조를 드러낸다.
   3. 에피소드와 의미 메모리는 벡터 검색과 텍스트 형태를 함께 사용해 과거 사건과 의미를 찾는다.
   4. 네 데이터베이스가 분리되어 있으면 서로의 결과를 조정해야 하지만, 통합 데이터베이스는 에이전트 메모리의 단일 진실의 원천을 제공한다.

3. 하네스의 중앙신경계

   1. 통합 데이터베이스는 에이전트 하네스에 필요한 메모리를 저장하는 장소가 된다.
   2. 하네스가 몸이라면 메모리는 중앙신경계이므로, 하네스가 실제 행동을 하려면 데이터베이스에 남은 기억과 컨텍스트를 신뢰할 수 있어야 한다.

6. 메모리 브로커와 팀 단위 연속성

코드뿐 아니라 컨텍스트를 공유하는 메모리 브로커가 여러 작업 분기와 개발자를 하나의 연속된 작업으로 연결한다.

6.1. Py 메모리 브로커의 작동

1. 자동 연속성(Automatic Continuity)

   1. Kay의 팀은 메모리 브로커 Py를 사용해 AI가 만든 문제를 해결했다.
   2. Py는 코드와 함께 작업 컨텍스트를 추적해 한 작업 창에서 다른 작업 창으로 필요한 기억을 전달했다.

2. 사람 에이전트와 작업 분기

   1. 한 컨텍스트 창에 절차·에피소드·장기 메모리가 있었다면, 그 정보가 다른 팀원과 다른 코드 포크로 공유됐다.
   2. 사람 개발자들은 여전히 통제권을 유지하면서도, 각자 다른 브랜치에서 일관된 배경 정보를 이용했다.

3. 컨텍스트와 코드의 연결

   1. Py는 컨텍스트가 어느 포크와 브랜치에 속하는지 찾아냈다.
   2. 해당 작업이 어느 커밋에 연결되는지도 기록해, 코드 변경과 인간의 의도를 함께 추적하게 했다.

7. 엔터프라이즈용 Oracle Agent Memory

파일 기반 메모리는 한 사람의 에이전트에는 유용하지만, 여러 에이전트와 팀으로 확장하려면 데이터베이스 기반 메모리 SDK가 필요하다.

7.1. 세 가지 자료가 뒷받침한 메모리의 필수성

1. OpenAI 인하우스 데이터 에이전트

   1. OpenAI의 인하우스 데이터 에이전트는 올바른 필터링을 수행하려면 메모리가 중요하다고 말한다.
   2. 충분한 메모리가 없으면 과거 맥락에 맞춘 필터링 대신 단순 문자열 매칭에 의존하게 된다.

2. Harrison Chase의 하네스 원칙

   1. Harrison Chase는 “당신의 하네스가 당신의 메모리이며, 하네스를 소유하지 않으면 메모리도 소유하지 못한다”고 말했다.
   2. 모델 공급자가 하네스와 메모리 저장 방식을 통제하면 기업은 에이전트가 무엇을 기억하고 왜 그렇게 행동했는지 완전히 통제하기 어렵다.

3. Claude 메모리의 확장 문제

   1. Claude에도 메모리가 있지만 파일 시스템에 가까운 방식으로 작동하며, 단일 사용자·단일 에이전트에서는 쓸 만하다.
   2. 기업에서 에이전트 수가 하나를 넘어가면 파일 공유, 동시 업데이트, 권한 분리, 단일 진실의 원천 문제가 나타난다.

7.2. SDK와 저장 계층

1. 설치와 기능

   1. Oracle Agent Memory 패키지는 pip install oracle-agent-memory로 설치할 수 있다.
   2. SDK는 실시간 대화, 메모리, 사실(facts)을 보관하고 무엇을 오래 남길 가치가 있는지 판단한다.

2. 팀 상호작용

   1. Kevin은 Py 메모리 브로커와 컨텍스트를 공유한다.
   2. Oracle Agent Memory SDK는 Oracle Autonomous Database에 저장된다.
   3. LLM은 원하는 모델을 선택할 수 있고, Oracle Private AI Services 컨테이너를 통해 로컬 모델을 사용할 수도 있다.
   4. Linda는 현장에서 Kevin과 상호작용하며, 공유된 기억 덕분에 두 작업이 단절되지 않는다.

3. 개인 속도에서 팀 속도로

   1. AI는 개인을 빠르게 만든다.
   2. Oracle AI Database의 공유 메모리는 팀을 빠르게 만든다.
   3. 에이전트 메모리는 파일 시스템, 데이터베이스 파일 시스템, 데이터베이스 중 요구사항에 맞는 저장 형태를 선택할 수 있다.
   4. 데이터 모델링이 필요하면 JSON과 관계형 구조를 함께 선택할 수 있다.

8. Oracle 생태계에서 직접 실험하는 방법

통합 데이터베이스와 에이전트 메모리는 이론이 아니라 개발자가 직접 실행해 볼 수 있는 학습·실험 자원으로 연결된다.

8.1. 개발 자료와 LiveLabs

1. Oracle AI Developer Hub

   1. Oracle AI Developer Hub에서 코딩 자료와 애플리케이션 예제를 얻을 수 있다.
   2. 데이터베이스에 에이전트 메모리를 저장하는 방식과 발표에서 다룬 애플리케이션을 실습할 수 있다.

2. LiveLabs

   1. livelabs.oracle.com에서 다양한 Oracle 기술을 직접 시험할 수 있다.
   2. Kay는 약 6년 전에 직접 작성한 LiveLabs 플랫폼이 약 4천만 명의 사용자에게 사용됐다고 말했다.
   3. Oracle Cloud Infrastructure(OCI) 테넌시 비용을 활용해 6시간, 12시간 또는 필요한 만큼 실습 환경을 켜 볼 수 있다.

8.2. Always Free OCI

1. 무료 자원

   1. Always Free OCI에서는 무료 Oracle 데이터베이스와 컴퓨트를 사용할 수 있다.
   2. 한 달에 3,000개의 이메일을 보낼 수 있다.
   3. 200GB의 저장 공간을 제공한다.

2. 실행 권유

   1. Oracle Cloud Always Free를 검색하면 접근 방법을 찾을 수 있다.
   2. 직접 무언가를 만든 뒤 Kay에게 메시지를 보내 결과를 공유하라는 요청으로 발표가 마무리됐다.

주요 발언 모음

“Git은 코드를 기록하지만 인간의 의도는 기록하지 않는다.”

“하네스는 몸이고, 메모리는 중앙신경계다.”

“하네스를 소유하지 않으면 메모리도 소유하지 못한다.” — Harrison Chase 인용

“AI는 개인을 빠르게 만든다. Oracle AI Database의 공유 메모리는 팀을 빠르게 만든다.”

“Oracle은 여러분이 생각하는 그 Oracle이 아니다.”

“The cow jumped over the moon.”

핵심 데이터 & 수치

• 20년: Kay Malcolm이 Oracle에서 일해 온 기간이다.
• 오전 4시: 네덜란드 팀이 미국 팀이 잠든 사이 코드를 커밋한 시각이다.
• 2개에서 4개: 비정형 전용 데이터베이스가 추가되며 매주 참석해야 했던 보안·패치 회의가 늘어난 수다.
• 5중 중첩 UNION ALL: 주변 전력 폴의 관계를 계산하기 위해 작성한 SQL의 구조다.
• 약 20분: 해당 SQL 쿼리가 실행되는 데 걸린 시간이다.
• 6개: Neo4j를 추가한 뒤 Kay가 참석해야 했던 주간 회의 수다.
• 5가지: 단기·장기·에피소드·절차·의미 메모리로 구분한 메모리 유형의 수다.
• 5배: 자원봉사자들이 실험에서 크게 말할 때 발생한다고 설정한 토큰 비용 배수다.
• 3,000개: Always Free OCI에서 한 달에 보낼 수 있다고 제시한 이메일 수다.
• 200GB: Always Free OCI에서 제공한다고 제시한 저장 공간이다.
• 약 6년·4천만 명: Kay가 직접 작성한 LiveLabs 플랫폼의 운영 기간과 사용자 규모다.

결론 및 시사점

1. 에이전트의 품질은 모델의 추론 능력만으로 결정되지 않으며, 도구·컨텍스트·메모리·가드레일을 포함한 하네스 설계에 달려 있다.
2. AI가 코드 작성 속도를 높여도 인간의 의도와 작업 컨텍스트가 공유되지 않으면 팀의 순생산성은 올라가지 않는다.
3. Git 커밋과 프롬프트 기록을 분리하지 말고 코드·브랜치·커밋·절차·결정을 함께 연결해야 한다.
4. 다섯 종류의 메모리를 여러 사일로에 흩어 놓으면 에이전트가 단일 진실의 원천을 찾느라 오류와 토큰 비용을 키운다.
5. JSON·관계형·그래프·벡터·공간 데이터를 통합 저장하는 데이터베이스는 하네스가 의존하는 내구성 있는 메모리 계층이 된다.
6. 파일 기반 메모리는 단일 에이전트의 시작점으로 쓸 수 있지만, 기업 규모의 다중 에이전트 협업에는 권한·동시성·검색·감사 기능이 필요하다.
7. 메모리 브로커는 서로 다른 포크와 브랜치의 개발자가 코드뿐 아니라 절차적·에피소드적 컨텍스트까지 공유하게 만든다.
8. 엔터프라이즈 메모리 SDK는 대화·사실·기억 중 무엇을 보존할지 판단하고, 데이터베이스를 통해 여러 에이전트가 같은 기록을 읽게 해야 한다.
9. 모델과 공급자를 바꾸더라도 기업이 소유한 데이터베이스와 하네스가 기억의 기준점으로 남아야 한다.
10. 실험 가능한 무료 클라우드와 LiveLabs는 에이전트 메모리와 통합 데이터 모델을 실제 워크로드에서 검증하는 출발점이 된다.

메타데이터

• type: youtube-digest
• source: aiDotEngineer
• video_id: jA_x7F8caHI
• video_url: https://www.youtube.com/watch?v=jA_x7F8caHI
• title_original: No Memory, No Harness: Why the Database Is the Last Line of Defense — Kay Malcolm, Oracle
• processed_date: 2026-09-15
• language: 한국어 번역·심층 정리
• category: ai-llm