홍드로이드의 야매코딩

AI 답이 매번 달라질 때 — 지시보다 예시가 낫습니다 본문

AI & Vibe Coding

AI 답이 매번 달라질 때 — 지시보다 예시가 낫습니다

홍드로이드 2026. 9. 4. 20:12
반응형

AI를 코드에 붙여 본 사람이면 다 겪는 일이 있습니다. 어제는 잘 되던 게 오늘은 모양이 다릅니다. 항목 순서가 바뀌거나, 안 시킨 인사말이 앞에 붙거나, 목록이었던 게 문장이 되어 있죠. 그러면 뒤에서 받아 처리하는 코드가 조용히 깨집니다. 공식 문서에 일관성을 높이는 방법이 정리돼 있는데, 여러 기법 중 문서가 콕 집어 강조하는 게 하나 있습니다 — 형식을 말로 설명하는 것보다 예시를 보여 주는 쪽이 더 효과적이라는 겁니다.

📌 30초 요약

  • 추상적인 지시보다 예시가 효과적입니다. 문서가 직접 그렇게 씁니다.
  • 형식이 반드시 지켜져야 한다면 프롬프트로 풀지 마세요. 전용 기능이 따로 있습니다.
  • 이 페이지에 남아 있는 답변 첫머리 채우기는 최신 세대에서 막혔습니다.
  • 근거를 고정하면 답도 고정됩니다. 같은 자료를 참조하게 만드세요.
  • 복잡한 일은 쪼개세요. 각 조각이 온전한 주의를 받습니다.

1. 왜 매번 달라지나

원인은 대체로 셋 중 하나입니다. 첫째 형식을 정해 주지 않았다. "정리해 줘"라고만 하면 정리하는 방식은 매번 모델이 고릅니다. 둘째 참조할 근거가 매번 다르다. 같은 질문이라도 그때그때 다른 지식에서 끌어오면 답도 흔들립니다. 셋째 한 번에 너무 많은 걸 시켰다. 분류하고 요약하고 다음 행동까지 한 번에 뽑으라 하면 어느 하나가 흐려집니다.

그래서 문서의 처방도 그 셋에 대응합니다 — 형식을 정확히 지정하고, 예시로 못 박고, 근거를 고정하고, 일을 쪼개라. 순서대로 보겠습니다.

2. 지시보다 예시가 낫습니다

가장 실용적인 대목입니다. 문서의 표현이 단정적입니다 — "원하는 출력의 예시를 제공하라. 이것이 추상적인 지시보다 더 효과적이다."

무슨 뜻이냐면, "각 항목은 50자 내외 요약과 강점·약점을 포함해서 정리해 줘"라고 길게 설명하는 대신, 그렇게 정리된 결과물 한 덩어리를 통째로 보여 주고 "이 형식으로 해"라고 하는 편이 훨씬 잘 지켜진다는 것입니다. 사람에게 일을 넘길 때도 규정집보다 지난번 산출물 하나를 보여 주는 게 빠른 것과 같습니다.

형식 자체도 눈에 보이는 틀로 주는 게 좋습니다. 문서 예시들은 빈칸이 뚫린 서식을 통째로 제시하는 방식을 씁니다 — 채워 넣을 자리에 자리표시자를 두고, 반복되는 부분에는 말줄임을 찍어 두는 식이죠. 프롬프트 기법을 하나씩 익혀 왔다면 이건 그중에서도 비용 대비 효과가 가장 확실한 한 가지입니다.

3. 이 문서는 자기 기법을 스스로 앞질렀습니다

흥미로운 건 이 페이지가 맨 위에 단서를 달고 시작한다는 점입니다. 요지는 이렇습니다 — 정해진 틀에 맞는 결과가 "보장"돼야 한다면, 아래 프롬프트 기법들 말고 전용 기능을 쓰라는 것.

⚠️ 한 페이지 안에 유통기한이 다른 조언이 섞여 있습니다

이 페이지의 두 번째 기법은 답변 첫머리를 미리 채워 형식을 강제하는 방법인데, 바로 그 자리에 "최신 세대 모델에서는 지원되지 않는다"는 주석이 붙어 있습니다. 즉 지금 쓰면 요청이 거부되는 기법이 본문에 그대로 남아 있는 겁니다. 문서를 위에서 아래로 읽으며 그대로 따라 하면 중간에서 막히죠. 공식 문서라도 페이지마다, 심지어 한 페이지 안에서도 갱신 시점이 다릅니다. 주석 상자를 건너뛰지 마세요.

정리하면 우선순위는 이렇습니다. 형식이 반드시 지켜져야 하는 자리라면 전용 기능을 먼저 보고, 그 틀에 딱 맞지 않는 유연한 일관성이 필요할 때 이 페이지의 기법들을 씁니다. 출력 형식을 손대는 기능이 여럿이라 헷갈리기 쉬운데, 말투를 바꾸려다 다른 규칙까지 통째로 갈아치우는 사고도 같은 혼동에서 나옵니다.

4. 프롬프트 밖에서 푸는 방법

일관성 문제를 프롬프트 문장으로만 풀려는 게 흔한 실수입니다. 문서는 구조로 푸는 방법도 함께 제시합니다.

방법 언제 쓰나 효과
형식을 눈에 보이게 지정 항목이 정해진 결과물 빠진 항목·순서 뒤바뀜이 줄어듦
예시로 못 박기 거의 항상 말로 설명하는 것보다 잘 지켜짐
근거를 고정 상담 봇·사내 지식 검색 같은 질문에 같은 근거 → 같은 답
일을 쪼개서 잇기 한 번에 여러 작업 각 조각이 온전한 주의를 받음
역할을 자세히 부여 캐릭터가 있는 서비스 말투가 중간에 안 흐트러짐

근거 고정은 특히 상담 봇에서 효과가 큽니다. 답을 모델의 기억에 맡기지 않고 정해진 자료 묶음에서만 끌어오게 하면, 같은 질문에 늘 같은 안내가 나갑니다. 문서 예시는 여기에 한 겹을 더 얹는데 — 어느 항목을 근거로 삼았는지도 함께 출력하게 만듭니다. 그러면 답이 이상할 때 어디서 틀어졌는지 바로 보이죠.

역할 유지에도 요령이 있습니다. 성격·배경·버릇까지 자세히 적어 두면 모델이 그 인물을 더 잘 일반화하고, 흔히 마주칠 상황과 그때의 답변 방향을 목록으로 미리 주면 예상 밖 질문에도 캐릭터가 안 깨집니다. 정확성이 생명인 분야일수록 이런 고정이 중요합니다 — 보안처럼 검증이 핵심인 영역에서는 답이 매번 다르면 맞는지 틀린지 판단하는 것 자체가 불가능해집니다.

5. 자주 묻는 질문 (FAQ)

Q. 예시를 몇 개나 넣어야 하나요?

문서 예시들은 하나로 시작합니다. 형식이 단순하면 한 개로 충분하고, 경우에 따라 답이 갈리는 작업이면 서로 다른 상황의 예시 두세 개가 낫습니다. 다만 예시도 매번 함께 보내는 입력이라 길어질수록 값이 오릅니다 — 늘리기 전에 하나로 충분한지 먼저 확인하세요.

Q. 형식을 지정했는데도 가끔 어겨요.

프롬프트로 하는 지정은 강한 권유이지 보장이 아닙니다. 어기면 안 되는 자리라면 정해진 틀을 강제하는 전용 기능으로 옮기세요. 그게 안 되는 상황이면 받는 쪽에서 검사해 실패 시 한 번 더 요청하는 안전망을 두는 게 현실적입니다.

Q. 쪼개면 요청 수가 늘어서 더 비싸지 않나요?

요청 수는 늘지만 각 요청이 짧아집니다. 그리고 한 번에 다 시켜서 결과가 어긋나면 통째로 다시 돌려야 하니 오히려 손해인 경우가 많습니다. 앞부분이 반복된다면 그 부분을 캐시에 태워 값을 더 낮출 수도 있고요.

Q. 일관성이 좋아졌는지 어떻게 확인하나요?

같은 질문을 여러 번 돌려 답이 얼마나 벌어지는지 재면 됩니다. 표현이 달라도 뜻이 같으면 통과로 볼지, 형식까지 똑같아야 통과로 볼지를 먼저 정하세요. 이 기준을 정해 두는 것이 곧 평가를 만드는 일입니다.

✨ 정리하면

답이 매번 달라진다면 말로 더 자세히 설명하지 말고 예시를 보여 주세요. 그다음은 셋 — 보장이 필요하면 전용 기능으로, 근거는 고정하고, 복잡한 일은 쪼개세요. 그리고 이 문서를 읽을 때 하나만 조심하면 됩니다 — 한 페이지 안에도 이미 막힌 기법이 섞여 있습니다. AI에 드는 돈이 새는 자리를 순서대로 훑고 싶다면 AI 지출 관리 허브에 단계별로 모아 뒀습니다.

※ 2026년 9월 기준 공식 문서(출력 일관성 높이기 안내)를 바탕으로 정리했습니다. 본문에서 짚었듯 이 페이지에는 최신 세대 모델에서 이미 막힌 기법이 주석과 함께 남아 있으니, 적용 전 쓰는 모델의 안내 문서를 함께 확인하세요. FAQ의 "받는 쪽에서 검사해 재요청" 부분은 동작 원리에 근거한 권고입니다.

반응형
Comments