프롬프트는 문장이 아니라 맥락 설계다

프롬프트라는 말은 너무 가볍게 쓰인다.

사람들은 종종 좋은 프롬프트를 주문처럼 생각한다. 특정 문장을 넣으면 결과가 좋아지고, 어떤 표현을 쓰면 모델이 갑자기 똑똑해질 것처럼 말한다. 하지만 실제로 Claude를 잘 쓰는 방식은 주문에 가깝지 않다.

차라리 작은 작업 환경을 설계하는 일에 가깝다.

Anthropic의 Prompting 101은 이 점을 꽤 명확하게 보여준다. 영상은 자동차 보험 청구 이미지를 분석하는 예시를 통해 프롬프트를 단계적으로 쌓아간다. 처음부터 "분석해줘"라고 던지는 것이 아니라, 어떤 회사의 어떤 업무인지, 어떤 자료를 보고 있는지, 어떤 판단을 해야 하는지, 어떤 형식으로 결과를 내야 하는지 차례로 넣는다.

중요한 건 문장력이 아니다.

맥락의 배치다.

모델은 우리 머릿속을 보지 못한다. 우리가 보기에는 당연한 상황도 모델에게는 비어 있다. 이 자료가 고객 민원인지, 내부 검수인지, 법적 리스크가 있는 판단인지, 단순 분류인지, 사람이 마지막에 확인하는지에 따라 좋은 답은 달라진다. 그러니 프롬프트의 첫 번째 일은 모델을 똑똑하게 만드는 게 아니라, 모델이 엉뚱한 상황을 상상하지 않게 막는 것이다.

그래서 좋은 프롬프트에는 업무 배경이 들어간다.

"너는 보험 청구 이미지를 검토한다"는 말과 "스웨덴 자동차 보험사의 청구 검수 흐름에서, 제출 이미지와 양식 정보를 비교해 손상 여부와 청구 타당성을 판단한다"는 말은 다르다. 후자는 모델에게 어떤 세상 안에서 일해야 하는지 알려준다.

두 번째는 자료의 경계다.

영상에서는 XML 태그나 Markdown 같은 구획을 활용한다. 이건 장식이 아니다. 모델에게 "이 안은 사용자 선호", "이 안은 양식 정보", "이 안은 분석 대상"이라고 알려주는 표지판이다. 긴 프롬프트에서 표지판이 사라지면 모델은 어느 정보가 규칙이고 어느 정보가 데이터인지 헷갈린다.

사람도 회의 자료를 볼 때 제목, 섹션, 표, 첨부를 구분한다. 모델도 마찬가지다. 맥락을 한 덩어리로 던지면 똑똑한 모델도 괜히 추측을 섞는다. 구획을 나누면 모델은 필요한 정보를 다시 찾기 쉬워진다.

세 번째는 예시다.

프롬프트에서 예시는 모델에게 말투만 알려주는 것이 아니다. 판단 기준을 압축해서 보여준다. 어떤 경우에는 "손상 있음"으로 봐야 하고, 어떤 경우에는 "정보 부족"으로 봐야 하며, 어떤 경우에는 사람이 재확인해야 하는지 예시가 보여준다.

규칙만 있으면 모델은 경계 사례에서 흔들린다. 예시는 그 경계를 잡아준다.

네 번째는 마지막 reminder다.

영상에서는 중요한 기준을 끝부분에서 다시 상기시킨다. 이것도 단순 반복이 아니다. 긴 맥락 끝에서 모델이 지금 당장 해야 하는 일을 다시 좁혀주는 장치다. 사람에게도 긴 설명 끝에는 "그래서 이번에 필요한 건 이것"이라고 다시 말해야 한다.

마지막은 출력 형식이다.

실무에서는 좋은 답변보다 다룰 수 있는 답변이 중요할 때가 많다. 데이터베이스에 넣어야 한다면 JSON이어야 하고, 검수자가 봐야 한다면 짧은 요약과 판단 근거가 분리되어야 한다. 출력 형식을 정하지 않으면 모델은 친절한 문단을 만들어내지만, 시스템은 그 문단을 다시 사람이 정리해야 한다.

이 지점에서 프롬프트는 글쓰기가 아니라 인터페이스 설계가 된다.

모델에게 어떤 일을 시킬지 정하고, 필요한 자료를 정리하고, 판단 기준을 고정하고, 결과가 다음 시스템으로 넘어갈 수 있는 형식을 지정한다. 프롬프트는 사람이 모델에게 던지는 말이지만, 동시에 모델이 일할 수 있는 작은 작업장이다.

그래서 프롬프트를 잘 쓰는 사람은 미사여구를 많이 아는 사람이 아니다.

상황을 잘 쪼개는 사람이다. 규칙과 자료를 구분하고, 예외를 드러내고, 출력이 쓰일 곳을 먼저 생각하는 사람이다. 모델의 답변이 이상하면 "모델이 틀렸다"에서 멈추지 않고, 어떤 맥락이 비어 있었는지 본다.

에이전트 시대에는 이 감각이 더 중요해진다.

단발성 답변은 틀려도 다시 물으면 된다. 하지만 업무 흐름에 들어간 에이전트는 수십 번의 작은 판단을 이어서 한다. 처음 맥락이 흐리면 뒤의 실행도 계속 비뚤어진다. 반대로 맥락이 선명하면 모델은 더 오래, 더 안정적으로 움직인다.

좋은 프롬프트는 마법 문장이 아니다.

모델이 일할 수 있는 방을 정리하는 일이다.

자료는 어디에 있고, 규칙은 무엇이며, 판단 기준은 어디까지이고, 결과는 어떤 형태로 나가야 하는가. 이 네 가지가 정리되면 프롬프트는 짧아도 강해진다. 정리되지 않으면 길어도 약하다.