Specification Engineering은 AI에게 어떻게 물을지보다, 어떤 산출물이 올바른지 정의하는 기술이다. 목표, 입력, 제약, 출력 형식, 엣지 케이스, 검증 단계, 실패 모드를 명확히 적어 AI 작업을 실행 가능하고 검토 가능한 단위로 바꾼다.
프롬프트 엔지니어링과 무엇이 다른가
프롬프트 엔지니어링은 모델이 더 나은 답변을 하도록 질문을 다듬는 기술이다. Specification Engineering은 답변이 “그럴듯한가”가 아니라 “요구사항을 만족했는가”를 판단할 기준을 만든다.
| 구분 | 프롬프트 엔지니어링 | Specification Engineering |
|---|---|---|
| 초점 | 어떻게 물을지 | 무엇이 완료 조건인지 |
| 산출물 | 자연어 지시, 역할, 예시 | 목표, 계약, 제약, 테스트, 검증 기준 |
| 실패 양상 | 답이 부정확하거나 모호함 | 요구와 평가 기준이 어긋남 |
| 잘 맞는 작업 | 단발성 요약, 아이디어, 초안 | 코딩, 데이터 분석, 에이전트 워크플로, 구조화 출력 |
AI가 코드를 수정하고, SQL을 만들고, 스프레드시트를 분석하고, JSON을 생성하고, 여러 도구를 호출하는 환경에서는 “좋은 답”보다 “검증 가능한 결과”가 중요하다. 명세가 약하면 모델은 보이는 테스트만 맞추거나, 중요한 제약을 놓치거나, 사용자의 의도와 다른 최적화를 할 수 있다.
좋은 명세의 구성 요소
실무 명세는 길 필요가 없다. 다만 다음 요소가 빠지면 AI가 임의로 해석할 공간이 커진다.
| 요소 | 질문 |
|---|---|
| Objective | 무엇을 달성해야 하는가 |
| Context | 모델이 알아야 할 배경은 무엇인가 |
| Inputs | 사용할 데이터, 파일, 도구, 전제는 무엇인가 |
| Output format | 최종 산출물은 어떤 구조여야 하는가 |
| Constraints | 하지 말아야 할 것, 지켜야 할 한계는 무엇인가 |
| Evaluation criteria | 성공 여부를 어떻게 판단할 것인가 |
| Edge cases | 예외 상황을 어떻게 처리할 것인가 |
| Verification steps | 어떤 테스트, 체크, 리뷰가 통과해야 하는가 |
예를 들어 “고객 이탈 데이터를 분석해줘”는 프롬프트다. “결측치, 클래스 불균형, 누수 위험, 주요 예측 변수를 확인하고, train/test split 후 세 모델을 비교하며, Accuracy·Precision·Recall·F1·ROC-AUC·PR-AUC와 confusion matrix를 보고하고, 상관관계만 기반으로 비즈니스 제안을 세 개 작성하라”는 명세에 가깝다.
AI 코딩에서의 의미
AI 코딩 에이전트에서는 Specification Engineering이 spec-driven-development와 직접 연결된다. “간단한 지출 앱 만들어줘”보다, 다음처럼 계약을 정의해야 반복 수정이 줄어든다.
- React 앱이어야 한다.
- 지출 추가, 수정, 삭제, 카테고리 필터, 월별 합계를 지원한다.
- 금액은 양수, 날짜는 필수, 카테고리는 선택 필수로 검증한다.
- localStorage에 저장한다.
- 추가, 삭제, 필터, 합계 계산 테스트를 포함한다.
- 외부 유료 API는 쓰지 않는다.
이런 명세는 모델의 자유도를 줄이는 것이 아니라, 모델이 창의성을 써도 되는 범위와 검증해야 할 계약을 분리한다.
작업 흐름
Specification Engineering 기반 작업 흐름은 다음 순서가 좋다.
- 초안 명세를 작성한다.
- AI에게 빠진 요구사항과 모호한 표현을 먼저 찾게 한다.
- 명세를 갱신한 뒤 생성 작업을 실행한다.
- 테스트, 스키마 검증, 수동 리뷰 등으로 결과를 검사한다.
- 실패한 체크만 근거로 수정하게 한다.
- 최종 가정과 한계를 로그로 남긴다.
이 흐름은 agent-harness 설계에서도 중요하다. 에이전트가 여러 단계로 실행될수록 각 단계가 어떤 입력을 받고 어떤 출력을 남겨야 하는지 명세화해야 관측성과 재현성이 생긴다.
어디에 적합한가
- AI 코딩 에이전트로 실제 코드베이스를 수정하는 개발팀
- LLM 출력이 JSON, SQL, 리포트, 테스트 결과처럼 후속 시스템에 들어가는 워크플로
- 데이터 분석에서 누수, 지표 선택, 검증 절차를 명시해야 하는 팀
- 업무 자동화에서 사람 승인 조건과 실패 모드를 문서화해야 하는 운영팀
단순 아이디어 발산이나 짧은 초안 작성에는 과할 수 있다. 하지만 산출물이 배포, 의사결정, 고객 응답, 규정 준수에 연결된다면 프롬프트보다 명세를 먼저 다루는 편이 낫다.
관련 문서
- spec-driven-development — AI 보조 개발을 명세 중심으로 운영하는 방법론
- ouroboros — 프롬프트 대신 명세로 AI 코딩 워크플로를 재생 가능하게 만드는 Agent OS
- agent-harness — 에이전트 실행 루프와 하네스 설계
- outlines-tips-structured-generation — JSON·선택지 출력을 토큰 단계에서 강제하기
참고 자료
- Specification Engineering: The New Skill After Prompt Engineering — KDnuggets (2026-08-10)
- Requirement-Oriented Prompt Engineering — arXiv (2024-09-13)
- SWE-bench — SWE-bench