GPT-4.1 모델군은 코딩, 지시 사항 준수, 그리고 긴 컨텍스트 처리 능력에 있어 GPT-4o 대비 상당한 발전을 이루었습니다.

이 가이드에서는 개발자들이 이 새로운 모델군의 향상된 능력을 최대한 활용할 수 있도록, 광범위한 내부 테스트에서 도출된 중요한 프롬프트 작성 팁들을 정리했습니다.

단순히 대화를 나누는 수준을 넘어, 이제 프롬프트는 정교한 소프트웨어를 '설계'하는 엔지니어링의 영역으로 진입하고 있습니다.
 
물론 컨텍스트 예시 제공, 지시 사항의 명확하고 구체적인 작성, 그리고 모델의 지능을 극대화하기 위한 계획 유도와 같은 기존의 모범 사례 대부분은 GPT-4.1에도 여전히 유효합니다.

하지만 이 모델의 잠재력을 최대한 이끌어내기 위해서는 어느 정도의 프롬프트 마이그레이션이 필요할 것으로 예상됩니다.

GPT-4.1은 이전 모델들보다 사용자의 지시를 더 면밀하고 문자 그대로 따르도록 훈련되었습니다.

이전 모델들은 사용자 및 시스템 프롬프트에서 의도를 더 자유롭게 추론하는 경향이 있었는데요.

이는 곧, GPT-4.1이 잘 명시된 프롬프트에 매우 순응적이고 반응성이 높다는 것을 의미합니다.

만약 모델의 행동이 예상과 다르다면, 원하는 행동을 확고하고 명확하게 설명하는 단 한 문장만으로도 모델을 올바른 방향으로 이끌기에 거의 항상 충분합니다.
 
이 글을 통해 참조할 수 있는 프롬프트 예시들을 살펴보시고, 이 가이드가 널리 적용 가능하지만 모든 경우에 통하는 만능 해결책은 아니라는 점을 기억해 주시기 바랍니다.

AI 엔지니어링은 본질적으로 경험적인 학문이며, 거대 언어 모델은 비결정적입니다.

이 가이드를 따르는 것과 더불어, 유용한 평가 지표를 구축하고 자주 반복 작업을 수행하여 프롬프트 엔지니어링 변경 사항이 여러분의 사용 사례에 실질적인 이점을 가져다주는지 확인하는 것이 중요합니다.
 
1. 에이전트 워크플로우
 
GPT-4.1은 에이전트 워크플로우를 구축하기에 아주 훌륭한 모델입니다.

모델 훈련 과정에서 우리는 다양한 에이전트적 문제 해결 경로를 제공하는 데 중점을 두었으며, 이 모델을 위한 저희의 에이전트 하네스는 SWE-bench Verified에서 추론 기능이 없는 모델 중 최첨단 성능을 달성하여 문제의 55%를 해결했습니다.
 
시스템 프롬프트 알림
 
GPT-4.1의 에이전트 능력을 완전히 활용하기 위해, 모든 에이전트 프롬프트에 세 가지 핵심적인 알림을 포함할 것을 권장합니다.

다음 프롬프트들은 특히 에이전트 코딩 워크플로우에 최적화되어 있지만, 일반적인 에이전트 사용 사례에 맞게 쉽게 수정할 수 있습니다.
 
첫째는 '지속성'에 대한 알림입니다.이는 모델이 다중 메시지 턴에 진입하고 있음을 이해하도록 보장하고, 모델이 사용자에게 너무 일찍 제어권을 넘겨주는 것을 방지합니다.

예시는 다음과 같습니다.'당신은 에이전트입니다. 사용자의 질의가 완전히 해결될 때까지 계속 진행한 후, 당신의 턴을 마치고 사용자에게 제어권을 넘겨주세요.

문제가 해결되었다고 확신할 때만 당신의 턴을 종료하세요.'
 
둘째는 '도구 호출'에 대한 알림입니다.이는 모델이 도구를 최대한 활용하도록 장려하고, 답을 환각하거나 추측할 가능성을 줄여줍니다.

예시는 다음과 같습니다.'사용자의 요청과 관련된 파일 내용이나 코드베이스 구조에 대해 확신이 서지 않는다면, 도구를 사용하여 파일을 읽고 관련 정보를 수집하세요.

절대로 답을 추측하거나 지어내지 마세요.'
 
셋째는 선택 사항인 '계획'에 대한 알림입니다.원하는 경우, 이 알림은 모델이 단순히 도구 호출만 연이어 수행하여 작업을 완료하는 대신, 각 도구 호출에 대해 명시적으로 계획을 세우고 그 결과를 텍스트로 성찰하도록 보장합니다.

예시는 다음과 같습니다.

'각 함수를 호출하기 전에 반드시 광범위하게 계획을 세우고, 이전 함수 호출의 결과에 대해 깊이 성찰해야 합니다.

이 전체 과정을 함수 호출만으로 수행하지 마세요. 이는 문제 해결 능력과 통찰력 있는 사고를 저해할 수 있습니다.'
 
GPT-4.1은 에이전트 환경에서 사용자 지시와 시스템 프롬프트 모두에 매우 가깝게 반응하도록 훈련되었습니다.

모델은 이 세 가지 간단한 지시를 철저히 준수했고, 그 결과 내부 SWE-bench Verified 점수가 거의 20% 증가했습니다.

따라서 모든 에이전트 프롬프트는 위에 나열된 세 가지 범주를 다루는 명확한 알림으로 시작하는 것을 강력히 권장합니다.

전반적으로 이 세 가지 지시는 모델을 챗봇과 유사한 상태에서 훨씬 더 '적극적인' 에이전트로 변모시켜, 자율적이고 독립적으로 상호작용을 이끌어 나가는 것을 확인했습니다.
 
도구 호출
 
이전 모델들과 비교하여 GPT-4.1은 OpenAI API 요청에서 인수로 전달된 도구를 효과적으로 활용하는 데 대해 더 많은 훈련을 거쳤습니다.

과거 일부 개발자들이 보고했던 것처럼 프롬프트에 도구 설명을 수동으로 주입하고 도구 호출을 위한 별도의 파서를 작성하는 대신, 도구를 전달하는 데 'tools' 필드를 독점적으로 사용할 것을 권장합니다.

이것이 오류를 최소화하고 도구 호출 과정에서 모델이 분포 내에 머무르도록 보장하는 최선의 방법입니다.

저희 자체 실험에서도 시스템 프롬프트에 스키마를 수동으로 주입하는 것과 비교했을 때, API로 파싱된 도구 설명을 사용할 경우 SWE-bench Verified 통과율이 2% 증가하는 것을 관찰했습니다.
 
프롬프트를 통한 계획 및 사고의 연쇄(Chain-of-Thought) 유도
 
이미 언급했듯이, 개발자들은 선택적으로 GPT-4.1로 구축된 에이전트가 중단 없이 연속적으로 도구를 호출하는 대신, 도구 호출 사이에 계획하고 성찰하도록 프롬프트를 작성할 수 있습니다.

GPT-4.1은 추론 모델이 아닙니다.

즉, 답변하기 전에 내부적인 '사고의 연쇄'를 생성하지는 않습니다.

하지만 개발자는 프롬프트에서 위에서 보여준 '계획' 프롬프트 구성 요소의 변형을 사용하여 모델이 명시적이고 단계적인 계획을 생성하도록 유도할 수 있습니다.

이는 모델이 '소리 내어 생각하는 것'으로 간주될 수 있습니다.SWE-bench Verified 에이전트 작업에 대한 저희의 실험에서, 명시적인 계획을 유도했을 때 통과율이 4% 증가했습니다.
 
샘플 프롬프트 SWE-bench Verified
 
아래에 SWE-bench Verified에서 최고 점수를 달성하는 데 사용한 에이전트 프롬프트를 공유합니다.

이 프롬프트는 워크플로우와 문제 해결 전략에 대한 상세한 지침을 특징으로 하며, 이 일반적인 패턴은 모든 에이전트 작업에 사용될 수 있습니다.
 
 
from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ.get(
        "OPENAI_API_KEY", "<your OpenAI API key if not set as env var>"
    )
)

SYS_PROMPT_SWEBENCH = """
You will be tasked to fix an issue from an open-source repository.

Your thinking should be thorough and so it's fine if it's very long. You can think step by step before and after each action you decide to take.

You MUST iterate and keep going until the problem is solved.

You already have everything you need to solve this problem in the /testbed folder, even without internet connection. I want you to fully solve this autonomously before coming back to me.

Only terminate your turn when you are sure that the problem is solved. Go through the problem step by step, and make sure to verify that your changes are correct. NEVER end your turn without having solved the problem, and when you say you are going to make a tool call, make sure you ACTUALLY make the tool call, instead of ending your turn.

THE PROBLEM CAN DEFINITELY BE SOLVED WITHOUT THE INTERNET.

Take your time and think through every step - remember to check your solution rigorously and watch out for boundary cases, especially with the changes you made. Your solution must be perfect. If not, continue working on it. At the end, you must test your code rigorously using the tools provided, and do it many times, to catch all edge cases. If it is not robust, iterate more and make it perfect. Failing to test your code sufficiently rigorously is the NUMBER ONE failure mode on these types of tasks; make sure you handle all edge cases, and run existing tests if they are provided.

You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully.

# Workflow

## High-Level Problem Solving Strategy

1. Understand the problem deeply. Carefully read the issue and think critically about what is required.
2. Investigate the codebase. Explore relevant files, search for key functions, and gather context.
3. Develop a clear, step-by-step plan. Break down the fix into manageable, incremental steps.
4. Implement the fix incrementally. Make small, testable code changes.
5. Debug as needed. Use debugging techniques to isolate and resolve issues.
6. Test frequently. Run tests after each change to verify correctness.
7. Iterate until the root cause is fixed and all tests pass.
8. Reflect and validate comprehensively. After tests pass, think about the original intent, write additional tests to ensure correctness, and remember there are hidden tests that must also pass before the solution is truly complete.

Refer to the detailed sections below for more information on each step.

## 1. Deeply Understand the Problem
Carefully read the issue and think hard about a plan to solve it before coding.

## 2. Codebase Investigation
- Explore relevant files and directories.
- Search for key functions, classes, or variables related to the issue.
- Read and understand relevant code snippets.
- Identify the root cause of the problem.
- Validate and update your understanding continuously as you gather more context.

## 3. Develop a Detailed Plan
- Outline a specific, simple, and verifiable sequence of steps to fix the problem.
- Break down the fix into small, incremental changes.

## 4. Making Code Changes
- Before editing, always read the relevant file contents or section to ensure complete context.
- If a patch is not applied correctly, attempt to reapply it.
- Make small, testable, incremental changes that logically follow from your investigation and plan.

## 5. Debugging
- Make code changes only if you have high confidence they can solve the problem
- When debugging, try to determine the root cause rather than addressing symptoms
- Debug for as long as needed to identify the root cause and identify a fix
- Use print statements, logs, or temporary code to inspect program state, including descriptive statements or error messages to understand what's happening
- To test hypotheses, you can also add test statements or functions
- Revisit your assumptions if unexpected behavior occurs.

## 6. Testing
- Run tests frequently using `!python3 run_tests.py` (or equivalent).
- After each change, verify correctness by running relevant tests.
- If tests fail, analyze failures and revise your patch.
- Write additional tests if needed to capture important behaviors or edge cases.
- Ensure all tests pass before finalizing.

## 7. Final Verification
- Confirm the root cause is fixed.
- Review your solution for logic correctness and robustness.
- Iterate until you are extremely confident the fix is complete and all tests pass.

## 8. Final Reflection and Additional Testing
- Reflect carefully on the original intent of the user and the problem statement.
- Think about potential edge cases or scenarios that may not be covered by existing tests.
- Write additional tests that would need to pass to fully validate the correctness of your solution.
- Run these new tests and ensure they all pass.
- Be aware that there are additional hidden tests that must also pass for the solution to be successful.
- Do not assume the task is complete just because the visible tests pass; continue refining until you are confident the fix is robust and comprehensive.
"""

 
 
2. 긴 컨텍스트
 
GPT-4.1은 1백만 토큰 입력 컨텍스트 윈도우를 지원하며, 구조화된 문서 파싱, 순위 재조정, 관련 없는 컨텍스트를 무시하고 관련 정보 선택, 그리고 컨텍스트를 사용한 다단계 추론 수행 등 다양한 긴 컨텍스트 작업에 유용합니다.
 
저희는 최대 1백만 토큰 컨텍스트까지 '건초더미에서 바늘 찾기(needle-in-a-haystack)' 평가에서 매우 우수한 성능을 관찰했습니다.

이는 방대한 정보 속에서 특정 정보를 정확히 찾아내는 능력을 의미합니다.또한 관련성 있는 코드와 그렇지 않은 코드가 혼합된 복잡한 작업에서도 매우 강력한 성능을 보였습니다.

하지만 검색해야 할 항목이 많아지거나, 전체 컨텍스트의 상태를 알아야 하는 복잡한 추론(예: 그래프 탐색)을 수행해야 할 경우 긴 컨텍스트 성능이 저하될 수 있습니다.
 
특히 긴 컨텍스트를 사용할 때는 지시 사항과 컨텍스트의 배치가 성능에 영향을 줄 수 있습니다.

프롬프트에 긴 컨텍스트가 있다면, 제공된 컨텍스트의 '시작과 끝 모두'에 지시 사항을 배치하는 것이 이상적입니다.

이는 컨텍스트 위나 아래에만 배치하는 것보다 더 나은 성능을 보였습니다.만약 지시 사항을 한 번만 넣고 싶다면, 제공된 컨텍스트 아래보다는 위에 배치하는 것이 더 효과적입니다.
 
3. 사고의 연쇄 (Chain of Thought)
 
앞서 언급했듯이 GPT-4.1은 추론 모델이 아니지만, 모델에게 단계별로 생각하도록 유도하는 것('사고의 연쇄'라고 불림)은 모델이 문제를 더 관리하기 쉬운 조각으로 나누고, 해결하며, 전반적인 출력 품질을 향상시키는 효과적인 방법이 될 수 있습니다.

이는 더 많은 출력 토큰 사용에 따른 비용 및 지연 시간 증가라는 단점을 감수해야 합니다.

모델은 에이전트적 추론과 실제 문제 해결에 능숙하도록 훈련되었으므로, 좋은 성능을 내기 위해 많은 프롬프팅이 필요하지는 않습니다.
 
프롬프트 끝에 다음과 같은 기본적인 '사고의 연쇄' 지시 사항으로 시작하는 것을 권장합니다.

'...먼저, 쿼리에 답하는 데 어떤 문서가 필요한지 단계별로 신중하게 생각하세요. 그런 다음, 각 문서의 제목과 ID를 출력하세요. 마지막으로, ID를 리스트 형식으로 정리하세요.'
 
여기서부터는 특정 예시와 평가에서 발생한 실패 사례를 감사하고, 보다 명시적인 지시 사항으로 체계적인 계획 및 추론 오류를 해결함으로써 '사고의 연쇄' 프롬프트를 개선해야 합니다.
 
4. 지시 사항 준수
 
GPT-4.1은 뛰어난 지시 사항 준수 성능을 보여주며, 개발자는 이를 활용하여 특정 사용 사례에 맞게 출력을 정밀하게 형성하고 제어할 수 있습니다.

모델이 지시를 더 문자 그대로 따르기 때문에, 개발자는 무엇을 해야 하고 무엇을 하지 말아야 하는지에 대한 명시적인 명세를 포함해야 할 수도 있습니다.

또한, 다른 모델에 최적화된 기존 프롬프트는 이 모델에서 즉시 작동하지 않을 수 있습니다.기존 지시는 더 엄격하게 준수되고 암묵적인 규칙은 더 이상 강하게 추론되지 않기 때문입니다.
 
다음은 프롬프트에서 지시 사항을 개발하고 디버깅하기 위한 권장 워크플로우입니다.

먼저, 상위 수준의 지침과 요점들을 담은 전반적인 '응답 규칙' 또는 '지침' 섹션으로 시작하십시오.

더 구체적인 행동을 변경하고 싶다면, '# 샘플 문구'와 같이 해당 카테고리에 대한 세부 사항을 명시하는 섹션을 추가합니다.모델이 따라야 할 특정 단계가 있다면, 순서가 있는 목록을 추가하고 모델에게 이 단계를 따르도록 지시합니다.

그래도 행동이 예상대로 작동하지 않는다면, 상충되거나, 불충분하게 명시되었거나, 잘못된 지시와 예시가 있는지 확인합니다.

만약 상충되는 지시가 있다면, GPT-4.1은 프롬프트 끝에 더 가까운 지시를 따르는 경향이 있습니다.
 
5. 일반적인 조언
 
프롬프트 구조
 
참고용으로, 프롬프트를 구조화하는 데 좋은 출발점은 다음과 같습니다.먼저 '역할 및 목표'를 정의합니다.그 다음 '지침'을 제시하며, 필요에 따라 하위 카테고리를 두어 더 상세한 지침을 제공합니다.

이후 '추론 단계'와 '출력 형식'을 명시하고, '예시'를 통해 원하는 동작을 보여줍니다.

마지막으로 '컨텍스트'를 제공하고, 단계별 사고를 유도하는 최종 지시를 덧붙입니다.

필요에 맞게 섹션을 추가하거나 제거하고, 사용 사례에 최적의 구성을 찾기 위해 실험해 보십시오.
 
구분 기호
 
프롬프트에 가장 적합한 구분 기호를 선택하기 위한 몇 가지 일반적인 지침입니다.'마크다운'으로 시작하는 것을 권장합니다.

주요 섹션과 하위 섹션에는 마크다운 제목을 사용하고, 코드를 정확하게 감싸기 위해 인라인 백틱이나 백틱 블록을 사용하며, 필요에 따라 표준 번호 매기기 또는 글머리 기호 목록을 사용합니다.

'XML' 태그 또한 성능이 좋으며, 이 모델에서는 XML 내 정보에 대한 준수율이 향상되었습니다.

'JSON'은 특히 코딩 컨텍스트에서 모델이 잘 이해하는 고도로 구조화된 형식입니다.

그러나 더 장황할 수 있고, 문자 이스케이프 처리가 필요하여 오버헤드가 추가될 수 있습니다.
 
결론 프롬프트에서 프로그래밍으로
 
GPT-4.1을 효과적으로 활용하는 것은 단순히 질문을 잘 던지는 것을 넘어, 모델의 행동을 정밀하게 '설계'하고 '프로그래밍'하는 과정에 가깝습니다.

이 가이드에서 제시된 전략들, 즉 명시적인 에이전트 워크플로우 정의, 긴 컨텍스트의 전략적 배치, 그리고 체계적인 사고의 연쇄 유도는 모두 모델을 단순한 정보 생성기에서 신뢰할 수 있는 문제 해결 파트너로 격상시키는 데 목적이 있습니다.

가장 중요한 것은 실험을 두려워하지 않는 것입니다.프롬프트 엔지니어링은 이론보다는 실증에 기반하며, 여러분의 특정 요구사항에 가장 잘 맞는 최적의 해법을 찾기 위해서는 끊임없는 시도와 개선이 필수적입니다.