코드 없는 맞춤형 스캐너 빌더란 무엇인가
맞춤형 스캐너 빌더는 탐지 엔진, 지표, 맥락 필터를 하나의 논리 조건으로 묶는 코드 없는 도구다. 필요한 요소를 고른 뒤 AND와 OR로 연결하면 플랫폼이 조건에 해당하는 모든 시장을 검사하고, 내가 정한 규칙이 정확히 맞을 때만 알림을 보낸다.
고정형 스캐너와의 차이는 통제권이다. 일반 스캐너는 제작자가 정의한 하나의 설정을 제공한다. 반면 빌더는 기본 재료를 건네고, 실제로 거래하는 설정을 직접 조립하게 한다. LiquidityScan에서는 이 기능이 Scanner Studio로 제공되며, 여러 사람이 공유하는 Confluence 카탈로그는 Studio에서 만든 스캐너를 모두에게 공개한 목록이다.
모든 트레이더의 엣지에 맞춤형 빌더가 필요한 이유
꾸준히 거래하는 트레이더라도 같은 조건을 찾지는 않는다. 어떤 사람은 1H에서 Change of Character(CHoCH)가 나온 뒤 London kill zone 안에서 강한 order block retest를 기다린다. 다른 사람은 더 높은 시간 프레임에서 liquidity sweep과 reclaim이 나온 종목 중 실제 거래량이 붙은 경우만 찾는다. 서로 다른 지표를 쓰는 게 아니다. 같은 블록을 서로 다르게 조합하는 것이다.
고정형 스캐너로는 이 차이를 담을 수 없다. 스캐너가 가진 하나의 패턴만 울리고, 나머지 confluence는 수백 개 차트를 직접 보며 확인해야 한다. "패턴이 나왔다"와 "내 전체 설정이 갖춰졌다" 사이의 간극을 메우는 장치가 바로 맞춤형 스캐너 빌더다. 체크리스트 일부가 아니라 전부를 규칙으로 옮긴다.
자리를 비운 날에는 차이가 더 크게 난다. "1H CHoCH" 하나만 알림으로 걸어두면 휴대폰이 수십 번 울리지만, 그중 실제 거래 조건에 맞는 경우는 거의 없다. retest, 세션, 거래량까지 맞아야 하기 때문이다.
조건을 모두 코드화하면 도착한 알림 자체가 1차 검증을 마친 상태가 된다. 그때부터 알림을 확인하는 데 드는 비용은 아직 처음부터 검토해야 하는 차트의 가치가 아니라, 실제 설정에 가까워진 후보를 보는 비용에 가까워진다.
- 구체성: 엣지는 보통 조건 하나가 아니라 3-5개를 겹쳐 만든다.
- 범위: 하나의 규칙은 시장 전체를 동시에 검사하지만, 사람의 눈은 그렇지 못하다.
- 규율: 정리된 규칙은 매번 같은 방식으로 작동해, 재량 스캔을 망치는 희망 섞인 패턴 찾기를 줄인다.
- 검증 정렬: 글로 적은 규칙은 의도적으로 검토하고 다듬을 수 있다. "보면 안다"는 식의 흐릿한 감각과 다르다.
하나의 규칙에 무엇을 조합할 수 있나
코드 없는 빌더의 힘은 꺼내 쓸 수 있는 구성 요소의 폭에서 나온다. Scanner Studio에서는 하나의 규칙이 3개 계열의 요소를 불리언 논리로 연결한다.
탐지 엔진은 패턴을 담당한다. Super Engulfing, OB+와 OB++ 강한 order block, Market Structure(BOS / CHoCH), Liquidity Sweep reversal, Pulse의 RSI confluence 필터, Core Layer 정렬, 그 밖의 스캐너 목록이 여기에 들어간다. 각 엔진은 스크립트가 아니라 체크박스로 선택하는 조건이다.
지표는 전통적인 기술 조건을 추가한다. RSI, EMA, SMA, 거래량, ATR, 등락률을 사용할 수 있다. 예를 들어 상승 패턴이 발생했을 때 RSI가 특정 기준 아래에 있어야 한다는 식으로 엔진 조건을 걸러낸다.
맥락 필터는 규칙이 작동할 장소와 시간을 제한한다. ICT kill zone, 거래 세션, 자산군(crypto와 전통 금융시장), 24시간 거래량 하한, 요일이 여기에 해당한다. 맥락 필터는 무언가를 탐지하지 않는다. 후보 중 어떤 것만 남길지 결정한다.
세 계열을 나누어 보는 이유는 규칙을 읽기 쉽게 만들기 위해서다. 엔진은 "무슨 일이 일어났는가"에 답하고, 지표는 "어떤 기술 조건에서 발생했는가"를 말하며, 맥락 필터는 "어디서 언제 의미가 있는가"를 정한다. 세 요소를 모두 빌린 규칙은 실제 설정을 설명하는 경우가 많다. 엔진만 쌓은 규칙은 시장 어디에서나 나오는 패턴을 설명하는 데 그치기 쉽다.
| 구성 요소 | 규칙에서의 역할 | 예시 |
|---|---|---|
| 탐지 엔진 | 반드시 나타나야 하는 패턴 요소 | OB+, CHoCH, Liquidity Sweep, Super Engulfing |
| 지표 | 패턴 요소를 확인하거나 제한 | RSI, EMA, SMA, 거래량, ATR, 등락률 |
| 맥락 필터 | 작동할 장소와 시간을 제한 | kill zone, 세션, 자산군, 거래량 하한, 요일 |
맞춤형 스캔을 만드는 순서
맞춤형 스캐너 빌더에서 규칙을 만드는 과정은 조건을 하나씩 좁혀가는 선택의 연속이다. 아래 순서로 구성하면 규칙의 앞뒤가 맞는다.
1. 패턴 요소와 연결 방식을 고른다
설정을 정의하는 패턴부터 고른다. 구조가 바뀐 뒤에만 의미가 있는 order block retest 모델이라면 OB+와 Market Structure CHoCH를 선택하고 AND로 연결한다. 그러면 두 조건이 모두 충족된 종목만 결과에 들어온다. 여러 패턴 중 하나만 맞아도 되는 경우에는 OR를 쓴다.
2. 맥락 필터를 추가한다
검사할 범위를 제한한다. London 구간에서만 규칙이 작동하도록 kill zone 필터를 넣고, 유동성이 낮은 종목이 뜨지 않게 24시간 거래량 하한을 설정한다. 예를 들어 거래량 2,000만 달러 이상인 종목만 남길 수 있다. 세션, 자산군, 요일도 같은 방식으로 제한한다.
3. 엔진별로 event와 holds-now를 선택한다
각 엔진 요소는 2가지 모드 중 하나로 읽는다. Event는 가장 최근에 마감된 캔들에서 패턴이 방금 발생해야 한다는 뜻이다. 새로운 트리거를 찾는다. Holds-now는 패턴이 언제 나왔는지와 상관없이 현재 조건이 유지되는지를 본다. CHoCH는 대개 event로 설정하고, 활성화된 bias나 아직 mitigation되지 않은 zone은 holds-now로 설정한다.
3a. 더 높은 시간 프레임 조건을 씌운다
원하는 요소를 다른 규칙보다 높은 시간 프레임에서 평가하도록 감쌀 수 있다. 하나의 스캔 안에 top-down 논리를 넣는 방식이다. 예를 들어 1H 진입 요소에 4H bias 요소를 씌우면, 진입 패턴이 작동하기 전에 더 높은 시간 프레임의 방향이 일치해야 한다.
4. 방향 일치를 강제한다
방향 일치 강제 기능을 켜면 모든 요소가 같은 방향을 가리켜야 한다. 이 기능이 없으면 상승 CHoCH가 하락 order block과 함께 잡히며 잡음이 생긴다. 기능을 켜면 전체 조건이 상승이거나 전체 조건이 하락일 때만 규칙이 작동한다. 실제 confluence는 이런 식으로 방향까지 맞아야 한다.
Sequence 규칙: 순서가 있는 플레이북의 장점
맞춤형이든 고정형이든 대부분의 스캐너는 조건이 동시에 나타났는지만 확인한다. 제대로 만든 빌더의 차별점은 sequence 규칙이다. 각 요소가 정해진 순서로 발생하고, 앞 단계의 캔들이 마감된 뒤 다음 단계가 나와야 한다.
전형적인 반전 흐름을 보자. CHoCH가 구조 전환을 알리고, 그 다음에야 새 방향으로 형성된 order block을 가격이 다시 건드리길 기다린다. 동시 발생 규칙으로는 "그다음"을 표현할 수 없다. sequence 규칙이라면 가능하다. 1단계는 CHoCH, 2단계는 OB+ tap으로 설정하고, CHoCH 이후에 tap이 나온 종목만 잡는다.
ICT 플레이북이 실제로 적히는 방식과 같다. Sweep, shift, entry 순서다. Bias, displacement, retrace 순서이기도 하다. 순서 규칙은 여러 단계의 플레이북을 하나의 스캔 가능한 조건으로 바꾼다. 순서를 기억하지 못하는 개별 알림을 여러 개 쌓는 것만으로는 만들 수 없는 구조다.
순서를 정하면 동시 발생이 조용히 통과시키는 오탐도 줄어든다. 횡보가 거친 구간의 한 캔들 안에서 상승 order block과 하락 구조 판독이 거의 동시에 나올 수 있다. 동시 발생 규칙은 이런 종목까지 결과에 넣을 수 있다.
반면 sequence 규칙은 먼저 구조가 바뀌고 그 후에 tap이 나와야 한다고 요구한다. 플레이북이 정한 순서를 통과하지 못한 조합은 거부한다. 그래서 결과 수는 줄어들고, 우연한 겹침이 아니라 실제 가격 진행을 반영하는 더 정돈된 후보만 남는다.
실전 설정 예시와 스캐너가 하지 않는 일
유동성 높은 crypto 종목에서 London 세션 반전을 거래한다고 가정하자. 빌더에 입력할 규칙은 다음처럼 구성할 수 있다.
- 요소 1(sequence 1단계): 1H Market Structure CHoCH, event 모드, 상승 방향.
- 요소 2(sequence 2단계): 1H OB+ tap, holds-now, 요소 1 이후에 발생해야 함.
- HTF 조건: 4H bias가 상승이어야 함. 구조 전환이 더 높은 시간 프레임과 같은 방향이어야 한다.
- 맥락: London kill zone만 허용, 24시간 거래량 2,000만 달러 초과, crypto 자산군.
- 방향 일치: 켬. 모든 요소가 상승 방향이어야 함.
저장하면 이 스캔은 마감된 캔들만 기준으로 매시간 시장 전체를 검사한다. 종목이 정해둔 순서의 전체 조건을 충족하는 순간 웹이나 기본 알림, 앱 알림으로 결과를 보낸다. 300개 차트를 직접 열어 찾을 필요 없이 알림에서 후보를 검토하면 된다.
이 기능이 무엇이고 무엇이 아닌지는 분명히 해야 한다. 빌더는 내 규칙에 맞는 후보를 찾는다. 해당 거래가 성공한다고 예측하지 않으며, 승률을 공개하지도 않고, 주문을 넣지도 않는다. 결과가 뜻하는 바는 "내 조건이 현재 존재한다"는 것뿐이다.
결과의 품질은 작성한 규칙의 품질을 넘을 수 없다. 모호한 규칙은 모호한 후보를 내놓는다. 잘못 정의된 엣지는 어떤 엔진으로도 고칠 수 없다.
현재 Scanner Studio는 관리자용 화면으로 운영되고 있으며, 공개 결과는 공유 Confluence 카탈로그를 통해 모든 사용자에게 전달된다. 실제로 직접 규칙을 만드는 빌더가 아직 모든 계정에 열려 있는 것은 아니다. 다만 여기서 만들어진 설정은 이미 공개되어 작동하고 있다.
순서가 있는 플레이북을 포함한 각 Confluence 항목은 Studio에서 만든 스캐너를 전 세계에 공개한 것이다. 지금은 카탈로그를 통해 빌더 결과를 사용하고 있으며, 계정별 직접 제작 기능이 다음 단계로 자연스럽게 이어질 구조다.
맞춤형 스캔을 망치는 실수
쓸모없는 스캔의 원인은 대부분 2가지다. 둘 다 빌더가 주는 자유를 잘못 쓰면서 생긴다.
조건을 너무 많이 걸어 결과를 없애는 경우. AND 조건을 하나 추가할 때마다 후보 수는 줄어든다. 엔진 6개, 지표 3개, kill zone, 요일 필터까지 한꺼번에 쌓으면 올해 한 번도 작동하지 않을 규칙을 만들 수 있다. 며칠 동안 결과가 0이라면 가장 덜 중요한 조건을 빼고 기준값을 넓힌다. 한 번도 작동하지 않는 규칙에서는 아무것도 배울 수 없다.
가짜 confluence. 같은 대상을 반복해서 측정하는 요소는 confluence가 아니다. 엄격해 보이게 꾸민 중복 조건일 뿐이다. 강한 상승 마감이 이미 필요한 상승 모멘텀 엔진에 RSI 과매도 조건을 더하는 것은 같은 신호를 2번 세는 것과 같다. 진짜 confluence는 서로 독립적인 판독을 쌓는다. 구조, zone, 시간 구간이 그 예다. 방향 일치와 HTF 조건은 독립성을 더하지만, 모멘텀 요소 3개를 겹친다고 독립적인 confluence가 되지는 않는다.
- 처음에는 엔진 범위를 좁히고 기준값은 넓게 둔다. 결과 비율을 확인한 뒤에만 조인다.
- 약한 필터 5개보다 강한 맥락 필터 하나를 우선한다. kill zone이나 거래량 하한이면 충분할 때가 많다.
- 동시에 나타나는 요소를 계속 추가하기보다 sequence 순서로 엄격함을 더한다.
자주 묻는 질문
맞춤형 스캐너를 만들려면 코딩을 알아야 하나
아니다. 코드 없는 빌더는 엔진, 지표, 필터를 체크박스와 드롭다운으로 제공하고 AND와 OR 논리로 연결한다. 화면에서 규칙을 조합해 저장하면 된다. 배워야 할 스크립트 언어가 없다는 점이 직접 탐지 코드를 작성하는 방식과 맞춤형 스캐너 빌더를 나누는 이유다.
맞춤형 스캔은 얼마나 자주 작동하나
LiquidityScan의 Scanner Studio는 저장된 규칙을 매시간 시장 전체에서 평가한다. 결과는 repaint를 막기 위해 확인된 마감 캔들만 사용한다. 종목이 규칙을 충족하면 직접 피드를 지켜보지 않아도 웹이나 기본 알림, 앱 알림으로 결과를 받는다.
event 모드와 holds-now 모드는 어떻게 다른가
Event 모드는 가장 최근에 마감된 캔들에서 패턴이 방금 발생해야 한다는 뜻이다. 새로운 트리거를 찾는다. Holds-now 모드는 패턴이 언제 나왔는지와 관계없이 현재 조건이 유지되어야 한다. 구조 이탈은 보통 event이고, 활성화된 bias나 아직 mitigation되지 않은 zone은 보통 holds-now 조건이다.
맞춤형 스캐너가 매수나 매도 시점을 알려주나
아니다. 정의한 조건에 맞는 후보를 보여줄 뿐이며, 거래 지시를 내리거나 결과를 보장하거나 승률을 계산하지 않는다. 대부분의 엔진은 진입가, 손절가, 목표가가 아니라 패턴이나 zone을 출력한다. 모든 결과를 직접 분석을 시작하는 필터링된 출발점으로 다뤄야 한다. 바로 행동하라는 신호로 받아들이면 안 된다.
관련 탐색 경로
빌더에서 출발해 조합하는 엔진과 실제 운용 흐름까지 이어서 확인한다.
- LiquidityScan 스캐너 작동 방식 - 규칙이 기반으로 삼는 원시 캔들부터 설정 탐지까지의 처리 과정을 확인한다.
- order block 스캐너: 실시간 OB와 FVG - 맞춤형 규칙에 넣는 엔진 요소를 설명한다.
- ICT top-down 분석: 다중 시간 프레임 정렬 - 요소별로 추가하는 HTF 조건의 논리를 다룬다.
- ICT 트레이딩에서 엣지 찾기: 전문화 프레임워크 - 규칙으로 옮길 가치가 있는 조건 세트를 먼저 정의하는 방법을 설명한다.
- 완성도 높은 ICT 트레이딩 모델 만들기 - 스캔 가능한 규칙을 진입, 손절, 관리 계획 전체로 확장한다.
- 최고의 ICT 스캐너 고르는 법 - 맞춤형 빌더가 고정형 스캐너와 어떤 차이가 있는지 비교한다.
- Scanner, Pulse, Core Layer: LiquidityScan의 3가지 화면 - 스캐너, Pulse, Core Layer를 다른 관점에서 살펴본다.
- ICT 트레이드 알림, 셋업이 생기는 순간 바로 받기 — 스캐너 규칙을 만든 뒤 셋업 발생 알림을 설정하는 다음 단계입니다.
