AI 엔지니어링 4레이어: Prompt · Context · Harness · Loop

AI 엔지니어링의 4가지 레이어

AI 엔지니어링이 “좋은 프롬프트 작성”에서 끝나는 것이 아니라, 프롬프트를 감싸는 컨텍스트, 실행 하네스, 반복 루프까지 확장되어야 실무 시스템이 된다는 점을 잘 표현한 모델입니다.

한 문장으로 정리하면 다음과 같습니다.

Prompt는 AI에게 일을 시키는 지시이고, Context는 판단 근거이며, Harness는 AI를 실제 시스템 안에서 안전하게 실행시키는 장치이고, Loop는 목표 달성까지 반복·검증·수정하게 만드는 운영 구조입니다.

이 4개 레이어는 다음처럼 진화합니다.

좋은 답변을 넘어, 근거·실행·자동화까지 설계한다 — Prompt → Context → Harness → Loop

1. 그림의 전체 메시지

위 그림의 핵심 문장은 이것입니다.

각 레이어는 그 전 레이어를 감싼다.

이는 단순한 포함 관계라기보다 책임 범위가 확장되는 구조입니다.

1
2
3
4

Loop Engineering
  └─ Harness Engineering
       └─ Context Engineering
            └─ Prompt Engineering

안쪽 레이어는 AI 호출 1회에 가깝고, 바깥쪽으로 갈수록 업무 시스템, 운영 프로세스, 자동화 플랫폼에 가까워집니다.

OpenAI는 프롬프트 엔지니어링을 “모델이 요구사항을 충족하는 콘텐츠를 일관되게 생성하도록 효과적인 지시를 작성하는 과정”으로 설명합니다. 다만 모델 출력은 비결정적이므로 테스트와 평가 체계가 필요하다고도 설명합니다. (OpenAI 개발자)

2. 1번 레이어: 프롬프트 엔지니어링

정의

프롬프트 엔지니어링은 AI에게 무엇을, 어떤 관점에서, 어떤 형식으로, 어떤 제약하에 수행할지 지시하는 기술입니다.

이미지에서는 “채팅창에 입력하는 직접적인 내용”이라고 표현되어 있습니다. 실무적으로는 단순 사용자 질문뿐 아니라 다음을 포함합니다.

이 레이어의 핵심 질문

프롬프트 엔지니어링에서는 다음 질문이 중요합니다.

장점

프롬프트 엔지니어링은 도입이 쉽고 즉시 효과가 납니다. 교육, PoC, 문서 요약, 아이디어 발산, 보고서 초안 작성에는 매우 유용합니다.

한계

그러나 프롬프트만으로는 근거 데이터 부족, 업무 맥락 부족, 검증 부족, 반복 자동화 부족 문제가 발생합니다.

이미지의 표현처럼,

좋은 프롬프트도 컨텍스트가 없으면 추측일 뿐입니다.

예를 들어 “우리 회사 표준 아키텍처에 맞게 리뷰해줘”라고 아무리 잘 지시해도, AI에게 회사 표준 문서가 제공되지 않으면 실제 표준 준수 여부를 판단할 수 없습니다.

3. 2번 레이어: 컨텍스트 엔지니어링

정의

컨텍스트 엔지니어링은 모델이 답변을 생성하기 전에 어떤 정보, 문서, 이력, 예시, 정책, 도구 설명, 메모리 등을 보게 할지 설계하는 기술입니다.

Anthropic은 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 확장으로 보며, 단순히 좋은 문장을 쓰는 것이 아니라 모델 추론 시점에 들어가는 토큰과 정보를 관리하는 전략이라고 설명합니다. 특히 에이전트가 여러 턴과 긴 시간 동안 동작할수록 시스템 지시, 도구, 외부 데이터, 메시지 이력 등을 관리하는 것이 중요해진다고 설명합니다. (Anthropic)

컨텍스트의 범위

컨텍스트는 단순히 “참고 문서”만 의미하지 않습니다.

프롬프트와 컨텍스트의 차이

컨텍스트 엔지니어링의 핵심 원칙

컨텍스트는 많을수록 좋은 것이 아닙니다. Anthropic은 컨텍스트가 중요한 동시에 유한한 자원이며, 모델이 긴 컨텍스트에서 집중력을 잃거나 혼란을 겪을 수 있으므로 고신호 정보를 선별하는 것이 중요하다고 설명합니다. (Anthropic)

실무적으로는 다음 기준이 중요합니다.

의미

훌륭한 프롬프트도 컨텍스트가 없으면 추측한다.

이는 특히 엔터프라이즈 환경에서 매우 중요합니다. 회사별 아키텍처 표준, 보안 정책, 개발방법론, 운영 기준, 클라우드 가드레일은 공개 인터넷 지식만으로 정확히 판단할 수 없습니다.

따라서 업무 적용에서는 다음과 같은 구조가 필요합니다.

1
2
3
4
5
6
7

사용자 질문
  + 업무별 프롬프트 템플릿
  + 관련 사내 표준 문서
  + 프로젝트 설계서
  + 과거 이슈/장애 이력
  + 출력 스키마
  = 근거 있는 AI 응답

4. 3번 레이어: 하네스 엔지니어링

정의

하네스 엔지니어링은 모델 주변의 실행 코드, 도구 연결, 입출력 검증, 재시도, 로깅, 보안 통제, 구조화된 출력 등을 설계하는 기술입니다.

이미지에서는 “모델의 주변 코드를 구성한다”고 표현되어 있습니다. 이 표현이 매우 중요합니다. 프롬프트와 컨텍스트가 “모델에게 무엇을 보여줄 것인가”라면, 하네스는 모델을 실제 업무 시스템 안에서 어떻게 실행시킬 것인가입니다.

Anthropic은 에이전트 시스템의 기본 빌딩 블록을 retrieval, tools, memory로 강화된 LLM으로 설명하며, 도구 인터페이스와 문서화를 명확히 설계해야 한다고 설명합니다. (Anthropic)

하네스의 주요 구성 요소

컨텍스트와 하네스의 차이

이 둘은 자주 혼동됩니다.

예를 들어, “Jira 이슈를 읽는 방법”에 대한 설명은 컨텍스트에 포함될 수 있지만, 실제로 Jira API를 호출하고, 권한을 확인하고, 결과를 파싱하고, 실패 시 재시도하는 것은 하네스의 책임입니다.

이미지 문장의 의미

훌륭한 컨텍스트도 하네스가 없으면 흔들린다.

이는 다음과 같은 상황을 말합니다.

즉, 하네스가 없으면 AI 활용은 “개인 생산성 도구” 수준에 머무르고, 하네스가 생기면 “업무 시스템”으로 발전합니다.

5. 4번 레이어: 루프 엔지니어링

정의

루프 엔지니어링은 AI가 목표를 달성할 때까지 계획, 실행, 관찰, 검증, 수정, 재시도를 반복하도록 시스템을 설계하는 기술입니다.

최근 루프 엔지니어링이라는 표현은 “사람이 매번 에이전트를 프롬프트하는 대신, 에이전트를 프롬프트하고 검사하고 다시 실행하는 시스템을 설계한다”는 의미로 사용됩니다. Addy Osmani는 루프 엔지니어링을 사람이 직접 프롬프트하는 역할을 시스템으로 대체하는 것으로 설명하며, 목적을 정의하고 AI가 완료될 때까지 반복하는 구조로 설명합니다. (Addy Osmani)

루프의 기본 구조

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

목표 입력
  ↓
계획 수립
  ↓
컨텍스트 수집
  ↓
모델 호출
  ↓
도구 실행
  ↓
결과 관찰
  ↓
검증
  ↓
성공?
  ├─ 예: 종료 / 보고 / 승인 요청
  └─ 아니오: 수정 후 재시도

Anthropic은 에이전트를 “LLM이 환경 피드백에 기반해 도구를 사용하는 루프”로 설명하며, 실행 중에는 도구 결과나 코드 실행 결과 같은 ground truth를 받아 진행 상황을 평가하고, 최대 반복 횟수 같은 중지 조건을 두는 것이 중요하다고 설명합니다. (Anthropic)

루프가 하네스와 다른 점

하네스는 AI가 “잘 실행되도록” 만드는 장치이고, 루프는 AI가 “끝까지 일하도록” 만드는 장치입니다.

이미지 문장의 의미

하네스가 있어도 루프가 없으면 멈춰 선다. 루프가 없으면 결국 당신이 병목이 된다.

이 말은 매우 실무적입니다.

하네스가 있어도 한 번 실행한 뒤 결과를 보고, 다시 지시하고, 다시 검증하고, 다음 작업을 배정하는 일을 사람이 계속 해야 한다면, 자동화의 병목은 다시 사람에게 돌아옵니다.

예를 들어 코드 수정 에이전트가 다음과 같이 동작한다면 아직 루프가 약한 상태입니다.

1
2
3
4
5
6
7
8
9

AI가 코드 수정
  ↓
사람이 테스트 실행
  ↓
사람이 실패 로그 복사
  ↓
사람이 다시 AI에게 수정 요청
  ↓
사람이 PR 작성

루프가 들어가면 다음처럼 바뀝니다.

1
2
3
4
5
6
7
8
9
10
11
12
13

AI가 코드 수정
  ↓
테스트 자동 실행
  ↓
실패 로그 자동 분석
  ↓
수정안 재생성
  ↓
테스트 재실행
  ↓
성공 시 PR 생성
  ↓
위험 변경은 사람 승인 요청

LangChain은 루프 엔지니어링을 Agent Loop, Verification Loop, Event-driven Loop, Hill-climbing Loop처럼 여러 층으로 설명합니다. 특히 검증 루프는 산출물을 루브릭이나 테스트로 검사하고 실패 시 피드백을 다시 모델에 전달하며, 이벤트 기반 루프는 문서 도착, 스케줄, 웹훅 같은 이벤트가 발생하면 에이전트가 자동 실행되는 구조입니다. (LangChain)

6. 네 레이어를 실무 관점에서 다시 해석

비유로 보면

아키텍처 관점으로 보면

1
2
3
4
5
6
7
8
9
10
11

[Loop Layer]
- 목표, 상태, 반복, 중지 조건, 승인, 스케줄러

  [Harness Layer]
  - 오케스트레이션, 도구 연결, 검증, 로깅, 권한, 에러 처리

    [Context Layer]
    - RAG, 문서, 메모리, 정책, 예시, 메타데이터

      [Prompt Layer]
      - 역할, 지시, 제약조건, 출력 형식

업무 자동화 성숙도 관점으로 보면

7. 예시: 아키텍처 리뷰 AI 시스템

첨부 그림의 4개 레이어를 “아키텍처 리뷰 자동화”에 적용하면 다음과 같습니다.

1단계: Prompt

1
2
3

너는 엔터프라이즈 아키텍처 리뷰어다.
다음 설계서를 보안성, 확장성, 운영성, 유지보수성 관점에서 검토하라.
이슈는 High/Medium/Low로 분류하고, 개선안을 제시하라.

이 단계에서는 리뷰 관점과 출력 형식을 잘 정의합니다.

2단계: Context

AI에게 다음 자료를 함께 제공합니다.

이제 AI는 일반론이 아니라 조직 기준에 맞는 리뷰를 수행할 수 있습니다.

3단계: Harness

하네스는 다음 작업을 자동화합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13

Confluence에서 설계서 조회
  ↓
관련 표준 문서 검색
  ↓
AI 리뷰 실행
  ↓
결과를 JSON Schema로 검증
  ↓
High 이슈만 Jira 후보 이슈로 변환
  ↓
리뷰 결과를 Confluence 표준 템플릿으로 생성
  ↓
로그와 근거 문서 ID 저장

이제 사람은 AI 답변을 복사해 붙여넣는 것이 아니라, 시스템화된 리뷰 파이프라인을 사용하게 됩니다.

4단계: Loop

루프가 들어가면 다음이 가능해집니다.

1
2
3
4
5
6
7
8
9
10
11
12
13

설계서 변경 감지
  ↓
자동 리뷰 실행
  ↓
High 이슈 존재 여부 확인
  ↓
개선 권고안 생성
  ↓
설계서 수정본 재검토
  ↓
High 이슈 0건이면 리뷰 완료
  ↓
남아 있으면 담당자에게 승인/조치 요청

이 구조가 되면 AI는 “리뷰 의견 생성기”가 아니라 아키텍처 품질 관리 프로세스의 일부가 됩니다.

8. 레이어별 품질 지표

AI 엔지니어링을 조직에 도입하려면 각 레이어별로 측정 지표가 달라야 합니다.

프롬프트만 평가하면 “답변이 좋아 보이는가”를 보게 됩니다. 루프까지 평가하면 “업무가 실제로 완료되었는가”를 보게 됩니다.

9. 리스크와 통제 방안

AI 시스템이 Prompt → Context → Harness → Loop로 갈수록 효과는 커지지만, 위험도 함께 커집니다.

OWASP LLM Top 10 2025는 Prompt Injection, Sensitive Information Disclosure, Improper Output Handling, Excessive Agency, Unbounded Consumption 등을 주요 위험으로 제시합니다. 특히 Harness와 Loop 레이어는 도구 사용과 반복 실행이 포함되므로 과도한 권한, 무제한 실행, 민감정보 노출 리스크가 커집니다. (OWASP Gen AI Security Project)

NIST AI RMF의 생성형 AI 프로파일은 조직이 생성형 AI 고유 리스크를 식별하고, 거버넌스·측정·관리 활동에 반영할 수 있도록 돕는 프레임워크입니다. 엔터프라이즈 환경에서는 루프 엔지니어링을 단순 개발 기법이 아니라 AI 리스크 관리 체계 안에서 다루는 것이 바람직합니다. (NIST)

10. 어떤 업무에 어느 레이어까지 필요한가?

모든 업무에 루프 엔지니어링이 필요한 것은 아닙니다. Anthropic도 LLM 애플리케이션을 만들 때 가능한 가장 단순한 해법부터 시작하고, 필요할 때만 복잡도를 높이라고 권고합니다. 특히 많은 경우 단일 LLM 호출에 검색과 예시를 붙이는 정도로 충분할 수 있다고 설명합니다. (Anthropic)

실무 판단 기준은 간단합니다.

11. 그림을 보완해서 이해해야 할 점

첨부 그림은 교육적으로 매우 좋지만, 실무 아키텍처 관점에서는 몇 가지 보완해서 봐야 합니다.

1. Context는 Prompt와 완전히 분리된 것이 아니다

기술적으로 모델이 보는 모든 입력 토큰을 넓은 의미의 컨텍스트라고 볼 수 있습니다. 따라서 프롬프트도 컨텍스트의 일부라고 볼 수 있습니다. 다만 그림에서는 이해를 쉽게 하기 위해 직접 지시문은 Prompt, 그 지시문을 뒷받침하는 정보 묶음은 Context로 나눈 것입니다.

2. Harness와 Context는 일부 겹친다

도구 설명, API 사용법, 함수 스키마는 모델에게 제공되는 정보이므로 Context 성격이 있습니다. 그러나 실제 도구 호출, 권한 체크, 오류 처리, 결과 검증은 Harness의 책임입니다.

3. Loop는 무조건 좋은 것이 아니다

루프는 자동화 수준을 높이지만, 잘못 설계하면 비용 폭증, 오류 누적, 무단 실행, 책임 소재 불명확 문제가 생깁니다. 따라서 루프에는 반드시 다음이 있어야 합니다.

4. 사람은 제거되는 것이 아니라 역할이 바뀐다

루프 엔지니어링의 목적은 사람을 없애는 것이 아니라, 사람이 매번 프롬프트를 입력하는 병목에서 벗어나 목표, 기준, 검증 방식, 승인 정책을 설계하는 역할로 이동하는 것입니다.

12. 엔터프라이즈 도입 전략

대기업 IT 조직에서는 다음 순서가 현실적입니다.

1단계: Prompt 표준화

업무별 표준 프롬프트를 만듭니다.

2단계: Context 체계화

사내 지식베이스, 표준 문서, 프로젝트 산출물, 운영 이력을 연결합니다.

핵심은 RAG 자체가 아니라 신뢰 가능한 컨텍스트 공급망을 만드는 것입니다.

1
2
3
4
5
6
7
8
9
10
11

문서 수집
  ↓
권한 적용
  ↓
메타데이터 부여
  ↓
청킹/임베딩
  ↓
검색 품질 평가
  ↓
근거 포함 응답

3단계: Harness 플랫폼화

개별 팀이 임의로 AI 스크립트를 만들게 두기보다, 공통 하네스를 제공합니다.

4단계: 제한된 Loop부터 시작

처음부터 운영 조치를 자동화하지 말고, 안전한 영역부터 시작하는 것이 좋습니다.

5단계: 운영 거버넌스 수립

루프 기반 AI는 사실상 “자동으로 판단하고 행동하는 소프트웨어 시스템”입니다. 따라서 다음 거버넌스가 필요합니다.

13. 최종 권고안

제 의견으로는, 이 그림은 앞으로 AI 엔지니어링 역량을 설명하는 데 매우 유용한 프레임입니다. 특히 대기업 IT 조직에서는 다음처럼 해석하는 것이 좋습니다.

1
2
3
4
5
6
7
8
9
10
11

Prompt Engineering
= AI 활용의 기본기

Context Engineering
= 사내 지식과 업무 기준을 AI에 연결하는 데이터/지식 아키텍처

Harness Engineering
= AI를 업무 시스템으로 만드는 애플리케이션 아키텍처

Loop Engineering
= AI가 목표 달성까지 반복 수행하는 Agentic Process Architecture

실무 도입 순서는 다음이 가장 안전합니다.

1
2
3
4
5
6

1. 프롬프트 표준화
2. 컨텍스트/RAG 체계화
3. 하네스 공통 플랫폼화
4. 검증 루프 도입
5. 제한된 업무 자동화
6. 승인·감사·롤백이 포함된 에이전트 운영

가장 중요한 판단 기준은 이것입니다.

AI에게 좋은 답을 얻고 싶으면 Prompt를 설계하고, 근거 있는 답을 얻고 싶으면 Context를 설계하고, 안정적인 업무 시스템을 만들고 싶으면 Harness를 설계하고, 사람이 병목이 되지 않는 자동화 체계를 만들고 싶으면 Loop를 설계해야 합니다.

첨부 그림의 메시지를 엔터프라이즈 아키텍처 관점으로 확장하면, 앞으로의 핵심 역량은 단순히 “프롬프트를 잘 쓰는 능력”이 아니라 AI가 안전하고, 검증 가능하며, 반복적으로 성과를 내도록 업무 루프를 설계하는 능력입니다.