agent는 모델에 state, tools, loop를 붙여서 사람 없이도 스스로 행동을 반복하게 만든 단계다. 앞 단계인 vibe coding까지는 loop를 사람이 돌았다. 만들고, 돌려보고, 고치는 일을 내가 했다. agent는 그 loop를 모델에게 넘긴다. 모델이 직접 tool을 쓰고, 결과를 보고, 다음 행동을 정한다.
“LLM 활용의 진화” 시리즈 ③편. ① Prompting · ② Vibe coding · ③ Agents · ④ Harness engineering · ⑤ Open models.
이 주제를 따로 정리한 이유는 단순하다. 나는 control engineering에서 출발했고, 거기서 제일 먼저 배우는 게 feedback loop다. 측정하고, 판단하고, 입력을 넣고, 다시 측정한다. agent의 구조를 보면 이 loop와 거의 같다. 다만 control loop와 달리 agent loop의 controller는 확률적으로 움직이는 LLM이고, 그 controller가 셸과 파일과 메일을 직접 만진다. 익숙한 구조에 낯선 위험이 얹힌 셈이라, 어디가 단단하고 어디서 깨지는지 한 번 적어두고 싶었다.
OpenClaw가 autonomous agent를 대중화했다
이 개념을 거의 하룻밤 사이에 대중의 언어로 만든 건 2026년 초의 OpenClaw였다. 오스트리아 개발자 Peter Steinberger가 만든 open-source autonomous agent로, Clawdbot → Moltbot → OpenClaw 순으로 이름이 바뀌었고(중간 개명은 Anthropic 상표 문제 때문이었다) GitHub star 14만 개를 넘겼다 [1]. Telegram·Slack 같은 messenger를 interface로 삼아 shell command, browser, 파일, 캘린더를 직접 실행한다. 문자 한 통으로 [2].
그림 1. 사람이 돌던 loop를 모델에게 넘긴 agent. tool을 쓰고 결과를 관찰하며 반복하되, 위험한 행동 앞에는 사람의 approval gate가 있다.
prompting·vibe coding과 갈리는 지점
앞 단계들의 한계는 셋이었다. state가 없고, tool이 없고, 검증이 없었다. agent는 이 셋을 정면으로 메운다.
- State: 지금까지 뭘 했는지에 대한 memory를 들고 다닌다.
- Tools: 코드 실행, 파일 읽기, 검색 같은 실제 행동을 한다.
- Loop: 한 번 답하고 끝내지 않고, 결과를 보고 다음 행동을 정하는 걸 반복한다.
세 단계를 나란히 놓으면 차이가 더 분명하다.
| 단계 | State (memory) | Tool 실행 | Loop |
|---|---|---|---|
| Prompting | 없음 | 없음 | 없음, 1회성 응답 |
| Vibe coding | session 안에서만 | 코드 생성까지 | 사람이 돌림 |
| Agents | 지속 유지 | 직접 실행 (shell, files, APIs) | 모델이 스스로 돌림 |
그래서 agent는 본질적으로 model + tools + loop + memory다. 모델은 두뇌의 한 부분일 뿐이고, agent를 agent로 만드는 건 그 주변의 loop다. 가장 단순한 형태는 이렇다.
# agent의 본질 = perceive -> plan -> act -> observe loop
state = memory.load()
while not done:
action = model.decide(state, tools) # plan: 다음 행동 결정
if action.is_risky: # 위험하면 사람에게
if not human_approve(action): # HITL gate
continue
result = run(action) # act: tool 실제 실행
state = memory.update(state, action, result) # observe: 결과를 state에 반영
done = model.is_complete(state)
prompt가 model.decide() 한 번 호출이었다면, agent는 그 호출을 while 안에 넣고 tool과 memory를 붙인 것이다. 코드로 보면 몇 줄 차이인데, 실제로 돌려보면 이 몇 줄이 시스템의 성격을 바꾼다. 한 번 답하는 모델은 틀려도 그 답 하나가 틀린 것으로 끝난다. loop를 도는 모델은 틀린 판단 위에 다음 행동을 쌓는다.
자율성의 대가: permission과 검증
OpenClaw가 화제이자 동시에 논란이었던 이유가 여기 있다. shell, email, 캘린더, messenger에 접근하려면 넓은 permission이 필요하고, 그 permission이 곧 위험이다. 잘못 설정되거나 외부에 노출된 agent는 바로 보안·privacy 사고로 이어진다. 보안 연구자들이 OpenClaw의 permission model을 우려한 것도 이 때문이다 [1].
문제의 뿌리는 자율성 그 자체다. loop를 모델에게 넘긴 순간, 잘못된 행동도 모델이 알아서 실행한다. 그래서 production agent에는 두 가지가 필요하다. 첫째, 위험한 행동(결제, 삭제, secret, 외부 게시) 앞에 두는 사람 approval gate (HITL). 둘째, 폭주를 막는 loop 상한과 검증. 위 코드에서 is_risky와 human_approve가 들어간 자리다.
뭐가 단단하고 어디서 깨지나
단단한 부분은 구조다. model + tools + loop + memory라는 분해는 어떤 framework를 쓰든 그대로 통한다. 새 agent framework가 나와도 결국 이 네 조각을 어떻게 나눠 담았는지만 보면 된다.
깨지는 지점은 위 코드에서 한 줄로 처리한 부분들이다.
is_risky판정: 코드에선 boolean 하나지만, 실제로는 어떤 행동이 위험한지 누군가 정해야 한다. 그 판정을 모델에게 맡기면 gate를 모델이 스스로 여닫는 구조가 된다.is_complete판정: 언제 멈출지를 모델이 정한다. 끝났다고 착각하고 멈추거나, 끝났는데 계속 돈다. loop 상한이 따로 필요한 이유다.memory.update: 틀린 관찰이 state에 들어가면 이후 판단이 전부 그 위에 선다. control에서 센서가 틀리면 controller가 아무리 좋아도 소용없는 것과 같다.
내가 agent를 굴린다면
여기부터는 내 기준이다. 내가 agent를 쓸 때는 금융 트랜잭션, 되돌릴 수 없는 삭제, secret 쓰기 앞에서는 반드시 사람이 멈추도록 정해둔다. 이 목록은 모델이 판단하게 두지 않고, 코드나 설정에 박아둔다. is_risky를 모델의 판단이 아니라 바깥 규칙으로 두는 셈이다.
permission은 필요한 만큼만 준다. shell, email, 캘린더처럼 민감한 접근은 범위를 최소로 잡고, agent가 하는 일이 넓어질 때마다 permission을 한 번에 다 열지 않고 하나씩 연다. loop에는 횟수나 비용 상한을 건다. lab에서 한 번 돌아가는 agent와 매일 돌아가는 agent의 차이는 대부분 이 지점에서 난다.
agent와 RPA 같은 자동화 script의 차이도 여기서 정리된다. script는 정해진 규칙대로만 움직이고 규칙이 바뀌면 다시 짜야 한다. agent는 같은 loop 안에서 다른 판단을 내린다. 그 유연함이 장점이고, 같은 이유로 guardrail이 script보다 더 필요하다.
정리
agent는 prompting과 vibe coding이 못 넘은 벽(state, tools, 검증)을 loop로 넘었다. 모델이 직접 tool을 쓰고 결과를 보며 반복한다. OpenClaw는 그 가능성을 대중에게 보여줬고, 동시에 자율성에는 guardrail이 따라와야 한다는 숙제를 남겼다.
그 숙제, 즉 agent를 안전하게 일정한 품질로 굴리는 일이 다음 편 주제다. 모델 주변에 tool, hook, guardrail, 검증을 설계하는 harness engineering이다.
