ChatGPT가 아키텍처 결정을 잊어버리는 이유
결정은 제약 조건과 이유의 결합입니다
"서비스 간에 데이터베이스를 공유하지 않는다"는 결정의 절반에 불과합니다. 나머지 절반은 마이그레이션 순서로 인해 두 번의 장애가 발생했고, 스키마를 소유한 팀이 모든 배포를 통제할 수 없기 때문이다라는 이유입니다. 두 번째 절반이 없다면 첫 번째 절반은 단순한 선호도일 뿐이며, 선호도는 그럴듯해 보이는 대안에 매번 밀리게 됩니다.
이것이 바로 아키텍처 결정 기록(ADR) 관행이 존재하는 이유입니다. ADR은 결정을 강제한 맥락(context) 및 그에 따르는 결과와 결정을 쌍으로 묶어줍니다. 팀들은 단순한 결정만으로는 새로운 사람이나 새로운 상황을 맞닥뜨렸을 때 살아남지 못한다는 것을 계속해서 깨달았기 때문입니다. 어시스턴트는 매 세션마다 새로운 사람과 같습니다.
요약되면서 사라지는 것은 바로 '이유'입니다
이것이 일반적인 망각보다 상황을 더 악화시키는 메커니즘입니다. ChatGPT의 저장된 메모리는 설계상 짧습니다. 모든 프롬프트와 함께 전달되어야 하기 때문입니다. 그리고 OpenAI가 2026년 6월에 발표한 메모리 개편 이후, 사용자가 얻는 것은 사용자가 말한 내용의 기록이 아니라, 시스템이 사용자에 대해 결론 내린 내용을 종합하여 지속적으로 업데이트하는 메모리 요약(summary)입니다.
종합(Synthesis)은 작은 메모리를 유용하게 유지하기에는 적절한 절충안이지만, 결정 사항에는 잘못된 방식입니다. "마이그레이션 순서로 인해 두 번의 장애가 발생했으므로 데이터베이스를 공유하지 말 것"을 압축하면 자연스럽게 "서비스 소유의 데이터베이스를 선호함"이라는 결과가 나옵니다. 제약 조건은 사라지고 선호도만 남으며, 선호도는 언제든 뒤집힐 수 있습니다. 결국 아키텍처를 단순한 스타일 선택으로 반쯤 기억하는 어시스턴트를 얻게 됩니다.
거부된 옵션은 절대 기록되지 않습니다
아키텍처 논의에서 가장 가치 있는 콘텐츠는 제외된 항목들과 그 이유의 목록입니다. 하지만 무언가를 제외하는 순간에는 그것이 너무 당연하고 기록할 가치가 없다고 느껴지기 때문에 아무도 기록하지 않는 콘텐츠이기도 합니다.
채팅 워크플로우에서는 이를 포착할 수 있는 것이 없습니다. 그래서 매 분기마다 동일한 세 가지 대안이 제안되고, 그때마다 왜 그것이 작동하지 않는지 다시 도출하는 데 20분을 소비하게 됩니다. 이는 어시스턴트가 이미 거부한 아이디어를 반복해서 제시하는 패턴의 원인입니다.
코딩 에이전트와 달리 이를 위한 파일이 없습니다
코딩 에이전트는 매 요청마다 파일을 로드하여 이 문제의 가용성 절반을 해결했습니다. Cursor가 아키텍처 결정을 잊어버리는 문제가 보통 더 나은 규칙 파일을 작성함으로써 해결되는 이유가 바로 여기에 있습니다.
ChatGPT에는 이에 상응하는 것이 없습니다. 답변하기 전에 읽는 경로가 없습니다. Custom instructions는 작고 글로벌하게 적용됩니다. Project에 첨부된 파일은 해당 Project로 범위가 제한됩니다. Memory는 한두 페이지에 불과합니다. 이 중 어느 것도 결정 로그가 아니므로, 아키텍처는 마지막으로 논의했던 대화 속에만 머물게 됩니다.
결정은 바뀌지만 이전 결정은 철회되지 않습니다
아키텍처는 버전을 관리하든 안 하든 버전이 지정됩니다. 3분기에 테넌시 모델을 개정하면, 2분기 모델 하에서 이루어진 모든 설계는 당시에는 올바른 것이었습니다. 채팅 기반 워크플로우에는 특정 날짜에 어떤 결정이 다른 결정을 대체했다는 사실을 기록할 공간이 없습니다. 결국 과거에 직접 작업한 내용을 해석할 수 없게 되는데, 이는 ADR이 상태(status) 필드를 통해 방지하고자 하는 실패 모드입니다.
사람들이 시도하는 방법들
매번 다시 설명하기. 작동은 하지만 점차 퇴화합니다. 기억에 의존해 다시 설명하기 때문에, 9월에 입력하는 버전은 7월에 도출한 버전의 자극적인 절반에 불과하며, 제약 조건이라는 지루한 절반은 누락됩니다.
가장 중요한 결정을 custom instructions에 넣기. 두세 개의 핵심 제약 조건에 대해서는 올바른 첫 단계이며 해볼 만한 가치가 있습니다. 하지만 텍스트 블록이 작기 때문에 가장 중요한 결정을 선택해야 하고, 글로벌하게 적용되므로 여러 시스템에서 작업할 때는 적절하지 않습니다.
결정을 memory에 저장하기. 안정적인 몇 가지 결정에는 괜찮지만, 곧 두 가지 장벽에 부딪힙니다. 공간이 부족해지고 — 메모리가 가득 차서 새로운 항목을 수락하지 않음 — 살아남는 것은 추론 과정이 아니라 종합된 패러프레이즈(paraphrase)뿐입니다.
아키텍처 문서가 첨부된 Project 사용. 가장 훌륭한 내장 옵션입니다. 범위가 올바르게 지정되고 요약이 아닌 실제 문서를 보관합니다. 하지만 ChatGPT 전용이며, 긴 세션 동안 파일이 컨텍스트에 안정적으로 유지되지 않고, 일반 채팅에서 던지는 빠른 질문에는 도움이 되지 않습니다.
리포지토리에 ADR 작성하기. 전문적인 해결책이며, 묻어두기보다 명확하게 밝힐 가치가 있습니다. 결정, 맥락, 결과, 상태가 포함된 번호가 매겨진 docs/adr/ 디렉토리를 커밋하고 검토하는 것이 아키텍처 근거를 보존하는 올바른 방법입니다. 이는 팀원이 퇴사해도 살아남고, 변경 사항을 비교(diff)할 수 있으며, 특정 벤더에 의존하지 않습니다. 팀에서 아직 이 작업을 하고 있지 않다면 시작하세요. 이 글의 그 어떤 내용보다 가치 있는 일입니다.
문제는 리포지토리의 ADR이 실제로 함께 생각하고 있는 어시스턴트에게는 보이지 않는다는 점입니다. 추론 과정을 기록해 두었음에도 ChatGPT는 여전히 이를 볼 수 없으므로, 관련 내용을 복사해서 붙여넣거나, 대개의 경우 귀찮아서 붙여넣지 않게 됩니다.
해결책: ChatGPT가 매번 읽을 수 있는 결정 기록 제공하기
다음 두 단계를 순서대로 실행합니다.
비공식적이더라도 ADR 형태로 결정을 작성하세요. 제목, 상태, 결정을 강제한 맥락, 결정 사항, 제외된 항목, 수용한 결과, 날짜를 포함합니다. 도구보다 형태가 더 중요합니다. 형태가 있어야 제약 조건에 이유를 계속 연결해 둘 수 있으며, 이것이 바로 이 글에서 다루는 실패를 방지하는 핵심입니다. '고려된 대안(Alternatives-considered)'은 선택 사항이 아닙니다. 논쟁의 재발을 막아주는 핵심 부분입니다.
그 다음 어시스턴트가 이 기록에 접근할 수 있도록 만드세요. 붙여넣는 것이 아니라 검색(retrieve)되도록 하는 것입니다. 어시스턴트가 매 요청마다 읽는 저장소를 사용하면, 결정 사항이 종합된 형태가 아니라 작성한 그대로의 이유, 날짜, 거부된 대안과 함께 전달됩니다.
MemoryLake는 이를 위해 구축된 메모리 레이어입니다. 결정 기록, 제약 조건, 소스 문서가 하나의 저장소에 보관되며, API를 통해 ChatGPT에서 읽을 수 있고 Claude 및 Codex와 같은 MCP 지원 도구에서 직접 읽을 수 있습니다. 따라서 동일한 결정이 설계 대화, 마이그레이션을 작성하는 코딩 에이전트, 그리고 9월에 합류한 엔지니어에게 모두 전달됩니다.
명시해야 할 두 가지 한계가 있습니다. 메모리 레이어는 팀 거버넌스를 위한 커밋된 ADR을 대체하지 않습니다. 버전 관리 시스템에 없는 결정 기록은 검토할 수 없으며, 검토 가능성은 이 관행의 핵심 목적 중 절반을 차지합니다. 또한 결정을 안정적으로 제공하면 이를 준수하는 빈도가 높아지지만, 어시스턴트가 이를 반드시 준수한다고 보장할 수는 없습니다. 이는 모델의 행동 방식이기 때문입니다. 달라지는 점은 제약 조건과 그 이유가 누락되거나 패러프레이즈되는 대신, 현재 상태 그대로 존재하게 된다는 것입니다.
1단계: API 키 생성
키를 생성하고 약 30초 만에 첫 번째 요청을 보낼 수 있습니다. 채팅에 붙여넣는 대신 환경 변수나 시크릿 관리자에 보관하세요.
2단계: 첫 번째 메모리 업로드
실제 결정이 담겨 있는 문서, 이미지, 파일을 업로드하세요. ADR, 설계 문서, 제약 조건을 유발한 장애 보고서, 누군가 작성하고 모두가 동의한 RFC 등이 해당됩니다. 정리된 요약본 대신 소스 자체를 업로드하세요. 요약본에서는 "두 번의 장애 때문에"가 "서비스 소유의 데이터베이스를 선호함"으로 변질되기 쉽습니다.
3단계: AI 및 에이전트 연결
Claude, Codex, OpenClaw 및 기타 AI 에이전트가 MCP 또는 API를 통해 메모리에 액세스할 수 있도록 하세요. ChatGPT에는 MCP 클라이언트가 없으므로 API를 사용해야 합니다. 관련 결정을 검색하여 프롬프트, custom GPT의 instructions 또는 모델을 호출하는 워크플로우에 주입합니다. MCP를 지원하는 도구는 동일한 저장소를 직접 읽습니다. 코드를 작성하는 에이전트에게도 이를 설계하는 어시스턴트와 동일한 제약 조건이 필요하기 때문에 이는 매우 중요합니다.
실제 적용 시 달라지는 점
첫 번째 차이점은 거부된 옵션이 계속 거부된 상태로 유지된다는 것입니다. 보고 서비스에 대해 질문하면 공유 스키마 접근 방식이 새로 제안되는 대신, 장애 이력이 첨부된 채 이미 제외된 상태로 답변이 돌아옵니다.
두 번째는 설계 대화가 훨씬 더 진전된 단계에서 시작된다는 점입니다. 처음 15분을 제약 조건을 다시 설정하는 데 낭비하지 않고, 실제 질문에 집중할 수 있습니다. 이는 복리로 작용합니다. 기록에 더 많은 결정이 누적될수록 새로운 대화가 더 많은 맥락을 상속받게 됩니다.
세 번째는 대체된 결정들이 혼란을 주기보다 명확하게 해석된다는 점입니다. 날짜와 상태가 표시된 결정을 통해 "해당 서비스는 8월 이전의 테넌시 모델 하에서 구축되었다"고 말할 수 있게 되며, 왜 설계가 잘못되어 보이는지 의아해할 필요가 없어집니다. 이는 과거의 아키텍처를 해석 가능하게 만드는 유일한 속성입니다.
또한 이는 ChatGPT에만 국한되지 않습니다. 테넌시 결정은 설계 대화뿐만 아니라 코딩 에이전트도 제약하며, 프로젝트 맥락 없이 시작되는 어시스턴트는 모든 도구에서 발생하는 동일한 문제입니다. 기록이 공유 저장소에 보관되면 모든 도구가 이를 상속받습니다.
AI가 활용할 수 있는 결정을 작성하는 모범 사례
결정을 강제한 맥락을 항상 작성하세요
"주문에 이벤트 소싱을 사용합니다"라는 문장은 논쟁을 불러일으킵니다. "재무팀에서 재구성 가능한 감사 추적이 필요하다고 요구했고, 이전의 가변 상태 설계가 1분기 감사를 통과하지 못했기 때문에 주문에 이벤트 소싱을 사용합니다"라는 문장은 논쟁을 종식시킵니다. 맥락은 선호도를 제약 조건으로 변환하는 요소이며, 기억에서 다시 꺼낼 때 가장 먼저 유실되는 부분입니다.
선택한 것뿐만 아니라 거부한 것도 기록하세요
대안당 두 줄씩 작성하세요. 무엇이었는지, 그리고 왜 안 되었는지입니다. 이 섹션은 가장 가치 있으면서도 가장 적게 작성되는 부분이며, 매 분기마다 동일한 제안이 다시 올라오는 것을 방지해 줍니다. 결정 사항 외에 다른 것을 쓰지 않더라도 이것만큼은 작성하세요.
모든 것에 날짜를 기입하고 대체된 결정도 유지하세요
각 결정에 날짜와 상태를 부여하고, 결정이 변경되면 이전 결정을 삭제하는 대신 새 결정을 추가하고 이전 결정을 '대체됨(superseded)'으로 표시하세요. 이전 결정을 삭제하면 그 결정 하에 작성된 코드를 이해할 수 없게 됩니다. 서로 충돌하는 날짜 없는 결정들은 특정 날짜 기준으로 솔직하게 표시된 하나의 결정보다 나쁩니다.
항상 로드되는 세트는 작게 유지하세요
모든 요청에 주입되는 내용은 단순한 스타일 문제를 넘어 답변을 완전히 틀리게 만들 수 있는 몇 가지 강력한 제약 조건이어야 합니다. 전체 기록은 검색(retrieval) 영역에 있어야 합니다. 모든 질문 앞에 아키텍처 역사의 장벽을 세워두면 정작 질문 자체가 묻히게 됩니다.
그럼에도 ADR은 커밋하세요
메모리 레이어가 있더라도 기록은 버전 관리 하에 리포지토리에 보관하세요. 저장소는 어시스턴트가 기록에 접근할 수 있게 해주고, 리포지토리는 팀이 이를 검토할 수 있게 해줍니다. 아무도 검토하지 않은 결정은 진정한 팀의 결정이 아닙니다. 각각의 장점에 맞게 두 가지를 모두 활용하세요.
결론
ChatGPT가 아키텍처 결정을 잊어버리는 이유는 제약 조건이 아닌 선호도를 유지하기 때문입니다. 읽을 수 있는 규칙 파일이 없고, 메모리는 매 요청마다 전달되는 한두 페이지에 불과하며, 현재의 메모리 시스템은 저장된 내용을 종합합니다. 따라서 결정에 구속력을 부여하는 절반인 '이유'가 바로 압축되어 사라집니다.
해결책은 오래된 조언에 새로운 단계 하나를 추가하는 것입니다. 결정을 ADR 형태(맥락, 결정, 거부된 대안, 결과, 날짜, 상태)로 작성하고 커밋하세요. 이것이 아키텍처 근거가 사람보다 오래 살아남는 방법이기 때문입니다. 그런 다음 어시스턴트가 매 요청마다 읽을 수 있는 곳에 기록을 두어, 붙여넣는 것을 기억해 낼 필요 없이 제약 조건과 그 이유가 함께 전달되도록 하세요. 그러면 7월에 했던 논쟁이 9월에도 여전히 해결된 상태로 유지될 것입니다.