대표이미지 127편이 같은 그림이었다 — 스톡 API로 하루에 푼 기록

숫자부터 셌다 — 256편 중 127편

눈으로 본 것은 「로봇 사진이 두 번 나왔다」였다. 그것만으로는 규모를 모른다. 목록 데이터를 열어 이미지 파일명으로 세어 봤다.

결과는 서른다섯 종을 127편이 나눠 쓰고 있었다. 절반이다. 원인은 두 갈래였다. 하나는 카테고리마다 둔 기본 이미지가 그 카테고리 글 전체에 그대로 붙어 있던 것, 다른 하나는 예전에 붙여 둔 외부 스톡 두 장을 열여덟 편이 공유하던 것이다.

여기서 방법이 갈린다. 생성형 AI로 글마다 한 장씩 만들면 내용에 정확히 맞는다. 실제로 그 방식으로 두 편을 만들어 봤는데 한 장에 8분에서 10분이 걸렸다. 127편이면 하루로 끝나지 않는다. 그래서 상위 글은 AI로 개별화하고, 나머지는 스톡으로 중복만 푸는 쪽으로 나눴다.

세는 김에 규격도 같이 봤다. 카테고리 기본 이미지 여섯 종은 가로 400픽셀에 세로 200픽셀이었다. 오픈그래프가 권하는 크기의 3분의 1이다. 이 크기로는 SNS에 링크를 붙였을 때 큰 카드가 아니라 작은 썸네일로 나간다. 어차피 손대는 김에 이것도 권장 규격으로 다시 만들었다.

기준을 이렇게 두면 목표가 분명해진다. 예쁜 이미지를 고르는 것이 아니라 고유 이미지 수가 전체 편수와 같아지게 만드는 것이다. 이 문장이 뒤에 나오는 판정 기준이 된다.

고칠 자리가 «세 갈래»였다

처음에는 두 곳만 고치면 되는 줄 알았다. 목록 카드가 읽는 데이터 파일 하나, 그리고 글 파일 안의 공유용 메타 태그 하나다. 실제로 그 둘을 고치고 나서 다시 세었더니 중복 0이 나왔다.

그런데 화면을 열어 보니 같은 그림이 그대로 깔려 있었다. 빠진 곳이 있었다. 글 파일 안에서 기본 이미지를 참조하는 자리가 160건 더 있었다.

• 글 상단 배경 — 그 글 자신의 배경인데 기본 이미지를 쓰고 있었다 (48편)
• 본문 아래 「관련 글」 카드 — 다른 글의 썸네일인데 역시 기본 이미지였다 (88건)
• 구조화 데이터 안의 이미지 필드 (4건)

덧붙여, 같은 사이트 안에서도 트랙마다 구조가 달랐다. 어떤 트랙은 상단 배경과 공유용 이미지가 같은 사진이고, 다른 트랙은 상단은 사진이면서 공유용은 따로 만든 카드였다. 후자를 사진으로 채워 놓았다가 목록에서 혼자 튀는 것을 뒤늦게 발견했다. 파일 이름 앞에 자리를 뜻하는 말을 붙여 두면 이런 혼동이 줄어든다.

이 셋을 놓친 채 「중복 0」이라고 판정할 뻔했다. 데이터만 세면 화면에 남은 것을 못 본다. 판정은 반드시 라이브 화면 쪽에서 한 번 더 해야 한다.

관련 글 카드에서 한 가지가 더 걸렸다. 카드의 alt 문구로 그 글을 찾아 이미지를 붙이려 했는데 28건이 전부 실패했다. alt는 축약형이었다.

Pixabay와 Pexels 중 무엇을 쓸 것인가

먼저 확인한 것은 디자인 도구의 스톡을 API로 끌어올 수 있는지였다. 결론은 안 된다. 그 도구의 공개 API에서 자산을 다루는 기능은 사용자가 직접 올린 파일만 대상으로 하고, 내장 스톡을 검색하는 통로가 없다. 스톡은 편집기 안에서만 쓸 수 있다.

그다음 후보가 Pexels와 Pixabay였다. 갈린 지점은 «우리가 하려는 일이 그 서비스가 권하는 방식인가»였다.

Pixabay 문서는 이미지를 쓸 의도라면 먼저 자신의 서버로 내려받으라고 적는다. 영구적인 핫링크는 금지한다. 우리는 받아서 우리 서버에 올린다 — 정확히 그 방식이다. 요청 한도는 60초당 100회이고, 별도의 출처 표기 의무는 없다.

Pexels도 상업적 이용이 가능하고 라이선스 자체가 출처 표기를 요구하지는 않는다. 다만 이용약관에 「콘텐츠를 그 자체로(standalone) 판매하거나 배포할 수 없다」는 조항이 있다. 글의 대표이미지로 쓰는 것이 여기 걸리는지 아닌지는 해석이 갈릴 수 있는 자리다. 크롭만 한 이미지가 SNS 카드로 나가는 형태라면 더 그렇다.

그래서 기본을 Pixabay로 잡았다. 판단이 애매한 조항이 없는 쪽을 고른 것이다. Pexels를 쓸 때는 워터마크를 얹어 새 창작물 쪽으로 두기로 했다.

도구에 넣은 것 — 중복 방지가 핵심이다

API를 부르고 이미지를 받아 자르는 것은 어렵지 않다. 진짜 문제는 다른 데 있었다. 도구가 같은 사진을 다시 고르면 지금 푸는 문제를 도구가 되풀이한다.

그래서 받은 사진의 고유 번호를 파일에 적고, 다음 회차 검색 결과에서 그 번호를 빼도록 했다. 이것이 이 도구에서 가장 중요한 한 줄이다.

걸린 것들 — 검색어는 딴 데로 간다

가장 많이 걸린 것은 동음이의어였다. 프로그래밍 언어 이름을 넣으면 뱀이 나오고, 모델 이름을 넣으면 동물이 나온다. iOS 개발 글에 쓸 사진을 찾으려고 「swift」를 넣었더니 칼새 사진이 줄줄이 나왔다. 「fine tuning」은 기타 줄을, 「comparison」은 자동차를 가져왔다.

더 위험한 것은 상표였다. 유명 플랫폼 화면이나 로고가 찍힌 사진이 결과에 섞인다. 스톡 서비스가 배포를 허용해도 그 안의 로고까지 상업적으로 쓸 수 있는 것은 아니다. 두 건을 골라 놓고 뒤늦게 발견해 다시 골랐다.

사람 얼굴이 크게 나온 컷도 뺐다. 초상 문제가 걸릴 수 있고, 글 내용과도 대개 맞지 않는다.

그리고 목업 사진에 안내 문구가 박혀 있는 경우가 있다. 화면 자리에 「여기에 디자인을 넣으세요」 같은 영문이 그대로 인쇄된 사진인데, 작게 보면 눈치채기 어렵다.

검색어를 고치는 요령은 단순하다. 낱말 하나로는 거의 실패하고, 맥락을 이루는 낱말을 두세 개 붙이면 결과가 제자리를 찾는다. 「swift」는 새가 나왔지만 「ios app development xcode」로 바꾸니 앱 설계 스케치가 나왔다. 그래도 첫 판에 맞는 경우는 절반쯤이라, 후보를 먼저 훑어보는 단계는 결국 남는다.

검색 결과의 순서에도 함정이 있었다. 후보를 먼저 보고 「세 번째 것」이라고 골라 두었다가 다음 호출에서 인덱스가 한 칸씩 밀렸다. 정렬이 호출마다 흔들리기 때문이다. 그 뒤로는 순번이 아니라 사진 고유 번호로 집도록 도구를 고쳤다.

결과와 남은 것

아침에 서른다섯 종 127편이던 중복은 하루 만에 0이 됐다. 판정은 라이브 데이터로 했다. 전체 256편에 고유 이미지 256종, 중복 0, 결손 0이다.

중복을 세는 과정에서 하나가 더 나왔다. 남아 있던 여덟 편은 이미지가 «겹친» 것이 아니라 아예 없는 상태였다. 공유용 메타 태그 자체가 없어서 SNS에 링크를 붙이면 카드가 비었다. 중복보다 나쁜 상태인데, 중복만 세면 이것이 안 보인다.

남은 것도 있다. 외부 서비스에 직접 연결해 쓰는 이미지가 72편 남아 있다. 지금은 정상적으로 표시되지만 그쪽에서 내리면 그날 깨진다. 이것도 같은 방식으로 내려받아 옮길 예정이다.

정리하면, 이 작업에서 시간이 걸린 곳은 API를 부르는 부분이 아니었다. 고칠 자리를 빠짐없이 찾는 것과 고른 사진을 눈으로 확인하는 것이었다. 자동화는 앞뒤로 사람이 한 번씩 보는 구조일 때 안전하다.

자주 묻는 질문