작성자 주: Agent는 웹페이지를 읽어 자료를 가져오고 목록으로 정리해 줄 수 있어요. 하지만 그 결과물은 ‘골라서 읽어볼 단서’이지 ‘바로 인용할 수 있는 근거’는 아니에요. 이 글에서는 공개된 사용 사례를 바탕으로 Agent가 자료를 수집한 뒤 작성자가 직접 확인해야 할 4가지를 살펴봅니다.
‘기술 혁신’처럼 범위가 넓은 주제는 곧바로 글을 쓰기 시작하면 내용이 막연해지기 쉬워요. 그래서 많은 콘텐츠 작성자와 연구자가 AI Agent에게 웹 자료를 대량으로 수집하게 하고, 여러 답변과 게시물에서 구체적인 주제의 실마리를 찾고 있어요. 이 글은 Agent가 자료를 수집한 뒤의 수동 검증에 초점을 맞춰, 목록에서 활용할 수 있는 내용과 특정 시점의 기록이나 간접 전달에 불과한 내용, 아직 불완전한 내용을 구분하는 방법을 알려드려요.
이 글은 도구 평가가 아닙니다. 참고한 사례는 홍보 표시가 있는 커뮤니티 공유 글에서 가져왔어요. 사례도 하나뿐이므로 효과를 입증하는 근거가 아니라 ‘한 사람의 경험’으로 살펴볼게요. 글에 등장하는 3D 프린팅 관련 답변은 원작성자도 원문으로 돌아가 확인하지 않았다고 밝혔어요. 따라서 이 글에서도 이를 사실로 인용하지 않습니다.
핵심 내용: 이 글을 읽고 나면 재사용할 수 있는 Agent 자료 검증 체크리스트를 얻게 돼요. 넓은 주제를 구체적인 질문으로 좁히는 방법과 확인되지 않은 간접 전달 내용을 글에 그대로 옮기지 않는 방법도 알 수 있어요.
Agent 자료 수집의 핵심: 목록으로 할 수 있는 일과 할 수 없는 일
먼저 참고 사례를 살펴볼게요. 한 작성자가 동료가 Codex와 Moli로 Quora를 읽은 기록을 봤어요. 동료는 Codex에서 Moli Web Fetch Skill을 선택하고 Quora의 “Technological Innovation” 주제 링크를 붙여 넣은 뒤, “View all content”라는 문장만 추가했어요. Codex는 작업 순서를 정하고 Moli를 호출해 웹페이지에서 콘텐츠를 가져온 다음, 질문·작성자·요약·출처를 목록으로 정리했어요.
이 과정에는 작성자가 특히 주의해야 할 세 가지 문제가 드러나요. 첫 번째 읽기 명령은 정상 종료됐지만, 결과에는 주제 제목과 “Something went wrong”만 있고 답변 내용은 없었어요. 웹 응답을 확인하는 방식으로 바꾼 뒤에야 답변 카드 10개를 가져왔는데, 반환 데이터의 hasNextPage가 참이라 다음 페이지가 있다는 사실도 확인됐어요. 목록의 7번째 항목은 미리보기도 잘려 있었고요.
| 핵심 요점 | 설명 | 작성자에게 주는 의미 |
|---|---|---|
| 목록은 골라 읽기에 적합 | Agent가 질문, 작성자, 요약, 출처를 한데 모아 빠르게 훑어보기 편해요 | 웹페이지와 채팅창 사이에서 자료를 옮기는 시간을 줄여줘요 |
| 명령 성공≠콘텐츠 확보 | 첫 번째 읽기는 정상 종료됐지만 제목과 오류 메시지만 가져왔어요 | 자료를 가져올 때마다 결과에 본문이 있는지 먼저 확인해야 해요 |
| 페이지 분할과 내용 잘림=자료 불완전 | hasNextPage가 참이고, 7번째 항목은 미리보기가 잘려 있어요 |
첫 번째로 가져온 결과를 ‘모든 관점’으로 여겨서는 안 돼요 |
| 상호작용 수는 특정 시점의 수치 | 목록의 상호작용 수는 수집 당시의 상태만 보여줘요 | 참고용으로만 쓰고 ‘가장 인기 있다’는 주장의 근거로 삼아서는 안 돼요 |
| 요약은 바꿔 쓴 내용 | 일상생활 사례는 Agent가 정리해 바꿔 쓴 것으로, 아직 원문을 확인하지 않았어요 | 인용하기 전에 원래 답변으로 돌아가 항목별로 확인해야 해요 |
Agent 취재 목록이 ‘골라 읽기’에만 적합한 이유
목록의 가치는 살펴볼 범위를 좁혀준다는 데 있어요. 사례의 작성자는 10개 항목을 훑어보다가 3번째인 “What happened to 3D printing？”(작성자 James Martin)에 주목했어요. 요약에 모델 설계, 재료, 가격, 양산 비용 같은 제약이 언급되어 있었기 때문이에요. 목록에서 읽고 싶은 글을 먼저 고른 뒤 출처를 따라가 세부 내용을 확인할 수 있죠. Agent를 활용한 취재가 시간을 절약해 주는 지점이에요.
다만 목록은 두 단계의 가공을 거쳐요. 먼저 Agent가 웹페이지에서 데이터를 가져오고, 그다음 모델이 내용을 압축해 요약하죠. 어느 단계에서든 정보가 빠지거나, 어조가 달라지거나, 내용을 잘못 연결할 수 있어요. 참고 자료에는 Agent 요약의 정확도에 관한 데이터가 없고, 저희도 숫자를 지어내지는 않을게요. 따라서 요약에는 ‘편차가 있을 수 있다’고 생각하고, 증거 자체가 아닌 길잡이로 활용하는 편이 안전해요.
넓은 주제에서 구체적인 질문으로 좁혀가기
사례의 작성자가 주제를 좁혀간 과정은 참고할 만해요. 처음 주제는 ‘기술 혁신’이었지만, 목록을 본 뒤 ‘3D 프린팅’으로 범위를 좁혔어요. 그리고 자료에서 전해 들은 일상 속 사례를 바탕으로 한층 더 구체화했죠. 자료에 따르면, 한 응답자는 상점이 문을 닫았을 때 수도꼭지 패킹을 직접 출력했고, 다른 사람이 올린 모델로 커피 머신 부품도 만들어 봤어요. 하지만 저렴한 양산 부품은 그냥 사는 편이 더 낫다고 생각했죠.
이렇게 해서 질문은 ‘급하게 필요한 부품을 살 수 없다면 직접 출력해야 할까?’가 됐어요. 충분히 구체적인 질문이면서 ‘급할 때 부품을 보충하는 것’과 ‘장기적으로 프린터로 쇼핑을 대체하는 것’도 구분할 수 있어요. 이 단계에서 작성자는 해당 내용이 자료에 전해진 응답자의 경험담이며, 원래 답변으로 돌아가 하나씩 확인하지는 않았다고 명시했어요. 주제는 먼저 정할 수 있지만, 인용은 검증한 뒤에 해야 해요.
Agent 자료 수집 빠르게 시작하기: 목록부터 인용 가능한 자료까지 6단계
사례에서 얻은 경험을 일반적인 절차로 정리했어요. 특정 도구 버전에 의존하지 않으므로 Moli와 Codex를 함께 쓰거나, 웹페이지를 읽을 수 있는 다른 Agent에도 적용할 수 있어요. 단계에 나오는 지시문과 매개변수는 인라인으로 표시했으며, 코드를 작성할 필요는 없어요.
1~3단계: Agent가 자료를 가져와 정리하게 하기
- 링크와 최소한의 요구사항 제공하기: 사례처럼 주제 링크만 붙이고
View all content같은 요청을 한 줄 추가하세요. 표 구조를 미리 정하지 말고, Agent가 무엇을 가져오는지 먼저 확인해요. - 결과에 실제 본문이 있는지 확인하기: 명령이 정상 종료됐다고 해서 성공한 것은 아니에요. 제목이나
Something went wrong같은 메시지만 보인다면 페이지 콘텐츠가 로드되기를 기다려야 할 수 있어요. Agent가 웹페이지에서 받은 응답 데이터를 확인하는 등 다른 경로로 읽도록 요청하세요. - 목록에 출처 필드 포함 요청하기: 질문, 작성자, 요약, 출처 링크가 모두 필요해요. 출처가 없는 항목은 나중에 확인할 수 없으므로 인용 후보에서 바로 제외하세요.
4~6단계: 직접 판단하고 확인하기
- 완전성을 확인할 단서 기록하기:
hasNextPage같은 페이지네이션 표시, 잘린 미리보기, 항목 수를 살펴보고 “이것은 첫 번째 묶음”이라고 메모해 두세요. - 결론이 아닌 접근점 찾기: 목록에서 더 읽어보고 싶은 세부 내용을 골라, 미리 정해진 주장 대신 구체적인 질문으로 바꿔보세요.
- 원문으로 돌아가 항목별로 확인하기: 인용하려는 주장, 사례, 숫자를 원본 페이지에서 하나씩 대조한 다음 기사에 넣을지 결정하세요.
🎯 기술 팁: 3단계에서 요약을 생성할 때 서로 다른 두 모델에 각각 요약을 맡긴 뒤 비교해 보세요. 같은 답변에 대한 설명이 두 요약에서 확연히 다르다면 해당 항목부터 원문을 확인하면 돼요. APIYI apiyi.com처럼 통합 인터페이스를 제공하는 플랫폼에서는 모델 이름만 바꾸면 여러 주요 모델을 호출할 수 있어, 이렇게 교차 비교하기가 훨씬 편해요.
Agent가 자료를 수집한 후 확인할 4가지 항목
이 글에서 가장 핵심적인 부분이에요. 사례 작성자는 글 끝에서 “인용하기 전에 봐야 할 원문은 직접 봐야 한다”고 말해요. 이 말을 하나씩 체크할 수 있는 네 가지 항목으로 나눠봤어요.
| 확인 항목 | 답해야 할 질문 | 사례에 나타난 단서 | 확인되지 않으면 어떻게 할까? |
|---|---|---|---|
| 출처 | 이 내용은 어느 페이지, 어떤 작성자에게서 왔나요? 원본 링크를 열 수 있나요? | 목록에 작성자 James Martin과 출처가 나와 있음 | 원본 링크를 찾을 수 없다면 인용하지 않고 영감으로만 활용 |
| 완전성 | 지금 보는 내용이 전문인가요, 미리보기인가요, 아니면 첫 번째 묶음인가요? | hasNextPage가 참이고, 7번 항목은 잘린 미리보기만 있음 |
나머지 페이지를 가져오거나 원본 답변을 열어 전체 내용 확인 |
| 시의성 | 데이터는 언제 수집했나요? 반응 수는 달라질 수 있나요? | 반응 수는 수집 당시의 스냅숏임 | 인용할 때 시점을 밝히거나 구체적인 숫자는 쓰지 않음 |
| 전달 과정의 차이 | 요약과 원문의 내용이 일치하나요? 전달 과정에서 내용이 달라졌나요? | 수도꼭지 와셔와 커피 머신 부품은 전해 들은 내용으로, 확인되지 않음 | 원문을 기준으로 다시 서술하고, 필요하면 원문을 직접 인용 |
이 네 가지 중 가장 놓치기 쉬운 것은 “전달 과정의 차이”예요. Agent의 요약은 대체로 매끄럽게 읽혀서 오히려 경계심이 풀릴 수 있어요. 예를 들어 원문에서는 출력 경험을 한 번 가볍게 언급했을 뿐인데, 요약에는 “오랫동안 직접 부품을 출력해 사용했다”고 적힐 수 있어요. 이렇게 뉘앙스가 바뀌면 글에서 펼치는 주장도 그에 따라 달라져요.
💡 선택 팁: 글에 외국어 답변을 많이 인용해야 한다면 번역과 요약을 분리하는 것이 좋아요. 먼저 모델에 원문을 문단별로 번역하게 한 다음 직접 요약해 보세요. APIYI apiyi.com에서는 동일한 인터페이스로 여러 모델을 호출할 수 있어요. 번역과 요약을 서로 다른 모델에 맡기면 한 모델이 “번역하면서 내용을 바꿔 쓰는” 데서 생기는 편차를 줄일 수 있어요.
Agent 자료 수집의 활용 범위: 읽을 자료 고르기와 인용 근거 비교
Agent로 자료를 수집하다 보면 놓치기 쉬운 문제가 있어요. 목록이 완전하고 깔끔해 보여서 어느새 그 자체를 인용 출처로 삼게 되는 거죠. 아래 표에서 자료를 “골라 읽는” 용도와 “인용하는” 용도를 비교해 볼게요.
| 비교 항목 | Agent가 정리한 목록 | 원문으로 돌아가 확인한 자료 |
|---|---|---|
| 주요 용도 | 훑어보기, 선별, 접근점 찾기 | 글에 인용하고 논점 뒷받침하기 |
| 완전성 | 첫 번째 수집분만 있거나 내용이 잘렸을 수 있음 | 답변 전체를 읽음 |
| 표현 방식 | 모델이 요약하고 전달한 내용 | 작성자의 원문이나 충실하게 바꿔 쓴 내용 |
| 시간 정보 | 수집 시점의 스냅샷 | 인용할 때 확인 날짜를 명시 |
| 오류의 영향 | 어떤 항목을 읽을지에만 영향 | 글의 신뢰도에 직접적인 영향 |
비교 해설
Agent 목록은 자료를 빠르게 훑고 읽을 만한 것을 고르는 데 효율적이에요. 사례 작성자도 웹페이지와 채팅창 사이에서 자료를 옮기는 과정이 줄어든 점을 가장 유용하게 봤어요. 하지만 내용이 불완전하거나 요약·전달된 것일 수 있고, 수집 시점의 스냅샷이라는 한계도 분명해요. 반면 원문 확인은 느리지만, 인용에 책임을 질 수 있는 유일한 단계예요.
다른 관점에서 보면 Agent를 활용한 자료 수집은 글쓰기의 중심을 “옮기기”에서 “판단하기”로 바꿔줘요. 예전에는 복사와 붙여넣기에 많은 시간을 썼다면, 이제는 그 시간을 검증과 사고에 쓸 수 있어요. 바로 사람이 대체할 수 없는 부분이죠.
📌 작업 흐름 제안: “확인 필요” 태그를 만들어 두세요. Agent 목록에서 가져온 의견을 초고에 넣을 때는 먼저 이 태그를 달고, 확인을 마친 후에 제거해요. APIYI apiyi.com에서 모델을 호출해 정리를 돕는다면, 각 요약에 “요약·전달”이라고 표시하도록 요청할 수도 있어요. 아직 원문이 아니라는 점을 상기시켜 주죠.
Agent 자료 검증의 활용 사례와 한계
이 검증 방법은 Quora 같은 Q&A 커뮤니티에만 적용되는 게 아니에요. 사례 작성자도 글 말미에서 제품 문서와 업데이트 안내에 같은 과정을 적용해 보고 싶다고 밝혔어요. 자료 유형마다 중점적으로 확인할 항목은 다릅니다.
| 자료 유형 | 가장 중요한 검증 항목 | 흔한 위험 |
|---|---|---|
| Q&A 커뮤니티 답변 | 전달 과정의 차이, 완전성 | 개인 경험이 일반적인 결론으로 요약됨 |
| 제품 문서 | 최신성 | 문서가 업데이트된 뒤 이전 버전의 설명이 유효하지 않게 됨 |
| 업데이트 안내 | 출처, 최신성 | 예고된 기능을 이미 출시된 기능으로 오인함 |
| 뉴스 또는 홍보 게시물 | 출처 | 홍보 콘텐츠를 중립적인 평가로 받아들임 |
마지막 항목은 특히 짚고 넘어갈 필요가 있어요. 이 글에서 참고한 게시물 자체에 “홍보”라고 표시되어 있으며, 독립적인 평가가 아니라 사용 기록을 보여 줍니다. 이 게시물을 인용한 이유는 특정 도구의 효과를 입증해서가 아니라, 자료 수집 과정의 중요한 신호 몇 가지를 명확하게 보여 주기 때문이에요. 홍보성 자료를 다룰 때도 반드시 “출처”를 확인해야 합니다.
사례 하나로는 부족해요. 무엇을 더 보완해야 할까요?
사례 작성자가 고른 주제를 아직 바로 글로 완성할 수 없는 이유는 뒷받침할 답변이 하나뿐이기 때문이에요. “갑자기 부품이 부족할 때 직접 출력해야 할까?”라는 질문에 답하려면 더 많은 사용자의 경험을 살펴보고, 모델 출처와 재료비, 직접 제작하는 데 드는 비용 중 무엇이 걸림돌인지 확인해야 해요. 작성자도 원본 답변을 다시 확인하고 사례를 더 찾아볼 예정이라고 밝혔어요.
이것이 바로 Agent를 활용한 자료 수집의 또 다른 한계예요. 첫 번째 단서는 찾을 수 있지만, 그 단서에 대표성이 있는지 대신 판단해 주지는 못합니다. 논거가 요약 하나에만 의존하고 있다면 서둘러 글을 쓰기보다 다시 검색 단계로 돌아가야 해요.
🔍 추가 제안: 사례를 더 찾을 때는 Agent에게 여러 키워드로 각각 자료를 수집하게 한 뒤, 모델로 목록을 합치고 중복을 제거할 수 있어요. APIYI apiyi.com의 통합 인터페이스를 활용해 같은 정리 지시를 여러 모델에 실행하고, 각 모델이 고른 핵심 내용이 일치하는지 비교하는 것도 비용을 적게 들여 직접 검증하는 방법이에요.
자주 묻는 질문 FAQ
Q1: Agent 자료 수집이란 무엇인가요?
Agent 자료 수집은 AI Agent가 사용자를 대신해 웹페이지를 열고, 콘텐츠가 로드되기를 기다린 뒤 본문을 읽어 목록으로 정리하는 작업이에요. 참고 사례에서는 Codex가 작업 단계를 정하고, Moli 같은 AI용 브라우저가 웹페이지를 읽어 질문, 작성자, 요약, 출처를 정리해요.
Q2: Agent가 정리한 목록은 원문과 어떻게 다른가요?
목록은 원문을 읽고 요약한 결과물이라 빠르게 훑어보기에 좋아요. 원문은 작성자의 완전한 표현이므로 인용 근거로 적합해요. 목록은 효율적이지만 내용이 잘리거나 요약 과정에서 왜곡될 수 있어요. 원문을 확인하는 데는 시간이 더 걸리지만, 신뢰성을 확보할 수 있어요.
Q3: 읽기 명령이 성공했는데 왜 결과를 확인해야 하나요?
참고 사례에서는 첫 번째 읽기 명령이 정상 종료됐지만, 결과에는 주제 제목과 “Something went wrong”만 있었어요. 일부 페이지는 로딩이 끝나야 내용이 나타나므로 ‘명령 완료’와 ‘콘텐츠 확보’는 다른 일이에요. 매번 결과에 본문이 있는지 먼저 확인하세요.
Q4: 가져온 자료가 불완전한지 어떻게 알 수 있나요?
세 가지 신호를 살펴보세요. 반환 데이터의 페이지 구분 표시가 남아 있거나(예: `hasNextPage`가 참), 항목에 잘린 미리보기만 있거나, 항목 수가 실제 페이지의 콘텐츠보다 눈에 띄게 적은 경우예요. 하나라도 해당하면 일부 자료만 확보한 것이므로 이를 바탕으로 ‘다들 어떻게 말하는지’ 일반화할 수 없어요.
Q5: 여러 모델로 요약을 교차 검증하려면 어떻게 시작하나요?
Agent가 가져온 동일한 원본 콘텐츠를 서로 다른 두 모델에 각각 전달해 요약하게 하세요. 그런 다음 차이가 가장 큰 항목부터 원문으로 돌아가 확인하면 돼요. APIYI apiyi.com 같은 통합 플랫폼을 이용하면 동일한 OpenAI 호환 인터페이스로 모델을 바꿔 쓸 수 있어, 여러 서비스를 각각 연동하는 번거로움을 줄일 수 있어요.
Q6: Agent 요약의 오류율은 대략 얼마나 되나요?
현재 참고한 자료에는 관련 통계가 없고 사례도 하나뿐이라 신뢰할 만한 수치를 제시할 수 없어요. 요약에는 오류가 있을 수 있다고 전제하고, ‘의심스러울 때만 확인’하기보다 검증을 필수 절차로 삼는 편이 안전해요.
Q7: 목록에 나온 반응 수를 글에 써도 되나요?
참고할 수는 있지만, 직접적인 논거로 쓰는 것은 권장하지 않아요. 반응 수는 수집 시점의 수치이며 이후에 달라질 수 있어요. 꼭 써야 한다면 확인 날짜를 밝히세요. 자료를 고를 때는 좋아요 수보다 답변 자체의 품질을 살펴보는 것이 중요해요.
Q8: 홍보 게시물에 나온 사례도 참고할 수 있나요?
참고할 수 있지만, 자료의 성격을 분명히 알아야 해요. 홍보 게시물은 대개 한 번의 순조로운 사용 과정만 보여주므로 일반적인 효과를 대표하지 않아요. 인용할 때는 출처의 성격을 밝히고, 이 글에서 참고 사례를 다룬 것처럼 구체적인 주장도 검증이 필요한 정보로 취급해야 해요.
Agent 자료 조사 검증 Key Takeaways
- 목록은 골라 읽기 위한 도구예요: Agent가 정리한 목록은 빠르게 훑고 주제의 실마리를 찾는 데 적합하지만, 그대로 인용 근거로 삼을 수는 없어요.
- 성공했다고 내용을 가져온 것은 아니에요: 읽기 명령이 정상 종료됐더라도 결과에 실제 본문이 있는지 먼저 확인하세요.
- 페이지가 나뉘거나 내용이 잘렸다면 불완전해요:
hasNextPage나 잘린 미리보기가 보인다면 확보한 자료는 첫 번째 묶음일 뿐이에요. - 반응 수는 특정 시점의 기록이에요: 수집 시점의 수치는 바뀔 수 있으므로, 인용할 때 시점을 밝히거나 숫자를 아예 쓰지 마세요.
- 요약한 내용은 반드시 원문으로 돌아가야 해요: 요약에 담긴 사례와 의견은 인용하기 전에 원래 답변과 하나씩 대조하세요.
- 사례 하나로는 부족해요: 실마리를 찾은 뒤에는 사례를 더 모아 그 단서가 대표성이 있는지 확인하세요.
- 여러 모델로 교차 검토해요: APIYI apiyi.com의 통합 인터페이스를 통해 여러 모델이 만든 요약의 차이를 비교할 수 있어요.
정리
Agent가 자료를 조사한 뒤 작성자가 직접 확인해야 할 일은 네 가지로 정리할 수 있어요.
- 출처: 모든 내용을 구체적인 페이지와 작성자까지 추적할 수 있어야 해요. 출처를 찾을 수 없다면 영감으로만 활용하세요.
- 완전성: 페이지 분할, 내용 잘림, 읽기 실패에 주의하고, 첫 번째 결과 묶음을 전체로 여기지 마세요.
- 시의성: 반응 수와 문서 내용은 특정 시점의 기록이므로 인용할 때 시점을 밝히세요.
- 요약과 원문의 차이: 요약은 원문 그대로가 아니에요. 인용하기 전에 원문과 하나씩 대조하세요.
‘기술 혁신’부터 ‘급하게 부품이 부족할 때 직접 출력해야 할까’까지, Agent는 자료를 찾는 시간을 줄여줘요. 하지만 주제가 타당한지, 자료를 인용할 수 있는지는 여전히 직접 원문을 읽고 판단해야 해요. Agent를 자료 조사 도우미로 활용하고 검증을 고정된 절차로 삼아야 빠르면서도 신뢰할 수 있는 결과를 얻을 수 있어요.
검증 단계에서 한 번 더 확인하고 싶다면 APIYI apiyi.com을 통해 여러 모델을 호출해 요약을 교차 비교해 보세요. 익숙한 웹페이지 하나부터 시작해 이 과정을 끝까지 따라가 보는 것도 좋아요.
📚 참고 자료
- V2EX 공유 게시글 – 동료가 Moli + Codex로 Quora를 읽고 답변 10개에서 주제를 찾는 과정: 이 글의 사례 출처(홍보 게시글로 표시됨)
- 링크:
www.v2ex.com/t/1254246 -
설명: 주제 링크 확인부터 목록 정리까지의 전체 과정을 담고 있으며, 첫 읽기 실패와 페이지네이션, 내용 잘림 등의 세부 사항도 포함해요.
-
Moli 오픈소스 프로젝트 공식 저장소: AI Agent를 위한 오픈소스 브라우저
- 링크:
github.com/lexmount/moli - 설명: Moli의 설치 방법과 기능을 확인할 수 있어요. 이 사례에서는 콘텐츠 읽기와 네트워크 응답 검사 기능을 사용했어요.
작성자: APIYI 기술팀
기술 교류: APIYI 웹사이트 홈에서 문의해 주세요. 여러 모델 호출에 관한 더 많은 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있어요.
