ChatGPT가 코딩 스타일을 잊어버리는 이유와 해결 방법 (2026)

채팅 앱에는 규칙 파일 역할을 하는 것이 없습니다

이것이 구조적인 차이의 전부이며, 해결책을 알아보기 전에 짚고 넘어갈 가치가 있습니다. Cursor의 공식 문서에서는 규칙 파일이 존재하는 이유를 다음과 같이 설명합니다. "대형 언어 모델은 완료(completion) 간에 메모리를 유지하지 않습니다. 규칙은 프롬프트 수준에서 지속적이고 재사용 가능한 컨텍스트를 제공합니다."

여러분의 스타일을 기억하는 것처럼 보이는 모든 코딩 도구는 디스크의 파일에서 매 요청마다 동일한 텍스트를 다시 제공하는 방식으로 작동합니다. Cursor는 .cursor/rules를 읽고, Claude Code는 CLAUDE.md를 읽으며, Codex는 AGENTS.md를 읽습니다. 그렇기 때문에 Claude가 코딩 스타일을 잊어버리는 문제나 Cursor가 이를 잊어버리는 문제는 대개 더 나은 파일을 작성함으로써 해결할 수 있습니다.

하지만 ChatGPT에는 그런 파일이 없습니다. 답변하기 전에 읽는 로컬 경로가 존재하지 않습니다. 따라서 다른 모든 도구에서 스타일을 유지해 주는 메커니즘을 사용할 수 없으며, 이를 대체하는 수단들은 모두 크기가 훨씬 작습니다.

메모리는 스타일 가이드가 아니라 선호도를 저장하는 크기입니다

ChatGPT의 저장된 메모리는 의도적으로 짧게 설계되었습니다. 매 프롬프트와 함께 전송되므로 크기가 곧 요청당 비용이 되기 때문입니다. 공식적으로 발표된 수치는 없지만, 대략 총 1,200~1,400 단어 또는 약 200개의 항목 정도로 추정되며 의견이 분분합니다. 그냥 한두 페이지 분량이라고 생각하시면 됩니다.

실제 스타일 가이드는 한두 페이지에 다 들어가지 않습니다. 억지로 넣으려고 하면 한계에 부딪히게 됩니다. 메모리가 가득 차면 ChatGPT는 무언가를 삭제할 때까지 새로운 장기 사실을 추가하지 않는데, 이는 그 자체로 또 다른 골칫거리입니다. OpenAI가 2026년 6월 4일에 발표한 개편된 메모리 시스템은 시간이 지나도 최신 상태를 유지하는 읽기 쉬운 메모리 요약 기능과 Plus 및 Pro 사용자를 위한 두 배의 용량을 제공하며 이를 개선했습니다. 하지만 한두 페이지를 두 배로 늘려도 여전히 스타일 가이드를 담기에는 부족합니다. 또한 새로운 시스템은 정확한 단어를 그대로 저장하기보다는 종합(synthesize)하여 저장하므로, 정밀하게 작성된 컨벤션이 다른 말로 패러프레이징되어 적용될 수 있다는 점도 알아두어야 합니다.

스타일은 하나의 지침이 아니라 수백 개의 작은 결정들입니다

"우리 코딩 스타일을 따르세요"라는 말은 하나의 지침처럼 보입니다. 하지만 실제로는 불리언 변수 명명법, 에러 처리 방식, 타입 정의 위치, barrel export 사용 여부, props 정렬 순서, 주석이 필요한 시점, 루프를 작성하는 대신 사용할 유틸리티 함수, 테스트 이름 지정 방식 등 수많은 세부 사항을 포함합니다.

이러한 사항 중 대부분은 명시적으로 언급되지 않습니다. 위반된 코드를 보고 나서야 비로소 깨닫게 됩니다. 즉, 스타일 가이드는 채팅을 통해 점진적으로 발견되며, 각 발견은 그것이 일어난 대화방 안에서만 존재합니다. 열 번의 세션을 거치는 동안 ChatGPT는 여러분의 컨벤션 중 서로 다른 10가지 하위 집합을 전달받았을 뿐, 그 어느 것도 온전히 기억하지 못합니다.

복사해서 붙여넣는 방식의 한계

결국 누구나 세션 시작 시점에 컨벤션 블록을 복사해서 붙여넣는 방식을 쓰게 됩니다. 하지만 시간이 지날수록 그 내용은 짧아집니다. 기억에 의존해 타이핑하게 되고, 예외 사항을 적는 것은 귀찮기 때문에 4주 차에 붙여넣는 내용은 1주 차 내용의 절반 수준으로 줄어듭니다. 여러분이 직접 다시 설명하는 내용이 달라지기 때문에 스타일도 어긋나게 됩니다. 이는 컨텍스트를 수동으로 매번 다시 설명해야 하는 흔한 문제입니다.

여기서 한 가지 다른 문제와 구분할 필요가 있습니다. 만약 맞춤 지침에 컨벤션을 넣었는데도 무시당한다면, 그것은 지침이 설정되었으나 적용되지 않는 문제로 다른 종류의 실패입니다. 이 글은 컨벤션이 아예 존재하지 않아 발생하는 문제에 대해 다룹니다.

맞춤 지침 (Custom instructions). 가장 먼저 시도해 볼 만한 좋은 방법이며, 몇 가지 엄격한 규칙을 적용하는 데 실제로 효과적입니다. 하지만 입력란이 작기 때문에 가장 중요한 5가지 컨벤션을 골라내야 하며, 모든 작업에 일괄 적용됩니다. 회사에서는 Go를 쓰고 집에서는 TypeScript를 쓰는 경우라면 적절하지 않습니다.

저장된 메모리 (Saved memory). 두세 가지의 고정된 선호도("나는 TypeScript 엄격 모드를 사용함")를 기억하는 데는 유용합니다. 하지만 가이드를 담기에는 적합하지 않은 그릇이며, 스타일 규칙으로 메모리를 채우면 자신에 대한 다른 중요한 정보를 저장할 용량이 부족해집니다.

컨벤션 파일이 첨부된 Project. 기본 제공 옵션 중 가장 좋습니다. 해당 프로젝트로 범위가 제한되어 전역적으로 섞이지 않으며, 요약본이 아닌 실제 문서를 제공할 수 있습니다. 한계점은 ChatGPT 내로 범위가 제한된다는 점, 긴 세션 동안 파일이 컨텍스트 내에 안정적으로 유지되지 않는다는 점, 그리고 일반 채팅에서 가볍게 묻는 질문에는 도움이 되지 않는다는 점입니다.

스타일 가이드가 지침에 포함된 맞춤형 GPT (Custom GPT). 효과적이고 확실히 한 단계 발전된 방법입니다. 맞춤 지침 블록보다 더 긴 지침을 넣을 수 있기 때문입니다. 다만 프로젝트마다 별도의 어시스턴트를 관리하고 매번 잊지 않고 사용해야 하며, 가이드를 업데이트하려면 GPT를 직접 수정해야 합니다.

매 세션마다 가이드 붙여넣기. 이론적으로는 확실하지만 실제로는 점차 소홀해지기 쉬우며, 대화할 때마다 토큰 비용이 발생합니다.

린터와 포매터 (Linter & Formatter). 기계적인 모든 문제를 해결하는 프로페셔널한 정답이며, 각주가 아닌 가장 먼저 언급되어야 할 핵심입니다. 아래 내용을 참고하세요.

먼저 스타일을 두 부분으로 나누세요. 스타일의 절반은 프롬프트에 전혀 들어갈 필요가 없기 때문입니다.

기계적인 부분은 도구에 맡겨야 합니다. 따옴표 스타일, 세미콜론, 들여쓰기, import 순서, 줄 길이, trailing comma, 그리고 대부분의 명명 패턴은 레포지토리에 설정 파일을 커밋해 둠으로써 Prettier, ESLint, Black, gofmt, rustfmt 또는 해당 언어의 도구로 강제할 수 있습니다. 포매터는 절대 잊어버리지 않습니다. AI에게 들여쓰기 선호도를 기억해 달라고 요청하는 것은 언어 모델을 린터로 사용하는 격이며, 이는 실제 린터보다 항상 성능이 떨어질 수밖에 없습니다. 이것이 이 글 전체에서 가장 효과가 큰 조치이며, 메모리와는 아무런 관련이 없습니다.

판단이 필요한 부분은 메모리 레이어가 필요합니다. 어떤 포매터도 "서비스 레이어에서는 상속을 사용하지 않는다", "기발한 한 줄짜리 코드보다 이름이 명확한 헬퍼 함수를 선호한다", "생성된 API 클라이언트에서만 any를 허용하고 다른 곳에서는 금지한다", "에러 메시지는 사용자에게 노출되므로 그에 맞게 작성한다"와 같은 내용을 표현할 수 없습니다. 이것들은 이유가 있는 컨벤션이며, 이유가 명확해야 불필요한 논쟁을 막을 수 있습니다.

이 두 번째 절반이 바로 ChatGPT가 매 요청마다 읽을 수 있는 저장소에 넣어야 할 내용입니다. 매번 다시 타이핑하는 복사-붙여넣기나, 다른 정보와 경쟁해야 하는 두 페이지짜리 메모리 예산이 아닙니다. MemoryLake는 이 작업을 위한 메모리 레이어입니다. 여러분의 컨벤션 문서가 하나의 저장소에 보관되어 필요할 때마다 검색되며, Claude, Codex 및 기타 에이전트에서도 읽을 수 있으므로 스타일 가이드가 도구별로 파편화되지 않습니다.

솔직한 한계점도 하나 있습니다. 컨벤션을 안정적으로 제공하면 이를 따르는 빈도는 확실히 높아지지만, 100% 준수를 보장하지는 않습니다. 모델이 읽은 내용을 실행에 옮길지 여부는 결국 모델 자체의 행동 방식에 달려 있기 때문입니다. 그렇기 때문에 기계적인 부분을 포매터에 맡겨야 하는 것입니다. 강제해야 하는 모든 사항에는 강제력을 가진 도구를 사용하세요.

1단계: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 보낼 수 있습니다. 채팅창에 붙여넣거나 커밋하지 말고 환경 변수나 시크릿 관리자에 보관하세요.

2단계: 첫 번째 메모리 업로드하기

실제 컨벤션이 담긴 문서, 이미지, 파일을 업로드하세요. 스타일 가이드, "서비스 작성 방법" 문서, 팀원들이 논쟁할 때 기준으로 삼는 리뷰 체크리스트, 모범적이라고 생각하는 코드 예시 등이 해당됩니다. 이유도 함께 포함하세요. 이유가 없는 컨벤션은 조금만 불편해져도 모델과 사람 모두에게 무시되기 쉽습니다.

3단계: AI 및 에이전트 연결하기

Claude, Codex, OpenClaw 및 기타 AI 에이전트가 MCP 또는 API를 통해 메모리에 액세스할 수 있도록 하세요. ChatGPT에는 MCP 클라이언트가 없으므로 API를 통해 접근해야 합니다. 관련 컨벤션을 검색하여 프롬프트, 맞춤형 GPT의 지침 또는 모델을 호출하는 워크플로우에 주입합니다. MCP를 지원하는 도구들은 동일한 저장소를 직접 읽을 수 있습니다. 이것이 바로 핵심입니다. 하나의 스타일 가이드로 모든 어시스턴트를 제어하는 것입니다.

첫 번째 변화는 컨벤션의 양이 줄어들지 않는다는 점입니다. ChatGPT가 보는 것은 여러분의 기억이 아니라 실제 문서이므로, 20주 차의 결과물도 1주 차와 동일한 기준을 유지합니다.

두 번째는 가이드가 올바르게 성장한다는 점입니다. 코드 리뷰 도중에 새로운 컨벤션을 발견하면, 곧 끝날 채팅창에 한 문장을 적는 대신 문서에 한 줄을 추가하게 됩니다. 몇 달이 지나면 이는 실제 스타일 가이드와 구전으로만 전해지는 기억의 차이로 나타납니다.

세 번째는 코드 리뷰가 유용해진다는 점입니다. "이 코드가 우리 컨벤션에 맞나요?"라는 질문은 컨벤션을 검색할 수 있을 때만 의미가 있습니다. 지금은 그저 일반적인 모범 사례만 답변할 뿐입니다. ChatGPT가 프로젝트 컨텍스트 없이 작동할 때 코드 리뷰가 자신감 넘치면서도 동시에 핵심을 벗어난 것처럼 느껴지는 이유가 바로 여기에 있습니다.

또한 이는 더 이상 ChatGPT에만 국한되지 않습니다. 컨벤션은 어시스턴트가 아니라 코드베이스의 속성입니다. 공유 저장소에 저장해 두면 다른 도구로 전환하더라도 처음부터 다시 가르칠 필요가 없습니다.

표현 가능한 모든 것에 대해 린터를 단일 진실 공급원(Source of Truth)으로 삼으세요

설정 파일을 커밋한 다음, AI의 출력을 프롬프트로 제어하려 하지 말고 린터로 검사하게 하세요. 이렇게 하면 기억해야 할 내용이 진정으로 판단이 필요한 부분으로 좁혀지고, 위반 사항이 논쟁의 대상이 아니라 눈에 보이는 사실이 됩니다.

컨벤션을 이유가 포함된 규칙으로 작성하세요

"early return을 사용하세요"는 단순한 선호도이므로 무시되기 쉽습니다. "early return을 사용하세요. 이 코드베이스에서 중첩된 조건문 때문에 else 분기를 놓쳐 두 번의 프로덕션 버그가 발생했습니다"는 명확한 근거가 있는 규칙입니다. 또한 이유는 해당 컨벤션이 더 이상 유효하지 않게 되었을 때 이를 알아차리는 데 도움이 됩니다.

줄글뿐만 아니라 모범 예시를 포함하세요

스타일을 전달하는 가장 빠른 방법은 올바르다고 생각하는 짧은 파일을 제공하는 것입니다. 모델은 형용사 목록보다 예시를 통해 더 안정적으로 일반화하며, 모범 예시는 여러분이 미처 말로 표현하지 못한 수많은 작은 결정들을 담고 있습니다.

항상 로드되는 부분은 작게 유지하세요

맞춤 지침이나 짧은 컨벤션 헤더처럼 매 요청마다 주입되는 내용은 전체 가이드가 아니라 가장 자주 위반되는 5가지 규칙이어야 합니다. 나머지는 검색(retrieval)의 영역에 두어야 합니다. 모든 질문 앞에 스타일 규칙 장벽이 세워지면 정작 중요한 질문이 묻히게 됩니다.

예외 사항을 명시적으로 기록하세요

모든 실제 코드베이스에는 "Y의 경우를 제외하고는 X를 한다"는 예외가 있습니다. 기록되지 않은 예외는 AI가 명시된 규칙을 정확히 따르면서도 가장 엉뚱한 결과를 내는 원인이 됩니다. 결국 가이드에 반영되지 않아 매번 똑같은 내용을 반복해서 수정하게 됩니다.

ChatGPT가 코딩 스타일을 잊어버리는 이유는 답변하기 전에 읽는 파일이 없기 때문입니다. 코딩 에이전트들은 매 요청마다 로드되는 규칙 파일로 이를 해결하지만, 채팅 앱은 작은 맞춤 지침 블록, 가이드보다는 선호도에 맞춰진 크기의 메모리, 그리고 Project 범위 제한만을 제공합니다. 결국 여러분의 컨벤션은 마지막으로 설명했던 대화 속에 머물게 됩니다.

해결책은 단일 조치가 아니라 분할하는 것입니다. 기계적인 모든 것은 설정 파일이 커밋된 포매터와 린터에 맡기세요. 포매터는 잊어버리지 않으며, 언어 모델은 들여쓰기 작업에서 전용 도구를 절대 따라갈 수 없습니다. 판단이 필요한 부분(이유가 포함된 컨벤션, 예외 사항, 모범 예시)은 어시스턴트가 매 요청마다 읽는 저장소에 넣으세요. 그러면 가이드가 여러분의 기억력 감퇴 속도에 맞춰 사라지는 일도 없고, 특정 제품에만 종속되는 일도 없어집니다.