의뢰자가 가장 어려워하는 단계를 AI로: Strands SDK를 활용한 라우드소싱의 공모전 브리핑 에이전트 구축기

스터닝은 ‘창작자가 중심이 된 비즈니스 생태계를 만드는 플랫폼’을 목표로 라우드소싱과 노트폴리오가 만나 탄생한 기업입니다. 그 중 라우드소싱은 디자인 아이디어를 얻을 수 있는 공모전, 1:1 의뢰 등의 서비스를 제공하고 있으며, 창작자와 의뢰자를 효과적으로 연결하기 위해 마켓, 매칭, 통합검색 기능 등을 지속적으로 고도화 해왔습니다.

라우드소싱의 브리핑 작성 AI는 의뢰자가 공모전을 등록할 때 원하는 디자인 카테고리, 업종, 스타일, 브랜드 방향성 등 복잡한 요구사항을 보다 쉽게 구체적으로 작성할 수 있도록 돕는 생성형 AI 기반 솔루션입니다. 라우드소싱은 Amazon Bedrock 기반의 생성형 AI를 활용하여, 사용자의 간단한 입력만으로도 공모전 목적에 맞는 브리핑을 손쉽게 작성할 수 있는 AI Agent를 개발했습니다.

이 블로그에서는 브리핑 작성 AI가 어떻게 의뢰자의 공모전 등록 경험을 개선하는지, 그리고 Amazon Bedrock AgentCore와 Strands Agents SDK를 활용해 해당 솔루션을 설계하고 구현한 과정을 소개합니다.

풀고 싶었던 문제

공모전 브리핑은 의뢰자가 원하는 디자인 결과물을 디자이너에게 전달하기 위한 핵심 문서입니다. 디자인 카테고리, 업종, 브랜드 방향성, 타겟 고객, 선호 스타일, 전달하고 싶은 메시지 등 공모전의 목적과 요구사항을 구체적으로 설명해야 하기 때문에, 공모전 결과물의 품질과도 직접적으로 연결됩니다.

하지만 실제 서비스에서는 많은 의뢰자가 브리핑 작성 과정에서 어려움을 겪고 있었습니다. 일반 의뢰자의 경우 디자인이나 브랜딩에 대한 전문 지식이 부족한 경우가 많아, 어떤 내용을 어떻게 작성해야 하는지 막막함을 느끼는 경우가 자주 발생했습니다. 원하는 이미지는 존재하지만 이를 언어로 구체화하지 못하거나, 추상적인 표현만 반복되어 디자이너가 의도를 정확히 이해하기 어려운 사례도 많았습니다.

특히 공모전 등록은 대부분 빈 입력 화면에서 시작되기 때문에, 사용자는 처음부터 모든 요구사항을 직접 작성해야 한다는 부담을 느끼게 됩니다. 이 과정에서 브리핑 작성 자체를 어려워해 공모전 등록을 중단하거나 서비스에서 이탈하는 사례도 존재했습니다. 또한 충분한 정보를 작성하지 못한 상태로 공모전이 등록되면서, 결과적으로 디자이너가 의뢰자의 의도를 정확히 이해하지 못하는 문제로 이어지기도 했습니다.

운영팀 역시 이러한 문제를 해결하기 위해 의뢰자와 디자이너 사이에서 지속적으로 커뮤니케이션을 보조하고 있었습니다. 브리핑 내용을 보완하거나 디자인 방향성을 정리하기 위한 컨설팅이 반복적으로 발생했고, 이는 운영 효율 측면에서도 병목으로 이어졌습니다.

라우드소싱은 이러한 문제를 단순한 “입력 편의성” 문제가 아닌, 의뢰자의 의도와 창작자의 이해 사이에 존재하는 간극의 문제로 정의했습니다. 의뢰자가 자신의 요구사항을 보다 쉽게 구조화하고 표현할 수 있다면, 디자이너는 더 정확하게 의도를 이해할 수 있고 결과적으로 더 높은 품질의 공모전 경험을 제공할 수 있다고 판단했습니다.

라우드소싱 팀은 이 문제를 해결하기 위해 AWS의 2주간 밀착 지원형 해커톤 프로그램인 AWS DEVCRAFT에 참여했습니다. 이를 통해 사용자가 간단한 입력만으로 공모전 목적에 맞는 브리핑 초안을 생성하고, 단계적으로 내용을 구체화할 수 있는 AI Agent를 설계했습니다. 프로그램 기간 동안 AWS의 생성형 AI 서비스 활용법을 익히고 AWS 기술 전문가의 지원을 받으며 빠르게 프로토타이핑할 수 있었고, 이 경험은 약 2개월 만에 실서비스로 발전시켜 나가는 밑바탕이 되었습니다.

솔루션 개요

브리핑 작성 AI는 기반 모델로 Amazon Nova Pro와 Anthropic Claude Haiku 4.5를 사용하며, 아래 그림과 같이 총 3개의 흐름으로 구성되어 있습니다.

의뢰자가 선호 스타일, 브랜드명, 카테고리, 업종 등 공모전과 관련된 기본 정보를 입력하면 브리핑 생성 AI Workflow가 실행됩니다.

먼저 (1) Draft Agent는 의뢰자의 입력 정보를 기반으로 Amazon Nova Pro 모델을 통해 브리핑 초안을 생성합니다. 이 과정에서 보다 완성도 높은 초안을 생성하기 위해 Amazon Bedrock Knowledge Bases를 활용하였으며, 라우드소싱이 보유한 기존 브리핑 데이터베이스에서 카테고리 및 업종 기반의 우수한 유사 브리핑을 검색(RAG)하여 초안 생성에 함께 활용했습니다.

이후 (2) Review Agent는 생성된 브리핑 초안을 Nova Pro 기반으로 분석하고 검토합니다. 초안 내 부족하거나 모호한 내용, 추가 설명이 필요한 항목을 식별한 뒤 의뢰자에게 추가 입력이 필요한 정보를 제공합니다. 의뢰자는 이를 바탕으로 브리핑 내용을 보완하게 됩니다.

마지막으로 (3) Briefing Agent는 Nova Pro 기반으로 최초 초안과 의뢰자의 추가 입력 내용을 통합하여 최종 브리핑을 생성합니다. 최종 단계에서는 사용 목적에 따라 활용할 수 있도록 완성된 브리핑 결과를 3가지 형태로 제공합니다.

실제 서비스 적용 과정에서는 초기의 순차형 Workflow를 에이전트 기반 구조로 개선했습니다. 초기에는 브리핑 생성과 검수를 하나의 흐름으로 처리하는 구조를 고려했지만, 서비스 운영 과정에서 응답 속도와 기능 확장성을 고려하여 역할별로 분리된 구조를 채택했습니다.

최종적으로는 브리핑 분석, 브리핑 작성, 브리핑 검수의 세 가지 에이전트로 구성했습니다. 브리핑 분석 에이전트는 기존 데이터를 분석하여 업종 및 카테고리별 필수 작성 항목을 도출하고, 브리핑 작성 에이전트는 Claude Haiku 4.5를 활용해 사용자가 입력한 정보를 기반으로 브리핑 초안을 생성합니다. 마지막으로 브리핑 검수 에이전트는 작성된 브리핑 품질을 점검하고 개선이 필요한 사항을 안내합니다.

각 에이전트는 필요한 정보만 참조하도록 설계하여 불필요한 컨텍스트 전달을 최소화했으며, 이를 통해 응답 지연 시간을 줄이고 기능별 독립적인 운영이 가능하도록 구성했습니다. 또한 검수 기능을 작성 기능과 분리하여 AI가 생성한 브리핑 뿐만 아니라 사용자가 직접 작성한 브리핑에도 동일하게 적용할 수 있도록 했습니다.

이러한 구조를 통해 사용자 경험을 개선하는 동시에, 향후 Bedrock Knowledge Bases 연계 및 에이전트별 기능 고도화가 가능한 확장성 있는 아키텍처를 구현했습니다.

솔루션 아키텍처

아래는 브리핑 AI의 솔루션 아키텍처입니다. 브리핑 AI는 실시간으로 브리핑을 생성하고 검수하는 사용자 요청 처리 흐름과, 브리핑 품질 향상을 위한 분석 흐름으로 구성됩니다.

브리핑 분석 에이전트는 사용자 요청과 별도로 동작하는 오프라인 분석 프로세스입니다. 기존 브리핑 데이터를 분석하여 업종 및 카테고리별 필수 작성 항목과 우수 브리핑 패턴을 도출하며, 이를 통해 브리핑 작성 및 검수에 활용할 수 있는 기준 정보를 생성합니다. 현재는 분석 결과를 프롬프트에 반영하여 활용하고 있으며, 향후 Bedrock Knowledge Bases 와 연계하여 작성 및 검수 에이전트가 동적으로 참조할 수 있도록 확장할 수 있습니다.

사용자가 공모전 기본 정보를 입력하고 AI 생성 기능을 실행하면, 입력된 정보는 API Web Server를 통해 Bedrock AgentCore Runtime 위에서 호스팅되는 브리핑 AI 에이전트로 전달됩니다. 이후 브리핑 작성 에이전트가 Claude Haiku 4.5 모델을 활용하여 사용자가 입력한 정보와 작성 가이드, 필수 작성 항목을 기반으로 브리핑 초안을 생성합니다.

사용자는 생성된 브리핑을 수정하거나 보완할 수 있으며, AI 생성 기능을 사용하지 않고 직접 브리핑을 작성하는 것도 가능합니다.

브리핑 작성이 완료되면 브리핑 검수 에이전트가 Claude haiku 4.5 모델을 활용하여 브리핑 품질을 검토합니다. 검수 과정에서는 필수 정보 누락 여부, 모호한 표현, 부족한 요구사항 등을 분석하고 개선이 필요한 사항을 제공합니다. 검수 에이전트는 작성 에이전트와 독립적으로 구성되어 있어 AI가 생성된 브리핑 뿐만 아니라 사용자가 직접 작성한 브리핑에도 동일하게 적용할 수 있습니다.

이러한 구조를 통해 브리핑 품질 기준을 생성하는 분석 영역과 사용자 요청을 처리하는 생성·검수 영역을 분리할 수 있었으며, 각 에이전트가 필요한 정보만 참조하도록 구성하여 응답 속도를 최적화했습니다. 또한 향후 Bedrock Knowledge Bases 연계, 업종별 특화 로직 추가 등 기능 확장이 용이한 구조를 구현했습니다.

멀티에이전트 구조 및 구현 상세

브리핑 생성 AI는 초기 설계 단계와 실제 운영 환경에서 서로 다른 형태의 Workflow로 발전했습니다. 초기에는 생성형 AI를 활용해 브리핑 초안을 단계적으로 개선하는 Multi-Agent 구조를 중심으로 설계했으며, 실제 서비스 적용 과정에서는 사용자 경험과 운영 효율을 고려하여 보다 단순한 형태의 Workflow로 개선했습니다.

이번 섹션에서는 초기 Multi-Agent 설계 과정과 실제 운영 과정에서 구조가 어떻게 변경되었는지, 그리고 각 Agent가 어떤 역할을 담당하도록 구현했는지 소개합니다.

DEVCRAFT 프로그램에서 설계한 초기 Multi-Agent구조

Multi-Agent 구조 설계

초기 설계 단계에서는 브리핑 생성 과정을 크게 초안 생성(Draft), 브리핑 검수(Review), 최종 브리핑 생성(Briefing)의 3단계로 분리했습니다.

각 단계를 독립적인 Agent로 나눈 이유는 역할을 명확히 분리하여 생성 품질을 단계적으로 개선하기 위함이었습니다.

Draft Agent : 사용자 입력과 RAG 기반의 우수 브리핑 사례를 활용해 브리핑 초안을 생성
Review Agent : 생성된 초안을 다시 검토하여 부족한 정보와 추가 입력이 필요한 항목 식별
Briefing Agent : 사용자의 추가 입력 내용을 반영하여 최종 브리핑 생성

초기 구조에서는 AI가 초안을 생성한 뒤 다시 AI가 검수하고, 사용자가 부족한 내용을 보완하는 형태로 설계했습니다. 특히 단순히 한 번의 Prompt 호출로 결과를 생성하는 방식보다, 생성과 검수를 분리하는 것이 브리핑 품질 측면에서 더 효과적이라고 판단했습니다.

또한 최종 단계에서는 서로 다른 스타일의 브리핑 결과를 동시에 제공하는 구조도 함께 설계했습니다. 이를 통해 사용자가 하나의 결과물만 수동적으로 수용하는 것이 아니라, 여러 형태의 브리핑을 비교하며 원하는 방향을 선택할 수 있도록 구성했습니다.

[결과물]

Input 예시 :

* 기본 정보
- 카테고리 : 박스(상자)
- 회사명 : 스터닝 괄사
- 업종 : 뷰티

* 브랜드 소개
도자기로 괄사를 만드는 회사입니다.

* 디자인 요구사항
- 스타일 키워드 : 여성타겟, 젊음, 대중적인, 현대적인, 단순한, 귀여운
- 선호 색상 : 파랑, 자유 색상

Output 예시 :

'<h3>브랜드 정체성</h3>\n<p>스터닝괄사는 도자기로 괄사를 제작하는 뷰티 회사입니다. 우리 브랜드는 여성 타겟을 중심으로 젊음과 대중적인 감성을 전달하고자 합니다. 현대적이면서도 단순하고 귀여운 이미지를 목표로 합니다. 따뜻하고 친근한 브랜드 이미지를 추구합니다.</p>\n<h3>활용 맥락</h3>\n<p>로고는 다양한 매체에서 사용될 예정입니다. 간판, 포장 상자, 온라인 매장 등에서 활용할 예정이며, 심볼과 워드마크를 분리하여 사용할 수 있어야 합니다.</p>\n<h3>디자인 요청 사항</h3>\n<p>로고의 색상은 파랑을 선호하며, 자유로운 색상 조합도 환영합니다. 뷰티 업종에서 일반적으로 사용되는 색상 계열(파스텔 계열, 핑크 등)을 고려할 수 있습니다.</p>\n<h3>참고 이미지</h3>\n<p>참고 이미지에서 느껴지는 스타일은 현대적이고 귀여운 느낌을 주는 요소들을 참고하여 주세요. 도자기의 질감과 색상을 반영할 수 있도록 디자인 해주세요.</p>\n', 

'<p>스터닝괄사는 도자기로 제작된 괄사를 판매하는 뷰티 브랜드로, 젊고 대중적인 여성 타겟을 중심으로 하고 있습니다. 브랜드 이미지는 현대적이면서도 단순하고 귀여운 느낌을 지향하며, 따뜻하고 친근한 분위기를 중요시합니다. 로고는 다양한 매체에서 사용될 예정으로, 간판, 포장 상자, 온라인 매장 등에서 활용될 것입니다. 따라서 심볼과 워드마크를 분리하여 사용할 수 있어야 합니다. 디자인 요청 사항으로는 파란색을 선호하지만, 자유로운 색상 조합도 환영합니다. 뷰티 업종의 일반적인 색상 계열인 파스텔 계열과 핑크 등을 고려할 수 있습니다. 참고 이미지에서 현대적이고 귀여운 요소를 참고하여, 도자기의 질감과 색상을 반영한 디자인을 요청합니다.</p>\n', 

'<p>스터닝괄사는 젊고 현대적인 여성을 타겟으로 한 뷰티 브랜드입니다. 이 브랜드는 도자기로 만든 괄사를 판매하며, 단순하고 귀여운 이미지를 추구합니다. 따뜻하고 친근한 브랜드 이미지를 중요시하며, 이러한 요소를 반영한 로고를 요청합니다. 로고는 간판, 포장 상자, 온라인 매장 등 다양한 매체에서 사용될 예정이므로, 심볼과 워드마크를 분리하여 사용할 수 있어야 합니다. 디자인 색상은 파란색을 선호하지만, 자유로운 색상 조합도 환영합니다. 특히, 뷰티 업종에서 일반적으로 사용되는 파스텔 계열과 핑크 등의 색상을 고려할 수 있습니다. 참고 이미지에서 현대적이고 귀여운 요소를 참고하여, 도자기의 질감과 색상을 반영한 디자인을 요청합니다.</p>\n'

초기 Workflow 구성

의뢰자가 입력한 카테고리, 업종, 브랜드 소개, 디자인 요구사항 등의 정보는 API Web Server를 통해 Bedrock AgentCore Runtime으로 전달됩니다. 이후 Draft Agent는 Nova Pro 모델을 기반으로 브리핑 초안을 생성하고, Review Agent는 생성된 결과를 검토하여 부족한 정보와 추가 입력이 필요한 항목을 식별하도록 구성했습니다.

사용자를 Review Agent의 검수 결과를 바탕으로 추가 정보를 입력하고, 최종적으로 Briefing Agent가 이를 반영하여 완성된 브리핑을 생성하는 흐름으로 설계했습니다.

멀티 에이전트 구조 설계 및 운영 환경 개선

사용자 경험 중심으로 문제를 재정의하고, Offline Agent를 추가

초기 설계에서는 브리핑 품질을 극대화하기 위해 여러 Agent가 순차적으로 협업하는 구조를 검토했습니다. 그러나 실제 서비스 환경에서는 사용자가 완성도 높은 결과를 얻기 위해 여러 차례 AI와 상호작용하는 것보다, 빠르게 초안을 생성한 후 직접 수정·보완하는 방식을 더 선호한다는 점을 확인할 수 있었습니다. 또한 각 Agent간 Context 전달과 반복적인 사용자 입력 과정은 응답 지연 시간을 증가시키고 Workflow를 복잡하게 만드는 요인이었습니다.

이에 따라 운영 환경에서는 브리핑 생성과 검수를 각각 독립된 Agent로 구성하고, 브리핑 품질 기준을 생성하는 분석 기능은 별도의 Offline Agent로 분리하는 방향으로 구조를 개선했습니다.

브리핑 분석 Agent 도입

브리핑 분석 Agent는 기존 브리핑 데이터를 분석하여 업종 및 카테고리별 필수 작성 항목, 우수 브리핑 패턴, 작성 가이드 기준을 도출합니다. 분석 대상이 되는 기존 브리핑 데이터는 Bedrock Knowledge Bases를 통해 카테고리 및 업종 기반의 유사 브리핑 사례를 검색(RAG)할 수 있도록 구성했습니다.

현재 분석 Agent를 통해 도출된 필수 작성 항목과 작성 기준은 프롬프트에 반영하여 관리하고 있습니다. 향후에는 이러한 분석 결과를 Knowledge Base와 연계하여 작성 Agent가 동적으로 참조할 수 있도록 확장하는 방안도 고려하고 있습니다.

생성과 검수 Agent 분리

브리핑 작성 Agent는 사용자가 입력한 정보를 기반으로 브리핑 초안을 생성합니다.

반면 브리핑 검수 Agent는 작성된 브리핑의 품질을 검토하는 역할만 수행합니다.

이러한 구조를 통해 사용자는 AI 초안을 생성한 후 검수를 받을 수 있으며, AI 생성 기능을 사용하지 않고 직접 작성한 브리핑도 동일한 검수 기능을 사용할 수 있습니다. 또한 각 Agent가 필요한 정보만 참조하도록 설계하여 Context 크기를 줄이고 응답 속도를 최적화할 수 있었습니다.

운영 환경에서의 최종 방향성

최종적으로는 “완벽한 결과를 자동 생성하는 AI”보다 “브리핑 작성의 시작과 품질 검수를 지원하는 AI”에 집중했습니다.

이를 위해 분석 Agent는 품질 기준을 지속적으로 개선하고, 작성 Agent는 초안 생성을 지원하며, 검수 Agent는 브리핑 품질을 보완하는 역할에 집중하도록 설계했습니다.

그 결과 사용자 입력 부담과 Workflow 복잡도를 줄이면서도 브리핑 작성의 진입 장벽을 낮출 수 있었습니다.

Prompt Engineering 및 Retrieval 최적화

Prompt Engineering 및 출력 제어

브리핑 생성 품질을 높이기 위해 단순히 사용자 입력만 활용하는 것이 아니라, Bedrock Knowledge Bases를 통해 검색한 유사 브리핑 사례와 작성 가이드 정보를 함께 활용하도록 구성했습니다.

브리핑 작성 Agent는 Claude Haiku 4.5 모델을 기반으로 동작하며, 카테고리, 업종, 브랜드 소개, 디자인 요구사항 등 사용자가 입력한 정보를 우선적으로 반영하도록 설계했습니다. 특히 Retrieval을 통해 검색된 사례가 실제 사용자 요구사항보다 과도하게 영향을 주는 현상을 방지하기 위해 Prompt 내에 사용자 입력 우선 원칙을 적용했습니다.

Prompt에서는 동일 카테고리 및 업종의 브리핑 사례를 검색한 후 공통적으로 포함되는 작성 항목을 파악하고, 작성 가이드에 정의된 필수 항목이 누락되지 않도록 검증 과정을 수행합니다. 또한 생성 결과는 Markdown 형태로 반환하여 사용자가 브리핑을 직접 수정하거나 보완할 수 있도록 구성했습니다.

   "로고/브랜딩": {
       "use_images": True,
       "required_blocks": [
           {
               "name": "브랜드명 의미",
               "rule": "브랜드명 + 한줄소개에서 시각적으로 그릴 수 있는 핵심 한 문장 추출. 사업 배경·미션 나열 금지.",
               "scope": "시각 모티프가 담긴 핵심 구문만 (설명 문장은 블록 밖)",
               "example": "[Required]83번길에서 시작한 이름처럼 숫자 모티프로 기원을 담은 로고[/Required]를 기대합니다.",
           },
…
       ],
   },
“패키지”: { … }

사용자 인터랙션 단순화

초기 구조에서는 AI가 생성한 내용과 사용자의 추가 입력이 필요한 내용을 구분하기 위해 [[ASSUMED]]. ((REQUIRED)) 형태의 두 가지 태그를 함께 사용했습니다. 하지만 실제 서비스 관점에서는 두 태그의 의미 차이가 사용자에게 직관적으로 전달되지 않을 것 같다는 우려가 있었습니다.

이에 따라 운영 환경에서는 Required 태그 하나만 사용하는 방향으로 구조를 단순화했습니다. 현재는 작성 가이드 상 반드시 확인이 필요한 항목만 [Required]…[/Required] 형태로 표시하고 있으며, Agent가 품질 향상을 위해 자연스럽게 보완한 내용은 별도의 태그 없이 문맥 내부에 포함하도록 변경했습니다.

[ 이전 prompt ]

3. 사용자가 제공하지 않은 내용을 추가할 때는 반드시 아래 두 가지 태그 중 하나를 사용합니다.
  태그는 단어나 값뿐 아니라 문장·절 전체에도 적용합니다.

  [태그 1] Agent가 KB 사례를 근거로 추가하거나 유추한 경우:
  [[ASSUMED: 추가한 내용 | 근거: 근거 설명]]
  예1) [[ASSUMED: 따뜻하고 친근한 브랜드 이미지 | 근거: 식품/베이커리 카테고리 사례 대부분에서 유사한 톤 사용]]
  예2) [[ASSUMED: 간판, 앱 아이콘, 명함 등 다양한 매체에서 활용될 예정이며 심볼과 워드마크를 분리하여 사용할 수 있어야 합니다 | 근거: 로고 카테고리 KB 사례에서 공통적으로 포함된 활용 맥락]]

  [태그 2] 사용자만 알 수 있어서 Agent가 채울 수 없는 경우:
  ((REQUIRED: 구체적인 안내 메시지))
  예) ((REQUIRED: 브랜드가 담고 싶은 구체적인 회사 가치나 의미를 입력해주세요))

[ 변경 prompt ]

## Required 블록 표기
[카테고리 작성 지침]에서 [Required] 블록 대상으로 지정한 항목은 사용자 입력 여부와 관계없이 반드시 [Required] 블록으로 감싸서 작성합니다.
- agent가 품질 향상을 위해 자체 판단으로 추가한 내용([카테고리 작성 지침] 필수 지정 아님)은 [Required] 블록 대상이 아닙니다.
- [Required] 블록은 내용만 감쌉니다. 섹션 제목은 블록 밖에 위치합니다.
- 확인된 사실과 [Required] 블록 내용이 섞이지 않도록 블록 경계를 정확히 나눕니다.
- [Required] 블록은 본문 흐름 안에 자연스럽게 위치시킵니다. 별도 섹션으로 몰아두지 않습니다.
- [Required] 블록은 핵심 표현 한 문장 단위로만 감쌉니다. 섹션 전체나 여러 문장을 한 블록으로 묶지 않습니다.

```
[Required]내용[/Required]
```

Knowledge Base 구축 및 Retrieval 개선

Knowledge Base 구축 과정에서는 기존 공모전 브리핑 데이터를 Amazon S3에 저장하고, Amazon Opensearch Service 기반 벡터 검색을 통해 카테고리 및 업종 기반의 유사 브리핑 사례를 검색하도록 구성했습니다.

초기에는 브리핑 원문을 TXT 형태로 저장하여 활용했지만, Retrieval 과정에서 카테고리나 업종과 관계없는 브리핑 사례가 함께 검색되는 문제가 발생했습니다. 또한 검색 결과에서 브리핑 일부 문맥이 잘린 상태로 조회되는 현상도 확인할 수 있었습니다.

이를 개선하기 위해 브리핑 데이터를 CSV 형태로 변경하고, 카테고리, 업종, 디자인 유형 등의 정보를 메타데이터로 함께 관리하도록 구성했습니다. 이후 Retrieval 단계에서는 metadata filtering 과 semantic search를 함께 활용하여, 보다 맥락에 적합한 브리핑 사례를 검색할 수 있도록 개선했습니다.

[ 기존의 txt파일 ]

--- metadata --- 
카테고리: 로고 
업종 : 일반/기타 
제목: 스터닝 로고 콘테스트 
선호 색상: 색상 자유, 흑백 
스타일: 대중적인, 진지한, 단순한, 중후한, 파워풀한, 현대적인, 추상적, 남성타겟 
로고 스타일: 조합형 로고, 심볼 로고 
--- briefing content --- 
브리핑 내용: 스터닝 로고는 창작자의 ~

[ 변경된 metadata 구조 ]

{
  "metadataAttributes": {},
  "documentStructureConfiguration": {
    "type": "RECORD_BASED_STRUCTURE_METADATA",
    "recordBasedStructureMetadata": {
      "contentFields": [
        {
          "fieldName": "content"
        }
      ],
      "metadataFieldsSpecification": {
        "fieldsToInclude": [
          {
            "fieldName": "category"
          },
          {
            "fieldName": "industry"
          }
        ]
      }
    }
  }
}

Chunking 전략 개선

초기에는 기본 Chunking 방식을 적용했지만, 브리핑 데이터 특성상 문맥이 중간에서 잘리거나 서로 다른 의미의 내용이 하나의 Chunk에 함께 포함되는 문제가 발생했습니다.

특이 브랜드 소개, 디자인 요구사항, 활용 목적과 같은 정보가 분리되어 검색되면서, 실제 생성 과정에서 브랜드 맥락과 맞지 않는 결과가 생성되는 경우가 있었습니다.

이를 개선하기 위해 브리핑 데이터의 섹션 구조를 유지하는 계층적 (Hierarchical) Chunking 방식으로 변경했습니다. 카테고리, 브랜드 소개, 디자인 요구사항 등 의미 단위 기준으로 Chunk를 분리하고 메타데이터 정보를 함께 관리하도록 구성하여, Retrieval 단계에서 보다 일관된 문맥 정보를 활용할 수 있도록 개선했습니다.

Amazon Bedrock AgentCore 기반 Agent Orchestration

브리핑 서비스는 Amazon Bedrock AgentCore와 Strands Agents SDK를 활용하여 구현했습니다. 각 Agent는 독립적으로 동작하며, 사용자 요청에 따라 필요한 Agent만 실행되도록 구성했습니다.

브리핑 작성 Agent의 동작 흐름은 아래와 같습니다.

단계 의뢰자가 카테고리, 업종, 브랜드 소개, 디자인 요구사항 등의 기본 정보를 입력하면 클라이언트는 API Web Server로 요청을 전달합니다.
단계 API Web Server는 Bedrock AgentCore Runtime을 호출하고, 브리핑 작성 Agent를 실행합니다.
단계 브리핑 작성 Agent는 입력된 카테고리와 업종 정보를 바탕으로 해당 유형의 브리핑 작성 기준을 확인합니다. 현재 작성 기준은 브리핑 분석 Agent를 통해 도출된 결과를 프롬프트에 반영하여 관리하고 있습니다.
단계 Claude Haiku 4.5 모델이 사용자 입력 정보와 작성 기준을 바탕으로 브리핑 초안을 생성합니다.
단계 생성된 결과는 Markdown 형태로 반환되며, 사용자는 생성된 브리핑을 직접 수정하거나 보완할 수 있습니다.

브리핑 검수 Agent 동작 흐름

단계 의뢰자가 브리핑 검수를 요청하면 클라이언트는 작성된 브리핑 내용을 API Web Server로 전달합니다.
단계 API Web Server는 Bedrock AgentCore Runtime을 호출하고, 브리핑 검수 Agent를 실행합니다.
단계 브리핑 검수 Agent는 작성 가이드와 필수 작성 항목 기준을 바탕으로 브리핑 내용을 분석합니다.
단계 검수 과정에서는 필수 정보 누락 여부, 모호한 표현, 부족한 요구사항 등을 확인합니다.
단계 수정이 필요한 내용 및 항목은 Markdown 형태로 반환합니다.

도입 효과

브리핑 AI는 2026년 5월 29일부터 실제 서비스 환경에 적용하여 운영하고 있으며, 작성 시점 기준 약 400건 이상의 브리핑 생성 및 검수 요청에 활용되었습니다. 운영 기간 동안 진행된 전체 185개의 공모전 개최 과정 중 약 절반 수준의 사용자가 브리핑 AI 기능을 활용하여 브리핑 작성 또는 검수를 진행했으며, 이를 통해 실제 사용자 환경에서도 AI 기반 브리핑 지원 기능에 대한 활용 가능성을 확인할 수 있었습니다.

서비스 적용 이후 가장 눈에 띄는 변화는 공모전 등록 과정에서의 사용자 이탈 감소였습니다. 기존에는 브리핑 작성 과정에서 무엇을 입력해야 하는지 어려움을 느껴 등록을 중단하는 사례가 많았지만, AI를 통해 초안 작성과 검수 기능을 제공하면서 사용자의 작성 부담을 줄일 수 있었습니다.

그 결과 공모전 등록 과정의 이탈률은 18% → 11%로 약 39% 감소했습니다.

또한 생성된 브리핑을 그대로 활용하여 실제 공모전 등록까지 이어진 사례도 확인할 수 있었습니다. 운영 기간 동안 이러한 방식으로 등록된 공모전 중 약 10건이 공모 종료 및 우승작 선정까지 완료되었으며, 이를 통해 AI가 생성한 브리핑만으로도 실제 운영 가능한 수준의 품질을 제공할 수 있음을 확인했습니다.

사용자 만족도 측면에서도 긍정적인 초기 신호를 확인할 수 있었습니다. 아직 운영 초기 단계로 표본 수는 제한적이지만, 현재까지 수집된 평가에서는 브리핑 작성 경험과 생성 결과 품질에 대해 전반적으로 긍정적인 반응이 나타났습니다.

단순히 브리핑 작성 시간을 줄이는 것 외에도 사용자의 작성 경험 자체가 개선되는 모습을 확인할 수 있었습니다. 특히 기존에는 브리핑 작성 자체를 어려워했던 사용자가 많았지만, AI가 초안을 먼저 제안해주면서 “빈 화면에서 시작해야 하는 부담”이 크게 줄어들었습니다.

또한 브리핑 검수 기능을 통해 사용자가 작성한 내용을 다시 점검할 수 있게 되면서, 단순 자동 생성보다 결과에 대한 신뢰와 통제감을 높일 수 있었으며, AI가 모든 내용을 대신 작성하는 것이 아니라 사용자의 작성을 지원하는 방식이 실제 서비스 환경에서 더 높은 수용성을 보인다는 점도 확인할 수 있었습니다.

이를 통해 팀이 배운 점

이번 프로젝트를 통해 가장 크게 얻은 인사이트는 항상 더 많은 Agent와 더 복잡한 Workflow가 더 좋은 사용자 경험으로 이어지는 것은 아니라는 점이었습니다.

초기에는 브리핑 품질을 극대화하기 위해 여러 Agent가 순차적으로 상호작용하는 구조를 설계했지만, 실제 사용자에게 더 중요한 것은 완벽한 결과보다 빠르게 시작할 수 있는 경험과 적절한 품질 보완 기능이라는 점을 확인할 수 있었습니다.

이에 따라 생성과 검수를 분리하고, 품질 기준 생성은 별도 분석 Agent로 분리하는 현재 구조로 개선할 수 있었습니다.

향후 계획

현재 브리핑 분석 Agent가 도출한 필수 작성 항목과 작성 기준은 프롬프트에 반영하여 활용하고 있습니다.

향후에는 분설 결과를 보다 구조화하여 Knowledge Base와 연계하고, 작성 및 검수 Agent가 동적으로 참조할 수 있도록 확장할 계획입니다.

또한 사용자 행동 데이터와 브리핑 품질 데이터를 지속적으로 축적하여 업종별 최적화 기준을 자동으로 생성하고, 보다 개인화된 브리핑 지원 기능으로 확장할 예정입니다.

라우드소싱 팀이 AWS 기술을 선택한 이유

Amazon Bedrock을 선택한 이유

브리핑 작성 AI는 단순 텍스트 생성 기능이 아니라, 사용자 입력 기반 브리핑 생성, Retrieval 기반 사례 검색(RAG), 작성 가이드 기반 검수 등 여러 Agent Workflow가 함께 동작하는 구조였습니다. 또한 DEVCRAFT 프로그램 기간 동안 짧은 시간 내에 실제 서비스 형태의 프로토타입을 구현해야 했기 때문에, 다양한 모델을 빠르게 실험하고 Agent 구조를 유연하게 구성할 수 있는 환경이 중요했습니다.

Amazon Bedrock은 여러 Foundation Model을 동일한 환경에서 활용할 수 있었고, Knowledge Bases, AgentCore 등 생성형 AI 기반 서비스 개발에 필요한 기능들을 함께 제공하고 있어 빠르게 구조를 검증하고 구현하는 데 적합했습니다. 특히 별도의 모델 인프라를 직접 운영하지 않아도 된다는 점에서, 서비스 로직과 Prompt Engineering, Retrieval 품질 개선에 더 집중할 수 있었습니다.

Nova Pro와 Claude Haiku 모델을 활용한 이유

초기 DEVCRAFT 기간에는 제한된 기간 내에 다양한 실험을 빠르게 수행해야 했기 때문에, 비용 효율성과 응답 속도를 고려하여 Nova Pro 모델을 중심으로 활용했습니다. 브리핑 생성 특성상 완벽한 문장을 생성하는 것보다 사용자가 작성 방향을 빠르게 잡을 수 있는 초안을 제공하는 것이 중요했기 때문에, 초기 실험 단계에서는 Nova Pro만으로도 충분히 유의미한 결과를 얻을 수 있었습니다.

이후 실제 서 비스 적용을 고려하는 과정에서는 보다 안정적인 응답 품질과 일관된 결과를 제공하기 위해 Claude Haiku 4.5 기반으로 운영하는 Workflow를 구성했습니다. 특히 Review Agent에서는 작성 가이드 기반 검수와 Required 영역 식별이 중요했기 때문에, 보다 안정적인 성능을 기대할 수 있는 모델 구성이 필요했습니다.

다만 현재 서비스 구조에서는 AI가 최종 결과물을 완전히 자동 생성하기보다, 사용자의 브리핑 작성을 보조하는 역할에 집중하고 있기 때문에, 향후 운영 환경에서도 비용과 응답 속도, 품질 간의 균형을 고려하여 다양한 모델 구성을 지속적으로 검토하고 있습니다.

Bedrock Knowledge Bases를 활용한 이유

브리핑 서비스에서는 기존에 축적된 브리핑 데이터를 효과적으로 활용하기 위해 Bedrock Knowledge Bases를 도입했습니다.

공모전 브리핑은 카테고리와 업종에 따라 포함되어야 하는 정보와 작성 방식이 크게 달라집니다. 따라서 단순히 사용자 입력만으로 브리핑을 생성하기보다, 실제 서비스에서 축적된 브리핑 데이터를 분석하여 활용하는 것이 중요했습니다.

이 과정에서 Bedrock Knowledge Bases를 활용하여 기존 브리핑 데이터를 저장하고 관리할 수 있도록 구성했습니다. 단순 파일 저장소 형태로 관리하는 경우 필요한 데이터를 탐색하거나 분석하기 위한 별도의 데이터 처리 로직을 구현해야 하지만, Bedrock Knowledge Bases를 활용하면 브리핑 데이터를 보다 체계적으로 관리하고 Agent가 필요한 데이터를 효율적으로 탐색할 수 있었습니다.

또한 서비스 운영 과정에서 브리핑 데이터는 지속적으로 증가하기 때문에, 향후 분석 대상 데이터가 늘어나더라도 동일한 구조를 유지하면서 확장할 수 있다는 점도 중요한 고려 요소였습니다.

현재 브리핑 분석 Agent가 도출한 필수 작성 항목과 작성 기준은 프롬프트를 통해 작성 및 검수 과정에 반영하고 있으며, 향후에는 이러한 분석 결과를 보다 유연하게 활용할 수 있는 방향으로 확장하는 방안도 검토하고 있습니다.

Strands Agents SDK를 선택한 이유

라우드소싱 팀은 기존에 Agent 기반 시스템 개발 경험이 많지 않은 상태에서 프로젝트를 시작했습니다. 따라서 복잡한 Agent orchestration 구조를 직접 구현하기보다, 짧은 기간 안에 Multi-Agent Workflow를 빠르게 구성하고 실험할 수 있는 개발 경험이 중요했습니다.

Strands Agents는 Agent간 흐름을 비교적 단순한 코드만으로 구성할 수 있었고, Prompt 및 Tool 연결 구조 역시 직관적으로 작성할 수 있어 빠르게 Multi-Agent 구조를 구현하는 데 도움이 되었습니다. 특히 복잡한 orchestration 로직 자체보다 Prompt Engineering과 Retrieval 데이터 품질 개선에 더 집중할 수 있었다는 점이 가장 큰 장점이었습니다.

또한 Agent 흐름이 코드 레벨에서 비교적 명확하게 드러나기 때문에, 개발 과정에서 Workflow를 반복적으로 수정하거나 운영 구조로 단순화하는 과정에서도 가독성과 유지보수 측면에서 유리했습니다. Strands Agents SDK 활용 방법은 AWS DEVCRAFT 프로그램 교육 자료인 ‘Strands Agents SDK와 Amazon Bedrock AgentCore로 나만의 AI Agent 구축하기’ 워크샵에서 확인하실 수 있습니다.

마무리

이번 프로젝트를 통해 라우드소싱 팀은 “완벽한 결과를 자동 생성하는 AI”보다, 사용자가 공모전 브리핑 작성을 보다 쉽게 시작하고 방향을 잡을 수 있도록 도와주는 AI가 실제 서비스 환경에서 더 중요하다는 점을 확인할 수 있었습니다. 특히 사용자가 빈 화면에서 직접 모든 내용을 작성해야 하는 부담을 줄이고, AI가 초안을 제공한 뒤 사용자가 이를 자연스럽게 수정·보완하는 경험이 브리핑 작성 진입 장벽을 낮추는 데 효과적이라고 판단했습니다.

또한 DEVCRAFT 프로그램 기간동안 Amazon Bedrock, AgentCore, Strands Agents와 같은 AWS 기반 서비스의 활용 방법을 체계적으로 배우고 전문가의 지원을 받아 곧바로 활용해나가면서, 비교적 짧은 기간 안에도 Multi-Agent 구조와 RAG 기반 Workflow를 빠르게 구현하고 실제 서비스 형태까지 검증할 수 있었습니다. 특히 Strands Agents SDK를 통해 복잡한 Agent Orchestration 로직 자체보다 Prompt Engineering과 Retrieval 품질 개선에 더 집중할 수 있었고, Bedrock Knowledge Bases를 활용하여 운영 정책과 브리핑 데이터를 유연하게 관리할 수 있었습니다.

향후에는 이미지 레퍼런스 분석 또한 더 고도화하고, 보다 정교한 Multi-Agent 구조를 통해 브리핑 품질 자체를 지속적으로 개선해나갈 계획입니다. 또한 실제 사용자의 피드백 데이터를 기반으로 Retrieval 품질과 검수 기준을 지속적으로 발전시켜, 의뢰자와 창작자 모두가 보다 효율적으로 협업할 수 있는 환경을 만들어가고자 합니다.

Authors

AWS 기술 블로그