fmtlib fmt가 GitHub Trending 정상에 올랐지만, 진짜 이야기는 유지보수에 있다

fmtlib fmt는 2026년 9월 3일자 GitHub Trending 핫리스트 스냅샷에서 1위에 올랐지만, 당일 새 릴리스가 있었던 것은 아니다.

이 구분은 중요하다. 해당 순위는 GitHub Trending을 추적하는 집계 서비스에서 나온 것이며, 그 기록에는 검증 가능한 수집 시점이나 일간 스타 증가 수가 제공되지 않았다. GitHub 역시 모든 Trending 목록에 대해 독립적으로 감사 가능한 영구 아카이브를 공개하지 않는다.

프로젝트의 릴리스 이력에 따르면 최신 안정 릴리스는 6월 16일 공개된 fmt 12.2.0이다. 이 버전은 C11 인터페이스를 추가하고 C++ 모듈 지원을 확장했으며, 라이브러리의 성능 개선 작업도 이어갔다.

따라서 이 사건은 전형적인 출시 소식이 아니다. 오랜 기간 사용된 인프라 라이브러리가 릴리스 수개월 뒤에도 갑자기 폭넓은 관심을 끌 수 있음을 보여주는 사례다.

이 관심은 C++ 팀에 중요한 질문도 다시 던진다. 이제 std::format과 std::print가 존재하는데, 이들의 형성에 기여한 독립 라이브러리는 왜 여전히 이렇게 주목받는가?

순위는 사실이지만, 원인은 검증되지 않았다

검증된 사실은 9월 제품 발표가 아니라 Trending 순위다.

제공된 BettaFish 스냅샷은 9월 3일 GitHub Trending 핫리스트에서 fmtlib/fmt를 1위로 표시했다. 그러나 이 집계 서비스는 정확한 공개 시점, 순위 집계 기간, 일간 스타 수를 제공하지 않았다.

이러한 누락 때문에 관심 급증의 원인을 확신하기 어렵다. 소셜 게시물, 하위 의존 프로젝트, 인기 튜토리얼 또는 일상적인 GitHub 활동이 영향을 미쳤을 수 있다. 순위만으로 단일 계기를 확정할 수는 없다.

9월 3일자 릴리스도 없다. 프로젝트의 릴리스 페이지는 검증된 소스 기록에서 12.2.0을 최신 안정 버전으로 명시한다.

해당 버전은 관찰된 순위보다 두 달 이상 앞서 공개됐다. Trending 등장을 릴리스로 취급하면 별개의 두 사건을 합쳐 잘못된 타임라인을 만들게 된다.

GitHub Trending 자체는 실제 운영 도입이 아니라 관심도를 측정한다. 높은 순위는 커뮤니티 관심의 빠른 변화를 반영할 수 있지만, 의존성 다운로드 수나 배포된 버전은 공개하지 않는다.

이 목록에는 엄밀한 비교에 필요한 방법론적 세부 정보도 부족하다. GitHub는 저장소가 선택한 기간 동안 트렌드에 오른다고 설명하지만, 완전한 순위 산식은 공개하지 않는다.

따라서 저장소는 단 하나의 헤드라인급 사건 없이도 상승할 수 있다. 개발자들은 패키지 업그레이드, 문서, 컴파일러 관련 논의 또는 다른 프로젝트의 의존성 그래프를 통해 이를 접할 수 있다.

이 패턴은 특히 fmt에 그럴듯하다. 포맷팅 코드는 로깅 시스템, 명령줄 도구, 데이터베이스, 서비스의 기반에 자리하며, 최종 사용자에게는 대개 보이지 않는다.

최근 인덱싱된 GitHub 화면에서 이 저장소는 약 23,500개의 스타와 2,900개의 포크를 보유했다. 이 수치는 갑자기 등장한 프로젝트가 아니라 기존 사용자층이 있음을 보여준다.

그 이력도 수천 건의 커밋에 걸쳐 있다. 성숙한 코드베이스는 누적된 유지보수 작업이 개발자에게 새롭게 중요해질 때 Trending에 다시 등장할 수 있다.

가장 안전한 결론은 제한적이지만 유용하다. fmtlib fmt는 9월 3일 GitHub에서 주목할 만한 관심 급증을 얻었지만, 직접적인 원인은 검증되지 않았다.

그 불확실성이 순위의 의미를 없애지는 않는다. 오히려 이야기를 추정된 출시 소식에서 이 라이브러리가 계속 다시 주목받는 이유로 옮긴다.

fmtlib fmt 12.2는 C까지 영역을 확장했다

버전 12.2가 중요한 이유는 fmt가 익숙한 C++ 역할을 넘어 확장하면서도 일상적인 포맷팅 작업의 최적화를 이어갔기 때문이다.

가장 큰 범위 변화는 fmt/fmt-c.h 헤더를 통해 제공되는 C11 인터페이스 fmt-c였다. 이는 인수의 타입을 기준으로 표현식을 선택하는 C11 기능 _Generic을 사용한다.

이 설계는 C에 C++ 템플릿이 있는 척하지 않으면서 타입 지향 포맷팅을 제공한다. 개발자는 중괄호 기반 포맷 문자열과 일반 값을 사용해 fmt_print를 호출한다.

전통적인 printf는 변환 지정자가 뒤따르는 인수와 일치해야 하는 포맷 문자열에 의존한다. 불일치는 경고, 잘못된 출력 또는 정의되지 않은 동작을 낳을 수 있다.

새 인터페이스는 타입 기반 디스패치를 통해 더 많은 실수를 잡는 것을 목표로 한다. 또한 C 프로그래머에게 이미 많은 C++ 및 Python 사용자에게 익숙한 포맷팅 모델을 제공한다.

이는 fmt의 핵심 정체성을 대체하는 것이 아니라 확장하는 변화다. 프로젝트는 프로젝트 개요에서 여전히 자신을 C stdio와 C++ iostreams의 오픈소스 대안으로 설명한다.

버전 12.2는 별도의 fmt::fmt-module CMake 타깃도 도입했다. CMake 타깃은 하위 프로젝트가 라이브러리를 일관되게 사용할 수 있도록 빌드 요구 사항을 패키징한다.

이 타깃은 C++20 모듈을 지원한다. C++20 모듈은 텍스트 헤더를 반복 파싱하는 대신 컴파일러가 선언된 인터페이스를 처리하도록 한다. fmt는 모듈 기반 빌드에 대한 지속적 통합 테스트 범위도 추가했다.

모듈은 수년간 더 깔끔한 경계와 향상된 빌드 동작을 약속해 왔다. 하지만 컴파일러, 표준 라이브러리, 빌드 시스템 지원이 맞물려야 하므로 실제 도입은 여전히 고르지 않다.

유지관리되는 타깃은 팀에 지원되는 통합 경로를 제공한다. 그렇다고 모든 툴체인 조합이 동일하게 동작한다고 보장하지는 않는다.

성능 개선도 핵심으로 남았다. 이 릴리스는 빌드가 명시적으로 바이너리 크기 최적화를 선택한 경우를 제외하고, 전체 Dragonbox 룩업 캐시를 기본으로 활성화했다.

Dragonbox는 이진 부동소수점 값을 십진 텍스트로 변환하는 알고리즘이다. 이 변환은 로그, 직렬화, 진단, 대시보드, 과학 소프트웨어에 등장한다.

프로젝트는 캐시 변경으로 약 10~25%의 속도 향상이 있었다고 보고한다. 공개된 벤치마크에서는 전체 캐시 구성에서 double당 22.07나노초를 측정했다.

동일하게 문서화된 설정에서 컴팩트 구성은 29.55나노초를 기록했다. 이 수치는 Apple M1 Pro에서 Clang 17을 사용해 프로젝트가 자체 수행한 벤치마크 결과다.

이는 해당 테스트 환경에서의 작동 방식을 보여줄 뿐, 모든 애플리케이션의 속도 향상을 의미하지는 않는다. 대부분의 프로그램은 실행 시간 중 일부에서만 부동소수점 값을 포맷팅한다.

버전 12.2는 정수 포맷팅도 약 3% 개선됐다고 보고했다. 컨테이너와 사용자 정의 문자열에 사용되는 back-insert 반복자 기반의 대량 추가 작업은 출력 성능을 개선했다.

디버그 빌드 크기도 개선 대상이었다. 프로젝트에 따르면 관련 구성에서 bloat 테스트 결과는 약 200킬로바이트에서 85킬로바이트로 줄었다.

그 밖의 변경 사항은 무손실 파일 시스템 경로 포맷팅, std::unexpected, 스타일이 적용된 println 오버로드, printf 호환 API의 위치 기반 너비 인수를 다뤘다.

이 항목들 중 어느 하나도 9월의 순위를 단독으로 설명하지는 못한다. 그러나 함께 보면 유지보수 작업을 포기하지 않으면서 프로젝트의 적용 범위를 넓히고 있음을 보여준다.

표준 C++는 fmt를 압박하지만 대체하지는 않는다

핵심 경쟁 구도는 fmt와 표준 라이브러리 포맷팅 사이에 있지만, 둘은 명확히 대립하기보다 여전히 연결돼 있다.

현대 C++에는 이제 포맷된 텍스트를 만드는 std::format과 포맷된 출력을 스트림으로 보내는 std::print가 포함된다. 이에 따라 외부 의존성의 필요성은 줄어든다.

중요한 역사적 사실은 fmt가 이 방향을 정립하는 데 도움을 줬다는 점이다. 프로젝트는 자신을 C++20 std::format과 C++23 std::print의 구현체로 소개한다.

fmt의 유지관리자인 Victor Zverovich는 현대 포맷팅 기능을 표준에 도입한 제안서도 작성했다. 포맷팅 제안서는 전통적인 포맷 출력보다 안전한 대안을 명시적으로 발전시켰다.

표준화는 코드베이스 내부의 선택 기준을 바꾼다. 팀은 또 다른 패키지를 관리하는 대신 컴파일러와 표준 라이브러리가 제공하는 기능을 선호할 수 있다.

이 선택지는 보수적인 환경에서 매력적이다. 의존성이 줄면 보안 검토, 라이선스 확인, 업데이트, 장기적인 빌드 재현성을 단순화할 수 있다.

표준 경로에도 제약은 있다. 기능 가용성은 컴파일러 버전, 표준 라이브러리 구현, 각 프로젝트가 선택한 언어 모드에 좌우된다.

오래된 엔터프라이즈 툴체인을 지원하는 팀은 모든 대상에서 완전한 C++20 또는 C++23 포맷팅 지원을 기대할 수 없다. 크로스플랫폼 제품은 종종 가장 오래된 지원 환경의 속도에 맞춰 움직인다.

fmt는 이런 환경 전반에서 더 일관된 인터페이스를 제공할 수 있다. 또한 여러 해가 걸리는 표준화 및 툴체인 배포 주기를 기다리지 않고 개선 사항을 릴리스할 수 있다.

이 라이브러리는 표준 표면을 엄격히 해석한 범위를 넘어서는 API도 제공한다. 여기에는 범위 포맷팅, 색상 및 텍스트 스타일, 출력 파일 헬퍼, 자체 릴리스 일정에 맞춰 설계된 통합 기능이 포함된다.

버전 12.2의 C11 API는 이 차이를 더욱 선명하게 한다. std::format은 C++에 속하지만, fmt는 이제 C와 C++ 프로젝트 전반에 하나의 포맷팅 모델을 제시하고 있다.

그렇다고 fmt가 자동으로 더 나은 선택이 되는 것은 아니다. 모든 의존성은 업그레이드 작업, 호환성 테스트, 업스트림 변경에 대한 노출을 만든다.

다른 의존성이 서로 다른 버전을 포함할 경우 fmt를 벤더링하면 빌드가 복잡해질 수 있다. 동적 링크 시스템은 애플리케이션 바이너리 인터페이스 호환성도 고려해야 한다.

표준 라이브러리는 또 다른 종류의 안정성을 제공한다. 기능은 공개된 사양을 따르며, 구현체가 성숙한 뒤에는 긴 지원 기간을 기대할 수 있다.

하지만 표준화가 원 프로젝트의 관련성을 고정시키거나 없애지는 않는다. 독립 라이브러리를 구현 아이디어와 성능 실험을 위한 업스트림 실험실로 만들 수 있다.

이 관계는 이 글의 핵심적인 반전을 만든다. 표준 안에서의 성공은 fmt를 불필요하게 보이게 할 수 있지만, 동시에 fmt의 설계 선택을 검증한다.

9월의 순위는 개발자들이 여전히 업스트림 프로젝트를 현재의 도구로 인식한다는 점을 시사한다. 얼마나 많은 이들이 std::format 대신 이를 선택하는지는 입증하지 않는다.

따라서 유용한 결정은 제약 조건에서 시작한다. 팀은 컴파일러 기준선, 필요한 기능, 의존성 정책, 측정된 애플리케이션 성능을 비교해야 한다.

Trending 순위를 기술적 증거로 받아들여서는 안 된다. 그렇다고 표준화가 원래 라이브러리를 사용할 모든 이유를 없앴다고 가정해서도 안 된다.

fmt 벤치마크가 입증하지 못하는 것

fmt는 설득력 있는 성능 수치를 공개하지만, 개발자는 집중된 포맷팅 테스트와 전체 애플리케이션 결과를 구분해야 한다.

프로젝트의 README에는 여러 포맷팅 방식을 비교한 벤치마크가 포함돼 있다. 문서화된 설정에서 fmt 12.1은 테스트를 0.44초에 완료했다.

동일한 테스트에서 printf는 0.66초, std::ostream은 1.63초, Boost Format은 3.89초를 기록했다. 이 벤치마크는 200만 개의 레코드를 /dev/null로 포맷팅했다.

이 측정값은 테스트된 작업과 환경에 관한 제한적인 주장을 뒷받침한다. 하나의 API를 교체하면 애플리케이션 전체 지연 시간이 같은 비율로 감소한다는 뜻은 아니다.

프로덕션 워크로드에는 할당, 동기화, 파일 시스템, 네트워크 작업, 파싱, 비즈니스 로직이 포함된다. 포맷팅은 일부 로깅 파이프라인에서 지배적일 수 있지만, 다른 환경에서는 거의 영향을 주지 않을 수 있다.

벤치마크의 주체도 중요하다. 이 수치는 독립 연구소가 아니라 fmt 프로젝트와 관련 벤치마크 저장소에서 나온 것이다.

방법론은 공개돼 있으므로 개발자는 결과를 재현할 경로를 갖는다. 재현 가능성은 맥락 없이 성능 헤드라인을 반복하는 것보다 더 가치 있다.

팀은 대표적인 포맷 문자열, 인수 타입, 컴파일러 플래그, 출력 대상을 테스트해야 합니다. 출력을 버리는 마이크로벤치마크는 모든 파일 또는 콘솔 워크로드를 모델링할 수 없습니다.

컴파일 시간에도 같은 수준의 주의가 필요합니다. fmt가 공개한 bloat 테스트는 100개의 번역 단위를 생성하고 각 포맷팅 메서드를 반복적으로 호출합니다.

프로젝트는 테스트한 fmt 리비전에서 최적화 컴파일 시간이 5초라고 보고합니다. printf는 1.6초이며, iostream과 Boost Format은 훨씬 더 긴 결과를 기록했습니다.

이 비교는 헤더 구조와 템플릿 인스턴스화가 중요한 이유를 설명합니다. 다만 사전 컴파일 헤더, unity build 또는 광범위한 생성 코드가 포함된 대규모 서비스의 빌드 시간을 예측하지는 못합니다.

12.2 릴리스에는 일반적인 마이그레이션 위험도 따릅니다. 새로운 타깃, 포매터, 성능 경로는 유지관리자가 완전히 통제할 수 없는 툴체인과 상호작용합니다.

공개 이슈 보고서는 그 경계를 보여 줍니다. 2026년의 한 보고서는 EBCDIC 및 기타 ASCII 비호환 실행 문자 세트와 관련한 인코딩 문제를 제기했습니다.

이슈가 확인된 취약점과 같은 의미는 아닙니다. 이는 이식성 주장이 주류 UTF-8 환경을 넘어선 테스트를 필요로 한다는 증거입니다.

아직 릴리스되지 않은 12.2.1 변경 로그는 또 다른 유용한 신호를 제공합니다. 여기에는 닫힌 파이프로 인한 멈춤, 정수 문자 포맷팅, 부동소수점 기간, 여러 통합 사례에 대한 수정 사항이 나열돼 있습니다.

이는 활발히 개발되는 라이브러리에서는 정상적인 일입니다. 동시에 프로덕션 팀이 메이저 또는 마이너 버전을 한 번 도입한 뒤 잊어버리는 대신 패치 릴리스를 추적해야 하는 이유를 보여 줍니다.

프로젝트는 12.2 주기에서 릴리스 아티팩트, 공급망 출처 정보, CodeQL 분석, 보안 정책을 추가했습니다. 이러한 조치는 다운스트림 사용자에게 제공되는 정보를 개선합니다.

그렇다고 의존성 위험이 사라지는 것은 아닙니다. 팀은 여전히 버전 고정, 취약점 모니터링, 재현 가능한 빌드, 지원 컴파일러를 대상으로 한 검증이 필요합니다.

엔지니어링 조직은 업그레이드 결정과 테스트 근거를 검색 가능한 기술 지식 베이스에 보관해 이 작업을 더 수월하게 할 수 있습니다. 목표는 문서의 양이 아니라 추적 가능성입니다.

따라서 회의적인 해석은 간단합니다. fmt에는 신뢰할 만한 엔지니어링 근거가 있지만, 가장 뛰어난 수치는 여전히 워크로드별 결과이며 일부는 자체 보고에 기반합니다.

출시 없이도 주목받을 수 있는 성숙한 인프라

fmt의 위치는 개발자 관심이 이미 주변 플랫폼에 영향을 미친 인프라를 다시 발견할 수 있음을 보여 줍니다.

소비자 애플리케이션은 보통 눈에 띄는 출시를 중심으로 화제가 됩니다. 인프라 리포지터리는 개발자가 의존성 변화와 기술적 문제를 통해 접하는 경우가 많아 다른 리듬을 따릅니다.

로깅 라이브러리는 오류 메시지를 통해 fmt를 드러낼 수 있습니다. 컴파일러 업그레이드는 호환되지 않는 매크로나 오버로드를 드러낼 수 있습니다. 빌드 마이그레이션은 팀이 header-only 통합을 재고하게 만들 수 있습니다.

각 경로는 조율된 발표 없이도 개발자를 리포지터리로 이끌 수 있습니다. 따라서 갑작스러운 관심의 원인을 특정하기는 더 어렵지만, 그 중요성이 줄어드는 것은 아닙니다.

fmt의 알려진 사용자 목록에는 데이터베이스, 터미널, 게임, 인프라 시스템, 개발자 도구가 포함됩니다. 프로젝트는 수많은 사례 가운데 ClickHouse, Envoy, PyTorch, Windows Terminal, spdlog를 명시합니다.

이 목록은 프로젝트가 관리하므로 완전한 의존성 조사 결과로 읽어서는 안 됩니다. 그럼에도 포맷팅 코드가 다양한 소프트웨어 계층을 거쳐 퍼지는 방식을 보여 줍니다.

이 라이브러리의 매력은 일상적인 문제에서 시작됩니다. 프로그램은 사용자, 로그, 진단, 파일, 네트워크 메시지를 위해 계속해서 타입이 지정된 값을 텍스트로 변환합니다.

C의 포맷형 I/O는 간결하지만 변환 지정자에 대한 책임을 개발자에게 둡니다. C++ iostream은 타입 기반 동작을 제공하지만 장황해질 수 있고 포맷팅 상태를 유지합니다.

중괄호 기반 포맷팅은 세 번째 경로를 제시합니다. 포맷 문자열은 위치와 표시 방식을 설명하고, 타입이 지정된 인수는 별도의 값으로 유지됩니다.

컴파일 타임 검사는 프로그램이 실행되기 전에 일부 잘못된 조합을 거부할 수 있습니다. 이는 드물게 실행되는 오류 경로가 실수를 숨길 수 있는 로깅에서 특히 유용합니다.

확장성도 중요합니다. 프로젝트는 자체 타입을 포맷하는 방식을 정의하고, 그 동작을 로깅과 사용자 대상 출력 전반에서 재사용할 수 있습니다.

이제 표준 라이브러리가 이 영역의 상당 부분을 다룹니다. fmt는 이식성, 새로운 추가 기능, 릴리스 주기를 통해 계속 경쟁하고 있습니다.

버전 12.2의 C 지원은 다시 한번 대상 사용자를 넓힙니다. 혼합 언어 프로젝트는 C 구성 요소를 C++로 변환하지 않고도 공통 포맷팅 방식을 평가할 수 있습니다.

이 변화는 다른 포맷팅 방식에도 압력을 가합니다. printf는 여전히 어디에나 존재하고 안정적이며 거의 모든 곳에서 사용할 수 있지만, 그 문법과 가변 인수 동작에는 익숙한 위험이 따릅니다.

C 래퍼 라이브러리는 컴파일러 어노테이션이나 생성 인터페이스를 통해 안전성을 높일 수 있습니다. 반면 fmt-c는 C11 제네릭 선택과 프로젝트의 기존 포맷팅 문법을 적용합니다.

이 접근 방식이 의미 있는 C 채택을 얻을지는 아직 알 수 없습니다. 9월 Trending 결과는 새 API에 대한 지속적 사용이 아니라 호기심을 측정합니다.

패키지 관리자 데이터는 더 강한 채택 신호를 제공할 것입니다. 다운스트림 의존성 업데이트, 반복되는 커뮤니티 사례, 대규모 C 코드베이스의 호환성 보고도 마찬가지입니다.

그러한 신호가 나타나기 전까지 이 순위는 발견 이벤트로 읽는 것이 가장 적절합니다. 이는 활성 리포지터리를 탐색하는 개발자의 경로에 확립된 라이브러리를 다시 올려놓았습니다.

이는 오픈 소스에 전략적으로 여전히 중요합니다. 성숙한 프로젝트는 새로운 리포지터리와 함께 유지관리자 관심, 기여자, 테스트 다양성, 인지도를 두고 경쟁합니다.

짧은 관심 급증은 새로운 이슈 보고와 패치를 가져올 수 있습니다. 또한 프로젝트 역량을 이해하지 못한 채 지원을 기대하는 사용자를 끌어들일 수도 있습니다.

그러면 유지관리자는 인터페이스 확장과 기존 사용자가 중시하는 예측 가능성 보존 사이에서 균형을 찾아야 합니다. fmt 12.2는 새로운 표면과 목표가 뚜렷한 수정 사항을 통해 두 가지를 모두 시도합니다.

관심의 지속 여부를 보여 줄 세 가지 신호

다음 시험대는 내일의 Trending 순위가 아니라, 관심이 릴리스와 다운스트림 채택, 신뢰할 만한 크로스 툴체인 결과로 전환되는지 여부입니다.

첫 번째 신호는 fmt 12.2.1입니다. 프로젝트의 변경 로그는 이 버전을 출시 예정으로 표시하며 이미 수정 사항과 추가 기능을 기록하고 있습니다.

시기 적절한 패치 릴리스는 유지관리자가 12.2 이후의 피드백을 안정적인 패키지로 전환하고 있음을 보여 줄 것입니다. 지연이 길어지면 출시되지 않은 커밋을 사용하거나 로컬 패치를 유지해야 하는 중요성이 커집니다.

내용은 시점만큼 중요합니다. 팀은 나열된 닫힌 파이프, 포맷팅, CMake, 모듈 수정 사항이 호환되지 않는 동작을 도입하지 않고 제공되는지 살펴봐야 합니다.

이 신호는 유지관리 측면의 이야기를 강화할 것입니다. Trending 노출이 개발 활동을 직접 늘렸다는 사실을 증명하지는 못합니다.

두 번째 신호는 fmt-c의 채택입니다. 패키지 업데이트, 다운스트림 C 리포지터리, 문서 예제, 실제 배포를 기반으로 한 이슈 보고를 살펴보세요.

몇 가지 데모는 문법을 검증할 수 있지만, 컴파일러와 운영체제를 아우르는 반복적 사용은 인터페이스의 실질적인 이식성을 시험하게 됩니다.

핵심 질문은 C 개발자가 타입 지향 포맷팅을 위해 새 의존성을 받아들일지 여부입니다. 기존 코드베이스는 printf, 래퍼, 플랫폼별 로깅에 깊이 투자돼 있습니다.

fmt-c가 의미 있는 다운스트림 프로젝트에 등장한다면 9월의 관심은 실제 확장과 연결된 것으로 보일 것입니다. 채택이 제한적인 수준에 머문다면 주목할 만한 실험으로 남을 것입니다.

세 번째 신호는 fmt와 표준 라이브러리 기능 사이의 움직임입니다. 컴파일러 릴리스와 프로젝트 기준선 변경은 더 많은 팀이 std::format과 std::print를 사용할 수 있게 만들 것입니다.

일부 코드베이스는 표준으로 이동할 것입니다. 다른 코드베이스는 오래된 플랫폼, 추가 API, 수정 사항에 더 빠르게 접근하기 위해 fmt를 유지할 것입니다.

공개 마이그레이션 보고서는 어떤 제약이 우세한지 드러낼 수 있습니다. 비교 테스트에는 빌드 시간, 바이너리 크기, 포맷팅 처리량, 이식성, 유지보수 노력이 포함돼야 합니다.

표준 라이브러리로의 마이그레이션 물결은 fmt를 기본 의존성으로 삼아야 한다는 근거를 약화시킬 것입니다. 그렇다고 구현 참조와 개발 공간으로서의 역할이 사라지는 것은 아닙니다.

fmt의 채택이 계속된다면 표준 사용 가능성만으로 인프라 선택이 결정되지는 않는다는 점을 보여 줄 것입니다. 릴리스 주기와 지원 환경은 계속 결정적인 요소로 남습니다.

따라서 fmtlib fmt를 평가하는 개발자는 1위 순위를 결론으로 바꾸고 싶은 유혹을 피해야 합니다. 12.2 변경 사항부터 살핀 뒤, 자체 빌드 환경에서 관련 테스트를 재현하세요.

지원하는 가장 오래된 컴파일러를 확인하세요. 전체 툴체인이 지원하는 경우에만 모듈을 테스트하고, 프로덕션 시스템을 업그레이드하기 전에 패치 수준 변경 사항을 검토하세요.

C 프로젝트에서는 분리된 예제 대신 실제 로깅 또는 진단 경로에서 fmt-c를 프로토타이핑하세요. 경고, 실행 파일 크기, 처리량, 실패 동작을 측정하세요.

9월 순위는 유용한 질문을 던졌을 뿐, 답을 제공하지는 않았습니다. 다음 툴체인 기준선에서 표준 포맷팅으로 충분해질까요, 아니면 fmt가 오늘도 구체적인 호환성 문제를 해결하고 있을까요?