Devsisters 기술 블로그

Kafka Streams를 k8s로 옮기며 얻은 스케일링 설계: 비용 80% 절감까지

Thu, 03 Sep 2026 00:00:00 GMT

안녕하세요. 기술본부 데이터엔지니어링셀 김태완입니다.

이 글에서는 AWS EC2 기반으로 운영되던 Log Transformer(Kafka Streams 애플리케이션)를 Kubernetes(이하 k8s)로 마이그레이션하면서, Kafka consumer 워크로드에 맞는 스케일링 정책을 설계한 과정과 그 결과를 공유합니다.

이 글에서 다루는 내용은 다음과 같습니다.

CPU 기반 HPA가 Kafka consumer 워크로드에 부적합한 이유
KEDA와 consumer lag을 활용한 도메인 메트릭 기반 스케일링 설계
자정 트래픽 급증에 cron trigger로 선제 대응하는 방법
pod당 thread 다중화로 JVM 오버헤드와 rebalance 이벤트를 줄이는 방법
그 결과로 얻은 EC2 대비 80% 이상의 인프라 비용 절감

#배경: EC2 기반 Log Transformer의 한계

Log Transformer는 여러 Kafka topic에서 원본 로그를 읽어 검증·변환한 뒤, 게임별 Kafka topic으로 다시 produce하는 Kafka Streams 애플리케이션입니다. 여러 source topic의 원본 로그를 게임·용도별 topic으로 분기시키므로, 후속 파이프라인은 필요한 topic만 골라 소비할 수 있습니다.

기존에는 c6g.2xlarge 인스턴스 72대 위에서 운영되고 있었으며, 다음과 같은 한계를 안고 있었습니다.

트래픽 패턴과 어긋나는 인스턴스 운영: 원래는 ASG(Auto Scaling Group)에 cron 기반 스케줄을 걸어 시간대에 따라 36대와 72대를 오가도록 운영했습니다. 그러나 이 방식이 불안정해 결국 피크 기준인 72대로 고정하게 되었고, 트래픽이 적은 시간대에도 같은 규모를 그대로 유지하고 있었습니다.
스케일링의 경직성: 트래픽 변화에 맞추려면 그때마다 사람이 ASG 설정을 직접 바꿔야 했습니다.
배포 파이프라인의 복잡성: Spinnaker 기반 EC2 배포는 단계가 많고 반영까지 오래 걸려 단순한 설정 변경에도 부담이 컸습니다.

이 한계들은 결국 트래픽에 실시간으로 반응하는 자동 스케일링과 빠르고 단순한 배포가 없다는 데서 비롯됐습니다. k8s는 HPA, KEDA 같은 오토스케일러로 트래픽 변화에 자동으로 반응할 수 있고, 선언형 매니페스트와 GitOps 배포로 설정 변경 부담도 줄일 수 있습니다. 그래서 저희는 Log Transformer를 k8s 기반으로 전환하기로 결정했습니다.

마이그레이션의 첫 단계로, 하나의 애플리케이션이 여러 source topic을 함께 consume하던 구조를 source topic별 독립 Kafka Streams 애플리케이션으로 분리했습니다. topic마다 트래픽 패턴이 다르므로 스케일링 정책을 독립적으로 적용하고, 장애와 배포를 topic 단위로 격리하기 위함이었습니다. 이렇게 구조 분리를 마친 뒤, 본격적으로 스케일링 정책 설계에 들어갔습니다.

#첫 시도: CPU 기반 HPA가 실패한 이유

k8s로 올린 뒤 가장 먼저 시도한 것은 기본적인 CPU 기반 HPA(Horizontal Pod Autoscaler)였습니다. 이 글의 YAML에 나오는 replica 수와 임계값은 설명을 위한 예시 값입니다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: log-transformer-hpa
spec:
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

결과는 기대와 달랐습니다. 하나의 partition은 consumer group 안에서 한 consumer(여기서는 pod)에만 배정되므로, partition이 consumer들에 고르게 나뉘어야 부하도 고르게 퍼집니다. 그러나 실제로는 partition이 consumer에 고르게 분배되지 않아, 일부 pod가 CPU 100%에 도달하는 동안에도 평균 CPU는 target 아래에 머물러 HPA가 반응하지 않았습니다.

#나누어떨어지지 않는 partition과 부하 집중

Kafka Streams는 partition을 task 단위로 묶어 StreamsPartitionAssignor로 분배하며, 각 인스턴스가 가진 stream thread 수에 비례해 task를 나눠줍니다. 문제는 그다음입니다. task 수가 전체 thread 수로 나누어떨어지지 않으면 남는 task는 어딘가로 가야 하므로, 일부 consumer가 task를 1개씩 더 받고 그만큼 부하가 집중됩니다.

이것은 특정 할당 전략의 약점이 아닙니다. task 수가 전체 thread 수로 나누어떨어지지 않는 한, 어떤 할당 전략을 쓰더라도 남는 편차입니다.

[상황 예시: partition 6개, consumer 4대]

6 / 4 = 1 나머지 2 → consumer 2대가 partition을 1개씩 더 가져갑니다.

Consumer A: partition 0, 1  → CPU 80%
Consumer B: partition 2, 3  → CPU 80%
Consumer C: partition 4     → CPU 40%
Consumer D: partition 5     → CPU 40%

평균 CPU: 60%
HPA target: 70%
→ 스케일링 조건 미충족. Consumer A, B는 처리가 밀립니다.

#CPU 평균 지표의 전제 조건

여기서 lag은 topic에 쌓인 메시지 중 consumer가 아직 처리하지 못한 메시지 수를 뜻합니다. partition이 많이 할당된 consumer에서는 처리가 밀려 lag이 쌓이고 해당 pod의 CPU도 100%까지 치솟지만, pod 수가 많아 평균 CPU는 target 이하에 머물기 때문에 HPA는 끝내 반응하지 않습니다.

CPU 평균은 워크로드가 애플리케이션의 pod 전체에 고르게 분산된다는 전제에서만 유효한 지표입니다. Kafka consumer처럼 partition 단위로 부하가 묶이는 워크로드에는 이 전제가 성립하지 않습니다.

#해결: KEDA와 consumer lag 기반 스케일링

문제의 핵심은 CPU가 이 워크로드의 실제 부하를 제대로 대변하지 못한다는 점이었습니다. 부하를 직접 나타내는 지표인 lag으로 스케일링해야 했습니다. HPA도 external metric을 지원하기는 하지만, Kafka lag을 노출하는 metrics adapter를 따로 붙이고 운영해야 합니다. 그래서 다양한 이벤트 소스를 스케일링 기준으로 삼을 수 있는 KEDA(Kubernetes Event-Driven Autoscaling)를 도입했습니다.

#KEDA 도입과 lagThreshold 설정

KEDA의 Kafka scaler는 consumer group의 lag을 직접 조회해 그 값을 기준으로 스케일링합니다.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: log-transformer
spec:
  scaleTargetRef:
    name: log-transformer
  minReplicaCount: 2
  maxReplicaCount: 10
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka-broker:9092
        consumerGroup: log-transformer-group
        topic: log-topic
        lagThreshold: '100'

lagThreshold는 replica 1개가 감당할 lag의 기준값입니다. KEDA는 전체 lag을 이 값으로 나눈 만큼 replica를 늘리며, replica 수는 partition 수를 넘지 않습니다.

#lag 기반 스케일링의 장점

도메인 메트릭 기반: 범용 지표가 아닌, Kafka consumer 워크로드에서 비롯한 지표로 판단합니다.
partition 할당 개수의 불균형에도 반응: 개별 consumer의 CPU가 아니라 전체 lag 총량을 기준으로 하므로, partition이 불균등하게 분배되어 평균 CPU가 낮게 나오는 상황에서도 스케일 판단이 이뤄집니다. 다만 특정 partition 하나에 트래픽이 몰리는 경우라면 replica를 늘려도 그 partition의 처리량은 늘지 않으므로, 이때는 partition 설계 자체를 다시 봐야 합니다.
scale-to-zero 지원: source topic에 데이터가 들어오지 않는 시간대에는 pod 수를 0까지 줄였다가, 메시지가 다시 쌓이기 시작하면 그때 pod를 띄워 처리할 수 있습니다. 저희는 트래픽이 간헐적인 개발 환경 topic에 이 방식을 적용해 idle 비용을 제거했고, 운영 환경 topic은 처리 지연을 피하기 위해 최소 replica를 유지합니다.

#보완: 자정 트래픽 급증과 cron trigger

KEDA를 적용한 뒤 대부분의 시간대는 안정적으로 운영됐지만, lag 기반 스케일링만으로는 대응이 늦는 구간이 하나 있었습니다.

많은 게임이 자정(0시)을 기준으로 일일 미션·출석 같은 콘텐츠를 초기화하는데, 그 시점에 관련 배치 작업과 일간 집계 로그가 한꺼번에 쏟아지면서 트래픽이 급증하는 패턴이 있었습니다. consumer lag 기반 스케일링은 lag이 쌓인 뒤에 반응하므로, 이렇게 급격한 트래픽 증가에는 대응이 늦을 수밖에 없습니다. 게다가 새 pod가 ready 상태가 되어 consumer group rebalance까지 마쳐야 비로소 처리가 시작되고, 여기에 JVM warm-up 시간까지 더해지므로, scale out이 완료되기 전까지 lag이 계속 치솟고 그만큼 다운스트림 파이프라인으로의 로그 전달이 지연됩니다.

#cron trigger로 선제 대응

KEDA는 Kafka scaler 외에도 cron trigger를 지원합니다. 0시 직전에 미리 pod 수를 늘려놓는 방식으로 해결했습니다.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: log-transformer
spec:
  scaleTargetRef:
    name: log-transformer
  minReplicaCount: 2
  maxReplicaCount: 10
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka-broker:9092
        consumerGroup: log-transformer-group
        topic: log-topic
        lagThreshold: '100'
    - type: cron
      metadata:
        timezone: Asia/Seoul
        start: '50 23 * * *' # 23:50에 scale out
        end: '30 0 * * *' # 00:30에 cron trigger 해제
        desiredReplicas: '8'

Kafka lag trigger와 cron trigger를 함께 사용하면, KEDA는 두 trigger 중 더 높은 replica 수를 채택합니다. 23:50에 미리 8대로 늘려놓고 0시 트래픽을 흡수한 뒤, 00:30 이후에는 lag 기반으로 자연스럽게 scale in됩니다.

#최적화: thread 다중화로 rebalance 이벤트 줄이기

스케일링 정책과 자정 대응까지 정리한 뒤, 마지막으로 pod 구성 자체를 재설계했습니다. pod 1대에 Kafka Streams thread 1개를 두는 단순한 구조는 운영이 쉽지만, JVM 기동 오버헤드가 pod 수만큼 선형으로 늘고, pod 수명 주기 이벤트(재시작, rolling deploy, eviction)가 곧 consumer group rebalance의 트리거로 이어집니다.

이를 줄이기 위해 저희는 pod 1대가 여러 개의 Kafka Streams thread를 동시에 실행하도록 구성했습니다. Kafka Streams는 num.stream.threads 설정으로 인스턴스(=pod)당 여러 stream thread를 띄우는 것을 지원하며, 각 thread는 독립적으로 task(partition 묶음)를 할당받아 처리합니다(Kafka Streams Architecture). consumer group 입장에서는 thread 하나하나가 독립 consumer처럼 동작하므로, pod당 thread 수를 늘려도 partition 분배와 처리 정합성은 그대로 유지됩니다. 즉 전체 consumer thread 수는 동일하게 두고 pod 수만 줄이는 변경이어서, JVM 인스턴스 수와 메모리 오버헤드, 그리고 수명 주기 이벤트의 절대 빈도를 함께 낮출 수 있었습니다.

다만 pod 1대에 더 많은 thread가 묶이는 만큼 pod 1대의 장애 영향 범위는 커지므로, pod당 thread 수는 무한정 늘리지 않고 아래의 CPU 할당 기준에 맞춰 제한했습니다.

thread 수는 thread 간 CPU 경합을 피하기 위해 thread당 CPU core 1개를 기준으로 잡고, pod의 CPU request/limit을 거기에 맞췄습니다. 예를 들어 6 thread를 실행하는 pod에는 6 core를 할당합니다. Kafka Streams의 capacity planning 가이드도 stream thread 수를 가용 CPU core 규모에 맞춰 잡도록 권하는데, 저희는 처리량을 예측 가능하게 만들기 위해 thread당 1 core로 다소 보수적으로 운영했습니다. 이렇게 하면 pod당 처리량이 안정적으로 유지되고, lag 기반 스케일링이 기준으로 삼는 "pod 1대가 흡수할 수 있는 lag 처리량"도 예측 가능한 값으로 수렴합니다.

#결과: 트래픽에 맞춘 리소스 운영과 비용 절감

#비용 절감 수치

EC2 고정 인스턴스 운영 대비, k8s + KEDA 기반으로 전환한 후 80% 이상의 인프라 비용을 절감할 수 있었습니다.

항목	EC2 기반	k8s + KEDA
스케일링	72대 고정 (스케줄 조정은 중단)	자동 (lag 기반 + cron)
비용	24시간 고정 비용	트래픽에 비례하는 비용
운영 부담	게임 추가 시 인스턴스 증설 등 인프라 작업 필요	설정 배포로 완료

80%라는 수치 자체보다 중요한 것은 운영 방식의 변화입니다. EC2에서는 피크 기준으로 인스턴스를 상시 유지해야 했지만, KEDA 기반에서는 새벽에 2대까지 줄었다가 피크에만 scale out되어 그 순간의 부하에 맞는 만큼만 pod를 할당합니다. 80%는 현재 트래픽 패턴에서 측정된 결과이며, 트래픽 패턴이 바뀌어도 리소스가 그에 따라 움직인다는 점이 핵심입니다.

#운영 부담 감소

게임 추가 시 Helm chart에 값만 추가하면 됩니다.
스케일링 정책을 Helm chart로 관리하므로 리뷰와 이력 추적이 가능합니다.
image tag와 환경 변수 변경만으로 ArgoCD를 통해 배포할 수 있어, 기존 Spinnaker 기반 EC2 파이프라인 대비 배포 준비와 반영 시간이 크게 줄었습니다.

#남은 과제: thread 단위까지 고려한 partition 균등 분배

현재 구성에서도 lag 기반 스케일링은 안정적으로 동작하지만, partition이 consumer에 균등하게 분배되지 않는 근본적인 문제는 남아 있습니다.

KEDA의 ensureEvenDistributionOfPartitions 옵션은 전체 partition 수의 약수로 replica 수를 제한해 이 문제를 해소합니다. 다만 이 옵션이 검사하는 것은 partition 수 / replica 수뿐입니다. pod 1대가 여러 thread를 띄우는 구성에서 실제로 partition을 나눠 갖는 주체는 pod가 아니라 thread이므로, 성립해야 할 조건은 partition 수 / (replica 수 × pod당 thread 수)가 정수인지입니다. 앞서 source topic별로 배포를 분리해둔 덕분에 pod 1대가 topic 하나를 전담하므로, 여기서 pod당 thread 수는 곧 그 topic을 처리하는 thread 수가 됩니다.

24 partition을 pod당 4 thread로 처리한다면, 옵션이 허용하는 replica는 24의 약수인 1, 2, 3, 4, 6, 8, 12, 24이지만, thread 단위까지 균등한 replica는 1, 2, 3, 6뿐입니다. 나머지 값에서는 두 가지 증상이 나타납니다.

replica 4: pod 단위로는 6 task씩 균등하지만, 전체 16 thread에 24 task가 나뉘어 thread 8개는 task 2개를, 나머지 8개는 1개를 받습니다. thread 간 처리량이 최대 2배까지 벌어집니다.
replica 8 이상: thread 수가 task 수를 넘어섭니다. replica 8이면 32개 thread 중 8개가, replica 24라면 96개 thread 중 72개가 아무 task도 받지 못한 채 빈 poll 루프만 돌게 됩니다.

replica 상한도 마찬가지입니다. KEDA는 replica 수를 partition 수 이하로 제한하는데, 이 상한 역시 pod당 thread 수를 모르는 채 계산됩니다. 결국 균등 분배를 thread 수준까지 끌어내리려면 KEDA가 pod당 thread 수까지 알고 replica를 결정해야 합니다.

이 공백을 메우기 위해 KEDA 저장소에 옵션 추가 issue를 올려두었고, 현재 threadsPerConsumer라는 이름의 구현 PR이 올라와 리뷰가 진행 중입니다. ensureEvenDistributionOfPartitions와 함께 이 값에 pod당 thread 수를 지정하면, KEDA가 partition 수가 아니라 partition 수 / threadsPerConsumer의 약수 중에서 replica를 고르게 됩니다. 앞의 예시라면 24가 아닌 6의 약수, 즉 1, 2, 3, 6만 후보가 되어 pod 단위와 thread 단위 모두에서 균등한 분배를 보장할 수 있습니다.

한편 더 근본적으로는, Scala로 작성된 Log Transformer를 대체할 확장된 역할의 컴포넌트를 Rust로 작성하는 작업도 진행 중입니다. JVM 기동 오버헤드와 GC 지연 감소, CPU·메모리 사용량 절감, throughput 향상을 기대하고 있으며, threadsPerConsumer 옵션의 진행 상황과 함께 결과가 정리되는 대로 별도의 글로 공유드리겠습니다.

#마치며: 워크로드 특성에 맞는 스케일링 메트릭

이번 마이그레이션에서 저희가 다시 확인한 것은 한 가지였습니다.

스케일링 메트릭은 워크로드의 부하 특성에 맞춰 골라야 합니다.

CPU 사용률은 부하가 pod 전반에 고르게 퍼지는 워크로드라면 충분히 유효한 지표입니다. 다만 Kafka consumer처럼 partition 단위로 부하가 묶이는 워크로드에서는 평균 CPU만으로 실제 처리 지연을 포착하기 어려웠습니다. 저희는 consumer lag을 기준으로 삼아 스케일링의 정확도를 높일 수 있었습니다.

KEDA는 Kafka 외에도 RabbitMQ, AWS SQS, Prometheus metrics 등 다양한 이벤트 소스에 대한 scaler를 제공합니다. CPU 외의 지표를 스케일링 기준으로 손쉽게 가져올 수 있다는 점이 저희에게는 가장 큰 장점이었습니다.

Kafka consumer 스케일링에 비슷한 고민이 있으시다면, consumer lag 기반 스케일링을 검토해보시길 권합니다.

감사합니다.

킹덤 서버! 튜토리얼

Tue, 02 Jun 2026 00:00:00 GMT

안녕하세요, 킹덤 서버셀에서 소프트웨어 엔지니어로 근무하고 있는 노수지입니다. 이번 글에서는 킹덤 서버셀에 합류한 이후, 지난 1년 동안 팀의 기술 문화를 체득하고 실제 서비스 코드에 기여하기까지의 과정을 정리해 보려 합니다. 킹덤 서버팀은 Scala를 활용한 함수형 프로그래밍(FP) 지향적인 코드베이스를 보유하고 있습니다. 저 또한 합류 당시에는 함수형 프로그래밍에 익숙하지 않았기에, 이러한 기술 스택은 큰 도전이자 생소한 과제로 다가왔습니다.

이 글에서는 저처럼 해당 패러다임에 낯선 개발자들을 위해 킹덤 팀이 어떤 체계적인 온보딩 시스템과 가이드를 제공하고 있는지 소개하려 합니다. 신규 입사자가 이러한 팀의 지원을 통해 어떻게 기술적 장벽을 넘고 개발 프로세스에 안정적으로 합류하게 되는지 그 여정을 공유하고자 합니다.

#Stage 1. 함수형 프로그래밍 이해하기

입사 후 가장 먼저 테크리드님이 직접 작성하신 스칼라 학습 레포지토리를 전달받았습니다. 기본 조건문과 반복문부터 시작해 Scala 고유의 문법과 함수형 프로그래밍(FP)의 정수를 익힐 수 있도록 설계된 실습용 코드들이 가득했습니다. 이 과정에서 “기존 값을 수정하지 않고 새로운 상태를 생성한다” 는 함수형 패러다임을 체득하게 됩니다.

#part 1. 순수 함수

Java와 같은 명령형 언어에서는 객체 내부의 필드를 직접 수정(Mutation)하여 상태를 변경합니다. 반면, 스칼라의 순수함수는 불변성(Immutability) 을 원칙으로 합니다. 예를 들어, Java에서 Map의 값을 수정하면 기존 Map 객체 자체가 변하지만, 스칼라에서는 기존 Map은 그대로 둔 채 변경사항이 반영된 새로운 Map 객체를 반환합니다. 이 구조는 동일한 입력에 대해서 항상 동일한 출력을 보장합니다. 수학에서 많이 보이는 y = f(x)의 f가 순수 함수입니다.

그렇다면 "새롭게 만들어진 객체는 어디에 적용(set)되는가?"라는 의문이 생길 수 있습니다. 순수함수의 세계에서 함수는 외부의 상태를 직접 바꾸는 '액션'을 취하지 않습니다. 대신 "입력값(A)을 넣으면 결과값(B)이 나온다" 는 정의에만 집중합니다. 이 방식에서 상태값은 어딘가에 고정되어 변하는 것이 아닙니다. 대신, '현재 상태를 토대로 다음 상태를 계산하는 함수들' 이 체인처럼 연결되어 흐릅니다. 각 함수는 이전 단계에서 계산된 최신 상태를 전달받아 새로운 상태를 만들어내고, 이 과정이 끝까지 흐르면 최종적으로 계산된 상태값이 도출됩니다. 이렇게 완성된 설계도는 프로그램의 가장 바깥쪽 레이어(Runtime)에 도달해서야 비로소 실제 저장소에 반영(set)되거나 처리됩니다.

class Library {
    private Set<BookId> books = new HashSet<>();
    private Map<BookId, String> borrowedBooks = new HashMap<>();
    
    // 기존 객체 내부의 상태(Map)를 직접 수정 (Side Effect)
    public void borrowBook(BookId bookId, String username) {
        borrowedBooks.put(bookId, username);
    }
}

가변 객체를 이용하는 Java

case class Library(
    books: Set[BookId],
    borrowedBooks: Map[BookId, String]
) {
    // 기존 상태를 수정하지 않고, 변경된 데이터가 담긴 새 Library 인스턴스를 반환
    def borrowBook(bookId: BookId, username: String): Library = {
        // copy를 통해 변경된 부분만 교체한 새 객체 생성
        copy(borrowedBooks = borrowedBooks.updated(bookId, username))
    }
}

불변 객체를 이용하는 스칼라

#part 2. 함수를 일급 객체로 다루기

스칼라에서는 함수를 일급 객체(First-class Object) 로 취급합니다. 이는 함수를 변수에 담을 수도, 다른 함수의 인자로 전달할 수도, 혹은 함수의 결과값으로 반환할 수도 있음을 의미합니다. 이러한 특징을 가장 직관적으로 보여주는 것이 바로 람다식(익명 함수) 입니다. 람다식은 복잡한 선언 없이 (입력값) => 로직의 형태로 즉석에서 함수를 정의합니다.

// 1. 함수를 변수에 할당
val double = (x: Int) => x * 2
val four = double(2)

// 2. 고차 함수에서의 활용
// 별도의 메서드 정의 없이, 람다식을 통해 '어떻게 처리할지'의 로직만 가볍게 전달합니다.
val numbers = List(1, 2, 3)
val doubledList = numbers.map(x => x * 2) // 각 요소에 람다 적용

람다식을 사용하면 코드가 극도로 간결해질 뿐만 아니라, 로직 자체를 값으로 취급해 이리저리 전달할 수 있게 됩니다. 이는 앞서 언급한 순수함수와 결합해, 거대한 비즈니스 로직을 작은 함수들의 조립식 결합으로 해결합니다.

더 자세한 스칼라와 함수형 프로그래밍 이야기를 듣고 싶다면 현수님의 기술블로그를 추천합니다.

#Stage 2. ZIO/ZPure 이해하기

스칼라 기초를 다진 후에는 학습서 Zionomicon을 통해 킹덤 아키텍처의 핵심인 ZIO와 ZPure를 학습합니다. ZIO는 실제 실행하는 계층(DB I/O, 통신 등)에서 ZPure는 결과를 계산하는 계층에서 사용됩니다.

#part 1. 순수한 레이어를 위한 ZPure

ZPure는 부수 효과와 완전히 격리된 로직을 설계할 때 사용합니다. ZPure[W, S1, S2, R, E, A]라는 복잡한 타입을 가지는데, 이는 "환경 R과 초기 상태 S1이 주어졌을 때, 로그(Chunk[W])를 남기고 상태를 S2로 변화시키며, 에러 E 혹은 결과 A를 반환함" 을 의미합니다.

(S1, R) => (Chunk[W], E | A)

ZPure의 가장 큰 특징은 부수 효과(Side-Effect)가 전혀 없다는 점입니다. 오직 입력된 값(R, S)만을 이용해 결과를 만들어내기 때문에, 동일한 입력에는 항상 동일한 결과가 보장됩니다. 예를 들어, 재고 상태(S1)를 받아 모든 재고를 0으로 만드는 로직은 아래와 같이 작성할 수 있습니다.

// 상태 S1 내의 stocks 전 재고를 0으로 만드는 순수 로직
lazy val reset: ZPure[Nothing, S1, S2, Any, Nothing, Unit] = {
  for {
    s1 <- ZPure.get[S1]
    // 기존 상태를 복사하여 새로운 상태 s2를 생성 (순수 계산)
    s2 = s1.copy(stocks = s1.stocks.mapValuesCompat(_ => 0))
    _  <- ZPure.set(s2)
  } yield ()
}

여기서 reset은 실제로 DB를 수정하는 것이 아니라, "상태가 이렇게 변해야 한다"라는 계산 결과만을 안전하게 만들어냅니다.

#part 2. 실행을 위한 Effect인 ZIO

우리가 ZPure로 짠 로직은 그 자체로는 아무런 일도 일으키지 않는 설계도와 같습니다. 비유하자면, ZPure는 "요리 레시피"를 작성하는 과정이고, 이 레시피(로직)가 실제 요리(실행)로 이어지기 위해서는 이를 감싸 안는 '효과'의 단위로 변환되어야 합니다. 킹덤 아키텍처는 이 '순수한 레시피'를 먼저 완성한 뒤, 이를 실제로 실행시켜 우리가 아는 게임 서비스를 제공합니다.

ZPure가 만든 순수한 결과물은 최종적으로 ZIO를 통해 현실에서 실행됩니다. ZIO[R, E, A] 환경 R에서 에러 E 혹은 결과 A를 반환하는 '효과'를 나타내며, ZPure와 달리 DB 조회, 네트워크 통신, 로깅 등 실제 부수 효과(Side-Effect) 를 관리하고 실행합니다. 이러한 계층 구조를 갖는 이유는 부수 효과에 대한 통제력 때문입니다.

먼저 ZPure에서 복잡한 도메인 로직을 오류 없이 계산합니다. (테스트가 쉽고 안전함)
계산된 결과를 바탕으로 ZIO가 외부 시스템(DB 등)과 상호작용합니다.
이 과정에서 ZIO는 동시성 제어(Fiber), 재시도 로직(Retry), 리소스 관리 등의 런타임 기능을 제공합니다.

결과적으로 "순수하게 계산된 결과를 기반으로, 부수 효과가 있는 ZIO를 실행시킨다" 는 원칙을 지킴으로써, 코드의 예측 가능성을 높이고 버그가 파고들 틈을 최소화합니다. 이 아키텍처에 대해 더 깊이 알고 싶다면 테크리드님의 블로그 글을 참고해 보시기 바랍니다.

ZPure로 순수하게 계산한 결과를 ZIO로 실행하는 Tri-Z 구조

#Final Stage. 라이브 서비스에 코드 작성하기

#part 1. 테스트 짜기

Scala와 ZIO에 익숙해졌다면, 이제 메인 레포지토리에 직접 코드를 작성할 차례입니다. 처음부터 수많은 동시성 처리와 대규모 데이터 모델이 포함된 핵심 시스템(또는 대형 인게임 콘텐츠) 개발에 바로 투입되기보다는, 시스템의 맥락과 팀 내 컨벤션을 파악하기 위해 테스트 코드 작성부터 시작하게 됩니다.

킹덤의 대표 대형 컨텐츠인 에피소드, 한 컨텐츠에 여러 기능이 섞여있습니다.

킹덤 서버의 테스트는 크게 유닛 테스트(Unit Test) 와 시나리오 테스트(Scenario Test) 두 가지 계층으로 나뉩니다. 킹덤의 소원나무 기능을 예시로 설명하겠습니다.

킹덤의 소원나무 기능

유닛 테스트는 이름 그대로 기능의 최소 단위가 의도대로 작동하는지 검증합니다. 앞서 배운 순수함수가 실제 도메인 규칙을 잘 지키고 있는지 확인하는 단계입니다.

'소원 하나 들어주기' 기능을 테스트한다면 아래 항목들을 개별적으로 확인합니다.
요구 품목인 아이템이 정확히 소모되었는가?
개별 소원에 따른 보상이 유저 인벤토리에 정확히 들어왔는가?
일일 보상 게이지가 로직에 맞게 상승했는가?

시나리오 테스트는 여러 기능이 맞물려 돌아가는 사용자 시나리오에서 시스템이 올바르게 반응하는지 확인합니다. 킹덤의 소원나무처럼 특정 횟수 이상의 소원을 들어주었을 때 발생하는 '일일 보상(보물상자) 획득' 같은 흐름이 대표적인 대상입니다.

N개의 소원을 들어주었을 때, 누적 횟수가 정확히 카운트되는가?
일일 게이지가 목표치에 도달했을 때 보상 획득 활성화 상태가 정상적으로 변경되는가?
실제 보상 획득 시, 보상 아이템이 지급됨과 동시에 게이지가 초기화되거나 다음 단계로 넘어가는가?

#part 2. 작은 버그 수정해보기

테스트 작성에 어느 정도 익숙해질 즈음부터는, 실제 코드에 존재하는 사소한 버그를 수정하거나 데이터 검증 로직을 강화하는 업무를 맡게 됩니다. 예를 들어, '개발맛 쿠키의 젤리 15종 물리치기' 라는 콘텐츠가 있다고 가정해 봅시다. 서버와 클라이언트는 각각 1번부터 15번 젤리에 대한 정보를 관리하고 있습니다. 만약 유저가 단 하나의 젤리도 처치하지 못한 채 게임이 종료되면, 기존 클라이언트에서는 기본값으로 '0' 을 전송하고 있었습니다.

하지만 서버에는 '0번 젤리'에 대한 데이터가 존재하지 않았기에 에러가 발생했고, 결과적으로 유저는 "해당 요청을 처리하는 데 문제가 발생했습니다" 라는 문구를 마주하며 정상적으로 게임을 마칠 수 없는 상황이었습니다. 킹덤 팀은 이 문제를 해결하기 위해 "1번 젤리조차 처치하지 못한 경우 클라이언트는 0 대신 Empty(None)를 보내고, 서버는 콘텐츠 참여 보상만 지급한다" 는 결론을 내렸습니다. 이때 제가 맡은 업무가 바로 이 예외 상황을 안전하게 처리하도록 기존 로직을 수정하는 것이었습니다.

def finishJellyWave(wave: Int): List[Reward] = 
  for {
    // wave가 0일 경우, 데이터를 찾지 못해 에러(Exception) 발생
    clearRewardDatas <- inquireJellyWaveClearRewards(wave) 
    playRewardDatas  <- inquireJellyWavePlayRewards       // 게임 입장 보상 조회
    rewards          <- rewards(clearRewardDatas ++ playRewardDatas)
  } yield rewards

수정전: 젤리를 하나도 물리치지 못했을 때, 에러 발생

def finishJellyWave(waveOpt: Option[Int]): List[Reward] = 
  for {
    // 패턴 매칭을 통해 클리어한 웨이브가 있을 때만 보상을 조회하도록 수정
    clearRewardDatas <- waveOpt match {
      case Some(wave) => inquireJellyWaveClearRewards(wave)
      case None       => ZPure.succeed(Nil) // 처리한 웨이브가 없어도 에러 없이 통과
    }
    playRewardDatas <- inquireJellyWavePlayRewards
    rewards         <- rewards(clearRewardDatas ++ playRewardDatas)
  } yield rewards

수정 후: 젤리를 하나도 물리치지 못했을 때, 기본 보상 지급

#part 3. 본격적인 콘텐츠 개발

특정 콘텐츠의 담당자로 배정되면, 먼저 킥오프 회의에서 기획에 대해 설명을 듣습니다. 해당 기획을 바탕으로 기획자 및 클라이언트 개발자분들과 협의하여 데이터 구조를 설계합니다. 데이터 구조 설계와 기능 정의가 완료되면 본격적인 구현에 들어갑니다.

예를 들어, 조커 뽑기와 유사한 '카드 뽑기 게임' 을 만든다고 가정해 봅시다. 기획안이 간단하여 서버는 결과 조회 및 보상 지급 기능만 구현하면 되는 상황입니다. 클라이언트에서 "n번째 카드를 뽑겠다"는 요청을 보내면, 서버는 슬롯 데이터를 무작위로 섞은 뒤 당첨된 보상이 무엇인지 판정하여 응답을 내려줍니다.

// 잘못된 코드
lazy val finishShellGame: Result[(List[ShellGameIndex], Int, List[Reward])] = 
  for {
    shellGameData <- inquireShellGameData // 게임 설정값 조회
    slots         =  shellGameData.slots
    _             <- shuffle(slots) // 각 슬롯을 섞음
    selectedSlot  =  Random.randInt(0, slots.size) // 당첨 슬롯 결정
    rewards       <- rewards(shellGameData.slot(selectedSlot).rewards) // 보상 획득
    _             <- liftEvent(ShellGameFinished(slots, selectedSlot, rewards)) // 상태 변경 이벤트 발생
  } yield (slots, selectedSlot, rewards)

초안

구현을 마친 후 서버를 띄워 테스트를 진행하다 보면, 동료 개발자의 코드 리뷰나 QA, 기획팀의 피드백을 받게 됩니다.

확인 결과, shuffle 함수는 섞인 새로운 리스트를 반환할 뿐 기존 리스트를 직접 수정(Mutation)하지 않는 스칼라의 불변성 원칙을 간과한 것이 원인이었습니다. 이를 아래와 같이 수정하여 다시 배포합니다.

lazy val finishShellGame: Result[(List[ShellGameIndex], Int, List[Reward])] = 
  for {
    shellGameData <- inquireShellGameData 
    slots         <- shuffle(shellGameData.slots) // 섞인 새 리스트를 받도록 수정
    selectedSlot  =  Random.randInt(0, slots.size) 
    // ... 후략
  }

카드가 섞이지 않는 버그 픽스

이후 코드 리뷰 과정에서 또 다른 피드백이 들어옵니다.

🥅 리뷰어 피드백

"수지님, Random.randInt는 호출되는 즉시 값을 고정해 버리기 때문에, 함수형 구조 안에서 재사용할 때 매번 새로운 랜덤 값을 얻을 수 없습니다. 킹덤 서버는 예측 가능하고 안전한 로직을 위해, 실행 시점에 매번 새로운 무작위 수를 생성하는 getRandInt를 사용하도록 아키텍처가 설계되어 있습니다. 이 코드로 변경해 주세요! 😄"

보충설명

Random.randInt와 getRandInt 둘 다 결국 '랜덤 정수'를 만들어 낸다는 목적은 같습니다. 하지만 "값이 결정되는 시점"이 완전히 다릅니다.

Random.randInt: 변수에 할당되는 그 순간(선언부) 즉시 무작위 숫자를 뽑아서 채워 넣습니다. 이후에 이 변수를 아무리 여러 번 호출해도 이미 처음에 뽑힌 숫자가 그대로 재사용됩니다.

getRandInt: 선언할 때는 "앞으로 실행하면 랜덤 숫자를 뽑아줄게"라는 동작만 정의합니다. 실제로 이 변수를 .run으로 실행할 때마다 매번 새로운 주사위를 굴립니다.
// 1. Random.randInt를 사용했을 때 (값 고정)
// 선언하는 순간 이미 42라는 값이 결정되어 상수가 됩니다.
val randomValue = pure(Random.randInt(100)) 

randomValue.run // 결과: 42
randomValue.run // 결과: 42 (매번 똑같은 값이 나옴)

---------------------------------------------------------

// 2. getRandInt를 사용했을 때 (매번 실행)
// 선언할 때는 동작만 정의하고, 실행할 때마다 주사위를 새로 굴립니다.
val randomAction = getRandInt(100)

randomAction.run // 결과: 91
randomAction.run // 결과: 7  (매번 새로운 값이 나옴)

아까 수정했던 shuffle 메서드도 getRandInt와 마찬가지로 side-effect가 통제된 함수입니다. 이를 사용함으로써, 선언부에서 미리 결과를 계산해 저장하는 것이 아니라 실행될 때마다 다르게 섞이게 할 수 있습니다.

lazy val finishShellGame: Result[(List[ShellGameIndex], Int, List[Reward])] = 
  for {
    shellGameData <- inquireShellGameData 
    slots         <- shuffle(shellGameData.slots) 
    selectedSlot  <- getRandInt(0, slots.size) // Side-effect가 통제된 자체 randInt 사용
    rewards       <- rewards(shellGameData.slot(selectedSlot).rewards)
    _             <- liftEvent(ShellGameFinished(slots, selectedSlot, rewards))
  } yield (slots, selectedSlot, rewards)

자체 메서드 사용

이러한 수정 과정을 반복하며 코드의 퀄리티를 점진적으로 높여 나갑니다. 단순히 동작하는 코드를 짜는 것을 넘어, 이벤트 발생 후의 요구사항 검증, 로그 기록 등 다양한 예외 케이스를 고려하는 법을 배웁니다. 특히 특정 콘텐츠의 수정이 시스템 전체나 다른 기능에 미칠 영향까지 유의하며 개발하는 역량을 키우게 됩니다.

모든 QA와 리뷰를 마치면 마침내 코드가 라이브 서버에 배포됩니다. 배포 이후에도 본인이 맡은 기능에서 버그가 발생하지 않는지 세밀하게 모니터링합니다. 라이브 환경에서 발생하는 이슈들은 QA 단계에서 잡히지 않은 까다로운 케이스가 많습니다. 만약 재화 지급 오류 등이 발생했다면, 이미 재화를 소모한 유저의 회수 여부나 전 서버 보상 지급 등을 기획팀과 긴밀히 논의하여 후속 대응 방향을 결정하게 됩니다.

#Clear! 어깨너머로 배우는 성장의 즐거움

킹덤 서버팀은 콘텐츠 개발 외에도 성능 개선을 위한 다양한 시도들이 끊임없이 일어나는 곳입니다. 스칼라 프로젝트 서버 안정화를 위한 'shardcake' 같은 라이브러리 개발이 대표적인데, 동료분들이 치열하게 고민하시는 모습을 어깨너머로 지켜보는 것만으로도 공부가 많이 됩니다. 가끔씩은 작게나마 일손을 보태면서 프로젝트의 맥락을 이해하고, 우리 팀이 어떤 방향을 지향하는지 자연스럽게 익혀나가고 있습니다. 기술적인 부분뿐만 아니라 팀의 전반적인 분위기나 동료들의 관심사를 알아가는 것도 소소한 재미 중 하나고요.

#마치며

이렇게 킹덤 서버에서 보낸 시간들을 정리해 보았습니다. 사실 생소한 테크 스택으로 첫 커리어를 시작한다는 게 조금 겁나기도 했지만, 뛰어난 분들과 함께 호흡하며 배울 수 있는 기회는 그 두려움보다 훨씬 값졌습니다. 혹시 Scala나 함수형 프로그래밍(FP)이 낯설어 지원을 망설이고 계신 분이 있다면, 너무 주저하지 말고 도전해 보세요! 이곳에서의 경험은 다른 곳에서 얻기 드문 즐겁고 든든한 자산이 될 거예요. 킹덤 서버에서 여러분과 함께 일할 수 있는 날을 기다리고 있겠습니다.

쿠키런: 킹덤의 전투 데이터, JSON Schema로 검증하고 자동완성하기

Tue, 19 May 2026 00:00:00 GMT

안녕하세요, 데브시스터즈 스튜디오 킹덤에서 전투 클라이언트 프로그래머로 일하고 있는 김용욱이라고 합니다. 게임 데이터를 JSON 형태로 엑셀에 수기 입력할 때, 오타나 잘못 입력된 값을 런타임 실행 전에 발견하기 어렵다는 문제가 있었습니다. 이 문제를 해결하기 위해 JSON Schema를 이용해 JSON 데이터를 자동 검증하게 되었는데, 그 과정에서 JSON Schema를 역직렬화되는 게임 데이터 클래스로부터 자동 생성하고 Contract Resolver를 이용하거나 JSON Schema 자체를 후처리하여 이용했습니다. 또한 텍스트 에디터인 Visual Studio Code와 연동하여 자동완성과 실시간 검증이 가능한 시스템을 만들었고, 그 결과 생산성을 높이고 오류를 줄일 수 있었습니다.

이 글에서는 (1) 왜 JSON으로 데이터를 입력하는지 (2) JSON Schema의 필요성 (3) Schema 생성 및 커스터마이징 방법 (4) VS Code 연동 활용까지 순서대로 다룹니다.

#JSON으로 데이터를 입력하는 이유

게임 개발을 할 때, 많이 쓰이는 패턴이 “로직을 데이터로 작성하는” 것입니다. 예를 들어

민트사탕맛 쿠키가 스킬을 사용하면, 스킬 사용 직후 아군에게 공격력 증가, 방어력 증가 버프를 부여하고, 0.5초 뒤에 가로 세로 4 범위의 적군에게 공격력 비례 피해를 입힌다. 1.5초 뒤에 가장 체력이 낮은 아군에게 최대 체력 비례 회복을 부여한다.

는 스킬이 있다고 하면, 이를 코드에서 모두 처리할 수도 있지만 아래와 같이 데이터로 표현할 수도 있습니다. (설명을 위해 만든 가상의 데이터 구조입니다)

SkillId	SkillType	SkillValues	Timing	Target
MintCandy-001	Add_Buff	AttackPoint, 0.2, DefencePoint, 0.2	0	Allies
MintCandy-002	Attack	AttackPoint, 0.5	0.5	Enemies, Rectangle, 4x4
MintCandy-003	Heal	AttackPoint, 0.25	1.5	Allies, LowestHP, 1

데이터 형식으로 로직을 분리할 경우, 기획자가 데이터만 수정해 가면서 빠른 이터레이션이 가능하다는 장점이 있으며, 데이터 수정만으로 버그 수정이나 콘텐츠 업데이트를 진행 가능하다는 장점이 있습니다. 테이블 형식을 이용할 경우 기획자에게 익숙한 인터페이스인 스프레드시트를 활용할 수 있고, 데이터 역직렬화(텍스트 혹은 바이너리 형태로 된 데이터 포맷에서 코드에서 활용 가능한 데이터를 생성하는 것을 말합니다)도 용이하다는 장점이 있습니다.

이런 테이블 형식의 데이터는, 아래와 같은 경우에 적합하다고 생각합니다.

순서가 없거나, 시계열에 따라 순서대로 발생하는 경우
입력해야 할 값의 종류가 적고 그 중 전체 혹은 대다수를 입력해야 하는 경우
다수의 데이터를 한눈에 살펴보면서 값을 정해야 하는 경우

하지만 가상의 예시로 그 뒤에 다음과 같은 기능을 만들게 되었다고 합시다.

민트사탕맛 쿠키가 마법사탕을 착용하면, 스킬이 다음과 같이 바뀐다. 게임 시작 시 민트 스택을 1개(최대 10스택) 가지고 시작하며, 스킬을 사용하거나 아군이 전투불능이 되면 스택을 1개 획득한다. 스킬을 사용하면 기존 스킬에 더해, 현재 민트 스택이 5개 이상이면 아군 전체에게 치명타 증가 버프를 부여한다. 1.5초 시점에, 민트 스택이 10개 이상이면 민트 스택을 모두 소진하고 적군 전체에게 민트 중독(전용 아이콘과 이펙트가 있음)을 부여한다. 민트 중독을 가지고 있다면 일정 시간마다 피해를 입으며, 대상이 스킬을 사용할 때마다 해로운 효과 증가 디버프와 큰 피해를 입는다.

그 자체로는 아무 역할도 하지 않지만, 전투 중 특정 조건에 따라 증감해야 하는 “스택” 개념이 생겼습니다.
다른 경우에는 쓰이지 않지만 특정한 경우에만 쓰이는 “최대 스택”, “전용 아이콘”이나 “이펙트” 를 입력할 수 있어야 합니다.
반복문, 분기처리 등 상대적으로 복잡한 상태를 관리해야 합니다.

이를 테이블 형태로만 입력하자니, 선택적으로 입력해야 하는 필드의 양이 너무 많아지고 가독성이 떨어집니다. 코드로 로직과 상태 관리를 작성할 수도 있겠지만, 로직을 데이터로 옮겼을 때의 장점을 유지하고 싶을 때가 있습니다. 이런 경우 JSON 형태로 데이터를 입력하고, 그 데이터를 런타임에 역직렬화하여 사용하는 것을 고려할 수 있습니다.

JSON 포맷은 값에 숫자나 문자열, 배열이나 다른 JSON 객체를 담을 수 있어 유연한 적용이 가능하며 그러면서 가독성이 좋은 편이므로 수제로 작성하는 식으로도 활용할 수 있습니다. “민트 스택이 10스택 이상이 되면 다른 행동을 한다”는 동작을 JSON 포맷으로 표현하자면 아래와 같은 형태가 될 것입니다(마찬가지로 설명을 위한 가상의 데이터입니다).

{
  "type": "Check",
  "version": 1,
  "check": [
    {
      "condition": "Stack",
      "target": "MintStack",
      "operator": ">=",
      "value": 10,
      "then": [
        "FirstAction",
        "SecondAction"
      ]
    }
  ]
}

다음과 같은 조건에서

시계열이 아니라, 특정 조건에 따라 복잡한 분기처리를 해야 하는 경우
입력해야 할 값의 종류가 많지만 실제로는 개중 일부만 입력해서 이용해야 하는 경우
상대적으로 소수의 데이터를 복잡하게 설정하는 경우

JSON 형태로 값을 입력하는 것을 고려해볼 수 있습니다.

#JSON Schema의 필요성

JSON Schema를 도입하기 전에는, 위 전투 시스템을 구현하는 각 필드를 기획자가 수동으로 입력하고 간단한 포매팅만 거쳐 Microsoft Excel에 입력하여 연동을 하고 있었습니다. JSON 포맷은 손으로 직접 작성할 수 있을 만큼 간단한 편이기 때문에 가능한 일입니다.

그러나 JSON 포맷의 텍스트를 메모장이나 Microsoft Excel에 직접 입력하기에는 상당히 번거롭습니다. 또한 쿠키런: 킹덤에서는 JSON 포맷을 이용할 때 유니티 내장 JSON 파서를 이용하여 역직렬화를 하고 있습니다. 속도가 빠르고 별도의 외부 라이브러리를 사용할 필요가 없다는 장점이 있지만, 아래와 같은 단점도 있습니다.

JSON 포맷에 맞기만 하면 데이터에 잘못된 값이 들어가더라도 최대한 Graceful하게 살리려 한다.
- 예를 들어 존재하지 않는 필드를 입력하더라도, 조용히 무시한다.
- 존재하는 필드의 타입을 잘못 입력하더라도, 혹은 잘못된 값을 입력하더라도 조용히 무시한다.

그 때문에

테이블 형식에 비해 오히려 입력이 어려워진다.
잘못 입력하더라도 어디가 잘못되었는지 확인하기 어렵다.
잘못된 필드에 값을 입력하고, 어디가 문제인지 찾는데 오래 걸린다.

라는 문제가 생깁니다.

이럴 때 사용할 수 있는 것이 JSON Schema입니다. 스키마(Schema)란 특정한 데이터가 가져야 할 구조나 제약조건을 말하는 것으로 JSON Schema는 JSON 타입의 데이터를 정의하고 제약하는 문서라고 할 수 있습니다.

예를 들어 JSON 데이터에 아래와 같은 제약 조건을 설정하고 싶을 때

“key” 필드는 문자열이어야 하며 필수적으로 존재해야 한다.
“id” 필드는 정수여야 한다.
위 필드 외에 다른 값을 입력하면 안 된다.

다음과 같은 JSON Schema를 이용할 수 있습니다.

{
  "type": "object",
  "properties": {
    "key": {
      "type": "string"
    },
    "id": {
      "type": "integer"
    },
  },
  "additionalProperties": false,
  "required": ["key"]
}

JSON Schema는 JSON 포맷을 검증한다는 그 자체의 기능 외에도, 아래와 같은 장점이 있습니다.

그 자체로도 JSON 파일이기 때문에 가독성이 좋고 다양한 프로그램에서 로드와 수정이 쉽다.
특정 값이 포함되어야 하는지, JSON Schema에서 정의한 키값 외에 다른 값들이 존재해도 되는지와 같은 메타적 요소도 검사 가능하다.
복잡한 조건도 원한다면 검증 가능하다. (JSON Schema에는 각 JSON 필드에 사용 가능한 다양한 조건들이 정의되어 있습니다.)
사용 환경에 독립적으로, JSON과 JSON Schema를 지원하기만 한다면 검증을 할 수 있다.

C#에서는 Json.NET 라이브러리를 이용해 JSON 포맷을 다룰 수 있으며 유니티 최신버전에 포함되어 있어 바로 이용 가능합니다. Json.NET에서 스키마 검사를 하는 부분은 별도의 유료 라이브러리로 분리되어 있지만, 기본적인 스키마 검사 기능은 오픈소스 Json.NET에 포함되어 있습니다. 현재 JSON 형태로 데이터를 입력하는 곳이 소수이기 때문에, 별도의 라이브러리 구입 및 임포트를 하는 대신 Json.NET의 내장 스키마 검증 기능을 활용하기로 하였습니다.

#JSON Schema 생성하고 활용하기

#스키마 작성하고 검증하기

스키마를 손으로 직접 작성하는 것은, 위 예시와 같이 그렇게 어렵지 않습니다. 이렇게 작성한 스키마를 텍스트 파일에서 읽어와, 검증하는 것도 간단하게 가능합니다. 어려운 부분은, 우리 목적에 맞는 올바른 스키마를 생성하는 것입니다.

// <https://www.newtonsoft.com/JSON/help/html/JTokenIsValidWithMessages.htm>
// 적절한 곳(이 경우는 C:\\schema.JSON)에서 읽어 온다.
JSONSchema schema = JSONSchema.Parse(File.ReadAllText(@"C:\\schema.json"));

// JSON string을 파싱한다.
JObject person = JObject.Parse(@"{
  'name': null,
  'hobbies': ['Invalid content', 0.123456789]
}");

IList<string> messages;
// 검증한다.
bool valid = person.IsValid(schema, out messages);

Console.WriteLine(valid);
// false

// 에러 메시지가 나온다.
foreach (string message in messages)
{
    Console.WriteLine(message);
}

#스키마 자동 생성하기

JSON Schema를 손으로 작성하는 것은 필드가 한 두 개 정도 있을 때 가능한 일이며, 그보다는 코드에서 자동으로 생성해주는 것이 바람직합니다. Json.NET에서는 JSONSchemaGenerator 클래스를 이용하여 특정 클래스 타입으로부터 스키마를 생성할 수 있습니다.

var generator = new JSONSchemaGenerator();
var schema = generator.Generate(type, new JSONSchemaResolver());

실제 예시를 통해 설명하겠습니다. 아래와 같은 클래스가 있다고 합시다. JSON 값은 이 클래스로 역직렬화되고, 이후 Initialize()가 불린 뒤 활용됩니다. 클래스는 다음과 같습니다.

[Serializable]
public class CookieData
{
    [Serializable]
    public enum CookieType
    {
        Normal = 0,
        Uncommon = 1,
        Bright = 2,
        Crispy = 3,
    }

    public int Id => id;
    public CookieType TypeOfCookie => typeOfCookie;
    public Vector2 Position => position;
    [SerializeField]
    private int id;

    [SerializeField]
    private string type;
    private CookieType typeOfCookie;

    [SerializeField]
    private float[] positionValue;
    private Vector2 position;

    public void Initialize()
    {
        typeOfCookie = Enum.Parse<CookieType>(type, false);
        position = new Vector2(positionValue[0], positionValue[1]);
    }
}

아래는 위 클래스로 역직렬화 가능한 JSON 예시 데이터입니다.

{
	"type": "Crispy",
	"id": 10000, 
  "positionValue": [
		2,
		3
	]
}

이 클래스에서 그대로 JSON Schema를 아무 처리 없이 JSONSchemaGenerator() 로 생성하면 다음과 같이 됩니다.

{
  "id": "CookieData",
  "type": [
    "object",
    "null"
  ],
  "properties": {
    "Id": {
      "required": true,
      "type": "integer"
    },
    "TypeOfCookie": {
      "required": true,
      "type": "integer",
      "enum": [
        0,
        1,
        2,
        3
      ]
    },
    "Position": {
      "id": "UnityEngine.Vector2",
      "required": true,
      "type": [
        "object",
        "null"
      ],
      "additionalProperties": false,
      "properties": {
        "x": {
          "required": true,
          "type": "number"
        },
        "y": {
          "required": true,
          "type": "number"
        },
        "normalized": {
          "$ref": "#/properties/Position"
        },
        "magnitude": {
          "required": true,
          "type": "number"
        },
        "sqrMagnitude": {
          "required": true,
          "type": "number"
        }
      }
    }
  }
}

검증을 해 봅시다.

Required properties are missing from object: Id, TypeOfCookie, Position.

이상하게도 제대로 된 JSON 데이터를 오류라고 인식합니다. JSON Schema가 잘못된 것 같습니다. 대표적으로,

우리가 입력할 때 이용하는 키값은 camelCase인데, 키값이 PascalCase에 대해 생성되었습니다.
역직렬화에 사용할 수 없는 퍼블릭 프로퍼티에 대해서 키값이 생성되었습니다.
typeOfCookie는 Enum 타입인데, 불편하게 숫자를 직접 입력하도록 하고 있습니다.

이럴 경우, 스키마를 생성하는 Generator를 직접 수정하는 대신 크게 두 가지 방법으로 생성되는 스키마를 커스터마이징할 수 있습니다.

Contract Resolver: 역직렬화 대상이 되는 클래스에서 JSON Schema를 생성할 때, 어떤 값에 대해 어떻게 동작해야 하는지를 재정의합니다. 예를 들어 데이터의 키값이 클래스의 어떤 값과 매칭되어야 하는지, 키값의 데이터 타입이 어떤 것이 되어야 하는지 역직렬화되는 클래스를 읽어들이며 수정합니다.
JSON Schema 후처리: JSON Schema도 결국 JSON 형태의 데이터이므로, 원본 데이터와 각 필드의 타입을 가지고 Schema를 재정의할 수 있습니다.

#1. Contract Resolver 튜닝하기: 입력해야 하는 값을 가져오는 문제

기본적으로 JSONSchemaGenerator는 해당 타입의 퍼블릭 필드와 프로퍼티가 직렬화된다고 가정하며, 퍼블릭 프로퍼티의 값에서 JSON 오브젝트를 생성합니다. 또한 모든 값들을 필수적으로 입력해야 한다고 간주합니다. 그런데 우리는 [SerializeField] 어트리뷰트가 붙은 (camelCase인) private 변수 이름을 가져오고, 타입은 이름이 일치하는 퍼블릭 프로퍼티를 따르게 하고 싶습니다. 그리고 대부분의 경우는 필수로 입력할 필요는 없고, 대신 다른 값을 잘못 입력하는 것을 막고 싶습니다.

첫 번째 문제부터 해결합시다. 간단히는 퍼블릭 프로퍼티의 이름이 private 변수와 대응하도록 수정해 주는 것입니다. 예를 들어 public SomeNumber ⇒ someNumberProperty.Value 혹은 public SomeClass ⇒ someClass 과 같이 지정해주는 것으로 해결이 가능합니다.

그러나 레거시 데이터 중에서 데이터의 키값 이름을 수정하기 어려운 경우가 있습니다. 이럴 때 Contract resolver를 커스터마이징하여 클래스가 있을 때 어떤 식으로 값을 인식할지를 튜닝할 수 있습니다.

위에서도 말했듯이, Contract Resolver는, 각 변수를 읽어들일 때 그 변수에 해당하는 JSON 값이 어떻게 매핑되어야 하는지 결정하는 클래스입니다. 예를 들어서, 해당 변수가 int 타입이라면 정수로 매핑이 되고, string 타입이면 문자열로 매핑이 되는 식입니다. 타입과 함께 다른 세부 정보들도 읽어들일 수 있습니다.

Contract Resolver를 오버라이드하여 커스터마이징을 해 줍시다. 커스터마이징의 예시로, 전용 어트리뷰트를 하나 만들어, 이 어트리뷰트에서 정보를 가져오게 할 수 있습니다. 예를 들어, 명명 규칙이 대응하지 않는 경우 해당 프로퍼티에 어트리뷰트 [GenerateSchemaAs(”someOtherName”)]를 붙인 뒤 Contract Resolver 단계에서 인식하는 식으로 대응이 가능합니다. 타입이 대응하지 않는 경우(입력은 double[]로, 출력은 Vector3으로 하는 경우 등)는 어트리뷰트 [GenerateSchemaAs(typeof(OtherType))] 식으로 하여 OtherType을 타입으로 가져오게 할 수 있습니다.

이 Contract Resolver가 값을 읽을 수 있게 클래스를 수정해주면 다음과 같이 됩니다.

[Serializable]
public class CookieData
{
    [Serializable]
    public enum CookieType
    {
        Normal = 0,
        Uncommon = 1,
        Bright = 2,
        Crispy = 3,
    }

    public int Id => id;
    public CookieType Type => typeOfCookie;  // 명명 규칙이 대응하지 않는 경우
    [GenerateSchemaAs(typeof(float[]), "positionValue")] // 명명 규칙과 타입이 모두 불일치하는 경우
    public Vector2 Position => position;

    [SerializeField]
    private int id;

    [SerializeField]
    private string type;
    private CookieType typeOfCookie;

    [SerializeField]
    private float[] positionValue;
    private Vector2 position;

    public void Initialize()
    {
        typeOfCookie = Enum.Parse<CookieType>(type, false);
        position = new Vector2(positionValue[0], positionValue[1]);
    }
}

이제 JSON Schema는 다음과 같이 변경되었습니다.

{
  "id": "CookieData",
  "type": [
    "object",
    "null"
  ],
  "properties": {
    "Id": {
      "required": true,
      "type": "integer"
    },
    "type": {
      "required": true,
      "type": "integer",
      "enum": [
        0,
        1,
        2,
        3
      ]
    },
    "positionValue": {
      "id": "System.Float[]",
      "required": true,
      "type": [
        "array",
        "null"
      ],
      "items": {
        "type": "number"
      }
    }
  }
}

하지만 아직 enum 등에 대해 제대로 대응이 되어 있지 않으므로, Contract Resolver만을 이용해 수정이 불가능한 경우 커스텀 Contract Resolver를 이용해 생성한 JSON Schema에 대해 추가적으로 후처리를 해 주어야 합니다.

#2. JSON Schema 후처리하기: Enum as String

전투 데이터에서 열거형(Enum) 타입을 입력할 때는 string으로 입력하고, 이 값을 나중에 파싱을 해 집어 넣고 있습니다. 그런데 내장된 Generator에서는 열거형 타입을 숫자로 대응하고 있었습니다. 열거형 데이터를 숫자로 입력하는 것은 의도한 것도 아니고, 실제로 입력하는 것도 직관적이지 않습니다. Schema Generator 자체를 커스터마이징하는 방법도 생각할 수 있지만, 외부 라이브러리에 존재하는 Deprecated된 클래스를 직접 수정하는 것은 배보다 배꼽이 더 큰 일이라고 생각했습니다.

그래서 Enum이 숫자로 매핑된 스키마를 가져와, 원본 타입 데이터를 이용해 그 타입이 다시 string 타입에 매핑되도록 후처리를 해주었습니다. 스키마를 재귀적으로 탐색하면서 Enum을 만나면 해당 Enum의 문자열을 가져와, 숫자 대신 그 문자열만 입력이 가능하도록 제한해주면 됩니다.

JSON Schema를 후처리하면서 다른 문제도 해결해봅시다. JSON Schema에서는 각 값의 메타데이터를 지정할 수 있습니다. 각 object나 array, enum 등에 additionalProperties = false를 추가하고(정의되지 않은 불필요한 값을 입력한 경우 에러가 발생함), 불필요한 required는 Null로 설정해 제거해줍시다(일부 값을 미입력하더라도 에러로 취급하지 않음).

이렇게 후처리를 하게 되면 결과적으로 아래와 같은 스키마가 생성됩니다.

{
  "id": "CookieData",
  "type": [
    "object",
    "null"
  ],
  "additionalProperties": false,
  "properties": {
    "id": {
      "type": "integer"
    },
    "type": {
      "type": "string",
      "enum": [
        "Normal",
        "Uncommon",
        "Bright",
        "Crispy"
      ]
    },
    "positionValue": {
      "id": "System.Single[]",
      "type": [
        "array",
        "null"
      ],
      "items": {
        "type": "number"
      }
    }
  }
}

#JSON 데이터를 이용하는 방법

일단 JSON Schema를 이용해 전투 데이터를 제대로 입력했는지 검증할 수 있습니다. 쿠키런: 킹덤에서는 매 전투 테스트마다 별도의 스레드에서 JSON Schema 검증을 실행하고, 오류가 존재하는 경우 유니티 로그로 출력해주는 방식을 이용하고 있습니다.

여기서 데이터를 검증하는 데서 그치지 않고, 데이터를 만들 때 Visual Studio Code의 JSON Schema 지원을 활용할 수 있습니다. Visual Studio Code는 마이크로소프트에서 만든 범용 텍스트 에디터로, 다양한 포맷을 지원하는 것이 특징 중 하나입니다. VS Code에서는 JSON Schema를 읽어 오고, 이를 이용해 원하는 JSON 파일에 대해 자동완성 및 값 검증을 할 수 있습니다.

json-validation-in-vs-code

이때 기획자나 QA도 별도의 클라이언트 조작 없이 편리하게 JSON 데이터를 입력할 수 있도록 일종의 “올인원 패키지”를 구성해 배포해주었습니다. 필드나 Enum의 값이 추가되는 등 데이터 구조가 바뀌면, JSON Schema를 사용자가 정의한 폴더로 내보내고, 업데이트합니다. 아래와 같이 정의하면, 특정 폴더 내의 모든 JSON 파일에 대해 해당 경로의 JSON Schema로 검증합니다. 이때 git 저장소 형태로 배포를 한다고 하면, 폴더의 하위 경로를 .gitignore 파일에 추가해주면 각 사용자는 원하는 대로 폴더를 만들고 하위에 JSON 파일을 생성하여 콘텐츠 작업에 활용할 수 있습니다. 이제 이 폴더와 JSON Schema, .gitignore를 합쳐서 git 저장소나 그 일부로 배포해주면 됩니다. 이때, settings.json 파일 내의 주석은 제거해야 합니다.

# 폴더 내 구성 예시
- .vscode/settings.json
- .gitignore
- json-schema.json
- SandBox/
- README.md

# .gitignore의 예시
!.vscode/* # VS Code 워크스페이스 설정은 동기화되어야 함
SandBox/**/*.json # SandBox 폴더 내의 모든 JSON 파일을 Git에서 무시함

# settings.json의 예시
{
  "[Json]": {
    "editor.tabSize": 2 # 탭 사이즈를 통일해줍니다
  },
  "editor.unicodeHighlight.nonBasicASCII": false, # 한글이 입력된 것을 에러로 판단하지 않게 합니다
  "json.schemas": [
    {
      # SandBox 폴더 내의 모든 JSON 파일에 대해 해당 스키마를 적용합니다 (자기 자신 제외)
      "fileMatch": ["SandBox/**/*.json", "!json-schema.json"],
      "url": "./json-schema.json"
    }
  ]
}

결과적으로, 자동완성을 이용하여 빠르고 정확하게 콘텐츠 추가가 가능해집니다. 이미 입력한 JSON 데이터에서 어떤 문법적 문제가 있는지도 쉽게 체크할 수 있습니다. 필요한 경우, 자주 쓰이는 구문은 Code Snippet으로 정의하여 상용구와 같이 입력하는 것도 가능합니다.

#결론

게임 개발을 진행하다 보면 JSON 포맷으로 데이터를 손수 입력하고 이를 역직렬화하여 사용해야 할 때가 있습니다. 이럴 때 역직렬화 대상이 되는 클래스에서 JSON Schema를 추출하고, 이를 이용해 수제 데이터를 검증할 수 있었습니다. JSON Schema가 생성되는 방식을 튜닝하고 후처리를 해주어 우리가 원하는 대로 JSON Schema를 정의할 수 있었고, 이를 바탕으로 Visual Studio Code와 연동하여 콘텐츠 작성의 효율을 극대화할 수 있었습니다.

해당 작업은 2023년부터 쿠키 캐릭터 및 여타 전투 콘텐츠의 규모와 복잡도가 높아지는 것에 발맞추어 진행하였으며 이후 수 차례의 고도화를 거쳐 현재 클라이언트 프로그래머와 기획자, QA 담당자가 모두 사용하고 있는 시스템으로 발전시켰습니다. 이 작업을 통해 개개인의 생산성을 높인 것은 물론 전투 콘텐츠에서 실수와 오류 발생을 줄일 수 있어서 보람이 있는 작업이었습니다.

앞으로도 JSON Schema 시스템과 같은 소소한 개선과 함께 플레이어 여러분께 즐거운 경험을 선사할 수 있도록 노력해 나가겠습니다. 감사합니다.

데브시스터즈 엔지니어링 데이 - 게임 서버 돌아보기

Thu, 30 Oct 2025 00:00:00 GMT

안녕하세요. 데브시스터즈 기술본부에서 조직·기술 문화를 가꾸고 있는 전경아입니다. 어느덧 세 번째 엔지니어링 데이 돌아보기 글로 인사를 드립니다. 이번 글에서는 2025년 9월 25일에 진행했던 <제3회 데브시스터즈 엔지니어링 데이 - 게임 서버>를 소개합니다. 온라인 다시 보기 영상 링크도 함께 제공해드립니다.

#행사 소개

‘데브시스터즈 엔지니어링 데이’란, 데브시스터즈에서 마주하는 기술적인 문제를 공유하고, 어떻게 풀어가는지 외부에 경험을 나누는 행사입니다. 본 행사를 통해 개발자 간에 소통할 수 있는 교류의 장을 만들고, 개발자 생태계에 긍정적인 영향을 미치기 위해 노력하고 있습니다.

지난 주제인 Infra/SRE, 데이터에 이어 세 번째 행사는 ‘게임 서버’를 주제로 진행하였습니다. 데브시스터즈는 ‘쿠키런: 킹덤’, ‘쿠키런: 모험의 탑’ 등 여러 게임을 서비스하고 있고, 또 신작을 새로 개발 중이기도 한데요, 전 세계 수천만 유저가 우리의 게임을 재미있게 즐길 수 있도록 대규모 트래픽 속에서도 안정적인 라이브 서비스를 제공하며 기술적인 도전을 멈추지 않는 서버 직군의 이야기를 들어보았습니다.

지난 발표 영상은 데브시스터즈 테크 유튜브 채널에서 다시 보실 수 있습니다. https://www.youtube.com/@DEVSISTERS_TECH

#발표 1 - Scala 리얼타임 게임 백엔드 해부하기

쿠키런: 킹덤 서버 엔지니어 손명배님

쿠키런: 킹덤은 함수형 프로그래밍 패러다임에 기반한 Scala로 백엔드를 구현한 프로젝트입니다. 2021년 출시 이후 지금도 활발하게 개발되고 있는 킹덤 백엔드는 여전히 명료하고 읽기 쉬운 코드, 강력한 확장성과 성능, 유지보수의 편의를 모두 만족하고자 끊임없이 노력하고 있습니다.

쿠키런: 킹덤이 발전하면서 새롭게 등장한 기술적 도전, 리얼타임 게임 서버를 어떻게 구현하였는지 회고하며, 함수형 프로그래밍으로 명료한 코드와 충분한 성능을 동시에 확보하기 위한 기법들을 소개해 주셨습니다.

#발표 2 - Unity 에셋 번들, 패치로 용량 줄이기

쿠키런: 모험의 탑 서버 엔지니어 배경민님

유니티(Unity) 엔진의 에셋 번들(Asset Bundle)은 플랫폼마다 최적화된 리소스 묶음을 빌드하고 배포하기 위한 기능입니다. 그러나 함께 묶인 리소스가 많으면 일부만 수정해도 사용자가 받아야 하는 추가 다운로드 용량이 커질 수 있습니다. 모바일 게임의 데이터 사용량은 사용자에게 큰 부담이 되므로 이를 최소화해야 합니다.

쿠키런: 모험의 탑에서 이 문제를 해결하기 위해 바이너리 패치를 적용하여 리소스 업데이트 시 다운로드 용량을 크게 줄이고 CDN 비용을 절감한 사례를 공유해 주셨습니다.

#패널톡 & 채용 부스

정규 발표 세션이 마무리된 후, 지식의 깊이를 더해줄 패널톡 시간이 50분간 이어졌습니다. 발표자 전원이 무대에 올라, 참석자분들이 보내주신 질문에 진솔하게 답변하는 시간으로 꾸려졌습니다. ‘장애 발생 시 대응 매뉴얼과 실제 경험’, ‘서버 관련 추천 학습 방법’, ‘게임별 프로그래밍 언어 선택의 기술적 배경’ 등 실무와 맞닿아있는 구체적이고 깊이 있는 질문들을 남겨주셨습니다. 게임 업계뿐만 아니라 다양한 업계의 서버 엔지니어들이 오셔서 더욱 다채로운 시각에서 이야기를 나눌 수 있었습니다.

발표장 뒤쪽에서는 데브시스터즈와 좀 더 가까워질 수 있는 채용 부스가 운영되었습니다. 이번 채용 부스는 참석자 개개인에게 조금 더 집중하고자, 사전 신청 내용을 기반으로 한 맞춤형 상담으로 진행되었습니다. 참석자분들은 본인이 가장 관심 있는 프로젝트의 담당 서버 개발자와 직접 만나 평소 궁금했던 점들을 편하게 질문할 수 있었습니다. 프로젝트의 기술적 과제와 비전, 팀의 개발 문화와 성장 가능성에 대한 현실적인 이야기부터, 서버 개발자로서의 커리어 패스, 이직과 취업에 대한 전반적인 고민 상담까지 채용 담당자와 현직 개발자가 함께 자리하여 다양한 시각에서 조언드릴 수 있었습니다. 참석자분들은 이번 채용 부스를 통해 데브시스터즈라는 회사와 각 프로젝트에 대한 관심과 이해도를 한층 더 높이는 계기가 되었고, 저희는 지원자분들의 열정과 고민을 가까이에서 느낄 수 있었던 의미 있는 시간이었습니다. 이 자리를 빌려 흔쾌히 참석해 주신 채용팀 분들과 각 프로젝트의 서버 개발자분들께도 감사의 말씀을 드립니다.

#마치며

2025년 2월, 기술 공유와 성장을 목표로 선보인 데브시스터즈 엔지니어링 데이가 여러분의 뜨거운 성원 속에 어느덧 세 번째 행사를 성공적으로 마무리했습니다. 무엇보다도 꾸준한 관심과 참여로 함께 해주신 여러분 덕분입니다.

지난 3번의 행사를 통해 저희는 Infra/SRE, 데이터, 게임 서버 등 데브시스터즈의 기술 분야에 대한 깊이 있는 이야기를 나누었습니다. 매번 세션이 끝난 후 보내주시는 여러 질문과 피드백 덕분에 저희도 더 성장할 수 있었습니다. 이를 바탕으로 2026년에는 더욱 다양한 직군을 모시고 인사이트를 교류할 수 있는 시간을 준비하겠습니다.

개인적으로는 이번에 AI와 함께 코딩하는 새로운 경험을 한 것이 기억에 많이 남습니다. 앞선 두 번의 행사에서는 행사 소개 페이지를 노션으로 만들어서 공개했었는데요, 최근 사내에서 AI 사용이 활발해짐에 따라 ‘AI로 행사 소개 페이지도 만들 수 있지 않을까?’라는 생각으로 Claude Code를 이용하여 만들어봤습니다. 외부에 보이는 웹 사이트 개발이 아예 처음이다 보니 시작은 다소 막막하고 쉽지 않았습니다. 하지만 주변에서 도와주신 덕분에 금방 기본 형태를 잡을 수 있었고, 그 이후에는 원하는 기능을 조금씩 덧붙이며 현재의 모습이 완성되었습니다. 이번 경험을 통해 히어로 섹션, 워드 브레이크, 푸터 등 다양한 키워드와 함께 웹 개발자분들의 대단함을 조금이나마 이해하게 되었습니다.

행사 소개 페이지: https://devsisters.github.io/engineeringday-2025-gameserver/

저의 작은 경험이 바로 기술과 인간이 점점 더 가까워지고 있음을 보여주는 예시가 아닐까 싶습니다. 많은 것이 급변하는 이 시대를 살아가고 있는 모든 분의 성장을 응원하며, 앞으로도 데브시스터즈 엔지니어링 데이와 기술직군에 많은 관심 부탁드립니다. 감사합니다.

게임 회사에서 클라이언트 프로그래머가 하는 일

Tue, 12 Aug 2025 00:00:00 GMT

#들어가며

안녕하세요. 저는 쿠키런 킹덤의 4년차 클라이언트 프로그래머로 일하고 있는 박지선입니다.

제가 취업준비생 시절, 클라이언트 프로그래머가 무슨 일을 하는지 구체적으로 잘 알지 못했습니다.

검색 엔진에 찾아봐도,

“서버 프로그래머는 유저 데이터를 저장하는 서버를, 클라이언트 프로그래머는 눈에 보이는 게임을 구현하는 일을 합니다.”

와 같은 간단한 정의만 흔히 접할 수 있었죠.

하지만 실제 현업에서는 클라이언트 프로그래머가 하는 일은 이보다 훨씬 다양합니다.

눈에 보이는 게임을 구현하는 것 뿐만 아니라,
다른 직군과 누구보다 긴밀히 협업하고,
툴을 개발하거나,
리소스를 관리하고,
게임 엔진을 다루는 등

게임 개발 전반에 걸쳐 다양한 업무를 맡고 있습니다.

그래서 이 글에서는 클라이언트 프로그래머를 꿈꾸며 공부하는 취업 준비생 분들에게 조금이라도 도움이 되기를 바라는 마음으로, 제가 실제로 구현한 컨텐츠를 예시로 들어서 컨텐츠 개발 흐름을 따라 클라이언트 프로그래머가 어떤 일을 하는지 구체적으로 이야기해보려 합니다.

물론 회사나 팀마다 개발 문화와 방식이 다를 수 있기 때문에 이 글에서 소개하는 내용이 모든 게임 회사에 똑같이 적용되지는 않을 수 있습니다. 같은 팀 내에서도 쿠키 제작이냐, 전투 컨텐츠 제작이냐, 왕국 컨텐츠 제작이냐에 따라서 달라질 수 있습니다. 이 점 참고해서 하나의 실무 예시로 읽어주시면 감사하겠습니다.

#게임 회사의 조직 구조와 직무 소개

이야기를 하기에 앞서, 게임 회사에 어떤 직군이 있는지 잘 모르시는 분들을 위해 간단한 설명을 하고 넘어가겠습니다. 지금 설명드리는 직군들이 앞으로 나올 실무 예시에 등장하게 됩니다. 이 정도는 안다! 하시는 분들은 다음 챕터로 바로 넘어가시면 됩니다.

게임 개발팀에는 다양한 직군이 속해있습니다. 회사나 프로젝트에 따라 명칭이나 세부 구성이 다르겠지만, 보통 다음과 같은 직군으로 나뉩니다.

PD (Project Director) : 프로젝트 전체의 방향성과 퀄리티를 총괄합니다.
PM (Project Manager) : 프로젝트의 개발 관리와 출시, 운영에 이르는 모든 매니지먼트를 담당하며, 개발팀 외부 조직들과의 커뮤니케이션도 함께 맡고 있습니다.
서버 프로그래머 : 게임의 백엔드를 구축하고, 유저 데이터 관리 및 서버-클라이언트 간 통신을 담당합니다.
클라이언트 프로그래머 : 게임 구조를 설계하고, 여러 직군이 만든 리소스와 데이터를 게임 속에서 자연스럽게 연결해서 게임이 실제로 동작하도록 구현합니다.
스토리 : 게임의 전반적인 스토리부터 캐릭터를 포함한 서사 전반을 구성합니다. 쿠키런 킹덤에서는 데코 아이템, 패키지 상품, 이벤트 문구 등 게임 곳곳에 들어가는 모든 텍스트가 스토리 팀의 손을 거칩니다.
아트 : 스토리에 어울리는 컨셉과 캐릭터를 디자인하고, 게임에 사용되는 리소스를 제작합니다. 쿠키런 킹덤에서는 배경 아트, 캐릭터 아트, 일러스트 아트 세 팀으로 구성되어 있습니다.
UIUX : 아트의 리소스와 기획서를 바탕으로 인터페이스와 유저 경험을 설계합니다. 프로젝트 내의 리소스를 관리하고 조립해서 프리팹을 제작하기도 합니다.

💡 프리팹(prefab) 이란?

Unity에서 재사용 가능한 오브젝트 템플릿을 의미합니다. 일관된 UI 구성이나 오브젝트 배치에 유용하게 사용됩니다.
이펙트 : 전투 연출이나 UI 효과 등 시각적인 효과를 제작합니다.
모션 : 캐릭터나 오브젝트에 생동감 있는 모션을 적용합니다.
기획 : 게임의 전반적인 시스템, 컨텐츠, 밸런스를 설계합니다. 쿠키런 킹덤에서는 왕국 컨텐츠 기획, 전투 컨텐츠 기획, 시스템 기획, 캐릭터 기획 네 팀으로 구성되어 있습니다.
QA (Quality Assurance) : 기획 의도에 맞게 기능이 동작하는지 테스트하고, 유저의 실제 경험을 바탕으로 피드백을 제공합니다.

이처럼 하나의 게임을 만들기 위해 다양한 직군이 함께 긴밀히 협업하며 프로젝트를 완성해 나갑니다.

#업데이트와 업무 루틴

클라이언트 프로그래머의 업무를 어떻게 더 잘 설명할 수 있을까 고민하다가, 실무를 예시로 설명드리면 좋을 것 같아서 게임 업데이트와 업무 루틴을 따라 설명드리려 합니다.

점핑 플랫폼 미니게임 플레이 영상입니다. 영상을 볼 수 없는 경우, 쿠키가 플랫폼을 점프하며 장애물을 피하는 게임 플레이를 상상해 주세요.

쿠키런 킹덤을 꾸준히 플레이 해보셨다면 이 미니게임을 아실 수도 있을 것 같습니다. 2025년 6월 4일에 업데이트 되었던 ‘정글전사 쿠키의 베리베리 높이높이!’ 로 제가 작업했던 미니게임 컨텐츠입니다.

이 컨텐츠가 어떤 과정을 통해 개발되었는지를 한 번 돌아보도록 하겠습니다.

참고로 ‘점핑 플랫폼’이라는 명칭이 계속 등장할텐데, 이는 임의로 작업자들끼리 정한 개발 명칭입니다. 컨텐츠의 이름은 개발 후반부에 스토리 팀에서 IP 특유의 톤앤매너와 함께 시스템상의 직관성이 전달될 수 있게끔 작성해주십니다.

#📋 컨텐츠 결정

쿠키런 킹덤은 PD와 스토리팀, 아트팀을 중심으로 1년 단위로 대략적인 업데이트 플랜을 정해두는데요, 그 플랜에 맞춰서 이번 업데이트에 어떤 스토리가 들어갈 것인지, 어떤 컨텐츠를 넣을 것인지를 결정합니다.

이번 업데이트에 들어가는 비스트 에피소드 스토리에서 정글전사 쿠키가 나무에 올라 베리를 따는 장면이 등장했고 그걸 토대로 미니게임으로 만들기로 결정하였습니다.

#🤝🏻 상위방향성 & 상세기획 회의

이 회의들은 PD님과 기획팀이 주로 진행합니다. 컨텐츠에서 어떤 경험을 줄 지에 대한 방향성, 미니게임의 구성을 논의하는 회의입니다.

이 단계까지는 클라이언트 프로그래머의 개입이 크게 없습니다. 이런 컨텐츠가 들어갈 예정이구나 정도만 파악해서 담당자를 배정하거나 구현 가능성을 확인합니다.

여기서 말하는 구현 가능성이란 제작할 일정이 충분한지, 기술적으로 가능한지 체크하는 것을 말합니다.

#🏃🏻 킥오프 회의

앞에서 방향성을 정한 후 기획팀에서는 킥오프 기획서를 작성합니다. 킥오프 회의는 실무자들을 위한 회의로, 이 회의를 진행한 후 본격적으로 작업을 시작합니다. 회의에서는 기획자를 중심으로 서버&클라이언트 프로그래머, 아트, UIUX, 이펙트, 모션팀 모두가 참석해서 컨텐츠 구현을 위해 구체적인 스펙을 체크하고, 회의가 끝나면 PM팀에서 각 직군별로 작업 일정을 확인해서 조율해주십니다.

킥오프 회의에서의 클라이언트 프로그래머의 역할은 매우 중요합니다.

클라이언트 프로그래머는 데이터, 서버, 리소스 작업이 모두 완료된 이후에 건담을 조립하는 것처럼 작업을 하는데, 이 때 부품이 맞지 않아 조립을 못하는 일이 생기면 안 되겠죠. 그래서 미리 설계에 참여해서 리드해야 이후 작업에 차질이 없습니다.

다음과 같이 원하는 형태로 리소스를 제작해주시게끔 작업 방향성을 제시합니다.

아트 ⇒ “이 정도 사이즈의 이미지 리소스를 반복해서 사용할 예정이라 이렇게 제작 부탁드립니다.”

UIUX ⇒ “이런 구조로 프리팹 제작 부탁드립니다.”

이펙트 ⇒ “이 오브젝트는 Canvas가 아니라 WorldSpace에 들어갈 예정이니, UI 이펙트가 아닌 일반 이펙트로 제작 부탁드립니다.”

#💽 데이터 구조 회의

쿠키런 킹덤은 게임 데이터를 위해 엑셀을 사용합니다. 서버와 클라이언트가 모두 엑셀 데이터를 가져다 사용하기 때문에 어떤 식으로 엑셀에 데이터를 입력할 것인지 논의가 필요합니다.

새로운 컨텐츠를 위해 데이터 구조를 새로 설계해야 하는 상황에 주로 진행하는 회의입니다.

#🛠️ 툴 개발

본격적인 점핑 플랫폼 게임 개발을 시작하기에 앞서, 기획팀에게 맵 툴이 필요한 상황이 되어 툴을 개발하게 되었습니다.

이 툴은 정해진 규칙에 따라 맵 데이터를 랜덤으로 생성하고, 결과를 유니티 에디터를 통해 가시적으로 확인하며 플랫폼의 위치나 타입을 원하는 대로 조정할 수 있도록 만들어졌습니다.

원하는대로 확률을 입력하면 그대로 맵을 찍어줍니다.

기존에는 데이터를 하나하나 입력해가며 맵을 완성해야 했지만, 툴을 통해 클릭 한 번으로 랜덤 생성이 가능해졌고, 원하는 확률을 실시간으로 조정해 바로 결과를 확인할 수 있게 되었습니다.

툴 개발은 이렇게 단순한 편의 기능을 넘어, 프로젝트 전체의 개발 효율과 안정성을 높이는 클라이언트 프로그래머의 주요 업무 중 하나입니다.

지금은 점핑 플랫폼 게임을 위한 맵 툴 하나만을 예시로 들었지만, 쿠키런 킹덤에서는 이 외에도 수많은 툴들을 제작 및 사용하고 있습니다.

툴이 가져다주는 이점은 다음과 같습니다:

반복 작업 자동화: 수동으로 해야하는 반복 작업을 클릭 몇 번으로 처리할 수 있게 만들어줍니다.
실수 방지: 사람이 직접 작업하다 보면 실수가 생기기 마련인데, 툴을 통해 데이터나 리소스를 다룰 때 발생할 수 있는 실수를 미리 탐지할 수 있습니다.
협업 효율 향상: 작업자가 다른 직군에게 요청하지 않고도 스스로 테스트해볼 수 있어, 반복적인 커뮤니케이션 비용이 줄어듭니다.
밸런싱 용이: 데이터를 빠르게 수정하고 테스트할 수 있어, 밸런싱과 퀄리티 향상에 큰 도움이 됩니다.

#🏗️ 작업 시작

이제 본격적인 개발이 시작되었습니다.

숙련된 클라이언트 프로그래머라면, 서버나 데이터 작업이 이미 끝났다고 가정하고! 리소스도 다 준비됐다고 생각하고! 미리 코드를 구상해보며 작업을 진행할 수도 있지만, 보통은 다음과 같은 순서를 거칩니다.

직군별로 독립적으로 진행되는 작업이 있고, 아닌 작업이 있습니다. 간단하게 정리해보면 이렇습니다.

클라이언트 프로그래머는 이 과정에서 모든 직군과 끊임없이 소통하며 작업을 조율합니다.

각 직군의 작업이 완료되면, 그 결과물을 모아서 실제 게임 안에서 동작하도록 구현하는 것이 클라이언트 프로그래머의 역할입니다.

#1. 데이터 & 서버 작업

작업이 시작되면 일단 기획팀에서 가데이터 작업을 올려줍니다.

가데이터 작업이 완료되면 서버에서 작업을 시작해서, 작업 내용을 반영한 서버를 띄워줍니다. 이후 클라이언트 프로그래머는 서버에 접속해서 서버 작업에 문제가 없는지 확인합니다.

#2. 리소스 작업

리소스 작업은 데이터 및 서버 작업과는 독립적으로 진행됩니다.

먼저 아트팀에서 게임에 들어갈 리소스를 제작합니다.

이후 UIUX팀이 해당 리소스와 기획서를 바탕으로 UI/UX를 설계하고, 실제 Unity에서 사용할 수 있는 프리팹(prefab)을 조립합니다.

왼쪽이 기획서, 오른쪽이 프리팹 시안

프리팹 제작이 완료되면 이펙트팀이 이펙트를 제작하여 시각적 효과를 추가하고,

모션 팀에서는 아트에서 작업해준 리소스에 움직임을 부여하여 생동감을 더해줍니다.

작업 중간중간, 각 리소스가 기획 의도나 설계대로 잘 제작되고 있는지 확인하는 절차도 중요합니다.

#3. 클라이언트 작업

필연적으로 클라이언트 프로그래머는 모든 직군의 작업이 완료되어야 작업을 끝마칠 수 있기 때문에 작업 순서 상 가장 마지막을 담당하고 있습니다.

앞에서 작업해주신 리소스, 서버, 데이터를 가지고 게임이 실제로 동작하도록 작업해줍니다. 기술적인 내용을 설명하는 글을 아니므로 자세한 작업 내용은 생략하도록 하겠습니다.

작업을 완료할 때 영상이나 캡쳐를 찍어서 리소스 제작자의 의도에 맞게 사용되었는지 확인해야 합니다.

작업을 하면서 같은 클라이언트 프로그래머끼리의 소통도 매우 중요합니다.

쿠키런 킹덤은 약 4년 반 동안 라이브 서비스를 이어오며 수많은 컨텐츠를 추가해왔고, 그만큼 프로젝트의 구조도 점점 깊고 복잡해졌습니다.

이런 기능이 필요하다 싶으면 80%는 이미 존재하는 기능입니다. 이미 구현된 기능을 모르고 또 추가하게 되면 코드가 중복되므로 불필요한 리팩토링이 이후 발생할 수 있습니다. 그래서 작업을 하면서 유사한 사례를 먼저 찾아보는 것이 중요합니다.

“이 기능, 이미 있을까요?”

“비슷하게 작업한 컨텐츠가 있을까요?”

”이 작업, 어떻게 하면 좋을까요?”

위와 같은 질문들이 실무에서는 클라이언트 프로그래머 사이에 거의 매일 오갑니다.

#📦 리소스 관리

개발 작업 마무리 단계에 해야하는 일이 있습니다.

바로 리소스 관리입니다.

리소스 관리를 어떻게 하는지 설명하기에 앞서, 쿠키런 킹덤에서는 Unity AssetBundle을 사용하고 있습니다.

AssetBundle이란, 게임 내 리소스를 따로 패키징해서 필요할 때 불러올 수 있도록 만든 Unity의 리소스 관리 시스템입니다.

AssetBundles - Unity 매뉴얼

앱의 용량이 크면 처음 다운로드 받을 때 오래 걸리기 때문에, 앱 자체는 가볍게 만들고 아래와 같은 타이틀 화면에서 추가적인 리소스를 다운받습니다.

이 때 앱에 포함되어 있는 리소스가 빌드 리소스, 타이틀 화면에서 추가로 다운받는 리소스가 AssetBundle 리소스(번들 리소스)입니다.

작은 규모의 프로젝트에서는 리소스를 빌드에 포함시켜도 큰 문제가 없습니다. 하지만 게임이 점점 커지고 업데이트가 누적되면 빌드 크기가 심각한 이슈가 됩니다. 그렇게 되면 빌드 내 리소스를 전부 번들로 옮기는 작업을 해야합니다.

만약 빌드에 들어있는 리소스가 번들 리소스를 참조하게 되면 다음과 같은 이슈가 발생하게 됩니다. 리소스를 제대로 불러오지 못해서 흰색 네모박스로 보이는 이슈입니다.

반대로 번들에서 빌드 리소스를 참조할 경우 빌드에 있는 리소스가 복사되어 번들로 들어갑니다. 결과적으로는 중복 리소스로 인해 번들의 용량이 늘어나게 됩니다.

최악의 경우 빌드를 다시 해서 업데이트를 다시 진행해야 하기 때문에 위와 같은 이슈를 방지하기 위해 클라이언트 프로그래머는 아래처럼 외부 리소스 참조 여부를 알려주는 툴을 제작해서 리소스를 관리합니다.

#↩️ 피드백 회의

마감 기간이 끝나면 해당 업데이트에 들어갈 모든 컨텐츠를 모아서 피드백 하는 회의가 있습니다. PD가 회의에 참여하여 구현이 처음 제시한 방향성대로 잘 되었는지, 더 필요한 부분은 없을지를 피드백 해주십니다.

이 회의 이후 3~4일 정도 피드백 반영 기간을 거치고, 본격적인 QA를 시작합니다.

#📝 QA & 빌드 제출

이제 QA팀의 작업이 본격적으로 시작됩니다.

QA팀이 컨텐츠 개발이 진행되는 동안 미리 해두었던 기획서 리뷰와 테스트 케이스를 토대로 테스트를 진행합니다.

기획서 리뷰 (인스펙션 작성)
- 인스펙션 : 기획 문서를 바탕으로, 초기 문제점을 사전에 탐색하고 보완하는 질의응답 과정을 말합니다.
TC(Test Case) 작성 : 인스펙션 내용을 반영한 기획서를 기반으로, 테스트 항목을 정리한 테스트 케이스(TC)를 작성합니다.
테스트 진행 : 테스트는 일반적으로 다음 순서로 진행됩니다 : 유니티 에디터 테스트 → 실제 기기 빌드 테스트
컨텐츠 플레이 및 피드백 제출

이 과정을 통해 실제 구현물이 기획 의도에 맞게 작동하는지 확인하고, 컨텐츠의 완성도를 높입니다.

클라이언트 프로그래머는 이 과정에서 발생한 피드백과 이슈를 수정하고, 다시 빌드하여 반영합니다.

QA 이후, 테스트를 마친 게임 빌드를 검수한 뒤 각 앱스토어(Google Play, Apple App Store 등)에 제출합니다.

#🪦 사후 관리

앱스토어에 제출했다고 끝난 것이 아닙니다. 이후에는 모니터링을 진행합니다.

#1. 라이브 이슈 수정

QA팀에서는 업데이트 이후에도 지속적으로 라이브 모니터링을 진행하고, 이슈가 나올 경우 원인을 확인해서 수정합니다.

어떤 이슈가 발생했느냐에 따라 대응 방식이 달라집니다.

리소스를 수정하는 것으로 고칠 수 있는 이슈는 패치를 진행하고, 코드를 수정해야 하는 이슈는 중요도에 따라 알려진 버그로 공지를 올리거나 빌드를 다시 해서 업데이트를 진행합니다.

#2. 메모리 관리

메모리 관련 이슈는 지금도 종종 저사양 기기를 사용하는 유저에게 발생하기 때문에, 지속적으로 모니터링해서 최적화를 해주어야 합니다. 모든 유저가 고사양 기기를 쓰는 것이 아니기 때문에, 저사양 환경에서도 원활하게 동작하도록 메모리 사용을 조절해야 합니다.

기기 사양에 따라 앱이 사용할 수 있는 메모리 양에 제한이 걸려있기 때문입니다.

예를 들어 iPhone 8이나 XR같은 일부 기기에서는 실행 중 앱이 사용할 수 있는 메모리가 약 2GB로 제한되어 있어서 이 이상으로 메모리를 사용할 경우 iOS는 메모리 보호를 위해 예고 없이 앱을 종료합니다.

게임이 안정적으로 실행되도록, 번들 리소스를 무제한으로 로드하지 않고 일정 시점마다 메모리에서 내리는 작업이 필요합니다.

위와 같은 로딩 화면을 띄워놓고 메모리 정리를 진행합니다.

주로 전투 화면에 진입하기 직전에 메모리를 정리하는데요, 전투 씬은 리소스를 많이 사용하는 씬이기 때문에 진입 직전에 사용하지 않는 리소스를 메모리에서 정리하여 여유 공간을 확보합니다.

#3. 리팩토링

작은 기술적 결함을 "시간이 없어서", "나중에 고치지 뭐" 하고 방치하다 보면, 그 문제가 점점 스노우볼처럼 굴러가 결국에는 팀 전체에 영향을 주는 큰 장애로 이어질 수 있습니다. 일명 기술 부채(Technical Debt)가 쌓인 것이죠. 이런 기술 부채를 예방하기 위해서는 리팩토링을 습관적으로, 꾸준히 진행하는 자세가 필요합니다.

지금은 아무 문제가 없어 보여도, 새로운 기능이 계속 추가되면서 코드의 복잡도는 점점 올라갑니다. 구조가 복잡해질수록 작은 수정이 큰 영향을 끼칠 수 있어, 어느 순간에는 리팩토링 없이는 손을 대기 어려운 지경에 이를 수 있습니다.

다만 리팩토링은 기능 변경을 동반하지 않더라도, 기존 동작에 영향을 주는 일이 자주 발생합니다. 따라서 리팩토링 전에 반드시 유관 부서와 협의하고, QA 및 PM 팀에 충분히 공유하여 리스크를 최소화해야 합니다. 또한 리팩토링 작업을 하는 사람은 테스트 코드를 짜두어 기존 기능이 잘 동작하는지 확인할 수 있어야 합니다.

#클라이언트 프로그래머가 되고 싶은 사람에게 하고 싶은 이야기

게임 클라이언트 프로그래머를 꿈꾸는 분들에게, 신입으로서 알아두면 좋은 기술과 실무에서 중요하게 여기는 태도를 소개드리고 싶습니다.

#✅ 신입으로서 알아두면 좋은 기술

신입으로서 알아야 하는 기술과 더불어, Unity 기반의 프로젝트에서 실무에 도움이 되는 기술들을 정리해보았습니다:

자료구조와 알고리즘 : 기본 중의 기본입니다. 면접에서도 자주 다뤄지는 만큼, 프로그래머라면 반드시 익혀야 합니다.
디자인 패턴 (Factory, Singleton, State, Observer 등) : 대규모 프로젝트에서 코드 유지보수성과 확장성을 높이기 위해 반드시 필요합니다.
Git : 버전 관리는 팀 프로젝트의 기본입니다. Git을 통해 브랜치 개념을 이해하고, 충돌 해결이나 커밋 이력을 관리하는 능력은 실무에 필요합니다.
Unity Profiler / Memory Profiler : GC 스파이크, 메모리 누수를 잡는 데에 핵심적인 도구입니다.

GC 스파이크 (Garbage Collection Spike)란?

C#에서 메모리 정리를 담당하는 Garbage Collector가 실행될 때, 게임 실행이 잠시 멈추는 현상을 말합니다. 큰 오브젝트 생성·삭제가 많으면 이 현상이 눈에 띄게 발생해, 프레임 드랍이나 끊김처럼 느껴집니다. 모바일 게임에서는 이를 최소화하는 것이 중요합니다.
UniTask 라이브러리 : coroutine, task보다 훨씬 가볍게 동작하여 GC 부담을 줄이는 데 유리합니다. 비동기 처리를 자주 하는 모바일 게임에서는 필수적으로 사용됩니다.
DOTween 라이브러리 : UI 애니메이션이나 연출 구현을 빠르게 도와주는 트윈 라이브러리입니다. 연출 퀄리티를 높이는 데 유용하면서도 사용이 간편합니다.

또한, 직접 게임을 처음부터 끝까지(출시까지) 만들어 본 경험만큼 좋은 포트폴리오는 없습니다. 출시한 게임이 있거나, 툴을 만들어 본 경험이 있다면 실무에 바로 도움이 되며, 팀에서도 높은 평가를 받습니다.

#🧠 실무에서 중요하게 여기는 태도

기술만큼 중요한 것이 ‘어떤 자세로 업무에 임하는가’입니다.

제가 현업에서 느낀, 클라이언트 프로그래머로서 중요한 자질들을 정리해보았습니다:

게임에 대한 애정과 몰입 : 게임을 좋아하는 사람은 결과물에 더 애정을 담게 됩니다. 결국 이런 마음가짐이 퀄리티와 디테일로 이어집니다.
끊임없이 배우려는 자세와 피드백을 수용하고 개선하는 마인드 : 기술은 계속 발전하기 때문에 끊임없이 배우려는 자세가 필요한 것 같습니다. 또 리뷰를 주고받는 일이 많다 보니, 방어적인 태도보다는 개선을 위한 수용력이 중요합니다.
끈기와 탐구심 : 실무에서는 ‘왜 이런 문제가 생겼는지’를 찾는 데 하루 이상 걸릴 때도 있습니다. 당장 눈에 보이지 않아도 포기하지 않고 끝까지 파고드는 태도가 필요합니다.
협업 중심 사고 : 클라이언트는 기획, 서버, 아트, UIUX, QA 등 모든 직군과 협업합니다. 타 직군의 흐름과 업무를 이해하려는 노력이 곧 원활한 개발로 이어집니다.

#마치며

제가 이 일을 하면서 가장 크게 느낀 건, 클라이언트 프로그래머는 게임을 살아 움직이게 만드는 사람이라는 점입니다. 그리고 그 과정에는 기술뿐 아니라, 소통, 문제 해결, 꾸준한 배움이 꼭 필요하다는 것도 함께 배웠습니다.

게임을 좋아하고, 계속 배우려는 마음이 있다면 누구든 이 일을 해낼 수 있습니다. 처음에는 부족할 수 있어도, 하나하나 익혀가다 보면 실력은 반드시 쌓이고, 언젠가 자신 있게 “나도 팀의 일원이다”라고 말할 수 있게 될 거예요.

지금 이 글을 읽고 있는 여러분이 그 첫걸음을 내딛고 있다면, 그 용기와 시작을 진심으로 응원하며, 이 글이 여러분의 여정에 작은 도움이 되기를 바랍니다.

읽어주셔서 감사합니다.

주니어 클라이언트 개발자의 성장 노트

Fri, 25 Jul 2025 00:00:00 GMT

#들어가며

안녕하세요. 스튜디오 킹덤 클라이언트 개발자 이한나입니다. 이 글은 제가 신입으로 입사하여 3년 차인 지금까지 일하며 경험한 것들을 돌아보고 되새겨 보는 글입니다. 이 글이 저와 같은 신입 또는 주니어 클라이언트 개발자분들께 작게나마 도움이 되기를 바라며 저의 경험을 나누고자 합니다.

#제발 담당자한테 물어보고 작업하자

일하다 보면 종종 내가 이해한 것과 기획자가 의도하는 방향이 다른 경우가 생깁니다. 확신이 가지 않는 부분은 당연히 물어봐야 합니다. 설계를 하고 있을 때, 작업을 진행하고 있을 때, 작업을 완료했을 때까지, 늦었다고 생각할 때가 가장 빠른 질문 타이밍입니다.

"10번 뽑기 기능"을 만드는 상황을 예시로 들어보겠습니다.

여기서 질문을 하지 않는 개발자가 1번 뽑기를 10번 반복하는 것으로 이해하고 (음! 전부 이해했어!) 작업을 진행합니다.

(이미지 출처 : 팝 팀 에픽)

그리고 마감날이 되어 테스트를 돌려본 기획자가 물어봅니다.

기획자 : 이거 뽑기 10번을 전부 보여주고 있네요? 뽑기는 1번만 보여주고 보상을 10개를 줘야 하는데 다르게 나오는 것 같아요. 확인 부탁드립니다.

클라이언트 개발자: !!!

그동안의 시간과 노력을 지우고 다시 작업을 하는 상황이 되어버렸습니다. 눈물을 머금고 다시 작업을 하고 싶지 않다면 자신이 이해한 것 그리고 작업 방향이 기획자가 의도하는 방향과 맞는지 물어보고, 기록하고, 작업을 진행하도록 합시다.

추가로 작업하면서 중간중간 결과물을 영상으로 찍거나 스크린샷으로 캡쳐해 공유합시다. 구현 방향을 공유하는 의미도 있고, 나중에 리팩터링하거나 기능이 추가될 때 원본 기능이 어땠는지 참고하기 좋아서 기록 차원에서라도 남겨두는 게 좋습니다. 그리고 귀여운 작업물을 만들었다면 자랑할 수 있다는 장점도 있습니다.

다른 프로그래머의 코드를 수정할 때도 비슷합니다. 코드에는 의도와 맥락이 있습니다. 왜 이런 코드가 있는지 물어보고 의도에 맞는 방향으로 작업해야 합니다. 그리고 수정 방향에 대해 얘기하다 보면 생각지 못한 더 좋은 코드가 떠오르거나 어딘가에 있는 동일한 코드를 가져다 쓸 수 있음을 알게 될 수 있어서, 어떤 코드에 대해 수정이 고민이 된다면 담당 프로그래머와 얘기해 보는 것이 좋습니다.

#데이터 수정은 기획자에게 요청하자

"쿠키런: 킹덤"에서는 기획자가 퀘스트 내용이나 쿠키의 능력치 같은 게임 데이터를 작업합니다. 적은 양의 데이터 수정일지라도 어떤 데이터는 서로 연결되어 있어 규칙에 맞게 입력해야 하고, 또 그 데이터를 수정하고 번역 요청을 하는 등 관리가 필요합니다. 따라서 데이터 수정은 담당 기획자에게 요청하는 것이 가장 안전합니다. (담당자한테 물어보자는 위 문단의 내용과도 유사합니다.)

#네트워크 환경이 항상 최선의 상태가 아닐 수 있음을 고려하자

예를 들어서, 클라이언트는 서버와 통신을 할 때, 클라이언트가 서버에 보내는 모든 요청이 실패할 수 있음을 고려해야 합니다. 유저의 네트워크 환경이 다양하기 때문입니다. 요청이 실패하면 경우에 따라 유저가 말을 걸어도 NPC 가 반응을 하지 않는 등 의도하지 않게 게임에 갇힐 수 있습니다. 그래서, 요청이 실패했을 때 화면이 어떻게 나와야 하는지, 다음 요청을 보내도 되는지, 요청이 실패하면 자동으로 다시 요청을 보내야 하는지 등 상황에 따라서 처리해야 합니다.

예를 들어, 유저가 버튼을 눌러 A 퀘스트를 클리어했다는 요청을 보냈는데 실패했다고 합시다. A 퀘스트는 클리어 통신 후 바로 다음 B 퀘스트를 시작하는 통신 요청을 (A 퀘스트 클리어 통신 성공 여부와 상관없이) 클라이언트에서 하게 되어 있습니다. 설상가상으로 B 퀘스트의 클리어 조건으로 걸려있는 게 A 퀘스트의 완료입니다. 이렇게 되면 유저는 B 퀘스트가 시작되어 있지만 영원히 클리어하지 못하게 될 수 있습니다.

이를 방지하기 위해 클라이언트는,

요청 실패 시, 성공할 때까지 재요청하기
요청 실패 시, 이후 처리를 하지 않도록 리턴하기(그래서 유저가 다시 버튼을 누르게 하기)
퀘스트를 완료해야 다음 퀘스트를 받을 수 있게 조건 걸기

등 팀의 개발 기조에 따라 예외 처리를 둘 수 있습니다.

이번에는 예방 방법이 아닌, 이미 유저가 통신 실패로 게임에 갇힌 상황에서 클라이언트 코드를 수정하는 방법에 대해 이야기해 보겠습니다.

예를 들어, 특정 조건을 달성하면 자동으로 요청을 보내는 기능이 있고, 요청이 실패했으나 유저가 따로 액션을 취할 방법이 없는 상황이 되었다고 해봅시다. 이렇게 되면, 분명 기능이 있는데 상호작용을 하지 못해서 좋지 못한 플레이 경험을 얻게 될 수 있습니다. 얼른 문제를 예방하기 위한 방어 코드를 추가하고 구출용 방안을 모색해야 합니다.

이때 클라이언트가 시도해 볼 수 있는 방안으로는,

유저가 버튼을 누르면 요청을 보내는 비상 탈출 기능 넣기
재진입 시 조건을 만족한 상태라면 요청을 자동 다시 보내기

등 상황에 맞게 수정을 해볼 수 있습니다.

이처럼 네트워크는 항상 실패할 수 있다는 전제를 두고 개발해야 합니다.

#라이브 서비스 중인 리소스는 조심히 다루자

이 주제를 얘기하려면 우선 빌드와 에셋번들에 대한 설명이 간단하게 필요합니다.

빌드는 코드, 프리팹, 텍스처 이미지 등의 리소스를 실행 가능한 파일로 묶은 것으로, 수정 시 전체 빌드를 새로 하고 스토어에 배포하는 과정을 거칩니다.
에셋번들은 리소스를 빌드와 분리된 외부 파일로, 빌드에 포함되지 않고 게임 내에서 패치 형식으로 다운로드하여 적용할 수 있게 해줍니다.

코드 수정이 필요하다면 빌드 수정이 필요하고, 에셋번들에 들어있는 리소스(프리팹 혹은 이미지 등) 수정이 필요하다면 에셋번들 수정으로 반영이 됩니다. 이 차이를 이해하고 있어야 다음 상황을 예방할 수 있습니다:

라이브 중인 기능을 수정하면서 어떤 변수가 더 이상 필요 없어 보여 코드상에서 제거했다고 합시다. 이 변수는 에셋번들로 관리되는 프리팹 A에서 사용하고 있습니다. 개발 환경의 코드에서는 더 이상 필요하지 않은 변수이지만, 라이브에 나가 있는 코드와 프리팹 A에서는 새 빌드를 스토어에 올리지 않는 한 이 변수를 사용하고 있을 것입니다. 개발 환경에서 변수가 제거된 프리팹 A'가 다른 라이브 수정이 필요해서 라이브에 나가게 되는 경우, 새 에셋번들의 프리팹 A’에서는 해당 변수가 사라지게 됩니다. 라이브의 코드는 제거된 변수를 참조하려 하므로 의도하지 않은 동작을 하게 됩니다.

이를 방지하기 위해 변수를 에셋번들의 프리팹에서 쓰고 있지는 않은지 먼저 확인하고 제거해도 될지, 남겨두어야 할지 고려하여 작업을 하는 게 필요합니다.

#마무리하며

시행착오는 누구나 겪을 수 있는 일입니다. 중요한 것은 그러한 경험을 혼자 감추지 않고 팀과 공유하며, 재발하지 않도록 개선해나가는 자세입니다.

이 글을 읽는 여러분도 한 번의 경험에 좌절하지 않고, 그 순간을 기회로 삼아 한 걸음 더 성장해 나가시길 진심으로 바랍니다. 우리 모두의 개발 여정을 응원합니다. 감사합니다.

결정론적인 알고리즘

Mon, 07 Jul 2025 00:00:00 GMT

안녕하세요. 소프트웨어 엔지니어 권형우입니다. 이 글에서는 게임 개발에서 결정론적인 알고리즘을 살펴봅니다.

#결정론적인 알고리즘에 대해

결정론적인 알고리즘은 같은 맥락에서 같은 입력을 수행했을 때 같은 결과를 냅니다. 다음은 용감한 쿠키의 움직임으로 결정론적인 알고리즘을 표현한 예시입니다.

용감한 쿠키가 (0, 0) 위치에서 출발
- 용감한 쿠키가 (5, 0)만큼 이동 -> 위치 (5, 0)
- 용감한 쿠키가 (0, 5)만큼 이동 -> 위치 (5, 5)
- 용감한 쿠키가 (-5, -5)만큼 이동 -> 위치 (0, 0)
용감한 쿠키의 최종 위치는 (0, 0)

용감한 쿠키가 같은 위치에서 출발해서 같은 양만큼 움직였다면 몇 번을 반복해도 용감한 쿠키의 최종 위치는 같습니다. 게임이 이런 결정론적인 알고리즘으로 구현되어 있다면 같은 입력은 같은 결과를 나타낸다는 근거로 여러 기능들을 구현할 수 있습니다.

#결정론적인 알고리즘의 구현

#고정 프레임 게임 루프

게임에는 게임 루프가 존재하고 대체로 입력 → 게임 로직 → 화면 그리기 순서로 수행됩니다. 이 단위를 프레임 이라고 하며 초당 프레임이 지나간 횟수를 FPS (Frames Per Second)라는 단위로 표현합니다.

게임에는 시간에 의존적인 코드 작성이 필요할 수 있습니다. 물체의 이동이나 시간 계산처럼 시간의 흐름에 따라 변화하는 게임 상태를 구현하기 위해 게임 루프에서 프레임이 처리되는 시간을 계산하고 활용합니다. 이를 프레임 처리 시간이라고 하겠습니다.

프레임 처리 시간은 기기 성능이나 게임 상태에 따라 매 프레임 다른 시간을 가집니다. 프레임 처리 시간이 매 프레임 달라진다면 게임 양상이 비슷하게 흘러갈 수는 있으나 결정론적으로 진행되지는 않습니다. 프레임 처리 시간이 달라짐에 따라 매 프레임 게임 상태에 다른 변화가 생기게 되고 달라진 게임 상태는 다른 결과를 만들 수 있기 때문입니다.

같은 입력에 대해 매번 같은 결과를 가지게 하는 결정론적인 알고리즘을 위해 게임 로직을 고정된 횟수대로 수행하는 고정 프레임 게임 루프를 사용할 수 있습니다. 고정된 시간 주기로 수행되는 게임 루프를 만들어서 항상 같은 프레임 처리 시간을 가지게 해 기기 성능에 상관없이 같은 결과를 가지게 합니다.

게임 루프를 고정된 주기로 수행하는 고정 프레임 게임 루프를 사용하면 게임 로직 수행 주기와 화면 갱신 주기에 차이가 생깁니다. 화면 갱신 주기는 하드웨어에서 정해진 주기를 따라가는데 게임 로직 수행 주기는 하드웨어에 관계 없이 고정 프레임 게임 루프에서 정해진 주기대로 수행되기 때문입니다. 화면 갱신 주기에 맞춰 고정 프레임 게임 루프를 사용하기 위해 예측을 구현할 수 있습니다.

예측이란 마지막으로 갱신된 게임 로직 수행 상태에서 다음 프레임 사이 화면 갱신 주기에 현재 상태를 예측하여 화면에 표현하는 작업입니다. 물체의 움직임이나 애니메이션처럼 화면에 보여지는 것들에 대해 예측을 구현해 고정 프레임과 다른 화면 갱신 주기를 가지는 기기에서도 화면 갱신 주기에 맞춰진 게임 상태를 표현할 수 있습니다.

#랜덤

게임에는 확률적으로 진행되는 것들이 있습니다. 확률적으로 진행되는 요소들을 결정론적으로 구현하기 위해 시드값을 넘겨받아 초기화하는 랜덤을 사용합니다. 시드값이 같다면 생성되는 난수도 같은 결과를 가지게 되어 확률적인 동작들을 결정론적으로 구현할 수 있습니다.

#마무리

게임 코드를 결정론적으로 작성하면 기기 성능에 영향을 덜 받는 결과를 만들 수 있고 개발 환경에 도움을 줄 수 있습니다. 또한 결정론적인 알고리즘이 뒷받침되어야 구현할 수 있는 기능들도 존재합니다.

게임을 개발할 때 필수적인 요소는 아니지만 상황에 따라 많은 도움을 줄 수 있습니다. 현재 진행중인 프로젝트에 어울리는지 혹은 활용할 여지가 있는지 살펴보고 적용하여 프로젝트를 발전시킬 수 있습니다.

데브시스터즈 엔지니어링 데이 - Data 돌아보기

Mon, 23 Jun 2025 00:00:00 GMT

안녕하세요. 데브시스터즈 기술본부에서 조직·기술 문화를 가꾸고 있는 전경아입니다. 이번 글에서는 2025년 5월 29일에 진행했던 <제2회 데브시스터즈 엔지니어링 데이 - Data> 에 대해 소개해드리고, 온라인 다시보기 영상도 공유하고자 합니다.

#행사 소개

‘데브시스터즈 엔지니어링 데이’란, 데브시스터즈에서 마주하는 기술적인 문제를 공유하고, 어떻게 풀어가는지 외부에 경험을 나누는 행사입니다. 본 행사를 통해 개발자 간에 소통할 수 있는 교류의 장을 만들고, 개발자 생태계에 긍정적인 영향을 주기 위해 노력을 기울이고 있습니다.

데브시스터즈의 서비스를 견고히 지탱해나가는 Infra/SRE 분야에서 일하고 계시는 세 명의 발표자를 모시고 발표와 패널톡을 진행했던 제1회 데브시스터즈 엔지니어링 데이 - Infra/SRE(링크)가 지난 2025년 2월 큰 관심 속에 마무리되었는데요, 다음으로 데이터와 관련된 행사도 있으면 좋겠다는 피드백을 반영하여 제2회 엔지니어링 데이는 '데이터'를 핵심 주제로 정했습니다. 데브시스터즈의 게임은 240여개국, 누적 2억 명 이상의 많은 유저분들에게 큰 사랑을 받고 있으며, 그 결과 매일 10 TB 이상의 데이터가 수집됩니다. 이 데이터를 효과적으로 관리하고 게임 기획부터 라이브 서비스까지 다양한 의사결정에 활용하기 위해, 데브시스터즈의 데이터 분야에서는 어떤 문제들을 고민하고 해결해 나가고 있는지 소개해 드리고자 합니다.

#발표 1 - 스키마, 버전 그리고 로그: 안정적인 로그 파이프라인 구축기

데이터엔지니어링셀 김규탁님

JSON 형식의 로그는 높은 자유도 및 편의성을 제공하지만, 한편으로 다양한 문제도 있습니다. JSON 로그의 문제를 해결하기 위해 도입된 ‘스키마 기반 로그 파이프라인’의 전반적인 설계와, 여러 버전의 스키마를 동시에 지원하기 위한 방법을 공유하고 JSON 로그의 자유도와 복잡함 속에서 어떻게 일관된 구조를 지키고 안정적인 분석 환경을 만들 수 있는지 소개해주셨습니다.

#발표 2 - 준실시간 파이프라인 구축기

데이터엔지니어링셀 서혜인님

데브시스터즈는 게임 런칭과 같은 핵심 순간에 필요한 지표를 신속하게 제공하기 위한 준실시간 데이터 파이프라인을 구축했습니다. 본 세션에서는 기존 시스템의 정확도와 안정성 문제를 해결하기 위해 어떤 고민을 하고 설계했는지 그 과정을 공유하고, 기술적인 이야기뿐만 아니라, 팀과 고객의 요구사항을 반영하여 실용적인 데이터 서비스를 만들어나가는 데브시스터즈의 일하는 가치관도 함께 소개해주셨습니다.

조금 더 기술적인 내용은 발표에서 QR 코드로 소개해주셨던 기술블로그 포스팅 ‘지금 매출 얼마인가요’를 참고해주세요.

#발표 3 - DW는 계획대로 되지 않아! - 게임 데이터 공통화, 이상과 현실 사이에서의 여정

DI셀 김가은님

데브시스터즈에서 서비스하는 게임이 늘어남에 따라, 모든 게임 데이터를 하나의 통합된 DW로 관리하는 '게임 DW 공통화'를 추진했습니다. 하지만 이상적으로 보였던 계획은 예측하기 어려운 데이터 앞에서 여러 난관에 부딪혔습니다. 이 과정에서 겪은 현실적 문제들과 이를 해결하는 과정, 그리고 앞으로의 과제와 새로운 도전 방향을 소개해주셨습니다.

#발표 4 - Level Up! CookieRun: Kingdom Data

쿠키런: 킹덤 데이터 이지용님

쿠키런: 킹덤 팀은 더 좋은 게임, 더 나은 유저 경험을 만들기 위해 게임 곳곳에서 데이터를 활용하고자 노력해왔습니다. 데이터 기반의 게임 디자인 의사 결정, 업데이트 성과 리포팅과 다양한 라이브 상황 대응 등 게임 곳곳에서 데이터를 사용하는 사례들을 중심으로, 데이터를 더 잘 활용하는 조직이 되기 위해 고민했던 많은 생각과 ‘게임팀에서 데이터를 잘 활용한다는 것’은 무엇일지 공유해주셨습니다.

#패널톡 & 채용 부스

발표가 끝난 뒤에는 약 40분간 참관객과 발표자가 직접 소통하는 패널톡이 이어졌습니다. 참관객들께서 궁금한 점을 말씀해주시면 발표자분들께서 돌아가면서 답변해주셨는데요, ‘현재 사용하는 DW 제품의 선택 이유’, ‘오랜 기간 서비스 중인 게임을 운영할 때 현재와 명세가 다른 레거시 데이터 처리’, ‘GDPR같은 컴플라이언스 이슈’, ‘LLM과 DW 활용’ 등 다양한 질문을 남겨주셨고, 발표자분들께서도 질문 하나하나 진지하게 고민하며 답변해주셨습니다. 서로 인사이트를 나누는 패널톡은 앞선 발표들과는 또 다른 분위기의 의미있는 시간으로 꾸려졌습니다.

한편, 행사장 한쪽에는 채용 상담 부스가 운영되었습니다. 데브시스터즈 데이터 직무에 관심 있는 참관객들을 위해 채용 담당자와 데이터 직군 스태프들이 직접 궁금증을 해소해주었습니다. '데브시스터즈 데이터 직군은 어떻게 일하는지', '어떤 역할을 맡게 되는지', ‘어떤 문화를 가지고 있는지’ 등 깊이 있는 대화를 나누는 자리로, 방문하신 많은 분들께서 긍정적인 피드백을 남겨주셨습니다.

#마치며

행사 당일, 소나기가 오는 변덕스러운 날씨에도 많은 분들이 발걸음하셔서 자리를 빛내주셨습니다. 또한, 발표가 끝나고 진행된 패널톡에서 정말 많은 질문을 해주셔서 현장에서의 열기를 다시 한번 느낄 수 있었습니다.

행사를 마치고 피드백을 정리하는데 행사 개최에 대한 감사부터 발표, 패널톡 등 행사 전반에 대한 긍정적인 후기까지 마음이 정말 따뜻해지는 내용이 많았습니다. 이런 피드백을 보며 저도 이번 행사를 통해 한단계 성장한 느낌이 들었습니다.

데브시스터즈 엔지니어링 데이 - Data에 큰 성원을 보내주셔서 감사드리며, 남겨주신 피드백을 바탕으로 발표자도, 참석하신 분도 서로 더욱 성장할 수 있도록 더욱 알찬 엔지니어링 데이를 준비하여 돌아올 예정이니 많은 관심 부탁 드립니다. 감사합니다.

데브시스터즈 엔지니어링 데이 - Infra/SRE 돌아보기

Thu, 03 Apr 2025 00:00:00 GMT

데브시스터즈에서 마주하고 있는 기술적인 문제를 공유하고 어떻게 풀어가고 있는지 경험을 나누는 행사 ‘데브시스터즈 엔지니어링 데이’를 소개합니다.

안녕하세요. 데브시스터즈 기술본부에서 조직문화, 개발문화를 가꾸고 있는 전경아입니다. 이번 글에서는 2025년 2월 13일에 진행했던 데브시스터즈 엔지니어링 데이 - Infra/SRE에 대해 소개해드리고, 발표 영상도 공유하고자 합니다.

#행사 소개

데브시스터즈에서 서비스중인 게임은 유저 여러분들께서 많은 사랑을 보내주시는 만큼 매일 대규모 트래픽이 발생하고 있습니다. 그 속에서 견고히 서비스를 지탱해나가는 Infra/SRE 분야에서 마주치는 기술적인 문제를 어떻게 해결해나가고 있는지 소개해 드리고자 이번 데브시스터즈 엔지니어링 데이 - Infra/SRE 행사를 기획하였습니다.

데브시스터즈와 같은 게임업계부터 하드웨어 제조사까지 다양한 업계에서 관심있는 분들이 모여 적극적으로 소통해주셔서 저희도 준비한 행사를 잘 진행할 수 있었습니다.

데브시스터즈 엔지니어링 데이 진행중인 모습

#발표 1 - 데브시스터즈의 장애 대응 원칙과 방법

인프라셀 셀장 이창원님

우리가 생각하는 ‘서비스 장애’란 무엇인지부터, 많은 수의 게임을 운영하는 데브시스터즈의 모든 개발팀에 통용되는 장애 대응 원칙을 크게 장애 대응 원칙과 방법, 알람 티어링 권장 체계, 효과적인 장애 대응 방법 세 부분으로 나누어서 데브시스터즈에서 발생했던 실제 사례와 함께 자세히 소개해주셨습니다.

발표에서 QR 코드로 소개해주셨던 기술블로그 포스팅도 함께 공유 드립니다.

🔗 https://tech.devsisters.com/posts/incident-management-principles/

#발표 2 - Dalgona: 쿠버네티스 인프라 표준화의 여정

인프라셀 용찬호님

데브시스터즈는 다양한 게임을 많은 수의 쿠버네티스 클러스터에서 관리하고 있습니다. 그러나 클러스터 수가 점차 증가하면서 쿠버네티스 레벨에서의 권한 관리가 어려워지거나 클러스터 유지보수 비용이 증가하는 문제가 있었습니다. 또한, 중앙 인프라 조직은 초기에 AWS 에서 로드 밸런서로 Classic Load Balancer(ELB)를 사용하다가 점차 Global Accelerator(GA)와 Network Load Balancer(NLB)로 전환했습니다. 그러나 이러한 최신 기술과 노하우가 조직 전체에 효과적으로 공유되지 않아, 게임 라이브팀은 여전히 기능이 제한적인 ELB를 계속 사용하는 등 노하우가 제대로 전파되지 않는 등의 상황도 발생하였습니다. 이런 현상을 해결하고 중앙 인프라 조직이 전사 쿠버네티스 클러스터를 효율적으로 관리하기 위해 인프라 형상을 표준화한 이야기와 함께 그 과정에서 어떤 고민을 하였는지, 데브시스터즈의 플랫폼 엔지니어링은 앞으로 어떤 계획이 있는지 소개해주셨습니다.

#발표 3 - 게임팀을 위한 궁극의 배포 시스템 만들기

인프라셀 노정훈님

Argo Workflow로 기획자와 서버 개발자 모두 중앙 인프라 조직의 도움을 받지 않고 사용할 수 있는 배포 시스템을 개발한 과정을 소개해주셨습니다. 기존 배포 툴은 도커 이미지 태그 형태가 고정되고 서버팀에서 환경 변수 수정이 직접 불가능하여 중앙 인프라 조직의 개입이 필수였고, 차트 설치 한 단계로 모든 배포를 해야 하여 Hook으로 제한적인 분리만 가능한 등의 한계점이 있었는데요, 이런 어려움 속에서 어떤 점을 고려하여 데브시스터즈만의 배포 시스템 ‘플랑’을 개발했는지 공유해주셨습니다.

#마치며

데브시스터즈 엔지니어링 데이에 보내주신 관심과 성원 감사드리며, 발표부터 네트워킹 세션까지 참석해주신 분들과 함께 현장에서 직접 교류할 수 있어 더욱 의미있는 시간이었습니다.

앞으로 Infra/SRE 외에도 다양한 분야의 엔지니어링 데이를 진행할 예정이니, 계속해서 많은 관심 가져주시길 바라며 이만 마치겠습니다.

감사합니다.

새로운 팀의 코드베이스 적응기: 내 코드로 만들어가는 과정

Wed, 05 Mar 2025 00:00:00 GMT

#서론

안녕하세요! 저는 쿠키런: 마녀의 성 서버를 담당하고 있는 5년 차 게임 서버 개발자 주윤아입니다.

이직을 고민하고 계신가요? 새로운 팀에 합류하거나, 전혀 다른 코드베이스에서 일하게 된다는 건 많은 개발자에게 큰 도전으로 다가올 수 있습니다. 저 역시 같은 고민을 했습니다. 전 직장에서는 하나의 프로젝트에 4년 동안 몸 담으며 처음부터 끝까지 모든 과정을 경험했기 때문에, 새로운 환경에서 타인의 코드를 이해하고, 빠르게 적응해 성과를 낼 수 있을지 걱정이 컸습니다.

하지만 그런 두려움에도 불구하고, 저는 데브시스터즈에서 1년 동안 두 개의 프로젝트에 참여해 각기 다른 코드베이스를 학습하고, 저의 것으로 만드는 과정을 거쳤습니다. 그 과정에서 크고 작은 기능 구현과 업데이트를 성공적으로 완료 하며 팀에 완전히 녹아들 수 있었죠.

본론에 들어가기 앞서, 첫 번째 팀이 아닌 두 번째 팀인 쿠키런: 마녀의 성 코드베이스 적응 과정에 집중하려고 합니다. 그 이유는, 두 번째 팀에서 경험한 것이 저에게 더욱 큰 도전이었기 때문입니다. 이전 팀에서는 익숙했던 C# 기반의 객체 지향 프로그래밍 언어를 사용했지만, 두 번째 팀에서는 함수형과 객체 지향 멀티 패러다임 언어인 Scala 를 처음 접하게 되었고, 더불어 새로운 아키텍처를 학습해야 했습니다. 또한 당시 혼자서 학습을 해야 했던 특수한 상황이었기에 그 과정은 더욱 까다로웠습니다.

이번 글에서는 제가 새로운 코드베이스에 적응하고, 그것을 내 것으로 만드는 과정에서 느꼈던 고민들과 배운 점들을 공유하려 합니다. 이직 후 새로운 팀에 적응하는 것이 막연하게 느껴지는 주니어 개발자들에게 이 글이 작은 도움이 되길 바랍니다.

#본론

#공부의 순서 정하기

새로운 팀에 합류하면서 낯선 코드 베이스와 프로그래밍 언어를 어떻게 효율적으로 익힐 수 있을지 고민이 컸습니다. 사람 마다 학습 방법이 다르겠지만, 저처럼 정석보다는 꼼수에 의존해온 사람에게는 특히나 공부의 순서를 정하는 것이 어려웠습니다. 제가 정한 학습 흐름은 크게 세 가지 단계로 나눌 수 있었습니다.

문법 학습 : 새로운 언어의 기본 문법을 익히는 것이 가장 중요했습니다. 이 과정에서 사내에서 모든 스칼라 개발자가 완독했다는 빨간 책이라는 scala 관련 서적을 참고했습니다.
1. 스칼라로 배우는 함수형 프로그래밍 (제이펍, 2015)
프레임워크 학습 : 서버 개발을 위해 사용되는 ZIO 프레임워크의 구조와 동작 방식을 파악했습니다.
상업 코드 분석 : 실무에서 작성된 코드를 분석하고 작은 퀘스트들을 수행하며 경험치를 쌓았습니다.

기존에 알고 있던 객체지향 언어들과 달리 새로운 패러다임을 익히는 과정은 고통스럽기도 했지만, 사내 상업 코드를 보며 월급을 받으며 새로운 언어를 학습할 수 있다니, 완전 럭키비키🍀 였습니다.

#새로운 팀의 코드 아키텍처

현재 팀의 코드베이스는 제가 익숙했던 기본 아키텍처와는 달랐습니다. 헥사고날 아키텍처와 도메인 주도 설계(DDD)를 기반으로 한 방식은 개념으로만 알고 있었고, 실제로 적용해 본 적은 없었습니다.

처음에는 낯선 함수형 언어와 새로운 아키텍처에 당황하기도 했습니다. 마치 대학 시절 객체 지향 프로그래밍 언어를 처음 배웠을 때의 혼란스러움이 떠오르더군요. 그 당시 “그래서 인터페이스가 뭔데?”라는 질문을 던졌다면, 지금은 “모나드가 뭔데?”라고 묻고 있는 상황이죠. 이러한 개념들은 여전히 머리로는 이해하기 어렵지만, 경험을 통해 가슴으로 이해하게 되는 순간들이 있었습니다.

#낯선 코드 속에서 길 찾기

새로운 코드베이스에 적응하기 위해 협업 미팅을 통해 약 일주일간 스칼라 문법과 프레임워크를 학습했고, 그 후 3주간 실제 퀘스트를 진행했습니다. 이 과정에서 가장 많이 사용한 방법은 코드 분석과 디버깅이었습니다. 디버깅 방법도 과거의 저와 달라졌습니다. 예전에는 오로지 printf 디버깅만으로 문제를 해결했었는데, 이제는 디버거 없이는 작업하기 어려운 상황이 되었죠. 물론 콜스택이 많이 쌓이는 경우에는 여전히 printf를 찍어가며 분석하는 경우도 있긴 합니다. 😊

새로운 언어, 새로운 패러다임, 새로운 프로젝트이기 때문에 모든 것이 낯설었습니다. 특히, 이미 출시된 게임 프로젝트의 방대한 코드와 구조를 빠르게 파악하는 것은 쉬운 일이 아니었습니다.

그래도 게임 서버 개발자로서의 핵심 역할은 유사할 것이라는 믿음으로, 우선 SignIn 기능에 집중했습니다. 로그인은 어떤 게임이든 필수적인 통신이며, 이 프로토콜을 완벽히 이해하면 팀의 구현 프로세스를 파악하는 데 도움이 될 거라 생각했습니다. 기획 문서를 파고들 필요 없이, 한 가지 프로토콜만 잘 이해해도 프로젝트 전반에 대한 감을 잡을 수 있으니까요!

#첫 번째 퀘스트 : 코드 분석과 기본 익히기

가장 먼저 한 작업은 서버 컴파일 및 서버 실행이었습니다.

모든 개발의 첫 단계는 프로그램이 로컬 환경에서 컴파일되고 실행되는 것입니다. 팀마다 개발환경이 다르기에 이 과정에서 많은 시간을 할애하게 되었습니다. 로컬 문제인줄 알았던 것이 팀 문제였고, 팀 문제인 줄 알았던 것이 로컬 문제로 판명되는 재밌는 상황도 펼쳐졌죠. 일반적이지 않은 의존성 문제나 데이터베이스 프로토콜화 변환이 익숙지 않아 처음에 많이 헤매기도 했습니다.

#두 번째 퀘스트 : 로그인 보상 기능 구현

로그인 시 보상을 주는 기능은 단순해 보이지만, 함수형 프로그래밍 패러다임에 익숙해질 좋은 기회였습니다. 이 퀘스트의 핵심은 이벤트를 발생시키는 liftEvent 함수의 사용이었는데, 이는 함수형 프로그래밍에서 사이드 이펙트를 관리하는 일반적인 패턴 중 하나입니다.

스칼라로 배우는 함수형 프로그래밍 책을 읽어봅시다 1편

liftEvent 는 이벤트를 처리하기 위한 사이드 이펙트를 함수형 패러다임 내에서 안전하게 발생시키기 위해 사용됩니다. 함수형 패러다임의 기본 개념인 함수는 하나의 기능을 수행해야 한다 는 원칙을 따르면서도, 하나의 함수 내에서 이벤트 발생이나 로깅 등의 사이드 이펙트를 처리할 수 있는 방법입니다. 즉, 순수한 계산의 흐름 속에서 이벤트 발생과 같은 부수 효과를 끼워 넣을 수 있는 형태로 구현 되는 것이죠.

Scala 에서 암묵적 매개변수(implicit parameter)가 컴파일러에 의해 자동으로 전달되는데, liftEvent 와 같은 함수에서 이러한 암묵적 매개변수가 함수의 동작에 필요한 Context 를 제공할 때 특히 유용합니다. liftEvent 함수는 보상 이벤트를 처리하는 데 필요한 환경을 암묵적으로 받기 때문에, 코드가 간결해지고, 함수형 설계 원칙을 유지하면서도 필요한 사이드 이펙트를 효과적으로 관리할 수 있습니다.

#세 번째 퀘스트 : gRPC 프로토콜 이해와 연습

운영툴 프로토콜에서 gRPC 생성 후 print 찍기는 간단한 수정 작업이었지만, Scala 에서 타입 일관성을 유지하는 스칼라 로직의 특징을 익히는 데 중요한 역할을 했습니다.

특히, ZIO 에서 사용되는 for 표현식에서의 타입 불일치 문제를 이해하고 프로토콜 작업의 기본 구조를 익혔습니다.

scala 에서 println 과 같은 사이드 이펙트는 zio.succeed 로 감싸서 ZIO 모나드 형태로 만들어야 합니다. zio.succeed(println("example")) 는 ZIO[Any, Nothing, Unit] 타입의 값을 변환하여 안전하게 사이드 이펙트를 처리하는데, 이는 함수형 프로그래밍의 원칙을 유지하면서도 로그 출력과 같은 작업을 가능하게 합니다. 특히 for 표현식에서는 flatMap, map, withFilter 등의 연산이 순차적으로 올바른 타입을 반환해야 하므로, 타입 불일치를 방지하기 위해 각 연산에 맞는 형태를 유지하는 것이 중요합니다.

#네 번째 퀘스트 : 운영 gRPC 에서 운영로그 남기기

gRPC로 로그를 남기는 작업에서는 특히 로그의 중요성을 새삼 느꼈습니다. 게임 운영 중 발생하는 CS 요청이나 버그 분석을 위해서 꼼꼼한 로그 작성은 필수적입니다. 처음에는 분석 로그 구조와 삽입 위치를 몰라 디버깅이 어려웠지만, 지금은 분석 로그 클래스 계층을 상속받아 liftEvent 로 필요한 시점에 이벤트를 발생시키고, 이를 처리하는 함수에서 케이스를 추가하는 패턴을 익혔습니다.

이제까지의 과정은 새로운 코드베이스와 프로그래밍 패러다임에 적응하며 프로젝트 전반에 걸쳐 필요한 기초를 다지기 위한 시간이었습니다.

Scala 와 함수형 프로그래밍에 익숙해지기 위해 첫 주는 문법과 개발 환경을 설정하는 데 집중했고, 이후 실제 퀘스트를 수행하며 코드를 분석하고 로컬 환경에서 컴파일과 실행을 반복했습니다. 특히 SignIn 기능 구현을 통해 기초 프로토콜의 흐름을 파악하고, 이벤트 처리를 위한 liftEvent 를 활용하면서 사이드 이펙트를 제어하는 패턴도 실습했습니다.

약 3주 간의 집중적인 학습과 디버깅 과정을 통해 새로운 언어와 시스템에 적응하고, 코드 베이스의 핵심 구조와 팀의 개발 방식을 이해하는 중요한 발판을 마련할 수 있었습니다.

#작은 피처에서 큰 피처까지

팀 이동을 성공적으로 마친 뒤, 작업의 첫 단계에서는 광고 시스템 관련 작은 피처를 수정했습니다. 비록 간단한 수정 작업이었지만, 프로토콜 추가 및 기획 데이터 테이블 연동 과정에서 코드베이스의 구조를 이해하는 데 많은 도움이 되었습니다. 이후 조금 더 큰 작업인 쿠키 퍼즐 챌린지 작업에 착수했을 때는 더 복잡한 로직을 다뤄야 했고, 아키텍처 간의 상호작용을 이해하는 것이 필수적이었습니다.

작은 피처들을 작업하면서, 제가 한 동안 사내 개발자들 분께 입버릇 처럼 하는 말이 있었죠. “작업 하긴 하는데, 머리가 아니라 본능대로 손이 코드를 짜는 기분이에요-”

프로젝트 내에 원하는 로직을 조립하는 것에는 익숙해 졌지만, 코드 전체 흐름은 전혀 보이지 않던 상황이었습니다.

점차 작업의 난이도가 높아졌고, 특히 유적 탐험 이벤트 작업은 워크타임만 약 2-3주가 걸렸습니다. 이 작업을 통해 코드베이스의 큰 그림을 완전히 파악할 수 있었습니다. 그 이전에는 나무는 보였지만 숲은 보이지 않았던 상황이었다면, 이제는 큰 틀 안에서 작은 피처들을 이해하고 구현할 수 있게 되었습니다.

이렇게 차근차근 작은 작업부터 큰 프로젝트까지 경험하면서, 팀의 코드를 내 것으로 만들 수 있었고, 새로운 환경에 대한 두려움도 서서히 사라졌습니다.

#도전과 극복

함수형 프로그래밍 패러다임 자체가 낯설어 개념 이해에 시간이 많이 소요되었습니다. 기존에 익숙했던 객체지향 패러다임과 달리, 스칼라는 문법이 복잡하여 한 가지를 이해했다 생각해도 다른 부분을 보는 순간 백지가 된 기분이었습니다.

가장 어려웠던 점은 문서화의 부족이었습니다. 게임 프로젝트 팀이라면 다들 공감하실 텐데, 초기에는 탄탄한 아키텍처와 문서화 작업을 해놓아도, 출시가 가까워지면 급변하는 요구 사항으로 인해 계획이 엎어지기 마련이죠. 그러다 보니 복잡한 코드와 생소한 언어를 문서화 없이 익히는 데 꽤 고전했습니다.

학습 과정에서 많은 팀원분들의 도움을 받았으며, 특히 파트장님께 질문을 자주 던져 문제를 해결했습니다. 질문을 할 때 꿀팁이 있다면, 무작정 안된다고만 하지 않고 스스로 ‘이건 왜 작동이 안되는 걸까-?’ 사고해보며 이런 저런 액션을 취한 후, 본인이 생각했을 때 동작이 되지 않는 이유 혹은 동작하기 위해 어떤 작업을 했는지 머릿속에 정리 한 후 질문을 드린다면 좀 더 명쾌한 답을 얻으실 수 있으실 겁니다.

다행히도 저는 출시 이후에 합류했기 때문에 이러한 혼란 속에서도 새로운 코드베이스를 익히면서 어려운 부분들을 체크해 가이드 문서를 작성할 수 있었습니다.

#팀과의 협업 : 코드 통합과 소통의 중요성

코드 리뷰와 피드백 과정을 통해 성장할 수 있었습니다. 코드 리뷰를 두려워하지 않고, 오히려 팀원들과의 소통을 통해 배워나가는 과정에서 많은 발전을 이룰 수 있었습니다.

또한, IT 업계 중 특히나 게임업계에서는 타 직군과의 소통 또한 중요한 요소로 작용했습니다. 게임 개발은 다양한 직군들이 협력해야 하기 때문에, 원활한 의사소통이 프로젝트 성공의 중요한 키가 되기도 하죠.

#마무리

팀의 코드베이스를 처음 접했을 때는 모든 것이 생소하고, 새로운 환경과 도구에 적응하는 데도 시간이 걸렸습니다. 초기에는 작은 작업을 하나 할 때마다 기획서부터 꼼꼼히 준비해야 할 만큼 낯설었지만, 6개월이 지난 지금은 팀의 코드 흐름과 아키텍처에 대해 이해하게 되어 비교적 자유롭게 작업할 수 있게 되었습니다. 심지어 팀 내에서 가이드 문서를 작성할 수 있을 정도로 익숙해졌습니다.

앞으로는 요구사항 구현을 넘어 시스템 개편에도 도전하고 싶습니다. 특히, DB 및 캐시 구조를 개선해 게임 성능을 최적화하는 프로젝트를 진행해 보고 싶습니다. 또한, 지금처럼 학습할 수 있는 기회가 있을 떄 근본적인 질문을 던지며 새로운 호기심도 품어보고 싶습니다. 적응 초기 단계의 질문은 성장의 원동력이 되기도 하니까요.

이번 적응 과정을 통해 깨달은 점도 많습니다. 게임 서버 개발자가 근본적으로 해야 할 일은 크게 다르지 않다- 라는 것처럼요. 결국 개발자는 소통하고, 필요한 프로토콜을 설계하고, 이슈를 해결해가며 끊임없이 나아가야 합니다.

또한, 팀에 새롭게 적응하는 데는 두 가지 접근법이 있다고 생각합니다.

시간적 여유가 있다면, 언어와 아키텍처를 충분히 학습한 뒤 작은 기능을 하나씩 구현하며 점진적으로 팀에 적응하는 것이 정석적인 방법이라 생각합니다.

그러나 빠른 기여가 요구되는 상황에서는 프로젝트와 언어를 동시에 익히면서 진행할 수 밖에 없는 경우도 많습니다. 이렇게 빠른 적응법을 사용하면 즉각적인 팀의 기여는 가능해지지만, 기초적인 개념이 머리에 남지 않을 위험도 크기 때문에 이후에도 지속적인 학습이 필요합니다.

마지막으로, 팀 적응과 언어, 아키텍처에 대한 깊은 이해는 별개의 문제임을 항상 기억했으면 합니다. 팀 적응에만 안주하지 말고, 내가 속한 프로젝트의 구조와 이론적 부분을 놓치지 않으려는 노력이 중요합니다. 그러한 지속적인 관심과 학습이 개발자로서의 성장을 이끌어 낼 것이라 믿습니다.

데브시스터즈의 장애 대응 원칙과 방법

Thu, 13 Feb 2025 00:00:00 GMT

안녕하세요, 저는 데브시스터즈 기술본부 인프라셀에서 DevOps 엔지니어로 일하고 있는 이창원입니다. 이 글에서는 데브시스터즈에서 전사적으로 적용하고 있는 기술적 관점에서의 장애 대응 원칙과 방법 전문을 공개합니다.

문서에 대한 설명은 데브시스터즈 엔지니어링 데이 Infra/SRE 행사 영상에서도 확인하실 수 있습니다.

#개요

이 문서는 우리가 운영하는 각종 서비스의 장애에 대한 탐지, 대응, 예방을 위해 가져야 할 자세와 방법론에 대해 서술합니다.

#원칙

📌 이 원칙들은 구성원들이 상시 장애 상황을 모니터링하라는 의도에서 만들어진 것이 아니며, 꼭 필요한 순간에만 기민한 대응을 할 수 있도록 원칙과 방법을 설정한 것입니다.

📌 모두가 기본적인 응급 조치를 할 수 있는 역량을 확보해야 합니다. 그래야 담당자가 쉬거나 부재 중이더라도 다른 사람이 대응할 수 있고, 서로를 믿고 편하게 쉴 수 있습니다.

[장애 대응의 목표] 장애 대응의 최우선 목표는 서비스가 가능한 정상적으로 동작하게 하는 것입니다.
- 지식이나 경험의 많고 적음에 관계 없이, 서비스 담당자인지 아닌지에 상관 없이 대응이 가능한 사람이라면 그 자리에서 할 수 있는 최선의 노력을 통해 문제 해결에 적극적으로 기여해야 합니다.
- 문제의 원인을 찾아 내려가는 것에만 집중해서는 안됩니다. 개발자라면 문제 발생 시 원인을 파내려가고 싶다는 걸 이해합니다. 그러나 비행 중 문제 발생 시 가장 먼저 할 것은 승객들이 안전하게 대피할 수 있도록 비행기를 잘 착륙시키는 것입니다.
- 스스로 알고 있는 지식으로 문제를 빠르게 해결할 수 있을지 판단해야 하며, 어려울 것 같은 경우 다른 사람에게 부탁해야 합니다.
[에스컬레이션과 상황 전파] 필요할 경우 적극적으로 도움을 요청해야 합니다.
- 장애가 발생한 사실을 뒤늦게 깨닫는 것보다는, 오탐이라도 장애 상황을 의심하고 다시 한 번 점검하는 것이 훨씬 더 좋습니다. 장애 인지를 했는데 이게 장애인지 아닌지, 어떻게 해야 할지 판단이 안 서는 경우에는 시간 장소 관계 없이 즉시 다른 사람들을 부르도록 합시다.
- 호출을 받는 사람은 이런 종류의 호출에 기분 나빠하거나 부담스러워하지 말고, 이런 호출이 있을 수 있다는 사실을 인지하고 문제를 같이 파악합니다.
- 같은 사람을 호출하는 상황이 반복된다면 해당 알람 관련 맥락을 다른 사람에게 잘 전파해주고 있는지를 점검해 보아야 합니다.
[장애 대응을 위한 환경 준비] 장애에 대응할 수 있도록 적절한 장비와 세팅을 최대한 유지합니다.
- 랩탑을 항상 휴대합니다. (사전에 입사자의 멘토가 랩탑 장비 신청 시 휴대성을 고려하여 신청하는 것을 권장합니다)
- 언제든 대응할 수 있도록 랩탑에도 평소 개발/운영 환경(Wireguard, SSH, AWS Console, kubectl, 간단한 스크립트 등)을 셋업하고, OS 버전업/기기 변경 등 다양한 변화에도 항상 잘 동작하게끔 준비하여야 합니다.
- Wi-Fi가 없는 환경에서도 대응할 수 있도록 사용하는 개인 폰에 테더링 환경(요금제 포함)을 구축하거나, 여의치 않은 경우 회사로부터 LTE 모뎀 / LTE 법인폰 등을 지급받아 준비합니다.
[장애 감지의 방법] 장애를 감지할 수 있는 알람 시스템을 구축하고 모두가 받을 수 있도록 항상 준비합니다.
- 장애 슬랙 채널의 알람은 티어에 맞게 Notification 설정을 All new messages 로 설정, 문제를 빠르게 인지할 수 있도록 합니다.
- 장애 문자, 전화 발신자는 Do not Disturb(방해 금지) 예외로 설정해둡니다.
- 적절한 티어링 체계를 갖추면 알람 체계를 잘 유지할 수 있습니다. 문서의 아래 항목에서 그러한 티어링 방안을 제안하고 있으니, 그에 맞춰서 알람 시스템을 정비하길 권장합니다.
[알람 건전성] 모든 알람은 약식으로라도 대응을 하여야 합니다.
- Feed 채널과 알람 채널의 목적은 다릅니다. 확인 결과 대응이 필요하지 않은 알람이었을 경우 알람 조건 수정, 티어 재배치 등을 진행합니다.
- 양치기 소년 이야기의 교훈을 인지해야합니다. 알람을 보고 2차적인 판단을 거쳐 대응하지 않는 케이스가 생기게 되면 이후 심각한 문제 발생 시에도 제대로 대응하지 못하는 경우가 있을 수 있으며, 새로운 사람이 맥락을 따라가기도 어렵게 됩니다.
- 알람에 대응하는 방식에는 여러가지가 있을 수 있습니다. 인지하였음을 스레드로 메시지를 남기거나, 관련한 이슈를 생성하거나, 알람 조건을 조정하고자 하는 논의를 시작하는 등 비교적 낮은 적극성의 액션부터 장애 선언을 하는 높은 적극성의 액션까지가 모두 포함됩니다.
[기록과 커뮤니케이션] 장애 대응 중 실행된 액션들은 객관적으로 공유되어야 합니다.
- 수행하는 조치가 멱등하지 않을 수 있으므로 시스템에 대한 변경 내역은 장애 대응에 참여하고 있는 사람들에게 반드시 공유되어야 하며, 채팅 메세지 혹은 장애 대응 문서에 판단 근거, 조치 시간과 함께 기록을 남아야 합니다.
- 장애 상황에서 조치 내용은 시스템에 대한 이해를 바탕으로 문제 해결을 위한 가설을 세우고, 이를 시험하기 위해 실행한 작업이 실제 안정화에 도움이 되는지 확인하는 과정을 거치기 때문에, 엔지니어로서의 역량을 빠르게 성장시킬 수 있는 기회이기도 합니다. 기록을 잘 남겨둘수록 장애 대응에 참여하지 않았던 다른 구성원들의 역량 강화에도 도움이 되며, 이는 우리가 더 견고한 팀이 되는 가장 효율적인 방법입니다.
- 장애 대응에 반드시 기술 직군만 개입하는 것이 아니므로, 유관 부서에 커뮤니케이션할 때에는 기술적 배경이 적은 사람들도 이해할 수 있도록 작성하는 것을 권장합니다.
[장애 회고의 중요성] 모든 인프라는 다양한 이유로 장애가 날 수 있지만, 같은 이유로 같은 장애를 겪는 것은 우리의 잘못입니다.
- 장애 원인과 조치 내용을 기록으로 남기고 동일한 유형의 장애를 예방할 수 있는 방법을 모색합니다.
- 되짚어볼 필요가 있는 장애라면 업무시간 중 시간을 잡아 포스트모템을 진행합니다. 포스트모템에서의 논의가 건설적일 수 있도록 사전에 논의할 내용은 미리 작성해두도록 합니다.
- 장애 회고 미팅의 참여자들은 비난하지 않는 포스트모템이 될 수 있도록 주의를 기울여야 합니다. 이를 위해서는 장애 대응 과정 중의 모든 조치들이 각자의 상황에서 최선을 다했음을 신뢰하여야 합니다. 만약 결과적으로 잘못된 의사결정 혹은 실수가 있었더라도, 그러한 결과로 이어지게 된 시스템적 원인에 대해 논의할 수 있어야 합니다. 어떠한 실패라도 시스템을 강화할 수 있는 기회로 이어질 수 있습니다.

#알람 티어링 권장 체계

알람을 분류할 때 최초 대응 시간(FRT, First Response Time: 문제 상황을 인지하고 파악하는 시작 시점) 을 기준으로 삼을 것을 권장합니다. 대응의 완료를 포함하는 시간이 아닌, 최초 인지 및 파악을 시작하기까지의 시간을 말합니다.

알람을 설정할 때 가급적 알람이 울린 채널만 보고 바로 대응 조치가 필요한지를 직관적으로 알 수 있도록 설정하는 것이 좋습니다.

아래 장애 유형에 부합하지 않는 알람이 있다면, 팀에서 FRT 기준에 맞게 자율적으로 판단하여 적절한 티어에 추가할 수 있습니다.

#[Tier 0] 언제든지 대응해야 하는 최우선순위 알람 (<~ FRT 15min)

티어 정의
- 고객이 체감 가능한 문제가 발생하거나, 또는 서비스와 연관된 내부 컴포넌트의 안정성에 위험이 발생하는 경우입니다. 진행 중인 대부분의 일상 업무보다 높은 우선순위를 가지고 최대한 빠르게 대응합니다.
장애 인지
- 시스템을 통한 문제별 주요 담당자에게 전화, 문자
- Tier 0 알람 채널으로의 메시지 수신
  만일 Tier 0수준의 장애에 대하여 위와 같은 시스템을 통한 선제적 인지를 하지 못하고 사람에 의한 인지나 우연에 기반한 파악을 하였다면, 모니터링 체계의 정비가 필요함을 의미합니다.
장애 유형
- 유저가 체감할 수 있는 이상 징후가 발생하는 경우
  - e.g., API failure rate N% 증가, Latency XXms 지연 등
- 시스템의 일부가 복구 불가능한 상황을 맞이하여 시스템 자체 안전성에 대한 위험이 예상되는 경우 (당장의 문제가 일어나지 않는 경우를 포함 e.g., HA 구성된 시스템의 일부 장애)

#[Tier 1] 최선의 속도로 대응해야 하는 차순위 알람 (FRT 평일 <~ 15m, 밤일 경우 다음날 오전까지인 약 12h)

티어 정의
- Tier 0과 같은 직접적인 영향은 감지하지 않았지만 기술적인 연관성을 통해 Tier 0으로 퍼질 수 있는 경우입니다. 업무 시간 중에는 Tier 0과 같은 수준의 경각심과 우선순위로 빠르게 대응하나, 늦은 밤에 일어날 경우 다음날 오전에 확인하는 것을 목표로 합니다.
장애 인지
- Tier 1 알람 채널으로의 메시지 수신
  Tier 1도 Tier 0과 마찬가지로, 시스템을 통한 선제적 인지를 하지 못하고 사람에 의한 인지나 우연에 기반한 파악을 하였다면 모니터링 체계의 정비가 필요합니다.
장애 유형
- Tier 0 문제로 발전할 가능성이 있는 기술적 문제
  - e.g., CPU Usage X% 이상 사용, DB latency API XXms 지연, 어플리케이션의 재시작 등
  - e.g., Atlantis(인프라 배포 툴), Vault(사용자 인증), 사내 운영툴 장애 등

#[Tier 2] 즉각적인 대응이 필요하지는 않지만 개입을 필요로 하는 알람 (FRT 평일 <~ 2~3h, 밤이나 주말일 경우 다음 업무일)

티어 정의
- 작업자의 개입이 필요하지만, 작업의 마감이 여유롭게 설정되었거나 또는 서비스 내외부적으로 직접적인 영향을 미치지 않아 시급성은 낮춰 대응해도 되는 경우입니다. 최대 1업무일 이내에 문제 해결계획을 수립하며, 실제 대응 작업을 더 늦게 진행할 경우 진행상황을 파악할 수 있도록 작업 티켓 등으로 기록을 남겨두는 것을 목표로 합니다.
장애 인지
- Tier 2 알람 채널으로의 메시지 수신
장애 유형
- 충분한 마감기한이 주어지는 작업
  - e.g., 인증서 만료, AWS instance retirement, AWS API deprecation
- 주기적으로 문제를 인지하여 대응이 필요한 작업
  - e.g., 정책적인 위반사항
- 비용에 대한 알람
  - e.g., 데이터독 사용량, cost enforcer

#효과적인 장애 대응 방법

💡 이 내용은 모든 것을 반드시 지켜야 한다기보다는 일종의 가이드라인입니다.

실제 장애 발생시 큰 틀 (장애 발생 공유 → 팀 구성 → 해결 → 종료 공유) 을 해치지 않는 선에서 융통성 있게 적용하시되, 포스트 모템을 진행할 때 어떤 것들이 어떤 이유로 가이드라인과 달라졌는지 설명해주세요.

아래의 예시를 따라 장애를 대응하면 보다 문제를 효과적, 효율적으로 대응할 수 있습니다.

이 내용은 가장 심각도가 높은 장애 상황을 가정하여 작성되었으므로 모든 장애 상황을 아래와 같이 대응하진 않아도 되고, 상황에 따라선 일부 항목을 생략할 수 있습니다.
위 티어링 체계 기준으로 Tier 0 및 1의 문제는 아래같이 대응하면 효과적입니다.

장애 최초 전파 및 대응 팀 구성
- 장애를 인지한 모든 인원은 즉시 팀 채널에 장애를 인지하였음을 알려야 합니다.
- 이후 장애 대응 팀을 구성합니다. 장애 대응 팀은 최소 2인 이상으로 구성함을 원칙으로 합니다.
- 장애 대응 팀은 지휘자와 기록가 역할 포함하도록 구성합니다.
- 각 역할은 특정 사람에게 명확하게 할당되어야 합니다.
  - ㅇㅇ님은 장애 기록 해주실 수 있을까요? 장애 문제는 제가 정리할게요
  - ㅁㅁ님은 서버 증설 준비해주세요
각 역할에 따라 해야 할 일은 다음과 같습니다.

A. 공통
- 장애 발생 원인 및 해결 방안을 탐색합니다.
- 의심이 되는 지점을 발견하면 다른 사람들에게 캡쳐나 링크 등의 근거자료와 함께 공유합니다.
- 장애 대응 과정에서 모든 의사 결정은 논의 하에 함께 수행합니다.
- 장애가 종료된 후, 포스트 모템 문서를 정리하여 공유합니다.
B. 지휘자
- 장애 상황을 주도적으로 파악하고, 대응 팀을 구성하여 역할을 분배합니다.
- 보통은 최초 인지자가 지휘자를 담당하는 경우가 많으며, 상황에 따라서 더 적절한 대상자가 있으면 다른 사람에게 지휘자를 인계할 수 있습니다.
- 추가 인원이 필요한 경우 다른 구성원들에게 적극적으로 연락하여 대응을 요청합니다.
  - 특히 문제 해결에 어려움을 겪을 경우, 혼자서 고민하지 말고 최대한 빨리 다른 사람들의 도움을 요청하도록 합시다.
  - 상황에 따라선 주 담당자 외에 외부의 인원이 문제를 함께 보는 것이 도움될 수 있습니다. (e.g., 인프라셀, 제품 팀 엔지니어, 동일 직군 다른 부서의 사람들, 그룹장 등)
- 대부분은 공동작업이 가능하나, 논의가 필요한 사항이 있다면 지휘자가 적극적으로 검토하고 결정합니다.
C. 기록가
- 원인, 고려한 해결 방안, 실제로 실행한 해결 방안 등 모든 것을 그 때 그 때 시간 순서로 기록합니다.
  - 각자가 의심하는 지점 및 장애 조치 내용은 각자가 직접 공유해주는 것이 원칙이며, 기록가는 그 내용들을 정리하고 수합하는 것이 주 목적입니다.
  - 장애 복구에 성공적인 시도만 기록하는 것보다는 실패했던 시도도 기록하는 것이 나중을 위한 자산이 됩니다.
- 장애 시점의 각종 모니터링 지표, 자료, 그래프, 로그 등을 보이는 대로 모두 모아 가능한 실시간으로 기록합니다. 실시간으로 기록이 정리되면 문제가 복잡해져 여러 사람의 개입이 필요한 경우 정보 전달 속도에 이점이 생깁니다.
- 장애 상황의 공유를 주로 담당합니다. 장애가 길어지는 경우에는 (30분 이상 소요되는 경우) 대응 현황, 예상 복구 시간을 공유합니다. 주기적으로 계속 업데이트합니다. 종료된 후에도 공유합니다.
장애 대응 채널 구성
- 지휘자는 Datadog Incident 기능을 사용하여 장애를 선언하고, 별도의 장애 대응 채널을 구성합니다. 장애를 선언하는 방법은 다음과 같습니다.
  - https://app.datadoghq.com/incidents/new 를 통해 UI에서 선언
  - 슬랙의 장애 인지 채널에서 /datadog incident 명령어를 사용하여 선언
- Incident를 선언하면 해당 incident 전용 채널이 생성됩니다. 장애 대응에 관여하는 모든 인원은 해당 채널에서 커뮤니케이션합니다.
- 화면공유를 위해 Slack huddle 또는 Google Meet 등을 개설해도 되지만, 주 커뮤니케이션은 슬랙 메세지를 이용해 추후 타임라인 분석이 용이하도록 잘 기록합니다.
장애 발생 공유
- 기록가가 장애 상황에 대해 인지한 즉시 슬랙을 통해 공유합니다. 만일 유관 부서와도 연관되는 내용이라면 메일 등 적절한 수단을 통해 유관부서로도 공유합니다. 공유 시에는 다음 내용이 들어가야 합니다.
  - 서비스 명
  - 발생 시간
  - 장애 규모와 범위
  - 장애 대응 채널
  - 장애 발생 메시지 예시:
    
    장애@ 쿠키런 킹덤 PVP 부분 장애
    
    조금 전 8월 11일 새벽 2시 35분경 부터 쿠키런 킹덤 PVP 서비스에 장애가 관측되고 있습니다. 약 25% 정도의 접속자가 영향을 받은 것으로 추정되고 있습니다. 용감한 쿠키, 명랑한 쿠키 2인이 #incident-XY 채널에서 대응 중이며, 추후 경과는 다시 공유드리겠습니다.
장애 원인 파악 및 해결
- 장애 대응은 기본적으로 원인 파악 → 해결 방안 탐색 → 해결 방안 시행 → 해결 여부 확인의 과정으로 진행됩니다.
- 앞서 명시한 장애 대응 원칙에 따라, 사용자들이 서비스 이용에 영향을 받는 상황이라면 근본 원인을 찾는 것보다 서비스를 가능한 빨리 복구하는 것을 우선시하여 대응해야 합니다.
  
  ⚠️ 어떠한 변경 작업 진행 시에는 반드시 작업 내용을 공유하여 함께 진행합니다.
  
  시스템에 따라 멱등성이 보장되지 않을 수도 있으므로 일관성을 위해 시스템 변경은 1인이 진행해야 합니다. 그러나, 이 1인이 독단적으로 시스템을 변경해서는 안됩니다.
  
  위급한 상황에서 개인이 단독으로 대응하는 것은 구성원 간 맥락의 전파를 저해할 뿐더러 긴급한 순간에서 빠르게 결정된 사항으로 더 나쁜 결과로 이어질 수 있습니다. 따라서 변경 작업 진행 시에는 커뮤니케이션을 통해 작업 내용을 같이 리뷰해나가며 진행하는 것이 우리의 방침입니다.
장애 종료 공유
- 장애 종료 메시지를 공유하는 것도 장애 대응의 일부입니다. 장애 대응이 끝나면 명확한 종료 선언을 하여 혼란을 방지합니다.
  - Root cause 분석이 끝나지 않았더라도, 일단 당장의 문제가 해결되면 장애 상황은 종료된 것입니다.
- 장애 상황이 종료되면 장애 상황 종료에 대해 슬랙을 통해 공유합니다. 공유 내용으로는 다음 항목을 포함하여 작성해야 합니다.
  - 장애 종료 시간
  - 장애 발생 (추정) 원인
  - 조치 내역 혹은 해결 방안
  - 포스트모템 미팅 일시
  - 장애 종료 메시지 예시:
    
    장애@ 쿠키런 킹덤 PVP 부분 장애
    
    2시 55분경 안정화되었습니다. PVP 서버 4대 중 1대에 이상이 생겨 해당 서버에 접속한 유저들에게 장애가 있었던 것으로 추정됩니다.
    
    대응 조치로 해당 서버를 서비스에서 제외하고 새 서버 1대를 추가하였습니다.
    
    서버에 왜 갑자기 이상이 생겼는지는 내일 중으로 추가 조사를 진행할 예정입니다.
    
    장애 포스트모템은 내일 오후 3시에 퓨어바닐라왕국 연회장 회의실에서 진행하겠습니다.
- 후속 액션을 위해 다양한 직군이 관여되어야 할 수 있으므로 장애 종료 공지를 할 때에는 가급적 프로그래머가 아닌 직군들도 이해할 수 있는 표현을 사용하고, 자세한 기술적인 내용이 궁금하면 포스트모템을 참고하도록 안내합니다.
- 장애 종료가 공유되면 지휘자가 Datadog incident status를 조정합니다.
  - 포스트모템 미팅이 예정되어 있을 경우: Active → Stable
  - 포스트모템 미팅이 예정되어 있지 않을 경우: Active → Resolved
포스트모템 준비
- 효율적인 포스트모템을 위해 논의가 필요한 내용, 대응 과정을 미리 갈무리 해둡니다.
  - 지휘자는 포스트모템 준비, root cause 분석, root cause 해결 등의 남은 작업을 특정 사람에게 명확하게 할당합니다.
- 포스트모템 템플릿을 참고하여 정보를 수집합니다.
- 포스트모템 문서 작성의 주 담당은 장애 대응 당시 지휘자였던 사람이 맡습니다.
  - 지휘자가 작성을 온전히 다 하는 것은 아니고, 다른 사람에게도 도움을 받을 수 있습니다.
  - 그러나 작성 진행 상황을 체크하고 잘 작성될 수 있도록 drive하는 것은 지휘자의 역할입니다.
  - 기록가의 기록을 잘 참고하고, 슬랙 히스토리와 대조하여 보충할 내용을 추가합니다.
- 당시 시스템의 상황을 잘 알 수 있도록 대시보드도 캡처해옵니다.
포스트모템 미팅
- 가까운 업무일에 포스트모템 미팅을 진행합니다. 진행 시에는 아래와 같은 항목들을 고민합니다.
  - 장애 대응 팀 뿐 아니라 관련된 구성원이 있다면 모두 소집합니다. 미팅에 초대받지 못하였더라도 관심있는 구성원들이 참여할 수 있도록 미팅 링크를 미팅 시작 시간에 공유합니다.
  - 장애 대응 과정에 대해 리뷰하고 놓친 것은 없는지 공유합니다.
  - 앞으로 같은 장애를 겪지 않도록 액션 아이템을 정리하고 계획을 수립하여 실행합니다. 근본적인 문제 파악에 대해서는 5 Whys 같은 좋은 방법들이 있으니 참고합니다.
- 미팅이 끝나면 포스트모템 문서 형태로 정리하여 공유합니다.
  
  ⚠️ 포스트모텀 미팅은 형식적인 자리여서는 안됩니다. 미팅이 끝나면 아래 질문에 답할 수 있도록 적극적으로 논의되어야 합니다.
  
  오늘 미팅 이후, 같은 문제가 안 생긴다 / 마주했을 때 잘 대처할 수 있다는 자신감이 드나요?

#포스트모템 문서 양식

#YYYY/MM/DD AAA로 인한 BBB 장애

(장애 대응 원칙과 방법 문서로의 링크)

[장애 대응의 목표] 장애 대응의 최우선 목표는 문제를 정상화하는 것입니다.

#Summary

해당 장애를 요약합니다.

#Impact

해당 장애로 발생한 영향을 기술합니다.

#Root Causes

해당 장애가 발생한 근본적 원인을 기술합니다.

#Trigger

해당 장애가 촉발된 직접적 원인을 기술합니다.

#Resolution

해당 장애를 어떻게 대응하고 해결 하였는지 기술합니다.

#Detection

해당 장애를 어떻게 감지 하였는지 기술합니다.

#Timeline

"[시간] 사건에 대한 기술"을 시간 순으로 기록합니다.

#Discussion

포스트모템 미팅을 진행하며 서로를 비난해서는 안됩니다.

포스트모템 미팅을 마치면 아래 질문에 답할 수 있어야 합니다.

같은 문제가 생기지 않는다 / 마주했을 때 잘 대처할 수 있다는 자신감이 드나요?

포스트모템 미팅에서 논의할 만한 주제들을 미리 기록해두고, 미팅 내용을 속기합니다.

#Lesson Learned

잘 된 일
- 이번 대응에서 잘 된 것을 기술합니다.
잘 안된 일
- 이번 대응에서 잘 되지 않은 것을 기술합니다.
운이 좋았던 일
- 이번 대응에서 운이 좋았던 것을 기술합니다.

#Action Items

해당 장애를 위해 앞으로 개선해야 할 것을 구체적으로 기술합니다.

💁 앞으로 같은 문제가 생기지 않는다 / 마주했을 때 잘 대처할 수 있다는 자신감이 드나요?

그래서 계정 연동 하면 뭐가 좋은데?

Tue, 21 Jan 2025 00:00:00 GMT

안녕하세요, 저는 데브시스터즈 기술본부 백엔드셀에서 소프트웨어 엔지니어로 일하고 있는 안정현입니다. 이 글에서는 DevPlay 계정에 대해 알아보고 이를 통해 얻을 수 있는 다양한 혜택을 알아봅니다.

#DevPlay 소개

DevPlay는 데브시스터즈의 글로벌 게임 서비스 플랫폼으로, 새로운 기기로 바꾸어도 기존에 플레이하던 게임 데이터 그대로 플레이할 수 있게 하거나, 데브시스터즈의 다양한 게임간 이벤트에 참여할 수 있습니다.

게임 진입 시 로그인 화면

DevPlay 계정 구조를 간단하게 나타내면 아래와 같습니다.

하나의 DevPlay 계정(Member)으로 여러 게임을 즐기고 있는 사용자는, 내부적으로 각 게임별 계정(Player)을 연결하여 저장하고 있습니다.

계정이 연동된 유저의 데이터 구조

#과거 로그인 기록을 통해 유저에게 편리함을 제공하는 방법

오랜만에 들어왔더니 어떤 계정으로 가입되어 있었는지 기억이 나지 않아요

DevPlay는 다양한 로그인 수단을 제공하고 있어서, Google, Apple 등 이미 가지고 있는 여러 로그인 수단 중 하나를 선택하여 계정 연동을 할 수 있습니다.

또한 게임에 접속할 때마다 매번 로그인해야 하거나 게임 도중에 인증수단이 만료되는 것은 사용자에게 좋지 않은 경험을 주기 때문에, DevPlay는 토큰을 일정 기간 동안(refresh token이 만료되기 전까지) 주기적으로 교체해 줘서 인증이 끊기지 않도록 도와줍니다.

신규 게임에 처음 접속했을 때, 이전에 사용했던 계정이 무엇이었는지 기억이 나지 않아요

위의 인증을 편하게 할 수 있도록 해주는 두 가지 기능의 영향인지는 모르겠지만 가끔 사용자분들이 자신의 계정을 기억하지 못하시는 경우도 있는데요, 플레이를 오랜 기간 쉬었던 사용자분들의 경우 더욱 그러합니다.

데브시스터즈에서 새로운 게임이 출시했을 때, 사용자분이 이전에 다른 게임에서 사용했던 DevPlay 계정이 무엇이었는지 기억하지 못하고 새로운 로그인 수단으로 DevPlay 계정을 새로 생성할 수 있습니다. 이는 궁극적으로 사용자의 불편으로 이어지기 때문에, DevPlay는 동일 디바이스의 다른 게임에서 DevPlay 로그인을 사용한 적이 있다면 디바이스의 고유 식별자를 통해 “이미 연동 가능한 DevPlay 계정이 있군요!" 라고 제안하며 이전의 로그인 수단으로 연동할 수 있도록 도와줍니다.

이는 한 게임에 대해 여러 계정을 사용하고 있는 사용자들에게도 좋은 경험을 제공합니다.

접속 이력이 있는 디바이스에서의 로그인 화면

#Guest 계정

회원가입을 진행하지 않고 게임을 진행하고 싶어요

DevPlay 계정을 이용하면 디바이스를 변경하는 상황에서도 게임 데이터를 안전하게 보호할 수 있는 장점이 있지만, 로그인 수단을 연동하는 과정 자체가 당장 플레이를 즐기고 싶은 사용자에게는 하나의 진입장벽이 될 수 있습니다. 이러한 경우 사용자는 Guest로 로그인 하여, DevPlay 연동 과정을 생략하고 계정을 생성하여 서비스를 이용할 수 있습니다.

Guest 계정의 경우에도 위에서 설명한 Auth-Member-Player의 구조를 가지지만, Guest 계정은 사용자를 기기 또는 앱의 생애주기에 맞춰서 구분하기 때문에 사용자가 핸드폰을 변경할 경우 게임 계정을 잃어버릴 수도 있습니다.

⚠️ DevPlay 연동을 하지 않은 채로 계정을 잃어버리더라도 계정을 찾을 수는 있습니다. 고객지원 페이지를 통해 계정을 복구받을 수 있지만, 그 때엔 결제내역 등을 통해 본인임을 증명해야 합니다.

게스트 유저의 데이터 구조

위와 같이 Guest 계정은 당장 플레이하기에 편리함을 제공하지만, DevPlay 연동을 하면 게임 데이터를 안전하게 보관할 수 있는 장점과 더불어 아래에서 설명할 크로스 게임 프로모션의 혜택을 받을 수 있게 됩니다.

#크로스 게임 프로모션

새로운 게임을 런칭했는데, 기존 게임들의 유저풀을 이용할 수 없나요?

서비스 런칭 후, 유저들에게 이를 알리는 방법은 굉장히 많습니다. 기존 라이브 서비스 게임을 통해서 홍보를 하는 방법도 그 중 하나인데, 이를 크로스 게임 프로모션(CGP)이라 부르고 있습니다.

CGP는 앱 마케팅 및 고객 유치를 위한 주요한 전략입니다. 고객이 새롭게 출시하는 게임에서 일정한 기준을 충족하는 경우, 연계된 기존 라이브 서비스 게임에 보상을 지급하는 방식으로 진행합니다. 이럴 경우 새롭게 출시하는 게임에 기존 게임의 고객을 유입시켜 런칭 초기 고객을 확보할 수 있는 효과를 노릴 수 있습니다.

아래는 기존에 진행했던 CGP 예시입니다.

각 게임의 크로스 게임 프로모션 예시

A게임에서 조건 달성 후 B게임에서 보상을 받기 위해서는 A게임의 Player와 B게임의 Player가 하나의 계정으로 묶여있어야 하는데, 이는 DevPlay 연동을 통해 가능합니다.

CGP 조건 달성 시 보상을 받는 플로우는 아래와 같습니다.

아래에서는 쉬운 설명을 위해, 쿠키런: 모험의 탑, 쿠키런: 킹덤 을 예시로 듭니다.

모험의 탑에서 스토리 모드 1-1 클리어 라는 CGP 조건을 달성하면,
DevPlay 서버에서 해당 DevPlay 계정의 킹덤 계정에 보상이 생성됩니다.
이후 유저는 킹덤에 다시 접속하여 보상을 획득합니다.

쿠키런: 모험의 탑 - 스토리 모드 1-1 클리어

계정 연동 상태

쿠키런: 킹덤 - CGP 보상 수령

모험의 탑과 킹덤 계정을 하나의 DevPlay 계정으로 연동하지 않은 상태라면, 상황은 조금 더 복잡해집니다. 당장은 CGP 조건을 달성 하더라도 보상을 받을 수 없는것이 당연하지만, 나중에 계정 연동을 했을 경우 그 즉시 보상을 받을 수 있도록 처리를 해줘야 합니다.

조건 달성을 먼저 한 후, 계정 연동을 하는 경우 보상을 받는 플로우는 아래와 같습니다.

모험의 탑에서 스토리 모드 1-1 클리어 라는 CGP 조건을 달성합니다.
아직 연동된 킹덤 계정이 없으므로, 모험의 탑 계정의 Member에 대해 지급되지 않은 킹덤 보상이 있음을 기록해둡니다.
이후 CGP 기간 내 해당 계정에 킹덤 계정이 생성되어 연동된다면, 그 때 지급하지 못한 킹덤 보상을 지급합니다.

#CGP를 통해 이득을 취하려는 시도와 해결방법

계정을 쉽게 초기화 할 수 있는 경우, 유저는 최초의 뽑기를 이론상 무한정 시도할 수 있습니다. 이것을 일본어로 리셋 마라톤, 줄여서 리세마라 라고 부르고 있고 한국에서도 리세마라 라고 부르는 편입니다. 데브시스터즈의 게임에서도 보상을 극대화 하기 위해 유저들이 리세마라를 하는 경우가 꽤 있습니다.

CGP에 대해서도 리세마라를 시도하는 유저가 있을 수 있습니다. 기본적으로 DevPlay 플랫폼 입장에서는 중복지급 방지를 위한 최소한의 방어 로직을 제외하고는 리세마라에 대한 제한을 두고 있지 않고, 각 게임사에 선택지를 주고 있습니다.

지난 CGP에서는 리세마라를 막기로 결정했고, 위의 설명과 동일하게 쿠키런: 킹덤 과 쿠키런: 모험의 탑 을 예시로 설명하겠습니다.

#모험의 탑 계정 리세마라 (조건 달성 게임)

조건을 달성하는 쪽인 모험의 탑 계정을 리세마라 하면서 하나의 킹덤 계정에 CGP 보상을 지급하려는 경우, DevPlay 서버에서 하나의 킹덤 계정에 중복 보상이 지급되지 않도록 처리를 하고 있습니다.

reward id의 구조를 통해 중복 지급을 막는 과정

만일 DevPlay 서버에서 이러한 처리를 하지 않는다면, 어떻게 해야할까요? 지난 CGP에선 별석탄이라는 CGP 전용 재화를 둠으로써 추가적인 방어 로직을 만들었습니다. 유저가 CGP 보상을 중복으로 받았어도 별석탄이라는 재화는 CGP 보상을 교환할 때에만 '1개일 경우' ~ '4개일 경우' 등 제한적으로 사용 가능하게 하였으므로, 유저가 일정한 수량을 초과하여 별석탄을 소지하고 있더라도 더 이상의 이득을 취할 수 없습니다.

쿠키런: 킹덤 - 별석탄 보상 획득

#킹덤 계정 리세마라 (보상 수령 게임)

반대로 보상을 받는 쪽인 킹덤 계정을 리세마라 하여 이미 미션을 완료한 모험의 탑 계정으로부터 중복된 CGP 보상을 얻어가려는 경우는 어떻게 처리할 수 있을까요?

모험의 탑 서버에서 DevPlay 서버에 미션 달성 API를 단 한번만 호출할 수 있도록 제한을 두어 보상을 중복지급하지 않게 만들 수 있습니다. CGP 조건 달성 및 보상 여부에 대해 서버가 매 번 중복을 체크하는 것은 부담이 될 수도 있지만, 잘 구현할 수만 있다면 가장 확실한 방법입니다. 지난 CGP에서는 모험의 탑 서버 개발자들이 이러한 방어 로직을 직접 구현하기도 했습니다.

이러한 작업들을 통해 유저들이 예상치 못한 방법으로 이득을 취하는 것을 방지하고, 게임의 공정성을 유지할 수 있습니다.

#마치며

지금까지 DevPlay 계정의 구조와, 계정 연동과 Guest 계정의 장단점, 크로스 게임 프로모션에 대해 알아보았습니다. 데브시스터즈의 게임을 이용해주시는 분들의 수 만큼 계정을 사용하는 방법이 다양하다고 느끼는데요, 이러한 다양한 방법들을 통해 사용자들에게 더 나은 경험을 제공할 수 있도록 노력하고 있습니다.

이 글을 통해 DevPlay 계정에 대한 궁금증이 어느정도 해소되었으면 좋겠습니다. 긴 글 읽어주셔서 감사합니다.

스칼라 컴파일 속도 빠르게 하기

Tue, 17 Dec 2024 00:00:00 GMT

안녕하세요. 스튜디오 킹덤에서 쿠키런: 킹덤의 서버 개발자로 재직하고 있는 전윤재입니다. 이번 글에서는 스칼라로 개발된 쿠키런: 킹덤 서버의 빌드 속도를 개선하기 위해 수행했던 과정과 결과를 소개해 드리려 합니다.

#도입부

스칼라는 정교한 타입 시스템, 매크로, implicit과 같은 강력한 기능들을 제공하여, 더 안전하고 생산적인 코드를 작성할 수 있도록 합니다. 이러한 기능들은 프로그램의 안정성을 높이고, 복잡한 로직을 간결하게 표현할 수 있게 해줍니다. 하지만 공짜 점심은 없듯이 프로젝트의 규모가 커질수록 컴파일러에 전가된 많은 작업이 오히려 컴파일 속도를 저하해 개발 생산성을 떨어뜨리는 결과를 초래할 수 있습니다.

쿠키런: 킹덤 서버는 국내에 몇 안 되는 스칼라 및 함수형 프로그래밍 패러다임을 적용한 서버로 Scala2로 작성되어 있으며 sbt로 빌드하고 있습니다. 시간이 흐르며 프로젝트의 규모가 커지다 보니 이에 따라 느려진 컴파일 속도로 인한 불편함을 저희도 체감하게 되었습니다.

컴파일 속도를 저하하는 요인은 다양합니다. 이 글에서는 typeclass 를 활용할 때 빌드 성능 저하를 피하는 방법, 그리고 build pipelining 을 적용하기 위한 과정과 그 과정에서 경험한 트러블슈팅을 담았습니다.

#컴파일러

본론으로 들어가기에 앞서 내용 이해를 돕기 위해 컴파일러에 대한 간단한 설명을 드리겠습니다. 컴파일은 여러 단계로 이루어지는데 이를 페이즈(phase)라고 합니다. 스칼라 컴파일러에서 수행되는 여러 페이즈는 네 가지 카테고리로 분류할 수 있습니다.

프론트엔드(frontend) - 소스코드로부터 초기 구조를 생성하는 과정
- parser - 소스 코드를 트리 형태로 변환 (타입 정보는 없음)
- typer - 트리에 타입 정보를 보충
- 그 외에 여러 페이즈 포함
피클러(pickler) - 프론트엔드 단계에서 생성된 트리를 직렬화하여 저장하는 단계
트랜스폼(transform) - 런타임에 적합한 로우레벨 형태로 변환 (패턴매치 변환, 타입 이레이저 등이 포함)
백엔드(backend) - 최종적으로 바이트 코드를 생성하는 단계

이 중 핵심적인 페이즈는 프론트엔드와 백엔드입니다. 프론트엔드 페이즈는 주로 코드를 분석하여 컴파일러가 이해할 수 있는 구조로 변환하는 데 집중하고, 백엔드 페이즈는 이러한 구조를 최종 실행 가능한 코드로 변환합니다.

#Typeclass

스칼라를 사용하다 보면 typeclass를 자주 접하게 됩니다. 이때 typeclass의 인스턴스를 어디에 정의하는지에 따라 컴파일 속도에 많은 영향이 있을 수 있습니다. 이는 컴파일러가 인스턴스를 검색할 때, 인스턴스의 정의된 위치에 따라 소요되는 시간이 다르기 때문입니다.

// Show.scala
trait Show[T] {
	def show(t: T): String
}

위와 같은 typeclass가 있다고 할 때 인스턴스를 정의하고 사용하는 방법은 대략 세 가지로 나눌 수 있습니다.

Companion 오브젝트에 정의

// Show.scala
object Show {
  implicit val intShow: Show[Int] = _.toString
}

// Foo.scala
// 컴패니언 오브젝트의 인스턴스는 기본적으로 스코프에 포함됨
println(implicitly[Show[Int]].show(3))

별도 trait에 정의하고, 이를 extends해서 스코프로 가져오기

// Show.scala
trait ShowInstances {
  implicit val intShow: Show[Int] = _.toString
}

// Foo.scala
object Foo extends ShowInstances {
  println(implicitly[Show[Int]].show(3))
}

별도 object에 정의하고, 이를 import해서 스코프로 가져오기

// Show.scala
object ShowInstances {
  implicit val intShow: Show[Int] = _.toString
}

// Foo.scala
import ShowInstances._

println(implicitly[Show[Int]].show(3))

세 가지 모두 유효한 방법이지만 빌드 속도에 유의미한 차이를 가져옵니다. 그러면 프로파일링 결과를 보면서 어떤 차이가 있는지 살펴보도록 하겠습니다.

아래 프로파일링 결과는 typeclass를 많이 사용하는 서브 프로젝트를 컴파일해서 얻은 결과를 약간 편집한 것입니다. 컴파일 시 -Vstatistics:typer 옵션을 활성화하면 아래와 같은 결과를 얻을 수 있습니다. 왼쪽 결과는 typeclass 인스턴스 정의 시 별도 object나 trait에 정의하는 2,3번 방법을 사용했을 때 결과입니다. 오른쪽 결과는 인스턴스를 companion object에 정의했을 때의 결과입니다. 프로파일링 결과를 보시면 각 페이즈별 소요된 시간 및 페이즈별 상세 스탯을 확인할 수 있습니다. 저희가 관심 있는 부분은 typeclass 검색에 사용된 시간이므로 typer 페이즈 내에서 time spent in implicits 부분을 확인하면 됩니다. -Vstatistiscs 의 더 자세한 사용법은 이 사이트에서 확인할 수 있습니다.

	                             baseline(import + extends)		      companion object

[info] #total compile time   : 1 spans, ()65561.041ms          : 1 spans, ()45911.915ms
[info]   parser              : 1 spans, ()115.791ms (0.2%)     : 1 spans, ()128.306ms (0.3%)
...
[info]   typer               : 1 spans, ()43962.134ms (67.1%)  : 1 spans, ()24221.797ms (52.8%)
...
[info]   pickler             : 1 spans, ()54.552ms (0.1%)      : 1 spans, ()54.096ms (0.1%)
...
[info]   patmat              : 1 spans, ()9903.798ms (15.1%)   : 1 spans, ()10066.074ms (21.9%)
[info]   uncurry             : 1 spans, ()2354.928ms (3.6%)    : 1 spans, ()2692.558ms (5.9%)
[info]   fields              : 1 spans, ()479.04               : 1 spans, ()450.513ms (1.0%)
...
[info]   jvm                 : 1 spans, ()1717.737ms (2.6%)    : 1 spans, ()1554.491ms (3.4%)
...

                                       baseline(import + extends)		             companion object
[info] time spent typechecking       : 1 spans, ()43962.129ms                  : 1 spans, ()24221.792ms
...
[info] time spent in implicits       : 55444 spans, ()34748.208ms (79.0%)      : 55464 spans, ()15114.999ms (62.4%)
[info]   successful in scope         : 21527 spans, ()20733.404ms (47.2%)      : 10435 spans, ()5559.827ms (23.0%)
[info]   failed in scope             : 33917 spans, ()15298.409ms (34.8%)      : 45029 spans, ()4790.923ms (19.8%)
[info]   successful of type          : 15548 spans, ()3092.438ms (7.0%)        : 26658 spans, ()4990.437ms (20.6%)
[info]   failed of type              : 18369 spans, ()198.034ms (0.5%)         : 18371 spans, ()400.566ms (1.7%)
[info]   assembling parts            : 5435 spans, ()120.933ms (0.3%)          : 12852 spans, ()194.988ms (0.8%)
[info]   matchesPT                   : 3675811 spans, ()3503.863ms (8.0%)      : 3678299 spans, ()3527.704ms (14.6%)
[info] time spent in macroExpand     : 7172 spans, ()9645.873ms (21.9%)        : 7174 spans, ()7884.628ms (32.6%)
...

baseline 대비 companion 오브젝트 사용 시 typer 페이즈에서 소요된 시간은 67.1% → 52.8%로 감소했습니다. 그리고 typer 페이즈 내에서 implicits 검색에 든 시간도 확인 가능한데 79% → 62.4%로 감소했습니다. 즉 typeclass 인스턴스 검색에 걸린 시간이 줄어든 것을 확인할 수 있습니다. 그리고 더 자세히 들여다볼 것은 time spent in implicits 의 세부 항목입니다. 여기서 ~~scope, ~~ of type으로 끝나는 항목이 있는데 각각 현재 스코프 내부에서 검색한 것인지, companion 오브젝트에서 검색한 것인지 나타냅니다. 변경 전 프로파일링 결과와 비교해 보면 successful in scope, failed in scope에서 소모된 시간은 큰 폭으로 감소했고, sucessful of type, failed of type에서 소모된 시간이 소폭 상승한 것을 확인할 수 있습니다. 이로써 스코프 내에서 인스턴스를 찾은 횟수보다 companion 오브젝트에서 검색한 횟수가 증가했고, 전체적으로 검색에 든 시간은 감소했다는 것을 알 수 있습니다. 아래 그래프를 참고 하시면 전후 차이점을 쉽게 파악하실 수 있습니다.

이런 시도를 하게 된 계기는 cats 라이브러리에서 typeclass 인스턴스 정의 위치를 리팩토링했던 경험을 공유한 글을 보고입니다(관련 PR). 해당 글에서 리팩토링 후 예상치 못하게 컴파일 속도가 향상된 경험을 공유하고 있고 이를 보고 저희 프로젝트에도 시도 해보게 되었습니다.

결과적으로 해당 서브 프로젝트의 컴파일 속도를 대략 65초에서 45초로 1.44배 빠르게 할 수 있었습니다.

앞서 typeclass 인스턴스 검색에 사용된 시간은 time spent in implicits 로 확인 가능하다고 말씀드렸습니다. 하지만 여기에는 한계점이 있습니다. 스칼라에선 typeclass를 네이티브 하게 지원하지 않기 때문입니다. 결국 implicit을 이용해서 typeclass 패턴을 구현하게 되는데 그러기 때문에 프로파일러 레벨에선 어떠한 implicit 검색이 typeclass 인스턴스를 검색한 것인지, 아니면 다른 용도인 것인지 구분할 수 없습니다. 따라서 implicit 검색에 걸린 시간중 typeclass 인스턴스 검색의 비중은 코드베이스에서 typeclass를 얼마나 사용 중인지를 통해 유추해야 합니다. 더 자세히 검증하고 싶다면 scala-profiling 을 이용해서 implicit search flamegraph를 확보하는 것입니다. Flamegraph를 확인하면 현재 typeclass 인스턴스 검색에 많은 시간이 소비되고 있는지 쉽게 파악이 가능합니다. 물론 이 역시 정량적으로 확인하기는 힘들지만, 프로파일링 결과만 보는 것보다 더 많은 단서를 얻을 수 있습니다. 아래는 flamegraph의 예시입니다.

칸 위에 마우스 포인터를 올리면 어떤 타입을 implicit 하게 검색했고 검색에 든 시간이 나옵니다. 따라서 전체적으로 확인해 보면 implicit 검색이 타입클래스 인스턴스를 많이 검색한 것인지 그 외의 경우인 것인지 파악이 가능합니다.

scala-profiling 의 자세한 사용법이 궁금하신 분을 위해 링크를 첨부했습니다. 추가로 scalac-profiling을 사용하여 Scala 빌드 서버인 bloop을 최적화한 사례를 소개한 글도 상당히 유익합니다. (링크)

#Build Pipelining

스칼라 컴파일러는 build pipelining을 제공합니다. 이 기능은 서브 프로젝트 간에 의존성이 있을 때 백엔드 단계까지 실행해야 나오는 결과물을 기다리는 게 아닌, 프론트엔드 단계까지 실행 후 나온 결과물을 이용하여 바로 다음 서브 프로젝트를 컴파일할 수 있도록 하는 기능입니다. 예를 들어 다음과 같은 의존성 그래프를 가진 프로젝트가 있다고 하겠습니다.

이 경우는 C를 컴파일해야 B를 컴파일 할 수 있는 상황입니다. 하지만 pipelining을 사용 시 C의 백엔드 단계까지 기다릴 필요가 없습니다. B를 컴파일 할 때 필요한 정보는 C의 타입 트리로 충분하며 .class 파일까지 필요로 하지 않습니다. Pipelining은 이 점을 이용하여 C의 typer 페이즈가 끝난 후 생성된 AST(Abstract Syntax Tree)를 이용하여 B를 컴파일합니다. 이때 typer에서 나온 트리를 직렬화해서 저장하는 단계를 pickler라고 합니다. 그리고 이때 생성된 결과물은 sbt에서 early output이라고 합니다.

sbt에서 build pipelining을 활성화하는 방법은 간단합니다.

ThisBuild / usePipelining := true

얼핏 보면 간단한 설정 하나만으로 큰 컴파일 속도 개선을 얻을 수 있을 거처럼 보입니다. 하지만 내부적으로는 빌드 과정이 복잡해지는 만큼 신경 써줘야 할 부분이 생기기 마련입니다. 따라서 저희 프로젝트에서 적용하면서 겪은 문제와 그 해결 방안을 공유해드리려 합니다.

#pipelining과 매크로

앞서 build pipelining은 pickler 페이즈까지만 실행 후 나온 결과물만을 이용하여 다음 의존성을 컴파일한다고 하였습니다. 여기서 한 가지 신경 써야 할 것은 매크로입니다. 스칼라는 프로그래머가 매크로를 정의하고 이를 호출하여 컴파일 타임에 코드를 생성할 수 있습니다. 매크로 코드는 컴파일 타임에 실행된다는 특성 때문에, 매크로 확장(macro expand)을 위해서는 실행할 수 있는 단계까지 컴파일된 스칼라 프로그램이 필요합니다. 이 특성으로 인해 매크로는 build pipelining을 방해하는 경우가 있습니다.

먼저 C에 어떤 매크로 코드가 정의되어 있고 B에서 이 매크로를 호출하는 상황을 가정 해보겠습니다. 이럴 경우 C의 pickler 페이즈에서 나온 결과물만 가지고 B를 컴파일 할 수 없습니다. 왜냐하면 B를 컴파일 할 때 매크로 확장을 해야 하기 때문입니다. 다른 말로 하면 B를 컴파일할 때 C에 정의된 매크로 코드를 실행할 수 있어야 하기 때문입니다. 그렇기 때문에 타입 검사 후 얻은 AST 트리만으로는 부족하며 이 경우는 pipelining이 불가능합니다.

반대의 경우도 있습니다. 매크로 확장 시 사용자가 정의한 코드에 따라 동작을 다르게 하고 싶은 상황을 예로 들어보겠습니다. 이 경우 매크로 코드가 실행될 때 사용자가 정의한 코드를 실행할 수 있어야 합니다. 따라서 이 경우 역시 typer 페이즈까지만 실행해서는 정보가 부족합니다.

예를 들어 chimney에서는 라이브러리 사용자가 직접 TransformedNamesComparison 을 정의하여 매크로가 transformer를 생성하는 동작을 제어 가능합니다. 이때 TransformedNamesComparison 의 타입 정보만 가지고는 매크로를 확장할 수 없기 때문에 pipelining이 불가능합니다.

chimney 예시 코드

// CustomTransformerConfiguration.scala
// chimney에서 변환하려는 메시지간 필드 이름 비교시 사용될 함수를 정의 가능
object CustomTransformerConfiguration {
  case object CustomNamesComparison extends TransformedNamesComparison {
    def namesMatch(fromName: String, toName: String): Boolean = ???
  }
}

// Transformers.scala
object Transformers {
  implicit val cfg = TransformerConfiguration.default.enableCustomSubtypeNameComparison(CustomTransformerConfiguration.CustomNamesComparison)
  implicit val aToB: Transformer[A, B] = Transformer.derive // 매크로 확장시 CustomNamesComparison 사용
}

위 사례들처럼 pipelining이 불가능한 의존성을 가지고 있을 때 사용하는 옵션이 exportPipelining 입니다. 해당 옵션을 false로 준 서브 프로젝트의 경우 early output을 산출하지 않습니다. 따라서 이 옵션으로, 순차적으로 컴파일해야 하는 부분을 조절할 수 있습니다.

매크로 정의에 의존하는 경우(전자의 경우) sbt가 자동으로 감지하고 순차적으로 컴파일합니다. 이는 암묵적으로 이루어집니다. 따라서 의식하지 못한 매크로 정의로 인해 pipelining을 활용하지 못하는 경우가 발생할 수 있어 주의가 필요합니다. 아래와 같이 sbt 디버그 로그를 활성화하면 매크로로 인해 early output 산출이 안 되는 경우를 확인할 수 있습니다.
// sbt의 로그레벨을 (set logLevel := Level.Debug) Debug로 해야 볼수 있는 메시지
// 그렇기 때문에 매크로 정의로 early output 산출에 실패해도 바로 알아차리기 힘들다
[projectA / compile] early output can't be made because of macros
또 다른 확인 방법은 end-to-end 컴파일 과정을 지켜보는 것입니다.
| => C / Compile / compileIncremental 30s
| => B / Compile / compileIncremental 20s
| => A / Compile / compileIncremental 10s
Build pipelining으로 인해 병렬적으로 컴파일되고 있다면, 컴파일 과정을 실시간으로 지켜보는 것만으로 바로 알 수 있습니다.

Build pipelining은 typer 페이즈에서 걸리는 시간이 적을수록 많은 이득을 누릴 수 있습니다. 따라서 프로젝트의 페이즈별 시간마다 pipelining의 효과는 다를 수 있습니다. 킹덤 서버의 경우 전체 프로젝트 컴파일 속도를 1.22배 빠르게 할 수 있었습니다.

#결론

지금까지 총 두 가지 컴파일 속도 개선 방법을 알아보았습니다. 첫 번째는 typeclass 인스턴스를 companion 오브젝트에 정의함으로써 인스턴스 검색 시간을 줄이는 방법입니다. 두 번째는 build pipelining을 통해 병렬성을 확보하는 것입니다. Pipelining 사용 시 신경 써야 할 점은 두 가지입니다. 첫 번째는 매크로 코드 또는 매크로 확장 시 사용되는 코드는 pipelining이 불가능하다는 것입니다. 따라서 이를 고려하여 서브 프로젝트를 분리하고 exportPipelining을 알맞게 설정하는 것이 중요합니다. 두 번째는 typer phase에서 시간을 많이 쓸수록 pipelining으로 얻을 수 있는 병렬성은 감소한다는 것입니다. 앞으로도 새로운 방법을 찾으면 공유해드리도록 하겠습니다. 많은 관심 부탁 드립니다.

그래서 QA가 왜 필요한데?

Tue, 26 Nov 2024 00:00:00 GMT

저에게는 게임 개발에 QA라는 직군이 있는 줄도 몰랐던 시절이 있었습니다. 사실 게임은 그냥 코드를 뚝딱하고 짜면 짠! 하고 만들어지는 것이라고 생각을 했다는 것이 더 정확할 겁니다. ‘개발자 = 똑쟁이’ 라서 저절로 양질의 제품이 만들어지겠지... 하는 바보 같은 생각이었죠. 우연한 기회로 QA를 업으로 삼고 나니, 테스트라는 것이 정말 소프트웨어 개발에 있어 상당히 중요하구나라는 것을 소름 돋을 정도로 느끼게 되었습니다. 생각보다 게임에는 고쳐야 할 것들이 엄청나게 많거든요.

우선 QA 활동이 게임 개발에 왜 필요한지는 아래 문장으로 간단하게 요약할 수 있을 것 같습니다.

“QA활동을 통해 게임 내 잠재위험과 문제점을 사전에 찾아내어, 제품의 품질을 보증하고 릴리즈 이후 발생하는 비용을 감소시킬 수 있다.”

위 문장이 전반적인 QA활동에 대해 적절히 잘 표현한 것 같습니다. 그렇지만 이렇게 정리하면 너무 식상합니다. 마치 면접장에서 많이 들을 수 있는 대답 같아 보이지 않나요?

그렇다면 좀 더 깊게 생각해봅시다. 만약 “그래서 너의 업무가 프로젝트 안에서 어떤 가치를 창출하는데?”라는 공격적인 질문을 갑자기 받게 되었다면, 빠르고 정확하게 저희의 가치를 상대방의 뇌리에 각인 시킬 수 있으신가요? 몇 년 전의 저였다면, 아마 흔들리는 동공과 떨고 있는 꽉 쥔 주먹만 보여주었을 것 같습니다.

게임 QA로 오랫동안 일하다 보니 가끔 시간이 날 때 마다 ‘나는 프로젝트에서 어떤 가치를 가질까?’하는 질문을 떠올립니다. 그래서 이번 포스팅은 그것에 대한 나름의 답을 같이 이야기하고자 합니다. 테크니컬한 부분은 없습니다만, 특별히 게임 QA를 직업으로 삼고 애정을 가진 많은 분들이 자부심을 가질 수 있도록 조금이나마 도움이 되었으면 합니다.

#1. 게임에서의 품질 기준

QA가 Quality Assurance 인 것은 모두 잘 알고 계실겁니다. 직역하면 역시나 ‘품질 보증’이구요. 어쨌든 단어풀이는 이해가 되는데, 그에 비해 예전부터 명확치 않았던 것이 있었습니다. 우리의 테스트 활동이 어떻게 품질을 ‘보증’하는 것일까요? 농축산품처럼 품질등급을 도장으로 쾅 찍는 것도 아니고, 공산품처럼 6시그마(σ) 품질관리를 활용해 불량률을 정확하게 평가할 수 있는 것도 아닌데 말이죠. 소프트웨어 제품이라는 두루뭉술한 대상에 대해서 우리는 어떻게 품질을 평가하고 있는걸까요?

이에 대한 정의는 사람에 따라 조금씩 다르겠지만, Software Testing Help 사이트에서 설명한 내용이 오늘 포스팅의 주제에 부합할 것 같습니다.

소프트웨어 품질보증(Software quality assurance, SQA)은 모든 소프트웨어 공학 프로세스, 방법 및 작업 결과물을 모니터링하여 정의된 표준을 준수하는지 확인하는 수단이자 관행이다.

출처 : https://www.softwaretestinghelp.com/software-quality-assurance/

여기서 말하는 QA는 “정의된 표준을 준수하였는가?”에 초점을 맞추고 있습니다. 그렇다면 우리는 먼저 게임 서비스에서 ‘정의된 표준’이 무엇인지 정리해야 할 것 같습니다.

ISTQB Foundation을 공부하셨다면 ‘요구사항’에 대한 내용을 기억하실 겁니다. 이는 사용자가 제품에 원하는 여러가지 기능/비기능적 사양을 뜻합니다. 이 요구사항이 제대로 충족되었는지 인수 테스트를 거친 다음 비로소 제품이 사용자에게 전달되게 됩니다. 즉, 사용자 요구사항이 명확히 정의되면서 표준(Standards)이 되고, 이 기준선을 통과한 상태를 우린 품질이 보증된 상태라고 볼 수 있을 것 같습니다.

그럼 라이브 서비스되는 게임에서 유저 요구사항은 무엇일까요? 이에 대해 ‘확실하게 정의할 수 없다’는 것이 제 의견입니다. 게임을 이용하는 유저들은 다양한 의견을 표출합니다. 서로 상반되어 충돌이 야기되는 의견도 심심치 않게 나오곤 하죠. 주류의견은 있을 수 있어도 통일된 명확한 요구조건은 나오기 힘든 환경이라고 볼 수 있습니다. 게다가 라이브 서비스라는 특징 때문에 이 요구사항들은 각종 조건에 따라 변경되거나 철회될 수도 있습니다. 이는 게임의 ‘재미’가 주관적인 측면이 강한 평가 요소이기도 하고, 또한 게임 서비스는 특정 기능이 필요한 사용자에게만 제공되는 것이 아닌 불특정 다수에게 배포되기 때문에 발생하는 필연적인 현상이라고 생각합니다.

결국 이런 상황에서 개발진은 선택의 기로에 놓이게 됩니다. 모든 의견은 소중하지만 우리의 시간은 유한하고 일정은 빡빡합니다. 따라서 먼저 VOC들의 우선순위를 설정하여 목록화 하고 분석 해야 할 필요성이 생깁니다. 어쩌면 개발 여건에 따라 약간의 타협이 필요할 수도 있습니다. 이렇게 되면 유저의 요구사항에는 ‘개발진의 의도’가 자연스럽게 반영됩니다. 요구사항을 명확하게 정의할 수 없기 때문에 하릴없이 자체적으로 가치를 부여하게 되기 때문이죠.

그래서 게임 개발진은 유저들과 소통해야 하는 의무를 동시에 지게 됩니다. 이런 의도가 어떤 방식으로 반영되었고 어떤 이점이 있는지, 어떤 문제점을 예상하는지, 앞으로의 계획은 어떤 지에 대한 상세한 소명이 있어야 한다는 뜻 입니다.

#2. QA활동의 가치

그럼 이제 QA활동이 제품에 어떤 기여를 하는가에 대한 내용을 고민해볼 차례입니다.

사실 제 결론은 간단합니다.

“게임 개발진과 유저 간의 원활한 소통을 위해 QA는 다양한 활동을 통하여 제품의 장애(Failure)를 최소화 하고, 소통의 질을 높이는데 기여한다.”

이것을 한번 풀어서 설명해보겠습니다.

유저분들이 보내주시는 피드백 중 가장 기분이 좋은 건 단연 게임이 재밌다는 의견일 겁니다. 또는 ‘유저를 배려한 UI’, ‘게임 그래픽이 너무 귀엽다’ 같은 의견도 입가에 미소를 짓게 합니다. 이런 긍정적인 피드백이 있는 반면 ‘밸런스가 엉망이다’, ‘보상을 얻기 너무 힘들다’ 같은 따끔한 질책의 피드백도 다수 받게 됩니다. 다만 이 두 상반된 피드백들의 공통점이 있다면 적어도 ‘제품(게임)’에 기반한 피드백이라는 것 입니다.

만약 여기에 ‘버그’가 눈치 없이 끼어든다면 어떻게 될까요? 아마도 저희는 제품기반 피드백을 받기 어렵게 될 확률이 높아지게 될 것입니다. 소프트웨어, 특히 게임에서 버그는 사용자 경험을 해치는 가장 명백한 원인입니다. 사소한 버그는 (어쩌면 웃고 넘어갈 수도 있겠지만) 팀의 전문성을 낮게 평가하게 되는 계기가 됩니다. 거기에 이용이 불가능하거나 밸런스를 무너트리는 심각한 버그는 유저의 게임 플레이 의욕을 현저히 저하시킵니다.

이처럼 버그는 경중에 관계없이 유저에게 부정적인 경험을 전달할 수 밖에 없습니다. 이런 상태에서 유저가 제품에 기반한 피드백을 온전히 전달할 수 있을까요? 아마도 버그에 대한 제보와 하소연, 분노를 표출하느라 정작 게임성은 눈에 들어오지도 않을 것 같습니다. 물론 버그가 많아도 제품에 대한 적절한 피드백을 주는 유저분들이 반드시 계실 것 입니다. 하지만 개발진은 이슈에 대한 관리없이, 요행에 가까운 의견을 보고 판단해서는 안됩니다.

앞서 설명했듯이 게임 서비스는 다수의 유저에게서 다양한 피드백을 전달받기 때문에, 확실한 품질 표준을 기대하기 힘든 환경입니다. 개발진은 유저와 서로 개발 위탁계약을 통해 제품을 제공하고 있는 것이 아니므로, 적어도 유저들에게 선보일 사양들에 대해 내부적으로 명확한 품질 기준을 설정해야 합니다. 여러가지 방법이 있겠지만 가장 쉬운 방법은 ‘기획서 기반 테스트 케이스’를 작성하는 것 입니다. 여튼 이렇게 설정된 기준을 넘었다면, 우선은 최소한의 품질이 보증된 상태라고 할 수 있을 것 같습니다.

품질이 보증된 상태의 제품은 개발진의 의도를 명확히 설명할 수 있는 훌륭한 기반이 됩니다. 상점에서 물건을 사는 상황을 생각해봅시다. 물건의 기능을 상점주인이 열심히 설명하고 있는데 들고 있는 물건을 보니 여기저기 흠집이 보이고, 심지어 손때까지 타서 꼬질한 상태라면, 그 물건이 기능상 아무리 좋아도 사고 싶은 마음이 사그라듭니다. 그러면 그 때부터는 말이 반대쪽 귀로 빠져나가면서 ‘그냥 빨리 집으로 가야겠다…’ 라고 되뇌이며 어색한 웃음과 함께 재빨리 자리를 피할겁니다.

위 예시처럼 제품이 말끔해야 개발진도 유저에게 명확한 개발의도를 전달할 수 있는 기회가 생깁니다. 버그 때문에 여기저기 너덜너덜한 게임을 보여준다면, 제 아무리 멋지고 재미있는 게임을 만들어도 유저들은 너덜너덜한 부분에 대해서만 토로하게 될 것 입니다.

더 나아가 라이브 서비스 게임은 ‘발전 가능성’이라는 특성을 품고 있습니다. 이 가능성은 양질의 피드백으로부터 활기를 부여받기 때문에, 이런 피드백이 없다면 게임은 방향을 잃고 누구도 만족시키지 못하는 쪽으로 흘러갈 가능성이 높아질 것이라 생각합니다. 결론적으로 QA란 ‘소통’의 질을 극대화한다는 가치를 창출하기 위해 범단계적인 종합 품질 보증 활동을 수행하는 것이라고 정리할 수 있겠습니다.

#3. 마치며

이처럼 QA활동이 단순 ‘버그 찾기’에서 쓰임을 다하는 것이 아닌, 개발진과 유저가 제품에 기반하여 건강한 피드백을 주고받을 수 있는 기틀이 되어줄 수 있다는 것을 나름대로 설명해보았습니다. 저는 그래서 QA가 개발 단계에서는 릴리즈 전 ‘마지막 수문장’이지만, 릴리즈 후에는 유저에게 선보이는 ‘첫인상’ 포지션을 지니게 된다는 점을 알리고 싶습니다. 그러므로 테스트 업무가 모두 종료되었을 때 손 털고 끝났다며 휴식하는 것도 좋지만, 버그로 인해 받을 수도 있었던 소중한 의견들을 받지 못하는 사태가 일어나지 않게끔 모니터링과 후속 대응에도 노력을 기울여야 할 것 입니다.

이렇게 되면 포스팅 초반 QA활동의 요약에서 언급한 ‘비용 감소’에 실질적으로 도움이 됩니다. 비용은 단순히 ‘돈’이 아닌 개발진의 시간과 노력을 포함한 개념입니다. 기획 방향성을 초반에 잘 갖출 수 있다면, 남은 리소스는 개발 품질에 더 투자할 수 있게됩니다. 이 때 유저들의 피드백이 좋은 참고자료로서 사용됩니다. 제품에 대한 진솔한 피드백이 많으면 많을수록 기획 방향성 설정에 이점이 되는 것은 당연한 이치가 아닐 수 없겠습니다. 결국 좋은 QA활동의 결과가 좋은 유저 피드백을 생산하고, 이것을 바탕으로 개발진은 좋은 기획을 창출하여 더 품질에 노력을 쏟을 수 있는 선순환 구조를 만들어 냅니다.

그러므로 QA로서 일하는 사람들은 버그를 찾는 것은 물론이거니와, 제품에 대한 깊은 관심을 가지고 유저관점에서 분석하려는 노력이 필요합니다. 이는 프리-프로덕션 단계부터 포스트-프로덕션까지 전단계에 걸쳐 유저에게 불편함을 줄 수 있는 모든 요소를 점검 해야함을 방증합니다.

물론 이런 활동은 쉽지 않습니다. 생각보다 게임은 크고, 방대하며, 복잡합니다. 고도로 발달한 AI가 아닌 이상 실수하며 놓치는 부분도 분명히 생기기 마련입니다. 그러므로 더더욱 유저들의 의견에 대해 귀 기울일 필요가 있습니다. 실수는 용서해도 방치와 기만은 용서가 되지 않을테니까요.

이 밖에도 세상에는 훌륭한 QA 엔지니어들이 더 좋은 가치를 만들어가고 있습니다. 그저 드리고 싶은 말씀은, QA의 활동이 프로젝트와 유저에게 적지 않은 가치를 창출하고 있다는 점, 그리고 유저 관점에서 생각하는 마음가짐을 가지자는 점입니다. 언제나 좋은 업데이트를 위해 고생하는 모든 QA 직군과 개발진에게 이 글을 바칩니다.

지금 매출 얼마인가요?

Mon, 18 Nov 2024 00:00:00 GMT

안녕하세요. 데브시스터즈 데이터플랫폼그룹의 박기범, 서혜인입니다.

여러분은 사업 지표를 얼마나 신속하고 정확하게 확인하고 싶으신가요? 아마 대부분 가능한 빠른 시점에 정확한 지표를 확인하고 싶어 하실 겁니다. 하지만, 데이터팀 입장에서는 사용자가 원하는 수준으로 정확하고 신속한 지표 서비스를 제공하기 위해 기술적으로 해결해야 하는 많은 문제들에 직면하게 됩니다. 이번 글에서는 데브시스터즈가 지난 수개월간 준실시간 지표 서비스를 도입하는 과정에서 마주하게 된 여러 기술적 도전 과제들과 해결 과정에 대해 소개해드리고자 합니다.

#게임 런칭 당일에 어떤 지표를 볼 수 있나요?

신규 게임이 출시되는 날, 모든 구성원의 관심은 게임 지표에 집중됩니다.

현재 게임을 접속한 유저 수가 어떻게 되나요?

지금까지 발생한 매출 중에 가장 구매가 많은 상품은 무엇인가요?

출시 직후 촌각을 다투는 상황에서는, 게임팀에서 유저의 접속 현황과 매출 성과에 따라 빠르게 의사결정을 내릴 수 있도록 “정확하고 신속하게” 지표를 확인할 수 있어야 합니다. 정확하지 않은 지표는 자칫하면 잘못된 의사결정을 초래할 수 있으며, 지표 조회가 지연되면 중요한 순간에 빠른 결정을 내리기 어려워지기 때문입니다.

이런 이유로 대부분의 데이터 조직은 짧은 지연 시간으로 주요 지표를 확인할 수 있는 준실시간(near real-time) 지표 서비스 도입을 고려하게 됩니다. 하지만, 왜 많은 회사들이 준실시간 지표 서비스 도입에 어려움을 겪고 있을까요?

각 회사마다 마주한 상황은 다르겠지만, 데브시스터즈에서 그동안 준실시간 지표 서비스를 도입하지 못한 데는 다양한 이유들이 있었습니다.

#기존 지표 환경

간소화한 데이터 파이프라인 구조

데브시스터즈에서는 2015년부터 Spark 과 Elastic Stack 기반의 빅데이터 플랫폼을 운영해 왔습니다.

2021년에는 Databricks를 도입하여 Lakehouse Architecture와 Medallion Architecture 기반의 데이터 환경을 구축했습니다. 이를 통해, DB와 로그 등 게임 서비스와 여러 플랫폼에서 발생하는 다양한 데이터를 가공 및 집계하여 지표 서비스에 활용 중이었습니다.

Databricks Data+AI World Tour 2023 Keynote: Databricks 도입 후의 Devsisters

해당 환경에서 지표를 서비스하는 방법은 크게 세 가지로 구성되어 있었습니다.

게임 서버에 연결된 세션 수를 기반으로 동시 접속자 (이하 '동접') 지표를 집계합니다.
시간별 배치로 운영계 DB 테이블을, 일별 배치로 로그를 ETL하여 Data Warehouse와 Data Mart에 적재합니다.
Elasticsearch 에 적재된 로그 원장을 기반으로 Kibana 에서 준실시간으로 갱신과 조회가 가능한 대시보드를 구성하여 활용합니다.

#기존 지표 환경의 한계

이처럼 기존 지표 환경에서도 게임 런칭 당일 제공할 수 있는 지표들이 존재하였지만, 사용자 요구를 완전히 충족시키기엔 한계가 있었습니다.

지금 국가별 동접은 볼 수는 없나요? iOS 동접은 어떤가요?

기존 동접 지표는 서버 입장에서의 세션 수만 수집했기 때문에 국가별, 스토어별 세부 동접 지표는 확인할 수 없었습니다. 특히 게임 런칭 초기에는 특정 국가의 반응, 스토어 및 OS별 접속 현황, 10분 단위의 접속자 추이를 빠르게 파악할 필요가 있었지만, 이를 확인할 수 있는 방법이 없어 불편했습니다. 반면 DB 기반의 시간별 지표에서는 여러 차원에서 지표를 조회할 수는 있었지만, 지표가 집계되기까지 한시간 가량을 기다려야 했기에 신속하게 의사결정을 내리기 어려웠습니다.

키바나 대시보드가 동작하지 않아요

Elastic Stack 기반으로 제공되는 키바나 준실시간 대시보드를 통해 여러 지표를 빠르게 확인할 수 있었지만, 게임 런칭과 같이 대규모 트래픽이 몰릴 때는 운영에 어려움이 있었습니다. 게임 CBT 시기에는 문제가 없었지만, 런칭 당일 초당 수십만 건의 로그를 처리할 수 있는 수준으로 Elastic Stack을 운영하기에는 높은 비용이 발생하게 되었습니다. 이로 인해, 게임 런칭 때는 키바나 기반의 대시보드를 제한적으로 활용할 수 밖에 없었습니다.

키바나 대시보드 지표가 시간별, 일별 지표와 달라요

제한적으로 Kibana 대시보드를 활용할 때에도 대시보드의 일부 지표가 실제와 다르게 집계되어 혼선이 발생하기도 했습니다. Elastic Stack에서는 로그 원장을 단순 집계하여 지표를 제공했기 때문에, 국가별 환율을 반영한 원화 환산 매출이나 게임 상품 이름과 같은 메타 정보를 대시보드에서 활용하기에 어려움이 있었습니다. Elasticsearch Ingest Pipelne 과 같은 기능을 활용해 이를 개선할 수는 있었으나 구현과 관리가 복잡했고, 기존 시간별/일별 지표는 SQL로 ETL되므로 동일한 로직을 새로 구현하는 것 역시 부담이 컸습니다.

#새로운 준실시간 지표 파이프라인

위와 같은 한계로 인해 게임 런칭 시 데이터 기반 의사결정이 지연되는 문제를 여러 차례 경험하면서, 이를 해결하기 위한 새로운 준실시간 지표 파이프라인을 개발하게 되었습니다.

이 목표를 달성하기 위해 다음과 같은 요구사항을 설정했습니다.

지표의 범위: 기존의 일별/시간별 지표로 대체할 수 없는 즉각 확인이 필요한 지표만 준실시간 지표 파이프라인에 포함하기로 했습니다. 그간의 사용자 요청 사항과 인터뷰를 기반으로, 국가, OS, 스토어 등 다양한 기준에서 유저 회원가입 수, 동접, 매출과 같이 핵심 지표를 확인할 수 있는 것을 목표로 설정했습니다.
클라이언트 로그를 적극적으로 활용: 설정된 지표를 수집하기 위해서는 서버에서 수집하지 않던 클라이언트의 다양한 맥락 데이터를 활용할 필요가 있었습니다. 기존 클라이언트 로그 SDK의 기능을 확장하여, 주기적으로 로그 수집 서버에 현재의 상태를 보내는 '하트비트 로그'를 추가 하였고, 클라이언트에서 보내주는 정보의 양을 늘렸습니다. 그리고 준실시간 지표 파이프라인에서 클라이언트 로그를 적극적으로 활용하기로 했습니다.
10분 이내의 지연 시간: 신속하게 지표를 확인해야 한다는 목적을 달성할 수 있도록, SLO(Service Level Objective) 를 10분으로 설정하였고, 게임 런칭과 같은 고부하 상황에서도 이 요구사항을 만족하는 것을 목표로 설정했습니다.
적절한 데이터 인프라 비용: 준실시간 지표는 주로 게임 출시 시 활용되지만, 정기 업데이트나 이슈 상황에서도 사용될 수 있어야 했습니다. 이를 위해, 파이프라인 운영 비용이 게임 인프라에 부담되지 않도록 설계 단계에서부터 기존 파이프라인의 비용을 참고하여 적정 비용 목표를 설정했습니다.
SQL 기반의 ETL: 매출을 비롯한 준실시간 지표는 정확하게 집계되어야 하는 동시에 여러 복잡한 비즈니스 로직이 반영되어야 했습니다. 예를 들어, 국가별 매출을 집계할 때는 통화 환율 정보를 반영해야 하며, 환불이나 쿠폰 사용 등 스토어별 결제 플로우에 맞는 복잡한 집계 공식이 반영되어야 했습니다. 이러한 비즈니스 로직을 지표 집계에 반영하기 위해서는 SWE 또는 데이터 엔지니어가 로직을 직접 개발하기보다는 DW 엔지니어 또는 데이터 분석가가 로직 개발에 참여할 수밖에 없었습니다. 또한, 이들의 개발 효율성을 높이기 위해서는 PySpark과 같은 범용적 프로그래밍 언어보다는 SQL로 집계 로직을 개발할 수 있어야 했습니다.

시간별/일별 매출 집계 쿼리의 일부분

실제 쿼리는 훨씬 복잡한 형태로 되어있어, SQL이 아닌 PySpark으로 관리하기에는 기대한 만큼의 생산성을 확보하기 어렵습니다.

#스펙

앞서 설명한 요구사항을 만족할 수 있도록 아래와 같이 구성된 스트리밍 기반의 ETL 파이프라인을 구성하여 준실시간 지표를 서비스하기로 했습니다.

스트리밍: Kafka로부터 로그를 실시간으로 읽을 수 있어야 합니다. 앞서 언급한 클라이언트 로그를 비롯해 데브시스터즈에서 발생한 다양한 로그들은 모두 Kafka로 인입되고 있으며, 로그를 스트리밍 처리하여 가공할 수 있어야 합니다.
전처리: Kafka로부터 읽어온 로그를 집계에 활용할 수 있는 형태로 가공하는 작업이 필요합니다.
집계: 가공된 데이터를 지표에 활용할 수 있도록 다양한 차원의 조합으로 지표를 집계해야 합니다.
시각화: 집계가 완료된 데이터를 사용자들이 조회할 수 있도록 대시보드로 서비스해야 합니다.

아래는 준실시간 지표 서비스의 흐름을 각 단계별로 추상화한 그림입니다. 그럼, 각 단계별로 구현해야 하는 상세한 스펙에 대해서 알아보겠습니다.

준실시간 지표 서비스의 추상화된 구조

#1. 스트리밍

스트리밍 단계에서 구현해야 하는 주요 스펙은 하트비트 로그의 Kafka topic을 분리하는 것이었습니다. 일반적인 로그는 다음날 자정 일 단위 배치를 통해 S3에 저장됩니다. 하지만, 준실시간 지표 서비스에 사용되는 하트비트 로그는 데이터 양이 많아 S3로 저장하는 데 드는 비용이 매우 많이 들지만 분석에 활용되는 빈도는 낮았습니다. 따라서 하트비트 로그를 별도의 Kafka topic으로 분리하여 기존 파이프라인에서 적재되지 않도록 Log Collection 모듈의 로직을 수정해야 했습니다.

#2. 전처리

전처리 단계에서는 매출 집계에 사용되는 로그를 추출하기 위한 작업이 필요했습니다. 매출 로그는, 서버와 클라이언트에서 발생하는 로그 각각에 집계에 필요한 정보가 저장되어 있기 때문에 서로 다른 두 개의 Kafka topic에 담긴 로그들 간의 JOIN 연산을 진행해야 했습니다.

얼핏 보면 데이터 파이프라인에서 쉽게 구현이 가능해 보이는 스펙이지만 스트리밍 데이터로부터 이를 구현할 때는 몇 가지 어려움들이 숨어있었습니다. 스트리밍에서는 Kafka topic마다 하나의 stream을 생성하는데, 서로 다른 두 Kafka topic의 로그를 조인하려면 stream-stream JOIN 방식이 필요합니다. 본래 JOIN은 데이터가 확정된 (INSERT가 완료된) 테이블들의 레코드를 조합하여 하나의 컬럼으로 표현할 때 사용됩니다. 따라서 계속해서 데이터가 인입되는 스트리밍에서는 각각의 데이터가 확정되는 (INSERT가 완료되는) 시점을 지정하여 JOIN의 기준점으로 사용해야 합니다. 이를 위해, 특정 시점을 기준으로 늦게 들어오는 데이터는 연산에서 DROP 할 수 있는 watermark 시간을 정해주어야 합니다.

# log 에 찍힌 timestamp 를 기준으로 watermark 를 1분으로 지정한다.
silver_df = (
    bronze_df.select(
        to_timestamp(col("timestamp")).alias("log_datetime")
    ).withWatermark("log_datetime", "1 minutes")
)
...

또한 각각의 stream 의 데이터 인입 완료 시점이 다를 수 있기 때문에 JOIN 할 다른 stream 의 데이터를 대기하는 시간을 지정해주어야 합니다.

revenue_df = (
    server_df.join(
        client_df,
        [
            server_df.log_datetime < client_df.log_datetime + expr("INTERVAL 5 MINUTES"),
            server_df.log_datetime + expr("INTERVAL 5 MINUTES") >= client_df.log_datetime,
            server_df.id == client_df.id,
        ],
        "leftOuter",
    )
    .select(
        # column from client_df,
        # column from server_df
    )
    ...
 )
 ...

이 설정값들은 최종적인 지연시간을 고려하여 적절하게 설정해야 합니다. 너무 큰 값으로 설정하면 데이터가 미처 들어오기 전에 JOIN이 이루어져 null 값으로 처리될 위험이 있고, 반대로 너무 작은 값으로 설정하면 지연시간이 커져 최종 지표 제공에 영향을 줄 수 있습니다. 따라서 적절한 균형을 찾아야 합니다.

또한, 이 과정에서 중요한 요소는 State (StateStore) 입니다. 파이프라인 내부에서는 JOIN이 이루어지기까지, 즉 watermark를 기준으로 데이터가 모두 들어왔다고 판단하기까지 데이터가 들어올 때마다 연산하여 중간값인 state를 저장하고 업데이트합니다. 데이터의 인입이 완료되면 state 업데이트도 완료되고 테이블에 레코드가 업데이트됩니다. 따라서 state 연산의 복잡도 그리고 state 저장 메모리를 스트리밍 구현 단계에서 염두에 두어야 합니다.

#3. 집계

집계 단계에서는, 위에서 언급한 복잡한 집계 로직을 효율적으로 운영하기 위한 요구사항들이 존재했습니다.

SQL을 활용할 수 있는가
내부 환율 테이블과 메타 테이블에 접근하여 집계 과정에서 활용할 수 있는가
하트비트 로그와 같이, 양이 매우 많은 경우에도 집계 시간이 지연되지 않게 클러스터를 효율적으로 관리하는 것이 가능한가

#4. 시각화

마지막 시각화 단계에서는, 준실시간 지표를 조회하기 위해 일반적인 BI 대시보드와 달리 아래 특징적인 요구사항들이 존재했습니다.

자동으로 대시보드 내의 데이터가 짧은 간격으로 갱신될 수 있는가
분 단위 또는 초 단위의 시계열 그래프를 표현하기에 적합한 대시보드인가

이처럼, 준실시간 파이프라인을 구축하기 위해서는 각 단계 별로 요구되는 스펙들이 존재하였고 이러한 요구사항들을 구현할 수 있는 플랫폼을 선택하기 위해 다양한 프레임워크들을 검토해 보았습니다.

#적절한 플랫폼 선택하기

#스트리밍 파이프라인

#시도 1. KSQL

위 1. 스트리밍, 2. 전처리, 3. 집계 단계를 수행하는 스트리밍 파이프라인의 플랫폼으로 검토한 첫 번째 프레임워크는 KSQL 이었습니다.

KSQL은 Kafka streams를 기반으로 한 프레임워크로, 기존 데이터 플랫폼에서 운영 중인 Kafka 클러스터를 그대로 사용할 수 있다는 장점이 있었습니다. 또한, SQL과 유사한 문법으로 DW 엔지니어/분석가의 러닝커브가 낮다는 점도 큰 장점이었습니다.

하지만 KSQL을 운영데이터에 적용해 보니 데이터 처리 성능 이슈로 인해 정확성 측면에서 문제가 발생했습니다. KSQL에서는 별도의 Kafka topic을 생성해 aggregation, join에서 발생하는 state를 저장합니다. 이때 Kafka message의 key는 group by에 포함된 column 들로 지정되며 사용자가 임의로 변경할 수 없고, 이를 기준으로 partition을 나누게 됩니다.

데브시스터즈의 게임들은 한국 사용자 비율이 매우 높기 때문에, 국가별 지표를 계산하는 과정에서 (group by country_code) 파티션이 편향되는 문제가 발생했습니다. 개발 환경에서는 데이터의 양이 적어 문제가 되지 않았지만 운영데이터는 양이 많아 파티션의 편향이 데이터 처리 속도에 큰 영향을 주었습니다. 특정 파티션에서 많은 데이터가 처리되며 Lag이 커졌고, 결국 집계되는 시점에 이미 KSQL 에 들어온 데이터가 누락되어 지표에 큰 오차가 발생했습니다. 이로 인해, KSQL은 후보에서 제외되었습니다.

KSQL 적용 후 KSQL consumer 의 offset lag

파티션이 편향되어, 하나의 파티션의 LogSize와 Lag가 지나치게 커졌던 상태

#시도 2. Databricks의 Delta Live Table (이하 DLT)

Databricks DLT 서비스로 구축한 스트리밍 파이프라인 (Medallion Architecture 활용)

다음으로 살펴본 것은, Databricks의 DLT 서비스였습니다. DLT 서비스는 Databricks에서 제공하는 스트리밍 프레임워크로, 스트리밍 및 배치 ETL 방식을 간편하게 처리할 수 있는 기능을 제공합니다.

기본적으로 DLT는 Spark Streaming을 기반으로 구현되며, Python뿐만 아니라 SQL 언어도 지원합니다.

이로 인해, SQL 개발자가 손쉽게 파이프라인에 집계 지표(Gold 영역)를 추가할 수 있다는 점이 큰 장점이었습니다. 또한, Web UI를 통해 테이블 간 구조를 시각적으로 쉽게 확인할 수 있고, 실행로그 및 실행시간 등을 한 곳에서 볼 수 있어 파이프라인 운영 측면에서 매우 유용했습니다. 스트리밍 파이프라인을 UI를 통해 간편하게 생성할 수 있고 Restart 버튼을 통해 재실행할 수 있어 유지보수 관점에서도 간편한 점이 많았습니다.

하지만 PoC 과정에서, DLT는 저희가 요구한 일부 조건을 충족하는 데 어려운 부분이 있었습니다.

지표 집계(Gold 영역)에서, 많은 양의 하트비트 로그와 복잡한 매출 집계 쿼리를 처리하는 과정에서 state 연산으로 인한 부하가 발생했고, 이로 인해 파이프라인의 전반적인 지연이 초래되었습니다. 이 문제로 인해 stream 데이터를 처리하는 Silver 영역과 지표를 집계하는 Gold 영역의 파이프라인을 별도로 분리해야 할 필요성이 제기되었습니다.

하지만, DLT 플랫폼에서는 각 파이프라인별에 개별 클러스터가 할당되며, 다른 작업에서 해당 클러스터를 공유해서 사용하는 것이 불가능했습니다. 파이프라인을 분리하게 되면, Silver 영역과 Gold 영역 각각의 파이프라인에서 발생하는 클러스터 비용의 총합이 파이프라인을 운영하는 데 배정된 목표 금액 치를 넘어서는 문제가 발생했습니다. 이에 따라 조금 더 저렴하게 운영할 수 있는 방법을 찾아 나서게 되었습니다.

#시도 3. Spark Streaming

마지막으로 검토한 방식은 DLT 서비스를 사용하지 않고 Spark Streaming을 직접 운영하는 것이었습니다.

해당 방식에서는 DLT와 달리 managed 되어 제공되는 뷰가 없기 때문에 Spark 설정, 클러스터 관리, 그리고 모니터링 방법 등을 작업자가 모두 직접 구축해야 했습니다.

하지만 Spark Streaming을 직접 관리하면서 얻을 수 있는 장점도 있었습니다. 가장 큰 장점은, 단일 Spark 클러스터를 stream 데이터를 처리하는 Silver 영역과 지표를 집계하는 Gold 영역의 파이프라인에서 공유하는 것이 가능해졌고 해당 클러스터를 파이프라인 내의 별도의 Spark 작업에서도 사용하는 것이 가능해졌습니다. 이를 통해, 비용 목표 금액 치를 충족하는 동시에 지표 서비스 운영에 필요한 다양한 작업들을 효율적으로 운영하는 것이 가능해졌습니다.

이러한 장점들을 고려하여, 저희는 Spark Streaming을 직접 운영하는 방식을 스트리밍 파이프라인의 플랫폼으로 최종적으로 선택하게 되었습니다.

#대시보드

대시보드의 경우, 기존 데이터 플랫폼에서도 활용 중인 Tableau, Quicksight 등 다양한 선택지가 있었지만, 위에서 언급한 4. 시각화 단계에 요구되는 두 가지 요건을 충족하면서 사내 구성원들에게 친숙한 환경인 Kibana를 선택하게 되었습니다.

1.자동으로 대시보드 내의 데이터가 짧은 간격으로 갱신될 수 있는가

2.분 단위 또는 초 단위의 시계열 그래프를 표현하기에 적합한 대시보드인가

Kibana 에서 제공하는 대시보드의 경우, Auto Refresh 기능을 통해 대시보드에서 조회하는 데이터를 원하는 간격으로 갱신할 수 있습니다. 또한, 그래프상의 timeseries 축을 자유롭게 조정할 수 있기에 위 두 가지 요건을 모두 충족할 수 있었습니다.

윗글에서는 ELK 스택으로 준실시간 지표 서비스를 구현하는 데 어려움이 있었다고 언급되어 있어, 신규 플랫폼에서 Kibana 대시보드의 역할에서 어떤 점이 달라지는 것인지 궁금한 분들도 계실 텐데요. 기존 데이터 플랫폼 구조에서는 Kibana에서 많은 양의 로그를 집계하는 연산을 사용하게 되면 클러스터에 큰 부하가 발생해 Elasticsearch 검색 기능과 같은 다른 서비스에도 문제를 유발하였습니다. 또한, 집계에 필요한 환율 테이블과 다른 메타 테이블에 대한 접근도 불가능하여 정확한 지표 집계에 어려움이 있었습니다.

하지만, Spark Streaming 기반의 신규 플랫폼에서는 집계 파이프라인에서 이미 집계가 완료된 데이터(Gold)를 Kibana 대시보드에서 조회하게 되면서 복잡한 연산 과정 없이 지표를 조회할 수 있게 되었습니다. 이로 인해 정확한 지표 집계와 부하 문제 해결이 동시에 가능해졌습니다. 이러한 개선된 구조는 다음 파트에서 자세히 다룰 예정입니다.

#최종 구조

준실시간 지표 서비스를 위한 최종 데이터 파이프라인

해당 파이프라인은 준실시간 지표 서비스에 요구되는 조건과 스펙들을 모두 충족하기 위해 구성된 최종 아키텍쳐입니다. 이 아키텍쳐는 데브시스터즈에서 운영 중인 게임 및 플랫폼에서 발생하는 로그 데이터가 준실시간 수준의 짧은 레이턴시 안에 사용자들에게 지표로 조회되기까지의 과정을 포함하고 있습니다. 그럼, 각 영역들의 역할과 구현 방식에 관해서 확인해 보겠습니다.

Spark Streaming을 통한 데이터 전처리 파이프라인

(Spark Streaming) Kafka topic에 저장된 원본 로그는 Spark Streaming에서 전처리 과정을 거치게 됩니다. topic으로부터 읽어오는 원본 로그는 위에서 언급했듯이 양은 많지만, 활용 빈도는 낮아 Bronze Layer 테이블로 적재하지 않았습니다.

(Silver Layer) 원본 로그들은 타입 지정과 같은 기본적인 전처리와 함께 앞서 언급된 서로 다른 stream 로그 간의 JOIN 작업이 이루어져 Delta Table 형태로 저장되게 됩니다.

데이터 집계 & Elasticsearch 데이터 전송 파이프라인

(Gold Layer) Spark Streaming에서 Delta Lake 형태의 테이블로 소스데이터가 저장되었기 때문에 데이터 집계 과정은 일반적인 집계 파이프라인과 유사한 구조로 구성할 수 있었습니다. 이 과정에서 Spark Streaming의 큰 장점인 단일 클러스터 공유를 통해 집계 작업을 효율적으로 운영할 수 있었습니다. 배치 작업의 경우, 기존에도 팀 내에서 활발하게 사용하고 있는 Airflow를 사용하여 2분 간격으로 Micro batch 방식으로 실행되도록 설정했습니다.

앞서 살펴보았듯이, 지표 집계를 위해서는 복잡한 집계 로직 구현과 환율 테이블을 사용하는 등 SQL 개발자가 자유롭게 개발이 가능한 환경이 필요했는데요, 현재의 환경, Delta Lake 형태로 저장된 로그 데이터를 Databricks SQL로 집계하고 Airflow 배치를 통해 실행하는 환경은 SQL 개발자에게 매우 친숙한 환경이었습니다. (실제로도 기존 데이터 플랫폼에서 사용 중인 집계 쿼리를 재활용하는 것이 가능했습니다.) 이를 통해, 5% 이내의, 준실시간 지표로써는 상당히 낮은 오차율의 지표를 집계하는 것이 가능해졌고 새로운 지표가 추가되거나 로직 수정이 필요한 경우에도 SQL에 익숙한 DW 엔지니어 또는 데이터 분석가가 아주 쉽게 코드를 수정할 수 있는 환경이 갖춰지게 되었습니다.

준실시간 집계 SQL 쿼리

기존 시간별/일별 집계 쿼리에서 사용하는 SQL 코드에서 1. 소스 테이블과 2. 집계 시간 단위만을 변경하여 재활용할 수 있습니다.

(Send Metric Task) 마지막 작업은, 집계된 데이터를 Kibana 대시보드에서 조회하기 위해 Elasticsearch로 데이터를 전송하는 작업입니다. 해당 작업에서도 마찬가지로 Spark Streaming에서 사용한 클러스터를 사용하여 비용 효율화를 달성할 수 있었습니다. 각각의 Gold 지표 테이블에서 최근 업데이트된 레코드들을 Elasticsearch로 보내는 spark job을 병렬적으로 제출하여 신규 레코드가 최대한 빠르게 Kibana 에서 조회될 수 있도록 구현했습니다.

def send_to_es(table_name):
	# 최근 20분 내에 업데이트된 레코드를 ES로 보내는 작업
	df = spark.read(f"{table_name}").where("updated_at" >= current_timestamp() - expr("INTERVAL 20 MINUTE"))
	(
      df.write.format("org.elasticsearch.spark.sql")
      .option("es.nodes.wan.only", True)
      .option("es.net.ssl", True)
      .option("es.nodes", "{ES_HOST}")
      .option("es.net.http.auth.user", "{ES_ID}")
      .option("es.net.http.auth.pass", "{ES_PASSWORD}")
      .option("es.mapping.id", "document_id")
      .mode("append")
      .save("{ES_INDEX}")
	)

# 쓰레드 풀을 이용한 병렬 작업
with ThreadPoolExecutor(max_workers=thread_pool_size) as executor:
	# Spark 작업 제출
  futures = {}
	for table_name in gold_table_list:
		futures[executor.submit(send_to_es, df, table_name)] = table_name
	
	for future in as_completed(futures):
      table_name = futures[future]
      try:
          future.result()
          print(f"Finish: {table_name} send to ES")
      except Exception as e:
          print(f"Failed: {table_name} send to ES\n{e}")

이처럼, 집계가 완료된 메트릭을 Kibana 대시보드에서 조회하게 되면서 기존 데이터 플랫폼의 ELK 스택에서 발생했던 문제들을 모두 해결하고 Kibana 대시보드의 장점만을 활용할 수 있게 되었습니다.

#준실시간 지표 서비스를 도입하고 일어난 일

오랜 준비 과정 끝에, 마침내 준실시간 지표 서비스는 지난 2024년 6월 쿠키런: 모험의 탑이 출시되는 날 구성원들에게 처음으로 공개되었습니다.

서비스에 대한 관심은 가히 폭발적이었으며, 런칭 당일 준실시간 대시보드에 접속한 사내 구성원의 비율은 무려 30%에 육박했습니다. (접속 권한이 없는 사용자들을 고려한다면, 대략 3명 중 2명의 구성원이 준실시간 대시보드에 접속한 셈입니다.)

준실시간 대시보드 지표는 게임팀의 마케팅 캠페인 전략 수립, 앱 푸시 송출 등 비즈니스 성과에 직접적으로 기여할 수 있는 의사결정들에 활용될 수 있었고, 다양한 분들이 지표 대시보드에 대해 긍정적 피드백을 보내주셨습니다.

쿠키런: 모험의 탑은 앱 출시 일주일 만에 200만 다운로드 달성 및 누적 매출 100억 원 돌파라는 놀라운 성과를 달성하게 되었는데, 준실시간 대시보드를 통해 이 성과를 만드는 데에 간접적으로 기여할 수 있게 되어 뿌듯했습니다.

사무실 모니터에 띄워진 준실시간 지표 대시보드

#데이터 임팩트를 함께 만들어갈 인재를 찾고 있습니다.

지표 서비스가 사용자들에게 이렇게까지 큰 관심을 받고 비즈니스 성과에 직접적으로 기여할 수 있는 경험은 매우 특별하고 드문 일이라 생각됩니다.

데브시스터즈 데이터플랫폼 그룹에서는 쿠키런: 킹덤, 쿠키런: 모험의 탑과 같이 운영 중인 게임은 물론, 런칭을 앞둔 다양한 게임 서비스에도 고도화된 데이터 플랫폼과 지표 서비스를 제공하기 위한 다양한 업무를 수행하고 있습니다.

데이터를 통해 비즈니스 성과를 만들어 나가는, 데이터 임팩트를 만드는 경험을 하고 싶으신 분들께서는 아래 채용 공고를 꼭 확인하셔서 저희의 여정에 함께할 수 있기를 기다리겠습니다.

감사합니다.

『스칼라로 배우는 함수형 프로그래밍』 책을 읽어봅시다: 1편 - 순수 함수와 참조 투명성

Fri, 01 Nov 2024 00:00:00 GMT

안녕하세요? 저는 스튜디오킹덤에서 쿠키런: 킹덤 게임 서버 개발을 담당하고 있는 이현수입니다.

쿠키런: 킹덤 서버는 스칼라와 함수형 프로그래밍을 활용하고 있으며, 이는 국내에서 정말 보기 드문 개발 환경입니다. 스칼라를 좋아하는 저는 이러한 독특한 환경에 흥미를 느껴 팀에 합류하게 되었고, 지금은 스칼라와 함수형 프로그래밍이라는 좋은 연장을 활용해 만족스럽게 기능을 개발하고 있습니다.

사실 지난 10년 동안 개인적으로 스칼라를 공부해왔지만 그동안 스칼라를 사용할 업무 기회가 거의 없었는데, 이렇게 킹덤 서버팀에 합류하게 된 것은 저의 개발자 인생 중에서 특별하고 중요한 전환점이 되었습니다. 취미로 하던 스칼라 학습자에서 이제 프로페셔널 스칼라 개발자가 되었으니, 앞으로는 실무 경험을 바탕으로 스칼라와 함수형 프로그래밍의 저변을 넓히는 데 공헌하겠다는 마음을 먹었습니다. 그래서 그 일환으로 지금부터 기술 블로그에 스칼라와 함수형 프로그래밍에 관한 글을 연재하고자 합니다.

#『스칼라로 배우는 함수형 프로그래밍』 책 소개

스칼라와 함수형 프로그래밍은 워낙 방대한 주제라 어디서부터 글을 시작해야 할지 고민이 되었습니다. 그러다 문득, 이미 출간된 좋은 책을 하나 참고하여 실무 경험을 더해 소개하면 좋겠다는 생각이 들었습니다.

출처: 『스칼라로 배우는 함수형 프로그래밍』 (제이펍, 2015)

현재 절판 상태이지만, 원서는 여기에서 구매할 수 있습니다.

이 책은 강렬한 표지 색깔 덕분에 빨간책(The Red Book)이라고도 불리며, 스칼라와 함수형 프로그래밍이라는 주제를 깊이 있게 다루는 유명한 책입니다. 저도 처음에는 충분한 배경 지식 없이 이 책을 읽으려고 시도했는데, 당시에 책의 내용을 이해하는 데에는 제법 어려움이 있었습니다. 다행히 그동안 스칼라와 함수형 프로그래밍을 다양한 경로로 익히고, 지금에서는 실무에서 매일 사용하다 보니 비로소 이 책의 내용을 제대로 이해하며 읽을 수 있게 되었습니다. 초반에 이 책을 읽으면서 겪었던 어려움이 기억나기에, 이 블로그 시리즈를 통해 처음 읽는 분들께 조금이나마 도움이 되었으면 합니다.

그래서 이번 블로그 시리즈의 제목을 『스칼라로 배우는 함수형 프로그래밍』 책을 읽어봅시다 로 정했습니다. 저와 함께 책을 읽으며 스칼라와 함수형 프로그래밍을 더 깊이 이해해보는 시간이 되길 바랍니다.

#당부의 말씀

책에 이미 나온 내용을 굳이 옮겨쓰고 하나하나 설명하지는 않을 생각입니다. 글의 방향은 중요한 핵심 포인트만 간단히 요약하고, 제가 경험한 실무적인 팁을 조금 가미한 형태가 될 것 같습니다. 제목과 같이 책을 함께 읽어보시는 것을 추천드립니다.

#함수형 프로그래밍이란 무엇인가?

#주요 키워드

계산 vs. 액션(computation vs. action)

순수 함수(pure function)

부수 효과(side effect)

참조 투명성(referential transparency), 치환 모형(substitution model)

이 책의 1장을 읽어보셨다면, 함수형 프로그래밍의 기본 개념을 어느 정도 이해하실 수 있을 겁니다.

간단한 예제를 통해 함수형 프로그래밍이 어떤 느낌인지 간단히 살펴보겠습니다.

먼저 순수 함수라는 개념에 대해서 알아볼 건데, 다음과 같이 순수하지 않은 함수에서 순수 함수를 추출해내는 코드 리팩터링 과정의 예제를 살펴봅시다.

다음은 정수 n을 입력으로 받아 그 제곱 값을 계산하고, 문자열 템플릿을 적용하여 결과를 표준출력으로 출력하는 코드입니다. 여기서는 계산과 액션(콘솔 출력)이 혼합된 형태입니다.

def printSquare(n: Int): Unit = {
  val square = n * n
  println(s"The square of $n is $square")
}

이 코드에서 n * n 부분을 별도의 calculateSquare() 함수로 추출해, 다음과 같이 리팩터링할 수 있습니다.

def calculateSquare(n: Int): Int = n * n

def printSquare(n: Int): Unit = {
  val square = calculateSquare(n)
  println(s"The square of $n is $square")
}

이 과정을 조금 더 발전시켜, 문자열 템플릿 적용 부분도 calculateMessage() 함수로 추출하여 이렇게 리팩터링할 수 있습니다.

def calculateSquare(n: Int): Int = n * n

def calculateMessage(n: Int, square: Int): String =
  s"The square of $n is $square"

def printSquare(n: Int): Unit = {
  val square = calculateSquare(n)
  val message = calculateMessage(n, square)
  println(message)
}

이 리팩터링을 통해, 액션(콘솔 출력)과 계산 부분을 분리하여 순수 함수를 추출해낼 수 있었습니다.

이러한 과정이 자연스럽게 느껴지시나요?

#관심사의 분리

순수 함수는 입력을 오직 함수의 인자로부터 받고, 출력은 반환 값으로만 이루어집니다. 즉, 인자가 아닌 외부 값을 읽거나, 외부 변수에 출력을 쓰는 등의 동작은 하지 않습니다. 순수 함수는 그 자체로 완결적이며, 함수 외부의 상태나 변화에 신경 쓸 필요가 없습니다. 이로 인해 함수가 독립적으로 동작하게 되어 코드의 이해와 유지보수가 훨씬 용이해집니다.

이렇게 입력에 대한 계산과 그 결과 출력만으로 이루어져있고, 함수 호출을 해도 아무 상태도 바꾸지 않는 위 calculateSquare(), calculateMessage() 같은 함수를 순수 함수라고 합니다.

순수 함수는 수학적 함수를 말합니다. 즉, 수학에서 말하는 함수라는 개념이 바로 순수 함수입니다.

#함수(function), 프로시저(procedure), 서브루틴(subroutine), 메서드(method) 차이?

프로그래밍 언어에서 부 프로그램 코드를 호출할 수 있는 부분을 정의하는 여러가지 방법들이 있습니다. 엄밀히 말하면 서로 다른 성격의 것들이지만 대개 프로그래밍 언어의 문법상으로는 같은 취급을 하는 경우가 많습니다. 입력 값이나 반환 값이 있느냐, 부수 효과를 동반하느냐, 객체나 클래스에 종속되어 있느냐에 따라 조금씩 의미를 달리합니다. 하지만 함수형 프로그래밍 언어에서 함수를 언급할 때는 기본적으로 수학적 순수 함수라고 생각하면 됩니다.

함수를 수학에서 정의하는 함수처럼 쓰는 것은 함수형 프로그래밍의 실천 사항 중의 하나라고 할 수 있습니다.

앞으로 이 공식을 잘 기억해 두세요.

계산으로만 이루어짐 = 부수 효과 없음 = 순수성 = 참조 투명성

각각의 개념을 간단히 설명하자면 다음과 같습니다.

#계산으로만 이루어짐 (Composed purely of computation)

함수의 동작이 오로지 입력에 기반한 계산 결과를 반환한다는 의미입니다. 함수는 외부 상태나 다른 요인에 의존하지 않으며, 주어진 입력에 대해 항상 동일한 출력을 반환합니다.

calculateSquare(): 입력 n만을 사용하여 계산합니다.
calculateMessage(): 입력 n과 square 값만으로 계산합니다.

#부수 효과 없음 (No side effects)

부수 효과는 부작용(副作用) 혹은 영어로 사이드 이펙트(side effect)라고도 부릅니다.

함수가 반환하는 계산 결과를 작용(effect) 혹은 주작용(main effect)이라고 한다면, 함수의 실행으로 인해 초래되는 작용 이외의 부수적인 변화는 모두 부작용(부수 효과)에 해당합니다.

부수 효과가 없다는 것은 함수 실행 중에 외부 상태를 변경하거나 외부에서 관찰 가능한 다른 효과를 발생시키지 않는 상태를 의미합니다.

예를 들어, 파일 시스템, 데이터베이스, 네트워크 입출력이나 이와 유사한 동작이 없는 함수를 가리킵니다.

calculateSquare(), calculateMessage()는 계산 결과만 반환하며, 외부 상태를 변경하지 않습니다.
반면에 printSquare()는 println()을 호출해 표준 출력에 값을 쓰므로 부수 효과가 발생합니다.

#순수성 (Purity)

위의 두 가지 조건을 만족하는 함수를 순수한 함수라고 합니다. 즉, 동일한 입력에 대해 항상 동일한 출력을 반환하고, 외부에 영향을 미치지 않는 함수입니다.

따라서 calculateSquare()와 calculateMessage()는 순수 함수입니다.
반대로 printSquare()는 순수하지 않은 println()을 중간에 실행하므로 순수하지 않습니다.

#참조 투명성 (Referential transparency)

이 용어는 분석 철학에서 어떤 표현이나 문장이 전체 글 내에서 항상 동일한 의미를 가지는 경우를 가리키는 의미로 사용되기도 합니다.

참조 투명성은 같은 입력 표현(함수 호출)에 대해 항상 같은 결과를 내는 성질을 의미하며, 프로그램에서 어떤 표현식을 그 평가 값으로 대체해도 그 프로그램의 결과가 동일하다는 것을 뜻합니다.

예를 들어, calculateSquare(2)는 2 * 2 = 4이므로, calculateSquare(2)를 4로 대체해도 결과는 변하지 않습니다. 또한, calculateSquare()와 calculateMessage()는 몇 번을 호출해도 동일한 결과를 반환하므로 참조 투명합니다
printSquare()는 콘솔에 같은 메시지를 출력하지만, 호출할 때마다 콘솔에 출력되는 횟수가 더해지므로 참조 투명하지 않습니다.

결국, 이 모든 개념은 서로 긴밀하게 연결되어 있습니다. 이후에 더 깊이 다룰 예정이지만, 1장에서는 이 용어들과 개념을 간단히 요약해 두시면 충분합니다.

함수형 프로그래밍은 이렇게 부수 효과가 없는 순수 함수를 사용하고, 참조 투명성을 지키는 방향으로 코드를 작성합니다. 그렇다면 이렇게 하는 이유는 무엇이고, 그로 인해 얻을 수 있는 이점은 무엇일까요?

#함수형 프로그래밍의 이점

지금까지 설명한 내용을 바탕으로, 함수형 프로그래밍의 주요 이점을 다음과 같이 정리할 수 있습니다.

코드의 가독성 및 유지보수성: 순수성과 참조 투명성 덕분에 코드의 의도가 명확히 드러납니다. 순수 함수는 함수 시그니처(함수 이름 + 인자 + 반환 타입)대로 동작하는 것이 보장되고, 함수 시그니처로는 파악할 수 없는 숨겨진 동작(부수 효과)을 하지 않으므로 가독성이 높아지고, 코드 변경 시에도 영향을 쉽게 추적할 수 있어 유지보수가 수월해집니다.
디버깅 및 테스트 용이성: 순수 함수는 외부 상태를 변경하지 않기 때문에, 함수가 예상과 다른 결과를 내더라도 해당 함수만 집중적으로 살펴보면 됩니다. 이는 프로그램의 특정 부분을 독립적으로 테스트할 수 있게 만들어주며, 부수 효과가 있는 함수보다 순수 함수가 테스트하기에 훨씬 적합합니다.

참조 투명성과 컴파일러

참조 투명성이 지켜지는 코드는 컴파일러가 분석하기 쉬워져 코드 블럭을 재구성하여 중복 계산을 제거하거나 실행 순서를 최적화할 수 있는 가능성을 열어주고, 더 나아가서 병렬 처리를 용이하게 하는 등의 도움을 줍니다.

이 외에도 여러 이점이 있겠지만, 이번에는 1장에서 언급된 내용만 다루고 넘어가겠습니다.

#치환 모형(substitution model)과 등식적 추론(equational reasoning)

조금 거창하게 들리는 치환 모형과 등식적 추론(등식 추론이라고도 부릅니다)에 대해 알아보겠습니다.

참조 투명성이 유지된다면, 아래와 같이 치환 모형을 사용한 등식적 추론이 가능합니다.

// 함수 정의가 이렇고
def calculateSquare(n: Int): Int = n * n

calculateSquare(2) // 이 표현식이 주어졌을 때,

= (n => n * n)(2)  // 1. calculateSquare()를 본문(n * n)으로 치환
= 2 * 2            // 2. n=2 인자를 적용하여 계산 표현식으로 치환
= 4                // 3. 표현식을 계산한 결과로 치환

즉, f(x) = x * x일 때, f(2)는 2 * 2로 치환할 수 있고, 또 2 * 2는 4로 치환되어 최종적으로 4라는 결과로 유도됩니다.

이게 별로 특별할 것이 없는 당연한 이야기처럼 느껴지시나요?

이렇게 할 수 있는 이유는 바로 calculateSquare() 함수가 순수 함수이며, 그래서 참조 투명성이 지켜지는 덕분에 가능한 것입니다.

그렇다면 반대로 등식적 추론이 불가능한 함수의 경우를 생각해봅시다. 그리고 왜 등식적 추론이 성립하지 않는지도 생각해봅시다.

#예시1 (외부 상태에 의존하거나 상태를 변경하는 함수)

아래는 순수하지 않은 함수의 예시입니다.

var counter = 0

def incrementCounter(): Int = {
  counter = counter + 1
  counter
}

이와 같은 상황에서는 등식적 추론을 적용할 수 없습니다.

incrementCounter() // 처음 호출에서 1을 반환
incrementCounter() // 두 번째 호출에서 2를 반환

이 함수는 외부 상태인 counter 변수를 변경하기 때문에, 같은 함수를 호출하더라도 매번 결과가 달라집니다. 따라서 참조 투명성이 유지되지 않습니다. 등식적 추론을 하기 위해서는 함수 호출이 참조 투명성을 가져야 하며, 이는 동일한 입력에 대해 언제나 동일한 출력을 반환해야 함을 의미합니다.

#예시2 (순수하지 않은 동작을 포함하는 함수)

또 다른 형태의 참조 투명하지 않은 함수는 부수 효과를 동반하는 함수입니다. 예를 들어, 함수가 콘솔에 값을 출력하거나 파일에 데이터를 기록하는 등의 입출력(I/O) 작업을 할 때 참조 투명성이 깨집니다.

예를 들어, 콘솔에 값을 출력하는 함수의 경우를 생각해봅시다:

def printHello(): Unit = {
  println("Hello, world!")
}

printHello()  // 이 표현식에 대해 등식적 추론을 적용해 봅시다

이 함수를 등식적 추론으로 치환해 본다면 다음과 같은 문제가 생깁니다:

printHello()  // () 리턴, 콘솔에 "Hello, world!" 출력
printHello()  // () 리턴, 또다시 "Hello, world!" 출력

이 함수는 Unit를 리턴하지만, 출력하는 행위 자체가 부수 효과이기 때문에 참조 투명하지 않습니다. 같은 값을 반환하는 함수라 하더라도 그 함수가 수행하는 액션(콘솔 출력) 때문에 등식적 추론이 불가능합니다.

printHello()는 단순히 값을 반환하는 것이 아니라 콘솔에 출력을 발생시키는 부수 효과가 포함되어 있습니다.
즉, 같은 입력(Unit)에 대해 호출할 때마다 같은 결과(Unit)가 나오더라도, 그 과정에서 발생하는 부수 효과 때문에 등식적 추론을 할 수 없습니다. 함수 호출이 반복될 때마다 콘솔에 새로운 문자열이 찍히는 액션이 일어나기 때문입니다.

#예시3 (예외를 던지는 함수)

예외를 던지는 함수는 특정 상황에서 정상적으로 값을 반환하지 않고, 프로그램 흐름을 중단시키며 예외를 발생시키므로 참조 투명성을 유지하지 않습니다.

def divide(a: Int, b: Int): Int = {
  if (b == 0) throw new ArithmeticException("Division by zero")
  else a / b
}

위 함수는 divide(4, 2)를 호출하면 2를 반환하지만, divide(4, 0)을 호출하면 예외를 던집니다. 따라서 동일한 입력에 대해 언제나 동일한 출력을 보장하지 않습니다. 즉, 특정 입력에서 예외가 발생하므로 등식적 추론이 성립하지 않습니다.

#예시4 (종료되지 않는 함수)

이런 함수는 호출될 때 정상적으로 값을 반환하지 않고 영원히 실행을 지속하거나 실행이 멈추지 않습니다.

def infiniteLoop(): Int = {
  while (true) {}
  0
}

이 함수는 언제나 0을 반환하는 것으로 보일 수 있지만, 실제로는 무한 루프에 빠져 실행이 끝나지 않습니다. 따라서 등식적 추론을 통해 infiniteLoop()를 0으로 대체할 수 없습니다. 호출 결과가 무한 실행으로 이어지기 때문에 참조 투명성이 깨집니다.

#예시5 (현재 시간 또는 임의의 값을 반환하는 함수)

현재 시간이나 임의의 값을 반환하는 함수는 매 호출마다 다른 결과를 반환하기 때문에 참조 투명성을 유지하지 않습니다.

def getCurrentTime(): Long = System.currentTimeMillis()
def getRandomNumber(): Int = scala.util.Random.nextInt()

getCurrentTime() 함수는 호출할 때마다 다른 값을 반환하며, getRandomNumber() 함수도 임의의 값을 생성하여 반환합니다. 이러한 함수들은 같은 입력에 대해 다른 결과를 반환하므로 등식적 추론을 적용할 수 없습니다.

#예시6 (외부 자원에 의존하는 함수)

외부 자원에 접근하는 함수, 예를 들어 파일을 읽거나 데이터베이스에서 값을 조회하는 함수는 외부 상태나 환경에 따라 다른 결과를 반환할 수 있기 때문에 참조 투명성을 유지하지 않습니다.

def readFile(filename: String): String = {
  scala.io.Source.fromFile(filename).mkString
}

이 함수는 파일의 내용을 읽어 반환하지만, 파일 내용이 변경될 경우 같은 filename을 인자로 넘겨도 다른 결과를 반환할 수 있습니다. 외부 자원 상태에 따라 결과가 달라지기 때문에 등식적 추론이 불가능합니다.

#예시7 (사용자 입력에 의존하는 함수)

사용자 입력을 요청하는 함수는 호출 시마다 사용자의 입력이 달라질 수 있어 같은 호출에서도 다른 결과를 반환할 수 있습니다.

def getUserInput(): String = {
  scala.io.StdIn.readLine()
}

getUserInput() 함수는 사용자가 입력하는 값에 따라 달라지므로 참조 투명성을 유지하지 않습니다. 동일한 입력에 대해 동일한 출력을 보장할 수 없기 때문에 등식적 추론을 적용할 수 없습니다.

#예시8 (네트워크 호출을 수행하는 함수)

네트워크 통신을 통해 외부 API에 접근하거나 네트워크 요청을 수행하는 함수는 네트워크 상태나 외부 서버의 응답에 따라 다른 결과를 반환할 수 있습니다.

def fetchDataFromApi(url: String): String = {
  // 네트워크 요청을 보낸다고 가정
  // 실제 구현은 생략
}

네트워크 상태나 API 서버의 상태에 따라 결과가 달라질 수 있으며, 네트워크 장애나 지연이 발생할 수도 있기 때문에 이 함수는 등식적 추론이 불가능합니다.

이상으로 등식적 추론이 불가능한 함수의 유형을 알아보았고, 다음과 같이 정리할 수 있습니다.

등식적 추론이 안 되는 함수 = 참조 투명하지 않은 함수 = 순수하지 않은 함수 = 부수 효과가 있는 함수

#순수 함수만 사용해서 일반적으로 유용한 프로그램을 작성할 수 있을까요?

답은 아니다 입니다. 함수형 프로그래밍 언어로 작성한 프로그램이라도 단순 계산 이상의 기능(데이터베이스 입출력, 네트워크 호출 등)이 필요한 경우 결국 어느 시점에는 순수하지 않는 동작을 실행하게 됩니다.

그러면 도대체 왜 함수형 프로그래밍에서는 이렇게 순수 함수를 강조할까요? 그것은 프로그램의 코드 대부분에 실제로 순수 함수를 사용하는 것이 일반적이기 때문입니다. 순수 함수를 합성해서 더 큰 단위의 순수 함수를 만들고, 그 함수들을 또 합성하여 기능을 수행하는 프로그램 코드가 됩니다. 그리고 마지막에 가서야 그 프로그램을 딱 한 번 순수하지 않게 실행합니다.

예를 들어, 한 번 실행하고 바로 종료하는 콘솔 프로그램이라면 주로 메인 함수에서, 반면에 반복적인 요청을 처리하는 서버라면 요청을 처리하는 컨트롤러 부분에서 그렇게 할 가능성이 높습니다. (그러나 이 경우 아마 함수형 웹 프레임워크나 라이브러리에 의해 순수하지 않는 동작을 실행하는 부분이 숨겨지게 되는 것이 일반적입니다)

즉, 가능하면 순수 함수를 합성해서 프로그램을 작성하고, 부수 효과를 마지막 순간까지 유예하는 방식으로 프로그래밍하는 것이 함수형 프로그래밍의 일반적인 전략입니다.

그리하여 오늘도 쿠키런: 킹덤 서버는 잘 돌아가고 있습니다.

이에 관한 자세한 내용은 나중에 책의 후반부, 제13장 외부 효과와 입출력 편에서 다루어집니다. 여러분들이 아마 어딘가에서 들어봤을 모나드(Monad) 같은 것들이 바로 함수형 프로그래밍에서 함수 합성을 가능하게 하는 도구 중의 하나입니다. 앞으로 이런 새롭고 흥미로운 개념들을 많이 만나보게 될 것입니다.

#정리

이번에 『스칼라로 배우는 함수형 프로그래밍』 제1장 함수형 프로그래밍이란 무엇인가? 를 함께 읽어보았습니다.

이번 장에서 다룬 주요 키워드는 다음과 같습니다:

계산 vs. 액션 (computation vs. action)
순수 함수 (pure function)
부수 효과 (side effect)
참조 투명성 (referential transparency)
치환 모형 (substitution model)
등식적 추론 (equational reasoning)

지금까지 간단한 코드 예제들을 통해서 각각의 용어의 의미가 무엇인지 살펴보았습니다.

이 용어와 개념을 잘 이해해두면 앞으로 책을 읽어가는 데 도움이 될 것입니다. 함수형 프로그래밍의 기본을 차근차근 다져 나가는 과정에서, 이러한 개념들이 어떻게 서로 연결되는지 확인하는 것이 중요합니다.

이제 막 첫 장을 마쳤고, 앞으로 점점 더 흥미롭고 심화된 내용이 나올 것입니다. 저도 계속해서 책을 다시 읽어보고 내용을 정리하며 다음 글에서 더 유익한 설명을 드리도록 하겠습니다.

그럼 다음 편에서 뵙겠습니다. 감사합니다.

#더보기

타입스크립트스럽게 성능과 생산성 두 마리 토끼 모두 잡기

Wed, 04 Sep 2024 00:00:00 GMT

안녕하세요, 이번 글에서는 javascript의 Proxy API를 사용해 웹 기반 게임 Admin에서 gRPC 게임 서버와 효과적으로 통신하는 방법을 소개합니다.

#Introduction

요즘 웹 서비스들은 통신 방식으로 대부분 REST API를 사용합니다. 하지만 실시간으로 많은 데이터를 주고받아야 하는 게임의 특성상, REST API를 사용하기에는 어려운 부분이 있습니다. 쿠키런: 킹덤을 포함한 데브시스터즈의 여러 게임은 효율적인 통신을 위해 API 프로토콜로 gRPC를 채택하고 있습니다. 아마 gRPC를 처음 들어보시는 분들도 있을 것 같은데요, gRPC의 특징 몇 가지 짚고 가겠습니다.

gRPC는 HTTP/2에 커스텀 헤더를 추가한 프로토콜로 통신합니다.
메시지 데이터는 protocol buffers(이하 protobuf)를 사용해 바이너리 형태로 직렬화하여 전송합니다.
protobuf를 사용하여 데이터 구조를 정의할 수 있고, code-gen 라이브러리로 .proto 스키마에 대응하는 .d.ts 파일과 .js파일을 생성할 수 있습니다.

(protobuf와 gRPC에 대한 자세한 내용은 이 링크를 참고해 주세요)

위의 세 가지 특징으로 게임 Admin의 아키텍처를 아래와 같이 구성했습니다.

Admin Frontend(이하 Admin FE), Admin Backend(이하 Admin BE), 게임 서버로 구성된 게임 Admin 아키텍처

gRPC에 필요한 커스텀 헤더를 브라우저가 지원하지 않아 게임 서버로 직접 gRPC 호출을 할 수 없기 때문에 Admin BE를 프록시 서버로 두어야 합니다.^[1] code-gen으로 생성된 .js 파일은 직렬화/역직렬화 로직으로 Admin BE와 게임 서버 간의 gRPC 통신에 사용되고, Admin FE와 Admin BE 간의 통신은 직접 HTTP endpoint를 작성해야 합니다.

그런데 이 구조에서는 한가지 문제점이 있습니다. 대부분의 protobuf code-gen 라이브러리가 Node.js 런타임을 대상으로 하기에 FE ↔ BE 통신의 구현체는 code-gen을 활용하지 못하고, gRPC method가 추가될 때마다 REST API의 endpoint를 직접 추가해야 하는 번거로움이 있습니다. 즉, protobuf를 쓰는 이유가 퇴색되고 있던 것입니다.

interface ApiClient {
	/* auto-generated */
	serviceA: {
		method1(): Promise<void>;
		method2(): Promise<void>;
	},
	serviceB: {
		method1(): Promise<void>;
	}
};

// Admin BE
const beClient: ApiClient = { /* auto-generated (생략) */ };

app.post('/grpc/serviceA/method1', async (req, res) => {
	const response = await beClient.serviceA.method1(req.body.payload);
  res.send(response.data);
});

app.post('/grpc/serviceA/method2', async (req, res) => {
	const response = await beClient.serviceA.method2(req.body.payload);
  res.send(response.data);
});

app.post('/grpc/serviceB/method1', async (req, res) => {
	const response = await beClient.serviceB.method1(req.body.payload);
  res.send(response.data);
});

------------------------------------------------------

// Admin FE
const beClient: ApiClient = {
	serviceA: {
		method1: (payload) => fetch('/gprc/serviceA/method1', { body: payload }),
		method2: (payload) => fetch('/gprc/serviceA/method2', { body: payload }),
	},
	serviceB: {
	  method1: (payload) => fetch('/gprc/serviceB/method1', { body: payload }),
	},
};

#Idea

오늘도 어김없이 개발자 김용쿠는 gRPC와 똑같은 REST API를 추가하다 문득 이런 생각이 들었습니다.

BE용 api client가 타입만 보면 브라우저에서도 사용할 수 있을 것 같은데, 저 타입처럼 동작하는 브라우저용 구현체를 자동으로 만들 수 없을까?^[2]

protobuf parser로 직접 FE용 code-gen을 만들어 이 문제를 해결할 수도 있습니다만, 이미 타입 정보가 존재하는데 각 endpoint와 1대1 대응하는 js 코드를 또 만들어야 할까요? 아래의 pseudo code를 상상하며 다음의 목표를 세웠습니다.

interface ApiClient { /* auto-generated */ };

// Admin BE
const beClient: ApiClient = { /* auto-generated */ };

// single & unique BE endpoint
app.post('/grpc', async (req, res) => {
  const paths = req.body.paths;
  const payload = req.body.payload;
  const rpc = paths.reduce((prev, path) => prev[path], beClient);
  const response = await rpc(payload);
  res.send(response.body);
})

------------------------------------------------------

// Admin FE
const feClient: ApiClient = ?;
feClient.serviceA.method1(payload); // fetch('/grpc', { body: JSON.stringify({ path: ['serviceA', 'method1'], payload }) })
feClient.serviceA.method2(payload); // fetch('/grpc', { body: JSON.stringify({ path: ['serviceA', 'method2'], payload }) })
feClient.serviceB.method1(payload); // fetch('/grpc', { body: JSON.stringify({ path: ['serviceB', 'method1'], payload }) })

JavaScript 구현체와 code-gen으로 생성된 타입을 합쳐, 기존에 BE에서 사용하던 모습 그대로 마치 FE에도 api client 존재하듯 개발자를 속이자
feClient 구현체는 beClient 타입 시그니처대로 동작해야 한다
feClient는 code-gen을 사용하지 않고 런타임에 동적으로 beClient의 함수를 호출하도록 설계하자

#Implementation

그런데 어떻게 code-gen 없이 feClient 구현체를 만들 수 있을까요? 답은 JavaScript Proxy에서 찾을 수 있습니다.

JavaScript의 Proxy는 Reflection과 함께 JavaScript의 meta-programming 기법에 사용하는 API로, 객체의 여러가지 기본 동작을 재정의 할 수 있습니다. 아래 코드는 get() handler와 두 번째 인자인 property를 사용하여 객체의 프로퍼티 접근을 재정의해, 실제 프로퍼티 값 대신 프로퍼티 접근 경로를 반환하도록 기본 동작을 재정의 한 예시입니다.

const obj = {};
const proxy = new Proxy(obj, {
  get(_target, property) {
    return 'access: ' + property;
  },
});

console.log(proxy.service); // "access: service"

proxy.service 같은 1단계 자식에 대한 접근은 쉽게 구현할 수 있었는데요, proxy.service.method와 같이 2단계 이상의 자식에 대한 접근은 어떻게 구현할 수 있을까요? 바로 재귀함수를 통해서 이를 쉽게 구현할 수 있습니다.

function createProxy(target, path = []) {
  return new Proxy(target, {
    get(_, property) {
      const newPath = [...path, property];
      console.log(newPath);
      return createProxy(target, newPath); // 재귀!!
    },
  });
}

const obj = {};
const proxy = createProxy(obj);
proxy.service.method;
// ['service']
// ['service', 'method']

이제 거의 다 왔습니다.

지금까지는 프로퍼티 접근에 대해서 다루었는데요, 어떻게 하면 proxy.service.method 호출시 실제 rpc가 호출되게 할 수 있을까요? 이를 위해서 Proxy API 중 apply() handler를 사용해 함수의 호출을 재정의 해보겠습니다.

const rpc = (path, payload) => console.log(path.join('.'), payload);

function createProxy(target, path = []) {
  return new Proxy(target, {
    get(_target, property) {
      return createProxy(target, [...path, property]);
    },
    apply(_target, _thisArg, argumentsList) {
      return target(path, argumentsList[0]); // 실제 rpc 호출
    },
  });
}

const proxy = createProxy(rpc);

proxy.service.method('payload'); // "service.method", "payload"

마치 실제로 proxy.service 라는 객체 안에 method라는 함수가 있는것처럼 보이지 않나요?

이렇게 저희는 실제로는 rpc라는 하나의 함수로, 개발자에게는 proxy.service.method 라는 api 인스턴스가 있는 것 같은 개발 경험을 선사할 수 있었습니다.

const callGrpc = (path: string[], payload: any) =>
  fetch('/grpc', { body: JSON.stringify({ path, payload }) });

function createClient(
  target: (path: string[], payload: any) => Promise<any>,
  path: string[] = []
): any {
  return new Proxy(target, {
    get(_target, property) {
      return createClient(target, [...path, property.toString()]);
    },
    apply(_target, _thisArg, argumentsList) {
      return target(path, argumentsList[0]); // 실제 rpc 호출
    },
  });
}

const feClient: ApiClient = createClient(callGrpc);

feClient.serviceA.method1(payload); // OK
feClient.serviceA.method2(payload); // OK
feClient.serviceA.method3(payload); // type error
feClient.serviceB.method1(payload); // OK
feClient.serviceB.method2(payload); // type error

#Furthermore

지금까지 동적으로 동작하는 웹 gRPC 클라이언트에 대해 알아보았습니다. 이번 단락에서는 위의 구현체를 활용하여 프록시 서버를 최적화하는 방법을 간단히 소개합니다.

grpc-node에서 제공하는 code-gen 예제를 보면 간단한 스키마에 대해서도 수백 줄의 코드가 생성되는 것을 확인 할 수 있는데요. 게임이 출시되고 시간이 흐름에 따라 게임이 갖는 스키마는 굉장히 거대하고 복잡해집니다. 그리고 code-gen으로 생성한 코드의 양도 비례해서 많아지죠. 무려 코드가 너무 무거워서 Admin BE의 부팅시간에 영향이 갈 정도가 됩니다.

Faster apps with JSON.parse (Chrome Dev Summit 2019) 발표에서 최적화 방안을 찾았습니다. code-gen의 결과물이 꼭 JavaScript일 필요는 없습니다. 직렬화/역직렬화 로직을 표현하는 JSON을 생성하고 이 JSON을 기반으로 동작하는 함수 하나만 있다면 같은 방법으로 성능을 올릴 수 있겠다고 판단했습니다.^[3] 그리고 앞에서 작성한 Proxy 객체를 재사용하면 기존의 code-gen으로 생성된 코드와 동일한 타입과 동작을 갖는 함수가 완성됩니다.

#Conclusion

이 방법으로 쿠키런: 킹덤 운영툴은 FE와 BE를 합쳐 약 100만 줄의 JavaScript 코드를 삭제했고, 개발자는 endpoint를 작성하는 번거로운 작업에서 벗어났습니다. 혹자는 너무 안전하지 못한 코드가 아니냐고 할 수 있겠지만 TypeScript가 컴파일타임을, meta-data가 런타임을 지켜주는 상황에서 JavaScript스럽게 문제를 해결했다는 말로 마무리합니다.

#Off the Record

[1] grpc-gateway를 사용할 수도 있지만 Node.js를 지원하지 않습니다. 이미 Next.js를 사용하고 있어서 고려하지 않았습니다.

[2] tRPC에서 아이디어를 얻었습니다.

[3] protobufjs는 런타임에 동적으로 proto → js 변환을 가능하게 해주는 reflection 기능을 제공합니다. 이를 활용하여 쉽게 구현할 수 있었습니다.

Datadog Live with Devsisters 돌아보기

Thu, 29 Aug 2024 00:00:00 GMT

안녕하세요. 데브시스터즈 기술본부에서 조직문화, 개발문화를 가꾸고 있는 전경아입니다.

데브시스터즈에서는 오랜 기간동안 Datadog(이하 데이터독)을 모니터링 서비스로 사용하고 있는데요. 지난 2024년 6월에 데브시스터즈에서 축적해온 데이터독의 사용 노하우를 다양한 분들께 공유해드리고자 개발자 분들을 초청하여 Datadog Live with Devsisters 행사를 진행하였습니다.

데이터독 담당자 분들과 함께 준비, 진행하였던 행사의 영상은 Datadog Korea 유튜브에 업로드되어 있으며, 본문에도 첨부해드립니다.

이번 글에서는 전반적인 행사 내용과 소감과 함께, 행사에서 다루었던 내용을 요약해보고자 합니다.

#행사 소개

Datadog Live with Devsisters은 데브시스터즈와 데이터독이 함께 준비한 라이브 톡 행사입니다. 데브시스터즈에서 과거에 데이터독을 왜 도입하였는지와 지금까지 어떻게 이용하고 있는지 실제 사례를 공유하고 Q&A 시간을 가지며 참가하신 분들께 데이터독에 대한 이해를 높여드리는 것이 목적이었습니다.

패널톡 형태로 게임, 인프라, 데이터, 플랫폼 팀을 리드하고 계신 4분의 엔지니어를 모시고 진행했는데요, 게임업계 담당자뿐만 아니라 다양한 산업군에서 많은 분들이 모여주셔서 저희의 이야기를 더욱 열정적으로 전달할 수 있었던 귀중한 시간이었습니다.

발표에 앞서 인사를 드리고 있는 데브시스터즈 동료분들

#데브시스터즈의 데이터독 도입 배경

데브시스터즈는 AWS의 한국 리전이 출시되기 훨씬 이전인 2011년부터 AWS 클라우드를 활용하여 서비스를 운영해왔습니다. 2013년에 출시한 쿠키런 For Kakao는 AWS 클라우드를 적극적으로 활용하여 적은 인력으로도 수백만 명의 유저분들에게 안정적으로 서비스를 제공할 수 있게 되었지만, 모니터링 측면에서는 여전히 보완할 필요가 있는 부분들이 있었습니다. 예를 들어, 당시 사용하던 Zabbix, CloudWatch, StatsD, Graphite 등의 기존 모니터링 도구들은 설정과 유지보수를 위해 전문적인 지식과 경험이 필요했고, Stateful 한 특성 때문에 트래픽 변동성이 큰 클라우드 환경에서 효율적인 관리가 어려웠습니다. 또한, 여러 애플리케이션을 운영하는 과정에서 각 애플리케이션에 맞춘 메트릭을 세밀하게 분석하고 수집하기에 지나치게 복잡했습니다.

이와 같은 고민을 하며 차기작 출시를 준비하다보니, 서비스 안정성 면에서 모니터링 스택에 대한 니즈는 커져갔습니다. 그러한 상황에서, 승용님께서 참석했던 컨퍼런스에서 우연한 기회로 데이터독 한국인 엔지니어께서 진행하신 세션을 듣게 되었고, anomaly 등의 다양한 기능이 매력적이고 안정적이라고 느껴 빠르게 차기작의 모니터링 스택으로 도입하게 되었습니다. 결과적으로, 2016년 쿠키런: 오븐브레이크가 출시되었을 때, 수 만명의 유저가 동시에 회원가입을 하는 과정에 발생했던 병목을 감지하여 빠르게 해결하는 등 많은 도움을 받을 수 있었습니다.

데브시스터즈에서의 데이터독 주요 사용 사례는 아래 자료들에서 상세하게 확인하실 수 있습니다.

이후로도 지속적으로 데이터독을 사용하며 아직도 다양한 장점을 체감하고 있습니다. 데브시스터즈에서 체감하는 주요 효용으로는, APM과 같이 니즈에 알맞게 필요한 모니터링 스택을 제공하고 있다는 점, 신규 Integration 요청에 빠르게 대응해주어 사용자로서 편리하다는 점, 그리고 무엇보다 모니터링 플랫폼으로써 핵심 기능과 사용성이 한결 같이 잘 유지되고 있다는 점을 꼽을 수 있습니다.

#팀 별 데이터독 활용 사례

다음으로는 게임 개발팀, 게임 플랫폼 팀, 데브옵스 팀에서 데이터독을 어떻게 활용하고 계신지 사례를 공유해주셨습니다. 내용을 간략히 요약하면 다음과 같습니다.

#1. 게임 개발팀

실시간 지표 모니터링:
- RPS 등의 시스템 지표를 모니터링하여 서버가 얼마만큼의 부하를 받고 어떤 상태에 있는지를 실시간으로 확인하여 트래픽 변동 상황에서 서버의 안정성을 유지합니다.
- 매출, 플레이 통계 등 게임 내 주요 지표를 커스텀 메트릭으로 설정하고 실시간으로 모니터링하여 매출 변동이나 플레이 패턴 변화를 빠르게 파악하고 대응할 수 있습니다.
장애 상황 대응:
- 장애 상황 모니터를 통해 특정 조건(ex. Go 서버에서 panic이 발생)이 일어나면 알람이 울리도록 Custom Metric과 조합하여 설정하여 빠르게 장애를 인지하고 신속히 대응할 수 있습니다.
프로파일링을 통한 서버 성능 개선:
- APM을 통한 주기적으로 성능 분석을 시도하면서, 신규 기능 도입을 통한 성능 문제를 파악하거나 개발 단계의 실수 등을 확인합니다.

#2. 플랫폼 팀

서비스 맵을 통한 MSA 모니터링:
- 서비스 간의 의존성을 시각화하여 각 서비스가 어떻게 상호작용하는지 파악합니다. 이를 통해 복잡한 서비스 구조에서도 문제를 쉽게 추적할 수 있습니다.
데이터독 기능을 사용한 모니터링:
- APM, Synthetic Monitoring, Service Check 등을 통해 서비스 상태를 확인하고 관리합니다.
서드파티 API 모니터링:
- Google 혹은 Apple 로그인과 같은 외부 API에서 문제, 지연 등이 발생하고 있는지 인지하고 대응하기 위해 데이터독 모니터를 사용합니다.

#3. 데브옵스 팀

기본적인 리소스 사용량 및 이벤트 모니터링:
- CPU, 메모리 사용률, 네트워크 트래픽 등을 모니터링하여 서버 상태를 파악하고, 리소스를 효율적으로 사용하고 있는지도 확인하여 비용을 절감하는 시도로도 이어지고 있습니다.
쿠버네티스 환경 모니터링:
- 쿠버네티스 클러스터에서 발생하는 다양한 이벤트를 모니터링하여 문제 발생 시 빠르게 파악합니다. 또한 Pod가 할당되지 않는다거나 반복적으로 재시작하는 등 단순한 지표가 아니라 현상도 확인할 수 있습니다.
SLO 관리
- 데이터독 SLO를 통해 에러율, 지연 시간, 서비스 상태 등을 관리 및 확인하고 알람을 받고 있습니다.
- 유저에게 서비스를 제공하는 입장에서 SLO는 무조건 높여야 하지만, SLO를 높히는 데에는 많은 비용이 들어갑니다. 이같은 기술적 어려움에 대해 담당 부서에 충분히 공유하여 이해를 구하고, 합리적인 게임 서비스 안정성을 협의하는 과정을 거치고 있습니다.

#인프라 관리

다음으로는 데이터독과는 크게 관련이 없을 수 있지만, 행사를 준비하며 사전에 수집하였던 질문 중 쿠버네티스와 인프라 관리에 대한 질문이 많았기 때문에 데브시스터즈에서는 인프라 관리를 어떤 방식으로 하고 있는지 데브옵스 팀에서 소개해주셨습니다.

쿠버네티스를 관리하는 조직이라면 모두 클러스터를 배포, 관리하는 방식이 있으실텐데요. 데브시스터즈에서 과거에는 하나의 클러스터에 여러 개의 게임, 어플리케이션을 배포하는 형태로 사용하고 있었습니다. 그러나 이러한 패턴에서는 구조적으로 특정 어플리케이션에서 발생한 장애가 인프라 혹은 클러스터 단으로 번져 다른 어플리케이션과 게임으로 전파될 위험성이 있고, 또 각 게임에서 적용하고 싶은 설정이 달라 관리해야할 설정셋이 점점 늘어나는 등의 어려움이 있었습니다. 그렇기에 데브시스터즈에서는 이제 각 게임마다 각각의 클러스터를 사용하는 패턴으로 변경하였습니다.

데브시스터즈에서 배포를 필요로 하는 모든 인프라는 코드로 관리될 것을 원칙으로 하고 있으며, 이는 쿠버네티스 클러스터 또한 예외가 아닙니다. 각 개발팀에서 필요로 하는 쿠버네티스 클러스터는 기본적으로 테라폼 코드를 통해 관리하고 있는데, 쿠버네티스를 분리하면서 클러스터와 애드온들을 클러스터 별로 개별 설치하고 관리하는 과도기가 있었습니다. 짐작하시다시피 설치 방법과 버전 별로 필요한 작업들이 달라지기 때문에 클러스터 수가 많아질수록 관리 상 어려움이 크게 발생하였기 때문에, 지금은 대부분의 클러스터를 직접 작성한 EKS 테라폼 모듈을 통해 관리하고 있습니다. 이 모듈에는 데이터독 등의 애드온부터 배포를 위한 도구 등까지, 기본적으로 데브시스터즈에서 EKS를 사용하는 패턴에서 필요한 것들을 직접 설정하여 사용할 수 있게 구현해두었습니다. 설정을 명시하지 않을 경우 미리 설정해둔 기본값이 자동으로 적용 및 업데이트 되기 때문에, 결과적으로 데브옵스 팀에서 축적한 경험이 적은 노력으로 전파되는 구조가 되었습니다.

데브시스터즈에서 사용중인 쿠버네티스 테라폼

또한 개발팀에서 개발을 진행하게 되면서 여러가지 환경의 QA가 필요하게 되었습니다. 그런 상황에서 새로운 환경의 서버를 쉽게 배포할 수 있는 CD 툴도 내부적으로 개발하여 사용하고 있습니다. (다소 갑작스럽게 CD툴에 대한 이야기가 나오지만, 관련해서 인프라셀에서 다른 기술블로그 글로 소개를 준비하고 있다고 합니다.)

자체 개발하여 사용하고 있는 CD도구 화면

#부하테스트 및 최적화

여러 게임들을 출시해온 데브시스터즈가 부하테스트에 대해 가진 노하우에 대한 질문을 주신 분도 있었습니다. 마침 행사 당시에 쿠키런: 모험의 탑 런칭을 준비하고 있었기 때문에 비교적 생동감 있는 답변을 드릴 수 있었습니다.

런칭 전 부하테스트는 목표 부하를 수용하기 위해 필요한 인프라 규모에 대한 가설을 세우고 검증하는 과정의 반복이기 때문에, RPS, 특정 컴포넌트의 서버 대수 등 다양한 설정을 변인으로 두고 성능에 발생하는 변화를 측정하는 방식으로 진행됩니다. 변인에 따라 여러 가지 시나리오를 준비하고, 이에 대한 지표와 결과를 분석하여 서버의 한계점과 적정점을 찾아가는 과정을 거칩니다. 보통 데브옵스 팀에서 테스트를 위한 격리된 인프라를 준비해서 제공하고, 게임 개발팀에서 이를 사용하여 테스트를 진행하며, 결과에 대해서는 서로 같이 논의하며 개선해나가는 사이클을 거칩니다. 부하 테스트 과정에서도 Datadog APM을 사용하여 어떤 API가 어떤 지점에서 문제를 일으키는지를 flame graph 등을 통해 손쉽게 확인할 수 있습니다.

물론 API에 따른 성능 최적화는 게임 서비스 중에도 진행이 필요합니다. 라이브 서비스 중에는 단순히 한 시점의 지표만 확인하는 것이 아니라, 데이터독 메트릭의 calendar_shift 함수를 활용하여 지난 주 등 과거 시점의 지표와도 비교하면 서비스에 어떤 변동이 있어서 새로운 상황이 발생하는지 모니터링할 수 있습니다.

#장애 알람 수신

데이터독을 사용하면 모니터링에 필요한 도구들을 적은 공수로 설정할 수 있지만, 모니터링만큼 중요한 것이 문제 상황에 대해 적절한 시점에 개입을 할 수 있도록 알람을 받는 것입니다. 행사에 참석하신 분들도 이 부분에 관심을 가지고 계신 것을 확인할 수 있었는데요.

데브시스터즈는 현재 데브옵스 팀을 주축으로 알람 가이드라인을 만들어두었고, 일관된 규칙의 알람에 대한 원칙을 홍보, 교육하여 게임팀에서 적용할 수 있도록 돕고 있습니다.

가장 기본적인 컨셉은 데이터독과 슬랙을 연동하여 슬랙으로 알람을 받는 것입니다. 과거에는 배포 환경에 따라 production 환경 알람은 중요 채널로, dev 환경은 서브 채널로 보내는 등의 규칙을 적용하였으나, 이 과정에서 내부 운영툴이나 크게 신경쓰지 않는 외부 서비스 등에 대한 알람이 섞여 들어와 발생한 알람에 대한 중요도를 판단하는데 혼란을 주었습니다. 그래서 지금은 알람을 받은 시점을 기준으로 15분 내에 대응해야 하는 알람, 1시간 내에 대응해야 하는 알람 등 대응시간에 따라 기준을 나누었습니다.

그렇게 발송된 알람에 대하여 빠르고 체계적인 대응이 필요할 경우 Datadog Incident 기능을 통해 별도의 슬랙 채널을 만들어 커뮤니케이션 파편화를 방지하고, 장애 상황과 타임라인은 노션에 기록하여 해결된 이후에도 참고할 수 있도록 관리하고 있습니다.

#마치며

2023년 2월에 진행한 스칼라 개발자 밋업 이후 오랜만에 외부 개발자분들과 지식을 나누고 서로 교류하는 시간을 가졌는데요, 데브시스터즈의 개발 문화를 알릴 수 있는 이번 행사를 함께 준비하고 진행할 수 있어서 뜻깊은 시간이었습니다.

좋은 기회로 행사 전반을 기획하고 진행해주신 데이터독 분들을 비롯하여, 짧은 기간 속에 매주 성실히 준비하면서 패널톡을 진행해주신 창원님, 재영님, 승용님, 대영님, 정훈님께 감사드립니다. 무엇보다, 데브시스터즈에서는 데이터독을 어떻게 사용하는지 궁금증을 가지고 긴 시간동안 집중하며 적극적인 질문으로 의미있는 시간을 만들어주신 참가자분들께 감사드립니다.

다음에도 개발 행사를 진행할 예정이니 많은 관심 가져주시고 다시 만나뵐 수 있기를 기대합니다.

고성능을 위한 ZIO 튜닝

Mon, 05 Aug 2024 00:00:00 GMT

알림: 이 글은 Tuning ZIO for high performance의 한국어 번역본입니다.

안녕하세요, 스튜디오 킹덤에서 서버 소프트웨어 엔지니어로 일하고 있는 삐에르입니다.

Disclaimer

우선, 이 글에서 논의하는 내용이 절대적인 진리는 아니라는 점을 밝힙니다. 무엇을 수행하는 애플리케이션인지에 따라 애플리케이션을 빠르게 만드는 방법도 크게 좌우됩니다. 사용 사례에 따라 ZIO의 오버헤드는 완전히 무시할 수 있는 수준일 수도 있지만, 상당히 클 수도 있습니다. 이를 알 수 있는 유일한 방법은 프로파일러와 함께 부하 테스트를 수행하여 애플리케이션 성능을 분석하고 측정하는 것입니다. 하지만 이 글을 통해 ZIO 앱을 프로덕션에 배포할 때 생각할 법한 몇 가지 흥미로운 점과 고려할 점을 알려드리고자 합니다.

#런타임 플래그

우선 쉬운 것부터 시작하겠습니다. ZIO에는 애플리케이션 실행 시 쉽게 켜거나 끌 수 있는 몇 가지 플래그가 있습니다. 이 중 모든 플래그를 상세히 설명하지는 않겠지만, 프로덕션에서 어느 정도 영향을 미칠 수 있는 두 가지 플래그에 주목하고자 합니다.

첫 번째 플래그는 FiberRoots라는 이름을 가지고 있으며 기본적으로 활성화되어 있습니다. 이 플래그가 활성화되면 루트 fiber가 생성될 때마다(일반적으로 forkDaemon 연산자를 사용할 때) 이 fiber는 모든 루트 fiber를 추적하는 목록에 추가됩니다. 이 메커니즘은 두 가지 목적을 가지고 있습니다:

Fiber 덤프를 수행할 수 있습니다. 스레드 덤프와 마찬가지로 애플리케이션 프로세스에 kill -s INFO를 보내면 루트 fiber의 전체 목록, 상태, 현재 수행 중인 작업(실행 중인 함수)을 출력합니다.
애플리케이션을 중지할 때 ZIO는 모든 루트 fiber를 중단하려고 시도합니다. 이를 추적하지 않으면 메인 fiber에서 생성된 "자식" fiber만 중단되지만, forkDaemon을 통해 생성된 다른 루트 fiber는 깨끗하게 종료되지 않을 것입니다.

그러나 많은 루트 fiber를 생성하는 경우 이러한 추적에는 비용이 발생할 수 있습니다. 가장 극단적인 사례로, 아무 작업도 하지 않는 루트 fiber만 포크하는 경우 FiberRoots 플래그를 비활성화하면 성능이 2.5배 향상됩니다(벤치마크 결과는 여기 참조). 비록 코드에서 forkDaemon을 많이 사용하지 않더라도 사용하는 라이브러리에 의해 호출될 수 있습니다. 예를 들어, zio-grpc는 모든 gRPC 요청에서 forkDaemon을 호출합니다. 일부 ZIO 연산자도 내부적으로 이를 사용합니다.

개인적으로 로컬 환경에서는 가끔 fiber 덤프를 사용하지만, 프로덕션에서는 정말로 필요하지 않기 때문에 불필요한 추적을 피하기 위해 해당 플래그를 비활성화했습니다. 이를 비활성화하려면 ZIO 앱의 bootstrap 함수에 다음 코드를 추가하면 됩니다:

val bootstrap = Runtime.disableFlags(RuntimeFlag.FiberRoots)

기본적으로 비활성화되어 있는 또 다른 흥미로운 플래그가 있습니다: RuntimeMetrics. 이 플래그를 활성화하면 몇몇 성능 메트릭이 직접 ZIO 메트릭으로 노출됩니다. Prometheus, Datadog 등 원하는 백엔드로 메트릭을 보내고 있다면, 이들은 자동으로 송출될 것입니다. 수집되는 메트릭은 다음과 같습니다:

zio_fiber_failure_causes는 fiber 실패의 개략적인 원인을 수집합니다.
zio_fiber_fork_locations는 코드에서 fiber를 가장 많이 포크하는 위치를 알려줍니다.
zio_fiber_started, zio_fiber_successes, zio_fiber_failures는 시작된 fiber의 수와 성공하거나 실패한 fiber의 수를 계산합니다.
zio_fiber_lifetimes는 fiber가 얼마나 오래 실행되는지를 측정합니다.

프로덕션 시스템을 모니터링할 때 이러한 메트릭은 매우 유용할 수 있으므로 런타임 오버헤드를 감안하더라도 이를 고려해볼만 합니다. 그 오버헤드는 매우 작겠지만, 적용하기 전에 항상 테스트하고 측정해야 한다는 점을 명심해주세요.

이를 활성화하려면 bootstrap 함수에 다음 코드를 추가하면 됩니다:

val bootstrap = Runtime.enableRuntimeMetrics

#병렬 처리

이제 ZIO를 사용할 때 흔히 발생하는 문제인 무제한 병렬 처리에 대해 이야기해보겠습니다. ZIO의 일반적인 연산자 중 하나는 ZIO.foreach로, 컬렉션의 각 항목에 대해 효과를 실행할 수 있게 해줍니다. 결과를 수집할 필요가 없을 때는(예: 효과가 Unit을 반환하는 경우) 더 빠른 ZIO.foreachDiscard도 있습니다. 병렬로 작업을 수행하려면 ZIO.foreachPar 및 ZIO.foreachParDiscard와 같은 병렬 대응 연산자가 있습니다.

하지만 어떤 상황에서는 foreachPar가 foreach보다 느릴 수 있습니다. 어떻게 그럴 수 있을까요?

1,000개 요소가 있는 컬렉션에서 foreachPar를 실행하면 ZIO는 1,000개의 fiber를 생성하여 모두 CPU 시간을 놓고 경쟁하게 됩니다. 각 fiber가 수행하는 작업이 CPU 중심적이라면 코어 수보다 많은 fiber를 생성하는 것은 이점이 없습니다. 반대로, 모든 fiber를 생성하고 연결하는 데 필요한 기계적 오버헤드로 인해 성능 저하가 발생할 것입니다. Fiber가 I/O를 수행하는 경우 한 번에 많은 수를 생성하는 것이 의미가 있을 수 있지만, 다른 제한(예: DB 연결, 네트워크 등)에 부딪힐 가능성이 높으므로 제한을 두는 것이 안전할 수 있습니다.

foreachPar를 사용할 때 생성되는 fiber 수를 제어하려면 ZIO의 withParallelism 연산자를 사용할 수 있습니다.

ZIO
  .foreachPar(1 to 1000)(_ => doSomething)
  .withParallelism(16)

이 예제에서는 16개의 fiber가 생성되어 myList의 요소를 동시에 처리합니다. doSomething이 CPU 중심적이고 16개의 코어가 있다고 가정하면, 1,000개의 fiber가 동일한 작업을 수행하는 것보다 훨씬 더 나은 성능을 발휘할 것입니다.

withParallelism 연산자는 그 범위 내에서 실행되는 코드의 병렬 처리 수준을 조정합니다. 여기에는 부모로부터 이 설정을 상속받는 포크된 모든 자식 fiber가 포함됩니다. 따라서 애플리케이션 전반에 걸쳐 합리적인 기본 병렬 처리 수준을 설정하기 위해 메인 함수에서 withParallelism을 사용할 수 있으며, 필요에 따라 지역적으로 조정할 수 있습니다.

재미있는 사실: 이 글을 작성하면서 foreachPar의 구현을 확인했는데, 컬렉션 크기보다 높은 숫자 n으로 withParallelism을 사용할 때 여전히 n개의 fiber를 생성하고 있음을 발견했습니다. 이는 불필요한 작업입니다. 컬렉션의 항목 수만큼 fiber를 생성하면 됩니다. 이를 최적화하기 위해 PR을 열었으며, 다음 ZIO의 마이너 릴리스에 반영될 것입니다.

#Executor

Fiber를 생성하고 작업을 할당하면 이 작업은 결국 실제 스레드에서 실행됩니다. ZIO에서는 이러한 스레드를 생성하고 작업을 할당하여 CPU 효율성을 최대화하는 논리를 담당하는 것이 executor의 역할입니다. 여기서 선택할 수 있는 다양한 옵션을 살펴보겠습니다.

ZIO 2.1.0부터 기본 executor는 ZScheduler라고 불리며, 이는 본질적으로 Rust의 Tokio 스케줄러의 포트입니다. 이 글은 알고리즘을 자세히 설명하지만, 간략하게 요약하자면:

사용 가능한 코어 수와 동일한 수의 스레드를 생성합니다.
각 스레드는 실행할 작업의 로컬 큐를 가지며, 모든 스레드가 공유하는 전역 큐도 존재합니다.
Fiber가 effect를 포크할 때 새 fiber를 생성하여 현재 스레드의 로컬 큐에 추가합니다. 현재 스레드가 ZIO 스레드가 아닌 경우(예: 외부 스레드에서 unsafe.run을 호출하는 경우), 전역 큐에 추가합니다. 로컬 큐가 꽉 차면(크기가 제한됨) 작업의 절반을 가져와 전역 큐로 이동합니다.
그런 다음 슬리핑 중인 스레드가 있는지 확인하고, 찾으면 깨웁니다.
깨어나거나 현재 작업을 마친 후 스레드는 다음 작업을 다음과 같은 방식으로 찾습니다:
- 먼저 로컬 큐에서 가져옵니다.
- 로컬 큐가 비어 있으면 전역 큐에서 가져옵니다.
- 전역 큐가 비어 있으면 다른 스레드의 로컬 큐에서 작업을 훔쳐올 수 있는지 확인합니다. 훔칠 때는 다른 스레드의 로컬 큐의 절반을 가져옵니다.

이 프로세스는 입증되었고 ZIO 2가 출시된 이후로 효율적으로 작동하고 있습니다. 최근에 향상되기까지 했습니다. 그렇다면 왜 변경해야 할까요? 알아봅시다.

#블로킹

ZIO 2.0.x에서 기본 스케줄러는 기본적으로 자동 블로킹 기능이 활성화되어 있었습니다. 2.1.x에서는 비활성화되어 있으며 명시적으로 선택해야 합니다:

val bootstrap = Runtime.enableAutoBlockingExecutor

이 기능은 fiber가 블로킹 작업을 수행하고 있는지 감지하려고 하며, 감지되면 그 코드 위치를 기억해 두었다가, 나중에 그 코드가 다시 실행되면 자동으로 fiber 를 블로킹 스레드풀로 이동시켜 줍니다. 사용자가 블로킹 코드를 ZIO.blocking 또는 ZIO.attemptBlocking으로 래핑하는 것을 잊었을 때 executor가 대신 처리해주는 것이 목표입니다.

기본 executor에서 블로킹 코드를 실행하는 것은 좋지 않습니다. 왜냐하면 제한된 수의 스레드를 사용하므로 쉽게 모든 스레드가 블로킹되어 아무 작업도 수행하지 못하는 상황에 처할 수 있기 때문입니다.

이 기능의 문제는 fiber가 블로킹 코드를 실행하고 있는지 여부를 감지하는 것이 완벽하지 않은 휴리스틱이라는 점입니다. 간단히 말해서, 작업이 특정 임계값보다 오래 실행되면 "블로킹"으로 간주됩니다. 그러나 이는 실제로 블로킹된 것이 아니라 단순히 CPU 중심적일 수 있으며, 다른 이유로 인해 느릴 수도 있습니다(시작 직후 JVM 이 warm-up 이 되지 않았을 때 클래스 로딩이 시간이 걸려 블로킹 스레드풀로 이동된 경우를 본 적이 있습니다). 또 다른 문제는 블로킹 위치를 추적하고 매번 작업을 실행할 때 이를 확인하는 것이 오버헤드를 유발한다는 것입니다.

가능한 최고의 성능을 얻으려면 이 모드를 사용하지 않고 블로킹 코드를 블로킹 스레드풀로 명시적으로 이동하는 것이 좋습니다. 의심이 간다면 스레드 상태를 살펴보고 잠재적인 블로킹을 찾아내기 위해 프로파일러를 사용하십시오. 하지만 당신의 코드나 사용하는 라이브러리에 대해 확신이 없고, 더 안전하게 하기 위해 성능 페널티를 기꺼이 감수할 수 있다면, 자동 블로킹을 활성화하는 것도 충분히 괜찮은 선택지입니다.

#Executor 오버라이드

ZIO에서 꽤 놀랍고 많은 사람들이 알지 못하는 동작이 하나 있습니다. 블로킹 스레드풀로 작업을 이동할 때, fiber는 해당 코드를 실행한 후 기본 executor로 자동으로 돌아오지 않는다는 것입니다. 한번 fiber 가 블로킹 스레드풀에 들어가면, 그 fiber 는 끝날 때까지, 또는 내부 루프를 충분히 많이 실행하여 기본 executor 로 돌아갈 (yield) 때까지 블로킹 스레드풀에서 계속 실행됩니다.

사용 사례에 따라 이러한 동작이 좋을 수도 나쁠 수도 있습니다. Fiber가 블로킹 호출 후 즉시 종료되는 경우(예: DB 호출을 수행하고 클라이언트에 반환하는 경우), 스레드 이동을 피하는 것이 더 효율적입니다. 그러나 fiber가 장기 실행되는 경우(예: Shardcake의 엔터티 동작), 블로킹 스레드풀에서 많은 코드가 실행되어 많은 수의 스레드가 생성되고 성능이 저하될 수 있습니다. 그에 반해 Cats Effect는 기본적으로 자동으로 돌아오도록 선택한 것으로 보입니다.

하지만 이를 해결하는 간단한 방법이 있으며, executor를 명시적으로 설정하는 것입니다. 기본 executor를 오버라이드하면 블로킹 코드가 실행된 후 작업이 항상 해당 executor로 돌아옵니다. 그러나 기본 executor를 유지하고 싶다면 어떻게 해야 할까요? 간단히 말해서 기본 executor를 자체적으로 오버라이드할 수 있습니다!

val bootstrap =
  Runtime.setExecutor(Executor.makeDefault(autoBlocking = false))

이 간단한 줄은 블로킹 코드 실행 후 항상 기본 executor로 돌아오도록 보장합니다.

ZIO 2.1.2부터는 블로킹 후 이전 executor로 돌아갈지를 제어하는 플래그가 생겼습니다. 위의 해결책 대신 다음과 같이 할 수 있습니다:

val bootstrap =
   Runtime.enableFlags(RuntimeFlag.EagerShiftBack)

#대안 Executor

기본 executor를 변경하는 또 다른 이유는 새로운 대체 executor를 시도해보는 것입니다. 첫째, ZIO 2.1.x에서는 Loom에 기반한 새로운 executor가 추가되었습니다 (JDK21+에서만 사용 가능). 이 executor는 각 fiber 작업에 Loom의 가상 스레드를 할당합니다. 실제 스레드에서 이러한 가상 스레드를 실행하는 효율성은 Loom에 맡겨집니다.

이를 사용하려면 bootstrap 함수에 다음 코드를 추가하십시오:

val bootstrap = Runtime.enableLoomBasedExecutor

이는 반드시 테스트해봐야 할 흥미로운 대안입니다. 그러나 많은 fiber를 생성하고 연결하는 것을 테스트하는 ZIO 벤치마크에서 기본적으로 Tokio 기반 스케줄러가 Loom 기반 스케줄러보다 상당히 빠르다는 점을 참고하십시오.

최근 또 다른 가능성은 Kyo의 스케줄러입니다. 이는 최근에 kyo 0.9.3에서 독립적인 의존성으로 추출되었습니다. 아주 최근에 릴리즈 되었고 아직 실전에서 증명된 물건은 아니지만, 그 창시자 Flavio Brasil은 JVM에서 다양한 effect 시스템을 사용한 경험을 바탕으로 한 전문가이며 그의 스케줄러는 이러한 경험을 바탕으로 만들어졌습니다. 향후에 이를 시도해볼 계획입니다.

#Datadog에 대한 마지막 주의 사항

Datadog을 사용하는 사용자에게 마지막 팁을 드리겠습니다. Datadog은 코드를 자동으로 프로파일링하여 별다른 오버헤드 없이 작동하는 에이전트를 제공합니다. 저는 프로덕션에서 ZIO와 관련된 두 가지 플래그를 변경했습니다:

-Ddd.integration.throwables.enabled=false는 예외 프로파일링을 비활성화합니다. 왜 필요할까요? ZIO 2.0.x 버전부터 ZIO는 내부적으로 제어 흐름을 위한 예외를 사용합니다. 이는 매우 많은 예외를 발생시켜 프로파일러를 과부하시킬 수 있습니다. ZIO 2.1.x에서는 이러한 사용이 감소했지만 완전히 제거되지는 않았기 때문에 여전히 유효합니다.
-Ddd.integration.zio.experimental.enabled=true는 성능을 향상시키지는 않지만 Datadog 추적기가 ZIO fiber 간에 컨텍스트를 전달할 수 있게 해줍니다. 이를 통해 더 나은 추적을 할 수 있으며, 예를 들어 DB 호출을 API 호출에 연결할 수 있습니다. 저희도 프로덕션에서 이를 사용하고 있으며, 오버헤드가 없음을 확인했습니다. 아직 실험적인 옵션이고 공식 문서에도 없지만 잘 작동하고 있어 추천합니다.

오늘은 여기까지입니다! 도움이 되었기를 바랍니다.

머신러닝 엔지니어가 퍼즐 게임을 더 재미있게 만드는 방법

Wed, 29 May 2024 00:00:00 GMT

#쿠키런: 마녀의 성과 퍼즐봇

쿠키런: 마녀의 성(이하 '마녀의 성')은 탭(Tap to blast) 방식의 퍼즐을 풀어 쿠키들을 마녀의 성에서 탈출시키는 퍼즐 게임입니다. 데브시스터즈에서는 마녀의 성을 AI가 학습하여 플레이하는 강화학습 기반의 퍼즐봇을 만들어 게임 레벨 밸런싱에 사용해왔습니다. 전작이었던 또 다른 퍼즐게임인 쿠키런: 퍼즐월드에서도 퍼즐봇을 만들어 게임 밸런싱에 사용했었는데요, 이 때의 경험을 바탕으로 한층 더 정교한 퍼즐봇을 만들어서 사용할 수 있었습니다. 마녀의 성은 각 레벨마다 독창적인 매력을 가진 스테이지들로 이루어져있고, 퍼즐봇은 이러한 각각의 스테이지 (레벨) 를 하나의 단위로 하여 학습하고 플레이를 하게 됩니다.

#밸런싱과 폴리싱, 그리고 스테이지 평가 지표

퍼즐 게임에서 밸런싱의 핵심은 각 스테이지에서 유저들이 사용할 수 있는 제한 무브 수를 결정하는 것입니다. 각 스테이지에는 주어진 미션이 있으며, 이 미션을 제한된 무브 수 안에 모두 해결해야 다음 스테이지로 넘어갈 수 있습니다. 따라서 제한 무브 수가 적으면 게임이 어려워지고, 많이 주어지면 비교적 쉬워집니다. 기획팀과 게임 디자인팀에서 제작한 스테이지는 이러한 밸런싱 과정을 거쳐 유저들에게 선보여집니다.

폴리싱 단계도 유저들에게 스테이지를 선보이기 전에 필수적으로 거쳐야 합니다. 폴리싱(Polishing; 연마) 단계란 제작된 스테이지들을 직접 플레이해 보며, 유저들에게 더 나은 플레이 경험을 제공하기 위해 스테이지를 다듬는 과정입니다. 스테이지를 플레이해보고 아쉬운 점을 개선하는 작업입니다. 또한, 폴리싱 단계는 제작된 스테이지를 그대로 사용할 수 있을지 판단하는 중요한 과정이기도 합니다.

저희는 퍼즐봇의 이점을 극대화하기 위해 폴리싱 단계에서도 퍼즐봇 데이터를 활용하고자 했습니다. 결과적으로, 기존의 폴리싱 과정에서 발생할 수 있는 문제점을 보완하고 더 효율적으로 스테이지 제작 과정을 수행하기 위해 퍼즐봇 데이터를 활용하여 각 스테이지를 평가할 수 있는 "스테이지 평가 지표"를 만들었습니다. 본 글에서는 그 이야기를 들려드리려고 합니다.

요약하자면, 저희는 "스테이지 평가 지표" 를 통해 폴리싱 단계에서 제작된 스테이지를 그대로 출시할 수 있을지 판단할 기준을 제공하고자 했습니다. "좋은 스테이지"라고 말할 수 있는 유저의 행동을 기준으로 잡고, 그 행동 비율과 높은 상관관계를 보이는 지표를 만들었습니다. 이렇게 만들어진 스테이지 평가 지표는 실제로 데브시스터즈 내부에서 진행된 사내 테스트 데이터를 기준으로도 유의미하게 높은 상관관계를 보였습니다. 이 지표는 기존 수작업으로 진행되던 폴리싱 단계에서 데이터 관점의 시각을 제공하여 더 효율적인 폴리싱 수행이 가능하게 했습니다.

#지표의 필요성과 목표

기존의 폴리싱 과정은 [ 퍼즐맵 제작 → 플레이 후 피드백 → 부족한 점 보완 → 이후 밸런싱 과정 진행 ] 의 순서로 이루어집니다. 이러한 작업은 소수의 폴리싱 작업자의 직감에 의존적일 수 밖에 없고, 이로 인해 개인 성향에 따라 편향되기 쉽습니다. 또한 스테이지의 개수가 늘어남에 따라 폴리싱에 소모되는 시간이 비례하여 증가될 수 있다는 문제가 있습니다.

물론, 기획자 및 게임 디자이너분들의 감은 아주아주 중요한 요소이지만, 스테이지 제작 과정을 보다 효율적으로 확장하기 위해 폴리싱 단계에서의 추가적인 판단 기준이 될 수 있는 지표를 제공하고자 했습니다. 이는 보다 객관적인 성격의 지표로 사용이 가능하며 폴리싱 과정을 효율화 시키는데 도움이 될 수 있습니다. 정성적인 평가에 대한 의존성을 낮춤으로써, 하나의 레벨에 대해서 [ 여러 맵을 제작 → 지표를 통한 1차적인 판단 → 기획자 / GD 분들의 정성적 평가 → 폴리싱 ] 과 같은 방식으로 프로세스를 개선시킬 수 있습니다.

#스테이지 평가 지표

#기준이 되는 유저의 행동

스테이지 평가 지표는 유저들이 스테이지를 플레이했을 때의 반응을 예측할 수 있는 지표로 생각해볼 수 있습니다. 이를 위해 기준이 되는 유저의 행동을 설정해야 했습니다. 기획팀과의 논의 끝에 "게임을 클리어하지 못했을 때, 얼마나 높은 비율로 이어하기 및 하트 구매 후 재시도가 이루어지는지"를 기준으로 삼게 되었습니다. 이는 곧 게임 클리어에 실패했을 때, 결제를 해서라도 클리어하고 싶은 스테이지라는 뜻으로 해석할 수 있습니다.

게임 성공 시의 행동에 대해서는 실패 경험이 유저 경험에 더 큰 영향을 미치며 레벨이 진행될수록 실패 케이스의 비중이 커지기 때문에 기준에 포함시키지 않는 방향으로 결정했습니다.

스테이지 평가 지표는 이러한 '유저의 행동'을 예측할 수 있는 지표여야 한다(= 상관관계가 높다) 는 것을 목표로 두고 지표 제작 과정을 시작하게 되었습니다.

#스테이지 평가 지표를 위한 EDA - 쿠키런: 퍼즐월드 데이터

우선, 마녀의 성의 전작인 <쿠키런: 퍼즐월드> 의 실제 유저 플레이 데이터를 활용하여 스테이지 평가 지표를 만들기 위한 힌트를 얻고자 했습니다. 마녀의 성을 플레이한 유저 데이터를 사용할 수 있다면 더 좋았겠지만, 게임 런칭 전에 스테이지 평가 지표가 제작되어야 했기에, 오랜 기간 운영되어 유저 분석이 가능한 기존의 쿠키런: 퍼즐월드 데이터를 활용했습니다. 디테일한 인게임 로직은 차이가 있지만, "미션"과 "유저의 행동"은 퍼즐 게임이라면 어느 정도 공통적인 특성이 있을 것으로 판단했습니다.

우선, 유저가 게임 클리어에 실패했을 때 남는 기록은 "남은 미션 수" 밖에 없습니다. 제한된 무브 수를 다 사용했지만 남은 미션의 수가 0이 되지 못했다면 게임에서 실패한 것이기 때문입니다.

쿠키런: 퍼즐월드의 상위 50%, 하위 50% 스테이지들에 대한 남은 미션 수 분포 비교

위 차트는 기존에 정한 "유저의 행동" 비율을 기준으로 상위 50%에 해당하는 스테이지들(Good, 파란색)과 하위 50%에 해당하는 스테이지들(Bad, 빨간색)의 남은 미션 수 분포를 나타낸 것입니다. 남은 미션 수가 1인 지점에서 파란색이 약 25%였고, 이는 상위 50%에 해당하는 모든 스테이지의 평균을 냈을 때 남은 미션 수가 1개인 플레이 비율이 약 25%였다는 것을 의미합니다.

위 차트를 그리면서 상위, 하위의 극단적인 스테이지들을 가져온 것이 아니라 모든 스테이지를 포함시켜 단순 평균을 낸 것임에도 유의미한 차이가 발생했다고 판단되었습니다. 즉, 유저 행동의 비율이 높은 경우, 남은 미션 수가 적은 실패 플레이 비율이 더 높다는 것을 의미합니다. 전체 스테이지가 아닌 성공률을 기준으로 보았을 때나 미션별로 스테이지를 구분하여 보았을 때도 대부분의 경우 위 차트와 유사한 경향이 나타났습니다. 다만, 미션에 따라 총 미션 수에 큰 차이가 있었고, Good과 Bad(파란색, 빨간색)가 달라지는 지점에도 조금씩 차이가 있었습니다.

밀크 로드 미션 스테이지들 기준

팝핑 젤리 벌레 미션 스테이지들 기준

위 분석을 통해 "남은 미션 수가 적게 남은 플레이 비율이 얼마나 많은가"를 스테이지 평가 지표에서 활용하는 것이 합리적이라는 결론을 내렸습니다. 다음 문제는 "그러한 정도를 어떻게 측정할까"와 "총 미션 수에 따라 달라지는 디테일을 어떻게 반영할까"였습니다.

#스테이지 평가 지표 설계 및 분석

“남은 미션 수가 적게 남은 플레이 비율이 얼마나 많은가”를 두 가지 방식으로 활용해 보고자 했습니다. 첫 번째는 남은 미션 수의 분포가 얼마나 0에 가깝게 존재하는가, 두 번째는 총 미션 수 대비 남은 미션 수의 비율 혹은 남은 미션 수가 특정 갯수 이하인 플레이의 비율이 어느 정도인가의 기준이었습니다.

#첫 번째 기준: 남은 미션 수의 전체적인 분포가 얼마나 0에 가깝게 존재하는가

첫 번째 기준으로 남은 미션 수의 전체적인 분포가 얼마나 0에 가깝게 존재하는가를 평가하기 위해 다음과 같은 과정을 거쳤습니다. 먼저, 스테이지마다 총 미션 수가 다르고, 실패한 플레이 횟수도 다르기 때문에 정규화 과정을 거쳤습니다. 그리고 표준편차를 계산하는 방법에서 아이디어를 얻어, 남은 미션 수가 적은 경우에 높은 가중치를 주었습니다. 이를 단순하게 표현하면, 하나의 스테이지에 대해 남은 미션 수 별로 (남은 미션 수 별 가중치) X (플레이 종료 시 해당 미션 수가 남은 유저 플레이의 횟수=플레이 카운트)를 합한 값을 정규화하여 첫 번째 지표로 삼았습니다.

#두 번째 기준: 특정 비율 혹은 특정 개수 관점의 지표

두 번째 기준은 특정 비율 또는 특정 개수 관점의 지표입니다. 예를 들어, 20%를 기준으로 한다면 스테이지마다 주어진 총 미션 수 대비 20% 이하의 미션 수만 남긴 플레이의 비율을 계산하는 것입니다. 총 미션 수가 100개인 스테이지라면, 제한된 무브 수를 다 사용했을 때 20개 이하의 미션만 남긴 플레이의 비율을 계산합니다.

그런데 총 미션 수 자체가 적은 경우에는 비율을 기반으로 설정하는 것이 어렵습니다. 예를 들어 총 미션 수가 2개인 스테이지에서 남은 미션 수가 1개라면 비율을 50% 로 설정하여 지표화하는 것이 의도를 잘 반영하기 힘듭니다. 따라서 총 미션 수가 특정 개수 이상이면 비율을 기준으로, 특정 개수 이하라면 절대적인 미션 수를 기준으로 사용하고자 했습니다.

결과적으로 지표의 기준으로 사용할 [총 미션 수], [기준 미션 수], [기준 미션 수 비율]의 세 가지 값을 찾아야 했습니다. 기획팀의 도움으로 각 기준의 적당한 범위를 설정하고 Grid Search를 통해 최적화를 진행했습니다. 이 세 가지 값을 바꿔가면서 나온 플레이 비율과 유저의 행동 비율 사이의 상관관계가 높은 것을 찾는 것이 목표였습니다.

#상관관계 분석

위의 두 관점에서 설계한 지표들과 유저의 행동 사이의 상관관계는 아래와 같았습니다.

전체 분포 관점 지표와 “유저의 행동” 사이의 상관관계 : 0.49 ~ 0.51
특정 비율 or 개수 관점 지표와 “유저의 행동” 사이의 상관관계:
- 총 미션 수 기준 = 12 / 기준 미션 수 = 2 / 기준 미션 비율 = 0.2 일 때 0.51 ~ 0.54
- 이는 곧, 총 미션 수가 12 이하일 때는 남은 미션 수의 개수가 2 이하인 플레이 비율에 해당하며, 총 미션 수가 12 초과일 땐 남은 미션 수의 비율이 (총 미션 수 대비) 20% 이하인 플레이 비율에 해당합니다.

하지만 총 미션 수가 너무 적은 경우(초록색 원) 경향에서 벗어나는 케이스가 다수 발생했습니다. (색이 어두울 수록 총 미션 수가 적은 스테이지) 따라서 이를 보완하기 위해 총 미션 수가 너무 적을 때는 전체 분포 관점 지표를 사용하는 것으로 변경하였습니다. 최종적으로, 총 미션 수가 3개 이하일 때 전체 분포 관점 지표를 사용했을 때 상관관계가 0.56 ~ 0.57의 값을 보였습니다.

#스테이지 평가 지표 정의

위의 과정으로부터 얻은 스테이지 평가 지표의 정의를 정리해보자면 다음과 같습니다. 아래에서 언급하는 "클리어 실패"란 제한된 무브 수를 모두 소모했음에도 남은 미션 수가 하나 이상인 경우를 의미합니다. 그리고 스테이지별로 총 미션 수가 각각 다르기 때문에 총 미션 수 기준으로 구분하여 정의합니다.

스테이지 평가 지표 = 아래 각 조건별로

총 미션 수가 3 이하인 스테이지 :
- 전체적인 남은 미션 수의 분포가 얼마나 0에 가까운지 (전체 분포 관점 지표)
  - [ 남은 미션 수 별 가중치 x 플레이 카운트 ]의 합
- 계산 방법은 아래와 같습니다.

총 미션 수가 4 이상 12 이하인 스테이지 :
- 남은 미션 수가 2 이하인 플레이의 비율
- 계산 예시
  - 총 미션 수가 8개인 스테이지에서 (4 ≤ 8 ≤ 12)
  - 실패한 플레이가 100번이고, 이 중 남은 미션 수가 2 이하인 플레이가 25번 있었다면
  - 스테이지 평가 지표는 25/100 = 0.25 로 계산
총 미션 수가 12 초과인 스테이지 :
- 남은 미션 수가 총 미션 수 대비 20% 이하인 플레이의 비율
- 계산 예시
  - 총 미션 수가 100개인 스테이지에서 ( 100 > 12 )
  - 그리고 실패한 플레이가 100번 있을 때,
  - 남은 미션 수가 20개 (100개 * 0.2) 이하인 플레이가 30번이라면,
  - 스테이지 평가 지표는 30 / 100 = 0.3 으로 계산

#보조 지표

위에서 설계된 스테이지 평가 지표는 기본적으로 게임에 실패했을 때 남은 미션 수의 분포를 기준으로 합니다. 그런데 모든 실패한 경우에 남은 미션 수가 하나이거나, 남은 미션 수에 상관없이 한 무브만 더 사용하면 클리어할 수 있는 특성을 가지는 스테이지라면 어떻게 될까요? 당연히 남은 무브 수의 분포를 통해 만든 스테이지 평가 지표의 신뢰도가 떨어질 수밖에 없습니다. 이를 위해, 스테이지 평가 지표의 신뢰도를 표현할 수 있는 보조 지표를 설계하게 되었습니다.

단, 이는 별도의 분석 과정이 아닌 논리적인 흐름에 따라 설계한 지표입니다. 처음 발단이 된 생각처럼, 이 보조 지표가 아주 낮을 때 스테이지 평가 지표를 신뢰하기 힘들 수 있다는 식으로 접근하는 것이 맞다고 생각되었습니다. 또한, 실제 런칭 이후 효과적인지에 대한 여부 판단이 필요합니다.

보조 지표 = 퍼즐봇 데이터 기준, '제한된 무브 수 시점에서의 남은 미션 수'와 '모든 미션을 클리어할 때까지 추가로 소모된 무브 수' 간의 상관관계

Pearson correlation (value based)와 Spearman correlation (rank based)의 평균값을 사용

(참고) 퍼즐봇은 제한된 무브 수를 넘어서까지 게임을 플레이할 수 있음

#결과

본 스테이지 평가 지표가 폴리싱 단계에서 사용되는 것을 목표한다면 실제로 스테이지들이 출시되기 전에 스테이지 평가 지표의 계산이 가능해야 합니다. 따라서 먼저 퍼즐봇의 플레이 데이터를 통해 스테이지 평가 지표를 계산하고, 사내 테스트 데이터에서 유저의 행동을 확인하는 과정을 통해 지표를 검증하였으며, 그 결과는 아래와 같습니다.

위 차트에서 하나의 점은 하나의 스테이지를 의미하며, x 축은 스테이지 평가 지표 값, y 축은 기준이 되는 “유저의 행동” 비율을 의미합니다.

실제로, 스테이지 평가 지표가 증가함에 따라 기준으로 삼은 유저의 행동 비율이 증가함을 볼 수 있었습니다. 또한, 스테이지 평가 지표가 0.5 이상인 스테이지들만 제한해서 본다면,

스테이지 평가 지표와 유저의 행동 사이에 더 뚜렷한 상관관계가 있음을 확인할 수 있었습니다. (Pearson, Spearman 상관관계 기준) 0.55~0.65 정도의 상관관계 값을 가졌습니다.

즉, 퍼즐봇 데이터로만 계산된 스테이지 평가 지표가 사내테스트 결과 유저의 행동과 유의미한 상관관계를 보였습니다. 다만, 보조 지표의 경우 경향성을 충분히 확인하기 위한 데이터는 부족한 상태라고 결론지었습니다. 비교 대상 스테이지들 간에 "스테이지 평가 지표의 수치가 비슷할 때에, 보조 지표의 값에 차이가 난다면 어떠한 현상이 있는가"가 중요하므로 지금보다 더 많은 스테이지가 있을 때 확인이 가능할 것이라고 판단합니다.

#Discussion

사내테스트 데이터 기준으로, 퍼즐봇 데이터로 만든 스테이지 평가 지표와 유저의 행동 비율 사이의 상관관계가 유의미했습니다. 이 결과를 바탕으로 기존의 프로젝트 수행 목적인 “폴리싱 단계에서의 도움”을 주기 위한 역할을 수행할 수 있을 것으로 생각됩니다.

쿠키런: 퍼즐월드 데이터로 만든 스테이지 평가 지표와 유저의 행동 비율 사이의 상관관계와 거의 유사한 정도를 보였습니다. (다만 게임이지만) 유저 데이터로 만든 지표와 퍼즐봇 데이터로 만든 지표가 거의 유사한 정도의 성능을 보였다는 점은, 성공률을 떠나서 퍼즐봇의 플레이 패턴이 유저의 플레이 패턴과 유사한 지점이 있고 이는 곧 플레이 패턴이 맵의 고유한 특성 자체(맵, 기믹, 미션 등)에서 나올 수 있음을 시사합니다. 즉, 더 좋은 맵이라는 개념이 존재할 수 있을 것이라 생각됩니다.

#한계

본 모델링 과정에는 한계가 다수 존재합니다. 퍼즐월드 유저 데이터를 기준으로 최적화한 지표가 마녀의 성 퍼즐봇 데이터에서도 똑같이 유의미할 것이라고 보장할 수 없습니다. 따라서 스테이지 평가 지표 계산 시 필요한 총 미션 수 기준, 남은 미션 개수 기준 등을 새롭게 최적화할 필요가 있습니다. 또한, 사내 테스트 데이터에 대한 검증 결과가 실제로도 유효할 것이라고 판단하기 어렵습니다. 유저의 행동 기준이 “결제”와 직접적으로 연관되어 있는 것에 비해, 사내 테스트는 결제에 대한 심리적 허들이 낮았을 것입니다. 또한 기준이 되었던 유저의 행동, “게임 실패 시 이어하기 및 하트 구매 후 재시도”가 분명 게임 운영 상 좋은 판단 기준이 될 수 있지만, 절대적이고 유일한 기준은 아닙니다. 이러한 유저의 행동을 100% 예측할 수 있다고 해서, 예측 결과가 높은 스테이지”만” 사용하는 것이 항상 좋다고 볼 수는 없습니다.

#마무리

위와 같이 한계가 분명히 존재했던 스테이지 평가 지표의 제작 과정이었지만, 실험 과정에서 유의미하다고 판단될 정도의 결과를 확인할 수 있었습니다. 또한 이 지표의 제작은 마녀의 성 게임의 런칭 이전 시점에 이루어진 만큼, 지표 자체의 개선과 유저 데이터의 지속적인 모니터링을 통해 점진적으로 개선 중입니다.

머신러닝 엔지니어로서 게임에 대한 이해도나 게임을 바라보는 시각에 한계가 있을 수 있다고 생각합니다. 하지만 오히려 그렇기 때문에 데이터의 관점으로 게임을 바라보는 시각은 마녀의 성 팀에게 큰 도움이 될 수 있었을 것이라 생각합니다. 부족한 부분도 많았지만, 직군과 역할에 상관없이 게임의 성공이라는 공통된 목적을 가지고 새로운 지표를 만들어낸 경험은 정말 뜻깊은 경험이었습니다. 이처럼 다양한 사람들의 노력이 들어간 쿠키런: 마녀의 성이 더 많은 사람들에게 사랑받을 수 있다면 그것만큼 보람찬 일도 없을 것입니다. 앞으로도 데브시스터즈와 쿠키런: 마녀의 성에 많은 관심 바랍니다!

세계 최초로 cert-manager 버그를 발견하고 해결하기

Tue, 27 Feb 2024 00:00:00 GMT

안녕하세요, 데브시스터즈 진저랩 인프라셀에서 데브옵스 엔지니어로 일하고 있는 이상유입니다.

여러분은 Let’s Encrypt를 알고 계시나요? 자세히 아는 것이 아니라도, SSL/TLS 인증서를 무료로 발급해 주는 서비스라고 많은 분들께서 한 번쯤은 들어 보았을 것이라고 생각합니다.

데브시스터즈에서는 쿠버네티스 환경에서 통신 암호화를 위해 Let’s Encrypt 인증서를 사용하고 있는데요, 최근 흥미로운 이슈를 발견하여 오픈소스 기여까지 하게 된 사례가 있어 이 글을 통해 이야기를 풀어보고자 합니다.

#네가 왜 거기서 나와?

지난 2월 13일, 설 연휴를 보내고 돌아온 인프라셀에 한 가지 요청이 들어옵니다. 개발 서버에 접속이 되지 않는데, 확인을 부탁드린다는 요청이었습니다.

연휴 직후였기 때문에 사람이 개입한 변경사항도 존재하지 않던 시점이었기에, 무엇이 문제일까 확인하던 도중 아래와 같은 화면을 보게 되었습니다.

DST Root CA X3이 포함된 Chain을 사용하고 있는 Cert Chain 스크린샷

2년 전인 2021년 9월 말 인증서가 만료된 DST Root CA X3가 서명한 인증서가 서빙되고 있었는데, 저희는 후술할 접속 불가 이슈 때문에 명시적으로 해당 체인을 사용하지 않도록 설정해 둔 상태였습니다.

그렇다면 왜 2년 전에 만료된 CA 인증서를 Trust Anchor으로 하는 인증 체인이 지금, 그것도 명시적으로 해당 체인을 사용하지 않도록 설정한 곳에 나타난 걸까요? 그 이야기를 하기 위해서는 전후 맥락을 알아보아야 합니다.

#Let’s Encrypt의 Chain of Trust

2024년 2월 13일 현재, Let’s Encrypt의 Chain of Trust는 다음과 같습니다.

Ref: Let's Encrypt Chain of Trust

ECDSA key를 사용하는 인증서(파란색)들은 이 내용을 풀어나가는데 큰 관계가 없기 때문에, 여기에서는 RSA key를 사용하는 인증서(주황색)에 조금 더 주목해보겠습니다. 아래와 같이, 2가지의 Chain of Trust가 만들어지는 것을 알 수 있습니다.

DST Root CA X3 → ISRG Root X1 → Let's Encrypt R3 → Client Certificate
ISRG Root X1 → Let's Encrypt R3 → Client Certificate

특기할 만한 점은 바로, 앞서 만료되었다고 이야기했던 DST Root CA X3이 아직도 Chain에 들어 있다는 점입니다. 만료된 인증서라면 두 체인 모두에서 Trust Anchor는 ISRG Root X1 일 것인데, 왜 굳이 제거하지 않는 것일까요?

#무시할 수 없는 과거

왜 DST Root CA X3가 지금까지 체인에 포함되는지를 알기 위해서는 Let’s Encrypt의 역사를 조금 살펴보아야 합니다.

2014년 11월 대중에 Let’s Encrypt가 처음으로 공개되었지만, 이 시점의 Let’s Encrypt는 아직 Trusted CA가 아니었습니다. 때문에 당시 이미 널리 신뢰받고 있던 IdenTrust로부터 Cross-Sign을 받아 인증서를 발급하는 한편, 자신들의 CA를 만들어 Trusted CA에 등록하는 절차를 밟아나갔습니다.

그렇게 시간이 지나 2020년 말, IdenTrust로부터 서명받을 때 사용된 DST Root CA X3인증서가 만료되기까지 1년 정도가 남은 시점이 되었습니다. 이 당시 Let’s Encrypt의 Root CA 인증서, ISRG Root X1은 주요 소프트웨어에서 Trusted CA가 되어 있었습니다.

하지만 그게 모든 기기에서 신뢰한다는 의미는 아니었습니다. Trusted CA가 소프트웨어 업데이트로만 갱신되는 경우, 업데이트 자체가 아예 발생하지 않았을 경우에는 아직 ISRG Root X1이 신뢰받고 있지 않을 가능성이 있습니다.

그리고 안타깝게도 위와 같은 사례로 인해 영향을 받는 경우는 적지 않았습니다. 안드로이드 7.1 미만에서 해당 문제가 발생하는데, 2020년 12월 기준 영향을 받는 사용자는 전체 안드로이드 사용자의 2/3 수준이었습니다. 무시할 수 없는 정도의 기기에서 문제가 발생하는 것이었기에, Let’s Encrypt 커뮤니티에서는 이를 해결할 수 있는 창의적인 방법을 고안해 내었습니다.

#Root CA 인증서와 Trust Anchor

우리는 흔히 인증 체인의 가장 위에 있는 것을 Root CA 인증서라고 부르고, 이것 자체가 인증을 해 준다고 오해합니다. 하지만 실제로는 조금 다릅니다.

실제로 인증 체인을 검증하는 데에는 Trust Anchor를 사용합니다. 이것은 일반적으로는 Root CA의 public key와 해당 Key의 Identity의 조합입니다. 우리가 Root CA의 인증서를 사용하는 것은, 이것이 Trust Anchor로서 필요한 모든 데이터를 다 가지고 있는 포맷이기 때문입니다. 그렇기에, 인증서 파일을 불러와서 Trust Anchor를 형성할 때 그 인증서의 만료일 검증을 하는 것은 구현체의 자율입니다. 인증서가 만료되었다는 것은 해당 Public Key와 Identity의 pair에 대한 서명의 유효기한이 다했다는 것이지, 우리가 필요로 하는 Public Key와 Identity가 더 이상 유효하지 않다는 의미는 아니니까요.

때문에 Trust Anchor으로 사용되는 CA 인증서의 만료일을 검증하는 구현체도 있고, 아닌 구현체도 있는데, 안드로이드의 경우에는 이를 검증하지 않습니다. 적어도 안드로이드에 한해서는, DST Root CA X3 라는 Trust Anchor는 업데이트 등으로 인증서 자체가 제거되지 않는 이상 영구히 유효한 것입니다.

이러한 창의적인 방법을 사용해서, 만료되는 DST Root CA X3이 ISRG Root X1에 서명하여 인증 체인을 구성한 것이 위 (1)번 체인입니다. 이 cross-sign은 DST Root CA X3이 만료되는 21년 9월부터 3년간, 즉 2024년 9월까지 유효하도록 설정되었습니다.

반대로 CA 인증서의 만료일을 검사하는 경우에는 동작이 조금 다릅니다. 이들의 경우에는 DST Root CA X3은 더 이상 유효한 Trust Anchor가 아니지만, 그 하위에 ISRG Root X1 이 있고 이는 Trust Anchor에 포함되어 있습니다. 때문에 일반적인 경우 (1)번 체인의 인증서를 내려보내도 (2)번 체인처럼 동작하여 정상적으로 신뢰 체인을 구성합니다. 일반적인 경우라면요.

문제는 일반적이지 않은 경우가 있다는 것입니다. 앞에서 접속 불가 이슈가 있었다는 이야기를 기억하시나요? 구버전 boringSSL의 경우 기본 설정상 (1)번 체인을 받았을 때 DST Root CA X3이 valid하지 않다면 무조건 신뢰 체인 구성에 실패합니다. 이 동작을 다른 구현체와 유사하게 설정하는 커밋이 있지만, boringSSL과 같은 라이브러리는 보통 직접 사용하는 경우가 드물죠. 저희같은 경우에는 사용중인 라이브러리에서 boringSSL 구버전을 사용하여 문제가 발생하였습니다. 다행히도, 이 케이스에서는 가장 상위 계층의 인증서가 DST Root CA X3에 의해 서명되지 않도록 하여 문제를 해결할 수 있습니다.

#문제로 돌아와서

이러한 접속 불가 히스토리가 있었기 때문에, 저희는 cert-manager에서 인증서의 인증 체인을 명시적으로 (2)번 체인인preferredChain: ISRG Root X1으로 설정하여 사용하고 있었습니다.

그런데 지금 보이는 동작은 이 preferredChain 설정값이 무시되고 DST Root CA X3 을 포함하는 (1)번 체인을 사용하는 동작입니다.

테스트 결과, preferredChain 설정값에 따라 다음과 같이 동작이 달라지는 것을 확인하였습니다.

preferredChain이 아예 설정되지 않는다면 ISRG Root CA X1 인증서 체인을 사용
preferredChain: DST Root CA X3이라면 정상적으로 DST Root CA X3 인증서 체인을 사용
preferredChain: ISRG Root X1이라면 DST Root CA X3 인증서 체인을 사용

명시적으로 preferredChain: ISRG Root X1을 지정하는데도 DST Root CA X3 체인을 사용하는데, preferredChain 을 설정하지 않는다고 늘 ISRG Root CA X1체인을 반환할 것이라고 확신할 수 없다고 판단하였습니다. 그렇다면 왜 이런 문제가 발생하는지 찾아봐야겠지요.

#안녕, DST Root CA X3

이 섹션의 내용에 대해 더 자세하게 알고 싶으시다면, Let’s Encrypt의 공식 블로그를 참고해 주세요.

앞서 이야기했던 Cross-sign의 유효기한은 2024년 9월 30일까지입니다. 원래 2021년 9월까지 서명했던 것을 하위 호환성 문제로 인해 3년 연장했던 것이고, 이제는 문제가 되는 기기의 점유율이 많이 줄어 (안드로이드 점유율 중 6% 수준) 더 이상 이 cross sign의 필요성이 크지 않습니다.

cross sign 인증서를 매번 통신을 수립할 때마다 서버에서 클라이언트에 내려주는 것도 불필요한 오버헤드이기 때문에, 더 이상 cross-sign을 하지 않고 ISRG Root X1을 사용하는 것이 목표인데, 그렇다고 한순간에 이걸 발급하지 않아버리면 혼란이 올 가능성이 높겠죠.

그래서 Let’s Encrypt에서는 단계적인 DST Root CA X3 deprecate 계획을 수립해 두었는데, 그 첫 번째 페이즈가 지난 2월 8일 적용되었습니다. 구체적으로, 기존에는 DST Root CA X3이 Default chain이었고, ISRG Root X1이 Alternate Chain 인증서로 제공되었는데, 이를 2월 8일부터 ISRG Root X1을 Default Chain으로 변경하고 DST Root CA X3 를 Alternate으로 제공하도록 변경되었습니다.

시기적으로 이 변경사항이 문제를 발생시킨 원인으로 가장 의심됩니다. 하지만 Default Chain과 Alternate Chain이 무엇이길래 지금 겪는 문제를 발생시키는지 조금 더 깊이 확인해 볼 필요가 있습니다.

#Automated Certificate Management Environment

Default Chain과 Alternate Chain이 어떻게 내려오는지 알려면 인증서 발급 과정이 실제로 어떻게 이루어지는지를 보아야 합니다. Let’s Encrypt와 같은 자동 인증서 발급 서비스는 ACME(Automated Certificate Management Environment) API를 사용하는데요, 이는 RFC 8555로 정의되어 있습니다.

해당 문서 7.4.2번 섹션을 보면, ACME 서버에서는 동일한 end-entity 인증서(=Let’s Encrypt에서의 Subscriber Certificate)를 포함하여 서로 다른 인증 체인을 사용하는 alternate 인증서를 지정할 수 있다고 되어 있습니다. 이 중 어떤 인증서를 사용할 것인지는 각 클라이언트의 재량입니다.

실제로 해당 방식으로 통신이 이루어지는지 확인하기 위해, Let’s Encrypt 커뮤니티에서 가장 폭넓게 사용되는 Certbot을 사용하여 새 인증서를 발급하여 봅니다.

Certbot은 기본적으로 디버그 로그를 남기는데, 이 안에서 ACME 서버와 통신하는 HTTP request와 response를 볼 수 있습니다.

로그를 확인하면 다음과 같습니다.

ISRG Root X1을 최상위 인증서로 사용하는 체인

ISRG Root X1을 최상위 인증서의 Issuer Common Name으로 하는 인증서 체인이 하나 내려오고, Link 헤더를 통해 alternate 인증서가 내려오는 것을 확인할 수 있습니다

이어지는 로그에서 Alternate 인증서를 불러오는 것을 확인할 수 있습니다.

DST Root CA X3을 최상위 인증서로 사용하는 체인

다음과 같이 최상위 인증서의 Issuer Common Name이 DST Root CA X3인 인증서 체인이 내려옵니다.

여기까지의 분석을 통해, Let’s Encrypt에서는 의도한 대로 인증서를 발급하고 있음을 확인할 수 있었습니다. 그렇다면 이제는 이 인증서를 받아와 실제로 secret을 만들어주는 클라이언트를 살펴볼 때입니다.

#구현별로 서로 다른 휴리스틱

ACME 클라이언트는 Certbot이나 cert-manager 이외에도 acme.sh 등이 존재하고, traefik이나 caddy와 같은 HTTP reverse proxy 소프트웨어에서 자체적으로 제공하고 있기도 합니다.

여기에서는 certbot과 지금 인프라셀에서 사용중인 cert-manager를 서로 비교하여 보겠습니다.

Certbot에서 Preferred Chain을 고르는 로직은 다음과 같습니다.

Ref: Github Certbot Repository

각 인증서 체인에서, 가장 마지막 (인증 체인에서 root와 가장 가까운) 인증서를 골라 해당 인증서 체인에서 Issuer의 Common Name을 추출, 이를 입력받은 값과 비교하는 것을 확인할 수 있습니다.

반면 cert-manager는 구현이 조금 다른데요,

Ref: Github cert-manager Repository

cert-manager의 경우 default chain을 제외한 alt chain 중에서, 각 체인의 모든 인증서를 순회하며 Issuer CN을 추출, 이를 입력받은 값과 비교하는 것을 확인할 수 있습니다.

로직을 분석함으로서 두 가지 디자인 선택이 cert-manager에서 잘못된 인증서 체인을 선택하도록 하는 문제를 만들었다는 것을 알 수 있었습니다.

우선 Alternate Chain을 선택할 때 Default Chain은 탐색 대상에서 제외한다입니다. 2월 8일 이전에는 Default Chain이 DST Root CA X3이었기 때문에 preferredChain이 ISRG Root X1인 경우 정상적으로 의도한 인증서 체인이 발급되었습니다. 하지만 지금은 Default Chain이 ISRG Root X1이기에, 이 체인의 인증서가 발급되기를 기대하였으나 preferredChain을 지정할 경우 이 체인은 아예 탐색 대상이 되지 않습니다.

다음으로, 모든 중간 인증서의 Issuer CN을 Alternate Chain 탐색 대상으로 삼는다 입니다. 지금 Alternate Chain인 DST Root CA X3 chain에도 ISRG Root X1을 Issuer으로 가지는 인증서가 존재합니다. 때문에 preferredChain을 ISRG Root X1으로 설정한 경우 해당 인증서가 조건을 충족시켜 DST Root CA X3 체인의 인증서를 반환하게 됩니다.

결론적으로,

Let’s Encrypt에서 하위 호환을 위해 제공하던 인증 체인을 deprecate하였고
해당 변경사항이 cert-manager에서 버그가 발생할 수 있는 조건을 트리거하였고
해당 버그가 발생해도 일반적으로는 문제가 없지만, 하필이면 Trust Anchor 인증서의 유효기간을 검증하고 무조건 topmost 인증서를 Trust Anchor을 통해 인증하려고 하는 구현체를 사용하였기에

발견하게 된 버그라고 할 수 있겠습니다.

#첫 오픈소스 기여

보통 제가 문제를 찾았을 때 즈음에는 누군가 이슈를 만들어 두던데, 이번 케이스에서는 아니었습니다. 문제를 확인했을 당시 Let’s Encrypt 커뮤니티 포럼이나 cert-manager 레포 중 어느 곳에도 리포팅이 되지 않은 상태였는데, 아마도 굉장히 특정한 상황에만 서비스 장애로 이어지는 문제였기에 영향을 받은 사람이 그리 많지 않았던 것으로 추정중입니다.

문제 리포팅을 하려고 보니, 이미 코드 분석도 완료한 시점에서 그리 어려운 변경사항이 아니리라고 판단되었습니다. 그렇다면 굳이 이슈 만들어두고 수정될 때까지 기다리는 것보다, 내가 PR을 올리는 게 낫지 않을까? 하는 생각에, 바로 PR을 올려 보았습니다.

개인 계정이어서 프로필을 살짝 가렸습니다. 원본이 궁금하시다면 여기를 참고해 주세요.

리뷰를 기다리며 저는 제가 코드 컨벤션 같은 것을 잘 지켰는지 등을 걱정했는데요, 이는 기우로 끝났습니다.

오히려 cert-manager의 메인테이너 분들은 사용자들이 기존 buggy한 구현에 의존하고 있을 가능성과 그로 인한 호환성 문제를 더 주의깊게 고려하시더라고요. 저는 생각지도 못한 부분이었고, 이런 고민을 한다는 것이 굉장히 인상깊었습니다.

여담으로, 이 PR을 올리고 하루 뒤 동일한 이슈가 cert-manager 레포에 리포팅되고, 5일정도 지나서 Let’s Encrypt 커뮤니티에도 사례가 공유되었습니다. 저희가 문제를 좀 더 빠르게 경험한 것은 맞는 것 같습니다.

#Wrap-Up

cert-manager 사용 중, 설정값과 실제 발급된 인증서의 인증 체인이 다른 문제를 발견하여 분석하여 보았습니다.
분석 결과 cert-manager에 존재하였으나 지금까지는 발현되지 않은 버그가 최근 Let’s Encrypt의 Default Certificate Chain 변경에 의해 발현되는 것을 확인하였고, 이를 ACME 스펙, 실제 통신 내용, 그리고 코드 확인으로 검증하였습니다.
분석한 결과를 바탕으로, cert-manager에 PR을 제출하여 머지되었습니다.

커뮤니티 리포팅된 사례 중 하나는 해당 버그로 장애가 발생했다고도 적혀 있었는데, 저희는 운 좋게 개발 환경에서 이슈를 발견하여 서비스 영향이 없었다는 점이 정말 다행이었습니다.

문제를 조사하면서 평소에 개인적으로도, 업무적으로도 많이 사용하는 Let’s Encrypt가 어떻게 동작하는지 조금 더 깊이있게 볼 수 있었던 것이 특히 기억에 남습니다.

긴 글 읽어주셔서 감사합니다.

스크립트 툴의 장점만 모았다! zx로 업무 자동화하기

Tue, 17 Oct 2023 00:00:00 GMT

안녕하세요. 데브시스터즈에서 프론트엔드 엔지니어로 일하고있는 김준영입니다. 이번 글에서는 자바스크립트에 익숙한 개발자가 자동화 스크립트를 편하게 작성할 수 있게 해주는 zx 라이브러리를 소개하려고 합니다.

#들어가기에 앞서

저는 업무 자동화 작업을 참 좋아합니다. 아래와 같은 여러 장점이 있기 때문입니다.

지루한 반복 업무를 더 이상 하지 않아도 된다는 편안함
개발자 다운 방식으로 문제를 해결했다는 뿌듯함
더 중요한 문제에 집중할 수 있음
오타 등 단순 실수에 신경쓰지 않아도 됨

스크립트를 통해 어떤 작업을 자동화 할 수 있고, zx 는 다른 선택지와 비교하여 어떤 장점이 있는지 살펴보겠습니다.

이 글은 아래와 같은 분들을 대상으로 작성하였습니다. 🙍‍♀️🙎‍♂️

- 반복 업무를 자동화하고 핵심 로직 개선에 집중하고 싶은 분
- 스크립트 작성은 처음이지만 새롭게 도입하고 싶은 분
- 쉘 스크립트 사용 경험이 있으나 더 편한 도구를 찾고 있는 분

#쉘 & 쉘 스크립트

쉘(shell)은 사용자가 OS 의 기능을 사용할 수 있도록 하는 사용자 인터페이스입니다. 사용자가 작성한 명령어를 커널이 이해할 수 있는 형태로 변환해 줍니다. 대표적인 쉘로는 bash, csh, zsh 등이 있습니다.

쉘 스크립트(shell script)는 쉘의 명령어들을 이용해 작성하는 프로그래밍 스크립트 언어입니다. 이를 통해 반복적인 작업을 자동화하거나 복잡한 작업을 단순화할 수 있습니다. 그러나 다소 복잡하고 생소한 문법을 가지고 있다는 단점도 있습니다. 아래 내용에서 zx 는 이러한 단점을 어떻게 보완하였는지 소개하려고 합니다.

Linux Shell

#zx란?

zx는 자바스크립트를 기반으로 쉘 명령어를 동시에 사용할 수 있는 라이브러리입니다. (ZX 공식 페이지) 그렇기에 자바스크립트와 쉘 스크립트가 각각 가지고 있는 장점을 동시에 누릴 수 있는 유용한 도구 입니다. bash 또는 node.js 를 단독으로 사용하여 스크립트를 작성하는 상황과 비교해서 zx 의 장점을 보여드리도록 하겠습니다.

#장점 1) JSON 조작의 편의성

JSON은 개발 영역 전반에서 쓰이고 있는 데이터 포맷입니다. 그러나 bash 에서는 JSON 데이터를 다루기에는 불편한 부분이 있습니다. 예시를 통해 zx 를 사용할 때와 비교해 보겠습니다.

bash 에서는 다양한 자료구조를 지원하고 있지 않아 JSON 데이터도 문자열의 형태로 관리하게 됩니다.

DATA = '{
  "users": [
    {
      "id": 1,
      "name": "John",
      "contacts": {
        "email": "john@example.com",
        "phone": "123-456-7890"
      }
    }
  ]
}'

DATA에서 이름이 John인 객체를 찾아 email을 출력하기 위해서는 아래와 같은 코드가 필요합니다.

JOHN_EMAIL = $(echo "$DATA" | jq -r '.users[] | select(.name == "John") | .contacts.email')
echo 'John's Email: $JOHN_EMAIL'

예시처럼, 쉘 스크립트를 통해 JSON 데이터를 다룰 때에는 몇 가지 단점이 있습니다.

데이터 구조가 다양하지 않아 jq 라는 별도의 도구 필요
도구를 사용해도 여전히 복잡한 코드 작성 (여러 개의 | 사용 필요)
문자열 로 명령어를 작성하는 방식의 불편함

반면에, zx 를 사용하는 경우 자바스크립트 매서드를 활용하여 익숙하고 편리한 방식으로 작성할 수 있습니다.

const data = {
  users: [
    {
      id: 1,
      name: 'John',
      contacts: {
        email: 'john@example.com',
        phone: '123-456-7890',
      },
    },
  ],
};

const johnEmail = data.users.find((user) => user.name === 'John').contacts
  .email;
console.log("John's Email:", johnEmail);

#장점 2) `$` 함수를 통한 쉘 스크립트 명령어 병행 사용

앞선 단락에서는 쉘 명령어를 사용할 때에 단점에 대해 설명드렸지만, 반대로 쉘 명령어가 강점을 발휘하는 순간도 있습니다. 많은 양의 처리가 필요한 작업에서는 쉘 명령어가 강한 성능을 발휘하기도 하고, 이미 쉘 스크립트로 작성 된 다양한 레퍼런스를 쉽게 참고할 수 있기 때문입니다.

필요한 경우에 zx 에서는 $ 함수를 사용해 쉘 명령어를 직접 호출할 수 있습니다. $ 함수를 불러와 문자열 형식으로 명령어를 작성해주면 자바스크립트와 쉘 명령어의 장점을 동시에 활용할 수 있게 됩니다.

ls *.js | wc -l 는 현재 디렉토리에 있는 .js 파일의 갯수를 세는 명령어입니다. $ 함수를 사용해 쉘 스크립트 구문을 실행하고, 자바스크립트의 console.log 를 통해 결과를 출력하고 있습니다.

import { $ } from 'zx';

const files = await $`ls *.js | wc -l`;
console.log(files.stdout);

#장점 3) Node.js 생태계를 활용한 작업 처리

zx 를 사용하면 스크립트 내에서 npm 패키지를 사용할 수 있습니다. HTTP 요청, 파일 압축, 이미지 처리 등 각 상황에 맞는 도구를 사용하여 원하는 작업을 쉽게 처리할 수 있게 됩니다.

예를 들어, HTTP 요청 시 자바스크립트 사용자에게 익숙한 axios 패키지를 동일하게 사용할 수 있습니다.

import axios from 'axios';

const response = await axios.get('https://api.example.com/data');

그 외에도 zx 는 여러 가지 장점 을 가지고 있습니다.

Promise와 async/await를 통해 비동기 작업을 쉽게 처리할 수 있습니다.
필요한 경우 타입 시스템(TypeScript)을 활용하여 안정적이고 정확한 코드 작성이 가능합니다.

#프론트엔드 개발자가 zx를 활용하는 방법

그러면 zx 는 어떤 상황에서 유용하게 사용할 수 있을까요? Next.js 로 만들어진 게임 어드민에서 이미지 파일을 다루기 위해 스크립트를 사용하는 사례를 통해 알아보겠습니다.

게임 어드민에는 프로젝트 내에 많은 이미지 삽입이 필요합니다. 게임 클라이언트에서 보여주는 많은 이미지를 운영툴에서도 동일하게 보여 주어야 하기 때문입니다. 보안 관련 번거로운 부분이 있기에 원격 이미지 저장소를 활용하는 대신 프로젝트에 직접 커밋을 하는 형태를 가지고 있습니다.

이미지 추가는 아래와 같은 방식으로 이루어집니다.

이미지 업데이트 프로세스

이 과정에는 몇 가지 어려움이 있었습니다.

수 만개의 이미지 파일과 수천 개의 폴더로 구성된 이미지 저장소의 크기
많은 이미지 파일 중 어드민에 필요한 이미지의 저장 경로 파악
게임 업데이트에 따라 주기적으로 새로운 이미지 추가 필요

이렇게 이미지를 옮기는 것은 지루하고 시간도 많이 소요됩니다. 다음 단락에서 귀찮은 작업을 어떻게 스크립트로 바꾸었는지 알아보겠습니다.

#주요 스크립트 내용

아래 내용은 독자의 이해를 돕고 외부에 공개하기 위해 핵심 로직을 남기고 부가적인 부분은 추상화 하였습니다.

먼저, 스크립트 내에서는 prefix 규칙을 활용해 원하는 이미지를 검색합니다. 어드민에서 필요한 이미지들은 이름에서 공통적인 prefix 규칙을 사용하고 있기 때문입니다. prefix 를 기준으로 스크립트를 작성하면 새로운 아이템이 추가 되어도 동일한 로직를 활용해 이미지를 가져올 수 있습니다.

각 단계별 함수를 호출하는 main 함수를 통해 전체적인 흐름을 소개하겠습니다. (main 함수 내 들어가는 개별 함수의 내용은 설명으로 대체하였습니다. 세부 내용이 궁금하시다면 아래에 첨부한 ‘스크립트 전체 코드’를 통해 확인해 주세요!)

const main = async () => {
  const { targetPath, sourcePath, prefixes } = config;

  await fs.mkdir(targetPath, { recursive: true });

  const findPatterns = prefixes.map((prefix) => `-name ${prefix}`).join(' -o ');
  const files = await findFiles(sourcePath, findPatterns);

  await copyFiles(files, targetPath);
  console.log(`.png 파일들이 모두 ${targetPath}로 복사되었습니다.`);
};

먼저, Node.js 의 fs 모듈을 사용하여 파일을 복사할 디렉토리를 생성합니다.

// 'recursive: true' 는 targetPath 경로에 있는 디렉토리가 없을 경우 생성해 주는 옵션입니다.
await fs.mkdir(targetPath, { recursive: true });

파일을 찾을 규칙을 findPatterns 변수로 정의하고, 복사할 파일의 경로를 리스트업 해주는 함수 findFiles 를 호출합니다. (함수의 내부에서는 $ 연산자를 통해 쉘 스크립트 문법을 사용하여 파일을 검색합니다.)

const findPatterns = prefixes.map((prefix) => `-name ${prefix}`).join(' -o ');
const files = await findFiles(sourcePath, findPatterns);

다음으로는 copyFiles 함수를 사용해 FindFiles 에서 찾은 파일을 복사하는 동작을 수행합니다. (함수 내부에서 파일 복사는 fs 모듈의 copyFile 을 사용하였습니다. 또한, Promise.all() 을 사용하여 복사 작업을 병렬적으로 처리해 주었습니다.

await copyFiles(files, targetPath);

마지막으로 모든 작업이 포함 된 main 함수를 실행하고 또 에러 처리를 위해 후속 메서드 catch 를 추가해 주었습니다.

main().catch(console.error);

Appendix) 스크립트 전체 코드

import { promises as fs } from 'fs';
import path from 'path';
import { $ } from 'zx';

const config = {
  targetPath: './target',
  sourcePath: '../source',
  prefixes: ['prefix1_.*\\.png', 'prefix2_.*\\.png', 'prefix3_.*\\.png'],
};

const main = async () => {
  const { targetPath, sourcePath, prefixes } = config;

  await fs.mkdir(targetPath, { recursive: true });

  const findPatterns = prefixes.map((prefix) => `-name ${prefix}`).join(' -o ');
  const files = await findFiles(sourcePath, findPatterns);

  await copyFiles(files, targetPath);
  console.log(`.png 파일들이 모두 ${targetPath}로 복사되었습니다.`);
};

const findFiles = async (sourcePath, pattern) => {
  const command = ['find', sourcePath, '-type', 'f'].concat(pattern.split(' '));
  let files = await $`${command}`;
  return files.stdout.split('\n').filter(Boolean);
};

const copyFiles = async (files, targetPath) => {
  const copyTasks = files.map((file) =>
    fs.copyFile(file, `${targetPath}/${path.basename(file)}`)
  );
  await Promise.all(copyTasks);
};

main().catch(console.error);

#zx 사용을 통한 변화

zx 로 작성한 스크립트를 사용하면서 생긴 변화를 단계별로 표현해 보았습니다. 기존의 5단계의 과정이 필요했던 작업이 2단계로 줄어든 것을 알 수 있습니다. 또한, prefix 를 추가해야 되는 상황은 가끔 발생하는 일이기에 부담이 더욱 줄어들게 됩니다.

이미지 업데이트 프로세스 비교

"zx를 사용해 이미지 변경 사항에 거의 신경쓰지 않고 프로젝트를 관리할 수 있게 되었습니다."

#글을 마치며

단순 작업을 반복하게 되면 종종 ‘나 대신 작업을 해 줄 사람이 없을까?’ 하는 생각이 들 때가 있습니다. 그러나 업무 자동화 를 선뜻 시작하기에는 부담스러운 경우가 많은 것 같습니다. 대부분의 개발자들에게 스크립트 작업은 주요 업무가 아니기 때문에, 생소한 문법을 배우고 구현하는 과정에서 여러 시행착오가 있을 수 있기 때문입니다.

이런 점에서 많은 개발자에게 zx는 유용한 도구가 될 것이라 생각합니다. 자바스크립트에서 제공하는 편의성과 쉘 스크립트의 뛰어난 성능과 다양한 자료를 동시에 활용할 수 있어, 빠르게 원하는 자동화 작업을 구현할 수 있기 때문입니다.

“지루한 반복 업무가 있다면 zx를 통한 업무 자동화를 적극 추천합니다.”

MySQL online alter부터 CPU 100% 장애까지

Tue, 05 Sep 2023 00:00:00 GMT

안녕하세요. [쿠키런: 오븐브레이크]의 서버 개발자 황재영입니다.

Database는 많은 개발자들이 유용하게 사용하면서 동시에 많은 문제를 겪는 요소라고 생각합니다. [쿠키런: 오븐브레이크] 팀 역시 그렇습니다. 이 글에서는 제가 22년 7월 경에 겪었던 AWS Aurora MySQL과 관련된 online alter과 CPU 100% 장애에 대해서 이야기해보려고 합니다.

#신규 기능과 Table Alter

작업의 시작은 22년 8월에 추가된 [쿠키런: 오븐브레이크]의 신규 기능, 패키지 매출 랭킹에서 비롯되었습니다. 패키지 매출 랭킹은 현재 판매 중인 패키지들에 대해서 지난 N시간동안의 매출을 집계해서 등수를 매기고 보여주는 기능입니다. 이 기능의 내부적인 구현을 위해서는 지난 N시간동안의 패키지별 판매 수량을 집계해야 했었습니다. 그러나 기존에 구매 기록을 관리하고 있던 AWS Aurora MySQL table에는 구매 시점 정보가 없었기에 "지난 N시간동안"이라는 정보를 조회하기 어려웠습니다. 이를 우회하기 위한 방법도 고려해보았지만, 결론적으로는 구매 시점 정보를 table에 추가하기로 했습니다.

ALTER TABLE $TABLE_NAME
ADD COLUMN purchase_dt datetime NOT NULL DEFAULT 0,
ADD KEY purchase_dt (purchase_dt);

구매 시점 정보를 purchase_dt라는 칼럼으로 생성하고 index까지 추가하기 위해서는 위와 같은 쿼리를 필요로 했습니다. 그리고 여기서 문제가 발생했습니다. 구매 기록을 관리하고 있던 table은 유저가 실제로 구매하는 로직과 직결되어 있기 때문에, 일반적인 ALTER TABLE로는 table lock이 잡혀서 문제가 될 것이기 때문에 진행할 수 없었습니다. 그렇다고 [쿠키런: 오븐브레이크] 팀에서 일반적으로 진행하는 점검 2시간동안 적용하기에는, 서비스 시작 이래의 모든 구매 기록을 가지고 있는 큰 크기의 테이블이었기에, 실행에 시간이 너무 오래 걸려서 어려웠습니다. 이러한 제한점 때문에 이 쿼리는 online alter를 통해 적용하는 것으로 결정하게 되었습니다.

#Online Alter Plan 1 - Inplace Algorithm

처음으로 고려해본 것은 MySQL Database에서 지원하는 기능이었습니다. 바로 lock을 잡지 않는 alter인 inplace algorithm이었는데요. 적용이 가능한지 간단히 테스트해보기 위해서, 개발팀에서 테스트로 사용하는 서버의 Database를 복제하여 alter를 진행해보았습니다. 결과는 다음과 같았습니다.

mysql> ALTER TABLE $TABLE_NAME
    -> ADD COLUMN purchase_dt datetime NOT NULL DEFAULT 0,
    -> ADD KEY purchase_dt (purchase_dt),
    -> ALGORITHM=inplace, LOCK=none;
ERROR 1062 (23000): Duplicate entry '73817' for key 'PRIMARY'

mysql> ALTER TABLE $TABLE_NAME
    -> ADD COLUMN purchase_dt datetime NOT NULL DEFAULT 0,
    -> ADD KEY purchase_dt (purchase_dt),
    -> ALGORITHM=inplace, LOCK=none;
Query OK, 0 rows affected (2.72 sec) Records: 0 Duplicates: 0 Warnings: 0

최초 시도에서는 실패하고, 2번째 시도에서는 성공하는 특이한 결과를 확인할 수 있었습니다. 최초 시도에서 발생한 에러에 대해 검색하니 MySQL의 공식 문서를 확인할 수 있었습니다. 문서에서는 위 에러가 inplace algorithm의 한계로, 간헐적으로 발생할 수 있는 문제라고 설명하고 있었습니다. 실제 서비스 환경에서 진행할 때는 더 발생할 가능성이 높은 에러로 고려되었기 때문에, inplace algorithm을 사용한 online alter plan은 폐기되었습니다.

#Online Alter Plan 2 - Percona Toolkit

MySQL의 기본 기능이 아닌 외부 툴에 대해서 찾아보니, Percona Toolkit이라는 툴에서 제공하는 online schema change라는 기능으로 실제 서비스 환경에서 online alter를 진행하는 사례를 찾았습니다. 어떤 원리로 동작하는지 궁금하여서 찾아봤더니 아래와 같이 정리할 수 있었습니다.

기존 table과 동일한 스키마를 가진 신규 table 생성
신규 table에 schema change를 바로 적용
기존 table의 변경사항이 신규 table에도 적용될 수 있게 trigger 설정
기존 table에서 일정 크기의 데이터만큼 신규 table로 복사
모든 데이터를 복사할 때까지 4번을 계속 반복
check sum 검사를 통해 신규 table과 기존 table이 동일한 상태에 있는지 검사
신규 table의 이름을 기존 table의 이름으로 변경

위 과정에 따른 online schema change에는 기존에 설정된 trigger가 없어야 한다거나 schema change에 위반되는 변경사항이 있어서는 안된다와 같은 제약사항이 있었지만, 이번에 적용하려고 하는 table에서는 문제가 없어 이 기능을 사용하여 online alter를 진행하기로 하였습니다.

해당 툴의 사용 테스트와 실제 적용은 아래와 같은 4단계로 진행하였습니다. 후술된 Staging은 내부 테스트 환경, Production은 실제 서비스 환경을 의미합니다.

Staging 복제본 테스트
Production 복제본 테스트
Staging 적용
Production 적용

#Staging 복제본 테스트

툴을 사용할 수 있는지 검증하고 실제로 일어날 변경사항을 확인하는 단계입니다.

먼저 dry run부터 사용해보았습니다.

pt-online-schema-change \
    --dry-run
    --host $DBHOST --user $USERNAME --ask-pass \
    --alter 'ADD COLUMN purchase_dt datetime NOT NULL DEFAULT 0, ADD KEY purchase_dt (purchase_dt)' \
    D=$DB_NAME,t=$TABLE_NAME

Starting a dry run.  `DB_NAME`.`TABLE_NAME` will not be altered.  Specify --execute instead of --dry-run to alter the table.
Creating new table...
Created new table DB_NAME._TABLE_NAME_new OK.
Altering new table...
Altered `DB_NAME`.`_TABLE_NAME_new` OK.
Not creating triggers because this is a dry run.
Not copying rows because this is a dry run.
Not swapping tables because this is a dry run.
Not dropping old table because this is a dry run.
Not dropping triggers because this is a dry run.
2022-07-13T11:52:58 Dropping new table...
2022-07-13T11:52:58 Dropped new table OK.
Dry run complete. `DB_NAME`.`TABLE_NAME` was not altered.

dry run에서는 trigger 설정도, copy도, swap도 없이 정말 툴을 사용할 수 있는지의 기본적인 검사만 이루어졌는데요. 특별한 문제가 없었기에 바로 real run으로 넘어가 보았습니다.

pt-online-schema-change \
    --execute
    --host $DBHOST --user $USERNAME --ask-pass \
    --alter 'ADD COLUMN purchase_dt datetime NOT NULL DEFAULT 0, ADD KEY purchase_dt (purchase_dt)' \
    D=$DB_NAME,t=$TABLE_NAME

Altering `DB_NAME`.`TABLE_NAME`...
Creating new table...
Created new table DB_NAME._TABLE_NAME_new OK.
Altering new table...
Altered `DB_NAME`.`_TABLE_NAME_new` OK.
2022-07-13T11:55:11 Creating triggers...
2022-07-13T11:55:11 Created triggers OK.
2022-07-13T11:55:11 Copying approximately 9980 rows...
...(중략)
2022-07-13T11:55:34 Copied rows OK.
2022-07-13T11:55:34 Analyzing new table...
2022-07-13T11:55:34 Swapping tables...
2022-07-13T11:55:34 Swapped original and new tables OK.
2022-07-13T11:55:34 Dropping old table...
2022-07-13T11:55:34 Dropped old table `DB_NAME`.`_TABLE_NAME_old` OK.
2022-07-13T11:55:34 Dropping triggers...
2022-07-13T11:55:34 Dropped triggers OK.
Successfully altered `DB_NAME`.`TABLE_NAME`.

real run에서는 원래 기대했던 기능들이 적용된 모습을 볼 수 있었습니다. 실행시간을 보면 내부 테스트용 Database라서 데이터가 많지 않아 매우 빠르게 끝났음을 알 수 있었습니다.

#Production 복제본 테스트

실제 Production에서 실행 때 일어날 변경사항과 소요 시간을 확인하는 단계입니다.

서비스의 Database 사용에 문제를 일으키지 않을 정도의 자원을 사용하면서 최대한 빠르게 실행하기 위해, Production 복제본에 적용하는 테스트는 chunk-size 옵션을 바꾸어 가며 여러 번 테스트를 진행했습니다. chunk-size 옵션은 위에서 설명한 작동 원리 4번의 복사 스텝에서 얼마만큼의 크기의 데이터를 복사할지를 조절하는 값으로, 이 값에 따라 툴의 실행 시간과 자원 소모량이 결정됩니다.

Production 복제본 테스트를 실행하였을 때 확인한 CPU 그래프

그래프에서 총 3개의 피크를 확인할 수 있는데, 첫번째 피크는 Database를 생성했을 때의 피크로 무시하고, 나머지 2개의 피크에서 결과를 확인할 수 있었습니다.

2번째 피크는 chunk-size를 250으로 설정했을 때이고, 3번째 피크는 chunk-size를 500으로 설정했을 때입니다. 안정적으로 45% 정도의 CPU를 유지하는 chunk-size 250과 다르게, chunk-size 500은 최초에 CPU가 거진 80%까지 올라가고 이후에 50% 정도로 안정되는 모습을 보여주었습니다. 상시적으로 약 8%의 CPU를 사용 중인 복제본 Database와 다르게, 실제 서비스 Database는 상시적으로 약 20%의 CPU를 사용하고 있습니다. 그리고 툴 사용 중에도 CPU 70%를 넘지 않는 것을 목표로 생각하고 있었기에, chunk-size는 250으로 결정하여 Production Database에 적용하는 것으로 결정했습니다.

#Staging 환경 적용

유저가 활동하는 상황에서 online alter가 잘 되는지 테스트하는 단계입니다.

유저의 사용 패턴을 mocking하여 여러 종류의 복잡한 구매를 시도하고, Production에 비해 너무 빠르게 끝나는 실행을 보완하기 위해 sleep 옵션을 사용해서 테스트도 진행하였습니다. 다행히도 문제 없이 적용되었습니다.

#Production 환경 적용

마침내 실제 서비스에 적용하는 단계입니다.

혹시 모를 상황에 대비하여 별도의 백업도 준비한 상태로 진행하였습니다. 미리 검증을 해서인지, 툴이 잘 만들어져 있어서인지, 아래와 같은 CPU 그래프와 함께 문제 없이 잘 실행되었습니다.

Production에서 실행하였을 때 확인한 CPU 그래프

#CPU 100%

그렇게 online alter 작업을 성공적으로 마치고, 기능 구현도 완료한 상태로 기능 배포 당일을 맞이하였습니다. 배포를 진행하면서 살짝 불안해진 CPU 그래프를 보고 있었습니다.

기존보다 평균치가 살짝 상승한 CPU

기존에 20% 정도만 사용하던 것에 비해 약 10~20% 정도 오른 그래프에서, 기능 구현을 위해 추가한 쿼리로 인한 영향을 인지했습니다. 그러나 아직 큰 문제는 아니기 때문에, 같이 배포된 다른 기능들에서 발견된 문제들을 먼저 해결하고 있었습니다.

그런데 상황이 바뀌기 시작했습니다. 여러 버그 픽스를 추가로 배포하고 유저들을 재접속시키니, 어느 순간 Database 알람이 울리고 다시 본 그래프는 아래와 같은 모습을 하고 있었습니다.

100%를 달성해버린 CPU

처음으로 보는 CPU 100% 그래프였는데요. 아니나 다를까, Database 접속에 문제가 생기면서 유저들이 정상적인 게임 접속/플레이가 불가능해졌습니다. 우선 서버 점검을 건 후, 문제가 되는 패키지 매출 랭킹 기능의 활성화 여부를 설정할 수 있는 기능을 빠르게 추가해 비활성화 상태로 설정한 후 서비스를 정상화시켰습니다. 서비스를 정상화시킨 다음 침착하게 기능 구현을 파악한 결과, 밝혀진 문제 원인은 2개였는데요. 바로 쿼리와 캐시 사용 패턴이었습니다.

#문제 원인1. 쿼리

먼저 쿼리 자체가 최적화가 되어 있지 않아서, CPU를 더 많이 소모하게 되었습니다. 사용한 쿼리는 아래와 같았습니다.

SELECT product_id, COUNT(*) AS count
FROM $DB_NAME
WHERE
(product_id = ‘aaa’ AND {판매 시작 시간} < purchase_dt AND purchase_dt <= {현재}) OR
(product_id = ‘bbb’ AND {판매 시작 시간} < purchase_dt AND purchase_dt <= {현재})

첫 번째 문제는 (product_id, purchase_dt)을 묶어서 쿼리를 하는데 이를 기준으로 한 index가 없는 것이었습니다. 두 번째 문제는 조회 과정에서 매번 바뀌는 "현재"가 조건으로 걸려 있기 때문에 Database 내부적으로 최적화하기 어렵다는 것이었습니다. 이 2개의 문제에 대해서 각각의 해결 방안을 고민해보았습니다.

첫 번째 문제인 index는, (product_id, purchase_dt)을 묶은 composite index로 해결하려고 하였습니다. online alter와 동일하게 Staging 복제본 Database에서 테스트해보았습니다. 그러나 아쉽게도 쿼리 성능 개선은 10% 정도로 미미하였고, index를 추가하는 비용에 비해 효과가 유의미하지 않다고 판단하여 현 상태를 유지하기로 하였습니다.

두 번째 문제인 최적화는, 쿼리의 컨디션을 최대한 묶고 현재 시간 기반 쿼리를 지우는 방식으로 해결하려고 하였습니다. 업데이트 때마다 새로운 상품이 출시되는 [쿠키런: 오븐브레이크] 특성상, 판매 시작 시간을 공유하는 상품들이 많아 해당 product_id의 컨디션을 묶는 방법으로 개선을 할 수 있었습니다. 또한 현재 시간 기반 쿼리는, 미래 시점에서 구매된 상품이 있을 수는 없으므로 무의미한 컨디션이었기 때문에 삭제하였습니다. 그 결과 다음과 같은 쿼리로 개선하였습니다.

SELECT product_id, COUNT(*) AS count
FROM $DB_NAME
WHERE
((product_id = ‘aaa’ or product_id = ‘bbb’) AND {판매 시작 시간} < purchase_dt)

기존 쿼리에 비해 한결 짧아진 것이 눈으로도 보이는 쿼리가 되었는데요. 아쉽게도 이 쿼리 역시 성능 개선은 크지 않았지만, 부정적인 점이 없는 변경사항이었기 때문에 바로 적용하였습니다.

#문제 원인2. 캐시 사용 패턴

사실 쿼리보다 주요하게 다룬 문제는 서버 내부의 캐시의 사용 패턴이었는데요. 이를 이해하기 위해서는 [쿠키런: 오븐브레이크]의 서버 구조에 대한 설명이 필요합니다. [쿠키런: 오븐브레이크]는 AWS autoscaling group을 활용한 수평 분산이 가능한 서버이고, 각 서버마다 독립적으로 캐시를 만들고 관리합니다. 그리고 기획팀은 필요할 때마다 게임데이터를 수정해서 업로드합니다. 이로 인해 여러 버전의 게임 데이터가 공존할 수 있습니다. 그리고 게임데이터마다 캐시 결과가 달라질 수 있으므로 게임데이터 버전에 따라 새롭게 캐시해야 합니다. 즉, 게임데이터마다 별개의 캐시가 만들어집니다.

기존 캐시 구조. 동일한 값을 사용하는 캐시가 많다

문제는 패키지의 판매 시작 시간도 게임데이터에 의존한다는 점입니다. 결과적으로는 캐싱을 하고 있지만, 쿼리를 (분산 서버 수) * (게임데이터 가짓수)만큼 실행하게 되었습니다. 게다가 서버를 업데이트하면 캐시가 비어있는 서버가 늘어나 쿼리를 더더욱 많이 실행하여 순식간에 Database에 부하를 가하게 된 것이었습니다. 개발 환경에서는 결제 데이터가 많지 않아 쿼리가 빨랐고, 분산 서버 수도 적어 이러한 문제를 발견하기 어려웠습니다.

이를 해결하기 위해서, 모든 서버들이 공통으로 사용할 수 있는 캐시를 별도로 운영하는 것으로 결정하였습니다. 그렇게 만들어진 단일 캐시는 "스케쥴러 서버"라는 이름의 별도의 서버에서 관리합니다. 이 서버는 주기적으로 주어진 요청을 처리합니다. 이를 활용하여 아래와 같은 스텝으로 구현을 변경하였습니다.

서버는 결과가 필요할 때 2가지 로직을 실행합니다
- Database에 직접 쿼리하는 대신 원격 저장소에 저장된 결과를 조회합니다. 저장된 결과가 없으면 빈 값으로 처리합니다
- 스케쥴러 서버로의 요청을 큐에 저장합니다
스케줄러 서버는 주기적으로 큐에서 모든 요청을 꺼내고, 마지막 요청을 기반으로 쿼리를 하여 결과를 계산합니다
스케줄러 서버가 계산한 결과를 원격 저장소에 저장(캐싱)합니다

쿼리를 각각의 서버가 실행하는 것이 아닌, 스케줄러 서버가 일괄적으로 실행함에 따라서 쿼리의 실행 횟수를 줄여서 부하를 줄일 수 있었습니다.

#문제 해결 완료

쿼리 최적화와 캐시 사용 패턴 개선을 적용한 다음, 조심스럽게 패키지 매출 랭킹 기능을 다시 활성화였을 때, 변경된 CPU 그래프는 다음과 같았습니다.

돌아온 CPU

중간중간 작은 피크들을 통해 스케쥴러 서버가 쿼리를 실행하고 있다는 것이 알 수 있습니다. 이러한 피크를 제외하면 전체적으로는 문제 없이 CPU가 유지되었고 기능 자체도 성공적으로 작동하였습니다. 마침내 모든 문제를 해결한 것입니다.

#결론

Database에 진행한 작업이 많지 않지만, 그 중에서도 패키지 매출 랭킹 관련 작업은 저에게 많이 인상 깊은 작업이었습니다.

Production 환경에서의 online alter를 위해 Percona Toolkit이라는 툴을 사용하여 성공적으로 진행한 경험을 쌓았습니다. 이후 몇 번 더 online alter를 해야하는 작업이 있었는데, 그 때마다 이 툴을 사용하여 문제 없이 진행할 수 있었습니다. 이 과정에서 유용한 툴을 잘 활용하는 것에 대한 중요성을 깨달았습니다.
무거운 쿼리와 분산 서버 환경에서의 캐시 시스템이 합쳐져 예상치 못한 문제를 야기하였는데, 사전에 문제될 만한 지점을 잘 파악하는 것 또한 중요하다는 것을 배웠습니다
장애가 발생하였을 때 원인 파악도 중요하지만 서비스 정상화를 우선시 해야 한다는 것을 새삼 깨달았습니다. 이번에는 문제 되는 기능의 활성화 여부를 설정할 수 있는 기능을 적용하여 해결했는데, 이러한 안전 장치를 미리 구현해두면 보다 안정적인 서비스를 운영하는데 도움이 될 것입니다.

이 글이 Database 작업을 하는 다른 분들께도 도움이 되길 바라며 마무리하겠습니다. 긴 글 읽어주셔서 감사합니다.

웹 개발자의 데이터 애플리케이션 flow 효율화하기

Wed, 02 Aug 2023 00:00:00 GMT

안녕하세요, 저는 데브시스터즈 진저랩 웹서비스셀에서 소프트웨어 엔지니어로 일하고 있는 안정현입니다. 이 글에서는 데이터 앱 프레임워크인 Dash를 도입하면서 겪었던 아키텍처 측면의 이슈와 개선에 대해 공유해 드리고자 합니다.

데브시스터즈에서는 이미 Mode나 Databricks를 사용해 데이터의 수집, 적재, 시각화까지 모든 프로세스가 이미 잘 되어있었습니다. 하지만 이 많은 데이터를 시각화하기 위한 성능적인 측면과, 데이터를 보는 사용자에게 더욱 많은 인사이트를 제공하기 위한 다양한 기능들이 필요했습니다.

이를 위해 저희는 순수하게 Python만 사용해서 데이터 엔지니어도 쉽게 개발이 가능하면서도 직접 만든 React Component를 연동할 수 있어서 웹 개발자들에게도 친화적인 data app framework인 Dash를 사용해 자체적인 서비스를 구현하기로 했습니다.

#Why Dash?

data app 개발을 위한 프레임워크가 많이 존재하고 있지만, Dash를 선택한 이유는 다음과 같습니다.

차트 라이브러리인 plotly.js를 개발한 Plotly에서 개발했기 때문에 차트 시각화 대시보드를 만들기에 궁합이 잘 맞습니다.
직접 만든 React 컴포넌트를 만들어서 사용할 수 있기 때문에 웹 개발자가 익숙한 방식으로 개발이 가능하고 사내 디자인시스템을 쉽게 적용할 수 있습니다.
stateless한 디자인으로 scale out을 자유롭게 할 수 있어서 High Availability 구성이 가능합니다.
Top of flask로 개발되어 있어서 아래의 예시와 같은 web app의 기능을 그대로 사용할 수 있습니다.
- middleware 연동 (Single Sign-On, ExceptionHandler, Cache 등)
- 추가적인 API 구현
- HTTP 압축

#Dash Internals

Dash의 동작 방식을 이해하면 callback 설계를 더 효율적으로 할 수 있습니다. 기본적인 렌더링 프로세스는 다음과 같습니다.

브라우저에서 Dash 페이지 접속
- 서버는 기본 HTML 템플릿 반환
- 필요한 JavaScript 번들 로드
레이아웃 데이터 요청 (_dash-layout)
- 서버에서 정의된 레이아웃 구조 로드
- 컴포넌트 트리 구성
의존성 정보 요청 (_dash-dependencies)
- Input/Output 관계 매핑
- 콜백 그래프 구성
초기 상태 설정
- 컴포넌트 초기값 설정
- 초기 렌더링 수행

이후 사용자 인터랙션이 발생하면 /_dash-update-component API를 통해 해당하는 callback이 실행되며 화면이 업데이트됩니다.

Dash 아키텍처 다이어그램

#Dash callback

Dash는 브라우저의 이벤트를 받아서 callback이라고 하는 추상화된 API를 호출합니다. callback의 Input과 Output으로는 Dash로 작성한 HTML element의 property를 받을 수 있습니다.

callback은 Python으로 작성한 callback과 Javascript로 작성한 clientside callback으로 구분됩니다.

아래는 하나의 callback으로 데이터 요청 후 차트를 그리는 가장 간단한 구조를 도식화한 것입니다. 4단계에서 반환하는 figure는 차트를 그리는 데 필요한 데이터를 담고 있는 객체입니다.

비교적 간단해 보이는 이 구조는 아래와 같은 문제점이 있습니다.

callback의 Input과 Output이 많아질수록 복잡해지기 쉽고, 유지보수가 힘들어집니다. 하나의 callback 내에서 query부터 render까지의 모든 로직을 넣게 되면 다음과 같은 문제가 발생합니다.

시각화에 필요한 모든 로직을 넣어야 해서 코드 덩어리가 커지고 경계가 모호해집니다.
이미 가져온 데이터의 보여주는 방식만 변경하고 싶은 경우에도 새롭게 query를 해야 합니다.
하나의 쿼리로 여러 차트를 그리는 경우 모든 로직이 순서대로 실행되기 때문에, n 배의 시간이 걸리게 됩니다.

실제 제품에서는 아래와 같은 추가적인 비즈니스 로직이 필요합니다.

데이터가 없는 경우 차트 대신 넘어진 용감한쿠키를 출력
데이터 캐싱
선택한 통화에 알맞은 표기로 전환 (ex. USD → $10.06만, KRW → ￦ 1.27억)
선택한 언어에 알맞은 표기로 전환 (ex. EN → ￦ 127.35M, KR → ￦ 1.27억)

데이터가 없는 경우 차트 대신 넘어진 용감한쿠키를 출력

이렇게 다양한 로직을 하나의 callback에 넣게 되면, 코드가 길어지고, 유지보수가 힘들어집니다.

#callback을 분리하고 연결하기

위의 문제를 해결하기 위해 아래와 같은 방법을 사용했습니다.

하나의 callback을 각 역할에 맞는 callback으로 분리하는 작업을 진행하였고, 각 callback에는 역할에 맞는 로직만 작성할 수 있도록 규칙을 정했습니다.

일반적인 웹 애플리케이션 개발과 비슷한 경험을 이어 나가고자, MVC 패턴과 같이 크게 3가지 영역으로 나누었습니다. Dash가 top of React이고 React에서는 Provider라는 컴포넌트 형태의 wrapper를 사용하는 것에서 착안하여 각각의 이름을 FetchProvider, TransformProvider, RenderProvider로 정했고, 각 역할은 아래와 같습니다.

FetchProvider: Databricks, Redis 등의 datastore로부터 데이터를 가져옵니다.
TransformProvider: 가져온 데이터를 차트를 그리기 쉬운 형태로 가공합니다.
RenderProvider: 가공된 데이터를 기반으로 차트를 그립니다. (Figure 객체를 생성합니다)

모든 callback은 API이므로, Output은 브라우저로 넘어가고, 다음 callback의 Input과 State로 재사용할 수 있습니다. 다시 말하자면, 언어 변경이나 누적값으로의 표현 방법 변경 등의 단순 view 변경 시 query를 다시 요청하지 않고, 이미 브라우저에 저장된 데이터를 재사용할 수 있다는 뜻입니다.

저장된 데이터를 재사용하는 경우, transform(아래 그림의 녹색 화살표)부터 실행되어, db를 거치지 않고도 변경된 차트를 화면에 반영할 수 있게 됩니다.

브라우저와 서버 간에 여러 번의 데이터 핑퐁이 있기 때문에 데이터를 빠르게 주고받는 것이 중요합니다. 저희는 gzip, br 두 가지의 압축을 적용하여 데이터를 약 1/5 크기로 줄였습니다.

#Mixin으로 차트 그리는 로직 합치기

callback을 통해 요구사항은 충족되었지만, 차트를 그리는 코드가 재사용 되지 않는 문제가 여전히 남아있습니다.

또한 차트에서 데브시스터즈의 다양한 이벤트(대규모 업데이트, 마케팅 등)를 차트에서 같이 확인할 수 있는 history 기능도 제공하고 있는데요, 이러한 차트를 그리는 코드가 render 콜백 여기저기서 반복된다면 유지보수가 힘들기 때문에 저희는 사용하는 패턴별로 차트를 모듈화하고자 했습니다.

디자인시스템의 톤앤매너에 맞게 차트의 스타일을 잡아야 했기 때문에 Dash의 Figure를 상속받아서 기본적인 디자인이 들어간 Figure 클래스를 생성하였고, Bar, Line, Area 등 다양한 시각화 로직을 Mixin 단위로 상속받는 방식을 택했습니다. Mixin에 대한 자세한 설명은 링크를 참고해주세요.

가상의 데이터로, 실제 지표와는 무관합니다.

아래는 Mixin 클래스의 예시입니다. (복잡한 구현 부분은 생략하였습니다.)

# ChartMixin의 예시

class LineChartMixin(BaseMixin):
    def add_cutsom_lines(self, traces: list[Trace]):
        for trace in traces:
            self.add_custom_line(trace)

    def add_custom_line(self, trace: Trace):
        self.add_trace(
            graph_objects.Scatter(...)  # Line 차트를 그려준다
        )

class HistoryMixin(BaseMixin):
    def add_histories(self, histories: list[History]):
        self._add_background()
        self._add_history_dots(histories=histories)

    def _add_background():
        self.add_shape(...)

    def _add_history_dots(histories: list[History]):
        self.add_trace(
            graph_objects.Scatter(...)
        )

class LineFigure(BaseAxisFigure, LineChartMixin, HistoryMixin):
    def __init__(
        self,
        traces: list[Trace],
        histories: list[History] = None,
    ):
        super().__init__()

        self.add_custom_lines(traces)

        if histories is not None:
            self.add_histories(histories=histories)

#정리

데브시스터즈에서는 Dash를 도입하여 목적에 맞게 로직을 분리한 후, chaining 하여 복잡한 인터렉션에도 간단한 코드 구조를 가질 수 있게 되었습니다. 또한 Mixin 클래스를 활용하여 차트마다 사용되는 공통 기능을 관리하기 쉽게 되었고, gzip, br을 통한 데이터 압축을 통해 많은 데이터를 빠르게 주고받을 수 있게 되었습니다. Dash를 사용 중인 분들이 계신다면, 이번 글이 도움이 되셨으면 좋겠고, 더 좋은 방법이 있다면 공유해 주시면 좋을 것 같습니다.

사운드 리소스 전달 WebApp 만들기

Tue, 04 Jul 2023 00:00:00 GMT

안녕하세요, 저는 데브시스터즈에서 Frontend R&D Engineer로 근무중인 문태근 이라고 합니다. 게임 개발과 운영에 필요한 다양한 백오피스 개발 및 기술 연구를 담당하고 있습니다.

이 글에서는 게임 개발에 필요한 웹앱을 개발했던 경험을 공유하고, 그 과정에서 가장 중요하게 생각했던 가치관인 “단순한 설계”에 대해 이야기해 보고자 합니다.

#문제 상황

게임 클라이언트를 만드는 데는 소스 코드 외에도 게임에 필요한 사운드나 이미지 같은 리소스들이 필요합니다. 일반적으로 리소스 제작팀은 Dropbox, Google Drive 등의 웹 드라이브를 통해서 클라이언트팀에게 리소스를 전달합니다.

하지만 웹 드라이브를 통한 전달에는 단점이 있습니다. 바로 이미지_최종_진짜최종_final(2).png과 같이 버전 컨트롤이 어렵다는 것입니다. 특히 게임 개발처럼 업데이트가 빌드 단위로 진행되는 프로젝트의 경우, 파일 개별의 버전이 아니라 전체 파일 단위에 대한 버전 컨트롤이 필요합니다. (특정 시점으로 되돌려야 하는 경우 있음)

그렇다면 왜 처음부터 Git과 같은 VCS를 바로 쓰지 않고 웹 드라이브를 통해 전달하는 것일까요? 여러 가지 이유가 있지만, 가장 큰 이유는 프로그래머가 아닌 팀원들에게 Git의 진입장벽이 높기 때문입니다.

Sourcetree나 Fork 같은 GUI 클라이언트를 쓰면 어느 정도 해결할 수 있으나, 여전히 아래와 같은 문제점이 있습니다.

Git을 써야 한다는 심리적 부담감
Merge Conflict 해결의 어려움
비용 발생 (GUI Client 라이센스, Github 계정 → 사용자 수에 비례)

이렇듯 프로그래머가 아닌 분들이 Git을 사용하기 위해서는 많은 심리적, 물질적 부담이 불가피해 보입니다.

그래서 쿠키런: 킹덤 개발팀은 버전 컨트롤이 가능한 사운드 파일 전달 Web App(a.k.a Sonic) 을 직접 만들기로 결정했습니다.

~~Git을 써야 한다는 심리적 부담감~~ → 사용자에게는 최소한의 필요한 interface만 노출 (push, checkout)
~~Merge Conflict 해결 어려움~~ → 무조건 덮어쓰도록 설정
~~비용 발생~~ → 최소한의 서비스 호스팅 비용만 발생 (사용자 수 비례 X)

#0. 설계 원칙

전 마이크로소프트 CTO인 Ray Ozzie는 2005년 내부 문건에서 다음과 같이 말했습니다.

복잡성은 살인적입니다. (Complexity Kills)

복잡성은 사용자, 개발자, IT 부서의 생명을 앗아갑니다. 복잡성은 제품을 계획, 구축, 테스트 및 사용하기 어렵게 만듭니다. 복잡성은 보안 문제를 초래합니다. 복잡성은 관리자의 좌절을 초래합니다.

실제로 저도 불필요하게 복잡하게 작성된 코드와 시스템으로 인한 문제를 느꼈던 적이 굉장히 많았습니다. 그래서 Sonic을 제작할 때는 UI와 Architecture 두 가지 측면에서 복잡성을 최소화하기 위해 노력했습니다.

User Interface : 사용자에게 노출되는 인터페이스 최소화
Architecture : 코드 및 컴포넌트 최소화

이제 각각의 관점에서 어떻게 서비스를 구현했는지 알아보겠습니다.

#1. User Interface

Sonic의 사용자는 사운드팀과 클라이언트팀 두 가지 그룹으로 나뉘어 집니다. 요구사항을 정리한 결과, 사운드팀은 전달 (push), 클라이언트팀은 동기화 (checkout) 인터페이스만 있으면 충분하다는 결론을 내렸습니다.

그 외에 잘 사용하지 않으면서 서비스의 복잡도만 증가시키는 기능들은 모두 제외하기로 하였는데, 자세한 내용은 뒤쪽(2. 스펙 줄이기)에서 다루어 보겠습니다.

User Interface

💡 용어 정의

Bundle : 모든 사운드 파일의 묶음

Revision : 번들의 버전 (Git의 commit에 대응). 사운드팀이 내부적으로 관리

push : 특정 revision을 서버에 업로드하는 행위 (by 사운드팀)

checkout : 특정 revision으로 리소스 파일을 동기화 하는 행위 (by 클라이언트팀)

#2. System Architecture

서비스는 Next.js를 사용한 풀스택 웹앱으로 docker image를 통해 배포하였습니다. API로는 tRPC를 사용했는데, 백엔드에 엔드포인트를 추가하면 프론트엔드에 이에 대응되는 함수를 자동 생성해주어 API 개발 공수를 크게 줄일 수 있었습니다. 풀스택 앱 개발을 할 일이 있다면 한번 사용해 보시길 추천합니다.

#2.1. 핵심 기능

우리의 목적은 사운드팀이 업로드한 여러 파일중 (1) 변경된 파일만 추려내어 (2) 시스템에 기록하고, (3) 이 파일들만 클라이언트팀에서 다운로드하는 것입니다 (변경사항이 있는 파일만 전달하는게 중요한 이유는, 클라이언트팀에서는 전달받은 파일에 암호화 등 추가 가공을 하기 때문에 변경사항이 없는 파일까지 불필요하게 전달되면 오버헤드가 크게 늘어나기 때문입니다).

위 3가지 핵심 기능을 어떻게 구현했는지 사용 플로우와 함께 전체 흐름을 알아보겠습니다.

#2.1.1. 변경된 파일 추려내기 (Diff Files)

xxHash32의 WASM 빌드를 사용해 이전에 업로드 된 파일의 해시값과 첨부된 파일의 해시값을 비교했습니다. SHA-256은 전체 파일 업로드시 약 1분, xxHash32는 약 3초 정도가 걸려서 최종적으로 xxHash32를 선택했습니다.

#2.1.2. 번들 데이터 시스템에 기록하기 (Persistence)

번들 데이터는 크게 두가지로 구성됩니다.

사운드 파일들
번들 메타데이터
- 제목
- 세부 설명
- Revision
- 작성자
- 생성 시간
- 파일명 및 VersionId

사운드 파일들은 AWS S3의 Versioning Bucket 에 저장하였습니다. 메타데이터와 별도로 저장한 이유는 사운드 리소스는 바이너리 파일이기 때문에, 텍스트 형태인 메타데이터와 함께 저장하기 어렵기 때문입니다.

일반 Bucket : 이름만으로 파일 식별
Versioning Bucket : Versioning 옵션이 켜진 버킷에서 파일들은 이름 외에 VersionId라는 추가 식별자를 부여받습니다. 다운로드시 이름만 제공하면 최신 버전을, 특정 versionId까지 명시하면 해당 버전의 파일 다운

그리고 파일 목록 (이름, versionId)을 메타데이터에 넣기로 하였습니다.

이를 통해 메타데이터만 있으면 해당 번들에 어떤 파일이 있는지와 이들의 S3 versionId를 알 수 있었습니다.

메타데이터의 경우, DBMS를 사용해 직접 저장하지 않고 local git을 DB처럼 사용하기로 했습니다.

git에 저장되는 데이터 schema가 Sonic 요구사항에 충분함 → schema 관리 필요 X ```bash $ echo $CONTENTS > sound_file_meta.csv $ git add sound_file_meta.csv $ git commit
--author $YOUR_EMAIL
-am $TITLE
-m $DESCRIPTION

$ git tag -a $REVISION -m $REVISION ``` - 제목, 세부 설명 → Git commit message (multi line) - Revision → Git tag - 작성자 → Git author - 생성 시간 → Git commit time - 파일들의 이름 및 Version Id → CSV 로 만들어 파일로 커밋 2. DBMS에는 없는 버전 컨트롤 기능 제공 → 어플리케이션 로직 (Revision 간 변경사항 찾는 코드) 작성 필요 X - git diff Rev.98 Rev.100 3. git cli 명령어로 DBMS가 제공해주는 query 기능 대체 가능 → 조회 성능 이슈 X - select * from limit 10 → git log -n 10

물론 성능 등 여러 측면에서 차이가 있겠지만, 당장의 요구사항에서 이런 DBMS의 기능들은 큰 의미가 없는 반면, DBMS 도입으로 인한 복잡성을 줄일 수 있는 이점이 더 크다고 판단하였습니다.

Next.js 에서 git cli 접근을 위해, node:child_process 모듈의 exec 을 사용했습니다. 이때 git의 pretty formats 을 사용해 하나의 커밋에 들어가는 정보는 한 줄에 출력되도록 설정했습니다. 이를 통해 stdout으로 출력된 결과물을 쉽게 파싱할 수 있었습니다.

즉, Sonic은 S3 파일 업로드 + Git 커밋을 해주는 웹앱으로, 사운드팀의 push flow를 정리하면 아래와 같습니다.

Push flow

첨부 파일 해시값 비교를 통해 변경사항이 있는 파일만 S3에 업로드 후
S3 업로드 response에 담긴 S3 file versionId를 포함해 번들 메타데이터 생성
Sonic 서버에 메타데이터 push
Sonic 서버 내 local git 에 커밋

#2.1.3. 클라이언트팀에서 다운로드 (Zip Streaming)

쿠키런: 킹덤은 Unity를 통해 개발되었습니다. Unity는 IDE 내에 커스텀 UI를 추가할 수 있는데, 클라이언트 개발자 한 분께서 이 기능을 활용해 번들 목록을 표시하고 특정 Revision으로 checkout 하는 UI를 만들어 주셨습니다.

Unity UI는 REST API를 통해 Sonic 서버에서 전체 Revision 목록을 받아와 표시합니다. 이때 Sonic 서버는 내부적으로 git history -n 20 커맨드를 사용해, 최근 20개 히스토리만 보내줍니다.

현재 Unity 에서 가지고 있는 사운드 파일이 Rev.98, 새로 Sonic을 통해 checkout 하고 싶은 번들을 Rev.100라 가정해 보겠습니다. Rev.98에서 Rev.100으로 checkout하는 플로우는 아래 그림과 같습니다.

Checkout flow

Sonic 서버에 Rev.100 checkout 요청 (REST GET).
Sonic 서버는 git diff Rev.98 Rev.100를 통해 차이가 있는 파일 리스트업.
S3에서 해당 Revision에 있는 파일들의 Download stream들을 열고 → 이를 Archiver의 input stream으로 넣고 → Archiver의 output stream을 클라이언트로 향하는 Response로 pipe.
Unity는 Response로 Rev.98과 Rev.100 사이 변경된 파일들의 zip 파일을 받음.

그다음 다운로드 받은 파일에 암호화 + 최적화 작업을 한 후, 소스코드에 commit 하게 됩니다.

#3. 스펙 줄이기

#3.1. Push된 번들 수정 / 삭제

Sonic은 단순한 구조와 안정성을 위해 (마치 블록체인처럼) 수정/삭제가 불가능하게 설계되었습니다.

수정/삭제는 자주 있는 상황이 아닌데 반해, 이를 구현하려면 복잡성이 너무 커진다고 판단했기 때문입니다.

내부적으로 Git 을 쓰기 때문에 수정/삭제는 force push를 사용해야 하는데, 아래와 같은 문제가 생깁니다.

수정된 commit 이후의 commit hash 가 모두 변함
- git tag 로 관리되는 revision 정보가 꼬임
이미 발송된 slack 알림과 정보 불일치 발생 (진실의 근원이 한곳이 아니게 됨)

대신 아래와 같은 우회법으로 대응하였습니다.

수정 : 해당 revision에 추가적인 suffix를 붙여 한번 더 push하도록 요청 (ex. 100-2)
삭제 : 삭제 전용 revision을 만드는 기능 추가 (ex. 100-DEL)

#3.2. Race Condition (Merge Conflict)

만약 사운드팀에서 두 명의 팀원이 동시에 push를 하면 어떻게 될까요?

(push가 꼬여버리는 상황 방지를 위해 critical section에 lock은 걸어 두었습니다.)

백엔드 시점으로 먼저 요청이 도착한 유저를 A, 늦게 도착한 유저를 B라 하겠습니다.

Git이었다면 A는 요청이 성공하고, B는 요청이 실패해 다시 최신 pull을 받은 다음 push 해야 합니다.

Sonic도 이렇게 구현할 수 있지만, 사용자가 이런 경우를 신경쓰지 않아도 되도록 backend에서 B를 자동으로 rebase한 뒤 commit 하게 하였습니다.

이런 구조가 가능했던 이유는 Sonic에서 데이터는 단방향으로만 흐르기 때문입니다.

Merge Conflict 는 push 한 팀이 다시 pull 을 받는 경우에 필요한데, Architecture Diagram을 다시 보면 사운드팀이 push한 파일을 사운드팀이 다시 pull 받지는 않습니다.

실제로 Revision 이라는 단위는 사운드팀 내부적으로 버전 컨트롤이 끝난 단위이며, Sonic은 단순히 이를 전달해 주기만 할 뿐입니다. 때문에 Merge conflict는 Sonic에서는 불필요한 개념인 것입니다.

#마치며

여러분들은 맥도날드에서 키오스크로 주문을 해 보신 적이 있으신가요? 주문 완료까지 10번에 가까운 터치를 해야 하는 키오스크를 보며 *“이 키오스크는 내가 할 수 있는 게 많아서 좋아!”*라고 생각하셨나요, *“햄버거 하나 주문하는게 왜 이리 복잡해!”*라고 생각하셨나요? 아마 후자가 더 많을 것이라 생각합니다.

Sonic은 필요한 인터페이스만 사용자에게 노출했으며, 내부 구현도 바닥부터 로직을 구현한 것이 아니라 이미 있는 시스템을 잘 연결해 주기만 했습니다.

단순하고 제한적인 스펙에도 불구하고 사용자분들께 사운드 리소스 동기화를 위한 공수가 거의 없어졌다는 피드백을 들을수 있었으며, 실제로 첫 배포 이후 8개월간 큰 이슈 없이 쿠키런: 킹덤에 들어가는 모든 사운드 리소스의 전달을 수행해 낼 수 있었습니다. 여러분들께서도 앞으로 서비스 기획이나 코드를 작성하실 때, 정말로 필요한 것이 무엇인지 고민해 보실 수 있으면 좋을 것 같습니다.

조직문화 담당자가 개발조직에 뛰어든 이야기

Fri, 26 May 2023 00:00:00 GMT

안녕하세요. 저는 데브시스터즈 진저랩 테크컬처셀에서 일하고 있는 전경아입니다. 평범한 인사담당자였던 저는 2021년부터 테크 컬처 매니저로 근무하고 있습니다. 이 글을 통해, 테크 컬처 매니저가 무엇인지와 어떤 일을 하는지를 소개해 드리려고 합니다.

#테크 컬처 매니저는 무엇인가요?

이 글을 읽는 대부분의 독자는 소프트웨어 개발과 관련 있는 직업을 가진 분이라 생각하는데요, 혹시 조직문화 담당자가 개발조직 소속인 걸 보신 적 있으신가요? 요즘은 IT기업을 중심으로 DevRel(Developer Relations)이라는 직무가 점점 많아지고 있는데, 제가 입사할 당시만 해도 아직 많이 알려지지는 않은 직무였습니다. 저 역시도 이전에는 일반적으로 인사팀, 경영지원, 경영관리, HR 등의 이름이 붙여진 조직에서 인사 업무를 해왔었고, 직접 개발조직 소속으로 그리고 조직문화 담당자로 일하는 것은 이번이 처음입니다.

정의하는 곳마다 다르겠지만, 저는 테크 컬처 매니저를 ‘개발 조직에 특화된 문화를 만들고 가꾸어 나가는 사람’이라고 생각합니다. 그러기 위해, 우리만의 뛰어난 기술 수준을 내외부에 적극적으로 알리는 것뿐만 아니라 지속적으로 구성원들이 업무에 몰입하고 성장할 수 있도록 구성원들과 함께 우리 조직에 가장 알맞은 조직문화를 기획하고 운영해 나가고 있습니다.

직무에 ‘테크'가 들어간다고 해서 기술적인 부분을 굉장히 잘 알아야 하는 것은 아닙니다. 예를 들어 기술적인 요청을 직접 처리하거나, 점검이나 장애 대응을 하지는 않습니다. 다만, 우리의 동료들이 어떤 일을 하는지를 알아야 현재 어떤 고충이 있고 어떻게 행동하면 좋을지 생각할 수 있기 때문에 꾸준히 관심을 두어야 합니다.

제가 오늘 새로 들은 용어는 DLQ(Dead Letter Queue)인데요, 이것이 무슨 원리로 어떻게 동작하는지, 어떻게 해결해야 하는지는 몰라도 괜찮습니다. 단지 이런 이슈를 어떤 분들이 대응한 지 기억해 두었다가 ‘그거 잘 해결하셨나요?’하고 한마디 붙여볼 수단으로 사용할 수 있겠죠.

#테크 컬처 매니저는 어떤 일을 하나요?

먼저 데브시스터즈 진저랩을 소개해 드리자면, 데브시스터즈의 모든 게임과 제품을 효율적이고 안정적으로 제공하여 사용자들에게 최고의 즐거움을 전달할 수 있도록, 데이터/QA/인프라/웹/플랫폼 등 다양한 직군의 전문가들이 모여 서비스를 개발/운영하고, 탄탄한 플랫폼을 구축하는 조직입니다.

테크 컬처 매니저는 이런 각 분야의 전문가들과 함께 지내며 문화와 관련된 문제들을 풀어나가고 있습니다. 구성원들의 심리적 안전감(psychological safety)을 조성하고, 서로 성장할 수 있도록 피드백 프로그램을 운영하거나, 행동강령을 만드는 일 등 건강한 문화가 정착될 수 있도록 일하고 있습니다. 또한 ‘테크’ 컬처 매니저다 보니, 회사의 개발문화도 함께 가꿔나가고 있습니다. 일반적으로 중앙조직에 있는 조직문화 담당자보다 구성원들을 더 가까이에서 만나며 일하고 있다고 생각합니다.

저도 이 직무를 시작한 지 이제 1년이 조금 넘었기 때문에, 아직 어떤 일을 어떻게 해야 하는지 찾아가는 중입니다. 그래서 그동안 저에게 의미 있었던 몇 가지 일을 소개해 드리고자 합니다.

#심리적 안전감 설문지

첫 출근 날, 코로나로 인해 사무실이 휑했지만, 화상으로 다들 반겨주셨던 점이 기억납니다. 그리고 CTO인 그룹장님이 각 셀이 하는 일과 클라이언트와 서버가 어떻게 동작하는지 간단히 알려주셨는데 ‘지금 들으셔도 잘 기억 안 날 수 있는데 다음에 궁금하시면 또 물어보세요.' 라고 말씀해 주신 것이 가장 기억에 남습니다. 지금 돌이켜보면 개발조직에서 어쩌면 기본적인 부분(클라이언트와 서버 동작 원리 등)인데도, 모르는 것이 생길 때마다 여쭤보면 친절하게 알려주셨습니다. 물론, 지금도 궁금한 것이 생기면 옆 동료나 그룹장님께 물어보고 있습니다.

어떻게 이런 일이 가능할까요? 그건 바로 심리적 안전감이 조성된 조직이기 때문이라고 믿습니다. 심리적 안전감이란 질문을 하거나 의견을 제시하거나 부족한 점을 보일 때 무시당하거나, 불이익 또는 비난을 받지 않을 것이라는 믿음입니다. 이를 통해 서로 눈치 보지 않고 아이디어를 내거나, 실수를 통해 배운 점을 공유하며 효율적으로 일할 수 있습니다.

우리 조직은 심리적 안전감이 잘 조성된 편이라고 느끼지만, 모두에게 계속해서 잘 작동하고 있는지 설문을 통해 주기적으로 살펴보고 있습니다.

분기별로 설문을 진행합니다.
설문지 답변을 보고 특이사항이 있는 분들은 따로 1on1(1대1 면담) 일정을 잡습니다.
요즘 어떤 것이 몰입을 방해하거나 어려움을 주는지 물어봅니다.
후속 조치가 필요하다면 그룹장, HR 조직, 심리상담가 등 적절한 사람과 연결해 줍니다.
이후 지속적으로 모니터링합니다.

이 설문과 후속 면담을 통해 퇴사위험을 미리 발견하고 방지한 사례도 있어서 이 글을 읽는 다른 분들도 진행해 보시면 조직 운영에 도움이 될 것이라고 생각합니다. 다만 구성원들이 설문지에 솔직하게 답변하거나 1대1 면담을 부담스러워하지 않도록 사전에 신뢰를 잘 구축해 두는 것 또한 중요하다고 생각합니다.

또한, 신규입사자를 대상으로 심리적 안전감에 대한 이해를 높일 수 있는 교육 시간을 마련하여 조직에 새로 합류한 분들도 빠르게 적응할 수 있도록 돕고 있습니다.

이외에도 저희 조직에서는 다양한 방법으로 독특하고 건강한 문화를 만들어 나가고 있습니다.

#행동강령

개인의 노력이 모여 조직의 문화를 만들기도 하지만, 조직에서 문화를 먼저 조성하는 방법도 있습니다. 바로 다른 회사나 컨퍼런스에서도 사용하는 행동강령입니다. 제가 입사할 때 가장 큰 미션으로 생각하던 일이기도 한데요, 행동강령이란 우리가 믿는 방향으로 말하고 행동하자는 약속입니다. 이를 통해 잘 몰라서 실수하거나 도움이 필요한 동료에게 적절히 개입할 수 있습니다.

진저랩만의 문화를 만드는 것에 앞서, 데브시스터즈의 문화와 정렬을 맞추는 것도 중요하기 때문에 데브시스터즈의 조직문화를 살펴보았습니다. ‘정보의 공유’, ‘역할 기반 조직 문화’, ‘자율과 책임을 바탕으로 스스로 책임을 다하는 문화’, ‘용기 있는 소통을 통한 탁월한 문제 해결’, ‘신뢰와 열린 커뮤니케이션’이 있습니다.

데브시스터즈의 조직 문화

그다음, 진저랩 문화 가꾸기에 관심 있는 구성원들과 데브시스터즈 조직문화를 바탕으로 행동강령 TF(Task Force)를 만들었습니다. TF 구성원들과 함께 우리가 해야 할 행동과 하지 말아야 할 행동을 나열한 다음 치열한 토론 끝에 행동강령을 완성하였고, 구성원들의 쉬운 이해를 돕기 위해 각각 현실적인 예시도 추가하였습니다.

진저랩 행동강령의 일부

초기 버전을 만드는데 10여 명이 모여 많은 시간을 썼는데요, 모두의 노력으로 어렵게 만든 만큼 한번 만들고 끝내는 것이 아니라 오늘의 우리에 맞게 계속해서 업데이트 해나가고 있습니다.

행동강령의 존재는 기존 구성원들에게도 중요하지만, 조직에 새롭게 합류한 신규입사자분들께도 진저랩의 분위기와 일하는 방법 등을 익히는 데 도움이 되기 때문에 입사 후 가장 먼저 읽어보길 권하고 있습니다. 그럼으로써 더욱 빠르게 우리의 문화와 정렬을 맞추고 행동할 수 있게 됩니다.

#기술 블로그 프로모션 이벤트

위 두 가지가 제가 소속되어 있는 진저랩의 문화를 위한 일감이라면, 이번엔 데브시스터즈 전체를 대상으로 진행한 개발 문화 관련 일감을 소개해 드리겠습니다.

우리가 기술적으로 어떤 문제를 멋지게 해결해 왔는지 글을 통해 외부에 널리 알리고, 잠재적 지원자들에게 매력적인 인상을 남길 수 있는 기술 블로그를 활성화해 보고자 하였는데요, 이를 위해 기술 블로그 원고 투고 행사를 진행하였습니다.

기술 블로그 원고 투고 행사

라이브 서비스, 신작 개발 등 업무를 진행하느라 바빠서 글 쓸 시간이 부족한 구성원들의 부담을 줄여드리고자 많은 분의 의견을 듣고 고민하였습니다. 최종적으로는 여러 유관부서와 협업하여 행사를 워케이션 형태로 구성해 보았습니다. 잠시 일에서 떠나 그동안 해결했던 문제나 기존에 관심 있었던 분야를 잠자고 있던 글솜씨로 마음껏 풀어내고, 서로의 글을 검수하고, 글쓰기 노하우도 전수하며 진행되었습니다.

당시 이벤트에 참여한 글들은 총 9편으로, 기술 블로그 뒤 페이지에서 확인하실 수 있습니다. 그 이후로도 데브시스터즈에 있었던 다양한 경험을 담은 글이 올라오고 있으니, 꾸준히 방문하셔서 둘러보시면 좋은 인사이트를 얻을 수 있으리라 생각합니다.

#월간 직군 모임

데브시스터즈에는 월간 서버, 월간 데이터, 웹 직군의 밤 등 월 단위로 진행하는 직군 모임이 존재합니다. 이름에서도 유추할 수 있듯이 각각 서버, 데이터, 웹 관련 업무를 하며 마주했던 문제를 해결하는 과정이나 컨퍼런스 방문기 등을 세미나 형식으로 공유하고 있습니다.

직군별로 지식 공유라는 필요를 느끼고 자율적으로 구성된 직군 모임이지만, 참석하시는 분들께 더욱 의미 있는 시간을 만들고 우리의 개발 문화 활성화를 위해 테크 컬처 매니저도 함께 고민하고 논의하며 운영해 나가고 있습니다. 직군 모임 진행을 도와드리기도 하고, 참석을 못 하신 분들을 위해 녹화를 하거나, 피드백을 수집하여 더 나은 모임으로 발전시키는 일 등을 하고 있습니다.

월간 서버 세미나 리스트

또한, 간혹 연사가 없을 때 주변 동료들을 열심히 찌르며 발표를 독려하기도 하고, 발표하신 동료들에게 드릴 선물도 준비하고 나눠드리며 우리의 지식이 더 잘 공유될 수 있도록 계속해서 개선해 나가고 있습니다. 최근에는 다른 팀과의 교류 시간이 좀 더 있으면 좋겠다는 피드백을 받아서 모든 팀이 함께 어우러져 친목을 다질 수 있는 시간도 준비 중입니다.

#Scala 개발자 MEET-UP

데브시스터즈 전체뿐만 아니라 개발팀과 함께 개발 커뮤니티를 위한 업무도 진행했습니다. 쿠키런: 킹덤의 서버는 Scala(이하 스칼라)로 개발하고 있는데요, 그중 한 개발자분께서 제안해 주셔서 스칼라 개발자 커뮤니티를 활성화하고 쿠키런: 킹덤의 멋진 기술력을 홍보하고자 스칼라 개발자 밋업을 개최하였습니다.

쿠키런: 킹덤 서버 개발자 총 3분을 연사로 모셔서 아래와 같은 주제로 발표를 진행했습니다.

쿠키런 킹덤이 Spark를 쓰는 조금 특별한 방법 - Event Sourcing Architecture에서 데이터 추출하기
Migration to ZIO 2
순수히 아름다운 쿠키런 킹덤 도메인 로직

스칼라 커뮤니티에 행사를 홍보하기 위해 진저랩 테크니컬라이팅셀의 도움으로 행사 노션 페이지를 만들었으며(coo.kie.run/scala-meetup; 깨알 정보-진저랩 인프라셀에서 만든 url 단축 내부 서비스 ‘쇼트닝’을 이용하였습니다.) 행사에 방문하시는 분들을 위해 대외 커뮤니케이션을 담당하는 임팩트그룹의 도움을 받아서 많은 분이 귀여워해 주셨던 스티커도 만들었습니다.

또한, 많은 인원이 모이는 행사인 만큼 혹시 모를 실수나 사고를 방지하기 위해 행동강령을 만들어 게시하였습니다. 다행히 참석하신 분들 모두 행동강령을 공감해 주시고 잘 따라주셔서 특별히 문제가 발생하지 않았습니다. 마지막으로는 네트워킹 시간을 마련하여 저녁 식사와 함께 참석자들이 각자 다채로운 스칼라 사용 경험을 공유하며 자유롭게 이야기를 나누는 시간으로 꾸렸습니다.

데브시스터즈에서 일하면서 가장 많은 부서의 동료들과 협업하며 준비한 행사인 동시에 처음으로 외부에 공개하는 행사다 보니 준비 과정에서 걱정이 많았는데요, 많은 분과 힘을 합쳐 무사히 마무리할 수 있어 개인적으로도 굉장히 의미 있던 시간이었습니다. 또한, 데브시스터즈에는 회고 문화가 일상화되어 있어서 행사 다음 날 진행자들이 모여 회고를 하였고, 잘한 점과 개선해야 할 점을 도출하여 문서로 정리하여 내부에 공유하였습니다. 앞으로도 스칼라를 비롯하여 다양한 테크 밋업을 개최할 예정이니, 관심 있으신 분들은 다음에 방문하셔서 다양한 경험을 나눠주시면 좋겠습니다.

스칼라 밋업 현장

#마치며

테크 컬처 매니저가 진행하고 있는 몇 가지 일을 소개해 드렸습니다. 이외에 우리의 좋은 문화나 일하는 방법을 글로 남겨서, 기존 구성원이 퇴사하거나 새로운 분들이 입사해도 계속해서 진저랩의 문화와 구성원의 정렬을 맞출 수 있도록 하고 있습니다. 또한, 구성원들의 업무 몰입을 높이고, 우리만의 독특한 문화를 발전시키기 위해 동료들과 함께 고민하고 연구하며 하나씩 실행해 보고 있습니다. 마지막으로, 기술 지식 공유 활동도 강화하여 우리 모두 함께 성장할 수 있는 환경을 조성하고자 노력하고 있습니다.

테크컬처셀 일감 중 일부

글을 다 읽으신 지금, ‘개발조직에서 일하는 조직문화 담당자’가 있기 때문에 함께 일하는 동료들이 그들의 문제 해결에 집중할 수 있다고 말씀드릴 수 있습니다. 여러분의 조직에도 테크 컬처 매니저를 모시는 것은 어떠신가요? 혹은 지금, 이 글을 읽고 계신 여러분도 테크 컬처 매니저에 있는 조직에서 한번 일해보고 싶지 않으신가요? 데브시스터즈와 진저랩의 문은 언제나 열려있습니다. 직무나 조직문화 관련하여 궁금한 점이 있거나 이야기 나누고 싶은 부분이 있으면 tech_blog@devsisters.com로 언제든 연락해 주시길 바라며, 다음에 또 흥미로운 조직문화를 소개해 드리도록 하겠습니다. 감사합니다.

쿠키런: 킹덤 길드 업데이트 이후 서비스 이슈 되돌아보기

Wed, 19 Apr 2023 00:00:00 GMT

이 글과 관련된 다른 글 보기

쿠키런: 킹덤 런칭 회고 - DevOps 관점에서 본 쿠키런: 킹덤 런칭 회고
CockroachDB in Production - CockroachDB에 대한 소개와 킹덤에서 CockroachDB를 사용한 이유 설명
쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기 - 엔지니어 관점 기록한 개괄적인 장애 대응 과정과 회고
CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기 - CockroachDB의 소스코드를 참고하며 바이너리 파일로부터 데이터를 복구한 이야기
입사 첫날에 36시간 점검 경험하기 - 신규입사자의 관점에서 서술된 장애 대응 기록
쿠키런: 킹덤 AWS AZ 장애 아웃라인 - AWS AZ 장애로부터 서비스를 복구한 이야기

안녕하세요, 데브시스터즈 진저랩 인프라셀에서 데브옵스 엔지니어로 일하고 있는 이상유입니다.

지난 NDC22의 쿠키런 킹덤: 총 56시간의 긴급 점검 회고를 보셨던 분이라면, 그 당시 시간 관계로 미처 이야기하지 못했던 주제가 하나 있었다는 것을 기억하실 것이라고 생각합니다.

이 글에서는 바로 그 주제, 21년 3월 길드 업데이트 이후 발생했던 서비스 이슈에 관해 다루고자 합니다.

#Hot Range(혹은 Hot Spot)

이전에 게시된 글을 읽어보신 분들이라면,

쿠키런: 킹덤은 CockroachDB라는 데이터베이스를 사용하고 있다
CockroachDB는 SQL 인터페이스를 제공하는 분산 데이터베이스이다
분산 처리와 고가용성을 위해, CockroachDB는 데이터를 쪼개 ‘Range’라는 단위로 저장한다

는 부분을 이미 알고 계실 것입니다.

혹 이전 게시글을 읽어보지 않으셨더라도, 위 3개 내용을 알고 계신다면 이 글을 무리없이 이해하실 수 있도록 구성했습니다. CockroachDB에 대해 더 깊게 알아보고 싶으시거나, 데브시스터즈에서 어째서 CockroachDB를 사용하도록 결정했는지 궁금하신 분은 CockroachDB in Production을 읽어보시기를 추천합니다.

CockroachDB는 Range별 용량과 초당 쿼리수를 종합해 자율적으로 Range를 병합하거나 분리합니다. 초기 설정에서 Range 용량은 128MB에서 512MB 사이를 유지하도록^[1], 그리고 Range에 초당 2500쿼리 미만의 요청이 가해지도록^[2] 설정되어 있습니다. 때문에 CockroachDB 클러스터를 관리하다 보면, 쿼리가 자주 일어나는 Range는 알아서 잘 분산되어 여러 노드에서 작업을 처리하고, 쿼리가 자주 일어나지 않는 Range는 합쳐지는 동작을 관측할 수 있습니다.

이러한 동작 덕분에, 부하가 장기간에 걸쳐 점진적으로 늘어나는 경우에는 관리자가 CockroachDB 클러스터에 대해서 해주어야 할 동작은 많지 않습니다. CPU나 메모리, 스토리지와 같은 리소스가 부족한 경우, 이에 맞춰 새 노드를 추가해주면 CockroachDB 클러스터에서 우아하게 Range를 분산하여, 모든 노드가 비슷한 양의 데이터와 부하를 처리하도록 조절합니다.

하지만 이런 아름다운 그림이 모든 상황에서 그려지는 것은 아닙니다. CockroachDB에서는 Primary Key를 go의 빌트인 인코딩/디코딩 메소드를 사용하여 정렬한 뒤 일정 간격으로 나누어 Range를 만들어냅니다^[3]. 이러한 알고리즘에 따라 유사한 키 값은 동일하거나 인접한 Range에서의 작업이 될 가능성이 높으며, 이렇게 대부분의 워크로드가 몰린 Range를 Hot Range 또는 Hot Spot이라고 합니다.

Hot Range는 결과적으로 해당 Range를 관할하는 노드들에서만 전체 부하를 처리하는 결과를 초래해, 클러스터가 제 성능을 낼 수 없도록 만들게 됩니다.

이러한 배경 지식을 가지고, 장애가 발생한 날로 떠나 보겠습니다.

#[05:00] 길드 업데이트

길드 기능 업데이트 점검에서, 쿠키런: 킹덤의 데이터베이스 클러스터에는 2가지 작업이 진행되었습니다.

첫째로 길드 기능에서 사용하는 테이블을 추가하고, 사전에 부하를 분산하도록 설정하였습니다. 길드 기능에서 사용하는 테이블들은 아직 CockroachDB가 부하를 분산할 수 있는 정보를 가지고 있지 않기 때문에, 서비스 오픈 직후 길드 기능에서 사용하는 테이블에서 Hot Range가 발생할 가능성이 높습니다. 이를 미연에 방지하기 위해, 길드 관련 테이블들의 Range를 강제로 분할하고, 이를 클러스터 전체에 나누어주도록 작업하였습니다.

둘째로 당시 점검 며칠 전 데이터베이스 노드 한 대가 물리 장비 이슈로 제거된 상태였는데, 새 노드를 추가하여 데이터베이스 규모를 원래 의도한 규모로 복원하였습니다. 길드 업데이트를 위해 점검이 필요했고, 이를 위해 데이터베이스 백업 등 안전한 작업에 필요한 제반 준비가 되어야 하는 상황이었기에, 이 기회를 틈타 함께 작업을 진행하였습니다.

점검 중 인프라 외적인 사유로 점검이 2시간가량 연장되었으나, 2021년 3월 6일 11시, 모든 문제를 해결하고 점검이 마무리되었습니다. 이후 모니터링 중, 데이터베이스의 CPU 사용량이 예상보다 조금 높다는 것을 확인했으나 당시 접속중인 유저가 평시보다 많은 점, 그리고 새롭게 상호작용하는 기능이 추가되었다는 것을 고려했을 때 우려하지 않아도 될 것으로 판단했습니다.

#[11:30] 불길한 신호는 항상 현실이 되고

그렇지만 우려하지 않아도 된다는 것이 특별한 조치를 취하지 않아도 된다는 것이지, 마음을 놓을 수 있다는 의미는 아니죠. 많은 유저분들이 새 업데이트를 즐겨주시고 있다는 것에 기뻐하며 서버 상태를 지켜보던 중, 굉장히 슬픈 소식이 들려오고 맙니다.

24코어 머신에서 24코어를 몽땅 다 사용중인 안타까운 모습

그것은 바로 한 노드의 CPU 사용량이 천장을 찍었다는 소식이었습니다. 이와 동시에 서버 지표에서도 유의미한 양의 에러가 관측되기 시작했습니다. 모두가 탄식하며 일시적인 현상이기를 기도하던 그때, 야속하게도 다른 두 노드에서도 CPU 사용량 이상이 확인되었습니다.

모종의 이유로 로드가 고르게 분배되지 않고 있으며, 이 때문에 특정 노드가 과도한 로드로 데이터베이스 클러스터 안정성에 악영향을 주고 있다는 사실을 받아들여야 하는 순간이었습니다.

#저희가 무엇을 잘못했나요

이야기를 더 진행하기 앞서, 무엇이 이런 상황을 만들었는지 정리해 봅시다.

근본적인 원인은 저희가 사전에 인지하지 못한 인덱스의 prefix 구조 추가와 변경이었습니다.

쿠키런: 킹덤의 게임 서버는 실제 플레이 데이터 이외에도, 더 나은 플레이 경험을 위한 데이터 분석을 위해 여러 가지 정보를 DB에 기록합니다. 이 때 사용되는 테이블은 용도에 따라 <feature>-<uuid> 형식의 Primary Key를 가집니다. 이 테이블은 런칭 초기에도 Split을 하지 않았었고, 그 상태로도 문제가 발생하지 않았기 때문에 명시적인 Split이 필요없는 테이블로 여겨졌습니다.

나중에 알고 보니, 런칭 초기에는 모든 유저들이 게임 시작 후 거치는 튜토리얼이 거대한 Funnel로 작용해 유저들이 이 테이블에 쓰기를 하는 시점이 제각각 달랐고, 이 덕분에 Hot Range 없이 자동적인 Split이 자연스럽게 수행될 수 있었습니다. 이와 달리 길드 업데이트의 경우 모든 킹덤 유저가 기다려오던 기능이었고 초기 Funnel 또한 거의 없도록 설계되었습니다. 따라서 업데이트 직후 모든 유저들이 이 테이블에 쓰기 활동을 하게 되어 아주 많은 수의 guild-<uuid> 형식의 Primary Key가 매우 빠르게 쓰여졌고, 결과적으로 시스템에 의한 Split이 미처 수행되지 못해 Hot Range가 발생한 것이 첫번째 원인이었습니다.

두번째로, 신규 기능이 추가되며 코드 리팩토링이 진행되었고, 겸사겸사 Primary Key의 형태가 변경된 경우도 있었습니다. 이 테이블의 경우 기존에 활발하게 쓰이고 있었고 Split도 잘 되어있었지만, PK의 포맷이 달라지면서 Split되어 있던 Range의 극히 일부만 실제로 사용되도록 변경되었고, 이 또한 마찬가지로 Hot Range를 발생시켰습니다.

종합적으로 이 테이블들은 1. 기존에 이미 존재하던 테이블이고, 스키마 변경이 없었기 때문에 잘 눈에 띄지 않았고, 2. 플레이에 직접적인 트래픽을 받지 않기 때문에 Hot Range가 발생할 것이라고 미처 판단하지 못했습니다.

그러나 여기까지만 해도 상황이 심각해지지는 않았을 수도 있습니다. CockroachDB에는 자체적인 부하 기반 Range 분산 로직이 있기 때문에, 시간이 지남에 따라 클러스터가 자가 회복하기를 기대해볼 수 있기 때문입니다.

이 문제를 더욱 키운 것은 새 DB 노드를 추가한 것이었습니다. CockroachDB는 새 노드를 클러스터에 추가하는 경우 기존 노드들이 가지고 있던 Range를 자동으로 분산하여, 모든 노드들이 비슷한 양의 작업을 할 수 있도록 만들고자 시도합니다. 이 때 Range가 이동하는 작업은 기존 Range를 분할하여 이동시키는 작업과 같은 큐를 사용합니다. 점검 중에 새 노드가 추가되며 발생한 Replication Queue가 오픈 때까지 충분히 해소되지 않았고, 새 노드에 Range들이 모두 분산된 뒤에야 Hot Range가 분산될 수 있었습니다.

정리하면, 사전에 부하를 분산하지 않은 테이블에서 Hot Range가 발생하여, CockroachDB에서 부하 분산을 시도했으나 노드 추가로 트리거된 Range 분할로 인해 해당 부하를 분산하지 못하였고, 이로 인해 DB가 과부하되어 발생한 문제였습니다.

#[11:55] 점검만은 안 돼

하지만 이번 문제는 앞서 게시된 두 번의 이슈^[4]와는 조금 달랐습니다. 이전의 상황은 데이터베이스가 데이터 로드를 거부했거나 데이터를 검증해줄 수 있는 서버 자체가 사라져 데이터의 정합성을 검증하지 못한 문제로, 이를 복구하기 위해 데이터베이스를 종료하고 storage layer에서 데이터를 조각모음 하는 등의 액션이 필요했습니다. 하지만 지금은 단순히 데이터베이스의 일부 노드에 일시적으로 과도한 부하가 가해져 CockroachDB 내부 로직이 동작할 시간이 부족한 것이어서 이 부하만 해결되면 상황이 호전될 것으로 기대되었습니다.

이러한 기대를 안고, 저희는 이제 점검 없이 서버에 가해지는 부하를 줄일 수 있는 방법을 찾기 시작했습니다.

다만 문제는, 저희가 선택할 수 있는 방법이 많지 않다는 점이 었습니다. 순간적인 부하를 줄이기 위해서 사용하는 가장 일반적인 방법은 접속 대기열을 운영하는 것인데, 쿠키런: 킹덤의 서버 아키텍처는 수평적인 확장이 가능하도록 특히 많은 고민과 노력을 기울인 만큼 접속 대기열이 필요할 상황 자체가 존재하지 않아야 했기에 대기열이 마련되어 있지 않았습니다. 그렇다면 유저 접근을 제한할 수 있는 방법은 점검뿐인데, 점검 없이 서버에 가해지는 부하를 줄인다는 고민과는 공존할 수 없는 방법이었습니다.

이러지도 저러지도 못하고 시간이 지나가던 중, ‘점검이 아닌 점검을 하자’라는 의견이 나왔습니다.

#[13:00] 점검 아닌 점검

쿠키런: 킹덤의 점검은 새로 접속하는 유저의 접속을 거부하는 부분과, 이미 게임을 플레이중인 유저를 강제로 접속 종료시키는 부분이 완전히 분리되어 존재합니다. 이 아래부터는 전자를 ‘로그인 블록’, 후자를 ‘유저 킥’으로 표현하겠습니다.

일반적인 점검 때에는 로그인을 블록한 뒤 기존 유저를 킥하는 동작을 함께 진행하지만, 두 동작은 앞서 언급한 대로 분리되어 존재하기 때문에 따로 실행하는 것 또한 가능합니다.

접속 대기열은 기본적으로 유저의 접속을 인위적으로 제한하면서, 동시에 원하는 만큼만 유저가 접속할 수 있도록 만드는 기능입니다. 킹덤의 점검에도 로그인하는 유저만 블록할 수 있는 방법이 존재합니다. 그럼 점검을 대기열처럼 사용할 수 있지 않을까요?

기존 유저를 킥하지 않고 로그인을 블록하는 것으로, 입장 인원을 0명으로 설정한 대기열과 같은 효과를 낼 수 있습니다. 이렇게 되면 이미 게임에 접속해 플레이하던 유저는 아무런 영향을 받지 않으면서, 서버에 가해지는 부하를 적절한 수준으로 관리할 수 있습니다. 접속에 성공한 유저가 게임에 접속하여 하려던 행동을 모두 완료하면 게임을 종료할 것이므로, 새로 게임에 접속하려는 유저를 제어하면 동시 접속자는 자연적으로 감소할 수밖에 없기 때문입니다.

그렇다고 계속 로그인을 블록하면 안 됩니다. 우리가 원하는 것은 대기열 기능으로, 유저분들이 기다리다 보면 어느 순간 게임에 접속되어 플레이하는 경험을 기대하기 때문입니다. 걸어둔 점검을 종료하면, 기다리시던 유저 분들께서 게임에 접속할 것이고, 지표를 참고하며 이를 반복하면 결국 동시에 원하는 만큼만 유저가 접속할 수 있도록 하는 대기열의 역할을 수행할 수 있게 됩니다. 점검이라는 방법을 사용하여 서비스 점검을 피한, ‘점검 아닌 점검’인 셈입니다.

이렇게 임시로 만든 대기열을 가지고 동시 접속자 수를 조절한 결과, 데이터베이스 클러스터가 상당히 안정되는 것을 확인할 수 있었습니다. 우아한 방법은 아니지만, 아무도 쿠키런: 킹덤에 접속하지 못하는 상황을 만들지 않고도 장애 상황을 해결할 수 있을 것이라는 희망이 보이기 시작했고, 이대로 지켜보며 클러스터 상황이 정상으로 돌아오기를 기다리자고 결정하게 되었습니다.

#[14:50] 진짜 긴급점검

그렇게 안정화 작업을 진행하던 중, 오후 2시 50분, 클러스터를 구성하는 노드 여러 대가 갑자기 health check를 통과하지 못하기 시작했습니다. 이때는 점검 직후 상황과 비교했을 때 더 많은 노드들이 영향을 받았고, 때문에 이 이상 문제가 전파된다면 데이터 안정성에도 영향이 갈 수 있다고 보여졌습니다. 때문에 클러스터가 불안정해진 직후, 긴급히 아무도 게임을 플레이할 수 없는 진짜 긴급점검을 수행하기로 결정했습니다.

점검을 시작한 직후부터 클러스터 상태가 눈에 띄게 좋아지는 것을 확인할 수 있었습니다. 당연한 결과이기도 했는데, 문제의 원인이 Hot Range에 있다고 예상된 이상 더 이상 유저 요청을 받지 않는다면 문제가 되는 Range를 사용하지도 않을 것이기 때문입니다. 다만 이를 실제로 확인함으로서 저희가 정의한 문제 상황과 해결 방법이 맞을 것이라는 확신을 가질 수 있었습니다.

하지만 그렇다고 이 클러스터를 그대로 계속 쓸 수 있다는 확신은 없는 상태였습니다. 클러스터가 불안정해지며 CockroachDB에서 데이터 정합성을 보증할 수 없어 접근 자체를 막은 Unavailable Range가 발생했고, 클러스터가 안정되며 해당 Range가 다시 접근 가능하다고 표시되었지만 이 클러스터에 문제가 발생하지 않을 것이라고 확답할 수 없었기 때문입니다. 여전히 데이터베이스의 여러 지표들은 클러스터가 아직 완전히 정상으로 되돌아오지 않았다고 말하고 있었고, 이전의 경험을 바탕으로 더욱 더 신중히 의사결정을 하고자 하였습니다.

일련의 데이터베이스 연관 장애를 겪으면서 저희 팀의 목표는 늘 유저 분들이 정성들여 키우신 소중한 왕국의 데이터를 지키는 것이었습니다. 언제 무너질지 모르는 데이터베이스 클러스터를 지켜보며, 저희는 우선 클러스터가 조금이라도 안정적일 때 데이터를 백업해 두기로 결정했습니다. 정기적으로 백업이 진행되고 있지만 실시간 백업이 아닌 이상 이는 최후의 수단이고, 점검 이후 데이터를 백업해 두면 클러스터가 돌아올 수 없는 강을 건너더라도 유저 임팩트는 없을 것이니까요. 백업 이후에 클러스터가 완벽히 정상화되어 백업한 데이터를 쓸 필요가 없으면 더 좋고요.

#[15:05] 미션: 데이터 백업하기

그렇지만 저희의 간절한 마음을 아는지 모르는지, CockroachDB 클러스터는 데이터 백업을 거부했습니다. CockroahchDB의 BACKUP statement를 사용해 전체 데이터베이스 백업을 시도했으나, 백업이 진행되다 어느 시점에 멈춰버리는 것을 볼 수 있었습니다. 혹시나 알 수 없는 문제 때문에 BACKUP 구문이 동작하지 않는 것일까 싶어 CSV 파일로 export도 시도해 보았으나, 지표상으로 클러스터가 불안정해지는 것을 확인해 중단했습니다.

이때 점검 시간이 길어진 주 원인이 바로 이 백업이 진행되지 않는 문제 때문이었습니다. 클러스터 상태가 불안정한 것이 눈에 보이는데 백업을 안 하고 방치하는 것은 선택지가 되지 않습니다. 그렇다고 백업을 하니 백업이 과연 완료되기는 할지, 된다면 얼마나 기다려야 할지 알 수 없는 상황이었습니다.

어떤 방법을 사용해야 안전하게 데이터를 백업할 수 있을지 찾아내던 중, 전체 데이터베이스가 아닌 테이블 단위 백업을 시도해 보자는 의견이 나왔습니다. 높은 부하가 걸린 것은 특정 테이블의 일부 Range였기 때문에, 이와 관련없는 다른 테이블은 문제없이 백업이 될 것이라는 가설으로부터 도출된 의견이었습니다. 또한 이때 문제가 되는 테이블은 다른 테이블의 정보를 바탕으로 복구 가능한 테이블이었기에, 다른 더 중요한 테이블을 백업할 수 있다면 이 테이블 또한 자연적으로 백업되었다고 볼 수 있는 점도 이러한 결정에 힘을 실어 주었습니다.

정말 다행히도 이 방법을 통해 킹덤 게임 데이터의 백업에 성공했습니다. 이 방법이 동작한다는 것을 확인한 뒤에는, 일단 필요한 모든 테이블을 테이블 단위로 백업한 뒤 클러스터 안정을 기다린 다음 서비스를 오픈하고, 서버에 일정 수준 이상의 부하가 가해질 경우 킥 없는 점검을 통해 부하를 조절하는 것으로 서비스 오픈 계획을 세울 수 있었습니다.

백업 중 진행도가 우려스러울 정도로 올라가지 않는 경우도 몇 번 있었으나, CockroachDB 서포트 팀의 도움으로 무사히 백업을 마칠 수 있었습니다.

이제 손에 데이터를 들고 있기 때문에, 클러스터에 조금 더 도전적인 작업을 시켜볼 수 있게 되었습니다. 이제는 클러스터가 완전히 사용 불능이 되더라도 백업 데이터에서 복원하면 데이터 손실은 없을 것이니까요.

#[18:35] 오픈 준비하기

서비스 오픈을 준비하며, 플레이 기록을 남기는 것은 일시 중지하기로 결정했습니다. 문제가 발생하는 원인은 규명되었고, 오픈 전 해당 테이블의 split을 진행하기로 했으나, 이와 별개로 최대한 데이터베이스에 부하를 가하지 않기 위해 진행한 조치였습니다.

하지만 예측되는 부하를 줄인다고 해도 쿠키런: 킹덤을 플레이해주시는 유저분들이 많다면 Range 분리는 다시 발생합니다. 그리고 앞선 경험을 기반으로, 우리는 이것이 일어나야 하는, 방해받으면 안 되는 작업임을 잘 알고 있습니다.

때문에 이 이후 오픈 준비는

문제가 되었던 테이블이 모두 잘 Split되어 모든 노드에 골고루 로드가 분산되며
CockroachDB의 Range Replication Queue가 0이 되어, 오픈 후 Range Split이 발생하더라도 방해받지 않도록

만드는 것에 초점을 맞추게 되었습니다.

그렇게 오후 6시 반 경, 문제가 되었던 테이블에 대해 Split 액션을 수행하기 시작했습니다^[5].

#[19:20] 좋은 노드, 기다리는 노드, 떠나간 노드

메트릭을 지켜보며 Split이 완료되기를 기다리고 있던 중, 오후 7시 20분 경 슬랙 알림이 한 건 날아옵니다.

OH NO...

바로 데이터베이스 노드 한 대가 Host Status Check를 통과하지 못했다는 알림이었습니다. 이 알림이 발생했을 때 운이 정말 좋지 않은 경우 EC2 인스턴스 자체가 대응할 시간 없이 셧다운되는 상황까지 가는 경우가 있지만, 이 때는 인스턴스가 셧다운되는 상황은 아니었습니다.

동시에 서버들의 이상 로그를 감지하는 채널에 한 메시지가 날아왔는데요, 해당 인스턴스에서 filemap_fdatawait_range_keep_errors라는 로그가 감지되었다는 알림이었습니다.

리눅스 커널에서 filemap_fdatawait은 Write-back Page를 다시 디스크에 작성하는 계통의 메소드인데요, 지금 Range를 옮기고 분리하는 것과 같이 디스크 Write 작업이 많은 상황에서 이러한 로그가 보인다는 것은 좋은 징조는 아니었습니다. Host Status Check이 실패했으니 이 인스턴스 자체도 신뢰할 수 없어졌다는 것 또한 문제가 되었습니다.

때문에 저희는 이 노드를 클러스터에서 제거하기로 결정하고, Range 분리와 이 노드의 Decommission을 함께 진행했습니다. 이 노드의 Decommission이 완료되면서 복제되지 않은 Range는 0이 되었고, 클러스터의 각종 지표 또한 안정적인 상태로 돌아왔습니다.

#[22:00] 대망의 오픈

데이터베이스 클러스터가 정상으로 돌아온 것처럼 보였어도 마음을 놓기에는 넘어야 할 산이 조금 더 있었습니다. 우선 점검이 끝나기만을 기다리던 유저 분들이 한꺼번에 게임에 접속하실 것이 자명했고, 로그인 보너스를 수령하기 위해 12시경 접속하는 유저 분들이 매우 많을 것인데다, 이렇게 많은 트래픽이 흘러들어갔을 때 데이터베이스가 안정적일지는 지켜보아야만 알 수 있었습니다.

모든 엔지니어들이 숨죽여 지켜보는 가운데 점검이 종료되었고, 서버는 트래픽을 잘 받아내는 것처럼 보였습니다. 그냥 그렇게 트래픽을 잘 받아내서 처리해줬으면 더할 나위 없이 좋았겠으나, 현실은 그렇지 않았습니다. 또 한 데이터베이스 노드에서 CPU를 100% 사용하는 것이 확인되었고, 다시 대기열을 통해 노드의 CPU 사용량을 안정시켰습니다.

이 때까지는 한 두 노드가 상태 회복을 위해 이럴 수 있다고 판단할 수 있는 내용이었는데, 이 뒤 얼마 지나지 않아 정확히 해당 노드가 다시 CPU를 100% 사용하기 시작했습니다. 몇 차례 대기열을 활용해 트래픽을 제어했으나, 문제가 발생하는 노드가 같다는 점에서 노드 자체의 문제일 가능성이 높아졌고, 결국 이 노드를 종료시킴으로서 문제 상황이 모두 해결되었습니다.

#몸으로 체득한 경험

일반적으로 RDBMS에서 Primary Key의 Prefix의 변경은 큰 문제가 되지 않습니다. 작업이 한 대의 서버에서만 처리되기 때문에 애초에 분산 처리를 상정하지 않는 이유도 있지만, RDBMS의 인덱스 자료형이 Prefix의 구조 변화에 크게 영향을 받지 않기 때문이기도 합니다.

하지만 CockroachDB의 분산 처리 특성상, 프로덕션 클러스터에서 이러한 변경이 가해지는 것은 상당한 주의가 필요한 작업임을 체득할 수 있었습니다. 팀 내에서 CockroachDB 스터디를 진행하며, 문서와 관련 자료들을 리뷰하며 충분히 알고 있던 내용이었지만, 실제 체험은 글로 얻은 정보에 비해 훨씬 큰 사건이었습니다.

#마무리하며

이렇게 킹덤 런칭 초창기의 점검 이야기는 모두 마무리됩니다.

이 당시 상황을 돌아보면, 많은 유저분들이 쿠키런: 킹덤을 사랑해주신 덕분에 전사적으로 처음 맞이해보는 규모의 트래픽을 다루게 되었고, 이 큰 트래픽을 잘 다루기 위해 끊임없이 노력을 기울이던 때였던 것 같습니다. 저희 예상보다 훨씬 더 많은 분들께서 쿠키런: 킹덤을 좋아해주셨고, 때문에 이에 맞추어 정말 많은 것을 개선하고 보수해야 했던, 정말 쏜살같이 빠르게 지나간 시간이기도 했습니다.

하지만 그런 환경 속에서도, 어떤 챌린지가 닥쳐왔을 때 타협하는 대신 최고의 고객 경험을 위해 끊임없이 다양한 방법을 시도하고 길을 찾아내는 것은, 데브시스터즈의 모든 구성원이 각자의 분야에서 이러한 노력을 뒷받침할 수 있는 경험과 스킬을 가지고 있기 때문에 가능했던 일이 아닐까 싶습니다.

긴 이야기의 끝까지 함께해 주셔서 감사합니다.

[1]: https://www.cockroachlabs.com/docs/v22.2/configure-replication-zones#replication-zone-variables

[2]: https://www.cockroachlabs.com/docs/v22.1/load-based-splitting

[3]: https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mapping-table-data-to-key-value-storage/

[4]: 쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기, 쿠키런: 킹덤 AWS AZ 장애 아웃라인

[5]: 이 오퍼레이션에 관해 더 자세히 알고 싶으시다면 CockroachDB in Production의 Production 배포시 고려해야 할 사항 > Range Split을 참고해주세요

쿠키런: 킹덤 AWS AZ 장애 아웃라인

Thu, 16 Feb 2023 00:00:00 GMT

이 글과 관련된 다른 글 보기

쿠키런: 킹덤 런칭 회고 - DevOps 관점에서 본 쿠키런: 킹덤 런칭 회고
CockroachDB in Production - CockroachDB에 대한 소개와 킹덤에서 CockroachDB를 사용한 이유 설명
쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기 - 엔지니어 관점 기록한 개괄적인 장애 대응 과정과 회고
CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기 - CockroachDB의 소스코드를 참고하며 바이너리 파일로부터 데이터를 복구한 이야기
입사 첫날에 36시간 점검 경험하기 - 신규입사자의 관점에서 서술된 장애 대응 기록
쿠키런: 킹덤 길드 업데이트 이후 서비스 이슈 되돌아보기 - 쿠키런: 킹덤에 길드 기능이 추가된 이후 발생한 서비스 이슈 회고

안녕하세요, 데브시스터즈 진저랩 플랫폼셀에서 소프트웨어 엔지니어로 일하고 있는 박새미, 인프라셀에서 일하고 있는 데브옵스 엔지니어 이창원입니다. 이 글에서는 2022년 NDC에서 함께 발표한 쿠키런: 킹덤, 총 56시간의 긴급 점검 회고 - 그때 그 명검은 왜 뽑아야 했는가 세션에서도 다룬 바 있는, 2021년 2월 19일에 발생한 AWS 도쿄 리전 데이터센터 장애에 대해 공유해 드리고자 합니다. 만약 정보를 접할 때 글보다 영상을 선호하는 편이시라면, 해당 세션 영상을 보시는 것을 권해드립니다.

#CockroachDB? 분산 데이터베이스!

어느 평화로운 봄날, 회식 자리에서 DB 노드 한 대가 내려갔다는 에러 알람이 슬랙에 나타났지만, 데브옵스 엔지니어들은 크게 당황하지 않았습니다. AWS 같은 거대한 클라우드 벤더사라고 해서 100% SLA를 보장하지는 못하기도 하고요. 무엇보다도 CockroachDB는 이러한 장애를 견딜 수 있게 설계된 분산 데이터베이스이기 때문입니다.

기본적으로 분산 DB는 일부 노드가 정상적으로 동작하지 않아도 견딜 수 있게끔 설계됩니다. CockroachDB는 기본적으로 3대의 레플리카를 두게 되어 있으며, 각 Range^[1] 는 레플리카들에 복사되어 저장됩니다. CockroachDB는 Raft 알고리즘을 채택하였고 이에 따라 DB가 N대 있다고 했을 때 (N/2) + 1 이상의 값, 즉 과반수를 정족수로 사용합니다. 결과적으로 정족수가 깨지지 않는 한 일부 노드가 죽어도 영향을 받지 않게 설계된 것이지요. 예를 들어 Replication을 5대로 설정한다면, (5/2)-1대 미만의 노드가 죽어도 DB를 이용하는 데는 문제가 없습니다. CockroachDB에 더 자세히 알고싶으시다면 진저랩 인프라셀 이준성 님이 쓰신 CockroachDB in Production을 읽어보시는 것을 추천드립니다.

다만 분산 DB라 하더라도 3분 만에 또 2대, 6분 뒤에 2대, 20분 후에 2대… 22분 만에 총 60대^[2] 중 6대의 노드가 작동 불능이 되는 것은 조금 다른 이야기입니다. 엔지니어들은 빠르게 상황 파악 및 대응에 나섰습니다.

다시는 보고 싶지 않은 그 날의 Ops 채널 알람을 모사해보았습니다.

#무슨 일이 일어나고 있나요?

애플리케이션 레벨에서 DB 호출과 관련된 치명적인 로직이 없고 DB 설계 자체에도 결함이 없다면, 12분만에 6대의 노드가 장애를 겪는 건 뭔가 다른 곳에 원인이 있다는 뜻일 것입니다. 이렇게 다발적이고 급격하게 Failure가 발생할 경우에는 문제의 Scope를 정확히 파악하는 것이 중요하다고 생각합니다. 여러 커뮤니티 사이트들을 살펴보니 저희만 겪는 문제가 아닌 것도 같았습니다. 또한 AWS 고객사로 알려진 다른 서비스들도 문제가 발생했다는 정황을 다양한 경로에서 파악할 수 있었습니다. 상황을 파악해본 결과, 해당 장애의 원인은 AWS 도쿄리전 데이터센터의 냉각 시스템 고장이었습니다. 서버 머신들이 과열되어 작동에 문제가 발생한 것이었습니다. 안타까운 점은 저희의 경우 고장 난 냉각 시스템의 범위에 있던 서버들이 게임 서버가 아니라 하필 DB였고, AZ 장애에 대한 고려가 배제되었었다는 점입니다. 게임 서버였다면 큰 문제 없이 자동으로 새 서버 인스턴스가 떴을 것이고, 순간적인 서비스 불안정 정도는 발생했을 수 있었겠지만, 점검을 걸 필요까지는 없었을 것입니다.

#AZ 장애는 왜 고려하지 않았는가?

CockroachDB는 AZ 혹은 Region 장애까지도 대비할 수 있는 Locality라는 기능이 있습니다. 하지만 자동으로 지정되는 것이 아니고, 당연하게도 (사람) Operator가 알맞은 Topology 설정을 따로 해줘야 합니다. 그러면 노드가 클러스터에 합류한 이후에 Replica를 분배받을 때, 하나의 Topology가 완전히 날아가더라도 데이터 유실이 발생하지 않도록 분배받게 됩니다.

Region 장애에서도 올바르게 설정된 Follow-the-Workload Topology 덕분에 데이터 유실을 방지하는 시나리오

저희는 Kubernetes 위에 CockroachDB를 배포하였고, 데이터베이스라는 하나의 논리적인 단위이니만큼 하나의 통일된 Helm Chart를 사용해서 배포를 관리하고자 했습니다. Multi-AZ 배포를 위한 Topology는 CockroachDB Pod이 생성되는 시점에 배정이 되어야 하는데, 이 정보는 배포를 준비하는 차트 작성 단계에는 알 수가 없고, Pod이 특정 노드에 물리적으로 배정이 되고 난 이후에야 비로소 정해지며 Kubernetes API를 통해서도 제공이 되지 않습니다. 작성에 필요한 정보가 부재한 상황을 우회하려면 기술적 복잡성이 과도하게 가중되는 상황이었기 때문에, 자연스레 이 정도의 중요도가 있는 작업인지를 따져보게 되었습니다. 데브시스터즈는 2013년 쿠키런 for Kakao 시절부터 AWS를 사용해왔지만, AZ 장애가 한번도 발생하지 않았다는 점을 고려했을때, 차라리 보다 시급한 조치가 필요한 다른 일부터 진행하기로 결정했습니다. 대표적으로, Instance Retirement 같이 보다 흔하고 동시다발적으로 발생할 수 있는 시나리오에 대비하기로 하였습니다. 이전 기록들을 기반으로 동시에 여러 노드가 Retire될 확률을 경험적으로 계산하여 3대까지는 동시에 내려가도 데이터 손실이 발생하지 않도록 Replication Factor를 7로 설정해두었습니다. 물론 이 결정은 오랜 기간 안정적으로 사용해왔던 클라우드 프로바이더에 대한 신뢰가 있었기에 할 수 있었던 결정이었습니다. 으레 플래그들이 그렇듯이, 그때는 이것이 아주 완벽한 플래그로 작용하게 될 결정이라는 것을 몰랐습니다…

#장애 영향 범위

결과적으로 안전 마진으로 설정해둔 3대를 넘어서는 6대의 노드에서 Host Status Failure가 발생했기 때문에 전체 25,000개의 Range 중 Data Range 2개, System Range 32개가 소실되었습니다. Range의 레플리카는 7로 설정되어 있었고, 각 Range의 레플리카 중 과반인 4개 이상의 Replica가 하필 문제의 노드 6대에 들어있을 확률을 계산해보면 대략 0.09%입니다. Range 각각에 대해 독립사건이라고 가정했을 때, 동전을 25000번 던지는 것과 유사하니 B(25000, 0.09)라고 할 수 있습니다. 평균적으로는 약 23개가 영향을 받는 정도의 확률이고, 32개의 Range가 소실될 확률까지 계산해보면 약 2.3% 정도에 불과합니다.

32개의 Range에 대해서 완전 유실이 발생했을 확률을 계산해본 정규분포 그래프

System Range의 경우 클러스터에 저장된 데이터들의 위치를 포함한 각종 메타 정보가 포함되어 있습니다. Cockroach Labs 서포트 엔지니어 측에 확인해보니 System Range는 소실되어도 복구할 수 있다고 하여, 저희는 실제 유저분들의 데이터가 저장된 Data Range 2개를 복구하는 데 최대한 집중하였습니다.

#우리는 해결할 것이다 늘 그랬듯이

지난번 장애에서 세 가지 해결 방법을 동시에 진행했듯이, 이번에는 두 가지 방법을 동시에 진행하였습니다. 두 방법은 생존한 54대 노드의 데이터와 Consistency 확인이 필요하다는 점에서는 동일했고, 54대가 들고 있지 않은 나머지 데이터를 가져오는 방법에 있어서 차이가 있었는데요. 해결 방법1은 Quorum이 깨진 레플리카에 남아있는 데이터들을 긁어오는 것이고, 해결 방법2는 백업에서 퍼오는 것이었습니다. 일단 공통적으로 필요한 작업인 54대의 생존한 노드로부터 테이블 백업 기능을 이용하여 데이터를 꺼내려고 시도했지만, 잘되지 않았습니다. 깨진 Range가 있어서 잘 안된 게 아닐까 추측할 수 있었습니다. 따라서 일종의 우회전략을 사용했는데요. INSERT INTO new_table SELECT * FROM old_table WHERE {unaffected_ranges} 같은 식으로 깨진 Range를 제외한 데이터를 새 테이블에 이사시켰습니다. 한편 백업 데이터를 활용하는 해결 방법2의 경우에는 주기적인 백업 데이터를 활용하는데, 이 백업 데이터를 퍼오는 작업 속도가 매우 느렸습니다. 8시간이 지나도 완료가 될 기미가 보이지 않았습니다. 저희는 조금이라도 점검 시간을 줄이고 싶었고, 어떻게 하면 더 빨리 데이터를 이사시킬 수 있을지 고민하던 찰나 생각지 못한 해결 방법3이 등장하게 됩니다.

CockroachDB 소스코드를 살펴보던 중 debug unsafe-remove-dead-replicas^[3]라는 명령어를 발견한 것이었습니다. Quorum이 깨진 Range를 복구 시도하는 것인데, unsafe라는 키워드에서도 짐작하실 수 있듯 일종의 흑마법(?) 같은 명령어입니다. 해당 명령어에는 긴 주석이 달려있었는데요. 주석을 거칠게 번역하자면, “이 명령은 복구를 위한 최후의 수단이다. 데이터가 만약 복구된다고 하더라도 그 데이터가 정합성이 맞다는 보장도 없다. 이 명령은 꼭 Cockroach Labs 엔지니어가 보는 앞에서만 사용해라" 정도로 번역할 수 있을 겁니다. 어쩌면 당연하게도 공식 문서에서는 찾아볼 수 없는 기능입니다. 저희는 Cockroach Labs 엔지니어들과 줌으로 화면 공유를 하면서 해당 명령어를 실행했습니다. 결과적으로 흑마법은 성공적이었으며 소실되었던 2개 Range 중 하나를 살릴 수 있었습니다.

CockroachDB 소스코드에서 찾아볼 수 있는 해당 명령어에 대한 무서운 주석

나머지 1개의 Range도 당연히 복원을 시도했습니다. Range가 완전히 소실된 것이 아니므로 강제로 특정 Replica를 원본으로 지정하고 다시 복제하는 기능이 있었으면 좋았으련만, 당시만 해도 그런 기능이 없었습니다.^[4]

따라서 살아나지 못한 Range 1개의 복원을 위해 1차 장애와 동일한 방법을 사용하였습니다. 어떤 식으로 복원했는지는 저희 기술 블로그에 있는 CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기, 쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기 글을 보시면 자세한 내용을 확인하실 수 있습니다. 참고로 해당 Range에 영향받을 수 있는 유저 수는 추측하건대 적으면 500명, 많으면 2천 명 정도로 예상됩니다. 결과적으로 데이터 유실 없이 온전하게 유저 데이터를 복구할 수 있었습니다.

#데브시스터즈가 얻은 교훈

AWS 도쿄 리전 데이터센터 장애는 저희 데브시스터즈에 매우 중요한 교훈을 주었습니다. 쿠키런: 킹덤 정도 규모의 게임을 서비스하기 위해서는 멀티 AZ 전략은 선택이 아니라 필수라는 것이죠. 이후 저희는 Locality 설정을 통해 데이터를 여러 지역에 걸쳐 고르게 분산시켰습니다. 낮은 확률이었지만 겪고 나니 보기에 흡족한 Helm 차트를 만들어 관리하고자 했던 마음은 쏙 들어갔습니다. 배포할 AZ마다 values 파일만 다르게 사용하는 한 벌의 차트를 사용하는, 다소 반복적이지만 확실한 방법으로 Locality를 설정하였습니다. 노드를 교체할 때는 Locality를 설정한 노드를 기존 클러스터에 편입시킨 이후 모든 AZ에 안정적으로 Replica가 복제된 것을 확인하고, 이후 Locality가 설정되지 않은 기존 노드들을 퇴역시키는 방법으로 진행했습니다.

클라우드 인프라를 제공하는 AWS 측에서도 고객인 우리를 위해서 만반의 대비를 해두었을 것입니다. 그래도 세상에는 물리적으로 어쩔 수 없는 요인, 혹은 인적 요인으로 인해서라도 문제가 발생할 수 있습니다. 이번 사건으로 저희 또한 저희의 고객을 위해서, 제삼자의 어떤 무언가에 기대는 것이 아니라 저희가 할 수 있는 최대한의 방비를 해두어야한다는 것을 새삼 깨닫게 되었습니다. 그러한 준비가 없었을 때 영향을 받는 것은, 바로 소중한 우리 고객들의 경험이니까요.

#글을 마치며

2022년 NDC 세션이 공개되고 나서, 몇몇 쿠키런: 킹덤 유저분들이 “서버실 에어컨 고장이라니 공포영화가 따로 없다"고 평해주신 것이 아직도 기억에 남습니다. 공포영화와 현실의 다른 점이라면 영화는 각본대로 흘러가지만, 현실에서는 온갖 좋지 못한 것들을 막기 위해 최대한 대비를 할 수 있다는 점이겠지요. 개인적으로 AWS 도쿄 리전 AZ 장애는 “대비”라는 단어가 어디까지 무게감을 가질 수 있는지 다시금 생각하게 해주었습니다. 긴 글 읽어주셔서 감사드립니다.

[1]: CockroachDB 내부적으로 사용하는 데이터 저장 단위입니다.

[2]: 36시간 점검 이후에 DB 용량을 추가적으로 확보하기 위해 총 60대 규모의 클러스터로 확장했었습니다.

[3]: 이 명령어는 지금은 deprecate 되고 debug recover 명령어로 대체되었습니다.

[4]: 새로 추가된 recover 명령어가 이러한 기능을 지원하기 위해서 개발되었다고 합니다. 잘 동작하는지 저희가 확인해보진 않았고, 앞으로도 그냥 모르고 살았으면 좋겠습니다 😅

9가지 프로그래밍 언어로 배우는 개념: 5편 - 동시성 프로그래밍

Tue, 31 Jan 2023 00:00:00 GMT

#프로그래밍 언어 시리즈

9가지 프로그래밍 언어로 배우는 개념: 1편 - 타입 이론
9가지 프로그래밍 언어로 배우는 개념: 2편 - 다형성
9가지 프로그래밍 언어로 배우는 개념: 3편 - 메타프로그래밍
9가지 프로그래밍 언어로 배우는 개념: 4편 - 하이 레벨 언어와 동적 타입 언어
9가지 프로그래밍 언어로 배우는 개념: 5편 - 동시성 프로그래밍

#서론

안녕하세요, 쿠키런 킹덤의 서버팀에 속해있는 지민규입니다. CPU 코어의 성능이 한계점에 가까워지고 보급형 CPU도 4코어 이상인 요즘 시대에 높은 반응성 및 성능을 요구하는 프로그램을 만들려면 동시성 프로그래밍은 필수입니다. 이러한 추세에 많은 프로그래밍 언어들도 각종 동시성 기능을 내장해가고 있습니다. 이 글에서는 각 동시성 기능 간의 관계와 몇몇 언어들의 특이한 동시성 기능들을 소개하려 합니다.

이전 편들이 하나의 프로그래밍 언어를 깊게 이해하고 있는 분들을 대상으로 쓴 것처럼, 이번 동시성 프로그래밍 편에서는 동시성 프로그래밍에 대해 어느 정도 이해하고 있는 분들을 대상으로 작성했습니다.

#용어 비교

시작하기에 앞서 먼저 동시성 프로그래밍 용어들을 정리해볼 필요가 있습니다

#병렬처리(Parallel Computing)

병렬처리는 간단히 말해서 여러 명령을 같은 순간에 처리하는 것입니다. 일반적으로 하나의 CPU 코어는 한 번에 하나의 명령을 처리합니다. 만약 하나의 프로그램에서 다중 코어를 이용해 여러 명령을 한 번에 처리한다면 병렬 처리라고 할 수 있습니다. 반드시 CPU 코어를 사용해야만 병렬처리를 할 수 있는 것은 아닙니다. 수백, 수천 개의 코어로 이루어진 그래픽카드(GPU)를 활용하여 병렬처리를 하는 방법도 있습니다.

#멀티쓰레딩(Multithreading)

운영체제가 제공하는 쓰레드를 이용하여 병렬처리를 하는 기법입니다. 일반적으로 컴퓨터 프로그램은 하나 이상의 프로세스들로 이루어져 있고 프로세스는 하나 이상의 쓰레드로 이루어져 있습니다. 하나의 쓰레드는 로컬 변수들을 저장할 스택 메모리와 실행 중인 명령의 위치 등으로 이루어져 있습니다. 같은 프로세스 내의 쓰레드끼리는 서로 힙 메모리를 공유합니다.

#동시성 프로그래밍(Concurrent Programming)

동시성 프로그래밍은 기존의 순서대로 명령들이 실행되는 구조에서 벗어나 명령들이 불규칙한 순서대로 실행될 수 있게 해주는 프로그래밍 기법입니다. 멀티쓰레딩은 동시성 프로그래밍의 한 방법이지만, 동시성 프로그래밍이 꼭 병렬처리 및 멀티쓰레딩을 의미하지는 않습니다.

#비동기 프로그래밍(Asynchronous Programming)

비동기 프로그래밍은 Future, Promise 및 Async-Await와 같은 추상화된 기능들을 이용하여 동시성 프로그래밍을 하는 방법입니다. 마찬가지로 비동기 프로그래밍을 사용한다고 해서 꼭 병렬처리 및 멀티쓰레딩인 것은 아닙니다.

#쓰레드

**쓰레드(Thread)**가 명령 흐름을 관리하는 기본 단위인 만큼 가장 대표적인 병렬처리 방식입니다. 쓰레드는 운영체제가 제공하기 때문에 운영체제마다 사용해야 하는 라이브러리, 쓰레드 생성 방식, 세부적인 기능들이 미묘하게 다릅니다. 다행히도, 대부분의 프로그래밍 언어는 운영체제를 신경쓰지 않아도 되도록 추상화한 쓰레딩 라이브러리를 제공합니다.

// C# 코드
// 쓰레드가 돌릴 함수
static void SayHi(string message) {
  Console.WriteLine("Hi, " + message);
}

// 쓰레드 생성
Thread thread = new Thread(() => SayHi("Mango"));

// 쓰레드 시작
// "Hi, Mango"를 출력한다
thread.Start();

// 쓰레드 종료 기다리기
thread.Join();

쓰레드를 생성할 때 운영체제와 소통하고 메모리를 할당해야 하므로 시간과 메모리 리소스가 들어갑니다. 쓰레드 개수가 너무 많아져도 문제인데, 운영체제가 관리해야 하는 쓰레드의 수가 늘어나고 코어를 더 많은 쓰레드들이 나눠서 사용해야 하며, CPU 코어를 사용하는 쓰레드가 교체될 때 레지스터를 교체하는 Context Switching이 더 자주 발생하여 성능도 하락하게 됩니다.

#쓰레드 풀

과도하게 잦은 쓰레드 생성과 Context Switching을 피하는 방법 중 하나는 **쓰레드 풀(Thread Pool)**을 사용하는 것입니다. 쓰레드가 필요할 때마다 매번 생성하는 것이 아닌, 쓰레드 풀에 저장된 쓰레드를 할당받아 사용하고 쓰레드 사용이 끝났을 때 다시 쓰레드 풀로 반환하는 방식입니다. 이때 쓰레드 풀로 넘겨진 함수를 일반적으로 **태스크(Task)**라고 부릅니다.

// C# 코드
// 기본 제공되는 쓰레드 풀, SayHi 함수를 실행하는 태스크를 전달한다.
ThreadPool.QueueUserWorkItem((_) => SayHi("Mango"));

다만 쓰레드 풀이 장점만 있는 것은 아닙니다. 리소스만 충분하다면 즉각적으로 생성되고 실행되는 쓰레드와 달리, 쓰레드 풀은 남은 쓰레드가 없다면 실행 중인 태스크 중 하나가 끝나 쓰레드를 반환할 때까지 시작하지 않습니다. 그렇기 때문에 무거운 태스크들로 쓰레드들을 소진시켰다면 다음 태스크는 아무리 가볍더라도 무거운 태스크 중 하나가 끝날 때까지 시작하지 않습니다. 이로 인해 반응성이 떨어집니다.

태스크가 무거워지는 이유는 크게 2가지로 나눌 수 있습니다.

파일 읽기/쓰기, 네트워크 송신 등 I/O 작업이 포함되어있어서
순수하게 CPU 연산이 많아서

1번 케이스로 인해 쓰레드 풀의 반응성이 떨어지는 경우는 CPU 성능의 문제가 아닙니다. I/O 작업은 CPU가 연산을 하느라 느려지는 것이 아니라 하드디스크/SSD와 같은 하드웨어의 작업을 기다리고 있거나 네트워크 응답을 기다리고 있는 것이기 때문입니다. 이 경우, 운영체제에서 쓰레드를 대기 상태로 설정하여 CPU를 다른 쓰레드에게 양보하기 때문에 쓰레드 개수가 늘어나더라도 Context Switching 횟수가 크게 늘지 않아 CPU 성능에 큰 문제가 발생하지 않습니다. 그렇기 때문에 I/O 작업을 처리하는 쓰레드 풀은 남은 쓰레드가 없으면 새 쓰레드를 만들어 쓰레드 풀에 포함시키고 오랫동안 사용하지 않은 쓰레드를 자동으로 제거하는 방식으로 쓰레드 개수를 가변적으로 운용하여 반응성을 높이는 것이 일반적입니다.

2번 케이스는 CPU 성능의 문제입니다. 일반적으로 CPU 작업을 위한 쓰레드 풀은 CPU 코어의 개수에 비례해서 쓰레드 개수를 고정으로 운용하는데, 만약 더 많은 쓰레드를 생성하면 Context Switching의 횟수가 증가하여 전체적인 성능 하락이 발생합니다. 이 경우에는 태스크 자체를 더 작은 단위로 쪼개서 다른 태스크가 돌아갈 기회를 주는 방법 밖에는 없습니다.

// C# 코드
// 기존 태스크
static void OriginalTask() {
  /* 매우 무거운 CPU 작업 1 */
  DoTheDishes();
  /* 매우 무거운 CPU 작업 2 */
  DoTheLaundry();
}

// 쪼개진 태스크들
static void CpuTask1() {
  DoTheDishes();
  ThreadPool.QueueUserWorkItem((_) => CpuTask2());
}

static void CpuTask2() {
  DoTheLaundry();
}

이렇게 I/O 작업이 있는 태스크와 CPU 작업 위주인 태스크는 서로 다른 쓰레드 풀을 사용해야 하며 태스크를 쪼개야 하는 경우도 있다는 것을 보았습니다. 만약 한 태스크가 CPU 작업과 I/O 작업을 함께 할 경우 각 작업은 서로 다른 쓰레드 풀에 할당되어야 하므로 계속해서 태스크를 쪼개야 합니다.

// C# 코드
// 기존 태스크
static void OriginalTask() {
  /* 매우 무거운 CPU 작업 1 */
  DoTheDishes();
  /* 매우 무거운 I/O 작업 */
  MakeDoctorsAppointment();
  /* 매우 무거운 CPU 작업 2 */
  DoTheLaundry();
}

// 쪼개진 태스크들
static void CpuTask1() {
  DoTheDishes();
  ioThreadPool.QueueUserWorkItem((_) => IoTask());
}

static void IoTask() {
  MakeDoctorsAppointment();
  cpuThreadPool.QueueUserWorkItem((_) => CpuTask2());
}

static void CpuTask2() {
  DoTheLaundry();
}

위 코드에서도 보이듯이, 태스크를 직접 쪼개는 건 비직관적입니다. 이러한 비직관성을 회피하는 방법 중 하나는 바로 경량쓰레드를 사용하는 것입니다.

#경량쓰레드

**경량쓰레드(Light-weight Thread)**는 운영체제가 아닌 프로그램 레벨에서 구현된 쓰레드입니다. 생성하고 제거할 때 운영체제와 소통할 필요가 없고 리소스의 사용량도 최적화하여 훨씬 가볍기 때문에 경량쓰레드라고 부릅니다. 경량쓰레드를 언어 차원에서 제공하는 대표적인 언어는 Go입니다.

// Go 코드
func task() {
  /* 매우 무거운 CPU 작업 1 */
  doTheDishes()
  /* 매우 무거운 I/O 작업 */
  makeDoctorsAppointment()
  /* 매우 무거운 CPU 작업 2 */
  doTheLaundry()
}

// 경량쓰레드 위에서 실행
go task()

경량쓰레드는 쓰레드 풀과 깊은 연관성이 있습니다. 사실 경량쓰레드는 쓰레드 풀 위에서 작동하고, 프로그래밍 언어가 태스크를 대신 쪼개주는 것이기 때문입니다.

위에서 보이는 task 함수는 어떤 면에서는 하나의 태스크가 아니라 세 개로 나눠진 태스크라고도 볼 수 있습니다. 나눠진 지점마다 다른 경량쓰레드가 작동할 기회를 주는 것입니다. 쓰레드가 명령의 흐름을 추적한다면 경량쓰레드는 태스크의 흐름을 추적한다고 할 수 있습니다. 그렇기 때문에 Context Switching의 비용 또한 운영체제의 쓰레드에 비하면 훨씬 낮습니다.

경량쓰레드를 사용하면 태스크를 어느 쓰레드 풀로 넘겨야 하는지, 어떻게 쪼갤지, 쓰레드가 충분한지에 대한 고민을 크게 덜 수 있습니다.

#비동기 프로그래밍

비동기 프로그래밍은 태스크 쪼개기 문제를 해결하는 방법 중 하나입니다. 비동기 프로그래밍은 태스크 쪼개기를 최대한 자연스럽게 만들어 코드의 직관성을 살립니다.

다만 비동기 프로그래밍이 꼭 멀티쓰레딩을 동반하지 않습니다. 태스크를 별도의 쓰레드나 쓰레드 풀로 넘긴다면 멀티쓰레딩을 활용하는 비동기 프로그래밍이고, 하나의 쓰레드가 모두 처리한다면 병렬성이 없는 비동기 프로그래밍입니다.

#Promise와 Future

비동기 프로그래밍을 배울 때 가장 먼저 Promise와 Future에 대해서 알아보아야 합니다. 쓰레드를 돌릴 때 대부분의 경우 실행 결과도 필요합니다. 이때 사용하는 것은 Promise와 Future입니다.

// C++ 코드
// 피보나치 함수
long fibonacci(long n) {
  if (n <= 1)
    return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

// 피보나치 계산 결과를 promise로 전달하는 태스크
void runFibonacci(long n, promise<long> fibonacciPromise) {
  long result = fibonacci(n);
  fibonacciPromise.set_value(result);
}

// 결과 값을 받아줄 promise 생성
promise<long> fibonacciPromise;

// 결과 값을 조회할 수 있는 future 생성
future<long> fibonacciFuture = fibonacciPromise.get_future();

// 쓰레드 생성 후 태스크 전달
thread t = thread(runFibonacci, 50, move(fibonacciPromise));

// future에 값이 도달할 때까지 기다리기
long result = fibonacciFuture.get();

Promise는 값을 받을 수 있고 Future는 값을 조회할 수 있습니다. 위에서 보이듯이 C++에서는 Promise를 먼저 만든 뒤 Promise에 대응되는 Future를 가져옵니다. promise에 set_value 함수가 호출되었을 때 future의 wait가 끝나는 것입니다.

물론 이렇게 직접 Promise를 다뤄야 하는 경우는 많지 않습니다. 일반적으로는 Promise는 라이브러리 내부에서 만들어지고, Future만 받아서 처리하는 경우가 많습니다.

// C++ 코드
long fibonacci(long n) {
  if (n <= 1)
    return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

// 새 쓰레드를 만들고 그 위에 태스크를 굴려서 결과를 future로 받는다.
future<long> fibonacciFuture = async(fibonacci, 50);

// future에 값이 도달할 때까지 기다리기
long result = fibonacciFuture.get();

Promise를 직접 다뤘을 때는 set_value를 호출하는 것을 잊어버리면 wait 함수가 영원히 끝나지 않겠지만 async 함수를 활용하여 간접적으로 사용하면 이러한 위험성을 피할 수 있습니다. async를 통해 만들어낸 Future와 직접 Promise로부터 만들어낸 Future는 안전성 측면에서 크게 다릅니다.

그렇기 때문에 많은 언어는 주인 없는 Future가 존재하지 않도록 Future를 만들 때부터 태스크를 묶고 실행하는 경우가 많습니다.

// Java 코드
// 태스크를 기본 쓰레드 풀에 실행시켜 결과를 future로 받는다.
CompletableFuture<Long> fibonacciFuture =
  CompletableFuture.supplyAsync(() -> {
    return fibonacci(50);
  });

// future에 값이 도달할 때까지 기다리기
Long result = fibonacciFuture.get();

C#에서는 아예 Future를 Task<T>라고 부르고 있습니다.

// C# 코드
// 태스크를 기본 쓰레드 풀에 실행시켜 결과를 future로 받는다.
Task<long> fiboncciFuture =
  Task<long>.Run(() => return Fibonacci(50));

// future에 값이 도달할 때까지 기다리기
long result = fiboncciFuture.Result;

재밌는 것은 Javascript/Typescript에서는 이런 Future들을 Promise라고 부른다는 것입니다.

// Typescript
// 태스크를 실행시켜 결과를 future로 받는다.
let fiboncciFuture: Promise<number> = new Promise((resolve) => {
  resolve(fibonacci(50));
});

태스크가 묶인 Future의 특징 중 하나는 태스크 연계가 가능하다는 것입니다. Future의 결과에 새로운 태스크를 묶어서 또 다른 Future를 만드는 것입니다. 이것 잘 활용하면 태스크가 자연스럽게 쪼개지게 되어 반응성 문제를 어느 정도 회피할 수 있습니다.

// Typescript 코드
// Future들을 출력하는 함수들
function getHired(): Promise<Job> {
  /* ... */
}

function earnMoney(job: Job): Promise<Money> {
  /* ... */
}

function buyHouse(money: Money): Promise<House> {
  /* ... */
}

// Promise의 then 메소드를 이용해서 Future들을 합친다
let houseFuture: Promise<House> = getHired()
  .then((job) => earnMoney(job))
  .then((money) => buyHouse(money));

이러한 방식으로 Future 합치는 것에 큰 단점이 있습니다. 각 태스크의 의존 관계가 복잡해지면 Future 중첩이 복잡해져 가독성이 떨어집니다.

// Typescript 코드
let future: Promise<[Job, Money, House]> = getHired().then((job) =>
  earnMoney(job).then((money) =>
    buyHouse(money).then((house) => [job, money, house])
  )
);

이러한 중첩 문제를 해결할 방법 중 하나는 Async-Await 기능을 이용하는 것입니다.

#Async-Await

Async-Await은 Future의 중첩으로 인한 가독성 하락 문제를 해결해줍니다. Typescript의 Async-Await 기능은 async 키워드와 await 키워드를 사용합니다. 먼저 async에 대해서 배워봅시다.

// Typescript 코드
async function getHired(): Promise<Job> {
  /* ... */
}

async function earnMoney(job: Job): Promise<Money> {
  /* ... */
}

async function buyHouse(money: Money): Promise<House> {
  /* ... */
}

먼저 async 함수는 반드시 Promise를 출력해야 한다는 제약 조건이 있습니다. Typescript에서는 출력 타입에 Promise<Job>과 같은 형식으로 적지만 Promise 부분을 생략하는 프로그래밍 언어도 몇몇 존재합니다.

async 함수를 사용하면 await 키워드를 사용할 수 있게 해줍니다. await 키워드를 활용하면 중첩 문제를 해결할 수 있습니다.

// Typescript 코드
async function collectAllFutures(): Promise<[Job, Money, House]> {
  let job: Job = await getHired();
  let money: Money = await earnMoney(job);
  let house: House = await buyHouse(money);

  return [job, money, house];
}

// 위 코드는 아래와 동일
// fucntion runAll(): Promise<[Job, Money, House]> {
//   getHired()
//     .then(job =>
//       earnMoney(job)
//         .then(money =>
//           buyHouse(money)
//             .then(house =>
//               [job, money, house]
//             )
//         )
//     )
// }

Async-Await는 완전히 새로 만들어진 기능이 아닌 Promise의 then을 이용해서 만들어진 것입니다. 물론 then으로 직접 중첩하는 것과는 세세한 차이점이 존재하지만 조금 넓게 보면 일종의 **문법적 설탕(Syntatic Sugar)**입니다. 문법적 설탕은 기존에 존재하는 기능에 새로운 문법을 추가하여 가독성을 높인 언어 기능을 뜻합니다.

그렇기 때문에 어떻게 보면 Async-Await는 눈속임입니다. 위 runAll의 3개의 함수 호출은 전부 다른 태스크에 속해있습니다. await를 하는 지점마다 다른 태스크가 실행될 기회를 주는 것이고 사실 한 함수의 몸체 내에서 모두 호출하는 것이 아닙니다. 이런 면에서 경량쓰레드랑 어느 정도 비슷한 점이 존재한다고 볼 수 있습니다. 경량쓰레드는 문법을 추가하지 않고 이러한 문제를 해결한다면, Async-Await는 새로운 키워드와 문법을 추가하여 해결합니다.

Kotlin에서는 Async-Await 대신 **코루틴(Coroutine)**을 사용하는데, yield등 몇 가지 특수한 기능들이 제공되는 것을 제외하면 Async-Await와 동일하기 때문에 이번 글에서는 다루지 않습니다.

#IO모나드

무시무시한 단어가 등장했습니다. **모나드(Monad)**입니다. 모나드는 함수형 프로그래밍 패러다임의 개념 중 가장 이해하기 어려운 개념으로 악명 높습니다. 이 글은 동시성 프로그래밍에 관한 글이기 때문에 분량상 모나드에 대해서 전부 설명할 수는 없지만, IO모나드를 대략적으로 이해하는데 필요한 수준까지 설명합니다.

먼저 IO모나드에 해당하는 Scala의 Future[T]를 살펴봅시다.

// Scala 코드
// 대략적인 Future 인터페이스
trait Future[T] {
  /* ... */
  def flatMap[U](f: T => Future[U]): Future[U]
}

// 대략적인 Future 정적 객체
object Future {
  /* ... */
  // Future의 정적 함수
  def successful[T](result: T): Future[T] = /* ... */
}

어떠한 타입이 모나드가 되려면 정확히 2개의 함수가 필요합니다. 대상 타입이 F이고. 타입 파라미터 T를 받는다면 T ⇒ F[U] 타입의 함수를 입력받아 F[U]를 출력할 수 있는 메소드와 T를 입력받아 F[T]를 출력할 수 있는 정적 함수가 필요합니다. Future의 경우 Future[T].flatMap 메소드가 전자에 해당하고 Future.sucessful 함수가 후자에 해당합니다.

이 두 함수를 가진 타입들을 가졌다면 해당 타입을 모나드라고 할 수 있습니다. 모든 모나드는 Typescript의 Promise와 같이 중첩된 형태로 함수를 호출하는 상황이 발생할 수 있습니다.

// Typescript 코드
// Typescript에서는 이렇게 중첩된다
fucntion collectAllFutures(): Promise<[Job, Money, House]> {
  getHired()
    .then(job =>
      earnMoney(job)
        .then(money =>
          buyHouse(money)
            .then(house =>
              [job, money, house]
            )
        )
    )
}

// Scala 코드
// Typescript의 Promise가 then을 사용한다면
// Scala의 Future는 flatMap을 사용한다
def collectAllFutures(): Future[(Job, Money, House)] =
  getHired()
    .flatMap(job =>
      earnMoney(job)
        .flatMap(money =>
          buyHouse(money)
              .flatMap(house =>
                Future.successful((job, money, house))
              )
         )
    )

여러 Future의 결과를 모아서 출력하는 경우 Typescript의 Promise가 그러했듯 Scala의 Future도 그런 문제를 겪게 됩니다. Scala의 Nullable 타입에 해당하는 Option도 모나드이기 때문에 마찬가지의 문제를 겪을 수 있습니다.

// Scala 코드
trait Option[T] {
  // 현재 값이 null일 때는 null을 출력한다
  // 현재 값이 null이 아닐 때는 f를 실행한 출력 값을 출력한다
  def flatMap[U](f: T => Option[U]): Option[U]
}

object Option {
  def some[T](value: T): Option[T] = /* ... */
}

// 마찬가지로 중첩된 형태로 함수를 호출한다
// 여기서 각각의 getXXX 함수는 Option을 출력한다고 가정한다
def collectAllOptions(): Option[(Job, Money, House)] =
  getJob()
    .flatMap(job =>
      getMoney(job)
        .flatMap(money =>
          getHouse(money)
            .flatMap(house =>
              Option.some((job, money, house))
            )
        )
    )

함수형 프로그래밍에서 모나드가 널리 쓰이는 만큼 함수형 프로그래밍에 굉장히 고전적인 문제라서 모나드를 위한 문법적 설탕이 이미 존재합니다. 이를 Scala에서는 For-Comprehension이라고 부릅니다.

// Scala 코드
def collectAllFutures(): Future[(Job, Money, House)] =
  for {
    job   <- getHired()
    money <- earnMoney(job)
    house <- houseMoney(job)
  } yield (job, money, house)

def collectAllOptions(): Option[(Job, Money, House)] =
  for {
    job   <- getJob()
    money <- getMoney(job)
    house <- getHouse(job)
  } yield (job, money, house)

// Typescript 코드
// 비교를 위해 가져온 Typescript의 Async-Await 코드
async function collectAllFutures(): Promise<[Job, Money, House]> {
  let job = await getHired()
  let money = await earnMoney(job)
  let house = await buyHouse(money)

  return [job, money, house]
}

뭔가 익숙하지 않으십니까? Async-Await와 상당 부분 비슷합니다. 차이점은 Async-Await는 비동기 처리 맥락에서만 사용할 수 있는 문법적 설탕이지만, For-Comprehension은 모나드들에 전반적으로 적용할 수 있는 문법적 설탕입니다. 제 동료가 집필한 게임 서버 개발에 스칼라 사용하기에서 비동기 처리가 전혀 없는 비즈니스 로직에 For-Comprehension을 사용한 것을 볼 수 있습니다.

#메모리 공유

동시성 프로그래밍을 할 때 생겨나는 본격적 고민은 메모리 공유에서 시작됩니다. 동시성 프로그래밍은 기존 순서대로 진행되는 코드의 형태에서 벗어나 명령들이 불규칙한 순서로 실행된다고 했었습니다.

명령 처리 순서가 불규칙해지면 어떠한 문제가 발생할까요? 예를 들어 전역 변수에 1씩 100,000번 더하는 함수가 있다고 합시다.

// C++ 코드
int globalValue = 0;

void add100_000() {
  for (int i = 0; i < 100000; i++) {
    globalValue++;
  }
}

이 함수를 2개의 쓰레드에 돌려서 200,000번 더해봅시다.

// C++ 코드
// 함수를 2개에 쓰레드에 나눠서 호출한다
thread thread1 = thread(add100_000);
thread thread2 = thread(add100_000);

thread1.join();
thread2.join();

// 과연 무엇이 출력될까?
cout << globalValue << endl;

같은 전역 변수에 200,000번 더했으니 200,000이 될 것 같지만, 실제로는 100,000과 200,000 사이의 숫자가 출력됩니다.

// 위 프로그램을 10번 실행한 결과
// 참고: 실행 환경에 따라 결과가 크게 다를 수 있음
108725
104778
102279
103750
100470
101885
102690
102263
102678
102362

어째서 이런 일이 발생하는 것일까요? 일단 add100_000 함수를 확인해봅시다. CPU 명령어 관점에서 globalValue++는 3개의 명령으로 이루어져 있습니다.

// C++ 코드
int globalValue = 0;

void add100_000() {
  for (int i = 0; i < 100000; i++) {
    // globalValue++; 는 다음 세 명령으로 변환된다.
    int oldValue = globalValue; // 1번
    int newValue = oldValue + 1; // 2번
    globalValue = newValue; // 3번
  }
}

이 3개의 명령을 2개의 쓰레드, A 쓰레드와 B 쓰레드에서 동시에 실행한다고 생각해봅시다. 쓰레드는 운영체제가 관리하므로 언제 명령을 수행하고 언제 CPU 코어를 양보할지 모릅니다. 만약 A 쓰레드에서 1, 2, 3번 명령을 완료한 뒤 B 쓰레드에서 1, 2, 3번 명령을 수행하면 결과는 예상대로 이루어집니다.

// C++ 코드
int globalValue = 0;

// 쓰레드 A에서 명령 1, 2, 3번 수행
// 전역 변수로부터 0을 읽는다
int threadA_oldValue = globalValue;
// 0에 1을 더해 1이라는 계산 결과가 나온다
int threadA_newValue = threadA_oldValue + 1;
// 1이라는 결과를 전역 변수에 대입한다
globalValue = threadA_newValue;

// 쓰레드 B에서 명령 1, 2, 3번 수행
// 전역 변수로부터 1을 읽는다
int threadB_oldValue = globalValue;
// 1에 1을 더해 2라는 계산 결과가 나온다
int threadB_newValue = threadB_oldValue + 1;
// 2이라는 결과를 전역 변수에 대입한다
globalValue = threadB_newValue;

// 2가 출력된다
cout << globalValue << endl;

하지만 만약 A 쓰레드에서 1, 2번째 명령을 수행한 뒤 3번째 명령을 수행하기 전에 B 쓰레드가 3개의 명령을 수행하면 어떻게 될까요?

// C++ 코드
int globalValue = 0;

// 쓰레드 A에서 명령 1, 2번 수행
// 전역 변수로부터 0을 읽는다
int threadA_oldValue = globalValue;
// 0에 1을 더해 1이라는 계산 결과가 나온다
int threadA_newValue = threadA_oldValue + 1;

// 쓰레드 B에서 명령 1, 2, 3번 수행
// 전역 변수로부터 0을 읽는다
int threadB_oldValue = globalValue;
// 0에 1을 더해 1라는 계산 결과가 나온다
int threadB_newValue = threadB_oldValue + 1;
// 1이라는 결과를 전역 변수에 대입한다
globalValue = threadB_newValue;

// 쓰레드 A에서 명령 3번 수행
// 1이라는 쓰레드A의 결과를 전역 변수에 대입한다
globalValue = threadA_newValue;

// 1이 출력된다
cout << globalValue << endl;

아직 A 쓰레드에서 1이라는 값을 대입하지 않았기 때문에 B 쓰레드에서도 1이라는 결과가 도출됩니다. 1이 아닌 다른 결과가 나왔더라도 어차피 A 쓰레드의 3번 명령에서 1로 덮어씌워질 것입니다.

이렇게 똑같은 코드임에도 명령의 실행 순서에 따라 결과가 달라지는 것을 **경쟁 상태(Race Condition)**라고 합니다. 두 쓰레드가 경쟁하여 어느것이 먼저 수행되는지에 따라 결과가 달라지는 것이죠.

위 예시에서는 쓰레드간 작업 전환이 일어날 수 있었기 때문에 경쟁 상태가 발생합니다. 만약 병렬성이 없는, 싱글쓰레드 환경이였다면 발생하지 않습니다. 싱글쓰레드 환경에서는 반드시 태스크 단위로 실행되기 때문에 A 쓰레드의 1, 2, 3번 명령 사이에 B 쓰레드의 1, 2, 3번 명령이 끼어들 수 없습니다. 대신 연산 및 대입이 여러 태스크에 걸쳐서 일어난다면 경쟁 상태가 발생할 수 있습니다.

// Typescript 코드
async function add100_000() {
  for (int i = 0; i < 100000; i++) {
    let oldValue = globalValue;
    let newValue = oldValue + 1;
    await fireGlobalValueChangeEvent(); // 태스크를 나누는 지점
    globalValue = newValue;
  }
}

#Compare and Swap

현대 프로그래밍에서 경쟁 상태 해결 방법은 Compare and Swap에서 시작합니다. Compare and Swap은 계산한 뒤 변수에 대입하여 확정하기 전에 변수의 값을 한 번 더 확인해서 기존 값과 같은지 확인하고 나서 대입합니다.

// C++ 코드
// 변경할 변수와, 계산에 사용했었던 변수의 값, 그리고 새 값을 넘긴다
bool compareAndSwap(int* target, int oldValue, int newValue) {
  // 변경할 변수의 값을 가져온다
  int targetValue = *target;

  // 변경할 변수의 값이 처음 계산에 사용했던 값과 같다면 변경한 뒤 성공으로 출력한다
  if (targetValue == oldValue) {
    *target = newValue;
    return true;
  }

  // 계산한 사이에 값이 바뀌었다면 실패로 출력한다.
  return false;
}

만약 계산하는 데 처음 사용했던 값과 현재 변수의 값이 다르다면 중간에 다른 태스크가 값을 변경한 것이기 때문에 다시 처음부터 계산해야 합니다. 만약 계산에 사용한 값과 현재 변수 값이 같다면 값이 변경되지 않았다고 가정하고 진행해도 되는 것입니다.

compareAndSwap 함수도 여러 명령으로 이루어져 있기 때문에 결국 경쟁 상태에 영향받지 않을까 생각될 수 있는데, 대부분의 현대 CPU에서는 compareAndSwap이 하나의 CPU 명령으로써 제공되기 때문에 이러한 문제에서 자유롭습니다. compareAndSwap 실행 도중 다른 쓰레드가 target의 값을 변경할 일은 없다는 것입니다.

compareAndSwap 명령을 활용하여 add100_000를 다시 구현한 것은 다음과 같습니다.

// C++ 코드
void add100_000() {
  for (int i = 0; i < 100000; i++) {
    // compareAndSwap이 실패하면 다시 시도한다
    do {
      int oldValue = globalValue;
      int newValue = oldValue + 1;
      // globalValue = newValue; 대신 compareAndSwap을 활용한다
    } while (!compareAndSwap(&globalValue, oldValue, newValue))
  }
}

이런 경우에는 A 쓰레드에서 1, 2번 명령을 수행하고 B 쓰레드에서 1, 2, 3번 명령을 수행했을 경우 A 쓰레드의 3번 명령은 실패하게 되어 다시 1, 2, 3번 명령을 재시도합니다. 이렇게 함수나 타입에서 경쟁 상태를 제거했다면 Thread-safe하다고 표현합니다.

Compare and Swap이 가진 단점이 두 가지 있는데, 첫 번째로는 재시도를 기반으로 사용하기 때문에 성능이 조금 떨어질 수 있다는 것이며, 두 번째로는 재시도할 명령들에 **부수 효과(Side-effect)**이 있으면 의도되지 않은 결과가 발생할 수 있습니다.

부수 효과란 쉽게 말해 함수 외부에 있는 환경에 영향을 끼치는 것입니다, 대표적인 부수 효과로는 네트워크 통신, 콘솔 출력이 있습니다. 만약 위의 do-while에 콘솔 출력이 있다면 compareAndSwap을 실패할 때마다 추가로 콘솔 출력을 합니다.

// C++ 코드
do {
  int oldValue = globalValue;
  int newValue = oldValue + 1;
  // 부수 효과! compareAndSwap이 실패하면 여러번 출력함!
  cout << "Changing globalValue to " << newValue << endl;
} while (!compareAndSwap(&globalValue, oldValue, newValue))

#Atomic

변수를 수정하는 작업에 Compare and Swap을 사용하는 것을 일반화한 것이 Atomic입니다. Atomic은 타입을 감싸서 Compare and Swap을 활용하여 Thread-safe한 메소드만을 노출시킵니다.

// Java 코드
AtomicInt atomicInt = new AtomicInt(10);
// Thread-safe한 함수들
int value1 = atomicInt.get();
int value2 = atomicInt.getAndIncrement();
int value2 = atomicInt.addAndGet(5);

Atomic에 단점이 몇 가지 있는데 값 타입에는 atomic을 사용할 수 없다는 것입니다. Compare and Swap 명령어는 int, bool이나 참조 타입(포인터)과 같은 기초적인 타입만을 넘길 수 있기 때문입니다.

Atomic 또한 Compare and Swap을 기반으로 만들었기 때문에 부수 효과를 포함하는 수정은 할 수 없습니다.

// C++ 코드
void add100_000() {
  for (int i = 0; i < 100000; i++) {
    int oldValue = globalValue;
    int newValue = oldValue + 1;
    // 부수 효과가 있어서 globalValue를 atomic으로 만들 수 없다!
    cout << "Changing globalValue to " << newValue << endl;
    globalValue = newValue;
  }
}

이런 경우에 사용하는 것이 **뮤텍스(Mutex)**입니다.

#뮤텍스

뮤텍스는 특정 코드 영역을 여러 쓰레드가 동시에 접근할 수 없게 만드는 데 사용합니다. add100_000에서 경쟁 상태가 발생하는 코드 부분만을 뮤텍스로 감싼 코드는 다음과 같습니다.

// C++ 코드
int globalValue = 0;
mutex m;

void add100_000() {
  for (int i = 0; i < 100000; i++) {
    m.lock();
    // 이 영역에는 동시에 하나의 쓰레드만 진입할 수 있다
    int oldValue = globalValue;
    int newValue = oldValue + 1;
    globalValue = newValue;
    m.unlock();
  }
}

뮤텍스를 활용할 경우 A 쓰레드의 1, 2, 3번 명령 사이에 B 쓰레드의 명령이 끼어들 수 없기 때문에 Thread-safey를 얻습니다. A 쓰레드가 먼저 lock을 호출하고 진입했다면 B 쓰레드는 A가 모든 작업을 끝내고 unlock을 호출할 때까지 대기합니다.

Atomic과 달리 재시도를 하지 않기 때문에 부수 효과가 있는 코드가 포함되어 있어도 문제없이 작동합니다.

// C++ 코드
int globalValue = 0;
mutex m;

void add100_000() {
  for (int i = 0; i < 100000; i++) {
    m.lock();
    int oldValue = globalValue;
    int newValue = oldValue + 1;
    // 부수 효과가 있어도 괜찮다!
    cout << "Changing globalValue to " << newValue << endl;
    globalValue = newValue;
    m.unlock();
  }
}

뮤텍스의 구현 방식은 여러 가지가 있는데, 가장 간단한 것은 **스핀락(Spinlock)**입니다. 스핀락은 Compare and Swap 명령을 이용하여 구현할 수 있습니다.

// C++ 코드
// 참고: 실제 스핀락은 더 최적화 되어있음
class SpinLock {
public:
  bool isLocked = false;

  void lock() {
    // isLocked가 false라면 true를 대입한다.
    // isLocked가 true라면 false가 될 때까지 재시도한다.
    while (compareAndSwap(&isLocked, false, true)) {}
  }

  void unlock() {
    isLocked = false;
  }
}

스핀락의 단점은 락이 해제될 때까지 반복적으로 명령을 수행하기 때문에 CPU를 낭비한다는 것입니다. 그렇기 때문에 보편적으로 사용하는 뮤텍스는 compareAndSwap 시도가 실패하면 운영체제와 소통하여 쓰레드를 대기 상태로 설정합니다. 재우는 동안에는 CPU를 점거하지 않으며 unlock이 호출되었을 때 일어나서 다시 compareAndSwap을 시도합니다. 단점으로는 운영체제와 소통하는 시간이 들어가기 때문에 스핀락보다 반응성이 조금 떨어지고 락이 풀리는데 걸리는 시간이 짧을 경우 스핀락보다 성능 면에서도 더 떨어질 수도 있습니다.

이러한 이유로 lock 함수 자체가 어느 정도 성능 또는 반응성을 희생하기 때문에 lock을 너무 자주 해제하고 거는 것은 좋지 않습니다. add100_000 함수의 뮤텍스는 사실 좀 더 넓게 잡아주는 게 좋습니다.

// C++ 코드
int globalValue = 0;
mutex m;

void add100_000() {
  // For 루프 시작 지점에 걸어서 100,000번이 아닌 1번만 lock을 건다
  m.lock();
  for (int i = 0; i < 100000; i++) {
    int oldValue = globalValue;
    int newValue = oldValue + 1;
    globalValue = newValue;
  }
  m.unlock();
}

뮤텍스가 장점만 있는 것은 아닙니다. 장점만큼 단점도 꽤 많습니다.

첫 번째로는 이미 lock이 걸렸을 때 unlock이 될 때까지 쓰레드가 대기해야 하기 때문에 CPU 쓰레드 풀의 쓰레드는 뮤텍스를 대기해서는 안 됩니다. 뮤텍스를 대기하는 순간 쓰레드 풀의 쓰레드 하나를 쓰지 못하는 것이기 때문에 CPU 코어를 제대로 활용할 수 없게 됩니다.

두 번째 문제는 락을 이용한 프로그래밍은 어렵다는 것입니다. 락을 걸어야할 필요가 있는지, 락을 얼마나 넓게 잡아야 할지 철저히 고민하면서 프로그래밍해야 하고 락을 거는 내부의 코드가 어떤 경쟁 상태를 만드는지도 꿰고 있어야 합니다.

세 번째 문제가 가장 큰 문제입니다, 바로 **데드락(Deadlock)**이 발생할 수 있다는 것입니다. 데드락은 두 개의 쓰레드가 서로의 뮤텍스가 해제되는 것을 기다릴 때 발생합니다.

// C++ 코드
mutex m1;
mutex m2;

void task1() {
  // 뮤텍스 1, 2에 락을 건다
  m1.lock();
  m2.lock();

  m2.unlock();
  m1.unlock();
}

void task2() {
  // 뮤텍스 1, 2에 락을 건다, 다만 2부터 건다
  m2.lock();
  m1.lock();

  m1.unlock();
  m2.unlock();
}

thread t1 = thread(task1);
thread t2 = thread(task2);

t1.join();
t2.join();

만약 각 쓰레드가 동시에 m1과 m2 뮤텍스에 락을 걸면 데드락 현상이 발생합니다.

// C++ 코드

// t1 쓰레드에서 m1 뮤텍스에 락을 건다
m1.lock();

// t2 쓰레드에서 m2 뮤텍스에 락을 건다
m2.lock();

// t1 쓰레드에서 m2 뮤텍스에 락을 건다
// 하지만 t2 쓰레드가 이미 걸어버려서 대기한다
m2.lock();

// t2 쓰레드에서 m1 뮤텍스에 락을 건다
// 하지만 t1 쓰레드가 이미 걸어버려서 대기한다
m2.lock();

두 쓰레드 다 서로의 락이 풀릴 때까지 기다리게 됩니다. 아무런 진전 없이 영원히 대기하게 되는 것입니다. 프로그램이 제대로 작동하지 않게 됩니다.

데드락을 약간이나마 예방하는 방법은 여러 뮤텍스를 언제나 순서대로 락을 거는겁니다. 위 예시에서는 t1 쓰레드는 m1 뮤텍스에 락을 건 뒤 m2 뮤텍스에 락을 걸었고 t2 쓰레드는 m2, 그다음 m1 뮤텍스에 락을 걸어서 발생합니다. 만약 두 쓰레드 모두 뮤텍스를 같은 순서대로 걸었다면 데드락 현상은 발생하지 않습니다.

하지만 이 예방 방법은 단점이 있습니다. 앞서서 락을 걸어야하기 때문에 락을 조건부로 거는 방법은 없습니다. m1, m2 순서대로 락을 걸도록 정책을 잡으면 m2에 락을 걸고 나서 m1을 조건부로 거는 방법은 없습니다. m2 락을 걸고 나서 뒤늦게 조건 체크하여 m1 락을 거는 것은 정책을 위반한 것이기 때문이죠. 여기서 m1 뮤텍스도 실제 필요한 순간보다 앞서서 락을 걸기 때문에 락을 거는 범위가 늘어나 쓰레드의 대기시간이 늘어난다는 단점도 있습니다.

그래도 뮤텍스가 부수 효과 있는 코드 영역에서 안전하게 경쟁 상태를 제거할 수 있는 몇 안 되는 방법이기에 뮤텍스를 완전히 배제할 수는 없습니다. 그나마 할 수 있는 것은 뮤텍스의 사용을 최소화하고 가능하면 락이 없는 메모리 공유 방식을 사용하는 것입니다.

#동시성 자료구조

**동시성 자료구조(Concurrent Data Structures)**는 Thread-safe한 자료구조들을 일컫습니다. 존재하는 동시성 자료구조들의 예시는 다음과 같습니다.

스택(Stack)
큐(Queue)
리스트(List)
맵(Map, aka. Dictionary)

각각의 자료구조들은 다양한 구현 방식이 존재하고 그에 따라 장점과 단점이 나눠집니다. 특히 맵의 경우 락을 이용해 방법이 있고 락 없이 구현한 방법도 있습니다. Java의 ConcurrerntHashMap 경우 락을 이용해서 구현되었습니다.

락 없이 구현된 동시성 자료구조들은 주로 Compare and Swap을 이용해서 구현되었습니다. 그렇기 때문에 많은 쓰레드가 동시에 접근하고 자료구조를 수정한다면 Compare and Swap이 더 자주 실패하기 때문에 성능이 조금 떨어질 수 있습니다.

동시성 자료구조 중에 가장 중요한 자료구조를 뽑아보라고 한다면 **큐(Queue)**라고 할 수 있습니다. 큐를 활용하면 쓰레드 간의 소통을 할 수 있습니다. 그중에서도 **채널(Channel)**은 큐에 더 이상 요소를 추가할 수 없도록 닫는 기능과 채널의 메시지를 대기하는 기능을 추가한 것입니다. 채널을 활용하면 비동기적으로 처리되는 스트림을 구현할 수 있습니다.

// Rust 코드
// 주어진 디렉토리에 있는 파일들을 읽어서 채널로 보내주는 함수
fn stream_files_in_directory(path: &'static str, sender: Sender<String>) -> io::Result<()> {
  // 디렉토리 내 디렉토리/파일들 나열하기
  let entries = fs::read_dir(path)?;

  // 디렉토리/파일들 순회
  for entry in entries {
    // 파일이면 읽고 string으로 변환해서 채널에 삽입
    let entry = entry?;
    if entry.file_type()?.is_file() {
      let bytes = fs::read(entry.path())?;
      sender.send(String::from_utf8(bytes).unwrap()).unwrap();
    }
  }

  // 작업 완료 (채널은 자동으로 닫힘)
  Ok(())
}

fn main() {
  // 채널 만들기
  let (sender, receiver) = channel();

  // 생성 후 실행
  let thread = thread::spawn(|| stream_files_in_directory("src", sender));

  // 채널이 닫힐때까지 파일 데이터를 받는다
  for bytes in receiver.iter() {
    // 파일 데이터를 콘솔로 출력한다
    println!("{bytes}")
  }
}

이외에도 쓰레드 풀에 태스크를 넘길 때 사용되는 것이 큐입니다. 태스크를 넘길 때 태스크 대기열에 들어가게 되는데 이때 Thread-safey를 가진 큐를 사용하여 여러 쓰레드가 동시에 태스크를 추가해도 문제없도록 구현합니다. 어떤 면에서는 쓰레드 풀의 큐도 쓰레드간 소통을 위해 사용한다고 볼 수 있습니다.

큐의 대표적 사용처가 한 가지 더 있는데, 바로 **액터(Actor)**입니다

#액터

액터는 메모리를 아예 공유하지 않고 쓰레드 하나에 완전히 맡겨버리는 방법입니다. 만약 다른 쓰레드에서 메모리에 접근하거나 수정하고 싶다면 반드시 해당 쓰레드와 소통하여 조회하거나 수정하게 해야 합니다. add100_000를 액터를 활용해서 구현한 코드는 다음과 같습니다.

// Rust 코드
// 참고: 9가지 언어 중에 내장 라이브러리만으로
// 액터를 간단하게 구현할 수 있는 언어가 Rust밖에 없었음

// 액터에게 보낼 수 있는 명령들
enum Command {
  Increment, // 값 1 올리기
  Get(Sender<i32>), // 값 조회하기
}

// 액터 명령을 받아줄 쓰레드용 함수
fn counter_actor(command_receiver: Receiver<Command>) {
  let mut value = 0;

  // 무한 반복
  loop {
    // 명령을 받아서...
    let command = command_receiver.recv().unwrap();
    match command {
      // Increment면 value를 1 상승시킨다
      Command::Increment => value += 1,
      // Get이면 같이 온 채널에 값을 전달한다
      Command::Get(sender) => sender.send(value).unwrap(),
    }
  }
}

fn add100_000(actor_sender: Sender<Command>) {
  for _ in 0..100000 {
    // 값을 직접 올리는 것이 아닌, 액터에게 값을 올리는 명령을 전달한다 일을 시킨다
    actor_sender.send(Command::Increment).unwrap();
  }
}

fn main() {
  // 액터 명령용 채널 생성
  let (command_sender, command_receiver) = channel();

  // 액터 쓰레드 돌리기
  thread::spawn(|| counter_actor(command_receiver));

  // add100_000를 돌릴 2개의 쓰레드
  let t1 = {
    let command_sender = command_sender.clone();
    thread::spawn(|| add100_000(command_sender))
  };
  let t2 = {
    let command_sender = command_sender.clone();
    thread::spawn(|| add100_000(command_sender))
  };

  // add100_000 작업이 끝날 때까지 기다리기
  t1.join().unwrap().unwrap();
  t2.join().unwrap().unwrap();

  // 조회 결과를 받을 채널 생성
  let (result_sender, result_receiver) = channel();

  // 액터에게 조회 명령을 내린다
  command_sender.send(Command::Get(result_sender)).unwrap();

  // 조회 결과는 채널에서 받는다
  let result = result_receiver.recv().unwrap();

  // 200000이 출력된다
  println!("{result}");
}

실제 액터를 사용할 때는 직접 구현하지 않고 라이브러리를 통해서 액터를 사용하는 것이 일반적입니다. 그리고 액터를 실행할 때 쓰레드를 사용하면 액터의 수와 쓰레드의 수가 비례하므로 운영체제 쓰레드가 아닌 경량쓰레드를 사용하는 것이 일반적입니다.

메모리를 공유하지 않으면 경쟁 상태가 발생할 일도 없습니다. 액터에 명령이 쌓이면 내부의 쓰레드가 명령들을 하나씩 순서대로 처리하여 값을 수정합니다. 그런 이유로 뮤텍스도 필요 없고 액터 내에서 Compare and Swap을 할 필요가 없기 때문에 부수 효과가 있는 명령들을 수행해도 괜찮습니다.

액터의 가장 빛날 때는 액터에 응답이 필요 없는 명령을 내리는 경우입니다. 위 예시에서는 Increment 명령이 그러한데요, Increment의 경우 기존 뮤텍스 기반 방식과 달리 쓰레드 대기가 전혀 필요없기 때문입니다. 그런 면에서 가장 CPU 사용 효율이 좋다고 할 수 있습니다.

이처럼 액터가 가진 강점이 여러 가지이기 때문에 액터가 언어에 내장되어 제공되기도 합니다. 그중 하나는 Swift입니다.

// Swift 코드
// 액터 정의
actor CounterActor {
  var value: Int = 0

  func increment() {
    self.value += 1
  }

  func get() -> Int {
    return self.value
  }
}

func add100_000(counterActor: CounterActor) async {
  for _ in 0..<100000 {
    // 그냥 함수 호출하듯이 사용하면 된다
    await counterActor.increment();
  }
}

// 액터 생성
let counterActor = CounterActor()

// 쓰레드 풀에 태스크 전달
let task1 = Task {
  await add100_000(counterActor: counterActor)
}
let task2 = Task {
  await add100_000(counterActor: counterActor)
}

// 태스크들이 끝날 때까지 대기
await task1.value
await task2.value

// 조회 및 출력
let value = await counterActor.get()
print(value)

액터를 자체 지원하는 다른 두 언어는 Erlang과 Elixir입니다. 두 언어 모두 BEAM이라는 **VM(Virtual Machine)**으로 실행하는데, 이 VM의 특징은 운영체제 쓰레드 대신 경량쓰레드만 존재한다는 것과 모든 경량쓰레드에 Mailbox라는 채널이 달려있다는 것입니다. Elixir에서 액터를 구현하는 방법은 다음과 같습니다.

# Elixir 코드
# 액터 정의
defmodule CounterActor do
  use GenServer

  def init(_init_arg) do
    {:ok, 0}
  end

  def handle_cast(:increment, value) do
    {:noreply, value + 1}
  end

  def handle_call(:get, _from, value) do
    {:reply, value, value}
  end
end

defmodule Test do
  def add100_000(actor_pid) do
    Enum.each(1..100000, fn (_) -> GenServer.cast(actor_pid, :increment) end)
  end
end

# 액터 생성
{:ok, actor_pid} = GenServer.start_link(CounterActor, [])

# 경량쓰레드 생성하여 태스크 전달
task1 = Task.async(fn -> Test.add100_000(actor_pid) end)
task2 = Task.async(fn -> Test.add100_000(actor_pid) end)

# 태스크들이 끝날 때까지 대기
Task.await(task1)
Task.await(task2)

# 조회 및 출력
result = GenServer.call(actor_pid, :get)
IO.puts(result)

하지만 응답이 필요한 요청을 보냈을 때 응답을 받으려면 액터의 쓰레드가 요청을 처리할 때까지 대기해야하므로 어떻게 보면 액터 자체가 락으로써 작용한다고 할 수 있습니다. 이러한 응답 대기가 꼬이면 뮤텍스처럼 액터도 데드락이 발생할 수 있다는 것이 단점입니다.

// Swift 코드
// 액터 정의
actor CounterActor {
  // 짝지어진 액터 변수 추가
  var otherActor: CounterActor!
  var value: Int = 0

  func setOtherActor(otherActor: CounterActor) {
    self.otherActor = otherActor
  }

  func increment() {
    self.value += 1
  }

  func get() -> Int {
    return self.value
  }

  // 짝지어진 액터 변수의 값을 가져와서 평균을 계산하여 출력하는 함수
  func getAverage() async -> Double {
    // 짝지어진 액터에게 요청하고 응답을 기다림
    let otherValue = await self.otherActor.get()
    return Double(otherValue + value) / 2.0
  }
}

// 액터 2개 생성
let actor1 = CounterActor()
let actor2 = CounterActor()
// 액터 짝지어주기
await actor1.setOtherActor(otherActor: actor2)
await actor2.setOtherActor(otherActor: actor1)

// 만약 양쪽 액터에 동시에 getAverage를 호출한다면..
async let asyncResult1 = Task { actor1.getAverage() }
async let asyncResult2 = Task { actor2.getAverage() }

// 과연 응답이 돌아올까?
let result1 = await asyncResult1
let result2 = await asyncResult2

만약 양쪽 액터가 getAverage을 동시에 실행하면 두 액터는 서로에게 get 명령을 전달하게 될 것입니다. 이 get 명령은 getAverage가 완료되었을 때 실행합니다. 하지만 getAverage가 완료되려면 서로의 get 함수가 수행되어 값을 전달받아야 한다는 모순에 빠지게 됩니다. 데드락에 걸리는 것입니다.

Swift는 이 데드락 문제를 Reentrancy로 해결했습니다. 액터에서의 Reentrancy는 액터 쓰레드가 대기할 상황이 생기면 대기하는 대신 다른 명령들을 실행하는 기능입니다. 위 예시에서는 다른 액터의 get을 호출하면 응답을 기다리는 게 아니라 큐에 들어온 명령을 틈틈이 수행하게 됩니다. 이 과정에서 큐에 있었던 다른 액터가 보낸 get 명령을 처리하게 되고 데드락은 완전히 제거됩니다.

다만 이 방법은 단점이 없지는 않은데, 다른 명령을 틈틈히 수행하는 과정에서 필드가 수정되어 상태가 변화할 가능성도 있다는 것입니다. await 전후로 상태가 바뀌는 것입니다. 이러한 이유로 await마다 상태가 바뀔 수도 있음을 감안하고 로직을 구현해야하기 때문에 로직 구현 난이도가 급상승합니다.

#STM

**STM(Software Transactional Memory)**은 데이터베이스의 트랜잭션과 유사한 방법으로 메모리 공유 문제를 해결하는 방법입니다.

데이터베이스의 트랜젝션은 조회 및 수정 이후 커밋 처리하면 성공 또는 롤백으로 응답하게 되는데, 성공이 되었으면 여러 데이터베이스 테이블에 대한 수정이 한 번에 적용되며 실패했으면 롤백 되어 수정 사항을 반영하지 않습니다.

STM도 비슷하게 여러 STM 변수와 STM 전용 자료구조를 수정한 뒤 일종의 커밋 과정을 거쳐 갑니다. 이때 조회 또는 수정한 자료구조들이 다른 쓰레드에 의해서 수정되었다면 실패 처리하고 처음부터 다시 수정 및 커밋 시도하는 구조입니다.

// Scala 코드
// ZIO 라이브러리를 이용해서 작성된 STM 코드
// 주의: 실제로는 동작하지 않는 코드

// STM 기초 타입들/자료구조들
val playerIds: TSet[String]
val lastJoinedPlayerId: TRef[Option[String]]
val log: TQueue[String]

// STM 조회 및 수정사항 정의
def notifyPlayerJoined(newPlayerId: String): USTM[Unit] =
  // 아래의 모든 요청들은 전부 한 번에 수정된다
  for {
    _                <- playerIds.put(newPlayerId)
    previousPlayerId <- lastJoinedPlayerId.getAndUpdate(Some(newPlayerId))
    _                <- previousPlayerId match {
                          case Some(previousPlayerId) =>
                            log.offer(s"$previousId is no longer the last player")
                          case None =>
                            STM.unit
                        }
    _                <- log.offer(s"$newPlayerId is the new last player")
  } yield ()

// commit으로 수정사항 확정
notifyPlayerJoined("Mango").commit

이런 면에서 Atomic과 유사한 점이 많은데, Atomic은 Compare and Swap으로 대입이나 덧셈 뺄셈과 같은 기본적인 연산들에 대한 Thread-saftey를 제공한다면 STM은 캐 여러 개의 자료구조나 변수에 대한 수정에 대한 Thread-safety를 제공합니다. 또 양쪽 기법 모두 재시도 기반으로 작동하기 때문에 부수 효과가 존재하면 안 된다는 점도 비슷합니다.

STM이 가진 단점은 몇 가지가 더 있는데 재시도 기반이라서 쓰레드간 수정 경쟁이 치열하다면 성능이 하락합니다. 특히 수정 및 조회가 많아서 영향 끼치는 자료구조가 많거나 커밋을 하기 전 계산이 오래 걸린다면 수정 경쟁이 일어날 확률이 더 높아져 효율성이 더 떨어질 수도 있습니다.

#결론

이번 동시성 프로그래밍 편은 작성하다 보니 프로그래밍 시리즈 5편 중 가장 긴 편이 되었습니다. 그럼에도 분량상 빠트린 내용도 이것저것 많이 있어서 아쉽습니다. 동시성 프로그래밍은 확실히 완벽한 해결책이 존재하지 않아 어렵습니다. 그래도 다행인 건 반드시 한 프로그램에서 한 가지 동시성 기법을 사용해야 하는 건 아닙니다. 어떤 동시성 프로그래밍 기법이 적절한지 판단하여 높은 성능과 반응성을 가진 아키텍처를 만드는 것에 이번 글, 모자라지만 조금이라도 도움이 되었으면 좋겠습니다.

여담으로 이번 편에서 사실 Haskell과 Zig이라는 언어도 소개하려고 했었는데 안 그래도 높은 글의 난이도가 더 높아질 것 같아서 Swift와 Elixir로 참았습니다. 언젠가 기회가 되신다면 Zig의 Colorblind Async-Await에 대해서 찾아보시는 것을 추천해 드립니다.

이렇게 프로그래밍 언어 시리즈가 끝났습니다. 프로그래밍 언어 시리즈는 사실 제 친구들이나 쿠키런 킹덤 서버팀 동료들과 프로그래밍 언어에 대해서 논쟁을 하면서 나왔었던 주제들을 총집합해서 엮어낸 시리즈입니다. 제 친구들과 동료들이 없었으면 작성할 수 없었을 것입니다. 제 친구들과 쿠키런 킹덤 서버팀에게 이 시리즈를 바칩니다.

CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기

Tue, 17 Jan 2023 00:00:00 GMT

이 글과 관련된 다른 글 보기

쿠키런: 킹덤 런칭 회고 - DevOps 관점에서 본 쿠키런: 킹덤 런칭 회고
CockroachDB in Production - CockroachDB에 대한 소개와 킹덤에서 CockroachDB를 사용한 이유 설명
쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기 - 엔지니어 관점 기록한 개괄적인 장애 대응 과정과 회고
입사 첫날에 36시간 점검 경험하기 - 신규입사자의 관점에서 서술된 장애 대응 기록
쿠키런: 킹덤 AWS AZ 장애 아웃라인 - AWS AZ 장애로부터 서비스를 복구한 이야기
쿠키런: 킹덤 길드 업데이트 이후 서비스 이슈 되돌아보기 - 쿠키런: 킹덤에 길드 기능이 추가된 이후 발생한 서비스 이슈 회고

소프트웨어 엔지니어들은 수많은 추상화 속에서 살아갑니다. 하위 레벨에서 제공하는 추상화는 공기처럼 당연한 것으로 여겨지고, 그 위에 무엇을 어떻게 쌓아 올릴지 고민하는 게 소프트웨어 엔지니어링이라 할 수 있습니다. 오늘은 이렇게 당연하게 여겼던 추상화를 하나하나 파고들어간 이야기를 소개해 볼까 합니다. 수십 명의 개발자들이 만들었던 게임. 36시간 장애 속에서 수백만 명이 서비스 오픈만을 기다리고 있고, DB를 만든 회사에서 복구는 불가능하다고 얘기하는 극한의 상황 속에서 CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기를 소개합니다.

이야기를 시작하기에 앞서 해커 문화(Hacker Culture)를 알고 갑시다. 대중적으로 ‘해킹’이라는 단어는 시스템을 불법적으로 침입하는 행위로 알려져 있습니다. 원래 ‘해킹’의 개념은 MIT에서 시작되었는데, 소프트웨어 시스템이나 하드웨어의 제약사항을 창조적으로 함께 극복해 내는 행위를 뜻합니다. 문제를 해결하거나 시스템의 한계를 극복하기 위해 시스템의 밑바닥까지 파고들고, 그 시스템에 대한 완벽한 이해를 추구합니다. 이러한 해커 문화를 이끌어간 리더들로는 GNU 창시자 RMS, C 언어를 개발한 Dennis Ritchie, Go 언어를 개발한 Ken Thompson, 리눅스를 개발한 Linus Torvalds 등이 있습니다. 보시면 아시겠지만 해커 문화와 오픈소스와는 밀접한 연관이 있습니다.

데브시스터즈의 엔지니어링 조직은 뛰어난 엔지니어링을 지향함과 동시에 해커 문화와 오픈소스를 좋아합니다. 사용하는 오픈소스 제품의 코드 레벨까지 뛰어드는 걸 주저하지 않습니다. 여기서 소개되는 이야기는 이러한 문화가 얼마나 극한까지 갈 수 있는지 보여주며, 극한의 데이터베이스 해킹을 통해 장애를 극복하는 기술적 이야기를 다룹니다.

이야기의 시작은 데브시스터즈 역사상 가장 길었던 쿠키런: 킹덤의 36시간 장애에서 시작합니다. 쿠키런: 킹덤은 메인 데이터베이스로 CockroachDB를 사용합니다. CockroachDB는 우리가 익숙한 전통적인 RDBMS처럼 ACID 특성을 가지고 있으며, SQL 기반의 트랜잭션 처리가 완벽하게 작동하는 분산 데이터베이스입니다. 런칭 전부터 대규모 사용자 유입을 대비하여 데이터베이스는 24대의 노드, 12TB의 스토리지, 7개의 복제본을 두는 설정으로 만반의 준비를 했는데요. 실제로 오픈 직후 어마어마한 사용자 유입이 있었고, 한 주가 채 지나기도 전에 스토리지가 약 8TB 정도로 꽉꽉 차기 시작합니다.

일반적으로 공휴일이 가장 큰 허들인데요. DevOps 조직인 인프라셀은 런칭 첫 주 주말을 장애 없이 넘어갑니다. 이후 월요일부터 스토리지가 차는 문제를 대응하기 위한 작업에 들어갑니다. 여기서 문제의 발단이 시작됩니다. 데이터베이스 확장 작업 전에 안전장치를 설정하기 위한 작업을 하던 중 의도치 않은 설정 미스로 인해 데이터베이스 노드 중 절반 이상이 다운되게 됩니다.

앞서 CockroachDB는 트랜잭션을 지원한다고 했는데요. CockroachDB 클러스터는 기본적으로 Raft 기반의 Consensus Algorithm 을 사용하고, 가장 높은 수준의 트랜잭션 일관성을 목표로 설정되어 있습니다. 앞서 언급한 작업 중 발생한 의도하지 않은 설정 이슈로 인해 절반 이상의 노드들이 비일관성을 탐지하고 에러가 발생하면서 클러스터에서 제외되기 시작합니다. 이에 따라 데이터베이스는 트랜잭션 일관성을 지켜줄 수 없다고 판단하고 트랜잭션 처리를 중단하는 일종의 보호 모드로 들어갑니다. 이 이후 모든 종류의 SQL 쿼리가 처리되지 않게 되고, 게임 서버는 당연히 데이터베이스가 응답이 없으므로, 클라이언트의 모든 요청 처리를 못하게 됩니다. 즉, 서비스 전체 장애가 발생하게 됩니다.

장애를 인지하자마자 저를 포함해 회사의 모든 가용인력이 장애 대응을 위한 비상 대응에 들어갑니다. 비상 대응에 들어가면서 두 가지 계획을 병행해서 운영하게 됩니다(상세한 장애 대응 기록은 별도의 기술블로그 글을 참고하시면 좋습니다.). 그 중 DevOps 팀의 최우선 과제는 데이터베이스를 정상 상태로 복원하는 것이었습니다.

쿠키런: 킹덤에는 장애 시 기술적인 지원을 받을 수 있는 CockroachDB Enterprise를 사용 중이었는데요. 신속히 기술 지원 요청을 보냈고, 온 콜 대기 중이던 서포트 엔지니어와 연락을 하게 됩니다. 상황을 설명하고, 노드의 로그 메시지를 공유하는 등 해당 업체와 함께 트러블슈팅 및 복구 방안을 찾기 위한 작업을 하게 됩니다. 하지만 결론적으로 몇 시간 뒤 상황에 대한 진단이 완료되고 나니, 업체 쪽에서는 복구가 불가능하다는 결론이 납니다. 마지막 백업본으로 데이터베이스를 복구하고 서비스를 재개하는 것을 추천합니다.

서포트 엔지니어가 이러한 추천을 한 기술적인 배경에는 CockroachDB의 설계 철학이 있다고 생각됩니다. CRDB는 Consensus Algorithm을 기반으로 Majority Node에 커밋 된 데이터를 통하여 일관성을 확보하기 때문인데요. 다수의 노드가 설정 미스로 인하여 클러스터 참여가 불가해진 시점에선 이미 데이터가 일관되게 저장되어 있음을 보장할 수 없기 때문에 불완전한 현재 데이터를 복구 하는 것 보다는 일관성이 보장된 상태의 백업으로 복구하는 것을 권장한 것으로 판단됩니다. 만약 CRDB 기반으로 은행 서비스를 개발했다면, 실제로 데이터베이스 복구 작업은 불가하다고 보는 게 맞고, 백업에서 복원하는 게 가장 좋은 선택일지도 모르겠습니다.

하지만 우리의 경우는 상황이 많이 달랐는데요. 쿠키런: 킹덤 서버의 구조는 Snapshot과 Journal을 사용해 데이터를 커밋 하는 Event Sourcing 기반의 아키텍처를 사용합니다.^[1] 따라서 데이터베이스에 있는 Snapshot, Journal 데이터를 가져올 수만 있다면 확률적으로 거의 완벽한 데이터 복구가 가능하다고 판단했습니다. 이에 따라 CockroachDB에 저장되어 있는 원시 데이터에서 테이블에 저장된 row들을 복구하는 방법에 대해 문의하였는데요. 서포트 엔지니어는 그런 마땅한 방법은 존재하지 않는다는 답변을 했습니다. 답변을 듣고 좌절하긴 했지만 (…) 분명히 데이터는 스토리지에 저장되어 있고, 이를 끄집어낼 수 있는 방법이 있을 거라고 생각했습니다. 이론적으로 가능하면, 실제로도 가능하니까요. ^[2]

저와 함께 몇몇 엔지니어들은 CRDB에 저장되어 있는 데이터를 끄집어낼 수 있는 방법을 리서치하기 시작합니다. 우선 CRDB의 아키텍처에 대해서 일부 파악하고 있던 지식들이 있었는데요. 하위 스토리지 레이어는 Pebble로 구성된 Key-Value 스토리지를 사용한다는 사실, 그 위에 Raft 기반의 Consensus Algorithm, 이를 통해 ACID 및 트랜잭션 구현을 했고, 그 위에 SQL 레이어를 구현했다는 것을 알고 있었습니다. 런칭 전에 CockroachDB 스터디를 함께 했었거든요.

Cockroach Labs Architecture Overview

우리는 저장되어 있는 스토리지에서 데이터를 뽑아낼 수 있는 방법이 없을까 고민하기 시작했습니다. 실제 노드에 물리적으로 저장된 파일들을 파보기 시작합니다. sst 확장자의 파일들이 보입니다.

[ec2-user@ip-172-21-76-209 /]$ cd /mnt/nvme1n1/
[ec2-user@ip-172-21-76-209 nvme1n1]$ ls -al
total 1749736
drwxrwsr-x 5 root root    12288 Jan 25 08:09 .
drwxr-xr-x 3 root root       21 Dec 22 15:15 ..
-rw-r----- 1 root root  4179539 Dec 24 09:35 001335.sst
-rw-r----- 1 root root  4194844 Dec 24 09:35 001336.sst
-rw-r----- 1 root root  1412741 Dec 24 09:58 001364.sst
-rw-r----- 1 root root  8405018 Dec 25 14:11 003425.sst
-rw-r----- 1 root root  8337500 Dec 25 14:11 003426.sst

여기서 sst 파일은 무엇일까요? CockroachDB에서 사용하는 Pebble은 Facebook에서 만든 RocksDB의 후계자이고, RocksDB는 Google에서 만든 LevelDB의 후계자입니다.^[3] sst 파일은 LevelDB가 스토리지에 데이터를 물리적으로 저장할 때 사용하는 확장자입니다. Pebble의 sst 파일이 RocksDB, LevelDB의 sst 파일과 호환이 될지 살펴봅니다.

https://www.cockroachlabs.com/docs/stable/architecture/storage-layer.html

CockroachDB uses the Pebble storage engine. Pebble is intended to be bidirectionally compatible with the RocksDB on-disk format, but differs in that it is written in Go and implements a subset of RocksDB's large feature set.

우선 Pebble은 RocksDB와 on-disk format 호환을 목표로 한다고 되어있습니다. 하지만 RocksDB의 경우 LevelDB와 API 레벨에서의 호환성만 얘기하지, on-disk format 에 대한 이야기는 찾아볼 수 없었습니다.

https://github.com/facebook/rocksdb/wiki

It was developed at Facebook based on LevelDB and provides backwards-compatible support for LevelDB APIs.

이에 따라 on-disk format이 동일한 RocksDB 의 구조를 파악하기 시작합니다. 조금 다르긴 하지만 기본적인 구성은 LevelDB와 유사하며, 확장한 형태로 보였습니다.

https://github.com/facebook/rocksdb/wiki/Rocksdb-BlockBasedTable-Format

<beginning_of_file>
[data block 1]
[data block 2]
...
[data block N]
[meta block 1: filter block]                  (see section: "filter" Meta Block)
[meta block 2: index block]
[meta block 3: compression dictionary block]  (see section: "compression dictionary" Meta Block)
[meta block 4: range deletion block]          (see section: "range deletion" Meta Block)
[meta block 5: stats block]                   (see section: "properties" Meta Block)
...
[meta block K: future extended block]  (we may add more meta blocks in the future)
[metaindex block]
[Footer]                               (fixed size; starts at file_size - sizeof(Footer))
<end_of_file>

실제 온전한 CRDB sst 파일들을 받아서 분석해 보기 시작합니다. hexdump 명령으로 보니까 내가 원하던 데이터가 들어있었습니다.

파일을 어떻게 파싱해서 우리가 원하는 데이터를 읽어올지 고민해 봅니다. sst 파일의 뒷부분에 metadata를 읽어야 data block들을 읽을 수 있습니다. 다만 실제 data block 들에 들어있는 CRDB의 row 데이터를 저장하는 방식도 파악이 필요해 보였습니다. 얘네들은 어떻게 구성되어 있는 걸까요?

Cockroach Labs Column Families

CRDB 문서를 읽어보니 Column Family라는 개념으로 K-V Store 저장되는 것을 확인했습니다. 구체적으로 어떻게 저장되는 걸까요? CRDB 소스코드 레포지토리 내에 있는 Design Document 들을 읽어보기 시작했습니다.

/<tableID>/<indexID>/<primaryKeyColumns...>/<columnID>

소스코드를 탐색하다보니 실제로 저장에 사용되는 Protocol Buffer 파일을 발견합니다.

https://github.com/cockroachdb/cockroach/blob/v21.1.19/pkg/roachpb/data.proto

// Value specifies the value at a key. Multiple values at the same key are
// supported based on timestamp. The data stored within a value is typed
// (ValueType) and custom encoded into the raw_bytes field. A custom encoding
// is used instead of separate proto fields to avoid proto overhead and to
// avoid unnecessary encoding and decoding as the value gets read from disk and
// passed through the network. The format is:
//
//   <4-byte-checksum><1-byte-tag><encoded-data>

주석을 읽어보니 Value 값이 <4-byte-checksum><1-byte-tag><encoded-data> 형태로 저장되고 있습니다. 스토리지에 저장된 파일을 직접 파싱해보고 싶어집니다. 파싱하는 코드도 발견합니다.

func (v Value) PrettyPrint() string {
  // ...
 var buf bytes.Buffer
 t := v.GetTag()
  // ...

 switch t {
 case ValueType_TUPLE:
  b := v.dataBytes()
  var colID uint32
  for i := 0; len(b) > 0; i++ {
      // ...
   _, _, colIDDiff, typ, err := encoding.DecodeValueTag(b)
   // ...
   b, s, err = encoding.PrettyPrintValueEncoded(b)
   // ...
   fmt.Fprintf(&buf, "%d:%d:%s/%s", colIDDiff, colID, typ, s)
  }
  // ...

코드를 쭉 읽어보면 앞서 주석에서 읽었던 순서대로 (checksum 은 생략하고) <1-byte-tag>를 읽고 case 문으로 Value Type 별로 별도의 파싱 루틴을 타서 예쁘게 출력을 하는 구조를 볼 수 있습니다.

실제 데이터가 들어있는 sst 파일을 하나 hexdump로 열어봅니다. 우리가 관심 있는 데이터는 보통 string 형태로 저장된게 보입니다. 그 부근으로 이동하여 <4-byte-checksum><1-byte-tag><encoded-data> 형태의 바이너리 패턴이 보이는지 확인해 봅니다. Checksum을 건너뛰고, 1-byte-tag 섹션을 체크해 봅니다. 값이 0x0a, 10진수로 10입니다. ValueType_TUPLE이네요. Tuple 은 내부 값을 어떻게 저장하고 있을까요? 주석을 확인해 보니 다음과 같이 설명합니다.

TUPLE represents a DTuple, encoded as repeated pairs of varint field number followed by a value encoded Datum.

DTuple 이 뭔지는 모르겠으나 장애 상황이니 일단 넘어갑니다. 인코딩을 설명하는데 varint 타입으로 field number를 저장하고, 그 이후에는 다시 Value 인코딩이라는 얘기입니다. 인코딩된 데이터를 확인해 봅니다. 위 경우는 첫 번째 아이템은 필드 번호 0x34이고 그다음에 다시 태그 값 0x08이 나옵니다. 문서를 보면 DELIMITED_BYTES라네요. DELIMITED가 붙어있지만 일단 BYTES라고 가정하고 파싱을 해봅시다. 그다음 바이트들을 체크해 봅니다. 0x01 0x12는 뭔지 잘 모르겠지만 그다음 0x30 은 왠지 Byte의 길이를 나타내는 값이 나오는 것 같네요. 실제로 10진수로 48인데, 뒤에 나오는 아스키 값들을 카운팅 해보니 길이가 48이 맞습니다. Protocol Buffer Encoding 문서를 보니 다음과 같이 설명합니다.

A wire type of 2 (length-delimited) means that the value is a varint encoded length followed by the specified number of bytes of data.

Protocol Buffer의 varint 타입은 최대한 많은 숫자들을 압축해서 저장하기 위한 protocol buffer에서 고안된 기법입니다. 자세한 내용은 Protocol Buffer Encoding 문서의 Base 128 Varints를 참고합니다. 필자의 경우도 이게 뭔지는 대략 알고 있었지만 기억이 확실하지 않게 때문에 문서를 확인하면서 파싱을 해봅니다. 파싱 중인 예시를 varint 기법에 맞게 파싱을 해보니 여전히 48이 나옵니다. Wire type 2 (LEN) 파싱 관련 문서 Length-Delimited Records의 예시를 보니 익숙한 패턴이 보입니다.

12 07 [74 65 73 74 69 6e 67]

즉, 0x12는 Wire type 2 (LEN) 을 알려주는 태그이며, 그다음 나오는 값이 varint로 인코딩된 길이인 것이었습니다. 우리의 실제 데이터의 경우에는 0x30, 즉 48이었던 것이죠. 여전히 0x01의 의미를 모르겠는데, 일단 넘어갑니다.

길이 이후에는 우리가 그토록 꺼내고 싶었던 저장된 데이터 값들이 보입니다. 희망이 생겼습니다. 이론적으로 파싱이 가능한 것에서, 실제로 손 파싱을 통해 데이터를 파싱해올 수 있음을 증명해냈습니다. 이제 데이터가 어디에 어떻게 저장되어 있는지 알고 있습니다. 7TB의 데이터를 전부 꺼내오는 방법을 고민하면 됩니다.

장애 상황이기 때문에 빠르게 구현해야 했습니다. 사용자의 데이터이기 때문에 정확하기도 해야 합니다. 저장된 데이터가 약 7TB 정도 됩니다, 따라서 처리 속도도 좋아야 합니다. 가장 어렵다는 세 가지를 만족해야 했습니다: 빨리 만들고, 오류 없어야 하고, 성능도 좋아야 했던 것이죠. 우선순위를 따져봅니다. 우선 빠르게 구현 가능하면서 정확해야 합니다. 처리 성능은 데브시스터즈 데이터플랫폼셀의 데이터 분산처리 역량과 AWS의 클라우드 컴퓨팅 자원을 믿고 돈으로 성능을 살 수 있다고 판단했습니다.

빠르고 정확하게 구현하기 위한 방법을 팀과 치열하게 고민했습니다. 다양한 아이디어가 나왔지만, 결과적으로 채택한 것은 소스코드를 읽어보면서 발견한 PrettyPrint 함수입니다. 이게 어디에서 사용되나 보니까 CLI 툴에서 디버깅을 위한 기능에서 사용됩니다. 결국 바이너리 sst 파일을 파싱해서 엔지니어가 읽을 수 있는 형태로 터미널에 출력해 주는 함수입니다. 그렇다면 이걸 변경해서 csv를 출력하게 하면 어떨까요?

CockroachDB CLI 소스코드를 수정해 줄 사람을 찾아봅니다. 데브시스터즈에서 Go 언어에 가장 뛰어나고, 스트레스 상황 속에서도 손이 빠르고, 정확한 사람을 찾아야 합니다. 인프라셀 셀장님을 선정합니다. 스펙을 논의하여 명확히 하고 가칭 crdb2csv 프로그래밍 작업에 착수합니다.

필자는 그 사이에 7TB의 데이터를 어떻게 하면 분산처리하여 csv 파일을 만들 수 있을지 고민해 봅니다. 데이터 분산처리에 경험이 많은 데이터플랫폼셀 엔지니어 분들과 해당 방법에 대한 논의를 시작합니다. PySpark 샘플 코드를 작성해 보면서 crdb2csv 프로그램이 왔을 때를 대비하여 분산처리 준비를 해둡니다.

프로토타입이 완성되어 이를 PySpark 코드를 통해 7TB의 sst 파일들에 대해서 돌려봅니다. 에러가 발생합니다. 에러 메시지를 공유하여 crdb2csv 소스코드를 디버깅하고 고칩니다. 이러한 작업을 여러 번 수행하고 나니 점점 완성도가 높아집니다.

def download_then_parse_sst(row):
    '''
    파라미터로 입력된 S3 버킷에 있는 sst 파일을 다운받아 내용물을 crdb2csv로 변환하여 문자열 반환
    '''
    key_name = row
    with NamedTemporaryFile() as file:
        Key(Bucket(connect_s3(), INPUT_BUCKET_NAME), key_name).get_contents_to_filename(file.name)
        run = subprocess.Popen([CLI, "crdb2csv", file.name], stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)

        while run.poll() is None:
            line = run.stdout.readline()
            yield Row(
                key_name=key_name,
                stdout=line.decode('utf-8').strip(),
            )
        output = run.communicate()[0]
        for line in output.decode('utf-8').split("\n"):
            yield Row(
                key_name=key_name,
                stdout=line,
            )

처리시간이 오래 걸립니다. 아무래도 csv 파일은 텍스트 포맷이고, stdout 출력물을 받으니 느릴 수밖에 없습니다. 예상되던 부분입니다. AWS 클라우드에서 컴퓨팅 자원을 끌어모을 수 있을 만큼 끌어모읍니다.

기록을 확인하니 Spark 클러스터에만 r5.8xlarge 350대를 사용했습니다. CPU 11,200코어 / 메모리 89,600GB 정도 되는 사양입니다. 이마저도 AWS의 도쿄 리전 캐퍼시티를 다 사용해버려서 350대를 운용하는 데에 큰 어려움을 겪었습니다. 결과적으로 어떻게든 확보한 노드들로 7TB의 데이터를 CSV 파일로 변환하는 데만 4시간이 걸렸습니다. crdb2csv 프로그램의 오류를 발견하여 이 4시간이 소요되는 작업도 여러 번 반복합니다.

변환한 파일에 모든 사용자 데이터가 담겨있는지 검증하는 작업도 꽤 오래 걸렸습니다. 데이터베이스가 사용하는 MVCC 구조상 필요 없는 사용자의 데이터가 다수 있었기 때문에 이를 제거하고, 최신 값을 뽑아내고, 뽑아낸 데이터를 백업본, 분석 로그와 교차 검증을 하면서 빠진 데이터가 없는지 체크를 진행했습니다. 결과적으로 뽑아낸 파일에 모든 사용자 데이터가 정확하게 담겨있음을 확인할 수 있었습니다.

이것들을 확인하는 중에 인프라 조직에서는 새로운 CockroachDB 클러스터를 준비하고 있었는데요. AWS 노드들을 다 끌어다 쓴 탓에, 해당 클러스터를 셋업하는 것도 여간 힘든 일이 아니었습니다. 결과적으로 클러스터 셋업이 완료되고, 확인이 완료된 CSV 파일을 클러스터에 적재하였습니다. 불러올 데이터가 크다 보니 예상외로 이것도 상당한 시간이 소요되었습니다.

이렇게 다시 정상 작동하는 데이터베이스를 만들었고, 이를 전사적으로 테스트를 거쳐서 36시간 만에 서비스를 다시 오픈하게 되었습니다(사실 오랜 시간 기다려주신 고객분들의 열렬한 성원에 힘입어 추가적인 장애들이 발생했는데요. 이에 대해서는 다음 기회에 다뤄보도록 하겠습니다.).

일련의 장애 복구 과정을 회고해 볼 때, 이러한 서비스 복구 방식은 전혀 일반적인 방식은 아니라는 생각이 들었습니다. 데이터베이스 업체에서 복구 불가 판정을 내렸으면, 이미 그 시점부터 백업본으로 서비스를 복구하는 소위 ‘백섭'을 하는 게 일반적이었을 겁니다. 시간은 다소 오래 걸렸을지라도 데브시스터즈 엔지니어들이 이런 방식으로 장애를 복구한 것에는 다음과 같은 이유가 있다고 생각합니다:

고객에게 최고의 경험을 선사하는 게 우리의 미션이고, 이를 진심으로 실천하기 위해 노력했습니다. 그 누구도 낙담하고 포기하지 않았습니다.
해커 문화를 가지고 있기 때문에 엔지니어들이 로우 레벨로 뛰어드는 것에 익숙했습니다. 데이터베이스 레벨부터 커널, VM 레벨까지 다양한 경험이 있는 엔지니어들이 있었습니다. 상호 지식공유를 통해 데이터베이스의 다양한 추상화 레벨에 대한 전방위적인 이해가 가능했습니다.
남의 소스코드를 읽고 고치는 것에 익숙한 조직입니다. 오픈소스 프로젝트들을 매일 이용하고, 문제가 있으면 소스코드를 읽고, 필요하다면 직접 고치면서 기여하기 때문에 가능했습니다.
데브시스터즈 산하 CTO 조직인 진저랩은 데이터와 인프라 관련 팀들이 한 조직에 속해있습니다. 일반적으로 분산처리 플랫폼은 지표 등의 데이터 분석에 주로 사용되는데요. 데이터와 인프라가 한 조직에 있다 보니 분산처리 역량으로 인프라 장애를 극복하는 특별한 시너지가 가능했습니다.
확장성 있는 인프라를 다루는 경험, 대용량의 데이터를 분산처리하는 경험이 풍부했습니다. 물론 7TB 단위의 데이터베이스 바이너리 데이터를 이렇게 극한 상황에서 다루는 건 처음이었고, 이를 통해 더 많이 성장했습니다.
장애 대응 경험이 풍부했기 때문에 Plan A/B/C를 동시에 가동하는 등 여러가지 복구 전략을 함께 진행했고, 실제로 두 가지 복구 전략을 혼합하여 완벽하게 장애 복구를 할 수 있었습니다.
조를 나누어서 여러 가지 복구 전략을 동시 실행했기 때문에, 내가 실패하더라도 플랜 B를 실행하는 동료를 믿고 과감하게 앞으로 전진할 수 있는 용기를 낼 수 있었습니다.

엔지니어로서 커리어의 최대 위기가 왔었고, 팀 분들과 함께 쌓아왔던 우리의 소중한 문화, 핵심가치, 경험 덕분에 이를 극복해낼 수 있었던 것 같습니다. 다시는 경험하고 싶지 않은 장애지만, 또 한편으로는 데브시스터즈의 팀워크가 가장 빛났던 순간이었던 것 같습니다. 뛰어난 동료분들과 최악의 장애를 함께 극복하는 경험은 평생 절대 잊을 수 없는 경험이었습니다. 저는 우리가 이 장애로 또 한 번 성장했음을 느낍니다.

지금까지의 글이 흥미로우셨다면, 이러한 문화와 핵심가치가 공감이 되신다면, 저희와 함께 일해보시는 건 어떨까요? 채용의 문은 활짝 열려있습니다. 지향점이 같은 훌륭한 미래의 동료분들을 모십니다. 읽어주셔서 감사합니다!

[1]: 쿠키런: 킹덤의 서버 구조는 NDC 발표를 참고하면 됩니다

[2]: 다만 이론적으로 가능하다 해도, 장애 상황이라는 아주 특수한 상황 속에서 얼마나 걸릴지 알 수 없는 이런 접근을 선택하는 게 쉽지는 않았는데요. DB 직접 복구가 불가능할 때를 대비한 로그 기반의 복구를 Plan B로 잡고 데이터 직군 엔지니어들과 서버 개발자분들이 해당 작업을 진행하고 있었습니다. 내가 실패해도 이들이 성공할 거라는 믿음을 갖고 공격적으로 진행할 수 있었습니다. 자세한 이야기는 다른 글에서.

[3]: 여담이지만 LevelDB도 구글의 전설적인 소프트웨어 엔지니어 Jeff Dean의 작품입니다

9가지 프로그래밍 언어로 배우는 개념: 4편 - 하이 레벨 언어와 동적 타입 언어

Thu, 12 Jan 2023 00:00:00 GMT

#프로그래밍 언어 시리즈

9가지 프로그래밍 언어로 배우는 개념: 1편 - 타입 이론
9가지 프로그래밍 언어로 배우는 개념: 2편 - 다형성
9가지 프로그래밍 언어로 배우는 개념: 3편 - 메타프로그래밍
9가지 프로그래밍 언어로 배우는 개념: 4편 - 하이 레벨 언어와 동적 타입 언어
9가지 프로그래밍 언어로 배우는 개념: 5편 - 동시성 프로그래밍

#서론

안녕하세요, 킹덤 서버 소프트웨어 엔지니어 지민규입니다. 이번에는 아키텍처 디자인에 있어 하이 레벨 언어와 동적 타입 언어에 대한 저의 견해들을 나누기 위해 글을 쓰게 되었습니다.

#하이 레벨 언어

프로그래밍 언어를 비교할 때, 하이 레벨과 로우 레벨로 나눌 수 있습니다. 다만 이 기준은 상대적인 경우가 많습니다. 가령 어셈블리와 C를 비교했을 때 어셈블리 언어는 로우 레벨, C는 하이 레벨이라고 할 수 있고 C와 Javascript를 비교했을 때는 C는 로우 레벨, Javascript를 하이 레벨이라고 할 수 있죠.

이 글에서는 메모리를 직접적으로 관리하는지 혹은 **가비지 컬렉터(Garbage Collector)**를 사용하여 관리하는지에 따라 로우 레벨, 하이 레벨로 나눕니다. 직접 메모리를 할당하고 풀어줘야하는 C는 로우 레벨 언어이고 이를 가비지 컬렉터가 자동적으로 관리해주는 Javascript은 하이 레벨 언어이죠. 로우 레벨과 메모리 관리의 안전성은 관련 없습니다. C++에서는 **RAII(Resource Acquisition is Initialization)**를 통해서 메모리 관리를 조금 더 안전하게 만들었지만 여전히 로우 레벨 언어로 취급됩니다. Rust는 특유의 레퍼런스 관리 시스템인 **버로우 체커(Borrow Checker)**를 통해 메모리 관리의 위험성을 거의 제거 했음에도 로우 레벨 언어입니다.

로우 레벨 언어와 하이 레벨 언어가 어떠한 차이를 보여주는지는 누구나 잘 알고 있습니다. 로우 레벨 언어는 일반적으로 성능이 더 좋지만 번거롭고 하이 레벨 언어는 일반적으로 성능이 상대적으로 낮은 대신에 메모리 관리에 대해 고민하지 않아도 됩니다. 가비지 컬렉터가 어떠한 장단점이 있는 지도 꽤 재밌는 주제이지만, 이 글에서는 메모리 관리에 대한 번거로움이나 성능이 아닌, 아키텍처 디자인에 있어 하이 레벨 언어들이 어떠한 장점들이 있는지를 집중해보려고 합니다.

#모든 것은 레퍼런스

하이 레벨 언어의 가장 큰 특징을 꼽아본다면 대부분의 타입들이 레퍼런스 형태로 저장된다는 것입니다. 흔히 Java에서 “모든 클래스 인스턴스는 레퍼런스로 저장된다”라는 말을 들어보셨을 수도 있습니다.

// Java 코드
class Human {
  public String name;
}

// Human 인스턴스에 대한 레퍼런스를 human1에 저장한다
Human human1 = new Human("Mango");

// human1에 저장된 레퍼런스를 복사하여 human2에 저장한다
Human human2 = human1;

// human2에 저장된 레퍼런스를 따라가서 Human 인스턴스의 name 필드를 수정한다
human2.name = "Tango";

// human1에 저장된 레퍼런스를 따라가서 Human 인스턴스의 name 필드를 출력한다
// 여기서 human1에 저장된 레퍼런스와 human2에 저장된 레퍼런스는
// 같은 인스턴스에 대한 레퍼런스 이므로
// Tango가 출력된다
System.out.println(human1.name);

Java에서 클래스 인스턴스를 만들려면 new를 해야 합니다. 그렇게 만들어진 인스턴스는 변수에 저장할 때 레퍼런스로 저장되죠. 다른 변수에 레퍼런스를 대입할 때는 인스턴스가 복사되는 것이 아닌 레퍼런스가 복사됩니다. 위 예시에서는 human2에 human1을 대입했기 때문에 이제 두 변수는 같은 레퍼런스를 가지게 됩니다. human1을 통해 인스턴스를 수정하는 것과 human2를 통해 인스턴스를 수정하는 것은 같은 작업입니다.

C/C++에서 Struct 변수 대입은 다릅니다. C/C++에서는 기본적으로 인스턴스를 복사하게 됩니다. 이러한 인스턴스 자체를 저장하는 타입을 값 타입이라고 합시다.

// C++ 코드
struct Human {
  string name;
};

// Human 인스턴스를 human1에 저장한다
Human human1 = { "Mango" };

// human1에 저장된 인스턴스를 복사하여 human2에 저장한다
Human human2 = human1;

// human2에 저장된 인스턴스의 필드를 수정한다
human2.name = "Tango";

// human1과 human2는 다른 인스턴스를 저장하고 있으므로
// human2의 필드 수정이 human1에 영향을 끼치지 않는다
// 따라서 Mango가 출력된다
cout << human1.name << endl;

C++에서는 레퍼런스를 저장하고 싶다면 레퍼런스 타입을 사용해야 합니다. 위 예시에서 변수의 타입을 Human에서 Human&로 바꾸어야 하죠

// C++ 코드
struct Human {
  string name;
};

Human& human1 = { "Mango" }; // 사실 Human&&를 써야한다 (C++ rvalue reference 참조)
Human& human2 = human1;
human2.name = "Tango";

// Tango가 출력된다
cout << human1.name << endl;

로우 레벨 언어에서 레퍼런스 타입이 아닌 값 타입을 사용하는 이유는 성능 최적화와 메모리 관리의 간편성 때문입니다. 레퍼런스 타입은 레퍼런스를 “따라가는” 연산이 필요하지만 값 타입은 그러한 작업이 필요 없고 메모리를 할당하고 풀 필요가 없기 때문입니다.

물론 하이 레벨 언어도 C#이나 Go 같이 값 타입을 지원해주는 경우도 있습니다. Java도 int나 float 같은 기초 타입들은 값 타입으로 취급되기도 하고요. 하지만 로우 레벨 언어에 비하면 레퍼런스 타입을 활용하는 빈도가 더 높습니다.

#타입 호환 문제

값 타입은 단점이 하나 있습니다. 값 타입 변수들은 제각각 다른 크기의 메모리를 요구합니다.

// C++ 코드, 64비트 환경
cout << sizeof(int) << endl; // int의 값 타입, 4가 출력된다
cout << sizeof(long) << endl; // int의 값 타입, 8이 출력된다

cout << sizeof(int*) << endl; // int의 레퍼런스 타입, 8이 출력된다
cout << sizeof(long*) << endl; // long의 레퍼런스 타입, 8이 출력된다

레퍼런스 타입은 일반적으로 32비트 환경에서 4바이트, 64비트 환경에서 8바이트를 차지합니다. 따라가야 할 인스턴스의 메모리 주소를 저장해야 하기 때문이죠. 대상 인스턴스 타입의 크기가 4바이트든 8바이트든, 몇백 메가바이트가 되든 64비트 환경에서는 메모리 주소를 저장할 8바이트만 있으면 됩니다.

여기서 생겨나는 문제점이 뭘까요? 바로 업캐스팅 및 다운캐스팅에 제약이 걸린다는 것입니다. 다형성 편과 메타프로그래밍 편에서 업캐스팅과 다운캐스팅에 대해 언급했었는데요, 간략하게 설명하자면 타입의 계층 간 타입 캐스팅입니다. 상위(부모) 타입으로 캐스팅하면 업캐스팅이고 하위(자식) 타입으로 캐스팅하면 다운캐스팅입니다. 서로 요구하는 메모리 공간이 다를 수도 있는 타입끼리의 캐스팅이기 때문에 제약이 걸립니다.

// C++ 코드
// 4 바이트 크기의 struct
struct Fruit {
  int weight;
};

// 8(4 + 4) 바이트 크기의 struct
struct Apple : public Fruit {
  int redness;
};

Apple apple = {280, 7};

// 4 바이트 크기의 변수에 8 바이트 크기의 변수를 대입했다?
// redness 필드는 버린 상태로 복사한다
Fruit fruit = apple;

// 8 바이트 크기의 변수에 4 바이트 크기의 변수를 대입했다?
// redness 필드를 채울 방법이 없으므로 컴파일 에러
Apple apple2 = fruit;

어떻게 보면 당연한 것이기도 합니다. 레퍼런스 타입들은 같은 메모리 주소를 담는 타입들이기에 계층 구조간 캐스팅이 자유롭지만, 값 타입들은 같은 계층 구조에 속하더라도 서로 다른 타입이기에 캐스팅 시 일부 정보를 버려야 하거나 불가능합니다.

여기서 비롯되는 실질적인 문제는 어떤 것들이 있을까요? 바로 다형성 편에서 언급하였던 Variance가 적용되지 않는다는 것입니다. Variance는 업캐스팅을 기반으로 작동하므로 애초에 제네릭 타입 T가 업캐스팅 될 수 없다면 Variance 규칙을 만족할 수 없겠죠. 그렇기 때문에 값 타입을 사용하였을 경우 Variance를 활용하기 어렵습니다.

// C# 코드
// Covariant한 T
public interface IEnumerable<out T> {}

// 값 타입
public struct Human {
  public string name;
}

// 내부적으로 Human 배열을 가진 List를 인터페이스로 캐스팅한다
IEnumerable<Human> humans = new List<Human>();
// 내부의 Human 배열과 object 배열의 요소 단위 크기가 호환되지 않는다
// object이 Human의 상위 타입이라서 Covariant 규칙을 만족하지만 컴파일 실패한다
IEnumerable<object> objects = humans;

// 레퍼런스 타입인 string은 잘되는데...
IEnumerable<string> strings = new List<string>();
IEnumerable<object> objects = strings;

C#에서 struct의 상속을 금지하는 이유도 여기에 포함되어있을 겁니다. struct의 상속을 허용하여 타입 계층 구조를 확장할 수 있도록 한다면 class의 Variance 규칙과 struct의 Variance 규칙이 달라져 언어의 일관성이 떨어집니다. 언어의 복잡도가 늘어난다는 것이죠

C#을 자주 다뤄보신 분이라면 뭔가 이상한 점을 눈치챘을지도 모릅니다. struct 타입들은 object 타입에 대입할 수 있거든요. 과연 무슨 일이 일어나는 것일까요?

// C# 코드
// 값 타입
public struct Human {
  public string name;
}

Human human = new Human();
// 값 타입인 Human은 다른 타입으로 캐스팅 될 수 없는 거 아니었나?
object humanObject = human;

사실 이건 단순한 캐스팅이 아닙니다. Boxing을 하고 있는 것이죠. Boxing이란 새로운 메모리를 할당한 뒤 기존 메모리를 복사하는 것을 말합니다. 위 예시에서는 Human 값 타입을 위한 메모리 공간을 마련하고 복사한 뒤 그 메모리에 대한 레퍼런스를 object 레퍼런스 타입에 대입한 것입니다. 값 타입을 레퍼런스 타입으로 변화시켜 캐스팅을 가능하게 만든 것이죠.

Rust를 사용해보신 분들이라면 Boxing이라는 단어가 익숙하실 겁니다. 바로 Box<T> 타입이죠.

// Rust 코드
// Box에 대한 정말 대략적인 구현
pub struct Box<T> {
  value: *const T,
}

pub struct Human {
  name: String,
}

let human: Box<Human> = Box::new(Human { name: "Mango".to_owned() });
let any: Box<dyn Any> = human;

Box<T>는 T타입을 요구하지만 실제로는 필드로써 레퍼런스 타입인 *mut T를 들고 있고 값 타입인 T를 가지고 있지 않습니다. 따라서 Box<T>의 T는 Variance 규칙이 적용될 수 있습니다. 위 예시에서는 Box<Human>을 Covariance를 이용하여 Box<dyn Any>로 바꿀 수 있었습니다.¹

값 타입을 자주 활용하는 로우 레벨 언어에서는 Variance를 자주 활용하기 어렵습니다. C++에서는 아예 지원하지 않고 Rust에서는 특정 타입에 대해서만 사용 가능하다거나 많은 제약 조건이 걸려 있습니다. 이 때문에 거의 모든 것을 레퍼런스 타입으로 저장하는 하이 레벨 언어에 비해 표현력이 더 떨어질 수 있습니다. 성능을 위해 값 타입을 사용한 댓가이죠. 그렇기 때문에 현대적인 로우 레벨 언어에서는 C++의 템플릿이나 Rust의 매크로 같은 막강한 메타프로그래밍 기능을 제공하여 대체적인 방안을 제공하는 경우가 많은 것 같습니다.

#동적 타입 언어

동적 타입 언어는 변수나 필드의 타입이 고정되어있지 않으며 런타임에 타입이 변경될 수 있는 언어를 가리킵니다. 동적 타입 언어인 Javascript에서는 String이었던 변수를 number, object로 바꿀 수 있습니다.

// Javascript 코드
let value = 'Mango'; // String 대입
value = 7337; // number 대입
value = { name: 'Tango' }; // object 대입

이걸 위의 타입 호환 문제와 엮어서 잘 생각해보시면 뭔가 느낌 오는 것이 있을 겁니다. 그렇습니다, 동적 타입 언어의 모든 타입은 레퍼런스 형태로 저장됩니다. 실제로는 성능 최적화가 적용되었기 때문에 number와 같은 기초 타입들은 레퍼런스가 아닌 채로 저장되기도 하지만 레퍼런스 타입처럼 동작합니다. 레퍼런스 타입을 많이 활용하는 만큼 대다수의 동적 타입 언어들은 가비지 컬렉터 또한 사용하고 있는데요, 자연스럽게 동적 타입 언어는 하이 레벨 언어의 장단점을 물려받게 됩니다.

동적 타입이 가져오는 문제점은 잘 아실 것이라고 생각합니다. 바로 타입 오류가 런타임에 발생한다는 것과 문서화가 필수라는 것입니다. 이로 인해 null 문제도 발생한다는 문제점도 존재합니다.

// Javascript 코드
// 과연 무슨 타입을 입력 받고 출력할까...
function evaluateGrade(score) {
  /* ... */
}

동적 타입 언어에서는 변수나 인수에 모든 타입을 넣을 수 있다고 해서 모든 타입을 넣어도 작동하도록 함수를 짜지 않습니다. 각 함수나 클래스마다 적절한 타입을 요구하도록 구현합니다. Javascript에서는 함수에서 출력 타입이나 인수 타입을 명시적으로 적지 않기 때문에 오로지 함수 이름과 인수 이름만으로 인수 타입과 출력 타입을 예상해야 합니다.

프로젝트 규모가 작을 때는 큰 문제가 되지 않지만 프로젝트의 규모가 커지고 복잡도가 높아질수록 주석을 통해서 문서화하는 것이 반쯤 필수적입니다. 정적 타입 언어에서는 명시적으로 적는 타입이 그 역할을 했었지만, 동적 타입 언어에서는 코멘트들로 처리해야 합니다. 어느 정도 동적 타입 언어의 장점을 포기하는 일이지만, 다른 방법이 없습니다.

// Javascript 코드
/**
 * @param {number} score - 0~100점 대의 점수
 * @return {number} 1~5점 대의 등급
 */
function evaluateGrade(score) {
  /* ... */
}

만약 잘못된 타입을 넘기게 되면 해당 함수 호출을 실행하기 전까지 버그가 있는지 알 수 없습니다. 이 문제를 완화 시키려면 테스트를 통해 수정 후 실행까지의 간격을 줄여야 합니다.

한 가지 더 아쉬운 점이라면 타입의 흐름을 확인하기 어렵다는 것입니다. 어디에서 생성된 타입이며 어떠한 흐름으로 어떤 함수에 도달하는지 파악하기 어렵다는 것이죠. 이는 디버깅이나 신규 인원이 코드를 파악할 때 좀 더 어렵게 만드는 요소 중 하나입니다.

이런 문제점들을 넘어간다면 풍부한 표현력을 가진 언어가 됩니다. 타입클래스나 Variance, 메타프로그래밍 지원이 약한 정적 타입 언어들에 비해서는 할 수 있는 것이 많은 언어가 되죠.

#합타입

타입 이론 편에서 소개해 드렸던 합 타입에 대해서 생각해봅시다. 당연하게도 모든 타입이 합 타입입니다. 같은 변수에 여러 타입을 대입할 수 있고 컴파일러가 그걸 거부하지 않기 때문이죠.

다만 아쉬운 점은 합 타입과 함께 자주 사용되는 완전 패턴 매칭 또한 사용할 수 없습니다. 이론적으로 매칭의 대상이 되는 값이 모든 타입이 될 수 있는데 모든 타입에 대응되는 케이스들을 작성할 수 없기 때문입니다. 그렇다고 default 케이스를 작성하거나 그냥 무시한다면 합 타입에 새 타입을 추가했을 때 런타임 에러가 발생할 가능성이 높습니다.

// Javascript 코드
function applyDiscount(originalPrice, discount) {
  // Javascript에서는 패턴 매칭이 없어서 간접적으로 해야한다
  // 여기서는 클래스 이름으로 매칭한다
  switch (discount.constructor.name) {
    case 'FixedDiscount':
      return max(originalPrice - discount.amount, 0);
    case 'RatioDiscount':
      return max(originalPrice * (1 - discount.ratio), 0);
    // 실수로 하나 빠트렸다
    // 이로 인해 발생하는 에러는 실행전까지 볼 수 없다
    // case 'Voucher':
    //   return 0
  }
}

완전 패턴 매칭이 존재하는 언어에서는 케이스를 빠트리면 컴파일 에러가 납니다. 그렇기 때문에 합 타입에 새 타입을 추가해도 수정이 강제되기 때문에 안전하죠. 그렇기 때문에 동적 타입 언어에서 합타입이 사용 가능하다 한들 부주의하게 사용할 경우 버그로 이어질 가능성이 높습니다.

// Scala 코드
def applyDiscount(originalPrice: Int, discount: Discount) =
  // 완전 패턴 매칭
  discount match {
    case Fixed(amount) => max(originalPrice - amount, 0)
    case Ratio(ratio)  => max(originalPrice * (1 - ratio), 0)
    // 실수로 하나 빠트렸다
    // 그렇지만 컴파일 할 때 컴파일 에러가 잡아준다
    // case Voucher    => 0
  }

#덕 타이핑

정적 타입 언어에 인터페이스, 타입클래스, 제네릭이 있다면 동적 타입 언어에는 **덕 타이핑(Duck Typing)**이 있습니다. 덕 타이핑은 서로 다른 타입들이 가진 메소드와 필드들이 같다는 것을 이용해 다형성을 이루는 것입니다. 위의 Discount 예시를 덕 타이핑 방식으로 해결한다면 다음과 같습니다.

// Javascript 코드
class FixedDiscount {
  applyDiscount(originalPrice) {
    return max(originalPrice - this.amount, 0);
  }
}

class RatioDiscount {
  applyDiscount(originalPrice) {
    return max(originalPrice * (1 - this.ratio), 0);
  }
}

class VoucherDiscount {
  applyDiscount(originalPrice) {
    return 0;
  }
}

let originalPrice = 15000;
let discount = getDiscount();
discount.applyDiscount(originalPrice);

여기서 중요한 점은 각 Discount 타입들이 공통 부모를 가졌거나 특정 인터페이스를 지정하고 있지 않다는 것 입니다. 그저 메소드가 같은 이름을 공유할 뿐입니다. 실제로 넘겨지는 인수가 어떤 타입인지, 같은 타입을 출력하고 있는지도 신경 쓰지 않습니다. 이 점에서 덕 타이핑은 정적 타입 언어의 인터페이스와 제네릭이 담당하는 다형성 영역을 커버할 수 있습니다.

다형성 편에서 인터페이스의 2가지 한계점에 대해 다뤘습니다. 당시에 제시했던 문제점은 다음 두 가지입니다.

자기 자신의 타입을 사용하는 메소드를 선언할 수 없다.
정적 메소드를 추상 메소드로 선언할 수 없다.

덕 타이핑은 추상 메소드 선언을 기반으로 하고 있지 않기 때문에 이 두 가지 문제점을 회피할 수 있습니다. 인수 타입이나 출력 타입을 신경 쓰지 않기 때문에 자기 자신 타입이든 그 어떤 타입이든 사용할 수 있으며, 정적 메소드로도 덕 타이핑이 가능하기 때문에 추상 메소드의 기능을 수행할 수 있습니다. 이 점에서 타입클래스의 역할도 수행할 수 있다는 것을 알 수 있습니다.

동적 타입 언어에서 모든 타입은 호환되기 때문에 Variance의 영향 또한 받지 않습니다. 다만 이점은 오히려 단점이라고도 볼 수 있는 것이, Variance 규칙을 만족하지 않는 타입 캐스팅 또한 허용하기 때문에 주의를 기울여서 캐스팅해야 합니다.

이렇게 동적 타입 언어에서는 덕 타이핑 하나로 다형성이 전부 처리됩니다. 이 모든 게 가능한 이유는 동적 타입 언어가 타입 안정성을 가지고 있지 않기 때문입니다. 만약 잘못된 타입으로 덕 타이핑을 시도하면 런타임 에러로 받게 되죠. 인터페이스와 달리 명시적인 타입이 존재하지 않아 덕 타이핑으로 묶인 타입들을 추적하기 어렵다는 단점도 있습니다. 그렇기 때문에 프로젝트의 복잡도가 상승할수록 덕 타이핑은 더욱 조심히 사용해야 합니다.

재밌는 것은 C++ 템플릿으로도 덕 타이핑이 가능하다는 것입니다. 타입을 치환하는 방식으로 처리하는 C++ 템플릿 특성상 함수나 필드를 이름으로 호출하는 것이 가능합니다. 심지어 동적 타입 언어와 다르게 타입 안정성도 가져갈 수 있습니다. 이는 C++ 템플릿이 메타프로그래밍의 특성도 띠고 있기 때문에 가능한 것으로, 다른 언어로도 메타프로그래밍을 활용하면 덕 타이핑을 할 수 있습니다.

#리플렉션

동적 타입 언어는 리플렉션 기능이 항상 존재합니다. 동적 타입 언어 그 자체가 리플렉션을 이용하여 다형성 코드들을 실행하기 때문입니다. 동적 타입 언어의 합타입과 덕 타이핑에 대해서 고민해봅시다. 변수에 그 어떤 타입도 대입할 수 있다는 이야기는 최소한 대입된 타입이 무엇인지 런타임에도 알고 있다는 것입니다.

// Javascript 코드
let value;
// 50% 확률로 string이 대입되고 나머지 50% 확률로 object가 대입된다
if (Math.random() < 0.5) value = 'Mango';
else value = { score: 10 };

// 결과적으로 무슨 타입일지 컴파일 타임에 알 방법이 없다
// 그렇다는 것은 타입을 런타임에 저장된 타입을 출력하고 있다는 것이다
console.log(typeof value);

그렇기 때문에 리플렉션의 타입 성찰 조건을 갖추고 있다는 것을 알 수 있습니다. 필드나 메소드는 어떨까요?

// Javascript 코드
let value = {};
// 50% 확률로 name 필드에 대입한다
if (Math.random() < 0.5) value.name = 'Mango';

// 필드의 존재 여부 또한 런타임에 정해진다
// 그렇다는 것은 필드 존재 여부 또한 런타임에 저장되어있는 정보를 이용하는 것이다
console.log(value.name);

그렇습니다. 정적 타입 언어는 리플렉션 기능이 없어도 구현 가능하기 때문에 리플렉션 유무가 갈리지만, 동적 타입 언어는 각종 언어 기능의 작동 원리부터가 리플렉션이기 때문에 리플렉션이 거의 항상 제공됩니다. 각종 필드를 이름으로 찾는 것과 필드들을 순회하는 것은 정적 타입 언어에 비해 매우 쉽습니다.

// Javascript 코드
let human = {
  name: 'mango',
  getName() {
    return this.name;
  },
};

// human의 필드를 이름으로 찾는다. mango가 출력된다
console.log(human['name']);

// human의 필드와 메소드들을 순회한다
for (let prop in human) {
  // name과 getName이 출력된다
  console.log(prop);
}

#동적 타입 생성

동적 타입 언어는 런타임에 타입을 생성하고 수정할 수 있습니다. 모든 타입과 메소드들을 컴파일 타임에 알고 있을 필요가 없기 때문입니다. 이를 이용하면 클래스 타입을 특정 로직에 따라 생성하고 마음대로 메소드를 추가하고 조작할 수 있다는 것이죠.

// Javascript 코드
// 주어진 필드명들로 생성자 및 print 메소드들을 추가한 클래스 타입을 만드는 함수
function createClassWithPrinters(...fields) {
  // 필드들을 인수로 받는 클래스 타입 생성
  let clazz = class {
    constructor(...params) {
      for (let [index, field] of fields.entries()) {
        this[field] = params[index];
      }
    }
  };

  // 클래스에 print 메소드 추가하기
  for (let field of fields) {
    clazz.prototype[`print_${field}`] = function () {
      console.log(this[field]);
    };
  }

  return clazz;
}

// 런타임 타입 생성
const Human = createClassWithPrinters('name', 'age', 'role');

let mango = new Human('mango', 23, 'software engineer');
// 생성된 메소드 호출
mango.print_name();
mango.print_age();
mango.print_role();

사실 이 예시는 메타프로그래밍 편에서도 정적 타입 언어로 이미 보여드렸었습니다. 그렇습니다, 동적 타입 생성은 메타프로그래밍에 해당하는 기능입니다. 정적 타입 언어에서는 복잡한 매크로를 사용했었지만 동적 타입 언어에서는 이러한 타입 조작이 훨씬 더 쉽고 자연스럽게 이루어집니다.

매크로가 존재하지도 않아서 타입 생성이 어려운 언어들도 있다는 것을 생각해보면 이렇게 쉽게 타입 생성과 메소드 조작을 할 수 있다는 것은 확실한 장점입니다. 특히 Java나 C#에서 타입에 특정 로직을 따라 임의의 메소드들을 추가하는 것은 꽤나 어렵습니다.

물론 모든 곳에 리플렉션과 동적 타입 생성을 남용해서는 안 됩니다. 먼저 다형성을 우선으로 사용해서 재사용성을 높인 뒤, 다형성으로 해결되지 않는 보일러플레이트에 메타프로그래밍을 사용한다는 규칙은 동적 타입 언어에서도 유지됩니다. 아무리 동적 타입 언어의 메타프로그래밍이 쉽더라도, 일반적인 다형성을 통해 구현하는 방안이 더 직관적입니다.

하나 동적 타입 생성이 아쉬운 점이 있다면, 사실상 리플렉션과 동일한 방식으로 작동하기 때문에, 런타임에 요구되는 연산의 양이 더 늘어납니다. 그렇기 때문에 정적 타입 언어의 코드 생성, 타입 생성에 비해서 좀 더 느립니다.

#Typescript에 대해서

Typescript는 Javascript를 기반으로 타입 안정성을 추가하여 만들어진 정적 타입 언어입니다. Typescript는 일반적으로 Javascript으로 컴파일(트랜스파일)된 뒤 실행됩니다. 그렇기 때문에 동적 타입 언어이기에 가능한 것들의 대다수가 Typescript에서도 가능합니다.

합타입 측면에서는 애초에 타입 호환 문제를 겪고 있지 않기 때문에 자유롭게 가능하면서도 타입 안정성을 챙길 수 있고, 덕 타이핑의 경우 Javascript의 덕 타이핑에 비해 좀 더 제한되었지만 어느 정도 활용할 수 있으며, 리플렉션과 동적 타입 생성 기능 또한 계승됩니다.

그렇기 때문에 다형성 편에서 보여드렸던 언어 기능 표대로, Typescript는 Rust, Scala 못지않게 많은 기능들을 제공하고 있습니다. Javascript를 기반으로 만들어졌기 때문에 계승되는 단점은 동적 타입 언어 수준으로 성능이 낮다는 것입니다.

#결론

솔직하게 말씀드리자면 저는 동적 타입 언어를 그다지 선호하지 않습니다. 규모가 작은 프로젝트나 아키텍처의 복잡도가 높지 않거나 스크립팅 용도로 사용하기에는 꽤 나쁘지 않지만, 규모가 커지면 커질수록 유지보수성에 크게 타격을 입으며 버그는 잡기 어려워지고 새 인원이 프로젝트에 참여했을 때 아키텍처를 이해하는데 들어가는 시간이 늘어난다고 생각합니다.

그러나 현대적인 프로그래밍 언어가 아닌, C++, C#, Java와 같이 언어 기능이 약한 언어들보다는 어느 정도 확실한 강점이 있을 것 같습니다. 특히 메타프로그래밍 측면에서 상당히 강력하고 진입장벽이 낮다는 점을 생각해보면, 이러한 언어들로 만들어진 프레임워크들이 어째서 많은지 이해가 가게 됩니다. 이러한 관점들을 나누기 위해서 이 글을 작성하게 되었습니다.

이번 글에서 Javascript가 등장하면서 더 이상 9가지 언어라는 컨셉을 유지할 수 없게 되었습니다. 그렇다고 시리즈 제목을 수정하기도 애매하기 때문에 일단은 그대로 유지했습니다. 사실 다음 편은 다양한 프로그래밍 언어들이 어떤 방식으로 비동기 처리 기능을 제공하는지를 다루고자 하는데, 이 과정에서 여러 가지 프로그래밍 언어들을 소개할 예정이기 때문에 이미 9가지 언어라는 컨셉은 불가능했을지도 모르겠습니다.

1: 사실 Variance가 아닌 Rust의 Coercion을 사용했다고 하는 것이 조금 더 정확한 표현입니다. Rust의 dyn Any와 같은 dyn 레퍼런스 타입은 메모리 주소 2개로 이루어져 있기 때문에 dyn 레퍼런스 타입과 메모리 주소 1개짜리인 struct 레퍼런스 타입은 호환되지 않습니다. 그렇기 때문에 C#의 Boxing처럼 Rust가 Coercion을 통해 변환 코드를 몰래 삽입한 것에 가깝습니다. Coercion 적용 규칙은 여전히 Variance 규칙을 기반으로 하고 있기 때문에 Variance라고 표현했습니다.

입사 첫날에 36시간 점검 경험하기

Fri, 06 Jan 2023 00:00:00 GMT

이 글과 관련된 다른 글 보기

쿠키런: 킹덤 런칭 회고 - DevOps 관점에서 본 쿠키런: 킹덤 런칭 회고
CockroachDB in Production - CockroachDB에 대한 소개와 킹덤에서 CockroachDB를 사용한 이유 설명
쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기 - 엔지니어 관점 기록한 개괄적인 장애 대응 과정과 회고
CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기 - CockroachDB의 소스코드를 참고하며 바이너리 파일로부터 데이터를 복구한 이야기
입사 첫날에 36시간 점검 경험하기 - 신규입사자의 관점에서 서술된 장애 대응 기록
쿠키런: 킹덤 AWS AZ 장애 아웃라인 - AWS AZ 장애로부터 서비스를 복구한 이야기
쿠키런: 킹덤 길드 업데이트 이후 서비스 이슈 되돌아보기 - 쿠키런: 킹덤에 길드 기능이 추가된 이후 발생한 서비스 이슈 회고

#들어가기에 앞서

안녕하세요, 저는 진저랩 데이터플랫폼셀에 재직 중인 2년 차 소프트웨어 엔지니어 김도현입니다.

데브시스터즈에 처음으로 출근한 날이 2021년 1월 25일인데, 글을 쓰는 지금 벌써 2년 가까운 시간이 지났다는 것이 아직도 실감이 잘 나지 않습니다. 오늘은, 입사 첫날에 36시간 점검을 경험한 이야기를 전해드리고자 합니다.

근 2년 동안 데브시스터즈에서 많은 일들이 있었지만, 제게 가장 강렬했던 기억은 역시 입사 첫날에 마주했던 36시간 점검입니다. 게임을 플레이하는 유저에서 하루 만에 유저 경험을 고려해야 하는 입사 1일 차 신입 엔지니어가 되었고, 또 그 점검의 규모 또한 상당히 컸습니다. 이런 특별한 상황이었다 보니 아직도 제 기억 속에 강렬하게 남아있습니다.

저 역시 입사 하루 전까지만 하더라도 일반 유저의 입장에서 게임을 즐기고 있었기 때문에, 아무래도 제 관점이 그 이전부터 팀 내부에 계셨던 엔지니어 분들의 관점보다는 친숙하게 느껴지실 것입니다. 이 글을 통해 당시의 제가 보았던 상황과 느꼈던 감정을 여러분께 공유 드림으로써 기술적인 맥락 없이도 점검 타임라인에 대해 보다 쉽게 이해하실 수 있었으면 좋겠습니다.

#첫 출근: 점검 8시간 전

2021년 1월 25일, 데브시스터즈에 기념비적인 첫 출근을 했습니다. 신규입사자를 대상으로 진행해주신 간단한 OT를 듣고, 사무실로 이동하여 데이터플랫폼셀 팀원분들과 인사를 나눴습니다. 당시 팀에는 저를 제외하고 3분이 있으셨는데(지금은 훨씬 더 큰 팀이 되었습니다), 슬프게도 팀원분들 모두가 런칭 이후 과도한 업무에 시달리고 계셨습니다.

2021년 1월 21일에 쿠키런: 킹덤이 출시되었습니다.

입사 4일 전인 1월 21일에 출시된 쿠키런: 킹덤은 역대급 이용자 수를 기록하며 많은 유저분의 관심과 사랑을 받고 있었고, 그만큼 큰 규모의 로그를 만들어내고 있었습니다. 킹덤은 제가 상상조차 해보지 못했던 크기의 로그를 매초 쏟아내고 있었고, 그로 인해 로그를 수집 및 적재하는 파이프라인의 부하가 커지고 있었습니다. 당연히 시급히 해결해야 할 문제들이 생겨났고, 팀원분들은 거의 밤을 새우다시피 파이프라인 관련 대응 작업을 하고 계셨습니다.

하지만 그렇게 바쁜 와중에도 멘토님을 비롯한 팀원분들 모두 온보딩 절차 및 가이드들을 잘 설명해주시고 전달해주셔서 긴장감이 많이 덜해졌습니다. 당시에 팀장님께서 우스갯소리로 “런칭 당일에 오셨어야 더 재밌는 일들이 많았을 텐데”라는 말씀을 해주셨는데, 정말로 한 달 정도 더 일찍 입사했다면 어땠을까 하는 생각을 해봤습니다. 게임 런칭이 그리 자주 있는 일도 아닌 데다가, 비록 아무것도 알지 못하더라도 런칭 과정을 지켜보면서 많이 성장할 수 있지 않았을까 하는 생각이었습니다.

그리고 그날 오후, 그 생각을 기억 속에서 날려버릴 일이 일어났습니다.

#오후 4시 52분: 점검 시작

퇴근 시간을 1시간 정도 남겨두고 온보딩 가이드를 열심히 따라가던 중, 킹덤을 플레이하던 친구로부터 메시지를 하나 받았습니다.

아직도 이 메시지를 받을 때의 기억이 생생합니다.

뭔가 싶어서 킹덤을 켜보니 실제로 접속이 되지 않았습니다. 사내 와이파이에 문제가 있나 싶어 셀룰러 모드로 다시 접속해보았지만, 똑같이 접속이 불가능하다는 팝업이 보였습니다. 싸한 느낌이 들어 팝업에서 눈을 떼니, 사색이 되어 움직이시는 그룹 분들과 모니터 속에서 시작되는 무수히 많은 화상회의가 보였습니다.

명백하게 문제로 보이는 상황에 저 역시 몹시 당황했습니다. 무슨 일이 벌어진 건가 여쭤보고 싶었지만, 당시 팀원분들이 다른 회의로 인해 자리를 비우신 상황이라 바로 맥락을 여쭤볼 순 없었습니다. 심상치 않은 분위기 속에서 당황한 채로 주변에서 들리는 이야기를 듣던 중, ‘데이터베이스’라는 단어가 들려왔습니다. 자연스럽게 ‘데이터베이스에 문제가 생겼나?’라는 의문이 머릿속에서 떠올랐고, 순간 오만가지 생각이 다 들기 시작했습니다.

점검에 대한 자세한 기술적 내용은 지난 NDC22에서 확인하실 수 있습니다.

당시 점검의 이유를 요약하자면, 데이터는 정상적으로 남아있으나 데이터베이스 클러스터에서 데이터를 인식할 수 없는 문제였습니다. 더욱 자세한 기술적 설명은 위 NDC 프레젠테이션과 데브시스터즈 기술 블로그의 이 글에서 확인하실 수 있습니다.

하지만 당시에는 이슈에 대한 자세한 상황을 몰랐고, 불안감은 잔뜩 커져만 갔습니다. 데이터가 날아갔다면 원본을 복구할 수 있는 것인지, 서버 롤백을 하게 될지, 만약 롤백을 한다면 후속 대응은 어떻게 진행될지 등등의 생각이 꼬리에 꼬리를 물며 떠올랐습니다. 저는 이제 막 신입 엔지니어로 입사한 데다가 아직 팀의 맥락은커녕 회사의 OT도 다 받지 못했던 상황이었고, 게다가 점검의 제대로 된 원인도 모르는 상황에서 혼자서 무언가를 할 수는 없었습니다. 그렇다 보니 팀원분들이 오실 때까지는 긴장한 채 주변의 상황을 지켜봤었습니다.

위의 NDC 프레젠테이션과 기술 블로그 게시글에서도 나온 내용이지만, 점검 시작 후 팀에서는 AWS 및 CockroachDB 엔지니어와 기술 지원을 위한 화상회의를 시작하였습니다. 많은 사람이 한꺼번에 대응하다 보니 회의는 스피커폰으로 진행되었는데, 전망이 좋지 않아 보이는 이야기들이 많이 들렸습니다. AWS 측에서는 마땅히 대응 방안을 제공해주지 못했다는 말과, CockroachDB 측에서는 롤백(백섭)이 최선의 방법일 것이라고 답변해주었다는 얘기도 들렸습니다.

NDC 2022 - 쿠키런: 킹덤, 총 56시간의 긴급 점검 회고 中

#1일차 종료: 점검 1시간 30분 경과

그렇게 절망적인 이야기들을 듣던 중 자리를 비우셨던 팀원분들이 돌아오셨습니다. 회의 도중에 대응을 진행하시다 자리로 돌아오셨다고 말씀해주셨는데, 아침에 뵀던 것보다 더욱 수척해지신 모습이셨습니다. 혹여나 제가 자리에 남는다면 조금이나마 도와드릴 수 있는 일이 있지 않을까 하는 마음이었지만, 팀원분들은 강력하게 저를 퇴근길에 올려보내셨습니다.

걱정 반 불안 반의 마음으로 집에 가는 와중에도 몇 번씩 킹덤을 실행해봤지만, 여전히 점검 안내 팝업이 저를 반겨주었습니다. 집에 도착하고서도, 저녁을 먹고서도, 씻고 잘 준비를 하면서도 계속해서 킹덤을 실행해봤지만, 점검은 계속되고 있었고 제 불안감도 커져만 갔습니다.

결국 오늘 막 입사한 제가 딱히 집에서 할 수 있는 일도 없었고(재택근무를 위한 노트북 VPN 설정조차 끝내지 못했었습니다), 깨어있다면 계속해서 불안한 생각만 들 것 같았기에 이른 잠자리에 들기로 하였습니다.

#두 번째 출근: 점검 16시간 경과

1월 26일, 잠을 설치고 새벽에 눈을 떴습니다. 일어나자마자 킹덤을 실행해봤으나 야속한 점검 팝업만 보였습니다.

새벽까지 킹덤 오픈을 기다리던 친구도 있었습니다.

출근 준비를 마치고 회사에 도착하니 멘토님이 어제와 똑같은 옷차림으로 퇴근할 때 뵌 모습과 똑같이 자리에 앉아계셨습니다. 밤새 이슈 대응을 진행하고 계셨다고 말씀해주셨고, 멘토님뿐만 아니라 저희 팀을 포함한 전사의 수많은 분이 대응을 위해 밤을 새우신 상태였습니다.

멘토님께서 간단하게 상황 정리를 해주셔서 현재 점검의 원인에 대한 자세한 설명과 진행 중인 대응의 기조를 들을 수 있었습니다. 롤백(백섭)을 하는 것이 단순하게 타협해볼 수 있는 선택이긴 하지만, 런칭하자마자 많은 분께서 게임을 즐겨주고 계셨던 상황에서 롤백으로 인한 데이터 손실이 몇 시간, 몇 분이라도 발생한다면 많은 유저분이 상실감을 느끼실 것을 우려하고 계셨습니다. 그 때문에 완벽한 복구를 계획하고 있다고 하셨고, 이를 위해 데이터베이스 클러스터 간 데이터 이동 작업을 밤새 준비하셨다고 알려주셨습니다.

덕분에 회사 차원에서 어떤 기조로 현 상황에 대처하고 있는지 알게 되어 무지에 대한 불안감은 어느 정도 줄어들었습니다. 다만 여전히 점검이 계속 길어지는 것에 대한 불안은 남아있었는데, 팀장님의 배려로 실제로 대응을 진행하시는 것을 가까이서 지켜볼 수 있었습니다.

처음으로 봤던 작업은 CockroachDB의 스토리지 레이어에서 사용하는 sst 파일을 csv 파일로 변환하는 과정이었습니다. Spark를 통해서 약 7TB나 되는 분량의 데이터를 병합하는 작업이었는데, 대략 11,200코어의 CPU와 89,600GB의 메모리를 가지는 클러스터임에도 불구하고 워낙에 데이터의 규모가 크다 보니 작업이 오래 걸릴 수밖에 없었습니다. 시간은 시간대로 흘러가고 Spark job 프로그레스 바는 너무나도 느리게 차오르다 보니, 계속 마음속으로 제발 잘 좀 옮겨지라고 기도하고 있었습니다.

다행히도 CSV 파일로의 변환은 잘 마무리되었고, 이어서 새로운 CockroachDB 클러스터에 변환된 데이터를 옮겨주기 시작했습니다. 하지만 추가로 한 가지 생겼던 문제가 더 생겼었는데, 바로 EC2 인스턴스 부족이었습니다. 데이터 전처리를 위해서 Spark 노드를 최대한 많이 띄웠었는데, AWS 도쿄 리전의 가용 가능한 모든 R계열 인스턴스를 끌어다 사용하다 보니 인스턴스가 부족해서 새 노드를 띄울 수 없었습니다.

결국 적재 및 분석에 사용하던 다른 인스턴스들까지 끌어와 데이터 이주 작업에 동원되었고, 오후 5시 반쯤이 되어서 데이터 이주가 모두 완료되었습니다. 다만 데이터베이스 클러스터 간의 데이터 정합성 역시 확인해야 했었기에, 최종적으로 오후 8시 정도가 되어서야 서비스 오픈을 위한 데이터베이스 준비가 완료되었습니다. 이때 작업을 지켜보면서도 시간이 이렇게 많이 흐른 줄 몰랐는데, 어느새 창밖이 어두워진 것을 보고 놀랐던 기억이 납니다.

#첫 야근: 점검 27시간 경과

그리고 또다시 퇴근 시간이 되었습니다. 팀원분들은 오늘도 저를 집으로 보내려 하셨지만, 무지에서 오는 불안감도 있었고, 남아서 도와드릴 수 있는 일들이 하나쯤은 있지 않을까 싶었기에 잠깐의 논의 끝에 회사에 남아 자잘한 작업을 더 도와드리기로 하였습니다.

오후 8시부터는 실제 유저 중 일부를 샘플링하여 데이터 정합성을 다시 한번 확인하였고, 이후 오후 10시경 전사 대상 내부 테스트가 시작되었습니다. 저도 아직 퇴근하지 않아서 내부 테스트에 참여했었는데, 다행히도 점검 시작 전까지의 제 킹덤 계정이 잘 보존된 것을 확인했습니다. 정말 안도의 한숨을 푹 쉬었던 기억이 아직도 생생합니다.

내부 테스트가 진행되는 동안 잠시 숨을 돌릴 틈이 있었고, 이 기회에 입사 첫날에 뵙지 못한 데이터 직군의 다른 분들과 안면을 트는 등 잠깐이지만 평범한(이미 오후 10시가 넘은 시점에서 사실 평범하지 않긴 했습니다) 온보딩을 진행했었습니다 🙃

테스트가 끝난 후, 오후 11시 30분경 점검 해제를 대비하여 데이터플랫폼의 로깅 인프라 모니터링을 준비하기로 하였습니다. 저는 Kafka와 Elastic Stack 메트릭을 모니터링하며 저희의 데이터플랫폼에 이상이 없는지 지켜보았습니다.

사실 자발적인 야근이긴 했습니다.

그리고 대망의 오후 11시 37분, 점검 시작 후 약 31시간 만에 서비스가 오픈되었습니다.

대략 1시간 정도 모니터링을 진행하였고, 정말 다행히도 Kafka와 Elastic Stack 모두 부하가 조금 걸리긴 했으나 서서히 줄어들고 마침내 다시 정상 범주 안으로 복귀하는 것을 확인하였습니다. 데이터플랫폼셀 뿐만 아니라 전사적으로도 어느 정도 복구가 완료된 것 같아 마음이 조금 놓였고, 새벽 1시경 모니터링을 마치고 퇴근하게 되었습니다.

다만 제가 퇴근하고 잠든 사이 점검이 한 차례 더 있었다는 이야기를 일어난 후에 듣게 되었습니다 😢

#점검 이후: 후일담

서버가 오픈된 새벽 1시에 느꼈던 기분은 안도감과 경외감이었습니다. 팀뿐만 아니라 그룹 전체가 나서서 완벽한 사용자 경험을 복구하기 위해서 최선의 노력을 다하였고, 비록 시간은 오래 걸렸지만 CockroachDB 엔지니어도 불가능하다고 말했던 “온전한 유저 경험”을 되살릴 수 있었다는 점이 너무나도 경이로웠습니다.

대응과 복구를 지켜보고 또 맥락을 이해하면서 팀에서 내렸던 결정 및 선택의 이유 역시 알 수 있었고, 데이터플랫폼의 인프라를 이렇게도 활용할 수 있구나라는 생각이 들었습니다. CockroachDB 클러스터의 데이터를 살리는 것과 로그 기반으로 데이터의 정합성을 확인하는 것 모두 데이터플랫폼셀에서 Spark를 사용해 모든 로그를 적재하지 않고 있었더라면 불가능했을 것입니다.

마지막으로, 외부에서 점검을 구경하던 것과 내부에서 점검을 마주했을 때의 느낌은 완전히 다르다는 것을 알았습니다. 많은 분이 치열하게 서비스 재개를 위해 노력하셨고, 대응이라는 것이 얼마나 바쁜 작업의 연속인지를 알게 되었습니다. 저 역시 이러한 과정의 한 부분을 맡을 수 있도록 더욱 노력해야겠다는 생각도 들었습니다.

이 글에서는 간략하게 다루었지만, 더욱 자세한 대응에 관한 기록과 이야기는 아래의 글에서 더 자세하게 확인하실 수 있습니다.

특히, 36시간 점검 당시 비트 레벨까지 내려가서 CockroachDB를 해킹한 CTO님의 이야기도 조만간 공개될 예정이니, 많은 관심을 부탁드리겠습니다.

읽어주셔서 감사합니다.

9가지 프로그래밍 언어로 배우는 개념: 3편 - 메타프로그래밍

Tue, 03 Jan 2023 00:00:00 GMT

#프로그래밍 언어 시리즈

9가지 프로그래밍 언어로 배우는 개념: 1편 - 타입 이론
9가지 프로그래밍 언어로 배우는 개념: 2편 - 다형성
9가지 프로그래밍 언어로 배우는 개념: 3편 - 메타프로그래밍
9가지 프로그래밍 언어로 배우는 개념: 4편 - 하이 레벨 언어와 동적 타입 언어
9가지 프로그래밍 언어로 배우는 개념: 5편 - 동시성 프로그래밍

#서론

안녕하세요, 킹덤 서버 소프트웨어 엔지니어 지민규입니다. 다형성을 아무리 잘 쓰더라도 메타프로그래밍 없이는 최소한의 보일러플레이트가 생깁니다. 인터페이스/타입클래스를 통해 다형성을 이루더라도 최소한 해당 인터페이스/타입클래스가 요구하는 함수들을 구현해야하며 제네릭을 사용하더라도 타입을 선언한 이상 최소한 해당 타입을 생성하는 코드를 구현해야합니다. 어떤 면에서는 이렇게 매번 추가적인 보일러플레이트를 구현하는 것은 마땅히 해야할 일로 받아들일 수도 있습니다. 최대한의 확장성을 가질 수 있는 코드는 아무런 암묵적 처리 없이 우리가 모든 것을 직접 수동적으로 조절할 수 있는 코드겠죠.

하지만 저는 확장성이라는 것은 주관적이라고 생각합니다. 모든 프로젝트와 도메인은 개별적인 요구 사항이 있고 요구 사항이 중간에 변경되어 확장성을 요구하는 상황이 오더라도 요구 사항이 변하는 방향은 정해져있다는 것입니다. 그렇다면 확장성이라는 것도 프로젝트와 도메인에 따라 의미가 있는 확장성과 의미가 없는 확장성이 나눠질 수 있습니다. **메타프로그래밍(Metaprogramming)**은 이러한 의미 없는 확장성을 포기하고 보일러플레이트 코드를 줄일 수 있을 때 가장 유용합니다. 코드를 경직화하는 대신 반복적인 코드를 없애는 것입니다. 비용에 비해 이러한 이점이 너무나 강력해서 메타프로그래밍을 활용하지 않는 프레임워크는 찾기 어려울 정도입니다.

메타프로그래밍은 언제나 다형성을 보조하는 기능으로서만 사용해야합니다. 메타프로그래밍 코드는 더 복잡할 뿐만이 아니라 이러한 확장성 비용도 있고 성능 혹은 컴파일 타임의 비용이 함께 다가옵니다. 그러므로 메타프로그래밍은 비용보다 이점이 더 클 때에만 사용해야합니다. 이번 포스트는 메타프로그래밍을 두려워하지 않고 필요에 따라 사용할 수 있도록 다양한 메타프로그래밍 기법들을 소개합니다.

#타입 성찰

하위 타입에서 상위 타입으로 캐스팅하는 것은 업캐스팅이라고 부릅니다. 그리고 상위 타입에서 하위 타입으로 캐스팅하는 것은 다운캐스팅이라고 부릅니다. C++에서는 다운캐스팅을 다음과 같이 합니다.

// C++ 코드
// 상위 타입 parent
class Parent {};

// 하위 타입 Child, Parent를 상속받음
class Child : public Parent {};

// Child 타입을 Parent 타입으로 업캐스팅한다. 그냥 대입하면 끝.
Parent* parent = new Child();

// Parent 타입을 Child 타입으로 다운캐스팅한다. dynamic_cast를 사용해야한다.
Child* child = dynamic_cast<Child*>(parent);

다운캐스팅은 업캐스팅과 다르게 dynamic_cast라는 특별한 키워드를 사용합니다. 이는 다운캐스트가 유효하지 않을 수도 있기 때문입니다. parent에 담긴 타입이 Child가 아닐경우 dynamic_cast는 null을 내립니다.

// C++ 코드
class Parent {};

// 2개의 하위 타입
class ChildA : public Parent {}
class ChildB : public Parent {}

// ChildA 타입을 업캐스팅한다.
Parent* parent = new ChildA();

// (ChildA가 있는) Parent 타입을 ChildB로 다운캐스팅한다.
// ChildA 타입은 ChildB 타입이 아니므로 null이 내려온다.
ChildB* child = dynamic_cast<ChildB*>(parent);

달리 말하자면 ChildA 타입이 Parent 타입으로 업캐스팅 되었어도 본래의 타입을 기억하고 있다는 것입니다. 그리고 중요한 점은 이것이 컴파일 타임이 아닌 런타임에 존재하는 정보라는 것입니다. 이를 **런타임 타입 정보(Run-time type information, RTTI)**라고 합니다. C++에서 런타임 타입 정보는 컴파일러 옵션으로 끌 수 있으며 끄게되면 더 이상 dynamic_cast를 사용할 수 없게 되죠. 더 높은 유연성을 위해 직접 타입 정보 시스템을 구현하는 몇몇 프레임워크는 런타임 타입 정보를 끄고 컴파일하기도 합니다.

C++에서 런타임 타입 정보는 타입으로부터 typeid 키워드를 이용해 type_info 클래스도 가져올 수 있게 해줍니다.

// C++ 코드
// type_info의 대략적인 정의
class type_info {
public:
  // 복사 생성 불가
  type_info(const type_info& rhs) = delete;

  // 타입의 해쉬
  size_t hash_code() const;

  // 타입간의 비교 연산자
  bool operator==(const type_info& rhs) const;

  // 복사 불가
  type_info& operator=(const type_info& rhs) = delete;

  // 이름을 가져오는 함수, 컴파일러마다 결과가 다름
  const char* name() const;
};

// A 클래스 정의
class A {};

// A 클래스 생성
A a = new A();

// a의 type_info 가져오기
type_info info = typeid(a);

이러한 type_info 클래스를 이용해서 만들어진 type_index 클래스를 이용하면 타입을 unordered_map(해쉬 테이블, 딕셔너리의 C++ 버전)의 키 값으로 사용할 수 있습니다. 이를 이용하면 C++의 타입들에 추가적인 정보들을 담을 수 있습니다.

// C++ 코드
// 각 타입들을 생성한 횟수
unordered_map<type_index, int> call_count;

// 타입의 인스턴스를 생성하는 함수, 타입별로 생성 횟수를 센다.
template<typename T>
T create() {
  creation_count[type_index(typeid(T))]++;
  return T();
}

Java를 비롯한 다른 JVM 계열 언어들에도 이러한 타입 정보를 가져올 수 있습니다. Class<T>가 이에 해당합니다. Java의 모든 오브젝트는 getClass() 메소드로 Class<T>를 가지고 있습니다. 다만 다형성 편에서 다뤄졌듯, Java 제네릭의 한계로 인해 위 C++의 템플릿처럼 제네릭한 생성 함수를 만들 수 없기에 제네릭 없이 Object로 받은 인수에 getClass()를 해서 횟수를 세어보겠습니다.

// Java 코드
// Class는 Invariant하기 때문에 `Class<?>`로 키타입을 설정해야한다.
// 여기서 ?는 타입이 일관적이지 않음을 의미한다.
HashMap<Class<?>, Integer> call_count = new HashMap<>();

// 인수로 받은 object를 타입별로 세는 함수
void increaseCallCount(Object object) {
  Integer integer = call_count.getOrDefault(object.getClass(), 0);
  call_count.put(object.getClass(), integer + 1);
}

이렇게 타입에 대한 정보를 가져오는 기능들을 **타입 성찰(Type Introspection)**이라고 부릅니다. 언어마다 타입 성찰은 개별적으로 구현되어있으며 어떤 면에서는 언어들이 가지는 가장 구별되는 특징중 하나라고 볼 수도 있습니다.

타입 정보를 이렇게만 사용하는 것은 사실 좀 심심하긴 합니다. 다행히도, C++와 다르게, Java의 타입 정보는 좀 더 많은 정보를 가지고 있습니다.

#리플렉션

Java의 Class<T>의 정의를 확인해봅시다.

// Java 코드
// Class<T>의 대략적인 정의
public final class Class<T> {
  // 타입 이름을 가져오는 메소드
  public String getTypeName() {
    /* ... */
  }

  // 필드 정보들을 가져오는 메소드
  public Field[] getFields() {
    /* ... */
  }

  // 메소드 정보들을 가져오는 메소드
  public Method[] getDeclaredMethods() {
    /* ... */
  }

  /* ... */
}

많은 메소드가 존재하지만 대표적인 메소드들만 추려낸 정의인데요, Java의 Class<T>에는 단순히 타입 이름뿐만이 아니라 클래스 내 메소드들과 필드들 또한 가져올 수 있습니다. 각각의 필드와 메소드 정보에는 타입, 이름등의 정보가 담겨져 있지요. 이러한 타입 정보들은 일반적으로는 컴파일할 때 모두 최적화되어 런타임에서는 접근할 수 없는 경우가 많지만, JVM의 경우 타입에 대한 정보를 남겨두어 런타임에서도 접근할 수 있게 해줍니다. 이렇게 컴파일 타임에만 존재하던 정보를 런타임에서도 제공해주는 것을 **리플렉션(Reflection)**이라고 합니다.

리플렉션을 활용하면 Object를 필드에 따라 JSON으로 직렬화 할 수 있는 함수도 만들 수 있습니다.

// Java 코드
// Json으로 직렬화하는 정말 대략적인 함수
public static String jsonify(Object object) {
  Class<?> clazz = object.getClass();
  Field[] fields = clazz.getFields();
  StringBuilder stringBuilder = new StringBuilder();

  stringBuilder.append("{\n");
  for (int i = 0; i < fields.length; i++) {
    Field field = fields[i];
    stringBuilder.append("  \"");
    stringBuilder.append(field.getName());
    stringBuilder.append("\": ");

    // 필드가 Integer 타입일 때
    if (field.getType().equals(Integer.class))  {
      stringBuilder.append(field.get(object));

    // 필드가 String 타입일 때
    } else if (field.getType().equals(String.class)) {
      stringBuilder.append("\"");
      stringBuilder.append(field.get(object));
      stringBuilder.append("\"");
    }
    // 마지막 필드가 아닐 때는 콤마 달기
    if (i != fields.length - 1) {
      stringBuilder.append(',');
    }
    stringBuilder.append('\n');
  }
  stringBuilder.append("}");

  return stringBuilder.toString();
}

// Item 클래스 정의
public class Item {
  public String itemTag;
  public int amount;
}

// Item 생성
Item item = new Item();
item.tag = "Rare";
item.amount = 5;

// Item json화
String result = jsonify(item);
/* result에는 다음 데이터가 담겨진다
{
  "tag": "Rare",
  "amount": 5
}
*/

기존 프로그램에서는 타입과 필드를 추가하면 웬만해서는, 타입과 필드를 활용해야만 프로그램의 동작이 달라집니다. 메타프로그래밍을 사용하면 타입과 필드를 추가하는 것 만으로도 프로그램이 다른 동작을 하게 됩니다. 반복적으로 작성해야하는 보일러플레이트 “활용” 코드를 작성할 필요 없이 최소한의 코드 작업으로도 새로운 기능을 추가할 수 있습니다.

다만 메타프로그래밍은 언제나 단점이 존재합니다. 리플렉션의 경우 보일러플레이트 코드를 작성하는 것에 비해 런타임에 해야할 작업이 더 많기 때문에 성능이 더 떨어지고, 타입 정보가 프로그램에 추가되어야하기 때문에 프로그램의 크기가 더 커집니다. 무엇보다 런타임에서 처리가 이루어지기 때문에 오류가 있어도 컴파일 타임에 잡을 수 없다는 것입니다.

가끔은 타입 정보만으로는 원하는 리플렉션 코드를 구현하기엔 부족할 때가 있는데요, 그런 경우에는 **어노테이션(Annotation)**이라는 기능으로 좀 더 많은 정보를 주어 좀 더 많은 일을 할 수 있습니다.

#어노테이션

Class<T>를 소개할 때 생략한 메소드가 하나 있습니다.

// Java 코드
// Class<T>의 대략적인 정의
public final class Class<T> {
  /* ... */

  // 어노테이션 정보들을 가져오는 메소드
  public Annotation[] getAnnotations() {
    /* ... */
  }

  /* ... */
}

어노테이션은 타입, 필드 등에 추가적인 정보들을 추가해서 메타프로그래밍을 좀 더 조절 할 수 있게 해줍니다. 엄연히 말하면 어노테이션은 리플렉션만을 위한 기능은 아닙니다. 어노테이션을 통해서 컴파일러의 동작을 바꾸거나 하는 경우도 있는데요, 이번 포스트에서는 어노테이션을 메타프로그래밍을 중심으로 다뤄볼 것 입니다.

Java에서 직접 어노테이션을 선언하는 방법을 확인해봅시다.

// Java 코드
enum CasingType { camelCase, snake_case }

@Target(ElementType.Field)
@Rentention(RententionPolicy.RUNTIME)
public @interface Casing {
  CasingType casingType default CasingType.camelCase;
}

가장 먼저 눈에 띄는 것은 @Target(ElementType.Field)입니다. 이는 해당 어노테이션이 어디에 붙을 수 있는지를 정합니다. 여기에서는 필드에 붙을 수 있음을 지정하고 있습니다. 두번째는 @Rentention(RententionPolicy.RUNTIME)으로, 해당 어노테이션 정보가 언제까지 존재하는지를 표시하는데, RententionPolicy에는 총 3가지 값이 있습니다. SOURCE는 해당 어노테이션이 프로그램 바이너리로 들어가지 않아 컴파일 타임에만 머문다는 것을 의미하고 CLASS는 프로그램 바이너리로 들어가지만 리플렉션으로 제공되지 않는다는 것을 의미하며, RUNTIME은 리플렉션으로 제공된다는 것을 의미합니다.

이렇게 정의한 어노테이션을 다음과 같이 사용할 수 있습니다.

//Java 코드
public class Item {
  @Casing(CasingType.snake_case)
  public String itemTag;
  public int amount;
}

이러한 어노테이션을 활용하여 리플렉션 코드에서 조회를 하면 좀 더 다양한 상황에 맞추어 사용할 수 있습니다. Typescript, Go에도 JVM의 어노테이션에 해당하는 기능은 일반적으로 지원해주고 있습니다.

// JVM 계열 언어인 Kotlin, Scala는 생략

// C# 코드
// attribute라고 부른다.
enum ECasingType { CamelCase, snake_case }
public class CasingTypeAttribute : System.Attribute {
  public ECasingType casingType;
}

// Typescript 코드
// Decorator라고 부른다. 2022년 7월 기준 experimental
type CasingType = "camelCase" | "snake_case"
function casing(casingType: CasingType) {
  return Reflect.metadata(Symbol("casingType"), casingType);
}

// Go 코드
// Struct tag라고 부른다.
type Item struct {
  itemTag string `casing:"snake_case"`
  amount int
}

Go의 struct tag에 대해서 유의해야할 것은 리플렉션으로 넘길 수 있는 데이터는 단순한 String 하나뿐이라는 것입니다. 따라서 casing:"snake_case"와 같은 형태로 넘기는 것이 컨벤션으로 잡혀 있습니다. 또한 좀 더 범용적으로 사용할 수 있는 어노테이션과 다르게, struct tag는 필드에만 달 수 있습니다.

#템플릿 메타프로그래밍

런타임에만 메타프로그래밍할 수 있는 것이 아닙니다. 메타프로그래밍은 코드 그 자체를 이용하여 프로그래밍하는 만큼, 컴파일 타임에도 코드를 이용하여 메타프로그래밍을 할 수 있습니다.

다형성 편에서 C++의 템플릿에 대해 간략하게 소개드렸습니다. C++의 템플릿은 제네릭을 구현하는 것 뿐만 아니라 메타프로그래밍 또한 가능합니다. 이는 C++의 템플릿은 컴파일타임에 지정된 타입으로 코드를 틀로 찍어내듯 복사하기 때문입니다.

다형성 편에서 이미 템플릿을 통해 필드 접근을 일반화시킬 수 있다는 것을 보여드렸습니다.

// C++ 코드
template<typename T>
void printValue(T t) {
  cout << t.value << endl;
}

// A.value는 int 타입
struct A {
  int value;
};

// B.value는 float 타입
struct B {
  float value;
};

A a = { 5 };
B b = { 10.5f };
printValue(a);
printValue(b);

이때 타입 T가 value를 요구한다는 것을 표시하지 않아도 됩니다.. C++ 템플릿에서는 일단 지정된 타입을 대입한 코드를 생성하고 이후에 해당 코드를 컴파일하기 때문에 만약 value 필드가 없는 타입을 넘긴다면 생성된 코드에 대한 컴파일 에러 메시지가 나타납니다.

// C++ 코드
struct C {};

C c;
printValue(c);

// C++ 컴파일러(clang++) 에러 메시지
error: no member named 'value' in 'C'
                cout << t.value << endl;
                        ~ ^

이는 곧 컴파일러가 템플릿 코드를 생성할 때 제공된 타입 T의 필드들과 그 이름, 그리고 필드들의 타입을 알고 있고 그러한 정보들을 이용해 컴파일이 성공하는지 확인하며 코드를 생성한다는 것을 알 수 있습니다.

이때 필드를 이름으로 조회하는 것을 일반화 시킬 수 있다는 점에서 리플렉션과 유사합니다. 차이점은 리플렉션은 런타임에서 타입 정보를 가져와 처리하고 템플릿은 컴파일 타임에 타입 정보를 가져와 코드를 생성합니다. 그렇기 때문에 유효하지 않은 타입을 넘겼을 때 에러가 컴파일 타임에 발생하기 때문에 에러를 좀 더 빠르게 발견하고 수정할 수 있습니다.

C++의 템플릿을 이용하면 좀 더 특이한 기능도 구현할 수 있습니다. 예를들어 std::is_base_of는 템플릿을 이용해 특정 타입이 다른 타입의 상위 타입인지 알려줍니다.

// C++ 코드
class A {};

// B의 상위 타입은 A다
class B : A {};

// result는 true
bool result = std::is_base_of<A, B>::value;

다른 언어에서는 이러한 기능은 컴파일러에 내장된 기능으로 제공해주는 경우가 많습니다. 어떻게 C++은 이것을 어떻게 템플릿만으로 구현할 수 있을까요? 해답은 **템플릿 특별화(Template Specialization)**에 있습니다. 먼저 특별화가 무엇인지 알아보아야 합니다.

// C++ 코드
// 구현 1
template <typename Base>
bool is_convertible(Base* base) {
  return true;
}

// 구현 2
// 구현 1을 적용할 수 없을 경우 사용된다
template <typename>
bool is_convertible(void* unknown) {
  return false;
}

class A {};

class B : A {};
B* b = new B();
// A는 B의 상위 타입이기에 A*에 B*를 대입할 수 있다
// 구현 1을 적용해도 문제없기에 is_convertible<A>(b)은 구현 1을 사용한다
// 따라서 true가 출력된다
is_convertible<A>(b);

class C {};
C* c = new C();
// A는 C의 상위 타입이 아니기에 A*에 C*를 대입할 수 없어
// 구현 1을 적용하면 컴파일 에러가 나기에 is_convertible<A>(b)은 구현 2을 사용한다
// 따라서 false가 출력된다
is_convertible<A>(c);

템플릿 특별화는 템플릿 함수 또는 타입을 사용했을 때 가장 적절한 구현을 자동으로 사용하는 기능입니다. 위 예시에서는 주어진 타입에 따라 컴파일 에러나는 함수 구현과 모든 타입을 사용할 수 있는 함수 구현 둘다 제공하여 상황에 맞는 구현을 사용하게 됩니다. is_convertible에 부모 타입을 넣었을 때 특별한 구현을 사용하는 것입니다.

이러한 특별화 기능은 다른 프로그래밍 언어들에게서는 쉽게 찾을 수 없는 기능입니다. C++가 강력한 언어라고 불리는 이유중 하나가 바로 이 템플릿 특별화에서 기인합니다. C++에는 이러한 템플릿 메타 프로그래밍을 활용한 함수들을 모아놓은 <type_traits> 라이브러리가 존재합니다. C++20에서는 이러한 템플릿 활용을 더 강화하기 위해 Concepts라는 개념을 추가하기도 하였죠.

다음은 리플렉션과 템플릿의 코드 생성을 비교한 표입니다.

	리플렉션	코드 생성
성능 저하	런타임	컴파일 타임
에러 발생 시점	런타임	컴파일 타임
바이너리 크기	상대적으로 작음	상대적으로 큼

하지만 C++의 템플릿에는 한계점이 있습니다. 리플렉션과 다르게 필드들의 목록을 가져올 방법이 없습니다. C++의 템플릿은 코드만을 생성하고 유효한지 검증해줄 뿐, 타입의 모든 정보를 가져오지는 못합니다. 리플렉션을 소개할때 작성한 임의의 데이터 타입을 JSON 형식으로 변환시키는 jsonify함수를 만들었었지만 C++에서는 템플릿만을 이용해서는 구현할 수 없습니다.

#매크로

C++ 에서의 메타프로그래밍은 템플릿만이 있는 것은 아닙니다. 매크로라는 템플릿보다 더욱 강력한 메타프로그래밍 기능이 존재합니다. 여기서는그중에서도 코드 일부를 치환해서 생성할 수 있는 매크로 함수에 대해서 다룹니다. 매크로 함수는 코드를 생성할 때 부분적으로 치환할 수 있다는 점에서 템플릿과 비슷합니다. 위 value 필드를 출력하는 템플릿을 매크로로 구현하면 다음과 같습니다.

// C++ 코드
// 매크로 함수 선언
#define DEF_PRINT_VALUE(T)    \
  void printValue(T t) {      \
    cout << t.value << endl;  \
  }

// A.value는 int 타입
struct A {
  int value;
};

// B.value는 float 타입
struct B {
  float value;
};

// A와 B 버전에 대한 오버로딩 함수 생성
DEF_PRINT_VALUE(A)
DEF_PRINT_VALUE(B)

A a = { 5 };
B b = { 10.5f };
printValue(a);
printValue(b);

만약 유효하지 않은 타입으로 생성할 경우, 함수 호출 코드를 작성한 시점이 아닌 함수를 생성하는 시점에 에러가 발생합니다.

// C++ 코드
struct C {};

DEF_PRINT_VALUE(C)

// C++ 컴파일러(clang++) 에러 메시지
error: no member named 'value' in 'C'
DEF_PRINT_VALUE(C)
^~~~~~~~~~~~~~~~~~
note: expanded from macro 'DEF_PRINT_VALUE'
                        cout << t.value << endl;  \

C++의 템플릿에 비해 더 나은 점이 있는가 싶을 수도 있습니다. 하지만 매크로의 진가는 타입만을 치환시키는 것이 아닌, 코드의 모든 부분들을 치환시킬 수 있다는 것입니다.


// C++ 코드
// C/C++ 매크로 정의
#define DEF_PRINT_FIELD(T, fieldName)  \
  void print_##fieldName(T t) {        \
    cout << t.fieldName << endl;       \
  }

struct Human {
  string name;
  int age;
  string role;
};

DEF_PRINT_FIELD(Human, name)
// 아래 코드가 생성된다.
//  void print_name(T t) {
//    cout << t.name << endl;
//  }

DEF_PRINT_FIELD(Human, age)
// 아래 코드가 생성된다.
//  void print_age(T t) {
//    cout << t.age << endl;
//  }

DEF_PRINT_FIELD(Human, role)
// 아래 코드가 생성된다.
//  void print_role(T t) {
//    cout << t.role << endl;
//  }

Human human = { "mango", 23, "software engineer" };

print_name(human);
print_age(human);
print_role(human);

역설적이게도 이렇게 강력하기 때문에 C/C++의 매크로를 기피하시는 분들도 많습니다. 강력한만큼 잘못된 방식으로 매크로를 사용하면 어떠한 동작을 할 지 예상하기 어려워져 더더욱 읽기 어려워지고 관리하기 어려워집니다.

하지만 리플렉션이 없고 컴파일 타임에서도 타입 정보가 부족한 C++에서는 보일러플레이트 코드를 줄이기 위해서는 매크로는 필수부가결합니다. 매크로의 단점을 감수하고 많은 C++ 프레임워크는 매크로를 사용합니다.

#추상 구문 트리 매크로

Scala와 Rust에도 매크로가 존재합니다. 다만 C/C++의 매크로와는 차이점이 많습니다. 먼저 Scala 부터 살펴봅시다. Scala의 경우 매크로 실행할 때 소스의 모든 타입 정보들이 제공되며 **추상 구문 트리(Abstract Syntax Tree, AST)**에 접근하고 수정할 수 있습니다.

Scala의 매크로를 이용하면 메소드나 클래스를 자동으로 생성하고 타입클래스를 자동으로 구현해주거나 기존에 존재하는 클래스도 수정할 수 있습니다. 위 C++ 매크로를 Scala 방식으로 구현한 것은 다음과 같습니다.

// Scala 코드
// 메소드 생성하는 매크로 어노테이션 정의
class Printer extends StaticAnnotation {
  def macroTransform(annottees: Any*): Any = macro Printer.impl
}

// 매크로 정의
object Printer {
  def impl(c: whitebox.Context)(annottees: c.Expr[Any]*): c.Expr[Any] = {
    import c.universe._

    // 어노테이션을 받은 클래스의 추상 구문 트리를 가져온다
    annottees.map(_.tree) match {
      case (clazz: ClassDef) :: Nil =>
        // 모든 필드들을 조회해 print 메소드들을 생성한다
        val printMethods = clazz.impl.body.collect {
          case valDef: ValDef if valDef.mods.hasFlag(Flag.CASEACCESSOR) =>
            q"""
            def ${TermName(s"print_${valDef.name}")}(): Unit =
              println(${valDef.name})
            """
        }

        // 생성된 print 메소드들을 이어붙힌다
        c.Expr(
          ClassDef(
            clazz.mods,
            clazz.name,
            clazz.tparams,
            Template(
              clazz.impl.parents,
              clazz.impl.self,
              clazz.impl.body ++ printMethods
            )
          )
        )
      case _ =>
        // class가 아닐 경우 에러를 낸다
        c.abort(c.enclosingPosition, "only classes can use @Printer")
    }
  }
}

// 매크로 어노테이션을 적용한 클래스를 정의한다
@Printer
case class Human(
  name: String,
  age: Int,
  role: String
)

// 생성된 메소드들을 마음껏 활용한다
val human = Human("mango", 23, "software engineer");
human.print_name();
human.print_age();
human.print_role();

Rust의 경우 매크로가 타입 정보를 제공해주지는 않습니다만, 여전히 추상 구문 트리에 접근할 수 있게 해주기 때문에 매크로를 적용 받는 타입의 필드 이름이나 필드 타입까지는 가져올 수 있습니다.

이를 이용하면 타입을 추가하거나 메소드를 추가하는 건 쉽습니다. Scala가 매크로로 타입클래스를 자동으로 구현해줄 수 있는 것처럼 Rust도 매크로를 이용하면 trait를 자동으로 구현해줄 수 있습니다. 위 C++ 매크로를 Rust 방식으로 구현한 것은 다음과 같습니다.

// Rust 코드
// attribute 매크로 정의
#[proc_macro_attribute]
pub fn make_printers(
  _attr: proc_macro::TokenStream,
  item: proc_macro::TokenStream,
) -> proc_macro::TokenStream {
  // 추상 구문 트리를 분석한다
  let derived_item = syn::parse_macro_input!(item as DeriveInput);
  let item_ident = &derived_item.ident;

  // attribute를 받은 struct의 구조를 가져온다
  let printers = match &derived_item.data {
    // 모든 필드들을 조회해 print 메소드들을 생성한다
    syn::Data::Struct(data) => data.fields.iter().map(|field| {
      let field_ident = field.ident.as_ref().unwrap();
      let printer_ident = proc_macro2::Ident::new(
        &format!("print_{}", field_ident),
        proc_macro2::Span::call_site(),
      );
      quote! {
        pub fn #printer_ident(&self){
          println!("{}", self.#field_ident);
        }
      }
    }),

    // sturct가 아닐 경우 에러를 낸다
    _ => compile_error!("only structs can use make_printers"),
  };

  // 생성된 print 메소드들을 추가한다
  quote! {
    #derived_item
    impl #item_ident {
      #(#printers)*
    }
  }.into()
}

// attribute 매크로를 적용한 struct를 정의한다
#[make_printers]
struct Human {
  pub name: String,
  pub age: i32,
  pub role: String,
}

// 생성된 메소드들을 마음껏 활용한다
let human = Human {
  name: "mango".to_owned(),
  age: 23,
  role: "software engineer".to_owned(),
};

human.print_name();
human.print_age();
human.print_role();

코드가 긴 만큼 단점도 명확하게 보일거라고 생각합니다. 일반적으로 이러한 강력한 기능을 제공하는 매크로는 복잡합니다. 이러한 문법 구문 트리를 수정할 수 있게 하는 매크로를 지원하려면 언어 차원에서 제공해야하는 기능이 많고 알아야 할 것도 많으며, 더 많은 코드가 컴파일 타임에 실행되는 만큼 컴파일 속도도 느려집니다. 하지만 그런 만큼 적재적소에 사용할 경우 많은 양의 보일러플레이트 코드를 없앨 수 있습니다.

#메타프로그램

사실 모든 프로그래밍 언어에 메타프로그래밍을 사용할 수 있습니다. 툴이나 스크립트로 코드를 읽고 코드를 생성하는 것도 메타프로그래밍이기 때문입니다. 유명 라이브러리와 프레임워크들도 언어에서 자체적으로 지원되는 기능 대신 외부 프로그램으로 코드를 생성하기도 합니다. 이러한 프로그램들을 **메타프로그램(Metaprogram)**이라고 부릅니다.

Java은 Annotation Processor, Kotlin은 Kotlin Symbol Prcoessor를 통해 코드를 생성할 수 있으며 JVM의 특성을 이용해 기존에 존재하는 클래스도 수정할 수 있고 C# 또한 코드를 생성할 수 있는 다양한 툴이 존재하며 Go는 다형성 기능이 부족한 만큼 메타프로그램에 의존하는 경향이 높습니다. 매크로가 코드의 일부분만을 생성하고 다른 매크로 호출에 간섭할 수 없는 만큼 때로는 메타프로그램이 매크로보다 나은 경우도 있으며 추상 구문 트리에 접근 가능한 매크로가 존재하는 Scala도 파일 단위로 추상 구문 트리에 접근 할 수 있게 해주는 Scalameta라는 라이브러리가 존재합니다.

코드 생성이 대표적인 기능인 라이브러리들로는 GraphQL과 gRPC/Protobuf가 대표적입니다. GraphQL은 언어 라이브러리마다 다르지만 GraphQL 스키마로부터 API 코드를 생성하거나 API 코드로부터 GraphQL 스키마를 생성할 수 있고 gRPC/Protobuf는 API나 데이터 타입을 protobuf 코드로 정의하고 다양한 언어들을 대상으로 코드를 생성할 수 있는 기능이 있습니다.

반드시 라이브러리와 툴을 사용해서 코드를 생성해야만 메타프로그램인 것이 아닙니다. Python과 같은 스크립팅 언어로 소스 파일을 생성해주는 프로그램 또한 메타프로그램입니다. 소스 파일의 추상 구문 트리를 분석하거나 스키마 파일을 읽을 수 있는 툴들에 비해 접근할 수 있는 정보는 적지만 프로젝트에 맞는 소스 코드를 자유롭게 생성할 수 있다는 장점이 있습니다.

#결론

그만큼 메타프로그래밍은 큰 규모의 프로젝트에서는 필수적인 기능입니다. 다형성을 통해 코드 재사용성을 늘리는 것이 가장 좋지만 고도화된 아키텍처에서는 도메인의 요구 사항에 맞는 메타프로그래밍이 필요한 순간이 옵니다. 그럴 때 이 글이 더 좋은 아키텍처를 디자인하는데에 조금이라도 도움이 되었으면 합니다.

프로그래밍 언어 시리즈에는 의도적으로 정적 타입 언어들만 포함하고 있었는데요, 이유는 정적 타입 언어와 동적 타입 언어를 정확하게 비교하려면 정적 타입 언어의 다형성, 메타프로그래밍까지 전부 이해하고 있어야 하기 때문입니다. 언젠가 기회가 된다면 정적 타입 언어와 동적 타입 언어를 비교하는 글을 쓸 수 있으면 좋겠습니다.

쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기

Thu, 22 Dec 2022 00:00:00 GMT

이 글과 관련된 다른 글 보기

쿠키런: 킹덤 런칭 회고 - DevOps 관점에서 본 쿠키런: 킹덤 런칭 회고
CockroachDB in Production - CockroachDB에 대한 소개와 킹덤에서 CockroachDB를 사용한 이유 설명
CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기 - CockroachDB의 소스코드를 참고하며 바이너리 파일로부터 데이터를 복구한 이야기
입사 첫날에 36시간 점검 경험하기 - 신규입사자의 관점에서 서술된 장애 대응 기록
쿠키런: 킹덤 AWS AZ 장애 아웃라인 - AWS AZ 장애로부터 서비스를 복구한 이야기
쿠키런: 킹덤 길드 업데이트 이후 서비스 이슈 되돌아보기 - 쿠키런: 킹덤에 길드 기능이 추가된 이후 발생한 서비스 이슈 회고

안녕하세요, 저는 데브시스터즈 진저랩 인프라셀에서 데브옵스 엔지니어로 일하고 있는 이창원입니다. 지난 글인 쿠키런: 킹덤 런칭 회고에 이어 이번에는 런칭 후 4일 만에 기술적인 문제로 인해 발생했던 약 36시간 동안의 서비스 장애에 대해 전해드리려고 합니다. 여러 편의 글을 통해 다각도에서 이야기를 풀어드리고자 하는데, 이번 글에서는 서비스 장애의 원인과 해결 과정, 그리고 회고를 다루려고 합니다.

#Disclaimer

이 이야기는 박새미님과 NDC22에서 공동 발표한 쿠키런: 킹덤, 총 56시간의 긴급 점검 회고 - 그때 그 명검은 왜 뽑아야 했는가와 CockroachDB 고객사 컨퍼런스 행사인 Roachfest 세션에서 발표되기도 하였습니다. 보다 생동감 있게 혹은 짧은(?) 버전으로 일련의 이야기를 접하고자 하는 분들은 발표 영상을 보시는 것을 권해드립니다.
데브시스터즈에서 어째서 CockroachDB라는 다소 생소한 데이터베이스를 사용하기로 결정했는지 이유나, 이 글을 읽으면서 CockroachDB의 내부 동작이나 설계가 궁금하신 분들은 CockroachDB in Production을 읽으시는 것을 추천합니다.

#지난 글에서…

지난 글에서 여러 장치를 두어 <쿠키런: 킹덤>을 런칭했고, 첫 주말을 안정적으로 넘겼지만 모니터링 중에 사용자 수가 단조증가하여 스토리지 사용량이 크게 늘고 있었다는 이야기로 마무리되었는데요. <쿠키런: 킹덤>에서 사용한 CockroachDB가 배포되어 있는 리눅스 운영체제의 특성 상 디스크 공간이 가득 차게 되면 더 이상의 쓰기 작업이 불가능하게 됩니다. 이렇게 되면 당연하게도 사용자 상태의 변경사항을 기록하는 데이터베이스 본연의 기능을 할 수 없을 뿐더러, 분산 데이터베이스로써 변경사항을 여러 노드 간에 항시 복제, 전파하는 안전장치가 동작할 수 없게 됩니다. CockroachDB는 CP 시스템이므로 이런 경우 가용성, 즉 문제가 발생한 노드를 희생하여 데이터 일관성을 보존하도록 설계되어 있으며, <쿠키런: 킹덤>의 경우 7개의 복제본을 저장하도록 설정되어 가용성이 보장되지 않는 상태에서도 데이터 영향도가 가장 적도록 의도하였습니다.

런칭 후 첫 주말을 보내고 월요일 오전 출근하여 클러스터 상태를 확인하니 사용자 인입이 현재 상태를 유지할 경우 위에서 묘사한 상황이 닥치기까지 약 36시간이 남은 것으로 계산할 수 있었습니다. 오픈 이후 유저 수는 단조증가하고 있었지만 마케팅은 서버 안정성이 확보된 이후에 집행하기로 결정되어 있던 상황이었습니다. 따라서 마케팅 집행이 시작되면 지금보다 더 가파른 규모로 유저가 증가할 수 있다는 사실을 인지하고 있었기 때문에 팀 내 위기감이 더욱 고조되었습니다. 당장 발등에 불이 떨어진 상황이기 때문에 저희는 여러 지표들을 따져보며 클러스터 규모를 얼마나 더 크게 키워야할지를 계산을 하는 동시에 공식 가이드를 따라 모든 노드에 Ballast 파일을 생성해두기로 결정했습니다.

당시 사용 중이던 19.1.11 버전 공식 가이드에 적힌 내용.

사실 파일 시스템이 가득 찰 경우 데이터베이스 쓰기 작업이 문제가 아니라, 리눅스 시스템에서는 대부분의 작업을 할 수 없게 됩니다. 이러한 상황에 대처할 수 있도록 CockroachDB의 공식 가이드에서는 Ballast 파일을 미리 생성해둘 것을 공식적으로 가이드하고 있습니다. 여기서 Ballast 파일이란 정확히 이런 경우에 대비한 보험으로, 미리 공간을 점유해두는 더미 파일을 의미합니다. 유사시 Ballast 파일을 삭제하면 스토리지 증설에 필요한 명령 등을 실행할 수 있게 되고, 이후 다시 클러스터에 Join할 수도 있어 재해 복구에 도움이 됩니다.

#데이터베이스 작업과 이슈 발생

그러나 Ballast 파일을 생성하기 위해 미리 작성해둔 스크립트를 실행하였는데 Ballast 파일의 경로가 잘못 설정되어 Block Device를 가리키고 있었고, 마침 Ballast 파일을 만들어주는 커맨드에는 대상 경로에 파일이 이미 있는지 확인하는 안전장치가 없었기 때문에 스크립트의 실행 결과 파티션을 덮어 쓰게 되었습니다. 이 영향으로 데이터베이스의 일부 노드에서 파일 시스템 불안정이 발생하게 되어 쓰기 작업이 실패하게 되고, 클러스터에서 자동적으로 격리되었습니다.

저희가 사용했던 AWS EC2 인스턴스 타입은 m5d.8xlarge로, 2개의 로컬 스토리지 디바이스를 제공하는 유형입니다. 여러 개의 로컬 스토리지 디바이스가 존재할 경우 EC2에서는 랜덤한 것을 Primary Mount로 삼는데, 이 때 설정 이슈로 인해 지정된 경로가 Primary Mount에 해당할 경우 문제가 발생하였습니다.¹ 총 24대의 노드로 클러스터를 구성하였으므로 확률적으로는 12대의 노드가 영향을 받아야 했겠지만, 저희의 경우는 과반 이상인 16대의 노드가 영향을 받게 되었습니다. 설계상 CockroachDB는 Raft라는 컨센서스 알고리즘을 차용하므로 동작하려면 적어도 과반 이상의 노드가 필요한데, 하필 그 이상의 노드가 영향을 받게 되었으므로 노드 단위 장애에서 클러스터 전역적인 장애로 번지게 됩니다.

지금에서야 정리된 형태로 사건을 서술할 수 있게 되었지만, 당시에는 설정 이슈가 있다는 사실을 인지하지 못하던 상태였으므로 작업 수행 직후 미리 설정해두었던 메트릭을 통해 상황을 인지하게 되었습니다. 삽시간에 에러율, 데이터베이스 연결, 그리고 Health Check 알람까지 수백 건의 알람이 발생했는데, 알람의 메세지를 읽기도 전에 여러 알람이 동시다발적으로 발생하는 상황은 일반적으로 생각해도 아주 굉장히 큰일 난 상황일 확률이 높습니다. 정상적인 게임 이용이 어려운 상황임을 인지하자마자 운영팀에 긴급 점검을 요청하여 16시 52분부터 긴급 점검이 시작되었습니다. 이후 데브옵스 팀 전체가 달려들어 약 30분 정도 셸 히스토리와 CRDB 로그, 커널 로그, 그리고 CRDB 소스코드를 분석한 이후 정확히 어떤 일이 일어나고 있는지를 파악할 수 있었습니다.

빨간 글씨가 많이 있어 딱 봐도 뭔가 잘못되었다는 것은 알 수 있는 당시 커널 작업 화면.

상황을 인지한 이후부터 팀의 최우선순위는 데이터베이스 클러스터의 상태를 복원하는 것으로 설정되었습니다. 문제에 대한 대응 방법을 탐색하는 과정에서 AWS와 CockroachDB 기술지원을 요청해보자는 의견이 있었고, 지푸라기 잡는 심정으로 양 측 기술지원팀과 동시에 화상 회의를 진행하였습니다. 설정 오류로 인해 커널 시스템 장애로 이어졌던만큼, 먼저 AWS EC2 팀에 기대어 보았습니다. 저희보다 리눅스 시스템에 대한 이해도가 조금이라도 더 깊을 것이라는 막연한 기대와 더불어 혹시라도 우리가 알지 못하는 사이에 모종의 가상머신 스냅샷을 찍어 보관하고 있지는 않을까 하는 희망을 가져보았지만, 역시나 세상에 그런건 없었고, 별다른 소득 없이 EC2 팀과의 서포트는 종료되었습니다. 이제 심각한 상황을 뭔가 매지컬한 방법으로 빠르게 없던 일로 되돌릴 수 있는 방법이 없다는 사실을 받아들이고 실질적으로 해결할 수 있는 전략을 세워야 했습니다.

CockroachDB 서포트 엔지니어와도 문의를 이어가고 있었는데, 저희는 먼저 영향 받지 않은 노드들을 바탕으로 과반 이상의 구성원을 잃어 클러스터 형성이 깨져버린 이 상황을 복구할 수 있는지 알아보고 있었습니다. 서포트 엔지니어도 이러한 상황이 흔하지는 않았던 모양인지 내부 엔지니어들과 지속적으로 소통하며 도움을 주려고 노력하였지만, 내부 논의가 썩 긍정적이지는 않았는지, 가장 빠르게 서비스를 복구하는 방법은 이전에 만들어둔 백업 데이터를 바탕으로 복원하는 것이라는 의견을 제시해 주었습니다. 이 경우 백업 데이터가 생성된 시점부터 장애 발생 시점까지의 모든 데이터는 유실되어, 흔히 백섭이라고 말하는 상황이 발생합니다. 냉정하게 생각하면, 주어진 상황을 고려했을 때 일반적으로 떠올릴 수 있는 방법인 것은 맞습니다. 그리고 직접 머신에 접근할 수 없는 CockroachDB 서포트팀 입장에서 원론적인 답변을 하는 것 또한 이해할 수 있습니다.

그러나 저희 팀은 이에 대해 쿠키런: 킹덤 개발팀과 깊게 논의한 끝에, 시간이 오래 걸리더라도 다른 방법이 존재하는 한 백섭이라는 선택지는 배제하기로 가장 먼저 결정하였습니다. 게임 운영 관점에서도 여러 이유가 있었겠지만, 엔지니어이기 이전에 한 명의 유저로서 적어도 제가 이해한 배경은 ‘유저들이 쿠키들을 막 만나가며 자신만의 왕국을 꾸며가는 과정에서 쌓은 추억을 그렇게 쉽게 없던 것으로 만들 수는 없다’는 것이었습니다. 또 모든 단서를 종합해봤을 때, 저희 팀은 그렇게 높은 확률은 아닐지언정 방법이 아예 존재하지 않는 것은 아니라고 판단했습니다. 따라서 저희는 서비스 중단이 발생하기 바로 이전까지의 모든 데이터를 복원하는 것을 장애 복구의 최종 목표로 설정하고 세 가지 방법을 동시에 진행하게 됩니다.

#Plan A, 운영체제 레벨에서 노드 복원하기, 그러나 영 좋지 않은 노드가…

먼저 Plan A는 앞서 시도해보고 있었던 데이터베이스 클러스터의 상태를 복원하는 것이었습니다. 클러스터의 상태를 복원할 수만 있다면 기존에 보유하고 있던 데이터도 모두 복원할 수 있을 것이기 때문에 따르는 사이드 이펙트가 가장 적을 것으로 예상되었습니다. 이를 위해 일단 영향을 받은 모든 머신에 ebs를 붙이고 dd 커맨드를 사용해 파티션을 복제하였습니다. 이후 파티션을 복원하기 위해 복제된 EBS 파티션에 fsck 명령어를 돌려보았는데, 오류 항목이 너무 많아 실질적으로 복원이 잘 되고 있다고 생각하기 어려웠습니다. 어쨌든 fsck 이후의 결과물을 바탕으로 클러스터를 재구성하려고 시도해보았지만, 여전히 특정 SST 파일을 찾을 수 없다는 등, 정황상 파일시스템 오류가 해결되지 않았습니다.

여러 가지 시도를 이어가던 중, 23시 02분 경 영향을 받지 않아 정상적인 파일 시스템을 소유하고 있던 노드 하나가 Host Status Failure를 맞고 그대로 내려가 버리고 말았습니다. 물론 이런 경우를 상정하고 Replication Factor를 높게 설정하기도 했지만, 하필이면 장애 복구 중에, 그것도 문제가 생긴 노드도 아닌 멀쩡한 노드에 발생하다니요. 안타깝게도 이때까지 대부분의 작업은 망가진 노드를 복구하는 것에 초점이 맞추어져 있었기 때문에 정상 작동하던 노드는 EBS 복원도 해두지 않았고, 따라서 이제 남아있는 노드는 8대가 아닌 7대가 되어버렸습니다.

아니 물론 저희가 잘못을 하긴 했지만 이렇게까지 시련을 겪을 필요는 없잖아요… ㅜㅜ

#Plan B, 데이터가 여기에 있는데 이걸 못 쓸 리가 없잖아!

일련의 과정에서 저희는 CockroachDB가 널리 알려진 RocksDB와 유사한 스토리지 엔진을 차용하고 있다는 점과 데이터가 7개의 복제본을 가지도록 설정해두었던 사실에서 착안하여 스토리지 이슈가 발생하지 않은 노드에 남아있는 데이터를 활용하여 복원할 수 있지 않을까 하는 아이디어를 떠올리고, 두번째 복구 전략인 Plan B를 수립하였습니다. 남아있는 노드가 7대이므로 우선 데이터의 완전 손실율이 C(16, 7) / C(24, 7) ~= 3.3%에 불과한데다, Event Sourcing 아키텍쳐를 사용한 킹덤 서버 구조, 그리고 MVCC 모델을 사용하여 데이터를 증분 저장하는 CockroachDB의 스토리지 레이어 구조를 종합적으로 고려할 때 이 정도 손실율이면 충분히 투자할 가치가 있다고 판단했습니다.

CockroachDB 서포트 팀에도 이 아이디어를 공유했지만 몹시 회의적인 반응이었습니다. 먼저 수동으로 Low-level Storage Layer에서 데이터를 추출할 수 있는 방법이 있는지를 물었지만 수 주 이상 소요될 것이고 성공하리라는 보장도 없다는 답변을 들었습니다. 이런 상황에 활용할 수 있는 내부툴이 있는지 역시 물었는데, 별로 쓸만하진 않을 것이라고 덧붙이긴 했지만 다행히 디버그 용도로 사용하는 명령어가 있다는 사실을 알 수 있었습니다. 저희는 아예 CockroachDB의 소스코드를 탐색하였고, 이윽고 CockroachDB 스토리지 레이어에서 사용하는 파일 확장자인 SST 파일 내부를 볼 수 있는 명령어를 찾아냈습니다. 저희는 떠올렸던 접근방식이 유효한지 검증하기 위해 PoC를 진행하기로 했지만, 서포트 팀에서는 여전히 귀중한 시간을 불확실한 확률에 낭비하기보다 백업 데이터에서 복원하는 것을 추천하는 등, 분위기가 썩 고무적이지는 않았습니다.

#Plan C, 헨젤과 그레텔도 집을 찾아갈 수 있었다면 우리도?

실제로 이 방법이 성공하더라도 이 방법을 통해 데이터를 복구해내기에는 걸려 넘어질 수 있는 구석이 많아 보였기 때문에, Plan C도 세워둘 필요가 있었습니다. 데이터 완전 복구를 위한 세번째 방법인 Plan C는 가장 최신의 백업 데이터를 사용해 데이터베이스를 어느정도 복원해둔 상태에서, 백업 시점부터 장애시점까지 발생한 분석용 로그 데이터를 바탕으로 사용자의 최종 상태를 복원하는 것이었습니다. 이 방법은 마치 LoL 중계에서 크로노 브레이크가 발생할 때 동작하는 원리와도 비슷한데요. 사용자의 행동을 다시감기하는 방법이므로 모든 로그를 완벽히 잘 남기고 있어야만 가능한 방법입니다. 언뜻 그럴듯 해 보이기는 하지만, 이 방법은 수백 종류가 넘는 로그의 정합성이 모두 보장되어야 한다는 전제 조건이 따르며, 사실상 모든 서버 API에 대해서 gRPC로 요청을 받는 방식에서 로그를 바탕으로 처리하는 방식으로 다시 구현해야 한다는 의미였습니다. 또 여러 가지 일반적이지 않은 엣지 케이스들도 처리해야 했고, 테스트를 통해 결과의 동일성 또한 보장할 수 있어야 합니다. 수백가지나 되는 모든 서버 API에 대해서 이러한 작업을 하기에는 시간과 인력, 정신력 모두 부족했기 때문에 우선순위를 두어 가장 핵심적이라고 생각되는 API에 대해서부터 대응을 시작하였습니다.

Plan A, B, C 모두 어느 하나 쉬운 방법이 없었습니다. 작업자들 모두 자신이 가장 잘 기여할 수 있는 방법에 최선을 다해 기여하면서도, 각자 진행하는 작업이 성공하리라는 확신은 없는 채로 그저 다른 쪽에서 진행하는 방법이 꼭 성공해줄 것이라 믿고 있는 상태였습니다.

Plan A 쪽에서는 몇 가지 시도를 더 이어간 끝에, 안타깝게도 결국 디스크 복구를 통해서도 리눅스 파일 시스템을 복구하는 것은 영영 불가능하다고 결론내렸습니다. 남아있는 7대의 노드 만으로 클러스터를 재구성할 수 있는지 또한 시도를 해보았는데, CockroachDB 클러스터가 시작할 때 Raft Quorum을 검증하는 로직이 있었고, 영향을 받은 노드들이 존재했던 기록이 남아있어서 Healthy State로 진행하지 못하고 있었습니다. 문서화되지 않은 CockroachDB 내부 툴까지도 총동원하며 이 로직을 우회할 방법이 없는지를 연구해보기도 하였지만, 다음날 오전 5시까지 시도해본 끝에 이 단계를 우회할 수 있는 방법은 찾지 못했고, 따라서 기존 클러스터를 재사용할 수 있을 확률은 매우 희박하다는 결론에 다다랐습니다.

다행히 Plan B 쪽에서 시도하던 방법이 어느 정도 성공을 거둬 SST 파일이 어떤 구조로 작성되어 있는지 해독하는 데에 성공했습니다. 또 해독한 바이너리 코드를 인코딩 규약에 따라 손으로 파싱을 해보니 그 결과가 그럴듯 했습니다. 이 경험을 바탕으로 장애 발생 다음날 오전 4시 경 Spark 기반으로 SST 파일의 내용물을 CSV 포맷의 텍스트 파일로 추출하는 샘플 코드를 작성할 수 있었습니다. 이 작업의 실행속도를 미리 계산해보니 32-core 머신 150대 규모의 Spark 클러스터를 사용해서 24개 데이터베이스 노드에 존재하는 모든 SST 파일을 변환한다고 할 때 약 24시간이 걸리는 것으로 예상되었습니다. 이는 너무도 긴 시간이었기 때문에 우리가 필요한 작업만을 고려하여 CockroachDB CLI 소스코드를 최적화 할 여지가 없는지 연구를 했고, 개조에 성공하여 결과적으로 약 10배 이상 빨라지도록 개선하기도 하였습니다. 이 과정에 대해 자세하고 기술적인 내용을 담은 글도 작성될 예정이니 참고를 해보셔도 좋겠습니다.

#다음 날, 일단 데이터는 읽었다. 그런데 너무 많다

이 방법이 성공할 경우 SST 파일에 존재하는 행(Row) 단위 내용물을 CSV로 추출할 수 있었고, CockroachDB는 CSV의 데이터로부터 테이블로 들여오는 기능이 있었기 때문에 데이터를 다시 복구해낼 수 있다는 희망이 보였습니다. 마침 저희가 사용하던 버전에 새로 추가된 기능이기도 했습니다. 오전 10시 30분 경부터 최후 생존한 7개 노드에 남아 있던 약 7.5TB 분량의 SST 파일을 CSV로 변환하며 발생하는 에러를 수정하는 사이클을 진행하였습니다.

이 때 실제로 테이블 스키마를 작성하고 복원하는 작업을 진행해보니 몇 가지 제약사항을 발견했습니다. 먼저 IMPORT INTO 명령어는 데이터를 특정 테이블에 대입하는 방식으로 동작하는데, 명령이 수행되는 동안은 테이블이 마치 존재하지 않는 것처럼 오프라인 상태가 되었고, 단일 Transaction으로 처리되어 Primary Key나 Unique Key Constraint 등에서 충돌이 발생할 경우 모두 Revert 되었습니다. 이러한 동작의 이유는 아마도 동시성 환경에서 테이블을 원자적으로 생성하기 위한 의도였을 것으로 추측되는데, 이 때문에 하나의 SST 파일, 즉 Range 단위로 병렬적으로 데이터를 들여오려던 원래의 계획대로 진행할 수 없게 되었습니다.

저희가 복원하고자 하는 것은 백만 단위의 사용자에 대한 이벤트소싱 아키텍쳐 하의 유저 데이터였으므로 아무리 성능 좋은 분산 데이터베이스 시스템이더라도 처리하는데 많은 시간이 소요될 수 밖에 없었는데요. 충돌이 발생하여 Transaction Rollback 되게 된다면 그만큼 복구시점이 늦어진다는 의미였으므로, 7.5TB 분량의 데이터에 대해서 신중하고 완벽한 중복처리 작업이 필요하게 되었습니다. 각 Range 파일은 최대 512메가, 혹은 Range Split 알고리즘에 따라 그보다 더 작은 크기로 관리되는데요. 이튿날 오후 12시부터는 발견한 제약사항에 따라 중복을 제거하여 실제 DB에 넣을 수 있는 형태로 된 하나의 거대한 CSV 파일로 병합하는 Spark 코드를 작성하였습니다.

길고 고된 복구 작업 중 잠시 누워 휴식을 취하는 동료의 모습

장애 발생 후 약 22시간이 지나 둘째날 오후 2시 30분 경이 되었을 때 위 작업이 모두 완료되었고, 보다 넉넉한 스토리지를 차용한 새로운 데이터베이스 클러스터에 데이터를 들이붓는 작업을 시작하였는데요. 그럼에도 Row Count와 유저 데이터의 크기가 물리적으로 너무 방대해 지나치게 긴 시간이 소요될 것으로 예상되었기에 각 유저당 킹덤 이벤트소싱 구조 처리에 필요한 최소 단위인 가장 최근 스냅샷 1개와 가장 최근 저널 300개만 복원하기로 다시금 조건을 좁혔습니다.² 데이터 전처리 작업을 위해 Spark Worker Node를 최대한 끌어쓰다보니, 저희가 사용하는 AWS 도쿄 리전의 모든 AZ에서 가용한 R계열 인스턴스를 모두 소진하는 일도 있었습니다. 당시 회사의 최우선 과제는 데이터베이스 복원 작업이었으므로 일상의 다른 작업을 위해 사용 중이던 인스턴스들까지 모두 종료하고 끌어모아 전처리 작업에 활용하기도 하였습니다.

마침내 오후 4시 20분, 저널 테이블의 복원이 성공적으로 완료되었고 오후 4시 57분에는 스냅샷 테이블의, 오후 5시 22분에는 유저 테이블의 복원에 성공하였습니다. 그러나 기쁨도 잠시, 복원 방법 자체가 사실 정상적인 데이터베이스 작업은 아니고 저희가 설정한 몇가지 가설들을 토대로 하고 있었기 때문에 완벽한 검증을 필요로 했습니다.

일단 가장 최근의 “정상적인” 데이터베이스 백업으로부터 또다른 데이터베이스를 구성해 정합성 검증에 나섰습니다. 모든 테이블에 대해 고유키를 대상으로 DISTINCT COUNT를 계산해 보았을 때, 자체적으로 복원해낸 데이터베이스(이하 ”리커버 본”)의 Row Count가 데이터베이스 백업으로부터 복원해낸 데이터베이스(이하 “백업 본”)의 Row Count보다 모두 더 많았습니다. 데이터베이스 백업은 실시간이 아니므로 장애 시점의 데이터를 토대로 복원해낸 데이터는 데이터베이스 백업보다 무조건 더 미래시점의 데이터입니다. 런칭 후 얼마 지나지 않아 사용자 탈퇴로 인한 데이터 보관 기한이 도래하지도 않았으므로, Row Count가 더 많다는 것은 일단 긍정적인 신호로 볼 수 있습니다. 또, 백업 본의 사용자 고유 식별자의 집합에서 리커버 본의 사용자 고유 식별자의 집합의 차집합을 구하도록 계산을 해보니 공집합을 얻었습니다. 이것은 백업 본이 리커버 본의 부분 집합이라는 의미이므로, 일단 백업 본에 존재하던 데이터들은 모두 복원에 성공한 것으로 해석할 수 있습니다! 이 날 들은 소식 중에 단연 가장 기쁜 소식이었습니다!

그러나 기쁜 소식만 있었던 것은 아니었던 것이, 간단한 검증 과정을 통해 유저 테이블에 오염이 심각한 것을 발견할 수 있었습니다. 왕국 이름에 중복되는 항목이 많다거나, 변화가 생겨야 하는 필드들이 그대로 남아있는다거나 하는 이상한 항목들도 많았고, 탈퇴한 유저들의 경우 또한 제대로 복구되지 않았습니다. 이 유저 테이블은 필수적인 테이블은 아니지만 유저 정보를 보여주기 위한 일종의 Projection Table인데, 이 테이블의 정보가 제대로 되어 있지 않으면 유저의 실제 상태와 프로필 등에서 보여지는 상태가 달라지는 이슈가 발생할 수 있습니다. 다행히 Plan C 작업에 몰두하시던 서버 엔지니어 분들께서 진실의 근원인 스냅샷과 저널 테이블을 기반으로 유저 테이블을 처음부터 재구성할 수 있도록 로직을 추가해주셔서 복원 대상에서 제외하기로 결정하였습니다. 나중에 알고 보니 INSERT/DELETE 쿼리 위주로 사용하는 저널과 스냅샷 테이블과 다르게 유저 테이블은 UPDATE가 자주 발생하는 테이블이었고, MVCC 데이터 처리 과정에서 중점적으로 고려한 시나리오는 킹덤 서버 구동에 필수적인 저널과 스냅샷 테이블의 복원 방식에 초점이 맞추어져 있어 전처리 과정에서 문제가 있었던 것으로 밝혀지기는 하였습니다.

#마침내! 서비스 복구 가시화와 만일을 위한 정합성 검증

오후 7시부터는 데이터 복원이 모두 성공되었을 때를 가정하고 서비스를 재개할 때 사용할 깨끗한 데이터베이스를 준비하기 시작했습니다. 지금까지 사용하던 데이터베이스는 여러 번의 실패도 겪었던 클러스터인지라 아무래도 정리되지 않은 쓰레기값을 내부적으로 들고 있을 수 있어 성능에 영향을 줄 수도 있기 때문에 프로덕션에 그대로 사용하기는 찝찝합니다. 복원에 성공한 2개의 필수 테이블 외에도 언급되지 않은 다양한 메타데이터성 테이블이나 데이터의 최신성이 크게 중요하지 않은 보조 테이블들도 있었는데, 이런 것들은 단순히 백업 시점의 데이터를 활용하는 것으로 타협하였습니다. 최종적으로 저널, 스냅샷, 유저 테이블 이외의 테이블은 백업에서 복원하였고, 저널과 스냅샷 테이블은 SST 파일에서 추출하여 전처리를 거친 CSV 파일에서 Import 하였으며, 유저 테이블은 서버 로직으로 재구성하는 방식으로 진행하여 마침내 오후 8시에는 모든 작업이 완료되었습니다.

그리하여 최종적으로 서비스를 받을 수 있는 준비가 되었지만, 서비스 오픈 이후 문제가 발생한다면 더 큰 문제로 이어질 수도 있기 때문에 조금 더 신중을 기하였습니다. 일부 유저를 샘플링하여 주요 상태에 대해서 분석 로그에 기록된 상태와 최종값이 같은지를 검증하였습니다. 모든 유저에 대해서 진행할 수 있었다면 좋았겠지만, 이 작업은 한 건당 매우 오래 걸리기 때문에 부득이 샘플링을 할 수 밖에 없었습니다. 또, 누락된 저널이 있다면 스냅샷 리플레이가 제대로 되지 않고 게임 플레이 진행에 문제가 생길 수 있다고 판단하여, 모든 유저에 대해서 스냅샷 리플레이가 정상적으로 작동하는지를 검증까지 한 결과 모든 유저의 리플레이가 정상적으로 가능한 것을 확인했습니다. 이로써 모든 사용자 데이터의 정합성이 일치한다는 확신을 얻을 수 있었습니다. 마지막으로 간단한 기능 테스트까지 진행하여 서비스 오픈까지도 할 수 있는 상황임을 확인하였습니다.

QA 상황보다 테스트 모수를 더 많이 확보하기 위하여 오후 10시에는 사내망 테스트까지 진행하여 사내 구성원들이 마지막으로 기억하고 있는 계정의 상태와 일치하는지 또 한번 검증하기도 하였습니다. 이론적으로도 일치해야 했고, 실제로 코드를 통해 일치하는 것도 확인한 것은 맞지만, 이 과정이 모두 사람이 진행한 일인지라 직접 눈으로 확인하고 이상이 없다는 말을 듣고 나서야 복구에 참여한 엔지니어들도 비로소 안심할 수 있었습니다. 이 때 늦은 시간임에도 굉장히 많은 사내 구성원들이 사내망 테스트에 참여해주셔서 오랜 복구 작업이었음에도 모든 구성원들이 관심을 가지고 응원해주고 계셨다는 것을 몸소 느낄 수 있어 감동적이었습니다.

#긴급 점검 해제, 해치웠나?

최종적으로 이튿날 23시 37분, 30시간 50분 만에 서비스를 다시 오픈할 수 있게 되었습니다. 감사하게도 인내심을 가지고 기다려주신 유저분들께서 커뮤니티에 많은 글을 남겨주셨는데요. 작업 중간중간 제보받은 센스 넘치는 게시글들을 보며 많은 힘을 얻을 수 있었습니다.

당시 서버 오픈을 기다려주시던 유저 분들의 소중한 반응들

이렇게 서비스를 다시 오픈하여 쿠키런: 킹덤은 안정적으로 운영을 해오고 있습니다. 라고 마무리를 할 수 있다면 좋겠지만 그렇지 못했죠. 바로 이렇게 긴 시간 점검을 했던 것도 처음이었고, 그만큼 많은 유저분들께서 서비스 오픈을 기다리고 계셨다는 것을 간과하였다는 것인데요. 쿠키런 킹덤에 로그인을 하게 되면 데브시스터즈 게임 플랫폼인 DevPlay로 먼저 로그인, 인증 관련 요청이 들어오는 구조로 되어있습니다.

중요한 컴포넌트이지만 정상적인 상황에서는 요청량도 많지 않고 오토스케일링도 적용되어 있기 때문에 문제가 되는 일이 많지 않았지만, 서버가 열려있지 않은 상태에서 많은 유저 분들께서 언제 서버가 열리는지 지속적으로 확인하시던 것이 게임 진입 플로우상 DevPlay 플랫폼에 대한 부하로 이어지게 되었고, 플랫폼 데이터베이스 장애로 이어지는 Cascading Failure가 발생했습니다. 당시 플랫폼 서버에 발생했던 순간 API 수는 글을 작성하는 지금까지도 역대 최고 기록으로 남아 있습니다. DevPlay 플랫폼의 데이터베이스는 AWS RDS로 구성되어 있어 일시적 순단을 각오하고 Failover를 수행한 뒤에 정상화되었습니다.

1차 오픈 이후 DevPlay 플랫폼 서버에 발생했던 API Call Count.

한편 얼마 지나지 않아 킹덤의 데이터베이스에도 부하가 누적되기 시작했습니다. 쿠키런: 킹덤은 게임 특성상 자정에 많은 요청이 발생하는데, 이 때를 기점으로 DB Timeout으로 인한 에러율이 관측되기 시작했습니다. 당시 클러스터 일부 노드의 CPU는 100%를 사용하는 등 매우 불안정한 상황이 이어졌고, DB가 감당할 수 있는 수준의 부하를 넘어섰다고 판단하고 있었습니다. 원래라면 적절한 수준의 부하가 유지될 때 분산 데이터베이스의 특성을 활용해 Scale out을 할 수 있어야 하겠지만, 이번 경우에는 워낙 빠르게 악화되었기 때문에 뒤늦게 Scale out을 진행하는 것은 적절하지 않았습니다. 새벽 시간대임을 감안하여 점차 요청이 줄어들 것으로 예상하고 모니터링을 하고 있었지만 새벽 2시 42분, 다시 데이터베이스에서 모든 쿼리와 요청이 실패하는 것을 관측하자마자 2차 긴급 점검에 들어갈 수 밖에 없었습니다.

2차 긴급 점검 당시 CockroachDB 클러스터 대시보드

새로운 데이터베이스 클러스터를 구성할 때는 i3계열 인스턴스를 사용하는 것으로 변경했었는데요, i3계열 인스턴스는 스토리지 특화 인스턴스임에도 지표를 보았을 때 Disk Write Ops로 인한 부하가 CPU 부하로까지 이어진 것으로 추측할 수 있었습니다. 이로 인한 컨텐션이 충분히 빠르게 해소되지 않고 있다고 판단했기 때문에 다시 한 번 새 데이터베이스 클러스터를 구성하기로 결정했고, 이번에는 공식 지원하는 데이터베이스 백업 및 복원 기능을 사용하여 데이터를 안전하게 이전할 수 있었습니다. 워크로드에 대해 충분히 테스트를 사전에 진행하지 않은 채로 다른 인스턴스 타입을 선택한 것은 지나친 모험이었다는 의견이 있었기 때문에, 기존에 사용하던 m5d 인스턴스를 사용하되 더 많은 인스턴스 대수를 사용하여 3번째 데이터베이스 클러스터를 구성하기로 결정하였습니다. 데이터 규모가 큰 만큼 이전에 많은 시간이 걸렸는데, CockroachDB 서포트 엔지니어들과 논의하여 아예 TPC-C 벤치마크에 사용되는 것과 비슷한 설정값을 적용하여 많은 시간을 단축하기도 하였습니다.

이와 같은 과정을 거쳐 오전 8시 30분, 총 점검 시간 36시간 29분 만에 임시점검을 종료하게 되었습니다.

#요약

점검 경과를 요약하면 다음과 같은 내용이 되겠습니다.

쿠키런: 킹덤 런칭 이후 지속적인 이용자 증가로 인해 데이터베이스 저장장치 공간 부족 현상 가속화
안정적인 데이터베이스 운영을 위해 필요한 작업을 수행하려 했으나, 이 과정에 발생한 인적 오류로 인해 전체 데이터베이스 클러스터의 작동 중지
해결을 위해 데이터베이스 소스 코드와 기술문서 등 가용 자원을 총동원하여 노드에 퍼져있는 바이너리 형식의 데이터 파일을 모아 해독 가능한 형태로 변환할 수 있음을 확인
데이터베이스 소스 코드를 개량하고 데이터 분석용 분산 인프라를 활용해 이진 데이터 파일을 데이터베이스 복원에 사용할 수 있는 형태로 재가공.
- 이 과정에서 일부 데이터 유실에 대한 위험이 있기는 하였으나, 약간의 운과 게임 아키텍처의 특성을 활용해 모든 데이터 복원 및 재구축에 성공
복원해낸 데이터를 바탕으로 새로운 데이터베이스 클러스터를 구축하여 정합성 검증
서비스 오픈을 결정했으나, 미증유의 트래픽을 받아 다시금 서비스 품질 불안정 발생, 두번째 데이터베이스 클러스터도 서비스 수용 불가 상태
위 상황을 고려해 여러 설정을 추가 적용한 세 번째 데이터베이스 클러스터를 구축하여 게임 서비스를 최종 복구

#회고

회사 역사상 유래가 없었던 당시의 점검을 회고해보자면, 가장 먼저 사람의 실수로 시스템의 오류가 발생한 만큼 인프라 작업 시의 프로세스를 전면적으로 개선하였습니다. 프로덕션 인프라에 어떤 사소한 작업을 하더라도 반드시 2명 이상의 작업자가 참여해야 한다고 규칙을 개선했고, 작업 중 사용할 스크립트나 진행할 작업에 대한 시나리오를 엄격하게 작성하여 사전에 팀 내에 공유하고 리뷰를 받도록 하였습니다. 아무리 숙련되고 경험이 많은 작업자라고 하더라도 사람인 이상 실수를 할 수도 있으며, 이를 예방하기 위해서는 시스템을 갖추어야 한다고 생각했기 때문입니다.

아무리 회고해보아도 아슬아슬한 지점이 많았지만, 그럼에도 복구를 가능하게 했던 몇 가지 요인들이 있다고 생각합니다. 먼저 데브시스터즈에는 장애 대응에 대해 확고한 원칙이 이미 사전이 정립되어 있었고, 발생한 장애에 대해 분석하고 회고하는 문화가 있었습니다. 이 장애 대응 원칙에는 작업자 개인을 탓하는 것보다는 상황 해결을 위해 모두가 적극적으로 기여하고, 대응 과정을 상세히 기록으로 남겨서 동일한 유형의 장애를 예방할 수 있는 액션아이템을 설정하여야 한다고 되어 있습니다. 이번 경우에도 발생한 장애에 대해 숨김 없이 공유가 된 덕분에 해결 방안을 고안하는데 모두가 머리를 맞댈 수 있었습니다. 또, 다년간의 게임 운영 경험에서 이미 축적되어 있는 크고 작은 장애 경험이 풍부했고, 그 경험들이 기록으로 남아있었기 때문에 장애를 직접 경험하지 않은 구성원들도 대형 장애 상황에서 어떤 일을 수행해야 하는지 간접적으로나마 알고 있었습니다. 이런 문화적인 배경 덕분에 여러 가지 복구 전략을 시도해 볼 수 있었다고 생각합니다.

또 다른 요소로는 장애 해결에 필요한 인프라와 전문성이 모두 미리 갖추어져 있었고, 인프라 운영과 데이터 분석을 담당하는 팀들이 한 조직에 속해 있어 서로의 역량이 시너지를 내며 복구 시간을 획기적으로 단축할 수 있었습니다. 그러나 무엇보다 중요한 것으로 구성원들의 꺾이지 않는 마음을 꼽지 않을 수 없습니다. 오랜 시간동안 체력적, 정신적으로 한계에 부딪힌 상황 속에서도 모두가 최선을 다해 더 긴 장애로 이어지거나 데이터 유실이 발생하는 최악의 상황을 피할 수 있었습니다.

한 명의 엔지니어로서 솔직히 다시 기억을 떠올리기 싫은 사건이었습니다만, 일련의 과정을 거치면서 우리가 이 정도로 심각한 문제도 극복해낼 수 있는 팀이라는 것을 느끼는 순간이었습니다. 이 같은 문제를 숨기는 것이 아니라 널리 공유하는 문화가 전파되어야 업계 전체의 역량이 성장할 수 있다고 생각하여 꽤 긴 시간이 지났지만 글의 형태로 공유하게 되었습니다. 긴 글 읽어주셔서 감사드립니다. 하지만 저희 발표를 들으셨거나, 이 당시 킹덤을 플레이하고 계시던 분들은 다른 사건도 있었다는 것을 기억하고 계시겠죠? 이 다음에 있었던 이야기에도 많은 관심 가져주시면 감사하겠습니다.

덧1) CockroachDB 측에서도 안전장치의 필요성에 대해 공감하여 빠르게 개선해 주었습니다. (관련 PR)

덧2) 21.2 버전 이상의 CRDB에서는 Ballast 파일이 자동으로 생성되어, 저희가 진행하려던 작업을 진행할 필요가 더 이상 없습니다.

1: 이 대목을 읽으면 그러면 RAID는…? 이라는 질문을 하실 수도 있으실텐데, 런칭을 준비하며 막바지에 인스턴스 타입이 결정되는 바람에 RAID 설정에 대한 우선순위를 낮게 설정하고 작업하지 않았습니다. 돌이켜 생각해보면 아무런 설정도 하지 않았기 때문에 확률적으로 살아있는 스토리지가 있었다고도 할 수 있고, 반대로 RAID 설정을 했다면 Storage Pressure가 발생하지 않았다고도 할 수 있겠습니다. 제 의견으로는 RAID0 설정을 진행해두어 장시간 점검이 없었던 평행우주에서도, 당시 Replication Factor 등 용량 측면에서 비효율적인 설정들이 많았기 때문에 스토리지 압박은 시간 문제였을 것 같기는 합니다 😅

2: 킹덤 아키텍쳐와 관련된 자세한 기술적 배경은 권태국님의 NDC 발표를 참고하시면 좋겠습니다.

CockroachDB in Production

Tue, 13 Dec 2022 00:00:00 GMT

이 글과 관련된 다른 글 보기

쿠키런: 킹덤 런칭 회고 - DevOps 관점에서 본 쿠키런: 킹덤 런칭 회고
쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기 - 엔지니어 관점 기록한 개괄적인 장애 대응 과정과 회고
CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기 - CockroachDB의 소스코드를 참고하며 바이너리 파일로부터 데이터를 복구한 이야기
입사 첫날에 36시간 점검 경험하기 - 신규입사자의 관점에서 서술된 장애 대응 기록
쿠키런: 킹덤 AWS AZ 장애 아웃라인 - AWS AZ 장애로부터 서비스를 복구한 이야기
쿠키런: 킹덤 길드 업데이트 이후 서비스 이슈 되돌아보기 - 쿠키런: 킹덤에 길드 기능이 추가된 이후 발생한 서비스 이슈 회고

#Summary

세상에는 다양한 종류의 데이터베이스 소프트웨어가 존재합니다. 특히 이용자가 많은 모바일 게임의 메인 데이터베이스로 사용하려면 쓰기 위주의 (Write-Heavy) 워크로드에 적합해야 하고, 이용자가 급격히 늘어날 때 빠르게 확장할 수 있어야 합니다. 대표적으로 MySQL, PostgreSQL과 같은 전통적인 관계형 데이터베이스를 고려해볼 수도 있고, Couchbase나 MongoDB, Cassandra와 같은 문서형 분산 데이터베이스를 고려해볼 수도 있고, DynamoDB와 같은 관리형 데이터베이스를 고려해볼 수도 있습니다.

데브시스터즈에서는 <쿠키런 킹덤> 의 데이터베이스로 CockroachDB라는 데이터베이스를 운용하고 있습니다. 이 글에서는 CockroachDB의 여러 가지 고유한 특성을 알아보고, 왜 CockroachDB를 메인 데이터베이스로 선택했는지, 그리고 Production 서비스에서 CockroachDB를 운용하기 위해 어떤 점들을 주의하고 신경써야 하는지에 대해 다룹니다.

참고: 데브시스터즈 CockroachDB Case Study

#What is CockroachDB?

CockroachDB란 SQL 인터페이스를 지원하는 분산 데이터베이스입니다. 수평 확장이 가능하고, 다양한 종류의 물리적 장애에서 살아남을 수 있으며, 전 지구적인 스케일로 데이터베이스를 구축하고 관리할 수 있는 다양한 기능을 지원합니다. GitHub에 오픈소스로 공개되어 있고, 무료로 사용할 수 있으나 몇몇 기능은 엔터프라이즈 라이센스를 필요로 합니다.

“SQL 인터페이스를 지원하면서 수평 확장이 가능한 강력한 분산 데이터베이스” 라고 하면 Google Cloud의 Spanner를 떠올리시는 분들도 계실텐데요. 실제로 CockroachDB의 세 설립자는 모두 구글의 전 직원이었고, 구글에서 퇴사한 후 Spanner와 비슷한 시스템을 세상에 내놓고자 프로젝트를 시작했습니다. 그래서 사실 CockroachDB의 핵심적인 설계는 많은 부분에서 Spanner로부터 영감을 받았다고 볼 수 있습니다.

그렇지만 Spanner와 다른 부분들도 많습니다. 대표적으로, Spanner의 경우 트랜잭션 사이의 실행 순서를 엄격히 보장하기 위해 Google 데이터센터의 전용 하드웨어에 달려있는 원자 시계 (Atomic Clock) 를 활용한다고 알려져 있습니다. 하지만…. 저희를 포함해 대부분의 개발팀은 구글이 아니고, 전용 하드웨어도 원자 시계도 없죠 😅. CockroachDB의 경우 원자 시계를 사용하지 않는 (정확히는, 시간의 동기화에 의존하긴 하지만 원자 시계만큼의 정확도까지는 요구하지 않는) 알고리즘을 구현하여 소프트웨어적인 방법으로 같은 로직을 처리하고 있습니다.

그들은 왜 데이터베이스에 Cockroach (바퀴벌레) 라는 징그러운 이름을 붙였을까요? 왜냐하면 CockroachDB는 시스템에 크고 작은 문제가 생겼을 때 생존하고 스스로 회복하는 것 (Resiliency) 에 가장 큰 강점이 있기 때문입니다. 분산 시스템을 설계할 때에 가장 어려운 문제 중 하나가 바로 장애 상황에서 일관성이나 가용성을 최대한 유지하면서 복구해내는 것인데요. 특히 분산 데이터베이스 시스템의 경우 복구에 많은 시간이 걸리거나 많은 데이터가 소실되면 어플리케이션에 큰 영향을 끼칠 수 있습니다.

CockroachDB의 경우 디스크, 물리적 머신, 심지어 데이터 센터 단위의 장애가 생기더라도 생존할 수 있는 다양한 옵션을 제공하고 있습니다. 또한 문제 상황이 생기면 스스로 감지하고 사람의 개입 없이도 자동으로 서비스를 최대한 복구해냅니다. 실제로 CockroachDB를 운영하다보면 하드웨어 문제로 데이터베이스 인스턴스 중 하나가 꺼졌는데 서비스 지표에는 영향이 전혀 없고 조금 기다리면 인스턴스도 알아서 교체되어 있는 놀라운 경험을 하게 되기도 합니다.

생존과 자가 회복 외에도 CockroachDB에는 여러 개의 핵심적인 특성 (Killer Features) 이 있는데요. 그 중 저희가 주목했던 몇 가지를 소개합니다.

PostgreSQL Compatibility

PostgreSQL 프로토콜의 거의 대부분을 지원하기 때문에, 기존에 커뮤니티에 존재하던 다양한 DB 접속 라이브러리나 ORM 등을 거의 그대로 사용할 수 있습니다.

Serializable Transactions

SQL 표준에 정의되어 있는 트랜잭션 격리 수준 4단계 중 가장 강력한 SERIALIZABLE 격리를 모든 트랜잭션에서 사용하도록 되어 있습니다. 즉, 여러 개의 트랜잭션이 동시에 실행되어도 한 번에 하나씩 실행한 것과 동일한 결과를 보장합니다.

수평 확장성

데이터베이스 확장이 필요한 경우 노드를 추가로 확보하고 붙여주기만 하면 그대로 처리량과 용량을 늘릴 수 있습니다. 노드를 확장/축소하거나 교체할 때 별도의 서비스 중단이 필요하지 않고 무중단으로 작업할 수 있는 것 또한 강력한 강점입니다.

Multi-Region 클러스터 지원

전 세계를 대상으로 하는 어플리케이션의 경우 데이터베이스의 위치와 이용자의 위치 사이의 물리적 거리로 인해 응답 시간이 길어질 수 밖에 없는데요. 이것을 극복하기 위해 데이터베이스를 여러 개로 나누어 운영할 수도 있지만, 그러면 이제 그 데이터베이스들 사이의 싱크를 맞추는 일과 장애를 대비하는 일에 많은 공을 들여야 합니다.

CockroachDB에는 클러스터를 굳이 쪼개고 샤딩하지 않고도 하나의 거대한 클러스터를 여러 개의 리전에 걸쳐 운영할 수 있는 기능이 내장되어 있습니다. 이 기능을 활용하면 데이터베이스/테이블/row 단위로 메인 리전을 결정하고 최적화할 수 있게 됩니다.

#Why we chose CockroachDB?

데브시스터즈에서는 <쿠키런: 킹덤> 의 개발 초창기부터 CockroachDB를 염두에 두고 설계했습니다. 그 전까지 데브시스터즈에서는 주로 JSON 문서 기반의 데이터베이스를 사용했었고, 원하는 정도의 성능 기준은 충분히 충족할 수 있었습니다. 하지만 이러한 NoSQL의 경우 문제 발생 시 대응하기 위해서 상당한 노력이 필요했고, Transaction 구현을 위해 어플리케이션 개발 시 별도의 복잡한 로직을 구현해야 했습니다. 반면 CockroachDB는 RDBMS의 장점 (Transaction 지원) 과 NoSQL의 장점 (샤딩 없이 수평 확장 가능) 을 모두 가지고 있어 상당히 매력적인 포지션에 놓여 있었습니다.

그렇지만 당시에는 CockroachDB가 세상에 나온지 얼마 되지 않은 시점이었기 때문에 대규모 제품에 사용한 케이스가 거의 존재하지 않았고, 아직 검증되지 않은 데이터베이스를 사용하는 것은 백엔드 엔지니어 입장에서 매우 도전적인 일이었습니다. 다행히도 CockroachDB가 PostgreSQL 인터페이스를 지원했기 때문에, 추후 성능 테스트를 진행해서 원하는 성능과 안정성이 나오지 않을 경우 최소한의 수정을 거쳐 PostgreSQL과 호환되는 다른 DB로 빠르게 전환하는 것을 플랜 B로 두고 설계를 진행할 수 있었습니다.

이후 제품 개발 과정을 거쳐 런칭 준비에 들어서면서, 본격적으로 데이터베이스에 대한 검증을 시작했습니다. 당시 검토했던 최종 후보는 1. Amazon DynamoDB, 2. Amazon Aurora (PostgreSQL 호환), 3. CockroachDB 총 세 가지였습니다. 성능, 확장 가능성, 비용 등 주요 요인에 대해 세 가지 데이터베이스를 벤치마크해보았습니다.

#성능

로드를 소화하기에는 충분한, 비슷한 규모의 인프라를 기준으로 킹덤 서버의 특정 기능을 반복 수행하여 테스트를 진행했습니다. 다른 어플리케이션이나 다른 워크로드 수행시 충분히 양상이 달라질 수 있으므로 참고만 해주세요!

latency 중위값 (p50): CockroachDB = Aurora << DynamoDB
tail latency (p99): CockroachDB << Aurora = DynamoDB
Error Count: CockroachDB와 Aurora는 에러가 검출되지 않았고, DynamoDB에서 0.01% 정도의 에러 카운트 발생

중위 latency를 볼 때 세 엔진 모두 저희가 원하는 최소 성능은 만족시켰으나, 전반적인 분포로 볼 때에는 CockroachDB가 성능 면에서 가장 뛰어난 것으로 나타났습니다.

#확장 가능성

Aurora의 경우 가장 큰 인스턴스가 최대 96개의 vCPU를 제공하므로 확장에 한계가 있었습니다. 현재 실제 운용중인 쿠키런 킹덤 데이터베이스가 수백~수천 개 단위의 vCPU 코어를 사용하고 있음을 감안하면 (당시엔 몰랐지만) 선택할 수 있는 옵션이 아니었죠.

DynamoDB의 경우 내부적으로 자동으로 수평 확장이 발생하므로 이 부분에서는 이점을 가지고 있었습니다. 그러나 사용량에 따라 다이나믹하게 수평확장이 발생하므로 확장 시점을 컨트롤하기 어렵고, hot partition이 발생하지 않도록 신경써야 합니다.

CockroachDB의 경우 수평적 확장이 가능하므로, 필요한 만큼 인스턴스를 띄워 확장할 수 있었습니다. 다만 DynamoDB와 마찬가지로 hot partition이 발생하지 않도록 신경써야 합니다.

#비용

DynamoDB의 경우 OnDemand와 Provisioned 사이의 가격 차이가 크므로 1년 Provisioned 기준으로 대략적인 가격을 산정했습니다.

Aurora의 경우에도 1년 Reserved Instance 기준으로 가격을 산정했습니다.

CockroachDB의 경우 인스턴스 컴퓨팅 비용에 더해 라이센스 비용을 고려해야 했습니다. 물론 엔터프라이즈 라이센스 없이 오픈소스 버전으로 서비스하는것도 고려했지만, 상대적으로 새로운 엔진을 도입한다고 가정할 때 문제 상황 대처나 최적화 튜닝을 위해 CockroachLabs의 기술 지원이 꼭 필요하다는 판단을 내렸습니다. 실제로 서비스를 운영하면서 여러 가지 기술적으로 유용한 지원을 여러 번 받을 수 있었습니다.

전반적인 가격의 구체적인 비교는 사정상 자세하게 적기에는 어렵지만, 내부에서 계산해 본 결과 대체로 비슷하거나 CockroachDB의 가격이 (라이센스 비용을 포함해서) 조금 더 경쟁력 있는 것으로 나타났습니다.

종합적으로 비교해 본 결과 비용, 성능, 안정성, 확장성 등등 대부분의 지표에서 CockroachDB가 우위에 있었고, 최종적으로 킹덤에서 사용할 데이터베이스로 선정했습니다.

#CockroachDB Internals

어떤 데이터베이스나 분산 시스템을 사용하건 그것의 동작 방식을 어느 정도 파악해두는 것은 매우 중요한 일입니다. 물론 기본 설정으로 배포해두어도 일단 적당히 사용할 수는 있겠지만, 최적화와 문제 상황 분석 및 트러블슈팅에 있어서 한계가 있을 수 밖에 없습니다.

CockroachDB를 사용하기로 결정한 이후로 저희는 이 시스템의 동작 방식을 이해하는 데에 많은 시간과 노력을 쏟았는데요. 그 중 운용을 위해 반드시 알아야 하는 중요한 컨셉을 몇 가지 소개하고자 합니다.

#Key-Value Store

CockroachDB는 PostgreSQL 인터페이스를 사용해 데이터를 주고받기 때문에 관계형 데이터베이스처럼 보이지만, 사실 내부적으로는 분산 Key-Value 저장소로 구현되어 있습니다. SQL 쿼리문이 입력되면 이를 이에 맞는 Key-Value 연산으로 변환하여 수행 가능한 노드로 보낸 뒤 다시 결과를 취합하여 보여 주는 것이죠.

CockroachDB의 각 노드는 로컬 Key-Value 스토리지 엔진으로 Pebble 을 사용합니다. 초창기에는 RocksDB 를 엔진으로 사용 했지만, CockroachDB에 더 적합한 엔진을 사용하기 위해 RocksDB를 기반으로 직접 개발한 것이 Pebble 입니다(CockroachDB v20.2 버전부터 Pebble을 디폴트 엔진으로 사용하고 있습니다).

RocksDB나 Pebble 은 내부적으로 LSM tree (Log-Structured Merge tree) 구조를 사용하며, 디스크에는 SST (Sorted String Table) 포맷으로 저장합니다. 실제로 각 노드의 데이터 디렉토리에 들어가면 .sst 파일들이 존재하는 것을 확인할 수 있습니다. cockroach 바이너리에는 각종 디버그 툴이 포함되어 있는데, 그 중에서 sst 파일의 내용을 key-value 단위로 확인할 수 있는 커맨드들도 있습니다. (e.g. cockroach debug sst_dump)

#Range

큰 데이터베이스를 모두 Key-Value 형태로 저장하기 위해서는 적당한 크기로 나누어 저장해야 합니다. 기본적으로는 최대 512MiB 단위로 쪼개어 저장하는데, 이 단위를 Range 라고 부릅니다.

다시 말해서 CockroachDB의 각각의 노드는 여러 개의 Range를 저장하는 저장소이고, 하나의 Range에는 여러 개의 연속한 Key와 Value가 들어있으며, 여러 노드에 복제되어 있어 각각 복제본 (Replica)의 역할을 합니다.

아래 쿼리를 통해 어떤 키가 어느 range에 속하는지, 해당 range를 복제하고 있는 노드 목록은 무엇인지 등을 확인할 수 있습니다.

select * from crdb_internal.ranges_no_leases limit 10;

#Replication: Leaseholder, Raft Leader

CockroachDB는 각 range를 Replication factor 에 맞춰 여러 노드에 복제합니다. 이때 여러 노드로 분산된 환경에서 Read 와 Write 를 올바르게 처리하기 위해, 각 range 별로 Leaseholder, Raft Leader 를 하나씩 선출합니다.

Leaseholder는 해당 range에 대한 모든 읽기 요청을 처리하고 raft leader에게 쓰기 연산을 제안하는 (즉 해당 range에 대한 읽기/쓰기 연산을 최전선에서 담당하는) 노드입니다. Raft Leader는 해당 range에 대한 쓰기 연산이 항상 합의된 상태로 유지되도록 관리하는 노드입니다. 구조적으로 Leaseholder 와 Raft Leader 가 동일한 노드인 경우 쓰기 연산의 rtt가 줄어들기 때문에, CockroachDB는 가급적 이 둘을 같은 노드로 배정하려고 하지만 항상 그렇게 배정되지는 않을 수도 있습니다. 읽기, 쓰기 연산에서 각각의 역할에 대해서는 아래의 다이어그램을 통해 더 자세히 설명합니다.

이름에서 알 수 있듯 range 내에서의 합의에는 Raft consensus algorithm 을 사용합니다. 이 알고리즘은 과반 이상이 투표해야 합의가 이루어지는 알고리즘이므로, 특정 range 의 레플리카 중 과반 이상이 작동하지 않는 경우 해당 range 를 포함하는 모든 쿼리는 거부됩니다. 즉 CockroachDB는 floor(replication factor / 2) 만큼의 노드 장애 까지는 서비스 품질 저하 없이 수용하지만, 이후부터는 확률에 따라 (특정 range의 replication이 장애난 노드에 몰려 있을 확률) 일부 쿼리 (장애 range 를 포함하는 쿼리) 가 작동하지 않게 됩니다.

#Read Scenario

range에 대한 읽기 연산은 아래와 같이 행해집니다. r1, r2, r3 각각은 하나의 range를 의미합니다.

r3 내의 값을 읽으려는 요청이 클러스터에 도달합니다. 이때 CockroachDB 에서 사용자의 요청은 어떤 노드에 도달하더라도 상관 없습니다. 처음으로 요청을 받은 노드(이를 게이트웨이 노드라 합니다)는 해당 요청을 처리할 수 있는 적합한 노드에게 해당 요청을 라우팅해줍니다.
r3의 leaseholder는 Node 3 이므로, 게이트웨이 노드인 Node 2 는 이 요청을 Node 3 으로 전송합니다.
Node 3이 해당하는 데이터를 게이트웨이 노드에 전달합니다.
사용자에게 응답이 내려갑니다.

#Write Scenario

r1 내의 값을 업데이트하려는 요청이 클러스터에 도달합니다.
해당 요청은 r1의 leaseholder 인 Node 1 으로 전달됩니다.
r1 의 raft leader 또한 Node 1 이기에, Node 1이 즉시 쓰기 연산에 대한 합의를 다른 노드들에게 전파합니다.
Node 2 에게 ack 을 받습니다.
과반 이상이 확인하였으므로 (Node 1, Node 2) 즉시 게이트웨이 노드에 결과를 전달합니다.
사용자에게 응답이 내려갑니다.

#MVCC

CockroachDB는 데이터를 저장할 때 MVCC (Multi-Version Concurrency Control) 를 사용합니다.

모든 Key-Value 값은 한번 쓰이면 더이상 변경되지 않는 immutable 한 값입니다.
특정 Key에 대한 업데이트 연산은 동일 Key 에 대해 (더 이후의 타임스탬프를 갖는) 새로운 값을 추가하는 연산입니다.
특정 Key에 대한 삭제 연산은 해당 Key가 지워졌음을 표시하는 (이 마커를 tombstone 이라 합니다) 값을 추가하는 연산입니다.

이러한 특성을 이용해 읽기 쿼리 뒤에 AS OF SYSTEM TIME ... 을 붙여 과거 시간을 기준으로 읽기를 수행할 수 있습니다 (time travel query). 현재 진행되고 있는 트랜잭션과도 상관이 없기에, 이러한 time travel query 는 leaseholder 가 아닌 다른 레플리카에서 읽어도 상관이 없으며, 따라서 적절히 활용할 경우 leaseholder가 받는 읽기 부하를 완화할 수 있습니다.

즉, 어떤 키에 대한 데이터를 UPDATE 하면 예전 값이 사라지는 것이 아니라 MVCC에 의해 일정 시간동안 보존되게 됩니다. 따라서 INSERT 연산 보다 UPDATE 가 더 많은 경우 예상했던 것 보다 스토리지 사용량이 많을 수 있음을 유의해야 합니다. 같은 키를 가지는 오래 된 데이터는 시스템에 설정된 gc.ttlseconds 보다 오래 된 경우 sst compaction 과정에서 제거되는데, 이 설정의 기본값은 25시간입니다.

#Production 배포시 고려해야 할 사항

#Range Split

특정 range에 너무 많은 read나 write가 몰리면 병목이 발생하고 쿼리의 응답 속도가 느려질 수 있습니다. 이런 현상이 발생한 range를 hot range 혹은 hotspot 이라고 부릅니다. Hot range가 발생하거나 특정 range의 크기가 너무 커지면 CockroachDB가 자동으로 range를 쪼개어 부하를 분산하게 됩니다 (range split). 반대로 인접한 여러 개의 range가 너무 작거나 쿼리가 별로 발생하지 않는다면 range를 합치게 됩니다 (range merge).

Range를 합치거나 나누는 과정은 보통 CockroachDB에 의해 자동으로 이루어집니다. 그러나 서비스 런칭 혹은 특정 피쳐 배포 초창기에 수많은 INSERT 문이 발생하게 되면, 자동 split 이 INSERT 속도를 따라가지 못해 hot range가 발생할 수 있습니다. 특히 게임 서비스의 경우 런칭 직후나 패치 직후에 트래픽 피크가 발생하므로 서비스에 매우 큰 위험 요인이 될 수 있습니다.

이와 같이 테이블이 새로 생겼거나 새로운 패턴의 데이터가 폭발적으로 인입될 것이 예상되는 경우 range 범위를 미리 어느 정도 쪼개두는 것이 좋습니다. range를 수동으로 쪼개려면 다음과 같은 쿼리를 이용하면 됩니다.

ALTER TABLE members SPLIT AT VALUES ('AAAAA0000');
ALTER TABLE members SPLIT AT VALUES ('ABAAA0000');
...
ALTER TABLE members SPLIT AT VALUES ('ZYAAA0000');
ALTER TABLE members SPLIT AT VALUES ('ZZAAA0000');

ALTER TABLE members SCATTER;

#Hotspot 피하기

CockroachDB를 사용하기로 했다면 테이블을 설계할 때부터 데이터가 잘 분산되고 핫스팟이 생기지 않도록 고려할 필요가 있습니다. 가장 대표적으로 차이가 발생하는 부분이 Primary Key와 Index 입니다.

RDBMS에서는 auto_increment를 이용한 ID column이나 계속 증가하는 타임스탬프 등을 키로 쓰는 것이 보통 일반적입니다. 그러나 CockroachDB에서는 이렇게 계속 증가하는 column을 key로 활용하는 경우 항상 테이블의 마지막 range에서만 쓰기가 일어나고, 이것이 항상 핫스팟이 될 수 밖에 없습니다.

CockroachDB에서는 Table의 Primary Key로 UUID를 사용하거나 랜덤성이 있는 컬럼을 활용하는 등 최대한 잘 분산된 키를 사용할 것을 권장합니다. 여러 컬럼을 함께 Primary Key로 묶어서 사용하는 경우 키의 분산에 더 도움을 줄 수도 있습니다.

만약 꼭 증가하는 int column을 키로 써야만 한다면 hash-sharded index를 사용할 수 있습니다. 단 hash-sharded index 를 사용하는 경우 range query (>, <) 를 사용할 때 풀스캔이 발생함을 염두에 두어야 합니다.

#Locality 설정하기

Multi-region 혹은 Multi-az 등 여러 개의 데이터센터에 걸쳐 CockroachDB를 배포하는 경우, --locality 플래그를 설정하여 각 range를 분산할 때 지리적 특성을 고려하도록 할 수 있습니다.

예를 들어 replication factor가 3 이고 세 개의 AZ (혹은 데이터 센터) 에 걸쳐 DB를 배포한 경우를 가정해보겠습니다. 만약 locality 플래그를 따로 설정하지 않은 상태에서 데이터 센터 장애가 발생한 경우, 특정 range의 replica가 모두 한 데이터 센터에 존재해서 결국 데이터가 소실될 가능성이 충분히 존재합니다.

반면 locality 플래그를 설정하게 되면 각 range 별로 3개의 레플리카가 전부 다른 az에 분배되도록 분산해줍니다. 이렇게 설정하면 특정 데이터 센터에 문제가 생겨도 나머지 두개의 데이터 센터에 2개의 replica가 남아 있는 것이 보장되므로 데이터 손실도 없고 서비스도 문제 없이 제공할 수 있게 됩니다.

쿠키런: 킹덤에서 CockroachDB 를 처음에 운영할 때에는 locality 플래그를 설정하지 않았는데, 실제로 이 부분으로 인해 장애를 겪은 적도 있었습니다. 이 부분에 대한 자세한 이야기는 NDC22 - 쿠키런: 킹덤, 총 56시간의 긴급 점검 회고 - 그때 그 명검은 왜 뽑아야 했는가 라는 세션에서 다룬 바 있으니 관심 있으신 독자분께서는 꼭 확인해보세요!

#Conclusion

CockroachDB는 수평 확장이 가능하고 다양한 장애 시나리오에서도 생존할 수 있는 강력한 분산 데이터베이스 소프트웨어입니다. 데브시스터즈에서는 쿠키런: 킹덤 에서의 도입을 시작으로, 다양한 내/외부 프로젝트에서 CockroachDB를 메인 데이터베이스로서 검토하고 도입하고 있습니다.

만약 CockroachDB를 검토하고 계시거나 새 프로젝트에 사용할 멋진 데이터베이스를 찾고 있는 분이 계시다면, 이 글을 읽으신 후 꼭 CockroachDB를 한 번 활용해보시길 다시 한 번 권해드립니다.

감사합니다.

#읽을 거리 / 볼 거리

Spanner: Google’s Globally-Distributed Database

https://www.cockroachlabs.com/docs/v20.2/topology-patterns.html

Devsisters: Uptime as a core requirement for online gaming application

쿠키런: 킹덤, 총 56시간의 긴급 점검 회고 - 그때 그 명검은 왜 뽑아야 했는가

쿠키런: 킹덤 런칭 회고

Wed, 23 Nov 2022 00:00:00 GMT

이 글과 관련된 다른 글 보기

CockroachDB in Production - CockroachDB에 대한 소개와 킹덤에서 CockroachDB를 사용한 이유 설명
쿠키런: 킹덤 데이터베이스 스토리지 레이어 복원기 - 엔지니어 관점 기록한 개괄적인 장애 대응 과정과 회고
CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기 - CockroachDB의 소스코드를 참고하며 바이너리 파일로부터 데이터를 복구한 이야기
입사 첫날에 36시간 점검 경험하기 - 신규입사자의 관점에서 서술된 장애 대응 기록
쿠키런: 킹덤 AWS AZ 장애 아웃라인 - AWS AZ 장애로부터 서비스를 복구한 이야기
쿠키런: 킹덤 길드 업데이트 이후 서비스 이슈 되돌아보기 - 쿠키런: 킹덤에 길드 기능이 추가된 이후 발생한 서비스 이슈 회고

안녕하세요, 저는 데브시스터즈 서비스기술그룹 인프라셀에서 데브옵스 엔지니어로 일하고 있는 이창원입니다. 저희 팀은 데브시스터즈에서 제공하고 있는 모든 게임의 Ops와 기술적 결정에 깊게 관여하고 있습니다. 작년 저희 팀의 가장 큰 미션은 쿠키런: 킹덤을 런칭하고 안정적으로 운영하는 체계를 구축하는 것이었는데요. 당시 어떤 과정을 거쳐 쿠키런: 킹덤이 여러분께 전달되었지를 공유드리고, 이어지는 글들에서 엔지니어로서 특별히 기억에 남는 주요 사건들에 대해 전해드리고자 합니다.

이 글의 내용은 박새미님과 NDC22에서 공동 발표한 쿠키런: 킹덤, 총 56시간의 긴급 점검 회고 - 그때 그 명검은 왜 뽑아야 했는가 세션에서 다뤄진 바 있습니다. 다만, 아무래도 발표는 시간 제한을 고려해야 하는 사정이 있다보니 자세한 정보를 담지 못했다는 아쉬움이 남아 글의 형식으로 다시 한 번 풀게 되었습니다. 보다 생동감 있는 짧은(?) 버전으로 일련의 이야기를 접하고자 하는 분들은 발표 영상을 보시는 것을 권해드립니다.

#Step 1. 기술환경질의서: 게임 스튜디오와의 첫 소통

데브시스터즈 퍼블리싱을 결정하면 가장 먼저 “기술환경질의서”를 바탕으로 게임 스튜디오에서 선택한 기술스택과 아키텍쳐를 리뷰하게 됩니다. 이 때가 개발 스튜디오의 기술적 실무진들과 게임 Ops를 주로 담당하는 저희 팀이 공식적으로 대면하는 첫 자리입니다. 게임의 기술 스택에 대해서도 이야기를 나누고, 각각의 컴포넌트와 아키텍쳐를 살펴보며 운영 관점에서 취약한 구조 또는 최적화할 여지는 없는지 Scalability와 Resiliency 관점에서 면밀히 살펴보고 개선점이 있다면 함께 보완합니다.

기술환경질의서의 일부 항목과 초창기 쿠키런: 킹덤 아키텍쳐를 바탕으로 서술된 답변.
데브시스터즈에서는 효율적인 기술 자문을 위해 게임 서비스를 제작할 때 반드시 고려해야 하는 문제들을 기술환경질의서로 정리해두었습니다.

쿠키런: 킹덤 프로젝트의 기술질의서를 바탕으로 데브옵스 조직인 저희 인프라셀에서 파악한 리스크 포인트는 크게 두 가지였습니다. 첫번째는 팀에서 처음 운영해보는 Stateful 서버라는 것입니다. 이 당시의 인프라셀은 이미 쿠키런 For Kakao, 쿠키런: 오븐브레이크, 쿠키워즈, 쿠키런: 퍼즐 월드, 그리고 파티파티 데코플레이까지 총 5개의 모바일 게임에 대한 런칭 경험을 보유한 팀이었습니다. 그러나 이 게임들은 모두 Stateless 서버구조를 차용하였기 때문에 여기서 쌓은 노하우를 쿠키런: 킹덤 런칭에 그대로 적용하기에는 무리가 있었습니다. 저희 팀에서는 이 질의서를 바탕으로 스튜디오 킹덤의 서버 개발자들과 지속적으로 교류하며 Stateful 서버 구조, Akka 클러스터에 대한 이해도를 높였습니다. 또한 클라우드 환경에서 Stateful 서버를 운영하기 위해 필요한 제반 기술들을 연구하여 준비해두었습니다.

쿠키런: 킹덤은 데브시스터즈 최초로 수평확장 가능한 분산 RDBMS인 CockroachDB를
메인 데이터베이스로 채택하였습니다. (쿠키런: 킹덤의 CockroachDB 케이스 스터디)

두번째 리스크 포인트는 데브시스터즈에서 기존까지 사용해본 적 없었던 새로운 데이터베이스인 CockroachDB를 쿠키런 킹덤에서 사용하였다는 것입니다. 쿠키런: 킹덤에서 채택한 CockroachDB는 전통적인 RDBMS와 NoSQL의 장점을 접목한 분산 NewSQL 데이터베이스로, 데브시스터즈에서 사용하던 Couchbase, MySQL 등과는 완전히 다른 특성을 가지고 있습니다. 게임 서비스에서 데이터베이스는 사용자의 추억과 노력이 담겨 있으므로 당연히 가장 안정적이어야 하며, 팀의 경험을 바탕으로 가장 보수적으로 접근하는 것이 일반적입니다. 새로운 데이터베이스의 안정성을 담보하기 위해 데브옵스 엔지니어들은 CockroachDB의 설계와 동작에 초점을 두어 심도 깊은 스터디를 진행했고, 이를 바탕으로 클라우드 환경에서 Cloud-Native 철학과도 맞는 운영 방법을 고안하였습니다.

이 시리즈물은 CockroachDB와 깊은 연관이 있는데, 앞으로의 이야기를 이해하시는데 도움이 되게끔 당시 스터디했던 자료를 엮어 기술블로그 글로 작성해 두었습니다. 데브시스터즈가 CockroachDB를 선택하게 된 과정에 대해 궁금하시다면 이 글(CockroachDB in Production)을 읽으시는 것을 권해드립니다.

#Step 2. 여러 개의 게임을 안정적으로 서비스하기: Kubernetes 인프라 구축의 여정

게임 스튜디오에서 희망하는 아키텍쳐에 대해 공유를 받았다면, 그 다음에 풀어야 할 숙제는 이를 어떤 추상화 단계에서 구축할 것인지 결정하는 일입니다. 데브시스터즈에서는 2019년에 이미 향후 출시되는 모든 게임을 Kubernetes 환경에서 운영하기로 결정했습니다. 이러한 결정의 배경에는 2014년 처음 Kubernetes R&D를 시작하여 2016년부터 게임 개발용 플랫폼으로 지속적으로 사용해오고 있던 경험이 크게 뒷받침되었다고 할 수 있는데요. 게임을 퍼블리싱하는 입장에서 Kubernetes를 사용하면 다양한 아키텍쳐와 컴포넌트를 가진 여러 개의 게임을 비슷한 방식으로 배포하고 운영할 수 있는 장점이 있습니다. 지금 시점에서야 Kubernetes를 프로덕션 서비스에 활용하고 있는 사례들이 많이 있지만, 그 당시에는 아직 Kubernetes의 안정성에 대해 의심스러운 눈길이 많았습니다. 이 부분을 검증하기 위해 저희는 AWS EC2 인스턴스 기반 아키텍쳐로 짜여져 잘 운영 중이던 쿠키런 for Kakao를 2019년 Kubernetes 환경으로 이전하였습니다. 결과적으로 모든 컴포넌트를 최소한의 영향으로 이전하는데 성공하여 인프라 운영에 필요한 기본적인 구성을 EC2와 동일한 안정성 수준에서 Kubernetes 위에서도 구성할 수 있다는 사실을 확인했습니다.

안녕! 용감한 쿠키들(현 쿠키런: 퍼즐월드)은 데브시스터즈 게임 중 최초로 완전히 Kubernetes에서 배포할 것을 염두에 두고 런칭하였습니다.

이 경험을 바탕으로 2020년 1월에는 쿠키런: 퍼즐월드(당시 안녕! 용감한 쿠키들)를 런칭했습니다. 저희에게 쿠키런: 퍼즐월드는 인프라 컴포넌트와 배포 방법을 선택할 때부터 Kubernetes 환경을 고려한 최초의 프로젝트로써 일종의 De facto 패턴을 정립한 것에 의의가 있습니다. 기존에는 AWS EC2과 Route53, LoadBalancer를 사용하였다면 Kubernetes 리소스와 externalDNS, Envoy, Istio를 사용하는 식으로 패러다임이 달라졌고, 배포 방법의 경우 과거에는 Terraform과 Spinnaker를 사용하였다면 그에 더해 Helm과 ArgoCD를 추가로 사용하여 Kubernetes 환경에 보다 적합한 방향으로 확장하였습니다. 또 모니터링 관점에서도 Kubernetes 클러스터 내부에서 발생하는 메트릭 역시 추적이 필요했기에 Prometheus와 Thanos를 도입했습니다. 데브시스터즈의 프로덕션 Kubernetes 사용을 향한 여정과 그 과정에 풀어야 했던 고민들은 저희 팀 용찬호님께서 NDC21에서 발표한 게임 서버를 품은 쿠버네티스 발표에 보다 자세히 담겨 있습니다.

쿠키런: 킹덤은 2021년 1월에 런칭되었으므로 안녕! 용감한 쿠키들 런칭 이후로 딱 1년 간의 텀이 있었습니다. 사업적 관점에서도 쿠키런: 킹덤은 안녕! 용감한 쿠키들보다 더 넓은 지역의 더 많은 유저들에게 다가가고자 하였기 때문에 저희가 추가적으로 신경써야 할 부분도 많아졌습니다. 더 넓어진 서비스 지역을 고려하여 AWS Global Accelerator를 도입하여 Istio Service Mesh와 연결하기도 하였고, 더 커진 서비스 규모에 발맞추어 Kubernetes 워커 그룹을 구성할 때 Multi-AZ를 필수적으로 활용하기도 하였습니다. 이 기간 인프라셀에서 진행한 업무는 한 마디로 팀의 내실을 다지며 다룰 수 있는 인프라 컴포넌트를 체계적으로 확장하는 작업이었다고 요약할 수 있겠습니다.

#Step 3. 터지지 않는 서비스 인프라 구축하기: 적절한 예측과 부하 테스트

이제 남은 작업은 어떠한 규모의 트래픽이 들어와도 터지지 않는 서비스 인프라를 구축하는 일입니다. 앞선 절차에서 기술환경질의서를 통해 인프라 규모가 확장될 때 문제가 될 수 있는 부분들을 체크하여 개선해두었으므로 사실 비용을 최대한 끌어다 쓰면 터지지 않는 인프라를 구축할 수는 있을 것입니다. 하지만 오버프로비저닝 된 서버가 일하지 않고 있는 모습을 보는 것은 효율을 중시하는 한 명의 엔지니어로서 눈 뜨고 볼 수 없는 일입니다. 즉 너무 많지도, 너무 적지도 않은 규모의 인프라를 구축해 비용의 낭비를 최대한 줄이면서 안정적인 인프라를 구축하는 것이 중요합니다. 사용자 경험에는 영향을 주지 않으면서 서버는 효율적으로 일하는 규모의 인프라를 산정하기 위해서는 두 가지 정보가 필요한데요, 바로 사용자가 게임 내에서 여러 가지 활동을 할 때 우리 서버에 어느 정도의 부하가 발생하는지 파악하는 일과 우리 유저의 규모가 어느 정도일지에 대한 예상치입니다. 두 가지 모두 실제 서비스를 시작하기 전에는 제대로 알기 어렵지만 역설적으로 비용 효율적으로 안정적인 서비스를 제공하기 위해서는 정식 서비스를 시작하기 전에 반드시 알아야 합니다. 따라서 과거의 경험과 현재의 상황을 바탕으로 하여 적절히 예측할 수 밖에 없었습니다.

실제 서비스를 시작하기 전에는 알 수 없는 정보들이지만 역설적으로 실제 서비스를 시작하기 전에 알아야 합니다. (이미지 출처: DALL-E 생성)

마침 런칭 인프라 규모를 산정하려고 고민할 즈음 전사 플레이 테스트를 진행하게 되었습니다. 이 테스트의 목적은 초기 경험에 대한 피드백을 수집하고 밸런스 수치를 최종 확정하기 위함이었는데요. 저희에게는 인프라에 발생하는 부하 패턴을 관측할 수 있는 소중한 기회였습니다. 사용자층에 따라 선호하는 게임 플레이 패턴이 다양할 수 있는데, 데브시스터즈의 전사 구성원이라면 그래도 어느 정도 평균성을 가져갈 수 있는 집단이기도 하고요.

저희는 전사 테스트 기간 동안 수집한 데이터를 시간별 window로 나누어, 특정 시간에 발생한 총 요청 수와 활성 사용자(AU)를 추출하였습니다. window의 크기를 충분히 작게 선택하면 동시 접속자(CCU)가 되겠지만, 테스트 유저 수의 모수가 충분히 크지는 않으므로 적절한 대표값을 취해 단위 사용자가 발생시키는 대략적인 초당 요청 수를 근사하였습니다. 이 값은 게임의 특성에 따라, 또는 사용자의 플레이 패턴에 따라 크게 달라질 수 있는데, 아주 대략적으로 우리 게임을 플레이하는 유저층의 특성을 정의했다고도 할 수 있겠습니다. 사용자의 요청 중에는 으레 무거운 요청도 있고, 가벼운 요청도 있으므로 그렇게 단순하게 근사하는 것은 어렵지 않느냐고 궁금증을 가지실 수도 있는데요. 쿠키런: 킹덤은 다행히도 이벤트 소싱 패턴을 사용하였기 때문에 대부분의 요청에 발생하는 오버헤드가 평이한 편이어서 많은 계산을 단순화해도 큰 문제가 없었습니다. (이벤트 소싱과 쿠키런: 킹덤의 아키텍쳐와 관련된 내용은 권태국님의 NDC21 발표 〈쿠키런: 킹덤〉 서버 아키텍처 뜯어먹기!를 참고해주세요.)

시기적절한 사내 테스트를 통해 서버에 발생할 부하 패턴을 파악할 수 있었으니 이제 남은 일은 사용자의 규모를 예측하는 일입니다. 여기에는 마케팅 목표와 사전예약자 모객 현황을 모니터링하며 다소 감각적으로 설정하였습니다. 또 이 숫자는 기대와 현실 그 사이 어딘가에 존재는 목표치에 가까우므로 만일에 대비해 2~3배의 충분한 버퍼를 두었습니다. 이제 단위 사용자에 대한 초당 요청 수(RPS)를 근사해내었고 목표로 하는 사용자 규모 또한 예측하였으므로 이 두 숫자를 곱하면 목표 RPS를 설정할 수 있습니다. 물론 이 과정이 수학적으로 엄밀하다고 말할 수는 없겠지만, 그래도 인프라 규모를 산정하기 위한 어느 정도의 기준치를 설정하였으니 소기의 목적은 충분히 달성했습니다. 남은 일은 실제로 쿠키런: 킹덤 아키텍쳐의 각 컴포넌트를 성능적으로 고려하여 이 목표 RPS를 문제 없이 소화하면서 비용 측면에서 가장 효율적인 인스턴스 타입과 사이즈의 조합을 찾는 일이고, 이 조합을 확실하게 검증하기 위해서는 부하 테스트가 필요합니다.

기록을 찾아보니 가장 최선의 조합을 찾기 위해서 인프라셀에서는 총 79회의 부하 테스트를 진행하였습니다. 부하 테스트 스크립트를 작성하여 Load Injector를 만들었는데, 최종적으로 목표로 설정된 부하 수준은 단일 머신에서 물리적으로 만들어낼 수 있는 한계를 넘어서는 수준이었기 때문에 별도 Kubernetes 클러스터에서 fleet을 구성해 부하를 발생시켰습니다. 과학적 방법에 따라 같은 테스트를 조건만 바꾸어가며 개선여부를 검증하는 작업인지라 엔지니어의 손과 시간이 많이 소요되는 고된 작업이었지만, 안정적인 서비스를 효율적으로 제공해야 한다는 엔지니어의 사명의식으로 작업에 매진하였고 결국 만족할 수 있는 검증된 결과를 얻어내었습니다.

광기와 좌절의 부하 테스트. 가장 적절한 조합을 찾기 위한 실험과 검증의 반복되는 사이클입니다.

런칭을 준비하며 야심차게 준비하였지만 일정 상의 이유로 진행하지 못한 작업으로는 서비스 공방전이 있습니다. 서비스 공방전이란 어떤 시스템이나 프로세스의 실패 사례를 가장하는 작업으로, AWS GameDay에서 모티브를 얻어 기획하였습니다. 유저들을 대상으로 하는 실제 서비스를 개시하기 전에 모의 서비스를 운영하며, 공격 측에서는 실제로 일어날 법한 여러 장애 시나리오를 준비하여 발생시키고, 방어 측에서는 이러한 장애 상황이 서비스에 영향을 미치는지 확인하며 필요한 경우 서비스 장애를 복구하는 연습을 하는 것이 의도였습니다. 서비스 장애의 원인은 매우 다양하고, 복구 과정에는 생각보다 많고 다양한 직군에 속한 사람들의 협업이 필요합니다. 마치 우리가 재난 대피 훈련을 하듯, 뜻밖의 상황을 마주했을 때 각자 맡은 역할에 따라 어떤 행동을 해야하는지 경험을 통해 체득하고 체계를 잡아나가는 과정...으로 의도했습니다만 어쩄든 실제로 진행하지 못해 아쉬움이 남습니다. 언젠가 다음 서비스를 런칭할 때는 서비스 공방전을 진행해본 소회 또한 공유드릴 수 있으면 좋겠습니다.

#Final Step. 대망의 런칭과 모니터링

바쁘게 준비하였던 대망의 런칭일은 하루가 다르게 다가왔고, 2021년 1월 21일 쿠키런: 킹덤을 드디어 유저 분들께 선보일 수 있게 되었습니다. 지금까지도 이미 과할 정도로 열심히 일했지만 사실 런칭 이후에도 데브옵스 엔지니어들은 긴장을 풀 수 없습니다. 열심히 준비했음에도 문제는 얼마든지 발생할 수 있고, 만에 하나라도 무언가 문제가 생긴다면 최대한 빠르게 해결할 수 있어야 하니까요. 일반적으로 게임은 그 특성상 평일보다 주말에, 낮 시간대 보다 저녁 시간대에 활성 사용자 수가 더 많습니다. 또, 쿠키런: 킹덤은 게임 설계 상 소원나무와 같이 컨텐츠 일간 보상 획득량 제한이 해제되는 자정에 평소의 2~3배에 달하는 피크가 발생합니다. 따라서 저희는 런칭 후 첫 주말을 보내며 늦은 시간까지도 미리 구성해 둔 모니터링 대시보드를 살피며 리소스 사용량 등 주요 지표에 이상이 없는지 관찰하고 있었습니다.

앞서 들인 여러 노력 덕분인지 런칭 후 첫 주말까지도 쿠키런: 킹덤은 안정적으로 순항하고 있었습니다. 또 인프라의 주요 리소스 사용량도 정확히 설계한 범위에서 머무르는 것을 확인할 수 있었는데, 치밀하게 계산하고 공들여 테스트한 결과가 맞아떨어져 뿌듯했던 기억이 납니다. 어쨌든 이런 일도 있을 수 있다고 사전에 예상하기도 했었고 뭐가 됐든 숫자가 맞으니 기분은 좋았습니다.

단조 증가 하고 있는 DAU와 줄어들 기미 없이 차오르는 데이터베이스 스토리지 사용량.

이렇게 좋은 경험만 남은 런칭 회고가 되었다면 좋았으련만, 현실은 그렇지 않았습니다. 런칭 후 첫 72시간 동안 유저 수가 단조증가 하고 있었는데요. 서비스 관점에서는 당연히 너무 좋은 일이지만, Ops 관점에서 저희는 두려움에 떨고 있었습니다. 정상적인 경우라면 데이터베이스 스토리지 사용량이 일정 범위에서 안정화되어야 하는데, 저희가 상정한 수치를 한참 지났음에도 추세에 꺾임 없이 증가하고 있었기 때문입니다. 주말 동안의 상승추세를 월요일 출근시간에 그대로 적용하여 계산해보니 데이터베이스 용량이 한계치에 다다를 때까지 약 36시간이 남아있는 것으로 계산되었다는 복선과 함께 쿠키런: 킹덤의 런칭을 준비했던 이야기는 마무리하도록 하겠습니다.

Scala for Game Server Development

Mon, 24 Oct 2022 00:00:00 GMT

알림: 한국어로 번역된 글을 보시려면 여기를 클릭하세요.

At Studio Kingdom, we use the Scala programming language to bring our hit game CookieRun: Kingdom to life. Scala is the language used for developing the game servers. Even though it is not the most popular language out there, we think that it’s a perfect fit for us and game server development in general. Let’s see why.

In this article, we will discuss several aspects of game development where Scala shines particularly:

Game Logic correctness is very important. There is nothing worse for a player than seeing their efforts wasted by a programming bug. Depending on the game, this logic can be particularly large and complex.
Games are fast-evolving, and players are always eager for new features. That means the game server codebase needs to constantly grow and evolve. Being able to bring features at a steady pace is primordial in order to stay on top.
Designing a multi-player game means dealing with concurrency and scaling issues. Game servers will receive a lot of concurrent requests, some of them dealing with the same entities.

#Game logic correctness

#The Power of types

Scala is a statically-typed language, which means that types are defined and known at compile-time. This prevents a whole range of runtime errors common with dynamically-typed languages (such as Javascript’s TypeError). But compared to other statically-typed languages, Scala uses types to express a lot of different things.

A simple example of that is the type Option[A] that is used to represent an optional value of type A. Rather than returning A that can be null and add the proper null-handling logic everywhere at the risk of missing some places, the idiomatic Scala way is to return Option[A]. That forces the developer to always handle the case where A is missing, using pattern matching or functions such as getOrElse or fold.

// this returns Option[GnomeResearchLevel]
val currentLevel = getGnomeResearchLevel(researchDataId)

// we have to handle the case where there is no current level
// in this case, we take the initial level
val nextLevel = currentLevel.map(_.up).getOrElse(GnomeResearchLevel.initial)

We push this idea even further by using refined types to add constraints to the values types can have. For example, a “Kingdom Level” is an integer that can only be 1 or more. Instead of simply using Int, we use type PosInt that enforces that the value is positive. We know for sure that the value will never be 0, so we don’t need to handle that case or to be careful with things like division by 0.

type PosInt = Int Refined Positive // alias for a positive Int

val a: PosInt = 1
val b: PosInt = 0 // will fail to compile

The compiler is able to detect if static values are valid or not. For values coming from the client, an error will be raised immediately after parsing the client request if a value doesn’t respect the type constraint.

Using PosInt is great, but if a “Cookie Level” is also a PosInt, there is a risk that we pass the wrong level to a function. To avoid that, we use a newtype, which is basically a wrapper around our PosInt to give it a special meaning.

@newtype case class KingdomLevel(value: PosInt)

def receiveKingdomLevelRewards(level: KingdomLevel): List[Reward]

Now, the compiler will enforce that when we call receiveKingdomLevelReward, we pass a KindomLevel and nothing else.

In summary, by using types that describe precisely what they hold, we avoid a whole range of silly bugs and improve the quality of our code.

#Types as documentation

Just like returning an Option tells you that a function may or may not return a result, we use types that describe the kind of computation that a function runs. Here are a few examples:

Option[A]: a function that may or may not return a result of type A. It does not have any side effect.
Either[E, A]: a function that may either fail with an E or succeed with an A. It does not have any side effect.
ZIO[R, E, A]: a function that requires an environment R and may either fail with an E or succeed with an A. It may have some side effects (such as I/O). It is equivalent to R => Either[E, A] + the notion of side-effecting code.
ZPure[W, S1, S2, R, E, A]: a function that requires an environment R and an initial state S1 and may either fail with an E or succeed with an updated state S2 and an A along with a log with entries of type W. It does not have any side effect. It is equivalent to (R, S1) => (List[W], Either[E, (S2, A)]).

We use these various types to reflect exactly what a function is doing. You may have noticed that there are a lot of type parameters. But in practice we use type aliases to make it much shorter and convenient. Here are a few examples.

// a function that increments a metric
// the return type means it is side-effecting, and can never fail
def incrementInFlightMessagesMetric: UIO[Unit]

// a function that converts protobuf data into kingdom level
// the return type means that it may fail with a non-empty list of errors
// EitherNel[E, A] = Either[NonEmptyList[E], A]
def extractKingdomLevel(raw: Protos): EitherNel[ExtractionError, KingdomLevel]

// a function that returns the current pvp (a.k.a. "Kingdom Arena" in the game) state of the user
// the return type means it may access the user state but not modify it
def getCurrentPvpState: KingdomReader[Pvp]

Not only do these types enforce the behavior of a function, but they give you a precise idea of what a function is doing just by reading its type signature. All possible errors are clearly declared in return types (as well as the absence of error, which is just as useful), so we are never surprised by an exception thrown unexpectedly. The same goes with side effects.

#Make your own DSL

We’ve seen a few examples where we use types to constrain what a value can be or what a function can do, and rely on the compiler to catch any programming mistake early on. We can go even further and make the whole code constrained to only allow “valid” operations. We do that by creating custom DSLs for specific operations. Because Scala is both powerful and very concise, it excels at creating sub-languages. You can push it pretty far by making the code read almost like a spec document.

Without going that far, creating a DSL is useful when you want to restrict some parts of your code to only a small subset of operations. Let’s see an example: in our game, we support transactions between multiple entities. That means we can send commands to two different users (or a user and a guild), and commit all changes only if both commands are handled successfully.

We created a small DSL for transactions, with only the following operations:

identify an entity by ID: kingdom(userId) , guild(guildId)
send a command to an entity: entity ! command
combine sending operations: >>> for sequential, &&& for parallel

We can then write simple transactions like this:

transaction { context =>
  (kingdom(context.userId) ! SendFriendRequest(friendId)) &&&
    (kingdom(friendId) ! ReceiveFriendRequest(context.userId))
}

The transaction block defines where our DSL can be used. We won’t be able to use “normal code” within the boundaries of this block, but only what our DSL allows. It gives us access to a context that contains information about the current user. We will then send SendFriendRequest to the current user (that will check that this user is allowed to send a friend request, and save the pending request), and ReceiveFriendRequest to the other user (which will save the received request). These 2 operations will be done in parallel, and if any one of those 2 fail, nothing will be persisted.

This little transaction system does not support other types of operations. If we tried to persist something to Redis or Kafka within the transaction block, it wouldn’t be rollbacked in case of error. But because we use a custom DSL, it is actually impossible to call that kind of code (we would get a compiler error), because we are restricted by our DSL operations.

Most of our business logic is implemented using a DSL whose basic operations are:

succeed with a result
fail with a ValidationError
access the environment (that is a large object containing all the game configuration: the list of characters, levels, events, etc)
access the user state
lift an event (we use event sourcing), which will automatically update the user state

Thanks to this limited set of operations, it is impossible to do something unexpected in the middle of our business logic.

#Evolving fast

#Focus on what’s important

As we’ve just seen, writing DSLs constrain our code to a smaller subset of valid operations. It has another huge benefit, combined with the conciseness of Scala: it makes the code super short and readable.

Creating a DSL is a good way to hide the complexity of our program to focus on what really matters which is the business logic. Considering our transaction example above, it actually involves complex low-level code. We need to locate and send messages to entities that may be hosted on different nodes, using a particular messaging protocol. The persistence layer also needs to combine all writing operations into a single transaction that can be committed or rollbacked, communicating with an actual database. But we don’t want to care about any of this when we write our business logic.

The general idea behind this is to separate the “technical” layers from the business logic so that both of them can be implemented and tested entirely separately. That allows implementing business logic, which represents the majority of the work of adding new features, without any kind of interference, which is much more efficient.

Here’s a simplified example of business logic function used when a user joins a guild: we get some metadata from the game configuration, get the guild state and check that the request is valid. On success, we lift an event to record the fact that this user joined the guild. Note how we don’t care about messaging protocols, persistence, transactions, locks or whatever technical challenges that actually exist under the hood.

val joinGuild: KingdomProgram[Unit] =
  for {
	metadata    <- inquireGuildMetadata
    requesterId <- inquireRequesterId
    memberCount <- getGuild(_.members.size)
    ()          <- assertThat(
                     memberCount < metadata.maxMemberCount,
                     ValidationError.GuildFull
                   )
    ()          <- liftEvent(GuildMemberJoined(requesterId))
  } yield ()

An interesting consequence of this is that it’s easy to onboard new developers to our team: because there are only a few operations available, they will be able to understand the DSL and start writing code easily, without necessarily understanding how the DSL is implemented. They can focus on learning about the domain rather than technical concepts.

#Death to boilerplate!

Implementing new features usually means writing a lot of code: exposing new APIs to the client, implementing the persistence layer, converting data types between different layers, etc. One thing Scala is great at is keeping that boilerplate to a minimum, thanks to a powerful macro engine and the ability to write compiler plugins.

As it is commonly done in many languages, we generate server code from protobuf file definitions. However we don’t use the generated code in our business logic, because this generated code doesn’t use our refined types and we sometimes use more convenient data types than the ones generated (collections are usually an area where the choice of data type is quite significant). It means that we need to convert the proto-generated objects that we receive from the client into our own. We are talking about thousands of objects, which could become a huge source of boilerplate. However, thanks to Scala macros, these transformations are done automatically for the most part, and we can verify it at compile-time!

All we have to do is make sure we have an instance of Transformer for each data type. A macro is used to generate a Transformer automatically between 2 classes, as long as their field names are matching and that we have a Transformer between each corresponding field types.

Let’s see an example. We have a protobuf type defined like this:

message CraftProduction {
  string id = 1;
  repeated int32 cookie_data_ids = 2;
  int32 completed_job_count = 3;
}

The generated code will look like this:

case class CraftProduction(
  id: String,
  cookieDataIds: Seq[Int],
  completedJobCount: Int
)

But our own class with “enhanced” types is more like this:

case class CraftProduction(
  id: ActivityId,
  participants: NonEmptyList[CookieDataId],
  completedJobCount: Int
)

All IDs use more specific types such as ActivityId or CookieDataId so we don’t mix them up, we also use a NonEmptyList because there must be at least one participant, and finally the cookieDataIds field is named differently because it makes more sense in the game server code.

We’ll need transformer for the following types:

a Transformer between String and ActivityId
a Transformer between Int and CookieDataId
a Transformer between Seq and NonEmptyList

Transformer for IDs are very simple and can be created in a generic way since IDs are just wrapper types. A Transformer between Seq and NonEmptyList is also simple, failing if the Seq is empty, otherwise wrapping it into a NonEmptyList. The last problem we have is that the field cookieDataIds was renamed into participants.

In this case, we can create a transformer like this:

implicit val transformer =
  Transformer
    .define[entities.CraftProduction, protobuf.CraftProduction]
    .withFieldRenamed(_.participants, _.cookieDataIds)
    .buildTransformer

The macro is able to convert all fields automatically, and since we defined a mapping between the participants field and the cookieDataIds field, it is able to generate a transformer. Most of the time, fields are named the same way so we don’t need to write this kind of code at all. The great thing about this is that if anything is missing, we will get a compile error telling us which field couldn’t be transformed and why. We can be sure that if the code compiles, it will work as expected.

Another example of relying on macros and code generation to cut down the boilerplate is our usage of GraphQL. Macros allow us to generate a GraphQL schema from our server data classes automatically, and a compiler plugin automatically generates client code powered by Scala.js (Scala code that is converted into JavaScript). We get both a client and a server from the same code with almost no effort!

Most of the macros and compiler plugins mentioned here were not even developed by us: they are available in open source libraries. The Scala OSS ecosystem is very dynamic and offers a lot of options for cutting down the boilerplate.

#Safe refactoring

An important concept in the world of functional programming with Scala is referential transparency. A function that is referentially transparent means that we can replace that function with its value without changing the behavior of the program.

Let’s see an example.

def add(a: Int, b: Int) = a + b

val sum = add(1, 2)

Everywhere in our code, we can use sum or add(1, 2) interchangeably. It won’t change anything in the code whether we use one or the other.

On the other hand:

object Test {
  var total = 0

  def add(a: Int): Int = {
	total = total + a
	total
  }
}

val sum = Test.add(2)

Using sum or Test.add(2) will lead to totally different behavior: calling sum will always return the same result, however calling Test.add(2) will trigger another modification of total and return a different result each time. In this case we can say that add is NOT referentially transparent.

Why does this matter? If we are able to replace pieces of code by functions interchangeably, it means we can do heavy refactorings without risking to break the code’s behavior. In addition to that, static typing will ensure that moving code around always make sense and the compiler will tell us if types don’t match. The ease of refactoring means that our code will be easy to maintain and extend in the feature, allowing it to grow and evolve together with our feature set.

Referential transparency is not specific to Scala, but this style of programming where all functions are referentially transparent and use immutable data types is heavily encouraged and followed within the Scala community and its library ecosystem.

#Multi-player challenges

#Local concurrency

When building a game server for a multiplayer game, we usually need multiple concurrent requests to access the same data. We sometimes need to run tasks concurrently and gather the results. We also need to run tasks in the background for the whole lifecycle of our application. The list goes on. We need to be able to perform a lot of actions concurrently without exhausting the resources that we have.

Scala comes with the concept of Future but there are even better alternatives offered by libraries such as ZIO (which is what we use), Cats Effect or Monix. They all have in common to be built on top of fibers, which are lightweight “green threads” managed by a runtime system. Unlike traditional threads, they are very cheap to create and make concurrent programming super simple.

These libraries provide a bunch of operators to let you run computations in parallel: you can fork a computation to run it in a different fiber, join a fiber to wait for its result, interrupt a fiber, race multiple fibers, etc. Most of the time, you don’t even need to manipulate them as you can simply use high level operators such as ZIO.foreachPar or ZIO#zipPar. There are many convenient data types built on top of fibers such as Promise, Schedule or Queue.

Let’s see a simple example. Whenever a player open our game client, a gRPC stream is opened to the server and maintained for as long as the user uses the game. While this stream is alive, we want to regularly update the “last connection date” of the user in the database.

updateLastConnectionDate(userId)
  .repeat(Schedule.spaced(1 hour))
  .fork

That’s it. Running this code means that the updateLastConnectionDate function will be called every one hour. Because we use fork, the function will immediately return and run in the background. By default, a fiber is terminated when its parent fiber is terminated, so that background process will automatically be stopped when our gRPC stream is disconnected. If we wanted to keep the fiber running even after the termination of its parent, we could have used .forkDaemon.

Another super useful data type from ZIO is the Hub. Unlike a Queue where each item is given to a single consumer, items that are published to a Hub are broadcasted to all subscribers. Let’s imagine that we have global messages that we want to send to all connected users through that gRPC stream we just talked about. On each game server, we can start one fiber that consumes messages from Kafka (where global messages come from), and publishes each received messages to a hub. Then, each connected gRPC stream can simply subscribe to this hub and it will receive all the messages.

def createHub(consumer: Consumer): UIO[Hub[Message]] =
	Hub.unbounded[Message].flatMap { hub => // create a hub with no max size
    consumer
     .read                                // read from Kafka
     .mapZIO(event => hub.publish(event)) // publish all messages to the hub
     .runDrain                            // consume the stream to the end
     .fork                                // do this in a separate fiber
	 .as(hub)                             // return the hub
  }

// create a stream that will contain all messages published to the hub
val stream = ZStream.fromHub(hub)

At the end, our gRPC stream is just the combination of various streams coming from different sources like this one and merged together. This Hub data type is so convenient that we created our own variant, IndexedPubSub, that allows subscribing to particular keys only. Thanks to Hub but also Ref, Promise, Queue and a few others, local concurrency problems become really trivial with ZIO.

#Distributed concurrency

In a real application, concurrency problems are often not only local but also distributed. We want to able to scale out our game servers by simply adding more nodes. Having multiple nodes causes some problems: for example, if a guild only has 1 spot left but 2 players send a request to join that guild at the exact same time, only the first one should succeed and the other should fail.

A typical way to solve that is the single writer principle: at any given time, there should be only a single instance of each entity that can modify its state. In other words, there should be a single process handling messages for any given guild at any time. That way, this process will handle the 2 messages sequentially, succeeding the first one and failing the second.

There are several ways to implement this, and the Scala ecosystem is rich with options. One of them is using Kafka consumer groups to ensure only a single consumer handles all messages of a given entity ID. In our case, because of the “synchronous” nature of our workflows (the client expects an instant response for every request), we went another route and use the actor sharding pattern. This pattern was popularized by the Akka library which is ideal for getting started (we are now using our own custom implementation that follows similar principles).

An actor is basically a tiny process that consumes messages sequentially from a queue (called “mailbox”). Sharding means that actors are distributed across a group of nodes and that you can send messages to an actor just by knowing its ID. This concept is known as location transparency, meaning that you can send messages to an actor without knowing where the actor is actually located (it might be on the same node or another one).

Following the DSL introduced earlier to send message, 2 different nodes can call the following code concurrently:

guild(guildId) ! JoinGuild(inviteId)

Under the hood, the sharding system will find on which node the actor in charge of guildId is located, and send a request to that node containing the payload (JoinGuild). That node will forward those messages to the local actor handling this guild ID. The actor will handle the message that arrived first and respond with a success. It will then handle the second message and respond with a failure.

Thanks to a few powerful libraries, Scala makes it really easy to handle distributed and concurrent payloads without resorting to things like distributed locks that might clog response times and create issues like deadlocks. The actor pattern, whether it is implemented with Akka or ZIO, makes our life easier once again.

Through a handful of practical and simple examples, we’ve seen that Scala is a really interesting choice for building a game server. Combining its powerful type system with the best practices of functional programming, we are able to minimize the risk of errors and focus entirely on the business logic. Thanks to Scala’s rich ecosystem of open source libraries, we can cut down the boilerplate and resolve all kinds of concurrency problems.

Sounds attractive to you? Want to know more? We are hiring!

게임 서버 개발에 스칼라 사용하기

Mon, 24 Oct 2022 00:00:00 GMT

알림: 이 글은 Scala for Game Server Development의 한국어 번역본입니다.

스튜디오 킹덤 팀은 스칼라 프로그래밍 언어 (이하 스칼라)를 사용하여 인기 게임 <쿠키런: 킹덤> 게임 서버를 만들었습니다. 스칼라는 다른 프로그래밍 언어들보다 덜 알려졌지만, 그래도 우리가 만든 게임 서버에는 정말 잘 맞는 언어라고 생각합니다. 킹덤 팀이 왜, 그리고 어떻게 스칼라를 사용하여 게임 서버를 개발했는지 이번 글에서 여러분께 공유하려 합니다.

이번 글에서, 저는 게임 개발의 몇 가지 측면을 살펴보면서 스칼라가 어떤 장점이 있는지 구체적으로 이야기해보려 합니다.

게임 로직을 정확하게 만드는 것은 매우 중요합니다. 버그 때문에 게임 유저의 노력이 물거품이 된다면, 정말 끔찍한 일이 아닐 수 없습니다. 또한 게임에 따라, 게임의 로직은 얼마든지 크고 복잡해질 수 있기 때문에 게임 로직을 에러 없이 만들기는 쉽지 않습니다.
게임은 매우 빠르게 변화하며, 게임 유저는 항상 새로운 기능을 원합니다. 이는 곧 게임 서버의 코드가 어쩔 수 없이 거대해질 수 밖에 없고, 또한 계속해서 진화해야 함을 의미합니다. 인기있는 게임이 되기 위해서는 꾸준히 새로운 기능을 출시해야만 합니다.
여러 플레이어가 참여하는 게임을 설계할 때는 동시성과 확장성 문제를 다뤄야 합니다. 게임 서버는 매우 많은 요청을 동시에 받게 되며, 이 중에는 같은 엔티티를 가리키는 요청도 많이 있을 것입니다.

#게임 로직의 정확성

#타입의 강력함

스칼라는 정적 타입 언어로, 컴파일할 때 타입이 정의되고, 타입의 존재를 인식할 수 있습니다. 덕분에 동적 타입 언어에서 흔히 발생하는 수많은 런타임 에러들 (예를 들어 자바스크립트의 TypeError 같은 에러)을 미리 예방할 수 있습니다. 하지만 다른 정적 타입 언어에 비해, 스칼라는 타입을 사용하여 훨씬 더 많은 일을 할 수 있습니다.

간단한 예로, Option[A] 처럼 A 라는 타입의 값이 있을 수도 있고, 없을 수도 있습니다. 다른 프로그래밍 언어에서는 A 타입의 값이 null 값을 담을 경우 코드 이곳 저곳에서 null 값에 대한 예외 처리 로직을 넣어야 하고, 잘못 동작할 수 있는 위험을 감수해야 하지만, 스칼라에서는 관용적으로 Option[A] 라는 타입으로 반환하도록 만들 수 있습니다. 개발자는 이 경우 반드시 A 의 값이 없을 경우를 고려하여 코드를 작성해야 하며, 이 때 패턴 매칭이나 getOrElse 혹은 fold 같은 함수를 사용하여 코드를 작성할 수 있습니다.

// Option[GnomeResearchLevel] 를 반환합니다.
val currentLevel = getGnomeResearchLevel(researchDataId)

// currentLevel에 값이 없을 경우를 반드시 고려해야 하는데,
// 이 때, 초기 레벨 값을 대신 설정할 수 있습니다.
val nextLevel = currentLevel.map(_.up).getOrElse(GnomeResearchLevel.initial)

여기서 더 나아가서, refined라는 스칼라 라이브러리를 이용하여 타입이 가질 수 있는 값의 종류를 제한할 수 있습니다. 예를 들어, “킹덤의 왕국 레벨” 숫자값 타입의 변수에서는 반드시 1 또는 그 이상의 값을 가져야 합니다. 단순히 Int 타입을 사용하지 않고, PosInt 라는 타입을 이용하여 값이 반드시 양의 정수가 되도록 제한할 수 있습니다. 이렇게 하면, 값이 절대로 0으로 설정될 일이 없어서, 값이 0이 될 경우를 고려해야 하거나 0으로 나누기 같은 연산 에러를 일으킬 가능성을 걱정하지 않아도 됩니다.

type PosInt = Int Refined Positive // 0보다 큰 정수값을 담는 새로운 타입 정의

val a: PosInt = 1
val b: PosInt = 0 // 컴파일 에러를 발생시킵니다.

컴파일러는 설정된 값이 유효한지 아닌지 확인할 수 있습니다. 클라이언트로부터 오는 값의 경우, 클라이언트의 요청을 분석한 후, 값이 타입의 제약 조건을 만족하지 않을 경우 즉시 에러를 발생시킵니다.

PosInt를 사용할 수도 있지만, 만약 “쿠키 레벨”도 PosInt 타입을 사용한다면, 잘못된 값을 함수에 전달할 위험성도 지니게 됩니다. 이를 예방하기 위해, newtype 스칼라 라이브러리를 사용하여, PosInt 타입에 특별한 의미를 부여하는 새로운 타입을 정의할 수 있습니다.

@newtype case class KingdomLevel(value: PosInt)

def receiveKingdomLevelRewards(level: KingdomLevel): List[Reward]

이제 컴파일러는 receiveKingdomLevelReward 함수를 호출할 때, KingdomLevel 타입 외의 데이터는 전달할 수 없도록 호출을 제한할 것입니다.

지금까지의 내용을 활용하여 타입에 정확한 의미와 제약 조건을 부여함으로서, 불필요한 버그를 줄이고 코드의 품질을 개선할 수 있습니다.

#타입을 통한 문서화

Option 타입을 사용하기만 해도 함수가 결괏값을 반환할 수도, 반환하지 않을 수도 있음을 쉽게 알 수 있습니다. 이와 같이 타입을 사용하여 함수가 어떤 종류의 연산을 수행하는지 설명할 수도 있습니다. 몇 가지 예를 들면 다음과 같습니다.

Option[A]: 함수가 A 타입의 결괏값을 반환할 수도, 반환하지 않을 수도 있습니다. 다른 부수 효과는 없습니다.
Either[E, A]: 함수 실행이 실패하면 E 타입의 에러를 반환하거나, 성공하면 A 타입의 값을 반환할 수 있습니다. 다른 부수 효과는 없습니다.
ZIO[R, E, A]: 함수가 실행에 필요한 환경 R 타입이 필요하며, 실행이 실패하면 E 타입의 에러를 반환하거나, 실행이 성공하면 A 타입의 값을 반환할 수 있습니다. 또한 부수 효과 (입출력)가 있을 수 있습니다. 부수 효과가 있을 수 있는 R => Either[E, A] 타입이라고 볼 수 있습니다.
ZPure[W, S1, S2, R, E, A]: 함수가 실행에 필요한 환경 R 타입이 필요하며, 초기 상태로 S1 타입이 필요하고, 실행이 실패하면 E 타입의 에러를 반환하거나, 성공하면 S2 타입의 업데이트된 상태값, A 타입의 실행 결괏값을 반환하며, 실행 중 발생한W 타입의 로그 값들을 반환합니다. (R, S1) => (List[W], Either[E, (S2, A)]) 와 같은 의미이며, 코드에 부수 효과는 없습니다.

위의 타입들을 사용하여 함수가 정확히 무슨 일을 하는지 알 수 있습니다. 보시다시피 타입 매개 변수들을 매우 많이 사용하고 있습니다. 그러나 실제로는 타입 별칭을 사용하여 훨씬 더 짧고 간편하게 표현할 수 있습니다. 몇 가지 예를 들어보겠습니다.

// 메트릭 값을 증가시키는 함수
// 반환 타입에서 부수 효과가 있으며, 절대 실패하지 않는다.
def incrementInFlightMessagesMetric: UIO[Unit]

// 프로토버프 데이터를 킹덤 레벨 데이터로 변환하는 함수
// 반환 타입에서 실패 가능성이 있을 수 있습니다. 실패 시 오류 정보로 채워진 리스트가 반환됩니다.
// EitherNel[E, A] = Either[NonEmptyList[E], A]
def extractKingdomLevel(raw: Protos): EitherNel[ExtractionError, KingdomLevel]

// 사용자의 현재 PVP (킹덤 아레나) 상태 정보를 반환하는 함수
// 반환 타입에서 사용자 상태 정보에 접근하지만, 상태 정보를 수정하지 않습니다.
def getCurrentPvpState: KingdomReader[Pvp]

이와 같이 타입을 활용하면, 함수의 동작을 강제할 뿐만 아니라 타입의 이름이나 타입 구성 형태를 읽기만 해도 함수가 무슨 일을 하는지 명확하게 알 수 있습니다. 발생할 수 있는 모든 오류가 반환 타입에서 명확하게 선언되므로 (오류가 발생하지 않더라도 그렇습니다.), 예외가 갑자기 발생하여 전파될 걱정을 하지 않아도 됩니다. 부수 효과도 마찬가지입니다.

#직접 도메인 특화 언어 (DSL) 만들기

지금까지 값이 가질 수 있는 유효한 범위를 정하거나, 함수가 무슨 일을 하는지를 타입을 이용해 표현하는 방법을 살펴보았으며, 컴파일러가 프로그래밍 상의 에러를 일찍 잡아내도록 하는 방법도 살펴보았습니다. 여기서 더 나아가 “유효한” 동작만을 수행하도록 코드 수준의 제약을 추가할 수 있습니다. 특정 작업에만 사용하기 위한 **별도의 도메인 특화 언어 (이하 DSL)**을 만드는 방식으로 구현할 수 있습니다. 스칼라는 그 자체로도 매우 강력하고 간결하여 하위 언어를 만들 때에도 좋습니다. 마치 사양 문서를 작성하듯 코드를 만듦으로서 꽤 많은 부분을 이룰 수 있습니다.

거창한 예를 들지 않더라도 DSL을 만들면, 특정 코드 영역에서 지정된 동작을 수행하도록 제한할 수 있습니다. 예를 하나 들어보겠습니다. 우리 게임에서는 여러 엔티티 사이에 트랜잭션을 지원합니다. 다시 말해 서로 다른 두 사용자 (혹은 사용자와 길드)에 명령어를 각각 보낸 뒤, 모든 명령어의 실행 결과가 성공적으로 끝날 때에만 변경 사항을 반영할 수 있습니다.

그래서 우리 팀에서는 트랜잭션을 위해 작은 DSL을 만들고, 다음의 작업만 수행할 수 있도록 했습니다.

ID로 엔티티를 식별할 수 있게 합니다: kingdom(userId) , guild(guildId)
엔티티로 명령어를 보냅니다: entity ! command
보내기 작업을 하나로 묶습니다: 순차적으로 보내기 위해 >>> , 병렬로 보내기 위해 &&& 연산자를 사용합니다.

이제 다음과 같이 간단한 트랜잭션을 작성할 수 있습니다.

transaction { context =>
  (kingdom(context.userId) ! SendFriendRequest(friendId)) &&&
    (kingdom(friendId) ! ReceiveFriendRequest(context.userId))
}

transaction 블록은 우리가 사용할 DSL이 사용될 곳을 나타냅니다. 이 블록 안에서 “보통 코드”는 사용할 수 없고, 우리가 만든 DSL만 사용할 수 있습니다. 그런 다음, 현재 사용자에게 SendFriendRequest 명령 (이 사용자가 친구 요청을 보낼 수 있는지 확인하고, 친구 추가할 상대의 대기 중인 친구 요청 정보를 저장하는 명령)을 보내고, 다른 사용자에게는 ReceiveFriendRequest 명령 (수신된 요청을 저장하는 명령)을 보냅니다.

이 작은 트랜잭션 시스템에서 다른 종류의 작업은 지원하지 않습니다. 만약 레디스나 카프카 같은 곳에 데이터를 저장하기 위한 코드를 transaction 블록 안에서 추가하려 한다면, 문제가 발생했을 때 제대로 롤백되지 않을 것입니다. 하지만 별도의 DSL을 사용하기 때문에 이런 일은 불가능합니다. 코드를 추가하려고 하면, DSL에서 허용하지 않는 작업을 하려고 했기 때문에 컴파일 에러가 발생할 것입니다.

대부분의 비즈니스 로직은 이와 같이 DSL을 사용하여 구현했으며, 각 DSL에서는 다음의 작업만 할 수 있도록 기능이 제한되어 있습니다.

결괏값과 함께 성공 상태를 표현합니다.
ValidationError 와 함께 실패 상태를 표현합니다.
환경 (모든 게임 설정 정보를 담는 거대한 개체로, 캐릭터 목록, 레벨, 이벤트 등이 들어있습니다.) 데이터에 접근할 수 있습니다.
사용자 상태에 접근할 수 있습니다.
사용자 상태를 변경하는 이벤트를 처리합니다. (이벤트 소싱을 사용합니다.)

약속된 작업만 수행할 수 있도록 제한한 덕분에, 비즈니스 로직 중간에서 예기치 않은 에러가 발생할 가능성을 막을 수 있었습니다.

#빠르게 변화에 대응하기

#중요한 것에만 집중하기

지금까지 본 것처럼, DSL을 작성하여 코드가 올바른 작업만 실행하면서도 작게 유지될 수 있도록 제한할 수 있습니다. 이는 스칼라 프로그래밍 언어의 간편함과 결합되면서 훨씬 더 큰 이점을 가져다 주는데, 코드를 매우 짧고 읽기 쉽게 만들어줍니다.

DSL을 만들면 프로그램에서 복잡한 세부 사항을 효과적으로 감출 수 있어, 비즈니스 로직에서 정말 중요한 것에만 집중할 수 있게 해줍니다. 위의 트랜잭션 예제는 사실 매우 복잡한 코드가 그 안에서 작동하게 됩니다. 다른 노드 위에 저장된 엔티티로 메시지를 보내기 위해, 노드의 위치를 파악하고, 어떤 메시지 프로토콜을 사용하여 메시지를 보낼 것인지 결정하는 등의 일을 해야 할 것입니다. 영속 레이어에서는 모든 쓰기 작업을 하나의 트랜잭션으로 묶어 한 번에 반영되거나 롤백되도록 처리해야 하고, 실제 데이터베이스와 상호 작용해야 할 것입니다. 그러나 비즈니스 로직을 작성할 때 이런 부분들을 신경쓰기는 너무 복잡합니다.

즉, DSL를 통해 기술적인 레이어를 비즈니스 로직과 분리할 수 있어 개별적으로 구현하고 테스트할 수 있습니다. 그 결과, 새로운 기능을 추가하는 작업이 대부분인 비즈니스 로직을 어떤 간섭도 없이 구현할 수 있어 훨씬 더 효율적입니다.

여기 사용자가 길드에 가입할 때 사용되는 간단한 비즈니스 로직 함수 예제가 있습니다. 게임 설정으로부터 메타데이터를 가져오고, 길드 상태를 확인한 후, 요청이 올바른지 확인합니다. 문제가 없다면, 이벤트를 처리하면서 사용자가 길드에 가입했다는 사실을 기록합니다. 여기서 메시징 프로토콜, 영속성, 트랜잭션, 데이터베이스 잠금 등 어떤 것이든 밑에서 일어나는 기술적인 세부 사항은 전혀 신경쓰지 않았다는 점을 주목하세요.

val joinGuild: KingdomProgram[Unit] =
  for {
	metadata    <- inquireGuildMetadata
    requesterId <- inquireRequesterId
    memberCount <- getGuild(_.members.size)
    ()          <- assertThat(
                     memberCount < metadata.maxMemberCount,
                     ValidationError.GuildFull
                   )
    ()          <- liftEvent(GuildMemberJoined(requesterId))
  } yield ()

덕분에 새로운 개발자가 우리 팀에 합류하더라도 온보딩 걱정은 자연스럽게 덜 수 있게 됩니다. 왜냐하면 사용할 수 있는 연산자가 얼마 되지 않아 DSL을 쉽게 이해하고 코드를 작성할 수 있습니다. 기술적인 개념보다는 도메인 지식을 배우는 데 집중할 수 있습니다.

#보일러플레이트와 헤어질 시간!

새로운 기능을 구현하면 많은 양의 코드를 작성해야 합니다. 클라이언트를 위한 새로운 API를 공개해야 하고, 영속성 레이어를 구현하며, 서로 다른 레이어 사이에 주고 받는 데이터 타입을 변환하는 등의 일이 될 것입니다. 스칼라를 사용하면 보일러플레이트 코드를 최대한 줄일 수 있습니다. 이는 강력한 매크로 엔진과 컴파일러 플러그인을 작성할 수 있는 스칼라의 능력 덕분입니다.

수많은 프로그래밍 언어들과 마찬가지로, 우리 팀에서도 프로토버프 파일 정의를 사용하여 서버 코드를 생성합니다. 하지만 비즈니스 로직에서 생성된 코드를 사용하지는 않는데, 생성된 코드는 우리가 정의한 refine 타입을 사용하지 않으며, 자동 생성된 코드에서 사용하는 타입보다는 더 사용하기 편리한 데이터 타입을 사용하는 것을 선호하기 때문입니다. (컬렉션은 일반적으로 데이터 타입 선택이 무척 중요한 영역입니다.) 다시 말해, 우리가 클라이언트로부터 받은 자동 생성된 타입으로 이루어진 개체를 우리 자신의 것으로 변환해야 한다는 것입니다. 수천가지 개체들을 사용하여 통신을 진행하게 되며, 이는 많은 양의 보일러플레이트 덩어리와 씨름하는 일일 수 있습니다. 하지만, 스칼라 매크로 덕분에, 이런 변환 작업의 대부분이 자동으로 처리될 뿐 아니라, 컴파일 시점에서 데이터의 유효성을 검증할 수도 있습니다.

여기서 각 데이터 타입마다 Transformer 인스턴스를 만들었는지 확인해야 합니다. 매크로는 필드 이름이 일치하고 각 해당 필드 유형 사이에 변환기가 있다면, 두 개의 클래스 간에 Transformer를 자동으로 생성하는 데 사용됩니다.

예제를 살펴보겠습니다. 다음의 프로토버프 타입이 있습니다.

message CraftProduction {
  string id = 1;
  repeated int32 cookie_data_ids = 2;
  int32 completed_job_count = 3;
}

생성된 코드는 다음과 같은 모습일 것입니다.

case class CraftProduction(
  id: String,
  cookieDataIds: Seq[Int],
  completedJobCount: Int
)

그러나 앞서 살펴본 매크로를 이용한다면 다음과 같이 더 “개선된" 타입을 만들 수 있을 것입니다.

case class CraftProduction(
  id: ActivityId,
  participants: NonEmptyList[CookieDataId],
  completedJobCount: Int
)

모든 ID는 ActivityId 나 CookieDataId 처럼 좀 더 정확한 타입을 사용하여 단순히 정수 값으로만 취급하여 값이 섞이지 않도록 분리하고, 또한 NonEmptyList 타입을 사용하여 최소한 하나 이상의 값이 들어있는 리스트여야 함을 나타냅니다. 그리고 cookieDataIds 필드 대신 다른 이름을 사용하여 게임 서버 코드를 이해하기 쉽게 만들었습니다.

아래 타입들 사이를 변환하기 위해 각각의 Transformer 들이 필요할 것입니다.

String 타입과 ActivityId 타입 사이를 변환하는 Transformer
Int 타입과 CookieDataId 타입 사이를 변환하는 Transformer
Seq 타입과 NonEmptyList 타입 사이를 변환하는 Transformer

ID를 처리하는 Transformer는 단지 값을 보조하는 타입이므로 구조가 매우 단순하여, 일반화된 방법으로 만들 수 있을 것입니다. Seq 타입과 NonEmptyList 타입 사이를 변환하는 Transformer 역시 구조가 단순하며, 다만 Seq 안에 들어있는 요소가 하나도 없을 경우에만 실패로 처리하고, 그 외에는 NonEmptyList 로 쉽게 변환할 수 있을 것입니다.

위의 예제를 만들기 위해, 다음과 같이 변환기를 정의할 수 있습니다.

implicit val transformer =
  Transformer
    .define[entities.CraftProduction, protobuf.CraftProduction]
    .withFieldRenamed(_.participants, _.cookieDataIds)
    .buildTransformer

매크로는 모든 필드를 자동으로 변환할 수 있고, participants 필드와 cookieDataIds 필드 사이의 관계를 정의했기 때문에, 이를 토대로 변환기를 만들 수 있을 것입니다. 대부분의 경우 필드 이름이 같은 방식으로 지정되므로 이런 형태의 코드를 전혀 작성할 필요가 없습니다. 만약 누락된 부분이 있다면, 컴파일 단계에서 변환할 수 없는 필드와 그 이유를 알려주는 에러를 발생시킬 것이므로 문제를 미리 찾을 수 있어 매우 유용합니다. 코드가 에러 없이 컴파일된다면 예상대로 작동할 것을 확신할 수 있는 것입니다.

보일러플레이트를 줄이기 위해 매크로와 코드 생성에 의존하는 또 다른 예는 그래프 QL을 사용하는 것입니다. 매크로를 사용하면 서버 데이터 클래스에서 그래프 QL 스키마를 자동으로 생성할 수 있으며, 컴파일러 플러그인은 스칼라 JS (자바스크립트로 변환되는 스칼라 코드)로 구동되는 클라이언트 코드를 자동으로 생성합니다. 힘들이는 것 없이 동일한 코드에서 클라이언트와 서버를 모두 얻을 수 있습니다!

이 글에서 소개한 대부분의 매크로와 컴파일러 플러그인은 저희가 개발한 것이 아닌, 오픈 소스 라이브러리에서 사용할 수 있는 매크로와 컴파일러 플러그인들입니다. 스칼라 오픈 소스 생태계는 매우 역동적이며 보일러플레이트를 줄이기 위한 많은 방안을 제공합니다.

#안전한 리팩토링

스칼라를 사용한 함수형 프로그래밍에서 참조 투명성은 중요한 개념입니다. 참조적으로 투명한 함수는 프로그램의 동작을 변경하지 않고 해당 함수를 해당 값으로 대체할 수 있습니다.

다음의 예를 살펴보겠습니다.

def add(a: Int, b: Int) = a + b

val sum = add(1, 2)

코드 어디서나 sum 또는 add(1, 2)를 서로 바꿔서 사용할 수 있습니다. 어떤 것을 사용하든 의미는 동일합니다.

또 다른 예를 살펴보겠습니다.

object Test {
  var total = 0

  def add(a: Int): Int = {
	total = total + a
	total
  }
}

val sum = Test.add(2)

반면 위의 코드에서 sum 과 Test.add(2) 는 각각 완전히 다른 결과를 만들 것입니다. sum 은 항상 같은 결과를 반환하지만, Test.add(2) 는 total 에 변경을 일으키게 되고, 실행할 때마다 다른 값을 반환할 것입니다. 이 때 add 는 참조 투명성이 없다고 말할 수 있습니다.

참조 투명성을 지키는 것이 왜 중요할까요? 코드 조각을 함수로 교체할 수 있다는 것은, 코드의 동작을 깨뜨릴 위험 없이 리팩토링을 폭넓게 수행할 수 있습니다. 그 외에도 정적 타입 지정은 코드 이동이 항상 의미가 있는지 확인하고, 타입이 다르면 컴파일러에서 알려주어 에러를 쉽게 찾을 수 있습니다. 리팩토링이 쉬우면, 만들었던 기능과 함께 계속해서 성장하고 발전하면서, 코드를 유지 관리하거나, 기능을 확장하기 쉽기 때문입니다.

참조 투명성은 스칼라에만 국한된 것은 아니지만, 스칼라 커뮤니티와 라이브러리 생태계 내에서는 모든 기능이 참조적으로 투명하고 불변 데이터 유형을 사용하는 방식의 프로그래밍 방식을 사용할 것을 적극 권장합니다. 또한, 스칼라 프로그래밍 언어를 사용하는 많은 개발자들이 참조 투명성을 지키기 위해 노력합니다.

#멀티 유저 문제

#로컬 동시성

멀티 유저 게임을 위한 게임 서버를 만들 때, 여러 요청이 동시에 같은 데이터를 활용하는 기능을 자주 개발하게 됩니다. 그리고 종종 동시에 작업을 실행하고 결과를 수집하기도 합니다. 또한 애플리케이션 생애주기 전체에 걸쳐 백그라운드에서 작업을 실행하도록 만들 필요가 있습니다. 그 외에도 정말 많습니다. 서버 자원을 소진하지 않고 동시에 많은 작업을 해내야 할 필요가 있습니다.

스칼라에서는 Future 라는 개념을 제공하지만, ZIO (우리 팀에서 사용 중인 라이브러리), Cats Effect, Monix 등 다양한 라이브러리들을 대신 사용할 수도 있습니다. 이런 라이브러리들은 모두 파이버 위에서 만들어졌다는 공통점이 있는데, 파이버란 런타임 시스템이 관리하는 경량화된 “가상 스레드"입니다. 전통적인 스레드와 달리, 동시성 프로그래밍을 매우 단순하게 만들어주고, 원하는대로 만들어 사용하기 쉽습니다.

동시성 라이브러리들은 계산을 병렬로 실행할 수 있는 여러가지 오퍼레이터를 제공합니다. 예를 들어, fork 를 이용하여 다른 파이버에서 계산이 실행되도록 만들거나, join 을 사용하여 기존 스레드가 결과를 반환할 때까지 기다리게 하거나, interrupt 로 파이버를 중단시키거나, race 로 여러 파이버들을 경합시키는 등의 작업을 할 수 있습니다. 그러나 대부분은 고차원의 오퍼레이터인 ZIO.foreachPar 나 ZIO#zipPar 같은 오퍼레이터를 활용할 수 있으므로 스레드 작업을 직접 제어할 필요가 없습니다. 또한 파이버를 기반으로 만든 편리한 여러 데이터 타입, 예를 들어 Promise, Schedule, Queue 같은 데이터 타입을 활용할 수도 있습니다.

간단한 예를 하나 살펴보겠습니다. 유저가 우리가 만든 게임 클라이언트를 실행하면, 사용자가 게임을 종료하기 전까지 서버로 스트림이 연결된 후 계속 유지될 것입니다. 스트림이 유지되는 동안, 주기적으로 “마지막 연결일시" 정보를 사용자 데이터베이스에 기록하려고 합니다.

updateLastConnectionDate(userId)
  .repeat(Schedule.spaced(1 hour))
  .fork

어렵지 않습니다. 이 코드를 실행하면, updateLastConnectionDate 함수가 매 시간마다 호출됩니다. fork를 사용했으므로, 함수를 호출하는 코드는 즉시 반환되고, 작업은 백그라운드에서 실행될 것입니다. 기본적으로, 파이버는 상위 파이버가 종료되면 자동으로 종료되므로, 백그라운드 프로세스는 gRPC 스트림의 연결이 끊어지면 자동으로 종료됩니다. 상위 파이버가 종료된 후에도 계속 파이버를 유지하려면, .forkDaemon 을 사용할 수 있습니다.

또한 ZIO에는 무척 유용한 데이터 타입인 Hub 가 있습니다. Queue 는 안에 들어있는 항목이 한 곳에만 전달되지만, Hub 에 들어있는 항목은 이벤트를 수신하는 모든 곳에 전달됩니다. 앞서 살펴본대로 gRPC 스트림이 연결된 모든 사용자들에게 전체 메시지를 보내는 상황을 상상해보겠습니다. 각 게임 서버에서는 카프카로부터 오는 메시지 (글로벌 메시지가 카프카를 통해 전달될 것입니다)를 구독하는 파이버를 시작할 수 있을 것이고, 수신된 각각의 메시지를 허브로 보낼 것입니다. 그다음, 연결된 각각의 gRPC 스트림에서는 허브에서 발생하는 이벤트를 수신하며 들어오는 메시지를 모두 받을 것입니다.

def createHub(consumer: Consumer): UIO[Hub[Message]] =
	Hub.unbounded[Message].flatMap { hub => // 크기 제한이 없는 허브를 만듭니다.
    consumer
     .read                                // 카프카에서 데이터를 읽습니다.
     .mapZIO(event => hub.publish(event)) // 모든 메시지를 허브로 보냅니다.
     .runDrain                            // 스트림을 끝까지 읽습니다.
     .fork                                // 이 작업을 별도의 파이버에서 처리합니다.
	 .as(hub)                         // 허브를 반환합니다.
  }

// 허브에 보낸 모든 메시지를 포함할 스트림을 만듭니다.
val stream = ZStream.fromHub(hub)

결국 게임 서버에서 관리하는 gRPC 스트림은 이처럼 다양한 곳에서 오는 다양한 스트림을 조합하여 하나로 통합한 것입니다. Hub 데이터 타입을 활용하여 우리 팀에서는 특정 키만 선택적으로 구독할 수 있는 IndexedPubSub 라는 또 다른 타입을 만들어 편하게 활용할 수 있었습니다. Hub 뿐 아니라, Ref, Promise, Queue 등 여러 타입 덕분에, 로컬 동시성 문제를 ZIO를 이용하여 단순하게 만들 수 있었습니다.

#분산 동시성

실제 애플리케이션에서, 동시성 문제는 로컬에서만이 아니라 분산된 환경에서도 자주 발생합니다. 우리 팀은 게임 서버를 단순히 노드를 추가하기만 해도 쉽게 확장할 수 있는 구조를 만들기 원했습니다. 여러 노드를 사용하면 몇 가지 문제점이 발생할 것입니다. 예를 들어, 만약 길드에 자리가 한 개만 남은 상황에서, 두 명의 유저가 동시에 그 길드에 정확히 같은 시간에 가입 요청을 보낸다면, 한 사용자는 가입에 성공할 것이고, 다른 한 명은 실패할 것입니다.

이 문제를 풀 수 있는 일반적인 방법은 **단일 기록자 원칙 (Single Writer Principle)**을 적용하는 것입니다. 이 원칙은 주어진 시간에 각각의 엔티티의 상태를 변경할 수 있는 인스턴스를 단 하나만 만들어 유지하는 것을 말합니다. 다시 말해, 길드에 대한 메시지를 처리하는 프로세스가 주어진 시간 범위 안에 단 하나만 있게 만드는 것입니다. 이렇게 하면, 프로세스는 두 개의 메시지를 순차적으로 처리할 수 있으므로, 먼저 도착한 사람만 가입에 성공하도록 만들 수 있는 것입니다.

이 방식을 구현하는 방법은 여러 가지가 있을 수 있지만, 스칼라 에코 시스템에서는 풍부한 옵션을 제공합니다. 그 중 하나는 카프카 컨슈머 그룹을 사용하여 하나의 컨슈머가 특정 엔티티 ID에 대한 모든 메시지를 수신하여 처리하도록 만드는 것입니다. 우리의 경우, 이런 “동기적인 방식"의 워크플로우 때문에 (클라이언트는 모든 요청에 즉각적으로 답을 받도록 설계되었기 때문에), 조금 다른 방법인 액터 샤딩 패턴을 사용했습니다. 이 패턴은 배우기 쉬운 Akka 라이브러리 덕분에 많이 유명해졌습니다. (현재 우리 팀에서는 Akka를 대신하여 비슷한 원칙을 따르는 독자적인 구현체를 사용하고 있습니다.)

액터는 기본적으로 큐 (”메일함"이라고도 부릅니다.)에서 메시지를 순차적으로 수신하는 작은 프로세스입니다. 샤딩은 액터가 노드 그룹에 걸쳐 분산되어, 호출하려는 액터의 ID를 사용하여 메시지를 보내기만 하면 액터를 실행할 수 있습니다. 이 개념은 위치 투명성이라고도 불리며, 액터가 어느 위치에서 실행되고 있는지를 모르더라도 메시지를 보낼 수 있습니다. 액터는 같은 노드에서 실행되고 있을 수도, 다른 노드에서 실행될 수도 있습니다.

앞서 소개한 다음의 DSL은 메시지를 보내기 위해 두 개의 다른 노드가 아래의 코드를 동시에 호출할 수 있습니다.

guild(guildId) ! JoinGuild(inviteId)

내부적으로 샤딩 시스템에서는 guildId 에 지정한 값을 처리해야 할 액터가 어느 노드에서 실행되고 있는지 찾아서, 해당 노드에 페이로드 (JoinGuild)를 포함시켜 메시지를 보낼 것입니다. 메시지를 받은 노드에서는 이 길드 ID를 처리할 액터에게 메시지들을 전달할 것입니다. 가장 먼저 메시지를 받을 액터에서는 작업을 처리한 후 성공 응답을 내보낼 것입니다. 처리가 끝난 후에 도착하는 메시지는 실패로 응답을 내보낼 것입니다.

강력한 라이브러리 덕분에, 스칼라는 응답 시간에 영향을 주거나, 교착 상태 같은 문제를 일으킬 수 있는 분산 잠금 기술에 의존하지 않고서도 분산 처리를 유연하게 구현할 수 있고, 동시에 도착하는 페이로드를 정말 쉽게 처리할 수 있습니다. 그리고 Akka로 구현하든 ZIO로 구현하든, 액터 패턴은 우리의 삶을 다시 한 번 더 쉽게 만듭니다.

몇 가지 실용적이고 간단한 예제를 통해 우리는 Scala가 게임 서버를 구축하기 위한 정말 흥미로운 선택인 것을 알 수 있었습니다. 강력한 타입 시스템과 함수형 프로그래밍의 모범 사례를 결합하여, 에러가 발생할 위험을 최소화하고, 비즈니스 논리에만 집중해서 개발할 수 있다는 사실도 알았습니다. 그리고, 스칼라의 풍부한 오픈 소스 라이브러리 생태계 덕분에 보일러 플레이트 코드를 줄이고, 모든 종류의 동시성 문제를 해결할 수 있습니다.

지금까지의 이야기가 재미있으셨나요? 더 자세한 내용을 알고 싶으신가요? 우리 팀과 함께 해요!

바삭한 신입들의 동시성 이야기 - Swift편

Wed, 17 Aug 2022 00:00:00 GMT

안녕하세요! 마이쿠키런에서 팬플랫폼 iOS 개발을 하고 있는 이인애입니다. 벌써 팀에 합류한지 약 6개월이 되었는데요. 오늘은 신입 iOS 개발자가 Swift 5.5에 새롭게 등장한 동시성, 그중에서도 async/await 키워드의 동작에 대해 공부하면서 깨달았던 내용들을 공유해 보려고 합니다.

#Swift 5.5 이전의 동시성

Swift 5.5에서 새로운 동시성 모델을 제시하기 전까지 우리는 GCD와 completion handler를 사용해 비동기 프로그래밍을 해야 했습니다. GCD API로 비동기 작업을 처리하고, completion handler로 비동기가 끝나는 시점에 필요한 작업을 할 수 있었습니다.

기존에도 Swift에는 동시성 프로그래밍을 위한 방법들이 존재하고 있었습니다. 그런데 왜 또 다른 동시성 생태계(Swift Concurrency)를 도입하고자 했을까요?

그 배경을 이해하기 위해 바삭한 쿠키🍪를 함께 구워보겠습니다. 쿠키 만드는 각 단계는 긴 시간이 소요되기 때문에 비동기로 동작한다고 가정하겠습니다.

도우 만들기
도우 숙성시키기
오븐에 굽기
쿠키에 얼굴 그리기

먼저 completion handler를 사용해 구현한 코드입니다.

func makeCrunchyCookie(completion: @escaping ((Cookie) -> Void)) {
    makeDough { dough in // ✅ (1)
        self.chillDough(dough: dough) { ripedDough in // ✅ (2)
            self.bakeCookie(dough: ripedDough, time: bakeTime) { cookie in // ✅ (3)
                self.drawFace(cookie: cookie) { crunchyCookie in // ✅ (4)
                    completion(crunchyCookie)
                }
            }
        }
    }
}

자, 여기서 ‘*개발자의 실수로 인해 발생할 수 있는 오류’*가 발생할 가능성이 있기 때문에 쿠키를 굽는 개발자들이 주의해야 할 점이 있습니다.

에러 처리를 위해 모든 case에서 completion handler를 리턴했나요?
self property에 접근할 때, 어떤 스레드에서 접근하게 될지 생각했나요?
self property에서 retain cycle이 발생할 가능성은 없나요?
etc

가장 먼저 눈에 띄는 것은 중첩되는 코드 블럭입니다. 들여쓰기가 많아지면 가독성이 떨어질 뿐 아니라, 코드 내부에서 분기 처리 시 completion handler를 호출하지 않는 실수를 할 수도 있습니다.

또 코드 내부에서 self 키워드에 접근해야 한다면 retain cycle(참조 사이클) 발생 가능성을 고려해야 합니다. 그렇다고 무분별한 [weak self]의 사용은 런타임 오버헤드를 발생시킬 수도 있고, nil을 체크해야 하는 수고를 거쳐야 합니다. guard let 문법을 사용한다면 self가 nil 일 때 특정 코드들을 건너뛰게 되는 상황도 발생할 수 있습니다.

✅ completion handler의 문제점
    ∙ 중첩되는 들여쓰기로 인한 가독성 저하
    ∙ 개발자의 실수로 인해 발생할 수 있는 오류
        ◦ 복잡한 에러 핸들링
        ◦ closure에서 self capture → retain cycle 발생 가능성

컴파일러는 이런 종류의 *‘개발자로 인해 발생할 수 있는 오류’*들을 감지할 수 없습니다. 그래서 문법적인 패턴을 도입해 보다 명확하고 안전하게 문제를 해결하고자 했습니다.

#async, await 문법의 도입

아래의 키워드를 사용해서 비동기 함수를 사용할 수 있습니다.

async: 비동기 함수임을 나타낸다.
await: async 키워드가 표시된 메소드나 함수의 리턴을 기다린다. 즉, async 함수는 비동기적으로 동작할 수 있고, await 키워드를 사용해 비동기 함수의 결과를 대기할 수 있습니다.

앞서 살펴본 예제를 async, await로 변경한 코드입니다.

func makeCrunchyCookie() async throws -> Cookie {
    let dough = try await makeDough() // ✅ (1)
    let ripedDough = try await chillDough(dough: dough) // ✅ (2)
    let cookie = try await bakeCookie(dough: ripedDough, time: bakeTime) // ✅ (3)
    let crunchyCookie = try await drawFace(cookie: cookie) // ✅ (4)

    return crunchyCookie
}

completion handler가 사라지면서, 비동기 함수를 한 줄로 처리할 수 있어 훨씬 간결해 보입니다. 이와 동시에 retain cycle이 발생할 우려도 사라졌습니다. 또, 개발자가 실수로 try await 키워드를 빼먹은 경우에는 컴파일러가 오류를 알려줘 조금 더 안정적인 에러 핸들링이 가능합니다.

이처럼 가독성이 더 좋아졌을 뿐 아니라 위에서 언급한 여러 문제를 해결하고 있습니다.

#동작 과정

최근 새로운 프로그래밍 패러다임으로 자리 잡기 시작한 구조화된 동시성(Structured Concurrency)이 Swift에도 도입되었습니다. Swift 5.5부터 도입된 구조화된 동시성은 async/await 키워드로서 제공됩니다.

다른 언어에서도 Swift와 유사하게 구조화된 동시성이 async/await 키워드로 제공됩니다. async 키워드를 사용해서 비동기적으로 동작하는 함수를 만들 수 있는데, 이때 이 비동기 함수는 코루틴(Coroutine)으로 만들어집니다. Coroutine은 함수가 동작하는 도중 특정 시점에 suspend(일시정지)할 수 있고, resume(다시 재개)할 수 있게 합니다.

다른 언어에서는 Coroutine을 이용해서 비동기 함수 매커니즘을 제공하고, Swift의 구조화된 동시성 또한 이와 유사하게 동작합니다.

함수의 이름 뒤에 async 키워드를 붙여 해당 함수가 비동기임을 나타낼 수 있고, 비동기 함수가 결과를 반환할 때까지 suspend(일시정지) 될 수 있습니다. 이때 비동기 함수가 일시정지될 수 있는 지점을 알려주는 장치가 await 키워드입니다.

await 키워드는 호출할 함수의 앞에 붙여 suspension point 임을 나타냅니다. 호출된 함수가 결과값 혹은 오류를 던진 이후, suspension point에서 resume(실행을 재개)할 수 있습니다.

#📌 비동기 함수를 처리할 때 suspend / resume이 왜 필요하죠?

Swift의 모든 비동기 함수는 여러 task의 집합으로 이뤄져 있습니다. 비동기 함수가 다른 비동기 함수를 호출했을 때, 해당 호출 또한 task입니다. task는 동기 함수에서 스레드 내 함수 컨텍스트에 해당하는 continuation을 포함합니다. continuation은 task가 suspend 되었을 때 발생하며, resume 될 때 이를 이용해 suspension point로 돌아갈 수 있습니다.

해당 과정을 코드와 함께 살펴보겠습니다. 먼저 위의 예시에 등장한 비동기 함수들을 task로 나눠보겠습니다. 우리는 함수를 기다려야 하는 부분과, 비동기로 처리되어야 하는 코드의 일부분을 task로 나눌 수 있습니다. 시스템은 이 task들을 각각 어떤 스레드에서 동작할지 executor(일종의 스레드 풀)를 통해 결정합니다.

함수가 실행되는 과정에서 await 키워드를 만나면 해당 지점을 suspension point로 표시하게 됩니다.

작업이 suspend되면, task는 작업을 진행 중이던 스레드의 제어권을 포기하게 됩니다. 이때 해당 스레드 제어권은 시스템이 가지게 되는데, 시스템은 이 스레드에서 다른 작업을 수행하다가 task의 수행이 필요하다고 느껴지는 적절한 시점에 스레드 제어권을 반환합니다.

스레드 제어권은 다시 suspension point가 발생한 지점으로 돌아가 작업이 resume 됩니다.

✅ suspend → resume의 과정
    1. await 키워드를 만나면 suspension point로 지정하고 일시정지 (suspend)
    2. 스레드의 제어권을 시스템에게 넘겨줌
    3. 시스템이 다시 비동기 함수에게 스레드 제어권을 넘겨줌
    4. suspension point에서 작업 재개 (resume)

#헉 그럼 이 task는 어떤 스레드에서 실행되는거죠..?

스레드는 너굴맨이 처리했으니 안심하라구!

일반적으로 함수는 정해진 스레드에서 처리해야 합니다. 즉, 처리해야 할 작업이 많아지면 생성되는 스레드도 증가하게 됩니다. 그렇다면 스레드의 수가 많아지면 더 많이 처리할 수 있으니까 더 좋은 거 아닐까요?

예상외로 그렇지는 않습니다. 스레드의 수가 지나치게 많이 생성되는 현상(thread explosion)이 발생합니다. 스레드의 수가 디바이스의 CPU 코어 수보다 많아지면 실제 용량을 초과해 요구하는 셈(overcommit)이 되어버립니다.

코어의 수가 제한된 디바이스에서 스레드가 과도하게 생성될 경우 빈번한 컨텍스트 스위칭(context switching)으로 인해 스케줄링 오버헤드가 발생하거나, block된 스레드가 다시 실행되기를 기다리면서 가지고 있는 메모리 및 리소스 때문에 메모리 오버헤드가 발생해 성능을 저하시킬 가능성이 있습니다.

또, 엄청난 양의 스레드를 개발자들이 직접 관리하는 것은 꽤나 복잡한 작업을 요구하게 될 것입니다.

GCD를 사용할 때는 너무 많은 스레드들이 block 되지 않도록 제어하거나, 세마포어(semaphore)를 사용해 할당되는 스레드의 수를 제한하는 방법을 사용해야 했습니다. 이 점 또한 앞에서 언급한 ‘개발자의 실수로 인해 발생할 수 있는 오류’를 발생시킬 가능성이 있기 때문에 언어적인 측면에서 안전하다고 판단되는 것은 아니었습니다.

Swift concurrency: Behind the scenes

WWDC 2021에 따르면, 애플은 스레드 관리를 개발자에게 맡기기보다 시스템 자체에서 처리해 안전성을 보장하고자 했습니다. 그래서 시스템이 넘겨받은 작업의 우선순위와 실행하기에 적절한 스레드를 고려하여 제어권을 넘겨줍니다.

즉, 함수가 suspend 되는 과정에는 추가적인 스레드의 생성 없이 작업할 수 있도록 executor가 task를 적절한 스레드로 배정하는 과정이 포함되었다고 볼 수 있습니다.

이제 task는 시스템에게 넘겨받은 스레드 제어권으로 작업을 재개할 수 있습니다. 하지만 여기서 task가 재개되는 스레드는 이전과 같지 않을 수 있다는 점을 기억해야 합니다.

✅ suspension point에서 변할 수 있는 것
    ∙ 스레드 제어권
    ∙ resume 되는 스레드
    ∙ suspend → resume 이후 앱의 상태

#📌 작업이 재개되는 스레드가 왜 이전과 같지 않을 수 있을까요?

이것을 알기 위해서는 비동기 task가 어떤 식으로 동작하는지 이해해야 합니다. continuation이란, 특정 지점에서의 함수 실행 컨텍스트를 추적할 수 있는 객체입니다. 새로운 Swift 동시성 모델에서는 각 task에 대해서 스레드를 생성하는 대신 continuation을 할당합니다.

일반적으로 실행 중인 프로세스 내에서 모든 스레드는 독립적인 stack 영역과 프로세스 내에서 공유되는 heap 영역을 가지고 있습니다. 이때 stack은 함수 호출의 상태를 저장하기 위해 사용됩니다. 지역 변수와 반환 주소값 등 함수 호출에 필요한 정보들을 함께 저장하고 있습니다.

일반적으로 함수가 호출 및 반환될 때의 stack의 모습입니다. 함수가 호출되면 stack에 push되고, 실행이 끝나 함수가 return 되면 pop을 수행합니다. 기존에 동시성 프로그래밍을 구현하기 위해서는 여러 개의 스레드를 사용해 처리해야 했습니다. 이처럼 여러 개의 스레드 작업을 번갈아가며 처리할 때 컨텍스트 스위칭(context switching)이 발생합니다.

그러나 Swift Concurrency에 도입된 코루틴에서는 비동기 함수의 실행을 stack과 heap에서 관리합니다. stack에는 비동기 함수를 실행할 때 사용되지 않는 지역변수들을 저장합니다. 추가로 heap에는 suspension point에서 실행하는데 필요한 함수 컨텍스트들을 저장합니다. 이것을 continuation이라고 부르며, 이를 통해 일시정지된 함수의 상태를 추적해 어디서부터 재개할지 알 수 있습니다.

continuation은 heap에 저장되기 때문에 스레드 간의 함수 컨텍스트를 공유할 수 있습니다. 바삭한 쿠키를 굽는 과정에서 makeDough 함수가 suspend 된 상황을 가정해 보겠습니다.

먼저 미래에 사용될 가능성이 있는 변수들이 continuation의 형태로 heap에 저장됩니다. suspend 되었던 함수가 resume 되면, stack의 최상단 frame이 해당 함수 frame으로 교체됩니다. 이미 heap에 함수 컨텍스트가 저장되어 있기 때문에 새로운 stack frame을 생성하지 않고 교체만으로도 동작할 수 있습니다.

작업의 교체만 이뤄지면 이미 생성된 스레드를 재사용하는 것도 가능합니다. 비동기 함수가 어떤 스레드에서 suspend 되었는지와 관계없이 가장 효율적으로 실행될 수 있는 스레드에서 함수 컨텍스트를 불러와 resume 할 수 있습니다. 또, 이러한 과정은 컨텍스트 스위칭 없이 함수 호출 만으로도 작업의 변경이 가능해 스케줄링 오버헤드를 줄일 수 있는 이점이 있습니다.

그래서 쿠키를 굽기 위해 비동기 함수 makeDough를 실행하다가(suspend), 손을 씻어야 할 때가 오면 비동기 함수 washHand를 실행(resume)할 수 있는 것입니다. 이 말은 곧, 비동기 함수를 실행하다가 UI 업데이트 같은 중요한 작업을 진행할 수 있게 해준다는 뜻입니다.

비동기 함수가 suspend 되면 해당 스레드 제어권은 시스템이 가지고 있기 때문에, 시스템 판단하에 적절한 스레드를 찾아서 task에게 제어권을 넘겨줍니다. 여기서 말하는 적절한 스레드는 ‘원래 작업 중이던 스레드’ 혹은 ‘작업이 다 완료되어 쉬고 있는 다른 스레드’가 될 수 있습니다. 따라서 작업이 resume 되는 스레드가 같지 않을 수 있다는 특징이 여기서 발생하게 됩니다.

✅ continuation 특징
    ∙ 컨텍스트 스위칭을 함수 호출로 대체 → 스케줄링 오버헤드 감소
    ∙ 추가적인 스레드 생성 없이 스레드 재사용 → thread explosion 방지

#요약

지금까지 Swift에서 async, await가 어떤 원리로 비동기 처리를 하고 있는지 살펴봤습니다. coroutine model을 기반으로 한 Swift Concurrency는 함수의 실행이 스레드에 국한되지 않는 동시성 생태계를 제공하고 있습니다. 요약하자면, Swift 5.5에 반영된 async/await 문법은 컴파일 타임과 런타임에 안전성을 보장하면서 한 번 이상 suspend, resume 될 수 있음을 의미합니다.

✅ Swift Concurrency에 적용된  변화
    📌 언어적 개선
        ∙ completion handler 제거로 인한 가독성 증가
        ∙ self 참조 사이클이 생길 우려 제거
        ∙ 에러 처리 용이
    📌 성능적 개선
        ∙ 시스템이 스레드 관리
        ∙ continuation으로 스레드 증가 방지
        ∙ 컨텍스트 스위칭을 함수 호출로 대체

#Swift Concurreny의 미래

한편, WWDC에서 애플이 소개한 안전한 동시성 생태계의 최종 목표는 아래와 같습니다.

편리하고 명확한 비동기 프로그래밍 환경 제공
Swift 개발자들이 따를 수 있는 표준 언어와 기술 제공
컴파일 타임에 비동기 코드의 성능 향상
데이터 레이스(data race)와 데드락(deadlock)의 제거

수차례의 release를 통해 이러한 목표를 달성할 예정인데, 이는 크게 두 단계로 나눌 수 있습니다.

✅ Swift Concurrency의 2단계
    1. async, await 문법과 actor 타입의 등장
    2. full actor isolation (독립성)

첫 번째 단계는 async/await API를 도입해 언어적, 성능적 관점에서의 개선을 이뤄냅니다. 이 과정에서 발생 가능한 data race를 줄이기 위한 방식으로 actor 타입을 제안합니다.

두 번째 단계는 data race를 줄이는 것이 아닌, 완전한 제거를 목표로 full actor isolation 한 생태계를 조성하는 것입니다. 이를 위한 다양한 기능들도 함께 제공하는 것이 목표입니다.

Swift 5.6까지 release된 현재 시점에서 살펴본 Swift Concurrency에는 첫 번째 단계가 충분히 반영되었다고 느낄 만큼 큰 변화를 체감할 수 있었습니다. 또, 여러 공식 문서를 통해 Swift가 얼마나 safe-by-default함을 중시하고 있는지 옅볼 수 있는 기회였습니다.

이번 글에서는 async/await의 동작만 살펴봤지만, data race를 회피할 수 있는 동시성 프로그래밍을 위한 actor 타입과 task의 우선순위와 취소 기능을 위해 Structured Concurrency에 도입된 API 등 추가로 이해해야 할 개념이 많습니다.

아직 Swift 동시성 모델 없이 개발된 코드들이 많이 존재합니다. 하지만 시간이 지남에 따라 Swift의 동시성 모델의 제약조건에 맞게 바꿀 일이 생길 것이라고 생각합니다. 마이쿠키런 iOS 팀에서는 이런 변화에 대응하기 위한 기술 스터디를 진행하며 쿠키런 팬들을 위한 플랫폼 서비스를 만들고 있습니다.

이 글을 흥미롭게 읽으셨거나, 이미지 처리 혹은 서비스 개발에 관심이 많으신 iOS 개발자님이 계시다면 지금 당장 마이쿠키런의 n번째 바삭한 쿠키가 되어주세요! 🍪

긴 글 읽어주셔서 감사합니다.

9가지 프로그래밍 언어로 배우는 개념: 2편 - 다형성

Tue, 09 Aug 2022 00:00:00 GMT

#프로그래밍 언어 시리즈

9가지 프로그래밍 언어로 배우는 개념: 1편 - 타입 이론
9가지 프로그래밍 언어로 배우는 개념: 2편 - 다형성
9가지 프로그래밍 언어로 배우는 개념: 3편 - 메타프로그래밍
9가지 프로그래밍 언어로 배우는 개념: 4편 - 하이 레벨 언어와 동적 타입 언어
9가지 프로그래밍 언어로 배우는 개념: 5편 - 동시성 프로그래밍

#서론

안녕하세요, 킹덤 서버 소프트웨어 엔지니어 지민규입니다. 프로그래밍에 있어 추상화만큼이나 중요한 것은 다형성입니다. 다형성으로 인해 다양한 데이터 타입과 오브젝트의 재사용이 가능해지며 필요한 코드의 양을 획기적으로 줄입니다. 다형성을 이룩하는 방법에는 여러가지가 있으며 흔히 객체 지향 프로그래밍(Object-oriented Programming)의 특징으로 다형성이 꼽히곤 하지만 사실 절차적 프로그래밍(Procedural Programming) 언어이든 함수형 프로그래밍(Functional Programming) 언어이든 다형성을 어떠한 방식으로든 지원하는 경우가 많습니다. 이번 글에서는 언어 기능으로서의 다형성들을 나열하고 비교합니다.

#오버로딩

**오버로딩(Overloading)**은 같은 함수명에 다른 입출력 타입들을 가진 함수를 정의하여 하나의 함수 이름으로 묶을 수 있는 기능입니다. 프로그래밍에서는 이름이 추상화의 기초 요소라는 점을 생각해보면 오버로딩은 다형성 기법이라기보다 추상화 기법에 가깝다고도 생각할 수 있습니다. 두 숫자를 받아서 합을 출력하는 함수를 int와 float 버전으로 구현해봅시다. C의 경우 오버로딩이 없기 때문에 서로 다른 함수 이름으로 구현해야 합니다.

// C 코드
int addInt(int a, int b) {
  return a + b;
}

float addFloat(float a, float b) {
  return a + b;
}

C++에서는 오버로딩이 추가되었기 때문에 다음과 같이 처리가 가능합니다.

// C++ 코드
// A함수: int끼리 add 하는 함수
int add(int a, int b) {
  return a + b;
}

// B함수: float끼리 add 하는 함수
float add(float a, float b) {
  return a + b;
}

int a = add(1, 1);       // 여기서는 int끼리 add 하는 A함수를 쓴다.
float b = add(1.0f, 1.0f); // 여기서는 float끼리 add 하는 B함수를 쓴다.

하지만 오버로딩은 남용될 가능성이 있습니다. 함수 간의 동작 차이가 클 경우 함수가 어떤 일을 할지 예측하기 어려워지며 직관성을 떨어트리고 실수로 잘못된 함수를 부를 가능성이 있습니다.

// C/C++ 코드
int getGrade(int score) {
  return a * 2 / 100;
}

int getGrade(string gradeString) {
  return toInt(trim(a));   // 앞뒤 공백 삭제 후 int로 파싱
}

int b = getGrade(getScore()); // 과연 어느 함수가 호출될까?

Go와 Rust는 오버로딩이 가져오는 이점보다 위험성이 더 높다고 판단하여 오버로딩을 지원하지 않습니다.

오버로딩과 유사한 기능으로는 인수 기본 값 기능입니다. 인수 기본 값이란 함수를 호출할 때 인수의 값을 지정하지 않았을 경우, 대신 기본 값을 넣어주는 기능입니다. 인수 기본 값은 하나의 함수 블록을 사용하므로 오버로딩에 비해 상대적으로 안전하나, 여전히 잘못 사용하면 버그를 가져옵니다.

// C++ 코드
// score의 기본값은 100으로 설정한다
int getGrade(int score = 100) {
  return a * 2 / 100;
}

int score = getScore();
int grade = getGrade(); // 실수로 score 변수를 사용하지 않았다!

#인터페이스

**인터페이스(Interface)**는 대부분의 프로그래밍 언어가 어떠한 형태로든 지원하는 다형성 기법입니다. 하지만 언어마다 걸린 제약과 기능이 조금씩 다릅니다. 과거 Java, C#의 인터페이스에는 추상 메소드만을 포함할 수 있었으나, 최근에는 인터페이스 메소드에 구현을 포함할 수 있게 되었습니다.

// Java 코드
public interface Food {
  int getCalories();
  int getWeight();

  default float getCaloriesPerWeight() {
   return getCalories() / getWeight();
  }
}

인터페이스를 이용하면 다음과 같은 방식으로 다형성을 이룰 수 있습니다.

// Java 코드
public interface Food {
  int getCalories();
}

public class Pizza implements Food {
  int sliceCount; // 피자 조각 개수

  @Override public int getCalories() {
    return sliceCount * 300;
  }
}

public class Burger implements Food {
  public enum BurgerType { CHEESE, BACON_CHEESE }

  BurgerType burgerType;  // 버거의 종류

  @Override public int getCalories() {
    switch (burgerType) {
      case CHEESE:
        return 700;
      case BACON_CHEESE:
        return 900;
    }
  }
}

Food pizza = cookPizza();
Food burger = cookBurger();

// 하나의 Food 타입으로 두 가지 다른 동작을 한다.
int pizzaCalories = pizza.getCalories();
int burgerCalories = burger.getCalories();

이러한 합 타입 데이터에 대한 인터페이스는 타입 이론 포스트에서도 이야기했듯 완전 패턴 매칭으로 대체할 수 있습니다. 완전 패턴 매칭을 이용하면 더 직관적이고 문맥에 맞는 코드를 구현할 수 있습니다.

// Scala 코드
sealed trait BurgerType
case object Cheese extends BurgerType
case object BaconCheese extends BurgerType

sealed trait Food
case class Pizza(pieceCount: Int) extends Food
case class Burger(burgerType: BurgerType) extends Food

def getCalories(food: Food): Int = food match {
  case Pizza(pieceCount)  =>
    pieceCount * 300
  case Burger(burgerType) =>
    burgerType match {
      case Cheese      => 700
      case BaconCheese => 800
    }
}

val food: Food = getPizza()
val calories: Int = getCalories(food)

// Rust 코드
pub enum BurgerType {
  Cheese,
  BaconCheese,
}

pub enum Food {
  Pizza { piece_count: i32 },
  Burger{ burger_type: BurgerType },
}

pub fn get_calories(food: &Food) -> i32 {
  match food {
    Food::Pizza { piece_count }  => piece_count * 300,
    Food::Burger { burger_type } =>
      match burger_type {
        BurgerType::Cheese      => 700,
        BurgerType::BaconCheese => 800,
      },
  }
}

let food: Food = get_pizza();
let calories: i32 = get_calories(&food);

#제네릭

**제네릭(Generics)**은 함수나 타입을 선언할 때 고정된 타입 뿐만 아니라 가변적인 타입을 사용할 수 있게 해줍니다. 어떤 타입이 사용되는지는 함수를 호출하거나 타입의 인스턴스를 생성할 때 결정됩니다. 제네릭 타입은 특히 자료 구조 타입에서 자주 쓰입니다.

// Java 코드
public class ArrayList<T> {
  private T[] elementData;
  private int size;

  public boolean add(T e) {
    /* ... */
    elementData[size++] = e;
    return true;
  }
}

ArrayList<Integer> intList = new ArrayList<Integer>();
ArrayList<String> stringList = new ArrayList<String>();

// ArrayList<Integer>의 add는 Integer를 받는다
intList.add(5);
intList.add(10);
intList.add(15);

// ArrayList<String>의 add는 String를 받는다
stringList.add("one");
stringList.add("two");
stringList.add("three");

그러나 제네릭 함수는 Java나 C#과 같은 상속 기반의 객체 지향 프로그래밍 언어에서는 상대적으로 적게 쓰입니다. 상속을 위시로 한 다형성은 데이터 타입을 그대로 인수로 전달하는 경우보다 인터페이스나 추상 클래스를 사용하는 경우가 많습니다. 다만 입출력 타입에 제네릭을 사용하고 있다면 제네릭 함수는 필수적입니다.

// Java 코드
// value를 size 만큼 채워서 ArrayList를 출력하는 함수
public <T> ArrayList<T> fill(T value, int size) {
  ArrayList<T> ret = new ArrayList<T>();
  for (int i = 0; i < size; i++) {
    ret.add(value);
  }
  return ret;
}

// a와 b를 비교해서 더 높은 것을 출력하는 함수
// T는 Comparable<T> 인터페이스를 구현하고 있어야 한다
public <T extends Comparable<T>> T max(T a, T b) {
  if (a.compareTo(b) >= 0) {
    return a;
  } else {
    return b;
  }
}

C++의 제네릭은 **템플릿(Template)**이라고 부릅니다. 템플릿은 다른 언어의 제네릭과 비교하면 특이한 점이 많은데 타입 인수에 들어간 타입이 마치 틀로 찍어낸 듯이 대입되어 함수가 구현된 것과 같습니다. 임의의 타입 2개를 받아서 더하는 add 함수를 구현할 때 템플릿을 이용하면 인터페이스 없이, 하나의 함수로 구현할 수 있습니다.

// C++ 코드
template<typename T>
T add(T a, T b) {
  return a + b;
}

int a = add<int>(10, 5);          // 여기서는 T가 int이다.
float b = add<float>(7.5f, 2.0f); // 여기서는 T가 float이다.

// T 위치에 지정된 타입을 치환하여 따로 구현한 것과 동일하다.
// int add(int a, int b) {
//   return a + b;
// }
//
// float add(float a, float b) {
//   return a + b;
// }

C++의 템플릿은 필드 접근도 일반화시킬 수 있습니다. 심지어 필드가 서로 다른 타입이어도 상관없습니다.

// C++ 코드
template<typename T>
void printValue(T a) {
  cout << a.value << endl;
}

struct A {
 int value;
};

struct B {
 float value;
};

A a = { 5 };
B b = { 10.5f };
printValue(a);
printValue(b);

이처럼 C++의 템플릿은 C/C++의 매크로와 필적할 정도로의 강력함을 가지고 있습니다. 그러나 단점도 많은데 그중 하나가 Variance가 잘 적용되지 않는다는 점입니다.

#Variance

Variance는 제네릭 타입간의 자연스러운 타입 캐스팅을 지원해주는 기능입니다. 제네릭 타입을 사용할 때 간혹 내부 T 타입을 바꿔줘야 원활한 경우가 있는데 구현에 따라 캐스팅이 안전한 타입이 있고 캐스팅이 안전하지 않은 타입들이 있습니다. Variance가 있으면 이러한 타입 캐스팅이 유효한지 컴파일 타임에 검증해줄 수 있습니다.

Variance는 특이하게도 각각의 프로그래밍 언어들이 서로 다른 방식으로 구현하고 있습니다. C++에서는 템플릿 특성상 Variance를 지원하지 않으며, C#, Kotlin은 인터페이스에서만 Variance를 허용하고 있고 Typescript에서는 모든 제네릭 타입에 Variance를 활용할 수 있습니다. Rust의 경우 로우 레벨 언어 특성상 Variance를 적용할 때의 세세한 규칙들이 있습니다.

// C# 코드
// 인터페이스에서만 활용 가능하다
IEnumerable<string> stringList = new List<string>();
IEnumerable<object> objectList = stringList;

// Kotlin 코드
// 인터페이스에서 활용 가능하다
val intList: List<Integer> = listof()
val objectList: List<Object> = intList

// Scala 코드
// 자유롭게 가능하다
val intList: List[Int] = List()
val anyList: List[Any] = intList

// Typescript 코드
let intArray: Array<number> = []
let anyArray: Array<any> = intArray

// Rust 코드
let i32Box: Box<i32> = Box::new(4);
let anyBox: Box<dyn Any> = i32Box;

위 예시에서는 Integer가 Object가 되는 예시를 들었는데 반대로 Object가 Integer가 되는 것만 허용되는 경우도 있습니다. C#의 IComparer<T>가 그 예시입니다.

// C# 코드
// C#의 IComparer<T>의 대략적인 구현
public interface IComparer<in T> {
  int Compare(T x, T y);
}

IComparer<object> objectComparer;

// stringComparer에 objectComparer를 대입할 수 있다.
IComparer<string> stringComparer = objectComparer;

Variance는 기본적으로 **업캐스팅(Upcasting)**을 기반으로 하고 있습니다. 업캐스팅이란 타입의 계층 구조에서 하위 계층에 존재하는 타입은 상위 계층으로 아무 위험성 없이 캐스팅 될 수 있다는 것을 가리킵니다. C#에서 string은 object를 상속 받고 있기 때문에 object에 대입할 수 있습니다

// C# 코드
string str = "Hi";
object obj = str;

이는 곧 String를 출력하는 함수는 곧 Object를 출력하는 함수로 취급해도 괜찮다는 것을 의미합니다.

// C# 코드
// int를 string으로 변환시키는 익명 함수
Func<int, string> toString = x => x.ToString();

// 출력 타입을 object로 취급해도 괜찮다
Func<int, object> func = toString;

// 어차피 둘 다 출력을 object 타입에 대입시킬 수 있다
object toStringOut = square(5);
object funcOut = func(5);

이것을 인터페이스의 맥락으로 가져오면 다음과 같습니다.

// C# 코드
public interface IGenerator<out T> {
  T Generate();
}

// string를 생성하는 인터페이스
public class StringGenerator : IGenerator<string> {
  public string Generate() {
    return "Hi";
  }
}

// int generate() 메소드는 Object generate()로 변환이 가능하다
IGenerator<string> stringGenerator = new StringGenerator();
IGenerator<object> objectGenerator = stringGenerator;

이렇게 하위 타입 T가 상위 타입으로 변환될 수 있는 경우를 Covariant이라고 부릅니다.

그렇다면 반대의 경우는 어떨까요?

// C# 코드
// object를 string으로 변환시키는 익명 함수
Func<object, string> toString = x => x.ToString();

// 입력 타입을 string으로 취급해도 괜찮다
Func<string, string> func = toString;

// 어차피 둘 다 입력으로 string를 받을 수 있다
string toStringOut = toString("hello");
string funcOut = func("hi");

// 인터페이스에서는...
public interface IConsumer<in T> {
  void consume(T v);
}

// object를 입력받는 인터페이스
public class ObjectConsumer : IConsumer<object> {
  public void consume(object v) {
    Console.WriteLine(v.ToString());
  }
}

// void consume(object value) 메소드는
// void consume(string value)로 변환이 가능하다.
IConsumer<object> objectConsumer = new ObjectConsumer();
IConsumer<string> stringConsumer = objectConsumer;

상위 타입T가 하위 타입으로 변환될 수 있는 경우를 Contravariant이라고 부릅니다.

Variance의 방향은 제네릭을 어떤 방식으로 활용하고 있는지에 따라 갈립니다. T를 출력하는 메소드가 있다면 Covariant, 입력으로 T를 받는 메소드가 있다면 Contravariant가 되고 타입의 필드에서 T를 어떤 방식으로 활용하고 있는지도 중요합니다.

그렇다면 Java의 ArrayList<T> 같이 T를 입력 받기도 하고 T를 출력하기도 하는 타입은 어느 것일까요? 정답은 “둘 다 아니다” 입니다. ArrayList<T>의 T는 바꿀 수 없고 이 경우를 Invariant 이라고 부릅니다.

Scala의 합 타입은 상속을 이용하여 구현되어있기 때문에 합 타입의 하위 타입과 상위 타입간의 업캐스팅이 가능합니다.

// Scala 코드
sealed trait Fruit
case class Apple(weight: Int) extends Fruit
case class Banana(length: Int) extends Fruit

val appleList: List[Apple] = List()
val fruitList: List[Fruit] = appleList

#인터페이스의 한계

제네릭과 Variance에 대해서 충분히 이해했다면 상속이 있는 언어들에서 인터페이스에 담긴 언어적 한계를 파악할 수 있습니다. 인터페이스에는 총 두 가지의 문제점이 있습니다.

자기 자신의 타입을 사용하는 메소드를 선언할 수 없다.
정적 메소드를 추상 메소드로 선언할 수 없다.

먼저 첫 번째 문제를 파헤쳐봅시다, 자기 자신의 타입을 사용하는 메소드를 선언할 수 없다는 것이 무슨 의미일까요? 가령 Java에서 숫자 타입의 덧셈을 인터페이스로 구현해봅시다. int의 덧셈 메소드는 int 인수를 받고 덧셈을 하여 int를 출력 해야합니다. double의 덧셈 메소드는 double을 받고 덧셈을 하여 double을 출력 해야 합니다. 이러한 덧셈을 하나의 인터페이스로 일관화 시킬 수 있을까요? Java는 int에 메소드를 추가할 수 없으므로 int를 감싸는 CustomInt 타입으로 인터페이스를 충족시켜봅시다.

// Java 코드
public interface Addable {
  Addable add(Addable value); // CustomInt를 사용할 수 없다
}

public class CustomInt implements Addable {
  public int value;

  public CustomInt(int value) {
    value = value;
  }

  @Override public Addable add(Addable rhs) {
    return new CustomInt(value + ((CustomInt) rhs).value); // 캐스팅 해야 함
  }
}

Addable a = new CustomInt(10);
Addable b = a.add(new CustomInt(5)); // Addable 타입이 출력된다

Addable 인터페이스에서 메소드에 CustomInt를 명시할 수 없으므로 어쩔 수 없이 Addable에 제네릭 T를 추가하고 CustomInt가 Addable<CustomInt>를 상속받도록 해야 합니다.

// Java 코드
public interface Addable<T> {
  T add(T value);
}

public class CustomInt implements Addable<CustomInt> {
  public int value;

  public CustomInt(int value) {
    value = value;
  }

  @Override public CustomInt add(CustomInt rhs) {
    return new CustomInt(value + rhs.value);
  }
}

Addable<CustomInt> a = new CustomInt(10);
CustomInt b = a.add(new CustomInt(5)); // CustomInt 타입이 출력된다

이런 방식으로 구현하면 어느정도 해결되는 것 처럼 보입니다. 하지만 CustomInt를 상속받기 시작하면 문제가 나타납니다.

// Java 코드
public class CustomComplex extends CustomInt {
  public int imaginaryValue;

  public CustomComplex(int value, int imaginaryValue) {
    super(value); // 부모의 생성자 활용
    imaginaryValue = imaginaryValue;
  }

  // 나머지 함수는 그대로 상속받는다
}

CustomComplex a = new CustomComplex(1, 2);
CustomInt b = a.add(new CustomComplex(3, 4)); // CustomInt가 출력된다!!!

Addable<T> 인터페이스의 메소드를 곰곰히 생각해보면 T를 입력으로 받고 T를 출력하기 때문에 Invariant입니다. 그러므로 하위 타입인 CustomComplex가 Addable<CustomInt>의 메소드를 사용할 수 있는 것은 옳지 않습니다. 그러나 이를 무시하고 추가한 결과 CustomComplex의 add 메소드는 CustomInt 타입을 출력하고 있습니다. 상속과 Variance를 섞어서 활용할 경우 이러한 모순적인 코드 나타납니다.

두번째 문제로 넘어갑시다. 9개의 언어 중 Rust를 제외하고 정적 메소드를 추상 메소드로 구현 할 수 있는 언어는 없습니다. 정적 추상 함수는 일반적으로는 의미가 없으나 제네릭과 함께 사용할 때 매우 유용합니다. 예를 들어 인스턴스 생성 함수를 인터페이스 메소드로 추가할 수 있습니다.

// Java 코드, 주의: 컴파일할 수 없는 코드
public interface Entity {
  Entity parseFromString(String string);
}

public class Human implements Entity {
  private String name;

  @Override public Entity parseFromString(String string) {
    Human human = new Human();
    human.name = string;
    return human;
  }
}

public class Sword implements Entity {
  private int attackPoint;

  @Override public Entity parseFromString(String string) {
    Sword sword = new Sword();
    sword.attackPoint = Integer.parseInt(string);
    return sword;
  }
}

// T는 Entity를 상속받음
public <T extends Entity> Entity parseEntityFromString(String string) {
  return T.parseFromString(string);
}

Entity human = parseEntityFromString<Human>("mango");
Entity sword = parseEntityFromString<Sword>("120");

이 문제 때문에 일반적으로 객체 지향 프로그래밍 언어에서는 **팩토리 패턴(Factory Pattern)**으로 우회해서 구현합니다. 하지만 이는 코드의 불필요한 복잡도 상승과 오브젝트 간의 강한 결속을 야기합니다.

Java, C#, Kotlin 등의 객체 지향 프로그래밍 언어에서 제네릭 함수의 활용성이 떨어지는 것은 이러한 인터페이스의 한계점과 연관이 있습니다. 그렇다면 Scala나 Rust에서는 어떠한 방식으로 해결되었을까요?

#타입클래스

타입클래스는 인터페이스와 비슷하게, 타입간에 공통된 추상 함수를 지정할 수 있습니다. 다만 인터페이스는 타입의 메소드로 구현하지만 타입클래스는 타입과 분리된 영역에서 함수들을 구현합니다. 그렇기 때문에 상속 문제에서 자유로우며 모든 함수가 자연스럽게 정적이므로 정적 메소드 문제는 피할 수 있습니다.

Scala는 숫자 타입의 연산 타입클래스를 다음과 같이 일반화하여 제공하고 있습니다.

// Scala 코드
// "숫자"를 위한 타입클래스
// 인터페이스와 제네릭을 섞어서 타입클래스를 만든다
trait Numeric[T] {
  def plus(lhs: T, rhs: T): T
  /* ... */
}

// Numeric를 상속받지 않는다
case class CustomInt(value: Int)

// Numeric[CustomInt]의 정의
implicit val numeric: Numeric[CustomInt] =
  new Numeric[CustomInt] {
    def plus(lhs: CustomInt, rhs: CustomInt): CustomInt =
      CustomInt(lhs.value + rhs.value)
    /* ... */
  }

// T는 Numeric 타입클래스를 가지고 있어야 한다
def addThree[T: Numeric](first: T, second: T, third: T) =
  first + second + third

// addThree 함수를 자유롭게 사용할 수 있다
val intAdds: Int =
  addThree(5, 10, 20)

val customIntAdds: CustomInt =
  addThree(CustomInt(5), CustomInt(10), CustomInt(20))

val floatAdds: Float =
  addThree(0.5, 1.2, 500.0)

Rust의 인터페이스에 해당하는 trait는 자기 자신 타입을 지정할 수 있습니다. 이것이 가능한 이유는 Rust는 상속 자체가 없어 부모로부터 잘못된 메소드를 상속받을 일이 없기 때문입니다. 또한 Rust는 인터페이스에서 정적 메소드도 선언할 수 있습니다. 이러한 점들을 살펴보면 Rust의 trait는 타입클래스와 많이 닮아 있다는 것을 알 수 있습니다.

// Rust 코드
// 덧셈을 위한 trait, Self는 자기 자신 타입이다
pub trait Add<Rhs = Self> {
  type Output;
  fn add(self, rhs: Rhs) -> Self::Output;
}

// Rust에는 상속이 없다
#[derive(Clone)]
struct CustomInt(i32);

// Add trait 정의
impl Add for CustomInt {
  type Output = CustomInt;
  fn add(self, other: Self) -> Self {
    CustomInt(self.0 + other.0)
  }
}

// T는 Add<Output = T>를 구현하고 있어야한다
pub fn add_three<T: Add<Output = T>>(first: T, second: T, third: T) -> T {
  first + second + third
}

// Add 함수를 자유롭게 사용할 수 있다.
let int_adds: i32 =
  add_three(5, 10, 20);

let custom_int_adds: CustomInt =
  add_three(CustomInt(5), CustomInt(10), CustomInt(20));

let float_adds: f32 =
  add_three(0.5, 1.2, 500.0);

이렇게 주요 프로그래밍 언어들의 다형성 기능들을 대부분 살펴보았는데요, 이렇듯 언어들이 한 가지 다형성만이 아닌 여러가지 다형성을 제공하는 이유는 다형성마다 장단점이 있고 적절한 장소에 적당한 다형성 기능을 사용할 수 있게 해주기 때문입니다.

하지만 다형성을 사용한다고 해서 언제나 소프트웨어 아키텍처를 확장할 때 코드의 양이 필요한 만큼만 작성되는 것이 아니며 때로는 위 다형성 기능들로 해결이 안되는 반복적인 **보일러플레이트 코드(Bolierplate code)**가 작성되어야하기도 합니다. 다음 편에서는 이러한 보일러플레이트 코드가 어떻게 **메타 프로그래밍(Metaprogramming)**으로 해결되는지 다루고자 합니다.

#부록

#프로그래밍 언어 기능별 지원표, 2022년 5월 기준

언어 자체 기능 혹은 정규 라이브러리만 포함하고 있습니다.

	C	C++	C#	Java	Kotlin	Scala	Rust	Typescript	Go
Nullable Type	X	X	O	O	O	O	O	O	X
합 타입	X	X	X	O	O	O	O	O	O
합 타입 완전 패턴 매칭	X	X	X	O	O	O	O	부분적	X
오버로딩	X	O	O	O	O	O	O	O	X
상속	X	O	O	O	O	O	X	O	X
오버라이딩	X	O	O	O	O	O	O	O	X
타입 클래스	X	X	X	X	X	O	O	X	X
제네릭	X	O	O	O	O	O	O	O	O
타입 선언부 Variance	X	X	인터페이스만	X	인터페이스만	O	O	O	X

#아쉽게도 다루지 못한 다른 다형성 기능들

Wildcard (Java의 개념), Type Projection (Kotlin의 개념)
Associated Type
Kind (Higher-kinded types)
덕 타이핑(Duck typing)
Constraint (C++의 개념)

#힙스터라면 공부해볼 만한 다른 언어들

Assembly
- 바로 그 어셈블리
- C보다도 로우 레벨
- 스택, 함수 호출, 다양한 최적화의 원리를 이해해보자
Carbon
- 정적 타입
- 로우 레벨
- Better C++ 계열
- 2022년 7월 공개된 언어
D
- 정적 타입
- 로우 레벨
- Better C++ 계열
Erlang, Elixir
- 동적 타입
- 함수형
- 모든 것은 액터 모델
- Fault-tolerant
Haskell
- 정적 타입
- 순수 함수형
Jai
- 정적 타입
- 로우 레벨
- 메타 프로그래밍 특화
Julia
- 동적 타입
- 고성능
- 계산 수학
OCaml
- 정적 타입
- 함수형 패러다임 입문용으로 나쁘지 않음
Zig
- 정적 타입
- 로우 레벨
- Better C 계열

Unity 프로젝트를 위한 Git Hooks 활용

Tue, 02 Aug 2022 00:00:00 GMT

안녕하세요. 저는 쿠키런 킹덤에서 게임 클라이언트를 개발하고 있는 이규호입니다. 게임 클라이언트란 플레이어 분들의 기기에 설치돼서 게임 서버와 통신하며 게임 화면을 표시하고 플레이어 분들의 입력에 맞게 게임 로직을 실행하는 소프트웨어입니다.

일반적으로 게임 클라이언트 개발자의 주된 업무는 게임 엔진 등을 활용하여 실제 게임에 들어가는 컨텐츠 및 기능을 구현하는 것입니다. 하지만 게임 개발 조직 안에서 발생하는 다양한 비효율을 해소하고 게임 개발 과정이 빠르고 문제 없이 진행될 수 있도록 여러 가지 노력을 기울이는 것도 클라이언트 개발자의 중요한 임무 중 하나일 것입니다. 이 글에서는 그러한 노력의 일환으로 Unity 엔진과 Git을 사용하는 프로젝트에서 Git Hooks를 활용한 경험을 공유하고자 합니다.

이 글의 작성 시점에서 Git의 최신 버전은 2.37.1이며 Unity는 2022.1.8까지 릴리즈되었습니다. 추후 각 소프트웨어 및 개발 환경이 업데이트됨에 따라 이 글에 언급된 내용 중 일부가 더이상 유효하지 않게 되거나 더 나은 방법이 생길 수 있습니다.

#서론

진짜_진짜_최종 같은 접미사가 붙는 파일이 담긴 USB 메모리를 손에서 손으로 주고받으며 버전 관리를 한다는 괴담이 실없는 농담이 된 시대입니다. 오늘날 대부분의 소프트웨어 개발 조직은 한 개 이상의 버전 관리 시스템을 사용하고 있을 것입니다. 그 중에서도 가장 대중적인 것은 리누스 토르발스가 Linux 커널 프로젝트를 관리하기 위해 만든 Git입니다. 2005년에 처음으로 공개된 이래로 Git은 꾸준히 발전해 왔으며 Git을 활용하는 전략도 점점 진보해 왔습니다.

#GitFlow를 활용한 원활한 버전 관리

대표적인 Git 활용 전략으로는 GitFlow가 있습니다. 일반적인 서비스 백엔드 프로젝트에서 GitFlow를 따르는 개발 과정은 다음과 같을 것입니다.

새 피쳐 구현을 위해 새 브랜치를 생성합니다. 이 피쳐 브랜치에서는 상대적으로 소수의 소프트웨어 엔지니어가 작업합니다.
구현이 끝나면 풀 리퀘스트(혹은 머지 리퀘스트)를 생성하고 CI와 다른 동료들의 코드 리뷰를 통해 작업 내용을 꼼꼼히 점검한 후 이를 메인 브랜치에 머지합니다.

이 경우 브랜치 히스토리는 마치 각자의 레인에서 안정적인 크롤 영법을 구사하는 수영 숙련자들처럼 깔끔한 평행선을 그립니다. 여러 개의 큰 피쳐를 연이어 머지하는 경우가 아니면 각 커밋은 막힘 없이 나아가고 문제가 생기더라도 수영하는 사람들이 다들 수영을 잘 하기 때문에 크게 고생하는 경우는 적습니다.

#게임 클라이언트 프로젝트의 개발 양상

그러나 게임 클라이언트 프로젝트의 개발 과정은 이와 다른 경우가 많습니다. 필요에 따라 여러 개의 마이크로 서비스로 분리하는 것을 지향하는 현대적 서비스 백엔드 아키텍쳐와 달리 게임 클라이언트는 기본적으로 모놀리식한 구조이며 상대적으로 더 많은 인원이 하나의 저장소에 커밋을 밀어넣습니다. 인원의 구성도 소프트웨어 엔지니어에 한정되지 않고 게임 디자이너, 아티스트 등 다양한 직군의 동료들이 개발에 참여합니다. 따라서 GitFlow를 따를 경우 다음과 같은 문제가 발생합니다.

게임 내 각 피쳐 및 각 직군 간의 작업물이 상호 의존적인 경우가 많습니다. 따라서 피쳐 브랜치를 잘게 분리하기 어려우며 한 브랜치에 다양한 팀원이 커밋하게 됩니다.
구현된 사항을 즉각 시험해보며 최대한 짧은 주기의 피드백 루프를 여러 번 거쳐 재미를 검증해야 합니다. 메인 브랜치에 가급적 여러 기능이 빠르게 반영되어 중간 구현 결과를 시험해 볼 수 있는 편이 유리합니다.

이에 보다 적합한 Git 활용 전략은 모두가 메인 브랜치에 커밋을 밀어넣는 트렁크 기반 개발일 것입니다. 그래서 개발 과정은 레인이 나뉜 실내 수영장보다는 워터파크의 파도 풀장에 가까운 양상을 띱니다. 수많은 사람이 한 풀장에 들어가며 레인 같은 것은 나뉘지 않으니 수영을 하던 사람들끼리 부딪히는 일도 잦습니다.

사람들이 모두 수영에 능숙한 것도 아닙니다. Git은 기본적으로 커맨드라인 인터페이스로 작동하는 도구이며 파일 시스템이나 트리 구조, 참조 등의 멘탈 모델에 근거하다 보니 아무래도 소프트웨어 엔지니어 이외 직군의 동료들은 Git에 덜 익숙한 편입니다. 그래서 혼잡한 파도 풀장에서 문제가 발생할 경우 수영에 보다 능숙한 소프트웨어 엔지니어의 도움이 필요할 때가 많습니다.

더군다나 파도 풀장에는 수영복을 입은 사람들 이외에도 튜브, 스노클, 구명조끼, 풀장 옆 매점에서 파는 츄러스 등 정말 다양한 것들이 들어옵니다. 코드 이외에도 아트워크, 사운드 리소스 등 다양한 에셋이 프로젝트 저장소에 올라오며 이러한 파일이 코드보다 더 큰 비중을 차지합니다. 그리고 다양한 종류의 물건은 다양한 문제를 일으킵니다.

#파도 풀장의 파수꾼

이런 피서철의 혼잡한 파도풀에는 사고를 예방할 안전 요원이 필요합니다. 일반적으로 CI(Continuous Integration, 지속적 통합)가 그러한 역할을 맡지만 게임 클라이언트 프로젝트의 경우에는 CI만으로는 충분하지 않습니다. 이전에 올린 커밋의 CI가 채 돌기도 전에 새 커밋이 끊임없이 올라오기 때문에 중간에 문제가 있는 커밋이 생길 경우 CI는 명절 고속도로 IC에 늘어선 차량들의 브레이크등처럼 기나긴 빨간 불의 행렬을 띄웁니다. 이 경우 어느 커밋에서부터 어떤 문제가 생겼는지 추적하기가 번거롭습니다.

CI가 띄우는 경고를 읽고 대처하는 것은 대개 소프트웨어 엔지니어의 역할입니다. 프로젝트 저장소에 문제가 생겨서 교통 체증이 발생하면 다른 동료들의 작업이 모두 지장을 받기 때문에 하던 작업을 내려놓고 높은 우선순위로 대응해야 하며, 때문에 문제가 빈번하게 발생할수록 주 업무에 할애할 집중력과 시간이 고갈됩니다. 따라서 소프트웨어 엔지니어 스스로의 생산성 향상을 위해서라도 CI보다 즉각적으로 예방 효과를 발휘할 수 있는 수단이 필요합니다. 그 수단 중 하나로 Git Hooks를 소개하고자 합니다. 물론 Git Hooks는 보편적인 기능이다 보니 소개라고 하기에는 다소 새삼스럽습니다. 이 글이 뻔한 내용이 되지 않도록 쿠키런 킹덤에서 사용하는 Unity 개발 환경에서 Git Hooks를 활용해 온 주관적이고 덜 보편적인 경험과 의견을 공유하겠습니다.

#Git Hooks란

Git Hooks(이하 “Hook”으로 짧게 적겠습니다)는 Git에서 특정 이벤트가 발생할 때 호출되는 스크립트이며 기본적으로 저장소 루트 디렉토리의 .git/hooks 경로 안에 위치합니다.

프로젝트에서 발생할 문제를 예방하기 위해 가장 많이 사용하는 이벤트는 pre-commit 입니다. 이는 커밋 시 가장 먼저 발생하는 이벤트로 커밋 메시지를 작성하기 전 단계에 발생합니다. (물론 git commit -m 옵션이나 GUI 클라이언트로 커밋 메시지를 함께 전달하는 경우 이 이벤트가 발생한 후 따로 커밋 메시지 작성을 요구하지 않습니다.) 0 이외의 Exit Code를 리턴하면 커밋이 취소되기 때문에 커밋을 검사 후 문제가 생길 경우 Exit Code를 통해 커밋을 취소하는 방식으로 문제 예방에 활용할 수 있습니다.

Hook은 대개 셸 스크립트로 작성되지만 다음의 사례처럼 생산성과 유지보수, 혹은 기능적, 성능적 필요에 의해 다른 프로그래밍 언어로 HookHook 작성하는 경우도 많습니다.

Git LFS(Git Large File Storage): Git은 기본적으로 소스 코드와 같은 평문(Plain Text) 파일의 버전 관리에 용이한 시스템입니다. Git LFS는 이미지나 오디오처럼 용량이 큰 바이너리 등의 파일을 별도의 원격 저장소에 저장해 효율적으로 관리하기 위한 도구로, 일반 Git 저장소에는 해당 파일의 레퍼런스를 저장하고 post-commit, post-checkout 등의 이벤트에서 Hook을 실행해 해당 레퍼런스와 원격 저장소의 파일을 동기화하는 방식으로 동작합니다. Go로 작성되었습니다.
Gitmoji CLI: Gitmoji는 커밋 메시지 앞에 작업의 성격을 나타내는 이모지를 달아 커밋 의도를 더 쉽게 파악할 수 있게 하려는 운동입니다. Gitmoji CLI는 prepare-commit-msg 이벤트에서 작동해 커밋 앞에 편리하게 이모지를 달 수 있게 해 주는 CLI 도구이며 Node.js로 작성되었습니다.

Git Hooks는 터미널에서 Git 명령을 실행하는 경우는 물론 Fork, Sourcetree 등의 GUI Git 클라이언트에서도 문제 없이 작동합니다. 다만 Hook에서 출력하는 stdout 등의 스트림을 터미널에서는 바로 확인할 수 있으나 GUI 클라이언트에서는 0 이외의 Exit Code를 리턴하는 경우에만 로그가 출력된 오류 팝업이 열리기 때문에 그렇지 않은 경우에는 일부러 조회하지 않는 한 확인이 불가능합니다.

#자주 발생하는 문제와 Hook 활용 예시

게임 클라이언트 프로젝트 저장소에서 자주 발생하는 문제와 이를 예방하기 위해 Hook을 활용하는 예시를 몇 가지 소개하겠습니다.

#파일이나 디렉토리 이름에 잘못된 문자나 문자열이 포함된 경우

각 운영체제마다 파일 시스템에서 사용할 수 없는 문자나 문자열이 있습니다. 물론 IT 업종에 종사하는 프로들인 만큼 파일이나 디렉토리 명칭에는 가급적 문제 소지가 없는 알파벳 대소문자 및 숫자와 _(언더스코어)만으로 파일 이름을 짓는 분들이 대부분이나 간혹 실수로 인해 파일을 새로 만들거나 이름을 변경하면서 특정 OS에서 사용할 수 없는 문자나 문자열이 포함된 상태로 커밋을 올리는 경우가 있습니다.

대표적인 사례는 Windows 외의 운영체제에서 엔터 키를 누르려다가 가까이 있는 \(백슬래시)를 같이 누르는 경우입니다. MacOS, Linux에서는 파일이나 디렉토리 이름에 \를 사용할 수 있으나 Windows에서는 C:\Documents\CookieRun 등과 같이 경로 구분자로 \를 사용하기 때문에 이를 사용할 수 없습니다. 따라서 이러한 파일명이 포함된 커밋을 Windows 외의 컴퓨터에서 올린 후 Windows 컴퓨터에서 이를 체크아웃할 경우 오류가 발생합니다.

물론 특정 조건을 만족하는 문자열만 허용하는 방식이나 특정 조건을 만족하지 않는 문자열을 전부 허용하지 않는 방식으로 문제가 되는 문자 및 문자열을 모두 걸러내는 것이 최선이겠지만 간단하게 \만 걸러내는 pre-commit Hook을 예시로 작성하겠습니다.

먼저 .git/hooks/pre-commit 파일을 생성 후 텍스트 에디터로 다음과 같은 스크립트를 작성합니다.

#!/bin/sh

# 커밋으로 생성되는 파일을 나열하기 위해 현재 Index와 비교할 HEAD를 지정합니다
if git rev-parse --verify HEAD >/dev/null
then
	against=HEAD
else
	# 새로 생성해서 커밋이 없는 저장소의 경우 HEAD가 없기 때문에 빈 Tree와 비교합니다
	against=`git hash-object -t tree /dev/null`
fi

# Index에서 ADD된 파일의 이름만 순회합니다. RENAME도 ADD에 포함됩니다
git diff --cached --name-only --diff-filter=A -z $against | while IFS= read -r -d '' filename; do
	if [[ $filename =~ "\\" ]]; then
		# 사용자가 수정할 수 있도록 문제가 무엇인지 제대로 안내해야 합니다
		>&2 echo "새로 생성된 파일 \"${filename}\" 의 이름 혹은 경로에 잘못된 문자 '\'이 포함됐습니다."
		# 0이 아닌 Exit Code를 리턴해 커밋을 중단합니다
		exit 2
	fi
done

첫 줄의 Shebang이 누락되면 Hook이 실행되지 않음에 주의해야 합니다.

생성한 파일의 실행 권한을 부여하기 위해 다음 명령을 실행합니다. 이후 이름이나 경로에 \를 포함한 커밋을 시도할 경우 오류 메시지와 함께 도중에 취소됩니다.

chmod +x .git/hooks/pre-commit

#`.meta` 파일의 짝이 맞는지 검사하기

Unity 엔진은 각 에셋, 스크립트, 디렉토리 등을 프로젝트에서 사용하기 위한 추가적인 메타데이터를 정의하기 위해 Assets 디렉토리 내부의 각 파일 및 디렉토리마다 해당 대상의 이름 뒤에 .meta 가 붙는 별도의 메타데이터 파일을 생성합니다.

그러나 종종 이 .meta 파일과 원 대상이 쌍을 이루지 않는 경우가 발생합니다. 원인이 되는 대표적인 시나리오는 다음과 같습니다.

동료가 다른 툴로 작업한 파일을 저장소에 새로 가져오면서 운영체제의 파일 탐색기에서만 파일을 옮겨 두고 Unity를 실행하지 않은 채 모든 변경사항을 스테이징한 후 커밋했습니다. 이로 인해 저장소에 파일은 추가되었으나 쌍을 이루는 .meta 파일이 생성되지 않았습니다. 혹은 Unity를 거치지 않고 원본 파일만 삭제하거나 이름을 변경하는 등의 조작을 통해서도 유사한 문제가 발생합니다.
동료가 새 디렉토리를 생성했으나 안에 다른 파일을 추가하지 않았습니다. Unity는 해당 디렉토리와 쌍을 이루는 .meta 파일을 자동으로 생성했고 모든 변경사항을 스테이징한 후 커밋했습니다. Git은 디렉토리가 아니라 파일을 추적하기 때문에 빈 디렉토리는 Git으로 추적되지 않았고 이후 다른 동료가 자신의 기기에서 해당 커밋을 체크아웃했으나 추적되지 않은 빈 디렉토리는 동료의 로컬 저장소에 생성되지 않았습니다. 따라서 .meta 파일만 생성되었습니다.

이러한 불일치는 다음과 같은 번거로운 문제를 야기합니다.

.meta 파일만 있고 쌍을 이뤄야 할 원 대상이 존재하지 않는 경우 Unity는 자동으로 .meta 파일을 삭제합니다. 이 경우 다른 동료는 자신이 작업하지 않은 변경사항이 생기는 것을 보고 의아해하며 매번 이 변경사항을 폐기(Discard)하거나 스태시에 밀어넣은 후 풀을 받습니다. 이 번거로운 일은 누군가가 해당 .meta 파일을 삭제하는 커밋을 올릴 때까지 되풀이됩니다. 안타깝게도 그렇게 일단락되더라도 빈 디렉토리로 인해 생성된 .meta 파일인 경우 해당 .meta 빈 디렉토리를 로컬에 가지고 있는 동료가 .meta 파일을 계속해서 커밋하는 경우 누군가가 정확한 원인을 파악하고 해결하기 전까지는 영원한 핑퐁이 계속됩니다.
위의 만성적인 사례와 달리 원 대상은 존재하나 쌍을 이뤄야 할 .meta 파일이 존재하지 않는 경우 좀 더 즉각적인 문제가 발생합니다. 이 경우 Unity는 자동으로 .meta 파일을 생성하며, 이 .meta 파일을 여러 동료가 커밋하는 경우 .meta 파일에 기입된 guid가 각 동료의 로컬 저장소에서 일치하지 않기 때문에 처음으로 푸시한 동료를 제외한 다른 동료는 충돌(Conflict)을 겪게 됩니다. 충돌은 특히 소프트웨어 엔지니어 이외의 직군에게는 당혹스러운 경우가 많으며 “임의로 생성된 guid니 어느 쪽을 채택해서 머지하든 문제가 되지 않을 것”이라고 가볍게 넘기다가 가끔 더 번거로운 문제가 생기기도 합니다. 채택되지 않은 guid를 사용한 쪽에서 해당 에셋을 참조하는 다른 에셋이나 프리팹을 생성한 경우 guid에 맞는 대상을 찾지 못해 참조가 소실되는 문제가 발생합니다.

이러한 .meta 파일 불일치를 검사하기 위한 오픈소스 Hook이 있으며 대부분의 상황에서 잘 작동합니다. 쿠키런 킹덤 프로젝트에서는 해당 Hook이 검출하지 못하거나(빈 폴더는 아니지만 빈 폴더와 빈 폴더의 .meta만을 포함하는 “재귀적으로 사실상 빈 폴더" 등) 오검출하는(이름이 ~ 로 끝나는 디렉토리 및 하위 항목은 Unity에서 무시하며 쌍을 이루는 .meta 파일도 생성하지 않아 검사해서는 안되는 등) 상황을 정확하게 처리하고 검사 속도 최적화와 좀 더 쉬운 문제 해결을 위해 빠르고 안전하며 현대적인 프로그래밍 언어인 Rust로 Hook을 만들어 사용하고 있습니다. 이에 관해서는 다른 기회에 소개하겠습니다.

이외에도 컴파일러나 린터를 실행해 코드의 문제를 검사하거나 에셋 간의 잘못된 의존관계(프로덕션에 나갈 에셋이 테스트용 에셋에 의존하는 등)를 검사, 혹은 이러한 pre-commit 단계에서의 검사 외에도 post-checkout이나 post-merge 단계에서 정리 작업 또는 디펜던시 관련 처리를 하는 등 다양한 문제를 예방하거나 편의성 개선을 위해 Hook을 활용할 수 있습니다.

#설치 및 버전 관리

기본적으로 Hook 파일은 해당 로컬 저장소에서만 유효하며 공유 및 버전관리가 불가능합니다. 이는 Hook 파일의 디폴트 경로인 .git/hooks 디렉토리의 상위 디렉토리인 .git 디렉토리를 Git이 추적하지 않기 때문입니다. 이로 인해 Hook을 작성하더라도 팀 내에서 모두가 설치해서 사용하도록 공유하며 변경이 있을 때마다 이를 업데이트하는 것이 다소 번거로운 경우가 많습니다. 이러한 설치 및 버전 관리에 관한 고민 및 나름대로의 해법을 소개하겠습니다.

팀 동료들과 Hook을 공유하기 위해서는 먼저 Hook 디렉토리를 Git이 추적하는 경로로 옮길 필요가 있습니다. 이를 위해 프로젝트 저장소 안에 다음과 같이 .githooks 디렉토리를 새로 생성합니다.

repository-root
│
├── .git/
│   ├── config
│   │   ...
│
├── .githooks/
│   ├── pre-commit
│   ├── post-checkout
│				...
│
├── .gitconfig

.githooks 디렉토리 아래에는 각 Hook 파일을 작성합니다. 주의할 점은, Git LFS와 같이 팀 내에서 공통적으로 설치해서 사용하는 필수적인 Hook이 있다면 해당 Hook을 실행하는 코드도 같이 가져와야 그 Hook을 다시 설치하는 번거로운 일이 일어나지 않습니다. 예를 들어 Git LFS를 저장소에 설치 시 post-checkout Hook에는 다음과 같은 두 라인이 추가됩니다.

# .git/hooks/post-checkout
...
command -v git-lfs >/dev/null 2>&1 || { echo >&2 "...생략..."; exit 2; }
git lfs post-checkout "$@"

새로 작성한 Hook의 경로는 Git에 의해 추적되기 때문에 공유와 버전관리가 가능합니다. 다음 명령을 실행해 각 파일을 실행 권한과 함께 저장소에 추가한 후 커밋합니다.

git add --chmod=+x .githooks/*

그러나 이 상태로는 새로 작성한 Hook이 실행되지 않습니다. 여전히 Git은 .git/hooks 디렉토리에서 Hook 파일을 찾으려 하기 때문입니다. 다음과 같이 저장소 루트 디렉토리에 .gitconfig 파일을 생성해 Hook 경로 설정을 동료 간에 공유할 수 있도록 합니다.

# .gitconfig
[core]
	hooksPath = .githooks

.gitconfig 파일에는 이외에도 다양한 옵션을 추가해 동료 간에 일관적인 설정을 유지할 수 있습니다. 예를 들어 MacOS에서는 core.ignoreCase 가 기본적으로 false로 설정돼 있기 때문에 파일명의 대소문자를 바꾸더라도 변경 내역을 추적하지 못하는 경우가 많습니다. 이를 true로 설정하면 이러한 문제를 피할 수 있습니다.

하지만 여전히 새로 작성한 Hook은 실행되지 않습니다. Git의 로컬 설정은 기본적으로 .git/config 파일에 저장되며 임의로 작성한 .gitconfig 파일은 Git에게 특별할 것이 없는 그냥 평범한 파일일 뿐입니다. 이 파일에서 설정을 읽게 하기 위해서는 다음과 같은 명령을 통해 로컬 설정에 .gitconfig 파일을 등록해야 합니다.

git config --local include.path ../.gitconfig

이제 Hook은 정상적으로 실행됩니다. 그러나 문제는 아직도 끝나지 않았습니다. 각 동료의 로컬 저장소에서 위 명령을 실행해야 하기 때문입니다. 위 명령을 실행하도록 안내하는 것도 방법이지만 이는 생각보다 쉽지 않습니다. 동료의 숫자가 많지 않으면 개별 안내 및 점검이 가능하겠지만 동료의 숫자가 늘어날수록, 재택근무를 하는 인원이 많을수록 안내 및 점검에 필요한 비용이 증가합니다. 또한 동료가 컴퓨터를 교체하거나 저장소를 새로 클론받으면 매번 같은 명령을 실행해야 하며 문서화를 통해 안내하더라도 이는 누락되기 쉽습니다.

문제를 해결하려면 가끔 정석적이지 않은 방법이 필요한 때도 있습니다.

이 문제를 해결하기 위해 약간의 편법을 사용합니다. UnityEditor 네임스페이스에는 InitializeOnLoadMethod Attribute가 있는데, 이 Attribute를 가진 메서드는 Unity 에디터가 해당 메서드를 어셈블리에서 불러올 때마다 호출됩니다. 따라서 그러한 메서드가 .gitconfig 파일을 Git 설정에 등록하는 명령을 실행하도록 하면 Unity로 프로젝트를 1회 이상 실행한 동료의 저장소에서 Hook 및 기타 설정이 모두 적용되도록 할 수 있습니다. Unity 프로젝트의 Assets/Editor 디렉토리 하위 경로에 다음과 같은 파일을 작성합니다.

using System.Diagnostics;

public class InstallGitHooks {
    [UnityEditor.InitializeOnLoadMethod]
    private static void Install() {
        Process.Start("git", "config --local include.path ../.gitconfig");
    }
}

위 스크립트의 실행에 걸리는 소요 시간은 Unity 에디터가 로드되는 시간에 비해 지극히 짧으며 여러 번 실행되더라도 문제가 없는, 일종의 멱등적(Idempotent) 명령이기 때문에 어떠한 불편도 체감되지 않습니다. 이제 모든 문제가 해결되었습니다.

#Hook에 관해 주의할 점

Hook을 사용하며 느낀 주관적인 주의점을 몇 가지 적어 보았습니다.

#잘못된 Hook으로 작업이 중단되지 않도록 유의

워터파크의 안전 요원이 잘못된 안전 수칙을 적용해 별 문제가 없는 상황에서도 조치를 가한다면 오히려 물놀이 경험이 훼손됩니다. 특히 pre-commit Hook이 제대로 작동하지 않아 오류가 발생할 경우 모든 팀원의 커밋이 멈추게 되며 이는 Hook을 도입한 취지와 정면으로 위배되는 최악의 상황입니다. 충분한 테스트 코드 및 수동 검증을 통해 Hook이 팀 내에서 사용하는 모든 환경에서 제대로 작동하는 것을 확인한 후 메인 브랜치에 적용해야 합니다.

드물게 휴리스틱을 사용해야 하는 경우, 오류 검출에 있어서는 거짓 음성보다는 거짓 양성을 줄이는 것이 바람직합니다. Hook이 거짓 음성을 잡지 못하더라도 여전히 CI와 소프트웨어 엔지니어의 관찰력이라는 종전의 수단으로 문제를 해결할 수 있습니다.

또한 Hook에서 버그 발생 시 대응할 수 있는 소프트웨어 엔지니어가 자리를 비운 상황이나 예외적으로 Hook을 우회해야 하는 상황에서 빠른 대처가 가능하도록 Hook을 건너뛸 수 있는 수단을 안내해야 합니다. Git의 --no-verify 옵션이나 GUI Git 클라이언트의 Hook을 건너뛰는 메뉴 등의 사용법, 혹은 관련 문서 링크를 에러 메시지와 함께 안내하면 해결법을 애타게 찾는 상황을 피할 수 있습니다.

#사용자의 환경에 주는 영향 최소화

위에서 Unity의 InitializeOnLoadMethod Attribute를 통해 아무도 몰래 Hook을 로컬 저장소에 설치하는 편법을 소개했습니다. 이러한 방법을 따른다면 해당 저장소를 사용하는 사람들은 Git 작업 시마다 Hook이 작동하는 것을 알기 어려울 것입니다. 모르는 상태에서 의도하지 않은 변경이 일어나지 않도록 Hook의 기능 및 취지에 대해 미리 공유하고 Hook이 작동할 때 로컬 저장소 밖의 파일 시스템, Git 전역 설정 등을 건드리지 않도록 영향 범위를 로컬 저장소 안쪽으로 한정해야 합니다.

#실수를 제재하는 것이 아니라 보완하는 방향으로

안전 요원은 범죄자를 잡는 형사가 아니라 안타까운 사고로 즐거운 경험이 훼손되지 않도록 돕는 사람입니다. 문제가 있는 커밋을 무작정 가로막기보다는 상세하고 이해하기 쉬운 오류 시각화를 통해 빠르게 문제를 해결하고 작업을 이어갈 수 있도록 하는 것이 바람직합니다.

#성능도 중요

특히 프로젝트 내 파일 시스템을 순회해야 하는 작업은 프로젝트 전체 파일 및 디렉토리 개수가 늘어날수록 더 많은 시간이 소요됩니다. Git에서 발생하는 이벤트마다 긴 시간이 걸리면 이는 팀의 생산성 저하로 이어집니다. Hook 작동에 걸리는 시간이 유의미하게 늘어나기 시작하면 최적화를 고민해야 합니다.

#복잡한 Hook은 다른 프로그래밍 언어로 작성

셸 스크립트는 Unix 계통의 다양한 CLI 도구를 활용해 간단하고 효율적인 코드를 작성하기에는 용이합니다. 그러나 코드 라인 수가 늘어날수록 코드 흐름을 파악하기 어려우며 다양한 기능을 구현하기에도 적합하지 않으므로 복잡한 Hook을 작성할 경우 상황에 맞는 프로그래밍 언어를 사용하는 것이 좋습니다.

Python, C#, Java 등 다양한 언어를 사용할 수 있겠지만 제 주관적인 선호는 빠르고 안전하며 현대적인 시스템 프로그래밍 언어인 Rust이며 이유는 다음과 같습니다.

실행에 별도의 런타임을 필요로 하는 언어는 해당 런타임을 같이 설치해야 하기 때문에 개발 환경을 갖추는 과정이 복잡해집니다. 물론 런타임을 같이 번들링하는 방법도 있으나 용량이 커지고 번잡합니다. Shell처럼 거의 모든 환경에서 실행 가능한 경우가 아니라면(Windows의 경우에도 보편적인 Git 클라이언트가 mingw 위의 Git Bash를 기반으로 하므로 Hook 내에서 대부분의 기본적인 Shell 명령을 수행할 수 있습니다.) 바이너리 실행 파일을 컴파일할 수 있는 언어가 편리합니다.
C나 C++ 등 전통적인 시스템 프로그래밍 언어가 갖추지 못한 현대적인 패키지 매니저와 손쉬운 빌드 및 크로스 컴파일을 제공합니다.
강력한 타입 시스템 및 값에 기반한 에러 핸들링 등을 통해 런타임에 발생할 수 있는 버그를 상당 부분 컴파일 타임에 예방하기에 좋은 언어입니다.
기본적으로 성능이 좋고 동시성 프로그래밍에 용이해 최적화에 좋습니다.
코어 모듈 및 상당수의 라이브러리가 포터블하기 때문에 OS별로 큰 추가 작업 없이 쉽게 크로스 컴파일이 가능합니다. Go도 이를 제외한 위의 장점을 다수 공유하지만 Windows 환경에서 다소 까다로운 점들이 있습니다.

#Rust를 활용한 바이너리 Hook 구현 예시

마지막으로 원격 저장소로부터 풀을 받았을 때 로컬에 설치된 Unity 버전이 풀을 받은 프로젝트 버전보다 낮으면 Unity Hub에서 다운로드 팝업을 띄우는 간단한 Hook을 Rust로 작성해 보겠습니다.

프로젝트에서 사용하는 Unity 버전을 업데이트할 때마다 동료들에게 현재 컴퓨터에 새 Unity 버전 설치 안내를 해야 할 필요가 있습니다. 문제는 다른 바쁜 업무나 휴가 등으로 버전 업데이트 소식을 보지 못한 동료는 버전이 업데이트됐다는 것을 놓치기 쉬우며 나중에 업데이트 안내문을 찾으려면 메일함이나 메신저를 뒤져야 해 번거롭습니다.

이 Hook의 목적은 Unity 버전업이 있을 때마다 자동으로 다운로드 팝업을 띄워 이러한 불편을 해소하고자 하는 것이며 복잡한 Hook은 아니지만 프로젝트에 바이너리 Hook을 적용하는 예제로 적합하다는 생각에 간단히 작성해 보았습니다.

//! src/main.rs

use anyhow::Context;
use regex::Regex;
use std::fs;
use std::path::{Path, PathBuf};

#[derive(PartialOrd, PartialEq)]
struct UnityVersion {
    major: u32,
    minor: u32,
    patch: u32,
    final_ver: Option<u32>,
    full: String,
    revision: String,
}

fn extract_version<P: AsRef<Path>>(path: P) -> anyhow::Result<UnityVersion> {
    let text = fs::read_to_string(path.as_ref())?;
    let re = Regex::new(
        r"m_EditorVersion(WithRevision)*:[ ]*((\d+)\.(\d+)\.(\d+)(f(\d+))?)[ ]*\(([0-9a-f]+)\)",
    )
    .unwrap();
    let caps = re.captures(&text).context("Version not exists")?;
    Ok(UnityVersion {
        major: caps[3].parse().unwrap(),
        minor: caps[4].parse().unwrap(),
        patch: caps[5].parse().unwrap(),
        final_ver: caps.get(7).map(|m| m.as_str().parse().unwrap()),
        full: caps[2].to_string(),
        revision: caps[8].to_string(),
    })
}

fn main() -> anyhow::Result<()> {
    let unity_root = PathBuf::from(std::env::var("UNITY_ROOT")?);
    let remote_ver =
        extract_version(unity_root.join(Path::new("ProjectSettings/ProjectVersion.txt")))?;
    let last_local_ver =
        extract_version(unity_root.join(Path::new("Library/PackageManager/ProjectCache")))?;
    if remote_ver > last_local_ver {
        open::that(format!(
            "unityhub://{}/{}",
            remote_ver.full, remote_ver.revision
        ))?;
    }
    Ok(())
}

위 Hook은 환경 변수 UNITY_ROOT를 Unity 프로젝트의 루트 디렉토리로 읽어 해당 디렉토리에서 프로젝트의 Unity 버전이 기록된 파일(ProjectSettings/ProjectVersion.txt)과 로컬에서 마지막으로 해당 프로젝트를 실행한 버전이 기록된 캐시 파일(Library/PackageManager/ProjectCache)을 파싱해 두 버전명을 기록하고 로컬 버전이 더 낮으면 Unity 허브의 커스텀 URL 스킴을 실행해 Unity 허브에서 해당 버전의 설치 페이지를 엽니다.

.unwrap()을 여러 번 호출하고 있으나 정규식으로 캡쳐된 결과이므로 panic이 일어날 여지는 없습니다. OS에 종속적인 기능을 사용하지 않았으며 파일 경로가 Unix 스타일이긴 하지만 Rust의 Path는 포터블하기 때문에 위 코드는 별다른 추가 작업 없이 크로스 컴파일이 가능합니다.

예시 코드는 Rust 1.62.0에서 컴파일했으며 의존하는 Crate 목록은 다음과 같습니다.

# cargo.toml
...
[dependencies]
regex = "1"
open = "3.0"
anyhow = "1"

이 Hook은 단순해서 굳이 필요하진 않지만 복잡하거나 성능이 중요한 Hook의 경우 lto = true로 링크 타임 최적화를 통해 추가적인 성능 향상을 노릴 수 있습니다.

컴파일 결과로 나온 바이너리 파일을 프로젝트 저장소에 등록 후 다음과 같이 post-merge Hook에서 OS에 맞는 바이너리를 실행하도록 설정합니다. 의도한 대로 원격 저장소에서 Unity 버전을 올릴 경우 풀을 받으면 Unity 허브에서 새 Unity 버전을 다운로드하는 페이지가 열리는 것을 확인할 수 있습니다. (post-pull에 해당하는 Hook은 존재하지 않으나 git pull 명령 실행 시 post-merge Hook이 발동됩니다.)

#!/bin/bash

run_binary_hook()
{
    case "$OSTYPE" in
        linux-gnu*)
            <Linux 바이너리 Hook 경로> ;;
	    darwin*)
            <MacOS 바이너리 Hook 경로> ;;
        # 일반적으로 Windows에서는 Git Bash를 통해 접근하므로 msys 외의 경우는 없을 것입니다.
        win*|msys*|cygwin*)
            <Windows 바이너리 Hook 경로> ;;
        *)
        echo "${OSTYPE}: 지원하지 않는 실행환경입니다." ;;
	esac
}

export UNITY_ROOT=<Unity 프로젝트 루트 디렉토리 경로>
# pre-commit처럼 특정 조건을 검사하는 Hook이 아니기 때문에 에러가 발생하더라도 무시합니다.
run_binary_hook || true

#맺음말

이상으로 Unity와 Git을 사용하는 쿠키런 킹덤 프로젝트에서 Git Hooks를 활용해 온 몇 가지 사례와 고민을 소개했습니다. 다소 장황하게 적다 보니 길어서 스크롤을 내리셨을 분들을 위해 본문을 세 줄로 요약하겠습니다.

게임 클라이언트 프로젝트에서 자주 발생하는 골칫거리 중에서는 Git Hooks를 활용해 완화할 수 있는 것들이 있습니다.
여러 인원이 참여하는 프로젝트에서 Git Hooks를 동기화하기 위해 Unity Editor의 InitializeOnLoadMethod Attribute를 활용하는 편법이 있습니다.
Rust는 훌륭한 언어입니다.

읽어주셔서 감사합니다. 다음에도 쿠키런 킹덤에서 여러가지 문제를 해결한 경험을 소개하는 글로 찾아뵙겠습니다.

데브시스터즈에서는 다양한 문제들을 적절한 기술로 탁월하게 같이 해결할 분들을 모집하고 있습니다.

폼 데이터를 우아하게 관리하는 방법

Tue, 26 Jul 2022 00:00:00 GMT

안녕하세요. 저는 데브시스터즈 플랫폼셀에서 백엔드 엔지니어로 일하고 있는 이창희입니다. 저는 그동안 쌓은 대부분의 경력이 백엔드와 프론트엔드 개발을 같이하는, 흔히 말하는 풀 스택 엔지니어였는데요 오늘은 그 중 프론트엔드 개발 경험을 살려 흥미로운 이야기를 해볼까 합니다.

프론트엔드 개발을 하다 보면 폼을 통해 사용자에게 값을 입력받고, 검증하고 서버로 전송해야 하는 경우가 있습니다. 얼마 전에 새로 단장한 데브시스터즈 채용 홈페이지의 채용 지원 폼도 그러한데요. 이 글에서는 채용 홈페이지를 새로 만들며 입력이 많고 복잡한 폼을 함수형 라이브러리인 fp-ts를 사용하여 폼 데이터 상태 관리를 우아하게 처리한 경험에 대해 소개합니다.

#기본적인 폼 상태 관리

데브시스터즈 채용 홈페이지는 React를 사용하여 개발했습니다. React에서 기본적인 상태 관리는 React.useState 를 사용하는데요. 예를 들어 React.useState 를 사용해 채용 지원 폼에 있는 휴대폰 번호가 올바른 휴대폰 번호인지(적어도 아주 이상한 번호는 아닌지) 검증을 한다면 아래와 같이 명령형 코드로 작성할 수 있을 것입니다.

const [mobileNumber, setMobileNumber] = React.useState<string>('');
const [mobileNumberError, setMobileNumberError] = React.useState<string>('');

// 올바른 형식의 휴대폰 번호인지 검증하는 함수
const validateMobileNumber = (value: string): boolean => {
  if (value == '') {
    setMobileNumberError('휴대폰 번호를 입력해주세요.');
	  return false;
  }

	if (!mobileNumberRegex.test(value)
      || !value.startsWith('01')
      || value.length < 10
      || value.length > 11
  ) {
	  setMobileNumberError('휴대폰 번호가 올바르지 않습니다.');
	  return false;
	}

	return true;
}

// 휴대폰 번호 input의 onChange 이벤트 핸들러
const handleMobileNumberChange = (e) => {
	const { value } = e.target;
	validateMobileNumber(value);
	setMobileNumber(value);
}

// form onsubmit 이벤트 핸들러
const onSubmit = () => {
	const validations = [validateMobileNumber(mobileNumber), ...];
	if (validations.some((valid) => !valid)) {
		return;
	}

  // Submit Form ...
  //
}

return (
	...
	<input onChange={handleMobileNumberChange} value={mobileNumber} />
	<span className="error">{mobileNumberError}</span>
	...
)

위의 코드만 보면 딱히 문제는 없습니다. 하지만, 검증해야 할 값들이 더 늘어난다면 어떻게 될까요? 원래는 한 입력에 대해 값과 오류 상태를 관리하기 위해 2개의 React.useState가 필요했으니 만약 3개의 입력을 관리해야 한다면 아래와 같이 관리해야 할 상태와 작성해야 할 함수들이 비례해서 늘어나게 됩니다.

하지만 3개가 아닌 4개, 5개 혹은 그보다 더 늘어난다면 어떨까요? 하나의 폼을 검증하기 위해 작성해야 하는 코드가 너무 많아질 것 같습니다. 게다가 ‘값이 필수적으로 입력되어 있어야 한다’ 같은 규칙들은 여러 필드가 공통으로 사용할 텐데, 이를 각 필드에서 매번 확인한다면 코드 중복도 높아질 것입니다. 그렇다면 이 문제는 어떻게 해결해야 할까요?

const [mobileNumber, setMobileNumber] = React.useState<string>('');
const [mobileNumberError, setMobileNumberError] = React.useState<string>('');
const [name, setName] = React.useState<string>('');
const [nameError, setNameError] = React.useState<string>('');
const [email, setEmail] = React.useState<string>('');
const [emailError, setEmailError] = React.useState<string>('');

// 검증 함수들
const validateMobileNumber = (value: string): boolean => { /* ... */ }
const validateName = (value: string): boolean => { /* ... */ }
const validateEmail = (value: string): boolean => { /* ... */ }

// input들의 onChange 이벤트 핸들러
const handleMobileNumberChange = (e) => { /* ... */ }
const handleNameChange = (e) => { /* ... */ }
const handleEmailChange = (e) => { /* ... */ }

// form onsubmit 이벤트 핸들러
const onSubmit = () => {
	const validations = [
		validateMobileNumber(mobileNumber),
		validateName(name),
		validateEmail(email),
	];
	if (validations.some((valid) => !valid)) {
		return;
	}

	// Submit Form ...
}

return (
	...
	<input onChange={handleMobileNumberChange} value={mobileNumber} />
	<span className="error">{mobileNumberError}</span>

	<input onChange={handleNameChange} value={name} />
	<span className="error">{nameError}</span>

	<input onChange={handleEmailChange} value={email} />
	<span className="error">{emailError}</span>
	...
)

#조금 더 간결하게

이런 문제를 만난다면 보통은 react-hook-form 같은 라이브러리를 사용하여 해결합니다. 하지만 저희는 조금 다르게 이 문제를 해결해보고 싶었고, 프로젝트에서 이미 사용 중이던 fp-ts를 사용하여 함수형 프로그래밍으로 이 문제를 해결해보기로 하였습니다.

문제를 간결하게 정의하기 위해서는 공통 부분 문제와 그렇지 않은 문제를 파악해야합니다. 앞에서 예로 들었던 이름, 휴대폰 번호, 이메일에 대해 입력 상태 흐름을 일반화하면 아래와 같이 표현할 수 있습니다.

입력값과 오류 메시지를 관리하는 두 개의 상태가 있습니다.
사용자가 값을 입력하면 상태를 갱신합니다.
검증 함수를 통해 사용자가 입력한 값이 올바른지 검증합니다.
검증에 오류가 있다면 오류 메시지 상태를 갱신합니다.

여기서 입력값과 검증 함수가 공통적이지 않고 나머지는 공통적입니다. 즉, 입력값과 검증 함수만 외부에서 주입받으면, 나머지 부분은 공통 함수에서 처리할 수 있습니다.

#함수형 검증 함수

검증 함수를 작성하기에 앞서 공통 함수를 구현합니다. 아래 validate<T> 함수는 검증 함수 배열과 오류 메시지를 인자로 입력받고, 검증 함수 배열에 있는 모든 함수에 입력값을 주고 실행하고, 하나라도 검증에 실패하면 오류 메시지를, 모두 성공했다면 다시 입력값을 되돌려주는 함수입니다. 이제 우리는 하나의 오류에 대해 여러 개의 검증 규칙을 묶어 사용할 수 있게 되었습니다.

fp-ts에 익숙하지 않으신 분들을 위해 fp-ts의 함수와 타입에 대해 간단한 설명을 적어놓았습니다.

pipe

pipe 함수는 이름 그대로 함수들을 파이프처럼 쭉 이어주는 역할을 합니다. 예를 들어 pipe(foo, bar)(value)는 bar(foo(value))와 같습니다.

예를 들어 아래 pipe 함수를 호출하는 코드는

pipe(addOne, multiplyByTen)(10);

이런 흐름으로 실행됩니다.

Either<E, A>

Either<E, A> 타입은 분리 합집합 혹은 서로소 합집합을 나타내는 타입으로 Left<E> 혹은 Right<A> 타입 중 하나만을 가집니다. T | None 을 표현하는 Option<T>와 달리 Either<E, A>는 Left<E>와 Right<A> 모두 null이 아닌 값을 가질 수 있어, falsy한 경우에도 값을 표현해야 하는 경우에 사용됩니다.

일반적으로 Falsy한 경우를 Left로, Truly한 경우를 Right로 표현합니다.

Predicate<T>

Predicate<T> 는 (a: T) => boolean 을 뜻합니다. 즉, 어떤 값에 대해서 참이냐 거짓이냐를 판별하는 제네릭 함수 타입입니다.

Either.fromPredicate

Either.fromPredicate 는 ((predicate, onFalse) => ((a: A) => Either) 시그니처를 갖는 함수로 predicate 의 실행 결과에 따라 Left 혹은 Right 타입을 변환시켜줍니다.

만약 predicate의 실행 결과가 false라면 onFalse의 실행 결과를 Left 객체에 담아 반환하고, true라면 Right 객체에 value를 담아 반환해 줍니다.

import { fromPredicate } from 'fp-ts/Either';
import { pipe, type Predicate } from 'fp-ts/function';
import { every, map } from 'fp-ts/Array';

const validate =
  <T,>(validators: Array<Predicate<T>>, errorMessage: string) =>
  (value: T) =>
    pipe(
      value,
      fromPredicate(
        (val) =>
          pipe(
            validators,
            map((fn) => fn(val)),
            every(Boolean)
          ),
        () => errorMessage
      )
    );

#검증기 만들기

이제 검증에 사용할 공통 함수를 만들었으니, 각 입력 필드에서 사용할 검증기를 만들어봅시다. 하지만 모두 적기에는 지루해질 것 같으니 간단하게 휴대폰 번호 필드에 대한 검증기를 만들어 보면서 앞에서 정의했던 validate 함수를 어떻게 사용하고 어떻게 오류 메시지를 처리하는지 알아봅시다.

먼저 검증 규칙 함수들을 선언합니다. 어떤 규칙들은 한 필드에서만 사용되지만, 많은 규칙들을 여러 필드에서 사용하기에 작은 단위로 선언하면 재사용성이 높아집니다. 이렇게 검증 규칙 함수들을 공통적으로 사용할 수 있게 정의해놓으면, 다른 값에 대한 검증기를 만들 때 편리합니다.

const startsWith =
  (search: string): Predicate<string> =>
  (text: string) =>
    text.startsWith(search);

const minLength =
  (limit: number): Predicate<string> =>
  (text: string) =>
    text.length >= limit;

const maxLength =
  (limit: number): Predicate<string> =>
  (text: string) =>
    text.length <= limit;

const testPhoneNumberPattern = (text: string) => !/[^0-9\\s\\-]/gi.test(text);

그리고 원하는 규칙에 맞게 휴대폰 검증 함수를 정의합니다. 여기서 구현하려는 검증 규칙은 아래와 같습니다.

휴대폰 번호가 한 글자라도 입력이 되지 않았으면 필수 항목이라는 오류 메시지를 반환합니다.
아래 함수들을 실행해 모두 조건을 만족하는지 확인합니다.
- 숫자 외에 다른 문자가 있는지 확인합니다.
- 휴대폰 번호가 '01'로 시작하는지 확인합니다.
- 번호 길이가 10자 이상인지 확인합니다.
- 번호 길이가 11자 이하인지 확인합니다.
모든 조건을 만족한다면 휴대폰 번호를 Right<string> 타입으로 반환합니다.
하나라도 만족하지 못한다면 올바르지 않은 번호 형식이라는 오류 메시지를 Left<string> 타입으로 반환합니다.

Either.chain

Either와 함께 Either를 입력받는 콜백 함수를 입력받습니다. 입력받은 Either가 Left냐 Right냐에 따라 함수를 실행할지 말지 결정하는 함수입니다. 만약 입력받은 Either가 Left라면 그대로 Left를 반환하고 Right라면 Right에 담긴 값을 실행할 함수의 인자로 넘깁니다.

아래의 예시를 보시면 이해에 도움이 되실 것 같습니다.

import { chain, left, right, type Either } from 'fp-ts/lib/Either';

// left 함수는 입력받은 값을 가지는 Left 타입의 객체를 생성합니다.
// right 함수는 입력받은 값을 가지는 Right 타입의 객체를 생성합니다.

const multiplyByTen = (n: number): Either<string, number> => right(n * 10);
const func = (e: Either<string, number>) => {
  return chain(multiplyByTen)(e);
};

console.log(func(left('CookieRun!'))); // 결과: {_tag: 'Left', left: 'CookieRun!'}
console.log(func(right(10))); // 결과: {_tag: 'Right':, right: 100}

export const validatePhoneNumber = (
  phoneNumber: string
): Either<string, string> =>
  pipe(
    validate([minLength(1)], '필수항목입니다.')(phoneNumber), // 아무것도 입력되지 않았는지 검사합니다.
    chain(
      validate(
        [
          testPhoneNumberPattern, // 숫자 외에 다른 문자가 있는지 확인합니다.
          startsWith('01'), // 휴대폰 번호는 01로 시작해야합니다.
          minLength(10), // 휴대폰 번호의 길이는 최소 10자여야합니다.
          maxLength(11), // 휴대폰 번호의 길이는 최대 11자여야합니다.
        ],
        '올바르지 않은 번호형식입니다.'
      )
    )
  );

#커스텀 훅 만들기

공통 validate 함수와 휴대폰 번호를 검증할 때 쓸 검증 함수까지 작성했으니, 값과 오류에 관한 상태를 아래와 같이 처리하던 것을 커스텀 훅을 만들어 간결하게 만들어봅시다.

const [mobileNumber, setMobileNumber] = React.useState<string>('');
const [mobileNumberError, setMobileNumberError] = React.useState<string>('');

먼저, 실제로 폼을 렌더링할 때 필요한 것을 생각해보면 아래와 같습니다.

React.useState처럼 입력값의 상태를 관리할 수 있어야 합니다.
값을 검증하고 오류 메시지를 가져올 수 있어야 합니다.
검증 함수를 직접 호출할 수 있어야 합니다.

여기서 검증 함수를 직접 호출할 수 있어야 하는 이유는 사용자가 폼에 어떠한 입력을 하지 않고 바로 폼을 제출하는 경우가 있기 때문에 폼을 제출하기 전 검증을 해야 하기 때문입니다.

이러한 조건을 바탕으로 커스텀 훅을 만들면 아래와 같은 모양이 됩니다. 입력값과 오류에 대한 상태를 내부에서 관리하고 있으며, 넘겨받은 검증 함수를 호출하며 결과에 따라 상태를 업데이트합니다.

Either.match

Either 타입에 대해 패턴 매칭을 수행합니다. Either와 콜백 함수 두 개를 인자로 받는데 첫 번째 인자로 들어오는 함수는 Left 타입일 경우에, 두 번째 인자로 들어오는 함수는 Right 타입일 경우에 실행됩니다.

function.identity

(a: A) => A

인자로 입력받은 값을 그대로 다시 반환하는 함수입니다.

string.isEmpty

빈 문자열인지 확인합니다.

string.empty

빈 문자열입니다. ''과 같습니다.

import { match, type Either } from 'fp-ts/Either';
import { identity, pipe } from 'fp-ts/function';
import { isEmpty, empty } from 'fp-ts/string';

type StateValidator = {
  validate: () => boolean;
  error: string;
};

const useStateWithValidator = <T,>(
  initialState: T,
  validator: (v: T) => Either<string, T>
): [T, (v: T, t?: boolean) => void, StateValidator] => {
  const [value, setValue] = useState<T>(initialState);
  const [error, setError] = useState('');

  const changeError = (e: string) => {
    setError(e);
    return e;
  };

  const changeValue = (v: T) => {
    pipe(
      validator(v),
      match(
        (error) => error,
        () => pipe(v, setValue, () => empty)
      ),
      changeError
    );
  };

  const stateValidator: StateValidator = {
    validate(): boolean {
      return pipe(
        validator(value),
        match(identity, () => empty),
        changeError,
        isEmpty
      );
    },

    get error(): string {
      return error;
    },
  };

  return [value, changeValue, stateValidator];
};

이 훅을 기존 코드에 적용하면 아래와 같아집니다. 많은 구현이 숨겨져 이제 컴포넌트에서 폼 상태 관리와 검증을 위해 작성해야 하는 코드가 줄었습니다. 또한 작게 나누어진 검증 규칙들을 조합해 원하는 대로 사용할 수 있고, 여기서 더 확장하면 하나의 필드에서 발생한 오류 한 가지만 보여주는 것에서 모든 오류를 보여줄 수 있습니다. (아무짝에도 쓸모없는 수 많은 사이트의 비밀번호 필드 규칙들을 생각해보세요)

/* --------------- 새로 작성한 코드 --------------- */

const [phoneNumber, setPhoneNumber, phoneNumberValidator] = useStateWithValidator<string>('', validatePhoneNumber);

const onPhoneNumberChange = (e) => setPhoneNumber(e.target.value);

// form onsubmit 이벤트 핸들러
const onSubmit = () => {
    const validators = [phoneNumberValidator, ...];
    const isNotValid = validators
        .map((validator) => validator.validate())
        .some((valid) => !valid);

	if (isNotValid) {
		return;
	}

	// Submit Form ...
}

return (
	...
	<input onChange={onPhoneNumberChange} value={phoneNumber} />
	<span className="error">{phoneNumberValidator.error}</span>
    ...
)

/* --------------- 기존 코드 --------------- */

const [mobileNumber, setMobileNumber] = React.useState<string>('');
const [mobileNumberError, setMobileNumberError] = React.useState<string>('');

// 올바른 형식의 휴대폰 번호인지 검증하는 함수
const validateMobileNumber = (value: string): boolean => {
	if (!mobileNumberRegex.test(value)) {
	  setMobileNumberError('휴대폰 번호가 올바르지 않습니다.');
	  return false;
	}

	if (!value.startsWith('01')) {
	  setMobileNumberError('휴대폰 번호가 올바르지 않습니다.');
	  return false;
	}

	if (value.length < 10 || value.length > 11) {
	  setMobileNumberError('휴대폰 번호가 올바르지 않습니다.');
	  return false;
	}
	return true;
}

// 휴대폰 번호 input의 onChange 이벤트 핸들러
const handleMobileNumberChange = (e) => {
	const { value } = e.target;
	validateMobileNumber(value);
	setMobileNumber(value);
}

// form onsubmit 이벤트 핸들러
const onSubmit = () => {
	const validations = [validateMobileNumber(mobileNumber), ...];
	if (validations.some((valid) => !valid)) {
		return;
	}

	// Submit Form ...
}

return (
	...
	<input onChange={handleMobileNumberChange} value={mobileNumber} />
	<span className="error">{mobileNumberError}</span>
	...
)

#정리

따라오느라 고생하셨습니다. 이 글에서 어떤 것들을 했는지 다시 한번 돌아봅시다.

fp-ts를 사용해 공통으로 사용할 검증 유틸 함수를 만들었습니다.
검증에 사용할 검증 규칙들을 재사용성이 높은 작은 함수로 만들었습니다.
검증 유틸 함수와 검증 규칙을 조합하여 입력 필드에 사용할 검증 함수를 만들었습니다.
검증 함수를 쉽게 사용하기 위하여 커스텀 훅을 만들었습니다.

단순히 폼 관련 라이브러리를 사용해도 되지만, 함수형 프로그래밍과 타입으로 같은 문제를 해결하는 과정을 지켜보시면서 어떠셨나요? 프론트엔드 개발을 하다 보면 상태 관리와 전쟁하는 것이 부지기수이지만, 함수형 프로그래밍이라는 무기를 사용하면 그 전쟁을 조금 더 수월하게 이끌어나갈 수 있는 것 같습니다. 이 글을 읽고 흥미가 생기셨다면 여러분의 프로젝트에 함수형 프로그래밍을 적용해보시는 건 어떨까요?

긴 글 읽어주셔서 감사합니다.

데브시스터즈에서는 다양한 문제들을 적절한 기술로 탁월하게 같이 해결할 분들을 모집하고 있습니다.

바삭한 신입들의 동시성 이야기 - Kotlin 편

Tue, 19 Jul 2022 00:00:00 GMT

안녕하세요. 마이쿠키런 Android 파트 개발을 맡고 있는 박세란입니다.

마이쿠키런은 데브시스터즈에서 신규 개발중인 쿠키런 팬들을 위한 플랫폼 서비스입니다. 와글와글한 커뮤니티부터 두근두근 쿠키런 오리지널 웹툰까지 다양한 컨텐츠들을 서빙해야하는 마이쿠키런 앱에 쾌적한 사용자 경험을 위한 비동기 처리는 필수적입니다. 이에 마이쿠키런 Android 팀은 Coroutine을 사용하여 신규 개발을 진행하고 있습니다.

작년 여름 입사한 신입이 Coroutine을 직접 사용하며 차곡차곡 공부한 내용을 공유하고자 합니다. 이번 포스팅에서는 Kotlin Coroutine을 가독성과 성능 측면에서 다른 방법들과 비교해보고, 내부 동작 구조에 대해 알아보겠습니다.

#Summary

Main-Safe하다는 것은 중요한 역할을 맡고 있는 메인스레드를 블락하지 않는다는 것이다.

막힘 없는 앱 환경을 제공하기 위해서는 Main-Safe하게 개발해야하고, 이를 위해 여러 스레드를 활용하여 동시성 코드를 짜야한다.

동시성 프로그래밍을 할 때 콜백보다 Coroutine을 사용하는 것이 가독성이 더 좋다.

CPS는 함수 호출 시에 Continuation을 전달하는 패러다임이며, Kotlin Coroutine 역시 CPS로 구현되었다. Kotlin 컴파일러는 suspend 함수를 CPS 패러다임을 구현한 코드로 변환해준다.

멀티 스레드보다 Coroutine을 활용하는 것이 불필요한 스레드 생성과 blocking을 없애 성능이 더 좋다.

#Intro

본론으로 들어가기 전, 막연한 질문부터 던져보겠습니다. 막힘 없는 앱은 얼마나 빨라야할까요?

#16ms 마다 한 프레임

사람이 빠르게 움직이는 이미지를 동작으로 인식하는 매커니즘 Youtube@Andymation

사람의 눈과 뇌는 스냅샷이나 프레임의 개념이 아닌, 사람의 눈이 보내는 신호를 뇌가 끊임없이 받아들이는 구조입니다. 즉, 연속해서 빠르게 보여지는 이미지를 동작으로 인식하는 구조입니다 (어떻게 보면 착시현상이죠). 따라서 빠르게 보여지는 이미지를 빠짐없이 모두 인식하는 것엔 한계가 있는데요. 보통 사람의 눈은 초당 60프레임인 모션과 그 이상의 모션의 큰 차이를 느끼지 못한다고 합니다.

1000ms/ 60 frames = 16.666 ms/ frame

그래서 사용자가 “와 막힘 없다!”라고 느낄 수 있는 매끄러움을 위해선 초당 60 프레임을 그려야 하는 것이고, 이를 역으로 계산해보면, 16ms마다 한 프레임을 그리는 작업(입력, 처리, 통신, 렌더링)을 완료 해야한다는 것을 의미합니다.

하지만, 앱에 필요한 작업 중에서 16ms 보다 긴 처리 시간을 요구하는 작업을 흔히 찾아볼 수 있습니다. 네트워크 통신, 데이터베이스 작업, JSON 파싱 등등이 그 예 인데요. 이 긴 작업이 메인스레드에서 이뤄진다고 가정하면, 메인스레드의 본래 역할에 영향을 줄 수 있습니다. 메인스레드에서의 긴 작업은 화면 버벅임이나 ANR을 발생시켜 사용자 만족도를 떨어트리는 요인이 되곤 합니다.

그러므로 앱 개발자에겐 사용자가 앱을 쓰는 동안에는 항상 초당 60 프레임 업데이트를 유지해야 한다는 의무가 주어지고, 이를 지키기 위해 안드로이드 개발에 있어 메인스레드를 blocking하지 않는 것은 매우 중요한 일이 됩니다. 이 중요성은 UI 스레드인 메인스레드에서 네트워킹 작업을 실행하면, NetworkOnMainThreadException를 발생시키며 애플리케이션을 중단하는 등 안드로이드 프레임워크가 뒷받침해 주고 있습니다. (안드로이드 3.0 이상 부터)

한편 메인스레드를 blocking하지 않는 것은 왜 중요할까요 ?

#Main-Safety

Unsplash@jannerboy62

메인스레드가 생성되고 시작되는 곳, main 함수를 찾아가 보겠습니다. android.app.ActivityThread 클래스의 main 함수에서 메인스레드가 컴포넌트 생명주기 메서드와 그 안의 메서드 호출, UI 작업을 실행한다는 것을 확인할 수 있습니다.

그 중 UI 작업은 메인스레드에서만 실행될 수 있다는 특징이 있습니다. 이렇게 특정 작업이 하나의 스레드에서만 실행될 수 있게 제한하는 것을 Single-Thread 모델이라고 하는데, 자원 접근에 대한 동기화를 신경 쓰지 않아도 되고, 경쟁 상태(race condition)와 교착 상태(deadlock)도 예방할 수 있다는 이점이 있습니다. 또한 작업 전환(context switching) 비용을 요구하지 않기 때문에 애플리케이션의 응답성을 유지하는 데 도움을 줍니다. 이러한 이점을 얻기 위해, UI 작업은 메인스레드에서만 실행되도록 제한되었으며, UI 스레드라는 용어가 생기게 되었습니다.

16ms 마다 한 프레임의 이야기를 다른 관점에서 이해해보면,UI 작업은 메인스레드에서만 이뤄질 수 있기때문에, 메인스레드가 방해되면 원활한 UI 작업이 어려워지게 된다는 점을 이해할 수 있습니다. UI는 사용자와 맞닿는 부분으로 앱 응답성과 직결되므로 중요도가 높은 작업입니다. 따라서 메인스레드가 항상 이 역할을 수행할 수 있도록 앱을 설계해야합니다.

결국 Main-Safe하다는 것은, 중요한 역할을 맡은 메인스레드가 제 역할을 하도록 blocking 하지 않는 것을 의미합니다.

#Android Concurrency

Main-Safe하게 앱의 여러 작업을 수행하는 방법의 하나로, 동시성을 사용하는 방법이 있습니다. 하지만 동시성 코드를 제대로 작성하는 것은 좀처럼 간단한 일이 아닙니다. 경쟁 상태, 원자성 위반, 교착 상태, 라이브락과 같은 동시성 이슈들이 개발자들을 괴롭히기 때문입니다. 한편 언어 자체가 동시성 코드를 작성하는 것을 어렵게 하기도 합니다. 언어 문법이 너무 장황하거나, 다양한 상황에 대응할 수 있는 유연함이 없다면 말이죠.

Understand Kotlin Coroutines on Android (Google I/O'19)

Google I/O'19 에 따르면, 구글은 매년 개발자 대상으로 그들이 어떻게 지내는지, 그들의 문제는 무엇인지 설문 조사를 한다고 합니다. 2018 Developer Survey 를 통해서 많은 개발자가 Threading, Concurrency에 어려움을 겪고 있다는 것을 파악한 구글은 더 나은 액션을 정의하기 위해 Concurrency UXR (User Experience Research)를 진행했습니다. UXR을 통해 RxJava, LiveData, Coroutine과 같은 기존 솔루션들을 검토하며 알게 된 개발자들의 니즈를 바탕으로, 구글은 2가지 액션을 취하기로 했습니다.

Understand Kotlin Coroutines on Android (Google I/O'19)

First Class Coroutines Support : 제트팩에서 Coroutine에 대한 최고 수준의 품질 지원

RxJava Guidance in Docs : 공식문서에 RxJava에 대한 더 많은 지원

이 중에서 구글으로부터 최고 수준의 품질 지원을 받는 Coroutine에 집중해볼 예정인데요. Kotlin Coroutine은 어떤 특징이 있는지 살펴보면서 왜 Coroutine이 선택되었는지 알아보도록 하겠습니다.

#Kotlin Coroutine

#가독성 이야기 : Callback vs Coroutine

콜백은 백그라운드 스레드를 사용하여 긴 작업을 실행하고, 백그라운드 스레드에서 작업이 완료되면 메인스레드에 정의된 콜백을 호출하여 작업 결과를 알려주는 방법입니다. 긴 작업의 완료 여부를 메인스레드가 busy waiting하고 있지 않기 때문에, 기본적으로 콜백 구조를 사용하면 Main-Safe하게 긴 작업을 처리할 수 있습니다. 한편, 콜백은 Main-Safe한 작업을 하게 해주지만, 반복적인 들여쓰기로 인해 “가독성이 안 좋아질 수 있다”는 단점을 가지고 있습니다. 흔히 콜백 지옥이라고 불리기도 하는데요. 콜백 지옥은 코드를 추론하기 어렵게 만드는 요인 중 하나가 되기도 합니다.

// 순차적인 네트워크 호출을 나타내는 코드

fun getGingerBrave(api: CookieService): gingerBrave {
    api.makeDough{ dough ->
        api.addMagicPowder(dough){ -> magicDough
            api.escapeOven(magicDough) { -> cookie
                api.fetchGingerBrave(cookie) { -> gingerBrave
                    Log.d("You can't catch me! I'm the Gingerbre.. I'm Ginger Brave!")
                    return gingerBrave
                }
            }
        }
    }
}

콜백과 Coroutine은 Main-Safe한 작업을 하게 해준다는 점에서 같은 일을 하지만, Coroutine을 사용한다면 위에서 언급한 콜백의 가독성 문제를 없앨 수 있습니다. Coroutine은 콜백 기반 코드를 sequential code로 바꾸어주기 때문에 비동기 코드를 단순화할 수 있습니다.

suspend fun getGingerBrave(api: CookieService): gingerBrave {
    val dough = api.makeDough()
    val magicDough = api.addMagicPowder(dough)
    val cookie = api.escapeOven(magicDough)
    val gingerBrave = api.fetchGingerBrave(cookie)
    Log.d("You can't catch me! I'm the Gingerbre.. I'm Ginger Brave!")
    return gingerBrave
}

코드를 보면서 Coroutine과 콜백을 가독성 측면에서 비교해보도록 하겠습니다. 동기 코드처럼 표현된 Coroutine에서는 들여쓰기가 사라져 코드 가독성이 좋아졌으며, 중간의 콜백 람다 블록들이 사라져 현재 위치를 더 추론하기 쉬워졌습니다. 코드의 가독성과 추론성은 예측 가능한 프로그램을 만드는 데에 도움을 준다는 점에서 에러 핸들링과 디버깅과 같은 작업에서 큰 이점을 줍니다.

그럼 Coroutine은 어떻게 콜백 없이 동작할 수 있는걸까요? 간단히 요약하자면, 놀랍게도 Kotlin의 suspend 키워드는 내부적으로 콜백을 생성합니다. 즉, suspend 키워드를 만난 Kotlin 컴파일러는 suspend-resume을 위한 최적화된 콜백 코드를 생성합니다. 한번 변환 과정을 살펴볼까요?

#`suspend`의 속사정

Kotlin 컴파일러가 suspend 키워드를 만나면 어떻게 동작하는지 간단하게 모방해보겠습니다. 생소하게 느껴질 수 있는 개념이어서, 임의로 4개의 단계로 나누어 설명합니다.

#Step 1. CPS 패러다임 - Continuation 객체를 사용하다!

Coroutine에는 CPS(Continuation Passing Style) 패러다임이 적용되어 있습니다. CPS란 호출되는 함수에 Continuation을 전달하고, 각 함수의 작업이 완료되는 대로 전달받은 Continuation을 호출하는 패러다임을 의미합니다. 이러한 의미에서 Continuation을 일종의 콜백으로 생각할 수 있습니다.

그럼 이 Continuation이 무엇이고, CPS에서 Continuation을 전달하는 이유는 무엇일까요?

/**
 * Interface representing a continuation after a suspension point that returns a value of type `T`.
 */
@SinceKotlin("1.3")
public interface Continuation<in T> {
    /**
     * The context of the coroutine that corresponds to this continuation.
     */
    public val context: CoroutineContext

    /**
     * Resumes the execution of the corresponding coroutine passing a successful or failed [result] as the
     * return value of the last suspension point.
     */
    public fun resumeWith(result: Result<T>)
}

https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/src/kotlin/coroutines/Continuation.kt

Continuation은 다음에 무슨 일을 해야 할지 담고 있는 확장된 콜백입니다. 명확한 이해를 위해, Kotlin에 정의된 Continuation 인터페이스를 확인해봐야겠죠? Continuation 인터페이스엔 크게 context 객체와 resumeWith라는 함수가 있습니다.

resumeWith는 특정 함수 a가 suspend 되어야 할 때, 현재 함수에서 a의 결과 값을 T로 받게 해주는 함수입니다.
context는 각 Continuation이 특정 스레드 혹은 스레드 풀에서 실행되는 것을 허용해줍니다.

감이 오시나요? CPS에선 Continuation을 전달하면서, 현재 suspend된 부분에서의 resume을 가능하게 해줍니다. Continuation은 resume되었을 때의 동작 관리를 위한 객체로, 연속적인 상태간의 communicator라고 생각할 수 있습니다.

요약하자면 Continuation은 호출 함수간의 suspend-resume을 위한 communicator이고, CPS는 함수 호출 시에 이 Continuation을 전달하는 패러다임입니다. Kotlin Coroutine 역시 CPS로 구현되었습니다.

#Step 2. `suspend` fun의 시그니처가 변경되다!

Continuation은 Kotlin 컴파일러가 suspend 함수의 시그니처를 변경하면서 사용됩니다.

(1) Continuation 객체가 기존 suspend 함수의 파라미터에 추가되고 suspend 키워드가 사라집니다.

(2) 이 객체는 suspend 함수 계산의 결과를 호출한 Coroutine에 전달하는 데 사용됩니다.

(3) 또한 함수의 리턴 타입 또한 gingerBrave에서 Unit으로 변경되었는데요. 결과는 resume 함수의 매개변수를 통해 얻을 수 있게 됩니다.

suspend fun getGingerBrave(api: CookieService): gingerBrave { // (1)
    val dough = api.makeDough()
    val magicDough = api.addMagicPowder(dough)
    val cookie = api.escapeOven(magicDough)
    val gingerBrave = api.fetchGingerBrave(cookie)
    Log.d("You can't catch me! I'm the Gingerbre.. I'm Ginger Brave!")
    return gingerBrave //(2)(3)
}

fun getGingerBrave(api: CookieService, completion: Continuation<Any?>) { // (1)
    val dough = api.makeDough()
    val magicDough = api.addMagicPowder(dough)
    val cookie = api.escapeOven(magicDough)
    val gingerBrave = api.fetchGingerBrave(cookie)
    Log.d("You can't catch me! I'm the Gingerbre.. I'm Ginger Brave!")
    completion.resume(gingerBrave) //(2)(3)
}

#Step 3. State machine - Suspension Points를 기준으로 코드 블록이 구분되다!

자 그래서 대체 어떻게 suspend, resume 연산이 가능한 걸까요?

fun getGingerBrave(api: CookieService, completion: Continuation<Any?>) {
    val dough = api.makeDough() // suspending fun
    val magicDough = api.addMagicPowder(dough) // suspending fun
    val cookie = api.escapeOven(magicDough) // suspending fun
    val gingerBrave = api.fetchGingerBrave(cookie) // suspending fun
    Log.d("You can't catch me! I'm the Gingerbre.. I'm Ginger Brave!")
    completion.resume(gingerBrave)
}

fun getGingerBrave(api: CookieService, completion: Continuation<Any?>) {
    when (label) {
        0 -> // Label 0 -> first execution !
            val dough = api.makeDough() // suspend

        1 -> // Label 1 -> resume from makeDough
            val magicDough = api.addMagicPowder(dough) // suspend

        2 -> // Label 2 -> resume from addMagicPowder
            val cookie = api.escapeOven(magicDough) // suspend

        3 -> // Label 3 -> resume from escapeOven
            val gingerBrave = api.fetchGingerBrave(cookie) // suspend

        4 -> { // Label 4 -> resume from fetchGingerBrave
            Log.d("You can't catch me! I'm the Gingerbre.. I'm Ginger Brave!")
            completion.resume(gingerBrave)
        }
    }
}

Kotlin은 모든 중단 가능 지점을 찾아 when으로 표현합니다. Kotlin 컴파일러는 함수가 내부적으로 중단 가능 지점을 식별하고, 이 지점으로 코드를 분리합니다. 분리된 코드들은 부여된 각각의 label로 인식되며, when을 사용하여 작성됩니다. (label에 대한 설명은 아래에서 계속됩니다.)

이렇게 코드를 명확히 구분해두어, 중단 가능 지점에서 suspend되고 해당 작업이 끝나 resume되면 다시 다음 블록을 실행하게 될 수 있게 합니다. 이런 방식은 상태를 관리하는 하나의 방법으로 상태머신(state machine)이라고 불리기도 합니다.

중단 가능 지점을 표현하는 화살표

한편 중단 가능 지점은 Android Studio, IntelliJ IDE의 화살표 표시로도 확인할 수 있습니다.

요약하면, Kotlin 컴파일러는 suspend 함수 내부를 상태머신으로 표현합니다. suspend 함수를 호출할 때마다 구역을 나누고, labeling하여 when문으로 표현합니다. 한편 현재 실행 차례를 가리키는 label과, suspend 함수 내부에 선언된 변수들을 어떻게 관리될까요?

#Step 4. State machine - label과 각 `suspend` fun 내부 변수들이 관리되다!

fun getGingerBrave(api: CookieService, completion: Continuation<Any?>) {
    class GetGingerBraveStateMachine(completionL Continuation<Any?>): CoroutineImpl(completion) {
        // 기존 함수 내부에 선언된 변수들
        var dough: Dough? = null
        var magicDough: MagicDough? = null
        var cookie: Cookie? = null
        var gingerBrave: GingerBrave? = null

        var result: Any? = null
        var label: Int = 0

        override fun invokeSuspend(result: Any?) {
            this.result = result
            getGingerBrave(api, this)
        }
    }
}

Kotlin 컴파일러는 getGingerBrave 함수안에 GetGingerBraveStateMachine이라는 클래스를 생성합니다. 이 클래스는 Continuation의 자식인 CoroutineImpl을 구현하고 있으며, 원래 suspend 함수에 선언된 변수들과, 실행 결과인 result, 현재의 진행 상태인 label을 가지고 있습니다. 이 클래스가 어떻게 사용되는지 아래 코드에서 확인해보겠습니다.

fun getGingerBrave(api: CookieService, completion: Continuation<Any?>) {
    val continuation = completion as? GetGingerBraveStateMachine ?: GetGingerBraveStateMachine
    (completion)

    when (continuation.label) {
        0 -> {// Label 0 -> first execution !
            throwOnFailure(continuation.result)
            continuation.label = 1
            api.makeDough(continuation) // suspend
        }
        1 -> {// Label 1 -> resume from makeDough
            throwOnFailure(continuation.result)
            continuation.dough = continuation.result as Dough
            continuation.label = 2
            api.addMagicPowder(continuation.dough, continuation) // suspend
        }
        2 -> {// Label 2 -> resume from addMagicPowder
            throwOnFailure(continuation.result)
            continuation.magicDough = continuation.result as MagicDough
            continuation.label = 3
            api.escapeOven(continuation.magicDough, continuation) // suspend
        }
        3 -> { // Label 3 -> resume from escapeOven
            throwOnFailure(continuation.result)
            continuation.cookie = continuation.result as Cookie
            continuation.label = 4
            api.fetchGingerBrave(continuation.cookie, continuation) // suspend
        }
        4 -> { // Label 4 -> resume from fetchGingerBrave
            throwOnFailure(continuation.result)
            continuation.gingerBrave = continuation.result as GingerBrave
            Log.d("You can't catch me! I'm the Gingerbre.. I'm Ginger Brave!")
            completion.resume(continuation.gingerBrave)
        }
        else -> throw IllegalStateException
    }
}

Step 3에서 중단 가능 지점을 기준으로 코드를 나눈 이유가 여기서 더 와닿으실 것 같습니다. 컴파일러가 생성해준 GetGingerBraveStateMachine의 label이 when 절안에서 사용되는데요. suspend 지점에 따라 코드를 나눴고 그것을 label로 구분했으니, 이제 resume 을 위해 label을 사용할 차례입니다. 각 label 분기에선 label의 값을 증분 시켜 다음 실행 지점을 가리키고, 이를 통해 resume이 됩니다.

한편 GetGingerBraveStateMachine을 살펴보면 기존 suspend 함수 내부에 선언된 변수들이 null로 초기화 되어있는 모습을 확인할 수 있는데요. 또한 when 절안에서 resume시 suspend되고 실행된 작업의 결과가 continuation.result로 받아오는 모습도 확인할 수 있습니다. continuation.result를 각 타입으로 캐스팅하여 함수 내부에서 선언된 변수들을 관리하고 있습니다. 이렇게 각 블록을 하나하나 실행할 때마다 함수의 상태가 점점 누적되고 마지막 resume을 통해 최종 결과 값이 전달되게 됩니다. 이렇게 하나의 Coroutine이 끝나게 됩니다.

지금까지 Kotlin 컴파일러가 suspend 키워드를 만났을때 어떻게 동작하는지를 4단계로 알아보았습니다.

Coroutine은 Continuation을 주고 받는 CPS 패러다임을 사용합니다.

Kotlin 컴파일러는 suspend fun의 시그니처를 변경합니다. 매개변수에 Continuation을 추가합니다.

Kotlin 컴파일러는 suspend fun의 내부 코드들을 분석하여 중단 가능 지점을 찾아 구분합니다.

Kotlin 컴파일러는 다음 실행 지점을 나타내는 label과 내부 변수들을 관리하는 상태머신 클래스를 생성합니다.

아니요

여기서의 의의는 Kotlin 컴파일러가 suspend 키워드를 만나면 CPS 패러다임을 구현하여, Continuation이라는 일종의 콜백을 주고 받도록 코드를 변환해준다는 것입니다.

한편, 이렇게 모든 suspend 연산은 Continuation을 보내고 받도록 변환됩니다. 복잡한 변환 작업을 컴파일러가 뒤에서 수행해주고 있던 것이죠. 간단한 suspend 키워드 너머 이렇게 복잡한 변환 과정이 이뤄진다니 놀랍지 않나요? 이렇게 Kotlin 팀은 동시성을 지원하기 위해 가능한 작은 변화를 주도록 노력했고, 단 하나의 suspend 키워드로 Kotlin 개발자들에게 쉽게 동시성을 사용하도록 했다고 하네요. 거..참 쉽..죠 ..?

#성능 이야기 : Thread vs Coroutine

스레드에서 실행되지만, 스레드에 종속적이지 않은 Coroutine을 보여주는 자료

왜 Coroutine은 light-weight thread라고 불릴까요?

기본적으로 애플리케이션에는 하나 이상의 프로세스가 있고, 각각의 프로세스는 적어도 하나의 스레드를 갖고 있습니다. 그렇다면 Coroutine은 어디서 실행될까요? Coroutine은 스레드 안에서 실행됩니다. 같은 스레드에 10개, 100개의 Coroutine이 있을 수 있습니다. 하지만 이것이 한 시점에 여러 Coroutine이 실행된다는 의미는 아닙니다. 동시성 프로그래밍에서 한 시점에는 하나의 Coroutine만 실행됩니다. 한편 main 함수에서 시작되는 메인스레드부터 백그라운드 스레드까지, 앱은 Main-Safe하게 여러 스레드를 활용해야합니다. Coroutine은 메인스레드 뿐만아니라 다른 백그라운드 스레드에서도 동작할 수 있으므로, Coroutine을 활용하여 Main-Safe하게 앱을 만들 수 있게 됩니다.

즉, Coroutine은 스레드 안에서 실행되고 Coroutine을 활용하여 Main-Safe하게 앱을 만들 수 있습니다.

스레드는 프로세스에 종속이 되는데, 그렇다면 Coroutine도 스레드에 종속이 될까요? 여기서 멀티스레드 방식과 Coroutine의 큰 차이점이 나타나는데요, Coroutine은 특정 스레드에 종속되지 않는다는 점이 큰 특징입니다. 즉, Coroutine은 resume될 때마다 다른 스레드에서 실행될 수 있습니다.

작업이 스레드에 종속되지 않는 특징은 스레드를 blocking 하지 않으면서 작업의 실행을 잠시 중단할 수 있게합니다. 즉, 스레드 B가 스레드 A의 작업이 끝날때까지 대기해야하는 작업을 잠시 중단하고, 그동안 다른 작업을 할수 있게 합니다.

이 특징은 스레드를 blocking하지 않아 더 빠른 연산으로 이어지게하고, 메모리 사용량을 줄여 많은 동시성 작업을 수행할 수 있게 합니다. Coroutine 생성 또한 스레드 생성보다 빠르고 적은 비용으로 이뤄질 수 있습니다.

이를 강조하기 위해 Kotlin 공식 문서에선 Coroutine을 light-weight thread라고 부르는 것입니다. 프로세서가 실행할 명령어 집합을 정의한다는 점 및 생명주기가 스레드와 비슷하다는 점에서 “thread", 하지만 스레드 보다 빠르고 적은 메모리를 사용한다는 점에서 “light-weight”으로 표현되었다고 이해할 수 있습니다.

자 그럼 정말 light weight 한지 코드로 확인해볼까요?

import kotlin.system.measureTimeMillis
import kotlinx.coroutines.*

fun main() = runBlocking {
    val amount = 10
    println("✅ Test when the amount is $amount")
    println("🛫 ${Thread.activeCount()} threads active at the start")
    val time = measureTimeMillis { createThreads(amount) }
    println("⏰ Running time for createThreads is $time ms")
}

suspend fun createCoroutines(amount: Int) = coroutineScope {
    val jobs = ArrayList<Job>()

    for (i in 1..amount) {
        jobs += launch(Dispatchers.Default) {
            delay(1000L)
        }
    }
    println("🛬 ${Thread.activeCount()} threads active at the end")
    jobs.forEach { it.join() }
}

fun createThreads(amount: Int) {
    val jobs = ArrayList<Thread>()

    for (i in 1..amount) {
        jobs += Thread {
            Thread.sleep(1000L)
        }.also { it.start() }
    }
    println("🛬 ${Thread.activeCount()} threads active at the end")
    jobs.forEach { it.join() }
}

성능 차이를 측정해보기 위해 스레드와 Coroutine으로 같은 작업을 하는 코드를 작성해보았습니다. create-으로 시작하는 함수는 main 함수에서 실행되어, 1초간 대기하는 작업을 실행하는 스레드 혹은 Coroutine을 amount 개수 만큼 생성하고 실행시킵니다. 아래는 amount가 100, 1000 ,10000 일 때의 실행 결과(시간과 스레드 생성 개수)입니다.

#1️. amount = 100

createCoroutines(100)을 호출했을때

createThreads(100)을 호출했을때

#2. amount = 1000

createCoroutines(1000)을 호출했을때

createThreads(1000)을 호출했을때

#3️. amount = 10000

createCoroutines(10000)을 호출했을때

createThreads(10000)을 호출했을때

아래 두 표는 위 코드의 실행 결과를 요약한 표입니다. amount 값에 따라 생성된 스레드의 개수와 소요된 실행 시간의 변화를 나타내고 있습니다.

amount 값에 따른 createThreads와 createCoroutines의 실행 결과

메모리 측면에서 큰 차이를 보여주고 있습니다. Coroutine을 사용하면 불필요한 blocking을 하지 않아, 스레드 생성을 줄일 수 있기 때문인데요. 이는 createThreads에서 OOM 이 발생하는 원인과 관련이 있습니다. amount가 100일때, createCoroutines와 createThreads 호출을 통한 스레드 생성 횟수는 30배가 넘는 차이가 발생했습니다. Coroutine이 멀티스레드 방식보다 30배 적은 thread 객체를 생성하고 있으므로, 30배 적은 메모리를 사용하고 있다고 말할 수 있을 것 같습니다. 한편 실행 시간 측면에선 큰 차이를 보여주진 않았습니다.

#Outro

마이쿠키런에서 Coroutine을 활용하여 신규개발을 진행하면서 개인적으로 느낀 점, 궁금한 점들이 많았는데요. (ex. Coroutine은 정말 최고야! JetBrains 감사합니다.) 그 중 궁금한 점들을 직접 정의하고 답을 찾아갈 수 있던 좋은 기회였습니다.

저와 같은 물음표를 가진 분들에게 느낌표를 드릴 수 있는 글이 되었으면 좋겠습니다.

한편 Understand Kotlin Coroutines on Android (Google I/O'19)를 보면서 개발자들에게 큰 편의를 주는 이러한 기술적인 지원이 개발자들의 경험인 UXR와 이를 바탕으로 기획한 것들이라는 것을 알게 되었습니다. 개발자들의 의견에 귀기울이며 발전해가는 안드로이드 생태계의 일원이라는 것에 큰 자부심을 느낀 순간이었습니다.

더 좋은 방향으로 나아가기 위해 치열하게 고민하는 개발자분들에게 감사하는 마음으로 이번 포스팅을 마치겠습니다. 읽어주셔서 감사합니다.

#References

9가지 프로그래밍 언어로 배우는 개념: 1편 - 타입 이론

Tue, 12 Jul 2022 00:00:00 GMT

#프로그래밍 언어 시리즈

9가지 프로그래밍 언어로 배우는 개념: 1편 - 타입 이론
9가지 프로그래밍 언어로 배우는 개념: 2편 - 다형성
9가지 프로그래밍 언어로 배우는 개념: 3편 - 메타프로그래밍
9가지 프로그래밍 언어로 배우는 개념: 4편 - 하이 레벨 언어와 동적 타입 언어
9가지 프로그래밍 언어로 배우는 개념: 5편 - 동시성 프로그래밍

#서론

안녕하세요, 저는 게임 "쿠키런: 킹덤"의 서버 파트에서 근무하고 있는 지민규라고 합니다.

시작하기에 앞서 어째서 이 글을 쓰게 되었는지를 말씀드리고 싶은데요, 흔히 언어는 우리의 사고를 형성한다는 말이 있습니다. 언어가 가진 문장 구조과 발성, 그리고 단어들의 형태에 따라 세상에 대한 시각이 바뀐다고 합니다.

저는 다양한 프로그래밍 언어를 배우면서 비슷한 경험을 했습니다. 첫 프로그래밍 언어로 C++를 배웠을 때 C++가 가진 한계점이 제 프로그래밍 방식의 한계점이 되었었고, Go를 배웠을 때 Go가 가진 언어의 구조가 프로그래밍하기에 충분하다고 생각했었습니다. 하지만 이후 더 많은 프로그래밍 언어들을 배우면서 생각이 더 넓어지고 프로그래밍 언어들 사이의 공통점이 보이기 시작했으며, 어떻게 하면 더욱 깨끗한 코드를 구현할 수 있을지 깨달아가게 되었습니다.

다양한 프로그래밍 언어를 배워야하는 이유는 단순히 프로그래밍 언어들을 적재적소에 사용할 수 있어서가 아닙니다. 다양한 프로그래밍 언어를 배우면 아키텍처 디자인을 할 때 좀 더 넓은 시각을 가질 수 있게 되며, 어떠한 코드가 이상적인 코드인지 좀 더 알게 되고 좀 더 깊은 고민을 하며 구현할 수 있게 된다고 생각합니다.

이 글은 주요 프로그래밍 언어들 중 하나를 깊게 이해하고 있는 분들을 대상으로 썼습니다. 그런 분들이 좀 더 다양한 시각을 가질 수 있도록 돕기위해 제가 프로그래밍 언어들을 배우고 사용하면서 알게된 것들을 조금이나마 나눠드리고자 합니다.

#언어 소개

#C

1972년에 공개되어 로우 레벨 프로그래밍 언어
초창기 프로그래밍 언어라서 기능이 많지 않아 단순함

#C++

1985년에 공개되어 C를 바탕으로 OOP 기능들이 추가된 로우 레벨 언어
C와 다르게 템플릿을 지원하고 C에 비해 굉장히 많은 기능들이 붙어 복잡도가 높음

#Java

1995년에 공개되어 C++를 바탕으로 OOP 기능을 강화한 JVM 계열 언어
C++와 다르게 하이 레벨 언어에 가까우며 메모리를 직접 관리하지 않고 가비지 컬렉터를 사용함

#C#

2000년에 공개되고 Java를 벤치마킹하여 만들어진 하이 레벨 언어
Java와 많은 유사점을 가지고 있음

#Scala

2004년에 공개된 하이 레벨, 함수형, JVM 계열 언어
Java가 쓰는 JVM으로 작동하지만 함수형 프로그래밍에서 밴치마킹한 기능들이 많으며 동시에 OOP 개발도 가능함

#Go

2009년에 공개된 하이 레벨 언어
현대 프로그래밍 언어가 지원하는 기능 대다수가 존재하지 않는 대신 C와 비견될정도로 단순하며, 성능 또한 로우 레벨 언어 수준까지는 아니지만 빠른 편

#Rust

2010년에 공개된 메모리 안전성 문제를 해결하고 타입 시스템을 강화하기 위해 만들어진 로우 레벨 언어
다른 로우 레벨 언어가 갖지 못한 강화된 타입 시스템과 메모리 안전성을 강화하는 버로우 체커가 특징임

#Kotlin

2011년에 공개된 하이 레벨, JVM 계열 언어
Scala를 벤치마킹하였기에 Scala의 대다수 기능들을 가지고 있으며, 문법도 유사하지만 좀 더 OOP 계열 언어에 가까움

#Typescript

2012년에 공개된 하이 레벨, Javascript 기반 언어
Javascript과 달리 타입 시스템을 지원하고 있으며 타입 시스템 또한 다른 주요 언어들에 비해 정교함

#Null, Nullable, Option

가장 유명하면서도 가장 끔찍한 프로그래밍 언어 기능 중 하나를 꼽으라고 한다면 null이라고 자신있게 말할 수 있습니다. null이라는 값을 데이터에 사용하면 “없음”을 표현할 수 있습니다.

// Java 코드
public class Person {
  public String name;
  public String nickname;
}
Person person = new Person();
person.name = "Min Gyu Chi";
person.nickname = null; // 별명은 없다

null 참조는 “10억 달러짜리 실수”라는 악명이 붙어있습니다. 이는 전세계 IT회사들 통틀어 null을 참조하려다 생겨난 버그로 인해 10억 달러어치의 손실을 낼 정도로 많은 버그를 일으켰다는 관점이 있기 때문입니다. 실수로 null이 들어있는 데이터를 참조하면 값이 존재하지 않아서 프로그램을 진행할 수 없어 런타임 에러를 내게 됩니다.

// Java 코드
Integer a = null;
Integer b = a + a; // null 더하기 null은 어떤 값이지? NullPointerException 에러!

Java에서는 코드에서 null을 참조할 가능성이 있어도 컴파일을 막지 않습니다. 그렇기에 null 에러를 피하려면 모든 필드와 함수 인수를 문서화하여 null이 들어갈 가능성이 있는 값을 표기해야 합니다. 만약 문서가 잘못되었거나 null 체크하는 것을 잊었다면 곧바로 에러로 이어질 수도 있습니다.

// Java 코드
public class Person {
  public String name;
  @Nullable public String nickname; // 이 필드는 null이 들어갈 수도 있어
}

이러한 문제들을 컴파일 타임에 잡기 위해서는 IDE의 도움을 받거나 null이 들어간 필드들의 타입을 감싸야 합니다. 많은 프로그래밍 언어들은 null을 담을 수 있는 타입을 뚜렷하게 구별하고 있으며 Java도 Java 8에서부터 Optional<T> 타입을 추가하여 문서화의 영역이 아닌 타입의 영역으로 가져올 수 있도록 했습니다.

// Java 코드
Optional<String> nickname = Optional.empty();

// Rust 코드
let nickname: Option<String> = None;

// Scala 코드
val nickname: Option[String] = None;

이를 nullable 타입이라고 부릅니다. nullable 타입은 프로그래밍에 광범위하게 쓰이는 만큼 C#과 Kotlin은 nullable 타입 전용 문법을 추가하였습니다.

// C# 코드
String? nickname = null;

// Kotlin 코드
val nickname: String? = null;

다만 Java, C#, Kotlin, Rust, Scala의 nullable 타입 구현 방식은 서로간에 차이가 있습니다.

// Java 코드
public class Optional<T> {
  private final T value; // 필드 하나 그대로 null인지 아닌지 확인
  /* ... */
}

// C# 코드
// 레퍼런스 타입이 아닌 경우
public struct Nullable<T> {
  private bool hasValue; // null인지 저장하는 필드
  private T value;
  /* ... */
}

// 레퍼런스 타입인 경우
String? nickname; // 컴파일 타임에 모든 체크가 강제된다

// Kotlin 코드
val nickname: String?; // 컴파일 타임에 모든 체크가 강제된다

// Rust 코드
pub enum Option<T> { // Option<T> 이라는 타입이 있는데
  None,           // None 이거나
  Some(T)         // T를 가진 Some 이거나
}

// Scala 코드
sealed trait Option[+A]                         // Option[A] 이라는 타입이 있는데
case object None extends Option[Nothing]        // None 이거나
case class Some[+A](value: A) extends Option[A] // A를 가진 Some 이거나

여기서 특이하게도 Scala와 Rust는 null에 해당하는 None과 null이 아님에 해당하는 Some을 합친 Option 타입으로 처리하고 있습니다. Some인 경우 데이터를 저장하고 있는 필드를 가지고 있고 None이면 null에 해당되는 “없음”이라는 정보를 표현합니다. 이 방식은 Typescript의 nullable 타입 처리 방식과 어느정도 비슷합니다.

// Typescript 코드
let nickname: string | null; // string 일 수도 있고 null 일 수도 있어

Scala, Rust, Typescript가 이러한 공통점을 보여주는 이유는 세 언어 모두 타입 이론의 합 타입을 기반으로 nullable 타입을 지원하고 있기 때문입니다.

#타입 이론

데이터는 표현합니다. 하지만 표현 가능한 정보의 종류와 수는 타입에 따라 결정됩니다. 타입 이론은 데이터의 타입을 어떠한 방식으로 확장시킬 수 있는지를 정립합니다. 타입 이론은 작은 타입들로 더 큰 타입을 만들어내는 방식으로 타입을 확장시키는데, 여기서 가장 기초가 되는 개념은 **곱 타입(Product Type)**과 **합 타입(Sum Type)**입니다.

곱 타입은 한 데이터에 두 가지 정보를 모두 저장하여 두 정보를 함께 표현합니다. 많은 언어들의 struct, DTO, record들이 이에 해당합니다.

// C/C++ 코드
struct Human {
  string name;
  int age;
}

// Rust 코드
pub struct Human {
  name: String,
  age: i32,
}

// Kotlin 코드
data class Human(val name: String, val age: Int)

// Scala 코드
case class Human(name: String, age: Int)

위 예시로 들자면 사람에게 이름 정보에 더불어 나이 정보도 함께 표현하게 되므로 훨씬 많은 표현을 할 수 있게 됩니다. 이로써 사람이라는 정보가 가지는 경우의 수는 이름이 가지는 경우의 수와 나이가 가지는 경우의 수의 곱입니다.

이번에는 합타입을 살펴봅시다. nullable 타입은 데이터가 “없음”이라는 정보를 추가적으로 표현할 수 있게 됩니다. 이는 기존 데이터가 가진 표현력(Expressiveness)에서 null이라는 표현을 “더한” 것이기 때문입니다. 위 예시에서는 수많은 별명들을 표현할 수 있는 것에 더불어 별명이 없다는 것도 추가적으로 표현할 수 있게 됩니다.

// Typescript 코드
const nickname1: string | null = 'mango'; // mango라는 별명도 있을 수 있고
const nickname2: string | null = 'mystery meat'; // mystery meat도 있을 수 있고
const nickname3: string | null = null; // 별명이 없을 수도 있지

합 타입은 null 타입을 더하는 것에 국한되지 않으며 세 개 이상의 타입들을 합할 수도 있습니다.

// Typescript 코드
type CouponCode = string | number        // 쿠폰 번호는 문자열이거나 숫자
type ExcelCell = string | number | Date  // 엑셀 셀은 문자열, 숫자, 시간 중 하나

// Rust 코드
pub enum CouponCode {
  CouponString(String),
  CouponNumber(i32),
}

// Scala 코드
sealed trait CouponCode
case class CouponString(value: String) extends CouponCode
case class CouponNumber(value: Int) extends CouponCode

이처럼 곱 타입은 많은 언어들이 지원하고 있지만, 합 타입은 일부 프로그래밍 언어들만이 지원하고 있습니다. C/C++, C#은 합 타입을 지원하지 않으며 합 타입을 미약하게나마 구현하려면 추상 클래스나 인터페이스를 이용하여 제한적으로 구현하거나 타입 캐스팅을 하여서 하위 타입을 확정하여 접근해야 합니다.

#상속의 한계

아래와 같은 요구사항으로 합 타입을 묘사했다고 해봅시다.

// Java 코드
public abstract class Job {
  public int speedLevel; // speed level은 공유한다
}

public class Police extends Job {
  public int strengthLevel;
  public int fame;
}

public class Robber extends Job {
  public int robberyLevel;
  public int infamy;
}

public class Human {
  public String name;
  public int health;
  public Job job;
}

여기서 Job의 메소드를 추가하여 Police의 표현력과 Robber의 표현력을 그대로 가진 인터페이스를 구현할 수 있을까요?

// Java 코드
public abstract class Job {
  public int speedLevel;

  // 어느 정보가 어디서 왔는지 모른다!
  public abstract Optional<Int> getStrengthLevel();
  public abstract Optional<Int> getRobberyLevel();
  public Int getSpeedLevel() {
    return Optional.of(speedLevel);
  }
  public abstract Optional<Int> getFame();
  public abstract Optional<Int> getInfamy();
}

위 방법으로 개별 필드들을 노출하면 각 필드가 어떤 하위 타입에서 오는지 파악하기가 어렵습니다. 또한 유지보수로 인해 하위 타입이 바뀌게 될 경우 메소드는 삭제되지 않고 남아있기 때문에 유지보수성을 해치고 의미 없는 코드로 인해 코드 가독성 또한 낮아집니다.

그렇다면 타입 캐스팅은 어떨까요?

// Java 코드
public int getScore(Job job) {
  if (job instanceof Police) {
    return ((Police) job).fame * 100;
  } else if (job instanceof Robber) {
    return ((Robber) job).infamy * 150;
  } else {
    // 이 경우는 불가능하니까 exception을 던진다?
    throw new RuntimeException("Unreachable code");
  }
}

타입 캐스팅을 통해 타입들을 명시할 경우 세 가지 문제가 발생합니다.

하위 타입이 늘어날 수록 if문이 많아지고 처리 속도는 느려진다.
하위 타입이 추가가 되고 if문이 추가되지 않으면 컴파일 에러 대신 예외가 던져진다.
코드에 불필요한 예외가 있어서 코드 가독성을 해친다.

여기서 1번 문제는 enum과 switch-case를 이용하여 어느정도 해결이 가능합니다. 하위 타입에서 현재 타입이 어떤 타입인지 enum으로 먼저 알려주고 나서 타입 캐스팅을 하면 됩니다.

// Java 코드
public enum JobType { POLICE, ROBBER }

public abstract class Job {
  public int speedLevel;

  public abstract JobType getType();
}

public class Police extends Job {
  public int strengthLevel;
  public int fame;

  @Override public JobType getType() {
    return JobType.POLICE;
  }
}

public class Robber extends Job {
  public int robberyLevel;
  public int infamy;

  @Override public JobType getType() {
    return JobType.ROBBER;
  }
}

public class Human {
  public String name;
  public int health;
  public Job job;

  public int getScore(Job job) {
    switch (job.getType()) {
      case POLICE:
        return ((Police) job).fame * 100;
      case ROBBER:
        return ((Robber) job).infamy * 150;
    }
    // 이 경우는 불가능하니까 exception을 던진다.
    throw new RuntimeException("Unreachable code");
  }
}

이 경우 하위 타입이 늘어나더라도 switch-case는 한 번만 실행되므로 성능적인 면에서는 손해를 보지 않습니다. 이러한 방식의 데이터 타입은 Tagged Union이라고 부릅니다. 사실 Rust와 Scala의 합 타입들은 마찬가지로 일종의 Tagged Union으로 구현되어 있습니다.

// Rust 코드
// Tagged Union에 필요한 enum 필드가 숨겨져 있다
pub enum Job {
  Police {
    strength_level: i32,
    speed_level: i32,
    fame: i32,
  },
  Robber {
    robbery_level: i32,
    speed_level: i32,
    infamy: i32,
  },
}

pub fn get_score(job: &Job) -> i32 {
  match job { // 내부적으로는 switch-case와 원리가 같다
    Job::Police { fame, .. }   => fame * 100,
    Job::Robber { infamy, .. } => infamy * 150,
  }
}

// Scala 코드
// JVM의 런타임 타입 정보를 이용한다
sealed trait Job
case class Police(strengthLevel: Int, speedLevel: Int, fame: Int) extends Job
case class Robber(robberyLevel: Int, speedLevel: Int, infamy: Int) extends Job

def getScore(job: Job): Int =
  job match { // 내부적으로는 switch-case와 원리가 같다
    case Police(_, _, fame)   => fame * 100
    case Robber(_, _, infamy) => infamy * 150
  }

이렇게 Scala와 Rust의 match 키워드로 데이터가 가질 수 있는 여러가지 경우의 수에 대한 정의를 할 수 있는 기능을 **패턴 매칭(Pattern Matching)**이라고 합니다. 그중에서도 합타입으로 패턴 매칭을 하고 하위 타입에 대한 모든 케이스를 정의할 경우 switch-case와 비슷한 연산으로 최적화되어 분기가 이루어집니다. 이것을 **완전 패턴 매칭(Exhuastive Pattern Matching)**이라고 부릅니다. 완전 패턴 매칭을 사용하면 하위 타입이 추가되어도 예외 대신 컴파일 에러를 내고 코드 추가를 유도하게 됩니다. 또한 이론적으로 “불가능한” 상황에 대한 예외를 던지는 코드를 추가할 필요가 없습니다.

Java는 Java 16에서 패턴 매칭을 추가되었고 Java 17에서 sealed 키워드가 추가되어 합타입이 정식적으로 지원되고 있습니다. C#은 C# 7.0부터 패턴 매칭을 추가했지만 아직 합 타입이 없기 때문에 완전 패턴 매칭이 불가능합니다.

합 타입 없이는 완전 패턴 매칭이 불가능한 이유는 인터페이스나 클래스는 소스 코드 어디서든 상속 받고 구현할 수 있기 때문입니다. 예를들어 라이브러리 코드 내부에서 완전 패턴 매칭을 했다고 합시다. 애플리케이션 코드에서 해당 타입에 하위 타입을 추가하게 되면 라이브러리 코드에는 해당 하위 타입에 대한 경우가 추가되어 있지 않아 오류가 발생합니다.

Rust의 합 타입은 하나의 enum 정의라서 하나의 파일에 모든 하위 타입이 정의되어있고, Scala, Kotlin, Java의 경우 합 타입에 sealed 키워드를 붙이는데 이는 모든 하위 타입을 해당 상위 타입이 선언된 파일에서 구현해야한다는 것을 의미합니다.

이처럼 합 타입과 곱 타입 위주로 데이터를 정의해가며 더 큰 타입을 만들어내는 방식을 **컴포지션(Composition)**이라고 부릅니다. 상속은 잘못된 데이터 설계를 불러일으키기 때문에 Go와 Rust는 상속을 지원하지 않고 컴포지션 위주의 데이터 설계를 유도합니다.

#에러 처리와 타입 이론

합 타입과 곱 타입은 자주 쓰이는 만큼 익명으로(anonymously) 정의할 수 있는 경우가 많습니다. 그 중에서도 가장 널리 알려진 것은 곱 타입의 익명 타입인 **튜플(Tuple)**입니다. 튜플은 임의의 타입들을 곱 타입으로 묶습니다.

// C++ 코드
tuple<int, string, double> tp;

// C# 코드
(int, string, double) tp;

// Rust 코드
let tp: (i32, String, f64)

// Scala 코드
val tp: (Int, String, Double)

튜플은 함수에서 여러 값을 함께 리턴해야 할 때 유용합니다.

// C# 코드
// 상품을 구매하면 상품과 영수증이 같이온다.
public (Product, Receipt) PurchaseProduct(string productId)

// Scala 코드
// 상품을 구매하면 상품과 영수증이 같이온다.
def purchaseProduct(productId: String): (Product, Receipt)

합 타입도 익명 타입 버전이 존재합니다. Scala, Rust, Typescript가 익명적 합 타입을 지원하고 있지만, 3개 이상의 타입을 묶는 것은 Scala 3나 Typescript에서만 가능합니다.

// Scala 코드 (Scala 2)
sealed trait Either[+A, +B] // 정규 라이브러리에 정의된 타입
case class Left[A](value: A) extends Either[A, Nothing]
case class Right[B](value: B) extends Either[Nothing, B]

val couponCode: Either[Int, String]

// Scala 코드 (Scala 3)
val couponCode: Int | String | Array[Int]

// Typescript 코드
let couponCode: number | string | number[]

익명적 합 타입도 함수 출력에 쓰이는 경우가 많습니다. 다만 보통 여러 데이터를 한번에 내려주는 용도가 아닌, 오류 또는 실행 성공 결과 값을 내려주는 용도로 사용합니다. 이렇게 사용하는 경우가 너무 많아서 Rust에서는 익명적 합 타입의 이름이 Result입니다.

Scala에서는 성공 타입을 오른쪽 타입 파라미터에 넣는 경향이 있으나 Rust에서는 성공 값은 왼쪽 타입 파라미터에 넣습니다.

// Scala 코드
// 오류 없이 성공했다면 (Product, Receipt),
// 실패했다면 PurchaseError를 내려준다
def purchaseProduct(productId: String): Either[PurchaseError, (Product, Receipt)]

// Rust 코드
// 함수가 오류 없이 성공했다면 (Product, Receipt)
// 실패했다면 PurchaseError를 내려준다
pub fn purchase_product(product_id: &str) -> Result<(Product, Receipt), PurchaseError>

전통적 프로그래밍 언어들은 이러한 출력을 통한 에러 처리가 아닌 예외를 던지고 잡아서 처리하는 경우가 많습니다. 어째서 Rust와 Scala는 어째서 예외를 선택하지 않았을까요? 이는 예외가 가진 문제점들을 살펴보아야 합니다. 주요 프로그래밍 언어들 중 C++에서 가장 처음으로 예외를 추가하였는데, 가장 눈에 띄는 문제점은 함수 선언부를 확인해도 해당 함수가 예외를 던질지 말지를 알 수 없다는 것입니다.

// C++ 코드
Product purchaseProduct(string productId);        // 나는 예외를 과연 던질까 말까...

Product purchaseProduct(string productId) {
  if (productId.empty()) {
    throw new invalid_argument("Invalid id"); // 사실 던졌지롱 ㅋㅋㅋ
  }
  /* ... */
}

만약 예외가 발생하면 안되는 곳에서 이 함수를 호출하면 곧바로 프로그램 크래쉬로 이어집니다. 또한 어떤 예외를 던질지 몰라서 어느 예외를 잡아야할지 불분명해집니다. 만약 해당 함수가 수정되어 더 이상 예외를 던지지 않게 되어도 try-catch는 남아있을 것이며 다른 협업자들은 여전히 예외를 고려하며 함수를 호출할 겁니다. null 문제와 비슷하게 C++의 경우 throw() 키워드나 주석으로 문서화하는 것이 최선입니다.

이 문제를 해결하기 위해 Java는 반드시 선언부에 예외들을 기록하도록 강제하였습니다. 다만 모든 예외를 기록해야하는 것은 아니고 RuntimeException을 상속받지 않는 예외 클래스만 기록해야 합니다. 이것을 Checked Exception이라고 부릅니다.

// Java 코드
public class PurchaseException extends Exception {
  public PurchaseException(String message) {}
}

// throws PurchaseException을 넣지 않으면 컴파일이 되지 않는다
public Product purchaseProduct(String productId) throws PurchaseException {
  if (productId.isEmpty()) {
    throw new PurchaseException("Invalid id");
  }
  /* ... */
}

하지만 Java의 Checked Exception 또한 많은 문제점을 내포하고 있습니다. 이렇게 선언부에 추가해 try-catch를 강제하더라도 부주의한 개발자들이 Checked Exception을 잡아서 RuntimeException으로 감싸 다시 던지는 방법으로 회피를 한다는 의견도 있으며 선언부에 입력해야할 에러의 종류도 호출하는 함수가 많아질수록 불어납니다. 또한 예외가 어디서 발생하는지 명확하게 알 수 없는 문제는 여전히 남아있습니다.

// Java 코드
public Product purchaseProduct(String productId) throws Exception {
  // 이 많은 함수들중에서 언제 어디서 exception이 던져질까?
  ShopSystem shopSystem = getShopSystem();
  CalendarSystem calendarSystem = getCalendarSystem();
  Date date = calendarSystem.getCurrentDate();
  Wallet wallet = getWallet();
  Product product = shopSystem.getProduct(productId);
  transactionManager.makeTransaction(product, wallet);
  return product;
}

이러한 코드를 유지 보수하는 것은 지뢰밭을 건너는 것과 같습니다. 프로젝트와 코드 베이스에 대한 현저한 이해 없이 수정하는 것은 가능하면 피해야 합니다. 또한 선언부에 Exception이 추가될 때마다 그 함수를 호출하는 다른 모든 함수에도 마찬가지로 Exception을 추가해야하는 것이 대부분입니다. 그리고 코드를 읽어도 언제 어디서 예외가 던져지는지 파악하기가 어렵습니다. Rust의 경우 다음과 같이 완화됩니다.

// Rust 코드
// Product 타입이 아닌 Result<Product, MyError> 타입을 출력하기 때문에
// 에러 처리를 강제합니다.
pub fn purchaseProduct(productId: &str) -> Result<Product, MyError> {
  // Rust의 경우 에러가 발생할 수 있는 함수 호출은 에러가 발생할 경우 '?' 기호로 에러를 리턴한다.
  let shopSystem = getShopSystem()?; // 에러 발생가능
  let calendarSystem = getCalendarSystem();
  let date = calendarSystem.getCurrentDate()?; // 에러 발생가능
  let wallet = getWallet()?; // 에러 발생가능
  let product = shopSystem.getProduct(productId);
  transactionManager.makeTransaction(product, wallet)?; // 에러 발생가능
  return product;
}

이외에도 여러가지 문제점들이 있지만 결론적으로는 Checked Exception을 실패한 개념으로 여기는 것이 정론이며 차세대 OOP 언어들은 Checked Exception을 지원하지 않는 경우가 많습니다.

그렇기 때문에 Scala와 Rust는 예외의 문제점들을 피하기 위해 에러와 출력 값을 Sum Type으로 컴포지션하여 해결했습니다. 비슷하게 Go도 exception 대신 error를 다중 출력하는 방향으로 언어가 디자인 되었습니다.

// Scala 코드
def purchaseProduct(productId: String): Either[PurchaseError, Product]

// Rust 코드
pub fn purchase_product(product_id: &str) -> Result<Product, PurchaseError>

// Go 코드
func purchaseProduct(productId string) (Product, error)

이렇게 언어들이 어떠한 방식으로 타입 이론의 기초적인 요소들을 활용하였는지를 알아봤습니다. 하지만 합 타입과 곱 타입만으로는 아직 이해하기 쉽고 확장하기 쉬운 소프트웨어 아키텍처를 구현할 수 없습니다. 다음 편은 코드의 재사용성을 높이는 **다형성(Polymorphism)**이 어떠한 방식으로 이러한 문제를 해결하는지 알아볼 것입니다.

참고자료

개발자에서 기술 작가로 전직하기까지 2년 간의 이야기

Fri, 08 Jul 2022 00:00:00 GMT

#자기 소개

안녕하세요. 어느덧 15년째 건강 보험료를 납부하면서 일하고 있고, 아주 어렸을 적 경력까지 포함하면 어느덧 20년째 IT 업계에서 일하고 있는, 흔히 말하는 "고인물" 소프트웨어 엔지니어 남정현입니다. 아니, 최근에는 엔지니어가 아닌 기술 작가로서 새롭게 인사를 드립니다.

#기술 작가란 무엇인가

소프트웨어 엔지니어가 아니라 기술 작가로서 자기 소개를 한다니 의아하게 생각하시는 분들이 많으실 것 같습니다. 이 짧은 소개 한 마디 만으로도 갑자기 주의가 환기되어 저를 유심히 보는 분들도 떠오르네요.

테크니컬 라이터 (좀 더 쉬운 우리말로 "기술 작가"라고 바꾸어 부르겠습니다.) 라고 불리는 직군의 사람들이 무슨 일을 하는지 생각보다 잘 알려지지 않은 것 같습니다. 전면에 드러나는 일 보다는, 주로 완성된 제품을 실제 사용자들에게 인도하면서 같이 전달되는 사용자 가이드를 작성하는 일에 시간을 많이 쓰기 때문일 것입니다.

그러다 보니 소프트웨어 엔지니어 일을 하던 사람이 갑자기 본인을 기술 작가라고 소개하는 것의 거리감은 제법 있는 것 같습니다. 클라우드 컴퓨팅 기술이 본격적으로 산업 전반에 영향을 끼치기 전이라면, 확실히 소프트웨어 엔지니어와 기술 작가는 서로 아주 다른 두 가지 영역이라고 보는 것이 타당했을 것입니다.

하지만 최근에는 이런 경계가 빠른 속도로 옅어지고 있습니다. 소프트웨어 개발자들은 분명 논리적인 체계를 가지고 작동하는 소프트웨어를 만드는 사람이지만, 혼자서 할 수 있는 일의 폭이 작기 때문에 필연적으로 팀을 만들어 협력해야 하며, 팀을 만든다면 자연히 팀원들 사이에 정보를 주고 받을 일이 많아질 수 밖에 없습니다.

이 과정에서 팀 안에는 다양한 직군의 사람들이 협업 하면서 일을 진행하게 되는데, 각자의 직군에서는 일상적으로 사용하는 언어들이 다른 직군의 사람들에게는 생소하게 들릴 수 있습니다. 그런데 이런 생소함이 꼭 완수해야 하는 일에서 걸림돌이 된다면 어떻게 해야 할까요? 특히 이것이 비즈니스와 비즈니스 사이를 잇는 상황이라면 더욱 가볍게 볼 수 없겠죠.

즉, 기술 작가는 복잡한 정보를 독자의 눈높이에 맞추어 다양한 형태의 매체로 알기 쉽게 풀어서 설명해주는 일을 하는 사람입니다. 흔히 작가라고 하면 문학적인 재능이 있어야 한다고 이야기하지만, 기술 작가는 그렇지 않습니다.

기술 작가는 지금까지는 주로 "문서"를 만드는 일에 전념해왔고, 그러다 보니 문서 만을 만드는 사람이라는 고정 관념이 널리 퍼져있었습니다. 뒤에서도 말씀드리겠지만, 이제는 문서 뿐 아니라 다양한 매체로 이런 문제를 해결할 수 있는 것이 중요하다고 말할 수 있습니다.

#소프트웨어 엔지니어가 기술 작가로 전향하게 된 이유

소프트웨어 엔지니어로서 일하면서 저는 "무언가를 만든다"는 것에 큰 즐거움과 보람을 느끼며 살아왔습니다.

그러나 소프트웨어 엔지니어로서 문제를 해결하는 소프트웨어를 만드는 것 이전에, 그 소프트웨어를 만들게 된 상황, 배경, 맥락을 설명하고 기록으로 남기는 "문서화"는 생각만큼 많은 투자를 받지 못한다는 것을 스스로도 깨달았을 뿐 아니라, 현장에서 끊임없이 문제가 반복된다는 사실을 여러 번 접했습니다.

그러다 보니 IT 업계에서 일하는 모두가 한 목소리로 "문서화가 중요해"라고 마치 약속이라도 한 듯 누구나 같은 말을 하는 모습을 어디서나 접합니다. 하지만, 그토록 중요하다는 "문서화"는 결코 제대로 해결된 적이 없습니다. 왜 일까요?

제가 보기에 문서화는 소프트웨어를 만들 때 들여야 하는 에너지와 시간을 기준으로 봤을 때 적어도 70% 내외의 에너지와 시간을 들여야 의미 있는 결과물을 만들 수 있기 때문이라고 생각합니다.

여기에 더해 정말 안타까운 사실은, 문서화 작업으로 만들어진 결과물도 소프트웨어와 마찬가지로 가치가 시간이 지날 수록 하락하기 때문에, 지속적인 유지 보수가 뒷받침되어야 한다는 점입니다.

다시 말해, 소프트웨어를 만드는 과정과 이 과정을 거치면서 비용을 들이는 것 만큼 문서화에도 투자해야 우리가 생각하는 이상적인 모습을 마주할 수 있는 것입니다.

저는 이런 문제를 가만히 두고 보는 것이 항상 마음에 걸렸고 늘 안타까웠습니다. 소프트웨어를 "잘 만드는 것"은 차고 넘칠 만큼 충분하게 논의가 되어왔지만 왜 유독 문서화를 포함한 정보 전달은 잘 다루어지지 못하는 가에 대한 안타까움이 항상 있었습니다.

그래서, 소프트웨어 엔지니어로서의 기술적 역량을 충분히 보유하고 있으면서, 이런 문제를 집중해서 다룰 수 있는 역할을 하는 사람이 있다면 지금보다 더 나은 환경을 만들 수 있지 않을까? 하는 기대로 평소에 문서화와 정보 전달을 위한 노력에 많은 시간을 써왔습니다. 그리고 최근에는 이 방면에 온전히 집중할 수 있도록 기술 작가로서 본격적인 업을 시작하게 되었습니다.

#달라진 것, 달라지지 않은 것

소프트웨어 엔지니어로서 일을 할 때는 요구 사항에 맞추어 "동작하는 소프트웨어"를 만드는 것이 중요한 목표였습니다. 기술 작가로 일하는 지금은 "이해하기 쉬운 콘텐츠"를 만드는 것이 중요한 목표가 되었다는 점입니다.

누가 콘텐츠를 읽거나 접할 것 인지를 생각해보고, 그 사람이 어떤 상황에서 무엇 때문에 콘텐츠를 접하고 있을 것 인지를 상상하며, 어떻게 하면 그 사람에게 최선의 결과를 가져다 줄 것 인지를 고민하며 콘텐츠를 만드는 것입니다.

소프트웨어를 만들 때는 요구 사항에 맞게 동작하며, 예외적인 입력 값이 주어지더라도 사용자에게 손해가 없도록 안전하게 소프트웨어를 만들고, 사용자가 원하는 목표를 신속하고 효율적으로 달성할 수 있도록 도와주는 것과는 확실히 다른 목표라고 할 수 있습니다.

사용자가 "원하는 것을 이룰 수 있도록" 해준다는 점에 있어서 둘은 다른 듯 보이지만 하나의 공통된 목표를 지향하고 있으며, 서로 분리되지 않고 긴밀하게 연결되어야 할 것입니다. 그런 맥락에서, 일을 하는 "방법"에는 분명한 변화가 찾아왔지만, 목적지에 도착하는 것에는 여전히 변함이 없다고 생각합니다.

때로는 글 뿐만 아니라 고도화된 방법으로 정보를 추출하고 가공할 수 있는 일을 해낼 수 있다면 그것이 꼭 글의 형태로 고정되어야 할 이유가 없습니다. 몇 가지 예를 들어보죠.

글 뿐만이 아니라 동영상도 정보 교환에서 중요한 수단이라고 생각합니다. (사내 VOD 라이브러리인 OvenTV)

저는 사내 기술 세미나에서 공유되는 값진 엔지니어들의 지식을 자산화 할 목적으로, 매번 세미나가 있을 때마다 직접 영상을 촬영하고, 동영상을 편집하여 지속적으로 콘텐츠를 올리고 공유하고 있습니다. 이 과정에서 콘텐츠를 알리기 위해 다양한 노력을 기울입니다.

그리고 매월 제가 속한 팀에서는 정기적으로 타운 홀 미팅을 진행합니다. 팀 내에 속한 각 셀과 태스크 포스 들은 각자의 성과를 공유하고, 우리 팀 뿐 아니라 회사 내의 다른 팀과 자회사들을 위한 기능, 제품, 서비스를 출시하기도 합니다. 이 때 새로운 소식을 취합하여 전사 직원들을 대상으로 누구나 정보를 읽을 수 있도록 소식지를 발행하는 일을 합니다.

회사 구성원들을 대상으로 발행하는 뉴스레터

또한 콘텐츠를 만들거나, 어딘 가로 이동하는 과정에서 만들어지는 다양한 문서, 이미지, 영상 등의 콘텐츠는 모두 디지털로 저장되는 자산입니다. 디지털로 저장되는 정보는 당연히 개발자가 만드는 코드를 이용하여 처리를 자동화하고, 통찰을 얻을 수 있을 것입니다.

기술 작가로서 문서화 엔지니어링을 위한 애플리케이션 개발도 합니다.

뿐만 아니라 콘텐츠를 분석하고 가공하기 위한 자동화 작업에 프로그래밍 능력을 활용할 수 있다면, 그 가치는 매우 높을 것입니다.

한정된 인원과 시간이 가끔 걸림돌이 되긴 하나, 저는 기술 작가로 일하는 지금도 여전히 개발자로서 역량을 아낌없이 투자하고 있으며, 동시에 발전시켜 나가고 있습니다.

이처럼 기술 작가는 누구에게나 열려있고, 어느 한 쪽을 꼭 선택해야 하는 문제가 아닌 다양한 직군이 한 데 어울려 자유롭게 일할 수 있는 새로운 직업이라고 저는 자신 있게 말할 수 있습니다.

#기술 작가로서 뿌듯했던 기억

아직은 기술 작가로서 어떤 일을 할 것 인지를 치열하게 고민하던 중, 스스로의 정체성을 확립하고 일하는 방법을 규정할 수 있도록 도와주었던 중요한 프로젝트 두 가지가 있었습니다.

두 프로젝트 모두 데브시스터즈 사내 구성원을 위한 내부 서비스 프로젝트였습니다. 그 중 하나는 소프트웨어 엔지니어를 위한 자동화 기능을 제공하는 서비스였으며, 다른 하나는 전사 규모로 진행되는 타운 홀 미팅을 고도화 하는 방송 플랫폼이었습니다. 편의 상 전자를 Cargo, 후자를 DevTalk 이라고 칭하도록 하겠습니다.

Cargo 개발자용 가이드

Cargo 프로젝트를 진행하는 동안에는 문서화 사이트를 어떻게 제작하여 공유하는 것이 좋을지, 도구와 방법론 적인 관점에서 실력을 가다듬고 최적화 할 수 있는 소중한 시간이었습니다. 당시 제 목표와 의지를 실현할 수 있도록 도와주셨던 인프라 셀의 동료 팀원께 받은 도움은 정말 큰 힘이 되었습니다.

DevTalk 사용자 (시청자)용 가이드

그 후 DevTalk 프로젝트에서는 한층 더 폭이 넓어진 독자 층 (방송 시청자, 방송 스탭)을 대상으로 어떻게 해야 의미 있는 사용자 가이드를 만들 수 있을 것 인가에 대한 고민을 할 수 있었던 시기였습니다.

그리고 제품을 만드는 과정에서 언제 기술 작가가 참여해서 콘텐츠를 저작 하는 것이 좋은지, 어떻게 피드백을 주고 받는 것이 좋은 지를 학습할 수 있었던 소중한 시간이었습니다. 무엇보다도, 이 프로젝트에서 저는 회사 전체에 저를 "기술 작가"로서 알릴 수 있었던 데뷔 프로젝트였기에 뜻 깊은 시간이었습니다.

두 개의 프로젝트를 마치고 난 후, 제가 작성한 가이드가 실제로 문제 해결에 도움이 되었다는 피드백, 시스템과 서비스를 이해할 때 도움이 되었다는 피드백을 접할 수 있었고, 그 순간 제가 이 일을 올바른 방향으로 잘 해 나가고 있다는 것을 알 수 있어 행복했습니다.

#기술 작가가 되실 여러분들을 위하여

기술 작가는 엔지니어 뿐 아니라, 특정 분야와 기술에 관심이 있다면, 본인이 인문학을 전공했든, 이공계를 전공했든 상관없이 누구나 도전할 수 있는 영역이라고 생각합니다.

저는 앞에서 "문서"를 만드는 일을 하는 사람이라는 "고정 관념"이 있다고 말했습니다.

문서를 기술 작가가 제작할 수 있는 하나의 제품이라고 본다면, 문서를 만들기 위해 인문학적 접근이 필요할 수도 있고, 공학적 접근이 필요할 수도 있는 것입니다.

그리고 "제품"이라면 "문서"만이 최종 결과물이라고 정해 놓을 이유 또한 없습니다. 즉, 저는 이 분야가 특정 분야의 전유물이라고 생각하지 않습니다.

그러므로 '나는 엔지니어여서 문서를 쓰는 것이 소질이 없다'고 한정 지을 이유가 없고, 인문 계열 전공이라서 '기술을 몰라 문송하다'는 말을 할 이유도 없습니다. 각자가 집중하고 만들어낼 수 있는 결과는 고유한 가치를 지니며, 모두가 소중한 자산이 됩니다.

옛 속담 중에 "구슬이 서 말이라도 꿰어야 보배다"라는 말이 있듯, 기술 작가에 출신은 중요하지 않다고 생각합니다. 자신의 전공, 적성에 연연하지 마시고 팀 동료, 그리고 새로 들어오는 팀원들을 위해 작게 실천할 수 있는 것부터 조금씩 문서를 써보세요! 틀림없이 누군가는 여러분에게 감사할 것이고, 피드백도 아끼지 않을 겁니다.

#앞으로의 계획

우리 회사는 **<쿠키런: 킹덤>**의 기록적인 성공과 함께 전세계에서 사랑 받는 IP (지적 재산)을 보유한 회사가 되었다고 생각합니다. 당연히 같이 일하는 사람들이 한국어를 사용하는 사람만 있다고 가정하는 것도 그래서 더는 맞지 않는 말이라고 생각합니다.

정보를 누구에게나 손쉽게 전달할 수 있으려면, 독자가 한국어 만을 사용할 것이라는 가정에서 벗어나 어떻게 하면 효율적으로 여러 언어로 콘텐츠를 번역해서 출시할 것 인지에 대한 고민도 자연스럽게 하게 됩니다.

제품을 접하는 고객들을 위한 다국어 작업도 중요하지만, 우리 회사 구성원들을 위한 다국어 정보 공유는 어떻게 하는 것이 좋을 지에 대한 고민이 나날이 깊어지고 있습니다.

멀지 않은 시일 내에 저는 이 고민을 포함하여 나날이 커지고 있는 회사의 규모에 맞는 비즈니스 테크니컬 라이팅을 효과적으로 수행할 수 있는, 테크니컬 라이팅 내의 세부적인 역할, 직군에 대한 고민도 구체적으로 해보고 싶습니다.

그리고 고민이 끝날 무렵, 제 자리 옆에 앉아 같이 머리를 맞대고 기술 작문 활동을 고민하는 동료들이 함께 하는 모습을 상상해봅니다.

#덧붙임

기술 작가로서 일을 시작할 무렵, 라인 (LINE)에서 기술 작가로 일하신다는 분들의 글과 영상을 보며 방향성을 잡고 큰 힘을 얻을 수 있었습니다.

그 외에도 딱 맞아 떨어지지는 않지만, 테크니컬 라이팅이라는 큰 분야를 이해하는데 도움이 될 만한 커뮤니티에 참여하고, 여러 강의를 보면서, 이 분야에서 일하는 분들이 어떤 일을 하고, 무엇을 중요하게 생각하는지 알아갈 수 있었습니다.

그 때 제가 도움받았던 자료들 가운데 몇 가지를 골라 기술 작가로 도전하시는 분들을 위해 공유드립니다.

블로그

YouTube 영상

라인의 전정은 님이 말하는 테크니컬 라이팅의 모든 것

온라인, 오프라인 교육

커뮤니티

WriteTheDocs Seoul 커뮤니티

컨퍼런스

Technical Communication Summit

테스트 케이스 관리를 JIRA로 하자! : 웹서비스셀의 테스트 관리 툴 도입기

Tue, 05 Jul 2022 00:00:00 GMT

안녕하세요! 웹서비스셀에서 웹 QA를 담당하고 있는 강유경, 송선주입니다. 저희는 데브시스터즈의 웹서비스 품질을 높이는 업무 및 QA 프로세스 개선 업무 등을 진행하고 있습니다. 기존에 엑셀로 관리하던 테스트 케이스(Test Case) 작성을 탈피하고 JIRA에서 제공하는 테스트 관리 툴로 테스트 케이스를 작성부터 테스트 수행, 결과 보고서와 이슈(Issue)를 관리하는 방법에 대해 소개해 드리고자 합니다.

#엑셀로 테스트 케이스 관리가 점점 어려워져

대부분의 QA 직군은 테스트를 진행하기 전 테스트 케이스를 작성하며 관리합니다. 테스트를 수행하면서 이슈를 찾고, 어느 부분에서 이슈가 발생했는지 또 수정은 되었는지, 어떤 항목은 이번 환경에서는 제외되었는지, 발생한 이슈로 인해 더는 테스트 진행이 불가한지 등 테스트 케이스에 기록들을 남기고 다양한 활동들을 합니다. 테스트 케이스는 테스트 진행률과 이슈 발생률 등을 한눈에 볼 수 있는 자료로 활용됩니다.

저희 웹서비스셀에서도 엑셀을 사용해 테스트 케이스를 관리해왔습니다. 게임과 달리 웹서비스셀의 프로젝트는 주기적으로 관리하는 프로젝트보다는 1회성으로 개발 및 검증을 하는 프로젝트가 많습니다. 테스트 케이스 관리 툴로 엑셀을 사용하다 보니 크게 5가지의 불편함을 느낄 수 있었습니다.

1) 작성해야 하는 테스트 케이스는 많고, 테스트 기간은 너무 짧다

웹의 경우 브라우저(Browser)와 기기 별로 검증이 필요하고, 기기 별로 제공되는 브라우저가 달라 해상도까지 고려할 사항이 많습니다.

테스트 케이스에 기기 별 브라우저 및 해상도 항목을 추가한 모습

위 이미지에서 보이는 것과 같이 PC는 OS 기준으로 크롬, 사파리, 인터넷 익스플로러 브라우저를 확인하고, 모바일의 경우는 OS 기준으로 크롬, 사파리, 삼성 인터넷, 네이버, 웹 뷰까지 확인합니다.

그러다 보니 스펙이 크거나 새로운 프로젝트의 경우 Full 테스트 케이스를 작성하게 되면 테스트 케이스가 1,000개가 넘는 경우가 많아 작성 기간도 일주일 이상 소요될 때가 있습니다. 이렇게 되면 짧은 기간 안에 많은 양의 테스트 케이스를 상세하게 쓰기 쉽지 않습니다.

기기와 브라우저를 포함하니 총 테스트 케이스가 4,950개가 된 것을 확인할 수 있습니다.

아찔한 테스트 케이스, PC와 모바일 별로 작성한 흔적들

QA직군에 계신 분들이라면 누구나 한 번쯤 이런 테스트 케이스를 작성하고 이를 기반으로 검증을 수행해 보셨을 거라는 생각이 듭니다. 이렇게 테스트 케이스가 길어지면 이를 확인하는데 어려움이 있습니다. 그리고 협업하는 다른 부서의 분들도 확인하는데 어렵다는 피드백을 주셨습니다. 더구나 짧은 기간 안에 브라우저별, PC/모바일별로 기획이 다른 경우라면 시간이 매우 부족한 경우가 많았습니다.

2) 기능 업데이트 시 버전 관리의 어려움이 있다

2020년 상반기까지는 in-house 제품 및 사전 예약이 업무의 대부분을 차지했지만, 2020년 하반기부터는 더욱 많은 게임 사이트와 기업 사이트에 대한 업무까지 진행하게 되었습니다. 게임 관련 웹 프로젝트의 경우 게임별, 언어별 등 다양한 케이스가 있다 보니 이걸 엑셀 시트에 추가하더라도 버전 관리가 어려웠습니다. 또한, 완료한 테스트 케이스에서 다음 버전으로 업데이트 시 테스트 케이스를 복제한 뒤 새로 만들어야 합니다. 새로 추가가 된 후 어느 부분이 이번에 새로 추가되었는지 표시까지 해줘야 합니다.

노란색, 초록색으로 형형색색 추가/수정된 테스트 케이스를 표시해준 모습

3) JIRA에 등록한 이슈를 또 엑셀에 복사/붙여넣기를 해야 한다

엑셀에 JIRA 이슈 링크를 연동할 때 보통 하나의 케이스에 여러 개 이슈를 추가하게 됩니다. 이때, 가끔 알 수 없는 이유로 최상위에 있는 이슈만 하이퍼링크(Hyperlink)가 연결되는 것을 경험하신 분들이 많으실 겁니다.

해당 이슈를 보고 싶을 때 직접 URL을 입력해서 들어가거나 아예 JIRA 화면을 띄운 채 들어가야 하는 불편함이 있습니다.

이슈를 등록하고 하나의 JIRA 티켓 링크를 복사하고, 다시 엑셀에 붙여 넣고, 하이퍼링크는 한 개만 연결되는 이런 과정들이 계속 반복되어 피로감이 있었습니다.

또한, 별도로 이슈 관리 시트도 만들었는데 이슈가 수정되었을 경우 일일이 수정 확인 후 상태 변경이 필요했습니다. 이런 과정들이 모두 수작업으로 진행되다 보니 소요되는 시간이 상당했습니다.

4) 이전 테스트 결과를 보려면 과거 테스트 케이스를 일일이 열어봐야 한다

기능 업데이트 시 버전 관리의 어려움과 연결되는 부분인데, 이전 테스트 결과를 보려면 과거 테스트 케이스를 하나하나 열어서 확인해야 합니다. 과거부터 쌓아온 테스트 케이스이고, 히스토리 관리가 잘 되었다고 하더라도 수작업으로 진행하고 있어 많은 비효율이 발생하게 됩니다.

5) 이미지 삽입 등의 첨부 파일을 삽입 할 경우 테스트 케이스 템플릿이 한정적이기 때문에 보기 및 관리가 어렵다

아무래도 엑셀을 사용하기 때문에 이미지가 삽입되면 셀의 크기가 커지기 마련입니다. 1,000개가 넘어가는 테스트 케이스에 이미지까지 추가된다면 문서 한 페이지의 크기가 너무 커져 각각의 테스트 케이스를 확인하는 것이 아주 어려워집니다. 셀 내에 이미지를 삽입할 수 있으나 셀의 크기가 작다면 이미지의 크기도 작아져 따로 확대해서 이미지를 확인하고, 다시 줄이는 일련의 과정을 거쳐야 합니다.

위와 같은 문제들로 인해 저희는 공통으로 한 가지를 생각하게 됐습니다.

"그러면 우리 엑셀에서 벗어나 보는 건 어떨까요?"

#엑셀에서 벗어나서 어떤 테스트 관리 툴을 사용해볼까?

여러 가지 많은 테스트 관리 툴이 있지만 저희는 JIRA와 연동이 가능한 QAlity와 Zephyr Scale을 선정했습니다.

어떻게 하면 테스트 케이스를 줄이고, 테스트 수행부터 결과까지의 시간을 단축 할 수 있을까?에 대한 고민을 다른 셀의 QA직군에 계신 분과 이야기를 나누다가 QAlity를 제안받았습니다. QAlity는 쉽게 앱 설치가 가능했고, 다양한 상황에서 유동적으로 대응이 가능하다는 것에 눈길이 갔습니다.

QAlity를 활용한 초기 제품 개발팀의 테스트 적용기

한 가지 툴만 사용하기 보다는 다른 툴도 비교해보고 싶다는 생각이 들어 인터넷 검색을 통해 ‘상위 20개 최고의 테스트 관리 도구 목록’의 블로그 글 내용에서 Zephyr Scale을 알게 되었습니다. 사용하기 쉽고, 유연해 시작하는데 최소한의 노력만 들일 수 있다는 문구가 매력적으로 느껴졌습니다.

상위 20개 최고의 테스트 관리 도구 목록

이 두 가지 테스트 관리 툴로 웹서비스셀의 프로세스와 얼마나 잘 맞을지 비교 검증하게 되었습니다.

1) 테스트 케이스 작성

기존과 제일 큰 차이점은 바로 Test Step(재현 방법)과 Expected Result(기대 결과)만으로 작성이 가능한 점이었습니다. 이전에는 대분류/중분류/소분류/사전 조건/재현 방법/기대 결과 이런 식으로 작성했다면, 재현 방법과 기대 결과만 작성하니 작성 시간이 굉장히 줄어들었습니다.

QAlity와 Zephyr Scale로 작성한 테스트 케이스

2) 테스트 수행

작성한 테스트 케이스를 수행하기 위해선 테스트 사이클(Test Cycle)을 설정해야 합니다. 테스트 사이클은 작성한 테스트 케이스를 실행할 수 있게 해주는 기능입니다. 테스트 케이스와 연결하고 실행하면 본격적으로 수행할 수 있는 환경이 만들어집니다.

테스트하면서 결과를 직관적으로 확인할 수 있고, 이슈와 테스트 케이스 간에 추적성이 높아졌습니다. 이런 방식으로 JIRA 티켓 복사/붙여넣기에서 해방되었습니다.

QAlity와 Zephyr Scale의 테스트 수행 및 이슈 연결한 모습

3) 테스트 결과

테스트 사이클로 테스트를 완료하면 자동으로 결과가 생성됩니다. QAlity는 테이블과 상태 그래프, 담당자 그래프 형태로 결과를 볼 수 있었습니다. Zephyr Scale의 경우는 다양하게 결과를 나타낼 수 있는데 그중에서 전체적으로 볼 수 있는 항목(Test execution results (summary))을 선택해 종합적인 결과를 확인했습니다.

QAlity와 Zephyr Scale의 결과

사용한 경험을 토대로 이제 2가지 툴의 장/단점을 비교해보도록 하겠습니다.

QAlity의 장/단점은 아래와 같습니다.

QAlity 장점

오타 및 새로 변경할 사항이 있으면 바로 수정할 수 있습니다.
테스트 케이스 작성에 필요한 항목이 줄어들었습니다.
테스트 케이스에 이슈를 바로 등록/연결할 수 있습니다.

QAlity 단점

상태가 Not Executed, In Progress, Pass, Fail, Blocked밖에 없습니다.
- 5가지만 사용할 수 있으며, 추가 및 수정 불가합니다.
테스트 케이스가 새 창이 아닌 현재 페이지에서 열리고 로딩이 깁니다.
- 각 케이스 별로 찾는 시간이 많이 소요됩니다.

Zephyr Scale의 장/단점은 아래와 같습니다.

Zephyr Scale 장점

테스트 케이스를 작성하고, 테스트 사이클을 연결하고, 테스트 케이스를 실행하는 것까지 자연스럽게 연결되어 있어 편하게 관리할 수 있습니다.
테스트를 수행하는데 걸리는 시간을 기록합니다.
테스트 케이스에 이슈를 바로 등록/연결할 수 있습니다.
작성한 테스트 케이스를 엑셀이나 다른 파일로 변환할 수 있습니다.
상태가 Not Executed, In Progress, Pass, Fail, Blocked이 디폴트로 있고, 설정을 통해 상태를 추가할 수 있습니다.

Zephyr Scale 단점

오타 및 새로 변경될 사항이 있으면 테스트 케이스를 수정하고 테스트 사이클을 갱신해야 하는 추가 작업을 해야 합니다.
이슈 등록 시 재현 방법과 기대 결과가 반영될 줄 알았으나 직접 입력해야 하는 점이 아쉬웠습니다.

위 2가지 툴을 사용해보니 QAlity와 Zephyr Scale의 장점들을 놓치기 어려웠지만, 저희는 결국 Zephyr Scale을 채택하게 되었습니다. 그 이유는 테스트 케이스를 작성, 수행, 결과를 만들 때까지 연결되며 편하게 관리할 수 있다는 점이 가장 컸고, 무엇보다 상태를 추가할 수 있는 점이 가장 좋았습니다. Not Executed, In Progress, Pass, Fail, Blocked 외에도 N/A, N/I 항목 등 다양하게 커스텀마이징이 가능해 웹서비스셀의 QA 업무 성격과 잘 맞았습니다.

#Zephyr Scale 선택 후 이전보다 나아진 점

저희가 사용해보고 나아진 점은 아래 6가지를 나열해 보았습니다.

1) 엑셀에서 벗어나면서 테스트 케이스 작성 시간이 70% 단축되었다

앞서 위에서 언급한 것과 같이 재현 방법과 기대 결과만 작성하니 1주일 이상 걸리던 테스트 케이스 작성 시간이 1~2일 정도로 확연히 감소했습니다. 1,000개가 넘던 테스트 케이스가 이제는 25~30개로 충분히 작성할 수 있었습니다.

또한, 재현 방법이나 기대 결과를 입력하는 곳에 이미지나 다른 첨부 파일 삽입이 가능합니다. 삽입하더라도 템플릿이 일그러지거나 이미지가 작아지지 않습니다. JIRA에서 제공되는 기능이기 때문에 어렵지 않게 작성을 할 수 있습니다.

마지막으로, 테스트 케이스를 추가할 때 자동으로 순서가 지정되어 번호를 직접 부여하지 않아도 자동으로 번호가 부여됩니다. 그리고 테스트 케이스의 순서도 자유롭게 변경할 수 있어서 다른 곳에 잘못 추가했더라도 쉽게 순서 변경을 할 수 있고, 복제도 가능합니다.

작성된 테스트 내용

2) 이슈 관리가 굉장히 단순해졌다

해당 테스트 케이스에서 이슈 발생 시 바로 이슈를 등록할 수 있고, 등록된 이슈의 티켓 번호만 안다면 검색해서 연결할 수도 있습니다. 수동으로 복사/붙여넣기 하던 시절에는 느끼지 못한 감동이었습니다.

이슈가 수정되면 케이스에도 상태가 반영되어 이슈 확인 및 종료하는데도 수월했습니다.

케이스에 나온 이슈 맵핑된 모습

3) 테스트 수행 시 시간을 측정해주는 기능이 있어서 얼마나 걸렸는지 확인할 수 있다

테스트 사이클에서 테스트 수행할 때 소요되는 시간을 측정할 수 있습니다. 대신 다른 테스트 케이스로 이동하면 시간은 멈춥니다. 이전에는 테스트 소요 시간을 체감으로만 알 수 있었고, 현재는 이 기능으로 테스트 리소스 측정을 정확하게 할 수 있어 다음 테스트를 계획하는 시간을 확보할 수 있었습니다.

시간 측정 시 나오는 결과

4) 결과를 한눈에 볼 수 있는 툴이 제공되어 편리하다

지금까지는 복잡한 엑셀 수식을 사용해 결과 보고서를 작성했습니다. 효과적으로 작성이 되는 것 같지만 수식에 오류라도 있으면 결과는 제대로 나오지 않습니다. 하지만 Zephyr Scale에서는 결과 보고서를 보여주는 툴이 제공됩니다. 원하는 형태의 보고서를 간편하게 만들 수 있습니다.

제공되는 결과 리포트

5) 테스트 케이스를 처음 접한 사람도 쉽게 이해할 수 있다

사인 오프(Sign-off: “제품이 시장에 출시되어도 됩니다” 라고 선언)를 할 때에도 유관 부서와 함께 해당 케이스들을 내부에 공유하면서 체크를 하는데 사용했습니다. 기존 엑셀의 경우 내용이 너무 길어서 체크하면서 검증하기가 어려움이 있었으나, Zephyr Scale 의 경우 재현 방법/기대 결과/등록한 이슈가 한번에 노출되어 처음 본 사람도 알기 쉬웠습니다.

전체 케이스 모습

6) 기타

버전 관리도 쉬운데다가 프로젝트별로 폴더를 생성해 관리를 할 수 있어 좋다
- 테스트 케이스별 엑셀 시트와 같이 LNB 메뉴가 제공되고 폴더 별로 관리가 쉬워졌고 이전 테스트 케이스를 바로 확인할 수 있었습니다.
검증 시간이 많이 절약됐다
- 플로우에 맞게 순서에 따라 작성 및 테스트하는데 시간이 감소하고, 좀 더 엣지 케이스(Edge case) 위주의 검증을 할 수 있는 시간이 늘었습니다.

#엑셀을 대체 할 만큼 좋은가?

테스트 케이스를 작성하는 과정에서 굉장히 시간을 단축할 수 있었고, 결과 보고서 작성도 빨라졌습니다. 하지만 JIRA에서 제공되는 툴이기 때문에 JIRA를 사용하지 않는 유관부서에서 확인하기 어려워 테스트 케이스 및 결과를 Zephyr Scale에서 pdf 파일로 다운받은 후 가공해서 유관부서에 전달하고 있습니다. 결과적으로 리소스는 낭비를 줄이고 이전보다 빠르게 결과 공유가 가능했습니다.

제공되는 결과 리포트에서 추출해 결과 보고를 작성한 일부 내용

엑셀을 대체할 만큼 좋은가? 라고 누군가 물어본다면, 네라고 답변할 수 있습니다. 테스트 케이스 작성도 편리했지만, 무엇보다 테스트 케이스 수행부터 결과 보고서 작성, 특히 이슈 관리를 유연하게 할 수 있었습니다. 이렇게 효과적으로 리소스를 관리해서, 예외 케이스가 발생했을 경우 셀 구성원들과 협업을 통해 대응할 수 있었습니다.

저희와 같은 고민을 하신 분들이 계신다면 소개해 드린 QAlity와 Zephyr Scale을 테스트 관리 툴로 사용해 보시는 건 어떨까요? 30일 무료 체험 버전이 있어서 어떤 툴이 본인의 QA 업무에 맞는지 비교해 보시고 선택하시는 걸 추천해 드립니다.

긴 글 읽어주셔서 감사드립니다.

데브시스터즈에서는 작은 불편함을 참지 않고 새로운 기술을 받아들여 개선하려는 도전적인 QA 인재를 기다리고 있습니다. 여러분과 함께 하길 기다리며 글을 끝내도록 하겠습니다. 그럼 이만!

“DevOps”의 인적 확장 (The human scalability of “DevOps”)

Tue, 28 Jun 2022 00:00:00 GMT

안녕하세요, 데이터플랫폼/인프라셀의 데브옵스 엔지니어로 일하고 있는 원대영입니다.

이 글은 제가 DevOps 엔지니어로 지내면서 읽어본 많은 글 중 가장 마음에 두고 오래오래 읽어보았던 글이었습니다. 2018년 6월의 글로 벌써 4년 전의 글인데, DevOps 세계에선 4년이란 시간이 짧지 않은데도 이 당시에 이런 이야기를 할 수 있었다는 건 참 대단하다고 생각하고, 동시에 지금 읽어봐도 여전히 통찰력있는 글이라고 생각합니다. 언젠가 책 ‘어린 왕자' 를 어릴 때 읽는 것과 성인이 되어 읽을 때 다르게 읽힌다는 말을 들은 적이 있는데, 제게 기술 관련 글에선 이 글이 그랬습니다. 시간을 두고 한 번씩 읽어볼 때마다 다르게 읽히며 마음 저리게 다가온 글이었고, DevOps 엔지니어의 조직구조나 역할, 방향성을 치열하게 고민해봤다면 뼈아픈 글일 거라고도 생각합니다.

원저자의 허락을 구했으며, 이 글을 번역할 수 있게 허락해준 Matt Klein에게 감사 인사를 남깁니다. 저자에 대한 소개를 안 할 수가 없는데, Matt는 무려 DevOps 엔지니어라면 많이 알 Envoy 의 창시자입니다. 그의 개인 홈페이지에는 읽어보면 좋을 다양한 글도 많으니 한 번 방문해보는 것 또한 추천합니다. Thank you, Matt!
저는 전문 번역가도 아니고 영어가 그리 능숙하지도 않기 때문에 많은 의역을 거쳤습니다. 한국어 번역이 애매하거나 더 어렵게 느낄 만한 표현들은 영어를 그대로 쓰거나 영어 발음대로의 한국어로 썼으니 양해 부탁드리며, 오역에 대한 의견은 tech_blog@devsisters.com로 주시면 언제든 감사하게 받겠습니다.

원문: https://medium.com/@mattklein123/the-human-scalability-of-devops-e36c37d3db6a

최근 트위터에 썼듯, 저는 요즘 꽤 많은 시간을 들여 “DevOps”의 인적 확장(human scalability)에 대해 생각하고 있습니다. (“DevOps”에다가 따옴표를 붙인 건, 이에 대해 추후 서술할 다양한 정의가 있기 때문입니다.) 그렇게 내려본 결론은, DevOps는 작은 엔지니어링 조직들에서 굉장히 잘 돌아갈 수도 있지만, 신중한 생각과 관리 없이는 큰 인적/조직적 확장(scaling) 문제를 일으킨다는 것입니다.

#DevOps란 무엇인가 (What is DevOps)

DevOps라는 용어에 대해선 많은 사람들이 다양한 의미로 말합니다. 제가 이 글을 본격적으로 시작하기 전에, 제가 어떤 의미로 DevOps라는 용어를 쓰는지 정리하는 게 중요해 보입니다.

Wikipedia에서 정의하는 DevOps는 다음과 같습니다:

DevOps(“Development”와 “Operations”의 합성어) 는 소프트웨어 개발(Dev)과 운영(Ops)을 융합한 소프트웨어 개발 문화와 관행(practice)을 말한다. DevOps movement의 주요 특징은 통합, 테스팅, 릴리징부터 배포, 인프라 관리까지 소프트웨어를 만드는 모든 과정에서의 자동화 및 모니터링을 강력하게 추구하고 제안하는 것이다. DevOps는 짧은 개발 사이클, 잦은 배포 주기, 더 신뢰할 수 있는 릴리즈를 추구하여 비즈니스 목표와 방향성을 더 밀접하게 맞춘다.

저는 보다 더 좁고, 살짝 다른 형태로 DevOps를 정의하는데요,

DevOps는 개발자가 프로덕션 환경에서 24시간 365일 서비스가 운영되도록 책임지게 하는 방법(practice)이다. 이것은 공용 인프라 기반기술을 사용한 개발, 테스팅, 상시 장애대응, 신뢰성 엔지니어링(reliability engineering), 장애 복구, SLO 정의, 모니터링 셋업 및 알람 설정, 디버깅 및 성능 분석, 장애 근본 원인 분석(root cause analysis), 프로비저닝 및 배포 등을 포함한다.

Wikipedia의 정의와 제 정의와의 구분(‘개발 철학’ 대 ‘운영 방식’)은 저의 업계 경험을 바탕으로 만든 중요한 내용입니다. DevOps “movement” 일부는 느리게 움직이는 “오래된" 회사들에게 고도로 자동화된 최신 인프라와 개발 방법의 장점들을 설명하는 것입니다. 예를 들면, 서로 느슨하게 연결된(loosely-coupled) 서비스와 API 및 팀들, 지속적 통합(continuous integration), master에서 일어나는 작고 잦은 배포, 애자일 커뮤니케이션 및 플래닝, 클라우드 기반의 유연한 인프라 등입니다.

제 최근 10년의 커리어를 보면, AWS EC2, 상장 이전의 Twitter, Lyft 같은 급성장하는 인터넷 회사(hyper-growth Internet companies)에서 일을 해왔습니다. 더불어 Envoy를 만들고 알리기 위한 지난 2년간, 수많은 급성장 인터넷 회사들의 기술 아키텍처와 조직 구조를 마주하고 배웠습니다. 그 기업들에게 자동화, 애자일 개발/플래닝, 기타 DevOps “best practice”를 받아들인다는 건 당연한 일인데, 그건 이들이 생산성 향상에 대해 잘 이해하고 있기 때문입니다. 그 대신, 이러한 엔지니어링 조직이 갖는 당면 과제는 ‘비즈니스 성장, 개인의 성장 및 (비즈니스/채용에 대한) 경쟁 등에 대한 극심한 압박과 시스템 신뢰성(reliability) 간의 균형을 어떻게 맞추는가’ 입니다. 이 글의 이후 부분은 저의 개인적 경험에 근거한 것으로, 맞지 않는 경우가 있을 수 있고, 특히 분기마다 한 번씩 monolithic 소프트웨어를 배포하는 천천히 움직이는 회사들이나 더 빠르고 애자일한 개발 방법을 도입하고자 하는 회사같은 경우엔 맞지 않을 수 있습니다.

#인터넷 어플리케이션 운영의 역사 (A brief history of operating Internet applications)

제가 현대 인터넷 시대(modern Internet era)라고 일컫는 최근 30여년 동안, 인터넷 어플리케이션 개발 및 운영은 (제 생각에) 세 가지 뚜렷한 단계를 거쳤습니다.

첫 번째 단계에선, 인터넷 어플리케이션은 만들어지면 “꼼꼼하게 포장(shrink-wrapped)” 된 프로그램이 배송되는 것처럼 배포됐습니다. 어플리케이션을 개발하고 운영하기까지의 아주 긴 엔지니어링 주기에 걸쳐 세 가지 서로 다른 직무(개발, QA, 운영)가 협업했습니다. 이 기간 동안 각 어플리케이션은 전용 데이터 센터나 공용 데이터 센터(colocation facility)에 배포되므로, 해당 장소의 네트워크/하드웨어/시스템 관리에 익숙한 운영 인력이 추가로 필요했습니다.
두 번째 단계에선, 90년대 후반 ~ 2000년대 초반의 Amazon, Google을 필두로 빠르게 급성장하는 회사의 인터넷 어플리케이션들이 loosely-coupled 서비스, 빠른 개발 및 배포, 자동화 등 현대 DevOps movement와 비슷한 형태의 시도를 시작했습니다. 이런 기업들은 여전히 큰 자체 데이터 센터를 운영하고 있는데, 이런 규모 때문에 모든 서비스에 필요한 공통 문제(네트워킹, 모니터링, 배포, 프로비저닝, 데이터 스토리지, 캐싱, 물리 인프라 등)를 해결하는 중앙 집중식 인프라 팀들을 만들기도 했습니다. 그러나 Amazon과 Google은 그러한 역할들을 하나의 개발 직무로 완전히 통합하진 않았는데 (이를 테면 Amazon의 Systems Engineer, Google의 Site Reliability Engineer처럼), 각 직무가 요구하는 능력과 관심사가 다르다고 인식했기 때문입니다.
세 번째 단계는 클라우드 네이티브 단계라고 할 수 있습니다. 인터넷 어플리케이션은 이제 “Big 3” 퍼블릭 클라우드가 제공하는 유연한 아키텍처에 기반하여 만들어집니다. 시장에서의 높은 실패 가능성을 감안하다보니 제품을 가능한 빠르게 시장에 내놓는 것이 기업의 최우선 목표가 되어왔는데, 클라우드 네이티브 시대에선 “즉각" 제공되는 기반기술들을 통해 이를 이전보다 훨씬 더 빠른 속도로 반복하는 게 가능해졌습니다. 이 시대에 시작한 기업의 또 다른 특징은 소프트웨어 개발 역량을 보유하지 않은 엔지니어 역할을 두는 것을 지양한다는 것입니다. 사용할 수 있는 인프라 기반이 (그들 생각에) 상대적으로 탄탄하다보니, 스타트업의 인건비를 엔지니어링과 운영을 동시에(DevOps) 할 수 있는 소프트웨어 개발자를 위해 쓰는 게 더 낫습니다.

세 번째 단계의 기업들이 운영 전담 인력을 뽑지 않는 방향으로 변화한다는 건 아주 중요합니다. 분명 이러한 회사가 공용 데이터 센터의 기기를 다룰 풀타임 시스템 관리자를 필요로 하진 않지만, 이전에 그런 업무를 수행했던 사람은 보통 시스템 디버깅, 성능 프로파일링, 운영에 대한 직관(Intuition) 등 다른 20%의 스킬들을 제공했습니다. 신규 회사들은 이제 중요하고 쉽게 대체되지 않는 스킬셋을 보유한 인력 없이도 만들어집니다. (역자 주: 여기서 신규 회사가 갖지 않는 스킬셋이란, 데이터 센터의 네트워크 설치, 사전 부팅 실행 환경(PXE) 구성, 장소의 항온항습이나 바닥 관리 등 서버실을 관리하던 운영 전담 엔지니어가 해왔던 것들을 의미한다고 볼 수 있겠습니다.)

#왜 DevOps가 현대 인터넷 스타트업에서 잘 돌아갈까? (Why does DevOps work well for modern Internet startups?)

위에서 정의한 DevOps는 현대 인터넷 스타트업에서 정말 잘 동작할 수 있는데, 그 이유는 다음과 같습니다.

제 경험 상, 성공한 스타트업의 초기 엔지니어는 엔지니어 중에서도 특별한 부류입니다. 그들은 위험을 감내할 수 있고(risk tolerant), 아주 빠르게 배우며, 기술부채의 증가가 있더라도 아주 빠르게 무언가를 만들어내는 것에 익숙하고, 여러 시스템과 언어로 작업할 수 있으며, 보통 시스템 관리나 운영에 대한 경험이 있고, 계속 배우길 원하는 사람입니다. 다시 말해, 보통의 스타트업 엔지니어들은 DevOps 엔지니어가 되기 아주 적합한 사람들입니다. 물론, 그들이 그렇게 불리길 원하는지와는 별개입니다. (전 아닙니다 😉)
위에서 서술했듯, 현대 퍼블릭 클라우드들은 기반이 되는 인프라들을 아주 훌륭하게 제공합니다. 과거에 진행하던 가장 기본적인 운영 작업은 자동화되어, MVP를 만들어서 시장에 적합한지 확인할 수 있을 만큼의 좋은 기반이 만들어졌습니다.
저는 개발자들이 자신이 작성한 코드에 대해 책임을 지고 장애대응을 할 때 그 시스템의 퀄리티가 향상된다고 굳게 믿는 사람입니다. 누구도 장애로 호출 받는 걸 좋아하진 않지만, 이런 피드백 루프는 더 나은 제품을 만들어냅니다. 또한 1번에서도 설명했듯 보통 초기 스타트업에서 일하는 것에 매력을 느끼는 엔지니어는 배우는 것과 운영 업무를 하는 걸 꺼리지 않는 사람들입니다. 특히 제품 신뢰성이 낮아도 큰 영향을 받지 않는 초기 스타트업의 경우에는 이런 경향이 더욱 두드러지게 나타납니다. 초기 스타트업의 경우에는 제품이 적절한 시장을 찾아 급성장할 수 있는 국면에 진입할 정도만 제품의 신뢰성이 있어도 충분하기 때문입니다.

#현대 인터넷 스타트업이 급성장하면 무슨 일이 벌어지는가? (What happens when a modern Internet startup undergoes hyper-growth?)

대부분의 스타트업은 실패합니다. 그게 현실입니다. 초기 스타트업이 Google을 상상하며 인프라를 만들어나간다면, 그건 시간 낭비일 뿐입니다. 제가 사람들에게 늘 말하는 건, 인적 확장 문제(의사 소통, 계획 산정, 강한 의존성 등)로 인해 보다 의존성이 적은 아키텍처로 전환하기 전까진, 다른 걱정은 하지 말고 그냥 현재의 monolithic 아키텍처를 유지하라는 것입니다.

그러면 현대의 (위에서 말한 세 번째 단계의) 스타트업이 성공을 거두며 급성장 시기를 맞이하면, 어떻게 될까요? 몇 가지 흥미로운 일들이 동시에 일어나기 시작합니다.

인력 증가 속도가 빠르게 늘어나며, 커뮤니케이션과 엔지니어링 효율에 심각한 부담이 오기 시작합니다. 이 주제에 대해서는 맨먼스 미신(The Mythical Man-Month) 을 꼭 읽어보길 권합니다. (거의 50여년 전 책인데도 여전히 아주 좋은 책입니다.)
위 내용으로 인해 거의 대부분 monolithic 아키텍처에서 microservice 아키텍처로 전환하며, 개발 팀들을 분리하고 커뮤니케이션 및 엔지니어링 효율을 높이려고 합니다.
Monolithic 아키텍처에서 microservice 아키텍처로의 전환은 시스템 인프라 복잡성을 몇 배나 증가시킵니다. 네트워킹, 시스템 가시성, 배포, 라이브러리 관리, 보안 등 이전에는 그리 어렵지 않았던 수백가지 문제가 불거지고, 해결해야 할 주요 문제가 됩니다.
동시에, 급성장으로 인해 트래픽이 증가하고 그로 인한 기술적인 확장 문제를 겪게 되며, 완전한 실패(complete failure)와 작은 사용자 경험 문제들이 생기기 시작, 점점 큰 사용자 영향이 나타납니다.

#중앙 인프라 팀 (Central infrastructure teams)

이런 초기 스타트업 단계에서, 거의 대부분 현대 인터넷 급성장 회사(modern Internet hyper-growth companies)들은 엔지니어링 조직들을 비슷하게 만들기 시작합니다. 공통적으로 나타나는 구조는 중앙 인프라 팀을 만들어, DevOps랑 비슷한 일을 하고 있는 다양한 제품 팀을 지원하는 구조입니다. 각 팀은 DevOps라고 불리지 않을 수도 있습니다.

중앙 인프라 팀이 보편적으로 생기는 이유는, 위에서 이야기했듯 급성장이 사람과 기술 양 측면에서 여러 변화를 야기하는데, 모든 제품 엔지니어링 팀이 각각 개별적으로 네트워킹, observability, 배포, 프로비저닝, 캐싱, 데이터 저장 등의 문제를 풀고자 최신의 클라우드 네이티브 기술들을 사용하긴 너무 어렵기 때문입니다. 전체 엔지니어링 조직이 거의 비즈니스 로직에만 집중하여, 아주 신뢰할 수 있는, 대규모의, 실시간 인터넷 어플리케이션을 만들도록 탄탄하게 지원하는 그런 “서버리스” 기술은 아직 수십년은 멀었습니다.

그리하여, 클라우드 네이티브 인프라 기반기술들이 제공해주는 것 너머의 이런 대규모 엔지니어링 조직들이 갖고 있는 문제들을 해결하기 위해 중앙 인프라 팀이 탄생했습니다. 분명 Google의 인프라 팀은 Lyft같은 회사보다는 몇 배는 더 큽니다. Google은 데이터 센터 수준에서의 근본적인 문제들을 해결하는 반면, Lyft는 공개적으로 사용할 수 있는 많은 기반기술들에 의존하고 있기 때문입니다. 그러나, 두 회사 모두 중앙 인프라 조직을 만드는 근본적인 이유는 동일합니다. 바로 어플리케이션/제품 개발자가 비즈니스 로직에 집중할 수 있도록 가능한 많은 인프라들을 추상화하기 위함입니다.

#대체 가능성에 대한 착오 (The fallacy of fungibility)

마지막으로 “대체 가능성(Fungibility)", 조직의 엔지니어 숫자가 어느 수준 이상으로 커지며 단일(pure) DevOps 모델의 실패로 이어지게 되는 핵심에 대해 이야기해보려 합니다. (역자 주: 단일 DevOps 모델이라는 번역이 적절한가 고민했는데, 뒤에서 제안하는 개발팀을 포함하는 복합적인 DevOps 모델과 대비되는 단어로 선택했습니다) 대체 가능성은 모든 엔지니어가 똑같이 태어나 모든 것들을 다 할 수 있다는 개념입니다. (적어도 Amazon이나 다른 회사들처럼) 채용 대상을 아주 분명하게 적어뒀든, 아니면 “부트캠프" 같이 엔지니어를 어떤 팀이나 역할에 염두하지 않고 뽑아 이후에 명확하게 검증해보든, 대체 가능성은 지난 10년-15년간 많은 회사들에서 현대 엔지니어링 철학의 가장 인기 있는 요소입니다. 왜 그럴까요?

위에서 말했듯, 현대 클라우드 네이티브 기술 및 추상화는 기능이 아주 풍부한 어플리케이션들을 더 정교한 인프라 추상화로 구축할 수 있게끔 합니다. 그래서 자연스럽게, 대부분의 회사들에서는 데이터 센터 설계나 운영 같은 종류의 전문 기술은 더 이상 필요하지 않게 되었습니다.
지난 15년간, 업계는 소프트웨어 엔지니어링이 모든 분야의 근본이라는 생각에 집중해왔습니다. 예를 들어, Microsoft는 전통적인 QA 엔지니어들을 소프트웨어 테스트 엔지니어로 대체했습니다. 수동으로 진행하는 QA는 더 이상 효율적이지 않고 모든 테스트는 자동화되어야 한다고 생각했기 때문입니다. 마찬가지로, 기존의 운영 역할은 SRE(Site reliability engineering) 등으로 대체되었습니다. 수동으로 운영하는 건 더 이상 효율적이지 않으며, 확장할 수 있는 방법은 소프트웨어 자동화가 유일하다고 생각했기 때문입니다. 물론, 저도 이런 시대적 흐름에 동의합니다. 보다 더 효율적으로 확장하는 방법이, 바로 자동화입니다.

그러나, 많은 신생 스타트업들의 경우, 이런 아이디어를 극한까지 적용하여 제너럴리스트 소프트웨어 엔지니어들“만” 채용하는 결과로 이어지기도 했습니다. 이들이 개발, QA, 운영 모두 담당해줄 수 있다는 기대와 함께 말이지요.

대체 가능성과 제네럴리스트 채용은 초기 스타트업에서는 대체로 잘 맞는 개념입니다. 그러나, 어느 규모 이상으로 가면 모든 엔지니어가 대체 가능하다는 생각은 다음과 같은 이유로 거의 터무니없는 말이 됩니다.

제네럴리스트 vs 스페셜리스트 (Generalist vs Specialists)
- 더 복잡한 어플리케이션과 아키텍처들은 프론트엔드, 인프라, 클라이언트, 운영, 테스팅, 데이터 사이언스 등 다양한 분야에서 더 전문화된 기술들을 필요로 합니다. 이건 제네럴리스트가 더 이상 유용하지 않거나 제너럴리스트가 전문가가 될 수 없다는 말이 아니라, 단지 더 큰 엔지니어링 조직이 성공하기 위해선 다양한 유형의 엔지니어들을 필요로 한다는 걸 말합니다.
어떤 엔지니어도 모든 일을 다 하는 것을 좋아하지 않는다 (All engineers do not like doing all things)
- 어떤 엔지니어들은 제네럴리스트가 되길 원합니다. 어떤 엔지니어는 스페셜리스트가 되길 원합니다. 누구는 코드를 작성하는 걸 좋아하고, 누구는 디버깅을 하는 걸 좋아합니다. 누구는 UI를 좋아하고, 누구는 시스템을 좋아합니다. 스페셜리스트를 지원하는 엔지니어링 조직이라면, 구성원의 행복이 때로는 특정 종류의 문제와는 연관되고 다른 종류의 문제와는 연관되지 않는다는 사실을 극복하려고 노력해야 합니다.
어떤 엔지니어도 모든 일을 잘 하지는 못한다 (All engineers are not good at doing all things)
- 제 커리어 동안 저는 정말 대단한 사람들을 만났습니다. 그 중 일부는 IDE의 빈 파일에서부터 시작해서 놀라운 시스템을 만들어내기도 합니다. 그렇지만 동시에, 그 똑같은 사람들은 신뢰할 수 있는 시스템을 만드는 방법이나 시스템을 디버깅하는 방법, 모니터링하는 방법은 잘 모릅니다. 반대로, 아주 뛰어난 운영 엔지니어로 디버깅에 대한 전문 지식을 가지며 신뢰 가능한 시스템을 어떻게 운영할 수 있는지 선천적인 직관으로 알아 조직 전체에 어마어마한 이점을 줄 수 있는 사람이, 단지 “충분한 코딩 기술"을 보여주지 못했다는 이유로 인터뷰에서 거절당하는 것을 보는 격분할 만한 인터뷰도 많이 겪었습니다.

아이러니하고 위선적이게도, Amazon이나 Facebook같은 조직들은 소프트웨어 엔지니어링 역할의 대체 가능성을 우선시하지만, 개발과 운영 간에 각각 서로 다른 커리어 패스를 제공하며 둘의 나눠진(그렇지만 일부는 겹치는) 스킬셋을 더 중요시합니다.

#붕괴 (The breakdown)

단일 DevOps 모델은 어느정도의 조직 규모에서 어떻게 무너질까요? 무엇이 잘못되었을까요?

Move to microservices. 엔지니어링 조직이 75명쯤 되면, 중앙 인프라 팀이 거의 무조건 존재하여, microservice를 만드는 각 제품팀을 지원하기 위한 공통 기반을 만듭니다.
Pure DevOps. 동시에, 제품 팀이 DevOps를 하라는 이야기를 듣습니다.
Reliability consultants. 이런 조직 규모에선 인프라 작업에 관심을 갖는 엔지니어는 이전에 운영 경험을 가진 엔지니어거나 해당 분야에서 뛰어난 직관을 가진 엔지니어일 가능성이 높습니다. 필연적으로 이러한 엔지니어는 사실상의 SRE/프로덕션 엔지니어가 되어, 조직의 나머지 부분을 지원하는 동시에 비즈니스 운영에 필요한 인프라를 지속적으로 구축해나갑니다.
Lack of education. 이제 우리는 스스로가 직접 개입해서 인터넷 서비스를 개발하고 운영할 수 있는 사람을 고용하길 기대합니다. 그러나, 새로운 채용과 저런 일을 수행하기 위한 지속적인 교육을 같이 하는 걸 우린 보통 너무나도 못합니다. 우리가 그런 기술들을 가르치지 않는데 운영에 대한 직관을 엔지니어들이 가지길 기대할 수 있을까요?
Support breakdown. 엔지니어링 조직이 점점 많은 사람을 고용하며, 중앙 인프라 팀이 더 이상 비즈니스 성공에 중요한 인프라를 구축 및 운영하기 버거워지는 지점이 옵니다. 그러나 각 제품 팀의 운영 업무를 지원해야하는 부담은 여전히 유지됩니다. 중앙 인프라 조직은 기존 워크로드에 더해 조직 전체의 SRE 컨설턴트로서의 이중 역할을 수행하기 시작합니다. 교육 및 문서화 작업이 중요하다는 것은 누구나 알고 있지만, 이 두 가지 작업을 위해 그런 시간을 내는 걸 우선시하는 일은 잘 일어나지 않습니다.
Burnout. 더 문제인 건, 앞서 설명한 상황들이 인적 희생을 유발하며 조직 전체의 사기를 떨어뜨리는 일을 만든다는 것입니다. 제품 엔지니어는 자신들이 하기 싫거나 배우지 않은 일들을 하도록 요구받는다고 느낍니다. 인프라 엔지니어는 회사 전반의 기존 시스템을 높은 신뢰성을 가지고 유지하는 동시에, 교육과 문서화가 필요하다는 것은 인지하지만 이걸 진행하는 걸 우선시하긴 어렵다는 걸 알며 지원 업무의 무게로 점점 번아웃되기 시작합니다.

엔지니어링 조직의 규모가 일정 수준이 되면 중앙 인프라팀이 단일 DevOps 모델을 진행하며 조직에서 인적 확장 문제를 겪기 시작하고, 이런 문제들을 기점으로 상황이 급격히 나빠집니다. 이 크기는 퍼블릭 클라우드 기반 기술들이 얼마나 성숙한가에 따라 달라지며, 저는 이 글을 쓰는 현재 시점(역자 주: 2018년입니다)에선 전체 엔지니어가 100~200명(low hundreds)인 수준이라고 생각합니다.

#“오래된 방식”과 DevOps 방식의 중간지점? (Is there a middle ground between the “old way” and the DevOps way?)

약 10년 이상 된 회사의 경우, 사이트 신뢰성(site reliability)이나 제품 엔지니어링 모델은 흔해집니다. 구현 형태는 회사마다 다르지만, 공통적으로 추구하는 바는 제품 관리자에게 매이지 않고 온전히 신뢰성 엔지니어링에 집중할 수 있는 엔지니어를 고용하자는 것입니다. 구현 형태의 디테일도 연관성이 꽤 있는데, 이를테면 이런 부분들입니다.

SRE만 장애 대기를 함께 하는가, 아니면 소프트웨어 엔지니어도 장애 대기를 함께 하는가?
SRE는 실제 엔지니어링 및 자동화를 하고 있는가, 아니면 배포/반복되는 장애 해소 등 수동으로 진행되고 반복적인 작업들을 수행하는가?
SRE는 중앙 컨설팅 조직의 일부인가, 아니면 제품 팀에 포함되어 있는가?

보통 위의 질문들에 대한 대답에 따라, 프로그램의 성공과 그 성공이 전체 엔지니어링 조직에 미치는 영향은 달라집니다. 하지만, 저는 특정 규모 이상에선 SRE 모델만이 단일 DevOps 모델이 망가지는 시점을 넘어 엔지니어링 조직의 규모를 훨씬 크게 확장할 수 있는 유일한 방법이라고 믿습니다. 보다 솔직하게는, 여기에서 설명한 인적 확장의 한계 시점 이전에 SRE 모델을 성공적으로 도입하는 것이 현대 급성장 인터넷 회사들의 엔지니어링 조직 리더십이 가져야할 아주 중요한 책임이라고 생각합니다.

#올바른 SRE 모델이란 무엇인가? (What is the right SRE model?)

현재 업계에서 구현된 수많은 사례들을 볼 때, 이 질문에 대한 정답은 없으며, 모든 모델은 각각의 빈틈과 그로 인한 문제들이 있습니다. 제가 지난 10년간 관찰한 결과를 바탕으로, 제가 생각하는 SRE 모델의 핵심(sweet spot)을 간략히 설명해보면 다음과 같습니다.

운영 및 신뢰성 엔지니어링은 개별적이고 매우 가치있는 스킬셋이라는 걸 인지합니다. 모든 것을 자동화하려는 시도와 소프트웨어 엔지니어가 대체 가능하다는 생각은, 소프트웨어 엔지니어와 동등한 (어쩌면 더 나은) 가치가 있는 엔지니어링 인력 일부를 소외되게 만듭니다. 소프트웨어 엔지니어가 스트레스가 심한 장애 상황에서 디버깅하고 불을 끄는 일에 편안함을 느껴야할 필요는 없는 것처럼, 똑같이 운영 엔지니어는 빈 소스파일에 편안함을 느끼지 않아도 됩니다. 운영 엔지니어와 소프트웨어 엔지니어는 서로 대체할 수 있는 톱니바퀴같은 존재가 아니라, 파트너입니다.
SRE는 장애 대기하고, 대시보드를 만들고, 배포를 하는 원숭이가 아닙니다. 이들은 제품 업무가 아닌 신뢰성 업무에 집중하는 소프트웨어 엔지니어들입니다. 이상적인 구조는 모든 엔지니어가 장애 대응, 배포, 모니터링 등의 기본적인 운영 업무를 수행하는 것입니다. 이건 아주 중요한 이야기로, 신뢰성 엔지니어와 소프트웨어 엔지니어 간의 직업 계층화를 방지하고, 소프트웨어 엔지니어가 제품 품질에 대해 보다 직접적으로 책임을 지게 만들기 때문입니다.
SRE들은 구조적으로는 제품 팀에 속하나, 제품 팀의 엔지니어링 매니저에게 보고하진 않아야 합니다. 이를 통해 SRE는 자신이 속한 팀에서 스크럼을 하고, 상호 신뢰를 얻으며, 상호 적절한 견제와 균형을 유지하며 신뢰성과 기능 사이를 저울질할 수 있는 진짜 대화를 이뤄나갈 수 있습니다.
각 제품 팀에 포함된 SRE의 목표는 각 제품의 신뢰성을 올리는 것입니다. 이는 신뢰성을 중시하는 기능 및 자동화, 운영 모범 사례에 대해 다른 팀을 멘토링하고 교육하는 것, 제품 팀과 인프라 팀 간의 소통(문서에 대한 피드백, Pain points, 필요 기능 등) 등을 통해 달성할 수 있습니다.

위에서 설명한 성장 시기의 초기에 SRE 모델을 성공적으로 구현하면, 신규 채용에 대한 투자와 지속적인 교육 및 문서화를 바탕으로 조직 전체의 엔지니어링 기준을 높이는 동시에, 앞서 설명한 많은 인적 확장 문제들을 완화할 수 있습니다.

#결론 (Conclusion)

이 글에 서술한 내용들을 바로 적용할 수 있는 급성장 회사들은 거의 없습니다. 상당수 기업들은 현대 클라우드 네이티브 기반기술에 기초한 단일 DevOps 모델로도 충분한 숫자의 엔지니어 수, 필요한 시스템 안정성, 비즈니스에서 요구하는 제품의 반복 속도를 만들 수도 있습니다.

이 글을 적용할 수 있는, 비교적 적은 숫자의 회사를 위해 이 글의 주요 내용을 요약해보면 다음과 같습니다.

경쟁하고자 하는 신기술 회사에는 DevOps 스타일의 애자일한 개발 및 자동화가 필요합니다.
소규모 중앙 인프라 팀이 퍼블릭 클라우드 네이티브 기반기술을 사용하면, 교육 부족 및 역할 특수성 부족으로 인한 운영 문제가 발생하기 전까지 엔지니어링 조직을 수백명 수준으로 확장할 수 있습니다.
운영 인력 확장 문제를 위해서는 신규 채용 및 지속적 교육, 문서화, 제품 팀과 인프라 팀 사이의 가교 역할을 할 수 있을만한 제품 팀 내의 SRE팀 만들기 등의 실질적인 투자가 필요합니다.

현대의 급성장 인터넷 회사들은 (제 생각엔) 말도 안되게 많은 숫자의 번아웃을 겪고 있는데, 이는 주로 가혹할 정도의 제품 요구사항과 운영 인프라에 대한 부족한 투자 때문입니다. 이 문제가 더 커져서 조직 안정성에 큰 걸림돌이 되기 전에, 저는 엔지니어링 리더십들이 이 문제를 선제적으로 개선할 수 있을 것이라고 믿습니다.

신생 기업들은 클라우드 네이티브 자동화의 발전으로 인해 기존의 전통적인 운영 엔지니어가 필요 없어졌다고 착각할 수도 있는데, 이는 사실과 아주 다릅니다. 분명 미래에 가장 최신 기술들을 쓰고 있다 하더라도, 운영 및 신뢰성을 전문으로 하는 엔지니어는 다른 방법으로는 얻을 수 없는 아주 중요한 스킬셋들을 갖고 있다고 인식되고 평가받아야 합니다. 그리고 그들의 이런 중요한 역할은 성장 시기 초기의 엔지니어링 조직에 제대로 구성되어야 할 것입니다.

다시 본 글의 옮긴이, 원대영입니다. 데브옵스라는 업무 형태나 일하는 방식은 역사가 수 년밖에 되지 않은 분야라 '어떻게 더 잘 일할 수 있는지'에 대해선 전 세계 수많은 조직이 공통적으로 고민하는 문제라고 생각합니다. 지금 번역한 이 글에서 다루고 있는 문제 또한 저희 데브시스터즈 내부에서도 수 년간 진화를 거듭하며 배운 것과 굉장히 유사하다고 느꼈습니다. 이런 사례가 계속 공유되고 다함께 더 좋은 방법을 찾다보면 데브옵스라는 직무의 일하는 방식이 점차 잡혀갈 것이라 생각합니다.

더불어 저를 비롯한 데브시스터즈의 여러 데브옵스 엔지니어들이 이 글을 기반으로 많은 생각과 의견을 나눠봤습니다. 그 부분에 대해서는 별도의 글로 찾아오도록 하겠습니다. 다음 글을 기대해주세요!

데브시스터즈 서버 직군은 왜 코딩 면접을 볼까?

Fri, 10 Jun 2022 00:00:00 GMT

안녕하세요. [쿠키런: 오븐브레이크]의 서버 개발자 황재영입니다.

시간이 흐르면서 참 많은 것들이 바래는데요. 저희가 코딩 면접에 사용했던 문제들 또한 마찬가지였습니다. 코딩 면접 문제를 변경하려고 살펴보다 보니, 왜 우리는 코딩 면접을 진행하는 것인가? 라는 근본적인 질문에 대해 생각하게 되었습니다. 이를 위해 코딩 면접을 왜 진행하는지, 그 과정을 통해서 데브시스터즈는 지원자의 어떤 점을 알고 싶은 것인지에 대해 고민하고 논의하였습니다. 논의 이후 곰곰이 생각해보니, 위 질문에 대한 답은 데브시스터즈의 면접관뿐만 아니라, 데브시스터즈의 지원자에게도 유용한 정보가 될 것이라고 생각하였습니다.

본론에 들어가기에 앞서, 이 글은 데브시스터즈 서버 직군의 논의를 통해 작성되었음을 말씀드립니다. 서버 직군이 아닌 다른 개발 직군에서는 다른 면접 절차와 기조를 가지고 있을 수 있으며, 서버 직군 면접 중에서도 진행하는 포지션에 따라 코딩면접이 생략되는 등, 포지션과 지원자에 따라 다르게 적용될 수 있습니다. 이 글은 그러한 면접 지원자분들이, 특히 신입 서버 개발자 포지션으로 지원하시는 분들께서 이 글을 읽고 자신의 강점을 더 잘 어필하고 코딩 면접을 잘 진행할 수 있게 도움을 드리기 위해 작성하게 되었습니다

#데브시스터즈 서버 직군의 면접 절차

데브시스터즈 서버 직군의 면접 절차는 일반적으로 아래와 같습니다.

온라인 코딩 테스트 이후 총 3개의 면접 과정이 있습니다

1차 기술 면접에서는 지원자의 기술적인 역량을 확인합니다. 먼저 구술 면접으로 지원자에게 다양한 질문을 드리며, 각각의 기술에 대해 어떤 지식과 관점을 가지고 계신지 확인합니다. 구술 면접이 종료된 후에는 잠시 쉬는 시간을 가진 이후, 주어진 시간 동안 지원자가 문제를 푸는 코딩 면접 시간을 가집니다.

#데브시스터즈 서버 직군이 코딩 면접을 통해 알고 싶은 것

데브시스터즈 서버 직군의 코딩 면접은 언어나 라이브러리, 프레임워크 사용에 제한이 없고 웹 검색도 자유롭게 허용합니다. 지원자의 역량을 최대로 펼칠 수 있는 환경에서 진행하는 것이 능력을 더 잘 확인할 수 있다고 생각하기 때문입니다. 그런 환경 속에서 저희가 코딩 면접을 통해 알고 싶은 것은 다음과 같습니다.

먼저 문제를 정의하고 풀어가는 과정입니다. 저희는 완벽한 결과물보다 문제를 풀어나가는 과정에 집중합니다. 문제 풀이 과정의 생각의 흐름과 작성했던 코드를 통해, 지원자에 대해 더 깊게 알 수 있다고 생각하기 때문입니다. 그래서 정답이 정해져 있는 문제가 아닌 사람에 따라 다양하게 생각하고 고민해볼 수 있는 문제들을 사용합니다. 또한 지원자가 문제를 푸는 과정은 면접관들에게 화면 공유되어 전달됩니다. 이렇게 면접관은 지원자가 어떤 고민을 거쳐 해답에 도달하는지를 확인합니다. 이 일련의 과정은 간단하지 않지만, 정답만을 확인하는 것이 아닌 문제 해결에 대한 고민과 난관을 해결하는 모습을 알고자 노력하고 있습니다.

다음은 코드를 이해하고 개선해나가는 과정입니다. 데브시스터즈에서는 코딩 면접 결과물을 제출한 이후, 면접관과 이야기하는 시간을 가집니다. 이 시간 동안 지원자는 작성한 코드에 관해서 설명하고 개선할 수 있는 점 또는 코드의 한계 등에 대해서 자유롭게 이야기 할 수 있습니다. 단순히 지금의 문제만 해결하는 코드가 아니라 코드를 작성하고, 소통하고, 정확히 이해하고 유지 보수하는 것 또한 개발자의 중요한 역량이라고 생각합니다. 그렇기에 이러한 과정에서 지원자가 하는 말과 생각은 단순한 구술 면접에서는 볼 수 없고 코딩 면접에서만 볼 수 있는 중요한 요소입니다. 다만 이 시간은 면접 과정 중 시간이 부족하다거나 코드의 퀄리티가 뛰어나면 생략하는 때도 있으니 면접 과정 중 오해하지 않아 주셨으면 합니다.

위 내용이 글 만으로는 잘 와닿지 않을 수 있을 것 같아 다음으로는 과거에 실제로 사용했던 문제들을 예시로 함께 살펴보겠습니다.

#데브시스터즈 서버 직군의 코딩 면접 문제

#문제1. 멀티 스레드 그랩

용감한 쿠키는 평소 사용하는 파일 내 문자열 검색 툴 grep보다 더 빠른 속도를 자랑하는 ack나 ag같은 다양한 툴들이 있다는 것을 들었다.
자신만의 dgrep을 만들어 널리 세상을 이롭게 하고 싶다고 생각하게 된 용감한 쿠키는 그 첫 단계로 멀티스레드로 동작하는 grep을 직접 만들어보기로 결심하였다.
원하는 스펙에 맞는 파일 내 문자열 검색 툴을 만들어보자.

입력 형식
 - dgrep {keyword} {relative path}

출력 형식
 - 파일의 각 line에 keyword가 있는 경우, 해당 파일과 줄 번호를 출력한다.

조건
1. relative path가 디렉토리인 경우 디렉토리 내 모든 파일에 대해 검사를 진행한다.
2. relative path 내에 또 다른 디렉토리가 존재하는 경우, 각 디렉토리 내 모든 파일에 대한 검사 또한 진행한다.
3. 멀티 스레드를 이용하여 최대한 빠르게 작업을 완료하도록 작성한다.
4. 동일한 파일에 대한 검사 결과는 한 번에 출력되어야 한다.
5. Directory 내 symlink는 없다고 가정한다.
6. 파일들은 모두 UTF8 인코딩으로 작성된 Text파일이라고 가정한다.

이 문제의 핵심 풀이 요소는 멀티 스레드를 이용하여 여러 개의 파일을 동시에 처리하는 것입니다.

이 문제를 통해 데브시스터즈에서 보고 싶은 핵심 요소는 멀티 스레드라는 하나의 기술에 대해 이해하고 응용할 수 있는지 였습니다. 단순히 기술을 사용하여서 문제를 푸는 것이 아닌, 기술을 활용할 때의 장단점 및 유의해야 할 부분에 대해 이해하는지를 보고 싶었습니다. 특히 동시성 프로그래밍은 실제 대규모 서비스에서도 효율적인 처리를 위해 사용되는 중요한 기술 중 하나입니다. 그러나 멀티 스레드 프로그램은 단일 스레드 프로그램에 비해 예측하기 어려운 문제가 발생할 가능성이 높아 세심한 설계가 요구되고, 디버깅에도 깊은 통찰력이 필요합니다. 저희는 지원자에게 이러한 요소를 이해하고 대처하는 모습을 기대하였습니다.

정리하자면, 이 문제에 대해서 기대하는 건 완벽한 멀티 스레드 그랩을 구현하는 것이 아닙니다. 일단 단순한 그랩을 구현하는 것으로 시작하고, 구현한 그랩의 동작을 확인했다면 그다음 멀티 스레드를 적용하는 풀이 과정에 대해 살펴보고 싶었습니다. 정확한 멀티 스레드를 구현하는 것보다, 멀티 스레드를 어떻게 설계하고 발생할 수 있는 문제에 대해서 어떻게 생각하고 해결하는지를 보고 싶었던 문제였습니다.

#문제2. 환상의 쿠키쇼

영화 ‘위대한 쇼맨’을 보고 크게 감동을 받은 치즈볼 새는, 쿠키들과 함께 공연을 준비하기로 마음을 먹었다.
매일매일 고된 연습을 강행한 끝에, 공연의 내용은 전부 완성되었고 세계 각국의 전문가들 앞에서 쇼케이스를 펼치게 된다.
결과는 대성공! 치즈볼 새는 자신의 동전 주머니가 가득찰 생각을 하며 행복감에 젖었다.

 이윽고 치즈볼 새는 사람들에게 온라인으로 티켓을 팔기 시작했는데,
 예매 사이트를 이용하다보니 수수료를 떼이는 것이 불만인 치즈볼 새는 당신에게 예매 API 서버를 만들어달라고 의뢰를 했다.
 치즈볼 새의 돈주머니가 가득찰 수 있게 도와주도록 하자.

공연을 만들고 고객이 예매를 하기까지의 흐름은 다음과 같다.

1. 공연을 서버에 등록한다.
2. 예매 시작 시간이 되면 사람들은 빈 좌석 목록을 보고,
3. 원하는 자리를 ‘찜'한다. 다른 사람이 예매했거나 찜한 자리는 찜할 수 없다.
4. 찜한 자리에 대해서 정해진 시간 내에 결제정보를 마저 등록하여 예매를 완료한다.

이 문제의 핵심 풀이 요소는 API 서버의 구현입니다. 임의의 서버 프레임워크를 통해서 API를 구현하고 비즈니스 로직을 구현해야 합니다.

이 문제를 푸는 과정에서 저희가 관찰하고자 하는 역량은 풀어야 할 요소를 정의하고 설계하는 부분입니다. 실제 서비스 개발에서는 입력과 출력이 정해져 있는 경우가 많지 않습니다. 대부분의 경우에는 이 문제처럼 해결해야 하는 상황만 존재합니다. 이러한 상황에서 명확하게 어떤 요구사항이 있는지를 구체적으로 정의하고, 이를 구현하기 위해 어떤 값들을 사용할지 설계하는 점이 실무와 비슷한 요소가 많은 문제입니다. 실무와 비슷한 문제인 만큼, 동시에 많은 요청이 들어오고 서버가 여러 대일 때도 문제없이 작동하는 등의 구조적인 설계도 고려해볼 수 있었습니다. 그러한 문제 상황을 정의하고 설계하여서 서버를 만드는 모습을 지원자에게 기대하였습니다.

이 문제 또한 완벽한 API 서버를 구현하는 것이 아닌, 서버를 설계하는 과정을 살펴보고 싶었습니다. 공연이나 좌석 등의 데이터를 어떤 형태로 저장하는지, 동시적인 요청으로 발생할 수 있는 문제들을 예측하고 어떻게 방어하는지의 과정을 확인하고자 하였습니다

#글을 마무리하며

데브시스터즈 면접에선 지원자의 완벽한 모습이 아닌, 지원자가 품은 수많은 가능성을 보는 것을 기대합니다 이 글이 지원자에게 와닿는 글이 되고, 코딩 면접에서 지원자의 역량을 최대한으로 확인할 수 있는 기회로 뻗어나갔으면 좋겠습니다. 긴 글 읽어주셔서 감사합니다.