📨
Apache Kafka 치트시트

Kafka 아키텍처, KRaft & Docker Compose 환경 구축, Topic 관리, Console Producer/Consumer, Consumer Group & Offset 리셋, 핵심 파라미터 튜닝, Spring Kafka 연동 및 장애 트러블슈팅 완벽 가이드
#kafka#kraft#message-broker#streaming#event-driven#spring-kafka#docker#backend최종 업데이트: 2026-09-30
Apache Kafka 치트시트 핵심 명령어 및 실전 가이드

## 1. Kafka 핵심 아키텍처 & 동작 원리 (Architecture)
```mermaid
graph LR
  subgraph Producers
    P1[Producer App 1]
    P2[Producer App 2]
  end

  subgraph Kafka Cluster [Kafka Cluster / KRaft Controller]
    subgraph Topic: orders [Topic: orders]
      P_0[Partition 0<br/>Leader: Broker 1<br/>ISR: 1, 2]
      P_1[Partition 1<br/>Leader: Broker 2<br/>ISR: 2, 3]
      P_2[Partition 2<br/>Leader: Broker 3<br/>ISR: 3, 1]
    end
  end

  subgraph Consumer Group: order-service [Consumer Group: order-service]
    C1[Consumer 1<br/>reads P0]
    C2[Consumer 2<br/>reads P1]
    C3[Consumer 3<br/>reads P2]
  end

  P1 -->|Key=101 -> P0| P_0
  P2 -->|Key=102 -> P1| P_1
  P1 -->|Key=103 -> P2| P_2

  P_0 --> C1
  P_1 --> C2
  P_2 --> C3
```
```text
■ 핵심 용어 정리:
• Topic: 메시지를 구분하는 논리적 채널 (RDBMS의 테이블 개념)
• Partition: 토픽을 분할하여 병렬 처리 및 수평 확장을 가능하게 하는 물리적 큐 단위 (순서 보장 단위)
• Offset: 파티션 내에서 각 메시지가 부여받는 고유한 순차적 번호 (0부터 단조 증가, 불변)
• Broker: Kafka 서버 인스턴스 (메시지 수신, 디스크 기록, 오프셋 관리, 장애 복구 담당)
• Replication Factor: 파티션의 복제본 수 (Leader 1개 + Follower N-1개, 고가용성 보장)
• ISR (In-Sync Replicas): Leader와 동기화 상태를 유지하고 있는 복제본 그룹
• Consumer Group: 동일한 토픽을 분산/병렬 처리하기 위해 협력하는 컨슈머 인스턴스들의 집합
• KRaft (Kafka Raft): Kafka 3.x+부터 ZooKeeper 없이 자체 Raft 알고리즘으로 메타데이터를 관리하는 차세대 아키텍처
```

---

## 2. Docker & Docker Compose 빠른 실행 (KRaft Mode)
```bash
# 🐳 [1] Docker 단일 브로커 즉시 실행 (ZooKeeper 없는 최신 KRaft 모드)
docker run -d \
  --name kafka-standalone \
  -p 9092:9092 \
  -e KAFKA_NODE_ID=1 \
  -e KAFKA_PROCESS_ROLES=broker,controller \
  -e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093 \
  -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://localhost:9092 \
  -e KAFKA_CONTROLLER_LISTENER_NAMES=CONTROLLER \
  -e KAFKA_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT \
  -e KAFKA_CONTROLLER_QUORUM_VOTERS=1@localhost:9093 \
  -e KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR=1 \
  -e KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR=1 \
  -e KAFKA_TRANSACTION_STATE_LOG_MIN_ISR=1 \
  -e KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS=0 \
  -e KAFKA_NUM_PARTITIONS=3 \
  apache/kafka:latest

# 컨테이너 쉘 접속
docker exec -it kafka-standalone /bin/bash
```
```yaml
# 🐳 [2] docker-compose.yml (Kafka KRaft 브로커 + Kafka UI 웹 대시보드)
version: '3.8'

services:
  kafka:
    image: apache/kafka:latest
    container_name: kafka-kraft
    ports:
      - "9092:9092"
    environment:
      # 노드 역할 및 ID (브로커 + 컨트롤러 통합 모드)
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: broker,controller
      # 리스너 설정 (외부 접속: 9092, 내부 컨트롤러: 9093)
      KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@kafka:9093
      # 개발용 단일 노드 설정
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_LOG_DIRS: /tmp/kraft-combined-logs
    volumes:
      - kafka_data:/tmp/kraft-combined-logs

  # Kafka UI: 웹 브라우저(http://localhost:8080)로 토픽, 메시지, 컨슈머 그룹 확인
  kafka-ui:
    image: provectuslabs/kafka-ui:latest
    container_name: kafka-ui
    ports:
      - "8080:8080"
    environment:
      KAFKA_CLUSTERS_0_NAME: local-cluster
      KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS: kafka:9092
    depends_on:
      - kafka

volumes:
  kafka_data:
```

---

## 3. 토픽 관리 CLI (`kafka-topics.sh`)
```bash
# ⚠️ Kafka 기본 CLI 실행 위치: $KAFKA_HOME/bin/ 또는 docker exec -it kafka-kraft ...

# [1] 토픽 생성 (파티션 3개, 복제 계수 1개)
kafka-topics.sh --bootstrap-server localhost:9092 \
  --create \
  --topic payment-events \
  --partitions 3 \
  --replication-factor 1

# [2] 토픽 생성 시 보존 정책(Retention) 동시 설정 (예: 7일 = 604800000ms)
kafka-topics.sh --bootstrap-server localhost:9092 \
  --create \
  --topic order-events \
  --partitions 3 \
  --replication-factor 1 \
  --config retention.ms=604800000 \
  --config segment.bytes=1073741824

# [3] 전체 토픽 목록 확인
kafka-topics.sh --bootstrap-server localhost:9092 --list

# [4] 특정 토픽 상세 정보 조회 (파티션별 Leader, Replicas, ISR 확인)
kafka-topics.sh --bootstrap-server localhost:9092 \
  --describe \
  --topic payment-events

# [5] 파티션 개수 증가 (⚠️ 파티션 수는 늘릴 수만 있고 줄일 수 없음!)
kafka-topics.sh --bootstrap-server localhost:9092 \
  --alter \
  --topic payment-events \
  --partitions 5

# [6] 토픽 삭제 (delete.topic.enable=true 필요)
kafka-topics.sh --bootstrap-server localhost:9092 \
  --delete \
  --topic payment-events
```

---

## 4. 토픽 동적 설정 변경 (`kafka-configs.sh`)
```bash
# [1] 토픽의 현재 설정값 전체 조회
kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name order-events \
  --describe

# [2] 메시지 보존 시간(retention.ms) 동적 변경 (예: 24시간 = 86400000ms)
kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name order-events \
  --alter \
  --add-config retention.ms=86400000

# [3] 최대 메시지 크기 변경 (기본 1MB -> 10MB로 확장)
kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name order-events \
  --alter \
  --add-config max.message.bytes=10485760

# [4] 정리 정책(Cleanup Policy) 변경: 삭제(delete) vs 압축(compact)
# compact: 최신 Key 값만 유지하는 로그 압축 방식
kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name user-profile \
  --alter \
  --add-config cleanup.policy=compact

# [5] 동적으로 추가했던 토픽 설정 삭제(기본값 복원)
kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name order-events \
  --alter \
  --delete-config retention.ms
```

---

## 5. 메시지 발행: 콘솔 프로듀서 (`kafka-console-producer.sh`)
```bash
# [1] 기본 메시지 발행 (한 줄 입력할 때마다 Value로 발행, Ctrl+C로 종료)
kafka-console-producer.sh --bootstrap-server localhost:9092 \
  --topic order-events

# [2] Key-Value 형태 메시지 발행 (동일 Key는 동일 Partition으로 라우팅됨)
kafka-console-producer.sh --bootstrap-server localhost:9092 \
  --topic order-events \
  --property "parse.key=true" \
  --property "key.separator=:"

# 입력 예시:
# order-101:{"itemId": "item-A", "price": 15000}
# order-102:{"itemId": "item-B", "price": 28000}

# [3] 파일 내용 또는 표준 입력을 통한 대량 메시지 전송
cat sample_events.json | kafka-console-producer.sh \
  --bootstrap-server localhost:9092 \
  --topic order-events

# [4] Producer ACKs 옵션을 부여하여 안전하게 발행
kafka-console-producer.sh --bootstrap-server localhost:9092 \
  --topic order-events \
  --request-required-acks all
```

---

## 6. 메시지 소비: 콘솔 컨슈머 (`kafka-console-consumer.sh`)
```bash
# [1] 실시간 메시지 구독 (명령어 실행 이후 인입되는 메시지만 소비)
kafka-console-consumer.sh --bootstrap-server localhost:9092 \
  --topic order-events

# [2] 처음 오프셋(0번)부터 과거 모든 메시지 읽기 (--from-beginning)
kafka-console-consumer.sh --bootstrap-server localhost:9092 \
  --topic order-events \
  --from-beginning

# [3] 메시지 Key, Timestamp, Partition, Offset을 함께 출력 (디버깅 필수)
kafka-console-consumer.sh --bootstrap-server localhost:9092 \
  --topic order-events \
  --from-beginning \
  --property print.key=true \
  --property print.timestamp=true \
  --property print.partition=true \
  --property print.offset=true \
  --property key.separator=" | "

# [4] 특정 컨슈머 그룹(Consumer Group)을 지정하여 메시지 소비 (오프셋 커밋됨)
kafka-console-consumer.sh --bootstrap-server localhost:9092 \
  --topic order-events \
  --group order-worker-group

# [5] 특정 파티션의 지정 오프셋부터 읽기
kafka-console-consumer.sh --bootstrap-server localhost:9092 \
  --topic order-events \
  --partition 0 \
  --offset 100 \
  --max-messages 50
```

---

## 7. 컨슈머 그룹 및 오프셋 관리 (`kafka-consumer-groups.sh`)
```bash
# [1] 등록된 모든 컨슈머 그룹 목록 확인
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list

# [2] 특정 컨슈머 그룹의 소비 진행 상태 및 Lag(지연) 점검
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --describe \
  --group order-worker-group

# 출력 결과 컬럼 해석:
# TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG      CONSUMER-ID     HOST
# order-events    0          1452            1460            8        consumer-1...   /127.0.0.1
# -> LAG: Log-End-Offset - Current-Offset = 컨슈머가 아직 처리하지 못하고 쌓인 메시지 수!

# ⚠️ [3] 오프셋 리셋 (반드시 해당 컨슈머 그룹 프로세스가 중지된 상태여야 함)

# 3-1. 가장 처음 오프셋으로 리셋 (--to-earliest)
# --dry-run: 실제 반영 전 시뮬레이션
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --group order-worker-group \
  --topic order-events \
  --reset-offsets \
  --to-earliest \
  --dry-run

# 3-2. 실제 오프셋 리셋 실행 (--execute)
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --group order-worker-group \
  --topic order-events \
  --reset-offsets \
  --to-earliest \
  --execute

# 3-3. 최신 오프셋으로 리셋 (과거 메시지 건너뛰기)
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --group order-worker-group \
  --topic order-events \
  --reset-offsets \
  --to-latest \
  --execute

# 3-4. 특정 일시 기준으로 리셋 (--to-datetime)
# 형식: YYYY-MM-DDTHH:mm:ss.sss
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --group order-worker-group \
  --topic order-events \
  --reset-offsets \
  --to-datetime 2026-09-30T00:00:00.000 \
  --execute

# 3-5. 현재 오프셋에서 N건 뒤로 되돌리기 (--shift-by)
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --group order-worker-group \
  --topic order-events \
  --reset-offsets \
  --shift-by -100 \
  --execute
```

---

## 8. 프로듀서(Producer) 핵심 튜닝 파라미터
```properties
# 1. 메시지 유실 방지 (신뢰성 vs 처리량)
# acks=0: 응답 대기 없음 (최대 속도, 유실 가능)
# acks=1: Leader 파티션 디스크 기록 확인 후 응답 (기본값)
# acks=all 또는 -1: 모든 ISR 복제본 기록 완료 후 응답 (강력 권장, 데이터 유실 0)
acks=all

# 2. 멱등성 프로듀서 (Idempotence) - 네트워크 재시도 시 중복 메시지 저장 방지
enable.idempotence=true
# 멱등성 활성화 시 필수 연계 옵션:
# acks=all
# retries > 0
# max.in.flight.requests.per.connection <= 5

# 3. 재시도 및 타임아웃
retries=2147483647
delivery.timeout.ms=120000
retry.backoff.ms=100

# 4. 일괄 전송(Batching)으로 처리량 극대화
# linger.ms: 버퍼가 덜 차도 최대 N밀리초 동안 대기 후 모아서 전송 (기본 0 -> 5~20ms 권장)
linger.ms=20
# batch.size: 단일 배치 최대 바이트 크기 (기본 16KB -> 대용량 트래픽 시 64KB 권장)
batch.size=65536

# 5. 메시지 압축 알고리즘 (네트워크 대역폭 절약)
# snappy: CPU 사용량 낮고 압축/해제 속도 매우 빠름 (실무 표준 권장)
# zstd: 높은 압축률 (로그, 텍스트 데이터에 적합)
compression.type=snappy

# 6. 버퍼 메모리
buffer.memory=33554432 # 32MB 프로듀서 버퍼
max.block.ms=60000
```

---

## 9. 컨슈머(Consumer) 핵심 튜닝 파라미터
```properties
# 1. 초기 오프셋 결정 전략 (커밋된 오프셋이 없을 때)
# earliest: 가장 오래된 메시지부터 읽기
# latest: 가장 최신 메시지부터 읽기 (기본값)
# none: 커밋 기록 없으면 예외(NoOffsetForPartitionException) 발생
auto.offset.reset=earliest

# 2. 오프셋 자동 커밋 (Auto Commit) vs 수동 커밋 (Manual Commit)
# 실무 권장: false 설정 후 비즈니스 로직 정상 완료 시점에 수동 커밋 (At-Least-Once 보장)
enable.auto.commit=false
auto.commit.interval.ms=5000

# 3. 폴링(Poll) 레코드 수 및 인터벌 튜닝 (리밸런싱 방지 핵심)
# max.poll.records: 단일 poll() 호출 시 가져올 최대 레코드 수 (기본 500)
# 처리 시간이 긴 작업인 경우 50~100개로 줄여 리밸런싱 타임아웃 방지
max.poll.records=100

# max.poll.interval.ms: poll() 호출 간 최대 허용 시간 (기본 300,000ms = 5분)
# 이 시간 내에 다음 poll()이 호출되지 않으면 브로커는 컨슈머가 죽은 것으로 간주하고 Rebalance 유발
max.poll.interval.ms=300000

# 4. 하트비트 및 세션 타임아웃
# session.timeout.ms: 브로커가 컨슈머의 장애를 감지하는 시간 (기본 45초)
session.timeout.ms=45000
# heartbeat.interval.ms: session.timeout.ms의 1/3 수준 권장 (기본 3초)
heartbeat.interval.ms=3000

# 5. 파티션 할당 전략 (Partition Assignment Strategy)
# CooperativeStickyAssignor: 리밸런싱 발생 시 전체 중단(Stop-the-world) 없이 점진적 재할당
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor
```

---

## 10. 브로커(Broker) `server.properties` 필수 설정
```properties
# 1. 브로커 고유 ID 및 로그 디렉토리
broker.id=1
log.dirs=/var/lib/kafka/data

# 2. 토픽 기본 파티션 및 복제 계수
num.partitions=3
default.replication.factor=3
min.insync.replicas=2 # acks=all과 결합하여 최소 2대 이상 쓰기 성공해야 승인

# 3. 토픽 자동 생성 방지 (실무 필수: 오타로 인한 토픽 난립 방지)
auto.create.topics.enable=false

# 4. 신뢰성 없는 리더 선출 방지 (ISR에 없는 복제본이 리더 되는 것 차단 -> 유실 방지)
unclean.leader.election.enable=false

# 5. 로그 보존 및 세그먼트 정책
log.retention.hours=168            # 7일 보존
log.retention.bytes=107374182400   # 브로커당 토픽 최대 100GB 보존
log.segment.bytes=1073741824       # 세그먼트 파일 1GB 단위로 롤링
log.cleanup.policy=delete          # 초과 시 삭제

# 6. 네트워크 & I/O 스레드 수 (CPU 코어 수 기반 튜닝)
num.network.threads=8              # 요청 수신/응답 스레드
num.io.threads=16                  # 디스크 읽기/쓰기 스레드
```

---

## 11. Spring Boot 연동: `application.yml` 설정
```yaml
spring:
  kafka:
    # 카프카 브로커 클러스터 주소 목록
    bootstrap-servers: localhost:9092

    # 프로듀서 전역 설정
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.springframework.kafka.support.serializer.JsonSerializer
      acks: all
      retries: 3
      properties:
        enable.idempotence: true
        linger.ms: 20
        compression.type: snappy

    # 컨슈머 전역 설정
    consumer:
      group-id: order-service-group
      auto-offset-reset: earliest
      enable-auto-commit: false # 수동 커밋 모드 사용
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.springframework.kafka.support.serializer.JsonDeserializer
      properties:
        spring.json.trusted.packages: "com.example.*"
        max.poll.records: 100

    # 리스너 컨테이너 설정 (수동 Ack 지원)
    listener:
      ack-mode: MANUAL_IMMEDIATE # 수동 즉시 커밋
      concurrency: 3             # 컨슈머 스레드 동시성 수
```

---

## 12. Spring Boot 프로듀서 & 컨슈머 구현 코드
```java
// [1] Kafka Producer 서비스 (비동기 콜백 전송)
@Service
@RequiredArgsConstructor
@Slf4j
public class OrderProducer {

    private final KafkaTemplate<String, OrderEvent> kafkaTemplate;

    public void sendOrderEvent(String orderId, OrderEvent event) {
        // 토픽명, 메시지 키(orderId 파티셔닝 보장), 페이로드
        CompletableFuture<SendResult<String, OrderEvent>> future = 
            kafkaTemplate.send("order-events", orderId, event);

        future.whenComplete((result, ex) -> {
            if (ex == null) {
                RecordMetadata meta = result.getRecordMetadata();
                log.info("발행 성공: topic={}, partition={}, offset={}", 
                    meta.topic(), meta.partition(), meta.offset());
            } else {
                log.error("발행 실패: orderId={}, error={}", orderId, ex.getMessage());
            }
        });
    }
}
```
```java
// [2] Kafka Consumer 리스너 (수동 커밋 + DLT 재시도 지원)
@Component
@Slf4j
public class OrderConsumer {

    @KafkaListener(
        topics = "order-events",
        groupId = "order-service-group",
        containerFactory = "kafkaListenerContainerFactory"
    )
    public void consumeOrder(
        @Payload OrderEvent event,
        @Header(KafkaHeaders.RECEIVED_KEY) String key,
        @Header(KafkaHeaders.RECEIVED_PARTITION) int partition,
        @Header(KafkaHeaders.OFFSET) long offset,
        Acknowledgment ack
    ) {
        try {
            log.info("수신: key={}, partition={}, offset={}, payload={}", 
                key, partition, offset, event);

            // 비즈니스 로직 수행
            processOrder(event);

            // 처리 완료 후 오프셋 수동 커밋
            ack.acknowledge();
        } catch (Exception e) {
            log.error("메시지 처리 실패, 재시도 대기: {}", e.getMessage());
            // 예외를 던지면 ErrorHandler에 의해 DLT(Dead Letter Topic)로 이동 가능
            throw e;
        }
    }

    private void processOrder(OrderEvent event) {
        // 주문 처리 로직
    }
}
```

---

## 13. 실무 장애 트러블슈팅 & 성능 최적화 (Troubleshooting)
```text
■ 1. Consumer Lag(지연)이 지속적으로 증가할 때
  ① 원인 분석:
     - 컨슈머의 비즈니스 로직 처리 속도(DB 쓰기, 외부 API 호출 지연)가 프로듀서 인입량보다 느림
     - 특정 파티션에 Key 불균형으로 핫스팟(Hotspot) 발생
  ② 해결 조치:
     - 토픽 파티션 수 증가 + 동일 컨슈머 그룹의 인스턴스/스레드 증설 (1:1 매핑)
     - DB Batch Insert 또는 비동기 멀티스레드 파이프라인 처리
     - Key가 특정 값에 치우치지 않도록 Salt 추가 또는 해시 분산

■ 2. Rebalance Storm (빈번한 컨슈머 리밸런싱 발생)
  ① 원인 분석:
     - 컨슈머가 1회 poll()해온 메시지들을 처리하는 데 걸리는 시간이 `max.poll.interval.ms`(기본 5분)를 초과
     - 브로커가 컨슈머가 다운된 것으로 판정하고 전체 컨슈머 파티션 재할당 반복
  ② 해결 조치:
     - `max.poll.records` 크기를 500 -> 50~100으로 줄여 1회 처리 시간 단축
     - `max.poll.interval.ms` 대기 시간을 10~15분으로 충분히 연장
     - 파티션 할당 전략을 `CooperativeStickyAssignor`로 전환하여 전면 중단(Stop-the-world) 방지

■ 3. 메시지 유실 방지(Zero Data Loss) 3대 골든 룰
  ① Producer: `acks=all`, `retries=int_max`, `enable.idempotence=true`
  ② Broker: `min.insync.replicas=2` (복제 계수 3 기준), `unclean.leader.election.enable=false`
  ③ Consumer: `enable.auto.commit=false` (로직 성공 후 명시적 `ack.acknowledge()`)

■ 4. OS 및 디스크 I/O 성능 튜닝
  ① Zero-Copy & Page Cache:
     - Kafka는 JVM 힙 대신 OS 커널의 PageCache를 적극 활용함 (sendfile 시스템 콜)
     - 브로커 JVM 힙 크기는 6~8GB 정도로 작게 두고, 남은 시스템 메모리를 OS Page Cache에 할당할 것!
  ② 디스크 XFS 파일 시스템 사용 권장 (ext4 대비 대용량 세그먼트 플러시 성능 우수)
```
💬
Apache Kafka 치트시트

의견 및 질문

댓글 수정

댓글 삭제
