외부 원문 링크
게으른 개발자가 꼭 써야 할 10가지 도구
반복 작업을 한 번만 적어두면 기억해주는 10개 도구: Taskfile/Watchman/tmux/Renovate/pre-commit/GitHub Actions/Ansible/zoxide/cron/Espanso. 각자 해결하는 병목이 다르다.
핵심 요약
10개 도구를 트리거 축으로 재분류하면 이렇다.
- 로컬 파일 변경 감지:
Watchman(파일 변경 훅),tmux(세션 복원),zoxide(디렉토리 자동 점프) - 커밋 시점:
pre-commit(포맷/린트 차단),Espanso(커밋 템플릿 텍스트 확장) - Push/PR 시점: GitHub Actions(CI),
Renovate(의존성 자동 PR) - 정기 실행:
cron(시간 트리거), Ansible(다수 서버 멱등 프로비저닝) - 태스크 러너:
Taskfile(Makefile 대안, YAML)
핵심은 각 도구를 외우는 게 아니라 반복이 발생하는 트리거 를 식별하는 눈이다.
자동화 도구를 '같은 명령을 두 번 이상 친 순간 빚이 쌓인다' 는 렌즈로 본다. 도구마다 '어떤 반복을 흡수하는가' 가 다르며, 파일 저장 시 / 커밋 시 / 푸시 시 / 주기적 네 트리거로 분류해 외우면 실전에서 빠르게 조합 가능.
신입/주니어가 '도구 10개 외웠어요' 라고만 하면 얕은 답. 면접관이 원하는 건 '어떤 문제를 어떤 도구로 풀었나' 다. 10개를 4개 트리거(로컬 파일 변경 / 커밋 hook / CI push / 주기) 축으로 분류하면 질문에 구조적으로 대응할 수 있다.
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
Taskfile = 팀이 쓸 수 있는 Makefile
Makefile 은 강력하지만 탭 들여쓰기 요구, POSIX 의존, 비프로그래머에게 난해 한 단점. Taskfile.yml 은 YAML 기반으로 같은 역할.
version: '3'
tasks:
dev:
cmds:
- npm run build
- npm start
deploy:
deps: [test]
cmds: [ansible-playbook deploy.yml]
팀원 전체가 읽을 수 있고, task dev 처럼 호출. CI 에서도 동일 명령.
package.json scripts 에 모든 걸 몰아넣는 것. Node 프로젝트가 아니면 실행 불가 + 복잡한 의존 관계 표현 불가.
Renovate vs Dependabot
둘 다 의존성 자동 PR이지만 정책 세분화가 다르다.
| 기능 | Dependabot | Renovate |
|---|---|---|
| 무료/호스팅 | GitHub 기본 | 자체 호스팅 가능 |
| 그룹 PR | 제한적 | 패턴 기반 그룹핑 |
| 스케줄 | 제한적 | cron 수준 세밀 |
| Auto-merge 정책 | 단순 | packageRules 로 'patch 자동 merge' 가능 |
팀 규모가 커지면 Renovate 로 넘어가는 이유는 'patch 는 자동, minor 는 라벨, major 는 수동' 같은 규칙을 YAML 로 선언할 수 있어서.
자동 PR 봇을 깔아놓고 PR 이 쌓이게 만드는 것. 자동 merge 규칙을 최소한 patch 레벨에는 걸어야 실효성.
pre-commit = 코드 품질의 첫 방어선
.pre-commit-config.yaml 에 lint/format/scan 을 모아두면 커밋 자체가 막혀 '나중에 CI 가 잡겠지' 가 없어진다.
repos:
- repo: https://github.com/pre-commit/mirrors-prettier
rev: v3.1.0
hooks: [{ id: prettier }]
- repo: https://github.com/eslint/eslint
rev: v9.0.0
hooks: [{ id: eslint }]
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0
hooks: [{ id: gitleaks }] # 비밀키 커밋 차단
CI 가 늦게 돌아 5분 뒤에 깨지는 대신 로컬에서 즉시 차단.
husky 스크립트를 직접 짜서 유지보수 부담만 늘리는 것. pre-commit 프레임워크는 훅 정의를 선언적 으로 관리.
읽는 순서
- 1이론
10개 도구를 4 트리거 축(파일변경/커밋/푸시/정기) 로 본인 말로 재분류한 표를 1장으로 작성.
- 2구현
본인 최신 프로젝트에
Taskfile.yml+pre-commit을 도입하고, README 명령을 전부 Taskfile 로 이동. - 3실무
팀 레포에
Renovate를 붙이고packageRules로 devDep patch auto-merge 규칙을 넣어 1주일 뒤 PR 발생 패턴을 분석. - 4설명
사내 공유에 '반복 1회차는 메모, 2회차는 스크립트, 3회차는 자동화' 원칙으로 10개 도구를 배치한 가이드를 작성.
면접 연결 질문
[좋은 답변] (1) Taskfile 도입 — 모든 명령을 한 파일로 집약, (2) pre-commit 으로 lint/format 자동화, (3) CI 를 task test/task build 로 재작성해 로컬 = CI 동일 명령. 이 세 단계만으로 'onboarding 시간' KPI 를 반으로 줄일 수 있다.
[좋은 답변] (1) packageRules 로 devDep patch 는 auto-merge, (2) major 는 별도 라벨/리뷰어 지정, (3) 그룹핑 — 같은 스코프(예: @testing-library/*)는 하나의 PR 로 묶기, (4) schedule: 'before 3am on monday' 로 한 주 1회 배치.
[좋은 답변] act (GitHub Actions 로컬 실행) + Taskfile 로 동일 인터페이스, pre-commit 으로 커밋 전 검증. 그래도 차이가 있으면 컨테이너 이미지 pin 하기 — runner 버전 드리프트 가 주범인 경우가 많다.
자기 점검
'다 좋아보여서 다 깐다' — 도입 비용과 팀 학습 곡선 고려해 필요한 순간에 도입.
무조건 한쪽이 낫다는 오해 — DB 접근이 필요한 배치는 사내 VPN 내 cron, 외부 API 폴링은 Actions.