프롬프트 엔지니어링은 끝났는가? —— AI 개발의 주역이 「Prompt」에서 「Rules / Skills / Context / Quality

AI를 개발에 도입하는 것에 대해 다양한 논의가 일어나고 있다.

• 인간의 코딩 능력이 떨어지지 않을까
• AI에게 코드를 작성하게 해야 할까
• 프롬프트 엔지니어링 (Prompt Engineering)은 이제 구식 아닌가
• 앞으로의 개발자에게 필요한 능력은 무엇인가
• AI를 사용하는 팀과 사용하지 않는 팀의 차이는 무엇인가

겉으로는 「AI 찬성/반대」, 「프롬프트가 중요/중요하지 않음」으로 보이지만, 실무적인 관점에서 보면 논점이 어긋나 있다.

프롬프트 엔지니어링 (Prompt Engineering)은 사라진 것이 아니다. 단지, AI 개발의 주역이 아니게 되어가고 있을 뿐이다.

지금 주역이 되고 있는 것은 프롬프트 그 자체가 아니라, 다음과 같은 것들이다.

• Rules (규칙)
• Skills (기술)
• Context (문맥)
• ADR (Architecture Decision Records)
• 참고 구현
• 외부 설계
• CI/CD
• 자동 테스트
• Linter
• Code Review (코드 리뷰)
• Quality Gate (품질 게이트)
• 인간에 의한 검품
• 개발 플로우 전체의 통제

AI에게 「어떻게 말할 것인가」보다, AI가 망설임 없이, 망가뜨리지 않고, 검사받으면서 움직일 수 있는 환경을 어떻게 설계할 것인가 —— 이쪽의 비중이 높아지고 있다.

이 기사에서는 프롬프트 엔지니어링 (Prompt Engineering)에서 컨텍스트 엔지니어링 (Context Engineering), 워크플로우 엔지니어링 (Workflow Engineering), 품질 게이트 설계로 주전장이 이동하고 있는 흐름을 논문, 공식 문서, 실례를 바탕으로 정리한다.

프롬프트 엔지니어링 (Prompt Engineering)은 「AI에게 잘 부탁하는 기술」이었다.

AI 에이전트 (AI Agent) 시대의 개발에서는 그것만으로는 부족하다.

앞으로 중요한 것은 AI가 올바르게 작동할 수 있는 전제, 문맥, 절차, 제약, 검사 게이트를 설계하는 것이다.

강력한 AI 개발 팀은 프롬프트로 품질을 내는 것이 아니라, Rules / Skills / Context / Workflow / Quality Gate로 품질을 낸다.

프롬프트가 불필요해지는 것이 아니다. 역할이 바뀌는 것이다.

과거의 프롬프트는 품질 기준, 역할, 전제, 기대치, 제약을 매번 설명하는 것이었다.

당신은 숙련된 엔지니어입니다.
가독성, 유지보수성, 확장성, 보안을 고려하여,
기존 설계에 맞춰 고품질의 코드를 구현해 주세요.

Rules, Skills, ADR, 참고 구현, 외부 설계, 테스트, CI/CD가 갖춰진 상태에서 프롬프트는 다음과 같이 된다.

이 티켓을 기존의 Rules / Skills / ADR / 참고 구현에 따라,
영향 범위를 파악한 후 최소한의 차이(diff)로 구현해 주세요.

「프롬프트가 불필요해졌다」기보다, 프롬프트에 담아두었던 품질 기준이 외부화·자산화되었다는 이야기다.

프롬프트 엔지니어링 (Prompt Engineering)이 중요했던 이유를 부정할 필요는 없다. 초기 LLM 활용에서는 입력문의 작성 방식이 출력 품질을 크게 좌우했다.

OpenAI의 프롬프트 엔지니어링 (Prompt Engineering) 베스트 프랙티스에서도 대체로 다음과 같은 방침이 제시되어 있다.

• 최신의 고성능 모델을 사용할 것
• 지시를 명확히 할 것
• 지시와 입력 문맥을 구분할 것
• 출력 형식을 지정할 것
• 예시를 보여줄 것
• 문맥, 결과, 길이, 형식, 스타일을 구체적으로 적을 것

이는 지금도 유효하다. 단발적인 요약, 분류, 번역, 추출, 간단한 코드 생성에서는 프롬프트 작성 방식이 여전히 효과가 있다.

2024년의 프롬프트 엔지니어링 (Prompt Engineering)에 관한 서베이 논문에서도, Prompt Engineering은 모델의 가중치(weight)를 바꾸지 않고 태스크 특유의 지시나 예시로 LLM의 능력을 끌어내는 기술로 정리되어 있다.

프롬프트 엔지니어링 (Prompt Engineering)이 「틀렸던」 것이 아니다. LLM을 실무에 이용하기 위해 처음에 필요했던 기술이다.

변한 것은 AI의 이용 형태다.

과거에는 많은 사용법이 단발적이었다.

입력한다
↓
답변을 얻는다
...

개발 현장에서의 AI 이용은 점점 복잡해지고 있다.

사양을 읽는다
↓
기존 코드를 읽는다
...

이제 더 이상 단발성 프롬프트의 세계가 아니다. AI가 여러 턴(turn)에 걸쳐 도구를 사용하고, 파일을 편집하고, 테스트를 실행하며, 외부 정보를 참조하면서 진행한다.

이 순간부터 주전장은 「좋은 문장을 쓰는 것」에서, AI가 사용하는 문맥·도구·제약·실행 루프를 어떻게 설계할 것인가로 옮겨간다.

이 변화를 명확하게 언어화하고 있는 것이 Anthropic의 「Effective context engineering for AI agents」다.

Anthropic의 정리는 대체로 다음과 같다.

• 지난 몇 년간은 프롬프트 엔지니어링 (Prompt Engineering)이 주목받아 왔다
• 언어 모델 활용은 프롬프트 문구를 찾는 작업에서, 바람직한 행동을 이끌어내기 위해 어떤 컨텍스트 (Context) 구성을 제공할 것인가라는 문제로 옮겨가고 있다
• 컨텍스트 (Context)란 LLM이 추론 시에 받는 토큰 전체를 의미한다
• 컨텍스트 엔지니어링 (Context Engineering)이란 프롬프트 이외의 정보를 포함하여, LLM에게 유용하도록 관리·선별·유지하는 기술이다
• 에이전트 (Agent)에서는 시스템 지시사항 (system instructions), 도구 (tools), MCP, 외부 데이터, 대화 이력 등 모델에 전달되는 상태 전체를 다룰 필요가 있다

프롬프트는 컨텍스트의 일부다. 컨텍스트는 프롬프트만이 아니다.

컨텍스트에는 예를 들어 다음과 같은 것들이 포함된다.

• 시스템 지시 (System Instructions)
• 사용자 지시 (User Instructions)
• 규칙 (Rules)
• 기술 (Skills)
• 대화 이력 (Conversation History)
• 외부 설계 (External Design)
• 사양서 (Specifications)
• ADR (Architecture Decision Records)
• 참고 구현 (Reference Implementation)
• 리포지토리 내의 코드 (Code in Repository)
• 에러 로그 (Error Logs)
• 테스트 결과 (Test Results)
• 이슈 (Issue)
• PR 설명 (PR Description)
• MCP를 통한 외부 정보
• 도구 실행 결과 (Tool Execution Results)
• 과거의 실패 (Past Failures)
• 메모리 (Memory)
• 워크플로 상의 상태 (Workflow State)

AI에게 있어 '입력'은 채팅창의 한 문장만이 아니다. AI가 동작하는 시점에 주어지는 상황 일체가 입력이 된다.

따라서 '프롬프트를 쓰는 것'보다, 'AI가 읽어야 할 것, 읽지 말아야 할 것, 지켜야 할 것, 참조해야 할 것, 실행해도 좋은 것'을 설계하는 것이 더 효과적이다.

2025년 서베이 논문인 「A Survey of Context Engineering for Large Language Models」에서는 컨텍스트 엔지니어링 (Context Engineering)을 단순한 프롬프트 디자인 (Prompt Design)을 넘어서는 체계로 정리하고 있다.

LLM의 성능은 추론 시에 주어지는 문맥 정보에 크게 좌우되며, 컨텍스트 엔지니어링은 LLM에 제공하는 정보 페이로드 (Information Payload)를 체계적으로 최적화하는 기술로 다뤄진다.

논문상의 정리에서는 컨텍스트 엔지니어링에 크게 다음과 같은 것들이 포함된다.

• 컨텍스트 검색 (Context Retrieval)
• 컨텍스트 생성 (Context Generation)
• 컨텍스트 처리 (Context Processing)
• 컨텍스트 관리 (Context Management)
• RAG (Retrieval-Augmented Generation)
• 메모리 시스템 (Memory Systems)
• 도구 통합 추론 (Tool-integrated Reasoning)
• 멀티 에이전트 시스템 (Multi-agent Systems)

컨텍스트 엔지니어링은 '긴 프롬프트를 쓰는 기술'이 아니다. 다루는 질문은 다음과 같은 느낌이다.

• 필요한 정보를 어떻게 검색할 것인가
• 취득한 정보를 어떻게 압축할 것인가
• 오래된 정보와 새로운 정보를 어떻게 다룰 것인가
• 어떤 정보를 모델에 전달할 것인가
• 어떤 정보를 전달하지 않을 것인가
• 도구 실행 결과를 어떻게 문맥으로 되돌릴 것인가
• 메모리를 어떻게 업데이트할 것인가
• 여러 에이전트 간에 문맥을 어떻게 분담할 것인가
• 장기 태스크에서 문맥 저하를 어떻게 방지할 것인가

개발 현장의 과제와 맞닿아 있다. "적당히 고쳐줘"로는 품질이 안정되지 않는다. AI가 판단에 사용하는 정보를 정돈하고, 절차를 나누고, 제약을 부여하며, 출력을 검사할 필요가 있다.

OpenAI의 「A practical guide to building agents」에서도 에이전트 설계는 단순한 프롬프트 설계가 아니다.

에이전트 (Agents)는 '사용자를 대신하여 높은 독립성을 가지고 태스크를 수행하는 시스템'으로 정의되며, 설계 요소로 다음과 같은 것들이 꼽힌다.

• 모델 선정 (Model Selection)
• 도구 정의 (Tool Definition)
• 지시 설정 (Instruction Setting)
• 오케스트레이션 (Orchestration)
• 가드레일 (Guardrails)

프롬프트는 요소 중 일부일 뿐이다. AI가 어떤 도구를 사용할 수 있는지, 어떤 조건에서 멈추는지, 어디서 인간에게 되돌려주는지, 어느 범위까지 자율 실행할 수 있는지——제어 (Control)가 본질이다.

개발 현장에 대입하면 다음과 같다.

에이전트 설계 요소	개발 현장에서의 대응
Instructions	Rules / AGENTS.md / copilot-instructions.md / CLAUDE.md
...

AI 개발은 '프롬프트 개선'만으로는 성립하지 않는다. 에이전트에 대하여 업무 시스템처럼 권한, 절차, 예외 처리, 감사, 승인을 설계해야 한다.

단순한 이론적인 이야기가 아니다. 주요 AI 개발 도구들은 Rules나 Instructions를 명시적으로 다루는 방향으로 나아가고 있다.

Cursor는 Project Rules, Team Rules, User Rules, AGENTS.md 등을 통해 영속적인 지시사항을 관리할 수 있다. 매번 프롬프트에 규약이나 설계 사상을 쓰는 것이 아니라, 프로젝트 측에 문맥을 갖게 하는 메커니즘이다.

Rules에는 예를 들어 다음과 같은 내용을 작성할 수 있다.

• 아키텍처 방침 (Architecture Policy)
• 디렉토리 구조 (Directory Structure)
• 사용 라이브러리 (Used Libraries)
• 금지 사항 (Prohibitions)
• 명명 규칙 (Naming Conventions)
• 테스트 방침 (Testing Policy)
• 기존 구현 참조처 (References to Existing Implementations)
• 변경 시 확인 절차 (Verification Procedures for Changes)
• 리뷰 관점 (Review Perspectives)

Rules는 "매번 쓰는 프롬프트"가 아니라, AI가 항상 참조해야 하는 개발 규약이다.

GitHub Copilot Code Review에서도 리포지토리 단위나 경로 단위로 커스텀 인스트럭션 (custom instructions)을 설정할 수 있다.

GitHub Docs에서는 .github/copilot-instructions.md에 리포지토리 전체의 지시사항을 작성하고, .github/instructions/**/*.instructions.md에 경로 단위의 지시사항을 작성할 수 있다고 설명되어 있다. Copilot Code Review는 PR 리뷰 시 커스텀 인스트럭션 (custom instructions)을 참조할 수 있으며, 에이전트 스킬 (agent skills)이나 MCP 서버 (MCP servers)도 이용할 수 있다.

코드 리뷰 AI도 단순히 PR 차이점(diff)을 읽는 것에 그치지 않고 있다.

• 리포지토리 지시사항
• 경로별 지시사항
• 보안 체크리스트 (Security Checklist)
• 에이전트 스킬 (Agent Skills)
• MCP를 통한 외부 정보
• 이슈(Issue)나 인시던트 ID (Incident ID)

이러한 문맥(Context)을 사용하여 리뷰한다. 리포지토리에 내장된 규약과 외부 문맥을 참조하는 메커니즘이다.

2025년 논문 「On the Use of Agentic Coding Manifests: An Empirical Study of Claude Code」에서는 Claude Code를 위한 CLAUDE.md와 같은 설정 파일을 "에이전틱 코딩 매니페스트 (Agentic Coding Manifests)"로 분석하고 있다.

253개의 CLAUDE.md 파일을 조사한 결과, 작성된 내용 중 많은 비중을 차지하는 것은 다음과 같다.

• 운영 명령 (operational commands)
• 기술적 구현 노트 (technical implementation notes)
• 상위 수준 아키텍처 (high-level architecture)

개발자들은 단발성 프롬프트가 아니라, 프로젝트 문맥, 실행 명령, 아키텍처 정보를 리포지토리 내에 두기 시작했다.

기존에는 채팅창에 "당신은 우수한 엔지니어입니다"라고 적었다. 에이전틱 코딩 매니페스트 (Agentic Coding Manifest)에서는 리포지토리 내에 다음과 같이 배치한다.

# Project Overview
이 프로젝트는 Spring Boot + PostgreSQL + Meilisearch로 구성된 사내 업무 시스템입니다.
# Architecture
...

이것은 더 이상 프롬프트가 아니라, AI를 위한 개발자 온보딩 자료다.

2026년 논문 「Toward Instructions-as-Code: Understanding the Impact of Instruction Files on Agentic Pull Requests」에서는 AI 에이전트를 위한 인스트럭션 파일 (instruction files)을 소프트웨어 개발 활동으로 다룰 필요성을 제시하고 있다.

148개 프로젝트, 15,549건의 에이전틱 PR (Agentic PR)을 분석하여, 인스트럭션 파일 (instruction files) 작성 전후의 머지율 (merge rate), 변경량, 머지까지의 노력 등을 비교하였다.

인스트럭션 파일 (instruction files)이 있다고 해서 반드시 좋아지는 것은 아니다. 작성 후 머지율이 크게 상승한 프로젝트가 있는가 하면, 반대로 하락한 프로젝트도 있다.

"Rules를 작성하면 AI가 똑똑해진다"라는 단순한 문제가 아니다. Rules나 Instructions도 설계가 잘못되면 역효과를 낳는다.

나쁜 Instructions의 예.

# 나쁜 예
항상 고품질로 작성하세요.
유지보수성을 의식하세요.
...

너무 추상적이다. 좋은 Instructions는 AI가 판단할 수 있는 입도(Granularity)로 작성되어야 한다.

# 좋은 예
## Controller
- Controller에서는 비즈니스 로직을 작성하지 않는다
...

Instructions-as-Code라는 개념은 매우 타당하다. Rules나 Skills는 한 번 작성하고 끝내는 것이 아니라, 버전 관리하고, 리뷰하고, 개선하고, 테스트해야 하는 대상이기 때문이다.

2026년의 논문 「Configuring Agentic AI Coding Tools: An Exploratory Study」에서는 Claude Code, GitHub Copilot, Cursor, Gemini, Codex 등의 Agentic AI Coding Tools의 설정 메커니즘을 분석하고 있다.

2,926개의 GitHub 리포지토리를 조사한 결과, 대략 다음과 같은 경향이 보고되었다.

• Context Files가 설정의 중심이 되고 있다
• AGENTS.md가 도구 전반에 걸친 표준으로 나타나고 있다
• Skills나 Subagents의 채택은 아직 초기 단계이다
• 많은 Skills는 실행 가능한 워크플로 (Workflow)라기보다 정적인 지시에 머물러 있다
• Claude Code 사용자는 비교적 폭넓은 설정 메커니즘을 사용하고 있다

현장의 체감과 일치한다. 많은 개발 현장은 이제 막 다음 단계로 진입하기 시작했다.

제1단계: 프롬프트를 고민한다
제2단계: Rules / Instructions / AGENTS.md 를 배치한다
제3단계: Skills / Subagents / MCP / Hooks 를 사용한다
...

아직 많은 현장은 제2단계에 머물러 있다. 방향성 측면에서는 프롬프트 단독이 아니라, 리포지토리에 내장된 AI용 설정으로 나아가고 있다.

2026년의 논문 「Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems」에서는 Claude Code의 설계 공간 (Design Space)을 분석하고 있다.

Claude Code의 중심에는 모델을 호출하고, 도구를 실행하며, 반복하는 단순한 while-loop가 있다. 반면, 실제로 중요한 코드의 상당수는 그 주변 시스템에 있다고 설명한다.

주변 시스템에는 예를 들어 다음과 같은 것들이 있다.

• 권한 시스템 (Permission System)
• 안전성 분류 (Safety Classification)
• Context Management
• Context Compaction
• MCP
• Plugins
• Skills
• Hooks
• Subagents
• Worktree isolation
• Session storage

LLM을 호출하는 것만이라면 간단하다. 실무에서 사용할 수 있는 AI 에이전트 (Agent)로 만들려면 주변에 다음과 같은 것들이 필요하다.

• 어떤 도구를 사용해도 되는가
• 어떤 조작에는 승인이 필요한가
• 어떤 파일을 건드려도 되는가
• 긴 문맥 (Context)을 어떻게 압축할 것인가
• 실패했을 때 어떻게 되돌아갈 것인가
• 여러 작업을 어떻게 분리할 것인가
• 세션을 어떻게 저장할 것인가
• 위험한 조작을 어떻게 중단할 것인가

「Prompt Engineering」에서 「Workflow Engineering」, 「Quality Gate Engineering」으로의 이행이라는 관점으로 볼 수 있다.

Google Chrome 팀 등으로 잘 알려진 Addy Osmani는 2026년을 향한 LLM 코딩 워크플로 (coding workflow) 기사에서, LLM을 사용하는 개발에서는 「명확한 계획부터 시작하기」를 강조하고 있다.

흐름은 대략 다음과 같다.

• 갑자기 코드를 쓰게 하지 않는다
• 먼저 문제와 요구사항을 정리한다
• AI에게 질문하게 하여 사양 (Specification)을 구체화한다
• spec.md에 요구사항, 아키텍처 판단, 데이터 모델, 테스트 전략을 정리한다
• 그것을 바탕으로 구현 계획을 세운다
• 태스크를 작게 나눈다
• 그 후에 코딩에 들어간다

프롬프트 단독이 아니다. AI를 사용하기 전에, AI가 헤매지 않을 사양과 계획을 만드는 것이다.

인간의 개발도 마찬가지다. 사양이 모호한 상태에서 "적당히 만들어줘"라는 말을 들으면 위험하며, AI라면 더욱 그렇다. AI는 모호한 지시에도 그럴싸하게 대답해 버리기 때문에 모호함이 잘 보이지 않는다.

AI 개발에서는 사양, 설계, 수락 조건, 테스트 방침을 명문화하는 가치가 오히려 높아진다.

여기까지를 단계로 나타내면 다음과 같다.

Prompt Engineering
↓
Context Engineering
...

일본어로 하면 (한국어로 바꾸면).

프롬프트를 고민한다
↓
AI가 사용할 문맥을 정돈한다
...

• Prompt Engineering — AI에게 지시하는 기술
• Context Engineering — AI가 판단에 사용하는 재료를 설계하는 기술
• Workflow Engineering — AI가 작업을 진행하는 절차를 설계하는 기술
• Quality Gate Engineering — AI의 작업을 어디서 멈추고, 무엇을 충족해야 통과시킬지를 설계하는 기술

이러한 이행이 지금 일어나고 있는 일이다.

극단적인 질문을 던져보자.

Rules & Skills와 외부 설계 수준의 목표, 그리고 사용하는 아키텍처와 참고할 프로젝트가 있다면, 프롬프트는 필요 없는 것 아닌가?

답은 이렇다.

매번 작성하는 장문의 프롬프트는 필요 없어진다.

다만, 작업을 기동하는 짧은 지시는 남는다.

불필요해지는 것은 다음과 같은 프롬프트다.

당신은 우수한 엔지니어입니다.
유지보수성, 가독성, 확장성을 고려해 주세요.
기존 설계에 맞춰 주세요.
...

이것들은 본래 Rules나 Skills에 적혀 있어야 할 내용이다.

대신 필요해지는 것은 다음과 같은 지시다.

티켓 #123의 검색 조건 추가를 구현해 주세요.
먼저 영향 범위를 파악하고, 기존 검색 화면 A를 참고하여
Controller / Service / Repository / 화면 / 테스트를 최소한의 차이로 수정해 주세요.
...

프롬프트라기보다 작업 지시다. 프롬프트의 역할은 "품질 기준을 매번 설명하는 것"에서 "정비된 개발 환경을 기동하는 커맨드 (Command)"로 변한다.

AI 개발을 안정시키려면 최소한 다음과 같은 구성 요소가 필요하다.

docs/
requirements/
external-design.md
...

AGENTS.md에는 툴을 가로질러 AI 에이전트에게 읽히고 싶은 기본 방침을 적는다.

# AGENTS.md
## Project Overview
이 프로젝트는 사내 업무 시스템이며, 유지보수성과 업무 정합성을 중시한다.
...

Rules에는 항상 지켜야 할 규약을 적는다.

# Rules
## 공통
- 기존 명명 규칙을 따른다
...

Skills에는 작업 절차를 적는다.

# Skill: implement-feature
## Purpose
기능 추가를 안전하게 구현한다.
...

Quality Gate에는 통과 조건을 적는다.

# Quality Gates
## Gate 1: 구현 전
- 요구사항이 명확하다
...

이렇게 구성하면 프롬프트는 짧게 끝난다.

티켓 #123을 implement-feature Skill에 따라 진행해 주세요.
구현 전에 영향 범위와 작업 계획을 제시해 주세요.

이 정도로 끝낼 수 있는 상태가 강력하다.

AI가 구현할 수 있게 되어도 인간의 역할이 없어지는 것은 아니다. 다음과 같이 변한다.

기존의 역할	AI 시대의 역할
손으로 코드를 작성한다	AI에게 안전하게 작성하게 한다
...

코딩 능력이 불필요해지는 것이 아니다. 코드를 읽는 능력, 설계를 이해하는 능력, 위험한 차이(diff)를 간파하는 능력은 더욱 중요해진다.

놓쳐서는 안 될 능력은 대체로 다음과 같다.

• 사양을 읽는 능력
• 업무를 이해하는 능력
• 요구사항을 분해하는 능력
• 설계 의도를 설명하는 능력
• AI의 출력을 의심하는 능력
• 차이(diff)를 리뷰하는 능력
• 테스트의 타당성을 판단하는 능력
• 릴리스 여부를 판단하는 능력
• 실패를 규칙화하는 능력

인간이 담당해야 하는 것은 단순한 작업이 아니라, 판단·보증·통제·개선이다.

AI 개발을 현실적으로 운용하려면 대체로 다음과 같은 역할 분담이 필요하다.

역할	주요 책임
설계·구현 지휘	AI에게 맡길 작업을 분해하고, 구현 방침과 변경 범위를 결정한다
...

AI를 사용하는 사람만 늘린다고 해서 팀이 강해지지는 않는다. AI가 만든 것을 누가, 어디서, 무엇을 기준으로, 어떻게 검사할 것인가——이 부분을 설계하지 않으면 AI 활용은 개인기(Personal skill)에 머물게 된다.

개인기에 의존한 AI 활용은 단기적으로는 빠르다. 하지만 중장기적으로는 생성된 코드의 품질이 사람마다 들쭉날쭉하거나, 리뷰 관점이 일치하지 않거나, AI가 만든 차이(diff)를 설명하지 못하거나, 테스트는 늘어나는데 가치는 낮거나, 사양과 구현의 괴리를 알아차리지 못하거나, 기술적 부채가 급속도로 증가하거나, 특정 개인에게 종속된 AI 운용이 되는 등의 문제가 발생한다.

AI 시대에 필요한 것은 'AI를 쓸 줄 아는 사람'뿐만 아니라, AI를 포함한 개발 라인을 설계할 수 있는 사람이다.

Rules나 Docs가 없는 상태에서 매번 거대한 프롬프트를 쓰는 패턴.

당신은 숙련된 아키텍트이자 보안 전문가이며,
가독성, 유지보수성, 확장성, 테스트 용이성을 고려하여……

언뜻 보기에는 열심히 하는 것처럼 보이지만, 프로젝트 고유의 설계나 구현 규칙이 외부에 정의되어 있지 않기 때문에 재현성이 없다.

반대로 Rules를 너무 많이 쓰는 것도 위험하다.

• 모순되는 Rules
• 오래된 Rules
• 너무 추상적인 Rules
• 우선순위가 없는 Rules
• 어느 상황에 적용해야 할지 알 수 없는 Rules

Rules는 많다고 좋은 것이 아니다. 짧고, 구체적이며, 적용 상황이 명확하고, 유지보수되고 있을 것이 중요하다.

나쁜 Skills의 예.

# Skill: good coding
고품질의 코드를 작성해 주세요.
유지보수성을 중요하게 생각하세요.
...

이것은 Skill이 아니다. Skill은 AI가 실행할 수 있는 절차(Procedure)여야 한다.

# Skill: add-backend-api
1. OpenAPI 정의를 확인한다
2. Controller의 기존 구현을 확인한다
...

GitHub Copilot Code Review처럼 AI 리뷰는 편리하다. 하지만 인간 리뷰의 완전한 대체재는 아니다. 업무 타당성, 사용자 영향, 릴리스 판단, 설명 책임은 인간이 확인해야 한다. AI 리뷰는 품질 게이트 (Quality Gate)의 일부이지, 최종 승인자가 아니다.

AI가 작성한 코드는 테스트를 통과하더라도 위험한 경우가 있다. AI가 작성한 테스트 자체가 취약할 가능성이 있다.

• 정상계(Happy Path)만 있음
• 경계값(Boundary Value)이 없음
• 이상계(Edge Case)가 없음
• 모크(Mock)가 허술함
• 구현에 너무 치우친 테스트가 되어 있음
• 사양의 본질을 검증하지 않음

AI 시대에는 테스트의 개수보다 테스트의 의미를 볼 필요가 있다.

갑자기 완벽한 AI 개발 기반을 만들 필요는 없다. 현실적으로는 다음 순서로 정비하는 것이 좋다.

외부 설계, 화면 사양, API 사양, 수락 조건(Acceptance Criteria)을 정비한다. AI에게 맡기기 이전에, 인간 사이에서도 인식이 어긋나지 않는 상태를 만든다.

AI에게 단순히 "기존 방식에 맞춰줘"라고 말하는 것은 약하다.

검색 화면은 XxxSearchController / XxxSearchService / xxx-search.html을 참고할 것

이와 같이 구체적인 참조처를 지정한다.

처음에는 10~20개 정도면 충분하다.

• 계층 구조
• 명명 규칙 (Naming)
• 금지 사항
• 테스트 방침
• 변경 범위
• 보안
• 리뷰 관점

우선은 다음 4가지가 실용적이다.

implement-feature

fix-bug

write-test

review-pr

각각 AI가 실행할 수 있는 절차로서 작성한다.

PR(Pull Request) 전에 반드시 확인해야 할 항목을 만든다.

• 영향 범위
• 테스트
• 예외 처리
• 로그
• 보안
• 업무 타당성
• 릴리스 영향

AI가 지켜야 할 규칙을 인간의 주의력에만 의존하지 않는다.

• Formatter
• Linter
• Unit Test (단위 테스트)
• Integration Test (통합 테스트)
• Static Analysis (정적 분석)
• Security Scan (보안 스캔)
• Migration Check (마이그레이션 체크)
• API Contract Test (API 계약 테스트)

AI가 실수하면 화를 내는 것이 아니라, 시스템(Mechanism)으로 되돌린다.

AI가 DTO와 Entity를 혼용했다
↓
Rules에 "DTO와 Entity를 혼용하지 말 것"을 추가
...

이 루프가 중요하다.

AI를 포함한 개발 플로우는 예를 들어 다음과 같다.

1. 티켓 발행 (Ticket Creation)
- 목적
- 수락 조건
...

이 흐름에서 프롬프트는 중심이 아니다. 중심에 있는 것은 **공정과 품질 게이트 (Quality Gate)**다.

좋은 프롬프트를 잘 쓰는 사람이 강력했던 시대가 있었다. 지금도 가치는 있다.

다만, 개발 현장에서는 다음과 같은 사람이 더 가치가 높다.

• AI에게 전달할 문맥 (Context)을 설계할 수 있는 사람
• Rules를 정리할 수 있는 사람
• Skills를 절차화할 수 있는 사람
• ADR (Architecture Decision Record)로서 판단을 남길 수 있는 사람
• 참고 구현을 선택할 수 있는 사람
• 티켓을 AI가 처리하기 쉬운 입도로 분해할 수 있는 사람
• CI/CD를 통해 품질을 기계적으로 담보할 수 있는 사람
• AI 리뷰와 인간 리뷰의 경계를 정의할 수 있는 사람
• AI의 실패를 팀의 규칙으로 되돌릴 수 있는 사람

프롬프트 엔지니어라기보다, AI 개발 프로세스 설계자. 더 나아가, AI 시대의 소프트웨어 엔지니어링 담당자다.

프롬프트 엔지니어링은 끝났는가——끝나지는 않았다. 다만, 주역이 아니게 되었을 뿐이다.

이전의 프롬프트는 AI에게 품질 기준이나 역할을 매번 설명하는 것이었다. 앞으로의 프롬프트는 정비된 Rules, Skills, ADR, 외부 설계, 참고 구현, 테스트, CI/CD를 전제로 작업을 기동하는 짧은 지시가 된다.

프롬프트를 길게 만드는 것이 아니라, 프롬프트에 쓰지 않아도 되는 상태를 만드는 것이 중요하다. 그러기 위해서는 Rules, Skills, Context, ADR, 외부 설계, 참고 구현, Quality Gate, CI/CD, AI 리뷰, 인간 리뷰, 검품, 회고(Retrospective)가 필요하다.

AI 시대에 강한 것은 「AI를 사용하는 팀」이 아니라, AI를 포함한 개발 라인을 설계하고, 통제하며, 개선할 수 있는 팀이다.

프롬프트 엔지니어링 (Prompt Engineering)의 시대는 AI에게 어떻게 부탁할 것인가의 시대였다. 앞으로는 AI가 망설임 없이, 망가뜨리지 않으면서, 검사(Inspection)를 받으며 작동할 수 있는 개발 환경을 어떻게 구축할 것인가의 시대다.