'1원도 안 틀려야 한다'는 세계
평범한 웹 서비스에서 숫자가 조금 틀리면 어떨까요? 좋아요 개수가 하나 어긋나는 정도면 아무도 안 죽어요. 그런데 그 숫자가 '돈'이라면 얘기가 완전히 달라지죠. 1원이라도 사라지거나 두 번 빠져나가면 그건 그냥 버그가 아니라 사고예요. 핀테크 엔지니어링 핸드북류의 자료들이 공통으로 강조하는 게 바로 이 '돈을 다루는 코드는 일반 코드와 다른 규율이 필요하다'는 점이에요.
토스, 카카오페이, 네이버페이처럼 한국에도 핀테크가 넘쳐나고 결제·정산 시스템을 만지는 개발자 수요도 많은데요. 막상 학교나 부트캠프에서는 잘 안 가르쳐주는 실무 지식이라, 한번 정리해 둘 만해요.
첫째, 돈은 절대 실수(float)로 다루지 마세요
초보가 가장 많이 하는 실수예요. 0.1 더하기 0.2를 컴퓨터에 시키면 0.3이 아니라 0.30000000000000004 같은 괴상한 값이 나와요. 이게 뭐냐면, 컴퓨터가 소수를 2진법으로 저장하는 방식 때문에 생기는 미세한 오차거든요. 평소엔 티가 안 나지만, 돈 계산을 수백만 번 반복하면 이 오차가 쌓여서 결국 장부가 안 맞아요.
그래서 핀테크에서는 돈을 소수가 아니라 '정수'로 다뤄요. 1,000원을 그냥 1000.0이라고 두지 않고 '가장 작은 단위의 정수'로 저장하거나, 오차가 없는 전용 십진(decimal) 타입을 쓰는 거죠. 이 원칙 하나만 지켜도 사고의 절반은 막아요.
둘째, 멱등성 - 두 번 눌러도 한 번만 빠지게
결제 버튼을 눌렀는데 화면이 멈췄어요. 그래서 다시 눌렀죠. 그런데 알고 보니 첫 번째 요청도 사실은 서버에 도착했던 거예요. 그럼 돈이 두 번 빠지나요? 이걸 막는 게 '멱등성(idempotency)'이에요. 어려운 말 같지만 뜻은 간단해요. '같은 요청을 몇 번을 보내도 결과는 딱 한 번 일어난 것과 같다'는 성질이죠.
실무에선 요청마다 고유한 '멱등성 키'를 붙여 보내요. 서버는 이 키를 보고 '아, 이건 아까 그 요청이네' 하고 중복 처리를 막는 거예요. 네트워크는 언제든 끊기고 자동으로 재시도되니까, 돈을 다루는 API라면 이건 선택이 아니라 필수예요.
셋째, 복식부기와 원장 - 돈의 흐름을 '기록'으로 본다
핀테크 시스템의 심장은 '원장(ledger)'이에요. 그냥 잔액 숫자 하나를 들고 있다가 더하고 빼는 게 아니라, 회계의 복식부기 원리를 그대로 가져와요. 모든 거래는 '어디서 빠져서 어디로 들어갔다'는 두 줄로 기록되고, 양쪽 합이 항상 맞아떨어져야 하죠.
그리고 이 기록은 '추가만 되고 절대 수정·삭제하지 않는(append-only)' 방식으로 쌓아요. 잔액은 이 기록들을 합산한 결과일 뿐이고요. 왜 이렇게 번거롭게 하냐면, 나중에 '이 돈이 왜 여기 있지?'를 끝까지 추적할 수 있어야 하고, 감사(audit)나 규제 대응에도 그 흐름의 증거가 필요하거든요.
넷째, 정산(reconciliation)이라는 마지막 안전망
아무리 코드를 잘 짜도 우리 시스템의 기록과 실제 은행·카드사의 기록이 어긋날 수 있어요. 그래서 매일 양쪽 장부를 대조해서 '우리가 100건 처리했다고 적었는데 카드사도 100건이 맞나?'를 확인하는 정산 작업을 돌려요. 여기서 차이가 발견되면 곧장 알람이 울리게 하고요. 이게 돈 사고를 조기에 잡아내는 마지막 그물이에요.
한국 개발자에게
결제·정산·송금 도메인은 한 번 경험을 쌓으면 이직 시장에서 꽤 강력한 무기가 돼요. 위 원칙들(정수로 돈 다루기, 멱등성, 원장, 정산)은 특정 회사의 기술이 아니라 업계 공통 상식에 가까워서, 미리 알아두면 면접에서도 실무에서도 바로 티가 나요. 결제 모듈을 처음 맡았을 때 이걸 모르고 float로 짰다가 식은땀 흘리는 일, 생각보다 흔하거든요.
한 줄 정리
핀테크 코드의 본질은 '화려한 기능'이 아니라 '1원도 안 틀리고, 두 번 안 빠지고, 모든 흐름을 추적 가능하게'라는 보수적인 규율이에요. 여러분은 돈을 다루는 코드를 짜본 적 있으세요? 가장 아찔했던 순간은 언제였나요?
🔗 출처: Hacker News