왜 우리는 자체 백그라운드 에이전트를 구축했는가 (그리고 남들 것으론 안 됐는가)

새로운 기술을 도입할 때 대부분의 회사는 이렇게 시작합니다.
“일단 시장에 나와 있는 솔루션부터 써보자.”

우리도 그랬습니다.
하지만 일정 수준 이상으로 자동화와 성능을 밀어붙이고, 우리 조직에 딱 맞는 워크플로를 만들고 싶어지는 순간, 선택지는 결국 둘 중 하나만 남습니다.

남이 만든 틀에 회사를 맞출 것인가,
회사의 일하는 방식에 맞춘 도구를 직접 만들 것인가.

우리는 두 번째를 선택했고, 그 결과가 바로 “자체 백그라운드 에이전트”였습니다.
이 글에서는 왜 그런 결정을 했는지, 어떤 방향과 원칙으로 설계했는지, 그리고 무엇이 실제로 달라졌는지를 정리해 보겠습니다.

1. 기존 솔루션을 써보니 바로 부딪힌 세 가지 한계

백그라운드 에이전트라고 하면 거창하게 들리지만, 본질은 단순합니다.
눈에 보이지 않는 곳에서 계속 돌아다니며 일을 대신 해주는 “자동화 직원”입니다.
버그를 감지하면 티켓을 만들고, 데이터가 쌓이면 리포트를 만들고, 조건이 맞으면 알림을 보내는… 그런 일들 말이죠.

문제는, 이미 시장에 비슷한 도구가 꽤 많음에도 불구하고, 우리 상황에 그대로 들이기엔 치명적인 한계가 있었다는 점입니다.

첫 번째는 “유연성의 벽”이었습니다.
대부분의 솔루션은 미리 정의된 워크플로, 특정 클라우드, 혹은 몇 가지 도구에 tightly-coupled 되어 있었습니다. GitHub, 특정 모니터링 도구, 특정 메시징 플랫폼과만 잘 붙는 식입니다.
우리는 사내 레거시 시스템, 사내 BI, 여러 SaaS를 동시에 엮어야 했기 때문에, 이런 고정된 통합 방식으로는 복잡한 흐름을 표현하기 어려웠습니다.

두 번째는 “관찰 불가능한 블랙박스”였습니다.
성능이 나쁘거나, 처리 속도가 떨어지는 건 튜닝으로 어떻게든 해볼 수 있습니다.
하지만 에이전트가 지금 무엇을 하고 있는지, 어디에서 병목이 생기는지, 왜 어떤 작업은 실패했는지를 파악하기 어려운 구조라면 운영 리스크가 너무 커집니다.
오류 로그는 보여주지만, 전체적인 데이터 파이프라인과 실행 상태를 한눈에 보기 힘든 솔루션이 대부분이었습니다.

세 번째는 “부분 최적화”였습니다.
많은 제품이 특정 단일 도메인에 특화되어 있습니다. 예를 들어 개발팀만을 위한 코드 수정 에이전트라거나, 고객지원 티켓만 처리하는 에이전트처럼요¹².
우리가 원한 것은 개발, 운영, 데이터, 고객지원까지 걸쳐 있는 “통합 업무 프로세스”를 관통하는 에이전트였습니다. 팀마다 따로따로 에이전트를 쓰는 대신, 하나의 공통 인프라 위에서 다양한 역할을 수행할 수 있어야 했습니다.

처음엔 “이 정도면 될 것 같은데?” 싶었던 도구들도 실제 트래픽과 조직 규모를 얹고 돌려보면 금세 한계가 드러났습니다.
그때부터 고민의 방향이 바뀌었습니다.

“우리가 원하는 수준의 ‘백그라운드 에이전트 경험’을 얻으려면, 결국 직접 만들어야겠다.”

2. 자체 백그라운드 에이전트가 풀고자 한 아주 구체적인 문제들

우리가 새 에이전트에게 기대했던 건 추상적인 ‘AI’가 아니라, 아주 현실적인 문제 해결 능력이었습니다.

가장 먼저 겨냥한 것은 데이터 처리 속도와 실시간 분석이었습니다.
단순히 밤마다 배치로 돌려서 리포트나 만드는 정도로는 부족했습니다.
우리는 실시간에 가까운 수준으로 로그, 이벤트, 사용자 행동 데이터를 분석해, 그 결과를 다시 시스템에 반영하고 싶었습니다. 예를 들면 이런 것들입니다.

• 에러 패턴이 일정 임계치를 넘으면, 사람보다 먼저 에이전트가 탐지하고 알림을 보낼 것

• 특정 고객 구간에서 이탈률이 갑자기 튀면, 해당 세그먼트만 별도의 플로우로 보내고, 세일즈나 CS에게 슬랙 알림을 줄 것

• 반복적으로 발생하는 설정 문제나 단순 작업은 에이전트가 스스로 수정하거나, 수정 제안을 PR로 올릴 것¹

두 번째 목표는 “조직 맞춤형 자동화”였습니다.
백그라운드 에이전트가 단순 도구가 아니라, 우리 조직의 룰과 문화, 우선순위를 이해하는 “팀원”이 되기를 원했습니다.
예를 들어 어떤 팀은 로그를 Sentry로, 어떤 팀은 Datadog으로 관리하고 있어도, 에이전트는 이를 감추고 “문제 감지 → 영향 범위 분석 → 알림 → 해결 제안”이라는 공통 플로우로 일해야 합니다¹.

세 번째는 운영 효율성 극대화입니다.
사람이 해야 할 판단의 질을 떨어뜨리지 않으면서, 사람이 “굳이 하지 않아도 되는 일”을 에이전트가 먼저 떠안게 하는 것이 목표였습니다.
단순 반복적이고 규칙이 분명한 작업은 최대한 에이전트가 처리하고, 애매하고 복잡한 결정은 사람에게 끌어올리는 구조가 이상적이라고 봤습니다.

결국 이 모든 요구사항은 한 문장으로 압축됩니다.

“지금 회사가 일하는 방식을 깨트리지 않으면서, 보이지 않는 곳에서 일을 폭발적으로 많이 해줄 존재가 필요하다.”

3. 확장 가능한 아키텍처: ‘오늘’이 아니라 ‘내년 트래픽’ 기준으로 설계

백그라운드 에이전트는 이름 그대로 항상 돌아가는 시스템입니다.
이 말은 곧, 잘못 설계하면 눈에 안 띄는 곳에서 조용히 비용과 장애를 키우는 “숨은 폭탄”이 될 위험이 크다는 뜻이기도 합니다.

그래서 우리는 아키텍처 설계부터 “확장성”과 “운영 가능성(operability)”을 최우선으로 놓았습니다³⁴.

첫 번째 원칙은 가능한 한 stateless한 컴퓨트였습니다³.
에이전트의 각 작업 단위는 특정 서버 인스턴스에 붙잡히지 않도록 설계했습니다.
상태는 외부의 안정적인 스토리지나 큐에 놓고, 개별 워커는 언제든 수평 확장이 가능하도록 구성했습니다.
그래야 트래픽이 순간적으로 몰리거나, 특정 시점에 작업이 폭증해도, 단순히 워커 수만 늘려서 대응할 수 있습니다.

두 번째는 핫 패스(hot path)를 짧게 유지하는 것이었습니다³.
사용자 경험에 직접 영향을 주는 경로에서는 절대 무거운 일을 하지 않습니다.
어떤 기능이 사용자 요청과 동시에 돌아가야 한다면, 그 요청이 완료된 뒤에 에이전트가 비동기로 후속 작업을 처리하도록 설계합니다.
예를 들어 사용자가 버튼을 누른 뒤 로그 분석, 리포트 생성, 슬랙 알림까지 모두 한 번에 동기 처리하면, 결국 사용자는 “버튼이 안 눌리는 서비스”라고 느끼게 됩니다.
핵심 사용자 흐름은 최대한 가볍게, 나머지는 모두 에이전트로 미루는 구조를 만들었습니다.

세 번째는 동시성과 백프레셔(backpressure)의 철저한 관리였습니다³.
“트래픽이 많으면 인스턴스를 더 늘리면 되겠지”라는 생각은 실제 운영에서는 금방 한계를 드러냅니다.
큐 길이, 워커 수, 외부 시스템 호출 횟수에 모두 명시적인 상한을 두고, 특정 한도를 넘으면 작업을 거절하거나 재시도하도록 만들었습니다.
이렇게 해야 갑작스러운 피크 상황에서도 전체 시스템이 무너지는 대신, 일부 기능만 점진적으로 느려지거나 제한되는 “우아한 저하(Graceful degradation)”가 가능합니다³.

마지막으로, 관측 가능성(Observability)을 아키텍처의 일부로 넣었습니다⁴.
에이전트가 무엇을 언제, 어떻게 처리했는지 시계처럼 들여다볼 수 있어야 합니다.
그래서 각 작업의 상태, 실패 사유, 재시도 횟수, 처리 시간 등을 모두 메트릭으로 남기게 했고, 이를 기반으로 알람과 대시보드를 만들었습니다.
운영자가 “요즘 에이전트가 느린 것 같은데?”라는 감으로만 판단하지 않아도 되게 만든 셈입니다.

4. 구성은 더 쉽게, 구조는 더 모듈식으로

에이전트의 뇌가 아무리 똑똑해도, 설정이 복잡하면 현업 팀은 결국 쓰지 않습니다.
우리가 목표로 한 것은 “개발팀이 아닌 사람도 쓸 수 있는 백그라운드 에이전트”였습니다.

그래서 두 가지 축으로 접근했습니다.

첫 번째는 쉬운 구성(Declarative Configuration)입니다.
에이전트를 “코딩해서” 만드는 게 아니라, 마치 워크플로를 정의하듯 “이런 이벤트가 발생하면, 이런 조건일 때, 이런 작업을 수행하라”는 식으로 선언적으로 구성할 수 있게 설계했습니다.
이 선언적인 구성을 통해, 마케팅 팀이든 운영 팀이든 직접 자신들의 자동화 플로우를 만들고 수정할 수 있습니다.
개발팀은 이들이 사용할 공용 모듈과 안전장치를 만들어 두는 역할에 집중합니다.

두 번째는 모듈식 디자인입니다.
각 기능을 잘게 쪼갠 “스킬(혹은 능력)” 단위로 바라보는 접근이었습니다.
AI 에이전트를 위한 Agent Skills 같은 표준이 추구하는 것과 비슷하게⁵,
“데이터 가져오기”, “필터링”, “알림 보내기”, “코드 리팩터링 제안하기” 같은 능력을 작은 블록으로 만들고, 이를 조합해 더 복잡한 자동화 시나리오를 구성할 수 있게 했습니다.

이렇게 모듈화해 두면 좋은 점이 많습니다.

한 번 만든 “에러 알림 스킬”을 여러 팀에서 재사용할 수 있습니다.
어떤 팀은 슬랙, 어떤 팀은 이메일, 어떤 팀은 티켓 시스템으로 알림을 받고 싶다면, 알림 스킬만 해당 채널에 맞게 교체하면 됩니다.
새로운 도구를 도입해도 전체를 갈아엎지 않고, 관련 모듈 몇 개만 교체하면 시스템 전체가 그대로 살아 있습니다.

결국 에이전트는 거대한 하나의 프로그램이 아니라, 여러 스킬과 구성 요소를 조합한 플랫폼에 가깝게 진화했습니다.

5. 실시간 분석과 속도의 게임: 경쟁 우위를 만드는 백그라운드 에이전트

“이걸 굳이 직접 만들었을 때, 뭐가 그렇게 달라지나요?”
이 질문은 의외로 자주 나옵니다.
결국 핵심은 속도, 그리고 그 속도가 만들어내는 경쟁력의 차이에 있습니다.

첫 번째로, 데이터 처리 속도가 눈에 띄게 빨라졌습니다.
일부 프로세스는 일 단위 배치에서 분 단위, 어떤 것은 초 단위에 가까운 near-real-time으로 바뀌었습니다.
이 말은, 문제를 발견하고 대응하는 시간이 줄어든다는 뜻이고, 고객 경험 측면에서는 “문제가 있다고 느끼기도 전에 이미 조치한 상태”를 만들 수 있다는 의미입니다.

두 번째로, 실시간 분석 능력이 강화되었습니다.
에이전트는 단순히 로그를 모으는 것이 아니라, 패턴을 인식하고, 기준을 넘으면 즉시 반응합니다.
예를 들어, 에러율이 특정 구간에서만 튄다거나, 특정 국가에서만 성능이 나빠지는 경우를 스스로 감지해, 관련 팀에게 정확한 맥락과 함께 전달합니다.
분석이 사람 손에만 의존할 때는 “알고 나서 대응”하지만, 에이전트가 있으면 “발생하면서 동시에 대응”하는 구조에 가까워집니다.

세 번째로, 내부 개발 생산성이 크게 올라갑니다.
코드 기반에서 백그라운드 에이전트가 직접 수정 제안, 테스트, PR 생성까지 관여하는 방식은 이미 일부 기업에서 효과를 입증하고 있습니다¹.
우리는 이 개념을 우리 스택과 툴 체인에 맞게 재구성해, 반복적인 코드 변경이나 설정 수정은 에이전트가 먼저 시도하고, 사람은 리뷰와 승인에 집중하도록 만들고 있습니다.

이 세 가지 요소가 합쳐지면, 눈에 보이는 지표로는 “머지되는 PR의 일부를 에이전트가 직접 기여한다”거나¹, “동일 인력으로 더 많은 트래픽과 프로젝트를 감당한다”는 결과로 나타납니다.
하지만 체감되는 가장 큰 차이는, 팀이 반복업무에서 해방되고 “진짜 중요한 고민”에 시간을 쓸 수 있게 된다는 점입니다.

6. 시장에서의 위치와 고객 경험은 어떻게 달라지는가

자체 백그라운드 에이전트는 겉으로 보기엔 고객이 직접 만지는 기능이 아닙니다.
그러나 고객 경험과 시장에서의 포지션에는 생각보다 크게 영향을 줍니다.

먼저, 서비스 품질의 일관성이 올라갑니다.
사람이 수동으로 점검하고 대응하던 것들을 에이전트가 24시간 같은 기준으로 감시하고 처리하기 때문에, 시간대, 담당자, 팀마다 품질 편차가 줄어듭니다.
결과적으로 고객은 “언제 들어와도 비슷한 성능, 비슷한 안정성”을 경험하게 됩니다.

둘째, 신규 기능 출시 속도가 빨라집니다.
내부적으로 많은 작업이 자동화되어 있기 때문에, 새로운 기능을 런칭할 때도 모니터링, 롤백, 알림, 실험 관리 같은 반복 서포트 작업을 에이전트가 맡습니다.
덕분에 팀은 기능 설계와 UX 개선에 더 집중할 수 있고, 같은 시간에 더 많은 실험을 시도할 수 있습니다.

셋째, 고객 지원과 운영에서도 한 단계 높은 대응이 가능합니다.
에이전트는 고객 행동 데이터를 분석하고, 특정 패턴을 보이는 고객군에게 사전에 안내를 보내거나, 문제를 겪은 고객에게는 선제적으로 보상을 제안하는 흐름까지도 자동화할 수 있습니다.
이는 단순히 비용을 줄이는 수준이 아니라, “이 회사는 내가 말하기 전에 이미 알고 움직인다”라는 신뢰로 이어집니다.

결국 자체 에이전트를 구축한다는 것은, 기술 스택에 하나의 기능을 더하는 일이 아니라,
“우리가 일하는 방식”과 “고객에게 가치를 전달하는 속도”를 근본적으로 바꾸는 선택에 가깝습니다.

시사점: 남의 에이전트 vs. 나만의 에이전트, 어떻게 선택할 것인가

지금 이 글을 읽고 있는 당신이 당장 자체 백그라운드 에이전트를 만들어야 하는 건 아닙니다.
하지만 최소한, 이런 질문은 해보는 게 좋습니다.

1. 우리 조직의 핵심 워크플로는 기존 솔루션의 제한된 모델 안에 억지로 끼워 맞추고 있는가, 아니면 도구가 우리 방식에 맞춰주고 있는가.

2. 트래픽과 팀 규모가 두세 배로 늘었을 때, 지금 구조로도 여전히 운영 가능할 것 같은가.

3. 반복적이고 규칙적인 작업 중, “사람이 굳이 하지 않아도 될 일”이 너무 많지는 않은가.

만약 이 질문들에 대해 마음 속으로라도 “조금 불안하다”고 느껴진다면,
당장 자체 에이전트를 개발하지 않더라도, 언제, 어디까지는 직접 만들어야 할지에 대한 전략은 지금부터 준비할 만한 주제입니다.

우리가 깨달은 건 하나였습니다.
자동화의 경쟁력은 “몇 개의 기능을 쓰느냐”가 아니라,
“얼마나 우리 조직을 닮은 자동화를 가지고 있느냐”에서 갈린다는 사실입니다.

그리고 그 지점에 이르면, 남이 만든 에이전트는 결국 출발점일 뿐,
결승선까지 데려다 줄 수 있는 건 “우리 손으로 만든 에이전트”뿐이었습니다.

참고

¹Why We Built Our Own Background Agent

²Software Architecture Best Practices for Scalable Apps

⁵Agent Skills: The Open Standard for Custom AI Capabilities](https://www.bishoylabib.com/posts/claude-skills-comprehensive-guide)