Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며

앞의 일곱 편은 읽고, 빌드하고, 관측하고, 모듈을 쓰는 이야기였습니다. 마지막 편은 그 결과를 밖으로 내보내는 이야기입니다.

여기서 한 가지를 먼저 말해두는 게 정직할 것 같습니다. 첫 패치에서 어려운 부분은 대개 코드가 아닙니다. 한 줄을 고치는 패치도, 처음 보내면 형식 때문에 되돌아옵니다. 그리고 그 형식은 누군가의 취향이 아니라 커널 트리 안에 문서로 들어 있습니다.

이 글에 나오는 규칙은 전부 커널 공식 문서 Documentation/process/submitting-patches.rst에서 확인한 것입니다. 기억이 아니라 문서를 근거로 적었고, 인용한 문구는 그대로 옮겼습니다.

1. 보내기 전에 돌리는 두 스크립트

커널 트리에는 제출 전에 돌려야 할 스크립트가 두 개 있습니다. 둘 다 scripts/ 아래에 있습니다.

checkpatch.pl — 형식 검사

scripts/checkpatch.pl 0001-my-change.patch

공백, 줄 길이, 괄호 위치, 금지된 함수, 커밋 메시지 형식 등을 검사합니다. 첫 패치가 반려되는 사유 중 상당수가 여기서 미리 잡힙니다.

다만 문서는 이 도구의 위치를 분명히 정해둡니다 — 스타일 검사기는 "가이드로 볼 것이며, 사람의 판단을 대체하는 것이 아니다"라고 명시돼 있습니다. checkpatch가 지적했지만 고치지 않는 것이 맞는 경우도 있고, checkpatch가 통과시켰지만 리뷰어가 지적하는 경우도 있습니다. 통과가 승인은 아닙니다.

get_maintainer.pl — 받는 사람 결정

scripts/get_maintainer.pl 0001-my-change.patch

패치 파일 경로를 인자로 주면, 그 코드를 책임지는 사람과 관련 메일링 리스트를 알려줍니다. 근거는 트리 최상위의 MAINTAINERS 파일입니다.

이 단계를 건너뛰면 패치가 아무도 보지 않는 곳으로 갑니다. 커널에는 단일한 접수 창구가 없고, 서브시스템마다 유지보수자와 리스트가 다릅니다. 어디로 보낼지는 추측할 것이 아니라 스크립트에 물어볼 것입니다.

2. Signed-off-by — 필수이고, 저작권 양도가 아닙니다

모든 패치에는 서명 태그가 필요합니다. 형식은 정확히 이렇습니다.

Signed-off-by: Random J Developer <random@developer.example.org>

git commit -s를 쓰면 설정된 이름과 이메일로 자동 삽입됩니다.

이 태그가 무엇을 뜻하는지는 오해가 흔합니다. 저작권을 넘긴다는 서명이 아닙니다. 문서에 따르면 이것은 개발자 원본 증명서 1.1, 곧 Developer's Certificate of Origin 1.1의 조건을 충족한다는 증명입니다. 요지는 "이 코드를 제출할 권리가 나에게 있다"는 진술입니다 — 내가 썼거나, 적합한 라이선스의 코드를 기반으로 했거나, 그런 사람에게서 받아 형식을 바꾸지 않고 전달한다는 것.

즉 법적 진술이므로, 남의 코드를 옮겨 붙이고 서명하는 것은 형식 위반이 아니라 거짓 진술입니다.

3. 커밋 메시지의 구조

문서가 정해둔 순서가 있습니다.

제목 줄 — [PATCH] 접두사
From: 줄 — 보내는 사람과 작성자가 다를 때만
설명 본문 — 75열에서 줄바꿈
빈 줄
Signed-off-by: 등의 태그
--- 표시 줄
체인지로그에 남기지 않을 추가 코멘트
실제 diff

6번 --- 줄이 실무에서 가장 유용한 장치입니다. 그 아래에 쓴 내용은 커밋 히스토리에 들어가지 않습니다. 그래서 "v2에서 이 부분을 이렇게 바꿨습니다", "이 접근을 골랐고 다른 방법은 이래서 버렸습니다" 같은 리뷰어용 메모를 여기에 씁니다. 영구 기록에 남을 설명은 위에, 이번 리뷰에만 필요한 말은 아래에 — 이 구분이 커널 커밋 로그를 읽을 만하게 유지합니다.

75열은 임의의 숫자가 아닙니다. 메일 클라이언트에서 인용 부호(> )가 붙어도 80열을 넘지 않게 하려는 값입니다. 다음 절과 이어지는 이유입니다.

4. 왜 첨부가 아니라 본문인가

문서의 표현은 명확합니다 — "모든 패치는 이메일 '인라인'으로 제출되어야 한다". MIME 첨부나 압축 파일은 받아들여지지 않고, git send-email이 강력히 권장된다고 적혀 있습니다.

git send-email --to=maintainer@example.org --cc=linux-kernel@vger.kernel.org 0001-my-change.patch

첨부를 금지하는 이유는 리뷰 방식에 있습니다. 커널 리뷰는 GitHub의 웹 UI가 아니라 메일에서 일어납니다. 리뷰어는 답장에서 패치의 특정 줄을 인용하고 그 아래에 코멘트를 답니다. 패치가 첨부 파일이면 그 인용이 불가능합니다.

이것이 3절의 75열과 연결됩니다. 인용될 것을 전제로 한 형식인 겁니다.

여러 개의 패치를 묶어 보낼 때는 커버 레터를 붙여 전체 변경과 그 이유를 설명합니다.

5. 리뷰 — 그리고 답하지 않으면 무시당합니다

문서에 이례적으로 직설적인 문장이 있습니다.

"당신은 그 코멘트들에 답해야 한다. 리뷰어를 무시하는 것은 자기가 무시당하는 좋은 방법이다."

첫 기여자가 가장 많이 오해하는 부분입니다. 리뷰가 무뚝뚝하게 오면 거절로 읽히지만, 대개는 거절이 아니라 작업 지시입니다. 서브시스템 유지보수자는 하루에 수십 개의 패치를 보고, 문장을 다듬을 시간이 없습니다. 짧은 답장은 감정이 아니라 처리량의 결과입니다.

그리고 다시 보낼 때는 이전 버전과 무엇이 달라졌는지 패치 체인지로그를 붙입니다. 4절에서 말한 --- 아래가 그 자리입니다. 리뷰어가 v1을 기억하고 있을 것이라 기대하지 않는 게 맞습니다.

6. 첫 패치로 무엇을 고를까

정직하게 적자면, 첫 패치의 목표는 코드가 아니라 절차를 통과해 보는 것입니다. 그래서 크기가 작고 논쟁의 여지가 없는 것이 좋습니다.

현실적인 후보는 이런 것들입니다.

문서의 사실 오류. 코드와 문서가 어긋난 곳. 읽다가 발견하게 되고, 검증이 쉽습니다.
checkpatch가 지적하는 실제 문제. 다만 스타일만 바꾸는 대량 패치는 환영받지 못하는 경우가 많습니다 — git blame을 망치고 리뷰 비용만 발생시키기 때문입니다. 고치는 이유를 설명할 수 있는 것만 고르세요.
자기가 겪은 버그. 이게 가장 좋습니다. 재현 방법을 아는 사람이 쓴 패치는 설명이 구체적입니다.

반대로 첫 패치로 피하는 게 좋은 것: 서브시스템의 설계 방향에 대한 제안, 여러 파일에 걸친 리팩터링, 성능 개선 주장. 셋 다 코드보다 합의가 어렵습니다.

이 글이 다루지 않는 것

서브시스템별 관례. 각 서브시스템은 자체 규칙과 트리, 머지 창을 갖습니다. 이 글은 공통 절차까지만 다룹니다.
b4 같은 최신 도구. 패치 시리즈 관리를 돕는 도구가 있고 점점 표준에 가까워지고 있지만, 이 글에서 직접 사용해 확인하지 않았으므로 자세히 쓰지 않았습니다.
메일 클라이언트 설정. git send-email의 SMTP 설정은 환경마다 다르고, 잘못 설정하면 조용히 형식이 깨진 메일이 나갑니다. 자기 자신에게 먼저 보내 확인하는 절차를 권합니다.
머지되기까지의 시간. 서브시스템과 머지 창 시점에 따라 크게 다릅니다. 확인한 수치가 없어 적지 않았습니다.

마치며

이 시리즈를 여기서 끝내는 이유가 있습니다. 커널을 읽고 빌드하고 관측하고 모듈을 쓰는 일까지는 혼자서 할 수 있지만, 그 다음은 혼자 하는 일이 아니기 때문입니다.

그리고 그 지점에서 관문이 되는 것이 코드 실력이 아니라 절차라는 사실이, 처음에는 답답하게 느껴지지만 나중에는 합리적으로 보입니다. 커널은 수십 년간 수천 명이 메일로 협업해 온 프로젝트입니다. 형식은 그 규모에서 리뷰가 가능하도록 남은 최소한의 규약입니다.

첫 패치가 되돌아오면, 대개는 거절이 아니라 절차를 한 번 더 돌라는 뜻입니다.

참고 자료

Submitting patches: the essential guide to getting your code into the kernel — 2026-08-19 열람. 이 글의 checkpatch.pl·get_maintainer.pl 사용법, Signed-off-by 형식과 그것이 증명하는 DCO 1.1, 커밋 메시지 순서와 75열, 인라인 제출 원칙과 git send-email 권장, 리뷰에 답해야 한다는 문장은 모두 이 문서에서 확인했습니다.

필사 모드: 첫 커널 패치 보내기 — 코드보다 절차가 관문인 이유