컴파일 바이너리 라이선스: 설계 공간

2026-09-30 기준 상태: 이 글은 설계 탐색입니다. 글에서 설명하는 마켓플레이스, 라이선스 서버, 판매자 도구는 계획 단계로 아직 만들어지지 않았고, 출시일도 정해지지 않았습니다. 이를 떠받칠 엔진과 트랜스파일러는 지금 존재합니다.

전략 제작자는 소스를 넘기지 않고 수익을 내고 싶어 합니다. 구매자는 자기 데이터로 백테스트하고 자기 브로커에서 실행하고 싶어 합니다. 두 요구는 실제로 충돌하고, 지금 나와 있는 해법 대부분은 이 충돌을 잘 풀지 못합니다. 이 글은 PineForge 마켓플레이스의 기반으로 컴파일 바이너리 라이선스를 택하기 전에 우리가 탐색한 설계 공간을 정리합니다.

문제를 쉽게 말하면

전략 제작자가 제대로 작동하는 무언가를 만들었습니다. 몇 달 동안 파라미터를 다듬고, 엣지 케이스를 고치고, 표본 외 구간에서 검증까지 마쳤습니다. 이제 팔고 싶습니다. 구매자는 그 전략을 자기 데이터로 돌려 보고, 제작자가 말한 대로 백테스트되는지 확인하고, 자기 주문 실행 파이프라인에 연결하고 싶습니다.

제작자가 소스 코드를 넘기는 순간 수익화는 끝납니다. 구매자는 그 전략을 무기한 돌리고, 마음대로 고치고, 다른 사람에게 되팔 수 있습니다. 제작자가 얻는 건 딱 한 번의 판매입니다. 그 뒤의 구매자는 모두 놓친 잠재 고객입니다.

반대로 제작자가 소스 코드를 쥐고 있는 순간, 구매자는 전략을 검증하거나 튜닝하거나 신뢰할 수 없게 됩니다. 블랙박스를 구독하는 셈입니다. 제작자의 서버가 멈추면 구매자의 거래도 멈춥니다.

이 문제를 풀려는 흔한 해법이 두 가지 있습니다. 둘 다 어떻게 실패하는지 잘 알려져 있습니다.

패턴 1: 소스 판매

제작자가 Pine 스크립트를 직접 팝니다. 한 번 구매하면 구매자는 .pine 파일을 받습니다.

구매자에게 장점은 분명합니다. 완전한 접근, 완전한 검증 가능성, 완전한 통제권. 어떤 데이터로든 백테스트하고, 파라미터를 조정하고, 판매자와 상관없이 영원히 독립적으로 실행할 수 있습니다.

판매자에게 단점도 분명합니다. 소스가 한번 넘어가면 판매자에게 남는 지렛대가 없습니다. 불법 복제 방지는 구매자의 선의만큼만 강합니다. 전략은 다른 플랫폼에 다시 올라오거나, 수정되어 파생 상품으로 팔리거나, 그냥 무료로 공유될 수 있습니다. 수익은 정직한 첫 구매자의 수에서 멈춥니다.

지속적인 수익보다 단순함을 원하는 제작자에게는 맞는 모델입니다. 전략이 정말 가치 있어서 여러 해에 걸쳐 지키고 싶은 제작자에게는 맞지 않습니다.

패턴 2: 시그널 판매

제작자가 전략을 직접 돌리고, 진입·청산·포지션 크기 같은 시그널을 구독자가 받아 보는 피드로 내보냅니다. 소스는 제작자의 통제를 벗어나지 않습니다.

판매자에게 장점: 소스를 완벽하게 보호하고, 구독 수익이 계속 들어오며, 모든 가치를 한 번에 넘겨주는 거래가 없습니다.

구매자에게 단점은 심각합니다. 자기 데이터로 전략을 백테스트할 수 없습니다. 제작자가 주장하는 과거 성과를 믿는 수밖에 없습니다. 제작자의 인프라에 전적으로 의존하므로, 제작자가 휴가를 가거나, 서버 장애가 나거나, 서비스를 접기로 하면 구매자에게는 아무것도 남지 않습니다. 파라미터도 조정할 수 없고, 제작자가 설정한 그대로 받을 뿐입니다.

시그널 서비스는 직접 전략을 돌릴 기술적 역량이 없는 구매자에게 맞습니다. 무엇을 돌리는지 이해하고 독립적으로 검증하고 싶은 기술적인 구매자에게는 애초에 선택지가 되지 못합니다.

패턴 3: 컴파일된 바이너리 판매

세 번째 패턴이 PineForge가 계획 중인 마켓플레이스의 설계 중심입니다. Pine 전략을 공유 라이브러리(Linux에서는 .so, macOS에서는 .dylib)로 컴파일합니다. 제작자는 소스가 아니라 바이너리를 배포합니다. 구매자는 오픈 소스 PineForge 런타임을 통해 자기 머신에서 자기 OHLCV 데이터로 바이너리를 실행합니다.

이 방식은 충돌의 양쪽을 모두 해결합니다.

제작자 입장: 소스는 제작자의 머신을 떠나지 않습니다. 바이너리는 제작자의 Pine 스크립트로 컴파일되지만, 컴파일된 .so를 읽을 수 있는 Pine으로 되돌리려면 상당한 노력이 듭니다. 되돌리더라도 결과는 어셈블리 수준의 출력이지, Pine다운 코드가 아닙니다. 전략의 핵심 로직은 실질적으로 보호됩니다.

구매자 입장: 백테스트는 자기 데이터로 로컬에서 돌아갑니다. 주문 실행은 자기 브로커 연동을 씁니다. 오픈 소스 런타임은 감사할 수 있습니다. 보안에 신경 쓰는 구매자는 전략 자체는 읽지 못해도, 자기 돈을 굴리는 코드는 읽을 수 있습니다. 백테스트 자체는 판매자 서버에 의존하지 않습니다.

이 패턴은 PineForge가 처음 만든 것이 아닙니다. MetaTrader 생태계는 2011년 MetaQuotes가 MQL5 Market을 연 이후로 이 방식으로 운영되어 왔습니다. MetaTrader 전략은 .ex4나 .ex5 바이너리로 컴파일됩니다. Market은 구매 한 건 한 건을 구매자의 컴퓨터에 묶고, 활성화 가능 횟수는 판매자가 정합니다. 판매자는 상품을 대여 방식으로 내놓을 수도 있습니다. 구매자는 MetaTrader의 전략 테스터에서 로컬로 백테스트하고, 소스는 개발자에게 남습니다. 이미 검증된 모델입니다.

우리는 같은 플레이북을 Pine에 적용하되 두 가지를 더합니다. 하나는 더 세밀한 라이선스 조절 항목(아래에서 설명)이고, 다른 하나는 누구나 자기 거래를 실행하는 부분을 감사할 수 있도록 런타임을 오픈 소스로 두는 것입니다.

라이선스 차원

라이선스 체계가 없는 컴파일 바이너리는 누구나 복사할 수 있는 파일일 뿐입니다. 비즈니스 모델을 성립시키는 것은 라이선스 계층입니다.

설계에는 라이선스 차원이 여섯 가지 있습니다.

기간 제한. 라이선스에는 구매일로부터 며칠, 몇 주, 몇 달 같은 만료일이 있습니다. 라이선스가 만료되면 바이너리는 전략 실행을 멈춥니다. 구매자는 갱신할 수 있고, 판매자는 지속적인 수익을 얻습니다. 가장 흔한 차원이며, 거의 모든 마켓플레이스 전략이 쓰게 될 것입니다.

머신 바인딩. 라이선스가 하드웨어 지문에 묶입니다. 구매자는 등록한 머신에서는 전략을 실행할 수 있지만, 두 번째 머신이나 클라우드 인스턴스에서는 실행할 수 없습니다. 바이너리를 공유해 봐야 받은 쪽 머신에는 유효한 라이선스가 없으니 공유의 가치가 떨어집니다. 가벼운 공유보다 대규모 불법 복제를 더 걱정하는 판매자가 켤 수 있는 옵션입니다.

브로커 바인딩. 라이선스가 전략을 실행할 수 있는 브로커 연동을 지정합니다. 특정 브로커 API와 제휴한 판매자는 실행을 그 연동으로만 제한해, 지원하지 않거나 원치 않는 체결 장소에서 전략이 쓰이는 것을 막을 수 있습니다.

심볼 바인딩. 라이선스가 전략이 거래할 수 있는 티커 심볼을 제한합니다. BTC/USDT에서 전략을 만들고 검증한 제작자는 그 심볼만 허용하는 라이선스를 배포할 수 있습니다. 한 자산에 맞춰 최적화한 전략을 전혀 다른 자산에 써서 예상 밖의 결과를 얻고, 그 탓을 제작자에게 돌리는 일을 막아 줍니다.

입력 범위 제한. 구매자는 전략 파라미터를 조정할 수 있지만, 판매자가 허용한 범위 안에서만 가능합니다. 룩백 기간 파라미터가 있는 전략이라면 10~50봉 사이로만 설정하게 하고, 10 미만(제작자가 과적합이 심하다고 아는 구간)이나 50 초과(의미가 없어지는 구간)는 막을 수 있습니다. 판매자는 범위를 공개하고, 런타임은 그 범위를 강제합니다.

철회 가능. 라이선스 서버가 다음 정기 라이선스 확인에서 403을 반환하면, 그 시점에 바이너리는 실행을 멈춥니다. 구매자가 바이너리를 공유하거나 승인되지 않은 하드웨어에서 실행하는 등 약관을 위반한 것이 확인되면, 제작자는 환불이나 법적 절차 없이 라이선스를 철회할 수 있습니다. 철회는 최후의 수단이므로, 판매자는 명백한 위반에만 써야 합니다.

일부러 하지 않는 것

DRM식 난독화 쇼는 하지 않습니다. .so는 진짜 컴파일된 바이너리입니다. 시간이 충분하고 알맞은 도구가 있다면, 숙련된 엔지니어는 그 로직을 리버스 엔지니어링할 수 있습니다. 아니라고 주장하지 않겠습니다. 계약을 이루는 것은 라이선스이지 바이너리 형식이 아닙니다. 보호는 구매자가 동의한 약관과 런타임의 라이선스 집행에서 나오지, 디스어셈블이 불가능해서 생기는 것이 아닙니다. 바이너리를 뚫을 수 없는 척하는 건 정직하지 못한 일입니다.

백테스트마다 서버를 호출(phone home)하지 않습니다. 라이선스 확인은 호출마다가 아니라 주기적으로 합니다. 런타임은 유효한 라이선스를 로컬에 캐시하고, 정해진 주기(라이선스별로 설정 가능, 기본값은 하루 한 번)로 라이선스 서버를 확인합니다. 라이선스 유효 기간 동안은 오프라인에서도 백테스트가 됩니다. 봉을 계산할 때마다 서버를 호출하지도 않습니다. 그렇게 하면 백테스트가 네트워크 상태에 좌우되고 지연만 늘 뿐, 실질적인 보안 이득은 없습니다. 라이선스 확인 한 번을 가로챌 수 있는 공격자라면 백 번도 가로챌 수 있습니다.

깜짝 수익 배분은 없습니다. 마켓플레이스 수수료율은 출시 전에 공개하는 고정 비율입니다. 대기자 명단에 등록한 판매자는 상품을 올리기 전에 조건을 알 수 있습니다. 상품이 공개된 뒤에야 수수료 구조를 밝히는 마켓플레이스를 본 적이 있는데, 우리는 그것을 불성실한 행동으로 보고 하지 않을 것입니다.

아직 풀고 있는 질문들

라이선스 키 유출. 구매자의 머신이 침해되어 라이선스 키가 빠져나가면 어떻게 할까요? 선택지는 두 가지입니다. (a) 키를 철회하고 정당한 구매자에게 다시 발급한다. 이 경우 사용에 차질이 생깁니다. (b) 구매자별 키 로테이션 체계를 두고 머신 인스턴스마다 서로 다른 파생 키를 쓴다. 그러면 머신 한 대가 뚫려도 모든 구매자가 위험해지지 않습니다. 우리는 (b) 쪽으로 기울고 있지만, 구현하려면 만만치 않은 키 관리 요건을 풀어야 합니다.

범위와 함께 판매자가 정하는 입력 기본값. 입력 범위 제한 차원에서는 판매자가 파라미터마다 경계를 공개합니다. 그렇다면 판매자가 기본값, 즉 구매자가 전략을 처음 설정할 때 보게 되는 시작 값도 공개할 수 있어야 할까요? 아마 그럴 것입니다. 20봉 룩백에서 전략이 가장 잘 작동한다는 걸 아는 판매자가, 구매자에게 그걸 시행착오로 알아내게 할 이유는 없습니다. 기본값은 권장 사항일 뿐 강제되지는 않을 것입니다.

판매자가 공개하는 “데모 백테스트” 리포트. 구매자는 사기 전에 판매자의 주장만이 아니라 전략이 실제로 작동한다는 증거를 볼 수 있어야 합니다. 현재 계획은 판매자가 자기 데이터와 OHLCV 기간으로 갤러리 형식의 백테스트 리포트(/gallery의 갤러리와 같은 스키마)를 공개할 수 있게 하는 것입니다. 리포트는 명시된 입력으로 PineForge 엔진이 만든 것인지 검증을 거치게 됩니다. 구매자는 마케팅용 스크린샷이 아니라 실제 트레이드 목록, 실제 샤프 지수, 실제 스파크라인을 봅니다. “사기 전에 직접 확인하세요”의 정직한 버전입니다.

오픈 코어 정렬

컴파일 바이너리 마켓플레이스의 걱정거리 하나는 구매자 자금의 안전이 전적으로 바이너리 실행기에 달려 있다는 점입니다. 그리고 대부분의 구현에서 그 실행기는 독점 블랙박스입니다. MetaTrader에서 .ex5 파일을 실행한다면, MetaQuotes의 런타임과, 공개되지 않은 동작은 실행하지 않는다는 그들의 보증을 믿는 셈입니다.

PineForge 엔진은 Apache-2.0 라이선스로 공개되어 있습니다(pineforge-engine, 엔진과 트랜스파일러를 함께 담은 Docker 이미지는 ghcr.io/pineforge-4pass/pineforge-release). 트랜스파일러(Pine을 C++로 컴파일하는 부분)는 개인 트레이딩에는 무료이고, 상업적으로 쓰려면 라이선스가 필요합니다. 실행기, 즉 컴파일된 바이너리를 OHLCV에 대해 실제로 돌려 트레이드 목록을 만드는 코드는 오픈 소스입니다.

따라서 보안에 신경 쓰는 구매자는 백테스트를 맡기기 전에 실행기를 감사할 수 있습니다. 전략 소스는 감사할 수 없지만(그게 핵심입니다), 그 전략을 돌리는 코드는 감사할 수 있습니다. 이렇게 나눈 것은 의도적입니다. 전략을 돌리는 부분은 공개하고, 트랜스파일러는 상업적으로 쓸 때 라이선스를 받습니다.

마켓플레이스 현황

정해진 날짜는 없습니다. 엔진과 트랜스파일러는 지금 존재하지만, 라이선스 서버, 판매자 대시보드, 구매자 구매 흐름은 아직 없습니다.

계획은 판매자를 수동으로 온보딩하는 베타가 먼저입니다. 심사를 거친 소수의 제작자, 팀이 검토하는 상품 등록, 그리고 규모를 키우기 전에 연동 문제를 잡기 위한 제한된 카탈로그로 시작합니다. 그다음에는 셀프서비스 마켓플레이스가 이어질 것입니다. 판매자가 직접 상품을 등록하고, 라이선스 차원을 스스로 설정하고, 데모 백테스트 리포트를 공개하고, 팀의 개입 없이 카탈로그를 관리하는 형태입니다.

다음으로

• 판매자 대기자 명단 등록 — 마켓플레이스에 올리고 싶은 전략을 만들고 있다면 대기자 명단에 등록해 주세요. 베타 온보딩이 열리면 연락드리겠습니다.
• 지금 런타임 써 보기: MCP 서버의 backtest_pine은 마켓플레이스 전략이 돌아가게 될 것과 같은 엔진으로 실행됩니다.
• 패리티를 측정하는 방법: TradingView 대비 엔진의 현재 결과.