[생성AI] AI 엔지니어링 4가지 패러다임 — Prompt, Context, Agentic, Harness

개요

요즘 Claude Code로 작업을 하다 보면, “프롬프트를 잘 쓰는 것”만으로는 부족하다는 걸 느낄 때가 많습니다. 똑같은 지시를 해도 어떤 정보를 함께 줬느냐에 따라 결과가 달라지고, 에이전트를 어떻게 구성하느냐에 따라 작업 품질이 확연히 차이 나기도 합니다.

이런 경험을 정리하다 보니, AI를 효과적으로 활용하려면 프롬프트 외에도 신경 써야 할 영역이 꽤 많다는 것을 알게 되었습니다. 이번 포스트에서는 제가 실무에서 느낀 것들을 바탕으로 AI 엔지니어링을 4가지 패러다임으로 나누어 정리해 보았습니다.

패러다임	한 줄 요약
Prompt Engineering	AI에게 어떻게 말할지 다듬는 것
Context Engineering	AI에게 어떤 정보를 보여줄지 고르는 것
Agentic Engineering	AI가 도구를 써서 스스로 일하게 만드는 것
Harness Engineering	AI가 일하는 환경(권한, 안전장치)을 세팅하는 것

1. Prompt Engineering — “어떻게 말할까”

가장 많이 들어본 개념일 것입니다. AI에게 전달하는 지시문(prompt)을 어떻게 작성하느냐에 따라 결과가 크게 달라집니다.

같은 질문이라도 물어보는 방식에 따라 답이 달라지는 경험, 다들 해보셨을 거예요. “코드 리뷰 해줘”보다 “시니어 개발자 관점에서 보안 이슈 중심으로 리뷰해줘”라고 하면 훨씬 구체적인 피드백을 받을 수 있습니다.

자주 쓰이는 기법

Few-shot: “이런 식으로 해줘”라고 예시를 몇 개 보여주는 방법입니다. 패턴을 직접 보여주면 AI가 의도를 더 정확하게 파악합니다.
Chain-of-Thought: “단계별로 생각해보세요”라고 요청하면 AI가 추론 과정을 거치면서 더 정확한 답을 내놓습니다.
Role Prompting: “당신은 10년 경력의 백엔드 개발자입니다”처럼 역할을 부여하면, 해당 관점에 맞는 답변을 받을 수 있습니다.
출력 형식 지정: “JSON으로 응답하세요”, “마크다운 테이블로 정리하세요”처럼 출력 형태를 미리 정해두면 후처리가 편합니다.

실무에서는 이런 식으로 씁니다

범위를 제한하면 AI가 불필요한 내용을 쏟아내는 걸 막을 수 있습니다.

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

출력 형식을 미리 정해두면 결과를 바로 활용할 수 있어 편합니다.

다음 형식의 테이블로 응답하세요:
| 기능 | 설명 | 우선순위 |

그런데 프롬프트만으로는 한계가 있습니다

아무리 프롬프트를 잘 작성해도, AI가 외부 데이터를 가져오거나 도구를 직접 사용하게 할 수는 없습니다. “말을 잘 거는 것”과 “일을 잘 시키는 것”은 다른 차원의 문제입니다. 이 한계를 넘기 위해 다음 패러다임이 필요합니다.

2. Context Engineering — “무엇을 보여줄까”

똑같은 질문을 해도, AI에게 어떤 정보를 함께 보여주느냐에 따라 결과가 완전히 달라집니다. 이것을 체계적으로 설계하는 것이 Context Engineering입니다.

비유하자면, 프롬프트가 “이 문제를 풀어줘”라는 질문이라면, 컨텍스트는 시험지 옆에 놓아두는 참고 자료입니다. 같은 문제를 풀더라도 교과서를 펼쳐놓고 푸는 것과 아무것도 없이 푸는 것은 결과가 다릅니다.

핵심은 “필요한 정보만 골라서 넣는 것”

LLM의 컨텍스트 윈도우는 무한하지 않습니다. 정보를 너무 많이 넣으면 중요한 내용이 묻히고, 비용도 올라갑니다. 반대로 너무 적게 넣으면 AI가 충분한 판단을 내리지 못합니다.

실무에서 자주 하는 실수와 개선

API 응답 전체를 그대로 컨텍스트에 넣는 것은 흔한 실수입니다. 필요한 필드만 뽑아서 넣는 것만으로도 결과 품질이 크게 좋아집니다.

# 이렇게 하면 불필요한 데이터까지 전부 들어갑니다
curl -s https://api.example.com/comments | jq '.[].body'

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

지시문도 마찬가지입니다. 하나의 거대한 파일에 모든 규칙을 넣는 것보다, 상황에 따라 필요한 부분만 로드하는 게 낫습니다.

# 이렇게 하면 매번 500줄이 전부 컨텍스트에 올라갑니다
instructions.md (500줄)

# 이렇게 나누면 필요한 모듈만 올라갑니다
router.md (50줄) → 상황에 맞는 module.md만 추가 로드

Claude Code를 사용하고 계신다면, CLAUDE.md를 프로젝트 루트에 하나만 두는 것보다 서브 디렉토리별로 나누어 관리하는 것이 좋은 예입니다. 프론트엔드 코드를 수정할 때 백엔드 규칙까지 로드할 필요는 없으니까요.

그래도 넘지 못하는 벽

정보를 아무리 잘 골라서 넣어줘도, AI가 스스로 파일을 열어보거나, API를 호출하거나, 코드를 실행하게 할 수는 없습니다. 컨텍스트 엔지니어링은 AI의 판단 재료를 최적화하지만, 판단 후에 실행하는 것까지는 설계하지 않습니다.

3. Agentic Engineering — “스스로 하게 할까”

지금까지 프롬프트(어떻게 말할까)와 컨텍스트(무엇을 보여줄까)를 다뤘습니다. 둘 다 AI의 **“입력”**을 최적화하는 것이었습니다. Agentic Engineering은 여기서 한 발 더 나아가, AI가 도구를 써서 스스로 일하게 만드는 것입니다.

쉽게 말하면, AI에게 답을 달라고 하는 것이 아니라, 일을 맡기는 것입니다. “이 코드를 리팩토링해줘”라고 말하면 AI가 파일을 읽고, 수정하고, 테스트를 돌려보고, 결과를 알려주는 것이죠.

어떤 것들이 가능할까요

Tool Use: AI가 터미널 명령을 실행하거나, 파일을 읽고 쓰거나, API를 호출합니다.
Multi-Agent: 코드를 탐색하는 에이전트, 리뷰하는 에이전트, 구현하는 에이전트로 역할을 나눕니다.
계획 수립 후 실행: 복잡한 작업을 한 번에 시키는 대신, 먼저 계획을 세우게 하고 확인한 뒤 실행합니다.
자기 수정: AI가 결과를 스스로 검증하고, 문제가 있으면 수정하는 과정을 반복합니다.

실무에서 특히 효과적인 패턴

작업 특성에 따라 다른 모델을 쓰면 비용과 품질을 동시에 잡을 수 있습니다.

탐색 에이전트: 코드베이스를 빠르게 조사하고 구조를 파악
  → Sonnet (빠르고 저렴한 모델로 충분)

리뷰 에이전트: 산출물을 꼼꼼하게 검증하고 결함을 찾아냄
  → Opus (비판적 사고가 필요한 작업에 적합)

결과물의 품질이 중요한 경우, 한 번에 끝내려 하지 말고 반복 검증 루프를 만드는 것도 좋습니다.

최대 3라운드 반복:
  1. 작업 수행
  2. 자기 검토 또는 별도 에이전트 검토
  3. 통과하면 종료, 아니면 수정 후 다음 라운드

Claude Code에서 Agent 도구로 서브 에이전트를 만들거나, /plan 모드로 먼저 계획을 세운 뒤 실행하는 것이 이 패러다임에 해당합니다.

자율성이 높아질수록 필요한 것

에이전트가 알아서 파일을 수정하고 명령을 실행하다 보면, 자연스럽게 **“이거 해도 되는 건가?”**라는 질문이 따라옵니다. 중요한 파일을 실수로 삭제하거나, 의도하지 않은 명령을 실행하는 문제가 생길 수 있습니다. 이 문제를 해결하기 위해 마지막 패러다임이 필요합니다.

4. Harness Engineering — “어디서 하게 할까”

Harness는 원래 말의 힘을 안전하게 제어하는 **마구(馬具)**를 뜻합니다. AI도 마찬가지로, 강력한 능력을 가졌지만 적절한 제어 장치 없이 풀어놓으면 예상치 못한 문제가 생길 수 있습니다.

Harness Engineering은 AI가 일하는 방의 규칙을 정하는 것입니다. 어떤 도구를 쓸 수 있는지, 어떤 파일에 접근할 수 있는지, 위험한 작업 전에 어떤 검증을 거쳐야 하는지를 미리 설정해 둡니다.

실무에서 바로 쓸 수 있는 설정들

최소 권한 원칙: AI가 꼭 필요한 것만 할 수 있게 제한합니다. 읽기는 허용하되, 삭제나 관리자 명령은 차단하는 식입니다.

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

Hooks로 자동 검증 끼워넣기: AI가 코드를 커밋하려고 할 때 자동으로 린트를 돌리게 할 수 있습니다. 사람이 매번 체크하지 않아도 일정 수준의 품질이 보장됩니다.

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

Claude Code를 쓰고 계시다면, settings.json에서 권한을 세팅하고 Hooks로 검증 파이프라인을 구성하는 것이 바로 Harness Engineering입니다.

Hooks 설정에 대한 구체적인 방법은 Claude Code terminal-notifier로 작업 완료 알림 받기에서 다루고 있습니다.

환경만으로는 부족합니다

아무리 안전한 방을 만들어도, 그 안에서 일하는 AI가 엉뚱한 지시를 받거나 잘못된 정보를 보고 있다면 좋은 결과를 기대하기 어렵습니다. 좋은 환경은 좋은 프롬프트, 좋은 컨텍스트, 좋은 에이전트 설계와 만날 때 비로소 제 역할을 합니다.

한눈에 비교하기

관점	Prompt	Context	Agentic	Harness
뭘 다루나	지시문	정보	행동	환경
비유	”뭘 해라"	"이걸 보고 해라"	"이 도구로 스스로 해라"	"이 방에서 해라”
핵심 활동	지시를 명확하게	정보를 골라서	도구와 에이전트를	권한과 안전장치를
결과물	프롬프트 텍스트	데이터 파이프라인	에이전트 구조	설정 파일, Hooks
Claude Code	명확한 지시 작성	CLAUDE.md 모듈화	Agent 도구, /plan	settings.json, Hooks

4가지 패러다임의 관계

이 4가지는 따로 노는 것이 아니라, 겹겹이 쌓인 레이어 구조입니다.

┌─────────────────────────────────────────┐
│  Harness Engineering (실행 환경)          │
│  ┌───────────────────────────────────┐  │
│  │  Agentic Engineering (행동 설계)    │  │
│  │  ┌─────────────────────────────┐  │  │
│  │  │  Context Engineering (정보)   │  │  │
│  │  │  ┌───────────────────────┐  │  │  │
│  │  │  │  Prompt Engineering   │  │  │  │
│  │  │  │  (지시)               │  │  │  │
│  │  │  └───────────────────────┘  │  │  │
│  │  └─────────────────────────────┘  │  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘

가장 안쪽부터 살펴보면:

Prompt는 Context의 일부입니다. 프롬프트도 결국 컨텍스트 윈도우에 들어가는 텍스트니까요.
Context는 Agent가 참고하는 재료입니다. 에이전트는 컨텍스트에 있는 정보를 보고 판단하고 행동합니다.
Agent는 Harness 안에서 실행됩니다. 아무리 유능한 에이전트라도 환경이 허용하지 않는 일은 할 수 없습니다.

바깥 레이어가 안쪽 레이어의 효과를 증폭시킵니다. 반대로, 어느 한 레이어가 부실하면 다른 레이어가 아무리 좋아도 전체 결과가 떨어집니다. 예를 들어 프롬프트를 아무리 잘 써도 컨텍스트에 엉뚱한 정보가 들어있으면 소용없고, 에이전트를 잘 설계해도 실행 환경의 권한이 부족하면 작업을 끝마칠 수 없습니다.

결국 4가지를 균형 있게 신경 쓰는 것이 AI를 가장 잘 활용하는 방법이라고 생각합니다.