오픈소스 기여의 흐름을 따라가며 LitmusChaos를 배워보다

Intro

이번 글에서는 2026 오픈소스 컨튜리뷰션 아카데미 Git 활용 및 LitmusChaos를 진행하면서 배운 내용을 정리해보려고 한다.

 

프로그램은 약 6주 동안 진행되었고,

Git 활용, 오픈소스 기여 흐름, Go 언어, Kubernetes, LitmusChaos를 단계적으로 학습하는 방식이었다.

 

처음에는 LitmusChaos라는 도구 자체가 낯설었다.

 

카오스 엔지니어링이라는 개념도 이름만 들어봤지,

실제로 Kubernetes 환경에서 장애를 주입하고 결과를 확인하는 흐름은 경험해본 적이 거의 없었다.

 

이번 프로그램을 통해 단순히 새로운 기술을 하나 사용해본 것이 아니라,

오픈소스 프로젝트에 참여하기 위해 어떤 준비가 필요한지,

그리고 장애를 다루는 도구를 어떻게 실습 환경에서 이해할 수 있는지 살펴볼 수 있었다.

 

 

참여 배경

개발을 공부하면서 GitHub에 코드를 올리는 일은 자주 해봤지만,

실제 오픈소스 프로젝트에 기여하는 일은 조금 다르게 느껴졌다.

 

개인 저장소에서 코드를 작성하는 것과 달리,

오픈소스에서는 이미 존재하는 프로젝트의 규칙을 이해해야 한다.

 

Issue를 확인하고,

Contribution Guide를 읽고,

DCO 같은 기여 규칙을 지키고,

Pull Request를 만들고,

리뷰 과정에서 피드백을 반영해야 한다.

 

코드를 작성하는 능력만으로는 부족하고,

프로젝트의 흐름을 읽고 커뮤니티와 소통하는 과정까지 함께 필요하다.

이번 프로그램은 이 과정을 단계적으로 경험해볼 수 있는 좋은 기회였다.

 

 

전체 활동 흐름

프로그램은 큰 흐름으로 보면 아래와 같이 진행되었다.

오픈소스 기여 흐름 이해
    -> Go 언어 기초 실습
        -> Kubernetes 기본 리소스 실습
            -> LitmusChaos 설치 및 카오스 실험
                -> 실제 기여 가능 이슈 검토

 

처음부터 바로 LitmusChaos에 기여하는 방식은 아니었다.

 

먼저 오픈소스 협업 방식과 GitHub 기반 기여 절차를 익히고,

LitmusChaos를 이해하는 데 필요한 Go와 Kubernetes 기본기를 실습했다.

 

그 후 ChaosCenter를 설치하고,

샘플 애플리케이션을 대상으로 카오스 실험을 실행해보는 방식으로 이어졌다.

 

이 흐름이 좋았던 이유는,

도구를 단순히 실행하는 것에서 끝나지 않고,

왜 이런 도구가 필요한지 자연스럽게 이해할 수 있었기 때문이다.

 

 

오픈소스 기여 흐름 익히기

초반에는 GitHub 기반 오픈소스 기여 흐름을 중심으로 학습했다.

 

Issue를 어떻게 확인하는지,

Pull Request를 만들 때 어떤 내용을 작성해야 하는지,

Conflict가 발생하면 어떻게 해결하는지,

DCO는 왜 필요한지 등을 살펴보았다.

 

개인적으로는 이 부분이 생각보다 중요하게 느껴졌다.

 

오픈소스 기여는 단순히 코드를 잘 작성해서 제출하는 일이 아니라,

프로젝트가 유지되는 방식을 존중하면서 변경 사항을 제안하는 일에 가깝다.

 

업무에서 다른 팀의 코드를 수정할 때도 바로 고치는 것이 아니라,

왜 수정이 필요한지 설명하고,

기존 규칙에 맞게 변경하고,

리뷰를 통해 합의하는 과정이 필요하다.

 

오픈소스 기여도 이와 비슷하게 느껴졌다.

 

다만 그 과정이 더 공개적이고,

더 명확한 기록 위에서 진행된다는 차이가 있었다.

 

 

Go 언어와 HTTP CRUD API 실습

프로그램 중간에는 Go 언어 기초를 실습했다.

 

LitmusChaos 프로젝트가 Go 기반의 구성 요소를 많이 가지고 있기 때문에,

프로젝트를 이해하려면 Go 문법에 대한 기본 감각이 필요했다.

 

실습은 `Hello, Go!` 출력부터 시작했다.

 

이후 변수와 타입,

조건문과 반복문,

함수와 에러 처리,

컬렉션,

구조체와 메서드까지 순서대로 다뤘다.

 

마지막에는 Go 표준 라이브러리만 사용해서 HTTP CRUD API를 구현했다.

 

Go를 깊게 사용해본 것은 아니지만,

이번 실습을 통해 Go가 비교적 단순한 문법으로 서버를 구성할 수 있다는 점을 느꼈다.

 

특히 에러를 값으로 다루는 방식이나,

구조체와 메서드를 통해 데이터를 표현하는 방식이 Java와는 다르게 느껴졌다.

 

아직 익숙하다고 말하기는 어렵지만,

오픈소스 코드를 읽기 위한 첫 발판은 만들 수 있었다.

 

 

Kubernetes 기본기 다시 보기

LitmusChaos는 Kubernetes 위에서 동작한다.

 

그래서 프로그램에서는 Kubernetes 기본 리소스도 함께 실습했다.

 

Pod, Deployment, ReplicaSet, Service, ClusterIP, NodePort, port-forward,

ConfigMap, Secret, Volume, Helm chart 설치와 업그레이드 등을 다뤘다.

 

가장 기억에 남는 부분은 Pod를 삭제했을 때 Deployment가 다시 Pod를 생성하는 과정이었다.

 

Kubernetes의 self-healing이라는 개념을 글로 읽을 때는 단순히 자동 복구 정도로 이해했는데,

직접 Pod를 삭제하고 상태가 다시 맞춰지는 과정을 보니 조금 더 명확하게 이해할 수 있었다.

 

Kubernetes는 현재 상태를 보고 명령을 한 번 실행하는 도구라기보다,

원하는 상태를 계속 유지하려는 시스템에 가깝다.

 

이 관점을 이해하고 나니 Deployment, ReplicaSet, Service 같은 리소스도 조금 더 자연스럽게 연결되었다.

 

 

LitmusChaos 실습

후반에는 LitmusChaos를 설치하고 실제 카오스 실험을 수행했다.

 

LitmusChaos는 Kubernetes 환경에서 장애 상황을 통제된 방식으로 만들어보고,

시스템이 예상대로 복구되는지 확인할 수 있게 도와주는 오픈소스 도구이다.

 

이번 실습에서는 ChaosCenter,

Chaos Infrastructure,

ChaosHub,

Resilience Probe의 역할을 살펴보았다.

 

그리고 `podtato-head` 샘플 애플리케이션을 대상으로 `pod-delete`와 `pod-memory-hog` 실험을 실행했다.

 

`pod-delete`는 대상 Pod를 삭제해서 애플리케이션이 다시 복구되는지 확인하는 실험이고,

`pod-memory-hog`는 Pod에 메모리 부하를 주어 리소스 압박 상황에서 시스템이 어떻게 반응하는지 확인하는 실험이다.

 

처음에는 카오스 엔지니어링을 장애를 일부러 발생시키는 방식 정도로만 생각했다.

 

하지만 실습하면서 느낀 것은,

중요한 것은 장애 자체가 아니라 장애를 통해 검증하려는 가설이라는 점이다.

 

무작정 시스템을 흔드는 것이 아니라,

어떤 상황을 만들고,

그 상황에서 시스템이 어떻게 동작해야 하는지 예상하고,

실험 결과를 통해 그 예상이 맞는지 확인하는 과정이다.

 

장애 대응 훈련과 비슷하다고 볼 수 있다.

 

실제 장애가 발생한 뒤에야 대응 방식을 확인하는 것이 아니라,

안전한 환경에서 먼저 상황을 만들어보고 시스템의 회복력을 확인하는 것이다.

 

 

수동 장애 주입과 LitmusChaos의 차이

실습 중에는 수동으로 Pod를 삭제하는 방식과 LitmusChaos를 활용하는 방식의 차이도 비교해보았다.

 

수동으로 `kubectl delete pod`를 실행하면 장애 상황을 간단히 만들 수 있다.

 

하지만 이 방식은 실험 조건, 실행 시점, 결과 기록을 반복 가능하게 관리하기 어렵다.

 

반면 LitmusChaos는 실험을 선언적으로 구성하고,

실행 결과와 Resilience Score를 확인할 수 있다.

 

또한 Resilience Probe를 통해 실험 후 시스템 상태를 검증하는 흐름도 만들 수 있다.

 

즉, LitmusChaos는 단순히 장애를 발생시키는 도구라기보다,

장애 실험을 반복 가능한 형태로 관리하는 도구라고 이해했다.

 

이 차이를 이해한 것이 이번 실습에서 가장 중요한 지점 중 하나였다.

 

 

실제 기여로 이어질 이슈 검토

멘토링 후반에는 실제 LitmusChaos SDK 기여로 이어질 수 있는 이슈를 검토했다.

 

최종적으로 살펴본 이슈는 `#58 Add experiment run polling helper`이다.

 

이 이슈는 Litmus Java SDK에서 실험 실행 상태를 조회하는 흐름을 개선하는 작업이다.

 

현재는 `getExperimentRun()`을 통해 특정 실험 실행 상태를 한 번 조회할 수 있다.

 

하지만 애플리케이션 입장에서는 실험이 끝날 때까지 상태를 계속 확인해야 하는 경우가 있다.

 

이때마다 각 애플리케이션이 직접 polling loop를 만들고,

timeout을 처리하고,

완료, 실패, 중지, 에러 같은 terminal phase를 판단해야 한다.

 

이 로직이 반복된다면 SDK 수준에서 공통 helper로 제공하는 것이 더 자연스럽다.

 

그래서 `LitmusClient`에 아래와 같은 API를 추가하는 방향을 검토했다.

waitForExperimentRun(projectId, experimentRunId, timeout, interval)

 

 

이 helper는 설정한 `interval`마다 `getExperimentRun()`을 호출하고,

실험 실행 상태가 terminal phase에 도달하면 최종 `ExperimentRun` 응답을 반환한다.

 

반대로 `timeout`을 초과하면 명확한 예외를 발생시킨다.

 

아직 실제 구현을 완료한 것은 아니지만,

이 이슈를 검토하면서 SDK API를 설계할 때 고려해야 할 지점도 함께 생각해볼 수 있었다.

 

단순히 기능을 추가하는 것보다,

어떤 phase를 완료 상태로 볼 것인지,

timeout과 interval을 어떤 타입으로 받을 것인지,

실패 상태를 예외로 볼 것인지 결과로 반환할 것인지 등을 정리해야 한다.

 

이런 고민이 실제 오픈소스 기여에서는 중요하다고 느꼈다.

 

 

진행하면서 느낀 점

이번 프로그램을 진행하면서 가장 크게 느낀 점은,

오픈소스 기여는 결과보다 과정의 이해가 먼저라는 것이다.

 

Issue 하나를 선택하더라도 단순히 구현할 수 있는지만 보는 것이 아니라,

프로젝트의 현재 구조,

기존 API와의 관계,

문서화 방식,

테스트 작성 방식까지 함께 살펴봐야 한다.

 

또한 Kubernetes와 LitmusChaos를 실습하면서,

장애를 다루는 방식에 대한 관점도 조금 바뀌었다.

 

장애는 피해야 하는 대상이지만,

그렇다고 전혀 다루지 않고 넘어갈 수는 없다.

 

운영 환경에서 문제가 발생하기 전에,

제어 가능한 환경에서 먼저 실험하고 확인하는 과정이 필요하다.

 

그런 점에서 카오스 엔지니어링은 시스템을 망가뜨리는 실험이 아니라,

시스템에 대한 신뢰를 조금씩 검증하는 과정에 가깝다고 느꼈다.

 

앞으로 할 일

앞으로는 `#58 Add experiment run polling helper` 이슈를 기반으로 실제 기여를 진행할 계획이다.

 

먼저 기존 `getExperimentRun()` 동작과 `ExperimentRun` phase 구조를 더 자세히 분석해야 한다.

 

그 다음 `waitForExperimentRun()` API를 구현하고,

terminal phase에 도달했을 때 정상적으로 결과를 반환하는지 확인할 예정이다.

 

또한 timeout을 초과했을 때 어떤 예외를 발생시킬지,

`Duration` 기반으로 timeout과 interval을 받을 수 있을지,

완료, 실패, 중지, 에러 phase를 어떻게 문서화할지도 함께 정리해야 한다.

 

구현 후에는 JavaDoc과 unit test를 추가하고,

Pull Request를 생성해 리뷰를 받아볼 계획이다.

 

이번 프로그램에서 배운 내용을 실제 기여로 이어가야 비로소 흐름이 한 번 완성될 것 같다.

 

 

마무리

이번 글에서는 2026 오픈소스 컨튜리뷰션 아카데미 Git 활용 및 LitmusChaos를 진행하며 배운 내용을 정리해보았다.

 

처음에는 LitmusChaos라는 도구를 설치하고 실험을 실행해보는 것이 중심이라고 생각했다.

 

하지만 실제로는 오픈소스 프로젝트에 참여하는 방식,

Go와 Kubernetes 기본기,

카오스 엔지니어링의 목적,

그리고 SDK에 기여하기 위해 필요한 고민까지 함께 다루는 과정이었다.

 

특히 이번 활동을 통해 단순히 기술을 사용하는 것보다,

그 기술이 어떤 문제를 해결하기 위해 만들어졌는지 이해하는 것이 중요하다고 느꼈다.

 

LitmusChaos도 마찬가지였다.

 

장애를 발생시키는 도구로만 보면 조금 거칠게 느껴질 수 있지만,

실제로는 시스템이 장애 상황에서 어느 정도 회복력을 가지는지 검증하기 위한 도구이다.

 

앞으로 실제 기여를 진행하면서 SDK 구조와 테스트 작성 방식도 더 자세히 살펴보려고 한다.

 

이번 프로그램은 오픈소스 기여를 막연하게 바라보던 단계에서,

작은 이슈 하나를 기준으로 실제 기여 흐름을 생각해보는 단계로 넘어가는 계기가 되었다.

 

참고 자료 :

- https://github.com/litmuschaos/litmus-java-sdk/issues/58

Add experiment run polling helper · Issue #58 · litmuschaos/litmus-java-sdk

 

- https://dev-rowing.tistory.com/82

[Go] 왜 Go를 배워야 할까

 

- https://dev-rowing.tistory.com/83

Mac에서 LitmusChaos 설치하기

 

- https://dev-rowing.tistory.com/84

Go 기초부터 HTTP CRUD API까지

 

- https://dev-rowing.tistory.com/86

LitmusChaos로 카오스 실험하기