# 스토어 상태

v1.10.0 신규 기능

스토어 상태는 **WCPOS v1.10.0**에서 도입되었습니다. 기존의 단독 로그 화면을 대체하며, 동기화 상태와 로컬 데이터 커버리지, 서버 부하를 실시간으로 확인할 수 있게 해 줍니다.

**스토어 상태**는 내 기기와 WooCommerce 스토어 사이에서 일어나는 모든 일을 보여주는 POS의 대시보드입니다. 내비게이션 서랍의 심박 아이콘으로 엽니다. **성능**, **데이터베이스**, **로그** 세 개의 탭으로 구성됩니다.

## 성능[​](#performance "성능으로 직접 링크")

성능 탭은 “POS가 내 서버에 얼마나 부담을 주고 있는가, 그리고 동기화는 정상인가?”에 답합니다.

* **상태 표시줄** — 엔진의 현재 상태에 따라 `✓ Normal` 또는 `⚠ Needs attention`으로 표시됩니다(이미 회복된 일시적 문제로 하루 종일 경고가 남아 있지는 않습니다).
* **측정된 활동** — 지난 24시간 동안의 요청 수와 일반적인 응답 시간은 추정치가 아니라 이 계산대에서 측정한 값입니다. 전송된 데이터 양은 하한값입니다. 크기가 명시되지 않은 응답은 0으로 계산되기 때문입니다.
* **가동 시간 표시줄** — 지난 24시간을 시간당 한 칸으로 보여줍니다. 초록색은 해당 시간에 요청이 오류 없이 완료되었다는 뜻이고, 주황색은 요청이 하나 이상 실패했다는 뜻이며(단 한 건이어도 표시되고 별도의 기준값은 없습니다), 빈 칸은 앱이 실행되지 않았다는 뜻입니다.
* **다음 확인까지 남은 시간** — 다음 변경 확인 예정 시각입니다. 유휴 상태의 계산대에서는 설정된 간격보다 길게 표시되는 것이 정상입니다. 확인 간격에는 지터가 적용되고, 10분간 유휴 상태가 지속되면 주기가 느려지기 때문입니다. 조용한 계산대에서 남은 시간이 길게 표시되는 것은 동기화가 멈춘 것이 아니라 정상입니다.

### 동기화 프리셋[​](#sync-presets "동기화 프리셋으로 직접 링크")

세 개의 프리셋 카드가 이 기기의 동기화 적극성을 두 가지 항목으로 설정합니다. POS가 변경 사항을 얼마나 자주 확인하는지, 그리고 한 번에 몇 개의 레코드를 요청하는지입니다:

| 프리셋           | 확인 간격 | 요청당 레코드 수 |
| ---------------- | --------- | ---------------- |
| **에코**         | 5분       | 25               |
| **균형**(기본값) | 60초      | 50               |
| **실시간**       | 10초      | 75               |

공유 호스팅이나 저가형 호스팅에서는 **에코**를, 여러 계산대가 서로의 변경 사항을 빠르게 확인해야 하고 서버가 이를 감당할 수 있을 때는 **실시간**을 선택하세요. **사용자 지정** 슬라이더를 사용하면 전체 범위(5초~~5분, 레코드 10~~100개)를 사용할 수 있습니다.

두 가지를 알아 두세요:

* **설정은 기기별로 적용됩니다.** 한 계산대를 조정해도 다른 기기는 그대로이므로, 조정하려는 계산대마다 동일한 변경을 반복해야 합니다.
* 조절 항목 옆에 표시되는 *하루 약 N건의 요청* 수치는 설정된 간격에서 산출한 명목 확인 빈도이며, 상한이나 예측이 아닙니다. 지터는 실제 횟수를 양방향으로 움직일 수 있고, 변경이 없는 `304`는 비용이 낮지만 여전히 요청 한 건으로 계산됩니다. 유휴 감쇠는 60초 하한보다 빠른 프리셋에서만 횟수를 줄이므로 균형 프리셋을 더 느리게 만들지는 않습니다.

변경 사항은 즉시 적용되며 재시작이 필요 없습니다. 이 수치들의 기술적 배경은 [동기화 성능](/ko/reference/sync-performance.md)을 참조하세요.

## 데이터베이스[​](#database "데이터베이스으로 직접 링크")

데이터베이스 탭은 “이 기기에는 무엇이 있고, 모든 것이 서버에 전달되었는가?”에 답합니다.

상단에는 네 개의 타일이 있습니다. **판매 준비 완료** 마일스톤, 이 기기의 레코드 수, 사용 중인 저장 공간, 전송 대기 중인 변경 사항입니다.

판매 준비 완료는 마일스톤이지 전체 다운로드 조건이 아닙니다

첫 제품이 기기에 도착하는 즉시 전환됩니다. 오프라인 상태여도 이를 막지 않습니다. 기기에 제품이 있는 계산대는 오프라인에서도 판매할 수 있으며, 그것이 바로 로컬 우선 POS의 목적입니다.

### 커버리지 표[​](#coverage "커버리지 표으로 직접 링크")

동기화되는 각 컬렉션마다 **기기에 있는 수**, **서버에 있는 수**, 커버리지 막대가 한 행으로 표시됩니다. 이 숫자들은 엄격한 정직성 원칙을 따릅니다. *서버에 있는 수*는 서버가 실제로 보고한 수치이며 추측값이 아닙니다:

* ***확인 중…*** — POS가 아직 최신 서버 총계를 확보하지 못했습니다. 어떤 행이 약 15분 넘게 이 상태로 남아 있다면 해당 컬렉션의 REST 경로에 문제가 있을 수 있으니 [로그](#logs)를 확인하세요.
* **막대가 부분적으로 채워진 것은 정상인 경우가 많습니다.** 고객은 유휴 시간에 점진적으로 다운로드되고, 카테고리와 쿠폰은 처음 열 때 다운로드되며, **주문** 막대는 전체 주문 이력을 기준으로 측정하는 반면 계산대는 의도적으로 열린 주문과 최근 주문만 보관합니다. 그래서 완벽하게 정상인 계산대에서도 주문은 부분적으로 표시됩니다.
* **“초기화 후 다시 다운로드”를 실행한 뒤 개수가 비어 있거나 적은 것은 동기화가 멈춘 것이 아니라 설계된 결과입니다.** 필요할 때 다운로드되는 컬렉션은 사용하면서 다시 채워지며, 각 행의 설명이 해당 컬렉션이 어떻게 다시 채워지는지 알려 줍니다.

### 서버에 전달되지 않은 변경 사항[​](#refused-changes "서버에 전달되지 않은 변경 사항으로 직접 링크")

서버가 변경 사항을 영구적으로 거부하면(예: 사이트가 요청을 유효하지 않다고 거부한 상태에서 생성된 판매), POS는 이를 조용히 무한 재시도하지 **않으며**, 숨기지도 않습니다. 해당 변경 사항은 보류된 뒤 서버가 제시한 사유, 발생 시각과 함께 여기에 표시되며 두 가지 조치를 제공합니다:

* **다시 보내기** — *현재* 상태의 레코드에서 요청을 다시 구성하여 대기열에 넣습니다. 같은 필드가 다시 거부되면 성공한 척하지 않고 시도 횟수가 눈에 보이게 올라갑니다.
* **삭제** — 변경 사항을 버립니다. 확인 대화 상자는 해당 레코드에서 삭제가 정확히 무엇을 의미하는지 알려 줍니다(그 레코드가 이 기기에만 존재했던 경우 삭제하면 레코드 자체가 사라진다는 점을 포함합니다).

복구는 언제나 의도적이고 눈에 보이는 동작입니다. 여기서 자동으로 이루어지는 것은 없습니다.

### 초기화 후 다시 다운로드[​](#clear-and-redownload "초기화 후 다시 다운로드으로 직접 링크")

각 컬렉션 행에는 **초기화 후 다시 다운로드**가 있으며, 해당 컬렉션의 로컬 사본을 제거하고 다시 가져옵니다. 확인 창은 몇 개의 레코드와 대략 어느 정도의 저장 공간이 삭제되는지, 그리고 무엇이 서버에 안전하게 남는지 알려 줍니다. 모든 로컬 데이터를 초기화하는 것보다 이 방법을 우선하세요. 대상이 한정되어 있고 로그아웃되지도 않습니다. 전체 초기화는 여전히 [모든 로컬 데이터 초기화](/ko/support/troubleshooting/clear-local-data.md)입니다.

## 로그[​](#logs "로그으로 직접 링크")

로그 탭은 이 기기의 동기화 활동 기록으로, 행마다 **시간, 레벨, 이벤트, 소요 시간, 상태**를 보여주며 30일간 보관됩니다.

* **미리 정의된 필터** — 전체 / 작업 / 오류 / 동기화와 함께, 24시간 동안 추가 세부 정보를 수집한 뒤 스스로 꺼지는 **상세 진단** 토글이 있습니다.
* **행 세부 정보** — 오류와 경고를 펼치면 알기 쉬운 원인 설명, 데이터 안전성 안내, 권장 다음 단계, [오류 코드](/ko/error-codes/.md) 도움말 링크가 표시됩니다. 각 세부 정보 화면에는 복사 가능한 이벤트 코드가 있으니 지원팀에 문의할 때 함께 알려 주세요.
* 로그 항목은 표시될 때 번역되므로, 몇 달 전에 기록된 행도 오늘 계산대가 사용하는 언어로 읽힙니다. 안정적인 식별자는 이벤트 코드입니다.

두 개의 탭, 두 개의 집계

로그 탭은 막힌 레코드 수를 로그 항목만으로 산출하지만, 데이터베이스 탭은 보류된 거부 변경 사항까지 포함합니다. 두 값이 다를 때 서버에 전달되지 않은 항목에 대한 기준은 **데이터베이스 탭**입니다.

## 관련 페이지[​](#related "관련 페이지으로 직접 링크")

* [동기화 엔진의 작동 방식](/ko/reference/sync-engine.md) — 레인, 변경 감지, 쓰기 대기열에 대한 개발자 수준의 세부 정보
* [동기화 성능](/ko/reference/sync-performance.md) — 서버를 보호하는 요청 상한과 백오프 규칙
* [서버 성능](/ko/support/performance/server.md) — WordPress/WooCommerce 호스팅 튜닝
* [모든 로컬 데이터 초기화](/ko/support/troubleshooting/clear-local-data.md) — 전체 로컬 초기화