문제 해결

차트가 비어 있거나 WebGL 문제가 표시될 때

차트는 WebGL로 그려집니다. 브라우저가 WebGL 컨텍스트를 아예 만들지 못하면, 차트는 초기화에 실패했다고 알리며 브라우저를 업데이트하거나 하드웨어 가속을 켜라고 안내합니다. 이 두 가지가 해결책입니다. 그래픽 컨텍스트가 나중에 손실되는 경우, 예를 들어 GPU가 재설정되거나 탭이 정리되거나 모바일 기기가 절전에서 깨어난 경우, 차트는 렌더링이 멈췄으며 GPU가 복구되면 다시 시작된다고 알립니다. 복구는 자동입니다. 브라우저가 컨텍스트를 복원하면 차트가 GPU 자원을 다시 만들고 현재 캔들을 다시 올리므로 새로고침이 필요하지 않습니다. 재구축 자체가 실패하면 차트는 멈춘 상태로 남고 실패 내용이 브라우저 콘솔에 기록됩니다.

브라우저가 갖추어야 하는 것

캔들스틱 차트와 히트맵 차트는 WebGL2 컨텍스트 위에 그려집니다. 렌더러는 캔버스에 명시적으로 webgl2를 요청하고, 브라우저가 아무것도 돌려주지 않으면 오류를 냅니다. 바로 이 지점에서 차트가 WebGL 초기화에 실패했다고 알리며 브라우저 업데이트나 하드웨어 가속 활성화를 제안합니다. 캔들 자체를 그리는 소프트웨어 경로는 없습니다. 주석 레이어는 일반 2D 캔버스를 쓰지만, WebGL2가 없으면 가격 계열은 아예 그려지지 않습니다. 1세대 WebGL만 지원하는 브라우저나 가속이 꺼진 상태로 실행되는 브라우저에서는 그래서 정확히 그 메시지와 함께 빈 차트가 나옵니다.

컨텍스트가 만들어졌다가 나중에 손실되는 경우, 즉 GPU 드라이버 재설정이나 백그라운드 탭 정리, 모바일 기기의 절전 해제가 있을 때, 차트는 브라우저의 기본 손실 처리를 취소하고(애초에 자동 복원을 가능하게 만드는 것이 바로 이 단계입니다) 멈춤 상태로 전환합니다. 복원되면 GPU 자원을 다시 만들고 버퍼 버전을 무효화해 모든 캔들을 다시 업로드한 뒤 그리기를 재개합니다. 각 단계는 브라우저 콘솔에 [WebGLChart] 접두사가 붙은 줄을 남깁니다. 손실에 하나, 재구축 성공에 하나, 재구축이 실패하면 오류 줄 하나입니다. 빈 차트를 신고할 때는 이 세 줄이 가장 빠른 증거입니다.

로그인 리디렉션, 업그레이드 안내, 꺼진 기능

로그아웃 상태에서 보호된 페이지를 열면 목적지를 보존한 채 로그인 페이지로 이동하고, 로그인 후에는 원래 목적지로 돌아옵니다. 같은 상황에서 API 요청은 401과 UNAUTHORIZED로 답합니다. 로그인은 되어 있지만 요금제가 그 페이지를 포함하지 않는다면, 필요한 등급을 쿼리 문자열에 담아 Upgrade 페이지로 리디렉션되며, 같은 상황의 API 요청은 402와 PAYMENT_REQUIRED, 그리고 기능 키로 답합니다. 실시간 채팅도 같은 방식으로 제한됩니다. preview 등급에서는 Support 페이지가 채팅 대신 업그레이드 안내를 보여줍니다. 운영자가 꺼둔 기능은 503과 KILL_SWITCH, 그리고 Retry-After 헤더로 답합니다.

잠김, 제한, 지연 — 고장이 아닌 것들

"이 요금제에는 포함되지 않음"을 뜻하는 시각 신호가 두 가지 있으며, 둘 다 오류가 아닙니다. 제한된 영역은 자물쇠 오버레이로 덮이는데, 이 오버레이는 마우스 클릭과 키보드 조작을 모두 가로채 아래의 링크 대신 업그레이드 대화상자를 엽니다. 일부만 보이는 데이터 위젯에는 대신 금색 인라인 알약 표시가 붙습니다. 데이터가 있긴 하지만 줄어든 경우, 예를 들어 지연된 시세나 제한된 과거 데이터 깊이에 쓰입니다. 차트에 기대보다 적은 봉이 표시되는데 이 표시가 붙어 있다면, 과거 데이터가 사라진 것이 아니라 의도적으로 짧아진 것입니다.

세 번째 현상은 타이밍으로 설명됩니다. 권한 정보가 로드될 때까지 제한 검사는 의도적으로 미결 상태로 남습니다. 그동안에는 숨겨져 있고 동작하지 않으므로, 유료 사용자가 잠금이 풀리기 전에 잠긴 상태를 잠깐 보는 일이 없습니다. 눈에 보이는 결과는 페이지를 불러온 직후 제한된 타일이 잠시 비어 있을 수 있다는 것입니다. 서버에서는 같은 정책이 API 요청에 402와 함께 기능 키와 필요한 등급을 담은 데이터로 답하고, 브라우저 이동은 출처와 원래 경로, 필요한 등급을 쿼리 문자열에 담아 Upgrade 페이지로 리디렉션합니다. 그래서 Upgrade 페이지가 무엇을 열려고 했는지 정확히 알려줄 수 있습니다.

API 응답에 담기는 오류 코드

앱 자체 API의 모든 응답은 정해진 형태를 가집니다. 성공에는 success: true와 data 페이로드, 타임스탬프가 담깁니다. 실패에는 success: false와 함께 기계가 읽는 code, 사람이 읽는 message, 그리고 선택적으로 문제가 된 필드를 가리키는 target, 추가 맥락을 담은 details 객체, doc_url을 가진 error 객체가 담깁니다. 문제를 신고할 때는 code를 인용해 주세요. 코드는 안정적이지만 메시지 문구는 그렇지 않습니다. 코드는 열두 개가 있으며 각각 하나의 HTTP 상태와 연결되어 있습니다.

이 집합 밖에 있는 응답 형태가 두 가지 있습니다. 오래된 엔드포인트는 code, msg, data, success로 이루어진 기존 방식의 봉투로 답하며, 여기서 code는 부류별로 묶인 숫자 문자열입니다. 10xxx는 입력 문제, 20xxx는 인증, 30xxx는 권한, 40xxx는 리소스 부재나 충돌, 50xxx는 서버 오류, 60xxx는 상위 서비스입니다. 데이터베이스 문제는 사용자에게 닿기 전에 변환됩니다. 연결이 끊기면 "Database temporarily unavailable"과 함께 503이 되고, 제한 시간을 넘긴 조회는 "Request timed out"과 함께 504가 되며, 중복은 409, 제약 조건 위반은 400이 됩니다. 앞의 둘은 재시도해 볼 만하고, 뒤의 둘은 입력이 바뀌기 전까지 계속 반복됩니다.

• BAD_REQUEST — 400. 요청 형식이 잘못되었습니다. 보낸 파라미터를 확인하세요.
• VALIDATION_ERROR — 400. 입력 하나가 검증을 통과하지 못했으며, 응답의 target이 그것을 알려줍니다.
• UNAUTHORIZED — 401. 유효한 세션이 없습니다. 로그인한 뒤 요청을 다시 보내세요.
• PAYMENT_REQUIRED — 402. 로그인은 되어 있지만 요금제가 이를 포함하지 않습니다. details에 featureKey와 requiredTier가 담기며, 도메인 제한인 경우 requiredDomain도 담깁니다.
• FORBIDDEN — 403. 인증은 되었지만 허용되지 않았습니다. 정확한 사유는 의도적으로 서버에만 남습니다.
• NOT_FOUND — 404. 그 주소에 해당하는 리소스가 없습니다.
• CONFLICT — 409. 그사이 리소스가 바뀌었거나 이미 존재합니다. 새로 고친 뒤 다시 시도하세요.
• PAYLOAD_TOO_LARGE — 413. 요청 본문이 허용 크기를 초과했습니다.
• RATE_LIMITED — 429. 요청이 너무 많습니다. 응답에 Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining이 실립니다. AI 엔드포인트는 별도의 예산을 가지며 AI_RATE_LIMITED라는 별개의 코드로 답합니다.
• INTERNAL_ERROR — 500. 예기치 못한 서버 오류입니다. Error ID와 함께 신고해 주세요.
• UPSTREAM_ERROR — 502. 이 엔드포인트가 의존하는 서비스가 실패했습니다. 나중에 다시 시도하세요.
• SERVICE_UNAVAILABLE — 503. 일시적으로 이용할 수 없습니다. 의도적으로 꺼둔 기능은 아래에 설명한 다른 형태의 503 본문을 사용한다는 점에 유의하세요.

kill switch: 누가 기능을 끄고, 얼마나 오래 꺼두는가

kill switch(차단 스위치)는 이름이 붙은 기능 하나를 끄는 스위치이며, 사용자가 아니라 Athenum 팀이 조작합니다. 앱의 나머지가 멀쩡한데도 어떤 페이지에 닿을 수 없는 이유가 바로 이것입니다. 서로 다른 두 상황이 같은 503을 만들어냅니다. 백엔드가 아직 출시되지 않아 기능이 꺼져 있다면 오류 페이지에 "Coming Soon"이 표시되며 개발 중이라고 설명합니다. 운영자가 잘 동작하던 기능을 껐다면 "Temporarily Unavailable"이 표시됩니다. 두 응답 모두 code KILL_SWITCH와 funding-heatmap이나 cme-detector 같은 안정적인 공개 기능 이름으로 자신을 밝힙니다.

응답은 얼마나 기다려야 하는지도 알려줍니다. 스위치마다 자체 Retry-After 값이 있습니다. Funding Heatmap은 60초, CME Detector는 1800초, 별도 설정이 없는 경우는 300초입니다. API 호출자는 같은 정보를 application/problem+json으로 받으며, 여기에는 아직 만들어지지 않은 경우와 운영자가 끈 경우를 구분해 주는 defaultKilled 플래그도 포함됩니다. 503 자체는 결코 캐시되지 않고, 스위치가 걸릴 수 있는 엔드포인트의 성공 응답도 캐시가 10초로 제한되므로 스위치 변경이 빠르게 전달됩니다. 다만 공유 캐시는 변경 후 약 15초 동안 이전 응답을 계속 내보낼 수 있습니다.

꺼진 경로는 보통 클릭으로는 닿을 수 없습니다. 스위치가 완전히 막은 경로는 홈 카드에서 걸러지고 커맨드 팔레트에서도 숨겨지므로, 503은 대개 북마크나 직접 링크, API를 쓰는 사람만 보게 됩니다. 모든 스위치가 경로를 막는 것은 아닙니다. 일부는 대신 동작만 바꾸는데, 그래서 어떤 페이지도 503을 반환하지 않는데 기능이 영향을 받을 수 있습니다. kill switch 페이지에는 Error ID가 없습니다. 이 응답은 사고가 아니라 의도적인 결정이며, 빈칸을 채우려고 식별자를 지어내지 않기 때문입니다.

사이트 전체 점검과 기능 하나의 장애

예정된 점검 시간은 다른 모든 장애와 다르게 보입니다. 평소의 오류 페이지 대신 "We'll be back soon"이라는 제목의 독립된 문서가 표시되며, 내비게이션도 Error ID도 지원 링크도 없습니다. HTTP 503과 1시간짜리 Retry-After와 함께 제공됩니다. 이 페이지는 완전히 자족적입니다. 스타일과 로고가 내장되어 있고 네트워크 호출을 하지 않으므로, 백엔드와 데이터베이스, 분석 도구가 모두 닿지 않는 상황에서도 표시됩니다. 또한 색인 대상에서 제외되도록 표시되어 있어 검색 엔진이 이 장애를 일시적인 것으로 취급합니다.

이 차단은 의도적으로 좁게 적용됩니다. 브라우저의 페이지 요청, 즉 HTML을 요구하는 GET이나 HEAD 요청만 대체합니다. /api/ 아래의 API 호출은 그대로 통과하며, 컨테이너 상태 점검 엔드포인트와 스크립트, 스타일, 폰트 요청도 마찬가지입니다. 알아둘 만한 결과가 있습니다. 점검 중에도 API 클라이언트나 내장 연동은 정상적으로 계속 동작할 수 있으며, 그동안 브라우저에는 점검 페이지가 보입니다. "We'll be back soon"이 보인다면 사이트 전체가 영향을 받은 것이고, 특정 기능 이름이 적힌 503 오류 페이지가 보인다면 그 기능만 영향을 받은 것입니다.

빈 패널 읽기: 배지가 장애의 이름을 알려줍니다

매크로 페이지의 패널에는 모서리에 작은 배지가 있으며, 이 배지가 장애와 조용한 데이터 출처를 구분하는 가장 빠른 방법입니다. 배지 상태 중 다섯 가지는 실제 데이터를 설명하고, 두 가지는 패널 자체를 설명합니다. 배지는 패널이 그림을 그릴 때 쓰는 것과 같은 신선도 규칙에서 나오므로, 데이터가 뒷받침하지 않는 상태를 주장할 수 없습니다. 보여줄 것이 없는 패널이 STALE로 표시되는 일은 결코 없고, 빠진 값이 대체 숫자로 채워지는 일도 없습니다.

패널 수준의 껍데기는 두 번째 층의 정보를 더합니다. 첫 로드가 진행 중이면 판정도 문구도 없는 뼈대가 표시됩니다. 전송 단계에서 실패한 조회는 "Fleet read failed — the source may still be live. Retry to reload."라는 문구와 재시도 버튼이 있는 오류 카드를 표시합니다. 원본 데이터는 멀쩡할 가능성이 크며, 이때는 재시도가 올바른 대응입니다. 조회는 성공했지만 아무 행도 돌아오지 않으면 UNAVAILABLE 배지와 함께 "Awaiting Fleet-Bridge"가 표시됩니다. 이 둘은 비슷해 보이지만 정반대를 뜻합니다. 앞의 것은 재시도할 수 있는 연결 문제이고, 뒤의 것은 해당 계열이 아직 흘러오기 시작하지 않았다는 뜻입니다.

TradeFI 패널은 배지 대신 사유를 문장으로 알려줍니다. 데이터 제공처가 실패했다면 데이터를 일시적으로 이용할 수 없다고 표시합니다. 제공처가 아무것도 응답하지 않았다면 그 종목에 대한 데이터가 없다고 표시합니다. 기관 보유 현황에는 세 번째 경우가 더 있습니다. 이 화면이 공식적으로 추적되는 기관의 부분집합이며 전수 조사가 아니라 대표성을 갖는 자료라는 안내입니다. 이는 장애가 아니라 범위에 대한 설명입니다. 동종 기업 목록도 같은 방식으로 동작하며, 기본이 아닌 출처를 사용한 경우 패널 위의 안내에 그 출처를 밝힙니다.

• LIVE — 예상된 주기 안에 들어온 장중 또는 실시간 관측치.
• EOD — 일간, 주간, 월간, 분기 계열의 정직한 기간 마감값.
• STALE — 실제 값이지만 해당 계열의 예상 갱신 주기보다 오래된 값.
• FALLBACK — 마지막으로 정상이었던 캐시 데이터이며, 명시적으로 현재 값이 아닙니다.
• MODEL — 직접 관측이 아니라 계산된 추정값이거나 Athenum이 구성한 값.
• UNAVAILABLE — 패널이 오류 상태이며 아무것도 그려지지 않았습니다.
• LOADING — 첫 로드가 아직 진행 중이며 신선도가 아직 정해지지 않았습니다.

문제 신고하기: Error ID

요청이 실패하면 오류 페이지에 HTTP 상태와 짧은 제목, 그리고 생성된 경우에 한해 Error ID가 표시됩니다. 이 식별자는 사용자의 개별 사고마다 새로 발급되어 기록된 오류 보고서에 붙으므로, 지원팀이 정확히 그 사례를 찾을 수 있습니다. 옆의 복사 버튼을 누른 뒤 “Support와 채팅”을 선택하세요. 링크가 Error ID를 Support 페이지까지 함께 전달합니다. 신고할 때는 Error ID와 페이지 주소, 그리고 무엇을 하던 중이었는지를 함께 알려주세요. 모든 오류에 이 값이 있는 것은 아닙니다. 일시적으로 꺼둔 기능에는 대체 값을 지어내지 않으므로 해당 항목이 아예 없습니다.

복사한 Error ID는 어디로 가는가

오류 페이지의 식별자는 실패가 포착된 순간 서버에서 사고당 한 번 발급됩니다. 서버는 그 식별자와 함께 HTTP 상태, 오류 이름, 요청 경로, 요청 방식, 타임스탬프를 담은 로그를 기록하며, 운영 환경에서는 스택 추적과 내부 세부 정보를 의도적으로 생략합니다. 같은 식별자가 오류 추적 시스템으로 보내지는 사고에도 붙으므로, 지원팀이 사용자가 복사한 id와 기록된 실패를 연결할 수 있습니다. 단순히 존재하지 않는 페이지에 닿은 요청은 예외입니다. 이 경우에도 식별자는 발급되지만 오류 추적으로는 전달되지 않습니다.

브라우저가 돌려받는 내용은 의도적으로 얇습니다. 일반적인 메시지와 식별자뿐이므로 내부 세부 정보가 페이지를 통해 새어 나가지 않습니다. "Support와 채팅"을 누르면 식별자가 그대로 이어집니다. 이 링크는 실패한 페이지에서 채팅 위젯을 띄우는 대신, 사고 주제와 Error ID, 채팅 요청을 담아 Support 페이지를 엽니다. 복사 버튼을 눌러도 아무 일이 없어 보인다면 클립보드 쓰기가 거부된 것입니다. 안전하지 않은 출처이거나 클립보드 권한이 거부된 경우에 생기며, 실패는 브라우저 콘솔에 기록됩니다. 그럴 때는 식별자를 직접 선택해 복사하세요.

Support 페이지에서 실시간 채팅을 실제로 쓸 수 있는지는 페이지가 그려지기 전에 이루어지는 세 가지 확인에 달려 있습니다. 채팅에는 유료 요금제가 필요합니다. preview 등급에서는 그 자리에 업그레이드 안내가 표시됩니다. 또한 지원 메신저 스위치가 꺼져 있는 동안, 그리고 아직 기록되지 않은 동의가 필요한 요청에 대해서도 채팅은 제공되지 않습니다. 후자는 유럽, 영국, 스위스로 보이는 요청과, 국가 정보가 전혀 없는 요청에 해당합니다. 이 확인은 불확실하면 막는 쪽으로 동작하기 때문입니다. 이 모든 경우에도 페이지는 이메일과 Discord 커뮤니티를 계속 제공하며, 이 둘은 요금제와 무관하게 항상 있습니다.

문제를 신고하기 전에 확인할 것

지원팀이 물어볼 내용의 대부분은 이미 화면에 보입니다. 아래 확인 사항은 1분도 걸리지 않으며, "고장 났어요"를 실제로 조치할 수 있는 신고로 바꿔 줍니다. 바깥에서 안쪽으로, 즉 사이트 전체에서 페이지로, 다시 패널로 좁혀 가세요. 각 층은 담당자도 해결 방법도 다르기 때문입니다. 개발자 도구가 필요한 항목은 그렇다고 명시한 두 가지뿐입니다.

• 범위를 확인하세요. 모든 페이지가 영향을 받나요, 한 페이지인가요, 아니면 잘 동작하는 페이지 안의 패널 하나인가요? "We'll be back soon"은 사이트 전체를 뜻하고, 특정 기능 이름이 적힌 503 페이지는 그 기능만을 뜻합니다.
• 문구를 그대로 읽으세요. "Coming Soon"과 "Temporarily Unavailable"은 둘 다 503이지만 서로 다른 상황이며, 패널 문구 "Fleet read failed"와 "Awaiting Fleet-Bridge"는 정반대를 뜻합니다.
• 배지를 찾아보세요. LOADING, STALE, FALLBACK, UNAVAILABLE은 각각 다른 상태를 나타내며, 자물쇠나 금색 알약 표시는 장애가 아니라 요금제 제한을 뜻합니다.
• 기다린 뒤 한 번 다시 시도하세요. 일시적인 응답은 Retry-After 헤더에 스스로 재시도 시점을 알려주며, 이는 브라우저의 네트워크 패널에서 볼 수 있습니다. 그보다 일찍 다시 시도하면 대개 같은 답이 돌아옵니다.
• 차트가 비어 있다면 브라우저 콘솔을 열어 [WebGLChart] 접두사가 붙은 줄을 찾은 뒤, 브라우저가 최신인지와 하드웨어 가속이 켜져 있는지 확인하세요.
• Error ID가 표시되어 있다면 복사하세요. 복사 버튼이 동작하지 않으면 직접 선택하세요. 브라우저가 클립보드 쓰기를 거부할 수 있습니다.
• 페이지 주소와 시각, 그리고 실패 직전에 무엇을 했는지 적어 두세요. Error ID는 사고를 식별하고, 이 세 가지는 무엇을 하려 했는지를 식별합니다.

수집기 오류 코드

선물 데이터 수집기는 모든 실패에 안정적인 코드를 붙이며, 이 코드는 오류 문구가 표시되거나 기록되는 곳마다 대괄호 안에 나타납니다. 이는 백엔드 식별자입니다. 지원 답변이나 상태 안내에서 이 코드를 보게 되면 어느 단계가 실패했는지, 그리고 수집기가 재시도했는지, 다른 출처로 대체했는지, 아니면 포기했는지를 알 수 있습니다.

Volume Delta 오류 코드

Volume Delta 엔드포인트는 VDLT_로 시작하는 코드와 힌트를 반환합니다. 재시도 가능한 오류는 일시적인 것으로, 같은 요청이 잠시 뒤에 성공할 수 있습니다. 그 밖의 오류는 요청 자체를 바꿔야 합니다.

그래도 해결되지 않는다면

앱 안에서 Support에 문의해 주세요. 공개된 서비스 수준 목표나 가동률 수치, 보장된 응답 시간이 없으므로 이 페이지도 그런 내용을 제시하지 않습니다.