AI 워크플로
한 번 묻고 한 번 답받는 시대가 저물고 있다. 능숙한 사용자는 더 이상 명령을 일일이 입력하지 않는다. 대신 스스로 돌아가는 루프를 설계하고, 결과만 거둔다.
지난 1~2년간 사람들이 AI 코딩 도구를 쓰는 방식은 단순했다. 화면 앞에 앉아 작업을 설명하고, 결과를 받고, 마음에 들지 않으면 다시 설명한다. 이 요청-응답의 반복이 일의 전부였다. 그런데 가장 앞서 있는 사용자들 사이에서는 사뭇 다른 풍경이 자리 잡고 있다. 이들은 모델에게 매번 무엇을 하라고 입력하는 대신, 일이 끝날 때까지 알아서 돌아가는 루프(loop)를 만들어 두고 자리를 뜬다.
표현을 빌리자면 이렇다. "이제 나는 모델에게 프롬프트를 거의 넣지 않는다. 주로 만드는 것은 루프다. 나머지 일은 루프가 한다." 처음 듣기엔 다소 과장처럼 들리지만, 막상 그 구조를 들여다보면 지극히 단순한 발상에서 출발한다. 사람이 매번 엔터를 누르는 대신, 그 엔터를 자동으로 눌러 주는 장치를 끼워 넣는 것이다.
흥미로운 점은 루프가 하나의 고정된 기법이 아니라 폭넓은 스펙트럼이라는 사실이다. 5분짜리 가벼운 실험부터 며칠씩 멈추지 않고 돌아가는 장기 작업, 매일 같은 시각에 반복되는 일상 업무 처리까지, 같은 발상이 전혀 다른 규모로 적용된다. 이 글은 그 스펙트럼을 따라가며 루프가 실제로 어떻게 작동하고, 어떤 일에 잘 맞으며, 어디서 위험해지는지를 정리한다.
자율 코딩 에이전트는 본질적으로 하나의 순환 고리 안에서 일한다. 학계에서는 이를 관찰–판단–행동(Observe–Think–Act) 패러다임이라 부른다. 에이전트는 파일을 읽고(관찰), 다음에 무엇을 할지 정하고(판단), 코드를 고치거나 명령을 실행한 뒤(행동), 그 결과를 다시 읽어 들여 계획을 갱신한다. 이 고리는 작업이 끝나거나 무언가가 멈출 때까지 돈다.
문제는 "무언가가 멈춘다"가 자동으로 일어나는 일이 드물다는 데 있다. 명시적인 종료 조건이 없으면 에이전트는 작업이 끝나지 않았다고 느끼는 한 계속 계획하고 행동한다. 그래서 전통적인 방식에서는 사람이 그 빈자리를 메웠다. 200개 파일을 마이그레이션하거나 깨진 테스트를 전부 손보는 일이라면, 사람은 한 시간 내내 몇 분마다 "계속해"를 입력해야 했다. 장시간 에이전트 작업의 진짜 병목은 모델이 아니라, 엔터를 누르는 사람이었다.
루프는 바로 이 병목을 제거한다. 사람이 반복해서 입력하던 신호를 자동화 장치가 대신 넣어 주는 것이다. 핵심 전환은 추상화 수준이 한 단계 올라간다는 데 있다. 사용자는 더 이상 "다음 단계는 이것"이라고 지시하지 않는다. 대신 "이 일이 다 끝났다고 판단할 기준은 이것"이라고 한 번만 정의해 두고, 그 기준이 충족될 때까지 시스템이 알아서 돌게 한다.
한 번 묻고 답받는 방식이 질문할 때마다 매번 다시 불러야 하는 컨설턴트라면, 루프는 "이 일이 끝날 때까지 알아서 해 두라"고 맡겨 놓는 인턴에 가깝다. 인턴은 중간에 막히면 자기 노트를 보고, 한 걸음 진전시키고, 다시 노트에 기록한 뒤 그다음 일로 넘어간다. 당신이 자리를 비워도 일은 계속된다. 다만 그 인턴이 엉뚱한 방향으로 갈 수도 있으니, 무엇을 끝으로 볼지는 당신이 미리 정해 둬야 한다.
오늘날 자율 코딩 도구들은 대체로 세 가지 방식의 루프를 제공한다. 셋은 서로 경쟁하는 기능이 아니라, 작업의 성격에 따라 골라 쓰는 도구다. 트리거(무엇이 다음 회차를 일으키는가)와 종료 조건(언제 멈추는가)이 다르다는 점만 이해하면 구분은 명확하다.
가장 단순한 형태다. "5분마다 이 일을 하라"처럼 주기를 자연어로 정해 두면, 그 간격마다 같은 프롬프트가 다시 실행된다. 내부적으로는 세션 안에 일종의 예약 작업(cron job)을 걸어 두고, 지정한 기간 동안 정해진 간격마다 동작을 발화시키는 결정론적 장치다. 가령 "앞으로 3시간 동안 5분마다 이 부분을 탐색해 보라"고 걸어 둘 수 있다.
이 방식이 빛을 발하는 곳은 두 가지다. 하나는 시계에 맞춰 무언가를 감시해야 할 때다. 예컨대 "15분마다 특정 라벨이 붙은 변경 요청을 점검하고, 실패한 검사가 있으면 고치고, 본류에서 뒤처졌으면 맞춰 놓으라" 같은 당직(watchdog) 작업이다. 다른 하나는 열린 탐색이다. 새 프로젝트의 초기 단계처럼 정답이 정해지지 않은 국면에서, 폭넓고 개방적인 질문을 던져 두고 모델이 가진 역량을 마음껏 펼치게 하는 것이다. 코드를 시도하는 비용이 점점 싸지면서, 이렇게 야심 찬 시도를 던져 보는 일이 한결 가벼워졌다.
두 번째 형태는 시간이 아니라 조건으로 멈춘다. 사용자가 측정 가능한 종료 상태(예: "모든 테스트 통과, 린트 오류 없음")를 한 번 정의하면, 에이전트는 회차를 거듭하며 일하고, 매 회차가 끝날 때마다 별도의 작고 빠른 모델이 그 조건이 충족됐는지 판정한다. 충족되지 않았으면 계속 일하고, 충족됐으면 달성 사실을 기록하고 멈춘다.
여기서 중요한 설계가 하나 있다. 일을 하는 모델과 끝났다고 판정하는 모델을 분리한다는 점이다. 판정자는 명령을 직접 실행하거나 파일을 뒤지지 않는다. 작업 모델이 이미 드러내 놓은 결과만 보고 "됐다/아직"의 두 가지만 결정한다. 결정이 단순하기에 가볍고 저렴한 모델로도 충분하다. 이는 코딩 에이전트만의 발상이 아니라, 추론 시스템 전반에서 검증·심판 모델을 따로 두는 흐름의 일부다.
목표 루프는 시험을 보는 학생(작업 모델)과 답안을 채점하는 감독관(평가 모델)을 따로 두는 것과 같다. 학생은 계속 답을 고쳐 쓰고, 감독관은 채점 기준표만 들고 "합격/불합격"을 매 회차 판정한다. 학생이 스스로 "다 풀었다"고 선언하게 두면 대충 끝내 버릴 수 있지만, 별도 채점자가 객관적 기준으로 막아 서면 기준을 진짜로 만족할 때까지 멈추지 못한다.
세 번째는 실행 위치 자체를 옮긴다. 앞의 두 루프가 사용자의 세션 안에서 돈다면, 이 방식은 관리형 클라우드 인프라에서 일정·API 호출·저장소 이벤트 등을 방아쇠 삼아 돈다. 노트북을 닫아도 작업은 계속된다. 데일리 이슈 분류, 검사 실패 요약, 릴리스 브리핑 생성, 정기 보안 점검처럼 사람이 매번 시동을 걸 필요가 없는 일이 여기에 어울린다.
실무 감각으로 보면, 사용자가 직접 운전하며 결과를 즉시 보고 싶은 일은 세션 안의 인터벌·목표 루프가, 한 번 설정해 두고 잊고 싶은 정형 업무는 클라우드 스케줄이 맡는 식으로 역할이 나뉜다.
이 모든 흐름의 원형이 된 기법이 하나 있다. 2025년 중반, 한 개발자가 만화 캐릭터의 이름을 따 "랠프 위검(Ralph Wiggum)"이라 부른 루프 패턴이다. 순진할 정도로 끈질긴 그 캐릭터처럼, 이 기법은 작업이 끝날 때까지 같은 프롬프트를 무한히 다시 먹이는 단순한 반복 고리다. 고안자 본인의 표현으로는 "랠프는 그냥 배시(bash) 루프다."
겉보기엔 조잡하지만, 이 기법에는 정교한 통찰이 숨어 있다. 진전은 모델의 문맥창(context window)이 아니라 파일과 형상관리 기록에 남는다는 점이다. 매 회차마다 깨끗한 문맥으로 새로 시작하되, 이전 회차가 남긴 코드 변경과 커밋 기록을 읽어 들여 어디까지 했는지 파악한다. 그래서 긴 세션이 누적되며 문맥이 흐려지고 압축 과정에서 정보가 새는 문제를 피한다.
고안자는 이 기법의 철학을 이렇게 요약한다. "불확정적인 세계에서 결정론적으로 형편없는 방식이다. 예측 불가능하게 성공하느니 예측 가능하게 실패하는 편이 낫다." 다시 말해, 한 번의 천재적 시도에 기대기보다 단순한 반복을 신뢰성 있게 돌리는 쪽을 택한다는 뜻이다.
실제 보고된 성과는 상당히 인상적이다. 명확한 사양이 갖춰진 신규 프로젝트에서, 한 엔지니어가 5만 달러짜리 계약 작업을 약 300달러어치의 API 비용만으로 끝냈다는 사례가 회자됐다. 한 해커톤에서는 코딩 에이전트를 밤새 루프로 돌려 아침에 여섯 개 코드베이스에 걸친 1,000건 이상의 커밋을 받았다는 일화도 있다. 다만 이런 사례는 하나같이 사양이 분명하고 검증이 자동화된 작업이었다는 점이 중요하다.
랠프 패턴은 기계적 실행을 자동화할 뿐, 무엇을 만들 가치가 있는가라는 판단은 자동화하지 못한다. 큰 코드베이스에 대한 깊은 이해, 미묘한 설계 판단, 아키텍처 결정이 필요한 일에는 맞지 않는다. 또한 완료 약속을 지켜야 한다는 압박 탓에 루프를 빠져나오지 못하고 과도하게 매달리는 "오버베이킹(overbaking)", 혹은 스스로 됐다고 둘러대는 아첨성 응답 같은 실패도 보고된다. 기대치를 현실적으로 잡으면, 기계적 작업에서 2~3배의 속도 향상이 신뢰할 만한 수준이다.
루프가 며칠씩 멈추지 않고 돌 수 있는 까닭은 단 하나, 스스로 결과를 검증할 수단이 있기 때문이다. 단위 테스트를 돌릴 수 있는 작업, 명령 한 줄로 상태를 확인할 수 있는 작업, 출력이 객관적 기준에 맞는지 가려낼 수 있는 작업이라면 루프는 자기가 옳게 가고 있는지 매 회차 스스로 점검하며 나아간다. 검증이 가능한 작업일수록 사람의 개입 없이 더 오래, 더 멀리 갈 수 있다.
경계가 분명히 정해진(bounded) 작업이라면 이런 루프를 며칠씩 돌리는 것도 가능하다. 예컨대 여러 출처에 흩어진 복잡한 문서 더미를 파싱하는 작업처럼, 규모는 크지만 검증 가능한 측면이 있는 일이 좋은 후보다. 반대로 종료점을 측정할 수 없는 목표는 자율 에이전트가 스스로 닫기 어렵다.
| 잘 맞는 작업 | 맞지 않는 작업 |
|---|---|
| ● 테스트 마이그레이션 | ● 아키텍처 설계 결정 |
| ● 대규모 리팩터링 | ● 무엇을 만들지에 대한 판단 |
| ● 깨진 테스트 일괄 수정 | ● 모호한 요구사항 |
| ● 정형 문서·데이터 파싱 | ● 미묘한 맥락 판단이 필요한 일 |
| ● 스키마 적용·정합성 검사 | ● 종료점을 측정할 수 없는 목표 |
잘 맞는 쪽의 공통점은 명확하다. "끝났다"의 정의가 객관적으로 검증된다는 것이다. 테스트가 모두 통과하는가, 빌드가 성공하는가, 상태 확인 명령이 깨끗하게 떨어지는가. 이런 작업은 루프를 작은 단위로 쪼개 각 단계마다 검문소(checkpoint)를 두는 방식과 특히 잘 어울린다. 한 부분 작업을 돌리고, 출력을 검증하고, 통과했을 때만 다음으로 넘어간다. 그러면 3단계의 실패가 4~10단계의 비용을 통째로 날리지 않는다.
긴 루프를 그냥 한 번에 돌리는 것은 안전 장비 없이 절벽을 오르는 것과 같다. 중간에 미끄러지면 처음부터 다시다. 검문소를 두는 방식은 일정 높이마다 확보물을 박으며 오르는 것이다. 떨어져도 마지막 확보 지점까지만 미끄러진다. 토큰 비용도 같은 논리로 통제된다. 짧고 명확한 종료 조건을 가진 루프 여러 개가, 막연한 거대 루프 하나보다 훨씬 다루기 쉽다.
루프의 쓸모는 코딩에만 머물지 않는다. 오히려 일상에서 가장 큰 효용을 보이는 영역은 따로 있다. 자율 코딩 도구들은 대체로 자동화 탭(automations tab)을 갖추고 있다. 현재 돌아가는 자동화와 멈춰 둔 자동화가 나열되는 단순한 화면이다. 처음 등장했을 때는 큰 주목을 받지 못했지만, 매일 유용한 일 하나를 처리하는 자동화를 한번 손에 쥐고 나면, 그동안 사람이 떠안던 자질구레한 일들을 하나씩 넘길 발상이 줄지어 떠오른다.
받은편지함을 훑어 들어온 요청을 칸반 보드에 올리고, 어제 보드와 대조해 오늘 우선 처리할 일이 무엇인지 정리한다.
프로젝트를 일정 주기로 스캔해 취약점을 찾아 보고한다. 사람이 매번 시동을 걸 필요 없이 같은 검사가 반복된다.
한 주 동안 한 일을 모아 프로젝트 지침서나 재사용 가능한 절차서(스킬)로 정리해 둔다. 다음 작업의 출발점이 한 단계 높아진다.
열린 변경 요청을 일정 간격으로 점검해, 검사 실패를 고치고 본류와의 충돌을 정리하며 검토 대기 항목을 짚어 준다.
핵심은 이런 일들이 대부분 반복적이고, 컴퓨터 안에서 일어나며, 결과를 확인할 수 있다는 점이다. 당신이 매일·매주 되풀이하는 일 가운데 이 조건을 만족하는 것이 있다면, 상당수는 자동화로 넘길 수 있다. 정형 보고서 생성을 몇 주에서 몇 분으로 줄였다는 사례가 나오는 것도 이런 맥락이다.
루프의 가장 흥미로운 쓰임새 하나는 기억이다. 사람이 잠자는 동안 하루의 일을 정리하듯, 에이전트가 하루치 작업 기록을 되짚어 보게 하자는 발상이 최근 빠르게 퍼졌다. 이 오프라인 정리 과정을 업계에서는 '꿈꾸기(dreaming)'라 부른다. 과거 세션 기록들을 한꺼번에 비동기적으로 되돌아보며, 모델은 마치 렘(REM) 수면 중인 뇌처럼 기억을 청소하고 재정리한다. 중복을 합치고, 낡은 사실을 최신 진실로 덮어쓰고, 흩어진 대화에서 고차원의 통찰을 추려 낸다.
이 흐름을 제대로 이해하려면, AI 시스템의 학습이 한 곳이 아니라 세 개의 서로 다른 층위에서 일어난다는 점을 짚어야 한다. 흔히 '학습'이라 하면 모델 가중치를 바꾸는 일만 떠올리지만, 에이전트는 다음 세 층 모두에서 배운다.
맨 아래는 모델 자체의 가중치다. 가장 근본적이지만 갱신하려면 재학습이 필요해 가장 무겁다. 가운데는 하니스(harness), 곧 모델을 둘러싸고 모든 에이전트 인스턴스를 구동하는 코드와 도구, 상시 지시문이다. 맨 위는 컨텍스트로, 하니스 밖에 살면서 그때그때 동작을 조정하는 추가 지침과 절차서다. 루프로 돌리는 대부분의 '학습'은 바로 이 맨 위층에서 일어난다. 모델을 건드리지 않고도, 과거 기록을 정리해 다음번에 더 잘 작동할 컨텍스트를 만들어 두는 것이다.
이렇게 정리된 기억은 단순한 대화 로그 보관이 아니다. 작고 일관되며 점진적으로 펼쳐지는 형태로, 모델이 필요할 때 문맥창에 불러들여 "이 일에 대해서는 여기를 보면 된다"고 길을 찾게 하는 구조화된 지식 표상이다. 원자료(문서·기록·메모)를 일종의 소스 코드로 두고, 모델을 컴파일러처럼 써서 교차 참조된 정리본을 빚어낸다는 발상도 같은 갈래다.
사람의 뇌는 깨어 있는 동안 겪은 일을 그대로 저장하지 않는다. 잠자는 동안 중요한 것은 단단히 굳히고, 사소한 것은 흘려보내며, 흩어진 경험을 의미 있는 덩어리로 묶는다. 에이전트의 '꿈꾸기'도 정확히 그 일을 한다. 하루치 작업을 끝낸 뒤 한가한 시간에 자기 기록을 되짚어, 다음에 깨어났을 때 더 똑똑하게 움직일 수 있도록 기억을 재편하는 것이다.
이것이 바로 지속 학습(continual learning)이 가리키는 방향이다. 사전 학습된 지식과 고정된 하니스에 갇히지 않고, 세상의 다양한 과제를 직접 탐색하며 시간이 흐를수록 그 위에 쌓아 가는 시스템. 그런 시스템은 점진적으로 더 영리해지고, 더 많은 영역에서 쓸모를 늘린다. 앞으로 몇 달간 이 주제가 점점 더 자주 거론될 영역인 이유다.
자동화를 이야기하면 흔히 "처음부터 끝까지 사람 없이 돌린다"는 그림을 떠올린다. 하지만 가장 실용적인 운용은 그 반대다. 루프는 사람을 대체하기보다, 사람이 개입할 지점을 좋은 자리로 옮긴다. 끝까지 자동으로 보낼 필요는 없다. 사람은 여전히 고리 안에 머물 수 있다.
예를 들어 받은편지함을 정리하는 자동화에 메일 발송까지 맡기지는 않는 식이다. 초안을 잡는 데까지만 쓰고, 맥락을 완전히 잡아내지 못하는 부분은 사람이 판단한다. 자율 에이전트는 의도적으로, 정말 모호한 지점에서 멈춰 사람에게 묻도록 설계되는 경향이 있다. 자신 있게 결정하기 어려운 선택, 요구사항 간의 충돌, 두 갈래 모두 타당한 분기점 같은 곳이다. 몇 시간짜리 작업 내내 단 한 번도 확인하지 않고 내달린다면, 그것은 기능이 아니라 경고 신호에 가깝다.
흥미로운 점은, 사람이 개입하며 남기는 피드백 자체가 다시 학습 재료가 된다는 것이다. 루프가 매번 어떤 부분을 놓치는지 사람이 바로잡아 주면, 시간이 흐르며 그 작업을 끌어가는 프롬프트와 절차가 스스로 개선된다. 사람은 모든 출력을 일일이 검수하는 자리에서 벗어나, 시스템이 무엇을 어떻게 배울지를 설계하는 자리로 올라선다.
루프는 공짜가 아니다. 오히려 자율 에이전트 작업의 비용 구조는 일반적인 채팅과 근본적으로 다르다. 단발 질문이나 자동완성은 싸지만, 코드베이스를 읽고 여러 파일에 걸쳐 기능을 구현하고 테스트를 돌리며 실패를 거듭 고치는 한 번의 에이전트 작업은, 같은 사용자가 일주일간 가볍게 쓴 양보다 더 많은 토큰을 삼킬 수 있다.
비용을 키우는 진짜 동력은 출력이 아니라 입력 쪽이다. 회차가 쌓일수록 문맥이 누적되며 입력 토큰이 불어난다. 한 번의 본격적인 에이전트 세션에서 입력이 출력의 20~25배에 달한다는 분석도 있다. 자율 작업이 매 단계마다 자기 점검과 도구 호출, 오류 교정의 연쇄를 일으키기 때문이다. 그래서 "끝났다"의 기준이 없는 막연한 루프는, 단순히 모델이 비싸서가 아니라 멈출 줄 몰라서 비용이 폭주한다.
대다수의 비용 사고는 모델 단가가 아니라 종료 조건의 부재에서 비롯된다. 그래서 실무에서는 회차 상한, 지출 한도, 명시적 정지 기준을 설계에 미리 박아 둔다. 작업을 작은 부분으로 쪼개고 각 단계를 검증하며 통과한 것만 다음으로 넘기는 검문소 패턴은, 정확성뿐 아니라 비용 예측 가능성을 위한 장치이기도 하다. 한 분석은 추정과 실시간 모니터링만 갖춰도 토큰 비용을 충분히 예측 가능하게 만들 수 있다고 본다.
비용 외에 거버넌스의 공백도 있다. 자율성이 높아질수록, 누가 무엇을 승인하고 어디까지 책임지는지가 흐려진다. 그래서 변경을 곧장 본류에 밀어 넣는 대신 검토 대기열에 쌓아 두거나, 사람의 승인을 거쳐야 반영되도록 하는 운용이 표준으로 자리 잡는 중이다. 자율성과 통제는 맞바꾸는 관계가 아니라, 설계로 양립시켜야 하는 두 축이다.
루프는 하나의 기능이 아니라 사고방식의 전환이다. 작게는 탐색을 거드는 5분짜리 인터벌 루프, 크게는 며칠씩 돌아가는 목표 루프, 그리고 매일·매주 정해진 일을 처리하는 클라우드 스케줄까지, 같은 발상이 규모만 달리해 적용된다. 공통의 열쇠는 두 가지다. 끝을 객관적으로 정의할 수 있는가, 그리고 결과를 스스로 검증할 수 있는가. 이 둘이 갖춰질수록 루프는 더 멀리, 더 안전하게 간다.
그래서 던질 질문은 단순하다. 당신이 컴퓨터 앞에서 반복적으로 하는 일 가운데, 끝이 분명하고 결과를 확인할 수 있는 것은 무엇인가. 그런 일이라면 상당 부분을 루프에 넘길 수 있다. 판단이 필요한 일, 무엇을 만들 가치가 있는지를 정하는 일은 여전히 사람의 몫으로 남는다. 자동화가 가장 잘 작동하는 모습은 사람을 밀어내는 것이 아니라, 사람을 더 높은 자리로 옮겨 놓는 것이다.
덜 입력하고 더 설계한다. 프롬프트를 쓰는 시간이 줄고, 시스템과 에이전트가 관리할 루프를 짜는 시간이 늘어난다 — 그것이 지금 일어나고 있는 전환이다.