- 2026년 개발자들이 매일 쓰는 소프트웨어
- GitHub이 또 멈췄다, 우리는 무엇을 맡기고 있나
- VisiGrid, 코드 에디터처럼 만든 로컬 스프레드시트
지난 월요일 저녁, GitHub이 일곱 시간 가까이 제대로 동작하지 않았습니다. 한국은 마침 휴일이었지만 미국은 근무일 오후였고, 그날 이후 GeekNews 상위권은 온통 “우리가 매일 의존하는 도구”에 관한 글로 채워졌습니다. 오늘 TOP3는 우연히 하나의 질문으로 이어집니다. 우리가 매일 쓰는 도구는 정말 우리 것인가, 아니면 남의 서버 위에 얹혀 있는 것인가.
2026년 개발자들이 매일 쓰는 소프트웨어
6년 만에 다시 물어본 “매일 뭘 쓰나요”
Lobsters에 6년 만에 같은 질문이 다시 올라왔습니다. 개발자들이 실제로 매일 쓰는 소프트웨어를 나열해보자는 스레드입니다. 흥미로운 건 답변의 구성입니다. 최신 도구가 기존 도구를 밀어낸 자리는 거의 없고, 대신 새 계층이 기존 워크플로 위에 얹히는 형태가 압도적이었습니다. Ghostty 같은 최신 GPU 터미널을 쓰면서도 그 안에서는 여전히 tmux를 돌리고, Claude Code와 Codex를 쓰면서도 편집기는 Emacs와 Neovim 그대로입니다.
편집기는 Emacs, Vim/Neovim, Helix, VS Code, Zed, JetBrains 계열이 고르게 언급됐습니다. 터미널은 Ghostty, Kitty, WezTerm, Alacritty가 나뉘었고 세션 관리는 tmux가 여전히 기본값입니다. 셸은 fish와 zsh가 대화형, bash가 스크립트용으로 역할이 갈렸습니다. 검색과 탐색 계층에서는 fzf, ripgrep, fd, bat, jq가 거의 표준처럼 반복 등장했습니다.
진짜 목록은 “개발 도구”가 아니라 “개인 컴퓨팅 환경”
이 스레드가 단순한 툴 자랑과 다른 이유는 범위입니다. 브라우저(Firefox, qutebrowser), 메일(Thunderbird, Mutt/NeoMutt, Fastmail), RSS(Newsboat, Miniflux, FreshRSS), 노트(Org mode, Obsidian, Zotero, Anki), 파일 동기화(Syncthing, rsync, restic, rclone), 비밀번호(KeePassXC, pass, Bitwarden)까지 이어집니다. 공통점은 하나입니다. 데이터를 직접 소유하고 내보낼 수 있는 도구를 고르는 경향입니다.
버전 관리에서는 Git 옆에 Jujutsu(jj)가 눈에 띄게 늘었고, 환경 재현에는 Nix와 direnv, mise가 반복적으로 등장했습니다. AI 코딩 도구는 이미 목록에 들어와 있지만 위치가 명확합니다. 편집기를 대체하는 자리가 아니라 옆자리에서 일하는 추가 작업자로 배치돼 있습니다.
Tech Insight — 이 목록이 CEO에게 주는 시사점은 “우리 팀 도구를 바꿔야 한다”가 아닙니다. 오래 살아남은 도구들의 공통 조건 — 키보드 조작, 자동화 가능성, 데이터 소유권, 낮은 자원 사용량, 원격에서도 동일한 동작 — 이 곧 도구 도입 체크리스트라는 점입니다. 신규 SaaS를 검토할 때 이 다섯 항목으로 먼저 걸러보면, 2~3년 뒤 이관 비용을 크게 줄일 수 있습니다.
GitHub이 또 멈췄다, 우리는 무엇을 맡기고 있나
멈춘 것은 Git이 아니라 개발 과정 전체
8월 17일 GitHub.com 장애로 웹과 API 트래픽의 약 20%, 아카이브와 Raw 콘텐츠 다운로드의 약 50%에서 오류가 발생했습니다. Pull Request, Issues, Actions, Webhooks가 함께 영향을 받았고, 복구 후에도 상태 페이지는 정상인데 PR에 접근할 수 없는 상황이 이어졌습니다. GeekNews는 여기서 이주 논의를 꺼내기 전에 먼저 물어야 할 질문을 제시합니다. GitHub이 멈출 때 우리에게서 정확히 무엇이 멈추는가.
앞선 장애에서는 GitHub Actions와 Pages가 6시간 넘게 영향을 받았는데, 이때 자체 호스팅 러너조차 작업을 받지 못했습니다. 컴퓨팅 자원은 자기 서버에 있는데도 작업을 배정하는 제어면(Control Plane)이 GitHub에 남아 있었기 때문입니다. Git 저장소만 맡겼다고 생각했지만 실제로는 리뷰, 자동화, 릴리스, 프로젝트 운영까지 함께 맡기고 있었던 셈입니다.
숫자로 보는 부하: 주당 5억 분에서 21억 분으로
GitHub COO Kyle Daigle이 공개한 수치에 따르면 GitHub Actions 실행 시간은 2023년 주당 5억 분에서 2025년 주당 10억 분으로 늘었고, 2026년 4월 초에는 그 주 누적 21억 분에 도달했습니다. 이 수치가 AI를 단일 원인으로 증명하지는 않지만, 플랫폼이 감당할 작업량이 급격히 커졌다는 사실은 분명합니다. 원인 진단은 AI 에이전트 트래픽, Azure 인프라 이전, 오래된 내부 구조로 갈립니다.
의존은 네 층으로 나뉜다
글은 GitHub 의존을 네 층으로 정리합니다. ① 코드와 Git 이력은 가장 옮기기 쉽고 미러만 있어도 잃을 위험이 작습니다. ② Issues와 PR은 논의와 설계 판단, 상호 참조가 GitHub 데이터 모델과 URL에 묶여 있어 내보내도 맥락이 깨집니다. ③ Actions와 릴리스 과정은 장애가 실제 업무를 멈추게 만드는 지점입니다. ④ 정체성과 발견은 가장 옮기기 어렵습니다. Star, 기여 이력, 검색 노출은 저장소를 복사한다고 따라오지 않습니다.
Ghostty를 만든 Mitchell Hashimoto는 한 달간 GitHub 문제로 작업이 막힌 날을 기록했고 거의 매일 영향이 있었다고 밝혔습니다. 다만 그의 전략은 신중했습니다. 옮길 곳을 정하지 않은 채 의존을 점진적으로 줄이고, 기존 GitHub URL에는 읽기 전용 미러를 남기는 방식입니다. 대안 목록도 명확한 트레이드오프를 갖습니다. GitLab·Codeberg 같은 관리형 포지는 이전이 쉽지만 중앙 의존 구조는 그대로이고, Forgejo·Gitea 자체 호스팅은 통제권을 얻는 대신 업그레이드·백업·보안·러너 운영 책임이 따라옵니다. 목록에서 자주 빠지는 항목은 무료 CI 실행기입니다. 공개 프로젝트가 Linux뿐 아니라 Windows와 macOS 러너까지 무료로 쓰던 것을 옮기면, 협업 방식만 바뀌는 게 아니라 없던 비용이 생깁니다.
Tech Insight — 실무 결론은 “전면 이주”가 아니라 “의존성 분리”입니다. 첫째, 코드는 독립 원격 저장소나 정기 미러에 두되 미러가 있다는 사실보다 그 미러에서 다시 작업을 시작할 수 있는지를 검증해야 합니다. 둘째, 중요한 설계 판단과 운영 절차를 PR 댓글이 아니라 저장소 문서로 옮겨야 합니다. 셋째, 긴급 수정과 중요한 릴리스만이라도 만들 수 있는 대체 경로를 확보해야 합니다. 자체 호스팅 러너만 추가해서는 부족합니다. 작업 배정과 인증이 GitHub 제어면에 남아 있다면 전체 장애에서는 함께 멈춥니다.
VisiGrid, 코드 에디터처럼 만든 로컬 스프레드시트
메뉴 대신 Command Palette, 콜드 스타트 300ms
VisiGrid는 Excel의 사용 방식이 아니라 코드 에디터의 사용 방식을 가져온 오픈소스 스프레드시트입니다. 메뉴를 뒤지는 대신 키보드와 Command Palette로 조작합니다. Zed가 만든 GPU 가속 UI 프레임워크 GPUI로 만들어졌고 맥·윈도우·리눅스를 지원합니다. 콜드 스타트는 약 300ms, 다운로드 크기는 약 16MB입니다. XLSX, XLS, XLSB, ODS, CSV, TSV, JSON을 완전히 로컬에서 처리하며 120개 이상의 수식 함수와 자동완성을 제공합니다.
조건부 서식도 UI 옵션을 클릭하는 대신 =A1>100 -> warning처럼 규칙을 직접 입력하고 그리드에서 실시간으로 결과를 봅니다. 핵심 차별점은 스프레드시트를 문서가 아니라 디버깅 가능한 데이터 프로그램으로 취급한다는 점입니다. Cell Inspector에서 수식·값·선후 셀·재계산 시점을 확인하고, 시트 간 데이터 흐름 추적과 순환 참조 탐지를 지원합니다. 계산은 같은 입력에 항상 같은 결과가 나오는 결정적 재계산을 지향하고, 구조 변경은 재현 가능한 provenance 기록으로 남깁니다.
“AI는 작성자가 아니라 증인이다”
가장 눈에 띄는 설계 철학은 AI를 다루는 방식입니다. VisiGrid는 AI를 지원하지만 데이터를 직접 바꾸는 자동화가 아니라 증인(witness)으로 배치합니다. AI가 관여한 변경은 provider와 시간까지 기록되고, 사용자의 명시적 승인 없이 셀을 수정하거나 백그라운드에서 자동 실행할 수 없습니다. AI는 질문에 수식을 제안하거나 변경 내역을 설명할 수 있지만, 실제 결과는 Inspector·Diff·Provenance로 사람이 검증하도록 구성돼 있습니다.
GUI와 같은 엔진을 쓰는 vgrid CLI와 헤드리스 모드도 제공합니다. CSV/XLSX 변환, 수식 계산, 필터링, 두 데이터셋의 reconciliation을 파이프라인에서 실행할 수 있고, vgrid diff는 키 기준 비교에 금액 tolerance와 stdin 입력, JSON/CSV 출력을 지원합니다. 중복 키처럼 애매한 상황에서는 추측하지 않고 오류로 처리합니다. LLM 에이전트와 CI용으로는 apply → inspect → verify 워크플로와 fingerprint 검증을 제공합니다. 라이선스는 AGPLv3 + Plugin Exception입니다.
Tech Insight — 재무·정산처럼 숫자 하나가 계약을 좌우하는 업무에 AI 에이전트를 붙일 때 가장 큰 리스크는 “결과만 그럴듯한 시트”입니다. VisiGrid의 접근은 그 리스크를 감사 가능성(auditability)으로 푸는 방향입니다. 에이전트에게 시트 작업을 맡길 계획이라면, 도입 기준을 “얼마나 잘 만드나”가 아니라 “만든 과정을 재현하고 검증할 수 있나”로 잡는 편이 안전합니다.
관련 글
- 커서는 왜 딱 50명만 볼까
- 레디스 만든 그가 요즘 꽂힌 것
- 팀장은 하루 종일 뭘 할까
- GitHub Went Dark. Cursor Was Already Waiting.
- 회계법인 70곳을 쓸어담았다
출처
- GeekNews — 2026년에 매일 어떤 소프트웨어를 사용하시나요?
- Lobsters — What software do you use daily? (2026)
- GeekNews — GitHub이 또 멈췄다: 우리는 무엇을 GitHub에 맡기고 있나
- GeekNews — VisiGrid: 코드 에디터처럼 설계된 로컬 네이티브 스프레드시트
- GitHub — VisiGrid/VisiGrid
AI Biz Insider · Tech Digest · aibizinsider.com
댓글 남기기