VPS용 셀프 호스팅 RSS 리더 5종 비교 분석

소규모 VPS에 적합한 셀프 호스팅 RSS 리더는 무엇인가

Miniflux는 소규모 VPS에 설치하기 가장 적합한 셀프 호스팅 RSS 리더입니다. PostgreSQL과 함께 실행되는 단일 Go 바이너리 형태입니다. Fever 및 Google Reader API를 지원하므로 타사 모바일 앱과 연동할 수 있으며, 업그레이드 또한 docker compose pull 한 번으로 완료됩니다. 확장 기능이 필요하거나 SQLite를 포함한 단일 컨테이너 구성을 선호한다면 FreshRSS를 선택하십시오.

VPS의 디스크 공간을 할애할 가치가 있는 RSS 리더는 Miniflux, FreshRSS, CommaFeed, yarr, Tiny Tiny RSS 총 5가지입니다. 이 페이지에서는 각 서비스의 실질적인 차이점, 즉 스택별 메모리 요구량, 필수 데이터베이스 종류, 모바일 앱 연동을 위한 동기화 API, 그리고 업그레이드 시의 작업 내용을 비교합니다. 여기에 기재된 모든 수치는 프로젝트 공식 발표 자료이거나 단순 산술 계산 결과이며, 출처를 명시하였습니다. 이 내용은 사용자의 하드웨어 성능을 측정하는 벤치마크가 아니므로, 실제 환경에서의 성능은 docker stats를 사용하여 직접 측정하십시오.

다섯 가지 리더, 각 단락별 소개

Miniflux는 Go로 작성되었으며 단일 정적 컴파일 바이너리 형태로 배포됩니다. 문서에서는 필수 의존성에 대해 "PostgreSQL에서만 동작한다"고 명확히 밝히고 있습니다. SQLite 모드는 지원하지 않습니다. REST API, Fever 호환 API, Google Reader 호환 API를 제공하며 OPML 가져오기 및 내보내기 기능을 갖추고 있습니다. 전문 검색 기능은 PostgreSQL이 담당하며, 이것이 데이터베이스를 필수 요소로 두는 이유 중 하나입니다.

FreshRSS는 PHP 기반이며 웹 서버와 애플리케이션을 하나의 컨테이너에 담아 실행합니다. 기본 데이터베이스는 SQLite이므로 별도의 서비스가 필요 없으나, 대규모 설치를 위해 PostgreSQL과 MySQL도 지원합니다. Google Reader API와 Fever API를 지원합니다. 설치 방법은 VPS에 FreshRSS 설치하기 가이드에서 이미 다루었으므로, 이 페이지에서는 설치 과정을 반복하는 대신 다른 서비스와 비교합니다.

CommaFeed는 Quarkus 기반의 Java 애플리케이션으로, Google Reader를 모방한 레이아웃을 제공합니다. 데이터베이스는 런타임이 아닌 빌드 시점에 결정되므로, 프로젝트는 데이터베이스별로 별도의 이미지를 배포합니다. 내장 H2 데이터베이스용 athou/commafeed:latest-h2, PostgreSQL용 athou/commafeed:latest-postgresql, 그리고 MySQL 및 MariaDB용 변형 버전이 있습니다. 해당 태그는 네이티브 컴파일 빌드이며, -jvm 접미사가 붙은 버전은 JVM 위에서 실행되는 변형입니다. REST API와 Fever 호환 API를 제공하며, 7.3.0 버전(2026년 8월)부터는 Google Reader 호환 API도 지원합니다.

yarr(yet another rss reader)는 SQLite가 내장된 단일 Go 바이너리이며 컨테이너가 전혀 필요하지 않습니다. 기본적으로 ./yarr가 127.0.0.1:7070 포트에서 대기합니다. 플래그는 간단합니다. -addr 0.0.0.0:7070 -auth alice:secret은 비밀번호를 설정하여 네트워크에 공개하며, -db /data/yarr.db는 데이터베이스 위치를 지정합니다. Fever 호환 API를 지원합니다. 최신 태그 버전은 2026년 9월에 출시된 v2.9이며, 2026년 10월에 확인되었습니다. 6월의 v2.7과 7월의 v2.8에 이어 다시 활발하게 개발되고 있습니다.

Tiny Tiny RSS는 이 다섯 가지 중 가장 오래되었으며 실행 시 가장 무거운 리더입니다. tt-rss.org의 원본 프로젝트는 2025년 11월 1일부로 종료되었으며, 현재는 github.com/tt-rss/tt-rss의 커뮤니티 포크에서 개발이 계속되고 있으며 해당 문서가 공식 설정 가이드가 되었습니다. 이 설정은 PostgreSQL 컨테이너, PHP-FPM 애플리케이션 컨테이너, 피드를 가져오는 별도의 업데이터 컨테이너, 그리고 앞단에 위치한 nginx 컨테이너까지 총 네 가지 서비스로 구성됩니다. 문서는 "이 설정은 PostgreSQL을 사용한다"고 명확히 명시합니다. 자체 JSON API를 보유하고 있으며, 안드로이드 클라이언트와 여러 타사 앱이 이를 사용합니다. Fever는 지원하지 않습니다.

각 스택에 필요한 메모리 용량

아래 수치는 측정값이 아닌 예산이며, 소규모 VPS에서 각 스택이 유지해야 할 메모리 상한선입니다. CommaFeed의 수치는 프로젝트에서 공식적으로 게시한 예시이며, 컨테이너를 256 MB로 제한합니다. 다른 수치들은 피드 가져오기(feed fetcher)를 위한 여유 공간을 고려한 상한선입니다. 피드 가져오기는 새로고침 주기가 시작될 때 메모리 사용량이 급증하는 부분입니다.

[
  {
    "label": "yarr (SQLite)",
    "containers": 1,
    "mem_limit_mb": 128
  },
  {
    "label": "FreshRSS (SQLite)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "CommaFeed (H2)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "Miniflux + Postgres",
    "containers": 2,
    "mem_limit_mb": 320
  },
  {
    "label": "Tiny Tiny RSS",
    "containers": 4,
    "mem_limit_mb": 640
  }
]

yarr는 단일 바이너리와 하나의 SQLite 파일로 구성되며, 별도의 데이터베이스 서버나 언어 런타임이 필요하지 않으므로 128 MB로 가장 낮습니다. Miniflux는 2개의 컨테이너를 합쳐 320 MB가 필요하며, 이 중 대부분은 Miniflux 자체가 아닌 PostgreSQL이 차지합니다. Tiny Tiny RSS는 4개의 컨테이너를 합쳐 640 MB를 사용하는 예외적인 경우입니다. 애플리케이션, 업데이트 도구, 데이터베이스, 웹 서버가 각각 별도의 힙을 사용하는 4개의 독립된 프로세스로 동작하기 때문입니다.

이 수치들을 막연한 기대치가 아닌 실제 제한값으로 설정하십시오. Docker Compose의 메모리 제한에서 관련 구문과 컨테이너가 상한선에 도달했을 때 발생하는 동작을 다룹니다. 제한이 없는 컨테이너는 서버 자원이 가득 찼을 때 정상적으로 종료되지 않습니다. 커널이 임의의 프로세스를 희생양으로 선택해 강제 종료하며, 이때 선택되는 프로세스는 종종 메모리 압박을 유발한 컨테이너가 아닐 수도 있습니다.

각 리더가 강제하는 데이터베이스

이 다섯 가지 도구 사이의 가장 큰 운영상 차이점은 데이터베이스입니다. 이는 사용자 인터페이스의 차이보다 훨씬 중요한 결정인데, 백업 절차와 업그레이드 위험을 결정하기 때문입니다.

Miniflux와 공식 Tiny Tiny RSS 설정은 PostgreSQL을 요구합니다. 이를 통해 강력한 전체 텍스트 검색과 안전한 동시 쓰기가 가능해집니다. 대신 두 번째 컨테이너와 볼륨이 필요하며, 한 가지 반복적인 문제가 발생합니다. 공식 PostgreSQL 이미지는 메이저 버전 간의 데이터 마이그레이션을 제자리에서 수행할 수 없습니다. Tiny Tiny RSS 문서에서도 이를 직접 언급하며 "공식 PostgreSQL 컨테이너는 메이저 버전 간 데이터 마이그레이션을 지원하지 않는다"고 경고합니다. 피드 리더를 운영할 때 현실적인 선택지는 이전 메이저 버전을 고정하거나, pg_dump 및 pg_restore를 사용하여 덤프 및 복원을 수행하는 것입니다. PostgreSQL은 pg_upgrade 및 복제 기반 업그레이드 방법도 문서화하고 있습니다. 이는 다운타임이 중요한 대규모 데이터베이스에서는 추가적인 설정 노력을 할 가치가 있지만, 피드 리더의 데이터베이스는 거의 그런 경우가 없습니다. 1~2년에 한 번씩 이 작업을 수행할 계획을 세우십시오.

SQLite는 FreshRSS와 yarr의 기본값입니다. 파일 하나로 구성되며 서버, 포트, 비밀번호가 필요 없습니다. 수백 개의 피드를 사용하는 1인 환경에서는 성능이 충분하지만, 여러 사용자가 동시에 데이터를 쓸 때는 속도가 저하됩니다. 이때부터 FreshRSS의 PostgreSQL 옵션이 제값을 하기 시작합니다. yarr는 v2.7부터 PostgreSQL 지원을 추가했지만, 내장 파일을 사용하는 것이 일반적인 운영 방식입니다.

H2는 CommaFeed의 기본 내장 데이터베이스입니다. CommaFeed는 이미지가 빌드될 때 데이터베이스가 결정되므로 시작하기 전에 잠시 고려해야 합니다. 나중에 H2에서 PostgreSQL로 전환하는 것은 단순한 설정 변경이 아닙니다. 다른 이미지를 사용해야 하며 직접 데이터 마이그레이션을 수행해야 하므로, 1년 치 읽기 기록이 쌓이기 전에 결정하십시오.

모바일 앱이 작동합니까

이 질문은 예상보다 더 중요한 의미를 갖습니다. 웹 인터페이스는 피드 리더 사용 방식의 절반에 불과하기 때문입니다.

Miniflux는 Fever 호환 API와 Google Reader 호환 API를 모두 지원하므로 대부분의 iOS 및 Android 클라이언트가 연결할 수 있습니다. FreshRSS도 동일한 두 가지 API를 지원하며, 자체 문서에서는 Google Reader API를 모든 기능을 지원하는 "최고"의 선택으로, Fever API는 "제한된 기능과 낮은 효율성"을 가진 것으로 평가합니다. 또한 FreshRSS는 앱에서 로그인하기 전에 두 단계를 거쳐야 합니다. Authentication 설정에서 "Allow API access (required for mobile apps)"를 활성화한 다음, 사용자 프로필에서 API 비밀번호를 생성하십시오. API 비밀번호 설정을 건너뛰면 웹 로그인은 정상 작동함에도 앱에서는 인증 실패가 발생하는데, 원인을 알기 전까지는 혼란스러울 수 있습니다.

CommaFeed도 이제 두 API를 모두 지원합니다. 오랫동안 Fever 호환 API를 제공해 왔으며, 버전 7.3.0부터는 Fever를 지원하지 않는 앱을 위해 Google Reader 호환 API가 추가되었습니다. 따라서 사용 중인 앱이 Google Reader만 지원한다면 7.3.0 이상의 버전을 실행하십시오. yarr은 Fever 호환 API만 제공하므로 Fever를 지원하는 클라이언트에서는 작동하지만 Google Reader만 지원하는 앱에서는 작동하지 않습니다. Tiny Tiny RSS는 자체 API를 사용하므로 해당 API용으로 작성된 클라이언트가 필요합니다. 300개의 피드를 가져오기 전에 선호하는 앱이 해당 리더를 지원하는지 확인하십시오.

1 GB 서버를 위한 작동 가능한 compose 파일

이 구성은 2026년 10월 기준 Miniflux 프로젝트의 공식 Docker 예제를 기반으로 작성된 스택입니다. 공개된 포트는 루프백 주소에 바인딩되어 있고, 수신 주소는 명시적으로 설정되었으며, 두 컨테이너 모두 메모리 제한이 적용되어 있습니다.

services:
  miniflux:
    image: miniflux/miniflux:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    depends_on:
      db:
        condition: service_healthy
    environment:
      - DATABASE_URL=postgres://miniflux:CHANGE_ME@db/miniflux?sslmode=disable
      - LISTEN_ADDR=0.0.0.0:8080
      - BASE_URL=https://rss.example.com/
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=CHANGE_ME_TOO
      - POLLING_FREQUENCY=60
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    mem_limit: 128m
  db:
    image: postgres:18
    restart: unless-stopped
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=CHANGE_ME
      - POSTGRES_DB=miniflux
    volumes:
      - miniflux-db:/var/lib/postgresql
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      start_period: 30s
    mem_limit: 192m
volumes:
  miniflux-db:

이 파일에서 사람들이 자주 실수하는 부분은 세 줄입니다. LISTEN_ADDR=0.0.0.0:8080는 공식 이미지가 Dockerfile에서 이미 설정한 내용을 반복하므로, miniflux/miniflux와 함께 사용하면 수정이라기보다는 안전장치 역할을 합니다. 이 설정은 직접 이미지를 빌드하거나 패키지된 바이너리를 실행할 때 중요합니다. 바이너리의 기본값은 127.0.0.1:8080으로 문서화되어 있는데, 컨테이너 내부에서 루프백에 바인딩된 프로세스는 외부에서 공개된 포트로 접근할 수 없기 때문입니다. 이 경우 컨테이너는 정상으로 보이지만 연결이 초기화(connection reset)됩니다. 볼륨 경로 /var/lib/postgresql은 PostgreSQL 18 버전과 일치합니다. 17 버전 이하에서는 데이터가 /var/lib/postgresql/data에 저장되므로, 잘못된 경로를 마운트하면 데이터 디렉터리가 볼륨에 위치하지 않게 되어 컨테이너를 재생성할 때 모든 데이터가 사라집니다. 127.0.0.1:8080:8080는 포트가 공용 인터넷에 노출되지 않도록 합니다. 주소 없이 포트만 공개하면 ufw가 관리하지 않는 체인에 규칙이 추가되기 때문입니다. Docker 포트가 ufw를 우회하는 원리에서 해당 메커니즘을 설명하며, Traefik 리버스 프록시를 사용하면 그 앞에 TLS를 적용할 수 있습니다.

docker compose up -d
docker compose ps
docker compose logs -f miniflux
docker stats --no-stream

docker compose ps을 실행하면 두 서비스가 모두 실행 중이어야 하며, 데이터베이스는 healthy 상태로 표시되어야 합니다. Miniflux가 처음 시작될 때 RUN_MIGRATIONS=1가 트리거하는 스키마 마이그레이션 로그가 출력됩니다. docker stats --no-stream은 실시간 메모리 사용량을 출력하며, 이 값을 위 차트의 제한 수치와 비교해야 합니다. Miniflux 컨테이너가 반복적으로 재시작된다면 로그를 확인하십시오. connect: connection refused는 PostgreSQL이 연결을 수락할 준비가 되기 전에 Miniflux가 시작되었음을 의미합니다. 이는 service_healthy 조건이 방지하는 상황이므로, 해당 조건이 편집 과정에서 누락되지 않았는지 확인하십시오. Compose 사용이 처음이라면 VPS에서의 Docker Compose 기초에서 파일 구조를 먼저 확인하시기 바랍니다.

1 GB 서버에서 실행하기 어려운 서비스

Tiny Tiny RSS는 피해야 할 서비스입니다. 공식적인 4개 서비스 스택은 아무것도 실행하지 않는 1 GB VPS에서 간신히 돌아가며, 데이터베이스를 사용하는 다른 애플리케이션이나 리버스 프록시와 함께 실행할 수 없습니다. 4개의 서비스는 4배의 오버헤드를 의미하며, 그중 하나는 PostgreSQL입니다.

CommaFeed는 실행 가능하지만, H2 이미지를 사용하고 프로젝트 예제에서 설정한 256 MB 제한을 적용해야 합니다. 작은 서버에서 문제가 발생하는 경우는 CommaFeed를 별도의 데이터베이스 서버와 함께 실행할 때이며, -jvm 이미지 변형을 사용하면 상황이 더 악화됩니다. 프로젝트 문서에 따르면 JVM은 기본적으로 메모리를 많이 점유하며 사용하지 않는 메모리를 운영체제로 반환하지 않기 때문입니다. latest-h2 및 latest-postgresql 태그는 네이티브 빌드이며, 프로젝트 측에서도 메모리 사용량이 적어 이를 권장하므로 JVM을 실행해야 할 특별한 이유가 없다면 이 태그를 유지하십시오.

서버 메모리가 부족해지면 커널의 out of memory killer가 프로세스를 선택하여 강제 종료합니다. dmesg -T에는 Out of memory: Killed process 1234 (java)과 같은 줄이 나타나며, 애플리케이션 로그에는 아무런 메시지도 남지 않은 채 컨테이너가 docker compose ps에서 사라집니다. 이는 애플리케이션이 로그를 기록할 기회조차 얻지 못했기 때문입니다.

각 서비스의 업그레이드 방식

• Miniflux: docker compose pull && docker compose up -d를 사용하며, RUN_MIGRATIONS=1이 설정된 상태에서 시작 시 스키마 마이그레이션이 적용됩니다. 업그레이드 위험 요소는 Miniflux 자체가 아니라 그 기반이 되는 PostgreSQL 메이저 버전입니다.
• FreshRSS: 새 이미지를 pull 합니다. SQLite는 업그레이드할 데이터베이스 엔진이 없으므로, 일반적으로 발생하는 문제는 최신 버전과 호환되지 않는 타사 확장 기능에서 비롯됩니다.
• CommaFeed: 사용하는 데이터베이스와 일치하는 이미지 변형을 pull 합니다. latest-h2에서 latest-postgresql로 전환할 경우 데이터가 이전되지 않습니다.
• yarr: 바이너리를 교체하고 데이터베이스 파일은 유지합니다. 2026년 6월, 7월, 9월에 릴리스가 있었으며 2026년 10월 기준 v2.9가 최신 버전이므로 주기적으로 릴리스 페이지를 확인하십시오.
• Tiny Tiny RSS: docker compose pull && docker compose up -d을 사용합니다. 애플리케이션 컨테이너는 시작 시 스스로 업데이트하며, 프로젝트 FAQ에 따르면 스키마 업데이트 오류는 볼륨이나 override 설정이 손상되었을 때 발생하므로 오류 발생 시 이를 먼저 확인하십시오. 만약 compose 파일이 여전히 운영이 중단된 tt-rss.org 프로젝트의 이미지를 pull 하고 있다면, 포크된 프로젝트의 이미지(Docker Hub의 supahgreg/tt-rss 또는 ghcr.io/tt-rss/tt-rss)로 변경하십시오.

이러한 작업을 수행하기 전에는 반드시 데이터베이스 덤프를 생성하십시오. 작업 이후가 아닌 이전이어야 합니다.

docker compose exec -T db pg_dump -U miniflux miniflux | gzip > miniflux-$(date +%F).sql.gz

새로 고침 주기가 대역폭에 미치는 비용

아래 수치는 측정값이 아닌 산술적인 계산 결과입니다. 피드 100개, 피드당 주기별 1회 요청, 응답당 40 KB를 가정합니다. 서버가 조건부 요청을 준수하면 실제 트래픽은 이보다 낮아지고, 피드에 전체 기사 본문이 포함되면 더 높아집니다.

[
  {
    "label": "Every 5 minutes",
    "fetches_per_month": "864,000",
    "gb_per_month": 34.6
  },
  {
    "label": "Every 15 minutes",
    "fetches_per_month": "288,000",
    "gb_per_month": 11.5
  },
  {
    "label": "Every 30 minutes",
    "fetches_per_month": "144,000",
    "gb_per_month": 5.8
  },
  {
    "label": "Every 60 minutes",
    "fetches_per_month": "72,000",
    "gb_per_month": 2.9
  }
]

100개 피드에 대해 5분 주기를 설정하면 864,000회의 요청이 발생하며, 월간 약 34.6 GB의 트래픽이 소모됩니다. 1시간 단위 폴링은 72,000회의 요청과 약 2.9 GB의 트래픽을 발생시킵니다. Miniflux는 POLLING_FREQUENCY를 60분으로 설정하여 배포하며, 이는 해당 차트의 마지막 행에 해당합니다. 이 기본값은 거의 모든 사용자에게 적합합니다. 더 자주 요청한다고 해서 기사가 더 빨리 도착하지는 않습니다.

조건부 요청은 실제 트래픽을 산술적 계산값보다 낮게 유지하는 핵심 요소입니다. 피드가 반환한 ETag 및 Last-Modified 헤더를 저장하는 리더는 이를 If-None-Match 및 If-Modified-Since로 다시 전송하며, 새로운 내용이 없는 서버는 본문 없이 304 Not Modified으로 응답합니다. 연결 시 핸드셰이크 비용은 발생하지만 페이로드는 전송되지 않습니다. 조건부 요청을 무시하는 피드는 매번 전체 문서를 전송하므로, 몇 개의 대용량 피드만으로도 전송 비용이 크게 증가할 수 있습니다.

과도한 폴링은 차단으로 이어질 수 있습니다. 서버가 사용자의 요청을 공격으로 판단하면 429 Too Many Requests로 응답하며, 일부 사이트는 403를 반환하기도 합니다. Miniflux는 피드 자체에 마지막 오류를 기록하므로, 다른 피드는 정상인데 특정 피드만 업데이트가 멈췄다면 피드 목록을 가장 먼저 확인해야 합니다.

피드는 사라지며, OPML 파일은 백업이 아닙니다

피드는 예상보다 빠르게 부패합니다. 도메인 만료, 피드를 지원하지 않는 플랫폼으로의 이전, XML을 제공하던 URL이 200 OK 상태 코드를 반환하는 HTML 오류 페이지로 바뀌는 경우가 발생합니다. 마지막 사례가 가장 까다롭습니다. 가져오기(fetch)는 성공하지만 구문 분석(parse)이 실패하며, 리더는 네트워크 오류가 아닌 구문 분석 오류를 기록합니다. 1년에 한 번씩 피드 목록을 마지막 업데이트 순으로 정렬하고, 응답이 없는 피드는 삭제하십시오.

OPML 내보내기는 구독 목록일 뿐입니다. 표준 OPML 파일은 피드 URL과 폴더 이름만 담고 있습니다. FreshRSS는 새로 고침 주기, XPath 스크래핑 선택자, 자동 읽기 필터와 같은 피드별 설정을 포함하는 자체 XML 네임스페이스를 추가하지만, 어떤 OPML 내보내기도 읽음 상태, 별표 표시된 기사, 저장한 기사 본문을 포함하지 않습니다. 이 OPML을 새로 설치한 환경에 가져오면 피드는 복구되지만, 이전에 읽었던 모든 기사가 다시 읽지 않음 상태로 표시됩니다.

진정으로 중요한 백업은 데이터베이스입니다. PostgreSQL의 경우, 위에서 언급한 pg_dump 명령이 전체 작업의 전부입니다. FreshRSS나 yarr와 같은 SQLite 기반 리더는 쓰기 작업을 중단한 뒤 파일을 복사하거나, sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'"을 사용하여 실행 중에도 일관된 복사본을 생성해야 합니다. 쓰기 작업이 진행 중인 데이터베이스를 단순히 cp로 복사하면 복사본이 쓰기 도중의 불완전한 상태를 담게 되어 나중에 열리지 않을 수 있습니다. 이러한 파일은 VPS의 restic 백업을 사용하여 주기적으로 외부로 전송하고, 절차가 정상적으로 작동하는지 확인하기 위해 최소 한 번은 임시 컨테이너에 복원해 보십시오.

피드 리더는 직접 운영하기에 가장 저렴한 서비스 중 하나이며, 이것이 2026년에 직접 호스팅할 가치가 있는 서비스 목록에 항상 포함되는 이유입니다. 그 옆에 직접 호스팅하는 SearXNG 인스턴스를 배치하면 읽기와 검색 활동 모두를 본인이 제어하는 하드웨어 내에서 유지할 수 있습니다.

FAQ

메모리를 가장 적게 사용하는 셀프 호스팅 RSS 리더는 무엇입니까?

yarr입니다. SQLite가 내장된 단일 Go 바이너리 형태이므로 별도의 데이터베이스 서버나 언어 런타임이 필요 없으며, 128 MB 정도의 메모리 제한으로도 충분히 원활하게 동작합니다. 다만 기능 면에서 제약이 있는데, Fever API만 지원하며 최신 릴리스는 2026년 9월에 나온 v2.9입니다. 비슷한 수준의 메모리 점유율에서 Google Reader API 지원과 전체 텍스트 검색 기능을 원한다면, 320 MB를 사용하는 Miniflux와 PostgreSQL 조합이 더 나은 선택입니다.

1 GB VPS에서 셀프 호스팅 RSS 리더를 운영할 수 있습니까?

네, 가능합니다. Miniflux와 PostgreSQL은 두 컨테이너에 mem_limit을 설정하면 320 MB 이내로 운영할 수 있으며, FreshRSS는 SQLite를 사용하여 단일 컨테이너로 구성할 수 있습니다. 1 GB 환경에서 피해야 할 것은 공식 Tiny Tiny RSS 스택인데, 이는 자체 PostgreSQL을 포함하여 4개의 서비스로 구성되기 때문입니다. 항상 메모리 제한을 설정하십시오. 제한 없는 컨테이너가 메모리를 가득 채우면 커널이 프로세스를 강제 종료하는데, 이때 문제가 된 애플리케이션 대신 데이터베이스가 종료되는 경우가 많기 때문입니다.

이 중 iOS 및 Android RSS 앱과 호환되는 것은 무엇입니까?

Miniflux, FreshRSS, 그리고 CommaFeed 7.3.0 이상 버전은 Fever 호환 API와 Google Reader 호환 API를 모두 지원하므로 거의 모든 모바일 클라이언트를 연결할 수 있습니다. yarr은 Fever API만 제공합니다. Tiny Tiny RSS는 자체 API를 사용하므로 해당 API 전용 클라이언트가 필요합니다. FreshRSS의 경우, Authentication 설정에서 API 접근을 활성화하고 프로필에서 별도의 API 비밀번호를 설정해야 합니다. 그렇지 않으면 웹사이트는 정상 작동하더라도 앱에서는 로그인이 실패합니다.

OPML 내보내기가 RSS 리더의 백업이 됩니까?

아니요. OPML은 구독 목록만 복구할 수 있습니다. FreshRSS의 확장 내보내기 기능은 피드별 설정과 필터를 포함하지만, 읽음 상태, 별표 표시된 항목, 기사 본문은 모두 데이터베이스에 저장됩니다. PostgreSQL의 경우 pg_dump를 사용하거나 SQLite의 경우 .backup 명령어를 사용하여 데이터베이스 자체를 백업하고, 해당 결과물을 서버 외부로 복사해야 합니다.

Miniflux는 SQLite를 지원합니까?

아니요. 프로젝트 문서에 따르면 Miniflux는 "PostgreSQL에서만 작동"하며, 전체 텍스트 검색 기능도 PostgreSQL의 기능을 활용하여 구현되었으므로 더 가벼운 모드로 전환할 수 없습니다. 데이터베이스 컨테이너 없이 피드 리더를 사용하고 싶다면, 기본 SQLite 백엔드를 사용하는 FreshRSS나 내장 파일을 사용하는 yarr을 선택하십시오.