글의 핵심인 변경분을 비동기로 감지해 처리하는 방식은 결합도를 낮추고 부수 효과를 구현하기에 좋음
하지만 LLM은 코드가 곳곳으로 퍼지는 현상을 막기보다 가속하는 도구라서 아키텍처상 부채가 되기 쉬움. 이해하는 속도보다 빠르게 생성되는 코드를 어떻게 검토할 수 있는지도 의문인데, Exe가 코드 검토조차 하지 않는다는 대목은 더욱 두려움

원래도 진지한 적이 별로 없던 기술 업계가 지금은 유난히 비진지한 시기를 지나고 있음을 기억해야 함

청구 시스템을 다루는 입장에서 꽤 무서운 접근임. 청구 플랫폼은 여러 경계가 명확한 컨텍스트로 구성되는데, LLM은 도메인 경계를 잘 지키지 못하므로 큰 고통을 부를 가능성이 큼

“LLM을 써도”가 아니라 “특히 LLM을 쓰면” 코드가 더 퍼지는 것 아닌가 싶었음

그 인용문은 Orwell이 아니라 Upton Sinclair의 말로 알고 있음

이 아키텍처가 흥미롭기는 하지만, 글 앞부분에서 제시한 문제를 어떻게 해결하는지는 불분명함. 결제가 거절되면 모든 리소스의 결제를 보장하기보다 미결제 리소스를 먼저 제공하게 될 것으로 보임
청구 작업자가 declined 사실을 발행해 리소스를 회수할 수도 있지만, 깔끔한 단방향 흐름과 비교하면 순환 구조가 됨. Exe처럼 월별로 청구하는 컴퓨팅 서비스에는 잘 맞겠지만, 물리 장비를 배송하거나 다른 서비스의 좌석을 재판매하는 사업에서는 받아들이기 어려운 절충안임

제품이 추상적이고 대체 가능한 소프트웨어 중심 청구 방식임. 사용량 기반 청구는 과금 이벤트가 발생했다는 분석 데이터를 토대로 하고, 청구 시스템이 이를 집계해 일관된 청구 내역을 만드는 편이 좋음. 과금 이벤트는 여러 곳에서 생길 수 있으므로 제품 코드 밖으로 분리하는 것도 건전함
다만 API 호출이나 데이터베이스 트랜잭션 실패, 비정상적인 구독 상태, 좌석 결제 거절을 어떻게 처리하는지는 직접 답하지 않음. 리팩터링으로 분석 수집이 깨지거나, 특정 행을 더 이상 변경 상태로 표시하지 않거나, 새 경로에서 변경 표시를 빠뜨리는 문제도 그대로 남음
좌석·무료 할당량 제한, 최대 지출액 설정, 선불 잔액 차감처럼 제품 내부에 존재하는 청구 관련 상태도 해결하지 못함. 제품 서비스가 이벤트를 발행하고 청구 서비스가 준수 상태를 다시 제품에 반영할 수 있지만, 그러면 상태를 가진 분산 시스템에 두 행위자가 생김

Stripe가 숫자 하나만 원하는 것처럼 보이지만, 일정 규모에서는 결제의 세부 항목까지 제공하면 교환 수수료를 절감하고 승인율을 높일 수 있음

Exe가 코드 검토를 하지 않는 방식은 신선함. 그렇다면 릴리스와 테스트는 어떤 방식으로 운영하는지 궁금함