터미널 명령어를 가르치지 마세요. 터미널 워크플로우(Workflows)를 가르치세요.

대부분의 터미널 교육은 명령어(Commands)를 가르칩니다.

시작 단계에서는 그것이 타당합니다.

grep이 무엇을 하는지 알아야 합니다. find가 어떻게 작동하는지 알아야 합니다. 파이프(Pipes), 리다이렉션(Redirects), 종료 코드(Exit codes), 환경 변수(Environment variables), 그리고 셸 스크립트(Shell scripts)를 이해해야 합니다.

하지만 시간이 흐른 뒤에는, 명령어가 어려운 부분이 아닙니다.

어려운 부분은 워크플로우(Workflow)입니다.

다음과 같은 것이 아닙니다:

grep -R "TODO" .

하지만 다음과 같은 것입니다:

레포지토리(Repo)를 조사합니다.
위험한 파일들을 찾습니다.
무엇을 변경해야 할지 결정합니다.
...

이것이 대부분의 사람들이 배우지 못하는 부분입니다.

그리고 이것이 바로 AI 에이전트(AI agents)에게 가장 필요한 부분이기도 합니다.

명령어는 어휘입니다

터미널 명령어를 아는 것은 유용합니다.

하지만 명령어는 어휘(Vocabulary)일 뿐입니다.

워크플로우(Workflows)는 실제로 업무를 완수하는 방법입니다.

초보자는 이렇게 묻습니다:

파일 목록을 보여주는 명령어가 무엇인가요?

경험이 더 많은 개발자는 이렇게 묻습니다:

파일 시스템(Filesystem)에서 무엇을 배우려고 하는가? 그리고 그것을 조사하는 가장 안전한 방법은 무엇인가?

이것들은 서로 다른 질문입니다.

예를 들어, 이 명령어는 암기하기 쉽습니다:

ls

하지만 실제 워크플로우는 다음과 같을 수 있습니다:

pwd
ls -la
find . -maxdepth 2 -type f | head
...

이 시퀀스(Sequence)는 당신이 어디에 있는지, 주변에 무엇이 있는지, 어떤 종류의 프로젝트에 있는지, 그리고 작업 공간(Workspace)이 이미 지저분한 상태인지(Dirty)를 알려줍니다.

명령어는 작습니다.

명령어를 둘러싼 판단력이 바로 기술(Skill)입니다.

터미널 워크플로우에는 단계가 있습니다

저는 다음과 같은 간단한 모델을 좋아합니다:

inspect (조사) -> decide (결정) -> run (실행) -> verify (검증) -> recover (복구)

이 패턴은 어디에서나 나타납니다.

1. Inspect (조사)

무언가를 변경하기 전에, 문제의 형태를 파악하십시오.

pwd
git status --short
find . -maxdepth 2 -type f | sort | head -50

이것은 의미 없는 잡무가 아닙니다.

이것은 가장 흔한 터미널 실수, 즉 잘못된 위치에서 올바른 명령어를 실행하는 것을 방지해 줍니다.

2. Decide (결정)

조사를 마쳤다면, 가장 작고 유용한 행동을 선택하십시오.

가장 강력한 명령어로 시작하지 마십시오.

더 많은 정보를 제공하거나 되돌릴 수 있는(Reversible) 변경을 수행하는 명령어로 시작하십시오.

예를 들어:

git diff -- path/to/file

다음보다는 말입니다:

git add .

또는:

ffprobe input.mp4

이전의 방식:

ffmpeg -i input.mp4 output.mp4

3. 실행 (Run)

명확한 기대치를 가지고 명령어를 실행하세요.

엔터(Enter) 키를 누르기 전에 무엇이 성공인지 알고 있어야 합니다.

나쁜 예:

이걸 한번 해보고 어떻게 되는지 봅시다.

좋은 예:

이 명령어는 출력 폴더에 하나의 MP4 파일을 생성해야 하며, 소스 파일은 변경되지 않은 상태로 유지되어야 하고, 입력값이 유효하지 않을 경우 0이 아닌 종료 코드(non-zero exit code)를 반환해야 합니다.

4. 검증 (Verify)

명령어가 종료되었다고 해서 워크플로우(Workflow)가 완료된 것은 아닙니다.

비디오를 변환했다면, 출력물을 검사하세요.

ffprobe output.mp4

코드를 변경했다면, 관련 테스트를 실행하세요.

npm test

콘텐츠를 편집했다면, 단순히 로컬 마크다운(Markdown)만 확인하지 말고 최종적으로 렌더링된 페이지를 확인하세요.

검증은 터미널 습관이 프로덕션 워크플로우(Production workflow)로 변모하는 지점입니다.

5. 복구 (Recover)

모든 유용한 워크플로우에는 복구 경로(Recovery path)가 필요합니다.

명령어가 실패하면 어떻게 되나요?

성공했지만 잘못된 결과물이 생성되면 어떻게 되나요?

워크스페이스(Workspace)에 이미 관련 없는 변경 사항이 있었다면 어떻게 되나요?

예를 들어:

git diff
git restore --staged .

또는:

mkdir -p output_failed
mv broken-output.mp4 output_failed/

복구는 무언가 망가진 후에 즉흥적으로 이루어져서는 안 됩니다.

복구는 워크플로우의 일부여야 합니다.

AI 에이전트(AI agents)에게 이것이 더 중요한 이유

AI 에이전트는 명령어를 찾아내는 데 매우 능숙합니다.

그들은 보통 인간보다 더 빠르게 올바른 셸(Shell) 구문을 찾아낼 수 있습니다.

하지만 그들도 여전히 익숙한 방식으로 실패할 수 있습니다:

• 프로젝트를 검사하기 전에 명령어를 실행함
• 좁은 범위의 명령어로 충분한 상황에서 광범위한 명령어를 사용함
• 성공 출력(Success output)을 너무 일찍 신뢰함
• 복구 계획 없이 파일을 덮어씀
• 플랫폼별 검증 단계를 건너뜀
• 도구의 기능(Capability)을 완성된 워크플로우로 취급함

그렇기 때문에

하지만 실제 검색 워크플로우 (Workflow)는 다음과 같을 수 있습니다:

git status --short
find . -maxdepth 3 -type f | sort | head -100
grep -R --exclude-dir=node_modules --exclude-dir=.git "stripe" .
...

그 차이는 단순히 구문 (Syntax)의 문제가 아닙니다.

워크플로우는 다음과 같이 말합니다:

• 먼저 워크스페이스 (Workspace)를 확인하라
• 의존성 폴더 (Dependency folders)를 피하라
• 광범위하게 검색한 다음, 파일 유형별로 범위를 좁혀라
• 제품 용어와 구현 용어를 모두 검색하라
• 실제 경계가 어디인지 알기 전까지는 편집하지 마라

이것이 개발자들이 실제로 하는 일입니다.

명령어는 단지 하나의 조각일 뿐입니다.

예시: ffmpeg를 가르치는 것 vs 미디어 준비 (Media prep)를 가르치는 것

당신은 다음과 같이 가르칠 수 있습니다:

ffmpeg -i input.mov output.mp4

데모용으로는 괜찮습니다.

하지만 파일을 플랫폼에 업로드해야 한다면, 워크플로우 (Workflow)가 더 중요합니다:

입력 파일 검사 (Inspect input).
길이, 코덱 (Codec), 픽셀 포맷 (Pixel format), 오디오, 그리고 크기 (Dimensions)를 확인하라.
안전한 기본값으로 변환하라.
...

중요한 교훈은 "FFmpeg를 사용하라"가 아닙니다.

중요한 교훈은 다음과 같습니다:

대상 플랫폼이 수락할 때까지 미디어 변환을 절대 신뢰하지 마라.

이것이 워크플로우 (Workflow) 지식입니다.

이것이 Terminal Skills가 필요한 이유입니다

Terminal Skills가 유용한 이유는 에이전트 (Agent)에게 단순한 명령어가 아닌, 워크플로우 (Workflows)를 패키징할 수 있는 방법을 제공하기 때문입니다.

좋은 기술 (Skill)은 단순히 다음과 같이 말하지 않습니다:

이 명령어를 실행하라.

대신 다음과 같이 말합니다:

작업이 이와 같이 보일 때 이것을 사용하라.
이러한 입력값들을 검사하라.
이러한 단계들을 실행하라.
...

이것이 가공되지 않은 도구 접근 (Raw tool access)과 신뢰할 수 있는 자동화 (Automation) 사이의 누락된 계층입니다.

예를 들어, 미디어 기술 (Media skill)은 에이전트에게 업로드하기에 안전한 비디오를 준비하는 방법을 가르칠 수 있습니다.

Git 기술 (Git skill)은 에이전트에게 사용자의 변경 사항을 파괴하지 않고 더러워진 워크트리 (Worktree)를 검사하는 방법을 가르칠 수 있습니다.

배포 기술 (Deployment skill)은 에이전트에게 빌드, 테스트, 배포, 그리고 라이브 URL을 검증하는 방법을 가르칠 수 있습니다.

핵심은 터미널이 쉬워지는 것이 아닙니다.

핵심은 워크플로우 (Workflow)가 반복 가능해진다는 것입니다.

유용한 기술은 완료 정의 (Definition of done)를 갖는다

이 부분이 제가 가장 중요하게 생각하는 지점입니다.

명령어는 성공적으로 종료될 수 있지만, 여전히 문제를 해결하지 못할 수도 있습니다.

기술 (Skill)은 완료 (Done)를 정의해야 합니다.

코드 변경의 경우:

완료 (Done)란 대상 파일들이 변경되었고, 테스트를 통과했으며, 관련 없는 파일은 건드리지 않았고, 결과가 정확한 파일 경로와 함께 요약되었음을 의미합니다.

비디오 변환 (Video conversion)의 경우:

완료 (Done)란 출력 파일이 읽기 가능하고, 예상된 코덱 (Codec) 및 픽셀 포맷 (Pixel format)을 사용하며, 목표 크기 미만이고, 업로드 컴포저 (Upload composer)에 의해 수락되었음을 의미합니다.

콘텐츠 워크플로우 (Content workflow)의 경우:

완료 (Done)란 초안이 존재하고, 링크가 작동하며, 대상 플랫폼 형식이 준수되었고, 게시 승인이 기록되었음을 의미합니다.

마지막 줄이 중요합니다.

실제 업무에서 검증 (Verification)과 승인 (Approval)은 시스템의 일부입니다.

이것들은 선택적인 관리적 세부 사항이 아닙니다.

터미널 작업을 가르치는 더 나은 방법

저는 여전히 사람들이 명령어를 배워야 한다고 생각합니다.

하지만 거기서 멈춰서는 안 됩니다.

워크플로우 (Workflows) 안에서 명령어를 가르치세요.

다음과 같은 방식 대신:

여기 유용한 Linux 명령어 20개가 있습니다.

이렇게 가르치세요:

익숙하지 않은 리포지토리 (Repo)를 조사하는 방법은 다음과 같습니다.
코드베이스 (Codebase)를 안전하게 검색하는 방법은 다음과 같습니다.
업로드를 위해 비디오를 준비하는 방법은 다음과 같습니다.
...

이것이 개발자들이 실제로 일하는 방식에 더 가깝습니다.

또한 AI 에이전트 (AI agents)가 필요로 하는 것에도 더 가깝습니다.

터미널 자동화 (Terminal automation)의 미래는 에이전트가 더 많은 명령어를 암기하는 것이 아니기 때문입니다.

더 나은 워크플로우를 따르는 에이전트가 되는 것입니다.

만약 AI 에이전트를 활용해 무언가를 만들고 있다면, 스스로에게 이렇게 물어보세요:

내가 처음부터 계속 설명하고 있는 터미널 작업은 무엇인가?

그것은 아마 프롬프트 (Prompt)의 문제가 아닐 것입니다.

그것은 아마 기술 (Skill)로 전환되어야 할 워크플로우의 문제일 것입니다.

공개 사항: 저는 이 글의 초안을 작성하고 편집하는 데 AI의 도움을 받았으며, 게시하기 전에 예시, 명령어 및 주장을 검토했습니다.