C.W.K.
Stream
Lesson 01 of 05 · published

Footprint 이 제품 요구사항이야

~12 min · tauri, electron, footprint, product-requirement, rust

Level 0툴 임차인
0 XP0/33 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"무거운 프로그램 옆에 하루 종일 열려 사는 앱은 자원 hog 일 수 없어. footprint 이 구현 디테일이길 멈추고 제품이 뭔지의 일부가 돼."

'가벼움' 이 선택이길 멈출 때

열고, 쓰고, 닫는 툴엔, 자원 footprint 이 거의 안 중요해 — 디테일이야. 근데 Cinder 는 사이드카야: 포토샵 옆에 창작 세션 내내, 한 번에 몇 시간씩 열려 있어, 포토샵 자체가 이미 진지한 메모리를 먹는 동안. 그 역할에선, footprint 이 나중에 최적화할 디테일이 아니야. 제품 정의의 일부야. 무거운 사이드카는 전체 셋업을 굼뜨게 느껴지게 하고, 아티스트가 조용히 안 열게 돼.

Electron 의 유혹

웹 기술로 크로스플랫폼 데스크톱 앱 짓는 친숙한 방법은 Electron 이야 — 모든 앱에 full 브라우저 엔진을 묶어. 잘 다져졌고, 잘 문서화됐고, 대부분의 개발자가 이미 알아. 그 친숙함이 진짜 끌림이야. 근데 각 Electron 앱이 자기 무거운 런타임을 싣고, 이미 무거운 호스트 옆 하루 종일 사이드카엔, 그 무게가 제품의 존재 이유를 직접 약화시켜.

비기능적 품질이 제품 목적에 핵심이면, 기능적 요구사항으로 다뤄. footprint, latency, 시작 시간 — 나중에 튜닝하는 '품질' 처럼 느껴져. 근데 제품의 전체 가치가 하나에 의존하면(가벼워야 하는 사이드카), 그 품질은 어떤 기능과도 동등한 요구사항이야. 승격시키고, 기술 선택을 veto 하게 둬.

Tauri 랑 진짜 Rust core

선택은 더 가벼운 native shell 이었어: 브라우저를 묶는 대신 운영체제 자기 web view 를 쓰는 framework, native 행동을 위한 진짜 Rust core 를 밑에. 그게 footprint 을 사이드카 역할을 존중할 만큼 작게 유지해. Rust core 는 장식이 아니야 — 윈도우 행동, 파일시스템 staging, 웹 전용 wrapper 가 나쁘게 처리하는 native 관심사를 소유해. shell 이 가볍고 그리고 native 레이어가 진짜야. 이걸 이해만 말고 직접 짓고 싶으면, Tauri Quest 가 native shell 을 처음부터 끝까지 걷고 Rust Quest 가 core 가 쓰인 언어를 가르쳐 — 이 레슨은 , 걔 둘은 어떻게.

더 어려운 툴 고르기는 선호가 아니라 요구사항으로 정당화돼. 더 가벼운 native 스택은 친숙한 것보다 배우는 데 더 들어. 그 비용은 footprint 요구사항이 진짜고 핵심이라서만 지불할 값어치 있어. 정당화는 'native 가 더 멋져' 가 아니라 — '제품이 가벼워야 하고, 이게 가벼움의 비용이야'. 어려운 선택을 그걸 요구하는 요구사항에 묶어.

정직하게 유지하는 fallback 룰

이 선택을 지키는 규율이 있어: 더 무겁고 친숙한 옵션은 더 가벼운 쪽의 진짜, 입증된 blocker 후에만 fallback 으로 허락돼 — 더 가벼운 게 낯설다는 이유로 절대 X 아님. 낯섦은 학습 비용이지 blocker 가 아니야. 이 룰이 '이거 어렵고 잘 몰라' 가 '이거 안 돼' 인 척하는 걸 막아. 더 가벼운 스택이 진짜로 필수적인 걸 못 하면, fallback 하고; 그냥 아직 안 배웠으면, 배워.

낯섦이 불가능으로 변장해. '이 툴이 X 를 못 해' 랑 '이 툴로 X 하는 법을 아직 몰라' 가 안에서 똑같이 느껴져, 특히 데드라인 압박 하에선. 친숙한 옵션으로 fallback 전에, blocker 가 진짜인지 입증해 — 네 지식의 틈이 아니라 실제 한계. 대부분의 '불가능' 이 '안 배움' 으로 드러나.

피파의 고백

모든 본능이 친숙한 무거운 framework 를 쓰라고 했어 — 알았고, 문서가 사방에 있었고, 빨리 움직일 수 있었어. 아빠가 선을 지켰어: 사이드카는 가벼워야 하고, '다른 거 이미 알아' 가 제품을 더 나쁘게 만들 이유가 아니라고. 더 가벼운 native 스택 배우는 게 진짜 마찰이었고, 난 그 마찰을 blocker 라 부르고 싶은 나를 잡았어. 아니었어. 그냥 학습이었어. 낯섦이 fallback 이유가 아니란 룰이 나 자신한테 정직하게 유지하게 했어.

Code

선택, 그리고 그걸 지키는 룰·text
결정: 하루 종일 사이드카를 위한 크로스플랫폼 데스크톱 shell.

  요구사항 (기능적으로 승격):
    이미 무거운 호스트 옆에 몇 시간 동안 가벼워야 함.

  옵션 A: 앱마다 full 브라우저 엔진 묶기 (친숙)
    + 다들 앎, 좋은 문서, 빨리 시작
    - 앱마다 무거운 런타임 -> 사이드카 존재 이유 약화

  옵션 B: OS web view + 진짜 native (Rust) core (덜 친숙)
    + 작은 footprint -> 요구사항 존중
    + 윈도우/파일시스템 행동을 위한 진짜 native 레이어
    - 학습 비용

  fallback 룰:
    B 의 입증된 blocker 에서만 A 로 fallback.
    'B 가 낯섦' 은 학습 비용, blocker 아님.

External links

Exercise

백그라운드에 늘 열려 있는 제품을 골라 (챗 앱, 음악 플레이어, 클립보드 매니저). footprint 이 네가 열어두는 이유의 일부야 — 아니면 닫을까 고민한 이유의 일부야? 그다음 친숙함 때문에 한 기술 선택을 골라 물어봐: 친숙한 옵션이 실제로 옳았어, 아니면 그냥 안전하게 느껴졌어?
Hint
질문의 정직한 버전: 더 잘 맞는 툴을 고르려면 뭘 배워야 했을지 나열하고, 그 학습 비용이 진짜 blocker 였는지 아니면 blocker 라고 다시 라벨한 불편함이었는지 물어봐.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.