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~99%), 확인할 날짜를 적는다. 상황·검토한 선택지·근거·태그는 선택이고 나중에 채워도 된다. 예측은 결정당 최대 5개.

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

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

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

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

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

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

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

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

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

MIT