다크 모드
요청 작성
채팅 결과는 요청에 포함된 맥락, 목적, 출력 형식에 크게 영향을 받습니다. 반복해서 사용할 업무라면 먼저 채팅에서 요청 방식을 검증한 뒤 에이전트나 워크플로우로 옮기는 것을 권장합니다.
채팅으로 검증할 것
에이전트나 워크플로우를 만들기 전에는 채팅에서 실제 업무 요청을 먼저 검증하는 것이 좋습니다.
| 확인할 항목 | 설명 |
|---|---|
| 지시문 | 역할, 목적, 출력 형식이 충분히 명확한지 확인합니다. |
| 모델 | 응답 품질, 속도, 비용을 고려해 적절한 모델을 고릅니다. |
| 도구 | 필요한 MCP 도구, 에이전트, 워크플로우를 @mention으로 직접 호출해 봅니다. |
| 결과 형식 | 표, 목록, JSON, 보고서 형식처럼 원하는 출력이 안정적으로 나오는지 확인합니다. |
| 예외 상황 | 정보 부족, 도구 오류, 검색 결과 없음 같은 상황에서 적절히 되묻는지 확인합니다. |
같은 요청 패턴을 여러 번 반복한다면 에이전트나 워크플로우로 옮겨 재사용하세요.
좋은 요청 작성하기
| 포함할 내용 | 예시 |
|---|---|
| 목적 | "고객에게 보낼 답변 초안을 작성해줘." |
| 배경 | "고객은 환불 정책을 문의했고, 구매일은 7일 전이야." |
| 제약 조건 | "정중한 톤으로 쓰고, 확정되지 않은 내용은 단정하지 마." |
| 출력 형식 | "제목, 핵심 답변, 후속 확인 사항 순서로 정리해줘." |
| 사용할 도구 | "@정책검색으로 먼저 관련 정책을 확인해줘." |
예시
@문서작성에이전트를 사용해 "다음 회의 메모를 실행 항목 중심으로 정리하고, 담당자/기한/리스크를 표로 만들어줘"처럼 요청하면 역할과 출력 형식이 함께 전달되어 결과가 안정적입니다.
응답 검증 기준
중요한 업무에 채팅 결과를 사용할 때는 다음 항목을 확인하세요.
| 항목 | 확인 방법 |
|---|---|
| 출처 | 문서나 외부 도구를 사용한 경우 어떤 정보를 근거로 답했는지 확인합니다. |
| 최신성 | 날짜, 가격, 정책처럼 바뀔 수 있는 정보는 도구 조회 또는 원문 확인을 요구합니다. |
| 누락 | 요청한 조건과 출력 형식이 모두 반영되었는지 확인합니다. |
| 실행 가능성 | 후속 조치가 실제 업무 단계로 옮길 수 있을 만큼 구체적인지 확인합니다. |
| 민감 정보 | 공유 전에 개인정보, 토큰, 내부 전용 정보가 포함되지 않았는지 확인합니다. |