처음 VSCode를 쓴 건 거창한 이유가 있어서가 아니라, 그냥 기존에 쓰던 개발 환경이 점점 무거워져서였습니다. 프로젝트 하나 열 때마다 팬이 먼저 돌고, 뭘 하나 바꾸려면 기다리는 시간이 애매하게 길어지는 게 계속 쌓이더라고요. 그래서 한동안은 “일단 가벼운 걸로 옮겨보자”는 생각이 더 컸습니다.
그때 VSCode가 제일 많이 보였고, 다들 가볍다고 하길래 별 생각 없이 설치했습니다. 사실 처음엔 코드 편집기라는 말 그대로, 메모장보다 조금 더 좋은 수준일 줄 알았습니다. 그런데 막상 써보니까 애매하게 비어 있는 느낌이 있었습니다. 가볍긴 한데, 제가 하던 작업을 그대로 옮기려면 결국 이것저것 만져야 하더라고요.
그래서 이 글도 “VSCode 좋다” 같은 식으로 끝나는 얘기는 아니고, 실제로 옮겨가면서 어디서 막혔는지, 왜 계속 설정을 바꾸게 됐는지, 지금은 어떤 식으로 타협해서 쓰고 있는지 적어보려 합니다.
처음엔 그냥 에디터처럼 썼는데 생각보다 허전했다
설치하고 처음 열었을 때 느낌은 꽤 좋았습니다. 실행이 빨랐고, 화면도 깔끔했고, 프로젝트 폴더 열어서 파일 왔다 갔다 하는 것도 부담이 없었습니다. 예전엔 IDE를 켜는 것 자체가 작업 시작 버튼 같은 느낌이었다면, VSCode는 그냥 파일 열듯이 들어갈 수 있어서 진입이 편했습니다.
그런데 딱 하루 이틀 지나니까 허전한 부분이 보이기 시작했습니다. 자동 완성은 되긴 되는데 제가 기대하던 정도는 아니었고, 디버깅도 생각보다 바로 되는 게 아니었습니다. 특히 언어마다 느낌이 조금씩 달라서, “가볍다”는 장점이 반대로 “기본 상태는 좀 비어 있다”로 느껴질 때가 있었습니다.
이때 처음 한 착각이, VSCode를 설치하면 대부분 기본으로 다 되는 줄 알았던 겁니다. 실제로는 확장 프로그램 구성이 거의 절반 이상이더라고요. 이걸 빨리 받아들이면 편한데, 저는 초반에 그걸 몰라서 왜 어떤 프로젝트는 멀쩡하고 어떤 건 이상하게 불편한지 한참 헤맸습니다.
짧게 팁을 말하면, 처음부터 욕심내서 확장을 많이 깔기보다 자주 쓰는 언어 하나 기준으로만 맞추는 게 낫습니다. 저는 초반에 웹, 파이썬, 도커, 마크다운, 원격 개발까지 한 번에 깔았다가 오히려 뭐가 문제인지 구분이 안 됐습니다.
자동 완성만 믿고 들어갔다가 여기서 한 번 막혔다
첫 번째로 제대로 막힌 건 Python 작업할 때였습니다. 분명히 다들 VSCode 자동 완성 좋다고 했는데, 제가 열어보니 import 경로나 타입 힌트가 애매하게 안 잡히는 경우가 있었습니다. 처음엔 프로젝트 문제인 줄 알았는데, 알고 보니 인터프리터 선택이 꼬여 있었습니다.
이게 별거 아닌 것 같아도 한 번 꼬이면 꽤 귀찮습니다. 터미널에서 실행은 되는데 에디터 안에서는 경고가 뜨고, 린터는 다른 말을 하고, 자동 완성은 또 반쯤만 되는 식이었습니다. 저는 여기서 한참 돌아갔습니다. 확장을 지웠다 깔았다도 해보고, 설정 파일도 만져봤는데 방향이 틀렸던 거죠.
결국 해결된 건 의외로 단순했습니다. 현재 프로젝트가 어떤 가상환경을 쓰는지 먼저 정리하고, VSCode에서 Python 인터프리터를 그 환경으로 명확하게 다시 지정하니까 바로 정리됐습니다. 그 전까지는 “에디터가 왜 이러지”라고 생각했는데, 사실은 실행 환경이 두 개 이상 섞여 있었던 겁니다.
이때 알게 된 게 하나 있는데, VSCode에서 이상하게 자동 완성이나 진단이 어긋나면 에디터 자체보다도 실행 환경, 워크스페이스 루트, 확장끼리의 역할 겹침을 먼저 보는 게 빠릅니다. 특히 Python은 인터프리터, Node 쪽은 workspace와 tsconfig 쪽이 은근히 영향을 많이 줍니다.
비슷한 상황에서 PyCharm 같은 IDE는 이런 걸 비교적 덜 헷갈리게 잡아주는 편이었습니다. 대신 가볍게 파일 몇 개만 수정할 때는 VSCode 쪽이 훨씬 부담이 적었습니다. 그래서 지금도 Python 프로젝트를 깊게 볼 땐 IDE가 편하다고 느끼고, 일상적인 수정이나 스크립트 작업은 VSCode로 갑니다.
확장 프로그램은 많을수록 좋을 줄 알았는데 아니었다
두 번째 시행착오는 확장 프로그램 욕심이었습니다. 처음엔 VSCode의 장점이 필요한 기능만 골라 넣는 거라길래, 그 말을 너무 곧이곧대로 받아들였습니다. 추천 목록 보이는 대로 깔고, 블로그에서 좋다던 것도 넣고, 테마도 여러 개 바꾸고, Git 관련 확장도 두세 개 겹쳐서 써봤습니다.
초반엔 되게 뿌듯했습니다. 뭔가 제 작업 환경이 점점 완성되는 느낌이었거든요. 그런데 며칠 지나니까 이상한 증상이 나오기 시작했습니다. 저장할 때 포맷이 두 번씩 먹는 것 같고, 어떤 파일은 import 정리가 되고 어떤 파일은 안 되고, 같은 언어인데 프로젝트마다 동작이 미묘하게 달랐습니다.
여기서 한 번 더 잘못 생각한 게, 설정이 세밀해질수록 생산성도 같이 올라간다고 본 거였습니다. 실제로는 확장이 많아질수록 충돌 가능성도 같이 올라갑니다. Prettier랑 언어별 포매터 설정이 겹치고, 린터가 두 군데서 경고를 뿌리고, Git 장식이 많아지니까 오히려 화면이 산만해졌습니다.
결국 저는 한 번 크게 정리했습니다. 포매터는 하나만 남기고, Git 관련 확장도 꼭 필요한 것만 두고, 보기 좋은데 실제로 안 쓰는 확장은 과감히 뺐습니다. 이 과정을 거치고 나서야 VSCode가 다시 가볍게 느껴졌습니다. 웃긴 건, 기능을 더하는 과정이 아니라 덜어내는 과정에서 편해졌다는 점이었습니다.
실무에서는 이게 꽤 중요합니다. 본인 말고 다른 사람도 같이 보는 저장소라면, 포맷 방식이나 추천 확장 정도는 workspace 기준으로 어느 정도 맞춰두는 게 좋습니다. 안 그러면 사람마다 저장할 때 결과가 달라져서 쓸데없이 diff가 커집니다.
Git은 편했는데, 편한 만큼 실수도 빨라졌다
VSCode를 계속 쓰게 된 이유 중 하나는 Git 화면이 생각보다 편했기 때문입니다. 파일별 변경 사항 보기, 바로 stage 하기, 간단한 commit까지 이어지는 흐름이 매끄러웠습니다. CLI를 완전히 대체하진 않더라도, 자잘한 수정 확인은 훨씬 빨랐습니다.
그런데 여기서도 한 번 실수했습니다. 예전엔 터미널에서 git status부터 보고 천천히 확인했는데, VSCode에선 바뀐 파일이 눈앞에 바로 보이니까 대충 훑고 넘기는 습관이 생기더라고요. 그러다가 테스트용 로그 파일 하나를 같이 올릴 뻔했습니다. 다행히 commit 전에 보고 뺐지만, UI가 편하다고 검토까지 꼼꼼해지는 건 아니었습니다.
이후로는 오히려 기준을 하나 만들었습니다. 파일 수가 적으면 VSCode에서 확인하고, 변경 범위가 크거나 리팩터링처럼 영향이 넓은 건 터미널 명령이나 별도 diff 도구까지 같이 봅니다. 특히 rename이나 대량 수정은 GUI만 믿고 가면 놓치는 게 있습니다.
비교하자면 SourceTree 같은 전용 Git 툴은 히스토리 흐름을 볼 때는 편한데, 코드 수정과 함께 오가려면 창이 분리되는 게 저는 조금 번거로웠습니다. VSCode는 수정-확인-커밋이 한 화면에서 이어지는 게 장점이지만, 그만큼 너무 빨리 처리해버리는 단점도 같이 있었습니다.
원격 개발은 신세계 같았는데, 네트워크 타니까 바로 현실적이 됐다
조금 지나고 나서는 Remote SSH 쪽도 써봤습니다. 서버에 있는 코드를 로컬처럼 열어서 보는 경험은 처음엔 꽤 인상적이었습니다. 예전에는 ssh 접속해서 vim으로 급하게 고치거나, 파일 내려받았다가 다시 올리는 식으로 했는데, VSCode로 붙으니까 훨씬 덜 귀찮았습니다.
문제는 여기서 또 다른 종류의 막힘이 나왔다는 겁니다. 기능 자체는 좋은데, 네트워크 상태나 서버 권한 문제를 만나면 체감이 확 달라집니다. 어느 날은 확장 서버 설치가 중간에 꼬였고, 어느 날은 파일 감시가 느려서 저장 반영이 굼뜨게 느껴졌습니다. “이거면 서버 작업도 다 끝났다” 싶다가도, 연결 상태 안 좋으면 다시 전통적인 방법이 더 안정적으로 느껴졌습니다.
한 번은 로그만 잠깐 보고 수정하려고 원격으로 붙었는데, 접속 쪽에서 시간을 너무 써서 그냥 터미널로 처리한 적도 있었습니다. 그때 좀 생각이 바뀌었습니다. 원격 개발이 무조건 더 나은 게 아니라, 오래 붙어서 작업할 때는 편하고, 5분짜리 수정이면 오히려 과할 수도 있겠다는 식으로요.
그래서 지금은 기준을 나눕니다. 파일 여러 개를 오가며 구조를 봐야 하면 VSCode 원격이 좋고, 설정 파일 한두 줄 바꾸는 정도면 그냥 SSH가 빠릅니다. 이런 건 결국 도구 문제가 아니라 작업 길이 문제 같았습니다.
디버깅은 분명 편한데, 결국 설정 파일을 이해해야 했다
VSCode에서 좋았던 것 중 하나는 디버깅 진입 장벽이 낮다는 점이었습니다. 브레이크포인트 찍고 바로 돌려보는 흐름 자체는 꽤 잘 되어 있습니다. 특히 프론트엔드나 Node 작업에서는 생각보다 금방 손에 익었습니다.
다만 여기서도 저는 한 번 돌아갔습니다. launch 설정을 대충 자동 생성해놓고, 왜 제가 원하는 방식으로 실행이 안 되는지 한참 봤습니다. 환경 변수 먹는 위치가 다르고, 작업 디렉터리가 예상과 다르고, attach랑 launch 차이도 정확히 모르고 건드렸으니 당연히 꼬일 수밖에 없었습니다.
이 구간은 좀 재밌었는데, 처음엔 설정 파일이 너무 귀찮아서 피하고 싶었습니다. 그런데 몇 번 삽질하고 나니까 오히려 launch.json을 조금 읽을 줄 아는 게 시간을 아끼더라고요. 무작정 버튼만 누르는 것보다, 어떤 프로세스를 어떻게 붙는지 감이 생기니까 문제를 줄이는 속도가 달라졌습니다.
이건 VSCode에만 해당하는 얘기는 아니지만, UI가 친절하다고 내부 동작을 몰라도 되는 건 아니었습니다. 특히 디버깅은 한 번만 제대로 잡아두면 반복 작업이 빨라져서, 처음 세팅할 때 조금 시간 쓰는 게 오히려 이득이었습니다.
결국 지금은 만능 도구가 아니라 기본 작업장처럼 쓴다
이쯤 오고 나서야 VSCode를 보는 시선이 조금 정리됐습니다. 처음엔 가벼운 대체재라고 생각했고, 중간엔 확장으로 다 해결할 수 있는 도구처럼 봤고, 지금은 그냥 “기본 작업장” 정도로 두고 씁니다. 웬만한 수정, 탐색, 리뷰, 간단한 디버깅은 여기서 하고, 프로젝트 성격에 따라 더 무거운 IDE나 전용 툴로 넘어갑니다.
Visual Studio랑 비교하면, 대형 .NET 프로젝트처럼 IDE의 관리 능력이 중요한 경우는 아직도 완전한 개발 환경 쪽이 편했습니다. 반대로 여러 언어를 조금씩 만지거나, 저장소를 여러 개 번갈아 열고, 문서랑 코드 작업을 같이 하는 흐름은 VSCode가 훨씬 덜 피곤했습니다.
또 하나 좋았던 건 커스터마이징 폭이 넓다는 점인데, 이것도 방향을 잘 잡아야 장점이 됩니다. 테마, 글꼴, 단축키, 설정 동기화 이런 것들이 은근히 체감에 영향을 줍니다. 다만 너무 꾸미기 시작하면 다시 딴 데로 새기 쉽습니다. 저도 한동안 폰트랑 아이콘 테마 바꾸는 데 시간을 쓴 적이 있는데, 지나고 보니 생산성에는 큰 차이가 없었습니다.
실무적으로는 몇 가지만 맞춰두면 만족도가 올라갔습니다. 자동 저장 여부, 포맷 온 세이브, 탭 크기, 기본 터미널, 파일 제외 규칙 정도요. 이런 건 거창하지 않은데 매일 만나는 부분이라 차이가 누적됩니다.
좋아진 점은 분명한데, 애매하게 남는 것도 있다
지금 기준으로 보면 VSCode는 확실히 손이 자주 갑니다. 실행이 빠르고, 여러 언어를 오가도 기본 리듬이 크게 안 바뀌고, Git이랑 터미널이 한 화면에 붙어 있어서 작업 흐름이 끊기지 않는 점은 꽤 큽니다. 예전보다 “작업 시작하는 데 드는 마음의 비용”이 줄어든 것도 사실입니다.
반대로 애매한 부분도 남아 있습니다. 확장 의존도가 높은 만큼, 프로젝트나 언어가 바뀌면 다시 미세 조정이 필요할 때가 있고, 어떤 건 오늘 잘 되다가 다음 업데이트 뒤에 느낌이 달라지기도 합니다. 이게 꼭 큰 문제는 아닌데, 안정적으로 다 맞춰진 IDE 느낌을 기대하면 조금 피곤할 수 있습니다.
그래서 저는 VSCode를 아주 완성된 답이라고 보진 않습니다. 다만 손에 맞게 조금씩 다듬으면 꽤 오래 쓰게 되는 도구인 건 맞는 것 같습니다. 처음엔 가볍다는 이유로 시작했는데, 지금은 오히려 너무 많은 걸 얹지 않는 쪽으로 쓰는 게 더 낫다고 생각하게 됐습니다.
아직도 원격 작업 쪽은 상황 따라 다른 선택을 하게 되고, 언어별 확장 조합도 완전히 끝났다는 느낌은 없습니다. 아마 다른 방법으로 더 편하게 쓰는 사람도 분명 있을 것 같습니다. 저도 지금 방식이 정답이라고는 못 하겠고, 비슷하게 써본 사람들 중에 더 덜 번거로운 조합이 있으면 좀 궁금하긴 합니다.