---
title: "erpc worker로 앱을 실행하고 확인하고 비용 지불하기"
description: "앱이 실행 중인지와 시간당 비용을 확인하고, 릴리스를 롤백하고, 서버에서 RPC 지연 시간을 측정하고, 상태 데이터를 백업하고, 시간별 과금을 종료합니다."
canonical: "https://erpc.global/ko/doc/erpc-cli/worker-status-and-billing/"
locale: "ko"
---

# erpc worker로 앱을 실행하고 확인하고 비용 지불하기

`erpc worker status`는 앱이 실행 중인지와 시간당 비용을 보여 줍니다. 무언가를 시작할 때는 항상 가격을 먼저 보여 주며, `erpc worker delete --release-server`는 앱이 시간별 과금으로 사용하는 gRPC, Shreds, Unlimited RPC를 종료한 다음 시간별 과금 서버를 종료합니다.

이 페이지는 프리릴리스인 ERPC CLI `v0.1.0-rc.4`를 설명합니다.

## 앱 확인

```text
$ erpc worker status --env prod
api-prod on 203.0.113.10: running, release 20261101T093000Z-1a2b3c4d, pid 4217, up 2h 14m
  current 20261101T093000Z-1a2b3c4d, previous 20261028T171500Z-9f8e7d6c, 2 releases kept
  WAF: listening on port 8080, forwarding to 127.0.0.1:3000, since 2026-11-01T09:30:12Z; requests 5120, forwarded 5043, blocked 71, connections refused 12, app errors 6, addresses banned now 1
  `erpc worker delete --release-server --env prod` ends what this app is charged for.
```

`status`는 앱이 잠긴 상태인지 실행 중인지, 어떤 릴리스인지, 언제부터인지를 보여 줍니다. 로그인되어 있으면 환경의 시간당 비용도 보여 주는데, 각 항목에는 계정에 청구되는 가격이 함께 표시되고, 계정의 Credit과 그 Credit이 얼마나 유지되는지도 표시됩니다. `--json`은 같은 내용을 `hourly.charged` 아래에 담습니다.

계정의 청구 항목에 없는 항목은 종료되었다고 하지 않고 청구 항목에 없다고 표시합니다. 그 목록이 시작보다 일 분 늦을 수 있기 때문입니다. 세션이 없거나 계정의 청구 항목을 읽을 수 없으면, `status`는 기록에 있는 내용을 보여 줍니다.

## 앱 제어

| 명령 | 하는 일 |
| --- | --- |
| `erpc worker logs -n 200`, `logs -f` | 앱과 에이전트의 로그. 줄 안의 제어 문자는 `?`로 출력됩니다 |
| `erpc worker start` | 앱을 실행합니다. worker가 잠긴 상태이면 키를 보냅니다 |
| `erpc worker stop`, `stop --lock` | 앱을 중지합니다. `--lock`은 메모리에서 키도 지웁니다 |
| `erpc worker restart` | 앱을 중지한 뒤 다시 시작합니다 |
| `erpc worker releases` | 서버에 보관된 릴리스(`deploy.keep_releases`) |
| `erpc worker rollback`, `rollback --to <release>` | 이전 릴리스 또는 지정한 릴리스로 돌아갑니다. 그 릴리스의 헬스 체크 포트를 지금 실행 중인 다른 worker가 쓰고 있으면 거부되며, 사용 중인 릴리스는 그대로 남습니다 |
| `erpc worker api <PATH>` | 이 머신에서 앱의 API를 읽습니다. API는 계속 서버의 loopback에 있습니다(변경하려면 `-X POST`, `-d '{...}'`) |
| `erpc worker trades [--profit]` | 서버에서 앱이 한 거래 |
| `erpc worker list` | 이 머신에 있는 앱과 각 앱이 배포된 곳. `--prune`은 `erpc.toml`이 사라진 앱을 목록에서 뺍니다 |

앱의 `API_TOKEN`은 여기서 읽혀 표준 입력으로 서버에 전달되며, 명령줄에도 저널에도 남지 않습니다. 모든 worker 명령은 `--env <name>`(기본값 `default`)과 `--json`을 받습니다. 단, 앱이 아니라 이 머신의 키스토어에 관한 `secret unlock`과 `secret lock`은 `--env`를 받지 않습니다. 어디서 실행하든 명령은 erpc가 알고 있는 이름으로 앱을 찾습니다. `secret put`, `secret rm`, `key import`, `firewall allow`, `firewall deny`는 `--dir`로만 앱을 지정합니다.

## 시간별 과금의 작동 방식

- **무언가를 시작할 때는 항상 가격을 먼저 보여 줍니다.** 터미널에서는 yes로 답한 뒤에만 시작하며, `--yes`를 쓰면 시작할 대상을 지정한 명령줄 자체가 yes 응답이 됩니다.
- **시간별 과금 상품은 ERPC Credit으로 결제되며**, ERPC Credit은 미리 구매합니다. Credit으로 충당되지 않는 시작은 거부됩니다. 가격은 [요금제](https://erpc.global/ko/price/)와 [ERPC Web Dashboard](https://dashboard.erpc.global/ko)에 나와 있습니다.
- **새 VPS는 이름이 정해지는 즉시,** 준비되기 전에 기록에 남습니다. 다음 배포는 VPS를 새로 사지 않고 그 VPS를 이어받습니다.
- **`deploy`에서 응답을 받지 못한 시작은 다시 보내지며, 새 요청으로 보내지는 일은 없습니다.** 요청 키가 기록에 남으므로(`[env.<name>.starting]`), 같은 명령을 다시 실행하면 같은 요청을 보냅니다. 응답에 따라서는 직접 제거할 때까지 요청 키가 남아 있습니다([erpc가 기록하지 못한 구매](https://erpc.global/ko/doc/erpc-cli/worker-troubleshooting/#erpc가-기록하지-못한-구매)). `erpc worker run`은 기록을 남기지 않으므로, 다음 실행에서는 새 요청을 만듭니다.
- **환경은 한 번에 하나씩 배포하세요.** 같은 환경의 배포 두 개를 동시에 시작하면 두 개를 구매하게 될 수 있으며, 이는 지원되지 않습니다.
- **회선이 아직 존재하는지는 계정에 청구되는 항목으로 판단합니다.** 시간별 과금이 아닌 회선은 erpc가 절대 종료하지 않습니다. 대시보드에서 종료하세요.

## 앱 제거

`erpc worker delete`는 worker를 제거합니다. `erpc worker delete --release-server`는 회선도 종료한 다음 시간별 과금 서버를 종료합니다. 종료하지 못한 것은 기록에 남으며, 시간별 과금이 아닌 회선은 대시보드에서 종료하도록 이름이 표시됩니다.

- 옵션 없는 삭제는 구매했지만 한 번도 접속하지 못한 VPS에 대해서는 거부됩니다. 과금 중인 VPS를 기록에서 잊게 되기 때문입니다. 접속한 적이 있는 시간별 과금 VPS를 옵션 없이 삭제하면, 아직 과금 중인데도 기록에서 빠지며 이에 대해 경고합니다.
- `--forget`은 더 이상 접속할 수 없는 서버에 접속을 시도하지 않고 그대로 두며, `--forget-line <id>`는 erpc 밖에서 종료된 회선을 기록에서 뺍니다.

## 서버에서 RPC 지연 시간 측정

`erpc worker bench`는 환경의 서버에서 RPC 호출 시간을 잽니다. ERPC의 공유 RPC, ERPC의 Unlimited RPC, 그리고 그 밖의 RPC를 나란히 비교합니다. 서버의 에이전트가 각 호출 시간을 재므로, 수치는 앱이 실제로 얻는 값입니다.

```bash
erpc worker bench                                  # getSlot: shared RPC vs the Unlimited RPC
erpc worker bench --rounds 300 --interval 150      # for a plan that limits calls per second
erpc worker bench --url other=op://<vault-id>/<item-id>/url   # another provider's RPC
```

- `--method`는 `getSlot`, `getBlockHeight`, `getLatestBlockhash`, `getHealth` 중 하나를 받습니다.
- `--no-shared`는 공유 RPC를 제외합니다. `--url` 값은 URL 자체, `op://…`, `keychain:…`, `keystore:…` 참조(키가 들어 있는 URL을 보관한 곳을 가리킴. 트레이딩 키의 항목을 가리키는 참조는 절대 허용되지 않으며 거부됨), 또는 `-`(표준 입력에서 읽거나, 화면에 보이지 않게 입력받음)일 수 있습니다. 엔드포인트가 여섯 개를 넘으면 거부됩니다.
- 벤치는 p50, p90, p99, 최솟값, 최댓값, 첫 번째 사유가 포함된 실패, 그리고 각 응답이 같은 라운드에서 가장 최신인 응답보다 몇 슬롯 뒤처졌는지를 출력합니다.
- 키는 표준 입력으로만 서버에 전달되며, 표에는 스킴, 호스트, 포트가 표시됩니다.

## 앱의 상태 데이터 백업

`erpc worker backup on`은 앱의 상태 데이터를 restic으로 암호화해 매일 ERPC Global Storage에 백업합니다. 백업은 서버 시간 기준으로 `--at`에 지정한 시각부터 30분 이내에 실행됩니다. 스토리지 요금제가 필요합니다(`erpc storage buy 5`).

- **백업 대상**은 앱의 상태 데이터인 `/var/lib/private/erpc-worker-<id>`입니다. 릴리스는 배포가 다시 넣어 주므로 백업하지 않습니다. Redis와 PostgreSQL 데이터는 포함되지 않습니다.
- **서버는 스냅샷을 삭제할 수 없습니다.** 서버는 erpc 세션, 계정의 관리자 키, 마스터 비밀번호를 절대 갖지 않습니다.
- **탈취된 서버는** 이 머신을 포함해 계정에 있는 모든 머신의 스냅샷을 읽을 수 있고, restic이 절대 바꾸지 않는 리포지토리 키를 `off` 이후에도 보관할 수 있으며, 다른 머신의 이름으로 스냅샷을 추가할 수 있으므로 그런 일이 있었다면 `restore latest`가 무엇을 고르는지 확인하세요. 또한 계정의 스토리지를 가득 채워 모든 머신의 백업을 멈추게 할 수 있습니다. `erpc worker backup off`는 서버가 응답하든 하지 않든 먼저 서버의 액세스 키를 폐기합니다.
- worker가 실행되는 동안 **restic은 파일을 있는 그대로 복사하므로**, 데이터베이스를 일관된 상태로 복원하려면 별도의 덤프가 필요할 수 있습니다. 서버가 꺼져 있는 동안 놓친 실행은 서버가 다시 켜지면 실행됩니다.
- `erpc worker backup off`, `status`, `now`는 각각 백업을 중지하고, 상태를 보고하고, 백업을 실행합니다. 스냅샷은 `off` 이후에도 남으며, `erpc backup prune --host`는 오래된 스냅샷을 솎아 냅니다.

이 머신에서 `erpc backup init`을 실행한 뒤 복원하세요.

```bash
erpc backup restore latest --from-host erpc-worker-<id>-<tag> --path /var/lib/private/erpc-worker-<id> --target ./restored
```

## 여러 환경과 머신

- 한 서버의 여러 worker는 각자 자체 유닛으로 실행되고, 서버의 방화벽 테이블을 공유하며, 각자 자기 포트만 엽니다.
- 앱 하나에 여러 환경(`[env.staging]`, `[env.prod]`)을 둘 수 있으며, 환경마다 자체 서버와 회선을 갖습니다.
- 환경은 서버 정보를 `erpc.toml` 대신 1Password에 둘 수 있습니다. 그러면 그 보관함에 로그인되어 있고 앱의 리포지토리가 있는 머신이라면 어느 머신에서든 모든 명령을 실행할 수 있습니다. 이런 앱의 `keychain:`과 `keystore:` 참조는 다른 머신이 읽을 수 없으므로 경고가 표시됩니다. `erpc login`이 세션을 1Password에 보관하면 새 환경은 정보를 그곳에 둡니다. `deploy --vault <vault-id>`는 다른 보관함을 지정하고, `deploy --inline`은 정보를 `erpc.toml`에 둡니다.
