가이드

작성자 Matt Connor 2026-08-22 · 업데이트됨 2026-09-01

셀프 호스팅 가계부 앱 추천 및 Actual, Firefly III 비교

Actual Budget, Firefly III, Fava, Wallos의 주요 차이점을 분석합니다. 은행 거래 내역 자동 연동 여부와 데이터 관리 방식, 각 서비스별 컨테이너 구성 및 설치 전 고려해야 할 애그리게이터 설정 과정을 상세히 정리했습니다.

간단한 답변

셀프 호스팅 가계부 애플리케이션은 설치 여부를 결정짓는 핵심적인 차이점이 하나 있습니다. 바로 소프트웨어가 거래 내역을 자동으로 가져오는지, 아니면 사용자가 직접 입력해야 하는지입니다. Actual Budget은 가계 예산 관리를 위한 가장 적합한 기본 선택지입니다. 이 앱은 봉투 예산법(envelope method)을 사용하며 단일 컨테이너로 실행됩니다. 또한 사용자가 요청할 때 은행 데이터 제공업체로부터 거래 내역을 불러올 수도 있습니다.

Firefly III는 복식 부기 계정을 원하거나, 아무도 지켜보지 않는 상황에서 예약된 일정에 따라 자동으로 데이터를 가져오기를 원할 때 적합합니다. Beancount와 Fava는 장부를 버전 관리 시스템 하의 일반 텍스트 파일로 유지하려는 사용자에게 알맞습니다. Wallos는 매달 계좌에서 빠져나가는 정기 결제 비용을 추적하는 단일 목적에 특화되어 있습니다.

이러한 애플리케이션 중 어느 것도 은행과 직접 통신하지 않습니다. 은행 거래 내역을 보여주는 모든 앱은 제3자 애그리게이터(aggregator)로부터 데이터를 가져오며, 이 애그리게이터 계정을 생성하는 과정이 많은 사용자가 어려움을 겪는 단계입니다. 무엇을 설치하기 전에 먼저 동기화 섹션을 읽어 보시기 바랍니다.

각 서비스의 실행 구성 비교

ChartServices, storage and sync model, taken from each project's own install docs

tool

services

storage

bank_sync

multi_user

encryption

Actual Budget

SQLite files

Aggregators, manual pull

Needs OpenID

Optional end to end

Firefly III

MariaDB

Importer, cron capable

Built in accounts

None at rest

Beancount + Fava

Text file

Import scripts only

No login at all

File level, your choice

Wallos

SQLite file

Manual entry only

Extra logins in settings

None at rest

The data behind this chart

[
  {
    "tool": "Actual Budget",
    "services": 1,
    "storage": "SQLite files",
    "bank_sync": "Aggregators, manual pull",
    "multi_user": "Needs OpenID",
    "encryption": "Optional end to end"
  },
  {
    "tool": "Firefly III",
    "services": 3,
    "storage": "MariaDB",
    "bank_sync": "Importer, cron capable",
    "multi_user": "Built in accounts",
    "encryption": "None at rest"
  },
  {
    "tool": "Beancount + Fava",
    "services": 1,
    "storage": "Text file",
    "bank_sync": "Import scripts only",
    "multi_user": "No login at all",
    "encryption": "File level, your choice"
  },
  {
    "tool": "Wallos",
    "services": 1,
    "storage": "SQLite file",
    "bank_sync": "Manual entry only",
    "multi_user": "Extra logins in settings",
    "encryption": "None at rest"
  }
]

Actual Budget은 1개의 상시 실행 서비스를 구동합니다. Firefly III는 3개의 서비스를 구동하는데, 이는 공식 compose 파일이 애플리케이션, MariaDB 데이터베이스, 그리고 cron 도우미를 각각 별도의 컨테이너로 실행하기 때문입니다. 이것이 이 4개 애플리케이션의 전체 리소스 구성입니다. 데이터베이스 서버가 그룹 내에서 유일하게 무거운 부분이며, 나머지는 작은 파일을 처리하는 가벼운 프로세스입니다.

어떤 셀프 호스팅 가계부 앱이 은행 거래 내역을 불러올 수 있습니까?

어떤 셀프 호스팅 앱도 은행에 직접 연결하지 않습니다. 은행은 오픈 뱅킹 API를 통해 거래 내역을 제공하며, 이 API는 은행과 관계를 맺고 접근 권한을 재판매하는 애그리게이터(aggregator) 업체를 통해 연결됩니다. 따라서 실제 질문은 두 부분으로 나뉩니다. 해당 앱이 애그리게이터와 통신하는지, 그리고 사용자의 은행을 지원하는 애그리게이터 계정을 생성할 수 있는지 확인해야 합니다.

Actual Budget은 여러 애그리게이터와 통신합니다. 2026년 8월 기준, 해당 문서에는 뉴질랜드의 Akahu, 유럽의 Enable Banking, 유럽의 GoCardless Bank Account Data, 북미의 SimpleFIN Bridge, 브라질의 Pluggy.ai가 나열되어 있습니다. 사용자가 직접 해당 제공업체에 가입하여 키와 비밀 값을 생성한 뒤, 이를 서버에 입력해야 합니다. 두 가지 제한 사항이 중요합니다. Actual 문서는 은행 데이터가 자동으로 동기화되지 않으므로 사용자가 직접 버튼을 눌러야 한다고 명시합니다. 또한 같은 페이지에서 GoCardless가 신규 계정을 받지 않는다는 점을 언급하고 있는데, 이는 이전 가이드에서 추천하던 무료 유럽 경로가 막혔음을 의미합니다. SimpleFIN Bridge는 Actual이 아닌 제공업체에서 청구하는 유료 구독 서비스입니다.

Firefly III는 가져오기 기능을 별도의 컨테이너인 Firefly III Data Importer로 분리합니다. 예시 설정에는 CSV 및 CAMT.053 파일 가져오기 외에도 GoCardless(Nordigen), Enable Banking, Spectre, SimpleFIN을 위한 자격 증명 슬롯이 포함되어 있습니다. CAN_POST_AUTOIMPORT=true을 설정하고 AUTO_IMPORT_SECRET에 긴 임의의 값을 넣으면, 호스트의 cron 작업이 브라우저를 열지 않고도 가져오기를 트리거할 수 있습니다. 이는 이 비교에서 유일하게 완전히 자동화된 동기화 방식입니다.

Beancount는 동기화 기능을 제공하지 않습니다. 은행에서 CSV 또는 OFX 파일을 다운로드한 뒤, 직접 작성하거나 구한 임포터 스크립트를 실행해야 합니다. Wallos 역시 설계상 동기화 기능이 없습니다. 구독 정보를 한 번 입력하면 설정된 일정에 따라 스스로 반복됩니다.

수동 가져오기는 항상 작동하며 은행이 제공업체를 변경하더라도 영향을 받지 않는 방식입니다. 은행 연결 기능이 선택의 결정적인 요소라면, 무엇을 설치하기 전에 특정 은행이 해당 애그리게이터의 지원 범위에 포함되는지 먼저 확인하십시오. 이 확인 작업은 10분이면 충분하며, 주말을 허비하는 일을 방지해 줍니다.

Actual Budget: 컨테이너 하나로 운영하는 봉투 예산 관리

봉투 예산 관리란 이미 보유한 자금을 지출하기 전에 특정 항목에 할당하는 방식을 의미합니다. 식비에 300, 교통비에 80을 배정하는 식이며, 총 할당액은 계좌에 있는 잔액을 초과할 수 없습니다. Actual은 이 방식을 구현하며 로컬 우선(local-first) 원칙을 따릅니다. 브라우저나 데스크톱 클라이언트가 예산 데이터의 전체 사본을 보유하고 서버와 동기화하므로, 서버가 중단되어도 앱은 계속 작동합니다.

services:
  actual_server:
    image: actualbudget/actual-server:latest
    ports:
      - '5006:5006'
    volumes:
      - ./actual-data:/data
    restart: unless-stopped

docker compose up -d로 시작하고 http://your-server:5006을 엽니다. 데이터 볼륨에는 server-files과 user-files이라는 두 개의 디렉터리가 생성됩니다. 이 디렉터리들이 곧 사용자의 예산 데이터입니다. 내부 네트워크 외부에서 접근하려면 반드시 앞에 TLS(transport layer security)를 적용한 리버스 프록시를 배치하십시오. 전체 설치 과정은 Actual Budget 설치 가이드에 있으며, 해당 파일의 기반이 되는 compose 패턴은 VPS에서의 Docker Compose에서 확인할 수 있습니다.

다중 사용자. 기본적으로 서버는 모든 사용자가 공유하는 하나의 비밀번호를 사용합니다. 개별 계정을 사용하려면 OpenID Connect가 필요하며, 서버는 Authentik, Keycloak, Google, GitHub와 같은 제공자를 지원합니다. OpenID를 통해 처음 로그인한 사람이 서버 소유자가 되며, ACTUAL_USER_CREATION_MODE 설정에 따라 이후 로그인하는 사용자의 계정 자동 생성 여부가 결정됩니다. 두 사람이 동시에 같은 예산 파일을 열 수 있지만, 문서에서는 충돌하는 편집이 안전하지 않다고 경고하므로 예산을 공유하는 경우 같은 화면을 동시에 수정하지 않도록 주의해야 합니다.

암호화. Actual은 예산 파일별로 종단간 암호화(end-to-end encryption)를 제공합니다. 이 기능을 활성화하면 서버는 내용을 읽을 수 없는 상태로 데이터를 저장하며, 이는 임대 서버를 사용할 때 권장되는 방식입니다. 여기에는 두 가지 결과가 따릅니다. 암호화 비밀번호를 분실하면 재설정 기능이 없으므로 파일은 영구적으로 손실됩니다. 또한 은행 동기화 토큰은 별도로 저장되어 암호화 대상에 포함되지 않으므로, 서버의 데이터베이스에 접근할 수 있는 사람은 해당 토큰을 읽을 수 있습니다.

Firefly III: 복식 부기 및 유일한 자동 가져오기

복식 부기는 모든 거래에 원천 계정과 대상 계정이 존재함을 의미합니다. 식료품을 구매하면 당좌 예금 계좌에서 비용 계정으로 돈이 이동하므로, 아무것도 없는 상태에서 돈이 생겨나지 않습니다. 설명할 수 없는 자금은 범주 합계에 숨지 않고 불균형 계정으로 나타납니다. Firefly III를 선택하는 이유는 예산 관리보다는 회계에 더 가깝기 때문입니다.

프로젝트의 자체 파일을 사용하여 설치합니다:

mkdir -p /srv/firefly
curl -fsSL -o /srv/firefly/docker-compose.yml https://raw.githubusercontent.com/firefly-iii/docker/main/docker-compose.yml
curl -fsSL -o /srv/firefly/.env https://raw.githubusercontent.com/firefly-iii/firefly-iii/main/.env.example
curl -fsSL -o /srv/firefly/.db.env https://raw.githubusercontent.com/firefly-iii/docker/main/database.env

첫 실행 전에 .env을 편집합니다. APP_KEY은 정확히 32자 길이의 문자열이어야 하며, 프로젝트는 이를 생성하는 명령어를 제공합니다:

head /dev/urandom | LC_ALL=C tr -dc 'A-Za-z0-9' | head -c 32 && echo

STATIC_CRON_TOKEN에는 두 번째 32자 문자열이 필요합니다. 해당 compose 파일의 cron 컨테이너는 하루에 한 번 앱을 호출하는데, 유효한 토큰이 없으면 호출이 거부되어 반복 거래와 청구서 알림이 작동하지 않습니다. SITE_OWNER을 본인의 이메일 주소로 설정하고, .env의 데이터베이스 비밀번호를 .db.env의 비밀번호와 일치시킨 다음 시작합니다:

docker compose up -d
docker compose logs -f app

정상적인 첫 실행은 컨테이너 내부 80번 포트에서 앱이 서비스되고 로그가 안정화되면서 끝납니다. 데이터베이스 연결 오류가 반복된다면 .env과 .db.env의 비밀번호가 일치하지 않는 것이며, 이 경우 앱이 MariaDB에 로그인할 수 없습니다.

자동 가져오기. Data Importer는 별도의 컨테이너로 실행되며 FIREFLY_III_ACCESS_TOKEN에 있는 개인 액세스 토큰을 사용하여 Firefly III를 인증합니다. 대화형 방식으로 가져오기 설정을 한 번 구성하고 제공된 설정 파일을 저장한 뒤, cron이 일정에 따라 자동 가져오기 엔드포인트로 요청을 보내도록 합니다. 사람들이 Firefly III가 동기화된다고 말할 때 의미하는 바가 바로 이것입니다. 애그리게이터가 은행 연결을 유지하고, 임포터가 데이터를 수집하며, 사용자가 잠든 사이에 서버가 작업을 수행합니다.

다중 사용자. Firefly III는 AUTHENTICATION_GUARD=web에서 선택한 자체 데이터베이스에 실제 계정을 보관합니다. 대신 remote_user_guard을 가리키도록 설정하면 Authelia와 같은 인증 프록시가 로그인을 처리하고 헤더에 사용자 이름을 전달합니다. LDAP은 더 이상 지원되지 않습니다. 인터넷에서 접근 가능한 인스턴스의 경우, 첫 로그인 후 관리 페이지를 열어 다른 사람이 가입할 수 있는지 여부를 제어하는 단일 사용자 모드 설정을 확인하십시오.

암호화. 저장 데이터에 대한 암호화는 없습니다. 거래 내역은 MariaDB에 읽기 가능한 형태로 저장되므로, 데이터베이스 비밀번호를 알거나 볼륨 사본을 가진 사람은 누구나 귀하의 금융 기록을 볼 수 있습니다. 앞단에서 TLS를 종료하고, 가능한 한 공개 인터넷에 노출하지 않으며, 백업을 암호화하십시오.

Beancount와 Fava: 원장은 텍스트 파일입니다

Beancount는 일반 텍스트 기반의 복식 부기 문법입니다. 거래 내역은 사용자가 소유한 파일 내 몇 줄의 텍스트로 기록됩니다.

2026-08-19 * "Supermarket" "Weekly shop"
  Expenses:Food:Groceries   42.10 EUR
  Assets:Bank:Checking

Fava는 해당 파일을 위한 웹 인터페이스입니다. 차트, 대차대조표, 손익계산서를 시각화하며 소스 파일을 직접 수정할 수도 있습니다. 가상 환경에 설치하십시오.

sudo apt update && sudo apt install -y python3-venv
python3 -m venv ~/.venvs/fava
~/.venvs/fava/bin/pip install fava
~/.venvs/fava/bin/fava --read-only ~/ledger/main.beancount

Ubuntu 24.04에서 일반적인 pip3 install fava 명령은 error: externally-managed-environment 오류로 인해 실패합니다. 이는 apt가 시스템 Python을 관리하기 때문이며, 따라서 가상 환경을 사용하는 것이 임시방편이 아닌 올바른 해결책입니다.

Fava는 기본적으로 localhost의 5000번 포트에서 대기합니다. -H으로 호스트를, -p로 포트를 변경할 수 있으나, 외부 공개 범위를 넓히기 전에 신중히 고려하십시오. Fava에는 로그인 기능이 없습니다. 명령줄 인터페이스에도 사용자 이름이나 비밀번호 옵션이 없으므로, 해당 포트에 접근할 수 있는 모든 사용자가 모든 거래 내역을 읽을 수 있습니다. 기본 호스트 설정을 유지하고 SSH 터널, VPN 또는 인증 기능을 갖춘 프록시를 통해 접근하십시오. --read-only 플래그는 브라우저를 통한 쓰기 작업을 차단합니다. 노트북에서 파일을 직접 편집하고 커밋하는 경우 이 설정을 사용하는 것이 좋습니다.

다중 사용자 및 암호화. 사용자 모델이 존재하지 않습니다. 하나의 인스턴스는 식별 정보 없이 하나의 원장만을 서비스하므로, 공유하려면 프록시의 로그인 정보를 공유해야 합니다. 암호화는 age나 gpg를 사용한 파일 암호화, 또는 암호화된 백업 저장소 등 사용자가 직접 적용해야 합니다. 텍스트 원장의 장점은 git을 통해 이력 관리, blame 확인, 원격 복사본 생성을 무료로 이용할 수 있다는 점입니다.

Wallos: 반복 비용 관리를 위한 경량 도구

services:
  wallos:
    image: bellamy/wallos:latest
    ports:
      - "8282:80/tcp"
    volumes:
      - './db:/var/www/html/db'
      - './logos:/var/www/html/images/uploads/logos'
    restart: unless-stopped

Wallos는 모든 데이터를 db/wallos.db의 SQLite 파일 하나에 저장합니다. 여러 통화를 지원하며 환율 변환 기능을 갖추고 있고, 이메일, Discord, Telegram, Gotify, Pushover 또는 웹훅을 통해 다가오는 갱신 알림을 보낼 수 있습니다. 설정 페이지에서 추가 로그인을 생성할 수 있으며, 각 계정은 독립적인 목록을 가집니다.

이 도구의 용도를 명확히 이해해야 합니다. Wallos는 일일 지출을 추적하지 않으며 예산 개념도 없습니다. 이 도구는 "매달 얼마를 지불하고 있으며, 다음 주에 갱신되는 항목은 무엇인가?"라는 질문에 답하는 데 특화되어 있습니다. 많은 사용자가 바로 이러한 이유로 Actual과 함께 이 도구를 사용합니다. 만약 관리하려는 반복 금액이 지불하는 비용이 아니라 청구해야 할 금액이라면, 자체 호스팅 인보이스 소프트웨어를 확인하십시오.

Maybe는 어떤가요?

많은 스레드에서 Maybe Finance를 추천하므로 이에 대한 답변이 필요합니다. 해당 저장소의 README에는 더 이상 활발하게 유지보수되지 않는다고 명시되어 있으며, 최종 릴리스는 v0.6.0으로 태그되었고 코드는 AGPLv3 라이선스를 따릅니다. 현재도 실행은 가능합니다. 예산 데이터는 10년 이상 보관해야 하는 데이터이며, 데이터베이스 스키마와 은행 자격 증명을 보관하는 소프트웨어가 유지보수되지 않는다는 것은 데이터를 보관하기에 적절하지 않습니다. 이는 2026년 8월 기준의 상황이므로, 사용을 결정하기 전에 직접 저장소를 확인하십시오.

이 서비스들은 어느 정도의 서버 사양을 요구합니까?

이 서비스들은 모두 규모가 작으므로, 블로그의 수치를 맹신하기보다 직접 측정하는 것이 좋습니다. 일반적인 사용 환경에서 하루를 보낸 뒤 서버에서 다음 명령을 실행하십시오.

docker stats --no-stream

MEM USAGE 열을 확인하십시오. Actual, Wallos, Fava는 각각 하나의 작은 프로세스가 하나의 작은 파일을 다루는 형태이므로, 다른 서비스와 함께 적당한 사양의 VPS에서 충분히 운영할 수 있습니다. Firefly III는 MariaDB를 스택에 포함하고 있어 다릅니다. 데이터베이스 서버는 쿼리 여부와 관계없이 메모리를 점유하기 때문입니다. 트랜잭션보다는 데이터베이스를 위한 여유 메모리를 계획하십시오. 그렇다 하더라도 가계부 앱 때문에 VPS 자원이 고갈되는 경우는 드뭅니다. 만약 전체 스택을 하나의 서버에 구성한다면, PhotoPrism과 Immich의 최소 메모리 요구 사항이 서버의 RAM 용량을 결정할 가능성이 훨씬 높습니다.

데이터 자체는 거의 늘어나지 않습니다. 10년 치 가계부 트랜잭션 데이터도 수 메가바이트 수준이므로 디스크 용량은 제약 사항이 아닙니다. 이러한 데이터의 장기 보관이 갖는 실질적인 중요성은 다음 섹션에서 다룹니다.

모바일 환경의 현주소와 아쉬운 점

이 지점이 바로 셀프 호스팅 금융 앱이 상용 앱에 밀리는 부분입니다. 가계 전체의 자산 관리를 이전하기 전에 현실적인 기대를 가져야 합니다.

공식 문서상으로 모바일 전용 애플리케이션은 지원이 중단되었습니다. 대신 제공되는 것은 웹 버전이며, 자체 문서에서는 이를 홈 화면에 설치하여 네이티브 앱처럼 사용할 수 있는 반응형 프로그레시브 웹 앱(PWA)으로 설명합니다. 동작은 원활하지만 앱 스토어에서 내려받는 앱은 아닙니다. 다만 커뮤니티에서 비공식 네이티브 클라이언트를 유지보수하고 있습니다.

Firefly III 역시 공식 앱을 제공하지 않지만, API를 활용한 두 가지 우수한 비공식 앱이 존재합니다. Waterfly III는 Android용 앱으로 Google Play와 F-Droid에 배포되어 있습니다. Abacus는 iPhone, iPad, Android에서 실행되며 OAuth2로 로그인하고 iOS 키체인에 토큰을 저장합니다. 두 앱 모두 휴대폰에서 인스턴스에 접근할 수 있어야 합니다.

Fava와 Wallos는 반응형 웹 페이지 외에 별도의 기능을 제공하지 않습니다. 휴대폰으로 원장을 읽는 것은 괜찮지만, 휴대폰 키보드로 Beancount 트랜잭션을 입력하는 것은 불편합니다.

모든 서비스에 공통으로 적용되는 사항이 있습니다. 모바일 데이터를 사용하는 휴대폰은 홈 네트워크에 연결된 상태가 아닙니다. TLS와 강력한 인증을 적용한 도메인에 앱을 공개하거나, 휴대폰을 VPN에 연결해야 합니다. 금융 앱을 단일 비밀번호 하나로 보호한 채 인터넷에 그대로 노출하는 것은 반드시 피해야 할 실수입니다. 두 방법 모두 마음에 들지 않는다면, 인스턴스를 v3 onion 서비스 뒤에 배치하는 것이 세 번째 대안이 될 수 있습니다. 이 방식은 공개 DNS 레코드가 필요 없고 인터넷에 포트를 개방할 필요도 없지만, 휴대폰에서 Tor Browser를 통해 접속해야 한다는 제약이 있습니다.

백업: 이 범주에서 가장 중요한 섹션

미디어 라이브러리를 잃어버리면 다시 다운로드하면 그만입니다. 하지만 5년간 정리한 거래 내역을 잃어버리면 다시는 복구할 수 없습니다. 첫날부터 백업을 설정하십시오.

애플리케이션별 복사 대상:

Actual Budget: server-files 및 user-files을 포함한 전체 데이터 볼륨.
Firefly III: 데이터베이스 덤프, .env, .db.env 및 업로드 볼륨.
Beancount: 원장 파일(ledger file). 원격 저장소가 있는 git 저장소로 관리하는 것이 좋습니다.
Wallos: db/wallos.db 및 업로드된 로고 디렉터리.

실행 중인 SQLite 파일을 그대로 복사하는 것은 복구 불가능한 백업을 만드는 전형적인 방법입니다. SQLite는 최근 쓰기 작업을 별도의 write ahead log 파일에 보관하므로, .sqlite 파일만 복사하면 최신 거래 내역이 누락되거나 파일 자체가 열리지 않을 수 있습니다. 복사하는 몇 초 동안 컨테이너를 중지하십시오:

cd /srv/actual
docker compose stop actual_server
tar czf /srv/backups/actual-$(date +%F).tgz -C /srv/actual actual-data
docker compose start actual_server

Firefly III는 덤프 파일이 필요합니다. 데이터베이스 컨테이너 내부에서 덤프를 생성하여 비밀번호가 셸 히스토리에 남지 않도록 하십시오:

cd /srv/firefly
docker compose exec -T db sh -c 'mariadb-dump -u firefly -p"$MYSQL_PASSWORD" firefly' > /srv/backups/firefly-$(date +%F).sql

구형 MariaDB 이미지는 동일한 도구를 이전 이름인 mysqldump으로 제공합니다. .env와 .db.env를 덤프 파일과 함께 보관하십시오. 설정 파일이 없는 상태에서 데이터베이스만 복구하는 것은 최악의 상황에서 해결해야 할 골치 아픈 문제가 됩니다.

같은 VPS에 복사본을 두는 것은 실수로 인한 편집으로부터는 보호해주지만, 서버를 분실하거나 서버가 침해당하는 상황에서는 보호해주지 못합니다. restic을 사용하여 백업 디렉터리를 객체 스토리지로 전송하십시오. restic은 데이터가 서버를 떠나기 전에 저장소를 암호화합니다:

export RESTIC_REPOSITORY=s3:s3.example.com/money-backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /srv/backups
restic forget --keep-daily 7 --keep-weekly 8 --keep-monthly 12 --prune

이제 restic snapshots 명령을 실행하면 오늘 날짜가 찍힌 스냅샷 목록이 표시되어야 합니다. 스케줄링, 자격 증명, systemd 타이머에 관한 내용은 VPS에서 암호화된 restic 백업을 수행하는 가이드에서 다룹니다.

한 번도 복구해 본 적 없는 백업은 추측에 불과합니다. 아무런 문제가 없는 지금, 한 번 테스트해 보십시오:

restic restore latest --target /tmp/restore-test

Actual 아카이브를 임시 디렉터리에 풀고, 다른 포트에서 두 번째 컨테이너를 시작하여 열어 보십시오. 백업 시점의 잔액이 포함된 계좌 내역이 보여야 합니다. Firefly III의 경우, 덤프를 임시 데이터베이스에 로드한 뒤 transactions 테이블의 행 수를 확인하십시오. 실제 인스턴스와 숫자가 일치한다면 백업이 정상적으로 이루어진 것입니다. 테스트가 끝나면 임시 인스턴스는 삭제하십시오. 실제 금융 데이터가 포함된 테스트 인스턴스를 방치하는 것 자체가 또 다른 보안 문제가 될 수 있습니다.

애플리케이션 하나를 골라 실제 데이터를 넣고 한 달간 운영해 보면서, 같은 주에 백업까지 정상 작동하도록 설정하십시오. 어떤 데이터를 직접 호스팅할지 고민 중이라면, 2026년 직접 호스팅할 가치가 있는 서비스 모음에서 나머지 스택을 확인해 보십시오.

FAQ

은행과 연동할 수 있는 셀프 호스팅 가계부 앱은 무엇인가요?

Actual Budget과 Firefly III 모두 직접 연결 방식이 아닌 제3자 애그리게이터를 통해 은행과 연동할 수 있습니다. Actual은 북미의 SimpleFIN Bridge, 유럽의 Enable Banking, 뉴질랜드의 Akahu, 브라질의 Pluggy.ai 등을 지원합니다. Actual의 문서에 따르면 은행 데이터는 자동으로 동기화되지 않으므로 사용자가 직접 버튼을 눌러야 합니다. Firefly III는 별도의 Data Importer 컨테이너를 사용하며 cron으로 실행을 자동화할 수 있어, 진정한 의미의 무인 자동화를 지원합니다. Beancount와 Wallos는 은행 연동 기능을 제공하지 않습니다. 기능보다 지원 범위가 선택의 핵심이므로, 앱을 선택하기 전에 애그리게이터가 본인의 은행을 지원하는지 먼저 확인하십시오.

스마트폰에서 이러한 가계부 앱을 사용할 수 있나요?

네, 공식 앱은 없지만 사용 가능합니다. Actual의 문서는 공식 모바일 앱이 더 이상 지원되지 않음을 명시하며, 홈 화면에 설치하여 사용하는 반응형 웹 앱인 웹 버전을 권장합니다. Firefly III는 안드로이드용 Waterfly III, iOS 및 안드로이드용 Abacus와 같은 우수한 비공식 클라이언트를 제공합니다. Fava와 Wallos는 반응형 웹 페이지로만 동작합니다. 어떤 경우든 스마트폰에서 서버로 접근해야 하므로, TLS와 강력한 인증이 적용된 도메인을 설정하거나 VPN을 통해 접속하십시오.

데이터베이스 손상 없이 셀프 호스팅 가계부 앱을 백업하려면 어떻게 해야 하나요?

실행 중인 SQLite 파일을 단독으로 복사하지 마십시오. SQLite는 최근 쓰기 작업을 별도의 write ahead log에 보관하므로, 쓰기 도중에 복사하면 트랜잭션이 누락되거나 파일을 열 수 없게 될 수 있습니다. 컨테이너를 중지하고 데이터 디렉토리를 복사한 뒤 다시 시작하십시오. 이 앱들은 규모가 작아 몇 초면 충분합니다. Firefly III의 경우, 데이터베이스 컨테이너 내부에서 mariadb-dump을 실행하여 덤프를 생성하고, 환경 설정 파일과 함께 보관하십시오. 생성된 결과물은 암호화된 restic 저장소로 외부로 전송하고, 복원 테스트를 통해 정상 작동 여부를 확인하십시오.

Firefly III는 소규모 VPS에서 사용하기에 너무 무거운가요?

이 목록에서 가장 무거운 옵션입니다. 공식 compose 파일이 앱 및 cron 컨테이너와 함께 MariaDB 서버를 별도로 실행하기 때문입니다. 개인 금융 데이터는 매우 작으므로, 메모리 대부분은 트랜잭션 처리가 아닌 유휴 상태의 데이터베이스 프로세스가 점유합니다. 일반적인 사용 후 본인의 서버에서 docker stats --no-stream를 실행하여 MEM USAGE 열을 직접 확인하십시오. 공개된 수치를 맹신하지 않는 것이 좋습니다. 가장 가벼운 환경을 원한다면, 단일 프로세스로 단일 파일을 처리하는 Actual Budget이나 Wallos를 선택하십시오.

#budgeting#personal-finance#self-hosting #docker #privacy