창간 Vol와 첫 하드웨어 증거가 나간 뒤의 한 주. Signal의 결이 조금 달라졌다 — 이전이 "그게 되나"였다면, 이번 주는 "그럼 우리 경우엔?"이 많았다.
이번 주 Signal
"우리 업종도 되나"가 들어오기 시작했다. 패널 업체가 HMI를 30분에 얹은 글이 나간 뒤, 가장 많이 받은 반응은 칭찬이 아니라 대입이었다. "우리는 계측기를 만드는데", "우리는 센서 모듈인데", "우리는 키오스크인데 — 같은 식으로 되나?" 좋은 Signal다. 증거의 목적은 감탄이 아니라 "내 경우로 바꿔 생각하게 만드는 것"이니까. 이 연재가 업종을 하나씩 늘려 가는 이유이기도 하다.
첫 화면을 띄운 사람들이 생겼다. 코딩 글을 따라 화면 하나를 띄워 본 독자들의 짧은 후기가 들어온다. 공통점이 인상적이다 — 거의 모두가 "빌드를 기다리는 단계가 없는 게 제일 낯설었다"고 말한다. 익숙한 비용이 사라지면, 그 빈자리가 오히려 어색하게 느껴진다. 그 어색함이 이 전환의 가장 정직한 증거다.
"서버가 화면을 정의하면 느리지 않나"라는 오해. 이번 주 가장 자주 정정한 오해다. 매 순간 서버를 부른다는 그림에서 온 걱정인데, 실제로는 화면 정의만 오간다 — 무거운 코드 번들이 아니라 "버튼 하나, 텍스트 하나"짜리 가벼운 명세다. 게다가 한 번 받은 정의는 캐시된다. 정작 무거운 그리기 엔진은 이미 기기에 네이티브로 있다. 체감 성능은 네이티브 그대로다.
도구·패키지 메모
이번 주의 메모는 상태에 관한 것. 화면에 값을 묶을 때, 초보가 가장 자주 막히는 지점은 "값이 바뀌었는데 화면이 안 바뀐다"이다. 거의 항상 원인은 같다 — 화면을 직접 고치려 들었기 때문이다. 서버 정의 방식에서는 화면을 고치는 게 아니라 상태를 고친다. 상태가 바뀌면 거기에 묶인 자리가 알아서 따라온다. "다시 그려라"라고 명령하지 않는다. 이번 Vol 코딩 둘째 글이 정확히 이 지점을 다룬다.
짧은 생각
"30분"이라는 숫자에 대해. 그 숫자의 절반 이상은 빌드를 기다리지 않아도 됐기 때문에 생긴 여유다. 우리가 흔히 "개발 시간"이라 부르는 것의 상당 부분은 사실 기다리는 시간이다 — 컴파일, 굽기, 심사, 배포. 만드는 행위 자체가 아니라 만든 것이 도달하기를 기다리는 시간. 그 기다림이 0에 가까워지면, 같은 사람이 같은 손으로 훨씬 멀리 간다. 빨라진 건 타이핑 속도가 아니라 시도와 확인 사이의 호흡이다.
현장에서
한 독자가 보내온 한 줄이 오래 남았다. "버튼 색을 바꾸고 저장했더니, 다른 방에 있던 태블릿 화면이 그냥 바뀌어 있었다. 아무것도 안 했는데." 이 매거진이 길게 설명한 것을, 그는 한 문장으로 요약했다.
이번 주 질문
당신의 일에서 "한 번 만들면 끝"이 아니라 "계속 다듬어야 하는" 화면은 무엇인가. 가격표, 메뉴판, 상태 보드, 설정 화면처럼 자주 바뀌는 것들. 그런 자리일수록 굽지 않고 정의하는 방식의 이득이 크다. 다음 주에는 그 "자주 바뀌는 화면"을 다루는 도메인 사례를 짚는다.
makemind.dev 「소식」 — 1월 셋째 주. "우리 업종도 되나"라는 물음에 숫자로 답하며.