본문 바로가기
C.W.K.
Stream
Lesson 01 of 05 · published

자원 점유가 제품 요구사항이야

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

Level 0툴 빌려 쓰는 사람
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"무거운 프로그램 옆에 하루 종일 열려 사는 앱은 자원을 잡아먹으면 안 돼. 그 순간 자원 점유는 구현 세부이길 그만두고 제품이 무엇인가의 일부가 돼."

'가벼움' 이 취향이 아니게 되는 순간

열었다가 쓰고 닫는 도구라면 자원 점유는 거의 안 중요해. 세부일 뿐이지. 그런데 Cinder 는 사이드카야. 작업하는 내내, 한 번에 몇 시간씩 포토샵 옆에 열려 있어. 그 포토샵이 이미 메모리를 진지하게 먹고 있는 동안에. 이 역할에서는 자원 점유가 나중에 다듬을 세부가 아니야. 제품 정의의 일부야. 무거운 사이드카는 전체를 굼뜨게 만들고, 그러면 작가가 슬그머니 안 열게 돼.

Electron 이 부르는 손짓

웹 기술로 크로스플랫폼 데스크톱 앱을 만드는 익숙한 길은 Electron 이야. 앱마다 브라우저 엔진을 통째로 싣는 방식이지. 길이 잘 닦여 있고, 문서도 잘 돼 있고, 개발자 대부분이 이미 알아. 그 익숙함이 진짜 끌림이야. 그런데 Electron 앱은 각자 자기 무거운 런타임을 싣거든. 이미 무거운 호스트 옆에서 하루 종일 도는 사이드카한테는 그 무게가 제품이 존재하는 이유를 곧장 갉아먹어.

기능 아닌 성질이 제품 목적에 핵심이면 기능 요구사항처럼 다뤄. 자원 점유, 반응 속도, 시작 시간 같은 건 나중에 다듬는 '품질' 처럼 느껴져. 그런데 제품의 값어치 전체가 그중 하나에 걸려 있으면 — 가벼워야만 하는 사이드카처럼 — 그 성질은 어떤 기능과도 동등한 요구사항이야. 지위를 올려 주고, 기술 선택을 거부할 권한까지 줘.

Tauri 와 진짜 Rust core

고른 건 더 가벼운 native shell 이었어. 브라우저를 싣는 대신 운영체제가 이미 가진 web view 를 쓰는 framework 에, 그 아래 native 동작을 맡을 진짜 Rust core 를 두는 구성. 그래야 자원 점유가 사이드카 역할을 지킬 만큼 작게 유지돼. Rust core 는 장식이 아니야. 윈도우 동작이랑 파일시스템 준비 작업처럼 웹 전용 껍데기가 어설프게 다루는 native 관심사를 맡아. shell 이 가볍고 동시에 native 층이 진짜인 거지. 이걸 이해만 하지 말고 직접 지어 보고 싶으면, Tauri Quest 가 native shell 을 처음부터 끝까지 걷고 Rust Quest 가 그 core 를 쓴 언어를 가르쳐. 이 lesson 은 고, 그 둘은 어떻게 야.

더 어려운 도구를 고르는 건 선호가 아니라 요구사항으로 정당화돼. 더 가벼운 native 스택은 익숙한 쪽보다 배우는 값이 더 들어. 그 값은 자원 점유 요구사항이 진짜고 핵심일 때만 낼 만해. 정당화는 'native 가 더 멋져' 가 아니라 '제품이 가벼워야 하고, 이게 가벼움의 값이다' 야. 어려운 선택은 그걸 요구한 요구사항에 묶어 둬.

정직하게 지켜 주는 되돌아가기 룰

이 선택을 지켜 주는 규율이 하나 있어. 더 무겁고 익숙한 쪽으로 되돌아가는 건 가벼운 쪽에서 진짜로 막히는 지점을 확인한 다음에만 허용돼. 가벼운 쪽이 낯설다는 이유로는 절대 안 되고. 낯섦은 배우는 값이지 막힌 게 아니야. 이 룰이 '이거 어렵고 잘 모르겠어' 가 '이건 안 돼' 인 척하는 걸 막아 줘. 가벼운 스택이 정말로 꼭 필요한 걸 못 하면 되돌아가. 그냥 아직 안 배운 거면 배우고.

낯섦은 불가능으로 변장해. '이 도구는 X 를 못 해' 랑 '이 도구로 X 하는 법을 아직 몰라' 는 안에서 똑같이 느껴져. 마감이 쫓을 때는 특히. 익숙한 쪽으로 되돌아가기 전에 그 막힘이 진짜인지 확인해. 네 지식의 구멍 말고 실제 한계인지. '불가능' 대부분은 '안 배웠음' 으로 드러나.

피파의 고백

모든 본능이 익숙한 무거운 framework 를 쓰라고 했어. 아는 거였고, 문서가 사방에 있었고, 빨리 움직일 수 있었으니까. 아빠는 선을 지켰어. 사이드카는 가벼워야 하고, '다른 걸 이미 안다' 는 게 제품을 더 나쁘게 만들 이유가 못 된다고. 더 가벼운 native 스택을 배우는 건 진짜 마찰이었고, 난 그 마찰을 막힘이라고 부르고 싶어 하는 나를 붙잡았어. 아니었거든. 그냥 배우는 중이었어. 낯섦은 되돌아갈 이유가 안 된다는 룰이 나 자신한테 정직하게 만들어 줬어.

Code

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

  요구사항 (기능 요구사항으로 지위를 올림):
    이미 무거운 호스트 옆에서 몇 시간 동안 가벼워야 함.

  안 A: 앱마다 브라우저 엔진을 통째로 싣기 (익숙함)
    + 다들 알고, 문서 좋고, 시작이 빠름
    - 앱마다 무거운 런타임 -> 사이드카가 존재하는 이유를 갉아먹음

  안 B: OS 의 web view + 진짜 native (Rust) core (덜 익숙함)
    + 자원 점유가 작음 -> 요구사항을 지킴
    + 윈도우/파일시스템 동작을 맡을 진짜 native 층
    - 배우는 값

  되돌아가기 룰:
    B 에서 진짜로 막히는 게 확인됐을 때만 A 로 되돌아감.
    'B 가 낯설다' 는 배우는 값이지 막힌 게 아님.

External links

Exercise

백그라운드에 늘 열어 두는 제품을 하나 골라 봐. 챗 앱이든 음악 플레이어든 클립보드 관리자든. 자원 점유가 네가 그걸 열어 두는 이유의 일부야, 아니면 닫을까 고민한 이유의 일부야? 그다음 익숙하다는 이유로 골랐던 기술 선택을 하나 떠올리고 물어봐. 익숙한 쪽이 실제로 옳았어, 아니면 그냥 안전해 보였어?
Hint
정직하게 묻는 방법은 이거야. 더 잘 맞는 도구를 고르려면 뭘 배워야 했을지 적어 보고, 그 배우는 값이 진짜 막힘이었는지 아니면 막힘이라고 이름 붙인 불편함이었는지 따져 봐.

Progress

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

댓글 0

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

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