<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Prompt Engineering | The .NET Blog</title><link>https://thedotnetblog.com/ko/tags/prompt-engineering/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>ko</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Fri, 17 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/ko/tags/prompt-engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>VS Code의 GPT-5.5 프롬프트 튜닝이 가혹한 진실을 증명합니다: 하네스 설계가 과대광고를 이깁니다</title><link>https://thedotnetblog.com/ko/news/emiliano-montesdeoca/gpt-5-5-prompt-tuning-vscode-less-wandering/</link><pubDate>Fri, 17 Jul 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/ko/news/emiliano-montesdeoca/gpt-5-5-prompt-tuning-vscode-less-wandering/</guid><description>VS Code의 GPT-5.5 실험은 측정 가능한 이득이 단순히 새로운 기반 모델로 교체하는 것이 아니라, 규율 있는 하네스와 프롬프트 반복에서 비롯됨을 보여줍니다.</description><content:encoded>&lt;p&gt;VS Code의 GPT-5.5 튜닝 포스트에서 가장 가치 있는 부분은 승리한 변형이 아닙니다. 방법론입니다. 명확한 가설, 통제된 처리, 라이브 트래픽 측정, 가드레일 메트릭은 정확히 프로덕션 환경에서 에이전트 품질이 개선되어야 하는 방식입니다.&lt;/p&gt;
&lt;p&gt;원문: &lt;a href="https://code.visualstudio.com/blogs/2026/07/06/optimizing-vscode-coding-harness-model-providers"&gt;https://code.visualstudio.com/blogs/2026/07/06/optimizing-vscode-coding-harness-model-providers&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;핵심 아이디어는 간단했습니다: 탐색적 드리프트를 줄이고 편집 후 더 일찍 검증하는 것입니다. 그것은 당연해 보이지만, 흥미로운 발견은 하네스 레이어의 구조적 프롬프트 가이드가 주요 품질 붕괴 없이 지연 시간, 꼬리 토큰 사용량, 도구 호출 수에서 통계적으로 강력한 개선을 이끌었다는 것입니다.&lt;/p&gt;
&lt;p&gt;내 의견은 직설적입니다: &lt;strong&gt;모델 업그레이드만 쫓는 조직은 쉬운 성능 및 비용 이득을 테이블 위에 남겨두고 있습니다.&lt;/strong&gt; 하네스 동작과 시스템 프롬프트 설계는 사용량 기반 청구가 관련될 때 특히 모델 교체보다 비즈니스 메트릭을 더 빠르게 움직일 수 있습니다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Treatment B가 이긴&lt;/strong&gt; 이유는 검색 제약뿐만 아니라 전체 루프를 공식화했기 때문입니다. 모델이 국소적 반증 가능한 가설을 세우고, 근거 있는 첫 편집을 수행하며, 즉시 집중 검증을 실행하도록 유도했습니다. 그 순서는 좋은 인간 엔지니어가 시간 압박 아래 디버깅하는 방식을 반영합니다.&lt;/p&gt;
&lt;h3 id="이-접근법에서-복사할-점"&gt;이 접근법에서 복사할 점&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;품질 가드레일을 사전에 정의&lt;/strong&gt;한 다음, 그 제약 조건 내에서 지연 시간과 비용을 최적화하세요.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;중앙값과 꼬리 동작 모두를 측정&lt;/strong&gt;하세요. 첫 편집까지의 시간 및 토큰 사용량의 p95 개선은 실제 사용자 만족도를 위해 p50 승리보다 종종 더 가치 있습니다.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;오프라인 평가에만 과적합하지 마세요.&lt;/strong&gt; VS Code 팀은 오프라인 검사를 사용한 다음, 라이브 트래픽에서 출시 전에 검증했습니다. 실제 워크플로가 합성 벤치마크가 놓치는 동작을 노출시키기 때문에 그 순서가 중요합니다.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;한 가지 트레이드오프는 주목할 가치가 있습니다: 단기 생존 메트릭의 약간의 움직임. 팀은 이를 올바르게 처리하여 효과 크기와 유의성을 더 강력하고 고도로 유의미한 효율성 이득과 대비했습니다. 이것은 메트릭 체리픽이 아닌 성숙한 의사 결정입니다.&lt;/p&gt;
&lt;p&gt;더 넓은 교훈은 &lt;strong&gt;전략적&lt;/strong&gt;입니다. 프롬프트 엔지니어링은 &amp;ldquo;프롬프트 마법&amp;quot;이 아닙니다. &lt;strong&gt;제품 엔지니어링&lt;/strong&gt;입니다: 가설, 실험, 통제, 배포 게이트. 이 루프를 운영화하는 팀은 지속적으로 개선할 것입니다. 소셜 미디어에서 모델 순위에 대해 논쟁하는 팀은 그렇지 않을 것입니다.&lt;/p&gt;
&lt;h2 id="결론"&gt;결론&lt;/h2&gt;
&lt;p&gt;다가오는 해에 개발자 AI의 경쟁 우위는 특정 모델 제품군에 대한 접근보다는 &lt;strong&gt;누가 이 최적화 루프를 안정적으로 실행할 수 있는지&lt;/strong&gt;에서 더 많이 나올 것입니다. VS Code의 결과는 실용적인 청사진입니다: 관찰, 가설 수립, 테스트, 출시, 반복.&lt;/p&gt;</content:encoded></item></channel></rss>