WSJT-X 3.1 improved의 FT8 디코더 설정 이해하기

JTDX는 오래전부터 디코더 설정이 어떻게 동작하는지 유용한 설명을 제공해 왔습니다. 그 안내는 언제나 가치가 있었는데, 한 가지 중요한 원칙을 매우 분명하게 보여 주기 때문입니다.

이것이 핵심 원칙입니다.

하지만 2026년 현재 FT8/FT4 운용 성능이 관심의 중심이라면, 논의의 전제는 이미 달라졌습니다.

WSJT-X 3.1 improved는 더 이상 단순히 “표준 WSJT-X에 몇 가지 기능을 더한 버전”이 아닙니다. JTDX 사용자에게 매우 익숙하게 느껴질 아이디어를 포함해, 실제 운용에서 얻어진 상당한 디코더 철학이 의미 있게 반영되었습니다. 이제 이를 WSJT-X 2.7 또는 그 이전 버전과 가볍게 비교하는 것은 솔직히 큰 의미가 없습니다.

좀 더 직접적으로 말하면, 일반적인 운용자에게 WSJT-X 3.1 improved는 이제 최우선 후보 중 하나로 진지하게 고려할 가치가 있습니다.

물론 JTDX의 다음 GA 릴리스를 기다리는 것도 하나의 선택입니다. 하지만 실제 디코더 성능, 지금 사용할 수 있는 기능, 업데이트 활동, 그리고 오늘 바로 설치해 쓸 수 있는 것을 우선한다면, 이미 존재하고 이미 강력한 것을 활용하는 편이 더 합리적입니다.

그렇다고 JTDX가 더 이상 필요 없다는 뜻은 아닙니다. JTDX 인터페이스를 정말 좋아한다면 계속 사용하는 것은 충분히 타당한 선택입니다. 다만 그것은 디코더 능력과 실전 최적화의 문제와는 별개의 질문입니다.

이 글은 단순히 또 하나의 추천 설정 목록을 만들기 위한 것이 아닙니다. 대신 더 근본적인 질문을 살펴보려 합니다.

FT8 디코더 최적화란 실제로 무엇인가? 그리고 더 구체적으로, WSJT-X 3.1 improved의 “Decode Start” 설정은 실제로 무엇을 하는가?

먼저 실전 결론

Normal에서 시작하십시오. CPU 여유가 충분하면 3-Stage를 시험하십시오. 타이밍 여유가 더 중요하면 Early를 사용하십시오.

먼저 실전적인 결론부터 말하겠습니다.

FT8 디코더 튜닝에서 가장 중요한 원칙은 다음이 아닙니다.

“사용 가능한 가장 무거운 설정을 사용하라.”

실제로 중요한 것은 다음입니다.

“15초 사이클 안에서 시스템이 안정적으로 끝낼 수 있는 범위 내에서 가장 공격적인 설정을 사용하라.”

이것은 완전히 다른 사고방식입니다.

많은 스테이션에서는 다음과 같은 구성이 합리적인 출발점입니다.

이것이 반드시 최종 답은 아니지만 좋은 출발점입니다. CPU에 여유가 있다면 더 공격적인 방향으로 갈 수 있습니다. 지연, 늦은 완료, 불안정성이 보이기 시작하면 한 단계 뒤로 물러나면 됩니다.

Decode Start를 실전적으로 요약하면 다음과 같습니다.

이것이 실전적인 요약입니다. 하지만 이 설정이 중요한 이유는 이 단순한 요약보다 훨씬 흥미롭습니다.

Decode Start는 단지 “더 일찍 시작할지, 더 늦게 시작할지”를 고르는 설정이 아닙니다. 디코더가 몇 단계를 사용하는지, 그 단계들이 시간축 어디에 배치되는지, 그리고 FT8 사이클 전체에서 연산 노력이 어떻게 분배되는지와 밀접하게 연결되어 있습니다.

이것이 이 문제의 진짜 핵심입니다.

왜 지금 WSJT-X 3.1 improved를 진지하게 볼 필요가 있는가

이것이 왜 중요한지 이해하려면 한 걸음 뒤로 물러나 전체 그림을 보는 것이 도움이 됩니다.

지난 몇 년 동안 WSJT-X improved는 단순히 옵션이 더 많은 곁가지 버전을 훨씬 넘어섰습니다. 실제 디코더 아이디어, UI 유연성, 운용 지향 개선을 시험하고 구현하는 실용적인 플랫폼으로 발전했습니다.

현재의 improved 빌드를 어느 정도 사용해 보면 한 가지가 분명해집니다.

“표준 WSJT-X 2.7과 비교하면 어떤가?”라는 오래된 질문은 이제 가장 유용한 질문이 아닙니다.

지금 더 중요한 질문은 다음과 같습니다.

• WSJT-X 3.1 improved는 오늘날 실전 FT8/FT4 운용 도구로 얼마나 좋은가?
• 얼마나 많은 실제 운용 기반 디코더 아이디어가 여기에 반영되어 있는가?
• 운용자는 자신의 스테이션, CPU, 운용 우선순위에 맞춰 어떻게 튜닝해야 하는가?

그래서 이 글의 핵심은 비교표가 아닙니다. 소프트웨어를 얼마나 지능적으로 사용할 것인가에 관한 이야기입니다.

논의가 “어떤 설정이 있는가?”에서 “그 설정을 어떻게 사용해야 하는가?”로 넘어가면, 그 설정들이 15초 FT8 사이클 내부에서 실제로 무엇을 의미하는지 물어볼 필요가 있습니다.

각 설정의 역할

“더 공격적”이라고 해서 자동으로 “더 좋다”는 뜻은 아니다

Decode Start에 집중하기 전에 FT8 디코더 설정을 전체적으로 어떻게 이해해야 하는지 먼저 정리할 필요가 있습니다.

아주 흔한 오해는 이것입니다.

설정이 무거울수록 성능이 더 좋아야 한다.

그럴듯하게 들리지만 FT8은 그렇게 동작하지 않습니다.

FT8은 15초 사이클로 동작하므로 실제로 중요한 것은 다음 네 가지의 균형입니다.

1. 디코딩 전에 얼마나 많은 신호를 기다릴 것인가
2. 후보 메시지를 얼마나 깊게 검색할 것인가
3. 그 모든 처리가 제시간에 끝나는가
4. 얼마나 많은 오디코딩을 감수할 것인가

이렇게 보면 FT8 최적화는 “최대 출력”의 문제가 아닙니다. 제한된 처리 시간을 어떻게 배분할 것인가의 문제입니다.

이 관점은 각 설정을 보는 방식을 바꿉니다.

디코딩 스레드 수

대부분의 운용자에게 Auto는 여전히 가장 좋은 출발점입니다. 단순히 스레드 수를 강제로 늘린다고 결과가 더 좋아지는 것은 아닙니다. OS 스케줄링, 백그라운드 부하, 코어 구조, 시스템 전체 동작이 모두 영향을 줍니다.

디코딩 패스 수

패스 수를 늘리면 더 약하거나 애매한 신호를 복구할 가능성이 높아질 수 있습니다. 하지만 그만큼 CPU 시간이 필요합니다. 시스템이 충분히 강하다면 3패스가 의미 있을 수 있고, 많은 스테이션에는 2가 가장 합리적인 기본값입니다. 제한된 하드웨어에서는 1이 더 안전할 수 있습니다.

Decoder Sensitivity

실전적으로는 다음처럼 이해하면 됩니다.

• Minimum은 가볍다
• Low thresholds는 균형형이다
• Subpass는 더 공격적이지만 더 무겁다

Subpass는 공짜 성능이 아닙니다. 더 약하거나 더 어려운 신호를 복구할 가능성을 얻는 대신 추가 연산을 하는 것입니다.

Fast / Normal / Deep와 Multithreaded FT8 Decoder에 대한 주의

이 부분은 특히 오해하기 쉽습니다. Fast / Normal / Deep가 Multithreaded FT8 decoder와 같은 화면에 있기 때문에 같은 제어 기능의 다른 버전이라고 생각하기 쉽습니다. 하지만 소스 코드는 두 설정이 같은 종류가 아님을 보여 줍니다.

먼저 Fast / Normal / Deep는 전통적인 decode-depth 설정입니다. 즉 디코더가 얼마나 깊게 검색할지를 정합니다. 기존 단일 스레드 FT8 디코딩 경로에서는 이 깊이가 디코딩의 계산량과 검색의 공격성에 직접 연결됩니다.

반면 Multithreaded FT8 decoder는 완전히 다른 축입니다. 본질적으로 어떤 계열의 디코더 엔진을 사용할지를 결정합니다. 코드에서도 decode depth와 멀티스레드 FT8은 같은 기능의 두 이름이 아니라 서로 다른 파라미터로 처리됩니다.

다음으로 중요한 미묘한 차이가 있습니다. FT8이 실제로 멀티스레드 디코더를 켠 상태에서 동작하면 프로그램은 기존의 전통적인 FT8 디코딩 경로가 아니라 전용 MTD 경로로 들어갑니다. 이 경로에서 실제 동작을 좌우하는 것은 예전의 Fast / Normal / Deep 단계보다 MTD 전용 설정입니다.

• Decoder Sensitivity
• Decode Start
• Number of decode passes
• QSO Rx Frequency Sensitivity

가장 정확한 이해 방식은 이렇습니다. Fast / Normal / Deep는 여전히 존재하고 프로그램의 전반적인 decode-depth 논리에 속하지만, FT8 MTD 운용에서는 디코더의 공격성을 결정하는 주된 노브가 아닙니다. 실제 튜닝에서 더 중요한 것은 MTD 지향 설정, 특히 Decoder Sensitivity, Decode Start, Number of decode passes, QSO Rx Frequency Sensitivity입니다.

즉, 멀티스레드 디코더를 켠 WSJT-X 3.1 improved의 FT8을 진지하게 튜닝하려면 Fast / Normal / Deep가 여전히 디코더 성격을 결정하는 주된 요소라고 생각하기보다 MTD 전용 동작 제어를 중심으로 접근하는 편이 낫습니다. 기존 depth 설정도 여전히 설계의 일부이지만, FT8 MTD 경로에 들어간 뒤에는 더 이상 가장 중요한 실전 레버가 아닙니다.

QSO Rx Frequency Sensitivity

이것은 단순한 속도 설정이 아닙니다. 현재 QSO 관련 주파수 영역과 인접 후보를 디코더가 얼마나 적극적으로 조사할지에 영향을 줍니다.

• Low는 보수적
• Medium은 균형형
• High는 공격적

예상할 수 있듯이 더 공격적인 설정은 의심스러운 후보와 디코딩 노이즈를 더 많이 가져올 수도 있습니다.

Reduce False Decodes

이 설정은 생각보다 더 많은 주의를 받을 가치가 있습니다. 추가 결과의 신뢰성이 점점 낮아진다면 “더 많이 찾는 것”이 자동으로 더 좋은 것은 아닙니다. 혼잡한 밴드나 애매한 조건에서는 오디코딩 제어가 매우 중요합니다.

이 설정들은 서로 고립된 채 “누가 가장 강한가”를 겨루는 것이 아닙니다. 각각은 같은 근본적인 질문에 서로 다른 답을 줍니다.

매우 제한된 15초 안에서 디코더는 무엇을 우선해야 하는가?

그중에서도 Decode Start는 가장 분명하고 많은 것을 보여 주는 예 중 하나입니다.

핵심 질문

“Decode Start”는 실제로 무엇을 하는가?

바로 여기서부터 주제가 정말 흥미로워집니다.

사용자 인터페이스에서 Decode Start는 다섯 가지 선택지를 제공합니다.

• 2-Stage
• 3-Stage
• Early
• Normal
• Late

처음 보면 단순한 타이밍 제어처럼 보입니다.

더 일찍 디코딩을 시작하거나, 더 늦게 시작하는 것.

하지만 그것이 전부는 아닙니다.

실제 WSJT-X 3.1 improved 구현을 보면 이 모드들은 내부적으로 다음과 같이 처리됩니다.

• 0 = 2-Stage
• 1 = 3-Stage
• 2 = Early
• 3 = Normal
• 4 = Late

FT8 운용 중 프로그램은 m_hsymStop, m_earlyDecode, m_earlyDecode2 같은 값을 사용해 각 디코딩 단계가 언제 트리거될지 결정합니다.

이것은 즉시 한 가지 사실을 알려 줍니다.

이해하기 쉽게 먼저 비교적 단순한 세 모드 Early, Normal, Late를 살펴본 뒤, 더 많은 설계 의미를 보여 주는 2-Stage와 3-Stage로 넘어가겠습니다.

Early / Normal / Late

먼저 단순한 세 모드

가장 직관적인 선택지부터 보겠습니다.

멀티스레드 FT8 디코더가 활성화된 경우 내부 stop point는 대략 다음과 같습니다.

• Early → 48
• Normal → 49
• Late → 50

대략적인 시간으로 바꾸면 다음과 같습니다.

• Early → 약 13.8초
• Normal → 약 14.1초
• Late → 약 14.4초

기본 의미는 직관적입니다.

• Early는 CPU 시간 여유를 확보하는 대신 신호 수집을 조금 포기합니다
• Late는 조금 더 많은 정보를 모은 뒤 디코딩하기 위해 더 오래 기다립니다
• Normal은 그 중간입니다

Decode Start가 이 세 모드만 제공했다면 여전히 유용한 설정이겠지만 특별히 독특한 기능은 아니었을 것입니다.

이 기능을 훨씬 더 흥미롭게 만드는 것은 다음 두 모드입니다.

2-Stage와 3-Stage.

추가 기술 메모

2-Stage와 3-Stage의 실제 의미

단순히 “더 일찍” 또는 “더 늦게”가 아니라, STD와 MTD를 결합하는 단계별 디코딩 전략

WSJT-X improved 변경 로그는 2-stage와 3-stage를 “두 디코더를 지능적으로 결합하는” 모드라고 설명하며, 이를 통해 지금까지 가장 좋은 FT8 디코딩 성능을 얻는다고 표현합니다.

즉 소프트웨어는 이들을 전통적인 STD 디코더(단일 스레드)와 더 새로운 MTD 디코더(멀티스레드)를 결합하는 방법으로 명시적으로 제시합니다.

변경 로그가 설명하지 않는 것은 정확한 실행 순서와 두 디코더의 시간 관계입니다. 이것은 실제 구현을 보아야 분명해집니다.

그리고 구현을 보면 2-Stage와 3-Stage는 단순히 시작 시간이 다른 모드가 아니라는 것이 분명합니다. 이들은 다단계 디코딩 전략이며, 각 단계의 역할도 동일하지 않습니다.

STD와 MTD의 역할 분담

여기서 STD는 전통적인 단일 스레드 FT8 디코더를 뜻하고, MTD는 improved 계열에서 도입된 멀티스레드 FT8 디코더를 뜻합니다.

구현을 보면 단계별 모드는 대략 다음처럼 동작합니다.

• 앞 단계에서는 STD를 사용
• 최종 단계에서는 MTD를 사용

이것이 핵심 설계 아이디어입니다.

즉, 의도적으로 다음 두 역할을 분리한 것으로 이해하는 것이 가장 좋습니다.

• 더 이르고, 더 가볍고, 더 빠른 확인
• 그리고 더 늦고, 더 완전한 디코딩 패스

이 차이는 매우 중요합니다.

더 단순한 설계라면 수신 구간의 끝까지 기다린 뒤 무거운 디코딩 패스를 한 번 수행했을 수도 있습니다. WSJT-X improved는 그렇게 하지 않습니다. 최종 단계 전에 중간 후보 검색을 수행하고, 이후 더 진지한 디코딩으로 마무리합니다.

이것은 설계가 한 가지 핵심 문제를 매우 중요하게 보고 있음을 보여 줍니다.

개발자 관점: STD 사전 패스의 진짜 목적

Uwe Risse / DG2YCB에 따르면 STD 사전 패스는 단순한 추가 예비 디코딩이 아닙니다. 중요한 역할은 전통적인 STD 디코더가 가진 조기 디코딩의 장점을 MTD 작업 흐름 안으로 가져오는 것입니다.

개발 과정에서는 여러 STD/MTD 조합과 다양한 nzhsym 파라미터를 시험했습니다. 현재 방식, 즉 STD를 사전 패스로 사용하고 MTD를 주 최종 패스로 사용하는 조합이 가장 좋은 실전 결과를 보였습니다.

이 점은 매우 중요합니다. 2-Stage와 3-Stage는 단순히 “디코더를 여러 번 실행하는” 구조가 아닙니다. STD의 가벼운 조기 디코딩 동작과 MTD의 더 완전한 최종 디코딩 능력을 결합해, 15초 FT8 사이클 안의 제한된 CPU 시간을 더 효과적으로 사용하도록 설계되었습니다.

Uwe는 또한 2-Stage가 훨씬 적은 연산 능력으로 3-Stage 디코딩 성과의 약 99.5%를 달성한다고 설명합니다. 이것이 대부분의 사용자에게 2-Stage가 강력한 실전 추천이 되는 이유이며, 3-Stage는 매우 빠른 컴퓨터에서 최고 성능을 추구하는 옵션으로 남습니다.

2-Stage의 실제 의미

실제 온에어 디코딩에서 2-Stage는 nzhsym=41에서 한 번의 STD 사전 패스를 수행한 뒤 nzhsym=49에서 최종 MTD 디코딩 패스를 수행합니다.

실제 순서는 다음과 같습니다.

• STD 사전 패스 @ nzhsym=41 — 약 11.8초
• 최종 MTD @ nzhsym=49 — 약 14.1초

핵심은 실제 디코딩에서 nzhsym=46의 두 번째 STD 사전 패스가 2-Stage에 포함되지 않는다는 점입니다. 그 추가 사전 패스는 3-Stage에만 속합니다.

즉 2-Stage는 균형이 좋은 모드입니다. 한 번의 조기 정찰 패스를 수행한 뒤 nzhsym=49에서 주 MTD 디코딩으로 마무리합니다.

디코딩 성과와 CPU 비용 사이의 균형이 매우 좋기 때문에 저는 대부분의 사용자에게 먼저 2-Stage를 권하고 싶습니다. Uwe Risse / DG2YCB에 따르면 3-Stage 성과의 약 99.5%를 훨씬 적은 연산 자원으로 얻을 수 있습니다. 실전적으로 매우 강한 절충안입니다.

3-Stage의 실제 의미

3-Stage는 최종 MTD 디코딩 패스 전에 nzhsym=46에서 두 번째 STD 사전 패스를 추가합니다.

실제 온에어 디코딩 순서는 다음과 같습니다.

• STD 사전 패스 @ nzhsym=41 — 약 11.8초
• STD 사전 패스 @ nzhsym=46 — 약 13.2초
• 최종 MTD @ nzhsym=50 — 약 14.4초

따라서 3-Stage는 먼저 41에서 조기 정찰을 하고, 46에서 추가 STD 사전 패스를 한 번 더 수행한 뒤, 마지막으로 50에서 주 MTD 디코딩을 실행합니다.

이로써 3-Stage는 WSJT-X 3.1 improved에서 사용할 수 있는 가장 높은 성능의 FT8 디코딩 모드가 됩니다.

하지만 여기에는 중요한 실전 경고가 필요합니다. 3-Stage의 추가 디코딩 이득은 추가 CPU 사용량에 비례하지 않습니다. Uwe Risse / DG2YCB는 2-Stage가 이미 3-Stage 디코딩 성과의 약 99.5%를 얻는다고 말합니다. 따라서 남는 이득은 추가로 필요한 연산 능력과 비교하면 작습니다.

성능이 낮은 컴퓨터에서는 nzhsym=46의 추가 STD 사전 패스가 너무 많은 시간을 소비할 수 있으며, 최악의 경우 가장 중요한 nzhsym=50의 최종 MTD 디코딩을 방해할 수도 있습니다. 그래서 3-Stage는 고성능 하드웨어용 모드로 생각해야 합니다. 강력한 시스템에서는 궁극의 선택이지만 모든 사용자에게 자동으로 가장 좋은 추천은 아닙니다.

“먼저 STD, 마지막에 MTD”로 이해해야 하며 “먼저 MTD, 나중에 STD”가 아니다

이것은 특히 오해하기 쉬운 부분입니다.

변경 로그가 2-Stage와 3-Stage가 STD와 MTD를 결합한다고 설명하기 때문에 일부 독자는 다음과 같은 모델을 상상할 수 있습니다.

• 먼저 MTD가 실행된다
• 그다음 STD가 MTD가 놓친 것을 보완한다

하지만 실제 온에어 디코딩 동작은 그렇지 않습니다.

더 정확한 해석은 반대입니다.

• STD가 더 이르고 가벼운 정찰 패스를 수행합니다
• MTD가 최종적인 더 본격적인 디코딩을 수행합니다

실제 운용에서의 차이는 다음과 같습니다.

• 2-Stage: STD @41 → 최종 MTD @49
• 3-Stage: STD @41 → STD @46 → 최종 MTD @50

이 차이는 중요합니다. 3-Stage는 가능한 최고의 디코딩 성능을 제공하지만, 대부분의 사용자에게는 nzhsym=46 두 번째 STD 사전 패스의 추가 CPU 비용을 피할 수 있는 2-Stage가 더 실용적인 선택입니다.

왜 앞 단계에서 STD를 사용하는가?

이 점 역시 많은 것을 보여 줍니다.

목표가 단순히 “디코더를 더 여러 번 실행하는 것”이라면 각 단계에서 MTD를 반복 실행할 것이라고 예상할 수 있습니다. 하지만 실제로는 그렇게 하지 않습니다.

가장 가능성 높은 이유는 간단합니다.

앞 단계는 가볍고 빨라야 하기 때문입니다.

이른 시점에는 아직 수신이 끝나지 않았습니다. 사용할 수 있는 정보량도 최종 단계보다 적습니다. 매번 가장 무거운 디코딩 로직을 최대 강도로 돌리는 것은 제한된 CPU 시간을 가장 효율적으로 사용하는 방법이 아닐 수 있습니다.

그래서 소프트웨어는 앞 단계에서 STD를 이용해 빠르고 경제적으로 확인하고, MTD는 마지막의 더 중요한 디코딩 패스를 위해 남겨 둡니다.

이는 단순한 구현 세부사항이 아닙니다. 짧고 순간적이며 타이밍에 민감한 FT8의 계산 부하 특성에 매우 잘 맞는 디코딩 철학을 보여 줍니다.

코드는 또한 앞 단계가 최종 단계보다 다소 제한된 처리를 사용하는 것으로 보입니다. 이는 이 모드들이 단순한 반복 패스가 아니라 각 패스마다 다른 역할을 갖는 단계적 진행이라는 해석을 더 뒷받침합니다.

2-Stage와 3-Stage의 본질은 시간 배분

결국 2-Stage와 3-Stage가 다루는 것은 한 가지입니다.

15초 사이클 안에서 연산 노력을 어떻게 배분할 것인가.

• 디코더가 더 일찍 한 번 볼 것인가?
• 중간에 한 번 더 볼 것인가?
• 아니면 끝까지 기다린 뒤 가장 완전한 최종 시도를 할 것인가?

단계별 모드는 바로 이것을 결정합니다.

따라서 2-Stage와 3-Stage를 단순한 타이밍 조정으로 보아서는 안 됩니다. FT8 디코더의 작업을 시간축에 펼쳐 놓는 서로 다른 방식으로 이해하는 편이 정확합니다.

실제 운용에서는 어떻게 해석해야 하는가?

운용 관점의 언어로 바꾸면 차이는 꽤 실용적으로 보입니다.

2-Stage

• 응답성을 상당히 잘 유지합니다
• 더 이른 확인을 한 번 추가합니다
• 최종 단계는 대략 Normal 타이밍 부근에 둡니다
• CPU 부하를 극단으로 올리지 않으면서 후보 복구를 개선합니다

즉 균형 잡힌 단계별 전략입니다.

3-Stage

• 일찍 한 번 봅니다
• 중간에 다시 한 번 봅니다
• 그리고 대략 Late 타이밍에서 최종 MTD 패스를 유지합니다
• 놓친 디코딩을 줄이기 위해 더 강하게 밀어붙입니다
• 그만큼 CPU 부하도 증가합니다

따라서 3-Stage는 사용할 수 있는 단계별 모드 중 가장 야심차고 공격적인 모드입니다.

CPU에 충분한 여유가 있다면 매우 매력적일 수 있습니다. 반대로 CPU가 이미 타이밍 한계에 가깝다면 이론적인 이득보다 매 사이클을 깨끗하게 끝내는 것이 더 중요합니다.

여기까지 오면 각 모드의 의미가 훨씬 분명해집니다.

한 가지 더 중요한 점

단계별 모드는 단순한 “여러 번의 디코딩”이 아니라 각 단계에 서로 다른 역할을 부여한다

조금 더 넓은 관점에서 보면 2-Stage와 3-Stage가 흥미로운 이유는 디코딩을 여러 번 실행한다는 사실 자체가 아닙니다.

더 중요한 것은 각 단계가 서로 다른 역할을 담당한다는 점입니다.

• 앞 단계는 더 가볍고 빠릅니다
• 최종 단계는 더 완전합니다
• CPU 연산은 한 번에 모두 소비되지 않고 사이클 전체에 걸쳐 분배됩니다

이는 FT8의 특성과 매우 잘 맞습니다.

원한다면 끝까지 기다린 뒤 한 번의 최종 판단만 할 수도 있습니다. 하지만 복구 가능한 후보를 더 일찍 찾고, 이후 더 많은 정보와 더 강한 처리를 이용해 다시 확인하는 데에는 실제 가치가 있습니다.

그래서 단계별 모드를 이해한다는 것은 단순히 하나의 설정을 이해하는 것이 아닙니다. 결국 FT8 최적화 자체가 무엇인지 이해하는 일입니다.

실전 해석

각 모드는 실제 운용에서 어떻게 사용해야 하는가?

많은 기술적 세부사항을 살펴봤으니 이제 다시 운용자의 언어로 돌아가 볼 필요가 있습니다.

2-Stage

매우 실용적입니다. 응답성을 유지하면서도 더 일찍 한 번 확인합니다. 최종 단계가 Late만큼 늦지 않기 때문에 불필요하게 부담이 커지는 것을 피합니다.

3-Stage

좋은 의미에서 가장 야심찬 모드입니다.

일찍 한 번 보고, 조금 뒤에 다시 보고, 마지막에는 강력한 최종 패스까지 유지합니다. CPU 여유가 충분하고 놓친 디코딩을 줄이는 것이 우선이라면 전체 패널에서 가장 흥미로운 설정 중 하나입니다.

Early

이를 단순히 약한 CPU용 대체 옵션으로만 생각해서는 안 됩니다. 매우 합리적인 안정성 전략이기도 합니다. 마지막 한 조각의 신호를 더 얻는 것보다 처리가 다음 사이클로 넘어가지 않는 것이 중요하다면 Early가 정확히 맞는 선택일 수 있습니다.

Normal

기준점입니다. 대부분의 사용자는 여기서 테스트를 시작하는 것이 좋습니다. 다른 모드와 비교하기도 가장 쉽습니다.

Late

더 오래 기다리고, 더 늦게 디코딩하며, 조금 더 많은 정보를 가지고 최종 판단을 합니다. 이론적으로는 도움이 될 수 있지만 실제로는 시스템이 여전히 안정적으로 제시간에 끝낼 수 있을 때만 유용합니다.

전체적으로 Decode Start 모드는 “개인 취향”으로 이해하기보다 서로 다른 타이밍 전략으로 보는 것이 더 정확합니다.

그렇다면 우리가 정말 최적화하는 것은 무엇인가?

평균 성능이 아니라 15초 사이클 안에서 CPU 시간을 사용하는 방식

이쯤이면 더 큰 원칙이 분명해졌을 것입니다.

FT8 최적화는 단순히 모든 것을 “더 강하게” 만드는 일이 아닙니다.

결정해야 하는 것은 다음과 같습니다.

• 얼마나 오래 기다릴 것인가
• 얼마나 자주 확인할 것인가
• 어디에서 더 가벼운 패스를 수행할 것인가
• 어디에서 더 무거운 최종 패스를 수행할 것인가
• 그리고 전체 과정이 사이클마다 계속 안정적으로 유지되는가

즉 중요한 것은 CPU 성능이 얼마나 많은가만이 아니라 그 성능이 어떻게 사용되는가입니다.

이 관점에서 Decode Start는 전체 디코더 패널에서 가장 중요한 설정 중 하나입니다. 작아 보이는 UI 옵션이 실제로는 시간 전략을 직접 표현합니다.

그래서 Decode Start를 이해하는 것은 단순히 설정 하나를 설명하는 일이 아닙니다. FT8에서 연산 자원을 어떻게 배분하는지에 대한 근본 철학을 이해하는 방법이기도 합니다.

조금 더 개인적인 이야기

내가 이 글을 쓰는 이유

지금까지는 논의를 일반적이고 기술적인 수준으로 유지하려고 했습니다. 하지만 배경을 위해 제 입장도 분명히 해 둘 필요가 있습니다.

이것은 JTDX에 가치가 없기 때문이 아닙니다. 소프트웨어는 지금 실제로 사용할 수 있는지, 충분히 성숙해 시험할 수 있는지, 그리고 현재 실질적인 도움이 되는지도 함께 평가해야 하기 때문입니다.

누군가 JTDX의 인터페이스를 정말 좋아해서 계속 사용한다면 충분히 이해할 수 있습니다. 하지만 질문이 오늘의 디코더 능력과 실제 운용 가치라면 WSJT-X 3.1 improved는 진지한 검토 대상이 되어야 합니다.

나의 운용 철학

지금까지는 일반 원칙에 집중했습니다. 이제 그 원칙이 제 실제 운용에서 어떤 선택으로 이어지는지 설명하는 것도 도움이 될 것입니다.

제 주 운용 PC는 Core i9-9900K를 사용합니다. 이 점은 중요하지만 단순히 비교적 강한 CPU라는 이유만은 아닙니다.

컴퓨터를 어떻게 설정해 두었는지도 중요합니다.

Windows 전원 설정에서 최소 프로세서 상태를 100%로 설정합니다. 즉 디코딩 부하가 생긴 뒤 CPU가 클럭을 올릴 때까지 기다리지 않습니다. 미리 높은 클럭으로 동작하며 준비된 상태를 선호합니다. 제 경우 사실상 약 4.7 GHz로 유지됩니다.

이유는 간단합니다.

FT8 디코딩은 일정한 부하가 오랫동안 계속되는 장시간 영상 렌더링과 다릅니다. 예측 가능한 간격으로 반복되는 짧고 집중적인 작업 폭발에 훨씬 가깝습니다.

이런 종류의 부하에서는 평균 벤치마크 성능만으로 모든 것을 설명할 수 없습니다. 초기 응답이 중요합니다.

CPU가 낮은 전력 상태에 있다면 시스템은 다음 과정을 거쳐야 합니다.

• 부하 감지
• 성능 상태 변경
• 클럭 상승
• 전압 조정
• 그리고 스케줄러의 반응

장시간 지속되는 부하에서는 이런 지연이 거의 무시할 만할 수 있습니다. 하지만 짧고 타이밍에 민감한 작업에서는 생각보다 큰 영향을 줄 수 있습니다.

그래서 저는 이렇게 생각합니다.

물론 이 선택에는 대가도 있습니다.

• 더 높은 전력 소비
• 더 많은 발열
• 더 낮은 효율
• 에너지 절약 관점에서는 덜 세련된 방식

하지만 스테이션 PC에서는 전력 효율의 깔끔함보다 디코딩 응답성과 안정성을 더 중요하게 생각합니다.

내 설정이 의도적으로 공격적인 이유

50 MHz가 나에게 중요하기 때문에

제 설정은 이런 철학을 꽤 명확하게 반영합니다.

• Decoder Sensitivity: Subpass
• QSO Rx Frequency Sensitivity: High
• CPU는 미리 높은 클럭으로 대기

이것은 보수적인 설정이 아니며, 보수적이라고 주장할 생각도 없습니다.

하지만 분명한 이유가 있습니다.

50 MHz는 저에게 매우 중요합니다.

6미터 밴드에서는:

• 조건이 빠르게 변할 수 있습니다
• 활동이 갑자기 증가할 수 있습니다
• 약한 신호와 강한 신호가 동시에 존재하는 경우가 많습니다
• 그리고 짧은 오프닝에서는 놓친 기회가 특히 아쉽습니다

그래서 저는 놓친 디코딩을 줄이기 위해 CPU 자원을 더 사용하는 것을 받아들입니다.

그 때문에 저는 다음을 사용합니다.

• 더 깊게 검색하기 위한 Subpass
• 후보 복구를 더 공격적으로 하기 위한 High 감도
• 그리고 순간 부하가 오기 전에 CPU를 준비된 상태로 두는 전원 설정

이것은 단순히 “더 많으면 더 좋으니 전부 올린다”는 접근이 아닙니다.

다음 요소를 바탕으로 한 의도적인 운용 전략입니다.

• 50 MHz 중시
• 충분한 CPU 여유
• 응답 속도의 중요성
• 그리고 효율보다 기회를 선택할 의향

마무리 생각

진짜 질문은 “어느 프로그램이 맞는가?”가 아니라 “어떤 튜닝 철학이 당신의 스테이션에 맞는가?”이다

이 긴 논의를 한 문장으로 줄인다면 다음과 같습니다.

이 관점에서 WSJT-X 3.1 improved는 매우 흥미로운 소프트웨어입니다. 단순히 옵션이 더 많아서가 아니라 운용자가 디코더 타이밍 전략을 의미 있게 제어할 수 있기 때문입니다.

그리고 Decode Start는 이를 가장 잘 보여 주는 예 중 하나입니다.

2-Stage, 3-Stage, Early, Normal, Late는 단순한 이름표가 아닙니다. FT8 사이클 전체에서 디코딩 노력을 서로 다르게 배분하는 전략입니다.

단계별 모드를 더 자세히 보면 그 밑에 특히 우아한 아이디어 하나가 보입니다.

마지막으로, JTDX를 진심으로 높이 평가하는 사람으로서 이렇게 말하고 싶습니다.

JTDX를 고집하는 이유가 인터페이스에 대한 선호라면 그것은 별개의 문제입니다. 하지만 오늘 실제 운용 환경에서의 디코더 능력이 관심사라면 주저할 이유가 거의 없습니다.