문서 작성 에이전트는 글을 대신 써 주는 기계가 아니다. 더 정확히 말하면, 아무 글이나 그럴듯하게 늘어놓는 모델을 목적에 맞는 문서를 안정적으로 생산하는 시스템으로 바꾸는 설계다. 여기서 중요한 것은 문장력이 아니라 맥락의 배열이다. 누가 읽는지, 왜 쓰는지, 어떤 톤으로 써야 하는지, 어떤 형식 제약이 있는지, 무엇을 근거로 말해야 하는지, 어느 단계에서 스스로 검토해야 하는지를 한 흐름으로 묶어야 한다.
문서 작성 에이전트를 처음 붙일 때 많은 팀이 같은 실수를 한다. "블로그 글 하나 써 줘", "제안서 초안 작성해 줘", "보도자료 스타일로 바꿔 줘" 같은 요청을 한 번 던지고, 결과가 마음에 안 들면 모델 탓을 한다. 하지만 실제 문제는 대개 모델이 아니라 입력 환경의 빈약함에 있다. 사람도 마찬가지다. 독자도 모르고, 목적도 모른 채, 참고 자료도 없이, 톤만 "전문적으로"라고 적어 놓으면 좋은 글이 나오기 어렵다. AI도 똑같다.
문서 작성 에이전트의 진짜 일은 글 생성이 아니라 글쓰기 시스템화다
리서치 에이전트가 근거를 모으는 조사팀이라면, 문서 작성 에이전트는 그 재료를 독자가 읽을 수 있는 결과물로 바꾸는 편집팀에 가깝다. 조사 단계가 "무엇이 사실인가"를 다룬다면, 작성 단계는 "무엇을 어떤 순서와 목소리로 전달할 것인가"를 다룬다.
이 차이는 꽤 크다. 같은 사실을 가지고도 문서는 완전히 달라질 수 있다. 경영진 보고서는 결론이 먼저 와야 하고, 제품 소개서는 장점이 빠르게 보여야 하며, 고객지원 문서는 애매한 표현보다 즉시 실행 가능한 안내가 중요하다. 즉 문서 작성 에이전트는 사실을 문장으로 옮기는 것이 아니라, 독자에게 맞는 정보 구조를 선택해야 한다.
여기서 마이크로소프트 연구가 던지는 통찰이 있다. LLM 기반 글쓰기 도구는 단순히 생산성을 높이는 것만이 아니라, 사용자의 편집 판단과 주도권에 영향을 준다. 잘 설계된 도구는 사람을 밀어내지 않고, 사람의 판단을 돕는 방식으로 작동해야 한다.1 문서 작성 에이전트가 유용하려면 "내 대신 다 써 줘"보다 "내가 더 잘 쓰게 도와줘"와 "반복되는 부분은 대신 처리해 줘" 사이의 균형을 잡아야 한다.
시작점은 언제나 독자와 목적이다
문서를 쓰기 전에 가장 먼저 정해야 하는 것은 주제가 아니다. 독자와 목적이다. 주제는 같아도 독자와 목적이 달라지면 문서는 거의 새로 써야 한다.
예를 들어 같은 "사내 AI 도입 정책"이라는 주제도 이렇게 갈린다. 경영진에게는 위험과 투자 대비 효과가 중요하고, 실무자에게는 승인 절차와 사용 금지 사례가 중요하며, 법무팀에게는 개인정보와 감사 추적이 중요하다. 문서 작성 에이전트는 이 차이를 프롬프트 한 줄로 얼버무리면 안 된다. 시작 상태에서 아예 구조화해 두는 편이 낫다.
실전에서는 최소한 다음 항목을 입력 변수로 분리해 두면 좋다.
독자: 누가 읽는가
목적: 읽고 난 뒤 무엇이 달라져야 하는가
문서 유형: 보고서, 제안서, 이메일, 가이드, FAQ 중 무엇인가
기대 행동: 승인, 이해, 구매, 회신, 실행 중 무엇을 유도하는가
허용 톤: 단정적, 친절한, 권위 있는, 담백한 등 어떤 범위까지 허용되는가
이 다섯 가지가 없으면 에이전트는 보통 가장 평균적인 글을 만든다. 평균적인 글은 겉보기엔 무난하지만, 실제 업무에서는 자주 쓸모가 없다. 누구에게도 정확히 맞지 않기 때문이다.
톤은 분위기가 아니라 의사결정 규칙이다
많은 팀이 톤을 감성적 지시로만 다룬다. "세련되게", "신뢰감 있게", "브랜드답게" 같은 표현이 대표적이다. 문제는 이런 말이 사람에게도 모호하다는 점이다. 모델에게는 더 모호하다.
그래서 톤은 분위기 설명보다 선택 규칙으로 바꾸는 편이 훨씬 강하다. 예를 들어 "친절한 톤"이라고만 쓰지 말고, 다음처럼 행동 규칙으로 풀어 쓰는 것이다.
어려운 용어를 쓰면 바로 짧게 풀어 설명한다.
과장 표현은 피하고, 근거가 있는 주장만 강하게 말한다.
독자를 몰아붙이는 명령형보다 안내형 문장을 우선한다.
한 문단에는 하나의 핵심만 담는다.
이렇게 해 두면 톤이 문체 취향이 아니라 문장 선택 알고리즘이 된다. 좋은 지시문은 감상문이 아니라 운영 규칙에 가깝다.
브랜드 보이스도 마찬가지다. 브랜드 보이스는 멋진 슬로건 몇 개가 아니라, 반복되는 어휘 선택과 문장 리듬, 금지 표현, 강조 순서의 집합이다. 자주 쓰는 서두, 피해야 할 표현, 숫자를 다루는 방식, 고객을 부르는 호칭, CTA의 톤까지 포함해야 한다. 이런 정보는 매번 대화에서 다시 설명하기보다, 상시 참조 문서나 메모리로 관리하는 편이 안정적이다. LangChain 문서는 런타임마다 바뀌지 않는 지시와 도구, 사용자 메타데이터 같은 정적 맥락과, 실행 중 변하는 대화·중간 결과 같은 동적 맥락을 구분해 다루는 것이 중요하다고 설명한다.2 문서 작성 에이전트에서 브랜드 가이드는 대표적인 정적 맥락이다.
형식은 마지막 장식이 아니라 초반의 제약 조건이다
문서를 다 쓴 뒤 형식을 맞추려 하면 거의 항상 두 번 일하게 된다. 처음부터 형식을 설계하면 불필요한 재작성 비용을 줄일 수 있다.
예를 들어 문서 유형별로 요구하는 구조는 꽤 다르다. 제안서는 문제-해결-효과-실행계획이 자연스럽고, 블로그 글은 문제 제기-설명-사례-정리 흐름이 잘 맞는다. 고객 공지는 결론-변경 사항-영향 범위-일정-문의 채널 구조가 읽기 쉽다. 형식은 말하자면 에이전트에게 주는 레일이다. 레일이 없으면 모델은 자꾸 예쁜 우회로를 만든다.
실전에서 형식 설계는 두 층으로 나누면 편하다. 하나는 문서 전체 구조다. 다른 하나는 각 섹션의 작성 규칙이다. 예를 들어 전체 구조가 "요약-배경-핵심 내용-예시-다음 행동"이라면, 섹션 규칙은 "요약은 3문장 이내", "배경은 이전 상황만 설명", "핵심 내용은 번호보다 소제목 중심"처럼 둘 수 있다. 이 정도만 해도 출력이 훨씬 재현 가능해진다.
참고 자료는 넣는다고 끝이 아니라, 역할을 나눠 넣어야 한다
문서 작성 에이전트의 품질은 참고 자료를 얼마나 많이 넣느냐보다, 무슨 역할의 자료를 어떤 타이밍에 넣느냐에 달려 있다. 모든 문서를 한 번에 몰아 넣으면 오히려 핵심이 흐려진다.
작성 시스템에서 참고 자료는 보통 네 가지 역할로 나눌 수 있다.
첫째는 사실 근거 자료다. 제품 문서, 정책 문서, 조사 결과, 인터뷰 메모처럼 "무엇이 사실인가"를 떠받치는 재료다.
둘째는 스타일 자료다. 과거에 잘 쓴 문서, 브랜드 가이드, 금지 표현 목록처럼 "어떻게 말할 것인가"를 정하는 재료다.
셋째는 형식 자료다. 템플릿, 샘플 구조, 제출 양식처럼 "어떤 틀로 쓸 것인가"를 정하는 재료다.
넷째는 검수 자료다. 체크리스트, 평가 루브릭, 승인 기준처럼 "무엇을 통과해야 하는가"를 정하는 재료다.
이 네 역할을 구분하지 않으면 이상한 일이 벌어진다. 예를 들어 스타일 문서를 사실 근거처럼 인용하거나, 제품 FAQ를 브랜드 보이스 규칙처럼 따라 버리기도 한다. 문서 작성 에이전트는 자료를 읽는 것만이 아니라, 자료의 용도를 구분해야 한다.
좋은 글쓰기 시스템은 한 번에 쓰지 않고, 단계별로 쓴다
사람도 중요한 문서를 한 번에 끝내지 않는다. 개요를 잡고, 초안을 쓰고, 이상한 부분을 고치고, 논리를 다듬고, 문체를 정리한다. 문서 작성 에이전트도 이 순서를 따라야 안정적이다.
가장 실용적인 기본 파이프라인은 다음과 같다.
브리프 정리: 독자, 목적, 톤, 형식, 핵심 메시지 확인
자료 선택: 사실 근거, 스타일 가이드, 템플릿 불러오기
개요 작성: 문서 구조와 섹션별 목적 정의
초안 작성: 구조를 따라 첫 버전 생성
비평: 요구사항, 근거, 톤, 누락, 과장을 점검
수정: 비평에 따라 고친 뒤 최종본 정리
겉으로 보면 단순하지만, 이 파이프라인이 중요한 이유는 각 단계의 목표가 다르기 때문이다. 개요 단계에서 문장 미세수정에 집착하면 큰 구조를 놓치고, 초안 단계에서 완벽한 문체를 요구하면 속도가 떨어진다. 반대로 비평 단계 없이 바로 배포하면 그럴듯한 오류가 그대로 나간다.
에이전트 설계 패턴 관점에서도 이런 순차 흐름은 매우 자연스럽다. 계획하고, 실행하고, 정제하는 흐름은 글쓰기 같은 복합 작업에서 특히 잘 맞는다.3
개요 단계가 약하면 초안은 화려하게 흔들린다
문서 작성 에이전트에서 가장 저평가되는 단계가 개요 작성이다. 하지만 실제로는 여기서 승부가 많이 난다. 개요는 단순한 목차가 아니라, 각 섹션의 임무를 정하는 설계도다.
좋은 개요는 최소한 세 가지를 담아야 한다. 각 섹션이 답할 질문, 그 섹션에서 사용해야 할 근거, 그리고 독자가 그 섹션을 읽고 가져가야 할 메시지다. 예를 들어 제품 소개 글이라면 "문제 제기" 섹션은 독자의 불편을 이름 붙이는 역할을 하고, "해결 방식" 섹션은 기능 나열이 아니라 작동 원리를 이해시키는 역할을 하며, "도입 효과" 섹션은 숫자와 사례로 신뢰를 만드는 역할을 한다.
이렇게 섹션별 임무를 먼저 정해 두면 초안 단계에서 모델이 갑자기 본론을 잊고 멋진 서론을 길게 쓰는 일을 줄일 수 있다. 개요가 튼튼하면 문체가 조금 흔들려도 고치기 쉽다. 개요가 약하면 문체가 좋아 보여도 전체 문서는 쉽게 무너진다.
초안은 완성본이 아니라 재료다
많은 팀이 AI 초안을 받아 들면 두 극단으로 간다. 한쪽은 거의 그대로 써 버리고, 다른 한쪽은 너무 엉망이라며 전부 다시 쓴다. 둘 다 아깝다. 초안은 완성품보다 가공 가능한 재료로 보는 편이 낫다.
초안 단계의 목표는 딱 세 가지면 충분하다. 구조를 세우고, 핵심 메시지를 문장으로 꺼내고, 비어 있는 구멍을 드러내는 것이다. 이 단계에서 지나치게 매끈한 문장을 요구하면, 오히려 중요한 빈칸이 숨는다. 초안은 조금 거칠어도 된다. 대신 어디가 약한지 보여 줘야 한다.
이 관점은 인간의 글쓰기 주도권을 지키는 데도 도움이 된다. 글쓰기 도구가 사람 대신 완성본을 만들어 주면 편하긴 하지만, 그만큼 사용자의 판단과 목소리가 밀려날 수 있다.1 그래서 중요한 문서일수록 초안은 넓게 만들고, 결정은 사람이나 이후의 비평 단계에서 내리게 하는 편이 낫다.
비평자는 작가와 다른 역할이어야 한다
문서 작성 에이전트에서 품질을 크게 끌어올리는 지점은 대개 초안이 아니라 비평 단계다. 다만 여기에는 조건이 있다. 비평자는 작가와 다른 목표를 가져야 한다.
작가의 목표는 글을 전진시키는 것이다. 반면 비평자의 목표는 멈추게 하는 것이다. 빠진 근거가 있으면 멈추고, 톤이 어긋나면 멈추고, 요구 형식을 어기면 멈추고, 과장 표현이 있으면 멈춘다. 이 둘을 같은 모드로 섞어 두면 모델은 종종 자기 글을 변호해 버린다.
Self-refine 계열 가이드와 실무 정리들이 공통으로 강조하는 것도 이 지점이다. 초안 생성, 비평, 수정은 서로 다른 목적을 가진 단계로 분리할 때 가장 효과적이다. 특히 비평은 막연한 "더 좋아지게 해 줘"가 아니라, 명시된 루브릭에 따라 무엇이 틀렸고 무엇을 고쳐야 하는지 지적해야 한다.45
좋은 비평 루브릭은 대개 이런 질문을 포함한다.
이 문서는 요청한 독자에게 맞는가
목적이 첫 부분에서 분명히 드러나는가
핵심 주장마다 근거나 예시가 있는가
브랜드 보이스를 벗어난 표현이 있는가
불필요하게 길거나 반복되는 부분이 있는가
출력 형식과 분량 제약을 지켰는가
여기서 핵심은 점수놀이가 아니다. 수정 가능한 피드백이어야 한다는 점이다. "조금 더 명확하게"는 나쁜 비평이다. "2번째 문단은 기능 설명이 길고 독자 이점이 보이지 않으니, 결과 중심으로 재구성하라"는 좋은 비평이다.
비평은 자유 감상이 아니라 구조화된 판정이어야 한다
비평 단계를 강하게 만들고 싶다면 출력 형식을 구조화해야 한다. 예를 들면 verdict, issues, fixes 같은 필드를 쓰는 방식이 좋다. Arun Baby의 정리도 신뢰할 수 있는 비평 루프는 PASS/FAIL, 이슈 위치, 심각도, 수정 지시처럼 구조화된 결과를 만들 때 훨씬 쓸모가 커진다고 설명한다.5
실전에서는 다음과 같은 형식이 잘 작동한다.
판정: 통과 / 수정 필요
치명 이슈: 배포 전에 반드시 고쳐야 할 문제
보통 이슈: 품질을 떨어뜨리지만 배포를 막지는 않는 문제
근거 부족 문장: 출처 또는 예시 보강이 필요한 문장
톤 이탈 문장: 브랜드 보이스를 벗어난 표현
수정 지시: 문장 교체가 아니라, 무엇을 어떤 방향으로 바꿀지에 대한 지시
이렇게 하면 비평 단계가 막연한 잔소리가 아니라, 수정 엔진에 바로 넣을 수 있는 작업 목록이 된다.
수정 단계는 새로 쓰기가 아니라 패치 작업이어야 한다
수정 단계에서 흔히 생기는 문제는 초안 전체를 다시 써 버리는 것이다. 그러면 좋아진 부분도 사라지고, 브랜드 보이스가 흔들리고, 근거 연결도 끊어질 수 있다. 수정은 가능하면 국소적 패치로 설계하는 편이 좋다.
예를 들어 비평에서 "3문단은 주장에 비해 예시가 약하다"고 나왔다면, 수정자는 3문단만 보강해야 한다. "전체를 더 설득력 있게 다시 써라" 같은 명령은 지나치게 넓다. 넓은 수정은 종종 예상치 못한 부작용을 낳는다.
또 하나 중요한 점이 있다. 자기 비평 기반 수정은 새로운 정보가 없으면 같은 오류를 더 매끈하게 다듬을 수 있다. Self-refine 가이드도 모델이 모르는 사실을 자기 힘으로 검증할 수는 없다고 경고한다.4 따라서 수정 단계는 비평만 넣는 것으로 끝내지 말고, 필요하면 다시 참고 자료를 조회하거나 근거 문장을 함께 제공해야 한다. 문서 작성 에이전트는 생각보다 자주 "고치는 단계에서 다시 찾는 단계"로 되돌아가야 한다.
브랜드 보이스는 프롬프트가 아니라 자산으로 관리해야 한다
브랜드 보이스를 매번 대화창에 길게 붙여 넣는 방식은 금방 무너진다. 길어질수록 중요도는 희미해지고, 작성 작업마다 조금씩 다른 버전이 섞이기 쉽다. 그래서 브랜드 보이스는 일회성 입력보다 지속 관리되는 자산으로 다루는 편이 좋다.
실전에서는 브랜드 보이스 패키지를 다음처럼 구성할 수 있다.
브랜드 핵심 원칙 3~5개
자주 쓰는 표현과 피해야 할 표현
문장 길이와 단락 길이 기준
숫자와 근거를 다루는 방식
독자 호칭 규칙
좋은 예시와 나쁜 예시 한 쌍
특히 예시는 강력하다. "우리는 따뜻하고 전문적이다"보다, 같은 내용을 좋은 문장과 나쁜 문장으로 보여 주는 편이 모델이 훨씬 잘 따른다. Deep Agents 문서가 AGENTS.md 같은 항상 로드되는 메모리는 최소한의 핵심 규칙만 담고, 더 자세한 워크플로는 필요할 때 불러오는 기술로 분리하라고 설명하는 이유도 여기에 있다.6 브랜드의 항상 지켜야 할 규칙은 짧고 강하게, 세부 스타일 가이드는 필요할 때 선택적으로 불러오는 편이 좋다.
사람의 개입 지점을 없애지 말고, 똑똑하게 배치하라
문서 작성 에이전트가 잘 작동할수록 사람은 빠지기 쉬워 보인다. 하지만 실제로는 반대다. 중요한 문서일수록 사람의 개입 지점은 더 중요해진다. 다만 개입 방식이 바뀔 뿐이다.
사람은 이제 문장을 하나하나 직접 쓰기보다, 더 상위의 의사결정에 개입하는 편이 효율적이다. 예를 들어 이런 지점이다.
브리프 승인: 이 문서의 독자와 목적 정의가 맞는가
개요 승인: 지금 구조가 정말 설득 경로에 맞는가
핵심 메시지 승인: 이 문서가 밀어야 할 메시지가 분명한가
배포 전 승인: 사실, 톤, 리스크 측면에서 공개 가능한가
이런 구조는 사람의 시간을 줄이면서도 주도권을 잃지 않게 한다. AI가 빈 페이지의 공포를 줄여 주되, 최종 방향키는 사람이 잡는 셈이다. 이는 글쓰기 지원 도구가 사용자의 주체성을 해치지 않도록 설계해야 한다는 연구의 방향과도 맞닿아 있다.1
문서 종류별로 파이프라인을 조금씩 다르게 설계하라
문서 작성 에이전트는 하나의 범용 파이프라인으로도 꽤 많은 일을 할 수 있다. 하지만 품질을 한 단계 더 올리고 싶다면 문서 유형별로 비평 기준과 자료 묶음을 조금씩 바꾸는 편이 좋다.
예를 들어 블로그 글은 흥미로운 도입과 독자 친화성이 중요하다. 반면 제안서는 리스크 관리와 실행 가능성이 더 중요하다. 고객 메일은 짧고 분명한 행동 요청이 핵심이고, 정책 문서는 해석의 여지를 줄이는 쪽이 중요하다. 즉 작성 시스템은 "문서 생성기"가 아니라, 실제로는 여러 개의 문서별 미니 에이전트 모음에 가깝다.
이때 바뀌어야 하는 것은 모델보다 루브릭이다. 같은 초안이라도 블로그용 비평자는 "읽는 맛"을 보지만, 제안서용 비평자는 "의사결정 가능성"을 봐야 한다. 고객지원 문서용 비평자는 "애매함 제거"와 "행동 가능성"을 우선 봐야 한다. 좋은 문서 작성 에이전트는 결국 글쓰기의 정답을 찾는 시스템이 아니라, 문서별 성공 기준을 정확히 구분하는 시스템이다.
한 가지 실전 예시로 전체 흐름을 묶어 보자
가령 당신이 신제품 출시 소개서를 만드는 에이전트를 설계한다고 해 보자. 사용자는 "새 협업 기능을 소개하는 1200자 내외 블로그 초안"을 요청한다. 여기서 바로 글을 쓰게 하면 십중팔구 기능 나열형 소개문이 나온다.
더 나은 흐름은 이렇다. 먼저 브리프 단계에서 독자를 "기존 사용자", 목적을 "새 기능의 필요성과 사용 장면 이해", 톤을 "친절하지만 과장 없는 제품팀 톤", 형식을 "문제-해결-활용 예시-시작 방법"으로 정한다. 다음으로 참고 자료를 불러온다. 기능 명세 문서, 과거 출시 글 중 잘된 예시, 브랜드 보이스 가이드, 금지 표현 목록을 각각 다른 역할로 제공한다. 그 뒤 개요를 만든다. 예를 들어 1단락은 기존 협업의 불편, 2단락은 기능 소개, 3단락은 실제 사용 장면, 4단락은 시작 방법이라는 식이다. 초안이 나오면 비평자가 본다. 과장 표현이 있는지, 실제 사용자 가치가 먼저 나오는지, 기능 설명이 내부 용어 중심으로 흐르지 않았는지, CTA가 지나치게 공격적이지 않은지 점검한다. 그다음 수정자는 문제 문단만 고친다.
이렇게 설계하면 결과는 단순히 "잘 쓴 글"이 아니라, 다음 출시 글에도 거의 그대로 재사용 가능한 글쓰기 파이프라인이 된다. 바로 이 재사용성이 실무에서 가장 큰 힘이다.
자주 실패하는 문서 작성 에이전트의 패턴
실패 패턴은 놀라울 만큼 반복적이다.
첫 번째는 독자 없는 글쓰기다. 정보는 맞는데 누구를 위한 문서인지 보이지 않는다.
두 번째는 스타일과 사실의 혼선이다. 브랜드 보이스 문서에 있는 과장 어조를 사실 근거처럼 사용하거나, 반대로 딱딱한 정책 문체를 마케팅 문서에 끌고 온다.
세 번째는 초안 과신이다. 첫 버전이 유창하다는 이유로 검수를 생략한다.
네 번째는 비평의 저품질이다. "더 자연스럽게" 같은 모호한 피드백만 반복되어 실제 개선이 일어나지 않는다.
다섯 번째는 수정의 폭주다. 문제 문단만 고치면 되는데 전체를 다시 써서 좋은 부분까지 날려 버린다.
여섯 번째는 사람의 승인 지점 부재다. 중요한 판단이 자동화 파이프라인에 숨어 버려, 나중에 왜 이런 문장이 나왔는지 설명하기 어려워진다.
이 패턴을 피하려면 화려한 에이전트 구조보다 먼저, 입력 변수와 비평 루브릭부터 단단히 만드는 편이 낫다.
좋은 문서 작성 에이전트는 작가가 아니라 편집 시스템에 가깝다
결국 문서 작성 에이전트의 핵심은 "글을 잘 쓰는 모델"을 고르는 데 있지 않다. 독자, 목적, 톤, 형식, 근거, 스타일, 비평, 수정이라는 요소를 끊기지 않는 한 줄의 작업 흐름으로 연결하는 데 있다.
좋은 시스템은 첫 문장을 멋지게 시작하는 능력보다 더 중요한 것을 갖는다. 무엇을 쓰지 말아야 하는지 알고, 어떤 근거가 비어 있는지 찾고, 브랜드 목소리를 지키며, 초안을 비평하고, 수정 범위를 통제하고, 사람에게 다시 물어봐야 할 순간을 안다. 이런 시스템은 글을 "생성"하는 것을 넘어, 문서를 운영한다.
프롬프트 한 번으로 기적 같은 글을 기대하는 단계는 이제 지났다. 실무에서 필요한 것은 언제나 비슷하다. 반복 가능하고, 점검 가능하고, 팀의 목소리를 잃지 않으면서도, 빈 페이지를 빠르게 넘어설 수 있는 글쓰기 시스템. 문서 작성 에이전트는 바로 그 시스템의 이름이다.
참고
1"Helping Me Versus Doing It for Me": Designing for Agency in LLM-Infused Writing Tools
3Design Patterns for LLM Agent Systems
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.