커널 패치 작성 및 제출 과정

커널 패치를 작성하고 제출하는 일은 단순히 '코드를 고치는 것' 그 이상이에요. 오픈소스 커뮤니티와 직접 소통하고, 내 코드를 전 세계 개발자들과 공유하면서, 진짜 리눅스 커널의 발전에 기여하는 멋진 경험이죠. 그런데 처음 도전할 땐 어디서부터 시작해야 할지 막막하고, 실수할까 두려운 마음이 드는 것도 너무나 자연스러운 일이에요. 저도 첫 패치 제출할 때 머릿속이 새하얘졌던 기억, 아직도 생생합니다. "이거 잘못 보내면 욕먹는 거 아니야?" 이런 걱정, 다들 해보셨죠?

이 글에서는 커널 패치 작성의 기본 원칙부터, 실전 커밋 메시지 작성법, git을 활용한 패치 생성과 관리, 메일링 리스트 제출, 리뷰 대응, 코딩 스타일과 테스트까지, 실제로 바로 따라할 수 있게 단계별로 안내할 예정이에요. 중간중간 실수담, 자주 하는 실수와 해결법, 그리고 실무에서 바로 쓸 수 있는 명령어 예시도 빼놓지 않을게요. 읽고 나면, 여러분도 주저하지 않고 자신 있게 오픈소스 커널 프로젝트에 기여할 수 있을 거예요. 완벽하지 않아도 괜찮으니, 함께 한 걸음씩 나아가 봅시다!

목차

1. 커널 패치 작성의 기본 개념
2. 커밋 메시지 규칙과 작성법
3. git을 활용한 패치 생성 및 관리
4. 메일링 리스트를 통한 제출 및 리뷰 프로세스
5. 코딩 스타일과 테스트 요구사항 준수
6. 실제 사용 사례로 배우는 패치 작성
7. 주요 이슈와 해결 방안

커널 패치 작성의 기본 개념

커널 패치, 도대체 뭘까요? 저도 처음엔 "커널 패치가 뭐길래 다들 어렵다고 하지?" 싶었는데, 막상 해보니 신경 쓸 게 정말 많더라고요. 한 번 경험해보면, 단순히 코드 고치는 게 아니라는 걸 바로 알게 됩니다.

커널 패치란?

쉽게 말해, 리눅스 커널 소스 코드에 버그를 고치거나, 기능을 추가하거나, 성능을 개선할 때 작성하는 코드 변경사항이에요. 그런데 중요한 건, 이게 단순히 코드를 고치는 걸 넘어서, 커널의 안정성과 호환성을 지키는 게 핵심이라는 점이죠.

예를 들어, 버그 하나 고치려고 코드를 바꿨는데, 그게 다른 하드웨어나 드라이버에 영향을 줄 수도 있어요. 저도 실제로 너무 성급하게 코드를 바꿨다가, 엉뚱한 곳에서 에러가 터진 적이 있었어요. "이거 왜 갑자기 안 되지?" 하면서 3시간 날린 적도 있습니다. 여러분도 비슷한 경험 있으시죠?

패치 작성의 3대 원칙

1. 최소한의 변경만 포함
   "이왕 고치는 김에 여기저기 같이 손보자!" 했다가 패치가 커지고, 리뷰어한테 "이거 너무 범위가 넓다"는 피드백 받는 건 진짜 흔한 실수입니다.
   → 한 패치에는 하나의 논리적 변경만!

2. 코딩 스타일 준수
   리눅스 커널에는 엄격한 코딩 스타일 가이드가 있어요.
   scripts/checkpatch.pl 스크립트로 자동 검사도 가능하니, 꼭 돌려보세요.
   (저는 이거 안 돌리고 제출했다가, 스타일 지적만 10개 넘게 받은 적도 있어요.)

3. 충분한 테스트
   바꾼 코드가 진짜 문제없는지, 영향을 주는 모듈이나 하드웨어에서 꼭 확인해야 해요.
   가상머신에서 테스트하다가 실제 장비에서만 나는 버그, 저도 여러 번 겪었습니다.

커밋 메시지, 왜 중요할까?

"커밋 메시지가 그렇게 중요한가요?" 네, 정말 중요합니다.
커널 개발에서는 커밋 메시지가 곧 내 패치의 의도와 신뢰도를 보여주는 증거거든요.

• 제목(Subject): 50자 이내, 간단명료하게
• 본문(Body): 변경 이유, 상세 설명, 관련 이슈 링크
• Signed-off-by: 책임 소재 명확히 (이거 없으면 패치 거절될 수도 있어요!)

저는 처음에 이 부분 빼먹어서 다시 제출했던 기억이 아직도 생생합니다.

핵심 용어

• 패치(Patch): 소스 코드의 변경사항을 담은 파일. diff 형식으로 작성.
• Signed-off-by: 패치 작성자가 해당 코드에 책임을 진다는 의미의 서명.
  공식 설명

💡 실무 팁

• 패치 작성 후 반드시 scripts/checkpatch.pl로 코딩 스타일 점검!
• 한 패치에는 하나의 논리적 변경만. 여러 변경사항은 별도 패치로 분리.
• 커밋 메시지에 변경 이유와 영향을 받는 부분을 명확히 기술.

커밋 메시지 규칙과 작성법

커밋 메시지, 그냥 대충 써도 되는 거 아니냐고요? 저도 그렇게 생각했다가, 커널 패치 작업하면서 메시지 하나로 신뢰를 얻거나, 반대로 괜히 오해받는 경우를 수도 없이 겪었습니다. "이 커밋 뭐지?" 하면서 혼란스러웠던 경험, 다들 있으시죠?

커밋 메시지, 왜 이렇게 써야 할까요?

커널 개발에서는 작은 실수 하나도 시스템 전체에 영향을 줄 수 있어서, 커밋 메시지를 엄격하게 관리해요.
제목(Subject)과 본문(Body)을 구분해서 써야 하고, 각 부분마다 지켜야 할 규칙이 있습니다.

1. 제목(Subject) 작성법

• 50자 이내로 요약
  너무 길면 한눈에 안 들어오잖아요.
• 첫 글자는 대문자, 마침표는 생략
  예시:

  Fix memory leak in device driver
  

  (마침표 빼는 이유, 저도 처음엔 몰랐는데, 짧고 임팩트 있게 하려고 그렇대요.)

2. 본문(Body) 작성법

• 제목과 한 줄 띄우기
  깜빡해서 에러난 적, 한두 번이 아니에요.
• 72자 이내로 줄 바꿈
  한 줄이 너무 길면 읽다 지치죠.
• 변경 이유와 영향, 문제 해결 방식 구체적으로
  예시:

  The previous implementation caused a memory leak whenever
  the device was removed. This patch ensures proper cleanup
  by releasing allocated memory in the remove callback.
  
  Fixes: #123
  

• 관련 이슈 번호, 참고 링크 넣기
  협업할 때 정말 편해요.

3. Signed-off-by 태그 꼭 추가하기

이 태그는 “내가 이 코드에 책임진다”는 의미예요.
작성법은 아래처럼:

git 커맨드로는 이렇게 간단하게 처리돼요:

이거 안 넣고 PR 올렸다가, “Signed-off-by 누락”으로 반려된 경험… 아마 다들 있으실걸요?

규칙 안 지키면 어떤 문제가?

실제로 메시지 규칙 무시하고 커밋했다가, 코드가 두 번이나 리뷰에서 반려된 적이 있었습니다.
이유는 딱 하나, “무슨 변경인지 읽는 사람이 이해가 안 된다”는 거였죠.
이렇게 되면 코드 히스토리 추적이 힘들어지고, 나중에 버그 찾을 때도 정말 고생해요.
특히 여러 팀이 동시에 커널 패치에 기여하는 환경에서는, 명확한 커밋 메시지가 협업의 기본이 된다는 거, 절대 잊으면 안 됩니다.

잠깐, 여기까지 정리할게요.

• 제목(50자 이내, 대문자 시작, 마침표 X)
• 본문(72자 이내 줄바꿈, 상세 설명)
• 마지막에 Signed-off-by 태그

이 세 가지 꼭 지키세요.
실수하면 리뷰에서 시간만 더 걸리니까, 처음부터 습관들이는 게 진짜 중요해요!
아직 저도 배우는 중이지만, 같이 천천히 익혀나가요 :)

참고 링크
커널 커밋 메시지 작성 가이드

💡 실무 팁

• 커밋 메시지 제목은 50자를 넘기지 말고, 본문은 72자 단위로 줄 바꿈!
• git commit -s 옵션을 사용해 Signed-off-by 태그 자동 추가.
• 본문에는 변경 이유와 영향을 명확히, 관련 이슈 번호도 꼭 포함.

git을 활용한 패치 생성 및 관리

이제 git을 활용한 패치 생성과 관리, 실전으로 들어가 볼까요?
저도 처음엔 이게 뭐가 이렇게 복잡해 보였는지, 한참 헤맸어요.
근데 단계별로 따라가보면 생각보다 어렵지 않아요.
실제로 실수도 여러 번 했었고요.
여러분이 저처럼 헤매지 않도록, git 명령어 중심으로 패치 생성부터 제출, 관리 노하우까지 쭉 풀어볼게요.

1. 패치 파일 만들기 – git format-patch

커널이나 오픈소스 프로젝트에 기여할 때, 변경사항을 한 번에 보내는 게 아니라
각 커밋별로 패치 파일을 만들어서 메일로 보내는 경우가 많아요.
여기서 바로 git format-patch를 씁니다.

예시: 내 브랜치에서 origin/master 이후로 작업한 커밋을 모두 패치로 만들고 싶다면?

이렇게 하면

• 0001-...patch, 0002-...patch
  이런 식으로 번호가 붙은 패치 파일이 만들어집니다.
  각 파일에는 커밋 메시지, diff, 그리고 메타데이터가 다 들어가 있어요.

패치 파일이란?
커밋 하나당 파일 하나! 각 패치가 독립적으로 리뷰될 수 있게 만드는 거죠.

실수 경험:
커밋을 squash 안 하고 패치 만들었다가, 의도치 않은 커밋까지 포함돼서 다시 만들었던 적 있어요.
꼭 필요한 커밋만 패치에 들어갔는지
git log로 한 번 더 확인하는 거, 잊지 마세요!

2. 패치 보내기 – git send-email

패치를 만들었으면 이제 메일로 보내야겠죠?
여기서 git send-email이 등장합니다.

예시:

여러 개의 패치를 한 번에 보내고 싶으면,
*.patch로 여러 파일을 지정하면 돼요.

Tip:
SMTP 서버 세팅 때문에 고생한 적 많으시죠?
~/.gitconfig에 아래처럼 설정해두면 편해요.

중요:
메일 제목, 수신자(to/cc), 그리고 서명자(Sign-off-by) 같은 메타데이터를 꼭 확인하세요.
이게 빠지면 리뷰어가 패치를 무시하거나, 다시 보내달라고 할 수도 있습니다.

참고 링크
git send-email 공식 문서

3. 패치 관리 – 유의사항과 실전 팁

패치 순서 잘못 보내서 리뷰어한테 "순서가 이상해요"라는 답변 받은 적, 저만 그런 거 아니죠? 😂
정확한 순서와 메타데이터 관리가 핵심입니다.

• 서명자(Sign-off-by)
  커밋할 때 꼭 git commit -s 옵션으로 서명 추가!
• 패치 수정
  이미 보낸 패치를 고쳐야 한다면
  git commit --amend로 수정하고,
  다시 git format-patch로 패치 파일을 만든 뒤
  아래처럼 보냅니다.

정리!

• 패치 번호 꼬이면 안 됨
• In-Reply-To 헤더 유지 필수 (메일 스레드 연결)
• 커밋 메시지에 서명 누락하지 않기

실제로 In-Reply-To 안 넣고 보냈다가
스레드가 분리돼서 리뷰어가 "뭐가 최신 버전이냐" 혼란스러워했던 적이 있어요.

아직 저도 배우는 중이고,
실수하면서 하나씩 익혔던 부분이 많아요.
여러분도 너무 겁먹지 마시고,
실제로 손으로 패치 만들어보고 메일로 보내보는 경험이
진짜 가장 큰 공부가 됩니다!
궁금한 점 생기면 댓글로 남겨주세요 :)

💡 실무 팁

• 패치 생성 시 반드시 커밋 메시지에 'Signed-off-by' 라인 포함!
• 여러 패치 보낼 땐 순서 유지, 각 패치가 독립적으로 적용 가능하도록 커밋 세분화.
• git send-email 사용 전 SMTP 설정과 메일 포맷(특히 In-Reply-To 헤더)이 커널 메일링리스트 요구사항에 맞는지 테스트!

메일링 리스트를 통한 제출 및 리뷰 프로세스

메일링 리스트, 처음엔 진짜 낯설죠? 저도 커널에 패치 하나 올려보려고 했을 때, 메일링 리스트라는 게 너무 생소해서 부담스러웠어요. 한국 개발 문화에서는 흔히 쓰는 방식이 아니라 더더욱 헷갈렸던 것 같아요.

1. 메일링 리스트 가입과 규칙 숙지

먼저, 관련 메일링 리스트에 꼭 가입해야 해요.
예를 들어, 네트워크 드라이버 패치라면 netdev@vger.kernel.org 같은 리스트에 들어가야 하죠.
가입 방법은 각 리스트 웹페이지나 README에 잘 나와 있으니 참고!
중요한 건 각 리스트마다 엄격한 규칙이 있다는 거예요.

• 제목 형식: [PATCH v1] ... 처럼 버전과 목적을 명확히
• 커밋 메시지: 변경 이유, 해결되는 문제, 테스트 결과 등 상세히

저는 처음엔 일반 메일처럼 보냈다가, 제목 형식 안 맞는다고 리턴당한 적도 있습니다.

참고 링크
커널 메일링 리스트 가이드

2. 패치 제출 시 유의사항

패치 제출에는 보통 git send-email 명령어를 써요.
처음엔 이 커맨드도 낯설었는데, 익숙해지면 생각보다 편하더라고요.

• 메일 본문에 꼭 포함해야 할 것
  • 커밋 메시지
  • 변경 요약
  • 테스트 결과
  • 알고 있는 이슈

설명을 너무 간단히 썼다가, "이거 왜 이렇게 했냐"는 피드백 폭탄 맞은 적도 있어요.
여기선 메일로 모든 걸 설명해야 하니, 조금 더 신경 써야 합니다.

3. 리뷰 피드백 대응법

리뷰가 들어오기 시작하면 어떻게 해야 할까요?
커널 개발자들은 메일로 인라인 코멘트(본문 중간중간에 직접 답변)로 피드백을 줍니다.

• 모르는 건 꼭 물어보세요!
  저도 "이걸 물어봐도 되나?" 고민했는데, 오히려 바로 물어보는 게 더 신뢰를 쌓는 방법이더라고요.
• 피드백 반영해서 패치 다시 보낼 때
  • 제목에 v2, v3처럼 버전 넘버 붙이기
  • 메일 본문에 "지난번 리뷰에서 ~를 반영했다"는 식으로 상세히 적기

예시:

4. 커뮤니케이션 태도

메일링 리스트는 완전히 공개되고, 기록이 다 남아요.
실수도, 질문도, 전부 남죠.
저는 이게 부담이라 조심스러웠는데, 사실 다들 실수하면서 배우는 거더라고요.

• 무례하지 않게, 솔직하게, 그리고 성실하게 대응!
• 이런 태도가 쌓이면, 커널 커뮤니티에서 신뢰를 얻고, 나중엔 패치도 더 잘 받아들여집니다.

아직 저도 배우는 중이지만, 이 과정 하나하나가 진짜 성장의 발판이 되는 것 같아요.
혹시 메일링 리스트에서 겁먹거나 실수해본 분들, 비슷한 경험 있으시면 댓글로 공유해 주세요!
우리 같이 배우면서 성장해봐요 :)

💡 실무 팁

• 메일링 리스트에 패치 보낼 때는 'Signed-off-by' 라인 꼭 포함!
• 피드백 받을 때는 방어적으로 대응하지 말고, 리뷰어 의견을 객관적으로 수용.
• 패치 버전 올릴 땐 제목에 v2, v3 등 명확히 표시, 변경 사항 요약을 메일 본문 상단에 작성.

코딩 스타일과 테스트 요구사항 준수

커널 기여에서 정말 중요한 두 가지—코딩 스타일과 테스트 요구사항—제대로 짚고 넘어가 볼까요?

솔직히, 저도 처음에 리눅스 커널 코딩 스타일 가이드라인을 봤을 때 "이 정도까지 엄격해야 하나?" 싶었어요. 근데 직접 패치 제출해보면, 왜 그렇게까지 하라고 하는지 알게 됩니다.

• 코딩 스타일
  • 들여쓰기는 탭(tab)으로만!
  • 한 줄은 80자 넘기면 안 됨
  • 변수명, 함수명 컨벤션 철저
  • 주석 처리 방식 통일

실수로 스페이스 섞어서 들여쓰기 했다가, 코드 리뷰에서 바로 반려당했던 기억이 있네요.

꼭 해야 할 것:
패치 작성 끝나면 scripts/checkpatch.pl 스크립트로 스타일 자동 검사!
이거 안 하면, 코드 제출해도 바로 튕깁니다.

테스트 요구사항

커널 패치는 단순히 코드만 올린다고 끝이 아니에요.
실제로 동작하는지, 다른 부분에 영향은 없는지 꼭 검증해야 합니다.

• QEMU로 가상머신 환경 만들어서 빌드&부팅 테스트
• 실제 하드웨어 테스트가 가능하면 더 좋음
• 커널에 기본 탑재된 kselftest 프레임워크로 기능별 자동화 테스트

예를 들어, 파일 시스템 관련 패치라면, 그 부분과 연관된 kselftest 스크립트를 실행해서 정상 동작하는지 확인하는 거죠.
테스트 과정 없이 코드를 병합하면, 나중에 시스템 크래시나 데이터 손상 같은 무서운 문제가 생길 수 있어요.
테스트 빠뜨렸다가, 나중에 버그 터져서 욕먹는 경우도 봤습니다.

실전 팁!
패치 제출할 때, 테스트 결과 로그나 간단한 설명도 같이 첨부해보세요.
"이렇게 테스트했고, 문제 없었습니다"라고요.
관련 테스트 코드도 같이 올리면 더 신뢰받습니다.

아직 저도 배우는 중이지만, 이 과정 거치면서 코드 품질이 훨씬 좋아졌다고 느끼고 있어요.
"이 정도면 됐겠지" 했다가 예상치 못한 에러 만난 적, 저만 그런 거 아니죠?
커널 기여는 꼼꼼함이 진짜 생명입니다.

💡 실무 팁

• 패치 제출 전 반드시 scripts/checkpatch.pl로 코딩 스타일 점검!
• QEMU 가상 머신 환경을 구축하면 다양한 아키텍처에서 손쉽게 테스트 가능.
• kselftest 프레임워크로 자동화된 테스트 작성, 패치와 함께 제출하면 리뷰어가 쉽게 검증 가능.

실제 사용 사례로 배우는 패치 작성

실제 사례를 보면 이해가 확 달라지죠?
여기, 제가 겪었던 실제 커널 패치 작성 과정을 단계별로 정리해볼게요.

1. 버그 발견 및 이슈 정리

• 증상: 네트워크 드라이버에서 특정 상황에 메모리 누수 발생
• 관련 코드 위치: drivers/net/ethernet/example.c
• 재현 방법: 특정 패킷을 반복 전송

2. 코드 분석 및 수정

• 원인 분석: remove() 콜백에서 할당한 메모리 해제 누락
• 코드 수정: kfree() 추가

3. 커밋 메시지 작성 예시

4. 패치 파일 생성

5. 패치 제출

6. 리뷰 대응

• 리뷰어: "테스트 결과 로그 첨부해 주세요."
• 대응: QEMU에서 테스트 로그 캡처, 메일로 첨부

7. 패치 수정 및 재제출

• 피드백 반영 후 git commit --amend
• git format-patch -v2 origin/master
• git send-email --to=netdev@vger.kernel.org --subject-prefix="PATCH v2" --in-reply-to=<이전메일ID> 0001-net-example-Fix-memory-leak-in-remove-callback.patch

실패담:
처음엔 커밋 메시지에 Signed-off-by 빼먹고,
테스트 로그도 안 올려서 두 번이나 반려당했어요.
"이거 왜 이렇게 복잡해?" 싶었는데,
한 번 익히고 나니 다음부터는 훨씬 수월했습니다.

주요 이슈와 해결 방안

커널 패치 작업하다 보면 자주 만나는 문제들, 그리고 해결법을 정리해볼게요.

1. 커밋 메시지 규칙 위반

• 문제: 제목 길이 초과, 마침표 사용, Signed-off-by 누락 등
• 해결: 커밋 메시지 템플릿 만들어두고, git commit -s 습관화

2. 패치 파일에 불필요한 커밋 포함

• 문제: squash 안 하고 패치 만들어서, 의도치 않은 커밋까지 포함
• 해결: git rebase -i로 커밋 정리 후 git format-patch

3. 메일링 리스트 제출 오류

• 문제: 제목 형식 오류, In-Reply-To 누락, SMTP 설정 문제
• 해결: 제출 전 메일 미리보기(git send-email --dry-run), 메일링 리스트 규칙 재확인

4. 리뷰 피드백 반영 누락

• 문제: 리뷰어가 지적한 부분 반영 안 하고 재제출
• 해결: 피드백 받은 내용 체크리스트로 정리, 반영 내역을 메일 본문에 명확히 작성

5. 코딩 스타일/테스트 미준수

• 문제: checkpatch.pl 미실행, 테스트 누락
• 해결: 패치 제출 전 자동화 스크립트로 스타일/테스트 점검

마무리

지금까지 커널 패치 작성의 기본 개념부터 커밋 메시지 작성, git을 이용한 패치 관리, 메일링 리스트 제출과 리뷰, 코딩 스타일 준수, 실제 사례, 그리고 자주 발생하는 이슈와 해결법까지 살펴봤습니다.
이 과정을 통해 여러분은 단순히 코드를 작성하는 것에서 한 걸음 더 나아가, 오픈소스 커뮤니티와 소통하며 성장할 수 있는 실질적인 역량을 갖추게 되었습니다.

이제 작은 수정이라도 직접 커널 코드를 분석하고, 패치를 만들어 제출하는 경험에 도전해보세요.
여러분의 도전이 리눅스 커널 발전의 한 축이 될 수 있습니다.
"완벽하지 않아도 괜찮아요!"
지금 바로 첫 번째 커널 패치, 도전해보시겠어요?

📚 참고자료 및 추가 학습

공식 문서

• The Linux Kernel Patch Submission Process
• Linux Kernel Newbies: How to Submit a Patch
• Submitting Patches to the Linux Kernel Mailing List

튜토리얼

• 📄 Linux Kernel Development Tutorial: How to Write and Submit a Patch
• 🎥 How to Contribute to the Linux Kernel (Video)
• 📄 Linux Kernel Patch Submission Workflow

유용한 도구

• 🔧 git - 커널 소스 코드 버전 관리 및 패치 생성
• 🔧 patch - 패치 파일 적용 및 생성
• 🔧 checkpatch.pl - 커널 코딩 스타일 검사 도구
• 🔧 scripts/get_maintainer.pl - 담당 메인테이너 이메일 자동 조회

커뮤니티

• 🌐 Linux Kernel Mailing List (LKML)
• 💭 Kernel Newbies
• 🟠 r/kernel

🔗 관련 주제

• 커널 소스 코드 구조와 빌드 시스템 이해
• git을 활용한 소스 코드 관리
• 커널 코드 스타일과 패치 작성 규칙
• 메일링 리스트를 통한 패치 제출과 리뷰 프로세스
• 커널 디버깅 및 테스트 기법

📈 다음 단계

1. 실제 커널 패치 작성 및 제출 경험 쌓기
2. 자신만의 리눅스 커널 모듈 작성 및 오픈소스 프로젝트에 기여
3. 정기적으로 커널 메일링 리스트 구독 및 리뷰 활동 참여
4. 커널 보안 패치 및 취약점 분석 활동

휴, 복잡하죠? 천천히 다시 보셔도 괜찮아요.
실수해도 괜찮으니, 직접 해보면서 익혀가면 어느새 여러분도 커널 개발자!
궁금한 점, 실패담, 성공담 모두 댓글로 남겨주세요.
함께 배우고 성장하는 그날까지, 파이팅입니다! 🚀