SBOM·소프트웨어 공급망 지속가능성, 오픈소스 배포 최적화부터 🏋️‍♂️

 

SBOM·소프트웨어 공급망 지속가능성, 오픈소스 배포 최적화

안녕하세요,

그로메트릭 입니다. 🐸

 

오픈소스를 배포할 때 "더 많이, 더 자주"가 항상 좋은 신호는 아닙니다.

전 세계 자바 생태계의 핵심 인프라인 Maven Central을 운영하는 소나타입(Sonatype)이 퍼블리셔들과 나눈 대화에서 발견한 흥미로운 사실이 있습니다. Central에 올라오는 아티팩트 중 상당수가 애초에 다운스트림 소비자를 위한 것이 아니었다는 점입니다. 벤치마크용 JAR, 아무도 쓰지 않는 테스트 픽스처, 로컬 개발용 서버가 그대로 공개 배포 번들에 섞여 들어가는 식입니다. 악의도, 부주의도 아닙니다. 빌드 기본값과 오래된 릴리스 관행, 그리고 아무도 다시 들여다보지 않은 자동화가 누적된 결과일 뿐입니다.

 

이번 글은 실제 커머셜 퍼블리셔 한 곳이 릴리스 번들을 직접 감사(audit)해 본 사례를 중심으로, 오픈소스 배포에서 발생하는 낭비의 다섯 가지 유형과 이를 줄이는 방법을 다룹니다. 해당 퍼블리셔는 릴리스 크기를 3GB에서 300MB까지 줄였는데, 놀랍게도 배포 빈도나 릴리스 수는 거의 그대로 유지했습니다. SBOM 포맷 중복, pretty-print된 메타데이터, 벤치마크·테스트 아티팩트의 오배포 등 구체적인 문제와 해법을 함께 살펴보겠습니다.

 

*아래 글은 소나타입(Sonatype)의 공식 블로그 글을 번역하여 작성되었습니다.

 

---

 

Maven Central 퍼블리셔들과 지속가능성(sustainability)을 주제로 대화를 나누면서 반복적으로 나타난 패턴이 하나 있습니다. Central에 도달하는 것들 중 놀라울 만큼 많은 부분이 애초에 다운스트림 소비자를 위해 의도된 것이 아니었다는 사실입니다.

이는 악의적이거나 무모하거나, 심지어 특별히 이례적인 일도 아닙니다. 오히려 빌드 기본값, 릴리스 관행, 레거시 설정, 그리고 아무도 굳이 다시 검토할 이유가 없었던 자동화가 누적된 결과에 가깝습니다.

 

벤치마크용 JAR가 매 릴리스마다 첨부되는 이유는 빌드가 원래 그렇게 해왔기 때문입니다. 조직 외부에서 아무도 소비하지 않는데도 테스트 픽스처가 배포됩니다. 개발 서버가 shaded JAR 형태로 조립되어 조용히 공개 릴리스 번들의 일부가 됩니다. 동일한 기계 판독용(machine-readable) 메타데이터가 여러 포맷으로 중복 게시됩니다. 오직 기계만 처리할 파일인데도 사람이 읽기 좋은 형태로 포맷팅됩니다.

 

개별적으로 보면 이런 선택들은 사소해 보일 수 있습니다. 그러나 여러 모듈, 여러 릴리스, 여러 퍼블리셔, 그리고 수년에 걸쳐 반복되면 그 자체로 인프라가 됩니다.

"릴리스는 완전히 유효하면서도, 아무도 필요로 하지 않는 것들을 담고 있을 수 있습니다."

 

이는 Maven Central의 지속가능성 작업이 단순한 '한도 설정' 논의보다 훨씬 더 섬세한 문제라는 것을 보여주는 또 다른 사례입니다. 더 적게 배포한다고 해서 릴리스 빈도를 줄이거나, 지원하는 사용자 수를 줄이거나, 프로젝트의 가치를 낮춰야 하는 것은 아닙니다.

때로는 릴리스에 실제로 무엇이 담겨 있는지 한 번 더 자세히 들여다보는 것만으로 충분합니다.

---

낭비는 남용이 아니다 🙅‍♀️

"낭비"라는 단어는 주의가 필요합니다. 태만이나 의도적인 과잉을 암시할 수 있기 때문입니다.

하지만 대부분의 퍼블리셔 대화에서 확인한 것은 그런 모습이 아니었습니다. 더 흔한 패턴은, 각각은 합리적이었던 로컬 단위의 의사결정들이 누적되어 전체적으로는 비효율적인 결과를 만들어냈다는 점입니다.

 

현대 빌드 시스템은 자동화를 위해 설계됩니다. 플러그인이 아티팩트를 첨부하고, 부모(parent) 설정이 상속되며, 릴리스 파이프라인은 지시받은 대로 패키징합니다. 프로세스가 일단 안정화되면, 이를 건드리는 데 대한 거부감이 생기기 마련입니다.

그 결과 공개 릴리스에는 다음과 같은 것들이 포함될 수 있습니다.

• 내부 벤치마킹에만 사용되는 아티팩트
• 로컬 개발을 위해 만들어진 shaded 실행 파일
• 외부 소비자가 없는 테스트 JAR 및 테스트 소스
• 여러 직렬화(serialisation) 형태로 중복된 메타데이터
• 크기만 키울 뿐 기계 판독 가치는 없는 포맷팅이 적용된 생성 파일
• 과거에는 다운스트림 용도가 있었지만 지금은 그렇지 않은데도 계속 배포되는 모듈
• 완전한 번들로서 아무도 검토한 적 없는 릴리스 산출물

이 사례들이 반드시 Central의 오남용을 의미하지는 않습니다. 오히려 원래의 맥락이 사라져버린 배포 결정으로 이해하는 편이 더 정확합니다.

이것이 바로 가시성(visibility)이 중요한 이유입니다. 퍼블리셔가 자신의 릴리스 크기와 구성을 직접 확인할 수 있기 전까지는, 무엇이 필수적이고 무엇이 단순히 '존재'하는 것인지 구분하기 어렵습니다.

---

숫자로 보는 현황: Central의 전체 릴리즈, 우리가 목격한 것들 👀

개발자는 보통 아티팩트를 모듈 단위로 생각하는 경향이 있습니다. 반면 Central은 이를 총합으로 바라봅니다.

한 모듈에 불필요한 파일이 몇 개 포함된 것은 사소해 보일 수 있습니다. 하지만 동일한 파일이 수십 개의 모듈, 여러 저장소, 잦은 릴리스 주기에 걸쳐 생성된다면 이야기는 완전히 달라집니다.

 

이러한 구분은 이 시리즈 전반을 관통하는 주제와도 맞닿아 있습니다. 인프라에 부담을 주는 많은 행동은 로컬 관점에서 보면 합리적입니다. 그 행동이 규모 있게 반복될 때, 비로소 그 영향이 달라지는 것입니다.

테스트 JAR 하나는 작을 수 있습니다. 소스 아카이브는 기대되는 요소일 수 있습니다. SBOM은 가치 있는 자료일 수 있습니다. shaded 아티팩트가 실제로 필요한 경우도 있습니다.

 

핵심 질문은 특정 classifier나 파일 유형이 본질적으로 낭비인가가 아닙니다. 해당 릴리스에서 그 특정 파일이 다운스트림 목적을 실제로 수행하고 있는가입니다.

 

이런 맥락 없이는 일괄적인 규칙이 도움이 되지 않습니다. 어떤 프로젝트는 다른 개발자들이 실제로 의존하는 재사용 가능한 테스트 하네스를 배포합니다. 다른 프로젝트는 전혀 소비되지 않는데도 테스트 아티팩트를 자동으로 첨부합니다. 어떤 프로젝트는 실행 가능한 배포판이 실제로 필요합니다. 또 다른 프로젝트는 실수로 개발 전용 서버를 라이브러리와 함께 배포하기도 합니다.

 

파일명만 보고는 어떤 경우에 해당하는지 알 수 없습니다.

---

실제 사례: 번들 내부를 들여다본 한 퍼블리셔 🕵️‍♀️

 

대화 중 가장 명확했던 사례 중 하나는, 릴리스 규모가 초기 사용 가이드라인을 넘어선 한 커머셜 퍼블리셔로부터 나왔습니다.

해당 조직은 익명으로 남기지만, 이 사례는 공유할 가치가 있습니다. 개선이 정당한 릴리스를 줄이거나 사용자가 받는 것을 바꾸는 방식으로 이루어지지 않았기 때문입니다.

 

팀은 자신들의 빌드가 배포를 위해 무엇을 준비하고 있는지 살펴보는 것부터 시작했습니다.

이들은 릴리스를 사실상 드라이런(dry-run)하고, 생성된 번들을 검사한 뒤 다음을 보고하는 작은 감사(audit) 스크립트를 만들었습니다.

• 예상되는 전체 릴리스 크기
• 각 모듈의 크기
• 서로 다른 아티팩트 classifier가 차지하는 비중
• 릴리스에서 가장 큰 비중을 차지하는 파일들

구현 자체는 정교하다기보다는 실용적이었습니다. 중요했던 것은 이전까지 대체로 보이지 않던 릴리스 프로세스를 실행 가능한 정보로 전환했다는 점입니다.

 

이 검토를 통해 피할 수 있었던 몇 가지 산출물 유형이 드러났습니다. 벤치마킹 모듈은 지속적인 성능 테스트에는 유용하지만 다운스트림 소비자에게는 아무 가치가 없는 대용량 shaded JAR를 만들어내고 있었습니다. 일부 저장소는 엔지니어가 라이브러리를 로컬에서 실행해볼 수 있도록 개발 서버를 fat JAR로 조립하기도 했습니다. 이런 서버는 개발 워크플로 내부에서는 유용했지만, Central을 통해 배포할 이유는 없었습니다.

 

팀은 또한 테스트 JAR와 테스트 소스 JAR를 모듈 단위로 하나하나 검토했습니다. 재사용 가능한 테스트 하네스나 계약 테스트(contract-test) 스위트가 실제 다운스트림 목적을 가진 경우는 그대로 남겼습니다. 내부에서만 소비되거나 전혀 소비되지 않는 아티팩트는 공개 릴리스에서 제거했습니다.

 

결과는 미미하지 않았습니다.

 

세 차례의 보고 기간에 걸쳐 이 조직의 총 릴리스 크기는 약 3GB에서 1.5GB로, 다시 약 300MB로 줄어들었습니다. 릴리스 횟수와 빈도는 대체로 그대로 유지되었습니다. 이러한 감소는 소프트웨어 딜리버리를 줄여서가 아니라, 의도적으로 보다 계획적인 배포 방식을 채택한 데에서 비롯된 결과였습니다.

 

이는 실로 중요한 차이입니다.

이 퍼블리셔는 제품을 희생시켜 숫자를 최적화한 것이 아닙니다. 애초에 Central의 소비자들에게 전혀 유용하지 않았던 것들을 찾아낸 것뿐입니다.

 

가장 큰 파일이 바이너리가 아닐 수도 있다 ‼️

같은 검토에서 더 명확한 발견도 하나 나왔습니다.

가장 큰 우발적 아티팩트들을 제거하고 나자, 일부 릴리스 번들에서 소프트웨어 자재 명세서(SBOM)가 눈에 띄는 비중을 차지하기 시작했습니다.

 

이것이 SBOM 자체가 낭비라는 의미는 아닙니다. SBOM은 유용한 소프트웨어 투명성 자료이며, 풍부한 정보량 자체가 그 목적의 일부입니다. 하지만 SBOM 역시 기계 판독용 문서이며, 의존성 트리가 깊은 프로젝트에서는 용량이 커질 수 있습니다.

이 사례에서 해당 퍼블리셔는 동일한 의미 정보를 두 가지 이상의 직렬화 형태로 만들어내고 있었습니다. 팀은 실제로 다운스트림에서 사용하는 포맷 하나만 배포하는 방식으로 전환했습니다.

 

팀은 또한 SBOM 파일이 기본적으로 pretty-print(들여쓰기·공백 등 사람이 읽기 좋게 포맷팅) 되어 있다는 점도 발견했습니다. 들여쓰기와 공백은 사람이 문서를 읽어야 할 때는 유용하지만, 주로 기계가 소비하는 아티팩트에는 그다지 쓸모가 없습니다.

 

이 퍼블리셔는 compact 출력을 더 쉽게 생성할 수 있도록 업스트림에 변경 사항을 기여했고, 이후 자체 빌드 도구에서 이를 사용하는 작업을 시작했습니다. 일부 대형 모듈에서는 불필요한 포맷팅을 제거함으로써 SBOM 한 건당 약 100~150KB를 절감했습니다. 이 수치 자체만 보면 대단해 보이지 않을 수 있지만, 여러 모듈과 릴리스에 걸쳐 반복되면 자세히 들여다볼 때에만 비로소 보이는 또 다른 형태의 회피 가능한 용량 증가 사례가 됩니다.

 

이는 또한 지속가능성 작업이 개별 퍼블리셔의 설정 수준에서 멈춰서는 안 되는 이유를 보여줍니다.

때로는 도구의 기본 설정으로 인해 낭비가 심화되기도 합니다 그 근본적인 원인을 해결하면 이후 해당 도구를 사용하는 모든 사람의 행동을 개선할 수 있습니다.

---

오픈소스 배포 낭비의 다섯 가지 유형 📋

위 사례들은 몇 가지 뚜렷한 범주를 가리킵니다.

공개 소비자가 없는 아티팩트 (Artifacts With No Public Consumer)

개발, 테스트, 벤치마킹, 또는 내부 운영을 지원하지만 프로젝트의 공개 인터페이스를 구성하지는 않는 파일들입니다.

이런 파일들은 유용할 수 있고, 퍼블리셔 자신의 엔지니어링 프로세스에 필수적일 수도 있습니다. 하지만 그렇다고 해서 Central이 이를 배포하기에 적절한 장소라는 의미는 아닙니다.

이것이 가장 명확한 형태의 회피 가능한 배포입니다. 유효한 아티팩트가 존재하지 않는 소비자에게 전달되는 경우입니다.

중복된 표현(Duplicate Representations)

메타데이터가 XML과 JSON, 압축·비압축 형태, 또는 여러 개의 겹치는 플러그인 출력을 통해 생성될 수 있습니다.

때로는 소비자가 실제로 이러한 대안들을 필요로 합니다. 때로는 각 도구가 각자 선호하는 포맷을 독립적으로 첨부했기 때문에 생성된 것일 뿐입니다.

동일한 정보를 나타내는 두 개의 파일 중 하나만 사용된다면, 둘 다 배포하는 것은 상응하는 가치 없이 비용만 만들어냅니다.

빌드 산출물과 릴리스 산출물의 혼동 (Build Outputs Mistaken for Release Outputs)

소프트웨어 팩토리는 릴리스를 만들어내기까지 여러 가지를 생성합니다. 중간 패키지, 개발 서버, 진단용 번들, 생성된 테스트 픽스처, 벤치마크 실행 파일, 임시 어셈블리 등은 모두 정당한 빌드 산출물일 수 있습니다.

하지만 이것들이 자동으로 공개 릴리스 아티팩트가 되는 것은 아닙니다.

Central은 릴리스 준비가 완료된 컴포넌트를 공개 배포하기 위한 곳이지, 파이프라인이 만들어낼 수 있는 모든 것의 영구 저장소가 아닙니다. 이 구분은 소나타입의 지속가능성 프레이밍에서 처음부터 견지해 온 원칙입니다.

레거시 배포(Legacy Publication)

한 모듈이 과거에는 다운스트림 사용자를 가지고 있었을 수 있습니다. 오래된 툴체인이 특정 classifier를 요구했을 수도 있습니다. 릴리스 프로필이 수년 전 상위(parent) 프로젝트에서 그대로 복사되었을 수도 있습니다.

공개 아티팩트는 추가하기는 쉽지만, 제거하려면 호환성 우려가 생길 수 있어 질문을 던지기가 어렵습니다. 신중함은 당연히 필요합니다. 하지만 그 신중함이 퍼블리셔가 해당 아티팩트가 여전히 사용되고 있는지 확인하는 것 자체를 막아서는 안 됩니다.

중요한 단계는 무분별한 삭제가 아니라 근거(evidence) 확보입니다.

비효율적인 표현 방식(Inefficient Representation)

일부 아티팩트는 필요하지만, 실제로 필요한 것보다 더 큰 경우가 있습니다.

Pretty-print된 기계용 문서가 한 예입니다. 반복적으로 임베드된 의존성, 의도치 않은 shading, 비압축 리소스, 또는 중복된 세부 정보를 담은 생성 메타데이터도 마찬가지입니다.

목표는 모든 바이트를 깎아내는 것이 되어서는 안 됩니다. 엔지니어링 시간에도 비용이 들며, 지나친 최적화는 인프라 개선 효과를 상쇄할 만큼의 복잡성을 만들어낼 수 있습니다.

유용한 질문은 비교적 단순한 변경으로 유용성을 해치지 않으면서 의미 있는 중복을 제거할 수 있는가입니다.

---

최적화는 '측정'에서 시작된다 📏📐

익명의 퍼블리셔 사례에서 얻은 교훈 중 하나는, 가장 먼저 유용했던 도구가 정책 엔진이나 복잡한 플랫폼이 아니었다는 점입니다.

바로 하나의 '리포트'였습니다.

감사 스크립트가 존재하기 전에도 릴리스 프로세스는 작동하고 있었지만, 팀은 전체 배포 번들에 무엇이 담겨 있는지 명확하게 파악하지 못하고 있었습니다. 콘텐츠를 모듈, 아티팩트 유형, 크기별로 그룹화하자 명백한 후보들이 비로소 눈에 들어왔습니다.

이는 퍼블리셔와 인프라 관리자 모두에게 실용적인 방향을 시사합니다.

퍼블리셔에게는 배포 이후의 총합뿐 아니라, 배포 전 더 나은 가시성이 필요합니다. 유용한 릴리스 리뷰는 다음 질문들에 답할 수 있어야 합니다.

• 무엇이 배포될 예정인가?
• 어떤 파일이 새로 추가되었는가?
• 어떤 모듈이 대부분의 용량을 차지하는가?
• 어떤 classifier가 첨부되어 있는가?
• 이번 릴리스는 이전 릴리스와 비교해 어떤가?
• 각 아티팩트는 확인된 다운스트림 목적을 가지고 있는가?

이러한 질문들이 매번 수작업 포렌식 작업을 요구해서는 안 됩니다. 이상적으로는 빌드 및 릴리스 도구가 배포물의 구성을 쉽게 파악할 수 있도록 만들어야 합니다.

한 퍼블리셔가 자체적으로 감사 스크립트를 만들었다는 사실 자체가 고무적입니다. 동시에 이는 더 넓은 생태계에 유용한 유형의 도구가 아직 부족하다는 신호이기도 합니다.

모든 비용 절감이 가치 있는 것은 아니다 😅

낭비에 관한 논의가 자칫 최소화에 대한 집착으로 변질될 위험이 있습니다.

그것은 잘못된 교훈일 것입니다.

 

소스 JAR, 문서, 서명, provenance, SBOM, 체크섬, 메타데이터는 모두 정당한 역할을 가지고 있습니다. 더 큰 아티팩트가 더 나은 사용성을 제공할 수도 있습니다. 재사용 가능한 테스트 픽스처는 여러 다운스트림 팀이 동일한 것을 다시 만드는 수고를 덜어줄 수 있습니다. 생태계가 아직 하나로 수렴하지 않은 영역에서는 여러 포맷이 필요할 수도 있습니다.

 

지속가능성이 유용한 자료를 제거하거나 릴리스를 소비하기 어렵게 만드는 핑계가 되어서는 안 됩니다.

기준은 "가능한 한 적은 바이트를 배포하라"가 아닙니다.

기준은 "다운스트림 가치를 만들어내는 것을 배포하고, 그것이 왜 존재하는지 이해하라"입니다.

여기에는 판단의 여지가 남아 있습니다. 이는 소나타입이 커뮤니티 오픈소스 예외(exemption)에 접근해온 방식과도 일맥상통합니다. 수치 신호는 어디를 봐야 할지 알려줄 수 있지만, 맥락을 대체할 수는 없습니다.

효율화는 퍼블리셔 자신에게도 이득이다 👍

불필요한 배포를 줄이는 것은 단지 Central의 부하를 낮추는 데에만 그치지 않습니다.

더 작고 명확한 릴리스는 다음과 같은 이점도 가져다줄 수 있습니다.

• 더 빠른 빌드 및 릴리스 파이프라인
• 퍼블리셔 자체 시스템 내부의 저장·전송 비용 절감
• 릴리스 크기가 예상치 못하게 변할 때 더 쉬운 원인 조사
• 우발적인 공개 노출(disclosure) 감소
• 더 단순해진 다운스트림 의존성 선택
• 배포된 결과물이 프로젝트가 실제로 지원하려는 범위와 일치한다는 더 높은 확신

앞선 익명 퍼블리셔의 감사 작업은 Central 사용량 가시성 확보가 동기였지만, 이 작업은 팀에게 자신들의 릴리스 프로세스에 대한 더 명확한 이해도 함께 안겨주었습니다.

이는 좋은 인프라 최적화 작업에서 반복적으로 나타나는 특징입니다. 공유 시스템에서 낭비를 제거하는 과정은 종종 그 낭비를 만들어낸 로컬 시스템 내부의 낭비까지 드러냅니다.

더 나은 기본값(Default)이 중요하다

개별 퍼블리셔가 자신의 릴리스 번들을 검토할 수는 있지만, 생태계 전체가 모든 팀이 이런 문제를 독립적으로 발견하기만을 기대할 수는 없습니다.

빌드 도구와 플러그인은 배포 행동 자체를 형성합니다. 아티팩트를 자동으로 첨부하거나, 중복된 출력을 생성하거나, 기계 전용 파일을 pretty-print하거나, 릴리스 번들을 검사하기 어렵게 만드는 기본값들은 수천 개 프로젝트에 걸쳐 누적된 비용을 만들어낼 수 있습니다.

대다수 사용자는 기본 경로를 그대로 따릅니다. 이는 아무도 의도하지 않았더라도 기본값 자체가 일종의 인프라 정책이 된다는 것을 의미합니다.

 

그렇기에 퍼블리셔가 낭비를 발견했을 때 얻을 수 있는 가장 강력한 결과는, 단순히 그 퍼블리셔 한 곳의 설정이 바뀌는 것이 아닙니다. 그 교훈이 상류(upstream)로 흘러가는 것입니다.

• 플러그인으로
• 부모(parent) POM으로
• 릴리스 도구로
• 문서로 
• 배포 전 더 나은 가시성으로

앞선 사례의 퍼블리셔는 정확히 이를 실천했습니다. 최적화 내용을 자신들만 사용하는 데 그치지 않고, 업스트림 SBOM 라이브러리에 변경 사항을 기여한 것입니다.

이것이 바로 로컬 단위의 지속가능성 작업이 생태계 전체의 개선으로 이어지는 방식입니다.

---

의도를 가지고 배포하라

Maven Central은 자바 생태계에 유용한 소프트웨어를 쉽게 배포할 수 있도록 하는 것을 목표로 해야 합니다.

그렇다고 해서 모든 빌드 산출물이 영구적인 공개 아티팩트가 되어야 하는 것은 아닙니다. 또한 퍼블리셔가 릴리스를 불편하거나 불완전해질 때까지 최소화해야 하는 것도 아닙니다.

필요한 것은 '의도(intent)'입니다.

 

릴리스는 소비자가 실제로 필요로 하는 바이너리, 메타데이터, 문서, 보안 정보, 그리고 부속 아티팩트를 담아야 합니다. 오직 퍼블리셔 자신의 엔지니어링 프로세스만을 위해 존재하는 것이 있다면, 대개 더 나은 보관 장소가 따로 있습니다. 동일한 정보가 두 번 배포되고 있다면, 두 사본 모두가 정말 필요한지 물어볼 필요가 있습니다. 도구의 기본값 때문에 파일이 커졌다면, 그 기본값을 개선할 수 있는지 고려할 가치가 있습니다.

 

이런 결정들은 한 번 내릴 때는 사소해 보입니다. 하지만 Central은 이를 생태계 전체에 걸쳐 경험합니다.

소나타입의 지속가능성 작업은 규모, 한도, 상업적 사용, 커뮤니티 예외라는 눈에 보이는 질문들에서 시작되었습니다. 이들은 여전히 중요합니다. 하지만 퍼블리셔들과의 대화는 더 건설적인 기회 또한 보여주고 있습니다. 모두가 자신이 배포하는 것이 무엇인지 이해하고, 더 이상 목적에 부합하지 않는 것을 제거하도록 돕는 일입니다.

 

가장 훌륭한 낭비 처리 방식은 낭비를 더 효율적으로 가격 매기고, 저장하고, 최적화하는 것이 아닙니다.

애초에 시스템에 잔류하는 낭비를 막는 것, 그것이 가장 훌륭한 처리 방식일 수 있습니다.

---

출처

소나타입 블로그 : Optimising Out the Waste in Open Source Publishing