블로그 이미지에 넣을 일러스트를 무료로 구했습니다. 2,885개가 들어 있고, 색을 브랜드 색으로 바꿔 쓸 수 있었습니다. 실제로 써 본 기록입니다.
ManyPixels — 2,885개, MIT
SVG 일러스트 모음입니다. 같은 그림이 다섯 가지 형태로 들어 있습니다.
outline— 선으로 그린 평면flatline— 선과 면을 섞은 평면monochromatic— 한 색 계열, 그라데이션 있음two_color— 두 색 계열isometric— 입체감 있는 형태
npm install @quentincaffeino/manypixels-svg
색을 바꾼다
SVG는 글자로 된 파일이라 안에 적힌 색 코드를 찾아 바꾸면 됩니다. 먼저 어떤 색이 얼마나 쓰였는지부터 세어 보는 것이 순서입니다.
monochromatic은 한 가지 색이 압도적으로 많았습니다. 그 색을 제 브랜드 색으로 바꾸니 한 번에 정리됐습니다. 남은 회색 계열은 밝기를 보고 진한 색과 연한 색으로 나눠 넣었습니다.
평면만 쓴다
제 블로그는 그라데이션을 안 씁니다. 그래서 처음엔 monochromatic에서 그라데이션을 지우려고 했습니다. 그랬더니 그림이 무너졌습니다. 그라데이션이 형태를 만들고 있었기 때문입니다.
답은 간단했습니다. 원래 평면인 형태를 쓰면 됩니다. outline과 flatline은 애초에 그라데이션이 없습니다. 지우려 애쓸 필요가 없었습니다.
여백 때문에 작아 보인다
제일 오래 걸린 부분입니다. 크기를 키워도 그림이 계속 작게 나왔습니다. 확인해 보니 그림을 담는 상자는 400×300인데 실제 그림은 그 안쪽 244×150만 차지하고 있었습니다.
그래서 실제 그림이 차지하는 범위를 재서 상자를 그만큼 줄였습니다. 브라우저에 getBBox()라는 기능이 있어서 그걸로 쟀습니다. 한 번 잰 값은 저장해 두고 다시 쓰지 않습니다.
라이선스
MIT입니다. 상업적으로 쓸 수 있고 수정해도 됩니다. 제가 확인한 건 패키지에 적힌 내용이고, 원 저작자 사이트의 조건은 따로 확인하시는 게 좋습니다.
MIT 라이선스가 허용하는 것과 지켜야 할 것
Open Source Initiative에 게시된 MIT 라이선스 문안에 따르면, 소프트웨어 사본을 가진 사람은 대가 없이 제한 없이 사용·복사·수정·병합·게시·배포·재라이선스·판매할 수 있습니다. 조건은 하나입니다. 저작권 표시와 허가 표시를 모든 사본 또는 상당 부분에 포함해야 합니다. 그리고 소프트웨어는 “있는 그대로” 제공되며, 상품성·특정 목적 적합성·비침해에 대한 보증이 없고, 저작자나 권리자는 그 사용으로 생기는 청구나 손해에 책임지지 않는다고 적혀 있습니다.
| 항목 | MIT 문안의 내용 | 일러스트를 쓸 때 의미 |
|---|---|---|
| 사용·수정 | 제한 없이 허용 | 색 치환 같은 수정이 가능합니다. |
| 배포·판매 | 허용 | 글 이미지에 넣어 공개해도 됩니다. |
| 표시 조건 | 저작권·허가 표시를 사본에 포함 | 파일 자체를 배포할 때는 라이선스 문구를 함께 둡니다. |
| 보증 | 없음(“AS IS”) | 문제가 생겨도 제공자에게 책임을 묻기 어렵습니다. |
이 표는 MIT 문안 자체를 옮긴 것이고, ManyPixels 패키지에 어떤 표시 문구가 들어 있는지는 내려받은 패키지의 라이선스 파일에서 직접 보셔야 합니다. 완성된 그림을 블로그 이미지로 쓰는 경우와 SVG 원본 파일을 그대로 다시 나눠 주는 경우는 조건이 다르게 적용될 수 있으므로, 후자라면 라이선스 파일을 같이 두는 것이 안전합니다.
getBBox()가 재는 것
여백 문제를 풀 때 쓴 getBBox()는 MDN 문서에 따르면 요소를 담는 가장 작은 사각형을 돌려주는 메서드입니다. 기본값으로는 요소의 모양만 포함하고, 옵션으로 stroke(선 두께), markers, clipped를 켜서 범위를 넓히거나 줄일 수 있습니다. 선으로 그린 outline 형태에서는 선 두께만큼 가장자리가 잘려 보일 수 있으므로 stroke: true 옵션을 주고 재는 편이 안전합니다.
MDN은 이 방법이 요소나 부모에 적용된 변환(transform)을 반영하지 않는다는 점과, 뷰포트 기준 값을 주는 getBoundingClientRect()와는 값이 다르다는 점도 알려 줍니다. 그래서 잰 값을 그림 상자 크기로 쓸 때는 두 값을 섞지 않아야 합니다.
한계
사람이 등장하는 그림이 많습니다. 글의 성격에 따라 안 어울릴 수 있습니다. 저는 사물이나 화면이 나오는 것 위주로 골랐습니다.
그리고 이름으로 찾기가 어렵습니다. “api”나 “filter”로 검색하면 하나도 안 나옵니다. DataHosting, CodeDevelopment처럼 이름이 정해져 있어서, 몇 번 훑어보며 쓸 만한 것을 골라 두는 편이 빨랐습니다.
한 번 더 확인할 기준
무료라는 말 다음에는 라이선스가 옵니다. 상업적 사용, 출처 표기, 수정과 재배포 중 어디까지 허용되는지 작품마다 다를 수 있으므로 내려받는 페이지의 조건을 보관해 두는 편이 좋습니다.
| 확인할 것 | 왜 보는가 | 바로 해 볼 일 |
|---|---|---|
| 출처와 날짜 | 같은 말도 기준 시점이 다르면 뜻이 달라집니다. | 원문과 마지막 갱신일을 함께 적습니다. |
| 내 작업과의 거리 | 일반적인 설명이 내 상황에 그대로 맞지는 않습니다. | 작은 예시 하나로 먼저 시험합니다. |
| 되돌릴 방법 | 편리한 선택도 실수하면 비용이 생깁니다. | 원본·설정·결과를 구분해 둡니다. |
이 경우에는 이렇게 판단한다
브랜드 색으로 바꿀 때는 색 하나만 맞추지 말고 작은 크기에서도 형태가 읽히는지 확인하세요. 배경색과 명도 차이가 작으면 예쁜 색이어도 버튼이나 설명 그림에서는 잘 보이지 않습니다.
작게 해 보는 예시
처음부터 중요한 일을 맡기지 않는 편이 좋습니다. 예를 들어 새 기능이나 자료를 발견했다면, 실제 결과를 바꾸지 않는 샘플 하나로 시작합니다. 입력은 짧게 정하고, 기대한 결과와 실제 결과를 나란히 적습니다. 여기서 차이가 나면 도구가 틀렸다기보다 내가 세운 조건이 모호했을 가능성도 같이 살펴볼 수 있습니다.
그다음에는 예외 하나를 일부러 넣어 봅니다. 빈칸, 오래된 날짜, 예상과 다른 형식처럼 현실에서 자주 만나는 조건입니다. 정상적인 경우만 통과한 방법은 다음 단계에서 쉽게 흔들립니다. 반대로 예외를 어떻게 처리할지 정해 두면, 나중에 문제가 생겼을 때 다시 처음부터 찾지 않아도 됩니다.
기록을 남기면 달라지는 점
새 방법을 쓴 날에는 “무엇을 넣었고 무엇이 나왔는지”를 두세 줄로 남겨 보세요. 다음에 결과가 달라져도 기억에 기대지 않고 비교할 수 있습니다. 특히 외부 자료나 서비스의 정책이 바뀌는 일은 눈에 잘 띄지 않습니다. 같은 입력을 다시 확인할 수 있는 작은 기록이 있으면, 변화가 도구 때문인지 내 조건 때문인지 구분하기 쉬워집니다.
이 기록은 긴 보고서일 필요가 없습니다. 날짜, 사용한 자료의 제목 또는 버전, 기대한 결과, 실제 결과, 다음에 고칠 한 가지면 충분합니다. 잘된 결과만 적기보다 애매했던 사례를 남겨 두는 쪽이 나중에 더 큰 도움이 됩니다. 비슷한 선택을 할 때 감으로 다시 시작하지 않아도 되기 때문입니다.
| 단계 | 확인하는 질문 | 다음 행동 |
|---|---|---|
| 1. 목표 | 무엇을 줄이거나 알아내려는가 | 한 문장으로 적습니다. |
| 2. 표본 | 작은 사례에서 같은 결과가 나오는가 | 입력과 결과를 보관합니다. |
| 3. 예외 | 모르는 값이나 실패는 어떻게 보이는가 | 멈춤·알림·재확인 중 하나를 정합니다. |
| 4. 적용 | 사람에게 영향을 주는 부분이 있는가 | 확인 단계를 남긴 뒤 범위를 넓힙니다. |
짧은 점검표
- 목적을 한 문장으로 적었는가 — 필요한 기능과 멋있어 보이는 기능을 구분합니다.
- 작은 범위에서 확인했는가 — 처음부터 중요한 자료나 많은 사람에게 적용하지 않습니다.
- 바뀔 수 있는 부분을 표시했는가 — 요금·정책·지원 범위는 공식 안내를 다시 확인합니다.
- 결과를 사람이 읽어 봤는가 — 자동으로 나온 값도 맥락과 예외를 마지막에 확인합니다.
- 원래 상태를 되돌릴 수 있는가 — 바꾸기 전의 기록을 남겨 두면 비교와 복구가 쉬워집니다.
업데이트
이 글의 기본 설명은 원문 발행 당시 공개 자료를 바탕으로 합니다. 기능, 약관, 제공 범위와 수치는 바뀔 수 있으므로 실제 적용 전에는 아래 자료의 최신 안내를 확인하세요. MIT 라이선스와 getBBox 설명의 기준일은 2026년 10월 18일입니다.
확인 자료
- Open Source Initiative: MIT License (확인: 2026-10-18)
- MDN: SVGGraphicsElement.getBBox() (확인: 2026-10-18)
- CISA 보안 기본 수칙 (확인: 2026-09-14)