핀테크 엔지니어링 핸드북

commit history는 모든 변경을 author에 귀속하고, review와 linked ticket을 통해 이유와 연결함

signed commit, protected branch, shared history force-push 금지로 보호해야 함

review와 pipeline은 강제되어야 함

required review, status check, main branch direct push 금지가 중요함

deployment는 추적 가능해야 함

어떤 version이 실행 중인지, 누가 언제 release했는지 재구성 가능해야 incident를 원인 변경과 연결할 수 있음

테스트 전략

돈 시스템에서는 operation sequence 공간이 크고 흥미로운 실패가 조합에서 나오므로 테스트가 특히 중요함

Property-based testing은 특정 출력보다 어떤 입력에서도 성립해야 하는 property를 검증함

invariant와 money math에 잘 맞음

operation sequence를 생성할 때 마지막뿐 아니라 매 단계 뒤 invariant를 확인해야 함

수동으로 대규모 수행하기 어려우므로 assertion을 자동 주입하는 testing harness가 필요함

Generative idempotency testing은 외부 세계를 만지는 모든 operation이 두 번째 호출에서 영향이 없는지 검증함

Crash and resume injection은 long flow가 어떤 단계 사이에서 죽어도 살아나는지 검증함

Round-trip testing은 encode/decode, serialize/deserialize, convert/convert back 뒤 시작점으로 돌아오는지 또는 알려진 tolerance 안에 있는지 확인함

money와 currency type의 boundary 정밀도 손실과 serialization bug를 잡는 빠른 방법임

Golden testing은 fee breakdown, statement, report 같은 계산 결과를 저장된 기대 결과와 비교해 의도치 않은 diff를 드러냄

Backward-compatibility testing은 오래된 real-format payload corpus를 유지하고 현재 코드가 여전히 deserialize와 project를 올바르게 하는지 검증함

Production testing은 sandbox가 production과 크게 다를 때 필요할 수 있음

canary release, 작은 blast radius의 controlled rollout, 작은 실제 금액을 지속적으로 흐르게 하는 synthetic transaction이 예임

production test는 실제 돈을 움직이므로 ledger, reconciliation, audit trail을 똑같이 거쳐야 하며, 정상 correction/reversal 경로로 정리해야 함

도메인 용어와 참고 자료

핀테크 입문에서는 코드보다 vocabulary와 concept이 더 어려울 수 있어 핵심 용어를 별도로 정리함

회계와 ledger 영역에는 ledger, general ledger와 sub-ledger, debit/credit, posting, chart of accounts, receivable/payable, IOU, accrual vs cash basis, trial balance, suspense/clearing account, write-off, commingling, reconciliation break가 포함됨

Money와 FX 영역에는 Money type, minor units, basis point, notional, fiat vs crypto, stablecoin, pegged/wrapped/bridged, bid/ask/spread, mid-market rate, reference rate, mark-to-market가 포함됨

거래와 settlement 영역에는 value date, booking date, settlement date, T+X, clearing vs settlement, cut-off time, float, netting, backdating, reversal/correction이 포함됨

결제, 카드, 시장, crypto, compliance 용어도 별도로 정리됨

PSP, omnibus account, FBO account, chargeback, issuer/acquirer, authorization vs capture

order book, market vs limit order, maker/taker, slippage, liquidity, derivative, futures, perpetual, liquidation

custody, hot/cold wallet, private key, multisig, MPC, gas, confirmation/finality, reorg, UTXO vs account model

훑어봤는데, 이 핸드북은 얕고 일부 영역에서는 나쁜 조언에 가깝다고 봄
예를 들어 금액이 정수가 아닌 형태로 저장된 걸 보면 비명을 지르며 도망갈 것 같음. Rust의 decimal이 JSON 부동소수점으로 표현되는 경우 같은 것 때문임. 아주 강한 이유가 없는 한 항상 정수여야 하고, 내보내는 뷰는 이상한 비트코딩 형식이든 뭐든 가능함
외환 환율도 특정 시점 하나로 해결되는 문제가 아님. 구매자 기준 시점 환율, 판매자 기준 시점 환율, 합의, 합의 허용오차, 합의된 확정 타임스탬프 같은 것이 모두 영향을 줌
불변성 때문에 돈을 다루는 모든 곳에는 이벤트 소싱을 두고 싶어짐. 최종 정리된 스트림은 A -> B -> E처럼 보이지만, 실제 스트림은 A0 -> Edit(A0, A) -> B -> C -> D -> Rollback(B) -> E일 수 있음
결국 Fintech도 다 같은 Fintech가 아님. 어떤 곳에서는 돈이 짐짝처럼 취급됐고, 다른 곳에서는 돈이 모든 것의 중심이었음

정수/부동소수점 얘기가 정확히 뭘 가리키는지 모르겠음. 글에서는 경험칙으로 부동소수점은 쓰지 말라고 분명히 말하고, 거의 항상 좋은 생각이 아니며 예측 불가능한 정밀도 손실을 일으킨다고 설명하고, 여러 곳에서 정수나 BigDecimal 타입을 권장함. 유리수까지 말하는 건지 궁금함
외환에 대해서도 핸드북의 “정 canonical rate는 없다”는 말을 보강하는 것처럼 보임. 게다가 글은 확정 이후 기록을 다루고 있고, 이쪽은 확정 방법을 말하는 것 아닌가 싶음. 별도 목표에 대한 유효한 뉘앙스이긴 하지만, 빠졌거나 틀렸다는 증거처럼 보이지는 않음
불변성 부분도 글이 같은 요지를 말하는 것 같음. 무엇이 다르다는 건지 모르겠음

이건 문제를 너무 과장한 것임. 금융의 여러 영역은 double로도 잘 돌아감
금리 경로 위에서 Monte Carlo 옵션 가격을 계산하고, 듀레이션, 컨벡시티, 베가 같은 위험 지표에 관심이 있다면 반올림 규칙이 뭔지는 아무도 신경 쓰지 않음. double이면 충분함. exp(-rt)cashflow나 정규 누적분포함수를 어떻게 정수로 강제할 건가?
정수가 맞는 영역도 있음. 하지만 보편적인 원칙은 아니고, 올바른 공학적 선택을 하면 됨

나도 그 부분이 제일 먼저 눈에 띄었고 위키 전체를 의심하게 됐음. 돈을 저장하는 유일하게 올바른 방식은 말한 대로 정수[1]이며, 이 점을 명확히 했어야 함
사용하는 환경이 지원한다면 고정소수점도 쓸 수 있지만, 기술적으로는 여전히 정수임

필요한 모든 일을 정수만으로 할 수는 없음. 센트보다 작은 값을 표시하거나 계산해야 할 때가 있고, 어떤 곳에서는 대부분의 경우 부동소수점 오류에 안전한 BigDecimal 같은 것이 필요함
표시용으로는 decimal 값을 반환해도 안전함

JSON에는 부동소수점이 아니라 숫자가 있음. 파싱된 뒤 어떻게 쓰이는지는 명세의 일부가 아님
금액을 정수로 저장하는 시스템에서 도망간다니 좋음. 그러면 아마 같은 시스템에서 일하지 않게 될 듯함. 요즘은 오히려 금액을 정수로 다루는 시스템에서 도망가고 싶을 때가 많음. 경험 많은 금융 프로그래머만 만지는 이상적인 코드베이스라면 잘 될 수 있지만, 그런 시스템은 대개 지나치게 배타적이거나 취약해질 위험이 있음

금액 표현에 minor-unit precision 전략을 고려하는 사람에게 조언하자면, 하지 않는 편이 좋음. 적어도 교환/API 데이터 형식으로는 쓰지 말아야 함
빠른 정수 연산, 덧셈과 뺄셈의 반올림 문제 없음처럼 영리해 보이지만, 특정 통화에 대해 암묵적으로 가정한 자릿수가 다른 파트너와 일하는 순간 극심하게 물릴 수 있음. 특히 스테이블코인은 자신이 대표하는 법정화폐와 암묵적 소수 자릿수가 다른 경우가 많아 더 중요함
JSON 기반 API에서는 금액을 문자열 타입으로 표현하는 것도 고려할 만함. JSON은 십진 정밀도를 지정하지 않으므로, 자신과 모든 사용자/벤더가 파서/직렬화기가 내부적으로 부동소수점을 거치며 정밀도를 잃지 않는지 항상 확인해야 함. 금방 지저분해질 수 있고, 문자열은 개념적으로 덜 깔끔해 보이지만 이 문제를 완전히 우회함. 어떤 사람들은 이를 안티패턴 [1]이라고 부르겠지만, 사용자나 주주의 어깨 위에서 이념적 순수성을 위해 이 싸움을 하고 싶지는 않음
[1] https://blog.json-everything.net/posts/numbers-are-numbers-n...

여기서 유일하게 진짜 올바른 해법은 가수와 지수를 별도 정수 두 개로 보내는 것임. 원하는 계산에 맞춰 지수 사이를 변환하는 건 사소하고, 원하는 만큼 정확하게 만들 수 있으며 모호하지 않음
고빈도 거래 영역에서는 어떤 {slice}에 대해 미리 일관된 지수를 확정할 수 있으면 전송 공간을 아낄 수 있음. 예를 들면 상품/틱 크기/자산군/거래소/피드/서버 같은 범위에서 가수만 보내고 클라이언트는 하드코딩된 지수를 쓰는 식임
하지만 비슷한 영역에서도 전송 데이터에 uint32 지수를 하나 더 보내는 값어치가 있을 때가 많음. 그래야 나중에 바꿀 수 있고, “지금은 센트만 필요해” 같은 초기 설계 때문에 발목 잡히지 않음. 예를 들어 갑자기 bitcoin 가격을 전체 정밀도로 지원해야 할 수 있음. 고정 지수를 조정하고 싶을 때 깨지는 변경을 조율하지 않아도 되면 사용자들이 고마워할 것임

C++로 고빈도/저지연 거래를 만들고 브라우저 기반, 즉 JavaScript 관리 프런트엔드를 붙여본 입장에서 말하면, 그냥 모두 정수 센트를 쓰면 됨. 사실상 업계 표준이고 잘 동작함. 다른 선택지는 전부 더 나쁜 절충임

그게 왜 문제가 되는지 모르겠음. 상대 API와 상호작용할 때 값을 변환하면 됨

그 글의 결론이 “파서를 고쳐야 한다. JSON 숫자에서 원하는 어떤 숫자 타입이든, 어떤 정밀도든 추출할 수 있어야 한다”라고 한다면, 그건 기껏해야 극단적이고 비현실적이라는 데 전적으로 동의함
“어떤”이라는 기준은 비합리적임. 실제로 입증 가능한 가치도 없이 무제한의 공학 예산을 요구할 수 있는 달성 불가능한 표준임
표준 부재를 식별하고, 실제 파서들이 어떻게 동작하는지 이야기하고, 공백과 충족되지 않은 사용 사례를 논의하는 건 좋음. 더 합리적인 표준이 필요하다고 제안하는 것도 좋음. 하지만 아무도 실제로 필요로 하지 않고, 의미도 불명확하며, 실제로 달성할 수도 없는 “모든 가능성”을 모두가 지원하라고 요구하는 건 좋은 생각이 아님

그 대신 뭘 추천하는지 궁금함. 표준 부동소수점인 float/double, minor unit의 천분의 일이나 그보다 작은 단위의 고정소수점 산술, 임의 정밀도 십진수, 아니면 완전히 다른 방식인가?

프로그래머로서 Fintech 프로그래머들이 각자 다른 경험과 관점에서 말하는 걸 보면, 프로그래밍을 잘한다는 게 대체 무엇인지 궁금해짐
xlii가 금액을 부동소수점으로 저장하지 말라고 한 건 흔한 IEEE 754 문제임. 금융 추적은 불변 로그나 이벤트 기반 기록으로 하는 게 맞지만, 주변 서비스 전부를 이벤트 소싱으로 만들 필요는 없다고 봄. 원장, 정산, 주문, 체결 같은 핵심 로직에만 적용해도 충분하다고 생각함. xlii의 글을 보면 모델링이 성공했을 때만 실현 가능한 기법처럼 보임
lxgr의 말은 minor-unit 문제를 짚음. JSON 숫자를 언어나 파서가 부동소수점으로 파싱하면 정밀도가 손실될 수 있음. 보통은 값과 별도의 소수 자릿수 필드를 함께 보냄. 다만 고빈도 거래에서는 그 오버헤드 자체가 너무 비싸서 그렇게 하지 않는다고 들었음
antonymoose의 말은 많은 책에서 말하는 내용과 맞닿아 있음. 그래서 외환이나 API 맥락에서는 이런 설계가 흔함. 프로토콜 설계처럼 느껴지기도 함
종합하면 모두가 자기 도메인 안에서는 맞음. xlii 같은 사람이 시니어 프로그래머라면 좋겠다고 생각하지만, 동시에 내가 그런 복잡한 시스템을 설계할 수는 없을 것 같기도 함. 그런 의미에서 각자의 말이 타당하고, 도메인에 따라 의견이 갈리는 모습이 흥미로움. 이게 전문성인가 싶음
이런 걸 보면 프로그래머가 어떤 경험에서 왔는지 대략 추론할 수 있음. 때로 프로그래밍은 정답을 찾는 게 아니라 세계관을 선택하는 일처럼 느껴짐
HN에서 프로그래머들이 자기 도메인을 어떻게 모델링하는지 보는 건 늘 흥미로움. 가끔 프로필을 눌러보고, 언젠가 쓸지도 모른다고 생각하며 그들의 도메인 지식을 개인 위키에 추가함

그 위키에 대해 더 듣고 싶음

좋음. 이 책에는 이미 다른 곳에서도 찾을 수 있는 좋은 정보가 많이 담겨 있는데, 모아놓은 것만으로도 꽤 실용적임. Kleppmann의 Designing Data-Intensive Applications를 강력히 추천함. 1판도 아주 좋았고 최근에 2판이 나왔음
FinTech에서 CTO로 일하며 전체 소프트웨어 스택을 처음부터 만든 적이 있는데, 책의 교훈은 대체로 맞음. 대체로라고 한 건 언제나 그렇듯 특정 프로젝트에서는 “상황에 따라 다름”을 많이 고려해야 하기 때문임. 예를 들어 나는 전체 상태 계산 문제를 피하려고 이벤트 소싱을 쓰지 않았음. 표준적인 append-only 감사 추적만으로도 충분할 수 있음
정확히 한 번 전달은 보장할 수 없지만, 사실상 한 번 처리는 구성할 수 있고, 실제로 원하는 것도 그쪽임
모든 요청과 응답을 저장하라는 말은 절대적으로 맞음. API를 소비할 때뿐 아니라 외부 세계에서 어떤 정보를 수집할 때도 그래야 하며, 가능하다면 경계 안에서 모든 중간 변환 단계도 기록해야 함. 콘텐츠 주소 기반 버킷과 관계형 테이블 조합이 좋음
또한 본문은 데이터 계보에 대해 아무 말도 하지 않음. 벤더가 한낮에 어떤 데이터를 업데이트했고, 그 사실을 반드시 알아야 한다면 어떻게 할 것인가? 예전 값을 사용한 계산을 재실행해도 같은 결과가 나오도록 하면서, 그 변화를 설명할 수 있어야 함. 풀기 특별히 어려운 문제는 아니지만, 생각이 필요함

“나쁜 조언”이라니 꽤 점잖게 표현한 것임. 솔직히 이 “핸드북”은 대부분 LLM이 쓴 것 같음
예를 들어 불변성 섹션에 이런 문장이 있음: “PII를 금융 데이터와 분리하면, 보관해야 하는 금융 이력을 잃지 않고 삭제권을 존중할 수 있다”
금융기관에서는 명백한 KYC/AML 이유로 둘이 함께 움직임
관련 기간이 만료되기 전에 고객 이름, 주소 등을 요청 즉시 지우면서 금융 데이터만 남겨두면, 범죄 추적을 위해 합법적 기관이 데이터를 요구하러 왔을 때 조직 전체가 아주 나쁜 하루를 보내게 될 것임
Fintech에서 일하려는 사람은 알 수 없는 관할권의 알 수 없는 사람이 쓴 임의의 “핸드북”에 의존하면 안 됨
Fintech에서 일하는 사람은 고용주의 내부 핸드북/가이드라인 등에 따라서만 일해야 함. 그런 문서는 회사 변호사와 컴플라이언스 담당자들이 함께 작성해, 고용주가 운영되는 관할권의 법과 보고 요건을 충족하도록 만들어졌을 것임

글이 관련 기간 만료 전에 고객 이름과 주소 등을 요청 즉시 지우라고 어디서 권장하는지 모르겠음
내가 보기에는 결국 삭제해야 할 PII와, 회계 방정식/불변조건에 들어가므로 사실상 영구 보관하고 싶은 데이터를 분리하라고 권장함. 그래야 관련 기록 보관 기간이 지난 뒤 전자를 삭제할 수 있음
알 수 없는 관할권의 알 수 없는 사람이 쓴 “핸드북”에 의존하면 안 된다는 건 맞음. 하지만 거기에 나온 아이디어와 실천을 맹목적으로 무시하거나 자기 조직 밖을 보지 않는 것도 안 됨. 이상적으로는 그걸 본 뒤 자신의 지식과 현지 규정과 대조해 조정해야 함
완벽하고 오류 없는 조직만 있는 세상이라면 고용주의 내부 지침만 따르는 접근이 합리적으로 보임. 하지만 이런 대화 없이 어떻게 그 수준에 도달할 수 있겠음?

이 내용 대부분은 Fintech뿐 아니라 소프트웨어 엔지니어링 전반에 적용된다고 봄
예를 들어 재시도, 멱등성, 이벤트 순서 등을 다루는 부분은 돈이 직접 관련되지 않더라도 어느 정도의 정확성이 필요한 모든 시스템에 적용됨. “언제든 재시도하면 된다”는 가정으로 만든 시스템을 너무 많이 봤는데, 애초에 깨끗하게 실패해야만 재시도가 가능하고, 하위 시스템이 내가 생각하는 수준의 멱등성을 제공해야 함. 이런 부분은 자주 실제로 검증되지 않음

동의함. 원장 처리와 반올림 부분을 빼면 여기서 Fintech에만 특별히 적용되는 내용은 거의 없고, 그마저도 꽤 가벼움
차라리 계정별 데이터베이스 같은 더 급진적인 접근을 옹호하는 글을 읽고 싶음. Fintech 안에서 고유한 트레이드오프가 있는 그런 것 말임
Fintech 엔지니어나 창업자에게 가장 해주고 싶은 조언은 첫날부터 위험과 컴플라이언스를 진지하게 다루라는 것임
금융 시스템은 신뢰를 기반으로 함. 위험을 입증 가능하게 완화하지 못하면 신뢰를 잃고, 결국 사업 전체를 잃게 됨

부동소수점을 피하라는 말은 사실이 아님. Fintech에서 20년 일했는데 대부분 double을 썼음. Excel도 double을 쓰고, 프런트엔드도 double을 쓸 것이며, 모든 데이터베이스가 double을 지원함. 표준 라이브러리는 double 파싱을 알고 있고, JSON도 이론은 몰라도 실제로는 double을 씀. 많은 ERP 시스템도 double을 씀
double로 통화를 다룰 때 핵심은 총 15자리 정밀도를 담을 수 있다는 점을 염두에 두는 것임. 숫자가 123456789.01이나 123.456789처럼 그보다 많은 자릿수를 쓰지 않는 한, 금융 계산에서 완벽한 십진 정밀도를 가질 수 있음. 각 계산 뒤와 각 비교 전에 항상 결과를 15자리 정밀도 안으로 반올림하면 됨. Excel이 그렇게 함
double의 가장 큰 장점은 널리 지원되고, 시스템 안에서 서로 다른 정밀도를 섞을 수 있다는 것임. 국제 금융이나 고급 금융상품을 다루면 그런 일이 생김. 어떤 회계는 천분의 일까지 정밀도가 필요하고, 어떤 것은 0.25의 배수로 반올림해야 함. 결국 기본 산술은 쓰지 않고 특화된 회계 수학 라이브러리를 쓰게 될 것이며, 그 라이브러리는 백엔드로 부동소수점을 완벽히 사용할 수 있음

Plaid 잔액 확인은 곧 제출할 ACH 출금이 성공한다는 보장이 아님
잔액이 백만 달러든 상관없음. ACH가 처리되기 전에 모든 돈이 (a) 전신송금으로 빠져나가거나, (b) 어제의 ACH들, 즉 청구서, 자동이체 등과 수표로 청산되거나, (c) 직불카드/ATM에서 사용될 수 있음
왜 일부 Fintech가 이걸 처리하지 않는지 내가 어떻게 아는지는 아마 말하지 않는 게 좋겠음

좋은 지표이긴 하지만 절대 보장은 아님. 이 개념을 이해하지 못한 프로젝트 매니저들에게 설명해야 했던 적이 있음

멱등성 키 섹션만으로도 읽을 가치가 있음. 대부분의 개발자는 그 교훈을 힘들게 배움

지금도 쓰이는 60~70년대 핵심 은행 시스템과 금융 통신 프로토콜이 만들어질 때 금융업계 자체가 이걸 알고 있었으면 좋았겠음
이들 중 다수는 멱등성에 대한 지식이 널리 퍼지기 전의 것이어서, 여러 개의 전역적으로 고유할 것 같은 필드를 이어붙여 멱등성 키를 억지로 만드는 경우가 많음. 문제는 그게 결코 완전히 고유하지 않다는 것임. 가끔 커튼 뒤를 볼 수 있는데, 예를 들어 은행이 같은 날짜에 같은 금액을 같은 수취 계좌로 이체하지 못하게 할 때가 그런 경우임

100% 동의함. 더 자세히 다룰 가치도 있음 멱등성이 어떻게 동작해야 하는지, 왜 중요한지 설명하는 데 많은 시간을 썼음. 대부분의 팀은 필요성은 이해하지만, 처음부터 생각해둔 팀은 거의 없었음

감사 추적도 마찬가지임. 좋은 감사 추적은 비상시에 회사와 자신을 구할 수 있음. 디버깅에도 유용하고, 최후의 컴플라이언스 데이터 소스로도 쓸 수 있음

“Fintech”는 매우 넓고, Fintech라고 불리는 것의 대부분은 사실 통신임. 회사 간, 트레이더 간, 시스템 간, 원장 간 통신임. 업계 전체에 통용되는 “올바른” 프로그래밍 방식은 없음. 결국 올바른 방식은 내가 통신하는 상대가 이해할 수 있는 방식이기 때문임
상대가 통화를 센트 단위로 추적한다면, 그보다 더 높은 정밀도로 추적하면 반올림 불일치가 생김. 반대로 나는 센트 단위인데 상대는 0.1센트 단위로 다뤄도 마찬가지임. 이 문서의 다른 조언들도 모두 그렇게 봐야 함