실전 문제와 해결 전략

이번 글에서는 백엔드 실전 문제들을 살펴보고, 각각의 문제를 해결하는 방법에 대해 정리해보겠습니다.

1. CS - CAS(Compare-and-Swap) 활용

 

 문제: synchronized 없이 다중 스레드 환경에서 동시성 제어하기

 

멀티스레드 환경에서 하나의 변수를 여러 스레드가 동시에 수정하는 경우 경합 상태(Race Condition)가 발생할 수 있습니다. 기존에는 synchronized 키워드를 사용하여 동기화했지만, 이는 성능 저하의 원인이 될 수 있습니다. 이를 해결하기 위해 CAS(Compare-and-Swap) 연산을 활용한 AtomicInteger 사용을 고려해야 합니다.

 

해결 방법: AtomicInteger를 활용한 CAS 동기화

import java.util.concurrent.atomic.AtomicInteger;

public class Counter {
    private final AtomicInteger count = new AtomicInteger(0);

    public void increment() {
        count.incrementAndGet(); // CAS 연산을 통해 동기화 없이 증가
    }

    public int getCount() {
        return count.get();
    }
}

왜 AtomicInteger를 사용해야 할까?

• synchronized를 사용하면 JVM이 락을 사용하여 스레드 간 접근을 제어 → 컨텍스트 스위칭 비용 증가
• AtomicInteger는 내부적으로 CAS 연산을 사용하여 락 없이도 안전하게 값을 업데이트
• 성능 향상: 락이 필요 없으므로 병렬 처리 성능이 크게 향상

 

멀티스레드 환경에서 AtomicInteger를 사용하면 동기화 없이도 안전한 값 변경이 가능하며, 성능 최적화에 효과적이다.

 

 

2. Spring Boot 심화 – AOP 기반 트랜잭션 로깅

 

문제: @Transactional 실행 시간을 자동으로 측정하고 로깅하기

 

트랜잭션이 실행될 때 일부 작업이 예상보다 오래 걸려 성능 저하를 유발할 수 있습니다.

이를 감지하기 위해 AOP(Aspect-Oriented Programming)을 활용해 트랜잭션 실행 시간을 자동으로 측정하고 로그를 남기는 방식을 적용할 수 있습니다.

 

해결 방법: @Around AOP 로깅

@Aspect
@Component
public class TransactionLoggingAspect {

    private static final Logger logger = LoggerFactory.getLogger(TransactionLoggingAspect.class);

    @Around("@annotation(org.springframework.transaction.annotation.Transactional)")
    public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
        long start = System.nanoTime();
        Object result = joinPoint.proceed();
        long duration = (System.nanoTime() - start) / 1_000_000; // 밀리초 변환

        if (duration > 500) {
            logger.warn("트랜잭션 실행 시간 경고: {} ms - 메서드: {}", duration, joinPoint.getSignature());
        }

        return result;
    }
}

 

왜 AOP를 활용해야 할까?

• @Transactional이 붙은 모든 메서드의 실행 시간을 자동으로 측정
• 500ms 이상 실행되는 트랜잭션에 대해서만 경고 로그 출력 → 병목 구간 탐지
• 기존 비즈니스 로직을 수정하지 않고, 별도의 로깅 기능을 추가 가능

 

트랜잭션 실행 시간을 실시간으로 모니터링하고 성능 병목을 찾아 최적화하는 데 유용하다.

 

 

 

3. 대규모 시스템 설계 – CQRS + Event Sourcing

 

문제: 고성능 트래픽을 처리하기 위해 CQRS 패턴을 도입해야 한다면?

 

대규모 트래픽을 처리하는 전자상거래 시스템에서 주문(Order) 정보를 관리할 때,

쓰기(주문 생성)와 읽기(주문 조회) 성능을 각각 최적화해야 합니다.

이를 위해 CQRS(Command Query Responsibility Segregation) 패턴과 Event Sourcing을 활용한 데이터 동기화를 적용해야 합니다.

 

해결 방법: Kafka를 활용한 이벤트 기반 CQRS

 

1. 주문 생성 시 이벤트 발행 (Command Service)

@Service
public class OrderCommandService {
    private final OrderRepository orderRepository;
    private final KafkaTemplate<String, String> kafkaTemplate;

    public void createOrder(Order order) {
        orderRepository.save(order);
        kafkaTemplate.send("order-events", new OrderCreatedEvent(order.getId(), order.getUserId()));
    }
}

2. Query 서비스에서 Kafka Consumer로 데이터 동기화 (Query Service)

@Service
public class OrderQueryService {
    @KafkaListener(topics = "order-events", groupId = "order-group")
    public void handleOrderCreated(OrderCreatedEvent event) {
        OrderReadModel orderReadModel = new OrderReadModel(event.getOrderId(), event.getUserId());
        orderReadRepository.save(orderReadModel);
    }
}

 

CQRS + Event Sourcing 적용 시 장점

• 쓰기(Command)와 읽기(Query)를 분리하여 성능 최적화
• Kafka를 활용한 비동기 이벤트 처리 → 높은 확장성
• 최종 일관성(Eventual Consistency) 보장

 

CQRS + Event Sourcing을 활용하면 대규모 트래픽에서도 안정적으로 데이터 동기화 가능.

 

 

 

4. DevOps & 배포 – Docker 레이어 캐싱 최적화

 

문제: Docker 빌드 속도가 너무 느리다. 이를 최적화하려면?

 

Docker를 활용하여 Spring Boot 애플리케이션을 배포할 때,

불필요한 빌드 과정을 줄이고 캐싱을 활용하여 속도를 최적화해야 합니다.

 

해결 방법: Multi-Stage Build + Layered JAR 적용

# 빌드
FROM openjdk:17 AS builder
WORKDIR /app
COPY gradle gradle
COPY build.gradle settings.gradle gradlew /app/
RUN ./gradlew dependencies  # 의존성 미리 캐싱

COPY src /app/src
RUN ./gradlew bootJar

# 실행
FROM openjdk:17-jre
WORKDIR /app
COPY --from=builder /app/build/libs/app.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]

 

최적화 원리

• Multi-Stage Build를 활용하여 빌드 환경과 실행 환경을 분리
• COPY build.gradle settings.gradle을 먼저 실행하여 의존성 캐싱
• 최종 이미지를 경량 JRE로 실행하여 이미지 크기 감소