편집기를 고르는 것과 개발 환경을 만드는 것은 이제 다른 일이다. 편집기는 30초면 깔지만, 그 위에 어떤 확장(extension)을 어떤 순서로 얹느냐가 실제 생산성을 가른다. 마이크로소프트의 비주얼 스튜디오 코드(Visual Studio Code, 이하 VS Code)가 스택오버플로 개발자 설문에서 수년째 사용률 1위를 지키는 이유도 편집기 본체의 기능보다 그 위에 쌓인 확장 생태계에 있다. 최근 임베디드 툴 업체 IAR가 VS Code용 디버그 확장을 갱신하고, 마이크로소프트가 C++ 확장을 편집기와 분리해 별도로 관리하며, 앱 자동화 도구 Appium(에이피움) 세팅 사례가 함께 회자되는 흐름에는 하나의 공통점이 있다. ‘편집기+확장’이 개발 워크플로의 중심축이 됐고, 세팅의 난이도가 편집기 밖의 의존 요소로 옮겨갔다는 점이다. 이 글은 이 세 갈래를 하나의 판단 기준으로 묶는다.
VS Code가 ‘조립형 플랫폼’이 된 배경
VS Code는 2015년 공개 당시 가벼운 텍스트 편집기에 가까웠다. 무료이고 윈도우·맥·리눅스를 모두 지원하며, 설치 용량이 수백 MB로 풀사양 통합개발환경(IDE)의 수 GB 대비 확연히 가볍다는 점이 초기 확산을 이끌었다. 그러나 판을 바꾼 것은 용량이 아니라 두 개의 개방형 규격이었다. 언어 서버 프로토콜(LSP, Language Server Protocol)과 디버그 어댑터 프로토콜(DAP, Debug Adapter Protocol)이다. 이 규격 덕분에 언어·하드웨어 업체는 편집기 본체를 건드리지 않고 확장 하나만 만들면 자동완성과 디버깅을 붙일 수 있게 됐다. 편집기 회사가 모든 언어를 직접 지원하던 구조에서, 각 언어·하드웨어 주인이 자기 몫을 붙이는 구조로 책임이 분산된 것이다.
여기서 실무자가 오해하기 쉬운 지점이 갈린다. VS Code는 ‘완성된 도구’가 아니라 ‘조립 대상’이다. 설치 직후에는 C++ 자동완성도, 브레이크포인트 디버깅도 동작하지 않는다. ‘깔았는데 왜 IDE처럼 안 되냐’는 초보자의 첫 좌절이 바로 여기서 나온다. 반대 방향의 함정도 있다. 확장을 20~30개씩 무분별하게 설치하면 편집기 시작 시간이 눈에 띄게 늘고, 같은 역할의 확장이 겹쳐 자동완성이 이중으로 뜨거나 CPU 점유율이 치솟는다. 실무에서 검증된 시작 구성은 ‘핵심 4~5개’다. 언어 확장 1개, 디버거 1개, 포매터 1개, 린터 1개. 필요가 생길 때만 하나씩 더한다. 확장을 늘리기는 쉬워도 어느 것이 충돌의 원인인지 되짚기는 어렵다는 점을 기억하면, 처음부터 적게 시작하는 편이 유지보수 비용을 훨씬 줄인다.
디버그 확장: 편집기와 하드웨어를 잇는 다리
디버깅은 확장 생태계에서 전문성 편차가 가장 큰 영역이다. 웹 개발이라면 브라우저 연동 디버거로 충분하지만, 임베디드나 마이크로컨트롤러(MCU) 개발에서는 실제 칩과 편집기를 잇는 전용 디버그 확장이 반드시 필요하다. IAR 같은 임베디드 툴체인 업체가 VS Code용 디버그 확장을 꾸준히 갱신하는 배경이 여기 있다. 과거에는 자사 전용 IDE를 함께 쓰도록 강제하던 업체들이, 이제는 ‘개발자가 이미 쓰는 편집기 위에 우리 컴파일러·디버거 엔진을 얹는’ 전략으로 방향을 틀었다. 편집기 선택권은 개발자에게 넘기고, 엔진 경쟁력으로 승부하겠다는 계산이다.
디버그 확장을 고를 때 확인할 체크포인트는 세 가지로 압축된다. 첫째, launch.json 지원이다. VS Code 디버깅은 이 JSON 설정 파일로 실행 대상·포트·심볼 경로·아키텍처를 지정하는데, 확장이 예시 템플릿을 제공하지 않으면 필드 이름 하나 몰라 초기 설정에서 반나절을 흘려보내기 쉽다. 설치 후 ‘디버그 구성 자동 생성’이 뜨는지부터 확인하라. 둘째, 버전 호환성이다. VS Code는 대략 한 달 주기로 마이너 업데이트를 낸다. 확장이 특정 버전의 확장 API에 묶여 있으면 편집기 자동 업데이트 직후 디버거만 먹통이 되는 사고가 실제로 흔하다. 마켓플레이스의 ‘지원 VS Code 버전’ 표기를 확인하고, 팀 단위라면 편집기 버전을 고정(예: 특정 릴리스로 pin)하거나 사내 확장 저장소로 배포 시점을 통제하는 편이 안전하다. 셋째, 라이선스 구조 분리다. 상용 툴체인 연동 확장은 확장 자체는 무료여도 뒤에 붙는 컴파일러·디버거 엔진이 연 단위 유료 라이선스인 경우가 많다. ‘확장 무료 = 무료 개발환경’으로 오해하지 말고, 도입 전에 확장 비용과 엔진 비용을 반드시 갈라서 계산해야 한다.
언어 확장의 함정: C++ 확장이 드러내는 역할 분리
마이크로소프트가 자사 편집기의 C++ 지원을 본체에 넣지 않고 별도 확장으로 공개·관리한다는 사실 자체가 이 생태계의 설계 원칙을 보여준다. 언어 지원은 편집기가 아니라 확장 단위로 분리돼 있다. C++ 확장은 자동완성(IntelliSense), 코드 탐색(정의로 이동·참조 찾기), 디버깅 연동을 담당하지만, 정작 코드를 기계어로 바꾸는 컴파일러(GCC, Clang, MSVC 등)는 확장에 들어 있지 않다. ‘C++ 확장을 깔았는데 빌드가 안 된다’며 막히는 지점이 정확히 이 경계다. 확장은 ‘편집 경험’을, 툴체인은 ‘실제 빌드’를 맡는다. 이 둘을 한 덩어리로 착각하면 오류 메시지를 아무리 읽어도 원인을 못 찾는다.
언어 확장을 고르는 순서는 ‘공식 여부 → 유지보수 활성도 → 중복 방지’다. 같은 언어라도 개인이 만든 확장과 벤더 공식 확장이 공존하는데, 공식 확장은 편집기 릴리스 주기에 맞춰 갱신될 가능성이 높다. 마켓플레이스에서 최근 업데이트 날짜, 누적 다운로드 수, 이슈 트래커의 응답 속도를 한 화면에서 확인하는 습관이 필요하다. 경험칙으로 마지막 업데이트가 6개월 이상 멈춘 확장은 편집기 버전이 올라갈 때 깨질 위험을 안고 있다고 보는 편이 안전하다. 마지막 함정은 자동완성 엔진 중복이다. 같은 언어의 자동완성 확장을 둘 이상 켜 두면 IntelliSense 팝업이 이중으로 뜨거나 서로 인덱싱을 반복하며 CPU가 100%에 붙는다. 원칙은 단순하다. 한 언어당 자동완성을 책임지는 확장은 하나만 활성화한다. 굳이 대안을 시험하려면 워크스페이스 단위로 하나만 켜고 나머지는 비활성으로 두라.
편집을 넘어 자동화로: Appium 세팅이 보여주는 ‘의존성 사슬’
확장 생태계의 연장선에는 ‘편집기 밖의 자동화’가 있다. 모바일 앱 테스트 자동화 도구 Appium은 VS Code 확장이 아니지만, 개발 환경 세팅이라는 관점에서 똑같은 고민을 공유한다. 도구 하나를 설치한다고 끝이 아니라, 그 뒤의 의존 요소를 순서대로 맞춰야 한다는 점이다. 맥(macOS)에서 Appium을 세우려면 대체로 Node.js 런타임 → iOS라면 Xcode와 시뮬레이터, 안드로이드라면 JDK와 Android SDK → 기기와 통신할 드라이버가 차례로 갖춰져야 한다. 이 사슬에서 고리 하나만 버전이 어긋나도 세션이 아예 열리지 않는다. 확장을 늘릴 때 충돌을 걱정하듯, 자동화에서는 이 의존성 사슬의 정합성을 걱정해야 한다.
실무에서 Appium 세팅이 막히는 원인은 대부분 ‘버전 조합’이다. Appium 서버 버전, 드라이버 버전, 대상 OS 버전, 편집기에서 돌리는 언어 바인딩(Java·Python 등) 버전이 서로 맞물려 있어, 각각을 최신으로 깔면 오히려 호환이 깨지는 역설이 생긴다. 그래서 접근 순서를 뒤집어야 한다. 먼저 테스트할 앱과 기기 OS 버전을 고정하고, 그에 맞는 드라이버 버전을 역산한 뒤, 마지막에 그 드라이버와 호환되는 Appium 서버 버전을 맞춘다. ‘최신 좇기’가 아니라 ‘검증된 조합 고정’이 안정성의 핵심이다. 여기에 더해 자동화의 진짜 비용은 세팅이 아니라 유지보수라는 점을 놓치면 안 된다. 화면 UI가 조금만 바뀌어도 요소를 못 찾아 테스트가 깨지므로, 스크립트를 계속 고쳐야 한다. 따라서 자동화가 투자 대비 효과를 내는 구간은 ‘같은 시나리오를 반복 검증하는 회귀 테스트’에 한정된다. 한두 번 확인하고 말 화면을 자동화하는 것은 수동 테스트보다 오히려 손해다. 도입 전에 ‘이 테스트를 앞으로 몇 번 돌릴 것인가’를 먼저 계산하는 것이 첫 체크포인트다.
자주 묻는 질문
VS Code를 설치했는데 C++ 컴파일이 안 됩니다. 확장이 잘못된 건가요?
확장 문제가 아닐 가능성이 큽니다. C++ 확장은 자동완성·코드 탐색·디버깅 연동만 담당하고 컴파일러는 포함하지 않습니다. GCC, Clang, MSVC 같은 툴체인을 따로 설치하고 경로를 잡아줘야 실제 빌드가 됩니다. ‘확장은 편집 경험, 툴체인은 빌드’로 역할이 분리돼 있다고 이해하면 오류 원인을 훨씬 빨리 좁힐 수 있습니다.
확장을 많이 깔수록 개발이 편해지나요?
아닙니다. 확장이 늘면 편집기 시작이 느려지고, 같은 언어의 자동완성 확장이 겹치면 IntelliSense가 중복 표시되거나 서로 인덱싱을 반복해 CPU 점유율이 치솟습니다. 언어 1개·디버거 1개·포매터 1개·린터 1개의 핵심 4~5개로 시작하고, 필요가 생길 때만 하나씩 추가하세요. 어느 확장이 충돌 원인인지 되짚기는 어렵기 때문에 적게 시작하는 편이 유지보수에 유리합니다.
편집기를 자동 업데이트했더니 디버거가 갑자기 안 됩니다.
VS Code는 약 한 달 주기로 갱신되는데, 디버그 확장이 특정 버전의 확장 API에 묶여 있으면 편집기 업데이트 직후 동작이 깨질 수 있습니다. 마켓플레이스의 ‘지원 VS Code 버전’ 표기를 확인하고, 팀 작업이라면 편집기 버전을 고정하거나 확장 배포 시점을 사내에서 통제하는 방식이 안전합니다. 급하면 직전 버전으로 롤백한 뒤 확장 갱신을 기다리는 것도 방법입니다.
Appium 세팅이 자꾸 실패하는데 무엇부터 봐야 하나요?
대부분 버전 조합 문제입니다. 무작정 최신으로 깔면 서버·드라이버·OS·언어 바인딩 버전이 어긋나 세션이 열리지 않습니다. 순서를 뒤집어 테스트 대상 앱과 기기 OS 버전을 먼저 고정하고, 그에 맞는 드라이버 버전을 역산한 뒤 마지막에 호환되는 Appium 서버 버전을 맞추세요. 최신보다 ‘검증된 조합’을 고정하는 것이 핵심입니다.
임베디드 개발도 VS Code로 할 수 있나요?
가능합니다. IAR 같은 임베디드 툴체인 업체들이 VS Code용 디버그 확장을 제공해 자사 컴파일러·디버거 엔진을 편집기에 연동합니다. 전용 IDE를 강요하던 방식에서 개발자가 쓰는 편집기에 엔진을 얹는 방식으로 바뀐 흐름입니다. 다만 확장 자체는 무료여도 뒤에 붙는 컴파일러·디버거는 유료 라이선스인 경우가 많으니, 확장 비용과 엔진 비용을 분리해 확인하세요.
자동화 테스트를 도입하면 무조건 시간이 절약되나요?
조건이 있습니다. 자동화의 진짜 비용은 세팅이 아니라 유지보수입니다. UI가 조금만 바뀌어도 요소를 못 찾아 스크립트가 깨지므로 계속 손봐야 합니다. 그래서 효과가 뚜렷한 구간은 같은 시나리오를 반복 돌리는 회귀 검증이고, 한두 번 확인하고 말 화면은 수동 테스트가 더 쌉니다. 도입 전에 ‘이 테스트를 앞으로 몇 번 돌릴 것인가’를 먼저 계산하세요.