Skip to content

License

  • Published on
    오픈 모델의 license 필드에 적힌 짧은 식별자는 목차일 뿐이고 실제 조건은 전문에 있습니다. 이 글은 2026-08-12에 실제로 마주친 라이선스 유형들을 정리하고, 커뮤니티 라이선스와 비상업 조건이 무엇을 요구하는지, 게이트 저장소가 배포 파이프라인에서 왜 문제가 되는지, 그리고 GGUF 같은 양자화 배포판의 출처를 어떻게 확인해야 하는지를 설명합니다. 오픈 모델 가이드 시리즈 마지막 8편입니다.
  • Published on
    허깅페이스 모델 카드에서 실제로 판단 근거가 되는 항목은 라이선스, 파라미터 수, 컨텍스트 길이, intended use, limitations, 학습 데이터 여섯 가지입니다. 이 글은 각 항목이 무엇을 뜻하고 무엇을 숨기는지, 다운로드 수와 좋아요 수가 왜 품질 지표가 아닌지, 그리고 카드에 적혀 있지 않은 항목을 어떻게 다뤄야 하는지를 2026-08-12에 실제로 확인한 모델 페이지 사례로 정리합니다. 오픈 모델 가이드 시리즈 1편입니다.
  • Published on
    데이터 계층에서 자리를 내주었거나 배포 조건이 바뀐 프로젝트 10개를 공식 발표문과 Apache Attic 기록만 근거로 정리합니다. Redis와 Elasticsearch, MongoDB의 라이선스 변경과 그로 인해 생긴 Valkey, OpenSearch 포크를 사실만으로 다루고, Kafka에서 ZooKeeper가 빠진 과정, Apache Attic으로 이관된 Sqoop과 Oozie, Giraph, Tajo, 회사 종료 후 리눅스 재단으로 간 RethinkDB, 상표 문제로 이름을 바꾼 PrestoSQL과 Trino를 살펴봅니다. 각 항목은 무엇이었나, 왜 그때 옳았나, 무엇이 바뀌었나, 무엇이 그 자리에 왔나, 무엇을 남겼나, 지금도 쓰는 게 맞는 경우로 나눠 정리했습니다. 상태 정보는 2026년 8월 12일에 원문에서 직접 확인했습니다.
  • Published on
    한때 컨테이너 인프라의 기본 구성이었다가 지금은 다른 것으로 대체된 프로젝트 11개를 공식 공지와 저장소 보관 상태만 근거로 정리합니다. rkt, dockershim, Classic Swarm, Docker Machine, Compose V1, Heapster, Apache Mesos, PodSecurityPolicy, CoreOS Container Linux, ingress-nginx, 그리고 HashiCorp 라이선스 변경과 OpenTofu를 다룹니다. 각 항목은 무엇이었나, 왜 그때 옳았나, 무엇이 바뀌었나, 무엇이 그 자리에 왔나, 무엇을 남겼나, 지금도 쓰는 게 맞는 경우로 나눠 봅니다. 인프라 계층의 교체는 성능보다 운영 부담과 표준화, 그리고 유지보수 인력이 원인인 경우가 많습니다. 상태 정보는 2026년 8월 12일에 원문에서 직접 확인했습니다.
  • Published on
    자리를 내준 오픈소스 시리즈의 마지막 편입니다. 앞선 세 편에서 다룬 30여 개 프로젝트를 가로질러, 기술을 교체시키는 힘이 무엇인지 다섯 가지로 정리합니다. 플랫폼 흡수, 운영 부담, 유지보수 인력, 라이선스 변경, 문제 정의의 이동. 특히 라이선스 변경은 MongoDB와 Elastic, HashiCorp, Redis 사례를 어디에서 어디로 바뀌었는지 사실만으로 표에 정리하고, 그 결과 생긴 OpenSearch와 OpenTofu, Valkey 포크를 함께 짚습니다. 이어서 우리 조직의 스택이 같은 궤적 위에 있는지 확인하는 관측 가능한 신호 목록과 GitHub API 점검 명령, 그리고 지금 옮길지 기다릴지를 가르는 판단 기준을 제시합니다. 상태 정보는 2026년 8월 12일에 원문에서 직접 확인했습니다.
  • Published on
    스타 수는 인기 지표이지 위험 지표가 아닙니다. 오픈소스를 프로덕션에 들이기 전에 실제로 확인해야 하는 신호를 정리합니다. 최근 커밋과 릴리스 주기, 이슈 응답, 기여자 분포와 버스 팩터를 GitHub API로 직접 세는 방법, 라이선스가 자동 분류되지 않을 때 LICENSE 파일을 직접 읽어야 하는 이유, 그리고 도입 전 체크리스트를 담았습니다. 시리즈에서 실제로 확인한 사례를 근거로 삼았고, 저장소 정보는 2026년 8월 12일 GitHub에서 직접 확인한 시점 값입니다.
  • Published on
    모델 카드는 위에서 아래로 읽으면 필요한 정보를 못 찾도록 쓰여 있습니다. 벤치마크 표가 화면의 절반을 차지하는 동안 라이선스와 채팅 템플릿은 한 줄로 지나갑니다. 이 글은 카드를 읽는 순서를 뒤집어, 배포 판단에 실제로 필요한 일곱 가지를 5분 안에 뽑아내는 방법을 정리했습니다. 가중치 공개와 오픈소스가 어떻게 다른지, 카드의 점수를 왜 그대로 믿으면 안 되는지, 컨텍스트 길이 표기가 무엇을 감추는지, 그리고 토크나이저와 채팅 템플릿에서 왜 오류 없이 조용히 망가지는지를 다룹니다. 마지막으로 2026년 8월 2일에 허깅페이스에서 직접 확인한 카드 하나를 체크리스트대로 끝까지 읽습니다.
  • Published on
    2018년 MongoDB의 SSPL 전환을 시작으로, 2021년 Elastic, 2023년 HashiCorp, 2024년 Redis가 차례로 Apache/MIT를 떠나 BSL·SSPL·RSALv2 같은 비-OSI 라이선스로 갔다. 그 결과 OpenSearch·Valkey·OpenTofu·OpenBao 같은 커뮤니티 포크가 줄지어 태어났고, 2024년 8월 Elastic은 AGPL로 돌아왔다. 이 글은 BSL 물결의 7년사를 정리하고, OSI 정의와 "source-available" 논쟁, AWS "strip-mining" 내러티브의 진위, Sustainable Use License / Fair Source 운동, 그리고 한국·일본 기업의 입장과 우리 회사가 라이선스를 바꾸거나 마이그레이션할 때 고려할 의사결정 프레임을 깊게 들여다본다.