---
title: "리눅스 커널, 6년·360개 넘는 패치 끝에 strncpy 제거"
published: 2026-06-20T20:59:40.000Z
canonical: https://jeff.news/article/4219
---
# 리눅스 커널, 6년·360개 넘는 패치 끝에 strncpy 제거

리눅스 커널이 오랫동안 버그의 원인이던 strncpy API 사용을 Linux 7.2에서 제거했어. NUL 종료 동작이 직관적이지 않고 불필요한 zero-fill로 성능 문제도 있던 API를 6년 동안 약 362개 커밋으로 걷어낸 작업임.

- 리눅스 커널이 드디어 `strncpy` API를 제거함
  - 이 작업은 Linux 7.2에 들어갈 예정이고, 마지막 per-CPU 아키텍처별 `strncpy` 구현까지 제거됐다고 함
  - 걸린 시간은 6년, 관련 커밋은 약 362개 이상임. C API 하나 없애는 데 이 정도가 든다는 게 커널 스케일임

- `strncpy`가 문제였던 이유는 이름과 실제 동작이 개발자 기대를 자주 배신했기 때문임
  - NUL termination 주변 의미가 직관적이지 않아서 버그의 지속적인 원인으로 지목돼 왔음
  - destination을 불필요하게 zero-fill하는 동작 때문에 성능 면에서도 손해가 있었음

> [!IMPORTANT]
> 이건 단순 리팩터링 뉴스가 아니라, 커널이 위험한 C 문자열 API를 장기적으로 걷어낸 사례임. “금지된 API”를 없애려면 대체 API와 패치 누적이 같이 필요함.

- 대체 API는 복사 목적에 따라 나뉨
  - NUL로 끝나는 destination에는 `strscpy()` 사용
  - NUL 종료와 zero-padding이 모두 필요한 경우엔 `strscpy_pad()` 사용
  - NUL 종료가 아닌 고정 폭 필드에는 `strtomem_pad()` 사용
  - 명시적 padding이 있는 bounded copy에는 `memcpy_and_pad()` 사용
  - 길이를 이미 알고 있는 메모리 복사는 그냥 `memcpy()` 사용

- 흥미로운 포인트는 ‘하나의 범용 함수’ 대신 의도를 드러내는 API 여러 개로 쪼갰다는 점임
  - 문자열인지, 고정 폭 메모리 필드인지, padding이 필요한지에 따라 호출자가 선택하게 만듦
  - 리뷰어 입장에서도 “이 복사가 NUL 종료를 기대하는가?”를 코드에서 바로 읽을 수 있음

---
## 기술 맥락

- 리눅스 커널이 한 선택은 `strncpy`를 더 조심해서 쓰자는 게 아니라 아예 제거하는 쪽이에요. 왜냐하면 이 함수는 이름만 보면 안전한 문자열 복사처럼 보이지만, 실제 NUL 종료 규칙이 헷갈려서 리뷰로 계속 잡아내기 어렵거든요.

- 대체 API를 여러 개 둔 이유는 복사의 의도를 타입처럼 드러내기 위해서예요. NUL 종료 문자열이면 `strscpy`, zero-padding까지 필요하면 `strscpy_pad`, 고정 폭 필드면 `strtomem_pad`처럼 목적별로 갈라야 실수가 줄어요.

- 6년과 362개 커밋이라는 숫자는 레거시 API 제거가 얼마나 현실적인 비용을 먹는지 보여줘요. 특히 커널처럼 아키텍처별 구현과 오래된 호출부가 많은 코드베이스에서는 ‘나쁜 API 금지’보다 ‘모든 사용처를 안전하게 바꾸는 작업’이 진짜 본게임이에요.

## 핵심 포인트

- strncpy는 NUL 종료 의미가 헷갈려 커널에서 지속적인 버그 원인이었음
- 불필요한 destination zero-filling 때문에 성능 문제도 있었음
- 6년 동안 약 362개 커밋으로 커널 내 사용처를 제거함
- 대체 API로 strscpy, strscpy_pad, strtomem_pad, memcpy_and_pad, memcpy가 권장됨

## 인사이트

C API 하나를 없애는 데 6년이 걸렸다는 게 커널 코드베이스의 현실을 잘 보여줌. 위험한 API를 금지하는 건 선언보다 마이그레이션 경로를 촘촘히 제공하는 일이 더 중요함.