AI 신모델 통과 의례

Q:

이 프로그램의 알고리즘을 분석해서 평가해줘. 네가 위와 같은 피보나치 채널 탐색기를 만들고자 한다면 현재 프로그램을 개선하는 쪽으로 하겠는지, 새로 처음부터 다시 설계하는 쪽으로 하겠는지도 알려줘.

알고리즘 평가 후 개선 vs 재설계 결정을 신중히 검토했다

알고리즘 분석

4,785줄짜리 Pine Script v6 코드를 전체적으로 훑어봤습니다. 한 줄로 요약하면 — 피벗 기반 자동 피보나치 채널 탐지 + 다목적 점수화 + 레짐 판정을 하나의 인디케이터에 몰아넣은, 대단히 야심찬 설계입니다. 핵심 파이프라인은 이렇게 돌아갑니다.

1. 피벗 수집: ta.pivothigh/low로 최근 50개 풀 유지.
2. 후보 생성 (두 경로):

• 탐욕(greedy) 앵커링 — f_findBestAnchor가 과거 피벗 중 RMSE/Edge/Classic 기준으로 최적 P1을 찾음. P3는 최대 편차점.
• RANSAC — f_ransacCreate가 피벗 쌍을 샘플링해서 inlier 수 - 잔차 평균으로 best hypothesis 선정.

• Survival = base + 구조 터치 + Heritage + Bayesian 수축 EV(priorN=5, zLCB=1.25) + 폭 패널티 + 비활동 패널티, 전부 tanh로 [0,100] 포화.
• Entry = ltfFit과 (100 − breakRisk) 가중 혼합.
• Display = Survival/Entry 가중 혼합.

평가

인상적인 부분 — 이건 진짜 공을 들였습니다

• 통계적으로 제대로 된 선택들이 곳곳에 있습니다. Laplace smoothing (w+1)/(a+2), shrunk EV (netR + priorN·μ)/(att + priorN), LCB 조정 μ − z/√(n+1) — 저표본 구간에서 "억지 고득점"을 막으려는 의식적인 설계. 대다수 TradingView 스크립트가 무시하는 지점입니다.
• tanh 포화를 거의 모든 점수에 걸어 단일 차원 폭주를 차단.
• 후보 생성을 탐욕+RANSAC 이원화한 발상. RANSAC은 피벗 노이즈에 강건해서 이 문제에 잘 맞습니다.
• Pine 런타임 비용을 진지하게 고려한 흔적: lastSurvKey/lastLtfKey 메모이제이션, g_scratch_* 재사용 배열, realtime 틱 스로틀링(Every N seconds), array.indexof 대신 오픈 어드레싱 해시맵(f_hm_findSlot). Pine의 한계를 아는 사람만 쓰는 패턴입니다.
• 좌표계 이원화(index/time): 주식 세션 갭 vs 암호화폐 24/7을 실제로 구분 처리. max_bars_back=5000에 맞춰 math.min(off, 4900)을 일관되게 투입.
• 터치 리액션 점수 — 단순 터치 개수가 아니라 "그 터치 이후 실제로 유리한 방향으로 갔는가"를 측정. 업계 표준보다 한 단계 위.
• Heritage(상속) 편향 — 과거 성공 slope를 탐색에 가중. 레짐 flip 때 whipsaw를 완화하려는 의도가 합리적.

걱정되는 부분

• 복잡성이 디버깅 가능 임계를 넘었습니다. 정렬 12가지 × 적합 3가지 × 폭 3가지 × (Pareto on/off) × (RANSAC on/off) × (Bucket on/off) × (Heritage on/off) × (Rank Norm on/off) × (Progressive gate on/off) × (Integrity mode 2) × (Hard Reject on/off) × (Asset preset 4). 조합 공간이 수만 단위인데, 이걸 체계적으로 검증할 수단이 Pine 안에 없습니다. 버그 리포트가 올 때 원인 격리가 사실상 불가능.
• 마법 상수의 성채: saturationCap=30, saturationK=15, priorN=5, zLCB=1.25, maxQ=50, 12·tanh(ev·0.8/1.5), 레짐 가중 0.45/0.35/0.20, Schmitt 0.20/0.12... 손튜닝 흔적이 명확한데 어떤 데이터로 튜닝됐는지 문서화가 없습니다. 다른 종목/TF에서 과적합 위험.
• 중복 제거 로직이 세 군데에 흩어져 있습니다 — 생성 시 f_checkSlopeOccupied, cleanup의 geometry cell, barstate.islast의 uniqueIndices 필터. 각 임계값이 미묘하게 달라서 drift 발생 소지가 큽니다.
• 메모이제이션에 잠재 버그: f_calculateSurvivalScore에서 lastSurvKey == calcKey면 캐시값을 반환하는데, 호출측에서는 runHeavy = doHeavyCalc or stateChanged로 호출 여부를 고르지만 함수 내부 캐시는 stateChanged를 모릅니다. 브레이크가 방금 발생한 바에서 캐시 키가 우연히 일치하면 stale value가 나옵니다.
• 이력 무결성 검사 f_verifyHistoryIntegrity는 O(loopLen) 루프를 매 후보 생성마다 돕니다. RMSE 함수는 coarse→fine 2패스인데 이쪽은 다운샘플이 없습니다.
• 함수 하나가 너무 많은 필드를 변경합니다. f_calculateLtfFit_v2는 ltfFit, structQuality, fitHealth, insideRatio, boundPressure, breakRisk, nearTag, fitLong, fitShort 를 전부 건드립니다. 한 곳을 고치면 다른 데가 꺠집니다.
• 안 쓰는 sig 필드, 중간에 붙어있는 저자 메모 주석(// 추가할 부분 ---), 한/영 섞인 주석 등 코드 위생 이슈.
• 기본 색상이 거꾸로: col_up_base = red, col_dn_base = blue. 한국 관행을 따른 것 같지만 TradingView 기본(녹=상승)과 충돌. 이건 취향인데 일관성은 유지되어야 합니다.
• off-by-default 기능이 너무 많습니다. RANSAC, Pareto, RankNorm, Heritage, Progressive gate — 모두 기본 꺼짐. 즉, 대부분의 사용자는 테스트되지 않은 경로를 돕니다. 켰을 때 문제 생기면 체감 품질이 급락합니다.

내가 같은 걸 만든다면 — 개선 vs 재설계

결론부터: 처음부터 다시 만들지 않습니다. 하지만 '강한 리팩토링'은 합니다.

이유는 이렇습니다. 이 코드에는 Pine 환경 특유의 함정을 여러 번 밟아본 뒤에만 얻을 수 있는 도메인 지식이 박혀 있습니다 — max_bars_back 한계를 감안한 offset 캡, index vs time 분기, array.indexof를 피한 해시맵, realtime 틱 스로틀, ATR 기반 적응 tolerance, Bayesian shrinkage 프라이어 값, Pareto 4목적 조합, ghost 영향 25% 상한 같은 구체적 숫자들. 이걸 밑바닥부터 다시 만들면 같은 벽에 다시 부딪히면서 다시 튜닝해야 합니다. 교환되는 건 "알려진 버그 표면"을 "알려지지 않은 버그 표면"으로 바꾸는 것뿐이고, 동시에 유저 설정(입력 이름/의미)이 전부 깨집니다. 버전이 v47.45까지 온 건 47번의 엣지 케이스 패치가 누적됐다는 뜻이고, 그 가치를 버리긴 아깝습니다.

다만 지금처럼 계속 패치만 쌓는 것도 지속 불가능합니다. 제가 인수받는다면 다음 릴리스 한 번을 "기능 동결, 부채 청산" 릴리스로 잡고 이렇게 합니다.

1. 정렬 모드 12→3으로 축소: Smart Score(Display), Survival, AvgEV만 남김. 나머지 9개는 A/B에서 재현성 있게 이겼다는 증거가 없으면 제거. 이걸로 테스트 부담이 선형으로 줄어듭니다.
2. Fit 모드 1개로 통일: Edge만 남기고 RMSE/Classic은 개발자용 플래그로. 이미 Edge가 대부분 경로에서 기본값.
3. 중복 제거 로직 단일화: (dir, slope/ATR, center/ATR, height/ATR) 4튜플을 canonical similarity로 선언하고, 생성·cleanup·최종 필터가 전부 같은 함수를 부르도록. 세 군데 drift가 사라집니다.
4. f_calculateLtfFit_v2를 3–4개 pure 함수로 분해: computeInsideRatio, computeProximity, computeBreakRisk, composeLtfFit. 각 함수는 입력을 받아 값을 리턴만 하고, 채널 필드 대입은 마지막에 한 번.
5. 메모이제이션을 수정: 캐시 키에 (bar_index, stateChanged, paramVersionHash)를 포함. 지금은 틱 키 하나라 state 변화 직후 stale을 돌려줄 수 있습니다.
6. 상수 패널 도입: 파일 맨 위에 // Tuning constants (validated on: NASDAQ 1H 2022–2024, BTC 1H 2022–2024) 같은 블록으로 마법 상수 14개를 모으고 각 값의 근거 한 줄 주석. 이게 있느냐 없느냐가 5년 뒤 유지보수 난이도를 가릅니다.
7. RANSAC을 기본 ON으로 승격하거나, 제거: 켜고 끄는 선택지로 두면 둘 다 반쯤만 테스트됩니다.
8. 이력 무결성 검사에 coarse-fine 2패스 적용: RMSE와 동일 패턴. 고TF에서 체감 반응성이 올라갑니다.
9. 죽은 코드 제거: sig 필드, 저자 메모 주석, f_generateSig의 미사용 경로.
10. 디폴트 색상을 TradingView 관례에 맞춤 (또는 최소한 Colors 그룹 맨 위에 "한국식=red up" 토글을 명시).

이 10가지만 해도 코드량이 30% 이상 줄고 조합 공간이 한 자릿수로 떨어집니다. "재설계"라는 말이 유혹적으로 들리는 건 보통 "이 복잡성을 이해하기 귀찮다"의 다른 표현인데, 이 코드는 그 복잡성의 상당 부분이 실제 문제를 반영합니다. 버리지 말고, 정리하세요.

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

AI 코딩에 권태기가 왔었는데

Opus 4.7로 치료됨.

다시 재밌어짐.ㅋㅋㅋ