감을 기록하고, 점수로 돌려받는다.
판단을 내릴 때 확률과 함께 적어두면, 결과가 나올 때쯤 다시 꺼내 채점해준다. 데이터는 내 컴퓨터의 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주면 된다", "이 채용은 잘 될 것이다", "이 기능은 안 쓰일 것이다". 문제는 결과가 나올 때다.
- 그때쯤이면 왜 그렇게 판단했는지 기억나지 않는다.
- 맞았는지 틀렸는지 집계되지 않는다. 기억은 성공 쪽으로 편향된다.
- 그래서 판단력은 경력만큼 늘지 않는다.
노트 앱은 저장은 해주지만 다시 꺼내주지도, 채점하지도 않는다. Hunch는 판단을 검증 가능한 형태로 적게 만들고, 확인 날짜에 큐로 내놓는다.
- 30초 기록 — 제목 · 예측 문장 · 확률 · 확인 날짜 넷이면 충분하다
- 확률 강제 — "잘 될 것 같다"는 채점할 수 없지만 "3개월 안에 온보딩 완료 · 70%"는 채점된다
- 키보드 완주 —
1적중 ·2빗나감 ·3무효 ·S연기 ·Enter저장 - 보정 피드백 — Brier 점수, 보정 곡선, 과신 지표, 태그별 성적
- 데이터 소유 — SQLite 파일 하나 + 자동 백업 + JSON 내보내기
제목과 검증 가능한 예측 문장, 확률(1~99%), 확인할 날짜를 적는다. 상황·검토한 선택지·근거·태그는 선택이고 나중에 채워도 된다. 예측은 결정당 최대 5개.
확인 날짜가 되면 홈에 "오늘 확인할 판단"으로 뜬다. 리뷰 화면은 판단 당시의 근거를 먼저 보여준 뒤 예측을 채점하게 한다.
| 키 | 동작 |
|---|---|
1 |
적중 |
2 |
빗나감 |
3 |
무효 (판정할 수 없는 예측) |
S |
연기 (결과를 아직 모를 때) |
Enter |
저장하고 다음 |
⌘/Ctrl + Enter |
메모 입력 중에도 저장 |
결과를 모르면 연기한다. 연기 횟수는 기록되어, 결과가 안 나오는 판단이 통계로 드러난다.
- 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 |
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 서버 + 임시 DBbin/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가 이를 검사한다.
| 문서 | 내용 |
|---|---|
| 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

