이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 세금계산서 발행 모듈을 담당했는데, 부가세 계산 방식이 공급가액 기준인지 공급대가 기준인지를 잘못 이해해서 발행된 계산서 금액이 실제와 달라지는 오류가 납품 전날 발견됐습니다. 혼자 로직을 짜면서 회계 담당자에게 확인하는 단계를 건너뛴 게 원인이었습니다.
긴급하게 세무 담당자와 함께 요구사항을 재검토하면서 로직을 수정했습니다. 그 경험 이후로 재무 도메인 기능은 코드 작성 전 도메인 전문가와 꼭 요구사항을 구두로 확인하는 단계를 먼저 넣게 됐습니다.
이후엔 계산 결과에 대한 단위 테스트를 경계 케이스 기준으로 작성하는 습관도 생겼습니다. 금액이 0원일 때, 소수점이 생길 때, 면세 항목이 섞일 때 등. 회계 로직은 테스트가 명세 역할을 한다는 것이 그때 배운 가장 중요한 교훈입니다.
사이드 프로젝트로 소규모 쇼핑몰의 월말 정산 기능을 이어받았습니다. 코드는 돌아가고 있었지만 특정 월에 윤달이 끼거나 주문이 월을 넘어갈 때 집계 누락이 발생하는 버그가 있었습니다. 처음엔 이유를 몰랐습니다.
날짜 범위 쿼리가 `BETWEEN` 문자열 비교로 작성돼 있어서, 타임존 설정과 맞물려 경계 날짜 데이터가 제외됐습니다. >=와 < 범위 쿼리로 바꾸고 UTC 기준으로 통일하니 누락이 사라졌습니다.
그 버그가 6개월간 조용히 살아있었다는 사실이 충격이었습니다. 이후 정기적으로 합산 결과를 외부 장부와 대조하는 자동화 검증 스크립트를 추가했습니다. 재무 시스템은 오류가 조용히 누적되는 성격이라, 주기적인 자동 대조 없이는 버그를 늦게 발견할 수밖에 없다는 걸 배웠습니다.
팀 프로젝트에서 급여 명세서 생성 기능을 맡았는데, 재무팀과 개발팀이 같은 단어를 다르게 이해하는 문제가 생겼습니다. '공제액'이 세전 공제인지 세후 공제인지에 대한 인식이 달라 만들고 나서야 요구사항이 틀렸다는 걸 발견했습니다.
재작업 비용이 컸고, 팀에 이 문제를 공유하면서 용어 사전 문서를 만들자고 제안했습니다. 재무팀 실무자와 같이 30분짜리 세션을 두 번 진행해서 주요 용어 12개의 정확한 의미를 확인하고 문서화했습니다. 이후 같은 종류의 오해는 완전히 사라졌습니다.
실패 경험에서 얻은 것은 도메인 특화 시스템은 코드 리뷰 이전에 도메인 리뷰가 있어야 한다는 것입니다. 개발자끼리 로직을 검토해도 도메인 요구사항이 틀리면 의미가 없다는 걸 그때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 재무·회계 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.