현상에서 원리를 —
내가 추론하는 법

단편적인 사실에서 그럴듯한 인과를 즉석에서 구성하고,
검증해 진실에 다가간다.
식당에서든 데이터 앞에서든, 작동하는 엔진은 같다.

① LA갈비 — 지어낸 이야기 (미검증)

② 간짜장 — 추론이 사실로 (검증→적중)

③ 자동차 번호판 — 아들과 함께, 그리고 정련

못 읽는 메뉴판에서,
QR 주문 서비스까지

서버를 못 만든다는 한계 하나로
두 달간 잠적해 풀스택을 정복한 그 자세한 이야기

공부만 하던 어느 저녁, 밥을 먹으러 동네 식당에 들어갔다.
메뉴는 칠판에 적힌 태국어 꼬부랑 글씨뿐, 단 한 글자도 읽을 수 없었다.
관광지가 아니니 영어 메뉴도 사진도 없다.
뭘 파는 집인지도 모른 채, 손가락으로 아무거나 가리켰다.

나온 국수는 시쿰하고 맛이 없었다. 몇 젓가락 뜨다 내려놓고, 젓가락을 든 채 멍하니 생각했다.
아니, 왜 사진 메뉴가 없는 거야. 사진만 있어도 시킬 수 있을 텐데.

답은 금방 나왔다 — 인쇄와 갱신이 번거로워서다. 신메뉴 하나 넣을 때마다 다시 찍어야 하니까.
진짜 그런지 확인하고 싶어서, 그날부터 식당에 갈 때마다 메뉴판을 사진으로 모았다.
어딜 가나 같은 문제였다.
영어가 몇 단어 있으면 그나마 짐작이라도 할 수 있었지만.

해법은 머릿속에 이미 그려져 있었다. “테이블마다 QR만 붙인다.
스캔하면 사진 메뉴가 뜨고, 주문하면 점주 앱이 확인·결제한다. 신메뉴 등록도 사진 한 장.”
마침 손에는 막 배운 풀스택이 있었다. 그래서 그냥, 만들었다.
Sketch로 디자인을 그리고, React Native로 고객앱과 점주 관리앱을,
React·GraphQL·Apollo·Node로 백엔드를 세웠다.

실기기 데모까지 만들었다.

백종원 선생님을 찾아가고도 싶었다.
그 당시 방영하던 “백종원의 푸드트럭”에 적용하면 딱 맞을 서비스 같았다.
실제로 찾아가지는 못했지만,
이런 서비스가 우리나라에서 보편화된 건 그로부터 몇 년이 지난 뒤의 일이다.

데이터를 의심하는 법 —
배차 ML 연구 노트

좋은 숫자일수록 의심한다.
코드는 AI가 쓰고,
데이터를 피처로 빚는 직관과 검증은 사람이 한다.

“너무 좋은 결과는 의심하라”

AI가 흥분했다. “하차 피처가 압도적입니다. MAE가 1.03까지 내려갑니다.”
나는 베이스라인 1.70이 갑자기 무너진 게 눈에 걸렸다.
“너무 낮아지는데. 기준과 목표가 제대로 설정된 거 맞아?”
코드를 다시 뒤졌다. net_flow = trip − arrival —
타겟이 피처에 섞여 있었고, 미래 정보가 새고 있었다. 고치고 나니 1.27. 그게 정상값이었다.

상관 0.956이 “의심스럽게 높다” → 예언가가 아니라 nowcaster

모델 예측과 실측의 상관이 0.956 — 현장 작업자(0.77)보다 훨씬 높았다.
기뻐할 일 같지만, 곧장 누수 감사에 들어갔다.
분해해 보니 ‘멍청한 30일 평균’만으로도 0.988이 나왔다. 모델의 고유 예측력은 0.14~0.18뿐.
모델이 ‘먼저 아는’ 이유는 빨라서가 아니라, 작업자가 8주 늦어서였다.
거창한 예언가 행세를, 정직한 nowcaster로 격하시켰다.

shift(24) — 상식 한 줄로 잡은 버그

며칠간 모든 실험이 이상하게, 그것도 일관되게 안 풀렸다.
AI는 매번 ‘모델의 한계’라는 그럴듯한 해석을 내놨다. 나는 상식에서 멈췄다.
“날씨·시간 피처면 패턴이 더 모여야지, 왜 흩어져? 데이터 만드는 스크립트가 틀린 거 아냐?”
10분짜리 코드리뷰로 끝났다.
shift(24)는 ‘24시간 전’이 아니라 ‘24개 레코드 전’을 보고 있었다 —
희소한 데이터라 실제로는 9일 전 값, 오류율 79%.
모델이 중요하다고 꼽은 피처 Top4 중 3개가 이 버그였다.
모델은 노이즈를 외우고 있었던 것이다. 며칠치 모델을 전량 폐기했다.

KPI 자체를 갈아엎다 + 한계효용

AI가 ‘MAPE 16% 개선’을 ‘운영효율 16%’처럼 포장했을 때는, 목표 자체를 갈아엎었다.
수요예측 정확도가 아니라 스쿠터 대당 하루 트립(TPD)의 최대화 —
예측이 아니라 가치가 목적이니까.
‘평균 매력도 상위 k곳’ 배치가 강남역 몰빵을 불렀을 때는 엔진을 다시 설계했다.
한 대를 놓고, 그다음 한 대를 어디 둘지 다시 계산하라 — 한계효용의 문법으로.

손실이 만든 피처 —
주식 자동매매 연구 노트

잃어본 사람만이 피처의 ‘의미’를 안다.
어림잡기와 검증 본능이 만나는 곳.

손실이 곧 도메인 지식

도서관에서 빌린 책 서너 권으로 용어부터 익혔고, 유료 강의도 들었다.
그러고도 차트와 지표만 보며 잡주로 오래 잃었다. 그런데 그 수업료가 사라지지 않았다.
지금 매매엔진이 학습하는 57개 피처의 의미를 아는 건, 전부 잃어본 자리이기 때문이다.
MACD·RSI·볼린저·MFI를 다루는 건 기본이고, 보조지표의 이동평균까지 직접 고안한다.
지표를 소비하지 않고, 짓는다.

“모든 지표는 매매자의 심리다” — 표현학습을 스스로 도출

처음엔 회의적이었다. 끝난 차트로 미래를 어떻게 안다는 건가. 그러다 생각이 뒤집혔다.
모든 지표엔 매매자들의 손절과 익절, 본전 탈출의 심리가 응축돼 있고,
눈에 안 보이는 그 잠재 패턴을 ML이 뽑아낸다.
“마치 딥러닝처럼. 피처가 몇십 개라도 결국 그 방식이지.”
표현학습(latent feature)이라는 개념을, 강의가 아니라 내 매매로 직관한 셈이다.

좋은 숫자를 스스로 사형하다

프로젝트 첫날, 백테스트가 연간 수익률 400%를 찍었다. 환호 대신 코드를 뜯었다.
신호와 시뮬레이션의 인덱스가 252봉쯤 어긋나, 미래를 보고 매수하고 있었다. 즉시 거짓 판정.
종가베팅 전략이 leak 검증을 통과한 뒤에도 미시구조까지 파고들었고,
이기는 종목의 73%가 상한가에 잠겨 살 수 없는 종목이라는 걸 적발했다.
전수 leak 감사로 알파의 82%가 사라졌다. 그래도, 진실을 택했다.

라이브 대시보드

보유·수익

종목 AI 추론

매매 신호

차트·지표

‹

›

두 원과 픽셀의 밑그림 —
필기엔진 연구 노트

200MHz 기계에서, 지연 없는 매끄러운 획을.
원리는 배웠고, 나머지는 직접 풀어야 했다.

문제는 하나였다. 포켓PC의 CPU는 200MHz. 부동소수점은 느리고, GPU는 없다.
그 위에서 펜이 움직이는 대로, 지연 없이, 계단 없는 매끄러운 획을 그려야 한다.
참고할 라이브러리는 없었다. 종이에 원 두 개를 그리는 데서 시작했다.

모든 픽셀에, 거리를 묻는다

발상은 이렇다. 스캔라인이 지나가는 픽셀마다
“너는 이 캡슐에서 얼마나 떨어져 있나”를 묻고, 그 거리로 알파를 정한다.
경계에 걸친 픽셀은 거리만큼 옅어지니, 계단이 사라진다.

// 픽셀에서 획까지의 거리가, 곧 그 픽셀의 알파가 된다
fxDistGap = fxWidth - (fxCurDist * 2.0);
blendProc(pDibBlock, pBackBlock, pCurMaskBlock, fxDistGap, ...);

훗날 알게 된 이름으로, 이것은 Signed Distance Field 렌더링이다.
Valve가 논문으로 발표한 게 2007년 — 이 코드는 그보다 몇 년 앞서,
GPU가 아니라 200MHz CPU 위에서 돌고 있었다.

백미 — 픽셀당 덧셈 한 번

거리 계산엔 곱셈과 나눗셈과 제곱근이 든다. 픽셀마다 하면 200MHz가 못 버틴다.
그래서 쥐어짰다. 한 행 안에서 x가 1씩 갈 때 직선까지의 거리는 늘 같은 양만큼 변한다 —
그 변화량을 미리 유도해 두면:

if (fxDistForLine == 0)
{   // 행의 첫 픽셀만 점-직선 거리 공식으로 계산하고
    fxDistForLine = (((fxCY * (fxBlockX - ptStart.x))
                    + (fxCX * fxBlockStartGap)) / fxDistCXCY);
}
else
{   // 그다음부터는 — 픽셀당 덧셈 한 번
    fxDistForLine += fxDistGapForX;
}

제곱근도 곱셈도 루프 밖으로 쫓겨났다. Bresenham이 정수 직선에서 쓴 증분의 사고를,
거리장 위에 옮겨 얹은 것이다.
스캔라인의 시작·끝 위치도 같은 증분으로 굴러간다 —
픽셀 하나의 비용이 공짜에 가까워질 때까지.

형광펜이 얼룩지지 않는 이유

반투명 획엔 조용히 어려운 문제가 하나 있다.
획은 짧은 마디들의 연속이라 마디끼리 겹치는데, 겹친 자리가 두 번 칠해지면 형광펜에 얼룩이 진다.
답은 픽셀마다 ‘지금까지 칠해진 최대 농도’를 기억하는 마스크 버퍼 —
그리고 이미 칠해진 픽셀의 농도를 올릴 때의 보정식이다.

if (bPercent > bMaskBlock)   // 이미 칠한 농도보다 진할 때만
{
    int bMaskGap = (bPercent - bMaskBlock);
    *(pBufferBlock) = (blue - bufferBlue) * bMaskGap / _bMaskBlock + bufferBlue;
    ...
    *pMaskBlock = bPercent;  // 커버리지 갱신 — 얼룩은 여기서 죽는다
}

이 보정식은 알파 합성 대수를 거꾸로 풀어야 나온다. 논문에는 없는 문제다 —
필기 앱을 실제로 출시해서, 형광펜으로 얼룩을 만들어 본 사람만 아는 문제니까.

정직한 좌표

거리 기반 안티알리아싱은 학계에 있었다 — Gupta-Sproull, 1981.
나도 알고는 있었다. 컴퓨터그래픽스 수업에서 배웠으니까.
그 원리를 어느 정도 알고 시작했다.
다만 어디까지가 배운 것이고 어디서부터가 내 생각인지,
20년이 지난 지금은 나도 가려낼 수 없다.
분명한 것은 수업과 논문이 원리까지였다는 것,
그리고 200MHz 위에서 지연 없이 돌게 만드는 일과
형광펜의 얼룩 같은 제품의 문제는 거기 없었다는 것이다.
그 엔진이 포키패드가 되고, 10년 뒤 UPAD가 됐다.

그리고 이것이, 그 모든 수식이 화면에 도착한 모습이다.
2008년 포키패드 매뉴얼에 직접 그려 넣은 소개 컷 —
확대경 안에 픽셀 단위로 옅어지는 가장자리가 보인다.
‘보다 빠르고’는 픽셀당 덧셈 한 번이, ‘부드러운’은 거리로 정한 알파가,
글자 밑의 노란 형광펜은 마스크 버퍼가 만든 것이다.

확대해도 깨지지 않는 데는 이유가 하나 더 있다. 이 엔진은 화면에 찍힌 픽셀을 저장하지 않는다.
획을 점과 폭의 데이터 — 벡터로 들고 있다가,
배율이 바뀔 때마다 방금 그 수식으로 처음부터 다시 그린다.
매뉴얼의 세 컷이 그 증명이다 — 같은 획을 아무리 당겨도, 가장자리는 계속 매끄럽다.
그때 나는 이 엔진이 세상에서 가장 빠르다고 생각했다.
입 밖에 낸 적은 없지만.

로컬 퍼스트가 DB 엔진이 되기까지 —
monolog 연구 노트

제목 없는 채팅 한 줄 뒤에서 벌어진 일 —
시간을 품은 UID, 손바닥 위의 페이지네이션,
그리고 40여 개 언어와 1,600장의 스크린샷.

시간을 품은 UID

monolog는 로컬 퍼스트다. 네트워크가 없어도 기록은 즉시 저장되고,
연결이 돌아오면 서버와 맞춰진다. 이 구조가 성립하려면 첫 단추가 하나 있다 —
오프라인의 기기들이 서버에 묻지 않고 각자 ID를 만들어도,
나중에 합쳤을 때 충돌하지 않고 시간순이 유지되어야 한다는 것.
그래서 메시지의 UID에 처음부터 시간 정보를 넣어 설계했다.
ID를 정렬하면 그게 곧 타임라인이 되도록.

서버가 하던 일을, 손바닥 위에 다시 짓다

로컬 퍼스트를 끝까지 밀면 청구서가 온다.
서버의 Postgres가 하던 검색과 페이지네이션을, 이제 손안의 메모리에서 직접 해야 한다.
메시지를 노드로 들고, 로드된 구간과 안 된 구간의 경계를 표시하고 —
끊어진 자리를 잇는 장치에는 Splitter라는 이름을 붙였다 —
10년 전 날짜로 점프했다가 다시 현재로 돌아오는 이동을 감당해야 한다.
‘다음 페이지가 있는가’라는 단순해 보이는 질문조차 까다로웠다.
로컬 캐시는 “내가 더 갖고 있다”만 알 뿐, “서버에 더 있는지”는 모른다. 그래서 원칙을 세웠다.
그 답의 권한은 서버에만 있다. 로컬은 ‘있다’고 올릴 수만 있고, ‘없다’고 내릴 수는 없다.

메모리에 얼마를 남기고 얼마를 버릴지도 전부 직접 정했다.

// 한 번에 100개를 부르고, 화면 주변에 500개까지 들고, 3,000개까지 캐시한다
DEFAULT_LOADING_MESSAGE_COUNT = 100;
MAX_LOADED_MESSAGE_COUNT      = 500;
MAX_MESSAGE_CACHE_COUNT       = 3000;

그렇게 커서와 경계 노드, 캐시 정책, 정합성 규칙을 하나씩 쌓고 나서야 알았다.
이 구조, 실제 데이터베이스 엔진이 안에서 하는 일과 같다.

AI 셋이 서로의 번역을 검증하다

40개 언어는 한 번 번역해서 끝나는 일이 아니었다. 파이프라인을 고정했다 —
Gemini가 초벌을 하고, GPT가 리뷰하고, Gemini가 수정하고, Claude가 최종 중재한다.
세 AI의 교차검증을 돌리자 기존 번역 287개 키 가운데 274개가 고쳐졌다. 95.5%다.
이탈리아어 자리에 영어가 들어가거나 키릴 문자 언어에 라틴 문자가 섞이는 실패는
자동으로 감지되게 만들었고, 공지 240건은 자소 단위로 직접 검수했다 —
여섯 개 언어에서만 마크업 앞 관사를 제거하고, 번체 중국어의 您은 你로 바꿔 톤을 데웠다.

그 홈페이지들은 지금도 전부 열려 있다 — 언어를 누르면 그 언어의 monolog 홈페이지가 열린다.

1,600장의 스크린샷

40개 언어가 실제 화면에서 제대로 보이는지는 번역 파일만으로 알 수 없다.
그래서 앱을 언어별로 자동 구동해 언어당 40장씩,
1,600장의 스크린샷을 찍는 도구를 만들었다.
그 화면들을 한 장 한 장 — 번역이 맞는지, 레이아웃이 깨지지 않는지,
오타가 없는지 — LLM과 함께 검수했다.
스토어에 올릴 스크린샷과 설명은 따로 제작해,
Apple과 Google 양쪽 스토어에 단일 커맨드로 올리는 업로드 도구까지 만들었다 —
실수로 일부만 올려 기존 세트를 날리는 사고까지 도구가 막아준다.