자율 에이전트인가, 통제된 하네스인가 — LLM을 부리는 두 가지 모델

요즘 LLM(Large Language Model, 대규모 언어 모델 — 사람의 글을 학습해 다음 단어를 예측하며 문장·코드를 생성하는 모델)을 어딘가에 끼워 넣으면 일단 "AI 에이전트"라고 부른다. 챗봇도 에이전트, 자동 코드 리뷰 봇도 에이전트, 야간에 도는 배치 작업도 에이전트다. 그런데 이 한 단어가 성격이 전혀 다른 두 가지 설계를 한데 묶어 버린다. 그리고 그 묶음이 실무에서 사고를 낳는다.

나는 집에 로컬 AI 서버를 한 대 두고 여러 자동화를 돌린다. 캘린더를 정리하고, 사진을 분석하고, 블로그 초안을 쓰고, GPU 자원을 나눠 쓰는 작업들이다. 이걸 만들면서 매번 부딪힌 질문이 하나 있었다. "이 작업은 LLM에게 얼마나 맡겨도 되는가?" 이 질문의 답이 곧 두 모델 중 무엇을 고를지를 결정한다.

배경 — "에이전트"라는 말이 너무 많은 걸 가린다

업계에서 "에이전트"는 보통 "LLM이 스스로 판단하고 도구를 호출하며 목표를 향해 반복하는 시스템"을 가리킨다. 하지만 실제로 그렇게 완전히 자율적인 시스템은 프로덕션에서 드물다. 대부분은 LLM의 판단을 코드가 빙 둘러싸고, 입력을 검사하고, 출력이 이상하면 막고, 실패하면 다시 시키는 구조다. 겉보기엔 같은 "에이전트"지만 통제권이 누구에게 있는지가 정반대다.

이 글에서는 둘을 이렇게 부른다. 하나는 하네스(harness) — 말(馬)에 씌우는 마구(馬具)에서 온 말로, LLM이 핵심 판단을 내리되 그 주변을 결정론적 가드가 둘러싸 "틀려도 안전하게" 만든 구조다. 여기서 결정론적(deterministic)이란 같은 입력에 항상 같은 출력을 내는, LLM처럼 매번 달라지지 않는 코드를 말한다. 다른 하나는 자율 에이전트(autonomous agent) — 목표만 주면 스스로 계획·실행·반복하는 구조다. 둘 다 LLM을 쓰지만 통제권의 위치가 다르다.

다이어그램 설명. 위 그림은 "LLM을 쓰는 시스템"이라는 한 입구가 통제권의 위치라는 단 하나의 질문으로 두 갈래로 갈린다는 걸 보여준다. 같은 LLM을 쓰더라도, 코드가 모델을 빙 둘러싸 판단을 검사·차단하면 하네스고, 모델이 직접 목표를 향해 다음 행동을 정하면 자율 에이전트다. 핵심은 "에이전트냐 아니냐"가 아니라 "통제권이 어디 있느냐"가 둘을 가른다는 점이다. 흔한 오해는 "도구를 호출하면 에이전트"라고 보는 것인데, 도구 호출 여부가 아니라 그 호출을 코드가 검문하는지가 갈림길이다.

문제 — 구분하지 않으면 통제 수준을 잘못 잡는다

두 모델을 구분하지 않으면 어떤 일이 생기는가. 두 가지 방향의 실수가 모두 일어난다.

첫째, 통제가 필요한 작업에 자율을 줘 버린다. 예를 들어 "오래된 로그 파일을 정리해줘"라는 작업을 자율 에이전트에게 목표만 던지면, LLM이 rm -rf 같은 되돌릴 수 없는 명령을 스스로 조합해 실행할 수 있다. 파일 삭제는 한 번 일어나면 끝이라 — 비가역적이라 — 사람 손이 닿지 않은 채 LLM이 판단하게 두면 사고가 한 방에 난다.

둘째, 반대로 자율이 빛날 작업을 과하게 묶는다. "이 코드베이스를 탐색하면서 버그를 찾아봐"처럼 어디서 무엇을 찾을지 미리 알 수 없는 작업은, 매 단계를 코드로 검문하려 들면 오히려 LLM의 유연한 탐색 능력을 죽인다. 읽기 전용이라 — 파일을 고치지 않으니 되돌릴 일이 없는 — 작업이라면 자율을 줘도 위험이 낮다.

다이어그램 설명. 위 그림은 두 모델을 구분하지 못할 때 양쪽 끝에서 벌어지는 두 가지 실수를 한눈에 보여준다. 왼쪽은 파일 삭제처럼 되돌릴 수 없는 작업에 자율을 줘 한 번의 잘못된 판단이 그대로 사고가 되는 경우고, 오른쪽은 버그 탐색처럼 자유로운 탐색이 필요한 작업을 단계마다 막아 유연성을 죽이는 경우다. 두 화살표가 한 결론으로 모이는 게 핵심이다 — 통제 수준은 작업의 성격에 맞춰야 한다는 것. 자주 하는 오해는 "통제는 무조건 많을수록 안전하다"는 생각인데, 과잉 통제는 안전이 아니라 능력의 낭비다.

방법 — 두 모델을 구조로 분리해서 본다

두 모델의 차이를 말로만 하면 또 흐려진다. 그림으로 구조를 분리해서 보자. 비교 대상이 둘이므로 한 블록에 나란히 두지 않고 따로 쌓는다.

▲ 하네스 — LLM 코어를 결정론적 가드가 감싼다

다이어그램 설명. 위 그림은 하네스의 내부 구조다. LLM의 판단은 한가운데 "핵심 판단" 자리에만 있고, 그 앞뒤를 코드로 짠 장치들이 둘러싼다. 들어오는 입력을 먼저 검사해 이상한 값을 막고, LLM이 쓸 수 있는 도구를 미리 정한 목록(화이트리스트)으로 제한하고, 결과가 나오면 종료 게이트에서 검사한 뒤 통과시키거나 실패면 다시 시킨다. 화이트리스트란 "이것만 허용" 목록으로, 막을 것을 일일이 적는 블랙리스트의 반대다 — 새로운 위험이 생겨도 목록에 없으면 자동으로 막히므로 더 안전하다. 핵심은 LLM이 틀려도 그 틀림이 바깥으로 새어 나가기 전에 코드가 잡는다는 점이다. 이 그림만 보고 "LLM이 작은 역할만 한다"고 오해하기 쉬운데, 판단의 질은 여전히 LLM이 결정한다 — 코드는 안전망일 뿐 판단을 대신하지 않는다.

▲ 자율 에이전트 — LLM이 계획·실행·관찰을 스스로 반복한다

다이어그램 설명. 위 그림은 자율 에이전트의 구조다. 사람은 맨 위에서 목표 하나만 주고, 그다음부터는 LLM이 계획을 세우고, 행동을 고르고, 결과를 보고, 목표에 닿을 때까지 그 고리를 스스로 돈다. 앞의 하네스 그림과 비교하면 차이가 분명하다 — 하네스에서는 코드로 짠 검사 장치가 LLM을 둘러쌌지만, 여기서는 계획부터 실행·판단까지 전부 LLM 안에서 돌고 사람의 코드가 끼어드는 자리가 없다. 그래서 유연하지만 통제가 약하다. 함정은 이 루프가 "스스로 멈춘다"는 보장이 약하다는 점이다 — 목표를 잘못 해석하면 같은 고리를 무한히 돌거나 엉뚱한 방향으로 끝까지 달릴 수 있다.

가드레일·모델 선택·테스트를 합치면 결국 하네스가 된다

그동안 LLM을 안전하게 쓰는 기법으로 여러 가지가 따로 이야기돼 왔다. 입력·출력을 검사하는 가드레일(guardrail — LLM의 입출력을 검사해 위험하거나 형식이 틀린 것을 걸러내는 장치), 작업 난이도에 맞춰 빠른 모델과 똑똑한 모델을 골라 쓰는 모델 선택, 그리고 결과가 기대대로인지 확인하는 테스트다. 이 셋은 흩어진 팁처럼 보이지만, 한자리에 모으면 정확히 앞에서 본 하네스의 구성요소가 된다.

다이어그램 설명. 위 그림은 따로 논의되던 세 기법이 하나로 합쳐져 하네스를 이룬다는 걸 보여준다. 입출력을 검사하는 가드레일은 하네스의 입력 검증·종료 게이트가 되고, 작업 난이도에 맞춰 모델을 고르는 일은 어디까지 LLM에 맡길지를 정하는 결정이며, 결과를 확인하는 테스트는 종료 게이트의 판단 근거가 된다. 세 화살표가 한 상자로 모이는 게 핵심 메시지다 — "LLM을 안전하게 쓴다"는 노력은 결국 하네스를 짓는 일이라는 것. 흔한 오해는 이 셋을 각각 독립한 별개의 기능으로 보는 것인데, 같은 목표(틀려도 안전하게)를 향한 한 구조의 부품들이다.

그래서 무엇을 고르나 — 비가역성과 반복성으로 판단

두 모델을 구분했으니 이제 실제 선택 기준이 필요하다. 나는 두 축으로 본다. 비가역성(되돌릴 수 있는 작업인가)과 반복성(매번 같은 패턴으로 도는 정형 작업인가, 매번 다른 탐색이 필요한가)이다.

다이어그램 설명. 위 그림은 작업 하나를 놓고 무엇을 쓸지 정하는 결정 트리다. 맨 먼저 되돌릴 수 없는 행동 — 파일 삭제, 결제, 외부 발행처럼 한 번 일어나면 끝인 일 — 이 들어 있는지 묻고, 그렇다면 곧장 하네스로 간다. 되돌릴 수 있는 작업이라면 다음으로 그게 매번 같은 패턴으로 도는 정형 작업인지 묻고, 정형이면 검증을 코드로 고정한 하네스가, 매번 다른 탐색이 필요한 열린 작업이면 자율 에이전트가 빛난다. 읽는 순서는 위에서 아래로 한 번씩이다 — 두 질문을 차례로 통과하며 좁혀 간다. 이 트리의 핵심은 "비가역 행동이 하나라도 있으면 자율은 포기한다"는 점이다. 빠지기 쉬운 함정은 "대부분 안전한데 가끔만 위험한" 작업을 자율로 두는 것인데, 그 "가끔"이 정확히 사고가 나는 지점이다. 안전한 부분과 위험한 부분을 분리해, 위험한 행동만 게이트로 감싸는 게 정석이다.

내 로컬 서버의 예로 풀면 이렇다. 사진을 보고 설명을 다는 작업은 결과가 틀려도 description 한 줄을 다시 쓰면 그만이라 자율에 가깝게 둘 수 있다. 반대로 블로그 글을 외부에 발행하는 작업은 한 번 공개되면 되돌리기가 번거로워, 발행 직전에 사람이 검토하고 형식·금칙어를 코드로 검사하는 게이트를 반드시 통과시킨다 — 전형적인 하네스다. 두 작업 모두 LLM을 쓰지만 통제 수준은 정반대다.

효과와 트레이드오프

두 모델을 의도적으로 골라 쓰면 얻는 건 안전과 능력의 균형이다. 통제가 필요한 곳엔 하네스를 씌워 사고를 막고, 자율이 빛나는 곳엔 풀어 줘 LLM의 유연함을 살린다. 막연히 "에이전트를 만든다"가 아니라, 이 작업에 통제권을 누가 쥘지를 의식적으로 정하는 것이다.

물론 공짜는 아니다. 하네스는 설계·유지 비용이 크다. 입력 검증, 도구 목록, 종료 게이트, 재시도 로직을 다 짜고 유지해야 하므로 코드가 늘고 손이 많이 간다. 반대로 자율 에이전트는 사고 위험이 크다. 통제 장치가 없으니 적게 짜도 되지만, 한 번 잘못 판단하면 막을 방법이 없다.

그래서 실제 프로덕션 시스템은 대부분 하네스 쪽으로 기운다. 되돌릴 수 없는 행동, 외부에 노출되는 결과, 돈이 걸린 작업이 하나라도 끼면 자율의 매력보다 사고 비용이 훨씬 크기 때문이다. 자율 에이전트는 읽기 전용 탐색이나 사람이 곁에서 지켜보는 실험 환경에서 빛난다. "AI 에이전트를 만들었다"고 말하기 전에, 그게 통제된 하네스인지 자율 에이전트인지부터 스스로에게 묻는 것 — 그 한 가지 구분이 시스템의 안전과 능력을 동시에 챙기는 첫걸음이다.

---

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