이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
자산관리 및 정산 도메인을 처음 접한 것은 핀테크 스터디에서였습니다. 기술 로드맵 수립을 위해 먼저 도메인의 핵심 흐름을 파악하는 것부터 시작했습니다. 자산 변동 이력의 정합성 유지, 실시간 잔고 계산, 정산 주기별 집계가 핵심 요구사항이라는 것을 공부했습니다.
이중 원장 방식으로 잔고 데이터를 관리하면 오류 발생 시 추적과 롤백이 쉽다는 원리를 이해했고, 이를 기반으로 스터디 프로젝트에서 간단한 정산 모듈을 구현해봤습니다. 이벤트 소싱 패턴을 적용해 모든 잔고 변동을 이벤트 로그로 기록하니, 특정 시점의 잔고를 재계산하는 것이 가능해졌습니다.
기술 로드맵은 도메인 이해를 먼저 충분히 쌓은 뒤 기술을 선택하는 순서가 중요하다고 생각합니다. 자산관리 시스템은 정확성이 기능보다 우선되는 도메인이라는 결을 공부하며 얻었습니다.
자산관리 스터디 프로젝트에서 배치 기반 정산 모듈을 이벤트 기반으로 전환하는 실험을 했습니다. 기존 배치 방식은 자산 변동이 발생해도 다음 배치 실행 시점까지 잔고 반영이 지연됐는데, 이벤트 소싱 패턴을 적용해 변동 즉시 이벤트를 기록하고 잔고를 재계산하는 구조로 바꿨습니다.
변환 전후 차이는 잔고 반영 지연 시간으로 비교했습니다. 배치 방식에서는 최대 1시간 지연이 발생했는데, 이벤트 기반으로 전환 후 평균 반영 지연이 3초 이내로 줄었습니다. 이중 원장 구조 덕분에 이벤트 로그와 현재 잔고를 대조하는 검증 쿼리를 추가할 수 있었고, 정합성 오류 발생 시 어느 이벤트에서 불일치가 시작됐는지 추적하는 것도 가능해졌습니다.
수치로 개선을 확인하기 전까지는 이벤트 기반 방식이 정말 나은지 확신하기 어려웠습니다. 지연 시간을 측정 기준으로 삼으니 설계 결정을 근거 있게 설명할 수 있는 자리가 생겼습니다.
정산 도메인을 공부하면서 가장 인상 깊었던 것은 대사 절차였습니다. 내부 원장 잔고와 외부 정산 결과를 매일 대조해서 불일치를 찾는 작업이 수동으로 이뤄지면 누락이 생긴다는 것을 스터디에서 배웠고, 자동화 스크립트를 직접 만들어봤습니다.
T+1 기준으로 전일 거래 내역과 정산 결과를 비교해서 불일치 행을 추출하는 스크립트를 파이썬으로 작성했습니다. 처음에는 단순 집계로 시작했는데, 같은 금액이지만 시점이 다른 케이스, 수수료가 분리된 케이스 등이 각각 다른 처리가 필요해서 대사 로직이 생각보다 복잡하다는 것을 알게 됐습니다.
이 경험에서 정산 도메인의 기술 로드맵이 단순히 기술 스택을 배우는 것이 아니라, 업무 규칙을 코드로 정확하게 표현하는 것임을 처음으로 실감했습니다. 도메인 지식 없이는 올바른 기술 선택도 어렵다는 생각이 이 경험에서 자리 잡혔습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.