LangChain 광고 운영 에이전트의 설계와 사람의 승인 경계
LangChain의 광고 운영 에이전트가 계산과 판단을 나누고, 필요한 도구를 찾아 쓰며, 사람의 승인과 실행 후 확인으로 광고 변경을 통제하는 구조를 살펴본다.
TL;DR
- LangChain은 Slack 질의와 정기 광고 보고서를 하나의 에이전트 런타임으로 통합했다. 스레드별 샌드박스와 플랫폼별 하위 에이전트로 작업을 나눴다. 별도 컨텍스트만으로는 파일과 완료 상태까지 격리되지 않았다.
- 모델은 성과를 해석하고 코드는 계산과 안전 규칙을 처리한다. 광고비는 광고 플랫폼, 리드와 영업 파이프라인은 웨어하우스를 기준으로 삼는다. 도구도 전부 넣지 않고 검색한 뒤 필요한 스키마만 읽는다.
- 광고 변경 제안과 실제 실행은 분리된다. 권한 있는 사람이 검토·승인하면 서버가 변경을 적용하고 광고 플랫폼에서 결과를 다시 확인한다. 공개 구현도 실계정 쓰기를 기본 비활성화하며 제안이 바뀌면 재승인을 요구한다.
- 유료 광고의 마케팅 파이프라인 기여 비중은 6개월 동안 0에서 20%로 늘었다. 초기 보고 작업은 약 40배 저렴해지고 13배 빨라졌다. 사업 성과는 인과 실험이 아니며, 공개 저장소의 평가도 본문의 실데이터 실험과 구분해야 한다.
다섯 광고 채널을 분석하는 공통 런타임
LangChain 마케팅팀은 오픈소스와 콘텐츠 중심으로 성장하던 영업 파이프라인에 유료 광고를 더하면서 6개월 안에 다섯 채널로 운영 범위를 넓히려 했다. 플랫폼마다 데이터 구조와 전환 정의가 달랐고 광고 캠페인 설정을 영업 문의·가입·콘텐츠 다운로드와 연결하기도 어려웠다. Paid Media Agent는 매주 월요일 광고 플랫폼 데이터와 웨어하우스의 리드·파이프라인 데이터를 합쳐 Slack에 요약과 플랫폼별 PDF를 올리고 팀의 후속 질문을 받아 키워드·타기팅·광고 문구·검색 캠페인 변경을 제안한다.
처음에는 큰 모델과 샌드박스를 쓰는 보고서 그래프, 저렴한 모델과 읽기 전용 도구만 쓰는 Slack 그래프를 따로 만들었다. 이 구조는 다섯 주 만에 폐기됐다. 기능을 두 번 구현해야 했고 Slack 에이전트는 첨부파일을 처리하거나 다른 그래프가 만든 월요일 PDF를 읽어 후속 질문에 답하기 어려웠다. 통합 뒤에는 같은 그래프 정의를 요청마다 새로 구성하되 스레드마다 샌드박스와 체크포인트를 두고 정기 실행에는 위임용 task()만, Slack에는 조회·웨어하우스·캠페인 작업 도구를 노출한다.
프롬프트에는 지도를, 작업 공간에는 지식을 둔다
Deep Agents 하네스는 파일 접근, 코드 실행, 작업 계획, 하위 에이전트 위임과 컨텍스트 관리를 맡는다. 각 실행은 32 GB 디스크와 셸을 갖춘 LangSmith Sandbox의 격리된 microVM을 이용하며 pandas·DuckDB로 분석하고 openpyxl로 스프레드시트를 다루며 WeasyPrint·Jinja2로 보고서를 만든다. 소프트웨어와 업무 위키를 미리 넣은 스냅샷으로 시작하면서 평균 준비 시간을 10초 줄였다. 작업 공간에는 입력 파일, 계산 결과, 임시 파일, 완성 보고서를 구분하고 대용량 API 응답도 모델 컨텍스트 밖의 파일에 보관한다.
컨텍스트는 시스템 프롬프트, 스킬, 위키, 실시간 도구, 결정론적 코드로 나눈다. 프롬프트는 역할과 지식의 위치를 안내한다. 여섯 스킬은 처음에 제목과 설명만 노출하며 분석·보고·변경 준비의 재사용 가능한 절차를 담는다. 열아홉 페이지 위키에는 LangChain의 퍼널, 캠페인 목적, 지표별 권위 있는 출처, 과거 결정의 이유를 저장하며 현재 광고비와 설정은 실시간 도구로 가져온다. 계산·기간 정렬·계정 매칭·강제 안전 규칙은 코드에 두므로, 한 주 성적이 나쁘다는 이유만으로 주요 파이프라인 기여 캠페인을 줄이지 못하게 하는 규칙도 모델이 덮어쓸 수 없다.
계산을 코드로 옮기고 지표마다 기준 출처를 정한다
초기 보고서는 캠페인 행, 키워드, 파이프라인 기록, 랜딩 페이지 점검 내용을 모두 모델에 넣고 합계와 전주 대비 변화까지 계산하게 했다. 고정된 테스트 세트에서 보고서 한 건이 입력 토큰 약 390만 개를 처리했고 실행 시간은 1,112초, 비용은 3달러를 조금 넘었다. 개선 뒤에는 Python이 데이터를 가져와 날짜 범위를 맞추고 합계·비교·고정 규칙을 계산해 압축된 결과를 파일로 남긴다. 모델은 이 결과를 읽고 캠페인 목적과 증거를 연결해 원인을 해석하고 다음 행동을 권고하며 원문의 요약 기준으로 해당 초기 작업은 약 40배 저렴해지고 13배 빨라져 약 18분에서 85초로 줄었다.
모든 플랫폼을 하나의 완벽한 스키마에 맞추는 대신 지표마다 믿을 시스템을 정했다. 광고비·노출·클릭은 광고 플랫폼, 전환 이후의 리드·영업 기회·파이프라인은 웨어하우스를 기준으로 삼는다. Google 동영상 캠페인은 키워드가 없을 수 있는데 웨어하우스가 키워드로 결합하면서 Google 광고비의 약 10%를 빠뜨렸고 Meta의 전환 수만으로는 영업 문의와 가입을 제대로 구별하기 어려웠다. 출처 규칙을 위키에 쓰는 데 그치지 않고 잘못된 시스템에서 해당 지표를 조회할 도구도 제거하며 결합이 불확실하면 빈틈을 추정으로 메우지 않고 출처·기간·기여도 산정 방식을 답변에 남긴다.
도구 검색과 자유 질의가 고정 도구를 보완한다
Pipeboard MCP의 광고 플랫폼 도구를 한꺼번에 노출하면 사용자 질문을 읽기도 전에 컨텍스트를 많이 소비한다. 6월의 더 작은 읽기 전용 목록만 해도 이름·설명·인자를 넣는 데 38,000토큰이 필요했다. 팀은 218개 호출을 검색·스키마 읽기·실행 인터페이스 뒤에 두어 검색에서 최대 여덟 도구를 찾고 선택한 도구의 전체 스키마만 읽게 했다. 서버가 실행을 중개하고 캠페인 쓰기는 별도 승인 경로를 거치며 이 방식은 첫 턴을 약 12,000토큰으로 줄이고 전체 스키마를 로드하던 방식보다 비교 비용을 4배 낮추면서 평가된 답변 품질을 유지했다.
BigQuery에서는 캠페인별 파이프라인처럼 반복 질문에 맞춘 고정 도구에 더해 테이블·필드 설명 도구와 분석 질의 실행 도구를 제공했다. 모델이 스키마를 살펴 필요한 질의를 작성하므로 개별 영업 기회처럼 새로운 묶음 기준마다 도구를 추가할 필요가 줄었다. 고정 도구만 사용한 구성, 질의 인터페이스를 사용한 구성, 둘을 함께 쓴 구성을 실데이터 실행 60회로 비교했으며 질의 인터페이스가 있는 두 구성은 모든 분석 질문에 답했다. 고정 도구는 복잡한 질문을 지원하지 않는다고 올바르게 알렸지만 일상적인 질문에는 유용해 유지했고 본문은 질문별 표본 배분과 품질 채점 기준을 공개하지 않아 이를 일반적인 정답률 100%로 확대할 수 없다.
하위 에이전트의 격리는 파일과 종료 조건까지 포함한다
팀은 플랫폼별 독립 실행, 모든 플랫폼을 맡는 단일 에이전트, 플랫폼별 하위 에이전트에 위임하는 상위 에이전트를 실데이터로 비교했다. 독립 실행은 구현이 단순했지만 Slack 메시지가 여러 개로 흩어지고 채널을 가로지르는 종합 분석이 약했다. 두 통합 방식 모두 하나의 결과와 채널 간 해석을 만들었고 최종적으로 상위 컨텍스트를 작게 유지하면서 각 플랫폼의 데이터와 주의사항을 별도 컨텍스트에서 다루는 상위·하위 에이전트 구조를 선택했다.
컨텍스트를 나눈 뒤에도 두 하위 에이전트가 같은 보고서 경로와 완료 플래그를 공유해 한쪽의 완료가 다른 쪽의 작업을 중단시키는 문제가 생겼다. 플랫폼별 출력 위치와 완료 상태를 따로 두어 문제를 해결했다. 다른 하위 에이전트는 PDF 생성 성공 여부를 확인하다 파일 점검을 반복하고 보고서를 처음부터 다시 만들려 했으므로, 도구를 컨텍스트 읽기·계산·렌더링 세 가지로 제한하고 렌더링 성공을 종료 조건으로 삼았다. 별도 컨텍스트는 격리의 일부일 뿐이며 사용할 도구, 파일, 상태, 반환 결과와 실패 처리까지 명시해야 한다.
사람의 승인과 실행 후 확인을 하나의 절차로 묶는다
Slack에서 분석을 요청할 수 있는 사람과 캠페인을 수정·승인할 수 있는 사람은 다르다. 서버는 수정과 승인 때 Slack 사용자 ID를 확인하고 허가받지 않은 요청을 차단하며 제안을 승인 대기 상태로 남긴다. Block Kit 승인 카드에는 현재 값과 제안 값이 함께 나타나고 권한 있는 검토자가 수정·승인하면 코드가 광고 플랫폼에 적용한 뒤 실제 값을 다시 조회한다. 에이전트의 추천을 그대로 광고 집행으로 간주하지 않고 사람이 실행 여부를 결정하는 구조다.
공개 저장소의 승인 문서는 이 경계를 더 구체화한다. 승인 정보는 제안의 정확한 리비전과 다이제스트에 묶이며 제안 내용이 달라지면 새 승인이 필요하다. 실행기는 변경 호출을 한 번만 시도한 뒤 제한된 횟수와 시간 안에 결과를 읽어 확인한다. 변경 후 상태가 일치하면 verified, 변경 전 상태가 남아 있으면 failed, 실행됐을 가능성은 있지만 확인할 수 없으면 unknown으로 구분하며 중단된 변경을 자동 재시도하지 않는다. 실계정 쓰기는 기본적으로 꺼져 있고 검토한 도구 목록·정책·승인 등 별도 조건을 충족해야 하므로, 공개 코드를 받았다는 사실만으로 광고 변경 권한이 생기지 않는다.
사업 성과, 평가 결과, 공개 구현의 범위를 구분한다
원문에서 유료 광고가 만든 파이프라인 비중은 6개월 동안 전체 마케팅 파이프라인의 0에서 20%로 늘었다. 적격 리드당 비용인 CPL은 6월 대비 8월에 30% 줄었지만 월 광고 지출은 약 60% 늘었고 LinkedIn CPL의 40% 감소는 1월을 기준으로 한 별도 비교다. 분석과 보고를 대행사 대신 내부에서 처리하며 월 약 5,000달러를 절감했다. CPL의 분모는 적격 리드 수이지만 원문에는 그 판정 기준과 절대 건수가 없고 대조군도 제시되지 않아, 이 사업 변화를 모두 에이전트만의 인과 효과로 볼 근거는 부족하다.
평가도 비용·지연 시간만으로 끝나지 않는다. 원문은 작업 완료율과 답변 품질을 함께 보되 전체 완료율의 수치나 원시 실험 결과를 공개하지 않았고 공개 저장소의 별도 평가 문서는 합성 데이터에 관한 업무 질문 15개를 모델이 연결된 서버에 보내 같은 데이터에서 계산한 정답과 비교하도록 구성한다. 지출과 기간별 CPA 등 결정적으로 확인 가능한 수치는 코드로 검사하고 도구·시간·답변·기대 조건은 사람이 검토하는 방식이므로 이 평가를 원문의 실데이터 실행 60회와 같은 실험으로 묶으면 안 된다. 공개 버전의 웨어하우스 연결은 추가 구현이 필요한 선택 확장이며 Slack PDF 자동 첨부도 포함되지 않아, 내부 운영 사례가 설치 직후 그대로 재현되는 것은 아니다.
현재 내부 에이전트는 주로 예약 실행과 팀의 요청에 반응한다. 지속적인 성과 감시, 실험 제안, 영업 대화와 거래 결과를 반영한 GTM 공동 지식의 학습은 앞으로의 방향이다. 여러 광고 그룹과 소재를 다루는 대량 수정이나 반복 검토는 Slack만으로 불편해 전용 인터페이스로 옮기고 있으며 Slack은 간단한 질문·추천 검토·승인에 남긴다. 이는 이미 완성된 자율 광고 운영의 성과와 향후 개발 계획을 구분해야 하는 이유이기도 하다.