우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›토스›백엔드›질문 상세
    問
    토토스백엔드직무 역량2026년 출제

    정산 시스템을 구축할 때, 오차 없이 빠르게 계산할 수 있도록 하기 위한 기술적 고려사항은 무엇인가요?

    답변 미리보기

    팀 프로젝트에서 수수료 정산 기능을 만들 때, 소수점 반올림 방식을 신경 쓰지 않았다가 하루 전체 정산 금액이 7원 차이나는 오류가 생겼습니다. 소액이었지만…

    예상 답변 시간
    60~90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    기술적 고려사항은 무엇인가?
    정산 시스템 구축 시 고려한 기술적 요소의 흔적이 답에 있어야 합니다. 없으면 면접관이 '어떤 기술을 사용할 수 있습니까?'를 추가로 묻는 경우가 자주 보입니다.
    骨
    02
    오차를 줄이기 위한 방법은?
    정산 과정에서 오차를 줄이기 위한 방법에 대한 설명이 답에 있어야 합니다. 없으면 면접관이 '구체적으로 어떤 방안을 생각했나요?'를 추가로 묻는 경우가 흔하게 통합니다.
    語
    03
    빠른 계산을 위한 접근법은?
    빠른 계산을 위한 접근법에 대한 언급이 답에 있어야 합니다. 없으면 면접관이 '어떤 최적화 방법을 고려했나요?'를 추가로 묻는 자리가 자주 보입니다.
    本
    04
    시스템 안정성을 어떻게 보장할 것인가?
    시스템의 안정성을 보장하기 위한 대책의 흔적이 답에 있어야 합니다. 없으면 면접관이 '위험 요소를 어떻게 관리할 것인가요?'를 추가로 묻는 경우가 많습니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    토스 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    부동소수점 오차로 정산 불일치가 난 실패 경험과 해결 과정 중심약 90초야간 배치 정산이 새벽 마감 시간을 넘긴 실패 경험과 개선 과정약 90초정산 중복 처리 실패 경험과 멱등성 보장 설계를 배운 과정 중심약 90초
    소수점 오차와 트랜잭션 경험
    약 90초

    부동소수점 오차로 정산 불일치가 난 실패 경험과 해결 과정 중심

    팀 프로젝트에서 수수료 정산 기능을 만들 때, 소수점 반올림 방식을 신경 쓰지 않았다가 하루 전체 정산 금액이 7원 차이나는 오류가 생겼습니다. 소액이었지만 금융 로직에서 오차가 누적되는 게 얼마나 심각한지 처음 체감했습니다.

    원인은 Python의 `float` 타입을 그대로 쓴 것이었습니다. decimal.Decimal 로 교체하고 반올림 방식을 ROUND_HALF_UP으로 명시하니 오차가 사라졌습니다. 이 경험 이후 금액이 관여되는 모든 연산에서는 부동소수점을 쓰지 않는다는 원칙을 세웠습니다.

    트랜잭션 범위도 함께 정리했습니다. 정산 계산과 DB 저장이 별개 연산으로 분리돼 있어 중간에 실패하면 일부만 저장되는 문제가 있었습니다. 명시적인 트랜잭션으로 묶고 원자성을 보장하니 재실행 시 일관성이 유지됐습니다. 정산 시스템에서는 속도보다 정확성과 원자성이 먼저라는 걸 그때 배웠습니다.

    이 결의 특징
    팀 프로젝트에서 수수료 정산 기능을 만들 때, 소수점 반올림 방식을 신경 쓰지 않았다가 하루 전체 정산 금액이 7원 차이나는 오류가 생겼습니다. 소액이었지만 금융 로직에서 오차가 누적되는 게 얼마나 심각한지 처음 체감했습니다. 원인은 Python의 `float` 타입을 그대로 쓴 것이었습니다라는 흔적이 있습니다
    이 결이 통하는 자리
    `decimal. Decimal` 로 교체하고 반올림 방식을 `ROUND_HALF_UP`으로 명시하니 오차가 사라졌습니다. 트랜잭션 범위도 함께 정리했습니다. 정산 계산과 DB 저장이 별개 연산으로 분리돼 있어 중간에 실패하면 일부만 저장되는 자리에서 통합니다
    배치 정산 최적화 경험
    약 90초

    야간 배치 정산이 새벽 마감 시간을 넘긴 실패 경험과 개선 과정

    인턴 때 일간 정산 배치 작업이 데이터 증가로 매일 새벽 마감 시간을 30분씩 넘기기 시작했습니다. 처음엔 서버 사양 문제인 줄 알았는데, 실행 계획을 보니 복합 조인 쿼리에 인덱스가 없어 풀스캔을 하고 있었습니다.

    user_id + settled_at 복합 인덱스를 추가하니 쿼리 실행 시간이 42분에서 8분으로 줄었습니다. 하지만 그것만으로 충분하지 않아서, 월별 파티셔닝도 제안드렸는데 당시 팀에서는 즉시 적용이 어렵다고 하셔서 인덱스 개선까지만 반영됐습니다.

    그 경험에서 개선 제안이 항상 받아들여지진 않는다는 현실도 배웠습니다. 대신 현재 상황에서 적용 가능한 해결책을 먼저 완료하고, 더 큰 개선은 근거를 갖춰 다음 기회를 기다리는 방식을 그때부터 익혔습니다. 정산 시스템 성능은 데이터 설계에서 이미 상당 부분 결정된다는 것이 지금도 제 기준입니다.

    이 결의 특징
    인턴 때 일간 정산 배치 작업이 데이터 증가로 매일 새벽 마감 시간을 30분씩 넘기기 시작했습니다. 처음엔 서버 사양 문제인 줄 알았는데, 실행 계획을 보니 복합 조인 쿼리에 인덱스가 없어 풀스캔을 하고 있었습니다. `user_id + settled_at` 복합 인덱스를 추가하니 쿼리 실행 시간이 42분에서 8분으로 줄었습니다라는 흔적이 있습니다
    이 결이 통하는 자리
    `user_id + settled_at` 복합 인덱스를 추가하니 쿼리 실행 시간이 42분에서 8분으로 줄었습니다. 그 경험에서 개선 제안이 항상 받아들여지진 않는다는 현실도 배웠습니다. 대신 현재 상황에서 적용 가능한 해결책을 먼저 완료하고, 더 큰 개선은 근거를 갖춰는 자리에서 통합니다
    멱등성과 재처리 설계 경험
    약 90초

    정산 중복 처리 실패 경험과 멱등성 보장 설계를 배운 과정 중심

    졸업 프로젝트에서 포인트 정산 기능을 만들었는데, 네트워크 타임아웃 후 재시도 로직이 없어 동일 트랜잭션이 두 번 처리돼 포인트가 이중 지급되는 버그가 났습니다. 처음엔 단순 실수로 봤는데, 알고 보니 멱등성 설계를 아예 고려하지 않은 구조였습니다.

    각 정산 요청에 고유한 `idempotency_key`를 부여하고, DB에 처리 여부를 먼저 확인한 뒤 실행하도록 바꿨습니다. 동일 키가 이미 처리됐으면 이전 결과를 그대로 반환합니다. 재시도가 안전한 정산 시스템을 만드는 구조였습니다.

    이후 정산 결과를 별도 감사 테이블에 함께 기록하는 방식도 추가했습니다. 장애 후 어디서 멈췄는지 확인하고 안전하게 재실행할 수 있게 하기 위해서입니다. 금융 도메인에서는 '빠르게'보다 '다시 돌려도 안전하게'가 먼저라는 것이 그 경험이 남긴 기준입니다.

    이 결의 특징
    졸업 프로젝트에서 포인트 정산 기능을 만들었는데, 네트워크 타임아웃 후 재시도 로직이 없어 동일 트랜잭션이 두 번 처리돼 포인트가 이중 지급되는 버그가 났습니다. 처음엔 단순 실수로 봤는데, 알고 보니 멱등성 설계를 아예 고려하지 않은 구조였습니다라는 흔적이 있습니다
    이 결이 통하는 자리
    각 정산 요청에 고유한 `idempotency_key`를 부여하고, DB에 처리 여부를 먼저 확인한 뒤 실행하도록 바꿨습니다. 동일 키가 이미 처리됐으면 이전 결과를 그대로 반환합니다. 이후 정산 결과를 별도 감사 테이블에 함께 기록하는 방식도 추가했습니다. 장애 후 어디서 멈췄는지 확인하고 안전하게 재실행할 수 있게 하기는 자리에서 통합니다
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
    • ✕선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
    • ✕결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
    • ✕지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹정산 시스템에서 어떤 기술을 사용하실 건가요?
    貳이전 경험에서 어떤 문제를 겪었나요?
    參정산 시스템의 정확성을 어떻게 검증할 건가요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 토스 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    무신사 · 백엔드
    정산 시스템을 설계할 때 가장 중요하게 고려해야 할 요소는 무엇이라고 생각하나요?
    이 질문 보기
    무신사 · 백엔드
    정산 시스템을 개발할 때 가장 중요하게 고려해야 할 요소는 무엇이라고 생각하나요?
    이 질문 보기
    쿠팡 · 백엔드
    고가용성을 보장하는 분산 시스템을 구축할 때 가장 중요하게 고려해야 할 요소는 무엇인가요?
    이 질문 보기
    쿠팡 · 인프라/클라우드
    분산 시스템을 구축할 때 고려해야 할 주요 설계 원칙은 무엇인지 설명해보세요.
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 토스 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기