← 빌드 일지
빌드 로그2026-07-12·3분 읽기

차트와 시장이 같은 방향인지 재는 지표를 만들었다: 근접도와 방향 일치를 구분한 정합도 설계

차트 기술적 분석과 시장 수급·심리 분석을 각각 상방 확률로 환산한 뒤, 둘이 같은 방향을 가리키는지를 재는 교집합 정합도 지표를 만들고 매시간 자동으로 돌렸다.

3줄 요약

  • 무슨 작업: 차트 기술적 분석(주봉·일봉·4시간)과 시장 수급·심리 분석(펀딩·미결제약정·공포탐욕·자금흐름)을 각각 상방 확률로 바꾼 뒤, 두 분석이 같은 방향을 가리키는지를 하나의 숫자로 요약하는 "교집합 정합도" 지표를 만들었다.
  • 왜 중요: 지표 하나하나보다 두 분석이 서로 동의하는지가 더 강한 신호인데, 첫 버전이 그 동의를 잘못 계산해서 서로 반대 방향인데도 정합이 높게 나오는 버그가 있었다.
  • 빌더에게의 의미: 두 수치가 가깝다는 것과 두 수치가 같은 방향을 가리킨다는 것은 서로 다른 질문이다. 근접도로 방향 일치를 재면 조용히 틀린다.

왜 하나의 값이 아니라 정합도인가

정합도는 차트와 시장이라는 두 독립 렌즈가 서로 같은 결론을 가리키는지를 하나의 숫자로 요약한 값이다. 방향 판단은 원래 여러 신호의 싸움이다. 이동평균은 위를 보는데 자금은 빠지고, 심리는 과열인데 추세는 죽어 있는 식으로 신호끼리 자주 어긋난다. 그래서 각 지표의 절대값보다, 성격이 다른 두 진단이 서로 동의하느냐가 실제로는 더 쓸모 있는 신호다.

그래서 구조를 둘로 나눴다. 하나는 순수 차트 쪽으로, 시간대별 이동평균 위치와 정배열 여부, 과열 정도를 점수화해 가중 합산한 뒤 상방 확률로 환산한다. 다른 하나는 시장 쪽으로, 펀딩·미결제약정 흐름·공포탐욕·자금 유입·청산 지도·거시 이벤트를 묶어 역시 상방 확률로 환산한다. 두 확률이 나오면 마지막 질문은 하나다. 이 둘은 같은 쪽을 보고 있는가.

첫 버전의 버그: 근접도를 방향 일치로 착각했다

첫 버전은 두 확률의 차이가 작으면 정합이 높다고 계산했고, 그건 틀린 정의였다. 차트가 하방 30퍼센트, 시장이 상방 60퍼센트로 나온 상황을 넣었더니 정합도가 80퍼센트라는 값이 튀어나왔다. 하방과 상방으로 서로 반대를 가리키는데 정합이 높다는 뜻이니, 지표가 정반대로 거짓말을 하고 있었다.

원인은 계산식 자체에 있었다. 두 확률의 거리, 그러니까 얼마나 숫자가 가까운지를 정합으로 삼았기 때문이다. 그런데 30과 60은 거리로 보면 그리 멀지 않다. 문제는 이 둘이 각각 중립선인 50을 기준으로 반대편에 서 있다는 사실을 거리 계산이 통째로 놓쳤다는 데 있다. 근접도는 두 값이 얼마나 붙어 있는지를 재지만, 방향은 그 값들이 기준선의 어느 쪽에 있는지의 문제다. 다른 질문에 다른 답을 요구해야 했다.

방향 부호의 곱으로 고쳤다

정합의 올바른 정의는 두 값의 거리가 아니라 방향 부호의 곱이다. 각 확률을 중립선 50에서 얼마나, 어느 쪽으로 떨어져 있는지로 바꾼다. 두 편차의 부호가 같으면 같은 방향이니 정합이 높고, 부호가 다르면 서로 반대를 가리키니 정합이 낮다. 편차의 크기는 확신의 세기로 쓴다. 이렇게 바꾸자 차트 하방과 시장 상방은 정확히 낮은 정합, 곧 방향 충돌로 판정됐다.

여기에 하나를 더 붙였다. 정합도라는 숫자만 던지면 보는 쪽은 그래서 뭘 봐야 하냐고 되묻게 된다. 그래서 판정이 뒤집히는 구체적 지점을 같이 출력하게 했다. 일봉 이동평균을 되찾으면 상방으로, 4시간봉 장기 이동평균을 잃으면 하방으로 무게가 넘어가는 식으로, 지금 어디를 지켜보면 판단이 바뀌는지를 함께 알려준다. 게이지 숫자보다 다음에 확인할 지점을 주는 편이 실제로 도움이 된다.

마지막으로 이 계산을 매시간 자동으로 돌려 텔레그램으로 요약을 보내고, 같은 결과를 스냅샷과 누적 일지로 남기게 했다. 랜딩페이지에도 누구나 브라우저에서 공개 데이터만으로 차트·시장·정합도를 직접 확인하는 페이지를 붙였다. 자금 유입이나 청산 지도처럼 브라우저에서 직접 가져오기 어려운 항목은 텔레그램 심층판으로 미루고, 웹은 계산 가능한 것만 정직하게 보여주도록 나눴다.

하루를 관통한 판단

오늘 배운 것은 정의를 잘못 고르면 코드는 멀쩡히 돌면서 계속 거짓말을 한다는 사실이다. 근접도를 재는 코드에는 버그가 없었다. 버그는 근접도로 방향 일치를 재려 한 결정에 있었다. 두 값이 가깝다와 두 값이 같은 방향을 본다는 서로 다른 질문이고, 다른 질문에는 다른 계산이 필요하다. 숫자가 나온다고 해서 맞는 숫자가 나오는 것은 아니다. 지표를 만들 때 먼저 물어야 할 것은 이 값이 정확히 무엇을 재고 있는가다.

빌드 일지 구독

1인 빌더의 매일 작업 일지 — 새로 만든 것, 깨진 것, 배운 것.

이메일만 넣으면 끝. 매주 1–2회 빌드 일지만 보냅니다. 광고 없음, 언제든 해지.

Wildeconforce

매일 만들고, 매일 분석하고, 매일 기록합니다.
© 2026 wildeconforce · build-in-public

이 사이트는 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.