무료 이미지를 찾아서 — 저작권, 깨진 URL, 호스팅 불안정과의 싸움

 

78장의 이미지가 필요하다

화면 디자인은 완성되었다. 별이 흐르는 배경 위에서 카드가 아름답게 뒤집힌다. 문제는 뒤집힌 카드 앞면에 보여줄 이미지가 없다는 것이었다. 타로 덱은 메이저 아르카나 22장과 마이너 아르카나 56장, 총 78장으로 구성된다. 78장의 이미지를 모두 확보해야 한다.

상업용 타로 덱의 이미지를 사용하려면 라이선스 비용이 발생한다. 사이드 프로젝트에 수십만 원을 투자하고 싶지는 않았다. 그렇다면 무료 이미지를 찾아야 한다. 여기서부터 예상치 못한 긴 여정이 시작되었다.

퍼블릭 도메인의 함정: 1909 vs 1971

타로 이미지 하면 가장 먼저 떠오르는 것이 라이더-웨이트-스미스(RWS) 덱이다. 1909년에 아서 에드워드 웨이트가 기획하고 파멜라 콜먼 스미스가 그린 이 덱은 현대 타로의 표준이다. 대부분의 타로 앱이 이 이미지를 사용한다.

"1909년이면 저작권이 만료되었을 테니 자유롭게 쓸 수 있겠다"고 생각했다. 반은 맞고 반은 틀렸다. 파멜라 콜먼 스미스의 원본 흑백 선화는 1909년 작품으로, 대부분의 국가에서 저작권이 만료되어 퍼블릭 도메인이다. 하지만 우리가 흔히 보는 컬러 버전은 다른 이야기다.

1971년에 US Games Systems가 새로운 색채로 칠한 버전을 출시했다. 이 컬러링에 대한 저작권은 여전히 유효할 수 있다. 즉, 같은 그림이라도 "어느 버전의 색칠인가"에 따라 저작권 상태가 달라진다. AI에게 이 부분을 물어봤을 때 처음에는 "RWS는 퍼블릭 도메인이므로 자유롭게 사용할 수 있다"는 답을 받았다. 틀린 답은 아니지만, 컬러 버전에 대한 중요한 뉘앙스가 빠져 있었다.

추가로 질문을 던져서야 1971년 컬러 버전의 저작권 이슈에 대한 설명을 얻을 수 있었다. 이 경험은 중요한 교훈을 남겼다. AI의 첫 번째 답변을 그대로 믿지 말고, 특히 법적 문제에서는 반드시 후속 질문으로 검증해야 한다는 것이다.

Wikimedia에서의 첫 번째 시도

안전한 선택은 1909년 원본에 가까운 이미지를 사용하는 것이었다. Wikimedia Commons에 RWS 타로 카드 이미지가 올라와 있다는 정보를 확인하고 시도해봤다. 실제로 78장 전부가 업로드되어 있었고, 파일 크기와 해상도도 적당했다.

하지만 문제는 안정성이었다. Wikimedia의 이미지 URL 구조는 복잡하고, 파일명에 특수문자가 포함된 경우가 있다. 처음에는 직접 URL을 참조하는 방식으로 구현했다. 몇 주간은 잘 작동했다. 그러다가 어느 날 갑자기 일부 이미지가 로드되지 않았다.

Wikimedia가 이미지 URL을 변경한 것인지, 서버 일시 장애인지 정확한 원인은 알 수 없었다. 하지만 확실한 것은 외부 서비스의 URL에 직접 의존하는 것이 얼마나 위험한지를 체감했다는 점이다. 78장 중 3장만 깨져도 앱의 신뢰성은 바닥으로 떨어진다.

Internet Archive: 또 다른 시도, 또 다른 불안정

Wikimedia의 대안으로 Internet Archive를 시도했다. 여기에도 RWS 타로 카드 이미지가 아카이빙되어 있었다. URL 구조가 좀 더 안정적으로 보였고, 이미지 품질도 괜찮았다.

하지만 Internet Archive는 다른 문제가 있었다. 로딩 속도가 일정하지 않았다. 어떤 때는 순식간에 로드되고, 어떤 때는 5초 이상 걸렸다. 타로 카드를 뒤집는 극적인 순간에 이미지가 5초간 로딩 중이라면 모든 분위기가 깨진다. 0.8초짜리 뒤집기 애니메이션을 공들여 만들어놓고 이미지 로딩 때문에 빈 카드가 보이는 것은 받아들일 수 없었다.

preload나 lazy loading 같은 기술적 해결을 시도해봤지만, 근본적으로 외부 서버의 응답 속도를 제어할 수는 없었다. 78장을 모두 미리 로드하면 초기 로딩이 너무 무거워지고, 필요할 때만 로드하면 뒤집기 순간에 빈 이미지가 보인다.

AI가 제안한 URL이 존재하지 않았다

이 과정에서 가장 당황스러웠던 순간이 있다. AI에게 "RWS 타로 카드 78장의 퍼블릭 도메인 이미지를 호스팅하는 안정적인 소스를 알려줘"라고 물었다. AI는 자신 있게 여러 URL을 제시했다. 특정 GitHub 레포지토리의 경로, 특정 웹사이트의 API 엔드포인트 등.

하나씩 확인해봤다. 절반 이상이 존재하지 않는 URL이었다. GitHub 레포지토리는 실제로 있었지만 이미지 경로가 달랐고, 웹사이트 API는 아예 존재하지 않았다. AI가 "있을 법한" URL을 그럴듯하게 생성해낸 것이다. 이것이 바로 AI 할루시네이션의 전형적인 사례다.

이 경험은 AI 협업에서 가장 중요한 교훈을 안겨주었다. AI는 코드 작성, 설계 논의, 아이디어 브레인스토밍에서는 탁월하다. 하지만 "특정 URL이 실제로 존재하는가", "이 라이브러리의 최신 버전이 무엇인가" 같은 구체적 사실 확인에서는 반드시 직접 검증해야 한다. AI의 "그럴듯한 정보"와 "정확한 정보"는 전혀 다르다.

결국 직접 호스팅으로 해결

여러 시행착오 끝에 도달한 결론은 단순했다. 직접 호스팅하자. Wikimedia에서 퍼블릭 도메인 확인된 이미지 78장을 다운로드하고, 프로젝트의 public 폴더에 넣는 것이다.

이 방법의 장점은 명확하다. 외부 의존성이 없으므로 URL이 깨질 일이 없다. 이미지가 프로젝트와 함께 배포되므로 로딩 속도가 일정하다. 78장의 이미지 파일을 최적화하면 총 용량도 관리 가능한 수준이다.

다운로드한 이미지를 일괄적으로 리사이징하고 WebP로 변환하는 작업은 AI의 도움이 컸다. 이미지 처리 스크립트를 작성하는 데는 AI가 정확하고 빠르다. "78장의 PNG 이미지를 300px 너비로 리사이징하고 WebP로 변환하는 스크립트"를 요청하면 즉시 사용 가능한 코드가 나왔다.

돌이켜보면 처음부터 직접 호스팅이 답이었다

Wikimedia 직접 참조, Internet Archive 시도, AI에게 다른 소스 질문까지 돌아돌아 결국 직접 호스팅에 도착했다. 처음부터 이 결론을 냈다면 하루 만에 끝날 작업이었다.

하지만 이 돌아간 과정이 완전히 무의미하지는 않았다. 퍼블릭 도메인의 미묘한 저작권 이슈를 이해하게 되었고, 외부 리소스 의존의 리스크를 체감했으며, AI의 사실 정보 제공에서의 한계를 명확히 인식하게 되었다. 특히 마지막 교훈은 이후 프로젝트 전체에서 AI와 협업하는 방식을 크게 바꿔놓았다.

AI에게는 "어떻게(how)"를 물어보면 뛰어난 답을 얻을 수 있다. 하지만 "어디에(where)"나 "있는가(whether)"를 물을 때는 항상 직접 확인하는 습관이 필요하다. 이것이 AI 협업 개발에서 반드시 기억해야 할 구분선이다.

다음 편 예고

이미지도 확보했고, 디자인도 완성되었다. 이제 진짜 코드를 구조화할 차례다. 다음 편에서는 React 컴포넌트 설계 과정을 이야기한다. AI에게 컴포넌트 구조를 효과적으로 요청하는 방법, 처음부터 완벽한 설계를 포기하는 것의 가치, 그리고 리팩토링이 자연스러운 과정인 이유를 함께 나눈다.