2026 OSSCA 발대식

Mini·2026년 7월 14일
OSSCAkubernetesopenstack

OpenSource

목록 보기
1/2
post-thumbnail

OSSCA

오픈소스 컨트리뷰션 아카데미(OSSCA)는 참여자를 멘토·멘티로 묶어 실제 오픈소스 프로젝트에 기여하는 경험을 쌓게 해주는 프로그램이다. 2026년에는 11개 팀이 참여형 프로젝트로 운영됐고, 나는 그중 OpenStack&Kubernetes 운영 문서화 및 국제화 팀에 멘티로 합류하게 됐다. (작년에 Pytorch프로젝트에 참여해 기여했었는데 좋은 기회가 다시...)

발대식 진행

이번 발대식은 2026년 7월 11일 서울 강남 한국과학기술회관 국제회의장에서 진행되었으며, 참여형 멘토와 멘티, 사무국 등 약 300명이 함께한 행사였다.
행사는 OSSCA 프로그램 소개와 운영 일정 안내로 시작되었으며, 이후에는 프로젝트별 팀 소개와 팀별 자율 미팅이 진행되었다.

타임테이블

시간내용
12:30 ~ 13:00출석체크 및 팀별 착석
13:00 ~ 13:05오프닝
13:05 ~ 13:10주관기관 환영사
13:10 ~ 13:40첫 번째 초청 강연 — 박수홍 삼성전자 오픈소스 그룹장
13:40 ~ 14:00오픈소스 컨트리뷰션 아카데미 소개 (프로그램·참여형 11팀 소개, 세부일정, 멘토·멘티 활동 의무사항 및 지원사항 안내)
14:00 ~ 14:30두 번째 초청 강연 — 정승록 AMD 수석 엔지니어
14:30 ~ 15:00단체 기념촬영
15:00 ~ 17:00팀별 발대식 진행 및 기념촬영

강연정리 : 오픈소스를 대하는 나

박수홍 삼성전자 오픈소스 그룹장 — 오픈소스는 생각보다 폐쇄적이다

가장 기억에 남는 메시지는 "오픈소스는 열려 있고 개방적이라고 생각하지만, 사실 생각보다 폐쇄적이다"라는 문장이었다. 기업 입장에서는 과거에 오픈소스를 부정적으로 바라보는 시선이 컸다고 한다. 내 코드와 기술을 외부에 공개한다는 것 자체가 리스크로 여겨졌기 때문이다. 그런데 시간이 지나면서 이 인식이 조금씩 바뀌었고, 지금은 오히려 오픈소스 참여가 기업 경쟁력의 핵심으로 여겨지는 흐름으로 왔다는 이야기였다.

다른 자리에서도 밝힌 적 있는 관점과 맞닿는 지점이 있었다. "오픈소스는 기업에서 보면 경쟁력의 핵심이고, 사업에서는 헤게모니를 위한 굉장히 중요한 전략"이라는 표현인데, 결국 기업이 오픈소스를 공개하는 이유가 순수한 선의가 아니라 각자의 사업 전략에 맞춰 계산된 선택이라는 뜻이다. 실제로 삼성전자는 SW의 70% 이상을 오픈소스로 활용하며 165개 프로젝트를 직접 공개하고 있고, ONAP 같은 프로젝트에서는 코드 기여 순위로 화웨이를 앞서기도 했는데, 이런 활동들도 결국 산업 표준을 주도하고 영향력을 확보하기 위한 전략적 포지셔닝의 성격이 크다고 생각한다.

발대식에서 나온 "오픈소스는 순결하지만은 않다"는 표현을 말씀하셨다. 오픈소스라고 해서 모든 게 순수한 선의와 이상으로만 돌아가는 게 아니라, 그 안에도 기업의 이해관계와 전략이 얽혀 있다는 것이다. 이 얘기를 들으면서 최근 몇 년간 업계에서 실제로 있었던 사례들이 떠올랐다. MongoDB(2018년), Elastic(2021년), Redis(2024년) 같은 오픈소스 데이터베이스 기업들이 잇따라 라이선스를 바꾼 일이 대표적이다. AWS 같은 대형 클라우드 벤더가 이들의 오픈소스 코드를 그대로 가져다 관리형 서비스로 팔면서도 코드 기여로는 거의 돌려주지 않자, 원저작 기업들이 코드 공개 자체를 제한하는 source-available 라이선스로 돌아선 것이다. 이 사례는 오픈소스가 늘 이상적인 협업 공동체로만 굴러가는 게 아니라, 누가 가치를 만들고 누가 그 가치를 가져가느냐를 둘러싼 현실적인 힘겨루기의 장이기도 하다는 걸 잘 보여준다.

정승록 AMD 수석 AI 소프트웨어 엔지니어 — GPU 성능 평가 현장에서 오픈소스를 대하는 법

정승록 엔지니어는 AMD에서 GPU performance evaluation(그래픽카드 성능 평가) 파트를 담당하고 있다고 소개했다. 실제로 benchmarking과 performance testing 업무를 주로 하신다고 했는데, AMD가 ROCm(Radeon Open Compute)이라는 오픈소스 GPU 컴퓨팅 스택을 공개하고 있고, 그 안에 rocHPL이나 hipBench 같은 벤치마킹 도구들도 오픈소스로 함께 제공한다는 걸 감안하면 실무와 맞닿아 있는 이야기로 느껴졌다.
강연에서는 AMD 자체 코드도 이미 오픈소스로 공개되어 있고, 이 외에도 해외 유수 기업들이 공개한 오픈소스 프로젝트가 정말 많다고 강조했다. 다만 기술적으로 핵심적인 코드 기여는 결국 그 프로젝트를 직접 만든 사람들이나 이미 이름이 알려진 기업들이 주도하는 경우가 많으니, 후배 개발자 입장에서는 그런 코드를 보면서 공부하고 직접 뜯어보면서 시야를 넓히는 게 중요하다고 조언했다. 여기에 AI를 적극적으로 잘 활용하라는 말도 덧붙였다. 강연 말미에는 본인이 요즘 재미있게 보고 있는 논문이나 분야를 언급하며, 관련된 오픈소스 프로젝트 몇 가지를 추천해주기도 했다.

저녁엔 오픈인프라 x 쿠버네티스 한국 사용자 모임 밋업도

같은 날 저녁에는 OSSCA 발대식과는 별개로 OpenInfra 한국 사용자 모임과 Kubernetes 한국 사용자 모임이 공동 주최하는 밋업이 있었다.

타임테이블

시간내용
17:30 ~ 18:00등록 및 네트워킹
18:00 ~ 18:20최영락님 — OpenStack & Kubernetes Localization Trend (OpenInfra x Ceph x KCD Korea 2026 소개, Localization 및 커뮤니티 활동 소개)
18:20 ~ 18:50조성수님 — OpenStack은 어떻게 번역되고 운영되는가? (OpenStack 번역 시스템과 커뮤니티, Weblate 기반 번역·운영 방식)
19:00 ~ 19:30황원용님 — Kubernetes SIG Docs Localization 소개 (Kubernetes 문서 현지화 프로젝트, Localization Contributor Workflow)
19:30 ~ 20:00박은정님 — OpenStack과 Kubernetes 컴포넌트는 어떻게 만나는가? (OpenStack on Kubernetes, 연계 사례)
20:00 ~ 20:20Q&A 및 네트워킹

낮에 있었던 발대식 세션과 저녁 밋업의 세션이 그대로 이어져서 시간가는줄 모르고 집중해서 들었다. 뒤에서는 밋업에서 얻은 인사이트를 OpenStack, Kubernetes 순서로 정리해보려고 한다.

OpenStack — 탄생부터 운영 문서화까지

OpenStack 이전

2010년 이전, 클라우드라는 개념 자체는 이미 있었지만 선택지가 좋지 않았다. 한쪽에는 AWS처럼 완전히 폐쇄적인 API로 돌아가는 퍼블릭 클라우드가 있었고, 다른 한쪽에는 VMware 같은 값비싼 proprietary 가상화 스택이 있었다. 오픈소스 쪽에서 그나마 존재하던 대안이 Eucalyptus였는데, 이건 아예 AWS API와 호환되도록 설계된 프로젝트였다. 즉 자체 표준을 만드는 게 아니라 AWS 생태계 안에서 하이브리드 클라우드를 돌리기 위한 보조 도구에 가까웠다. 결국 기업 입장에서는 어느 쪽을 택하든 특정 벤더(AWS든 VMware든)의 API와 생태계에 종속될 수밖에 없는 구조였다.

OpenStack 탄생

이 벤더 종속 문제를 풀기 위해 2010년, 미국항공우주국(NASA)과 클라우드 호스팅 업체 Rackspace가 각자 개발하던 프로젝트를 합쳤다. NASA는 자체 클라우드 플랫폼인 Nebula를 개발 중이었는데 여기서 나온 컴퓨트 제어 코드가 나중에 Nova가 됐고, Rackspace는 자사의 오브젝트 스토리지 서비스인 Cloud Files를 오픈소스로 공개하면서 이게 Swift가 됐다. 두 프로젝트가 만나 2010년 7월 오스틴에서 첫 디자인 서밋을 열고, 같은 달 21일 OSCON에서 정식으로 발표된 게 OpenStack의 시작이다. 그해 10월 나온 첫 정식 릴리스("Austin")에는 Nova와 Swift, 딱 두 개 서비스만 들어 있었다. 컴퓨트(Nova)와 스토리지(Swift)라는 클라우드의 가장 기본적인 두 축에서 시작해서, 이후 네트워킹(Neutron), 블록 스토리지(Cinder) 같은 프로젝트가 붙으며 지금의 오픈스택 생태계로 확장된 것이다.
핵심은 벤더 종속을 끊자는 목적의식이었다. VMware 같은 프로프라이어터리 스택도, AWS 같은 폐쇄적 퍼블릭 클라우드 API도 아닌, 아무 벤더에도 종속되지 않는 완전한 오픈소스 표준을 만들겠다는 게 OpenStack의 존재 이유였다. (아주 흥미롭지요)

OpenStack 재단, 그리고 왜 처음엔 리눅스 재단에 안 갔는가

OpenStack이 처음 만들어질 때 리눅스 재단(Linux Foundation) 산하로 들어가는 방안도 검토됐다고 한다. 그런데 당시 리눅스 재단은 사실상 리눅스 커널 하나만 돌보는 조직에 가까웠고, 지금처럼 수백 개 프로젝트를 품는 "빅 텐트" 구조가 아니었다. 그래서 오픈스택은 2012년에 독립된 재단(OpenStack Foundation)을 따로 설립하는 길을 택했다. 이후 2020년에는 오픈스택 하나만이 아니라 여러 오픈 인프라 프로젝트를 아우르겠다는 뜻에서 이름을 OpenInfra Foundation으로 바꿨다.

그리고 2025년, 큰 사건이 하나 있었다. OpenInfra Foundation이 리눅스 재단에 정식으로 합류한 것이다. 독립 재단을 만들었던 2012년의 결정과는 정반대의 방향인데, 이번엔 AI 시대의 막대한 인프라 투자와 지정학적 변화 속에서 힘을 합치는 게 낫다는 판단이었다고 한다. 이 합류로 재미있는 구조가 완성됐다. 운영체제 표준(Linux), 클라우드 인프라 표준(OpenStack/OpenInfra), 컨테이너 표준(Kubernetes/CNCF)이 모두 같은 리눅스 재단이라는 우산 아래 들어오게 된 것이다. OpenInfra Foundation은 리눅스 재단 안에서도 독자적인 예산과 거버넌스, 회원 구조를 유지하는 "재단 안의 재단" 형태로 운영된다.

OpenStack I18n 팀이 하는 일

OpenStack I18n(Internationalization) 팀의 공식 가이드는 "국제화는 OpenStack을 유비쿼터스로 만드는 데 필수"라는 문장으로 시작한다. 소프트웨어 자체의 국제화 품질을 높이고, 고품질 번역을 관리하는 게 이 팀의 역할이다. 쿠버네티스처럼 SIG-Docs 산하에 Localization 서브프로젝트를 두는 구조가 아니라, OpenStack은 애초에 I18n 팀 자체가 독립된 프로젝트 팀으로 존재한다. 소통 창구는 메일링 리스트와 IRC #openstack-i18n 채널이다.

번역 플랫폼 : Zanata -> Weblate

OpenStack은 2015년 9월부터 Zanata라는 번역 플랫폼(translate.openstack.org)을 써왔다. 웹 브라우저만 있으면 원문과 번역문을 좌우로 나란히 놓고 작업할 수 있는 CAT(Computer-Aided Translation) 툴이다. 그런데 Zanata 프로젝트 자체가 2018년 9월 이후로는 활발한 개발이 멈춘 상태였고, 이 문제를 풀기 위해 2023년 OpenStack 기술위원회가 Weblate로의 이전을 공식 투자 과제로 올렸다. 2024~2025년 사이 I18n SIG가 이 마이그레이션을 우선순위로 진행 중이며, Gerrit/Zuul과의 연동 문제 등을 해결해가고 있다고 한다.

기여 절차 부분은 핸즈온 세션을 통해 직접 실습을 진행했기 때문에, 해당 내용은 다음 글에서 실습 과정과 함께 자세히 다루도록 하겠다.

Kubernetes — 탄생부터 운영 문서화까지

Kubernetes 이전


Kubernetes도 마찬가지로 갑자기 생겨난 것이 아니다. 컨테이너 자체를 널리 퍼뜨린 건 Docker였고, Docker가 뜨자 "이 수많은 컨테이너를 어떻게 관리할 것인가"라는 오케스트레이션 문제가 따라왔다. 이 문제를 풀겠다고 나선 후보가 여럿 있었는데, Docker 진영 자체가 내놓은 Docker Swarm과, 아파치 재단의 Mesos(+Marathon)가 대표적이었다.
쿠버네티스 자체는 구글이 내부적으로 써오던 Borg, 그리고 그 후속작 Omega의 경험을 이어받아 만든 세 번째 컨테이너 관리 시스템이다. 즉 구글은 이미 수년간 수십만 대 서버에서 컨테이너를 굴려본 경험이 있었고, 그 노하우를 외부에 공개 가능한 형태로 다시 설계한 게 Kubernetes였다. 2014년 오픈소스로 공개됐고, 2015년 구글이 이걸 갓 설립된 CNCF(Cloud Native Computing Foundation)에 기증했다.

Kubernetes란


Kubernetes는 구글이 만든 관리 시스템이다. 컨테이너가 제공하는 활용성을 누리면서도 복잡한 분산 시스템을 쉽게 배포하고 관리할 수 있도록 도와주는 컨테이너 오케스트레이션 시스템으로 정의된다. 애플리케이션 배포 방식이 Traditional Deployment(물리 서버) → Virtualized Deployment(VM) → Container Deployment로 진화해온 흐름의 마지막 단계에 있다.

참고

CNCF - Kubernetes의 관계
CNCF(Cloud Native Computing Foundation)는 2015년 설립된 Linux Foundation 산하 재단으로, 벤더 중립적으로 클라우드 네이티브 오픈소스 프로젝트를 육성한다. 같은 해인 2015년, 구글이 쿠버네티스를 CNCF에 기증했고 쿠버네티스는 CNCF 최초의 오픈소스 프로젝트이자 최초로 졸업(Graduated)한 프로젝트가 됐다.

Kubernetes 커뮤니티 그룹 구조

쿠버네티스 커뮤니티는 세 층위로 나뉜다.

  • 위원회(Committees): 프로젝트에 대한 특정 권한을 위임받은 그룹. 행동 강령 위원회, 보안 대응 위원회, 운영 위원회 등이 있다.
  • 특별 관심 그룹(SIGs): 프로젝트의 특정 영역을 담당하는 그룹. Architecture, Docs, Release, Testing, Node, Storage 등으로 나뉜다.
    • 하위 프로젝트(Subprojects): SIG 안에서 독립적으로 운영되는 조직. 내가 참여하는 SIG-Docs 안의 Localization과 Website가 여기 해당한다.
  • 워킹 그룹(Working Groups): 여러 SIG에 걸쳐 특정 목표를 달성하기 위해 만들어진 임시 그룹.

SIG-Docs가 하는 일

SIG-Docs의 목적은 문서를 통해 쿠버네티스에 기여하며, 가능한 한 많은 사람이 쿠버네티스를 쉽게 사용하도록 돕는 것이다. kubernetes.io에 문서를 게시하고, 기능 문서화 표준을 제공하며, 핵심 API·아키텍처 문서화, 분기별 릴리스 문서 작성, 기여자 지침 제공, 공식 블로그 관리까지 담당한다.

Localization(L10n)이란

SIG-Docs의 하위 프로젝트인 Localization의 목표는 영문 공식 문서를 다양한 언어로 현지화하고, 그 과정을 표준화하는 공간을 제공하는 것이다. 단순히 "번역팀"이 아니라 공식 문서 유지보수 조직에 가깝다는 게 발대식에서 가장 인상 깊었던 설명이었다.

L10n의 역할을 정리하면:

  • Localization은 단순 번역이 아니라 오픈소스 접근성을 높이는 기여다. 모든 사용자가 영어에 익숙한 건 아니고, 모국어 문서의 존재는 학습 장벽을 크게 낮춘다.
  • 글로벌 커뮤니티 확장에 기여한다. 누구나 사용할 수 있는 프로젝트를 만드는 게 오픈소스 철학 중 하나이고, Localization은 지역 커뮤니티(예: 한글화팀) 활성화에도 기여한다.
  • 항상 최신 정보를 유지해야 한다. 쿠버네티스 릴리즈 주기는 약 4개월이고, L10n팀은 새 기능·Deprecated 기능·변경 사항을 각 언어 문서에 반영한다. 각 현지화 팀마다 별도 가이드라인이 있다.

AI 시대, L10n은 어떻게 변화해야 하는가

발대식 자료에서 많은 생각이 들었었다. 예전에는 "기여자가 직접 번역 → PR 생성 → 다른 기여자가 리뷰 → 머지"가 표준 흐름이었는데, 지금은 "AI가 자동 번역해주면 되는 거 아니냐"는 질문이 자연스럽게 나온다. (글쓰는 화자도 Claude를 pro를 사용하며 하루 토큰량을 빡빡하게 다 쓰는 입장이기에..)

앞으로의 방향으로 제시된 흐름은 "한글화 가이드라인을 기반으로 한 AI 프롬프트로 초안 생성 → 기여자가 리뷰 → PR 생성 → 다른 AI 혹은 기여자가 리뷰 → 머지"였다. 완전 자동화도, 완전 수작업도 아닌 중간 지점을 계속 고민해야 하는 이슈로 남겨져 있었다.

실제로 용어집 등록 논의(GitHub issue #51885)를 보면, "Pod를 포드로 표기할지 팟으로 표기할지" 같은 세부 사항까지 커뮤니티가 활발하게 토론하며 표준을 정하고 있었다. 이렇게 정립된 용어는 쿠버네티스 관련 문서·강의·서적의 참고 기준이 된다는 설명을 들으니, 단순 번역 작업이 아니라 표준을 함께 만들어가는 일이라는 게 실감났다.

실제 기여 프로세스

1) 기여 준비

  • CNCF 커뮤니티 행동 강령(Code of Conduct)을 숙지한다.
  • CLA(Contributor License Agreement)에 서명한다. 기여자가 작성한 코드의 권리를 커뮤니티에 양도한다는 의미이며, PR 생성 시 자동으로 서명 여부가 확인된다. 서명이 안 되어 있으면 PR이 머지되지 않는다.
  • 처음이라면 kubernetes-sigs/contributor-playground 저장소에서 연습해볼 수 있다. remote 디렉터리에 자신의 GitHub 아이디로 마크다운 파일을 만들어 PR을 올리면 CLA 서명 코멘트가 자동으로 달리고, 머지되면 메인테이너의 환영 메시지도 받을 수 있다.

2) 이슈 탐색 및 작성

  • Kubernetes i18n Tracker(kfess.github.io/kubernetes-i18n-tracker)에서 언어별로 원문 대비 얼마나 뒤처졌는지(outdated) 확인할 수 있다.
  • 번역이 필요한 문서를 찾으면 kubernetes/website 저장소에 이슈를 등록한다.

3) 한글화 작업 및 PR 작성

  • 쿠버네티스 문서 한글화 가이드(kubernetes.io/ko/docs/contribute/localization_ko)를 따른다. 과거에는 별도 브랜치를 운영했지만 지금은 메인테이너·컨트리뷰터 모두 main 브랜치를 기준으로 작업한다.
  • 한글화 모범 사례 문서도 참고하면 좋다. 기여 방식, 문체 및 표현, 원문 처리, 용어 네 가지 카테고리로 자주 반복되는 리뷰 사례가 정리돼 있다.
  • 작업이 끝나면 PR을 올린다.

4) AI 사용에 대한 가이드라인
이 부분이 개인적으로 가장 중요하게 느껴졌다. kubernetes.dev의 AI Guidance 문서 핵심은 이렇다.

  • AI를 이용한 PR 작성은 허용되지만, 모든 변경 사항은 작성자가 이해하고 책임져야 한다.
  • AI를 사용했다면 PR 설명에 반드시 공개해야 한다.
  • AI를 공동 작성자로 등록하거나 AI가 만든 커밋 메시지를 그대로 쓰는 건 금지된다.
  • AI가 대부분 작성한 대규모 PR은 허용되지 않는다.
  • PR 제출 전 반드시 직접 코드 리뷰와 테스트를 해야 한다.
  • 리뷰어의 질문에는 AI가 아니라 작성자가 직접 답해야 하고, 변경 이유를 설명하지 못하면 PR이 종료될 수 있다.

참고

한국어 L10n 팀은 Slack kubernetes.slack.com의 #kubernetes-docs-ko 채널을 중심으로 소통한다. 2주 단위 목요일 밤 10시(KST)에 Zoom으로 정기 회의를 하고, 회의록은 Google Docs에 공개되어 있다. 팀 구성은 Lead 1명, Approver·Reviewer 각 여러 명, 그리고 활동 현행화가 필요한 Member 목록까지 투명하게 공개돼 있었다. 실제로 참여형 로컬라이제이션(ko) 프로젝트를 새로 발족하려는 신규 기여 문의가 Slack에 올라오는 것도 볼 수 있었는데, 커뮤니티 활발히 운영되기도 하고 나도 기여 할 수 있을까에 대한 막연한 두려움이 든다.. (글, 리뷰, Issue, PR등등 모두 영어여...)

생각정리

같은 "문서 현지화"라도 OpenStack과 Kubernetes의 워크플로는 꽤 다른점이 처음 보는 입장에서는 적응하기 어려웠다. OpenStack은 Zanata(→Weblate)라는 전용 번역 툴 안에서 원문·번역문을 대조하며 작업하는 번역 전용 워크플로였고, 기여자의 활동을 "번역 단어 수"로 정량화해 거버넌스 투표권(AC 지위)까지 연결했다. 반면 쿠버네티스는 GitHub 저장소에 PR을 올리고 리뷰를 받는, 개발자에게 익숙한 코드 기여 방식 그대로였고 AI 사용 가이드라인까지 별도 문서로 명문화돼 있었다. 먼저 이 프로세스를 적응하고 방법, 돌아가는 구조를 이해해야 하기에 공식문서들을 들여다 봐야지.. (기여하는 부분에 있어 문서화가 정말 잘 되어있어 보기 편하다)

발대식을 진행하며 팀원들과의 자기소개 시간이 있었는데, 실제 현업에서 일하시는 분들도 많았고 인턴하시는 분들, 학생분들도 있었다. 모두 Cloud/Infra 관심이 있고 오픈소스 기여하는 것에 관심이 있어서 이렇게 팀으로 모이게 되었으니, 멘토님이 밋업 때 강조해주신 대로 팀원들과 함께 많이 소통하고 리뷰하고 배워야겠다. 발대식을 시작으로 이제 프로젝트가 시작된다. 앞으로 멘토님들을 따라 OpenStack, Kubernetes를 사용하는 한국사람들에게 더 보기 좋고 편한 문서를 만들기 위해 기여하면서, 더 좋은 서비스가 뭐가 있을까, 가독성이 좋은 글이 무엇일까(단어에 대한 양식은 정해진 부분이 많지만)에 대해서 고민을 많이 할 것 같다. 중간에 놓지 말고 끝까지 집중해서 많은 것을 배우고 성장하자. (좋은 Review를 받아 기여해 Organization Member가 되는것이 현재 목표!)

참고 자료

OpenStack 문서 기여 관련 (한국어 자료)

쿠버네티스 문서 기여 관련

profile
Mini
發現(발현)
다음 포스트

2026 오픈소스 컨트리뷰션 아카데미, Challenges 회고

0개의 댓글