AWS 기술 블로그
AWS X Remember GenAI 해커톤 사례: 영업팀을 위한 AI 솔루션 샐리(Sales:Re) 개발기
지난 10월 17일, AWS와 리멤버앤컴퍼니가 함께 진행한 GenAI Hackathon이 성황리에 마무리되었습니다. 이번 해커톤에는 총 12개 팀이 참가하여 생성형 AI를 활용한 다양한 프로젝트를 선보였습니다.
리멤버앤컴퍼니는 국내 대표 비즈니스 네트워크 서비스, ‘리멤버’를 운영하는 기업으로, 직장인들의 커리어 성장과 비즈니스 연결을 돕고 있습니다. 500만 명 이상의 회원을 보유한 리멤버는 명함 관리, 채용, 콘텐츠 등 다양한 서비스를 제공하며, 최근에는 생성형 AI 기술을 적극 도입하여 사용자 경험을 혁신하고 있습니다. AWS Seoul Summit 2025에서 “리멤버 채용 AI의 미래: Caching 기법을 결합한 LLM as Reranker” 사례를 발표하며, 메인 비즈니스인 채용 플랫폼에서의 성공적인 AI 도입 경험을 공유한 바 있습니다.
이번 해커톤은 AWS의 생성형 AI 코딩 어시스턴트인 Kiro와 생성형 AI 솔루션인 Amazon Bedrock을 활용하여 실무에 적용 가능한 솔루션을 개발하는 것을 목표로 진행되었습니다. 12개 프로젝트는 각각 고객 서비스 자동화, 콘텐츠 생성, 지능형 검색, 업무 효율화 등 다양한 분야에서 생성형 AI의 가능성을 보여주었습니다.
본 글에서는 해커톤에서 1위를 수상한 2pm 팀의 “영업팀을 위한 AI 솔루션 샐리” 프로젝트를 중심으로, 생성형 AI를 처음 접하는 개발자/비개발자의 기술적 접근 방식과 구현 과정에서의 시행착오, 그리고 실무 적용시 고려사항 등을 상세히 공유하고자 합니다. 생성형 AI 도입을 고민하시는 분들께 실질적인 참고 사례가 되길 바랍니다.
프로젝트 배경
리멤버 세일즈 에이전트 샐리
기술적인 구현 과정을 공유하기에 앞서, 2pm팀이 수많은 도메인 중 왜 ‘영업(Sales)’을 선택했는지, 그리고 어떤 문제를 기술로 해결하고 싶었는지에 대한 배경을 먼저 공유합니다.
1. B2B 기업의 숙명: “클릭 한 번으로 살 수 없다”
B2B 비즈니스는 일반적인 쇼핑몰과 다릅니다. 기업 간 거래는 제품의 가격이 높고 도입 결정이 신중한 ‘고관여 상품’이기 때문입니다. 따라서 “구매하기” 버튼 하나로 매출이 발생하지 않습니다. 반드시 고객의 상황을 듣고, 설득하고, 신뢰를 쌓는 영업 담당자와의 ‘미팅’ 프로세스가 필수적인데요. 이것이 B2B 기업에게 강력한 세일즈 조직이 필요한 이유이자, 디지털화가 가장 어려운 영역으로 남은 이유이기도 합니다.
2. 영업 담당자 : “저희… 원시인처럼 일하고 있어요”
리멤버는 데이터/기술력을 기반으로 성장한 IT 스타트업이지만, 영업 조직이 뒤늦게 구축되면서 다른 조직들과 비교해 영업 프로세스에 있어 상대적으로 시스템화 되어 있지 않은 부분들이 많았습니다. 문제 정의와 원인 파악을 위해 영업 담당자와의 인터뷰를 진행했고, AI로 해결해야하는 문제를 크게 3가지로 정의할 수 있었습니다.
- 리드 확보의 막막함
채용/도입 니즈가 있는 기업을 찾기 위해 매일 아침 뉴스 기사/잡 포털을 검색합니다. - 비효율적인 반복 업무
어렵게 찾은 고객사에게 첫 컨택 메일을 보내고 제안서를 작성하는 수기 업무를 매주 수십 번씩 반복합니다. - 파편화된 정보
유사한 레퍼런스나 내부 데이터를 찾기 위해 슬랙, 위키, 동료의 경험과 같은 여러 루트를 탐색해야합니다.
이러한 문제들은 AI로 충분히 해결할 수 있는 영역이고, 이번 해커톤이 기존에 없는 B2B 세일즈 프로세스를 재정의할 수 있는 기회라고 판단했습니다. 이에, 2pm 팀은 영업 담당자에게 도움을 줄 수 있는 세일즈 AI 에이전트, 샐리(Sales:Re)를 개발하기로 했습니다.
팀 소개
2pm 팀은 두 명의 PM, 두 명의 서버 개발자, 두 명의 데이터 엔지니어로 구성되었습니다. 전담 프론트엔드 개발자가 없는 상황에서 PM이 Kiro(구 Amazon Q Developer)를 활용해 직접 프론트엔드 개발을 담당했으며, 이를 통해 기획 변경사항을 즉시 반영하고 테스트하며 기획과 개발 간 간극을 최소화할 수 있었습니다.
이번 프로젝트에서는 AI가 반복적이고 정형화된 업무를 자동화하여, 영업 담당자가 고객 관계 구축과 창의적 제안 등 핵심 업무에 집중할 수 있는 환경을 만드는 것을 목표로 설정했습니다.
샐리(Sales:Re) 전체 아키텍처
아키텍처는 Front Layer, Agent Layer, Background Process, Knowledge Base 로 구성했습니다.
- Frontend (Next.js + Open WebUI)
- 사용자가 자연어로 질문하면, FastAPI 기반 Agent로 전달됩니다. UI는 대화형으로 설계되어 영업 담당자가 챗봇처럼 질의·응답이 가능합니다.
- Agent Layer (Strands Framework + FastAPI)
- 각 에이전트는 FastAPI로 래핑되어 있으며, 서로 API 호출이 가능한 멀티 에이전트 구조입니다.
- Knowledge Base (Amazon Bedrock + Amazon S3 + Mem0Memory)
- Bedrock 기반 모델을 통해 추론 작업을 수행하고, S3에는 세션간 대화 맥락, Mem0Memory에는 영업 이벤트 이력을 저장합니다. 이를 통해 각 기업별 과거 전략 및 히스토리를 기반으로 맞춤형 대응이 가능합니다.
- Background Process (Naver / Exa / Perplexity API)
- 외부 API를 통해 기업 동향, 채용 정보, 투자 뉴스 등을 수집하고 평가합니다. 이 정보는 Lead Search Agent가 활용하여 신규 영업 리드를 탐색합니다.
Kiro를 활용한 프론트엔드 구현
팀에 프론트엔드 개발자가 없는 상황이었지만, PM이 Kiro를 활용해 개발을 담당했습니다. 요구사항을 구체적인 프롬프트로 작성하고 Kiro가 이를 코드로 구현하는 방식으로 작업을 진행했으며, 서비스를 단계별로 나누어 점진적으로 개발했습니다.
프로토타입 개발
메인 화면과 리드 상세 화면 두 가지를 디자인 시안 겸 프로토타입으로 제작했습니다. 각 화면에 필요한 Agent와 기능, 표시할 정보를 구체적으로 프롬프트로 작성하여 반영했습니다.
메인 화면은 B2B 영업 담당자용 대시보드로, 사용자가 배정받은 리드 리스트를 보여주고, 리스트는 콜 예정일 임박순, 최근 등록순, 우선순위 순으로 정렬할 수 있습니다. 키워드 검색과 콜 예정일 미등록 리드 필터 기능도 포함했습니다.
또한, 오늘 등록 리드 영역을 별도로 두어, 해당 날짜에 새로 등록된 리드를 강조 표시했습니다. 오늘 등록 리드는 전체 리스트와 중복될 수 있으며, 기업명, 우선순위, 등록일, 업데이트 뉴스 등의 정보를 포함합니다.
디자이너가 없었지만, Kiro는 요구사항을 명확한 프로토타입으로 구현했습니다. 다만, 화면 간 연결성 구현 시 실제 데이터 연동 없이 작업하다 보니 의도를 완벽히 전달하기 위해 프롬프트를 원하는 흐름을 구체적인 문장으로 표현하고, 여러 차례 수정해야했습니다.
최종적으로 팀 피드백을 반영해 프로토타입을 리드 상세 화면 하나로 통합했습니다. 이는 5분 발표 시간 내에 모든 AI 에이전트 기능을 효과적으로 시연하기 위한 결정이었습니다.
프론트엔드 개발
팀 피드백이 반영된 최종 프로토타입을 기반으로 Kiro에게 웹 개발 작업을 요청했습니다. Kiro는 Next.js 기반 로컬 서버 환경을 구축하여 프로젝트를 실행할 수 있도록 했고, 결과적으로 비개발직군인 PM이 직접 코드를 작성하지 않고도 로컬에서 프로젝트를 빌드하고 실행하여 팀이 테스트할 수 있는 환경을 구축했습니다.
작업 중 Kiro CLI가 로컬 서버 실행에서 중간에 멈추는 현상이 종종 있었습니다. 이는 웹 개발 환경을 처음 세팅할 때 의존성 충돌, 캐시 등으로 발생하는 문제이지만 Kiro와 에러 메시지를 실시간으로 공유하면서 문제의 원인을 파악하고, 필요한 조치를 취하여 서버를 정상적으로 실행할 수 있었습니다.
완성된 웹 프로젝트는 팀원들이 테스트할 수 있도록 테스트용 파일과 가이드 문서가 포함된 ZIP 파일로 제공되었고, 이 과정에서도 Kiro의 도움을 받았습니다.
UX/UI 개선
데모 제작 완료 후, 초기 구현 결과물의 완성도를 높이기 위해 Ant Design 오픈소스 UI 라이브러리를 적용했습니다. Kiro는 라이브러리 설치부터 적용까지 수행하여 전문적인 수준의 인터페이스를 구현했습니다.
Kiro를 활용하며 중시한 점은 두 가지입니다.
- 요청사항을 구체적이고 상세하게 기술
프롬프트를 작성할때, 요구사항을 구체적이고 상세하게 기술하는 것이 중요했습니다. 구체적이지 않은 설명은 의도하지 않은 부분의 수정을 만들어내기 때문에 배경 정보와 함께 원하는 결과를 명확히 표현할수록 더 나은 결과물을 얻을 수 있었습니다. - 작업 단위별 중간 저장과 컨텍스트 기록
Kiro와 작업할 때 각 단계 완료 후 history를 저장하고 추후에 이 Context를 기억할 수 있도록 해두면, 특정 단계에서 문제가 생겨 롤백을 해야할 때 보다 수월하게 다시 작업을 이어갈 수 있었습니다.
Kiro는 프론트엔드 개발 경험이 없는 PM도 실무 수준의 웹 애플리케이션을 구현할 수 있도록 지원했으며, 팀은 생성형 AI 기반 개발의 가능성을 확인할 수 있었습니다.
백엔드 개발기
Strands Agents SDK 사용
2pm 팀에서는 Sales의 복잡한 비즈니스 문제 해결을 위한 Agentic AI를 구축하기 위해 Strands Agents SDK를 사용했습니다. 기존 Agent 개발 시에는 다음과 같은 로직들을 직접 구현해야했습니다.
- Bedrock 모델에 대한 세부 호출 로직 작성 (invoke_model, 토큰 관리 등)
- 대화 세션별 상태 관리 (Redis나 S3 같은 외부 스토리지 직접 관리)
- Tool을 직접 주입하고 호출 순서를 제어하는 로직 구성
Strands Agents는 추상화 계층이 잘 설계되어 있어 Agent 개발 시 위와 같은 복잡한 로직을 직접 구현할 필요가 없이 간단한 코드 몇줄로 위의 기능들을 사용할 수 있습니다.
@classmethod
def get_agent(
cls,
user_id: str | None = None,
chat_id: str | None = None,
prompt: str | None = None,
tools: List | None = None
) -> Agent:
cls._init()
session_manager = None
if user_id and chat_id:
try:
session_manager = S3SessionManager(
session_id=f"{user_id}:{chat_id}",
bucket=s3_bucket,
prefix=s3_prefix,
region_name=aws_region,
)
...
...
return Agent(
model=cls._model,
tools=tools or cls._tools,
system_prompt=prompt or cls._system_prompt,
session_manager=session_manager,
conversation_manager=SummarizingConversationManager(
summary_ratio=0.3,
preserve_recent_messages=10,
),
callback_handler=None,
)
멀티 에이전트의 한계와 단일 에이전트 최적화 전략
초기에는 Supervisor Agent가 각 업무를 세분화하여 하위 Sub Agent를 Agent-as-a-Tool 형태로 호출하는 구조를 설계했습니다. 각 Agent는 명확히 정의된 작은 태스크를 수행하고, Supervisor Agent가 이들을 오케스트레이션하는 방식이었습니다.
그러나 실제 운영에서 과도한 에이전트 간 호출로 인해 토큰 사용량 증가와 응답 지연 문제가 발생했습니다. 영업 현장에서 요구되는 실시간 리드 조회에서 응답 시간이 5분 이상 지연되는 경우가 빈번했으며, 세분화된 태스크 구조가 오히려 전체 시스템 성능을 저하시키는 것을 확인했습니다.
이를 해결하기 위해 Sub Agent 구조를 제거하고 주요 판단 로직을 단일 Agent 내부 프로세스로 통합했습니다. 그 결과 응답 속도가 크게 개선되었고 운영 비용도 절감할 수 있었습니다.
MCP 의존도 최소화 및 Tool 기반 구조 개선
초기 에이전트는 Naver, Perplexity, Exa 등 여러 검색 엔진과 MySQL MCP를 동시에 활용하도록 구성되어 있었습니다. 그러나 MCP 내부에는 실제 작업과 관련 없는 도구들까지 함께 컨텍스트로 주입되면서, LLM이 상황에 맞는 도구를 적절히 선택하지 못하는 문제가 발생했습니다. 그 결과, 불필요한 MCP 호출이 늘어나고, 의도하지 않은 도구 사용으로 인해 성능과 안정성이 모두 저하되는 상황이 발생했습니다.
이를 해결하기 위해 MCP를 직접 사용하는 대신, MCP에서 필요한 기능만 분리하여 독립적인 Tool 형태로 재구성했습니다. 이렇게 함으로써 LLM은 오직 필요한 도구만 명확하게 인식하고 호출할 수 있게 되었으며, 불필요한 컨텍스트 노이즈를 제거하여 에이전트의 판단 정확도와 응답 일관성이 크게 향상되었습니다.
@tool
def get_sales_reference_companies(company_id: int) -> str:
"""
주어진 회사 ID를 기반으로 유사한 회사들을 다단계로 조회하고,
중복을 제거한 후 상세 정보를 MySQL에서 추출합니다.
Args:
company_id: 유사한 회사를 찾을 대상 회사의 ID
Returns:
JSON 형태의 유사 회사 상세 정보 목록 문자열. 구조는 다음과 같습니다:
{
"original_company_id": int, # 원본 회사 ID
"total_similar_companies": int, # 발견된 유사 회사 총 개수
"companies": [ # 유사 회사 목록
{
"id": int, # 회사 ID
"display_name": str, # 회사명
"number_of_employees": int, # 직원 수
"total_assets": int, # 총자산 (원)
"total_liabilities": int, # 총부채 (원)
"total_equity": int, # 총자본 (원)
"revenue": int, # 매출액 (원)
"operating_profit": int, # 영업이익 (원)
"product_usage": str, # 제품 사용 상태
"base_date": str, # 기준일자
"job_apply_cnt": int, # 채용공고 지원 건수
"job_success": int # 채용 성공 건수
}
]
}
특히 MySQL MCP의 경우, 임의의 쿼리를 실행하지 않도록 제한된 쿼리만 호출할 수 있는 Tool로 구현했습니다. 이를 통해 LLM이 데이터베이스의 민감한 정보에 접근할 수 있는 가능성을 원천적으로 차단함으로써 보안 리스크도 효과적으로 해소할 수 있었습니다.
이와 같은 접근 방식은 실제로 Anthropic의 공식 블로그에서도 권장되는 방향으로, MCP 전체를 사용하는 대신 필요한 도구만 선별적으로 사용하는 것이 에이전트 효율과 제어 가능성을 모두 높인다는 점이 강조된 바 있습니다.
Lead Search Agent를 통한 유효 리드 수집
영업 담당자가 매일 수행하던 기업별 뉴스 및 채용 공고 리서치를 자동화하기 위해 Lead Search Agent를 구축했습니다.
Agent는 Naver, Exa, Perplexity 등 외부 API를 Strands Framework 상에서 Tool로 래핑하여 직접 호출하며, 이때 LLM이 투자, 시리즈 A·B 등 관련 키워드를 자동으로 확장하며 사람이 놓치기 쉬운 다양한 채용 시그널을 수집합니다.
이렇게 수집된 데이터를 LLM이 분석한 결과, 실제 영업 가능성이 높은 기업임에도 적절한 시기에 컨택되지 않은 사례가 상당수 확인되었으며, Agent는 근거와 함께 신규 리드 발굴의 최적 타이밍을 제시하여 영업팀이 적시에 접근할 수 있도록 지원할 수 있습니다.
아래는 Naver Search API를 호출하도록 만들어진 Tool 의 코드 일부입니다.
from strands import tool
import requests, json, os
@tool
def search_naver_news(query: str, limit: int = 30) -> str:
"""
네이버 뉴스 검색 API를 호출하여 지정된 키워드의 최신 뉴스를 검색합니다.
Args:
query (str): 검색할 키워드
limit (int): 가져올 뉴스 개수 (기본값: 30)
Returns:
str: JSON 형식의 뉴스 검색 결과
"""
url = "https://openapi.naver.com/v1/search/news.json"
headers = {
"X-Naver-Client-Id": os.getenv("NAVER_CLIENT_ID"),
"X-Naver-Client-Secret": os.getenv("NAVER_CLIENT_SECRET"),
}
response = requests.get(url, params={"query": query, "display": limit}, headers=headers)
data = response.json()
return json.dumps(data, ensure_ascii=False)
성능 / 비용 최적화를 위한 서버 애플리케이션 비동기 처리
유저가 리드 목록을 조회할 때마다 실시간으로 에이전트를 호출하여 정보를 가져오고 가공하는 것은 성능상 부담이 크기 때문에, 서버 애플리케이션에서 비동기 스케줄 JOB을 실행하여 최신 리드 정보를 주기적으로 갱신하도록 설계했습니다.
- 리드 원천 저장소에서 샐리에 필요한 정보만을 유저별로 가져와 샐리 DB에 리드 메타데이터로 저장합니다.
- 저장한 리드 메타데이터를 key로 앞서 설명해드린 Lead Search Agent 를 일 n회 호출하여 리드의 최신 정보들을 가져옵니다.
- 가져온 최신 정보를 내부 스코어링 알고리즘을 통해 가공하여 DB에 저장합니다. 이로서 샐리에서 제공하는 리드 정보는 모두 샐리 DB를 통해 관리되게 됩니다.
- 유저는 샐리 DB에 적재된 리드 최신 정보를 통해 서비스를 이용하게 됩니다.
위와 같은 비동기 처리를 통해, 유저에게 빠른 서비스를 제공하고, 불필요한 에이전트 호출을 최소화하여 비용을 줄일 수 있습니다.
Lead Reference Agent를 통한 데이터 기반 영업 전략 수립
Lead Reference Agent 는 기업 정보, 경쟁사 정보, 그리고 내부 영업 히스토리를 종합 분석하여 영업 대상 기업에 최적화된 맞춤형 영업 전략을 수립하도록 돕는 Agent입니다.
이 에이전트는 단순히 기업 데이터를 보여주는 수준을 넘어, 실제 리멤버 채용 서비스 도입 현황과 인재 채용 성과 데이터를 바탕으로 영업 타깃 기업의 경쟁력과 시장 포지션을 실시간으로 판단할 수 있도록 설계되었습니다.
Lead Reference Agent는 총 3단계로 Tool을 호출하여 영업 전략을 수립합니다.
1단계: 기업 재무 평가 Tool
영업 사원이 낯선 기업을 조사하고 영업 가능성을 판단하는 데 드는 시간을 LLM으로 자동화했습니다. 내부 데이터와 뉴스 분석을 통해 기업의 재무 안정성과 성장 가능성을 평가하고, 산업군 평균과 비교하여 리스크와 기회 포인트를 도출합니다. 이를 통해 실제 영업 진행 여부와 전략적 접근 타이밍까지 판단할 수 있습니다.
2단계: 경쟁사 추출 Tool
기존에는 사내 Rule-Base API를 통해 업종 기준으로 동종 업계 경쟁사를 단순히 추출했습니다.
그러나 이 방식은 업종만을 기준으로 하기 때문에, 실제 사업 영역이나 고객군이 전혀 다른 기업이 경쟁사로 분류되는 경우가 많았습니다.
이를 개선하기 위해, Agent는 기존 API를 활용하되 LLM이 추론을 통해 키워드를 확장하고, API 응답 결과를 바탕으로 “진짜 경쟁사”를 식별하는 판단 로직을 도입했습니다. 이 과정에서 LLM은 업종뿐 아니라 사업 영역, 주고객층, 재무 구조의 유사도까지 고려해 경쟁사를 평가하므로, 기존 Rule-Base 방식보다 훨씬 정교하고 실제적인 경쟁사 식별이 가능해졌습니다. 또한 경쟁사별로 매출 규모, 채용 성과, 비즈니스 모델 유사도 등을 종합 분석하여 영업 레퍼런스 점수를 산정했습니다.
- 직접 레퍼런스: 핵심 비즈니스 모델 70% 이상 일치, 유사 매출 및 직원 규모, 동일 타겟 고객층
- 간접 레퍼런스: 일부 비즈니스 영역만 일치하지만 시장 영향력이 높거나 브랜드 파워가 있는 기업
3단계: 채용 성과 분석 Tool
내부 데이터베이스를 활용하여 기업별 채용 공고, 지원 수, 채용 성공률 등을 분석했습니다.
이를 통해 경쟁사의 채용 역량을 객관적으로 비교하고, 대상 기업의 채용 전략에 대한 시사점을 도출할 수 있었습니다.
위의 도구를 사용하여 사용자에게 올바른 데이터를 제공하기 위해서는 프롬프트도 정해진 포맷에 맞게 구체적으로 작성되어야만 합니다. 아래는 프롬프트 예시입니다.
이러한 다단계 분석을 통해 영업 포인트를 도출하고, 경쟁사의 리멤버 채용 서비스 도입 효과를 측정하며, 고객사 맞춤형 영업 전략을 제안할 수 있었습니다.
특히 경쟁사 추출 과정에서 LLM을 활용해 기존 Rule-Based 한계를 극복함으로써, 데이터 기반의 실제 영업 현장에서 바로 활용 가능한 인사이트를 실시간으로 지원할 수 있는 수준의 기능 제공이 가능했습니다.
결론 및 향후 계획
“고객을 설득하고 신뢰 관계를 구축하는 영역은 영업 담당자의 고유 영역이지만, 이를 지원하는 반복적인 프로세스는 AI가 효과적으로 자동화할 수 있습니다.” 라는 가설을 이번 해커톤에서 확신으로 바꾸는 중요한 계기가 되었습니다.
그동안 B2B 세일즈의 병목은 사람의 품이 많이 드는 수동 작업에 있었습니다. 이제 리멤버는 기술을 통해 이 문제를 해결하고자 합니다. 단순 반복 업무는 ‘AI 에이전트’에게 일임하고, 영업 담당자는 세일즈의 본질인 ‘고객과의 소통’에만 온전히 집중할 수 있는 새로운 프로세스를 구축해 나아갈 예정입니다.
이번 해커톤 이후, 리멤버 영업담당자가 실제 ‘샐리’를 만나볼 수 있도록 다음과 같은 단계별 로드맵을 실행할 계획입니다.
- 기능 고도화 : 해커톤 프로토타입에서 발견된 엣지 케이스(Edge Case)를 보완하고, 리멤버의 방대한 데이터와 연동하여 답변의 정확도와 개인화 수준을 개선합니다.
- 사내 파일럿 : 실제 영업팀을 대상으로 한 CBT(비공개 베타 테스트)를 진행하여, 현업의 피드백을 즉각적으로 반영하고 사용성을 검증합니다.
- 정식 도입 및 확장 : 검증된 AI 에이전트를 사내 CRM 시스템에 정식 탑재하여, 리멤버의 모든 세일즈 프로세스에 ‘샐리’가 실질적인 기여를 할 수 있도록 전면 적용할 예정입니다.