software

Funky: 24일 만에 806,893줄: 해커톤이 광기로 전환될 때 무슨 일이 일어날까

발행: (2025년 12월 29일 오전 06:04 GMT+9)
13 min read
원문: Dev.to

Source: Dev.to

위에 제공된 내용만으로는 번역할 텍스트가 없습니다. 번역을 원하는 본문을 함께 제공해 주시면 한국어로 번역해 드리겠습니다.

모든 시작은

이 프로젝트는 $work 해커톤 프로젝트 로 시작되었습니다 — 며칠 동안 무언가를 프로토타입하고 어디까지 갈지 보는 그런 종류죠.

원래 아이디어는 간단했습니다: 테스트에 사용하던 관리가 어려운 스프레드시트를 대체할 UI를 만드는 것. 전형적인 CRUD, 즉 폼, 테이블, 일반적인 엔터프라이즈 기능들 말이죠. 2025년이고 “바이브”가 트렌드인 만큼, 저는 자연스럽게 최신 모델들을 살펴보고 Claude Opus 를 선택해 무엇을 할 수 있는지 확인했습니다.

목표는 단순히 또 다른 CRUD 앱을 만드는 것이 아니라, 진행 과정에서 몇 가지 현대적인 관행을 적용하는 것이었습니다:

  • WebSockets 를 통한 실시간 업데이트 (사용 사례에 전혀 필요 없지만)
  • 적절한 키보드 네비게이션 (실제로 누가 쓰겠어요?)
  • 완전한 PWA 및 SPA 기능 — 왜냐하면 재미로 과잉 설계하기 위해

이 모든 것을 제가 직접 거의 코드를 쓰지 않고, 주로 방향만 제시하면서 진행했습니다.

그때 뭔가가 떠올랐습니다.

WebSocket 연결을 구성하고, 모달 다이얼로그를 만들고, import/export 로직을 구현하면서 저는 스프레드시트 대체라는 목표를 보지 못했습니다. 대신 그 아래에 있는 형태, 즉 모든 CRUD 애플리케이션이 필요하지만 아무도 처음부터 만들고 싶어 하지 않는 패턴들을 보게 된 것이죠:

  • 실시간 동기화 레이어
  • 키보드 단축키 매니저
  • 접근성을 고려한 포커스 트래핑 로직

LLM이 만든 코드는 실제로 나쁘지 않았습니다. 저는 이것이 무엇이 될 수 있는지 보게 되었습니다.

그래서 저는 그 패턴들을 꺼내기 시작했습니다.

“이 부분만 추상화해 보죠,” 라고 LLM에 말했습니다. “해커톤 코드가 더 깔끔해질 거예요.”

그 다음 또 다른 부분을 추상화했고, 또 또 추상화했습니다. 그리고 커스텀 가상 DOM 을 추가했죠, 왜냐하면 재미였으니까요; 약 한 시간 정도 걸렸습니다. 직접 DOM을 조작하는 것과 벤치마크를 해보니 대부분의 경우 의미가 없다는 결론에 이르렀습니다.

해커톤이 다가왔고, 저는 LLM과 함께 구현한 보안 측면에 대해 많이 이야기했으며, 결국 스프레드시트 앱을 만드는 대신 그 스프레드시트 앱이 존재하기를 원했던 프레임워크 를 만들기 시작했습니다. 해커톤 프로젝트는 Funky 프레임워크 의 기반이 되었습니다.

“불필요한 WebSockets 를 CRUD 앱에 추가해 보자” 라는 생각으로 시작했지만, 지금까지는 다음과 같은 JavaScript “프레임워크” 로 발전했습니다:

  • 74개의 컴포넌트
  • 35개의 핵심 모듈
  • 실제 브라우저에서 실행되는 8,800 개 이상의 테스트를 포함하는 커스텀 테스트 프레임워크

이해되지 않는 숫자들

나는 내가 만든 것이 좋은지 스스로 논쟁하지만, 먼저 내 머리를 뒤흔든 통계부터 시작하겠다:

메트릭값
타임라인2025 년 12월 4‑28일
총 커밋 수195
추가된 라인1,297,591
삭제된 라인490,698
순 코드 라인806,893
JavaScript266,551 라인
CSS46,670 라인
컴포넌트74
핵심 모듈35
문서 파일127
테스트 스위트858
개별 테스트8,800+

맞다, 나는 컴퓨터 앞에서 많은 시간을 보내며 그 시간 동안 실제 작업도 하고 있다. LLM을 사용해 본 사람이라면 알겠지만, LLM을 모든 일에 풀어놓을 수는 없으며 마법도 아니다… 하지만…

산업 표준인 개발자당 하루에 약 50줄의 테스트·문서화된 코드를 기준으로 하면, 이는 대략 16,138 인·일에 해당한다 — 즉 64.5 인·년이다. 풀타임으로 일하는 5명의 개발자 팀이라면 이를 만들기 위해 13 년이 필요할 것이다.

Opus는 이 통계를 산출했으며, 이 모든 작업을 24 일 안에 완료했다…

Source: …

No‑jQuery 철학

논란이 될 수도 있는 의견 하나: jQuery가 필요 없어요. React도 필요 없고, Webpack, Vite, Babel도 필요 없어요. 버튼 하나 렌더링하기 위해 인터넷 절반을 npm install로 다운받을 필요도 없죠.

Funky는 순수 JavaScript만 사용합니다. 개발 워크플로우는 혁명적입니다:

  1. 파일을 수정한다
  2. 브라우저를 새로 고친다

그게 전부입니다. 빌드 단계도 없고, 핫‑모듈 교체도 없으며, Webpack이… 뭐든지 하는 동안 터미널을 5분 동안 지켜볼 필요도 없습니다.

“하지만 순수 JS는 장황하고 고통스럽다!” 라고 들리시나요?

그렇나요? 토스트 알림을 만드는 방법은 이렇습니다:

Funky.Toast.show('Hello world', { type: 'success' });

그리고 정렬, 필터링, 페이지네이션, 키보드 내비게이션, 접근성 지원까지 갖춘 완전한 데이터 테이블을 만드는 방법은 다음과 같습니다:

Funky.Table.init('#my-table', {
    data: myData,
    columns: myColumns,
    pageLength: 25,
    selectable: true
});

때때로 이것이 너무 쉬워 보이기도 했습니다 — 하루 만에 DataTables와 비슷한 컴포넌트를 다시 작성했거든요. 원본보다 조금 더 걸렸을 것이라고는 확신합니다. 견고한가에 대해서는 또 다른 이야기인데, 저는 이 코드를 실제 운영 환경에서 사용해 본 적은 없지만 동작 예시는 가지고 있고 로그에 큰 오류도 거의 보이지 않아요… 결국 JavaScript이니까요.

Perl

네, 백엔드는 Perl입니다.

모두가 죽었다고 생각하지만 Tiobe 순위에서 계속 상승하는 언어입니다.

낙타는 살아남는다.

웹 프레임워크로 Mojolicious, 백그라운드 작업으로 Minion, API 검증으로 OpenAPI::Modern를 사용하고 있습니다. 이들 없이는 불가능했을 것입니다. 지금까지는 모든 것을 연결하고 JavaScript만 추가했습니다.

앞으로 계획이 많이 있지만, 현재는 JS에 집중하고 있습니다.

PSPWA

PSPWA는 Progressive Single Page Web Application의 약자입니다.

Architecture

  • Progressive: 오프라인에서도 동작하고, 설치 가능하며, 푸시 알림을 지원합니다.
  • Single Page: 전체 페이지 새로 고침 없이, 클라이언트‑사이드 라우팅을 사용합니다.
  • Web Application: 문서가 아니라, 웹사이트가 아니라, 애플리케이션입니다.

그리고 모든 것이 컴파일된 JavaScript 프레임워크 없이 실행됩니다. 단순히 ES5와 약간의 규율, 그리고 많은 Claude 대화 덕분이죠.

실제 브라우저에서 8,800개 이상의 테스트

“Vanilla JavaScript을 제대로 테스트할 수 없어요,” 라는 말은 실제로 LLM으로 시도해 본 사람은 없었다.

테스트 러너는 실제 브라우저에서 실행됩니다. Node.js가 가장하는 것이 아닙니다. jsdom도, happy-dom도 없습니다. 실제 Chrome, 실제 Firefox, 실제 Safari.

키보드 네비게이션을 테스트할 때는 실제 키보드 이벤트를 테스트합니다. 포커스 관리를 테스트할 때는 실제 포커스를 테스트합니다.

테스트 철학은 간단합니다:

사용자가 코드를 실행할 환경에서 코드를 실행하라.

ComboBox 테스트

FunkyTests.describe('ComboBox', function() {
    FunkyTests.it('should open dropdown on click', function() {
        var combo = Funky.ComboBox.init('#test', { items: items });
        TestUtils.click(combo.element);
        expect(combo.isOpen()).toBe(true);
    });
});

전체 화면 모드 진입

전체 화면 모드 종료

물론 CI를 위해 헤드리스 브라우저에서 테스트를 실행할 수 있지만, 개발 중에는 실제 브라우저에서 실행해 초기 버그를 잡는 것을 권장합니다. 나는 WWW::Mechanize::Chrome을 이용해 이를 수행하는 Perl 스크립트를 가지고 있다.

학습

  1. 방향 없는 속도는 그저 혼돈일 뿐이다.
    Claude는 어떤 인간보다도 코드를 빠르게 작성할 수 있지만, 명확한 아키텍처와 가혹한 모니터링 없이는 엉망이 됩니다.

  2. 테스트는 선택 사항이 아니다.
    이렇게 빠르게 진행할 때, 테스트는 완전한 재앙을 막는 유일한 수단입니다. Git도 도움이 됩니다.

  3. 거짓 문서는 문서가 없는 것보다 더 나쁘다.
    우리는 Claude가 존재하지 않는 기능을 문서화하는 것을 발견했습니다. 이제 우리는 모든 것을 검증하고, 혹은 그가 설명하는 기능을 구현하도록 강제합니다. 신뢰하되 검증하라.

태그라인

“코드를 적게 쓰고, 기능을 더 많이 배포하고, 밤에 더 잘 잡니다.”

그것이 약속입니다. 우리가 그것을 실현할 수 있을지는… 24일 후에 물어보세요.

Funky에 대해 더 알고 싶다면 공식 웹사이트를 방문하세요. 이것은 오픈‑소스가 될 것이지만, 제 비전은 아직 최종 확정되지 않았습니다. 추후 소식을 알려드리겠습니다.

Back to Blog

관련 글

더 보기 »