본문으로 건너뛰기
피드

Consuela — 디펜던시 그래프 기반으로 데드코드 제거하고 파일 분리까지 해주는 코드베이스 청소 도구

frontend 약 4분
vote
0
댓글
북마크

TypeScript/JavaScript 코드베이스의 전체 디펜던시 그래프를 구축한 뒤, 데드코드 제거·대형 파일 AI 분할·폴더 구조 재배치를 자동으로 수행하는 CLI 도구. ESLint/Knip과 달리 그래프 기반 분석에 AI 리팩토링까지 결합한 것이 차별점.

  • 1

    코드베이스 전체의 export/import/호출 관계를 디펜던시 그래프로 구축한 뒤 분석 수행

  • 2

    데드코드 제거, 대형 파일 AI 분할, 폴더 구조 AI 재배치 세 가지 핵심 기능

  • 3

    fix 명령 실행 후 빌드 검증까지 자동화하며 gold-standard 스냅샷으로 변경 안전성 확인

  • 4

    AI 기능은 Google Gemini 무료 티어 사용, AGPL-3.0 라이선스

Show HN | HN

  • TypeScript/JavaScript 프로젝트의 코드 정리를 자동화하는 CLI 도구가 Show HN에 올라옴. "No no no... I clean"이라는 Family Guy 레퍼런스를 컨셉으로 가져감
  • 핵심 차별점은 코드베이스 전체의 디펜던시 그래프를 먼저 구축한다는 점임. 모든 export, import, 호출 지점, 심볼 간 관계, 순환 의존성까지 완전한 그래프를 만든 뒤 이를 기반으로 분석과 수정을 수행함
  • 주요 기능 세 가지: 데드코드(미사용 export, 빈 파일) 제거, 대형 파일을 AI로 모듈 분리, 폴더 구조 AI 재배치
  • consuela fix가 메인 명령어로, 문제를 고친 뒤 빌드가 여전히 작동하는지까지 자동 검증함. 첫 실행 시 .consuela/ 폴더에 분석 캐시와 gold-standard 스냅샷을 생성해 AI 변경이 기존 구조를 망가뜨리지 않는지 확인함
  • consuela diagnose로 0~100점 건강도 점수를 받을 수 있고, consuela trace [symbol]로 특정 함수/타입의 사용처를 라인 번호까지 추적 가능함. consuela impact [file]은 특정 파일 변경 시 영향받는 파일을 직접/간접 의존성 포함해서 보여줌
  • ESLint나 Knip 같은 기존 도구와의 차이점: ESLint는 파일 단위 린팅, Knip은 미사용 의존성 탐지에 초점이 맞춰져 있는 반면, Consuela는 그래프 분석 + AI 리팩토링(파일 분할, 폴더 재구성)까지 한 단계 더 나아감
  • AI 기능은 Google Gemini(gemini-3-flash-preview)를 사용하며 무료 티어로 신용카드 없이 이용 가능함. API 키는 프로젝트가 아닌 사용자 머신에 전역 저장됨
  • CI 연동도 지원해서 --fail 플래그로 이슈 발견 시 exit code 1을 반환하게 할 수 있음. GitHub Actions 예시도 제공됨
  • 라이선스는 AGPL-3.0으로, SaaS에 사용 시 전체 애플리케이션을 오픈소스해야 하는 조건이 있음. 상용 라이선스는 별도 문의 필요
  • Python은 실험적 지원 단계이며, 추가 언어 지원이 예정되어 있음

ESLint는 파일 단위 린팅, Knip은 미사용 패키지 탐지에 집중하는 반면, Consuela는 프로젝트 전체 그래프를 기반으로 구조적 리팩토링까지 시도한다는 점에서 레이어가 다름. 다만 AI가 파일을 분할하고 이동시키는 것이 실제 대규모 프로젝트에서 빌드를 안정적으로 유지할 수 있는지는 실사용 검증이 필요함.

댓글

댓글

댓글을 불러오는 중...

frontend

요즘 픽셀 폰트가 그냥 복고 감성이 아닌 이유

1990년대 기기 화면 느낌을 현대 폰트 시스템으로 재해석한 픽셀 폰트 몇 가지를 소개한 글이다. 핵심은 예쁜 복고풍 글자 모양만이 아니라, 실제 제품에서 쓸 수 있게 기준선, 자간, 메타데이터, 세로 메트릭까지 챙기는지가 중요하다는 점이다.

frontend

HTML의 `<dl>`이 생각보다 쓸모 많은 이유

이 글은 HTML의 description list, 즉 `<dl>`, `<dt>`, `<dd>`가 단순 용어 사전용 태그가 아니라 이름-값 쌍 UI를 표현하는 꽤 강력한 시맨틱 도구라고 설명한다. 숙소 편의시설, 요금 내역, 기술 용어 설명, 게임 능력치표처럼 흔한 패턴을 중첩 `<div>` 대신 의미 있는 HTML로 만들 수 있다는 얘기다.

frontend

HTML을 캔버스 안에 넣는 데모 모음이 등장함

구글 크롬 랩스 저장소에 HTML-in-Canvas 관련 데모와 프레임워크 지원 목록이 정리됐다. Duck Hunt 스타일 폼, 흔들리는 버튼, 셰이더 기반 페이지 전환, 천처럼 매달린 폼 같은 실험적 예제가 포함돼 있고 Three.js와 PlayCanvas 쪽 샘플도 연결돼 있다.

frontend

싱글 페이지 앱이 웹을 너무 비싸게 만들었다는 불평

이 글은 싱글 페이지 앱(SPA)이 사용자 경험을 좋게 만든다는 명분 아래 웹의 초기 로딩 비용, 도구 복잡도, 개발 진입 장벽을 키웠다고 비판한다. 페이스북 로그인 페이지의 CSS 3.8MB, 레딧 몇 개 클릭 후 33MB 다운로드 같은 숫자를 들며, 지금의 프론트엔드 생태계가 사람보다 대기업의 요구에 맞춰져 있다고 주장한다.

frontend

네이티브로 끝까지 가려다 텍스트에서 막힌 macOS 개발자의 고백

20년 가까이 macOS와 iOS 네이티브 개발을 해온 작성자가 SwiftUI, AppKit, TextKit 2로 마크다운 채팅 UI를 만들다 결국 WebKit과 Electron 쪽이 훨씬 낫다는 결론에 도달한 글이다. 문제는 성능 하나가 아니라 선택, 스트리밍, 스크롤, 접근성, 텍스트 상호작용 같은 ‘사용자가 당연히 기대하는 기본기’가 네이티브 조합에서 계속 깨진다는 점이다.