도구 일곱 개를 오가던 일감이 Skill 네 번으로 끝나기까지

일감 하나를 끝내는 동안 여는 도구가 일곱 개였다. Redmine, IntelliJ, Postman, GitHub, Jenkins, S3, 그리고 메일.

그중 가장 오래 걸리는 건 IntelliJ에서 하는 구현이고 이 시간은 AI로 크게 줄였다. 그다음에는 더 줄일 수 있는 곳이 어디인지 고민했다. 눈에 들어온 건 나머지 여섯 단계였다.

남은 여섯 단계는 옮기는 일이었다

하나씩 적어 보니 대단한 일은 없었다. 일감 번호를 복사해 커밋 메시지에 넣고, 커밋 해시를 Jenkins에 넣고, S3 경로를 복사해 메일에 붙인다. 판단 없이 옮기기만 하면 되는 일이었다.

그중 제일 무거운 건 운영 배포였다. 모듈 네 개에서 직전 릴리스 이후 바뀐 게 있는지 확인하고, 버전을 올리고, Release 문서를 쓰고, Jenkins를 돌리고, SQL과 S3 경로를 확인하고, 배포 일감을 만들고, 메일까지 써야 한다.

반복하는 일은 Skill로 ?

Microsoft가 AI 에이전트와 일하는 개발자에게 제안한 규칙 가운데 이 문제를 정확히 짚은 대목이 있다.

If you’re doing something repeatedly with an agent, wrap it into a reusable skill and share it. Team skills compound the same way code libraries do. If the same agent failure shows up twice, promote the correction into a reusable skill, test, eval, prompt, or workflow with a clear trigger.

에이전트와 반복해서 하는 일이 있다면 재사용할 수 있는 Skill로 감싸서 공유하라. 팀의 Skill은 코드 라이브러리처럼 쌓일수록 효과가 커진다. 같은 에이전트 실패가 두 번 나타나면 바로잡은 내용을 트리거가 분명하고 재사용할 수 있는 Skill, 테스트, eval, 프롬프트, 워크플로로 승격하라.

출처: Jay Parikh, Introducing Command Line, and the new rules for builders

만든 Skill 다섯 개

기준은 하나로 잡았다. 두 번 이상 똑같이 하는 일은 Skill로 만든다. 그렇게 만든 게 다섯 개다.

• /manage-redmine: 회사 규칙에 맞춰 일감을 만들고 고친다.
• /generate-postman: API 요청을 Postman 컬렉션에 넣고 실제로 호출해 본다.
• /commit-push: 커밋하고 푸시한다. 요청하면 배포로 이어 간다.
• /deploy-dev-server: 개발 서버에 반영하고 일감 상태를 맞춘다.
• /deploy-release: 운영 릴리스 전 과정을 처리한다.

도구는 되도록 API로

Skill이 도구를 대신 열어 주려면 AI가 그 도구를 직접 다룰 수 있어야 한다. computer use나 browser use처럼 AI가 화면을 보고 누르게 하는 방법도 있지만 느렸다.

한 번 누를 때마다 화면을 캡처해 모델에 보내면 모델이 그걸 읽고 다음에 무엇을 누를지 정해서 돌려준다. 동작 하나가 모델 호출 한 번이라 입력 칸 몇 개를 채우는 데도 이 왕복을 여러 번 해야 한다. 그래서 되도록 API로 갔다.

Redmine, Jenkins, Postman은 API 키로

• Redmine: API 키로 일감을 만들고, 고치고, 상태를 바꾼다. 브라우저는 열지 않는다.
• Jenkins: API 토큰으로 배포 작업을 실행하고 빌드 번호와 성공 여부를 확인한다.
• Postman: API 키로 요청을 컬렉션에 넣고 같은 요청을 로컬 서버에 호출해 응답까지 보여 준다.

메일은 browser use 대신 Playwright로

회사 메일인 Mailplug는 외부에서 쓸 수 있는 API를 제공하지 않는다. 그래서 브라우저를 직접 다뤄야 했고 방법은 크게 세 가지였다.

방식	어떻게 움직이나	모델 호출	맞는 일
Computer Use	화면을 찍어 보고 누를 좌표를 골라 클릭하거나 입력한다	동작마다	처음 보는 화면, 판단이 필요한 탐색
Browser Use	페이지 구조(DOM)를 요약해 보고 다음 행동을 고른다	동작마다	매번 다른 사이트
Playwright	브라우저를 코드로 조작해 정해 둔 입력 칸을 바로 채운다	0번	매번 같은 화면, 같은 절차

Computer Use와 Browser Use는 사람처럼 화면을 보고 매번 판단한다. 문제는 속도다. 앞에서 말한 왕복을 쪼개 보면 Computer Use는 동작 하나를 할 때마다 아래 과정을 한 바퀴 돈다.

1. 스크린샷: 화면 전체를 찍는다.
2. 이미지 전송: 스크린샷 한 장이 입력 토큰 약 1,000~1,800개다.
3. 모델 추론: 어디를 누를지 판단하는 데 몇 초가 걸린다.
4. 행동: 클릭이나 입력을 하나 한다.

메일 한 통을 채우려면 받는 사람, 참조, 제목, 본문을 넣고 확인까지 하는 동안 이 과정을 열 번 넘게 돈다. 사람이 하면 몇 초면 끝날 일이 분 단위가 된다.

출처: Anthropic, Computer use tool (스크린샷 한 장의 토큰 수)

느린 건 모델이 아니라 구조다. 메일 작성 화면은 매번 똑같고 하는 일도 판단이 아니라 옮기기다. 같은 화면을 매번 처음 보는 것처럼 판단할 이유가 없었다. 그래서 Microsoft가 공개한 오픈소스 브라우저 자동화 도구인 Playwright로 스크립트를 썼다.

Playwright는 어느 칸에 무엇을 넣을지 코드에 미리 적어 둔다. 모델은 메일 내용만 만들고 입력 칸은 코드가 채운다. 모델에게 묻지 않고 브라우저에 바로 명령을 보내니 기다릴 일이 없다.

로그인은 전용 Chrome 창에서 내가 직접 하고 스크립트는 그 세션을 이어받아 값만 채운다. 로그인 정보를 입력하지 않고 보내기도 누르지 않는다. 창을 열어 둔 채 끝나면 내가 내용을 확인하고 보낸다.

판단은 모델이, 실행은 스크립트가

Skill을 만들면서 가장 신경 쓴 건 토큰이었다. 그래서 Skill 하나를 짧은 설명서인 SKILL.md와 실제 일을 하는 Python 스크립트로 나눴다.

deploy-release/
├── SKILL.md                ← 언제, 어떤 순서로 (짧게)
└── scripts/
    ├── changed_modules.py  바뀐 모듈 찾기
    ├── bump_version.py     버전 올리기, Release 문서 작성
    ├── jenkins_deploy.py   배포 실행, 완료 대기
    ├── redmine_issue.py    일감 생성, 상태 변경
    └── fill_mail.py        메일 채우기

SKILL.md에는 언제 쓰는지와 어떤 순서로 하는지만 짧게 적는다. 바뀐 모듈 찾기, 버전 올리기, Jenkins 배포, Redmine 일감 처리 같은 실제 작업은 스크립트가 한다. 모델이 하는 일은 아래 한 줄을 실행하고 결과 몇 줄을 읽는 것이다.

$ python scripts/jenkins_deploy.py --module api
{"module": "api", "status": "SUCCESS",
 "s3": "auto-deploy/.../api-5.34.0.zip"}

• 스크립트 없이: 모델이 매번 API 호출 코드를 새로 짜고 Jenkins 로그와 Redmine 응답 원문을 Context에 그대로 읽어 들인다. 토큰이 많이 들고 결과도 매번 조금씩 다르다.
• 스크립트로: 모델은 스크립트를 실행하고 요약된 결과 몇 줄만 읽는다. 스크립트 코드는 Context에 들어가지 않고 결과는 매번 같다.

Anthropic의 Skill 작성 가이드도 같은 이야기를 한다.

Utility scripts can be executed through bash without loading their full contents into context. Only the script's output consumes tokens

유틸리티 스크립트는 내용 전체를 Context에 불러오지 않고 bash로 실행할 수 있다. 토큰은 스크립트가 출력한 만큼만 든다.

출처: Anthropic, Skill authoring best practices

그래서 판단이 필요한 곳은 모델이 맡고 정해진 일은 스크립트가 맡는다.

일곱 단계가 Skill 네 번으로

단계	전	후
업무 전달	사람	사람
일감 생성	Redmine에 직접 입력	/manage-redmine
구현과 코드 확인	IntelliJ에서 파일을 오가며 확인	/implement-readable-code
API 테스트	Postman에서 직접 작성	구현 요청에 포함
커밋과 푸시	GitHub	/commit-push
개발 서버 배포	Jenkins 확인 후 Redmine 수정	커밋 요청에 포함
운영 배포	버전, Release 문서, SQL, S3, 일감, 메일을 직접 처리	/deploy-release

업무를 전달받는 건 그대로 사람이다. 나머지는 도구를 열지 않고 요청 몇 줄로 간다. 일곱 단계가 Skill 호출 네 번으로 줄었고 반나절 붙잡고 있던 운영 배포는 계획을 읽고 승인 한 번 하는 일이 됐다.

Skill 다음은 프로세스

표를 다시 보면 단계 수는 그대로다. 나는 회사의 일원으로서 주어진 업무 프로세스 안에서 할 수 있는 만큼 자동화했다. 단계를 없애지는 않았지만 단계마다 들던 수고는 크게 줄었다.

그래도 생산성은 여기서 더 끌어올릴 수 있다고 생각한다. 그러려면 도구 자동화에서 한 걸음 더 나아가 업무 프로세스도 조금씩 함께 바꿔 갈 필요가 있다.

그 가능성을 Anthropic의 사례에서 봤다. 나는 도구를 옮겨 다니지 않으려고 AI 쪽으로 갔는데 Anthropic은 반대로 AI를 일하는 자리로 데려왔다. 사내 메신저인 Slack의 채널에 Claude를 둔다. 이야기하던 스레드에서 동료를 부르듯 @Claude로 일을 맡긴다.

• 오간 대화가 그대로 맥락이 된다: Claude는 스레드의 대화를 읽고 일을 이어받는다. 도구마다 같은 정보를 다시 넣던 내 방식과 반대다.
• 진행과 결과를 팀이 같이 본다: 채널 하나에 Claude 하나가 모두와 일하기 때문에 누구나 지금 무슨 일을 하는지 볼 수 있다. 내 화면 안에서 끝나지 않고 채널에 남는다.

Anthropic 발표 기준으로 제품팀 코드의 65%가 이 방식으로 만들어진다. 마케팅 자료의 법무 검토는 하루 이상 걸리던 것이 한 건에 30분으로 줄었다. 일부 업무가 빨라진 게 아니라 팀이 일하는 방식이 바뀌었다.

출처: Anthropic, Introducing Claude Tag, Claude, How Anthropic employees use Claude Tag

물론 한 번에 바꿀 수 있는 일은 아니다. 지금의 프로세스에는 그렇게 자리 잡은 이유가 있고 무엇을 바꿀지는 팀이 함께 정할 일이다. 나는 Skill로 반복을 덜어 낸 경험을 팀과 나누는 것부터 시작하려 한다.

주어진 프로세스 안에서는 Skill로 최대한 덜어 내고, 그다음은 팀과 함께 조금씩 바꿔 간다.