VS Code 스니펫 만들기, 반복 타이핑 줄이는 법

같은 형태의 코드를 하루에도 몇 번씩 치고 있다면 스니펫을 만들 때가 된 것이다. VS Code는 사용자가 직접 스니펫을 정의할 수 있고, 만드는 데 5분이면 충분하다. 이 글은 스니펫 파일을 만드는 방법부터 탭으로 이동하는 자리 표시자, 파일 이름이나 날짜 같은 변수, 그리고 팀과 공유하는 프로젝트 스니펫까지 다룬다. 마지막에는 스니펫을 만들지 말아야 할 경우도 짚는다.

만드는 곳은 명령 팔레트 한 군데다

File > Preferences > Configure Snippets를 고르면 언어 목록이 뜬다. 특정 언어용을 만들려면 그 언어를 고르고, 모든 언어에서 쓰려면 New Global Snippets file을 고른다. 명령 팔레트(Ctrl+Shift+P)에서 Snippets를 쳐도 같은 메뉴가 나온다.

파일이 열리면 JSON 형식으로 정의한다. 공식 문서의 예시가 기본 구조를 잘 보여준다.

{
  "For Loop": {
    "prefix": ["for", "for-const"],
    "body": ["for (const ${2:element} of ${1:array}) {", "\t$0", "}"],
    "description": "A for loop."
  }
}

바깥쪽 키("For Loop")는 스니펫 이름이다. 안쪽에 세 가지가 들어간다. prefix는 자동완성에서 이 스니펫을 부를 단어이고 배열로 여러 개를 줄 수 있다. body는 실제로 삽입될 내용이며 줄 단위 배열이다. description은 자동완성 목록에 뜨는 설명이다.

body의 각 원소가 한 줄이다. 들여쓰기는 \t로 넣는다. 공백을 직접 넣어도 되지만 \t를 쓰면 사용자의 editor.tabSize 설정을 따라가므로 그쪽이 낫다.

탭 순서를 설계하는 것이 스니펫의 핵심이다

스니펫이 단순한 텍스트 치환과 다른 지점이 여기다. 삽입한 뒤 Tab을 누르면 정해둔 자리로 커서가 차례로 이동한다.

$1, $2처럼 숫자를 붙이면 그 순서대로 방문한다. $0은 특별해서 마지막 위치를 뜻한다. 모든 자리를 다 채우고 나면 커서가 여기로 온다. 위 예시에서 $0이 반복문 안쪽에 있는 이유가 그것이다. 배열과 변수 이름을 채운 뒤 바로 본문을 쓰게 된다.

${1:element}처럼 콜론 뒤에 기본값을 주면 그 텍스트가 선택된 상태로 들어간다. 그대로 두려면 Tab을 누르고, 바꾸려면 그냥 타이핑하면 된다.

같은 번호를 여러 곳에 쓰면 연결된다. 한 곳을 고치면 나머지가 같이 바뀐다. React 컴포넌트 스니펫이 좋은 예다.

{
  "React Function Component": {
    "prefix": "rfc",
    "body": [
      "interface ${1:Name}Props {",
      "\t$2",
      "}",
      "",
      "export function ${1:Name}({ $3 }: ${1:Name}Props) {",
      "\treturn (",
      "\t\t<div>$0</div>",
      "\t);",
      "}"
    ],
    "description": "타입 정의가 붙은 함수형 컴포넌트"
  }
}

${1:Name}이 세 군데 있다. 이름을 한 번만 치면 인터페이스 이름, 함수 이름, 타입 참조가 전부 바뀐다.

선택지를 주는 문법도 있다. ${1|get,post,put,delete|}처럼 파이프로 묶으면 삽입 시 드롭다운이 뜬다. HTTP 메서드나 로그 레벨처럼 후보가 정해진 값에 쓴다.

파일 이름, 날짜, 클립보드를 자동으로 채운다

문서가 소개하는 변수들을 쓰면 손으로 치지 않아도 되는 것이 늘어난다. 자주 쓰는 것은 이렇다.

TM_FILENAME은 현재 파일 이름, TM_FILENAME_BASE는 확장자를 뺀 이름이다. CURRENT_YEAR, CURRENT_MONTH, CURRENT_DATE는 날짜다. CLIPBOARD는 클립보드 내용, WORKSPACE_NAME은 열려 있는 워크스페이스 이름이다.

라이선스 헤더 스니펫이 이 변수들의 전형적인 용도다.

{
  "License Header": {
    "prefix": "license",
    "body": [
      "/*",
      " * $TM_FILENAME",
      " * Copyright (c) $CURRENT_YEAR ${1:회사명}",
      " * Created: $CURRENT_YEAR-$CURRENT_MONTH-$CURRENT_DATE",
      " */",
      "$0"
    ]
  }
}

변수가 비어 있을 때 대신 넣을 값은 ${변수:대체값}으로 준다. 문서 표현으로는 "변수가 설정되지 않았으면 대체값을 삽입한다"이다.

파일 이름을 그대로 클래스 이름으로 쓰는 것도 많이 쓴다. ${TM_FILENAME_BASE}를 클래스 이름 자리에 넣으면 UserService.ts에서 class UserService가 자동으로 나온다.

프로젝트 스니펫은 저장소에 넣어 함께 쓴다

개인 스니펫은 내 컴퓨터에만 있다. 팀이 같이 쓰려면 프로젝트 스니펫을 만든다. 스니펫 설정 메뉴에서 New Snippets file for '폴더명'을 고르면 .vscode 안에 .code-snippets 확장자의 파일이 생긴다. 이 파일은 커밋되므로 저장소를 클론한 사람 모두가 같은 스니펫을 쓴다.

프로젝트 스니펫에는 scope 속성을 줄 수 있다. 특정 언어에서만 뜨게 하는 용도다.

{
  "API 핸들러": {
    "scope": "typescript,typescriptreact",
    "prefix": "handler",
    "body": [
      "export async function ${1:name}(req: Request, res: Response) {",
      "\ttry {",
      "\t\t$0",
      "\t} catch (err) {",
      "\t\tlogger.error('${1:name} failed', { err });",
      "\t\tres.status(500).json({ message: '${2:처리 중 오류가 발생했습니다}' });",
      "\t}",
      "}"
    ],
    "description": "팀 표준 에러 처리가 포함된 핸들러"
  }
}

이런 스니펫의 가치는 타이핑 절약이 아니라 규칙의 전파에 있다. 에러 로깅 형식이나 응답 구조 같은 팀 컨벤션을 문서로만 적어두면 아무도 안 본다. 스니펫으로 만들어 두면 코드를 쓰는 순간 자연스럽게 따라간다. 새로 합류한 사람이 가장 빨리 배우는 경로이기도 하다.

자동완성을 거치지 않고 단축키로 바로 넣는 법

접두사를 치고 자동완성 목록에서 고르는 것이 기본이지만, 매일 쓰는 스니펫이라면 단축키에 직접 걸어두는 편이 빠르다. keybindings.json에서 editor.action.insertSnippet 명령에 인자를 주면 된다.

[
  {
    "key": "ctrl+alt+l",
    "command": "editor.action.insertSnippet",
    "args": { "langId": "typescript", "name": "License Header" },
    "when": "editorTextFocus"
  }
]

name에는 스니펫 정의의 바깥쪽 키를 그대로 적는다. 스니펫 파일을 거치지 않고 내용을 직접 넣을 수도 있다.

[
  {
    "key": "ctrl+alt+t",
    "command": "editor.action.insertSnippet",
    "args": { "snippet": "console.time('$1');\n$0\nconsole.timeEnd('$1');" }
  }
]

when 절을 쓰면 조건을 붙일 수 있다. 위 예시의 editorTextFocus는 편집기에 포커스가 있을 때만 동작하게 한다. 터미널에서 같은 키를 눌러도 스니펫이 끼어들지 않는다.

단축키 편집기는 Ctrl+K Ctrl+S로 연다. 여기서 검색해 기존 단축키와 충돌하는지 먼저 확인하고 정하는 것이 좋다. VS Code 기본 단축키를 덮어쓰면 나중에 왜 안 되는지 한참 찾게 된다.

스니펫을 만들지 말아야 할 때

여기까지 읽으면 이것저것 만들고 싶어지겠지만, 나는 개수를 의도적으로 적게 유지한다. 이유가 둘이다.

첫째, 자동완성 목록이 오염된다. 스니펫 접두사가 늘어나면 평범한 변수 이름을 치는 중에 스니펫이 끼어들어 엉뚱한 코드가 삽입된다. 접두사를 흔한 단어(log, get, api)로 잡으면 특히 그렇다. 나는 접두사를 일부러 특이하게 짓는다. 예를 들어 handler 대신 xhandler처럼 앞에 한 글자를 붙인다. 오타로 발동될 일이 없다.

둘째, 기억 비용이 든다. 스니펫이 서른 개 있으면 어떤 게 있는지 모르게 되고, 결국 안 쓰게 된다. 쓰지도 않는 스니펫이 자동완성만 어지럽히는 상태가 된다. 손이 진짜 자주 가는 것만 남기고 주기적으로 정리하는 편이 낫다.

그리고 한 가지 더. 스니펫으로 해결하려는 문제가 사실은 함수나 유틸리티로 해결할 문제인 경우가 있다. 같은 코드를 계속 찍어내야 한다면, 그 코드를 함수로 묶을 수 없는지 먼저 생각해 봐야 한다. 스니펫은 중복을 빠르게 만들어내는 도구라서, 잘못 쓰면 중복 코드를 양산하는 기계가 된다. 구조가 반복되는 것(컴포넌트 골격, 테스트 골격)에는 맞고, 로직이 반복되는 것에는 맞지 않는다.

참고 자료

• Snippets in Visual Studio Code — 스니펫 파일 만들기, prefix/body/scope, 탭 정지점과 자리 표시자, 변수 목록
• User and workspace settings — Visual Studio Code Docs — 프로젝트 스니펫이 놓이는 .vscode 폴더와 공유 방식