diff --git a/.forge/SPRING-ARC-REFERENCE-1783832425-attempt-4.md b/.forge/SPRING-ARC-REFERENCE-1783832425-attempt-4.md
deleted file mode 100644
index 9b2bede..0000000
--- a/.forge/SPRING-ARC-REFERENCE-1783832425-attempt-4.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# SPRING-ARC-REFERENCE-1783832425-attempt-4
-
-Forge 이슈 작업 브랜치 `forge/SPRING-ARC-REFERENCE-1783832425-attempt-4`.
diff --git a/docs/architecture/adr-payment-boundary.md b/docs/architecture/adr-payment-boundary.md
deleted file mode 100644
index 6f11c74..0000000
--- a/docs/architecture/adr-payment-boundary.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Architecture Decision Record: Payment Boundary
-
-## Context
-In the process of defining a payment transition architecture, it is essential to delineate clear boundaries regarding payments. This includes how payments are processed, managed, and interacted with other services within the larger application ecosystem.
-
-## Decision
-The payment boundary will be established to segregate payment functionalities from other domains. This will facilitate clearer service contracts, promote scalability, and enhance maintainability. The boundaries defined are:
-1. **Payment Processing** - Manage all transaction flows, including initiation, validation, and completion.
-2. **Payment Storage** - Handle data persistence for transactions, ensuring compliance with security protocols.
-3. **Payment Notifications** - Direct communication with users and systems regarding the status of transactions.
-
-Additional services such as audits and reporting will be encapsulated within the payment context but operate on a separate service layer.
-
-## Alternatives
-- **Single Service**: All payment functionalities within one service.
-  - **Pros**: Simplicity in managing. 
-  - **Cons**: Difficult to scale and maintain, especially with increased complexity.
-- **Microservices**: Distributed payment functions.
-  - **Pros**: Improved separation of concerns, easier to manage separately.
-  - **Cons**: Increased complexity in inter-service communication.
-
-The decision leans towards microservices for better scalability and maintainability of the payment system.
-
-## Consequences
-Implementing a microservices approach to the payment boundary means that each service can be scaled independently, enhancing performance. However, it also requires robust inter-service communication strategies and potentially higher operational overhead due to multiple service deployments.
\ No newline at end of file