Skip to content

Latest commit

 

History

2 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Hunch

감을 기록하고, 점수로 돌려받는다.

판단을 내릴 때 확률과 함께 적어두면, 결과가 나올 때쯤 다시 꺼내 채점해준다. 데이터는 내 컴퓨터의 SQLite 파일 하나에만 저장되고, 외부로 나가는 네트워크 요청은 없다.

Node.js만 있으면 된다. 설치할 의존성 0개, 빌드 단계 없음.

상태 — 보관용

유지보수하지 않습니다. 실행에는 문제가 없고, 로컬에서 쓰기에는 그대로 동작합니다.

이 저장소는 "아이디어부터 최종 테스트까지 에이전트가 질문 없이 혼자 만든다" 는 실험의 결과물입니다. 2026-08-22 하루 만에 기획·설계·구현·테스트까지 끝냈고, 테스트 112건이 통과합니다. 이후 워크스페이스의 기준 스택이 Next.js + Cloudflare Workers + D1 로 바뀌면서 이 구조(의존성 0개 · 로컬 SQLite · 자체 비밀번호 인증)는 더 이상 이어지지 않습니다.

화면

라이트 다크
라이트 다크

빠른 시작

npm start

브라우저에서 http://127.0.0.1:4848 을 열고 계정을 한 번 만들면 끝이다.

첫 실행 시 node:sqlite의 실험 기능 경고가 뜰 수 있어 npm start에는 --disable-warning=ExperimentalWarning이 붙어 있다. 직접 실행하려면 node bin/hunch.js.

요구 사항: Node.js 22.5 이상 (24 이상 권장)


무엇을 해결하나

개발자와 리드는 매주 판단을 내린다. "이 리팩터링 2주면 된다", "이 채용은 잘 될 것이다", "이 기능은 안 쓰일 것이다". 문제는 결과가 나올 때다.

  1. 그때쯤이면 왜 그렇게 판단했는지 기억나지 않는다.
  2. 맞았는지 틀렸는지 집계되지 않는다. 기억은 성공 쪽으로 편향된다.
  3. 그래서 판단력은 경력만큼 늘지 않는다.

노트 앱은 저장은 해주지만 다시 꺼내주지도, 채점하지도 않는다. Hunch는 판단을 검증 가능한 형태로 적게 만들고, 확인 날짜에 큐로 내놓는다.

  • 30초 기록 — 제목 · 예측 문장 · 확률 · 확인 날짜 넷이면 충분하다
  • 확률 강제 — "잘 될 것 같다"는 채점할 수 없지만 "3개월 안에 온보딩 완료 · 70%"는 채점된다
  • 키보드 완주1 적중 · 2 빗나감 · 3 무효 · S 연기 · Enter 저장
  • 보정 피드백 — Brier 점수, 보정 곡선, 과신 지표, 태그별 성적
  • 데이터 소유 — SQLite 파일 하나 + 자동 백업 + JSON 내보내기

사용법

1. 판단 기록

제목과 검증 가능한 예측 문장, 확률(1~99%), 확인할 날짜를 적는다. 상황·검토한 선택지·근거·태그는 선택이고 나중에 채워도 된다. 예측은 결정당 최대 5개.

2. 리뷰

확인 날짜가 되면 홈에 "오늘 확인할 판단"으로 뜬다. 리뷰 화면은 판단 당시의 근거를 먼저 보여준 뒤 예측을 채점하게 한다.

동작
1 적중
2 빗나감
3 무효 (판정할 수 없는 예측)
S 연기 (결과를 아직 모를 때)
Enter 저장하고 다음
⌘/Ctrl + Enter 메모 입력 중에도 저장

결과를 모르면 연기한다. 연기 횟수는 기록되어, 결과가 안 나오는 판단이 통계로 드러난다.

3. 보정

  • Brier 점수 — 낮을수록 좋다. 0 완벽, 0.25 동전 던지기. 항상 자기 기저율만 말했을 때의 점수를 함께 보여준다
  • 보정 곡선 — 가로는 내가 말한 확률, 세로는 실제 적중률. 점선 아래면 과신, 위면 과소평가
  • 편향 — 평균 확신 − 실제 적중률. 양수면 과신
  • 표본이 5건 미만인 구간은 흐리게 표시하고, 채점 10건 미만이면 결론 대신 "몇 건 더 필요한지"를 말한다

4. 백업

설정에서 JSON을 내보내고 가져올 수 있다(더하기 / 전부 대체하기). 서버도 부팅할 때와 24시간마다 자동 백업을 만들고 최근 7개를 유지한다.


채점 방식

이진 예측을 확률로 채점하는 표준 방식(Brier score)을 쓴다.

Brier = mean( (확률 − 실제)² )        실제: 적중 1, 빗나감 0, 무효는 제외
기준선 = 적중률 × (1 − 적중률)         항상 자기 평균만 말했을 때의 점수
편향   = 평균 확률 − 실제 적중률        양수면 과신

구간은 10%p 단위(0–9, 10–19, …, 90–99)로 나눠 구간별 평균 확률과 실제 적중률을 비교한다. 되돌린(다시 연) 판단의 예측은 채점 표본에서 빠진다 — 채점된 예측은 "해결된 판단의 예측"으로만 정의한다.


설정 (환경변수)

변수 기본값 설명
HUNCH_PORT 4848 포트
HUNCH_HOST 127.0.0.1 바인딩 주소
HUNCH_DATA_DIR ~/.hunch DB와 백업 위치
HUNCH_LOG_LEVEL info debug/info/warn/error/silent
HUNCH_BACKUP_KEEP 7 보관할 백업 개수
HUNCH_BACKUP_INTERVAL_HOURS 24 백업 주기
HUNCH_DAY_CUTOFF_HOUR 4 하루 경계 시각(0~23)
HUNCH_SESSION_DAYS 30 세션 유효 기간
HUNCH_ALLOWED_HOSTS 추가로 허용할 Host 헤더(쉼표 구분)
HUNCH_PORT=8080 HUNCH_DATA_DIR=./data npm start

하루의 시작은 자정이 아니라 로컬 04:00이다. 새벽에 남긴 기록은 전날로 집계된다.


보안

로컬 도구지만 로컬이라고 방치하지 않았다. 판단 기록은 사내 정보에 가깝기 때문이다.

  • 127.0.0.1에만 바인딩, Host 헤더 허용목록으로 DNS rebinding 차단
  • 비밀번호는 scrypt(N=16384) + 사용자별 salt, 세션 토큰은 sha256 해시로만 저장
  • 세션 쿠키 HttpOnly + SameSite=Strict, 변경 요청은 Origin 검증(CSRF)
  • CSP default-src 'none', 인라인 스크립트 없음, 렌더는 전 구간 textContent(XSS)
  • 모든 SQL은 바인딩 파라미터, 모든 조회에 소유자 조건
  • 로그인 15분 10회 / API 분당 600회 제한, 본문 1MB(가져오기 5MB) 상한

비밀번호를 잊으면 복구할 수 없다. 데이터 파일 자체는 암호화되지 않으므로 디스크 암호화(FileVault 등)를 함께 쓰는 것을 권한다.


개발

npm test                  # 전체 112건
npm run test:unit         # 순수 함수 + 정적 검사
npm run test:integration  # 실제 HTTP 서버 + 임시 DB

구조

bin/hunch.js       실행 엔트리(시그널 · 종료 처리)
src/
  config.js        환경변수 → 설정(단일 소스)
  server.js        미들웨어 체인 + 라우팅 + 생명주기
  http/            라우터 · 정적 서빙 · 보안 미들웨어 · 라우트 핸들러
  domain/          time · text · validate · calibration · ids (순수 함수, I/O 없음)
  data/            db · migrations · repos(모든 SQL) · backup
  services/        auth · decisions · review · stats · transfer
public/            빌드 없는 ES Modules + CSS 토큰
tests/             unit · integration · helpers
docs/              단계별 설계·검증 기록

의존 방향은 단방향이다: http → services → data, domain은 어느 층에도 의존하지 않는다. SQL은 data/repos.js 밖에서 쓰지 않고, 렌더 코드에서 innerHTML을 쓰지 않는다(테스트로 강제).

디자인

UI는 oh-my-designmercury 디자인 시스템을 단일 기준으로 삼아 구현했다. 색·타이포·간격·모서리·그림자·모션은 전부 public/css/tokens.css 한 곳에 있고, 나머지 CSS는 변수만 참조한다. 접근성 때문에 명세와 달리 간 두 지점과 파생 토큰의 근거·명암비는 docs/06-design.md에 기록했다. 디자인 시스템 위반은 버그로 취급하며 tests/unit/design-system.test.js가 이를 검사한다.

설계·검증 기록

문서 내용
docs/00-idea.md 문제 정의와 범위
docs/01-naming.md 서비스명 후보와 검증
docs/02-plan.md 기능·화면·데이터 흐름·예외·경계
docs/03-architecture.md 기술 선택 근거, 데이터 모델, API
docs/04-implementation.md 구현 결정과 발견한 결함
docs/05-design-system-selection.md 440개 중 mercury를 고른 근거
docs/06-design.md 토큰 이식·파생·상태·접근성·명암비
docs/07-test-report.md 테스트 결과
docs/08-final-test.md 최종 점검
docs/persona-log.md 8개 관점 검증 로그 63건

범위 밖 (의도적으로 넣지 않음)

팀 공유·권한, 클라우드 동기화, 이메일/푸시 알림, 첨부파일, 마크다운 렌더링, 외부 캘린더 연동, AI 예측 제안.


라이선스

MIT

About

판단을 기록하고 확률로 채점하는 로컬 우선 결정 저널

Resources

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages