VSCode tasks.json 입문: 반복 명령 자동화, 빌드·테스트·실행 한 번에 묶는 법

터미널에서 같은 명령을 매번 다시 입력하다 보면 작은 작업도 자꾸 끊깁니다. npm run build, npm test, python -m pytest, uvicorn main:app --reload 같은 명령을 자주 반복한다면 VSCode의 tasks.json으로 한 번 정리해두는 편이 훨씬 편합니다.

tasks.json은 작업 이름을 붙여 명령을 저장하고, 빌드·테스트·실행 순서를 묶고, 디버깅 시작 전 필요한 준비 작업까지 연결하는 데 잘 맞습니다. 초보자라면 복잡한 자동화부터 넓게 잡기보다 자주 쓰는 명령 2~3개를 먼저 작업으로 저장하는 방식이 부담이 적습니다.

VSCode tasks.json은 무엇을 자동화해주나

tasks.json은 워크스페이스의 .vscode 폴더에 두는 작업 설정 파일입니다. VSCode 안에서 외부 명령을 실행할 수 있게 해주며, 빌드·테스트·린트·개발 서버 실행처럼 터미널 기반 작업을 반복해서 돌릴 때 특히 유용합니다.

출처: Visual Studio Code 공식 문서

처음에는 네 가지만 보면 충분합니다

기본 흐름은 단순합니다. label은 작업 이름, type은 실행 방식, command는 실제 명령, group은 작업 성격을 나눕니다. 여기에 터미널 표시 방식을 정하는 presentation만 더해도 반복 작업을 정리하는 데는 충분한 출발점이 됩니다.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Run tests",
      "type": "shell",
      "command": "npm test",
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    }
  ]
}

shell과 process는 어떻게 고를까

type은 보통 shell과 process 중 하나를 고릅니다. 명령을 셸 문법 그대로 쓰고 싶다면 shell이 편하고, 특정 실행 파일을 직접 호출하는 식으로 더 단순하게 쓰려면 process가 잘 맞습니다. 초보자라면 먼저 shell로 시작하고, 운영체제 차이나 인용 부호 처리에서 자주 막힐 때 process를 비교해보는 흐름이 무난합니다.

다만 셸 문법을 쓰는 만큼 운영체제 차이가 드러나기도 합니다. 같은 작업이라도 macOS·Linux와 Windows 명령이 다를 수 있으니, 한 프로젝트를 여러 환경에서 쓴다면 플랫폼별 속성을 나눠 적는 습관이 도움이 됩니다.

빌드·테스트·실행을 한 번에 묶는 기본 패턴

자동화 체감이 가장 큰 순간은 따로따로 돌리던 명령을 하나의 작업 흐름으로 묶을 때입니다. 예를 들어 빌드 후 테스트, 테스트 후 실행처럼 순서를 정해두면 작업 전환이 줄어듭니다. 이때 핵심이 dependsOn과 dependsOrder입니다.

여러 작업을 순서대로 실행하기

dependsOn은 다른 작업을 호출하고, dependsOrder를 sequence로 두면 적은 순서대로 실행할 수 있습니다. 빌드와 테스트를 각각 따로 만든 뒤 마지막 실행 작업에서 묶는 방식이 가장 관리하기 쉽습니다.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "build",
      "type": "shell",
      "command": "npm run build",
      "group": "build"
    },
    {
      "label": "test",
      "type": "shell",
      "command": "npm test",
      "group": "test"
    },
    {
      "label": "start",
      "type": "shell",
      "command": "npm run dev",
      "dependsOrder": "sequence",
      "dependsOn": ["build", "test"],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    }
  ]
}

이 구조의 장점은 작업이 섞이지 않는다는 점입니다. 실패한 지점이 빌드인지 테스트인지 바로 구분되고, 나중에 lint나 타입체크를 추가해도 흐름을 유지하기 쉽습니다. 작업 이름만 명확하면 혼자 쓰는 프로젝트든 팀 프로젝트든 다시 보기 편합니다.

입력값을 받아 같은 작업을 재활용하기

매번 포트 번호나 스크립트 이름이 달라진다면 inputs를 같이 쓰면 편합니다. VSCode는 promptString, pickString, command 형태의 입력값을 지원하므로, 작업 파일을 여러 개 복붙하지 않고 하나로 재사용하기 좋습니다.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "run server",
      "type": "shell",
      "command": "npm run dev -- --port ${input:devPort}"
    }
  ],
  "inputs": [
    {
      "id": "devPort",
      "type": "promptString",
      "description": "개발 서버 포트를 입력하세요",
      "default": "3000"
    }
  ]
}

변수 치환은 모든 속성에서 자유롭게 되는 것은 아닙니다. 보통 command, args, options에서 주로 쓰는 편이 안전합니다. 파일 경로나 환경 변수는 ${workspaceFolder}, ${file}, ${env:NAME}처럼 읽기 쉬운 형태로 정리해두면 다른 환경에서도 수정량이 줄어듭니다.

launch.json과 연결하면 디버깅 전 준비가 자동으로 된다

실행 전에 미리 빌드나 watch를 돌려야 하는 프로젝트라면 launch.json의 preLaunchTask와 연결하면 됩니다. 디버깅 버튼을 눌렀을 때 필요한 준비 작업이 먼저 실행되므로, 수동으로 터미널을 열어 선행 명령을 치는 습관을 줄일 수 있습니다. 디버깅 흐름이 아직 낯설다면 VSCode 디버깅 입문 2026: 브레이크포인트/launch.json로 Node·Python 10분 디버깅을 이어서 보면 연결이 훨씬 자연스럽습니다.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Python: FastAPI",
      "type": "debugpy",
      "request": "launch",
      "program": "${workspaceFolder}/main.py",
      "preLaunchTask": "build"
    }
  ]
}

watch 작업처럼 계속 살아 있어야 하는 작업은 조금 다릅니다. 이 경우에는 isBackground 설정과 적절한 problemMatcher가 같이 있어야 디버깅 쪽에서 준비 완료 시점을 알 수 있습니다. 개발 서버나 번들러를 백그라운드로 붙일 때 자주 만나는 포인트입니다.

자주 막히는 문제와 정리 순서

처음부터 완벽한 자동화를 만들 필요는 없습니다. 자주 쓰는 명령 하나를 저장하고, 그다음 두 개를 묶고, 마지막에 디버깅이나 watch 작업과 연결하는 순서가 가장 무난합니다. 아래 네 가지를 기억해두면 시행착오를 많이 줄일 수 있습니다.

1. 명령이 안 잡히면 PATH부터 확인하기

tasks.json에서만 명령이 안 되고 터미널에서는 되는 경우가 있습니다. VSCode 작업은 일반 로그인 셸과 다르게 동작할 수 있어, nvm, pyenv, Homebrew 경로가 자동으로 안 붙는 상황이 생깁니다. 이런 경우에는 작업 명령보다 셸과 PATH 설정을 먼저 확인하는 편이 빠릅니다.

2. output이 너무 지저분하면 presentation을 조정하기

작업을 여러 번 돌리다 보면 이전 로그가 계속 남아 보기가 불편해집니다. 이때는 presentation.reveal, panel 값을 조절해 항상 새 터미널을 열지, 같은 패널을 재사용할지 정하면 됩니다. 초보자라면 먼저 panel: "new"로 구분해보고, 익숙해지면 필요한 작업만 재사용하도록 바꾸면 됩니다.

3. 다시 실행할 때 값이 달라져야 하면 runOptions를 보기

같은 작업을 다시 돌릴 때 변수 값을 새로 평가할지, 이전 값을 재사용할지도 설정할 수 있습니다. 반복 작업 성격이 강하면 기본값대로 두고, 같은 조건으로 재실행하는 패턴이 많다면 runOptions를 조정해 흐름을 단순하게 만들 수 있습니다.

4. 초보자에게 가장 쉬운 출발점

처음에는 테스트 명령 하나 저장하기, 빌드와 테스트를 분리해 이름 붙이기, 필요하면 실행 작업에 dependsOn 붙이기, 디버깅 전에 필요한 작업만 preLaunchTask로 연결하기 순서가 부담이 적습니다. 여기까지 해도 수동 입력이 크게 줄어듭니다.

처음에는 이렇게 설정하면 편하다

가장 부담 없는 시작점은 매일 한 번 이상 치는 명령 하나를 작업으로 옮기는 것입니다. 그다음 테스트와 빌드를 나누고, 마지막에 실행이나 디버깅과 연결하면 tasks.json이 왜 편한지 바로 체감됩니다. 처음부터 모든 명령을 넣기보다 자주 쓰는 흐름 하나를 먼저 완성하는 편이 훨씬 오래 갑니다.

참고자료(외부링크)

공식 문서에서 기본 동작을 먼저 확인한 뒤, 아래 두 글을 이어서 보면 실제 작업 흐름을 연결하기가 더 쉬워집니다.

자주 묻는 질문

반복 명령을 한두 개만 자동화해도 VSCode 작업 흐름은 훨씬 단순해집니다. 처음에는 테스트 하나부터 저장하고, 익숙해지면 빌드·실행·디버깅으로 천천히 넓혀가면 됩니다.