AI 에이전트, 940만 원 주고 살 것인가 직접 만들 것인가

$6,880짜리 AI 에이전트의 정체

Vertu가 6,880달러짜리 폴더블폰을 내놓으며 임원들에게 "AI 에이전트"를 팔겠다고 했다. TechCrunch가 직접 써본 결과는 솔직했다. AI 워크플로 성능은 그럭저럭. 배터리도 보안도 마찬가지. 황금 케이스에 담겨 있어도 AI 에이전트 자체는 요즘 웬만한 스마트폰과 크게 다르지 않았다는 평가다.

그러면 뭘 파는 걸까. 포장이다. "우리 회사 임원은 AI 에이전트를 쓴다"는 시그널이다. 그리고 설정하거나 고민할 필요 없이 박스에서 꺼내면 바로 되는 경험.

우리 같은 팀에게 이 뉴스가 의미 있는 이유는 따로 있다. 저 940만 원짜리 패키지 안에서 파는 것 — AI가 업무 흐름에 끼어들어 반복을 줄이고 판단을 보조하는 것 — 을 우리는 직접 만들어 쓰고 있기 때문이다. 그 과정에서 배운 것들이 "사거나 만들거나"를 고민하는 팀에게 쓸모 있을 것 같다.

AI 에이전트라는 말을 함부로 쓰기 전에

"에이전트"라는 단어가 너무 많이 쓰인다. Vertu 폰의 AI는 리뷰 내용을 보면 실상 고급 자동완성에 가깝다. 일정 요약, 이메일 초안, 회의 메모 정리 — 사람이 매 단계마다 "이거 해줘"라고 지시해야 한다면 그건 챗봇이지 에이전트가 아니다.

진짜 에이전트가 다른 점은 목표를 받아 스스로 계획을 세우고, 필요한 도구를 호출하고, 결과를 검증하고, 다음 행동을 결정한다는 것이다. 사람이 매 단계를 지시하지 않아도 된다는 게 핵심이다.

우리가 운영하는 봇 13개가 정확히 이 구조로 돌아간다. 각 봇은 목표(오늘 콘텐츠 발행)를 받고, 크롤러·LLM·DB·Discord를 도구로 쓰고, 검수 루프를 통해 결과를 검증하고, 스킵이나 재시도를 스스로 결정한다. 겉으로는 파이썬 스크립트처럼 보여도 구조로는 에이전트다. AI 개발을 업무 도구로 적극 수용하는 방향이 맞다고 생각한 건 이 구조를 직접 굴려보고 나서다.

직접 만들어보니 가장 어려운 건 LLM이 아니었다

처음엔 LLM 호출이 제일 어려울 거라 생각했다. 틀렸다. API 문서 보고 하루면 된다. 진짜 시간이 걸리는 건 연결의 신뢰성이었다.

2026년 6월 29일, kpopdex의 discover_groups 봇이 LLM 호출 사이 idle 5분 만에 폭사했다. MySQL wait_timeout이 300초인데 LLM 응답을 기다리는 시간이 그 창을 넘겨버린 것이다. (2013, 'Lost connection') — 그 다음 쿼리에서 그냥 죽었다. 이런 엣지케이스를 만나고, 공용 DB 헬퍼를 만들어 cursor() 직전마다 ping으로 연결을 살리는 로직을 박아넣기까지 반나절이 걸렸다.

같은 달, gov 봇이 4일간 발행을 멈췄다. 이유는 황당했다. sys.path.insert(0, '/opt/common')가 로컬 db.py를 가려버린 것. 코드 한 줄 차이인데 그걸 찾는 데 또 반나절이 걸렸다.

Vertu 폰이 파는 것의 실제 값어치가 여기에 있다. 이 모든 엣지케이스를 블랙박스 안에 숨겨준다는 것. 보이지 않으면 신경 쓰지 않아도 되니까.

비용 계산은 API 요금만이 아니다

Claude Haiku 기준 입력 100만 토큰에 $0.80, 출력 $4다. 봇 13개를 하루 풀로 돌려도 API 비용은 $510 수준이다. 연간 환산하면 $1,8003,600. Vertu 폰 한 대 가격의 약 40~52%다.

그런데 이건 LLM 비용만이다. 서버, 인프라, 그리고 가장 비싼 것 — 봇을 만들고 유지하고 장애를 잡는 시간 — 을 넣으면 계산이 달라진다. 반나절짜리 장애 디버깅 두 번이면 이미 상당한 기회비용이다.

팀이 크고 기술 인력이 부족할수록 이 비용은 커진다. 반면 코드를 직접 짜는 작은 팀에게는 DIY가 훨씬 싸다. 엣지케이스 하나 잡을 때마다 다음 장애 예방 비용까지 건지니까. 트레이드오프를 솔직하게 쓰면 이렇다: 직접 만들면 비용이 싸고 제어권이 있지만 장애를 내가 잡아야 한다. 사면 비용이 비싸고 블랙박스지만 새벽 3시에 알람이 안 온다.

에이전트를 업무에 붙일 때 실제 순서

경험에서 수렴한 순서가 있다. 봇을 하나씩 만들고 터뜨리면서 정리된 것이다.

반복하는 단일 작업 하나만 고른다. "뭔가 AI로 해보자"가 아니라 "이거 어제도 똑같이 했는데" 싶은 작업을 찾는 게 시작이다. 매일 같은 형식으로, 같은 소스에서, 같은 결과물을 만드는 것. 에이전트는 복잡한 판단보다 단순 반복에서 ROI가 바로 나온다.

검증 루프를 반드시 붙인다. LLM 출력을 검증 없이 그냥 발행하면 어느 날 이상한 내용이 나간다. 우리는 본문 1500자 미만 자동 차단, Claude Sonnet 기반 자동 검수 루프, 새벽 4시 재점검을 단계적으로 붙였다. 에이전트의 자율성은 검증 장치 위에서만 의미 있다.

도구 연결은 얇게 시작한다. 첫 버전에서 외부 API를 여러 개 연결하면 장애 지점이 그만큼 늘어난다. LLM 하나, DB 하나, 알림 하나로 시작하고 증명된 뒤에 늘려라. 동시에 모든 걸 붙이려다 아무것도 안정화하지 못한 봇을 몇 개 만들어봤다. 그래서 하는 말이다.

실패 모드를 먼저 설계한다. DB 연결이 끊기면, LLM 응답이 짧으면, 크롤 소스가 바뀌면 어떻게 할지를 코드에 박아두지 않으면 반드시 새벽에 장애가 온다. 스킵·재시도·Discord 알림을 공통 패턴으로 뽑아두는 것만으로도 유지보수 비용이 눈에 띄게 줄었다.

핵심 업무일수록 블랙박스는 위험하다

Vertu 폰이 틀린 제품은 아니다. IT팀이 없는 조직, 보안 요구가 높은 임원, 설정에 시간을 쓰고 싶지 않은 사람에게 올인원 패키지는 합리적 선택이다. 일정 관리나 이메일 초안 같은 주변 업무라면 블랙박스도 나쁘지 않다.

다만 업무 흐름의 핵심에 AI를 붙이려 한다면 얘기가 다르다. 콘텐츠 발행, 데이터 처리, 고객 응대 — 이런 곳에서 에이전트가 틀렸을 때 내가 고칠 수 없다면 그건 도구가 아니라 위험이다.

우리가 직접 만든 에이전트는 느리고 번거롭지만, 모든 결정을 내가 안다. 검증 로직도, 실패 처리도, 비용 통제도 직접 결정한다. 그 투명성이 장기적으로는 더 싸게 먹힌다. 봇이 잘못된 내용을 발행하려 할 때 가드가 잡아내는 구조를 스스로 설계했기에 가능한 일이다.

소규모 팀이 AI 에이전트를 도입할 때 선택지는 결국 두 개다 — 사거나 만들거나. 어느 쪽이 맞냐는 팀의 기술 역량과 그 에이전트가 얼마나 핵심 업무에 닿아 있느냐에 달려 있다. 핵심에 닿을수록, 직접 만든 쪽이 낫다.

원문: AI News & Artificial Intelligence | TechCrunch