별칭을 더 만드는 대신, AI 에이전트를 셸 프런트엔드로 사용하세요

수년간 반복되는 명령어에 대한 해답은 그것을 저장하는 것이었습니다. 별칭(alias), 셸 함수(shell function), 또는 나중에 잊어버릴 이름으로 ~/bin에 저장하는 스크립트처럼 말입니다. 그러한 습관은 이제 의문을 가져볼 만합니다. AI 에이전트가 평이한 영어를 읽고 그 자리에서 바로 표준 도구들로 올바른 파이프라인을 구성할 수 있을 때, 대부분의 개인 스크립팅 계층은 더 이상 제 역할을 하지 못하게 됩니다. 이 글은 이러한 변화가 유효한 경우와 그렇지 않은 경우, 그리고 어느 쪽인지 결정하는 규칙에 대해 다룹니다.

이 주장은 한정적입니다. 스크립트가 구식이 된 것은 아닙니다. 하지만 사람들이 작성하는 작은 스크립트의 상당수는 파이프라인을 직접 손으로 입력하는 것이 번거롭다는 이유만으로 스크립트화된, 일회성이거나 거의 반복되지 않는 작업들입니다. 바로 그 번거로움을 AI 프런트엔드가 제거해 줍니다.

잊혀진 스크립트의 무덤

오래된 ~/bin이나 .zshrc를 들여다보면 같은 패턴을 발견하게 됩니다. 수십 개의 별칭과 함수가 있고, 그중 절반은 사용되지 않으며 대부분은 문서화되어 있지 않습니다. gs가 git status라는 것은 기억하지만, 로그를 추적하는 스크립트의 이름이 errlog였는지 logtail이었는지 기억나시나요? 6개월 전, 액세스 로그에서 실패한 요청을 추출하는 스크립트를 작성했습니다. 그것을 다시 찾는 데는 새로 작성하는 것보다 더 오랜 시간이 걸립니다.

여기에는 세 가지 비용이 쌓입니다. 첫째, 이름과 인수 순서를 기억해야 하는데, 이는 더 많은 조회 대상을 만듦으로써 해결하려 했던 조회 문제입니다. 둘째, 플래그가 바뀌거나 경로가 이동하면 스크립트가 조용히 깨지기 때문에 유지보수해야 합니다. 셋째, 다른 사람은 아무도 그것들을 읽을 수 없으므로, 그 지식은 한 사람의 머릿속에만 머물다가 그 사람이 팀을 떠나거나 자신의 축약어를 잊어버리면 사라집니다.

이 스크립트들 중 어떤 것도 작성하는 것이 잘못된 일은 아니었습니다. 각각은 그 순간의 실제적인 마찰을 해결했습니다. 문제는 축적입니다. 개인적인 자동화 계층은 누구도 가지치기할 수 있는 속도보다 더 빨리 자라며, 그 대부분은 1년 안에 쓸모없는 짐이 됩니다.

AI를 통해 셸을 구동하는 것은 어떤 모습인가

대안은 의도를 명시하고 에이전트가 명령어를 만들게 하는 것입니다. 도구의 이름을 지정하거나 플래그를 기억해 낼 필요가 없습니다. 원하는 결과를 설명하면 에이전트가 grep, awk, jq, find, sort 또는 적합한 도구를 선택하고 실행한 다음, 출력을 보여줍니다. 첫 시도가 잘못되었다면 구문이 아닌 말로 수정합니다.

그 모습은 다음과 같으며, 왼쪽에는 의도를, 오른쪽에는 에이전트가 구성하는 파이프라인의 종류를 나타냅니다.

왼쪽에 있는 것은 외울 필요가 없는 평이한 요청들입니다. 오른쪽에 있는 도구들은 숙련된 셸 사용자라면 이미 알고 있는 것들이지만, 그것들을 아는 것과 시간 압박 속에서 정확한 플래그를 기억해 내는 것은 다른 기술입니다. 에이전트가 기억해 내는 부분을 담당합니다. 사용자는 출력이 올바른지에 대한 판단을 계속 담당합니다.

요약하는 경우는 일반적인 스크립트가 따라올 수 없는 부분입니다. grep은 오류 라인을 가져올 수 있지만, 수백 개의 스택 트레이스를 실제로 무엇이 실패했는지 알려주는 세 문장으로 바꾸는 것은 언어 작업입니다. 동일한 루프 안에 있는 파이프라인과 언어 모델은 어느 한쪽만으로는 할 수 없는 일을 해냅니다.

왜 표준 도구가 AI의 홈그라운드인가

이것이 가능한 이유는 AI에게 요청되는 작업의 특성 때문입니다. Unix 도구 집합은 작고 오래되었으며, 문서화가 극도로 잘 되어 있습니다. grep, sed, awk, find, sort, jq 및 이들을 연결하는 셸은 수십 년 동안 안정적으로 유지되어 왔으며 수백만 개의 예제에 설명되어 있습니다. 모델이 이러한 부분들로 파이프라인을 구성할 때, 이는 모델이 가진 가장 잘 다루어지는 영역 중 하나에서 작업하는 것입니다. 명령어는 설계상 조합이 가능하므로, 모델은 무언가를 발명하는 대신 알려진 조각들을 끼워 맞추는 것입니다.

모델에게 새로운 알고리즘을 작성하거나 문서화되지 않은 비공개 내부 API를 탐색하도록 요청하는 것과 비교해 보십시오. 그런 경우 모델은 의지할 것이 거의 없으며 오류율이 치솟습니다. 셸 조합은 그 반대편에 있습니다. 구성 요소는 공개되어 있고, 조합 규칙은 간단하며, 잘못된 추측은 조용히 실패하기보다는 보통 요란하고 저렴하게 실패합니다.

이것이 적합한 두 번째 이유가 있습니다. 작업이 일회성이고 가변적일수록 스크립트는 그 역할을 제대로 수행하지 못하고 위임하는 것이 더 낫습니다. 스크립트는 작성 및 유지 관리 비용을 상각할 만큼 동일한 작업이 충분히 자주 반복될 때만 제값을 합니다. 대부분의 셸 요구사항은 그렇지 않습니다. 매번 약간씩 다릅니다. 날짜 범위가 다르거나, 필드가 다르거나, 파일이 다릅니다. 자연어는 그 변동성을 무료로 흡수하지만, 스크립트는 각 변형에 대해 새로운 플래그나 재작성이 필요할 것입니다.

스크립트가 여전히 우세할 때

위임이 모든 것의 해답은 아니며, 그렇다고 여기는 것은 반대의 실수로 이어집니다. 작성된 스크립트는 몇 가지 명확한 경우에 자연어 요청보다 뛰어납니다.

• 높은 빈도의 반복. 하루에 스무 번씩 동일한 작업을 실행한다면, 매번 말로 설명하는 과정은 두 글자 별칭보다 느립니다. 고정되고, 빈번하며, 동일한 작업이야말로 별칭이 만들어진 이유입니다. 이것들은 유지하세요.
• 정확한 재현성. cron 작업, 배포 단계 또는 CI 파이프라인에서 동일한 명령이 매번 같은 방식으로 실행되어야 할 때, 약간 다르게 나올 수 있는 프롬프트로부터 재조립하는 대신 파일에 고정된 리터럴 명령을 원할 것입니다.
• 정확성이 중요한 파이프라인. 미묘한 차이가 데이터를 손상시키거나 잘못된 결과를 초래할 수 있는 모든 것은 검토되고 버전 관리되는 스크립트에 속해야 합니다. 여기서의 가치는 편의성이 아니라, 정확한 단계가 고정되고 감사 가능하다는 점입니다.
• 공유되고 이름이 지정된 워크플로. 팀 전체가 의존하는 배포 단계는 각 개인의 표현 방식에 존재하는 것이 아니라, 이름이 있는 하나의 정식 형태를 가져야 합니다.

패턴은 간단합니다. 스크립트는 안정적이고, 빈번하며, 변하지 않아야 하는 것을 위한 것입니다. 위임은 탐색적이고, 가끔 발생하며, 매번 다른 것을 위한 것입니다. "그것을 스크립트로 만들어야 한다"는 오래된 조언은 대부분의 반복 작업이 첫 번째 범주에 속했을 때 옳았습니다. 작업이 두 번 다시 같은 방식으로 반복되지 않는 움직이는 대상일 때는 틀립니다.

위험한 명령어 문제

AI에게 명령어 조립을 맡기는 것은 명백한 위험을 야기합니다. 모델이 잘못된 명령어를 만들 수 있고, 일부 잘못된 명령어는 데이터를 삭제하거나 덮어씁니다. 이것은 실제 상황이며 전체 접근 방식의 한계를 설정합니다.

안전장치는 신중한 엔지니어가 이미 사용하는 것과 동일합니다. 파괴적인 작업은 실행되기 전에 사람의 검토를 거칩니다. 파일을 삭제하거나, 데이터베이스를 덮어쓰거나, 브랜치를 강제 푸시하거나, 권한을 변경하는 요청은 모델의 말만 듣고 실행되어서는 안 됩니다. 먼저 명령어를 읽고, 의도한 대로 작동하는지 확인한 다음 실행해야 합니다. 좋은 에이전트는 맹목적으로 실행하는 대신 명령어를 표시하고 되돌릴 수 없는 작업에서는 일시 중지합니다.

읽기 전용 및 쉽게 되돌릴 수 있는 작업은 위임이 자유롭게 실행되는 영역입니다. 나열, 계산, 검색, 요약 및 검사는 아무것도 손상시킬 수 없으므로 이를 막을 이유가 거의 없습니다. 정신적인 구분은 관찰하는 명령어와 변경하는 명령어 사이에 있습니다. 관찰하는 경우, 실행하게 두십시오. 변경하는 경우, 돌다리도 두들겨 보고 건너십시오.

비파괴적인 작업이라도 검증은 중요합니다. 모델은 깔끔하게 실행되면서도 잘못된 질문에 답하는 파이프라인을 조립할 수 있습니다. 예를 들어 날짜 필터에서 하나 차이 오류가 있거나 awk 필드에서 잘못된 열을 사용하는 경우입니다. 자신감 있게 생성되었다고 해서 출력이 자동으로 정확한 것은 아닙니다. 결과를 동료의 빠른 스크립트처럼 다루십시오. 유용하고 아마도 맞겠지만, 중요한 일에 사용하기 전에 한 번 훑어볼 가치가 있습니다.

재현성에는 여전히 기록이 필요합니다

대화가 제공하지 않는 한 가지는 영구적인 기록입니다. 만약 어떤 작업이 같은 방식으로 다시 실행하거나, 다른 사람에게 전달하거나, 사후 분석에서 설명할 만큼 중요하다면, 채팅에 입력한 단어들은 신뢰할 수 있는 결과물이 아닙니다. 그것들은 사라지거나 묻혀버리고, 모델은 다음번에 명령어를 다르게 표현할 수도 있습니다.

그래서 솔직한 입장은 "모든 스크립트를 삭제하라"가 아닙니다. 무언가를 기록하게 되는 계기가 바뀐다는 것입니다. 단지 한 번 타이핑하는 것이 지루하다는 이유만으로 더 이상 작업을 스크립트로 만들지 않습니다. 재현 가능해야 할 때, 즉 무인으로 실행될 때, 다른 사람들이 그것에 의존할 때, 정확한 단계가 유지되어야 할 때 기록을 합니다. 그 시점에서 일회용 파이프라인을 실제 스크립트나 문서화된 노트로 승격시키는데, 이상적으로는 에이전트에게 방금 실행한 정확한 명령어를 저장하도록 요청함으로써 그렇게 합니다. 에이전트는 그것도 잘하는데, 이름을 가질 만하다고 결정하면 성공적인 일회성 작업을 이름이 지정되고 커밋된 스크립트로 바꾸는 것입니다.

이것은 두 가지의 장점을 모두 유지합니다. 탐색적이거나 드문 작업은 자연어로 남아 빠르고 일회용으로 처리됩니다. 핵심적인 역할을 하게 되는 모든 것은 이전과 똑같이 이름이 있는 파일에 고정됩니다. 차이점은 이전의 습관이 가정했던 것보다 훨씬 더 적은 수의 작업만이 그 단계로 넘어간다는 것입니다.

내가 정한 규칙

의도를 말하고, 도구는 머릿속에서 비우며, 반드시 재현해야 할 것만 기록한다.

셸에서 하루 대부분을 차지하는, 끊임없고, 탐색적이며, 매번 조금씩 다른 작업의 경우, 결과를 설명하고 에이전트가 파이프라인을 구성하게 하는 것이 개인적인 스크립트 박물관을 유지하는 것보다 더 빠르고 가볍다. 안정적이고, 빈번하며, 정확성이 중요하고, 공유되는 작업의 경우, 명시적인 스크립트를 유지한다. 그 경우 핵심은 단계가 변하지 않는다는 것이기 때문이다.

모든 작업을 분류하는 기준은 그 작업이 같은 방식으로 반복될 것인지의 여부이다. 그렇고, 자주 반복된다면, 고정한다. 그렇지 않다면, 이름도 잊어버릴 도구를 만들지 않는다. 결과를 요청하고, 파괴적인 것이 실행되기 전에 명령을 확인하며, 이제 앞에 번역기를 둔 채로 셸의 가장 오래되고 가장 잘 문서화된 도구들이 언제나 해왔던 일을 하도록 둔다.