왜 좋은 프롬프트만으로는 부족한가

AI를 처음 써 본 사람은 종종 비슷한 경험을 한다. 어떤 날은 정말 똑똑해 보인다. 질문 한 줄만 잘 던졌는데도 보고서를 정리하고, 메일 초안을 쓰고, 회의 내용을 깔끔하게 요약한다. 그래서 금세 이런 믿음이 생긴다. 결국 중요한 것은 프롬프트를 얼마나 잘 쓰느냐는 믿음이다.

물론 절반은 맞다. 좋은 프롬프트는 분명 도움이 된다. 하지만 실무에 들어가면 곧 한계를 만난다. 같은 질문인데도 답이 들쭉날쭉하고, 이전 대화를 반영하지 못하며, 회사 문서를 참고해야 할 때 엉뚱한 내용을 말한다. 어떤 경우에는 규정을 알려 줬는데도 지키지 않고, 도구를 연결해 두었는데도 써야 할 순간에 쓰지 않는다.

이때 많은 사람은 모델이 멍청하다거나, 프롬프트를 더 세련되게 쓰면 해결될 거라고 생각한다. 그러나 현대 AI 시스템의 실패는 단순히 문장력이 부족해서 생기지 않는다. 더 자주 문제를 일으키는 것은 모델이 그 순간 실제로 보고 있는 정보의 구조, 즉 입력 환경이다.

이 장의 목적은 간단하다. AI의 성패를 더 이상 "질문을 잘 썼는가"만으로 보지 않고, "AI가 어떤 맥락 속에서 일하고 있는가"로 바라보는 출발점을 만드는 것이다.

프롬프트 만능론이 통하지 않는 순간

프롬프트 엔지니어링이 주목받은 데에는 이유가 있다. 초기 생성형 AI 사용 경험에서 가장 손에 잡히는 조작 수단이 프롬프트였기 때문이다. 사람은 문장을 바꾸며 결과가 달라지는 것을 쉽게 확인할 수 있다. "친절하게 답해 줘"를 넣으면 톤이 달라지고, "표로 정리해 줘"를 넣으면 형식이 바뀐다. 눈앞에서 바로 효과가 보이니, 프롬프트는 AI를 다루는 핵심 기술처럼 느껴진다.

하지만 실제 업무는 한 번의 질문으로 끝나지 않는다. 고객지원 봇은 회사 정책을 알아야 하고, 문서 작성 에이전트는 참고 자료와 브랜드 톤을 지켜야 하며, 일정 관리 비서는 사용자의 선호와 캘린더 상태를 함께 고려해야 한다. 코딩 에이전트는 저장소 구조, 기존 코드 스타일, 테스트 실패 로그까지 이해해야 제대로 움직인다.

이때 프롬프트만 잘 쓰는 방식은 곧 벽에 부딪힌다. 이유는 단순하다. 모델이 답을 만들 때 참고해야 할 것이 이미 너무 많아졌기 때문이다. 해야 할 일은 단지 문장을 예쁘게 쓰는 것이 아니라, 무엇을 보여 주고 무엇을 숨기며 무엇을 먼저 읽게 할지 설계하는 일이 된다.

좋은 프롬프트는 요리로 치면 양념에 가깝다. 중요하다. 하지만 재료가 없거나, 상한 재료가 섞였거나, 조리 순서가 뒤죽박죽이면 양념만으로는 음식이 살아나지 않는다. 현대 AI 시스템도 마찬가지다. 프롬프트는 중요하지만, 그것만으로 전체 품질을 설명할 수는 없다.

모델은 의도를 읽지 않고 입력을 읽는다

사람끼리 대화할 때는 빈칸을 잘 메운다. 상대가 말을 조금 어색하게 해도 표정, 상황, 관계, 이전 맥락을 보고 의도를 추측한다. 하지만 AI 모델은 인간처럼 눈치를 보는 존재가 아니다. 모델은 기본적으로 입력된 것을 바탕으로 다음 출력을 만든다. 사용자의 진짜 의도, 조직의 숨은 규칙, 말하지 않은 전제는 자동으로 알아채지 못한다.

예를 들어 사용자가 이렇게 요청했다고 해 보자.

"지난달 회의 내용을 바탕으로 이번 분기 실행안을 정리해 줘."

사람 동료라면 "지난달 회의"가 어떤 회의인지 대충 알 수도 있다. 하지만 모델은 회의록을 실제로 받지 못했다면 알 수 없다. 사용자는 머릿속에서 분명한 장면을 떠올리며 말하지만, 모델은 그 장면을 보지 못한다. 결국 그 빈자리를 그럴듯한 일반론으로 채우게 된다.

이 점이 중요한 이유는, 많은 실패가 여기서 출발하기 때문이다. 사용자는 "내가 원하는 걸 충분히 말했어"라고 느끼지만, 모델 입장에서는 핵심 정보가 빠져 있는 경우가 많다. 반대로 너무 많은 정보를 한꺼번에 넣어도 문제가 생긴다. 중요한 규칙이 사소한 문장들 사이에 묻혀 버리기 때문이다.

즉, 모델은 의도를 읽는 존재가 아니라 주어진 컨텍스트 안에서 패턴을 계산하는 존재다. 이 사실을 받아들이는 순간, 질문은 달라진다.

"어떻게 더 똑똑하게 말할까?"보다 먼저 물어야 할 것은 이것이다.

"모델이 지금 답을 만들기 위해 꼭 봐야 할 정보가 실제로 들어가 있는가?"

프롬프트 하나가 아니라 입력의 층이 함께 작동한다

실무에서 AI가 받는 입력은 보통 한 줄짜리 프롬프트가 아니다. 여러 층의 정보가 동시에 들어온다. 겉으로 보기에는 사용자가 질문 한 번 던진 것 같아도, 내부에서는 다양한 재료가 합쳐져 하나의 작업 환경이 만들어진다.

대표적으로 다음과 같은 요소들이 있다.

• 시스템 지시문: AI의 역할, 목표, 금지사항, 말투, 안전 규칙처럼 기본 행동 기준을 정한다.

• 사용자 프롬프트: 지금 사용자가 당장 해결하고 싶은 요청이다.

• 대화 기록: 앞에서 무슨 이야기를 했는지, 어떤 결정을 내렸는지 보여 준다.

• 첨부 파일과 문서: 회의록, 정책 문서, 보고서, 코드, 표 데이터처럼 구체적 근거를 제공한다.

• 검색 결과: 외부나 내부 지식 저장소에서 가져온 최신 정보나 관련 자료다.

• 도구 응답: 캘린더 조회 결과, 데이터베이스 질의 결과, 계산 결과, API 응답처럼 모델 바깥에서 얻은 사실이다.

중요한 것은 이 요소들이 서로 다른 역할을 한다는 점이다. 시스템 지시문은 행동의 경계를 정하고, 사용자 프롬프트는 현재 과제를 정의하며, 대화 기록은 연속성을 제공한다. 문서는 근거를 주고, 검색 결과는 부족한 지식을 보충하며, 도구 응답은 확인된 사실을 넣어 준다.

따라서 "프롬프트를 잘 쓴다"는 말만으로는 충분하지 않다. 실제로는 어떤 층의 정보를 어떤 순서와 형식으로 조합할 것인가가 더 중요해진다. 같은 모델을 써도 시스템 지시문이 모호하면 결과가 흔들리고, 검색 결과가 부정확하면 답도 흔들린다. 대화 기록이 길게 누적되어 앞선 실수가 남아 있으면 그 실수가 계속 이어질 수도 있다.

결국 모델의 출력은 문장 하나의 결과가 아니라, 입력 전체 설계의 결과다.

같은 요청인데 결과가 달라지는 이유

사람들이 AI를 불안정하다고 느끼는 대표적 이유는 같은 요청에도 결과가 달라 보이기 때문이다. 그런데 이 현상을 자세히 보면, 모델이 변덕을 부린다기보다 들어간 맥락이 조금씩 달랐기 때문인 경우가 많다.

예를 들어 같은 "고객 환불 정책을 요약해 달라"는 요청도 상황에 따라 완전히 다른 결과가 나온다. 최신 정책 문서가 들어가면 정확한 요약이 나온다. 하지만 오래된 PDF만 붙어 있으면 이미 폐기된 규정을 말할 수 있다. 대화 앞부분에서 "우리는 예외 환불을 원칙적으로 금지한다"는 문장이 있었는데 뒤에서는 "VIP 고객은 예외 처리 가능"이라는 운영 메모가 추가되면, 어떤 정보를 더 강하게 따르느냐에 따라 답이 달라질 수 있다.

여기서 핵심은 모델이 마술을 부리는 것이 아니라는 점이다. 모델은 주어진 단서 사이에서 가장 그럴듯한 출력을 만들 뿐이다. 문제는 우리가 종종 그 단서들의 상태를 제대로 관리하지 않는다는 데 있다.

그래서 실무에서는 프롬프트를 손보기 전에 먼저 물어봐야 한다.

이 답변은 정말 프롬프트가 나빠서 틀린 것인가? 아니면 최신 문서가 빠졌는가? 이전 대화의 잡음이 너무 많았는가? 출력 형식이 불분명했는가? 도구 결과를 다시 컨텍스트에 넣지 않았는가?

이 질문이 바로 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로 넘어가는 문이다.

정보가 없을 때 AI는 침묵하지 않고 채워 넣는다

초보 사용자가 AI를 가장 쉽게 오해하는 지점은 여기다. AI가 모르는 것을 모른다고 말할 것이라고 기대하는 것이다. 물론 잘 설계하면 그렇게 만들 수 있다. 하지만 기본적으로 모델은 입력을 보고 가장 가능성 높은 다음 문장을 이어 가려는 성질이 강하다. 빈칸이 있으면 멈추기보다 채워 넣는다.

그래서 컨텍스트가 부족하면 두 가지 일이 자주 벌어진다. 하나는 일반론으로 얼버무리는 것이다. 예를 들어 회사 내부 문서를 바탕으로 답해야 하는데 문서가 없으면, 업계에서 흔히 볼 수 있는 상식적인 대답을 내놓는다. 읽는 사람은 그럴듯하다고 느끼지만, 정작 우리 조직의 실제 규정과는 다를 수 있다.

다른 하나는 존재하지 않는 세부사항을 만들어 내는 것이다. 회의에 참석하지도 않았고 첨부 자료도 없는데, 마치 본 것처럼 프로젝트 우선순위나 일정까지 단정해서 적는 식이다. 사람은 자신 있게 말하는 문장을 신뢰하기 쉽기 때문에 이 문제는 더 위험하다.

여기서 중요한 교훈이 나온다. AI의 자신감은 지식의 증거가 아니다. 유창함은 이해의 증거가 아니다. 답변이 자연스럽다고 해서 충분한 근거 위에 서 있다는 뜻은 아니다.

따라서 실무에서 필요한 것은 "더 멋지게 답하게 만들기"보다 "모를 때는 모른다고 하게 만들기", "근거가 없으면 추정이라고 표시하게 만들기", "필요한 문서가 없으면 먼저 요청하게 만들기" 같은 설계다. 다시 말해, 문제는 문체가 아니라 정보 공급 방식이다.

좋은 프롬프트가 오히려 문제를 가릴 때

흥미로운 점은, 프롬프트 실력이 좋을수록 오히려 문제를 늦게 발견할 수도 있다는 것이다. 능숙한 사용자는 모델이 얼버무리지 않도록 질문을 매끈하게 다듬는다. 출력 형식도 잘 지정하고, 어조도 안정시킨다. 그러면 결과물은 더 그럴듯해진다.

하지만 겉모습이 좋아졌다고 해서 기반이 튼튼해진 것은 아니다. 최신 데이터가 빠진 상태에서 멋진 보고서 형식으로 잘못된 결론을 정리하면, 오히려 더 위험해진다. 잘못된 답이 어설프게 보이면 사람이 경계라도 하지만, 아주 잘 정돈된 문장으로 나오면 검토 없이 넘어가기 쉽다.

즉, 좋은 프롬프트는 때때로 결과의 품질을 높이는 동시에 오류를 숨기는 화장 기술이 될 수 있다. 그래서 실무에서는 말투와 형식의 개선만으로 만족하면 안 된다. 반드시 물어야 한다. 이 답은 무엇을 근거로 만들어졌는가? 어떤 문서를 봤는가? 어느 도구 결과를 사용했는가? 빠진 정보는 없는가?

프롬프트 엔지니어링이 출력의 모양을 다듬는 기술이라면, 컨텍스트를 다루는 일은 출력이 서 있는 바닥을 점검하는 일에 가깝다.

이제는 질문을 잘하는 사람보다 환경을 설계하는 사람이 필요하다

오늘날의 AI 활용은 점점 시스템화되고 있다. 한 번 묻고 한 번 답하는 단순한 사용을 넘어, 검색이 붙고, 메모리가 붙고, 외부 도구가 붙고, 여러 단계의 워크플로가 이어진다. 이 구조에서는 뛰어난 프롬프트 작성자보다 입력 환경을 설계하는 사람이 더 큰 차이를 만든다.

예를 들어 문서 작성 에이전트를 만든다고 해 보자. 정말 중요한 것은 "초안을 써 줘"라는 한 줄이 아니다. 누가 독자인지, 어떤 브랜드 톤을 따라야 하는지, 반드시 참고해야 할 문서가 무엇인지, 초안 뒤에 비평 단계가 있는지, 수정 기준은 무엇인지, 최종 출력 형식은 어떻게 검증할 것인지를 함께 설계해야 한다.

고객지원 챗봇도 마찬가지다. 친절한 문장만으로는 좋은 챗봇이 되지 않는다. 답변 가능한 범위를 정하고, 정책 문서를 연결하고, 오래된 정책과 최신 정책이 충돌할 때 무엇을 우선할지 정하고, 확신이 낮을 때 사람에게 넘기는 규칙을 만들어야 한다.

이 일은 더 이상 단순한 프롬프트 작성이 아니다. AI가 어떤 정보 세계 속에서 일할지 정하는 일이다. 그래서 앞으로 중요한 역량은 "멋진 질문 만들기"에서 "일 잘하는 입력 환경 만들기"로 이동한다.

프롬프트에서 컨텍스트로 시선을 옮겨야 하는 이유

이 장의 핵심을 한 문장으로 줄이면 이렇다.

AI의 품질은 프롬프트 한 줄이 아니라, 모델이 일하는 전체 맥락에 의해 결정된다.

좋은 프롬프트는 필요하다. 그러나 그것만으로는 부족하다. 현대 AI 시스템은 시스템 지시문, 사용자 요청, 대화 기록, 문서, 검색 결과, 도구 응답, 메모리 같은 여러 요소가 함께 결과를 만든다. 실패의 원인도 그래서 더 복합적이다. 문장이 어설퍼서가 아니라, 필요한 정보가 없어서 실패하기도 하고, 너무 많은 정보가 들어가서 실패하기도 하며, 서로 충돌하는 지시 때문에 실패하기도 한다.

이 관점을 받아들이면 AI를 다루는 태도도 달라진다. 답이 이상할 때 무작정 프롬프트만 다시 쓰지 않게 된다. 먼저 입력 환경을 점검하게 된다. 무엇이 빠졌는지, 무엇이 과한지, 무엇이 충돌하는지, 무엇이 오래되었는지 살펴보게 된다.

그 순간부터 우리는 단순히 AI에게 질문하는 사람이 아니라, AI가 제대로 일할 수 있는 작업 환경을 만드는 사람이 된다.

다음 장에서는 바로 그 관점을 더 분명하게 다룬다. 프롬프트 엔지니어링을 넘어, 왜 이제는 컨텍스트 엔지니어링이라는 이름이 필요해졌는지 살펴볼 것이다.