grep

Engineering

늙어버린 당신의 AI

Ashe여기어때

2026년 7월 31일

원문에서 보기 ↗

글. 김의석(Ashe) / 주문결제개발팀

새로운 모델이 나올 때 꼭 확인해야하는 것

안녕하세요. 여기어때컴퍼니 주문결제개발팀 애쉬입니다.

새 모델이 나오면 우리는 어렵지 않게 갈아탑니다. 설정에서 모델 이름 하나만 바꾸면 되니까요. 그런데 이런 순간이 있지 않으셨나요 — 분명 더 좋은 모델로 바꿨는데, 어딘가 예전 버릇이 남아 있는 것 같은 순간이요. 그럴 만한 이유가 있습니다. AI는 모델만으로 움직이지 않기 때문입니다. 시스템 프롬프트, 설정 튜닝값, 지침 문서, 세션이 쌓아온 메모리 — 이 자산들은 모델을 갈아탄다고 함께 갈아타지지 않습니다. 작성되던 시점의 구세대에 맞춰진 채 그대로 남습니다. 부품이 낡으면, 전체는 늙습니다. 모델이 아무리 새것이어도요.

2026년 7월, Claude 5가 나온 날 저희 팀 전체에 배포되던 AI 설정 파일에서 두 줄을 지웠습니다. 이 글은 그 두 줄을 찾아낸 감사(audit)의 기록이자, “새로운 모델이 나올 때 무엇을 확인해야 하는가”에 대한 저희 나름의 답안입니다. AI 도구를 팀으로든 혼자서든 쓰고 계시다면 도움이 될 이야기라 생각합니다.

이 글의 기준 시점

주제가 주제인 만큼 이 글에도 기준 시점을 박아둡니다. 이 글의 판단 역시 이 시점의 공식 문서 기준이고, 다음 세대가 나오면 똑같이 늙습니다 — 그게 이 글의 요지이기도 합니다.

AI는 늙어도 아프다고 말하지 않습니다

먼저 서두의 그 “두 줄”부터 말씀드리면, 한 줄은 신모델이 아예 무시하는 값이었고, 다른 한 줄은 일부 사용자의 모델 기본값을 몰래 한 단계 낮추고 있던 값이었습니다. 그런데 두 값 모두 도입 이후 여러 달 동안 단 한 번도 문제를 일으키지 않았습니다 — 정확히 말하면, 문제를 일으키지 않는 것처럼 보였습니다.

AI 위에 쌓은 자산은 작성 시점의 모델 세대를 전제로 만들어집니다. 얼마나 장황하게 답하는지, thinking을 어떻게 쓰는지, 어떤 지시에 민감한지 — 전부 그 세대의 성향에 맞춘 튜닝입니다. 문제는 모델이 바뀌어도 이 자산들이 어떤 오류도 내지 않는다는 점입니다.

AI의 노화는 침묵합니다. 코드는 전제가 깨지면 컴파일 에러나 테스트 실패로 알려주지만, 프롬프트와 설정은 낡아도 그냥 조용히 적용됩니다. 문제를 일으키는 게 아니라 손해를 누적시키기 때문에, 재검토 트리거가 없으면 영원히 발견되지 않습니다.

낡는 방식은 두 갈래로 나뉩니다. 모델명이나 가격이 박혀 있는 명시 의존은 grep 한 번으로 찾을 수 있으니 그나마 낫습니다. 위험한 쪽은 암묵 의존 — “이 모델은 말이 많으니 짧게 답하게 하자” 같은, 특정 세대의 성향에 대응해 넣은 값과 문구입니다. 파일 어디에도 “모델 X 기준”이라고 적혀 있지 않아서, 세대가 바뀌어도 아무도 재검토를 떠올리지 못합니다.

벤더가 먼저 말하고 있습니다 — “프롬프트를 다시 점검하라”

이것이 한 팀의 유난이 아니라는 근거는 벤더 공식 문서에서 바로 나옵니다.

Anthropic 은 모델 세대가 바뀔 때마다 마이그레이션 가이드를 발행하는데, API 변경뿐 아니라 프롬프트 재검토 항목을 명시합니다. 대표 대목이 이렇습니다 — “Opus 5는 지시하지 않아도 스스로 작업을 검증하므로, 이전 모델에 맞춰 넣어둔 명시적 자기검증 지시를 제거하라. 남겨두면 과잉 검증을 유발한다.”

OpenAI 쪽에는 한 세대의 모범 기법이 다음 세대의 안티패턴이 된 유명한 사례가 있습니다. 구세대 프롬프트 엔지니어링의 대표 기법이던 “단계별로 생각하라”(chain-of-thought 강제)는 reasoning 모델 가이드에서 “내부적으로 추론을 수행하므로 불필요하며, 때로는 성능을 저해할 수 있다”로 뒤집혔습니다. 최신 세대에서도 반복됩니다 — GPT-5.x 가이드는 “‘Be concise’ 같은 간결성 지시가 여전히 유용한지 점검하라. 응답을 과도하게 짧게 만들 수 있다”고 경고합니다.

명시적 세대 교체가 없어도 문제는 생깁니다. Stanford·UC Berkeley 연구진은 같은 이름의 GPT-4가 3개월 사이 소수 판별 정확도 84%에서 51%로 변한 것을 실측하고, 같은 LLM 서비스라도 지속적 모니터링이 필요하다고 결론지었습니다. 프롬프트·모델 조합을 테스트로 묶어 교체 전에 회귀를 잡는 promptfoo 같은 도구가 CI에 통합되는 수준으로 자리잡은 배경입니다.

요컨대 “모델 위에 쌓은 자산은 주기적 재검증 대상”이라는 전제는 이미 업계 합의에 가깝습니다. 벤더가 세대마다 “이 지시를 지워라”를 문서로 내는데, 그 문서를 자기 자산에 적용하는 절차를 갖춘 팀은 드뭅니다. 이번 감사는 그 간극을 메우는 작업이었습니다.

사례 ① — 팀 설정 파일에서 나온 두 줄

Claude 5 출시를 트리거 삼아 중앙 저장소 전체를 감사했습니다. 서두에 말씀드린 두 줄이 팀 전체에 배포되는 Claude Code 설정 파일(settings.json)에서 나왔습니다. 둘 다 저장소 초기 구성(Opus 4.x 초기 세대) 때 들어간 뒤 한 번도 재검증된 적이 없었습니다 — 말하자면 두 세대 전의 처방전을 계속 복용하고 있던 셈입니다.

첫 번째 줄 — CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1

두 번째 줄 — effortLevel: "high"

한 값은 신모델에게 무효이면서 구모델에게 역효과였고, 다른 값은 기본값을 억누르는 부작용만 내고 있었던 셈입니다. 어느 쪽도 에러 한 줄 내지 않았다는 점이 핵심입니다 — 전자는 비용과 속도로, 후자는 일부 사용자의 출력 품질로, 손해가 조용히 분산 청구되고 있었습니다.

설정만이 아닙니다. 매 세션 자동 주입되는 행동 규약 문서에서도 세대 마찰이 나왔습니다. “생각 과정을 숨기라”는 문구는 구세대 모델이 응답 본문에 사고 과정을 늘어놓던 성향을 막으려던 것인데, thinking이 별도 채널로 분리된 신세대에서는 자칫 “추론 자체를 줄여라”로 읽혀 품질을 깎는 방향으로 작용할 수 있습니다. 앞에서 본 GPT-5.x의 “간결성 지시가 과도 압축을 유발한다”는 경고와 정확히 같은 축의 사례가 저희 문서에도 있었던 것입니다. 문구를 “응답 본문에 추론 과정을 다시 풀어 쓰지 마라(내부 thinking은 대상이 아니다)”로 정밀화해 오독 여지를 닫았습니다.

감사 내내 지킨 원칙이 하나 있습니다. 설정·환경변수의 유효성 판단은 벤더 공식 문서 대조로만 하고, 기억이나 추측으로 하지 않는다. “이 값이 아직 유효했던 것 같은데”라는 기억 자체가 구세대에 형성된 자산이기 때문입니다. 위 결론이 전부 문서 근거를 갖는 이유입니다.

사례 ② — 기억도 늙습니다

설정이 모델 세대에 묶여 낡는다면, 세션이 축적하는 에이전트 메모리는 사실의 시점에 묶여 늙습니다. “그때 참이었던 것”이 지금도 참이라고 재주장되는 쪽이 주 위험입니다. 이번 감사에서 양방향 실증이 다 나왔습니다.

업계에서도 메모리 staleness를 시간 정보로 다루는 시도가 나오는 중입니다 — Zep은 사실마다 유효기간을 두고 모순되는 새 사실이 오면 구사실을 무효화하는 구조로 장기 메모리 벤치마크 정확도를 최대 18.5% 끌어올렸습니다. 다만 “구모델 시절 축적한 메모리·설정이 신모델에서 여전히 유효한가”라는 조합을 정면으로 다룬 표준 관행은 아직 희박합니다. 아래에 나올 경량 검진이 그 공백에 대한 저희 나름의 답안입니다.

노화는 막을 수 없으니, 검진을 정기화했습니다

노화 자체는 막을 수 없습니다 — 모델은 앞으로도 계속 나올 테니까요. 막을 수 있는 것은 “모르고 늙는 것”입니다. 일회성 대청소로 끝내면 다음 세대 전환 때 같은 조사를 처음부터 반복하게 되기에, 이번 감사 결과를 초판 데이터로 삼아 정기 검진 장치를 세 겹 만들었습니다. 요지만 적겠습니다.

첫째, 모델 진화 runbook. “이 저장소의 정책·튜닝은 어느 모델 세대에서 검증됐는가”를 적는 기준선 (현재: Claude 5 패밀리), 모델 세대 가정을 가진 파일을 명시 의존·암묵 의존·비의존 확인 세 등급으로 열거한 의존 자산 목록 , 그리고 신모델이 나왔을 때 밟는 감사 절차를 한 문서에 담았습니다. 다음 전환부터 재검토는 막막한 탐색이 아니라 목록 순회가 됩니다.

세대 전환 감사 루프. 신모델 GA → grep 스윕 → 목록 순회·공식 문서 대조 → 변경 있으면 기록·리뷰·배포, 없으면 기준선 갱신

둘째, 동기 불변식. 모델 세대 가정을 가진 파일을 만들거나 고치면 같은 커밋에서 runbook 목록에 행을 추가해야 하고, 팀 배포물이라면 변경 이력에 “어느 세대 기준인지”를 남깁니다. 목록이 처음 한 번만 정확하고 이후 현실과 어긋나는 것을 막는 장치입니다.

셋째, 리뷰 단계의 상기. “모델 의존 여부”는 기계적으로 판별할 수 없어 커밋을 자동 차단하는 린트로는 만들 수 없습니다. 대신 리뷰에서 변경 세트에 thinking·effort·모델명 같은 튜닝이 보이면 목록 동기 여부를 점검 항목으로 올립니다. 이 한계는 감추기보다 명시해 두는 편이 낫습니다 — 목록 등재가 빠진 파일은 여전히 사각지대이고, 그래서 최종 방어선은 어디까지나 세대 전환 때의 전체 감사입니다.

그리고 이 모든 장치보다 앞서는 상시 원칙이 하나 있습니다.

가장 싼 검진은 검진할 것을 만들지 않는 것입니다. 팀 배포물에 모델명을 하드코딩하지 않고, 서브에이전트를 띄울 때 모델을 고정하지 않으며(세션 모델 상속), 튜닝값은 공식 기본값으로 충분한지 먼저 의심합니다. 실제로 튜닝값 0이 된 저희 설정 파일은 이제 신모델의 공식 기본값을 자동 승계합니다 — “새 모델이 나왔으니 설정을 바꾸자”가 아니라 “바꿀 설정이 없게 만들자” 쪽이 세대 전환 작업량을 구조적으로 줄여줍니다.

당신의 AI를 위한 3분 검진

팀 저장소가 없어도 문제는 같습니다. 각자의 머신에는 AI가 읽는 자산이 세 층 있습니다 — 개인 글로벌 설정, 지침 파일(CLAUDE.md 류), 세션이 축적하는 메모리. 이쪽은 배포 채널도 변경 이력도 리뷰어도 없어서 조건이 중앙보다 오히려 나쁩니다. 다행히 개인 레벨에는 runbook 같은 무거운 장치까지는 필요 없습니다. 검진 세 가지면 충분합니다.

1. 설정과 지침은 한 문장으로 검진합니다 — 찾을 것은 두 가지입니다. 특정 모델을 고정해 둔 모델 핀 (다음 세대가 나왔을 때 손으로 갱신해야 하는 지점), 그리고 구세대 지시 문구 — 앞에서 벤더가 “지우라”고 한 바로 그 지시들입니다. “단계별로 생각해라”(reasoning 모델에서는 불필요·저해), “짧게 답해라”(과도 압축 위험), “끝나면 스스로 검증해라”(과잉 검증 유발). 하나하나가 도입 당시에는 모범 기법이었다는 점이 함정입니다. 직접 파일을 뒤질 필요는 없습니다 — 세션에 이 한 문장이면 됩니다.

내 개인 설정(~/.claude/settings.json)과 CLAUDE.md를 읽고, 특정 모델에 고정된 값이나
구세대 모델 기준의 지시 문구가 있으면 찾아서, 지금 모델 세대에서도 유효한지
공식 문서 기준으로 알려줘

2. 메모리 감사는 세션에게 시킵니다 — “내 메모리에서 낡았거나 서로 모순인 팩트를 찾아줘” 한 문장이면 AI가 수행합니다. 틀린 기억은 지우기보다 정정 마커로 교체하는 편이 낫습니다 — 같은 오판이 재발하려 할 때 마커가 방어선이 되기 때문입니다.

3. 트리거는 밖에서 빌립니다 — 신모델 출시를 각자 기억할 필요는 없습니다. 벤더의 마이그레이션 가이드 발행, 신모델 GA 소식, 소속 팀의 감사 공지를 “내 AI도 검진할 때”라는 신호로 쓰면 됩니다.

맺으며 — 모르고 늙게 두지는 맙시다

이번 감사가 실제로 사준 것을 세 줄로 요약하면 이렇습니다. 에러 한 줄 없이 손해를 누적시키던 값 두 개를 찾아 제거했고, 다음 세대 전환의 재검토를 탐색이 아닌 목록 순회로 바꿔놨으며, 애초에 검진할 것이 줄어드는 방향(튜닝값 0)으로 자산을 재설계했습니다.

돌아와서 — 새로운 모델이 나올 때 꼭 확인해야 하는 것은 결국 세 가지입니다. 설정과 지침은 한 문장 검진으로, 기억은 메모리 감사로, 그리고 그 확인 자체를 다음에도 반복되는 절차로. 벤더는 이미 세대마다 “이 지시를 지워라, 이 기법은 이제 해롭다”를 공식 문서로 내고 있으니, 남은 것은 그 문서를 자기 자산에 적용하는 습관뿐입니다. 시작은 거창하지 않습니다 — 오늘 세션에 검진 한 문장을 던져보는 것입니다. 저희가 찾은 두 줄 같은 것이, 아마 거기에도 있을 겁니다.

AI는 늙습니다. 하지만 모르고 늙게 둘 이유는 없습니다. 저와 비슷한 고민을 하는 팀과 개인에게 도움이 되었길 바랍니다. 🥰

references

Anthropic, Model migration guide, https://platform.claude.com/docs/en/about-claude/models/migration-guide.md, 2026.07.30

OpenAI, Reasoning best practices, https://developers.openai.com/api/docs/guides/reasoning-best-practices, 2026.07.30

OpenAI, GPT-5.x prompting guidance, https://developers.openai.com/api/docs/guides/prompt-guidance, 2026.07.30

Lingjiao Chen, Matei Zaharia, James Zou, How Is ChatGPT’s Behavior Changing over Time?, https://arxiv.org/abs/2307.09009, 2026.07.30

promptfoo, Getting started, https://www.promptfoo.dev/docs/intro/, 2026.07.30

Preston Rasmussen et al., Zep: A Temporal Knowledge Graph Architecture for Agent Memory, https://arxiv.org/abs/2501.13956, 2026.07.30