사용자 정의 Agent Skill과 안전한 실행 설계

01 배경

회의록 정리처럼 사용자마다 반복하는 작업이 달라, 개발자가 전부 미리 만들 수는 없었습니다. 또 AI가 만든 편집안이 요청 일부를 빠뜨리거나 문장을 어색하게 바꾼 채 사용자에게 넘어갔고, 코드의 형식과 범위 검사만으로는 걸러내지 못했습니다. 결국 안정적인 서비스를 제공할 수 없게 되고, 항상 같은 출력을 원하는 작업을 운에 맡기게 되면 사용자가 불편함을 겪습니다. 또 사용자가 API 비용을 선결제해서 사용하는 결제 구조상, 다시 결제하기 싫어질 이유가 될 수도 있었습니다.

02 판단과 구현 과정

1. 사용자 정의 작업 지침의 작성과 게시 기능 구현

   문제 상황 회의록 정리처럼 사용자마다 반복하는 작업이 달라, 개발자가 모두 미리 만들어 둘 수는 없었습니다. 하지만 사용자가 반복된 작업을 매번 같은 요청 프로세스를 반복하도록 만드는 것은 사용자로서 불편하다고 생각했습니다.

   판단 기능을 하나씩 늘리는 대신, 사용자가 자연어로 작업 지침을 정의하고 다시 쓰게 하기로 했습니다. AI가 만든 지침은 사용자가 검토하기 전까지 제안으로만 다룹니다.

   구현 자연어 요청을 다시 쓸 수 있는 Markdown Skill로 정리했습니다. 사용자가 초안을 검토하고 수정해 게시할 때 Skill과 버전을 저장합니다. 게시한 Skill은 덮어쓰지 않고 불변 버전으로 덧붙이고, 실행할 버전을 가리키는 포인터를 따로 뒀습니다. 어떤 실행이 어느 버전을 썼는지 추적할 수 있고, 새 버전에 문제가 생겨도 이전 정의가 남습니다.

   확인한 결과 작성 단계에서는 아무것도 저장하지 않는지, 게시하면 새 버전이 생기고 실행 버전이 그쪽을 가리키는지, 다른 워크스페이스나 /명령으로도 게시한 Skill을 불러오는지 단위 테스트로 확인했습니다. 기능을 마쳤을 때 Skill 모듈 74개와 파이프라인 전체 546개 테스트를 통과했습니다.

2. 작업 지침의 권한과 승인 우회 방지 검증

   문제 상황 지침과 참고 문서에 개인정보나 승인을 건너뛰라는 지시가 섞이면 문서가 승인 없이 바뀌거나 정보가 샐 수 있었습니다. 표현도 제각각이고, 초안은 게시 전에 다시 고쳐질 수 있었습니다.

   판단 명확한 위험과 권한 검사는 코드가 맡고, 표현을 바꾼 우회 의도는 LLM으로 찾았습니다. 검토 뒤에도 내용이 바뀔 수 있으므로 이전 검사 결과만으로 게시를 허용하지 않았습니다.

   구현 입력과 참고 문서에 규칙 검사를 적용하고, LLM이 지적한 위험 문구가 원문에 정말 있는지 서버에서 대조했습니다. 참고 문서는 권한과 원문을 검사한 뒤 필요한 구조만 모델에 넘겼습니다. 최종 게시 때는 고친 내용으로 다시 검사합니다. 위험 문구는 자동으로 지우지 않고, 사용자가 재생성을 고른 경우에만 뺀 뒤 결과를 다시 검사합니다.

   확인한 결과 승인 우회와 권한 상승 등 6가지 유형의 위험 문구 25개와 개인정보 및 인증 정보를 규칙으로 검사합니다. '승인 없이 관련 문서를 이동한다' 같은 지시가 모델 호출 전에 막히는지, LLM이 짚은 문구의 위치가 원문과 같은지, 최종 게시 때 넣은 이메일이 저장 없이 막히는지를 테스트로 확인했습니다. 막히면 원문과 문제 위치를 보여 줘, 사용자가 직접 고치거나 재생성을 고를 수 있습니다.

3. 변경 미리보기와 사용자 승인 후 반영

   문제 상황 Skill을 게시했더라도, 할루시네이션으로 인해 사용자가 원치 않은 방식으로 생성, 편집, 정리되는 경우 이를 다시 복구하기 위해 롤백을 하러가야하는 경우가 생길때마다 사용자가 불편함을 겪을 수 있습니다. 따라서 실행할 때 바뀔 문서와 내용은 따로 확인받아야 했습니다.

   판단 지침 게시와 실제 문서 변경은 승인을 따로 받기로 했습니다. 작업 분류는 라우터가, 실행은 실행기가 맡되, 무엇이 바뀌는지는 사용자가 확인합니다.

   구현 편집은 수정 전후 차이를, 폴더 정리는 만들 폴더와 옮길 문서를 계획으로 보여 줬습니다. 출력 형식과 수정 범위는 코드로 검사하고, 승인한 변경만 실행합니다.

   확인한 결과 문서 6개로 계획, 승인, 실행을 해 보니, 승인 전에는 아무것도 바뀌지 않았고 승인 뒤에 주제별 폴더 3개가 생기고 문서가 옮겨졌습니다.

4. 대화 맥락과 편집 입력의 범위 결정

   문제 상황 대화가 길거나 편집할 문서가 크면 모델 입력이 늘어, 사용자가 부담하는 비용과 대기 시간이 커집니다. 그래서 무엇을 남기고 무엇을 자를지 정해야 했습니다.

   판단 대화는 최근 메시지 6개(질문과 답 약 세 번)만 원문으로 두고, 그 이전은 누적 요약으로 압축했습니다. 편집은 문서 전체 대신 대상 줄 범위와 주변 문맥만 보내고, 표나 코드 블록 경계에 걸치는 범위는 거절했습니다.

   구현 최근 메시지가 6개가 되면 기존 요약과 최근 메시지를 함께 넣어 누적 요약을 갱신합니다. 요약 호출이 실패하면 요약을 바꾸지 않아 대화가 끊기지 않습니다. 라우터에는 요약과 최근 메시지에 이전 턴의 라우팅 결정까지 넘겨, '그거'처럼 가리키는 말의 대상을 이전 턴에서 찾게 했습니다. 편집 입력은 대상 줄 범위에 위아래 문맥 줄을 붙여 자르고, 구조 경계를 걸치는 범위는 예외로 막았습니다.

   확인한 결과 1,000줄 문서에서 모델에 보낸 입력은 원문의 5.58%, 5,000줄에서는 1.12%였고, 입력을 만드는 시간의 p95는 각각 7.7ms, 34.4ms였습니다. 표, 코드 블록, 수식에 일부만 걸치는 범위가 거절되는지도 테스트했고, 실제 HTTP 요청에서 코드 블록 일부를 고른 요청은 422로 막혔습니다.

5. LLM 실행 추적과 민감정보 경계 설정

   문제 상황 평가 루프가 평범한 Python 흐름이라 의미 추출, 평가, 보정, 재시도를 단계별로 볼 수 없었습니다. 그렇다고 추적을 켜면 도구 조회 원문과 개인정보가 외부 추적 도구로 나가 보안에 취약해지는 문제가 있었습니다.

   판단 생성, 평가, 재시도를 단계별로 보려고 품질 루프는 LangGraph 노드 단위로 추적하고, 사용자 문서를 다루는 Agent 그래프는 추적을 끄고 원문을 상태에 남기지 않았습니다.

   구현 평가 루프를 LangGraph 그래프로 다시 짜서 응답 생성, 평가, 재시도를 각각의 노드로 드러냈습니다. 추적 설정이 켜져 있어도 키가 없으면 실행은 그대로 하고 추적만 건너뛰어, 경고와 불필요한 네트워크 재시도를 없앴습니다. Agent 그래프는 추적을 끄고 도구 조회 원문을 상태 저장에서 뺐고, 보관 기간이 끝나면 저장 상태를 실행 기록보다 먼저 지웁니다. 직접 남기는 프롬프트 로그는 기록 전에 숫자 개인정보를 마스킹합니다.

   확인한 결과 요청을 실제로 실행해 그래프 노드와 모델 호출 구간이 추적에 잡히는지 확인했습니다. 시간을 재는 실험은 추적과 프롬프트 로그를 모두 끄고 돌려, 계측 부담이 측정값에 섞이지 않게 했습니다.

03 개선한 처리 흐름

flowchart TD
 U[사용자가 반복 작업을 자연어로 정의] --> S[Skill 초안 작성, 개인정보 마스킹 및 Prompt Injection  검사]
 S --> P[사용자 검토, 게시 시 재검사]
 P --> K[재사용할 작업 지침 저장]
 Q[사용자 문서 작업 요청] --> R[라우터가 작업과 조건 결정]
 K -. 필요한 작업에 활용 .-> R
 R --> E[편집 실행, 목적과 범위 유지]
 R --> F[폴더 정리 계획, 요청과 대조]
 E --> V[형식과 수정 범위 한정 개인정보 마스킹 및 Prompt Injection  검사]
 V --> D[통과한 수정안과 변경점 표시]
 F --> D
 D --> A{사용자 승인}
 A -->|승인| W[문서 수정 또는 폴더 정리 실행]
 A -->|취소| N[원본 유지]

flowchart TD
 U[사용자가 반복 작업을 자연어로 정의] --> S[Skill 초안 작성, 개인정보 마스킹 및 Prompt Injection  검사]
 S --> P[사용자 검토, 게시 시 재검사]
 P --> K[재사용할 작업 지침 저장]
 Q[사용자 문서 작업 요청] --> R[라우터가 작업과 조건 결정]
 K -. 필요한 작업에 활용 .-> R
 R --> E[편집 실행, 목적과 범위 유지]
 R --> F[폴더 정리 계획, 요청과 대조]
 E --> V[형식과 수정 범위 한정 개인정보 마스킹 및 Prompt Injection  검사]
 V --> D[통과한 수정안과 변경점 표시]
 F --> D
 D --> A{사용자 승인}
 A -->|승인| W[문서 수정 또는 폴더 정리 실행]
 A -->|취소| N[원본 유지]

04 결과와 배운 점

사용자 정의 작업과 승인 흐름 구현, 편집 품질 82.5% → 91.2%(114건 평가)

사용자가 반복 작업을 직접 정의해 Skill로 게시하고 다시 쓸 수 있게 했습니다. 게시할 때는 최종 내용을 다시 검사하고, 실제 문서 변경은 미리보기와 사용자 승인을 거칩니다. 문서 6개로 폴더 정리를 계획, 승인, 실행해 정상 작동함을 확인했습니다. 편집 품질은 19종 요청에서 나온 초안 114개를 회귀셋으로 고정해 비교했습니다. 잘못된 검사 규칙과 재시도 입력을 고치고, 요청 충족과 의미 보존을 따로 평가해 실패 이유와 함께 한 번만 다시 쓰게 해 94개를 104개로 높였습니다. 평가 루프의 효과만 보려고 코드 수정만 넣은 대조군도 함께 쟀고, 대조군은 98개였습니다. 평가에서 정상인 경우까지 거부하는 문제는 생성과 평가 프롬프트를 분리해 해결했고, 다시 실패하면 수정안을 반환하지 않도록 구현했습니다. AI는 작업 지침과 수정안을 쓰고, 코드는 권한과 실행 범위를 검사하고, 사용자는 게시와 최종 반영을 결정하도록 책임을 나눴습니다.