GN⁺: 엔지니어들의 스타트업 실수 없는 Ledger 구축

스타트업에서 회계 시스템 구축 시 실수하지 않기

• 핀테크 회사에서 돈의 흐름을 놓치지 않는 것은 기본임. 그러나 일부 스타트업에서는 거래마다 몇 센트를 놓치는 경우가 발생함.
• 스타트업에서는 "작동하게 만들고, 올바르게 만들고, 빠르게 만들자"라는 철학을 따르며 복식부기 시스템을 구축하지 않음.
• 이러한 실수는 사용자 불만을 초래하고, 회사의 성장을 방해함.
• 고객 지원팀이 수동으로 잘못된 거래를 보상하는 방식으로 문제를 해결하려고 했음.

회계 시스템의 중요성

• 돈은 이동할 때 생성되며, 이를 추적하는 것은 복잡함.
• 단일 부기 시스템은 자금 흐름을 제공하지만, 그 이유를 설명하지 못함.
• 복식부기 시스템은 돈의 출처와 목적지를 모두 추적하여 문제를 해결할 수 있음.

복식부기 시스템의 데이터 모델

• 복식부기 시스템은 계정, 항목, 거래라는 세 가지 엔티티로 구성됨.
• 계정은 가치의 변화를 나타내며, 항목은 계정 간의 자금 흐름을 나타냄.
• 거래는 항목이 올바르게 쌍을 이루도록 보장함.

두 가지 회계 시스템

• 회계 시스템은 외부에서 본 장부의 인터페이스이며, 엔지니어링 시스템은 장부의 구현임.
• 회계 시스템은 높은 가용성과 낮은 지연 시간을 요구하며, 엔지니어링 시스템은 강력한 일관성과 데이터 정확성을 요구함.

항목의 작동 방식

• 항목은 대기, 폐기, 게시의 세 가지 상태 중 하나에 있을 수 있음.
• 항목은 항상 대기 상태로 생성되며, 폐기된 항목은 게시된 항목으로 대체될 수 있음.

거래의 작동 방식

• 거래는 항목이 게시되거나 폐기될 때만 게시됨.
• 거래가 부분적으로 실패할 경우 보상 항목으로 의미적으로 취소할 수 있음.

계정의 작동 방식

• 계정은 여러 항목과 연결되며, 총 잔액은 모든 항목의 개별 잔액의 합계와 일치해야 함.
• 계정의 정상 잔액에 따라 총 잔액 계산 방식이 다름.

결론

• 장부는 비기술적 분야로 위장한 어려운 컴퓨터 과학 문제의 명확한 예시임.
• 복식부기 시스템을 구축하는 것은 적절한 맥락 없이는 어렵지만, 이를 통해 더 나은 결정을 내릴 수 있음.

[neo]

Hacker News 의견

• Synapse 고객의 경우 많은 돈이 사라졌음. 은행은 자금의 흐름을 엄격히 관리해야 하지만, 핀테크는 FBO 계좌에 모든 자금을 모아두고 이를 추적하는 원장을 구축함. Synapse의 경우 원장에 기록된 고객 잔액이 실제 FBO 계좌의 자금보다 많았음. 이는 사기보다는 결함 있는 원장 때문일 가능성이 높음. 핀테크 예금 계좌에 돈을 넣지 말고 실제 은행을 이용할 것을 권장함. 핀테크는 종종 예금이 FDIC 보험에 가입되어 있다고 주장하지만, 이는 기본 은행이 파산할 경우에만 보호됨.

• Google에서 일하면서 신뢰성이나 정확성을 희생하여 확장성을 얻는 것에 대해 배움. 수백만 쿼리를 처리할 때 일부는 실패할 수 있으며, 이는 엔지니어링 태도의 차이를 보여줌. Gmail을 열었을 때 오류가 발생하는 경우가 많지만, 사용자는 새로고침을 통해 문제를 해결함. 저장소의 내구성이 99.99999%일 경우, 20억 명의 고객 중 200명은 불편을 겪을 수 있음.

• 엔지니어링 리더십에서 도메인 지식의 중요성을 강조함. 금융 회사에서 일할 경우 금융에 대한 이해가 필요하며, 이는 저널리즘이나 상업에서도 마찬가지임. 성공적인 조직은 기술 팀 인터뷰에서 도메인 관련 비기술적 질문을 포함함.

• 적절한 인재를 고용하는 것이 중요함. 데이터 구조와 알고리즘을 잘 아는 사람을 고용하는 것보다 실제로 필요한 것을 구축할 수 있는 사람을 고용해야 함. 엔지니어가 다른 분야의 교육을 받는 것이 도움이 될 수 있음. 문제 해결과 엔지니어링은 산업에 대한 깊은 이해와 전문가와의 협력을 통해 이루어짐.

• 인터넷/통신 스타트업에서 청구 시스템을 구축한 경험을 공유함. 청구 로직을 두 곳에 구축하여 동기화 유지가 어려웠음. 수작업으로 청구서를 검토하여 오류를 방지했으며, 이중 로직을 통해 오류를 방지함. 이 경험을 통해 복식부기의 중요성을 이해하게 됨.

• 단일 입력 회계 시스템을 옹호하는 의견이 많음. 단일 입력 회계가 더 쉬울 수 있지만, 복식부기를 사용하는 것이 좋음. 프로그래머를 위한 회계 관련 자료를 찾고 있음.

• "make it work, make it right, make it fast"라는 원칙에 대한 오해가 있음. "make it right"는 두 번째 단계이며, 시스템이 올바르게 작동할 때까지 작업이 중단됨. 최적화는 모든 문제가 해결된 후에 시작됨.

• 테스트가 없는 경우, 거래에서 돈을 잃는 문제가 발생할 수 있음. 금융 시스템을 구축할 때 이러한 문제를 정상으로 여기는 것은 잘못임.

• 은행의 일부를 재발명하려는 경우, 이미 검증된 시스템을 참고하는 것이 좋음. 예를 들어, 미국의 중소형 금융 기관에서 사용되는 핵심 은행 예금 거래 스키마를 참고할 수 있음.

• 돈을 다루는 소프트웨어는 매우 신중하게 다루어야 하며, 과거의 실수를 인식해야 함. 영국 우체국 스캔들이 이러한 문제의 실제 결과를 보여줌.