이미지 출처 표기, 위키미디어 커먼즈 사진을 받을 때 저작자까지 같이 받아왔다

사진 다섯 장을 보고서에 넣으면서 사진마다 저작자와 라이선스를 적는 출처 표를 만들었는데, 그 표에 사람이 손으로 옮겨 적은 칸은 하나도 없었다.

이미지 출처 표기는 늘 맨 마지막에 하게 된다. 사진부터 구해서 붙여놓고 "출처는 나중에 달지 뭐" 하다가, 막상 달 때 되면 어디서 받았는지 기억이 안 나는 거지 ㅋ 이번에 연구보고서에 실물 사진을 넣을 일이 생겼는데, 순서를 아예 거꾸로 했다. 클로드코드가 사진을 받는 그 순간에 저작자와 라이선스까지 같이 받아오게 만든 거다. 생각보다 간단했고, 짐작으로 하던 방식이 왜 안 되는지도 확실히 알게 됐다.

1. 글만 많아서 심심하다는 말에 사진이 들어가게 됐다

요즘 중국 태양광 산업을 다루는 긴 연구보고서를 만들고 있다. 집필은 클로드코드가 하고, 나는 장마다 정독하고 코멘트를 단다. 태양광 장을 읽고 코멘트를 달다가 전체에 대고 한 말이 하나 있었는데, 그냥 "글만 많으니 좀 심심하다"였다.

진짜 그랬다. 정책 이름이랑 숫자가 몇 페이지씩 이어지는데 눈 쉴 데가 없더라. 그래서 집필 가이드에 실물 사진이라는 유형이 새로 들어갔고, 그림도 맨 마지막에 몰아서 만들지 말고 장 하나 쓸 때마다 바로 붙이기로 규칙이 바뀌었다. 그 장에 도표 7개와 사진 5컷이 들어갔다.

근데 사진은 도표랑 달랐다. 도표는 데이터로 직접 그리면 끝인데, 사진은 남이 찍은 걸 빌려와야 한다. 연구보고서라 조건이 세 개 붙었다. 저작권이 안전해야 하고, 저작자와 라이선스를 캡션에 정확히 적어야 하고, 나중에 누가 봐도 그 출처를 다시 확인할 수 있어야 했다.

2. 사진 주소를 짐작했더니 두 번 다 400이었다

사진은 위키미디어 커먼즈(Wikimedia Commons)에서 구했다. 위키백과에 들어가는 사진과 그림을 모아두는 저장소인데, 대부분이 자유 라이선스나 퍼블릭 도메인(저작권이 만료됐거나 포기된 상태)이라 조건만 지키면 다른 곳에서도 쓸 수 있다. (commons.wikimedia.org)

처음엔 클로드코드가 웹 검색으로 사진을 찾은 다음 썸네일 주소를 짐작해서 받으려고 했다. 썸네일은 원본을 원하는 폭으로 줄인 사본이다. 결과는 두 번 다 400 에러였다. 서버가 "그런 요청은 이해를 못 하겠다"고 돌려보내는 응답이다.

이유가 재밌더라. 커먼즈 썸네일 주소 중간에는 파일 이름으로 계산한 해시가 폴더 이름처럼 박혀 있다. 해시는 글자를 넣으면 짧은 기호열이 나오는 계산이라, 계산 규칙을 모르고 파일 이름만 봐서는 그 기호열을 짐작으로 맞히기 어렵다. (mediawiki.org) 짐작한 주소가 두 번 다 400을 낸 것도 이 해시 때문으로 보인다.

여기서 하나 더 걸렸다. 주소를 손으로 짐작해서 받는 방식이면 저작자랑 라이선스도 결국 손으로 따로 찾아 적어야 한다. 사진은 이 주소에서, 출처는 저 페이지에서. 둘이 어긋나도 아무도 모른다.. 그래서 두 번 막힌 뒤 바로 방법을 바꿨다.

▲ 짐작한 사진 주소는 두 번 다 400 에러였고 커먼즈 API 응답에는 사진 주소와 저작자, 라이선스, 원본 페이지가 함께 온다는 비교 카드 (자체 제작 이미지)

3. 커먼즈에 물어보면 사진과 라이선스가 한 번에 온다

바꾼 방법은 커먼즈의 API로 받는 거였다. API는 프로그램끼리 데이터를 주고받는 공식 창구다. 웹페이지를 사람 눈으로 보는 대신 "이 조건에 맞는 파일 정보를 줘" 하고 정해진 형식으로 물어보는 거라 생각하면 된다. (commons.wikimedia.org)

실제로 던진 질문은 이렇게 생겼다.

action=query
&generator=search&gsrsearch=<찾을 말>&gsrnamespace=6
&prop=imageinfo&iiprop=url|extmetadata&iiurlwidth=<원하는 폭>

글자가 많아 보여도 뜻은 세 개뿐이다. 첫 줄 action=query 와 둘째 줄 앞부분 generator=search 는 둘이 합쳐 "검색해서 나온 것들에 대해 물어볼게"라는 한 가지 뜻이다. 둘째 줄 끝의 gsrnamespace=6 은 검색 범위를 파일로만 좁히는 설정인데, 6번이 커먼즈에서 사진·그림 파일이 들어 있는 구역 번호다. (mediawiki.org) 셋째 줄은 각 파일의 주소와 부가 정보를 달라는 말이고, 폭을 정해주면 그 크기로 줄인 사진 주소까지 같이 계산해서 준다. (mediawiki.org)

커먼즈 서버가 돌려준 응답에는 항목마다 이름표가 붙어 있는데, 그중 꺼내 쓴 칸(항목)은 네 개다. thumburl 은 바로 받을 수 있는 크기 지정 사진 주소다. 짐작으로는 못 맞히던 그 해시 박힌 주소를 서버가 직접 만들어 주는 거라 짐작한 주소처럼 틀릴 일이 없다. 둘째 칸 descriptionurl 은 원본 설명 페이지 주소로, thumburl 과 같이 주소 정보로 온다. 나머지 둘은 extmetadata 라는 묶음 안에 들어 있다. 파일 설명 페이지에 사람이 적어둔 저작자·라이선스 같은 정보를 기계가 읽을 수 있는 형태로 내준 것이다. (mediawiki.org) 거기서 LicenseShortName(라이선스 짧은 이름)과 Artist(저작자)를 꺼냈다.

파일 제목을 이미 알 때는 검색 대신 titles=File:파일이름 으로 그 파일 하나만 콕 집어 물어보면 된다. 응답 모양은 똑같다.

▲ 커먼즈 API 질의와 응답 네 칸이 태양전지 셀 사진의 출처 표 한 줄과 보고서 캡션으로 옮겨지는 과정을 보여주는 터미널 화면과 표 (자체 제작 이미지)

4. 라이선스는 눈으로 읽지 않고 받은 그대로 옮겼다

클로드코드가 받은 네 칸을 사진이 든 폴더 옆 출처 표 파일에 그대로 한 줄씩 떨어뜨렸다. 사진 다섯 컷이면 다섯 줄이다. 캡션은 그 표를 보고 달면 되니까 캡션 근거가 자동으로 남는다.

예를 들어 태양전지 셀 사진은 표에 이렇게 한 줄로 들어갔다.

파일	원본	저작자	라이선스
`04_cell.jpg`	File:Silicon solar cell (PERC) front and back.jpg	WhistlingBird	CC BY-SA 4.0

이 한 줄을 보고 보고서에 단 캡션은 "셀 사진은 WhistlingBird의 것(CC BY-SA 4.0)이다."였다. 보고서 캡션에는 이름과 라이선스만 넣고 원본 링크는 출처 표에 남겼는데, 블로그처럼 링크가 바로 눌리는 곳이라면 원본과 라이선스 링크까지 캡션에 다는 게 맞다.

중요한 건 라이선스 판정을 사람 눈에 안 맡기고 서버가 준 값을 그대로 썼다는 거다. 설명 페이지를 열어서 "음, CC BY-SA 같네" 하고 읽어 적으면 거기서 틀릴 수 있다. 버전 숫자를 빼먹거나, 비슷한 라이선스랑 헷갈리거나. 라이선스는 읽어서 옮기는 순간 오류가 낄 자리가 생긴다. 그래서 서버가 준 문자열을 한 글자도 안 바꾸고 표에 적었다.

이게 왜 중요하냐면, CC BY 계열 라이선스는 저작자 표시와 라이선스 표시를 쓰는 사람의 의무로 걸어둔다. (creativecommons.org) 출처를 틀리게 적으면 그 사진을 쓸 조건 자체를 못 지킨 셈이 된다. 원본 설명 페이지 주소까지 남겨둔 이유도 같다. 나중에 누가 "이 사진 정말 써도 되는 거야?" 하고 물으면 그 주소 하나만 열어보면 되니까.

출처를 붙이는 것과 그 출처가 맞는 것은 다른 일이라는 얘기는 링크가 살아있다고 출처 검증이 끝난 게 아니었다에서 글 문장 쪽으로 따로 썼다. 사진도 결국 같은 얘기더라. 서버 값을 그대로 옮기면 옮기다 틀릴 자리는 사라진다. 그 값이 정말 맞는지는 원본 페이지 주소가 남아 있어야 다시 확인할 수 있는 거고.

5. AI로 그린 사진은 왜 안 넣었나

솔직히 제일 쉬운 길은 따로 있었다. 이미지 생성 AI한테 "중국 태양광 공장 사진" 하나 그려달라고 하면 남이 찍은 사진의 저작자와 라이선스를 찾아 적을 일은 없다.

근데 클로드코드는 그 길을 안 갔다. 연구보고서에 합성 사진을 넣으면 사실성이 오염된다는 판단이었다. 독자는 사진을 보면 "실제로 저렇게 생겼구나" 하고 믿는다. 그게 실제가 아니면 보고서 안의 숫자가 다 맞아도 그 페이지 하나가 거짓말을 하는 거다. 그래서 선을 이렇게 그었다. 개념이나 구조를 보여주는 도해는 직접 그리고, 실물은 실사진만 쓴다.

나도 이건 맞는 판단이라고 본다. 블로그 썸네일이면 모를까, 근거를 대려고 쓰는 문서에서 그럴듯한 가짜 사진은 장식이 아니라 오류더라. 남의 웹페이지에서 자료를 가져올 때 지켜야 할 선은 클로드코드 크롤링 입문에서 정리해 둔 적이 있는데, 사진은 거기에 라이선스라는 층이 하나 더 얹혀 있는 셈이다.

6. 도표 속 중국어 회사명이 네모 칸으로 나왔다

사진이랑 같이 도표를 만들다가 곁가지로 하나 더 걸렸다. 도표에 넣은 隆基, 阳光电源, 領跑者 같은 중국어 회사명이 전부 네모 칸으로 나왔는데, 맷플롯립(matplotlib)에 지정해 둔 애플고딕(AppleGothic) 글꼴에 중국어 간체 글자가 없어서였다. 글꼴을 ["AppleGothic", "Arial Unicode MS"] 처럼 목록으로 주니 첫 글꼴에 없는 글자만 다음 글꼴에서 빌려 그리더라(맷플롯립 3.6부터 되는 기능이다). (matplotlib.org)

▲ 애플고딕 하나만 줬을 때 중국어 회사명이 네모로 깨지고 대체 글꼴 목록을 주면 정상으로 그려지는 것을 비교한 표와 글자 조회 순서 (자체 제작 이미지)

3줄 요약

커먼즈 사진 주소를 짐작해서 받았더니 두 번 다 400이 났다. 주소 안에 박힌 해시 때문으로 보인다.
커먼즈 API로 물어보니 받을 주소와 저작자, 라이선스, 원본 페이지가 한 응답에 같이 와서 출처 표에 그대로 옮겼다.
라이선스는 눈으로 읽어 옮기지 않았고, 연구보고서의 실물 자리에는 AI가 그린 사진 대신 실사진만 넣었다.

주소를 짐작하던 방식이었으면 출처도 짐작으로 적었을 거다..

이 글은 정보 제공이 목적이고, 작성 시점 기준이다. 내용은 이후 바뀔 수 있으니 중요한 판단 전에는 공식 자료를 한 번 확인하는 게 좋다. 특정 선택을 권유하거나 결과를 보장하지 않는다.

참고한 공식 자료

위키미디어 커먼즈 외부 재사용 안내: Commons:Reusing content outside Wikimedia
커먼즈 API 창구: commons.wikimedia.org/w/api.php
파일 정보 조회 방법: MediaWiki API:Imageinfo
저작자·라이선스 메타데이터: Extension:CommonsMetadata
이름공간 번호: Help:Namespaces
업로드 파일 해시 경로: Manual:$wgHashedUploadDirectory
CC BY 4.0 라이선스 조건: creativecommons.org/licenses/by/4.0
맷플롯립 3.6 글꼴 대체 기능: What's new in Matplotlib 3.6.0