Developer_TaeHui

Kafka란 무엇인가?

TaeHuiLee — Sat, 18 Jan 2025 03:05:31 +0900

Apache Kafka는 분산 메시징 플랫폼으로, 데이터를 생산자(Producer)에서 소비자(Consumer)로 빠르고 안정적으로 전달하기 위해 설계된 시스템입니다. 처음 LinkedIn에서 개발되었으며, 현재는 오픈소스로 전 세계적으로 사용되고 있습니다. Kafka는 단순한 메시징 큐 이상의 기능을 제공하며, 대규모 실시간 데이터 스트리밍 및 분산 처리를 가능하게 합니다.

1. `Kafka 개요`

Kafka는 Publish-Subscribe 모델 기반으로 동작하며, 다양한 데이터 소스에서 발생하는 데이터를 처리하는 데 사용됩니다. 이를 통해 실시간 데이터 스트림을 관리하거나, 데이터를 저장소로 전송하는 데이터 파이프라인 역할을 수행합니다.

Kafka의 주요 구성 요소

Producer (생산자): 데이터를 생성하고 Kafka의 특정 토픽(Topic)으로 전송합니다.
Broker (브로커): 데이터를 저장하고 관리하며, 여러 브로커가 클러스터를 형성하여 데이터를 분산 처리합니다.
Consumer (소비자): 데이터를 읽고 처리하는 애플리케이션입니다.
Topic (토픽): 데이터를 분류하기 위한 논리적인 단위입니다. 각 토픽은 여러 개의 Partition(파티션)으로 나뉩니다.
Partition (파티션): 데이터를 물리적으로 나누어 저장하는 단위입니다.
ZooKeeper/Kafka Raft: 클러스터 상태와 노드 메타데이터를 관리합니다. (최신 Kafka 버전에서는 Raft로 ZooKeeper를 대체)

Kafka의 핵심 개념

분산 아키텍처:
Kafka는 분산 시스템으로 설계되어 높은 가용성과 확장성을 제공합니다. 데이터를 여러 노드에 분산 저장하여 성능을 최적화하고 장애에도 대비합니다.
내구성(Durability):
Kafka는 데이터를 디스크에 저장하며, 데이터를 복제하여 안정성을 유지합니다. 데이터 손실을 최소화하고 필요할 경우 재처리를 지원합니다.
오프셋(Offset):
Kafka는 데이터를 순차적으로 처리하기 위해 오프셋 개념을 사용합니다. 소비자는 오프셋을 기준으로 데이터를 읽으며, 원하는 시점으로 돌아가 데이터를 다시 처리할 수 있습니다.

2. `Kafka 데이터 처리 방식`

Kafka의 데이터 처리 방식은 생산자 → 브로커 → 소비자의 흐름으로 이루어집니다. 각 단계에서 특정한 기능과 특징이 적용됩니다.

1️⃣ 데이터 생성: `Producer`

생산자는 데이터를 생성한 후 Kafka의 특정 토픽으로 데이터를 보냅니다.
데이터를 보낼 때, Round-Robin 방식 또는 Key 기반 해싱으로 특정 Partition에 데이터가 저장됩니다.
Kafka는 프로듀서가 보낸 데이터를 배치 처리하여 네트워크 효율성을 높입니다.

2️⃣ 데이터 저장: `Broker`

Kafka의 브로커는 데이터를 Partition 단위로 저장합니다.
각 Partition은 여러 브로커에 복제되어 안정성을 높입니다.
- 예: 복제 계수(Replication Factor)가 3인 경우, 동일한 데이터가 3개의 브로커에 저장됩니다.
Kafka는 데이터를 디스크에 저장하지만, 데이터 쓰기 및 읽기가 매우 빠릅니다. 이는 순차적 I/O를 활용하기 때문입니다.

3️⃣ 데이터 소비: `Consumer`

소비자는 Kafka에서 데이터를 읽어오는 역할을 합니다.
소비자는 각 Partition에서 데이터를 오프셋 기반으로 읽습니다. 이렇게 하면 데이터를 실시간으로 처리하거나, 과거 데이터를 다시 읽는 재처리가 가능합니다.
소비자 그룹 (Consumer Group):
- 여러 소비자가 그룹을 이루어 데이터를 처리할 수 있습니다.
- 각 소비자는 Partition을 독점적으로 처리하며, 부하가 분산됩니다.

Kafka 데이터 처리의 특징

배치 처리와 스트리밍 처리의 균형:
- Kafka는 데이터를 실시간으로 처리하면서도, 데이터의 배치 처리 및 재처리를 지원합니다.
Pull 기반 처리:
- 소비자가 데이터를 요청(Pull) 하여 가져오는 방식입니다. 이는 RabbitMQ 같은 Push 기반 메시징 시스템과의 주요 차이점입니다.
데이터 보관:
- Kafka는 데이터를 로그 파일 형태로 저장하며, 설정에 따라 특정 기간 동안 데이터를 유지합니다.

3. `Kafka의 성능`

Kafka는 대규모 데이터를 빠르고 안정적으로 처리할 수 있도록 설계되었습니다. 아래는 Kafka 성능의 주요 특징입니다:

1️⃣ ⚡ `처리량`

Kafka는 초당 수백만 건의 메시지를 처리할 수 있습니다.
데이터 처리량은 파티션 수와 브로커 수에 따라 확장 가능하며, 클러스터의 크기를 조정하여 성능을 높일 수 있습니다.

2️⃣ ⏱ `낮은 지연 시간`

Kafka는 밀리초(ms) 단위의 지연 시간으로 데이터를 처리합니다.
실시간 데이터 처리에 적합하며, 실시간 분석, IoT 애플리케이션, 로그 처리에 널리 사용됩니다.

3️⃣ `확장성`

Kafka는 새로운 브로커를 추가함으로써 클러스터 크기를 동적으로 확장할 수 있습니다.
각 브로커가 독립적으로 동작하므로, 장애가 발생해도 전체 시스템에 영향을 주지 않습니다.

4️⃣ `내구성`

Kafka는 데이터를 디스크에 저장하며, 데이터 손실을 방지하기 위해 복제합니다.
장애 복구 시 복제된 데이터를 기반으로 복원이 가능합니다.

5️⃣ `안정성`

Kafka는 분산 환경에서 노드 간 통신을 효율적으로 관리하여 안정적인 메시징을 제공합니다.
클러스터를 통해 데이터가 특정 노드에만 의존하지 않도록 설계되어 있습니다.

4. ⚖️ `RabbitMQ와의 차이점`

Kafka와 RabbitMQ는 모두 메시징 시스템이지만, 설계 철학과 사용 사례에서 큰 차이가 있습니다.

특징KafkaRabbitMQ아키텍처분산 시스템, 브로커 기반중앙 집중형 메시징 큐메시징 모델Publish-Subscribe메시지 큐 (Queue)데이터 전달 방식Pull 기반Push 기반데이터 저장디스크 기반 (로그 보관 가능)메모리 우선 (빠른 처리)복잡성클러스터 설정 및 운영이 복잡상대적으로 간단한 설정실시간성밀리초 수준 (약간의 지연)매우 낮은 지연 시간 (실시간 처리)확장성브로커와 Partition 추가로 높은 확장성확장성은 제한적사용 사례대규모 데이터 처리, 로그 분석실시간 알림, 요청-응답 구조

RabbitMQ가 더 적합한 경우

실시간 처리가 중요한 경우 (예: 알림 서비스, 요청-응답)
소규모 메시징 환경에서 단순하고 빠른 설정이 필요한 경우

Kafka가 더 적합한 경우

대규모 데이터 스트리밍이 필요한 경우 (예: 로그 수집, 데이터 파이프라인)
높은 내구성과 데이터 보존이 중요한 경우

5. Kafka를 활용한 시스템 설계(결제 시스템)

결제 시스템 설계 목표

확장성
- 대량의 주문 요청에도 안정적으로 처리.
데이터 신뢰성
- 결제 및 주문 데이터 유실 방지.
서비스 분리
- 재고 관리, 결제, 알림 등 서비스 간 독립적이고 느슨한 결합.
오류 처리 및 복구
- 실패 시 재처리(재시도) 및 데드 레터 큐(Dead Letter Queue) 사용.
실시간 피드백
- 사용자에게 즉각적인 상태 알림 제공.

️ Kafka와 Spring Boot로 설계한 시스템 구조

1. 사용자 → 2. 주문 서비스(Order Service) → 3. Kafka (`order-created` 이벤트)
    ↓                                  ↘
4. 재고 서비스(Inventory Service)        6. 결제 서비스(Payment Service)
    ↓                                  ↘
5. Kafka (`inventory-confirmed` or       7. Kafka (`payment-success` or
   `inventory-failed` 이벤트)               `payment-failure` 이벤트)
    ↓                                  ↘
8. 알림 서비스(Notification Service) ← 9. Kafka

단계별 구현 및 실패 처리 전략

1️⃣ 주문 생성 (Order Create)

동작: 사용자의 요청을 받아 주문 정보를 저장하고 Kafka에 order-created 이벤트를 발행합니다.
오류 처리:
- Kafka로 메시지 발행 실패 시 재시도 로직 추가.
- DB 트랜잭션과 Kafka 발행 간 트랜잭션 동기화(e.g., Kafka Transactional API) 구현.

@RestController
@RequestMapping("/orders")
public class OrderController {

    @Autowired
    private KafkaTemplate<String, Order> kafkaTemplate;

    @PostMapping
    public ResponseEntity<String> createOrder(@RequestBody Order order) {
        try {
            // 주문 저장 (DB)
            orderService.saveOrder(order);

            // Kafka에 이벤트 발행
            kafkaTemplate.send("order-created", order);
            return ResponseEntity.ok("Order Created Successfully!");
        } catch (Exception e) {
            // 예외 처리: Kafka 발행 실패 시 로깅 및 재시도
            log.error("Failed to create order: ", e);
            return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body("Failed to create order");
        }
    }
}

2️⃣ 재고 확인 (Inventory Check)

동작: order-created 이벤트를 구독하고 재고를 확인합니다. 결과에 따라 inventory-confirmed 또는 inventory-failed 이벤트를 발행합니다.
오류 처리:
- 재고 확인 실패: Kafka 재시도를 설정하거나, 실패 메시지를 데드 레터 큐(Dead Letter Queue)로 전송.
- 재시도: 특정 횟수(예: 3회) 재시도 후 실패하면 알림 서비스로 전달.

@KafkaListener(topics = "order-created", groupId = "inventory-service")
public void checkInventory(Order order) {
    try {
        boolean inventoryAvailable = inventoryService.checkInventory(order.getItems());
        if (inventoryAvailable) {
            kafkaTemplate.send("inventory-confirmed", order);
        } else {
            kafkaTemplate.send("inventory-failed", order);
        }
    } catch (Exception e) {
        // 실패 처리 로직
        log.error("Inventory check failed for order: " + order.getOrderId(), e);

        // 데드 레터 큐로 전송
        kafkaTemplate.send("inventory-dlq", order);
    }
}

3️⃣ 결제 처리 (Payment Process)

동작: inventory-confirmed 이벤트를 구독하여 결제를 처리하고 결과를 발행합니다.
오류 처리:
- 결제 실패: Kafka 이벤트로 payment-failure 발행 후 알림 서비스에서 처리.
- 결제 시스템 장애: Kafka 재시도 설정으로 복구 시도.

@KafkaListener(topics = "inventory-confirmed", groupId = "payment-service")
public void processPayment(Order order) {
    try {
        boolean paymentSuccess = paymentService.process(order);
        if (paymentSuccess) {
            kafkaTemplate.send("payment-success", order);
        } else {
            kafkaTemplate.send("payment-failure", order);
        }
    } catch (Exception e) {
        // 예외 발생 시 재시도 또는 데드 레터 큐 처리
        log.error("Payment processing failed for order: " + order.getOrderId(), e);
        kafkaTemplate.send("payment-dlq", order);
    }
}

4️⃣ 사용자 알림 (Notification)

동작: payment-success 또는 payment-failure 이벤트를 구독하여 사용자에게 알림(SMS, Email 등)을 보냅니다.
오류 처리:
- 알림 실패 시 실패 내역을 기록하고 관리자에게 보고.

@KafkaListener(topics = {"payment-success", "payment-failure"}, groupId = "notification-service")
public void sendNotification(Order order) {
    try {
        if ("payment-success".equals(order.getStatus())) {
            notificationService.sendSuccessNotification(order);
        } else {
            notificationService.sendFailureNotification(order);
        }
    } catch (Exception e) {
        // 알림 실패 처리
        log.error("Notification failed for order: " + order.getOrderId(), e);
    }
}

️ 실패 처리 전략

Kafka 재시도
- Spring Kafka의 RetryTemplate을 사용하여 메시지 재처리.
- 설정 예시:

spring:
  kafka:
    # Kafka 브로커 주소 설정 (클러스터의 여러 브로커를 쉼표로 구분하여 추가 가능)
    producer:
      bootstrap-servers: localhost:9092

      # 메시지 전송 보장 수준 설정
      # all: 모든 복제본(ISR)에 저장 완료 후 응답 (최고의 신뢰성)
      # 1: 리더 브로커만 저장 후 응답 (성능 향상, 일부 유실 가능성)
      # 0: 브로커 응답을 기다리지 않음 (유실 가능성 높음, 매우 빠름)
      acks: all 

      # 전송 실패 시 재시도 횟수 (일시적 네트워크 장애 등 대응)
      retries: 5

      # Producer가 메시지를 일정 크기(16KB)까지 모아서 전송하여 성능 최적화
      batch-size: 16384

      # 메시지를 전송하기 전 대기하는 시간 (단위: ms, 대기 후 배치 전송)
      linger.ms: 5

      # 메시지 버퍼 크기 (Producer가 메시지를 전송하기 전까지 보관할 메모리 크기)
      buffer-memory: 33554432

      # 메시지 중복 방지를 위해 동시에 처리할 수 있는 최대 요청 수
      max-in-flight-requests-per-connection: 5

      # Producer에서 메시지를 직렬화할 때 사용할 Serializer (String 기반)
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.apache.kafka.common.serialization.StringSerializer

    consumer:
      # 자동 커밋을 비활성화하여, 수동으로 메시지를 확인 후 커밋 (데이터 유실 방지)
      enable-auto-commit: false

      # Consumer가 새 컨슈머 그룹으로 시작할 때 어디서부터 데이터를 읽을지 지정
      # earliest: 가장 오래된 메시지부터 소비
      # latest: 가장 최근의 메시지부터 소비
      auto-offset-reset: earliest

      # 한 번에 가져올 최대 메시지 수 (너무 크면 메모리 부족 위험)
      max-poll-records: 100

      # 최소 가져올 데이터 크기 (50KB 이상의 데이터가 쌓일 때 가져오도록 설정)
      fetch-min-size: 50000

      # 데이터를 기다리는 최대 시간 (단위: ms, 적절한 값 조정 필요)
      fetch-max-wait: 500

      # 컨슈머가 브로커에게 보내는 하트비트 간격 (단위: ms)
      heartbeat-interval: 3000

      # 컨슈머가 일정 시간 내에 하트비트를 보내지 않으면 그룹에서 제거 (단위: ms)
      session-timeout-ms: 10000

      # Consumer에서 메시지를 역직렬화할 때 사용할 Deserializer (String 기반)
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer

    listener:
      # 컨슈머가 메시지를 배치 단위로 수신하여 처리 (성능 최적화)
      type: batch

      # 특정 토픽이 존재하지 않을 때 예외를 발생시키지 않도록 설정
      missing-topics-fatal: false

      # 메시지 처리 실패 시 최대 5번까지 재시도 (오류 복구 로직을 위해 설정)
      retry:
        max-attempts: 5

      # 재시도 간 간격 설정 (1초부터 시작, 실패할 때마다 증가)
      backoff:
        initial-interval: 1000  # 첫 번째 재시도 간격 (1초)
        multiplier: 2.0         # 다음 재시도까지의 시간 배수 증가 (1초 → 2초 → 4초)
        max-interval: 10000     # 최대 재시도 간격 (10초)

      # 메시지 처리가 완료된 후 수동으로 오프셋을 커밋하도록 설정 (acknowledgment 필요)
      ack-mode: manual_immediate

      # 메시지 처리 실패 시 Dead Letter Queue(DLQ)에 저장 (재처리 및 분석)
      error-handler:
        dead-letter-publish: true

데드 레터 큐(Dead Letter Queue)
- Listener처리 실패 메시지를 별도의 Kafka 토픽으로 이동.
- 실패한 데이터를 분석 및 복구하는 데 사용.
- Spring Kafka에서 데드 레터 큐를 활성화하려면 error-handling 설정을 추가합니다.

트랜잭션 관리
- Kafka 트랜잭션 API를 사용하여 데이터베이스 작업과 Kafka 이벤트 발행을 원자적으로 처리.
모니터링 및 로깅
- Kafka와 Spring Boot의 Actuator를 활용한 실시간 모니터링.
- 예외 발생 시 로깅 및 알림을 통해 장애 대응.
Outbox 패턴
- Outbox 패턴은 Kafka와 RDBMS를 함께 사용하는 환경에서 데이터 일관성과 신뢰성을 보장
- Kafka 발행 실패와 같은 상황에서 메시지 유실을 방지하며 안정적인 시스템을 설계

오류 처리 핵심: 재시도, 데드 레터 큐, 트랜잭션 관리, 모니터링을 통해 시스템 신뢰성을 극대화합니다.

정리

Kafka의 동작 방식:
Kafka는 Producer, Broker, Consumer, Topic, Partition 등으로 구성된 분산 메시징 시스템으로, 데이터를 생성, 저장, 소비하는 과정에서 높은 확장성과 안정성을 제공합니다.
Kafka의 장단점:
Kafka는 대규모 데이터 스트리밍과 내구성이 강점이지만, 설정 및 운영이 복잡하며 실시간 처리가 필요한 경우 적합하지 않을 수 있습니다.
RabbitMQ와의 차이점:
RabbitMQ는 단순하고 빠른 메시징에 적합하며, Kafka는 대규모 데이터 처리 및 스트리밍에 특화된 플랫폼입니다.

[JAVA] Spring Boot 대규모 트래픽 처리 #Redis #Scheduler

TaeHuiLee — Tue, 14 Jan 2025 23:47:46 +0900

1. ️ Spring Boot 대규모 트래픽 처리 방안: Redis, Scheduler

대규모 트래픽 상황에서 데이터를 효율적으로 처리하기 위한 방법중 하나로 Redisd와 Scheduler를 활용한 개발 방법을 정리해 보려 합니다.
Redis에 데이터를 임시 저장하고, 일정 시간 간격으로 DB에 적재하는 방식을 구현합니다. Redis는 빠른 쓰기 작업에 유리하며, 데이터 배치를 통해 DB의 부담을 줄일 수 있습니다.

2. 로직과 코드 구현

전체 로직

데이터 저장
- 데이터를 Redis의 리스트(List) 구조에 저장합니다.
- 가장 최근 키에 데이터를 추가하되, 리스트가 3000개 이상일 경우 새로운 키를 생성합니다.
스케줄링 처리
- Redis에서 가장 오래된 키부터 데이터를 가져옵니다.
- 데이터를 DB에 적재하고, 처리된 키는 삭제합니다.
- 데이터가 3000개 미만이면 추가 데이터를 가져와 배치를 완성합니다.

3️⃣ 구현 코드

1. Redis에 데이터 저장 서비스

@Service
public class RedisDataService {

    private final RedisTemplate<String, String> redisTemplate;

    public RedisDataService(RedisTemplate<String, String> redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    public void saveData(String data) {
        // 1. 가장 최근 Key 찾기
        String recentKey = findMostRecentKey();

        // 2. Key의 데이터 개수 확인
        Long size = redisTemplate.opsForList().size(recentKey);

        if (size != null && size < 3000) {
            // 기존 Key에 데이터 저장
            redisTemplate.opsForList().leftPush(recentKey, data);
        } else {
            // 새로운 Key 생성
            String newKey = generateNewKey();
            redisTemplate.opsForList().leftPush(newKey, data);
        }
    }

    private String findMostRecentKey() {
        // Redis Key 조회 후 가장 최근 Key 반환
        Set<String> keys = redisTemplate.keys("data_*");
        return keys.stream().max(String::compareTo).orElse(generateNewKey());
    }

    private String generateNewKey() {
        // 새로운 Key 생성: 현재 시간 + UUID
        return "data_" + LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMdd_HHmmss")) + "_" + UUID.randomUUID();
    }
}

2. Redis 데이터를 DB로 옮기는 스케줄러

@Service
public class RedisToDbScheduler {

    private final RedisTemplate<String, String> redisTemplate;
    private final DataRepository dataRepository;

    public RedisToDbScheduler(RedisTemplate<String, String> redisTemplate, DataRepository dataRepository) {
        this.redisTemplate = redisTemplate;
        this.dataRepository = dataRepository;
    }

    @Scheduled(fixedRate = 5000) // 5초마다 실행
    public void processRedisKeys() {
        Set<String> keys = redisTemplate.keys("data_*");

        if (keys != null && !keys.isEmpty()) {
            // 가장 오래된 Key 정렬 후 처리
            List<String> sortedKeys = keys.stream().sorted().toList();

            int totalProcessed = 0;
            List<String> batchData = new ArrayList<>();

            for (String key : sortedKeys) {
                // 현재 Key의 데이터 가져오기
                List<String> dataList = redisTemplate.opsForList().range(key, 0, -1);

                if (dataList != null && !dataList.isEmpty()) {
                    batchData.addAll(dataList);
                    totalProcessed += dataList.size();

                    // Key 삭제
                    redisTemplate.delete(key);

                    // 3000개 이상 채워지면 DB에 INSERT 후 종료
                    if (totalProcessed >= 3000) {
                        break;
                    }
                }
            }

            // 배치 INSERT
            if (!batchData.isEmpty()) {
                List<DataEntity> entities = batchData.stream()
                        .map(data -> new DataEntity(data))
                        .collect(Collectors.toList());
                dataRepository.saveAll(entities);
            }
        }
    }
}

4. 장점과 단점

장점

부하 분산:
- Redis를 완충 버퍼로 사용해 트래픽 몰림 방지.
- DB는 3000개 단위로 배치 처리하여 성능 최적화.
데이터 유실 방지:
- Redis에 데이터를 저장 후 처리하므로 실시간 데이터 유실 가능성 낮음.
확장성:
- Redis Cluster와 함께 사용하면 높은 트래픽도 안정적으로 처리 가능.

단점

Key 관리 복잡성:
- Key 개수가 많아지면 스케줄러 처리 비용 증가.
스케줄 주기 조정 필요:
- 트래픽 상황에 따라 5초 주기가 너무 짧거나 길 수 있음.
Redis 부하:
- 과도한 트래픽으로 인한 Redis 부하가 발생할 수 있음.
Redis 설정 복잡성
- Redis의 원자성과 격리성을 보장하기 위해 추가 설정이 필요할 수 도 있음.

개선방안

Kafka 사용
- 다음 글에서는 Kafka 메시지 큐를 통해 사용해 보다 효율적으로 처리하는 방법을 정리해 보도록 하겠습니다.

5. 정리

Redis 데이터 저장 로직
- 최근 키 확인 후, 조건에 따라 데이터 저장 또는 새 키 생성.
스케줄링으로 데이터 처리
- Redis에서 오래된 데이터를 배치로 가져와 DB에 저장.
Kafka 도입으로 개선
- 메시지 큐를 통해 트래픽 분산 및 병렬 처리로 성능 최적화.

[JAVA] Spring 테스트 : Mock VS MockBean

TaeHuiLee — Mon, 13 Jan 2025 19:49:19 +0900

이전 글에서 Spring에서의 단위테스트와 통합테스트에 대해 간략하게 정리해 보았습니다.

[JAVA] Spring을 이용한 테스트 코드 작성 방법 (단위 테스트, 통합 테스트)

소프트웨어 개발에서 테스트 코드는 단순히 오류를 찾는 도구를 넘어, CI/CD(Continuous Integration/Continuous Deployment) 파이프라인과 개발 생산성 향상에 핵심적인 역할을 합니다.이 글에서는 JPA를 사용

tae-hui.tistory.com

이번 글에서는 해당 내용에 대해 조금 더 깊에 알아보려고 합니다. 특히, Mock 객체와 MockBean의 차이점, 통합테스트에서의 Application Context 초기화, 그리고 성능 최적화 방법을 자세히 정리했습니다.

1. Spring 테스트의 기본: `@SpringBootTest`

`@SpringBootTest`란?

@SpringBootTest는 Spring Boot 애플리케이션 전체를 초기화하며, 통합 테스트를 위한 환경을 제공합니다. 이 애노테이션을 선언하면 애플리케이션 컨텍스트(Application Context)가 생성되고, 컨텍스트에 등록된 @Service, @Repository, @Component 같은 빈들을 사용할 수 있습니다.

️ Application Context 초기화의 특징

Application Context는 등록된 빈만 사용 가능: @SpringBootTest는 애플리케이션 전체 컨텍스트를 초기화하기 때문에, 테스트 대상 클래스에서 등록되지 않은 빈은 사용할 수 없습니다.
모든 의존성이 반드시 빈이어야 함: 테스트 클래스에서 의존성을 주입받으려면, 해당 의존성이 반드시 Application Context에 등록되어 있어야 합니다.

장점

실제 환경과 유사한 테스트 환경 제공: 실제 애플리케이션과 동일한 컨텍스트에서 동작합니다.
빈 의존성 테스트 가능: 의존성 주입이나 컨텍스트 설정이 올바른지 확인할 수 있습니다.

단점

속도가 상대적으로 느림: 애플리케이션 컨텍스트를 초기화하는 데 시간이 걸리기 때문에, 작은 단위 테스트보다는 통합 테스트에 적합합니다.

사용 예시

@SpringBootTest
public class ExampleServiceTest {

    @Autowired
    private ExampleService exampleService;

    @Test
    public void testServiceLogic() {
        String result = exampleService.doSomething();
        assertEquals("ExpectedValue", result);
    }
}

Tip: @SpringBootTest는 애플리케이션 전체를 테스트할 때 유용합니다. 하지만 모든 테스트에서 사용하면 속도 문제가 생길 수 있으니 필요한 경우에만 해야합니다.

2. ️ `@MockBean`: Mock 객체를 Application Context에 등록하기

`@MockBean`의 역할

@MockBean은 Spring의 Mock 객체를 Application Context에 등록하는 방법입니다. 실제 빈 대신 Mock 객체를 주입하여 테스트에 활용할 수 있습니다.

주요 특징

Mock 객체를 사용하면서도, Spring 컨텍스트와 연동된 테스트를 수행할 수 있습니다.
Mock 객체의 동작을 정의하여 원하는 시나리오를 검증할 수 있습니다.

사용 예시

@SpringBootTest
public class ExampleServiceTest {

    @MockBean
    private ExampleRepository exampleRepository;

    @Autowired
    private ExampleService exampleService;

    @Test
    public void testMockRepository() {
        // Mock 동작 정의
        when(exampleRepository.getData()).thenReturn("MockData");

        String result = exampleService.processData();
        assertEquals("Processed MockData", result);
    }
}

장점

통합 테스트 가능: Mock 객체를 주입하더라도 실제 컨텍스트를 초기화하여 전반적인 시스템을 테스트할 수 있습니다.
테스트 대상의 의존성 대체: 특정 클래스의 테스트에서만 Mock 객체를 사용하고, 나머지는 실제 빈으로 동작합니다.

단점

@SpringBootTest와 함께 사용되므로 테스트 속도가 느릴 수 있습니다.

3. `@Mock`과 `@InjectMocks`: Mockito 기반의 단위 테스트

`@Mock`과 `@InjectMocks`란?

@Mock은 Mock 객체를 생성하고, @InjectMocks는 해당 Mock 객체를 주입하여 테스트 대상을 초기화합니다. Spring 컨텍스트를 전혀 사용하지 않고 순수하게 Mockito 프레임워크만으로 테스트를 수행합니다.

사용 예시

@RunWith(MockitoJUnitRunner.class)
public class ExampleServiceTest {

    @Mock
    private ExampleRepository exampleRepository;

    @InjectMocks
    private ExampleService exampleService;

    @Test
    public void testUsingMockito() {
        // Mock 동작 정의
        when(exampleRepository.getData()).thenReturn("MockData");

        String result = exampleService.processData();
        assertEquals("Processed MockData", result);
    }
}

장점

빠른 테스트 속도: Spring 컨텍스트를 초기화하지 않아 매우 빠릅니다.
간단한 구조: 단위 테스트 작성이 용이하며, 특정 메서드나 클래스의 동작을 독립적으로 검증할 수 있습니다.

단점

Spring 컨텍스트를 활용하지 않기 때문에, 빈의 의존성이나 설정 검증은 불가능합니다.

4. `@SpringBootTest` vs Mockito 테스트: 언제 사용할까?

`@SpringBootTest`를 사용하는 상황

통합 테스트가 필요한 경우: 여러 계층(Service, Repository 등)을 함께 테스트해야 할 때.
빈 의존성 확인: 의존성 주입 및 설정이 올바른지 확인해야 할 때.
Spring Boot 애플리케이션 전체 동작 검증: 실제 환경과 유사한 테스트 환경이 필요할 때.

Mockito 기반 테스트를 사용하는 상황

단위 테스트: 특정 메서드나 클래스만 독립적으로 검증해야 할 때.
빠른 테스트가 필요한 경우: 컨텍스트 초기화 없이 간단히 동작을 확인할 때.

5. 성능 최적화: `@SpringBootTest`를 사용할 때 주의할 점

@SpringBootTest를 사용하면 Application Context의 초기화가 일어나기 때문에 속도가 느릴 수 있습니다. 하지만 Spring Boot는 컨텍스트 캐싱을 활용하여 동일한 컨텍스트를 재사용하므로, 설정이 변경되지 않는 한 성능 문제가 심각하지 않습니다.

초기화가 일어나는 경우

설정이 다르거나 캐싱 조건을 만족하지 못하는 경우
다른 프로파일 사용

@ActiveProfiles로 지정된 프로파일이 다르면 별도의 Context를 초기화합니다.

다른 설정 클래스

@SpringBootTest(classes = ...)로 지정된 설정이 다르면 매번 초기화합니다.

@DirtiesContext 사용

특정 테스트가 Context를 더럽혔다고 표시하면, 이후 테스트는 새로운 Context를 초기화합니다.

성능 최적화 팁

WebEnvironment 설정: 테스트 환경의 WebEnvironment를 NONE으로 설정하면 불필요한 서버 초기화를 방지할 수 있습니다.
@SpringBootTest(webEnvironment = WebEnvironment.NONE) public class ExampleServiceTest { // Test logic here }
테스트 분리: 통합 테스트(@SpringBootTest)와 단위 테스트(Mockito 기반)를 명확히 분리하여 필요 이상으로 컨텍스트를 초기화하지 않도록 합니다.

6. 정리: Mock VS MockBean 비교표

항목	`@MockBean`	`@Mock` + `@InjectMocks`
Spring Context 초기화 여부	초기화함	초기화하지 않음
테스트 속도	상대적으로 느림	매우 빠름
빈 의존성 테스트	가능	불가능
사용 용도	통합 테스트	단위 테스트

핵심 요약

@SpringBootTest: 애플리케이션 전체 컨텍스트를 초기화하기 때문에, 테스트 대상 클래스에서 등록되지 않은 빈은 사용할 수 없다.
@MockBean: 통합 테스트에서 유용하며, Application Context와 연동된 Mock 객체를 생성합니다.
@Mock: 빠른 단위 테스트에 적합하며, Spring과 독립적으로 동작합니다.

[JAVA] Spring을 이용한 테스트 코드 작성 방법 (단위 테스트, 통합 테스트)

TaeHuiLee — Sat, 11 Jan 2025 08:00:02 +0900

소프트웨어 개발에서 테스트 코드는 단순히 오류를 찾는 도구를 넘어, CI/CD(Continuous Integration/Continuous Deployment) 파이프라인과 개발 생산성 향상에 핵심적인 역할을 합니다.
이 글에서는 JPA를 사용한 DB 연결 후 테스트를 작성하는 방법을 단계별로 알아보겠습니다.

1. 단위 테스트와 통합 테스트의 차이

✅ 단위 테스트(Unit Test)

목적: 메서드, 클래스 등 작은 단위의 코드가 올바르게 동작하는지 검증.
도구: JUnit, Mockito 등.
실행 방식:
- @ExtendWith, @Mock, @InjectMocks 등을 활용하여 외부 의존성을 모킹(Mock).
- 테스트 환경에서 빠르게 검증.

✅ 통합 테스트(Integration Test)

목적: 여러 구성 요소(Controller, Service, Repository 등)가 올바르게 협력하는지 검증.
도구: Spring Boot Test, H2 Database.
실행 방식:
- @SpringBootTest를 활용하여 애플리케이션 컨텍스트를 로드.
- 실제 데이터베이스와 연결하거나 테스트용 메모리 데이터베이스 사용.

2. 준비 사항

2.1 의존성 추가 (Maven 기준)

테스트를 위한 주요 라이브러리를 추가합니다.

의존성을 pom.xml 파일에 추가합니다.

<dependencies>
    <!-- Spring Boot Starter Test -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>

    <!-- Spring Data JPA -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
    </dependency>

    <!-- H2 Database (테스트용) -->
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <scope>runtime</scope>
    </dependency>
</dependencies>

2.2 테스트 환경 설정 (`application.yml`)

테스트 전용 데이터베이스를 설정합니다. 여기서는 H2를 사용합니다.

`application-test.yml`

spring:
  datasource:
    url: jdbc:h2:mem:testdb
    driver-class-name: org.h2.Driver
    username: sa
    password: 
  jpa:
    hibernate:
      ddl-auto: create-drop
    show-sql: true

3. 단위 테스트 작성하기

단위 테스트에서는 데이터베이스 대신 Mock을 활용합니다. 예제로 간단한 UserService의 단위 테스트를 작성해 볼게요.

3.1 User 엔티티 및 리포지토리

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;
    private String email;

    // Getters and Setters
}

@Repository
public interface UserRepository extends JpaRepository<User, Long> {}

3.2 UserService

@Service
public class UserService {
    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public User createUser(String name, String email) {
        User user = new User();
        user.setName(name);
        user.setEmail(email);
        return userRepository.save(user);
    }
}

3.3 UserService 단위 테스트 작성

@ExtendWith(MockitoExtension.class)
public class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    void testCreateUser() {
        // Given
        String name = "John";
        String email = "john@example.com";
        User user = new User();
        user.setName(name);
        user.setEmail(email);

        when(userRepository.save(any(User.class))).thenReturn(user);

        // When
        User createdUser = userService.createUser(name, email);

        // Then
        assertEquals(name, createdUser.getName());
        assertEquals(email, createdUser.getEmail());
        verify(userRepository, times(1)).save(any(User.class));
    }
}

✅ `@ExtendWith(MockitoExtension.class)`

설명:
- JUnit 5(=JUnit Jupiter)와 Mockito를 통합해 사용할 때 필요한 어노테이션입니다.
- Mockito에서 제공하는 Mock 객체를 테스트 클래스에 주입할 수 있도록 설정합니다.
사용 시점:
- 단위 테스트에서 Mockito를 사용하여 테스트 대상을 모킹(Mocking)할 때 사용합니다.

✅ `@Mock`

설명:
- Mockito에서 제공하는 어노테이션으로, 가짜 객체(Mock)를 생성합니다.
- 실제 객체 대신 Mock 객체를 사용하여 외부 의존성을 제거하고 코드의 특정 부분만 테스트할 수 있습니다.
사용 시점:
- 리포지토리, API 호출 등 실제 객체와 상호작용하지 않고 원하는 동작을 시뮬레이션할 때.

✅ `@InjectMocks`

설명:
- Mockito에서 제공하는 어노테이션으로, 테스트 대상 클래스에 Mock 객체를 주입합니다.
- @Mock으로 생성된 Mock 객체를 테스트 대상 클래스의 생성자나 필드에 자동으로 주입합니다.
사용 시점:
- 테스트 대상 클래스에 의존성 주입(DI)이 필요한 경우.

4. 통합 테스트 작성하기

통합 테스트에서는 실제 데이터베이스와 연결된 환경에서 테스트를 실행합니다.

4.1 통합 테스트 설정

@SpringBootTest와 @Transactional 어노테이션을 활용해 통합 테스트를 작성합니다.

@SpringBootTest
@Transactional
 @ActiveProfiles("test") // test 프로파일 활성화
public class UserIntegrationTest {

    @Autowired
    private UserRepository userRepository;

    @Test
    void testSaveAndFindUser() {
        // Given
        User user = new User();
        user.setName("Alice");
        user.setEmail("alice@example.com");

        // When
        userRepository.save(user);
        Optional<User> foundUser = userRepository.findById(user.getId());

        // Then
        assertTrue(foundUser.isPresent());
        assertEquals("Alice", foundUser.get().getName());
        assertEquals("alice@example.com", foundUser.get().getEmail());
    }
}

✅ `@SpringBootTest`

설명:
- Spring Boot 통합 테스트를 실행하기 위한 어노테이션입니다.
- 애플리케이션 전체 컨텍스트를 로드하고 테스트를 수행합니다.
사용 시점:
- 여러 Bean 간의 상호작용 및 애플리케이션 전반적인 통합 테스트를 실행할 때.

✅ `@Transactional`

설명:
- 테스트 실행 중 데이터 변경 사항을 롤백하도록 설정합니다.
- 테스트마다 새로운 트랜잭션이 생성되고, 테스트가 끝나면 데이터베이스 상태를 초기화합니다.
사용 시점:
- 데이터베이스를 사용하는 통합 테스트에서 DB 상태를 초기화해야 할 때.

✅ `@ActiveProfiles`

설명:
- 특정 Spring Profile을 활성화하도록 설정합니다.
- 이를 통해 테스트 환경, 개발 환경 등 환경별 설정을 분리할 수 있습니다.
사용 시점:
- application-test.yml과 같은 테스트 전용 설정 파일을 적용하고 싶을 때.

5. 정리: 단위 테스트와 통합 테스트의 핵심 비교

특징	단위 테스트	통합 테스트
목적	특정 단위의 독립적 검증	시스템의 통합된 흐름 검증
외부 의존성	Mock 객체 사용	실제 데이터베이스 사용
실행 속도	빠름	상대적으로 느림
어노테이션	`@ExtendWith(MockitoExtension.class)`	`@SpringBootTest`, `@Transactional`

단위 테스트는 빠르게 개발 주기를 반복할 때 유용하며, 통합 테스트는 실제 환경과의 상호작용을 검증하는 데 필수적입니다.

[GIT] Git 히스토리 이메일 및 이름 수정

TaeHuiLee — Wed, 1 Jan 2025 08:00:18 +0900

Git을 사용하다 히스토리에 기록된 이메일과 이름 정보를 수정할 일이 생겨 이참에 수정 방법에 대해 포스팅해보려고합니다

주의: 작업 환경 준비

기존 프로젝트에 직접 작업하지 마세요!
다음 절차를 따라 새로 클론한 저장소에서 작업을 진행하세요.

현재 작업 중인 프로젝트가 있다면 변경사항을 커밋하거나 백업하세요.
원격 저장소를 새 폴더에 클론합니다:
git clone <원격 저장소 URL> <새 폴더 이름>
새로 클론한 저장소에서 아래의 모든 작업을 진행하세요.

1. `git filter-repo` 설치

git filter-repo는 Git의 기본 명령어에 포함되지 않으므로 별도로 설치해야 합니다.

1.1. Python 설치 여부 확인

먼저 Python이 설치되어 있는지 확인합니다:

python --version

또는:

python3 --version

팁: Python이 설치되지 않았다면 Python 공식 웹사이트에서 설치하세요. 설치 시 pip(Python 패키지 관리자)도 함께 설치되었는지 확인하세요.

️ 1.2. pip를 통해 `git filter-repo` 설치

Python과 pip가 준비되었다면, 아래 명령어로 git-filter-repo를 설치합니다.

pip install git-filter-repo

✅ 1.3. 설치 확인

설치가 완료되었는지 아래 명령어로 확인합니다:

git filter-repo --version

2. 수정 대상 데이터 확인하기

2.1. 이메일 및 이름 데이터 확인

히스토리에서 이메일과 이름 정보를 확인합니다.
다음 명령어를 실행하여 필요한 데이터를 확인하세요:

git log --all --format="%h - author: %an <%ae> / committer: %cn <%ce>"

출력 예시:

abc123 - author: John Doe <johndoe@example.com> / committer: Jane Smith <janesmith@example.com>

팁: 결과에서 수정하고자 하는 이메일과 이름을 찾아 emails_to_update 리스트에 추가하세요.

3. Git 히스토리 이메일 및 이름 수정

git filter-repo를 사용하여 이메일과 이름을 수정합니다.
아래는 Test용 데이터로 작성된 스크립트입니다.

3.1. `git filter-repo` 실행

아래 코드를 사용해 이메일과 이름을 수정하세요:

git filter-repo --force --commit-callback "
# 수정 대상 이메일 및 이름
old_emails = ['oldemail@example.com', 'testuser@example.com']  # 기존 이메일
new_email = 'newemail@example.com'  # 변경할 이메일

old_names = ['Old Name', 'Test User']  # 기존 이름
new_name = 'New User'  # 변경할 이름

# 바이트 문자열을 일반 문자열로 변환
def to_str(byte_str):
    return byte_str.decode('utf-8') if isinstance(byte_str, bytes) else byte_str

# 일반 문자열을 바이트 문자열로 변환
def to_bytes(string):
    return string.encode('utf-8') if isinstance(string, str) else string

with open('filter-repo-debug.log', 'a') as log_file:
    # 이메일 및 이름 가져오기
    author_email = to_str(commit.author_email)
    committer_email = to_str(commit.committer_email)
    author_name = to_str(commit.author_name)
    committer_name = to_str(commit.committer_name)

    # 로그 기록
    log_file.write(f'Processing commit: {author_email}, {committer_email}, {author_name}, {committer_name}\\n')

    # 이메일 수정
    if author_email in old_emails:
        log_file.write(f'Updating author_email: {author_email} -> {new_email}\\n')
        commit.author_email = to_bytes(new_email)

    if committer_email in old_emails:
        log_file.write(f'Updating committer_email: {committer_email} -> {new_email}\\n')
        commit.committer_email = to_bytes(new_email)

    # 이름 수정
    if author_name in old_names:
        log_file.write(f'Updating author_name: {author_name} -> {new_name}\\n')
        commit.author_name = to_bytes(new_name)

    if committer_name in old_names:
        log_file.write(f'Updating committer_name: {committer_name} -> {new_name}\\n')
        commit.committer_name = to_bytes(new_name)
"

3.2. 결과 확인

수정된 이메일과 이름 정보를 확인합니다:

git log --all --format="%h - author: %an <%ae> / committer: %cn <%ce>"

4. 원격 저장소 다시 설정

git filter-repo를 사용한 경우 원격 저장소(remote)와 로컬 저장소의 커밋 히스토리가 달라집니다.
따라서 원격 저장소를 다시 설정하거나 강제로 푸시해야 합니다.

4.1. 기존 원격 저장소 백업

기존 원격 저장소를 백업하거나 이름을 변경해 데이터 유실을 방지합니다.

git remote rename origin origin-backup

팁: 원격 저장소를 백업하지 않아도 괜찮다면 이 단계는 생략 가능합니다.

4.2. 원격 저장소 재설정

수정된 로컬 저장소를 새로운 원격 저장소에 연결합니다.

git remote add origin <원격 저장소 URL>

4.3. 강제 푸시

수정된 히스토리를 원격 저장소에 강제로 푸시합니다.

git push origin main --force

팁: --force 또는 --force-with-lease 옵션을 사용하세요. 강제 푸시는 기존 히스토리를 덮어쓰기 때문에 협업 중인 경우 팀원들에게 반드시 사전 안내를 해야 합니다.

4.4. 최종 확인

원격 저장소에 수정된 내용이 정상적으로 반영되었는지 확인합니다.

git log origin/main --oneline

5. 캐시와 불필요한 데이터 정리

Git 저장소의 캐시와 임시 데이터를 정리합니다.

rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now --aggressive

6. 팀원에게 안내하기

6.1. 팀원의 로컬 저장소 초기화

팀원들은 기존 로컬 저장소가 새로운 히스토리와 충돌하지 않도록 초기화 후 다시 클론해야 합니다.

rm -rf <로컬 저장소 폴더>
git clone <원격 저장소 URL>

중요: 반드시 새로운 저장소를 기반으로 작업해야 합니다.
기존 원격 저장소를 대체했다면 팀원들에게 이를 공지하세요.

✨ 정리

클론 작업: 기존 프로젝트에 작업하지 말고 새로운 클론 저장소를 생성.
설치: Python 설치 여부 확인 → pip로 git filter-repo 설치.
데이터 확인: git log를 사용해 이메일과 이름 정보를 확인.
수정 작업: git filter-repo 스크립트를 실행하여 이메일과 이름 수정.
원격 저장소 재설정: 기존 원격 저장소를 백업 후 재설정 및 강제 푸시.
정리: 불필요한 캐시와 데이터를 정리.
팀원 안내: 새로 생성된 원격 저장소에 클론하도록 안내.

[JAVA] ArrayList vs LinkedList 완벽 정리

TaeHuiLee — Tue, 31 Dec 2024 08:00:07 +0900

1. ArrayList와 LinkedList의 성능 차이

ArrayList와 LinkedList는 중간 삽입/삭제의 시간 복잡도가 모두 O(N)으로 동일합니다. 하지만 실제로는 ArrayList가 더 빠른 경우가 많습니다.

ArrayList:
- 내부적으로 배열을 사용하며, 연속된 메모리에 데이터를 저장합니다.
- 특정 위치를 찾는 데 O(1)로 빠르며, 삽입/삭제 시 데이터 이동이 발생하지만, 캐시 최적화 효과로 인해 성능이 더 좋습니다.
LinkedList:
- 노드 기반 자료구조로, 삽입/삭제는 연결만 변경하면 되지만 특정 위치를 탐색하는 데 O(N)이 걸립니다.
- 메모리가 비연속적이어서 캐시 효율이 떨어지고, 실제로 더 느릴 수 있습니다.

결론: 이론적으로 LinkedList가 유리할 것 같지만, 캐시 친화적인 ArrayList가 더 빠른 경우가 많습니다.

2. 삽입/삭제가 빈번할 때 ArrayList가 더 빠른 이유

"삽입/삭제가 많다면 LinkedList가 더 적합하다"는 말을 들어본 적 있으시죠? 이론적으로는 맞지만, 현실에서는 ArrayList가 더 나은 경우가 많습니다.

ArrayList의 경우:
- 삽입/삭제 시 요소를 밀거나 당기기만 하면 됩니다.
- 연속된 메모리를 사용하므로 CPU 캐시 효율이 좋아 성능이 더 빠를 때가 많습니다.
LinkedList의 경우:
- 삽입/삭제 위치를 찾기 위해 순차 탐색이 필요합니다.
- 노드 추가/삭제 시 포인터를 조작하는 작업이 필요해, 삽입/삭제만큼 비용이 더 들어갈 수 있습니다.

정리: 삽입/삭제 작업만을 보더라도, ArrayList의 캐시 효율로 인해 실제로 더 나은 성능을 보이는 경우가 많습니다.

3. 앞뒤 삽입/삭제도 ArrayList가 더 빠를까?

앞이나 뒤에 데이터를 삽입/삭제하는 경우, 성능 차이는 작업 위치에 따라 다릅니다.

뒤쪽 삽입/삭제:
- ArrayList와 LinkedList 모두 O(1)로 수행됩니다.
- ArrayList는 배열 끝에 포인터를 변경하면 끝이고, LinkedList도 마지막 노드에 연결하면 끝나기 때문입니다.
앞쪽 삽입/삭제:
- ArrayList: 첫 번째 위치에 삽입/삭제 시 모든 요소를 한 칸씩 이동해야 하므로 O(N)입니다.
- LinkedList: 첫 번째 노드의 포인터만 변경하면 되므로 O(1)입니다.

결론: 앞쪽 삽입/삭제는 LinkedList가 더 빠르지만, 뒤쪽 삽입/삭제는 둘 다 O(1)으로 비슷한 성능을 보입니다.

4. 기본 용량

ArrayList: 초기 용량(기본 10) 설정 후, 용량 초과 시 기존 용량의 1.5배로 배열을 확장합니다.
LinkedList: 별도의 초기 용량 개념이 없으며, 필요한 경우에 노드를 동적으로 생성합니다.

5. LinkedList와 ArrayList의 구조적 차이

✨ ArrayList

내부적으로 동적 배열로 구성됩니다.
메모리가 연속적으로 배치되어 있어 CPU 캐시 효율이 높습니다.
삽입/삭제 시 데이터 이동이 필요합니다.

✨ LinkedList

각각의 요소가 노드로 존재하며, 각 노드가 다음/이전 노드를 가리키는 포인터를 가집니다.
메모리가 비연속적으로 배치되므로 캐시 효율이 낮습니다.
삽입/삭제 시 노드 연결만 변경하면 되므로 비용이 낮습니다.

6. 왜 LinkedList가 캐시 친화적이지 않은가?

LinkedList는 각 노드가 비연속적인 메모리에 저장됩니다.
이 때문에 캐시 지역성(Cache Locality)이 떨어지게 됩니다.

ArrayList는 배열로 연속적으로 데이터를 저장하므로 캐시 친화적입니다. 하지만, LinkedList는 포인터를 따라가며 노드를 탐색해야 하므로 캐시 효율이 낮아지고 속도가 느려질 수 있습니다.

7. 언제 LinkedList를 선택해야 하나?

LinkedList를 선택하는 경우는 아래와 같습니다.

삽입/삭제가 매우 빈번하고 특정 위치 탐색이 거의 없는 경우
정확한 메모리 관리가 필요한 경우 (각 노드가 독립적으로 관리되므로 필요 없는 노드를 빠르게 제거할 수 있음)
메모리 크기 확장이 자주 일어나는 상황 (ArrayList는 배열 크기 확장이 발생할 때 성능 저하가 생길 수 있음)

하지만 대부분의 경우 ArrayList가 더 적합합니다.

✨ 핵심 요약

ArrayList는 배열 기반으로 캐시 효율이 좋아 대부분의 경우 더 빠릅니다.
LinkedList는 삽입/삭제가 많고 탐색이 거의 없는 경우에 적합합니다.
데이터의 접근 패턴과 삽입/삭제 빈도를 고려해 적절히 선택하세요!

[JAVA] PriorityQueue 설명 및 사용법

TaeHuiLee — Mon, 30 Dec 2024 08:00:56 +0900

PriorityQueue는 자바에서 제공하는 우선순위 큐(Priority Queue) 구현체로, 요소를 우선순위에 따라 자동으로 정렬하여 관리하는 자료구조입니다. 내부적으로 힙(Heap) 자료구조를 기반으로 하며, 최소 힙(Min-Heap)을 기본으로 사용합니다.

1. `PriorityQueue`란?

1.1 주요 특징

자동 정렬: 삽입된 요소는 우선순위에 따라 정렬됩니다.
(기본적으로 오름차순으로 정렬되며, 사용자 정의 정렬 순서를 지정할 수 있습니다.)
FIFO가 아닌 우선순위 기반 처리:
- 일반적인 큐(FIFO)와 다르게, 요소는 우선순위가 높은 순서대로 처리됩니다.
중복 요소 허용:
- 동일한 값을 여러 번 삽입할 수 있습니다.
내부적으로 힙(Heap) 자료구조를 사용하여 정렬 및 삽입/삭제 작업을 효율적으로 수행합니다.

2. `PriorityQueue` 주요 메서드

메서드	설명
`add(E e)`	큐에 요소 삽입 (성공 시 `true` 반환, 실패 시 예외 발생)
`offer(E e)`	큐에 요소 삽입 (성공 시 `true` 반환, 실패 시 `false` 반환)
`poll()`	우선순위가 가장 높은 요소를 제거하고 반환 (큐가 비어 있으면 `null`)
`remove()`	우선순위가 가장 높은 요소를 제거하고 반환 (큐가 비어 있으면 예외)
`peek()`	우선순위가 가장 높은 요소를 조회 (큐가 비어 있으면 `null`)
`element()`	우선순위가 가장 높은 요소를 조회 (큐가 비어 있으면 예외)

3. `PriorityQueue` 기본 사용법

3.1 기본 우선순위 (오름차순)

PriorityQueue는 기본적으로 요소를 오름차순으로 정렬합니다. 즉, 숫자가 작은 값이 가장 높은 우선순위를 가집니다.

코드 예제

import java.util.PriorityQueue;

public class PriorityQueueExample {
    public static void main(String[] args) {
        PriorityQueue<Integer> queue = new PriorityQueue<>();

        // 요소 삽입
        queue.add(30);
        queue.add(10);
        queue.add(20);

        // 우선순위가 가장 높은 요소부터 제거
        System.out.println(queue.poll()); // 출력: 10
        System.out.println(queue.poll()); // 출력: 20
        System.out.println(queue.poll()); // 출력: 30
    }
}

결과

요소가 10, 20, 30 순서로 정렬되어 반환됩니다.

3.2 사용자 정의 정렬

우선순위를 직접 정의하려면 Comparator를 제공해야 합니다. 예를 들어, 내림차순 또는 사용자 정의 객체를 기준으로 정렬할 수 있습니다.

내림차순 정렬

import java.util.PriorityQueue;
import java.util.Comparator;

public class PriorityQueueDescendingExample {
    public static void main(String[] args) {
        // 내림차순 정렬
        PriorityQueue<Integer> queue = new PriorityQueue<>(Comparator.reverseOrder());

        // 요소 삽입
        queue.add(30);
        queue.add(10);
        queue.add(20);

        // 출력
        while (!queue.isEmpty()) {
            System.out.println(queue.poll()); // 30, 20, 10
        }
    }
}

사용자 정의 객체 정렬

예를 들어, 학생 객체(Student)를 점수(grade)에 따라 정렬한다고 가정해 봅시다.

import java.util.PriorityQueue;
import java.util.Comparator;

class Student {
    String name;
    int grade;

    public Student(String name, int grade) {
        this.name = name;
        this.grade = grade;
    }

    @Override
    public String toString() {
        return name + " (" + grade + ")";
    }
}

public class PriorityQueueCustomObjectExample {
    public static void main(String[] args) {
        // 점수(grade) 오름차순 정렬
        PriorityQueue<Student> queue = new PriorityQueue<>(Comparator.comparingInt(s -> s.grade));

        // 학생 데이터 삽입
        queue.add(new Student("Alice", 85));
        queue.add(new Student("Bob", 92));
        queue.add(new Student("Charlie", 78));

        // 출력
        while (!queue.isEmpty()) {
            System.out.println(queue.poll()); // Charlie (78), Alice (85), Bob (92)
        }
    }
}

내림차순으로 사용자 정의 객체 정렬

import java.util.PriorityQueue;
import java.util.Comparator;

public class PriorityQueueDescendingCustomObjectExample {
    public static void main(String[] args) {
        // 점수(grade) 내림차순 정렬
        PriorityQueue<Student> queue = new PriorityQueue<>((s1, s2) -> s2.grade - s1.grade);

        // 학생 데이터 삽입
        queue.add(new Student("Alice", 85));
        queue.add(new Student("Bob", 92));
        queue.add(new Student("Charlie", 78));

        // 출력
        while (!queue.isEmpty()) {
            System.out.println(queue.poll()); // Bob (92), Alice (85), Charlie (78)
        }
    }
}

4. ️ 내부 동작 원리

4.1 힙(Heap) 자료구조

PriorityQueue는 내부적으로 힙(Heap) 자료구조를 사용하여 요소를 정렬합니다.

기본 구현은 최소 힙(Min-Heap)으로, 루트 노드가 가장 작은 값을 가집니다.
삽입(add)과 삭제(poll) 시, 힙의 성질을 유지하기 위해 O(log n) 시간 복잡도를 가집니다.

5. 제한 사항 및 주의점

5.1 요소의 순서 보장

PriorityQueue는 삽입 순서를 유지하지 않습니다.
오직 우선순위에 기반하여 요소를 정렬하고 처리합니다.

5.2 중간 요소 접근

특정 인덱스에 있는 요소를 조회하거나 삭제할 수 없습니다.
큐의 가장 높은 우선순위 요소만 peek() 또는 poll()로 접근 가능합니다.

5.3 정렬 방식

기본 정렬은 자연 정렬 순서(오름차순)이며, 사용자 정의 Comparator로 변경할 수 있습니다.

6. ⚡ `PriorityQueue`와 다른 큐 구현체 비교

구현체	내부 구조	삽입/삭제 성능	요소 정렬	FIFO	LIFO	우선순위 기반
`PriorityQueue`	힙	O(log n)	✅	❌	❌	✅
`ArrayDeque`	배열	O(1)	❌	✅	✅	❌
`LinkedList`	연결 리스트	O(1)	❌	✅	✅	❌

7. 요약 및 활용 사례

단순 우선순위 작업:
- 기본 우선순위 정렬이 필요한 경우 PriorityQueue를 사용하세요.
사용자 정의 정렬:
- Comparator를 활용하여 원하는 정렬 기준을 구현하세요.
활용 사례:
- 작업 스케줄링
- 최단 경로 알고리즘(예: 다익스트라)
- 데이터 스트림 처리

PriorityQueue는 우선순위가 중요한 모든 상황에서 효율적으로 활용할 수 있는 자료구조입니다.

[JAVA] Queue와 Deque 무엇이 좋을까?

TaeHuiLee — Fri, 27 Dec 2024 08:00:52 +0900

자바에서 Queue 인터페이스는 기본적인 단방향 큐(FIFO)를 정의하는데 사용됩니다. 하지만, 실제로 Queue 대신 Deque를 사용하여 동일한 동작을 구현해도 성능에 문제가 없습니다. Deque는 큐와 스택 동작을 모두 지원하므로, Queue의 모든 기능을 충분히 대체할 수 있습니다.

1. `Queue`와 `Deque`의 차이

1.1 `Queue`의 특징

단방향 삽입/삭제만 가능하며, FIFO(First In, First Out) 동작을 따릅니다.
주요 메서드:
- 삽입: add(E e), offer(E e)
- 삭제: poll(), remove()
- 조회: peek(), element()

1.2 `Deque`의 특징

양방향 삽입/삭제가 가능하지만, 단방향 동작도 구현 가능합니다.
Deque를 단방향 큐로 사용하면, Queue의 모든 기능을 대체할 수 있습니다.
주요 메서드:
- 삽입: addLast(E e) (뒤쪽 삽입, Queue의 offer와 동일)
- 삭제: pollFirst() (앞쪽 삭제, Queue의 poll과 동일)
- 조회: peekFirst() (앞쪽 조회, Queue의 peek과 동일)

2. `Deque`를 사용하여 `Queue` 동작 구현

코드 예제

import java.util.ArrayDeque;
import java.util.Deque;

public class DequeAsQueueExample {
    public static void main(String[] args) {
        Deque<Integer> deque = new ArrayDeque<>();

        // 큐의 삽입 동작
        deque.addLast(10); // Queue의 offer()와 동일
        deque.addLast(20);
        deque.addLast(30);

        // 큐의 삭제 동작
        System.out.println(deque.pollFirst()); // 출력: 10 (Queue의 poll()과 동일)
        System.out.println(deque.peekFirst()); // 출력: 20 (Queue의 peek()과 동일)

        // 남은 요소 출력
        System.out.println(deque); // 출력: [20, 30]
    }
}

3. `Deque`로 구현할 때 성능 분석

Deque를 Queue처럼 사용할 때의 성능은 Queue 구현체와 동일하거나 더 효율적입니다. 특히, ArrayDeque와 LinkedList를 사용할 경우의 성능을 비교해 보면 다음과 같은 특징이 있습니다.

3.1 `ArrayDeque`의 성능

삽입/삭제:
- O(1): 양 끝에서의 삽입/삭제가 빠릅니다.
- ArrayDeque는 내부적으로 배열을 사용하므로 캐시 친화적이고 메모리 접근 속도가 빠릅니다.
동적 크기 조정:
- 큐의 크기가 가득 차면 내부 배열을 2배로 늘리는 동작이 발생하지만, 이는 삽입/삭제의 평균 성능에 큰 영향을 미치지 않습니다.

3.2 `LinkedList`의 성능

삽입/삭제:
- O(1): 양 끝에서 삽입/삭제가 빠릅니다.
메모리 오버헤드:
- 각 노드에 추가적인 포인터 메모리를 사용하므로, 배열 기반의 ArrayDeque보다 메모리를 더 사용합니다.

4. 왜 `Deque`를 사용하는 것이 괜찮은가?

4.1 `Queue` 대신 `Deque`를 사용하는 이유

더 많은 기능 지원:
- Deque는 양방향 삽입/삭제 기능을 지원하므로, 더 유연하게 동작할 수 있습니다.
- 하지만 단방향 동작만 구현해도 충분히 Queue를 대체할 수 있습니다.
성능 손실 없음:
- ArrayDeque나 LinkedList를 사용하여 Deque를 구현하면, Queue의 주요 구현체(LinkedList와 ArrayDeque)와 동일한 성능을 제공합니다.
캐시 친화적:
- ArrayDeque는 배열 기반이기 때문에 메모리 접근 속도가 빠르고, 대부분의 상황에서 LinkedList보다 효율적입니다.

5. ⚡ `Deque`와 `Queue` 구현체 비교

구현체	동작 방식	삽입/삭제 성능	중간 접근 성능	메모리 사용	특징
`Queue` + `LinkedList`	연결 리스트	O(1)	O(n)	높음	동적 크기, 삽입/삭제 효율적
`Queue` + `ArrayDeque`	배열	O(1)	O(n)	낮음	빠른 삽입/삭제, 캐시 친화적
`Deque` + `ArrayDeque`	배열	O(1)	O(n)	낮음	큐와 스택 모두 가능, 양방향 삽입/삭제 지원
`Deque` + `LinkedList`	연결 리스트	O(1)	O(n)	높음	큐와 스택 모두 가능, 유연한 크기 확장 가능

6. 요약

Deque로 Queue 구현하기:
- Deque를 사용하면 단방향 큐(Queue)의 동작을 그대로 구현할 수 있습니다.
- 예: addLast → offer, pollFirst → poll, peekFirst → peek.
성능 문제 없음:
- Deque를 사용하여 큐를 구현할 경우 성능은 동일하거나 더 효율적입니다.
- 특히 ArrayDeque는 캐시 친화적이고 빠른 삽입/삭제를 제공하므로, 대부분의 경우 추천됩니다.
선택 가이드:
- 단순한 큐 작업만 필요하다면 ArrayDeque를 사용하세요.
- 양방향 삽입/삭제가 필요하거나 더 유연한 사용이 필요하면 Deque 인터페이스로 구현하세요.
- 정렬이 필요하다면 Queue 인터페이스를 이용한 PriorityQueue 구현체를 사용해야합니다.

결론적으로, Deque는 Queue를 대체할 수 있는 충분히 강력하고 성능이 좋습니다.

[JAVA] @Transactional 알아보기 Part.3 #격리(Isolation)

TaeHuiLee — Thu, 26 Dec 2024 08:00:43 +0900

트랜잭션 격리 수준(Isolation Level)

격리 수준의 정의

격리 수준은 동시에 실행되는 트랜잭션 간의 데이터 충돌 방지 및 무결성 보장을 위해 설정하는 규칙입니다. 각 수준은 트랜잭션 성능과 일관성 사이에서 트레이드오프를 제공합니다.

격리 수준은 ANSI SQL 표준에 정의되어 있으며, Spring에서는 이를 데이터베이스에 전달하여 적용합니다.

격리 수준 설정 방법

Spring에서 @Transactional 어노테이션에 isolation 속성을 설정하여 격리 수준을 지정할 수 있습니다.

예시 코드

@Transactional(isolation = Isolation.READ_COMMITTED)
public void processData() {
    // 트랜잭션 동작
}

격리 수준 값과 특징

아래는 Spring과 ANSI SQL에서 제공하는 주요 격리 수준과 각 문제를 방지하는 방법입니다.

격리 수준	설명	방지되는 문제	발생 가능한 문제
`READ_UNCOMMITTED`	커밋되지 않은 데이터 읽기 가능	없음	Dirty Read 발생
`READ_COMMITTED`	커밋된 데이터만 읽기 가능	Dirty Read 방지	Non-Repeatable Read 발생
`REPEATABLE_READ`	동일 데이터 트랜잭션 동안 일관성 유지	Dirty Read, Non-Repeatable Read 방지	Phantom Read 발생
`SERIALIZABL`E	트랜잭션 순차 실행으로 완전 격리	Dirty Read, Non-Repeatable Read, Phantom Read 방지	성능 저하, 교착 상태 발생 가능

주요 문제와 격리 수준 적용 사례

1️⃣ Dirty Read (더티 읽기)

Dirty Read는 커밋되지 않은 데이터를 읽는 문제로, 롤백된 데이터가 다른 트랜잭션에 영향을 줄 수 있습니다.

문제 상황

트랜잭션 A가 데이터를 수정했으나 커밋하지 않음.
트랜잭션 B가 수정 중인 데이터를 읽음.
트랜잭션 A가 롤백되면, 트랜잭션 B는 잘못된 데이터를 사용하게 됨.

해결 방법

격리 수준을 READ_COMMITTED 이상으로 설정.

2️⃣ Non-Repeatable Read (불일치 읽기)

Non-Repeatable Read는 같은 데이터를 반복 조회할 때 값이 달라지는 문제입니다.

문제 상황

트랜잭션 A가 데이터를 읽음.
트랜잭션 B가 데이터를 수정하고 커밋.
트랜잭션 A가 같은 데이터를 다시 읽으면 값이 달라짐.

해결 방법

격리 수준을 REPEATABLE_READ 이상으로 설정.

3️⃣ Phantom Read (팬텀 읽기)

Phantom Read는 조건에 맞는 데이터 집합이 트랜잭션 도중에 변경되는 문제입니다.

문제 상황

트랜잭션 A가 WHERE 조건으로 데이터를 조회.
트랜잭션 B가 새로운 데이터를 추가하거나 삭제하고 커밋.
트랜잭션 A가 같은 조건으로 다시 조회하면 결과 집합이 달라짐.

해결 방법

격리 수준을 SERIALIZABLE로 설정.

격리 수준 예제

1️⃣ READ_UNCOMMITTED 예제 (Dirty Read 허용)

@Transactional(isolation = Isolation.READ_UNCOMMITTED)
public void processUncommittedData() {
    // 커밋되지 않은 데이터 읽기 가능
}

사용 사례: 성능이 가장 중요한 경우. 데이터 정확성보다 속도가 더 중요할 때 사용.
문제: Dirty Read 발생.

2️⃣ READ_COMMITTED 예제 (Dirty Read 방지)

@Transactional(isolation = Isolation.READ_COMMITTED)
public void processCommittedData() {
    // 커밋된 데이터만 읽기
}

사용 사례: 대부분의 애플리케이션에서 사용. 데이터 정확성을 어느 정도 보장하면서 성능 손실이 적음.
문제: Non-Repeatable Read 발생.

3️⃣ REPEATABLE_READ 예제 (Non-Repeatable Read 방지)

@Transactional(isolation = Isolation.REPEATABLE_READ)
public void processRepeatableData() {
    // 트랜잭션 동안 동일 데이터 일관성 유지
}

사용 사례: 데이터 정확성이 중요한 시스템(은행, 회계 시스템 등).
문제: Phantom Read 발생 가능.

4️⃣ SERIALIZABLE 예제 (팬텀 읽기 방지)

@Transactional(isolation = Isolation.SERIALIZABLE)
public void processSerializableData() {
    // 트랜잭션 순차 실행
}

사용 사례: 데이터 일관성이 가장 중요할 때(예: 금융 거래).
문제: 높은 동시성 요구 시스템에서는 성능 저하 발생 가능.

스냅샷과 MVCC (Multi-Version Concurrency Control)

스냅샷이란?

스냅샷은 트랜잭션이 시작된 시점의 데이터 상태를 캡처하여, 트랜잭션 동안 일관성을 유지합니다.

MVCC 동작 방식

스냅샷 데이터는 데이터베이스 엔진의 Undo Log 또는 메모리에 저장.
각 트랜잭션은 스냅샷을 기반으로 읽기 작업을 수행하므로 다른 트랜잭션의 변경에 영향을 받지 않음.

스냅샷 저장 위치

데이터베이스 서버의 메모리 또는 Undo Log에 저장.
WAS(Application Server)로 올라가지 않음.

격리 수준 선택 기준

성능이 중요한 경우: READ_UNCOMMITTED 또는 READ_COMMITTED.
데이터 정확성이 중요한 경우: REPEATABLE_READ.
가장 높은 일관성이 필요한 경우: SERIALIZABLE.

요약

트랜잭션 격리 수준
- READ_UNCOMMITTED: Dirty Read 허용. 성능 우선.
- READ_COMMITTED: Dirty Read 방지. 일반적인 설정.
- REPEATABLE_READ: Non-Repeatable Read 방지.
- SERIALIZABLE: 가장 높은 일관성 제공. 성능 저하 가능.
스냅샷과 MVCC
- 스냅샷 기반으로 읽기 일관성을 유지.
- Undo Log 또는 메모리에서 관리.
주요 문제와 해결 방법
- Dirty Read: READ_COMMITTED 이상.
- Non-Repeatable Read: REPEATABLE_READ 이상.
- Phantom Read: SERIALIZABLE.

[JAVA] @Transactional 알아보기 Part.2 #전파(Propagation)

TaeHuiLee — Tue, 24 Dec 2024 08:00:15 +0900

트랜잭션 전파(Propagation)란?

트랜잭션 전파(Propagation)는 트랜잭션의 존재 여부와 관계를 정의합니다.

현재 트랜잭션이 있는 경우 그 트랜잭션에 참여할지,
새로 트랜잭션을 생성할지,
트랜잭션 없이 실행할지를 결정합니다.

Spring에서 제공하는 전파 속성은 @Transactional 어노테이션의 propagation 속성으로 설정할 수 있습니다.

트랜잭션 전파와 격리 수준의 차이

전파(Propagation)

트랜잭션의 관계를 설정합니다.
예: 새로운 트랜잭션 생성, 기존 트랜잭션 참여 등.

격리 수준(Isolation Level)

동시에 실행되는 트랜잭션 간 데이터 접근 규칙을 설정합니다.
예: Dirty Read 방지, Repeatable Read 보장 등.

간단히: 전파는 트랜잭션의 관계, 격리 수준은 데이터 무결성을 관리.

트랜잭션 전파 속성의 종류와 동작 방식

Spring은 7가지 전파 속성을 제공합니다. 각 속성의 동작 방식을 살펴봅니다.

속성	설명
`REQUIRED`	(기본값) 기존 트랜잭션에 참여. 없으면 새로 생성.
`REQUIRES_NEW`	항상 새로운 트랜잭션 생성. 기존 트랜잭션은 일시 중단.
`SUPPORTS`	트랜잭션이 있으면 참여, 없으면 트랜잭션 없이 실행.
`NOT_SUPPORTED`	트랜잭션 없이 실행. 현재 트랜잭션이 있으면 일시 중단.
`MANDATORY`	반드시 기존 트랜잭션에 참여. 없으면 예외 발생.
`NEVER`	트랜잭션이 있으면 예외 발생. 트랜잭션 없이 실행
`NESTED`	부모 트랜잭션 내부에서 독립적인 롤백이 가능한 트랜잭션 생성. (Savepoint 기반)

주요 전파 속성의 상세 동작 방식과 예제

1️⃣ `REQUIRED` 전파 속성

기존 트랜잭션이 있으면 참여, 없으면 새 트랜잭션 생성.
기본값으로 설정되어 있으며, 가장 일반적으로 사용됩니다.

사용 예제: 주문 및 결제

주문과 결제는 동일한 트랜잭션 안에서 처리되어야 합니다.

코드

@Service
public class OrderService {
    @Transactional(propagation = Propagation.REQUIRED)
    public void placeOrder() {
        saveOrderDetails();  // 같은 트랜잭션
        processPayment();    // 같은 트랜잭션
    }

    @Transactional(propagation = Propagation.REQUIRED)
    public void saveOrderDetails() {
        // 주문 정보 저장
    }

    @Transactional(propagation = Propagation.REQUIRED)
    public void processPayment() {
        // 결제 처리
    }
}

결과

placeOrder 메서드에서 오류 발생 시, 모든 작업이 롤백됩니다.
동일한 트랜잭션으로 처리됩니다.

2️⃣ `REQUIRES_NEW` 전파 속성

항상 새로운 트랜잭션 생성.
부모 트랜잭션은 일시 중단됩니다.

사용 예제: 주문 처리와 로그 저장

주문 처리와 로그 저장은 서로 독립적이어야 합니다.

코드

@Service
public class OrderService {
    @Transactional(propagation = Propagation.REQUIRED)
    public void processOrder() {
        saveOrderDetails();  // 부모 트랜잭션
        saveAuditLog();      // 독립 트랜잭션
    }

    @Transactional(propagation = Propagation.REQUIRED)
    public void saveOrderDetails() {
        // 주문 데이터 저장
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void saveAuditLog() {
        // 로그 데이터 저장
    }
}

결과

saveAuditLog는 부모 트랜잭션과 독립적으로 커밋/롤백됩니다.
saveOrderDetails에서 예외가 발생해도, 로그는 저장됩니다.

3️⃣ `SUPPORTS` 전파 속성

트랜잭션이 있으면 참여, 없으면 트랜잭션 없이 실행.

사용 예제: 상품 조회

상품 조회 작업은 트랜잭션 없이도 실행 가능하지만, 트랜잭션이 있다면 참여합니다.

코드

@Service
public class ProductService {
    @Transactional(propagation = Propagation.SUPPORTS)
    public List<Product> getAllProducts() {
        // 상품 조회
        return productRepository.findAll();
    }
}

결과

트랜잭션 컨텍스트 내에서 호출되면 트랜잭션에 참여합니다.
트랜잭션 컨텍스트가 없으면 트랜잭션 없이 실행됩니다.

4️⃣ `NOT_SUPPORTED` 전파 속성

트랜잭션 없이 실행하며, 현재 트랜잭션이 있으면 일시 중단됩니다.

사용 예제: 파일 저장

파일 저장 작업은 데이터베이스 트랜잭션과 분리되어야 합니다.

코드

@Service
public class FileService {
    @Transactional(propagation = Propagation.NOT_SUPPORTED)
    public void saveFile(File file) {
        // 파일 저장 작업
    }
}

결과

데이터베이스 트랜잭션과 무관하게 파일 저장 작업이 수행됩니다.

5️⃣ `MANDATORY` 전파 속성

반드시 기존 트랜잭션에 참여해야 하며, 없으면 예외 발생.

사용 예제: 주문 상태 업데이트

주문 상태를 업데이트하려면 반드시 주문 생성 트랜잭션 내에서 실행되어야 합니다.

코드

@Service
public class OrderService {
    @Transactional(propagation = Propagation.REQUIRED)
    public void processOrder() {
        updateOrderStatus();  // 기존 트랜잭션에 참여
    }

    @Transactional(propagation = Propagation.MANDATORY)
    public void updateOrderStatus() {
        // 주문 상태 업데이트
    }
}

결과

processOrder가 트랜잭션 없이 호출되면 예외 발생.
트랜잭션 내에서 호출될 때만 정상 실행.

6️⃣ `NEVER` 전파 속성

트랜잭션이 있으면 예외 발생, 없으면 트랜잭션 없이 실행.

사용 예제: 캐싱 작업

캐싱 작업은 트랜잭션과 분리되어야 하며, 트랜잭션 내에서 호출되면 안 됩니다.

코드

@Service
public class CacheService {
    @Transactional(propagation = Propagation.NEVER)
    public void cacheData(Object data) {
        // 캐싱 작업
    }
}

결과

트랜잭션 내에서 호출되면 IllegalTransactionStateException 발생.
트랜잭션 없이 호출될 때만 실행.

7️⃣ `NESTED` 전파 속성

부모 트랜잭션 안에서 동작하며, Savepoint를 생성해 트랜잭션의 일부 작업만 롤백 가능합니다.
부모 트랜잭션은 유지되며, 자식 트랜잭션에서 발생한 오류는 Savepoint를 활용해 부분적으로 롤백됩니다.

동작 원리

부모 트랜잭션이 시작되면, NESTED 전파를 가진 메서드가 호출될 때 Savepoint가 생성됩니다.
자식 트랜잭션에서 오류가 발생하면 Savepoint까지만 롤백되며, 부모 트랜잭션은 영향을 받지 않습니다.
부모 트랜잭션이 커밋되지 않으면 자식 트랜잭션도 커밋되지 않습니다.

사용 예제: 주문과 배송 처리

상황

주문 데이터 저장과 배송 데이터 저장을 처리해야 합니다.
배송 처리 중 문제가 발생하면, 배송 데이터만 롤백되고 주문 데이터는 유지됩니다.

코드

@Service
public class OrderService {

    @Transactional(propagation = Propagation.REQUIRED)
    public void processOrder() {
        saveOrderDetails();     // 부모 트랜잭션
        processShipping();      // Savepoint 생성 (NESTED)
    }

    @Transactional(propagation = Propagation.REQUIRED)
    public void saveOrderDetails() {
        // 주문 데이터 저장 (부모 트랜잭션)
        System.out.println("Order details saved");
    }

    @Transactional(propagation = Propagation.NESTED)
    public void processShipping() {
        System.out.println("Processing shipping...");
        if (someConditionFails()) {
            throw new RuntimeException("Shipping failed!");
        }
        // 배송 데이터 저장
        System.out.println("Shipping details saved");
    }

    private boolean someConditionFails() {
        return true; // 테스트를 위해 항상 실패하도록 설정
    }
}

동작 흐름

processOrder() 호출
- 부모 트랜잭션이 시작됩니다 (Propagation.REQUIRED).
- saveOrderDetails() 실행 → 주문 데이터 저장.
processShipping() 호출
- NESTED 전파에 따라 Savepoint가 생성됩니다.
- 배송 데이터 처리 중 예외 발생(throw new RuntimeException()).
롤백
- 자식 트랜잭션(processShipping)이 Savepoint로 롤백됩니다.
- 부모 트랜잭션(processOrder)은 유지되며 커밋 가능합니다.

실행 결과

saveOrderDetails()에서 주문 정보가 저장됩니다.
processShipping()에서 예외가 발생해 배송 데이터 저장이 롤백됩니다.
부모 트랜잭션은 성공적으로 커밋됩니다.

결과 해석

장점

부모 트랜잭션을 유지하면서 자식 트랜잭션만 롤백 가능.
복잡한 작업에서 부분 롤백이 필요한 경우 유용.

적용 사례

주문은 유지해야 하지만, 배송 데이터를 별도로 롤백해야 하는 경우.
부모 작업의 성공 여부와 관계없이 하위 작업만 롤백해야 할 때.

전파 속성으로 인해 전체 작업이 롤백되는 상황과 해결 방법

문제

부모 트랜잭션이 롤백되면, 참여 중인 모든 트랜잭션이 함께 롤백됩니다.

해결 방법

REQUIRES_NEW를 사용해 부모 트랜잭션과 독립된 트랜잭션 생성.

예시 코드

@Transactional
public void parentTransaction() {
    childTransaction(); // 부모 트랜잭션 참여
    saveLog(); // 독립 트랜잭션
}

@Transactional(propagation = Propagation.REQUIRED)
public void childTransaction() {
    throw new RuntimeException("Rollback!");
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void saveLog() {
    // 독립적으로 로그 저장
}

독립적인 트랜잭션에서 예외 발생 시 처리 방법

문제

독립 트랜잭션에서 예외가 발생해도 부모 트랜잭션에 영향을 미치지 않아야 함.

해결 방법

REQUIRES_NEW로 독립 트랜잭션 생성.
부모 트랜잭션과 상관없이 커밋/롤백.

예시 코드

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void saveAuditLog() {
    try {
        // 로그 저장 작업
    } catch (Exception e) {
        // 예외 처리
    }
}

전파 속성으로 인해 새로운 트랜잭션을 만들지 못하는 상황

문제

클래스 내부 호출로 인해 전파 속성이 적용되지 않음.

해결 방법

AopContext 사용
- 내부 호출 시 프록시 객체를 강제로 참조.
메서드 분리
- 호출 메서드를 별도 빈으로 이동하여 외부 호출이 가능하도록 설계.

요약

전파 속성
- 트랜잭션의 생성/참여 여부를 결정.
- REQUIRED, REQUIRES_NEW, SUPPORTS 등 다양한 설정 제공.
주요 전파 속성
- REQUIRED: 기본값. 트랜잭션 참여 또는 생성.
- REQUIRES_NEW: 새로운 독립 트랜잭션 생성.
- NESTED: 부모 트랜잭션의 일부로 동작하며 Savepoint 생성.
전파 속성 문제와 해결 방법
- 부모 트랜잭션 롤백 문제는 REQUIRES_NEW로 해결.
- 내부 호출 문제는 AopContext나 빈 분리로 해결.

[JAVA] @Transactional 알아보기 Part.1 #프록시와 트랜잭션 동작 원리

TaeHuiLee — Mon, 23 Dec 2024 15:06:08 +0900

`@Transactional`이란?

Spring에서 제공하는 트랜잭션 관리 어노테이션으로, 데이터 작업의 ACID 특성을 보장하며 트랜잭션 시작, 커밋, 롤백을 자동으로 처리합니다.

@Transactional의 동작 원리

@Transactional은 AOP(Aspect-Oriented Programming) 기반으로 동작하며, 프록시 객체가 트랜잭션의 시작과 종료를 제어합니다.

프록시 동작 구조

클라이언트가 호출 → 프록시 객체가 메서드를 가로챔.
프록시 객체가 트랜잭션을 시작(Commit/Rollback 결정).
실제 객체의 메서드 실행.
메서드 종료 후 트랜잭션 종료.

트랜잭션은 원래 하나인가? 독립적으로 동작한다는 의미는?

트랜잭션은 하나의 작업 단위

트랜잭션은 데이터를 다루는 논리적 작업 단위입니다. 이는 작업이 완벽히 성공하거나, 실패 시 원래 상태로 복원되는 것을 의미합니다.

독립적이라는 의미

독립적 트랜잭션은:

서로 다른 트랜잭션이 상호 간섭하지 않는 것을 뜻합니다.
전파 속성(Propagation)을 통해 다른 트랜잭션과의 관계를 정의.

트랜잭션 생성 및 독립적 관리 방식

Spring의 트랜잭션 생성 방식

전파 속성(Propagation)과 프록시 객체를 통해 트랜잭션 생성과 관리를 결정.
트랜잭션 범위 내에서 데이터 작업을 제어하며, 필요 시 새로운 트랜잭션을 생성합니다.

독립적 관리 사례

REQUIRES_NEW를 사용해 부모 트랜잭션과 독립된 새 트랜잭션을 생성.

클래스 내부 호출과 트랜잭션 동작

왜 클래스 내부에서 `@Transactional` 메서드를 호출하면 새로운 트랜잭션이 생성되지 않는가?

Spring의 @Transactional은 프록시 객체를 통해 트랜잭션을 관리합니다.
그러나 클래스 내부에서 메서드를 호출하면 프록시 객체를 거치지 않고 직접 호출하기 때문에 새로운 트랜잭션이 생성되지 않습니다.

문제 상황 코드

public class MyService {
    @Transactional
    public void outerMethod() {
        innerMethod(); // 프록시 객체를 거치지 않고 호출
    }

    @Transactional
    public void innerMethod() {
        // 트랜잭션 동작하지 않음
    }
}

프록시를 거치지 않아 발생하는 문제

outerMethod()는 트랜잭션이 적용되지만, 내부 호출(innerMethod())은 적용되지 않음.
내부 호출은 프록시 객체를 우회하기 때문.

Spring AOP의 프록시 구조

프록시 객체란?

Spring의 AOP는 프록시 패턴을 기반으로 동작합니다.

프록시 객체는 실제 메서드를 호출하기 전/후에 부가 기능(트랜잭션 관리)을 추가합니다.

프록시 호출 흐름

[클라이언트] → [프록시 객체] → [실제 객체]

트랜잭션 시작, 커밋, 롤백 등은 모두 프록시 객체에서 처리.

내부 호출 문제 발생 이유

클래스 내부에서 호출 시 [클라이언트] → [프록시] 구조를 우회하여, 실제 객체의 메서드가 직접 호출됩니다.

✅ 해결 방법

1️⃣ `AopContext.currentProxy()`를 사용

Spring에서 제공하는 AopContext.currentProxy()를 이용해 현재 객체의 프록시를 가져와 호출합니다.

수정된 코드

public class MyService {
    @Transactional
    public void outerMethod() {
        ((MyService) AopContext.currentProxy()).innerMethod(); // 프록시를 통해 호출
    }

    @Transactional
    public void innerMethod() {
        // 트랜잭션 적용
    }
}

2️⃣ 내부 호출 대상 메서드를 별도 빈으로 분리

다른 클래스에 메서드를 정의하여 외부 호출이 프록시를 거치도록 설계합니다.

분리된 클래스 코드

@Component
public class InnerService {
    @Transactional
    public void innerMethod() {
        // 새로운 트랜잭션 생성
    }
}

@Component
public class MyService {
    @Autowired
    private InnerService innerService;

    @Transactional
    public void outerMethod() {
        innerService.innerMethod(); // 프록시를 거쳐 호출
    }
}

프록시 객체와 트랜잭션이 클래스 외부 호출에서만 동작하는 이유

프록시 객체 동작의 본질

Spring은 JDK 동적 프록시 또는 CGLIB 프록시를 사용하여 트랜잭션을 제어합니다.

JDK 동적 프록시: 인터페이스 기반.
CGLIB 프록시: 클래스 상속 기반.

클래스 외부 호출이 필요한 이유

프록시 객체는 클라이언트 호출을 가로채 트랜잭션 관리.
내부 호출은 프록시 객체를 우회하므로 트랜잭션 동작이 적용되지 않음.

Spring 트랜잭션에서 내부 호출이 프록시를 거치지 않는다는 것은 무슨 의미인가?

내부 호출 동작 원리

Spring은 AOP 프록시를 통해 트랜잭션을 제어.
내부 호출은 프록시 객체를 거치지 않고 실제 객체 메서드를 직접 호출.

문제 해결 방법

AopContext 사용: 프록시 객체를 직접 참조.
빈 분리: 호출 메서드를 별도 빈으로 분리.

메서드 단위의 `@Transactional`은 클래스 전체에 영향을 미치는가?

적용 범위

메서드 단위로 트랜잭션이 적용되며, 호출된 메서드에만 영향을 미칩니다.
클래스 레벨에 선언하면, 클래스의 모든 메서드가 트랜잭션 대상이 됩니다.

주의

클래스 레벨 선언 시에도 프록시를 거치지 않으면 동작하지 않음.

요약

@Transactional의 동작 원리
- AOP 기반 프록시 객체를 통해 트랜잭션을 제어.
- 내부 호출 시 프록시를 거치지 않아 트랜잭션 미적용 문제 발생.
내부 호출 문제 해결 방법
- AopContext.currentProxy()를 사용해 프록시를 강제로 호출.
- 호출 메서드를 별도 빈으로 분리.
클래스 외부 호출이 필요한 이유
- 프록시 객체는 외부 호출을 가로채 트랜잭션 제어.
메서드 단위의 적용
- @Transactional은 기본적으로 메서드 단위로 적용되며, 클래스 레벨에 선언 시 모든 메서드가 트랜잭션 대상.

[JAVA] Spring 공통 모듈을 패키지화하고 GitHub Packages에 등록하는 방법

TaeHuiLee — Fri, 6 Dec 2024 18:31:44 +0900

Spring Boot 프로젝트를 진행하다 보면, 여러 프로젝트에서 재사용할 수 있는 공통 모듈을 패키지화해서 관리하고 싶을 때가 많습니다. 이번 포스팅에서는 공통 모듈을 Maven 패키지로 만들어 GitHub Packages에 등록하고, 이를 다른 프로젝트에서 사용하는 방법을 처음부터 끝까지 자세히 설명합니다.

1. 공통 모듈 프로젝트 생성

1️⃣ 프로젝트 구조 만들기

Spring Boot 공통 모듈 프로젝트를 생성합니다. Maven 프로젝트로 설정하는 것이 중요합니다.

Maven 프로젝트 생성 명령어:

mvn archetype:generate -DgroupId=com.example -DartifactId=springboot-common-modules -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

디렉토리 구조:

springboot-common-modules
├── src/main/java/com/example/common
│   └── StringUtils.java
├── src/test/java/com/example/common
├── pom.xml

2️⃣ 공통 모듈 코드 작성

공통적으로 사용할 코드를 src/main/java 폴더에 추가합니다.

예: `StringUtils` 클래스

package com.example.common;

public class StringUtils {
    public static boolean isEmpty(String str) {
        return str == null || str.trim().isEmpty();
    }
}

2. Maven `pom.xml` 설정

1️⃣ 기본 POM 설정

프로젝트의 pom.xml 파일에 아래 내용을 추가합니다.

POM 파일 구조:

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>springboot-common-modules</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>

    <name>Spring Boot Common Modules</name>
    <description>Reusable Spring Boot components</description>

    <dependencies>
        <!-- 필요 시 의존성 추가 -->
    </dependencies>
</project>

3. GitHub Packages에 배포하기

1️⃣ `distributionManagement` 설정

GitHub Packages로 배포하려면 pom.xml 파일에 아래 내용을 추가해야 합니다.

<distributionManagement>
    <repository>
        <id>github</id>
        <url>https://maven.pkg.github.com/<GitHub-사용자명>/<저장소-이름></url>
    </repository>
</distributionManagement>

id: github로 설정.
url: GitHub Packages URL을 <GitHub 사용자명>과 <저장소 이름>으로 대체하여 입력.

2️⃣ 인증 정보 추가 (`settings.xml`)

GitHub Packages에 업로드하려면 ~/.m2/settings.xml 파일에 인증 정보를 추가합니다.

`settings.xml` 내용:

<settings>
    <servers>
        <server>
            <id>github</id>
            <username>GITHUB_USERNAME</username>
            <password>GITHUB_PERSONAL_ACCESS_TOKEN</password>
        </server>
    </servers>
</settings>

id: github로 설정 (POM의 distributionManagement와 동일).
username: GitHub 사용자명.
password: GitHub Personal Access Token.

3️⃣ GitHub Actions로 자동 배포 설정

1️⃣ `.github/workflows/deploy.yml` 작성

GitHub Actions를 이용해 Push할 때 자동으로 배포되도록 설정합니다.

name: Deploy Maven Package

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v3

    - name: Set up Java
      uses: actions/setup-java@v3
      with:
        distribution: 'temurin'
        java-version: '17'

    - name: Cache Maven dependencies
      uses: actions/cache@v3
      with:
        path: ~/.m2
        key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
        restore-keys: ${{ runner.os }}-maven

    - name: Deploy to GitHub Packages
      run: mvn deploy
      env:
        GITHUB_USERNAME: ${{ secrets.GITHUB_ACTOR }}
        GITHUB_PERSONAL_ACCESS_TOKEN: ${{ secrets.GITHUB_TOKEN }}

4. 다른 프로젝트에서 공통 모듈 사용하기

1️⃣ `pom.xml`에 의존성 추가

GitHub Packages에 업로드한 공통 모듈을 사용하는 프로젝트에서 아래 내용을 추가합니다.

GitHub Packages 저장소 정보 추가:

<repositories>
    <repository>
        <id>github</id>
        <url>https://maven.pkg.github.com/<GitHub-사용자명>/<저장소-이름></url>
    </repository>
</repositories>

공통 모듈 의존성 추가:

<dependencies>
    <dependency>
        <groupId>com.example</groupId>
        <artifactId>springboot-common-modules</artifactId>
        <version>1.0.0</version>
    </dependency>
</dependencies>

5. ✅ 정리

공통 모듈 생성:
- Maven 프로젝트로 생성 후 코드를 작성.
GitHub Packages 설정:
- pom.xml의 distributionManagement와 settings.xml에 인증 정보 추가.
GitHub Actions로 자동 배포:
- Push 시 자동으로 GitHub Packages에 배포되도록 설정.
다른 프로젝트에서 사용:
- 저장소 정보를 추가한 뒤, 의존성을 추가.

구현 참조: https://github.com/taehui8260/springboot-common-modules/

[WEB] Nuxt.js와 Spring을 이용한 POI Excel 파일 업로드 및 처리

TaeHuiLee — Wed, 27 Nov 2024 15:58:03 +0900

이번 글에서는 프론트엔드에서 업로드된 Excel 파일을 Spring 백엔드에서 받아서 Apache POI로 처리하는 방법을 알아보겠습니다. 업로드된 파일을 어떻게 서버에서 다룰 수 있는지 Spring MVC와 Apache POI를 활용하여 구현합니다.

전체 구현 개요

프론트엔드
- Nuxt.js를 통해 파일을 업로드.
- 서버로 HTTP POST 요청을 보냄.
백엔드
- Spring Controller에서 파일을 받음.
- MultipartFile 객체로 업로드된 파일 처리.
- Apache POI로 Excel 데이터를 읽고 출력 또는 가공.
처리된 데이터
- 데이터베이스 저장 또는 JSON 응답 반환.

1. 프론트엔드: Nuxt.js로 파일 업로드 구현

Nuxt.js는 Vue.js 기반으로 작동하기 때문에 파일 업로드는 Vue의 기본 이벤트 처리 방식을 사용합니다. 아래는 Nuxt.js에서 파일 업로드를 구현하는 코드입니다.

업로드 UI 생성 (Nuxt 페이지 컴포넌트)

pages/upload.vue에 아래 코드를 작성합니다.

<template>
  <div>
    <h1>Excel 파일 업로드</h1>
    <form @submit.prevent="handleFileUpload">
      <input type="file" @change="onFileChange" accept=".xlsx, .xls" />
      <button type="submit">업로드</button>
    </form>
    <div v-if="uploadResult">
      <h2>업로드 결과:</h2>
      <pre>{{ uploadResult }}</pre>
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      file: null, // 선택한 파일
      uploadResult: null, // 서버에서 받은 응답 데이터
    };
  },
  methods: {
    // 파일 선택 핸들러
    onFileChange(event) {
      this.file = event.target.files[0];
    },
    // 파일 업로드 처리
    async handleFileUpload() {
      if (!this.file) {
        alert("파일을 선택해주세요!");
        return;
      }

      // FormData 생성
      const formData = new FormData();
      formData.append("file", this.file);

      try {
        const response = await this.$axios.post("/upload", formData, {
          headers: { "Content-Type": "multipart/form-data" },
        });
        this.uploadResult = response.data;
      } catch (error) {
        console.error("업로드 실패:", error);
        alert("업로드 중 오류가 발생했습니다.");
      }
    },
  },
};
</script>

Nuxt Axios 설정

Nuxt.js에서 파일 업로드를 처리하기 위해 @nuxtjs/axios 모듈을 사용합니다. nuxt.config.js 파일에 Axios 설정을 추가합니다.

export default {
  modules: ["@nuxtjs/axios"],
  axios: {
    baseURL: "http://localhost:8080", // Spring 백엔드 URL
  },
};

2. 백엔드: Spring 파일 업로드 처리

Spring에서 Nuxt.js로부터 전달받은 파일을 처리하는 방법입니다.

Controller: 파일 업로드 처리

Nuxt.js가 보낸 파일을 @RequestParam으로 받습니다. MultipartFile 객체를 사용하여 파일 내용을 처리합니다.

import org.apache.poi.ss.usermodel.*;
import org.apache.poi.xssf.usermodel.XSSFWorkbook;
import org.springframework.web.bind.annotation.*;
import org.springframework.web.multipart.MultipartFile;

import java.io.InputStream;
import java.util.ArrayList;
import java.util.List;

@RestController
public class ExcelController {

    @PostMapping("/upload")
    public List<List<String>> uploadExcel(@RequestParam("file") MultipartFile file) {
        List<List<String>> excelData = new ArrayList<>();

        try (InputStream inputStream = file.getInputStream();
             Workbook workbook = new XSSFWorkbook(inputStream)) {

            // 첫 번째 시트 읽기
            Sheet sheet = workbook.getSheetAt(0);
            for (Row row : sheet) {
                List<String> rowData = new ArrayList<>();
                for (Cell cell : row) {
                    switch (cell.getCellType()) {
                        case STRING:
                            rowData.add(cell.getStringCellValue());
                            break;
                        case NUMERIC:
                            rowData.add(String.valueOf(cell.getNumericCellValue()));
                            break;
                        case BOOLEAN:
                            rowData.add(String.valueOf(cell.getBooleanCellValue()));
                            break;
                        default:
                            rowData.add(" ");
                    }
                }
                excelData.add(rowData);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        return excelData; // JSON으로 반환
    }
}

Spring 설정: CORS 지원

Nuxt.js와 Spring이 다른 포트를 사용하므로, CORS 설정이 필요합니다. 예를 들어, Spring에서 모든 도메인의 요청을 허용하려면 아래 코드를 추가합니다.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig {

    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/**").allowedOrigins("http://localhost:3000"); // Nuxt.js 주소
            }
        };
    }
}

3. 전체 데이터 흐름

프론트엔드 (Nuxt.js):
- 사용자가 Excel 파일을 선택하고 업로드 요청을 보냄.
- axios를 통해 백엔드 /upload 엔드포인트로 POST 요청.
백엔드 (Spring):
- 업로드된 파일을 MultipartFile로 받고, Apache POI로 데이터를 읽음.
- 읽은 데이터를 JSON 형태로 Nuxt.js로 응답.
프론트엔드 (Nuxt.js):
- 백엔드에서 받은 데이터를 화면에 출력.

4. 완성된 코드 요약

Nuxt.js `pages/upload.vue`

<template>
  <div>
    <h1>Excel 파일 업로드</h1>
    <form @submit.prevent="handleFileUpload">
      <input type="file" @change="onFileChange" accept=".xlsx, .xls" />
      <button type="submit">업로드</button>
    </form>
    <div v-if="uploadResult">
      <h2>업로드 결과:</h2>
      <pre>{{ uploadResult }}</pre>
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      file: null,
      uploadResult: null,
    };
  },
  methods: {
    onFileChange(event) {
      this.file = event.target.files[0];
    },
    async handleFileUpload() {
      if (!this.file) {
        alert("파일을 선택해주세요!");
        return;
      }
      const formData = new FormData();
      formData.append("file", this.file);

      try {
        const response = await this.$axios.post("/upload", formData, {
          headers: { "Content-Type": "multipart/form-data" },
        });
        this.uploadResult = response.data;
      } catch (error) {
        console.error("업로드 실패:", error);
        alert("업로드 중 오류가 발생했습니다.");
      }
    },
  },
};
</script>

Spring `ExcelController.java`

@RestController
public class ExcelController {

    @PostMapping("/upload")
    public List<List<String>> uploadExcel(@RequestParam("file") MultipartFile file) {
        List<List<String>> excelData = new ArrayList<>();

        try (InputStream inputStream = file.getInputStream();
             Workbook workbook = new XSSFWorkbook(inputStream)) {

            Sheet sheet = workbook.getSheetAt(0);
            for (Row row : sheet) {
                List<String> rowData = new ArrayList<>();
                for (Cell cell : row) {
                    switch (cell.getCellType()) {
                        case STRING:
                            rowData.add(cell.getStringCellValue());
                            break;
                        case NUMERIC:
                            rowData.add(String.valueOf(cell.getNumericCellValue()));
                            break;
                        case BOOLEAN:
                            rowData.add(String.valueOf(cell.getBooleanCellValue()));
                            break;
                        default:
                            rowData.add(" ");
                    }
                }
                excelData.add(rowData);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        return excelData;
    }
}

5. 마무리

이 글에서는 Nuxt.js와 Spring을 연동하여 Excel 파일을 업로드하고 데이터를 읽는 과정을 설명했습니다. 이를 통해 Nuxt.js가 백엔드로 파일을 전송하고, Spring에서 데이터를 처리하여 JSON으로 반환하는 방법을 알아보았습니다.

[JAVA] Java로 Excel 파일 생성 및 관리: Apache POI 사용법

TaeHuiLee — Tue, 26 Nov 2024 18:12:04 +0900

이번 글에서는 Apache POI 라이브러리를 사용해 Java로 Excel 파일을 생성하는 방법을 처음부터 끝까지 설명합니다. 스타일 적용, 데이터 작성, 컬럼 스타일링 등, 실용적인 예제를 통해 구현 방법을 단계별로 알아보겠습니다.

1. Apache POI란?

Apache POI는 Java 기반으로 MS Office 문서를 다룰 수 있는 강력한 라이브러리입니다. 특히, Excel 파일을 처리하는 데 가장 널리 쓰입니다.

2. Excel 파일 생성 프로세스

️ 준비 단계

의존성 추가
Maven 프로젝트라면 pom.xml에 아래 의존성 추가

<dependency>
   <groupId>org.apache.poi</groupId>
   <artifactId>poi-ooxml</artifactId>
   <version>5.2.3</version> <!-- 최신 버전을 확인하세요 -->
</dependency>

Apache POI 주요 클래스

Workbook: Excel 파일을 나타냄. (HSSFWorkbook: .xls, XSSFWorkbook: .xlsx)
Sheet: 워크시트(탭)를 나타냄.
Row와 Cell: 각 행과 셀.

3. 구현 방법: 단계별 설명

1단계: Workbook 생성

Excel 파일을 생성하려면 먼저 Workbook 객체를 초기화해야 합니다. .xlsx 파일은 XSSFWorkbook을 사용합니다.

Workbook workbook = new XSSFWorkbook();

2단계: Sheet 생성

workbook.createSheet("Sheet 이름")을 호출해 워크시트를 추가합니다.

Sheet sheet = workbook.createSheet("첫 번째 시트");

3단계: Row와 Cell 추가

Excel 파일에 데이터를 추가하려면 Row와 Cell 객체를 생성해야 합니다.

Row row = sheet.createRow(0); // 첫 번째 행 생성
Cell cell = row.createCell(0); // 첫 번째 셀 생성
cell.setCellValue("안녕하세요!"); // 데이터 입력

4단계: 스타일 적용

CellStyle을 사용해 셀의 스타일을 설정할 수 있습니다.

1. 스타일 초기화

CellStyle style = workbook.createCellStyle();
Font font = workbook.createFont();
font.setFontHeightInPoints((short) 14); // 글꼴 크기
font.setBold(true); // 굵게
style.setFont(font);
style.setAlignment(HorizontalAlignment.CENTER); // 가운데 정렬
style.setVerticalAlignment(VerticalAlignment.CENTER); // 세로 가운데 정렬

2. 스타일 적용

cell.setCellStyle(style);

5단계: 데이터와 스타일 반복 적용

데이터를 반복적으로 추가하고 스타일을 적용하려면 for 루프를 활용합니다.

for (int i = 0; i < 10; i++) {
    Row dataRow = sheet.createRow(i + 1); // 첫 번째 행 아래부터 데이터 추가
    for (int j = 0; j < 5; j++) {
        Cell dataCell = dataRow.createCell(j);
        dataCell.setCellValue("데이터 " + (i + 1) + "-" + (j + 1));
        dataCell.setCellStyle(style);
    }
}

6단계: 컬럼 너비 조정

자동으로 컬럼 크기를 설정하려면 다음 메소드를 사용합니다:

for (int i = 0; i < 5; i++) {
    sheet.autoSizeColumn(i); // i번째 컬럼의 너비를 데이터에 맞게 자동 조정
}

7단계: Excel 파일 저장

생성한 Excel 파일을 실제로 저장하려면 FileOutputStream을 사용합니다.

try (FileOutputStream fileOut = new FileOutputStream("sample.xlsx")) {
    workbook.write(fileOut); // 워크북 내용을 파일로 출력
}
workbook.close(); // 리소스 해제

4. 완성된 코드 예제

아래는 위의 모든 단계를 포함한 전체 구현 코드입니다:

import org.apache.poi.ss.usermodel.*;
import org.apache.poi.xssf.usermodel.XSSFWorkbook;

import java.io.FileOutputStream;

public class ExcelExample {
    public static void main(String[] args) {
        try (Workbook workbook = new XSSFWorkbook()) {
            Sheet sheet = workbook.createSheet("첫 번째 시트");

            // 제목 행 추가
            Row row = sheet.createRow(0);
            Cell cell = row.createCell(0);
            cell.setCellValue("안녕하세요!");

            // 스타일 설정
            CellStyle style = workbook.createCellStyle();
            Font font = workbook.createFont();
            font.setFontHeightInPoints((short) 14);
            font.setBold(true);
            style.setFont(font);
            style.setAlignment(HorizontalAlignment.CENTER);
            style.setVerticalAlignment(VerticalAlignment.CENTER);
            cell.setCellStyle(style);

            // 데이터 추가
            for (int i = 0; i < 10; i++) {
                Row dataRow = sheet.createRow(i + 1);
                for (int j = 0; j < 5; j++) {
                    Cell dataCell = dataRow.createCell(j);
                    dataCell.setCellValue("데이터 " + (i + 1) + "-" + (j + 1));
                    dataCell.setCellStyle(style);
                }
            }

            // 컬럼 크기 자동 조정
            for (int i = 0; i < 5; i++) {
                sheet.autoSizeColumn(i);
            }

            // 파일 저장
            try (FileOutputStream fileOut = new FileOutputStream("sample.xlsx")) {
                workbook.write(fileOut);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

5. 마무리

이 글에서는 Apache POI를 활용한 Excel 파일 생성 방법을 보았습니다.

Workbook 생성부터 데이터 추가, 스타일링, 파일 저장까지 전 과정
실제 프로젝트에서 다양한 Excel 템플릿 생성 및 데이터 관리에 활용

[Linux] 리눅스 환경에서 sudo 권한 실행 시 비밀번호를 묻지 않도록 설정하는 방법

TaeHuiLee — Mon, 25 Nov 2024 18:48:24 +0900

️ 리눅스 환경에서 `sudo` 권한 실행 시 비밀번호를 묻지 않도록 설정하는 방법

리눅스 시스템에서 sudo를 사용할 때 매번 비밀번호를 입력해야 하는 건 보안적인 이유 때문입니다. 하지만 개발 환경에서는 이를 생략해야 할 경우가 종종 있습니다. 이번 포스팅에서는 sudo 비밀번호 없이 실행되도록 설정하는 방법과 이 설정이 어떤 경우에 유용하며 어떻게 작동하는지를 알아보겠습니다.

1. ️ 비밀번호를 묻지 않도록 설정하는 과정

리눅스 시스템에서 특정 유저나 그룹이 sudo 명령을 사용할 때 비밀번호 입력을 건너뛰도록 설정하려면 sudoers 파일을 수정해야 합니다.

1.1. `sudoers` 파일 편집하기

터미널에서 sudo visudo 명령을 실행합니다.

sudo visudo

visudo는 sudoers 파일을 편집하기 위해 사용되는 전용 명령입니다. 이 명령을 통해 편집하면 실수로 파일이 손상되는 것을 방지할 수 있습니다.

sudoers 파일을 편집 창에서 열게 되면 다음과 같은 내용이 보입니다.

# User privilege specification
root    ALL=(ALL:ALL) ALL

1.2. 유저 비밀번호 입력 생략 설정

아래와 같이 특정 유저의 sudo 비밀번호를 묻지 않도록 설정합니다.

특정 유저에 대한 설정

<your_username> 대신 비밀번호를 생략하려는 유저명을 입력합니다.

<your_username> ALL=(ALL) NOPASSWD: ALL

특정 명령만 비밀번호 없이 허용

특정 명령에 대해서만 비밀번호를 묻지 않도록 하려면

<your_username> ALL=(ALL) NOPASSWD: /path/to/command

예를 들어, /sbin/reboot 명령만 비밀번호 없이 실행하도록 설정하려면

<your_username> ALL=(ALL) NOPASSWD: /sbin/reboot

1.3. 그룹 단위로 설정

여러 유저를 포함한 그룹에 대해 설정하려면 sudoers 파일에 다음과 같은 내용을 추가합니다.

%<groupname> ALL=(ALL) NOPASSWD: ALL

여기서 <groupname>은 비밀번호를 생략할 그룹 이름입니다.

1.4. 변경사항 저장

설정을 완료했으면, :wq 를 입력해 저장하고 sudoers 파일을 닫습니다.

만약 파일 저장 중에 에러가 발생했다면, visudo 명령이 문제를 알려줍니다. 이 경우 올바르게 수정한 뒤 다시 저장하세요.

2. 이러한 설정이 유용한 경우

비밀번호를 생략하는 설정은 다음과 같은 상황에서 유용합니다:

개발 환경 자동화:
- 스크립트나 배치 작업에서 sudo 명령을 반복적으로 사용할 때, 비밀번호 입력이 불필요한 경우.
- CI/CD 파이프라인에서 자동으로 작업을 처리하기 위해.
교육용 또는 실습용 환경:
- 특정 유저 계정만 사용하고 보안 위험이 낮은 환경(예: VM)에서.
IoT 및 임베디드 환경:
- 디바이스가 특정 작업을 수행할 때 비밀번호 입력 없이 권한 상승이 필요할 경우.

하지만, 이러한 설정은 보안에 민감한 환경에서는 절대 권장되지 않습니다. 누군가 계정에 접근한다면 비밀번호 없이 시스템을 제어할 수 있기 때문입니다.

3. 설정이 작동하는 원리

리눅스의 sudo는 /etc/sudoers 파일에 정의된 정책에 따라 동작합니다. 이 파일에는 다음과 같은 권한 규칙이 있습니다.

ALL=(ALL):
유저가 모든 호스트에서 모든 명령을 실행할 수 있음을 의미합니다.
NOPASSWD:
비밀번호를 묻지 않고 명령을 실행할 수 있음을 의미합니다.

위에서 편집한 대로 설정하면, sudo는 실행 시 비밀번호를 요청하지 않습니다.

4. ⚠️ 주의사항

보안 강화 권장
- 반드시 특정 유저나 명령에 대해서만 비밀번호 생략 설정을 사용하세요.
- 만약 모든 명령에 대해 비밀번호를 생략하면, 계정 탈취 시 심각한 보안 문제가 발생할 수 있습니다.
로그 기록 확인
- sudo는 모든 명령 실행을 /var/log/auth.log에 기록합니다. 로그를 주기적으로 검토해 이상 징후를 탐지하세요.
파일 편집 시 유의
- sudoers 파일을 잘못 수정하면 시스템에 문제가 발생할 수 있습니다. 꼭 visudo를 사용해야합니다.

5. 요약

sudo visudo를 사용해 sudoers 파일을 엽니다.
특정 유저 또는 그룹에 대해 NOPASSWD 옵션을 추가합니다.
설정 저장 후 테스트합니다.

<your_username> ALL=(ALL) NOPASSWD: ALL

위 방법은 개발 환경 자동화와 같은 상황에서 매우 유용하지만, 보안에 민감한 환경에서는 신중히 적용해야 합니다.

[DB] NoSQL의 모든 것

TaeHuiLee — Sun, 24 Nov 2024 22:42:49 +0900

1. NoSQL의 모든 것

데이터베이스(Database)는 애플리케이션 개발에서 중요한 요소입니다. 전통적으로 SQL 기반의 관계형 데이터베이스(RDBMS)가 널리 사용되었지만, 최근에는 NoSQL이 떠오르고 있습니다. 오늘은 NoSQL에 대해 기본 개념, 특징, 종류, 구현 방법을 깊이 있게 다뤄보겠습니다.

2. NoSQL이란?

✅ 정의

NoSQL은 "Not Only SQL"의 약자로, 전통적인 SQL 데이터베이스와 다른 방식으로 데이터를 저장하고 관리하는 데이터베이스를 의미합니다. 비관계형 데이터베이스라고도 불리며, 대규모 데이터 처리와 유연한 설계를 지원합니다.

✅ NoSQL의 RDB에 비해 장점

스키마가 유연하다
- RDBMS는 테이블 스키마가 고정되어 있지만, NoSQL은 유연한 데이터 구조를 지원합니다. 이를 통해 다양한 데이터 유형과 비정형 데이터를 쉽게 처리할 수 있습니다.
수평 확장이 용이하다
- RDBMS는 보통 고성능 서버(수직 확장)를 추가해야 하지만, NoSQL은 노드를 추가(수평 확장)하여 데이터를 분산 저장할 수 있습니다.
- 대규모 데이터를 다루는 서비스에서 특히 유리합니다.
대규모 분산 처리에 최적화
- NoSQL은 데이터를 여러 서버에 분산하여 저장하고 처리합니다.
- 예를 들어, 사용자 수가 폭발적으로 증가하는 애플리케이션에서 데이터 읽기/쓰기 속도를 유지할 수 있습니다.
고성능 읽기/쓰기
- NoSQL은 특정 쿼리 패턴에 최적화된 구조를 선택하여 RDB보다 빠른 읽기/쓰기 성능을 발휘합니다.
- 캐싱, 실시간 분석 등에 적합합니다.
비정형 데이터 처리
- JSON, XML, 이미지, 동영상과 같은 비정형 데이터를 저장하고 관리하기에 적합합니다.

3. NoSQL의 주요 종류

NoSQL은 사용 사례에 따라 여러 유형으로 나뉩니다.

1️⃣ 키-값 저장소(Key-Value Store)

특징: 데이터를 Key와 Value 쌍으로 저장.
장점: 단순한 구조로 빠른 읽기/쓰기 성능 제공.
예시: Redis, DynamoDB.

2️⃣ 문서형(Document Store)

특징: 데이터를 JSON 또는 BSON 문서 형태로 저장.
장점: 유연한 데이터 모델과 계층적 구조 지원.
예시: MongoDB, CouchDB.

3️⃣ 그래프 데이터베이스(Graph Database)

특징: 데이터 간의 관계를 그래프 형태로 표현.
장점: 복잡한 관계를 빠르게 조회 가능.
예시: Neo4j, ArangoDB.

4️⃣ 열 지향 데이터베이스(Column Family Store)

특징: 데이터를 열(Column) 단위로 저장.
장점: 대규모 분석 작업에 적합.
예시: Apache Cassandra, HBase.

4. NoSQL의 대규모 분산 처리

✅ 분산 처리의 원리

NoSQL은 수평 확장성을 지원하여 대규모 데이터를 다룰 때도 안정적으로 작동합니다.

샤딩(Sharding)
- 데이터를 여러 노드에 분산하여 저장.
- 사용자가 더 많은 데이터를 요청해도, 각 노드가 일부만 처리하므로 성능 유지.
복제(Replication)
- 데이터 복사본을 여러 서버에 저장하여, 장애 상황에서도 서비스 지속 가능.
CAP 이론
- 분산 시스템에서 Consistency(일관성), Availability(가용성), Partition Tolerance(파티션 허용성) 중 두 가지를 우선시합니다.

예를 들어, MongoDB는 데이터가 여러 노드에 분산 저장되며, 서버 장애가 발생해도 데이터 복구가 가능합니다.

5. 가장 보편적으로 사용되는 NoSQL: MongoDB

✅ MongoDB란?

MongoDB는 문서형 데이터베이스로, JSON과 유사한 BSON 포맷으로 데이터를 저장합니다. 유연한 스키마 덕분에 개발 초기부터 복잡한 데이터 구조 설계 없이도 빠르게 시작할 수 있어요.

6. MongoDB 설치 및 구현

✅ MongoDB 설치

MongoDB 공식 웹사이트에서 설치 파일 다운로드.
설치 후, mongod 명령어로 서버 실행.
MongoDB 클라이언트(예: MongoDB Compass)나 명령줄에서 데이터 작업 수행.

✅ MongoDB 기본 명령어

MongoDB에서 가장 기본적인 데이터 작업은 다음과 같습니다.

# 데이터베이스 목록 보기
show dbs

# 데이터베이스 선택 (없으면 생성)
use my_database

# 컬렉션 생성 및 데이터 삽입
db.my_collection.insertOne({ name: "Alice", age: 25, city: "Seoul" })

# 모든 데이터 조회
db.my_collection.find()

# 조건에 맞는 데이터 조회
db.my_collection.find({ age: { $gte: 20 } })

# 데이터 수정
db.my_collection.updateOne({ name: "Alice" }, { $set: { age: 26 } })

# 데이터 삭제
db.my_collection.deleteOne({ name: "Alice" })

✅ MongoDB 사용 예제: Node.js로 CRUD 애플리케이션 만들기

아래는 Node.js와 Mongoose를 이용해 MongoDB와 연결하고 CRUD 작업을 수행하는 코드 예제입니다.

1️⃣ 프로젝트 초기화 및 의존성 설치

mkdir mongodb-example
cd mongodb-example
npm init -y
npm install mongoose express body-parser

2️⃣ MongoDB 연결 및 스키마 정의

const mongoose = require('mongoose');
const express = require('express');
const bodyParser = require('body-parser');

const app = express();
app.use(bodyParser.json());

// MongoDB 연결
mongoose.connect('mongodb://localhost:27017/my_database', {
  useNewUrlParser: true,
  useUnifiedTopology: true,
});

// 스키마 정의
const UserSchema = new mongoose.Schema({
  name: String,
  age: Number,
  city: String,
});

const User = mongoose.model('User', UserSchema);

// 간단한 라우트
app.get('/', (req, res) => {
  res.send('Hello MongoDB!');
});

3️⃣ CRUD 라우트 구현

app.post('/users', async (req, res) => {
  const user = new User(req.body);
  await user.save();
  res.send(user);
});

app.get('/users', async (req, res) => {
  const users = await User.find();
  res.send(users);
});

app.put('/users/:id', async (req, res) => {
  const user = await User.findByIdAndUpdate(req.params.id, req.body, { new: true });
  res.send(user);
});

app.delete('/users/:id', async (req, res) => {
  await User.findByIdAndDelete(req.params.id);
  res.send({ message: 'User deleted' });
});

// 서버 실행
app.listen(3000, () => {
  console.log('Server is running on http://localhost:3000');
});

7. 정리: NoSQL의 강점과 활용 방법

✅ NoSQL의 RDB 대비 주요 강점

수평 확장성과 분산 처리로 대규모 데이터 관리 가능.
유연한 스키마를 통해 초기 개발 부담 감소.
빠른 읽기/쓰기 성능으로 실시간 애플리케이션에 적합.
다양한 데이터 유형 지원(JSON, 이미지, 동영상 등).

✅ MongoDB 활용

MongoDB는 웹 애플리케이션, IoT 플랫폼, 로그 관리 시스템 등 다양한 분야에서 사용됩니다.

NoSQL은 대규모 데이터를 처리할 수 있는 강력한 데이터베이스입니다. 특히 MongoDB는 유연하고 접근성이 좋아 초보 개발자도 쉽게 시작할 수 있습니다.

MariaDB란 무엇인가

TaeHuiLee — Sat, 23 Nov 2024 23:34:54 +0900

1. MariaDB란 무엇인가?

MariaDB는 원래 MySQL의 창시자인 몬티 와이드니우스(Michael "Monty" Widenius)가 MySQL의 대체제로 개발한 오픈 소스 데이터베이스입니다. MySQL과 매우 유사한 인터페이스를 제공하며, 기존 MySQL을 사용하던 애플리케이션에서 손쉽게 MariaDB로 전환할 수 있도록 설계되었습니다.

1.1 MariaDB와 오라클의 관계

MySQL의 역사:
- MySQL은 1995년에 처음 개발되었고, 빠르게 관계형 데이터베이스 시장에서 주요 플레이어로 자리 잡았습니다.
- 2008년, MySQL은 썬 마이크로시스템즈(Sun Microsystems)에 인수되었습니다.
- 2010년, 썬 마이크로시스템즈가 오라클(Oracle)에 인수되면서 MySQL 역시 오라클의 소유가 되었습니다.
MariaDB의 탄생:
- MySQL의 창시자였던 몬티 와이드니우스는 오라클의 MySQL 운영 방식에 대한 우려를 표명하며, MariaDB를 별도로 개발하기 시작했습니다.
- MariaDB는 MySQL의 코드베이스에서 분기된 포크 프로젝트로 시작되었으며, MySQL의 100% 오픈 소스 철학을 계승합니다.

2. ️ MariaDB의 핵심 구성 요소

MariaDB는 여러 가지 모듈과 구성 요소로 이루어져 있으며, 데이터베이스 엔진부터 고급 기능까지 다양한 요소를 포함합니다.

2.1 스토리지 엔진(Storage Engine)

MariaDB는 MySQL처럼 다양한 스토리지 엔진을 지원하며, 다음과 같은 주요 엔진이 포함됩니다.

InnoDB:
- MariaDB의 기본 스토리지 엔진.
- 트랜잭션 지원, 외래 키, ACID 특성 제공.
- 복잡한 애플리케이션과 대규모 트랜잭션 처리에 적합.
Aria:
- MyISAM의 대체 엔진으로 설계됨.
- 높은 쓰기 성능 제공.
- 주로 임시 테이블 용도로 사용.
ColumnStore:
- 컬럼 지향 저장 방식을 사용하여 분석 워크로드에 최적화.
- 대용량 데이터 분석에 유리.
MyRocks:
- RocksDB 기반의 스토리지 엔진.
- 쓰기 성능 최적화 및 효율적인 저장 공간 활용.
TokuDB:
- 압축 기술과 성능 향상에 중점을 둔 스토리지 엔진.
- 대규모 데이터베이스에서 효율적.

2.2 Replication(복제)

MariaDB는 기본적으로 데이터베이스 복제를 지원합니다. 이를 통해 데이터 가용성을 높이고 읽기 부하를 분산할 수 있습니다.

Master-Slave Replication:
- 하나의 마스터 데이터베이스에서 데이터를 작성하고, 여러 슬레이브 데이터베이스로 복제.
Master-Master Replication:
- 여러 노드에서 데이터를 동시에 읽고 쓰는 복제 모델.
Galera Cluster:
- MariaDB에서 클러스터링을 구현하는 기술.
- 트랜잭션이 모든 노드에 동기화되도록 보장.

3. MariaDB 설치 및 설정

MariaDB를 설치하고 기본적으로 사용할 수 있는 방법을 알아보겠습니다.

3.1 MariaDB 설치

MariaDB는 다양한 운영체제에서 사용할 수 있습니다. 여기서는 Ubuntu 기준으로 설명하겠습니다.

1️⃣ Ubuntu에서 설치

sudo apt update
sudo apt install mariadb-server

2️⃣ MariaDB 서버 시작

sudo systemctl start mariadb
sudo systemctl enable mariadb

3️⃣ 설치 확인

mariadb --version

3.2 초기 설정

MariaDB 설치 후 보안 설정을 진행합니다.

1️⃣ 보안 스크립트 실행

sudo mysql_secure_installation

기본적으로 루트 비밀번호 설정, 익명 사용자 삭제, 원격 루트 로그인 비활성화 등의 옵션을 설정합니다.

2️⃣ MariaDB 접속

MariaDB에 접속하려면 다음 명령어를 사용합니다:

sudo mariadb -u root -p

4. ️ MariaDB 사용법

4.1 데이터베이스 생성 및 사용

1️⃣ 데이터베이스 생성

CREATE DATABASE test_db;

2️⃣ 데이터베이스 확인

SHOW DATABASES;

3️⃣ 데이터베이스 사용

USE test_db;

4.2 테이블 생성 및 데이터 삽입

1️⃣ 테이블 생성

CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100)
);

2️⃣ 데이터 삽입

INSERT INTO users (name, email) VALUES
('Alice', 'alice@example.com'),
('Bob', 'bob@example.com');

3️⃣ 데이터 조회

SELECT * FROM users;

5. ️ RDB의 장점과 한계

5.1 RDB(Relational Database)의 장점

데이터 무결성:
- RDB는 엄격한 스키마와 제약 조건(Constraints)을 통해 데이터의 정확성과 일관성을 보장합니다.
트랜잭션 관리:
- 트랜잭션의 ACID(원자성, 일관성, 격리성, 지속성) 특성을 보장하여 안정적인 데이터 관리를 제공합니다.
관계형 모델:
- 테이블 간의 관계를 명시적으로 정의하여 복잡한 데이터 구조를 효과적으로 관리합니다.
표준화된 쿼리 언어(SQL):
- 데이터를 조회, 삽입, 수정, 삭제하기 위한 표준화된 언어를 제공합니다.

5.2 RDB의 한계

확장성 문제:
- 수평적 확장(Scale-Out)에 어려움이 있어, 데이터가 매우 방대해지면 성능이 저하될 수 있습니다.
고정 스키마:
- 스키마가 고정되어 있어, 데이터 구조가 자주 변경되는 경우 유연성이 떨어집니다.
비정형 데이터 처리 제한:
- 텍스트, 이미지, 동영상 등 비정형 데이터를 다루는 데 비효율적입니다.

요약: RDB는 일관성, 무결성, 트랜잭션 중심의 시스템에 적합하고, NoSQL은 확장성과 비정형 데이터 처리에 적합합니다.

7. 요약

MariaDB는 MySQL의 대안으로, 오픈 소스 철학을 유지하며 안정성과 성능을 제공합니다.
RDB는 데이터 무결성과 트랜잭션 관리에서 강력하지만, 확장성과 유연성에서 한계가 있습니다.
NoSQL은 비정형 데이터를 처리하고 확장성 있는 애플리케이션에서 뛰어난 성능을 발휘합니다.

[Docker]Docker를 이용해 MariaDB 설치하기

TaeHuiLee — Fri, 22 Nov 2024 10:23:28 +0900

이전 포스팅에서 다뤘던 [리눅스에서 Docker 설치 및 실행 방법] 내용을 참고하시면, 이번 주제에 대한 배경 지식이나 기초 정보를 확인하실 수 있습니다!

이 포스팅에서는 Docker를 이용해 MariaDB를 설치하고 사용하는 방법을 단계별로 설명하겠습니다. 최신 버전 MariaDB 사용 시 발생할 수 있는 오류를 방지하기 위해 10.7.4 버전을 사용하는 방법을 중점적으로 다룹니다.

1. 원하는 MariaDB Image를 다운로드

Docker는 이미지 기반의 가상화 기술로, MariaDB 이미지를 사용해 빠르게 데이터베이스 환경을 구축할 수 있습니다.

✅ 명령어

docker pull mariadb:10.7.4

설명

docker pull: Docker Hub에서 MariaDB 이미지를 다운로드.
mariadb:10.7.4: MariaDB의 10.7.4 버전을 명시적으로 지정합니다. 최신 버전이 불안정할 수 있으므로 권장됩니다.

2. Dockerfile 작성

Dockerfile은 MariaDB 컨테이너 이미지를 사용자 정의하는 데 사용됩니다.

✅ Dockerfile 내용

FROM mariadb:10.7.4

# 설정 파일 복사
#COPY my.cnf /etc/mysql/my.cnf
COPY my.cnf /etc/mysql/mariadb.conf.d/my.cnf

# 포트 노출
EXPOSE 3306

설명

FROM mariadb:10.7.4: 베이스 이미지를 설정. 여기서는 MariaDB의 특정 버전을 사용합니다.
COPY my.cnf /etc/mysql/my.cnf: MariaDB 설정 파일(my.cnf)을 컨테이너 내부로 복사합니다.
EXPOSE 3306: 컨테이너의 3306 포트를 노출. MariaDB의 기본 포트입니다.

3. 설정 파일 작성

MariaDB의 동작 방식을 설정하는 my.cnf 파일 작성 방법입니다.

✅ 예시 파일

[mysqld]
# MariaDB 설정 예제
user=mysql
datadir=/var/lib/mysql
socket=/var/run/mysqld/mysqld.sock

# 로그 파일 위치
log-error=/var/log/mysql/error.log
general_log_file=/var/log/mysql/mysql.log
slow_query_log_file=/var/log/mysql/mysql-slow.log

# 기타 설정
symbolic-links=0

설명

[mysqld]: MariaDB의 데몬 설정을 정의합니다.
datadir: 데이터 파일이 저장될 경로.
로그 파일 설정: MariaDB가 기록하는 로그 파일 위치를 지정합니다.
symbolic-links: 보안 문제 방지를 위해 심볼릭 링크를 비활성화.

⚠️ 주의: 설정 파일이 심볼릭 링크로 걸려있을 가능성이 있으니 확인 필요.

4. Docker 컨테이너 실행

MariaDB를 실행하는 Docker 명령어를 알아봅니다.

✅ 명령어

docker run --rm -d -p 3306:3306 --name mariadb \
-e MARIADB_USER=[user] \
-e MARIADB_PASSWORD=[password] \
-e MARIADB_ROOT_PASSWORD=[rootPassword] \
-e TZ=Asia/Seoul \
-v /appdata/mariadb/data:/var/lib/mysql \ 
-v /appdata/mariadb/config:/etc/mysql/mariadb.conf.d \
-v /appdata/mariadb/logs:/var/log/mysql \

mariadb:10.7.4

주요 옵션 설명

-e: 환경 변수 설정.
- MARIADB_USER: MariaDB 사용자 이름.
- MARIADB_PASSWORD: 사용자의 비밀번호.
- MARIADB_ROOT_PASSWORD: 관리자 계정(root)의 비밀번호.
- TZ=Asia/Seoul: 타임존 설정.
--rm: 컨테이너 종료 시 컨테이너를 삭제.
-d: 백그라운드 실행.
-p 3306:3306: 로컬 포트(3306)와 컨테이너 포트(3306)를 연결.
-v: 볼륨 마운트로 데이터 지속성을 확보.
- /var/lib/mysql: 데이터 파일이 저장될 위치.
- /etc/mysql/: MariaDB 설정 파일 위치.
- /var/log/mysql: MariaDB 로그 파일 위치.

5. 데이터 파일과 설정 파일의 권한 확인

MariaDB 컨테이너가 데이터를 올바르게 관리하기 위해서는 데이터 디렉토리 및 설정 파일 디렉토리의 권한이 정확히 설정되어 있어야 합니다.

✅ 권한 확인 및 수정 명령어

sudo chown -R 1001:1001 /appdata/mariadb/data

설명

chown -R 1001:1001: /appdata/mariadb/data 디렉토리의 소유자와 그룹을 컨테이너의 기본 MariaDB UID/GID(1001)로 변경.
MariaDB 사용자 권한: 기본적으로 MariaDB 컨테이너는 UID/GID 1001로 실행되므로, 해당 사용자가 데이터를 읽고 쓸 수 있어야 합니다.

⚠️ 주의: 잘못된 권한 설정은 MariaDB 컨테이너 실행 오류를 유발할 수 있습니다.

6. 기본 보안 설정 강화

MariaDB의 보안을 강화하려면 다음 설정을 추가로 고려해야합니다.

✅ 보안 강화 설정

1. 루트 계정 원격 접근 금지

MariaDB의 root 계정은 강력한 권한을 가지고 있어 보안에 취약할 수 있습니다. 원격 접근을 제한하고 별도의 관리 계정을 생성해야합니다.

CREATE USER 'admin'@'%' IDENTIFIED BY 'secure\_password';  
GRANT ALL PRIVILEGES ON _._ TO 'admin'@'%' WITH GRANT OPTION;  
REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'root'@'%';

2. 권한 최소화

특정 사용자가 필요한 데이터베이스에만 최소 권한을 가지도록 설정합니다.

GRANT SELECT, INSERT, UPDATE ON my\_database.\* TO 'my\_user'@'%';

3. `my.cnf` 보안 설정 추가

\[mysqld\]  
bind-address = 127.0.0.1 # 로컬 연결로 제한  
skip-symbolic-links # 심볼릭 링크 비활성화

설명

bind-address: MariaDB의 원격 접근을 제한하거나 특정 IP만 허용.
skip-symbolic-links: 보안 문제를 방지하기 위해 심볼릭 링크 비활성화.

7. 컨테이너 내부에서 데이터베이스 생성 및 계정 추가

MariaDB 컨테이너에 접속해 데이터베이스를 생성하고 계정을 설정합니다.

✅ 컨테이너 접속

docker exec -it mariadb bash
mysql -uroot -p
[rootPassword]

✅ 데이터베이스 생성

CREATE DATABASE my_database;

✅ 사용자 계정 생성 및 권한 부여

CREATE USER 'my_user'@'%' IDENTIFIED BY 'my_password';
GRANT ALL PRIVILEGES ON my_database.* TO 'my_user'@'%';
FLUSH PRIVILEGES;

설명

docker exec -it mariadb bash: 실행 중인 컨테이너에 접속.
mysql -uroot -p: root 사용자로 MariaDB에 로그인.
CREATE DATABASE: 새로운 데이터베이스 생성.
CREATE USER: MariaDB 사용자 계정 생성.
GRANT ALL PRIVILEGES: 사용자가 특정 데이터베이스에 대해 모든 권한을 가질 수 있도록 설정.
FLUSH PRIVILEGES: 권한 변경 사항을 즉시 적용.

정리

Docker로 MariaDB 이미지(10.7.4)를 다운로드.
MariaDB 설정 파일(my.cnf)을 작성하고 Dockerfile에 반영.
데이터 디렉토리 및 설정 파일 권한 확인 (chown 명령어 사용).
보안을 강화하여 원격 접근을 제한하고 최소 권한을 부여.
Docker 컨테이너 실행 및 내부에서 데이터베이스와 계정을 생성.

WSL에서 Docker 컨테이너 내부에서 외부 호출이 불가능한 문제 해결하기

TaeHuiLee — Thu, 21 Nov 2024 19:35:37 +0900

WSL(Windows Subsystem for Linux)을 사용할 때 Docker 컨테이너 내부에서 외부 네트워크에 접근할 수 없는 문제가 발생했습니다. 이 문제는 WSL과 Docker의 네트워크 구조 및 설정에서 비롯된 것이며, DNS 문제와 네트워크 브릿지 충돌 등이 원인일 수 있습니다.

문제의 원인과 개념을 자세히 설명하고, 이를 해결하는 방법을 차근차근 소개하겠습니다.

1. 문제의 원인 분석

1.1 WSL 네트워크 환경의 특징

WSL2는 Windows 내부에서 동작하는 가상화된 Linux 환경으로, 기본적으로 Windows 호스트 네트워크를 통해 인터넷에 연결됩니다.
WSL2와 Docker 간의 네트워크 설정이 서로 충돌하거나 호환되지 않으면 다음 문제가 발생할 수 있습니다.

Docker 컨테이너에서 외부 네트워크에 접근하지 못함.
WSL과 Docker 사이의 네트워크가 단절됨.

1.2 네트워크 브릿지 설정 문제

Docker는 기본적으로 bridge 네트워크를 사용하여 컨테이너 간 통신 및 외부 네트워크 연결을 관리합니다.
WSL2와 Docker가 사용하는 네트워크 인터페이스가 충돌하면 문제가 발생할 수 있습니다.

네트워크 브릿지란?

네트워크 브릿지는 컨테이너와 호스트 간의 통신, 컨테이너 간 통신, 외부 네트워크 연결을 가능하게 해주는 가상 네트워크입니다.
브릿지가 제대로 설정되지 않으면:

컨테이너가 외부 네트워크(인터넷)에 접근할 수 없음.
Docker와 WSL 사이의 네트워크가 단절됨.

1.3 DNS 설정 문제

컨테이너 내부에서 도메인 이름을 해석하려면 DNS 서버를 통해 도메인을 IP 주소로 변환해야 합니다.
WSL2 환경에서 Docker는 다음과 같은 이유로 DNS 문제를 겪을 수 있습니다.

WSL이 자동 생성한 resolv.conf 파일에 설정된 nameserver가 WSL 내부 DNS를 참조하지만, 컨테이너는 이를 사용할 수 없음.
Docker의 기본 DNS 설정이 WSL 네트워크와 충돌하거나, DNS 요청이 무한 순환되는 상황 발생.

1.4 `resolv.conf` 파일의 문제 (저는 이 문제였습니다.)

WSL2에서 /etc/resolv.conf 파일은 다음과 같이 자동 생성됩니다.

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.17.176.1

172.17.176.1: WSL 내부에서 생성된 가상 네트워크 인터페이스 주소입니다.
- 이 주소는 WSL 내부에서는 유효하지만, Docker 컨테이너에서는 접근 불가능할 수 있습니다.
- WSL과 Docker 간 네트워크 네임스페이스가 분리되어 있기 때문입니다.

1.5 방화벽/네트워크 규칙 문제

Windows 방화벽이 WSL과 Docker 사이의 네트워크 요청을 차단할 수도 있습니다.

예를 들어, WSL과 Docker의 네트워크 트래픽이 차단되면 DNS 요청이 실패하거나 네트워크 연결이 끊어질 수 있습니다.

2. 해결 방법: 단계별로 문제 해결하기

2.1 WSL의 DNS 자동 생성 비활성화

WSL이 자동으로 생성하는 /etc/resolv.conf 파일을 비활성화하고, 직접 DNS 설정을 추가합니다.

설정 방법:

/etc/wsl.conf 파일 수정:
[network] generateResolvConf = false
WSL 재시작:
wsl --shutdown
DNS 설정 파일 생성:아래 내용을 추가합니다:
nameserver 8.8.8.8 nameserver 8.8.4.4
sudo nano /etc/resolv.conf

이유:

Google Public DNS(8.8.8.8)를 명시적으로 사용하여 DNS 요청이 실패하지 않도록 설정합니다.

2.2 Docker 데몬 설정 수정(저는 이 방법을 사용했습니다.)

Docker가 사용할 DNS 서버와 네트워크 주소 범위를 명시적으로 설정합니다.

설정 파일 경로:

/etc/docker/daemon.json

설정 내용:

{
  "dns": ["8.8.8.8", "8.8.4.4"],
  "default-address-pools": [
    {
      "base": "192.168.1.0/24",
      "size": 24
    }
  ]
}

각 항목 설명:

dns: 컨테이너가 사용할 DNS 서버를 명시.
default-address-pools: Docker 네트워크의 IP 주소 범위를 명시하여 WSL 네트워크와의 충돌 방지.

Docker 서비스 재시작:

sudo service docker restart

2.3 네트워크 브릿지 확인 및 수정

Docker 네트워크 설정을 확인하고, 브릿지 네트워크를 조정합니다.

Docker 네트워크 확인:

docker network ls

브릿지 네트워크(bridge)가 활성화되어 있는지 확인합니다.

IP 충돌 방지:

Docker의 IP 풀을 재설정했으므로 브릿지가 올바르게 작동하지 않을 경우 아래 명령어로 네트워크를 재설정합니다.

docker network prune

2.4 방화벽 규칙 확인

Windows 방화벽에서 WSL과 Docker 관련 트래픽이 허용되도록 설정합니다.

2.5 DNS 캐시 초기화

WSL에서 DNS 캐시를 초기화하여 이전의 잘못된 DNS 설정을 제거합니다.

sudo resolvectl flush-caches

3. ✨ 정리

문제 원인:
- WSL의 자동 생성 DNS 설정이 Docker 컨테이너에서 동작하지 않음.
- Docker와 WSL 네트워크 충돌로 DNS 요청 실패.
- 방화벽 규칙 및 네트워크 브릿지 설정 문제.
해결 방법:
- WSL의 /etc/resolv.conf 파일을 비활성화하고, 명시적인 DNS 설정 추가.
- Docker 데몬 설정(/etc/docker/daemon.json)에 DNS와 네트워크 주소 범위를 명시.
- Windows 방화벽 규칙 확인 및 수정.
적용 후 테스트:
- Docker 컨테이너에서 외부 네트워크에 정상적으로 연결되는지 확인합니다:
```
docker run --rm alpine ping -c 3 google.com
```

위 과정을 차근차근 따라 하면, WSL 환경에서 Docker 컨테이너가 외부 네트워크에 접근하지 못하는 문제를 확실히 해결할 수 있습니다.

[Docker] SSH 연결 문제와 Docker 설정: 원인부터 해결까지

TaeHuiLee — Wed, 20 Nov 2024 13:57:39 +0900

SSH 연결 문제와 Docker 설정: 원인부터 해결까지

Docker 사용 중 서버에 SSH로 접속하여 도커 명령어를 실행하려고 할 때 접속이 끊기는 문제가 발생했습니다. 이 문제는 Docker의 IP 대역 충돌에서 비롯되었습니다. 앞으로 이러한 오류를 방지하기위해 이번 포스팅에서는 문제의 원인을 깊이 이해하고, 이를 해결하기 위한 방법인 daemon.json 설정 수정절차를 단계별로 알아보겠습니다.

1. 문제 상황

문제
로컬 PC에서 서버에 SSH로 접속 후 Docker를 실행하면 접속이 끊기거나 오류가 발생.

이 상황은 일반적으로 다음 이유 때문에 발생합니다.

Docker의 기본 네트워크 IP 대역인 172.17.0.0/16이 로컬 네트워크의 IP 대역과 겹칠 때 충돌.
충돌로 인해 Docker의 브리지 네트워크와 SSH 연결 간에 패킷이 잘못 라우팅되거나 차단됨.

2. 원인 분석

2.1 Docker 네트워크 기본값 이해하기

Docker는 컨테이너 간 통신을 위해 가상 네트워크를 생성합니다. 기본적으로 다음과 같은 네트워크 대역을 사용합니다.

브리지 네트워크 IP 대역: 172.17.0.0/16
Docker는 브리지 네트워크를 통해 컨테이너와 호스트 간 통신을 중계.

2.2 브리지 네트워크란?

브리지 네트워크는 호스트 머신과 Docker 컨테이너 간 가상 네트워크입니다.

기본적으로 Docker는 브리지 네트워크를 통해 컨테이너 간 통신과 외부 네트워크 연결을 관리합니다.
호스트 머신의 네트워크와 독립적으로 동작하므로 네트워크 격리를 제공합니다.

예:

호스트 머신: 192.168.1.10
Docker 컨테이너 네트워크: 172.17.0.0/16
이처럼 서로 다른 대역을 가지므로 네트워크 충돌이 없어야 하지만, 로컬 네트워크 대역이 중복되면 문제가 발생합니다.

2.3 충돌의 영향

SSH 연결 차단: 네트워크 충돌로 인해 SSH 연결 패킷이 손실될 수 있습니다.
Docker 작동 문제: 네트워크 충돌은 Docker 컨테이너 간 통신에도 문제를 유발합니다.

3. 해결 방법: `daemon.json` 설정

문제를 해결하려면 Docker의 네트워크 IP 대역을 변경하여 충돌을 방지해야 합니다. 이를 위해 /etc/docker/daemon.json 파일을 수정합니다.

3.1 `daemon.json` 기본 구조

daemon.json은 Docker 데몬의 설정 파일로, JSON 형식으로 작성됩니다. 이 파일을 통해 Docker의 기본 동작을 커스터마이징할 수 있습니다.

3.2 주요 설정 항목

아래는 문제 해결과 관련된 주요 설정 항목입니다:

data-root: Docker 데이터 경로를 변경.
bip: 브리지 네트워크 IP 대역 설정.
default-address-pools: Docker Compose의 네트워크 대역 설정.
insecure-registries: HTTP로 접근 가능한 프라이빗 레지스트리 설정.
registry-mirrors: Docker Hub 미러 설정.

4. 실습: `daemon.json` 수정

4.1 설정 파일 열기

sudo vi /etc/docker/daemon.json

4.2 수정 내용

{
    // Docker Root 경로 설정
    "data-root": "/data/docker",

    // 기본 Docker 브리지 네트워크 설정 (충돌 방지용 IP 대역)
    "bip": "192.172.100.1/24",

    // Docker Compose의 기본 네트워크 대역 설정
    "default-address-pools": [
        {
            "base": "192.172.100.1/16",
            "size": 24
        }
    ],

    // Docker 레지스트리 HTTP 연결 허용
    "insecure-registries": ["10.20.100.1:5000"],

    // Docker Hub 미러 설정
    "registry-mirrors": ["https://<my-docker-mirror-host>"]
}

설명

bip: Docker 브리지 네트워크의 기본 IP 대역을 변경.
default-address-pools: Docker Compose에서 기본 네트워크 대역을 별도로 설정.
insecure-registries: HTTP로 동작하는 프라이빗 레지스트리를 허용.
registry-mirrors: Docker Hub 대안 미러 설정.

5. 적용 및 확인

5.1 Docker 데몬 재시작

설정을 저장한 후 Docker 데몬을 재시작합니다:

sudo systemctl restart docker

5.2 설정 적용 확인

변경된 네트워크 대역을 확인하려면 다음 명령어를 실행:

docker network inspect bridge

출력에서 Subnet이 새로 설정한 대역으로 변경되었는지 확인합니다:

{
    "Subnet": "192.172.100.1/24"
}

6. ⚠️ 주의 사항

서버 재부팅 필요 여부: 일부 환경에서는 Docker 데몬 재시작만으로 충분하지만, 네트워크 충돌로 인해 시스템 재부팅이 필요할 수도 있습니다.
구성 파일 JSON 유효성 검사: JSON 파일 수정 시 유효한 형식인지 반드시 확인.
기존 네트워크 삭제: 기존 컨테이너의 네트워크 설정은 변경되지 않을 수 있으므로 필요시 네트워크를 삭제 후 다시 생성:
```
docker network rm <network_name>
```

7. 요약 및 결론

원인: Docker와 로컬 네트워크 간의 IP 대역 충돌로 SSH 연결이 차단됨.
해결책: daemon.json 파일에서 bip 및 default-address-pools 설정으로 네트워크 대역 변경.
주요 명령어:
- 설정 파일 열기: sudo vi /etc/docker/daemon.json
- Docker 재시작: sudo systemctl restart docker
- 네트워크 확인: docker network inspect bridge

위 내용을 따라가며 설정을 적용하면 Docker 네트워크 충돌 문제를 깔끔하게 해결할 수 있습니다. 더 궁금한 점이 있으면 댓글로 남겨주세요!

[Docker] 리눅스에서 Docker 설치 및 실행 방법

TaeHuiLee — Tue, 19 Nov 2024 17:16:40 +0900

Docker는 컨테이너 기반의 가상화 기술로, 개발 환경을 손쉽게 구성하고 배포하는 데 널리 사용됩니다. 이번 포스팅에서는 Ubuntu와 CentOS를 중심으로 리눅스에서 Docker를 설치하고 실행하는 방법을 단계별로 알아보겠습니다.

1. Ubuntu에서 Docker 설치 및 실행

1.1 Docker 설치

먼저 Docker를 설치하기 전에 패키지 목록을 업데이트합니다.

sudo apt update
sudo apt install -y docker.io

1.2 Docker 서비스 시작

설치가 완료되었다면 Docker 서비스를 시작합니다.

sudo systemctl start docker

1.3 부팅 시 Docker 자동 시작 설정

부팅 시 자동으로 Docker가 실행되도록 설정합니다.

sudo systemctl enable docker

1.4 WSL 사용자의 경우 자동 실행 설정

WSL 환경에서는 systemctl을 사용할 수 없으므로 별도 스크립트를 만들어 자동 실행하도록 설정합니다.

스크립트 생성:

sudo vi /etc/init.d/docker_daemon_run.sh

스크립트 내용:

#!/bin/bash
sudo dockerd &> /dev/null &

스크립트 실행 권한 부여:

sudo chmod +x /etc/init.d/docker_daemon_run.sh

WSL 시작 시 실행되도록 설정:

~/.bashrc 파일의 끝에 다음 내용을 추가합니다.
sudo /etc/init.d/docker_daemon_run.sh
visudo를 통해 스크립트 실행 시 비밀번호 입력을 생략하도록 설정합니다.visudo 편집기에서 다음 줄을 추가:
<사용자 이름> ALL=(ALL) NOPASSWD: /etc/init.d/docker_daemon_run.sh
sudo visudo

1.5 현재 사용자를 Docker 그룹에 추가

Docker를 루트 권한 없이 사용하려면 현재 사용자를 Docker 그룹에 추가해야 합니다.

sudo usermod -aG docker $USER

주의: 변경 사항을 적용하려면 로그아웃 후 다시 로그인하거나 시스템을 재시작해야 합니다.

2. CentOS에서 Docker 설치 및 실행

2.1 Docker 설치

CentOS에서는 yum 패키지 관리자를 사용하여 Docker를 설치합니다.

sudo yum install -y docker

2.2 Docker 서비스 시작

sudo systemctl start docker

2.3 부팅 시 Docker 자동 시작 설정

sudo systemctl enable docker

2.4 현재 사용자를 Docker 그룹에 추가

sudo usermod -aG docker $USER

3. 기타 배포판에서 Docker 설치

리눅스의 다른 배포판에서도 Docker 설치가 가능합니다. 아래는 공식 스크립트나 명령어를 사용하는 방법입니다.

3.1 공식 Docker 설치 스크립트 (Ubuntu, Debian 등)

공식 스크립트를 사용하면 Docker 설치가 간단합니다.

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER

3.2 CentOS 및 RHEL 기반 시스템

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum install docker-ce docker-ce-cli containerd.io
sudo systemctl start docker
sudo systemctl enable docker
sudo usermod -aG docker $USER

3.3 Fedora

sudo dnf install -y docker
sudo systemctl start docker
sudo systemctl enable docker
sudo usermod -aG docker $USER

4. Docker 설치 후 확인 및 기본 설정

4.1 Docker 버전 확인

Docker가 정상적으로 설치되었는지 확인하려면 다음 명령어를 실행합니다.

docker --version

4.2 컨테이너 실행

간단한 컨테이너를 실행하여 테스트합니다.

docker run hello-world

이 명령어는 Docker가 제대로 작동하는지 확인하기 위해 hello-world 이미지를 다운로드하고 실행합니다.

5. macOS 및 Windows에서 Docker 설치

5.1 macOS

macOS에서는 Docker Desktop을 공식 웹사이트에서 다운로드하는 방법이 일반적입니다.

5.2 Windows

Windows에서도 Docker Desktop을 설치하는 것이 권장됩니다.

정리

Ubuntu, CentOS 등에서 Docker를 설치하는 방법은 패키지 관리자 또는 공식 설치 스크립트를 통해 간단히 수행할 수 있습니다.
설치 후 반드시 Docker Daemon을 시작하고, 사용자를 Docker 그룹에 추가하여 권한을 설정해야합니다.
docker --version 명령어로 설치를 확인하고, docker run hello-world로 실행 테스트를 진행할 수 있습니다.

[Docker] Dockerfile 작성법

TaeHuiLee — Mon, 18 Nov 2024 21:30:01 +0900

이전 포스팅에서 다뤘던 [Docker란 무엇인가?] 내용을 참고하시면, 이번 주제에 대한 배경 지식이나 기초 정보를 확인하실 수 있습니다!

[Docker] Docker란 무엇인가?

1. Docker란 무엇인가요?Docker는 애플리케이션을 컨테이너라는 독립된 환경에 격리시켜 실행할 수 있게 도와주는 오픈 소스 플랫폼입니다. 애플리케이션과 그에 필요한 모든 라이브러리, 종속

tae-hui.tistory.com

1. ️ Dockerfile이란?

Dockerfile은 컨테이너 이미지를 정의하는 스크립트 파일로, 이미지 빌드에 필요한 설정과 명령을 담고 있습니다.

주요 특징

Dockerfile은 단계별로 이미지를 정의합니다.
빌드 시 각 단계가 레이어(layer)로 저장됩니다.
Docker는 레이어를 캐싱해 빌드 속도를 최적화합니다.

2. Dockerfile 명령어: 기본부터 심화까지

Dockerfile은 다양한 명령어로 구성됩니다. 명령어와 역할을 하나씩 살펴보겠습니다.

2.1. ️ `FROM`: 베이스 이미지 설정

Docker 이미지는 항상 베이스 이미지에서 시작합니다. 공식 이미지를 사용하는 것이 일반적입니다.

# Python 3.9 슬림 버전 사용
FROM python:3.9-slim

슬림(slim) 이미지는 경량화된 베이스 이미지로, 불필요한 라이브러리가 포함되지 않아 최적화에 유리합니다.

2.2. `RUN`: 명령 실행

이미지 빌드 과정에서 실행할 명령어를 정의합니다. 주로 패키지 설치, 환경 구성에 사용됩니다.

# 패키지 업데이트 및 설치
RUN apt-get update && apt-get install -y curl git

‍ 최적화 팁

명령어 병합: 여러 RUN 명령을 하나로 합쳐 레이어를 줄이세요.
RUN apt-get update && \ apt-get install -y curl git && \ apt-get clean && rm -rf /var/lib/apt/lists/*
캐싱 활용: 빈번히 변경되는 파일(코드)보다 의존성 설치 명령을 먼저 작성하세요.

2.3. `COPY`와 `ADD`: 파일 복사

컨테이너로 파일을 복사합니다.

COPY: 단순 파일 복사.
ADD: URL 다운로드, 압축 해제 기능 지원.

# 현재 디렉토리의 모든 파일을 컨테이너의 /app 디렉토리로 복사
COPY . /app

COPY 추천: 대부분의 경우 COPY가 더 효율적입니다. ADD는 URL이나 압축 파일 처리 시에만 사용하세요.

2.4. ️ `WORKDIR`: 작업 디렉토리 설정

명령어 실행의 기본 경로를 설정합니다. 이후 명령(RUN, CMD, COPY)은 이 디렉토리를 기준으로 실행됩니다.

WORKDIR /app

2.5. `ENV`: 환경 변수 설정

컨테이너 내부에서 사용할 환경 변수를 설정합니다.

ENV APP_ENV=production
ENV DEBUG=false

환경 변수는 모든 명령어와 애플리케이션에서 참조 가능합니다.

2.6. `EXPOSE`: 포트 공개

컨테이너가 외부와 통신할 포트 번호를 지정합니다.

EXPOSE 8080

주의: EXPOSE는 포트를 명시적으로 지정하는 역할만 합니다. 컨테이너 실행 시 실제로 열려면 docker run -p 옵션이 필요합니다.

2.7. ️ `CMD`와 `ENTRYPOINT`: 컨테이너 실행 명령 설정

컨테이너가 실행될 때 명령어를 정의합니다.

CMD: 컨테이너 시작 시 기본 실행 명령.
ENTRYPOINT: 고정 실행 명령.

CMD 예제

CMD ["python", "app.py"]

ENTRYPOINT 예제

ENTRYPOINT ["python"]
CMD ["app.py"]

동시 사용: ENTRYPOINT는 고정된 실행 파일, CMD는 옵션으로 함께 사용할 수 있습니다.

2.8. Multi-stage Build: 이미지 최적화

Multi-stage Build는 빌드와 런타임 환경을 분리해 이미지 크기를 최소화합니다.

# 1단계: 빌드
FROM node:16 AS builder
WORKDIR /app
COPY . .
RUN npm install && npm run build

# 2단계: 런타임
FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

이점: 빌드에 필요한 도구와 의존성을 최종 이미지에 포함하지 않아 더 작은 이미지를 생성합니다.

3. 종합 Dockerfile 예제

Python Flask 프로젝트 예제

# 베이스 이미지 설정
FROM python:3.9-slim

# 환경 변수 설정
ENV PYTHONUNBUFFERED=1 APP_ENV=production

# 작업 디렉토리 설정
WORKDIR /app

# 의존성 설치
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 애플리케이션 코드 복사
COPY . .

# 포트 공개
EXPOSE 5000

# 실행 명령 설정
CMD ["python", "app.py"]

Node.js 프로젝트 예제

# 1단계: 빌드
FROM node:16 AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install
COPY . .
RUN npm run build

# 2단계: 런타임
FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

4. Dockerfile 작성 시 주의사항 및 체크리스트

최소한의 베이스 이미지 사용: slim 또는 alpine 추천.
불필요한 파일 제외: .dockerignore 파일로 빌드에 포함되지 않을 파일 정의.
캐싱 최적화: 변경 빈도가 높은 명령은 아래쪽에 배치.
명령어 병합: RUN 명령을 한 줄로 합쳐 레이어 수 줄이기.
환경 변수 활용: 설정값을 코드에서 분리.
Multi-stage Build 사용: 빌드와 런타임 환경 분리.

5. ✨ 최종 요약

Dockerfile 작성 프로세스

FROM: 베이스 이미지 선택.
WORKDIR: 작업 디렉토리 설정.
COPY / ADD: 파일 복사.
RUN: 의존성 설치 및 환경 구성.
ENV: 환경 변수 설정.
EXPOSE: 외부 통신 포트 정의.
CMD / ENTRYPOINT: 컨테이너 실행 명령 설정.

실전 팁

Multi-stage Build로 이미지 크기 최소화.
불필요한 레이어 줄이기.
.dockerignore로 빌드 최적화.

[Nginx] Nginx 설정과 활용법

TaeHuiLee — Sun, 17 Nov 2024 10:00:41 +0900

Nginx 설정과 활용법

Nginx는 웹 서버, 리버스 프록시, 로드 밸런싱 등 다양한 용도로 활용할 수 있는 만능 도구라서, 제대로 이해하고 활용하면 큰 도움이 됩니다. 아래는 Nginx로 할 수 있는 주요 작업 10가지와 구체적인 설정 방법입니다.

1. 기본 웹 서버 설정

설정 내용

Nginx를 웹 서버로 설정하여 정적 파일(HTML, CSS, JS)을 서빙합니다.

설정 파일 (`nginx.conf`)

server {
    listen 80;
    server_name localhost;

    location / {
        root /usr/share/nginx/html;
        index index.html;
    }
}

도커로 실행

nginx.conf 파일을 생성합니다.
도커 컨테이너 실행 시 설정 파일을 마운트합니다.

docker run -d -p 80:80 -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf nginx

2. 리버스 프록시 설정

설정 내용

백엔드 서버(예: Node.js, Python 등)에 요청을 전달하는 리버스 프록시 설정입니다.

설정 파일

server {
    listen 80;

    location / {
        proxy_pass http://backend:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

도커 네트워크 활용

백엔드 컨테이너를 backend라는 이름으로 실행합니다.
도커 네트워크를 공유하도록 설정합니다.

docker network create my-network
docker run --network my-network --name backend my-backend-image
docker run --network my-network -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf -p 80:80 nginx

3. 로드 밸런싱 (Round Robin)

설정 내용

Nginx를 사용하여 여러 백엔드 서버에 로드 밸런싱을 적용합니다.

설정 파일

upstream backend_servers {
    server backend1:3000;
    server backend2:3000;
}

server {
    listen 80;

    location / {
        proxy_pass http://backend_servers;
    }
}

실행

docker network create lb-network
docker run --network lb-network --name backend1 my-backend-image
docker run --network lb-network --name backend2 my-backend-image
docker run --network lb-network -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf -p 80:80 nginx

4. 로드 밸런싱 (Least Connections)

설정 내용

least_conn 방식으로 트래픽을 처리하도록 설정합니다.

설정 파일

upstream backend_servers {
    least_conn;
    server backend1:3000;
    server backend2:3000;
}

server {
    listen 80;

    location / {
        proxy_pass http://backend_servers;
    }
}

5. HTTPS 설정

설정 내용

Let's Encrypt를 사용해 HTTPS를 적용합니다.

설정 파일

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/key.pem;

    location / {
        proxy_pass http://backend:3000;
    }
}

SSL 인증서 마운트

docker run -d -p 443:443 \
-v $(pwd)/nginx.conf:/etc/nginx/nginx.conf \
-v $(pwd)/ssl:/etc/nginx/ssl nginx

6. 서브도메인 분기 처리

설정 내용

서브도메인 별로 다른 백엔드로 요청을 전달합니다.

설정 파일

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://api_backend:3000;
    }
}

server {
    listen 80;
    server_name www.example.com;

    location / {
        proxy_pass http://web_backend:3000;
    }
}

7. 캐싱 설정

설정 내용

정적 파일에 대한 캐싱을 설정합니다.

설정 파일

server {
    listen 80;

    location /static/ {
        root /usr/share/nginx/html;
        expires 30d;
        add_header Cache-Control "public, must-revalidate";
    }
}

8. ️ 방화벽 역할 (IP 제한)

설정 내용

특정 IP 주소만 접근 가능하도록 설정합니다.

설정 파일

server {
    listen 80;

    location / {
        allow 192.168.1.1;
        deny all;
    }
}

9. Forward Proxy

설정 내용

Nginx를 클라이언트용 포워드 프록시로 사용합니다.

설정 파일

server {
    listen 8888;

    location / {
        proxy_pass $scheme://$http_host$request_uri;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

10. Custom Error Pages

설정 내용

404 에러 시 사용자 정의 에러 페이지를 반환합니다.

설정 파일

server {
    listen 80;

    error_page 404 /custom_404.html;

    location /custom_404.html {
        root /usr/share/nginx/html;
    }
}

️ 설정 확인 및 재시작

설정 파일 확인

docker exec -it <nginx-container-id> nginx -t

설정 적용

docker restart <nginx-container-id>

요약

Nginx의 주요 활용: 웹 서버, 리버스 프록시, 로드 밸런싱, HTTPS, 캐싱 등.
도커와 함께 사용: -v 옵션으로 설정 파일을 마운트하여 관리.
로드 밸런싱: Round Robin, Least Connections 등 다양한 방식 지원.
보안 및 최적화: IP 제한, 캐싱, HTTPS 설정.

[Jenkins] Jenkins Docker 컨테이너에서 Docker를 사용해 Git 소스 배포하기

TaeHuiLee — Sat, 16 Nov 2024 19:25:03 +0900

이전 포스팅에서 다뤘던 [ Jenkins CI/CD 환경 구축하기 ] 내용을 참고하시면, 이번 주제에 대한 배경 지식이나 기초 정보를 확인하실 수 있습니다!

[Jenkins] CI/CD 환경 구축하기

Jenkins로 CI/CD 환경 구축하기 - 기본 플러그인 소개부터 설치까지!개발이나 DevOps를 처음 시작한 분이라면 지속적 통합과 지속적 배포(Continuous Integration/Continuous Deployment, CI/CD) 자동화 도구로 Jen

tae-hui.tistory.com

Jenkins Docker 컨테이너에서 Docker를 사용해 Git 소스 배포하기

Jenkins를 Docker 컨테이너로 실행하면서 내부에서 호스트의 Docker 환경을 사용할 수 있게 설정하고, GitHub 소스를 가져와 빌드 및 배포까지 진행하는 방법을 알아보겠습니다. 이 과정에서는 Jenkins의 강력한 CI/CD 기능과 Docker를 활용한 배포 자동화를 결합합니다.

1. Jenkins 컨테이너 실행하기

먼저, Jenkins를 Docker 컨테이너로 실행하고, 호스트의 Docker 소켓을 컨테이너에 마운트하여 Docker 명령어를 사용할 수 있도록 설정해야 합니다.

Docker 명령어로 Jenkins 컨테이너 실행

docker run --rm -d -p 28080:8080 -p 50000:50000 \
-v /appdata/jenkins/jenkins_home:/var/jenkins_home \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /appdata/deploy:/home/portal/deploy \
-e TZ=Asia/Seoul \
-e JENKINS_OPTS="--httpPort=8080" \
-u root \
--name jenkins-container jenkins/jenkins:lts

주요 옵션 설명

-v /var/run/docker.sock:/var/run/docker.sock
- 호스트 Docker 소켓을 마운트하여 컨테이너 내부에서 Docker 명령어를 실행할 수 있게 만듭니다.
-u root
- root 사용자로 컨테이너를 실행합니다. Jenkins 컨테이너 내부에서 Docker 명령을 실행하려면 루트 권한이 필요합니다.
-v /appdata/jenkins/jenkins_home:/var/jenkins_home
- Jenkins 데이터를 호스트 디렉토리에 저장하여 데이터가 지속됩니다.

2. Jenkins 초기 설정

Jenkins 설치 후 초기 설정
- 브라우저에서 Jenkins에 접속합니다: http://<호스트 IP>:28080.
- 초기 관리자 비밀번호는 컨테이너 로그에서 확인할 수 있습니다.
- docker logs jenkins-container
- Jenkins UI에서 플러그인을 설치하고, 관리 계정을 생성합니다.
필수 플러그인 설치
- Jenkins 대시보드 → Manage Jenkins → Manage Plugins → Available 탭에서 다음 플러그인을 설치하세요:
  - Git Plugin
  - Docker Pipeline
  - SSH Pipeline Steps

[https://github.com/taehui8260/jenkins-plugins]해당 Github Repository에서 유용한 필수 플러그인을 직접 다운 후 적용할 수 있습니다.

Credential 설정
- GitHub Access Token: GitHub와 연동하기 위해 Personal Access Token을 생성하고 Jenkins에 추가합니다.
- Docker Hub 계정: Docker 이미지를 푸시하기 위해 Docker Hub 계정을 Jenkins에 등록합니다.
- SSH 계정: 원격 배포 서버에 접근하기 위해 SSH 정보를 등록합니다.

3. Jenkinsfile 작성하기

이제 Jenkinsfile을 작성하여, GitHub에서 코드를 가져오고 빌드 및 Docker 작업을 수행하는 파이프라인을 설정해 보겠습니다.

Jenkinsfile 코드

pipeline {
    agent any // Jenkins 노드에서 실행

    environment {
        GIT_REPO_URL = 'https://github.com/사용자명/레포지토리명.git'
        GIT_CREDENTIALS_ID = '깃허브-크리덴셜-ID'
        DOCKER_IMAGE = '사용자명/레포지토리명'
        DOCKER_CREDENTIALS_ID = '도커-크리덴셜-ID'
        CURRENT_DATE = sh(returnStdout: true, script: 'date +%Y%m%d%H%M').trim()
    }

    stages {
        stage('Clone Repository') {
            steps {
                git branch: 'main', credentialsId: "${GIT_CREDENTIALS_ID}", url: "${GIT_REPO_URL}"
            }
        }

        stage('Build') {
            steps {
                script {
                    def MAVEN_HOME = tool 'MAVEN_3.9.4'
                    sh "${MAVEN_HOME}/bin/mvn -f pom.xml clean package"
                }
            }
        }

        stage('Docker Build') {
            steps {
                script {
                    sh "docker build -t ${DOCKER_IMAGE}:${CURRENT_DATE} ."
                }
            }
        }

        stage('Docker Push') {
            steps {
                script {
                    withCredentials([string(credentialsId: "${DOCKER_CREDENTIALS_ID}", variable: 'DOCKER_PASSWORD')]) {
                        sh """
                        echo \$DOCKER_PASSWORD | docker login -u ${DOCKER_IMAGE} --password-stdin
                        docker push ${DOCKER_IMAGE}:${CURRENT_DATE}
                        """
                    }
                }
            }
        }

        stage('Deploy') {
            steps {
                script {
                    sh "docker run -d --name my-app-container ${DOCKER_IMAGE}:${CURRENT_DATE}"
                }
            }
        }
    }
}

4. 주요 단계 설명

GitHub에서 코드 가져오기
- git 명령어를 사용하여 GitHub의 소스를 Jenkins 워크스페이스로 가져옵니다.
Maven 빌드
- mvn clean package 명령어로 프로젝트를 빌드합니다. Maven 설정은 Jenkins Tools에서 관리합니다.
Docker 빌드
- docker build 명령어로 프로젝트의 Docker 이미지를 생성합니다.
Docker 푸시
- 생성된 이미지를 Docker Hub로 푸시합니다. Credential을 안전하게 관리하기 위해 withCredentials를 사용합니다.
Docker 배포
- Docker 컨테이너를 실행하여 배포합니다.

5. Jenkins Job 생성 및 실행

Jenkins 대시보드에서 New Item → Pipeline 선택.
Pipeline Script from SCM 설정:
- SCM: Git
- Repository URL: https://github.com/사용자명/레포지토리명.git
- Credentials: GitHub Access Token 선택.
Jenkins Job 실행 후, 단계별 로그를 확인하고 Docker Hub 및 컨테이너 상태를 점검합니다.

6. 추가 팁

Docker Volume 활용
- 컨테이너 내부 데이터의 영속성을 위해 볼륨을 적절히 설정하세요.
Credential 보안 관리
- Jenkins의 Credential Store를 사용해 민감한 정보를 안전하게 관리합니다.
자동화 향상
- Jenkins Pipeline에 알림 설정(Slack, Email)을 추가하여 빌드 및 배포 상태를 실시간으로 확인할 수 있습니다.

요약

Jenkins Docker 컨테이너 설정
- 호스트의 Docker 소켓을 마운트하여 내부에서 Docker를 사용할 수 있도록 설정합니다.
GitHub와 Docker 연동
- Jenkinsfile을 통해 GitHub에서 코드를 가져오고, Docker 이미지를 빌드하여 Docker Hub에 푸시한 후 배포합니다.
자동화된 CI/CD 파이프라인
- Jenkins를 활용해 빌드, 분석, Docker 작업, 배포까지 자동화된 워크플로우를 구현합니다.

Docker와 Jenkins를 통합하여 손쉽게 CI/CD 환경을 구축할 수 있습니다!

[JAVA] Java의 예외 계층 구조와 개념

TaeHuiLee — Fri, 15 Nov 2024 11:36:32 +0900

이전 포스팅에서 다뤘던 [ [JAVA] Java에서 예외 처리방법 ] 내용을 참고하시면, 이번 주제에 대한 배경 지식이나 기초 정보를 확인하실 수 있습니다!

[JAVA] Java에서 예외 처리방법

1. Java에서 예외 처리방법자바에서 예외 처리는 프로그램의 오류를 안전하게 처리하고 앱의 안정성을 유지하는 중요한 개념입니다. 예외는 예상치 못한 상황에서 발생할 수 있는 오류들을

tae-hui.tistory.com

1. Java의 예외 계층 구조와 개념

Java에서는 프로그램 실행 중 발생할 수 있는 문제를 체계적으로 관리하고 프로그램의 안정성을 높이기 위해 예외 처리를 제공합니다. 모든 예외 상황은 Throwable이라는 최상위 클래스를 중심으로 Error와 Exception으로 구분되며, 각 예외는 발생하는 시점과 성격에 따라 다르게 처리됩니다.

Throwable 계층 구조

Throwable: 모든 예외 객체의 최상위 부모 클래스입니다. 예외 상황을 구분하는 기반이 되며, Error와 Exception의 공통 부모 역할을 합니다.
- Error: 주로 JVM 레벨에서 발생하는 치명적 오류로, 개발자가 예측하거나 처리하기 매우 어려운 경우가 많습니다.
- Exception: 애플리케이션 수준에서 발생하는 오류로, 적절한 처리를 통해 복구 가능성이 높은 오류입니다.

JVM 실행 vs 애플리케이션 수준: 개념과 차이점

JVM 실행(JVM Level)은 Java Virtual Machine이 Java 코드를 운영 체제 위에서 실행하고 관리하는 수준을 의미합니다. 이 단계에서 발생하는 오류는 JVM 내부 자원 부족, 메모리 문제, 시스템 하드웨어 문제 등 시스템 전반에 영향을 미치는 심각한 오류가 포함됩니다. JVM은 이처럼 시스템 리소스와 직접 관련된 문제를 다루기 때문에 일반적으로 복구가 불가능합니다.

반면, 애플리케이션 수준(Application Level)은 우리가 작성한 애플리케이션 코드에서 발생하는 예외를 의미합니다. 여기에는 파일 입출력 문제, 데이터베이스 접근 오류, 잘못된 연산 등 로직이나 외부 자원과의 상호작용에서 발생하는 문제가 포함됩니다. 이와 같은 문제는 예외 처리를 통해 애플리케이션이 안정적으로 실행될 수 있도록 복구할 수 있습니다.

2. Error와 Exception: 발생 시점과 성격에 따른 차이

Java의 예외는 크게 JVM 실행 수준에서 발생하는 시스템 오류와 애플리케이션 수준에서 발생하는 오류로 구분할 수 있습니다. 이 차이에 따라 Error와 Exception으로 구분됩니다.

1) Error 클래스 - JVM 레벨에서 발생하는 시스템 오류

Error는 대부분 JVM이 Java 코드를 실행하는 중 메모리 부족, 무한 재귀 호출, 시스템 하드웨어 문제 등과 같은 치명적인 문제를 만났을 때 발생합니다. Error는 시스템 차원에서 발생하는 문제이기 때문에 대부분 복구가 불가능하며, try-catch 블록으로 처리하지 않는 것이 일반적입니다.

발생 시점: 실행 중 JVM이 심각한 문제를 만났을 때
복구 가능성: 대부분 복구 불가능, 단 일부 간접적 처리 가능
주요 Error 예시:
- OutOfMemoryError: JVM이 사용할 수 있는 메모리가 부족할 때 발생
  - 예: 대량의 데이터를 한꺼번에 로드하거나 메모리 누수가 발생하는 경우
  - 처리 가능성: try-catch로 잡을 수는 있으나, 메모리를 해제하거나 최적화하는 등 근본적인 해결이 필요합니다.
- StackOverflowError: 메서드 호출이 너무 깊어져 스택 메모리가 초과될 때 발생
  - 예: 재귀 함수의 종료 조건이 잘못되어 무한히 재귀 호출이 이루어질 때
  - 처리 가능성: 종료 조건을 설정하여 무한 재귀 호출을 방지하고, 코드 자체를 수정하여 예방할 수 있습니다.
- InternalError: JVM 내부에서 예기치 않은 문제가 발생할 때 발생
  - 예: JVM 실행 중 예상하지 못한 하드웨어나 운영 체제의 문제가 발생한 경우
  - 처리 가능성: 발생 원인이 JVM 내부 문제이기 때문에 애플리케이션 수준에서는 해결이 어렵습니다.
- AssertionError: 코드 검증을 위해 사용된 assert 구문이 실패할 때 발생
  - 예: 특정 조건이 거짓으로 판명될 때 assert로 예외 상황을 확인하고 개발자가 이를 검토할 수 있습니다.
  - 처리 가능성: 주로 디버깅 과정에서 사용되며, assert 구문을 통해 테스트 중인 조건이 만족되지 않을 때 발생합니다.

2) Exception 클래스 - 애플리케이션 레벨에서 발생하는 오류

Exception은 애플리케이션이 동작 중 발생할 수 있는 오류를 의미하며, 보통 적절한 예외 처리를 통해 복구 가능합니다. Exception은 다시 Checked Exception과 Unchecked Exception (Runtime Exception)으로 나뉩니다. 각각의 예외는 발생 시점과 상황에 따라 다르게 처리됩니다.

3. Checked Exception vs Unchecked Exception: 예외 발생 시점과 구체적인 예시

1) Checked Exception (컴파일 시점에서 발생)

Checked Exception은 외부 자원과의 상호작용 중 발생할 가능성이 높은 예외로, 예외 처리가 강제됩니다. 컴파일러는 Checked Exception이 발생할 가능성이 있는 코드를 try-catch로 감싸거나 throws로 선언하도록 요구합니다. 만약 이를 처리하지 않으면 컴파일 오류가 발생합니다.

발생 시점: 파일 입출력, 데이터베이스 접근, 네트워크 연결 등 외부 자원 접근 시 발생
복구 가능성: 대부분 복구 가능, 예외 처리를 통해 프로그램이 안정적으로 유지될 수 있습니다.
주요 Checked Exception 예시:
- IOException: 파일 입출력 작업에서 발생하는 예외
  - 예: 읽으려는 파일이 존재하지 않거나, 접근 권한이 없는 경우 발생
- SQLException: 데이터베이스와 연결 중 발생하는 예외
  - 예: 데이터베이스 연결 오류, SQL 구문 오류 등
- ClassNotFoundException: 지정된 클래스가 존재하지 않을 때 발생
  - 예: Class.forName("ClassName")으로 클래스를 찾으려 했으나 클래스가 존재하지 않는 경우
- InterruptedException: 스레드가 실행을 대기하는 중 인터럽트될 때 발생
  - 예: Thread.sleep() 중에 다른 스레드가 인터럽트를 발생시키는 경우

2) Unchecked Exception (Runtime Exception, 실행 시점에서 발생)

Unchecked Exception, 즉 RuntimeException은 실행 중 발생하는 예외로, 컴파일러가 예외 처리를 강제하지 않습니다. 주로 프로그래밍 논리 오류나 잘못된 접근으로 인해 발생하며, 개발자가 코드 자체를 수정하여 해결할 수 있습니다.

발생 시점: 코드의 논리 오류, 잘못된 접근 또는 연산으로 인해 발생
복구 가능성: 코드 수정으로 해결 가능
주요 Unchecked Exception 예시:
- NullPointerException: null 참조가 발생했을 때
  - 예: 객체가 초기화되지 않은 상태에서 해당 객체의 메서드나 필드에 접근할 때 발생
- ArrayIndexOutOfBoundsException: 배열의 유효하지 않은 인덱스에 접근할 때
  - 예: 배열 크기를 초과하는 인덱스를 참조하려 할 때
- ArithmeticException: 잘못된 산술 연산을 시도할 때
  - 예: 0으로 나누기를 시도하는 경우
- IllegalArgumentException: 메서드에 부적절한 인수가 전달될 때
  - 예: 특정 메서드에 예상한 값이 아닌 다른 값이 전달되는 경우
- ClassCastException: 잘못된 타입으로 객체를 캐스팅할 때
  - 예: 실제 타입과 맞지 않는 타입으로 강제 형 변환을 시도할 때

3) Unchecked Exception과 RuntimeException의 관계

Java에서 RuntimeException은 모든 Unchecked Exception의 상위 클래스입니다. RuntimeException을 상속하는 예외 클래스들은 모두 Unchecked Exception에 해당하므로, RuntimeException으로 선언하면 모든 Unchecked Exception을 포괄할 수 있습니다.

RuntimeException이 포괄하는 예외들

NullPointerException: null 참조가 발생할 때
ArrayIndexOutOfBoundsException: 배열의 유효하지 않은 인덱스를 참조할 때
ArithmeticException: 잘못된 산술 연산(예: 0으로 나누기)을 시도할 때
IllegalArgumentException: 메서드에 부적절한 인수가 전달될 때
ClassCastException: 잘못된 타입으로 객체를 캐스팅할 때

이처럼 모든 Unchecked Exception은 RuntimeException을 상속받아 이루어지기 때문에 catch (RuntimeException e) 구문으로 Unchecked Exception을 포괄적으로 처리할 수 있습니다.

4) Checked Exception을 포괄하는 상위 클래스는 존재하지 않음

Checked Exception은 컴파일러가 예외 처리를 강제하는 예외들이기 때문에, Checked Exception 전체를 포괄하는 상위 클래스는 없습니다. Java는 Checked Exception을 반드시 구체적으로 명시하도록 설계했기 때문에, Checked Exception의 최상위 클래스를 만들지 않았습니다.

왜 Checked Exception은 포괄하는 클래스가 없을까?

Java는 Checked Exception이 발생할 가능성이 높은 코드에서 예외를 명확하게 처리하도록 강제하는 언어입니다. 예를 들어, 파일 입출력, 데이터베이스 접근, 네트워크 연결 등에서 발생할 수 있는 예외들은 각각 IOException, SQLException 등으로 구체화되어 있고, 개발자는 특정 예외에 맞는 처리를 하도록 요구받습니다. 이를 통해 코드의 안정성과 예외 처리의 구체성을 높일 수 있죠.

즉, 모든 Checked Exception을 한꺼번에 잡아 처리할 수 있는 상위 클래스는 없으며, 개발자가 필요한 Checked Exception만 구체적으로 처리하도록 디자인되어 있습니다.

5) 모든 예외를 포괄하고 싶을 때: Exception 사용

모든 예외 상황을 한 번에 포괄하고 싶을 때는 Exception 클래스를 사용할 수 있습니다. Exception 클래스는 Throwable 하위의 모든 Checked Exception과 Unchecked Exception의 부모 클래스이므로, 모든 예외를 포괄적으로 처리할 수 있습니다.

try {
    // 예외가 발생할 가능성이 있는 코드
} catch (Exception e) {
    // 모든 Checked 및 Unchecked 예외를 포괄하는 처리
}

이 방식은 구체적인 예외 처리의 장점을 잃어버릴 수 있으므로 주의해서 사용해야 합니다. 상황에 맞는 예외를 구체적으로 처리하는 것이 보통 더 권장됩니다.

4. 예외 처리 방법: try-catch-finally, throw, throws

Java에서는 예외를 효율적으로 관리하기 위해 다양한 예외 처리 구문을 제공합니다. 각 구문에 대해 살펴보겠습니다.

try-catch-finally 구문

try-catch 구문은 예외가 발생할 가능성이 있는 코드를 try 블록에 작성하고, 특정 예외가 발생했을 때 catch 블록에서 이를 처리하는 기본 구문입니다. finally 블록은 예외 발생 여부와 관계없이 항상 실행되며, 주로 리소스를 정리하는 데 사용됩니다.

try {
  // 예외 발생 가능성이 있는 코드
} catch (ExceptionType e) {
  // 예외 발생 시 처리 코드
} finally {
  // 예외 발생 여부와 관계없이 항상 실행됨
}

throw와 throws 키워드

throw: 특정 예외를 강제로 발생시킬 때 사용합니다. 예를 들어, 잘못된 사용자 입력값이 들어왔을 때 throw new IllegalArgumentException("Invalid input")과 같이 사용할 수 있습니다.
throws: 메서드 선언부에서 사용되며, 메서드가 처리하지 않고 호출한 쪽으로 예외를 전달할 때 사용합니다.

public void someMethod() throws IOException {
  // 메서드 내에서 IOException 발생 가능성 있음
}

5. 예외 처리의 중요성: 프로그램 안정성 및 유지보수성 강화

Java의 예외 처리는 단순히 오류를 해결하기 위한 도구가 아니라, 프로그램이 예기치 않은 상황에서도 안정적으로 동작할 수 있도록 합니다. 예외 처리를 통해 외부 자원 문제, 사용자 입력 오류 등을 효과적으로 관리하여 시스템 다운타임을 최소화할 수 있습니다.

Java 예외 처리 요약

Error: 시스템 수준에서 발생하며, 보통 복구가 불가능합니다.
Checked Exception: 컴파일 시점에서 발생 가능성이 감지되며, 예외 처리가 강제됩니다.
Unchecked Exception (Runtime Exception): 실행 시점에 발생하며, 개발자가 코드 자체를 수정해 해결할 수 있습니다.
try-catch-finally 구문을 사용해 예외를 효과적으로 관리하고 throw와 throws로 예외를 전달하거나 강제로 발생시킬 수 있습니다.

위의 내용으로 Java 예외 처리의 개념, 구조, 종류와 처리 방법을 종합적으로 설명해드렸습니다. 각 예외 유형과 그에 따른 처리를 통해 더욱 안정적인 프로그램을 작성할 수 있습니다!

WSL(Windows Subsystem for Linux)에서 SSH 설정하기

TaeHuiLee — Thu, 14 Nov 2024 18:56:21 +0900

이전 포스팅에서 다뤘던 [WSL(Windows Subsystem for Linux) 설치 및 설정] 내용을 참고하시면, 이번 주제에 대한 배경 지식이나 기초 정보를 확인하실 수 있습니다!

WSL(Windows Subsystem for Linux) 설치 및 설정

1. WSL(Windows Subsystem for Linux) 설치 및 설정: 우분투 기반 사용하기WSL은 윈도우에서 리눅스 환경을 간편하게 사용할 수 있도록 해줍니다. 여기서는 Ubuntu 배포판을 설치하는 과정과 고정 IP 설정

tae-hui.tistory.com

️ WSL에서 SSH 설정하기

WSL에서 SSH를 사용하려면 SSH 서버를 활성화하고, SSH를 통해 외부에서 접속 가능하도록 설정해야 합니다. 아래 단계에 따라 설정하면 됩니다.

1. SSH 설치 확인

WSL에서 SSH를 사용하려면 SSH 서버가 설치되어 있어야 합니다. Ubuntu 등 WSL 배포판을 사용하고 있다면, 다음 명령어로 SSH 설치 여부를 확인합니다.

sudo apt update && sudo apt install openssh-server -y

2. SSH 서버 포트 확인하기

기본적으로 SSH 서버는 22번 포트를 사용합니다. SSH 서버가 올바르게 설치된 후에는 ss 명령어로 포트 상태를 확인할 수 있습니다.

sudo ss -tuln | grep 22

이 명령어는 현재 열려 있는 포트를 확인하고, 22번 포트가 열려 있는지 확인해줍니다. 만약 이 명령어의 출력에 22번 포트가 표시된다면, SSH 서버가 올바르게 작동 중이라는 의미입니다.

3. SSH 서버 상태 확인

이제 SSH 서버가 실행 중인지 확인해야 합니다. 다음 명령어를 사용하면 SSH 서버의 현재 상태를 알 수 있습니다.

sudo service ssh status

상태가 active(running)으로 표시된다면, SSH 서버가 정상적으로 실행 중인겁니다.
만약 inactive이나 stopped 상태로 표시되면 SSH 서버를 시작해야 합니다.

▶️ 4. SSH 서버 시작하기

SSH 서버가 비활성화 상태라면 다음 명령어로 시작할 수 있습니다.

sudo service ssh start

이제 SSH 서버가 실행되었고, 외부에서 접근할 수 있는 상태가 되었습니다. 그러나, 기본 설정으로는 비밀번호 인증이 비활성화되어 있을 수 있습니다. 이를 활성화해야 외부에서 비밀번호를 사용해 접속할 수 있습니다.

5. 비밀번호 인증 설정

SSH 서버에서 비밀번호 인증을 활성화하려면 SSH 설정 파일을 수정해야 합니다.

SSH 설정 파일을 엽니다.

sudo vi /etc/ssh/sshd_config

파일을 열었다면, PasswordAuthentication 옵션을 찾고, 해당 라인을 수정합니다.

만약 이 옵션이 주석 처리되어 있다면 주석을 제거합니다.
PasswordAuthentication 값을 yes로 설정합니다.

PasswordAuthentication yes

설정을 변경했으면 파일을 저장하고 종료합니다. vi 편집기에서 저장 후 종료하려면, Esc 키를 누른 후 :wq를 입력.

6. SSH 서버 재시작

설정 변경 사항을 적용하려면 SSH 서버를 다시 시작해야 합니다.

sudo service ssh restart

이제 SSH 서버가 비밀번호 인증을 허용하며, 외부에서 접속 가능해졌습니다.

7. WSL 실행 시 SSH 서버 자동 시작 설정

WSL이 시작될 때마다 SSH 서버를 자동으로 시작하려면 ~/.bashrc 파일에 SSH 서버 시작 명령을 추가해야 합니다.

~/.bashrc 파일을 엽니다.

vi ~/.bashrc

파일 맨 아래에 다음 줄을 추가합니다.

sudo service ssh start

이 명령어는 WSL이 실행될 때마다 SSH 서버를 자동으로 시작합니다.
파일을 저장하고 나가려면 Esc를 누르고 :wq를 입력합니다.

추가 설정을 적용하려면 터미널을 새로 열거나 아래 명령어로 .bashrc 파일을 다시 로드합니다.

source ~/.bashrc

이제 WSL을 실행할 때마다 자동으로 SSH 서버가 시작됩니다.

8. SSH로 접속 테스트하기

설정을 마쳤다면, 이제 원격에서 접속을 테스트할 수 있습니다. SSH 클라이언트가 있는 다른 장치에서 다음 명령어를 사용하여 접속합니다.

ssh username@server-ip

위 명령어에서 username은 WSL 환경의 사용자 이름으로, server-ip는 WSL이 설치된 장치의 IP 주소로 교체합니다.

⚠️ 주의 사항

로컬 네트워크 외부에서 SSH 접속을 시도할 경우, 라우터에서 포트 포워딩 설정이 필요할 수 있습니다.
SSH 보안을 위해 추가적으로 방화벽 설정을 검토하세요.

[JAVA] Java에서 예외 처리방법

TaeHuiLee — Wed, 13 Nov 2024 21:37:44 +0900

1. Java에서 예외 처리방법

자바에서 예외 처리는 프로그램의 오류를 안전하게 처리하고 앱의 안정성을 유지하는 중요한 개념입니다. 예외는 예상치 못한 상황에서 발생할 수 있는 오류들을 지칭하는데, 자바에서는 try-catch-finally 구문, throws 키워드, 그리고 커스텀 예외를 통해 다양한 예외 상황을 처리할 수 있습니다.

이 포스트에서는 자바에서 예외를 처리하는 방법을 세부적으로 설명하고, 예외 처리와 트랜잭션 처리의 관계를 알아본 뒤, 커스텀 예외를 만드는 방법까지 상세히 설명하겠습니다.

‍♂️ 2. 자바에서 예외 처리하는 주요 방법

2.1 `try-catch` 구문 사용하기

try-catch 구문은 자바에서 예외를 잡아내고 처리하는 가장 기본적인 방법입니다.

try: 예외가 발생할 가능성이 있는 코드를 감싸는 블록입니다.
catch: 특정 예외가 발생했을 때 실행되는 블록으로, 예외 종류에 따라 여러 개를 작성할 수 있습니다.
finally: 예외 발생 여부와 관계없이 항상 실행되는 블록으로, 주로 자원을 해제할 때 사용합니다.

try {
    // 예외가 발생할 가능성이 있는 코드
} catch (ExceptionType e) {
    // 예외 처리 코드
} finally {
    // 예외 발생 여부와 상관없이 실행되는 코드
}

2.2 `throws` 키워드 사용하기

메소드에서 특정 예외를 처리하지 않고 호출한 쪽에 넘길 때 사용합니다. 이를 예외 전가라고 하며, 메소드 선언부에 throws 키워드를 붙여 선언합니다.

public void exampleMethod() throws IOException {
    // 예외 발생 가능성이 있는 코드
}

이 방식은 호출자가 예외를 직접 처리하도록 책임을 넘기기 때문에 예외가 발생한 상황에서 유연하게 대응할 수 있습니다.

3. 트랜잭션과 예외 처리의 관계

트랜잭션은 데이터베이스에서 하나의 작업 단위로, 모든 작업이 성공적으로 완료되거나, 하나라도 실패하면 전체를 롤백하는 특징이 있습니다. Java와 스프링에서는 @Transactional 애너테이션을 통해 트랜잭션을 관리하는데, 예외가 발생하면 트랜잭션은 자동으로 롤백됩니다.

그러나, 예외가 발생한다고 무조건 롤백이 되지는 않습니다. 예외 유형에 따라 트랜잭션의 동작이 달라지기 때문인데

3.1 기본적인 트랜잭션 롤백 규칙

Unchecked Exception (런타임 예외): RuntimeException과 그 하위 예외들은 기본적으로 트랜잭션을 롤백합니다.
Checked Exception: Exception을 상속한 예외는 트랜잭션을 롤백하지 않으며, 필요 시 직접 설정이 필요합니다.

스프링에서는 이러한 규칙을 이해하고 @Transactional 애너테이션의 rollbackFor 속성을 사용해 롤백할 예외 유형을 지정할 수 있습니다.

@Transactional(rollbackFor = Exception.class)
public void someMethod() throws Exception {
    // 트랜잭션 관리 코드
}

‍♂️ 4. try-catch를 사용할 때 트랜잭션이 롤백되지 않는 이유

스프링의 트랜잭션 처리는 프록시(Proxy) 패턴을 통해 이루어집니다. @Transactional이 적용된 메소드에서 예외가 발생하면 프록시는 해당 예외를 감지해 트랜잭션을 롤백하게 됩니다. 하지만 try-catch 구문으로 예외를 잡아내면, 스프링은 예외가 발생했는지 인지하지 못하고 트랜잭션을 정상 종료(커밋) 시키게 됩니다.

예시 코드

@Transactional
public void processTransaction() {
    try {
        // 예외가 발생할 수 있는 코드
    } catch (Exception e) {
        // 예외를 잡아버려서 트랜잭션 롤백이 되지 않음
        System.out.println("Exception caught: " + e.getMessage());
    }
}

이 코드에서는 예외가 발생하더라도 catch에서 처리해버리면 트랜잭션이 자동으로 롤백되지 않습니다. 이를 해결하기 위해 catch 블록에서 RuntimeException으로 다시 예외를 던지거나 throws를 사용해 상위 메소드로 예외를 전파할 수 있습니다.

@Transactional
public void processTransaction() {
    try {
        // 예외가 발생할 수 있는 코드
    } catch (Exception e) {
        System.out.println("Exception caught: " + e.getMessage());
        throw new RuntimeException(e); // 예외를 다시 던져 트랜잭션 롤백 유도
    }
}

5. 커스텀 예외 만들기와 글로벌 예외 처리

자바에서는 사용자 정의 예외(커스텀 예외)를 만들어 특정 상황에서 발생하는 예외를 명확하게 구분할 수 있습니다. 커스텀 예외는 Exception 클래스를 상속하거나, 더 넓은 범위에서 잡기 위해 RuntimeException을 상속받아 만들 수 있습니다.

5.1 커스텀 예외 만들기 예시

public class CustomException extends RuntimeException {
    public CustomException(String message) {
        super(message);
    }
}

이렇게 만든 커스텀 예외는 필요할 때마다 throw로 발생시킬 수 있으며, 예외 메시지나 추가 정보를 전달해 디버깅에 도움이 됩니다.

public void riskyMethod() {
    if (/* 특정 조건 */) {
        throw new CustomException("커스텀 예외 발생: 특정 조건을 만족하지 않음");
    }
}

5.2 커스텀 예외와 글로벌 예외 처리

스프링에서는 @ControllerAdvice와 @ExceptionHandler를 통해 글로벌 예외 처리를 할 수 있어요. 글로벌 예외 처리를 사용하면 특정 예외가 발생했을 때 일관된 응답을 반환할 수 있고, 모든 컨트롤러에 공통적으로 적용됩니다.

예시 코드

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(CustomException.class)
    public ResponseEntity<String> handleCustomException(CustomException ex) {
        return new ResponseEntity<>(ex.getMessage(), HttpStatus.BAD_REQUEST);
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<String> handleGeneralException(Exception ex) {
        return new ResponseEntity<>(ex.getMessage(), HttpStatus.INTERNAL_SERVER_ERROR);
    }
}

이 GlobalExceptionHandler 클래스는 커스텀 예외인 CustomException이 발생하면 일관된 메시지와 상태 코드를 클라이언트에 반환하는 역할을 합니다. 이런 글로벌 예외 처리 덕분에 코드의 일관성을 유지하고 중복된 예외 처리 코드를 줄일 수 있습니다.

5.3 커스텀 예외와 트랜잭션 롤백 설정

커스텀 예외가 발생했을 때 트랜잭션이 롤백되길 원한다면, 커스텀 예외를 RuntimeException으로 상속하면 기본적으로 롤백됩니다. 만약 그렇지 않다면, @Transactional 애너테이션의 rollbackFor 속성을 설정해 강제로 롤백할 수 있습니다.

@Transactional(rollbackFor = CustomException.class)
public void someTransactionalMethod() throws CustomException {
    throw new CustomException("커스텀 예외 발생으로 인한 롤백");
}

6. 예외 처리 흐름 요약

자바에서 예외가 발생했을 때의 처리를 단계별로 보면 다음과 같습니다.

예외 발생: 예외가 발생하면 JVM은 이를 인식하고 예외 객체를 생성합니다.
예외 처리 탐색: JVM은 try-catch 블록을 찾고, 일치하는 catch 블록이 있는지 확인합니다.
예외 처리 수행: 해당 예외와 일치하는 catch 블록이 있으면, 그 안의 코드가 실행되고 예외는 처리됩니다.
finally 블록 실행: finally 블록이 있으면 무조건 실행됩니다.
트랜잭션 롤백 여부 판단: 예외가 RuntimeException 또는 Error이면 기본적으로 트랜잭션이 롤백됩니다. 그렇지 않으면 설정에 따라 다르게 동작합니다.

요약
자바의 예외 처리는 주로 try-catch, throws, 그리고 커스텀 예외를 통해 관리합니다. 트랜잭션은 RuntimeException에 의해 롤백되며, 커스텀 예외의 경우도 상속된 클래스에 따라 롤백 여부가 결정됩니다. 또한, 글로벌 예외 처리를 통해 일관된 예외 응답을 반환하고 코드 중복을 줄일 수 있습니다.

[Kubernetes] 쿠버네티스(Kubernetes)란 무엇인가

TaeHuiLee — Tue, 12 Nov 2024 16:34:16 +0900

️ 1. 쿠버네티스(Kubernetes)란 무엇인가?

쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션을 자동으로 배포, 관리 및 확장하는 오픈 소스 플랫폼입니다. 쿠버네티스는 Google에서 개발한 컨테이너 오케스트레이션 툴로 시작되었고, 현재는 CNCF(Cloud Native Computing Foundation)에서 관리하고 있습니다. 쿠버네티스는 특히 대규모의 분산 시스템에서 뛰어난 확장성과 자동화 기능을 제공하는데, 이 덕분에 클라우드 환경에서 애플리케이션을 쉽게 관리할 수 있습니다.

✨ 쿠버네티스의 핵심 개념

쿠버네티스를 이해하려면, 주요 개념 몇 가지를 알아야 합니다.

Pod

쿠버네티스에서 가장 작은 배포 단위로, 하나 이상의 컨테이너를 포함할 수 있습니다. 보통 하나의 애플리케이션 인스턴스를 의미합니다.
각 Pod는 고유 IP를 가지며, 같은 Pod 안의 컨테이너들은 네트워크와 스토리지를 공유합니다.
Pod는 하나 이상의 컨테이너를 포함할 수 있지만, 대부분의 경우 하나의 컨테이너만 포함합니다. Pod는 쿠버네티스에서 논리적 단위로, 실제로 컨테이너는 Docker와 같은 컨테이너 런타임에 의해 실행됩니다.
Pod 내부의 컨테이너들은 네트워크 네임스페이스를 공유하기 때문에 같은 IP를 사용하여 서로 통신할 수 있습니다.

Node

쿠버네티스 클러스터에서 실제 애플리케이션이 실행되는 서버입니다. 노드는 물리적 서버일 수도 있고 가상 머신일 수도 있습니다.
각 Node는 여러 Pod를 포함할 수 있으며, Node가 여러 개 모여 클러스터를 이룹니다.
Node에는 kubelet이라는 에이전트가 실행되어 쿠버네티스의 API 서버와 통신하며, 해당 Node에서 Pod를 실행하고 관리합니다.

Cluster

여러 Node가 모여 구성하는 하나의 큰 시스템입니다. 쿠버네티스가 클러스터 전체를 관리하며, 애플리케이션의 확장, 자원 할당, 장애 복구 등을 담당합니다.
클러스터는 여러 Node를 네트워크로 연결하여 구성되며, 각 Node는 물리적으로 분산되어 있을 수 있지만, 네트워크를 통해 하나의 클러스터로 관리됩니다.

ReplicaSet

특정 Pod의 복제본 수를 지정하여 항상 원하는 개수를 유지하게 해주는 오브젝트입니다.
예를 들어, Pod 인스턴스를 3개로 설정하면, 한 인스턴스가 죽더라도 자동으로 새 인스턴스를 생성해 3개를 유지합니다.

Deployment

Deployment는 애플리케이션의 버전 관리와 롤백을 지원해줍니다. 예를 들어 애플리케이션을 배포하다가 문제가 발생하면 손쉽게 이전 버전으로 되돌릴 수 있습니다.

️ 2. 쿠버네티스의 주요 기능과 특징

자동화된 배포와 복구

애플리케이션을 자동으로 배포하고 오류가 발생하면 자동으로 복구합니다. 이를 통해 서버 다운타임을 최소화할 수 있습니다.

확장성 (Scalability)

애플리케이션의 사용량이 많아지면 Pod의 수를 늘려 쉽게 확장할 수 있습니다. 반대로 사용량이 적을 때는 자원을 절약할 수 있습니다.

롤링 업데이트와 롤백

쿠버네티스는 버전 업데이트를 점진적으로 적용하는 롤링 업데이트를 지원합니다. 만약 업데이트 중 문제가 발생하면, 즉시 롤백할 수 있습니다.

3. 도커(Docker)와 쿠버네티스의 관계

Docker란?

Docker는 컨테이너화된 애플리케이션을 만드는 도구입니다. 개발 환경에서부터 배포 환경까지 일관된 환경을 제공해주는 도구로, 컨테이너 이미지라는 패키지를 통해 애플리케이션을 환경에 구애받지 않고 실행할 수 있게 해줍니다.

Docker와 Kubernetes의 관계

쿠버네티스와 도커는 애플리케이션을 컨테이너로 실행하고 관리한다는 점에서 상호보완적인 관계입니다.

도커: 애플리케이션의 컨테이너 이미지를 만들고 배포하는 도구
쿠버네티스: 여러 도커 컨테이너를 오케스트레이션하고 관리하는 플랫폼

즉, 도커가 컨테이너를 실행하는 역할을 한다면, 쿠버네티스는 여러 개의 컨테이너를 하나의 시스템으로서 관리하는 역할을 합니다.

쿠버네티스는 도커 외에도 containerd나 CRI-O와 같은 다른 컨테이너 런타임을 사용할 수 있습니다. Pod는 쿠버네티스에서 논리적 단위로, Docker를 포함한 다양한 컨테이너 런타임에 의해 실행됩니다.

️ 4. 쿠버네티스 기본 구성 요소와 실습 예제

쿠버네티스를 이해하기 위해 실제 예제를 통해 살펴보겠습니다. 이번 예제에서는 간단한 Nginx 서버를 배포하는 과정을 보여드리겠습니다.

Step 1: 쿠버네티스 클러스터 생성

미니쿠베(Minikube)를 사용하여 로컬에서 쿠버네티스 클러스터를 생성할 수 있습니다.

minikube start

Step 2: Nginx Pod 생성

이제 nginx-pod.yaml 파일을 만들어서 Nginx 컨테이너를 실행해보겠습니다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

파일을 만든 후 다음 명령어로 Pod를 생성합니다.

kubectl apply -f nginx-pod.yaml

Step 3: Pod 상태 확인

Pod가 잘 생성되었는지 확인하려면 kubectl get pods 명령어를 사용합니다.

kubectl get pods

Step 4: Deployment 설정

이제 Deployment를 사용하여 Nginx 애플리케이션을 배포해 보겠습니다. nginx-deployment.yaml 파일을 작성합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

작성한 파일을 배포합니다.

kubectl apply -f nginx-deployment.yaml

Step 5: 서비스 생성

외부에서 Nginx 서버에 접근할 수 있도록 Service를 설정합니다. nginx-service.yaml 파일을 작성합니다.

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

다음 명령어로 서비스를 생성합니다.

kubectl apply -f nginx-service.yaml

Step 6: 서비스 접근

마지막으로, 생성한 서비스의 NodePort를 통해 Nginx 애플리케이션에 접근할 수 있습니다.

minikube service nginx-service

5. 쿠버네티스의 장점과 한계

장점

자동화된 인프라 관리: 스케일링, 배포, 장애 복구 등이 자동화되어 관리 부담이 줄어듭니다.
플랫폼 독립성: 어디서든 애플리케이션을 동일한 방식으로 실행할 수 있습니다.
확장성: 대규모 애플리케이션 관리에 유리하여 유연한 확장이 가능합니다.

한계

복잡성: 초기 설정과 사용법이 다소 어렵습니다.
비용 문제: 대규모 환경에서는 관리와 자원 사용 비용이 증가할 수 있습니다.

쿠버네티스는 여러 Node를 네트워크로 연결하여 관리합니다. 각 Node는 물리적으로 분산되어 있을 수 있지만, 네트워크를 통해 하나의 클러스터로 구성됩니다. 컨트롤 플레인은 클러스터 전체를 관리하며, API 서버는 각 Node와 통신하여 Pod의 상태를 제어합니다. 각 Node의 kubelet은 API 서버와 상호작용하며 Pod를 실행하고 상태를 모니터링합니다.

요약

쿠버네티스는 컨테이너화된 애플리케이션을 배포하고 관리하는 자동화된 플랫폼입니다. Docker와 함께 사용되며, 복잡한 환경에서의 효율적인 애플리케이션 관리를 가능하게 해줍니다. Pod, Node, Cluster 같은 기본 개념을 통해 확장성과 복원성을 갖춘 시스템을 구축할 수 있으며, kubectl 명령어와 YAML 파일을 통해 다양한 설정을 할 수 있습니다.

요약하자면: 쿠버네티스는 여러 컨테이너를 자동으로 관리하고 확장하는 플랫폼으로, 도커 컨테이너를 효율적으로 오케스트레이션하여 대규모 애플리케이션 운영을 지원합니다.

[JAVA] 프로젝트에서 PMD를 이용한 소스 품질 검사

TaeHuiLee — Mon, 11 Nov 2024 15:45:23 +0900

️ 프로젝트에서 PMD를 이용한 소스 품질 검사

PMD는 Java와 같은 언어로 작성된 코드를 분석하여 코드 스타일, 복잡성, 중복, 오류 가능성 등의 문제를 잡아주는 정적 코드 분석 도구입니다. 품질 좋은 코드를 유지하려면 특히 중요한데, PMD는 프로젝트 코드의 품질을 한층 더 높이는 데 큰 도움을 줍니다. 오늘은 PMD에 대해 알아보고, 설정 방법과 사용 예시를 자세히 설명하겠습니다.

1. PMD란 무엇인가?

PMD(Programming Mistake Detector)는 오픈소스 정적 코드 분석 도구로, Java, JavaScript, XML 등을 포함한 여러 언어를 지원합니다. PMD는 코드에 대한 다양한 규칙(Rule)을 제공하여 코드의 오류나 중복 코드 등을 탐지합니다. 이를 통해 복잡성이나 코드 스타일 문제를 미리 발견하고, 유지 보수성을 높이는 데 큰 역할을 합니다.

2. ️ PMD의 주요 기능

PMD는 아래와 같은 주요 기능을 제공합니다:

코드 스타일 검사: 예를 들어, 클래스 이름이 CamelCase인지 확인하거나, 메소드가 너무 길지 않은지 검사합니다.
중복 코드 검사: 프로젝트 내에서 코드 중복이 발생했는지 감지하여 유지 보수를 쉽게 합니다.
복잡성 검사: 메서드의 복잡도를 측정해 가독성과 유지 보수성을 높입니다.
잠재적 오류 탐지: 예를 들어, 무한 루프가 발생할 가능성이 있는 코드를 찾아내기도 합니다.
커스텀 규칙 작성 기능: 프로젝트 요구에 맞게 맞춤형 규칙을 만들 수 있습니다.

3. PMD 설치하기

PMD는 일반적으로 Gradle, Maven 등 빌드 도구에 플러그인으로 추가하여 사용합니다. 여기서는 Gradle과 Maven 설정 방법을 설명하겠습니다.

Gradle에 PMD 추가하기

먼저 build.gradle 파일에서 PMD 플러그인을 추가합니다.

plugins {
    id 'java'
    id 'pmd'
}

pmd {
    toolVersion = '6.50.0'  // 원하는 버전 입력
    ignoreFailures = true   // 오류가 발생해도 빌드를 중단하지 않음
}

tasks.withType(Pmd) {
    reports {
        xml.required = true
        html.required = false
    }
}

PMD가 설치되면 ./gradlew pmdMain 명령어로 메인 소스에 대한 PMD 검사를 수행할 수 있습니다.

Maven에 PMD 추가하기

pom.xml 파일에 PMD 플러그인을 추가합니다.

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-pmd-plugin</artifactId>
            <version>3.15.0</version> <!-- 원하는 버전 입력 -->
            <configuration>
                <linkXref>false</linkXref>
                <printFailingErrors>true</printFailingErrors>
            </configuration>
            <executions>
                <execution>
                    <phase>verify</phase>
                    <goals>
                        <goal>check</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

이후 mvn pmd:check 명령어를 통해 PMD 검사를 실행할 수 있습니다.

4. PMD의 Rule 설정하기

PMD는 rulesets을 통해 코드 검사 규칙을 정의합니다. 기본 제공되는 rule을 사용할 수도 있고, 필요한 경우 직접 정의할 수도 있습니다. PMD가 제공하는 규칙에는 Java Basic Rules, Code Style Rules, Design Rules 등이 있으며, 예를 들어 rulesets/java/quickstart.xml 파일에서 규칙을 정의할 수 있습니다.

<ruleset name="My Custom Rules" xmlns="http://pmd.sourceforge.net/ruleset/2.0.0">
    <description>Custom ruleset for my project.</description>

    <!-- 기본 규칙 추가 -->
    <rule ref="category/java/bestpractices.xml"/>
    <rule ref="category/java/codestyle.xml"/>

    <!-- 복잡성 규칙 커스터마이징 -->
    <rule ref="category/java/design.xml/CyclomaticComplexity">
        <properties>
            <property name="max" value="10"/> <!-- 복잡도가 10 이상이면 경고 -->
        </properties>
    </rule>
</ruleset>

규칙 파일 적용하기

위와 같이 작성한 규칙 파일을 빌드 설정에서 적용할 수 있습니다. 예를 들어 Gradle에서는 다음과 같이 적용합니다.

pmd {
    ruleSetFiles = files("config/pmd/ruleset.xml")  // 설정 파일 경로 입력
}

5. PMD 검사 실행하기

위와 같이 설정한 PMD를 이제 실행하여 소스 품질을 검사해보겠습니다.

Gradle에서 PMD 검사 실행하기

다음 명령어로 PMD 검사를 수행할 수 있습니다.

./gradlew pmdMain

실행하면 build/reports/pmd/main.html 파일에 검사 결과가 저장됩니다. 결과 보고서를 통해 어떤 파일의 어떤 부분에서 문제가 발생했는지 확인할 수 있습니다.

Maven에서 PMD 검사 실행하기

Maven을 사용하는 경우 다음 명령어를 실행합니다.

mvn pmd:check

PMD가 코드 품질 검사를 수행하고, 보고서를 target/site/pmd.html 파일로 생성합니다.

6. PMD로 코드 품질 검사 예시

간단한 예제를 통해 PMD의 코드 품질 검사 기능을 확인해보겠습니다.

public class SampleClass {
    public void sampleMethod() {
        int i = 0;
        while (true) { // PMD가 무한 루프 가능성 경고 발생
            i++;
        }
    }
}

위 코드에서 PMD는 while (true)로 인해 무한 루프 가능성 경고를 발생시킵니다. 이외에도 메서드가 너무 길거나 복잡도가 높은 경우, 중복 코드가 있는 경우 등 다양한 상황에서 경고를 줄 수 있습니다.

7. PMD 결과 개선하기

PMD 검사 결과는 코드의 품질을 향상시키는 가이드라인 역할을 합니다. 무한 루프 방지, 복잡성 줄이기, 중복 코드 제거 등 PMD가 제시한 문제를 해결하며 코드의 유지 보수성을 크게 높일 수 있습니다.

요약
PMD는 정적 코드 분석 도구로 Java 코드 품질 개선에 유용하다.
Gradle과 Maven으로 손쉽게 설정 가능하다.
Custom Rules로 프로젝트에 맞는 규칙을 적용할 수 있다.

PMD는 소스 품질을 높이는 데 큰 역할을 하므로, 프로젝트 초기부터 도입하는 것을 추천드립니다! Programming Mistake Detector

[Docker] Docker란 무엇인가?

TaeHuiLee — Sun, 10 Nov 2024 22:27:36 +0900

1. Docker란 무엇인가요?

Docker는 애플리케이션을 컨테이너라는 독립된 환경에 격리시켜 실행할 수 있게 도와주는 오픈 소스 플랫폼입니다. 애플리케이션과 그에 필요한 모든 라이브러리, 종속성 등을 하나의 패키지로 묶어 일관된 실행 환경을 제공하죠. Docker는 애플리케이션을 서로 격리된 상태로 실행하며, 애플리케이션이 여러 환경에서 동일하게 작동하도록 합니다.

2. Docker의 탄생 배경

Docker의 탄생 배경은 복잡한 개발 환경의 일관성 유지라는 문제에서 시작되었습니다.

"개발 환경과 배포 환경이 다르면 발생하는 문제를 해결하고자 Docker가 탄생했습니다."

과거에는 애플리케이션 개발 및 테스트 시, 운영 환경과의 차이로 인해 문제가 발생하곤 했습니다. 개발자는 자신이 만든 애플리케이션이 운영 환경에서도 동일하게 동작하길 원했지만, 라이브러리 버전이나 OS 버전 등의 차이로 인해 예기치 못한 오류가 발생했습니다. Docker는 이를 해결하고자 애플리케이션을 독립된 컨테이너로 관리하는 개념을 도입하게 됩니다.

Docker가 만들어낸 변화는 코드의 "한 번 작성, 어디서나 실행"이라는 아이디어를 현실화하는 것이었습니다.

⚙️ 3. Docker의 특장점

Docker는 다양한 기능을 통해 개발자와 운영 팀에게 많은 이점을 제공합니다. 주요 특장점은 다음과 같습니다:

️ 3.1 환경의 일관성 유지

Docker 컨테이너는 어디서든 동일한 환경을 제공합니다. 개발자가 자신의 로컬 환경에서 테스트한 애플리케이션을 그대로 운영 환경에 배포할 수 있어 환경 차이로 인한 문제를 방지합니다.

3.2 빠른 배포 및 확장성

Docker는 이미지를 생성해 다양한 환경에 빠르게 배포할 수 있도록 도와줍니다. 또한 컨테이너를 쉽게 확장할 수 있어 높은 확장성을 제공합니다.

3.3 경량화된 가상화

컨테이너는 가상 머신(VM)과는 다르게 OS 커널을 공유하여 더 적은 리소스를 사용합니다. 가볍고 빠르게 실행할 수 있다는 장점이 있죠.

3.4 효율적인 리소스 관리

Docker는 각 컨테이너가 호스트 시스템의 자원을 효율적으로 사용할 수 있도록 관리합니다. 이를 통해 서버 리소스를 절약하고, 컨테이너를 더 많이 운영할 수 있게 됩니다.

4. Docker의 동작 원리

Docker의 핵심 개념은 이미지와 컨테이너입니다.

4.1 이미지(Image)

이미지는 Docker 컨테이너의 템플릿이라고 생각할 수 있습니다. 애플리케이션 실행에 필요한 모든 파일, 환경 설정이 포함되어 있죠. 이미지를 통해 동일한 환경을 만들어낼 수 있으며, 여러 곳에서 동일한 컨테이너를 만들 수 있습니다.

4.2 컨테이너(Container)

이미지를 실행하면 컨테이너가 생성됩니다. 컨테이너는 애플리케이션과 그에 필요한 모든 것을 격리된 공간에서 실행할 수 있게 해주는 역할을 합니다. 이미지에서 생성된 실행 가능한 인스턴스가 바로 컨테이너인 것이죠.

Docker의 동작 원리는 간단히 말해 이미지를 기반으로 컨테이너를 만들어 애플리케이션을 실행하는 것입니다. Docker는 컨테이너에 대한 격리된 네임스페이스를 생성하고, 필요한 자원을 할당하여 애플리케이션이 독립적으로 실행될 수 있도록 도와줍니다.

5. 자주 쓰는 Docker 명령어 예시

Docker를 효율적으로 사용하려면 자주 사용되는 명령어를 잘 알아두어야 합니다. 주요 명령어를 살펴보겠습니다.

️ 5.1 이미지 관련 명령어

docker pull [이미지 이름]
Docker Hub에서 특정 이미지를 다운로드합니다.
docker build -t [이미지 이름] .
Dockerfile을 이용해 이미지를 빌드합니다. -t 옵션을 통해 이미지에 이름을 지정할 수 있습니다.
docker images
로컬에 저장된 Docker 이미지 목록을 확인합니다.

5.2 컨테이너 관련 명령어

docker run [옵션] [이미지 이름]
이미지를 기반으로 컨테이너를 실행합니다. -d 옵션으로 백그라운드 실행, -p 옵션으로 포트를 매핑할 수 있습니다.
docker ps
현재 실행 중인 컨테이너 목록을 보여줍니다.
docker stop [컨테이너 ID]
특정 컨테이너를 중지합니다.
docker rm [컨테이너 ID]
중지된 컨테이너를 삭제합니다.

️ 5.3 네트워크와 볼륨 관련 명령어

docker network ls
Docker 네트워크 목록을 확인합니다.
docker volume create [볼륨 이름]
데이터 볼륨을 생성합니다.
docker volume ls
생성된 볼륨 목록을 확인합니다.

6. 마무리 정리

Docker는 애플리케이션을 실행하는 독립된 환경을 제공하여 개발 환경과 배포 환경 간의 일관성을 보장해 주는 컨테이너 기술입니다. Docker를 사용하면 애플리케이션이 어디서나 동일하게 실행될 수 있으며, 배포가 간편하고 확장성이 뛰어납니다. 이미지와 컨테이너를 활용한 Docker의 원리를 이해하면 애플리케이션의 일관성을 유지하고 효율적으로 운영할 수 있답니다.

주요 Docker 명령어: docker pull, docker build, docker run, docker ps, docker stop 등이 있으며, 각각 이미지를 다루고 컨테이너를 실행하거나 관리할 때 사용됩니다.

이제 Docker의 개념과 특장점, 주요 명령어까지 알아봤습니다. Docker로 애플리케이션을 쉽게 관리해보세요!

[Jenkins] Jenkins에서 GitHub 및 GitLab 인증 연동하기

TaeHuiLee — Sat, 9 Nov 2024 09:42:01 +0900

1. Jenkins에서 GitHub 및 GitLab 인증 연동하기

Jenkins를 사용해 GitHub이나 GitLab의 리포지토리와 통합하고 파이프라인을 자동화하려면 인증 설정이 필요합니다. 이번 글에서는 GitHub과 GitLab에 대한 인증 방법과 Jenkins 파이프라인 설정까지 설명하겠습니다.

2. GitHub 및 GitLab 인증 방식

GitHub과 GitLab에 접근하기 위해서는 Jenkins에서 OAuth 토큰이나 SSH 키를 통해 인증할 수 있습니다. 두 가지 방식 모두 보안성이 뛰어나며, 각 상황에 맞는 방식을 선택할 수 있습니다.

OAuth 토큰 방식: GitHub 또는 GitLab에서 생성한 개인 액세스 토큰을 사용합니다.
SSH 키 방식: Jenkins 서버와 리포지토리 간에 SSH 키를 사용해 인증합니다.

3. GitHub 연동하기

3.1 GitHub Access Token 발급

GitHub에 로그인 후, Settings > Developer settings > Personal access tokens로 이동합니다.
Generate new token을 클릭하고, 필요한 권한을 선택해 토큰을 생성합니다. (보통 repo, admin:repo_hook 권한 필요)
생성된 토큰을 복사해 두세요. 이 토큰은 한 번만 표시되므로 잃어버리면 재생성이 필요합니다.

3.2 Jenkins에 GitHub Access Token 등록

Jenkins 대시보드에서 Manage Jenkins > Manage Credentials로 이동합니다.
Global credentials에서 Add Credentials를 클릭합니다.
Kind는 Secret text로 설정하고, Secret에 아까 복사한 GitHub Access Token을 입력합니다.
ID와 Description을 지정해 나중에 구분하기 쉽게 설정합니다.

4. GitLab 연동하기

4.1 GitLab Access Token 발급

GitLab에서 로그인 후 Settings > Access Tokens로 이동합니다.
토큰 이름을 작성하고, 필요한 Scope를 선택합니다 (api, read_repository, write_repository 등).
생성된 토큰을 복사해 둡니다.

4.2 Jenkins에 GitLab Access Token 등록

Jenkins의 Manage Jenkins > Manage Credentials로 이동합니다.
Global credentials에서 Add Credentials를 선택합니다.
Kind를 Secret text로 설정하고, Secret에 GitLab Access Token을 입력합니다.
ID와 Description을 입력하여 나중에 관리하기 쉽게 합니다.

5. Jenkins 파이프라인 작성 예시

GitHub 또는 GitLab의 저장소를 빌드하고 배포하는 Jenkins 파이프라인을 작성해보겠습니다.

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                // GitHub 또는 GitLab 리포지토리에서 코드 체크아웃
                git branch: 'main', 
                    url: 'https://github.com/username/repository.git', 
                    credentialsId: 'GitHub-Token-ID'
            }
        }
        stage('Build') {
            steps {
                echo 'Building...'
                // 빌드 명령어 (예: Gradle, Maven 등)
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying...'
                // 배포 명령어 (예: Kubernetes, Docker 등)
            }
        }
    }
}

위의 credentialsId 값은 Jenkins의 Credentials에 등록한 ID를 입력하면 됩니다. branch와 url은 본인의 리포지토리에 맞게 수정해주세요.

6. 마무리

Jenkins에서 GitHub 및 GitLab 리포지토리를 연동하고 파이프라인을 설정하는 방법을 알아봤습니다. 인증 방식으로 OAuth 토큰과 SSH 키가 있으며, 각 저장소의 토큰을 Jenkins의 Credentials로 추가하고 파이프라인에서 credentialsId를 사용해 참조하는 구조입니다.

위의 방법을 통해 간단히 GitHub 및 GitLab 연동을 자동화할 수 있으며, 파이프라인에서 빌드와 배포 프로세스를 정의할 수 있습니다.

[Jenkins] CI/CD 환경 구축하기

TaeHuiLee — Fri, 8 Nov 2024 16:16:01 +0900

Jenkins로 CI/CD 환경 구축하기 - 기본 플러그인 소개부터 설치까지!

개발이나 DevOps를 처음 시작한 분이라면 지속적 통합과 지속적 배포(Continuous Integration/Continuous Deployment, CI/CD) 자동화 도구로 Jenkins를 한 번쯤 들어봤을 겁니다. Jenkins는 오픈 소스 기반의 자동화 서버로, 다양한 빌드와 배포 작업을 자동화할 수 있게 도와줍니다. 그럼 Jenkins의 기본 개념과 함께, CI/CD 작업을 자동화하는 데 필수적인 플러그인 설치 방법과 그 사용법에 대해 자세히 알아보겠습니다.

1. Jenkins란?

Jenkins는 주로 소프트웨어 프로젝트의 자동화된 빌드, 테스트, 배포 파이프라인을 관리하기 위해 개발된 오픈 소스 도구입니다. 개발 과정에서 반복되는 많은 작업을 자동화하여 생산성을 높이고, 팀이 더 빠르게 소프트웨어를 배포할 수 있게 해줍니다.

Jenkins의 주요 기능은 다양한 형태의 빌드, 테스트, 배포 작업을 조합해 하나의 파이프라인으로 묶는 것입니다. 이를 통해 코드 변경 사항이 배포까지 이어지는 과정을 자동화할 수 있습니다.
플러그인을 통해 기능을 무한히 확장할 수 있어, 거의 모든 빌드 도구 및 소스 코드 관리 도구(SCM)와 통합할 수 있습니다.

Jenkins의 탄생 배경

Jenkins는 2004년에 Hudson이라는 이름으로 시작되었습니다. 오라클이 Hudson 프로젝트를 인수하면서 라이센스 문제로 분리된 것이 바로 Jenkins입니다. 이후 Jenkins는 독립적인 오픈 소스 프로젝트로 빠르게 발전했고, 현재는 DevOps와 CI/CD의 표준 도구 중 하나로 자리 잡았습니다.

️ 2. Jenkins 설치하기

기본 시스템 요구사항:
- Java 설치 필수 (주로 JDK 11 이상 권장)
- 최소 메모리 256MB (권장 1GB 이상)
설치 과정
1. Java 설치 후 환경 변수 설정을 완료합니다.
2. Jenkins 공식 사이트에서 설치 파일을 다운로드합니다.
3. 다운로드한 파일을 실행하여 설치합니다.
4. 설치 후 브라우저에서 http://localhost:8080으로 접속하여 관리자 암호를 입력해 초기 설정을 마칩니다.

3. Jenkins에서 유용한 기본 플러그인들

Jenkins는 다양한 작업을 자동화하고, 다양한 도구와 통합할 수 있도록 플러그인 기반으로 동작합니다. 여기서 Jenkins의 주요 기능과 통합을 위한 필수 플러그인들을 살펴볼게요.

✅ 3.1 기본 플러그인 목록 및 기능 설명

Folders: 프로젝트를 폴더로 분류하여 관리할 수 있도록 해주는 플러그인으로, 여러 프로젝트를 관리할 때 유용합니다.
OWASP Markup Formatter: OWASP 표준을 기반으로 안전한 마크업을 지원하여 보안을 강화합니다.
Build Timeout: 빌드 시간이 너무 오래 걸리면 자동으로 중단해 주어, 자원을 낭비하지 않도록 해줍니다.
Credentials Binding: 암호나 API 토큰 같은 자격 증명을 안전하게 관리할 수 있습니다.
Timestamper: 빌드 로그에 타임스탬프를 추가해 로그 분석을 용이하게 합니다.
Workspace Cleanup: 빌드 전후에 워크스페이스를 정리하여 불필요한 파일을 제거하고 깨끗한 환경에서 빌드를 진행합니다.
Ant: Apache Ant 빌드 도구를 지원하는 플러그인입니다.
Gradle: Gradle 빌드 도구를 지원하여 더욱 다양한 빌드 옵션을 제공합니다.
Pipeline: Jenkins 파이프라인 스크립트를 통해 빌드 및 배포를 자동화하는 필수 플러그인입니다.
GitHub Branch Source: GitHub의 특정 브랜치를 빌드 소스로 설정하여, 브랜치마다 빌드를 자동화할 수 있습니다.
Pipeline: GitHub Groovy Libraries: 파이프라인에서 GitHub의 Groovy 라이브러리를 사용할 수 있어 다양한 스크립트를 손쉽게 사용할 수 있습니다.
Pipeline Graph View: 파이프라인 빌드를 그래프로 시각화해 보여줍니다.
Git: Git을 통한 소스 코드 관리를 위한 필수 플러그인입니다.
SSH Build Agents: SSH를 사용하여 원격 빌드 에이전트와 통신할 수 있습니다.
Matrix Authorization Strategy: 권한을 매트릭스 형식으로 설정할 수 있어 사용자 권한 관리를 체계적으로 할 수 있습니다.
PAM Authentication: PAM을 사용해 시스템 계정 인증을 Jenkins에서 활용할 수 있습니다.
LDAP: LDAP를 통한 사용자 인증을 지원하여 중앙집중적인 사용자 관리를 할 수 있습니다.
Email Extension & Mailer: 빌드 성공, 실패 등에 따라 이메일로 알림을 받을 수 있습니다.
Dark Theme: Jenkins 인터페이스에 다크 테마를 적용하여 눈의 피로를 줄일 수 있어요.
Slack Notification: Slack에 빌드 결과를 알림으로 보낼 수 있는 플러그인입니다.

4. 플러그인 설치 및 적용 방법

플러그인 파일 복사: 해당 플러그인을 /plugins 디렉토리에서 다운로드한 후, Jenkins의 플러그인 디렉토리 /var/jenkins_home/plugins에 복사합니다.
Jenkins 재기동: 플러그인을 적용하려면 Jenkins를 재시작해야 합니다. 명령어를 사용해 간단히 재기동할 수 있습니다.

명령어 예시:

sudo systemctl restart jenkins

플러그인 적용 확인: 재기동 후, Jenkins 관리 화면에서 플러그인 설치 여부를 확인하고, 설정에 반영되었는지 확인합니다.

5. Jenkins의 SCM(소스 코드 관리)와의 통합

Jenkins는 Git, GitHub, GitLab 등 다양한 소스 코드 관리(SCM) 도구와 통합할 수 있습니다. 특히 GitHub Branch Source와 Git 플러그인은 소스 코드 변경 사항에 따라 자동으로 빌드 및 배포 파이프라인을 시작하는 데 유용합니다.

GitHub 연동 예시

Jenkins에서 GitHub와 연동하는 과정은 다음과 같습니다.

Jenkins에 GitHub 플러그인 설치: GitHub Branch Source와 Git 플러그인을 설치합니다.
GitHub 웹훅(Webhook) 설정: GitHub 리포지토리 설정에서 웹훅을 추가하여 코드 변경 시 Jenkins에서 빌드가 자동으로 트리거되도록 합니다.
Credential 설정: GitHub에 인증할 자격 증명(Credential)을 Jenkins에 등록합니다.
Pipeline 스크립트 작성: Jenkinsfile을 작성하여 빌드와 배포 과정을 설정합니다.

Jenkinsfile 예시:

pipeline {
   agent any
   stages {
       stage('Build') {
           steps {
               echo 'Building...'
           }
       }
       stage('Test') {
           steps {
               echo 'Testing...'
           }
       }
       stage('Deploy') {
           steps {
               echo 'Deploying...'
           }
       }
   }
}

구현 및 플러그인 참조 링크

구현 참조: https://github.com/taehui8260/web-auto-deploy

Plugin 참조: https://github.com/taehui8260/jenkins-plugins

요약

Jenkins는 다양한 빌드와 배포 작업을 자동화하여 DevOps 프로세스를 간소화하는 강력한 도구입니다. 플러그인을 통해 기능을 확장할 수 있어 다양한 빌드 도구와 소스 코드 관리 시스템과 손쉽게 통합할 수 있습니다. 기본 플러그인 설치를 통해 Jenkins 환경을 안정적이고 효율적으로 구축하고, 자동화 파이프라인 설정을 통한 완벽한 CI/CD 환경을 만들어 보세요!

위의 과정들을 따라가면서 자신만의 Jenkins 환경을 구축해보세요.

웹 접근성(Web Accessibility)이란

TaeHuiLee — Thu, 7 Nov 2024 14:21:23 +0900

️ 1. 웹 접근성(Web Accessibility)이란?

웹 접근성(Web Accessibility)은 장애 유무와 관계없이 모든 사용자가 웹 사이트나 애플리케이션에 접근하고 사용할 수 있도록 만드는 개념입니다. 웹 접근성은 시각, 청각, 인지 및 운동 장애를 가진 사용자를 포함해 나이와 언어에 관계없이 모든 사용자에게 공평한 웹 환경을 제공하는 것이 목표입니다. 웹 접근성은 특히 사회적 약자를 배려하는 측면에서 매우 중요하지만, 궁극적으로는 모든 사용자가 더 쉽게, 빠르게 정보를 얻을 수 있도록 도와주는 역할을 하기도 합니다.

웹 접근성이 중요한 이유

포괄적인 사용자 경험을 제공하여 장애 유무에 관계없이 서비스를 사용할 수 있습니다.
법적 요구 사항을 충족할 수 있어, 많은 국가에서는 웹 접근성을 준수하도록 법적으로 요구하고 있습니다.
SEO에 유리한 측면도 있습니다. 접근성을 높인 웹사이트는 구조적으로도 깔끔해지기 때문에 검색 엔진 최적화에 긍정적 영향을 미칩니다.

️ 2. 웹 접근성 표준과 원칙

웹 접근성의 국제 표준으로 가장 많이 참고되는 것이 W3C에서 정의한 WCAG(Web Content Accessibility Guidelines)입니다. WCAG는 다양한 접근성 지침을 제시하며, 주요 목표를 4가지 원칙으로 정리하였습니다.

인식 가능성(Perceivable): 모든 사용자에게 콘텐츠가 잘 보이거나 들려야 해요. 텍스트 대체 텍스트, 자막 제공 등이 해당.
운용 가능성(Operable): 사용자가 다양한 방법(키보드, 음성 등)으로 인터페이스를 조작.
이해 가능성(Understandable): 정보와 사용자 인터페이스가 이해하기 쉬워야함.
견고성(Robust): 콘텐츠가 다양한 환경(브라우저, 스크린 리더 등)에서도 문제없이 작동해야함.

3. 웹 접근성 구현 요소

대체 텍스트(alt text) 제공

이미지 요소에 alt 속성을 사용하여 시각 장애가 있는 사용자가 이미지의 의미를 알 수 있도록 설명을 제공합니다.

<img src="image.jpg" alt="강아지가 공원에서 뛰어노는 모습">

색 대비 조정

텍스트와 배경 간의 색 대비를 충분히 높여 시각 장애나 색각 이상을 가진 사용자도 내용을 쉽게 인식할 수 있게 합니다. WCAG는 텍스트 대비를 4.5:1 이상으로 권장합니다.

키보드 접근성

모든 기능을 키보드로 조작 가능하게 만들면, 마우스를 사용하기 어려운 사용자도 콘텐츠를 사용할 수 있습니다. 일반적으로 Tab 키로 이동하고 Enter나 Space 키로 선택할 수 있게 합니다.

ARIA(Accessible Rich Internet Applications) 속성 사용

ARIA 속성은 HTML에 추가하여 스크린 리더가 보다 정확하게 내용을 전달할 수 있도록 합니다. 예를 들어, 동적 콘텐츠가 많은 웹사이트에서 role이나 aria-label 같은 속성을 사용하여 콘텐츠의 의미와 상태를 전달합니다.

<button aria-label="메뉴 열기"> </button>

4. 웹 접근성 테스트 방법

웹 접근성 테스트는 다양한 도구와 기술을 활용해 수동 및 자동으로 진행할 수 있습니다. 다음은 몇 가지 주요한 테스트 방법입니다.

✅ 수동 테스트

키보드 탐색: 키보드만으로 모든 콘텐츠에 접근할 수 있는지 확인합니다. Tab, Enter, Space 키를 사용해 콘텐츠를 이동하고 조작해볼 수 있습니다.
스크린 리더 테스트: 스크린 리더(예: NVDA, VoiceOver)를 사용해 텍스트 대체 텍스트, 링크 설명, ARIA 속성 등이 올바르게 읽히는지 테스트합니다.
색상 대비 확인: WCAG 기준 대비율(4.5:1)을 참고해 텍스트와 배경 색상을 검토합니다. Chrome의 DevTools 또는 접근성 검사 도구에서 확인할 수 있습니다.

⚙️ 자동화 도구 테스트

WAVE: WAVE(Web Accessibility Evaluation Tool)는 웹 페이지의 접근성을 검사하고 문제를 시각적으로 표시해주는 도구입니다.
Lighthouse: Google Chrome의 Lighthouse는 페이지 성능 및 접근성 테스트를 할 수 있습니다. DevTools에서 접근성 탭을 열어 Lighthouse의 접근성 보고서를 확인해볼 수 있습니다.
axe: axe는 Chrome과 Firefox에서 사용할 수 있는 접근성 확장 프로그램으로, 다양한 접근성 문제를 자동으로 검사합니다.

5. 웹 접근성 개선을 위한 팁

필수 태그(label, fieldset, legend 등)를 올바르게 사용.
탭 순서(Tab Order)를 논리적으로 배치해 사용자 경험을 개선.
에러 메시지를 명확히 제공하고, 에러 발생 시 어떻게 해결할 수 있는지 안내.
언어 속성을 설정해 스크린 리더가 적절한 언어로 콘텐츠를 읽을 수 있게 제공.

요약

웹 접근성은 모든 사용자, 특히 장애가 있는 사용자에게도 공평한 웹 경험을 제공하기 위한 노력입니다. WCAG의 4대 원칙에 따라 다양한 요소를 구현하고, 수동 및 자동화 도구로 테스트해 접근성을 높일 수 있습니다. 특히 텍스트 대체, 색 대비, 키보드 조작 등을 신경 써야 하며, 접근성 검사 도구를 통해 문제를 발견하고 개선해 나가면 됩니다.

WSL(Windows Subsystem for Linux) 설치 및 설정

TaeHuiLee — Tue, 29 Oct 2024 08:00:20 +0900

1. WSL(Windows Subsystem for Linux) 설치 및 설정: 우분투 기반 사용하기

WSL은 윈도우에서 리눅스 환경을 간편하게 사용할 수 있도록 해줍니다. 여기서는 Ubuntu 배포판을 설치하는 과정과 고정 IP 설정 및 Windows-Windows Subsystem 간 통신 방법을 다뤄보겠습니다.

1-1. WSL 설치 및 Ubuntu 세팅하기

1️⃣ WSL 설치 활성화

먼저 WSL을 설치하고 활성화합니다. 아래 명령어를 Windows PowerShell(관리자 권한) 에서 실행

wsl --install

이 명령은 최신 WSL과 함께 기본으로 Ubuntu 배포판까지 설치합니다. 만약 직접 선택하고 싶다면, 아래처럼 특정 버전을 선택

wsl --install -d Ubuntu-20.04

Tip: 설치 후 wsl --set-default-version 2 명령을 실행해 WSL 2로 기본 설정하면 더 빠른 파일 시스템과 네트워크 속도를 얻을 수 있다.

2️⃣ WSL 1과 WSL 2 전환 방법

WSL 1과 WSL 2의 차이

항목	WSL 1	WSL 2
커널	리눅스 호환 계층	진짜 리눅스 커널 사용
성능	파일 시스템 작업에 빠름	전체 성능 개선, I/O 작업 최적화
네트워크	Windows와 IP 공유	별도 가상 네트워크 IP 사용
Docker 지원	제한적 지원	완벽한 Docker 지원
가상화 필요	필요 없음	Hyper-V 가상화 필요

WSL 2를 기본 버전으로 설정

wsl --set-default-version 2

특정 배포판(예: Ubuntu)의 WSL 버전을 1에서 2로 전환

wsl --set-version [Ubuntu] 2

이 명령어로 WSL에 설치된 배포나 목록을 보고 실행하면 됩니다.

wsl --list --verbose

wsl -d [name]

1-2. WSL로 우분투 실행 및 초기 설정

설치가 완료되면 Ubuntu 앱을 실행합니다. 처음 실행 시 사용자 이름과 비밀번호 설정이 필요합니다. 이 설정이 완료되면, 아래 명령어를 입력해 패키지를 최신 상태로 유지

sudo apt update && sudo apt upgrade -y

2. WSL에서 고정 IP 설정 및 접근 방법

기본적으로 WSL의 IP 주소는 매번 재시작될 때마다 바뀝니다.. 고정 IP로 접근하려면 몇 가지 설정이 필요합니다.

2-1. WSL 고정 IP 설정하기

고정 IP를 설정하려면 WSL 네트워크 인터페이스를 조정하고, NAT(네트워크 주소 변환)를 설정해야합니다.

0. net-tools 패키지 설치

sudo apt update
sudo apt install net-tools

1. 먼저, WSL2의 기본 네트워크 인터페이스를 확인합니다.

ifconfig

인터페이스 이름은 일반적으로 eth0입니다.

2. 이제 WSL 시작 시 고정 IP를 할당하도록 설정합니다. 아래 경로에 스크립트 파일을 만들어 고정 IP를 부여할 수 있습니다.

/etc/init.d/fix_ip.sh 파일 생성하기

아래 명령어로 고정 IP 설정 스크립트를 만듭니다.

sudo nano /etc/init.d/fix_ip.sh

스크립트 내용:

#!/bin/bash
ip addr add 192.168.50.2/24 dev eth0

스크립트를 저장한 후 실행 권한을 부여합니다.

sudo chmod +x /etc/init.d/fix_ip.sh

3. WSL 시작 시 이 스크립트가 실행되도록 설정합니다.

nano ~/.bashrc

bashrc 파일의 맨 끝에 다음 줄을 추가합니다.

sudo /etc/init.d/fix_ip.sh

위 명령어는 sudo 권한이 필요하기 때문에, sudo 비밀번호 입력을 요구하지 않도록 visudo를 사용하여 다음 줄을 추가합니다.

sudo visudo

파일에 다음 줄을 추가합니다.

<사용자 이름> ALL=(ALL) NOPASSWD: /etc/init.d/fix_ip.sh

4. 재접속 후 IP를 확인해보면 추가된걸 확인할 수 있습니다.

ip add show

2-2. 윈도우에서 WSL에 접근하기 (고정 IP 사용)

1. WSL 내부에서 서버를 실행한 후 고정 IP로 접근할 수 있습니다. 예를 들어, WSL에서 간단한 웹 서버를 실행해봅시다.

sudo python3 -m http.server 80

2.Windows에서 브라우저를 열고 다음 주소로 접근합니다.

URL: http://127.0.0.1

위에서 설정한 고정 IP는(192.168.50.2) WSL의 네트워크 인터페이스가 가상 네트워크에 연결되어 있기 때문에 외부 접근이 차단되어 있습니다. 따라서 192.168.50.2로 접근을 원한다면 별도의 포트포워딩이 필요합니다.
본 게시물에서는 필요성을 못느껴 따로 설명하지 않도록 하겠습니다.

만약 접근이 되지 않으면 WSL의 방화벽 설정을 확인하거나 Windows Defender Firewall에서 해당 IP와 포트를 허용해야 합니다.

3. WSL에서 Windows로의 IP 접근 설정하기

3-1. WSL에서 Windows의 IP 접근

WSL에서 윈도우로 IP로 접근하려면 Windows의 IP 주소를 알아야 합니다. PowerShell에서 다음 명령어로 윈도우의 IP를 확인할 수 있습니다:

ipconfig

출력된 정보 중 IPv4 주소를 확인합니다. 예를 들어 192.168.0.1이라면, WSL에서 다음과 같이 핑 테스트를 해봅니다.

ping 192.168.0.1

만약 핑이 정상 작동하지 않는다면, 윈도우 방화벽에서 WSL의 접근을 허용해야 합니다.

3-2. Windows의 서버에 접근하기 (예: 웹 서버)

윈도우에서 로컬 서버를 열었다면, WSL에서도 해당 서버에 접근이 가능합니다. 예를 들어 윈도우에서 Python HTTP 서버를 열어봅시다.

Windows 명령 프롬프트:

python -m http.server 8080

이제 WSL에서 해당 서버에 접속합니다.

curl http://192.168.0.1:8080

4. 윈도우에서 WSL로의 IP 접근 허용하기

4-1. 윈도우에서 WSL 접근을 위한 방화벽 설정

만약 WSL의 서버에 접근이 불가능하다면, 윈도우 방화벽이 문제일 수 있습니다. 다음과 같이 설정합니다.

1. Windows Defender 방화벽을 엽니다.

2. 고급 설정 > 인바운드 규칙에서 새 규칙을 만듭니다.

3. 포트 선택 후, 특정 포트(예: 80 또는 8080)를 입력합니다.

4. 연결을 허용으로 선택하고, 규칙에 이름을 지정합니다.

이제 Windows에서 WSL 서버로 접근이 가능합니다.

5. 정리

WSL 설치: wsl --install로 간편하게 설치하고 Ubuntu 환경 세팅.
고정 IP 설정: WSL에서 고정 IP 할당 스크립트 작성.
Windows에서 WSL로 접근: WSL 내부 서버를 고정 IP로 운영하고, 브라우저에서 접근.
WSL에서 Windows로 접근: ipconfig로 윈도우 IP 확인 후 WSL에서 핑 테스트.
방화벽 설정: 필요한 포트를 방화벽에서 허용해 원활한 통신 보장.

[Git] 한 컴퓨터에서 두 개의 Git 계정 사용하는 방법

TaeHuiLee — Fri, 18 Oct 2024 08:00:03 +0900

한 컴퓨터에서 두 개의 Git 계정 사용하는 방법

Git을 사용하는 개발자라면, 때로는 회사용 계정과 개인용 계정을 동시에 관리해야 할 때가 있습니다. SSH 키와 Git 설정을 활용하여 두 계정을 효율적으로 관리할 수 있는 방법을 단계별로 알아보겠습니다.

1. 문제 상황

회사와 개인 프로젝트를 모두 관리하려면, 두 개의 Git 계정을 한 컴퓨터에서 사용하는 방법이 필요합니다. 기본적으로 Git은 하나의 계정을 설정하도록 되어 있지만, 다양한 프로젝트에서 여러 계정을 사용해야 할 경우 문제가 발생할 수 있습니다. 이를 해결하기 위한 방법이 바로 SSH 키를 사용한 계정 분리입니다.

2. 해결 방법

이제 두 계정을 동시에 사용할 수 있도록 설정하는 방법을 알아보겠습니다. 다음 단계로 SSH 키 생성, SSH 키 등록, Git 설정을 통해 두 계정을 깔끔하게 관리할 수 있습니다.

️ 2-1. SSH 키 생성

각 Git 계정에 대해 별도의 SSH 키를 생성합니다.

# user01 계정용 SSH 키 생성
ssh-keygen -t rsa -C "user01@example.com" -f ~/.ssh/id_rsa_user01

# user02 계정용 SSH 키 생성
ssh-keygen -t rsa -C "user02@example.com" -f ~/.ssh/id_rsa_user02

2-2. SSH 키를 GitHub에 등록

GitHub에 SSH 키를 등록해야 원격 리포지토리에 접근할 수 있습니다.

SSH 공개 키를 확인하고 복사합니다.

cat ~/.ssh/id_rsa_user01.pub

GitHub에 로그인하고 SSH and GPG keys 설정 페이지로 이동합니다.
New SSH key를 클릭하고, 위에서 복사한 공개 키를 붙여넣습니다.
동일한 방식으로 user02 계정용 공개 키도 등록합니다.

⚙️ 2-3. SSH config 설정

SSH 키를 만들었다면, ~/.ssh/config 파일에 두 계정을 구분하는 설정을 추가합니다.

# user01 계정 설정
Host github-user01
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_user01

# user02 계정 설정
Host github-user02
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_user02

2-4. SSH 에이전트에 SSH 키 추가

SSH 에이전트에 키를 추가하여 두 계정을 활성화합니다.

# SSH 에이전트 시작
eval "$(ssh-agent -s)"

# user01 계정용 SSH 키 추가
ssh-add ~/.ssh/id_rsa_user01

# user02 계정용 SSH 키 추가
ssh-add ~/.ssh/id_rsa_user02

3. 리포지토리 클론 및 푸시

두 계정 설정이 끝났다면, 이제 리포지토리를 각 계정에 맞게 클론하고, 그 계정으로 푸시하는 방법을 알아봅니다.

3-1. 클론 받을 때

각 계정에 맞는 SSH 별칭을 사용하여 리포지토리를 클론합니다.

user01 계정으로 클론 받기:

git clone git@github-user01:username/repository.git

user02 계정으로 클론 받기:

git clone git@github-user02:username/repository.git

3-2. 푸시할 때

클론받은 리포지토리에서 작업 후 git push 명령어를 사용하면, 클론할 때 설정한 계정으로 푸시가 이루어집니다. 예를 들어, user01 계정으로 클론받았다면 푸시도 user01 계정으로 진행됩니다.

푸시 계정을 변경하고 싶다면:

만약 다른 계정으로 푸시하고 싶다면, 원격 URL을 변경하거나 사용자 정보를 설정할 수 있습니다.

원격 URL 변경:

git remote set-url origin git@github-user02:username/repository.git

Git 사용자 정보 설정:

git config user.name "user02"
git config user.email "user02@example.com"

4. 결론

이제 한 컴퓨터에서 두 개의 Git 계정을 사용하는 방법을 마스터했습니다. SSH 키와 SSH config 파일을 통해 계정을 깔끔하게 분리하고, 필요에 따라 계정을 전환하며 효율적으로 프로젝트를 관리할 수 있습니다.

[JAVA] Spring 돌아보기 Part.3 #JDBC #MyBatis #Multiple DataSources

TaeHuiLee — Thu, 10 Oct 2024 08:00:25 +0900

Spring Data Access (JDBC, Transaction)

Spring 프레임워크를 사용하여 애플리케이션을 개발할 때, 데이터베이스와의 연동은 필수적인 부분입니다. 이번 글에서는 Spring의 JDBC를 사용한 데이터 접근과 함께 MyBatis 통합, 트랜잭션 관리 방법, 그리고 데이터베이스 연동 설정을 해보겠습니다.

1. Spring JDBC Template

✔️ Spring JDBC Template란?

Spring JDBC Template은 JDBC(Java Database Connectivity) 사용 시 발생하는 보일러플레이트 코드를 대폭 줄여주기 위해 설계된 유틸리티 클래스입니다. JDBC를 사용할 때 반복적으로 사용되는 코드, 예를 들면 데이터베이스 커넥션을 열고 닫는 것, PreparedStatement와 같은 SQL 구문을 작성하는 것, 예외 처리 등을 자동으로 처리해주어 더 적은 코드로 깔끔하게 데이터베이스 작업을 수행할 수 있게 해줍니다.

JDBC Template 사용 방법

Spring에서 JdbcTemplate을 사용하는 과정은 매우 간단합니다. 기본적으로 다음과 같은 단계를 따릅니다:

DataSource 설정을 통해 데이터베이스 커넥션을 구성
JdbcTemplate 객체를 생성하여 데이터베이스와 상호작용

예시 코드

@Bean
public JdbcTemplate jdbcTemplate(DataSource dataSource) {
    return new JdbcTemplate(dataSource);
}

위 코드에서 보듯, DataSource를 통해 데이터베이스 커넥션을 설정하고, 이를 JdbcTemplate에 전달하여 사용할 수 있습니다.

주요 메서드

queryForObject: 단일 결과를 반환할 때 사용
query: 여러 행을 반환할 때 사용
update: 삽입, 수정, 삭제를 수행할 때 사용

예시로, queryForObject를 이용해 단일 결과를 조회하는 코드를 보겠습니다.

String sql = "SELECT name FROM users WHERE id = ?";
String name = jdbcTemplate.queryForObject(sql, new Object[]{id}, String.class);

2. MyBatis와의 통합 및 XML Mapper 사용

✔️ MyBatis 소개

MyBatis는 SQL을 XML 파일에 정의하고, 자바 객체와 SQL 간의 매핑을 쉽게 해주는 프레임워크입니다. Spring에서 MyBatis를 사용하는 이유는 복잡한 SQL 쿼리와 객체 간의 매핑 작업을 더욱 직관적이고 효율적으로 처리할 수 있기 때문입니다. 특히, SQL을 XML 파일로 분리하여 관리할 수 있는 것이 큰 장점입니다.

MyBatis 의존성 추가 (pom.xml)

MyBatis를 사용하기 위해서는 다음과 같이 의존성을 추가합니다.

<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-starter</artifactId>
    <version>2.3.0</version>
</dependency>

MyBatis 설정 (application.yml)

MyBatis와 Spring을 연동하려면 간단한 설정이 필요합니다. application.yml 파일에서 데이터베이스 및 MyBatis 설정을 다음과 같이 할 수 있습니다.

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/mydatabase
    username: myuser
    password: mypassword
    driver-class-name: com.mysql.cj.jdbc.Driver
  mybatis:
    config-location: classpath:mybatis-config.xml
    mapper-locations: classpath:mappers/*.xml

위 설정을 통해 MyBatis와 MySQL이 연동되며, 쿼리문을 XML 파일로 분리해 사용할 수 있습니다.

✔️ XML Mapper 사용 예시

Mapper 인터페이스를 만들고, SQL 쿼리를 XML 파일로 분리하여 사용합니다. 먼저, 인터페이스를 정의한 다음, 그와 매핑되는 XML 파일에서 SQL을 정의합니다.

Mapper 인터페이스

public interface UserMapper {
    User findById(Long id);
    List<User> findAll();
}

XML 파일로 쿼리 정의 (`UserMapper.xml`)

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
  PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
  "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="com.example.mapper.UserMapper">

    <!-- 단일 사용자 조회 -->
    <select id="findById" parameterType="long" resultType="com.example.model.User">
        SELECT * FROM users WHERE id = #{id}
    </select>

    <!-- 모든 사용자 조회 -->
    <select id="findAll" resultType="com.example.model.User">
        SELECT * FROM users
    </select>

</mapper>

XML 파일에서는 SQL 쿼리를 정의하고, #{} 구문을 통해 동적으로 파라미터 값을 주입받습니다. 이를 통해 SQL 쿼리를 자바 코드에서 분리하여 XML 파일로 관리할 수 있습니다.

3. 트랜잭션 관리

데이터베이스 작업에서 트랜잭션 관리는 매우 중요한 부분입니다. 트랜잭션은 여러 작업을 하나의 단위로 묶어 원자성을 보장하며, 작업 중 하나라도 실패하면 전체 작업을 롤백할 수 있도록 도와줍니다. Spring에서는 트랜잭션을 선언적 또는 프로그래매틱하게 관리할 수 있습니다.

✔️ 선언적 트랜잭션 관리

선언적 트랜잭션 관리는 가장 많이 사용하는 방식으로, 애너테이션이나 XML 설정을 통해 트랜잭션을 관리하는 방식입니다. 가장 많이 사용하는 애너테이션은 @Transactional입니다. 메서드 또는 클래스 레벨에서 이 애너테이션을 붙이면, 해당 메서드 내의 모든 데이터베이스 작업이 트랜잭션으로 처리됩니다.

예시

@Transactional
public void transferMoney(Long fromAccountId, Long toAccountId, Double amount) {
    // 출금
    accountRepository.debit(fromAccountId, amount);
    // 입금
    accountRepository.credit(toAccountId, amount);
}

위 코드를 통해 입금과 출금 작업이 하나의 트랜잭션으로 묶이게 되고, 만약 중간에 에러가 발생하면 전체 작업이 롤백됩니다.

✔️ 프로그래매틱 트랜잭션 관리

프로그래매틱 트랜잭션 관리는 코드에서 직접 트랜잭션을 관리하는 방법입니다. PlatformTransactionManager와 TransactionTemplate을 사용하여 트랜잭션을 시작, 커밋 또는 롤백할 수 있습니다. 선언적 트랜잭션과 달리, 코드 내에서 트랜잭션의 범위를 명시적으로 정의할 수 있습니다.

예시

public void transferMoney(Long fromAccountId, Long toAccountId, Double amount) {
    DefaultTransactionDefinition def = new DefaultTransactionDefinition();
    TransactionStatus status = transactionManager.getTransaction(def);

    try {
        // 출금
        accountRepository.debit(fromAccountId, amount);
        // 입금
        accountRepository.credit(toAccountId, amount);

        transactionManager.commit(status);  // 트랜잭션 커밋
    } catch (Exception e) {
        transactionManager.rollback(status);  // 트랜잭션 롤백
        throw e;
    }
}

4. ⚙️ 데이터베이스 연동 설정 (DataSource 설정, HikariCP 등)

Spring에서 데이터베이스와의 연동을 위해서는 DataSource 설정이 필요합니다. DataSource는 데이터베이스 커넥션을 관리하며, Spring Boot에서는 기본적으로 HikariCP가 기본 연결 풀(Connection Pool)로 제공됩니다. HikariCP는 성능이 뛰어나고 경량화된 커넥션 풀로 많은 애플리케이션에서 사용됩니다.

✔️ HikariCP 설정 예시

Spring Boot에서는 간단하게 application.yml 파일에서 HikariCP 설정을 할 수 있습니다.

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/mydb
    username: root
    password: password
    driver-class-name: com.mysql.cj.jdbc.Driver
    hikari:
      maximum-pool-size: 10
      minimum-idle: 5
      idle-timeout: 30000
      max-lifetime: 1800000

이 설정을 통해 HikariCP를 이용한 데이터베이스 커넥션 풀링을 구성할 수 있습니다.

5. ⚙️ 두 개의 데이터베이스 사용하기 (Multiple DataSources)

Spring Boot에서는 두 개 이상의 데이터베이스를 사용하여 각각 독립적으로 트랜잭션을 관리할 수 있습니다. 여기서는 두 개의 DataSource를 설정하고, 각각의 데이터베이스에 대해 트랜잭션을 어떻게 처리할 수 있는지 설명하겠습니다.

두 개의 데이터베이스 설정 (application.yml)

spring:
  datasource:
    primary:
      url: jdbc:mysql://localhost:3306/primarydb
      username: primary_user
      password: primary_password
      driver-class-name: com.mysql.cj.jdbc.Driver
    secondary:
      url: jdbc:mysql://localhost:3306/secondarydb
      username: secondary_user
      password: secondary_password
      driver-class-name: com.mysql.cj.jdbc.Driver

mybatis:
  primary:
    mapper-locations: classpath:mappers/primary/*.xml
  secondary:
    mapper-locations: classpath:mappers/secondary/*.xml

위 설정은 각각 Primary 데이터베이스와 Secondary 데이터베이스에 대한 연결 정보를 제공합니다.

✔️ Primary DataSource 설정

@Configuration
@MapperScan(basePackages = "com.example.mapper.primary", sqlSessionFactoryRef = "primarySqlSessionFactory")
public class PrimaryDataSourceConfig {

    @Primary
    @Bean(name = "primaryDataSource")
    @ConfigurationProperties(prefix = "spring.datasource.primary")
    public DataSource primaryDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Primary
    @Bean(name = "primarySqlSessionFactory")
    public SqlSessionFactory primarySqlSessionFactory(@Qualifier("primaryDataSource") DataSource dataSource) throws Exception {
        SqlSessionFactoryBean sessionFactory = new SqlSessionFactoryBean();
        sessionFactory.setDataSource(dataSource);
        return sessionFactory.getObject();
    }

    @Primary
    @Bean(name = "primarySqlSessionTemplate")
    public SqlSessionTemplate primarySqlSessionTemplate(@Qualifier("primarySqlSessionFactory") SqlSessionFactory sqlSessionFactory) {
        return new SqlSessionTemplate(sqlSessionFactory);
    }
}

✔️ Secondary DataSource 설정

@Configuration
@MapperScan(basePackages = "com.example.mapper.secondary", sqlSessionFactoryRef = "secondarySqlSessionFactory")
public class SecondaryDataSourceConfig {

    @Bean(name = "secondaryDataSource")
    @ConfigurationProperties(prefix = "spring.datasource.secondary")
    public DataSource secondaryDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean(name = "secondarySqlSessionFactory")
    public SqlSessionFactory secondarySqlSessionFactory(@Qualifier("secondaryDataSource") DataSource dataSource) throws Exception {
        SqlSessionFactoryBean sessionFactory = new SqlSessionFactoryBean();
        sessionFactory.setDataSource(dataSource);
        return sessionFactory.getObject();
    }

    @Bean(name = "secondarySqlSessionTemplate")
    public SqlSessionTemplate secondarySqlSessionTemplate(@Qualifier("secondarySqlSessionFactory") SqlSessionFactory sqlSessionFactory) {
        return new SqlSessionTemplate(sqlSessionFactory);
    }
}

6. 두 개의 데이터베이스 트랜잭션 관리

✔️ 기본 트랜잭션 관리 문제

두 개의 데이터베이스를 사용하는 경우, 일반적으로 @Transactional 애너테이션을 사용하면 하나의 트랜잭션 매니저만 적용됩니다. 예를 들어 하나의 서비스에서 두 개의 데이터베이스를 동시에 사용하는 경우, 한 데이터베이스에서 에러가 발생해도 다른 데이터베이스의 변경 사항은 롤백되지 않을 수 있습니다.

이 문제를 해결하기 위해 ChainedTransactionManager를 이용하여 두 개의 트랜잭션을 동기화할 수 있습니다.

✔️ ChainedTransactionManager 설정

ChainedTransactionManager는 여러 개의 트랜잭션 매니저를 묶어 하나의 트랜잭션처럼 동작하게 만드는 방법입니다. 이를 통해 두 개 이상의 데이터베이스에서 발생하는 작업을 하나의 트랜잭션으로 처리할 수 있습니다.

ChainedTransactionManager 설정 예시

@Configuration
public class ChainedTransactionManagerConfig {

    @Bean(name = "chainedTransactionManager")
    public ChainedTransactionManager transactionManager(
            @Qualifier("primaryTransactionManager") PlatformTransactionManager primaryTransactionManager,
            @Qualifier("secondaryTransactionManager") PlatformTransactionManager secondaryTransactionManager) {
        return new ChainedTransactionManager(primaryTransactionManager, secondaryTransactionManager);
    }
}

✔️ ChainedTransactionManager를 이용한 트랜잭션 적용

이제 ChainedTransactionManager를 설정한 후, 서비스 레이어에서 두 개의 데이터베이스를 호출할 때 트랜잭션을 적용할 수 있습니다.

예시 서비스 클래스

@Service
public class UserService {

    @Autowired
    private PrimaryUserMapper primaryUserMapper;

    @Autowired
    private SecondaryUserMapper secondaryUserMapper;

    @Autowired
    private ChainedTransactionManager chainedTransactionManager;

    @Transactional(transactionManager = "chainedTransactionManager")
    public void createUserInBothDB(User user) {
        primaryUserMapper.insertUser(user);   // Primary DB에 사용자 추가
        secondaryUserMapper.insertUser(user); // Secondary DB에 사용자 추가
    }
}

위 코드에서는 ChainedTransactionManager를 통해 두 데이터베이스의 트랜잭션을 묶어 처리하게 됩니다. 하나의 데이터베이스에서 에러가 발생하면 전체 트랜잭션이 롤백됩니다.

요약

Spring JDBC Template은 복잡한 JDBC 작업을 간소화해주는 유틸리티로, 데이터베이스와의 상호작용을 쉽게 할 수 있게 도와줍니다.
MyBatis는 SQL과 자바 객체 간의 매핑을 지원하는 프레임워크로, SQL 쿼리를 XML 파일로 분리하여 관리할 수 있습니다.
트랜잭션 관리는 선언적 방식과 프로그래매틱 방식으로 나뉘며, 상황에 맞게 선택할 수 있습니다.
데이터베이스 연동 설정에서 HikariCP와 같은 커넥션 풀을 사용하여 성능 최적화를 도모할 수 있습니다.
두 개의 데이터베이스를 사용하는 경우, 각각의 DataSource와 트랜잭션 매니저를 설정해야 하며, 트랜잭션을 묶어 관리하려면 ChainedTransactionManager를 사용할 수 있습니다.
ChainedTransactionManager를 사용하면 두 개 이상의 데이터베이스에서 하나의 트랜잭션처럼 작업을 처리할 수 있어, 데이터 일관성을 유지할 수 있습니다.

[DB] JOIN과 EXISTS의 차이점

TaeHuiLee — Fri, 27 Sep 2024 08:00:09 +0900

1. 데이터베이스에서 `JOIN`과 `EXISTS`의 차이점

데이터베이스 쿼리를 작성할 때, 데이터를 가져오기 위해 JOIN을 사용할지, 아니면 특정 조건이 존재하는지만 확인하기 위해 EXISTS를 사용할지 고민하게 되는 경우가 있습니다. JOIN과 EXISTS의 차이점과 각각의 사용 목적에 대해 자세히 알아보겠습니다.

2. `JOIN`: 데이터를 가져오는 도구

JOIN은 말 그대로 두 개 이상의 테이블을 합쳐서 원하는 데이터를 가져오는 데 사용됩니다. 데이터를 결합하여 새로운 결과를 반환할 때 주로 사용됩니다. JOIN의 종류로는 INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL JOIN 등이 있으며, 각 방식에 따라 결과가 달라집니다.

INNER JOIN: 두 테이블에서 공통된 값이 있는 행만 가져옵니다.
LEFT JOIN: 왼쪽 테이블의 모든 데이터를 가져오고, 오른쪽 테이블에서 일치하는 데이터가 없는 경우 NULL을 반환합니다.
RIGHT JOIN: LEFT JOIN과 반대로, 오른쪽 테이블의 모든 데이터를 가져오고, 왼쪽 테이블에서 일치하지 않는 데이터는 NULL로 반환됩니다.
FULL JOIN: 왼쪽과 오른쪽 테이블의 모든 데이터를 가져오며, 일치하지 않는 부분은 NULL로 채웁니다.

‍ `JOIN` 예시

다음은 JOIN을 사용하는 간단한 예시입니다:

SELECT 
    a.name, 
    b.order_date
FROM 
    customers a
INNER JOIN 
    orders b
ON 
    a.customer_id = b.customer_id;

위의 쿼리는 customers 테이블과 orders 테이블을 INNER JOIN으로 연결하여, 고객의 이름과 그 고객의 주문 날짜를 함께 가져오는 방식입니다.

3. `EXISTS`: 존재 여부를 판단하는 도구

EXISTS는 데이터의 존재 여부를 확인할 때 사용됩니다. 즉, 데이터를 실제로 가져오지 않고, 서브쿼리에서 조건을 만족하는 데이터가 존재하는지 참 또는 거짓으로만 판단합니다.

이 방식은 대량의 데이터를 처리하지 않으며, 단순히 해당 조건을 만족하는 데이터가 있는지 여부만 판단합니다.

‍ `EXISTS` 예시

다음은 EXISTS를 사용하는 간단한 예시입니다:

SELECT 
    name
FROM 
    customers a
WHERE 
    EXISTS (
        SELECT 
            1 
        FROM 
            orders b 
        WHERE 
            a.customer_id = b.customer_id
    );

위의 쿼리는 customers 테이블에서 고객이 존재하는지 확인하고, 그 고객이 orders 테이블에 주문 기록이 있는지 여부만 확인합니다. 서브쿼리에서 조건을 만족하는 데이터가 존재하면 EXISTS는 TRUE를 반환하여 고객의 이름을 가져옵니다.

4. `JOIN`과 `EXISTS`의 차이점

JOIN과 EXISTS의 차이점은 다음과 같이 정리할 수 있습니다:

목적
- JOIN: 데이터를 가져오는 것이 목적입니다.
- EXISTS: 데이터를 가져오는 것이 아니라, 데이터의 존재 여부를 확인하는 것이 목적입니다.
동작 방식
- JOIN: 테이블 간의 데이터를 결합하여 새로운 결과를 반환합니다.
- EXISTS: 서브쿼리의 결과가 존재하는지만 확인하며, 실제로 데이터를 결합하지는 않습니다.
성능
- JOIN: 필요한 데이터를 가져오는 데 사용되지만, 큰 테이블을 연결할 경우 성능에 영향을 미칠 수 있습니다.
- EXISTS: 조건을 만족하는지만 판단하기 때문에, 대량의 데이터를 가져오는 것보다 빠른 경우가 많습니다.
사용 예시
- JOIN: 실제로 두 테이블에서 데이터를 결합하여 원하는 값을 가져올 때 사용합니다.
- EXISTS: 특정 조건에 맞는 데이터가 존재하는지만 판단할 때 사용합니다.

5. 정리

JOIN은 두 개 이상의 테이블을 결합하여 데이터를 가져오는 데 사용됩니다.
EXISTS는 데이터를 결합하지 않고, 특정 조건이 존재하는지만 확인합니다.
성능 면에서 JOIN은 대량의 데이터를 처리할 때 성능 저하가 있을 수 있지만, EXISTS는 존재 여부만 확인하기 때문에 상대적으로 더 가볍습니다.

상황에 따라 JOIN과 EXISTS를 적절히 사용하는 것이 중요합니다. 데이터 결합이 필요한 경우에는 JOIN, 단순히 조건을 확인하려는 경우에는 EXISTS를 사용하면 됩니다.

[Vue] 여러 컨테이너 다루기: v-show, v-if, :is, keep-alive

TaeHuiLee — Wed, 25 Sep 2024 08:00:45 +0900

Vue에서 여러 컨테이너 다루기: `v-show`, `v-if`, `:is`, `keep-alive` 사용법과 차이점

Vue로 개발하다 보면, 여러 컨테이너(컴포넌트)를 조건에 따라 보이거나 숨기거나, 동적으로 전환하는 상황이 자주 발생합니다. 이를 효과적으로 처리하기 위한 주요 도구로는 v-show, v-if, :is, 그리고 keep-alive가 있습니다. 이번 포스팅에서는 이들을 사용하는 방법과 각 방법의 차이, 동적 컴포넌트 전환 시 서로 다른 props 전달 방법과 동적으로 이벤트 메서드를 처리하는 방법을 포함해 자세히 알아보겠습니다.

1. `v-if`: 조건에 따라 컴포넌트를 추가/제거

v-if는 조건이 true일 때 컴포넌트를 DOM에 추가하고, 조건이 false일 때 컴포넌트를 DOM에서 완전히 제거합니다. 다시 렌더링될 때는 초기 상태로 돌아가기 때문에, 컴포넌트를 추가/제거할 때 상태가 초기화되는 것이 필요한 경우 적합합니다.

`v-if` 예시 코드

<template>
  <div>
    <button @click="showComponent = !showComponent">컴포넌트 보이기/숨기기</button>
    <ChildComponent v-if="showComponent" />
  </div>
</template>

<script>
import ChildComponent from './ChildComponent.vue';

export default {
  data() {
    return {
      showComponent: true
    };
  }
}
</script>

장점: 컴포넌트를 DOM에서 완전히 제거함으로써 성능 최적화 가능.
단점: 컴포넌트를 제거하고 다시 렌더링할 때 상태가 초기화됨.
사용 시기: 상태가 초기화되어야 할 때, 예를 들어 폼 데이터 리셋이나 탭 전환 시 페이지 초기화가 필요할 때 적합합니다.

2. `v-show`: 상태 유지한 채 컴포넌트 숨기기/보이기

v-show는 컴포넌트를 DOM에 유지한 채로, 조건에 따라 CSS를 사용해 보이거나 숨깁니다. 컴포넌트는 계속 DOM에 남아 있으므로, 상태가 유지됩니다.

`v-show` 예시 코드

<template>
  <div>
    <button @click="isVisible = !isVisible">컴포넌트 보이기/숨기기</button>
    <ChildComponent v-show="isVisible" />
  </div>
</template>

<script>
import ChildComponent from './ChildComponent.vue';

export default {
  data() {
    return {
      isVisible: true
    };
  }
}
</script>

장점: 상태가 유지된 상태로 컴포넌트를 빠르게 보이거나 숨길 수 있음.
단점: 컴포넌트가 DOM에 계속 남아 있기 때문에, 메모리 사용량이 증가할 수 있음.
사용 시기: 상태를 유지한 채로 빠르게 전환할 필요가 있을 때, 예를 들어 탭 전환에서 탭의 상태가 그대로 유지되어야 하는 경우 적합합니다.

3. `:is`: 동적으로 컴포넌트 전환 및 `props` 동적 전달

:is는 여러 컴포넌트 중 하나를 동적으로 선택해서 렌더링할 수 있게 해줍니다. 또한, 동적으로 전환되는 컴포넌트에 서로 다른 props를 전달할 수 있습니다. 이를 통해 상황에 맞게 다른 데이터를 각 컴포넌트에 넘겨줄 수 있습니다.

`:is`와 `props` 동적 전달 예시 코드

<template>
  <div>
    <button @click="changeComponent('Component1', { propA: '데이터 A' })">컴포넌트 1</button>
    <button @click="changeComponent('Component2', { propB: '데이터 B' })">컴포넌트 2</button>

    <!-- 동적 컴포넌트 및 props 전달 -->
    <component :is="currentComponent" v-bind="currentProps" />
  </div>
</template>

<script>
import Component1 from './Component1.vue';
import Component2 from './Component2.vue';

export default {
  data() {
    return {
      currentComponent: 'Component1',
      currentProps: {
        propA: '데이터 A'
      }
    };
  },
  methods: {
    // 컴포넌트와 props 동적 변경
    changeComponent(component, props) {
      this.currentComponent = component;
      this.currentProps = props;
    }
  },
  components: {
    Component1,
    Component2
  }
}
</script>

장점: 여러 컴포넌트를 동적으로 전환하고, 각 컴포넌트에 다른 props를 동적으로 전달할 수 있음.
단점: 상태가 유지되지 않고, 전환될 때 새로운 인스턴스가 생성됨. 이를 방지하기 위해 keep-alive를 사용해야 함.
사용 시기: 동적으로 여러 컴포넌트를 전환해야 하고, 각 컴포넌트에 다른 데이터(props)를 전달할 때 적합합니다. 예를 들어 탭 전환 시 각 탭에 서로 다른 데이터를 보여줄 때 유용합니다.

4. `keep-alive`: 상태를 유지한 채 컴포넌트 캐싱

keep-alive는 캐싱된 컴포넌트의 상태를 유지하도록 도와줍니다. 동적으로 컴포넌트를 전환할 때, 컴포넌트가 초기화되지 않고 이전 상태를 유지해야 한다면 keep-alive를 사용하면 됩니다. 컴포넌트를 전환해도 메모리에 캐싱된 상태로 유지되기 때문에 성능 최적화에도 도움이 됩니다.

`keep-alive`와 `props` 동적 전달 예시 코드

<template>
  <div>
    <button @click="changeComponent('Component1', { propA: '데이터 A' })">컴포넌트 1</button>
    <button @click="changeComponent('Component2', { propB: '데이터 B' })">컴포넌트 2</button>

    <!-- keep-alive로 상태 유지 -->
    <keep-alive>
      <component :is="currentComponent" v-bind="currentProps" />
    </keep-alive>
  </div>
</template>

<script>
import Component1 from './Component1.vue';
import Component2 from './Component2.vue';

export default {
  data() {
    return {
      currentComponent: 'Component1',
      currentProps: {
        propA: '데이터 A'
      }
    };
  },
  methods: {
    changeComponent(component, props) {
      this.currentComponent = component;
      this.currentProps = props;
    }
  },
  components: {
    Component1,
    Component2
  }
}
</script>

장점: 상태를 유지하면서 동적 컴포넌트를 전환하고, 각 컴포넌트에 다른 props를 넘길 수 있음.
단점: 컴포넌트를 메모리에 캐싱하므로, 많은 컴포넌트를 캐싱할 경우 메모리 사용량 증가 가능.
사용 시기: 상태 유지가 필요하면서도 동적 컴포넌트 전환이 필요한 상황에서 사용. 예를 들어, 동적 페이지 전환 시 각 페이지의 입력 상태나 폼 데이터를 그대로 유지하고 싶을 때 적합합니다.

5. 동적 컴포넌트 전환 시 `$emit` 메서드도 동적으로 변경하기

동적으로 컴포넌트를 전환할 때, 이벤트($emit)를 통해 상위 컴포넌트에 데이터를 전달해야 할 때가 많습니다. 이때 컴포넌트에 따라 이벤트 메서드도 동적으로 변경할 필요가 있습니다. 컴포넌트를 전환하면서 해당 컴포넌트에서 발생하는 이벤트를 동적으로 처리할 수 있도록 설정할 수 있습니다.

동적 컴포넌트에서 이벤트 처리 예시

<template>
  <div>
    <button @click="currentComponent = 'Component1'">컴포넌트 1</button>
    <button @click="currentComponent = 'Component2'">컴포넌트 2</button>

    <component :is="currentComponent" @custom-event="handleEvent" />
  </div>
</template>

<script>
import Component1 from './Component1.vue';
import Component2 from './Component2.vue';

export default {
  data() {
    return {
      currentComponent: 'Component1'
    };
  },
  methods: {
    handleEvent(data) {
      // 이벤트에 따라 처리할 동작을 설정
      if (this.currentComponent === 'Component1') {
        console.log('Component1 이벤트:', data);
      } else if (this.currentComponent === 'Component2') {
        console.log('Component2 이벤트:', data);
      }
    }
  },
  components: {
    Component1,
    Component2
  }
}
</script>

동적으로 변경된 컴포넌트에서 발생하는 이벤트를 동적으로 처리할 수 있습니다.
상위 컴포넌트에서는 동일한 이벤트 리스너를 사용하되, 컴포넌트에 따라 다른 동작을 수행할 수 있습니다.

6. v-if, v-show, :is, keep-alive 차이점 요약


특징	v-if	v-show	:is	keep-alive
렌더링 동작	조건에 따라 컴포넌트를 DOM에서 제거	컴포넌트를 DOM에 유지, CSS로 숨김	동적으로 컴포넌트를 교체	상태를 유지하면서 컴포넌트를 캐싱
상태 유지 여부	컴포넌트가 제거되면 상태 초기화	상태가 유지됨	상태가 유지되지 않음 (keep-alive 필요)	상태 유지됨
DOM 제거 여부	컴포넌트가 DOM에서 완전히 제거됨	컴포넌트는 DOM에 남아 있음	컴포넌트가 동적으로 전환됨	컴포넌트가 메모리에 남아 있음
성능	자주 변경 시 성능 저하 가능성 있음	성능에 유리	성능에 유리, keep-alive로 상태 유지 필요	성능 최적화, 메모리 사용량 증가 가능
사용 목적	상태가 초기화되어야 할 때	상태를 유지한 채 보이기/숨기기	여러 컴포넌트를 동적으로 전환	상태를 유지하면서 동적 전환할 때

정리

v-if: 컴포넌트를 조건에 따라 추가/제거하며, 상태가 초기화됩니다.
v-show: 상태를 유지한 채 DOM에서 컴포넌트를 숨기거나 보이기만 합니다.
:is: 여러 컴포넌트를 동적으로 전환할 수 있으며, 다른 props를 동적으로 전달할 수 있습니다. 상태가 초기화되며, keep-alive로 상태를 유지할 수 있습니다.
keep-alive: 상태를 유지하면서 동적으로 컴포넌트를 전환할 때 사용합니다. 상태가 캐싱되며, 성능 최적화에 도움을 줍니다.
동적 컴포넌트에서 $emit을 통해 상위 컴포넌트로 이벤트를 전달할 때는 동적으로 변경된 컴포넌트의 이벤트를 상위 컴포넌트에서 동적으로 처리할 수 있습니다.

[JAVA] Spring Boot Redis 캐시 사용법

TaeHuiLee — Fri, 20 Sep 2024 08:00:49 +0900

1. ️ Redis란 무엇인가?

Redis는 Remote Dictionary Server의 약자로, 데이터를 메모리에 저장하여 빠르게 처리하는 오픈 소스 인메모리 데이터베이스입니다. Key-Value 구조로 데이터를 저장하고, 다양한 데이터 구조를 지원하는 것이 특징입니다. 일반적인 데이터베이스와 달리 데이터를 디스크가 아닌 메모리에 저장하기 때문에 읽기/쓰기 속도가 매우 빠릅니다.

Redis의 특징

인메모리 데이터베이스: Redis는 모든 데이터를 메모리에 저장하고, 필요에 따라 데이터를 디스크에 백업할 수 있습니다. 이로 인해 데이터 처리 속도가 매우 빠르며, 특히 실시간 데이터 처리에 유리합니다.
다양한 데이터 구조 지원: Redis는 단순한 Key-Value 저장소일 뿐만 아니라, 다양한 데이터 타입을 지원합니다. 그 예로 다음과 같은 타입이 있습니다:
- String: 가장 기본적인 형태로, 문자열 데이터를 저장합니다.
- List: 연결 리스트 형태로, 순서가 있는 여러 값을 저장할 수 있습니다.
- Set: 중복되지 않는 값들의 집합을 저장할 수 있습니다.
- Hash: 필드와 값의 쌍으로 데이터를 저장할 수 있습니다. 흔히 자바의 Map과 비슷한 구조입니다.
- Sorted Set: 점수를 기반으로 정렬된 집합을 관리할 수 있습니다.
지속성 옵션: Redis는 메모리에 저장된 데이터를 디스크에 백업할 수 있는 옵션을 제공합니다. 이를 통해 RDB 스냅샷과 AOF(Append-Only File)와 같은 방식으로 데이터를 영구적으로 저장하거나 복구할 수 있습니다.
스케일링과 확장성: Redis는 클러스터링을 지원하여 여러 노드에 데이터를 분산시켜 저장하고 처리할 수 있습니다. 이를 통해 수평 확장이 가능하며, 큰 데이터를 분산 저장할 수 있습니다.
Pub/Sub 기능: Redis는 발행-구독(Pub/Sub) 패턴을 지원해, 메시지 브로커로도 사용할 수 있습니다. 실시간 채팅, 알림 서비스 같은 시스템에서 사용됩니다.
Atomic Operation: Redis는 모든 명령이 원자적(atomic)으로 실행되기 때문에, 복수의 클라이언트가 동시에 동일한 데이터에 접근해도 안전하게 처리됩니다.

Redis의 주요 용도

캐싱: Redis는 주로 캐시로 사용됩니다. 서버의 데이터를 Redis에 캐싱함으로써, 데이터베이스에 대한 접근을 줄이고 성능을 향상시킬 수 있습니다.
세션 저장소: 사용자의 세션을 Redis에 저장해 빠르게 접근하고, 여러 서버에서 공유할 수 있습니다.
순위 시스템: Sorted Set을 사용하여 점수 기반의 순위를 관리할 수 있습니다. 예를 들어, 게임 리더보드나 인기 콘텐츠 순위를 만들 때 유용합니다.
실시간 분석: 실시간 데이터를 빠르게 처리할 수 있는 특징 때문에, 로그 처리나 실시간 모니터링 시스템에서도 Redis를 많이 사용합니다.

2. Redis의 동작 원리

Redis는 데이터를 메모리에 저장하기 때문에, 매우 빠른 읽기 및 쓰기 성능을 제공합니다. 모든 데이터는 메모리에 상주하며, 필요에 따라 비동기적으로 디스크에 저장하여 데이터를 영구적으로 유지할 수 있습니다. Redis의 동작 원리는 다음과 같습니다:

Key-Value 데이터 저장: Redis는 Key-Value 방식으로 데이터를 저장하며, 이를 통해 빠르게 데이터를 찾고 처리할 수 있습니다.
비동기적 데이터 영속성: Redis는 메모리에 데이터를 저장하지만, RDB(Redis Database Backup) 방식이나 AOF(Append-Only File) 방식을 사용해 데이터를 디스크에 저장하여 영구성을 제공합니다. RDB 방식은 일정 주기로 데이터를 저장하고, AOF 방식은 명령어 단위로 로그를 기록해 복구 시 이 명령을 다시 실행합니다.
원자적 작업: Redis의 모든 명령은 원자적으로 처리됩니다. 즉, 동시에 여러 클라이언트가 같은 데이터에 접근하더라도 데이터 손상이 없으며, 항상 일관된 상태를 유지합니다.
Pub/Sub 동작 원리: Redis의 Pub/Sub 기능은 메시지를 발행자와 구독자가 직접적으로 연결해주는 방식입니다. 발행자는 특정 채널에 메시지를 보내고, 구독자는 해당 채널에 연결된 모든 메시지를 수신합니다. 실시간 알림이나 채팅 같은 시스템에 적합합니다.

3. Spring에서 Redis 사용 방법 (Maven)

이제 Redis의 동작 원리를 이해했다면, Spring에서 Redis를 어떻게 사용하는지 살펴보겠습니다. Spring에서는 Spring Data Redis를 통해 Redis와 쉽게 연동할 수 있습니다.

Maven 설정

pom.xml 파일에 아래와 같이 의존성을 추가합니다.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

그리고, application.yml 파일에 Redis 서버 정보를 설정합니다.

spring:
  redis:
    host: localhost
    port: 6379

이제 Spring에서 Redis를 사용할 준비가 완료되었습니다.

캐시 어노테이션 사용

Spring은 Redis와의 캐시 통합을 돕기 위해 몇 가지 유용한 어노테이션을 제공합니다:

@Cacheable: 메서드 실행 전에 캐시를 먼저 확인하고, 데이터가 없으면 메서드를 실행해 결과를 캐시에 저장합니다.

@CachePut(value = "users", key = "#user.id")
public User updateUser(User user) {
    // 메서드가 실행되고, 그 결과가 캐시에 저장됨
    return userRepository.save(user);
}

@CachePut: 메서드를 항상 실행하고 그 결과를 캐시에 업데이트합니다.

@CachePut(value = "users", key = "#user.id")
public User updateUser(User user) {
    // 메서드가 실행되고, 그 결과가 캐시에 저장됨
    return userRepository.save(user);
}

@CacheEvict: 캐시에서 데이터를 삭제할 때 사용됩니다.

@CacheEvict(value = "users", key = "#userId")
public void deleteUser(String userId) {
    // 캐시에서 해당 유저 데이터가 삭제됨
    userRepository.deleteById(userId);
}

4. 직렬화와 역직렬화 방식 (Java, Jackson)

Redis는 데이터를 저장할 때 직렬화 방식으로 데이터를 변환하여 메모리에 저장합니다. Spring에서 Redis와 데이터를 주고받을 때는 Java 직렬화 또는 JSON 직렬화(Jackson)를 주로 사용합니다.

Java 직렬화

Java 직렬화는 클래스가 Serializable 인터페이스를 구현해야 합니다.
Java 직렬화는 데이터가 클 수 있다는 단점이 있으며, 클래스 구조가 변경되면 이전에 직렬화된 데이터를 읽을 때 문제가 발생할 수 있습니다. 이때 serialVersionUID를 설정해주면 클래스의 변경 여부를 체크해 호환성을 보장할 수 있습니다.

Jackson을 사용한 JSON 직렬화

Jackson을 사용하면 데이터를 JSON 형식으로 직렬화해 저장할 수 있으며, 다른 시스템과의 호환성이 좋습니다.
Jackson 직렬화에서는 serialVersionUID가 필요하지 않으며, 필드 이름과 구조를 기반으로 직렬화 및 역직렬화가 진행됩니다.

Jackson 직렬화 설정 예시:

public class RedisConfig {
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory connectionFactory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(connectionFactory);
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new Jackson2JsonRedisSerializer<>(Object.class));
        return template;
    }
}

5. ‍ Redis 사용 시 발생할 수 있는 오류와 처리 방법

Redis를 사용하다 보면 다양한 오류가 발생할 수 있습니다. 그중 자주 발생하는 오류를 살펴보고, 그 처리 방법을 제시합니다.

1. 직렬화/역직렬화 오류 (SerializationException)

발생 상황

Redis에 데이터를 직렬화하여 저장하는 과정에서 직렬화 포맷이 잘못되면 데이터를 읽을 때 문제가 발생할 수 있습니다. 이런 경우, SerializationException과 같은 예외가 발생할 수 있습니다.

처리 방법

직렬화 오류는 Redis 캐시 관련 메서드에서 발생할 수 있으며, 이를 트라이-캐치 블록으로 감싸서 오류를 처리하고, 캐시에서 데이터를 읽지 못하면 DB에서 데이터를 불러오는 방식으로 처리할 수 있습니다.

@Cacheable(value = "users", key = "#userId")
public User getUserFromCache(String userId) {
    try {
        // Redis에서 데이터를 가져옴
        return (User) redisTemplate.opsForValue().get(userId);
    } catch (SerializationException e) {
        // 직렬화 오류 처리
        logger.error("Serialization error when getting user from cache", e);
        // 캐시에서 데이터를 읽을 수 없을 경우, DB에서 조회
        return userRepository.findById(userId).orElse(null);
    }
}

2. Connection 오류 (RedisConnectionFailureException)

발생 상황

Redis 서버와의 네트워크 문제로 인해 발생하는 오류입니다. Redis 서버가 중지되거나, 네트워크 연결이 끊어진 경우 발생할 수 있습니다.

처리 방법

Redis 연결 문제는 LettuceConnectionFactory와 같은 Redis 연결 설정에서 처리할 수 있습니다. 연결 상태를 주기적으로 확인하여 문제가 발생할 경우 다시 연결을 시도할 수 있도록 구성할 수 있습니다.

@Bean
public LettuceConnectionFactory redisConnectionFactory() {
    LettuceConnectionFactory connectionFactory = new LettuceConnectionFactory();
    connectionFactory.setValidateConnection(true);  // 연결 상태를 주기적으로 확인
    return connectionFactory;
}

3. 모델 클래스와 캐시 데이터의 불일치 (ClassCastException)

발생 상황

모델 클래스의 필드가 변경되거나 삭제된 경우, Redis에 저장된 데이터와의 불일치로 인해 ClassCastException이 발생할 수 있습니다.

처리 방법

모델 클래스에 @JsonIgnoreProperties(ignoreUnknown = true) 어노테이션을 사용하여, 알 수 없는 필드를 무시하고 역직렬화를 안전하게 수행할 수 있습니다.

@JsonIgnoreProperties(ignoreUnknown = true)
public class User implements Serializable {

    private static final long serialVersionUID = 1L;

    private String id;
    private String name;
    private int age;

    // 기본 생성자, getter, setter
}

트라이-캐치와 메서드 실행

Spring에서 Redis 캐시를 사용할 때 @Cacheable이나 @CachePut을 사용하는 경우, Redis에서 오류가 발생하더라도 메서드 자체는 계속 실행됩니다. 캐시에서 데이터를 찾지 못하면 메서드의 비즈니스 로직이 실행되고, 그 결과가 캐시에 저장됩니다. 그러나 Redis 오류는 로그에 남게 되므로, 트라이-캐치 블록을 사용해 오류 처리를 통해 안정성을 높일 수 있습니다.

요약

Redis는 빠른 성능의 인메모리 데이터베이스로, 다양한 데이터 구조와 캐시, 세션 관리, 실시간 데이터 처리에 적합합니다.
Spring Data Redis를 통해 쉽게 Redis와 연동할 수 있으며, @Cacheable, @CachePut, @CacheEvict 등의 어노테이션을 사용해 캐시 관리를 할 수 있습니다.
Redis 오류는 직렬화/역직렬화 오류, 연결 문제, 타입 불일치 등의 문제가 있을 수 있으며, 이를 적절한 예외 처리와 어노테이션으로 관리해야 합니다.
트라이-캐치 블록을 통해 Redis 오류가 발생하더라도 서비스가 정상적으로 동작하도록 처리할 수 있으며, 캐시와 비즈니스 로직이 원활하게 연결됩니다.

[JAVA] Spring 돌아보기 Part.2 #AOP

TaeHuiLee — Thu, 12 Sep 2024 08:00:28 +0900

Aspect-Oriented Programming (AOP)

AOP는 관심사 분리를 목표로 하는 프로그래밍 패러다임입니다. 특히 로깅, 트랜잭션 관리, 보안과 같은 횡단 관심사(Cross-cutting concerns)를 비즈니스 로직에서 분리할 수 있도록 해줍니다. 비즈니스 로직과는 상관없는 코드가 곳곳에 중복해서 나타나는 문제를 해결해주기 때문에 유지보수성을 크게 향상시킬 수 있습니다. 이를 통해 비즈니스 로직은 본연의 역할에만 집중할 수 있게 되는 거죠.

AOP의 핵심 개념

횡단 관심사(Cross-Cutting Concern): 애플리케이션 전반에 걸쳐 사용되는 공통된 기능들. 예를 들어, 로깅, 트랜잭션 관리, 보안 처리 같은 것들이 이에 해당됩니다. 이들은 각 모듈에서 필요로 하지만, 해당 모듈의 핵심 기능은 아닙니다.
Aspect: 횡단 관심사 로직을 모듈화한 것을 Aspect라고 부릅니다. 예를 들어, 트랜잭션 관리, 로깅 등을 각각의 Aspect로 만들 수 있습니다.
Advice: Aspect가 언제, 어떻게 적용될지 정의하는 동작입니다. Before, After, Around와 같은 여러 타입이 존재합니다.
Join Point: Aspect가 적용될 수 있는 지점을 의미합니다. 예를 들어, 메서드 호출이나 예외 처리 등이 이에 해당합니다.
Pointcut: Join Point 중 실제로 Advice가 실행되는 지점을 선택하는 것입니다. AOP에서는 특정 메서드나 클래스에만 Aspect가 적용되도록 Pointcut을 정의합니다.

2. AOP 설정 및 적용 방법

AOP를 적용하려면, 기본적으로 Spring이 AOP를 인식하고 관리할 수 있도록 설정이 필요합니다.

1) AOP 의존성 추가 (Maven 예시)

대부분의 Spring 프로젝트에서는 AOP 의존성이 기본적으로 포함되어 있지만, 만약 그렇지 않다면 다음과 같이 의존성을 추가해줘야 합니다:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

2) AOP 기능 활성화

@EnableAspectJAutoProxy 어노테이션을 통해 Spring의 AOP 기능을 활성화할 수 있습니다. Spring Boot 프로젝트에서는 보통 Application 클래스에 이 어노테이션을 추가합니다:

@SpringBootApplication
@EnableAspectJAutoProxy  // AOP 기능 활성화
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

3) `@Aspect`로 AOP 적용하기

Aspect를 만들기 위해서는 @Aspect 어노테이션을 사용해 클래스를 정의하고, 해당 클래스를 Spring 컨텍스트에 등록해야 합니다. 일반적으로 @Component나 @Bean을 사용하여 Spring이 관리하는 Bean으로 등록합니다.

로깅을 위한 AOP 예시

다음은 메서드 호출 전에 로그를 남기는 Aspect를 정의한 예시입니다:

@Aspect
@Component  // Spring Bean으로 등록
public class LoggingAspect {

    @Before("execution(* com.example.service.*.*(..))")
    public void logBefore(JoinPoint joinPoint) {
        System.out.println("메서드 실행 전: " + joinPoint.getSignature().getName());
    }

    @After("execution(* com.example.service.*.*(..))")
    public void logAfter(JoinPoint joinPoint) {
        System.out.println("메서드 실행 후: " + joinPoint.getSignature().getName());
    }

    @AfterThrowing("execution(* com.example.service.*.*(..))")
    public void rollbackTransaction() {
      // 트랜잭션 롤백 로직
      System.out.println("트랜잭션 롤백");
    }
}

이 코드에서는:

@Before 어노테이션을 통해 메서드 실행 전에 로그를 출력하는 Advice를 적용했고,
@After 어노테이션으로 메서드가 끝난 후에도 로그를 출력하게 했습니다.
@AfterThrowing 어노테이션으로 예외처리 시 로그를 출력하게 했습니다.

execution(* com.example.service.*.*(..))는 Pointcut 표현식으로, com.example.service 패키지의 모든 클래스의 모든 메서드에 대해 AOP를 적용한다는 의미입니다.

4) 트랜잭션을 위한 AOP 예시

트랜잭션 관리도 AOP로 처리할 수 있습니다. 하지만 일반적으로는 Spring이 제공하는 @Transactional 어노테이션을 사용하는 것이 편리합니다.

@Service
public class OrderService {

    @Transactional
    public void placeOrder(Order order) {
        // 주문 상태 확인
        if (!order.isValid()) {
            throw new IllegalStateException("주문 상태가 유효하지 않습니다.");
        }

        // 주문 처리 로직
        orderRepository.save(order);

        // 기타 비즈니스 로직
        // 트랜잭션은 알아서 커밋됩니다.
    }
}

이 코드에서 @Transactional 어노테이션을 사용하면, Spring이 내부적으로 AOP를 이용해 트랜잭션을 관리합니다. 비즈니스 로직이 정상적으로 완료되면 트랜잭션이 커밋되고, 예외가 발생하면 롤백됩니다.

3. 정리

AOP는 로깅, 트랜잭션 관리 같은 공통 기능을 비즈니스 로직과 분리하여 더 깔끔한 코드를 작성할 수 있게 해줍니다. 이를 통해 중복 코드를 제거하고, 유지보수가 쉬워집니다.
Spring AOP는 @Aspect, @Before, @After 같은 어노테이션을 사용해 쉽게 적용할 수 있으며, AOP 기능을 활성화하려면 @EnableAspectJAutoProxy 어노테이션을 추가해줘야 합니다.
트랜잭션 관리는 보통 @Transactional 어노테이션을 사용하여 Spring에서 자동으로 처리할 수 있습니다.

[JAVA] Spring 돌아보기 Part.1 #IoC #DI #싱글톤

TaeHuiLee — Tue, 10 Sep 2024 08:00:45 +0900

1. Spring의 IoC와 DI, 그리고 그 동작 방식

Spring에서 중요한 개념 중 하나는 IoC(제어의 역전)과 DI(의존성 주입)입니다. 이 두 가지는 결국 객체의 생성과 관리를 누가 담당하는지에 관한 이야기입니다.

원래는 개발자가 프로그램 내에서 필요한 객체를 직접 생성하고, 의존 관계가 있으면 그 관계를 직접 설정해야 했습니다. 하지만 Spring은 IoC를 통해 이런 책임을 프레임워크가 맡습니다. 쉽게 말하면, 객체 생성과 의존성 관리의 제어권을 Spring이 가져가고, 개발자는 비즈니스 로직에만 집중할 수 있게 되는 것이죠.

IoC 개념을 구현하는 방법이 바로 DI(Dependency Injection)입니다. DI는 말 그대로 객체가 필요한 의존성을 외부에서 주입받는 방식입니다. 예를 들어, 서비스 클래스가 Repository를 필요로 한다면, 개발자가 직접 Repository 객체를 생성하지 않고, Spring이 이를 자동으로 주입해줍니다. 코드를 한번 보겠습니다.

@Component
public class UserService {

    private final UserRepository userRepository;

    // 생성자 주입 방식
    @Autowired
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public void createUser(User user) {
        userRepository.save(user);
    }
}

여기서 UserService는 UserRepository를 필요로 하고, 우리는 생성자 주입 방식으로 이를 받아들입니다.

@Autowired 어노테이션 덕분에 Spring이 UserRepository 빈을 자동으로 찾아 주입해주는 것이죠. 이것이 바로 DI(의존성 주입)입니다. 이렇게 Spring이 객체 간의 의존성을 해결해주면, 개발자는 각 객체가 어떤 구체적인 클래스에 의존하는지 알 필요가 없고, 결과적으로 객체 간의 결합도가 낮아지며 코드가 더 유연해집니다.

2. 의존성 주입의 효과와 적용 시점

DI는 객체 간 결합도를 낮추는 데 큰 역할을 합니다. 만약 UserService가 UserRepository를 직접 생성하는 코드라면 다음과 같이 작성될 겁니다.

public class UserService {

    private final UserRepository userRepository = new UserRepository();

    public void createUser(User user) {
        userRepository.save(user);
    }
}

이 코드에서는 UserService가 UserRepository의 구체적인 구현에 의존하고 있습니다. 만약 UserRepository의 구현이 변경되거나 새로운 타입의 Repository가 필요해진다면, UserService도 함께 수정해야 합니다. 이렇게 직접 객체를 생성하는 방식은 클래스 간 결합도를 높이고, 변경이 발생할 때 유연성이 떨어지게 됩니다.

하지만 DI를 사용하면 클래스 내부에서 구체적인 구현을 몰라도 됩니다. Spring이 외부에서 의존성을 주입해주기 때문에, UserService는 UserRepository의 구체적인 동작을 몰라도 됩니다. 결과적으로 클래스는 인터페이스나 추상 클래스에만 의존하게 되어, 이후에 변경이 생기더라도 쉽게 처리할 수 있습니다.

그리고 Spring에서는 의존성 주입이 애플리케이션 실행 시 자동으로 이루어집니다. Spring이 애플리케이션을 구동하면서 필요한 빈들을 미리 생성하고, 주입을 완료하기 때문에 개발자가 직접 신경 쓰지 않아도 됩니다.

3. DI를 활용한 다양한 주입 방식

Spring에서는 주입 방식으로 크게 생성자 주입, 필드 주입, 세터 주입이 있습니다. 각각의 방식에 대해 간단히 살펴보겠습니다.

생성자 주입: 의존성을 객체가 생성될 때 주입받는 방식입니다. 생성자에 의존성을 명시하고, Spring이 해당 의존성을 주입해줍니다.

@Component
public class UserService {

    private final UserRepository userRepository;

    @Autowired
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

필드 주입: 클래스의 필드에 직접 @Autowired를 붙여서 주입하는 방식입니다. 코드가 간단하지만, 테스트하기 어렵고 순환 참조 문제를 발견하기 어렵다는 단점이 있습니다.

@Component
public class UserService {

    @Autowired
    private UserRepository userRepository;
}

세터 주입: 의존성을 세터 메서드를 통해 주입받는 방식입니다. 의존성이 필수가 아닐 때 유용하게 사용할 수 있지만, 생성자 주입만큼 많이 사용되진 않습니다.

@Component
public class UserService {

    private UserRepository userRepository;

    @Autowired
    public void setUserRepository(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

4. DI에서 구체적인 객체 선택과 주입

Spring에서 여러 구현체가 있을 때, 어떤 객체가 주입될지는 Spring이 타입을 기준으로 결정합니다. 만약 여러 구현체가 같은 타입으로 존재한다면, Spring은 @Primary나 @Qualifier 어노테이션을 통해 어느 빈을 주입할지 결정할 수 있습니다.

@Primary: 여러 빈 중에서 기본적으로 주입할 빈을 지정하는 방법입니다. 여러 개의 빈이 있을 때 우선적으로 선택됩니다.

@Primary
@Component
public class PrimaryUserRepository implements UserRepository {
    // ...
}

@Qualifier: 특정한 이름의 빈을 명시적으로 주입하고 싶을 때 사용합니다. 이를 통해 여러 구현체 중 하나를 선택할 수 있습니다.

@Component
public class UserService {

    private final UserRepository userRepository;

    @Autowired
    public UserService(@Qualifier("secondaryUserRepository") UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

5. 싱글톤 스코프의 컨트롤러와 의존성 관리

Spring에서 빈의 기본 스코프는 싱글톤입니다. 즉, 애플리케이션이 시작될 때 한 번만 생성되고 이후에 재사용됩니다. 하지만, 싱글톤 빈을 사용하더라도 각 요청마다 다른 데이터를 처리할 수 있습니다. 왜냐하면, 컨트롤러 같은 경우는 상태를 가지지 않고, 매 요청마다 새로운 파라미터나 데이터를 처리하기 때문입니다.

또한, 만약 요청마다 새로운 빈이 필요하다면, @RequestScope를 사용해서 요청마다 다른 빈을 생성할 수도 있습니다.

@Component
@RequestScope
public class RequestScopedBean {
    // ...
}

이렇게 하면, 각 요청마다 새로운 빈이 생성되어 서로 다른 데이터를 처리할 수 있습니다.

정리:
Spring에서 IoC와 DI는 객체의 생성과 의존성 관리를 프레임워크가 대신 해주는 방식입니다. 의존성 주입 덕분에 코드 간의 결합도가 낮아지고, 유지보수성이 높아집니다. 주입 방식으로는 생성자 주입이 가장 많이 사용되며, 여러 구현체가 있을 경우 @Primary나 @Qualifier로 주입할 객체를 선택할 수 있습니다. 또한, 싱글톤 스코프의 빈을 사용하면서도 각 요청마다 다른 데이터를 처리할 수 있는 다양한 방법이 제공됩니다.

[JAVA] 객체 비교와 Integer 클래스

TaeHuiLee — Mon, 9 Sep 2024 08:00:27 +0900

️ 객체 비교와 Integer 클래스

Integer.parseInt vs Integer.valueOf

Java에서 Integer.parseInt와 Integer.valueOf는 문자열을 정수로 변환하는 데 사용됩니다. 하지만 이 둘은 반환 타입과 동작 방식에서 차이가 있습니다.

Integer.parseInt(String s):
- 반환 타입: int (기본형)
- 설명: 주어진 문자열 s를 기본형 int로 변환합니다. 이 메서드는 단순히 문자열을 파싱하여 정수로 반환할 뿐입니다.
- 특징: 이 메서드는 int 타입을 반환하기 때문에, 객체가 아닌 기본형 값을 다루게 됩니다. 또한 null을 전달하면 예외가 발생합니다.
- 사용 예시:
  - Integer.parseInt("123")는 int 타입의 123을 반환합니다.
Integer.valueOf(String s):
- 반환 타입: Integer (객체형)
- 설명: 주어진 문자열 s를 Integer 객체로 변환합니다. 내부적으로는 Integer.parseInt를 호출하고, 그 결과를 Integer 객체로 반환합니다.
- 특징: Integer 객체를 반환하며, 자바의 Integer 캐싱 메커니즘에 따라 -128에서 127 사이의 값은 캐싱되어 동일한 참조를 가지게 됩니다. 따라서 메모리와 성능 측면에서 이점이 있습니다.
- 사용 예시:
  - Integer.valueOf("123")는 Integer 객체를 반환합니다.

int num1 = Integer.parseInt("123");
Integer num2 = Integer.valueOf("123");

요약하면, Integer.parseInt는 기본형 int를, Integer.valueOf는 객체형 Integer를 반환합니다. null 처리와 캐싱 메커니즘의 차이로 인해, 사용 목적에 따라 적합한 메서드를 선택하는 것이 중요합니다.

❓ == 연산자 vs equals 메서드

Java에서 객체 비교를 할 때, == 연산자와 equals() 메서드의 차이는 매우 중요합니다. 특히 Integer와 같은 객체형 데이터를 비교할 때, 이 차이를 이해하는 것이 필수적입니다.

1. == 연산자

설명: == 연산자는 참조(메모리 주소)를 비교합니다. 즉, 두 객체가 같은 메모리 주소를 가리키고 있을 때만 true를 반환합니다.
주의사항: 기본형 int와 객체형 Integer 간의 비교에서는 다르게 동작할 수 있습니다. 기본형 int는 단순히 값만을 비교하지만, Integer 객체 간 비교에서는 메모리 주소가 비교되므로, 같은 값을 가질지라도 false를 반환할 수 있습니다.

2. equals() 메서드

설명: equals() 메서드는 값을 비교합니다. Integer 클래스의 equals() 메서드는 내부적으로 두 객체가 같은 값을 가지는지를 비교하도록 오버라이드되어 있습니다. 즉, 같은 값을 가지는 두 Integer 객체가 있다면, equals()는 true를 반환합니다.
예시:
- Integer a = 128; Integer b = 128; 이 경우, a.equals(b)는 true를 반환하지만, a == b는 false를 반환할 수 있습니다. 이는 Integer 객체가 128 이상의 값일 때 캐싱되지 않기 때문에 서로 다른 메모리 주소를 가지기 때문입니다.

Integer a = Integer.valueOf(128);
Integer b = Integer.valueOf(128);

System.out.println(a == b); // false: 서로 다른 객체를 참조
System.out.println(a.equals(b)); // true: 같은 값을 가짐

int c = 128;
System.out.println(a == c); // true (auto-unboxing)

Integer와 int를 비교할 때는 자동 언박싱으로 인해 값이 비교되므로, == 연산자는 true를 반환할 수 있습니다. 하지만 Integer 객체 간 비교에서는 equals()를 사용하는 것이 안전합니다.

Integer와 int의 비교

Integer와 int를 비교할 때는 자동 언박싱(auto-unboxing)이라는 개념이 중요합니다. Java는 Integer 객체를 int 기본형으로 자동 변환하는 기능을 제공합니다. 따라서 다음과 같은 상황에서 == 연산자가 true를 반환할 수 있습니다.

자동 언박싱 예시:
- Integer a = 128; int b = 128; 이 경우, a == b는 true를 반환합니다. 이는 Java가 Integer 객체를 자동으로 int로 변환하여 값 비교를 수행하기 때문입니다.

캐싱 메커니즘과 참조 비교

설명: Java는 -128에서 127 사이의 Integer 값에 대해 캐싱을 제공합니다. 이 범위 내에서는 동일한 값을 가지는 Integer 객체가 동일한 메모리 주소를 참조합니다. 따라서 이 범위 내에서는 == 연산자도 true를 반환할 수 있습니다.

Integer x = Integer.valueOf(127);
Integer y = Integer.valueOf(127);

System.out.println(x == y); // true: 같은 객체를 참조

Integer와 int를 비교할 때는 자동 언박싱과 캐싱 메커니즘을 이해하는 것이 중요합니다. 특히 == 연산자와 equals() 메서드를 적절히 사용하는 것이 핵심입니다.

2. Stream API에서의 정렬과 데이터 처리

Java의 Stream API는 컬렉션 데이터를 효율적으로 처리하고, 정렬 작업을 간단하게 수행할 수 있도록 도와줍니다.

Stream에서의 정렬

Stream API에서 정렬을 하려면 sorted() 메서드를 사용합니다. 기본적으로 sorted() 메서드는 자연 순서(natural order)로 정렬합니다. 이때 Integer와 같은 객체를 정렬할 때도 자연 순서대로, 즉 오름차순으로 정렬됩니다. 여기서 int와 Integer 간의 차이점을 이해하는 것이 중요합니다.

기본 정렬:
- Integer 객체를 스트림에서 정렬할 때, sorted() 메서드는 객체 간의 비교를 위해 compareTo() 메서드를 사용합니다. 이때 Integer는 내부적으로 int 값으로 비교를 수행합니다.
- int 값은 기본형으로 단순히 값 자체를 비교하지만, Integer 객체는 자동 언박싱되어 비교됩니다.

List<Integer> numbers = Arrays.asList(3, 1, 4, 1, 5, 9);
List<Integer> sortedNumbers = numbers.stream()
                                     .sorted()
                                     .collect(Collectors.toList());

System.out.println(sortedNumbers); // [1, 1, 3, 4, 5, 9]

기본적으로 sorted()는 Integer 객체의 자연 순서에 따라 오름차순으로 정렬합니다. 이는 내부적으로 int 값으로 자동 언박싱되어 비교가 이루어지기 때문입니다.

사용자 정의 정렬 방식 적용

만약 특정 조건에 따라 커스텀 정렬을 하고 싶다면, Comparator를 사용할 수 있습니다. sorted(Comparator<? super T> comparator) 메서드를 활용하면, 다양한 기준으로 정렬할 수 있습니다.

예시:
- 다음은 Integer를 내림차순으로 정렬하는 예제입니다. 이때도 Integer 객체는 int로 자동 언박싱되어 비교가 이루어집니다.

List<Integer> numbers = Arrays.asList(3, 1, 4, 1, 5, 9);
List<Integer> sortedNumbersDesc = numbers.stream()
                                         .sorted(Comparator.reverseOrder())
                                         .collect(Collectors.toList());

System.out.println(sortedNumbersDesc); // [9, 5, 4, 3, 1, 1]

예시:
- Integer 를 숫자를 정수로 변환한 후, 홀수는 앞에, 짝수는 뒤에 오도록 정렬 하는 예제입니다.

// 숫자를 정수로 변환한 후, 홀수는 앞에, 짝수는 뒤에 오도록 정렬
List<Integer> customSortedNumbers = numbersAsStrings.stream()
        .map(Integer::valueOf)
        .sorted((a, b) -> {
            // 홀수는 앞에, 짝수는 뒤에 오도록 정렬
            if (a % 2 != 0 && b % 2 == 0) {
                return -1; // a가 앞에, b가 뒤에
            } else if (a % 2 == 0 && b % 2 != 0) {
                return 1; // b가 앞에, a가 뒤에
            } else {
                return a.compareTo(b); // 같은 홀수끼리, 같은 짝수끼리는 오름차순 정렬
            }
        })
        .collect(Collectors.toList());

Comparator.reverseOrder()를 사용해 내림차순으로 정렬할 수 있습니다. 이 과정에서도 Integer는 int로 언박싱되어 값 비교가 수행됩니다.

메서드 참조와 Stream

Stream에서 메서드 참조(Method Reference)는 코드의 가독성을 높여줍니다. Integer::parseInt와 같은 정적 메서드 참조를 활용하면, 보다 간결하고 직관적인 코드 작성을 할 수 있습니다. 여기서도 Integer와 int 간의 차이를 이해하는 것이 중요합니다.

정적 메서드 참조 예시:
- 문자열 리스트를 정수 리스트로 변환할 때, Integer::parseInt를 메서드 참조로 사용할 수 있습니다. 이 경우, parseInt는 기본형 int를 반환하기 때문에, 이후 연산에서도 기본형 int로 처리됩니다.

List<String> stringNumbers = Arrays.asList("1", "2", "3");
List<Integer> intNumbers = stringNumbers.stream()
                                        .map(Integer::parseInt)
                                        .collect(Collectors.toList());

System.out.println(intNumbers); // [1, 2, 3]

메서드 참조를 사용하면 코드가 더 간결해지며, 기본형 int와 객체형 Integer 간의 변환도 간편해집니다.

️ 복잡한 데이터 구조의 처리

Stream API는 복잡한 데이터 구조를 처리할 때도 강력한 도구입니다. 예를 들어, Map<List<Map<String, Object>>, Object>와 같은 복잡한 구조에서 데이터를 추출하고 정렬하는 작업도 가능합니다. 이때도 Integer와 int 간의 차이점을 고려해야 합니다.

예시:
- 만약 리스트 내의 맵에서 특정 키의 값을 기준으로 정렬하려 한다면, 다음과 같이 구현할 수 있습니다. 이 경우에도 Integer와 int 간의 비교가 자동으로 이루어집니다.

List<Map<String, Object>> dataList = new ArrayList<>();
// 데이터 추가 작업 생략...

List<Map<String, Object>> sortedDataList = dataList.stream()
    .sorted((map1, map2) -> {
        Integer value1 = (Integer) map1.get("keyName");
        Integer value2 = (Integer) map2.get("keyName");
        return value1.compareTo(value2);
    })
    .collect(Collectors.toList());

이와 같이 Stream API를 사용하면 복잡한 데이터 구조도 간결하게 처리하고 정렬할 수 있습니다. 이 과정에서도 Integer 객체는 자동으로 int로 변환되어 값 비교가 수행됩니다.

요약

Stream의 sorted()는 기본적으로 자연 순서로 정렬하며, Comparator를 통해 사용자 정의 정렬을 적용할 수 있습니다.
메서드 참조를 활용하면 코드의 가독성과 간결성을 높일 수 있으며, 기본형 int와 객체형 Integer 간의 자동 변환이 중요합니다.
복잡한 데이터 구조에서도 Stream API는 효과적이며, Integer와 int 간의 차이를 이해하고 사용해야 합니다.

[JAVA] #Deque VS Queue #ArrayDeque VS LinkedList #Map

TaeHuiLee — Fri, 6 Sep 2024 08:00:54 +0900

Java Collection?

Java의 컬렉션 프레임워크는 데이터를 효율적으로 저장하고 조작할 수 있는 다양한 인터페이스와 클래스를 제공합니다. 이 포스트에서는 Deque와 Queue의 성능 차이, ArrayDeque와 LinkedList의 성능 비교, 그리고 Map에서 키를 비교하는 방법에 대해 알아보겠습니다.

Deque와 Queue의 성능 차이

Deque(Double-Ended Queue)와 Queue는 모두 Java에서 큐 자료구조를 구현한 인터페이스입니다. 하지만 이 둘은 기능적 차이뿐만 아니라, 성능 면에서도 약간의 차이가 있습니다.

Queue: 큐는 기본적으로 FIFO(First-In-First-Out) 방식으로 동작하는 자료구조입니다. 가장 많이 사용되는 구현체는 LinkedList와 PriorityQueue입니다. LinkedList는 삽입과 삭제가 O(1) 시간이 소요되는 반면, PriorityQueue는 요소를 정렬해야 하기 때문에 삽입과 삭제에 O(log n) 시간이 소요됩니다.
Deque: Deque는 양방향으로 요소를 삽입하고 삭제할 수 있는 자료구조입니다. ArrayDeque와 LinkedList가 대표적인 구현체입니다. Deque는 양쪽 끝에서의 삽입과 삭제를 O(1) 시간에 처리할 수 있어 Queue보다 유연한 구조를 제공합니다.

Deque와 Queue 성능 비교

Deque와 Queue의 성능 차이는 구현체에 따라 달라집니다. Deque 인터페이스를 구현한 두 가지 대표적인 클래스는 ArrayDeque와 LinkedList입니다. 이제 이 둘의 성능 차이를 살펴보겠습니다.

ArrayDeque: 배열 기반으로 구현되어 있으며, 중간에 요소를 추가하거나 삭제하는 경우 성능이 저하될 수 있습니다. 하지만 끝부분에서의 삽입과 삭제는 매우 빠릅니다(O(1)).
LinkedList: 연결 리스트 기반으로 구현되어 있으며, 양쪽 끝에서의 삽입과 삭제가 O(1)로 빠릅니다. 그러나 메모리 오버헤드가 더 크고, 순차 접근 성능은 ArrayDeque에 비해 떨어집니다.

다음은 ArrayDeque와 LinkedList의 성능을 비교하는 간단한 예제입니다.

Deque<Integer> arrayDeque = new ArrayDeque<>();
Deque<Integer> linkedList = new LinkedList<>();

// ArrayDeque 성능 테스트
long start = System.nanoTime();
for (int i = 0; i < 1000000; i++) {
    arrayDeque.addLast(i);
}
long end = System.nanoTime();
System.out.println("ArrayDeque 삽입 시간: " + (end - start) + " ns");

// LinkedList 성능 테스트
start = System.nanoTime();
for (int i = 0; i < 1000000; i++) {
    linkedList.addLast(i);
}
end = System.nanoTime();
System.out.println("LinkedList 삽입 시간: " + (end - start) + " ns");

위의 테스트에서는 ArrayDeque가 끝부분에서의 삽입/삭제에서 더 나은 성능을 보여줍니다. 하지만 만약 중간 삽입/삭제가 빈번하다면 LinkedList가 더 유리할 수 있습니다.

Map과 키 비교

Java의 Map 인터페이스는 키와 값의 쌍으로 데이터를 저장하는 자료구조입니다. Map에서 키를 비교하는 방법과 성능에 중요한 영향을 미치는 요소들을 살펴보겠습니다.

Map에서 키가 정확히 일치하는지 확인하는 방법

Map에서 키가 정확히 일치하는지 확인하는 방법은 equals() 메서드를 사용하는 것입니다. Map은 내부적으로 키를 비교할 때 equals() 메서드를 호출하여 두 키가 같은지 확인합니다.

equals() 메서드: equals() 메서드는 두 객체가 의미적으로 동일한지 비교합니다. 이 메서드를 오버라이드하여 객체 비교 로직을 커스터마이징할 수 있습니다.

예시:

Map<String, String> map = new HashMap<>();
map.put("key1", "value1");

boolean isEqual = map.containsKey("key1"); // true

위 코드에서 containsKey() 메서드는 내부적으로 equals()를 사용하여 key1이 존재하는지 확인합니다. equals() 메서드가 정확히 구현되어 있다면, 정확한 키 비교가 가능합니다.

Map의 키로 사용된 객체가 동일한지 확인하는 방법

키로 사용된 객체가 동일한지 확인할 때는 equals()와 hashCode() 메서드를 모두 고려해야 합니다.

hashCode() 메서드: hashCode()는 객체를 해시 테이블에 저장할 때 사용되는 정수 값을 반환합니다. 두 객체가 equals() 메서드로 동일한지 판별될 경우, 동일한 hashCode 값을 반환해야 합니다. 그렇지 않으면 해시 충돌이 발생해 성능이 저하될 수 있습니다.
equals()와 hashCode()의 관계: Map은 내부적으로 키를 저장할 때 hashCode()로 해시 값을 생성한 후, equals()로 동일성을 확인합니다. 이 두 메서드를 올바르게 구현하는 것이 중요합니다.

예시:

class Person {
    private String name;
    private int id;

    public Person(String name, int id) {
        this.name = name;
        this.id = id;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Person person = (Person) o;
        return id == person.id && Objects.equals(name, person.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, id);
    }
}

Map<Person, String> personMap = new HashMap<>();
personMap.put(new Person("Alice", 1), "Developer");

boolean exists = personMap.containsKey(new Person("Alice", 1)); // true

위 코드에서 equals()와 hashCode() 메서드를 적절하게 오버라이드하여 동일한 속성 값을 가진 Person 객체들이 같은 키로 인식되도록 했습니다.

정리

Deque와 Queue 성능 차이: Deque는 양방향에서의 삽입과 삭제에 유리하며, ArrayDeque는 메모리 효율성과 끝부분에서의 성능이 뛰어납니다. LinkedList는 중간 삽입/삭제에서 더 좋은 성능을 보일 수 있습니다.
Map과 키 비교: Map에서 키 비교는 equals()와 hashCode() 메서드에 의해 결정됩니다. 올바르게 구현된 equals()와 hashCode()는 Map에서 키로 사용된 객체의 동일성을 정확하게 판단하는 데 필수적입니다.

[JAVA] Java 메서드 참조

TaeHuiLee — Wed, 4 Sep 2024 08:00:16 +0900

Java 메서드 참조

Java에서 메서드 참조(Method Reference)는 람다 표현식을 간결하게 표현할 수 있는 방법입니다. 메서드 참조는 코드의 가독성을 높이고, 불필요한 중복을 줄이는 데 유용하죠. 이번 포스트에서는 메서드 참조의 유형, 메서드 참조의 동작 방식, 그리고 특정 객체의 메서드 참조 사용에 대해 상세하게 설명드리겠습니다.

메서드 참조의 유형

메서드 참조는 네 가지 주요 유형으로 나눌 수 있습니다:

정적 메서드 참조 (Static Method Reference)
인스턴스 메서드 참조 (Instance Method Reference)
특정 객체의 인스턴스 메서드 참조 (Reference to an instance method of a particular object)
생성자 참조 (Constructor Reference)

이제 각 유형이 어떻게 동작하는지 자세히 알아보겠습니다.

Integer::parseInt와 String::toUpperCase

먼저, 정적 메서드 참조와 인스턴스 메서드 참조를 살펴보겠습니다.

Integer::parseInt: 이 메서드 참조는 Integer 클래스의 정적 메서드인 parseInt를 참조합니다. parseInt는 문자열을 정수로 변환하는 작업을 수행합니다.

  Function<String, Integer> parseFunction = Integer::parseInt;
  Integer result = parseFunction.apply("123");
  System.out.println(result); // 123

여기서 Integer::parseInt는 Function<String, Integer> 인터페이스와 매핑됩니다. 이는 입력된 String을 Integer로 변환하는 기능을 합니다. apply 메서드를 호출하면 parseInt 메서드가 실행되어 문자열 "123"이 정수 123으로 변환됩니다.

String::toUpperCase: 이 메서드 참조는 String 클래스의 인스턴스 메서드인 toUpperCase를 참조합니다. 이 메서드는 문자열을 대문자로 변환합니다.

  Function<String, String> upperCaseFunction = String::toUpperCase;
  String result = upperCaseFunction.apply("hello");
  System.out.println(result); // HELLO

여기서 String::toUpperCase는 Function<String, String>과 매핑되어, 입력된 문자열을 대문자로 변환합니다. 이 메서드 참조는 어떤 특정 인스턴스에 묶여 있지 않으며, 입력되는 문자열의 toUpperCase 메서드를 호출하게 됩니다.

정적 메서드 참조, 인스턴스 메서드 참조, 생성자 참조의 차이점

이제 메서드 참조의 유형별 차이점을 살펴보겠습니다.

정적 메서드 참조 (ClassName::methodName): 클래스의 정적 메서드를 참조합니다. 이 참조는 클래스 자체에 대해 정적으로 정의된 메서드를 대상으로 합니다.

Function<String, Integer> parseInt = Integer::parseInt;

여기서 Integer::parseInt는 Integer 클래스에 정적으로 정의된 parseInt 메서드를 참조합니다. 이 메서드는 String을 받아서 Integer로 변환합니다.

인스턴스 메서드 참조 (ClassName::methodName): 특정 인스턴스에 의존하지 않고, 전달된 인스턴스의 메서드를 참조합니다. 이 참조는 인스턴스 메서드이지만, 클래스 이름으로 참조되며, 실제로는 메서드가 호출될 때 전달된 객체의 메서드를 실행합니다.

  Function<String, String> upperCase = String::toUpperCase;

String::toUpperCase는 전달된 String 객체의 toUpperCase 메서드를 호출합니다. 여기서 upperCase 함수는 입력된 문자열을 대문자로 변환하는 역할을 합니다.

특정 객체의 인스턴스 메서드 참조 (instance::methodName): 특정 객체의 메서드를 참조합니다. 이 유형의 메서드 참조는 미리 정의된 객체의 메서드를 대상으로 합니다.

  String prefix = "Hello, ";
  Function<String, String> greeting = prefix::concat;
  String result = greeting.apply("World");
  System.out.println(result); // Hello, World

여기서 prefix::concat은 prefix라는 특정 String 객체의 concat 메서드를 참조합니다. 이 메서드 참조는 greeting.apply("World")가 호출될 때 prefix.concat("World")가 실행되는 방식으로 동작합니다.

생성자 참조 (ClassName::new): 클래스의 생성자를 참조하여 새로운 객체를 만듭니다. 이 참조는 기본 생성자 또는 매개변수가 있는 생성자와 연결될 수 있습니다.

  Supplier<List<String>> listSupplier = ArrayList::new;
  List<String> list = listSupplier.get();

ArrayList::new는 ArrayList의 기본 생성자를 참조하며, get() 메서드를 호출하면 새로운 ArrayList 인스턴스가 생성됩니다. Supplier 인터페이스와 함께 사용되어, new ArrayList<>()와 동일한 효과를 제공합니다.

메서드 참조의 동작 방식

메서드 참조는 람다 표현식의 간결한 대체물로 작동하며, Java 컴파일러는 이를 분석하여 적절한 메서드 또는 생성자를 호출합니다. 컴파일러가 어떻게 메서드 참조를 해석하고 작동하는지 이해해 봅시다.

정적 메서드 참조: 컴파일러는 클래스명과 메서드명이 명시된 경우 이를 정적 메서드로 인식합니다. 예를 들어 Integer::parseInt는 Integer 클래스의 정적 메서드인 parseInt로 매핑됩니다.이 경우 parseInt는 특정 인스턴스 없이 호출될 수 있습니다. 컴파일러는 Integer::parseInt가 Function<String, Integer>과 같은 인터페이스에 맞는 메서드라는 점을 인식하고 이를 사용합니다.
Function<String, Integer> parseInt = Integer::parseInt;
인스턴스 메서드 참조: 클래스명만 지정된 경우, 메서드 참조는 전달된 객체의 인스턴스 메서드를 참조하는 것으로 해석됩니다. 이 경우, 컴파일러는 메서드 참조가 특정 객체의 인스턴스 메서드로 적용될 수 있는지를 판단합니다.컴파일러는 String::toUpperCase가 String 객체에서 호출 가능한 인스턴스 메서드라는 점을 인식합니다.
Function<String, String> upperCase = String::toUpperCase;
특정 객체의 인스턴스 메서드 참조: 특정 객체가 주어지고 그 객체의 메서드가 참조되는 경우, 해당 객체의 메서드가 참조됩니다. 이는 메서드 참조가 어떤 객체에 속한 메서드인지를 컴파일러가 직접 판단하게 됩니다.컴파일러는 greeting::concat이 특정 greeting 객체의 concat 메서드를 참조한다는 것을 인식합니다. 이 참조는 concatFunction.apply("World")가 호출될 때 greeting.concat("World")를 수행하게 됩니다.
String greeting = "Hello, "; Function<String, String> concatFunction = greeting::concat;
생성자 참조: 클래스명과 new 키워드가 지정된 경우, 이를 생성자 참조로 인식합니다. 컴파일러는 생성자가 호출될 때 어떤 매개변수가 필요한지를 확인하고, 적절한 생성자를 선택합니다.여기서 ArrayList::new는 ArrayList의 기본 생성자를 참조하며, 컴파일러는 Supplier<List<String>> 인터페이스에 맞게 이 참조를 사용합니다.
Supplier<List<String>> listSupplier = ArrayList::new;

특정 객체의 메서드 참조

특정 객체의 인스턴스 메서드를 Stream에서 메서드 참조로 사용할 수 있습니다. 이는 특정 객체를 대상으로 메서드를 호출해야 하는 경우 유용하게 사용됩니다. 이 경우 메서드 참조는 주로 람다 표현식의 대안으로 사용되며, 간결하고 가독성 높은 코드를 작성할 수 있게 해줍니다.

예시:

List<String> messages = Arrays.asList("Hello", "World");
String prefix = "Message: ";
messages.stream()
        .map(prefix::concat)  // prefix 객체의 concat 메서드 참조
        .forEach(System.out::println);
// 출력: Message: Hello, Message: World

이 예제에서는 prefix::concat을 사용하여 Stream의 각 요소에 대해 concat 메서드를 호출합니다. prefix 객체에 대해 concat 메서드가 호출되어, 각 메시지에 "Message: "라는 접두어가 추가됩니다. 이처럼 특정 객체의 메서드 참조는 Stream API와 결합하여 매우 강력한 기능을 발휘할 수 있습니다.

정리

메서드 참조 유형: 정적 메서드 참조, 인스턴스 메서드 참조, 특정 객체의 인스턴스 메서드 참조, 생성자 참조의 네 가지 주요 유형이 있습니다.
메서드 참조 동작 방식: Java 컴파일러는 메서드 참조를 분석하여, 적절한 메서드나 생성자를 자동으로 선택하고 실행합니다. 이 과정에서 메서드 참조가 어떤 유형에 속하는지 판단하며, 적절한 함수형 인터페이스에 맞춰 실행합니다.
특정 객체의 메서드 참조: Stream에서 특정 객체의 메서드 참조를 사용하면, 각 요소에 대해 해당 객체의 메서드를 간편하게 호출할 수 있습니다. 이는 코드의 가독성을 높이고, 중복을 줄이는 데 도움이 됩니다.

[JAVA] Java Stream API 활용법

TaeHuiLee — Mon, 2 Sep 2024 08:00:03 +0900

1. Java Stream API 활용법

Java의 Stream API는 데이터 처리를 정말 편리하게 해주는 도구입니다. 데이터를 필터링, 매핑, 정렬, 수집하는 작업을 간단하게 할 수 있죠. 여기서 Stream을 어떻게 활용할 수 있는지, map과 mapToInt의 차이점, Collectors의 사용법, 그리고 복잡한 구조를 Stream으로 처리하는 방법에 대해 알아보겠습니다.

Stream 활용법: 기본적인 사용 방법

Stream은 컬렉션(예: List, Set, Map)이나 배열의 데이터를 순차적으로 처리할 수 있는 기능입니다. 이를 활용하면 반복문 없이 간단하게 데이터를 조작할 수 있습니다.

List<String> names = Arrays.asList("Alice", "Bob", "Charlie");

// 스트림을 사용한 필터링과 매핑
List<String> filteredNames = names.stream()
                                  .filter(name -> name.startsWith("A"))
                                  .map(String::toUpperCase)
                                  .collect(Collectors.toList());

System.out.println(filteredNames); // [ALICE]

map과 mapToInt의 차이점

map과 mapToInt는 모두 스트림에서 요소를 변환하는 역할을 합니다. 하지만 중요한 차이점이 있습니다.

map: 모든 타입의 Stream을 변환할 수 있습니다. 예를 들어, Stream<String>을 Stream<Integer>로 변환할 수 있죠.
mapToInt: 정수형 스트림(IntStream)으로 변환합니다. 그래서 주로 숫자 연산이 필요할 때 사용됩니다.

List<String> numbers = Arrays.asList("1", "2", "3");

// map 예시: String -> Integer 변환
List<Integer> intNumbers = numbers.stream()
                                  .map(Integer::parseInt)
                                  .collect(Collectors.toList());

// mapToInt 예시: String -> int 변환
int sum = numbers.stream()
                 .mapToInt(Integer::parseInt)
                 .sum();

System.out.println(sum); // 6

Collectors와 Stream 관련

Stream의 결과를 원하는 형태로 수집하려면 Collectors를 사용합니다. 여기서는 Collectors.toList()와 Collectors.toCollection()의 차이점, 그리고 Stream을 사용해 List를 Deque나 Queue로 변환하는 방법을 살펴보겠습니다.

Collectors.toList()와 Collectors.toCollection()의 차이점

Collectors.toList(): Stream의 결과를 List로 수집합니다. 기본적인 리스트로 변환할 때 사용하죠.
Collectors.toCollection(): Stream의 결과를 원하는 컬렉션 타입으로 수집할 수 있습니다. 예를 들어, Deque, Queue, 또는 PriorityQueue 같은 특정 컬렉션으로 변환할 수 있습니다.

Deque<String> deque = names.stream()
                           .collect(Collectors.toCollection(ArrayDeque::new));

PriorityQueue<String> priorityQueue = names.stream()
                                           .collect(Collectors.toCollection(PriorityQueue::new));

이렇게 하면 Stream의 요소들을 Deque나 PriorityQueue 같은 컬렉션으로 쉽게 변환할 수 있습니다.

중첩된 구조의 처리

Stream을 사용하면 복잡한 구조도 효율적으로 처리할 수 있습니다. 예를 들어, Map<List<Map<String, Object>>, Object> 같은 복잡한 구조에서도 특정 값을 가져올 수 있습니다.

Map<List<Map<String, Object>>, Object> complexMap = // 초기화된 복잡한 구조
// 특정 값을 가져오는 예시
Optional<Object> result = complexMap.entrySet().stream()
                                    .flatMap(entry -> entry.getKey().stream())
                                    .filter(innerMap -> "특정 키".equals(innerMap.get("key")))
                                    .map(innerMap -> innerMap.get("value"))
                                    .findFirst();

이 코드는 중첩된 구조에서 원하는 값을 효율적으로 추출할 수 있게 해줍니다.

정리

Stream: 데이터를 필터링, 매핑, 수집하는데 유용하게 사용됩니다.
map과 mapToInt: map은 타입 변환, mapToInt는 숫자 연산에 특화된 기능입니다.
Collectors: Stream의 결과를 다양한 컬렉션 형태로 수집할 수 있습니다.
복잡한 구조: Stream을 통해 복잡한 데이터 구조에서도 원하는 값을 쉽게 찾을 수 있습니다.

[JavaScript] JavaScript의 비동기 처리 이해하기

TaeHuiLee — Sun, 25 Aug 2024 14:53:47 +0900

1. JavaScript의 비동기 처리 이해하기

JavaScript는 싱글 스레드로 동작해요. 즉, 한 번에 하나의 작업만 처리할 수 있다는 뜻이죠. 그런데도 여러 비동기 작업을 동시에 처리하는 것처럼 보이는 이유는 JavaScript의 이벤트 루프(Event Loop) 덕분이에요. 자, 이 과정이 어떻게 이루어지는지 차근차근 설명해보겠습니다.

JavaScript는 싱글 스레드인데 비동기 작업을 어떻게 처리할까요?

JavaScript는 비동기 작업을 처리하기 위해 이벤트 루프와 태스크 큐라는 개념을 사용합니다.

비동기 함수 호출: 비동기 함수(예: setTimeout, fetch, async/await)가 호출되면, 그 작업은 브라우저나 Node.js의 백그라운드에서 처리돼고, 이때 JavaScript는 다른 코드를 계속해서 실행할 수 있습니다.

console.log("Start");

setTimeout(() => {
  console.log("Inside setTimeout");
}, 2000);

console.log("End");

위 코드에서는 setTimeout이 호출되었지만, JavaScript는 이 작업을 백그라운드에서 처리하고 console.log("End")를 먼저 실행한 후, 2초 후에 비동기 작업이 완료되면 "Inside setTimeout"이 출력됩니다.

태스크 큐(Task Queue): 비동기 작업이 완료되면, 그 결과는 태스크 큐에 들어갑니다.

setTimeout(() => {
  console.log("First task");
}, 1000);

setTimeout(() => {
  console.log("Second task");
}, 500);

console.log("Synchronous task");

이 예시에서는 500ms 후에 "Second task"가, 1000ms 후에 "First task"가 출력되는데, 그 전에 "Synchronous task"가 먼저 출력돼요. 이처럼 태스크 큐는 작업이 완료된 순서대로 큐에 저장됩니다.

이벤트 루프(Event Loop): 이벤트 루프는 콜 스택이 비어 있을 때, 태스크 큐에 있는 작업을 콜 스택으로 옮겨와 실행합니다.

비동기 함수 내부에서 `await`를 사용하면 콜 스택과의 관계는 어떻게 되나요?

await는 비동기 함수 내에서 특정 작업이 완료될 때까지 기다리도록 만드는 키워드입니다.

await를 만나면 JavaScript는 해당 비동기 작업이 완료될 때까지 기다리지 않고, 함수의 실행을 일시 중지합니다.
이 동안, 다른 코드가 실행될 수 있도록 콜 스택을 비워둡니다.
비동기 작업이 완료되면, 그 작업은 태스크 큐에 들어가고, 이벤트 루프가 이 태스크를 콜 스택으로 옮겨 실행을 재개합니다.

async function fetchData() {
  console.log("Fetching data...");

  const response = await fetch("https://api.example.com/data");
  const data = await response.json();

  console.log("Data received:", data);
}

console.log("Before fetch");
fetchData();
console.log("After fetch");

이 코드에서는 fetchData 함수 내에서 await가 호출될 때 JavaScript는 일시적으로 함수 실행을 중지하고, 나머지 코드 (console.log("After fetch"))를 먼저 실행해요. 이후, 데이터가 받아지면 "Data received:"와 함께 출력돼요.

비동기 작업이 완료된 후 태스크 큐로 결과가 전달되는 과정은 어떻게 이루어지나요?

비동기 작업이 완료되면, 그 결과는 태스크 큐에 저장돼요. 이 과정은 다음과 같습니다.

백그라운드 작업 완료: 비동기 함수로 백그라운드에서 처리된 작업이 완료되면, 그 결과는 태스크 큐에 들어갑니다.
이벤트 루프: 이벤트 루프는 콜 스택이 비었을 때 태스크 큐에서 작업을 가져와서 콜 스택으로 옮겨옵니다.
작업 실행: 이 태스크는 콜 스택에서 실행되고, 그 결과가 반영됩니다.

console.log("Start");

setTimeout(() => {
  console.log("First task");
}, 1000);

setTimeout(() => {
  console.log("Second task");
}, 500);

console.log("End");

이 코드에서는 "Second task"가 태스크 큐에 먼저 들어가고, 그 다음 "First task"가 들어갑니다. 이벤트 루프는 콜 스택이 비었을 때 태스크 큐에서 "Second task"를 먼저 가져와 실행합니다.

비동기 작업과 이벤트 루프의 역할

비동기 작업이 수행될 때, JavaScript는 해당 작업을 브라우저의 백그라운드로 넘기고, 다른 작업을 계속 수행할 수 있습니다. 이 과정에서 이벤트 루프는 다음과 같은 중요한 역할을 합니다:

백그라운드에서 작업 처리: 비동기 작업이 백그라운드에서 완료되면, 그 결과는 태스크 큐에 전달됩니다.
이벤트 루프가 주도권을 가져옴: 이벤트 루프는 콜 스택이 비었을 때, 태스크 큐에 있는 작업을 콜 스택으로 가져와 실행해합니다. 이때 비동기 작업의 결과도 처리됩니다.
결과 처리: 비동기 작업이 완료된 후, 이벤트 루프가 이를 JavaScript 엔진으로 돌려줘서 후속 작업을 이어가게 합니다.

`mounted` 훅에서 여러 비동기 작업이 순차적으로 실행되지 않는 이유는 무엇인가요?

mounted 훅에서 비동기 작업을 실행하면, 이 작업들은 병렬로 실행됩니다. 이는 각 비동기 작업이 별도로 시작되기 때문입니다. 만약 순차적으로 실행하고 싶다면, await 키워드를 사용하거나 Promise 체이닝을 해야 합니다.

async mounted() {
  await this.fetchData1();
  await this.fetchData2();
  await this.fetchData3();
}

위 코드처럼 await를 사용하면, 첫 번째 작업이 끝날 때까지 기다린 후 다음 작업이 실행됩니다. 하지만 await를 사용하지 않으면 모든 작업이 동시에 시작됩니다.

mounted() {
  this.fetchData1();
  this.fetchData2();
  this.fetchData3();
}

이 경우, fetchData1, fetchData2, fetchData3는 동시에 호출되고 병렬로 실행됩니다.

콜 스택, 태스크 큐, 마이크로태스크 큐 모두 하나의 스레드에서 처리가 가능한가요?

맞아요! 콜 스택, 태스크 큐, 그리고 마이크로태스크 큐는 모두 하나의 스레드에서 처리됩니다. JavaScript는 싱글 스레드 언어이기 때문에, 이 모든 작업이 한 줄로 정리된 하나의 스레드에서 실행됩니다.

태스크 큐와 마이크로태스크 큐도 결과를 저장하는 곳인가요?

엄밀히 말하면, 태스크 큐와 마이크로태스크 큐는 결과를 저장하는 곳이라기보다는, 실행 대기 중인 작업들을 보관하는 곳입니다. 비동기 작업이 완료되면 이 큐에 작업이 들어가고, 이벤트 루프가 이를 콜 스택으로 가져와 실행합니다.

Promise.resolve().then(() => {
  console.log("Microtask 1");
});

setTimeout(() => {
  console.log("Task");
}, 0);

Promise.resolve().then(() => {
  console.log("Microtask 2");
});

console.log("Synchronous task");

이 예시에서 "Microtask 1"과 "Microtask 2"는 마이크로태스크 큐에 들어가고, "Task"는 태스크 큐에 들어가요. 콜 스택이 비면 마이크로태스크가 먼저 실행되고, 그 다음 태스크가 실행합니다.

태스크 큐는 선입선출, 콜 스택은 후입선출 방식으로 동작하나요?

네, 맞아요!

태스크 큐는 선입선출(FIFO) 방식으로 동작해요. 먼저 들어온 작업이 먼저 실행됩니다.
콜 스택은 후입선출(LIFO) 방식으로 동작해요. 마지막에 들어온 작업이 먼저 실행됩니다.

function example() {
  function inner() {
    console.log("Inner function");
  }

  console.log("Before inner");
  inner();
  console.log("After inner");
}

example();

위 코드에서 example()이 호출되면, example 함수가 콜 스택에 쌓이고, 그 안에서 inner()가 호출되면 inner 함수가 콜 스택에 추가고, inner 함수가 실행된 후 스택에서 빠지고, 그 다음 example 함수가 완료됩니다.

`mounted`에서 여러 함수를 호출할 때, 함수들이 콜 스택에 한 번에 쌓이는 게 아니라 하나씩 처리 후 다시 쌓이나요? 함수 내에 함수가 있을 때만 스택에 넣나요?

mounted에서 여러 함수를 호출하면, 각 함수 호출이 순차적으로 콜 스택에 쌓이고 하나씩 처리됩. 함수 내에 또 다른 함수가 있다면, 그 함수가 콜 스택에 추가로 쌓이게 됩니다.

function outer() {
  console.log("Outer function start");

  function inner() {
    console.log("Inner function");
  }

  inner();
  console.log("Outer function end");
}

outer();

이 예시에서 outer()가 호출되면, outer 함수가 콜 스택에 쌓이고, 그 안에서 inner()가 호출되면 inner 함수가 콜 스택에 쌓입니다. inner가 먼저 실행되고, 완료되면 스택에서 빠지고, 그 다음 outer 함수가 완료됩니다.

요약

JavaScript는 싱글 스레드지만, 이벤트 루프와 태스크 큐를 이용해 비동기 작업을 효율적으로 처리한다.
await를 사용하면 콜 스택이 비동기 작업이 완료될 때까지 기다리지 않고 비워질 수 있다.
비동기 작업이 완료되면 결과는 태스크 큐에 저장되고, 이벤트 루프가 이를 처리한다.
이벤트 루프는 비동기 작업의 완료를 감지하고, 그 결과를 콜 스택에 전달한다.
mounted에서 여러 비동기 작업을 순차적으로 실행하려면 await를 사용해야 한다.
콜 스택, 태스크 큐, 마이크로태스크 큐는 모두 하나의 스레드에서 처리된다.
태스크 큐는 선입선출, 콜 스택은 후입선출 방식으로 동작한다.

[JavaScript] Array에서 특정 데이터 개수 구하기 #reduce

TaeHuiLee — Mon, 12 Aug 2024 15:17:52 +0900

JavaScript에서 카테고리별 개수 정렬하기

네, JavaScript에서 객체를 생성한 후에 카테고리별 개수를 정렬할 수 있습니다. 객체 자체는 순서를 가지지 않지만, 객체의 키-값 쌍을 배열로 변환한 후 배열을 정렬하면 원하는 대로 데이터를 정리할 수 있죠.

아래는 카테고리별 개수를 구한 후, 그 결과를 카테고리 이름이나 개수에 따라 정렬하는 방법입니다.

1. 카테고리별 개수 구하기

먼저, 카테고리별로 개수를 집계해야 합니다. 다음은 예시 코드입니다:

const items = [
  { id: 1, category: 'fruit', name: 'apple' },
  { id: 2, category: 'vegetable', name: 'carrot' },
  { id: 3, category: 'fruit', name: 'banana' },
  { id: 4, category: 'fruit', name: 'orange' },
  { id: 5, category: 'vegetable', name: 'broccoli' },
  { id: 6, category: 'grain', name: 'rice' },
];

const categoryCounts = items.reduce((acc, item) => {
  acc[item.category] = (acc[item.category] || 0) + 1;
  return acc;
}, {});

console.log('Category Counts:', categoryCounts);

이 코드는 items 배열에서 카테고리별로 항목 개수를 계산합니다. reduce 메서드를 사용해 categoryCounts 객체를 만들었죠.

2. 객체를 배열로 변환 후 정렬

객체는 기본적으로 순서를 가지지 않기 때문에 정렬하려면 먼저 Object.entries()를 사용해 배열로 변환해야 합니다. 변환한 배열은 sort() 메서드를 사용해 정렬할 수 있습니다.

2.1 카테고리 이름 기준으로 정렬

카테고리 이름을 알파벳 순으로 정렬하려면 다음과 같이 하면 됩니다:

const sortedByCategory = Object.entries(categoryCounts).sort((a, b) => {
  return a[0].localeCompare(b[0]);
});

console.log('Sorted by Category Name:', sortedByCategory);

2.2 개수 기준으로 정렬

카테고리별 항목 개수(내림차순)로 정렬하려면 이렇게 할 수 있습니다:

const sortedByCount = Object.entries(categoryCounts).sort((a, b) => {
  return b[1] - a[1];
});

console.log('Sorted by Count:', sortedByCount);

3. 정렬 결과 출력

정렬 결과는 배열로 반환됩니다. 각 배열의 요소는 [category, count] 형태로 이루어져 있죠.

만약 정렬된 결과를 다시 객체 형태로 변환하고 싶다면, Object.fromEntries()를 사용하면 됩니다:

const sortedCategoryCounts = Object.fromEntries(sortedByCount);
console.log('Sorted Category Counts Object:', sortedCategoryCounts);

전체 코드 예제

전체 코드는 다음과 같이 구성됩니다:

const items = [
  { id: 1, category: 'fruit', name: 'apple' },
  { id: 2, category: 'vegetable', name: 'carrot' },
  { id: 3, category: 'fruit', name: 'banana' },
  { id: 4, category: 'fruit', name: 'orange' },
  { id: 5, category: 'vegetable', name: 'broccoli' },
  { id: 6, category: 'grain', name: 'rice' },
];

const categoryCounts = items.reduce((acc, item) => {
  acc[item.category] = (acc[item.category] || 0) + 1;
  return acc;
}, {});

const sortedByCategory = Object.entries(categoryCounts).sort((a, b) => {
  return a[0].localeCompare(b[0]);
});

const sortedByCount = Object.entries(categoryCounts).sort((a, b) => {
  return b[1] - a[1];
});

console.log('Sorted by Category Name:', sortedByCategory);
console.log('Sorted by Count:', sortedByCount);

// 정렬된 결과를 객체로 변환
const sortedCategoryCounts = Object.fromEntries(sortedByCount);
console.log('Sorted Category Counts Object:', sortedCategoryCounts);

✨ 요약

객체는 기본적으로 순서를 가지지 않기 때문에 정렬하려면 Object.entries()를 사용해 배열로 변환해야 한다.
배열로 변환한 후 sort() 메서드를 사용해 카테고리 이름이나 개수에 따라 정렬할 수 있다.
정렬된 결과는 배열 형태로 사용하거나 다시 객체로 변환할 수 있다.

[DB] DB Table Key의 종류

TaeHuiLee — Wed, 7 Aug 2024 08:00:26 +0900

1. DB Table 생성할 때 Key의 종류

데이터베이스 테이블을 설계할 때, 키(key)는 매우 중요한 역할을 합니다. 각 키의 종류와 그 사용 이유, 그리고 예시 코드를 통해 쉽게 이해해보시죠.

1.1 후보키 (Candidate Key)

후보키는 테이블 내의 튜플을 고유하게 식별할 수 있는 속성(또는 속성들의 집합)을 의미합니다. 하나의 테이블에는 여러 개의 후보키가 존재할 수 있습니다. 후보키는 반드시 최소성을 만족해야 합니다.

예시:

학생 테이블에서 학번과 주민등록번호는 각각 학생을 고유하게 식별할 수 있는 후보키가 될 수 있습니다.
또한, 이름과 생년월일의 조합도 고유하게 식별할 수 있다면 후보키가 될 수 있습니다.

CREATE TABLE Student (
    student_id INT,
    name VARCHAR(50),
    ssn CHAR(13),
    birth_date DATE,
    PRIMARY KEY (student_id),
    UNIQUE (ssn),
    UNIQUE (name, birth_date)
);

1.2 기본키 (Primary Key)

기본키는 후보키 중에서 선택된 키로, 테이블 내의 각 행을 고유하게 식별합니다. 기본키는 null 값을 가질 수 없고, 중복될 수 없습니다.

예시:

Student 테이블에서 student_id가 기본키로 선택되었습니다.

CREATE TABLE Student (
    student_id INT PRIMARY KEY,
    name VARCHAR(50),
    ssn CHAR(13) UNIQUE,
    birth_date DATE,
    UNIQUE (name, birth_date)
);

1.3 참조키 (Foreign Key)

참조키는 다른 테이블의 기본키를 참조하는 키입니다. 두 테이블 간의 관계를 정의할 때 사용됩니다. 참조키는 참조하는 테이블에서 고유성을 가지지만, 참조하는 테이블에서는 반드시 유일성을 가질 필요는 없습니다.

예시:

Enrollment 테이블에서 student_id는 Student 테이블의 student_id를 참조합니다.

CREATE TABLE Enrollment (
    enrollment_id INT PRIMARY KEY,
    student_id INT,
    course_id INT,
    FOREIGN KEY (student_id) REFERENCES Student(student_id),
    FOREIGN KEY (course_id) REFERENCES Course(course_id)
);

1.4 대체키 (Alternate Key)

대체키는 후보키 중 기본키로 선택되지 않은 나머지 키들을 의미합니다. 대체키도 테이블 내에서 고유성을 유지합니다.

예시:

Student 테이블에서 ssn이 대체키로 사용될 수 있습니다.

CREATE TABLE Student (
    student_id INT PRIMARY KEY,
    name VARCHAR(50),
    ssn CHAR(13) UNIQUE,
    birth_date DATE,
    UNIQUE (name, birth_date)
);

1.5 슈퍼키 (Super Key)

슈퍼키는 테이블 내의 튜플을 고유하게 식별할 수 있는 하나 이상의 속성의 집합을 의미합니다. 여기에는 후보키와 기본키도 포함됩니다.

특징:
- 슈퍼키는 최소한의 조건을 요구하지 않기 때문에 불필요한 속성을 포함할 수 있습니다.
- 모든 후보키와 기본키는 슈퍼키에 포함됩니다.
- 단, 슈퍼키는 반드시 유일성을 보장해야 합니다.

예시:

학생 테이블 Student에서 (student_id, name), (student_id, ssn), (ssn, name) 등은 모두 슈퍼키가 될 수 있습니다. 이 예시들은 각각 학생을 고유하게 식별할 수 있기 때문입니다.

CREATE TABLE Student (
    student_id INT PRIMARY KEY,
    name VARCHAR(50),
    ssn CHAR(13) UNIQUE,
    birth_date DATE,
    UNIQUE (name, birth_date)
);

2. 예시 데이터를 이용한 상세 설명

위의 테이블 구조를 기준으로 예시 데이터를 넣어보겠습니다.

INSERT INTO Student (student_id, name, ssn, birth_date) VALUES (1, 'Alice', '900101-1234567', '1990-01-01');
INSERT INTO Student (student_id, name, ssn, birth_date) VALUES (2, 'Bob', '900202-2345678', '1990-02-02');

Student 테이블에 두 명의 학생 데이터가 들어갔습니다.
각 학생은 student_id로 고유하게 식별됩니다.

INSERT INTO Course (course_id, course_name) VALUES (1, 'Database Systems');
INSERT INTO Course (course_id, course_name) VALUES (2, 'Operating Systems');

Course 테이블에 두 개의 과목이 추가되었습니다.

INSERT INTO Enrollment (enrollment_id, student_id, course_id) VALUES (1, 1, 1);
INSERT INTO Enrollment (enrollment_id, student_id, course_id) VALUES (2, 2, 2);

Enrollment 테이블에 학생과 과목의 등록 정보가 추가되었습니다.
student_id와 course_id는 각각 Student 테이블과 Course 테이블을 참조하고 있습니다.

3. 슈퍼키와 후보키의 차이

슈퍼키 (Super Key)

슈퍼키는 하나 이상의 속성(attribute)의 집합으로, 테이블 내의 모든 행을 고유하게 식별할 수 있습니다. 즉, 특정 속성 집합이 슈퍼키라면, 그 속성 집합을 이용해 각 행을 유일하게 구분할 수 있어야 합니다.

특징:
- 슈퍼키는 최소한의 조건을 요구하지 않기 때문에 불필요한 속성을 포함할 수 있습니다.
- 모든 후보키와 기본키는 슈퍼키에 포함됩니다.
- 단, 슈퍼키는 반드시 유일성을 보장해야 합니다.

예시:

CREATE TABLE Student (
    student_id INT PRIMARY KEY,
    name VARCHAR(50),
    ssn CHAR(13) UNIQUE,
    birth_date DATE,
    UNIQUE (name, birth_date)
);

후보키 (Candidate Key)

후보키는 슈퍼키의 부분집합으로, 최소의 속성 집합으로 테이블 내의 모든 행을 고유하게 식별할 수 있습니다. 후보키는 중복되는 속성이 없어야 하고, 유일성을 유지해야 합니다.

특징:
- 후보키는 슈퍼키와 달리 중복된 속성을 포함하지 않는 최소 집합이어야 합니다.
- 하나의 테이블에는 여러 개의 후보키가 존재할 수 있습니다.
- 후보키 중 하나는 기본키로 선택됩니다.

예시:

Student 테이블에서 student_id와 ssn은 각각 후보키가 될 수 있습니다. 이 두 속성은 각각 학생을 고유하게 식별할 수 있는 최소의 속성 집합이기 때문입니다.

CREATE TABLE Student (
    student_id INT PRIMARY KEY,
    name VARCHAR(50),
    ssn CHAR(13) UNIQUE,
    birth_date DATE,
    UNIQUE (name, birth_date)
);

또한, name과 birth_date의 조합도 유일성을 만족할 경우 후보키가 될 수 있습니다.

CREATE TABLE Student (
    student_id INT PRIMARY KEY,
    name VARCHAR(50),
    ssn CHAR(13) UNIQUE,
    birth_date DATE,
    UNIQUE (name, birth_date)
);

슈퍼키와 후보키의 차이 요약

슈퍼키는 테이블 내의 모든 행을 고유하게 식별할 수 있는 하나 이상의 속성의 집합입니다. 불필요한 속성을 포함할 수 있습니다.
후보키는 슈퍼키의 최소 부분집합으로, 테이블 내의 모든 행을 고유하게 식별할 수 있는 최소한의 속성 집합입니다. 불필요한 속성을 포함하지 않습니다.

4. 요약

후보키 (Candidate Key): 튜플을 고유하게 식별할 수 있는 키.
기본키 (Primary Key): 후보키 중 하나를 선택하여 설정, null 값과 중복 불가.
참조키 (Foreign Key): 다른 테이블의 기본키를 참조하여 테이블 간의 관계 설정. 참조키 자체는 반드시 유일할 필요는 없습니다.
대체키 (Alternate Key): 후보키 중 기본키로 선택되지 않은 나머지 키.
슈퍼키 (Super Key): 테이블 내 튜플을 고유하게 식별할 수 있는 모든 속성의 집합.

이제 키의 종류와 사용 방법을 잘 이해하셨나요? 데이터베이스 설계 시 이러한 키들을 적절히 활용하면

[JAVA] 자바 버전별 차이점

TaeHuiLee — Fri, 2 Aug 2024 00:39:16 +0900

1. 자바 버전별 차이점

자바는 꾸준한 업데이트를 통해 많은 변화와 개선을 거쳐왔습니다. 버전별로 어떤 차이점이 있는지 알아보겠습니다. 주요 버전으로는 Java 8, Java 9, Java 10, Java 11, Java 12, Java 13, Java 14, Java 15, Java 16, Java 17이 있습니다. 여기서 각 버전별로 주요 특징과 차이점을 설명하겠습니다.

Java 8

주요 특징
- 람다 표현식(Lambda Expressions)
- 스트림 API (Stream API)
- 기본 메소드 (Default Methods)
- java.time 패키지 (새로운 날짜와 시간 API)
장점
- 코드가 간결해지고, 멀티코어 프로세서를 효율적으로 사용할 수 있습니다.
- 새로운 날짜와 시간 API는 훨씬 직관적이고 사용하기 쉽습니다.
단점
- 새로운 기능들이 익숙하지 않아서 초기 학습 비용이 필요합니다.
예시 코드

import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;

public class Java8Example {
    public static void main(String[] args) {
        // 람다 표현식을 이용한 리스트 필터링
        List<String> names = Arrays.asList("Alice", "Bob", "Charlie", "David");
        List<String> filteredNames = names.stream()
                                          .filter(name -> name.startsWith("A"))
                                          .collect(Collectors.toList());
        System.out.println(filteredNames);

        // 새로운 날짜와 시간 API 사용
        LocalDate today = LocalDate.now();
        LocalDate birthday = LocalDate.of(1990, Month.JANUARY, 1);
        Period p = Period.between(birthday, today);
        System.out.println("You are " + p.getYears() + " years old.");
    }
}

Java 9

주요 특징
- 모듈 시스템 (Module System)
- JShell (REPL)
- 스트림 API 개선
- 새로운 HTTP 클라이언트
장점
- 대규모 애플리케이션의 모듈화가 쉬워졌습니다.
- JShell을 통해 빠른 테스트와 프로토타이핑이 가능합니다.
단점
- 모듈 시스템에 대한 적응이 필요합니다.
- 기존 프로젝트를 새로운 모듈 시스템에 맞게 변경하는 데 시간이 걸릴 수 있습니다.
예시 코드

module com.example.myapp {
    requires java.base;
    requires java.sql;
}

// JShell 예시 (터미널에서 실행)
jshell> int sum(int a, int b) {
...>     return a + b;
...> }
jshell> sum(5, 3)

Java 10

주요 특징
- 지역 변수 타입 추론 (Local-Variable Type Inference)
- G1 가비지 컬렉터 성능 개선
장점
- var 키워드를 사용하여 코드 가독성을 높일 수 있습니다.
- G1 가비지 컬렉터가 더욱 효율적으로 개선되었습니다.
단점
- var 키워드 사용 시 타입 추론에 주의가 필요합니다.
예시 코드

import java.util.List;

public class Java10Example {
    public static void main(String[] args) {
        var numbers = List.of(1, 2, 3, 4, 5);
        for (var number : numbers) {
            System.out.println(number);
        }

        // 타입 추론으로 인해 예상치 못한 결과가 발생할 수 있음
        var text = "Hello, Java 10!";
        System.out.println(text);
    }
}

Java 11

주요 특징
- Long-Term Support (LTS) 버전
- 새로운 String 메소드 (lines, strip, repeat 등)
- HTTP 클라이언트 표준화
장점
- 장기 지원(LTS)으로 안정적인 사용이 가능합니다.
- 문자열 처리에 유용한 새로운 메소드가 추가되었습니다.
단점
- 일부 제거된 API에 대한 호환성 문제가 발생할 수 있습니다.
예시 코드

public class Java11Example {
    public static void main(String[] args) {
        String str = "  Hello World!  ";
        System.out.println(str.strip()); // "Hello World!"
        System.out.println("Java".repeat(3)); // "JavaJavaJava"

        // HTTP 클라이언트 사용 예시
        HttpClient client = HttpClient.newHttpClient();
        HttpRequest request = HttpRequest.newBuilder()
                .uri(URI.create("https://api.github.com"))
                .build();
        client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
              .thenApply(HttpResponse::body)
              .thenAccept(System.out::println)
              .join();
    }
}

Java 12 이후 버전

각 버전별로 주요 특징을 간단히 정리해보겠습니다.

Java 12
- Switch 표현식 (미리보기 기능)
- 새로운 JVM 메모리 관리 기능
예시 코드

public class Java12Example {
    public static void main(String[] args) {
        String day = "TUESDAY";
        String result = switch (day) {
            case "MONDAY", "FRIDAY", "SUNDAY" -> "Start of the week";
            case "TUESDAY" -> "Midweek";
            default -> "Weekday";
        };
        System.out.println(result); // "Midweek"
    }
}

Java 13
- 텍스트 블록 (미리보기 기능)
- 새로운 재사용 가능한 컴파일러 API
예시 코드

public class Java13Example {
    public static void main(String[] args) {
        String textBlock = """
                {
                    "name": "Alice",
                    "age": 30
                }
                """;
        System.out.println(textBlock);
    }
}

Java 14
- Switch 표현식 표준화
- NullPointerException 메시지 개선
예시 코드

public class Java14Example {
    public static void main(String[] args) {
        Object obj = null;
        try {
            obj.toString();
        } catch (NullPointerException e) {
            System.out.println("Caught exception: " + e.getMessage());
        }
    }
}

Java 15
- 텍스트 블록 표준화
- ZGC 개선 및 새로운 숨겨진 클래스 기능
예시 코드

public class Java15Example {
    public static void main(String[] args) {
        String html = """
                <html>
                    <body>
                        <p>Hello, world</p>
                    </body>
                </html>
                """;
        System.out.println(html);
    }
}

Java 16
- 패턴 매칭 for instanceof
- 기록 클래스 (Record Classes)
예시 코드

public class Java16Example {
    public static void main(String[] args) {
        Object obj = "Hello, Java 16!";
        if (obj instanceof String s) {
            System.out.println(s.toUpperCase());
        }

        record Person(String name, int age) {}
        Person person = new Person("Alice", 30);
        System.out.println(person.name() + " is " + person.age() + " years old.");
    }
}

Java 17
- 또 다른 Long-Term Support (LTS) 버전
- 새로운 흥미로운 기능 추가 (패턴 매칭, 숨겨진 클래스 등)
예시 코드

public class Java17Example {
    public static void main(String[] args) {
        // Pattern matching for switch (preview)
        Object obj = 123;
        String result = switch (obj) {
            case Integer i -> "Integer: " + i;
            case String s -> "String: " + s;
            default -> "Unknown type";
        };
        System.out.println(result); // "Integer: 123"
    }
}

요약

자바는 각 버전마다 다양한 새로운 기능과 개선 사항이 도입되어 왔습니다. 주요 버전의 특징과 장단점을 이해하면 더 나은 선택을 할 수 있을 것입니다. 각 버전별 주요 변경 사항을 통해 필요에 맞는 자바 버전을 선택하고 활용하시기 바랍니다.

[JAVA] JAVA로 REST API 구현하기

TaeHuiLee — Fri, 19 Jul 2024 08:00:59 +0900

1. REST API란?

REST API는 Representational State Transfer의 약자로, 웹에서 자원을 효율적으로 교환하기 위해 만들어진 아키텍처 스타일이에요. 간단히 말해, 웹 애플리케이션이 서버와 데이터를 주고받는 방식 중 하나죠. RESTful한 시스템은 자원(Resource), 자원의 상태(Representation), 이 자원을 조작하기 위한 표준 HTTP 메서드(GET, POST, PUT, DELETE)를 사용해요.

2. HTTP 메서드

REST API의 핵심은 HTTP 메서드를 사용해 자원과 상호작용하는 거예요. 주요 메서드에는 GET, POST, PUT, PATCH, DELETE 등이 있어요. 각 메서드는 특정 작업을 나타내요.

️ GET

GET 메서드는 서버에서 자원을 가져올 때 사용해요. 보통 데이터를 조회(read)할 때 쓰죠.

GET /users

위와 같은 요청은 모든 사용자의 정보를 가져오라는 의미예요.

️ POST

POST 메서드는 서버에 자원을 생성할 때 사용해요. 새로운 데이터를 추가(insert)할 때 쓰죠.

POST /users
{
  "name": "John",
  "email": "john@example.com"
}

이 요청은 새로운 사용자를 생성하라는 의미예요.

️ PUT

PUT 메서드는 서버의 자원을 업데이트할 때 사용해요. 전체 자원을 교체하는 방식으로 이해하면 돼요.

PUT /users/1
{
  "name": "John Doe",
  "email": "john.doe@example.com"
}

이 요청은 ID가 1인 사용자의 정보를 전체적으로 업데이트하라는 의미예요.

️ PATCH

PATCH 메서드는 서버의 자원을 부분적으로 업데이트할 때 사용해요. 일부 데이터만 수정할 때 쓰죠.

PATCH /users/1
{
  "email": "new.email@example.com"
}

이 요청은 ID가 1인 사용자의 이메일만 업데이트하라는 의미예요.

️ DELETE

DELETE 메서드는 서버의 자원을 삭제할 때 사용해요.

DELETE /users/1

이 요청은 ID가 1인 사용자를 삭제하라는 의미예요.

3. JAVA로 REST API 사용하기

이제 Java로 REST API를 어떻게 사용하는지 예시 코드를 통해 알아보아요. Spring Boot 프레임워크를 사용해서 간단한 RESTful 웹 서비스를 만들어볼게요.

️ Spring Boot 설정

먼저 Spring Boot 프로젝트를 생성하고, 필요한 의존성을 추가해요. build.gradle 파일에 다음과 같이 설정할 수 있어요.

plugins {
    id 'org.springframework.boot' version '2.5.4'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    runtimeOnly 'com.h2database:h2'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

️ 데이터 모델 생성

User 데이터를 나타내는 간단한 모델 클래스를 생성해요.

package com.example.demo;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private int id;
    private String name;
    private String email;

    // getters and setters
    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

️ 레포지토리 생성

JPA를 이용해 데이터베이스와 상호작용하는 레포지토리 인터페이스를 생성해요.

package com.example.demo;

import org.springframework.data.jpa.repository.JpaRepository;

public interface UserRepository extends JpaRepository<User, Integer> {
}

️ 컨트롤러 생성

이제 REST API의 엔드포인트를 정의하는 컨트롤러 클래스를 만들어볼게요.

package com.example.demo;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;

import java.util.List;

@RestController
@RequestMapping("/users")
public class UserController {

    @Autowired
    private UserRepository userRepository;

    @GetMapping
    public List<User> getAllUsers() {
        return userRepository.findAll();
    }

    @PostMapping
    public User createUser(@RequestBody User user) {
        return userRepository.save(user);
    }

    @PutMapping("/{id}")
    public User updateUser(@PathVariable int id, @RequestBody User user) {
        return userRepository.findById(id)
                .map(existingUser -> {
                    existingUser.setName(user.getName());
                    existingUser.setEmail(user.getEmail());
                    return userRepository.save(existingUser);
                })
                .orElseGet(() -> {
                    user.setId(id);
                    return userRepository.save(user);
                });
    }

    @PatchMapping("/{id}")
    public User partialUpdateUser(@PathVariable int id, @RequestBody User user) {
        return userRepository.findById(id)
                .map(existingUser -> {
                    if (user.getName() != null) {
                        existingUser.setName(user.getName());
                    }
                    if (user.getEmail() != null) {
                        existingUser.setEmail(user.getEmail());
                    }
                    return userRepository.save(existingUser);
                })
                .orElse(null);
    }

    @DeleteMapping("/{id}")
    public void deleteUser(@PathVariable int id) {
        userRepository.deleteById(id);
    }
}

️ 애플리케이션 실행

Spring Boot 애플리케이션을 실행하기 위해 메인 클래스를 설정해요.

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

4. JpaRepository에 대한 설명

UserRepository 인터페이스는 JpaRepository를 확장해요. Spring Data JPA가 제공하는 JpaRepository는 CRUD (Create, Read, Update, Delete) 작업을 위한 기본 메서드를 자동으로 구현해줘요. 주요 메서드들에는 다음과 같은 것들이 있어요:

save(S entity): 엔티티를 저장하거나 업데이트해요.
findById(ID id): 주어진 ID로 엔티티를 찾아요.
findAll(): 모든 엔티티를 리스트로 반환해요.
deleteById(ID id): 주어진 ID로 엔티티를 삭제해요.

이러한 메서드들은 SQL 쿼리를 직접 작성하지 않아도 데이터베이스와 상호작용할 수 있게 해줘요.

5. JPA의 동작 원리

Java Persistence API (JPA)는 자바 애플리케이션에서 관계형 데이터베이스를 사용하는 방식을 표준화한 인터페이스에요. JPA의 핵심 개념과 작동 방식은 다음과 같아요:

️ 엔티티(Entity)

데이터베이스 테이블과 매핑되는 클래스에요. @Entity 어노테이션을 사용해 정의해요.

️ 엔티티 매니저(Entity Manager)

엔티티의 생명주기를 관리해요. 엔티티를 데이터베이스에 삽입, 수정, 삭제, 조회하는 작업을 수행해요.

️ 영속성 컨텍스트(Persistence Context)

엔티티 매니저가 관리하는 엔티티 인스턴스의 집합이에요. 엔티티가 영속성 컨텍스트 내에 있으면 "영속 상태"라고 해요.

️ 트랜잭션(Transaction)

데이터베이스 작업의 논리적 단위에요. 모든 작업은 트랜잭션 내에서 이루어져야 해요. 트랜잭션은 원자성을 보장해요.

JPA는 이러한 개념을 바탕으로 동작하며, 개발자는 JPA를 통해 데이터베이스와의 상호작용을 쉽게 할 수 있어요.

6. DeleteMapping의 동작 원리

@DeleteMapping 어노테이션은 단순히 HTTP DELETE 요청을 처리하는 메서드라는 것을 명시해줄 뿐이에요. 실제 데이터베이스에서 삭제 작업을 수행하는 것은 UserRepository의 deleteById 메서드에 의해 이루어져요.

deleteById 메서드는 JPA 레포지토리 인터페이스의 기본 메서드 중 하나로, 엔티티의 ID를 인자로 받아 해당 엔티티를 데이터베이스에서 삭제해요. 이 메서드는 내부적으로 JPA가 제공하는 표준 SQL DELETE 쿼리를 생성하고 실행해요.

따라서, @DeleteMapping 어노테이션을 사용하면 Spring Boot는 해당 엔드포인트에 대한 HTTP DELETE 요청을 받았을 때, 자동으로 연결된 메서드를 호출하고, 그 메서드에서 deleteById를 통해 데이터베이스 삭제 작업을 수행하게 돼요.

7. REST API의 장점

REST API는 다음과 같은 장점들이 있어요:

확장성: 클라이언트와 서버의 독립성 덕분에 각기 따로 확장이 가능해요.
유연성: 다양한 데이터 형식을 지원해요 (JSON, XML 등).
가독성: URL과 HTTP 메서드를 사용해 직관적이에요.
성능: HTTP의 캐싱 기능을 사용할 수 있어 성능이 좋아요.

REST API는 현대 웹 개발에서 빼놓을 수 없는 중요한 기술이에요. GET, POST, PUT, PATCH, DELETE 같은 메서드를 잘 이해하고 활용하면, 효율적이고 확장 가능한 웹 서비스를 만들 수 있어요.

Developer_TaeHui

Kafka란 무엇인가?

1. Kafka 개요

Kafka의 주요 구성 요소

Kafka의 핵심 개념

2. Kafka 데이터 처리 방식

1️⃣ 데이터 생성: Producer

2️⃣ 데이터 저장: Broker

3️⃣ 데이터 소비: Consumer

Kafka 데이터 처리의 특징

3. Kafka의 성능

1️⃣ ⚡ 처리량

2️⃣ ⏱ 낮은 지연 시간

3️⃣ 확장성

4️⃣ 내구성

5️⃣ 안정성

4. ⚖️ RabbitMQ와의 차이점

RabbitMQ가 더 적합한 경우

Kafka가 더 적합한 경우

5. Kafka를 활용한 시스템 설계(결제 시스템)

결제 시스템 설계 목표

️ Kafka와 Spring Boot로 설계한 시스템 구조

단계별 구현 및 실패 처리 전략

1️⃣ 주문 생성 (Order Create)

2️⃣ 재고 확인 (Inventory Check)

3️⃣ 결제 처리 (Payment Process)

4️⃣ 사용자 알림 (Notification)

️ 실패 처리 전략

정리

[JAVA] Spring Boot 대규모 트래픽 처리 #Redis #Scheduler

1. ️ Spring Boot 대규모 트래픽 처리 방안: Redis, Scheduler

2. 로직과 코드 구현

전체 로직

3️⃣ 구현 코드

1. Redis에 데이터 저장 서비스

2. Redis 데이터를 DB로 옮기는 스케줄러

4. 장점과 단점

장점

단점

개선방안

5. 정리

[JAVA] Spring 테스트 : Mock VS MockBean

1. Spring 테스트의 기본: @SpringBootTest

@SpringBootTest란?

️ Application Context 초기화의 특징

장점

단점

사용 예시

2. ️ @MockBean: Mock 객체를 Application Context에 등록하기

@MockBean의 역할

주요 특징

사용 예시

장점

단점

3. @Mock과 @InjectMocks: Mockito 기반의 단위 테스트

@Mock과 @InjectMocks란?

사용 예시

장점

단점

4. @SpringBootTest vs Mockito 테스트: 언제 사용할까?

@SpringBootTest를 사용하는 상황

Mockito 기반 테스트를 사용하는 상황

5. 성능 최적화: @SpringBootTest를 사용할 때 주의할 점

초기화가 일어나는 경우

성능 최적화 팁

6. 정리: Mock VS MockBean 비교표

[JAVA] Spring을 이용한 테스트 코드 작성 방법 (단위 테스트, 통합 테스트)

1. 단위 테스트와 통합 테스트의 차이

✅ 단위 테스트(Unit Test)

✅ 통합 테스트(Integration Test)

2. 준비 사항

2.1 의존성 추가 (Maven 기준)

2.2 테스트 환경 설정 (application.yml)

application-test.yml

3. 단위 테스트 작성하기

3.1 User 엔티티 및 리포지토리

3.2 UserService

3.3 UserService 단위 테스트 작성

✅ @ExtendWith(MockitoExtension.class)

✅ @Mock

1. `Kafka 개요`

2. `Kafka 데이터 처리 방식`

1️⃣ 데이터 생성: `Producer`

2️⃣ 데이터 저장: `Broker`

3️⃣ 데이터 소비: `Consumer`

3. `Kafka의 성능`

1️⃣ ⚡ `처리량`

2️⃣ ⏱ `낮은 지연 시간`

3️⃣ `확장성`

4️⃣ `내구성`

5️⃣ `안정성`

4. ⚖️ `RabbitMQ와의 차이점`

1. Spring 테스트의 기본: `@SpringBootTest`

`@SpringBootTest`란?

2. ️ `@MockBean`: Mock 객체를 Application Context에 등록하기

`@MockBean`의 역할

3. `@Mock`과 `@InjectMocks`: Mockito 기반의 단위 테스트

`@Mock`과 `@InjectMocks`란?

4. `@SpringBootTest` vs Mockito 테스트: 언제 사용할까?

`@SpringBootTest`를 사용하는 상황

5. 성능 최적화: `@SpringBootTest`를 사용할 때 주의할 점

2.2 테스트 환경 설정 (`application.yml`)

`application-test.yml`

✅ `@ExtendWith(MockitoExtension.class)`

✅ `@Mock`

✅ `@InjectMocks`

✅ `@SpringBootTest`

✅ `@Transactional`

✅ `@ActiveProfiles`

1. `git filter-repo` 설치

️ 1.2. pip를 통해 `git filter-repo` 설치

3.1. `git filter-repo` 실행

1. `PriorityQueue`란?

2. `PriorityQueue` 주요 메서드

3. `PriorityQueue` 기본 사용법

6. ⚡ `PriorityQueue`와 다른 큐 구현체 비교

1. `Queue`와 `Deque`의 차이

1.1 `Queue`의 특징

1.2 `Deque`의 특징

2. `Deque`를 사용하여 `Queue` 동작 구현

3. `Deque`로 구현할 때 성능 분석

3.1 `ArrayDeque`의 성능

3.2 `LinkedList`의 성능

4. 왜 `Deque`를 사용하는 것이 괜찮은가?

4.1 `Queue` 대신 `Deque`를 사용하는 이유

5. ⚡ `Deque`와 `Queue` 구현체 비교