여기에 무엇을 쓸지
빈 블로그도 솔직함입니다. 내보낼 글——Pine 의미론, 트랜스파일러 설계, 패리티급 백테스트에 대한 엔지니어링 심층——과 왜 서두르기보다 제대로 쓰기를 기다리는지.
이 블로그는 일부러 비어 있습니다. 방치도 아니고 빈 마케팅도 아닙니다. 솔직함을 택한 겁니다. 엔지니어링인 척하는 소음보다 빈 페이지가 낫다고 보기 때문입니다.
PineForge 팀은 계속 엔진 안에 머물러 있습니다. 패리티 스윕 167개, 그중 165개는 엄격하게 트레이드 단위로 일치하고, codegen은 이미 무료 API로 나가 있습니다. 마케팅 사이트가 먼저 올라왔고, 긴 글은 나중에——문장만 던지지 않고 재현 가능한 근거를 붙일 수 있을 때 나옵니다.
앞으로 쓸 것
엔지니어링 글을 여러 편 줄 서 두었지만, 진짜 산출물 없이는 내지 않겠습니다. 누구나 다시 돌려볼 CSV, 나란히 놓은 트레이스, 당신 머신에서 도는 코드. 분위기용 글로 일정을 채우느니 기다려서 제대로 쓰겠습니다. 로드맵의 뼈대는 이렇습니다.
-
트랜스파일러 구조. Pine v6 lexer / parser / analyzer가 C++ codegen으로 어떻게 이어지는지. AOT 컴파일을 고른 이유(인터프리터가 아닌 이유). 독점 코어가 어디서 끝나고 Apache-2.0 런타임이 어디서 시작하는지.
-
패리티를 직업처럼. 참조 167개 중 165개에서 트레이드 일치를 만들려면 무엇이 필요한지——가차 없는 CI, 비교 하네스, 코퍼스 설계, 그리고 두 엔진이 딱 한 봉 어긋날 때의 방법(거기에 귀신이 붙는 경우가 많음).
-
전략을 컴파일된 바이너리로. 2027을 겨냥한 마켓플레이스 논지. JSON 시그널 피드보다 판매자가 정한 라이선스 범위가 붙은
.so가 왜 낫는지. 백테스트 매 바마다 집으로 전화하지 않는 라이선스 검증. -
Optuna + 워크포워드 통합. 2026년 Q3 예정. UI 피트니스 슬라이더 대신 Python lambda 목적함수로 옵티마이저를 노출한 이유. 매 최적화 런에 표본 외 검증을 넣어 숫자를 부풀리지 않기.
그동안에
엔진부터 쓰고 싶다면:
글 나오면 여기 목록도 늘립니다. 뉴스레터로 잔소리는 안 합니다. 볼 만할 때 한 번——그게 이 프로젝트가 유지하고 싶은 온도입니다.