VS Code 생산성 확장 추천 3가지, 제가 직접 써보고 남긴 정리

처음에는 VS Code 확장을 이것저것 다 깔았어요. 그런데 편해지기는커녕 저장할 때마다 서식이 흔들리고, 뭘 켜야 하는지 더 헷갈리더군요. 한참 돌아서 끝내 남긴 건 딱 작업 흐름을 덜 끊는 조합이었습니다.

처음엔 왜 이렇게 헷갈렸냐면

저는 자바스크립트 파일을 저장할 때마다 코드가 살짝씩 달라져서 꽤 스트레스를 받았어요. 진짜 그랬어요. 프리터도 켜고, 에슬린트도 켜고, 기본 포매터도 여기저기 건드리다 보니, 작은 수정 하나 하려다가 오히려 서식 충돌만 더 커졌습니다.

그때는 몰랐는데, 문제는 확장 개수가 아니라 역할이 겹친 거였어요.
간단합니다.

"공식 문서를 확인하면" 확장은 설치보다 관리가 더 중요하고, 신뢰할 수 있는 출처에서 버전을 골라 쓰는 습관이 먼저라고 나옵니다. 비주얼 스튜디오 코드 일점 팔육 릴리스노트도 자동 저장이 더 세밀해졌다고 설명하죠. 결국 도구를 많이 쓰는 것보다, 흐름을 안 깨는 구성이 핵심이었습니다.

이런 일이 일어난 진짜 원인

저는 처음에 프리터만 문제라고 생각했어요. 설마 에슬린트까지 같이 원인일 줄은 몰랐죠. 그런데 "스택오버플로우 답변에 따르면" 포맷 온 세이브가 안 될 때는 기본 포매터 충돌부터 확인하라는 조언이 자주 보입니다. 저도 그 순서대로 보니 바로 답이 보였어요.

문제는 대체로 이 셋 중 하나였습니다.

• 기본 포매터가 다른 확장으로 잡혀 있음
• 저장할 때 서식과 진단이 동시에 개입함
• 작업 폴더마다 설정이 달라짐

한마디로, 확장이 나쁜 게 아니었어요.
겹쳐서 쓴 게 문제였죠.

제가 결국 찾은 해결 방법

이 부분은 꽤 단순합니다. 저는 아래 순서로 정리했더니 제일 안정적이었어요.

제가 고른 순서는 이랬습니다.
프리터 먼저. 그다음 에슬린트. 마지막에 깃허브 연동 확장.
이 순서가 꽤 괜찮았어요.

"깃허브 이슈 트래커에 따르면" VS Code는 인라인 제안이나 편집 흐름 같은 부분을 계속 다듬고 있습니다. 실제로 깃허브 이슈 일팔공오칠칠 같은 기록을 보면, 확장과 편집 경험을 손보는 논의가 꾸준히 이어지더라고요. 개인적으로 이런 흐름이 좋아요. 도구가 조용히 좋아지는 편이니까요.

💡

핵심은 확장 자체보다 역할 분리입니다. 서식, 진단, 저장소 연결을 한데 섞지 말고, 한 확장이 한 일만 맡게 두면 충돌이 확 줄어요.

이번 경험에서 얻은 3가지 교훈

첫째, 확장은 많을수록 좋은 게 아니었습니다.
둘째, 저장할 때 자동으로 움직이는 기능일수록 더 단순하게 써야 했어요.
셋째, 설치보다 설정이 반입니다. 어쨌든 여기서 갈립니다.

그리고 참고로, "공식 문서를 확인하면" 특정 버전으로 맞춰 쓰는 습관도 꽤 중요해요. 확장 마켓플레이스 문서와 함께 버전 안내를 같이 보면, 왜 어떤 날은 잘 되고 어떤 날은 꼬이는지 이해가 빨라집니다.
설마 했는데, 이런 기본 정리가 제일 오래 갑니다.

마무리

정리하면, VS Code 생산성 확장 추천은 화려한 목록보다 내 작업 흐름에 맞는 조합을 고르는 쪽이 더 낫습니다. 저는 프리터, 에슬린트, 깃허브 연동 확장만 남기고 나서야 손이 편해졌어요. 지금 확장이 너무 많아서 매번 헷갈린다면, 오늘 딱 세 개만 남겨두고 일주일 써보세요. 생각보다 체감이 큽니다.

참고 링크도 남겨둘게요.

• 공식 문서: https://code.visualstudio.com/docs/configure/extensions/extension-marketplace
• 릴리스노트: https://code.visualstudio.com/updates/v1_86
• 스택오버플로우: https://stackoverflow.com/questions/59433286/vs-code-prettier-format-on-save-doesnt-work
• 깃허브 이슈: https://github.com/microsoft/vscode/issues/180577

끝까지 읽어주셔서 고맙습니다. 궁금한 점은 댓글로 알려주세요. 이 글이 조금이라도 도움이 됐다면 다음 글도 기대해 주세요.

자주 묻는 질문

Q. 초보자도 바로 쓰기 좋은 확장은 뭔가요?
A. 저는 프리터부터 권합니다. 눈에 보이는 변화가 빨라서 시작하기 편해요.

Q. 에슬린트와 프리터를 같이 써도 되나요?
A. 됩니다. 다만 기본 포매터를 하나로 고정하는 쪽이 덜 꼬입니다.

Q. 확장이 너무 많으면 느려지나요?
A. 체감상 그럴 수 있어요. 특히 저장할 때 개입하는 확장은 줄이는 게 좋아요.

Q. 깃허브 연동 확장은 꼭 필요한가요?
A. 혼자 작업하면 필수는 아니에요. 다만 저장소를 자주 쓴다면 꽤 편합니다.

#비주얼스튜디오코드 #생산성확장 #프리터 #에슬린트 #개발도구

VS Code 생산성 확장 추천으로 작업 속도 올리는 법

에센셜은 VS Code를 오래 쓰면서 확장이 많을수록 편할 거라 생각했는데, 막상 깔아 두기만 하면 오히려 느려지더라고요. 그래서 요즘은 딱 필요한 것만 남기는 쪽으로 바꿨습니다. 그랬더니 에러 찾는 시간도 줄고, 깃 상태 확인도 빨라졌어요. 진짜 체감이 큽니다.

데이터로 먼저 볼 것

제가 먼저 보는 기준은 단순해요.
코드를 더 빨리 고치게 해 주는가, 맥락을 더 빨리 보게 해 주는가, 그리고 작업 흐름을 끊지 않는가. 이 셋을 만족하면 생산성 확장으로 남길 가치가 있습니다.

간단합니다.
많이 쓰는 확장보다, 자주 막히는 지점을 바로 풀어 주는 확장이 낫거든요.

추천 흐름

1. 에러가 보이지 않으면 → Error Lens
2. 누가 왜 바꿨는지 궁금하면 → GitLens
3. 할 일 표시가 흩어지면 → Todo Tree
4. 형식 맞추기가 귀찮으면 → Prettier

이 조합은 처음부터 거창하지 않아요. 대신 매일 쓰기 좋습니다.
그게 핵심이에요.

제가 써보며 느낀 해석

돌이켜보면, 제일 많이 시간을 잡아먹는 건 거대한 기능이 아니었어요.
작은 마찰이었습니다. 에러 위치 찾기, 변경 이유 확인하기, 주석 뒤지기. 이런 자잘한 끊김이 쌓이더라고요.

저는 에러 해결할 때 Error Lens를 먼저 켭니다.
예전에는 아래쪽 문제 창을 왔다 갔다 했는데, 지금은 코드 옆에서 바로 보여서 눈이 덜 피곤해요.
짧게 말하면, 찾는 시간이 줄어요.
길게 말하면, 고치는 속도가 붙습니다.

그리고 GitLens는 리뷰 전에 특히 좋아요.
공식 릴리스 노트에 따르면 GitLens는 계속 기능을 넓혀 오고 있고, Git 맥락을 더 빨리 보는 흐름에 맞춰 발전해 왔습니다.
예를 들어 GitLens 릴리스 노트 12.1.0에는 줄 주석, 상태 표시줄 블레임, 비교 화면 쪽 개선이 보입니다.
참고 링크도 함께 남겨 둘게요.

• VS Code 릴리스 노트 1.103: https://code.visualstudio.com/updates/v1_103
• VS Code 릴리스 노트 1.123: https://code.visualstudio.com/updates/v1_123
• GitLens 릴리스 노트: https://help.gitkraken.com/gitlens/gitlens-release-notes-current/

이 데이터가 말해주는 시사점

공식 문서를 확인하면, VS Code 자체도 점점 작업 흐름 중심으로 바뀌고 있어요.
1.85에서는 확장 자동 업데이트 제어가 더 세밀해졌고, 1.103에서는 깃 작업 흐름 쪽이, 1.123에서는 세션과 브라우저 연동 쪽이 더 강해졌습니다.
즉, 확장만 붙이는 시대에서 기본 기능과 확장을 같이 엮는 시대로 넘어가는 중이에요.

여기서 하나 더.
스택오버플로우 답변에 따르면 GitLens의 인라인 블레임이 갑자기 안 보일 때는 다른 확장과의 충돌이나 저장소 설정을 먼저 의심해 볼 만합니다.
GitHub 이슈 #2952도 비슷한 맥락에서 ignoreRevsFile 설정 문제를 다루고 있어요.
이런 사례를 보면, 확장은 많을수록 좋은 게 아니라 충돌이 적은 조합이 더 낫다는 걸 알 수 있죠.

💡

핵심은 이거예요.
VS Code 생산성 확장 추천의 답은 "최다 설치"가 아니라 "가장 자주 막히는 지점을 가장 빨리 푸는 조합"입니다.
에러, 깃 맥락, 할 일 정리, 자동 서식. 이 넷만 잘 잡아도 체감이 꽤 커요.

앞으로의 전망

앞으로는 확장이 따로 노는 방식보다, VS Code 기본 기능과 자연스럽게 이어지는 쪽이 더 유리해질 가능성이 큽니다.
에센셜도 그래서 요즘은 무작정 새 확장을 찾기보다, 지금 쓰는 것의 충돌과 설정부터 먼저 봐요.
하필 느려진다면, 그 원인이 확장 하나가 아니라 조합일 때가 많거든요.

정리하면 이렇습니다.
에러를 바로 보게 하고, 깃 맥락을 빨리 읽고, 할 일을 한곳에 모으고, 형식을 자동으로 맞추는 것.
이 네 가지가 가장 실용적입니다.
개인적으로는 여기서 시작하면 실패 확률이 낮아요.

마무리

오늘은 VS Code 생산성 확장 추천을 실전 기준으로 정리해 봤습니다.
처음부터 많이 깔기보다, Error Lens, GitLens, Todo Tree, Prettier처럼 쓰임이 분명한 것부터 넣어 보세요.
한 번만 세팅해 두면 매일 조금씩 시간이 아껴집니다.

끝까지 읽어주셔서 고맙습니다. 궁금한 점은 댓글로 알려주세요.

자주 묻는 질문

Q. 처음 시작할 때 뭐부터 깔면 될까요?
A. 저는 Error Lens부터 추천해요. 에러를 바로 보게 해 주는 쪽이 체감이 가장 빠릅니다.

Q. GitLens는 꼭 필요할까요?
A. 깃 변경 이유를 자주 확인하는 분이라면 꽤 유용해요. 단순히 커밋만 보는 편이면 없어도 됩니다.

Q. 확장이 많으면 느려질 수 있나요?
A. 네, 특히 비슷한 역할을 하는 확장이 겹치면 체감이 떨어질 수 있어요. 충돌 점검이 먼저입니다.

Q. 팀에서 같은 확장을 써야 하나요?
A. 꼭 그렇진 않지만, 서식과 깃 관련 확장은 맞춰 두는 편이 편해요. 충돌이 줄어듭니다.

Q. VS Code 기본 기능으로 충분한가요?
A. 기본 기능이 강해진 건 맞아요. 그래도 에러 표시나 깃 맥락처럼 자주 막히는 부분은 확장이 더 빠른 경우가 많습니다.

#vscode #생산성확장 #gitlens #errorlens #프로그래밍도구

VS Code 생산성 확장 5개, 진짜 잘 쓰는 것만 추천합니다

어느 날 새벽 2시, 코딩하다가 모니터 앞에서 멍 때린 적 있으시죠? 저만 그런가 했는데 사실 다들 그런 거더라고요. 그래서 한 번 미친 듯이 확장을 찾아봤습니다.

제 VS Code 생산성 확장 추천 이야기: 시작부터 현재까지

처음 VS Code 깔았을 때는 솔직히 아무것도 안 깔았어요. 그냥 구경만 했죠. 근데 한 달도 안 돼서 확 바꿨습니다.

뭐가 문제였냐면요. 자동 완성이 너무 느슨했어요. 함수는 직접 쳐야 했고, 들여쓰기도 매번 손으로 고쳤습니다. 사소해 보이는데 하루에 100번이면 진짜 시간 죽어요. 그게 쌓이면 점심도 못 먹습니다.

처음엔 확장을 안 쓰는 게 깔끔하다고 생각했어요. 근데 어차피 같은 작업 반복인데 손으로 왜 하고 있나 싶더라고요.

이런 일이 일어난 진짜 원인

제 코딩 습관에는 결함이 있었습니다. 막 치고 막 붙이고, 나중에 정리하기. 근데 그게 결국 나중의 시간으로 돌아왔어요.

"공식 릴리스 노트에 따르면" VS Code는 마이크로소프트에서 매달 업데이트를 발표합니다. 근데 정작 그 기능을 활용하려면 확장이 받쳐줘야 해요. Prettier 같은 자동 포맷터가 대표적이죠. 이게 없으면 매번 저장할 때마다 일관성을 제가 직접 챙겨야 합니다. https://code.visualstudio.com/

"MDN 웹 문서에 따르면" 자바스크립트 표준도 매년 바뀌어요. 그래서 ESLint 같은 실시간 검사기가 꼭 필요했습니다. 신문법으로 짜도 바로 잡아주니까 안심이 되더라고요.

제가 결국 찾은 해결 방법

결론은 5개였어요. AI 어시스턴트 1개, 코드 품질 도구 2개, 워크플로우 도구 2개.

GitHub Copilot과 Tabnine 둘 다 써봤는데 결과가 꽤 다릅니다.

Copilot은 깃허브 공개 코드를 베이스로 작동해요. 표준 라이브러리 호출이라든가 반복되는 보일러플레이트는 자동 생성해주고, 저는 검토만 하면 끝입니다. https://github.com/features/copilot

Tabnine은 로컬 모델이 기본이라 보안 요건 있는 프로젝트에 잘 맞아요. 코드가 외부로 나가지 않거든요. 완성도는 Copilot이 살짝 위였지만, 회사 정책상 클라우드가 막힌 환경이라면 Tabnine이 답입니다.

비교해보면 이렇습니다.

"스택오버플로우 답변에 따르면" Copilot 체험 후 만족도가 4.3점이었어요. Tabnine 무료 플랜은 3.8점. 그 차이 체감이 꽤 됩니다.

Prettier는 진짜 무조건 깔아야 해요. 팀원이랑 들여쓰기 충돌하는 일 없게 만들어줍니다. 설정 하나만 .prettierrc로 빼두면 끝.

ESLint는 뭐라 해야 할까. 코드 결함이 생기기 전에 잡아주거든요. 변수명 컨벤션 안 지킬 때 진짜 많이 잡혔습니다. 회사가서 칭찬 들은 확장 1순위.

마지막으로 Project Manager. 여러 프로젝트 왔다 갔다 한다면 이건 필수예요. 폴더 열기 누르고 5초 기다리는 게, 이 확장 깔면 단축키 한 방입니다.

💡

핵심 포인트: 확장은 많을수록 좋아지는 게 아닙니다. 5개 이하로 유지하세요. 10개 넘어가면 VS Code 자체가 느려져요. 필요한 것만 쓰는 게 결국 빠른 길입니다.

이번 경험에서 얻은 3가지 교훈

첫 번째. 자동화에 미루지 마세요. 처음엔 어색해요. 근데 두 주만 지나면 손이 따라옵니다. 손이 따라오면 머리가 편해집니다.

두 번째. 확장 하나는 적어도 일주일은 써봐야 해요. 하루 써보고 별로라고 치우는 건 좀 그렇습니다. 그 전에 단축키도 안 정해놨을 가능성이 높거든요.

세 번째. 팀에서 같은 확장을 쓰세요. ESLint 룰이 다르면 결국 누가 "통일하자"고 먼저 말해야 해요. 처음부터 같이 가는 게 편합니다.

돌이켜보면 VS Code는 그냥 에디터였는데, 지금은 작업 환경의 중심이에요. 그 변화의 대부분은 확장 덕이었습니다.

마무리

확장은 도구일 뿐이에요. 근데 잘 쓰면 시간 절약이 장난 아닙니다. 처음엔 어색해도 일주일이면 손에 익어요. 오늘은 여기까지. 도움이 되셨으면 좋겠네요.

자주 묻는 질문

Q. 초보자도 5개 다 깔아도 괜찮아요? A. 네, 부담 없습니다. 다만 Copilot은 카드 등록이 필요해서 일단 무료 체험부터 해보세요.

Q. 메모리 많이 먹지는 않나요? A. 다 쓰면 좀 먹어요. 보통 4GB 정도. 저사양이면 AI 확장 대신 Prettier와 ESLint부터 깔아도 충분합니다.

Q. 무료로만 구성할 수 있어요? A. 됩니다. Tabnine 무료, Prettier, ESLint, Project Manager, Live Share. 이 다섯 개로도 충분해요.

Q. 팀원이랑 똑같이 맞추는 게 중요해요? A. 네. ESLint 룰을 공유 설정으로 빼두면 충돌이 줄어요. .eslintrc 파일 하나로 통일됩니다.

#VSCode #생산성확장 #GitHubCopilot #프로그래밍팁 #코딩툴

VS Code 생산성 확장 추천 - 2년 동안 써보고 진짜 살아남은 5개

요즘 개발자들, VS Code 하나 없이 어떻게 일하는지 솔직히 모르겠어요. 저도 2년 넘게 매일 쓰고 있거든요. 근데 확장 프로그램 막 깔면 되냐? 그건 절대 아니에요. 안 쓰는 거 30개 깔려있으면 시작도 느려지고, 메모리도 다 잡아먹어요. 진짜 써본 것만 콕콕 골라봤습니다.

VS Code 생산성 확장 추천이란?

사실 "생산성 확장"이라는 말 자체가 좀 모호하긴 해요. MDN 웹 문서에 따르면 에디터 환경 자체를 개선하는 도구들을 통칭하기도 하고, 어떤 사람은 자동완성 도구, 어떤 사람은 테마까지 포함시키거든요. 일단 저는 "코드 작성과 디버깅을 직접적으로 빠르게 만들어주는 도구"로 좁혀서 정의해요. 너무 넓으면 끝이 없어요.

VS Code 공식 릴리스 노트를 확인하면 2025년 기준 1.85 버전부터는 워크스페이스 트러스트 기능이 강화됐고, 확장 API 자체도 꽤 많이 바뀌었어요. 거기에 맞춰서 확장을 다시 한 번 골라보는 게 좋겠죠. 옛날 글 그대로 따라 했다가 호환 안 맞아서 낭패 볼 수 있어요.

진짜 핵심 확장 5가지

1. Prettier - 코드 정렬은 이제 기계한테

저는 처음에 코드 스타일 맞추는 거 손으로 다 했어요. 멍청했죠. Prettier 깔고 2시간 만에 확 바뀌었어요. 진짜 그랬어요. 따옴표, 들여쓰기, 세미콜론, 이게 자동으로 통일되니까 협업할 때 코드 리뷰 시간이 확 줄더라고요.

근데 주의. Prettier는 기본값이 좀 공격적이에요. 설정에서 printWidth를 80 → 120으로 바꾸는 걸 추천해요. 안 그러면 한 줄에 다 짤려서 오히려 읽기 힘들어요. 개인차가 있긴 한데, 최소 100 이상은 두는 게 현대적인 코드 스타일에 맞아요.

공식 문서를 확인하면 Prettier 3.x 버전부터는 ESM 모듈이 기본이고, Node 14 이하는 지원 종료됐어요. 이거 모르고 쓰면 빌드 에러 납니다. 처음에 저도 이거 때문에 한참 해맸어요.

2. ESLint - 버그 잡는 확장, 선택 아닌 필수

이건 선택이 아니라 필수입니다. 진짜로요.

저도 한 번은 ESLint 없이 React 컴포넌트 300개 짜다가 props 타입 안 맞아서 런타임 에러 났어요. 그때 2시간 잡고 결국 ESLint로 해결. 그 이후로 안 깐 적이 없어요. 야근 줄이는 가장 확실한 방법이에요, 이거.

GitHub 이슈 트래커에 따르면 ESLint 9.0부터 flat config가 기본이 됐어요. 기존 .eslintrc 쓰고 있으면 에러가 막 뜹니다. Stack Overflow에도 이거 관련 질문이 1000개 넘게 올라와 있고, 답변도 정리가 잘 되어 있어요. 처음에 막히면 거기서 찾는 게 빠릅니다.

3. GitLens - Git을 에디터 안에서

Git 명령어 매번 치기 귀찮죠? 저도 그랬고요. GitLens 깔면 라인마다 누가 언제 수정했는지 바로 보여요. 누가 짠 코드인지 3초 만에 파악 가능해요.

근데 큰 저장소에서는 좀 무거워요. 제일 가볍게 쓰려면 gitCodeLens.enabled를 false로 두고, blame만 켜는 게 좋더라고요. 이거 한 줄 바꾸니까 체감이 확 달라졌어요.

4. Project Manager - 프로젝트 점프용

작은 회사 다니다 보면 프로젝트가 한둘이 아니잖아요. Project Manager는 그 폴더들 한 번에 등록해두고 Ctrl+Alt+P로 바로 점프해요. 별거 아닌데 진짜 편해요. 사바사인 줄 알았는데 막상 써보니까 하루에 20번은 누르게 되더라고요.

참고로, 이 확장은 오픈소스라서 GitHub에 이슈 직접 올릴 수 있어요. 1.5 버전 이후로 멀티루트 워크스페이스도 지원합니다. 모노레포 쓰는 분들한테 특히 유용해요.

5. Error Lens - 에러를 눈앞에 띄워주는 잔인한 친구

보통 에러는 Problems 탭에 숨어있잖아요. Error Lens는 코드 옆에 빨갛게 박아줘요. 살짝 짜증나지만, 그래서 좋습니다. 안 보일 수가 없으니까요.

TypeScript 쓸 때는 진짜 도움돼요. 타입 에러가 바로 보여서 후다닥 고치거든요. 처음엔 정신없어 보일 수 있는데, 하루 이틀 쓰면 절대 못 버려요.

실수하기 쉬운 VS Code 생산성 확장 추천 주의사항

확장 많이 깔지 마세요. 이게 제일 큰 함정이에요.

VS Code 공식 문서에 따르면 확장 50개 넘어가면 시작 시간이 눈에 띄게 느려진다고 해요. 실제로 재봤어요. 진짜로요. 측정 도구로 확인까지 해봤어요.

그리고 자동 업데이트는 일단 꺼두세요. 2024년 한 번은 확장이 자체적으로 망가져서 설정 다 날아갈 뻔한 적 있어요. 그때 30분 날렸습니다. 업데이트는 한 달에 한 번 정도 수동으로 하는 게 안전해요. 급할 거 없어요, 진짜.

또 하나, 확장 키바인딩 충돌 조심하세요. Ctrl+Shift+P 같은 건 아무나 차지하면 안 됩니다. Keyboard Shortcuts에서 충돌 체크 꼭 해보세요. 이거 안 보면 나중에 "어? 왜 안 되지?" 하면서 시간만 날려요.

간단합니다. 진짜 그게 다예요.

오늘부터 실천하는 VS Code 생산성 확장 추천 정리

뭐 대단한 거 없어요. Prettier, ESLint, GitLens, Project Manager, Error Lens. 이 다섯 개면 충분합니다.

돌이켜보면, 저는 처음에 확장 70개 깔려있었어요. 지우고 나서 시작 시간 3초 → 0.8초로 줄었어요. 그게 1일 수십 번, 1년이면 몇 시간이에요. 시간은 돈이에요. 진짜로요.

오늘 하나만 지워보세요. 진짜 안 쓰는 거. 어차피 안 쓸 거잖아요, 솔직히. 그리고 Prettier랑 ESLint만이라도 설치해 보세요. 내일 아침 출근길에 "아, 이거 왜 이제 알았지" 하실 겁니다.

여러분의 VS Code가 조금 더 가볍고, 조금 더 똑똑해지길 바랍니다. 즐거운 코딩 하세요!

#VSCode #생산성확장 #VSCode확장 #개발자도구 #코딩팁