Skip to content

Gcc

  • Published on
    2026년 7월 29일 GCC 운영위원회가 AI 정책 작업 그룹의 권고안을 받아들였습니다. 핵심은 법적으로 유의미한 기여에 LLM 생성 콘텐츠가 포함되거나 그로부터 파생된 경우 받지 않는다는 것이고, 그 기준선은 GNU 유지보수자 지침의 약 15줄입니다. 다만 테스트 케이스는 예외이고, 연구·분석·버그 발견·패치 리뷰에 LLM을 쓰는 것 자체는 막지 않으며, AI 보조 작업에는 Assisted-by 트레일러를 요구합니다. 이 글은 정책의 실제 요구 사항, 그 배경에 있는 저작권 양도와 DCO 문제, 리눅스 커널·Debian·NetBSD·Gentoo·QEMU가 각각 어디에 선을 그었는지, 그리고 기여자에게 실제로 달라지는 것을 정리합니다.
  • Published on
    2026년 3월 28일 WG21은 C++26의 기술 작업을 끝냈습니다. 표결은 만장일치가 아니었고(찬성 114, 반대 12, 기권 3), 비만장일치의 주된 이유는 계약(contracts)이었습니다. 계약은 pre·post·contract_assert로 사전조건과 사후조건을 언어 차원에서 적는 기능이지만, 그 검사가 실제로 실행될지는 소스 코드가 아니라 빌드 설정이 정합니다 — 표준 문구 그대로 "구현 정의(implementation-defined)"입니다. 반대측은 헤더의 inline 함수 하나로 이 설계가 왜 안전을 해치는지를 보였고(P3835R0), 찬성측은 기능적 안전과 언어 안전은 다른 목표이며 최악이라 해봐야 검사가 건너뛰어질 뿐 새 버그가 생기지는 않는다고 반박했습니다(P3846R0). 이 글은 양측의 실제 논증, 표준 초안의 정확한 문구, 코나에서 실제로 고쳐진 것과 끝내 못 들어간 "반드시 검사" 문법(P3911), 그리고 2026년 7월 현재 이 기능을 구현한 컴파일러가 GCC 16.1 하나뿐이라는 이식성 현실을 정리합니다. 결론부터 말하면, 계약은 신뢰 경계 검증에 쓰라고 만든 물건이 아닙니다.
  • Published on
    2026년의 C++ 지도. C++ 23 (2024년 10월 ISO/IEC 14882:2024로 출간) 의 std::expected·std::print·std::generator, C++ 26의 진짜 주연인 Reflection (P2996) 과 Senders/Receivers (P2300), Linear Algebra (P1673), 마침내 쓸 만한 Modules, 성숙해진 Ranges. 빌드 도구는 CMake 3.30 / Meson / xmake / build2 / Bazel C++, 패키지는 Conan 2 와 vcpkg, 컴파일러는 Clang 19 / GCC 14 / MSVC, 그리고 libc++ vs libstdc++. Sanitizers (ASan / UBSan / TSan / MSan) 와 후계 언어 후보 (Carbon · Hylo · Cppfront), 한국·일본의 현장 사례까지 — 누가 C++ 을 골라야 하고, 어떻게 굴려야 하는가.