아이콘 라이선스 기준 명확화
목차
프로젝트 공식 지침에 아이콘 사용 정책을 추가했다. 상업용 무료 오픈소스 SVG만 사용하고, AI 생성 아이콘은 금지한다는 내용이다. 개발 가이드 문서 한 항목이 추가된 것이지만, 뒤에는 여러 고민과 판단이 들어가 있다.
지침이 필요했던 배경
처음엔 아이콘 선택에 공식 기준이 없었다. 개발자마다 편한 대로 했다. 누군가는 Figma에서 직접 그린 아이콘을 쓰고, 누군가는 유명한 오픈소스 라이브러리를 썼고, 또 누군가는 AI 이미지 생성 도구로 만든 아이콘을 프로젝트에 넣었다. 각자의 판단을 존중하는 것도 중요하지만, 이런 자유도가 쌓이면서 몇 가지 리스크를 안게 됐다.
첫째, 법적 명확성 부족이다. AI 생성 콘텐츠는 저작권 상태가 여전히 불명확하다. 누군가 우리가 쓴 아이콘이 학습 데이터 속 기존 작품에서 파생된 거라고 주장했을 때, 우리는 대응하기 어렵다. 오픈소스 라이브러리도 라이선스가 제각각인데, 제대로 확인하지 않고 쓰면 나중에 문제가 될 수 있다. 상업 서비스라면 이런 부채를 최소화해야 한다.
둘째, 일관성과 유지보수성 문제다. AI로 생성한 아이콘은 스타일이 뒤죽박죽되기 쉽고, 누군가 "이 아이콘 수정해줄 수 있어?"라고 물었을 때 원본을 재생산하기 어렵다. 오픈소스 아이콘은 최소한 깃헙에 소스가 있고, 버전 관리와 이슈 추적이 가능하다.
셋째, 온보딩 비용이다. 신입 개발자가 들어올 때마다 "우리는 이렇게 하거든"을 설명해야 하는데, 명확한 지침이 없으면 팀 내 경험담에만 의존한다. 지침을 문서화하면 일관성 있는 온보딩이 가능해진다.
정책 내용
| 항목 | 기준 |
|---|---|
| 사용 가능 | 상업용 무료 오픈소스 SVG (MIT, Apache 2.0, CC0 등) |
| 검증 방법 | 라이선스 명시된 공식 레포지토리에서만 다운로드 |
| 금지 항목 | AI 생성 아이콘, 라이선스 불명확한 자료 |
| 추천 예시 | Heroicons, Feather, Tabler Icons 등 |
판단을 단순하게 하기 위해 체크리스트로 정리했다:
- 라이선스 문서에 "상업용 무료" 또는 "CC0/MIT" 명시되어 있는가?
- 공식 깃헙 레포 또는 공식 웹사이트에서 다운로드했는가?
- 프로젝트 내 어딘가 출처를 기록할 수 있는가?
이 세 가지를 만족하면 충분하다. 복잡한 법 지식이 없어도 판단할 수 있도록 했다.
AI 생성 아이콘을 금지한 이유
기술이 발전했다고 해서 법적 리스크가 사라지진 않는다. 특히 이미지 생성 AI는 학습 데이터 출처가 불명확하고, 우리가 생성한 아이콘이 특정 아티스트의 스타일을 강하게 반영하거나 기존 작품의 파생물일 가능성이 있다.
더 실질적인 문제는 재현 불가능성이다. 같은 프롬프트를 다시 돌려도 매번 다른 결과가 나온다. "이 아이콘 색상을 바꿀 수 있어?"라고 물었을 때 원본을 다시 만들 수 없다. 반면 오픈소스 SVG는 소스 코드로 존재하고, 필요하면 수정할 수 있고, 업스트림에서 개선사항을 받을 수 있다. 버전 관리도 명확하다.
그리고 팀의 시각적 일관성 문제도 있다. AI로 생성한 여러 아이콘들은 스타일이 일관되지 않을 가능성이 높다. 결국 누군가 (보통 디자인팀) 손을 거쳐 톤 통일을 해야 하는데, 그럴 바엔 처음부터 커뮤니티에서 검증된 오픈소스 아이콘 세트를 쓰는 게 훨씬 효율적이다.
팀에 미치는 변화
첫 인상은 "또 새로운 규칙이냐" 할 수 있다. 하지만 실제로는 개발자의 판단 부담을 줄여준다. 아이콘을 선택할 때 "이거 괜찮나?"를 매번 고민할 필요가 없어진다. 정책이 명확하니 자신감 있게 결정할 수 있다.
누가 언제 어디서 가져온 아이콘인지 추적하기가 쉬워진다. 무언가 문제가 생겼을 때 "이건 공식 오픈소스에서 나온 거고, 라이선스는 이거다"라고 답할 수 있다. 신규 개발자 온보딩도 간단해진다. 더 이상 "선배한테서 물어봐" 스타일의 학습이 아니라, 문서를 읽으면 된다.
일반화하면
이런 정책화는 아이콘만의 문제가 아니다. 폰트, 라이브러리, 이미지 자료, UI 컴포넌트 등 외부 리소스를 쓰는 모든 곳에 같은 논리를 적용할 수 있다. 팀 규모가 작을 때는 "그냥 하던 대로"가 통한다. 하지만 성장하면서 팀원이 늘어나고 프로젝트가 복잡해지면, 암묵적 기준들이 충돌한다. 그때 되돌아보면, 명확한 지침이 없어서 야기된 기술 부채들이 보인다.
오픈소스 커뮤니티의 수많은 리소스는 이미 라이선스가 명확하고, 커뮤니티 지원을 받는다. 우리가 처음부터 만들 필요가 없다. 이 정책은 결국 "팀의 의도적 선택"을 문서화한 것일 뿐이다. "우리는 이런 기준으로 판단한다"는 신호를 팀 전체에 보내는 것이다. 그 신호가 명확할수록, 나중에 문제가 줄어든다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.