> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# 시스템 상태

> 네트워크와 거래소, 브릿지가 정상 동작하는지 확인하는 방법. 누가 발표해 주기를 기다리지 않고 직접 검증할 수 있는 항목까지 다룹니다.

<Note>
  공개 상태 페이지는 [2026년 9월 20일 공개 테스트넷](/ko/protocol/roadmap/milestones)과 함께 시작됩니다. 그때까지는 아래 검사가 네트워크가 무엇을 하고 있는지 확인하는 최종 근거이며, 그 이후에도 최종 근거로 남습니다. 체인에 관한 보고서가 아니라 체인 자체를 읽기 때문입니다.
</Note>

<h2 id="check-the-chain-directly">
  체인을 직접 확인하기
</h2>

가장 믿을 만한 신호는 누군가 관리하는 페이지가 아닙니다. 체인 자체이며, 요청 한 번으로 답합니다.

노드 RPC 루트는 네트워크의 현재 상태를 반환합니다.

```json theme={null}
{
  "chain_id": 2,
  "node_role": "validator",
  "block_height": "1540443",
  "ledger_version": "5046975",
  "epoch": "125",
  "oldest_ledger_version": "0"
}
```

몇 초 간격으로 두 번 호출하십시오. **`block_height`가 올라가고 있다면 네트워크는 블록을 만들고 있는 것입니다.** [매칭, 클리어링, 청산이 모두 블록 실행 안에서 돌기](/ko/protocol/architecture/kernel) 때문에, 블록을 만들고 있는 네트워크는 곧 매칭하고 클리어링하고 청산하는 거래소입니다. 체인은 살아 있는데 따로 죽어 있을 수 있는 별도의 거래소 프로세스란 없습니다.

이것은 운영상의 주장이 아니라 구조적 성질입니다. 매칭 엔진이 체인 옆의 별도 서비스인 거래소에서는 "체인은 정상이다"와 "거래가 된다"가 진짜로 다른 질문입니다. 여기서는 같은 질문입니다.

엔드포인트는 [현재 네트워크](/ko/protocol/architecture/network-status)에 정리되어 있습니다.

<h2 id="what-can-actually-be-degraded">
  실제로 품질이 떨어질 수 있는 부분
</h2>

일부 구성 요소는 *실제로* 독립적으로 고장 날 수 있고, 하나씩 이름을 알아 둘 만합니다. 각각이 눈에 보이는 방식으로 고장 나기 때문입니다.

| 구성 요소                                              | 증상                         | 계속 동작하는 것                       |
| -------------------------------------------------- | -------------------------- | ------------------------------- |
| **[인덱서](/ko/protocol/architecture/indexer)**       | 과거 데이터 조회와 스트림이 지연되거나 멈춥니다 | 거래. 주문 제출과 실행은 인덱서에 의존하지 않습니다   |
| **[오라클](/ko/protocol/architecture/oracle)**        | 특정 마켓의 인덱스 가격이 갱신을 멈춥니다    | 오더북. 그 마켓의 마크 가격과 펀딩은 품질이 떨어집니다 |
| **[브릿지](/ko/protocol/architecture/bridge)**        | 입금이나 출금이 멈춥니다              | 이미 보유한 잔액으로 하는 거래               |
| **[프로그램 서비스](/ko/protocol/architecture/programs)** | 수수료 등급이 갱신을 멈춥니다           | 거래. 현재 적용된 수수료율로 계속됩니다          |
| **웹 프런트엔드**                                        | 사이트에 접속되지 않습니다             | API를 통해 전부                      |

패턴을 짚어 둘 만합니다. **거래 경로는 이 중 어느 것에도 의존하지 않습니다.** 각각은 체인이 이미 수락한 입력으로서 실행의 상류에 있거나, 체인이 커밋한 내용을 읽는 쪽으로서 하류에 있습니다. 어느 위치도 블록을 멈출 수 없습니다.

통합 관점에서의 결론은, "인덱서가 뒤처졌다"와 "내 주문이 실행되지 않았다"가 서로 무관한 진단이라는 것입니다. 둘을 하나의 신호로 다루면 엉뚱한 곳을 뒤지게 됩니다.

<h2 id="checking-your-own-view">
  내 쪽 상태 확인하기
</h2>

그 RPC 응답의 두 필드가, 사람들이 보통 지원팀에 묻는 질문에 답합니다.

**`chain_id`는 어느 네트워크에 연결되어 있는지 확인해 줍니다.** 잔액이 하나도 안 보이는 것처럼 동작하는 클라이언트는, 장애를 겪고 있는 경우보다 엉뚱한 네트워크를 가리키고 있는 경우가 훨씬 많습니다.

**`oldest_ledger_version`은 이 노드가 히스토리를 어디까지 보관하는지 알려 줍니다.** 공격적으로 프루닝된 노드는 현재 상태는 정확히 제공하면서 과거 데이터 조회에는 전혀 답하지 못합니다. 데이터 손실처럼 보이지만 그렇지 않습니다. [상태 동기화](/ko/protocol/architecture/state/sync)를 참고하십시오.

<h2 id="what-the-status-page-will-cover">
  상태 페이지가 다룰 내용
</h2>

공개 테스트넷과 함께 시작될 때 다루는 항목입니다.

* **구성 요소별 상태**. 위의 각 영역을 하나의 지표로 뭉뚱그리지 않고 개별적으로 보고
* **예정된 점검**. 시간대와 예상 영향을 함께 사전 공지
* **장애 이력**. 해결되었다고 지우지 않고 보존
* **장애 진행 중 실시간 업데이트**

실행, 자금, 보유 포지션에 영향을 준 장애는 [프로토콜 체인지로그](/ko/protocol/roadmap/changelog)에도 기록되므로, 영구 기록이 상태 페이지에만 남지는 않습니다.

<h2 id="reporting-a-problem">
  문제 신고하기
</h2>

무언가 잘못된 것 같은데 체인이 블록을 만들고 있다면, 특정 영역이나 해당 통합에 국한된 문제일 가능성이 큽니다. 무엇을 하고 있었는지, 어떤 엔드포인트였는지, 트랜잭션 해시나 주문 ID가 있다면 그 값, 블록 높이나 타임스탬프를 함께 적으십시오.

`contact@intention.xyz`로 보내십시오. 취약점으로 의심되는 사안은 [버그 바운티](/ko/protocol/security/bug-bounty) 절차를 대신 이용하십시오. 제목에 **Security**를 넣으면 일반 메일보다 먼저 전달됩니다.

<h2 id="where-to-go-next">
  다음으로 읽을 문서
</h2>

<CardGroup cols={2}>
  <Card title="현재 네트워크" href="/ko/protocol/architecture/network-status">
    체인 식별자와 운영 중인 엔드포인트, 무엇을 기대할 수 있는지.
  </Card>

  <Card title="프로토콜 체인지로그" href="/ko/protocol/roadmap/changelog">
    릴리스와 장애를 날짜별로 남긴 기록.
  </Card>

  <Card title="문의" href="/ko/help/contact">
    팀에 연락하는 방법.
  </Card>

  <Card title="개발자" href="/ko/developers/overview">
    API, 그리고 장애 상황에서도 무너지지 않는 통합을 만드는 요령.
  </Card>
</CardGroup>