[AI] Prompt에서 Loop까지: LLM 애플리케이션 엔지니어링의 변화

개요

LLM 기반 서비스가 대중화되었을 때 많은 사람들은 큰 충격을 받았다. 글쓰기, 요약, 번역, 코드 작성처럼 이전에는 사람이 직접 해야 했던 작업을 자연어 질문 하나로 수행할 수 있었기 때문이다.

초기의 관심은 자연스럽게 “어떻게 질문해야 더 좋은 답변을 얻을 수 있을까?”에 집중되었다. 같은 모델을 사용하더라도 역할을 어떻게 부여하는지, 출력 형식을 어떻게 지정하는지, 어떤 예시를 제공하는지에 따라 결과물이 크게 달라졌다. 이 시기의 핵심은 Prompt Engineering이었다.

하지만 실제 LLM 애플리케이션을 만들다 보면 프롬프트만으로는 부족하다는 사실을 금방 깨닫게 된다. LLM은 기본적으로 현재 입력에 포함된 정보만 바탕으로 답변한다. 따라서 과거 대화, 조직의 업무 규칙, 프로젝트의 코드 컨벤션, 최신 문서처럼 입력에 포함되지 않은 맥락은 알 수 없다. 그래서 모델이 판단에 활용할 수 있는 배경 지식과 상황 정보를 함께 제공하는 Context Engineering이 중요해졌다.

Context를 제공한다고 모든 문제가 해결되는 것도 아니다. LLM은 주어진 규칙을 항상 정확히 따르지 않을 수 있고, 응답 형식이 흔들릴 수 있으며, 특히 도구 호출 권한이 있는 에이전트 구조에서는 위험한 작업을 제안하거나 실제로 수행하려 할 수도 있다.

이 때문에 입력 검증, 출력 파싱, 스키마 검증, 권한 제어, 재시도, 가드레일, 로깅 같은 장치로 모델 호출을 감싸는 Harness가 필요해졌다. 그리고 복잡한 작업에서는 한 번의 호출만으로 목표에 도달하기 어렵다. 기존에는 사람이 프롬프트를 입력하고, 결과를 확인하고, 오류가 있으면 다시 수정 지시를 내리는 과정을 반복했다.

Loop는 이 반복 과정을 시스템 안으로 가져와, LLM이 정해진 규칙과 도구의 범위 안에서 계획하고, 행동하고, 관찰하고, 수정하며 목표에 도달하도록 만드는 구조다.

이 글에서는 LLM 애플리케이션 엔지니어링이 Prompt에서 시작해 Context, Harness, Loop로 확장되는 흐름을 정리해보려 한다.

1. Prompt Engineering

모델에게 무엇을 요청할 것인가

Prompt Engineering은 LLM에게 어떤 작업을 어떤 방식으로 수행해야 하는지 알려주는 설계 과정이다.

LLM은 같은 질문을 받아도 질문 내용에 따라 전혀 다른 답변을 준다.

예를 들어 “이 코드 리뷰해줘”라고만 하면 모델은 어떤 기준(보안, 성능, 유지보수)으로 리뷰해야 하는지 명확하지 않기 때문에 그때 그때 LLM이 중요하다 판단하는 기준에 따라 결과물이 달라진다.

그래서 조금이나마 동일한 결과물을 받기 위해 Prompt에는 보통 다음과 같은 요소를 포함한다.

- 모델이 맡을 역할
- 수행해야 할 작업
- 지켜야 할 제약 조건
- 원하는 출력 형식
- 참고할 예시

예를 들어 다음과 같이 요청할 수 있다.

너는 숙련된 백엔드 엔지니어야. 아래 코드 변경사항을 보안, 성능, 유지보수 관점에서 리뷰해줘. 결과는 Markdown 표 형식으로 정리해줘.

이처럼 Prompt Engineering의 목적은 모델이 사용자의 의도를 더 정확히 이해하도록 돕는 것이다.

다만 Prompt만으로 모든 문제가 해결되지는 않는다. 모델의 행동을 유도할 수는 있지만, 모델에게 없는 정보는 제공하지 못하기 때문이다.

2. Context Engineering

모델에게 무엇을 알려줄 것인가

Context Engineering은 LLM이 판단에 사용할 배경 정보와 상황 정보를 구성하는 과정이다.

프롬프트를 아무리 잘 작성해도, 모델에게 필요한 정보가 없다면 좋은 답변을 기대하기 어렵다.

예를 들어 모델에게 “이 코드를 리뷰해줘”라고 요청했을 때, 변경된 코드만 전달하면 모델은 프로젝트의 전체 구조나 코딩 컨벤션, 기존 장애 이력, 테스트 실패 로그를 알 수 없다.

그래서 Context Engineering에서는 모델이 판단하는 데 필요한 정보를 함께 제공한다.

다음과 같은 정보들이 Context가 될 수 있다.

- 과거 대화 내용
- 사용자 상태
- 업무 규칙
- 참고 문서
- 검색 결과
- 코드 파일
- 테스트 로그
- API 응답
- 도구 실행 결과

코드 리뷰를 예로 들면 단순히 변경된 코드만 전달하는 것이 아니라, 관련 파일, 프로젝트 컨벤션, 실패한 테스트 로그까지 함께 제공하는 것이다.

사용자 요청: 이 코드 리뷰해줘.

함께 제공되는 Context:
	- 변경된 diff
	- 관련 프로젝트 코드
	- 프로젝트 코딩 컨벤션
	- 테스트 실패 로그
	- 보안 체크리스트

그렇다고 관련 없는 정보까지 모두 LLM에게 던지면 안된다.

관련 없는 정보가 많으면 모델이 오히려 잘못된 판단을 할 수 있고, 비용과 응답 시간도 늘어난다. 따라서 어떤 정보를 포함하고 어떤 정보를 제외할지 설계하는 것이 중요하다.

Context Engineering의 핵심은 정보를 많이 넣는 것이 아니다. 작업에 필요한 정보를 선별해 모델이 판단 가능한 형태로 구성하는 것이다.

3. Harness Engineering

모델을 어떻게 안전하게 다룰 것인가

Harness Engineering은 LLM 호출을 안전하고 안정적으로 제어하기 위한 실행 구조를 설계하는 과정이다.

LLM은 유용하지만 항상 안정적으로 동작하지는 않는다. 원하는 형식으로 답변하지 않을 수도 있고, 주어진 규칙을 무시할 수도 있으며, 그럴듯하지만 틀린 결과를 만들 수도 있다.

예를 들어 모델에게 JSON 형식으로 답변하라고 요청해도 실제로는 깨진 JSON이 나올 수 있다. 또는 반드시 포함해야 하는 필드가 빠지거나, 허용되지 않은 값이 들어갈 수도 있다.

이 문제를 단순히 “JSON으로 정확히 답해줘”라는 프롬프트만으로 해결하기는 어렵다. 모델의 출력을 시스템이 검증하고 제어하는 구조가 필요하다.

Harness에는 보통 다음과 같은 요소가 포함된다.

- 입력 검증
- 프롬프트 템플릿
- 출력 파싱
- 스키마 검증
- 재시도
- fallback 처리
- 권한 제어
- 가드레일
- 로깅

예를 들어 JSON 응답을 받아야 하는 경우에는 다음과 같은 흐름으로 제어를 할 수 있다.

LLM 호출
→ 응답 수신
→ JSON 파싱
→ 스키마 검증
→ 실패 시 재시도
→ 계속 실패하면 fallback 처리

Harness Engineering의 핵심은 LLM을 완전히 믿는 것이 아니다.

오히려 LLM이 실패할 수 있다는 전제에서 모델의 불확실성을 소프트웨어 시스템으로 감싸 실패를 감지하고 안전하게 사용할수 있도록 제어하는 과정이다.

4. Loop Engineering

모델이 어떻게 끝까지 수행하게 할 것인가

Loop Engineering은 LLM이 한 번 답변하고 끝나는 것이 아니라, 행동과 관찰을 반복하며 목표에 도달하도록 만드는 구조를 설계하는 과정이다.

단순한 질문에는 한 번의 응답이면 충분할 수 있다. 하지만 LLM이 실무에 투입된 이후 진행하고자 하는 업무가 한 번의 LLM 호출로 끝나지 않는 경우가 많다.

예를 들어 코드 수정 작업을 생각해보자.

모델이 코드를 수정했다고 해서 작업이 끝나는 것은 아니다. 수정한 코드가 실제로 동작하는지 테스트해야 하고, 테스트가 실패하면 로그를 분석해서 다시 수정해야 한다. 기존대로 라면 이래의 과정을 사람이 수동적으로 반복하여 업무를 진행한다.

프롬프트 입력
→ 결과 확인
→ 테스트 실행
→ 오류 확인
→ 다시 수정 요청

Loop Engineering은 사람이 진행하던 반복 과정을 시스템 안으로 가져온다.

목표 이해
→ 계획 수립
→ 행동 실행
→ 결과 관찰
→ 실패 원인 분석
→ 다시 행동
→ 완료 판단

아까의 코딩 수정 작업을 다시 예시로 들어보자. Loop Engineering을 적용한다면 LLM은 다음과 같은 루프를 돌 것 이다.

관련 파일 검색
→ 코드 수정
→ 테스트 실행
→ 실패 로그 분석
→ 코드 재수정
→ 테스트 통과
→ 결과 요약

여기서 중요한 점은 AI 에이전트가 작업을 무한정으로 반복한다고 해서 더 좋은 결과가 나오는 것은 아니라는 점이다. 명확한 종료 조건 없이 반복되는 Loop는 지능적인 개선이라기보다 통제 실패에 가깝다.

오히려 어느 시점부터는 품질이 정체되거나, 비용만 늘거나, 잘못된 방향으로 더 멀리 갈 수 있기 때문에

Loop에는 반드시 제어 조건이 필요하다.

예를 들면:

- 최대 반복 횟수
- 사용할 수 있는 도구의 범위
- 성공 조건
- 실패 조건
- 사람의 승인이 필요한 작업
- 비용 제한
- 중단 기준

Loop Engineering의 핵심은 LLM이 반복적으로 작업할 수 있게 하되, 그 반복이 통제 가능한 범위 안에서 이루어지도록 설계하는 것이다.

즉, LLM을 단순한 답변 생성기에서 작업 수행자로 확장하는 과정이라고 볼 수 있다.

결론

이렇게 Prompt에서 Loop까지 Engineering의 변화를 정리해 보았다. 이러한 변화는 단순한 LLM 활용 기법이 늘어나는 것이 아니라 소프트웨어 엔지니어링의 문제로 확장되면서, 어떤 정보를 제공할지, 어떤 권한 을 주고 어떻게 검증할지까지 함께 설계도 같이 고려하게 되었다. 이는 LLM을 바라보는 관점이 바뀌는 과정으로 볼 수있다.

결국 LLM 엔지니어링은 좋은 답변을 얻는 기술에서, 안정적으로 일을 끝내게 만드는 기술로 이동하고 있다. Prompt에서 Loop까지의 흐름은 바로 이 변화를 보여준다.