이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 포트폴리오 잔고 실시간 계산 모듈을 만들면서 이 도메인의 어려움을 처음 경험했습니다. 잔고는 단순 합산처럼 보이지만, 동시 거래 요청이 들어올 때 처리 순서에 따라 결과가 달라지는 문제를 직접 맞닥뜨렸습니다. 이벤트 소싱 방식으로 바꿔서 각 거래 이벤트를 시간 순으로 쌓고 재계산하는 구조를 만드니 데이터 일관성이 확보됐습니다. 리스크 산출에서는 변동성이 큰 자산의 노출 비중을 실시간으로 추적하는 부분이 가장 까다로웠습니다. 캐시를 적극 활용했는데, 캐시가 오래됐을 때 오히려 잘못된 리스크 수치를 보여줄 수 있다는 점도 경험했습니다. 실시간 산출은 정확성과 지연 시간이 동시에 요구되는 자리라, 두 목표가 충돌할 때 설계 초반에 우선순위를 결정하는 것이 중요하다는 걸 배웠습니다. 작은 규모였지만 금융 도메인 특유의 정합성 감각을 그때 처음 길렀습니다.
인턴 프로젝트에서 잔고 차감 로직을 처음 구현했을 때, 동시 요청이 들어오면 잔고가 음수로 빠지는 문제가 생겼습니다. Redis 분산락을 처음 도입하면서 락 범위를 너무 넓게 잡아 처리량이 절반으로 줄었고, 좁히면 경합이 다시 생겼습니다. 결국 와 를 조합해 원자 연산 단계에서 잔고 하한을 검사하도록 바꿨더니, 분산락 없이도 이중 차감을 막을 수 있었습니다. 락을 쓰는 것보다 DB와 캐시 연산 자체를 원자적으로 만드는 편이 처리량 면에서 유리하다는 걸 이 경험으로 처음 알게 됐습니다.
p99 레이턴시가 기존 대비 40% 줄었고, 팀원과 함께 적재 부하 테스트 시나리오를 만들어 검증했습니다. 지금도 잔고처럼 정합성이 중요한 데이터는 연산 원자성을 먼저 검토하는 편입니다.
학부 프로젝트에서 간단한 포인트 차감 기능을 만들었는데, 배포 후 포인트가 두 번 차감되는 신고가 들어왔습니다. 처음에는 클라이언트 중복 요청 문제라고 봤지만, 서버 로그를 들여다보니 트랜잭션 경계가 틀린 게 원인이었습니다. 을 서비스 메서드에 붙였는데도 롤백이 안 된 이유는, 로 예외를 잡아 삼켜버렸기 때문이었습니다. Spring은 예외가 메서드 밖으로 전파돼야 롤백을 트리거하는데, 내부에서 처리하면 정상 종료로 인식한다는 걸 공식 문서에서 확인했습니다. 버그를 수정하는 데 이틀이 걸렸고, 이후 트랜잭션 범위를 쓸 때 예외 전파 경로를 먼저 그려보는 습관이 생겼습니다. 금전 관련 로직을 건드릴 때는 롤백 조건을 코드 리뷰에서 반드시 확인하자고 팀원과 약속했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.