모든 피아노에 있는 이 버그

오늘 GeekNews 상단의 세 편은 접점이 없어 보입니다. 음악 이론, 개인 PC에서 돌리는 한국어 언어모델, 프론트엔드 상태 관리. 그런데 셋 다 같은 질문을 던집니다. 지금 당연하게 쓰는 규칙은 누가, 어떤 제약 아래에서, 무엇을 포기하며 정한 것인가.

모든 피아노에 남아 있는 23센트의 오차

소리는 시간에 따라 변하는 숫자다

악기를 다루지 못하는 개발자가 Web Audio API와 순수 자바스크립트만으로 음악 이론을 밑바닥부터 유도했습니다. 디지털 오디오는 초당 약 44,000번 스피커 콘의 위치를 지정하는 숫자 목록일 뿐이고, 440Hz라는 기준음조차 누군가 라(A)라고 부르기로 한 임의의 값입니다. 440Hz로 조율된 줄은 880, 1320, 1760Hz를 함께 내며 이 배음 배합비가 음색을 만듭니다. 옥타브가 같은 음으로 들리는 이유도 여기 있습니다. 한 옥타브 위 음의 배음은 이미 아래 음의 배음렬에 전부 포함되어, 새로운 소리 성분을 하나도 추가하지 않습니다.

고칠 수 없는 버그, 피타고라스 콤마

가장 깨끗한 비율인 3/2를 열두 번 쌓으면 출발음 220Hz가 아니라 222.99Hz에 도착합니다. 약 23센트, 피아노 인접 건반 간격의 4분의 1입니다. 수정이 불가능한 이유는 명확합니다. 5도 쌓기는 3의 거듭제곱, 옥타브는 2의 거듭제곱인데 둘 다 소수라 절대 같아지지 않습니다. 평균율은 순정 비율을 포기하고 옥타브를 2의 12제곱근으로 균등 분할한 타협이며, 완전5도를 0.1% 오차로 근사하는 최소 분할 수가 12라는 점도 15줄짜리 코드로 확인됩니다.

음계는 부분집합, 조표는 DRY

장음계는 [2,2,1,2,2,2,1]이라는 7원소 배열이고, 외우게 하던 선법은 같은 배열의 회전일 뿐입니다. 장3화음 [0,4,7]과 단3화음 [0,3,7]의 차이는 가운데 원소 하나이며, 밝음과 슬픔이라는 정서가 여기서 갈립니다. 로마 숫자 코드는 조에 독립적인 소스 코드이고 조옮김은 상수 덧셈이며, 조표는 헤더에 한 번만 선언하는 DRY 원칙입니다.

중학교 2학년이 설계한 1.09B 한국어 LLM

9GB 단일 GPU에 맞춘 학습 파이프라인

파이썬 기본 문법과 Pandas, Matplotlib 정도를 공부 중이라는 중학교 2학년 학생이 1.09B 파라미터 한국어 LLM 학습 파이프라인을 공개했습니다. Llama 3 계열을 따라 RMSNorm, SwiGLU, RoPE를 PyTorch 레이어로 구현했고, 9GB 단일 GPU에 맞추려 BF16 혼합 정밀도, bitsandbytes 8비트 AdamW, 그래디언트 체크포인팅과 누적을 적용했습니다. kullm-v2와 KoAlpaca-v1.1a 로드 시 standard에서 streaming, force_redownload로 이어지는 재시도 루틴을 넣고, matplotlib와 tkinter로 학습 루프와 UI 스레드를 분리한 실시간 채팅 테스트 화면까지 붙였습니다.

도구는 무료 웹 채팅 세 개

제작 방식이 더 눈길을 끕니다. 유료 툴이나 에이전트 없이 Claude, GPT, Gemini 무료 웹 창 세 개를 컨텍스트 제한이 걸릴 때마다 번갈아 쓰며 완성했습니다. 한계도 솔직합니다. 발열 탓에 250스텝마다 GPU를 잠시 쉬게 하는 꼼수를 넣었고, 장시간 프리트레이닝을 완주해 가중치를 뽑지는 못했습니다. 아이디어는 본인이 내고 코드는 AI가 썼다고 밝혔습니다.

프론트엔드 상태 관리, 아직 풀리지 않은 네 가지

지역과 전역 사이, 공유 상태

상태 관리 도구는 넘치는데 조명받지 못한 난제가 있다는 문제 제기입니다. 첫째, 공유 범위를 바꾸기 어렵습니다. 지역과 전역 둘로 분류되지 않는 공유 상태가 있고 그 범위는 계속 변하는데 기존 도구에는 다룰 방법이 없습니다. 둘째, 지역 상태를 전역으로 올리면 필요한 기간보다 오래 살아남아 reset, clean 로직이 등장합니다.

파생 상태의 유일성과 응집도

셋째, 훅은 같은 파생 계산을 재사용할 방법이 없고 useMemo나 useContext로 덮으면 다른 문제가 생깁니다. 부수효과가 끼면 해결책이 없습니다. 넷째, 훅 추상화로 하나의 기능처럼 보이게 해도 여러 곳에서 호출되면 같은 인스턴스로 작동하지 않고, useContext와 useEffect는 같은 기능의 코드를 멀리 흩뿌립니다. 저자는 넷이 하나의 문제라고 정리합니다. 공유 범위가 바뀌면 표현이 바뀌고, 공유 상태에는 자연스러운 수명이 없으며, 파생 상태의 유일성을 보장하기 어렵고, 그래서 기능 단위 응집도 어렵다는 것입니다.

관련 글

• 자바스크립트로 오디오 이펙터 만들기
• llm.c – raw C/CUDA로 LLM 훈련하기
• 8달러 마이크로컨트롤러에서 2,890만 매개변수 LLM 실행하기
• Past, Present, and Future of React State Management
• 리액트 useEffect: 개발자가 알아야 할 네 가지 팁

출처

1. 프로그래머를 위한 음악 이론 (runjs.app)
2. Show GN: 중2개발자가 만든 한국어 LLM (GitHub)
3. 프론트엔드 상태 관리의 네 가지 난제 (hackers.pub)
4. GeekNews