2026-08-28

AI 에이전트는 정말 24시간 일하게 될까? ‘항상 켜진 에이전트’의 현실과 한계

클라우드에서 여러 작업을 이어 수행하는 AI 에이전트를 사람이 승인 지점에서 감독하는 장면

AI 에이전트가 24시간 사람 없이 완전히 회사를 운영하는 단계에 들어선 것은 아닙니다. 다만 2026년 8월에는 에이전트를 클라우드에 상주시켜 일정이나 이벤트에 반응하고, 여러 단계의 일을 이어서 수행하며, 정해진 지점에서 사람이 승인하는 ‘always-on’ 구조가 실제 제품과 인프라로 빠르게 들어오고 있습니다. 이제 중요한 질문은 ‘얼마나 오래 켜 둘 수 있나’보다 무엇을 맡기고, 어디서 멈추게 하며, 어떤 증거를 보고 다음 단계로 넘길 것인가입니다.

왜 ‘항상 켜진 에이전트’가 갑자기 현실적인 말이 됐나요?

지금까지 많은 코딩 에이전트는 사람이 노트북 앞에서 프롬프트를 넣고 결과를 확인하는 방식으로 쓰였습니다. 작업이 끝나거나 세션이 끊기면 흐름도 함께 멈췄습니다. 최근에는 이 실행 위치를 개인 PC에서 클라우드 런타임으로 옮기고, 사람이 매번 시작 버튼을 누르지 않아도 일정·GitHub 이벤트·CI 실패 같은 신호를 받아 다음 일을 시작하는 구조가 늘고 있습니다.

OpenHands가 8월 11일 공개한 설명은 이런 변화를 ‘one-off prompts’에서 ‘always-on systems’로의 이동이라고 표현합니다. 백그라운드에서 실행되고, GitHub·Slack·예약 작업 같은 이벤트에 반응하며, PR 검토·CI 실패 수정·문서 업데이트를 반복 가능한 팀 워크플로로 바꾸는 방향입니다. 여기서 ‘always-on’은 모델이 무한히 혼자 판단한다는 뜻이 아니라, 필요한 실행 환경과 트리거가 계속 살아 있다는 의미에 가깝습니다.

8월 27일 Warp가 공개한 cloud software factory 설명도 같은 흐름을 더 넓게 잡습니다. 이 구조에서는 에이전트가 이슈를 분류하고, 명세를 만들고, 구현하고, 검증하고, 리뷰하고, 모니터링하는 단계를 하나의 자동화 루프로 묶습니다. 중요한 차이는 단순히 에이전트를 오래 돌리는 데 있지 않습니다. 각 실행을 측정하고 결과를 평가해 다음 실행의 모델·맥락·스킬을 조정하는 운영 계층이 붙는다는 점입니다.

24시간 자동화가 실제로 가능한 일

저녁 7시에 개발자가 노트북을 닫기 전에 ‘CI가 실패하면 원인을 조사하고 수정안을 준비하라’는 작업을 걸어 두는 장면을 생각해 볼 수 있습니다. 클라우드 에이전트라면 노트북이 꺼져도 이벤트를 받고, 저장소를 읽고, 테스트를 실행하고, 수정 브랜치나 검토 자료까지 준비할 수 있습니다. 다만 다음 날 아침 사람이 보는 것은 ‘밤새 알아서 배포된 결과’가 아니라, 검증 가능한 변경과 실행 기록이어야 안전합니다.

맡길 일	에이전트가 할 수 있는 범위	사람이 남겨야 할 지점
이슈 분류	라벨·우선순위 후보 생성	중요도·담당자 최종 결정
CI 실패	로그 분석·수정안·테스트	병합 승인
PR 검토 준비	변경 요약·위험 지점 표시	리뷰 판단
문서 갱신	코드 변경과 문서 차이 탐지	외부 공개 확인
정기 코드 점검	중복·취약 패턴·의존성 후보 탐지	실제 수정 범위 승인
테스트·평가	반복 실행·결과 수집	기준 변경과 배포 결정
모니터링 후속	오류 신호를 새 작업으로 전환	운영 시스템 변경 승인

이 표에서 눈여겨볼 부분은 사람의 역할이 사라지지 않는다는 점입니다. 반복 검색, 로그 읽기, 테스트 재실행, 초안 작성처럼 되돌리기 쉬운 일은 에이전트가 오래 맡을 수 있습니다. 반대로 병합, 배포, 데이터 삭제, 권한 변경처럼 잘못됐을 때 피해가 큰 행동은 짧은 승인 지점을 남기는 편이 낫습니다.

클라우드 소프트웨어 팩토리가 등장한 이유

코딩 에이전트 하나를 잘 쓰는 것과 조직이 에이전트를 계속 운영하는 것은 다른 문제입니다. 개인 도구에서는 좋은 프롬프트와 모델 선택이 중요하지만, 상시 실행에서는 누가 어떤 저장소에 접근했는지, 몇 번 재시도했는지, 비용이 얼마나 들었는지, 실패했을 때 어디서 멈췄는지까지 남아야 합니다. 그래서 최근 제품들이 에이전트 자체보다 런타임·스케줄·권한·측정·감사 기록을 함께 묶기 시작했습니다.

Warp Factories는 8월 18일 기준 closed beta로 소개됐습니다. Warp는 어떤 모델과 어떤 코딩 harness를 쓰든 클라우드 쪽에 실행·평가·메모리·제어 계층을 붙이는 구조를 제시합니다. 8월 27일 별도 설명에서는 Claude Code 같은 기존 코딩 도구를 대체하는 것이 아니라, 그 도구를 언제 어떤 작업에 돌릴지 정하는 런타임과 오케스트레이션, 사람 승인과 측정 계층을 더한다고 설명했습니다.

이 차이는 꽤 실용적입니다. ‘더 똑똑한 모델’을 고르는 경쟁에서 ‘작업이 반복돼도 같은 규칙으로 안전하게 실행되는 시스템’을 만드는 경쟁으로 평가 기준이 이동하기 때문입니다. 에이전트가 한 번 훌륭한 답을 내는 것보다 열 번째 실행에서도 같은 금지 범위를 지키고, 실패 이유를 남기고, 필요하면 멈추는지가 운영에서는 더 중요합니다.

사람이 사라지는 게 아니라 승인 지점이 바뀝니다

두 번째 장면은 조금 다릅니다. 에이전트가 밤새 이슈를 분석하다가 처음 세운 가정이 틀렸는데도 계속 코드를 고치고 테스트를 반복한다고 해보겠습니다. 오래 실행할 수 있다는 능력은 이때 장점이 아니라 비용과 위험을 키우는 장치가 됩니다. 그래서 상시 실행 에이전트에는 ‘계속해도 되는 조건’과 함께 ‘지금 멈춰야 하는 조건’이 필요합니다.

같은 오류를 몇 번까지 재시도할지 정합니다.
한 작업에 쓸 최대 실행시간이나 비용 한도를 둡니다.
접근 가능한 저장소·디렉터리·외부 서비스 범위를 제한합니다.
새 권한이 필요하면 자동 확장하지 않고 승인을 요청하게 합니다.
테스트 실패나 요구사항 충돌이 계속되면 사람에게 넘깁니다.
병합·배포·데이터 변경 전에는 별도 검증 증거를 요구합니다.
모든 주요 행동과 판단 근거를 나중에 되짚을 수 있게 기록합니다.

기업용 에이전트 훈련도 같은 문제를 드러냅니다. TechCrunch가 8월 26일 보도한 Arga는 Salesforce나 Workday 같은 기업 소프트웨어를 단순 API 모형으로 만들지 않고, 권한 체계와 webhook까지 포함한 디지털 트윈으로 재현해 에이전트를 훈련·시험한다고 설명합니다. 실제 업무에서는 화면을 클릭할 줄 아는 것보다 ‘누가 무엇을 할 수 있는가’라는 상태와 권한을 제대로 다루는 일이 더 어렵다는 뜻입니다.

정말 밤새 맡겨도 되는 에이전트가 나오고 있나요?

방향은 분명하지만 ‘완성된 24시간 자율 AI’라고 부르기에는 아직 이릅니다. WIRED는 8월 27일 공개된 Codex 코드 변경을 검토해 OpenAI가 ‘Persistent mode’를 개발하고 있다고 보도했습니다. 보도에 따르면 이 설정은 에이전트가 수동으로 잠들게 할 때까지 일을 이어가고, 이전 작업에서 후속 작업을 제안하는 더 적극적인 동작을 시험하는 방향입니다.

여기서 상태 표현이 중요합니다. Persistent mode는 이 글을 쓰는 시점에 공식 출시된 기능이 아니라 개발·테스트 중인 것으로 보도된 기능입니다. 따라서 ‘Codex가 이제 무제한으로 24시간 일한다’고 말하면 사실보다 앞서갑니다. 다만 OpenHands의 always-on 운영 구조, Warp의 cloud software factory, OpenAI가 시험 중인 persistent 실행이 비슷한 시기에 나타났다는 점은 에이전트의 다음 경쟁 축이 ‘한 번의 응답 성능’에서 ‘지속적으로 일을 맡길 수 있는 운영성’으로 넓어지고 있음을 보여 줍니다.

도입 전에 먼저 확인할 8가지

트리거: 일정, 이슈, CI 실패처럼 무엇이 작업을 시작시키는지 한 문장으로 정합니다.
완료 조건: ‘고쳐라’가 아니라 어떤 테스트와 결과가 있어야 끝난 것으로 보는지 적습니다.
권한: 읽기, 쓰기, 외부 호출, 배포 권한을 한 묶음으로 주지 않습니다.
중단 조건: 반복 실패, 충돌, 새로운 권한 요구가 생기면 자동으로 멈추게 합니다.
시간·비용: 작업별 최대 실행시간과 사용량 상한을 둡니다.
검증 증거: 테스트 결과, diff, 로그처럼 사람이 실제로 확인할 자료를 남기게 합니다.
사람 승인: 병합·배포·삭제처럼 되돌리기 어려운 행동 앞에는 짧은 승인 단계를 둡니다.
감사 기록: 어떤 트리거로 시작해 무엇을 바꿨고 왜 멈췄는지 나중에 재구성할 수 있어야 합니다.

처음부터 업무 전체를 맡길 필요는 없습니다. 반복되는 저위험 작업 하나를 골라 시작하고, 성공률만 보지 말고 재작업 횟수와 사람 개입시간, 잘못된 변경 비율을 함께 기록하는 편이 좋습니다. 그래야 ‘오래 돌아간다’와 ‘실제로 일을 덜어준다’를 구분할 수 있습니다.

어디까지를 아직 과장으로 봐야 하나요?

첫째, always-on은 unlimited autonomy와 같은 말이 아닙니다. 클라우드 런타임이 계속 살아 있어도 모델은 잘못된 가정을 만들 수 있고, 외부 서비스 상태는 바뀌며, 자격증명과 권한은 만료되거나 과도할 수 있습니다. 오래 실행하는 능력은 좋은 검증과 중단 장치가 있을 때만 장점이 됩니다.

둘째, 지금 보이는 제품들은 공개 범위가 서로 다릅니다. OpenHands는 실제 자동화·클라우드 운영 구조를 설명하고 있지만 세부 기능은 배포 환경에 따라 달라집니다. Warp Factories는 closed beta이고, WIRED가 보도한 OpenAI Persistent mode는 아직 공식 출시가 아닙니다. 오늘의 기능표를 업계 전체의 완성형으로 일반화하면 안 됩니다.

셋째, 상시 에이전트가 곧 인력 대체를 뜻하지도 않습니다. 오히려 현재 제품 설계를 보면 사람은 매 단계에서 직접 타이핑하는 역할에서 작업 경계, 권한, 평가 기준, 승인 지점을 설계하는 역할로 이동하고 있습니다. ‘사람이 없는 시스템’보다 ‘사람이 필요한 순간을 더 명확히 정한 시스템’에 가깝습니다.

오늘 시작한다면 이렇게 해보세요

가장 좋은 첫 실험은 실패해도 되돌리기 쉬운 반복 업무 하나입니다. 예를 들어 매일 발생하는 CI 실패를 분석해 수정 브랜치와 테스트 결과까지만 준비하게 하고, 병합은 사람이 하도록 둘 수 있습니다. 며칠 돌린 뒤에는 에이전트가 몇 시간을 일했는지가 아니라 실제로 해결된 건수, 잘못된 수정, 다시 사람이 손댄 횟수를 비교합니다.

반복되는 저위험 작업 하나를 고릅니다.
시작 신호, 수정 가능 범위, 금지 행동, 중단 조건을 적습니다.
최대 실행시간과 비용 한도를 정합니다.
최종 행동 전에 필요한 테스트와 사람이 볼 증거를 고정합니다.
병합·배포는 처음에는 사람 승인으로 남겨 둡니다.
일주일 뒤 성공 건수보다 재작업과 오류까지 함께 비교합니다.

확인한 출처

FAQ

Always-on AI 에이전트는 24시간 쉬지 않고 스스로 일한다는 뜻인가요?

꼭 그렇지는 않습니다. 보통은 클라우드 실행 환경이 계속 살아 있고 일정·이벤트에 반응해 정해진 작업을 반복한다는 뜻에 가깝습니다. 장시간 자율 실행 여부와 권한 범위는 제품과 설정에 따라 다릅니다.

노트북을 꺼도 AI 에이전트가 계속 일할 수 있나요?

클라우드 런타임을 사용하는 제품이라면 가능합니다. OpenHands는 클라우드에서 GitHub·Slack·예약 트리거에 반응하는 반복 워크플로를 설명하고 있습니다. 로컬에서만 도는 에이전트는 해당 실행 환경이 꺼지면 함께 멈출 수 있습니다.

OpenAI Codex의 Persistent mode는 지금 바로 쓸 수 있나요?

이 글 작성 시점에는 공식 출시 기능으로 확인되지 않았습니다. WIRED가 공개 코드 변경을 근거로 개발·테스트 중이라고 보도한 상태이므로 출시 여부와 최종 동작은 이후 공식 안내를 확인해야 합니다.

상시 실행 에이전트를 처음 도입할 때 가장 중요한 것은 무엇인가요?

무엇을 시작 신호로 삼고, 어디까지 접근할 수 있으며, 어떤 조건에서 멈추고 사람에게 넘길지를 먼저 정하는 것입니다. 특히 병합·배포·데이터 변경처럼 되돌리기 어려운 행동에는 검증 증거와 사람 승인을 남기는 편이 안전합니다.

다음으로 해볼 일

최신 AI 소식과 실제 활용 포인트를 이어서 확인해 보세요.

AI 뉴스 더 보기

← 허브로 돌아가기