한선씨 브라우저 WASM 프론트엔드 (세션3-웹 2단계)

개요

한선씨로 작성한 프론트엔드를 브라우저에서 WASM으로 실행하는 경로를 확립·검증했다. 결론: DOM-opcode 직접 경로(crowny-wasm/wasm_emit)는 미성숙(트릿문자열·미배선)이라 폐기하고, toau2c→wasm32(실문자열) + 한선씨가 HTML 렌더 → 출력버퍼 → JS innerHTML 주입 경로가 오늘 동작한다. 상태(입력버퍼) 구동 상호작용까지 end-to-end 검증.

무엇을 했는지

1. 두 WASM 경로 평가 (실증)

• Path1 crowny-wasm(wasm_emit.c): TOAU→.wasm 직접, DOM import(dom_create 등) 존재하나 ① STR_NEW이 텍스트 바이트가 아닌 트릿인코딩 i64 1개 저장 → JS가 "div" 같은 텍스트 복원 불가, ② DOM 데모의 변수→DOM호출 배선 미완(main() import 0회 호출). 실 DOM 부적합 → 폐기.
• Path2 toau2c→wasm32(platform_wasm.c): 풀 C VM(runtime_mcu) → self-contained wasm, 실문자열 풀, 출력버퍼(wasm_out)+입력버퍼(wasm_in). 채택.

2. runtime_mcu(wasm/MCU 코어) 갭 보강

• 숫자변환(TOINT 486)·문자열변환(TOSTR 488)이 미구현(default no-op)이라 입력 구동 프론트가 행/오류 → 두 opcode 구현 추가(mcu/runtime_mcu.c). 라이브 crownyc.c 무관(toau2c/MCU 전용 코어).
• 문자열 한계가 MCU 크기(STR_POOL 4096B·문자열 128개·SCRATCH 128) → 페이지 빌더가 176B에서 고갈. #ifndef 가드를 wasm 빌드 플래그로 오버라이드(toau2c-wasm-build.sh: POOL 4MB·COUNT 32768·SCRATCH 16KB·OUT 1MB). MCU 기본은 작게 유지.

3. 데모 + glue

• 한선씨 apps/웹프론트_데모.한선: 입력(카운터 상태)→HTML 렌더(카드/카운터/리스트, UTF-8 한글). 출력 444B(count0)~537B(count3).
• 브라우저 web/한선프론트.html: ~25줄 JS glue(fetch wasm→instantiate→wasm_set_input(count)→wasm_run→innerHTML) + CSS + ± 버튼. 상태=JS 보관, 렌더=한선씨.
• 검증(node, 브라우저 동일 로직): 클릭 시퀀스 0→inc 1/2/3→dec 2→reset 0 모두 정확, 6회 재실행 풀 고갈 없음.

관련 파일

• 데모 한선씨: /Users/ef/CrownyOS/crownyc/apps/웹프론트_데모.한선
• 브라우저 하니스: /Users/ef/CrownyOS/crownyc/web/한선프론트.html + web/한선프론트.wasm
• 런타임 보강: /Users/ef/CrownyOS/crownyc/mcu/runtime_mcu.c (486/488), wasm/toau2c-wasm-build.sh (WEB_LIMITS)
• 빌드: sh wasm/toau2c-wasm-build.sh apps/웹프론트_데모.한선 web/한선프론트.wasm

잔여 이슈 / 다음 단계

• 이벤트 핸들러: 현재 상호작용은 JS가 상태 보관 + 재렌더(한선씨는 순수 렌더). 한선씨-측 이벤트 콜백은 DOM-opcode 경로 성숙 또는 콜백 디스패치 필요.
• wasm_reset이 문자열 풀 미리셋: 재실행 누적. 큰 풀로 데모는 무탈하나, 장수 SPA엔 str_count 리셋 추가 권장.
• DOM-opcode 경로: 진짜 증분 DOM(부분 갱신)을 원하면 toau2c가 790~ opcode를 출력버퍼에 DOM 명령스트림으로 직렬화 → JS 재생 방식 권장(VM/컴파일러 세션 협의).
• 세션3 3단계: 라우터/템플릿/CSS 생성기 + SPA 패턴(스타일.한선/뷰.한선).
• 세션3 4단계: 게이트웨이 결선(한선씨 HTTP서버[1단계]가 이 WASM 프론트 서빙) — 정적+바이너리(.wasm) 서빙 필요.