개발 블로그

개발을 할 때 디렉터리 구조를 설계하는 방법은 크게 두 가지로 나뉩니다. 계층형 디렉터리, 도메인형 디렉터리 2가지로 구성되는데, 저는 항상 계층형 디렉터리로 설계해 왔습니다. 각각의 디렉터리 구조에는 장, 단점이 있지만, 프로젝트 규모와 팀원들 협업 스타일에 알맞게 설계하는 것이 중요하다고 생각합니다. 이제 차근차근 알아보도록 하겠습니다. 1. 계층형 디렉토리 구조(Layered Directory Structure) 기능 또는 역할에 따라 코드를 계층별로 그룹화하는 방식을 계층형 디렉터리 구조라고 합니다. Web Layer: Client와의 요청을 받아 처리하는 역할 담당을 담당, 컨트롤러(Controller), 필터(Filter) 관련 클래스들이 위치하며, HTTP 요청을 처리하여 비즈니스 로직 수행..

오늘은 동시성 이슈를 해결하는 과정에 대해서 포스팅하려고 합니다. 재고 시스템을 통해 Application Level에서 문제를 해결하는 방안, Database가 제공하는 Lock을 이용해서 문제를 해결하는 방안, Redis의 Lettuce, Redisson을 활용하는 방안에 대해서 설명드리겠습니다. domain은 간단하게 재고 갯수, version 정보(Optimistic Lock을 적용하기 위함)가 담겨있고, 재고 개수를 감소시키는 decrease 메서드 Stock 클래스로 구성되어 있습니다. service는 domain에서 재고 개수를 감소시키는 decrease 메서드를 호출하는 비즈니스 로직으로 구성되어 있습니다. 이제 multi-thread 환경에서 동시에 100개의 요청을 보냈을 때의 발생하는..

동시성 두 개 이상의 세션이 공통된 자원에 대해 읽고 쓰는 작업을 하는 경우, 발생할 수 있는 문제 동시성 문제의 2가지 현상 일관성 없는 읽기 세션 2는 동시에 실행되고 있는 세션 1 때문에, 데이터에 접근하는 시점마다 다른 값을 읽게 됩니다. 이러한 문제는 “불변성”, 복사본을 이용하여 해결, 세션2가 최초로 데이터를 조회하는 경우, 해당 데이터를 복사하고 이후에도 계속 사용하는 것입니다. 하지만, JPA에서는 영속성 컨텍스트에 데이터를 1차 캐시에 캐싱하기 때문에, 일관성 없는읽기에 대한 문제는 없습니다. 갱신 손실 세션2에 의해 세션 1의 변경 사항이 무시되는 현상 이러한 동시성 문제를 해결하기 위한 방안 Optimistic Lock(낙관적 락) 자원에 Lock을 걸지 않고 충돌이 발생했을 때, ..

예외 계층의 구조와 체크 예외, 언체크 예외의 차이와 활용에 대해서 알아보려고 합니다. Object: 예외도 객체이고, 모든 객체의 최상위 부모는 Object이므로, 예외의 최상의 부모 또한 Object 입니다. Throwable: 최상위 예외로서, Exception과 Error로 나눌 수 있습니다. Error: 메모리 부족, 시스템 오류와 같이 애플리케이션에 복구 불가능한 시스템 예외입니다. 이 예외를 잡아서는 안 됩니다. 상위 예외를 catch로 잡아버리면 하위 예외까지 같이 잡아버리는데, Throwable 예외를 잡게 되면, Error 예외도 함께 잡는 불상사가 일어날 수 있기 때문에 잡아서는 안됩니다. Error는 언체크 예외입니다. Exception: 체크 예외 애플리케이션 로직에서 사용할 수 ..

애플리케이션 로직은 큰 틀에서 핵심 기능, 부가 기능 2가지로 나눌 수 있습니다. 핵심 기능은 객체가 제공하는 비즈니스 로직이고, 부가 기능은 핵심 기능과 함께 사용되는 로그 추적 로직, 트랜잭션 기능과 같습니다. 부가 기능은 핵심 기능을 보조하기 위해 사용되는 기능입니다. 부가 기능은 여러 클래스에 걸쳐서 사용되는데 이를 횡단 관심사라고 하며, 하나의 부가기능이 여러 곳에서 동일하게 사용됨을 의미합니다. 하지만, 이러한 중복된 로직을 반복해서 사용하게 된다면 Refactoring에 있어서 많은 번거로움이 발생하게 됩니다. 즉, 이러한 문제점을 해결하기 위해 도입된 기술이 AOP 입니다. AOP가 생기면서 부가 기능을 핵심 기능에서 분리하고 한 곳에서 관리해 줄 수 있게 되었습니다. 그리고 이러한 기술을..

Proxy Pattern, Decorator Pattern은 모두 Proxy 기술(클라이언트의 요청을 대신해서 처리해 주는 역할)이 적용됩니다. 이때, 서버와 프록시는 같은 인터페이스를 사용해야 하고, 의존관계를 서버에서 프록시로 변경해도 클라이언트 입장에서는 이러한 사실을 몰라야 합니다(프록시 체인). 앞서 설명드린 DI를 사용하면, 클라이언트의 코드 변경 없이 프록시를 주입할 수 있게 됩니다. 이제 이 둘의 차이와 역할에 대해 설명드리겠습니다. GOF 디자인 패턴에 따라 프록시의 역할은 2가지로 구분됩니다(intent에 의해 구분). 1. Proxy Pattern 권한에 따른 접근 차단, 캐싱, 지연로딩 2. Decorator Pattern 원래 서버가 제공하는 기능에 더해 부가 기능 수행 Proxy..

스프링에서 사용되는 디자인 패턴인 템플릿 메서드 패턴, 전략 패턴, 템플릿 콜백 패턴에 대해 알아보려고 합니다. 이들을 적용하는 이유는 좋은 설계를 위해서입니다. 좋은 설계란 요구 부가 기능(핵심 기능의 보조 기능)을 변경하지 않고 핵심 기능만 변경하게 설계하는 것입니다.(중복된 로직을 변경하지 않고, 변하는 것(비즈니스 로직)만 순수하게 바꾸어주는 것) 우선 좋은 설계에 한 발짝 나아갈 수 있는 템플릿 메서드 패턴에 대해 설명드리고 이와 비슷한 기능을 하고 있지만, 템플릿 메서드 패턴의 단점을 보완할 수 있는 전략 패턴, 전략 패턴에서의 템플릿과 콜백 부분을 강조한 템플릿 콜백 패턴까지 설명드리려고 합니다. GOF 템플릿 메서드 패턴 정의 부모 클래스에서의 템플릿을 정의하고, 일부 변경되는 로직을 자식..

DI, IoC, 컨테이너와 같은 개념들은 Spring Framework의 가장 기본적인 특징입니다. 1. IoC(Inversion of Control, 제어의 역전) 프로그램의 제어 흐름을 프로그래머가 직접적으로 제어하는 것이 아니라, 외부에서 관리하는 것 프로그래머가 객체를 생성할 때, 직접 생성하는 것이 아니라 스프링 컨테이너에서 생성하고 등록된 객체(Bean)를 가져오는 것입니다. 즉, 제어권을 본인이 아닌, 프레임워크(Spring 컨테이너)에게 넘겨줬기 때문에 IoC라는 개념이 도입됐습니다. 2. DI(Dependency Injection, 의존관계 주입) 애플리케이션 실행 시점에 외부에서 실제 구현 객체를 생성하고, 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결되는 것 Sprin..

SOLID 원칙이란 좋은 객체 지향 설계를 하기 위한 5가지 원칙입니다. SRP, OCP, LSP, ISP, DIP 총 5가지가 있는데, 이 원칙에 대해 알아보도록 하겠습니다. 1. SRP(Single Responsibility Principle, 단일 책임 원칙) 한 클래스는 하나의 책임을 가져야 하는 원칙 변경이 있을 때, 변경에 대한 파급효과가 적으면 SRP를 준수하고 있다는 것입니다. 2. OCP(Open/Closed Principle, 개방-폐쇄 원칙) 소프트웨어 요소는 확장에는 열려 있어야 되지만, 변경에는 닫혀 있어야 하는 원칙 (다형성) 다형성은 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있어야 하는 개념입니다. 클라리언트를 변경하지 않으면서, 서버의 구현 기능을 ..

프로젝트에서 프론트 팀원분께서 api 연동을 하려는데 이러한 에러가 뜬다고 말씀해 주셨습니다. Access to XMLHttpRequest at 'http://ip주소/api/matches' from origin 'http://127.0.0.1:5173' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource 주어진 에러 메세지는 브라우저에서 발생한 CORS 관련 오류입니다. 서버에서 CORS 정책이 적절하게 구성되지 않은 경우에 클라이언트에서 요청한..