이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
정합성 검증은 실시간과 배치를 목적에 따라 나눠 사용했습니다. 실시간 검증은 트랜잭션 직후 핵심 조건이 충족되는지 확인하는 데 적합했고, 배치 검증은 전체 데이터를 일괄 비교해 누락이나 불일치를 찾는 데 활용했습니다.
실시간 검증에서는 이벤트 발생 시 연관 테이블 상태를 함께 체크하는 트리거 로직을 적용했습니다. 빠르게 오류를 감지할 수 있지만, 검증 로직이 과도하면 트랜잭션 성능에 영향을 줄 수 있어 핵심 조건만 포함했습니다.
야간 배치에서는 두 시스템 간 집계 수치를 비교하는 스크립트를 작성했습니다. 불일치 행을 JSONL 파일로 기록해 다음 영업일 아침에 확인하도록 했고, 반복 오류 패턴을 분석해 근본 원인을 추적하는 데 유용했습니다.
실시간 데이터 파이프라인에서 정합성 검증 실패 레코드를 어떻게 처리할지가 설계 과제였습니다. 검증 실패 레코드를 단순히 버리면 데이터 유실이 생기고, 재시도하면 파이프라인이 멈추는 결이 있었습니다. Dead Letter Queue(DLQ)를 별도로 두어, 검증에 실패한 레코드를 정상 흐름에서 격리하는 방식을 만들었습니다. DLQ에 쌓인 레코드는 수동 검토 후 수정해서 재처리 큐에 넣거나 버리는 두 경로로 처리했습니다. 이 방식 덕분에 오류 레코드가 전체 파이프라인을 멈추지 않으면서도 유실 없이 추후 처리할 수 있는 구조가 됐습니다.
정합성 오류는 막는 것뿐 아니라 발생했을 때 어떻게 격리하고 복구하는지 설계하는 것이 더 중요한 결이라는 것을 이 경험에서 배웠습니다.
배치 정합성 검증에서 소스 시스템과 타겟 데이터베이스 간 집계값 불일치를 발견하는 과정을 경험했습니다. 전날의 모든 레코드를 소스와 타겟에서 각각 집계해 비교하는 Data Reconciliation 스크립트를 만들었습니다. 행 수는 맞는데 합계가 다른 케이스도 있었는데, 특정 레코드의 값이 변경됐지만 타겟에 동기화되지 않은 것이었습니다. 불일치 레코드를 JSONL로 기록하고, 어떤 ID의 어떤 필드가 다른지를 명시하는 방식으로 원인 추적을 쉽게 만들었습니다.
배치 정합성 검증은 실시간 모니터링이 놓친 것을 잡아주는 안전망의 결이 있다는 것을 이 경험에서 배웠습니다. 두 방식을 함께 운영하는 것이 단일 방식보다 신뢰도 높은 결이 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.