슬래시 커맨드 만들기
매번 설명하던 것을 명령 하나로 굳힌다.
무엇인가
자주 시키는 일을 /이름 하나로 굳혀두는 것이다. 마크다운 파일 하나가 곧 명령이 된다.
지금 여덟 개를 쓰고 있다. /devlog /til /issue /blog-draft /publish /trend /ideas /refresh.
왜 만드나
같은 걸 세 번째 설명하고 있으면 그때가 만들 때다.
개발일지를 예로 들면, 매번 이렇게 말해야 했다. 오늘 커밋 긁고, 파일 수정 시각도 보고, 이슈 원장도 확인하고, 이모지 쓰지 말고, 거창하게 쓰지 말고, 자정 넘겨 일했으니 날짜 경계는 새벽 4시로 잡고. 이걸 매번 치는 순간 그 일은 안 하게 된다.
커맨드의 값은 자동화가 아니라 마찰 제거에 있다. /devlog 한 줄이면 그 규칙이 전부 딸려 온다.
커맨드 안에 들어가는 것
파일 하나에 세 종류가 들어간다.
두 번째가 제일 중요하다. 커맨드는 결국 프롬프트인데, 하지 말아야 할 것을 안 적으면 매번 다르게 나온다. /devlog에는 "이모지 금지"와 "raw 덤프 아니고 distill"이 규칙으로 박혀 있고, /refresh에는 "확인 전 단정·날조 금지"가 최우선 규칙으로 박혀 있다.
세 번째도 빼면 안 된다. 개발일지의 날짜 경계가 그렇다. 자정을 넘겨 일하는데 달력 자정으로 자르면, 새벽 2시 커밋이 다음 날 일지로 넘어간다. 그래서 작업일을 "그날 06시부터 다음 날 04시까지"로 정의해 커맨드에 적어뒀다.
하나에 다 넣지 않는다
만들다 보면 커맨드가 비대해진다. /trend가 그랬다.
원래는 하나였다. 동향을 수집하고, 카드로 굽고, 쓸 만한 아이디어를 표시하는 것까지. 그런데 아이디어가 그날 카드 안에 갇혀서 하루 지나면 아무도 안 봤다. 수집과 재사용은 시점이 다른 일인데 한 명령에 묶여 있으니 재사용 쪽이 죽은 것이다.
그래서 /ideas로 떼어냈다. 수집은 /trend, 재사용은 /ideas. 카드에 남은 표시를 나중에 프로젝트별로 다시 꺼내고, 실제로 반영하면 반영 표시를 남긴다.
한 명령이 여러 일을 하면 편해 보이지만, 그 일들의 실행 시점이 다르면 뒤쪽 일이 죽는다.
동향은 아침에 돌고, 아이디어를 꺼내 보는 건 그 프로젝트를 만질 때다. 며칠 뒤일 수도 있다. 시점이 다른 걸 한 명령에 묶으면 앞의 것만 돌고 뒤는 안 돈다.
무인으로 돌 것인가
커맨드를 만들 때 정해야 하는 게 하나 더 있다. 사람이 부를 것인가, 크론이 부를 것인가.
무인으로 돌릴 거면 커맨드가 질문하면 안 된다. 그래서 /trend와 /refresh에는 auto 인자를 뒀다. 이걸 붙이면 절대 되묻지 않고, 재료가 없으면 빈 결과를 쓰고 끝낸다. 억지로 채우지 않는 게 규칙에 박혀 있다.
반대로 /publish는 무인 모드가 없다. 무엇을 발행할 값이 있는지는 기계가 모른다.
실제로 굳어진 것들
/devlog그날 커밋·파일 수정 시각·이슈 원장을 긁어 일지 초안/til방금 배운 것을 그날 일지에 즉석으로 박기/issue이슈를 원장에 열고, 닫고, 목록 보기/blog-draft이슈·배움을 블로그 초안으로/publish검토 끝난 초안을 발행으로 토글/trend아침에 기술 동향을 수집해 카드로/ideas그 카드에 남은 아이디어를 프로젝트별로 회수/refresh코드에 밀린 위키를 커밋 근거로 갱신
언제 안 만드나
한 번 하고 말 일은 안 만든다. 커맨드도 유지보수 대상이라, 안 쓰는 게 쌓이면 목록에서 찾는 비용만 는다.
기준은 단순하다. 같은 설명을 세 번 했는가. 그 전에 만들면 대개 안 쓰게 되고, 그 뒤로 미루면 계속 손으로 하게 된다.