한 문장 요약
저는 짧은 부탁을 실행 가능한 프롬프트로 바꿔 주는 task-prompt-builder를 만들고, 공지와 링크 요약에 실제로 사용하면서 질문 방식, 내부 검증, 글의 길이와 말투를 고쳤습니다.
이런 분께 도움이 됩니다
• AI에게 짧게 부탁한 뒤 조건을 계속 덧붙이고 계신 분
• 반복 업무를 자신만의 Skill로 만들고 싶은 분
• 첫 결과보다 실제 사용과 수정을 중요하게 생각하는 분
짧은 공지 요청에서 시작했습니다
저는 도도치에게 이렇게 부탁했습니다.
공지사항 초안 써줘. 도도치 말투로.
제가 원한 것은 공지문 하나가 아니었습니다.
짧은 부탁을 받으면 현재 대화에서 아는 조건을 먼저 활용하고, 꼭 필요한 것만 물은 뒤, 다른 에이전트도 실행할 수 있는 프롬프트로 바꿔 주는 Skill이 필요했습니다. 질문은 결과를 바꾸는 것만 1~3개 묻기로 했습니다.
도도치는 task-prompt-builder를 만들고 설치한 뒤 저장된 본문을 다시 확인했습니다. 저는 목적과 질문 정책을 정했고, 도도치는 Skill 작성과 검증을 맡았습니다.
첫 실행에서 질문 방식을 고쳤습니다
첫 실험은 에이전트 하네스 카카오톡방의 온라인 모각 공지였습니다.
도도치는 공지 대상, 핵심 내용, 일정, 링크를 물었습니다. 저는 일요일 Google Meet 모각과 참여 요청을 답했지만 시간과 링크는 빠뜨렸습니다.
질문은 두 개뿐이었지만 한 질문에 여러 값을 묶어 답하기 어려웠습니다. 도도치는 질문 수를 늘리는 대신 아래처럼 답변 틀을 보여 주도록 Skill을 고쳤습니다.
• 대상
• 핵심 내용
• 날짜와 시간
• 링크
빠진 값은 추측하지 않고 [확인 필요]로 남겼습니다.
프롬프트 안에도 수정 루프를 넣었습니다
저는 도도치에게 생성된 프롬프트 자체에 루프 엔지니어링이 들어 있는지 물었습니다.
Skill 설명에 루프를 적는 것과 실제로 만들어지는 프롬프트가 첫 결과를 관찰하고 다시 고치게 하는 것은 다른 일이었습니다.
수정된 v0.2.0은 다음 순서로 작동하도록 바뀌었습니다.
1. 예상 결과를 정합니다.
2. 안전하게 첫 실행을 합니다.
3. 가장 큰 문제 한 곳만 고칩니다.
4. 같은 입력으로 다시 확인합니다.
실제 발송이나 게시처럼 영향이 있는 행동은 반복하지 않도록 분리했습니다.
공지 초안을 실행해 보니 필요한 내용은 있었지만 날짜와 링크가 문장 속에 붙어 있어 읽기 불편했습니다. 두 항목만 별도 줄로 나눈 뒤 같은 입력으로 다시 실행하니 카카오톡에서 훑기 쉬운 공지가 됐습니다. 실제 발송은 하지 않았습니다.
Tailscale 링크로 두 번째 실험을 했습니다
다음에는 링크를 주면 에이전트 하네스 스터디원에게 도움이 되는 요약 글을 만드는 프롬프트를 요청했습니다.
첫 프롬프트는 필요한 조건을 빠짐없이 담았지만 너무 길었습니다. 그래서 실행에 필요한 내용만 남겨 압축했습니다.
실제 입력으로 Tailscale 홈페이지를 주었습니다. 도도치는 공식 홈페이지와 문서를 확인해 요약했지만 결과가 또 길었고, 내부 검증용 루프 기록까지 글에 붙였습니다.
저는 이렇게 교정했습니다.
너무 길어.
그리고 루프 기록은 출력하는 게 아니야, 도도치야 😭
더 쉬운 용어로 써줘.
도도치는 루프를 없애지 않았습니다. 대신 내부에서만 검증하고, 요청하지 않으면 최종 글에 보이지 않게 했습니다.
스터디원용 글은 친근한 존댓말, 짧은 문장, 쉬운 용어를 기본으로 쓰도록 Skill에도 반영했습니다. v0.2.1 본문을 다시 불러 실제 저장 상태도 확인했습니다.
사용하면서 Skill이 달라졌습니다
이번 작업에서 저는 완성된 Skill을 한 번에 받은 것이 아닙니다.
실제 요청을 넣고 결과를 읽은 뒤 불편한 지점을 말했습니다. 도도치는 그 피드백을 다음 실행에도 남는 규칙으로 바꿨습니다.
확인된 변화는 다음과 같습니다.
• 여러 값을 물을 때 답변 틀을 제공합니다.
• 모르는 시간과 링크는 추측하지 않습니다.
• 생성된 프롬프트가 첫 결과를 관찰하고 한 곳을 고칩니다.
• 루프 기록은 내부에 남기고 최종 글에서는 숨깁니다.
• 스터디원용 결과는 짧고 쉬운 존댓말로 작성합니다.
새 세션에서 Skill 이름을 말하지 않아도 자연스럽게 선택되는지는 아직 확인하지 않았습니다. 공지와 Tailscale 요약도 외부 채널에 게시하지 않았습니다.
제가 배운 점
Skill은 문서를 한 번 잘 쓰는 것으로 끝나지 않았습니다.
실제 업무를 넣어 봐야 질문이 답하기 어려운지, 결과가 너무 긴지, 내부 기록이 사용자에게 새어 나오는지 알 수 있었습니다.
저는 목적과 기준을 정하고 결과를 판단했습니다. 도도치는 그 판단을 Skill 규칙과 검증 가능한 변경으로 남겼습니다.
이렇게 역할을 나누니 한 번의 피드백이 다음 요청의 기본값으로 이어졌습니다.
다음 실험
새 세션에서 평소처럼 짧게 부탁해 task-prompt-builder가 자연스럽게 선택되는지 확인해 보려고 합니다.
선택되지 않는다면 Skill 전체를 다시 쓰기보다 설명과 사용 조건부터 살펴볼 계획입니다.
