에이전트 루프의 첫 단추, 관찰(Observation) — 세상의 상태를 맥락으로 번역하기

AI 에이전트를 정의하는 핵심 구조는 스스로 도는 루프(Loop)다. 그리고 그 루프의 첫 단추는 언제나 관찰(Observation)이다. 챗봇은 사람이 던져주는 텍스트에만 의존하지만, 에이전트는 자율적으로 자신의 실행 환경을 탐색하고 상태를 수집한다. 관찰이 부실하다는 것은 에이전트가 눈을 감고 코딩을 하거나 시스템을 제어하겠다는 것과 다름없다.

이 글에서는 에이전트 루프의 출발점인 관찰이 구체적으로 어떤 일을 수행하는지, 왜 필수적인지, 그리고 실제 개발 환경에서 어떻게 구현되어 작동하는지 낱낱이 파헤친다.

① 관찰(Observation) 단계에서 수행하는 일

관찰은 단순히 '데이터를 읽어오는 것'을 넘어선다. 에이전트에게 관찰이란 "에이전트가 동작하는 외부 세계(로컬 OS, 파일 시스템, 프로세스, 실행 결과 등)의 물리적 상태를 관찰하고, 이를 LLM이 이해할 수 있는 디지털 맥락(Context Window)으로 선별·변역하는 행위"다.

주요 수행 항목은 다음과 같다.

• 환경 분석: 운영체제(Linux/macOS/Windows), 실행 엔진 버전(Node.js, Python), 사용 가능한 도구 목록을 파악한다.
• 맥락 탐색: 프로젝트의 디렉토리 구조, 설정 파일(package.json, pyproject.toml), Git 상태 등을 확인하여 현재 프로젝트의 전반적인 성격을 진단한다.
• 행동 결과 확인: 이전 루프에서 실행한 도구(파일 쓰기, 터미널 명령 등)의 반환값, Exit Code, 표준 출력(Stdout)/표준 에러(Stderr)를 수집한다.
• 정보 필터링: 수십만 줄의 코드베이스와 방대한 로그 중에서 '현재 목표와 연관된 핵심 단서'만 추려낸다.

관찰의 주체: 관찰 엔진(Observation Engine)의 정체

여기서 관찰을 수행하는 관찰 엔진(Observation Engine)은 구체적으로 무엇이며 어떻게 작동하는 것일까? 이를 이해하기 위한 세 가지 핵심 질문과 답변은 다음과 같다.

1. 누가 관찰 엔진을 관리하는가?관찰 엔진의 제어 주체는 LLM이 아니라 에이전트의 호스트 프레임워크(Host Framework, 에이전트 루프와 파일 및 네트워크 I/O를 조율하는 상위 애플리케이션 레이어)다. 프레임워크가 파일 시스템을 뒤지고 터미널 실행 결과를 회수하는 시스템 명령을 내린다.
2. LLM은 관찰 엔진의 존재를 아는가?LLM은 관찰 엔진의 세부 구현이나 물리적인 작동 방식을 전혀 모른다. 알 필요도 없다. LLM은 그저 관찰 엔진이 정제하여 맥락 창(Context Window)에 밀어 넣어준 텍스트 정보만을 소비할 뿐이다. 정보의 수집과 필터링은 철저히 무대 뒤(컴퓨터의 파일 시스템 및 프로세스 영역)에서 이루어진다.
3. 관찰 엔진은 또 다른 LLM 모델인가?대부분의 성숙한 에이전트 시스템에서 관찰 엔진은 결정적인(Deterministic, 동일한 입력에 대해 항상 동일한 결과를 보장하는) 일반 소스코드(Regex, AST 파서, 파일 조작 로직 등)로 작성된다. 속도가 빠르고 비용이 들지 않으며 신뢰도가 높기 때문이다. 다만, 10,000줄이 넘어가는 터미널 빌드 로그처럼 정보량이 지나치게 방대할 때는, 핵심 에러 메시지만 추출하기 위해 가벼운 요약 전용 LLM 모델이나 정교한 휴리스틱 알고리즘을 혼합하여 사용하기도 한다.

즉, 관찰 엔진은 물리 세계(운영체제, 코드 파일, 실행 결과)의 날것 그대로의 데이터를 LLM이 쉽게 요리할 수 있는 정형화된 식재료(맥락)로 다듬어 주는 일차 가공 공장의 역할을 담당한다.

다이어그램 설명. 왼쪽의 실제 서버/개발 서버에 널려 있는 수많은 정보(기가바이트 급의 소스코드와 거대한 파일 시스템)를 그대로 LLM에 넘길 수 없다. 중간의 '관찰 필터'가 목표에 맞게 꼭 필요한 파일 조각과 에러 로그만을 요약·선별하여 우측의 LLM 맥락 창에 밀어 넣어준다.

② 왜 관찰을 해야 하는가?

기본적으로 LLM(대형 언어 모델)은 학습이 끝난 시점에 지식이 고정된 오프라인 모델이다. LLM은 현재 디렉토리에 어떤 파일이 있는지, 자신이 수정하려는 코드에 오타가 있는지 스스로 알 방법이 없다. 정보의 비대칭성이 발생하기 때문이다.

관찰 단계가 필요한 이유는 명확하다.

1. 환각(Hallucination) 방지: 실제 소스 코드를 직접 보지 않으면 LLM은 상상 속의 코드를 지어내어 답변한다.
2. 실시간 피드백 반영: 방금 터미널에서 수행한 명령이 성공했는지 실패했는지 여부를 알아야 다음 올바른 방향을 잡을 수 있다.
3. 동적 한계 극복: 사용자의 질문("이 프로젝트의 API 서버 실행해줘")에 대해 실제 사용된 언어(Python인지 Node인지 Go인지)와 라이브러리를 판단하여 상황에 맞는 전술을 구상할 수 있게 한다.

③ 앞단계 및 뒷단계와의 연결고리

에이전트 루프에서 관찰은 검증(Verification)에서 정보를 넘겨받아 계획(Planning)으로 전달하는 다리 역할을 한다.

이전 단계 (검증)	현재 단계 (관찰)	다음 단계 (계획)
테스트 도구 실행 후 실패 로그(Traceback) 발생	실패 로그 전체를 가공하고, 에러가 난 파일의 소스코드 라인을 추적·추출	수집된 파일 경로와 에러 위치를 바탕으로 코드 수정 계획 수립

• 이전 단계(검증)와 연결: 에이전트의 이전 행동이 끝난 후 검증 단계에서 컴파일러, 린터, 테스트 코드가 실행된다. 여기서 통과하지 못해 실패하면, 검증 결과(에러 스택 트레이스)가 관찰 단계의 주 입력값이 된다.
• 다음 단계(계획)와 연결: 관찰 단계에서 환경 상태와 에러 정보를 취합하여 "현재 상태 문서"를 빌드한 후 LLM에 프롬프트로 주입하면, LLM은 이를 기반으로 다음 단계를 위한 로드맵(계획)을 수립한다.

④ 실질적으로 어떻게 동작하는가? (사례 중심)

가장 흔히 겪는 에러인 ModuleNotFoundError: No module named 'requests' 상황을 예시로 들어보자.

1. 챗봇의 대처 (관찰 없음)

사용자가 에러를 복사해서 붙여넣으면 챗봇은 이렇게 답한다. "파이썬 환경에 requests 라이브러리가 없는 것 같습니다. pip install requests 명령어를 실행해 보세요." 그러나 이 조언은 로컬 환경이 가상환경(venv, poetry)을 쓰고 있는지 여부나 권한 설정을 알지 못해 실패할 확률이 높다.

2. 에이전트의 대처 (관찰 루프 작동)

에이전트는 사용자가 명시적으로 알려주지 않아도 관찰 도구들을 이용하여 시스템 정보를 스스로 확인한다.

// 1단계: 프로젝트 디렉토리 목록 조회 (관찰 도구 호출)
{
  "tool": "list_dir",
  "arguments": { "DirectoryPath": "/workspace" }
}

// [응답] ["main.py", "poetry.lock", "pyproject.toml", ".venv/"] 
// -> 에이전트는 프로젝트가 Poetry 가상환경과 poetry.lock을 사용 중임을 알아챈다.

// 2단계: pyproject.toml 파일 보기 (관찰 도구 호출)
{
  "tool": "view_file",
  "arguments": { "AbsolutePath": "/workspace/pyproject.toml", "StartLine": 1, "EndLine": 30 }
}

// [응답] 툴 스키마 내에 `[tool.poetry.dependencies]` 섹션이 포함된 내용 반환.

에이전트는 관찰 결과를 조합하여 맥락 창을 다음과 같이 구성한다.

[관찰된 컨텍스트]
- 에러 종류: ModuleNotFoundError (requests)
- 프로젝트 도구: Poetry 기반 가상환경 감지됨
- 파일 구성: poetry.lock 존재함, pyproject.toml에 requests가 없음

이 고도로 정제된 관찰 컨텍스트 덕분에, 에이전트는 다음 계획 단계에서 단순 pip install requests가 아니라 poetry add requests를 실행하겠다는 정확하고 오차 없는 계획을 수립할 수 있게 된다.

정리하며

관찰(Observation)은 현실 세계의 원시 데이터를 LLM이 추론할 수 있는 지식 맥락으로 번역해주는 에이전트의 '눈'이다. 좋은 에이전트 설계자는 모델의 매개변수가 아니라, 상황에 맞게 꼭 필요한 정보를 추려내는 관찰 필터와 맥락 관리 도구를 설계하는 데 가장 많은 공을 들인다. 눈이 밝아야 발걸음(계획)이 흐트러지지 않기 때문이다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.