항해99 플러스 백엔드 2주차 WIL - 클린아키텍처와 동시성

1주차 발제에서는 TDD와 동시성이 주제였는데, TDD는 이제 기본으로 깔고 들어가야 한다.

이번 주차에서는 클린 아키텍처와 동시성이다.

저번 주차의 동시성은 단일 인스턴스라는 가정하에, DB 없이 락을 구현하는게 과제였다면, 이번 주차는 DB락을 걸어야 했다.

자세한 발제 내용은 다음과 같다.

토요일 3시, 발제 시간에 허재 코치님께서 클린 아키텍처에 대해 설명해 주셨다.

Layered Architecture

Layered Architecture의 단방향 하위참조 흐름

Layered Architecture는 상위 계층이 하위 계층을 호출하는 단방향 흐름을 유지해야 한다.

상위 계층은 하위 계층에 직접 의존하며, 이를 통해 필요한 기능을 수행한다.

예를 들어 Business Layer가 Persistence Layer를 호출하여 데이터를 조회하거나 저장할 수 있다.

이 구조에서는 상위 계층이 하위 계층을 호출하면서 필요에 따라 하위 계층의 구현에 의존하게 된다.

따라서 하위 계층이 변경되면 상위 계층에 영향을 미칠 가능성이 높다.

또 다른 예시를 든다면 데이터베이스의 기술 스택을 변경하면 영속성 레이어의 구현이 바뀔 수 있으며, 이로 인해 상위 계층에서도 변경이 필요할 수 있다.

Layered Architecture의 의존성 문제(DIP), OCP와의 연관성

Layered Architecture에서 상위 계층이 하위 계층에 의존하는 방식은 DIP(의존성 역전 원칙) 위반을 야기할 수 있다.

DIP에서는 상위 계층이 하위 계층의 구체적인 구현에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다.

즉, 상위 계층은 하위 계층의 구체적인 클래스가 아닌 인터페이스나 추상 클래스를 통해서만 하위 계층과 상호작용해야 한다.

하지만 Layered Architecture에서는 상위 계층이 종종 하위 계층의 구체적인 구현에 직접 의존한다. 예를 들어, Business Layer가 Persistence Layer의 구체적인 클래스에 의존할 경우, 하위 계층의 구현을 변경하면 상위 계층의 코드도 변경해야 하는 문제가 발생할 수 있다. 이런 상황은 DIP 원칙을 위반하며, 시스템의 결합도를 높여 확장성과 유지보수성을 저하시킬 수 있다.

그리고, OCP와의 연관성에 대해 설명하자면 OCP는 일단 개방-폐쇄 원칙은 "확장에는 열려 있고, 변경에는 닫혀 있어야 한다"는 SOLID의 마지막 원칙이다.

즉, 새로운 기능을 추가할 때 기존의 코드를 변경하지 않고도 확장할 수 있어야 한다는 원칙이다.

Layered Architecture에서 OCP를 적용하지 못하는 문제는 하위 계층의 변경이 상위 계층에 영향을 주기 때문에 발생한다.

상위 계층이 하위 계층의 구체적인 구현에 의존하면, 하위 계층의 변경이 있을 때마다 상위 계층의 코드도 변경되어야 할 수 있다.

이는 시스템이 새로운 요구 사항을 처리하기 위해 확장되는 경우에도 기존 코드를 변경해야 하는 문제가 발생하게 되고, 이는 OCP를 위반하는 구조이다.

단순히 하위참조만 따르게 된다면 아래와 같은 이상한 코드가 만들어지게 된다. 확장에 매우 닫혀있는 코드. 의존성 역전이 안되는 코드.

// Persistence Layer - 구체적인 구현
public class SpecialLectureRepository {
    public void register(Long studentId, Long lectureId) {
        // DB에 저장하는 로직
        System.out.println("특강 신청: 학생 " + studentId + "이(가) 강좌 " + lectureId + "에 신청했습니다.");
    }
}

// Business Layer - Persistence Layer의 구체적인 구현에 의존
public class SpecialLectureService {
    private final SpecialLectureRepository specialLectureRepository;

    public SpecialLectureService() {
        this.specialLectureRepository = new SpecialLectureRepository(); // DIP 위반
    }

    public void registerLecture(Long studentId, Long lectureId) {
        specialLectureRepository.register(studentId, lectureId);
    }
}

비즈니스 로직 보호의 문제

Layered Architecture에서 비즈니스 로직이 제대로 보호되지 않을 수 있다.

Layered Architecture는 전통적으로 비즈니스 로직을 애플리케이션 레이어 또는 도메인 레이어에 포함시킨다.

하지만, 이 비즈니스 로직은 하위 계층에 의존하게 되어 하위 계층의 변경이 상위 계층에 영향을 미칠 수 있다.

따라서 비즈니스 로직이 핵심적인 부분임에도 불구하고 보호받지 못하는 상황이 발생할 수 있다.

이 문제는 DIP 원칙을 적용하여 해결할 수 있지만, OCP를 적용하지 못한다면 비즈니스 로직을 확장하는 과정에서도 기존 코드를 변경해야 할 가능성이 크다. 이는 장기적으로 시스템의 유지보수성과 확장성에 문제를 일으킬 수 있다.

DIP를 적용할 수 있지만, OCP를 적용하지 못하는 이유

Layered Architecture에서 DIP는 어느 정도 적용할 수 있다. 상위 계층이 하위 계층에 의존하는 대신 인터페이스나 추상 클래스를 사용하여 상호작용하도록 구조를 개선할 수 있다. 즉, 상위 계층이 하위 계층의 구체적인 구현이 아닌 추상화된 계약(인터페이스)에 의존하게 함으로써 DIP를 적용할 수 있다.

그러나 OCP는 적용하기 어렵다. OCP는 "기존 코드를 변경하지 않고도 시스템을 확장할 수 있어야 한다"는 원칙인데, Layered Architecture에서는 하위 계층의 변경이 상위 계층에 영향을 줄 수 있기 때문에 하위 계층의 확장이 상위 계층의 변경을 유발할 가능성이 크다. 이로 인해 Layered Architecture는 OCP를 완전히 충족하지 못하는 경우가 많다.

예를 들어, 새로운 저장소 기술을 도입하거나 기존의 데이터 저장 방식을 변경해야 할 때, 하위 계층(영속성 레이어)에서 변화가 일어나면 그에 의존하는 상위 계층(비즈니스 로직)이 영향을 받을 수밖에 없다.

이를 피하기 위해 DIP를 적용하고 인터페이스를 통해 의존성을 낮출 수는 있지만, 하위 계층에서 큰 변화가 일어나면 상위 계층의 로직도 어쩔 수 없이 수정될 수 있다. 이는 OCP를 적용하는 데 어려움을 준다.

Layered Architecture 개선 방안

Layered Architecture에서 DIP와 OCP의 단점을 보완하려면 다음과 같은 접근 방식을 고려해보아야 한다.

첫 번째로는 DIP를 철저히 준수하는 것이다. 고수준 모듈이 저수준 모듈의 구체적인 구현에 의존하지 않도록, 모든 레이어에서 인터페이스나 추상화를 적극적으로 사용한다. 이를 통해 하위 계층의 변경이 상위 계층에 미치는 영향을 최소화할 수 있다.

두 번째로는 도메인 주도 설계(Domain-Driven-Design)로 개발하는 것이다. 비즈니스 로직이 더 잘 보호되고 핵심적으로 작동할 수 있도록 도메인 계층을 강화하고, 외부 기술에 의존하지 않도록 분리한다.

이는 비즈니스 로직을 보호하고 시스템의 유연성을 유지하는 데 도움이 된다.

Clean Architecture

Clean Architecture는 비즈니스 로직을 외부 시스템으로부터 보호하고, 유연성과 유지보수성을 높이기 위한 소프트웨어 아키텍처 패턴이다. Robert C. Martin(언클 밥)이 제안한 이 아키텍처는, 도메인 중심으로 계층을 나누고, 각 계층 간의 의존성을 안쪽으로 흐르게 하는 것이 특징이다.

Clean Architecture 핵심 개념과 주요 원칙

Entities(엔터티): 비즈니스 도메인 모델을 정의하며, 애플리케이션의 핵심 규칙을 포함한다.

Use Cases(유스케이스): 애플리케이션의 비즈니스 로직을 실행하며, 외부 시스템과의 상호작용을 정의한다.

Interface Adapters(인터페이스 어댑터): 외부 시스템과 비즈니스 로직을 연결하는 계층으로, 데이터 변환과 상호작용을 담당한다.

Frameworks & Drivers(프레임워크와 드라이버): 외부 기술(웹, 데이터베이스, UI 등)과 상호작용하는 계층이다. 애플리케이션에서 가장 바깥에 위치한다.

주요 원칙으로는 아래와 같다.

의존성 역전 원칙(DIP): 외부 계층이 내부 비즈니스 로직에 의존하며, 비즈니스 로직은 외부 시스템에 의존하지 않는다. 모든 의존성은 안쪽으로만 향한다.

개방-폐쇄 원칙(OCP): 시스템을 확장할 때 기존 코드를 변경하지 않고도 확장이 가능하다. 비즈니스 로직은 고정된 상태로 유지된다.

Clean Architecture 장점

비즈니스 로직 보호: 비즈니스 로직이 외부 시스템으로부터 독립적이므로 유지보수가 용이하다.

확장성: 외부 시스템(데이터베이스, UI, API 등)을 변경하거나 추가할 때, 비즈니스 로직에 영향을 미치지 않고 확장할 수 있다.

테스트 용이성: 외부 시스템을 모킹(Mock)하여 비즈니스 로직을 독립적으로 테스트할 수 있다.

결론적으로, 클린 아키텍처는 변화하는 요구사항에 민첩하게 대응하면서, 핵심 비즈니스 로직을 보호하고 시스템을 유지보수하기 쉽게 설계된 아키텍처 패턴이다.

그래서 나타난 Clean + Layered Architecture

Layered Architecture의 개선 방안에서, DIP를 철저히 준수하며, DDD를 강조하는 구조이다.

이 구조는 비즈니스 로직(도메인)이 시스템의 중심에 있고, 나머지 레이어들이 이 비즈니스 로직을 지원하는 방식으로 이루어져 있다.

이를 이해하기 위해 각 레이어와 관련된 아키텍처 원칙들이 어떻게 적용되는지 알아보자.

도메인 중심 아키텍처

이 구조에서 비즈니스 로직은 애플리케이션의 중심에 위치한다. 즉, 시스템의 핵심적인 부분인 비즈니스 로직이 가장 중요한 위치를 차지하며, 다른 모든 레이어는 이 비즈니스 로직을 지원하는 역할을 한다.

도메인 주도 설계에 기반한 레이어드 아키텍처는 다음과 같은 특징을 가진다.

도메인 계층(비즈니스 로직) : 비즈니스 규칙, 규정, 엔티티, 도메인 서비스가 위치하는 곳으로, 어플리케이션의 핵심 기능이 여기서 구현된다.

프레젠테이션 계층(Presentation Layer) : 사용자 인터페이스, API 등이 포함되며, 사용자가 시스템과 상호작용하는 방식이다. 이 레이어는 단순히 도메인 계층의 로직을 외부에 노출하는 역할을 한다.

데이터소스 계층(Data Source layer) : 패키지 구조로 따졌을때, Infra부분에 해당하는, 데이터베이스나 외부 API와 상호작용하는 레이어이다. 데이터를 읽고 쓰는 작업을 수행하며, 도메인 계층의 요구에 따라 데이터를 제공하는 역할을 하면서 도메인에 의존하는 구조로 설계뙨다.

계층 간 의존성

이러한 Clean + Layered Architecture 구조에서 프레젠테이션 레이어와 데이터소스 레이어는 모두 비즈니스 로직(도메인 계층)에 의존하고 있다.

이를 통해 시스템이 비즈니스 로직을 중심으로 설계되었으며, 다른 레이어들은 비즈니스 로직을 보호하고 지원한다는 역할을 한다는 점이 분명히 드러난다.

프레젠테이션 레이어는 도메인의 인터페이스를 활용하여 사용자에게 결과를 제공한다. 이 레이어는 비즈니스 로직의 구체적인 구현을 알 필요 없이, 도메인에서 제공하는 인터페이스를 통해 결과를 얻는다.

데이터소스 레이어는 도메인 계층이 필요로 하는 데이터를 제공하는 역할을 한다. 이 역시 도메인 인터페이스를 사용하여 데이터에 접근하거나 저장한다. 데이터소스 레이어는 도메인 계층의 비즈니스 요구 사항에 따라 데이터를 처리한다.

DIP(의존성 역전 원칙)의 완벽한 적용과 적용 가능한 OCP

이 구조에서는 DIP가 완벽하게 적용된다. 의존성 역전 원칙에 대해 다시 설명하자면, 상위 모듈(비즈니스 로직)이 하위 모듈(DB, 외부시스템)의 구체적인 구현에 의존하지 않도록 하는 원칙이다. 대신, 양쪽 모두가 추상화된 인터페이스에 의존하게 된다.

비즈니스 로직(도메인 계층)은 하위 레이어(프레젠테이션, 데이터소스) 의 구체적인 구현에 의존하지 않고, 오로지 인터페이스에 의존한다.

예를 들어, 비즈니스 로직은 데이터베이스와 직접 상호작용하는 것이 아니라, 레포지토리 인터페이스를 통해 데이터를 조회하고 저장한다. 실제 데이터베이스 접근은 구현 클래스(RepositoryImpl)에서 처리된다.

하위 레이어(프레젠테이션, 데이터소스)는 도메인이 제공하는 인터페이스를 사용하여 비즈니스 로직과 상호작용한다. 이를 통해 구체적인 구현체와의 결합도를 낮출 수 있다.

DIP가 적용되면, 데이터베이스나 프레젠테이션 레이어의 변경은 비즈니스 로직에 영향을 미치지 않으며, 상위 레이어는 하위 레이어의 구체적인 변경 사항에 민감하지 않게 된다. 이는 시스템의 유연성과 확장성을 크게 높인다.

OCP는 확장에는 열려있고, 수정에는 닫혀있어야 한다는 원칙으로, 새로운 기능을 추가할 때 기존 코드를 변경하지 않고 확장할 수 있어야 한다는 의미이다.

프레젠테이션 레이어는 새로운 API나 사용자 인터페이스가 추가되더라도, 비즈니스 로직을 수정할 필요 없이 확장 가능하다. 새로운 프레젠테이션 요소는 도메인 계층의 인터페이스를 그대로 사용하면 되기 때문에, 비즈니스 로직은 변경되지 않는다.

데이터소스 레이어도 마찬가지이다. 예를 들어, 기존에 Mysql을 사용하다가 PostgreSQL로 데이터베이스를 변경할 경우, 비즈니스 로직(도메인 계층)은 수정할 필요가 없다. 단지 새로운 데이터베이스에 대한 어댑터(PsqlRepositoryImpl)을 추가하면 된다. 즉, 비즈니스 로직을 변경하지 않고도 시스템을 확장할 수 있다.

OCP가 잘 적용된 시스템은 새로운 요구 사항이 들어오더라도 기존 코드의 변경을 최소화할 수 있으므로, 코드의 안정성을 유지하면서 기능을 추가할 수 있다.

// 도메인 계층 인터페이스 - 특강 신청 로직
public interface SpecialLectureRegistration {
    void register(Long studentId, Long lectureId);
}

// 유스케이스 - 인터페이스를 사용하여 비즈니스 로직을 호출
@Service
public class SpecialLectureService implements SpecialLectureRegistration {
    private final SpecialLectureRepository specialLectureRepository;

    // 비즈니스 로직이 오로지 인터페이스에 의존함
    public SpecialLectureService(SpecialLectureRepository specialLectureRepository) {
        this.specialLectureRepository = specialLectureRepository;
    }

    @Override
    @Transactional
    public void register(Long studentId, Long lectureId) {
        // 특강 신청 로직 구현
        specialLectureRepository.register(studentId, lectureId);
    }
}

// 데이터소스 계층 인터페이스 - DIP 적용
public interface SpecialLectureRepository {
    void register(Long studentId, Long lectureId);
}


// JPA를 통한 DB 저장소 구현 (데이터소스 레이어)
@Repository
public class JpaSpecialLectureRepository implements SpecialLectureRepository {
    @Override
    public void register(Long studentId, Long lectureId) {
        // 실제로 DB에 특강 신청을 저장하는 로직
        System.out.println("JPA: 학생 " + studentId + "이(가) 강좌 " + lectureId + "에 신청되었습니다.");
    }
}

// 파일 시스템을 통한 저장소 구현 (다른 데이터소스)
@Repository
public class FileSpecialLectureRepository implements SpecialLectureRepository {
    @Override
    public void register(Long studentId, Long lectureId) {
        // 파일 시스템에 특강 신청을 저장하는 로직
        System.out.println("파일 시스템: 학생 " + studentId + "이(가) 강좌 " + lectureId + "에 신청되었습니다.");
    }
}

테스트 용이성

장점을 쭉 나열해보려고 했는데, 위에서 설명한 것들이라 부가적인 장점으로 테스트 용이성이 있다.

각 계층이 독립적으로 설계되었기 때문에, 도메인 로직을 독립적으로 테스트할 수 있다. 또한 외부 시스템에 의존하지 않고, 비즈니스 로직을 테스트할 수 있으므로, 테스트 환경에서 어댑터를 쉽게 모킹(Mocking)하여 테스트할 수 있다.

장점만 있는 것이 아니다

모든 레이어에서 인터페이스를 사용하고 의존성을 추상화하다 보면 시스템이 매우 복잡해질 수 있다. 특히, 작은 애플리케이션에서는 과도한 인터페이스 사용이 오히려 코드의 복잡성을 높이는 요인이 될 수 있기 때문이다.

또한, 각 계층 간의 호출이 일어날 때마다 성능 오버헤드가 발생할 수 있다. 특히 대규모 시스템에서 이 점을 고려하여 최적화가 필요하다.

Hexagonal Architecture

Hexagonal Architecture는 비즈니스 로직과 외부 시스템 간의 의존성을 분리하여 시스템을 더 유연하고 유지보수하기 쉽게 만드는 아키텍처 패턴이다. 포트와 어댑터 아키텍처(Ports and Adapters Architecture)라고도 불린다.

이에 대해 과제를 수행하지는 않아, 요약하여 정리해 보면 아래와 같다.

Hexagonal Architecture의 핵심 개념과 주요 원칙

코어(비즈니스 로직): 애플리케이션의 핵심 기능을 담당하며, 외부 기술에 의존하지 않는다.

포트(Ports): 코어와 외부 시스템 간의 상호작용을 정의하는 인터페이스이다. 입력 포트와 출력 포트로 나뉜다.

어댑터(Adapters): 포트를 구현하여 실제로 외부 시스템과 상호작용하는 구체적인 구현체이다. 예를 들어, 데이터베이스, 사용자 인터페이스, 외부 API 등이 어댑터에 해당한다.

주요 원칙으로는 아래와 같다.

비즈니스 로직 보호: 외부 시스템과 비즈니스 로직을 완전히 분리하여, 기술 변화가 비즈니스 로직에 영향을 미치지 않도록 한다.의존성 역전 원칙(DIP): 비즈니스 로직은 외부 시스템의 구체적인 구현에 의존하지 않으며, 포트를 통해 상호작용한다.

Hexagonal Architecture의 장점

유연성: 외부 시스템이나 기술이 변경되어도 비즈니스 로직에 영향을 주지 않는다. 어댑터만 수정하면 다양한 외부 시스템과 연동할 수 있다.테스트 용이성: 어댑터를 모킹하여 비즈니스 로직을 독립적으로 테스트할 수 있다.

확장성: 새로운 기능이나 외부 시스템을 추가할 때, 비즈니스 로직을 수정하지 않고 어댑터를 추가하여 확장할 수 있다.

결론적으로, 헥사고날 아키텍처는 비즈니스 로직을 외부 시스템으로부터 보호하면서 시스템을 더 유연하고 테스트하기 쉽게 만들어 주는 아키텍처 패턴이다.

아키텍처 정리 비교표

특징	Layered	Clean	Clean+Layered	Hexagonal
비즈니스 로직 보호	외부 의존성에 영향을 받을 수 있음	외부 시스템에 의존하지 않음	Clean Architecture의 원칙을 따르므로 비즈니스 로직 보호 가능	비즈니스 로직을 완전히 외부로부터 독립시킴
의존성 흐름	상위 계층이 하위 계층을 호출하는 단방향 흐름	의존성은 항상 안쪽으로만 흐름	Clean의 흐름을 따르며 Layered 구조의 장점도 결합	비즈니스 로직이 포트와 어댑터를 통해 상호작용하며, 의존성은 안쪽으로만
확장성	하위 계층 변경 시 상위 계층에 영향	기존 코드를 수정하지 않고 확장 가능	Clean의 OCP 원칙을 따르며, Layered의 구조적 단순함을 유지	외부 시스템 변경 시 어댑터만 교체하면 되므로 매우 유연함
테스트 용이성	계층 간 결합도가 높아 일부 복잡할 수 있음	외부 시스템 모킹으로 비즈니스 로직을 독립적으로 테스트 가능	Clean 원칙을 따르므로 테스트 용이	포트와 어댑터 구조로 비즈니스 로직을 독립적으로 테스트 가능
기술 의존성	각 계층이 구체적인 구현에 의존할 수 있음	기술 의존성이 없으며, 오직 비즈니스 로직에만 집중	Clean의 원칙을 따르지만 Layered의 구조적 편리함을 제공	외부 기술에 의존하지 않으며, 어댑터를 통해 다양한 기술과 연동 가능
구현 난이도	비교적 단순하며 직관적인 구조	설계에 더 많은 추상화가 필요하므로 구현 복잡도가 높음	Layered의 직관성과 Clean의 추상화를 적절히 결합하여 난이도 적정	포트와 어댑터 설계가 필요하므로 설계 복잡도가 다소 높음

결론

이번 과제에서는 Clean+Layered Architecture를 적용하여 시스템을 설계하였다.

Layered Architecture의 직관적인 계층 구조와 Clean Architecture의 의존성 관리 원칙을 결합함으로써 유지보수성과 확장성을 높이는 데 중점을 두었다.

특히, 퍼사드 패턴을 적용하여 퍼사드는 application 계층에, 서비스는 domain 계층에 배치하였다. 퍼사드 패턴을 통해 클라이언트는 복잡한 비즈니스 로직을 쉽게 호출할 수 있었고, 애플리케이션 계층과 도메인 계층 간의 결합도를 낮추었다.

또한, 계층 간 데이터 이동의 책임 분리를 위해 다음과 같은 구조를 적용하였다:

• Request: interface 계층에서 클라이언트의 요청을 처리
• Criteria: application 계층에서 비즈니스 요구사항을 필터링
• Command: domain 계층에서 핵심 비즈니스 로직을 실행
• parameter: infra 계층에서 데이터베이스나 외부 시스템과의 상호작용
• Entity: infra 계층에서 영속성을 가진 객체 관리
• Info: domain 계층에서 도메인 관련 정보 전달
• Result: application 계층에서 처리된 결과 전달
• Response: interface 계층에서 클라이언트에게 응답

이러한 구조를 통해 각 계층의 책임이 명확해지고, 데이터 이동이 깔끔하게 분리되었다. 이로 인해 시스템의 유지보수성이 더욱 향상되었으며, 새로운 요구사항이 추가되더라도 각 계층에 맞는 적절한 변경만 이루어지도록 설계하였다.

결론적으로, 이번 과제에서 Clean+Layered Architecture는 비즈니스 로직 보호, 유연한 확장성, 테스트 용이성을 모두 충족할 수 있었으며, 퍼사드 패턴과 계층 간 데이터 이동의 책임 분리를 통해 복잡성을 최소화하고 가독성을 높여보았다.

하지만, 이러한 책임 분리에 데이터 변환 메서드의 위치가 너무 헷갈렸다. 자칫하면 참조 흐름이 꼬여버릴 수 있기 때문이다..

이곳저곳에서 찾아본 결과, Clean+Layered Architecture에서의 데이터 변환 메서드는, ModelMapper같이 데이터 변환 컴포넌트를 하나 만들어, application 계층에 위치시켜 주입받아 사용하는게 올바른 판단이었던것 같다.

추가로 서비스도 인터페이스로 만들었어야 하는게 아닌가 싶다.. (제출하고 나니 잘못된 점이 너무 잘 보인다..)

다음 과제부터는 이를 반영하여 짜보아야 겠다.

그리고, 과제의 동시성 관련 부분에서는 비관적 잠금(PESSIMISTIC LOCK)을 사용하였다.

public interface LectureRepository extends JpaRepository<Lecture, Long> {

    // Pessimistic Lock을 사용하여 데이터를 조회
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    Optional<Lecture> findByIdWithLock(@Param("id") Long id);
}

뭐 이런식으로 짰는데 내 코드는 아니다.

항해99 회고

1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)

이번 주차를 지나며 겪었던 문제가 무엇이었나요?
클린아키텍처, DIP에 대한 개념이 부족했었다.

2. 시도

문제를 해결하기 위해 어떤 시도를 하셨나요?
GPT 나무위키, 블로그 등 여러 레퍼런스를 참조했다. 똥글도 많았지만 어느정도 개념은 잡힌 것 같다.

3. 해결

문제를 어떻게 해결하셨나요?
팀원과 소통하며 지식공유를 하고, 멘토링을 통해 개념을 확립했다.

4. 알게된 것

문제를 해결하기 위해 시도하며 새롭게 알게된 것은 무엇인가요?
데이터 전송의 책임분리.

---

Keep : 현재 만족하고 계속 유지할 부분

이번 주를 마무리 하며 나에게 만족했던 부분은 무엇인가요?
여러모로 다 만족

Problem : 개선이 필요하다고 생각하는 문제점

이번 주를 마무리 하며 개선이 필요하다고 생각했던 문제점은 무엇인가요?
P1. 클린아키텍처 개념확립

Try : 문제점을 해결하기 위해 시도해야 할 것

이 문제점을 해결하기 위해 다음 한 주간 시도 할 것은 무엇인가요?

P1. 클린아키텍처 공부