LangChain은 유료 광고 운영 에이전트를 어떻게 만들었나

• 광고 플랫폼과 사내 데이터를 연결해
  성과 분석, 캠페인 변경 제안, 사람의 승인과 실행 검증까지 이어지는 Slack 기반 에이전트를 구축함
• 신입 분석가처럼
  작업용 컴퓨터와 분석 도구, 업무 지침과 회사 위키를 제공하고, 시스템 프롬프트에는 모든 지식 대신 필요한 정보를 찾는 방법을 담음
  계산과 고정 규칙은 코드, 해석과 판단은 모델에 맡겨 초기 보고서 생성 비용을 약 40분의 1로 줄이고, 실행 시간을 18분에서 85초로 단축함
• 수백 개 도구 중 필요한 것만 찾아 사용하고, 플랫폼별 분석은 서브에이전트에 분담함.
  컨텍스트를 나누는 것과 별개로 파일과 작업 상태도 분리해야 충돌을 막을 수 있었음
• 분석과 보고를 내부에서 처리해
  월 약 5,000달러의 대행사 비용을 절감했으며, 도구와 스킬, 샘플 위키, 보고서와 승인 흐름을 포함한 에이전트를 오픈소스로 공개함

구축 목표와 운영 성과

• LangChain은 초기 3년간 오픈소스, 콘텐츠, YouTube, 커뮤니티, 밋업 중심으로 영업 파이프라인을 확보하다가, 1월부터
  유료 광고를 확대하기 시작함

• 자연 유입으로 닿지 못한 신규 지역의 잠재 고객과 기업 의사결정자에게 접근하고, 6개월 안에 유료 채널 5개로 확장하려는 목표였음

• 소규모 마케팅팀이 채널별 캠페인, 소재와 타기팅 실험, 늘어나는 성과 데이터를 수작업으로 관리하기 어려워짐

• 플랫폼마다
  데이터 스키마가 다르고 캠페인 매개변수가 영업 문의, 가입, 콘텐츠 다운로드 같은 실제 성과와 깔끔하게 연결되지 않았음

• 제품 출시와 캠페인이 늘면서 무엇이 실행 중이고, 무엇이 효과가 있으며, 다음에 무엇을 시도할지 파악하기도 어려워짐

• 목표는 제품 발표 추적, 캠페인 초안 작성, 키워드 추가, 변형 테스트, 실험 승인 요청을 지원하고, 장기적으로
  분석 → 변경 → 결과 관찰 → 학습 기록 → 다음 캠페인 반영의 순환을 만드는 것이었음

• 운영 성과로 유료 광고의 마케팅 파이프라인 기여 비중이
  6개월 만에 0%에서 20% 로 증가함

• 6~8월 월 지출은 약 60% 늘고 적격 리드당 비용(CPL)은 30% 감소함

• 최대 소셜 채널인 LinkedIn의 CPL은 1월보다 40% 낮아짐

• 대행사에 맡겼던 분석과 보고를 내부로 가져와 월 약 5,000달러를 절감함

Slack에서 분석과 캠페인 제안을 수행하는 방식

Paid Media Agent는 Slack에서 운영되는 장기 실행 에이전트로, 매주 월요일 광고 플랫폼 데이터와 웨어하우스의 리드 및 파이프라인 데이터를 결합함

• 플랫폼별 요약과 브랜드 형식의 PDF를 게시해 무엇이 달라졌는지, 이유는 무엇인지, 다음에 무엇을 해야 하는지 전달함

• 팀원은 스레드에서 에이전트를 태그해
  캠페인, 비용, 파이프라인에 관한 후속 질문을 할 수 있음

• 업무 지침과 명문화한 판단 기준에 따라
  신규 키워드, 타기팅 변경, 광고 문구, 검색 캠페인도 제안함

에이전트를 지식 노동자로 설계하기

• 코딩 에이전트도 파일을 읽고 정보를 변환하며 분석을 실행하고 결과를 기록한다는 전제에서, 신규 광고 분석가처럼
  컴퓨터, 소프트웨어, 데이터 접근권, 업무 문서를 제공함

• 에이전트 하네스에는
  Deep Agents를 사용함

• 파일 접근, 코드 실행, 작업 메모리와 함께 계획 수립, 서브에이전트 위임, 컨텍스트 관리를 지원함

• 그 위에 유료 광고용 도구, 스킬, 비즈니스 지식을 올림

• 실행마다
  LangSmith Sandbox를 기본 제공함

• 32GB 디스크와 셸을 갖춘 격리된 microVM으로, 다른 실행이나 기반 시스템에 영향을 주지 않고 코드와 파일을 다룸

• 분석용 pandas와 DuckDB, 스프레드시트용 openpyxl, 보고서 생성용 WeasyPrint와 Jinja2를 설치함

• 작업 데이터와 비즈니스 지식은 스킬 6개와 19페이지 위키에 Markdown으로 저장함

• 소프트웨어와 위키를
  스냅샷에 미리 넣어 평균 시작 시간을 10초 줄임

• 작업 환경은
  에이전트의 업무에 맞춰 구성함

• 콘텐츠 생성 에이전트에는 헤드리스 브라우저, ffmpeg, 미디어 도구, 브랜드 가이드를 제공함

• 재무 에이전트라면 스프레드시트용 openpyxl과 대규모 데이터 처리용 DuckDB가 필요할 수 있음

컨텍스트를 다섯 계층으로 분리하기

• 모든 지식을 시스템 프롬프트에 넣으면
  길이와 실행 비용이 늘고 정보가 낡기 쉬움

• 추론 실패처럼 보이는 문제도 실제로는 필요한 정보가 없거나 무관한 정보가 주의를 분산시키는 컨텍스트 문제일 수 있음

• 지식은 예측 가능한 위치의 구조화된 파일에 두고,
  시스템 프롬프트는 지도로 사용해 작업에 필요한 정보만 읽도록 함

• 업무 지침, 캠페인 데이터, 분석 라이브러리를 조합하면서 별도 워크플로를 만들지 않은 질문에도 답할 수 있었음

• 컨텍스트는
  다섯 계층으로 나눔
  시스템 프롬프트: 한 문장의 역할 정의와 운영 방식, 수치의 출처, 결과 제시 방식으로 구성하며, 나머지는 지침과 위키 위치 및 색인 확인 안내로 연결함
  스킬: 6개 폴더에 절차를 저장하고, 처음에는 제목과 설명만 보여준 뒤 실행 중 필요한 내용을 점진적으로 공개함
  위키: 퍼널 구조, 캠페인 목적, 지표별 기준 출처, 팀의 의사결정과 이유를 19페이지에 담음
  실시간 도구: 매일 바뀌는 지출, 설정, 파이프라인은 요청 시 조회하며, 이런 호출이 218개 있음
  결정론적 코드: 계산, 날짜 범위, 계정 매칭, 강제 안전장치를 담당함

• 스킬과 위키는
  재사용 가능한 절차와 회사 고유 지식으로 구분함

• 스킬은 데이터 읽기, 계산, 보고서 작성, 변경 준비, 성과 해석 방법을 담되 특정 캠페인 정보는 넣지 않음

• 위키는 인지도용 캠페인과 데모 요청용 캠페인의 구분, 7월에 내린 결정과 이유처럼 LangChain에만 해당하는 정보를 담음

• 이 구성은 Karpathy의 LLM wiki와 LangChain의 Wiki Memory 패턴을 따름

• 핵심 파이프라인 기여 캠페인을 한 주의 부진만으로 축소하지 못하게 하는 규칙은
  코드로 강제해 모델이 우회할 수 없도록 함

보고서와 Slack을 하나의 런타임으로 통합하기

• 초기에는
  두 개의 에이전트 그래프를 별도로 운영함

• 주간 보고서는 Deep Agent, 샌드박스, 대형 모델, PDF 생성을 사용하는 예약 실행 구조였음

• Slack은 수초 내 응답을 위해 저렴한 모델의 경량 루프와 Google Ads 및 웨어하우스 도구를 사용하고, 샌드박스 없이 읽기 전용으로 운영함

• 분리 구조는
  5주 만에 폐기함

• 새 기능을 두 번 구현해야 했고 배포 시점도 달라짐

• Slack은 첨부파일을 처리할 수 없었으며, 다른 그래프가 만든 월요일 보고서의 후속 질문에도 답하지 못했음

• 현재는 같은 위키, 스킬, 도구, 데이터 출처 규칙을 공유하는
  단일 그래프를 요청마다 새로 생성함

• 스레드별로 샌드박스와 체크포인트를 분리하고 실행마다 필요한 도구만 노출함

• 예약 실행에는 플랫폼별 서브에이전트로 위임하는
  task()

도구 하나만 제공함

• Slack에는 더 넓은 범위의 읽기, 웨어하우스, 캠페인 운영 도구를 제공함

LangSmith Deployment가 호스팅, 확장, 예약 실행을 담당함

• Slack도 같은 샌드박스 구조를 사용하므로 보고서 PDF를 열고 해당 스레드에서 후속 질문에 답할 수 있음
• 동일한 런타임 생성 구조에서 진입점이나 사용자별로 스킬과 권한을 다르게 부여할 수 있음

모델에는 판단을, 코드에는 계산을 맡기기

• 초기 주간 분석은 모든 캠페인 행, 키워드, 파이프라인 기록, 랜딩 페이지 점검 결과를 컨텍스트에 넣고 모델이 계산과 분류, 보고서 작성을 모두 수행했음

• 고정 테스트 데이터에서 보고서 하나가
  입력 토큰 약 390만 개를 처리하고, 실행에 1,112초와 3달러 조금 넘는 비용이 들었음

• 매번 모델이 기초 수치를 다시 계산해 결과의 신뢰성을 확인하기도 어려웠음

• 현재는
  Python이 데이터를 조회하고 날짜 범위를 맞추며 합계와 비교값을 계산하고 고정 규칙을 적용한 뒤, 압축된 결과를 샌드박스에 기록함

• 모델은
  증거 연결과 판단에 집중함

• 가능한 원인 해석, 목표 대비 캠페인 평가, 다음 행동 제안을 담당함

• 계산을 코드로 옮기고 불필요한 모델 호출을 제거해 초기 보고 워크플로의
  비용은 약 40분의 1로 줄고 속도는 13배 빨라졌으며, 실행 시간은 약 18분에서 85초로 줄어듦

지표마다 신뢰할 기준 출처 정하기

• 데이터 통합에서는 ID, 전환 정의, 기여도 산정 기간, 캠페인 계층이 서로 다른
  6개 플랫폼을 다뤘음

• 완벽한 단일 스키마로 정규화하면 복잡성이 늘지만 데이터 신뢰성이 반드시 높아지는 것은 아니었음

• 지출, 노출, 클릭 등
  광고 활동은 광고 플랫폼, 리드, 영업 기회, 파이프라인 등 전환 이후 성과는 웨어하우스를 기준으로 삼음

• Google 동영상 캠페인은 키워드가 없는 경우가 있어, 키워드로 데이터를 조인하던 웨어하우스에서
  Google 지출 약 10% 가 누락됨

• Google 자체 지출 데이터는 정확했음

• 반대로 Meta는 전환 발생을 알려줄 수 있지만, 그것이 “Contact Sales” 요청인지 “Sign Up”인지 구분하는 데는 웨어하우스가 더 적합했음

기준 출처 규칙을 위키에 기록하고 특정 지표를 잘못된 시스템에서 조회하게 만드는 도구는 제거함

• 출처 경계, 전환 매핑, 캠페인 계층을 명확히 해 완벽히 정규화된 스키마 없이도 플랫폼을 함께 분석함

• 신뢰성 있게 조인할 수 없는 데이터는 빈틈을 추정해 채우지 않음

• 답변에
  출처, 날짜 범위, 기여도 모델과 한계를 남겨 수치의 산출 근거를 확인할 수 있게 함

도구 전체를 로드하지 않고 필요할 때 탐색하기

• 광고 지출 대비 파이프라인을 분석하려면 광고 플랫폼의 지출 및 클릭 데이터와
  BigQuery의 웹사이트 전환, 적격 리드, Salesforce 영업 기회 및 파이프라인을 함께 조회해야 함
  Pipeboard MCP는 광고 플랫폼 도구 200개 이상을 노출함

• 6월의 더 작은 읽기 전용 목록도 이름, 설명, 인자를 로드하는 데만 38,000토큰이 필요했으며, 대부분은 개별 요청과 무관했음

• 웨어하우스의 고정 쿼리 역시 캠페인별 파이프라인이나 광고 그룹별 전환에는 유용했지만, 개별 영업 기회별 분석처럼 집계 방식이 바뀔 때마다 새 도구가 필요했음

• 도구 목록을
  Search, Read, Run 인터페이스 뒤로 숨김

• Search는 질문에 맞는 도구를 최대 8개 찾음

• Read는 선택한 도구의 전체 스키마만 로드함

• Run은 서버를 통해 실행하며, 캠페인 쓰기는 별도의 승인 경로를 사용함

• 웨어하우스에는
  테이블과 필드 설명 조회, 분석 쿼리 실행 도구를 추가해 에이전트가 직접 스키마를 살피고 필요한 쿼리를 구성하도록 함

• 도구 탐색 방식은 첫 턴을
  약 12,000토큰으로 줄였고, 평가된 품질을 유지하면서 전체 스키마 로딩보다 비용을 4분의 1로 낮춤

• 이후 도구 목록이 거의 3배로 늘었지만 컨텍스트 비용은 대체로 일정했음

• 고정 도구, 쿼리 인터페이스, 두 방식을 함께 쓰는 구성을
  실제 실행 60회로 비교함

• 고정 도구는 일상 질문에 잘 답했지만 심층 질문은 지원하지 않는다고 올바르게 응답함

• 쿼리 인터페이스가 포함된 두 구성은 모든 분석 질문에 답함

• 흔한 질문은 고정 도구로 빠르게 처리하고 예상하지 못한 질문은 쿼리 인터페이스로 처리하도록 두 방식을 유지함

서브에이전트의 격리는 별도로 설계하기

• 5개 플랫폼을 분석할 때 플랫폼별 독립 실행, 단일 에이전트,
  부모 에이전트와 플랫폼별 서브에이전트를 실제 데이터로 비교함
• 독립 실행은 가장 단순했지만 Slack 메시지가 여러 개로 나뉘고 채널 간 종합 분석이 어려웠음
• 나머지 두 방식은 하나의 출력으로 플랫폼 전체를 종합할 수 있었음

부모와 서브에이전트 구조를 선택해 부모의 컨텍스트를 작게 유지하면서 플랫폼별 데이터와 주의사항은 각자의 컨텍스트에서 처리함

• 별도 컨텍스트만으로
  파일과 상태까지 격리되지는 않음

• 두 서브에이전트가 같은 보고서 경로와 완료 플래그를 공유해, 하나가 끝나면 다른 하나도 자기 작업이 끝났다고 판단해 보고서 없이 중단하는 문제가 있었음

• 플랫폼별 보고서 경로와 완료 상태를 분리해 해결함

• PDF 렌더링 성공 여부를 확인하지 못한 서브에이전트가 파일 확인을 반복하며 토큰을 과다 사용하고 PDF를 처음부터 다시 만들려 한 사례도 있었음

• 현재 서브에이전트에는
  컨텍스트 읽기, 계산, 렌더링 세 도구만 주고 렌더링이 성공하면 종료함

• 서브에이전트마다
  도구, 파일, 상태 접근 범위와 반환값, 실패 처리 방식을 명시해야 함

분석에서 승인과 실행 검증으로 연결하기

• 성과 분석만 하는 에이전트는 결국 더 나은 대시보드에 머무르므로, Slack에서
  키워드 추가, 지역 타기팅 변경, 검색 캠페인 생성을 직접 제안하도록 함

• 다른 팀도 성과와 파이프라인을 질문할 수 있지만,
  지정된 팀원만 변경안을 수정하거나 승인할 수 있음

• 서버가 Slack 사용자 ID를 확인하고, 권한 없는 요청은 차단하며 제안은 승인 대기 상태로 유지함

• 변경안은
  Block Kit 승인 카드로 표시함

• 승인자는 현재 값과 제안 값을 비교하고 수정한 뒤 최종 계획을 승인함

• 코드는 승인된 변경을 적용하고 광고 플랫폼을 다시 조회해 성공 여부를 검증함

• 에이전트는 분석과 제안을 담당하고,
  실제 실행 여부는 사람이 통제함

작업 복잡도에 맞춰 인터페이스 바꾸기

• Slack은 분석과 토론이 이루어진 같은 스레드에
  승인 카드를 둘 수 있어 초기 인터페이스로 적합했음

• 여러 팀이 질문하고 의견을 내되 캠페인 소유자가 실제 변경을 통제할 수 있었음

• 광고 그룹과 소재가 많은 캠페인,
  일괄 수정, 여러 차례 검토가 필요한 계획에서는 Slack을 주 작업 공간으로 쓰기 어려워짐

• 복잡한 워크플로는
  에이전트 중심 전용 인터페이스로 옮기는 중이며, Slack은 질문, 권고안 검토, 변경 승인용 경량 접점으로 유지할 계획임

다음 구축에도 적용할 원칙

신입 직원처럼 환경을 갖춰줌: 샌드박스, 라이브러리, 적절한 데이터 접근권, 명확한 문서를 제공해 질문마다 전용 워크플로를 만들지 않고도 조사할 수 있게 함
절차와 회사 지식을 분리함: 스킬은 업무 방법, 위키는 비즈니스 정보, 실시간 도구는 최신 정보를 담당하게 해 시스템 프롬프트를 키우지 않고 각각 갱신함
재현 가능한 작업은 코드로 처리함: 계산, 비교, 강제 규칙을 코드에 두고 모델은 결과 해석에 집중시킴
경계를 명시적으로 설계함: 컨텍스트 분리 외에도 도구, 파일, 상태, 반환값, 실패 처리 규칙이 필요함
업무 완수 여부를 함께 평가함: 토큰, 비용, 지연시간 감소가 수행 능력을 떨어뜨려서는 안 되며, 완료율과 답변 품질을 함께 측정해야 함
실사용에서 통합 개선점을 찾음: 반복적으로 답하지 못하는 질문을 통해 더 정확한 조인, 명확한 정의, 전용 도구가 필요한 지점을 찾음

향후 계획과 공개 구성

• 현재는 예약 실행과 팀 요청에 주로 반응하지만, 향후
  지속적 성과 모니터링으로 주의할 변화와 새 실험, 최적화 방안을 먼저 제안하도록 발전시키려 함
• 캠페인 참여 데이터는 영업 후속 활동에 활용하고, 파이프라인 진행, 영업 대화, 계약 결과는
  이상적 고객에 대한 이해와 다음 캠페인에 반영하려 함
• 장기적으로 GTM 에이전트들이
  공유 지식과 업무 지침에 학습 내용을 축적해 퍼널 전반의 타기팅, 메시지, 실험에 활용하는 것이 목표임
  Paid Media Agent를 오픈소스로 공개했으며, 광고 플랫폼 도구, 유료 광고 스킬, 샘플 위키, 보고서 생성, 승인 워크플로를 포함함
• 계정과 회사 정보를 연결한 뒤 Managed Deep Agents로 명령 하나를 통해 Slack에 배포할 수 있음
• Managed Deep Agents는 호스팅, 샌드박스, Slack 통합, 일정을 관리함

댓글과 토론