빈 블로그도 솔직함입니다. 내보낼 글——Pine 의미론, 트랜스파일러 설계, 패리티급 백테스트에 대한 엔지니어링 심층——과 왜 서두르기보다 제대로 쓰기를 기다리는지.
이 글의 수치는 2026년 5월 7일에 측정한 값이며 당시 그대로 두었습니다. 최신 결과는 패리티 측정 방법에서 확인하세요.
이 글을 쓸 당시, 이 블로그는 일부러 비워 둔 상태였습니다.
2026년 5월의 PineForge 팀은 엔진 개발에 몰두하고 있었습니다. 패리티 스윕에 전략 162개를 돌렸고, 그중 158개가 트레이드 단위로 엄격하게 일치했으며, codegen은 당시 무료 호스팅 API로 제공되고 있었습니다. 마케팅 사이트가 먼저 올라갔고, 글은 그다음 순서였습니다.
앞으로 쓸 것
엔지니어링 글 몇 편을 준비해 두었습니다. 분위기만 내는 글보다는 재현 가능한 CSV, 나란히 비교할 수 있는 트레이스, 실제로 돌아가는 코드 같은 진짜 산출물을 붙여서 한 편씩 내고 싶습니다. 대략적인 로드맵은 이렇습니다.
-
트랜스파일러 아키텍처. Pine v6의 lexer / parser / analyzer가 C++ codegen으로 어떻게 이어지는지, 인터프리터 대신 AOT 컴파일을 고른 이유, 그리고 트랜스파일러가 어디서 끝나고 Apache-2.0 런타임이 어디서 시작하는지.
-
패리티 엔지니어링이라는 분야. TradingView와 트레이드 단위로 일치시키려면 실제로 무엇이 필요한지. 인프라(CI 스윕, 비교 하네스), 코퍼스 설계, 그리고 두 엔진이 정확히 봉 하나만큼 어긋날 때 쓰는 방법론.
-
전략을 컴파일된 바이너리로. 마켓플레이스 구상(계획 중, 일정 미정): 판매자가 라이선스 범위를 정하는
.so가 JSON으로 인코딩한 시그널 피드보다 왜 더 나은 배포 모델인지, 그리고 런타임이 백테스트할 때마다 서버에 확인 요청을 보내지 않고 라이선스 검사를 어떻게 처리할지. -
Optuna + 워크포워드 통합. 계획 중, 일정 미정. 옵티마이저가 UI에서 만드는 피트니스 슬라이더가 아니라 Python lambda 목적 함수를 받도록 하려는 이유, 그리고 모든 최적화 실행에 표본 외 검증을 어떻게 녹여 넣을지.
그동안에는
기다리지 않고 엔진부터 써 보고 싶다면:
글이 나오는 대로 이 목록도 늘려 가겠습니다. 뉴스레터 스팸은 보내지 않습니다. 읽을 가치가 있는 소식이 생기면 한 번만 보내겠습니다.