코딩 보조 도구로 끝내지 못할 프로젝트 되살리기

• 오래 묵은 개인 프로젝트는 새로 학습하기보다 구현을 끝내는 데 초점이 맞춰져 있어, 코딩 보조 도구를 시험하기에 잘 맞았음
• YouTube Music을 OpenSubsonic API로 노출하는 shim을 다시 구현해, 서로 다른 Subsonic 클라이언트가 같은 방식으로 붙을 수 있게 만듦
• 최소 구조와 구현 규약을 먼저 고정한 뒤 짧은 반복 주기로 작업하면서, OpenAPI 스펙 기반 stub 생성과 실제 클라이언트 연결 테스트를 함께 돌림
• 스펙만 맞춘 초기 구현은 실제 연결에서 바로 깨졌고, 요청 로그 확인과 단위 테스트 추가를 반복하면서 검색·재생이 되는 수준까지 끌어올림
• 학습용 stretch 프로젝트가 아니라 그냥 있었으면 하는 프로젝트라면, 코딩 보조 도구는 미뤄 둔 작업을 실제로 쓰는 서비스로 바꾸는 데 큰 도움이 됨

---

프로젝트 배경과 접근 방식

• 오래전에 손댔다가 끝내지 못한 개인 프로젝트는 AI 코딩 보조 도구를 시험하기에 적합했음
  • 다시 살린 대상은 YouTube Music과 OpenSubsonic API를 잇는 shim이었음
  • OpenSubsonic은 음악 스트리밍 클라이언트와 서버를 분리할 수 있게 하는 API 계약으로 쓰였음
  • 서버는 Navidrome, 데스크톱 클라이언트는 Feishin, Android는 Symfonium을 사용했음
• shim은 YouTube Music을 OpenSubsonic API에 맞게 노출해 어떤 클라이언트에서도 붙을 수 있게 만듦
  • 메타데이터 조회에는 ytmusicapi, 스트리밍에는 yt-dlp를 프로그램적으로 호출했음
  • 기본 스트리밍은 비교적 쉽게 붙었지만, 규격에 맞게 모든 엔드포인트를 구현하는 데 긴 꼬리 작업이 남아 있었음
• 이 프로젝트는 새롭거나 독창적인 문제보다 명확한 스펙 구현이 중심이라 코딩 보조 도구와 잘 맞았음
  • Claude Code와 Opus 4.6으로 처음부터 다시 구현하는 실험으로 진행함

초기 세팅

• 시작점은 구조를 미리 제한한 최소 프로젝트였음
  • uv 프로젝트를 만들고 fastapi, pydantic, ytmusicapi, yt-dlp를 의존성으로 추가함
  • main.py는 FastAPI 예제 메인 파일로 바꾸고 OpenSubsonic OpenAPI 스펙을 폴더에 넣음
  • README에는 서버 역할, 사용 라이브러리, 문서 URL, openapi.json 위치를 짧게 적어 둠
  • 빈 TODO 파일을 추가하고 /init으로 CLAUDE.md를 생성함
• CLAUDE.md에는 구현 규약을 따로 적어 반복 지시를 줄였음
  • 메서드 인자와 반환값에 타입 애너테이션과 docstring을 요구함
  • 데이터 모델링은 Pydantic V2 규약으로 맞춤
  • docstring은 Google 스타일의 args, returns 섹션을 요구함
  • 테스트는 상위 레벨 함수와 assert, fixture를 쓰는 최신 pytest 스타일로 맞춤
• 이 시작점은 git repository로 묶어 둠

MVP 구현 흐름

• 작업 방식은 계획 모드와 짧은 반복 주기로 굴렸음
  • 다음 작업을 프롬프트로 던지고 초기 계획에서 빠진 점이나 문제를 확인함
  • 어긋나는 경우 관련 리소스 링크를 추가로 주거나, 여러 선택지가 있으면 검색 도구로 더 관용적인 방식을 찾게 함
  • 작업 뒤에는 "Accept and clear context"를 사용해 컨텍스트를 비우고 반복함
• 첫 구현은 OpenAPI 스펙에서 신형 JSON 엔드포인트만 stub으로 만드는 데 집중했음
  • 예전 XML 엔드포인트와 새 JSON 엔드포인트가 함께 있었지만, 새 쪽만 처리하도록 범위를 좁힘
  • 구현 후에는 모든 메서드가 맞는지 다시 점검하는 검증 단계를 넣음
  • 스펙이 있어도 첫 시도에는 실수가 나왔고, 두 번째 점검에서 대부분 잡힘
• 큰 변경 뒤에는 /init을 다시 돌려 CLAUDE.md를 새 상태에 맞게 갱신함
• 다음 단계는 검색과 스트리밍이 되는 최소 기능을 정의하고 붙이는 작업이었음
  • Subsonic 클라이언트를 연결해 곡을 검색하고 재생할 수 있는 최소 기능을 목표로 삼음
  • 검색은 ytmusicapi, 스트리밍은 yt-dlp를 사용함

실제 연결에서 드러난 문제와 보정

• 겉보기에는 그럴듯한 구현이 빨리 나왔지만, 실제로 Feishin에 붙이면 바로 무너졌음
  • 클라이언트를 직접 테스트하고 서버 요청 로그를 Claude Code에 넘기며 반복 수정함
  • 스펙만으로는 드러나지 않는 세부 차이도 있었고, 예를 들어 엔드포인트의 .view 접미사는 벗겨내야 했음
• 오류가 날 때마다 단위 테스트를 새로 만들어 회귀를 막음
• 몇 번 반복하지 않아도 Feishin에서 실제로 오디오가 재생되기 시작했음
  • 핵심 문제는 stub 엔드포인트가 아무것도 반환하지 않는 데 있었음
  • 대부분의 엔드포인트는 비어 있더라도 구조가 맞는 응답을 돌려주도록 바꿔야 했음
• 다만 이런 수준의 MVP는 예전 POC와 크게 다르지 않았고, 실제 사용성은 이후의 긴 꼬리 작업에 달려 있었음

긴 꼬리 작업과 전체 기능 확장

• OpenSubsonic 문서 기준으로 API는 약 80개 엔드포인트가 15개 카테고리에 퍼져 있었음
• MVP에 필요한 범위는 비교적 작았음
  • getLicense, getUser, getGenres, getMusicDirectories는 비어 있지만 유효한 컬렉션을 반환함
  • getSong은 쿼리 파라미터의 ID를 그대로 돌리고 기본값을 채우는 pass-through로 처리함
  • search3는 간단한 ytmusicapi 호출로 구현함
  • stream은 asyncio.to_thread로 감싼 yt-dlp 호출로 "bestaudio" 포맷 URL을 추출함
  • getCoverArt는 yt-dlp로 커버 이미지 URL을 뽑음
• 실제 Subsonic 클라이언트 전체 기능을 지원하려면 추가 작업이 필요했음
  • ytmusicapi 호출에는 단순한 메모리 캐시를 넣어 사용량 제한을 피함
  • 음악 메타데이터 저장에는 sqlite를 쓰고 browsing 카테고리의 모든 엔드포인트를 구현함
  • getTopSongs도 top songs 목록을 질의해 처리함
• 스트리밍 중에는 곡을 디스크에 저장해 재다운로드를 피했음
  • 클라이언트가 다운로드가 끝나기 전에 stream 엔드포인트 연결을 끊으면, 미완성 파일을 정리하는 추가 처리가 필요함
• 이런 작업들은 원래 손으로도 할 수 있었지만 끝내 하지 못했던 부분이었고, 배포 계획이 없어서 인증처럼 어려운 부분은 여전히 건너뜀
• 최종적으로는 짧은 저녁 시간 안에 Subsonic 클라이언트가 연결되는 동작하는 서비스를 만들었고, 프로젝트 이름은 Sub-standard로 붙임

어디에 쓰는 것이 맞는가

• 코딩 보조 도구를 무조건 밀어붙이기보다는 의존으로 인한 역량 저하에 대한 우려도 함께 두고 있었음
• 개인 프로젝트는 크게 두 갈래로 나뉘었음
  • 배우고 성장하기 위한 stretch 프로젝트
  • 그냥 존재했으면 좋겠다고 느끼는 프로젝트
• 이번 프로젝트는 두 번째 갈래에 속했고, 코딩 보조 도구는 그동안 끝내지 못했던 바람을 실체화하는 데 잘 맞았음
  • 원래라면 손대지 못했을 프로젝트를 실제로 가지게 됐고, 읽지 못한 책 더미를 하나 줄이는 감각에 가까웠음
• 중요한 기준은 두 번째 갈래 프로젝트를 하느냐보다, 첫 번째 갈래의 학습용 프로젝트도 계속 함께 하고 있느냐에 있었음

[GN⁺]

Hacker News 의견들

• 가장 자주 버려두는 프로젝트가 비디오게임이었음
  수십 개의 중단된 프로젝트 폴더가 있는데, 이제는 그걸 실험으로 다시 받아들이고 있음
  지난주에 그중 하나를 Claude로 다시 돌려봤는데 정말 잘 맞았고, 방향도 바로 잡아줬음
  애초에 버린 프로젝트라고 말해뒀더니 V0 게임플레이 루프부터 끝내고 거기서 재미를 붙여 확장하자고 밀어줘서 포기하지 않게 됐음
  게임 디자인 아이디어를 주면 돌아가는 코드를 내주고, procedural 알고리즘 논문을 주면 구현까지 가져오고, 아이템 브레인스토밍도 하고, 그래픽 에셋도 만들고, 심지어 lore 구축도 도와줬음
  Claude Code + Godot 조합은 정말 재미있고, 오랜만에 컴퓨터를 쓰는 게 이렇게 즐거웠음

  • LLM을 it가 아니라 he라고 부르는 걸 처음 봤음
    비난하려는 건 아니지만 꽤 흥미로우면서도 살짝 불편하게 느껴졌음
  • 나는 정반대임
    수십 개의 실험 폴더가 있었는데, 그중 상당수가 이제는 실제 프로젝트가 되어감
  • 요즘 재미있는 건 몇 달 전이나 1년 전에 agent driven development로 시작했다가 막혀서 멈춘 프로젝트를, 최신 Claude나 codex로 다시 집어 들고 더 밀어붙이는 일임
    이제는 실행까지 되는 것도 있고, 여전히 에이전트가 감당하기엔 너무 복잡한 것도 있음
    그래도 개인용 앱을 만드는 일은 점점 쉬워지고 있음
    머지않아 “Alexa, 냉장고 음식 사진을 찍어서 영양 정보를 모으고, 운동 앱과 동기화하고, 건강 앱의 목표에 맞는 재료와 비교하고, 예산·지역·식단 제한에 맞는 더 좋은 재료를 이메일로 알려주는 iPhone 앱 만들어줘”라고 말하면 15분 안에 앱이 생기는 수준까지 갈 것 같음
  • Godot은 LLM과 잘 맞게 설계된 도구는 아닌 듯함
    예를 들어 잘못된 tres 파일이 몇 번 나왔고, LLM이 ID를 생성하게 두는 것도 꽤 불안정하게 느껴졌음
  • procedural 쪽에서는 LLM을 procedural loop의 일부로 넣어보는 실험도 하고 있음
    일종의 라이브 내러티브를 그 위에 얹는 방식임
    로컬 모델은 아직 느리고 약하지만, 그래도 어떤 결과를 내는지 보는 건 꽤 흥미로웠음

• 정말 훌륭함
  이제 개인용 소프트웨어가 엄청나게 많아졌음
  어제는 MediaWiki에 완전히 통합된 네이티브 텍스트 에디터를 만들었고, 링크 자동완성과 문법 입력 보조까지 붙였음
  이런 소프트웨어는 다른 사람에겐 가치가 거의 없어서 나 말고는 만들 이유가 없고, 나도 예전엔 시간이 너무 오래 걸려서 못 만들었음
  그런데 에이전트에게 코딩을 맡기면 병목은 구현이 아니라 내 주의력이 되고, 머릿속의 빈 슬롯에 이런 개인용 작업을 던져 넣는 방식이 잘 맞음
  정말 좋은 시기라고 느낌

  • 몇 주 전에 1998년에 시작한 Quake 2 mod를 드디어 끝냈음
    AI 덕분에 COVID 이후 번아웃과 반쯤 해둔 프로젝트 더미를 넘어서게 됐음
    오늘은 터미널 관련 RDP 도구도 고쳤고, 10년 전에 OpenRA에 올린 이슈도 다시 잡고 있음
    엔진은 10배 빨라졌고 pathfinding도 이제는 대체로 제대로 돌아감
  • 정말 엄청남
    개인 도구가 120개쯤 되고, 병목이 구현에서 컨텍스트 스위칭으로 옮겨간 게 정확히 맞음
    그래서 이제는 프로젝트 루트마다 markdown 파일을 두고, 멈출 때마다 상태와 다음 단계를 적어둠
    그래야 다시 돌아왔을 때 20분 동안 “내가 어디까지 했지?”를 복구하는 비용을 안 냄
    어차피 다른 사람은 안 쓰니까 edge case 처리나 문서화 압박도 없고, 내 문제만 정확히 해결하고 바로 다음으로 넘어가면 됨
  • AI 없이 얼마나 오래 지냈는지 궁금함
    지금 느끼는 생산성 폭발을 보면, 이렇게 많은 작은 필요를 쌓아두는 데도 시간이 꽤 필요했을 것 같음
  • 부활절 Scavenger Hunt 계획용 앱도 만들었음
    얼마나 니치한지 생각하면 웃길 정도임

• 코드는 원래 쓸 줄 알았지만 시간이 없었고, AI는 오픈소스 프로젝트를 세상에 내놓게 해준 완전한 게임체인저였음
  예전엔 만들 동기까지는 안 났던 Linux용 로컬 GUI 앱들을 이제는 신나게 만들고 있음

  • Sambervise: https://github.com/edward-murrell/sambervise
    Samba 4 Active Directory Domain Controller를 원격 관리하는 Linux GUI 앱임
  • Krbtray: https://github.com/edward-murrell/krbtray
    Linux Mint / Cinnamon과 GtkStatusIcon을 쓰는 GTK 환경용 Kerberos 티켓 관리 GTK3 시스템 트레이 앱임
  • 이건 진짜 AI 코딩에 마음이 기울게 만듦
    둘 다 내가 실제로 필요해서 찾던 종류의 앱이기 때문임
  • 또 하나 중요한 변화는 대규모 리팩터링 비용이 크게 줄었다는 점임
    코딩 어시스턴트 덕분에 모듈 설계까지 포함한 깊은 구조 변경을, 예전보다 훨씬 적은 시간으로 시도해볼 수 있게 됐음
    물론 대가가 없는 건 아니고, 일부 모델은 유지보수성 기준에 못 미치는 코드를 자주 내놓음
    작성 시간을 아꼈다고 해서 반복 수정, 정리, system prompt나 instruction 파일 보강에 드는 시간이 사라지는 건 아님

• 도구를 너무 쓰면 deskilling될까 걱정한다는 말에는 크게 동의하지 않음
  나는 밀레니얼인데, 손도구와 옛날 목재 이음 방식으로 가구를 만듦
  누구에게 배운 것도 아니고, 온라인 자료를 보며 익혔을 뿐인데도 결국 원하는 건 배울 수 있었음
  나중에 이 기술을 잃을까 두렵지 않은 이유도, 필요하면 다시 익히면 되기 때문임
  책도, 영상도, 도구도, 목재도 사라지지 않음
  AI를 쓴다고 해서 손으로 코드를 자주 안 친 탓에 뇌에 블랙홀이 생기는 건 아님
  알츠하이머처럼 정보를 영영 잃는 것도 아니고, 잠깐 다시 데우는 시간이 들 뿐 다시 금방 돌아옴
  코딩하다 관리로 갔다가 몇 년 뒤 돌아온 사람들도 조금 녹슬었을 뿐 다시 집어듦
  특히 개인 프로젝트라면 굳이 Opus 토큰을 태울 필요도 없음
  값싼 구독으로 MiniMax 같은 걸 쓰고, 컨테이너에서 yolo mode로 돌리고, 컨텍스트와 프롬프트, 웹 검색, beads 같은 티켓 시스템만 주면 됨
  급한 일도 아니니 brainstorm → plan → implementation → testing 순서를 지키고, mock이나 unit test만이 아닌 실제 테스트 수단만 넣어두면 시간과 돈을 아끼면서 결국 완성 가능함

• 12년 전에 내 하루/주/월이 얼마나 남았는지 막대 길이로 보여주고, 날씨도 최고·최저 기온과 구름량 등을 막대로 표현하는 간단한 앱을 만들려 했음
  텍스트와 ASCII로는 어느 정도 됐지만, 매일 쓰고 싶을 정도의 인터페이스를 만드는 데 실패했고 그래픽 UI는 끝내 못 만들었음
  그래서 Claude Code에 원하는 그래픽 인터페이스를 설명하고 돌려봤더니, 딱 내가 원하던 앱이 나왔고 내가 몰랐던 날짜 파서 버그까지 찾아줬음
  지금은 그 앱을 화면 구석에 늘 띄워두고 있음
  다음에는 아이들 학교가 없는 날 아침 알람을 자동으로 꺼주는 iPhone 앱을 만들 생각임
  iPhone 앱은 전혀 모르고 배울 시간도 없어서 예전엔 엄두가 안 났음
  개인용 앱에서는 Claude Code가 정말 훌륭하고, 코드 품질이 아주 중요하지 않으니 결과물을 그대로 써도 충분함

  • Claude Code는 개인용 앱에 정말 잘 맞음
    내가 몇 년 동안 쓰던 Mac용 clipboard manager가 OS 업데이트 뒤로 이상해졌고, App Store의 대체 앱들도 내가 원하는 기능이 없었음
    그래서 Simon Willison의 SwiftUI vibe coding 글을 보고 Claude Code로 직접 만들었음
    몇 번 반복은 필요했지만, 지금은 Mac 메뉴바에서 내가 원하던 기능과 그 이상을 다 해주고 있음
    특히 CC에게 추가 기능 아이디어를 물어봤더니 내가 생각 못한 옵션을 길게 제안해줘서, 고른 것들을 그대로 구현시킨 게 꽤 인상적이었음
    이틀 전에는 LibreOffice의 새 markdown 편집 컴포넌트 비슷하지만 더 작고 가벼운 전용 markdown 에디터가 갖고 싶어졌음
    그래서 GPT 5.5로 개요를 짜고 CC로 구현했더니, 두 번의 vibe coding 세션만에 파일 열기·생성, 워드프로세서 같은 편집, canonical markdown 저장을 하는 가벼운 네이티브 Mac 앱이 거의 완성됐음
    markdown table만 아직 없고, 그건 오늘 더 시켜볼 생각임
    https://simonwillison.net/2026/Mar/27/vibe-coding-swiftui/
    https://news.ycombinator.com/item?id=47298885
  • 정말 그럼
    뭔가 만드는 건 좋아하지만, 가끔은 그냥 만들어진 결과를 빨리 얻고 싶을 때가 있음
    특정 목적의 개인 도구를 주말 하나 통째로 날리지 않고 얻고 싶을 때 LLM 도움은 정말 좋고, 코드 품질은 그다지 중요하지 않음
  • 앱을 직접 만들 필요조차 없을 수도 있음
    iPhone에서는 기본 Shortcuts 앱으로 해결 가능함
    모든 알람을 끄는 shortcut을 만들고, 캘린더 같은 신호를 읽어 특정 날짜나 시간에 알람을 켜고 끄도록 할 수 있고, 정기 스케줄로 돌리면 됨

• 사이드 프로젝트는 대체로 하고 싶은 마음이 없으면 할 가치가 적다고 봄
  과정과 경험이 우선이면 여가고, 결과가 우선이면 일이라고 부름
  결과를 위해서만 사이드 프로젝트를 많이 한다면 결국 자유시간에 일을 하는 셈인데, 그게 정말 자유인지 의문임
  현대 사회는 이미 우리에게 지나치게 많은 결과를 요구하니, 사이드 프로젝트만큼은 정신을 위해 남겨두고 싶음
  다만 더 큰 선을 위해 믿는 목적이 있다면 예외일 수 있고, 그런 목적은 과정 자체를 풍부하게 만들 수 있음

  • 취미가 많고, 프로그래밍은 그중 하나일 뿐임
    다른 취미를 더 재미있게 해줄 소프트웨어가 필요할 때가 있는데, 그렇다고 취미 X의 시간을 빼서 그 소프트웨어를 직접 만들고 싶지는 않을 때가 있음
    게다가 그런 작업은 내가 재미로 하고 싶은 종류의 코딩이 아닌 경우도 많음
    이런 지점이 내겐 LLM 보조 코딩의 sweet spot이었고, 실제로 다른 취미를 더 즐기기 위한 helper 앱을 여러 개 만들었음
    여전히 취미 시간은 맞지만, 그 취미가 코딩일 필요는 없음
  • 코딩 자체를 위해 코딩한다면 그럴 수 있음
    하지만 해결하고 싶은 itch나 이루고 싶은 야망이 있는데 시간이나 동기가 부족했던 경우라면, 그걸 왜 자유시간의 노동이라고 봐야 하는지 모르겠음
    예전엔 주말이나 휴가를 다 잡아먹던 프로젝트가 이제는 15분 만에 뼈대를 세울 수 있고, 그건 오히려 일의 반대편에 가까움
  • 이 관점에 공감하고, 꽤 건강한 태도라고 봄
    30년 넘게 프로그래밍해왔지만 커맨드라인 앱만으로도 늘 만족했고, 최근에야 Qt를 배워 제대로 된 데스크톱 앱 UI를 붙이기 시작했음
    학습 곡선이 매우 가팔랐지만 이제는 어느 정도 넘었음
    그런데 LinkedIn에 앱 스크린샷과 무료 오픈소스라고 올렸더니, 정작 나를 채용하지도 않을 LinkedIn식 사람들에게서 수백 개의 댓글이 달렸음
    “우리 워크플로우에 통합하고 싶다”거나 “이걸 시도한 사람이 처음은 아니다” 같은 반응이었는데, 전혀 동기부여가 안 됐고 오히려 남 좋은 일만 하거나 쓸데없는 비판만 받는 느낌이 들었음
    그 충격으로 한 달쯤 손을 놨다가, 결국 내가 좋아했던 건 Qt를 배우고 예전 프로그램들이 살아 움직이는 걸 보는 과정 자체였다고 정리했음
    그래서 이제는 이걸 내 project car처럼 다룸
    계속 뜯고 고치고, 데이터 모델을 완전히 갈아엎어 다른 설계의 장단점을 보고, 그래픽 뷰도 직접 만들고, 언어 번역도 붙여봄
    기능적으로는 이미 끝났지만 내부 구조가 완전히 다른 버전이 다섯 개쯤 있고, 바로 그게 재미임
    업무 중 하루 종일 잘 쓰고 있고, LinkedIn에는 다시는 언급하지 않게 됐음

• 개인 repo 안에 노트 앱 시도작이 세 개나 있었고, 전부 아이디어와 자유시간 사이의 틈에서 멈춰 있었음
  그런데 Claude Code 덕분에 정말 원하던 하나를 두 달 만에 완성했음
  만드는 과정 자체가 지금까지 찾은 최고의 취미였고, 게임이나 스크롤보다 훨씬 나음
  몇 년 동안 품고 있던 아이디어가 마침내 출시되면 그 앱에는 내 일부가 더 깊게 들어가게 되고, 이런 걸 만드는 솔로 빌더는 앞으로 훨씬 많아질 것 같음

  • 그런데 누가 그걸 살까는 별개의 문제임
    오래된 프로젝트를 다시 만드는 걸 깎아내리려는 건 아니지만, 시장은 극도로 특화된 프로젝트들로 넘쳐날 가능성이 큼
    예전엔 앱 박스에 사양서가 붙어 있었는데, 이제는 사용 목적과 범위를 설명하는 새로운 모델링 언어 같은 게 필요할지도 모르겠음

• 내 경험도 거의 똑같았음
  비교 집계용 사이드 프로젝트가 1년 넘게 20% 완성 상태로 멈춰 있었고, 한 달에 한 번 열어서 해야 할 일 목록을 보다가 지쳐 탭을 닫곤 했음
  그런데 Claude와 주말 몇 번 같이 붙으니 반쯤 만들어진 벽을 넘어섰음
  놀라웠던 건 순수한 속도가 아니라, 뭔가 하려면 먼저 내 오래된 코드를 한 시간씩 다시 머리에 적재해야 하는 재진입 비용이 사라졌다는 점이었음
  과장된 hype은 짜증나지만, 이런 도구를 비웃는 사람들 대부분은 정작 이런 지루한 작업에 얼마나 쓸 만한지 직접 써보지 않은 것 같음

• 항상 감당할 수 있는 것보다 아이디어가 더 많았고, 그중엔 꽤 좋은 것도 있었음
  AI 도구 덕분에 이제는 그중 더 많은 것들을 그럭저럭 돌아가는 형태로 구현할 수 있게 됐음
  아이러니하게도 그런 구현의 가치는 빠르게 떨어지고 있음
  몇 주 전에는 브라우저에서 돌고 서버가 필요 없는 작은 검색 라이브러리를 만들었는데, Elasticsearch 스타일에 term/matching query와 aggregation을 대부분 지원하고, ANN vector search도 WebGPU로 붙였음
  거의 “feature X 넣자” 하면 바로 되는 식이었고, 실제 웹사이트들에도 이미 써봤음
  규모 확장은 안 되지만 블로그나 문서 사이트에는 아주 좋고, 문서 사이트는 https://querylight.tryformation.com/에 있음
  내가 상상한 대로 정확히 동작하고, Elasticsearch의 긴 꼬리 기능들도 큰 노력 없이 더 넣을 수 있을 것 같음
  반면 GitHub 반응은 꽤 미지근했음
  이제는 다들 AI로 자기 것을 만들기 바빠서 남의 노력을 크게 반기지 않는 듯하고, 사실 그게 이해되기도 함
  검색 라이브러리가 필요하면 직접 생성해도 되고, AI가 적당한 걸 골라주게 해도 되기 때문임
  애초에 이걸 만드는 데 엄청난 노동이 든 것도 아니었음
  이런 프로젝트의 경제적 가치는 빠르게 떨어지고 있음
  그래도 나는 만드는 걸 좋아해서 계속하고, 이런 도구를 다루는 학습 곡선을 익히는 일도 중요하다고 봄
  앞으로도 해야 할 일은 많겠지만, 사람들은 더 적게 지불하면서도 괜찮은 결과를 기대할 것이고, 그 기대를 맞추려면 도구 숙련이 필요함
  결국 가능한 범위가 넓어지면 야망의 기준도 같이 올라갈 뿐이고, AI가 대신 일해줄 테니 사람은 기대도 안 해도 된다고 생각하면 오산임
  나도 지난 몇 달 동안은 아주 긴 시간 일하고 있음

• 몇 년 동안 매주 여러 개의 제품 아이디어를 떠올렸지만 전부 Apple Notes에만 쌓여 있었음
  그런데 지난 한 달 동안 그중 세 개를 실제로 쓸 수 있는 beta로 만들었고, 지금은 셋 다 매일 쓰고 있음