우리는 Qwen이 점수 산정 알고리즘을 재작성하게 했습니다 — 하지만 임상 스타일의 게이트를 통해서만 가능했습니다
요약
Qwen 모델을 활용하여 집중도 측정 알고리즘의 파라미터를 스스로 최적화하는 시스템을 구축했습니다. 모델이 제안한 변경 사항을 시뮬레이션과 엄격한 검증 게이트를 통해 검증함으로써, 신뢰할 수 있는 자동화된 알고리즘 개선 프로세스를 구현했습니다.
핵심 포인트
- Qwen 모델이 오류 로그를 분석하여 알고리즘 파라미터 변경을 제안
- 모델의 주장을 검증하기 위해 시뮬레이션을 통한 자동 검증 게이트 도입
- 데이터 프라이버시를 위해 비디오 대신 수치 데이터만 클라우드로 전송
- 검증된 결과물은 사람이 최종 채택하기 전까지 대기하는 Human-in-the-loop 구조
요약 (TL;DR) — 우리는 점수 산정 알고리즘이 스스로 개선되는 집중도 측정 시스템을 구축했습니다. Qwen3.7-Max가 오류 로그를 읽고 어떤 파라미터(parameter)를 변경할지 제안합니다. 그런 다음 우리 서버는 모델이 말하는 단 하나의 수치를 그대로 믿지 않습니다. 서버가 직접 시뮬레이션을 다시 실행하며, 0.5 퍼센트 포인트(percentage points) 이상 차이가 나는 모든 주장은 폐기됩니다. 살아남은 결과물은 훈련/홀드아웃(train/holdout) 게이트를 통과합니다. 그 단계를 통과한 결과물은 사람이 '채택(adopt)'을 클릭할 때까지 대기합니다. 우리의 첫 번째 Qwen 기반 생성에서, 홀드아웃(holdout) 공허한 시선 민감도(blank-stare sensitivity)는 회귀(regression) 없이 0.273에서 1.000으로 향상되었으며, Qwen은 이전 세대가 이미 실패했던 값을 의도적으로 피했습니다.
카메라로는 아무도 해결하고 싶어 하지 않는 문제
모든 부모와 교사는 동일한 답을 원합니다: 이 학생이 실제로 집중하고 있는가, 아니면 그냥 책 앞에 앉아 있는 것뿐인가?
카메라는 이를 알려줄 수 있습니다. 그것은 쉬운 부분입니다. 어려운 부분은 그 누구도 — 올바른 방식으로 — 자신의 아이의 얼굴을 누군가의 클라우드(cloud)로 스트리밍하는 것을 원하지 않는다는 점입니다.
그래서 우리는 아키텍처(architecture)에 엄격한 선을 그었습니다. 우리의 장치(책상 위의 작은 NIR 카메라 큐브)는 비디오를 온디바이스(on-device)로 처리하며, 절대 저장하거나 전송하지 않습니다. 장치를 떠나는 데이터는 10 Hz 기준으로 세션당 약 12,000~24,000개의 숫자 기록입니다: 시선 좌표(gaze coordinates), 페이지 내 확률(on-page probability), 동공 z-점수(pupil z-scores), 깜빡임 이벤트(blink events), PERCLOS.
클라우드는 숫자만을 봅니다. 얼굴은 절대 보지 않습니다.
이 숫자들로부터 우리는 0~100 사이의 **지속 집중 지수 (Sustained Focus Index, SFI)**를 계산합니다. 점수 함수(scoring function)는 의도적으로 순수 함수(pure function)로 설계되었습니다: score(records, param_set) → result. 동일한 입력, 동일한 파라미터(parameter), 동일한 출력. 항상 그렇습니다.
이러한 순수성이 이 포스트의 나머지 내용을 가능하게 만드는 핵심입니다.
진짜 어려운 문제: 누가 파라미터를 튜닝하는가?
이와 같은 점수 함수는 임계값(thresholds)에 따라 생사가 결정됩니다. 낮은 시선 분산(gaze dispersion)이 깊은 집중을 의미할 때와 공허한 시선(blank stare)을 의미할 때의 차이는 무엇일까요? 초당 몇 번의 사카드(saccades, 안구 급속 운동)가 독서와 멍하니 있는 상태를 구분할까요?
우리는 이것들을 수동으로 조정했습니다. 속도가 느렸고, 더 나쁜 점은 그것이 **반증 불가능(unfalsifiable)**했다는 것입니다. 임계값(threshold)을 조금씩 조정하고, 몇몇 세션을 눈으로 훑어보며, 그것이 더 나아졌다고 스스로를 설득하곤 했습니다.
2026년의 명백한 해답은 "LLM이 이를 수행하게 하는 것"입니다. 저희도 그것을 시도해 보았고, 즉시 모든 사람이 마주치는 문제에 부딪혔습니다.
LLM은 자신의 테스트 결과에 대해 기꺼이 거짓말을 할 것입니다
저희의 첫 번째 버전은 샌드박스(sandboxed) 작업 공간에서 로컬 코딩 에이전트 CLI를 실행했습니다. 이 에이전트는 파라미터(parameters)를 수정하고, 시뮬레이터(simulator)를 실행하며, 결과를 보고할 수 있었습니다.
그것은 훌륭한 결과를 보고했습니다. 그중 일부는 실제였습니다. 하지만 일부는 모델이 우리가 듣고 싶어 하는 말을 하는 것이었습니다. 즉, 측정된 수치가 아니라 모델이 추론을 통해 도출해낸 수치였습니다. 만약 당신이 에이전트에게 셸(shell)을 부여한 뒤 그 트랜스크립트(transcript)를 주의 깊게 읽어본 적이 있다면, 그 느낌이 무엇인지 정확히 알 것입니다.
더 나은 프롬프트(prompt)로는 이 문제를 해결할 수 없습니다. "테스트 결과를 환각(hallucinate)하지 마세요"라는 말은 엔지니어링 제어(engineering control)가 아닙니다.
그래서 우리는 모델을 신뢰할 수 있게 만들려는 시도를 멈추고, 모델의 신뢰성을 무관하게(irrelevant) 만들었습니다.
환각 방화벽 (The hallucination firewall)
전체 아이디어는 다음과 같으며, 거의 당황스러울 정도로 단순합니다:
LLM은 오직 어떤 파라미터를 변경할지만 결정할 수 있습니다. 그 결과로 무엇이 일어났는지는 절대로 우리에게 말할 수 없습니다.
구체적으로, 저희의 Qwen 어댑터(adapter)에서는 다음과 같습니다:
- 저희는 Qwen에게 증거를 제공합니다 — 실수 로그 (현재 파라미터가 정답(ground-truth) 레이블을 잘못 분류한 빈(bins)), 특징 통계(feature statistics), 현재 파라미터 세트, 그리고 이전 생성 이력입니다.
- Qwen은 작은 JSON을 반환합니다:
changes목록이며, 각 항목은 키(key), 목표 값(target value), 그리고 그에 대한 추론(reasoning)을 포함합니다. 그게 전부입니다. 파일 접근, 셸(shell), 도구(tools) 사용은 없습니다. - 저희 서버가 해당 변경 사항을 적용합니다 — 허용 목록(allowlist)을 통해 필터링되고, 유효한 범위 내로 제한(clamped)되며, 아무것도 조용히 누락되지 않도록 키 세트(key set)가 보존됩니다.
- 저희 서버는 프로덕션(production)에서 사용하는 것과 동일한 점수 산정 코어(scoring core)를 사용하여 시뮬레이션을 실행하고 변경 전후의 수치를 계산합니다.
- 검증기(validator)는 에이전트가 주장한 내용과 서버가 측정한 내용을 비교합니다. 편차가 ±0.5 퍼센트 포인트(percentage points)를 초과하면 → 해당 제안은 즉시 거부됩니다.
서버가 동일한 코드와 동일한 데이터로 수치를 계산하기 때문에, 5단계는 더 이상 단순히 "거짓말을 잡아내는 것"이 아닙니다. 이는 기록된 수치가 실제로 발생한 수치임을 보장하는 구조적 보증입니다.
그렇다면: 일반화(generalize)되는 것인가, 아니면 단순히 암기(memorize)한 것인가?
자가 테스트(self-test)를 통과하는 것만으로는 충분하지 않습니다. 파라미터 변경이 학습 세션(training sessions)에는 완벽하게 들어맞더라도, 새로운 상황에서는 무너질 수 있기 때문입니다.
따라서 모든 후보는 **학습/홀드아웃 분할(train/holdout split)**을 거칩니다. 에이전트가 보는 실수 로그는 오직 학습 세션에서만 가져옵니다. 게이트(gate)는 해당 제안이 전혀 영향을 미치지 않은 홀드아웃 세션(holdout sessions)을 통해 측정됩니다.
게이트 규칙은 의도적으로 보수적입니다:
홀드아웃에서의 모든 상태에 대한 민감도(sensitivity)와 특이도(specificity)는 베이스라인(baseline)의 −2 퍼센트 포인트 이내여야 하며, 동시에 최소 하나 이상의 지표가 실제로 개선되어야 합니다.
다른 무언가를 몰래 망가뜨리면서 승리만을 골라내는 체리 피킹(cherry-picking)은 허용되지 않습니다.
그리고 사람이 버튼을 클릭합니다
이 모든 과정을 거친 후에도 시스템은 멈춥니다. 통과한 후보는 PASSED 상태에 머뭅니다. 채택(Adoption)은 사람이 보고서를 열고 **채택(Adopt)**을 클릭할 때 일어납니다. 상태 머신(state machine)에는 사람을 거치지 않고 PASSED에서 ADOPTED로 가는 경로는 존재하지 않습니다.
이는 우리가 AI에 대해 소심하게 구는 것이 아닙니다. 이 수치는 부모에게 자녀에 대한 정보로 전달되기 때문입니다. 자동화(Automation)는 '제안(propose)'할 권한을 얻는 것이지, '결정(decide)'할 권한을 갖는 것이 아닙니다.
두뇌를 Qwen Cloud로 이동하기
우리의 CLI 기반 에이전트(agent)는 환각(hallucination) 문제 외에도 실질적인 문제가 하나 있었습니다. 바로 호스트 머신에 연결된 브라우저 OAuth 세션을 통해 인증한다는 점이었습니다. 이는 진화 엔진(evolution engine)이 개발자의 노트북에서만 실행될 수 있음을 의미했습니다. 즉, 배포가 불가능했습니다.
Alibaba Cloud Model Studio의 OpenAI 호환 엔드포인트를 통한 Qwen으로 전환함으로써 이러한 제약을 완전히 제거했습니다. API 키는 환경 변수(environment variable)입니다. 환경 변수는 컨테이너(container)에 들어갑니다. 갑자기 한 대의 노트북에 갇혀 있던 엔진이 서버에서 실행될 수 있게 되었습니다.
우리는 결국 두 가지 별개의 프로덕션 역할(production roles)에 Qwen을 사용하게 되었습니다:
| 역할 | 모델 | 이유 |
|---|---|---|
| 제안자 (Proposer) | qwen3.7-max | 통계적 증거에 기반한 파라미터 추론(Parameter reasoning) — 여기서는 플래그십(flagship) 수준의 추론 능력이 중요함 |
| 코치 (Coach) | qwen3.7-plus | 개인 정보가 포함되지 않은 수치 요약본을 바탕으로 한국어, 영어, 중국어로 학생/학부모 보고서를 생성함 |
(또한 스모크 테스트(smoke tests) 및 디버깅 반복 작업을 위해 qwen3.6-flash를 설정해 둡니다.)
모델별로 역할을 나누는 것은 사후 고려 사항이 아니라 실제적인 설계 고려 사항입니다. Model Studio는 모델당 무료 할당량(quota)을 부여하므로, 모델별로 역할을 분리하면 할당량 풀(quota pools)도 분리됩니다. 역할 분리와 비용 제어는 결국 동일한 결정이었음이 드러났습니다.
첫 번째 Qwen 생성에서 실제로 일어난 일
우리는 현재 파라미터 하에서 멍하게 응시하는 것(blank staring)이 집중으로 오분류되도록 설계된 18개의 합성 LAB-5 세션을 시드(seed)로 설정한 후, 한 번의 생성을 실행했습니다.
총 소요 시간: 2분 10초. (이전의 CLI 에이전트 리허설은 7분이 걸렸습니다.)
Qwen은 두 가지 변경 사항을 제안했습니다:
[{"key": "blank_stare.stare_dispersion_th", "from": 0.035, "to": 0.055},
{"key": "blank_stare.max_saccade_count_1s", "from": 0.5, "to": 0.6}]
홀드아웃(Holdout) 결과 — 제안 내용이 적용되지 않은 5개의 세션:
홀드아웃(Holdout) 결과 — 제안 내용이 적용되지 않은 5개의 세션:
| State | Sensitivity | Specificity |
|---|---|---|
| blank_stare | 0.273 → 1.000 | 1.000 → 1.000 |
| ... | ||
| Zero regressions. Gate passed. |
하지만 우리가 멈춰서 로그를 다시 읽게 만든 부분은 첫 번째 변경 사항에 첨부된 추론(reasoning)이었습니다:
"…이전에 거절되었던 0.06 / 0.062와는 다른 값으로, 홀드아웃 과적합 위험을 분산시키기 위해."_
Qwen은 생성 기록을 읽고, 이전 에이전트가 0.06을 제안했다가 거절한 것을 발견했고, 그 실패를 반복하는 것을 피하기 위해 의도적으로 분리 간격(separation gap)의 다른 지점을 선택했습니다.
아무도 그것에게 그렇게 하라고 프롬프트하지 않았습니다. 증거(evidence) 속에 있었고, 그것은 그것을 사용했습니다.
우리가 이것을 메모리 에이전트(memory agent)라고 부르는 이유
'에이전트 메모리(agent memory)'라는 버전 중에는 채팅 로그를 저장했다가 나중에 검색하는 것을 의미합니다. 그것도 괜찮지만, 여기서 일어나고 있는 일은 그렇지 않습니다.
저희 에이전트의 메모리는 점수 산정 매개변수의 버전화된 계보(versioned lineage)이며, 각 매개변수에는 그것을 정당화한 증거가 첨부되어 있습니다: 동기를 부여한 실수 로그, 서버에서 계산된 전/후 수치, 게이트 판결, 인간이 채택했는지 여부, 그리고 나중에 롤백되었는지 여부입니다.
그것은 감사(audit)할 수 있는 메모리입니다. 부모에게 보여지는 SFI가 변경될 때, 세대(generation)를 거슬러 올라가 어떤 변경 사항이 그것을 야기했는지, 무엇의 증거가 동기를 부여했는지, 보지 못한 데이터로 무엇을 측정했는지, 그리고 누가 승인했는지를 정확히 볼 수 있습니다.
경험은 기록(transcript)으로서가 아니라 증거로서 축적됩니다.
일일 증거가 나오는 곳
사람들을 놀라게 하는 한 가지는, 이 엔진에 입력되는 정답(ground truth)이 합성 데이터(synthetic)로만 이루어져 있거나 크라우드 소싱(crowd-labeled)으로 라벨링된 것이 아니라는 점입니다. 우리 팀은 종합병원에서 IRB(기관생명윤리위원회) 승인을 받은 검증 프로그램을 운영하며, 매일 감독하에 동의를 얻은 세션을 진행하여 데이터를 수집합니다. 각 세션은 지시된 실험입니다. 조사자가 피험자에게 실시간으로 집중(focus) (실제로 읽기), 멍하게 응시(blank-stare) (책을 계속 보고 있지만 읽는 것은 중단), 시선 돌리기(look away) (과업을 완전히 이탈) 등을 지시하며, 명령이 발화되는 순간마다 이를 기록합니다. 따라서 10Hz의 안구/동공 스트림(stream)은 초 단위로 정답(ground truth)과 동기화됩니다. 이 라벨링 방식은 우리 API에서 말 그대로 realtime_instructed라고 불립니다. 이러한 라벨을 바탕으로 진화하는 것은 바로 해석 방법(interpretation method) 그 자체입니다. 즉, 시선 분산(gaze dispersion), 사카드(saccades, 급속 안구 운동), 동공 역학(pupil dynamics)이 정신 상태와 어떻게 매핑되는지를 학습합니다.
우리는 어린이의 주의력을 측정하는 윤리적 및 안전성 문제를 회피하기보다, 제도적 검토 프로세스를 통해 정면으로 마주하기로 했습니다. 그 결과 아키텍처(architectural) 측면에서는 진화 서버(evolution server)가 지속적인 영양분을 공급받게 되었습니다. 매일 제공되는 임상 정답(clinical ground truth)은 신선한 증거가 되며, 신선한 증거는 새로운 세대의 후보가 됩니다. 제품 소비자가 마주하는 것은 책상 위의 작은 큐브입니다. 이 제품을 매일 더 똑똑하게 만드는 것은 바로 이 루프(loop)입니다.
이는 또한 두 서버를 분리한 이유를 설명해 줍니다. 운영 서버(operations server)가 곧 제품입니다. 진화 서버(evolution server)는 오직 제품을 성장시키기 위해서만 존재합니다. 진화 서버는 오류 로그, 계보(lineage), 제안자(proposer), 그리고 게이트(gates)를 관리합니다. 성장은 성장하는 대상과는 별개의 시스템입니다.
(참고로, 이 생태계는 Alibaba의 엔드 투 엔드(end to end) 구조입니다. 큐브는 Alibaba의 AI 소싱 플랫폼인 Accio를 통해 Alibaba 생태계의 PCBA 공급업체로부터 제조를 위해 조달되며, 백엔드는 ECS를 사용하고, 모델은 Model Studio 상의 Qwen을 사용합니다.)
우리가 당신에게 훔치라고 말하고 싶은 것
만약 당신이 LLM(대규모 언어 모델)이 사람들이 신뢰하는 수치를 생성하는 시스템을 수정하는 무언가를 구축하고 있다면:
- 모델이 보고하게 하지 말고, 선택하게 하세요. 결정(검증 비용이 저렴함)과 측정(신뢰 비용이 비쌈)을 분리하십시오. 동일한 엔티티가 두 가지를 모두 수행하게 해서는 안 됩니다.
- 산문을 검증하지 말고, 재계산하십시오. "이 주장이 그럴듯해 보이는가?"라고 묻지 마십시오. 다시 실행하십시오. 자신의 실행 결과에 대해 허용 오차(Tolerance check)를 확인하는 것이 그 어떤 프롬프트 엔지니어링 (Prompt Engineering)보다 가치 있습니다.
- 제안(Proposal)이 건드릴 수 없는 데이터를 남겨두십시오. 가시적인 데이터에 대한 자기 보고식(Self-reported) 개선은 개선이 아닙니다.
- 사람을 첫 번째 단계가 아닌 마지막 단계에 배치하십시오. 모든 제안을 검토한다면 당신은 느린 인간을 만든 것입니다. 기계적 검증(Mechanical verification)과 일반화 게이트(Generalization gate)를 통과한 것만 검토한다면, 당신은 레버리지 (Leverage)를 구축한 것입니다.
- 모델 간에 역할을 분리하십시오. 작업별로 더 적합한 모델을 선택하고, Model Studio에서는 무료 할당량 풀 (Free-quota pools)을 분리하십시오.
Qwen Cloud와 함께 Global AI Hackathon Series를 위해 제작되었습니다. 모든 것은 Alibaba Cloud에서 실행됩니다 — 스택을 위한 ECS, Qwen 모델을 위한 Model Studio (싱가포르).
Code: github.com/S-O-A-TECH/concentration-cube-cloud · Live demo: http://47.84.139.15:8200 · Track: MemoryAgent
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기