ChatGPT가 디자인 시스템을 잊어버리는 이유와 해결 방법 (2026)

이를 위한 파일이 존재하지 않습니다

코딩 에이전트들은 매 요청마다 파일을 로드하는 방식으로 이 가용성 문제를 절반쯤 해결했습니다. Cursor가 코딩 스타일을 잊어버리는 문제를 더 나은 규칙 파일을 작성하여 해결할 수 있는 이유가 바로 여기에 있으며, Lovable이 디자인 시스템을 유실하는 문제에 대한 해결책으로 지식 파일(knowledge file)이 제시되는 이유도 마찬가지입니다.

ChatGPT에는 이와 동등한 경로가 없습니다. 맞춤 지침은 작고 전역적인 블록에 불과합니다. 두세 개의 상시 규칙을 지정하는 데는 유용하지만, 컴포넌트 인벤토리를 담기에는 부적합하며, 어떤 제품을 작업하든 관계없이 모든 작업에 일괄 적용됩니다. Project 기능은 첨부된 파일을 해당 Project 내부로 제한하므로 도움이 되긴 하지만, 일반 채팅에서 가볍게 질문을 던지는 순간 무용지물이 됩니다. 그리고 메모리는 한두 페이지 분량에 불과합니다. ChatGPT 내에는 디자인 시스템을 담을 수 있는 구조가 전혀 없습니다.

메모리는 시스템의 구조화된 사실이 아니라 사용자에 대한 서술형 정보를 저장합니다

이 부분이 단순히 정보가 없는 것보다 상황을 더 악화시킵니다. 2026년 6월 메모리 기능이 개편된 이후, ChatGPT가 보관하는 것은 사용자가 입력한 정확한 단어가 아니라 시스템이 결론 내린 내용을 지속적으로 업데이트하여 요약한 '종합적인 요약본'입니다. 외부 추정치에 따르면 메모리 용량은 약 1,000단어 내외 또는 수백 개의 항목 수준입니다. OpenAI는 공식 수치를 발표하지 않으므로, 이는 대략적인 규모로만 이해하시면 됩니다.

이러한 요약 방식은 선호도를 저장하는 작은 메모리에는 적합한 절충안이지만, 디자인 시스템에는 완전히 잘못된 방식입니다. 토큰 테이블은 압축하기가 매우 어렵습니다. "여백 스케일은 4, 8, 12, 20, 32이며, 16은 없습니다"라는 규칙은 요약 과정을 거치며 "일관된 여백을 선호함"으로 변해버립니다. 여러분이 중요하게 생각하는 예외 사항이야말로 요약 과정에서 가장 먼저 누락되는 디테일이며, 결국 남는 것은 제약 조건이 아니라 모호한 '느낌'뿐입니다.

토큰이 제약 조건이 아니라 단순한 문서로 존재합니다

2026년 AI 지원 협업에 대해 글을 쓰는 디자인 시스템 실무자들은 한 가지 진단으로 의견을 모으고 있으며, 이는 모델 자체의 문제만은 아닙니다. 대부분의 조직에서 토큰과 컴포넌트 규약은 시스템이 검증하는 제약 조건이 아니라, 인간이 준수할 것으로 기대하는 '문서' 형태로만 존재합니다. 채팅창의 그 어떤 것도 팔레트에 없는 색상을 사용했다고 해서 출력을 거부할 수 없습니다.

즉, 모델에게 기억력과 선의에만 의존하여 작업을 수행하도록 요구하고 있는 셈입니다. 설령 모델이 팔레트를 완벽하게 기억하더라도 그것이 강제력(enforcement)을 가지지는 못합니다. 그저 수백만 개의 그럴듯한 다른 디자인 시스템을 학습한 모델이 제안하는 '정보에 기반한 권장 사항'에 불과할 뿐입니다.

일관성 이탈(Drift)은 세션 사이뿐만 아니라 단일 세션 내부에서도 발생합니다

사람들이 가장 많이 겪는 혼란스러운 오류는 바로 이것입니다. 동일한 대화 내에서 연이은 두 프롬프트 사이에 일관성이 깨지는 현상입니다. 대화 시작 부분에서 생성한 컴포넌트와 지금 생성한 변형(variant)이 일치하지 않으며, 아무도 변경을 지시하지 않았는데도 이런 일이 발생합니다.

이는 긴 컨텍스트(long-context) 문제의 전형적인 증상입니다. 긴 입력값의 중간에 있는 정보는 시작이나 끝에 있는 정보보다 덜 신뢰성 있게 활용됩니다. 이는 ChatGPT가 같은 대화에서 이전에 한 말을 잊어버리는 현상의 배후에 있는 메커니즘입니다. 처음에 붙여넣은 토큰 목록은 대화 상단에 위치하지만, 40번째 메시지에 도달할 때쯤이면 입력값에서 가장 취약한 위치로 밀려나고, 모델은 그 공백을 그럴듯한 임의의 값으로 채워 넣게 됩니다.

가공된 토큰 이름은 가장 잡아내기 어려운 오류입니다

API가 환각(hallucination)을 일으키면 에러가 발생합니다. 하지만 환각으로 만들어진 토큰 이름은 단순한 문자열에 불과합니다. var(--color-brand-600)은 에러 없이 조용히 실패하거나, 폴백(fallback) 처리되거나, 혹은 실제와 매우 유사하게 렌더링되어 코드 리뷰에서 누락되기 쉽습니다. 여러분의 명명 규칙(naming convention)을 모방하여 임의로 만들어진 이름은 무작위로 생성된 이름보다 더 위험합니다. 진짜처럼 보이기 때문입니다.

이것이 바로 팀들이 디자인 시스템의 일관성 이탈을 '시스템이 망가지는 것'이 아니라 '점진적으로 누적되는 것'으로 묘사하는 이유입니다. 에러는 발생하지 않고, 개별 변경 사항(diff)은 문제가 없어 보이지만, 6주일이 지나면 제품에 네 가지 서로 다른 버튼 스타일이 공존하게 됩니다.

매번 토큰과 컴포넌트 목록 붙여넣기. 작동은 하지만 점차 효과가 떨어집니다. 대화의 처음 세 메시지 내에서 가장 잘 작동하며, 매 작업마다 붙여넣는 비용을 감수해야 합니다. 또한 대화가 길어지도록 유도하여 위치적 일관성 이탈(positional drift)이 발생하기 쉬운 환경을 만듭니다.

주요 규칙을 맞춤 지침에 넣기. 여백 스케일, 두 개의 폰트 규칙, "절대로 토큰을 임의로 만들지 말 것"과 같이 뼈대가 되는 몇 가지 제약 조건을 설정하는 데는 올바른 방법입니다. 하지만 입력란이 작고 전역적으로 적용되기 때문에, 모든 작업에서 가장 중요한 5가지 사실을 골라내야 하므로 실질적이지만 부분적인 해결책에 불과합니다. 또한 이는 지침을 설정했으나 적용되지 않는 문제와는 또 다른 차원의 한계입니다.

디자인 시스템 문서를 첨부한 Project 기능 활용. 가장 우수한 기본 제공 옵션입니다. 범위가 올바르게 지정되고, 요약본 대신 실제 문서를 보관할 수 있습니다. 한계점은 ChatGPT에서만 사용할 수 있다는 점, 대화 세션이 길어지면 업로드된 파일이 컨텍스트에서 누락된다는 점 , 그리고 Project 외부에서 가볍게 던지는 질문에는 아무런 도움이 되지 않는다는 점입니다.

Figma 스크린샷 제공. 레이아웃 의도를 전달하는 데는 좋지만, 이름 지정에는 쓸모가 없습니다. 버튼 이미지 한 장으로는 프롭 시그니처(prop signature)를 알 수 없으며, 시각적으로 유사한 네 개의 버튼 중 어떤 것이 지원 중단(deprecated)되었는지도 전혀 알 수 없습니다.

디자인 시스템을 주입한 맞춤형 GPT(Custom GPT) 생성. 한 단계 발전된 방법이지만 유지보수가 걸림돌입니다. 디자인 시스템은 매주 변경되지만, 누군가 업데이트하지 않는 한 GPT의 파일은 그대로 유지됩니다. 오래된 시스템을 확신을 가지고 적용하는 것은 시스템이 아예 없는 것보다 더 나쁩니다.

AI를 실제 컴포넌트 라이브러리에 연결하기. 이는 실제로 루프를 완성하는 방향이며, 단순한 각주 이상의 가치가 있습니다. 동기화된 라이브러리, 코드 연결 스타일 매핑 또는 디자인 시스템 MCP 서버를 통해 생성을 실제 존재하는 컴포넌트로 제한하면, 브랜드 가이드라인을 벗어난 출력이 발생하는 것은 더 이상 기억력의 문제가 되지 않습니다. 팀에서 여기에 투자할 여력이 있다면 반드시 그렇게 하십시오. 채팅창이 제공할 수 있는 그 어떤 방법보다 지속 가능합니다.

이 목록 전체를 관통하는 패턴이 있습니다. 효과가 있는 모든 방법은 강제(enforcement) 또는 검색(retrieval)에 기반합니다. 실패하는 모든 방법은 반복을 통한 기억에 의존합니다.

문제를 솔직하게 나누어 보아야 합니다. 문제의 절반은 메모리 문제가 전혀 아니기 때문입니다.

기계적인 절반은 빌드(build) 단계의 몫입니다. 토큰을 코드가 소비하는 아티팩트로 컴파일하여, 시스템에 없는 값은 해석(resolve)되지 않도록 하세요. 원시 헥스(hex) 코드, 스케일을 벗어난 여백, 알 수 없는 토큰 이름을 거부하는 린트(lint) 규칙을 추가하고 이를 CI에서 실행하십시오. 컴포넌트 라이브러리를 컴포넌트의 유일한 단일 소스(source of truth)로 유지하세요. 린트 규칙은 망각하지 않으며, 그럴듯한 이름에 속아 넘어가지 않고, 대화가 얼마나 길어졌는지 신경 쓰지 않습니다. 이런 방식으로 표현할 수 있는 모든 것은 메모리가 아닌 이 방식으로 표현해야 합니다.

강제할 수 없는 나머지 절반은 검색 가능(retrievable)해야 합니다. 그 어떤 린터도 컴팩트 테이블 변형이 존재해야 하는 이유, 접근성 감사 이후 기존 모달이 지원 중단된 사실, 특정 패턴이 두 번이나 거절당한 이유, 또는 올바르게 보이는 두 컴포넌트 중 어느 것이 현재 버전인지 알지 못합니다. 이러한 지식은 서술형 텍스트이며, 수시로 변경되고, 여러분이 현재 AI에게 반복해서 설명하고 있는 바로 그 내용입니다. 이는 붙여넣기 버퍼가 아니라, 어시스턴트가 매 요청마다 읽을 수 있는 저장소에 보관되어야 합니다.

MemoryLake는 이 두 번째 절반을 위한 메모리 레이어입니다. 디자인 시스템 문서, 토큰 정의, 지원 중단 항목, 그리고 그 이면의 결정 사항들을 하나의 저장소에 담아, API를 통해 ChatGPT에서 읽거나 Claude 및 Codex와 같은 MCP 지원 도구에서 직접 읽을 수 있도록 합니다. 경계를 명확히 하자면, 이 레이어는 아무것도 강제하지 않으며 디자인 시스템 자체도 아닙니다. 강제는 파이프라인이 담당하며, 이 레이어는 시스템을 가용하고 최신 상태로 유지하는 역할을 합니다.

1단계: API 키 생성

키를 생성하고 약 30초 만에 첫 번째 요청을 보낼 수 있습니다. 이 키를 채팅창에 붙여넣지 말고 환경 변수나 보안 비밀 관리자(secret manager)에 보관하세요.

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

현재 붙여넣고 있는 문서, 이미지, 파일들을 업로드하세요. 실제로 정의된 토큰 정의, 컴포넌트 API 레퍼런스, 날짜가 포함된 지원 중단 목록, 접근성 관련 결정 사항, 거절된 패턴과 그 이유 등이 해당됩니다. 깔끔하게 정리된 요약본 대신 소스 파일 자체를 업로드하세요. 요약본을 올리면 "16px 단계는 없다"는 내용이 "일관된 여백을 선호함"으로 변질될 수 있습니다.

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

Claude, Codex, OpenClaw 및 기타 AI 에이전트가 MCP 또는 API를 통해 메모리에 액세스할 수 있도록 설정하세요. ChatGPT에는 MCP 클라이언트가 없으므로, API를 통해 시스템의 관련 부분을 검색하여 프롬프트, 맞춤형 GPT의 지침 또는 모델을 호출하는 워크플로우에 주입해야 합니다. MCP를 지원하는 도구들은 동일한 저장소를 직접 읽습니다. 이는 매우 중요한데, 컴포넌트를 작성하는 에이전트와 이를 디자인하는 어시스턴트가 동일한 시스템을 공유해야 하기 때문입니다.

첫 번째 변화는 임의로 만들어진 토큰 이름이 거의 사라지고, 간혹 발생하는 오류도 확실히 잡아낼 수 있게 된다는 점입니다. 검색(Retrieval)은 생성 시점에 실제 이름을 제공하고, 린터(linter)는 커밋 시점에 그 외의 모든 것을 거부합니다. 둘 중 하나만으로는 부족하지만, 함께 작동하면 완벽한 루프를 형성합니다.

두 번째는 대화가 길어질 필요가 없어진다는 점입니다. 요청과 함께 시스템 정보가 전달되므로, 대화 시작 부분에 3,000개의 토큰에 달하는 팔레트 정보를 미리 밀어 넣고 40번째 메시지까지 살아남기를 바랄 필요가 없습니다. 모델은 짧은 대화에서 가장 신뢰할 수 있으며, 컨텍스트를 반복해서 설명할 필요가 없어진다는 것이 짧은 대화를 효율적으로 유지할 수 있게 해줍니다.

세 번째는 마침내 지원 중단(deprecation)이 제대로 작동한다는 점입니다. 현재로서는 지난 분기에 폐기한 컴포넌트가 모델의 세계에 여전히 존재합니다. 여러분의 명명 규칙과 유사하고, 코드베이스에 등장한 적이 있으며, 폐기되었다는 표시가 없기 때문입니다. 날짜와 상태가 기록된 레코드만이 현재 버전과 과거 이력을 구분할 수 있는 유일한 방법이며, 이는 아키텍처 결정에 그 이유가 함께 첨부되어야 하는 이유와 동일합니다.

또한 이는 더 이상 ChatGPT에만 국한되지 않습니다. 디자인 시스템은 채팅창뿐만 아니라 코딩 에이전트도 제약하며, 프로젝트의 컨텍스트 없이 작동하는 어시스턴트는 모든 도구에서 공통으로 겪는 문제입니다. 하나의 저장소로 모든 리더(reader)를 지원할 수 있습니다.

기계적인 것은 강제하고, 맥락적인 것은 검색하세요

값, 이름, 스케일, 컴포넌트 경계는 토큰과 린트 규칙으로 관리해야 합니다. 근거, 지원 중단, 예외 사항, 거절된 패턴은 검색 가능한 레코드로 관리해야 합니다. 이 구분을 어느 한쪽으로라도 잘못하면 대부분의 좌절이 시작됩니다. 팀들이 의도(intent)를 린트로 검사하려 하거나, 값(values)을 기억에 의존하려 하기 때문입니다.

기계가 읽을 수 있는 버전의 시스템을 배포하세요

토큰이 Figma 파일과 슬라이드 덱에만 존재한다면, 인간이든 모델이든 모든 소비자는 추측에 의존할 수밖에 없습니다. 단일 소스(source of truth)에서 생성된 JSON 또는 CSS 아티팩트는 강제와 검색을 모두 가능하게 만드는 핵심 요소이며, 이 목록에서 가장 레버리지가 높은 작업입니다.

지원 중단 항목에 날짜를 표시하고 기존 항목을 유지하세요

문서에서 폐기된 컴포넌트를 완전히 삭제하면, 해당 컴포넌트를 여전히 사용 중인 기존 코드를 설명할 방법이 사라집니다. 지원 중단 표시를 하고, 날짜를 명시하며, 대체할 컴포넌트 이름을 지정하세요. 코드베이스와 일치하지 않는 날짜 미상의 디자인 시스템은 "7월 기준"이라고 솔직하게 명시된 시스템보다 더 나쁩니다.

항상 로드되는 세트는 엄격한 제약 조건으로만 제한하세요

매 요청마다 주입하는 정보는 단순히 '비전형적인' 출력이 아니라 '완전히 잘못된' 출력을 걸러내는 규칙이어야 합니다. 예를 들어 여백 스케일, 팔레트, "절대로 토큰 이름을 임의로 만들지 말 것" 등이 이에 해당합니다. 전체 컴포넌트 레퍼런스는 검색(retrieval) 영역에 두어야 합니다. 모든 질문 앞에 디자인 시스템의 방대한 역사적 맥락을 늘어놓으면 정작 중요한 질문이 묻히게 됩니다.

코드를 요청하기 전에 사용할 이름을 먼저 확인하세요

규모가 큰 작업의 경우, 모델에게 사용할 예정인 토큰과 컴포넌트 목록을 먼저 제시하도록 한 뒤, 이를 확인하고 나서 코드를 생성하게 하세요. 90줄의 CSS 코드를 꼼꼼히 읽는 대신 5개의 이름을 30초 동안 검토하는 것이 훨씬 효율적이며, 특히 '그럴듯한 이름'으로 발생하는 오류를 확실히 잡아낼 수 있습니다.

AI가 시스템을 정의하게 두지 마세요

가장 유혹적인 지름길은 모델에게 토큰 설계를 제안하도록 요청한 뒤 그 출력을 표준으로 삼는 것입니다. 이는 결국 아무도 결정하지 않은 시스템을 갖게 되는 결과를 초래합니다. 모델은 디자인 시스템의 소비자이지, 설계자가 아닙니다.

ChatGPT가 디자인 시스템을 잊어버리는 이유는 제품 내에 디자인 시스템이 상주할 공간이 없기 때문입니다. 규칙 파일도 없고, 맞춤 지침은 작고 전역적이며, Project 파일은 범위가 제한되어 있고, 메모리는 토큰 테이블 대신 선호도에 대한 요약된 정보만 저장합니다. 게다가 대부분의 조직에서 토큰은 제약 조건이 아닌 단순한 문서로 존재하므로, 설령 완벽하게 기억하더라도 그저 정보에 기반한 제안에 그칠 뿐입니다.

해결책은 양방향으로 진행되어야 하며, 둘 중 어느 것도 생략할 수 없습니다. 토큰을 컴파일하고, 위반 사항을 린트로 검사하며, 생성을 실제 존재하는 컴포넌트로 제한하세요. 린트 규칙은 결코 망각하지 않기 때문입니다. 그런 다음 린터가 표현할 수 없는 부분, 즉 의사결정 이유, 지원 중단 항목, 예외 사항, 이미 거절된 패턴 등을 어시스턴트가 매 요청마다 읽을 수 있는 하나의 저장소에 보관하세요. 그렇게 하면 팔레트는 더 이상 복사해서 붙여넣는 대상이 아니라, 시스템이 스스로 인지하는 지식이 됩니다.