Trae가 세션 간에 컨텍스트를 잊어버리는 이유
현재 Trae의 컨텍스트 처리 방식
세션 내부에서 Trae는 훌륭하게 작동합니다. 파일을 읽고, 지시를 따르며, 프로젝트에 대한 실질적인 그림을 그려냅니다. 하지만 그 그림은 컨텍스트 창 내에 존재하는 세션 상태일 뿐입니다. 데이터를 기록하는 저장소가 없기 때문에 세션이 종료되면 그 이해도 함께 사라지며, 다음 세션은 오직 코드 자체에서 유추할 수 있는 정보만으로 다시 시작해야 합니다.
컨텍스트가 유지되지 않는 기술적 이유
두 가지 요인이 겹칩니다. 첫째, 세션 간 메모리 기능이 없습니다. 사용자와 프로젝트에 대한 사실을 영구적으로 기억하는 어시스턴트들과 달리, Trae는 세션 간에 지속되는 기록을 남기지 않습니다. 둘째, 긴 세션 내에서도 컨텍스트가 저하됩니다. 대화가 길어지면 이전 지시사항을 놓치기 시작하므로, 개발자들은 작업 중간에 프로젝트 구조와 코딩 패턴을 다시 설명해야 하는 상황에 처하게 됩니다. 그 결과, 한 시간 동안은 매우 똑똑하다가도 다음 날 아침이 되면 백지상태가 되는 도구가 됩니다.
이로 인해 발생하는 비용
매일 IDE를 새로 온보딩해야 합니다. 동일한 규칙, 동일한 아키텍처 설명, 동일한 수정을 반복해야 합니다. 지난주에 정해둔 "여기서는 이 패턴을 사용하지 않는다"와 같은 결정사항이 사라져 다시 제안으로 올라옵니다. 또한 정보가 공유되지 않습니다. 세션의 이해도가 로컬 세션을 벗어나지 못하므로, 두 번째 컴퓨터나 팀원은 완전히 제로 베이스에서 시작해야 합니다.
Trae의 기본 임시 방편 (그리고 그 한계)
프로젝트 단위로 정리된 워크스페이스
채팅 창에 흩어놓는 대신 프로젝트를 중심으로 자료를 정리해 두면 Trae가 관련 파일을 찾는 데 큰 도움이 되며, 단순한 챗봇 흐름보다 훨씬 낫습니다. 하지만 정리가 곧 메모리는 아닙니다. 파일은 유지되지만, 파일에 대한 이해는 유지되지 않습니다.
규칙 및 커스텀 지시사항
Trae에서 프로젝트 규칙이나 상시 지시사항을 설정할 수 있다면 이를 활용하세요. 고정된 규칙을 담기에는 가장 적합한 곳입니다. 하지만 한계는 명확합니다. 수동으로 관리되는 정적 텍스트이기 때문에, 작업하면서 쌓이는 결정, 수정 사항, 새로운 발견 등을 담아내지 못합니다.
수동 세션 로그 작성
일부 개발자들은 자신만의 해결책을 만들었습니다. 세션을 닫기 전에 특정 트리거 단어를 사용하여 어시스턴트가 요약 챕터(수행된 작업, 변경된 파일, 결정 사항, 현재 상태, 남은 작업)를 작성하도록 하는 것입니다. 이는 정말 영리한 임시 방편이며 무엇이 부족한지 정확히 보여줍니다. 하지만 이 역시 완전히 수동이며, 잊어버리기 쉽고, 도구가 쿼리할 수 있는 메모리가 아니라 여러 파일에 흩어진 노트로 남게 됩니다.
공통적인 한계: 이 중 어느 것도 세션, 컴퓨터, 팀원을 넘어 유지되고 검색 가능한 영구적인 프로젝트 지식 저장소가 되지 못합니다. 이는 Cursor가 이전 세션을 잊어버리는 이유에서 다룬 것처럼 다른 IDE 에이전트들이 직면하는 것과 동일한 근본적인 공백입니다.
해결책: Trae에 영구적인 프로젝트 메모리 부여하기
지속 가능한 해결책은 세션 외부에 메모리 레이어를 두는 것입니다. 즉, 수동으로 작성하던 세션 로그를 자동화하는 것입니다. MemoryLake는 아키텍처, 규칙, 결정 사항을 한 번만 저장하면 검색이 가능하고, Git 스타일로 버전이 관리되어 규칙이 어떻게 발전했는지 추적할 수 있으며, 종단간 암호화(end-to-end encrypted)되어 코드가 안전하게 보호됩니다.
1단계: API 키 생성
MemoryLake에 로그인하고 키를 생성한 후 첫 번째 요청을 보내세요. 약 30초 정도 걸립니다.
2단계: 첫 번째 메모리 업로드
세션이 계속 잃어버리는 프로젝트 지식(아키텍처 노트, 규칙, 결정 기록, API 문서 등)을 업로드하세요. 문서, 이미지 및 기타 파일 모두 지원됩니다. 그런 다음 세션 로그 임시 방편이 지향했던 습관을 유지하세요. 세션에서 무언가 결정되면 이를 한 줄짜리 메모리로 기록해 두는 것입니다.
3단계: AI 및 에이전트 연결
API 키를 사용하여 Trae의 MCP 서버 구성에 MemoryLake를 추가하면 작업 중간에 프로젝트 메모리를 쿼리할 수 있습니다. MCP가 없는 환경이라면 세션 시작 시 API를 호출하여 관련 컨텍스트를 가져오세요. 동일한 메모리를 MCP 또는 API를 통해 Claude, Codex, OpenClaw 및 기타 에이전트에서도 사용할 수 있으므로 프로젝트 지식이 특정 IDE에 종속되지 않습니다.
프로젝트를 다시 설명할 때 실제로 발생하는 비용
매일 발생하는 재온보딩 비용
매 세션마다 구조와 규칙을 다시 설명하는 데 드는 10분은 실제 작업을 시작하기도 전에 일주일에 수 시간이 낭비됨을 의미합니다. 여기에 Trae가 어제 가졌던 그림을 다시 그리기 위해 파일을 재판독하는 데 소비하는 토큰 비용도 추가됩니다. 대규모 코드베이스에서 이러한 재구축 작업은 세션에서 가장 비용이 많이 드는 부분입니다.
다시 설명하는 대신 검색하기
영구 레이어를 사용하면 Trae는 규칙이나 결정을 다시 유추하는 대신 작업에 필요한 정보를 온디맨드로 가져옵니다. 세션은 이미 정보를 파악한 상태로 시작되고, 반복적인 수정이 사라지며, 프롬프트는 간결하게 유지됩니다. MemoryLake의 Token Saving Calculator를 통해 사용량에 따른 효과를 예측해 볼 수 있습니다.
Trae 프로젝트 메모리 구축을 위한 모범 사례
수동 세션 로그 작업 자동화
임시 방편의 직관은 옳았습니다. 컨텍스트가 사라지기 전에 일어난 일을 기록하는 것입니다. 이를 로컬 파일 대신 검색 가능한 메모리로 저장하면 어떤 컴퓨터에서든 다음 세션이 이를 실제로 활용할 수 있습니다.
규칙과 결정 사항 분리
변하지 않는 규칙은 Trae의 규칙(rules)에 보관하고, 동적인 이력(결정 사항, 기각된 접근 방식, 해결된 버그)은 메모리 레이어에 보관하세요. 이들은 변경되는 주기가 다르며 서로 다른 위치에 있어야 합니다.
리포지토리별 스코프 지정
리포지토리당 하나의 메모리 스코프를 유지하면 검색이 정확해지고, 각 프로젝트의 세션이 자신에게 해당하는 정보만 가져올 수 있습니다.
결론
Trae는 세션 내부에서는 강력하지만 세션이 바뀌면 잊어버리는, 아침마다 백지상태가 되는 유능한 IDE입니다. 솔직한 리뷰어들은 메모리 부재를 메모리 기능이 있는 도구들과 비교했을 때 가장 큰 단점으로 꼽습니다. 커뮤니티의 세션 로그 팁은 이러한 필요성을 증명합니다. 영구 메모리 레이어는 이를 자동화하고, 쿼리 가능하게 하며, 여러 컴퓨터와 도구에 걸쳐 제대로 수행해 줍니다. 프로젝트를 한 번만 학습시키고, 모든 세션이 지난 세션이 끝난 지점부터 시작되도록 하세요.