Codex 스킬과 업무용 도구 설계

스킬과 도구를 적용한 사례

반복 업무에서 두 가지를 살폈다.

• 기능 요청을 어떤 순서로 읽고 쓸지 스킬에 적어 두면, 구현할 사람이 필요로 하는 조건이 덜 빠지는가.
• 사용할 도구와 허용 범위를 정해 두면, 요청한 경로 안에서 필요한 결과를 얻을 수 있는가.

도구와 스킬의 역할

GitLab API는 이슈를 찾고, 등록하고, 저장된 내용을 다시 읽는 도구다. 언제 기존 이슈를 찾아야 하는지, 기능 요청에 어떤 내용을 적어야 하는지, 게시 후 무엇을 대조해야 하는지는 스킬에 적는다. SKILL.md에 작업 방법을 쓰고 필요하면 작성 양식이나 실행 스크립트를 함께 둘 수 있다. OpenAI 스킬 문서

구성	GitLab 이슈 작성 예시
도구	이슈 목록 조회, 본문 등록·수정, 저장 결과 조회
스킬	중복 이슈 검색, 관련 코드 읽기, 조작별 예상 동작 작성, 게시 결과 대조
개별 요청	대상 프로젝트, 변경할 기능, 초안 작성 또는 실제 등록

이슈 번호로 저장된 글을 다시 읽거나 첨부 링크가 열리는지 확인하는 일은 스크립트가 맡을 수 있다. 요청을 해석하고 기존 코드와 맞지 않는 부분을 찾는 일은 Codex가 맡는다. 스킬에는 어느 단계에서 어떤 입력을 읽고, 다음 단계에 무엇을 넘길지 적는다.

GitLab 이슈 작성 결과 비교

프로젝트나 그룹을 삭제하기 전에 비활성으로 전환하고, 모든 배포 서비스가 정지됐을 때만 그 전환을 허용하는 요청이었다. 같은 이슈의 초기 본문과 수정 본문은 동일한 모델과 추론 설정으로 작성했다. 초기 작성에도 등록용 스킬을 사용했다.

본문에 담긴 정보	초기 작성	수정 후
요청과 적용 범위	요청 요약과 조건 4개	프로젝트·그룹별 조건, 기존 동작과 바꿀 부분
사용자 조작	조작 시나리오 0개	상황, 조작, 예상 동작을 연결한 시나리오 9개
구현 후 점검	점검 항목 0개	구현 뒤 확인할 점검 항목 10개

수정한 이슈에는 개발자가 구현할 동작이 구체적으로 들어갔다.

• 그룹에 실행 중인 배포가 하나라도 있으면 비활성 전환을 막고, 어느 프로젝트에 어떤 서비스가 남았는지 알린다.
• 배포가 없는 경우, 서비스 정지에 실패한 경우, 실행 상태를 읽지 못한 경우의 처리 방법을 적는다.
• 기존 프로젝트를 활성으로 표시할 때에는 프로젝트의 관리 상태만 바꾼다. 배포 서비스의 실행 상태는 그대로 둔다.

초기 스킬은 이슈를 검색해 API로 게시하는 데 필요한 절차를 담고 있었다. 수정할 때는 기능 요청 작성 규칙을 보강했고, 사용자가 고른 이슈 예시와 프로젝트 코드, 별도 초안 검토도 함께 반영했다. 스킬 지침의 효과만 보려면 같은 자료와 검토 방법을 두고 스킬 버전만 바꿔 비교해야 한다.

CloudStack 배포 조회에 사용한 경로

사내 CloudStack에서 같은 프로젝트의 배포와 IP를 두 환경에서 조회했다.

• 첫 실행은 API로 몇 분 안에 프로젝트 1개, 실행 중으로 표시된 배포 5개, 설정과 일치하는 할당 IP 4개를 찾았다. 이어서 관리 화면까지 열었고, 사용자가 API만 쓰라고 지시한 뒤 실행이 중단됐다.
• 다른 Mac에서의 실행은 CloudStack 스킬을 직접 지정했다. API로 같은 배포와 IP를 읽어 표로 정리하고, IP가 없는 배포도 표시했다.

두 실행에서 확인한 차이는 요청한 API 경로로 보고까지 마쳤는지였다. 첫 실행의 API 조회도 수 분 안에 끝났다. 전체 작업 시간에는 실행 환경, 브라우저 조사, 중단 여부가 함께 영향을 미쳤다. 시간을 비교하려면 같은 환경에서 조회를 반복하고, 요청한 시점부터 결과를 검토할 때까지의 시간을 재야 한다.

관리 API의 배포 상태만으로 웹 접속이나 애플리케이션 내부 연결까지 알 수는 없다. 별도 구성 조사에서는 관리 API로 배포와 IP를 확인하고, 사용자가 허용한 읽기 전용 SSH로 데이터베이스 연결을 확인했다. GitLab에서도 이슈 등록은 API로 처리했고, 사용자가 따로 요청한 토큰 발급에는 브라우저를 사용했다. 목적마다 사용할 경로와 그 경로에서 읽을 수 있는 정보를 적어 두면 불필요한 조회를 줄일 수 있다.

반복 업무에 맞는 도구 설계

1. 되풀이하는 일을 찾는다. 업무 기록에서 같은 조회, 대조, 실행을 여러 번 한 곳을 찾는다.
2. 사람의 손이 자주 가는 일부터 고른다. 반복 횟수와 소요 시간, 직접 검사할 항목, 실패했을 때 다시 해야 하는 일을 살핀다.
3. 입력과 결과를 한 문장으로 적는다. 예를 들어 프로젝트 이름을 받아 배포 상태와 할당 IP를 반환하도록 한다.

업무	도구가 수행할 동작	검토할 결과
프로젝트 상태 파악	프로젝트·배포·할당 IP 읽기	배포별 상태, IP 일치 여부, 미설정 항목
서비스 재시작	지정한 배포 재시작, 상태 재조회	요청 접수, 이후 상태, 접속 검사 범위
GitLab 이슈 등록	이슈 검색·등록·재조회	이슈 번호, 저장된 본문, 첨부 열림 여부
강의 실습 검사	실습 노트북 셀 실행, 출력 대조	실패한 셀, 예상값과 실제값

조회와 변경에는 같은 API 연결 코드를 쓸 수 있다. 호출하는 동작은 구분한다.

• 조회에는 프로젝트 이름이나 ID를 받는다. 재시작에는 정확한 배포 ID와 변경 권한이 필요하다.
• 이름이 중복되거나 대상이 없을 때, 권한이 부족하거나 목록 일부만 읽었을 때에는 그 상태를 결과에 표시한다.
• 변경 요청을 보낸 뒤 연결이 끊기면 대상을 다시 읽는다. 변경이 이미 적용됐는지 살핀 뒤 재시도를 결정한다.

프로젝트 이름을 받아 배포와 할당 IP를 읽는 도구를 만든다. 같은 이름의 프로젝트가 여러 개면 후보를 반환한다. 주소가 없으면 미설정으로 표시한다. 정상 조회, 이름 중복, 권한 부족을 각각 시험한다.

스킬에 남길 작업 방법

같은 수정 요청을 여러 번 했다면, 그때 다시 설명한 내용을 스킬에 옮길 수 있다.

• GitLab 이슈에는 기능을 허용하거나 막는 조건과 사용자가 보게 될 결과를 적는다.
• 강의자료를 만들 때는 이전 주차의 실습과 풀이 파일을 살피고, 새 답안 코드를 실행해 예상 출력과 대조한다.
• 영상 제작 요청에서는 생성 버튼을 눌러 접수하는 일과 완성 영상을 받아 전달하는 일을 나눠 적는다.

스킬에 적용할 업무, 읽어야 할 자료, 허용할 변경, 완료를 확인할 방법을 적는다. 새 대화에서 정상 요청과 대상이 모호한 요청, 조회만 필요한 요청을 각각 실행해 본다.

Codex는 요청에 스킬을 직접 지정했거나, 요청 내용이 스킬 설명과 맞을 때 스킬을 불러올 수 있다. CLI와 IDE 확장에서는 $스킬이름으로 직접 지정한다. 자동으로 고르게 하려면 설명에 적용할 업무와 범위를 적는다. 사내 CloudStack 스킬은 allow_implicit_invocation: false로 설정해 직접 지정할 때 불러오도록 했다. OpenAI 스킬 호출 문서

사용자별 성과 비교 방법

팀에서 반복하는 일은 공통 스킬에 작업 방법을 넣어 함께 쓸 수 있다. 개인 업무에 필요한 절차는 별도로 추가한다. 같은 도구를 함께 사용하려면 실행 환경과 계정 권한도 맞춰야 한다.

개인별 차이를 알아보려면 같은 모델과 작업 자료를 두고 스킬 없이 한 실행, 팀 공통 스킬을 쓴 실행, 개인 스킬을 쓴 실행을 비교한다.

• 첫 결과를 바로 쓸 수 있었는가. 다시 고치지 않고 실제로 사용한 실행의 비율을 기록한다.
• 몇 번 더 지시했는가. 빠진 내용을 채우거나 잘못된 동작을 바로잡기 위해 사람이 보낸 지시를 센다.
• 일을 마치는 데 얼마나 걸렸는가. 처음 요청한 때부터 검토와 재작업이 끝날 때까지 잰다.

GitLab 사례에서는 구현할 동작을 더 구체적으로 설명했고, CloudStack 사례에서는 요청한 API 경로로 보고까지 마쳤다. 사용자별 생산성 차이를 판단하려면 여러 사람이 같은 조건에서 반복해서 실행한 결과가 필요하다.

연재 개요 · Codex 활용 방식에 따른 작업 성과 차이