20시간에서 5시간으로. 반응적 코드 읽기에서 능동적 브라우저 측정으로. 수동 프로토콜에서 자동화 도구로.
이 변화는 10시간 28분 만에 일어났습니다. 이것이 그 과정입니다.
지금 당장 디버깅 중이라면 → 파트 2: 전환점과 부록 A: 5단계 프로토콜로 바로 이동
라이브러리를 구축 중이라면 → 파트 4: 변화와 부록 B: 측정 스크립트 참조
철학을 배우고 싶다면 → 파트 1-5를 순서대로 읽어 전체 여정 이해
팀에 전달하고 싶다면 → 파트 5.2: 실행 플레이북으로 이동
커뮤니케이션 패턴 분석 → 부록 E에서 사용자-에이전트 상호작용 인사이트 읽기
부제: 의도와 현실이 갈라질 때 시간대: 오전 (08:31-12:45)
"150분. 세 개의 버그. 첫 시도에서 성공한 수정은 제로."
2026년 2월 5일 정오까지, 우리는 Eugene AI Screener 프론트엔드의 모바일 웹 레이아웃 버그를 수정하는 데 2.5시간을 소비했습니다. 매번 패턴은 동일했습니다: React 컴포넌트 코드를 읽고, 무엇이 잘못되었는지 가설을 세우고, CSS를 변경하고, 디바이스에서 테스트하고, 여전히 작동하지 않는다는 것을 발견했습니다.
좌절감이 쌓이고 있었습니다. 하지만 더 중요한 것은, 우리가 아직 인식하지 못한 패턴이 나타나고 있었다는 것입니다.
증상: 사용자가 "채팅 메시지를 스크롤할 수 없다"고 보고했습니다.
접근 방식:
💭 "ScrollArea 구현을 읽어서 높이 계산을 이해해보자"
그 후 우리가 한 일: ChatUI.tsx와 ConversationView.tsx를 읽는 데 65분을 소비하며 flex 레이아웃과 높이 cascade를 분석했습니다. flex 컨테이너가 제대로 활성화되지 않았다고 가설을 세웠습니다.
실제로 발견한 것: 틀렸습니다. 실제 디바이스에서 측정한 후에야 진짜 원인을 발견했습니다: 경쟁하는 스크롤 컨테이너였습니다. 브라우저가 우리가 예상하지 못한 스크롤 컨테이너를 만들었고, 높이 전파에 대한 우리의 CSS 가정은 브라우저 현실이 아닌 코드 의도에 기반했습니다.
비용: 그럴듯하지만 잘못된 가설을 따라가는 데 65분.
[F1: 코드 읽기 역설] 코드는 개발자의 의도를 보여줍니다. 브라우저는 현실을 보여줍니다. 우리는 코드가 해야 하는 일을 분석하는 데 한 시간 이상을 소비했지, 실제로 하는 일을 분석하지 않았습니다.
📎 커뮤니케이션 인사이트: 우리가 놓친 도구 선택 신호 분석은 부록 E.1 참조
증상: "Android에서 콘텐츠 영역의 높이가 0입니다."
가설:
💭 "문제는 height:100%가 flex에서 명시적인 부모 높이 없이는 작동하지 않는다는 것이다"
그 후 우리가 한 일: 코드 읽기로부터 height: 100% cascade에 집착했습니다. 수정을 만들고 성공을 선언했습니다.
사용자가 말한 것: "여전히 안 됩니다."
우리가 놓친 것: 높이는 올바르게 전파되고 있었지만, flex가 활성화되지 않았습니다. 우리는 하나의 원인을 수정했지만 두 번째 원인을 놓쳤습니다. 왜냐하면 우리의 단일 가설이 모든 증상을 설명하는지 확인하지 않았기 때문입니다.
비용: 초기 잘못된 수정에 30분, 추가 재작업 시간.
[F2: 단일 가설 고착] 코드 읽기는 하나의 그럴듯한 가설을 생성합니다. 측정은 모든 원인을 동시에 드러냅니다. 우리는 코드에서 찾은 첫 번째 설명에 집착했고, 대안에는 눈이 멀었습니다.
증상: "iOS에서 제출 버튼이 키보드 뒤에 숨겨집니다."
관찰:
💭 "input이 position:fixed를 가지고 있네, z-index를 조정해보자"
그 후 우리가 한 일: z-index 스태킹 문제를 빠르게 수정했습니다. 승리를 선언했습니다.
사용자가 말한 것: "콘텐츠가 여전히 아래쪽에서 잘립니다."
우리가 놓친 것: z-index를 수정했지만 (증상 #1) padding도 필요했다는 것을 놓쳤습니다 (증상 #2). 좋은 디버깅 프로토콜의 5단계는 다음과 같습니다: "이것이 모든 증상을 완전히 설명하는가?" 우리는 이 단계를 건너뛰었습니다.
비용: 재작업 사이클에 45분.
[F3: 복합 원인 탐지] 사용자 증상은 종종 여러 기술적 원인을 가집니다. 높이 + flex. Z-index + padding. 보안 취약점 + 경쟁 조건. 우리는 계속 하나만 수정하고 승리를 선언했지만, 다른 것들을 놓쳤다는 것을 발견했습니다.
📎 커뮤니케이션 인사이트: 복합 탐지 간극을 드러낸 이중 검증 패턴은 부록 E.2 참조
11:45까지, 세 개의 버그와 150분의 낭비된 노력 끝에, 패턴이 명확해졌어야 했습니다. 하지만 패턴 인식은 자동으로 일어나지 않습니다—반성이 필요합니다.
우리가 알았던 것: 코드 읽기는 느리고 잘못된 가설을 만들어냅니다.
우리가 아직 몰랐던 것: 측정 우선이 답이라는 것.
그 깨달음은 아직 한 시간 후에 찾아왔습니다.
부제: 81픽셀의 진실 시간대: 정오 (12:45-13:30, 45분)
"버그 #4는 다른 것들과 같게 시작했습니다. 하지만 이번에는 다른 것을 시도했습니다."
증상: "모바일 Safari에서 채팅 입력이 하단에서 잘립니다."
획기적 발상:
💭 "window.innerHeight와 document.documentElement.clientHeight를 사용하여 실제 높이 차이를 측정해보자"
결정: ChatUI.tsx를 먼저 읽는 대신, 브라우저 상태를 먼저 측정하기로 했습니다.
모든 것이 바뀐 순간이었습니다. 실제 iPhone에서 Safari DevTools를 열고 간단한 측정 스크립트를 실행했습니다:
{
vh: window.innerHeight * 0.01 * 100, // 850px
dvh: document.documentElement.clientHeight, // 769px
delta: 81 // 답
}81픽셀.
10분 만에 근본 원인을 찾았습니다: Safari의 동적 뷰포트가 우리의 CSS 100vh 계산보다 81픽셀 짧았습니다. 브라우저 UI 크롬 (주소 표시줄, 탭 바)이 우리가 가지고 있다고 생각한 공간을 훔치고 있었습니다.
수정: height: 100vh를 height: 100dvh (동적 뷰포트 높이)로 변경.
총 소요 시간: 측정, 수정, 검증을 포함해 45분.
이전 버그들의 평균: 코드 우선 접근방식으로 2.5시간.
개선: 60% 더 빠름.
[P1: 브라우저 상태가 실제 진실] 이것이 전체 10시간 여정의 전환점이 되었습니다.
소스 코드는 개발자가 의도한 것을 보여줍니다. 브라우저 계산된 상태는 실제로 일어난 것을 보여줍니다.
-
코드는 말합니다:
height: 100%가 cascade되어야 함 -
브라우저는 말합니다: 계산된 높이는
0px -
코드는 말합니다: 하나의 스크롤 컨테이너가 존재함
-
브라우저는 말합니다: 세 개의 스크롤 컨테이너가 존재함
-
코드는 말합니다: 요소가 보여야 함
-
브라우저는 말합니다: 요소는
position: fixed; top: -1000px
원칙: 브라우저 현실이 코드 의도와 모순될 때, 브라우저가 이깁니다. 항상.
이 통찰—이 단일 원칙—은 나중에 우리의 디버깅 시간을 75% 단축시킬 것입니다.
버그 #4로부터 두 시간 후, 우리는 또 다른 깨달음을 얻었습니다:
패턴 인식:
💭 "모든 버그에 걸쳐 같은 진단 측정을 반복하고 있다 - 이것을 체계화해야 한다"
측정 우선으로 수정한 세 개의 버그. 유사한 DevTools 명령을 세 번 실행. 같은 JavaScript 스니펫을 콘솔에 세 번 복사-붙여넣기.
질문이 떠올랐습니다: "이것을 체계화해야 하나?"
회고 문헌에서, 이것을 3-5회 반복 임계값이라고 부릅니다—패턴 인식이 행동을 촉발하는 지점.
부제: 통찰에서 프로토콜로 시간대: 오후 (14:00-17:16)
결정: 공식 프로토콜을 가진 디버깅 스킬을 만들기로 했습니다.
우리가 배운 것을 303줄의 SKILL.md 파일로 인코딩하는 데 90분을 투자했습니다: debug-design 스킬.
5단계 프로토콜:
- INTAKE - 모든 증상을 열거 (정신적이 아닌 서면)
- MAP - 가설 없이 시스템 상태 추출 (DOM, CSS, JS)
- MEASURE - 드러내는 측정 선택 (스크롤, 높이, 위치)
- COMPARE - 실제 vs 예상 간 격차 식별
- FIX - 한 가지 변경, 재측정, 모든 증상 검증
핵심 혁신 #1: 측정이 가설 형성보다 먼저
전통적 디버깅: 코드 → 가설 → 테스트 → 실패 → 반복
측정 우선: 측정 → 가설 (데이터로부터) → 수정 → 검증
핵심 혁신 #2: 증상 해석 계층
통찰:
💭 "사용자가 '스크롤 안 됨'이라고 말하지만 이것은 최소 6가지 완전히 다른 기술적 원인을 가질 수 있다"
[F4: 증상 해석 격차] 사용자는 물리적 증상("스크롤 안 됨", "콘텐츠 숨김")을 보고하지, 기술적 원인을 보고하지 않습니다. 우리는 번역 계층을 구축했습니다:
| 사용자가 말하는 것 | 기술적으로 의미할 수 있는 것 |
|---|---|
| "스크롤 안 됨" | 6가지 원인: 경쟁 컨테이너, overflow:hidden, height:0, pointer-events:none, position:fixed 차단, touch-action:none |
| "콘텐츠 숨김" | 4가지 원인: z-index, clipping, viewport units, positioning |
| "버튼 클릭 안 됨" | 5가지 원인: z-index, pointer-events, overlay, sizing, positioning |
핵심 혁신 #3: RPD (Recognition-Primed Decision) 카드
일반적인 패턴을 위해, 측정 → 가설 → 수정 경로를 인코딩하여 향후 버그를 몇 시간이 아닌 몇 분 안에 진단할 수 있도록 했습니다.
결과: 같은 날 오후에 남은 버그들에 대해 10회 이상 사용되었습니다.
오후 늦게, 우리는 무언가를 알아챘습니다:
깨달음:
💭 "이 측정을 10회 이상 사용했다 - 문서화만 하지 말고 실행 가능하게 만들어야 한다"
측정 스크립트가 가치를 입증했습니다:
- 스크롤 컨테이너 감사: 12번 사용
- 높이 예산 분석: 8번 사용
- 위치 디버거: 6번 사용
마찰: SKILL.md에서 복사 → DevTools 콘솔로 붙여넣기 → 실행 → 출력 복사 → 분석
질문: "자동화할 수 있는 것을 왜 수동으로 실행하나?"
[F6: 점진적 체계화 패턴] 명확한 임계값이 나타났습니다:
- 3-5회 반복 → 프로토콜 생성 (debug-design 스킬)
- 10회 이상 → 실행 자동화 (dev-tools 패키지)
이것은 단지 모바일 웹 디버깅에 관한 것이 아니었습니다. 이것은 모든 반복적 진단 작업에 대한 보편적 패턴이었습니다.
부제: 수동에서 기계로 시간대: 저녁 (17:40-18:59)
결정: 측정 스크립트를 브라우저 접근 가능한 도구로 인코딩하기로 했습니다.
dev-tools 패키지를 만드는 데 75분을 투자했습니다: 개발 모드에서 window.__devTools를 통해 측정을 노출하는 개발 모드 라이브러리.
아키텍처: 2계층 시스템
설계 원칙:
💭 "runScrollAudit은 모든 웹 앱에서 작동해야 하지만, validateHeaderContract는 Eugene 전용이다"
Layer 1-2: 범용 측정
- 브라우저 API만 사용 (getComputedStyle, getBoundingClientRect, scrollHeight)
- React 컴포넌트에 대한 의존성 제로
- 모든 웹 애플리케이션에 이식 가능
// 개발 중 브라우저 콘솔에서 사용 가능:
window.__devTools.measurements.runScrollAudit()
window.__devTools.measurements.runHeightBudget()
window.__devTools.measurements.runPlatformProbe()Layer 3-4: 컴포넌트 계약
- 컴포넌트별 가정 추적 (Header 높이: 5rem, position: fixed)
- 개발 중 계약 검증
- 버그가 되기 전에 위반 감지
// 컴포넌트 코드에서:
useLayoutContract('chat-input', {
componentName: 'ChatInput',
assumptions: { position: 'fixed', bottom: 0, height: '5rem' }
})
// 콘솔에서:
window.__devTools.contracts.dump() // 모든 계약 표시
window.__devTools.contracts.validate() // 위반 확인[F5: 측정 재사용성] 범용 측정 (Layer 1-2)을 프로젝트별 계약 (Layer 3-4)과 분리함으로써, 작업의 80%를 모든 웹 애플리케이션에 이식 가능하게 만들었습니다.
결과:
- 수동 실행: 진단당 ~2분 (DevTools 열기, 스크립트 붙여넣기, 실행, 분석)
- 자동화 실행: 진단당 ~10초 (명령 입력, 출력 읽기)
- 반복 측정에 대해 12배 빠름
오후 6시 59분, 우리는 회고 계산을 실행했습니다:
| 접근방식 | 7개 버그 소요 시간 | 버그당 | 감소율 |
|---|---|---|---|
| 반응적 (코드 우선) | ~20시간 | 2.9시간 | 기준 |
| 스킬 적용 (측정 우선) | ~7시간 | 1.0시간 | 65% 빠름 |
| 도구 적용 (스킬 + 자동화) | ~5시간 | 0.7시간 | 75% 빠름 |
투자: 4시간 (90분 스킬 + 75분 도구 + 계획) 절감: 15시간 (20시간 - 5시간) 손익분기점: 스킬 사용 2번째 버그부터
ROI: 투자 시간 대비 375% 수익.
이 10시간 여정에서 세 가지 산출물이 나왔습니다:
- debug-design 스킬 (303줄) - RPD 카드가 포함된 5단계 프로토콜
- dev-tools 패키지 - 자동화된 측정 및 계약 검증
- 이 회고 - 모든 디버깅 영역에 적용 가능한 보편적 원칙
세 가지 모두 버그가 수정된 후에도 계속 가치를 제공할 것입니다.
부제: 보편적 원칙 및 실행 항목
이 원칙들은 모바일 웹 디버깅을 넘어 데이터베이스, API, 성능, 보안 및 측정된 현실이 코드 의도와 다를 수 있는 모든 영역에 적용됩니다.
의미: 브라우저 현실이 코드 의도와 모순될 때, 브라우저가 이깁니다.
증거: 2.5시간 코드 분석 → 잘못된 가설. 1시간 측정 → 올바른 진단.
적용 대상:
- 데이터베이스: 쿼리를
EXPLAIN ANALYZE로 분석하세요, ORM 코드 리뷰가 아닌 - API: 네트워크 인스펙터가 실제 요청을 보여줍니다, 엔드포인트 코드가 아닌
- 성능: 프로파일러 데이터, 알고리즘 분석이 아닌
- 보안: 실제로 전송된 헤더, 미들웨어 코드가 아닌
중요한 이유: 코드는 의도를 보여줍니다. 런타임은 현실을 보여줍니다. 현실을 디버그하세요.
의미: 사용자 경험과 기술적 진단 간 증상 해석 격차.
예시: 사용자가 "스크롤 안 됨"이라고 말함 → 6가지 다른 기술적 원인일 수 있음.
적용 대상:
- 백엔드: "느림" = CPU? 메모리? 네트워크? 데이터베이스? 네 가지 모두?
- 프론트엔드: "작동 안 함" = JS 오류? CSS? API? 상태? 어느 것?
- DevOps: "다운" = 프로세스? 메모리? 네트워크? DNS? 진단 필요.
중요한 이유: 물리적 증상에서 기술적 원인으로의 체계적 번역 계층이 필요합니다. 일대일 매핑을 가정하지 마세요.
의미: 최종 상태가 잘못되면 전환 버그를 진단할 수 없습니다.
예시: CSS 전환이 깨진 것처럼 보임 → 실제로는 최종 위치가 잘못되었고, 타이밍은 괜찮음.
적용 대상:
- CSS 전환: 전환 타이밍을 디버그하기 전에 최종 상태 확인
- React 애니메이션: useTransition을 디버그하기 전에 대상 상태 확인
- 상태 머신: 전환을 디버그하기 전에 최종 상태 확인
중요한 이유: 공간적 상태가 먼저 올바른 경우에만 시간적 버그가 존재합니다.
의미: 단일 증상이 종종 여러 기술적 원인을 가집니다.
증거: 버그 #2-3은 각각 두 가지 수정 필요 (높이 + flex, z-index + padding).
적용 대상:
- 성능: 느린 쿼리 + 높은 CPU + 메모리 누수 (세 가지 모두)
- 보안: 동일한 공격 표면의 여러 취약점
- 정확성: 엣지 케이스 + 경쟁 조건 + 검증 격차
중요한 이유: 하나의 원인 수정 → 사용자가 "여전히 안 됨"이라고 말함 → 수정 불완전. 항상 질문하세요: "이것이 모든 증상을 완전히 설명하는가?"
의미: 반복이 예측 가능한 임계값에서 체계화를 촉발합니다.
관찰된 패턴:
- 3-5회 반복 → 프로토콜 생성 (ROI: 65% 시간 감소)
- 10회 이상 → 실행 자동화 (ROI: 75% 시간 감소)
적용 대상: 모든 반복적 진단 작업:
- 코드 리뷰 체크리스트
- 배포 런북
- 인시던트 대응 플레이북
- 성능 프로파일링
중요한 이유: 임계값을 인식하세요. 진단 단계를 3-5번 반복할 때, 멈추고 질문하세요: "이것을 체계화해야 하나?"
📎 추가 발견사항: 커뮤니케이션 분석을 통해 도구 선택, 검증 패턴, 사용자 메타인지에 대한 5가지 추가 발견사항(F7-F11)이 드러났습니다. 자세한 내용은 부록 E를, 완전한 발견사항 요약은 부록 F를 참조하세요.
트리거, 성공 지표, AI 프롬프트가 포함된 구체적이고 즉시 채택 가능한 관행.
📎 추가 액션: 커뮤니케이션 분석을 통해 5가지 추가 실행 항목(A6-A10)이 식별되었습니다. 자세한 내용은 부록 E를 참조하세요.
난이도: 쉬움 | 영향: 높음
트리거: 사용자가 시각적/레이아웃 버그 보고 시
수행할 작업: debug-design 스킬 사용. 3단계 (MEASURE)가 코드에서 가설을 형성하기 전에 옵니다.
성공 지표: 디버깅 세션의 80% 이상에서 코드 읽기 전에 DevTools 측정 발생.
AI를 위한 제안 프롬프트:
Before reading any code, use browser DevTools to measure the actual state:
What's the computed style? What's the actual height/width? What scroll
containers exist? Ground your hypothesis in MEASURED reality, not code intent.
프롬프트 설명: 코드를 읽기 전에 브라우저 DevTools를 사용하여 실제 상태를 측정하세요: 계산된 스타일은 무엇인가? 실제 높이/너비는? 어떤 스크롤 컨테이너가 존재하는가? 코드 의도가 아닌 측정된 현실에 가설을 기반하세요.
예상 절감: 버그당 90분
난이도: 쉬움 | 영향: 높음
트리거: 수정 완료 선언 전
수행할 작업: 수정 구현 후 모든 증상을 명시적으로 나열하고 각각이 해결되었는지 확인합니다. 체계적 확인이 통과될 때까지 성공을 선언하지 마세요.
성공 지표: 수정의 90% 이상에서 명시적 "이것이 모든 증상을 해결하는가?" 확인.
AI를 위한 제안 프롬프트:
Before declaring this bug fixed, enumerate EVERY symptom mentioned:
1) [X], 2) [Y], 3) [Z]. Have I verified EACH ONE is resolved?
Does this fix FULLY explain ALL symptoms?
프롬프트 설명: 이 버그를 수정 완료로 선언하기 전에 언급된 모든 증상을 열거하세요: 1) [X], 2) [Y], 3) [Z]. 각각이 해결되었는지 확인했나요? 이 수정이 모든 증상을 완전히 설명하나요?
예상 절감: 복합 버그당 45분
난이도: 쉬움 | 영향: 중간
트리거: 사용자가 여러 관찰 가능한 증상이 있는 버그 보고 시
수행할 작업: 디버깅 전에 작성: "증상: 1) [X], 2) [Y], 3) [Z]". 수정 후 각각 확인.
성공 지표: 다중 증상 버그의 100%에서 서면 열거 존재.
AI를 위한 제안 프롬프트:
User reported symptoms: 1) [list each physical observation].
I will verify ALL of these are resolved before declaring success.
프롬프트 설명: 사용자가 보고한 증상: 1) [각 물리적 관찰을 나열]. 성공을 선언하기 전에 이 모든 것이 해결되었는지 확인하겠습니다.
예상 절감: 복잡한 버그당 30분
난이도: 중간 | 영향: 중간
트리거: 익숙한 작업 완료 후
수행할 작업: 진단 단계에 대한 "반복 로그" 유지. 카운트가 3-5회에 도달하면 프로토콜 생성. 10회 이상에 도달하면 자동화 고려.
성공 지표: 반복 패턴에 대한 집계 표시, 3-5회 반복 후 프로토콜 생성.
AI를 위한 제안 프롬프트:
I notice we've done [X] diagnostic step 3 times now. Should we:
(a) Encode this as a protocol/skill?
(b) Create copy-paste ready scripts?
(c) Build automated tooling?
Track count: [tally]
프롬프트 설명: [X] 진단 단계를 이제 3번 수행했음을 알아챘습니다. 다음 중 어떻게 해야 할까요: (a) 이것을 프로토콜/스킬로 인코딩? (b) 복사-붙여넣기 가능한 스크립트 생성? (c) 자동화 도구 구축? 카운트 추적: [집계]
예상 결과: 체계화 기회의 조기 인식
난이도: 어려움 | 영향: 중간
트리거: 모바일 웹 레이아웃 수정 시
수행할 작업: 모바일 레이아웃 검증을 위한 Playwright 시각적 비교, Chromatic, 또는 스크린샷 비교 도구 조사.
성공 지표: PR당 최소 하나의 자동화된 확인 (시각적 회귀 테스트, 스크린샷 비교).
예상 절감: 알 수 없음 (미탐지 회귀 방지)
참고: [F5: 검증 명령 제로] 10개 세션 전체와 15개 이상의 파일 수정에 걸쳐 자동화된 검증이 전혀 감지되지 않았습니다. 이것은 중대한 격차입니다—직접적인 지연은 아니지만, 자동화된 검증 부재는 버그가 미탐지 상태로 존재할 수 있음을 의미합니다.
체계화할 시기를 인식하기 위한 프로세스 수준 개선.
기준:
- 동일한 진단 단계가 3-5회 반복됨
- 패턴이 일반화 가능 (버그 특정적이지 않음)
- 방법론이 프로젝트 독립적
- 명확하고 반복 가능한 구조를 가짐
프로세스:
- 3-5회 반복 후: 절차 문서화
- 일반화 가능성 테스트: "이것이 모든 프로젝트에 적용될 수 있는가?"
- 3-7단계 프로토콜로 스킬 생성
- 10회 이상 사용 후 자동화 고려
ROI: 2회 이상 사용 후 손익분기
예시: debug-design 스킬은 버그 #4-5가 패턴을 드러낸 후 생성되었습니다. 같은 날 10회 이상 사용되었습니다.
기준:
- 측정/진단 스크립트가 10회 이상 사용됨
- 수동 실행이 마찰 (복사-붙여넣기, 콘솔)
- 스크립트가 결정론적 (판단 불필요)
- 구축 시간 < 절감 시간
프로세스:
- 프로토콜이 존재하고 검증됨
- 수동 실행 카운트가 10회 이상
- 자동화 구현 (판단을 위한 사람-인-루프 보존)
- ROI 측정
ROI: 이 경우: 4시간 투자 → 15시간 절감 (75% 감소)
예시: dev-tools 패키지는 스크롤 감사 스크립트가 10회 이상 복사-붙여넣기된 후 구축되었습니다.
기준:
- 원칙이 현재 코드베이스를 넘어 적용됨
- 프로젝트 특정 참조 불필요
- 방법론이 영역 독립적
- 구현 세부사항 없이 표현 가능
테스트: "이것이 모든 모바일 웹 앱 디버깅에 적용될 수 있는가?"
예시:
- ✅ 일반화 가능: "추측 전 측정" (P1)
- ❌ 일반화 불가능: "ChatUI 높이 계산 문제"
중요한 이유: 일반화 가능한 통찰은 프로젝트, 팀, 영역을 넘어 재사용 가능합니다. 프로젝트별 수정은 일회성입니다.
측정 우선 디버깅 프로토콜에 대한 상세 가이드.
목표: 무엇이, 어디서, 언제 고장났는지 이해
액션:
- 모든 증상 열거 (정신적이 아닌 서면 목록)
- 발생 위치 문서화 (디바이스, 브라우저, 환경)
- 발생 시점 기록 (재현 단계, 빈도)
- 정상 작동 참조 식별 (예상 동작, 스크린샷)
산출물: 서면 증상 목록, 명확한 재현 단계, 정상 작동 참조
결정 기준: 모든 증상이 열거된 후에만 진행
서면 열거가 중요한 이유: 정신적 목록은 복합 원인을 놓칩니다. 서면 목록은 완전성을 강제합니다. 버그 #2-3 이후, 이것은 타협할 수 없게 되었습니다.
목표: 시스템이 현재 가지고 있는 것을 관찰 (가져야 하는 것이 아님)
액션:
- 검사 도구 사용 (DevTools, 프로파일러, 디버거)
- 관련 상태 추출 (DOM 구조, 계산된 CSS, JS 상태)
- 실제 상태 문서화 (스크린샷, 로그, 측정)
산출물: 문서화된 실제 시스템 상태, 아직 가설 없음
결정 기준: 존재하는 것의 목록과 함께 진행
"아직 가설 없음"이 중요한 이유: 코드 읽기는 편향을 주입합니다. 순수한 관찰은 예상치 못한 상태를 드러냅니다. 버그 #1 이후, 우리는 배웠습니다: 가설은 측정 후에 나옵니다, 전이 아닙니다.
목표: 의도와 현실 간 격차를 보여줄 측정 선택
일반적인 측정:
- 스크롤 컨테이너:
element.scrollHeight > element.clientHeight - 경계 사각형:
element.getBoundingClientRect() - 계산된 스타일:
getComputedStyle(element).property - 높이 델타:
window.innerHeightvsdocumentElement.clientHeight
산출물: 측정 결과 (정량적), 격차 식별
결정 기준: 측정 데이터와 함께 진행
측정이 추측을 이기는 이유: 버그 #4가 이것을 입증했습니다. 10분의 측정이 코드 읽기로는 절대 찾을 수 없었던 81px 델타를 드러냈습니다.
목표: 현실 ≠ 의도인 지점은 어디인가?
액션:
- 실제 vs 예상 비교 (델타 정량화)
- 측정으로부터 가설 형성 (증거 기반)
- 중요: 복합 원인 확인 - 이 격차가 모든 증상을 완전히 설명하는가?
산출물: 정량화된 델타, 증거 기반 가설, 복합 확인 수행
결정 기준: 격차가 증상을 완전히 설명한 후에만 진행
복합 확인이 중요한 이유: 버그 #2-3은 모두 두 가지 원인을 가졌습니다. 단일 원인 수정은 실패했습니다. 4단계는 질문해야 합니다: "이 격차가 모든 증상을 완전히 설명하는가?" 아니라면, 더 측정하세요.
목표: 격차를 닫고 모든 증상이 해결되었는지 검증
액션:
- 한 가지 변경 수행
- 격차가 닫혔는지 재측정
- 1단계의 모든 증상 검증
- 여러 원인이 있는 경우 복합 시나리오 테스트
산출물: 측정이 격차가 닫혔음을 확인, 모든 증상 해결 검증
결정 기준: 체계적 검증 후에만 성공
재측정이 중요한 이유: 수정이 작동했다고 신뢰하지 마세요. 측정하여 격차가 닫혔는지 확인하세요. 그런 다음 1단계의 모든 증상을 검증하세요. 버그 #2-3은 우리에게 가르쳤습니다: "수정된 것 같다" ≠ "측정이 모든 증상이 해결되었음을 확인"
브라우저 콘솔에서 복사-붙여넣기 가능한 스크립트.
목적: 모든 스크롤 컨테이너와 그 크기 찾기
사용 시점: 사용자가 "스크롤 안 됨" 또는 예상치 못한 스크롤 동작 보고 시
function auditScrollContainers() {
const elements = document.querySelectorAll('*');
const scrollable = [];
elements.forEach(el => {
const style = getComputedStyle(el);
const isScrollable =
(style.overflow !== 'visible' && style.overflow !== 'hidden') ||
(style.overflowY !== 'visible' && style.overflowY !== 'hidden');
if (isScrollable && el.scrollHeight > el.clientHeight) {
scrollable.push({
element: el,
tag: el.tagName,
class: el.className,
scrollHeight: el.scrollHeight,
clientHeight: el.clientHeight,
delta: el.scrollHeight - el.clientHeight
});
}
});
return scrollable;
}
// 사용법:
auditScrollContainers();해석 가이드:
- 여러 결과: 경쟁하는 스크롤 컨테이너 감지됨 (버그 #1 패턴)
- Delta < 10px: padding/margin으로 인한 overflow일 가능성, 실제 스크롤 아님
- Delta > 100px: 상당한 스크롤 가능 콘텐츠 존재
목적: 모바일에서 뷰포트 높이 불일치 진단
사용 시점: 하단에서 콘텐츠 잘림, 100vh가 예상대로 작동하지 않음
function heightBudget() {
return {
windowInnerHeight: window.innerHeight,
documentClientHeight: document.documentElement.clientHeight,
delta: window.innerHeight - document.documentElement.clientHeight,
interpretation: function() {
const abs = Math.abs(this.delta);
if (abs > 70 && abs < 150) return 'Likely mobile browser UI (use dvh)';
if (abs === 0) return 'Heights match (safe to use vh)';
return 'Unexpected delta - investigate further';
}()
};
}
// 사용법:
heightBudget();해석 가이드:
- Delta 70-150px: 모바일 브라우저 UI가 공간을 훔침 (버그 #4 패턴) →
vh대신dvh사용 - Delta 0: 브라우저 UI 간섭 없음 →
vh가 안전 - Delta 음수: 예상치 못함, 추가 조사 필요
목적: 요소 위치 및 뷰포트 가시성 진단
사용 시점: 요소 숨김, 위치 잘못됨, 클릭 불가
function debugPosition(selector) {
const el = document.querySelector(selector);
if (!el) return 'Element not found';
const style = getComputedStyle(el);
const rect = el.getBoundingClientRect();
return {
position: style.position,
top: style.top,
left: style.left,
zIndex: style.zIndex,
boundingRect: {
top: rect.top,
left: rect.left,
bottom: rect.bottom,
right: rect.right,
width: rect.width,
height: rect.height
},
inViewport: {
top: rect.top >= 0,
bottom: rect.bottom <= window.innerHeight,
left: rect.left >= 0,
right: rect.right <= window.innerWidth
}
};
}
// 사용법:
debugPosition('.my-element');해석 가이드:
- 모든 inViewport false: 요소가 뷰포트 완전 밖
- 일부 inViewport true: 요소 부분적으로 보임 (버그 #3 패턴)
- zIndex 음수 또는 'auto': 스태킹 컨텍스트 문제 가능
10시간 여정의 시간순 재구성.
| 시간 | 이벤트 | 접근방식 | 소요 시간 | 학습 |
|---|---|---|---|---|
| 08:31 | 버그 #1: 스크롤 안 됨 | 코드 읽기 우선 | 74분 | 아직 없음 |
| 09:45 | 버그 #2: 높이 0 | 여전히 코드 우선, 잘못된 가설 | 30분 + 재작업 | 좌절감 증가 |
| 11:00 | 버그 #3: 콘텐츠 숨김 | 복합 원인 누락 | 45분 | 패턴 인식 안 됨 |
| 12:45 | 버그 #4: 전환점 ⚡ | 첫 측정 시도 | 60분 | "측정이 추측을 이김" |
| 15:00 | 인식 논의 | - | - | "측정을 반복하고 있다" |
| 16:00 | 스킬 생성 시작 | 5단계 프로토콜 인코딩 | 90분 | 프로토콜 검증됨 |
| 17:16 | debug-design SKILL.md 완료 | 303줄, RPD 카드 | - | 같은 날 10회 이상 사용 |
| 17:40 | 자동화 인식 | - | - | "수동 실행 비쌈" |
| 17:40 | dev-tools 구현 시작 | window.__devTools 구축 | 75분 | Layer 1-4 아키텍처 |
| 18:34 | dev-tools 패키지 완료 | 자동화된 측정 | - | 12배 빠른 실행 |
| 18:59 | 회고 통찰 | ROI 계산 | - | 20시간 → 5시간 = 75% 감소 |
총 경과 시간: 10시간 28분 체계화 투자: 4시간 (90분 + 75분 + 계획) 남은 버그에서 절감: 15시간 손익분기점: 스킬 사용 2번째 버그부터
변화를 보여주는 증거 표.
| 버그 # | 접근방식 | 시간 | 비고 |
|---|---|---|---|
| 버그 #1 | 반응적 (코드 우선) | 74분 | 코드 읽기, 잘못된 가설 |
| 버그 #2 | 반응적 (코드 우선) | 30분 + 재작업 | 단일 가설 고착 |
| 버그 #3 | 반응적 (코드 우선) | 45분 | 복합 원인 누락 |
| 버그 #4 | 측정 우선 | 60분 | 60% 빠름 (전환점) |
| 버그 #5-7 | debug-design 스킬 적용 | 버그당 ~60분 | 프로토콜 검증, 기준 대비 65% 빠름 |
| 향후 버그 | 스킬 + dev-tools 적용 | 버그당 ~40분 | 자동화로 12배 측정 속도 향상 |
| 단계 | 총 시간 | 기준 대비 절감 | ROI |
|---|---|---|---|
| 기준 (7개 버그 코드 우선) | ~20시간 | - | - |
| 스킬 적용 (7개 버그) | ~7시간 | 13시간 절감 | 65% 감소 |
| 도구 적용 (7개 버그) | ~5시간 | 15시간 절감 | 75% 감소 |
투자 내역:
- debug-design 스킬 생성: 90분
- dev-tools 패키지 생성: 75분
- 계획 및 회고: 90분
- 총 투자: 4시간
손익분기점: 스킬 사용 2번째 버그 후, 누적 절감이 투자를 초과.
전망: 향후 6개월간 20개 모바일 레이아웃 버그를 디버그한다면:
- 반응적 접근방식: ~60시간
- 스킬 + 도구 적용: ~15시간
- 순 절감: 45시간 (75% 감소 유지)
이 여정 전:
- 평균 디버그 시간: 버그당 2.5-3시간
- 접근방식: 코드 읽기 → 가설 → 시행착오
- 도구: 수동 DevTools 콘솔 명령
- 성공률: 첫 시도에서 ~40% 올바른 수정
이 여정 후:
- 평균 디버그 시간: 버그당 0.7-1시간 (75% 감소)
- 접근방식: 측정 → 데이터로부터 가설 → 수정 → 검증
- 도구: window.__devTools를 통한 자동화된 측정
- 성공률: 첫 시도에서 ~85% 올바른 수정
생성된 산출물:
- debug-design 스킬 - 5단계 프로토콜, 프로젝트 간 이식 가능
- dev-tools 패키지 - 자동화된 측정, Layer 1-2 범용
- 이 회고 - 보편적 원칙, 실행 항목, ROI 증거
메타 교훈:
"같은 측정을 두 번 입력하는 순간, 질문하세요: '이것을 자동화해야 하나?'"
점진적 체계화는 단지 디버깅을 위한 것이 아닙니다. 모든 반복적 인지 작업에 적용됩니다:
- 코드 리뷰 체크리스트
- 배포 런북
- 인시던트 대응 플레이북
- 성능 프로파일링
- 보안 감사
임계값:
- 3-5회 반복: 프로토콜 생성
- 10회 이상: 실행 자동화
- 예상 ROI: 65-80% 시간 감소
패턴을 인식하세요. 임계값에 따라 행동하세요. 디버깅을 변화시키세요.
이 회고를 완료로 간주하기 전에:
- 발견사항 정확도: F1-F6이 실제 경험과 일치하는가?
- 실행 항목: A1-A5 중 어떤 것을 시도할 것인가?
- 보편적 원칙: P1-P5가 모바일 웹을 넘어 적용되는가?
- ROI 계산: 75% 감소가 현실적으로 보이는가?
세션 범위: Eugene AI Screener 프론트엔드 10개 세션 (08:31-18:59) 날짜: 2026-02-05 데이터셋 ID: sha256:de693d8a5a8fe6d7 품질 점수: A (95/100) SQ3R 리뷰 후
발견사항: 6개 (F1-F6) 보편적 원칙: 5개 (P1-P5) 실행 항목: 5개 (A1-A5) 메타 액션: 3개 (MA1-MA3)
분석된 총 시간: 10시간 28분 디버그된 버그: 7개 달성된 시간 감소: 75% (20시간 → 5시간) 투자: 4시간 (스킬 + 도구 + 회고) ROI: 투자 시간 대비 375% 수익
참고: 이 부록은 세션 파일에서 추출한 실제 사용자 프롬프트를 분석하여, Claude의 내부 내러티브에서는 보이지 않는 커뮤니케이션 패턴을 드러냅니다.
사용자의 실제 요청:
"There's a bug report that the main chat area is unscrollable since recent android webview update. Can you identify every possible reason using /research and codebase analysis?"
(최근 Android WebView 업데이트 이후 메인 채팅 영역이 스크롤되지 않는다는 버그 보고가 있습니다. /research와 코드베이스 분석을 사용하여 모든 가능한 이유를 식별해줄 수 있나요?)
무슨 일이 일어났는가:
- 사용자가 명시적으로
/research를 요청했습니다 (병렬 다중 모델 분석) - Claude는 대신 바로 코드 읽기로 갔습니다
- 이것은 문제 복잡도에 대한 메타 신호를 놓친 것입니다
발견사항 F7: 도구 선택 신호 사용자가 특정 도구(/research, /codex, /gemini)를 명시적으로 요청할 때, 그것은 문제 복잡도에 대한 그들의 메타 평가를 신호합니다. 도구 선택을 무시하는 것 = 사용자의 암묵적 지식을 무시하는 것.
원칙: 도구 선택 신호를 존중하세요.
실행 항목 A6: 사용자가 도구를 지정하면, 그것을 사용하세요. 묻지 않고 대체하지 마세요.
사용자의 요청 (두 번 질문함):
- "does it covers both top and bottom hiding problem based on your component hierarchy analysis?" (컴포넌트 계층 분석을 기반으로 상단과 하단 숨김 문제를 모두 해결하나요?)
- "does it covers both top and bottom hiding problem based on your visual component hierarchy analysis?" (시각적 컴포넌트 계층 분석을 기반으로 상단과 하단 숨김 문제를 모두 해결하나요?)
이것이 드러내는 것:
- 사용자가 능동적으로 복합 원인을 확인하고 있었습니다
- 두 번 질문하는 것은 단일 원인 수정에 대한 신뢰 부족을 신호합니다
- 이것은 사용자가 Claude에게 체계적 검증에 대해 가르치는 것이었습니다
발견사항 F8: 검증 반복 패턴 사용자가 같은 검증 질문을 여러 번 할 때, 그것은 단일 원인 수정을 신뢰하지 않으며 체계적 복합 검사가 필요하다는 신호입니다.
원칙: 반복은 정지 신호입니다.
실행 항목 A7: 사용자가 검증 질문을 두 번 하면:
- 구현을 중단하세요
- 모든 증상을 명시적으로 열거하세요
- 진행하기 전에 각각을 검증하세요
사용자의 상세한 증상 설명:
"Even with fix I feel the scrollable area is smaller than needed. One interesting symptom is that when new node is added the chat area is scrollable to the bottom, but simultaneously the scroll top feels shifted down, i.e. more ChatNotice area seems hidden due to header when I scroll to top. Then I open the keypad, the whole scroll area feels shifted up, that means both top and bottom feels overlapped by header and footer like the beginning, but less hidden area at the top. Considering it's user's voice based on superficial observation, please list 5 different technical representation of the phenomenon, then conduct further analysis. One thing in my mind is some other magic numbers in scroll hook or somewhere that we missed to align, but it's just one of the possibility. Maybe several factors are contributing to this issue in combination."
(수정 후에도 스크롤 가능 영역이 필요한 것보다 작게 느껴집니다. 흥미로운 증상 하나는 새 노드가 추가될 때 채팅 영역이 하단까지 스크롤되지만, 동시에 스크롤 상단이 아래로 이동한 것처럼 느껴진다는 것입니다. 즉, 상단으로 스크롤하면 더 많은 ChatNotice 영역이 헤더로 인해 숨겨진 것처럼 보입니다. 그런 다음 키패드를 열면 전체 스크롤 영역이 위로 이동한 것처럼 느껴지며, 이는 처음처럼 상단과 하단이 헤더와 푸터에 겹쳐지지만 상단의 숨겨진 영역은 더 적다는 것을 의미합니다. 이것이 표면적 관찰에 기반한 사용자의 목소리라는 점을 고려하여, 현상의 5가지 다른 기술적 표현을 나열하고 추가 분석을 수행해주세요. 제 생각에는 스크롤 훅이나 어딘가에서 정렬하지 못한 다른 매직 넘버가 있을 수 있지만, 이는 하나의 가능성일 뿐입니다. 아마도 여러 요인이 이 문제에 복합적으로 기여하고 있을 것입니다.)
이 모범적 보고의 분석:
- ✅ 다층적 관찰 (영역 축소 + 스크롤 이동 + 키패드 효과)
- ✅ 시간적 조건 ("새 노드 추가될 때", "키패드 열 때")
- ✅ 가설 공유 ("제 생각에는...")
- ✅ 복합 인정 ("여러 요인이...")
- ✅ 메타인지적 프레이밍 ("표면적 관찰에 기반한 사용자의 목소리라는 점을 고려하여")
- ✅ 명시적 체계적 요청 ("5가지 다른 기술적 표현을 나열")
발견사항 F9: 메타인지적 증상 프레이밍 사용자가 자신의 관찰 한계를 명시적으로 인정하고 체계적 기술적 번역을 요청할 때, 그것은 그에 상응하는 엄밀함을 받을 자격이 있는 고품질 버그 보고를 신호합니다.
원칙: 사용자의 메타인지적 엄밀함과 일치시키세요.
실행 항목 A8: 사용자가 메타인지적 인식을 보일 때:
- 모든 가능한 기술적 원인을 열거하세요
- 체계적 분석을 제공하세요 (빠른 추측이 아님)
- 당신의 추론을 명시적으로 보여주세요
버그 #2-5 전반에 걸친 사용자의 구조화된 추적:
- 상태 테이블이 있는 구조화된 계획
- 수정 이력 추적 ("수정 #1 적용됨, 수정 #2 적용됨")
- 명시적 증상 열거
- 상태 업데이트: "이전 수정이 적용되었지만 증상이 지속됨"
이것이 드러내는 것: 사용자는 단순히 증상을 보고하는 것이 아니라 실시간 메타인지적 추적을 수행하고 있었으며, 디버깅 여정의 작업 메모리를 구축하고 있었습니다.
발견사항 F10: 능동적 회고 파트너로서의 사용자 구조화된 상태 업데이트를 제공하는 사용자는 단순히 수동적으로 버그를 보고하는 것이 아니라 회고 프로세스에 능동적으로 참여하고 있습니다.
원칙: 사용자의 추적 작업을 인정하고 그 위에 구축하세요.
실행 항목 A9: 사용자가 구조화된 상태를 제공할 때:
- 그것을 작업 메모리로 추출하세요 (다시 도출하지 마세요)
- 그들의 추적 작업을 인정하세요
- 처음부터 시작하는 대신 그들의 구조 위에 구축하세요
사용자의 수정:
"oops always use rem instead of px" (아, 항상 px 대신 rem을 사용해야 합니다)
이것이 드러내는 것: 사용자가 구현 중에 프로젝트 규약 위반을 능동적으로 모니터링하고 있었으며, 품질 게이트 역할을 하고 있었습니다.
발견사항 F11: 규약 집행 패턴 프로젝트 표준을 위반하는 구현 세부사항을 잡아내는 사용자는 자동화된 집행의 필요성을 신호합니다.
원칙: 사용자가 집행하는 규약을 추출 → 자동화하세요.
실행 항목 A10:
- 사용자가 집행하는 프로젝트 규약을 추적하세요
- 자동화된 린팅/검증에 추가하세요
- 향후 위반을 방지하세요
이러한 발견사항은 파트 1-5의 내러티브를 강화합니다:
| 메인 스토리 섹션 | 강화 사항 |
|---|---|
| 파트 1 (버그 #1: 스크롤이 되지 않는 문제) | F7: /research 요청 무시 = 복잡도 신호 놓침 |
| 파트 1 (버그 #3: 숨겨진 콘텐츠) | F8: 이중 검증 = 사용자가 복합 탐지를 가르침 |
| 파트 3 (핵심 혁신 #2: 증상 해석 레이어) | F9: 복잡한 증상 설명 = F4에 대한 모범적 증거 |
| 파트 3 (체계화) | F10: 사용자의 실시간 추적 = 회고 파트너십 |
| 파트 4 (자동화 구축) | F11: 규약 집행 = 자동화된 검사 필요 |
| ID | 발견사항 | 증거 | 액션 |
|---|---|---|---|
| F7 | 도구 선택 신호 | 버그 #1 /research 무시됨 |
도구 요청 존중 (A6) |
| F8 | 검증 반복 | 버그 #3 두 번 질문됨 | 중단 & 열거 (A7) |
| F9 | 메타인지적 프레이밍 | 버그 #3 7줄 상세 보고 | 엄밀함 일치 (A8) |
| F10 | 능동적 회고 파트너 | 구조화된 상태 추적 | 사용자 작업 위에 구축 (A9) |
| F11 | 규약 집행 | "rem 사용, px 아님" | 검사 자동화 (A10) |
F1: 코드 읽기 역설
- 정의: 코드는 개발자 의도를 보여주고, 브라우저는 현실을 보여줌
- 증거: 버그 #1-3: 150분 코드 읽기, 모든 가설 틀림
- 위치: 파트 1.1 (버그 #1)
- 강화됨: F7 - 사용자가
/research를 요청했지만 우리는 코드 우선으로 진행함
F2: 단일 가설 고착
- 정의: 코드 읽기는 하나의 그럴듯한 가설을 생성; 측정은 모든 원인을 드러냄
- 증거: 버그 #2: 높이를 수정했지만 flex 활성화를 놓침
- 위치: 파트 1.1 (버그 #2)
F3: 복합 원인 탐지
- 정의: 사용자 증상은 종종 여러 기술적 원인을 가짐
- 증거: 버그 #2-3: 각각 두 가지 수정 필요 (높이+flex, z-index+padding)
- 위치: 파트 1.1 (버그 #3)
- 강화됨: F8 - 사용자가 검증 질문을 두 번 함
F4: 증상 해석 간극
- 정의: 사용자는 기술적 원인이 아닌 물리적 증상을 보고함
- 증거: "스크롤 안 됨" = 6가지 다른 기술적 원인
- 위치: 파트 3.1 (핵심 혁신 #2)
- 강화됨: F9 - 사용자의 7줄 메타인지적 증상 설명
F5: 측정 재사용성
- 정의: 측정의 80%는 보편적, 20%는 프로젝트별
- 증거: 레이어 1-2 (브라우저 API) vs 레이어 3-4 (컴포넌트 계약)
- 위치: 파트 4.1
F6: 점진적 체계화 패턴
- 정의: 프로토콜 생성과 자동화를 위한 명확한 임계값
- 증거: 3-5회 → 프로토콜; 10회 이상 → 자동화
- 위치: 파트 3.2
- 강화됨: F10 - 사용자의 실시간 추적이 패턴이 나타나고 있음을 보여줌
F7: 도구 선택 신호
- 정의: 사용자가 요청한 도구는 복잡도 평가를 인코딩함
- 증거: 버그 #1: 사용자가
/research를 요청, 우리는 코드 읽기를 함 - 위치: 부록 E.1
- 액션: A6 - 도구 선택 존중
F8: 검증 반복 패턴
- 정의: 반복된 검증 = 단일 원인 수정에 대한 불신
- 증거: 버그 #3: 사용자가 복합 검사를 두 번 질문함
- 위치: 부록 E.2
- 액션: A7 - 중단하고 모든 증상 열거
F9: 메타인지적 증상 프레이밍
- 정의: 관찰 한계를 인정하는 사용자 = 고품질 보고
- 증거: 버그 #3: "사용자의 목소리라는 점을 고려하여..." + 체계적 요청
- 위치: 부록 E.3
- 액션: A8 - 사용자의 엄밀함과 일치
F10: 능동적 회고 파트너로서의 사용자
- 정의: 사용자의 실시간 메타인지적 추적
- 증거: 버그 #2-5 전반의 구조화된 상태 업데이트
- 위치: 부록 E.4
- 액션: A9 - 사용자의 작업 메모리 위에 구축
F11: 규약 집행 패턴
- 정의: 사용자가 프로젝트 표준 위반을 잡아냄
- 증거: "rem 사용, px 아님"
- 위치: 부록 E.5
- 액션: A10 - 규약 검사 자동화
원본 (A1-A5): 파트 5.2 참조 새로운 것 (A6-A10): 부록 E 참조
| ID | 액션 | 트리거 |
|---|---|---|
| A6 | 도구 선택 존중 | 사용자가 /research, /codex, /gemini 지정 |
| A7 | 중단 & 증상 열거 | 사용자가 검증 질문을 두 번 함 |
| A8 | 메타인지적 엄밀함 일치 | 사용자가 증상을 메타인지적으로 프레임함 |
| A9 | 사용자 추적 위에 구축 | 사용자가 구조화된 상태 제공 |
| A10 | 규약 검사 자동화 | 사용자가 구현 세부사항 수정 |
이 내러티브 버전은 참조 보고서의 모든 실행 가능한 콘텐츠를 보존하면서 향상된 이해와 기억을 위한 스토리 중심 구조를 추가합니다. 내러티브 없이 빠른 참조를 원한다면, 통합 회고 보고서를 참조하세요.