diff --git a/.forge/SPRING-ARC-REVIEW-1783824683-attempt-4.md b/.forge/SPRING-ARC-REVIEW-1783824683-attempt-4.md
new file mode 100644
index 0000000..9aa1af2
--- /dev/null
+++ b/.forge/SPRING-ARC-REVIEW-1783824683-attempt-4.md
@@ -0,0 +1,3 @@
+# SPRING-ARC-REVIEW-1783824683-attempt-4
+
+Forge 이슈 작업 브랜치 `forge/SPRING-ARC-REVIEW-1783824683-attempt-4`.
diff --git a/docs/architecture/adr-payment-boundary.md b/docs/architecture/adr-payment-boundary.md
new file mode 100644
index 0000000..d8d7736
--- /dev/null
+++ b/docs/architecture/adr-payment-boundary.md
@@ -0,0 +1,15 @@
+# Payment Boundary Context
+
+## Context
+The payment processing system interfaces with external payment gateways and integrates seamlessly within the existing application architecture. The payment boundary defines the interfaces and interactions involved in processing payments, specifically ensuring transactions adhere to security, compliance, and business logic.
+
+## Decision
+The decision is to maintain a clear boundary between the payment domain and external gateways, thereby isolating payment logic from external dependencies and facilitating easier testing and maintenance. The adapters for payment gateways will not be directly referenced in the domain models.
+
+## Alternatives
+1. **Direct integration with payment gateways:** This would introduce tight coupling and hinder testing.
+2. **Using an event-driven approach:** While this has its benefits, the complexity of asynchronous processing may introduce challenges in transaction consistency.
+
+## Consequences
+- **Pros:** Improved testability and maintainability; stricter adherence to SOLID principles.
+- **Cons:** Slightly increased complexity in managing adapters and interfaces.
\ No newline at end of file