deepxrlab · Dual-Task Cognitive Training · reference

Double Decision 변형 / Peak 변형 — 프로토타입 설계 노트

위치: double-decision-st/docs/planning/

1. 배경

두뇌 훈련 앱을 카피캣 형태로 만들되, 원본 과제를 그대로 베끼지 않고 훈련 자극 구조는 유지하고 세션 구조·난이도 축·지표를 바꾼 변형을 만드는 것이 목표.

벤치마킹 대상으로 정리해 둔 것:

관심사로 남아 있는 것: 무료 구간을 어디까지 열고 페이월을 어디에 두는가(아래 6절, 아직 미결정).

주의: 이 계열 앱들의 "훈련 효과"는 학계에서 논쟁이 있는 영역입니다. 프로토타입 단계에서는 효과 주장을 마케팅 문구로 쓰지 말고, 측정 가능한 수행 지표(반응시간·정확도·역치)만 사용자에게 보여주는 쪽이 안전합니다.

---

2. 이번 세션에서 정한 것 (결정 로그)

---

3. 프로토타입 A — prototypes/double-decision-variant.html

3.1 과제 구조 (원본과 동일하게 가져온 뼈대)

중앙 과제와 주변 과제를 동시에 요구하는 이중과제. 둘 다 맞혀야 정답으로 처리한다.

1. 응시점 (500 ms)
2. 자극 제시 (노출시간 E, 적응적으로 변함)
   • 중앙: 승용차 / 트럭 판별
   • 주변: 8방향 링 위 한 곳에 초록 표지판(타깃) + 방해자극
3. 마스킹 (250 ms) — 잔상으로 푸는 것을 막는 핵심 단계
4. 응답 ①: 중앙 차량 — 화면의 선택지 클릭 또는 F / J (캔버스 밖 버튼에서 옮겼다)
5. 응답 ②: 표지판이 있던 방향 — 8방향 클릭 또는 Q W E / A D / Z X C
6. 피드백 (420 ms)

3.2 변형 포인트

1. 세션 구조 2종 분리 — 적응형 트레이닝(24 stage)과 60초 스코어어택.
2. 난이도 축의 확장 — 원본이 주로 노출시간 한 축으로 조이는 데 비해, 여기서는 노출시간 × 편심도 × 방해자극 유사도 3축을 노출시간에 연동해 함께 움직인다.
3. 콤보 = 난이도 — 스코어어택에서는 잘할수록 노출시간이 짧아지고 그만큼 점당 배점이 커진다. 난이도 선택 UI 없이 플레이어가 스스로 자기 수준으로 수렴한다.

3.2-1 M-스케일링 — 편심도가 '시력'을 재지 않게

원래 구현은 표적 표지판을 모든 편심도에서 지름 34px 로 고정했다. 편심도는 108 / 144 / 180px (캔버스 반경 대비 0.30 / 0.40 / 0.50)로 커지는데 크기는 그대로였다.

주변 시력은 편심도가 커질수록 떨어진다. 그래서 고정 크기로 두면 3단계에서 늘어난 난이도의 일부가 '주의 범위'가 아니라 시력 때문이 되고, 처리속도 역치가 무엇을 재는지 흐려진다.

표준 대응이 M-스케일링(cortical magnification scaling) — 자극 크기를 편심도에 따라 키워 "보이는 정도"를 맞춘 뒤, 남는 차이만 주의 효과로 읽는 것이다. 여러 과제(대비 민감도·시력·시각 탐색)에서 이렇게 크기를 맞추면 편심도에 따른 수행 차이가 사라진다고 보고돼 있다.

적용식: 배수 = (1 + e/E2) / (1 + e₀/E2), E2 = 140px, e₀ = 108px(1단계 링) → 1단계 1.00 · 2단계 1.15 · 3단계 1.29 배. 표적과 방해자극에 같이 적용해 탐색 부하는 그대로 둔다. 자극이 커지므로 최소 간격도 48 → 58px 로 넓혔다.

• 끄려면 파일 상단 P.MSCALE = false — 옛 동작(고정 크기)으로 돌아간다
• ⚠️ 이걸 켜고 끄면 역치의 절대값이 달라진다. 이전 세션과 비교할 때 주의
• 위치 응답 화면의 방향 버튼(반지름 30 → 36px, 화살표 20 → 27px)도 함께 키웠다. 그 화면은 측정과 무관한 UI 라 크게 잡아도 자유롭고, §8 의 "모바일 터치 미검증"에도 도움이 된다

3.2-2 응답 표면을 캔버스 하나로 통일

원래는 중앙 판별만 캔버스 밖 DOM 버튼이고 위치 응답은 캔버스 클릭이었다. 캔버스에는 차량 두 대가 그려져 있는데 눌리지 않아, "눌릴 것처럼 보이는데 안 눌리는" 상태였다. 측정상의 이유가 있는지 확인했으나 없었다 — RT 는 마스킹 종료 시점부터 재므로 어느 표면이든 같고, 원본 Double Decision 도 화면의 차량을 직접 고르게 한다.

• 캔버스의 차량 선택지를 클릭 가능하게 했다(150×104px 판정 상자, centralBox() 가 그리기와 히트 테스트에 같은 값을 쓴다). 선택지처럼 보이도록 테두리·배경도 넣었다
• 아래쪽 DOM 버튼은 없앴다 — 위치 응답과 마찬가지로 안내 문구만 남긴다. 응답 표면이 하나여야 마우스 이동 거리가 RT 에 섞이지 않는다
• 키보드(F / J)는 그대로다

3.2-3 모바일 기준 — 키보드 없는 조작

이 프로젝트의 목표는 모바일 앱이다. 키보드가 없는 기기가 기준이므로 모든 조작에 터치 경로가 있어야 한다. 점검해 보니 키보드 전용이 하나 남아 있었고(⎋ 일시정지), UI 곳곳이 키를 안내하고 있었다.

손가락은 정확히 짚지 못한다 — 최근접 선택으로 바꿨다.

• A 8방향: 반지름 36 → 40px, 판정은 가장 가까운 슬롯(단 LOC_BTN_R × 1.5 밖이면 무시). 390px 폭 화면에서 버튼 자체는 ≈40 CSS px 지만 유효 타겟은 ≈60 CSS px 이 된다
• C 원 선택: DOT_R+9 고정 반경 → 가장 가까운 원(DOT_R × 2.4 밖이면 무시). 원 사이 최소 간격이 DOT_R × 2.1 이라 고정 반경으로는 넓힐 수 없었다 — 최근접이면 겹칠 걱정이 없다

키 입력 핸들러는 남겨 뒀다. PC 에서 개발·검증할 때 쓰지만 UI 에는 노출하지 않는다 — 각 파일 §입력 절 머리에 그 이유를 적어 뒀다.

3.3 난이도 티어

방해자극은 기각표집으로 서로 48px 이상 떨어뜨려 배치한다(겹쳐서 뭉치면 탐색 과제가 아니라 그냥 잡음이 된다).

3.4 적응 알고리즘

• 3-up / 1-down 계단식: 3연속 정답 → E × 0.82, 1회 오답 → E × 1.32
• 범위: 16 ~ 900 ms, 시작 320 ms
• 이 비대칭 계단은 약 79% 정답률 지점으로 수렴한다(심리물리 표준 절차).
• 처리속도 역치 = 마지막 반전점 6개의 기하평균.

3.5 점수식 (스코어어택)

정답  : (60 + 140×난이도계수 + 60×속도계수) × (1 + min(2.0, 콤보×0.12))
        난이도계수 = (900 − 노출시간)/900,  속도계수 = max(0, 1200 − RT)/1200
부분정답(한쪽만) : +10
오답  : −25 (0 미만으로는 안 내려감)

---

4. 프로토타입 B — prototypes/peak-switch-variant.html (Switch & Stop)

4.1 과제 구조

카드 한 장에 색(파랑/주황)과 모양(원/사각)이 함께 들어 있고, 규칙 배너가 가리키는 속성만 보고 좌/우를 고른다.

1. 규칙 배너 선행 제시 (340 ms, CSI)
2. 카드 제시 — 제한시간 D 안에 응답 (F/← , J/→)
3. 피드백 (340 ms) + stage 간 간격 (260 ms)

세 종류의 억제 요구가 겹쳐 있다.

• 전환(switch): 규칙이 예고 없이 색 ↔ 모양으로 바뀐다 (배너에 ↻ 표시).
• 역방향(reverse): 배너에 역이 붙으면 정답의 반대쪽을 눌러야 한다.
• 노고(no-go): 회색 점선 테두리 + ⛔ 가 보이면 아무것도 누르지 않고 700 ms를 버텨야 한다.

4.2 변형 포인트

1. 보통 따로 만드는 세 과제(과제 전환 / 역방향 규칙 / 고고-노고)를 한 과제에 통합해, 한 세션에서 전환 비용과 충동 억제를 동시에 측정한다.
2. 난이도 축 = 제한시간 × 전환확률 × 노고비율 × 역방향비율 — 프로토타입 A의 축(노출시간)과 의도적으로 겹치지 않게 설계했다. 두 과제를 한 앱에 넣었을 때 "비슷한 걸 두 번 한다"는 인상을 피하기 위한 것.
3. 스위치 코스트를 사용자에게 그대로 보여준다 — 총점 대신 "전환 stage RT − 반복 stage RT"를 리포트해서 훈련의 대상이 무엇인지 드러낸다.

4.3 레벨 테이블

4.4 적응 / 점수

• 제한시간 D: 3연속 정답 → ×0.88, 오답 → ×1.22, 범위 420 ~ 2600 ms, 시작 1600 ms
• 점수: 정답 (50 + 90×속도 + 전환보너스 25 + 역방향보너스 25) × 콤보배수, 노고 성공 +80, 노고 실패 −60(가장 큰 감점), 오답/시간초과 −20

억제 실패에 가장 큰 페널티를 준 이유: 점수를 올리려면 무작정 빨리 누르는 전략이 유리해지는데, 그러면 과제가 측정하려는 억제 요소가 무력화된다.

---

5. 측정 지표 / 데이터 스키마

두 프로토타입 모두 stage 단위 로그를 메모리에 쌓고 세션 종료 시 요약한다.

A (Double Decision 변형) — {no, expo, tier, okC, okD, both, rt, rtCentral} → 양쪽 정답률 / 중앙 판별 정확도 / 주변 위치 정확도 / 처리속도 역치(ms) / 중앙 응답 RT 중앙값 / 최고 콤보 / 도달 난이도

B (Switch & Stop) — {no, rule, isSwitch, nogo, rev, congruent, outcome, ok, rt, deadline} outcome ∈ {hit, wrong, miss, correctReject, commission} → 전체·Go 정확도 / No-go 억제 성공률 / 커미션 오류 수 / RT 중앙값 / 전환·반복 RT / 스위치 코스트 / 도달 제한시간

이 두 세트가 앱 단계에서 그대로 서버 스키마의 초안이 된다. stage 로그만 저장하면 위 요약 지표는 전부 사후 계산이 가능하므로, 지표 정의가 바뀌어도 과거 데이터를 다시 쓸 수 있다.

---

6. 아직 정하지 않은 것 — 무료 구간과 페이월

프로토타입에는 페이월이 들어 있지 않다. 검토해 볼 만한 선택지:

마지막 안이 이번 구조와 가장 잘 맞는다 — 스코어어택은 바이럴·재방문용으로 전부 열고, 적응형 트레이닝과 지표 리포트를 유료로 두는 형태. 다만 결정 전에 각 모드의 실제 리텐션을 봐야 한다.

---

7. 검증

헤드리스 Chromium(Playwright)으로 두 프로토타입을 자동 플레이해 확인했다.

• A: 트레이닝 24 stage 완주 → 리포트 정상 출력, 스코어어택 60초 소진 후 종료 정상
• B: 트레이닝 40 stage 완주 → 노고 8 stage 중 커미션 0, 전환 16 stage, 스위치 코스트 산출 정상
• 콘솔 에러 / 페이지 예외: 없음
• 화면 캡처로 자극·응답·피드백·리포트 4개 화면의 레이아웃을 1440×900에서 확인(오버레이 잘림, 캔버스 세로 초과 문제는 수정 완료)

봇은 즉시 응답하므로 RT·점수의 절대값은 의미가 없다. 밸런싱(특히 A의 스코어어택 배점)은 사람 플레이로 다시 봐야 한다.

---

8. 알려진 한계 / 다음 단계

• [~] 모바일 조작 — 키보드 전용 경로 제거·최근접 선택 도입은 끝났다(§3.2-3). 실제 기기 검증은 아직
• [ ] 세션 기록이 메모리에만 있고 저장되지 않음 → 로컬 저장 또는 서버 연동 필요
• [ ] A의 노출시간은 requestAnimationFrame 기준이라 화면 주사율에 묶임(60Hz에서 최소 약 17 ms). 정밀 측정용이 아니라 훈련용이라 실용상 문제는 없지만, 지표를 비교할 때는 기기 차이를 감안해야 함
• [ ] 표준화 점수(연령대 대비 백분위) 없음 — 사용자에게 보여줄 "성장"의 형태를 아직 정하지 않음
• [ ] 여러 세션에 걸친 추이 그래프 / 일일 훈련 스케줄 미구현
• [ ] 사운드·햅틱 등 피드백 연출 없음

---

8-1. 맛보기(guided demo)

세 프로토타입 모두 메뉴에 ▶ 맛보기 버튼이 생겼다. 실제 루프를 그대로 쓰되 가장 쉬운 설정 고정 · 점수 없음 · 계단 없음 · 기록 없음이고, 단계마다 지금 무엇을 하는지 자막이 붙는다.

첫 stage 는 시범이다 — 입력을 막고 정답을 대신 골라 보여준다(S.demoShow). 나머지 stage 는 직접 한다.

맛보기 전용 대기 시간을 따로 둔다 — 훈련 타이밍을 그대로 쓰면 자막을 읽기 전에 화면이 넘어간다. 특히 피드백이 제일 짧아 스쳐 지나갔다(A 420ms · B 600ms · C 620ms → 전부 2,600ms). 그 밖에 A 응시점 500→1,000 · 가림막 250→800, B 규칙 배너 340→1,500 · ⛔ 유지 700→1,600, C 표적 지정 1,100→1,900 · 정지 350→800, 시범의 '대신 고르기 전 대기' 는 3본 모두 2,400ms.

20~34초면 끝난다. 로직 하네스가 맛보기가 로그·점수·난이도를 건드리지 않는지와 시범 중 입력이 실제로 막히는지를 단언으로 검사한다.

---

8-2. 실행 런처 prototypes/index.html

3본을 한 페이지에서 골라 실행한다. 본체는 손대지 않았다 — 런처는 껍데기이고 프로토타입은 그대로 독립 HTML 이다.

검증 (Chrome)

로컬 HTTP(python -m http.server)로 띄워 확인했다 — 브라우저 확장이 file:// 을 거부해 그쪽은 미검증이다.

• 목록 → A/B/C 실행 → ← 목록 → 기기 뒤로 가기: 전부 정상. iframe 은 나갈 때 제거되어 실행이 멈춘다
• 히스토리 오염 없음(4단계 조작에 항목 +1)
• 런처가 세로를 약 49px 먹는다 — 1707×791 기준 A 는 538→505 로 줄고 잘림은 없다
• 콘솔 에러 없음
• ⚠️ 짧고 넓은 창(높이 435px)에서는 잘린다. 이건 런처 탓이 아니라 본체가 원래 그렇다 — #app{max-width:min(860px,68vh)} 라 창이 납작하면 폭까지 같이 줄어 HUD 가 2줄로 접힌다. 세로가 짧은 창은 원래 대상이 아니다(모바일 세로 기준)

---

9. 파일

모두 외부 의존성이 없다. index.html 을 더블클릭하면 목록이 뜨고 거기서 고른다(본체를 직접 열어도 된다). 파라미터는 각 파일 상단의 const P = {...} 와 티어/레벨 테이블에서 조정한다.