· 18 min read

새 채팅의 AI는 나를 모른다 — 그래서 채팅 밖에 문맥을 만들었다

일기·프로젝트·생각을 한곳에 모으고 Claude Code와 Codex가 그 안에서 일하게 했다. 자연스럽게 질문해도 과거 기록을 찾아 작업하고 다시 기록하는 실제 사례와, AI 시대에 개인 기록이 더 중요해진 이유를 정리했다.

나는 Codex에 종종 이런 식으로 말한다.

그 샌드테이블 샌드크래프트 관련 프로젝트 기억나? 좀 찾아보고 와봐.

프로젝트의 정확한 이름이나 위치를 말하지 않았다. Codex는 저장소를 검색해 관련 기록을 찾았고, 이전에 검토했던 장비와 구현 방향을 다시 정리했다. 대화는 테이블 크기, 프로젝터, 센서, 사용할 모래까지 자연스럽게 이어졌다.

내가 모래층 8cm가 너무 얕은 것 같다고 말하자 기존 판단도 다시 검토했다. 초기 시험 기준과 실제 전시용 기준을 구분하고 기본안을 10cm로 수정했다. 내가 한 일은 기억나는 표현으로 프로젝트를 불러내고, 결과를 보며 생각을 덧붙인 것뿐이다.

이전 기록이 있어서 모호한 질문으로 시작할 수 있었고, 대화 중 바뀐 판단도 다시 문서에 남았다.

omni-space는 일기, 커리어, 프로젝트, 생각, 각종 생활 데이터를 모아두는 내 개인 워크스페이스다. 나는 Obsidian으로 읽고 쓰고, Claude Code와 Codex처럼 문서를 찾고 도구를 써서 작업하는 AI Agent도 같은 공간에서 일하게 한다.

AI 시대에는 기록의 역할이 달라진다

기록은 원래도 중요했다. 다만 예전에는 대부분 내가 나중에 다시 읽기 위한 자료였다. 기록이 많아질수록 필요한 내용을 찾고 서로 연결하는 비용도 함께 커졌다.

AI는 이 지점을 바꾼다. 몇 년 전 일기와 지난달 프로젝트 문서를 함께 훑고, 서로 다른 시기의 선택에서 반복되는 흐름을 찾을 수 있다. 내가 모든 기록을 기억하고 있지 않아도 원본이 남아 있다면 다시 살펴볼 수 있다.

여기서 문맥은 이름이나 직업 같은 자기소개만 뜻하지 않는다. 왜 어떤 선택을 했는지, 돈과 커리어를 어떤 기준으로 바라보는지, 프로젝트나 인간관계에서 생각이 어떻게 바뀌었는지도 문맥이다. 사실뿐 아니라 가치관과 판단 기준, 망설였던 이유까지 기록할수록 AI가 참고할 수 있는 배경도 구체적이 된다.

나는 시간이 지나면 당시의 이유와 감정을 잊고 결과만 단순하게 기억하는 편이다. 기록에는 그때의 표현과 고민이 남는다. AI의 해석이 항상 맞는 것은 아니지만, 멀리 떨어진 기록을 나란히 놓고 내가 놓친 더 큰 흐름을 다시 보게 만들 수는 있다.

같은 원본은 글쓰기에도 쓰인다. 여러 날의 메모를 블로그나 책의 주제로 묶고, 긴 글을 SNS 게시물이나 영상 대본으로 바꿀 수 있다. SNS는 원본 저장소가 아니라 여러 배포처 중 하나가 된다.

작업 과정과 판단 기준까지 쌓이면 AI에 단순한 질문보다 큰 일도 맡길 수 있다. 자료 조사, 주간 회고, 문서 정리, 콘텐츠 초안, 반복적인 데이터 처리를 같은 문맥 위에서 이어갈 수 있다.

모델과 도구는 계속 좋아진다. 문맥과 작업 흐름을 특정 채팅 밖에 두면 더 나은 AI가 나올 때 같은 기반을 다시 사용할 수 있다. 도구는 교체되지만 내가 축적한 기록과 워크플로는 남는다. 내가 AI 시대에 기록을 더 중요하게 보는 이유다.

실제로는 그냥 던지듯이 쓴다

처음 쓴 초안에서는 문서 범위, 기준일, 답변 규칙을 프롬프트에 적는 방법을 길게 설명했다. 그런데 실제 세션 기록을 다시 보니 나는 거의 그렇게 쓰지 않았다. 질문뿐 아니라 받은 파일과 떠오른 생각도 다듬지 않고 먼저 넣는 편에 가깝다.

새 전시 프로젝트를 시작할 때는 Inbox에 받은 영상 원고를 넣고 이렇게 말했다.

프로젝트 하나 만들자. Inbox에 넣어둔 영상 원고 파일 봐봐.

Agent는 원고와 비슷한 과거 프로젝트를 함께 찾아 새 프로젝트의 문맥을 만들었다. 이후 나는 문서를 보면서 “이 질문은 중요하지 않으니 빼자”, “이 부분은 휴대폰 웹으로 해도 되지 않나”, “버전은 아직 올리지 마”처럼 계속 방향을 수정했다. 완성된 기획을 한 번에 전달한 것이 아니라, 보이는 결과에 반응하며 생각을 구체화했다.

내 사용 방식은 프롬프트를 정교하게 작성하는 것보다, 생각나는 말과 도착한 자료를 먼저 던지고 저장소 안의 문맥을 함께 찾게 하는 것에 가깝다.

짧게 말할 수 있는 이유는 뒷면이 길기 때문이다

사용자는 자연스럽게 말하지만 Agent가 아무렇게나 일하는 것은 아니다. 워크스페이스 안에는 내 정보와 최근 기록, 프로젝트별 현재 상태, 파일을 정리하는 방식, 반복 작업의 절차가 쌓여 있다.

자연스러운 요청 뒤에서 개인 워크스페이스의 문맥이 작동하는 흐름
자연스러운 요청 뒤에서 개인 워크스페이스의 문맥이 작동하는 흐름

새 세션이 시작되면 Agent는 공통 문맥과 최근 기록을 읽고, 요청과 관련된 프로젝트나 자료를 검색한다. 일을 마친 뒤에는 새 결정과 다음 행동을 다시 프로젝트 문서나 저널에 남긴다. 그래서 다음 세션도 그 결과에서 출발할 수 있다.

규칙은 이 과정의 앞면이 아니라 뒷면에 있다. 나는 매번 “어느 폴더를 읽고 어디에 저장하라”고 말하지 않는다. 그런 설명이 반복되면 저장소의 안내 문서나 작업별 지침 파일인 Skill로 옮긴다.

정확한 순서와 판정 기준이 필요한 컨셉 아트 작업에서는 별도의 BRIEF.md에 읽을 자료, 단계, 저장 위치, 금지 사항을 적어뒀다. 새 세션에서 한 요청은 “BRIEF를 읽고 Stage 1만 실행해줘”가 전부였다.

즉 매번 규칙적인 프롬프트를 쓰는 것이 아니라, 반복되는 설명을 한 번 기록해두고 다음부터 자연스럽게 부르는 방식이다. 시스템이 복잡해질수록 대화는 오히려 짧아진다.

처음 보는 AI도 기록만으로 따라올 수 있을까

기존 Agent가 이미 구조에 익숙해서 잘하는 것인지 확인하려고, 이전 대화가 없는 독립된 AI 세션 세 개에도 기록을 읽혀봤다.

  • 첫 번째 세션은 서로 다른 시기의 커리어와 프로젝트 기록을 묶어, 내가 전체 흐름을 먼저 만들고 수치로 확인하며 반복 작업을 자동화하는 경향을 찾았다.
  • 두 번째 세션은 일주일치 기록에서 기술적으로 작동하는 상태와 실제 전달 가능한 상태를 구분하고 다음 행동을 제안했다.
  • 세 번째 세션은 여러 날의 메모를 묶어 AI가 프로토타입을 싸게 만들자, 포기하는 능력이 가장 비싸졌다라는 글감을 만들었다.

각 사건은 내가 알고 있던 내용이었다. 하지만 서로 다른 시기의 기록을 한꺼번에 연결했을 때 보이는 패턴은 새로웠다.

동시에 한계도 분명했다. 두 번째 세션의 답은 바로 다음 날 낡았다. 읽힌 기록 이후에 프로젝트의 주된 구현 방식이 바뀌었기 때문이다. AI는 기록되지 않은 합의와 감정을 알 수 없고, 오래된 문서를 현재 상태로 오해할 수도 있다.

개인 워크스페이스가 AI를 전지전능하게 만드는 것은 아니다. 대신 AI가 무엇을 읽고 판단했는지 확인하고, 틀렸다면 원본을 고칠 수 있게 한다.

처음부터 omni-space를 만들 필요는 없다

비슷한 방식을 시작하려고 거대한 분류 체계부터 만들 필요는 없다. 이미 쓰는 메모 앱이나 문서 폴더에서 오늘의 기록과 지금 진행 중인 일 하나를 남기는 것으로 충분하다.

새로 생기는 생각과 결정의 원본을 그곳에 두고, AI에는 “이 공간에서 관련 기록을 먼저 찾아봐”라고 해보면 된다. 문서 도구 안의 AI를 사용해도 되고, 일반 채팅에 파일을 첨부해도 되고, 로컬 폴더를 읽는 Agent를 사용해도 된다.

처음부터 과거 자료를 전부 옮길 필요도 없다. 당장 필요한 자료부터 연결하고, 같은 설명을 두 번 하게 될 때 공통 문서로 만든다. 같은 일이 반복되기 시작하면 그때 작업 순서나 자동화를 기록한다. 구조는 사용하면서 생겨도 된다.

다음과 같은 질문부터 해볼 수 있다.

  • “지난번에 이 문제를 어떻게 결정했지? 관련 기록을 찾아봐.”
  • “이 메일과 기존 자료를 같이 보고 내가 해야 할 일을 정리해줘.”
  • “최근 메모 중 하나의 글로 묶을 수 있는 생각이 있는지 찾아봐.”

답이 쓸모 있었다면 새로 내린 결정이나 다음 행동을 다시 원본에 남긴다. 이것만 반복해도 기록과 AI가 이어지는 순환이 생긴다.

Notion으로 시작해도 된다

직접 시스템을 만들 필요는 없다. Notion 자체는 써봤지만 Notion AI와 Notion Agent는 실제로 사용해보지 않았다. 따라서 omni-space와 사용성을 직접 비교할 수는 없다.

다만 공식 설명을 보면 Notion Agent는 워크스페이스의 페이지와 데이터베이스를 문맥으로 사용하고, Research Mode는 연결된 정보에서 답을 찾는다. 비개발자가 이미 Notion에 기록을 쌓고 있다면 가장 먼저 검토할 만한 선택지로 보인다.

내가 로컬 파일로 직접 만든 이유는 여러 AI가 같은 원본을 읽고, Git으로 변경 이력을 남기고, 일정·데이터·개발 프로젝트까지 자동화하고 싶었기 때문이다. 이런 요구가 생기기 전에는 이미 익숙한 도구가 더 나을 수 있다.

모든 것을 한 클라우드에 넣는다는 뜻은 아니다

‘한곳에 모은다’는 말은 하나의 논리적인 원본을 정한다는 뜻이다. 재무 원본, 건강 기록, 회사 자료, 타인이 포함된 사적 대화처럼 민감한 자료는 분리할 수 있다. 외부 공개나 메시지 전송, 인프라 삭제처럼 되돌리기 어려운 행동은 별도 확인을 거치게 할 수도 있다.

이런 경계는 사용자가 매번 프롬프트에 적기보다 서비스의 권한 설정이나 Agent의 공통 지침에 두는 편이 자연스럽다. 평소의 대화는 짧게 유지하면서 뒤에서 일관되게 적용할 수 있기 때문이다.

부록: 내가 만든 omni-space의 전체 구조

omni-space는 로컬의 Markdown, JSON, JSONL 파일이 원본이다. Obsidian으로 읽고 쓰고, Git으로 텍스트 변경 이력을 남긴다. 이미지와 PDF 같은 큰 파일은 별도 저장소에 두고 링크로 연결한다.

Claude Code, Codex, Hermes와 예약 자동화가 같은 기록을 사용한다. 입구는 메모 앱, 메신저, 터미널로 다르지만 결과는 프로젝트 문서, 저널, 할 일, 콘텐츠 원본으로 다시 모인다.

자연스러운 입력부터 기록·문맥·AI 에이전트·자동화·결과까지 이어지는 omni-space 전체 구조
자연스러운 입력부터 기록·문맥·AI 에이전트·자동화·결과까지 이어지는 omni-space 전체 구조

이 구조는 처음부터 설계한 완성품이 아니다. 기록하다가 반복되는 설명을 문서로 만들고, 반복되는 작업을 Skill과 자동화로 옮기면서 지금 모습이 됐다. 자유롭게 말하는 앞면과 일관되게 기록하는 뒷면이 함께 있는 셈이다.

좋은 프롬프트보다 오래 남는 것

AI 시대에 더 중요해진 것은 매번 완벽한 프롬프트를 작성하는 능력만은 아니다. 내가 무엇을 했고 왜 그렇게 생각했는지, 그 원본을 다음 대화에서도 다시 꺼낼 수 있게 남기는 일이다.

나는 AI에게 나를 완벽히 기억시키려는 것이 아니다. 기억해야 할 내용을 채팅 밖에 두고, 필요할 때 어떤 AI든 다시 읽을 수 있게 만들고 있다.

그래서 시작은 거창하지 않아도 된다. 오늘 있었던 일이나 지금 고민하는 프로젝트를 평소 말투로 적고 이렇게 물어보면 된다.

이거와 관련해서 내가 전에 적어둔 내용이 있나? 한번 찾아봐.

그 질문에 답할 기록이 아직 없다면, 바로 그 순간부터 남기면 된다.

Related Posts

View All Posts »

완벽과 AI, 그리고 TDD

사람이든 AI든 완벽할 수 없다. AI가 코드 변경량을 늘리는 동시에 테스트 작성 비용을 낮춘 지금, TDD와 CI가 왜 더 중요하고 더 가성비 좋은 선택이 되었는지 실제 게임·프레임워크 개발 경험으로 정리했다.

#AI #TDD #CI #Testing

엔진과 게임을 함께 개발하는 구조 — 승격 프로토콜, 파사드, 짝 worktree

게임 splanet.io는 직접 만든 엔진 OFF 위에 있다. 레포는 둘인데 변경은 대개 하나다. 무엇을 엔진에 올릴지는 규칙이 아니라 감각이지만, 어떻게 올릴지는 프로토콜이 있다. 파사드로 경계를 좁히고, worktree를 짝으로 움직이고, 어느 코딩 에이전트가 와도 같은 계약에서 출발하게 만든다.

#OFF #GameDev #Architecture #Git

.NET 서버 메모리 누수 잡기 — dotnet-gcdump로 안 보이는 할당 폭탄

.NET 서버 메모리가 2분 만에 136MB에서 14GB로 폭증했다. dotnet-gcdump와 dotnet-counters로도 안 잡히는 할당 폭탄을 추적하고, 그 과정을 재사용 가능한 스킬로 만든 이야기.

#Aethelgard #AI #Claude #GameDev