우분투(Ubuntu)의 AI 미래

^{source https://discourse.ubuntu.com/t/the-future-of-ai-in-ubuntu/81130}

• 2026년이 지나며 LLM 기반 도구가 점점 더 보편화되고 있음.

• 기술 업계 전반의 도입 양상은 엇갈렸음.

  • 어떤 프로젝트가 "AI" 기술을 받아들이는지도 제각각이고,

  • 기업이 도입 구조를 짜는 방식도 서로 다름.

• 그래서 Canonical과 Ubuntu가 AI를 어디까지, 어떻게 넣을지 자주 질문받고 있음.

• 이 글에서 다루려는 내용은 세 가지임.

  • AI가 Canonical과 Ubuntu의 미래에서 어떤 역할을 맡는지

  • OS 안의 AI 기능을 분류하는 내 프레임워크

  • Canonical 내부에서 지금 AI 도입을 어떻게 접근하는지

• 결론부터 말하면, Canonical은 초점을 분명히 두고 원칙 있게 AI 도구 사용을 확대하는 중임.

  • 우리 가치와 더 잘 맞는 라이선스 조건의 open weight 모델을 선호함.

  • 여기에 오픈 소스 하네스를 결합하는 방향임.

• Ubuntu에는 앞으로 1년 동안 AI 기능이 순차적으로 들어올 예정임.

  • 충분한 성숙도와 품질이 확인된 경우에만 넣을 것임.

  • 기본값은 로컬 추론 쪽으로 기울어져 있음.

• Ubuntu의 AI 기능은 두 가지 형태로 들어올 예정임.

  • 하나는 기존 OS 기능을 백그라운드 AI 모델로 강화하는 방식

  • 다른 하나는 원하는 사용자를 위한 "AI 네이티브" 기능과 워크플로우

Canonical의 AI 도입

• 올해 Canonical은 AI 도구 교육과 실전 역량 축적을 더 의도적으로 밀기 시작했음.

• 토큰 사용량, AI가 작성한 코드 비율 같은 얕은 지표는 잡지 않음.

  • 대신 엔지니어가 직접 실험하고, 어디에서 AI 도구가 가치를 내는지 이해하도록 유도함.

• 초기에 단일 AI 스택을 강제로 고르지 않음.

  • 각 팀이 일부러 서로 다른 선택을 하고 깊게 파보게 해서,

  • 앞으로 6개월 동안 조직 차원에서 더 많은 학습을 얻으려는 접근임.

• 어떤 작업에서는 AI 도구가 거의 고민할 필요 없는 선택지임.

  • 특히 작업이 기계적이고 적절한 컨텍스트가 주어지면,

  • 자율적으로도 매우 좋은 결과를 낼 수 있음.

• 반대로 잘 못하는 영역도 분명히 있음.

• 앞으로 몇 달 안에 우리 엔지니어 전원이 AI 도구 전반을 자연스럽게 다루게 되길 바람.

  • 잘 맞는 곳에서는 적극 활용하고,

  • 맞지 않는 곳에서는 피할 줄 알아야 함.

• Canonical에서 사람을 평가할 때 기준은 "AI를 얼마나 많이 쓰는가"가 아님.

  • 계속해서 "얼마나 잘 결과를 내는가"를 볼 것임.

• AI가 Canonical의 소프트웨어 엔지니어링 일자리를 가져가진 않을 것임.

  • 다만 AI 도구를 매우 능숙하게 다루는 다른 엔지니어가 경쟁 우위를 가질 수는 있음.

• AI를 쓰기 위한 AI 사용은, 노출을 늘리는 것 외에는 생산적인 목표가 아님.

  • 실제 프로덕션 코드에서도 좋은 결과로 이어지는 경우가 드묾.

• 잘 최적화된 지점에, 통제 가능하고 리뷰 가능한 방식으로 쓰면 매우 효과적임.

• 나는 AI가 다음 영역에서 특히 효과적인 사례를 봐 왔음.

  • 교육 보조

  • 개발 작업 가속

  • 디자인 보조용 몰입형 프로토타입 제작

  • 까다롭거나 단조로운 트러블슈팅 지원

신중하게 가기

• 우리 접근의 중심에는 책임성과 투명성이 있음.

• 오픈 소스 프로젝트에 거의 고민 없이 던져진 slop PR과 기여 사례를 많이들 봤을 것임.

• 그런 방식은 원래도 올바른 기여 방식이 아니었고, Canonical에서도 절대 장려하지 않음.

• 이런 도구에 과도하게 의존하면 새 개념을 배우는 능력이 약해질 수 있다는 우려도 커지고 있음.

  • 그럴 가능성은 있음.

  • 몇 년 전 StackOverflow를 두고 비슷한 얘기가 나왔을 때보다 이번이 더 그럴 수도 있음.

• 그래도 결국 팀 문화와 기대 수준의 문제라고 봄.

• 내 경험상 LLM은 학습 도구로 매우 뛰어났음.

• 동료와 오픈 소스 기여자가 좋은 감각을 갖도록 도와야 함.

  • 기계가 내놓은 결과를 맹신하지 않고 회의적으로 보게 훈련해야 함.

  • LLM이 가장 강한 지점과 가장 약한 지점을 이해하게 해야 함.

• 조직 입장에서는 이제 추가로 감사해야 할 도구와 벤더 집합도 생겼음.

• 업계와 고객군에 따라 어떤 모델과 도구를 쓸 수 있는지 제약이 있을 수 있음.

  • 지금 시점에서는 아예 못 쓰는 경우도 있을 수 있음.

  • 이럴 때 로컬 오프라인 추론과, LLM이 호출할 맞춤형 도구 접근성이 매우 중요해질 수 있음.

• LLM 맥락에서 "open source"라는 표현이 민감하게 들릴 수 있다는 점도 인정함.

• 모델 weight 접근성은 의미가 크지만, 오픈 소스 커뮤니티가 익숙한 종류의 투명성과 같지는 않음.

• Ubuntu에서 제공할 모델을 고를 때는 weight 공개 여부만 보지 않을 것임.

  • 모델 라이선스의 조건까지 균형 있게 볼 예정임.

• Ubuntu 관점의 기본 성향은 분명함.

  • 로컬 추론 선호

  • 오픈 소스 하네스 선호

  • 우리 가치와 호환되는 라이선스 조건의 모델 선호

  • 외부 서비스가 필요한 경우를 위한 명확한 인터페이스 제공

• 도입 속도를 보면, 한동안은 의심스러운 사용 사례도 계속 나올 가능성이 큼.

• 오픈 소스 커뮤니티의 오래된 구성원으로서 우리의 역할도 분명함.

  • AI 도구로 어디까지 가능한지 최전선에서 파악하고,

  • 좋은 본보기를 먼저 보여줘야 함.

• 책임감 있고 사려 깊은 사용으로 무엇을 만들 수 있는지 보여줘야 함.

• 새 기여자도 더 나은 실천으로 이끌어야 함.

  • 그래야 이 도구들을 강력하게 활용하게 되고,

  • 앞으로 수년간 오픈 소스의 다음 물결에도 기여하게 될 것임.

암묵적 기능 vs. 명시적 기능

• 지난 몇 주 동안 Ubuntu 안의 다양한 AI 도입 방식을 생각하기 위한 프레임워크를 다듬기 시작했음.

• 그 중심에는 명시적 AI 기능과 암묵적 AI 기능의 구분이 있음.

• 암묵적 AI는 사용자에게 새로운 멘탈 모델을 들이밀지 않으면서, 기존 운영체제 기능을 AI로 강화하는 접근임.

• 흥미로운 예로 Ubuntu에 speech-to-text와 text-to-speech를 일급 기능으로 넣는 일을 들 수 있음.

• 나는 이걸 "AI 기능"이라기보다 핵심 접근성 기능으로 봄.

  • LLM 도입으로 큰 폭의 품질 개선이 가능하고,

  • 단점은 거의 없거나 아예 없을 수도 있음.

• 이 영역 상당수는 로컬 추론만으로도 구현 가능함.

  • 오픈 소스 하네스와 open weight 모델을 쓰면 되고,

  • 이 용도에서는 정확도와 효율도 충분히 좋음.

• 명시적 AI 기능은 더 분명하게 AI 중심으로 보이는 기능임.

  • 더 "agentic"한 워크플로우도 여기에 들어갈 수 있음.

• 예를 들면 이런 것들이 가능함.

  • 새 문서나 애플리케이션 작성

  • 트러블슈팅 워크플로우 자동화

  • 맞춤형 일일 뉴스 브리핑 같은 개인 자동화 작업

• 이런 기능에는 큰 책임도 따라옴.

  • 원치 않는 부작용을 막기 위해,

  • 적절한 보안 통제와 격리 조치를 갖춰야 함.

• 암묵적 AI 기능은 Ubuntu가 원래 하던 일을 더 잘하게 만들 것임.

• 명시적 AI는 새로운 기능으로 도입될 것임.

로컬 추론 접근성

• 예전에도 inference snaps에 대해 쓴 적 있고, 최근 AI Native Dev 밋업에서도 더 자세히 발표했음.

• 핵심은 inference snaps가 로컬 추론 접근을 단순화해 준다는 점임.

  • 모델은 각 하드웨어에 맞게 특별히 최적화되어 제공됨.

• Ubuntu의 광범위한 보급과 Canonical의 실리콘 기업 파트너십이 결합되면서,

  • 사용자에게 큰 인지 부담을 주지 않고도

  • 배포판 차원의 고성능 기반 추론 기능을 제공할 수 있게 됐음.

• snap install nemotron-3-nano가 Ollama, Huggingface, 수많은 모델 quantization 조합을 직접 관리하는 것보다 훨씬 쉬움.

• 해당 실리콘 업체가 최적화 바이너리를 기여했다면,

  • snap이 그 하드웨어에 맞는 최적화 버전을 바로 제공함.

• inference snaps에도 다른 snap과 동일한 confinement 규칙이 적용됨.

  • 그래서 모델이 사용자의 머신이나 데이터에 무차별적으로 접근하지 않는다는 신뢰를 줄 수 있음.

• 예전에는 LLM의 성능을 제대로 쓰려면 더 큰 파라미터 모델 쪽으로 기울 수밖에 없었음.

• 최근 Gemma 4나 Qwen-3.6-35B-A3B 같은 모델 발전은 상황을 바꾸고 있음.

  • tool-calling 같은 고급 기능을 보여주고,

  • 그 덕분에 LLM이 웹 검색, 외부 API와 파일 시스템 상호작용, 라이브 시스템 트러블슈팅을 수행할 수 있음.

  • 초기 학습 데이터 바깥의 주제도 본격적으로 추론할 수 있게 됨.

• inference snaps의 다음 과제는 스케일 확장임.

  • 최신 모델 출시를 계속 따라가도록 팀을 더 확대할 예정임.

  • 가능한 많은 실리콘 플랫폼에 대해 최적화된 변형도 더 늘릴 것임.

컨텍스트 인지형 운영체제

Ubuntu는 에이전트형 워크플로와 로컬 AI 추론을 신중하게 녹여 넣어, 데스크톱부터 운영 환경까지 더 접근 가능하고 안전한 시스템으로 키우려 함.

• text-to-speech나 향상된 screen reading 같은 기능을 넘어, 사용자들은 이제 에이전트와 함께 일하는 방식에 점점 익숙해지고 있음.

• 지난 몇 년간 Linux가 쌓아 온 성능과 기능을 더 많은 사람이 더 쉽게 쓸 수 있게 된다는 발상이 나는 특히 마음에 듦.

• 우리는 원하는 사용자를 위해 Ubuntu에 에이전트형 워크플로를 어떻게 통합할지 구상 중임.

  • 사용자층에 자연스럽게 맞고, 과하지 않으며, 프라이버시와 보안 원칙을 해치지 않는 방식이 기준임.

• 아직 초기 단계지만, Snaps 기반의 confined packaging 투자와 Ubuntu가 핵심 시스템 기능을 일부 통합해 온 흐름이 이 목표를 안전하게 구현하는 데 큰 도움이 될 게 분명함.

• Linux 데스크톱 생태계는 잘 알려진 대로 파편화돼 있고, 어떤 면에서는 그 파편화 자체가 성공 요인이기도 했음.

  • 오랫동안 많은 똑똑한 사람들이 자기 필요를 해결하려고 뛰어들었고, 그 결과 훌륭한 소프트웨어가 많이 나왔음.

  • 다만 그 조각들을 잘 엮는 일은 늘 어려웠고, 일부 사용자에게는 꽤 답답한 경험으로 이어졌음.

• 시스템 맥락에서 LLM을 신중하게 쓰면, 현대적인 Linux 워크스테이션의 기능을 덜 낯설게 만들고 훨씬 넓은 사용자층까지 확장할 수 있음.

• 이 가능성을 데스크톱에만 묶어 둘 이유는 없음.

  • Ubuntu 머신 여러 대를 운영하는 Site Reliability Engineer (SRE)라면, 사고 대응 중 로그 해석으로 root cause analysis를 더 빠르게 하거나, 엄격한 가드레일 아래 예약된 유지보수 작업을 수행하는 등 LLM이 도울 수 있는 지점이 매우 많음.

• 나는 각 머신 유형에 맞는 인터페이스만 갖춰진다면, 어떤 Ubuntu 머신에서도 자연스럽게 동작하는 기능을 만들고 싶음.

• Site Reliability Engineering의 일부를 에이전트에 위임한다고 해서 반드시 완전히 새로운 종류의 위험이 생기는 것은 아님.

  • 기존 프로덕션 시스템이 이미 갖고 있는 제약을 그대로 물려받아야 함.

• 잘 운영되는 프로덕션 환경은 원래도 엄격한 접근 제어, 감사 추적, 관찰과 실행의 명확한 분리를 전제로 함.

• 내가 바라는 방향은 Ubuntu가 에이전트가 기존 경계 안에서 움직일 수 있도록 필요한 primitive를 드러내는 것임.

  • read-only 분석

  • 작업 실행 시 촘촘하게 제한된 권한

  • 의사결정과 결과 전부를 추적할 수 있는 감사 가능성

• 그래서 과제의 본질은 "에이전트를 믿을 수 있나"보다, 우리가 원래 모든 프로덕션 시스템에 적용하던 가드레일을 같은 수준으로 신뢰할 수 있게 만드는 쪽에 더 가까움.

• Linux 머신에게 Wi-Fi 연결 문제를 직접 진단하게 하거나, 미리 설정되고 보안이 잡혀 있으며 TLS로 접근 가능한 오픈소스 소프트웨어 포지를 세우게 하는 그림도 충분히 가능함.

• 이런 기능은 다른 기기에서 Linux 머신을 제어하는 관문 역할로도 쉽게 이어질 수 있음.

  • 모바일 앱

  • 문자 메시지

  • 음성 명령

  • 그 외 다양한 인터페이스

효율성과 성능

• 로컬 추론 접근성은 어느 정도는 결국 하드웨어 성능에 묶여 있음.

• 우리는 범용 하드웨어에서도 open weight 모델을 쉽게 돌릴 수 있게 최대한 노력하고 있지만, 작은 파라미터 모델은 아직 많은 작업에서 더 큰 모델과 경쟁하기 어려움.

• 나는 이 문제를 대체로 일시적인 격차로 봄.

  • 앞으로도 큰 모델과 작은 모델은 계속 공존할 것임.

  • 더 많은 compute를 가진 쪽이 더 많은 일을 해내는 구조도 계속될 것임.

  • 그래도 그 격차 자체는 점점 줄어들기 시작할 것임.

• 전 세계 실리콘 제조사들이 소비자용 실리콘의 추론 성능을 계속 끌어올리는 데 집중하고 있음.

  • 지금은 frontier AI factory에 접근해야만 가능해 보이는 일도, 앞으로 몇 달에서 몇 년 사이 훨씬 더 쉽게 접근 가능해질 것임.

• 이 논의에서는 성능과 효율을 함께 봐야 함.

• 클라우드의 대형 모델 token/sec와 로컬 머신 수치를 비교하는 건 쉽지만, 이런 워크로드에서 네이티브 가속기의 진짜 장점은 전력 소모도 크게 떨어진다는 점임.

  • 결국 진입 장벽을 다시 낮춰 줌.

• 이 지점에 하루아침에 도달하진 못하겠지만, 실제로 그 시점이 왔을 때 Ubuntu가 준비돼 있길 바람.

• 이를 현실로 만드는 데 silicon partnerships와 enablement 이니셔티브의 역할은 점점 더 중요해지고 있음.

요약

• 2026년 내내 우리는 Ubuntu 사용자가 frontier AI에 접근할 수 있도록 기반을 만들 예정임.

  • 방향은 신중함, 보안, 오픈소스 가치와의 정렬임.

• 엔지니어 교육, resilient system을 구축해 온 기존 경험, 더 강해지고 있는 실리콘 파트너십을 함께 밀어 붙여 다음을 제공하려 함.

  • 효율적인 로컬 추론

  • 강력한 접근성 기능

  • 맥락을 이해해 Ubuntu를 실질적으로 더 유능하게 만드는 OS

• Ubuntu가 AI 제품으로 바뀌는 것은 아님.

• 다만 AI를 신중하게 통합하면 Ubuntu는 더 강한 시스템이 될 수 있음.