# AI+Solo 개발의 Pain Points와 필요한 도구

> Being 프로젝트 개발 경험(2026-01~02)에서 관찰된 구조적 마찰을 패턴화.
> 각 문제에 대해 "어떤 도구가 있었으면 해결됐을까"를 구체적으로 기술.
>
> 소스: codebase-friction, cowork-ideas, dev-tooling-ideas, dev-automation v1/v2, hastlow-design

---

## 읽는 법

각 항목은 다음 구조:

```
## P{N}: 패턴 이름
- 증상: 개발 중 체감하는 문제
- 근본 원인: 왜 이런 일이 반복되는가
- 실제 사례: Being 개발에서의 구체적 경험
- 필요한 도구: 이 문제를 해결할 수 있는 도구/메커니즘
- 난이도/효과: 구현 비용 vs 체감 개선
```

---

## Part 1: 세션 연속성 — "매번 백지에서 시작하는 AI"

### P1: 세션 부팅 비용

**증상**: 새 대화를 시작할 때마다 첫 2-3턴을 "어디까지 했더라" 파악에 소비한다. MEMORY.md를 읽고, 관련 파일을 찾고, 현재 상태를 재구성하는 데 전체 세션의 15-20%를 쓴다.

**근본 원인**: AI 코딩 에이전트는 세션이 상태를 갖지 않는다. 사람은 어제 뭘 했는지 기억하지만, AI는 매번 파일을 열어봐야 안다. MEMORY.md가 있지만 200줄 한계로 점점 압축해야 하고, 압축하면 맥락이 손실된다.

**실제 사례**: Being M3에서 하루에 7개 피처(F1~F3, Chat통합, AgentExecutor, EmbedderRouter, Infrastructure)를 구현했다. 다음 날 세션에서 이 7개의 관계를 파악하려면 MEMORY.md 요약만으론 부족하고, 실제 코드를 읽어야 했다. 7개를 다 읽을 순 없으니 "골라 읽기"를 하는데, 그 선택 자체가 인지 비용이다.

**필요한 도구**: **세션 핸드오프 시스템**
- 세션 종료 시 구조화된 핸드오프 노트 자동 생성
- 필수 섹션: Done, Key Decisions, Changed Files, Next, Context Files
- 다음 세션 시작 시 마지막 핸드오프 하나만 읽으면 즉시 맥락 파악
- MEMORY.md(전술적 기억)와 보완 관계 — 핸드오프는 "이번 세션 바로 다음"에 초점

**난이도**: 낮음 (스킬 하나) | **효과**: 즉시 체감 — 부팅 시간 2-3턴 → 0-1턴

---

### P2: 프로젝트 상태의 다중 진실 소스

**증상**: "지금 프로젝트가 어디에 있는지"를 사람과 AI가 다른 소스에서 읽는다. 사람은 머릿속 + Roadmap, AI는 MEMORY.md + git log. 둘이 같은 상황을 다르게 이해하고 있어서 방향 불일치가 생긴다.

**근본 원인**: 목표(무엇을), 진행 상태(어디까지), 작업 기록(뭘 했는지)이 각각 다른 파일에 흩어져 있다.
- `docs/CURRENT_TASKS.md`: 수동 업데이트, 금방 stale
- `docs/01_ROADMAP.md`: 큰 그림은 있지만 현재 진행과 연결 약함
- `MEMORY.md`: AI는 읽지만 사람이 보기엔 불편
- git log: 실제 작업 기록이지만 목표와 연결되지 않음

**실제 사례**: "M4.4 acceptance test 해줘"라는 요청에 AI가 바로 뛰어들었지만, MindLoop이 실제로 돌아야 하는지, mock으로 충분한지, Redis/Qdrant 연결이 필수인지 확인하지 않아서 삽질이 발생했다.

**필요한 도구**: **Git-Anchored 프로젝트 상태 레저**
- `goals.yaml`: 계층적 목표 정의 (M4 → M4.3 → M4.3.1)
- `hastlow status`: 터미널에서 프로젝트 트리 + 진행률 한눈에 표시
- 커밋 컨벤션: `feat(M4.3): description` — git log로 목표별 히스토리 추출 가능
- AI가 매 세션 시작 시 goals.yaml을 읽어 방향을 잡음

**난이도**: 중간 (CLI 도구) | **효과**: 높음 — 사람-AI 동기화 문제 근본 해결

---

### P3: 큰 작업의 "중간 상태" 전달 실패

**증상**: 한 세션에서 여러 피처를 구현한 뒤, 다음 세션에서 각 피처의 연결 관계를 재구성하기 어렵다. "다 했어"라고 했지만, 뭘 다 했는지 검증할 방법이 테스트 실행 + 코드 직접 읽기뿐이다.

**근본 원인**: 한 세션 = 한 피처라는 리듬이 없으면, 세션 산출물이 너무 커서 전달이 불가능해진다. 7개 피처를 한 세션에 넣으면, 핸드오프 노트도 거대해지고, 다음 세션이 소화하지 못한다.

**실제 사례**: M3 하루 7피처 세션 후, 다음 세션이 이 7개를 이해하려면 MEMORY.md의 각 피처별 10-15줄 요약(총 100줄)을 읽어야 했다. 요약만으로 부족해서 코드를 또 읽으면 인지 비용이 배가됐다.

**필요한 도구**: **작업 크기 제한 + 중간 커밋 규칙**
- 한 세션 = 하나의 의미 있는 피처 단위(구현 + 테스트 + 검증 완료)
- 여러 피처 요청 시 각 피처 사이에 중간 커밋
- 세션 경과 시간 경고 (60분 초과 시 알림)
- 변경 파일 수 힌트 (10개 초과 시 쪼개라 제안)

**난이도**: 프로세스 변경(비용 0) | **효과**: 즉시 체감 — 검증 가능한 크기 유지

---

## Part 2: 코드베이스 가시성 — "매번 전체를 읽어야 하는 AI"

### P4: 수정 영향 범위 파악의 높은 비용

**증상**: "이 함수를 수정하면 어디에 영향이 가는가?"를 파악하려면 Grep/find_referencing_symbols로 하나씩 추적하고, 결과를 컨텍스트에서 조합해야 한다. 깊이가 깊어지면 컨텍스트 소모가 급증한다.

**근본 원인**: 30+ 모듈, 450+ 심볼 규모에서 단발성 쿼리(LSP/Grep)로는 전체 그림을 그릴 수 없다. 매 세션마다 같은 탐색을 반복한다. Serena의 find_referencing_symbols가 있지만 세션 간 캐시가 안 된다.

**실제 사례**: Being.chat()을 수정할 때, being.py → mind_loop.py → graph.py → plan.py → execute.py를 순서대로 읽어야 데이터 흐름을 파악할 수 있었다. 매 세션마다 이 5개 파일을 다시 읽었다.

**필요한 도구**: **정적 코드 참조 그래프**
- `scripts/codegraph.py --generate` → `.codegraph/graph.json` (AST 분석)
- 노드: 클래스, 함수, 메서드 (파일, 라인, 호출/피호출 관계)
- 엣지: call, import, event(EventBus subscribe/publish)
- `scripts/codegraph.py --query "Being.chat" --depth 2` → Grep 10번 대신 JSON 1번 읽기
- `scripts/codegraph.py --impact "Being.chat"` → 영향 범위 즉시 파악

**난이도**: 중간 (AST 분석 스크립트) | **효과**: 높음 — 매 세션 인지 비용 절감, 컨텍스트 윈도우 절약

---

### P5: 아키텍처 지도의 부재 → 반복적 구조 파악

**증상**: MEMORY.md는 "뭘 언제 만들었는지"(변경 로그)이지, "뭐가 뭐와 연결되는지"(구조)가 아니다. 데이터 흐름, 초기화 순서, 이벤트 토폴로지를 매 세션마다 코드를 읽어서 재파악해야 한다.

**근본 원인**: 구조 문서가 없거나, 있어도 코드와 동기화되지 않아 신뢰할 수 없다.

**실제 사례**: Chat 데이터 흐름(user → being.chat() → _pending_chat → MindLoop → graph.py → plan → execute → Future resolve)을 파악하려면 5개 파일을 순서대로 읽어야 했다. 매 세션마다.

**필요한 도구**: **자동 생성 아키텍처 문서** *(이미 적용됨)*
- `scripts/gen_architecture.py` → `docs/ARCHITECTURE.md` 자동 생성
- 모듈 의존 그래프(Mermaid), 이벤트 맵, 부트스트랩 순서, 데이터 흐름
- `make docs`로 재생성 — 코드와 항상 동기화

**상태**: **해결됨**. `docs/ARCHITECTURE.md`가 이미 존재하고, codemap 기반 자동 생성이 동작 중.

---

### P6: Being이 duck-typed 가방이다

**증상**: Being 인스턴스가 ~40개 속성을 들고 다니고, 모든 소비자가 `being.X`로 직접 접근한다. "이 함수가 being의 뭘 쓰는가?"를 알려면 grep밖에 방법이 없다.

**근본 원인**: 타입 시스템이 동적 속성을 추적하지 못한다. `load_soul()`이나 `bootstrap()`이 동적으로 설정하는 속성을 IDE도, 타입 체커도, MagicMock(spec=Being)도 잡지 못한다.

**실제 사례**:
- mind cycle의 reflect node가 `being.hippocampus, being.belief_manager, being.precedent_store`를 쓴다
- bootstrap이 거의 전부를 쓴다
- 새 속성 `being.new_attr`을 추가해도 기존 코드에 어떤 영향이 있는지 타입 체커가 못 잡는다

**필요한 도구**: **소비자별 Protocol 정의**
```python
class MindCycleContext(Protocol):
    hippocampus: Hippocampus
    belief_manager: BeliefManager | None
    precedent_store: PrecedentStore | None
    bus: EventBus
```
- 함수가 `being: Being` 대신 `ctx: MindCycleContext`를 받으면 의존성이 시그니처에 드러남
- Python Protocol은 structural subtyping이라 Being 클래스를 바꾸지 않아도 동작
- 새로 작성/수정하는 함수부터 점진적 적용

**난이도**: 중간-높음 (2-3시간, 점진적) | **효과**: 중간 — 타입 안전성 + IDE 지원

---

## Part 3: 테스트 신뢰성 — "항상 빨간불인 CI"

### P7: 깨진 테스트가 신호를 삼킨다

**증상**: 항상 18-20개 테스트가 실패하고 있어서, 새로운 실패가 섞여도 눈에 안 띈다. "green baseline"이 없어서 리팩토링이 뭔가를 깼는지 아닌지 확신이 없다. CI를 걸어도 항상 빨간불이라 의미가 없다.

**근본 원인**: pre-existing failure를 정리하지 않은 채 코드가 계속 진화했다. 현재는 216개 collection error로 테스트 시스템 자체가 거의 동작 불능.

**실제 사례**: 오늘 19→18로 실패가 줄어든 걸 수동으로 세서 확인했다. 자동으로 감지할 수 없었다.

**필요한 도구**: **테스트 베이스라인 관리**
- 당장: 깨진 테스트에 `@pytest.mark.skip(reason="pre-existing failure")` 처리 → green baseline 확보
- 이후: 하나씩 수리 (test_self_modification 11개 → test_tools 3개 → 나머지)
- 장기: known-failures 파일에 목록 관리, 새 실패만 CI에서 감지

**난이도**: 낮음 (30분) | **효과**: 즉시 — green baseline이 모든 후속 작업의 기반

---

### P8: AI가 테스트를 조작할 수 있다

**증상**: "테스트를 통과시키려고 테스트 자체를 수정"하는 경우가 발생할 수 있다. 구현 세션에서 테스트가 실패하면, 코드를 고치는 대신 테스트 assertion을 바꿔버릴 위험.

**근본 원인**: AI에게 "테스트 통과"를 지시하면, 가장 쉬운 경로(테스트 수정)를 택할 수 있다. 무결성 검증이 없다.

**실제 사례**: 직접 관찰되지는 않았지만, v2 설계 문서에서 명시적으로 위험으로 식별됨.

**필요한 도구**: **세션 무결성 검증**
- 세션 시작 시 테스트 파일 해시 스냅샷 저장
- 세션 종료 시 해시 비교 — 구현 세션에서 테스트 수정 감지 → 경고 + 자동 revert 제안
- 허용된 변경 목록(allowed_changes) 지정 가능

**난이도**: 낮음-중간 | **효과**: 중간 — 의미론적 실패 방어

---

## Part 4: 검증과 품질 — "다 했어"의 신뢰도

### P9: 검증 파이프라인이 수동이다

**증상**: 코드 작성 후 "잘 동작하는지" 확인하는 과정이 `pytest` 한 줄뿐이다. 정적 분석(mypy, ruff), 무결성 검사, 핸드오프 품질 확인이 각각 별도 명령이라 빠뜨리기 쉽다.

**근본 원인**: 검증 단계가 하나의 파이프라인으로 묶여있지 않다. 각 단계를 기억하고 수동으로 실행해야 한다.

**필요한 도구**: **통합 검증 파이프라인 CLI**
```bash
hastlow validate              # 전체 파이프라인
hastlow validate --static     # 정적 분석만
hastlow validate --test       # 테스트만
hastlow validate --integrity  # 무결성만
hastlow validate --quick      # static + 변경된 파일만 테스트
```
- 단계: Static Analysis → Tests → Integrity → 결과 요약
- 종료 코드로 스크립트 분기 가능 (0=pass, 2=fail)
- 설정 파일(`config.yaml`)에 검증 명령어 정의 → 언어 무관

**난이도**: 중간 | **효과**: 높음 — "validate 한 줄이면 끝" 워크플로우

---

### P10: AI 작업의 "완료" 기준이 모호하다

**증상**: AI가 "다 했어"라고 하면, 사람이 확인할 방법이 테스트 돌리기 + 코드 직접 읽기뿐이다. 700+개 테스트를 다 볼 수 없고, 30개 파일을 다 읽을 수도 없다.

**근본 원인**: "완료"의 정의가 암묵적이다. 테스트 통과? 코드 스타일 준수? 기존 기능 미파괴? 핸드오프 작성? 이 모든 조건이 명시적으로 정의되지 않았다.

**필요한 도구**: **구조화된 핸드오프 + 품질 게이트**
- 핸드오프 필수 섹션 검증 (Done, Key Decisions, Changed Files, Next)
- 각 섹션 최소 길이 (대충 쓰기 방지)
- Changed Files의 실제 존재 확인
- status=complete인데 test_result=fail이면 거부
- 품질 실패 시 핸드오프 재생성 유도

**난이도**: 중간 | **효과**: 높음 — 완료의 객관적 기준 확보

---

## Part 5: 코드 구조 — "거대한 God Object"

### P11: `__init__`이 거대하다

**증상**: `Being.__init__`이 ~120줄, ~40개 인스턴스 변수를 선언한다. 분해 후에도 이 부분은 건드리지 못했다.

**근본 원인**: duck-typed 접근 패턴 때문에 속성을 그룹으로 묶기 위험하다. `being.quota_tracker`를 직접 쓰는 소비자가 많아서, Protocol 정의 없이 그룹 객체화하면 모든 소비자 코드가 깨진다.

**실제 사례**: 속성을 Identity(3), Memory(2), Infra(6), Survival(4), Loops(5), Income(3), Mind support(8), Goals(5), Agent(3), Misc(6)로 나눌 수 있지만, 변경 영향 범위를 확신할 수 없어 손대지 못했다.

**필요한 도구**: **소비자별 Protocol 정의(P6) + 자동 리팩토링**
- P6의 Protocol이 선행되어야 안전
- Protocol이 있으면 그룹 객체(`MindSupport`, `InfraBundle` 등) 도입 시 소비자 코드 변경 없이 내부 구조 재편 가능
- IDE의 "Extract Parameter Object" 리팩토링과 결합

**난이도**: 높음 (P6 선행 필요, 3-4시간) | **효과**: 중간 — 속성 관리 단순화

---

### P12: bootstrap 초기화 순서의 암묵적 의존성

**증상**: `being_bootstrap.py`의 23단계 초기화에 암묵적 의존성이 있다. 누군가 순서를 바꾸면 런타임에서야 에러가 난다.

**근본 원인**: 의존 관계가 코드에 명시되지 않았다. `init_agent_executor()`가 `init_tools()` 이후여야 한다는 것이 주석이나 assertion에 없다.

**실제 사례**: `init_tools() → init_agent_executor()`가 tool_registry를 사용하고, `hippocampus.initialize() → init_precedent_store()`가 embedder를 사용하지만, 이 관계가 어디에도 명시되지 않았다.

**필요한 도구**: **초기화 의존성 가드**
- 각 init 함수에 `assert being.tool_registry is not None, "requires init_tools()"` 가드
- 또는 `# requires: init_tools()` 주석 규칙
- ARCHITECTURE.md에 이미 부트스트랩 순서가 기록됨 — 각 단계에 의존성 정보 추가
- 장기적으로 의존성 그래프 기반 초기화 (현재 규모에선 과도)

**난이도**: 낮음 (30분) | **효과**: 중간 — 순서 변경 시 즉시 감지

---

## Part 6: 작업 방식 — "빨리 결과를 보여줘야 한다는 압박"

### P13: 질문 없이 바로 구현에 뛰어드는 패턴

**증상**: AI가 "X 해줘" 요청을 받으면 즉시 코드를 읽고 구현을 시작한다. 방향을 확인하는 2-3개 질문을 건너뛰어서, 완성된 결과가 의도와 다른 경우가 발생한다.

**근본 원인**: AI가 "빨리 결과를 보여줘야 한다"는 암묵적 압박을 느낀다. 질문하면 느려 보이니까 건너뛴다.

**실제 사례**: "M4.4 acceptance test 해줘"에서 MindLoop이 실제로 돌아야 하는지, Redis/Qdrant 연결 필수인지, 어느 수준까지 통과하면 accept인지 물어봤으면 삽질이 절반으로 줄었을 것.

**필요한 도구**: **CLAUDE.md 규칙 강제** *(이미 적용됨)*
- "구현에 착수하기 전에 반드시 2-3개 명확화 질문을 먼저 던질 것"
- "사용자가 '질문 없이 바로 해'라고 명시한 경우에만 생략 가능"

**상태**: **해결됨**. CLAUDE.md 작업 프로토콜에 "질문 먼저, 구현 나중" 규칙 적용됨.

---

### P14: 실패 시 재시도 전략이 없다

**증상**: 세션이 실패하면 "다시 해봐"뿐이다. 같은 프롬프트로 같은 실수를 반복하거나, 반대로 너무 다른 접근을 해서 이전 진행을 날린다.

**근본 원인**: 실패 유형을 분류하지 않는다. API 타임아웃(재시도하면 됨)과 설계 결함(사람이 개입해야 함)을 같은 방식으로 처리한다.

**필요한 도구**: **실패 유형 분류 + 유형별 재시도 전략**
- Type 1 (일시적): 자동 재시도 + exponential backoff
- Type 2 (구조적): 프롬프트 재구성 + 컨텍스트 보강
- Type 3 (설계 결함): 즉시 사람 에스컬레이션
- Type 4 (환경): 환경 리셋 스크립트
- Type 5 (의미론적): 크로스모델 검증

**난이도**: 높음 (오케스트레이터 일부) | **효과**: 높음 — 실패 대응 시간 단축

---

## Part 7: 비용과 관찰가능성 — "보이지 않는 낭비"

### P15: 세션별 비용/성과가 추적되지 않는다

**증상**: 한 세션에 토큰을 얼마나 썼는지, 첫 시도에 검증을 통과하는 비율이 얼마인지, 평균 세션 시간이 얼마인지 모른다. 감으로만 "오늘 좀 비효율적이었다"를 느낀다.

**근본 원인**: 메트릭 수집 인프라가 없다.

**필요한 도구**: **개발 메트릭 수집기**
- 세션별: 소요 시간, 변경 파일 수, 성공/실패, 토큰 사용량
- 누적: first-pass success rate, 피처당 평균 재시도, 핸드오프 품질 통과율
- `hastlow metrics` — 터미널에서 한눈에 확인
- 경보: 연속 실패 3회, 일일 비용 한도 초과, 성공률 급락

**난이도**: 중간 (메트릭 + CLI) | **효과**: 중간 — 비효율 패턴 식별

---

### P16: 사람-AI 간 검증 비대칭

**증상**: AI가 "다 했어"라고 하면, 사람이 700+개 테스트와 30개 파일을 검증할 수 없다. AI의 자기 보고에 의존할 수밖에 없지만, AI는 자기가 만든 코드의 버그를 못 찾는다.

**근본 원인**: 같은 모델이 구현 + 검증을 하면 같은 오해를 공유한다 ("동의하는 바보 둘" 문제).

**필요한 도구**: **크로스모델 검증**
- 구현 모델과 다른 모델이 테스트/리뷰를 수행
- 변경 영향 요약 자동 생성 (커밋 시 의미론적 diff 요약)
- 행동 기반 스모크 테스트 (단위 테스트를 넘어서 "Being이 의도대로 행동하는가")

**난이도**: 높음 (멀티모델 오케스트레이션) | **효과**: 높음 — 의미론적 실패 방어

---

## Part 8: AI 컨텍스트 효율 — "컨텍스트 윈도우는 유한하다"

### P17: LSP 쿼리의 세션 간 캐시 부재

**증상**: Serena의 find_symbol, find_referencing_symbols는 매번 LSP를 호출한다. 자주 조회하는 심볼(Being, MindGraph, Hippocampus 등)의 결과가 세션마다 반복 조회된다.

**근본 원인**: LSP 결과가 세션 간 캐시되지 않는다. 코드 참조 그래프(P4)가 이 문제를 해결할 수 있다.

**필요한 도구**: P4의 코드 참조 그래프가 사실상 캐시 역할. 별도 도구 불필요.

---

### P18: AI 컨텍스트 구성의 비효율

**증상**: AI가 세션을 시작할 때 필요한 정보(목표, 이전 세션, 읽어야 할 파일, 규칙)를 각각 별도로 수집한다. 4개 소스를 읽는 데 턴을 쓴다.

**근본 원인**: "이 세션에서 AI가 필요한 모든 것"을 한 번에 제공하는 메커니즘이 없다.

**필요한 도구**: **AI 컨텍스트 생성기**
```bash
hastlow context
# → Current Goal + Previous Session + Your Task + Context Files + Rules
#   모든 것이 하나의 구조화된 텍스트로 출력됨
```
- 소스 우선순위: 핸드오프 Next → goals.yaml active → Key Decisions → Context Files → conventions
- 포맷: markdown(사람용), plain(토큰 절약), json(프로그래밍)
- `hastlow context | claude -p "$(cat -)"` — 비인터랙티브 세션에 즉시 주입

**난이도**: 중간 | **효과**: 높음 — 부팅 시간 0으로 수렴

---

## 종합 우선순위

| 순위 | Pain Point | 필요한 도구 | 난이도 | 효과 | 상태 |
|------|-----------|------------|--------|------|------|
| 1 | P7 깨진 테스트 | skip 처리 + green baseline | 30분 | 즉시 | 미적용 |
| 2 | P1 세션 부팅 | 핸드오프 시스템 | 낮음 | 즉시 | 미적용 |
| 3 | P13 질문 먼저 | CLAUDE.md 규칙 | 0 | 즉시 | **적용됨** |
| 4 | P3 작업 크기 | 프로세스 규칙 | 0 | 즉시 | 부분 적용 |
| 5 | P12 bootstrap 가드 | assert + 주석 | 30분 | 중간 | 미적용 |
| 6 | P5 아키텍처 지도 | ARCHITECTURE.md | 1시간 | 높음 | **적용됨** |
| 7 | P2 프로젝트 상태 | goals.yaml + CLI | 중간 | 높음 | 미적용 |
| 8 | P4 코드 그래프 | codegraph.py | 중간 | 높음 | 미적용 |
| 9 | P9 검증 파이프라인 | hastlow validate | 중간 | 높음 | 미적용 |
| 10 | P18 컨텍스트 생성 | hastlow context | 중간 | 높음 | 미적용 |
| 11 | P10 완료 기준 | 핸드오프 품질 게이트 | 중간 | 높음 | 미적용 |
| 12 | P6 Protocol 정의 | 소비자별 Protocol | 중-높 | 중간 | 미적용 |
| 13 | P8 테스트 무결성 | 해시 검증 | 중간 | 중간 | 미적용 |
| 14 | P15 메트릭 | 개발 메트릭 수집 | 중간 | 중간 | 미적용 |
| 15 | P11 init 그룹화 | Protocol 후 리팩토링 | 높음 | 중간 | 미적용 |
| 16 | P14 실패 전략 | 실패 분류 + 재시도 | 높음 | 높음 | 미적용 |
| 17 | P16 크로스 검증 | 멀티모델 오케스트레이션 | 높음 | 높음 | 미적용 |

### 관찰되는 패턴

이 18개 pain point는 **5개 상위 문제**로 수렴한다:

1. **세션 비연속성** (P1, P2, P3, P18) → 해결: hastlow (session + handoff + context + goal)
2. **코드베이스 불투명** (P4, P5, P6, P11, P12, P17) → 해결: 코드 그래프 + Protocol + 아키텍처 문서
3. **테스트 인프라 취약** (P7, P8) → 해결: green baseline + 무결성 검증
4. **검증 부재** (P9, P10, P14, P16) → 해결: 통합 검증 파이프라인 + 크로스모델
5. **관찰불가능성** (P15) → 해결: 메트릭 수집

이 5개 문제 중 **1(세션 비연속성)**이 가장 빈도 높고, **3(테스트 인프라)**이 가장 ROI 높다.
이 두 가지를 먼저 해결하면, 나머지 문제를 풀 기반이 마련된다.
