diff --git a/.forge/SPRING-ARC-CONVERGE-1783828654-attempt-1.md b/.forge/SPRING-ARC-CONVERGE-1783828654-attempt-1.md
new file mode 100644
index 0000000..a1c0b16
--- /dev/null
+++ b/.forge/SPRING-ARC-CONVERGE-1783828654-attempt-1.md
@@ -0,0 +1,3 @@
+# SPRING-ARC-CONVERGE-1783828654-attempt-1
+
+Forge 이슈 작업 브랜치 `forge/SPRING-ARC-CONVERGE-1783828654-attempt-1`.
diff --git a/docs/architecture/adr-payment-boundary.md b/docs/architecture/adr-payment-boundary.md
new file mode 100644
index 0000000..7e4a67b
--- /dev/null
+++ b/docs/architecture/adr-payment-boundary.md
@@ -0,0 +1,19 @@
+# Architecture Decision Record: Payment Boundary
+
+## Context
+In order to manage payment processing effectively, we need to establish clear boundaries between our domain logic and the external payment gateway. This separation will help us maintain a clean architecture and ensure that the domain does not directly depend on external systems, thereby promoting better testability and adaptability.
+
+## Decision
+We will use a port and adapter pattern, where the payment gateway will be accessed through a defined interface (port), and the actual implementation will be contained within an adapter. This will allow for easy switching of payment gateways without affecting the domain logic.
+
+## Alternatives
+1. **Direct Integration:** Integrating the payment gateway directly into the domain layer.  
+   - **Pros:** Simplicity in initial integration.
+   - **Cons:** Increases coupling, making it hard to switch gateways in the future.
+
+2. **Adapter Pattern (Chosen):** Implementing a port and adapter structure.  
+   - **Pros:** Low coupling, greater flexibility.
+   - **Cons:** Additional complexity in setup.
+
+## Consequences
+By adopting the port and adapter structure, we will ensure that the payment domain is isolated from external changes, which simplifies testing and reduces the risk of regressions related to payment processing.
\ No newline at end of file