소개
시도하고자 했던 것과 그 이유를 알려주세요.
Agent Skill 만들기 수업을 들으며 직접 Skill을 만들어보려고 했습니다.
처음에는 법규사항이나 일부 업무 지침만 있으면 Agent가 바로 업무를 도와줄 수 있을 것이라고 생각했습니다. 그래서 Skill을 만들기 위한 절차와 프롬프트를 먼저 설계해보았습니다.
하지만 실제로 Agent와 대화하며 Skill을 구성하려고 하니, 생각보다 많은 질문이 나왔습니다.
Code· text
이 업무는 언제 시작되는가?
어떤 자료를 입력으로 보는가?
좋은 결과물의 기준은 무엇인가?
어떤 경우에 Agent가 멈춰야 하는가?
어떤 판단은 사용자가 직접 해야 하는가?
반복되는 업무 중 Skill로 만들 만한 것은 무엇인가?처음에는 이런 질문들이 단순히 Skill 작성을 위한 준비 단계라고 생각했습니다. 그런데 대화를 이어가다 보니, 사실 이 질문들에 대한 답이 곧 업무 wiki가 되어야 한다는 것을 알게 되었습니다.
특히 SIF 유형과 통제 기준을 정리하려고 할 때 이 점을 크게 느꼈습니다. Agent가 “잠재적 SIF 요인은 무엇인지”, “각 요인의 핵심 통제는 무엇인지”, “사업장 방문 시 무엇을 확인해 야 하는지”를 물었는데, 막상 답하려고 보니 제 머릿속에는 있어도 문서나 wiki로 정리되어 있지 않았습니다.
즉, 이번 작업에서 실제로 완성된 것은 거대한 wiki가 아니라, Agent가 던지는 질문에 답하면서 어떤 내용을 wiki로 쌓아야 하는지 깨닫게 된 과정이었습니다.
그리고 그 wiki를 바탕으로 Agent Skill을 조금씩 깎아가야 한다는 점을 배웠습니다.
진행 방법
어떤 도구를 사용했고, 어떻게 활용하셨나요?
Tip: 사용한 프롬프트 전문을 꼭 포함하고, 내용을 짧게 소개해 주세요.
Tip: 활용 이미지나 캡처 화면을 꼭 남겨주세요.
Tip: 코드 전문은 코드블록에 감싸서 작성해주세요. ( / 을 눌러 '코드 블록'을 선택)
ChatGPT와 Hermes Agent를 함께 사용했습니다.
처음에는 work-context-interviewer Skill을 활용해, Agent가 사용자의 업무를 단계적으로 인터뷰하고 Skill 후보를 정리하는 구조를 실험했습니다.
처음 생각한 흐름은 다음과 같았습니다.
Code· text
setup
→ workflow
→ data-plan
→ skill-candidate
→ skill-spec
→ create-skill
→ verify-skill하지만 실제로 진행하면서 흐름이 바뀌었습니다.
바로 Skill을 만드는 것이 아니라, Agent가 던지는 질문에 답하면서 업무 기준을 정리하는 과정이 먼저 필요했습니다.
실제 흐름은 아래에 가까웠습니다.
Code· text
Agent와 업무 인터뷰
→ Agent가 필요한 기준과 데이터를 질문
→ 사용자가 답변하면서 빈틈 발견
→ wiki로 쌓아야 할 항목 확인
→ 반복 업무와 판단 기준 정리
→ Skill 후보를 천천히 구체화사용한 프롬프트의 핵심은 다음과 같았습니다.
Code· text
한 번에 질문을 많이 하지 말고,
가장 중요한 질문을 1~3개씩만 해줘.
사용자의 답변을 바로 Skill로 만들지 말고,
확인된 사실, Agent의 추론, 추가로 필요한 자료를 구분해줘.
새로운 반복 업무가 나오면
Context / Connector / Permission / Script / Bundle / Skill 중
어떤 방식이 적절한지 먼저 판단해줘.
사용자 승인 전에는 Skill을 만들거나 수정하지 말고,
먼저 업무 맥락과 필요한 wiki 항목을 정리해줘.실제로 드러난 빈틈
예를 들어 경영진 보고서 프레임을 만들던 중, SIF 통제 기준이 필요했습니다.
Agent는 다음과 같은 데이터를 요구했습니다.
Code· text
잠재적 SIF 요인:
주요 공정/작업:
핵심 통제:
사업장 방문 시 확인할 것:
미흡 시 조치:제가 예시로 답한 내용은 이렇습니다.
Code· text
잠재 SIF 요인: 끼임
주요 공정/작업: 컨베이어 벨트 교체 작업
핵심 통제: LOTOTO
방문 시 확인할 것: LOTOTO 절차 준수 여부이 답을 하면서 알게 된 것이 있습니다. 저는 업무적으로는 이런 내용을 알고 있었지만, Agent가 반복적으로 활용할 수 있는 형태로 정리해둔 wiki는 없었습니다.
그리고 미흡 시 조치 기준도 대화하면서 더 명확해졌습니다.
Code· text
미흡 시 조치는 최소 엔지니어링 통제 이상을 우선 검토한다.
교육, 표지, 절차, TBM 등 관리적 통제만으로 종결하지 않는다.이런 기준은 Skill 안에 바로 박아 넣기보다, 먼저 업무 wiki에 쌓여 있어야 했습니다. 그래야 Agent가 나중에 다른 사례를 만나도 같은 기준으로 판단할 수 있기 때문입니다.
흐름도
처음 생각은 단순했습니다.
Code· text
법규/지침 정리
→ Skill 만들기
→ Agent가 업무 지원하지만 실제로 해보니 흐름은 달랐습니다.
Code· text
Skill을 만들려고 시도
→ Agent가 질문
→ 답하려다 보니 정리 안 된 기준 발견
→ 이 질문과 답변을 wiki로 축적
→ 축적된 wiki를 바탕으로 Skill을 조금씩 구체화더 짧게 표현하면 이렇습니다.
Code· text
Skill을 먼저 만드는 것이 아니라
질문에 답하며 wiki를 쌓고
그 wiki 위에서 Skill을 깎아가는 과정결과와 배운 점
배운 점과 나만의 꿀팁을 알려주세요.
과정 중에 어떤 시행착오를 겪었나요?
도움이 필요한 부분이 있나요?
앞으로의 계획이 있다면 들려주세요.
이번 작업을 통해 배운 점은, Agent Skill은 빈 화면에서 바로 만드는 것이 아니라는 점입니다.
처음에는 법규사항이나 일부 지침만 있으면 충분할 줄 알았습니다. 하지만 실제로는 Agent가 판단하기 위해 더 많은 맥락이 필요했습니다.
예를 들면 다음과 같은 것들입니다.
Code· text
이 업무가 언제 시작되는지
어떤 입력을 봐야 하는지
좋은 결과물의 기준은 무엇인지
어떤 판단은 사용자가 해야 하는지
어떤 기준은 아직 정리되어 있지 않은지
어떤 내용을 wiki에 쌓아야 하는지특히 이번 작업에서 가장 크게 느낀 것은, Agent의 질문이 단순한 질문이 아니라는 점입니다.
Agent가 계속 묻는 질문은 귀찮은 확인 절차가 아니라, 제가 아직 wiki로 정리하지 못한 업무 기준을 드러내는 과정이었습니다.
그래서 앞으로는 Skill을 만들기 전에 다음을 먼저 하려고 합니다.
text
Agent가 던지는 질문을 기록한다.
답변 가능한 것은 wiki에 정리한다.
답변이 막히는 부분은 업무 기준이 아직 정리되지 않은 영역으로 본다.
반복해서 쓰이는 기준은 wiki에 쌓는다.
충분히 반복되고 절차화된 부분만 Skill로 만든다.
이번 실습은 하나의 완성된 Skill을 만드는 과정이라기보다, 질문을 통해 업무 wiki를 만들고, 그 위에서 Skill을 깎아가는 방법을 배운 과정이었습니다.
앞으로의 계획
앞으로는 Agent가 질문한 내용을 기반으로 업무 wiki를 조금씩 쌓아가려고 합니다.
예상되는 wiki 항목은 다음과 같습니다.
Code· text
업무 개요
반복 업무
판단 기준
보고서 기준
SIF 유형과 통제 기준
Agent 행동 경계
검증 사례그다음 반복해서 사용되는 업무만 Skill 후보로 전환할 계획입니다.
Code· text
질문
→ 답변
→ wiki 축적
→ 반복 패턴 발견
→ Skill 후보화
→ 검증
→ Skill 개선이 방식이라면 처음부터 완벽한 Skill을 만들려고 부담을 느끼기보다, 대화하면서 업무 기준을 정리하고, 그 기준을 바탕으로 Skill을 조금씩 다듬어갈 수 있을 것 같습니다.
도움 받은 글 (옵션)
참고한 지피터스 글이나 외부 사례를 알려주세요.
22기 리서치하네스 교육을 다시 보기로 듣고 있습니다.
관련된 팁을 많이 주시면 너무 감사하겠습니다.
