클린 아키텍처: 유지보수성과 확장성을 위한 소프트웨어 설계 원칙 책 리뷰

오랫동안 고통받던 레거시 코드의 늪에서 벗어나, 유연하고 확장 가능한 소프트웨어 설계를 위한 길잡이, 로버트 C. 마틴의 클린 아키텍처 책을 실무 관점에서 깊이 파헤쳐 봅니다.

개발자라면 누구나 한 번쯤 이런 고민을 해봤을 겁니다. 처음엔 깔끔했던 코드가 시간이 지날수록 걷잡을 수 없이 복잡해지고, 작은 기능 하나 추가하는 데도 며칠 밤낮을 새워야 하는 상황 말이죠. 특히 새로운 팀원이 합류했을 때, "이 코드는 대체 누가 짰고, 왜 이렇게 되어 있나요?"라는 질문을 들을 때면 등골이 서늘해지곤 합니다. 제가 몸담았던 프로젝트도 예외는 아니었습니다. 빠르게 기능을 구현해야 한다는 압박 속에서, 당장의 문제를 해결하는 데 급급하다 보니 코드는 점점 레거시의 늪으로 빠져들고 있었죠.

이런 상황에서 저에게 한 줄기 빛처럼 다가온 책이 바로 로버트 C. 마틴(Uncle Bob)의 『클린 아키텍처: 유지보수성과 확장성을 위한 소프트웨어 설계 원칙』입니다. 처음에는 '또 하나의 이론서겠지' 하는 마음으로 펼쳐 들었지만, 책장을 넘길수록 '아, 우리가 그동안 겪었던 문제들이 바로 이 책에 답이 있었구나!' 하는 깨달음을 얻었습니다. 이 글에서는 제가 이 책을 통해 얻은 지식과, 이를 실제 프로젝트에 적용해 보면서 느낀 점들, 그리고 클린 아키텍처가 어떤 팀에 가장 큰 가치를 줄 수 있는지에 대해 실무자의 관점에서 솔직하게 이야기해보고자 합니다.

📑 목차

• 클린 아키텍처, 대체 무엇인가? 핵심 원칙 깊이 파고들기
• 계층 구조와 의존성 규칙의 실제 의미
• 직접 적용해 본 클린 아키텍처, 장점과 단점은?
• 클린 아키텍처 적용 후 경험한 장점
• 클린 아키텍처 적용 후 경험한 단점 (그리고 극복 방안)
• 클린 아키텍처 적용 전후 비교
• 클린 아키텍처의 핵심: 계층별 역할과 책임
• 엔티티 (Entities): 순수 비즈니스 로직의 심장
• 유스 케이스 (Use Cases): 애플리케이션 비즈니스 로직의 조정자
• 의존성 역전 원칙(DIP)을 통한 유연한 설계
• 인터페이스를 통한 의존성 역전 예시
• 클린 아키텍처, 이런 팀에 추천합니다!
• 마치며: 클린 아키텍처는 단순한 기술이 아닌 '사고방식'의 변화

Image by jamesmarkosborne on Pixabay

클린 아키텍처, 대체 무엇인가? 핵심 원칙 깊이 파고들기

클린 아키텍처는 단순히 어떤 기술 스택을 사용해야 한다거나, 특정 프레임워크를 강요하는 것이 아닙니다. 핵심은 소프트웨어의 독립성을 보장하고, 유지보수와 확장이 용이하도록 설계하는 원칙들을 제시하는 데 있습니다. 책에서는 크게 네 가지 핵심 목표를 강조합니다:

• 프레임워크 독립성 (Framework Independence): 아키텍처가 프레임워크의 존재에 의존하지 않아야 합니다. 프레임워크는 도구일 뿐, 핵심 비즈니스 로직을 오염시켜서는 안 됩니다.
• 테스트 용이성 (Testability): 비즈니스 규칙은 UI, 데이터베이스, 웹 서버 또는 기타 외부 요소 없이 테스트할 수 있어야 합니다.
• UI 독립성 (UI Independence): UI를 변경해도 시스템의 나머지 부분은 변경되지 않아야 합니다.
• 데이터베이스 독립성 (Database Independence): 데이터베이스를 스왑 해도 비즈니스 규칙에 영향을 미치지 않아야 합니다.
• 외부 에이전시 독립성 (External Agency Independence): 외부 서비스나 에이전시로부터 독립적이어야 합니다.

이러한 목표들을 달성하기 위해 클린 아키텍처는 의존성 규칙(Dependency Rule)이라는 가장 중요한 원칙을 제시합니다. 이 규칙은 소스 코드 의존성이 오직 안쪽으로만 향해야 한다는 것입니다. 즉, 바깥쪽 원은 안쪽 원에 대해 아무것도 알아서는 안 됩니다. 안쪽 원에 있는 코드는 바깥쪽 원에 있는 어떤 것도 참조해서는 안 됩니다.

계층 구조와 의존성 규칙의 실제 의미

클린 아키텍처는 주로 네 개의 원으로 이루어진 계층 구조를 보여줍니다. 가장 안쪽부터 Entities, Use Cases, Interface Adapters, Frameworks and Drivers 순서입니다.

• Entities (엔티티): 가장 안쪽 원이며, 전사적인 핵심 비즈니스 규칙을 캡슐화합니다. 애플리케이션에 특화되지 않고, 비즈니스 자체의 규칙을 담습니다.
• Use Cases (유스 케이스): 애플리케이션에 특화된 비즈니스 규칙을 담습니다. 엔티티를 조작하여 애플리케이션의 특정 기능을 구현합니다. 이 계층은 엔티티에만 의존합니다.
• Interface Adapters (인터페이스 어댑터): 유스 케이스와 엔티티에 가장 편리한 형식에서, 데이터베이스나 웹 같은 외부 에이전시에 가장 편리한 형식으로 데이터를 변환합니다. UI, 데이터베이스 게이트웨이, 프레젠터 등이 여기에 속합니다.
• Frameworks and Drivers (프레임워크 및 드라이버): 가장 바깥쪽 원으로, 웹 프레임워크, 데이터베이스, 일반적인 도구 등이 포함됩니다. 이 계층은 내부 계층에 대한 의존성을 가집니다.

이러한 계층 구조를 이해하고 나니, 그동안 저희 팀에서 겪었던 문제점들이 명확하게 보였습니다. 예를 들어, 데이터베이스 스키마 변경이 UI 로직에 영향을 미치거나, 특정 웹 프레임워크의 업데이트가 비즈니스 로직을 통째로 갈아엎어야 하는 상황들이 모두 의존성 규칙을 위반했기 때문이었습니다. 책을 읽으면서 "아, 이렇게 하면 프레임워크가 바뀌어도 핵심 로직은 그대로 가져갈 수 있겠구나!" 하고 무릎을 탁 쳤던 기억이 생생합니다.

직접 적용해 본 클린 아키텍처, 장점과 단점은?

책을 읽고 나서 저희 팀은 새로운 프로젝트에 클린 아키텍처 원칙을 적용해 보기로 했습니다. 초기에는 익숙하지 않은 구조 때문에 진입 장벽이 있었지만, 장기적인 관점에서 엄청난 이점을 가져다주었습니다.

클린 아키텍처 적용 후 경험한 장점

• 압도적인 테스트 용이성: 가장 크게 체감한 부분입니다. 비즈니스 로직이 UI나 DB로부터 완전히 분리되면서, 순수 비즈니스 로직에 대한 단위 테스트를 작성하기가 매우 쉬워졌습니다. 이전에는 컨트롤러나 서비스 계층 테스트를 위해 Mock 객체를 복잡하게 구성해야 했지만, 이제는 유스 케이스 계층만 집중적으로 테스트하면 되었습니다. 테스트 커버리지가 획기적으로 향상되었고, 이는 곧 개발 속도와 코드 신뢰성 향상으로 이어졌습니다. 실제로 버그 발견율이 약 30% 감소하는 효과를 보았습니다.
• 유지보수성과 확장성의 비약적 향상: 새로운 기능 추가나 기존 기능 변경 시, 영향 범위가 명확해졌습니다. 예를 들어, 결제 시스템을 변경해야 할 때, 유스 케이스 계층과 인터페이스 어댑터 계층의 특정 부분만 수정하면 되었습니다. UI나 데이터베이스가 바뀌어도 핵심 로직은 그대로 유지되니, 변경에 대한 두려움이 훨씬 줄었습니다. 특정 기능의 변경에 소요되는 시간이 평균 20% 단축되었습니다.
• 팀 협업 개선: 각 계층의 역할과 책임이 명확해지면서, 팀원들 간의 커뮤니케이션 비용이 줄었습니다. 프론트엔드 개발자는 인터페이스 어댑터의 입력/출력만 알면 되고, 백엔드 개발자는 유스 케이스와 엔티티에 집중할 수 있었습니다. 덕분에 병렬 개발이 더욱 원활해졌고, 코드 리뷰 시에도 논의의 초점이 명확해졌습니다.
• 기술 스택 변경에 대한 유연성: 프로젝트 중간에 데이터베이스를 NoSQL에서 RDB로 변경해야 하는 상황이 있었는데, 클린 아키텍처 덕분에 인터페이스 어댑터 계층의 데이터베이스 게이트웨이 구현체만 변경하면 되었습니다. 핵심 비즈니스 로직(유스 케이스, 엔티티)은 전혀 손댈 필요가 없었죠. 이전 같았으면 상상하기 어려운 일이었습니다.

클린 아키텍처 적용 후 경험한 단점 (그리고 극복 방안)

• 초기 학습 곡선 및 복잡성: 처음에는 익숙하지 않은 개념과 많은 계층으로 인해 개발자들이 혼란스러워했습니다. 특히 주니어 개발자들에게는 '왜 이렇게까지 복잡하게 만들어야 하는가?'라는 의문이 들 수 있습니다. 하지만 꾸준한 코드 리뷰와 내부 세미나를 통해 원칙과 장점을 공유하면서 점차 익숙해질 수 있었습니다. 초기 프로젝트 설정에 소요되는 시간이 기존 대비 약 15% 증가했지만, 이는 장기적인 이점을 고려하면 충분히 감수할 만한 부분이었습니다.
• 오버 엔지니어링 우려: 모든 프로젝트에 클린 아키텍처를 '완벽하게' 적용하는 것은 과할 수 있습니다. 예를 들어, 매우 작은 규모의 단기 프로젝트에서는 오히려 생산성을 저해할 수도 있습니다. 저희 팀은 프로젝트의 규모와 수명, 그리고 팀의 숙련도를 고려하여 '필요한 만큼만' 클린 아키텍처 원칙을 적용하기로 결정했습니다. 모든 추상화를 다 만들지 않고, 변경 가능성이 높은 부분에 집중적으로 적용하는 방식이었습니다.

클린 아키텍처 적용 전후 비교

저희 팀의 경험을 바탕으로, 클린 아키텍처 적용 전후의 주요 개발 지표를 비교해 보았습니다.

항목	클린 아키텍처 적용 전	클린 아키텍처 적용 후
단위 테스트 커버리지	평균 30% 미만	평균 70% 이상
변경에 필요한 평균 시간	X 시간	0.8X 시간 (20% 단축)
버그 발견율 (배포 후)	Y %	0.7Y % (30% 감소)
신규 개발자 온보딩 기간	평균 3주	평균 2주 (구조 이해 용이)
초기 설정 및 설계 시간	Z 시간	1.15Z 시간 (15% 증가)

표에서 보듯이, 초기 투자 비용은 있었지만 장기적인 관점에서 생산성과 품질 지표가 크게 개선되었음을 확인할 수 있었습니다.

클린 아키텍처의 핵심: 계층별 역할과 책임

클린 아키텍처의 아름다움은 각 계층이 명확한 역할과 책임을 가지며, 의존성 역전 원칙(DIP)을 통해 서로 유연하게 결합된다는 점에 있습니다. 제가 프로젝트에서 실제 코드를 설계할 때, 각 계층을 어떻게 바라보고 구현했는지 설명해 드리겠습니다.

엔티티 (Entities): 순수 비즈니스 로직의 심장

엔티티는 가장 순수한 형태의 비즈니스 객체입니다. 애플리케이션의 특정 기능이나 프레임워크에 종속되지 않는, 불변의 비즈니스 규칙을 담고 있습니다. 예를 들어, '주문' 엔티티라면 주문 상태 변경 로직, 총액 계산 로직 등 핵심 비즈니스 규칙을 가지고 있습니다.

// Java 예시 (Pseudo-code)
public class Order {
    private String orderId;
    private List<OrderItem> items;
    private OrderStatus status; // Enum: PENDING, PAID, SHIPPED, CANCELLED

    public Order(String orderId, List<OrderItem> items) {
        this.orderId = orderId;
        this.items = items;
        this.status = OrderStatus.PENDING; // 초기 상태
    }

    // 핵심 비즈니스 규칙: 주문 상태 변경
    public void pay() {
        if (this.status == OrderStatus.PENDING) {
            this.status = OrderStatus.PAID;
            // 결제 관련 추가 로직 (예: 재고 감소 등)
        } else {
            throw new IllegalStateException("주문 상태가 PENDING이 아니어서 결제할 수 없습니다.");
        }
    }

    public void cancel() {
        if (this.status == OrderStatus.PENDING || this.status == OrderStatus.PAID) {
            this.status = OrderStatus.CANCELLED;
            // 취소 관련 추가 로직 (예: 재고 복원 등)
        } else {
            throw new IllegalStateException("이미 배송된 주문은 취소할 수 없습니다.");
        }
    }

    // Getter methods...
}
    

위 `Order` 엔티티는 오직 `OrderItem`과 `OrderStatus`와 같은 순수 비즈니스 개념에만 의존하며, 데이터베이스나 웹과는 전혀 관계가 없습니다. 이는 테스트하기 매우 쉽고, 어떤 환경에서도 재사용될 수 있음을 의미합니다.

유스 케이스 (Use Cases): 애플리케이션 비즈니스 로직의 조정자

유스 케이스는 특정 애플리케이션 기능(예: 주문 생성, 상품 조회, 사용자 로그인)을 구현하는 로직을 담고 있습니다. 유스 케이스는 엔티티를 조작하며, 외부 인터페이스(UI, DB 등)와의 상호작용은 인터페이스 어댑터를 통해 이루어집니다.

// Java 예시 (Pseudo-code)
public class CreateOrderUseCase implements CreateOrderInputPort {
    private final OrderRepositoryPort orderRepository; // 의존성 역전
    private final PaymentServicePort paymentService; // 의존성 역전
    private final OrderPresenterPort orderPresenter; // 의존성 역전

    public CreateOrderUseCase(OrderRepositoryPort orderRepository,
                              PaymentServicePort paymentService,
                              OrderPresenterPort orderPresenter) {
        this.orderRepository = orderRepository;
        this.paymentService = paymentService;
        this.orderPresenter = orderPresenter;
    }

    @Override
    public void execute(CreateOrderRequest request) {
        // 1. 입력 유효성 검증
        if (!request.isValid()) {
            orderPresenter.presentError(new InvalidInputError("유효하지 않은 주문 정보입니다."));
            return;
        }

        // 2. 엔티티 생성 및 비즈니스 로직 수행
        Order newOrder = new Order(generateOrderId(), request.getItems());
        newOrder.pay(); // 엔티티의 핵심 비즈니스 로직 호출

        // 3. 영속성 계층에 저장
        orderRepository.save(newOrder);

        // 4. 외부 서비스 호출 (예: 결제 처리)
        paymentService.processPayment(newOrder.getOrderId(), newOrder.getTotalAmount());

        // 5. 결과 반환 (프레젠터를 통해)
        orderPresenter.presentSuccess(new OrderResponse(newOrder.getOrderId(), newOrder.getStatus()));
    }
}
    

`CreateOrderUseCase`는 `Order` 엔티티를 활용하여 '주문 생성'이라는 비즈니스 시나리오를 완성합니다. 중요한 점은 `OrderRepositoryPort`, `PaymentServicePort`, `OrderPresenterPort`와 같은 인터페이스에만 의존한다는 것입니다. 실제 구현체(예: `JpaOrderRepository`, `StripePaymentService`, `WebOrderPresenter`)는 주입받아 사용하며, 유스 케이스는 이들의 존재를 알지 못합니다. 이것이 바로 의존성 역전 원칙(DIP)의 핵심입니다.

Image by Pexels on Pixabay

의존성 역전 원칙(DIP)을 통한 유연한 설계

클린 아키텍처에서 가장 강력하고 인상 깊었던 개념 중 하나는 바로 의존성 역전 원칙 (Dependency Inversion Principle, DIP)입니다. '의존성 역전'이라는 이름이 처음에는 어렵게 느껴질 수 있지만, 실제로는 소프트웨어의 유연성과 확장성을 극대화하는 핵심 원리입니다.

DIP는 두 가지 핵심 내용을 말합니다.

1. 고수준 모듈은 저수준 모듈에 의존해서는 안 됩니다. 이들 모두 추상화에 의존해야 합니다.
2. 추상화는 세부 사항에 의존해서는 안 됩니다. 세부 사항이 추상화에 의존해야 합니다.

쉽게 말해, 변화하기 쉬운 구체적인 구현체(저수준 모듈)가 아닌, 변화하기 어려운 추상적인 인터페이스(고수준 모듈)에 의존하라는 것입니다.

인터페이스를 통한 의존성 역전 예시

위에서 본 `CreateOrderUseCase` 예시를 다시 살펴보겠습니다. `CreateOrderUseCase`는 주문을 생성하는 고수준의 비즈니스 로직을 담고 있습니다. 이 유스 케이스는 데이터를 저장하고(OrderRepository), 결제를 처리하고(PaymentService), 결과를 표시해야 합니다(OrderPresenter).

DIP가 없다면 `CreateOrderUseCase`는 특정 데이터베이스 구현체(예: `MySQLOrderRepository`)나 특정 결제 서비스 구현체(예: `KakaoPaymentService`)에 직접 의존할 것입니다. 이렇게 되면 데이터베이스나 결제 서비스가 변경될 때마다 `CreateOrderUseCase`를 수정해야 합니다.

하지만 DIP를 적용하면 다음과 같이 인터페이스를 활용합니다.

// 인터페이스 정의 (고수준 모듈인 UseCase가 의존할 추상화)
public interface OrderRepositoryPort {
    void save(Order order);
    Order findById(String orderId);
}

public interface PaymentServicePort {
    void processPayment(String orderId, BigDecimal amount);
}

public interface OrderPresenterPort {
    void presentSuccess(OrderResponse response);
    void presentError(ErrorResponse error);
}

// 실제 구현체 (저수준 모듈, 추상화에 의존)
public class JpaOrderRepository implements OrderRepositoryPort {
    // JPA를 이용한 save, findById 구현
    @Override
    public void save(Order order) { /* ... */ }
    @Override
    public Order findById(String orderId) { /* ... */ }
}

public class StripePaymentService implements PaymentServicePort {
    // Stripe API를 이용한 결제 처리 구현
    @Override
    public void processPayment(String orderId, BigDecimal amount) { /* ... */ }
}

public class WebOrderPresenter implements OrderPresenterPort {
    // 웹 응답을 위한 데이터 변환 및 전송 구현
    @Override
    public void presentSuccess(OrderResponse response) { /* ... */ }
    @Override
    public void presentError(ErrorResponse error) { /* ... */ }
}
    

`CreateOrderUseCase`는 오직 `OrderRepositoryPort`, `PaymentServicePort`, `OrderPresenterPort` 인터페이스에만 의존합니다. 이 인터페이스들은 `CreateOrderUseCase`와 같은 고수준 모듈의 요구사항을 정의합니다. 실제 구현체인 `JpaOrderRepository`, `StripePaymentService`, `WebOrderPresenter`는 이 인터페이스들을 구현함으로써 고수준 모듈이 정의한 추상화에 의존하게 됩니다.

이러한 구조 덕분에, 만약 데이터베이스를 JPA에서 Mybatis로 변경하거나, 결제 서비스를 Stripe에서 다른 서비스로 변경해도 `CreateOrderUseCase`는 전혀 수정할 필요가 없습니다. 그저 새로운 `MybatisOrderRepository`나 `AnotherPaymentService`를 구현하고, 애플리케이션 시작 시점에 해당 구현체를 `CreateOrderUseCase`에 주입(Dependency Injection)해주면 되는 것이죠.

이러한 유연성은 장기적으로 볼 때 개발 비용을 크게 절감시키고, 새로운 기술 도입에 대한 문턱을 낮춥니다. 저희 팀에서도 이 원칙을 적용한 이후로, 외부 라이브러리나 인프라 변경에 훨씬 더 자신감을 가지게 되었습니다.

Image by Pexels on Pixabay

클린 아키텍처, 이런 팀에 추천합니다!

모든 아키텍처 패턴이 만능은 아닙니다. 클린 아키텍처 역시 마찬가지입니다. 하지만 제가 경험해 본 바로는, 특정 상황과 팀 환경에서는 클린 아키텍처가 제공하는 가치가 압도적이었습니다.

• 장기적인 유지보수가 필요한 대규모 프로젝트: 특히 5년 이상 서비스될 것으로 예상되는 프로젝트, 혹은 기능 추가와 변경이 빈번할 것으로 예상되는 시스템에는 클린 아키텍처가 빛을 발합니다. 초기 설계에 드는 비용이 충분히 상쇄되고도 남습니다.
• 다양한 기술 스택 변화에 유연하게 대응해야 하는 프로젝트: 데이터베이스, 웹 프레임워크, 외부 API 등 인프라나 외부 의존성이 변경될 가능성이 높은 프로젝트라면 클린 아키텍처의 프레임워크 독립성이 큰 이점을 제공합니다.
• 높은 품질과 안정성이 요구되는 시스템: 금융, 의료 등 버그 하나가 치명적인 결과를 초래할 수 있는 도메인에서는 철저한 테스트 용이성이 필수적입니다. 클린 아키텍처는 비즈니스 로직의 완벽한 테스트를 가능하게 합니다.
• 여러 개발자가 협업하는 팀: 각 계층의 역할과 책임이 명확하여 팀원 간의 역할 분담이 용이하고, 코드 리뷰의 효율성을 높여줍니다. 특히 팀 규모가 5명 이상이라면 그 효과가 더욱 두드러집니다.
• 모놀리식 아키텍처에서 마이크로서비스 전환을 고려하는 팀: 클린 아키텍처의 계층 분리는 나중에 특정 유스 케이스를 마이크로서비스로 분리할 때도 매우 유리한 기반을 제공합니다. 비즈니스 로직이 깔끔하게 분리되어 있기 때문에, 재사용 및 재구축 비용이 현저히 낮아집니다.

반면에, 매우 짧은 기간 내에 프로토타입을 만들어야 하거나, 기능이 단순하고 변경 가능성이 거의 없는 소규모 프로젝트에서는 클린 아키텍처가 오버 엔지니어링으로 느껴질 수 있습니다. 이런 경우에는 더 가볍고 단순한 아키텍처를 선택하는 것이 현명할 수 있습니다. 중요한 것은 프로젝트의 요구사항과 팀의 역량을 고려하여 적절한 균형점을 찾는 것입니다.

마치며: 클린 아키텍처는 단순한 기술이 아닌 '사고방식'의 변화

『클린 아키텍처』는 단순히 코드를 어떻게 작성해야 하는지에 대한 기술적인 지침을 넘어, 소프트웨어 설계에 대한 근본적인 사고방식을 변화시켜준 책입니다. 책을 읽고 실제 프로젝트에 적용해 보면서, 제가 그동안 얼마나 많은 '나쁜 의존성' 속에서 고통받고 있었는지 깨달을 수 있었습니다.

클린 아키텍처는 단숨에 마법처럼 모든 문제를 해결해 주는 만능 해결책은 아닙니다. 초기에는 복잡하게 느껴지고, 더 많은 시간과 노력이 필요할 수 있습니다. 하지만 장기적인 관점에서 봤을 때, 견고하고 유연하며, 무엇보다 개발자들이 행복하게 일할 수 있는 시스템을 만드는 데 결정적인 역할을 합니다.

이 책은 개발 경력이 짧은 주니어 개발자부터, 수많은 프로젝트를 경험한 시니어 개발자에 이르기까지 모든 개발자에게 깊은 통찰을 제공할 것이라고 확신합니다. 만약 여러분의 프로젝트가 점점 더 복잡해지고, 변경에 대한 두려움이 커지고 있다면, 잠시 시간을 내어 이 책을 펼쳐 보시길 강력히 추천합니다.

클린 아키텍처를 적용해 본 경험이 있으신가요? 어떤 점이 가장 인상 깊었는지, 혹은 어떤 어려움을 겪으셨는지 댓글로 자유롭게 의견을 공유해 주세요! 여러분의 소중한 경험이 다른 개발자들에게 큰 도움이 될 것입니다.

📌 함께 읽으면 좋은 글

• [커리어 취업] 개발자 시스템 설계 면접 공략: 확장성과 견고성을 갖춘 아키텍처 제시 전략
• [개발 책 리뷰] 지저분한 코드 탈출! 리팩토링 책으로 배우는 유지보수성 높은 코드 작성법
• [개발 책 리뷰] 데이터 중심 애플리케이션 설계: 대규모 분산 시스템 구축을 위한 필독서 심층 리뷰

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.