프롬프트 인젝션: 공격 유형부터 AI 에이전트 방어까지

에이전트가 읽은 이메일이 다른 이메일을 보내거나 고객 데이터를 내보내거나 거래 정보를 바꿀 수 있는 허가가 되어서는 안 됩니다. Open Worldwide Application Security Project(OWASP)는 LLM 애플리케이션 Top 10에서 프롬프트 인젝션을 LLM01으로 분류합니다. 개발자가 취해야 할 실질적인 대응은 모델이 잘못된 지시를 따르더라도 애플리케이션이 할 수 있는 일을 제한하는 것입니다. 현재 프롬프트 인젝션을 완전히 해결하는 방어책은 없습니다.

2026년 10월 26일 기준 OWASP와 Anthropic의 최신 지침을 대조해 검증했습니다. 아래의 메일함 및 CRM 시나리오는 설계를 설명하기 위한 예시이며, 실제 도입 결과를 보고한 것이 아닙니다.

프롬프트 인젝션이란?

프롬프트 인젝션(prompt injection)은 입력된 내용이 언어 모델을 원래 따라야 할 지시에서 벗어나게 만드는 현상입니다. 대규모 언어 모델(LLM)은 언어를 해석해 답변을 생성하고 실행할 작업을 제안합니다. 단순히 읽어야 할 내용을 따라야 할 지시로 받아들이는 순간 문제가 시작됩니다.

직원이 공급업체의 서신을 검토하는 상황을 생각해 보겠습니다. 서신에는 배송 문제를 설명할 수 있지만, 그 서신이 공급업체에 고객 데이터베이스 접근 권한을 부여할 수는 없습니다. 에이전트도 이처럼 정보와 권한을 구분해야 하며, 애플리케이션의 통제 장치가 그 구분을 강제해야 합니다.

OWASP는 LLM01:2025 프롬프트 인젝션에서 사용자의 직접 입력과 외부 콘텐츠를 통한 간접 입력을 모두 공격의 유입 경로로 지목합니다. 중요한 기준은 누가 작업과 권한을 정할 수 있느냐입니다. 의심스러운 문구가 전문적으로 보이는지는 그 기준이 될 수 없습니다.

답변이 틀렸다고 해서 곧바로 인젝션인 것은 아닙니다. 외부의 조작 없이도 모델이 사실을 지어낼 수 있습니다. 인젝션은 입력이 모델의 행동을 유도하는 경우를 가리킵니다. 둘 다 피해를 일으킬 수 있지만, 악성 지시를 찾는 필터가 일반적인 모델 오류까지 모두 잡아내지는 못합니다.

생성형 AI에서 프롬프트 인젝션은 어떻게 작동합니까?

모델은 지시와 작업 자료를 함께 읽으면서 자료에 원래 없는 지시 권한을 부여할 수 있습니다. 역할 구분과 출처 표시는 둘을 구별하는 데 도움이 되지만, 접근 통제를 대신하지는 못합니다.

에이전트에서는 그다음 단계가 실제 결과로 이어집니다. 애플리케이션이 모델의 작업 제안을 툴 호출로 바꾸기 때문입니다. 툴은 레코드 검색이나 메시지 전송처럼 대화 밖에서 일을 수행하는 함수입니다. 애플리케이션이 폭넓은 권한을 가진 인증 정보로 모델의 제안을 그대로 실행하면, 언어 해석의 오류가 실제 업무상의 조치로 이어질 수 있습니다.

툴을 사용하는 모든 에이전트가 마주하는 한계가 여기에 있습니다. 요청을 이해했다는 사실만으로 그 요청이 승인된 것은 아닙니다.

프롬프트 인젝션 예시: 직접 공격과 간접 공격

둘의 차이는 악성 지시가 어디에서 들어오느냐에 있습니다. 다음 예시는 공격 문구를 공개하지 않고 공격자가 유도하려는 행동을 설명합니다.

직접 프롬프트 인젝션

고객이 지원용 어시스턴트에 직접 입력하면서 특별한 내부 승인을 받은 요청인 것처럼 꾸며, 다른 고객의 계정 메모를 공개하도록 유도합니다. 공격자가 애플리케이션의 입력 채널을 직접 사용하는 경우입니다.

방어 설계에는 인증된 고객의 접근 권한을 확인하는 레코드 서비스가 반드시 포함되어야 합니다. 모델이 그 주장을 믿더라도 서비스는 무관한 레코드에 대한 접근을 거부해야 합니다. 시스템 프롬프트에 거부 지침을 넣는 것은 도움이 됩니다. 하지만 실제로 접근 경계를 지키는 것은 레코드에 대한 권한 검사입니다.

간접 프롬프트 인젝션

직접 영업에 나선 창업자가 에이전트에게 잠재 고객의 이메일을 요약하고 다음 조치를 제안해 달라고 요청합니다. 그런데 이메일에는 고객 관계 관리 시스템(CRM)에서 이 업무와 무관한 연락처를 외부 수신자에게 내보내도록 에이전트를 유도하는 내용이 들어 있습니다. 창업자의 요청 자체는 정당합니다. 악성 지시는 처리 대상인 이메일에서 들어옵니다.

웹페이지, 문서, 첨부 파일, 툴 실행 결과도 같은 유입 경로가 될 수 있습니다. 내부 저장소에 있다는 이유만으로 모든 레코드를 신뢰할 수는 없습니다. 지금 CRM에 들어 있는 텍스트도 고객이 제공한 내용일 수 있습니다. Claude 언어 모델을 개발한 Anthropic은 프롬프트 인젝션 방어 지침에서 이런 제3자 출처를 별도의 위협 모델로 다룹니다.

메일함 에이전트에서는 메일함 소유자가 요약을 요청했다는 이유만으로 이메일 발신자가 소유자의 툴 사용 권한까지 넘겨받아서는 안 됩니다.

프롬프트 인젝션과 탈옥은 어떻게 다릅니까?

탈옥(jailbreak)은 모델의 안전 제한을 우회하려는 시도입니다. 프롬프트 인젝션은 애플리케이션의 일반적인 작업이나 권한도 공격 대상으로 삼을 수 있습니다. 조작된 영업 요약이나 권한 없는 연락처 수정은 콘텐츠 모더레이션 시스템에는 무해해 보이면서도 회사의 업무 규칙을 위반할 수 있습니다.

콘텐츠 안전장치와 권한 검사를 함께 사용해야 합니다. 두 장치가 판단하는 대상은 서로 다릅니다.

프롬프트 인젝션 공격은 왜 비즈니스 위험이 됩니까?

에이전트가 접근할 수 있는 데이터와 실행할 수 있는 작업이 많아질수록 피해도 커집니다. OWASP는 별도의 과도한 에이전트 권한 지침에서 지나치게 많은 기능과 권한, 자율성을 에이전트가 피해를 일으키는 원인으로 지목합니다.

메일함이나 CRM 시스템에서 발생할 수 있는 피해는 익숙한 업무 사고의 형태로 나타납니다.

• 비공개 데이터가 유출됩니다. 출력, 첨부 파일, 외부로 나가는 요청이나 메시지에 수신자가 받아서는 안 되는 정보가 포함됩니다.
• 권한 없이 레코드가 바뀝니다. 검색해 가져온 텍스트가 에이전트를 다른 방향으로 유도해 계정을 수정하거나 유용한 이력을 삭제하거나 거래 단계를 변경합니다.
• 의사결정이 눈에 띄지 않게 왜곡됩니다. 잠재 고객의 유망도가 부풀려지고, 요약에서 불만 사항이 사라지거나, 근거 없이 특정 공급업체를 추천하게 됩니다.

읽기 전용 권한은 쓰기 권한보다 범위가 좁지만, 기밀 데이터가 유출되지 않는다는 뜻은 아닙니다. 애플리케이션이 비공개 레코드를 조회하고 답변이나 외부 연결을 통해 이를 공개할 수 있다면, 여전히 기밀성을 보호해야 합니다.

Palo Alto Networks의 Unit 42는 2026년 3월 3일 발표한 연구에서 실제 웹 콘텐츠에 삽입된 악성 지시를 기록했습니다. 공격 시도를 발견했다는 사실이 모든 대상이 그 지시를 따랐다는 증거는 아닙니다. 다만 에이전트에 실행 권한을 주기 전에 외부 콘텐츠를 위협 모델에 포함해야 하는 이유는 보여줍니다.

창업자는 워크플로에서 허용할 수 있는 최대 피해 범위를 승인해야 합니다. 개발자는 데이터와 툴의 경계에서 그 한도가 실제로 지켜지도록 만들어야 합니다. 운영자에게는 이러한 경계를 넘으려는 시도가 발생했을 때 실행을 일시 중지하고 조사할 수단이 필요합니다.

프롬프트 인젝션 방어: 공격이 실제 사고로 이어지지 않게 하려면

인젝션이 방어를 통과할 수 있다는 전제로 설계해야 합니다. 다음은 OWASP의 권한 및 승인 지침을 메일함이나 CRM 에이전트의 구체적인 워크플로에 적용한 권장 통제 설계입니다. 제품 벤치마크가 아니며, 공격에 뚫리지 않는다는 보장도 아닙니다.

먼저 툴의 실제 권한을 확인해야 합니다. 함수 이름이 ‘메일함 요약’이어도, 그 함수가 사용하는 인증 정보로 메시지를 보내고 메일을 삭제할 수 있다면 기능이 요약에 한정된 것이 아닙니다. 함수 이름만 보지 말고 실제 계정과 서비스 설정을 확인해야 합니다.

다음으로 애플리케이션 밖으로 나가는 데이터를 통제해야 합니다. 허용된 목적지를 정하는 네트워크 허용 목록은 정보가 유출될 수 있는 경로를 줄이는 데 도움이 됩니다. 하지만 메일 서비스를 허용했다고 모든 수신자가 승인되는 것은 아닙니다. CRM 도메인을 허용했다고 모든 계정이나 내보내기 작업이 승인되는 것도 아닙니다. 허용된 서비스 안에서도 요청 내용을 검증해야 합니다.

Anthropic의 안전한 배포 지침은 인증 정보를 에이전트 환경 밖에 보관하고, 네트워크 접근을 제한하며, 프록시를 통해 요청을 검증하는 방식을 설명합니다. 프록시는 요청을 전달하기 전에 정책을 적용할 수 있는 중개 장치입니다. 호스팅 환경의 메일함 연동에서는 자체 툴 서비스가 이 경계 역할을 할 수 있습니다. 서비스가 인증 정보를 보관하고 허용 범위를 벗어난 작업을 거부하는 방식입니다.

입력, 출력, 실행 전반의 검사에 대해서는 AI 가드레일 가이드를 참고하십시오.

검색해 가져온 콘텐츠에 Anthropic 지침을 적용하려면

Anthropic은 제3자 자료를 tool_result 블록으로 전달하고, 출처를 명시하며, 신뢰할 수 없는 콘텐츠에 대한 정책을 분명히 설정할 것을 권장합니다. 문자열을 자유 형식의 지시에 끼워 넣는 대신 JSON으로 인코딩하는 방법도 권장합니다. 툴 출력 검사와 행동 모니터링 역시 지침에 포함됩니다. Claude의 현행 지침을 참고하십시오.

앞선 영업 예시에서는 잠재 고객의 이메일 본문이 해당 발신자에게서 온 이메일임을 계속 식별할 수 있어야 합니다. 이전 모델 단계에서 요약했다는 이유로 그 내용을 권한이 높은 지시에 복사해서는 안 됩니다. 추출한 정보를 다음 단계로 넘길 때도 출처 참조를 유지해야 합니다.

JSON은 구조화된 데이터 형식입니다. 텍스트를 올바르게 이스케이프하면 주변의 직렬화 구조가 깨지는 것을 막을 수 있지만, 그 텍스트의 의미에 모델이 설득되는 것까지 막지는 못합니다. 인코딩 권고는 방어 계층의 하나로 보고, 권한 검사는 별도의 지점에서 계속 강제해야 합니다.

승인은 검토한 바로 그 작업에만 적용되어야 합니다

검토 버튼이 비즈니스를 보호하려면, 실제 실행이 검토자가 확인한 내용에 종속되어야 합니다. 첨부 파일을 보내거나 고객 레코드를 다시 쓸 수 있는 에이전트에게 ‘이 계정 처리를 계속합니다’라는 승인은 너무 모호합니다.

잠재 고객에게 답장을 보내고 거래 정보를 업데이트하는 제안을 생각해 보겠습니다. 검토자는 실제 수신자, 메시지, 첨부 파일 목록, 대상 레코드, 필드의 변경 전후 값을 확인할 수 있어야 합니다. 애플리케이션은 승인된 제안을 보존하고 그 버전을 실행해야 합니다. 이후 모델이 수신자나 첨부 파일을 바꾼다면 다시 검토를 받아야 합니다.

승인하는 사람은 인증을 거쳐야 하며 해당 승인 권한도 갖고 있어야 합니다. 이메일 안에 누군가 이미 승인했다는 문장이 있어도, 그것은 자료의 내용이지 승인 이벤트가 아닙니다. 모델이 스스로 승인 기록을 만들거나 승인 절차를 우회하는 다른 툴에 접근할 수 있어서는 안 됩니다.

검토자가 거절했거나, 승인이 만료되었거나, 검토 시스템을 사용할 수 없다면 작업을 보류 상태로 유지해야 합니다. 시간 초과가 아무도 모르게 허가로 바뀌어서는 안 됩니다. 전송 실패로 재시도하더라도 이미 승인된 동일한 메시지가 반복 전송되지 않도록 설계해야 합니다.

이는 해당 워크플로를 위한 구현 권고이며, 사람이 검토하면 모든 공격을 잡아낼 수 있다는 주장이 아닙니다. 사람이 개입하는 AI 가이드에서는 검토 대기열에 인력을 배치하고 상위 담당자에게 사안을 넘기는 방법을 설명합니다.

메일함·CRM 에이전트 도입 전 확인할 사항

유용한 범위 안에서 가장 좁은 워크플로부터 출시해야 합니다. 외부에 영향을 미치는 작업을 자율 실행하도록 허용하기 전에 다음을 확인하십시오.

• 신원: 모든 조회와 변경은 인증된 사용자와 접근 권한이 있는 업무 계정의 범위로 제한합니다. 모델이 더 높은 권한의 신원을 선택할 수 없어야 합니다.
• 데이터: 작업에 필요한 레코드와 필드만 가져옵니다. 모델이 볼 수 있는 콘텐츠에 비밀 정보를 넣지 않고, 이메일·문서·CRM 텍스트의 출처를 유지합니다.
• 툴: 읽기, 초안 작성, 전송, 내보내기, 수정을 각각 별도의 권한으로 관리합니다. 워크플로에 필요하지 않은 기능은 제거합니다.
• 외부 전달: 답변과 툴 인수가 외부로 전달되기 전에 검사합니다. 수신자, 첨부 파일, 목적지, 허용된 레코드 변경 사항을 검증합니다.
• 승인: 영향이 큰 작업은 실행할 바로 그 작업의 내용을 검토해야 하며, 애플리케이션 코드가 이를 강제해야 합니다. 승인이 없거나 승인 내용이 바뀌었다면 보류합니다.
• 운영: 개인정보 보호를 고려한 작업 로그를 남기고, 알림 담당자를 지정하며, 일시 중지 수단을 제공합니다. 접근 범위를 넓히기 전에 전체 워크플로를 테스트합니다.

창업자의 영업 어시스턴트라면 선택한 잠재 고객의 이메일 대화만 읽고 답장 초안을 제안하는 범위부터 시작하는 것이 합리적입니다. 대량 내보내기, 자동 전송, 거래 정보 일괄 업데이트는 각각 필요성을 따로 입증해야 하는 기능입니다. 연동으로 가능한 모든 기능을 기준으로 권한을 주지 말고, 제공하려는 업무를 기준으로 범위를 정해야 합니다.

운영 환경의 AI 에이전트 피해 범위 제한 플레이북에서는 더 넓은 차원의 피해 확산 방지 아키텍처를 다룹니다. 피해 범위란 오류가 연결된 시스템 전반으로 얼마나 멀리 퍼질 수 있는지를 뜻합니다.

프롬프트 인젝션 테스트: 답변보다 실제 결과를 확인해야 합니다

금지한 결과가 발생하지 않아야 테스트를 통과한 것입니다. 툴 호출이 이미 레코드를 바꾼 뒤에도 어시스턴트는 거부 문구를 출력할 수 있습니다. 대화 기록만 볼 것이 아니라 툴 서비스와 실행 후 상태를 확인해야 합니다.

출시 전 리허설에는 합성 연락처 데이터, 테스트용 메일함, 통제된 환경을 사용하십시오. 다음은 공격 페이로드 모음이 아니라 애플리케이션 테스트 계획입니다.

1. 1

   권한 범위 안의 정상 동작을 확인합니다

   일반적인 잠재 고객 요약 작업을 실행합니다. 올바른 레코드를 가져오는지, 초안이 유용한지, 정책이 정한 지점에서 정확히 승인을 요구하는지 확인합니다. 정당한 업무는 여전히 정상적으로 처리되어야 합니다.

2. 2

   직접·간접 유입 경로를 모두 테스트합니다

   사용자 입력 경계에는 권한 없는 요청을, 제3자 메시지에는 작업을 다른 방향으로 유도하려는 내용을 포함합니다. 무관한 레코드에 계속 접근할 수 없는지, 금지된 툴 작업이 거부되는지 확인합니다.

3. 3

   승인 절차와 실패 처리를 검증합니다

   승인 뒤 작업 세부 내용을 바꾸는 경우, 검토가 거절되는 경우, 정책 서비스를 사용할 수 없는 경우, 실행을 재시도하는 경우를 시험합니다. 애플리케이션이 작업을 보류하거나 거부하고, 중복 실행 결과를 만들지 않는지 확인합니다.

4. 4

   증거와 알림을 확인합니다

   최종 CRM 상태, 발송 메시지, 접근을 시도한 목적지, 승인 기록, 정책 로그를 확인합니다. 모델의 설명에 의존하지 않고도 운영자가 출처를 파악하고 워크플로를 중단할 수 있는지 검증합니다.

프롬프트, 모델, 검색·조회 방식, 툴, 권한이 바뀌면 관련 테스트를 반복해야 합니다. 테스트 결과는 해당 구성에만 유효합니다. 앞으로 나올 모든 버전을 보증하는 것은 아닙니다.

판단 과정을 재구성할 수 있을 만큼 기록하되, 감사 추적 기록이 메일함 전체의 또 다른 사본이 되지 않도록 해야 합니다. 안정적인 레코드 참조, 필요한 작업 세부 내용, 정책 버전, 접근이 통제된 증거를 우선적으로 남기십시오. 차단된 목적지, 예상치 못한 데이터 내보내기, 반복적인 승인 실패를 조사할 담당자도 정해야 합니다.

과장된 기대는 무엇이고, 아직 풀리지 않은 문제는 무엇입니까?

어떤 모델, 프롬프트, 필터, 가드레일 제품도 완전한 해결책으로 보아서는 안 됩니다. OWASP는 검색 증강 생성과 파인튜닝으로도 프롬프트 인젝션을 완전히 완화할 수 없다고 명시합니다. 검색 증강 생성(RAG)은 모델이 답변할 수 있도록 문서를 제공하는 방식이지, 그 문서에 작업을 바꿀 권한을 부여하는 방식이 아닙니다.

더 강력한 시스템 프롬프트는 모델의 행동을 개선할 수 있습니다. 하지만 인증 정보에 부여된 폭넓은 권한을 좁히지는 못합니다. 분류기는 의심스러운 콘텐츠를 표시할 수 있지만, 특정 직원이 특정 첨부 파일을 공개해도 되는지 결정하지는 못합니다. 다른 모델이 첫 번째 모델을 검토하면 검사 단계가 추가되지만, 여전히 독립적인 애플리케이션 정책이 필요합니다.

메일함 에이전트를 운영할 준비가 되었는지 알려주는 보편적인 탐지율도 없습니다. 실효성 있는 제한은 워크플로마다 다릅니다. 어떤 계정을 읽을 수 있는지, 어떤 필드를 바꿀 수 있는지, 데이터가 어디로 갈 수 있는지, 어떤 작업에 검토가 필요한지를 정해야 합니다. 공급업체가 다른 작업에서 얻은 결과로 우리 시스템의 승인 경로를 우회할 수 없다고 입증할 수는 없습니다.

근거를 갖고 할 수 있는 주장은 더 제한적이지만 실용적입니다. 여러 겹의 통제는 위험 노출과 피해를 줄이고, 테스트와 모니터링은 실패를 드러냅니다. 그래도 잔여 위험은 남습니다.

에이전트가 이미 외부 콘텐츠를 읽으면서 비공개 정보를 공개하거나 업무 상태를 변경할 수 있다면 지금 조치해야 합니다. 권한, 승인, 실패 처리를 강제하기 전까지는 자율성 확대를 보류해야 합니다. 비공개 데이터도 실행 툴도 없는 공개 문서 요약기는 피해 범위가 더 좁지만, 조작된 답변에 대한 방어는 여전히 필요합니다.

자주 묻는 질문

프롬프트 인젝션 공격을 어떻게 방어합니까?

데이터 접근과 툴을 제한하고, 신뢰할 수 없는 콘텐츠를 지시와 분리하며, 출력과 작업을 검증해야 합니다. 영향이 큰 작업은 검토를 요구하고 결과를 모니터링해야 합니다. 권한은 모델 외부에서 강제해야 하며, 어느 한 계층만으로 위험을 없앨 수는 없습니다.

프롬프트의 예시는 무엇입니까?

‘이 잠재 고객의 이메일을 요약하고 검토용 답장 초안을 작성해 주세요’는 일반적인 프롬프트입니다. 잠재 고객의 이메일은 작업 자료이며, 요청을 바꿀 수 있는 허가가 아닙니다.

SQL 인젝션은 지금도 사용됩니까?

그렇습니다. 안전하지 않은 데이터베이스 쿼리를 구성하는 애플리케이션에는 여전히 SQL 인젝션 위험이 있습니다. 프롬프트 인젝션 통제와 별개로 데이터베이스에 맞는 방어도 필요합니다. OWASP 인젝션 방어 지침을 참고하십시오.

코딩에서 인젝션이란 무엇입니까?

보안에서 인젝션은 신뢰할 수 없는 입력이 인터프리터가 실행하거나 처리하는 내용을 바꾸는 것을 뜻합니다. 프롬프트 인젝션은 모델의 행동을 대상으로 하며, 다른 인젝션 취약점은 데이터베이스 쿼리, 명령어, 브라우저 코드 등을 대상으로 합니다.

인젝션을 쉽게 설명하면 무엇입니까?

입력이 경계를 넘어, 원래 부여받지 않은 권한을 가진 지시처럼 취급되는 것입니다.

코드 인젝션에는 어떤 유형이 있습니까?

SQL 인젝션, 운영체제 명령어 인젝션, 스크립트 인젝션 등이 있습니다. 방어 방법은 대상 인터프리터에 따라 달라집니다. 프롬프트 인젝션도 신뢰 경계라는 문제를 공유하지만, 모든 코드 인젝션을 뜻하는 말은 아닙니다.

프롬프트 인젝션에는 어떤 유형이 있습니까?

주요 구분은 직접 유입과 간접 유입입니다. 공격이 사용자 입력을 통해 들어오는지, 애플리케이션이 가져온 콘텐츠를 통해 들어오는지에 따라 나뉩니다. 이미지 속 텍스트나 다른 매체에도 지시가 담길 수 있습니다. 유입 경로와 매체 형식은 서로 다른 구분 기준입니다.

해커의 주요 유형 7가지는 무엇입니까?

해커를 유형별로 분류하는 것은 에이전트의 권한 정책에 도움이 되지 않습니다. 누가 인증되었는지, 누가 콘텐츠에 영향을 줄 수 있는지, 애플리케이션이 무엇에 접근하고 무엇을 변경할 수 있는지를 기준으로 통제해야 합니다.

DDoS와 SQL 인젝션은 무엇입니까?

DDoS는 분산 서비스 거부를 뜻하며, 분산된 여러 출처를 이용해 가용성을 공격합니다. SQL 인젝션은 데이터베이스 쿼리를 조작합니다. 둘 다 프롬프트 인젝션과는 별개의 문제입니다. 가용성 방어에 대해서는 OWASP 서비스 거부 방어 지침을 참고하십시오.

다음 업무일에 바로 할 일

운영 중인 메일함 또는 CRM 워크플로 하나를 골라 접근 가능한 데이터, 툴, 외부 목적지를 목록으로 정리하십시오. 불필요한 접근 권한을 없애고, 영향이 큰 작업은 정확한 실행 내용에 대한 승인을 받을 때까지 기다리게 해야 합니다. 거절된 제안이 외부에 아무 영향도 주지 않는다는 점도 입증해야 합니다. 필요한 업무와 거부 경로가 모두 제대로 작동한 뒤에만 자율성을 확대하십시오.

뉴스레터에서 AI 워크플로 구축을 위한 실용적인 가이드를 받아보십시오.