요약
Zotero는 몇 년에 걸친 느린 구상 끝에 20년을 버티는 소프트웨어가 됐습니다.
조지메이슨대학교 역사·뉴미디어 센터에서 Zotero 개발을 이끈 역사학자 댄 코언이 출시 20주년을 맞아 쓴 회고입니다. AI로 소프트웨어를 순식간에 만드는 시대에 이 느린 과정이 주는 교훈을 짚었습니다.
왜 중요한가
- 코드를 바로 뽑아내는 시대에도 무엇을 만들지 정하는 구상은 줄일 수 없다는 사례입니다.
- 코언은 당시 원하는 것을 정확히 몰라서 LLM에 줄 프롬프트도 쓸 수 없었을 것이라고 했습니다.
- 여럿이 천천히 생각을 모은 방식이 쉽게 사라지지 않는 탄탄한 토대를 남겼다는 주장입니다.
핵심 내용
- 팀은 큰 탁자에 둘러앉아 오래 이야기했고, 코언은 그중 일부가 헛된 시간이었다고 인정했습니다.
- 출발점은 웹 자료를 모으는 Web Scrapbook과 메모·인용을 관리하는 Scribe라는 두 도구였습니다.
- 2004년 Firefox가 나온 날 밤, 코언은 Firefox 확장 기술(XUL)로 온라인판 Scribe를 만들자는 메일을 보냈습니다.
- 2006년 10월 공개 베타는 한 달 만에 이용자 6만 명을 모았고, 지금은 2,000만 명 넘게 씁니다.
- 이름은 SmartFox와 Firefox Scholar를 거쳐 알바니아어 사전에서 찾은 Zotero로 정해졌습니다.
HN 반응
- 프롬프트도 쓸 수 없었다는 대목에 공감이 많았고, 기존 제품을 참고해 에이전트에 맡기면 된다는 반론에는 구조를 찾는 일이 어렵다는 재반박이 나왔습니다.
- Zotero가 그냥 잘 돌아가고 데이터도 열린 형식으로 내보낼 수 있다는 칭찬이 많았지만, 동기화 서버를 직접 운영하기는 까다롭다는 불만도 있었습니다.
궁금해하실 분들을 위해 말씀드리면:
이 글은 Zotero 이야기예요. https://www.zotero.org/
학계 사람이 아니라면 Zotero를 모를 수도 있어요.
정말 쓰는 맛이 나는 도구예요. 모든 앱이 이랬으면 좋겠어요.
저는 지금 보고 있는 책들까지 전부 여기서 읽어요. https://teachyourselfcs.com/ 에서 가져온 책들이에요.
글을 스냅숏으로 떠 두는 것도 기가 막히게 잘해요. 해커뉴스 글을 가져와서 밑줄 치고 메모할 때 늘 써요.
게다가 기기가 바뀌어도 알아서 척척 동기화되고, 저처럼 ADD 있는 수집광이 웹에 파일을 너무 많이 쌓아 둬도 끄떡없어요.
한마디로 이 소프트웨어는 그냥 되고, 잘 돼요. 그래서 Zotero를 만든 분이 소프트웨어 개발에 관해 이야기하면 귀를 기울이게 돼요.
게다가 역사 이야기도 있는 재미있는 글이에요. 이 글을 Zotero에 저장한 다음에 읽어 보세요.
관련 없는 이야기지만, 사람들이 소프트웨어를 두고 “그냥 된다(just works)”고 말하는 걸 정말 좋아해요.
그 말에는 어떤… 단순함이 담겨 있고, 저도 제 모든 개발에서 그걸 쫓고 있거든요. 소프트웨어를 “되긴 되는데…” 수준에서 끌어올리는 데 드는 노력이 참 흥미로워요. 99%의 경우에 동작하는 걸 만들 수는 있어도, 우리가 좋아하는 “그냥 된다”의 품질에는 끝내 못 미치기도 하죠.
정말로, 그 경지에 이르기까지 얼마나 많은 노력이 드는지 아니까, “그냥 되는” 소프트웨어를 쓸 때면 곧바로 기쁨이 느껴져요.
어떤 종류의 소프트웨어냐에 따라서도 달라집니다.
미용실 예약 앱이나 호텔 와이파이 로그인처럼 “정해진 길(on rails)”을 따라가고 따로 배우거나 훈련받지 않아도 돌아가야 하는 것이 있고, 전문 창작 작업용 복잡한 애플리케이션은 완전히 다른 이야기입니다.
그리고 그냥 이상한 것들도 있습니다. 요즘 사정이 있어 모바일 게임을 들여다보게 됐는데, 온보딩 경험이 끔찍한 게임이 얼마나 많은지 정말 충격이었습니다. 예를 들어 “옷 모으기” 장르의 최고 게임들, Love Nikki 같은 게임은 부드러운 온보딩으로 게임 규칙을 가르쳐 주고 이야기로 끌어들여서 어쩌면 푹 빠지게 만듭니다. 저는 (페이스북이 나오기 전에) 소비자용 소셜·엔터테인먼트 앱을 개발할 때 “쉬운 온보딩은 사용자에게도 좋고 수익에도 좋다”고 믿었고, 그걸 이해하는 창업자들과 일하면서 스스로를 뛰어넘도록 채찍질당했습니다. 이 장르의 대부분 게임은 UI가 끔찍하고 규칙을 설명하려 들지도 않습니다. 사용자가 게임 속 화폐를 이해하든 말든 상관하지 않기 때문입니다. 그들은 빨간 점이란 빨간 점은 다 누르고 조금만 어려워져도 초록색에서 접어 버리는 최악의 “고래(whales)”만 신경 쓰니까요.
“느린 소프트웨어(slow software)” 이야기로 돌아오면, 플랫폼 관점에서 5년은 영원이라 무언가를 시작하면 다시 만들어야 할 수도 있다고 생각합니다. 저는 웹 플랫폼 말고 다른 것으로 개발하는 걸 정당화하기가 어렵습니다. (“한 번 쓰면 VR 헤드셋처럼 생각도 못 한 플랫폼에서도 돌아간다”, “제발, 1990년대에는 윈도 소프트웨어 업체마다 InstallShield 엔지니어가 최소 한 명씩 있었고 IT 부서는 모든 데스크톱을 업데이트하느라 머리를 쥐어뜯었다는 걸 알고는 있습니까?”, “App Store가 업데이트를 거절하는 데 3주나 걸렸다고요? 그럼 뭘 기대했습니까?” 같은 이유로요.) 그런데 지금 제가 작업 중인 앱은 2021년 이후 업데이트되지 않은 React 컴포넌트에 의존하고 있고, 청구서가 날아올 때가 됐습니다.
아, 드레스업 게임의 현실은 제 개인적인 불만거리예요. 형편없는 온보딩 튜토리얼은 문제의 하나일 뿐이고요. 아트 디렉션은 그냥 끔찍한 경우가 많고, 제대로 된 게임 루프는 (창의적인 건 말할 것도 없고) 거의 없고, 소액결제가 기본 수익 모델이에요. 솔직히 왜 그런지 모르겠어요. 어쩌면 수익이 그리 크지 않아서 실력 있는, 하다못해 성실한 게임 개발자가 모이지 않는 걸까요? 저는 이런 게임이 대체로 게임 자체를 싫어하거나 신경 쓰지 않는 사람, 아니면 드레스업 게임을 특히 싫어하는 사람이 만든 거라고 받아들이게 됐어요. 최고의 드레스업 게임은 보통 닌텐도가 만드는데, 닌텐도는 게임 디자인도 탄탄하고 게임 개발 문화 전반이 강하거든요.
덧붙이자면, 저는 제 취향을 채우려고 직접 그린 작은 드레스업 게임을 만들기 시작했어요. 프로그래머가 아니라서 정말 엉망이고 친구들한테만 보여 줘요. 비디오게임 만들기는 어릴 때 종이 인형 옷을 만들던 것만큼 쉽지는 않지만 정말 재미있고, 왠지 30년은 젊어진 기분이에요. :D
네, 그런 게임들은 사람들이 생각하는 것보다 잠재력이 크다고 생각합니다. 저는 투표 메커니즘을 정말 좋아하고(랭킹 시스템에 시간을 많이 썼습니다), 이야기가 좋은 게임도 있습니다. “니키가 대륙을 탐험하며 친구를 사귀고 놀라운 실력을 증명하는 훈훈한 이야기”부터 “고대 궁정에서 벌어지는 처절한 생존 싸움”까지 다양합니다.
좋은 투표 시스템이 뭘까요? Dress to Impress(모바일은 아니고 엄청나게 인기 있는 Roblox 게임이에요)를 살펴본 적이 있는데, 제 생각엔 투표 방식이 좀 불쾌했어요. 플레이어들이 서로의 코디에 투표하고 점수는 같이 하는 플레이어들이 준 점수의 합이라서, 플레이어가 모두에게 최저점을 주도록 유도하거든요. 게임은 “불공정한” 투표자를 감지해 그 표의 가중치를 낮추는 식으로 이런 행동을 “처벌”하려 하지만, 메커니즘을 바꿔서 애초의 유인을 손보는 편이 낫다고 생각해요. 코디마다 점수를 주는 대신 순위를 매기게 하면 되지 않을까요? 제가 놓친 다른 문제도 있겠지만요. 멀티플레이어 게임은 별로 안 해 봐서요.
(한편 랭킹을 “게이밍”할 생각을 하는 건 게임의 재미를 깎는다고 믿지만, Dress to Impress는 엄청나게 인기가 많으니 어쩌면 이 답답함이 인기의 비결일지도 몰라요. 아이들이 이 게임을 하는 게 이 장르에 경쟁작이 없어서인지, 어느 정도의 경쟁적 독성이 중독성이 있어서인지는 모르겠어요.)
저는 정치학 관점에서도, 랭킹 시스템 개발 관점에서도 투표 이론에 관심이 있습니다. 사실 꽤 우울한 주제인데, 대중은 아예 관심이 없다는 결론에 쉽게 도달할 수 있기 때문입니다.
한마디로, 쌍대 비교 순위(pairwise rankings)는 실재하고 사람 사이에서 비교할 수 있는 반면, 사람마다 척도를 다르게 쓸 수 있습니다. “나는 베이글 가게가 덮밥집보다 조금 더 좋은데, 셀리악병이 있는 일행의 의견이 내 의견보다 더 중요하다” 같은 상황은 다루기 어려운 문제입니다. 다음을 보세요
https://brocku.ca/MeadProject/Thurstone/Thurstone_1927f.html
이제 선택지가 N개 있을 때 모든 사람이 N(N-1)쌍을 평가할 필요는 없습니다. 선호는 서로 상관되어 있고 추이적이어야 하기 때문입니다. Elo나 그 논문의 방법처럼 토너먼트를 운영하고 점수를 계산하는 데 쓸 수 있는 알고리즘이 많습니다. Covet 게임은 쌍대 비교 랭킹을 쓰는데 평가가 좋은 걸로 압니다.
사회적 의사결정 이론으로 돌아가면, 승패를 걸고 플레이어를 팀으로 묶는 건 아마 좋지 않을 겁니다. 친구와 옷을 공유하는 건 정말 재미있는 메커니즘이라고 생각하지만 (뭔가를 사거나 얻으려고 열심히 하게 만들 수도 있고요!), 친구를 돕거나 해칠 수 있게 되면 N인 게임에서 연합이라는 골치 아픈 문제 전체에 얽히게 됩니다.
흥미롭네요. 공유해 주셔서 감사해요.
방금 Covet을 잠깐 해 봤는데, 두 가지 중 하나를 비교해서 고르는 행동이 왜 재미있을 수 있는지 상상이 가요. 정말 단순하고 “멍한” 재미가 필요할 때 제 코디는 만들지 않고 게임 속 코디에 투표만 하고 있을 것 같아요. 생산적인 효과는 아니지만, 제가 아는 한 큰 문제가 될 만큼 중독성이 있지도 않고요.
팀도 개념으로는 통할 수 있지만 메커니즘이 친사회적이고 우정을 북돋우게끔 아주 신중하게 설계해야 한다고 생각해요. 관련해서 좋은 글이 있어요: https://www.gamedeveloper.com/design/game-design-patterns-for-building-friendships
죄송한데, 뭐라고요?
“빨간 점(red dot)”은 모바일 앱이 배지 왼쪽 위에 작은 빨간 점을 찍어서 확인해 달라고 알려 주는 것을 말합니다.
“초록색에서 접는다(fold green)”는 라스베이거스까지 가야 도박을 할 수 있던 옛날부터 쓰던 도박 은어입니다. (블랙잭, 룰렛 등의) 테이블에서 돈을 잃고 있을 때 현금(예: 미국에서는 “초록색”)으로 칩을 더 사는 것을 가리킵니다.
제가 Zotero에서 마음에 안 드는 건 자체 호스팅이 정말 골치 아프다는 점이에요. 우리 학과에서는 박사과정생들을 위해 로컬 Zotero 서버를 띄워서 사실상 무제한 동기화를 줄 수 있을 텐데, 너무 까다로워요.
어떤 점이 어려우신가요? 필요한 건 WebDAV뿐입니다. 저는 제 것과 파트너의 Zotero 저장소에 nextcloud 서버를 쓰는데, 설정이 정말 간단합니다.
저는 Zotero에 불만이 많지만(한동안 파워 유저를 희생하면서 쉬운 쪽으로 수준을 낮춰 왔습니다) 쉬운 비공개 동기화는 분명 그중 하나가 아닙니다.
WebDAV로는 전부 동기화되지 않아요. 교수진이 동기화하는 양이면 메타데이터만으로도 저장 용량 한도에 걸릴 거예요.
정말입니까?
Zotero 사이트에는 이렇게 나와 있습니다:
https://www.zotero.org/support/sync
제 Zotero 계정을 보면 모든 메타데이터 저장은 무료이고 용량에 포함되지 않는다는 걸 확인할 수 있습니다(zotero.org 기준으로, 서지 항목 수천 개의 메타데이터를 동기화하는데도 계정의 300Mb 저장 용량은 하나도 쓰지 않고 있습니다). Zotero가 용량으로 세는 건 첨부 파일 저장소뿐인 듯하고, 그건 전부 제 WebDAV로 동기화됩니다.
제가 뭘 놓치고 있는 걸까요?
지금 얘기는 자체 호스팅에 관한 겁니다.
저는 이 논의가 데이터를 자체 호스팅해서 Zotero가 제공하는 무료 저장 한도로도 충분하게 하는 것에 관한 거라고 생각했는데요? 그런 용도라면 첨부 파일을 자체 호스팅 WebDAV 저장소에 두는 걸로 전혀 문제없습니다.
(제가 답글을 단 분은 첨부 파일에 WebDAV를 쓰더라도 부서 사용자들이 메타데이터만으로 저장 한도를 넘길 거라고 하셨는데, 제 경험으로도 온라인에서 찾을 수 있는 모든 자료로도 그건 사실이 아닌 것 같습니다.)
저는 로컬에서 호스팅하는 Wallabag를 쓰고, 제 모든 컴퓨터와 스마트폰 등에 동기화해요.
Zotero가 Wallabag보다 더 많은 걸 하는지도 모르지만, 저는 지금까지 만족해요.
동의해요. “오픈 소스”이긴 한데 그 딱지에는 커다란 별표를 붙이고 싶어요. 오픈 웨이트(open weights)로만 공개된 AI 모델이 가장 먼저 떠오르네요.
문서를 파고들 수도 있지만 열성 사용자에게 묻는 편이 낫겠습니다. 지금도 내 데이터를 깔끔하고 쉬운 형식으로 꺼낼 수 있나요? 저는 한때 어떤 노트 앱에 올인했는데 점점 나빠졌고 빠져나오기가 정말 번거로웠습니다. 그래서 이제는 뭘 시작하기 전에 항상 그 점을 따져 봅니다.
Zotero가 언젠가 쓰레기가 되거나 그냥 사라지더라도 제 데이터에 접근해서 다른 곳으로 옮길 수 있을까요?
사용자 데이터는 csv, xml, latex로 내보낼 수 있고, 원본 문서는 원래 형식과 pdf로 받을 수 있습니다.
전부 오픈 소스이고 로컬 우선(local-first)이기도 합니다. 클라이언트 간 동기화에 직접 호스팅하는 WebDAV 서버를 붙일 수도 있고요. 게다가 비영리 단체가 개발하고 있습니다.
찍어 보자면 Evernote 아닌가요? :)
답글 대상이 된 그 사람은 제가 아닙니다. 저는 마이크로소프트의 OneNote로 그런 일을 겪었습니다. 정말 마음에 들었고, 그 앱이 만든 XML 파일을 파싱하는 데 아무 문제가 없어서 다른 시스템으로 데이터를 흘려 보낼 수 있었는데, 그러다 100% 클라우드 저장소로 넘어갔습니다.
“마이크로소프트가 놀랍도록 좋은 걸 만들었는데, 작업 표시줄에 OneNote 아이콘을 다섯 개, 콧구멍에도 세 개 쑤셔 넣어서 사람들이 쓰레기라고 생각하게 만들고, 그러고는 망쳐 놓았다”는 전형적인 사례였습니다. 액티비전을 인수하는 게 좋은 생각이라고 한 바로 그 머리에서 나왔음이 틀림없습니다.
저는 Zotero에 플러그인을 몇 개 붙여서 .bib 파일을 만들고, 그 파일을 바탕으로 Emacs에서 노트를 씁니다. 이 구성이 마음에 드는 이유는 Zotero로 파일을 빠르게 저장하는 편리함을 누리면서도, 추출한 모든 데이터를 자동 내보내기로 열린 형식에 저장하기 때문입니다. 내일 Zotero가 사라지더라도 제 노트는 org 파일에, 인용은 bib 파일에 그대로 남아 있을 겁니다.
혹시 이것에 관해 블로그에 쓰신 적 있나요? 아니면 Zotero와 Emacs를 함께 쓰는 법에 관한 자료를 추천해 주실 수 있나요? 정말 흥미로워 보여요!
에이전트 개발이 대단하다는 사람들이 있습니다. 그렇게 많은 걸 그렇게 빨리 찍어낼 수 있으니까요. 하지만 그렇다고 그중 무엇이든 진짜로 좋고 믿을 만하다는 뜻은 아닙니다.
정말 통찰력 있고 탄탄한 것들은 결국 기하급수적으로 더 많이 쓰이게 되고, 그러면 개발 시간이 더 든다는 선형적인 비용은 (점근적으로) 비용 대비 효과 계산에서 무시해도 될 만큼 작아집니다.
양을 강조하고 질을 외면하는 태도를 보니 EWD1175[0]의 한 대목이 떠오릅니다.
[0] https://www.cs.utexas.edu/~EWD/transcriptions/EWD11xx/EWD1175.html
마지막의 곁가지 이야기는 좀 이상하네요. 네덜란드 칼뱅파 상인 계급이야말로 분명히 "양적"인 성향이 강했잖아요…
제가 아는 360 사용자들은 하나같이 그 기종에 향수가 많습니다.
잘 설계된 기종이었습니다. 360 아키텍처가 지금까지 살아 있는 건 PDP-11, VAX, 68k를 무너뜨린 함정을 피했기 때문입니다. 저는 PDP-11을 정말 좋아했지만요. 나왔을 당시에는 범용 운영체제가 어떤 모습이어야 하는지 아는 사람이 아무도 없었던 것도 사실이고, VM을 제품화해서 필요한 만큼 많은 운영체제를 동시에 돌릴 수 있게 되기까지 10년이 걸렸습니다.
품질과 개발 속도 사이의 트레이드오프는 언제나 소프트웨어 공학의 기본 원칙이었습니다. 에이전트 코딩이 그 방정식을 크게 바꿔 놓긴 했지만, 방정식 자체는 여전히 있습니다.