4. 관찰-추론-행동: 브라우저 에이전트의 내부 루프

2026-04-18Views 15약 8분

관찰-추론-행동: 브라우저 에이전트의 내부 루프

브라우저 에이전트가 똑똑해 보이는 순간은 클릭을 잘해서가 아니다. '왜 지금 이 버튼을 누르는가'가 설명될 때다. 일반 챗봇이 한 번 답하고 멈춘다면, 에이전트는 웹페이지를 보고, 다음 수를 생각하고, 실제로 행동하고, 그 결과를 다시 읽는다. 이 반복 구조가 바로 에이전트를 에이전트답게 만든다.¹²

관찰-추론-행동: 브라우저 에이전트의 내부 루프

브라우저 에이전트의 심장박동

브라우저 에이전트의 기본 리듬은 단순하다. 관찰한다. 추론한다. 행동한다. 그리고 다시 관찰한다. 겉으로 보면 사소한 반복 같지만, 실제로는 매 단계에서 '현재 상태와 목표 사이의 차이'를 계산하는 과정이다. 목표가 '회원가입 폼을 제출하라'라면, 에이전트는 지금 페이지가 폼인지, 필드가 비어 있는지, 제출 버튼이 활성화되어 있는지부터 확인한다. 그다음 가장 작은 유효 행동 하나를 고른다.

이 구조의 중요한 점은 개발자가 미리 'A 다음에 B, 그다음 C'를 전부 하드코딩하지 않아도 된다는 것이다. 모델은 도구를 더 써야 하는지, 지금 답을 끝내도 되는지를 매 반복에서 판단한다.³ 그래서 같은 루프가 날씨 조회 같은 1단계 작업도 처리하고, 가격 비교처럼 탭을 여러 개 오가야 하는 8단계 작업도 처리한다.⁴

관찰: 에이전트는 무엇을 보고 있다고 말할까

브라우저에서의 관찰은 사람의 '눈치 보기'와 비슷하지만, 더 구조적이다. 에이전트는 보통 현재 URL, 페이지 제목, DOM이나 접근성 트리, 눈에 보이는 텍스트, 클릭 가능한 요소, 스크린샷, 포커스된 입력창, 로딩 상태, 열려 있는 탭 목록을 함께 본다.⁵⁶

여기서 핵심은 '많이 보는 것'이 아니라 '행동에 필요한 만큼 정확히 보는 것'이다. 예를 들어 로그인 버튼을 눌러야 할 때, 예쁜 전체 스크린샷보다 중요한 것은 현재 탭이 맞는지, 버튼이 실제로 활성화되어 있는지, 비슷한 이름의 버튼이 여러 개인지다. 브라우저 에이전트가 자꾸 엉뚱한 곳을 누르는 이유는 대개 행동 엔진이 나빠서가 아니라 관찰이 뭉뚱그려져 있기 때문이다.

이전 장에서 웹페이지 이해를 다뤘다면, 여기서는 그 이해가 '실행 가능한 상태'로 바뀐다고 보면 된다. 페이지를 읽는 것이 끝이 아니라, 다음 행동의 후보를 줄이는 재료가 된다.

추론: 다음 행동은 어떻게 선택될까

좋은 에이전트는 거창한 철학자가 아니라, 빈틈을 잘 찾는 현장 감독에 가깝다. 추론 단계에서 에이전트는 늘 비슷한 질문을 던진다.

최종 목표는 무엇인가.
지금까지 무엇을 끝냈는가.
현재 페이지에서 할 수 있는 유효한 행동은 무엇인가.
가장 적은 비용으로 목표에 가까워지는 다음 한 걸음은 무엇인가.

중요한 것은 '한 번에 다 해결하려 하지 않는다'는 점이다. 예를 들어 '온라인 강의 3개의 가격을 비교해 달라'는 요청을 받으면, 에이전트는 곧바로 비교표를 쓰지 않는다. 먼저 검색 결과에서 공식 가격 페이지로 들어갈 후보를 고르고, 각 후보를 새 탭으로 열고, 가격이 월 기준인지 연 기준인지, 할인 문구가 본 가격인지까지 확인한 뒤에야 비교를 시작한다. 즉, 추론은 멋진 문장을 쓰는 능력보다 '지금 필요한 정보가 무엇인지'를 판별하는 능력에 가깝다.¹⁴

계획 수립: 큰 지도와 작은 발걸음

브라우저 에이전트의 계획은 보통 두 층으로 나뉜다. 위층에는 큰 계획이 있고, 아래층에는 바로 실행할 다음 행동이 있다. 큰 계획은 '가격 페이지 3개 수집 → 가격 기준 통일 → 차이 요약' 같은 뼈대다. 작은 행동은 '현재 결과에서 첫 번째 공식 사이트를 새 탭으로 열기'처럼 손이 바로 움직일 수 있는 수준이다.

실전에서 계획은 고정된 계약서가 아니라 수정되는 지도에 가깝다. 첫 탭이 로그인 벽에 막히면, 에이전트는 계획을 버리는 대신 우회 경로를 추가한다. '공식 사이트 대신 공개 요금 페이지를 찾기'나 '다른 후보를 우선 비교하기'처럼 말이다. 이런 식의 분류와 계획-실행 전략은 브라우저 에이전트 런타임의 핵심 설계 포인트로 자주 등장한다.⁷

그래서 좋은 계획은 길어야 좋은 것이 아니다. 바뀔 수 있어야 좋은 계획이다.

상태 추적: 에이전트는 무엇을 기억해야 하나

브라우저 에이전트는 생각보다 건망증이 심하다. 매 단계의 출력이 다음 단계의 입력이 되기 때문에, 상태 관리가 느슨하면 방금 열어 둔 탭도 잊고, 이미 입력한 폼도 또 채우고, 실패한 버튼을 다시 누르며 같은 자리를 맴돈다. 그래서 실전 시스템은 상태를 따로 장부처럼 관리한다.⁵⁷

보통 추적해야 하는 상태는 네 갈래다.

작업 상태: 원래 목표, 제약 조건, 완료한 하위 작업, 아직 남은 질문
브라우저 상태: 현재 활성 탭, 탭별 URL과 제목, 스크롤 위치, 포커스된 요소, 다운로드나 팝업 여부
증거 상태: 추출한 가격, 확인한 텍스트, 스크린샷, 도구 실행 결과
복구 상태: 방금 어떤 오류가 났는지, 몇 번 재시도했는지, 어느 지점부터 다시 시작할 수 있는지

상태 추적이 중요한 이유는 단순하다. 에이전트가 '생각'을 잘해도, 잘못된 상태를 바탕으로 생각하면 결국 틀린다. 그래서 최근 브라우저 에이전트 프레임워크들은 히스토리 관리, 메시지 압축, 루프 감지, 체크포인트 같은 기능을 별도 계층으로 둔다.⁵

행동: 클릭은 짧고, 관찰은 길게

행동 단계는 가장 눈에 띄지만, 사실 가장 짧아야 한다. 클릭, 입력, 스크롤, 탭 열기, 대기, 텍스트 추출, 파일 업로드 같은 동작은 가능한 한 작고 검증 가능해야 한다.⁶

예를 들어 '검색해서 가장 싼 상품을 사라' 같은 요청을 받은 에이전트가 한 번에 열 개를 클릭하고 세 페이지를 건너뛰면, 중간에 어디서 어긋났는지 찾기 어렵다. 반대로 '첫 후보 열기 → 가격 확인 → 장바구니 버튼 존재 확인'처럼 쪼개면, 실패 지점이 바로 드러난다.

그래서 좋은 루프에서는 행동보다 행동 뒤의 확인이 더 중요하다. 버튼을 눌렀다면 정말 페이지가 바뀌었는지, 입력을 했다면 값이 필드에 남았는지, 다운로드를 시작했다면 파일 생성 이벤트가 있었는지를 다시 봐야 한다. 브라우저 자동화에서 흔한 버그는 '행동을 했다'가 아니라 '행동이 되었을 것이라고 믿었다'에서 시작한다.

오류 복구: 실패를 예외가 아니라 신호로 다루기

브라우저는 원래 변덕스럽다. 버튼이 늦게 나타나고, 셀렉터가 바뀌고, 팝업이 갑자기 끼어들고, API는 429를 던지고, 페이지는 로딩 중인 척 오래 버틴다. 그래서 브라우저 에이전트의 실패는 특별한 사건이 아니라 일상이다.

실전에서는 오류를 몇 가지로 나눠서 다루는 편이 안전하다.⁸ 일시적 오류는 재시도하면 된다. 예를 들어 속도 제한이나 네트워크 타임아웃은 지수 백오프처럼 잠깐 쉬었다가 다시 시도하는 것이 맞다. 반면 401, 403처럼 권한이 없는 문제를 같은 방식으로 열 번 재시도하면, 에이전트는 끈질긴 것이 아니라 답답한 존재가 된다.

브라우저 작업에서 자주 쓰는 복구 순서는 대체로 이렇다.

같은 행동을 그대로 반복하기 전에, 먼저 다시 관찰한다.
관찰 결과가 달라졌다면 선택자나 행동 경로를 바꾼다.
외부 서비스 장애처럼 환경 문제라면 백오프와 폴백을 쓴다.
장시간 작업이라면 체크포인트에서 재개한다.
결제, 삭제, 계정 변경처럼 되돌리기 어려운 단계에서는 사람에게 넘긴다.

이 순서가 중요한 이유는, 브라우저 에이전트의 많은 실패가 '클릭 능력 부족'이 아니라 '상태 오해'에서 나오기 때문이다. 다시 말해, 복구의 첫 단계는 종종 재시도가 아니라 재관찰이다.

멀티탭 처리: 방이 많아질수록 현재 위치가 중요해진다

브라우저 작업이 조금만 복잡해져도 탭은 금세 늘어난다. 검색 결과 한 탭, 공식 페이지 두 탭, 비교용 문서 한 탭, 로그인 창 팝업 한 탭. 문제는 탭이 많아질수록 에이전트가 '지금 어느 방에 서 있는가'를 잃기 쉽다는 점이다.

그래서 멀티탭을 잘 다루는 에이전트는 모든 탭을 동시에 세밀하게 조종하려 하지 않는다. 보통은 활성 탭 하나를 현재 작업 공간으로 삼고, 나머지 탭은 식별자와 상태만 관리한다. 탭 ID, 제목, URL, 누가 이 탭을 열었는지, 아직 읽지 않았는지 같은 정보가 여기서 중요하다.⁹

실행 제어 측면에서도 원칙이 있다. 활성 탭에서 벗어날 때는 이전 탭의 제어를 풀고, 새 탭이 전경으로 오면 그곳에서 다시 관찰과 제어를 시작하는 방식이 안정적이다.⁹ 그래야 새 탭이 열렸는데도 이전 탭의 디버거 상태나 가상 시간이 남아서 화면이 멈추는 문제를 줄일 수 있다.

흥미로운 점은, 멀티탭은 꼭 '동시 조작'을 뜻하지 않는다는 것이다. 많은 시스템은 한 작업 안에서는 사실상 순차적으로 탭을 넘나들고, 병렬 처리는 여러 세션이나 여러 에이전트로 분리한다. OpenAI의 Operator 소개에서도 여러 작업을 여러 대화로 동시에 돌리는 비유가 나오는데, 이것은 '한 탭 안에서 모든 것을 한꺼번에 한다'보다 '작업 단위를 분리해 병렬화한다'에 더 가깝다.¹⁰

즉, 멀티탭의 핵심은 탭 수가 아니라 포커스 관리다.

무한 루프를 피하려면 종료 조건이 먼저 있어야 한다

브라우저 에이전트가 사람보다 빨리 지치는 이유는 토큰과 시간이 돈이기 때문이다. 루프가 강력한 이유는 반복할 수 있어서지만, 위험한 이유도 반복할 수 있어서다. 그래서 좋은 에이전트는 시작할 때부터 끝나는 조건을 함께 가진다.¹³

대표적인 종료 조건은 몇 가지로 정리된다.

성공 조건: 사용자가 원하는 산출물이 확보되었는가
반복 한도: 최대 몇 단계까지만 시도할 것인가
예산 한도: 시간, 토큰, API 비용을 얼마나 쓸 것인가
승인 조건: 결제나 전송처럼 민감한 행동 전에 사람 확인이 필요한가

이 조건이 없으면 에이전트는 '아직 뭔가 더 확인하면 더 좋아질지도 모른다'는 유혹에 약하다. 특히 검색, 비교, 정리 작업에서는 완벽주의가 곧 무한 루프가 된다.

작은 예시: 가격 비교 에이전트는 왜 그런 다음 수를 두는가

사용자가 '세 개의 AI 브라우저 서비스 가격을 비교해 줘'라고 말했다고 하자. 에이전트의 내부에서는 대략 이런 일이 벌어진다.

처음 관찰에서는 검색 결과 페이지, 현재 탭 하나, 공식 사이트 후보 여러 개가 보인다. 여기서 추론은 단순하다. 비교를 하려면 공식 가격 근거가 필요하니, 후보 셋을 새 탭으로 연다.

다음 관찰에서는 탭이 네 개가 된다. 한 탭은 메인 홈페이지, 두 탭은 가격 페이지, 한 탭은 로그인 유도 페이지다. 여기서 추론은 바뀐다. 로그인 벽에 막힌 탭은 바로 재시도하지 않고, 공개 요금 정보가 있는 다른 경로를 찾거나 우선순위를 뒤로 미룬다.

이후 행동은 가격 텍스트 추출, 월·연 기준 통일, 무료 체험 여부 확인으로 쪼개진다. 한 단계가 끝날 때마다 상태 장부에는 '서비스 A: 월 20달러, 서비스 B: 연 결제 할인 있음' 같은 증거가 쌓인다.

마지막으로 에이전트는 다시 묻는다. 이제 비교 가능한 근거가 충분한가. 충분하다면 멈추고 답한다. 부족하다면 부족한 항목 하나만 더 찾는다. 바로 이 질문, '지금은 계속할 때인가 멈출 때인가'가 내부 루프의 마지막 스위치다.

사람이 보면 더 잘 이해되는 설계 원칙

브라우저 에이전트의 내부 루프를 사람 언어로 번역하면 의외로 단순하다.

한 번에 하나의 유효 행동만 고른다.
행동 직후에는 반드시 환경을 다시 읽는다.
기억은 모델 머리에만 두지 말고 상태로 남긴다.
실패하면 먼저 다시 보고, 그다음 다시 시도한다.

이 네 가지가 지켜지면 에이전트는 덜 화려해 보여도 훨씬 믿을 만해진다. 반대로 이 원칙이 무너지면, 겉보기에는 빠르지만 실제로는 같은 버튼을 세 번 누르고 다른 탭에서 길을 잃는 자동 클릭 기계가 된다.

정리

브라우저 에이전트의 핵심은 클릭 기술이 아니라 루프 설계다. 관찰은 세계를 읽고, 추론은 목표와 현재 상태의 차이를 계산하고, 행동은 그 차이를 줄이는 가장 작은 시도를 만든다. 상태 추적은 기억을 보강하고, 오류 복구는 실패를 다음 판단의 재료로 바꾸며, 멀티탭 처리는 여러 작업 공간 사이에서 현재 위치를 잃지 않게 해준다.

결국 브라우저 에이전트는 '웹을 쓰는 AI'가 아니라, '웹에서 계속 상황을 업데이트하며 일하는 AI'다. 그 차이를 이해하는 순간, 다음 행동이 왜 나왔는지가 보이기 시작한다.