“ChatGPT에게 부탁했는데, 나온 결과물을 그대로 쓸 수 없었다.” — 업무에서 AI를 사용하기 시작한 사람이 가장 먼저 부딪히는 벽입니다.

원인의 대부분은 모델의 성능 문제가 아니라, 프롬프트가 ‘지시’의 세부 단위로 작성되어 있기 때문에 있습니다. 사람과 사람 사이라면 “자연스럽게 정리해 줘”라는 말만으로 통하지만, LLM(대규모 언어 모델)은 이전 문맥이나 회사 내부의 암묵지를 가지고 있지 않습니다. 그 결과, 매번 포맷이 달라지고, 전제가 임의로 보충되며, 결국 모든 것을 수동으로 수정해야 하는 상황이 발생합니다.

본 글에서는 실무에서 재현 가능한 결과물을 도출하기 위한 ‘입력(Input)・제약(Constraint)・출력(Output)’ 설계 프레임워크 (ICO 프레임), 복사-붙여넣기만으로 작동하는 실전 템플릿 3가지, 그리고 이를 자동화 파이프라인에 통합하는 아키텍처를 설명합니다.

특정 모델이나 기능에 의존하지 않는 방식으로 작성되었기 때문에 ChatGPT / Claude / Gemini 어느 것에서도 그대로 사용할 수 있습니다.

실무에서 실패하기 쉬운 프롬프트에는 공통적으로 3가지 유형이 있습니다.

“개조식으로 요약해 줘”라고만 지시하면, 제목의 깊이, 기호, 순서가 매번 달라집니다. 한 번은 사용 가능해도, 두 번째 요청에서는 다른 형식의 결과물이 나와 후속 작업(복사-붙여넣기, 스프레드시트 전사, 검토)에 차질이 생깁니다.

“신제품 홍보 문구를 작성해 줘”라고 의뢰하면, AI는 타겟 고객, 가격, 제공 시기를 “그럴듯하게” 채워 넣습니다. 이것은 단순한 환각(Hallucination) 문제가 아니라, 빈칸을 메우도록 작동하는 사양이기 때문입니다. 채워 넣고 싶지 않은 빈칸은 명시적으로 “불분명한 점은 불분명하다고 작성해 줘”라고 지시해야 합니다.

인간의 ‘자연스러운 느낌’이란 회사 내부의 과거 자료, 상사의 취향, 업계 관행이 집합된 결과물입니다. LLM은 이를 모르기 때문에 평균적이고 무난한 글에 그치게 됩니다. 평균적인 문장은 평균적인 결과만을 만들어냅니다.

즉, 프롬프트는 ‘부탁’이 아니라 **‘사양서(Specification)’**로서 작성해야 합니다. 이는 소프트웨어 개발에서 모호한 요구 정의가 재작업을 유발하는 것과 같은 구조입니다.

실무에서 사용되는 방식은 다음 3개 블록으로 나누어 작성하는 방법입니다 (ICO 프레임).

• 소재는 본문에 붙여넣습니다 (참조시키고 싶은 자료는 “이것이 유일한 근거”라고 명시합니다).
• 독자는 “누가, 무엇을 알고 있고, 무엇을 결정하는지”까지 작성해야 합니다.
• 역할은 “당신은 편집자입니다” 정도로는 약합니다. “〇〇 업계의 제안 자료를 10년간 리뷰해 온 전문가”처럼 판단 기준을 가진 역할로 설정해야 합니다.

제약(Constraint)은 문장으로 쓰지 않고, 목록 형태의 체크리스트로 만듭니다. LLM은 목록의 각 항목을 개별적으로 참조하기 쉽기 때문입니다.

• 소재에 적혀있지 않은 사실을 추가하지 않는다. 불분명한 점은 “확인 필요”라고 출력한다.
• 수치나 고유 명사는 소재의 표기 그대로 사용한다.
• 1문장은 60자 이내로 작성하고, 명사형 종결(체언적 마무리)을 쓰지 않는다.
• 과장된 표현(절대, 반드시, 누구나)을 사용하지 않는다.

출력(Output)은 ‘읽기 쉬움’보다 **‘검증 가능함’**을 우선합니다. 표나 JSON 형태로 만들면, 빠진 항목, 중복, 데이터 형식 불일치를 프로그램으로 감지할 수 있습니다.

• 제목 구조를 고정한다 (H2는 3개, 각 H2에 H3를 2개 등).
• 필수 항목을 열거한다 (담당자・기한・근거).
• 가능하다면 JSON Schema를 제공합니다.

생성 → 검증 → 수정의 루프를 하나의 프롬프트 내에서 완성시킵니다.

출력 후, 다음 관점에서 자체 리뷰하고, 문제가 있다면 수정본만 다시 출력해 주세요.
1. Constraint의 각 항목에 위반된 부분이 없는가
2. Output의 필수 항목이 모두 채워져 있는가
... 

이것을 추가하는 것만으로도 재작업 시간이 체감상 절반 이하로 줄어듭니다.

# 역할
당신은 프로젝트 관리를 전문으로 하는 PM입니다.
# 입력
...

evidence(근거 인용)를 필수화하는 점이 핵심입니다. 근거 작성을 요구하면, AI가 “그럴듯한 작업”을 만들 여지가 줄어들고, 사람의 검토도 순식간에 끝납니다.

긴 글을 한 번에 쓰게 하면 후반부가 옅어지는 경향이 있습니다. 일단 구성만 먼저 출력하게 하고, 확인한 후에 본문을 작성하도록 하는 것이 요령입니다.

# 역할
당신은 BtoB 제안서의 구성 설계에 능숙한 컨설턴트입니다.
# 입력
...

---(구성을 확인했다면, 이어서 실행)--- 
위의 구성안으로 확정합니다. 각 절을 300~400자로 작성하고,
서두에 100자 요약과 말미에 “다음 행동(Next Action)”을 3가지 항목 넣어주세요.

자동화 파이프라인에서는 생성물을 그대로 다음 공정으로 넘기는 것이 가장 위험합니다. 공개 또는 전송 직전에 삽입하는 검토용 프롬프트가 필요합니다.

역할

당신은 엄격한 리뷰어입니다. 작성자의 의도를 파악하지 않고, 기준만을 가지고 판정합니다.

입력

...

여기에 게이트를 넣으면, 인간의 리뷰는 “OK인지 수정이 필요한지” 판단하는 것만으로 충분하여 확인 비용이 대폭 감소합니다.

여기까지는 채팅 환경에서의 사용법이었습니다. 실무에서는 이것을 **함수(function)**로 만들어 파이프라인에 통합합니다.

프롬프트는 코드와 마찬가지로 버전 관리를 합니다. 변수는 {{...}}로 명시하여 누락을 테스트에서 감지할 수 있도록 합니다.

PROMPT_VERSION = "v3"
TEMPLATE = """...{{MEETING_MINUTES}}..."""
def build_prompt(minutes: str) -> str:
...

LLM의 출력은 확률적입니다. 검증 오류를 예외로 멈추는 것이 아니라, 수정 지시로 반환하는 것이 안정 운용의 핵심입니다.

from pydantic import BaseModel, ValidationError
class Task(BaseModel):
title: str
...

temperature=0 (또는 최소값)으로 설정하더라도 완전한 결정성을 얻을 수 없기 때문에, 재시도(retry)와 로그 기록은 필수입니다. 실패했을 때는 프롬프트와 검증 오류를 저장해 두면 템플릿 개선 사이클을 돌릴 수 있습니다.

[트리거] 회의 종료 / 파일 업데이트 / 정기 크론 작업(cron)
↓
[입력 정규화] 녹취록・글자 수 제한・개인 정보 제거
...

멱등성(Idempotency): 동일한 입력으로 태스크가 중복 등록되지 않도록, 입력 해시를 키로 사용합니다.
휴먼 게이트(Human Gate): 외부 전송・공개・금액이 관련된 작업은 반드시 승인을 거칩니다.
비용 상한선(Cost Limit): 1회 실행당 토큰 상한을 설정하고, 초과 시 중단 및 알림을 보냅니다.

본 기사의 핵심은 네 가지입니다.

• 프롬프트는 “부탁”이 아니라 “규격서(Specification)”로 작성한다.
• Input / Constraint / Output의 3개 블록으로 나눈다.
• 출력은 기계적으로 검증 가능한 형태(JSON・표・고정 헤드라인)로 만든다.
• 자동화할 경우, 스키마 검증・재시도・휴먼 게이트를 세트로 설계한다.

이 네 가지 포인트만으로 AI의 결과물은 “사용 가능/불가능”에서 “그대로 흐르게 할 수 있는(streamable)” 수준으로 바뀝니다.

실무에서의 템플릿 운용이나 비엔지니어 사용자를 위한 쉬운 절차는 아래에 정리했습니다 (무료 기사 목록입니다).