12월 21, 2025
42 분 읽기

주니어 SRE 면접 질문과 답변

interview
career-advice
job-search
entry-level
주니어 SRE 면접 질문과 답변
Milad Bonakdar

Milad Bonakdar

작성자

SLO, 오류 예산, 알림, 사고 대응, Linux 문제 해결, 자동화, Kubernetes 기초를 다루는 실전형 주니어 SRE 면접 질문을 준비하세요.

주니어 SRE 면접에서 보는 것

주니어 SRE 면접은 보통 사용자 영향에서 시스템 신호로 이어지는 사고 과정을 확인합니다. SLO, 오류 예산, 알림, 사고 대응, Linux 신호, 자동화, 컨테이너, Kubernetes 기본 운영이 핵심입니다. 시니어처럼 말할 필요는 없습니다. 차분하게 조사하고, 사고 중 명확히 소통하며, 위험을 숨기지 않고 반복 운영 작업을 자동화할 수 있음을 보여주면 됩니다.

각 질문으로 짧은 답변을 연습하고, 프로젝트, 실습 환경, 인턴 경험, 온콜 참관처럼 실제 사례와 연결해 설명해 보세요.

SRE 기본 사항

1. 사이트 안정성 엔지니어링이란 무엇이며 DevOps와 어떻게 다른가요?

답변: SRE는 Google에서 대규모 프로덕션 시스템을 안정적으로 운영하기 위해 사용하는 접근 방식입니다.

핵심 원칙:

  • 운영을 소프트웨어 문제로 취급
  • 운영 작업(Toil)에 최대 50%의 시간만 사용
  • 안정성과 속도의 균형을 위한 오류 예산
  • 무책임한(Blameless) 사고 후 분석 (Postmortems)
  • 점진적인 롤아웃 및 자동화된 롤백

SRE vs DevOps:

측면SREDevOps
초점안정성 및 확장성협업 및 자동화
지표SLI, SLO, 오류 예산배포 빈도, 리드 타임
접근 방식규범적(구체적인 실천)철학(문화 운동)
Toil명시적으로 50%로 제한구체적으로 정의되지 않음

SRE는 특정 실천 방법과 지표를 통해 DevOps 원칙을 구현합니다.

빈도: 매우 흔함 난이도: 쉬움

2. SLI, SLO 및 오류 예산에 대해 설명하세요.

답변: 이것들은 안정성을 측정하고 관리하기 위한 핵심 SRE 개념입니다.

SLI (Service Level Indicator, 서비스 수준 지표):

  • 서비스 수준의 정량적 측정
  • 예시: 지연 시간, 가용성, 오류율

SLO (Service Level Objective, 서비스 수준 목표):

  • SLI의 목표 값
  • 예시: "요청의 99.9%가 성공해야 함"

오류 예산 (Error Budget):

  • 허용된 실패율 (100% - SLO)
  • 안정성과 기능 개발 속도의 균형을 맞추는 데 사용
# SLI/SLO 계산 예시
def calculate_error_budget(total_requests, failed_requests, slo_target=0.999):
    """
    오류 예산 소모량 계산
    
    SLO: 99.9% 성공률
    오류 예산: 0.1% 실패 허용
    """
    success_rate = (total_requests - failed_requests) / total_requests
    error_rate = failed_requests / total_requests
    
    # 오류 예산: 허용된 0.1% 중 얼마나 사용했는지 계산
    allowed_errors = total_requests * (1 - slo_target)
    budget_consumed = (failed_requests / allowed_errors) * 100
    
    return {
        'success_rate': success_rate,
        'error_rate': error_rate,
        'slo_target': slo_target,
        'slo_met': success_rate >= slo_target,
        'error_budget_consumed': budget_consumed,
        'remaining_budget': max(0, 100 - budget_consumed)
    }

# 예시
result = calculate_error_budget(
    total_requests=1000000,
    failed_requests=500,  # 0.05% 오류율
    slo_target=0.999
)

print(f"성공률: {result['success_rate']:.4%}")
print(f"SLO 충족 여부: {result['slo_met']}")
print(f"오류 예산 소모량: {result['error_budget_consumed']:.1f}%")

빈도: 매우 흔함 난이도: 중간

3. Toil이란 무엇이며 어떻게 줄일 수 있나요?

답변: Toil은 반복적이고 수동적인 운영 작업으로 다음과 같은 특징을 가집니다.

  • 수동적임 (사람의 작업 필요)
  • 반복적임
  • 자동화 가능함
  • 지속적인 가치가 없음
  • 서비스 성장과 함께 선형적으로 증가함

Toil의 예시:

  • 수동으로 서비스 재시작
  • 서버 간 파일 복사
  • 수동으로 리소스 확장
  • 반복적인 티켓 응답

Toil 감소 전략:

# 예시: 서비스 재시작 자동화
#!/bin/bash
# auto-restart-service.sh

SERVICE_NAME="myapp"
MAX_RETRIES=3
RETRY_DELAY=5

check_service() {
    systemctl is-active --quiet $SERVICE_NAME
    return $?
}

restart_service() {
    echo "$(date): $SERVICE_NAME 재시작 중"
    systemctl restart $SERVICE_NAME
    
    # 서비스 안정화 대기
    sleep $RETRY_DELAY
    
    if check_service; then
        echo "$(date): $SERVICE_NAME 재시작 성공"
        # 알림 전송
        curl -X POST https://alerts.company.com/webhook \
          -d "{\"message\": \"$SERVICE_NAME 자동 재시작\"}"
        return 0
    else
        return 1
    fi
}

# 메인 로직
if ! check_service; then
    echo "$(date): $SERVICE_NAME 다운됨"
    
    for i in $(seq 1 $MAX_RETRIES); do
        echo "시도 $i / $MAX_RETRIES"
        if restart_service; then
            exit 0
        fi
        sleep $RETRY_DELAY
    done
    
    # 모든 재시도 실패 - 에스컬레이션
    echo "$(date): $MAX_RETRIES 시도 후 $SERVICE_NAME 재시작 실패"
    curl -X POST https://pagerduty.com/api/incidents \
      -d "{\"service\": \"$SERVICE_NAME\", \"severity\": \"critical\"}"
    exit 1
fi

SRE 목표: Toil을 시간의 50% 미만으로 유지하고 나머지는 자동화합니다.

빈도: 매우 흔함 난이도: 쉬움-중간

모니터링 및 관측 가능성

4. 모니터링과 관측 가능성의 차이점은 무엇인가요?

답변: 모니터링: 미리 정의된 메트릭 및 알림 수집

  • Known-unknowns: 감시해야 할 대상을 알고 있음
  • 대시보드, 알림, 메트릭
  • 예시: CPU, 메모리, 요청률

관측 가능성: 출력으로부터 시스템 상태 이해

  • Unknown-unknowns: 예상치 못한 문제 디버깅
  • 로그, 메트릭, 추적 결합
  • 임의의 질문에 답변 가능
Loading diagram...

관측 가능성의 세 가지 기둥:

  1. 메트릭: 집계된 숫자 (CPU, 지연 시간)
  2. 로그: 개별 이벤트
  3. 추적: 시스템을 통한 요청 흐름

예시: Prometheus + Grafana + Loki

# Prometheus 스크래핑 설정
scrape_configs:
  - job_name: 'api-server'
    static_configs:
      - targets: ['localhost:8080']
    metrics_path: '/metrics'
    scrape_interval: 15s

빈도: 흔함 난이도: 중간

5. 효과적인 알림을 설정하는 방법은 무엇인가요?

답변: 좋은 알림은 실행 가능하고 의미 있으며 피로감을 유발하지 않습니다.

알림 모범 사례:

1. 원인이 아닌 증상에 대한 알림:

# 나쁨: 높은 CPU에 대한 알림
- alert: HighCPU
  expr: cpu_usage > 80
  
# 좋음: 사용자 영향에 대한 알림
- alert: HighLatency
  expr: http_request_duration_seconds{quantile="0.95"} > 1
  for: 5m
  annotations:
    summary: "API 지연 시간 높음"
    description: "95번째 백분위수 지연 시간: {{ $value }}s"

2. 런북 링크 포함:

- alert: DatabaseConnectionPoolExhausted
  expr: db_connection_pool_active / db_connection_pool_max > 0.9
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "데이터베이스 연결 풀 거의 소진"
    runbook: "https://wiki.company.com/runbooks/db-connections"

3. 적절한 심각도 수준 사용:

# 페이지 호출 (누군가를 깨움)
- alert: ServiceDown
  expr: up{job="api"} == 0
  for: 1m
  labels:
    severity: critical
    
# 티켓 발행 (업무 시간 내 처리)
- alert: DiskSpaceWarning
  expr: disk_free_percent < 20
  for: 30m
  labels:
    severity: warning

4. 알림 피로 방지:

  • for: 지속 시간을 사용하여 깜박거림 방지
  • 관련 알림 그룹화
  • 적절한 임계값 설정
  • 정기적으로 검토 및 조정

빈도: 매우 흔함 난이도: 중간

사고 대응

6. 사고 대응 프로세스를 설명하세요.

답변: 구조화된 사고 대응은 영향과 복구 시간을 최소화합니다.

사고 대응 단계:

Loading diagram...

1. 감지:

  • 알림 발생 또는 사용자 문제 보고
  • 알림 확인
  • 사고 채널 생성

2. 분류:

# 빠른 평가 체크리스트
- 사용자 영향은 무엇인가?
- 영향을 받는 사용자 수는?
- 영향을 받는 서비스는?
- 상황이 악화되고 있는가?

3. 완화:

# 일반적인 완화 전략
- 최근 배포 롤백
- 리소스 확장
- 문제 있는 기능 비활성화
- 백업 시스템으로 장애 조치
- 트래픽 속도 제한

4. 해결:

  • 근본 원인 수정
  • 메트릭이 정상으로 돌아왔는지 확인
  • 재발 여부 모니터링

5. 사고 후 분석 (무책임):

# 사고 후 분석 템플릿

## 요약
발생한 상황에 대한 간략한 설명

## 영향
- 지속 시간: 2024-11-25 10:00 - 10:45 UTC (45분)
- 영향을 받은 사용자: ~10,000 (총 5%)
- 영향을 받은 서비스: API, 웹 프론트엔드

## 근본 원인
느린 쿼리로 인한 데이터베이스 연결 풀 소진

## 타임라인
- 10:00: 높은 API 지연 시간에 대한 알림 발생
- 10:05: 당직 엔지니어 확인
- 10:10: 데이터베이스가 병목 지점임을 확인
- 10:15: 연결 풀 크기 증가 (완화)
- 10:30: 느린 쿼리 식별 및 종료
- 10:45: 서비스 완전 복구

## 해결
- 즉시: 연결 풀을 100에서 200으로 증가
- 단기: 쿼리 시간 초과 추가 (30초)
- 장기: 느린 쿼리 최적화, 쿼리 모니터링 추가

## 실행 항목
- [ ] 느린 쿼리에 대한 알림 추가 (담당자: Alice, 마감일: 2024-12-01)
- [ ] 애플리케이션에 쿼리 시간 초과 구현 (담당자: Bob, 마감일: 2024-12-05)
- [ ] 상위 10개의 가장 느린 쿼리 검토 및 최적화 (담당자: Charlie, 마감일: 2024-12-10)

## 배운 점
- 연결 풀 모니터링이 불충분함
- 쿼리 성능 저하를 인지하지 못함

빈도: 매우 흔함 난이도: 중간

7. 지연 시간이 높은 서비스를 어떻게 문제 해결하나요?

답변: 체계적인 디버깅 접근 방식:

# 1. 문제 확인
curl -w "@curl-format.txt" -o /dev/null -s https://api.example.com/health

# curl-format.txt:
#     time_namelookup:  %{time_namelookup}s\n
#        time_connect:  %{time_connect}s\n
#     time_appconnect:  %{time_appconnect}s\n
#    time_pretransfer:  %{time_pretransfer}s\n
#       time_redirect:  %{time_redirect}s\n
#  time_starttransfer:  %{time_starttransfer}s\n
#                     ----------\n
#          time_total:  %{time_total}s\n

# 2. 애플리케이션 메트릭 확인
# - 요청률 (갑작스러운 급증?)
# - 오류율 (오류로 인한 재시도?)
# - 리소스 사용량 (CPU, 메모리)

# 3. 종속성 확인
# - 데이터베이스 쿼리 시간
# - 외부 API 호출
# - 캐시 적중률

# 4. 인프라 확인
top  # CPU 사용량
free -h  # 메모리
iostat  # 디스크 I/O
netstat -s  # 네트워크 통계

# 5. 오류 로그 확인
tail -f /var/log/app/error.log | grep -i "timeout\|slow\|error"

# 6. 애플리케이션 프로파일링
# Python 예시
import cProfile
cProfile.run('my_function()')

# 7. 데이터베이스 확인
# 느린 쿼리 로그
SELECT * FROM mysql.slow_log ORDER BY query_time DESC LIMIT 10;

# 활성 쿼리
SELECT pid, query, state, query_start 
FROM pg_stat_activity 
WHERE state = 'active';

일반적인 원인:

  • 데이터베이스 느린 쿼리
  • 외부 API 시간 초과
  • 메모리 부족 (GC 일시 중지)
  • 네트워크 문제
  • 리소스 소진
  • 비효율적인 코드 경로

빈도: 매우 흔함 난이도: 중간

자동화 및 스크립팅

8. 서비스가 정상인지 확인하고 필요한 경우 다시 시작하는 스크립트를 작성하세요.

답변: 상태 확인 및 자동 복구 스크립트:

#!/usr/bin/env python3
"""
자동 재시작 기능이 있는 서비스 상태 검사기
"""
import requests
import subprocess
import time
import sys
from datetime import datetime

class ServiceMonitor:
    def __init__(self, service_name, health_url, max_retries=3):
        self.service_name = service_name
        self.health_url = health_url
        self.max_retries = max_retries
    
    def check_health(self):
        """서비스가 정상인지 확인"""
        try:
            response = requests.get(
                self.health_url,
                timeout=5
            )
            return response.status_code == 200
        except requests.exceptions.RequestException as e:
            print(f"{datetime.now()}: 상태 확인 실패: {e}")
            return False
    
    def restart_service(self):
        """systemctl을 사용하여 서비스 재시작"""
        try:
            print(f"{datetime.now()}: {self.service_name} 재시작 중")
            subprocess.run(
                ['systemctl', 'restart', self.service_name],
                check=True,
                capture_output=True
            )
            time.sleep(10)  # 서비스 시작 대기
            return True
        except subprocess.CalledProcessError as e:
            print(f"{datetime.now()}: 재시작 실패: {e.stderr}")
            return False
    
    def send_alert(self, message, severity='warning'):
        """모니터링 시스템에 알림 전송"""
        try:
            requests.post(
                'https://alerts.company.com/webhook',
                json={
                    'service': self.service_name,
                    'message': message,
                    'severity': severity,
                    'timestamp': datetime.now().isoformat()
                },
                timeout=5
            )
        except Exception as e:
            print(f"알림 전송 실패: {e}")
    
    def monitor(self):
        """메인 모니터링 루프"""
        if self.check_health():
            print(f"{datetime.now()}: {self.service_name} 정상")
            return 0
        
        print(f"{datetime.now()}: {self.service_name} 비정상")
        self.send_alert(f"{self.service_name} 다운됨", severity='warning')
        
        # 재시도 시도
        for attempt in range(1, self.max_retries + 1):
            print(f"재시도 {attempt}/{self.max_retries}")
            
            if self.restart_service() and self.check_health():
                print(f"{datetime.now()}: 서비스 복구됨")
                self.send_alert(
                    f"{self.service_name} 재시작 후 자동 복구됨",
                    severity='info'
                )
                return 0
            
            time.sleep(5)
        
        # 모든 재시도 실패
        print(f"{datetime.now()}: 서비스 복구 실패")
        self.send_alert(
            f"{self.service_name} {self.max_retries}회 시도 후 복구 실패",
            severity='critical'
        )
        return 1

if __name__ == '__main__':
    monitor = ServiceMonitor(
        service_name='myapp',
        health_url='http://localhost:8080/health'
    )
    sys.exit(monitor.monitor())

빈도: 흔함 난이도: 중간

안정성 확보를 위한 실무

9. 런북이란 무엇이며 왜 중요한가요?

답변: 런북은 운영 작업 및 사고 처리를 위한 문서화된 절차입니다.

런북 구조:

# 런북: 높은 API 지연 시간

## 증상
- API 95번째 백분위수 지연 시간 > 1초
- 느린 페이지 로드에 대한 사용자 불만
- 알림: "HighAPILatency" 발생

## 심각도
**경고** - 사용자 경험을 저하시키지만 서비스는 작동 가능

## 조사 단계

### 1. 현재 메트릭 확인
```bash
# 지연 시간 분포 확인
curl -s http://prometheus:9090/api/v1/query?query='histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))'

# 요청률 확인
curl -s http://prometheus:9090/api/v1/query?query='rate(http_requests_total[5m])'

2. 병목 지점 식별

  • 데이터베이스 쿼리 시간 확인
  • 외부 API 호출 확인
  • 캐시 적중률 확인
  • 최근 배포 검토

3. 종속성 확인

# 데이터베이스 연결
mysql -e "SHOW PROCESSLIST;"

# Redis 지연 시간
redis-cli --latency

# 외부 API
curl -w "%{time_total}\n" -o /dev/null -s https://external-api.com/health

완화 단계

빠른 수정 (< 5분)

  1. 애플리케이션 인스턴스 확장
kubectl scale deployment api --replicas=10
  1. 캐시 TTL 임시 증가
redis-cli CONFIG SET maxmemory-policy allkeys-lru

문제가 지속되는 경우

  1. 최근 배포 롤백
kubectl rollout undo deployment/api
  1. 속도 제한 활성화
kubectl apply -f rate-limit-config.yaml

해결

  • 근본 원인 수정 (느린 쿼리, 비효율적인 코드)
  • 수정 사항 배포
  • 30분 동안 모니터링
  • 정상 용량으로 축소

에스컬레이션

30분 이내에 해결할 수 없는 경우:

  • 에스컬레이션 대상: @backend-team
  • Slack 채널: #incidents
  • 당직: PagerDuty 에스컬레이션 정책 사용

관련 항목


**런북이 중요한 이유:**
- 더 빠른 사고 대응
- 일관된 절차
- 지식 공유
- 사고 발생 시 스트레스 감소
- 새로운 팀원을 위한 교육 도구

**빈도:** 흔함
**난이도:** 쉬움

---

### 10. Graceful Degradation(점진적 기능 저하)의 개념을 설명하세요.

**답변:**
**점진적 기능 저하**는 시스템이 구성 요소가 실패하더라도 완전히 실패하는 대신 감소된 용량으로 계속 작동하는 것을 의미합니다.

**전략:**

**1. 기능 플래그:**
```python
# 높은 로드 시 중요하지 않은 기능 비활성화
class FeatureFlags:
    def __init__(self):
        self.flags = {
            'recommendations': True,
            'analytics': True,
            'search_autocomplete': True
        }
    
    def is_enabled(self, feature):
        # 오류 예산이 부족한 경우 중요하지 않은 기능 비활성화
        if self.error_budget_low():
            non_critical = ['analytics', 'search_autocomplete']
            if feature in non_critical:
                return False
        return self.flags.get(feature, False)
    
    def error_budget_low(self):
        # 오류 예산이 20% 미만인지 확인
        return get_error_budget() < 0.2

# 사용법
flags = FeatureFlags()
if flags.is_enabled('recommendations'):
    show_recommendations()
else:
    # Gracefully degrade - 정적 콘텐츠 표시
    show_popular_items()

2. 회로 차단기:

from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "closed"  # 정상 작동
    OPEN = "open"      # 실패, 요청 거부
    HALF_OPEN = "half_open"  # 복구 테스트

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60):
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.failures = 0
        self.last_failure_time = None
        self.state = CircuitState.CLOSED
    
    def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time > self.timeout:
                self.state = CircuitState.HALF_OPEN
            else:
                # 실패하는 서비스 호출 대신 대체 반환
                return self.fallback()
        
        try:
            result = func(*args, **kwargs)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            return self.fallback()
    
    def on_success(self):
        self.failures = 0
        self.state = CircuitState.CLOSED
    
    def on_failure(self):
        self.failures += 1
        self.last_failure_time = time.time()
        if self.failures >= self.failure_threshold:
            self.state = CircuitState.OPEN
    
    def fallback(self):
        # 캐시된 데이터 또는 기본 응답 반환
        return {"status": "degraded", "data": []}

# 사용법
breaker = CircuitBreaker()
result = breaker.call(external_api_call, user_id=123)

3. 시간 초과 및 재시도:

import requests
from requests.adapters import HTTPAdapter
from requests.packages.urllib3.util.retry import Retry

def create_resilient_session():
    session = requests.Session()
    
    # 재시도 전략
    retry = Retry(
        total=3,
        backoff_factor=0.3,
        status_forcelist=[500, 502, 503, 504]
    )
    
    adapter = HTTPAdapter(max_retries=retry)
    session.mount('http://', adapter)
    session.mount('https://', adapter)
    
    return session

# 시간 초과와 함께 사용
session = create_resilient_session()
try:
    response = session.get('https://api.example.com/data', timeout=5)
except requests.exceptions.Timeout:
    # Gracefully degrade - 캐시된 데이터 사용
    response = get_cached_data()

빈도: 흔함 난이도: 중간

컨테이너화 기본 사항

11. Docker란 무엇이며 가상 머신과 어떻게 다른가요?

답변: Docker는 애플리케이션을 종속성과 함께 패키징하는 컨테이너화 플랫폼입니다.

컨테이너 vs 가상 머신:

Loading diagram...

주요 차이점:

기능컨테이너가상 머신
시작 시간초분
크기MBGB
리소스 사용량가벼움무거움
격리프로세스 수준하드웨어 수준
OS호스트 OS 공유VM당 별도 OS

Docker 기본 사항:

# 이미지 풀
docker pull nginx:latest

# 컨테이너 실행
docker run -d \
  --name my-nginx \
  -p 8080:80 \
  nginx:latest

# 실행 중인 컨테이너 목록
docker ps

# 로그 보기
docker logs my-nginx

# 컨테이너에서 명령 실행
docker exec -it my-nginx bash

# 컨테이너 중지
docker stop my-nginx

# 컨테이너 제거
docker rm my-nginx

Dockerfile 예시:

# 기본 이미지
FROM python:3.12-slim

# 작업 디렉토리 설정
WORKDIR /app

# 요구 사항 복사
COPY requirements.txt .

# 종속성 설치
RUN pip install --no-cache-dir -r requirements.txt

# 애플리케이션 코드 복사
COPY . .

# 포트 노출
EXPOSE 8000

# 상태 확인
HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f http://localhost:8000/health || exit 1

# 애플리케이션 실행
CMD ["python", "app.py"]

빌드 및 실행:

# 이미지 빌드
docker build -t myapp:1.0 .

# 환경 변수와 함께 실행
docker run -d \
  --name myapp \
  -p 8000:8000 \
  -e DATABASE_URL=postgres://db:5432/mydb \
  -e LOG_LEVEL=info \
  myapp:1.0

# 리소스 사용량 보기
docker stats myapp

Docker Compose (다중 컨테이너):

services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://db:5432/mydb
    depends_on:
      - db
      - redis
    restart: unless-stopped
  
  db:
    image: postgres:14
    environment:
      - POSTGRES_DB=mydb
      - POSTGRES_PASSWORD=secret
    volumes:
      - postgres_data:/var/lib/postgresql/data
  
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  postgres_data:

Docker Compose로 실행:

# 모든 서비스 시작
docker compose up -d

# 로그 보기
docker compose logs -f web

# 서비스 확장
docker compose up -d --scale web=3

# 모든 서비스 중지
docker compose down

모범 사례:

  • 공식 기본 이미지 사용
  • 레이어 수 최소화
  • 루트로 실행하지 않기
  • .dockerignore 사용
  • 이미지 태그 적절하게 지정
  • 취약점 스캔

빈도: 매우 흔함 난이도: 쉬움-중간

버전 관리 및 배포

12. Git 워크플로우와 배포 처리 방법을 설명하세요.

답변: Git은 버전 관리 및 배포 자동화에 필수적입니다.

일반적인 Git 워크플로우:

Loading diagram...

기본 Git 명령어:

# 저장소 복제
git clone https://github.com/company/repo.git
cd repo

# 기능 브랜치 생성
git checkout -b feature/add-monitoring

# 변경 사항 작성 및 커밋
git add .
git commit -m "Prometheus 모니터링 추가"

# 원격으로 푸시
git push origin feature/add-monitoring

# 메인에서 업데이트
git checkout main
git pull origin main
git checkout feature/add-monitoring
git rebase main

# 기능 병합 (PR 승인 후)
git checkout main
git merge feature/add-monitoring
git push origin main

분기 전략:

1. Gitflow:

  • main: 프로덕션 준비 코드
  • develop: 통합 브랜치
  • feature/*: 새로운 기능
  • release/*: 릴리스 준비
  • hotfix/*: 긴급 수정

2. Trunk-Based Development:

# 수명이 짧은 기능 브랜치
git checkout -b feature/quick-fix
# < 1일 동안 작업
git push origin feature/quick-fix
# 리뷰 후 즉시 메인으로 병합

배포 워크플로우:

1. CI/CD 파이프라인 (GitHub Actions):

name: 프로덕션에 배포

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: 테스트 실행
        run: |
          npm install
          npm test
      
      - name: 린팅 실행
        run: npm run lint
  
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Docker 이미지 빌드
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker tag myapp:${{ github.sha }} myapp:latest
      
      - name: 레지스트리에 푸시
        run: |
          echo ${{ secrets.DOCKER_PASSWORD }} | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin
          docker push myapp:${{ github.sha }}
          docker push myapp:latest
  
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: 프로덕션에 배포
        run: |
          kubectl set image deployment/myapp \
            myapp=myapp:${{ github.sha }}
          kubectl rollout status deployment/myapp

2. 배포 스크립트:

#!/bin/bash
# deploy.sh - 간단한 배포 스크립트

set -e  # 오류 발생 시 종료

# 구성
APP_NAME="myapp"
VERSION=$(git rev-parse --short HEAD)
ENVIRONMENT=${1:-staging}

echo "$APP_NAME 버전 $VERSION을 $ENVIRONMENT에 배포 중"

# 테스트 실행
echo "테스트 실행 중..."
npm

마무리

주니어 SRE 면접은 SLO, 알림, 사고 대응, Linux 문제 해결, 안전한 자동화를 실제 사례와 함께 설명할 수 있는지 확인합니다. 좋은 답변은 명령어만 나열하지 않습니다. 사용자 영향을 먼저 파악하고, 신뢰할 수 있는 신호를 확인하고, 낮은 위험으로 완화한 뒤, 배운 점을 문서화하는 흐름을 보여줍니다.

Newsletter subscription

실제로 효과가 있는 주간 커리어 팁

최신 인사이트를 받은 편지함으로 직접 받아보세요

관련 게시물

주니어 DevOps 엔지니어 면접 질문과 답변
12월 21, 2025
41 분 읽기

주니어 DevOps 엔지니어 면접 질문과 답변

Linux 문제 해결, Git, CI/CD, Docker, 클라우드 기초, Terraform, 모니터링, Kubernetes, Bash를 실전 질문으로 준비하세요.

Milad BonakdarMilad Bonakdar
주니어 AWS 클라우드 엔지니어 면접 질문과 답변
12월 21, 2025
30 분 읽기

주니어 AWS 클라우드 엔지니어 면접 질문과 답변

EC2, S3, VPC, IAM, CloudWatch와 기본 운영 시나리오를 중심으로 주니어 AWS 클라우드 엔지니어 면접을 준비하세요.

Milad BonakdarMilad Bonakdar
주니어 머신러닝 엔지니어 면접 질문
12월 21, 2025
45 분 읽기

주니어 머신러닝 엔지니어 면접 질문

주니어 ML 엔지니어 면접을 위해 Python, 모델 평가, 데이터 누수, 배포, 모니터링, MLOps 기초 질문과 답변 포인트를 준비하세요.

Milad BonakdarMilad Bonakdar

채용률을 60% 높이는 이력서 만들기

몇 분 만에 면접을 6배 더 많이 받는 것으로 입증된 맞춤형 ATS 친화적 이력서를 만드세요.

더 나은 이력서 만들기

이 게시물 공유

50% 더 빠르게 채용되세요

전문적이고 AI로 강화된 이력서를 사용하는 구직자는 표준 10주에 비해 평균 5주 만에 일자리를 얻습니다. 기다리지 말고 면접을 시작하세요.

구직 활동 가속화