파이프의 꿈: Yahoo Pipes의 생애와 시대

 (retool.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • Yahoo Pipes는 2007년 Yahoo의 소규모 팀이 만든 브라우저 기반 시각 프로그래밍 서비스로, RSS·JSON·CSV·웹페이지 데이터를 끌어와 필터링·결합·가공하고 새 피드나 데이터 출력으로 배포하게 해줬음
  • 코드를 쓰지 않고 노드와 선을 연결하는 방식, 공개·복제·수정 가능한 Pipe 구조 덕분에 비개발자도 데이터 흐름을 직접 만들 수 있었음
  • 공개 베타는 약 1,000명 수준을 예상했지만 수십만 명이 몰렸고, 최적화되지 않은 Perl 코드와 제한된 서버 자원 때문에 출시 직후 대규모 과부하가 발생함
  • Pipes는 Automator, RSS, AJAX, mashup 문화, Yahoo Maps, YQL 같은 흐름을 결합했지만, 보장된 호출량을 판매하는 모델이나 명확한 제품 미션 없이 Yahoo 조직 변화 속에서 유지보수 중심으로 남음
  • 2015년 종료 뒤에도 Workflow/Shortcuts, Huginn, Node-RED 같은 도구와 시각 프로그래밍 논의에 영향을 남겼지만, 오늘날에는 유료 API, 스크래핑 제한, 저작권 불확실성이 비슷한 개방형 데이터 조합 서비스를 어렵게 만듦

Yahoo Pipes가 가능하게 한 일

  • Yahoo Pipes는 웹의 여러 데이터 소스를 가져와 사용자가 직접 필터링·조합·변환할 수 있게 한 클라우드 호스팅 서비스였음
  • 사용자가 만들 수 있던 작업은 생활 정보부터 뉴스 필터링까지 넓었음
    • 최신 지진 기록이 사용자 근처인지 확인
    • 100개 뉴스 사이트를 모아 고양이를 언급한 항목만 보기
    • RSS 피드가 없는 사이트에서 스포츠 점수를 긁어오기
    • Craigslist와 다른 임대 목록에서 가격 조건과 공원 근처 조건에 맞는 아파트 찾기
    • 이미 구독하는 매체에서 관심 없는 주제의 글 제외
  • 개별 Pipe는 개인용이면서 공개였고, 다른 사용자가 복사해 수정할 수 있었음
  • 출력은 RSS, JSON 객체, HTML, KML, XML 등으로 만들 수 있었고, 웹페이지에 임베드하거나 다른 사이트의 데이터 처리 흐름에 연결할 수도 있었음

작은 팀이 만든 클라우드 기반 시각 프로그래밍

  • Pasha Sadri는 2006년 Yahoo로 돌아온 뒤, 브라우저의 새로운 상호작용 가능성을 활용해 데이터를 다루는 도구를 만들고자 했음
  • Pipes는 Yahoo 내부에서 승인된 스컹크웍스 성격의 프로젝트였고, 핵심 팀은 Sadri를 포함해 5명 규모였음
    • Jonathan Trevor와 Ed Ho는 프로그래밍을 담당
    • Daniel Raffel은 제품 관리 역할을 맡음
    • Kevin Cheng은 몇 달 뒤 디자인에 합류
  • 사용자는 브라우저에서 요소를 끌어다 놓고 선으로 연결해 정보 피드를 만들었음
  • 데이터 소스는 뉴스, 데이터베이스 출력, 블로그 글, Atom, RDF, CSV, 웹페이지 등으로 확장됐음
  • 위치 태그가 있는 결과는 Yahoo Maps 필터를 거쳐 특정 지역이나 공원 같은 지형 요소와의 근접성으로 제한할 수 있었음

공개와 복제가 설계 원칙이 됨

  • 팀은 모든 Pipe를 공개하고, 누구나 복사해 수정할 수 있게 만드는 것을 핵심 설계 원칙으로 삼았음
  • Sadri는 이 공개성이 비개발자 접근성을 높이는 데 중요한 역할을 했다고 봤음
  • 사용자는 다른 사람의 Pipe를 보고 배울 수 있었고, 지식 공유가 서비스 사용 방식 자체에 포함됨
  • Pipes라는 이름은 한 프로그램의 출력을 다음 프로그램으로 전달하는 Unix의 파이프라인 개념에서 왔음

출시 직후 터진 수요와 확장 문제

  • Pipes는 2006년 중반부터 2007년 초까지 약 6개월 개발된 뒤, 2007년 2월 조용한 공개 베타로 내보낼 예정이었음
  • 팀은 초기 사용자를 약 1,000명으로 예상했지만, 출시 직후 수십만 명이 몰렸고 접속하지 못한 사용자도 많았음
  • 제한된 서버와 최적화되지 않은 코드가 뉴스피드 워크플로 실행과 페이지 제공을 감당하지 못해 시스템이 완전히 과부하됨
  • 단일 Pipe는 당시 개인용·업무용 컴퓨터에서도 실행 가능했지만, 서비스 전체를 클라우드에서 대규모로 돌리려면 상당한 데이터센터 자원이 필요했음
  • 캐시되지 않은 실행마다 단일 Pipe가 수십 MB에서 수백 MB를 내려받을 수 있었고, 당시 대역폭은 부족하고 비용도 비싼 경우가 많았음
  • Sadri는 이후 6개월 동안 이미 만든 시스템을 확장해 수요를 따라잡는 데 시간을 써야 했다고 회상함

Yahoo 내부 환경과 Brickhouse

  • Sadri는 2000년부터 2007년까지 대부분 Yahoo에서 일했고, 2005년에는 Google로 이동해 Google Maps에 참여한 뒤 2006년 Yahoo로 돌아왔음
  • Yahoo의 Technology Development Group, 즉 TechDev는 Flickr 공동창업자 Caterina Fake를 위한 조직으로 만들어졌고, Yahoo Advanced Development Division 아래에 있었음
  • TechDev는 검색 사업에 묶이지 않는 새로운 방향을 시험하고, 창업가적 성향의 직원을 끌어들이는 역할을 맡았음
  • Fake는 Jerry Yang으로부터 Yahoo를 “Flickr처럼” 만들라는 위임을 받았고, 작은 효과적인 팀을 만들고 조직 장벽을 줄이는 방안을 추진했음
  • Pipes는 그 흐름에서 나온 첫 프로젝트 중 하나였고, 이후 San Francisco에 만들어진 Brickhouse 산하로 들어감
  • Brickhouse는 Yahoo를 떠나려는 창의적이고 불안정한 인재들에게 “마지막 정거장”처럼 여겨졌음

Yahoo의 규모가 만든 기대감

  • Yahoo는 검색 광고와 검색 라이선스 사이트에서 대부분의 매출을 얻고 있었음
  • Kent Brewster에 따르면 Pipes 출시 당시 Yahoo 홈페이지는 월 12억 방문자를 기록했고, Yahoo 전체 사이트는 하루 10억 페이지뷰 이상을 받았음
  • Brewster가 Yahoo 홈페이지에 Al Gore의 An Inconvenient Truth 링크를 제안한 뒤, Al Gore가 Yahoo 본사 근처 상영회에서 직접 감사를 전할 정도로 홈페이지 노출의 영향력이 컸음
  • Sadri가 Yahoo로 돌아온 배경에는 당시 Google만큼 빠르게 성공 프로젝트를 내놓지는 못했지만, Yahoo에도 “다음 큰 것”이 나올 가능성이 있다는 기대가 있었음

Automator에서 브라우저 기반 도구로

  • Pipes의 그래픽 개념은 Apple의 Automator에서 큰 영향을 받았음
  • Automator는 사용자가 앱이나 시스템과 연결된 동작을 선형 워크플로에 끌어다 놓아 자동화를 만들 수 있게 한 macOS 도구였음
  • Apple은 2004년 Automator를 공개했고, 코딩 기술이 필요한 작업을 일반 사용자도 다룰 수 있게 하려는 목적을 가졌음
  • Pipes는 Automator의 아이디어를 발전시켰지만, 네이티브 앱이 아니라 브라우저에서 동작했음
  • Automator는 Mac에서 사용할 수 있는 여러 언어와 스크립트로 기능을 확장할 수 있었지만, Pipes는 클라우드 호스팅 서비스였기 때문에 임의 코드 실행을 허용하지 않고 제한된 기능 집합만 제공했음
  • 당시 클라우드 서비스에서 임의 코드를 실행하게 하면 CPU 자원을 과도하게 소비하고 다른 자원을 압박할 수 있었음

브라우저 UI 구현의 난이도

  • Pipes의 핵심은 코드를 쓰지 않고 노드와 연결선을 브라우저 안에서 조작하는 시각 프로그래밍 UI였음
  • Google Maps가 2005년 드래그·줌·실시간 지도 업데이트를 보여준 이후, CSS와 JavaScript, AJAX를 이용한 브라우저 상호작용이 더 현실적인 기반이 됐음
  • 팀원들은 출시 전 가장 많은 시간과 노력이 노드와 선 구조를 만들고 이를 시각 코딩 환경으로 표현하는 데 들어갔다고 기억함
  • 당시 Firefox, Opera, Safari, Internet Explorer는 지원 수준과 동작 방식이 달랐고, 특히 Internet Explorer는 독자적인 코딩·HTML 요구사항이 있었음
  • Sadri는 박스와 애니메이션 곡선을 여러 브라우저에서 작동하게 한 것이 주요 기술 성과 중 하나였다고 봤음

Mario Kart와 Wii 색감이 제품 디자인에 남음

  • 팀은 점심 뒤 매일 Nintendo DS로 Mario Kart를 플레이했고, 게임 후 아이디어를 화이트보드에 정리하는 방식으로 피드백과 논의를 이어갔음
  • Raffel은 게임을 하며 즐거운 분위기에서 피드백을 주고받는 것이 제품 개발에 중요했다고 봤음
  • 반복적인 Mario Kart 플레이는 밝고 대비가 강한 색상 조합을 Pipes 디자인에서 계속 의식하게 만들었음
  • 2006년 11월 Nintendo Wii가 나온 뒤, 팀은 초기 Wii의 색상 체계와 부드럽게 빛나는 색감에서도 영향을 받았음
  • Apple의 Aqua 인터페이스와 다색 iMac도 시각적 참고점이었음

데이터 흐름을 보이게 만든 실행 모델

  • Pipes는 초기에는 선형 흐름이었지만, 이후 각 노드가 프로그램 순서에서 스크립트와 코드를 실행할 수 있는 더 동적인 구조로 발전했음
  • 조건문, 반복, 분기와 결합, 외부 웹 서비스로 출력 전달 같은 제어 구조를 제공해 제한적이지만 범용 프로그래밍 언어에 가까운 작업을 가능하게 했음
  • 제어 구조 선은 회색, 데이터 흐름은 파란색으로 표시하는 링크 구문 색상도 사용했음
  • 팀은 스프레드시트를 비개발자를 위한 프로그래밍 모델의 중요한 기준으로 봤음
    • 스프레드시트는 데이터가 보이고 입력 변화에 따라 즉시 결과가 갱신됨
    • 컴파일이나 로그 기반 디버깅 없이 잘못된 부분을 바로 확인할 수 있음
  • Pipes는 요소를 연결하는 즉시 실행되고 결과를 보여주는 반응형 데이터 파이프라인을 제공했음
  • 화면 하단의 선택적 텍스트 디버거는 현재 결과를 개별 항목으로 보여줬음
  • Sadri는 Pipes에서 잘못된 프로그램을 작성하기가 매우 어려웠고, 화면에 무언가를 끌어다 놓으면 즉시 작동하고 출력이 생겼다고 말했음

내부 구현과 기술 부채

  • Pipes는 빠르게 반복 개발됐고, 정해지지 않은 출시 시점에 맞춰 기능·코드·디자인이 계속 만들어졌음
  • 팀은 나중에 완전한 제품이 되면 자신들이나 다른 사람들이 정리할 수 있다고 보고 단축 구현을 사용하기도 했음
  • Ed Ho에 따르면 기반 코드는 대부분 Perl로 작성됐음
  • Perl은 서버 측 시스템과 텍스트 처리에 널리 쓰였지만, Pipes가 실제로 요구하게 된 프로덕션 규모에는 부족했음
  • Trevor는 Perl 코드가 매우 비효율적이고 잘 확장되지 않았으며, 빠른 v1 개념 증명에 맞춰진 설계였다고 평가했음

O’Reilly의 호평과 폭발적 베타

  • 2007년 초, 정해진 종료 지점 없이 수개월 개발하던 팀은 상위 관리자로부터 2주 안에 Pipes를 완성하라는 지시를 받았음
  • 팀은 완성까지 2주가 남은 상태가 아니라고 느꼈지만 결국 출시했음
  • 출시 며칠 전 Caterina Fake는 Sadri를 데리고 Tim O’Reilly에게 데모를 보여줬음
  • O’Reilly는 Pipes를 인터넷 역사에서 이정표라고 평가하며, 웹 프로그래밍을 민주화하고 사용자가 소비하는 인터넷 정보 서비스를 더 잘 제어할 수 있게 한다고 썼음
  • 이 호평은 관심을 폭발시켰고, Sadri는 서버가 모두 녹아내리게 만들었다고 회상함
  • 출시일 내내 사용량은 줄지 않았고, Yahoo 데이터센터 팀은 다른 그룹에 배치하려던 서버를 Pipes에 투입했음
  • 팀은 충돌 페이지조차 준비하지 않았고, 베타 이후 “our pipes are clogged”와 비슷한 문구의 페이지를 먼저 만들었음

끝없이 도는 Pipe와 운영 부담

  • 출시 뒤 팀은 빠른 출시 과정에서 마무리하지 못한 문제들을 확인하기 시작했음
  • 사용자가 Pipe를 만들면 별도의 종료 시점 없이 계속 실행됐음
  • 로그인이나 갱신 요청이 필요하지 않았고, RSS 리더는 자동으로 업데이트를 폴링했음
  • Raffel은 “좀비”처럼 생성된 많은 작업들이 실제 사용자에 의한 것인지 불분명한 사용량을 빠르게 만들었다고 봤음
  • Yahoo는 서버를 더 투입했고, 프로그래머들은 가장 비효율적인 코드를 최적화했으며, 몇 달 뒤 안정성이 개선됨

데이터 조합 도구로서의 힘

  • Pipes는 2000년대 중반 mashup 문화와 RSS 전성기 위에서 성장했음
  • RSS는 블로그 업데이트, 팟캐스트 에피소드, 검색 결과, 다른 정보 단위를 단순하고 기계가 읽을 수 있는 방식으로 배포하는 표준으로 쓰였음
  • Jon Udell은 RSS가 접근 방식을 표준화했기 때문에 Pipes가 수많은 소스와 각각 대화하는 문제를 덜 겪을 수 있었다고 봤음
  • Pipes는 RSS뿐 아니라 Atom, RDF, CSV도 다뤘고, 약간의 작업으로 웹페이지를 가져와 특정 데이터를 걸러낼 수도 있었음
  • Yahoo 내부 서비스, 특히 Flickr와도 연결됐고, 이후 Yahoo Query Language, 즉 YQL도 지원했음
  • YQL은 Yahoo 내부 제품과 외부 개발자가 공통 엔드포인트로 쿼리할 수 있게 하려는 전사적 프로젝트였음
  • Pipes 출력은 페이지에 임베드하거나 HTML, JSON, KML, RSS, XML로 만들 수 있었음
  • 외부 웹사이트가 JavaScript로 Pipe 워크플로를 조회하고 결과를 받아오는 방식도 가능했음

Craigslist 차단 사례

  • Pipes는 유용했지만 다른 사이트에 부담을 줄 수도 있었음
  • Craigslist는 2009년 Yahoo가 아닌 개발자가 Craigslist 임대 목록 지도를 만들 때 Pipes를 사용한 뒤 Pipes를 차단했음
  • Craigslist CEO는 Pipes가 너무 많은 자원을 소모한다고 주장했음
  • 차단으로 인터넷의 여러 mashup이 데이터를 잃었고, 일부 개발자는 Craigslist를 데이터 소스로 쓰지 않고 Pipe는 유지했음
  • 차단은 약 2주 뒤 해제됐음

비즈니스 모델과 조직 지원의 부재

  • Pipes의 하락은 출시 때부터 시작됐고, 개념에서 완성된 제품으로 확장하려면 더 큰 팀과 명확한 미션이 필요했음
  • Kent Brewster는 컨퍼런스에서 사람들이 Pipes를 보고 인상적이라고 했지만, 서비스 비용을 얼마나 낼 수 있느냐고 물으면 Yahoo는 아직 그 단계가 아니라고 답해야 했다고 말했음
  • 보장된 월간 Pipe 호출량을 구매하는 상품은 없었고, 그 상태에서는 전문가나 대기업이 투자하기 어려웠음
  • Yahoo는 2008년 1월 약 1,000명을 해고했고, 이후 Microsoft의 446억 달러 현금·주식 인수 제안을 거절했음
  • 같은 해 후반에는 직원의 10%, 약 1,500명을 추가로 해고했음
  • 2008년부터 2017년 매각과 사실상 해체까지 Yahoo의 재무 성과에서 두드러진 사건은 2012년 Marissa Mayer가 Alibaba 지분 매각에 합의한 일이었음
  • Yahoo는 2005년 Alibaba 지분을 10억 달러에 인수했고, 매각 당시 가치는 76억 달러까지 올랐음

Brickhouse와 팀의 해체

  • Brickhouse는 2007년 기술 매체에서 주목받은 여러 프로젝트를 만들었음
    • BravoNation: 칭찬을 주고받는 온라인 시스템
    • FireEagle: 위치 정보를 제공하면서 프라이버시를 중재하는 서비스
    • KickStart: 대학생 대상 일자리 연결 사이트
    • Yahoo Live: 초기 라이브 웹캠 스트리밍 서비스
  • 이 프로젝트들은 성공으로 이어지지 않았음
  • Fake는 2007년 4월부터 임신·출산 휴가를 시작했고 2008년 6월 Yahoo를 떠났음
  • Bradley Horowitz는 2008년 2월 Google로 이동했고, Salim Ismail은 2008년 3월 떠났음
  • Chad Dickerson도 2008년 중반 Fake와 비슷한 시기에 떠났음
  • Brickhouse는 2008년 말 폐쇄됐음
  • Pipes 팀도 흩어져 Yahoo를 떠나거나 다른 팀으로 이동했고, 서비스 지원은 회사 내부의 관리 인력에게 넘어갔음

Pipes가 오래 살아남은 이유와 종료

  • Sadri는 Pipes 출시 몇 달 뒤 Polyvore를 창업했음
  • Polyvore는 사용자가 이미지 콜라주를 공유할 수 있는 플랫폼이었고, 패션과 인테리어 디자인에 자주 쓰였음
  • Polyvore는 2015년 Yahoo에 인수됐고, Sadri는 이후 Sutter Hill Ventures에 있음
  • Ho도 Sadri와 비슷한 시기에 떠났고, Cheng과 Raffel은 Pipes 출시 1년 안에 떠났음
  • Trevor는 2010년까지 Yahoo에 남아 여러 팀을 옮기면서 Pipes를 함께 가져갔고, 이 때문에 서비스가 더 오래 유지될 수 있었다고 말했음
  • Trevor는 Pipes를 Perl에서 Java로 다시 작성해 내부 YQL 언어와 호환되게 했음
  • 그 이후에는 언제 꺼질지만 남은 상태였다고 봤음
  • Yahoo는 2015년 Pipes를 최종 종료했음
  • Hacker News의 종료 공지 스레드에는 여전히 대안을 찾는 사용자와 실현되지 못한 가능성을 아쉬워하는 반응이 이어졌음
  • Sadri는 당시 “컨테이너, 예를 들어 Docker의 시대에 Pipes가 출시됐으면 좋았을 것”이라며, 오늘날 컨테이너라고 부르는 것에 원클릭 배포하는 아이디어가 있었다고 썼음

이후 도구와 시각 프로그래밍에 남은 영향

  • Pipes는 프로그래머, UI 디자이너, 제품 담당자 세대에 영감을 줬음
  • Apple이 2017년 인수한 iPhone/iPad 자동화 앱 Workflow는 이후 종료·통합되어 iOS, iPadOS, macOS의 Shortcuts로 다시 배포됐고, Pipes와 가까운 도구 중 하나로 언급됨
  • Huginn을 만든 Andrew Cantino는 2021년 Hacker News에서 Yahoo Pipes가 Huginn 제작에 영감을 줬다고 썼음
  • Node-RED는 2013년 출시됐고 Pipes와 유사한 분위기를 가진 도구로 언급됨
  • Pipes 대안으로 거론되는 공개·비공개 도구는 계속 늘어났음
  • Hacker News 종료 스레드의 한 사용자는 Pipes가 데이터 mashup 수업의 기반이 됐고, 비개발자 학생들이 몇 시간 만에 작은 맞춤형 데이터 앱을 만들 수 있었다고 공유했음
  • 그 사례에는 위치 엔티티 추출로 거리 예술 블로그를 지오코딩하고, 보강된 피드를 지도 보기로 출력한 작업이 포함됐음

오늘날 같은 서비스를 만들기 어려운 이유

  • Greg Wilson은 시각 프로그래밍 도구가 직업·산업별 전문 도구로 널리 존재하며, Hollywood의 고급 애니메이션도 Yahoo Pipes처럼 데이터 흐름 블록을 연결하는 도구로 만들어진다고 말했음
  • MATLAB도 수학 모델링 플랫폼으로 전 세계 약 400만 명의 사용자가 있고, 많은 사용자가 시각 프로그래밍 인터페이스를 쓴다고 언급됨
  • 일반 목적의 그래픽 도구가 널리 퍼지지 못한 이유 중 하나로 저작권 불확실성이 꼽힘
  • Anil Dash는 2007년 O’Reilly의 Pipes 글에 단 댓글에서 피드의 존재가 구독, 빈번한 폴링, 재게시를 암묵적으로 허용하는지에 대한 답이 없다고 썼음
  • 16년 뒤에도 그 질문들은 명확히 해결되지 않았고, 소송 위험은 무료·유료 서비스를 만들려는 회사에 위축 효과를 줄 수 있음
  • 현재 인터넷은 자유롭게 이용 가능한 정보 피드를 더 많이 잠갔고, 일반 웹페이지를 가져와 데이터를 파싱하는 스크래핑도 더 강하게 제한하고 있음
  • Sadri는 많은 합법적 API가 유료 플랜 뒤에 있는 상업 API가 됐다고 말했음
  • 그럼에도 Pipes에 대한 애정은 남아 있으며, Sadri는 오늘날의 인프라로 “Pipes 2” 같은 차세대 버전을 만들 수 있을지 생각한다고 말했음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Retool 직원으로서 이 글을 작업했는데, 이번 글은 개발자들에게 큰 영향을 준 새로운 프로그래밍 환경을 다루는 정기 시리즈의 두 번째 편임
    이런 글은 애정을 들여 만드는 작업이고, 우리에게 형성적 영향을 준 제품을 만든 원래 팀들과 직접 이야기할 수 있어 좋음
    Retool 같은 제품을 만드는 데서 가장 흥미로운 부분은 과거 아이디어의 진화라는 점이고, 오래된 컴퓨팅 논문과 제품에는 시대를 앞섰거나 업계 변화 속에서 사라진 훌륭한 아이디어가 많음
    Pipes는 새 제품인 Retool Workflows를 만들 때 참고점이 되었고, 앞으로 다룰 프로그래밍 환경 아이디어도 많지만 각자 애정이 있던 환경이 있다면 알려주면 좋겠음
    첫 번째 심층 글은 Visual Basic이었음: https://retool.com/visual-basic
    Retool Workflows: https://retool.com/workflows

    • 예술적인 접근은 좋지만, Firefox 120 on Linux 6.6에서는 페이지가 거의 동작하지 않음
      전반적으로 매우 버벅이고 스크롤 가로채기가 심각하며, Chromium은 훨씬 부드럽지만 여전히 스크롤 가로채기가 나쁨
      보통 Linux를 크게 신경 쓸 대상 플랫폼으로 보지는 않겠지만, 프로그래밍 관련 콘텐츠라면 얘기가 다를 수 있음
    • 다음 편 힌트가 있는지 궁금함. Smalltalk, HyperCard, NeXTSTEP Interface Builder 같은 것일 수도 있나?
    • 원 글 작성자로서 정말 멋진 작업에 감사함. 아직도 이스터 에그를 더 찾는 중임
      다른 독자들에게는 첫 화면의 데스크톱에서 모든 것을 클릭해 보라고 권하고 싶음
    • 이 시리즈만 구독할 수 있는 RSS나 JSON 피드가 있나? 없다면 전체 편을 모아둔 웹페이지라도 있으면 좋겠음

  • 업무에서 가장 좋아하던 프로젝트 인지 기법이 Pipes였고, 그때만큼 빠른 방법을 아직 못 써봄
    Yahoo Pipe로 Jira 프로젝트 10~15개와 GitHub 커밋 스트림 30~50개를 합치고 중복 제거해서 하나의 RSS 피드로 만들었고, Google Reader로 읽었음
    누가 무엇을 언제 어디서 바꿨는지 빠르게 알 수 있었고, RSS라서 이메일을 뒤지거나 여러 알림 페이지를 볼 필요가 없어 훌륭했음

  • Yahoo Pipes와 YQL이 너무 그리움
    2009년에 jQuery 위에 사실상 교차 도메인 XHR(AJAX) 플러그인을 만들어서 클라이언트 쪽에서 임의의 웹페이지를 가져오고 CSS 선택자에서 변환한 XPath로 질의할 수 있게 했음
    YQL이 JSONP를 돌려줘서 모든 게 마법처럼 느껴졌던 시절이었음

    • Node-RED를 써보면 좋음. Ypipes의 기능을 모두 제공하고 그 이상도 가능함
      게다가 UI에 jQuery를 쓴다는 점도 장점임
      IoT용으로 소개되지만 매우 유연해서 거의 무엇이든 할 수 있음
      https://nodered.org
    • Pipes는 CORS 프록시처럼 쓸 수 있었음
      당시 jQuery만으로 Spotify 같은 클라이언트 앱을 만들었고, radioblogclub과 VK.com에서 MP3를 검색·스트리밍하고 last.fm에서 메타데이터와 유사 추천을 가져왔음

  • 지금까지 본 애니메이션 중 가장 버벅이는 애니메이션임. Android의 Chrome, Pixel 7에서 완전히 못 쓸 수준인데 텍스트 버전이 있나?

    • M1 Pro의 Chrome에서도 완전히 못 쓸 수준임
      이 페이지 탭이 표시되어 있으면 모든 Chrome 창이 못 쓰게 됨
    • 위에서 이미 말했지만 덧붙이자면, Linux 워크스테이션의 Firefox에서는 정말 나쁨
      Chromium은 훨씬 낫지만 스크롤 가로채기는 여전히 심각함
    • M3 Pro 64GB, 최신 macOS의 Safari에서도 완전히 못 씀
    • 페이지가 멈춘 줄 알았고, 아무것도 제대로 동작시키지 못했음
    • iOS에서 버벅이며 조금 확대되다가 깨져서 커다란 스크롤 가능한 흰 페이지가 됨
      제대로 동작하면 애니메이션은 꽤 멋질 것 같지만, 독자를 튕겨내기 위해 이렇게 많은 작업을 한 셈이라 아쉬움

  • 이름도 비슷한 최근 워크플로 자동화 도구 중 좋아하는 Pipedream을 추천하고 싶음: https://pipedream.com/
    Yahoo Pipes 스타일의 자동화를 찾는다면 꼭 써볼 만함
    아무 관련은 없고 만족하는 사용자일 뿐임

    • 방금 가입했는데, fly.io 무료 티어에서 돌리며 Supabase 무료 티어로 데이터를 넣던 일부 Docker 컨테이너를 대체할 수 있을 것 같음
    • 소유자인 tod sacerdoti가 lobste.rs의 인기 글을 긁어 HN에 제출하는 식으로 카르마 차익거래 펌프로 쓰고 있음
      무슨 뜻인지 보려면 https://gerikson.com/hnlo/에서 todsacerdoti를 검색하면 됨
      쌓은 HN 카르마 양을 보면 꽤 잘 먹히는 것 같음
    • https://windmill.dev는 pipedream의 자가 호스팅 가능한 오픈소스 대안임
      참고로 창업자임
    • 자가 호스팅할 수 있나?

  • 이번 주 출시한 오픈소스 클라우드 스크립팅 엔진 Flowpipe도 관심 있을 만함
    HCL로 파이프라인을 만들어 HTTP 질의 연결, 컨테이너 실행, Lambda 호환 함수 실행, 데이터베이스 질의 등을 자기 머신과 CLI에서 할 수 있음
    클라우드 리소스를 SQL로 질의하는 오픈소스 프로젝트 Steampipe와도 결합할 수 있고, 플러그인이 139개 이상 있음
    우리는 DevOps 쪽에 더 집중하지만, 이런 것들을 “pipes”라고 부르게 된 데는 Yahoo Pipes도 영감이 되었음
    https://github.com/turbot/flowpipe
    https://github.com/turbot/steampipe

    • Steampipe를 좋아함. 많은 클라우드 리소스에 대한 피드백을 단순하고 명확하게 얻을 수 있게 해줌
      select * from cloud가 좋은 요약이고, Flowpipe도 확인해 보겠음

  • 대학 시절 기숙사 방 선택 순서를 무작위로 정할 때 Pipes를 썼음
    NY Times 웹사이트의 톱 헤드라인을 가져와 해시하고, 1~6 사이 숫자를 결정적으로 뽑게 했음
    여름에 멀리 떨어져서 진행하면서 직접 코드를 실행할 필요 없이 모두에게 공정하다고 설득할 수 있는 최선의 방법이었고, 유용하면서 재미있었음

  • Pipes는 확실히 훌륭했음
    널리 쓰이던 RSS와 비슷한 기술 덕분에 느슨하고 열린 상호운용성이 남아 있던 Web 2.0 황금기와 잘 맞았음
    단순한 것들을 엮어 단순하지만 유용한 것을 만드는 데 효과적이었음
    그런데 이 심층 글의 엄청난 디자인과 작업량은 대체 무엇인가 싶음. Retool이 정말 공을 많이 들였고, 왜 더 일찍 안 했는지가 궁금할 정도임

  • 이런 글이 어떻게 만들어지는지 흥미로움
    많은 정성을 들였고 최종 결과까지 다듬는 데 시간이 꽤 걸렸을 것이 분명함. 고품질 콘텐츠와 다듬기는 곧 높은 비용이기 때문임
    그래도 목적은 아직 잘 모르겠음. 마케팅 글처럼 보이지는 않지만, 행간의 메시지는 분명히 Pipes를 좋아했다면 Retool도 좋아할 것이라는 쪽으로 읽힘

    • 읽는 중인데 똑같은 궁금증이 있음
      제작 품질이 높고, URL도 그냥 retool.com/pipes라서 단순한 블로그 글 같지 않음

  • AWS Step Functions가 Yahoo Pipes와 비슷하다는 걸 깨닫는 데 시간이 좀 걸렸음
    그렇게 단순하지도 않고 클릭 가능한 구성요소도 많지 않지만, 그걸 이렇게 늦게 알아챈 게 이상했음
    더 통찰력 있는 사람이 어디가 틀렸는지 짚어줄 수 있을 듯함

답변달기