기호를 넣기 전에 무엇을 나눌지 생각하기

AI에 지시할 때 샤프나 괄호를 써야 할지 고민한 적이 있나요?

기호는 지시의 묶음을 나누거나 자료의 시작과 끝을 표시하는 데 사용할 수 있습니다.

다만 기호 자체가 정답을 보장하는 것은 아니며 같은 기호도 사용 장소나 서비스에 따라 역할이 달라집니다.

이 글에서는 일상적인 요청을 통해 기호를 쓰는 이유와 입력 방법, 사용 전 확인할 점을 차례로 살펴봅니다.

기호를 넣기 전에 무엇을 나눌지 생각하기

프롬프트는 AI에 해 주길 원하는 일을 전달하는 글입니다.

짧은 일상 요청이라면 특별한 기호 없이도 전달할 수 있습니다.

이 문장은 부탁할 일이 하나이므로 우선 그대로 시도할 수 있습니다.

반면 전달할 자료나 지켜야 할 조건이 늘어나면 요청이 어디까지이고 자료가 어디서 시작하는지 작성자도 파악하기 어려워집니다.

요청과 자료를 별도 묶음으로 만들기

동네 도서실의 독서 모임 담당자가 직원용 메모를 바탕으로 참가자에게 보낼 안내문을 만드는 상황을 생각해 봅시다.

메모는 다음과 같습니다.

이 정보를 사용해 처음 참가하는 사람에게 보낼 글을 만들고 싶다고 가정합니다.

요청, 조건, 메모를 이어 쓸 수도 있지만 다음처럼 제목을 붙이면 각 부분의 역할을 사람이 확인하기 쉽습니다.

여기서 #는 제목을 나타내는 데 사용했습니다.

중요한 것은 기호를 늘어놓는 것보다 요청·조건·자료의 역할을 구분하는 것입니다.

개최 연도와 도서실 주소는 메모에 없으므로 실제 안내를 보낼 때는 담당자에게 확인한 뒤 추가합니다.

기호를 추가해도 자료에 없는 것은 알 수 없다

제목이 있어도 AI가 메모에 없는 장소의 주소를 정확히 안다는 보장은 없습니다.

지시를 정리해도 AI가 반드시 조건대로 답한다는 보장 역시 없습니다.

답변을 쓰기 전에 참가비와 날짜·시간 등을 원래 메모와 대조해야 합니다.

샤프와 하이픈으로 제목과 항목 정리하기

#와 -는 글의 묶음을 만들 때 간단히 쓸 수 있는 기호입니다.

이 기호들은 글에 제목과 목록을 표시하는 작성 방식인 마크다운에서 사용됩니다.

표시는 서비스마다 다르므로 기호가 서식으로 보이지 않더라도 내용을 구분할 목적으로 쓸 수 있습니다.

제목으로 묶음에 이름 붙이기

다음은 독서 모임 안내에 필요한 요청과 조건을 나눈 예시입니다.

# 뒤에 반각 공백(ASCII 스페이스)을 넣고 제목을 씁니다.

제목을 붙이면 요청의 역할을 살펴보기 쉽지만 제목만으로 내용의 의미가 정해지는 것은 아닙니다.

예를 들어 조건이라고 써도 내용이 비어 있으면 어떤 조건을 지켜야 하는지 전달되지 않습니다.

하이픈으로 나란한 항목 나열하기

안내에 포함할 정보를 확인하려면 항목을 나열할 수 있습니다.

- 뒤에도 반각 공백(ASCII 스페이스)을 넣습니다.

이 네 가지는 하나를 고르는 후보가 아니라 안내에 넣어야 할 나란한 항목입니다.

항목을 나열해도 각각의 내용이 자료에서 정확히 추출됐는지는 알 수 없으므로 답변과 메모를 비교합니다.

순서가 중요하면 숫자 사용하기

AI에 작업 순서를 알려 주고 싶을 때는 번호 목록을 쓸 수 있습니다.

이 예시는 정보를 추출하고 안내문을 만든 뒤 마지막으로 부족한 정보를 표시하는 순서입니다.

실제 답변이 그 순서대로 정리됐는지와 추출한 정보가 원래 메모와 일치하는지도 확인합니다.

인용 부호로 자료로 읽을 부분 표시하기

짧은 자료를 지시 안에 넣을 때는 인용 부호로 감쌀 수 있습니다.

여기서는 일본어의 낫표 「 」 대신 입력란에 쓸 수 있는 큰따옴표 "를 예로 듭니다.

한 문장만 전달할 때

독서 모임 메모의 다음 문장을 알기 쉽게 바꾸고 싶다고 가정합니다.

요청에서 바꿔 쓸 대상을 인용 부호로 감쌀 수 있습니다.

인용 부호는 무엇을 바꿔 쓸지 구분하는 표시입니다.

이 기호를 넣어도 참가비나 신청 방법이 바뀌지 않았는지 확인해야 합니다.

대상 안에도 같은 기호가 있을 때

자료에 같은 인용 부호가 있으면 바깥쪽 경계를 구분하기 어려울 수 있습니다.

같은 기호를 억지로 겹치기보다 제목이나 뒤에서 소개할 이름 있는 태그처럼 다른 구분법을 선택할 수 있습니다.

서비스나 연동 대상의 형식이 정해져 있다면 해당 명세를 따르세요.

긴 자료는 시작과 끝 표시하기

여러 줄의 자료를 전달할 때 범위를 명확히 하면 사람이 요청을 다시 볼 때도 도움이 됩니다.

방법은 하나가 아니며 구분선이나 이름 있는 태그 등을 사용할 수 있습니다.

구분선 사용하기

예를 들어 하이픈 세 개를 한 줄에 놓고 메모 앞뒤에 배치할 수 있습니다.

여기서 ---는 독자가 메모의 경계를 구분하기 위한 표시입니다.

자료 안에도 같은 구분선이 있다면 끝이 모호해지므로 다른 기호나 방법을 선택합니다.

이름 있는 태그 사용하기

또 다른 방법으로 자료 앞뒤를 태그로 감쌀 수 있습니다.

<memo>가 시작이고 </memo>가 끝입니다.

태그 이름 memo는 여기서 자료의 역할을 나타냅니다.

시작과 끝에 같은 이름을 쓰면 사람이 경계를 따라가기 쉽습니다.

태그로 감싸도 내용이 안전하다거나 그 안의 지시가 반드시 무시된다는 보장은 없습니다.

자료 속 지시와 요청을 혼동하지 않기

외부에서 받은 글에 요청과 관계없는 명령이 포함될 수 있습니다.

예를 들어 행사 메모에 다음 문장이 들어갔다고 가정합니다.

이 문장은 참가자 안내에 필요한 행사 정보가 아닙니다.

자료를 자료로 취급하도록 요청하고 결과에 관계없는 내용이 섞였는지 확인하세요.

수상한 자료를 다룰 때는 구분 기호만을 보안 대책으로 생각하지 않는 것도 중요합니다.

이용 서비스의 설정과 데이터 접근 권한을 확인하고 중요한 작업은 사람이 판단합니다.

두 자료를 섞지 않고 다루기

기호의 역할을 이해했다면 자료가 여러 개인 상황에서도 사용해 봅시다.

같은 날 두 장소에서 열리는 행사의 안내문을 각각 만들고 싶다고 가정합니다.

두 장소 모두 날짜는 아직 알 수 없습니다.

자료를 한 문장으로 이어 쓰면 사람이 다시 읽을 때 시간과 참가비의 대응을 놓칠 수 있습니다.

그래서 장소별로 묶음을 나누고 대응 관계를 바꾸지 말도록 요청할 수 있습니다.

편집부가 준비한 교육용 답변 예시는 다음과 같습니다.

제목으로 장소를 나누면 장소별로 원래 자료와 답변을 비교할 수 있습니다.

하지만 제목을 붙인 것만으로 시간과 장소의 대응이 정확하게 유지된다는 보장은 없습니다.

실제 전송 전에는 장소명·시간·비용의 조합을 하나씩 대조합니다.

날짜를 모르면 참가자가 계획을 세울 수 없으므로 담당자에게 확인한 뒤 안내를 완성합니다.

자료의 제목과 요청의 제목이 겹칠 때

원래 자료에 # 장소 A 같은 제목이 있다면 요청에도 같은 기호를 쓸 때 자료의 시작을 구분하기 어려울 수 있습니다.

이때 자료 전체를 다른 이름의 태그로 감싸고 장소별 제목은 그대로 두는 방법이 있습니다.

중요한 것은 기호를 여러 개 겹치는 것 자체가 아니라 사람도 경계를 따라갈 수 있는 것입니다.

태그를 사용할 때는 시작과 끝의 이름을 맞추고 자료에 같은 종료 기호가 없는지도 확인합니다.

코드나 기호를 그대로 전달할 때 코드 펜스 사용하기

기호가 포함된 텍스트나 코드를 변경 없이 보여 주고 싶을 때가 있습니다.

마크다운에서는 백틱 세 개를 위아래에 놓는 코드 펜스를 사용할 수 있습니다.

다음은 AI에 전달할 입력 예시입니다.

다음 문자열에서 상품 번호를 변경하지 않고 번호만 추출해 주세요.

```
상품 번호: A-104
```

바깥쪽 표시용 틀이 아니라 상품 번호 앞뒤의 백틱 세 개로 된 줄이 입력에 쓰입니다.

표시 환경에 따라 바깥쪽과 안쪽 펜스가 충돌할 수 있으므로 실제 입력 시 펜스의 개수와 표시 형식을 확인합니다.

기대하는 결과는 A-104지만 AI가 반환한 문자열을 실제 번호와 대조해야 합니다.

코드 펜스는 문자열의 경계를 표시하는 방식이며 프로그램이 정확히 실행된다는 것까지 보장하지 않습니다.

대괄호로 나중에 바꿀 위치 표시하기

반복해서 쓰는 요청에서는 매번 바뀌는 정보를 대괄호로 표시하면 바꿀 위치를 찾기 쉽습니다.

[독자]와 [자료]는 입력 전에 바꿔 넣는 표시입니다.

완성된 프롬프트는 예를 들어 다음과 같습니다.

템플릿 사용 시 대괄호나 이전 자료가 남아 있지 않은지 확인합니다.

대괄호는 필수 형식이 아니며 팀이나 도구의 규칙에 따라 다른 표시를 사용해도 됩니다.

정해진 형식으로 받을 때 JSON 사용하기

결과를 프로그램에 전달할 때 등 JSON이라는 데이터 형식을 지정하는 경우가 있습니다.

JSON은 항목 이름과 값을 조합해 정보를 나타내는 형식입니다.

독서 모임 메모에서 날짜와 참가비를 추출하는 요청을 생각해 봅시다.

기대하는 형태의 교육용 예시는 다음과 같습니다.

{"date":"11월 14일","fee":"무료"}

중괄호 {}가 전체를 감싸고 "date"와 "fee"는 항목 이름입니다.

콜론 :은 이름과 값을, 쉼표 ,는 두 항목을 구분합니다.

문자열에 큰따옴표를 사용하는 것처럼 JSON에는 정해진 문법이 있습니다.

형태가 비슷해도 읽을 수 있는 것은 아니다

AI가 JSON처럼 답해도 괄호가 빠지거나 추가 문자가 있으면 받는 프로그램이 읽지 못할 수 있습니다.

사용할 프로그램에서 JSON으로 분석할 수 있는지와 필요한 항목이 있는지 검증하세요.

서비스에 따라 구조화 출력처럼 형식을 지정하는 전용 기능이 제공될 수 있습니다.

사용 가능한 기능과 설정은 서비스·모델·API마다 다르므로 최신 공식 문서를 확인합니다.

형식이 올바르더라도 날짜와 참가비의 내용이 정확하다는 보장은 없으므로 원래 메모와도 따로 대조합니다.

기호가 그대로 보일 때 확인할 점

입력란에 기호를 써도 서비스에 따라 제목이나 목록이 아닌 기호 그대로 보일 수 있습니다.

겉모습이 바뀌지 않아도 요청에 필요한 내용이 적혀 있는지 확인합니다.

샤프가 제목으로 표시되지 않을 때

예를 들어 입력란에 다음과 같이 썼다고 가정합니다.

전송 후 # 조건이 그대로 보여도 그것만으로 AI가 조건을 무시했다고 판단할 수 없습니다.

먼저 답변에 참가비와 준비물이 있는지 원래 메모와 대조합니다.

표시와 답변 내용은 별도로 확인해야 합니다.

서비스의 표시 방식을 바꿀 수 있는 경우도 있지만 설정과 조작은 서비스마다 다릅니다.

목록의 줄이 이어져 보일 때

입력한 줄바꿈이 잘 보이지 않아도 전송한 내용이나 답변을 보고 조건이 의도대로 전달됐는지 확인합니다.

줄바꿈 방법을 모른다면 사용하는 서비스의 안내를 확인하세요.

목록을 만들 수 없는 경우에도 한 문장에 조건을 분명히 나열할 수 있습니다.

목적은 기호 사용 자체가 아니라 무엇을 넣어야 하는지 명확히 전달하는 것입니다.

지시와 자료가 다르면 먼저 확인하기

기호로 깔끔하게 나눠도 두 부분의 정보가 다르다면 어느 쪽을 사용할지 결정해야 합니다.

예를 들어 다음 요청을 살펴봅시다.

조건과 메모의 시작 시간이 다릅니다.

안내문을 만들기 전에 정확한 시작 시간을 주최자에게 확인해야 합니다.

자료가 업데이트되지 않았는지 조건이 잘못됐는지는 이 두 줄만으로 알 수 없습니다.

확인 결과 오후 3시가 맞다면 요청과 메모를 같은 정보로 고칩니다.

이는 차이를 해결한 뒤의 요청을 짧게 보여 준 것입니다.

실제 안내문에는 날짜와 장소처럼 짧은 메모에 없는 정보도 확인해 추가해야 합니다.

기호를 선택한 뒤 확인할 점

사용할 기호를 정했다면 전송 전과 답변 후에 각각 간단히 확인할 수 있습니다.

전송하기 전

각 제목 아래에 알맞은 내용이 있는지, 자료의 경계가 닫혀 있는지 살펴봅니다.

태그를 썼다면 <memo>와 </memo>처럼 시작과 끝의 이름이 일치하는지 확인합니다.

템플릿을 썼다면 [자료] 같은 위치가 이번 자료로 바뀌었는지 확인합니다.

자료에 개인정보나 비밀 정보가 있다면 입력해도 되는지 소속 조직의 규칙과 서비스 설정을 확인합니다.

답변을 받은 후

먼저 요청 목적에 맞는 형태인지 보고, 날짜·시간·금액·상태 같은 중요한 내용을 원래 자료와 대조합니다.

JSON처럼 프로그램이 받는 형식이라면 프로그램에서 분석할 수 있는지도 별도로 검증합니다.

기호가 정돈돼도 내용이 정확하다는 보장은 없고, 내용이 맞아 보여도 기계가 받을 형식이라는 보장은 없습니다.

내용 확인과 형식 확인을 나누면 각각 필요한 점검을 할 수 있습니다.

같은 이름의 태그가 자료 안에 있을 때

태그를 사용할 때 감쌀 글 자체에 같은 종료 태그가 있는지도 확인합니다.

자료에서 </memo>라는 문자열을 설명할 때 그대로 같은 이름의 바깥 태그로 감싸면 사람이 경계를 놓칠 수 있습니다.

바깥쪽 역할을 알 수 있는 다른 이름을 사용할 수 있습니다.

바깥의 source_text는 시작과 끝이 일치하고 안쪽의 </memo>는 자료 속 문자열입니다.

이 방식도 AI가 경계를 반드시 지킨다는 보장은 아닙니다.

답변을 확인하고 필요하면 태그 이름을 바꾼 이유나 자료의 어느 부분을 다룰지 추가로 전달합니다.

XML로 엄격하게 분석하는 시스템에 전달할 때는 단순한 표시로 쓰는 경우와 달리 대상 시스템의 문법과 이스케이프 규칙을 따라야 합니다.

이 예시는 채팅에서 자료를 구분하는 설명이며 그대로 모든 XML 처리에 전달할 수 있다는 뜻은 아닙니다.

예를 들어 다른 도구가 XML로 읽는다면 글 속 <와 >를 그대로 전달할 수 있는지도 도구의 규칙에 달려 있습니다.

채팅에서 읽기 쉬운 것과 프로그램이 엄격한 형식으로 받는 것은 다르므로 연동 대상의 명세를 확인하세요.

예시를 복사할 때도 바깥과 안쪽이 각각 무엇을 뜻하는지 살펴본 뒤 사용합니다.

어떤 기호를 선택할까?

처음부터 모든 기호를 외울 필요는 없습니다.

무엇을 나누고 무엇을 나중에 확인할지에 따라 선택합니다.

• 제목: 요청, 조건, 자료의 묶음을 나눈다.
• 목록: 여러 조건이나 순서가 있는 작업을 나열한다.
• 구분선·태그: 자료의 시작과 끝을 나타낸다.
• 코드 펜스: 기호나 코드를 하나의 묶음으로 보여 준다.
• 대괄호: 템플릿에서 나중에 바꿀 위치를 표시한다.
• JSON: 정해진 데이터 형식으로 결과를 받는다.

자료에 필요한 정보가 빠져 있다면 기호를 추가하기 전에 그 정보를 확인해야 합니다.

상대에게 보내는 안내나 업무 판단에 답변을 쓸 때는 기호의 정돈 상태뿐 아니라 원래 자료·최신 정보·서비스 조건을 확인한 뒤 사용하세요.