이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 논문 프로젝트에서 이더리움 노드와 통신하는 백엔드 서비스를 처음 만들었습니다. 처음에는 RPC 호출을 아무 검증 없이 넣었다가 노드가 일시적으로 응답하지 않는 경우에 서비스 전체가 멈추는 문제가 생겼습니다. 이후 재시도 로직에 지수 백오프를 적용하고 노드 연결 상태를 주기적으로 확인하는 헬스체크를 추가했습니다. 인증 쪽에서는 개인키로 트랜잭션 서명을 서버에서 직접 처리하는 방식이 키 노출 위험이 있어서, 서명 로직을 별도 모듈로 격리하고 환경 변수로만 키를 참조하도록 바꿨습니다. 이벤트 구독은 web3.js 필터를 썼는데, 연결이 끊기면 이벤트가 누락되는 경우가 있어 재구독 로직을 명시적으로 구현했습니다.
블록체인 노드 통신은 일반 API보다 실패 케이스가 많아 방어 코드를 더 꼼꼼히 설계해야 하는 자리라는 걸 그때 배웠습니다.
블록체인 노드와의 통신에서 효율을 높이기 위해 가장 먼저 신경 쓴 것은 HTTP 폴링을 줄이는 것이었습니다. 트랜잭션 상태를 확인하기 위해 매초 Receipt를 조회하던 방식을 WebSocket eth_subscribe로 이벤트를 구독하는 방식으로 바꾸자 노드 부하가 줄고 확인 지연도 줄었습니다. 또한 Nonce 관리가 잘못되면 트랜잭션이 대기 상태에 멈추는 문제(Stuck Transaction)가 생기는데, 트랜잭션을 동시에 여러 개 제출할 때 Nonce를 서버에서 순서대로 할당하는 큐를 만들어 충돌을 방지했습니다. 여러 RPC 호출을 배치로 묶어 한 번에 전송하는 방식도 도입해 왕복 요청 횟수를 줄였습니다. 노드 응답이 느린 피크 시간대에는 읽기 전용 조회 결과를 단기 캐시에 두어 반복 호출을 줄이는 것도 효과적이었습니다. 블록체인 통신은 일반 REST보다 상태 변화가 느려, 그 간격을 효율로 채우는 설계가 중요합니다.
블록체인 API 설계에서 가장 중요하게 생각하는 원칙은 노드에는 서명된 트랜잭션만 전달한다는 것입니다. Private Key를 API 서버에 두면 서버 침해 시 키가 노출되기 때문에, 서명 로직을 별도 Signing Service로 분리하고 API 서버는 미서명 트랜잭션을 Signing Service에 보내 서명받은 결과만 노드에 전달하도록 구성했습니다. 재시도 원칙도 일반 HTTP와 다른데, 블록체인 트랜잭션은 동일 Nonce로 재시도해야 중복 전송을 막을 수 있어 재시도 로직에 Nonce를 고정시키는 설계가 필요합니다. 이벤트 수신은 WebSocket 구독이 끊겼을 때 누락이 발생하므로, 구독과 동시에 마지막 확인 블록 번호부터 이벤트 로그를 재조회하는 복구 로직을 함께 설계했습니다. 블록체인 통신은 실패 시나리오가 다양해 원칙 하나하나가 실제 장애와 직결됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 카카오페이 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.