AI 코딩 에이전트가 어제의 결정을 잊을 때, 프로젝트에 남겨야 할 것은 무엇일까요

핵심 요약 (TL;DR)

AI 코딩 에이전트는 한 세션 안에서는 놀랄 만큼 많은 맥락을 이해합니다. 그러나 창을 닫고 다음 날 다시 시작하면, 어제 합의한 규칙과 이미 버린 선택지를 사람이 다시 설명해야 하는 순간이 옵니다. 최근 공개된 OpenContext는 이 문제를 프로젝트 안의 .opencontext/ Markdown 파일과 MCP 서버로 다루려는 도구입니다. 공식 소개에 따르면 에이전트가 이 파일을 읽고 쓸 수 있게 하며, 규칙을 저장소에 커밋하거나 개인용으로 제외하는 선택도 제공합니다. 이 도구가 모든 에이전트의 기억 문제를 해결했다고 단정할 수는 없습니다. 다만 바이브코딩에서 ‘기억’은 모델의 기능만이 아니라, 사람이 다시 확인할 수 있는 프로젝트 기록이라는 점을 선명하게 보여 줍니다.

에이전트는 왜 같은 질문을 다시 할까요?

대화창의 맥락과 프로젝트의 공식 결정은 다릅니다. 대화 안에서는 ‘폼 검증에는 이 방식을 쓴다’고 정했더라도, 다음 세션의 에이전트는 그 결정을 알지 못하거나 중요도를 제대로 판단하지 못할 수 있습니다. 그 결과 이미 바꾼 라이브러리를 다시 제안하거나, 화면마다 다른 규칙을 적용하는 일이 생깁니다.

해결은 거대한 문서부터 만드는 것이 아닙니다. AI가 작업을 시작하기 전 읽을 짧은 기준을 저장소에 남기면 됩니다. 제품이 해결하는 문제 한 줄, 확정한 기술 선택, 금지한 행동, 확인이 필요한 질문 정도면 충분합니다. 중요한 것은 어떤 패키지를 쓰느냐보다 기록의 원본 위치를 하나로 정하는 일입니다.

어떤 내용은 남기고, 어떤 내용은 빼야 할까요?

다음 세션에도 살아남을 결정을 남기세요. 예를 들어 ‘관리자 승인 전에는 고객 정보를 외부 AI에 보내지 않는다’, ‘모바일 화면을 먼저 확인한다’, ‘로그인 오류는 사용자가 다시 시도할 수 있게 보여 준다’ 같은 문장은 재사용 가치가 큽니다. 반면 임시 디버그 출력, 비밀값, 감정적인 작업 메모는 오래 남길 이유가 적습니다.

각 항목은 짧고 검증 가능해야 합니다. ‘코드를 깔끔하게’보다 ‘새 화면에는 로딩·빈 상태·오류 상태를 함께 확인한다’가 낫습니다. 결정 옆에 날짜와 근거 링크를 붙이면, 에이전트가 다른 제안을 할 때도 충돌 여부를 판단하기 쉬워집니다.

MCP로 연결하면 기록 관리가 자동이 될까요?

자동 연결은 편의일 뿐 승인 절차를 대신하지 않습니다. 공식 페이지는 OpenCode, Cursor, Claude Desktop 등에서 MCP 설정 예시를 제시하지만, 실제로 어떤 파일을 읽고 쓰는지와 저장소에 반영되는 범위는 내 환경에서 먼저 확인해야 합니다. 처음에는 에이전트가 기록을 수정하지 말고 변경안을 제안하게 하는 편이 좋습니다.

특히 팀의 기준 문서에 고객 데이터, 토큰, 개인 연락처를 넣어서는 안 됩니다. 사람이 읽기 위한 문서라 해도 도구와 동료에게 공유될 수 있기 때문입니다. 기억을 남기는 목적은 AI에게 더 많은 비밀을 주는 것이 아니라, 다음 판단을 덜 추측하게 만드는 데 있습니다.

FAQ: Markdown 파일 하나면 정말 충분한가요?

초기에는 충분합니다. 자주 반복되는 결정만 짧게 기록하고, 필요해질 때 구조를 나누세요. 처음부터 복잡한 지식베이스를 만들면 최신 상태를 유지하기 어렵습니다.

FAQ: AI가 기준 문서를 자동으로 고쳐도 될까요?

처음에는 제안만 받는 편이 안전합니다. 실제로 반복된 문제인지 사람이 확인한 뒤 반영해야 임시 해결책이 영구 규칙으로 굳는 일을 막을 수 있습니다.

FAQ: 개인 프로젝트도 기록이 필요한가요?

필요합니다. 가장 자주 잊는 사람은 다음 주의 나일 수 있습니다. 기준은 협업 도구이자 미래의 나를 위한 인수인계입니다.

출처: https://www.opencntx.dev/
패키지 확인: https://www.npmjs.com/package/opencontext-mcp
발표 확인: https://news.ycombinator.com/item?id=49494219
관찰 시점: 2026-08-31 KST