Skip to content
Published on

VS Code 필수 익스텐션 2026 — GitLens / Error Lens / Pretty TypeScript Errors / Tailwind / Prisma / Biome 심층 가이드

Authors

"에디터는 골격이고, 익스텐션은 근육이다. 근육이 없으면 골격은 의자에 앉아만 있다." — 어느 시니어 프런트엔드 개발자

이번 글은 2026년 5월 기준 VS Code 익스텐션 시장 지도다. 2024-2025년 사이에 AI 익스텐션이 주류로 올라오면서 익스텐션 시장의 무게중심이 한 번 크게 흔들렸다. GitHub Copilot이 디폴트가 됐고, Codeium/Cody/Tabnine 같은 무료 옵션이 그 옆에 줄을 섰으며, Continue와 Cline은 BYOK(Bring Your Own Key) 진영을 만들었다. 한편 비AI 진영에서는 GitLens(GitKraken)가 Git UI의 사실상 표준으로 굳어졌고, Error Lens와 Pretty TypeScript Errors가 만든 "에러는 인라인으로 봐야 한다"는 UX 합의가 자리잡았다.

이 글은 Git 도구(GitLens, GitHub Pull Requests), UI 개선(Path Intellisense, Error Lens, Pretty TypeScript Errors, Indent Rainbow, vscode-icons, Material Icon Theme), 언어/프레임워크(Tailwind CSS IntelliSense, Prisma, ESLint, Prettier, Biome, Even Better TOML, Dependi), AI(Tabnine, Codeium, Cody, GitHub Copilot, Continue, Cline), 워크플로(REST Client, ThunderClient, ShellCheck, EditorConfig, Polacode, Quokka.js, Code Tour, Project Manager, Live Server, Markdown All in One, Vim/Neovim 모드)를 분류해서 비교한다. 마지막에는 한국의 토스/카카오, 일본의 메르카리/ZOZO 추천 익스텐션을 짚고 "당신은 무엇을 깔아야 하는가"라는 의사결정 가이드로 마무리한다.

1. 2026년 VS Code 익스텐션 지도 — 네 가지 분류

2026년의 VS Code 익스텐션을 보려면 먼저 분류가 필요하다. Marketplace에 60,000개가 넘는 익스텐션이 있는데 "다 깔자"는 답은 없다. 익스텐션은 곧 메모리이고, 곧 익스텐션 호스트 프로세스의 CPU 사용량이며, 곧 시작 시간이다.

  • Git 도구: GitLens(GitKraken), GitHub Pull Requests, Git Graph, Git History
  • 에러/UI 개선: Error Lens, Pretty TypeScript Errors, Path Intellisense, Indent Rainbow, vscode-icons, Material Icon Theme
  • 언어/프레임워크: Tailwind CSS IntelliSense, Prisma, ESLint, Prettier, Biome, Even Better TOML, Dependi
  • AI 어시스턴트: GitHub Copilot, Codeium, Tabnine, Cody, Continue, Cline
  • 워크플로 도구: REST Client, ThunderClient, ShellCheck, EditorConfig, Polacode, Quokka.js, Code Tour, Project Manager, Live Server, Markdown All in One
  • 에디터 모드: Vim, Neovim, VSCodeVim

이 분류는 책임 경계가 다르다. Git 도구는 "이 코드가 왜 이렇게 됐는가"를 보여주고, UI 개선은 "지금 화면에서 뭘 봐야 하는가"를 명확히 하며, 언어/프레임워크 도구는 "타이핑 도와줘"를 해결한다. AI 어시스턴트는 "코드를 대신 써줘"를 맡고, 워크플로 도구는 "에디터를 벗어나지 않게 해줘"를 담당한다.

가장 흔한 실수는 "기능이 겹치는 익스텐션을 동시에 깔아두는" 것이다. 2026년 시점에서 흔한 충돌은 ESLint + Prettier + Biome 셋 다 설치(Biome는 단독으로 쓸 때 진가가 나옴), vscode-icons + Material Icon Theme 둘 다 활성화(둘 중 하나만 활성화 가능), GitHub Copilot + Codeium + Tabnine 셋 다 자동완성 활성화(트리거가 충돌해서 한 쪽 제안이 사라짐) 같은 패턴이다. 한 카테고리당 하나만 깐다가 2026년의 베스트 프랙티스다.

또 한 가지 큰 흐름은 AI 익스텐션이 비AI 익스텐션을 흡수하는 흐름이다. Tabnine은 처음에는 단순 자동완성이었지만 지금은 AI Chat과 Code Review까지 한다. Codeium은 무료 AI에서 시작해서 자체 IDE(Windsurf)까지 만들었다. GitHub Copilot은 Workspace와 Agent Mode를 추가하면서 사실상 작은 에이전트가 됐다. 이 흐름 때문에 "AI 어시스턴트 익스텐션 하나"의 비중이 점점 커진다.

2. GitLens — Git 히스토리의 표준

GitLens는 2016년 Eric Amodio가 만든 익스텐션으로, 2022년 GitKraken에 인수됐다. 2026년 현재 Marketplace 다운로드 3,500만 회 이상을 기록한 사실상 Git 익스텐션의 표준이다. VS Code의 내장 Git UI는 의도적으로 미니멀하기 때문에, GitLens는 "Git을 진지하게 쓸 거면 무조건 까는" 익스텐션이 됐다.

핵심 기능:

  • Inline blame: 커서가 있는 라인의 마지막 커밋 정보를 라인 끝에 회색으로 표시
  • Hover 정보: 라인 위에 마우스를 올리면 커밋 메시지, 작성자, diff 미리보기
  • File history / Line history: 한 파일 또는 한 라인의 전체 변경 이력을 한 화면에서
  • Compare view: 임의의 두 브랜치/커밋/스태시 비교
  • Repositories view: 워크스페이스 내 모든 저장소의 브랜치/원격/태그/스태시를 트리로
  • Worktrees 관리: 워크트리 생성/전환/삭제를 UI로
  • Commit Graph: 커밋 그래프를 별도 탭에서. 한때 Pro 기능이었으나 2024년 무료로 풀림
  • Visual File History (Pro): 파일의 변화를 시간축으로 시각화
// .vscode/settings.json — GitLens를 가볍게 만드는 설정
{
  "gitlens.codeLens.enabled": false,
  "gitlens.currentLine.enabled": true,
  "gitlens.hovers.currentLine.over": "line",
  "gitlens.statusBar.enabled": true,
  "gitlens.blame.format": "${author|agoOrDate}",
  "gitlens.views.repositories.files.layout": "tree"
}

GitLens의 강점:

  • Blame이 시각적이라 매우 빠르게 책임 추적이 된다. "이 라인 왜 이렇게 됐어?"를 30초 안에 답할 수 있음
  • Worktrees 관리가 GUI로 가능한 거의 유일한 도구. 2025년 Claude Code/Cursor가 worktree 워크플로를 밀면서 다시 주목받음
  • GitKraken 인수 후에도 코어는 무료. Pro는 Visual File History/Workspace 같은 고급 기능만

GitLens의 약점:

  • 기본 설정이 시끄럽다. CodeLens가 모든 함수 위에 작은 글자로 정보를 띄우는데, 익숙해지지 않으면 방해됨 → codeLens.enabled: false 권장
  • 저성능 머신에서 무거움. 큰 저장소(>10만 커밋)에서 인덱싱이 오래 걸림
  • Pro 기능이 늘어남: 2022년 GitKraken 인수 후 일부 기능이 유료로 이동. 다만 코어 기능(blame, hover, history)은 무료 유지

누가 써야 하나: Git을 매일 쓰는 모든 개발자. 사실상 디폴트. 대안으로는 Git Graph(가벼움), Git History(파일/라인 이력에 특화), GitLens — 셋 중 GitLens가 가장 종합적이다.

3. Path Intellisense / Error Lens / Pretty TypeScript Errors — UI 개선의 3대장

이 세 익스텐션은 "VS Code의 기본 UI를 한 단계 위로" 끌어올리는 도구다. 2026년 시점에서 신규 개발자가 까는 첫 번째 묶음이기도 하다.

Path Intellisense (Christian Kohler)

importrequire 안에서 파일 경로를 자동완성한다. VS Code 내장 자동완성도 있지만 Path Intellisense가 훨씬 빠르고 정확하다. 특히 모노레포에서 @workspace/... 같은 alias 경로도 잡아준다.

{
  "path-intellisense.mappings": {
    "@app": "${workspaceFolder}/src/app",
    "@components": "${workspaceFolder}/src/components"
  },
  "path-intellisense.showHiddenFiles": false,
  "path-intellisense.extensionOnImport": true
}

다운로드 1,000만 회 이상. 2026년 기준 대부분의 워크플로에서 첫째 날 깔린다.

Error Lens (Alexander)

Alexander의 Error Lens는 진단 메시지(error/warning/info)를 라인 끝에 인라인으로 표시한다. 기본 VS Code는 진단 메시지를 보려면 마우스를 올려야 하는데, Error Lens는 그걸 화면에 박아둔다.

{
  "errorLens.enabled": true,
  "errorLens.fontSize": "12px",
  "errorLens.messageBackgroundMode": "none",
  "errorLens.gutterIconsEnabled": true,
  "errorLens.followCursor": "allLines",
  "errorLens.excludeBySource": [
    "cSpell"
  ]
}

호불호가 갈리는 익스텐션이다. "화면이 시끄러워진다"는 비판이 있고, "한 번 익숙해지면 못 돌아간다"는 옹호가 있다. 절충안으로는 followCursor: "activeLine"으로 설정해서 활성 라인만 보여주는 방법이 있다. 다운로드 700만 회 이상.

Pretty TypeScript Errors (yoavbls)

TypeScript의 에러 메시지는 악명 높다. 길고, 중첩되고, 어디서 끊어 읽어야 할지 모른다. Pretty TypeScript Errors는 그 에러 메시지를 구조화해서 보여준다. 타입 비교, 누락된 프로퍼티, 함수 시그니처 불일치를 색깔과 들여쓰기로 표현한다.

// 기본 TS 에러 — 한 줄로 너무 길다
// Type 'NewUser' is not assignable to type 'User'. ... missing the following properties from type 'User': id, createdAt

// Pretty TypeScript Errors가 보여주는 것
// ┌─ Type mismatch: NewUser vs User
// │  Missing properties:
// │  - id: number
// │  - createdAt: Date
// └─

특히 React/Next.js/tRPC를 쓰면서 제네릭 타입 에러를 자주 만나는 개발자에게 필수다. 다운로드 500만 회 이상.

이 세 도구의 공통점은 **"기존 정보를 더 잘 보여준다"**는 것이다. 새 기능을 추가하는 게 아니라 이미 있는 진단/타입/경로 정보를 가독성 있게 재배치한다. 그래서 거의 모든 워크플로에 무해하게 추가할 수 있다.

4. vscode-icons vs Material Icon Theme — 아이콘 전쟁

VS Code의 사이드바 파일 아이콘을 바꾸는 두 익스텐션이다. 둘 중 하나만 활성화할 수 있다(같은 contribution point를 점유). 2026년 시점에서 둘은 사실상 무승부 상태로 양분된다.

vscode-icons (icons-for-visual-studio-code 팀)

  • 다운로드 1,800만 회 이상 (2026년 5월 기준)
  • 더 다양한 파일 타입 아이콘 보유
  • 폴더 아이콘이 평면적이고 단순함
  • React/Vue/Angular 같은 프레임워크별 아이콘 풀이 깊음
  • 색감이 비교적 채도가 높음

Material Icon Theme (Philipp Kief)

  • 다운로드 2,500만 회 이상 (2026년 5월 기준)
  • Material Design 가이드라인 기반
  • 폴더 아이콘이 입체적이고 채워진 형태
  • 신규 프레임워크 대응이 빠름 (Next.js App Router, Astro, Bun 등)
  • 색감이 차분하고 어두운 테마와 잘 어울림
{
  "workbench.iconTheme": "material-icon-theme",
  "material-icon-theme.folders.theme": "specific",
  "material-icon-theme.activeIconPack": "nest",
  "material-icon-theme.hidesExplorerArrows": true
}

선택 가이드:

  • 다크 테마 + Next.js/Astro/Bun 같은 신규 도구: Material Icon Theme이 잘 어울림
  • 라이트 테마 + 다양한 언어 혼합: vscode-icons가 직관적
  • 모노레포에서 폴더 구조가 깊음: Material Icon Theme의 폴더 입체감이 도움
  • 취향: 결국 둘 다 좋아서, 일주일씩 써보고 결정하는 게 정답

2026년 트렌드는 Material Icon Theme이 약간 우세다. 다만 Material Icon Theme의 폴더 입체감이 너무 강해서 "단순한 vscode-icons가 좋다"는 사용자도 여전히 많다.

5. Indent Rainbow — 시각 보조의 시조

oderwat의 Indent Rainbow는 들여쓰기 레벨을 색깔로 표시한다. Python처럼 들여쓰기가 문법인 언어에서 특히 유용하다. 2025년 시점에서는 VS Code의 내장 "bracket pair colorization"이 비슷한 효과를 주기 때문에 필수성이 줄었지만, 여전히 Python/YAML 개발자에게 인기가 많다.

{
  "indentRainbow.colors": [
    "rgba(255,255,64,0.07)",
    "rgba(127,255,127,0.07)",
    "rgba(255,127,255,0.07)",
    "rgba(79,236,236,0.07)"
  ],
  "indentRainbow.ignoreLinePatterns": [
    "/[ \t]* [*]/g"
  ],
  "indentRainbow.tabmixColor": "rgba(255,127,127,0.3)"
}

장점:

  • Python/YAML/Kubernetes manifest에서 들여쓰기 레벨을 즉시 파악
  • 알파값을 낮추면 거슬리지 않음
  • tab/space 혼용 감지 (tabmixColor)

단점:

  • 화면이 시끄러워질 수 있음 → 알파값을 0.05-0.1로 낮춰서 사용 권장
  • VS Code의 bracket pair colorization과 시각적으로 겹칠 수 있음

대안으로는 Bracket Pair Color DLW(deprecated, 내장 기능으로 대체), Rainbow CSV(CSV 전용) 등이 있다. 2026년 권장: Python/Kubernetes를 자주 쓴다면 깐다, 아니면 굳이 필요 없음.

6. Dependi (구 Crates) — Rust 의존성 인라인

Rust의 Cargo.toml에서 crate 버전 위에 최신 버전 정보를 인라인으로 표시하는 익스텐션이다. 원래 이름은 "crates"였는데 2023년 maintainer가 바뀌면서 "Dependi"로 리브랜딩됐고, Rust뿐 아니라 npm(package.json), PHP(composer.json), Python(pyproject.toml/requirements.txt), Go(go.mod) 등 여러 패키지 매니저를 지원하게 됐다.

# Cargo.toml — Dependi가 인라인으로 최신 버전 표시
[dependencies]
serde = "1.0.197"     # ◀ latest: 1.0.219
tokio = "1.36.0"      # ◀ latest: 1.41.0
clap = "4.5.4"        # ◀ latest: 4.5.21
{
  "dependi.npm.indexServerURL": "https://registry.npmjs.org",
  "dependi.rust.indexServerURL": "https://crates.io",
  "dependi.vulnerability.ghsa.enabled": true,
  "dependi.vulnerability.osv.enabled": true
}

장점:

  • 버전 업데이트 결정이 빠르다. Cargo.toml에서 직접 보고 바로 수정
  • 취약점 표시: GHSA/OSV 데이터베이스 조회해서 CVE가 있는 버전을 빨간색으로 표시 (2024년 추가)
  • 여러 언어 지원: Rust 외에 npm/Python/Go까지

단점:

  • private registry는 별도 설정 필요
  • 큰 모노레포에서 모든 파일을 인덱싱하면 느려질 수 있음

Rust 개발자라면 무조건 깐다. Node 개발자도 깔아두면 좋다(다만 Renovate/Dependabot 같은 자동화가 있으면 중복).

7. Vim / Neovim 모드 — 마우스 없이

VS Code에서 Vim 키바인딩을 쓰려면 두 가지 선택지가 있다.

VSCodeVim (vscodevim)

  • 다운로드 7,000만 회 이상, 사실상 표준
  • Pure JavaScript로 Vim 모드를 에뮬레이션
  • Visual/Normal/Insert/Command 모드, ex 명령어, 매크로, leader 키 매핑 등 거의 모든 Vim 기능 지원
  • .vimrc 일부 호환
{
  "vim.useSystemClipboard": true,
  "vim.useCtrlKeys": true,
  "vim.hlsearch": true,
  "vim.leader": "<space>",
  "vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": ["<leader>", "w"],
      "commands": ["workbench.action.files.save"]
    },
    {
      "before": ["<leader>", "f"],
      "commands": ["workbench.action.quickOpen"]
    }
  ],
  "vim.handleKeys": {
    "<C-d>": true,
    "<C-f>": false
  }
}

단점: 진짜 Neovim의 Lua 플러그인을 못 쓴다. 복잡한 매크로/플러그인은 안 됨.

vscode-neovim (asvetliakov)

  • 다운로드 200만 회 이상
  • 실제 Neovim 바이너리를 백엔드로 실행해서 init.lua/init.vim을 그대로 사용
  • VSCodeVim보다 호환성이 훨씬 좋음 (텔레스코프 같은 일부 UI 플러그인 제외)
  • 설정이 살짝 복잡함 (Neovim 0.10+ 필요)
{
  "vscode-neovim.neovimExecutablePaths.darwin": "/opt/homebrew/bin/nvim",
  "vscode-neovim.neovimInitVimPaths.darwin": "~/.config/nvim/init.lua",
  "vscode-neovim.useWSL": false
}

선택 가이드:

  • Vim 키바인딩만 필요: VSCodeVim
  • 이미 Neovim init.lua를 관리하고 있음: vscode-neovim
  • 회사 정책이 외부 바이너리 금지: VSCodeVim 외 선택지 없음

2026년 시점에서 신규 Vim 사용자는 VSCodeVim으로 시작하고, Neovim 사용자가 VS Code에 발 한 짝 걸칠 때 vscode-neovim을 쓰는 패턴이 일반적이다.

8. AI 익스텐션 — Tabnine / Codeium / Cody / Copilot / Continue / Cline

2026년 AI 익스텐션 시장은 6개 주요 플레이어로 정리됐다. 각자 포지션이 다르다.

GitHub Copilot (GitHub/Microsoft)

  • 사실상 디폴트. 월 10달러 (개인), 무료 티어 추가 (2024년 12월)
  • Chat / Workspace / Agent Mode 세 가지 인터페이스
  • 모델: GPT-4o, Claude Sonnet 3.5/3.7, Gemini 등 선택 가능 (Pro+ 이상)
  • 강점: Microsoft 인프라 통합, MFA/SSO 지원, 엔터프라이즈 거버넌스
  • 약점: 컨텍스트 윈도우가 Cursor/Continue 대비 작음

Codeium (Codeium Inc., 현 Windsurf)

  • 무료 (개인 사용)
  • 70개 이상의 언어 자동완성
  • 2024년부터 Cascade Chat (long-context), 2025년부터 자체 IDE "Windsurf" 출시 (Cursor 직접 경쟁)
  • 강점: 무료, 빠른 자동완성 응답시간, 엔터프라이즈 옵션도 합리적
  • 약점: 코드베이스 인덱싱이 Copilot 대비 약함

Tabnine (Tabnine Ltd.)

  • 가장 오래된 AI 자동완성 (2018년부터)
  • 로컬 모델 옵션: 개인 데이터를 클라우드로 보내지 않는 워크플로
  • 2024년 Tabnine Chat, 2025년 Tabnine Code Review 추가
  • 강점: 보안에 민감한 환경 (금융/의료/방산)에 안전한 선택
  • 약점: 자동완성 품질이 Copilot/Codeium 대비 약함

Cody (Sourcegraph)

  • Sourcegraph의 코드 검색 인프라를 활용
  • 코드베이스 컨텍스트가 가장 강력: 모노레포 전체를 컨텍스트로 잡음
  • 2024년 Agentic Context (자동으로 관련 파일 찾기)
  • 강점: 대형 코드베이스에서 정확도 높음
  • 약점: Sourcegraph 셋업이 선행돼야 함

Continue (Continue Dev)

  • OSS, BYOK (Bring Your Own Key)
  • OpenAI/Anthropic/Ollama/로컬 모델 다 연결 가능
  • 2025년 .continue/config.yaml로 팀별 룰 설정 지원
  • 강점: 모델 비용을 직접 관리, 회사가 자체 LLM 게이트웨이를 쓸 때 적합
  • 약점: 설정 복잡도, UX가 Copilot 대비 거침

Cline (구 Claude Dev)

  • OSS, 에이전트 중심: 단순 자동완성이 아니라 "이 작업을 해줘"에 최적화
  • Anthropic Claude를 주로 쓰지만 OpenRouter 경유로 다양한 모델 지원
  • 2025년 Plan/Act 모드 분리, MCP 서버 통합
  • 강점: 실제 작업을 위임할 수 있는 에이전트
  • 약점: 토큰 비용이 높음 (에이전트 특성상)
// 한 가지만 활성화하는 게 정신건강에 좋다
{
  "github.copilot.enable": {
    "*": true,
    "plaintext": false,
    "markdown": true
  },
  "github.copilot.editor.enableAutoCompletions": true,
  "continue.enableTabAutocomplete": false,
  "codeium.enableConfig": {
    "*": false
  }
}

선택 가이드:

  • 기본 선택: GitHub Copilot. 회사가 사주면 더 좋음
  • 무료 우선: Codeium 또는 Continue + 무료 모델
  • 보안 민감: Tabnine (로컬 모델 옵션)
  • 대형 모노레포: Cody
  • 에이전트 작업 필요: Cline
  • 자체 LLM 게이트웨이 있음: Continue

중요: 자동완성 익스텐션을 두 개 이상 동시에 켜면 트리거가 충돌해서 양쪽 다 사라진다. 한 번에 하나만 활성화하라.

9. Tailwind CSS IntelliSense / Prisma — 프레임워크 친화

특정 프레임워크가 만든 공식 익스텐션 중 가장 잘 만들어진 두 개다.

Tailwind CSS IntelliSense (Tailwind Labs)

Adam Wathan을 비롯한 Tailwind 팀 공식 익스텐션. Tailwind를 쓴다면 무조건 깐다.

  • 클래스 자동완성 (현재 설정 기반)
  • hover 시 실제 CSS 미리보기
  • 색상 클래스 옆에 색 미리보기
  • 정렬되지 않은 클래스 경고
  • 커스텀 클래스 (apply, theme function) 지원
  • 2024년부터 Tailwind v4 alpha 지원, 2025년 v4 정식 지원
{
  "tailwindCSS.experimental.classRegex": [
    ["cva\\(([^)]*)\\)", "[\"'`]([^\"'`]*).*?[\"'`]"],
    ["cx\\(([^)]*)\\)", "(?:'|\"|`)([^']*)(?:'|\"|`)"]
  ],
  "tailwindCSS.includeLanguages": {
    "typescript": "javascript",
    "typescriptreact": "javascript"
  },
  "editor.quickSuggestions": {
    "strings": "on"
  }
}

cva/cx/clsx/twMerge 같은 헬퍼 함수 안에서도 자동완성을 받으려면 위 같은 정규식 설정이 필요하다.

Prisma (Prisma)

Prisma 공식 익스텐션. schema.prisma 파일의 문법 하이라이팅, 자동완성, 포맷팅, 모델 간 관계 jump-to-definition을 지원한다.

{
  "[prisma]": {
    "editor.defaultFormatter": "Prisma.prisma",
    "editor.formatOnSave": true
  },
  "prisma.fileWatcher": true
}

특히 schema.prisma의 model 사이 관계 자동완성과 @@index/@relation 옵션 자동완성이 강력하다. Prisma를 쓴다면 무조건 깐다.

다른 프레임워크 친화 익스텐션:

  • Vue / Volar (Vue Tooling): Vue 공식, Vue 3 + TypeScript에 필수
  • Svelte (Svelte 팀): Svelte 공식
  • Astro (Astro 팀): Astro 공식
  • Solid (community): Solid.js
  • Angular Language Service (Angular 팀): Angular 공식

공통 패턴: 프레임워크 팀이 만든 공식 익스텐션은 거의 항상 third-party 대안보다 낫다.

10. ESLint / Prettier / Biome — linter + formatter

2026년 JS/TS 생태계에서 가장 시끄러운 영역이다. 세 도구의 포지션이 갈라졌다.

ESLint (ESLint 팀)

  • JavaScript 표준 린터
  • 2024년 v9 flat config로 마이그레이션 (eslint.config.js)
  • 익스텐션은 dbaeumer.vscode-eslint
  • 강점: 플러그인 생태계가 압도적 (@typescript-eslint, eslint-plugin-react, eslint-plugin-import 등)
  • 약점: 느림, 설정 복잡함

Prettier (Prettier 팀)

  • JS/TS/HTML/CSS/JSON/Markdown 포맷터
  • 익스텐션은 esbenp.prettier-vscode
  • 강점: "선택의 여지 없음" 철학, 대부분의 프로젝트 표준
  • 약점: 일부 옵션이 부족 (Biome 비교 시), 플러그인 시스템이 약함

Biome (Biome 팀, 구 Rome)

  • Rust로 작성된 통합 도구 (linter + formatter)
  • 2024년 v1 stable, 2025년 v2 출시 (TypeScript type-aware 룰 추가)
  • 익스텐션은 biomejs.biome
  • 강점: 빠름 (Rust), 단일 도구, 설정 단순
  • 약점: 플러그인 생태계가 ESLint 대비 빈약, 일부 ESLint 룰 미지원
// .vscode/settings.json — ESLint + Prettier 조합
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  },
  "eslint.experimental.useFlatConfig": true,
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}
// .vscode/settings.json — Biome 단독 (ESLint + Prettier 둘 다 대체)
{
  "editor.defaultFormatter": "biomejs.biome",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "quickfix.biome": "explicit",
    "source.organizeImports.biome": "explicit"
  },
  "[typescript]": {
    "editor.defaultFormatter": "biomejs.biome"
  }
}

2026년 선택 가이드:

  • 신규 프로젝트, 단순성 우선: Biome 단독
  • 기존 ESLint 룰이 많은 프로젝트: ESLint + Prettier 유지
  • 모노레포 + 빠른 CI 필요: Biome (Rust 속도 이점)
  • React Native, Expo 같은 특수 환경: ESLint + Prettier (플러그인 의존성)

중요: ESLint + Prettier + Biome 셋 다 깔면 포맷팅이 충돌해서 저장할 때마다 코드가 뒤바뀐다. 한 카테고리당 하나만 활성화하라.

11. Even Better TOML / Markdown All in One — 마크업

Even Better TOML (tamasfe)

TOML 파일(Cargo.toml, pyproject.toml, netlify.toml 등)을 위한 익스텐션. 문법 하이라이팅, 자동완성, 검증, 포맷팅을 지원한다.

{
  "[toml]": {
    "editor.defaultFormatter": "tamasfe.even-better-toml",
    "editor.formatOnSave": true
  },
  "evenBetterToml.schema.associations": {
    "Cargo\\.toml": "https://json.schemastore.org/cargo.json",
    "pyproject\\.toml": "https://json.schemastore.org/pyproject.json"
  }
}
  • JSON Schema 통합: Cargo.toml에 잘못된 키를 쓰면 빨간 줄
  • Tombi라는 별도 LSP 백엔드 사용 (2024년부터)
  • 포맷팅 안정성: 주석 보존, 정렬 옵션 풍부

Rust/Python 개발자에게 필수. 다운로드 800만 회 이상.

Markdown All in One (Yu Zhang)

Markdown 파일 편집에 필요한 거의 모든 기능을 모은 익스텐션.

  • 키보드 단축키 (Ctrl+B 볼드, Ctrl+I 이탤릭)
  • 자동 목차 생성/갱신
  • 리스트 자동 번호 매김
  • 표 포맷팅
  • 수학 수식 미리보기 (KaTeX)
  • 미리보기와 에디터 동기화
{
  "markdown.extension.toc.levels": "2..6",
  "markdown.extension.toc.updateOnSave": true,
  "markdown.extension.preview.autoShowPreviewToSide": false,
  "markdown.extension.list.indentationSize": "adaptive",
  "markdown.extension.tableFormatter.normalizeIndentation": true
}

블로그를 MDX로 쓰는 사람, README를 자주 갱신하는 사람, 기술 문서를 쓰는 사람 모두에게 유용. 다운로드 1,300만 회 이상.

대안:

  • Markdown Preview Enhanced: 더 강력한 미리보기 (mermaid, plantuml, presentation mode)
  • markdownlint: 린팅 전용

12. Live Server (Ritwick Dey) — HTML 미리보기

Ritwick Dey의 Live Server는 정적 HTML을 로컬 서버로 띄우고 파일 변경 시 자동 리로드한다. 다운로드 4,000만 회 이상으로 VS Code Marketplace 최상위권 익스텐션이다.

{
  "liveServer.settings.port": 5500,
  "liveServer.settings.donotShowInfoMsg": true,
  "liveServer.settings.donotVerifyTags": true,
  "liveServer.settings.CustomBrowser": "chrome"
}

장점:

  • 클릭 한 번에 로컬 서버: index.html에서 우클릭 → "Open with Live Server"
  • 자동 리로드: HTML/CSS/JS 변경 시 브라우저 자동 새로고침
  • 모바일 테스트: 같은 네트워크에서 IP로 접속 가능

단점:

  • 활발한 유지보수 중단 상태: 2022년 이후 큰 업데이트 없음
  • 모듈 import 지원 미흡: ES module import는 별도 설정 필요
  • HTTPS 미지원 (커뮤니티 포크 Five Server는 지원)

대안:

  • Five Server: Live Server 포크, HTTPS/HTTP2 지원
  • Live Preview (Microsoft 공식): 내장 미리보기, 외부 브라우저 없이
  • Vite/Next.js 같은 프레임워크 dev 서버: 프레임워크를 쓰면 굳이 Live Server 필요 없음

2026년 권장: 순수 HTML/CSS 학습 단계라면 깔자, 프레임워크 프로젝트라면 dev 서버 쓰자.

13. REST Client / ThunderClient — API 테스트

Postman/Insomnia를 VS Code 안에서 대체한다.

REST Client (Huachao Mao)

.http 또는 .rest 파일에 HTTP 요청을 plain text로 쓰고 실행한다.

### GET 사용자 정보
GET https://api.example.com/users/1
Authorization: Bearer {{token}}
Accept: application/json

### POST 새 사용자
POST https://api.example.com/users
Content-Type: application/json

{
  "name": "Alice",
  "email": "alice@example.com"
}

### 환경별 변수
@baseUrl = https://api.example.com
@token = abc123

장점:

  • plain text 파일: Git에 커밋해서 팀원과 공유 가능
  • Postman 컬렉션 import 가능
  • 변수/환경: settings.json에 환경별 변수
  • 응답 저장: 다음 요청에서 응답 값 참조 가능

다운로드 800만 회 이상. API 테스트를 Git에 남기고 싶은 팀에게 최적.

ThunderClient (Ranga Vadhineni)

GUI 기반 API 클라이언트. Postman을 VS Code 안에서 직접 흉내낸다.

장점:

  • UI가 직관적: Postman 사용자에게 친숙
  • 컬렉션/환경 관리: 폴더 트리 구조
  • 테스트 스크립트: JS로 응답 검증

단점:

  • 2023년부터 상당 부분 유료화: 컬렉션 5개 제한, 팀 동기화 유료
  • Open Source 정책 후퇴: 한때 OSS였으나 점진적 폐쇄

2026년 선택 가이드:

  • plain text 선호, Git 공유 필요: REST Client
  • GUI 선호, Postman 마이그레이션: ThunderClient (단, 유료화 정책 확인)
  • 팀 차원의 API 카탈로그: 둘 다 부족, Bruno/Hoppscotch 고려

14. ShellCheck / EditorConfig — 스타일 가드

ShellCheck (Timon Wong)

bash/sh 스크립트 정적 분석기. ShellCheck 자체는 OSS 도구이고, VS Code 익스텐션은 그 결과를 표시한다.

#!/bin/bash
# ShellCheck가 잡는 흔한 실수들

# SC2086: 인용 부호 누락 (단어 분리 위험)
files=$1
ls $files          # warning

# SC2046: $() 결과를 인용 없이 사용
files=$(ls *.txt)
echo $files        # warning

# 올바른 방식
ls "$files"
echo "$files"
{
  "shellcheck.enable": true,
  "shellcheck.run": "onSave",
  "shellcheck.exclude": ["SC2086"],
  "shellcheck.customArgs": ["-x"]
}

장점:

  • bash의 함정을 거의 다 잡아줌: 인용 부호, 변수 확장, exit code 처리
  • CI에 연동 가능: 같은 룰을 로컬과 CI에서

단점:

  • ShellCheck 바이너리 설치 필요 (brew install shellcheck)
  • POSIX 외 셸은 부분 지원: zsh/fish는 제한적

DevOps/SRE 직군에 필수. 다운로드 200만 회 이상.

EditorConfig (EditorConfig 팀)

.editorconfig 파일을 읽어 들여쓰기/줄바꿈/인코딩을 프로젝트별로 통일한다. 거의 모든 IDE/에디터가 지원하므로 팀에 IDE가 섞여 있을 때 필수.

# .editorconfig
root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.{md,mdx}]
trim_trailing_whitespace = false

[Makefile]
indent_style = tab

장점:

  • 에디터 통일: VS Code/IntelliJ/Vim/Sublime 모두 지원
  • 언어별 룰: Markdown은 trailing whitespace 보존, Makefile은 탭
  • 설정이 단순: 한 파일, 한 번 작성

단점:

  • Prettier/Biome이 일부 영역 중복 → 우선순위 정의 필요

2026년 권장: 모든 신규 프로젝트에 .editorconfig 추가. 익스텐션은 무료 + 무해.

15. Polacode / Quokka.js / Code Tour — 데모/스크래치/투어

이 세 익스텐션은 "흔치 않지만 특정 상황에서 유일한 답"인 도구들이다.

Polacode (P. Cong)

코드 블록을 예쁜 이미지로 캡처한다. 트위터/블로그/발표 자료에 코드를 넣을 때 사용.

  • 선택 영역을 PNG로 저장
  • 배경 그라데이션/패딩/그림자 커스터마이징
  • VS Code의 현재 테마/폰트 그대로 반영

대안: Carbon (carbon.now.sh), Ray.so, CodeSnap (VS Code 익스텐션). 2026년 시점에서는 Carbon이 더 인기지만 Polacode는 에디터 안에서 끝낼 수 있다는 장점이 있다.

Quokka.js (Wallaby.js)

JavaScript/TypeScript scratchpad. 코드를 작성하는 동시에 라인별 결과가 인라인으로 표시된다.

// Quokka가 실행 결과를 인라인으로 표시
const arr = [1, 2, 3, 4, 5]
const sum = arr.reduce((a, b) => a + b, 0)  // ◀ 15
const avg = sum / arr.length                  // ◀ 3

const fetched = await fetch('https://api.example.com/data').then(r => r.json())
console.log(fetched)                          // ◀ { id: 1, ... }
  • 무료 (Community Edition)과 유료 (Pro) 분리
  • Pro는 import 자동 추가, 풍부한 출력, JSX 미리보기 등
  • 알고리즘 연습/디버깅/API 응답 탐색에 유용

대안: Node REPL, 브라우저 콘솔, replit, Observable. Quokka는 "에디터 안에서 즉시"라는 점이 강점.

Code Tour (Microsoft)

코드베이스에 가이드 투어를 만들 수 있다. 마치 슬라이드처럼 "이 파일의 이 라인을 봐, 다음은 이 함수야" 식으로 단계별 안내.

// .tours/onboarding.tour
{
  "title": "신규 개발자 온보딩",
  "steps": [
    {
      "file": "src/app.ts",
      "line": 1,
      "description": "앱 진입점. dotenv 로딩 후 server.ts로 위임한다."
    },
    {
      "file": "src/server.ts",
      "line": 24,
      "description": "Express 미들웨어 등록. CORS/auth/error 순서가 중요."
    }
  ]
}
  • 온보딩 자동화: 신규 입사자가 코드베이스를 자기 페이스로 탐색
  • PR 설명: 큰 PR의 변경점을 투어로 묶어 설명
  • OSS 튜토리얼: 외부 기여자에게 "여기서부터 읽으세요" 가이드

다운로드 100만 회 이상. 사용 빈도는 낮지만 만들 때 한 번 만들면 6개월~1년 가치 있음.

16. Project Manager / GitHub Pull Requests — 워크플로

Project Manager (Alessandro Fragnani)

여러 프로젝트를 빠르게 전환하는 익스텐션. VS Code 내장 "Recent Workspaces"보다 강력하다.

  • 즐겨찾기 프로젝트 저장: 태그/색깔로 그룹화
  • Git 저장소 자동 감지: 지정한 폴더 아래 모든 git 저장소를 자동 인식
  • VSCode Remote 지원: SSH/WSL/Container 환경 전환
{
  "projectManager.git.baseFolders": [
    "~/dev",
    "~/work"
  ],
  "projectManager.git.maxDepthRecursion": 3,
  "projectManager.sortList": "Recent",
  "projectManager.openInNewWindowWhenClickingInStatusBar": true
}

상태바에 현재 프로젝트 이름이 표시되고, 클릭하면 프로젝트 목록이 뜬다. 동시에 여러 클라이언트/사이드 프로젝트를 오가는 개발자에게 필수.

대안: Workspace Explorer, Peacock(프로젝트별 색깔 자동 변경). Project Manager가 가장 완성도 높음.

GitHub Pull Requests (GitHub)

GitHub 공식 익스텐션. PR을 VS Code 안에서 만들고 리뷰한다.

  • PR 만들기/체크아웃/리뷰/머지를 에디터 안에서
  • 인라인 코멘트: GitHub.com의 리뷰 UI를 에디터에 재현
  • Copilot for Pull Requests 통합 (Pro+)
  • Codespaces 연동: PR을 Codespace로 열기
{
  "githubPullRequests.pullBranch": "always",
  "githubPullRequests.defaultMergeMethod": "squash",
  "githubPullRequests.notifications": "pullRequests"
}

장점: GitHub로 작업하는 거의 모든 팀에게 유용. CLI(gh)와 함께 쓰면 키보드/GUI 둘 다 빠름.

단점: GitLab/Bitbucket은 지원 안 됨 (별도 익스텐션 필요).

대안: GitLens의 PR 통합(일부 기능), GitHub CLI(터미널 선호).

17. 한국 / 일본 — 토스, 카카오, 메르카리, ZOZO

회사별 추천 익스텐션 풀을 비교한다. 출처는 각 회사 기술 블로그와 공개 컨퍼런스 발표.

토스 (Toss / Viva Republica)

토스 프런트엔드 챕터가 공개한 익스텐션 묶음 (2024-2025년 토스 SLASH 컨퍼런스 자료 기준):

  • ESLint + Prettier (Biome는 일부 신규 프로젝트에서 실험)
  • GitLens
  • Tailwind CSS IntelliSense (디자인 시스템 tds 기반)
  • Error Lens, Pretty TypeScript Errors
  • GitHub Copilot (전사 도입)
  • Code Spell Checker (영어 오타 검사)
  • 자체 익스텐션: TDS Component Snippet (디자인 시스템 컴포넌트 자동완성)

토스는 "프론트엔드 펀더멘털 챕터" 단위로 도구 표준화를 했다. 새 입사자는 첫째 날 동일한 익스텐션 묶음을 깔게 된다.

카카오 (Kakao)

카카오 FE/BE 챕터별로 추천 익스텐션이 다르다 (Kakao Tech Blog 기준):

  • 공통: GitLens, Error Lens, ESLint, Prettier
  • BE (Java/Spring): Spring Boot Tools, Lombok, Maven for Java
  • FE: Tailwind CSS IntelliSense, Vue Volar, Pretty TypeScript Errors
  • DevOps: ShellCheck, Kubernetes, Even Better TOML, HashiCorp Terraform
  • AI: 카카오톡채널 사내 AI 도구 + GitHub Copilot (선택)

카카오는 사내 LLM 게이트웨이를 운영하기 때문에 Continue + 사내 모델 조합도 일부 팀이 사용한다.

메르카리 (Mercari)

메르카리 마이크로서비스팀의 공개 dotfiles 기준:

  • GitLens
  • Error Lens
  • ESLint + Prettier
  • Even Better TOML (Rust 일부 사용)
  • ShellCheck
  • Go (공식 Google 익스텐션)
  • Protobuf (gRPC 사용)
  • GitHub Copilot (전사 도입 2024년 발표)
  • Mercari 내부 익스텐션: 마이크로서비스 카탈로그/Backstage 연동

메르카리는 마이크로서비스 100+ 개를 운영하기 때문에 Project Manager 사용률이 높다.

ZOZO (ZOZOTOWN)

ZOZO 테크블로그가 공개한 추천 익스텐션 (2024-2025년 ZOZO TECH BLOG):

  • GitLens
  • ESLint + Prettier
  • Tailwind CSS IntelliSense
  • Pretty TypeScript Errors
  • vscode-icons (회사 표준)
  • Material Icon Theme도 자유 선택
  • GitHub Copilot

ZOZO는 디자인 시스템 "ZOZO Design System"용 자체 익스텐션을 만들어 사내 배포한다 (Material 컴포넌트 자동완성).

공통 패턴:

  • GitLens는 한일 양국 모두 사실상 디폴트
  • GitHub Copilot은 2024년 전후로 대형 IT 회사들이 전사 도입 (보안 검토 통과 후)
  • 언어/프레임워크 익스텐션은 팀별 자유
  • 회사 표준 디자인 시스템이 있는 곳은 사내 익스텐션을 만들어 배포하는 경향

18. 누가 무엇을 골라야 하나 — 신규 / TS / Rust / 풀스택

마지막 의사결정 가이드다. "전부 깐다"는 답은 없다. 역할에 맞는 묶음을 깐다.

신규 개발자 (학습 중)

미니멀 묶음. 화면을 시끄럽게 만들지 않는다.

  • GitLens: Git을 시각적으로 익히는 가장 빠른 길
  • Path Intellisense: import 실수 줄이기
  • Error Lens: 에러를 놓치지 않기 (단, followCursor: activeLine로 조용히)
  • Material Icon Theme: 파일 종류 빠르게 식별
  • GitHub Copilot 무료 티어 또는 Codeium: AI 자동완성에 익숙해지기
  • EditorConfig: 팀 프로젝트 합류 시 자동 적용
  • Live Server: 순수 HTML/CSS 학습용

총 7개. 익숙해지면 하나씩 추가한다.

TypeScript 풀스택 (Next.js / tRPC / Prisma)

타입 에러와 매일 싸우는 직군. UI 개선 익스텐션이 핵심.

  • 위 신규 개발자 묶음 +
  • Pretty TypeScript Errors: 제네릭 에러 해독에 필수
  • Tailwind CSS IntelliSense: Next.js + Tailwind가 디폴트
  • Prisma: schema.prisma 편집
  • ESLint + Prettier 또는 Biome
  • GitHub Copilot Pro: 모델 선택 가능, Workspace 사용
  • REST Client 또는 ThunderClient: API 테스트
  • GitHub Pull Requests: PR 워크플로

총 14개 안팎. Continue나 Cline을 추가하면 더 강력해지지만 Copilot과 충돌 주의.

Rust 개발자

  • 신규 개발자 묶음 +
  • rust-analyzer (Rust 공식, 사실상 IDE 자체)
  • Dependi: Cargo.toml 버전 관리
  • Even Better TOML: Cargo.toml 편집
  • CodeLLDB: Rust 디버거
  • crates.io (선택)
  • Better TOML 대신 Even Better TOML 권장
  • ShellCheck: build script가 bash인 경우
  • GitHub Copilot 또는 Codeium: Rust도 잘 지원

총 12개 안팎. rust-analyzer는 Rust 개발의 사실상 모든 것이라 비중이 크다.

DevOps / SRE

  • 신규 개발자 묶음 +
  • ShellCheck: bash 스크립트 필수
  • HashiCorp Terraform: HCL 편집
  • Kubernetes (microsoft): YAML 검증, kubectl 통합
  • Docker (Microsoft): Dockerfile/compose 편집
  • Even Better TOML
  • Remote-SSH / Remote-Containers / Dev Containers: 원격 작업
  • YAML (Red Hat): JSON Schema 검증
  • GitHub Pull Requests

AI 익스텐션은 선택. DevOps는 명령어 자체보다 "이 환경에서 어떻게 동작할까"가 본질이라 AI 자동완성 가치가 상대적으로 낮다.

데이터 엔지니어 / ML

  • 신규 개발자 묶음 +
  • Python (Microsoft): 공식
  • Pylance (Microsoft): 빠른 IntelliSense
  • Ruff (Astral): 빠른 린터 + 포맷터
  • Jupyter (Microsoft): 노트북 편집
  • Data Wrangler (Microsoft): pandas DataFrame 시각 편집 (2024년 공개)
  • GitHub Copilot 또는 Codeium: pandas/sklearn 자동완성 강함
  • Even Better TOML: pyproject.toml

총 11개 안팎. Python 개발은 Microsoft 공식 익스텐션 묶음(Python + Pylance + Jupyter)이 사실상 표준이다.

모든 직군 공통 추가 추천

  • EditorConfig: 항상 깐다
  • GitLens: 항상 깐다
  • GitHub Pull Requests: GitHub 쓰면 항상 깐다
  • Project Manager: 동시에 3개 이상 프로젝트를 다루면 깐다
  • Markdown All in One: README/문서를 쓴다면 깐다

VS Code 익스텐션 선정은 도구의 문제가 아니라 워크플로의 문제다. 2026년의 차이점은 AI 익스텐션이 디폴트가 됐다는 점이고, 동시에 Biome 같은 통합 도구가 나오면서 "여러 도구를 깔지 말고 하나를 깔자"는 흐름이 시작됐다는 점이다. 한 카테고리당 하나만 깔고, 기본 설정을 30분 정도 다듬고, 6개월에 한 번 정리하면 익스텐션은 친구가 된다. 그 정리를 안 하면 익스텐션은 점점 메모리를 잡아먹고 시작 시간을 늘리는 짐이 된다. 익스텐션은 추가하기는 쉬워도 빼기는 어려운 자산이라는 점을 기억하라.

참고 / References