OpenAI Agents SDK로 “출처 있는 리서치 브리프 에이전트”를 만드는 법

리서치 에이전트는 “조사하게 만들기”보다 “입력 제한, 도구 호출, 출력 검증, 사람 승인, 실행 추적”을 어디에 넣을지 먼저 설계해야 합니다.

들어가며 — 독자가 지금 이 문제를 검색하는 이유

AI에게 리서치를 맡기면 처음에는 꽤 그럴듯한 결과가 나옵니다. 문제는 그다음입니다.

• 이 출처는 실제로 확인된 것인가?
• 사내 문서 접근 권한을 넘어선 것은 아닌가?
• 최종 브리프에서 확인 안 된 내용을 단정하지 않았는가?
• 사람이 승인해야 할 단계 없이 바로 공유되는 것은 아닌가?
• 나중에 “왜 이런 답이 나왔는지” 실행 과정을 다시 볼 수 있는가?

이번 글의 질문은 “AI가 리서치를 잘하느냐”가 아닙니다.

OpenAI Agents SDK로 ‘출처 있는 리서치 브리프’라는 하나의 업무 결과물을 만들 때, guardrails, human-in-the-loop, tracing, testing을 어디에 배치해야 하는가입니다.

OpenAI Agents SDK는 공식 GitHub 저장소 기준으로 제공되고 있으며, 2026년 9월 9일 기준 v0.22.2 릴리스가 공개되어 있습니다. 공식 문서에서는 guardrails, human-in-the-loop, tracing, testing을 각각 별도 기능으로 설명합니다.

• OpenAI Agents SDK GitHub: https://github.com/openai/openai-agents-python
• v0.22.2 릴리스: https://github.com/openai/openai-agents-python/releases/tag/v0.22.2
• Guardrails 문서: https://openai.github.io/openai-agents-python/guardrails/
• Human-in-the-loop 문서: https://openai.github.io/openai-agents-python/human_in_the_loop/
• Tracing 문서: https://openai.github.io/openai-agents-python/tracing/
• Testing 문서: https://openai.github.io/openai-agents-python/testing/

1. 먼저 결과물을 고정합니다: “출처 있는 리서치 브리프”

에이전트 자동화를 시작할 때 흔히 하는 실수는 “리서치를 해줘”처럼 업무를 너무 넓게 정의하는 것입니다. 이렇게 시작하면 검증 기준도 함께 흐려집니다.

이번 가이드에서는 결과물을 하나로 고정합니다.

결과물: 출처 있는 리서치 브리프

브리프는 다음 조건을 만족해야 합니다.

1. 사용자의 질문 범위를 벗어나지 않는다.

2. 출처 링크를 포함한다.

3. 확인되지 않은 내용은 단정하지 않는다.

4. 최종 공유 전 사람이 승인할 수 있다.

5. 실행 과정이 trace로 남아 나중에 확인 가능하다.

6. 반복 테스트로 품질을 점검할 수 있다.

OpenAI Agents SDK 공식 문서에서 다루는 기능을 이 결과물에 대응시키면 다음과 같습니다.

기능	리서치 브리프에서 맡을 역할
Guardrails	입력 제한, 출력 형식 검증, 위험한 응답 차단
Tool calling	웹 검색, 문서 조회, 내부 자료 조회 등 외부 정보 접근
Human-in-the-loop	최종 발행·공유 전 사람 승인
Tracing	어떤 입력, 도구 호출, 중간 판단을 거쳤는지 확인
Testing	반복 질문에 대해 브리프 품질이 유지되는지 검증

여기서 중요한 점은 기능을 많이 붙이는 것이 아닙니다.

리서치 브리프가 실패할 수 있는 지점마다 필요한 안전장치를 배치하는 것입니다.

2. 최소 적용 단계: 입력 → 조사 → 초안 → 승인 → 추적 → 테스트

OpenAI Agents SDK로 리서치 브리프 에이전트를 설계한다면, 최소 흐름은 다음처럼 나눌 수 있습니다.

1단계. 입력 가드레일: 조사 범위를 먼저 제한합니다

리서치 에이전트의 첫 번째 위험은 질문을 과도하게 넓게 해석하는 것입니다.

예를 들어 사용자가 “최근 AI 에이전트 동향 정리해줘”라고 요청하면, 모델은 제품 비교, 시장 전망, 투자 의견, 기술 예측까지 섞어낼 수 있습니다.

그래서 입력 단계에 guardrails를 둡니다.

입력 가드레일의 목적은 다음과 같습니다.

• 질문이 리서치 브리프 작성에 충분히 구체적인지 확인
• 사내 기밀, 개인정보, 민감 정보가 포함되어 있는지 점검
• 조사 범위를 벗어난 요청 제한
• 확인 필요 항목을 별도로 표시

OpenAI Agents SDK는 guardrails를 공식 기능으로 설명합니다.

문서: https://openai.github.io/openai-agents-python/guardrails/

이 단계에서 중요한 기준은 “답을 잘하게 만들기”가 아니라 “잘못된 질문을 그대로 실행하지 않게 만들기”입니다.

2단계. 도구 호출: 출처를 가져오는 경로를 분리합니다

리서치 브리프는 모델의 기억만으로 쓰면 안 됩니다. 출처가 있어야 합니다.

따라서 조사 단계에서는 도구 호출을 통해 외부 자료를 확인하는 흐름을 따로 분리해야 합니다.

예상되는 도구 호출 대상은 다음과 같습니다.

• 공식 문서
• 공식 GitHub 저장소
• 릴리스 노트
• 사내 문서 저장소
• 제품 문서
• 정책 문서

다만 실제 사내 문서 접근권한, 모델 비용, 보안 정책 적용 방식은 조직마다 다릅니다. 이 부분은 본문에서 일반 원칙처럼 단정하기보다, 도입 전 점검 항목으로 남겨야 합니다.

이 단계의 핵심은 다음입니다.

모델이 “아는 것처럼 말하는 영역”과 도구가 “확인한 영역”을 분리해야 합니다.

브리프 본문에는 확인된 출처 링크를 남기고, 확인되지 않은 내용은 “확인 필요”로 분리하는 방식이 안전합니다.

3단계. 출력 가드레일: 브리프 형식을 검증합니다

출력 단계에서는 최종 브리프가 기준을 만족하는지 점검합니다.

예를 들어 다음 조건을 둘 수 있습니다.

• 모든 핵심 주장에 출처가 있는가?
• 출처 없는 수치나 사실을 단정하지 않았는가?
• 확인 필요 항목을 본문에서 사실처럼 쓰지 않았는가?
• 요청한 형식에 맞는가?
• 외부 공유에 부적절한 내용이 포함되지 않았는가?

OpenAI Agents SDK의 guardrails는 입력뿐 아니라 결과물 검증 관점에서도 활용할 수 있습니다.

문서: https://openai.github.io/openai-agents-python/guardrails/

출력 가드레일은 리서치 자동화에서 특히 중요합니다.

AI 리서치의 문제는 “틀린 말을 전혀 안 한다”가 아니라, 맞는 말과 확인 안 된 말을 자연스럽게 섞을 수 있다는 데 있기 때문입니다.

3. 사람 승인, 추적, 테스트를 넣어야 운영 가능한 에이전트가 됩니다

사람 승인: 최종 공유 전 멈추는 지점을 만듭니다

리서치 브리프는 내부 의사결정이나 외부 콘텐츠의 재료가 될 수 있습니다. 그래서 최종 공유 전에는 사람 승인 지점을 두는 것이 좋습니다.

OpenAI Agents SDK는 human-in-the-loop 기능을 공식 문서에서 별도로 설명합니다.

문서: https://openai.github.io/openai-agents-python/human_in_the_loop/

리서치 브리프 에이전트에서 사람이 확인해야 할 지점은 보통 다음입니다.

• 출처가 실제로 적절한가?
• 민감한 내부 정보가 포함되어 있지 않은가?
• 확인 필요 항목을 단정하지 않았는가?
• 외부 공유 가능한 표현인가?
• 최종 결론이 과장되어 있지 않은가?

여기서 사람 승인은 “AI가 못 미더워서 넣는 절차”가 아닙니다.

AI가 빠르게 초안을 만들고, 사람은 공개·공유 책임이 있는 판단만 맡도록 역할을 나누는 장치입니다.

Tracing: 나중에 설명 가능한 실행 기록을 남깁니다

리서치 브리프는 결과만 보면 그럴듯해 보일 수 있습니다. 하지만 운영 단계에서는 “왜 이런 결론이 나왔는지”를 확인할 수 있어야 합니다.

OpenAI Agents SDK는 tracing을 공식 기능으로 제공합니다.

문서: https://openai.github.io/openai-agents-python/tracing/

리서치 브리프에서 trace로 보고 싶은 항목은 다음입니다.

• 사용자의 원래 질문
• 입력 가드레일 판단
• 호출한 도구
• 참조한 출처
• 중간 판단
• 최종 출력
• 승인 또는 보류 여부

이 기록은 단순 로그가 아닙니다.

나중에 브리프 품질을 개선하거나, 잘못된 출처 사용을 찾아내거나, 승인 기준을 더 정교하게 만드는 근거가 됩니다.

Testing: 좋은 프롬프트가 아니라 반복 가능한 품질을 확인합니다

리서치 에이전트를 한 번 실행해서 좋은 결과가 나왔다고 운영 가능한 것은 아닙니다.

OpenAI Agents SDK는 testing 문서를 별도로 제공합니다.

문서: https://openai.github.io/openai-agents-python/testing/

테스트에서는 다음 질문을 확인해야 합니다.

• 같은 유형의 요청에서 항상 출처를 남기는가?
• 확인되지 않은 수치를 단정하지 않는가?
• 민감한 요청을 입력 가드레일에서 걸러내는가?
• 최종 출력 형식을 안정적으로 지키는가?
• 사람 승인 전 단계에서 멈추는가?

리서치 브리프 에이전트의 테스트는 “답변이 마음에 드는가”보다 “실패하면 안 되는 조건을 지키는가”에 가까워야 합니다.

바로 적용하는 체크리스트 또는 비교 기준

출처 있는 리서치 브리프 에이전트 적용 체크리스트

준비물

• [ ] OpenAI Agents SDK를 사용할 Python 프로젝트
• [ ] 공식 문서 기준으로 guardrails, human-in-the-loop, tracing, testing 기능 확인
• [ ] 리서치 브리프의 고정 출력 형식
• [ ] 사용할 출처 범위
• [ ] 사내 문서 접근권한 기준
• [ ] 외부 공유 전 승인 기준
• [ ] 모델 비용과 보안 정책 검토
• 실제 사내 문서 접근권한, 모델 비용, 보안 정책 적용 방식은 확인 필요

단계

1. 결과물 정의

• “출처 있는 리서치 브리프”처럼 산출물을 하나로 고정합니다.
• 요약문, 핵심 근거, 출처 링크, 확인 필요 항목을 포함하도록 형식을 정합니다.

2. 입력 가드레일 설정

• 조사 범위가 너무 넓은 요청을 제한합니다.
• 민감 정보나 권한 밖 자료 요청을 걸러냅니다.
• 불명확한 요청은 바로 실행하지 않고 확인 필요로 분류합니다.

3. 도구 호출 경로 설계

• 공식 문서, GitHub 저장소, 릴리스 노트, 사내 문서 등 출처 확인 경로를 정합니다.
• 모델의 추론과 실제 출처 확인을 분리합니다.

4. 출력 가드레일 설정

• 출처 없는 사실 단정을 막습니다.
• 확인 필요 항목이 본문 결론으로 섞이지 않게 합니다.
• 정해진 브리프 형식을 지키도록 검증합니다.

5. 사람 승인 단계 추가

• 최종 공유, 게시, 보고 전에는 human-in-the-loop 지점을 둡니다.
• 승인자는 출처, 표현, 민감 정보, 과장 여부를 확인합니다.

6. Tracing 활성화

• 입력, 도구 호출, 중간 판단, 최종 출력, 승인 여부를 추적합니다.
• 문제가 생겼을 때 결과만 보지 말고 실행 흐름을 확인합니다.

7. Testing 구성

• 정상 요청, 모호한 요청, 민감한 요청, 출처 없는 수치 요청을 테스트 케이스로 만듭니다.
• 브리프 품질보다 먼저 “지켜야 할 조건”을 검증합니다.

검증 기준

• [ ] 최종 브리프에 출처 링크가 포함되어 있는가?
• [ ] 출처 없는 수치나 사실을 단정하지 않았는가?
• [ ] 확인 필요 항목이 별도로 표시되는가?
• [ ] 외부 공유 전 사람 승인 단계가 있는가?
• [ ] 실행 trace로 도구 호출과 판단 흐름을 확인할 수 있는가?
• [ ] 반복 테스트에서 출력 형식이 유지되는가?
• [ ] 민감 정보나 권한 밖 요청이 가드레일에 걸리는가?

실패 시 점검 순서

1. 출처가 빠진다면

• 도구 호출 단계가 실제로 실행되는지 확인합니다.
• 브리프 출력 형식에 출처 필드를 필수로 두었는지 점검합니다.

2. 확인 안 된 내용이 단정된다면

• 출력 가드레일을 먼저 점검합니다.
• “확인 필요” 항목을 별도 섹션으로 분리했는지 확인합니다.

3. 사람 승인 없이 결과가 공유된다면

• human-in-the-loop 지점이 최종 출력 전에 있는지 확인합니다.
• 승인 전 단계와 승인 후 단계를 분리합니다.

4. 문제 원인을 추적하기 어렵다면

• tracing 설정을 확인합니다.
• 입력, 도구 호출, 최종 출력이 trace에 남는지 봅니다.

5. 실행할 때마다 품질이 흔들린다면

• testing 기준을 먼저 정리합니다.
• 성공 사례만 보지 말고 실패하면 안 되는 요청을 테스트 케이스로 추가합니다.

마무리 + 생각해볼 질문 1개

OpenAI Agents SDK로 리서치 에이전트를 만든다는 것은 “AI에게 검색을 시킨다”는 뜻이 아닙니다.

먼저 업무 결과물을 정하고, 그 결과물이 실패할 수 있는 지점마다 장치를 놓는 일입니다.

• 입력에서 범위를 제한하고
• 조사 단계에서 출처를 확인하고
• 출력에서 단정을 막고
• 사람 승인으로 공유 책임을 분리하고
• trace로 실행 흐름을 남기고
• test로 반복 품질을 확인하는 것

이 흐름을 갖추면 리서치 에이전트는 단순한 챗봇이 아니라, 재현 가능한 업무 파이프라인에 가까워집니다.

생각해볼 질문은 하나입니다.

우리 조직의 리서치 브리프에서 AI가 절대 단정하면 안 되는 정보는 무엇인가요?