(1) Local-first software 입문기
어떤 주제를 다양한 경로에서 마주치게 되면 자연스럽게 관심을 갖게 되는 편이다. 그리고 요즘 그런 주제가 Local-first software다.
Local-first software란, 다른 컴퓨터가 내가 해당 소프트웨어를 사용하는 데 영향을 주지 못하는 소프트웨어를 의미한다. 일반적인 웹 애플리케이션은 AWS 같은 클라우드 서비스를 기반으로 동작하기 때문에, AWS가 멈추면 이를 사용하는 서비스들도 영향을 받는다. 하지만 Local-first software는 이러한 종속성을 벗어나려는 접근법이다. (Local-first software도 클라우드를 사용하긴 하지만, 주로 백업 용도로 활용된다.)
그렇다고 해서 Local-only software는 아니다. 일반적인 데스크톱 프로그램과 달리, Local-first software는 멀티플레이어 환경을 고려한다. 대표적인 예로 Excalidraw, Figma, Linear 등이 있다.
짧게 공부한 바로는 Local-first software의 여러 장점 중 하나가 네트워크 오류를 고려하지 않아도 된다는 점이라고 한다. 대부분의 데이터를 클라이언트 측에 저장하고, 필요할 때만 클라우드와 동기화하는 방식인 듯한데, 이 부분은 좀 더 공부해봐야 할 것 같다.
Local-first software는 기존 웹 서비스의 대안이라는 점에서 Web3와 공통점을 가지지만, 또 완전히 반대이기도 하다.
- Local-first software는 외부 변수에 대한 의존성을 줄였다는 장점이 있지만, 서비스 간의 상호호환성을 희생했다.
- 반대로, Web3는 서비스 간의 상호호환성을 극대화했지만, 외부 변수(EVM, 타 앱의 사용량 등)의 영향을 더 크게 받는다는 단점이 있다.
내가 Delta에 인턴으로 합류한 것도 이러한 관심의 연장선에 있다. Delta는 CRDT라는 데이터 구조와 ZK라는 두 가지 핵심 기술을 사용하는데, 이 중 CRDT는 Local-first software에서 흔히 사용되는 데이터 구조다. Delta의 파운더 Oleh가 처음 작성한 글에서도 Local-first software와 블록체인의 장점을 모두 가져가는 디자인에 대한 고민이 담겨 있는데, 이는 Delta의 기술적 방향성에도 큰 영향을 미친 것으로 보인다. Delta 외에도 Pod나 Topology 같은 팀들도 CRDT를 활용하는 것으로 알고 있다.
📌 추천 자료
(2) Fintech에서 Tokentech로
크립토에 익숙한 우리는 보통 토큰 = 크립토라고 생각하지만, 이 글을 통해 토큰이라는 개념이 훨씬 넓게 쓰인다는 걸 다시 한번 깨달았다.
- Payment token: Apple Pay 등에서 카드 정보가 ‘토큰화’되어 저장 및 사용됨.
- Identity token: 운전면허증이나 정부 ID가 Apple Pay에 보관될 때도 토큰의 형태로 저장됨.
- Asset token: 우리가 익숙한 스테이블코인이나, 실물 자산을 디지털화한 토큰.
이렇게 보면, 자연스럽게 서로 다른 종류의 토큰들이 공유할 수 있는 기준이 존재할 수 있는가? 라는 질문이 떠오른다. 만약 가능하다면,
- 패스키로 신원 인증하고,
- 카드로 결제한 후,
- 페이백을 USDC로 받는 것 같은 프로그래머블한 금융 서비스도 가능해질 수 있다.
개인적으로는 Delta가 이런 토큰 간의 표준을 뒷받침할 가장 적합한 현실적인 인프라라고 생각하지만, 이를 주장하려면 Payment token과 Identity token이 실제로 어떻게 구현되는지 더 공부해봐야 할 것 같다.
어쨌든, 이 글에서 이야기하는 핵심은 Fintech가 Tokentech로 변화하는 과정에서, 금융 활동 대부분이 이미 "토큰화"된 상태라는 것이다.
📌 To-do
- Payment token과 Identity token의 실제 구현 방식 조사
(3) 금융 비용 대부분은 리스크에서 나오는 것 같다
금융 및 결제 시스템에서 발생하는 불필요한 비용의 대부분은 리스크에 대한 프리미엄이거나, 리스크를 줄이기 위한 조치에서 비롯된다는 생각이 든다.
대표적인 예로 결제 수수료 중 가장 많은 비중을 차지하는 Interchange Fee가 있다. 이는 merchant(가맹점)가 issuer(카드 발급 은행)에게 지불하는 수수료인데, 결국 issuer가 감당하는 리스크에 대한 비용으로 볼 수 있다.
예를 들어,
- 신용카드가 도난당해 부정 사용되었을 경우, 은행은 이를 환불해야 한다.
- 차지백(Chargeback, 고객이 결제를 취소하는 행위)이 발생하면, 은행이 손실을 감당해야 한다.
과거에는 Scam(스캠, 고객을 속여 돈을 송금하게 만드는 사기) 에 대해 은행이나 금융 기관이 책임을 지지 않았다. 그러나 최근에는 규제가 강화되면서 금융기관들도 일정 부분 책임을 지게 되는 방향으로 바뀌고 있다.
예를 들어, 작년 영국 PSR(Payment Services Regulator)의 지침에 따르면,
- 모든 은행 및 결제 업체는 사기 피해 고객에게 최대 $110,000까지 환불해야 한다.
- 이는 은행 및 금융기관들이 애초에 사기가 발생하지 않도록 더 많은 투자를 하게 될 것을 의미한다.
위 사례들은 리스크 = 비용이라는 관계를 보여주는 대표적인 예시다. 그렇다면 우리는 자연스럽게 이 비용을 줄일 방법을 고민할 수밖에 없다.
- 규제 강제 자동화 (Automatic Compliance Enforcement)
- 고도화된 비정상 거래 탐지
결국, 스테이블코인이 기존 결제보다 더 효율적이고 저렴하다는 주장을 강화하려면, 이런 규제 강제 자동화 같은 보완책이 필요할 것 같다.
개인적으로는 Delta가 이런 문제를 해결하는 데 강점을 가질 수 있다고 생각하지만, 역시 더 많은 근거를 확보한 후 주장하는 것이 좋을 것 같다.
📌 To-do
- 크립토 환경에서 존재하는 규제 조사
- 코드 단에서 강제할 수 있는 규제는 무엇이 있는지 분석
의견을 남겨주세요