simulate-dont-just-scan

name	simulate-dont-just-scan
description	읽기는 했지만 실행해 보지 않은 코드를 포팅·디버깅·구현할 때 적용한다 — 소스를 읽은 것이 동작을 이해한 것이라고 가정하지 말고, 구체적인 입력으로 코드를 머릿속에서 돌려 실제 런타임 출력·DOM·응답·데이터 모양·부수효과를 예측한다.

Simulate, Don't Just Scan

소스 파일을 읽는 것은 이해하는 것과 다르다. 파일을 여는 건 "이 텍스트가 존재한다"를 알려준다. 파일을 머릿속에서 실행하는 건 "이게 돌면 무엇을 만들어내는가"를 알려준다.

포팅·디버깅·구현 버그 대부분은 읽기를 충분하다고 여기는 데서 온다 — "이게 돌 때 실제 출력 / DOM / 응답 / 데이터 모양 / 부수효과가 뭐지?"를 한 번도 묻지 않고 소스 파일만 머릿속에 모으는 것.

The Mistake

관련돼 보이는 파일을 다 연다. 내용을 훑는다. context를 가졌다고 느낀다. 하지만 코드를 머릿속에서 돌린 적은 없다: 구체적인 값을 대입한 적도, entry point에서 부수효과까지 control flow를 따라간 적도, 터미널 출력을 예측한 적도 없다.

이해처럼 보이지만 아닌 신호들:

• "스타일 파일을 열었으니 스타일링은 안다." (그런데 렌더 시점에 어느 엘리먼트가 실제로 어느 클래스를 갖지?)
• "타입 정의를 읽었으니 모양은 안다." (그런데 살아있는 엔드포인트에서 오는 실제 응답 본문은 뭐지?)
• "미들웨어를 훑었으니 뭘 변환하는지 안다." (그런데 전체 체인을 통과한 뒤 요청이 어떻게 생겼지?)
• "config 스키마를 봤으니 런타임 값은 안다." (그런데 이 환경에서 실제로 로드된 건 뭐지?)

이건 모두 소스의 존재에 대한 것이지, 런타임 동작에 대한 게 아니다.

Why It Happens

읽기는 싸고 생산적으로 느껴진다. 머릿속 실행은 더 많은 상태를 들고 있어야 한다 — 값을 대입하고, 분기를 처리하고, 여러 계층을 가로질러 동작을 합성한다. 뇌는 가능하면 싼 길을 택한다.

합성과 추상화가 이걸 더 나쁘게 만든다. 컴포넌트 트리, 미들웨어 체인, 데이터 파이프라인, ORM 매핑, config 레이어링, 이벤트 디스패치에서는 — 어느 한 파일도 답 전체를 담고 있지 않다. 동작을 직접 합성해야 한다.

Symptoms

• 출력이 현실과 안 맞고, 교정을 거듭할수록 격차가 계속 벌어진다.
• 10초짜리 시뮬레이션이면 드러났을 값·상태·구조에 놀란다.
• 리뷰어가 "코드를 읽었으면 알았을" 효과를 반복해서 짚는다 — 그리고 따지자면 너는 코드를 읽긴 했다.

Protocol

출력(코드, 포트, 수정, 분석)을 내기 전에 명시적으로 시뮬레이션한다:

1. 구체적인 entry point와 구체적인 입력을 고른다. "일반적으로"가 아니라 특정 케이스로.
2. 실행을 한 단계씩 걷는다. 각 단계마다 짚는다:
   • 어느 파일 / 함수 / 계층이 처리하는지
   • 그 지점에서 입력이 어떻게 생겼는지
   • 어떤 변환이나 결정이 일어나는지
   • 그 단계 뒤 출력이 어떻게 생겼는지
3. 터미널에서 — DOM, HTTP 응답, DB row, 로그 줄 — 정확한 모양을 말한다. 못 하겠으면 아직 이해 못 한 것이다.
4. 가능하면 예측한 출력을 현실과 비교한다: 페이지를 렌더하고, 엔드포인트를 때리고, 함수를 돌리고, 로그를 본다.

Rules

• 실행 하나도 따라가지 않고 파일만 모으고 있다는 걸 알아챘으면, 멈추고 시뮬레이션한다.
• 시스템이 합성될수록 시뮬레이션은 더 필수다 — 덜 필요한 게 아니다.
• 읽기는 시뮬레이션을 준비시킨다. 시뮬레이션의 대체물이 아니다.
• 리뷰어가 "코드를 봤으면 보였을" 격차를 짚을 때, 진짜 교훈은 거의 항상 시뮬레이션을 건너뛰었다는 것이지 읽기가 불완전했다는 게 아니다.