# ISBN의 함정

> Clean Markdown view of GeekNews topic #26854. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26854](https://news.hada.io/topic?id=26854)
- GeekNews Markdown: [https://news.hada.io/topic/26854.md](https://news.hada.io/topic/26854.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-02-21T07:49:37+09:00
- Updated: 2026-02-21T07:49:37+09:00
- Original source: [rygoldstein.com](https://rygoldstein.com/posts/perils-of-isbn)
- Points: 8
- Comments: 4

## Topic Body

- 영화 기록 앱 **Letterboxd**처럼 깔끔하고 실용적인 도서 기록 앱을 만들려는 시도중에, ISBN 체계의 구조적 문제가 핵심 장애물이었음  
- 책 검색 기능을 위한 **Google Books API**가 동일한 작품의 여러 **ISBN 버전**을 각각 다른 항목으로 반환하는 문제를 발견  
- 이는 **서지학적 구조(FRBR 모델)** 에서 ‘작품(work)’과 ‘표현(expression)’, ‘형태(manifestation)’가 구분되기 때문이며, 사용자는 단순히 ‘책을 읽었다’는 사실만 기록하고 싶어도 데이터가 세분화되어 있음  
- **OpenLibrary**가 ‘작품’ 중심의 데이터 구조를 제공하지만, 여전히 **중복과 불완전성**이 존재해 완전한 대안이 되지 못함  
- 영화 데이터베이스 **TMDB**처럼 책 분야에는 고품질의 **공개 메타데이터 인프라**가 부재하며, 이는 책 중심 소셜 플랫폼 개발의 주요 장애 요인임  
  
---  
  
### Letterboxd와 책 플랫폼의 비교  
- Letterboxd는 **깔끔한 인터페이스**와 **비침해적 소셜 기능**으로 영화 감상 기록을 쉽게 관리할 수 있음  
  - 사용자는 시청한 영화와 시점을 간단히 기록 가능  
- 반면 **GoodReads**는 복잡한 UI와 다단계 클릭 구조로 인해 책 기록이 불편함  
  - ‘읽은 책’, ‘읽을 책’이 한 화면에 섞여 있으며, **독서 챌린지·뉴스레터 등 부가 요소**가 공간을 차지  
  - GoodReads가 이렇게 불편한 이유는 **Amazon 도서 판매 사업의 낮은 우선순위 파생 제품**이기 때문  
- **Storygraph** 역시 유사한 문제를 가지고 있어, 사용자는 결국 **Obsidian 파일**로 개인 기록을 관리하게 됨  
  
### Google Books API와 ISBN 문제  
- 책 검색 기능을 만들기 위해 **Google Books API**를 사용했으나, 동일한 작품이 여러 ISBN으로 중복 검색되는 현상 발생  
  - 예시로 “The Last Unicorn”을 검색하면 **하드커버, 페이퍼백, eBook, 개정판 등**이 각각 다른 ISBN으로 반환됨  
- 각 ISBN은 **서로 다른 판형이나 판본**을 의미하지만, 사용자는 단순히 ‘책을 읽었다’는 사실만 기록하고 싶음  
- 이러한 구조는 **검색 및 데이터 통합**을 어렵게 만들어, 단일 작품 단위의 기록 시스템 구축에 부적합함  
  
### FRBR 모델과 ‘작품’ 단위 접근  
- 도서관학에서 사용하는 **FRBR 모델**은 도서 데이터를 네 가지 계층으로 구분  
  - **Work**(작품): 추상적 창작물 자체 (예: 소설 "The Last Unicorn")  
  - **Expression**(표현): 특정 판본  
  - **Manifestation**(형태): 특정 판본의 물리적 포맷 (페이퍼백, 하드커버 등)  
  - **Item**(개체): 컬렉션 내 개별 물리적 사물  
- Google Books는 주로 ‘표현’ 또는 ‘형태’ 수준의 데이터를 반환하지만, 사용자는 ‘작품’ 수준의 추상적 단위를 필요로 함  
- **OpenLibrary**는 ‘작품’ 중심의 데이터 구조를 제공하지만, 여전히 **중복된 항목**이 존재  
  - 예: Yoko Ogawa의 *Hotel Iris* 검색 시 동일 작품이 네 번 중복 표시  
  
### 데이터 품질과 생태계의 한계  
- **Letterboxd**는 **The Movie Database (TMDB)** 를 기반으로 작동하며, TMDB는 약 **100만 개 영화 데이터**를 보유  
- 반면 **OpenLibrary**는 **4천만 개 이상의 작품**을 포함하지만, 불완전하고 정제되지 않은 데이터가 많음  
- 영화 데이터는 상업적 플랫폼과 커뮤니티 기여가 결합되어 품질이 높지만, 책 데이터는 **규모가 크고 자금 지원이 부족**함  
- 이로 인해 **책 중심의 Letterboxd형 서비스**를 만들기 위한 기반 데이터가 부재  
  
### 결론 및 향후 시도  
- 완전한 **오픈소스 도서 메타데이터 인프라**가 존재하지 않아, 책 기록 플랫폼 개발은 영화보다 훨씬 어려운 과제임  
- 저자는 여전히 **독립적인 책 기록 시스템 구축**을 시도할 예정   
- 영화 취향을 찾는 경험처럼 **책 기록도 개인화된 접근이 필요함**

## Comments



### Comment 51524

- Author: nemorize
- Created: 2026-02-21T12:11:17+09:00
- Points: 3

그야... ISBN은 출판물의 식별자지 컨텐츠의 식별자가 아니니까...  
제목이 너무 어그로네요ㅋㅋ

### Comment 52053

- Author: roxie
- Created: 2026-02-27T23:55:51+09:00
- Points: 1
- Parent comment: 51524
- Depth: 1

컨텐츠의 식별자 자리가 공백인것 같습니다 ㅠ

### Comment 51576

- Author: yeobi222
- Created: 2026-02-22T13:41:19+09:00
- Points: 1
- Parent comment: 51524
- Depth: 1

ISBN체계가 그다지 체계적 분류에 대한 고려가 없는것도 사실이긴 해서...  
규칙상 증판마다 번호를 별도로 부여하게 되어있는데도 최하위 카테고리가 출판사다 보니, 작품별 분류의 필요성에도 불구하고 관리가 쉽지 않죠

### Comment 51505

- Author: neo
- Created: 2026-02-21T07:49:37+09:00
- Points: 2

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47063663) 
- MusicBrainz의 데이터베이스 구조가 떠오름  
  예를 들어 Nirvana의 **Nevermind** 앨범은 하나의 *release group*으로, 테이프·CD·LP·프로모션 등 다양한 매체나 국가별 재발매 버전이 존재함  
  어떤 경우엔 카탈로그 번호나 바코드가 달라 구분되지만, 어떤 경우엔 동일한 코드로 표기되어도 실제로는 다른 버전임  
  같은 녹음이라도 **리마스터링**이나 편집, 검열 등으로 달라질 수 있음  
  MusicBrainz는 이런 차이를 세밀히 추적하며, 동일 녹음인지 아닌지를 명확히 구분함  
  커버곡이나 표준곡처럼 여러 아티스트가 녹음한 경우엔 ‘work’ 단위로 작곡가·작사가 정보를 연결함  
  이런 **정교한 관계형 데이터베이스 설계**가 창작물의 동일성과 차이를 기록하는 데 매우 유용하다고 느낌  
  [관련 링크](https://musicbrainz.org/release-group/1b022e01-4da6-387b-8658-8678046e4cef)
  - 최근에는 책을 위한 **BookBrainz**라는 데이터베이스도 알파 버전으로 운영 중임  
    [bookbrainz.org/about](https://bookbrainz.org/about)  
    MusicBrainz와 유사한 스키마라면 데이터 추출이 매우 용이할 것으로 기대함
  - Bach의 더블 바이올린 협주곡 CD를 MusicBrainz에 등록하려다 **CD-ID 인덱싱 오류**를 겪은 적이 있음  
    계정을 만들어 데이터를 직접 업로드하고, 여러 번의 수정 끝에 등록 성공함  
    중국 웹사이트에서 동일한 호주판 CD 정보를 찾아 참고했는데, 시장별로 미세하게 다른 버전이 존재함을 깨달음  
    사람들은 ‘고유 식별자’를 갱신하는 데 너무 느슨하다는 점에서 MusicBrainz 팀에 깊은 공감을 느낌
  - 10000 Maniacs의 *In My Tribe* 앨범이 좋은 예시임  
    1987년판과 1989년판(‘Peace Train’ 삭제판)의 **UPC 번호가 동일**했음  
    90년대 중반 중고 CD 매장에서 삭제 전 버전을 찾느라 애쓴 기억이 있음
  - 최근 CD 바코드를 스캔해봤는데 MusicBrainz에서 90~95%는 인식됨  
    나머지는 지역별로 트랙 수가 다른 여러 버전이 존재해 헷갈렸음  
    트랙별 아티스트 정보를 명시할 수 있는 기능이 있었다면 검색 정확도가 높았을 것 같음
  - Kindle Press를 통해 출판한 책의 경우, **ISBN은 동일하지만** 최소 3개의 공식 개정판과 여러 사소한 수정판이 존재함  
    오타 수정 정도의 차이만 있어도 구분이 어려움

- **Wikidata**는 FRBR 호환 공개 데이터베이스로, 최근 몇 년간 책 관련 품질이 크게 향상됨  
  예시로 든 오가와 요코의 *호텔 아이리스*는 동일 작품이 아니라 **서로 다른 번역본**임  
  번역은 원작과 다른 파생 저작으로 봐야 함  
  다만 목록이 뒤섞여 있어 오류가 많음
  - FRBR에서는 번역도 일반적으로 **같은 작품(work)** 으로 간주함  
    OpenLibrary에서는 하나의 work로 묶고, 언어와 번역자 정보를 edition에 저장함  
    현재의 중복은 언어별 자동 병합 과정에서 생긴 문제로 보임
  - 번역을 별도 파생물로 보더라도, 검색 시에는 **하나의 주체로 묶여야** 함  
    사용자가 원작과 번역본을 함께 탐색할 수 있도록 하는 게 이상적임

- [LibraryThing](https://www.librarything.com/)을 추천함  
  Goodreads보다 훨씬 낫다고 느낌  
  책의 **WEMI 구조(work, expression, manifestation, item)** 를 구분하는 것이 중요함  
  “돈키호테를 읽었다”는 work 수준의 이야기이고, “내 책에 커피 자국이 있다”는 item 수준의 이야기임

- 주(state) 단위 독서 대회에서 책을 ISBN으로만 관리해 학생들이 찾기 어려웠음  
  그래서 WorldCat의 **ISBN 매핑 데이터베이스**를 이용해 동일 내용의 다른 ISBN을 연결하는 SQL 조인을 추가함  
  그 결과 10년간 학생들이 **추가로 백만 권 이상**의 책을 읽게 되었음  
  - SQL 쿼리가 궁금하다는 질문이 이어짐

- [Anna’s Archive](https://annas-archive.li/blog/all-isbns-winners.html)는 ISBN 관련 데이터 정리에 큰 기여를 함  
  WorldCat을 **스크레이핑**해 활용했고, 현재는 ISSN(정기간행물) 데이터베이스도 구축 중임  
  ISSN은 책에 비해 매우 부족한 상태임

- Open Library는 **Brewster Kahle**(Internet Archive 창립자)와 **Aaron Swartz**의 초기 작업에서 출발했음을 상기함  
  [관련 블로그](http://www.aaronsw.com/weblog/openlibrary)

- 실제 서점에서 책을 보고 구매했는데, 집에 와보니 **같은 판본을 이미 가지고 있는** 경우가 종종 있었음  
  ISBN으로 내 소장 목록을 검색할 수 있었다면 이런 중복 구매를 막을 수 있었을 것임  
  - 전자책만 천 권 가까이 가지고 있는데, 어떤 책을 보유 중인지 확실히 알고 있어서 그런 일이 없다는 반응이 있음

- 개인 프로젝트로 **ISBNDB API**를 이용한 책 관리 사이트를 만든 경험이 있음  
  제목 검색 시 수많은 판본과 언어, 제본 형태가 뒤섞여 결과가 매우 복잡했음  
  Jaccard 유사도 기반으로 결과를 정리했지만 완벽하지 않았음  
  **OpenLibrary**를 대안으로 검토 중임

- StoryGraph 앱이 나쁘지 않다고 느낌  
  **AI 기능을 피하고 싶은 사용자**를 배려한 인터페이스가 좋음  
  검색 기능도 우수함  
  - [Hardcover.app](https://hardcover.app)도 좋은 대안임  
    개인적으로 2017년 이후부터 사용 중이며, **탈올리고폴리**를 목표로 선택했음

- ISBN에는 **출판사 식별자**가 포함되어 있어, 동일한 책이라도 시장별로 다른 ISBN을 가질 수 있음  
  - 뉴질랜드에서는 정부 도서관 서비스를 통해 ISBN을 발급받는데, 출판사 이름을 등록해야 함  
    무료 서비스라 국가별로 다를 수 있음  
  - ISBN은 출판사나 기업이 **블록 단위로 구매**하며, 내부적으로 각 인프린트에 배정함  
    따라서 출판사명이 직접 들어가진 않지만, 구조상 식별이 가능함