가격·거래량·재무 데이터를 종합한 매수/관망/매도 신호와 확신도 %, 그리고 모든 판단의 적중률을 투명하게 공개하는 데이터 기반 주식 판단 플랫폼.

포지셔닝

InverseOne 은 한국 주식 시장에서 매일의 매수·관망·매도 판단을 신호등 형태로 정리해주는 데이터 기반 인텔리전스 플랫폼입니다. 분석 의견이나 시장 소음 대신, 가격·거래량·재무 데이터에서 도출된 신호와 그 신호의 확신도, 그리고 같은 신호가 과거에 얼마나 적중했는지를 한 페이지에서 함께 보여주는 구조로 설계했습니다.

시장과 문제 정의

개인 투자자는 매일 노출되는 정보의 양에 비해, “지금 행동할 만한가” 라는 결정을 내릴 수 있는 비교 가능한 근거가 부족합니다. 종목 토론은 의견의 형태로 흩어져 있고, 증권사 리포트는 결론은 있지만 사후 검증이 닫혀 있고, 무료 차트 도구는 지표만 보여줄 뿐 그 지표의 과거 적중률은 보여주지 않습니다.

InverseOne 은 정보의 양보다 판단의 비교 가능성 과 사후 검증의 투명성 을 핵심 가치로 두고 출발했습니다. 같은 화면 안에서 (1) 지금 어떤 신호가 났는지, (2) 그 신호를 얼마나 신뢰할 수 있는지(확신도), (3) 같은 종류의 신호가 과거에 얼마나 적중했는지(트랙레코드) 를 비교 가능한 지표로 노출합니다.

핵심 타깃과 페르소나

입문자(Layer 0 사용자) — 신호등과 한 줄 요약만 보고 빠른 판단을 원함. 매수/관망/매도와 확신도 % 만 봐도 판단의 출발점이 잡힘
중급자(Layer 1~2 사용자) — 신호의 근거(어떤 지표가 발화했는지), 유사 상황의 과거 결과, 기관 컨센서스 이탈 여부까지 직접 검증하고 싶음
검증 중시 사용자 — 단발 추천보다 “당신 시스템의 적중률은 얼마인가” 를 묻는 사용자. /performance 페이지의 캘리브레이션 곡선과 기관 대비 성과 비교가 진입 동기

세 페르소나가 같은 페이지에서 progressive disclosure 로 자기 깊이만큼 정보를 가져갈 수 있게 설계했습니다. Layer 0(항상 보임) → Layer 1(스크롤·1클릭) → Layer 2(탭 전환).

가치 제안과 차별점

판단·근거·검증을 한 페이지에 통합 — 다른 도구는 차트만, 또는 의견만, 또는 적중률만 보여줍니다. InverseOne 은 종목 상세 페이지에서 신호등 + 확신도 + 한 줄 요약 + 발화한 지표 상세 + 유사상황 과거 통계 + 기관 컨센서스 + 매수 CTA + 면책을 같은 흐름 안에 둔다.
확신도(confidence)를 % 로 노출 — 결론만 던지지 않고 “이 신호는 60% 확신도, 저 신호는 85% 확신도” 라고 명시. 같은 매수 신호도 강도가 다르다는 사실을 사용자가 즉시 비교 가능
모든 판단의 적중률 공개 — /performance 페이지가 캘리브레이션 곡선(70% 확신도 신호의 실제 적중률은?)과 기관 컨센서스 대비 성과 비교를 매일 갱신해 노출. 추천 시스템의 신뢰를 의견이 아니라 데이터로 검증
법적 안전 어휘를 빌드 단계에서 강제 — “AI”, “추천”, “목표가”, “손절선”, “보장” 같은 단어를 코드 레벨 린트로 차단. 빌드 시 자동 검출. 핀테크 광고 가이드라인을 시스템에 박았다

핵심 사용자 흐름

진입: 홈의 오늘의 신호 / 판단 변경 / 컨센서스 이탈 섹션 또는 /stocks 8-컬럼 테이블에서 시작
검증: 종목 상세에서 신호등 → 확신도 → 한 줄 요약(Layer 0) → 발화 지표·차트·유사상황·컨센서스(Layer 1) → 지표 상세 패널·백테스트 케이스(Layer 2) 순서로 깊이 진입
행동: 종목 상세 sticky CTA (매수/매도 버튼) 로 제휴 증권사 모달 진입 (홈/리스트엔 CTA 없음 — 행동 의도가 분명한 사용자에게만 노출)
재방문: /performance 의 캘리브레이션 갱신 → 신호 시스템의 신뢰도 검증 → 다음 진입 동기 형성

Progressive disclosure — 한 페이지에서 입문자→중급자→검증자 모두 흡수

flowchart LR
    L0["Layer 0 — 항상 보임
━━━━━━━━━━━
· 신호등(매수·관망·매도)
· 확신도 %
· LLM 한 줄 요약
· 제휴 CTA
· 면책 문구"]
    L1["Layer 1 — 스크롤·1클릭
━━━━━━━━━━━
· 가격 차트
· 발화 지표 바
· 유사상황 통계
· 기관 컨센서스"]
    L2["Layer 2 — 2클릭+
━━━━━━━━━━━
· 지표 상세 패널
· 백테스트 개별 케이스
· 알림 (Pro 잠금)"]

    L0 -->|입문자는 여기서 끝| L1
    L1 -->|중급자가 검증| L2

같은 화면 안에서 빠른 판단과 깊은 검증을 동시에 흡수한다는 점이 페이지 분리 모델 대비 핵심 차별점.

비즈니스 모델 가설

수익화는 단계적으로 검증할 계획이며, 현재는 트랙레코드와 사용자 친밀도 자산화 단계입니다.

증권사 제휴 (실행 중) — 매수/매도 CTA 가 실제 증권사 매매 페이지로 연결되는 affiliate 구조. CTA 위치를 종목 상세에만 한정해 (홈/리스트엔 노출 안 함) 행동 의도가 분명한 사용자에게만 노출
Pro 티어 (가설) — 트랙레코드 3~6개월 누적 후 검증 예정. 후보 기능: 사용자별 알림(특정 신호 변경/유사상황 hit 시 푸시), 종목별 캘리브레이션, 저장 필터
시장 확장 — 미국·일본·암호화폐로 동일 신호 엔진 재사용. 한국에서 검증된 적중률을 다른 시장으로 이식하는 형태

시스템 아키텍처 (기획 결정을 시스템으로)

기획적으로 무거운 결정 두 가지가 시스템 구조를 결정했습니다.

1. “결론과 적중률을 같은 페이지에서 동시에 보여줘야 한다” → 종목 상세 한 화면에서 (a) 오늘의 신호 (b) 그 신호의 확신도 (c) 같은 신호가 과거에 적중한 횟수 를 동시 fetch · 동시 렌더. 별도 페이지로 분리하지 않은 이유: 검증을 다른 화면에 두는 순간 사용자는 결론만 보고 떠난다. 같은 페이지 안에서 progressive disclosure 로 빠른 판단과 깊은 검증을 모두 흡수.

2. “트랙레코드는 매일 자동 누적되고 누구나 검증 가능해야 한다” → 신호 생성 스케줄러가 매일 종가 후 실행되고, 적중 여부는 다음 영업일 종가 시점에 그 신호의 결과를 평가해 DB 에 저장. /performance 페이지가 누적 데이터를 그대로 노출. 신호를 만든 사람과 적중률을 채점하는 사람이 같은 코드라는 것이 핵심.

신호 생성 → 사용자 노출 파이프라인

flowchart TD
    S1[일별 스케줄러
시장 종가 후 트리거]
    S2[일별 스케줄러
다음 영업일 트리거]
    API[Hono API
AWS Lightsail · 9 services 공용]
    DB[(MySQL
stocks · judgments
firings · similar_situations)]
    Cache[in-process
memory cache 5min]
    CDN[CloudFront
inverseone.com]
    User[사용자
Astro Island Architecture]
    Crawler[SNS 크롤러
정적 OG buy/hold/sell]

    S1 -->|가격·거래량·재무 fetch
지표 발화 + 확신도 산출| API
    API --> DB
    S2 -->|어제 신호 채점
calibration bands 갱신| API
    DB --> API
    API --> Cache
    Cache --> CDN
    CDN --> User
    CDN --> Crawler

신호 생성과 사후 채점이 같은 API 코드를 통과하므로 “결론” 과 “검증” 의 데이터 출처가 분리되지 않는다.

기술 결정과 트레이드오프

Frontend: Astro 5 + React 19 (Island Architecture) + TypeScript 5.9 + S3 + CloudFront. Next.js → Vite SPA → Astro 순으로 진화. Astro output: 'static' + client:load React island 구조로 전환 — 상호작용 없는 페이지(About, FAQ, Privacy 등)는 JS 없이 순수 HTML 로 서빙, 상호작용이 필요한 부분만 island 로 hydration. SNS OG 메타는 Astro <head> 슬롯에서 처리. 호스팅 비용 · 콜드 스타트 · 플랫폼 lock-in 유지. 종목별 동적 OG 이미지(Satori 합성)는 후속 과제로 유보
Backend: Hono on Node + PM2 on AWS Lightsail. 9개 서비스가 동일 core 를 공유하는 host-routing 구조 (api.inverseone.com/v1/*). 서버리스로 쪼갰다면 콜드 스타트 + 인프라 비용이 N배. 단일 warm 프로세스가 적중률 cron 같은 batch 작업과 동거하기 좋은 구조
DB: MySQL 8.0 + greenfield 스키마. 기존 Neon/Drizzle (Next.js 시절) 데이터는 이전하지 않고 새 스키마로 재시작. 컴포지트 인덱스 + DATETIME 비교가 핵심이라 Postgres 대비 의사결정에 영향 없음
상태 관리: TanStack Query + 로컬 useState. 전역 store 없음. 데이터 90% 가 서버 fetch 이므로 클라이언트 store 가 부담만 됨
테마 시스템: Tailwind v4 + CSS 변수 토큰 (tokens.css) 기반 라이트/다크 듀얼 테마. dark: Tailwind 변형 금지, hardcoded hex 금지를 빌드 린트(theme-lint.mjs)로 강제 — 신규 컴포넌트가 자동으로 듀얼 테마 호환
법적 어휘 차단: “AI”, “추천”, “목표가”, “손절선”, “보장” 5종을 legal-lint.mjs 가 build prebuild 에서 차단. 광고법상 안전선을 코드 단계 가드레일로 박은 결정
포기한 것: 사용자 인증 (MVP 단계에서 운영 부담만 키움), 실시간 가격 푸시 (일별 신호이므로 불필요), 모바일 네이티브 앱 (Expo 코드는 frozen, 웹 PWA 검증 후 해동 결정)

운영 자동화

1인 운영을 가능하게 만드는 자동화 layer:

일별 신호 자동 생성 — 시장 종가 후 토큰 인증된 스케줄러가 신호 생성 엔드포인트를 호출. 가격·거래량·재무 데이터 fetch + 지표 발화 평가 + 확신도 산출 + DB 저장. 다음날 사용자가 보는 신호는 어젯밤 자동 생성된 결과
적중 채점 자동화 — 어제의 신호를 오늘 종가 시점에 채점해 hit/miss 기록. 캘리브레이션 곡선과 누적 적중률이 사용자가 보는 그 시점에 항상 최신
컨센서스 비교 — 기관 컨센서스 데이터를 주기적으로 갱신해 InverseOne 신호와 동일/이탈 여부 라벨링. /stocks 의 “컨센서스 이탈” 필터, 종목 상세의 “컨센서스 카드”, /performance 의 “기관 대비” KPI 가 같은 데이터 소스
OG 이미지 정적 자산 — 신호별(buy/hold/sell) 정적 OG 이미지 미리 만들어 S3 에 배치. 종목 상세 공유 시 신호 색상으로 미리보기 자동 노출 (종목명 합성은 후속)
테마/법적 빌드 가드 — astro build 실행 전 lint:legal + lint:theme 강제. 컬러 토큰 외 사용 · 금지 단어 사용 시 배포 자체가 막힘. 타입 검사는 Astro 빌드가 처리

현재 상태와 운영 신호

상태: 한국 주식 시장 운영 중, 일별 자동 신호 + 적중 채점 누적
시작: 2024-01 (Next.js + Neon 으로 첫 출시), 2026-04 Vite + S3 + Hono + MySQL 로 재구축 (greenfield), 2026-05 Astro Island Architecture 로 프론트엔드 전환
인프라: AWS Lightsail 단일 인스턴스 + S3 (inverseone.com 버킷, web/files 분리) + CloudFront, 9개 서비스 공용 백엔드
자동화: 일별 스케줄러 2종(신호 생성 / 적중 채점) + 빌드 prebuild 가드 3종(legal / theme / types)
검증 신호: 일별 신호 자동 갱신 무중단, 캘리브레이션 곡선이 양의 단조성(높은 확신도 → 높은 실제 적중률) 유지, 종목별 컨센서스 비교 기능 운영

회고와 다음 가설

잘 작동한 것: “결론 · 근거 · 검증” 을 한 페이지에 묶은 progressive disclosure 구조. 입문자는 신호등만 보고 떠나도 충분하고, 중급자는 같은 화면에서 깊이파기 가능. 페이지 분리했으면 둘 다 만족 못 시켰음
다시 한다면: 초기 Next.js + Neon 선택은 SEO/SSR 을 빠르게 푸는 듯했지만 운영 단계에서 Vercel/Neon 비용 + 콜드 스타트 + 플랫폼 lock-in 이 부담이었다. Astro Island Architecture + MySQL 로 가도 SNS 미리보기와 검색 인덱싱 모두 방어 가능하다는 사실을 마이그레이션 후 확인. 처음부터 이 조합으로 갔으면 마이그레이션 비용 절감
법적 어휘 시스템: “AI”, “추천” 같은 단어를 코드 린트로 막은 결정은 의외로 자주 효과 봤다. 카피 검토 시간을 빌드가 대신 채점해줌
다음 가설: (1) 미국 · 일본 시장 확장 (엔진 재사용, 신호 형태 동일), (2) Pro 티어 (저장 필터 · 알림 · 종목별 캘리브레이션 — 트랙레코드 누적 후), (3) 종목별 동적 OG 이미지 합성, (4) 다국어(en/ja) 재활성화

비슷한 결의 작업 의뢰

InverseOne 을 단독으로 기획 · 구현 · 운영하면서 만들어낸 핵심 역량은 다른 도메인에도 적용 가능합니다.

결론 · 근거 · 검증을 같은 화면에 통합하는 의사결정 UX — 의료 검사 결과 + 진단 + 통계, 채용 후보 매칭 + 점수 + 적중률, 부동산 매물 추천 + 근거 + 트랙레코드 등 “왜 이 결론인지” 와 “이 시스템 믿을 만한가” 를 동시에 묻는 모든 도메인
법적 안전 어휘를 코드 린트로 강제하는 시스템 — 핀테크 · 헬스케어 · 보험처럼 광고 가이드라인이 엄격한 영역에서 빌드 단계 가드레일로 안전선을 박는 작업
일별 자동 데이터 입수 + 사후 채점 파이프라인 — 신호/예측/추천 시스템을 만들 때 “결과를 자동으로 채점하고 그 채점 결과를 다시 사용자에게 노출” 하는 폐쇄 루프 설계
멀티서비스 백엔드 + 비용 최적 인프라 — 여러 서비스가 단일 Hono 코어와 인프라를 공유하는 host-routing 구조. 서비스당 비용을 N분의 1로 떨어뜨리는 결정
Next.js → Astro Island Architecture 마이그레이션 — Vercel/Neon 호스팅 비용 · 콜드 스타트 · 플랫폼 lock-in 에서 빠져나오는 작업. SEO · OG 메타 · SNS 공유까지 모두 방어하면서 비용은 정적 호스팅 수준으로. 상호작용 없는 페이지는 JS 제로, 상호작용 부분만 React island 로 hydration

기획부터 시스템 구축, 운영 자동화까지 한 사람이 끝까지 들고 가는 형태의 작업을 선호합니다. 의뢰는 /work-with-me 또는 /contact 로 연락주세요.