삐삐북 개발기 3편 — 책 검색 API 삼파전: 네이버 vs 카카오 vs 알라딘

책 데이터가 없으면 앱이 없다

독서 기록 앱의 핵심은 책을 검색하고 등록하는 것입니다.

책 정보를 직접 입력하게 할 수도 있습니다. 제목, 저자, 출판사, 표지 이미지를 하나하나 입력하는 방식. 하지만 이건 사용자 경험이 너무 나쁩니다. 누가 매번 그렇게 입력하겠습니까.

책 이름이나 바코드로 검색해서 바로 등록할 수 있어야 합니다. 그러려면 책 데이터를 제공하는 API가 필요했습니다.

내 서버에 모든 책 DB를 구축하는 건 불가능한 얘기입니다. 오픈 API를 찾는 수밖에 없었습니다.

조사해보니 책 검색 오픈 API를 제공하는 곳이 꽤 있었습니다.

각각 무료로 사용할 수 있었습니다. 하지만 제공하는 데이터의 품질과 형식이 모두 달랐습니다.

독서 기록 앱에서 책 표지 이미지는 생각보다 중요합니다. 내가 읽은 책들이 표지 이미지와 함께 나열되는 게 앱의 시각적 핵심입니다.

네이버와 카카오 API를 둘 다 써봤습니다.

네이버: 책 표지 이미지가 충분한 해상도로 제공됩니다. 앱에서 크게 보여줘도 깨지지 않습니다.

카카오: 데이터 자체는 나쁘지 않지만, 책 표지 이미지 사이즈가 너무 작았습니다. 썸네일 수준의 이미지가 제공되는 경우가 많아서, 앱에서 크게 보여주면 픽셀이 보였습니다.

결론: 네이버 API를 기본으로 사용하기로 했습니다.

네이버를 기본으로 하되, 다른 API도 선택해서 검색할 수 있게 했습니다.

네이버에서 검색이 잘 안 될 때 카카오나 알라딘으로 전환할 수 있습니다. 각 API마다 색인되어 있는 책 목록이 조금씩 다르기 때문에, 하나에서 안 나오는 책이 다른 곳에서 나오는 경우도 있습니다.

국립중앙도서관 API는 특히 오래된 책이나 학술 자료를 찾을 때 유용했습니다.

각 API마다 response 형태가 완전히 달랐습니다.

같은 "책 제목"이라도 어떤 API는 title, 어떤 API는 bookName, 어떤 API는 titleStatement로 제공합니다. 날짜 형식도 다르고, 저자가 배열로 오는 경우도 있고 문자열로 오는 경우도 있습니다.

Swift에서 JSON을 파싱할 때 Codable 프로토콜을 씁니다. 각 API마다 다른 구조의 Decodable 모델을 만들어야 했습니다.

이게 꽤 번거로웠습니다. 단순히 모델 4개를 만드는 게 아니라, 각 API의 응답을 앱 내부에서 사용하는 통일된 책 데이터 모델로 변환하는 작업이 필요했습니다.

예를 들어 네이버 API response → NaverBookResponse → BookItem(내부 모델) 형태로 변환. 같은 과정을 카카오, 알라딘 각각에 대해 반복합니다.

그 변환 과정에서 API마다 없는 필드, 빈 값, 예상치 못한 형식 등의 엣지 케이스를 처리하는 게 생각보다 시간이 걸렸습니다.

API에서 가져온 책 데이터를 그대로 Firestore에 저장하지 않습니다.

앱에서 필요한 필드만 골라서, 앱의 데이터 구조에 맞게 변환해서 저장합니다. "가공에 가공"이라고 표현할 만한 과정입니다.

API response → 앱 내부 모델 → Firestore 저장 모델

이 세 단계의 구조가 명확하게 분리되어 있어야 나중에 API를 바꾸거나 추가할 때 다른 부분을 건드리지 않아도 됩니다.

초반에 이 구조를 잘 잡아둔 덕분에, 나중에 API를 추가하는 작업이 상대적으로 수월했습니다.