LLM을 처음 쓰기 시작했을 때 가장 많이 들었던 말은 Prompt Engineering이었다.

AI에게 어떻게 질문해야 더 좋은 답을 받을 수 있을까?

처음에는 이 문제가 가장 중요해 보였다.

그런데 AI를 반복적으로 쓰기 시작하면 조금 다른 문제가 생긴다.

오늘은 이렇게 답하고
내일은 다르게 답하고
같은 작업인데 기준도 흔들리고
출력 형식도 매번 달라진다.

그때부터 질문 하나를 잘 만드는 것보다 AI가 어떤 방식으로 행동해야 하는지를 정의하는 일이 중요해진다.

이 글에서는 이런 재사용 지침을 Meta Prompt라고 부르겠다. 다만 이 용어는 프롬프트를 생성·개선하는 프롬프트를 뜻하기도 한다. 여기서 다루는 내용은 주로 system/developer 지침이나 프로젝트 규칙에 해당하며, Meta Prompt를 독립된 표준 계층으로 정의하려는 것은 아니다.

나는 두 개를 이렇게 구분해서 이해하고 있다.

Prompt Engineering이 좋은 질문을 만드는 기술이라면, Meta Prompt는 AI의 행동 원칙을 만드는 기술이다.

먼저 Prompt부터

가장 단순한 Prompt는 그냥 요청이다.

이 코드를 리뷰해줘.

이것도 충분히 동작한다.

하지만 결과는 꽤 넓게 흔들릴 수 있다.

AI가 성능을 먼저 볼 수도 있고, 가독성을 먼저 볼 수도 있고, 단순 요약만 할 수도 있다.

그래서 Prompt Engineering을 적용하면 요청을 조금 더 구체적으로 만든다.

아래 코드를 리뷰해줘.

다음 순서로 확인해줘.
1. 보안 문제
2. 장애 가능성
3. 성능
4. 가독성

문제가 있다면
- 문제 위치
- 이유
- 수정 예시

순서로 정리해줘.

같은 “코드 리뷰” 요청이지만 훨씬 원하는 결과에 가까워진다.

Prompt Engineering은 결국 명확성을 높이는 작업이다

좋은 Prompt에는 보통 몇 가지 요소가 들어간다.

코드 리뷰 요청이라면 다음 여섯 가지를 구체적으로 적을 수 있다.

  • 목표: 이 코드를 리뷰해줘.
  • 역할: 시니어 백엔드 엔지니어 관점에서 검토해줘.
  • 기준: 보안, 장애, 성능, 가독성 순서로 확인해줘.
  • 입력: 검토할 Java 코드를 함께 제공한다.
  • 제약: 추측하지 말고 코드에서 확인 가능한 내용만 다뤄줘.
  • 출력: 문제, 이유, 수정안을 구분해 정리해줘.

결국 핵심은 AI에게 우리가 원하는 것을 덜 애매하게 전달하는 것이다.

flowchart TD
    N0["모호한 요청"]
    N1["조건 추가"]
    N2["평가 기준 추가"]
    N3["출력 형태 정의"]
    N4["더 일관된 답변"]
    N0 --> N1
    N1 --> N2
    N2 --> N3
    N3 --> N4

그래서 Prompt Engineering은 여전히 중요하다.

특히 한 번성 작업에서는 꽤 강력하다.

그런데 매번 이걸 적어야 할까?

문제는 반복 작업이다.

예를 들어 나는 AI에게 코드 리뷰를 받을 때 항상 이런 기준을 원한다고 해보자.

  • 보안
  • 장애 가능성
  • 성능
  • 유지보수성

매번 이렇게 쓰는 것은 귀찮다.

이번에도 시니어 백엔드 엔지니어처럼 보고...
보안 먼저 확인하고...
성능도 보고...
추측하지 말고...

이 규칙들이 특정 질문이 아니라 모든 코드 리뷰에 적용해야 하는 공통 정책이라면 위로 올릴 수 있다.

그게 Meta Prompt다.

Meta Prompt는 무엇인가?

Meta Prompt는 개별 작업 자체보다 모델이 작업을 수행하는 방식을 정의하는 상위 지침에 가깝다.

예를 들어:

너는 시니어 백엔드 엔지니어처럼 행동한다.

코드 리뷰 시 다음 순서를 따른다.

1. Security
2. 장애 가능성
3. Performance
4. Maintainability

문제를 발견하면 반드시
- 문제
- 영향
- 근거
- 수정 방법

을 제시한다.

확실하지 않은 내용은 사실처럼 단정하지 않는다.

이것을 기본 규칙으로 가지고 있다면 사용자는 이후에 그냥 이렇게 말할 수 있다.

이 코드 리뷰해줘.

실제 작업 Prompt는 짧아졌지만 AI가 사용하는 기준은 유지된다.

구조로 보면 이런 느낌이다.

flowchart TD
    M["Meta Prompt"] --> R["역할·판단 기준"]
    M --> C["금지 사항·출력 원칙·작업 방식"]
    R --> P["지침과 요청을 반영해 코드 검토"]
    C --> P
    U["User Prompt: 이 코드 리뷰해줘"] --> P
    P --> A["Answer: 리뷰 결과"]

Prompt와 Meta Prompt의 가장 큰 차이

둘을 비교하면 훨씬 이해하기 쉽다.

구분 Prompt Meta Prompt
목적 지금 할 작업 지시 작업하는 방식 정의
범위 한 번의 요청 여러 요청에 반복 적용
예 이 코드 리뷰해줘 코드 리뷰 시 항상 보안을 먼저 확인
변경 빈도 자주 변경 상대적으로 고정
역할 Task Policy / Behavior

나는 개인적으로 Task와 Policy의 차이라고 생각하면 가장 이해하기 쉬웠다.

  • Prompt: 무엇을 할 것인가
  • Meta Prompt: 어떤 원칙으로 할 것인가

개발 업무로 보면 더 명확하다

예를 들어 Terraform을 작성한다고 해보자.

일반 Prompt:

AWS S3 Bucket Terraform 코드 만들어줘.

Prompt Engineering:

AWS S3 Bucket Terraform 코드를 작성해줘.

조건:
- Public Access Block 활성화
- Versioning 활성화
- Server-side encryption 사용
- 변수와 output 분리
- Terraform 1.8 기준

Meta Prompt:

Infrastructure 코드를 작성할 때는 항상 다음 원칙을 따른다.

1. Public exposure를 기본적으로 금지한다.
2. Encryption이 가능한 리소스는 기본 활성화한다.
3. 하드코딩 대신 variable을 사용한다.
4. 최소 권한 원칙을 따른다.
5. 변경 영향이 큰 설정은 주석으로 설명한다.
6. 코드 생성 후 보안 위험을 자체 점검한다.

그리고 실제 요청은 다시 간단해진다.

S3 Bucket 하나 만들어줘.

Meta Prompt에 인프라 작성 원칙이 이미 있기 때문이다.

Meta Prompt는 개발 규칙과 비슷하다

개발팀에는 보통 여러 규칙이 있다.

  • Coding Convention
  • Architecture Rule
  • Security Policy
  • PR Template
  • Code Review Checklist
  • Definition of Done

Meta Prompt는 이런 규칙을 AI가 이해할 수 있는 형태로 표현한 것과 비슷하다.

사람 개발자에게:

우리 팀에서는 Controller에 비즈니스 로직 넣지 마세요.

라고 문서화하는 것처럼 AI에게도:

Controller에는 요청 검증과 Service 호출만 둔다.
비즈니스 로직을 생성하지 않는다.

라고 정의할 수 있다.

그래서 Meta Prompt는 단순히 “AI에게 성격을 부여하는 프롬프트”보다 훨씬 실용적인 개념이라고 생각한다.

잘 사용하면 AI용 Engineering Guideline이 된다.

좋은 Meta Prompt에는 무엇이 들어갈까?

개인적으로는 크게 다섯 가지 정도로 나누면 관리하기 편하다.

1. Role

AI가 어떤 관점에서 문제를 볼지 정의한다.

너는 Backend / DevOps 경험이 많은 Senior Engineer다.

하지만 Role만 길게 적는 것은 생각보다 중요하지 않을 수 있다.

“세계 최고의 천재 개발자” 같은 표현보다 실제 판단 기준을 명확하게 주는 편이 더 유용하다.

2. Principles

가장 중요한 부분이다.

Security > Reliability > Performance > Convenience

처럼 판단 우선순위를 명시할 수 있다.

예를 들면:

Infrastructure 변경에서는
편의성보다 안전성을 우선한다.

Production 변경은
되돌릴 수 있는 방법이 있는지 먼저 확인한다.

이런 규칙은 실제 Agent 작업에서도 중요해진다.

3. Workflow

어떤 순서로 작업할지도 정의할 수 있다.

1. 요구사항 확인
2. 현재 코드 분석
3. 변경 영향 파악
4. 최소 변경으로 구현
5. Test
6. 결과 요약

AI가 매번 작업 순서를 새로 결정하지 않아도 된다.

4. Constraints

하지 말아야 하는 것도 중요하다.

확실하지 않은 API를 임의로 만들지 않는다.

기존 public interface를 이유 없이 변경하지 않는다.

Production credential을 코드에 작성하지 않는다.

AI 시스템에서는 “무엇을 해야 하는가”만큼 무엇을 하면 안 되는가가 중요하다.

5. Output Contract

결과 형태도 정의할 수 있다.

예를 들어 장애 분석 Agent라면:

답변은 항상 다음 형식으로 작성한다.

원인:
영향:
근거:
조치:
추가 확인:

이렇게 만들면 후속 시스템에서 결과를 처리하기도 쉬워진다.

Meta Prompt가 길수록 좋은 것은 아니다

처음에는 Meta Prompt에 모든 규칙을 넣고 싶어진다.

100줄
200줄
500줄...

그런데 규칙이 많아질수록 서로 충돌하거나 중요한 규칙이 묻힐 수 있다.

그래서 나는 Meta Prompt도 코드처럼 관리하는 게 좋다고 생각한다.

  • 짧게
  • 명확하게
  • 중복 제거
  • 우선순위 명시
  • 필요하면 문서로 분리

예를 들면 모든 프로젝트 지식을 Meta Prompt에 넣는 것보다는:

flowchart TD
    M["Meta Prompt"] --> R["핵심 행동 규칙·판단 우선순위"]
    M --> L["필요한 문서 위치 안내"]
    L --> C["Project Context"]
    R --> W["작업 수행"]
    C --> W

처럼 분리하는 편이 낫다.

여기서 자연스럽게 Context Engineering으로 이어진다.

Meta Prompt와 Context Engineering은 다르다

Meta Prompt가 행동 규칙이라면 Context는 실제 판단에 필요한 정보다.

예를 들어:

Meta Prompt:

기존 Architecture를 최대한 유지한다.

그런데 AI가 현재 Architecture를 모르면 이 규칙을 실행할 수 없다.

그래서 다음 정보가 필요하다.

  • architecture.md
  • repository structure
  • API specification
  • DB schema
  • recent PR
  • logs
  • issue

이것이 Context다.

  • Prompt: 지금 무엇을 시킬까?
  • Prompt Engineering: 어떻게 요청해야 명확할까?
  • Meta Prompt: 어떤 원칙으로 행동해야 할까?
  • Context Engineering: 판단에 필요한 어떤 정보를 줄까?

결국 하나만 잘한다고 AI가 항상 좋은 결과를 내는 것은 아니다.

명확한 Prompt, 일관된 Meta Prompt, 적절한 Context를 함께 갖추면 더 안정적인 결과를 기대할 수 있다.

지침과 실행 권한은 다른 계층이다

‘운영 DB를 변경하지 않는다’고 적는 것은 모델의 행동 지침이다. 실제 운영 DB 쓰기 권한을 제거하는 것은 실행 환경의 통제다. 안전성이 필요한 작업에서는 두 가지를 함께 적용한다.

지침 시스템에서 확인할 통제
운영 데이터 변경 금지 읽기 전용 계정, 대상 제한
배포 전 검증 CI 필수 검사와 배포 gate
무한 재시도 금지 실행 횟수·시간·비용 제한
근거를 남기기 도구 실행 로그와 변경 이력

문서나 외부 페이지에서 읽은 문장을 신뢰된 상위 정책으로 취급하지 않는 것도 중요하다. 정책은 버전 관리하고, 정책을 바꿨을 때 허용·금지 사례에서 동작이 유지되는지 평가한다.

Agent가 되면 Meta Prompt의 의미가 더 커진다

단순 Chat에서는 잘못된 답변 하나가 큰 문제가 아닐 수 있다.

하지만 Agent가 실제 행동을 하기 시작하면 얘기가 달라진다.

  • 코드 수정
  • Git Push
  • Issue 변경
  • Cloud Resource 생성
  • DB Query 실행
  • Browser 작업

이제 AI가 단순히 “답변하는 시스템”이 아니라 행동하는 시스템이 된다.

그러면 반복적으로 지켜야 할 규칙이 필요하다.

예를 들어:

Production 변경은 직접 실행하지 않는다.

삭제 작업은 항상 대상과 영향을 먼저 확인한다.

권한을 추가할 때는 최소 권한을 우선한다.

실패한 작업을 무한 재시도하지 않는다.

이런 규칙은 한 번의 Prompt에 넣을 내용이 아니다.

Agent 전체에 적용되는 상위 정책에 가깝다.

그래서 Agent가 발전할수록 Meta Prompt도 단순한 문장 작성 기법에서 Agent Policy 설계에 가까워질 것이라고 생각한다.

그러면 Harness Engineering과는 어떻게 연결될까?

여기까지 오면 이전에 정리했던 Harness Engineering과 연결된다.

flowchart TD
    P["Prompt: 무엇을 할지"] --> A["Agent 작업"]
    M["Meta Prompt: 행동 원칙"] --> A
    C["Context: 판단에 필요한 정보"] --> A
    A --> H["Harness: 환경·도구·검증"]
    H -->|"실행 결과와 피드백"| A

예를 들어 “장애 원인을 찾아 수정해줘”라는 Agent를 만든다면:

Prompt
"장애 원인을 찾아 수정해줘"

Meta Prompt
"안정성을 우선하고 근거 없는 변경은 하지 않는다"

Context
Repository + Logs + Metrics + Runbook

Harness
GitHub + Terminal + Test + CI + Sandbox

각각 맡는 역할이 다르다.

이 중 하나라도 부족하면 Agent의 품질이 떨어질 수 있다.

Harness에 대한 내용은 AI Agent 시대, 왜 Harness Engineering이 중요해졌을까에서 따로 정리했다.

내가 생각하는 흐름

AI 개발 방식을 시간 순서로 단순화하면 이런 느낌이다.

flowchart TD
    N0["Prompt"]
    N1["Prompt Engineering"]
    N2["Meta Prompt"]
    N3["Context Engineering"]
    N4["Tools"]
    N5["Harness Engineering"]
    N6["Agent"]
    N0 --> N1
    N1 --> N2
    N2 --> N3
    N3 --> N4
    N4 --> N5
    N5 --> N6

물론 실제 기술 발전이 정확히 이 순서대로 진행된 것은 아니다.

하지만 AI를 사용하는 개발자 입장에서는 관심사가 이렇게 넓어지고 있는 느낌이 든다.

처음에는:

어떻게 질문하지?

였다.

그다음은:

어떤 규칙을 계속 적용하지?

그리고 이제는:

어떤 정보와 도구를 주고 실제 일을 맡기지?

로 이동하고 있다.

결론

Prompt Engineering과 Meta Prompt를 굳이 나눠서 생각해야 하는 이유는 일회성 요청과 반복 가능한 행동 규칙을 분리하기 위해서다.

나는 이렇게 정리하는 게 가장 이해하기 쉬웠다.

Prompt는 AI에게 지금 할 일을 전달하는 요청이고, Prompt Engineering은 그 요청을 더 명확하고 효과적으로 다듬는 작업이다. Meta Prompt는 여러 작업에서 반복적으로 지킬 행동 원칙을 정한다.

여기에 Context Engineering으로 판단에 필요한 정보를 제공하고, Harness Engineering으로 실제 작업 환경과 검증 시스템을 갖춘다.

결국 좋은 AI 시스템은 엄청난 Prompt 하나로 만들어지는 것이 아니다.

신뢰할 수 있는 AI를 만들려면 Task·Rules·Context·Environment를 함께 설계해야 한다.

그래서 앞으로 Prompt Engineering이 사라진다기보다 역할이 조금 더 명확해질 것 같다.

Prompt는 작업을 정의하고, Meta Prompt는 행동을 정의하고, Context는 판단 재료를 제공한다.

그리고 그 모든 것을 실제 시스템에서 움직이게 만드는 것이 Harness다.

참고 자료

용어의 사용 범위는 제품과 연구자마다 조금씩 다를 수 있다. 이 글에서는 개발자가 AI 시스템을 설계할 때 실용적으로 구분하기 쉬운 관점으로 정리했다.