▲

Claude Code로 바이브 코딩한 책장 프로젝트

 (balajmarius.com)
7P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • 약 500권의 책을 자동으로 분류·시각화하기 위해 Claude Code를 활용한 개인 프로젝트 사례
  • 기존 ISBN 스캐너나 Goodreads가 루마니아어 판본을 인식하지 못해 실패했던 문제를, OpenAI Vision API와 Claude의 스크립트로 해결
  • 90% 정확도의 메타데이터 추출 후, 나머지는 수작업으로 보정하고 Open Library·SerpAPI를 통해 표지 이미지를 자동 수집
  • Framer Motion을 이용한 스크롤 기반 애니메이션과 페이지 수 기반의 책 두께 표현으로 실제 책장 같은 인터랙션 구현
  • AI가 실행을 맡고 사용자가 미적 판단과 선택을 담당하는 협업 구조를 보여주며, ‘실행 비용은 줄지만 취향은 여전히 인간의 몫’ 임을 강조

완성된 Bookshelf - https://balajmarius.com/bookshelf 구경하기

프로젝트 개요

  • 약 500권의 책을 보유했지만 목록을 관리하지 못한 상태에서, AI 도구를 이용해 자동 분류·시각화 시스템을 구축
  • 단순한 스프레드시트 대신, Claude Code를 통해 실행 단계를 자동화하여 오랫동안 미뤄온 개인 프로젝트를 완성
  • 프로젝트의 핵심은 기술적 완성도보다 실행의 병목을 제거하는 데 있음

문제 인식

  • ISBN 스캐너 앱과 Goodreads가 루마니아어 판본이나 희귀 출판물을 인식하지 못해 데이터가 불완전
  • 불완전한 데이터는 오히려 혼란을 초래해 프로젝트가 반복적으로 중단됨
  • 필요한 것은 완벽한 앱이 아니라, 불완전함을 견딜 수 있는 시스템 구조였음

데이터 수집과 처리

  • 책의 표지와 책등을 촬영한 470장의 사진을 기반으로 데이터 구축
  • Claude가 작성한 스크립트가 각 이미지를 OpenAI Vision API로 전송해 저자·제목·출판사를 추출하고, 결과를 JSON 파일로 저장
  • 약 90% 정확도를 달성했으며, 나머지 오류는 조명·손상·해상도 문제로 발생
  • 남은 10%는 수작업으로 수정, 이후 새 책 추가 시 동일 파이프라인을 자동 실행

표지 이미지 보완

  • Open Library API로 표지를 가져왔으나 절반은 품질이 낮거나 잘못된 이미지
  • Claude가 품질 점수화 및 오류 플래그 시스템을 추가하고, 실패 시 SerpAPI를 통해 Google 이미지 검색으로 대체
  • 약 460권 중 10권만 수동 보정으로 해결, 자동화 효율 확보

책장 UI 구현

  • 단순한 커버 그리드 대신 실제 책장처럼 책등 중심의 시각 표현을 구현
  • Claude가 색상 추출(color quantization) 과 대비 텍스트 색상 계산을 수행
  • Open Library의 페이지 수 데이터를 이용해 책 두께를 반영하고, 약간의 변동치를 추가해 현실감 강화
  • 결과적으로 실제 책장과 유사한 시각적 질감 구현

애니메이션과 인터랙션

  • Framer Motion으로 스크롤 시 책등이 기울어지는 스크롤 기반 애니메이션 추가
  • 초기에는 React 상태 업데이트로 인해 끊김 현상이 있었으나, motion values와 spring 애니메이션으로 수정
  • 수정 후 부드러운 움직임 구현, 실험 비용이 낮아져 반복 시도가 가능해짐

불필요한 기능 제거

  • 무한 스크롤 기능을 추가했으나, 컨테이너 높이 불일치와 스크롤 오류로 사용자 경험 저하
  • 기술적으로는 작동했지만 필요하지 않아 삭제
  • “작동하지만 불필요한 코드”를 제거하는 판단은 인간의 역할임을 강조

모바일 대응과 스택 뷰

  • 모바일에서 가로 스크롤이 불편해 세로형 스택 뷰를 추가
  • Claude가 기존 코드를 분석해 애니메이션 타이밍, 색상 추출, 스크롤 투명도 처리 등을 재활용
  • 별도 설명 없이 완전한 새 컴포넌트를 생성, AI의 코드 이해·재구성 능력을 확인

인간의 역할과 결론

  • Claude가 모든 코드를 작성했지만, 사용자는 다음을 결정함
    • 90% 정확도 수용
    • 10개의 표지 수동 수정
    • 책등 중심 디자인 선택
    • 불필요한 기능 삭제
    • 애니메이션의 감각적 완성 확인
  • 최종 결과물은 460권의 책을 자동 분류·시각화한 웹 기반 책장
  • AI가 실행을 담당하고 인간이 취향과 판단을 담당하는 협업 모델을 보여줌
  • 결론적으로 “실행 비용은 계속 낮아지지만, 취향은 여전히 인간의 몫”
▲
ahwjdekf 21시간전  [-]

10개만 수작업 필요했다고 주장하고 있으나, 자위에 불과함. 그 10개를 찾기위해선 전수검사가 필요했음. 웩더독

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 지금의 vibe coding은 작은 규모의 프로젝트에 딱 맞는 시점임
    프로젝트가 커지면 맥락 관리가 어려워지고, LLM이 불필요하게 많은 코드를 생성하거나 미묘한 버그를 만들기 쉬움
    그럴 때는 다시 브레인스토밍 모드로 돌아가서 설계만 LLM의 도움을 받고, 실제 코드는 직접 작성하거나 뼈대를 짜고 LLM이 채워 넣게 하는 게 좋음
    LLM은 기존 코드를 조금만 수정하거나 기존 구조를 활용하는 데는 아직 약함. 대부분 새로운 추상화를 덧붙이려 함

    • 나도 동의함. 다만 Claude Code를 쓰면 큰 프로젝트에서도 잘 작동함
      나는 모듈 구조를 직접 설계하고, 결과를 명확히 알고 있음. 모든 코드를 세밀히 검토하고, 좋은 프롬프트와 컨텍스트 관리(예: 샘플 코드 제공, agent.md 가이드 등)를 하면 충분히 통제 가능함
    • 이런 문제는 사실 인간 개발자도 겪는 소프트웨어 아키텍처의 고전적인 이슈임
      코드베이스가 커지면 모듈 간 강한 결합(tight coupling) 이 성능을 떨어뜨림
      해결책은 “구현이 아닌 인터페이스에 맞춰 프로그래밍하라”는 원칙임
      각 모듈의 경계를 명확히 하고, 필요한 부분만 노출하는 인터페이스를 별도 파일로 분리해 Claude나 동료가 그 인터페이스만 사용하게 하면 됨
      이렇게 하면 컨텍스트가 줄어들어 Claude가 더 잘 작동함
      프로젝트가 더 커지면 인터페이스 자체가 많아질 수 있으니, 그때는 더 큰 단위로 분리하거나 변경 범위를 줄이는 식으로 관리해야 함
    • 지금은 vibe-coding부터 copilot 스타일, 설계 보조, 완전 수동 코딩까지 스펙트럼이 생겼음
      이제는 꽤 큰 프로젝트에서도 이들을 섞어 쓸 수 있는 수준임
    • 지금은 작은 프로젝트에 적합하지만, 결국 모든 소프트웨어가 이런 식으로 작성되는 시대가 올 것 같음
    • Ken Miles의 “7000rpm” 인용이 떠오름. 어느 정도 규모에서 이런 한계가 생기는지 궁금함

  • “더 나은 앱이 아니라, 불완전함을 견디는 시스템이 필요했다”는 문장이 인상 깊었음
    Claude가 아이디어를 만든 게 아니라 구현을 맡았고, 나는 취향을 담당했다는 식의 글쓰기 스타일이 멋있음

    • 하지만 이런 문체는 인간보다는 AI가 쓴 듯한 느낌이 강함
      요즘 이메일에서도 “우리가 바퀴를 재발명하지 않았다. 우리가 바퀴다” 같은 문장이 자주 보임
    • 나는 오히려 이런 문체를 초보 블로거의 글로 느꼈음
      거창한 단어를 쓰지 않고, 같은 문장 구조를 반복하는 점이 인간의 습관처럼 보였음
      AI는 보통 문장 패턴을 무작위로 섞는데, 이건 오히려 일관된 틀을 유지함
      아직 편집 감각이 덜 다듬어진 사람이 의도적으로 멋지게 쓰려는 느낌임
      다른 사람들은 이걸 AI 냄새로 느꼈는지 궁금함
    • 나도 공감하지만, 이번엔 이상하게 AI 느낌이 덜했음
      다만 LinkedIn에서는 그런 문체가 너무 많아서 어제 결국 폭발해서 글을 올렸음
      아마 가치감과 분위기의 미묘한 조합이 AI 감지에 영향을 주는 듯함
    • “그 정도면 충분했다”는 문장이 마음에 남음

  • 아직 vibe coding으로 성공한 대형 프로젝트는 본 적이 없음
    대부분 이미 학습 데이터에 존재하는 작은 프로그램임
    정말 혁신적이라면 새로운 압축 알고리즘이나 최적의 외판원 문제 해법 같은 걸 만들어보길 바람

    • 하지만 굳이 그럴 필요가 있을까? 망치에게 못질 이상의 걸 기대하지 않듯이
      AI 코딩 도구는 자신이 잘하는 영역에 집중해야 함
      나는 이런 도구로 작은 비즈니스용 자동화 프로그램을 자주 만듦
      이 덕분에 예전엔 불가능했던 일을 할 수 있게 되었고, 생산성이 10배는 늘었음
    • 맞음, 하지만 대부분의 소프트웨어는 이미 존재함
      Perfect Software 글처럼, 누군가에게 완벽한 앱은 그 사람의 취향과 목적에 맞는 것임
      LLM 덕분에 이런 개인 맞춤형 완벽 소프트웨어를 쉽게 만들 수 있게 되었음
    • 나는 LLM 에이전트로 두 개의 Rust/C++ 대회를 이끌었음
      대회1, 대회2
      내 점수가 다른 참가자들의 개선을 유도했음
    • 대부분의 코딩은 반복적이고 이미 학습 데이터에 있음
      AI가 이런 지루한 작업을 제거해주면 인간은 창의적인 일에 집중할 수 있음
    • 이런 비판은 좀 우울함. 지금은 탐구와 학습의 시기임
      작은 문제를 해결하는 이런 vibe coding이 훨씬 가치 있는 시간 사용임

  • 나도 며칠 전 같은 아이디어로 Claude로 책장 앱을 만들어봤음
    nindalf.com/books
    덕분에 독서량이 늘었고, 하이라이트와 노트를 보기 편해졌음
    Claude의 UI 제안은 내가 직접 만든 것보다 훨씬 나았고, 백엔드도 거의 비슷했음
    단, 가끔 이상한 검증 로직을 고집했는데, 내가 직접 수정하니 “당신이 맞아요!”라고 인정함. 이런 경우는 드물었음

    • 멋지다. 하이라이트와 노트는 Kindle에서 가져오는 건가?
      나도 비슷한 책장 앱을 만들었는데, 오디오북 노트 관리는 아직 좋은 방법을 못 찾았음
    • 나도 비슷한 걸 만들고 있음. Claude가 엉뚱한 결정을 내릴 때가 많지만, 무거운 가이던스와 워크트리로 관리하면 여전히 빠름
      네 버전도 흥미로움
    • 혹시 코드 공개할 수 있나? 나도 연간 독서 기록 앱을 만들고 싶음

  • 나도 비슷한 걸 시도했는데, 내 경우는 Claude 실패 사례였음
    andrewblinn.com에서 책장 이미지를 클릭할 수 있게 만들고 싶었음
    하지만 Claude는 Goodreads 링크를 자주 잘못 생성했고, 유효하지 않은 ID를 붙였음
    책등 인식도 부정확해서 결국 Figma로 수동 작업함
    Claude가 제안한 자동화는 너무 느리고 비쌌음

  • 나도 매년 읽은 책을 HTML로 만든 정적 책장 페이지를 만들곤 했음
    예전엔 Delicious Library를 재현하려고 글도 썼음

    • 나도 그 앱을 기억함. Mac 초창기 시절의 즐거운 추억이었음
      굳이 필요는 없었지만 책을 정리하는 게 즐거웠음
    • 완전히 잊고 있었는데, Delicious Library의 감성은 이런 앱에 정말 잘 어울림

  • “460권은 규모 문제가 아니다. 작동하는 코드를 지울 시점을 아는 건 AI가 대신 못한다”는 말에 공감함
    나도 900개 평점과 550권 책 데이터를 가진 앱을 만들었는데, 무한 스크롤이나 복잡한 검색은 브라우저가 버틸 때까진 안 넣기로 했음
    지금은 “페이지 내 검색”으로 충분함

  • “정확도 90%면 충분하다”는 말이 좋았음
    LLM이 새로운 오류를 만들더라도, 세상엔 원래 오류 허용 시스템이 많음
    이런 태도는 반(反)AI 시각을 가진 사람에게도 도움이 될 것 같음

    • 나도 동의함. LLM과의 대화에서 가끔 웃긴 결과가 나오지만, 90%가 유용하다면 이미 구글 검색보다 낫다고 생각함

  • 나도 moviesonthe.computer에서 영화 감상 기록 앱을 vibe coding으로 만들었음
    “나만의 Letterboxd 클론”이라는 명확한 아이디어로 시작하니 빠르게 진행됨
    이런 개인 맞춤형 앱 제작 능력은 엄청난 힘임
    다만 현재 도구들은 비개발자에게 사고방식 자체를 가르치는 데는 부족함

    • 나도 영화 기록 앱을 만들고 싶었는데, Letterboxd는 마음에 안 들었음
      네 말처럼 프로그래밍 배경이 있는 사람이 이런 프로젝트를 더 쉽게 프롬프트할 수 있음

  • 솔직히 이 사람이 만든 결과물의 사용성은 형편없음
    본인은 성취감을 느꼈겠지만, 실제로는 생산성보다는 엔터테인먼트용 장난감에 가까움
    그래도 이런 시도에서 배울 점은 있음

    • “moo point”라니, 소의 의견처럼 의미 없다는 농담이 떠오름
      하지만 개인용 도구라면 즐거움 자체가 목적일 수도 있음
      나도 어릴 때 BASIC으로 재미 삼아 코딩했음. 그게 생산적이진 않았지만 충분히 가치 있었음
답변달기