DOGFOOD 2026을 위한 Forgeboard 구축: 신뢰도를 꾸미는 것을 거부하는 해커톤 심사 플랫폼

browser ──HTTP──▶ Next.js (App Router, React 19)
                    pages and route handlers   ← 여기에 규칙은 없다
                    capabilityFor()            ← 유일한 문```

-   **두 번째 프로세스 없음.** 데이터베이스 컨테이너, 큐(queue), 캐시(cache), 사이드카(sidecar)가 없습니다.
-   **`node:sqlite`를 통한 SQLite 사용:** Node 24에 포함되어 있어 네이티브 빌드 단계나 설치할 드라이버가 필요 없고, 시작할 것도 없습니다.
-   **ORM 없음.** 스키마는 검토자가 한 번의 통과로 읽을 수 있는 단일 파일의 일반 SQL입니다.
-   **아무것도 집으로 전송하지 않음 (Nothing phones home).** 폰트는 `geist` 패키지에서 가져오고, 분석 기능은 제거되었으며, 사용자가 직접 구성한 웹훅(webhook) 외에는 앱이 런타임에 외부 요청을 보내지 않습니다.
-   **메일 서버 없음.** 팀 초대, 심사위원 초대, 투표 토큰 및 비밀번호 복구는 모두 주최자나 관리자가 전달하는 일회용 링크입니다.

이를 통해 우리는 `--network none`으로 시작하면서도 모든 공개 경로(public route)를 서비스하고 데이터를 유지하며 다시 시딩(re-seed)하지 않는 컨테이너에서 1.2초에서 1.6초 사이에 통과하는 건강 검진(healthcheck)의 콜드 스타트(cold start) 시간을 확보할 수 있었습니다.

피처(fixture) 임포트는 같은 본능을 따릅니다: 지루하고, 변경하는 모든 것에 대해 명확하게 알립니다.

저희 스키마는 고유 인덱스(unique index)를 통해 팀당 하나의 프로젝트만 허용하므로, 임포터는 재제출을 유지하고 무엇이 누락되었는지 소리 내어 말합니다. 데이터를 조용히

DOGFOOD 사양은 한 줄의 체커 실행이 실패하는 팀의 이야기를 전합니다: `판정관이 피어 점수를 볼 수 없음... 200을 받았으나 401 또는 403을 원함`. 그들의 템플릿은 다른 판정관의 점수를 숨겼고, 그들의 API는 로그인한 모든 사람에게 그것들을 반환했습니다. 사양의 평가는 다음과 같습니다: _"버튼을 숨기는 것과 요청 자체를 거부하는 것 사이에는 차이가 있다."_

우리는 이 문장을 중심으로 제품을 구축했습니다.

**규칙은 데이터 계층에 살아 있습니다.** 모든 요청에서 Forgeboard는 `event_roles` 테이블로부터 하나의 _역량(capability)_을 구축합니다. 이는 한 행위자가 하나의 이벤트 내에서 할 수 있는 것을 의미하며, 요청 간에는 절대 캐시되지 않고 브라우저로 전송되지도 않습니다. 도메인 함수들은 올바른 역량이 없으면 실행을 거부합니다:

**격리성은 필터가 아니라 쿼리 형태입니다.** 판정관의 대기열은 "모든 할당 건을 내 것만 걸러낸 것"이 아닙니다. 이는 소유권에 의해 선택되므로, 다른 사람의 것을 반환할 수 있는 코드 경로는 없습니다:

단일 리뷰를 여는 것은 판정관이 대기열에서 왔다고 신뢰하는 대신 모든 검사를 재실행합니다: 해당 할당 건은 이 이벤트와 이 판정관에게 속하며, 프로젝트는 판정관의 트랙 권한 안에 놓여 있고, 판정관은 프로젝트 팀에 속하지 않으며, 결코 속했던 적도 없습니다. 우리는 팀 멤버십 기록을 유지하므로, 할당 후 팀을 떠난다고 해서 충돌이 해소되지 않습니다. 리뷰를 저장하는 것은 먼저 열기 경로를 호출하므로, 쓰기는 읽기의 검사를 건너뛸 수 없습니다. 그리고 API 라우트는 페이지와 동일한 도메인 함수들을 호출하므로, `curl`로 접근해도 인터페이스가 거부되는 방식과 정확히 똑같이 거부됩니다.

[![ ](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fwb4x9sgy2vydin0g2x0j.png)](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fwb4x9sgy2vydin0g2x0j.png)  
[![ ](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F3svb5ha2j2du8l44tw28.png)](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F3svb5ha2j2du8l44tw28.png)  
_심사위원 Sam이 다른 심사위원의 리뷰 URL을 붙여넣자 일반적인 404 오류가 발생한다. 주최자의 감사 추적(audit trail)에는 이미 이 기록이 남겨져 있다: `review.open`, 거부됨, "지정된 심사위원이 아님"._

왜 403이 아니라 404일까? 심사위원이 주최자 URL을 건드려도 아무것도 알 수 없다. 페이지가 존재하는지조차 모른다. 기계에 노출되는 엔드포인트(endpoints), CSV 내보내기, 그리고 API는 대신 403 응답을 한다. 왜냐하면 정중한 허구보다 명확한 거절이 더 유용하기 때문이다.

> **우리가 설계상의 버그로 만든 부분.** Next.js App Router에서 라우트 레벨의 `loading.tsx`는 페이지를 Suspense 경계(Suspense boundary)로 감싸고 셸을 즉시 플러시한다. 바이트가 와이어에 올라가는 순간, `notFound()`와 `redirect()`로는 더 이상 상태 코드(status code)를 설정할 수 없으므로, 권한이 없는 페이지는 **200**으로 응답하며 클라이언트 측 리디렉트(client-side redirect)를 내부적으로 포함하게 된다. 상태 코드는 우리의 권한 부여 스토리의 일부이므로, Forgeboard에는 라우트 레벨 로딩 파일이 없다. 스켈레톤(skeleton)이 실제로 도움이 되는 곳, 예를 들어 갤러리 그리드 같은 경우에는 Suspense 경계가 접근 결정이 내려진 후에 페이지 내부에 위치한다.

우리가 좋아하는 또 다른 세부 사항은 다음과 같다: 인스턴스 관리자(instance admin)는 모든 이벤트를 열람할 수 있다. 왜냐하면 그것이 관리자의 의미이기 때문이다. 다만 조용하지 않을 뿐이다. 첫 번째 접근 시 해당 이벤트 자체의 감사 추적에 `admin.access` 행이 기록되며, 주최자들이 이를 볼 수 있게 된다.

## 규칙 3: 심사위원이 부여하지 않은 의견은 절대 지어내지 않기

단일 리뷰를 채점하는 것은 쉬운 부분이다. 주최자가 가중치(weight)와 정수 척도(integer scale)를 가진 기준을 정의하고, 리뷰의 원점수(raw score)는 가중 평균이 된다:

이는 제출 시점에 계산되어 저장되므로, 나중에 루브릭(rubric)을 수정해도 이미 부여된 점수를 소급하여 변경할 수 없습니다. 저희 데모 루브릭은 DOGFOOD 자체의 채점 가중치를 차용했습니다: 완성도(Completeness) 40, 무결성(Integrity) 25, 운용 가능성(Operability) 20, 기술적 숙련도(Craft) 15.

[![ ](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fscquklqwmq1wrw9ttx9y.png)](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fscquklqwmq1wrw9ttx9y.png)  
_한 심사위원이 Beacon에 대해 4, 5, 3, 4점을 부여하고 가중치 40/25/20/15를 적용합니다. 누적 합계는 4.05가 되며, 이는 저희 유닛 테스트(unit tests)에서 고정하는 값(100점 만점에 76.25점)과 동일합니다._

어려운 점은 원시 점수(raw scores)가 심사위원마다 비교 가능하지 않다는 것입니다. 저희의 시드 이벤트(seeded event)에서 보듯이:

| 심사위원 | 리뷰 수 | 원시 평균 | 패널 대비 편향도 | 
| :--- | :--- | :--- | :--- |
| Mo Nakamura | 5 | 2.06 | −1.03σ |
| ... | 

Mo가 그린 프로젝트와 Jai가 그린 프로젝트는 동일한 측정 도구로 측정되고 있지 않습니다. 원시 점수를 평균 내면 패널 로터리(panel lottery)가 순위 결정의 일부를 담당합니다.

따라서 Forgeboard는 각 심사위원 내에서 표준화합니다:

그러면 모든 항목에 3점을 준 심사위원을 만나게 됩니다. 이 사람의 표준편차는 0이므로 공식은 0으로 나누게 됩니다. 교과서적인 회피 방법으로는 패널의 분산(variance)을 차용하거나 심사위원을 그쪽으로 수축시키는 것입니다. 둘 다 존재하지 않는 투표에서 인위적인 구분을 만들어냅니다. 모든 프로젝트에 3점을 준 심사위원은 어떤 프로젝트가 더 좋은지에 대해 아무것도 알려주지 않았으며, 정직한 답변은 그들의 입장을 대신하여 의견을 꾸며내기보다는 그렇게 말하는 것입니다.

Forgeboard는 최소 세 개의 완료된 리뷰와 0을 초과하는 분산(spread)을 가진 심사위원만 표준화합니다. 그 외의 사람은 **이름과 이유를 명시하여** 제외되며, 해당 사람들의 원점수(raw scores)는 화면에 그대로 표시됩니다. 사용 가능한 리뷰가 두 개 미만인 프로젝트는 순위가 전혀 매겨지지 않으며, 확신을 주는 위치를 부여받기보다는 _비교 가능한 리뷰 부족_으로 표시됩니다. 만약 모든 심사위원이 제외된다면, API, 콘솔, 스냅샷 모두 `raw_fallback`이라고 표시할 것입니다. 이 방식은 절대 조용히 전환되지 않습니다.