Molayo

© 2026 Molayo

Dev.to헤드라인2026. 05. 27. 18:12

구조화된 프롬프트는 토큰 낭비를 35-40% 줄입니다. 이것이 실제로 중요한 지점입니다.

요약

구조화된 프롬프트 형식을 사용하면 비구조화된 방식 대비 토큰 사용량을 약 32-40% 절감할 수 있습니다. 하지만 토큰 절약보다 중요한 것은 작업의 성격에 따라 구조화가 일관성을 제공하는지, 혹은 유연성을 저해하는 오버헤드가 되는지를 판단하는 것입니다.

핵심 포인트

  • 구조화된 프롬프트는 토큰 사용량을 30% 이상 절감하여 비용 효율성을 높임
  • XML 태그와 명시적 필드 정의는 출력의 일관된 형태(Shape)를 보장함
  • 코드 생성 작업에서는 구조화된 형식이 압도적으로 유리함
  • 작업의 유연성이 필요한 경우 구조화된 형식이 오히려 제약이 될 수 있음

한 가지의 구조화된 프롬프트 형식. 두 개의 동일한 추론 (Reasoning) 작업. 동일한 모델. 비구조화된 방식 (Unstructured): 1,240 토큰. 구조화된 방식 (명시적 스키마 포함): 847 토큰. 32% 감소. 이것은 실제적이고, 반복 가능하며, 비용 로그에 나타나는 수치입니다. 하지만 이것은 쉬운 부분일 뿐입니다.

더 어려운 부분은 절약된 토큰이 '당신의' 작업에서 실제로 더 나은 답변으로 이어지는지 아는 것입니다. 그리고 언제 구조화가 도움이 되고, 언제 그것이 단순한 오버헤드 (Overhead)가 되는지를 아는 것입니다.

저는 지난 한 달 동안 Claude Sonnet 4.6을 대상으로 두 가지 형태의 동일한 프롬프트를 실행했습니다. 하나는 단계별 자연어 지침 (Natural language instructions)을 사용한 것이고, 다른 하나는 XML 태그와 명시적 필드 정의 (Explicit field definitions)를 사용한 것입니다. 코드 생성 (Code generation) 작업, 추론 (Reasoning) 작업, 다단계 워크플로우 (Multi step workflows)를 수행했습니다. 실제 패턴이 보여주는 결과는 다음과 같습니다.

비구조화된 기준점 (The Unstructured Baseline)

모델에 평이한 영어로 요청을 보낼 때, 모델은 당신이 원하는 형태를 추론해야 합니다. 이는 유연하지만, 동시에 모호하기도 합니다.

사용자 이메일 주소를 검증하고 도움이 되는 에러 메시지를 반환하는 함수를 작성하세요.

모델은 '무언가'를 내놓을 것입니다. 인라인 검증 (Inline validation)이 포함된 함수일 수도 있고, 헬퍼 클래스 (Helper class)일 수도 있습니다. 정규 표현식 (Regex) 주석일 수도 있고,

동일한 모델로 5회 실행한 결과, 모든 출력의 형태 (Shape)가 동일했습니다. 팩토리 함수 (Factory functions), 클래스 (Classes), 혹은 기타 부가적인 요소 없이 요청된 사항을 정확히 수행했습니다.

5회 실행 총 토큰 수: 4,235개. 회당 평균: 847개.

32% 감소했습니다. 모호함이 없습니다. 일관된 형태 (Consistent shape) 덕분에 변환 과정 없이 출력을 테스트 하네스 (Test harness)로 직접 파이프라인 연결 (Pipe)할 수 있었습니다.

실제 모습은 다음과 같습니다:

function validateEmail(email) {
 const atIndex = email.indexOf('@');
 if (atIndex === -1) {
...

모든 구조화된 실행은 정확히 이와 같은 형태를 생성했습니다. 비구조화된 실행 (Unstructured runs)은 동일한 로직을 생성했지만, 이를 다르게 감싸서(wrapped) 출력했습니다.

이것이 당신이 생각하는 것보다 덜 중요한 이유

여기 까다로운 부분이 있습니다. 토큰 (Tokens)이 전부는 아니라는 점입니다.

비구조화된 버전들이 객관적으로는 더 유연했습니다. 만약 제가 "함수를 작성하고 테스트 하네스 (Test harness)를 포함해달라"고 요청했다면, 세 가지 아키텍처 중 하나는 이를 아주 쉽게 수행했을 것입니다. 구조화된 형식은 너무 엄격하게 고정되어 있어서, 테스트를 요청하려면 두 번째 프롬프트 (Prompt)가 필요했습니다.

벤치마크 친화적인 지표 (절약된 토큰)는 실재합니다. 하지만 유용한 지표 (이 출력이 내 파이프라인에 직접 공급되는가?)는 문맥 (Context)에 따라 다릅니다. 작업에 따라 답이 달라지며, 가중치도 달라집니다.

구조화가 실제로 승리하는 경우

코드 생성 (Code generation) 작업에서는 구조화가 압도적으로 유리합니다. 형식 사양 (Format spec)이 있고, 모델이 이를 따르기를 원하기 때문입니다. 토큰은 줄어들고 일관성은 높아집니다.

다섯 가지 추론 (Reasoning) 작업(에세이 작성, 텍스트 분석, 브레인스토밍)에 대해 동일한 비교를 수행했을 때, 토큰 절감 효과는 여전히 나타났지만 (평균 29%), 품질 측면의 트레이드오프 (Tradeoff)가 관찰되었습니다. 구조화된 프롬프트는 추론을 더 좁은 경로로 가두었습니다. 일부 에세이는 더 정형화된 (Formulaic) 형태로 나왔습니다. 더 나쁘다기보다는, 단지 경계가 더 뚜렷해진 것입니다.

모델이 실제 추론 공간 (Reasoning space)을 탐색하는 대신 스키마 준수 (Schema compliance) 목표에 도달해 버린 것입니다.

코드의 경우: 스키마 준수가 곧 목표입니다. 추론의 경우: 때로는 그 무질서함 (Messiness) 자체가 핵심일 수 있습니다.

토큰 수학 (실제 수치)

현재 가격 (Sonnet 4.6 입력 $3/1M, 출력 $15/1M)을 기준으로, 평균 입력 토큰 2,000개, 평균 출력 800개일 때:

비구조화된 접근 방식 (Unstructured approach):

  • 입력 (Input): 2,000 tokens × ($3/1M) = $0.000006
  • 출력 (Output): 1,200 tokens × ($15/1M) = $0.000018
  • 호출당 (Per call): $0.000024
  • 100회 호출 시: $0.0024

구조화된 접근 방식 (Structured approach):

  • 입력 (Input): 2,000 tokens × ($3/1M) = $0.000006
  • 출력 (Output): 800 tokens × ($15/1M) = $0.000012
  • 호출당 (Per call): $0.000018
  • 100회 호출 시: $0.0018

차이: 100회 호출당 $0.0006. 가격 측면에서는 미미한 수준입니다. 하지만 지연 시간 (Latency) 측면에서는 (출력 토큰이 적을수록 더 빠르기 때문에) 훨씬 더 중요합니다.

만약 작업의 출력량이 정기적으로 4,000 토큰에 달한다면, 계산 결과는 갑자기 달라집니다. 4,000 토큰의 출력을 30% 줄여주는 구조화된 형식은 실제로 체감할 수 있는 비용 절감을 가져옵니다.

패턴 인식의 관점 (The Pattern Recognition Angle)

흥미로운 점은 출력 패턴을 통해 모델이 지시 사항을 어떻게 파싱 (Parse) 하는지 알 수 있다는 것입니다.

방대한 코드 데이터셋으로 학습된 모델은 수천 개의 함수 명세 (Function specifications)를 보아왔습니다. 여러분이 구조화된 명세 (이름, 입력 타입, 출력 타입, 제약 조건)를 보낼 때, 여러분은 모델이 이전에 보았던 패턴 인식 경로를 활성화하는 것입니다. 모델은 그 형태를 복제합니다. 빠르고, 일관되며, 토큰을 적게 사용합니다.

자연어 (Natural language)를 보낼 때, 모델은 처음부터 문맥 (Context)을 구축해야 합니다. 이는 더 느리고, 모호하며, 더 창의적입니다. 코드 작업의 경우 이는 오버헤드 (Overhead)가 됩니다. 추론 (Reasoning)의 경우, 때로는 그것이 핵심 목적이 되기도 합니다.

모델은 비구조화된 프롬프트를 통해 "추론"하는 것이 아닙니다. 제약이 덜한 패턴 세트에서 패턴 매칭 (Pattern matching)을 수행하는 것입니다. 이는 괜찮습니다. 다만 어떤 일이 일어나고 있는지는 알고 있어야 합니다. 구조화된 버전이 반드시 더 똑똑한 것은 아니며, 단지 더 좁은 목표를 향하고 있을 뿐입니다.

실무적인 조치 (The Practical Move)

대규모 코드 생성에서 비용을 최적화하고 있다면:

  • 구조화된 형식 (XML 또는 JSON schema)을 사용하세요.
  • 출력 형태와 타입 제약 조건을 미리 지정하세요.
  • 일관성은 유연성을 대가로 얻어진다는 점을 받아들이세요.

추론이나 분석 작업을 하고 있다면:

  • 실제 작업에 두 형식을 모두 테스트해 보세요.
  • 토큰 절약이 곧 더 나은 출력을 의미한다고 가정하지 마세요.
  • 벤치마크가 아니라 5~10회 실행을 통해 품질 차이 (Quality delta)를 관찰하세요.

"항상 프롬프트를 구조화하라"고 말하는 사람들은 코드에 대해서는 옳습니다. 하지만 그들은 또한 코드 중심적인 커뮤니티의 조언을 그대로 복사하고 있는 것이기도 합니다. 여러분의 작업(Task)에 직접 테스트해 보세요. 벤치마크의 성능 향상 (Benchmark lift)이 실제 유용성을 예측하지는 않습니다. 여러분의 데이터가 예측합니다.

Tags: #ai #tutorial #javascript #optimization

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0