diff --git a/.forge/SPRING-ARC-REVIEW-1783835414-attempt-1-run-ed09f4501fdf.md b/.forge/SPRING-ARC-REVIEW-1783835414-attempt-1-run-ed09f4501fdf.md
deleted file mode 100644
index 62e0434..0000000
--- a/.forge/SPRING-ARC-REVIEW-1783835414-attempt-1-run-ed09f4501fdf.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# SPRING-ARC-REVIEW-1783835414-attempt-1-run-ed09f4501fdf
-
-Forge 이슈 작업 브랜치 `forge/SPRING-ARC-REVIEW-1783835414-attempt-1-run-ed09f4501fdf`.
diff --git a/docs/architecture/adr-payment-boundary.md b/docs/architecture/adr-payment-boundary.md
deleted file mode 100644
index f8a1e07..0000000
--- a/docs/architecture/adr-payment-boundary.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# ADR: 결제 경계 정의
-
-## Context
-이 결정은 결제 처리 시스템의 경계를 정의하는 것을 목표로 한다. 여러 서비스 간의 상호작용과 데이터 흐름을 명확하게 규명하여, 각 서비스가 자신의 책임을 다할 수 있도록 하고자 한다.
-
-## Decision
-결제 처리 시스템은 다음과 같은 경계를 가질 것이다:
-- 결제 요청 서비스: 사용자로부터 결제를 요청받고, 유효성을 검사한 후 결제 처리 서비스를 호출한다.
-- 결제 처리 서비스: 결제 요청을 처리하고, 외부 결제 제공자와 통신하여 결제를 수행한다.
-- 결제 확인 서비스: 결제 처리 결과를 사용자에게 전달하고, 결제 상태를 관리한다.
-
-## Alternatives
-1. 단일 서비스 아키텍처: 모든 결제 관련 기능을 단일 서비스에서 처리.
-2. 마이크로서비스 아키텍처: 각 기능별로 서비스를 분리하여 독립적으로 운영.
-
-## Consequences
-- 마이크로서비스 아키텍처를 선택할 경우, 각 서비스의 독립성을 높일 수 있으며, 변화에 대해 더 유연하게 대응할 수 있다. 그러나 서비스 간의 통신 오버헤드와 데이터 일관성 관리가 필요하다.
-- 반면에 단일 서비스 아키텍처는 초기 개발이 용이하지만, 장기적으로 코드가 복잡해질 위험이 있다.
\ No newline at end of file