프롬프트 (prompt)
LLM 에 건네는 입력 전체. 모델 출력을 좌우하는 '지시 + 문맥 + 예시' 의 묶음.
1줄 정의
LLM 에 건네는 입력 전체. 모델 출력을 좌우하는 ‘지시 + 문맥 + 예시’ 의 묶음.
전체 시스템에서 맡는 역할
프롬프트를 “AI 에 내리는 명령” 으로 이해하면 대체로는 맞지만, 실무에서 통하는 입자는 한 단계 더 아래에 있다.
프롬프트는 보통 3층으로 구성된다.
- System prompt: 모델의 행동·인격·지켜야 할 규칙을 설정 (개발자가 고정)
- User prompt: 사용자가 그때그때 넣는 지시
- Few-shot / Context: 예시, 과거 대화, 참고 문서
LLM 은 system + user + context 를 이은 입력을 받아 그걸 조건으로 다음 토큰을 예측한다. 그래서 프롬프트 작성 방식 하나에 출력 품질이 크게 흔들린다. 이게 “프롬프트 엔지니어링” 이라 불리는 기술의 내용이다.
Claude Code 나 Cursor 의 Agent 모드도 안쪽에서는 방대한 프롬프트 설계가 돌고 있다. system prompt 로 “당신은 유능한 코딩 어시스턴트” 를 정의하고, 도구 설명을 넣고, 사용자 지시를 더하고, 파일 내용을 컨텍스트에 섞는다. 사람 눈엔 “버그 고쳐” 한 줄이지만 모델이 실제로 보는 건 수천~수만 토큰의 구조화된 입력이다.
흔한 오해
- 오해 1: 프롬프트는 “주문” 으로 외우는 것이다, 라고 여겨지기 쉽다.
– 실제로는 모델도 평가 방법도 계속 바뀌어서 어제 잘 먹힌 프롬프트가 오늘 안 먹히기도 한다. 암기보다 “어떤 구조로 하면 출력이 안정되는가” 의 원리를 이해하는 게 낫다.
- 오해 2: 좋은 프롬프트를 쓰면 agent 를 만들 수 있다, 라고 기대되기 쉽다.
– 실제로 프롬프트는 agent 를 이루는 요소 하나일 뿐. 도구, 루프, 권한, 컨텍스트 관리가 다 갖춰져야 agent. 프롬프트만 갈고 닦아도 chatbot 을 못 넘는다.
- 오해 3: 짧은 프롬프트일수록 훌륭하다, 라고 여겨지기 쉽다.
– 실제로는 태스크 난도와 문맥량에 맞는 길이가 있다. 너무 짧으면 오해되고 너무 길면 중요 지시가 묻힌다. 기준은 “이 지시를 처음 보는 사람이 한 번에 이해할 수 있는가”.
이 용어가 중요한 이유
프롬프트를 “주문” 이 아니라 입력 설계 로 볼 수 있게 되면 내 워크플로 전체를 다시 짤 수 있게 된다. 이게 T2 에서도 잡아 둬야 하는 이유다.
- system prompt 와 user prompt 를 어디서 나눌 것인가
- 예시는 몇 개 넣고 어떻게 고를 것인가
- 컨텍스트는 어디서 가져올 것인가 (검색, 파일, 대화 기록)
- 출력 형식은 어디까지 지정할 것인가 (구조, 길이, 스타일)
이걸 판단할 수 있는 사람은 새 모델이나 새 도구로 옮겨도 생산성을 유지한다. 반대로 “이 프롬프트 복붙하면 된다” 수준에서 멈추면 모델 업데이트 때마다 0에서 다시 배우게 된다.
이 용어가 나오는 기사
- 프롬프트 엔지니어링, 바이브 코딩, Claude Code 관련 기사 다수