비하인드 스토리: Red Hat Enterprise Linux 10 제작 과정(4부)

이 시리즈에서는 Red Hat Enterprise Linux 10을 빌드하고 출시하기 위해 투입된 인력과 계획을 살펴봅니다. 초기 개념 단계부터 Red Hat Summit 2025 출시에 이르기까지 RHEL 10이 탄생하게 된 과정을 직접 확인하실 수 있습니다.

1부 | 2부 | 3부

Red Hat Enterprise Linux (RHEL) 10이 탄생하게 된 과정에 관해, 지난 블로그에서 테스트 프로세스와 주요 기능(및 관련 스토리)이 구체화되는 과정을 살펴보았습니다. 4부에서는 코드 프리즈(code freeze)를 앞두고 다양한 기능을 마무리하는 과정에서 이러한 스토리가 더욱 명확하게 드러납니다.

2025년(Summit 2025까지 6개월)

Brian Stinson, 수석 소프트웨어 엔지니어

"마지막 구간: 이 단계는 개별 팀에게 더욱 치열한 시기입니다. 단순히 기능을 마무리하는 것뿐만 아니라, 릴리스의 일부로 수행해야 했던 나머지 기본 지원 작업을 모두 완료했는지 확인해야 하기 때문입니다. 내 모든 패키지가 포함되었는지, 적절한 일정에 맞춰 QE(품질 검증)를 거쳤는지, 그리고 피드백을 위해 외부에 배포되었는지 등을 점검해야 합니다. 이러한 작업들은 코드 프리즈에 가까워질수록 실제로 훨씬 더 빠르게 증가하게 됩니다.”

Chris Wells, RHEL 사업부 제품 마케팅 수석 디렉터

"저는 이 이야기를 흥미롭게 전달해야 한다는 점을 알고 있었습니다. 이번 릴리스에 포함될 기능을 바꿀 수는 없었지만, 해당 기능을 설명하는 방식은 바꿀 수 있었습니다.

그래서 저는 이곳 콜럼버스에서 RHEL 10의 리드 제품 마케팅 매니저인 Marty Loveless, 그리고 한두 시간 거리인 애크런에 사는 Scott McCarty와 회의를 가졌습니다. 그는 당일 회의를 위해 왔습니다. 우리는 회의실에서 '이야기를 풀어나갈 수 있는 다양한 관점에는 무엇이 있을까?'’를 계속 브레인스토밍했습니다. 새로 나온 무언가를 바라보면서, 과연 다른 각도로 풀어낼 방법이 있는지 찾으려고 했던 거죠.”

Major Hayden, 수석 소프트웨어 엔지니어

"엔지니어링 측면에서는 저와 다른 한 명의 Red Hatter가 함께 코드를 만들었고, 그래서 업무를 나눠서 진행했습니다. 가장 큰 과제는 RAG(검색 증강 생성, Retrieval Augmented Generation)였습니다. 처음에는 ‘PDF를 한곳에 넣어두면, 그냥 검색하면 되겠지’라고 단순하게 생각했습니다. 하지만 그건 전혀 맞지 않았습니다.

당시 겪었던 많은 어려움은 다음과 같은 이유에서 비롯되었습니다. 우리 중 많은 이들이 벡터를 다루는 것이 처음이었다는 사실입니다. 학창 시절 미적분학을 배웠기 때문에 벡터가 데카르트 평면 위의 선이라는 점은 알고 있었지만, 아는 것은 그게 전부였습니다. 그런데 문장이 어떻게 벡터로 바뀌는지 전혀 이해가 되지 않았습니다. 그래서 결국 어느 날 시간을 내서 미적분을 다시 공부하면서 “이게 실제로 무슨 일을 하는 건가?”를 이해하려고 했습니다.

그리고 가장 큰 문제는 결과 품질이 충분히 좋지 않았다는 점이었습니다. 

그러던 중 누군가가 “LLM에게 사용자의 질문을 더 정제(refine)해보라”는 블로그 글이나 자료를 읽게 되었습니다. 결국 저희는 고객으로부터 받은 질문을 LLM에 전송하는 질문 정제(question refinement) 프로세스를 만들었습니다. 사용자의 질문을 먼저 받아서 LLM에 전달하고, 이렇게 요청했습니다: “이 질문은 RHEL이나 Red Hat 제품, 또는 Linux와 관련된 내용일 가능성이 높습니다. 이 질문을 5개의 더 구체적인 질문으로 바꿔주고, 관련 키워드를 포함해 주세요.” 예를 들어 사용자가 “SSH no restart”라고만 입력하면, 질문 정제 과정에서는 이를 더 구체적인 문장과 키워드로 변환합니다. 이렇게 하면 RAG 콘텐츠 안에 더 잘 등장하는 표현으로 바뀌게 됩니다. 그 결과 벡터 검색이 더 많은 문서와 매칭되기 시작했고, 결국 검색 결과 품질이 눈에 띄게 개선되는 것을 확인할 수 있었습니다.”

Wells

"시장에서 Red Hat만의 고유한 차별화 요소인 RHEL용 Linux에 관한 모든 지식과 전문성을 제품화하여, Lightspeed를 통해 어시스턴트 형태로 제공할 수 있게 되었습니다. 덕분에 RHEL 10에 대해 매우 강력하게 어필할 수 있는 방안이 마련되었습니다."

Stef Walter, Linux Engineering 수석 디렉터

"이름만 대면 알 만한 대기업을 포함한 모든 고객이 이미지 모드가 공식 지원되기도 전에 이를 배포하고 있었습니다. 고객들은 '정말 훌륭하네요, 지원 여부는 상관없습니다. 지금 바로 배포하겠습니다'라고 말했습니다."

실제로 실감하게 된 계기는 '아, 고객들이 우리를 기다리지 않고 프로덕션 환경에 바로 배포하고 있구나'라는 사실을 깨달았을 때였습니다. 이미지 모드는 고객의 IT 프로세스와 추진 중인 변화에 매우 가치 있는 것이어서, 고객들은 우리를 기다려 주지 않을 것입니다. 이제 우리가 그 속도를 따라잡아야 합니다."

Wells

"이미지 모드에 관해 매우 강력한 이야기를 나눌 수 있었습니다. 그래서 '이미지 모드를 시스템 패치 및 업데이트를 위한 새로운 방식으로 설명하면 어떨까?'라고 생각했습니다." 지난 1년 동안은 이미지 모드를 주로 새로운 시스템과 이미지, 그리고 엣지 배포를 위한 방식으로 설명해 왔습니다. 이것도 물론 완전히 타당하고 좋은 접근이었습니다. 

하지만 저희는 '여기서 한 단계 더 나아가면 어떨까?'라고 자문했습니다. 단순히 엣지에 배포하는 것을 넘어, 프로덕션 서버의 이미지를 그대로 생성하여 불변(immutable) 상태로 만든 다음 배포하는 방식은 어떨까요?" 따라서 해당 서버를 업데이트해야 할 때마다 이미지를 업데이트하고 시스템을 다시 이미지화하기만 하면 됩니다. 이는 새로운 배포 방식이 될 것입니다. 이러한 방식을 적용하면 Linux 시스템 관리에서 가장 까다로운 작업 중 하나인 패치 적용의 번거로움을 해결할 수 있습니다. 이미지 모드를 통해 패치 관리를 수행하면 기존의 패키지 방식보다 훨씬 쉽고 빠르며 위험성도 낮기 때문입니다.

이제 Summit 2025에서 Red Hat Enterprise Linux 10이 출시될 예정입니다. 가장 쉬운 단계라고 할 수 있죠. 그렇지 않나요? 팀이 실제 출시 메커니즘과 프로세스를 안내해 드릴 2026년 다음 게시물을 기대해 주시기 바랍니다.