C 코드는 거의 어디에나 정의되지 않은 동작이 숨어 있다는 얘기

“C를 잘 쓰면 된다”는 말이 점점 방어가 안 된다는 주장

• 글쓴이는 C/C++를 30년 가까이 거의 매일 써온 사람인데도, 결론이 꽤 세다. “비자명한 C/C++ 코드에는 정의되지 않은 동작(Undefined Behavior, UB)이 있다”는 쪽임.

  • double-free, use-after-free, 배열 범위 밖 접근, 초기화 안 된 메모리 읽기 같은 건 다들 위험하다고 알고 있음.
  • 그런데 글의 핵심은 그런 뻔한 메모리 버그가 아니라, 평소에 별생각 없이 쓰는 코드에도 표준상 UB가 숨어 있다는 것임.

• “최적화 끄면 괜찮지 않나?”도 틀린 접근이라고 봄.

  • UB는 컴파일러가 “어? 네 실수 잡았다” 하고 공격적으로 최적화하는 문제가 아니라, 컴파일러가 애초에 “그런 코드는 유효하지 않으니 고려하지 않아도 된다”고 가정하는 계약 문제임.
  • 그래서 최적화 옵션을 끄더라도, 컴파일러 내부 단계나 하드웨어로 의도가 전달되는 과정에서 이미 보장 자체가 사라질 수 있음.

생각보다 가까운 곳에 있는 UB 사례들

• 정렬(alignment)이 맞지 않는 포인터를 만드는 것부터 이미 위험하다고 설명함.

  • 예를 들어 int 포인터가 sizeof(int)의 배수 주소를 가리키지 않는다면, 어떤 플랫폼에서는 그냥 동작하고 어떤 플랫폼에서는 SIGBUS로 터질 수 있음.
  • Linux Alpha에서는 커널이 일부 load를 소프트웨어로 보정해주기도 했지만, 다른 경우에는 크래시가 났고 SPARC도 SIGBUS가 날 수 있음.
  • x86/amd64에서는 대체로 관대하게 돌아가지만, 그건 표준이 보장해서가 아니라 그 플랫폼이 봐주는 것에 가깝다는 얘기임.

• 더 골때리는 포인트는 “역참조하기 전”에도 이미 UB일 수 있다는 점임.

  • 정렬 안 된 주소를 int*로 캐스팅하는 순간부터 문제가 될 수 있다고 봄.
  • 미래 아키텍처가 int 포인터의 하위 비트를 태깅이나 보안 용도로 쓴다고 해도, 표준상 불가능한 포인터를 만든 코드가 항의할 근거가 약함.

• isxdigit()에 char를 그대로 넘기는 코드도 함정이라고 지적함.

  • isxdigit()은 int를 받지만, 허용되는 값은 unsigned char로 표현 가능한 값 또는 EOF임.
  • char가 signed인 아키텍처에서 128 이상 값이 음수로 승격되면, 테이블 인덱싱 같은 구현에서 엉뚱한 메모리를 읽을 수 있음.
  • 데스크톱 앱에서는 그냥 크래시나 이상한 값으로 끝날 수 있지만, 임베디드나 유저스페이스 네트워크 드라이버 같은 환경에서는 I/O mapped memory를 건드리는 식의 더 이상한 일이 생길 수도 있다고 봄.

• float를 int로 캐스팅하는 단순한 코드도 만만치 않음.

  • float 값이 int로 표현 가능한 범위를 벗어나면 UB이고, non-finite 값이어도 UB라고 설명함.
  • 그러면 INT_MAX와 비교하려고 float를 int로 바꾸면 그 자체가 위험하고, INT_MAX를 float로 바꾸면 정확히 표현되는지 또 따져야 함.
  • “초를 밀리초 정수로 바꾸려고 곱하고 캐스팅하는 코드” 같은 흔한 패턴도 입력 범위에 따라 위험해질 수 있다는 얘기임.

NULL, printf, divide by zero도 그냥 교과서 문제가 아님

• 주소 0에 객체를 두는 것도 C 표준 관점에서는 실전에서 거의 답이 없다고 봄.

  • C의 NULL은 “기계 주소 0”을 의미하는 게 아니라 C 추상 머신의 null pointer constant임.
  • 역사적으로 NULL 포인터가 실제 주소 0이 아닌 머신도 있었고, memset으로 포인터 필드를 0으로 채운다고 반드시 NULL 포인터가 된다고 보장할 수도 없음.
  • OS 커널이나 임베디드처럼 주소 0을 실제로 다루고 싶은 코드에서는 이 간극이 꽤 불편해짐.

• printf 계열의 가변 인자도 타입이 조금만 어긋나면 UB가 됨.

  • %ld가 필요한 곳에 long long을 넘기거나, %lld가 필요한 곳에 long을 넘기는 식의 실수는 표준상 안전하지 않음.
  • NULL을 %p에 넘길 때도 NULL 매크로가 정수 0처럼 해석될 수 있어서, 명시적으로 void*로 맞추는 식의 주의가 필요하다고 봄.
  • uid_t를 출력하려고 해도 signed인지 unsigned인지, 어떤 포맷 매크로를 써야 하는지 계속 타입 계약을 따라가야 함.

• divide by zero는 다들 알지만, 보안 관점에서는 더 민감하다고 짚음.

  • 분모가 신뢰할 수 없는 입력에서 온다면 단순 크래시가 아니라 서비스 거부나 더 큰 취약점 표면이 될 수 있음.
  • C/C++에서는 “아마 이 값은 0이 아니겠지”가 코드 계약으로 남아 있으면, 언젠가 공격 입력이나 엣지 케이스가 그 부분을 찌를 수 있음.

그래서 LLM을 코드 리뷰에 넣자는 결론

• 글쓴이는 대규모 언어 모델(LLM)이 C 코드에서 UB를 찾는 데 사람보다 꽤 잘한다고 말함.

  • 아무 C 코드나 던지고 UB를 찾아보라고 하면 요즘 모델은 꽤 높은 확률로 맞는 지적을 한다는 경험담을 공유함.
  • 본인 코드에서 문제를 찾은 뒤, 더 성숙하고 엄격하게 작성됐을 OpenBSD의 find 코드에도 시도했고, out-of-bounds write와 로직 버그를 찾아 패치를 보냈다고 함.

• 다만 “AI가 고쳐준 코드 그냥 머지하자”는 얘기는 아님.

  • 글쓴이도 LLM 결과를 보고 사람이 다시 확인해야 한다고 선을 그음.
  • 문제는 이 검토가 주니어에게 맡기기엔 너무 미묘하고, 시니어에게 맡기기엔 너무 많은 반복 노동이라는 점임.
  • 그래서 “AI slop을 커밋하지 않으면서도, 사람 리뷰어를 압도하지 않는 규모의 UB 정리 방식”이 필요하다고 정리함.

• C/C++ 코드베이스를 당장 버릴 수 없다는 현실도 인정함.

  • 레거시 시스템, 커널, 임베디드, 고성능 네트워크, 런타임, 데이터베이스 같은 영역에는 C/C++가 여전히 깊게 박혀 있음.
  • 하지만 “그냥 원래 이렇게 해왔다”로 계속 두기에는 2026년의 컴파일러, 하드웨어, 보안 환경이 너무 달라졌다는 게 글의 큰 메시지임.

---

기술 맥락

• 이 글에서 중요한 선택은 C/C++를 버리자는 게 아니라, UB를 찾는 리뷰 경로에 LLM을 넣자는 거예요. 왜냐하면 UB는 문법 에러처럼 바로 보이는 문제가 아니라 표준, 컴파일러, 아키텍처 지식이 겹쳐야 보이는 경우가 많거든요.

• 기존 정적 분석 도구만으로 충분하지 않다는 뉘앙스도 있어요. 왜냐하면 도구는 정해진 규칙을 안정적으로 잡는 데 강하지만, “이 캐스팅이 특정 플랫폼에서는 왜 위험한가” 같은 설명과 수정 방향까지 이어가는 데는 사람이 계속 맥락을 보태야 하거든요.

• LLM을 쓰는 이유는 후보를 빠르게 많이 뽑아내기 위해서예요. 다만 글쓴이는 모델이 낸 패치를 그대로 믿는 방식은 경계해요. 왜냐하면 UB 수정은 겉보기 동작을 바꿀 수 있고, 리뷰어가 표준상 문제와 실제 영향 범위를 같이 확인해야 하기 때문이에요.

• 이 접근이 특히 잘 맞는 곳은 오래된 C/C++ 코드베이스예요. 왜냐하면 수십 년간 돌아간 코드라도 x86에서는 우연히 안전해 보였을 수 있고, ARM이나 RISC-V, 새 컴파일러, 다른 최적화 조건에서는 전혀 다른 결과가 나올 수 있거든요.