가이드

작성자 Matt Connor 2026-10-18

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

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

간단한 답변

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

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

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

각 서비스의 실행 구성 비교

차트Services, 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 via admin page

None at rest

이 차트의 데이터

[
  {
    "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 via admin page",
    "encryption": "None at rest"
  }
]

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

은행 거래 내역을 자동으로 가져올 수 있는 셀프 호스팅 가계부 앱은 무엇인가요?

어떤 셀프 호스팅 앱도 은행과 직접 연결되지 않습니다. 은행은 오픈 뱅킹 API를 통해 거래 내역을 제공하며, 이 API는 은행과 관계를 맺고 접근 권한을 재판매하는 애그리게이터(aggregator)를 통해 연결됩니다. 따라서 핵심 질문은 두 가지입니다. 해당 앱이 애그리게이터와 통신하는가, 그리고 본인의 은행을 지원하는 애그리게이터 계정을 생성할 수 있는가입니다.

Actual Budget은 여러 애그리게이터를 지원합니다. 2026년 10월 기준 문서에 따르면 뉴질랜드의 Akahu, 유럽의 Enable Banking 및 GoCardless Bank Account Data, 북미의 SimpleFIN Bridge, 브라질의 Pluggy.ai를 지원합니다. 사용자가 직접 해당 제공업체에 가입하여 키와 비밀 값을 생성한 뒤, 이를 서버에 입력해야 합니다. 두 가지 제한 사항이 있습니다. 현재 안정 버전인 26.10.0에서는 사용자가 버튼을 눌러야 동기화가 실행됩니다. 선택한 간격으로 연결된 계정을 자동으로 동기화하는 설정이 병합되었으나, 2026년 10월 기준 나이틀리 빌드(nightly builds)에서만 제공되며, 그마저도 기기에서 Actual이 실행 중일 때만 동기화가 이루어집니다. 또한 같은 페이지에는 GoCardless가 신규 계정을 받지 않는다는 점이 명시되어 있어, 이전 가이드에서 추천하던 무료 유럽 경로가 막혔습니다. SimpleFIN Bridge는 Actual이 아닌 제공업체에 비용을 지불하는 유료 구독 서비스입니다.

사용자가 직접 조작하지 않아도 Actual이 자동으로 데이터를 가져오길 원한다면, actual-auto-sync라는 커뮤니티 프로젝트를 통해 예약된 일정에 따라 은행 동기화를 실행할 수 있습니다. 이는 Actual 서버 옆에서 실행되는 별도의 컨테이너이며, Actual의 공식 API 패키지를 통해 통신합니다. Actual의 일부가 아니므로 설정하고 업데이트해야 할 서비스가 하나 더 늘어나는 셈입니다.

Firefly III는 가져오기 기능을 별도의 컨테이너인 Firefly III Data Importer로 분리했습니다. 이 컨테이너의 예시 설정에는 GoCardless (Nordigen), Enable Banking, SimpleFIN, Lunch Flow를 위한 자격 증명 슬롯이 있으며, CSV 및 CAMT.053 파일 가져오기도 지원합니다. CAN_POST_AUTOIMPORT=true를 설정하고 AUTO_IMPORT_SECRET에 긴 임의 값을 입력하면, 호스트의 cron job을 통해 브라우저를 열지 않고도 가져오기를 실행할 수 있습니다. 이 비교에 포함된 앱 중 유일하게 자동 동기화가 내장된 방식이며, Actual은 위에서 언급한 추가 커뮤니티 서비스를 사용해야만 가능합니다.

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

수동 가져오기는 언제나 작동하며, 은행이 제공업체를 변경하더라도 영향을 받지 않는 방식입니다. 은행 연결성이 가장 중요한 결정 요소라면, 무엇을 설치하기 전에 본인의 은행이 해당 애그리게이터의 지원 범위에 포함되는지 먼저 확인하십시오. 10분 정도 투자하면 주말 내내 고생하는 일을 방지할 수 있습니다.

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

봉투 예산 관리란 이미 보유한 자금을 지출하기 전에 특정 항목에 할당하는 방식을 의미합니다. 식비에 300, 교통비에 80을 배정하는 식이며, 이 방법론에 따르면 총 할당액은 계좌에 있는 잔액을 초과해서는 안 됩니다. Actual은 이를 강제적인 제한으로 두지는 않습니다. 보유액보다 많은 금액을 할당하면 해당 월은 예산 초과 상태로 표시되며, 초과분은 이를 보전할 때까지 다음 달 예산에서 차감됩니다. 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 명령으로 시작합니다. Actual의 Docker 설치 문서에서는 로컬 네트워크의 다른 컴퓨터에서 http://your-server:5006 주소로 접속하도록 안내하며, 이 경우 HTTPS 없이 앱이 로드됩니다. HTTPS 관련 페이지에서는 Actual의 모든 기능을 안전하게 사용하려면 HTTPS가 필요하다고 명시하며, 이 단계를 생략할 수 있는 두 가지 경우를 제시합니다. 하나는 본인 컴퓨터에서 실행 중인 서버에 localhost를 통해서만 접속하는 경우이고, 다른 하나는 클라우드 제공업체가 HTTPS를 대신 처리해 주는 경우입니다. 데이터 볼륨은 server-files와 user-files라는 두 개의 디렉터리로 구성됩니다. 이 디렉터리들이 곧 사용자의 예산 데이터입니다. 인터넷을 통해 접속하는 VPS 환경이라면, 사용 전 반드시 TLS(transport layer security)를 적용한 리버스 프록시를 앞단에 배치하고 프록시가 제공하는 HTTPS 주소로 앱에 접속하십시오. 자체 서명 인증서도 사용할 수 있지만, 브라우저에서 인증서가 유효하지 않다는 경고가 표시됩니다. 전체 절차는 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

정상적인 첫 실행은 컨테이너 내부의 8080 포트에서 앱이 서비스되고, compose 파일이 이를 호스트의 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 또는 웹훅을 통해 갱신 예정일을 알림으로 보내줍니다. 추가 계정은 관리자 페이지에서 관리자가 생성하며, 해당 페이지에서 회원가입을 허용하거나 OpenID Connect 로그인을 활성화할 수 있습니다. 각 계정은 독립적인 목록을 유지합니다. 설정에서 추가하는 가구 구성원은 비용 지불 주체를 표시하는 라벨일 뿐, 별도의 로그인 계정은 아닙니다.

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

Maybe는 어떤가요?

많은 스레드에서 Maybe Finance를 추천하므로 이에 대한 답변이 필요합니다. 해당 저장소의 README에 따르면 프로젝트는 더 이상 활발하게 유지보수되지 않으며, v0.6.0이 최종 릴리스입니다. 코드는 AGPLv3 라이선스를 따릅니다. 해당 저장소는 2025년 7월 27일에 읽기 전용으로 보관(archived) 처리되었습니다. 현재도 실행은 가능합니다. 예산 데이터는 10년 이상 보관해야 하는 정보이며, 데이터베이스 스키마와 은행 자격 증명을 다루는 소프트웨어가 유지보수되지 않는다는 점은 데이터를 보관하기에 매우 위험합니다. 2026년 10월 시점에도 이 입장은 변함없으므로, 사용을 결정하기 전에 직접 저장소 상태를 확인하십시오.

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

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

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 등의 제공자를 지원하며, 현재 안정화 버전에서는 버튼을 눌러 동기화를 실행합니다. 2026년 10월 기준, 지정된 간격으로 자동 동기화하는 기능은 나이틀리 빌드에서만 제공되며 Actual이 실행 중일 때만 작동합니다. 별도의 컨테이너로 actual-auto-sync라는 커뮤니티 서비스를 사용하면 예약된 시간에 동기화를 실행할 수 있습니다. Firefly III는 cron으로 트리거할 수 있는 별도의 Data Importer 컨테이너를 사용하므로, 무인 가져오기 기능이 내장된 유일한 앱입니다. Beancount와 Wallos는 은행 연동 기능을 전혀 제공하지 않습니다. 기능보다 지원 범위가 선택의 핵심이므로, 앱을 선택하기 전에 애그리게이터가 본인의 은행을 지원하는지 먼저 확인하십시오.

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

네, 하지만 공식 앱은 없습니다. Actual의 문서에 따르면 공식 모바일 앱은 더 이상 지원되지 않으며, 홈 화면에 설치하여 사용하는 반응형 프로그레시브 웹 앱(PWA)인 웹 버전을 권장합니다. Firefly III는 Android용 Waterfly III, iOS 및 Android용 Abacus라는 두 가지 우수한 비공식 클라이언트를 지원합니다. Fava와 Wallos는 반응형 웹 페이지로만 작동합니다. Actual은 예산 데이터를 로컬에 저장하므로 연결 없이도 작동하지만, 동기화 및 은행 데이터 호출을 위해서는 스마트폰이 서버에 접속할 수 있어야 합니다. 다른 앱들은 모든 작업에 서버 연결이 필요합니다. 어떤 경우든 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