엔지니어는 Ledger 구축에서 스타트업식 실수를 할 수 없음

 (news.alvaroduran.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 실제 돈을 다루는 핀테크에서는 몇 센트 차이도 사용자 신뢰를 무너뜨리며, 단일 입력 방식으로 거래를 기록한 주식 거래 스타트업은 dancing cents 문제를 겪음
  • 단일 입력 원장은 돈의 입출금만 남기기 때문에 외환, 브로커의 rounding to even, FINRA TAF 수수료처럼 차이를 만든 원인을 추적하기 어려움
  • 이중 입력 원장은 돈이 항상 한 계정에서 다른 계정으로 이동한다고 보고, Accounts, Entries, Transactions를 분리해 출처와 목적지를 함께 기록함
  • Entries의 pending, discarded, posted 상태와 Transactions의 게시 조건을 명확히 두면 부분 실패와 보상 Entries를 더 안전하게 다룰 수 있음
  • Ledger는 회계 보고를 위한 인터페이스이면서 동시에 돈의 일관성을 지키는 system of record라서, 확장 과정에서 가용성과 강한 일관성 사이의 긴장이 커짐

몇 센트 차이가 무너뜨린 사용자 신뢰

  • 주식 거래 플랫폼을 만들던 스타트업은 “make it work, make it right, make it fast” 원칙을 따르며 처음부터 이중 입력 회계 시스템을 만들지 않음
  • 출시 직후 벤더가 인식한 금액과 내부 시스템이 인식한 금액이 몇 센트씩 어긋남
    • 내부에서는 이를 dancing cents라고 부름
    • 사용자는 Apple 주식 5달러어치를 샀는데 주문이 4.98달러로 보이면 즉시 고객지원에 문의함
  • 문제의 본질은 손실 금액보다 신뢰와 성장에 있었음
    • 화난 사용자는 서비스를 추천하지 않았고, 스타트업의 성장이 막힘
    • CEO는 잘못된 거래가 발생하면 고객지원이 몇 센트를 수동 보상하도록 지시함
    • 이를 처리하기 위해 Slack 봇도 만듦

돈은 현재 잔액이 아니라 미래의 가치까지 추적함

  • Ledger는 돈을 추적하는 시스템임
  • 돈은 단순한 현재 잔액이 아니라 앞으로 받을 가치나 줄 가치를 표현할 때 필요함
    • 개념적으로 돈은 미래의 자산임
  • “사용자가 5달러를 냈다”, “사용자가 6달러를 냈다”처럼 입출금만 기록하면 실제 금융 흐름을 설명하기 부족함
  • 은행 송금은 인터넷 기준으로 느리고, 많은 은행은 송금을 다음 영업일에 정산함
    • 결제가 완료되면 언젠가 돈을 받을 것이라는 확신은 생김
    • 하지만 주식은 지금 브로커를 통해 사야 함
    • 며칠 뒤 정산될 pending 금액과 즉시 브로커로 나가는 금액을 동시에 표현해야 함
  • 단일 입력 방식에서는 오류가 났을 때 롤백이 매우 어렵고, 일부 코너 케이스에서는 롤백을 시도하지도 못함

단일 입력 원장이 디버깅을 막는 이유

  • 단일 입력 원장은 자금 흐름을 보여줄 수 있지만, 그 흐름이 왜 발생했는지까지 설명하지 못함
  • 특정 돈의 이동 원인을 찾으려면 여러 모델의 데이터를 이어 붙여야 했고, 어떤 경우에는 그마저 불가능했음
  • 이중 입력 원장은 무엇이 일어났는지와 왜 일어났는지를 함께 남김
    • 모든 돈 이동은 한 계정에서 다른 계정으로 발생함
    • 각 센트가 어느 계정에서 나와 어느 계정으로 갔는지 기록됨
  • dancing cents 문제는 단일 입력 시스템에서 해결하기 어려웠음
  • 시스템이 어떻게 동작하는지 이해할 수 없으면 버그를 없애기도 어려움

Ledger 데이터 모델: Accounts, Entries, Transactions

  • 많은 엔지니어는 처음 돈을 추적할 때 도메인 모델 안에 금액을 넣음
    • Order에 price 속성을 두거나 expenses 테이블에 amount 컬럼을 두는 방식임
    • 이는 balance as property 접근임
  • 이 방식은 초기에 빠르게 작동하지만, 시간이 지나면 리포팅이 복잡하고 느려지며 결제 처리와 분석도 어려워짐
    • 야간 리포트 작업이 여러 시간 걸린다면 이 접근이 근본 원인일 수 있음
  • Ledger는 시스템의 모든 금융 거래를 도출할 수 있는 별도 데이터 모델로 다루는 편이 좋음
  • 세 가지 엔티티가 기본 구조를 이룸
    • Accounts: 가치의 버킷이자 시간이 지나며 가치가 어떻게 변하는지 보는 관점
    • Entries: 계정 사이의 자금 흐름이며, 항상 가치의 교환을 나타냄
    • Transactions: Entries가 올바르게 짝지어지고 처리되도록 보장하는 단위

Entries의 상태와 불변성

  • Entries는 pending, discarded, posted 세 가지 상태를 가질 수 있음
  • Entry는 항상 pending 상태로 생성됨
    • 교환된 가치
    • 방향인 credit 또는 debit
    • 참조하는 account 정보
  • 금액의 방향을 양수와 음수로 표현하는 것은 흔한 실수임
  • Entries는 기본적으로 불변이지만, pending Entry는 posted Entry를 만들기 위해 discarded될 수 있음
  • pending Entry를 되돌리기 위해 reversal Entry를 만드는 대안도 있음
    • 하지만 reversal Entry 방식은 계정 이력을 지저분하게 만들 수 있음
    • discarded 상태를 쓰면 현재 Entries를 볼 때 discarded_at이 설정된 항목을 제외하면 되고, 이력도 잃지 않음
  • 이중 입력 시스템에서는 discarded되지 않은 credit Entries의 총액과 discarded되지 않은 debit Entries의 총액이 같음
    • 개념적으로 돈을 주머니 안에서 어떻게 옮겨도 총액은 같다는 뜻임
  • 외부 세계를 나타내며 Profit and Loss statement에 합쳐지는 일부 특수 계정은 예외적으로 균형을 맞출 수 없음

Transactions와 부분 실패 처리

  • Entries는 쌍으로 생성되며, Transactions는 그 과정이 의도대로 진행되도록 보장함
  • Transaction은 연결된 Entries가 posted이거나 discarded 상태이고 posted Entries로 대체된 경우에만 posted됨
  • 부분 실패가 난 Transaction은 compensating Entries로 의미적으로 되돌릴 수 있음
  • 이 접근은 Saga pattern과 잘 맞음
    • Saga는 원자성을 가용성과 맞바꿈
    • 여러 테이블을 잠그는 느린 트랜잭션 대신 더 작은 개별 작업과 중간 체크포인트로 프로세스를 나눔
    • 그 사이 다른 트랜잭션이 작업할 수 있어 처리량이 좋아짐

Accounts와 normal balance

  • 단일 Account 관점에서 Ledger는 단일 입력 시스템처럼 보임
    • 하나의 Account는 여러 Entries와 일대다 관계를 가짐
    • 총 잔액은 연결된 Entries의 개별 잔액을 집계한 값과 맞아야 함
  • Account의 normal balance에 따라 총액 계산 방식이 달라짐
  • Entry 금액에 양수·음수 부호를 묶는 것은 회계적으로 피해야 함
    • 어떤 계정은 net credit이 정상이고, 어떤 계정은 net debit이 정상임
    • 예를 들어 은행 현금 계정은 net debit이 정상일 수 있지만, 초과 인출되면 음수가 될 수 있음
  • normal credit balance는 연결된 credit Entries 총액이 debit Entries 총액보다 클 때 정상이라는 뜻임
  • normal debit balance는 그 반대임

회계 시스템과 엔지니어링 시스템의 긴장

  • Ledger에는 서로 다른 요구를 가진 두 시스템이 공존함
    • Accounting system: 외부에서 보는 Ledger의 인터페이스
    • Engineering system: Ledger가 자기 자신을 보는 구현
  • Accounting system은 여러 관점에서 집계된 데이터를 노출함
    • Reporting
    • Financial ratios
    • Business Intelligence
  • Engineering system은 데이터의 일관성과 정확성을 보장해야 함
    • 핀테크 회사에서 Ledger는 영업팀의 CRM처럼 source of truth 역할을 함
  • Ledger 확장이 어려운 이유는 두 시스템의 요구가 서로 다르기 때문임
    • Accounting system은 높은 가용성과 낮은 지연 시간을 요구함
    • Engineering system은 강한 일관성과 schema-on-write 검사를 요구함

개발자가 참고할 회계 자료

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Synapse 고객들에게도 그렇게 말해 보라고 하고 싶음. 수백만 달러가 사라졌음
    은행은 돈이 어디로 갔는지 엄격한 규칙에 따라 장부를 맞춰야 하지만, 핀테크는 보통 고객 돈을 모아 둔 하나 또는 몇 개의 기초 FBO 계좌 위에 자체 원장을 얹어 각 고객 잔액을 추적함. Synapse의 경우 자체 원장상 고객 잔액 총합이 실제 FBO 계좌 잔액보다 훨씬 컸음
    많은 사람들이 사기를 의심하지만, 그냥 엉망이고 버그 많은 원장이었을 가능성에 돈을 걸겠음. 내부를 보고 나면 핀테크 예금 계좌에는 절대 돈을 넣지 않을 것 같고, 진짜 은행을 쓰는 편이 낫다. 핀테크가 예금이 FDIC 보험 대상이라고 홍보해도, 그건 기초 은행이 망했을 때만 보호해 주지 핀테크가 내 돈을 추적하지 못하게 된 경우는 보호하지 않음
    참고: https://www.forbes.com/sites/zennonkapron/2024/11/08/what-th...

    • 9천만 달러가 사라지고 2억5천만 달러가 동결됨. 그 돈 중 상당수는 누군가의 월세로 필요했을 돈일 수 있음
      Andreessen Horowitz가 투자했는데, 이들은 모든 정부 규제에 대해 초토화전을 벌이는 쪽임
      https://finance.yahoo.com/personal-finance/synapse-bankruptc...
    • 큰 회사에서 일할 때 거래 시스템 간 일관성이 없어서 돈이 허공에서 생기거나 사라지는 일이 있었음
      그 전에 코드베이스가 너무 엉망이라 이런 것들을 제대로 추적하지 못할 것이라고 예상했고, 모든 게 마법처럼 돌아간다고 믿던 상사와 다퉜음. 며칠 뒤 회계 불일치에 대한 감사가 시작된다는 메일을 받았음
      JPMC는 내부적으로 현금 흐름을 일관되게 관리하기 위해 암호화폐 사용을 제안했지만, 실제로 어디까지 갔는지는 모르겠음
    • Synapse는 실제 회계 실수가 은행인 Evolve 쪽에 있었다고 말함. 누락된 거래, 보고되지 않은 차변, 진행 중인 거래를 Mercury로 보내면서 Synapse에는 잘못 차감한 일 등이 포함됨
      https://lex.substack.com/p/podcast-what-really-happened-at-s...
    • HSBC 계좌에서 돈이 사라진 적이 있음. 두 계좌 사이 결제였는데 복식 항목이 소액만큼 맞지 않았고, 장부상 쉽게 대조할 수 없었음
      한동안 따졌지만 제대로 인정도 하지 않았고 고쳐 주지도 않았음. 근거 없이 내부의 미묘한 절도일지도 모른다고 의심했지만, 무능이 더 그럴듯한 설명일 듯함
    • 실제 은행 기관도 불안하기는 마찬가지임. 예를 들어 Vanguard는 몇 년 전 개발 업무 상당 부분을 인도에 외주화했음
      BoA에서 시스템 관리자로 일한 친구는 특정 로그를 7년 보관해야 했지만, 디스크가 가득 차기 시작하면 그냥 지워 버렸다고 함

  • Google에서 일하기 시작했을 때 이해하는 데 시간이 걸렸던 것 중 하나가 확장성을 위해 신뢰성이나 정확성을 절충하는 일이었음
    이전에는 과금 시스템이나 소규모 OLTP 웹 애플리케이션을 만들었고, 허용 가능한 데이터 손실이나 0이 아닌 오류율 같은 질문 자체를 떠올린 적이 없었음. 초당 수백만 요청을 처리하면 일부는 실패한다는 사실보다, 엔지니어링 태도의 차이가 더 충격적이었음
    지금 이 순간에도 Gmail을 열었는데 제대로 로드되지 않거나 500 오류를 받은 사람이 수천 명쯤 있을 수 있음. 아무도 그 원인을 추적하지 않는데, 사용자가 새로고침하고 하루를 계속 보낼 것이기 때문임. 반대로 저장소 내구성이 1년에 99.99999%라는 인상적인 수치여도 고객이 20억 명이면 200명은 정말 최악의 하루를 겪게 됨
    로그의 모든 오류를 조사하던 습관에서, 모든 것이 항상 조금씩 망가져 있고 뭔가를 고치기 전에 비용을 먼저 따지는 방식으로 넘어가는 전환이 꽤 충격적이었음

    • 그 정도로 낮은 내구성 수준은 이제 최신 수준이 아님
      비슷한 규모에서 많이 본 경험칙은 전체 인프라 기준으로 100년에 데이터 손실 1건을 목표로 하는 것임. 보통 비용은 10%보다 훨씬 적게 늘지만, 데이터 배치 알고리즘을 설계할 때 조합론을 이해하는 사람이 필요함
      이쪽을 이해해야 한다면 copyset 논문이 좋은 출발점임
    • 이 말은 대체로 맞지만, 반대 방향도 자주 봤음. 특히 실패에 대해 아주 느슨한 감각을 가진 소셜미디어 회사 출신들이 금융 애플리케이션으로 들어오는 경우인데, 대체로 잘 풀리지 않음
    • Google에 있을 때 Android 팀에 파견되어 연락처 동기화 작업을 한 적이 있음. 내가 겪던 문제는 극히 드문 상황이었고, 프로덕션 집계 데이터를 뽑아 보니 사용자 0.01% 에 영향을 줄 것 같았음
      해결책을 발표하며 이 오류율을 말했더니, 그 20만 명의 Android 사용자가 어떻게 복구할 수 있느냐는 질문을 받았음. 복구할 방법이 없고 연락처 동기화가 그냥 망가질 뿐이라서, 다시 설계하라는 말을 들었음
      숫자 자체가 겸손하게 만들었음. 99.99%로 충분한 영역도 분명 있지만, 충분하지 않은 영역도 그만큼 많음

  • 이런 일은 처음부터 맞는 사람을 뽑는 게 도움이 됨. LeetCode 전문가를 잔뜩 뽑아 놓고, 자료구조와 알고리즘을 머릿속에서 떠올리는 능력 말고 실제로 만들고 싶은 것을 만들 수 있는지 묻지 않으면 안 됨
    사람들이 그 대상을 어떻게 만들어야 하는지 알고 있다면 성장을 희생할 필요가 없고, 처음부터 제대로 만들어짐
    때로는 회계, 금융, 생물학 같은 다른 교육 배경을 가진 엔지니어가 필요함. 커리어에서 가장 중요했던 부분은 내가 만드는 대상 산업을 깊이 이해하고, 정말 중요한 질문을 던질 수 있는 해당 분야 전문가를 아는 일이었음. 그게 문제 해결이자 엔지니어링이고, 나머지는 프로그래밍/코딩임

    • HN에서 내 현재 일상을 이렇게 무섭도록 정확히 묘사하면서도 완전히 동의하게 만드는 글은 처음 봄
      커리어 대부분을 기술과 금융이 겹치는 영역, 주로 판매세·사용세 준수 쪽에서 보냈음. 그 과정에서 회계사, 컨트롤러, 변호사들이 나에게 얼마나 영향을 줬는지 충분히 깨닫지 못했음
      최근 꽤 오래된 스타트업의 원장 시스템을 자문했는데, 금융이나 회계 배경이 없는 엔지니어들이 회계 시스템을 만들면 어떤 모습이 되는지 보고 경악했음
      마법 같은 회계사 겸 엔지니어를 찾을 필요는 없음. 설계 과정에 실제 회계사를 엔지니어링 팀 옆에 앉히기만 해도 충분함. 전체 개편 설계를 마친 뒤 CPA 친구에게 완전히 검토를 맡겼고, 몇몇 시나리오에서 구멍을 찾았지만 대체로 괜찮았음
      돈은 어려운 엔지니어링 문제임. 돈에는 그 주변을 둘러싼 인간의 온갖 엉뚱함이 따라오기 때문임
    • 맞음. 원장은 도메인 지식임. 고부하 최적화를 포함해 다른 모든 것은 그 위에 만들어야 함
    • 어떤 집단에는 기술이 모든 문제를 해결할 수 있다고 믿는 짜증나는 경향이 있음. 혁신을 무엇보다 높게 평가하다 보니 전문가를 멀리함

  • 엔지니어링 리더십에서 도메인 지식이 중요하다는 점을 다시 확인하게 됨. 금융 회사에서 일한다면 올바른 기술적 결정과 절충을 위해 금융을 어느 정도 이해해야 하고, 저널리즘이나 상거래도 마찬가지임
    내가 일했던 성공적인 조직들은 항상 기술팀 면접에 도메인 특화 비기술 질문을 포함했음. 반대로 기술적으로 매우 뛰어난 팀 중 일부는 도메인 통찰이 부족해서 허우적댔음

    • 소프트웨어 엔지니어이면서 CPA라서 도메인 지식은 있음. 그런데 그걸 적용할 일을 어떻게 찾을지 모르겠음
      어디를 봐도 회계 경력과 상대적으로 짧은 소프트웨어 엔지니어 경력을 가진 나보다, 도메인 지식은 전혀 없어도 소프트웨어 엔지니어 경력이 두 배인 사람을 훨씬 선호하는 것 같음. 이걸 효과적으로 활용하는 방법이 있을지 궁금함
    • 취지에는 동의하지만, 그런 도메인 특화 질문도 그냥 다른 기술 영역의 기술 질문으로 보는 편이 도움이 됨
      금융도 기술적이고, 기계공학도 기술적이며, 스포츠 경영이나 사회학에도 큰 기술적 요소가 있음. 기술 역량이 무엇인지 넓게 바라보면 여러 도메인에서 협업하는 데 필요한 겸손함이 생김
    • 보험 회사에서 일하기 시작한 뒤로 보험 산업을 이해하는 것이 코드베이스를 이해하는 것보다 훨씬 어렵다는 걸 깨달았음. 코드베이스가 이상하게 동작하면 적어도 디버거로 따라가 볼 수는 있음
    • 그건 잘 모르겠음. 도메인 지식을 모두 갖는 건 제품 관리자의 역할이라고 늘 이해해 왔음
      요구사항이 올바른지, 만들어진 제품이 그 요구사항을 충족하는지 엔지니어링과 함께 확인하는 게 PM의 일임. 애자일 환경에서는 그런 대화와 검증이 매 스프린트마다 일어나므로, 뭔가가 너무 오래 걸러지지 않고 지나가기는 어려움
      PM이 없다면 엔지니어링 팀에 깊은 도메인 지식이 필요하겠지만, 그렇지 않다면 엔지니어링의 책임은 아님. 제품 조직의 책임

  • 오래된 이야기를 하나 하자면, 복식부기 시스템을 만든 적은 없지만 수십 년 전 매출이 8자리까지 성장한 인터넷/통신 스타트업에서 과금 시스템을 만든 적이 있음
    젊은 개발자로서 잘 몰랐고 우연히도 첫날부터 과금 로직을 만들게 됐는데, 좋든 나쁘든 시스템의 두 곳에 만들었음. 소비자용 과금 웹페이지와, 인보이스를 생성하고 신용카드 결제를 수행하는 별도 백엔드 프로세스였음
    둘을 맞춰 유지하는 일은 놀라울 만큼 어려웠음. 자본을 태우며 시장 반응을 찾으려고 계속 반복 개발했고, 새 제품과 서비스, 새 할인·가격 방식, 사용량 과금, 월 과금, 첫 X회 무료, 기업 계정의 대표 결제자/하위 계정, 사용자가 지정하는 비용 센터, 그 비용 센터로 세금 배분과 1센트 단위 배분 같은 기능이 계속 추가됐음. 그럴 때마다 새로운 주름과 예외가 생겨 두 화면/방식의 숫자가 맞지 않았음
    과금 책임자가 나였기 때문에 매달 며칠씩 모든 인보이스를 손으로 훑어, 신용카드 결제와 종이 인보이스 발송 전에 최종 점검으로 숫자가 맞는지 확인했음. 항상 또는 자주 한 명이나 소수 고객에게 영향을 주는 새 문제를 발견했고, 실제 과금 전에 코드를 고쳤음. 모든 걸 손으로 재확인하지 않고 놓아주는 게 늘 불안했음
    불일치와 수동 교차 검증을 없애기 위해 과금 로직을 한 곳으로 리팩터링할까 고민했지만, 오래 생각한 끝에 단일 코드베이스가 불편했고 오히려 두 코드베이스가 내 오류를 잡는 데 도움이 된다는 걸 깨달았음. 이후에는 두 구현 사이의 자동 실행과 교차 검증을 점점 쉽게 만들었음
    과금 코드는 자랑하기엔 좀 지저분했지만, 과금 정확도, 불만 부족, 여러 해 동안 피한 아찔한 실수들은 매우 자랑스러웠음. 후임자들에게 남긴 복잡성에는 약간 죄책감이 있지만, 지금도 크게 후회하지는 않음
    그 경험 뒤로는 복식부기의 동기가 항상 잘 이해됐음. 고객에게 피해가 가지 않도록 내 실수를 막기 위해, 허접한 방식으로 이중 로직 과금 코드를 재발명한 셈이었음

    • 과금이나 돈이 얽힌 것은 무엇이든 틀리기 너무 쉬움
      예전 회사에서 이끌게 된 데이터 팀은 돈을 “잃어버리는” 불운한 습관이 있었음. 실제 돈이 다른 곳으로 이동 중 사라진 건 아니었고, 고객에게 청구해야 할 기록이 사라지는 식이었음
      매출을 잃지 않을 때는 이중 청구를 하곤 했고, 이런 일이 계속됐음. 경영진의 신뢰를 되찾는 데 3년의 힘든 작업이 걸렸음
    • 악의는 없지만 악몽처럼 들림. 동시에 시스템 복잡성에도 불구하고 정확성을 달성한 건 정말 훌륭한 일임. 자랑스러워해도 됨
    • 이건 N-version programming과도 매우 비슷함

  • 테스트도 없었나? “5달러를 구매할 때마다 거래 로그에는 4.98달러가 남았다”는 예를 들 정도로 매 거래마다 돈을 잃어버린다면, 문제는 복식부기 부재보다 훨씬 더 큼
    누가 그런 금융 시스템을 만들고 정상이라고 여김? 보상도 문제지만, 그런 서비스라면 가능한 한 빨리 도망쳐야 함

    • 바로 이 사람들이 그랬음. 스스로 “제대로 만들 수도 있었지만 그러지 않았다”고 말했음. 사고가 아니라 선택이었음
      “춤추는 센트” 같은 농담을 했고, 의미 있는 결과를 감수하지 않아도 된다는 걸 알고 있었기 때문에 그렇게 했음. 빠르게 움직였고, 무언가를—돈과 관련된 것을—망가뜨렸고, 웃어넘겼음
      이제는 자신들이 의도적으로 그런 결정을 했다는 이유로 도덕적·기술적 권위가 있는 것처럼 사람들을 가르치려 듦. 놀랍도록 거만한 스타트업 VC 문화식 헛소리임
    • 아직도 돈을 어떻게 잃어버렸는지 이해하지 못했음. 복식부기가 진단에는 도움이 됐겠지만, 실제로는 어떻게 사라진 거지?
    • 나도 같은 생각이었음. 원장은 장점이 많지만 춤추는 센트 문제를 고쳐 주지는 않음. 원장에 잘못된 숫자가 올라갈 뿐임
      물론 버그를 찾는 데 단서가 될 수는 있지만, 기본적인 테스트를 작성해도 마찬가지였을 것임
    • 좋은 설계 원칙 하나는 테스트 1000개만큼 가치 있음
    • 그 이야기가 사실인지 어떻게 판단함?

  • 작성자가 “make it work, make it right, make it fast”라는 격언을 왜 부정적으로 가져오는지 모르겠음. 아마 “make it fast”가 어디에 들어가는지 오해한 듯함
    “make it right”가 두 번째 단계이고, 올바르게 동작하게 만들기 전에는 거기서 작업이 멈춰야 함. 시스템이 건전하게 작동해야 함. “make it fast”, 즉 최적화는 정확성과 건전성 문제가 완벽하게 해결된 뒤에야 시작하는 것임
    이것은 납품 속도나 빨리 일하는 것과는 상관없고, 최적화를 마지막 단계로 미루라는 뜻임
    다만 작성자가 말하고 싶었던 것이, 어떤 것이 대충 “작동”하더라도 “올바름”에서 너무 멀어 나중에 되돌려 고칠 수 없고, 겨우 작동하기 시작하기 전부터 처음부터 “올바르게” 만들어야 한다는 점이라면 이해됨

    • 마지막 문장이 맞다고 봄. 작성자는 결제 시스템에서는 먼저 작동하게 만든 뒤 나중에 올바르게 만들 수 없다고 말하는 것 같음
      나도 같은 생각이고, 핀테크 시스템 감사에 참여한 적이 있음. 감사인들이 장부 승인 전에 모든 것을 Excel 스프레드시트로 내려받아 숫자를 맞춰야 했음. 시간과 돈이 많이 들었고, 3년 뒤 유동화 이벤트에서 최소 0.1 유니콘 정도 차이를 만들었을 것이라고 짐작함
    • 작성자가 잘못된 격언을 골랐다고 봄
      빠르게 움직이는 스타트업에서는 가능한 빨리 사실상 MVP를 출시함. 고객 기반과 재무 등을 만들어야 하므로 “make it work” 단계에서 멈춰 버림
      더 나은 격언은 Facebook의 “move fast and break things”였을 것임. 다만 그건 나중에 고칠 수 있을 때만 통함. 예를 들어 항공기를 만든다면 그렇게 하지 않을 것임
    • 엔지니어링 팀이 이 격언을 따랐다고 했고, 그 안에는 “make it right”가 포함돼 있음. 하지만 그들은 그러지 않았음. 제품을 만들기 전에 핀테크에 대해 무엇을 모르는지 알아보려는 시도조차 하지 않았음
      그 문맥을 보면 첫 문장에서 말한 오해가 가장 그럴듯함. 바로 뒤에서 스타트업이 받는 시간 압박을 이야기하기 때문임

  • 여기 댓글 대부분이 글이 비판하는 내용을 그대로 반복하고 있음. 단식부기를 옹호하는 긴 논쟁이 수없이 보임
    단식부기가 더 쉽고 더 일반화되어 있을 수는 있지만, 때로는 수세기에 걸쳐 발전한 시스템과 추상화를 그냥 따르는 게 좋은 생각임
    반드시 다른 것이 필요한 게 아니라면 복식부기를 쓰는 편이 낫다. 프로그래머 본능에는 찝찝할 수 있지만, 불일치를 정리하려고 실제 회계사를 불러야 하는 순간이 오면 고마워하게 될 것임
    관련해서 결제나 인접 분야의 프로그래머를 위한 좋은 자료를 아는 사람이 있을까? “프로그래머를 위한 회계” 같은 것 말임

  • 10번 거래할 때마다 데이터의 1%가 사라지는 데이터베이스 시스템을 쓰고 있다고 말하면, 이런 엔지니어링 블로그 조언을 진지하게 받아들일 수 있겠나? 이런 글은 개념 소개라기보다 특정 개인이나 집단 홍보 광고처럼 차분하게 포장된 느낌이 듦

  • 돈을 옮기는 소프트웨어에 대한 이런 허술한 태도가 실제 사람에게 어떤 결과를 낳는지 보려면 Post Office 스캔들을 보면 됨
    https://en.wikipedia.org/wiki/British_Post_Office_scandal
    돈을 움직이는 모든 것은 최대한 진지하게 다뤄야 하고, 가능한 한 많은 역사적 실패를 알고 있어야 함

답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.