오래 쓰이는 소프트웨어는 천천히 만들어집니다

AI 요약

Zotero는 연구 자료를 모으고 정리하며 인용하는 무료 연구 도구로, 수십 개 언어로 2천만 명 넘게 사용합니다. 글쓴이는 Zotero의 시작을 돌아보며, AI가 코드를 빠르게 만들어주는 시대에도 소프트웨어의 방향을 정하는 데는 시간이 걸린다고 말합니다. 초기 팀은 원하는 제품을 미리 알고 있지 않았습니다. 어떤 문제를 풀지, 웹과 데스크톱의 장점을 어떻게 결합할지 여러 해 동안 함께 논의하며 구체화했습니다.

웹 스크랩 도구와 서지 관리 프로그램

2001년 George Mason University의 Center for History and New Media에 합류한 글쓴이는 과학사 자료를 온라인에서 수집하고 보존하는 프로젝트를 맡았습니다. 직접 만든 Web Scrapbook은 브라우저에서 이미지와 링크를 골라 공유하는 웹 앱이었습니다. 다만 암호를 암호화하지 않고 전송하는 등 보안이 허술했고, 학술 자료에 필요한 메타데이터와 인용 기능도 부족했습니다. 동료 Elena Razlogova는 FileMaker로 데스크톱 프로그램 Scribe를 만들었습니다. Scribe는 검색과 주석, 자료 정리 기능을 갖춰 EndNote를 대신할 무료 도구로 역사학자 사이에서 쓰였습니다.

2003년 무렵 팀은 두 프로그램의 장점을 결합해야 한다고 봤습니다. 연구 도구는 웹과 분리된 채 자료를 관리하는 동시에, 브라우저에서 열어보는 도서관 목록과 디지털 자료도 알아볼 수 있어야 했습니다. 당시에는 두 환경을 어떻게 합칠지 분명하지 않았습니다. 2003년 12월 Elena가 제안한 개선 목록에는 온라인 서지 데이터베이스 연결, 인용 양식 추가, 공동 편집, 외국어 지원 등이 담겼습니다. 팀은 Scribe를 브라우저 안으로 옮기는 방향에 뜻을 모았습니다.

Firefox에서 찾은 실마리

2004년 Firefox 베타와 확장 기능을 살펴보면서 팀은 브라우저를 연구 도구로 바꿀 가능성을 발견했습니다. XML User Interface Language(XUL)로 브라우저를 확장하고, Amazon의 도서 정보 API 등을 활용하면 서지 정보를 자동으로 채울 수 있다고 봤습니다. 팀은 아이디어를 SmartFox라는 이름의 연구자용 브라우저 도구로 정리해 Institute of Museum and Library Services에 지원했습니다. 브라우저가 디지털 도서관 자료를 인식해 저자, 제목, 날짜 같은 정보를 가져오고, 자료와 웹페이지를 저장하고 주석을 달 수 있다는 구상이었습니다.

Simon Kornblith와 David Norton은 2005년 초기 프로토타입을 만들었습니다. 이후 Dan Stillman이 개발팀에 합류했고 Sean Takats, Kari Kraus 등도 프로젝트에 참여했습니다. Firefox의 데이터베이스 지원과 SQLite를 활용하며 기능과 설계를 다듬었습니다. 개발팀은 약 6개월 동안 초기 버전을 빠르게 개선해 2006년 가을 공개를 준비했습니다. Firefox 상표를 이름에 쓸 수 없다는 문제를 해결하려고 여러 이름을 검토한 끝에, 알바니아어로 ‘잘 배우다, 익히다’라는 뜻의 zotero를 골랐습니다.

출시 뒤에도 이어진 개발

Zotero는 2006년 10월 5일 베타를 공개했고, 한 달 만에 이용자 6만 명을 모았습니다. 이후 추가 지원금을 받아 연구팀 간 자료 동기화 기능을 더하고 Firefox에 종속되지 않는 프로그램으로 발전했습니다. 글쓴이는 초기 아이디어가 한 사람의 발명으로 완성된 것이 아니라 역사학자와 개발자, 여러 협력자가 함께 논의하고 만들어낸 결과라고 강조합니다. 팀이 처음부터 완성된 제품의 청사진을 갖고 있던 것은 아닙니다. Web Scrapbook과 Scribe의 한계를 경험하고, 브라우저 기술을 살펴보며 문제와 해법을 함께 찾아갔습니다.

Hacker News 반응

댓글에서는 AI 코딩 도구가 구현 속도를 높여도 제품의 방향과 아키텍처를 정하는 과정까지 대신하지는 못한다는 의견과, 조사·프로토타입·피드백·코딩을 모두 도울 수 있다는 반론이 맞섰습니다.

• @ghoshbishakh — AI로 기능을 쉽게 추가할 수 있다는 생각에 프로젝트 전체를 망친 적이 있습니다. 바이브 코딩을 하면서 쓸모없는 기능을 잔뜩 넣지 않기는 정말 어렵습니다.
  • @huijzer — AI로 기능을 더 빨리 없앨 수도 있습니다. 초기 개발 단계에서는 그게 가장 중요합니다.
  • @josephg — 정말 그런가요? 저는 LLM이 코드를 삭제하는 데 꽤 서툴다고 느낍니다. 기능을 추가한 다음 없애달라고 하면 코드베이스는 여전히 커집니다. 매번 커집니다. 리팩터링으로 코드를 단순화해달라고 해도 실패합니다. LLM은 프로토타입을 만드는 데는 뛰어납니다. 프로토타입은 잘못된 기능을 만들지 않게 도와줄 수도 있습니다.
• @adamddev1 — 에이전트 개발이 많은 것을 빠르게 만든다는 점이 장점으로 꼽힙니다. 하지만 많이 만든다고 그중 무엇이든 정말 좋고 믿을 만하다는 뜻은 아닙니다. 통찰력 있고 견고한 결과물은 훨씬 더 많이 쓰이므로, 개발에 더 드는 선형적인 비용은 비용 대비 효과에서 점점 작아집니다.
  • @lmz — 그럴 수 있지만 글은 견고한 기반이 코드라고 주장하지 않습니다. 기존 두 제품의 설계와 제품 구상이 기반이었다는 내용에 가깝습니다. 지금도 기존 제품을 연구하고 에이전트에게 이를 바탕으로 만들라고 할 수 있습니다.
  • @scruple — 그 주장은 핵심을 슬쩍 바꿉니다. 어려운 부분은 Scribe와 Web Scrapbook을 발전시키면서, 로컬 오프라인 저장과 여러 학술 카탈로그의 실시간 DOM 수집을 함께 풀 아키텍처를 발견하는 일이었습니다. 프롬프트를 쓰는 사람이 아직 모르는 문제를 에이전트가 해결할 아키텍처로 종합할 수는 없습니다.
• @kstenerud — AI가 이 과정을 막지는 않습니다. 오히려 일부를 앞당길 수 있습니다. 프로젝트의 일반적인 흐름은 기존 환경 조사, 사용자 조사, 아이디어 구상, 초기 프로토타입과 피드백, 설계와 아키텍처 선정, 단계별 구현과 테스트입니다. LLM은 조사와 프로토타입, 사용자 의견 정리에 뛰어나고 설계가 끝난 뒤 코딩도 잘합니다.
  • @mmarian — 사람들이 빠르게 만들 수 있는 기능을 시험하느라 정신이 팔리면 오히려 과정이 늦어질 수도 있습니다.
  • @kstenerud — 그건 절제와 오만의 문제입니다. LLM 이전에도 많은 사람이 그런 문제를 겪었습니다. 대부분의 V2 재작성도 비슷한 사례입니다.
• @peterbell_nyc — 소프트웨어 개발에는 무엇을 만들지 생각하고 논의하는 과정, 실제로 만드는 과정, 그 결과가 정말 만들어야 할 것이었는지 사용해보는 과정이 있습니다. 그리고 이 순환을 반복합니다. LLM은 두 번째 과정을 확실히 앞당기고, 첫 번째와 세 번째도 도울 수 있습니다.
  • @skydhash — LLM으로 구현을 앞당기려는 사람은 첫 번째 과정을 충분히 생각하지 않는 경우가 많습니다. 좋은 소프트웨어는 작은 범위에서 시작해 조금씩 더하는 경우가 많습니다. LLM 프로젝트는 구현을 서두르고 일을 너무 크게 벌여 설계와 평가를 어렵게 만들곤 합니다. 집을 지으려면 성당이 아니라 작은 오두막부터 시작해야 합니다.
• @nickledave — Zotero는 정말 쓰기 편합니다. 제가 읽는 자료를 전부 넣고, 웹페이지를 저장하고 주석을 달며, 기기 간 동기화도 합니다. 그냥 잘 작동합니다. Zotero를 만든 사람이 소프트웨어 개발을 이야기한다면 들어볼 만합니다.
  • @TripleTree — 데이터를 쉽고 깔끔한 형식으로 꺼낼 수 있나요? 쓰던 노트 앱이 나빠져서 떠나기 힘들었던 적이 있어, 데이터 이동을 늘 고려합니다.
  • @freeone3000 — CSV, XML, LaTeX로 내보낼 수 있고, 원본 문서와 PDF도 받을 수 있습니다.
• @doug_durham — 이 글은 기원을 낭만적으로 다시 그린 것 같습니다. LLM이 있었다면 5년이 5개월로 줄었을 가능성이 큽니다. LLM은 원하는 것을 정확히 모르는 작업을 가속하는 데도 뛰어납니다.
  • @jjuel — 원하지 않는 방향으로 아주 빠르게 끌고 갈 수도 있습니다. 그 길을 잘못 들었다는 걸 깨달을 때쯤이면 이미 빠르게 달려온 뒤입니다. 되돌아가 다시 시작하는 일을 몇 번이나 해야 실제로 시간을 아끼는 걸까요?
• @sdevonoes — 대규모 회사에서 중간 규모 이상 기능을 만들 때는 자기 영역 안의 작업과 다른 영역에 걸친 작업이 함께 발생합니다. 다른 팀과 조율하고 설계 문서를 쓰며 승인을 받는 과정이 필요합니다. AI는 모든 단계에서 도움을 주지만, 잘 쓴 프롬프트 하나로 전체 일을 해결하는 마법은 아닙니다.

원문: Dan Cohen의 뉴스레터 / 번역·요약: Trawling