AI 에게도 작업 기억이 필요하다

지난 글에서 AI 시스템은 단순한 자동화 도구가 아니라, 사람과 AI의 인지 부하를 조절하는 장치에 가깝다고 썼다.

그때 인지 부하를 크게 기억 부하, 사고 부하, 공정 부하로 나누어 보았다. 이번에는 그중 첫 번째인 기억 부하에 대해 조금 더 구체적으로 적어보려 한다.

요즘 나는 Dev Memory라는 실험을 하고 있다.

AI와 함께 개발하면서 생기는 작업 기록, 세션 데이터, 코드와 지식 노드의 변화를 모으고, 다시 AI가 읽을 수 있는 형태로 정리하는 구조다.

처음부터 이것을 명확한 제품이나 시스템으로 생각한 것은 아니었다. 처음에는 옵시디언을 사용해보면서 시작되었다.

쓰레드나 인스타그램 등에서 옵시디언에 대한 이야기를 자주 보았다. 3월쯤부터 흥미는 있었지만, 한동안은 “이걸 내가 왜 써야 하지?”라는 생각이 더 컸다.

그러다가 지난 5월쯤, 그래도 직접 경험해보는 것이 좋을 것 같아 옵시디언을 설치했다.

처음에는 ChatGPT와 나눈 대화 기록을 넣어봤다. 하지만 그때는 기대만큼 특별한 용도를 찾기 어려웠다.

기록은 있었지만, 그 기록이 다음 행동으로 이어지는 느낌은 약했다. 그냥 대화 기록을 모아둔 저장소에 가까웠다.

그러다가 AI 친화적인 도구들을 만들고 사용하면서 옵시디언의 용도가 조금씩 보이기 시작했다.

내가 세션마다 꼼꼼하게 기록을 남긴다기보다는, AI 개발 도구와 내가 만든 시스템들이 만들어내는 작업 기록, 세션 데이터, 코드와 지식 노드의 변화가 옵시디언 안에 쌓이기 시작했다.

그리고 그 기록들을 Dev Memory라는 형태로 정리하기 시작했다.

Dev Memory는 단순한 개발 로그가 아니다. AI와 함께 개발하면서 생기는 작업 흔적을 다시 AI가 읽을 수 있는 형태로 남기는 작업 기억층에 가깝다.

AI에게 “오늘 Dev Memory 브리핑해줘”라고 요청하면, 최근 개발 활동과 시스템 상태를 요약해서 보여준다.

예를 들면 이런 식이다.

오늘 현재까지 집계된 개발 활동 및 시스템 메모리 상태는 다음과 같습니다.지속적 모니터링: 5분 간격으로 전체 소스 코드 및 지식 노드를 스캔 중입니다.최신 동기화: 새로운 세션 데이터가 동기화 및 정규화되었습니다.상태: 모든 수집기가 정상 작동 중이며, 누락된 세션이나 오류 없이 안정적으로 기록되고 있습니다.어제는 오픈 소스 리포 및 시나리오에 대한 리뷰가 진행되었고, 주요 시나리오들이 검토 상태로 승급되었으며, 결과가 대시보드에 반영되었습니다.

생각보다 좋은 경험이었다.

예전에는 “어제 어디까지 했더라?”를 떠올리는 데 에너지를 썼다면, 이제는 기록된 흐름을 보고 “그럼 다음에 무엇을 할까?”로 넘어갈 수 있다.

단순히 기록을 보관하는 것과는 조금 다르다. 기록이 다시 판단의 재료로 돌아온다.

처음에는 이것을 사람을 위한 회고 도구처럼 생각했다. 어제 무엇을 했는지, 어떤 작업이 진행되었는지, 어떤 프로젝트가 어디까지 갔는지 다시 확인하기 위한 장치라고 보았다.

하지만 써보면서 조금 다르게 보이기 시작했다.

Dev Memory는 사람을 위한 회고 도구이기도 하지만, 더 크게 보면 AI 를 위한 작업 기억 저장소가 될 수 있다.

앞으로 AI 가 더 많은 일을 하게 된다면, 단순히 명령을 잘 내리는 것만으로는 부족할 것이다.

AI가 이전 작업의 맥락을 읽고, 어떤 판단이 있었는지 확인하고, 어떤 작업이 완료되었고 어떤 작업이 중단되었는지 이해할 수 있어야 한다.

사람에게도 인수인계 문서가 필요하듯이, AI 에게도 이어받을 수 있는 작업 기억이 필요하다.

지금의 AI 개발 도구들은 각각의 세션 안에서는 꽤 잘 작동한다. 하지만 세션이 끝나면 맥락은 쉽게 끊어진다.

어떤 도구에서 어떤 작업이 진행되었는지, 어떤 결과물이 만들어졌는지, 어떤 판단이 있었는지, 어떤 문서가 갱신되어야 하는지 흩어지기 쉽다.

사람이 계속 그것을 기억하고 다시 설명해야 한다면, 결국 기억 부하는 사람에게 남는다.

Dev Memory는 이 부하를 줄이는 실험이다.

작업 흔적을 남기고, 그 흔적을 정규화하고, 다시 AI가 읽을 수 있게 만드는 것. 그러면 다음 AI 오퍼레이터는 빈 상태에서 시작하지 않아도 된다.

이 구조는 작업을 작게 나눌수록 더 중요해질 것 같다.

AI에게 큰 작업을 한 번에 맡기면 결과는 빠르게 나오지만, 방향이 흐려지거나 평균적인 결과로 수렴하기 쉽다. 그래서 나는 점점 작업을 더 작게 나누는 쪽으로 가고 있다.

작업을 작게 나누면 AI가 실행하기는 쉬워진다. 하지만 동시에 맥락은 더 잘게 흩어진다.

작은 작업들이 많아질수록 전체 흐름을 다시 구성하는 비용이 커진다. 무엇이 끝났고, 무엇이 보류되었고, 어떤 결정이 있었고, 어떤 결과가 다음 작업으로 이어져야 하는지 계속 추적해야 한다.

그래서 작은 작업 단위와 작업 기억은 함께 가야 한다.

작업을 작게 나누는 것은 AI의 실행 부하를 낮추는 일이다. 작업 기억을 남기는 것은 사람과 AI의 기억 부하를 낮추는 일이다.

이 둘이 같이 있어야 AI 가 더 많은 일을 이어서 할 수 있다.

지금은 아직 초기적인 실험이다.

오늘의 세션을 모으고, 어제의 작업을 브리핑받고, 프로젝트별 흐름을 다시 확인하는 정도다. 하지만 이 구조가 더 다듬어지면 단순한 기록 이상의 경험도 가능할 것 같다.

프로젝트별 월간 결산, 작업량 추이, 문서 갱신 후보, 중단된 아이디어 복원, 다음 작업 추천 같은 것들이 자연스럽게 이어질 수 있다.

예를 들어 AI 가 하루 동안 여러 작은 작업을 수행했다면, Dev Memory는 그 작업들을 모아 다음과 같은 질문에 답할 수 있어야 한다.

어떤 프로젝트가 가장 많이 진행되었는가. 어떤 파일과 문서가 바뀌었는가. 어떤 결정이 반복적으로 나타났는가. 어떤 작업은 중단되었고, 왜 중단되었는가. 어떤 문서를 갱신해야 하는가. 다음 AI 가 이어받아야 할 작업은 무엇인가.

이런 질문에 답할 수 있다면, Dev Memory는 단순한 로그 저장소가 아니라 AI 의 작업 환경이 된다.

AI 시대의 개발 환경은 코드 생성 도구만으로는 부족할지도 모르겠다.

코드를 잘 생성하는 도구는 중요하다. 하지만 AI가 실제로 일을 이어가려면, 코드만이 아니라 이전 작업의 맥락을 읽을 수 있어야 한다.

코드, 문서, 세션, 판단, 변경 이력, 프로젝트 상태가 연결되어 있어야 한다.

사람이 기억해야 할 것을 시스템이 기억하고, AI가 다시 읽어야 할 것을 기록으로 남기고, 다음 작업자가 그 위에서 이어갈 수 있어야 한다.

그런 의미에서 Dev Memory는 기억 부하를 낮추는 장치다.

사람을 위한 기억이기도 하고, AI 오퍼레이터를 위한 기억이기도 하다.

앞으로 AI가 더 많은 작업을 하게 될수록, 이런 작업 기억을 남기고 다시 읽는 구조는 더 중요해질 것 같다.

좋은 AI 시스템은 똑똑한 답을 한 번에 내는 시스템이 아니라, 좋은 작업이 이어질 수 있는 상태를 만드는 시스템일 수 있다.

Dev Memory는 그 방향을 실험하는 작은 시작이다.