이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
블록체인 노드 모니터링에서 가장 중요하게 추적한 지표는 블록 높이와 피어 수였습니다. 블록 높이가 멈추거나 다른 노드와 차이가 벌어지면 네트워크 동기화 오류를 의심할 수 있기 때문에, Prometheus 익스포터로 해당 값을 수집하고 Grafana 대시보드에 시각화했습니다.
피어 수가 급감하는 경우는 방화벽 규칙 변경이나 ISP 단에서의 포트 차단이 원인인 경우가 많았습니다. 이를 탐지하기 위해 피어 수 임계치를 설정하고 Slack 채널로 알림이 오도록 연결했습니다. 덕분에 이슈를 노드 로그를 직접 보기 전에 먼저 파악할 수 있었습니다.
정기적인 RPC 응답 시간 체크도 운영에 포함했습니다. 응답이 느려지면 노드 자체 부하인지, 네트워크 혼잡인지 구분해서 확인하는 절차를 팀과 공유했습니다. 운영 이슈의 대부분은 로그보다 메트릭이 먼저 신호를 보냈습니다.
노드 운영 중 블록 높이가 멈추는 알람이 새벽에 들어온 적이 있습니다. Grafana 대시보드를 확인하니 블록 높이는 고정됐고 피어 수도 1개로 줄어 있었습니다. 서버 재시작 후 방화벽 규칙이 초기화되면서 P2P 포트가 닫힌 것이 원인이었습니다. Prometheus의 피어 수 지표가 임계값(최소 5개) 이하로 떨어지자 Slack 알람이 왔고, 덕분에 블록 처리 지연이 서비스 장애로 이어지기 전에 포트를 복구했습니다. 이후 방화벽 규칙을 IaC로 코드화해 재시작 시 자동으로 적용되도록 했고, 노드 이중화 구성을 도입해 하나가 고립돼도 다른 노드가 계속 동기화되도록 했습니다. 지표가 없었다면 아침에야 발견했을 이슈를 새벽에 잡을 수 있었던 경험이었습니다.
블록체인 노드를 운영하면서 가장 예상 밖이었던 것은 체인 데이터 증가 속도였습니다. 초기엔 200GB로 충분했던 디스크가 3개월 만에 90% 이상 차면서 노드가 불안정해지는 상황이 생겼습니다. Prometheus로 디스크 사용률을 추적하고 있었지만 임계값 알람을 80%로 설정해두지 않아 경고를 놓쳤습니다. 이후 디스크 사용률 알람을 80%로 낮추고, 체인 데이터 크기 증가 속도를 별도 지표로 추가해 3개월 후 포화 예상 시점을 계산하는 방식으로 바꿨습니다.
프루닝(Pruning) 모드를 활용해 불필요한 과거 상태를 정리하고 디스크 점유를 줄였습니다. 노드 운영에서 용량 계획은 현재 상태가 아니라 증가 속도를 보는 것이라는 감각을 이 경험에서 얻었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 코빗 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.