[생성AI] LLM에서 Loop까지 — AI 엔지니어링은 왜 이렇게 진화했는가

들어가며
LLM — 모든 것의 출발점
Prompt Engineering — 어떻게 말할 것인가
Context Engineering — 무엇을 보여줄 것인가
Harness Engineering — 어떤 제약 안에서 일하게 할 것인가
Loop Engineering — 누가 프롬프트를 입력할 것인가
진화의 큰 그림
정리

들어가며

몇 년 사이 AI를 다루는 방식을 부르는 이름이 꽤 여러 번 바뀌었습니다. “프롬프트를 잘 써야 한다”는 이야기가 한창이더니, 어느새 “컨텍스트가 중요하다”는 말이 나오고, 요즘은 “하네스(harness)“나 “루프(loop)” 같은 단어까지 등장합니다.

이 단어들은 유행 따라 그냥 갈아 끼워진 게 아닙니다. 각각은 바로 앞 단계가 부딪힌 한계를 넘기 위해 등장했습니다. 프롬프트만으로는 안 되는 지점이 있어서 컨텍스트가 나왔고, 컨텍스트만으로도 막히는 벽이 있어서 하네스가 나왔습니다. 즉 이름이 바뀔 때마다 그 뒤에는 “이전 방식으로는 풀 수 없던 문제”가 하나씩 숨어 있습니다.

이 글은 LLM → Prompt → Context → Harness → Loop라는 흐름을, “각 단계가 무엇이고, 왜 등장했으며, 어떤 문제 때문에 다음 단계로 넘어갔는가”라는 관점에서 따라가 봅니다. 정적인 분류보다는 진화의 이야기로 읽어 주시면 좋겠습니다.

이 글이 진화의 “흐름”에 초점을 맞춘다면, 각 개념을 겹겹이 쌓인 레이어로 나란히 비교한 AI 엔지니어링 4가지 패러다임 글은 정적인 “구조”에 초점을 맞춥니다. 함께 보시면 좋습니다.

LLM — 모든 것의 출발점

이야기의 출발점은 대형 언어 모델(LLM) 그 자체입니다.

LLM은 근본적으로 “지금까지의 텍스트 다음에 올 가장 그럴듯한 토큰”을 예측하는 모델입니다. 방대한 텍스트로 학습된 이 예측기는 번역, 요약, 코드 생성처럼 이전에는 각각 별도의 시스템이 필요했던 작업을, 하나의 모델로 자연어 지시만으로 해낼 수 있게 만들었습니다.

여기서 초기의 핵심 질문이 생깁니다.

“이 강력한 예측기에게 어떻게 명령을 내려야 내가 원하는 결과가 나올까?”

오픈소스 소형 모델은 데이터를 추가로 학습시키는 파인튜닝(fine-tuning)으로, 대형 상용 모델은 API 호출과 함께 필요한 지식을 넣어 주는 방식으로 각자 답을 찾아갔습니다. 하지만 대부분의 실무자에게 모델 자체를 손대는 일은 현실적이지 않았습니다. 우리가 건드릴 수 있는 건 결국 모델에게 건네는 입력 텍스트뿐이었죠.

바로 이 지점에서 첫 번째 엔지니어링이 등장합니다.

Prompt Engineering — 어떻게 말할 것인가

Prompt Engineering은 모델에게 건네는 지시문(prompt)을 어떻게 쓸 것인가에 대한 기술입니다. 모델의 가중치는 고정되어 있으니, 우리가 조절할 수 있는 유일한 손잡이인 “입력 텍스트”를 최대한 잘 다듬자는 발상입니다.

같은 질문이라도 묻는 방식에 따라 답이 크게 달라진다는 건 누구나 경험해 보셨을 겁니다. “코드 리뷰 해줘”보다 “시니어 백엔드 개발자 관점에서 보안 이슈를 중심으로 리뷰해줘”라고 하면 훨씬 구체적인 답이 돌아옵니다. 이런 경험이 쌓이면서 몇 가지 정형화된 기법이 자리를 잡았습니다.

Few-shot: 원하는 결과의 예시를 몇 개 보여주어 패턴을 학습시킵니다.
Chain-of-Thought: “단계별로 생각해보라”고 요청해 추론 과정을 유도합니다.
Role Prompting: “당신은 10년 차 백엔드 개발자입니다”처럼 역할을 부여합니다.
출력 형식 지정: “JSON으로 응답하라”처럼 결과 형태를 미리 못 박습니다.

예를 들어 답변의 범위를 좁히고 싶다면, 아래처럼 “무엇을 다루고 무엇을 다루지 말지”를 명시하는 식입니다.

요구사항의 What과 Why만 분석하세요.
How(기술적 구현)는 논의하지 마세요.

그런데 — 프롬프트는 결국 “부탁”이다

프롬프트 엔지니어링에는 근본적인 약점이 있습니다. 아무리 정성껏 써도 그것은 강제가 아니라 부탁이라는 점입니다.

"IMPORTANT: 절대 이렇게 하지 마세요"라고 대문자로 강조해도 모델이 그 지시를 반드시 따른다는 보장은 없습니다. 단어 하나, 문장 순서 하나만 바뀌어도 결과가 달라질 만큼 취약하기도 합니다. 그리고 결정적으로, 프롬프트를 아무리 잘 써도 모델이 실제 파일을 열어보거나, 최신 API 응답을 확인하거나, 프로젝트의 현재 상태를 알게 할 수는 없습니다.

“말을 잘 거는 것”과 “필요한 정보를 쥐여주는 것”은 다른 차원의 문제였습니다. 이 한계가 다음 단계를 불러옵니다.

Context Engineering — 무엇을 보여줄 것인가

관심의 초점이 “어떻게 말할까”에서 “무엇을 함께 보여줄까”로 옮겨 갑니다. 이것이 Context Engineering입니다.

비유하자면 프롬프트가 “이 문제를 풀어줘”라는 질문이라면, 컨텍스트는 시험지 옆에 펼쳐 두는 참고 자료입니다. 같은 문제라도 관련 교과서를 펼쳐 놓고 푸는 것과 맨몸으로 푸는 것은 결과가 다릅니다. 프로젝트 배경, 관련 코드, 파일 구조, 지금까지의 작업 내역 — 모델이 좋은 판단을 내리는 데 필요한 재료를 골라서 넣어 주는 일이 컨텍스트 엔지니어링입니다.

이 시기에 모델은 단순한 질문-응답기를 넘어 도구를 쓰고(tool calling), 기억을 갖고(memory), 스스로 다음 행동을 정하는(ReAct) 에이전트(agent)로 진화하기 시작했습니다. 에이전트가 좋은 결정을 내리려면 좋은 컨텍스트가 필수였기에, 컨텍스트 엔지니어링은 자연스럽게 에이전트 시대의 핵심 기술이 되었습니다.

핵심은 “필요한 것만 골라 넣기”

컨텍스트 윈도우는 무한하지 않습니다. 너무 많이 넣으면 정작 중요한 정보가 묻히고 비용도 오릅니다. 그래서 API 응답을 통째로 넣는 대신 필요한 필드만 추출하고, 거대한 지시문 파일 하나 대신 상황에 맞는 모듈만 로드하는 식의 설계가 중요해졌습니다.

# 응답 전체를 넣으면 불필요한 데이터까지 다 들어간다
curl -s https://api.example.com/comments | jq '.[].body'

# 필요한 것만 골라 넣으면 훨씬 효율적이다
curl -s https://api.example.com/comments \
  | jq '.[] | select(.tag == "review") | .body'

그런데 — 정보를 잘 줘도 무너지는 지점이 있다

컨텍스트를 아무리 잘 설계해도, 작업이 길고 복잡해지면 성공률이 급격히 떨어지는 현상이 관찰됩니다. 대표적인 문제가 이런 것들입니다.

Context Rot: 대화가 길어져 컨텍스트 윈도우를 넘어서면 앞부분 내용을 잊어버립니다.
세션 단절: 세션이 바뀌면 기억이 사라지고, 이전 작업과 충돌하거나 흐름이 끊깁니다.
규칙의 취약성: 컨텍스트에 규칙을 적어 둬도, 그것 역시 결국 “프롬프트”라서 일관되게 지켜지지 않습니다.

결국 컨텍스트 엔지니어링은 모델의 판단 재료를 최적화할 뿐, 그 판단이 항상 지켜지도록 강제하거나, 판단 이후의 실행을 안전하게 감싸 주지는 못했습니다. 좋은 재료를 줬다고 해서 요리가 항상 성공하는 건 아니었던 셈입니다.

Harness Engineering — 어떤 제약 안에서 일하게 할 것인가

여기서 등장하는 것이 Harness Engineering입니다. Harness는 원래 말의 힘을 안전하게 제어하는 마구(馬具)를 뜻합니다. 즉 모델을 감싸서 올바른 방향으로 제어하는 구조를 만들자는 것이죠. 이 관점을 흔히 이렇게 요약합니다.

Agent = Model + Harness

모델의 성능만큼이나, 그 모델을 감싼 하네스의 설계가 에이전트의 실제 성능을 좌우한다는 뜻입니다. 이 용어는 2025년 말 Anthropic이 “effective harness”를 언급하면서 부각되었고, 2026년 초 Mitchell Hashimoto가 자신의 AI 도입기에서 이를 다루며 널리 퍼졌습니다.

Hashimoto는 하네스 엔지니어링을 이렇게 정의합니다.

“에이전트가 실수를 할 때마다, 그 실수를 다시는 하지 않도록 해결책을 엔지니어링하는 것.”

핵심은 부탁에서 강제로 넘어간다는 데 있습니다. 컨텍스트 엔지니어링까지가 “이렇게 해줬으면 좋겠다”였다면, 하네스는 “이 범위를 벗어나는 건 애초에 불가능하게 만든다”에 가깝습니다. 구체적으로는 대략 이런 방법들이 있습니다.

최소 권한 원칙 — 필요한 능력만 주고 범위를 좁힙니다. 읽기는 허용하되 삭제나 관리자 명령은 막는 식입니다. 실수하더라도 피해 범위가 애초에 제한됩니다.

{
  "permissions": {
    "allow": ["Bash(ls:*)", "Bash(cat:*)", "Read(/src/**)"],
    "deny": ["Bash(rm:*)", "Bash(sudo:*)"]
  }
}

자동 검증(Hooks) — 프롬프트로 “테스트를 돌려 달라”고 부탁하는 대신, 커밋 시점에 린트나 테스트를 구조적으로 강제합니다. 통과하지 못하면 다음 단계로 나아가지 못합니다.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git commit:*)",
        "hooks": [{ "type": "command", "command": "npm run lint" }]
      }
    ]
  }
}

검증 도구 제공 — Hashimoto가 강조한 부분인데, 에이전트에게 스스로 결과를 확인할 수 있는 수단을 쥐여 주는 것입니다. 자기 작업을 검증할 방법이 있으면 에이전트는 대개 스스로 실수를 고치고 회귀(regression)를 막습니다. 이 지점에서 이미 피드백 루프의 씨앗이 보입니다.

CLAUDE.md / AGENTS.md 같은 기준 문서로 세션 간 상태를 외부에 명시적으로 기록하는 것, 위험한 작업 전에 승인 단계를 두는 것도 모두 하네스에 속합니다.

그런데 — 안전한 방을 만들어도, 문은 사람이 연다

하네스는 에이전트가 일하는 “방”을 튼튼하게 만들어 줍니다. 하지만 그 방에서 일을 시작시키는 것은 여전히 사람입니다. 사람이 프롬프트를 입력해야 에이전트가 한 사이클을 돌고, 결과를 확인한 사람이 다시 다음 프롬프트를 입력합니다.

작업이 반복적이고 길어질수록, 이 “사람이 매번 프롬프트를 입력하는” 병목이 눈에 들어옵니다. 안전한 방과 유능한 일꾼은 준비됐는데, 정작 일을 계속 굴러가게 하는 동력이 사람의 타이핑에 묶여 있는 것이죠. 이 마지막 병목을 겨냥한 것이 Loop Engineering입니다.

Loop Engineering — 누가 프롬프트를 입력할 것인가

Loop Engineering은 발상을 한 번 더 뒤집습니다.

“프롬프트를 잘 입력하는” 대신, 프롬프트를 대신 입력해 주는 메커니즘을 설계한다.

핵심은 사람과 에이전트 사이의 반복을 자동화하는 것입니다. 에이전트가 스스로 현재 상태를 관찰하고 → 다음 행동을 정하고 → 실행하고 → 결과를 평가하고 → 계속할지 멈출지를 판단하는, 이 사이클을 사람 개입 없이 돌게 만드는 것이죠. 사람의 역할은 매 스텝을 지시하는 것에서, 무엇을 달성해야 하는지(루프의 설계)로 옮겨 갑니다.

하네스 엔지니어링에서 등장한 “자기 검증 → 자기 수정” 피드백 루프를, 아예 시스템의 중심축으로 끌어올린 것이라고 볼 수 있습니다. 실제 운영 단계의 루프는 대략 이런 요소들로 구성됩니다.

트리거(Automation): 스케줄이나 이벤트로 루프가 스스로 시작됩니다.
워크트리(Worktree): 여러 작업이 충돌하지 않도록 격리된 공간에서 병렬로 돕니다.
스킬/플러그인: 에이전트가 참조하는 절차서와 외부 도구 연결.
서브 에이전트: 만드는 에이전트와 검증하는 에이전트처럼 역할을 나눕니다.
상태/메모리: 재시작을 넘어 작업 상태를 지속적으로 추적합니다.

그런데 — 이건 아직 완성된 방법론이 아니다

Loop Engineering은 현재진행형 개념입니다. “실재하지만 아직 완결된 방법론은 아니다”라는 표현이 정확합니다. 사람이 루프에서 빠질수록 토큰 비용이 커지고, “결과가 정말 맞는지”를 검증할 책임은 오히려 무거워집니다. 무엇보다 사람이 직접 쓰지 않은 코드가 쌓여 가는 이해 부채(comprehension debt)라는 새로운 숙제가 생깁니다.

즉 사람이 불필요해진 게 아니라, 역할이 매 스텝의 실행자에서 루프 전체의 설계자·감독자로 옮겨 갔을 뿐입니다. 그리고 지금까지의 패턴이 반복된다면, 다음 단계가 무엇이 될지는 아마 이 새로운 문제들 — 비용과 이해 부채 — 이 어디서 벽에 부딪히느냐가 결정할 것입니다.

진화의 큰 그림

지금까지의 흐름을 한 장에 모으면 이렇게 됩니다.

단계	핵심 질문	조절 대상	등장을 부른 한계
LLM	어떻게 명령할까	모델 자체	모델은 고정, 입력만 조절 가능
Prompt	어떻게 말할까	지시문	부탁일 뿐, 정보·강제력이 없음
Context	무엇을 보여줄까	정보	판단은 최적화해도 실행·강제는 못함
Harness	어떤 제약에서 시킬까	환경·권한	방은 안전해도 시작은 사람 몫
Loop	누가 프롬프트를 넣을까	반복 그 자체	비용·이해 부채 (진행 중)

관통하는 두 개의 축이 보입니다.

첫째, “부탁”에서 “강제”로. 프롬프트는 잘 지켜지길 바라는 부탁이었지만, 하네스는 벗어날 수 없는 제약이 되었습니다.

둘째, “사람이 매번 개입”에서 “사람은 설계만”으로. 프롬프트 시대에는 사람이 한마디 한마디 입력했지만, 루프 시대에는 사람이 시스템을 설계해 두고 한발 물러섭니다.

한 가지 오해하지 말아야 할 점은, 뒷 단계가 앞 단계를 폐기하지 않는다는 것입니다. 루프 안에서도 여전히 좋은 프롬프트가 필요하고, 좋은 컨텍스트가 필요하며, 튼튼한 하네스가 필요합니다. 뒤에 등장한 엔지니어링은 앞선 것을 감싸며 증폭시키는 관계에 가깝습니다. 이 “겹겹이 쌓인 레이어” 구조는 AI 엔지니어링 4가지 패러다임 글에서 더 자세히 다룹니다.

정리

AI를 다루는 방식을 부르는 이름들은 유행 따라 바뀐 게 아니라, 앞 단계의 한계가 다음 단계를 낳는 방식으로 이어져 왔습니다.

LLM: 고정된 예측기. 우리가 만질 수 있는 건 입력뿐이다.
Prompt: 입력을 다듬는다. 하지만 부탁일 뿐이다.
Context: 정보를 함께 준다. 하지만 강제하진 못한다.
Harness: 제약으로 강제한다. 하지만 시작은 사람 몫이다.
Loop: 반복까지 자동화한다. 대신 새로운 부채를 남긴다.

지금 우리는 Harness가 자리를 잡고 Loop가 막 논의되기 시작한 지점에 서 있습니다. 이 글이 나온 이후에 또 어떤 이름이 등장할지는 모르지만, 아마 그것도 Loop가 부딪힌 한계를 넘기 위한 무언가일 것입니다. 새 용어를 만날 때마다 “이건 앞 단계의 어떤 문제를 풀려는 걸까?”를 물어보면, 유행어의 홍수 속에서도 흐름을 놓치지 않을 수 있으리라 생각합니다.