GPT 5.5와 Claude Opus 4.7이 등장하면서 프롬프트 작성 방식도 예전과 달라졌습니다. 이 글에서는 최신 모델에서 긴 지시가 왜 오히려 방해가 될 수 있는지, 결과 중심 요청이 왜 중요한지, 글쓰기·코드·이미지 작업에서 어떻게 프롬프트를 바꿔야 하는지 설명해드리겠습니다.
결과 중심 프롬프트
목표 우선 작성
GPT 5.5와 Claude Opus 4.7 같은 최신 모델에서는 프롬프트를 길게 늘리는 것보다 원하는 결과를 분명하게 적는 방식이 더 잘 맞습니다. 예전에는 모델이 중간에 방향을 잃는 일이 많아서 사고 순서, 역할, 말투, 출력 방식까지 촘촘하게 넣는 경우가 많았습니다. 그런데 최신 모델은 내부 판단 능력이 강해져서 사람이 사고 과정을 지나치게 잡아주면 오히려 답변이 답답해질 때가 있습니다.
기준 중심 요청
요즘 프롬프트에서 중요한 건 “어떻게 생각할지”가 아니라 “무엇을 만들어야 하는지”입니다. 예를 들어 블로그 글을 요청한다면 먼저 주제, 독자, 분량, 말투, 제외할 표현, 반드시 담을 내용을 알려주는 편이 낫습니다. 직접 써보면 장황하게 역할극을 시키는 문장보다 “초보자가 이해할 수 있게, 실제 사용 사례를 섞어서, 과장 없이 작성해줘”처럼 요구 기준을 바로 넣었을 때 결과물이 더 깔끔하게 나오는 경우가 많았습니다.
짧은 요청 장점
좋게 보였던 부분은 불필요한 말이 줄어든다는 점입니다. 예전에는 프롬프트가 길어질수록 모델이 이것저것 붙여서 답변을 크게 부풀리는 일이 많았는데, 최신 모델은 짧고 분명한 요청에도 꽤 안정적으로 반응합니다. 특히 글쓰기, 코드 검토, 기획안 작성처럼 목표가 뚜렷한 작업에서는 핵심 조건만 줘도 예상보다 완성도 있는 답을 내는 편입니다.
짧은 요청 단점
반대로 아쉬운 부분도 있습니다. 요청을 너무 짧게만 쓰면 모델이 알아서 잘 채워줄 거라고 기대하게 되는데, 최신 모델은 사용자가 적은 조건만 깔끔하게 따르려는 경향이 강합니다. 그래서 “자연스럽게 써줘”라고만 쓰면 원하는 말투와 다른 결과가 나올 수 있고, “예시도 넣어줘”라고 따로 적지 않으면 사례 없이 설명만 나오는 경우도 있습니다.
절차 지시 축소
오래된 문장 한계
과거 프롬프트에서는 모델에게 사고 과정을 길게 요구하는 문장이 자주 쓰였습니다. 천천히 판단하라는 식의 표현이나 순서대로 고민하라는 식의 문장이 대표적입니다. 당시에는 그런 문장이 모델의 답변 품질을 올리는 데 도움이 되기도 했습니다. 하지만 GPT 5.5와 Claude Opus 4.7 같은 모델에서는 이런 문장이 항상 이득이 되지는 않습니다.
내부 추론 강화
최신 모델은 이미 내부에서 복잡한 문제를 여러 단계로 나눠 판단합니다. 사용자가 그 과정을 문장으로 계속 지정하면 모델 입장에서는 원래 잘하던 판단 위에 불필요한 지시를 하나 더 받는 셈입니다. 실제로 긴 분석 문구를 넣었을 때보다 “결과물 기준을 먼저 맞추고, 부족한 부분만 보완해줘”라고 요청했을 때 답변이 더 담백하고 실전에 쓰기 좋았습니다.
과정 노출 감소
예전에는 모델이 어떤 생각을 했는지 길게 보여주도록 요청하는 경우가 많았습니다. 하지만 지금은 중간 사고를 길게 보여달라고 하기보다 최종 답변, 검증 기준, 오류 발생 시 보고 방식에 집중하는 편이 낫습니다. 특히 코드 작업에서는 사고 설명을 길게 받는 것보다 수정 파일, 변경 이유, 테스트 결과만 받는 편이 훨씬 유용했습니다.
API 설정 중요성
추론 강도 조절
GPT 5.5는 추론 강도를 낮음, 중간, 높음처럼 설정하는 방식으로 다룰 수 있다는 점이 중요합니다. 어려운 작업에서 답변이 얕게 나온다면 프롬프트를 더 길게 쓰기보다 추론 강도를 올리는 접근이 먼저입니다. 반대로 단순한 요약, 제목 작성, 짧은 문장 변환에는 높은 설정이 꼭 필요하지 않습니다.
비용 관리 관점
실제로 작업을 나눠서 해보면 모든 요청에 높은 추론 강도를 쓰는 건 낭비가 될 수 있습니다. 블로그 제목 후보를 뽑거나 문장을 부드럽게 바꾸는 정도는 중간 설정만으로도 충분한 경우가 많았습니다. 좋았던 점은 작업 난도에 맞춰 비용을 조절할 수 있다는 점이고, 불편했던 점은 처음에는 어떤 작업에 어느 정도 설정이 맞는지 몇 번 테스트해봐야 한다는 점입니다.
Claude 설정 차이
Claude Opus 4.7은 적응형 사고와 effort 설정이 핵심으로 다뤄집니다. 복잡한 에이전트 작업이나 코드 수정처럼 여러 판단이 이어지는 요청에서는 effort를 높게 두는 편이 낫고, 간단한 문장 작업에서는 낮게 둬도 충분합니다. 여기서 중요한 건 프롬프트 문장으로 모델을 몰아붙이기보다 설정값과 요청 내용을 함께 맞추는 것입니다.
어조 설정 필요성
기본 답변 변화
최신 모델의 기본 답변은 예전보다 훨씬 건조해졌습니다. 따뜻한 말, 가벼운 리액션, 친근한 문장이 자동으로 붙는 경우가 줄고, 곧바로 핵심만 말하는 답변이 많아졌습니다. 개발 자동화나 내부 업무용 도구에서는 이런 변화가 오히려 좋습니다. 군더더기 없이 필요한 말만 나오기 때문입니다.
사용자 서비스 문제
하지만 고객 상담 챗봇이나 일반 사용자를 상대하는 서비스라면 이야기가 달라집니다. 아무 지침 없이 쓰면 답은 맞는데 말투가 차갑게 느껴질 수 있습니다. 실제로 문의 응대 문장을 만들어보면 “환불은 불가합니다”처럼 딱 잘라 말하는 답이 나오기도 합니다. 내용은 맞아도 사용자 입장에서는 불친절하게 보일 수 있습니다.
말투 기준 추가
그래서 시스템 프롬프트나 기본 요청에는 말투 기준을 따로 넣는 것이 좋습니다. 예를 들어 “짧게 답하되 무례하게 들리지 않게 작성”, “전문 용어는 줄이고 일반 사용자에게 설명”, “거절 답변에는 대안 하나를 함께 제시”처럼 적으면 답변 품질이 훨씬 안정됩니다. 좋았던 점은 이런 기준을 한 번 넣어두면 전체 답변의 분위기가 꽤 일정하게 유지된다는 점입니다.
도구 호출 조건
강한 명령 부작용
이전 모델에서는 도구 사용을 확실히 시키기 위해 강한 명령문을 넣는 경우가 많았습니다. 문제는 최신 모델이 이런 지시를 너무 잘 따른다는 점입니다. “항상 검색 도구 사용”처럼 적어두면 굳이 검색이 필요 없는 질문에도 도구를 호출할 수 있습니다. 결과적으로 속도는 느려지고 비용은 늘어나며, 답변도 불필요하게 복잡해집니다.
조건형 문장 필요
이제는 도구 사용 지시를 조건형으로 쓰는 편이 낫습니다. 예를 들어 최신 가격, 일정, 법률, 실시간 데이터처럼 바뀔 수 있는 정보가 필요할 때만 검색하도록 적는 방식입니다. 코드 실행 도구도 마찬가지입니다. 계산이나 파일 생성이 필요한 경우에만 쓰라고 해야 모델이 상황을 보고 판단할 수 있습니다.
자동화 작업 예시
직접 자동화 프롬프트를 만들어보면 이 차이가 꽤 큽니다. “무조건 모든 도구를 확인하라”라고 쓰면 간단한 문장 수정에도 검색, 파일 확인, 계산 같은 불필요한 단계가 붙을 수 있습니다. 반면 “현재 정보가 필요한 경우에만 검색하고, 단순 문장 수정은 바로 처리”라고 적으면 답변 속도와 결과 품질이 더 좋아졌습니다.
GPT 5.5 활용 방식
에이전트 작업 강점
GPT 5.5는 단순한 대화형 모델이라기보다 여러 작업을 이어서 처리하는 에이전트형 모델에 가깝게 다루는 편이 좋습니다. 코드베이스 탐색, 여러 파일 수정, 테스트 확인, 문서 작성처럼 한 번에 끝나지 않는 작업에서 장점이 잘 나타납니다. 특히 길게 이어지는 대화에서 앞서 정한 조건을 비교적 오래 유지한다는 점이 인상적이었습니다.
계획 모드 필요
다만 적극성이 강하다는 점은 양날의 칼입니다. 코드 작업을 맡기면 도움이 되는 파일을 찾아 빠르게 고치는 장점이 있지만, 요청 범위를 넘어 주변 파일까지 손대는 경우도 생길 수 있습니다. 그래서 변경 전에는 먼저 구현 계획을 작성하게 하고, 사용자가 승인하기 전에는 실제 수정을 하지 않도록 제한하는 문장이 필요합니다.
승인 대기 문장
실무용 프롬프트에는 “수정 전 변경 대상 파일과 예상 변경 내용을 먼저 제시”, “승인 전에는 파일을 바꾸지 않기”, “요청 범위를 벗어난 변경은 따로 질문하기” 같은 문장을 넣는 것이 좋습니다. 이 방식은 조금 번거롭지만, 예상치 못한 수정으로 시간을 날리는 일을 줄여줍니다. 개인적으로 좋았던 부분은 작업 전 위험 지점을 먼저 볼 수 있다는 점이었습니다.
실패 보고 조건
GPT 5.5를 쓸 때 특히 중요한 건 실패 기준입니다. 불가능하거나 조건이 부족한 요청에서도 어떻게든 결과를 만들려고 할 수 있기 때문입니다. 그래서 “테스트가 실패하면 성공처럼 말하지 말고 실패 원인만 보고”, “추가 수정은 사용자 확인 후 진행”, “검증되지 않은 내용은 추정이라고 표시” 같은 문장이 필요합니다.
검증 가능한 성공
예를 들어 코드 수정 작업에서는 “테스트 전체 통과”, “빌드 오류 없음”, “기존 기능 유지”처럼 확인 가능한 성공 기준을 넣어야 합니다. 글쓰기 작업에서도 “금지어 미포함”, “외부 링크 없음”, “각 문단에 하위 소제목 포함”처럼 확인 기준을 넣으면 좋습니다. 이런 식으로 기준을 주면 모델이 결과물을 스스로 점검하기 쉬워집니다.
Claude Opus 4.7 활용 방식
API 변경 주의
Claude Opus 4.7은 성능이 강해졌다는 점만 보고 바로 교체하면 문제가 생길 수 있습니다. 기존에 쓰던 temperature, top p, top k 같은 파라미터가 더 이상 맞지 않는다면 API 호출에서 오류가 날 수 있습니다. 그래서 모델만 바꾸는 게 아니라 호출 방식까지 함께 점검해야 합니다.
프롬프트 제어 방식
Claude 쪽은 확률값으로 답변을 흔드는 방식보다 프롬프트 문장과 출력 형식으로 결과를 제어하는 쪽에 가깝습니다. 창의적인 글이 필요하면 “비유를 조금 넣고 문장을 부드럽게 작성”처럼 말로 요청하고, 엄격한 결과가 필요하면 항목명, 필수 필드, 제외할 값을 분명하게 적어야 합니다.
명시 지시 중요
Claude Opus 4.7은 사용자가 적은 지시를 매우 정확히 따르는 편입니다. 이건 좋은 점이면서 동시에 불편한 점입니다. 예를 들어 첫 번째 항목에만 적용한 서식 규칙을 전체 항목에도 당연히 적용할 거라고 기대하면 결과가 어긋날 수 있습니다. 모든 항목에 같은 규칙을 적용해야 한다면 그 말을 반드시 적어야 합니다.
작업 범위 표현
직접 문서 변환 작업을 시켜보는 상황을 가정하면 차이가 분명합니다. “첫 항목처럼 나머지도 바꿔줘”라고 쓰면 어느 정도는 맞지만, 세부 규칙이 빠질 수 있습니다. 반면 “모든 항목에 동일한 제목 길이, 같은 말투, 같은 출력 순서를 적용”이라고 쓰면 결과가 훨씬 일정해집니다. 이 부분은 좋았지만, 프롬프트를 대충 쓰면 생각보다 빠르게 티가 났습니다.
출력 형식 관리
JSON 응답 주의
최신 모델을 API에 연결해 쓰는 경우 출력 형식 관리는 매우 중요합니다. JSON 응답을 받아야 하는데 null 값이 들어가거나, 필드명이 바뀌거나, 설명 문장이 섞이면 바로 오류로 이어질 수 있습니다. GPT 5.5는 긴 작업에서도 금지 조건을 비교적 잘 유지하는 편이라 이런 파이프라인 작업에 유리합니다.
필드 기준 명확화
출력 형식이 중요한 작업에서는 “필수 필드”, “허용 값”, “금지 값”, “빈 값 처리 방식”을 반드시 적는 편이 좋습니다. 예를 들어 상품 데이터를 뽑는다면 이름, 가격, 설명, 상태처럼 필요한 필드를 먼저 정하고, 값이 없을 때는 null 대신 빈 문자열을 쓰라고 지정하는 식입니다.
문장 답변 구분
블로그나 문서 작성에서는 출력 형식이 더 느슨해도 되지만, 그래도 기준은 필요합니다. 제목은 하나만 제시할지, 소제목을 몇 개 넣을지, FAQ를 넣을지, 표를 쓸지 같은 부분을 미리 말해야 합니다. 이걸 빼면 모델은 자기가 보기 좋은 방식으로 답을 만들고, 사용자는 다시 수정 요청을 하게 됩니다.
이미지 프롬프트 변화
장황한 묘사 감소
이미지 제작 프롬프트에서도 변화는 비슷합니다. 예전에는 카메라 렌즈, 조명, 색상, 배경, 인물 포즈, 화풍을 한 문장에 길게 몰아넣는 방식이 많았습니다. 그런데 최신 이미지 모델에서는 너무 많은 수식어가 들어가면 오히려 핵심 장면이 잘 구현이 되지 않았습니다.
짧은 문장 예시
예전 방식이라면 “고품질, 초고해상도, 극사실주의, 영화 같은 조명, 정교한 배경, 세밀한 표정”처럼 표현을 많이 붙였습니다. 요즘 방식으로는 “1:1 포토그래피, 한국인 개발자가 노트북 앞에서 프롬프트를 수정하는 장면, 어두운 사무실, 모니터 불빛, 차분한 분위기” 정도가 더 낫습니다. 핵심 피사체와 장면만 또렷하게 주는 편이 결과가 더 잘 나왔습니다.
불필요한 수식 제거
좋았던 점은 이미지가 덜 산만해진다는 것입니다. 인물, 장소, 행동, 비율, 스타일만 분명히 주면 모델이 알아서 화면을 채웁니다. 아쉬운 점은 세부 연출을 빼면 생각보다 평범한 이미지가 나올 수 있다는 점입니다. 그래서 상업용 썸네일처럼 목적이 있는 이미지는 “상업용 텍스트 넣기”, “중앙 피사체”, “여백 충분”, “블로그 썸네일용” 같은 실전 조건을 추가하는 편이 좋습니다.
프롬프트 예시 비교
글쓰기 요청 이전
예전 방식의 글쓰기 프롬프트는 역할 부여와 사고 지시가 길게 붙는 경우가 많았습니다. “전문가처럼 분석하고 여러 단계를 거쳐 판단한 뒤 답변”처럼 쓰면 모델이 답변 앞부분에 설명을 길게 붙이고, 실제 본문보다 준비 문장이 많아지는 일이 자주 있었습니다. 최신 모델에서는 이런 표현이 꼭 필요하지 않습니다.
글쓰기 요청 현재
지금은 “주제는 프롬프트 작성법 변화, 대상은 AI 도구를 자주 쓰는 블로거, 말투는 자연스러운 존댓말, 외부 링크 없음, 장점과 단점을 사례에 섞어서 작성”처럼 바로 요청하는 편이 낫습니다. 이렇게 쓰면 모델이 목적을 더 빨리 파악하고 본문에 필요한 요소를 바로 반영합니다.
코드 요청 이전
코드 작업에서도 예전에는 “모든 파일을 꼼꼼히 읽고 가능한 모든 문제를 찾아서 수정”처럼 넓게 지시하는 경우가 많았습니다. 하지만 최신 모델에 이런 식으로 요청하면 손대지 않아도 될 파일까지 바꾸는 일이 생길 수 있습니다. 특히 운영 중인 사이트나 실제 서비스 코드라면 위험합니다.
코드 요청 현재
지금은 “로그인 버튼 클릭 오류만 확인, 관련 파일 후보를 먼저 제시, 수정 전 계획 작성, 승인 전 파일 변경 금지, 테스트 실패 시 중단 보고”처럼 범위를 좁히는 편이 안전합니다. 이 방식은 느려 보이지만 결과적으로 되돌릴 작업이 줄어듭니다. 실제 작업 상황에서는 이쪽이 훨씬 마음이 편했습니다.
실무 적용 기준
단순 작업 처리
짧은 요약, 문장 다듬기, 제목 후보 생성, 짧은 안내문 작성 같은 작업은 프롬프트를 길게 쓸 필요가 없습니다. 원하는 말투와 제외할 내용만 적어도 충분합니다. 오히려 긴 지시를 넣으면 모델이 불필요한 설명을 붙이거나 결과가 무거워질 수 있습니다.
복잡 작업 처리
반대로 코드 수정, API 이전, 여러 문서 비교, 자동화 설계처럼 실수가 큰 문제가 되는 작업은 짧은 프롬프트만으로 부족합니다. 이때는 목표, 범위, 중단 조건, 검증 기준을 모두 넣어야 합니다. 최신 모델이 똑똑해졌다고 해서 사용자 책임이 사라지는 건 아닙니다.
반복 작업 관리
블로그 글을 자주 쓰거나 비슷한 양식의 콘텐츠를 계속 만든다면 기본 프롬프트를 하나 만들어두는 것도 좋습니다. 다만 예전처럼 긴 역할극 문장을 넣기보다 “금지 표현”, “소제목 방식”, “문단마다 하위 소제목”, “외부 링크 제외”, “경험성 문장 포함”처럼 실제 결과에 영향을 주는 조건만 남기는 편이 낫습니다.
모델 선택 기준
GPT 5.5 적합 작업
GPT 5.5는 긴 대화, 코드 작업, 도구 사용, 여러 파일을 다루는 작업에 잘 맞습니다. 복잡한 요청을 여러 단계로 이어가는 능력이 좋고, 조건을 오래 붙잡는 힘도 강한 편입니다. 다만 너무 적극적으로 움직일 수 있으니 작업 전 계획과 승인 대기 조건을 넣는 것이 안전합니다.
Claude Opus 4.7 적합 작업
Claude Opus 4.7은 지시를 정확히 따르는 작업, 긴 문서 처리, 문체 유지, 세부 조건 반영에 잘 맞습니다. 특히 “이 항목은 이렇게, 저 항목은 저렇게”처럼 세밀한 요구가 있을 때 강점이 있습니다. 대신 알아서 확장해줄 거라고 기대하면 빠지는 부분이 생길 수 있으니 적용 범위를 분명하게 써야 합니다.
공통 활용 원칙
두 모델 모두 예전보다 훨씬 강해졌지만, 잘 쓰는 방법은 더 단순해졌습니다. 길게 가르치려고 하기보다 원하는 결과, 지켜야 할 조건, 실패했을 때의 처리 방식만 분명하게 주는 것이 좋습니다. 잘 쓴 프롬프트는 길이가 긴 문장이 아니라, 모델이 헷갈리지 않게 만드는 문장입니다.
결론
GPT 5.5와 Claude Opus 4.7을 제대로 쓰려면 예전처럼 프롬프트를 길게 늘리고 사고 과정을 일일이 지시하는 방식에서 벗어나는 것이 좋습니다. 이제는 모델에게 판단 방법을 가르치기보다 원하는 결과, 지켜야 할 조건, 실패했을 때 멈춰야 하는 기준을 분명하게 알려주는 쪽이 훨씬 실용적입니다. 실제로 사용해보면 짧고 명확한 요청이 더 빠르고 깔끔한 결과로 이어지는 경우가 많았고, 반대로 너무 강한 명령이나 과한 설명은 불필요한 답변, 원치 않는 도구 호출, 범위를 벗어난 작업으로 이어질 수 있었습니다. 결국 최신 모델 시대의 프롬프트는 많이 쓰는 것이 아니라 정확히 쓰는 것이 중요합니다.
FAQ
GPT 5.5와 Claude Opus 4.7에서는 긴 프롬프트가 필요 없나요?
긴 프롬프트가 무조건 나쁜 것은 아니지만, 예전처럼 역할 설명과 사고 과정을 길게 붙이는 방식은 효율이 떨어질 수 있습니다. 최신 모델은 이미 내부 판단 능력이 강하기 때문에 목표, 조건, 제외할 내용, 결과 기준을 짧고 분명하게 적는 편이 더 나은 결과로 이어질 때가 많습니다.
예전 프롬프트 방식이 왜 오히려 방해가 될 수 있나요?
예전 방식은 모델이 길을 잃지 않도록 세세하게 안내하는 데 목적이 있었습니다. 하지만 최신 모델은 스스로 판단하는 힘이 커졌기 때문에 사람이 너무 많은 절차를 지정하면 답변이 무거워지거나 불필요한 설명이 붙을 수 있습니다. 특히 코드 작업이나 자동화 작업에서는 과한 지시가 예상 밖의 행동으로 이어질 수 있습니다.
최신 모델에 프롬프트를 쓸 때 가장 먼저 적어야 할 것은 무엇인가요?
가장 먼저 적어야 할 것은 원하는 결과입니다. 예를 들어 글을 써야 한다면 주제, 독자, 말투, 분량, 반드시 넣을 내용, 빼야 할 표현을 먼저 알려주는 것이 좋습니다. 코드 작업이라면 수정 범위, 변경 전 보고 여부, 테스트 기준, 실패 시 중단 조건을 먼저 적는 편이 안전합니다.
GPT 5.5는 어떤 작업에 더 잘 맞나요?
GPT 5.5는 여러 단계가 이어지는 작업, 코드 수정, 파일 검토, 도구 사용, 긴 대화에서 조건을 유지해야 하는 작업에 잘 맞습니다. 다만 적극적으로 작업을 넓혀갈 수 있기 때문에 수정 전에 계획을 먼저 보여주게 하고, 승인 전에는 실제 변경을 하지 않도록 제한하는 문장을 넣는 것이 좋습니다.
Claude Opus 4.7은 어떤 작업에 더 유리한가요?
Claude Opus 4.7은 긴 문서 처리, 문체 유지, 세부 조건 반영, 항목별 규칙 적용 같은 작업에 강점이 있습니다. 다만 사용자가 적은 내용만 정확히 따르려는 성향이 강해서 “모든 항목에 같은 규칙 적용”처럼 적용 대상을 분명하게 적어야 원하는 결과가 안정적으로 나옵니다.
도구 사용 지시는 어떻게 적는 것이 좋나요?
도구 사용은 무조건 실행하라는 식보다 조건형으로 적는 것이 좋습니다. 예를 들어 최신 정보가 필요한 경우에만 검색하고, 단순 문장 수정은 바로 처리하라고 쓰는 방식입니다. 이렇게 해야 필요 없는 도구 호출을 줄이고 답변 속도와 비용을 함께 관리할 수 있습니다.
이미지 프롬프트도 짧게 쓰는 편이 좋은가요?
이미지 프롬프트도 핵심 장면을 짧고 분명하게 적는 편이 좋습니다. 인물, 장소, 행동, 분위기, 비율, 스타일을 먼저 잡고 불필요한 수식어는 줄이는 방식이 더 안정적입니다. 예를 들어 “1:1 포토그래피, 한국인 개발자가 노트북 앞에서 프롬프트를 수정하는 장면, 어두운 사무실, 모니터 불빛”처럼 쓰면 장면이 더 선명하게 잡힙니다.
최신 모델을 쓸 때 가장 조심해야 할 부분은 무엇인가요?
가장 조심해야 할 부분은 모델이 똑똑해졌다고 해서 모든 것을 알아서 잘 처리할 거라고 기대하는 것입니다. 목표가 모호하거나 성공 기준이 없으면 결과가 그럴듯해 보여도 실제로는 부족할 수 있습니다. 그래서 중요한 작업일수록 검증 기준, 중단 조건, 수정 범위를 꼭 함께 적어야 합니다.
