금요일 회의 직전, 팀장이 AI가 정리한 주간보고를 엽니다. “개발 진행 중, 테스트 진행 중, 일정 조정 검토.” 읽기는 편합니다. 그런데 팀장이 결정해야 할 질문은 남아 있습니다. 어느 일정이 얼마나 밀렸는지, 원인은 확인됐는지, 인력을 옮길지 범위를 줄일지 판단할 근거가 보이지 않습니다.
설명용 가상 장면입니다. 여기서 AI의 문장력이 부족했다고만 진단하면 지시를 더 세련되게 쓰는 데 시간을 쓰게 됩니다. 먼저 확인할 것은 그 보고서가 어떤 판단을 돕도록 요청됐는가입니다. 프롬프트 엔지니어링의 가치는 말의 기교뿐 아니라, 기대하는 결과를 모델이 수행할 수 있는 조건으로 표현하는 데 있습니다.
이 글에서는 공개 연구를 참고해 결과의 목적을 지시에 넣는 법과 같은 사례에서 효과를 비교하는 법을 살펴봅니다. 보고서 적용 예시는 가상이며 실제 개선 수치를 주장하지 않습니다.
01독자가 결정할 일을 정하면 정보의 순서가 달라집니다
요리사에게 “맛있게 만들어 주세요”라고만 주문하면 이동 중 먹을 도시락이 필요한 사람에게 접시 요리가 나올 수도 있습니다. 음식의 완성도와 사용 목적의 일치는 서로 다른 문제입니다. “이동 중 먹을 한 끼”라고 알려 주면 용기, 분량, 먹는 방식이 달라집니다. 프롬프트를 주문서에 비유하는 이유입니다.
보고서에서도 같은 진행 기록이 독자에 따라 다른 결과가 됩니다. 실무자는 내일 할 작업과 막힌 일을 먼저 알아야 합니다. 팀장은 일정 조정의 선택지를 먼저 알아야 합니다. “빠짐없이 요약해 달라”는 요청은 정보의 포괄성을 요구하지만 어떤 내용을 앞에 둘지까지 정해 주지는 않습니다.
앞의 가상 장면에서 바꿔 볼 지시는 다음과 같습니다.
금요일 회의에서 팀장이 일정 조정을 결정할 수 있도록 보고서를 작성해 주세요. 승인 계획과 이번 주 기록의 차이를 먼저 정리하고, 확인된 지연 근거와 결정할 선택지를 연결해 주세요. 원인이 확인되지 않은 항목은 미확인으로 구분해 주세요.
같은 가상 기록을 어떻게 구성할지 기대 결과도 그려 볼 수 있습니다. 아래는 모델을 실행한 결과가 아니라 지시의 차이를 설명하는 필자의 예시입니다. 기록에는 “계획: 금요일 테스트 종료 / 현황: 테스트 미완료 / 원인 메모 없음”이 있다고 가정합니다.
작업 목록 중심: 테스트 진행 중. 일정 조정 검토.
판단 중심: 금요일 종료 계획과 달리 테스트가 미완료입니다. 원인은 미확인입니다. 일정 조정 여부를 결정하기 전 담당자에게 남은 작업과 지연 근거를 확인해야 합니다.
뒤의 예시가 보여 주는 차이는 계획과 현재의 차이, 모르는 것, 결정 전에 확인할 것을 연결했다는 점입니다. 실제 AI 결과가 이 기대를 충족하는지는 뒤에서 설명할 비교로 확인해야 합니다.
이 문장은 네 가지 조건을 전달합니다. 누가 사용할지, 어떤 판단을 할지, 무슨 근거를 쓸지, 확인되지 않은 내용을 어떻게 다룰지입니다. “좋은 보고서”라는 모호한 표현을 수행 가능한 요구로 풀어 쓴 것입니다. 세부 항목을 늘리는 이유도 해당 판단을 돕기 위해서여야 합니다.
요청의 조건이 충돌할 때는 우선순위도 필요합니다. 예를 들어 “모든 상세 내용을 넣고 한 페이지로 작성하라”는 지시는 기록이 많을 때 동시에 지키기 어렵습니다. 결정할 쟁점은 본문에 두고 상세 기록은 별도로 연결할지, 어느 항목을 줄여도 되는지 정해야 합니다. 이 선택은 모델이 대신 추측하기보다 업무 담당자가 결정하는 편이 명확합니다.
02예시는 기대를 보여주지만 사실의 근거와는 역할이 다릅니다
좋은 보고서 한 건을 보여주는 방법은 “쟁점을 먼저 쓴다”는 말을 구체화할 수 있습니다. 어떤 수준으로 요약하고, 근거와 선택지를 어떻게 연결하는지 예시에서 드러나기 때문입니다. 그러나 예시에는 따라야 할 구조와 가져오면 안 되는 사실이 함께 들어 있습니다.
지난주 보고서를 예시로 준 경우를 생각해 봅니다. 문체와 구성은 참고할 수 있지만 지난주 진척률과 지연 원인을 이번 주 보고서에 복사하면 틀립니다. 따라서 예시를 줄 때에도 “구성과 표현의 참고용이며 현재 사실은 이번 주 기록을 사용한다”는 역할을 구분해야 합니다. 지시를 쓰는 일과 모델에게 보여줄 정보를 고르는 일이 만나는 지점입니다.
2022년 Chain-of-Thought 논문은 중간 추론을 포함한 예시가 당시 일부 추론 과제에 도움이 됐음을 보여줬습니다. 이는 예시 설계가 결과를 바꿀 수 있다는 연구 근거입니다. 다만 그 연구의 모델과 과제를 모든 최신 모델의 기본 사용법으로 일반화할 수는 없습니다. Chain-of-Thought 논문
업무에 적용할 때 중요한 것은 검토 가능한 결과입니다. 보고서의 일정 차이를 계산했다면 기준 날짜와 입력 수치, 계산 결과를 확인할 수 있어야 합니다. 근거를 찾았다면 실제 자료로 돌아갈 수 있어야 합니다. 설명이 길다는 이유만으로 판단 과정이나 사실이 정확하다고 받아들이지는 않습니다.
예시는 다양성도 살펴야 합니다. 매번 지연이 발생한 보고서만 보여주면, 지연이 없는 주에도 쟁점을 억지로 찾는 결과가 나오는지 확인해야 합니다. 원인이 미확인인 사례, 일정이 정상인 사례, 자료가 부족한 사례에서 기대하는 처리가 무엇인지 보여주면 예시의 목적이 더 분명해집니다. 이는 앞선 연구를 가상 업무에 적용한 설계 제안입니다.
03프롬프트를 바꾸면 무엇이 좋아졌는지 비교할 수 있어야 합니다
2023년 DSPy 논문은 언어모델 작업을 모듈로 나누고, 각 작업의 목표와 입력·출력을 정한 뒤 평가 기준에 맞게 지시와 예시를 고치는 접근을 제시했습니다. 여기서 참고할 관점은 입력 설계와 측정을 연결할 수 있다는 점입니다. 이 글은 현행 도구의 사용법이나 성능 수치를 설명하지 않습니다. DSPy 논문
가상 보고서 업무에서는 기존 지시와 목적을 구체화한 지시에 같은 기록을 주어 비교할 수 있습니다. 먼저 성공 기준을 정해야 합니다. 결정할 일정 쟁점이 포함됐는가, 수치가 원자료와 맞는가, 근거 없는 원인이 추가되지 않았는가, 사람이 실제로 사용할 수 있는가를 구분해 봅니다. 사람이 다시 고친 사실 오류와 누락, 수정에 쓴 시간도 기록하면 수정 부담을 비교할 근거가 됩니다.
읽기 쉬움이 좋아져도 사실 오류가 늘면 전체 개선이라고 판단하기 어렵습니다. 반대로 문장은 조금 투박해도 중요한 누락을 줄이고 수정 부담을 낮췄다면 그 효과를 볼 수 있습니다. 평가 기준이 결과의 쓰임을 반영해야 프롬프트의 변경 방향도 명확해집니다.
비교할 때에는 모델과 자료, 사용 가능한 도구 같은 조건을 가능한 범위에서 맞춥니다. 지시와 모델을 동시에 바꾸면 무엇 때문에 결과가 달라졌는지 분리하기 어려워집니다. 같은 조건에서도 출력이 달라질 수 있으므로, 중요한 업무라면 필요한 범위에서 반복해 결과가 얼마나 흔들리는지도 확인해야 합니다. 여기서 고정된 반복 횟수를 제시하지 않는 이유는 업무의 오류 비용과 판단 목적이 다르기 때문입니다.
개선에 사용한 사례와 확인용 사례를 나누는 것도 도움이 됩니다. 특정 보고서 몇 건을 보며 지시를 수정하다 보면 그 사례에만 맞는 조건을 과하게 넣을 수 있습니다. 지시를 고치는 데 쓰지 않은 기록에서도 중요한 쟁점과 사실을 잘 다루는지 보아야 합니다. 실패한 결과를 지우는 대신 어떤 조건에서 실패했는지 남기면 다음 수정의 근거가 됩니다.
04지시가 분명해져도 없는 정보와 권한은 생기지 않습니다
목적을 구체화한 뒤에도 원인을 찾을 수 없다면 정보의 문제를 살펴야 합니다. 이번 주 작업 기록에 지연 원인이 없는데 “원인을 반드시 써라”라고 요구하면 확인되지 않은 설명을 만들 여지가 생깁니다. 이 경우에는 부족한 자료를 조회할 수 있는지, 담당자에게 확인해야 하는지, 미확인으로 남길지를 정해야 합니다.
도구의 문제도 비슷합니다. 모델에게 최신 현황을 확인하라고 말해도 현황 시스템에 접근할 수 없으면 지시만으로 현재 상태를 알 수 없습니다. 접근할 수 있지만 조회 응답이 실패했다면 자료가 없는 것과 구분해야 합니다. 이런 오류를 프롬프트 문장만 계속 늘려서 해결하려 하면 실제 원인을 놓치기 쉽습니다.
지시를 자세히 쓰는 일에는 유지 비용도 있습니다. 요구가 많아질수록 조건 충돌과 예외를 점검해야 합니다. 보고서 하나의 문제를 해결하려고 조직의 모든 업무 규칙을 한 프롬프트에 넣으면 현재 작업의 우선순위가 흐려질 수 있습니다. 실패 사례에서 필요한 조건을 추가하고, 효과가 없는 조건은 정리하는 방식이 더 구체적인 출발점입니다.
05마치며: 좋은 지시는 결과를 쓸 판단과 연결됩니다
최근 AI에게 받은 결과 하나를 골라 누가 어떤 판단에 쓸 것이었는지 한 문장으로 적어 보시길 권합니다. 그 문장을 지시에 넣은 뒤 같은 자료로 비교하면 바뀌어야 할 결과가 구체적으로 보입니다. 문장의 매끄러움과 함께 필요한 쟁점, 사실의 일치, 사람의 수정 부담을 확인합니다.
프롬프트는 여전히 AI 엔지니어링의 중요한 부분입니다. 다만 역할은 모든 문제를 문장으로 해결하는 데 있지 않습니다. 기대하는 결과를 분명히 표현하고, 그 기대를 실제 사례에서 확인하며, 지시 밖의 정보와 실행 조건이 부족한 곳을 찾아 다음 설계로 연결하는 데 있습니다.
다음 편에서는 자료가 충분해 보여도 답이 틀리는 이유를 컨텍스트의 선택과 갱신에서 살펴봅니다.
이 글은 AI의 도움을 받아 작성했습니다.