llm-wiki/raw/official-docs/sample-realworld-gothinkster-github.md

---
title: gothinkster/realworld — "The mother of all demo apps" cross-stack 동일 명세 sample
source_type: official-doc
url: https://github.com/gothinkster/realworld
archive_url:
status: raw
confidence: high
tags: [ca-tmpl, sample-fixture, realworld, conduit, cross-stack-spec, github-reference, official-doc]
related_projects: [ca-skeleton-operational-contract]
related_branches: [feature-sample-domain-contract-fixture]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# gothinkster/realworld (Conduit)

> Layer: `raw/official-docs/` — gothinkster/realworld README + spec docs verbatim 발췌. ca-tmpl sample-ticket 결정의 대안 2 (cross-stack spec sample) 비교 근거. **OSS community spec — 단일 벤더의 official doc 은 아님**.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-sample-domain-contract-fixture]] | sample fixture 의 "cross-stack 명세 vs 내부 contract 검증" trade-off — RealWorld 는 frontend/backend interop 명세, ca-tmpl 은 skeleton 내부 contract (state machine, optimistic lock, idempotency) 검증이라는 차별점 |

## 컨텍스트

ca-tmpl sample-ticket 결정에 대한 대안 2. RealWorld는 "동일한 API/UI 명세를 백엔드·프론트엔드 어떤 스택으로도 구현"하는 cross-stack sample이며, "sample을 명세(spec)로 정의한다"는 접근이 ca-tmpl의 "sample fixture = skeleton contract 검증" 접근과 비교 가치 있음.

## 출처 / Source

- 원본 URL: https://github.com/gothinkster/realworld
- 명세: https://realworld-docs.netlify.app/specifications/backend/introduction/
- 아카이브 URL: (미수집)
- 저자/조직: gothinkster (OSS 커뮤니티, Eric Simons 외)
- Star 수: 80,000+ (사실상 cross-language reference)
- 라이선스: MIT
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim)

> [§README headline] "The mother of all demo apps — Exemplary fullstack Medium.com clone powered by React, Angular, Node, Django, and many more"

> [§README — combining frontends/backends] "You can combine any frontend with any backend, because they all adhere to the same API spec"

> [§README — modularity] "Every tutorial is built against the same API spec to ensure modularity of every frontend & backend"

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| SMP-RW-C1 | RealWorld 는 React/Angular/Node/Django 등 다양한 스택으로 구현된 "fullstack Medium.com clone" 데모 앱들의 묶음이다 | [§README headline] "The mother of all demo apps — Exemplary fullstack Medium.com clone powered by React, Angular, Node, Django, and many more" | `engineering-blog` | OSS demo / 학습 reference 평가 | "production-ready" / "공식 best practice" 라는 뜻은 아님 — 어디까지나 demo 명세 |
| SMP-RW-C2 | 모든 frontend 와 모든 backend 는 **동일 API spec** 을 따르므로 자유롭게 조합 가능하다 | [§README] "You can combine any frontend with any backend, because they all adhere to the same API spec" | `engineering-blog` | cross-stack interop 학습 / spec-first 접근 평가 | spec 이 모든 endpoint contract 의 모든 corner case (concurrency / idempotency / optimistic lock) 를 다룬다는 뜻은 아님 |
| SMP-RW-C3 | 모든 튜토리얼/구현체는 같은 API spec 으로 빌드되어 frontend & backend 의 modularity 가 보장된다 | [§README] "Every tutorial is built against the same API spec to ensure modularity of every frontend & backend" | `engineering-blog` | RealWorld 튜토리얼 군의 일관성 평가 | 각 구현체가 동일 spec 준수임을 자동 검증하는 conformance test suite 가 모든 언어에 적용된다는 뜻은 본 인용에 명시 없음 |

### Strength 허용값 사용

- `engineering-blog` — gothinkster 는 OSS 커뮤니티 프로젝트로, 단일 벤더의 공식 문서나 공식 표준이 아님. 따라서 `engineering-blog` (커뮤니티 reference 수준) 로 분류. ca-tmpl 운영 규칙 §5 의 "company-tech-blog 는 공식 best practice 로 취급 금지" 와 동일한 제약 적용 — RealWorld 자체는 "공식 best practice" 가 아님

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `SMP-RW-C1`: RealWorld 가 다언어 데모의 묶음이라는 사실
  - `SMP-RW-C2`: frontend/backend 의 동일 spec 조합 가능성
  - `SMP-RW-C3`: tutorial 단위 modularity 의도
- **이 자료가 증명하지 않는 것**:
  - RealWorld spec 이 optimistic lock / idempotency key / state machine corner case 를 다룬다 — README 자체에는 명시 없음 (별도 spec 페이지의 endpoint 정의를 직접 확인 필요)
  - RealWorld 의 모든 backend 구현체가 production 검증되었다는 사실
  - 80k star 가 "공식 표준" 또는 "best practice" 를 의미한다 — 인기 ≠ 공식
  - ca-tmpl 의 12-scenario matrix (sample disabled startup, sample removal smoke 등) 에 해당하는 RealWorld 의 검증 시나리오 존재 여부
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - RealWorld API spec 의 정확한 endpoint 목록 (Article / Comment / User / Profile / Favorite / Follow) 및 각 endpoint 의 contract 깊이
  - Spring Boot 구현체 reference 의 코드 품질 (별도 평가)
  - RealWorld 가 ca-tmpl 의 "skeleton 내부 contract 검증" 목적에 noise 가 너무 큰지 단순화 가능한지

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

- 도메인: Article / Comment / User / Profile / Favorite / Follow — 소셜 블로그.
- 핵심 차이점: RealWorld는 **frontend/backend interop 검증**용 명세. ca-tmpl sample-ticket은 **skeleton 내부 contract**(상태 머신·optimistic lock·idempotency) 검증.
- 시나리오 매트릭스: RealWorld API spec은 endpoint 단위 contract만 정의. ca-tmpl 12-scenario(sample disabled startup, sample removal smoke 등)는 RealWorld에는 없음.
- 모델 깊이: optimistic lock·idempotency key가 명세에 없음. → ca-tmpl 결정(6-field min model + idempotency + optimistic lock)이 RealWorld보다 contract 검증에 적합.
- 장점: cross-stack 비교가 가능하고 백엔드 구현체가 수십 개라 패턴 참고 풍부.
- 단점: 도메인이 너무 풍부해 minimum fixture가 아님. skeleton 검증용으로 차용 시 noise 큼.
- 신뢰도: github star 80k급 OSS reference. 단 official-doc은 아니고 community spec. tag는 official-doc으로 묶되 본문에 "OSS community spec" 명시 (frontmatter `source_type: official-doc` 은 wiki 의 광의의 "외부 reference 문서" 분류 — 단일 벤더의 표준이 아닌 점은 strength = `engineering-blog` 로 표시).

## 관련 ca-tmpl branch / contract

- 적용 branch-note:
  - [[raw/branch-notes/feature-sample-domain-contract-fixture]]
- canonical contract 섹션:
  - [[raw/project-notes/ca-skeleton-operational-contract#17. Sample Domain Fixture]]
  - [[raw/project-notes/ca-skeleton-operational-contract#22. Sample-portfolio Contract Matrix]]
- 대안 그룹: **Group G — Sample domain contract fixture**
- 본 source의 위치: 대안 2 — cross-stack spec sample (RealWorld/Conduit)

## Related / 관련

- 같은 주제 다른 official-doc:
  - [[raw/official-docs/sample-microservices-spring-cloud-github]] (대안 3 — microservices reference variant)
- 인용하는 branch:
  - [[raw/branch-notes/feature-sample-domain-contract-fixture]]
- 인용하는 wiki: (미작성)