LLM 루프 밖에서 무슨 일이 일어나는지 이해하려고 코딩 에이전트를 직접 만들어봤습니다
I built a coding agent to understand what happens outside the LLM loop
핵심 요약
코딩 에이전트 개발 시 LLM 루프보다 샌드박싱, 도구 설계 등 실제 시스템 구현이 훨씬 어렵다는 점을 다룬 글입니다.
- 에이전트 구현 — LLM 루프보다 도구 설계, 샌드박싱, 세션 유지 등이 핵심임
- 도구 활용 — Bash와 파일 시스템 접근만으로는 부족한 이유를 설명함
- 보안 및 격리 — 승인 정책과 OS 샌드박싱이 해결하는 문제의 차이를 다룸
- 메모리 관리 — 에이전트 메모리의 세 가지 의미와 컨텍스트 윈도우 문제를 분석함
예전에는 코딩 에이전트가 그저 루프 안에서 도구를 호출하는 LLM인 줄 알았습니다.
직접 만들어보기 전까지는요.
루프는 쉬운 부분이었습니다. 진짜 어려운 건 도구 설계, 승인 정책, 샌드박싱, 컨텍스트 압축, 세션 유지, 그리고 모델이 다음에 어떤 정보를 봐야 할지 결정하는 것이었습니다.
이 블로그에서는 다음 내용을 다룹니다:
-
도구 호출이 어떻게 실제 동작으로 이어지는지
-
Bash와 파일 시스템 접근만으로는 왜 기술적으로는 충분해도 이상적이지 않은지
-
승인 정책과 OS 샌드박싱이 왜 서로 다른 문제를 해결하는지
-
에이전트 메모리의 세 가지 의미
-
도구 결과가 왜 결국 컨텍스트 윈도우를 다 잡아먹는지
-
같은 모델이라도 왜 하네스(harness)에 따라 다르게 동작하는지
(링크는 고정 댓글에 있습니다)


