처음 선택이 비효율적이었던 이유와 설정을 바꾸며 작업 흐름이 달라진 과정

시작할 때는 가벼운 편집기면 충분하다고 봤다

처음 Visual Studio Code를 다시 검토한 이유는 거창하지 않았습니다. 프로젝트 규모가 커진 상황이 아니라, 작은 수정 작업과 로그 확인, 스크립트 편집이 반복되는데 기존 도구들이 오히려 느려졌기 때문입니다. 실행은 빨랐지만 언어별 설정이 제각각이어서, 파일을 열 때마다 포맷터와 인코딩, 터미널 동작을 따로 맞춰야 했습니다.

처음에는 “가벼운 에디터 하나면 된다”는 기준으로 접근했습니다. 그래서 VSCode를 선택한 이유도 단순했습니다. 무료로 쓰기에는 괜찮다라는 평가가 많았고, 운영체제가 달라도 동일한 환경을 만들기 쉽다는 점이 실무용으로 보였기 때문입니다. 특히 코드 수정, Git 확인, 간단한 실행 테스트를 한 화면에서 처리할 수 있다는 점이 눈에 들어왔습니다.

하지만 실제 사용 직후 예상과 달랐던 부분이 있었습니다. 기본 상태가 곧바로 효율적인 것은 아니었습니다. 설치만 하면 바로 생산성이 나올 줄 알았는데, 오히려 확장 프로그램 추천이 많고 설정 선택지가 넓어서 초반에는 판단 비용이 컸습니다. 가볍다는 장점이 자동으로 작업 속도로 이어지지는 않는다는 점을 여기서 처음 확인했습니다.

첫 번째 실패: 확장을 많이 넣을수록 편해질 거라는 오판

가장 먼저 한 실수는 확장을 너무 많이 설치한 것입니다. 언어 지원, 테마, Git 보조, AI 추천, 테스트 보조, 마크다운 미리보기, CSV 보기까지 한 번에 넣었습니다. 당시 판단은 단순했습니다. 필요한 기능을 미리 다 넣으면 나중에 덜 번거로울 것이라고 본 것입니다.

결과는 반대였습니다. 실행 속도와 파일 인덱싱이 생각보다 느려졌고, 자동 완성 후보가 과하게 늘어나면서 타이핑 흐름이 자주 끊겼습니다. 특히 같은 기능을 수행하는 포맷터가 두 개 이상 겹치면서 저장할 때마다 결과가 달라졌습니다. 기능이 많은 것이 아니라, 책임이 겹치는 구성이 문제였습니다.

이 실패가 의미 있었던 이유는 원인을 비교적 명확하게 추정할 수 있었기 때문입니다. 편집기 자체가 느리다기보다, 확장 간 충돌과 백그라운드 감시 범위가 과도했던 겁니다. 그래서 두 번째 시도에서는 “무조건 추가”가 아니라 “작업에 직접 기여하는가”를 기준으로 재정리했습니다. 언어 서버, 포맷터, Git 관련 핵심 확장만 남기고 나머지는 프로젝트 단위로 필요할 때만 켰습니다.

실무 팁으로 정리하면 첫째, 포맷터는 언어별로 하나만 기본값으로 고정하는 편이 낫습니다. 둘째, 검색 제외 폴더와 파일 감시 제외 범위를 초기에 잡아두면 대형 프로젝트에서 체감 차이가 큽니다. 설정에 따라 체감이 달라진다라는 말이 이 부분에서는 꽤 직접적으로 맞았습니다.

두 번째 실패: IDE처럼 쓰려다가 오히려 반복 작업이 늘었다

두 번째로 막힌 부분은 작업 방식을 잘못 가져온 경우였습니다. 기존에는 무거운 IDE에서 프로젝트 전체를 열고 모든 기능을 한 번에 쓰는 방식에 익숙했습니다. 그래서 VSCode에서도 같은 방식으로 대형 저장소 전체를 항상 열고, 테스트와 빌드, 로그 확인까지 모두 한 창에서 해결하려고 했습니다.

문제는 이 방식이 VSCode의 장점을 살리지 못했다는 점입니다. 필요한 수정은 한두 디렉터리 안에서 끝나는데도 전체 워크스페이스를 열어 검색 범위와 확장 동작 범위를 불필요하게 키웠습니다. 그 결과 전역 검색은 편했지만, 시작 시간과 인덱싱 비용이 계속 발생했습니다. 반복 작업이 줄어들지 않는 원인이 도구 자체가 아니라 제 사용 방식에 있었다는 뜻입니다.

여기서 판단 기준이 바뀐 순간이 있었습니다. 작은 핫픽스 작업에서 폴더 하나만 따로 열어 작업해보니, 검색 속도와 터미널 반응이 훨씬 안정적이었습니다. 그때부터 “모든 걸 한 번에 관리”가 아니라 “작업 단위를 분리해서 여는 방식”이 더 효율적이라는 쪽으로 기준이 이동했습니다.

이후에는 저장소 전체가 필요한 날과 파일 몇 개만 고치는 날을 나눠서 환경을 다르게 썼습니다. 전자는 멀티 루트 워크스페이스와 디버깅 설정을 활용하고, 후자는 단일 폴더 + 내장 터미널 + Git 패널만 사용했습니다. 비슷한 방법과 비교하면, 무거운 IDE가 유리한 구간은 분명 있지만 일상적인 수정 작업에서는 이렇게 분리하는 편이 더 빨랐습니다.

다시 시도하게 된 계기와 실제로 바꾼 설정

사실 한 번 비효율을 겪은 뒤에는 다른 에디터로 넘어갈까도 고민했습니다. 그런데 다시 시도하게 된 계기는 원격 서버 설정 파일과 배치 스크립트를 동시에 다뤄야 했던 작업이었습니다. 운영체제가 다른 환경을 왔다 갔다 해야 했고, 동일한 단축키와 설정을 유지하는 쪽이 비용이 적었습니다. 그 지점에서 VSCode의 멀티 플랫폼 장점이 실무적으로 다시 보였습니다.

다시 구성할 때는 세 가지 원칙만 뒀습니다. 첫째, 기본 기능으로 가능한 것은 확장으로 대체하지 않는다. 둘째, 저장 시 자동 동작은 최소화하고 결과가 예측 가능한 것만 남긴다. 셋째, 프로젝트별 설정과 사용자 전역 설정을 분리한다. 이 세 가지를 적용하니 초기 혼란이 크게 줄었습니다.

구체적으로는 저장 시 포맷팅과 import 정리는 언어별로 다르게 설정했습니다. Python은 포맷팅 우선, JavaScript는 포맷팅 + 린트 수정 일부만 허용하는 식으로 나눴습니다. 터미널은 기본 셸을 프로젝트 성격에 따라 바꾸고, 파일 자동 저장은 짧은 지연이 아니라 수동 저장 위주로 유지했습니다. 자동 저장이 많을수록 편할 것 같았지만, 빌드나 테스트가 저장 이벤트에 묶여 있을 때는 오히려 비효율이 커졌기 때문입니다.

여기서 얻은 또 하나의 팁은 설정 동기화를 바로 전부 믿지 않는 것입니다. 계정 동기화는 편리하지만, 과거 실험용 확장과 설정까지 같이 들어오면 오히려 초기 품질이 떨어집니다. 새 환경에서는 최소 설정으로 시작한 뒤 필요한 것만 다시 올리는 편이 안정적이었습니다.

실제로 개선된 점과 끝까지 애매하게 남은 점

명확하게 개선된 문제는 반복적인 파일 탐색과 간단 수정 작업의 전환 속도였습니다. 예전에는 탐색기, 터미널, Git 상태 확인을 각각 다른 도구에서 열어야 했는데, VSCode에서는 이 세 가지가 한 창에서 이어졌습니다. 특히 빠른 검색과 심볼 이동, 변경 파일 비교가 합쳐지면서 작은 수정 업무는 확실히 빨라졌습니다.

반대로 끝까지 완전히 해결되지 않은 문제도 있습니다. 대형 저장소에서 확장 두세 개만 써도 메모리 사용량과 인덱싱 부하가 완전히 사라지지는 않았습니다. 원격 개발이나 컨테이너 환경까지 붙으면 편의성은 높아지지만, 로컬에서 가볍게 쓴다는 처음의 기대와는 거리가 생깁니다. 즉, 가벼움은 항상 절대적인 장점이 아니라 작업 구조에 따라 달라집니다.

이 부분은 다른 방법과 비교했을 때 더 분명합니다. 단순 텍스트 편집 중심이라면 더 가벼운 에디터가 반응성에서 유리할 수 있습니다. 반대로 복잡한 리팩터링, 대규모 솔루션 관리, 깊은 디버깅이 핵심이면 정식 IDE가 더 나은 상황도 많습니다. VSCode는 그 중간 영역, 즉 편집기 속도와 개발 도구 통합의 균형이 필요한 구간에서 가장 효율이 났습니다.

어떤 상황에서 적절하고, 어떤 사용자에게 맞는가

이 도구가 적절한 상황은 비교적 분명합니다. 여러 언어를 조금씩 다루거나, 서버 스크립트 수정과 프런트엔드 작업, 설정 파일 편집을 한 환경에서 처리해야 할 때 강점이 있습니다. 특히 팀마다 개발 환경이 다르고, Windows와 Mac, Linux를 오가야 한다면 동일한 작업 흐름을 복제하기 쉽습니다.

덜 불편하게 쓰는 방식도 명확합니다. 첫째, 확장은 역할별로 최소화합니다. 둘째, 대형 저장소는 전체를 항상 열지 말고 작업 범위를 분리합니다. 셋째, 자동화는 저장 시 일괄 실행보다 명시적 실행 위주로 시작합니다. 실제로 효율이 나오는 사용 방식은 “필요한 기능만 선택해 붙이는 편집기”로 이해할 때였습니다.

적합한 사용자는 두 부류입니다. 하나는 IDE가 과하다고 느끼지만 터미널, Git, 디버깅, 자동 완성 정도는 포기하기 어려운 사용자입니다. 다른 하나는 언어나 프로젝트가 자주 바뀌어 고정된 무거운 환경보다 조립식 구성이 필요한 사용자입니다. 반대로 비추천인 경우도 있습니다. 설정을 자주 만지기 싫고, 처음부터 완성된 워크플로가 필요한 사용자라면 초기 적응 비용이 스트레스로 느껴질 수 있습니다.

특히 실무에서 비추천인 상황은 표준화가 매우 강한 팀입니다. 예를 들어 특정 IDE 플러그인과 디버거에 업무 흐름이 깊게 묶여 있으면, VSCode로 옮기는 과정에서 생기는 자잘한 차이가 더 큰 손실이 될 수 있습니다. 무료로 쓰기에는 괜찮다라는 장점만 보고 바꾸기보다, 현재 팀의 빌드/디버그 체인과 맞는지 먼저 보는 것이 맞습니다.

비슷한 방법과 비교했을 때 선택 기준

비슷한 방법과 비교하면 선택 기준은 생각보다 단순했습니다. 단일 언어, 대형 프로젝트, 정교한 리팩터링이 핵심이면 전용 IDE 쪽이 더 낫습니다. 반대로 여러 파일 형식과 스크립트를 오가며 수정하고, Git 확인과 간단 실행 테스트가 잦다면 VSCode가 더 나은 상황이 많았습니다.

더 가벼운 편집기와의 비교에서는 확장성과 기본 기능 통합이 기준이 됩니다. 정말 빠른 실행만 중요하면 더 단순한 편집기가 유리합니다. 하지만 자동 완성, 디버깅, 내장 터미널, Git, 원격 작업까지 한 번에 이어야 한다면 VSCode가 균형이 좋습니다. 결국 선택 기준은 기능 수가 아니라, 한 작업을 끝내기 위해 창을 몇 번 옮겨야 하는가에 가깝습니다.

제 경우에는 조건부 추천에 가깝습니다. 설정을 거의 하지 않고도 완성형 환경을 원하면 최선은 아닐 수 있습니다. 하지만 작업 유형이 자주 바뀌고, 직접 기준을 세워 도구를 다듬을 수 있다면 충분히 실무 적용 가능성이 있습니다. 다만 설정에 따라 체감이 달라진다라는 점은 장점이면서 동시에 진입 장벽이기도 합니다.

정보 요약 구간

핵심 장점은 분명합니다. 가벼운 편집기 수준의 진입성에 Git, 터미널, 디버깅, 자동 완성을 묶어 둘 수 있어서 작은 수정 작업의 전환 비용을 줄이기 좋습니다. 여러 운영체제에서 비슷한 환경을 만들 수 있어 개인 작업뿐 아니라 팀 내 표준화 후보로도 검토할 만합니다. 비슷한 방법과 비교하면, 여러 언어와 파일 형식을 함께 다루는 실무에서는 특히 강점이 뚜렷했습니다.

아쉬운 점도 명확합니다. 기본 설치 상태가 곧 최적 상태는 아니고, 확장과 자동화 설정을 잘못 잡으면 오히려 느려지거나 결과가 불안정해질 수 있습니다. 대형 저장소에서는 메모리 사용량과 인덱싱 부담이 남아 있어, “항상 가볍다”고 보기는 어렵습니다. 무료로 쓰기에는 괜찮다라는 표현은 맞지만, 관리 비용이 0이라는 뜻은 아닙니다.

계속 사용할지에 대한 판단은 조건부로 긍정적입니다. 작업 단위를 나눠 열고, 확장을 최소화하며, 언어별 포맷팅 규칙을 명확히 두는 방식이라면 효율이 확실히 납니다. 반대로 팀이 특정 IDE 중심으로 굳어 있거나, 복잡한 디버깅과 대규모 리팩터링이 주업무라면 우선순위가 내려갑니다. 추천은 가능하지만, 사용자와 프로젝트 구조에 따라 만족도가 크게 갈릴 수 있다는 점은 끝까지 남습니다.

정리하면 이 도구의 가치는 “무엇이든 된다”보다 “필요한 만큼만 조립할 수 있다”에 있습니다. 그 점이 맞는 사용자에게는 실무에서 충분히 쓸 만하고, 그렇지 않으면 초기 기대보다 애매할 수 있습니다. 그래서 제 결론은 전면 추천이 아니라, 작업 범위와 설정 관리 성향이 맞는 경우에 한한 조건부 추천입니다.