항해+ 백엔드 코드 3주차 회고

이번주의 주된 과제는 '아키텍처'였다. 총 4개의 아키텍처 중 원하는 아키텍처를 선택하고,
지난주에 선택한 시나리오(이커머스 웹)를 선택한 아키텍처로 구현해보는 과제였다.

항해 추천인코드: NYFKU8

✍️ 이번 주 주제: 아키텍처

이번 주의 메인 과제는 **'아키텍처'**였습니다.
총 4개의 아키텍처(레이어드, 릴레이션 레이어드, 클린, 헥사고날) 중 하나를 선택하고,
지난주에 설정한 이커머스 웹 시나리오를 기반으로 해당 아키텍처를 적용해 구현하는 것이 목표였습니다.

---

📌 과제 링크

• Step05 PR
• Step06 PR

---

🗂️ 과제 요약

🔹 STEP 05

• 선택한 아키텍처에 맞춰 패키지 구조 설계
• 핵심 비즈니스 로직 구현
• 시나리오 기반 필수 기능 구현
• 단위 테스트 작성(Mocking/Stub 활용)
  → 단위 테스트는 외부 의존성 없이 해당 기능 자체에 집중

🔹 STEP 06

• 시나리오 기반 추가 기능 구현
• 각 레이어의 책임을 README에 명시
• 아키텍처 설계 원칙에 맞춰 책임 분리 및 유지보수성 고려한 구조 개선

---

🔍 아키텍처별 핵심 요약

1. 레이어드 아키텍처 (Layered Architecture)

Layered Architecture

• 가장 전통적인 구조
• Controller → Service → Repository → DB
• 단순한 CRUD 시스템에 적합
• 단점: 계층 건너뛰기 유혹, 테스트 어려움, 도메인 로직 분산

2. 릴레이션 레이어드 (Layered + Interface / DIP 적용)

• 레이어드는 유지하되, 인터페이스로 추상화
• Repository → Interface → 구현체
• DIP 일부 적용 (Service는 인터페이스에만 의존)
• 장점: 유연한 구조, DB 교체 용이, 테스트 가능
• 단점: 도메인 모델 여전히 빈약

3. 헥사고날 아키텍처 (Hexagonal Architecture)

• 도메인 로직을 중심으로, 외부 시스템은 어댑터로 처리
• REST, gRPC, MQ 등 다양한 입출력 대응 가능
• 포트(Port): 도메인이 요구하는 인터페이스
• 어댑터(Adapter): 외부 시스템을 연결하는 구현체
• 장점: 도메인 독립성, 테스트 용이
• 단점: 작은 프로젝트에 과도할 수 있음

4. 클린 아키텍처 (Clean Architecture)

• UseCase 중심 설계, 도메인 모델과 유스케이스가 핵심
• 모든 외부 의존성은 내부를 향함
• 도메인 → UseCase → Interface → Adapter
• DIP 완전 적용, OCP 준수
• 장점: 유지보수성, 확장성 최고
• 단점: 인터페이스 과다, 복잡도 높음

---

🛠 내가 선택한 아키텍처: 클린 아키텍처

클린 아키텍처를 선택한 이유는 다음과 같습니다:

• 비즈니스 로직의 독립성과 테스트 용이성을 확보할 수 있음
• 확장성과 유지보수성이 뛰어나고, 명확한 책임 분리가 가능
• 다양한 UI나 인프라 변경에도 도메인 로직이 영향을 받지 않음

---

🧠 어려웠던 점 & 해결 방법

❗ 가장 어려웠던 점

• 처음에는 클린 아키텍처의 구조 자체가 모호하게 느껴졌습니다.
  각 레이어가 어디까지 책임져야 하는지, 어떤 방향으로 의존성이 향해야 하는지 혼란스러웠습니다.

✅ 해결 전략

• 핵심 원칙인 의존성 역전(Dependency Inversion Principle) 을 중심으로 구조를 이해하고 구현했습니다.
• 아키텍처 전반에 걸쳐 의존성의 방향을 도메인 → 인터페이스 → 외부로 유지하려 노력했습니다.

---

🔍 아쉬운 점 & 보완할 부분

• 분명 의존성 역전은 구현했지만, 결과적으로 1:1로 매핑된 인터페이스와 구현체가 많아졌습니다.
  → 실제로 인터페이스의 추상화 역할이 퇴색된 느낌도 들었습니다.
• 파사드 패턴(Facade)에 대한 이해 부족으로, 중간 조율 역할을 해주는 파사드를 적용하지 못했습니다.
  → 몇몇 레이어는 파사드를 활용해 더 깔끔하게 연결할 수 있었을 것으로 생각합니다.
• 전체 구조가 다소 복잡해졌고, 오히려 개발 생산성이 떨어진 부분도 있음.
  → 이후에는 복잡성과 실용성 사이의 균형에 대해 고민해봐야 할 것 같습니다.

---

👨‍💻 팀 코드리뷰 소회

• 팀원들의 구조와 설계를 보며 같은 클린 아키텍처를 선택해도 구현 방식이 다양하다는 점을 체감했습니다.
• 특히, 도메인 설계와 추상화 정도에서 차이가 났는데, 이를 통해 제 코드가 과하게 복잡했는지 돌아보게 됐습니다.
• 다른 사람의 설계를 보며 실용적이고 간결한 방식의 장점도 배울 수 있었습니다.

---

 ✅ 한 줄 회고

“클린 아키텍처의 핵심은 구조가 아니라 방향성과 책임 분리에 있다는 것을 깨달은 한 주였다.”