오픈 소스 기여 도전기 Ep.1

오픈소스 소프트웨어(OSS) 컨트리뷰트에 대한 관심이 생겼다. 이것저것 링크드인, 주변인들의 이야기를 듣다보니 관심이 생기는 게 당연할 건지도.?

 

기존의 방식이 코드를 한 줄 한 줄 뜯어보는 '바텀업(Bottom-up)' 식이었다면, 이제는 AI 에이전트를 활용해 프로젝트의 맥락을 먼저 파악하고 최적의 기여 지점을 타격하는 '탑다운(Top-down)' 방식이 주목받고 있다.

 

이번 포스팅에서는 Medium의 'OpenSource Contributors' 에서 제안된 AI 기반 분석 프레임워크를 활용하여, Apple의 공식 프로젝트인 apple/container를 분석하고, 기여할 이슈(Issue #962)를 선정하기까지의 치열한 의사결정 과정, 그리고 기여를 도전하는 과정에 대해 작성을 해볼 예정이다.

- 현재 PR이 올라가있는 상황인데, Merge가 된다면 바로 Ep.(완)를 작성하지 않을까.. 싶다.

---

apple/container?

기여할 프로젝트를 고를 때 가장 중요한 것은 '내 기술셋과 맞는가' 그리고 '기여가 유의미한가'다.

수많은 프로젝트 중 apple/container를 선택한 이유는 아래와 같다.

 

🍎  Swift로 짜인 컨테이너

apple/container는 macOS(특히 Apple Silicon) 환경에서 리눅스 컨테이너를 실행하기 위한 CLI 도구입니다. Docker Desktop이나 Podman과 비슷해 보이지만, 결정적인 차이점(Singularity)이 있다.

• 언어의 희소성 (Swift): 대부분의 컨테이너 런타임이 Go 언어로 작성된 것과 달리, 이 프로젝트는 핵심 로직이 Swift로 작성되어있다. 이전 iOS를 학습했던 저에겐 매우 좋은 기회라고 생각햇다.
• 초기 단계의 기회 (Blue Ocean): 아직 0.x.x 버전대의 프리릴리즈 단계다. 코드가 고착화되지 않았고, 아키텍처가 유동적이라 초기 기여자가 프로젝트 방향성에 큰 영향을 미칠 수 있다.
  • 즉, 이제 막 상장도기 직전..?의 느낌!

아키텍처를 보면, CLI(Swift)가 사용자의 입력을 받아 Virtualization.framework를 통해 경량 가상머신(VM)을 제어하는 구조다.

 

즉, 기존 iOS를 공부했었고 현재 Docker/k8s/Linux 등을 공부하던 저에겐 매우 좋은 기회라고 생각했다.

- 실제로 apple container에 star를 누르고 계속 언급하고 있었던..

---

AI를 활용한 Issue 선정

[2026.01 업데이트] AI 활용 오픈소스 기여 가이드

 

이전 교내 동아리 연사자로 오셨던 김인제 님의 기여 가이드를 보게 되었다.

 

사실 이를 통해 오픈소스 기여에 도전을 마음먹기로 했다. [접하는 난이도가 많이 이지해졌기 때문입니다.]

 

수백 개의 이슈를 눈으로 다 읽는 건 비효율적이다. 위 링크에서 나온 가이드대로 apple container Issue를 필터링하기 시작했다.

 

쉽게 요약을 해보면 아래와 같은 과정을 거친다.

1. 메타데이터 학습: CONTRIBUTING.md 등을 AI에게 주입해 프로젝트의 규칙을 먼저 이해시킨다.
2. 타겟 필터링: "Bug 라벨이 있고, 재현 가능하며, 초보자도 접근 가능한(Good First Issue 성격의) 이슈를 찾아줘."
3. 맥락 분석: AI에게 이슈 리포터의 의도를 해석하게 하고 해결 난이도를 점수화한다.

이 과정을 통해 커널 패닉이나 간헐적 버그 같은 '지뢰'를 피하고, 접근하기 쉬운 이슈를 찾을 수 있었다.

---

이슈 선정 

필터링 끝에 선정된 이슈는 바로 Issue #962: ": relative path in 'entrypoint' is not accepted" 다.

 

https://github.com/apple/container/issues/962

[Bug]: relative path in 'entrypoint' is not accepted · Issue #962 · apple/container

 

문제 상황 (The Problem)

사용자가 컨테이너를 실행할 때 entrypoint 옵션으로 상대 경로를 주면 에러가 발생한다.

# Docker에서는 잘 되는데...
$ container run --entrypoint ./rustc rust:latest --version
Error: internalError: "failed to find target executable./rustc"

 

왜 이 이슈인가? (Feasibility & Impact)

이 이슈가 선정한 이유는 아래와 같다.

1. 명확한 대조군 (Docker vs apple/container): Docker나 Podman에서는 ./rustc라고 입력하면 컨테이너 내부의 작업 디렉토리(Working Dir)를 기준으로 알아서 해석해준다. 하지만 apple/container는 이를 찾지 못해 에러를 뱉는다. 즉, 정상적으로 동작할 때의 상황이 명확하다.
2. 낮은 리스크, 높은 접근성: 이 문제는 커널이나 가상화 기술을 깊이있게 알지 않아도 된다. Swift로 짜인 CLI가 입력받은 문자열(string)을 파싱하는 과정에서 경로 정규화(Path Normalization)를 누락했기 때문일 가능성이 크다.
3. 사용자 경험(UX)의 완성: 개발자들은 습관적으로 스크립트에서 상대 경로를 쓴다. 이 기능을 지원하지 않으면 기존 Docker 사용자들이 apple/container로 넘어올 때 스크립트를 다 고쳐야 하는 불편함이 생긴다. 이 이슈 해결은 단순 버그 픽스를 넘어 OCI 호환성과 사용자 경험을 개선하는 중요한 작업이다.

이 세 가지를 AI와 함께 분석한 결과, Issue #962라는 최적의 기여 포인트를 찾아낼 수 있었다.

 

다음 포스팅에서는 실제 Swift 코드를 열어 이 문제를 어떻게 해결하고자 했는지, 또한 오픈소스 컨트리뷰트 과정에 대해 이야기를 해보고자 한다.