빠른 설정

Styles
  -> 톤, 문체, 표현 경향 저장

custom instructions
  -> 반복 운영 규칙, 형식, 우선순위 저장

prompt 본문
  -> 이번 작업의 목적, 입력, 제약, 산출물

스타일 고정

Styles와 custom instructions를 나눠야 출력이 안정되는 이유

Styles는 결과물의 톤과 표현 방식을 더 안정적으로 맞추는 도구입니다. 간결한 문체, 설명형 문체, 업무용 톤처럼 반복되는 스타일을 저장해 두면 매번 말투를 길게 다시 적지 않아도 됩니다. 하지만 스타일만으로 모든 요구를 해결할 수는 없습니다. 형식, 포함 항목, 근거 수준, 표 구조처럼 작업별 규칙은 여전히 custom instructions나 프롬프트 안에서 명시해야 합니다. 이 두 가지를 구분하지 않으면 스타일에 작업 규칙이 섞여서 나중에 무엇이 톤이고 무엇이 규칙인지 흐려집니다.

custom instructions가 Styles보다 구체적인 운영 규칙에 맞는 이유

custom instructions는 스타일보다 더 구체적인 운영 규칙을 담는 곳입니다. "표로 요약", "근거 우선", "한국어 기술 문체", "짧은 결론 먼저"처럼 반복적으로 적용할 출력 규칙이 잘 맞습니다. 이런 규칙을 Styles 안에 넣으면 같은 스타일을 다른 작업에 쓸 때 의도치 않게 특정 형식이 강제되거나, 스타일을 수정할 때 규칙까지 함께 사라지는 문제가 생깁니다.

Styles
  -> 말투
  -> 문체
  -> 표현 톤

custom instructions
  -> 출력 순서
  -> 포함 항목
  -> 우선순위

반복 기준과 작업별 요구를 분리해야 재사용이 가능한 이유

핵심은 "반복적으로 유지할 기준"과 "이번 작업에만 필요한 조건"을 분리하는 것입니다. Styles와 custom instructions는 재사용되는 기준을 담고, 프롬프트 본문은 작업별로 바뀌는 목적, 입력, 제약, 산출물을 담는 역할을 합니다. 이 구분이 잘 되면 스타일은 다양한 작업에 재사용되고, 프롬프트는 작업별로 바뀌어도 충돌이 적어집니다.

스타일 하나에 모든 것을 밀어넣으면 생기는 문제

스타일에 작업 규칙까지 전부 넣으면 나중에 스타일을 수정할 때 어떤 항목이 톤에 관한 것이고 어떤 항목이 출력 계약에 관한 것인지 파악하기 어렵습니다. 또한 같은 스타일을 서로 다른 성격의 작업에 적용하면 규칙이 충돌해 예상치 못한 출력이 나올 수 있습니다. 스타일은 말투와 표현 경향만 담고 작업 규칙은 custom instructions나 프롬프트 본문에 두는 편이 관리하기 쉽습니다.

어디에 넣을까

주의할 점

❌ Style 이름: "기술 문체"
내용: "표로 정리하고, 위험도부터 쓰고, 5줄 이하로 답해라"

이렇게 되면 문체와 출력 계약이 한 덩어리가 됩니다. 재사용성이 급격히 떨어집니다.