AI가 계속 잊어버릴 때: LLM 워크플로가 붕괴되는 이유와 대신 구축해야 할 것

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line, formatting, markdown, and any code blocks exactly as they are.

문제

나는 career‑intelligence 프로젝트를 ChatGPT와 Claude를 활용해 6개월째 진행하고 있었는데, 점점 퇴화되는 것을 눈치챘다. 내가 정확히 정의해 둔 용어들이 흔들리기 시작했다 — “Career Intelligence Framework” 가 어느 세션에서는 “Career Intel System” 으로, 또 다른 세션에서는 “CI Framework” 로 변했다. 몇 주 전에 내렸던 결정들이 다시 열린 질문으로 떠올랐다. 개념을 설명하고 좋은 결과물을 얻었지만, 세션을 세 번 넘긴 뒤에는 우리가 그때 합의했던 대화를 모델이 기억하지 못해 다시 설명해야 했다. 참조도 모호해졌다 — “update the ontology” 라는 말이 세션에 따라 세 개의 다른 파일을 의미할 수 있었다.

뭔가 설정이 잘못된 것이 아닐까 생각했지만, 그렇지 않았다. ChatGPT는 토큰 윈도우, 메모리 제한, 그리고 LLM 구조 때문에 용어 추적을 잃어버린다. 이런 용어의 변동은 보고할 버그가 아니라, 시스템이 작동하는 기본적인 결과이다 — 안정적인 저장소에서 정보를 꺼내는 것이 아니라 패턴을 기반으로 언어를 재생성하기 때문이다. 모든 응답은 새롭게 재구성된 것이지, 기억을 불러오는 것이 아니다. 컨텍스트를 고정시켜 줄 스캐폴딩이 없으면 장기 프로젝트는 점점 침식된다.

그 침식은 형태를 가지고 있었다. 나는 그것을 정리하기 시작했다.

왜 깨지는가

실패 모드가 무작위가 아니었습니다. 모든 프로젝트 스레드, 모든 모델, 모든 세션 길이에서 반복되는 일곱 가지 범주로 나뉘었습니다. 저는 이를 C1–C7이라고 명명했으며, collapse‑risk taxonomy라고 부릅니다. 정확히 이름을 붙이는 것이 대책을 설계하는 첫 번째 단계였기 때문입니다.

이러한 위험은 상호 의존적입니다. 어휘 드리프트(C3)는 참조 모호성(C4)을 만들고, 컨텍스트 포화(C1)는 지시 희석(C2)을 가속화합니다. 스레드 단편화(C7)는 단일 세션에 전체 그림이 없기 때문에 모든 위험을 증폭시킵니다.

내가 시도한 방법

첫 번째 직관은 포괄적이었습니다: 모든 붕괴 위험을 특정 대응책에 매핑하는 하네스라는 전체 스캐폴딩 시스템을 설계하는 것이었습니다.

1. Ontology.yml (anti‑C3)

목적: 어휘 안정성.
내용: 개념당 하나의 정규 용어, 승인된 동의어, 고유 ID.
도움이 되는 방식: 모델이 “Career Intelligence Framework”에서 “Career Intel System”으로 흐트러질 때, 온톨로지가 권위가 됩니다. 이론적으로 린터가 풀 리퀘스트에서 흐트러짐을 잡아 코드베이스에 들어가기 전에 차단할 수 있습니다.

2. Context Packs (anti‑C1 & anti‑C2)

목적: 세션 재주입.
구조:

purpose: "Update the career‑intel data model"
glossary_slice: ["Career Intelligence Framework", "CI Framework"]
current_milestone: "v0.3 – data ingestion"
active_constraints:
  - token_limit: 8192
  - no_new_dependencies
open_questions:
  - "How to version the ontology?"

도움이 되는 방식: 전체 프로젝트를 컨텍스트 창에 덤프하는 대신, 컴팩트한 번들이 모델에게 이번 세션에 필요한 것만 정확히 제공하고 그 외는 배제합니다.

3. Decision Log (anti‑C4 & anti‑C5)

목적: 근거 추적.

**Decision**: Adopt GraphQL for the API layer  
**Why**: Enables flexible client queries and reduces over‑fetching.  
**Alternatives**: REST (rejected – higher latency), gRPC (rejected – steeper learning curve)  
**Reversible**: Yes – abstraction layer isolates GraphQL specifics.  
**Impacted artifacts**: api/schema.graphql, docs/api.md

도움이 되는 방식: 참조가 모호하지 않게 유지되고, 범위 변경이 조용히 일어나지 않고 명시적으로 드러납니다.

4. Checkpoints (anti‑C6)

목적: 고정된 상태.
구현: 알려진 좋은 시점에 저장소를 캡처하는 Git 태그/릴리즈(v0.3‑ontology‑stable 등).
도움이 되는 방식: 출처를 위한 안정적인 기준점을 제공합니다.

5. Chronicle (anti‑C7)

목적: 파편화된 스레드 간 연속성.
형식: 대화, 결정, 코드 변경을 하나의 일관된 역사로 엮는 서술형 타임라인.
도움이 되는 방식: 작업이 세션과 모델을 가로질러 분할될 때, 연대기는 이를 연결하는 단일 스레드가 됩니다.

매핑은 깔끔했습니다: 각 구성 요소가 특정 붕괴 위험을 목표로 했고, 각 붕괴 위험마다 최소 하나의 대응책이 있었습니다.

Source: …

긴장감

전체 Harness 접근 방식을 더 단순한 Stage B와 비교했을 때 설계상의 긴장이 발생했습니다 — GitHub 기반 아키텍처로, 명확한 저장소 구조, 프론트‑머터 규칙, 수동적인 규율을 갖지만 자동화 레이어는 없습니다.

ChatGPT의 평가는 직설적이었습니다: Harness는 복잡성 오버헤드와 유지비용을 가져오고, Stage B는 마찰이 적지만 붕괴 위험을 크게 확인하지 못한다는 것이었습니다.

핵심 요점

• 일곱 가지 붕괴 위험(C1‑C7)을 식별한다.
• 프로젝트 장기성과 오버헤드 사이의 균형을 맞추는 완화 전략을 선택한다.
• 다수의 세션과 협업자를 포함한 장기 안정성이 필요하다면 Harness‑스타일 스캐폴딩에 투자한다.
• 프로젝트가 단기이거나 규율 있는 팀이라면 가벼운 Stage B 접근이 충분할 수 있다.

어느 쪽이든, 위험을 명시적으로 인식하는 것이 LLM‑보강 프로젝트가 조용히 무너지지 않도록 하는 첫 번째 단계입니다.

엔트로피 위험에 대한 인용; 수동 검증에 의존.

위험은 면역 체계가 보호하도록 설계된 작업보다 면역 체계 자체를 유지하는 데 더 많은 시간을 소비하는 스캐폴딩을 구축하는 것이었습니다.

밝혀진 내용

Harness 설계는 내가 계속 되돌아가게 만든 원칙을 드러냈다: 뼈대는 엔진이 아니라 서보다. 서보는 시스템을 바로 세워 주고, 엔진은 실제 작업을 수행한다. 서보가 작업이 되어 버리면—즉, 프로젝트가 존재하는 이유인 연구와 글쓰기 대신 온톨로지 유지보수와 컨텍스트 팩 생성에 세션을 소비하게 되면—잘못된 것을 만든 것이다.

더 깊은 통찰은 붕괴는 실패 상태가 아니라 기본 상태라는 점이었다.

• LLM은 기억을 갖고 있지 않다—패턴 재생성만 할 뿐이다.
• 그들은 당신의 용어를 검색하지 않는다; 근사치를 재구성한다.
• 그들은 당신의 결정을 기억하지 않는다; 현재 창에 있는 내용으로부터 추론한다.
• 그들은 프로젝트 상태를 유지하지 않는다; 영원히 현재에 머문다.

현재 컨텍스트 창 밖의 모든 것은 사실상 사라진 것이며, 다시 주입해야 할 경우 주입은 항상 손실이 있다—요약은 뉘앙스를 없애고, 컨텍스트 팩은 이유를 압축하고, 세션 전달은 질감을 잃는다.

붕괴를 예외가 아니라 기준으로 이해하게 되면 설계 질문이 바뀐다. **“붕괴를 어떻게 방지할까?”가 아니라—현재 아키텍처로는 완전히 방지할 수 없으니—“어디에 뼈대를 고정시켜야 하고, 어디를 유연하게 할 수 있을까?”**가 된다.

• 장기 프로젝트에서는 어휘 안정성이 중요하다—용어가 흐트러지면 모호함이 누적된다.
• 결정의 출처는 몇 달 후에 선택을 다시 검토할 때 중요하다.
• 세션 연속성은 일회성 분석보다는 몇 주에 걸친 반복 개발에서 더 중요하다.

나타난 뼈대 스펙트럼

1. 레포지토리 구조 및 명명 규칙 – 비용이 들지 않으며 가장 흔한 실패를 방지한다.
2. 온톨로지 – 어휘 흐트러짐이 눈에 띄게 될 때 추가한다.
3. 컨텍스트 팩 – 세션 재진입에 드는 시간이 작업 자체보다 많아질 때 추가한다.
4. 자동화 – 수동적인 규율이 부하에 못 미칠 때 추가한다.

첫 날에 전체 Harness를 구축하지 마라. 현재 직면하고 있는 붕괴 위험을 해결하는 부분만 구축하라.

재사용 가능한 규칙

LLM을 이용해 장기 프로젝트(몇 번의 세션을 넘어서는 모든 작업)를 진행하고 있다면, 모델은 흐름을 놓치게 됩니다. 모델이 고장 난 것이 아니라 메모리가 없기 때문입니다. 모델은 한정된 컨텍스트 윈도우 안에서 패턴을 재생성하며 동작하고, 그 윈도우 밖의 모든 내용은 사라집니다.

진단 신호

• 이미 모델이 다뤘던 개념을 다시 설명할 때 → 컨텍스트 포화 또는 어휘 변동.
• 모델이 이미 거부한 제안을 다시 제시할 때 → 엔트로피의 증거.
• 용어의 정식 버전에 대한 불확실성이 있을 때 → 어휘 변동이 누적되어 참조 모호성으로 이어짐.
• 대화가 원래 목표에서 인접한 주제로 조용히 전환될 때 → 목표 크리프.

실패를 명명하십시오. C1–C7 분류 체계가 절대적인 것은 아니므로—재명명, 확장, 혹은 통합해도 좋습니다—실제로 무너지는 부분을 카탈로그화하여 구체적인 대책을 설계할 수 있게 하세요.

스캐폴딩 원칙

• 특정 붕괴 위험이 나타날 때만 구성 요소를 추가하고, 그 이전에 추가하지 마십시오.
• 각 인프라스트럭처 조각을 방지하려는 실패와 매핑하십시오.
• 명시된 실패를 방지하지 못한다면, 그것은 아마도 메타 작업일 가능성이 높습니다.

그리고 서보 원칙을 기억하십시오: 스캐폴딩은 붕괴를 방지하여 실제 작업을 할 수 있게 하는 것이 목적입니다. 스캐폴딩 자체가 작업이 되는 순간, 잘못된 것을 만든 것입니다.