4편: 이미지 소싱의 현실 — 퍼블릭 도메인과의 사투

 

시리즈: AI 협업 개발기: 타로 마스터 프로젝트
키워드: 퍼블릭 도메인, 이미지 저작권, CDN, Wikimedia, Internet Archive

---

"무료 이미지"는 간단하지 않다

프로젝트 초기에 Claude가 알려준 정보는 이랬다. 1909년 Pamela Colman Smith가 그린 원본 Rider-Waite-Smith(RWS) 타로카드는 퍼블릭 도메인이다. 미국과 영국에서 저작권이 만료됐다. 무료로 쓸 수 있다.

여기까지만 들으면 간단해 보인다. 하지만 실전에서는 전혀 간단하지 않았다. "퍼블릭 도메인 이미지가 존재한다"는 것과 "웹 프로젝트에 안정적으로 사용할 수 있는 이미지 URL이 있다"는 건 완전히 다른 문제였다.

첫 번째 시도: Wikimedia Commons

가장 먼저 시도한 건 Wikimedia Commons였다. 위키피디아의 미디어 저장소로, RWS 타로카드 이미지가 카테고리별로 정리되어 있다. URL 패턴도 명확해 보였다.

Claude가 78장의 이미지 URL을 생성해줬고, 로컬에서 테스트하니 대부분 잘 로드됐다. "이거면 되겠다"고 생각하고 넘어갔다.

문제는 배포 후에 발견됐다. 몇몇 카드의 이미지가 깨져 있었다. The Lovers, Eight of Wands, Nine of Wands, King of Wands — 총 4장의 URL이 404를 반환하고 있었다.

Wikimedia Commons의 이미지 URL에는 해시 경로가 포함된다. 예를 들어, /commons/3/3a/RWS_Tarot_06_Lovers.jpg에서 3/3a는 파일명의 MD5 해시 첫 글자들이다. 파일이 이동되거나 이름이 바뀌면 이 해시 경로도 바뀐다. 그리고 Wikimedia는 커뮤니티 프로젝트라 파일 관리가 일관적이지 않다. 같은 카드의 이미지가 여러 버전으로 올라와 있고, 어느 것이 "정본"인지 명확하지 않다.

두 번째 시도: Internet Archive

Wikimedia의 불안정성을 해결하기 위해 Internet Archive로 갈아탔다. 누군가 78장 전체 RWS 덱을 하나의 컬렉션으로 올려놓은 것을 찾았다. Public Domain Mark 1.0 라이선스가 명시되어 있었고, 파일명도 깔끔했다.

URL 패턴도 단순했다. archive.org/download/컬렉션명/파일명.jpg. 해시 경로 같은 변수가 없어서 안정적이었다.

78장 중 77장이 정상적으로 로드됐다. 하지만 딱 1장, Nine of Wands가 문제였다. 나머지 Wands 카드들은 Wands01.jpg, Wands02.jpg... 패턴인데, Nine of Wands만 Tarot_Nine_of_Wands.jpg라는 전혀 다른 파일명으로 올라가 있었다.

이런 불일치는 사람이 수동으로 업로드하는 오픈 아카이브의 본질적 한계다. 파일 명명 규칙이 강제되지 않기 때문에 업로더가 한 장만 다른 이름으로 올리면 전체 패턴이 깨진다. Claude와 함께 해당 컬렉션의 파일 목록을 검색해서 실제 파일명을 찾아 수정했다.

저작권의 함정: 1909년 원본 vs 1971년 재색칠 버전

이미지 소싱 과정에서 가장 조심해야 했던 건 저작권이었다. "RWS 타로카드는 퍼블릭 도메인"이라는 말은 반만 맞다.

퍼블릭 도메인인 것은 1909년 Pamela Colman Smith의 원본 흑백 + 수채 일러스트다. 하지만 우리가 보통 "타로카드"하면 떠올리는 선명하고 현대적인 색감의 이미지는 1971년 US Games Systems가 재색칠한 버전이다. 이 버전은 아직 저작권 보호를 받고 있다.

웹에서 검색하면 두 버전이 섞여서 나온다. 눈으로는 구분이 어려운 경우도 있다. 일반적으로 색이 선명하고 깔끔한 것은 1971년 버전, 색이 바랜 듯하고 인쇄 질감이 있는 것이 1909년 원본이다.

이 구분이 왜 중요한가. 만약 1971년 버전을 "퍼블릭 도메인이니까 무료"라고 생각하고 사용하면 저작권 침해가 된다. 특히 상업적 용도로 사용할 경우 법적 문제가 생길 수 있다.

타로 마스터에서는 명확히 1909년 원본 스캔을 사용하는 소스만 선택했다. itch.io의 CC0 정리본, Internet Archive의 Public Domain Mark 컬렉션 등 라이선스가 명시된 소스만 후보로 두었다.

세 가지 이미지 소스의 비교

최종적으로 검토한 세 가지 소스를 비교하면 이랬다.

첫째, itch.io의 CC0 정리본. 파일명이 깔끔하고 웹 프로젝트에 바로 쓸 수 있는 크기로 정리되어 있다. CC0 라이선스라 저작권 걱정이 없다. 다만 외부 호스팅(itch.io)의 안정성에 의존하는 것이 약간 불안했다.

둘째, Internet Archive. 78장 전체가 하나의 컬렉션에 있고, Public Domain Mark가 명시되어 있다. URL 패턴이 안정적이다. 다만 앞서 말한 파일명 불일치 같은 자잘한 문제가 있었다.

셋째, Wikimedia Commons. 가장 "공식적"이지만 URL 안정성이 가장 낮았다. 해시 경로 문제와 파일 이동 가능성이 걸렸다.

최종 선택은 Internet Archive였다. 파일명 불일치 문제를 수동으로 한 번만 수정하면 되니까 가장 안정적이었다.

이미지 로딩 최적화: 외부 URL의 한계

이미지를 프로젝트에 직접 포함시키지 않고 외부 URL을 참조하는 방식을 선택한 이유가 있다. 78장의 이미지를 프로젝트에 포함시키면 빌드 크기가 크게 늘어나고, 이미지 파일 자체를 저장소에 커밋하는 것이 깔끔하지 않기 때문이다.

하지만 외부 URL 참조 방식에는 단점이 있다. 첫 로드 시 78장의 이미지를 외부 서버에서 가져와야 하므로 로딩이 느릴 수 있다. 외부 서버의 가용성에 의존하므로 서버가 다운되면 이미지가 깨진다.

이 문제를 완화하기 위해 두 가지 조치를 취했다. 하나는 이미지가 로드되기 전에 카드 뒷면 디자인(CSS로 구현된)을 보여주는 것이다. 사용자는 이미지 로딩을 의식하지 못한 채 카드를 고르고, 뒤집는 시점에는 이미 이미지가 캐시되어 있다. 다른 하나는 이미지 로드 상태를 추적해서 로드 실패 시 대체 텍스트를 표시하는 것이다.

완벽한 해결은 아니지만, 사이드 프로젝트 수준에서는 충분한 대응이었다. 본격적인 서비스라면 이미지를 자체 CDN에 올리는 것이 맞지만, 이 프로젝트의 목적에서는 과도한 인프라 투자다.

Claude와 함께 한 디버깅 과정

이미지 문제를 디버깅하는 과정 자체도 AI 협업의 좋은 사례였다. 사용자가 "이 URL 4개가 깨져요"라고 알려주면, Claude가 해당 URL을 검색해서 실제 파일 존재 여부를 확인하고, 대체 소스를 찾아 수정하는 과정이 한 세션 안에서 진행됐다.

특히 Internet Archive 컬렉션의 파일 목록을 검색하거나, GitHub에 호스팅된 타로 이미지 레포지토리를 찾는 작업은 AI가 능숙하게 처리한 영역이다. 개발자가 직접 검색하면 여러 탭을 오가며 확인해야 할 일을 대화 한 번으로 해결할 수 있었다.

다만 한 가지 한계도 있었다. Claude가 네트워크 제한 환경에서 직접 URL을 테스트할 수 없는 경우가 있었다. 이럴 때는 "이 URL이 작동하는지 브라우저에서 확인해주세요"라고 사용자에게 확인을 요청했다. AI가 모든 걸 해결하는 게 아니라 사람과 번갈아가며 검증하는 과정이 필요했다.

이미지 소싱에서 배운 교훈

첫째, "무료"와 "안정적으로 사용 가능"은 다른 문제다. 퍼블릭 도메인 이미지가 존재한다고 해서 프로젝트에 바로 쓸 수 있는 건 아니다. URL 안정성, 파일명 일관성, 호스팅 신뢰도까지 확인해야 한다.

둘째, 저작권은 "같은 그림"이라도 버전에 따라 다르다. 원본이 퍼블릭 도메인이어도 파생물이 보호받을 수 있다. 이미지 소스의 라이선스를 반드시 확인해야 한다.

셋째, 외부 리소스 의존은 항상 리스크가 있다. 호스팅이 바뀌거나, 파일이 삭제되거나, URL 구조가 변경될 수 있다. 장기적으로 운영할 서비스라면 자체 호스팅이 필수다.

넷째, 1장의 예외가 전체의 문제가 된다. 77장이 정상이어도 1장이 깨지면 사용자에게는 "이미지가 안 나오는 앱"이다. 78장 전체를 일일이 검증하는 것은 지루하지만 필수적인 작업이었다.

다음 편 예고

이미지까지 해결됐다. 프로젝트의 모든 조각이 맞춰졌다. 마지막 5편에서는 완성된 결과물을 돌아보며, AI와 함께 프로젝트를 만드는 과정에서 얻은 인사이트와 방법론적 교훈을 정리한다.

---

이 글은 "AI 협업 개발기: 타로 마스터 프로젝트" 시리즈의 4편입니다.