한 달여, 클로드와 함께 퀀트 시스템을 설계해 왔다. 그리고 오늘 드디어 R1(첫 구현)에 진입했다. 위 그림은 그 결과물의 골격 — 프런트엔드 React, 백엔드 Spring Boot, 그리고 데이터·백테스트·사이징을 담당하는 Python 퀀트 엔진이 함께 도는 구조다. 이 글은 “설계를 어디까지 했을 때 아웃풋이 정확해지는가”에 대한 오늘까지의 기록이다.
1. 같은 손으로, 두 번 그린 화면
처음엔 빨랐다. 상세설계를 건너뛰고 곧장 화면설계로 넘어가 9개 화면을 그렸다. 그런데 1,900개의 요구를 9개 화면에 담을 수는 없었다. 정보구조도, 메뉴도 없이 와이어프레임으로 점프한 결과는 — 폐기였다.
두 번째는 순서를 지켰다. 요구를 적극적으로 끌어내고 → 사용자 여정 → 메뉴 구조·정보설계(IA) → UML 식별 → 화면 명세 → 유스케이스(UC)까지 쌓은 뒤에야 화면을 그렸다. 결과는 질적으로도 양적으로도 달랐다.
① 바로 화면설계 (폐기)
정보구조·메뉴 없음 · 1,900 요구 대비 절대 부족 · 화면이 무엇을 근거로 존재하는지 추적 불가 · 재작업
② 명세 기반 설계 (정합)
메뉴 162노드 · UC 75건 풀명세 · 요구 1,189건 100% 추적 · 모든 화면이 요구·UC·메뉴에 연결(고아 0) · 안전선 강제
숫자만 5배가 아니다. 두 번째 화면들은 전부 추적된다. 어떤 화면이든 “이건 어느 요구에서 나왔고, 어느 유스케이스를 실현하며, 어느 메뉴에 걸리는가”가 데이터로 증명된다. 화면 위를 흐르는 사용자 동작은 그대로 유스케이스의 기본·대안·예외 흐름이 되고, 그 흐름의 길목마다 안전선(매수 전 점검·종목당 한도·손절 의무·생존 레짐 차단)이 박혀 우회되지 않는다.
2. 오늘 하루는 어떻게 정리됐나 — 상태전이도
오늘 세션 전체를 하나의 상태전이도(STD)로 정리했다. 흥미로운 건, 하나의 일하는 루프가 반복됐다는 점이다 — 헌장/계획 → 저작(병렬) → 디스크·DB 검증 → 빈곳/갭 발견 → 보완 → 수렴. 그리고 이 루프가 메뉴·화면·UC·DB적재·정합성감사·R1 구현까지 6개 도메인을 차례로 통과했다.
3. 그려진 화면들 — 모바일
주린이는 길을 잃지 않아야 한다. 시드머니 하나로 시작해, 오늘 할 일은 한 줄, 평단가는 숨기고 논거만 보여준다. 충동(추격·물타기·익절)은 설명이 아니라 구조로 차단한다.
자동으로 넘어갑니다 · 화면 위에 올리면 멈추고, 누르면 확대됩니다
4. 그려진 화면들 — 데스크톱(전문가)
같은 엔진, 표현만 진화한다. 전문가에겐 정밀 수치와 불확실성 밴드를, 운영자에겐 읽기 우선의 관리 콘솔을. 다크 모드와 2026년 UI 트렌드(설명가능 AI·내러티브·공간감)를 입히되, 안전선은 어떤 트렌드에도 양보하지 않는다.
자동으로 넘어갑니다 · 화면 위에 올리면 멈추고, 누르면 확대됩니다
5. 남은 일 — 그리고 다음
R1의 퀀트 코어는 이미 실제 데이터로 돈다. 수집 → 백테스트(비용·세후·미래참조 방지) → 페이퍼 매매가 e2e로 작동하고, 가드레일은 위반 주문을 실제로 차단한다. 남은 것은 앱 레이어를 끝까지 잇는 일이다.
- Spring Boot 백엔드 도커 빌드 · ars-mysql 연결
- Spring 도메인 ↔ Python 퀀트 엔진 연결(REST)
- 온보딩(시드입력→단일화면) e2e 관통
- 잔여 미세 결함 흡수 · 설치 가이드 · 감내손실/마켓필터 설정
아직 개발 중이다. 그러나 설계가 추적까지 무결하게 섰기에, 이제 무엇을 바꿔도 그 파급을 한 줄의 질의로 잡아낼 수 있다. 빠른 길이 아니라 정확한 길로 — R1은 그렇게 시작됐다.