ChatGPT가 테스트 케이스를 잊어버리는 이유
애초에 테스트 스위트를 가지고 있지 않았습니다
테스트 스위트는 수백 개의 케이스, 명명 규칙, 픽스처(fixtures), 태깅 규칙, 그리고 무엇이 테스트되고 무엇이 의도적으로 제외되었는지에 대한 암묵적인 맵을 포함하는 크고 구조화되며 진화하는 결과물입니다. 대화에 직접 입력하지 않는 한, 모델은 이러한 정보를 전혀 알 수 없습니다. 대신 여러분이 얻게 되는 것은 일반적인 모범 사례 기반의 테스트 스위트입니다. 이는 개별적으로 보면 합리적일 수 있지만, 여러분의 리포지토리에는 맞지 않습니다.
업로드된 파일은 채팅이 끝나면 사라집니다
테스트 스위트를 업로드하는 것은 해당 채팅 세션 내에서만 유효합니다. 대화가 유지되는 동안에는 콘텐츠를 사용할 수 있지만, 대화가 끝나면 사라집니다. 새 채팅은 해당 파일이 존재했는지조차 모른 채 시작됩니다. 이는 why ChatGPT forgets your uploaded files에서 설명한 것과 동일한 한계입니다. 매주 변경되는 테스트 스위트의 경우, 매번 다시 업로드하는 것은 번거로운 일일 뿐만 아니라 소리 없이 버전이 어긋나게 만듭니다. 실제로 최신 버전을 매번 다시 업로드하는 경우는 거의 없기 때문입니다.
내장 메모리는 테스트 범위가 아닌 선호도를 저장합니다
ChatGPT의 메모리는 사용자의 역할, 어조, 상시 지침 같은 것들을 기억하도록 설계되었습니다. 이는 분명 유용하지만, 태그, 담당자, 근거가 포함된 400개의 테스트 케이스를 인덱싱하는 용도가 아닙니다. ChatGPT에 테스트 커버리지 맵을 기억해 달라고 요청하는 것은 설계되지 않은 작업을 요구하는 것과 같으며, 그 실패는 조용히 일어납니다. 모델은 오래된 기억을 바탕으로 자신 있게 오답을 제시할 것입니다.
가장 가치 있는 QA 컨텍스트는 역사적 맥락입니다
가장 중요한 테스트는 무언가 고장 난 후에 작성된 테스트입니다. 이러한 테스트의 가치는 그 기원에 있습니다. 예를 들어, 프로덕션 환경에서 부분 환불이 이중 지급되었기 때문에 이 어설션(assertion)이 존재하고, 결제 게이트웨이가 30초 만에 소리 없이 타임아웃되었기 때문에 해당 재시도 테스트가 존재하는 식입니다. 이러한 역사는 오늘 아침에 새로 연 채팅창이 아니라, 장애 보고서, 티켓 스레드, 그리고 당시 당직 담당자의 기억 속에 남아 있습니다. 이와 관련된 실패 사례는 ChatGPT forgetting project context 및 테스트가 검증하려 했던 요구사항을 분실하는 현상으로 나타나며, 이는 ChatGPT forgetting product requirements에서 다루고 있습니다.
QA 팀들이 시도하는 방법들
거대한 프롬프트 템플릿
가장 일반적인 임시방편은 기술 스택, 규칙, 사용자 역할, 비즈니스 규칙이 담긴 재사용 가능한 블록을 모든 세션의 시작 부분에 붙여넣는 것입니다. 이 방법은 작동은 하지만 비용이 듭니다. 매 요청마다 토큰 비용을 지불해야 하고, 템플릿은 코드베이스와 동기화되지 않은 채 노후화되며, 명명 규칙이 변경된 스프린트 이후에는 아무도 이를 업데이트하지 않습니다.
매 세션마다 테스트 스위트 다시 업로드하기
템플릿보다 정확하지만 더 번거로우며, 업로드 용량 제한과 모델이 유용하게 읽을 수 있는 한계에 부딪힙니다. 또한 이는 잘못된 동기를 유발합니다. 번거롭기 때문에 사람들은 일부만 업로드하게 되고, 결국 모델은 보이지 않는 테스트 범위에 대해 추론하게 됩니다.
Custom GPTs 또는 전용 프로젝트
지침과 참조 파일을 한곳에 모아 팀과 공유하는 실질적인 개선책입니다. 하지만 여전히 수동으로 관리해야 하는 사일로(silo)입니다. 테스트 범위가 변경되어도 파일이 자동으로 업데이트되지 않으며, 구현 코드를 작성하는 코딩 에이전트나 릴리스를 요약하는 어시스턴트가 이 정보에 접근할 수 없습니다. 동일한 테스트 스위트에 대해 두 개의 진실의 원천(source of truth)이 생기는 순간 모순이 시작됩니다.
전체 사양서 붙여넣기
긴 컨텍스트 창 덕분에 이 방법이 매력적으로 보일 수 있습니다. 하지만 사양서(spec)는 의도를 설명할 뿐 실제 테스트 범위를 설명하지 않으며, 어떤 케이스가 이미 존재하는지에 대해서는 아무것도 말해주지 않습니다. 결국 중복된 테스트가 생성되고, 사람 역시 머릿속에 400개의 테스트 이름을 모두 담아둘 수 없기 때문에 이 중복 테스트들은 리뷰를 통과하게 됩니다.
해결책: ChatGPT에 영구적인 QA 메모리 제공하기
이러한 반복을 끝내는 패턴은 개별 채팅 외부의 메모리 레이어에 QA 컨텍스트를 유지하고, 모델이 이를 읽을 수 있도록 하는 것입니다. MemoryLake는 바로 이를 위해 설계되었습니다. 규칙, 커버리지 맵, 장애 이력을 한 번만 저장하면 어떤 어시스턴트나 에이전트든 작업을 수행할 때 이를 검색하여 활용할 수 있습니다.
1단계: API 키 생성하기
키를 생성하고 약 30초 만에 첫 번째 요청을 보낼 수 있습니다.

2단계: 첫 번째 메모리 업로드하기
팀의 테스트 방식을 정의하는 문서, 이미지, 파일을 업로드하세요. 명명 및 태깅 규칙, 커버리지 맵, 테스트 계획서, 인수 기준, 회귀 테스트를 유발한 버그의 사후 분석 보고서(post-mortem), 그리고 원인이 포함된 불안정한 테스트(flaky test) 목록 등이 포함됩니다.

3단계: AI 및 에이전트 연결하기
Claude, Codex, OpenClaw 및 기타 에이전트에 MCP 또는 API를 통해 해당 메모리에 대한 액세스 권한을 부여하세요. ChatGPT의 경우, API를 통해 관련 메모리를 검색하여 대화나 QA 도구에 주입할 수 있습니다. 이를 통해 모델은 일반적인 테스트 스위트가 아닌 실제 테스트 스위트에서 작업을 시작하게 됩니다. 핵심은 모든 도구가 동일한 소스를 읽는다는 점입니다. 코드를 작성하는 에이전트와 테스트를 작성하는 어시스턴트가 무엇이 존재하는지에 대해 서로 다른 의견을 내는 일이 없어집니다.

실제 업무에서 달라지는 점
반복 작업에 드는 비용을 직접 계산해 보세요. QA 엔지니어가 일주일에 10번, 세션 시작 시 모델에 5분 동안 다시 브리핑을 한다면, 이는 한 사람당 매주 거의 한 시간을 변하지 않은 사실을 다시 설명하는 데 낭비하는 셈입니다. 상시 컨텍스트 블록이 2,500 토큰이고 팀 전체에서 하루에 30번 전송된다면, 하루에 75,000 토큰, 한 달에 약 220만 토큰을 단지 같은 말을 반복하는 데 지불하는 것입니다.
청구서에 표시되지 않는 비용은 더 큽니다. 테스트 스위트 실행 시간을 늘리는 중복 케이스, 모델이 무엇이 누락되었는지 몰라 아무도 눈치채지 못하는 커버리지 공백, 그리고 작성 이유가 기록되지 않아 소리 없이 다시 논쟁의 대상이 되는 회귀 테스트 등이 있습니다. 메모리가 모델을 더 뛰어난 테스트 설계자로 만들어주지는 않습니다. 하지만 여러분의 테스트 스위트를 제대로 알고 있는 테스트 설계자로 만들어줍니다.
QA 메모리 구축을 위한 모범 사례
모든 어설션이 아닌 테스트 스위트의 구조를 저장하세요
메모리에 400개의 테스트 본문을 모두 담을 필요는 없습니다. 필요한 것은 맵입니다. 모듈과 해당 커버리지 수준, 명명 및 태깅 규칙, 의도적으로 테스트하지 않은 부분, 신뢰할 수 있는 스위트와 불안정한 스위트가 무엇인지 등이 이에 해당합니다. 이는 한두 페이지 분량에 불과하며, 바로 모델에 결여되어 있는 정보입니다.
각 회귀 테스트가 존재하는 이유를 기록하세요
장애로 인해 생성된 테스트마다 증상, 근본 원인, 날짜를 한 줄로 기록해 두세요. 이는 저장해야 할 가장 가치 있는 정보입니다. 사람이 퇴사할 때 함께 사라지는 지식이며, 6개월 후에 '불필요해 보이는' 테스트가 삭제되는 것을 방지해 주기 때문입니다.
테스트 범위와 동일한 풀 리퀘스트(PR)에서 메모리를 업데이트하세요
메모리 업데이트를 별도의 작업으로 분리하면 메모리는 노후화됩니다. 변경 사항과 연동하세요. 규칙이 바뀌거나 테스트 스위트가 폐기될 때, 동일한 PR에서 저장된 사실을 업데이트해야 합니다. 새로운 내용을 추가하기보다는 오래된 내용을 교체하는 방식을 권장합니다. 오래된 QA 컨텍스트는 없는 것보다 나쁩니다. 모델과 사람 모두 그것을 신뢰하기 때문입니다. 이 습관은 일반화될 수 있으며, not re-explaining context to your AI의 핵심 원칙과도 일치합니다.
결론
ChatGPT가 테스트 케이스를 잊어버리는 이유는 애초에 이를 기억하고 있지 않았기 때문입니다. ChatGPT는 테스트 스위트에 대한 시야가 없고, 업로드된 파일은 채팅이 끝나면 사라지며, 내장 메모리는 커버리지 맵이 아닌 선호도를 저장합니다. 더 나은 프롬프트를 작성한다고 해서 이 사실이 바뀌지는 않습니다. 단지 재브리핑 과정만 길어질 뿐입니다.
테스트 스위트의 구조, 규칙, 장애 이력을 도구가 읽을 수 있는 메모리 레이어에 넣어두세요. 그러면 모델의 결과물은 '그럴듯한 수준'에서 '바로 사용할 수 있는 수준'으로 바뀝니다. 여러분의 명명 스타일에 맞고, 실제로 테스트되지 않은 부분을 겨냥하며, 팀이 이미 대가를 치르고 해결한 버그들을 고려한 케이스가 생성될 것입니다. 이는 단 한 번만 제대로 기록해 둘 만한 가치가 있습니다.