Git 히스토리로 살펴본 Fizzy 개발의 여정: 18개월간의 반복적 제품 개발 사례

Rob Zolkos - Ruby on Rails Software Developer

작성자
Ruby AI News
발행일
2025년 12월 02일

핵심 요약

  • 1 Fizzy는 18개월간 8,152개의 커밋을 통해 'Splats'에서 'Kanban 보드'로 진화한 반복적 제품 개발 사례입니다.
  • 2 DHH는 Rails 8 업그레이드, 캐싱, '빈혈 코드' 제거 등 아키텍처 개선에 핵심적인 역할을 수행했습니다.
  • 3 'Fizzy Ask' AI 기능 제거, 'Bubbles'에서 'Cards'로 명칭 변경 등 끊임없는 실험과 피벗이 특징입니다.

도입

Fizzy는 37signals의 최신 제품으로, 18개월간의 개발 역사가 담긴 전체 Git 히스토리가 공개되었습니다. 이는 제품이 어떻게 구체화되는지 엿볼 수 있는 드문 기회를 제공합니다. 이 문서는 8,152개의 커밋을 통해 'Splats on a Windshield'라는 초기 아이디어에서 시작하여 최종적으로 '오픈 소스 프로젝트 관리 도구'로 거듭난 Fizzy의 개발 과정을 상세히 추적합니다. 첫 커밋부터 주요 변경 사항, 결정 및 실험 과정을 조명하며, 반복적인 개발 과정의 본질을 보여줍니다.

개발 초기: ‘Splats’에서 ‘Bubbles’로의 전환

  • 시작 (2024년 6월 21일): Kevin McConnell의 ‘New Rails app’ 커밋으로 시작, 단 몇 시간 만에 Gemfile, Rubocop, 인증, CSS, Brakeman 설정 등 Rails 애플리케이션의 기본 골격이 완성되었습니다.

  • ‘Splat’ 시대 (2024년 7월 23일): Jason Zimdars가 ‘Splat’ 모델을 도입하며 ‘앞유리에 튀긴 벌레’라는 시각적 은유를 통해 정보 조각들을 표현했습니다. 이는 혼란스럽지만 즉각적인 주의를 끄는 개념이었습니다.

  • ‘Bubbles’로의 피벗 (2024년 7월 31일): ‘Splats’의 혼란스러운 이미지는 ‘Let’s try bubbles’ 커밋과 함께 ‘앞유리에 떠다니는 거품’이라는 더 부드러운 개념으로 변경되었습니다. 이 시각적 변화는 제품의 정체성을 재정의하는 중요한 전환점이었습니다.

  • 이름 찾기 (2024년 9월 4일): ‘Splat’이 ‘Bubble’로, 다시 ‘Fizzy’로 최종 명명되는 과정을 거쳤습니다. ‘Boost’ 기능의 ‘거품이 솟아오르는’ 애니메이션이 ‘Fizzy’라는 이름을 자연스럽게 이끌어냈습니다.

DHH의 합류와 아키텍처 정립

  • DHH의 등장 (2024년 10월 17일): Ruby on Rails의 창시자 DHH는 사용되지 않는 파일 삭제 커밋으로 프로젝트에 첫 발을 들였습니다. 이후 Rails 8 RC1 업그레이드 및 광범위한 HTTP 캐싱 적용을 주도했습니다.

  • ‘빈혈 코드’와의 전쟁: DHH는 ‘anemic’ 코드를 제거하는 데 집중했습니다. 이는 설명 가치가 없거나 구현 복잡성을 숨기지 않는 얇은 래퍼(wrapper)를 의미하며, 불필요한 간접성을 제거하여 코드를 간결하게 만들었습니다.

  • 대규모 리팩토링 (2025년 4월): DHH는 한 달 동안 323개의 커밋을 통해 불필요한 작업, 비표준 팩토리 메서드, 사용되지 않는 코드 등을 제거하며 대대적인 코드 정리를 단행했습니다. ‘삭제는 기능이다’라는 그의 철학이 반영된 순간입니다.

최종 변환: ‘Cards’와 ‘Kanban 보드’ 시스템

  • ‘Bubbles’에서 ‘Cards’로 (2025년 4월 9일): ‘Bubbles’는 ‘Cards’로 명칭이 변경되며, ‘pop’ (완료)은 ‘closure’ (닫기)로 바뀌는 등 놀이 같은 은유에서 실제 태스크 관리 용어로 전환되었습니다.

  • 컬럼 시스템 도입 (2025년 9월-11월): Fizzy는 ‘Columns’ 모델을 추가하여 Kanban 보드의 형태를 갖추기 시작했습니다. ‘Projects’ → ‘Buckets’ → ‘Collections’ → ‘Boards’로 이어지는 명칭 변경은 팀이 올바른 정신 모델을 찾아가는 과정을 보여줍니다.

  • 제거된 기능: ‘Fizzy Ask’ (AI 챗봇), ‘Custom Views’, ‘Workflows’와 같은 기능들이 추가되었다가 제거되면서, 핵심 가치에 집중하고 복잡성을 줄이는 방향으로 진화했습니다.

  • 실험적 기능: ‘MCP (Model Context Protocol)’ 브랜치를 통한 AI-native 통합 시도와 모바일 컬럼 뷰에 대한 다양한 실험은 미래 지향적인 접근 방식을 보여줍니다.

결론

Fizzy의 개발 스토리는 '만들면서 발견하는' 반복적 제품 개발의 전형을 보여줍니다. 팀은 처음부터 칸반 보드를 만들 계획이 아니었지만, 끊임없는 시도와 피벗을 통해 제품의 정체성을 찾아갔습니다. 이름, 기능, 아키텍처 모두 사용과 실험을 통해 진화했으며, DHH의 '빈혈 코드 제거' 철학과 '삭제는 기능'이라는 접근 방식은 코드 품질과 유지보수성에 큰 영향을 미쳤습니다. Fizzy는 18개월간의 여정 끝에 오픈 소스로 공개되었으며, 이는 반복적 개발, 디자인 주도 명명, 그리고 핵심 가치에 집중하는 개발 프로세스의 훌륭한 사례로 평가될 수 있습니다.

댓글 0

로그인이 필요합니다

댓글을 작성하거나 대화에 참여하려면 로그인이 필요합니다.

로그인 하러 가기

아직 댓글이 없습니다

첫 번째 댓글을 작성해보세요!