엘리엇파동 분석기

약 4,800줄에 달하는 이 Elliott Wave 자동 카운팅 알고리즘을 상세히 분석했습니다. 전체적으로 매우 정교하고 완성도 높은 스크립트입니다. 핵심 구조와 장단점, 그리고 개선 방안을 정리하겠습니다.

알고리즘 구조 요약

이 스크립트는 크게 6개의 엔진으로 구성되어 있습니다. 멀티스케일 피벗 엔진(S1/S2/S3 세 개의 ZigZag 스케일), 임펄스 탐지 엔진(1-2-3-4-5 구조 검증), 복합 스코어링 시스템(피보나치, 거래량, 시간, RSI 다이버전스, 교대 법칙, 프랙탈 일관성 등 7개 이상의 서브스코어), 차수(Degree) 추론 트리 엔진, 조정파 패턴 인식(ABC, 삼각형, 더블/트리플 콤보), 그리고 프로젝션 및 리스크 관리 시스템입니다.

장점

멀티스케일 아키텍처가 탁월합니다. 세 개의 독립적인 ZigZag 스케일(leftBars 5/8/13)을 동시에 운용하고, 각 스케일에서 임펄스를 독립적으로 탐지한 후 점수 기반으로 최적 스케일을 선택합니다. 이 접근은 단일 스케일 방식에서 흔히 발생하는 "파동 하나를 놓치면 전체가 틀어지는" 문제를 크게 완화합니다.

스코어링 시스템이 다차원적입니다. 단순히 구조만 보는 것이 아니라, 피보나치 비율 적합도(fibImpulseScore), 3파 거래량 지배성(volumeWave3DominanceRatio), 시간 비율의 피보나치 수열 근접도(timeImpulseScore), RSI 다이버전스(rsiDivergenceScore), 2파와 4파의 교대 법칙 준수(alternationImpulseScore), 하위 프랙탈 일관성(fractalDegreeConsistencyScore), MTF 추세 맥락(mtfImpulseContextScore)까지 반영합니다. 특히 교대 법칙 스코어는 깊이(depth), 시간(time), 속도(slope) 세 축의 대비를 정량화하는데, 이 수준의 구현은 상당히 드뭅니다.

차수 추론에 히스테리시스와 충격 필터를 적용합니다. 피벗 간 평균 갭으로 차수를 결정할 때 비대칭 히스테리시스 밴드(degreeUpgradeBand 0.10 vs degreeDowngradeBand 0.18)를 사용하여 불필요한 차수 변경을 억제합니다. 갑작스러운 갭 변화에 대해서는 충격 필터(degreeShockRatioThreshold 1.90)가 일정 바 수 동안 차수 변경을 차단합니다. 이 안정화 로직 덕분에 차수 라벨이 매 바마다 달라지는 문제가 크게 줄어듭니다.

조정파 인식이 포괄적입니다. ABC 패턴에서 지그재그뿐 아니라 플랫, 확장 플랫, 러닝 플랫까지 B파 비율 기준으로 자동 분류하며, 삼각형의 수렴 조건(range2 < range1), 더블/트리플 콤보의 X파 되돌림 비율(18~95%)까지 검증합니다. 콤보 패턴의 경우 하위 스케일에서 실제로 ABC 하위구조가 존재하는지까지 확인(comboChildABCPass)하는 점이 인상적입니다.

무효화 및 소프트 무효화 이중 체계를 갖추고 있습니다. 하드 무효화(2파 시작점 이탈)와 소프트 무효화(4파 시작점 이탈)를 분리하여, 소프트 이탈 시에는 점선으로 스타일을 변경하고 경고 라벨을 표시하면서도 카운트를 즉시 폐기하지 않습니다. 종가 기준 vs 고/저가 기준 선택도 가능합니다.

프로젝션 시스템이 적응적입니다. 프로젝션 실패(miss) 누적 시 자동으로 방향을 전환(projectionAutoFlipOnMiss)하고, 연속 실패 시 Continuation 우선 모드로 전환(projectionForceContOnMissAccum)하는 자기수정 메커니즘이 있습니다.

단점 및 개선점

1. ZigZag 엔진 코드 중복이 심각합니다

S1, S2, S3 세 스케일의 ZigZag 로직이 거의 동일한 코드 70줄씩 세 번 반복됩니다(라인 2830~3035). 스케일별 변수만 다를 뿐 구조가 완전히 같습니다. Pine Script v6에서는 UDT(User-Defined Types)와 메서드를 지원하므로, ZigZag 상태를 타입으로 캡슐화하면 코드량을 1/3로 줄이고 유지보수 오류를 방지할 수 있습니다.

같은 문제가 fractalInternalStructurePass, diagonalInternalPass, isDiagonalShapeByScale 등에서도 발생합니다. childScale == 1 / == 2 / == 3 분기가 동일 로직을 반복하는데, 배열 참조를 함수 파라미터로 넘기면 해결됩니다.

2. ta.valuewhen 기반 히스토리컬 참조의 한계

rsiAtBar(int x)와 cumVolAtBar(int x)는 ta.valuewhen(bar_index == x, ...) 방식인데, 이는 해당 바가 실제로 계산 범위 내에 있어야만 값이 반환됩니다. max_bars_back=2000을 설정했지만, 피벗이 2000바 이전이면 na가 반환되어 RSI 다이버전스와 거래량 스코어가 조용히 실패합니다. 사용자에게는 왜 점수가 낮은지 알 수 없습니다.

개선안: array에 바별 RSI와 누적 거래량을 롤링 저장하고, bar_index를 키로 직접 조회하는 방식으로 전환하면 참조 실패를 방지할 수 있습니다. 또는 최소한 na 반환 시 스코어를 0이 아닌 중립값(예: weight * 0.5)으로 처리하여 데이터 없음을 빈약함으로 오해하지 않게 해야 합니다.

3. 총점 산출 방식이 선형 합산이라 해석이 불투명합니다

현재 점수 공식은 다음과 같습니다:

서브스코어의 최대값이 각각 다르고(fibScoreWeight=22, volumeScoreWeight=12, rsiDivScoreWeight=14 등), 기본점 40점에 패턴 보너스 10~16, 컨센서스 보너스 12+6까지 더하면 이론적 최대가 약 175점인데, scoreGradeText에서는 100점을 A+ 기준으로 씁니다. 이 불일치 때문에 "B 등급"이 실제로 얼마나 좋은 카운트인지 직관적으로 파악하기 어렵습니다.

개선안: 각 서브스코어를 0~1로 정규화한 뒤 가중 평균을 내어 최종 점수를 0~100 범위로 통일하면, 등급 기준과 일치하게 됩니다. 또한 "피보나치 85%, 거래량 40%, RSI 다이버전스 70%"처럼 서브스코어 분해를 상태 테이블에 표시하면 사용자가 카운트의 강약점을 구체적으로 이해할 수 있습니다.

4. 임펄스 탐색이 "가장 최근" 하나에만 의존합니다

findLatestImpulse는 피벗 배열 끝에서부터 역순 탐색하여 첫 번째 유효 임펄스를 발견하면 즉시 break합니다. 이는 최근에 발생한 구조적으로 더 나은 임펄스가 하나 뒤에 있어도 놓칠 수 있습니다. 예를 들어 가장 최근 임펄스가 점수 55점이고, 한 피벗 앞의 임펄스가 점수 92점이면, 55점짜리가 선택됩니다.

개선안: 상위 N개(예: 3~5개)의 임펄스 후보를 모두 찾아 점수를 비교한 뒤 최고점을 선택하는 방식이 더 견고합니다. 이미 topNAlternatives 시스템이 있으므로, 탐색 단계에서 후보 풀을 넓히는 것은 구조적으로 자연스럽습니다.

5. 프랙탈 내부구조 검증의 스케일 제한

fractalInternalStructurePass와 diagonalInternalPass는 한 단계 아래 스케일(childScale = scaleId - 1)만 확인합니다. S1(가장 작은 스케일)의 임펄스에 대해서는 scaleId > 1 조건이 거짓이라 프랙탈 검증을 전혀 수행하지 않습니다. 엘리엇 이론에서 프랙탈 일관성은 모든 차수에 적용되어야 하므로, S1에서도 더 작은 피벗(예: leftBars=3)을 임시로 생성하여 검증하거나, 최소한 S1에서는 프랙탈 페널티를 면제하되 그 사실을 신뢰도에 반영해야 합니다.

6. 볼류 레짐 필터의 뒤집힌 로직 가능성

거래량 스파이크 시 ZigZag 임계값을 완화(줄이는) 방향으로 작동하는데(zzVolSpikeMaxRelax = 0.40, 즉 최대 40% 축소), 이는 변동성 급등 시 작은 움직임도 피벗으로 인식하게 만듭니다. 실제 시장에서 거래량 스파이크는 대형 추세파의 징후인 경우가 많아, 오히려 더 큰 필터가 필요한 상황일 수 있습니다.

개선안: 거래량 스파이크의 성격을 구분하여, 추세 방향 스파이크는 임계값을 유지/상향하고, 반전 방향 스파이크만 완화하는 방향성 감도 조절이 바람직합니다.

7. 실시간 리페인팅 위험

ZigZag 엔진에서 마지막 피벗은 현재 바의 high/low 기준으로 지속적으로 갱신됩니다(addPivot에서 같은 방향이면 더 극단적인 가격으로 교체). 이는 완료된 바에서는 안정적이지만, 마지막 피벗이 아직 확정되지 않은 상태에서 임펄스 탐지가 실행되므로, 현재 진행 중인 카운트가 바가 닫힐 때 바뀔 수 있습니다. 이는 ZigZag 기반 시스템의 본질적 한계이지만, 사용자에게 "마지막 피벗 미확정" 상태를 명시적으로 표시하는 것이 좋습니다.

8. Pine Script 리소스 한계에 근접

max_lines_count=500, max_labels_count=500을 사용 중이고, candidateMaxObjectBudget으로 후보 객체수를 제한하고 있습니다. 멀티스케일 + 양방향 + 대안 + 후보까지 동시에 표시하면 TradingView의 드로잉 제한에 쉽게 도달합니다. 현재 candidateCanCreate 가드가 있지만, 제한에 도달했을 때 어떤 후보가 생략됐는지 사용자에게 알려주지 않습니다. 조용한 생략은 분석 왜곡으로 이어질 수 있으므로, 제한 도달 시 상태 테이블에 "후보 일부 생략됨"을 표시하면 좋겠습니다.

9. 상수 하드코딩이 매우 많습니다

ratioFit 가중치(0.28, 0.40, 0.18, 0.14), 교대 법칙 가중치(0.44, 0.28, 0.28), 거래량 스코어 가중치(0.40, 0.30, 0.20, 0.10) 등이 코드 전체에 매직 넘버로 산재해 있습니다. 이 값들을 변경하려면 코드를 직접 수정해야 하고, 어떤 값이 어떤 역할인지 추적이 어렵습니다. 핵심 가중치들을 input 파라미터로 노출하거나, 최소한 파일 상단에 명명된 상수로 모아두면 유지보수성과 최적화 가능성이 크게 향상됩니다.

10. 백테스트 및 자기검증 메커니즘 부재

현재 프로젝션 miss 이벤트를 알림으로 제공하지만, 역사적 적중률을 집계하는 로직은 없습니다. "이 알고리즘이 과거에 얼마나 정확했는가"를 사용자가 알 수 없습니다. Pine Script의 var 배열로 최근 N개 프로젝션의 성공/실패를 누적하고, 상태 테이블에 "최근 20회 프로젝션 적중률 65%"처럼 표시하면 실질적인 신뢰도 판단에 도움이 됩니다.

종합 평가

이 스크립트는 Pine Script로 구현할 수 있는 엘리엇 파동 자동 분석의 사실상 상한선에 근접한 수준입니다. 멀티스케일 합의, 다차원 스코어링, 차수 트리 추론, 프랙탈 검증, 적응적 프로젝션까지 갖춘 구현은 상업용 도구를 포함해서도 흔치 않습니다. 가장 시급한 개선 우선순위를 꼽자면, 점수 정규화(0~100 통일 + 서브스코어 분해 표시), 임펄스 탐색 범위 확대(상위 N개 후보), 그리고 코드 중복 제거(UDT 기반 리팩토링)입니다. 이 세 가지만 해결해도 분석 정확도와 코드 유지보수성이 모두 크게 향상될 것입니다.

===================

알고리즘 분석시켜보면 클로드는 그래도 돈값은 함.

제미니는 답도 없슴.ㅋㅋㅋ

그런데... 업데이트 하려고 하면 결제 추가...ㅂㄷㅂㄷ