▲

Scrappy - 친구들과 나만을 위한 작은 앱 만들기

 (pontus.granstrom.me)
5P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • Scrappy는 비전문가도 손쉽게 직접 작은 앱을 만들 수 있도록 돕는 홈메이드 소프트웨어 제작 도구
  • 대형 상용 앱이나 엔터프라이즈 앱과 달리, 개인적이고 창의적인 소규모 문제를 자유롭게 해결할 수 있음
  • 캔버스 기반 UI와 간편한 코드 편집, 실시간 협력 및 공유 기능을 제공해 비프로그래머도 활용 가능함
  • 모든 앱(스크랩) 은 기본적으로 멀티플레이어 환경이며, 계정 생성 없이 즉시 사용과 협업이 가능함
  • AI 코드 생성이나 기존 도구와 달리, Scrappy는 사용자 직접 조작과 소유권을 강조함

소개 및 배경

  • 대부분의 소프트웨어는 대중 시장 판매용이거나 대규모 맞춤형 앱이 중심임
  • 그러나 실제 개개인의 필요를 채우는 소규모, 개인 맞춤형 앱은 매우 드묾
  • Scrappy는 누구나 친구 및 가족을 위해 간단하고 창의적인 앱을 직접 만들 수 있도록 돕는 연구 프로토타입
  • Scrappy의 목표는 프로그래밍 전문성이 없어도, 더 많은 사람들이 창의적이고 개인화된 소프트웨어를 만들 수 있는 비전을 구체적으로 제시하는 것

Scrappy란 무엇인가

  • Scrappy에서 만든 앱은 Scrapp이라 부름
  • 대표적인 예시:
    • 초등학생을 위한 산수 연습 앱: 난이도 조절 가능
    • 지역 행사 참석자 카운터: 여러 입구에서 참가자 출입 관리
    • 회의비용 계산 시계: 실시간 회의 비용 산출
    • 주간 집안일 관리: 구성원별로 일정 유연 관리 가능

Scrappy에서 앱을 만드는 경험

  • Scrappy는 Figma, Miro, Google Slides와 유사한 무한 캔버스에서 버튼, 텍스트필드 등 오브젝트를 배치함
  • Inspector 패널에서 속성을 직접 수정할 수 있으며, 버튼 등에는 JavaScript 코드도 연결 가능함
  • 앱 제작은 드래그/드롭, 속성 수정, 코드 삽입을 단계적으로 반복하며 완성

주요 특징:

  • 기본 동작 구성: 필드와 버튼을 놓고 즉각적인 동작 연결 가능
  • 반응형 수식: 특정 조건에 반응하는 실시간 속성 변경 구현
  • 멀티플레이어 동기화: 상태가 항상 실시간으로 저장, 동기화됨
  • 라이브 편집: 실행과 편집 구분 없이 항상 실시간 수정 가능
  • 선택적 공유: 앱의 특정 일부분만 별도로 공유 및 연결 가능
  • 가시적 데이터 조작: 스프레드시트처럼 데이터를 보면서 디버깅 및 수정 가능

Scrappy를 개발한 이유

  • Scrappy는 사용자 주도의 프로그래밍을 실현하는, “small computing”, “casual programming”, “home-cooked software”같은 트렌드와 관련됨
  • 기존의 시각적 프로그래밍(블록, 노드-와이어 기반)과는 다른 길을 택해, 직관적 조작과 스크립팅을 결합
  • HyperCard, Visual Basic, 동시적 온라인 미디어 등에서 영감을 얻었으며, 생산성 캠퍼스 도구와 실시간 협업(구글 독스, Figma 등)의 경험을 중요하게 삼음.
  • Scrappy는 대규모 상용 앱이나 AI 자동 생성방식과는 달리, 사용자가 직접 제어하며, 개인화·재미·창의성을 극대화함
  • 코드를 직접 생성하지 않고도, 더 쉽고 인간친화적인 앱 제작 경험을 제공함.

Scrappy의 대상 사용자

  • 업무 프로세스 최적화자: 복잡한 업무 흐름을 전문가 도움 없이 개선하고 싶은 사람
  • 교사와 학생: 부수적 기술(커맨드라인, 환경설정) 없이 프로그래밍 본질에 집중 가능
  • 취미 개발자: 대중 앱의 복잡함을 벗어나 빠르게 여러 프로젝트 탐구 희망자
  • DIY 지향자: 집, 취미처럼 자신만의 앱을 직접 만들고 싶은 사용자

현재, Scrappy로 완전 초심자가 앱을 만드는 것은 아직 어려움(일부 JavaScript 지식 필요), 하지만, 공유와 리믹스는 비프로그래머도 가능함.

Scrappy에서 만들기 좋은 앱은?

  • 친구/지인과 공유: 대다수 Scrapp은 여러 사용자가 실시간 공동작업에 적합함
  • 지속적 수정 및 개선: 앱 실행 중에도 즉시 수정 가능, 배포/빌드 과정 없음
  • 소규모 계산 또는 조작: 복잡한 시스템보다는 공유 문서+약간의 컴퓨팅에 효과적임
  • 사용자 마찰 최소화: 계정 만들기 등 불필요한 과정 없이 링크만으로 접근 및 사용 가능
  • 신뢰할 수 있는 소수 사용자: 권한 제어나 미션 크리티컬이 필수라면 적합하지 않음

앱 아이디어 예시: 맞춤형 플래시카드, 회의 아젠다, 온라인 워크숍 관리, 가족 게시판, 여행 계획표 등

Scrappy vs 대중 앱

대중적인 앱을 찾을 수 없거나 적합한 것이 없는 경우, Scrappy로 직접 만들어 공유할 수 있음. Scrappy의 이점:

  • 필요한 기능만 가짐: 불필요한 요소 없음
  • 개인적인 정성: 직접 만든 앱은 의미와 애착 높음
  • 재미있게 수정 가능: 색상, 레이아웃을 자유롭게 꾸미고 유머도 추가 가능
  • 쉬운 리믹스/공유: 다른 사용자가 쉽게 수정 및 재활용 가능
  • 협업 중심 설계: 다수 사용자가 동시에 조작 및 편집 가능
  • 즉시 사용: 계정 가입 없이 링크 클릭만으로 바로 사용 가능
  • 데이터 소유권 명확: 데이터는 로컬에 저장되어, 온전히 사용자가 제어함

Scrappy vs AI 기반 앱 생성

AI가 앱을 자동 생성할 수 있지만, Scrappy의 장점은 이해 용이성, 실시간 협업, 창의적 소유감에 있음

  • 쉬운 이해 구조: 복잡한 코드 없이 시각적 오브젝트 기반
  • 실시간 협력 지원: 여러 사용자가 동시에 협업 및 수정 가능
  • 더 많은 재미와 창의성: 즉각적인 피드백, 능동적 수정의 즐거움을 제공함

Scrappy vs HyperCard 및 후속 도구

  • 인터넷 친화적 공유: Scrappy 앱은 링크만으로 온라인 공유 가능
  • 실시간 협업 환경: 동시 편집/실행 지원
  • 현대적 UI 및 인터랙션: 무한 캔버스, 다양한 오브젝트 지원
  • JavaScript 스크립팅: 현대적이며 보편적인 언어로 동작
  • 더 다양한 인터랙티브 오브젝트: 문자열, 숫자, 날짜, JSON 등 지원
  • 반응형 수식 및 상태 연결: 스프레드시트와 비슷한 동적 관계 설정 가능

향후 계획

  • 프로그래머가 아닌 사용자를 위한 진입장벽 낮추기
    • 코드 자동완성, 더 쉬운 디버깅, 관계 시각화, 이해하기 쉬운 에러 메시지, AI 기반 어시스턴트
    • 쉽고 빠른 공유, 공개 갤러리, 모바일 지원 강화
  • 기능 강화 및 확장
    • 컬렉션 및 데이터 처리 기능 강화, 반복적인 오브젝트 관리, 리유저블 컴포넌트 도입
    • Scrappy 확장성(새 오브젝트 지원), 개념적 일관성 개선 등
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 나는 이 프로젝트의 방향성은 마음에 들지만, 호스팅된 SaaS 방식은 내가 원하는 것과 다름을 느낀 경험 공유. 작은 카운터 등 하루 프로젝트에는 상관없지만, 몇 년간 쓸 작은 앱이면 의존도가 문제라는 판단. 학습 곡선이 아무리 낮아져도 결국 존재하며, 오히려 오랜 기간 쓸 수 있는 접근성과 쉬운 언어, 직접 GUI를 입힐 수 있는 도구가 더 원하는 선택지임. 코드는 완전히 감춰질 필요 없이 사람들이 실제 할 수 있는 방향으로 쉽게 만들어야 한다고 생각. MySpace에서 얼마나 많은 사람들이 CSS를 배우게 됐는지 떠올려 보면, 복붙이 시작이지만 결국 자신만의 걸로 튜닝하게 되는 과정이라서. 개인적으로 요즘엔 HTML/CSS/JS를 주로 사용하고, 정말 백엔드가 필요하면 순수 PHP(프레임워크 없이)를 씀. 하지만 이 방식은 브라우저에 묶이는 단점이 있는데, 회사에서 이런 방식(AutoHotKey 포함)으로 만든 소규모 프로젝트들이 10년 넘게 거의 관리 없이 잘 돌아가고 있음. 특히 AutoHotKey 스크립트는 8년 전에 macOS로 전환하면서 손 뗐지만, 아직도 동료들이 매일 수차례 사용 중. 만약 AutoHotKey가 더는 작동 안 해도 이미 만들어진 코드는 계속 사용 가능. 하지만 SaaS 방식의 솔루션은 설립자가 다른 것에 관심을 옮기면 다시 만들어야 하는 리스크가 발생. 이런 “scrappy”한 솔루션을 찾는 사람들은 그때마다 다시 만들고 싶어하지 않는다는 점이 핵심.

    • 이런 식의 솔루션이라면 TiddlyWiki처럼 하는 게 더 맞을 것이라 생각. TiddlyWiki는 단일 HTML 파일에 전체 웹앱이 들어있으며, 기존에는 뭔가 바꾸면 HTML 파일 자체에 저장해서 셀프 리플리케이션이 됨. 최근에는 백엔드 저장도 지원하는 등 다양한 방식이 나옴. 자기 복제 HTML 파일 및 선택적 백엔드 접근으로 작은 개인 맞춤형 프로젝트에는 훨씬 신뢰성 있는 선택지가 될 수 있다고 봄. 적어도 강력한 복원력이 장점.
    • codeboot.org 추천. 완전 클라이언트 사이드 파이썬 IDE로, 싱글스테핑 지원과 비계층적 가상 파일 시스템, JS 코드 FFI 등 여러 기능이 있음(문서 참고). 앱 공유도 아주 쉬워서 플레이 버튼 우클릭하면 URL 복사만으로 공유 끝. 데이터 정제 등 여러 문제를 해결한 적이 있고, 이렇게 만든 앱을 바로 책갈피 해두고 쓰는 경우가 많았음. 진짜로 잘 작동하고, 만약 궁금한 게 있으면 AMA(질문 환영). 적극적으로 개발 중이고 멋진 새 기능도 준비 중임.
    • SaaS 코드 전체를 오픈소스로 공개해서 장기 사용성을 보장하는 방법도 있겠다는 생각. Penpot가 이 방식을 잘 쓰고 있음. 대부분은 SaaS로 쓰지만, 셀프 호스팅도 가능. 물론 배포판 인증이나 앱 서명 등은 어쩔 수 없이 어려운 요소이지만, 아마 Web3 방식도 도움이 될 듯함. 혹은 PICO-8이나 예전의 Flash처럼 런타임을 공개하고, “카트”나 앱을 유통하는 방식도 방법. SaaS 바깥에서 신뢰할 수 있는 유통망 만들기는 꽤 복잡하긴 해도, 실제로 역사가 있기 때문에 시도해볼 만하다고 생각. Penpot / PICO-8 참고
    • Scrappy 공동 제작자로서, 소프트웨어 장기 사용성 중요성에 전적으로 공감. Scrappy는 로컬 퍼스트 아키텍처로 설계, 전통적인 백엔드가 없어서 클라우드 의존성은 단순 싱크 서버 뿐. (HN에서 이 논의가 커진 후 급히 FAQ에 기술적 세부 내용을 추가함.) 이는 기술적·재정적으로 SaaS 저코드/노코드 툴과는 차별 포인트라고 생각. 초기부터 단일 페이지, 자체 포함형 HTML 파일로 스크랩 저장 기능을 실험했으나, 이 기능은 현재 노출은 안됨.
    • 나는 Cursor와 vibe coding 방식으로 이런 거 만들고 있는데, 정말 만족스럽게 사용 중. 최근에는 내 집 항로 정보를 SDR로 받아와서, 공항에서 비행 정보도 붙여주고, 기차역 플립 보드 스타일로 마법 거울에 표시하는 비행기 추적기를 만들었음. 프론트엔드는 JS도 거의 몰랐지만, 10시간 정도 코딩해서 꽤 괜찮은 앱 완성. 예전이면 2달 이상 걸려서 결국 포기했을 텐데, vibe coding으로 하니 너무 재밌고 긍정적인 경험이었음. 1200 sLOC쯤 되는데, 로깅/성능/퀄리티도 괜찮은 준전문가급 코드라 자부(상업용 평균 코드보다 낫다고 생각).

  • CardStock은 본문에 언급되지 않았지만 Scrappy와 목표와 접근 방식이 비슷해 보임. Scrappy와 달리 CardStock은 오픈소스이며 로컬에서도 실행됨. CardStock / GitHub 저장소 참고. Decker도 오픈소스이고, Scrappy 로드맵의 여러 요구사항(테이블 데이터 쿼리 랭귀지·그리드 위젯, “Contraption”으로의 부품 추상화 등)을 이미 구현함. Decker 링크 참고.

    • 내가 이런 툴을 오랫동안 찾고 있었는데, CardStock에 데스크톱 앱이 있는 점이 진짜 큰 의미라는 입장.

  • 모바일에서 만든 앱이 잘 작동하도록 하는 게 로드맵에 있지만, 모바일 자체 편집은 고려 밖인 듯함(“손바닥 크기의 터치스크린은 Scrapps 편집에 불편하다” 언급). 하지만 지금은 많은 사람들이 모바일만을 유일한 컴퓨팅 디바이스로 쓰는 시대이고, 코드나 소설까지도 모바일에서 작성하는 경우가 많음. 그래서 조금 불편하더라도 모바일 편집 인터페이스까지 고민한다면 이 툴의 영향력이 훨씬 커질 것임을 강조.

  • 내가 했던 가장 좋은 일 중 하나는, Apple Watch 걷기 기록을 한 장의 커다란 지도에 올려주는 심플한 앱을 일주일간 만들어서 AppStore에 올리고 지인과 공유한 경험. 1년이 지난 지금도 친구들이나 우연히 앱을 발견한 사람들이 도시 전체를 걷고 인증 메시지를 보내줘서 뿌듯함. 수익은 없어도 정말 보람찼던 경험. OP 말처럼 재미로 친구들을 위한 간단한 앱을 만드는 게 최고의 행복.

    • 앱 링크가 궁금해짐.
    • 그 과정에서 얼마나 많은 벽과 수많은 허들을 지나 만들어 냈는지 상상해 보면, 수많은 사람들이 그 중 하나에서 포기했을 것임. 결과적으로 사용자는 여전히 아무것도 컨트롤하지 못하고, 벤더 종속이 되어버림. 만약 AI에게 바로 명령해서 오픈소스 워치로 자유롭게 이식이 가능하다면 얼마나 좋은 세상일지 상상하게 됨.

  • 스프레드시트만큼 실제로 엔드유저에게 쓸만한 프로그래밍 환경은 본 적이 없음.

    • 여기에 극단적으로 몰입한 예시로 pyspread 추천.
    • 테스트, 버전 관리, 라이브러리 지원이 없어서 개인적으로는 패스.
    • 결국 직접 코딩을 배우는 게 나음. 이런 도구를 배우는 이유를 모르겠음. 개발자 입장에선 그냥 만들면 되고, LLM 쓰면 아주 단순한 거는 손쉽게 vibe coding으로 뚝딱이며 잃을 것도 없음. 비개발자라도 이런 툴을 배우는 사람이 과연 얼마나 많은지(TAM이 궁금함). 누가 굳이 귀찮게 앱을 끌어다 놓으며 만들지 의문.

  • vibe coding이 당장 개발자를 대체하진 않겠지만, 이런 단순한 시스템에는 가장 강력한 경쟁자가 될 것. LLM에게 간단한 앱(HTML+내장 JS) 만들라고 해도 약간의 수정만 거치면 완성도 높고, 심지어 시각적으로도 더 좋았음 예시 참고.

    • 나도 vibe coding으로 사이드 프로젝트 중. 매번 몇 시간마다 LLM이 풀 수 없는 문제에 부딪혀서, 코딩 경험이 없는 사용자는 아예 해결 못 하고 넘어갈 수도 있다는 생각. 사용 기술이나 프로젝트 범위에 따라 차이 있을 듯.
    • 버그 신고: 3 + 2 = 5.1 같은 실수를 입력하면 맞는 답으로 처리됨.
    • vibe coding이 원조 목적이 맞고, 이들은 자연스러운 대립자.
    • 셀프 호스팅이 가능한 간단한 시스템 스택이 궁금해짐. 개인적으로 Vue에 인증, 멀티플레이어 오프라인 DB, 정적 호스팅, 파일 호스팅, 사용자가 다른 사람 데이터 안 볼 수 있는 필터 기능이 필요.
    • 물음표 대신 빈칸이나 밑줄로 바꾸고 싶음.

  • 우리는 이 주제를 프로그래머 입장에서 접근하는데, 실제 기회는 커뮤니티에 있다는 생각. 예를 들어 가족 단위의 개인 앱스토어처럼 시작해볼 수도 있음(Masterson 스타일). 보안 없이(모두 지인이니까), 초대 없인 기여도 불가. 그냥 그런 아이디어 제안.

  • UI 요소를 빈 시트에 드래그 앤 드롭하고, 그리드 스냅이 UI 요소 크기와 달라서 계속 싸우고, 결국 코드 자동완성이나 비주얼 프로그래밍, API 도움, AI 지원 없이 생 자바스크립트 입력만 해야 된다면 이게 정말 끝인가라는 의문.

  • 나 역시 초심자에게 블록 기반이 아닌 “스크립팅 가능한 컴포넌트” 접근 방식에 100% 동의. 지금은 모바일이라 곧 데스크톱에서 써볼 계획. 분석에서 놓친 점은 사람들은 “쉬운 공유”와 “제로코스트”를 원한다는 사실. 최소 환경에서도 앱 자체 만들기는 쉽지만, 배포(앱스토어 장벽)/호스팅이 문제라서 가족/지인조차 월 5달러 내는 건 망설임. 사실 프로 개발자도 마찬가지.

    • 집에 웹서버+동적 DNS 연결로 셀프호스팅하면 됨.
    • 아이디어 공유 자체는 좋지만, 무료 호스팅/배포는 악의적 사용자 남용 위험이 있음.

  • “컴퓨터는 사람을 위해 일해야 하며, 요리나 워드프로세싱처럼 모두의 활동이 되었으면 한다” 같은 지향점 언급 보면서, 너무 일반적이라는 느낌. “라이브 업데이트 포함, 전부 무료. LLM이…”처럼 em-dash(-)가 지나치게 많아 AI 생성 티가 난다고 판단. 개인적으로 AI가 작성한 콘텐츠임이 보이면 흥미가 급격히 떨어지는 타입. 창작자 탓은 아니지만, 나 또한 이런 식의 카피 쓰는 데 그다지 흥미 없음.

    • 이런 스타일의 em-dash는 내가 10~15년째 써오던 IRL 문체. 나 역시 AI가 만든 콘텐츠를 소비하는 걸 별로 안 좋아하고, 누군가 프롬프트만 쳐준 거면 나도 LLM에 직접 묻는 게 낫다고 느낌.
    • 하이픈/엔대시/엠대시 용법을 따지면, em-dash를 구분자로 쓰는 건 원칙에 맞는 정답임. AI 표시로 간주하는 건 동의하지 않음.
    • Scrappy 공동 제작자 입장에서, 나는 오랜 매킨토시 유저라서 하이픈·엔대시·엠대시 구분 확실함 :) AI로 폴리싱 용도로만 가끔 쓴 거지, 텍스트 생성은 절대 아니었음. 직접 썼기 때문에 실제 작업량이 매우 많았음(실제 대부분의 작업은 Pontus가 맡음).
    • em dash 쓰려면 compose 키 후 하이픈 세 번. — 이런 식. 맥에서는 shift-option-hyphen임.
답변달기