UbuCon Korea 2026

Saturday 29 Aug 2026, 09:00 → 20:00 Asia/Seoul

AWS Korea 18F (Centerfield EAST)

Junsang Moon, Youngbin Han (Ubuntu Korea Community), Yeonguk Choo (Ubuntu Korea Community), Sangkon Han (Ubuntu Korea Community), Hoehyeong Jung, Gyuseok Jung

UbuCon Korea 는 한국 내 우분투 기여자 및 사용자를 대상으로 매년 열리는 행사로, 우분투 관련 사례와 노하우를 공유 하는 모임의 장 입니다.

본 웹사이트는 발표 제안서 제출/검토 및 일정 공유 용도로 활용됩니다, 그 외 공지사항 및 기타 정보는 https://2026.ubuntu-kr.org 를 확인 하시기 바랍니다.

10:00 → 10:30 입장

10:30 → 11:00 Keynote : 오픈소스 생태계에서 배포판의 역할과 앞으로의 방향

데비안과 우분투를 비롯한 여러 리눅스 배포판은 지금까지 각종 오픈소스 소프트웨어를 사용자에게 배포하는 역할을 해 왔습니다. 하지만 최근에는 자체 패키징 시스템을 비롯해 소프트웨어를 배포하는 여러 대안들이 많아졌습니다. 최근의 변화 속에서 리눅스 배포판은 앞으로 어떤 역할을 할 수 있을까요? 리눅스 배포판의 방향은 어떻게 결정되고 있고, 사용자와 기여자로서 우리의 의견을 배포판에 반영하려면 어떻게 해야 할까요?

Speaker: Changwoo Ryu (debian.org)

오픈소스 생태계에서 배포판의 역할과 앞으로의 방향.pdf

11:00 → 11:30 "GPU 어디서 돌려요?" — Ubuntu + 컨테이너로 AI 학습부터 추론, 서빙까지 한방에

AI 모델을 서비스에 도입하려 할 때 가장 먼저 마주하는 벽은 'GPU 인프라 구축'과 '감당하기 힘든 비용'입니다. 본 세션에서는 거창하고 복잡한 MLOps 플랫폼 이야기 대신, Ubuntu 개발자와 인프라 엔지니어가 내일 당장 실무에 적용할 수 있는 "컨테이너 기반의 실전 AI 인프라 구축기"를 공유합니다.

AWS 환경에서 검증된 Ubuntu 기반 인프라를 시작으로, Docker를 통해 환경 의존성을 깨끗하게 제거하는 방법, 그리고 Amazon EKS와 Karpenter를 결합해 복잡한 GPU 워크로드를 유연하고 탄력적으로 오케스트레이션하는 아키텍처 패턴을 소개합니다. 특히 현업에서 가장 민감한 GPU 클라우드 비용을 Spot 인스턴스와 MIG(Multi-Instance GPU), GPU time-slicing 등의 기술에 따른 상세한 내용을 들으실 수 있습니다.

다루는 내용
: AI 워크로드에서 Ubuntu를 선택하는 이유
: GPU 인스턴스 유형별 선택 기준 (학습 vs 추론)
: Docker 컨테이너로 CUDA 환경을 사용하는 방법
: Amazon EKS + Karpenter로 GPU 워크로드 오케스트레이션
: 학습된 모델을 컨테이너 기반으로 추론 서빙하는 패턴
: Spot, MIG, GPU time-slicing을 활용한 비용 최적화 전략

청중이 얻어갈 것
: Ubuntu + 컨테이너 기반 GPU AI 파이프라인의 전체 아키텍처 레퍼런스
: EKS + Karpenter GPU 워크로드 오케스트레이션 모범 사례
: 바로 적용 가능한 GPU 비용 절감 전략 (Spot, MIG, time-slicing)

Speaker: Ian Y. Choi

11:30 → 12:00 캐노니컬의 깃헙 러너 운용법 | Ephemeral by Design: How Canonical Runs Self-Hosted GitHub Actions Runners with Ubuntu and Juju

캐노니컬은 오픈소스 문화를 중요시 합니다. 깃헙 또한 오픈 소스에 많은 기여를 하고있기에 깃헙에서의 CI 사용은 오픈소스에 기여하는데 중요한 역할을 맡고 있습니다.
캐노니컬의 오픈소스 기반 인프라와 깃헙 러너의 결합을 소개합니다. 서비스 운영의 난이도에서부터 보안정책까지의 경험을 함께 공유하고자 합니다.
Juju의 생태계에 포함된 RabbitMQ, PostgreSQL 및 Canonical Observability Stack을 활용한 깃헙러너 배포 및 운영, 또한 내부 팀 관련 use-case를 소개합니다.

---

What happens when a CI runner is reused between jobs? Secrets linger in the environment, caches can be poisoned, and a compromised build can affect the next team that uses the same machine. The answer Canonical found was simple in concept but fascinating in implementation: every GitHub Actions job gets its own fresh Ubuntu virtual machine — and that VM is destroyed when the job ends.

In this talk, we'll walk through why Canonical needed self-hosted GitHub Actions runners, what security challenges motivated an ephemeral-VM approach, and how we built a production system using entirely open source tools: Juju charms, OpenStack, Ubuntu runner images, RabbitMQ, PostgreSQL, and the Canonical Observability Stack.

You'll see how the Juju operator model makes it possible to compose infrastructure from building blocks — webhook gateway, job planner, runner manager — each modelled as a charm with explicit relations and lifecycle hooks. We'll share architecture decisions, surprising failure modes, and practical lessons for teams considering self-hosted runners.

Whether you're new to CI/CD or a seasoned DevOps engineer, you'll leave with a concrete picture of how open source Linux infrastructure can power secure, scalable developer workflows — and a link to the charms on Charmhub if you want to try it yourself.

Speakers: Florentiana Yuwono, Mr Yang Soo Yoon (Engineer)

12:00 → 13:30 점심시간 | Lunch Break

13:30 → 15:00 MicroCeph를 이용한 Ceph 배포 및 응용 그리고 cephtrace를 이용한 디버깅 방법 습득

왜 Ceph인가

1. 분산 스토리지의 필요성
2. 블록 / 파일 / 오브젝트를 하나의 플랫폼에서 제공
3. 운영 난이도가 높은 이유

MicroCeph 소개

1. 기존 Ceph 배포 방식과 차이
2. Snap 기반 구성
3. 단일 노드 → 멀티 노드 확장

실전 배포 데모

• 노드 bootstrap
• OSD 추가
• cluster 상태 확인

Ceph 활용 사례

1. RBD 기반 VM 스토리지
2. CephFS 공유 스토리지
3. S3 호환 Object Storage
4. OpenStack / Kubernetes 연동 개요

cephtrace를 이용한 ceph 디버깅

1. eBPF란 무엇인가?
2. I/O가 내부적으로 어떻게 흐르는가
3. write/read 요청 추적
4. latency 분석
5. 병목 포인트 찾기

Speakers: Dongwon Cho, Seyeong Kim

13:30 → 14:10 Nix를 활용해 선언적으로 패키지 관리하기

13:30 → 14:00 커널 수준에서 완성하는 컨테이너 보안 격리

AppArmor 설정으로 인해 컨테이너를 운영하기 까다로웠던 적이 있었나요? 기본적으로 AppArmor는 호스트 전역에서 네임스페이스를 공유하기 때문에, 멀티 테넌시 환경이나 복잡한 컨테이너 인프라에서 보안 정책을 유연하게 관리하기 까다로웠습니다.

본 세션에서는 이러한 한계를 해결하기 위한 AppArmor Policy Namespaces의 핵심 개념과 동작 원리를 중급 개발자의 눈높이에서 설명합니다. 컨테이너마다 독립된 AppArmor 정책 공간을 부여함으로써, 시스템 보안을 보다 더 유연하게 관리합니다.

Speaker: Mr Leesoo Ahn

13:30 → 15:00 키사이닝 파티

13:30 키사이닝 파티

14:00 → 14:30 PostgreSQL on AMD/ARM/RISCV using Apt/Snap/Charm/Rock/Juju

PostgreSQL is a popular and powerful, open source object-relational database. Canonical provides your simple and secure way to enjoy it on the most popular architectures today in many different flavors: Apt/Snap/Charm/Rock/Juju!

Speaker: Mr Alex Lutay (Canonical)

14:10 → 14:50 네트워크 세계에서 하드웨어의 소중함: 네트워크 세계에서 하드웨어의 소중함 - 임시우

14:30 → 15:00 “모니터링은 정상인데 OOM?” Ubuntu 환경에서 eBPF로 추적하는 PyTorch 유령 메모리 누수

[세션 개요]
Ubuntu 기반 AI 인프라를 운영하다 보면 원인 모를 OOM(Exit 137) 장애를 마주하곤 합니다. Prometheus 대시보드나 컨테이너 메트릭은 완벽하게 정상이지만, PyTorch 프로세스가 갑자기 강제 종료되는 현상입니다. 이 문제는 PyTorch가 공유 메모리(/dev/shm)에 텐서를 생성한 후, 프로세스가 종료되는 과정에서 고아가 된 자식 워커들이 정리되지 않아 발생합니다. OS 수준에서는 (deleted) 상태로 마킹되어 지표에 잡히지 않지만, 실제로는 메모리가 반환되지 않고 노드 자원을 점유하는 ‘유령 메모리’ 현상입니다.

[핵심 내용 및 실전 트러블슈팅]
기존의 유저 스페이스 모니터링 도구로는 파악하기 힘든 이 사각지대를 Linux 커널 표준 기술인 eBPF로 추적하고 조치하는 방법을 공유합니다. 무거운 외부 솔루션 도입이나 애플리케이션 코드 수정은 필요하지 않습니다.
Ubuntu 커널에 내장된 BTF(CO-RE)와 공식 패키지인 bpftrace만으로 문제를 추적하는 과정을 실제 장애 재현 시나리오와 함께 단계별로 시연합니다. 특히 VFS(가상 파일 시스템) 내부의 kprobe:fput을 활용해 f_count 참조 카운트가 0으로 떨어지지 않는 누수 현상을 직접 포착하고, 커널 레벨에서 리소스가 해제되지 않고 잔존하는 원인을 정확히 찾아내는 실전 팁을 다룹니다.

[청중이 얻어갈 수 있는 것]
- 커널 레벨 진단 시야: 원인 불명의 OOM이 발생했을 때 단순 추측성 컨테이너 재시작에 의존하지 않고, 시스템 콜 수준에서 원인을 진단하는 접근법을 공유합니다.
- 모니터링의 사각지대 이해: 표준 메트릭 도구가 놓치는 가상 파일 시스템 레이어와 Linux 커널 실제 상태 간의 간극을 이해합니다.
- 바로 사용 가능한 오픈소스 스크립트: 발표자가 Pytorch의 유령 메모리를 관측할 때 사용한 bpftrace 기반 진단 스크립트를 GitHub 링크를 통해 공유받을 수 있습니다.

Speaker: minjin park (MegazoneCloud, Microsoft Certified Trainer)

[박민진]_답답한 쿠버네티스 장애 추적로그 창 닫고 눈으로 확인하기 (feat. eBPF).pdf

14:50 → 15:20 휴식시간 | Break

15:00 → 16:40 AWS 후원사 세션

15:00 → 15:15 휴식시간 | Break

15:00 → 15:15 휴식시간 | Break

15:15 → 15:45 Ubuntu 25.10/26.04의 새로운 RISC-V 기본 프로파일, RVA23 알아보기

Ubuntu 25.10와 26.04에서는 RISC-V 아키텍처의 기본 지원 프로파일이 RVA23로 상향되었습니다.

RISC-V는 x86, ARM와 다르게 명령어 집합(ISA)이 '개방형 표준(Open Standard)'으로 공개된 아키텍처입니다. 칩셋 제조사가 자유롭게 원하는 기능을 넣고 뺄 수 있습니다.

이런 유연성을 가지게 되면 특정 칩셋에 맞는 소프트웨어를 극도로 최적화해 맞춤 제작할 수 있지만, 반대로 다른 칩셋에서는 프로그램이 대부분 돌아가지 않는 심각한 '파편화(Fragmentation)' 문제가 발생합니다.

어느 표준에 맞추어 소프트웨어를 빌드하면 이 표준을 따르는 다른 칩셋에서는 모두 돌아가도록 하는 것이 목표이며, RVA(RISC-V Application Profile)는 소프트웨어가 원활하게 구동되기 위한 하드웨어 확장의 '최소 기준선'을 만들어 상호 호환되게 하는 것입니다.

우분투가 기본 프로파일을 RVA23으로 올렸다는 것은, RVA23을 지원하지 않는 기존 칩셋은 모두 지원을 포기한다는 의미입니다. 실제로 지금까지 나온 대부분의 상용 RISC-V 칩셋과 보드는 RVA23을 지원하지 않습니다. 2026년 5월 처음 출시된 Spacemit-K3 칩셋 외에는 QEMU 말고는 지원하는 환경이 전무하다시피 합니다.

그럼에도 이런 급진적인 변경을 하게 된 계기는 무엇일까요?

RVA23은 가장 중요한 2가지 확장을 가집니다.

1. 벡터 확장: 가변적인 길이를 가진 벡터를 통해 한 번에 많은 데이터를 병렬로 연산할 수 있습니다. 이를 통해 암호화, AI 연산, 멀티미디어 인코딩/디코딩 등 강력한 연산 능력을 요구하는 환경에서 더 높은 성능을 이끌어 낼 수 있습니다.
2. 하이퍼바이저 확장: 가상화를 하드웨어적으로 지원하여 더 빠른 가상화 환경을 제공할 수 있으며, 이는 가상 머신을 자주 사용하는 서버 환경에 매우 중요한 확장입니다.

이런 추가 확장 기능을 통해 더 고성능의 RISC-V 생태계를 이끌어 낼 수 있습니다. 과거의 호환성을 포기하더라도 미래의 고성능 환경에 집중하겠다는 것이 이번 우분투 개발 방향 변화의 핵심이라고 생각합니다.

이번 발표에서는 이러한 기술적 배경을 더 자세하게 설명하고, 실제 RVA23을 지원하는 최신 기기 환경을 직접 시연할 예정입니다.

Speaker: Sungjoon Moon

15:15 → 15:45 우분투 컨테이너로 AI 에이전트 샌드박싱하기

레거시 애플리케이션에서는 종종 하드코딩된 로직이라든가 특정 파일시스템에 강한 종속성을 지닌 스크립트라든가 하는 것들이 보입니다. 이런 상황이 되면 유지보수는 너무 어렵죠. 이런 상황에서 앱 현대화는 더더욱 어려워질 수 밖에 없습니다.

이럴 때 Docker Sandbox 기능이 아주 유용합니다. 샌드박스 안에서 코드베이스를 GitHub Copilot과 같은 코딩에이전트를 통해 앱 현대화 작업을 수행하는 경우 샌드박스 밖의 파일에 접근할 수 없으니 보안상으로도 안전하고 기존의 코드에 영향을 주지도 않게 됩니다.

이번 세션에서는 Docker의 Sandbox 기능을 통해 컨테이너 안에서 AI 코딩 에이전트를 실행시켜 앱을 현대화 하는 과정에 대해 간단하게 다뤄보기로 합니다.

Speaker: Mr Justin Yoo

15:20 → 16:00 데비안 배포판의 한국어 지역화에 대한 여러 이슈

15:45 → 16:15 연구실에서 만나는 Linux : NAS, 초전도체와 열전도, 자동화

Audiences

• Linux를 실제 업무나 연구에 활용하는 사례가 궁금한 분
• Ubuntu, WSL, NAS, Docker를 활용한 개인 또는 소규모 서버 환경 구축에 관심 있는 분
• 연구 데이터 관리와 자동화 방법에 관심 있는 학생 및 연구자
• HPC(고성능 컴퓨팅) 환경이 실제 연구에서 어떻게 활용되는지 궁금한 분
• Linux 기반 도구들을 하나의 워크플로우로 연결하는 사례를 보고 싶은 분

Abstract

계산과학 기반의 응집물질 물리 연구를 수행하며 Linux는 단순한 운영체제를 넘어 연구 환경 전반을 연결하는 플랫폼이 되었다. 본 발표에서는 Ubuntu Desktop, WSL, HPC 클러스터를 오가며 연구를 수행한 경험을 바탕으로, NAS와 Docker를 활용한 연구 데이터 관리, SSH 기반 원격 계산 환경, 그리고 Python과 Shell Script를 이용한 반복 작업 자동화 사례를 소개한다. 또한 이러한 경험을 출발점으로 Materials Project와 Autonomous Laboratory 등 최신 연구 환경의 흐름도 함께 살펴본다. 이를 통해 Linux와 오픈소스가 단순한 운영체제를 넘어 연구 인프라를 구성하는 핵심 플랫폼으로 어떻게 활용되는지 살펴보고, 개인 연구실 수준에서도 구축 가능한 실용적인 연구 환경 사례를 공유하고자 한다.

Table of Contents

연구 환경에서 Linux를 사용하게 된 배경 (5분)

• 응집물질 물리 연구와 계산과학
• Ubuntu Desktop, WSL, HPC 환경 소개

Linux 기반 연구 인프라 구축 (8분)

• NAS 기반 연구 데이터 관리
• Docker를 활용한 Nextcloud 구축 사례

Linux를 활용한 계산과학 연구 (9분)

• HPC 환경에서의 VASP 및 Quantum ESPRESSO 활용
• SSH 기반 원격 연구 환경
• 초전도체 관련 연구와 열전도 계산 사례

Linux를 활용한 자동화와 생산성 향상 (5분)

• Python 및 Shell Script를 활용한 반복 계산 및 데이터 정리 자동화

Linux가 만드는 현재와 미래 연구 환경 (3분)

• Materials Project와 Autonomous Laboratory 사례

Speaker: Sue Hyeon Hwang (Pusan National University)

15:45 → 16:15 오픈소스 생태계를 위협하는 최신 APT 공격과 우분투 환경에서의 DevSecOps 대응 방안

1. 공격 패러다임의 변화 (5분)
   CVE 취약점 패치 시대의 종말: 개발자의 단순 실수로 발생하는 취약점(CVE) 방어를 넘어, 처음부터 악의적인 의도를 가지고 npm, PyPI 등에 삽입되는 '악성 오픈소스 컴포넌트(Malware Component)' 공격의 위협성을 공유합니다.
   공격자들이 오픈소스 커뮤니티의 개방성과 무조건적인 신뢰를 어떻게 역이용하여 소프트웨어 공급망 전체를 무너뜨리는지 변화를 짚어봅니다.

2. 최신 지표 및 글로벌 데이터 분석 (5분)
   6분마다 1개씩 쏟아지는 위협: 글로벌 오픈소스 보안 연구소의 최신 2026년 1분기 지표를 인용하여, 분기당 2만 개가 넘는 악성 패키지가 폭증하고 있는 현실을 데이터로 직시합니다.

전체 악성 코드 중 과반수 이상(55%+)이 시스템 파괴가 아닌 '호스트 정보 정찰' 및 'AWS/Git 자격 증명(Secrets) 탈취'를 목적으로 작동한다는 통계적 인사이트를 제공합니다.

1. 실제 APT 위협 사례 및 Demo (15분)
   국가 지원 해커들의 전략: 북한 연계 라자루스(Lazarus) 그룹이 오픈소스를 무기화하여 전 세계 개발자를 타깃으로 벌인 글로벌 스파이웨어 캠페인의 기술적 메커니즘을 상세히 살펴봅니다.

Demo: 우분투 환경에서 오픈소스 타이포스쿼팅 패키지를 명령어로 설치했을 때, 런타임 스크립트를 통해 우분투 시스템 내부의 환경 변수와 비밀 키가 유출되는 과정을 시연합니다.

1. 실행 가능한 DevSecOps 대응 전략 및 결론 (5분)
   인바운드 방화벽의 한계 극복: 네트워크 단을 넘어선 런타임 통제 방안을 논의하고 CI/CD 파이프라인 자동화를 통해 조직 내 빌드 파이프라인에 즉시 연동 및 검토할 수 있는 오픈소스 보안 도구 활용법과 실무적인 공급망 방어 정책 가이드를 제시합니다.

Speakers: Jeff gy Kim, Jisu Na (GroMetric)

UbuCon26_오픈소스 생태계를 위협하는 최신 APT 공격과 우분투 환경에서의 대응.pptx

16:00 → 16:40 USB 한 장으로 끝내는 P2V/V2P

16:15 → 16:40 휴식시간 | Break

16:15 → 16:40 휴식시간 | Break

16:40 → 17:05 라이트닝 토크 | Lightning Talk

17:05 → 17:35 폐회사 | Closing Remarks