도구(모델)가 좋아져도 AI 협업이 매 세션 “처음부터 다시”인 느낌이 드는 이유는, 지식·검증·강제가 세션 밖에 누적되지 않는 구조 때문입니다. 이 글에서는 이를 해결하기 위해 제가 정리한 /init→/work→/save→/tidy→/check→/ship→/retro 7단계 세션 파이프라인과, 반복 실패를 Hard Rule로 승격하는 기준(테스트 게이트 포함)을 공유합니다.
왜 “세션이 반복될수록 규칙이 진화하는 루프”가 필요한가
AI와 협업을 하다 보면 이런 문제가 반복됩니다.
- 어제 했던 실수를 오늘 또 합니다(회귀, regression).
- 세션이 바뀌면 품질 기준/작업 규칙이 흐려집니다.
- “테스트는 해야지”가 매번 결심으로 끝나고, 강제되지 않습니다.
이건 모델 성능보다 운영 구조의 문제라고 봤습니다.
해결 목표는 간단합니다.
세션이 끝나면 교훈이 남고, 다음 세션 시작부터 그 교훈이 자동으로 적용되게 만들자.
세션 파이프라인 7단계: /init→/work→/save→/tidy→/check→/ship→/retro
아래 7단계를 표준 커맨드(의식/프로토콜) 로 고정하면, “기억/검증/강제”가 세션 밖으로 빠져나와 누적됩니다.
1) /init — 컨텍스트 로드 + 오늘의 품질 기준 선언
- 저장된 Memory(프로젝트 규칙/실패 기록/결정 사항)와 현재 이슈/PR/릴리즈 상황을 불러옵니다.
- “이번 세션에서 절대 깨면 안 되는 Hard Rule”을 맨 위에 씁니다.
예: UI 작업이라면
- “D&D 관련 변경 시 Playwright 핵심 시나리오 통과는 Hard Gate”
- “성능 예산(예: 특정 페이지 LCP) 체크는 Soft Gate 또는 Hard Gate”
2) /work — 작업 우선순위화 + 변경 범위 명시
- 작업을 나누고, 영향 범위(affected areas) 를 먼저 적습니다.
- “부분 수정이 전체 리그레션을 만든다”는 문제는 결국 변경 영향 추적이 약할 때 자주 생깁니다.
UI에서 특히 중요합니다. 컴포넌트 한 군데를 고쳤는데 라우트/상태 흐름 전체가 느려지거나 상호작용이 깨질 수 있으니까요.
3) /save — 교훈/결정/실패 모드(실패 형태)를 Memory에 저장
여기서 핵심은 “커버리지 숫자”가 아니라 실패 모드 기반으로 무엇을 막을지 저장하는 것입니다.
예: “D&D 모듈에서 상호작용 버그가 반복됨 → e2e가 비싸지만 필수”
4) /tidy — 외부 이슈 동기화 + 산출물 정리
- PR/이슈/문서와 동기화합니다.
- “다음 세션에서 바로 이어갈 수 있는 상태”로 정리합니다.
5) /check — 배포 전 품질 게이트(Soft/Hard) 실행
여기서 “혁신 속도 vs 안정성”의 균형이 결정됩니다.
- Hard Gate: 실패 시 배포/머지를 막습니다.
- Soft Gate: 실패해도 기록은 남기되, 예외 승인을 통해 진행할 수 있습니다.
제가 대화에서 결론에 가까웠던 기준은 이렇습니다.
- 반복 실수가 많은 영역(특히 UI 상호작용/D&D)은 속도를 포기하고 안정성을 택할 가치가 큼
- 다만 커버리지 강제만으론 부족하고, 실제 실패 모드를 잡는 시나리오/신호가 필요함
- e2e는 느리고 플래키할 수 있으니, “무엇을 e2e로 강제할지”를 좁혀야 함
(사례) D&D 상호작용 버그 → Playwright 필수 테스트로 Hard Rule 승격
D&D(Drag & Drop)는 좌표/타이밍/이벤트 차이로 플래키가 생기기 쉬워서, “AI Agent가 1차로 테스트한다”는 흐름은 좋지만 증거 기반이 필요합니다.
- 실패 시: trace/video/screenshot/event log 같은 증거를 남기기
- “플래키”와 “실결함”을 구분할 수 있는 재현 정보 최소화
6) /ship — 배포 자동화 + 결과 기록
- 배포/머지/릴리즈 노트를 표준화합니다.
- “어떤 게이트를 통과했고 무엇을 예외로 처리했는지”를 남겨야
/retro에서 데이터가 됩니다.
7) /retro — 회고 + 규칙 승격(Soft→Hard) + 회귀 페널티 반영
회고의 목적은 감상이 아니라 규칙의 진화입니다.
- 동일 실패 재발 시: 강제력(LEVEL)을 올립니다.
- 점수(Eval)에서 회귀 페널티를 줘서 “재발 비용”을 명확히 합니다.
- 결과적으로 “교훈 → 자동 차단 규칙”으로 변환됩니다.
Eval(평가)을 누적하는 이유: 병목을 감이 아니라 데이터로 잡기
세션 단위로 5개 차원(D1~D5)을 평가하고 누적하면, 팀/프로젝트의 병목이 드러납니다.
- 예: “UI 변경에서 회귀가 잦다”가 감상이 아니라,
- 어떤 유형의 작업에서,
- 어떤 게이트가 부족했고,
- 어떤 신호(e2e/성능/비주얼 디프)가 실패를 놓쳤는지
를 추적할 수 있게 됩니다.
그리고 반복 실패는 Regression Penalty로 다룹니다.
- “또 터졌네”가 아니라 “또 터졌으니 Hard Rule/강제력을 올린다”
- 운영이 사람의 의지에서 시스템으로 이동합니다.
대화에서 나온 가장 큰 인사이트: property-based 테스트는 구조가 허락해야 한다
대화 중에 제가 스스로 확인한 중요한 사실이 있었습니다.
D&D의 drag 계산을 pure function으로 추출하지 않았기 때문에 property-based 테스트를 도입할 수 없었습니다.
이건 단순히 “테스트를 더 써야지”가 아니라, 테스트 가능성(testability)은 설계의 결과라는 신호였습니다.
- 지금 분리 비용이 커 보여도,
- 분리하지 않으면 e2e 비용(느림/플래키/유지보수)이 계속 누적됩니다.
현실적인 절충은 “완전 분리”가 아니라 가장 좁은 계산 조각부터 분리하는 겁니다.
- 예:
pointerMove의 delta/스냅/경계 클램핑 같은 계산만이라도 pure function화 - 그 위에 e2e는 “핵심 플로우 3~5개” 정도만 Hard Gate로 유지
마무리
세션 파이프라인 7단계의 요지는 AI가 똑똑해지는 걸 기다리는 게 아니라, 세션 밖에 규칙과 검증을 누적하는 구조를 만드는 것입니다. 특히 UI/D&D처럼 반복 실수가 발생하는 영역은 “테스트를 해야지”가 아니라 Hard Gate로 승격되는 운영 루프로 다루는 게 결국 가장 빠른 길이었습니다.
참고자료
CLI-Anything (GitHub - HKUDS/CLI-Anything: "CLI-Anything: Making ALL Software Agent-Native" -- CLI-Hub: https://clianything.cc/ · GitHub)