Tinypay 프로젝트 회고

결제 API를 개발하다 보면 “결제 요청 한 번에 결제도 정확히 한 번만 실행된다”고 생각하기 쉽다.하지만 실제 서비스에서는 동일한 결제 요청이 여러 번 전달될 수 있다.사용자가 결제 버튼을 연속으로 클릭한 경우서버 응답이 늦어 프론트엔드가 요청을 다시 보낸 경우모바일

앞선 작업에서는 멱등성 키를 적용해 동일한 결제 요청이 반복 실행되는 문제를 방지했다.하지만 멱등성만으로 모든 동시성 문제가 해결되는 것은 아니다.예를 들어 한 사용자의 지갑 잔액이 100일 때 서로 다른 80원짜리 결제 두 건이 동시에 들어올 수 있다.결제 A와 B는

이전 결제 로직은 결제 결과를 다음과 같이 단순하게 관리하고 있었다.이 구조는 결제가 성공했는지 실패했는지는 알려주지만, 결제가 어떤 단계를 거쳤고 어느 단계에서 실패했는지는 표현하기 어렵다.블록체인 결제를 예로 들면 실제 처리 과정에는 여러 단계가 존재한다.그런데 모

앞선 작업에서는 결제 시스템에 다음 기능을 적용했다.멱등성 키를 이용한 중복 결제 방지비관적 락을 이용한 잔액 동시성 제어결제 상태 머신과 실패 단계 기록하지만 이런 기능을 적용해도 내부 결제 기록과 블록체인의 실제 거래 결과가 항상 일치한다고 단정할 수는 없다.예를

이전 작업에서는 서버의 결제 기록과 블록체인 거래 내역을 비교하는 결제 대사 기능을 구현했다.하지만 대사 기능이 자동으로 실행된다는 것만으로는 운영 환경에서 충분하지 않았다.예를 들어 다음과 같은 질문에 답할 방법이 필요했다.현재 대기 중인 대사는 몇 건인가?결제 기록

결제 시스템에 멱등성, DB 락, 상태 머신, 대사 배치를 구현했다고 해서 곧바로 안전하다고 말할 수 있을까?코드만 보면 올바르게 동작하는 것처럼 보여도 실제 데이터베이스에서는 예상과 다르게 동작할 수 있다.특히 다음 기능은 단위 테스트만으로 충분히 검증하기 어렵다.비

결제 시스템의 안정성을 높이기 위해 지금까지 다음 기능을 구현했다.멱등성 키 기반 중복 결제 방지비관적 락 기반 동시성 제어결제 상태 머신블록체인 거래 대사대사 모니터링 API대사 실패 알림과 자동 재시도Transactional Outbox실제 MySQL 기반 통합 테

TinyPay의 결제 안정성을 개선하면서 멱등성 키, 동시성 제어, 결제 상태 머신, 대사 배치와 같은 기능을 추가했습니다.하지만 애플리케이션 내부의 안정성을 높이더라도, 새로운 버전을 배포하는 순간 서비스가 중단되거나 문제가 있는 버전이 운영 환경에 바로 노출된다면

이전 작업에서는 TinyPay의 프롬프트 인젝션 탐지 기능을 강화했습니다.기존 정규식 탐지 외에도 다음과 같은 우회 공격을 탐지하도록 개선했습니다.제로폭 문자 삽입전각 Unicode 문자 사용문장부호를 이용한 키워드 분리시스템·개발자 역할 위조긴 문자열 뒤쪽에 공격문

TinyPay에는 사용자의 요청을 분석해 필요한 AI 서비스를 결정하고, 유료 API 사용이 필요하면 예상 결제 금액을 안내하는 기능이 있습니다.AI가 결제 흐름과 연결되어 있기 때문에 일반적인 챗봇보다 프롬프트 인젝션에 더욱 주의해야 했습니다.프롬프트 인젝션이란 사용