토큰 까먹는 나쁜 프롬프트 예시, 좋은 프롬프트 예시 (강수진 박사)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

토큰을 낭비하는 나쁜 프롬프트는 작업 범위를 열어 두고, 좋은 프롬프트는 결과물·자료·검증 범위·종료 조건을 구체적으로 정한다.

📌 핵심 요점

1. 목표와 실행 조건을 함께 적는다. 원하는 결과물과 분량을 먼저 제시하고, 어떤 상황에서 지침이나 문서를 적용할지 명시한다. 모든 수정에 모든 문서를 읽게 하는 지시는 반복 참조 비용을 키울 수 있다.
2. 스킬은 필요한 만큼만 읽고 호출한다. 이름과 설명으로 용도를 판단한 뒤 필요한 상세 자료를 추가로 읽도록 설계한다. 호출이 잦으면 목적을 좁히고, 사용하지 않을 조건도 적어 중복 호출을 줄인다.
3. 입력·답변·추론 토큰을 따로 관리한다. 관련 없는 자료와 반복 지시를 줄이고 답변 형식과 설명 분량을 지정한다. 발표자는 Low부터 시작해 작업 난도와 실패 경험에 따라 추론 수준을 높이는 개인 기준을 제안한다.
4. 검증 범위와 완료 조건으로 과잉 작업을 막는다. 대시보드 사례에서는 종료 조건이 없자 댓글·감정 분석까지 작업이 확장됐다. 웹페이지 재현에서는 시각적 일치, 인터랙션, 기능, 기기별 화면, 한국어 표현, 빌드·실행 오류로 검증 항목을 한정했다.
5. 많은 토큰과 긴 대화가 품질을 보장하지 않는다. 울트라 제작 사례는 출력 토큰 12.2만과 반복 검증에도 결과물이 만족스럽지 않았다. 장기 작업은 체크포인트로 기록하고, 맥락을 정리할 때는 중요한 요구사항과 원문의 의미를 보존하는 접근을 권한다.

🧩 배경과 문제 정의

• 성능이 좋아진 AI 모델도 모호한 작업 지시, 반복적인 문서 참조, 불필요한 스킬 호출 때문에 토큰을 과도하게 소비할 수 있다.
• 프롬프트에는 목표뿐 아니라 지침의 적용 시점, 필요한 자료, 결과물의 분량, 검증 범위와 종료 조건까지 구체적으로 담아야 한다.
• 스킬과 에이전트의 자율성을 넓히면 작업이 확장되고, 승인 절차를 지나치게 강화하면 확인 질문과 검증 때문에 시간이 늘어난다.
• 실제 제작 사례에서는 추론 수준을 높이거나 토큰을 많이 사용해도 원하는 품질과 스타일을 보장하지 못했다.

🕒 시간순 섹션별 상세정리

1. 한 번에 필요한 정보를 주되 입력량 자체를 목표로 삼지 않는다

• 토큰을 아끼려는 상황에서는 작업을 여러 단계로 나눌지, 필요한 정보를 한 번에 줄지가 중요한 선택이 된다. 입력을 많이 넣는 것만으로 결과가 좋아지는지는 별개의 문제다 [01:11]
• 모델이 멀티턴에 취약하다는 판단에 따라, 가능한 경우 필요한 정보를 한 번에 제공하는 방식이 권장된다 [01:31]

2. 지침과 문서 참조에는 구체적인 적용 조건이 필요하다

• “데이터 영속성과 관련된 작업에 사용하라”는 지시는 적용 범위가 모호하다. “마이그레이션을 추가하거나 변경할 때, 롤아웃을 검토할 때 사용하라”처럼 실행 조건을 명시해야 불필요한 검증을 줄일 수 있다 [02:19]
• 수정할 때마다 모든 문서를 읽게 하면 참조 비용이 반복된다. 서비스 경계에는 아키텍처 문서, 스키마 변경에는 데이터 문서, 배포 준비에는 배포 문서를 연결하는 방식이 더 구체적이다 [03:21]

3. 스킬은 최소 정보부터 필요한 자료까지 단계적으로 읽는다

• 스킬의 이름과 설명으로 용도를 판단하고, 정보가 부족할 때 스크립트나 참고 자료를 추가로 읽는 구조는 필요한 만큼만 컨텍스트를 사용하는 데 도움이 된다 [04:40]
• 스킬을 너무 많이 추가하면 코덱스가 공간을 맞추려고 설명을 줄이기 시작하고, 그 결과 작업 품질이 떨어질 수 있다 [05:14]

4. 스킬 호출 오류는 이름·설명·제외 조건으로 줄인다

• 스킬이 많을 때는 불필요한 스킬이 자주 호출되거나 필요한 스킬이 호출되지 않는 문제가 생긴다. 사용 경험에서는 과도한 호출이 더 흔한 문제로 지목된다 [06:08]
• 필요한 스킬이 호출되지 않으면 설명을 보강하고, 너무 자주 호출되면 “문서 처리”보다 “PDF 법률 계약서 검토”처럼 목적을 좁혀야 한다 [06:36]

5. 아스트라의 추론 특성은 긴 풀이보다 내부 연산에 초점을 둔다

• 아스트라의 특징은 생각의 사슬을 단순히 숨기는 것이 아니라, COT 없이 가중치 연산으로 문제를 푼다는 설명이다. 풀이를 손으로 길게 쓰는 방식과 암산으로 답을 구하는 방식의 차이에 비유한다 [08:34]
• 추론 구조에 대한 비유에서는 100층을 순서대로 올라가는 대신, 필요한 단계를 반복하거나 쉬운 단계를 건너뛴다. 이 설명은 필요한 연산에 집중하는 효율성을 강조한다 [09:14]

6. 환각 감소의 체감과 행동 감시의 필요성은 함께 봐야 한다

• 논문 작성과 프롬프트 A/B 테스트 경험에서는 아스트라의 환각이 페이블 5.1보다 크게 줄었다는 체감이 나온다. “거의 없는 것 같다”는 평가는 개인 사용 경험이며, 높은 비용도 함께 나온다 [10:03]
• 성능 향상과 함께 나쁜 의도를 감추거나 평가 상황을 우회하는 능력도 높아질 수 있다는 우려가 있다. 말로 드러난 생각만 확인하면 실제 행동의 문제를 놓칠 수 있다 [10:33]

7. 입력·답변·추론 토큰을 각각 관리한다

• 입력에는 관련 없는 스킬, 반복 지시, 불필요한 문서를 넣지 않고 필요한 부분을 발췌하거나 요약한다. 답변에는 결과 형식과 설명 분량을 구체적으로 지정해야 한다 [12:01]
• 에이전트 생성은 보고하게 하고 스킬 생성은 승인받게 하는 수동 절차로 바꾸자, 자동으로 작업을 확장하며 토큰을 소비하는 문제를 통제할 수 있었다 [12:26]

8. 승인과 검증은 필요한 범위에 한정하고 결과 범위를 명시한다

• 매번 검토와 승인을 요구하면 조금만 모호하거나 지침이 충돌해도 확인 질문이 반복된다. 검증도 까다로워져 작업 시간이 크게 늘어나는 문제가 생겼다 [13:40]
• 안전한 영역에서는 자율적으로 진행하게 하되, 불필요한 스킬과 에이전트 생성을 제한하고 설명 분량을 줄여야 한다. 모든 문제를 단계별로 길게 설명시키기보다 중요한 과정과 핵심 근거만 요구하는 편이 낫다 [14:28]

9. 왁스볼 구현 비교에서는 물리감과 지시 우선순위가 중요했다

• 같은 프롬프트로 세 모델의 왁스볼 구현을 비교했다. 껍질이 깨진 뒤 내부가 슬라임처럼 말랑하게 움직이는 동작이 중요한 평가 요소였다 [17:14]
• 최종 구분은 첫 번째가 아스트라 로우, 두 번째가 제미나이, 마지막이 페이블 5.1이었다. 이 사례에서는 아스트라 결과가 가장 현실적으로 느껴졌고, 페이블 결과는 물리감 구현이 부족했다 [18:43]

10. 대시보드는 결과물을 먼저 지정하고 수집·집계 경로를 연결한다

• 아스트라와 플러그인으로 만든 티타임즈 TV 대시보드에는 발행 영상 30편과 누적 조회수 77만, 월별 발행 수와 영상별 지표 등이 담겼다 [20:34]
• 이 작업에서는 지시문보다 결과물을 먼저 적는 방식이 더 좋았다는 사용 경험이 나온다. 대시보드 제작을 목표로 제시하고 분석할 URL을 연결했다 [21:34]

11. 대시보드의 신뢰성과 작업 범위는 금지 사항·종료 조건으로 지킨다

• 데이터 숫자를 조작할 가능성을 막기 위해 금지 사항을 넣었고, 추정과 인과 설명에 관한 제한도 프롬프트에 포함했다 [22:07]
• 종료 조건을 넣지 않은 비교 결과에서는 댓글 분석과 감정 분석 등으로 작업이 확장됐다. 불필요한 수치나 자체 생성 결과가 섞이며 신뢰할 수 없다는 표시까지 나타났다 [22:17]

12. 인터랙티브 웹페이지 재현은 목표와 검증 항목을 함께 제한한다

• 앤트로픽의 영어 리서치 페이지를 한국어로 번역하면서, 스크롤에 반응하는 콘텐츠와 색상 변화까지 동일하게 구현하는 작업을 같은 프롬프트로 두 모델에 맡겼다 [23:21]
• 목표는 원본 URL의 디자인, 콘텐츠 구성, 인터랙션을 동일하게 재현하고 한국어로 구현한 뒤 배포하는 것이었다. 결과물과 목표를 프롬프트 앞에 배치했다 [24:20]

13. 같은 웹페이지 목표에서도 모델별 구현 경로가 달랐다

• 아스트라 미디엄은 한국어 번역과 인터랙션을 원본에 가깝게 구현했다. 페이블 5.1 하이는 번역과 화면 구성이 달랐고, 카테고리 버튼과 펼쳐지는 동작 등도 제대로 재현하지 못했다 [25:16]
• 페이블은 원본의 웹 리소스에서 정보를 수집해 비슷한 구성을 새로 만드는 방향으로 작업했다. 아스트라는 브라우저 화면과 스크롤을 측정하고 원본 클라이언트 코드를 재사용해 더 가까운 결과를 냈다 [26:33]

14. 울트라의 많은 토큰과 집요한 검증이 원하는 결과를 보장하지는 않았다

• 방송용 슬라이드 38장과 지정한 두 가지 콘텐츠 작업에 울트라를 사용하자, 메인 에이전트와 서브에이전트 세 개가 동작했다. 로그에는 출력 토큰 12.2만 사용이 기록됐지만 결과물은 만족스럽지 않았다 [27:25]
• 각 슬라이드를 PNG로 렌더링해 글자가 영역 밖으로 나가는지와 기능·품질을 확인하는 과정까지 수행했다. 이런 검증이 추가 사용량을 늘렸다 [28:14]

15. 자율성과 끈기는 간접적인 요청도 지속적인 작업으로 확장할 수 있다

• 공개된 프롬프트의 자율성과 끈기 지침에는 사용자의 목표가 완료될 때까지 지속하고 자율적으로 진행하라는 내용이 있었다. 사용 경험에서는 이 성향이 요청하지 않은 작업까지 과잉 수행하며 종료를 늦추는 문제와 연결됐다 [29:01]
• “해 줄 수 있어?”, “하고 싶어”, “도와줘”처럼 간접적으로 행동을 요청하는 표현도 실제 작업을 수행하라는 지시로 간주한다. 이런 표현이 단순한 가능 여부 확인을 넘어 실행으로 이어질 수 있다 [29:33]

16. 자율적으로 끝까지 작업하는 모델에는 완료 조건이 필요하다

• 원하는 결과물과 검증 범위를 세세하게 지정하지 않으면, 아스트라는 자율성과 끈기를 바탕으로 작업을 계속 이어가는 성향을 보인다. [30:16]
• 유출된 시스템 프롬프트는 설계 참고 자료가 될 수 있지만, 공식사가 인정하기 전까지 진위는 확정할 수 없다. [31:00]

17. 출력 형식과 스킬 호출도 시스템 지침의 영향을 받는다

• 글쓰기에는 마크다운, 코드에는 코드 블록을 적용하는 등 요청 유형에 따라 출력 형식을 상세하게 정하는 규칙이 들어 있다. [32:46]
• 스킬을 자율적으로 생성하거나 사용자 지시를 일부 놓치는 현상은 시스템 프롬프트의 지침과 충돌한 결과일 가능성이 있다. [33:13]

18. 추론 수준은 작업 난도와 실패 경험에 맞춰 선택한다

• 개인적인 사용 기준으로는 Low부터 시작하는 편이 좋으며, 며칠에 걸친 장기 작업이 아니라면 Low도 충분할 수 있다. [34:31]
• Medium은 여러 문서를 바탕으로 근거를 갖춘 보고서를 작성하는 등 비교적 복잡한 작업에 사용하는 기준을 제안한다. [34:41]

19. 파일 재독과 긴 도구 설명, 중복 기억을 줄인다

• 슬라이드 파일을 통째로 제공하면 검증, 재현, 도구 성공 여부 확인 과정에서 같은 파일을 반복해서 읽어 토큰 소모가 커질 수 있다. 스킬이나 지침용 MD 파일도 읽는 시점을 지정필요가 있다. [35:36]
• 도구 실행의 중간 과정과 결과를 모두 길게 설명하기보다, 필요한 내용만 요약해 기록하도록 하면 토큰 사용을 줄일 수 있었다는 경험을 제시한다. [36:03]

20. 검색과 검증 범위를 정하고 오류는 해당 부분만 수정한다

• 인터넷 검색에서 자료를 지나치게 많이 가져오는 일을 줄이려면 필요한 정보와 출처 범위를 명확히 지정해야 한다. 주요 언론사나 공신력 있는 사이트로 범위를 정하는 방식이 예시다. [37:42]
• 검증에 적극적인 모델인 만큼, 효과가 있었던 간결한 검증 절차를 정해 반복해서 사용하는 편이 좋다. 검증 범위를 열어 두면 여러 대상을 계속 확인할 수 있다. [38:00]

21. 장기 작업은 체크포인트로 기록하고 적절한 예산으로 시작한다

• 여러 세션에 걸친 긴 작업에서는 모든 과정을 상세 로그로 남기기보다, 간단한 체크포인트나 나중에 찾아볼 수 있는 인덱스를 남기는 방식이 유용하다. [38:45]
• 처음부터 비용을 지나치게 아끼려다 계속 수정하게 하기보다, 프롬프트를 잘 작성하고 적절한 추론 예산을 정해 한 번에 처리하는 편이 토큰 사용에서 더 경제적이라는 사용 경험을 제시한다. [39:18]

22. 효율적인 지시에는 모델의 한계와 도메인 이해가 필요하다

• 자료를 적게 보거나 특정 작업만 하도록 제한하면 다른 사실을 놓칠 가능성도 있다. 모델의 특성과 업무 도메인을 정확히 알아야 필요한 범위를 적절히 정할 수 있다. [41:25]
• 보편적인 작업을 모델이 잘할수록 프롬프트 설계자는 모델이 못하는 일과 반복적인 실패 패턴을 빨리 파악해 그 빈틈을 보완해야 한다. 토큰 절감 효과는 다음에 로그와 A/B 테스트로 입증하겠다는 계획이며, 이 구간에서는 결과가 제시되지 않는다. [42:43]

23. 멀티턴에서는 품질 저하를 고려해 맥락을 간결하게 유지한다

• 최근 연구를 근거로, 고성능 모델도 멀티턴 대화가 길어질수록 내용이 빈약해지거나 오류가 늘고 일곱 턴 정도에서도 결과가 깨질 수 있다는 경고가 나온다. 다만 해당 연구의 구체적인 출처는 제시되지 않는다. [44:16]
• 아스트라에서는 같은 멀티턴 품질 저하를 체감하지 못했다는 개인적인 경험도 함께 드러난다. 이 경험을 다른 모델이나 모든 작업에 일반화할 근거는 없다. [44:27]

24. 새 세션으로 옮길 때는 핵심 정보와 원문의 의미를 보존한다

• 멀티턴 작업에서 답변이 이상해졌다고 느끼면 새 창에서 시작하거나, 이전 대화를 필요한 형태로 정리하는 메모리용 스킬을 사용할 수 있다. 정리가 잘되면 반드시 다른 창으로 옮길 필요는 없다는 판단이다. [45:10]
• 이상함이 커졌다면 새 세션이 낫지만, 기존의 좋은 결과물과 정성 들여 만든 파일을 이어 쓰려면 자신의 작업 방식에 맞게 기억을 구성해 두는 편이 좋다. [45:31]

🧾 결론

• 좋은 프롬프트에는 목표뿐 아니라 필요한 자료, 지시 우선순위, 결과 분량, 검증 항목, 완료 조건이 들어가야 한다.
• 안전한 범위의 자율성은 허용하되, 불필요한 스킬·에이전트 생성과 반복 승인·검증이 작업을 늘리지 않도록 조건을 정해야 한다.
• 비용을 지나치게 아껴 재작업을 반복하기보다, 요구사항을 정리하고 적절한 추론 예산으로 처리하는 편이 경제적일 수 있다는 사용 경험이 제시된다.
• 자료와 검증을 줄이면 필요한 사실을 놓칠 수도 있다. 적절한 범위는 모델의 한계와 업무 도메인을 이해한 뒤 정해야 한다.

📈 투자·시사 포인트

• AI 업무 도입에서는 모델 성능과 함께 반복 참조, 도구 호출, 검증, 재작업에 드는 비용을 살펴볼 필요가 있다.
• 고비용 모델과 높은 추론 수준의 효용은 업무별로 판단해야 한다. 제시된 사례만으로 일상 업무에서도 비용 대비 우위가 있다고 결론 내리기 어렵다.
• 스킬 설명, 호출 조건, 완료 기준을 정비하는 운영 설계가 AI 활용 효율을 좌우할 수 있다. 절감 효과는 실제 로그와 비교 실험으로 확인해야 한다.
• 에이전트의 신뢰성을 평가할 때는 추론 텍스트뿐 아니라 도구 실행과 실제 수행 결과도 확인해야 한다는 시사점이 나온다.

⚠️ 불확실하거나 확인이 필요한 부분

• 토큰 절감과 기억 정리의 효과는 주로 사용 경험으로 제시된다. 절감률이나 통제된 A/B 테스트 결과는 제공되지 않았고, 이후 입증하겠다는 계획만 언급된다.
• 아스트라의 환각 감소와 모델별 구현 품질 비교는 특정 작업에서의 체감이다. 다른 업무와 모델 설정에도 같은 결과가 나타난다고 일반화할 수 없다.
• 아스트라의 내부 추론 구조에 관한 설명과 비유는 이 자료만으로 기술적 사실을 검증하기 어렵다. 멀티턴 품질 저하 연구와 사보타주 실험도 구체적인 원출처 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 자주 쓰는 프롬프트 앞부분에 결과물, 형식, 분량, 필요한 자료, 지시 우선순위를 명시한다.
• 문서와 스킬마다 읽거나 호출할 조건을 정하고, 중복되거나 지나치게 넓은 설명에는 제외 조건을 추가한다.
• 작업별 검증 항목과 종료 조건을 적고, 오류 발생 시 문제가 생긴 부분만 수정하도록 지시한다.
• 같은 작업에서 기존 프롬프트와 수정안을 비교해 입력·답변·추론 토큰, 호출 횟수, 재작업과 결과 품질을 기록한다.

❓ 열린 질문

• 문서 참조와 검증을 얼마나 줄여야 품질을 유지하면서 토큰도 아낄 수 있을까?
• 업무별로 추론 수준을 높이는 기준을 실패 횟수, 제약의 복잡성, 재작업 비용 중 무엇으로 정할까?
• 필요한 정보를 한 번에 제공하는 방식과 여러 턴으로 나누는 방식은 어떤 작업에서 비용·품질 차이를 보일까?