diff --git a/.forge/SPRING-ARC-VERIFIED-1783826844-attempt-3.md b/.forge/SPRING-ARC-VERIFIED-1783826844-attempt-3.md
deleted file mode 100644
index 1ed3abe..0000000
--- a/.forge/SPRING-ARC-VERIFIED-1783826844-attempt-3.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# SPRING-ARC-VERIFIED-1783826844-attempt-3
-
-Forge 이슈 작업 브랜치 `forge/SPRING-ARC-VERIFIED-1783826844-attempt-3`.
diff --git a/docs/architecture/adr-payment-boundary.md b/docs/architecture/adr-payment-boundary.md
deleted file mode 100644
index e218e6c..0000000
--- a/docs/architecture/adr-payment-boundary.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Payment Boundary Decision Record
-
-## Context
-In developing the architecture for the payment processing system, our objective is to ensure a clear separation between the application logic and the payment gateways. This boundary will help maintain a clean architecture and allow for easier testing and maintainability.
-
-## Decision
-We have decided to implement a port and adapter pattern where the payment gateway is accessed via a defined interface (port) rather than being directly referenced in the domain model. This ensures that our domain logic remains agnostic of the specific implementations of payment gateways.
-
-## Alternatives
-1. Direct coupling with the payment gateway: This approach could lead to tight coupling and hinder maintainability and testability.
-2. Abstracting payment logic into a service layer: While this maintains separation, it increases complexity and could introduce overhead. 
-
-## Consequences
-- By adhering to the port and adapter pattern, we ensure our domain model remains clean and focused on business logic.
-- Changes in payment gateway implementations can be managed without affecting the domain logic, leading to improved agility.
\ No newline at end of file