[Edu] Reframe Puzzle 9 around Mojo's AOT model and refresh tutorial

output

MODULAR_ORIG_COMMIT_REV_ID: e23d3626d61ccfca8241b66731a0b075d61f5c86

Author: dunnoconnor

book/i18n/ko/GLOSSARY_KO.md

@@ -57,7 +57,6 @@
 | hidden dimension       | 은닉 차원             | 신경망 내부 표현의 차원 수. 트랜스포머에서 각 토큰의 벡터 크기                                                                            |
 | host code              | 호스트 코드           | CPU에서 실행되는 코드. GPU 작업을 설정하는 부분                                                                                           |
 | in-place (computation) | 직접 저장 (연산)      | 별도 메모리를 할당하지 않고 기존 버퍼에 결과를 직접 기록하는 방식                                                                         |
-| JIT                    | JIT                   | Just-In-Time. 실행 시점에 코드를 컴파일하는 방식. 빌드 단계 없이 빠른 반복 가능                                                           |
 | kernel                 | 커널                  | GPU에서 여러 스레드가 함께 실행하는 함수                                                                                                  |
 | kernel code            | 커널 코드             | GPU에서 병렬로 실행되는 코드                                                                                                              |
 | lane                   | 레인                  | 워프 내 각 스레드의 위치 (0-31)                                                                                                           |

book/i18n/ko/src/puzzle_09/essentials.md

@@ -111,10 +111,10 @@ error: use of undeclared identifier 'my_variable'
 **빠른 참조:**
 
 ```bash
-# 1. JIT + LLDB: 소스에서 직접 CPU 호스트 코드 디버깅
+# 1. 소스 + LLDB: 소스에서 직접 CPU 호스트 코드 디버깅
 pixi run mojo debug your_gpu_program.mojo
 
-# 2. JIT + CUDA-GDB: 소스에서 직접 GPU 커널 디버깅
+# 2. 소스 + CUDA-GDB: 소스에서 직접 GPU 커널 디버깅
 pixi run mojo debug --cuda-gdb --break-on-launch your_gpu_program.mojo
 
 # 3. 바이너리 + LLDB: 미리 컴파일된 바이너리에서 CPU 호스트 코드 디버깅
@@ -129,11 +129,12 @@ pixi run mojo debug --cuda-gdb --break-on-launch your_program_debug
 
 **학습과 빠른 실험용:**
 
-- **JIT 디버깅** 사용 - 빌드 단계가 필요 없어 더 빠르게 반복 가능
+- **소스 디버깅** 사용 - 별도 빌드 단계가 필요 없어 더 빠르게 반복 가능
 
 **본격적인 디버깅 세션용:**
 
-- **바이너리 디버깅** 사용 - 더 예측 가능하고 깔끔한 디버거 출력
+- **바이너리 디버깅** 사용 - 더 예측 가능하고 깔끔한 디버거 출력, 빌드
+  플래그를 완전히 제어 가능 (`-O0 -g`로 로컬 변수 보존)
 
 **CPU 측 문제용** (버퍼 할당, 호스트 메모리, 프로그램 로직):
 
@@ -143,8 +144,8 @@ pixi run mojo debug --cuda-gdb --break-on-launch your_program_debug
 
 - **CUDA-GDB 모드** 사용 - 개별 GPU 스레드를 검사하는 유일한 방법
 
-장점은 다양하게 조합해서 사용할 수 있다는 점입니다. JIT + LLDB로 설정 코드를
-디버깅한 다음, JIT + CUDA-GDB로 전환해서 실제 커널을 디버깅할 수 있습니다.
+장점은 다양하게 조합해서 사용할 수 있다는 점입니다. 소스 + LLDB로 설정 코드를
+디버깅한 다음, 소스 + CUDA-GDB로 전환해서 실제 커널을 디버깅할 수 있습니다.
 
 ---
 
@@ -362,15 +363,17 @@ CUDA-GDB 바이너리를 자동 감지하고 conda 환경에 링크하여 전체
 ### 디버깅 접근법 학습 경로
 
 Puzzle 01을 예제로 [네 가지 디버깅 조합](#네-가지-디버깅-조합)을 탐색합니다.
-**학습 경로**: JIT + LLDB(가장 쉬움)로 시작해서 CUDA-GDB(가장 강력함)로
+**학습 경로**: 소스 + LLDB(가장 쉬움)로 시작해서 CUDA-GDB(가장 강력함)로
 진행합니다.
 
 **⚠️ GPU 디버깅 시 중요사항**:
 
 - `--break-on-launch` 플래그는 CUDA-GDB 접근법에서 **필수**
-- **미리 컴파일된 바이너리** (접근법 3 & 4)는 디버깅을 위해 `i` 같은 로컬 변수를
-  보존
-- **JIT 컴파일** (접근법 1 & 2)은 대부분의 로컬 변수를 최적화로 제거
+- **미리 컴파일된 바이너리** (접근법 3 & 4)는 `-O0 -g`로 빌드되어 최적화가
+  비활성화되고 디버그 심볼이 포함됩니다 — 그래서 `i` 같은 로컬 변수가
+  검사를 위해 보존됩니다
+- **소스에서 디버깅** (접근법 1 & 2)은 기본 플래그로 컴파일되므로, 대부분의
+  로컬 변수가 최적화로 제거됩니다
 - 본격적인 GPU 디버깅에는 **접근법 4** (바이너리 + CUDA-GDB) 사용
 
 ## 튜토리얼 Step 1: LLDB로 CPU 디버깅
@@ -383,7 +386,7 @@ Puzzle 01을 예제로 [네 가지 디버깅 조합](#네-가지-디버깅-조
 
 ### 디버거 실행
 
-JIT 컴파일로 LLDB 디버거를 시작합니다:
+소스에서 직접 LLDB 디버거를 시작합니다:
 
 ```bash
 # 한 단계로 p01.mojo를 컴파일하고 디버깅
@@ -407,10 +410,15 @@ Puzzle 01이 실행될 때 무슨 일이 일어나는지 추적해 봅시다.
 출력:
 
 ```text
-Breakpoint 1: where = mojo`main, address = 0x00000000027d7530
+Breakpoint 1: no locations (pending).
+WARNING: Unable to resolve breakpoint to any actual locations.
 ```
 
-디버거가 main 함수를 찾았고 거기서 실행을 일시 정지합니다.
+이것은 예상되는 동작입니다. `mojo debug your_program.mojo`로 실행하면 디버그
+세션이 시작될 때 프로그램이 컴파일되므로, 브레이크포인트를 설정하는 시점에는
+모듈이 아직 디버거에 로드되지 않았습니다. LLDB는 브레이크포인트를 보류 상태로
+등록하며 아직 구체적인 명령어 주소에 바인딩할 수 없습니다. 실행이 시작되고
+모듈이 로드되면 LLDB가 자동으로 브레이크포인트를 해결합니다.
 
 **Step 2: 프로그램 시작**
 
@@ -422,67 +430,22 @@ Breakpoint 1: where = mojo`main, address = 0x00000000027d7530
 
 ```text
 Process 186951 launched: '/home/ubuntu/workspace/mojo-gpu-puzzles/.pixi/envs/default/bin/mojo' (x86_64)
-Process 186951 stopped
-* thread #1, name = 'mojo', stop reason = breakpoint 1.1
-    frame #0: 0x0000555557d2b530 mojo`main
-mojo`main:
-->  0x555557d2b530 <+0>: pushq  %rbp
-    0x555557d2b531 <+1>: movq   %rsp, %rbp
-    ...
-```
-
-프로그램이 브레이크포인트에서 멈췄습니다. 현재 **어셈블리 코드**를 보고 있는데
-이는 정상입니다 - 디버거가 고수준 Mojo 소스에 도달하기 전에 저수준 머신 코드에서
-시작합니다.
-
-**Step 3: 시작 과정 탐색**
-
-```bash
-# 명령어 하나를 단계별 실행 시도
-(lldb) next
-```
-
-출력:
-
-```text
-Process 186951 stopped
-* thread #1, name = 'mojo', stop reason = instruction step over
-    frame #0: 0x0000555557d2b531 mojo`main + 1
-mojo`main:
-->  0x555557d2b531 <+1>: movq   %rsp, %rbp
-    0x555557d2b534 <+4>: pushq  %r15
-    ...
-```
-
-어셈블리를 단계별로 실행하는 것은 지루할 수 있습니다. 더 관련 있는 부분으로
-진행합시다.
-
-**Step 4: Mojo 소스 코드에 도달하기 위해 계속**
-
-```bash
-# 시작 어셈블리를 건너뛰어 실제 코드로 이동
-(lldb) continue
-```
-
-출력:
-
-```text
-Process 186951 resuming
 Process 186951 stopped and restarted: thread 1 received signal: SIGCHLD
 2 locations added to breakpoint 1
 Process 186951 stopped
-* thread #1, name = 'mojo', stop reason = breakpoint 1.3
-    frame #0: 0x00007fff5c01e841 JIT(0x7fff5c075000)`stdlib::builtin::_startup::__mojo_main_prototype(argc=([0] = 1), argv=0x00007fffffffa858) at _startup.mojo:95:4
+* thread #1, name = 'mojo', stop reason = breakpoint 1.2
+    frame #0: 0x00007fff5c01e841 JIT(0x7fff5c075000)`std::builtin::_startup::__mojo_main_prototype(argc=1, argv=0x00007fffffffa858) at _startup.mojo:119:5
 ```
 
-Mojo의 런타임이 초기화 중입니다. `_startup.mojo`는 Mojo의 내부 시작 코드를
-나타냅니다. `SIGCHLD` 시그널은 정상입니다 - Mojo가 내부 프로세스를 관리하는
-방식입니다.
+프로그램이 시작되면 보류 중이던 브레이크포인트가 **2개의 위치**로 해결됩니다 —
+하나는 `_startup.mojo`(Mojo의 내부 시작 래퍼)에, 다른 하나는 여러분의
+`p01.mojo`의 `main`에 위치합니다. LLDB는 첫 번째 히트인 시작 래퍼에서 멈춥니다.
+`SIGCHLD` 시그널은 정상입니다 — Mojo가 내부 프로세스를 관리하는 방식입니다.
 
-**Step 5: 실제 코드로 계속**
+**Step 3: 실제 코드로 계속**
 
 ```bash
-# 한 번 더 continue해서 p01.mojo 코드에 도달!
+# p01.mojo 코드에 도달하기 위해 continue
 (lldb) continue
 ```
 
@@ -491,25 +454,28 @@ Mojo의 런타임이 초기화 중입니다. `_startup.mojo`는 Mojo의 내부 
 ```text
 Process 186951 resuming
 Process 186951 stopped
-* thread #1, name = 'mojo', stop reason = breakpoint 1.2
-    frame #0: 0x00007fff5c014040 JIT(0x7fff5c075000)`p01::main(__error__=<unavailable>) at p01.mojo:24:23
-   21
-   22
-   23   def main():
--> 24       with DeviceContext() as ctx:
-   25           out = ctx.enqueue_create_buffer[dtype](SIZE)
-   26           out.enqueue_fill(0)
-   27           a = ctx.enqueue_create_buffer[dtype](SIZE)
+* thread #1, name = 'mojo', stop reason = breakpoint 1.1
+    frame #0: 0x00007fff5c014040 JIT(0x7fff5c075000)`p01::main() at p01.mojo:30:23
+   27
+   28
+   29   def main() raises:
+-> 30       with DeviceContext() as ctx:
+   31           var out = ctx.enqueue_create_buffer[dtype](SIZE)
+   32           out.enqueue_fill(0)
+   33           var a = ctx.enqueue_create_buffer[dtype](SIZE)
 ```
 
 이제 실제 Mojo 소스 코드를 볼 수 있습니다. 주목할 점:
 
-- p01.mojo 파일의 **21-27번 줄**
-- **현재 줄 24**: `with DeviceContext() as ctx:`
-- **JIT 컴파일**: `JIT(0x7fff5c075000)`은 Mojo가 코드를 즉석에서 컴파일했음을
-  나타냄
+- p01.mojo 파일의 **27-33번 줄**
+- **현재 줄 30**: `with DeviceContext() as ctx:`
+- **인프로세스 실행**: `JIT(0x7fff5c075000)` 접두사는 실행 중인 프로세스에
+  로드된 코드 영역에 대한 LLDB의 라벨입니다. `mojo debug your_program.mojo`로
+  실행하면, 컴파일된 프로그램이 디스크에 실행 파일을 쓰지 않고 인프로세스에서
+  실행됩니다 — 그래서 이 경로가 먼저 바이너리를 빌드하는 것보다 시작이 빠르고,
+  `your_program_debug` 파일이 생성되지 않습니다
 
-**Step 6: 프로그램 완료**
+**Step 4: 프로그램 완료**
 
 ```bash
 # 프로그램을 완료까지 실행
@@ -532,12 +498,12 @@ Process 186951 exited with status = 0 (0x00000000)
 
 **거쳐온 디버깅 여정:**
 
-1. **어셈블리로 시작** - 저수준 디버깅에서는 정상적인 현상이며, 디버거가 머신
-   수준에서 어떻게 작동하는지 보여줌
-2. **Mojo 시작 과정 탐색** - Mojo에 내부 초기화 코드가 있음을 학습
-3. **소스 코드 도달** - 구문 강조가 된 실제 p01.mojo 21-27번 줄 확인
-4. **JIT 컴파일 관찰** - Mojo가 코드를 즉석에서 컴파일하는 것을 관찰
-5. **성공적인 실행 확인** - 프로그램이 예상된 출력을 생성함을 확인
+1. **Mojo 시작 과정 탐색** - Mojo에 내부 초기화 코드가 있음을 학습 (브레이크
+   포인트가 두 위치로 해결되어 먼저 `_startup.mojo`에서 멈췄습니다)
+2. **소스 코드 도달** - 구문 강조가 된 실제 p01.mojo 27-33번 줄 확인
+3. **인프로세스 실행 관찰** - `mojo debug your_program.mojo`가 프로그램을
+   컴파일하고 디스크에 실행 파일을 쓰지 않고 바로 실행하는 것을 관찰
+4. **성공적인 실행 확인** - 프로그램이 예상된 출력을 생성함을 확인
 
 **LLDB 디버깅이 제공하는 것:**
 
@@ -567,7 +533,7 @@ CPU에서 일어나는 모든 것. 실제 GPU 커널 디버깅에는 다음 접
 
 ## 튜토리얼 Step 2: 바이너리 디버깅
 
-JIT 디버깅을 배웠으니 이제 프로덕션 환경에서 사용하는 **전문적인 접근법**을
+소스 디버깅을 배웠으니 이제 프로덕션 환경에서 사용하는 **전문적인 접근법**을
 탐색합시다.
 
 **시나리오**: 여러 파일이 있는 복잡한 애플리케이션을 디버깅하거나 같은
@@ -600,19 +566,19 @@ pixi run mojo debug solutions/p01/p01_debug
 
 **시작 비교:**
 
-| JIT 디버깅                         | 바이너리 디버깅            |
-|------------------------------------|----------------------------|
-| 한 단계로 컴파일 + 디버깅          | 한 번 빌드, 여러 번 디버깅 |
-| 느린 시작 (컴파일 오버헤드)        | 빠른 시작                  |
-| 컴파일 메시지가 디버그 출력과 섞임 | 깔끔한 디버거 출력         |
-| 디버깅 중 생성되는 디버그 심볼     | 고정된 디버그 심볼         |
+| 소스 디버깅                        | 바이너리 디버깅                |
+|------------------------------------|--------------------------------|
+| 한 단계로 컴파일 + 디버깅          | 한 번 빌드, 여러 번 디버깅     |
+| 느린 시작 (컴파일 오버헤드)        | 빠른 시작                      |
+| 컴파일 메시지가 디버그 출력과 섞임 | 깔끔한 디버거 출력             |
+| 기본 빌드 플래그                   | 명시적 `-O0 -g` 빌드 플래그    |
 
 **같은 LLDB 명령어**(`br set -n main`, `run`, `continue`)를 실행하면 다음과 같은
 차이를 느낄 수 있습니다:
 
 - **빠른 시작** - 컴파일 지연 없음
-- **깔끔한 출력** - JIT 컴파일 메시지 없음
-- **더 예측 가능** - 디버그 심볼이 실행 간에 변하지 않음
+- **깔끔한 출력** - 컴파일 메시지가 섞이지 않음
+- **더 예측 가능** - 빌드 플래그가 명시적이고 실행 간에 재사용됨
 - **전문적인 워크플로우** - 프로덕션 디버깅이 이렇게 작동함
 
 ---
@@ -660,11 +626,11 @@ GPU 디버깅이 근본적으로 다른 이유를 이해합시다:
 # 이미 실행했는지 확인 (한 번이면 충분)
 pixi run setup-cuda-gdb
 
-# JIT + CUDA-GDB 사용 (위의 접근법 2)
+# 소스 + CUDA-GDB 사용 (위의 접근법 2)
 pixi run mojo debug --cuda-gdb --break-on-launch solutions/p01/p01.mojo
 ```
 
-학습과 빠른 반복에 적합한 **JIT + CUDA-GDB 접근법**을 사용합니다.
+학습과 빠른 반복에 적합한 **소스 + CUDA-GDB 접근법**을 사용합니다.
 
 **Step 2: 실행하고 GPU 커널 진입 시 자동 정지**
 
@@ -1278,7 +1244,7 @@ GPU 디버깅 기초에 대한 포괄적인 튜토리얼을 완료했습니다.
 
 - ✅ LLDB로 **CPU 호스트 디버깅** - 장치 설정, 메모리 할당, 프로그램 흐름 디버깅
 - ✅ CUDA-GDB로 **GPU 커널 디버깅** - 병렬 스레드, GPU 메모리, 경쟁 상태 디버깅
-- ✅ **JIT vs 바이너리 디버깅** - 상황에 맞는 접근법 선택
+- ✅ **소스 vs 바이너리 디버깅** - 상황에 맞는 접근법 선택
 - ✅ pixi로 **환경 관리** - 일관되고 신뢰할 수 있는 디버깅 설정 보장
 
 **실제 병렬 프로그래밍 통찰**:
@@ -1295,8 +1261,8 @@ GPU 디버깅에 대해 읽기만 한 것이 아니라 **경험했습니다**:
 
 - **실제 코드 디버깅**: 실제 GPU 실행으로 Puzzle 01의 `add_10` 커널을
   디버깅했습니다
-- **실제 디버거 출력 확인**: LLDB 어셈블리, CUDA-GDB 스레드 상태, 메모리 주소를
-  직접 확인했습니다
+- **실제 디버거 출력 확인**: JIT 라벨이 붙은 프레임에서 LLDB 소스 정지,
+  CUDA-GDB 스레드 상태, 메모리 주소를 직접 확인했습니다
 - **전문 도구 사용**: 프로덕션 GPU 개발에서 사용하는 것과 동일한 CUDA-GDB를
   사용했습니다
 - **실제 시나리오 해결**: 범위 초과 접근, 경쟁 상태, 커널 실행 실패 문제를

book/i18n/ko/src/puzzle_09/puzzle_09.md

@@ -27,7 +27,7 @@ GPU 프로그래밍의 현실이 바로 이것입니다.
   수행할 수 있음
 - **여러 메모리 공간 탐색**: 전역 메모리, 공유 메모리, 레지스터, 상수 메모리
 - **조율 실패 처리**: 경쟁 상태, 배리어 교착 상태, 메모리 접근 위반
-- **최적화된 코드 디버깅**: JIT 컴파일, 변수 최적화, 제한된 심볼 정보
+- **최적화된 코드 디버깅**: 변수 최적화, 제한된 심볼 정보
 - **전문 도구 사용**: 커널 검사, 스레드 탐색, 병렬 상태 분석을 위한 CUDA-GDB
 
 **GPU 디버깅을 익히면 병렬 컴퓨팅의 기초를 깊이 이해하게 됩니다**.
@@ -66,7 +66,7 @@ GPU 프로그래밍의 현실이 바로 이것입니다.
 **기초 다지기** - 도구와 워크플로우 배우기
 
 - `pixi`와 CUDA-GDB로 디버깅 환경 설정
-- 네 가지 디버깅 접근법 배우기: JIT vs 바이너리, CPU vs GPU
+- 네 가지 디버깅 접근법 배우기: 소스 vs 바이너리, CPU vs GPU
 - GPU 커널 검사를 위한 필수 CUDA-GDB 명령어 학습
 - 이전 퍼즐의 익숙한 코드로 실습
 - 각 디버깅 접근법을 언제 사용해야 하는지 이해