# \#prompt-engineering

**URL:** https://discuss.pytorch.kr/tag/prompt-engineering/164.md

[최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md)

---

## [REAP: 리버스 엔지니어링 에이전트(REA)에서 바로 사용 가능한 55개의 리버스 엔지니어링 프롬프트 저장소 (≠ REA 공식)](https://discuss.pytorch.kr/t/reap-rea-55-rea/12255)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [10월 22, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/reap-rea-55-rea/12255 "2026-10-22T09:30:07Z")

</div>

핵심 요약 REAP(REA Investigation Prompts)는 리버스 엔지니어링 도구 REA를 연결한 코딩 에이전트에 붙여 넣어 쓰도록 만든 프롬프트 55개를 README 파일 하나에 17개 분야로 정리한 저장소입니다. REA 개발팀이 아니라 보안 연구자 Joas A Santos가 만들었습니다. 대부분의 프롬프트는 기능 하나로 범위를 좁히고 결론마다 파일, 함수, 주소 같은 근거를 요구합니다. 확인된 사실과 추론(inference), 확인하지 못한 부분의 구분은 13개 정도, 정적 분석 우선은 7개 프롬프트에만 명시되어 있습니다. 55개 중 6개는 madewithrea.com 프롬프트 갤러리와 문구가 같습니다. README는 이 갤러리를 공식 갤러리로 소개하지만, madewithrea.com은 스스로 REA 프로젝트와 관계없는 커뮤니티 디렉터리라고 밝히고 있습니다. REA 자체에도 가이드 프롬프트 6개와, 결론마다 관찰, 추론, unknown을 구분하게 하는 에이전트 스킬이 들어 있습니다. REAP는 여기에 더해 펌웨어, 커널 드라이버, 게임의 WASM(WebAssembly) 이식, 안티치트와 크래킹 연구까지 대상별 프롬프트를 둡니다. 안티치트, DMA(Direct Memory Access) 치트, 소프트웨어 크래킹을 다루는 12~14절은 REA 프로젝트가 지원하지 않는다고 밝힌 용도와 일부 겹치므로, 자신이 소유하거나 분석을 허가받은 대상에만 써야 합니다. REAP 소개 코딩 에이전트에 리버스 엔지니어링(reverse engineering) 도구를 연결해도, 에이전트가 돌려주는 답의 질은 질문을 어떻게 쓰는지에 따라 달라집니다. REA(Reverse Engineer Anything) (:pytorch::kr: REA: Ghidra와 IDA 같은 분석 도구를 하나의 MCP로 묶어 코딩 에이전트에 연결하는 리버스 엔지니어링 도구)는 Ghidra, IDA, Hopper 같은 분석 도구를 하나의 MCP 서버로 묶어 에이전트에 연결하는 프로젝트입니다.…

---

## [OpenAI Codex 팀이 권하는 GPT-6 Astra 전환 준비, 스킬 설명은 좁게 AGENTS.md는 조건부로](https://discuss.pytorch.kr/t/openai-codex-gpt-6-astra-agents-md/11900)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [9월 12, 2026, 5:30오전 UTC](https://discuss.pytorch.kr/t/openai-codex-gpt-6-astra-agents-md/11900 "2026-09-12T05:30:49Z")

</div>

GPT-6 Astra에 맞춘 스킬과 AGENTS.md 재점검 가이드 소개 OpenAI의 Codex 팀이 2026년 9월 11일 개발자 블로그에 Rethinking skills and prompts for GPT-6 Astra 를 공개했습니다. Eric Provencher가 쓴 이 글은 새 모델을 쓰기 시작할 때 API 파라미터를 바꾸는 이야기가 아니라, 지난 1년 동안 저장소와 사용자 설정에 쌓여 온 지시(instructions) 를 덜어내는 이야기입니다. 글이 대상으로 삼는 지시는 세 가지, 스킬(Skill)과 AGENTS.md, 그리고 작업을 시킬 때 쓰는 프롬프트입니다. 전제는 단순합니다. 코딩 에이전트가 빠르게 좋아졌고, 그에 따라 모범 사례도 빠르게 바뀌고 있다는 것입니다. 원문은 첫 문단에서 이를 "모델이 더 유능해지면서, 예전에는 손을 많이 잡아 주고 보조 코드(Scaffolding)를 깔아 줘야 했던 일이 이제는 그렇지 않다"고 정리합니다. 문제는 그 손잡아 주기의 흔적이 파일로 남아 있다는 점입니다. 원문이 각 항목에서 드는 예시가 그것으로, 테스트를 실행하도록 독려하는 한 줄, 모델이 허락 없이 일을 처리해 버려서 넣은 금지 문구, "편집 전에 문서 세 개를 먼저 읽어라" 같은 지시는 그것을 넣게 만든 모델이 사라진 뒤에도 저장소에 그대로 남습니다. 각각은 한 줄이지만 모두 합치면 모델이 매 요청에서 읽어야 하는 분량이 되고, 지시끼리 서로 어긋나기 시작합니다. 원문의 조언은 GPT-6 Astra 공식 활용 가이드와 짝을 이룹니다. 공식 가이드가 Responses API 파라미터 정리와 모델의 다섯 가지 행동 특성을 프롬프트로 조정하는 방법을 다뤘다면, 이번 블로그는 그 프롬프트가 실제로 놓이는 자리, 즉 저장소에 체크인된 지시 파일과 사용자 홈에 쌓인 스킬 폴더를 다룹니다. 공교롭게도 같은 시기에 Anthropic도 Claude Code의 시스템 프롬프트에서 80% 이상을 덜어낸 이유를 발표했습니다. 두 회사가 각자의 프런티어 모델…

---

## [GitReverse: 공개 GitHub 저장소를 바이브 코딩용 프롬프트 한 개로 되돌리는 웹 도구](https://discuss.pytorch.kr/t/gitreverse-github/11816)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [9월 8, 2026, 12:00오전 UTC](https://discuss.pytorch.kr/t/gitreverse-github/11816 "2026-09-08T00:00:04Z")

</div>

GitReverse 소개 코딩 에이전트로 무언가를 만들어 보려고 할 때 가장 막히는 지점은 첫 프롬프트입니다. 만들고 싶은 결과물과 비슷한 프로젝트가 GitHub에 이미 있어도, 그 저장소를 읽어서 "이걸 만들어 달라"는 한 문단으로 압축하는 일은 별개의 작업입니다. 저장소를 그대로 붙여 넣으면 컨텍스트 창(Context Window)을 낭비하고, 요약하면 무엇을 남기고 무엇을 버릴지 매번 다시 판단해야 합니다. 이번에 소개할 GitReverse는 그 판단을 대신하는 웹 도구입니다. 공개 GitHub 저장소 주소를 넣으면, 그 프로젝트를 처음부터 한 번에 만들어 달라고 요청할 때 붙여 넣었을 법한 합성된 사용자 메시지 한 개 를 돌려줍니다. 저자는 이 결과물을 Cursor, Claude Code, Codex, v0 같은 도구에 붙여 넣는 용도로 설명하고 있습니다. GitReverse는 Next.js 16(App Router)과 React 19, TypeScript, Tailwind CSS 4로 만들어졌고 저장소가 공개되어 있습니다. 다만 저장소는 호스팅되는 서비스의 소스이기도 해서, gitreverse.com 에는 무료로 쓸 수 있는 기본 변환 외에 유료 플랜과 크레딧 구매가 함께 운영되고 있습니다. lib/billing-config.ts 를 보면 플랜이 무료와 starter, pro, unlimited로 나뉘어 있고 deep\_reverse 와 manual\_control 이 플랜에 따라 제한되는 기능으로 정의되어 있습니다. GitReverse와 기존 저장소 분석 도구 비교 저장소를 입력으로 받아 무언가를 만들어 주는 도구는 이미 여러 가지가 있고, 방향이 서로 다릅니다: 도구 입력 출력 쓰이는 자리 ReadMeReady 저장소 코드 README 문서 만든 것을 설명하기 GitMCP 저장소 MCP 서버 에이전트가 저장소를 조회하기 Skill Seekers 저장소와 문서 에이전트 스킬 패키지 저장소 지식을 에이전트에 넣기 …

---

## [sepia: AI가 작성한 티를 없애기 위해, 어휘 교정 뿐만 아니라 서사 구조까지 종합적으로 살펴보고 개선하는 에이전트 스킬](https://discuss.pytorch.kr/t/sepia-ai/11813)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 1\
**마지막 업데이트:** [9월 6, 2026, 6:41오전 UTC](https://discuss.pytorch.kr/t/sepia-ai/11813 "2026-09-06T06:41:14Z")

</div>

sepia 소개 AI가 쓴 글을 사람 글처럼 만들어 준다는 도구는 이미 많습니다. 대부분은 단어와 문장 구조를 손봅니다. 상투적인 형용사를 빼고, 대시를 쉼표로 바꾸고, 문장 길이를 뒤섞습니다. 문제는 그렇게 표면을 다 지워도 판별이 거의 그대로라는 점입니다. 2026년 4월 공개된 논문 StoryScope는 문체 신호를 전혀 쓰지 않고 담화 수준의 서사 선택만으로 학습한 분류기가 사람과 AI 소설을 macro-F1(클래스별 F1 점수의 산술 평균) 93.2%로 구분했다고 보고했습니다. sepia 저자는 이 논문을 인용해 표면 문체를 걷어내도 판별 성능이 95.5%에서 93.9%로만 내려간다고 정리하고 있습니다. 이번에 소개할 sepia는 그 결과를 개고 순서로 옮긴 에이전트 스킬입니다. 소설에서는 서사 구조를 먼저 고친 뒤에야 단어를 건드리고, 릴리즈 노트나 장애 회고 같은 실무 문서에서는 문서가 게재될 지면에 맞춘 규칙을 적용합니다. 어느 쪽이든 연산은 네 가지로 고정되어 있습니다. 새로 쓰기(write), 수정 없이 진단만 하기(review), 최소한만 손대기(refactor), 사실만 남기고 다시 쓰기(recreate)입니다. sepia는 Agent Skills 표준을 따르는 이식 가능한 스킬이라 그 표준을 읽는 에이전트라면 불러 쓸 수 있고, 77종 이상의 에이전트를 지원하는 Skills CLI (:pytorch::kr: Vercel Skills (Skills.sh): 여러 AI 에이전트들을 지원하는 오픈소스 스킬 생태계)로 한 줄에 설치됩니다. Claude Code, Codex, Grok Build (:pytorch::kr: Grok Build: 터미널에서 코드베이스를 이해하고 편집하는 AI 코딩 에이전트), Antigravity는 별도의 플러그인 패키징까지 제공하며, 저자는 이 네 곳에서 설치가 완료되고 항목이 나타나는 것까지 직접 확인했다고 적어 두었습니다. 정본 SKILL.md 는 하나이고 플랫폼별로 따로 관리하는 사본을 두지 않습니다…

---

## [Goal-Driven: 완료 기준을 검사해 서브 에이전트를 계속 다시 실행하는 다중 에이전트 프롬프트 도구](https://discuss.pytorch.kr/t/goal-driven/11783)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [9월 2, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/goal-driven/11783 "2026-09-02T06:30:56Z")

</div>

Goal-Driven 소개 코딩 에이전트에게 규모가 큰 작업을 맡겨 본 사람이라면 익숙한 장면이 있습니다. 에이전트가 한참 작업하다가 "구현을 완료했습니다"라고 선언하는데, 정작 확인해 보면 절반쯤 되어 있거나 테스트가 통과하지 않는 상태입니다. 다시 지시하면 또 얼마쯤 진행하고 다시 멈춥니다. 문제는 능력보다 종료 조건에 있습니다. 에이전트는 자기가 언제 끝난 것인지 판단할 기준을 갖고 있지 않으므로, 대화가 길어지면 남은 작업을 완료로 간주하고 작업을 멈춥니다. Goal-Driven 은 이 종료 판정을 에이전트 자신에게서 떼어내 별도의 감독자에게 넘기는 방식을 정리한 프로젝트입니다. 목표(Goal)와 완료 기준(Criteria)을 사람이 먼저 문장으로 정해 두고, 마스터 에이전트(Master Agent)가 그 기준만 보고 완료 여부를 판정하며, 작업은 서브 에이전트(Subagent)가 맡습니다. 마스터 에이전트는 서브 에이전트가 멈추거나 완료를 선언하면 기준과 대조해 보고, 기준에 못 미치면 같은 이름의 서브 에이전트를 새로 세워 작업을 계속하게 합니다. 저자인 lidangzzz 는 이 방식으로 다중 에이전트 시스템이 하나의 문제에 300시간 이상 연속으로 매달릴 수 있다고 적었습니다. 여기서 저장소의 실체를 먼저 짚어 둘 필요가 있습니다. Goal-Driven 저장소에 들어 있는 것은 실행 가능한 프로그램이 아니라 마크다운 문서 두 개, 즉 영문 README와 중문 README 뿐입니다. 설치할 패키지도, 실행할 스크립트도 없습니다. 이 프로젝트가 배포하는 것은 목표와 완료 기준 두 칸을 채워 Claude Code, Codex, OpenClaw 같은 서브 에이전트 생성이 가능한 도구에 그대로 붙여 넣는 프롬프트 한 장입니다. GitHub 저장소 설명이 이 프로젝트를 "다중 에이전트 시스템(multi-agent system)"이라고 소개하기 때문에 프레임워크를 기대하고 들어오기 쉬운데, 실제로 받아 가는 것은 방법론과 그것을 담은 프롬프트 문안입니…

---

## [stop-slop: 산문에서 AI 글쓰기 패턴을 찾아 제거하는 Claude 스킬](https://discuss.pytorch.kr/t/stop-slop-ai-claude/10552)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 2\
**마지막 업데이트:** [8월 27, 2026, 4:47오전 UTC](https://discuss.pytorch.kr/t/stop-slop-ai-claude/10552 "2026-08-27T04:47:33Z")

</div>

stop-slop 소개 stop-slop은 산문에서 AI 특유의 글쓰기 패턴을 찾아 제거하도록 LLM에게 지시하는 스킬(Skill) 파일입니다. 프로젝트는 "AI writing has patterns. Predictable phrases, structures, rhythms." 라는 문장으로 문제를 정의합니다. LLM이 쓴 글에는 상투적인 도입부, 기계적인 대조 구문, 단조로운 리듬처럼 반복해서 나타나는 특징이 있고, 독자는 이런 특징을 통해 글이 AI로 작성되었음을 알아챕니다. stop-slop은 이런 패턴을 목록화해 Claude를 비롯한 LLM이 글을 쓰거나 고칠 때 스스로 잡아내도록 만듭니다. 이 프로젝트는 실행 파일이나 라이브러리가 아니라 마크다운 문서로만 구성된 스킬 패키지입니다. 핵심 지침을 담은 SKILL.md 와 세 개의 참조 문서, 즉 제거할 문구 목록(references/phrases.md), 피해야 할 구조 패턴(references/structures.md), 수정 전후 변환 예시(references/examples.md)로 이루어져 있습니다. 문서 기반이라 Claude Code의 스킬 폴더, Claude Projects의 프로젝트 지식, 시스템 프롬프트 등 LLM에 텍스트 지침을 넣을 수 있는 곳이면 어디든 적용할 수 있습니다. stop-slop이 정의하는 핵심 규칙은 여덟 가지입니다. 군더더기 문구 삭제, 공식화된 구조 깨기, 능동태 사용, 구체적으로 쓰기, 독자를 장면 안에 두기, 리듬에 변화 주기, 독자의 지능을 신뢰하기, 인용구처럼 들리는 문장 다시 쓰기입니다. 각 규칙에는 점검 질문이 따라붙어 있어, 글을 전달하기 전에 부사 사용 여부, 수동태, Wh-로 시작하는 문장, em dash 사용 같은 항목을 하나씩 확인하는 체크리스트로도 쓸 수 있습니다. stop-slop이 잡아내는 글쓰기 패턴 stop-slop이 차단하는 패턴은 세 층위로 나뉩니다. 첫 번째는 금지 문구 입니다. "Here's the thing:", "…

---

## [dsh-routing-suite: DeepSeek Harness에서 모델의 사고 방식을 프리셋으로 고르는 라우팅 키트](https://discuss.pytorch.kr/t/dsh-routing-suite-deepseek-harness/11655)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [8월 24, 2026, 12:30오후 UTC](https://discuss.pytorch.kr/t/dsh-routing-suite-deepseek-harness/11655 "2026-08-24T12:30:57Z")

</div>

dsh-routing-suite 소개 코딩 에이전트를 오래 쓰다 보면 같은 모델이 날마다 다르게 움직이는 것처럼 느껴질 때가 있습니다. 어떤 세션에서는 첫 턴에 설계를 길게 늘어놓고 파일은 한참 뒤에야 건드리고, 어떤 세션에서는 곧바로 파일을 열어 고치기 시작합니다. 사용자 입장에서는 같은 모델에 비슷한 요청을 넣었을 뿐인데 작업 방식이 달라지니, 원인을 프롬프트에서 찾아야 할지 모델의 컨디션 탓으로 넘겨야 할지 판단하기 어렵습니다. 이 차이를 재현 가능한 조건으로 묶어 두지 못하면, 매번 다른 결과를 받고도 무엇을 바꿔야 할지 알 수 없습니다. 이번에 소개할 dsh-routing-suite는 DeepSeek Harness (:pytorch::kr: DeepSeek Harness: 에이전트 루프까지 설정으로 교체하는 플러그인 구조의 코딩 에이전트)에서 이 차이를 프리셋 선택 이라는 명시적인 스위치로 바꾸는 저장소입니다. 저자는 첫 요청에 실리는 시스템 프롬프트의 페르소나(Persona) 한 문장이 모델의 작업 궤적을 좌우한다고 보고, 그 한 문장을 세션 시작 시점에 갈아 끼우는 프리셋을 만들었습니다. 프리셋을 고르는 일은 사람이 하고, 고른 뒤에는 라우터가 첫 요청에서만 개입한 다음 손을 뗍니다. 저자가 공개한 실험 문서에 따르면 모델이 세션 도중 스스로 모드를 바꾸는 경로는 거의 열려 있지 않아서, 선택은 바깥에서 들어와야 한다는 것이 이 설계의 출발점입니다. dsh-routing-suite는 직접 코드를 담고 있지 않고 두 개의 서브모듈을 묶어 설치 절차만 정리한 저장소입니다. 하나는 실행 중인 DSH에 플러그인을 재시작 없이 주입하는 dsh-super-injector이고, 다른 하나는 라우팅 프리셋 본체인 dsh-router-standard입니다. 두 구성 요소는 각자의 저장소에서 따로 버전을 올리고, 이 키트는 둘을 한 번에 받아 순서대로 설치하는 역할을 맡습니다. 저장소의 README.md는 중국어로 쓰여 있고 영문판인 README.en.md가…

---

## [Photo Abstract Editorial: 원본 사진을 건드리지 않고 추상 패널을 덧붙이는 Codex 스킬](https://discuss.pytorch.kr/t/photo-abstract-editorial-codex/11635)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [8월 17, 2026, 7:30오전 UTC](https://discuss.pytorch.kr/t/photo-abstract-editorial-codex/11635 "2026-08-17T07:30:47Z")

</div>

Photo Abstract Editorial 소개 사진을 이미지 생성 모델에 넣으면 대부분의 결과는 사진 자체를 바꿔 놓습니다. 필터를 씌우거나, 벡터로 따거나, 화풍을 옮기거나, 아예 다시 그립니다. 그런데 사진을 찍어 두고 나중에 다시 볼 때 남는 것은 피사체의 정확한 형태보다 공간이 배치된 방식, 색이 맡고 있던 역할, 비어 있던 자리 쪽인 경우가 많습니다. 그 기억에 해당하는 층만 따로 뽑아 눈에 보이게 만들려면 지금까지는 사람이 직접 편집 작업을 해야 했습니다. Photo Abstract Editorial은 그 작업을 맡기는 Codex 스킬입니다. 사진 한 장을 받아 원본 사진 영역과 그 사진에서 도출한 추상 기억 패널, 그리고 짧은 영문 제목으로 이루어진 세로형 편집 작품 한 장을 만들어 냅니다. 저자는 이것이 필터도, 사진 다시 그리기도, 스타일 트랜스퍼(Style Transfer)도 아니며 사진 자체에서 공간 관계와 구도의 리듬, 색 관계만 뽑아낸 결과라고 선을 그어 둡니다. 실제로 스킬의 첫 번째 가드레일은 업로드된 사진을 유일한 콘텐츠 출처로 다루라는 것이고, 사진 영역은 비율 조정이나 접합에 필요한 약간의 크롭 외에는 다시 그리거나 확장하거나 보정할 수 없습니다. 저장소는 코드가 아니라 규칙 문서로 채워져 있습니다. 작업 절차와 가드레일을 담은 SKILL.md, 중국어와 영어로 각각 작성된 전체 프롬프트 두 벌, Codex 인터페이스 메타데이터인 agents/openai.yaml, 그리고 예시 결과물이 담긴 assets/examples 디렉토리가 전부입니다. 위는 저장소가 공개한 예시 작품 중 하나입니다. 위쪽에는 촬영한 노을 사진이 그대로 있고, 아래쪽 상아색 패널에는 그 사진에서 뽑아낸 관계만 남았습니다. 붉은 띠 몇 겹은 지평선 위 빛의 층을, 수직으로 지나가는 가는 선은 전신주의 축을, 아래쪽 점의 행렬은 흩어져 있던 불빛의 간격을 대신합니다. 형태를 축소해 옮긴 것이 아니라 관계만 옮겼다는 점이 이 결과물의 핵심입니…

---

## [Anthropic이 공개한 Claude Opus 5 프롬프트 작성법 및 Opus 4.8 마이그레이션 가이드](https://discuss.pytorch.kr/t/anthropic-claude-opus-5-opus-4-8/11439)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 28, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/anthropic-claude-opus-5-opus-4-8/11439 "2026-07-28T03:30:10Z")

</div>

Claude Opus 5 프롬프트 가이드 소개 Anthropic이 공식 문서에 Claude Opus 5 전용 프롬프트 가이드를 추가했습니다. 새 모델이 나올 때 개발자가 기대하는 것은 대개 "같은 프롬프트로 더 좋은 결과"인데, 이 문서가 다루는 내용은 정확히 그 기대가 어긋나는 지점입니다. Anthropic 스스로도 Claude Opus 4.8 시절 프롬프트에서 "별도 손질 없이 잘 동작한다" 고 적어 두었지만, 그 다음 문장부터 문서 전체가 가장 자주 손봐야 하는 동작들 을 하나씩 짚습니다. 가이드를 관통하는 논지는 한 문장으로 압축됩니다. 이전 모델을 달래려고 써 둔 지시를 지우는 일이, 새 지시를 추가하는 일보다 중요합니다. 예전 Claude에게 "작업이 끝나면 반드시 검증 단계를 넣어라" 라고 적어 두었다면 Opus 5에서는 그 문장이 과잉 검증을 유발하고, "진행 상황을 3번의 도구 호출마다 요약하라" 라고 적어 두었다면 이제는 중복 서술이 됩니다. 모델이 알아서 하게 된 일을 계속 시키면 토큰만 늘고 결과는 나아지지 않습니다. 반대로 새로 적어야 하는 지시도 있습니다. Opus 5는 사용자에게 보여 주는 응답도, 파일로 써 내려가는 산출물도 이전 모델보다 깁니다. 그리고 문서가 못 박아 두는 중요한 사실이 하나 있는데, 응답 길이는 effort 파라미터로 줄어들지 않습니다. effort는 모델이 얼마나 생각하는지 를 조절할 뿐 얼마나 말하는지 를 조절하지 않기 때문에, 분량은 프롬프트로 직접 요구해야 합니다. 비용을 줄이려고 effort만 낮췄다가 응답 길이는 그대로여서 당황하는 경우가 여기서 나옵니다. 이 게시물에서는 프롬프트 가이드의 전체 내용과, 함께 읽어야 하는 Claude Opus 4.8에서 Claude Opus 5로의 마이그레이션 가이드를 묶어 정리합니다. 두 문서는 같은 이야기를 각각 프롬프트 관점과 API 관점에서 서술하고 있어서, 실제로 모델을 갈아 끼울 때는 둘을 함께 봐야 빠지는 항목이 없습니다. :books: 심…

---

## [agenta: 프롬프트 관리와 평가, 관측을 통합한 오픈소스 LLMOps 플랫폼](https://discuss.pytorch.kr/t/agenta-llmops/11322)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 21, 2026, 5:30오전 UTC](https://discuss.pytorch.kr/t/agenta-llmops/11322 "2026-07-21T05:30:19Z")

</div>

agenta 소개 agenta는 프로덕션 수준의 LLM 애플리케이션을 만드는 과정을 프롬프트 관리, 평가, 관측이라는 세 축으로 묶어 다루는 오픈소스 LLMOps 플랫폼입니다. LLM 앱을 개발할 때 프롬프트를 실험하는 도구, 결과 품질을 검증하는 도구, 운영 중 동작을 추적하는 도구가 제각기 흩어져 있는 경우가 많은데, agenta는 이 세 가지를 하나의 플랫폼 안에서 연결하는 것을 목표로 합니다. 이 플랫폼은 엔지니어와 제품팀, 그리고 도메인 전문가(Subject Matter Expert)가 함께 협업하도록 설계된 점이 특징입니다. 프롬프트를 코드로만 다루지 않고 UI 기반 플레이그라운드에서 실험할 수 있게 하여, 프롬프트 작성에 밝은 도메인 전문가가 엔지니어와 같은 화면에서 작업할 수 있습니다. 동시에 평가와 관측은 UI와 API 양쪽으로 접근할 수 있어, 비개발자는 화면에서 실행하고 개발자는 코드로 자동화하는 식으로 역할을 나눌 수 있습니다. agenta는 Agentatech UG(상호명 Agenta)가 개발하며, 무료 요금제가 있는 관리형 서비스인 Agenta Cloud와 함께 직접 서버에 올리는 셀프호스팅 방식을 모두 제공합니다. 본 게시물에서는 agenta의 세 가지 핵심 기능과 설치 방법, 라이선스 구조를 정리합니다. agenta의 세 가지 핵심 기능 agenta의 기능은 프롬프트 관리, LLM 평가, LLM 관측이라는 세 축으로 나뉩니다. 아래는 각 기능의 실제 화면으로, 프롬프트를 나란히 비교하는 플레이그라운드, 평가 실행 화면, 운영 관측 화면을 보여줍니다. agenta의 프롬프트 관리 프롬프트 관리 기능은 프롬프트를 실험하고 버전을 남기는 작업을 다룹니다. 인터랙티브 플레이그라운드에서는 여러 프롬프트를 테스트 케이스와 함께 나란히 비교할 수 있고, 50개 이상의 LLM 모델을 지원하거나 직접 준비한 모델을 연결할 수 있습니다. 프롬프트와 설정에는 브랜치와 환경(environment) 개념을 적용한 버전 관리가 …

---

## [OpenAI가 공개한 GPT-5.6 공식 활용 가이드: 마이그레이션부터 프롬프팅, Pro 모드까지](https://discuss.pytorch.kr/t/openai-gpt-5-6-pro/11195)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 2\
**마지막 업데이트:** [7월 16, 2026, 8:19오전 UTC](https://discuss.pytorch.kr/t/openai-gpt-5-6-pro/11195 "2026-07-16T08:19:35Z")

</div>

GPT-5.6 모델 가이드 소개 OpenAI가 개발자 문서 사이트에 GPT-5.6 모델 패밀리를 위한 공식 활용 가이드(Model Guidance)를 공개했습니다. 이 문서는 GPT-5.6으로의 마이그레이션 절차, 새로 추가된 API 기능, 그리고 이전 세대와 달라진 프롬프팅 모범 사례를 한곳에 정리한 실무 지침서로, GPT-5.5나 GPT-5.4 기반 애플리케이션을 운영 중인 개발자라면 반드시 짚고 넘어가야 할 내용을 담고 있습니다. 가이드에서 가장 눈에 띄는 메시지는 \*"마이그레이션을 모델 슬러그 교체가 아니라 튜닝 패스(tuning pass)로 취급하라"\*는 것입니다. GPT-5.6은 더 적은 토큰으로 같은 수준 이상의 품질을 내는 경우가 많기 때문에, 기존 추론(reasoning) 설정을 그대로 옮기는 것이 아니라 대표 작업에서 현재 설정과 한 단계 낮은 설정을 함께 비교해보라고 권합니다. 즉, 모델 이름만 바꾸고 끝내면 GPT-5.6이 제공하는 토큰 효율 개선을 제대로 누리지 못한다는 의미입니다. 한편 이 가이드는 프롬프팅 관점에서도 흥미로운 전환점을 보여줍니다. 그동안 에이전트 하네스(harness)에 쌓여온 장황한 시스템 프롬프트를 걷어내고 최소한의 프롬프트로 시작하는 편이 오히려 성능과 비용 모두에서 유리하다는, 내부 평가 수치에 기반한 조언이 담겨 있기 때문입니다. GPT-5.6의 새 네이밍 체계와 안전 스택에 대한 개요는 GPT-5.6 Sol, Terra, Luna 프리뷰 소개 글에서 다룬 바 있으며, 이번 글은 그 후속으로 실제 개발 워크플로우에 적용할 수 있는 세부 지침을 정리합니다. 새 네이밍 체계: Sol, Terra, Luna 중 무엇을 쓸 것인가 GPT-5.6은 새로운 네이밍 체계를 도입했습니다. 용도별 세 가지 모델로 구성되며, gpt-5.6 별칭(alias)은 플래그십 모델인 gpt-5.6-sol로 요청을 라우팅합니다. 모델 포지셔닝 권장 용도 gpt-5.6-sol 플래그십 성능 최고 품질이 필요한 복…

---

## [talk-normal: 어떤 LLM이든 장황한 답변을 간결하게 만드는 시스템 프롬프트](https://discuss.pytorch.kr/t/talk-normal-llm/11208)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 13, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/talk-normal-llm/11208 "2026-07-13T06:30:17Z")

</div>

talk-normal 소개 LLM 에게 간단한 질문을 던졌을 때 필요 이상으로 긴 답변이 돌아온 경험은 흔합니다. 불릿 목록과 소제목, 반복되는 요약이 붙어 실제로 필요한 정보는 몇 문장인데도 화면을 한참 채우는 식입니다. 이런 장황함(verbosity)은 읽는 시간을 늘리고 핵심을 흐립니다. talk-normal 은 이 문제를 하나의 시스템 프롬프트로 해결하려는 프로젝트입니다. 장황하고 기업 문서 같은(corporate-sounding) LLM 출력을 군더더기 없이 핵심만 담은 응답으로 바꾸는 것을 목표로 하며, 저자는 이를 "어떤 LLM 이든 일반 사람처럼 말하게 만든다" 는 한 줄로 요약합니다. 특정 모델에 묶이지 않고 GPT, Claude, Gemini, LLaMA 등 어떤 모델에서도 동작하도록 설계되어 있습니다. talk-normal 은 규칙(rule) 기반으로 동작하며, 규칙은 저장소의 이슈와 CHANGELOG.md 를 통해 계속 다듬어집니다. 본 게시물에서는 talk-normal 이 실제로 무엇을 줄이는지, 저자가 보고한 측정 결과, 그리고 사용법을 정리합니다. talk-normal이 하는 일 talk-normal 의 핵심은 정보를 버리지 않으면서 표현의 군더더기만 걷어내는 것입니다. 저자는 10개의 테스트 질문에 대한 전후 비교를 TEST\_RESULTS.md 에 정리해 두었으며, GPT-4o-mini 에서 73%, GPT-5.4 에서 72%의 길이 감소를 보고하면서도 유용한 정보는 모두 보존했다고 설명합니다. 예를 들어 "What is Python?" 이라는 질문에 GPT-4o-mini 는 1,583자에 이르는 답변을 내놓았지만, talk-normal 을 적용하면 같은 내용을 513자로 압축합니다. 파이썬이 고수준 인터프리터 언어이고 여러 패러다임을 지원하며 웹 개발·데이터 분석·AI 등에 널리 쓰인다는 핵심은 그대로 유지한 채, 불필요하게 번호를 매긴 항목과 반복 설명을 걷어낸 형태입니다. 저자는 이 프로젝트를 만들게 된 실…

---

## [Loop Library: 반복 가능한 AI 에이전트 워크플로우를 만들고 공유하는 루프 라이브러리](https://discuss.pytorch.kr/t/loop-library-ai/11050)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 3, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/loop-library-ai/11050 "2026-07-03T06:30:13Z")

</div>

Loop Library 소개 대부분의 프롬프트는 에이전트에게 무언가를 한 번 시키고 끝납니다. 하지만 실제 작업은 첫 시도가 곧 최종 답이 아닌 경우가 많습니다. 프로덕션 오류를 고치거나, 테스트 커버리지를 높이거나, 문서를 최신 상태로 유지하는 일은 한 번의 실행보다 결과를 보고 다음 단계를 정하는 반복이 필요합니다. Loop Library는 이런 반복 작업을 위한 루프(loop), 즉 피드백이 내장된 플레이북을 모아 둔 라이브러리입니다. 이 저장소는 서로 연결된 두 부분으로 이뤄져 있습니다. 하나는 누구나(사람이든 에이전트든) 발행된 루프를 둘러보고 그 프롬프트를 복사할 수 있는 공개 카탈로그인 Loop Library 웹사이트 이고, 다른 하나는 에이전트가 루프를 발견·검색·점검·수리·제작·실행·디브리핑·발행하도록 돕는 설치형 가이드인 Loopy 스킬 입니다. 웹사이트가 곧 라이브러리이고, Loopy는 그 라이브러리를 다루는 동반 도구입니다. Loopy를 설치하지 않아도 웹사이트만으로 루프를 읽고 활용할 수 있습니다. Loopy가 없는 에이전트는 웹사이트가 함께 제공하는 에이전트 가이드, llms.txt, JSON·텍스트 카탈로그를 직접 참조할 수도 있습니다. Loop Library는 Forward Future의 프로젝트입니다. Loop Library에서 루프란 무엇인가 루프는 에이전트가 결과로부터 배우고 다음 유용한 단계를 밟도록 만드는 장치입니다. 예를 들어 단발성 프롬프트가 "이 웹사이트를 더 빠르게 만들어줘" 라고 말한다면, 루프는 여기에 피드백을 더해 "가장 느린 페이지를 찾아 한 가지만 개선하고 다시 측정하라. 도움이 될 때만 변경을 유지하고, 모든 페이지가 목표를 만족하거나 더 이상 의미 있는 개선이 나오지 않을 때까지 반복하라" 처럼 반복 가능한 형태로 바꿉니다. 좋은 루프는 네 가지 질문에 답합니다. 에이전트가 무엇을 이루려 하는가, 방금 시도가 통했는지 어떻게 알 수 있는가, 배운 것을 가지고 무엇을 해야 하는가, 그리고 언제…

---

## [Anthropic이 공개한 Claude Fable 5 프롬프팅 가이드: 강력해진 모델에 맞춰 프롬프트 다시 쓰기](https://discuss.pytorch.kr/t/anthropic-claude-fable-5/11062)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 3, 2026, 4:30오전 UTC](https://discuss.pytorch.kr/t/anthropic-claude-fable-5/11062 "2026-07-03T04:30:20Z")

</div>

Claude Fable 5 프롬프팅 가이드 소개 Anthropic이 Claude Fable 5와 Claude Mythos 5를 공개하면서, 이 모델을 실제로 잘 쓰기 위한 별도의 프롬프팅 가이드(Prompting Claude Fable 5)도 함께 내놓았습니다. Claude Fable 5 는 이전 모델인 Claude Opus 4.8로는 너무 복잡하거나, 너무 오래 걸리거나, 지시가 모호해서 다루기 어려웠던 문제까지 맡을 수 있도록 설계된 모델입니다. 사람이 몇 시간, 며칠, 심지어 몇 주에 걸쳐 처리하는 종단간(end-to-end) 작업에서 특히 강점을 보입니다. 이 가이드가 흥미로운 이유는, 단순히 "새 기능을 어떻게 쓰는가"를 다루는 문서가 아니기 때문입니다. 오히려 핵심 메시지는 조금 역설적입니다: 모델이 충분히 똑똑해졌으니, 지금까지 촘촘하게 쌓아 올린 지시와 가드레일(guardrail) 중 상당수는 이제 걷어내는 편이 낫다는 내용을 담고 있습니다. 이전 모델을 붙들기 위해 만들었던 장황한 규칙들이 오히려 Fable 5의 성능을 떨어뜨릴 수 있고, 능력이 크게 오른 지금이야말로 프롬프트와 스캐폴딩(scaffolding, 모델을 감싸는 실행 구조)을 원점에서 다시 점검할 좋은 기회라는 이야기입니다. 이 글은 그 가이드를 한국어로 정리하되, 각 권고안이 왜 필요한지, 그리고 Anthropic이 제시한 실제 프롬프트 문구를 함께 담아 여러분이 자신의 에이전트 하네스(harness)나 시스템 프롬프트에 바로 적용할 수 있도록 구성했습니다. 모든 Claude 모델에 공통으로 적용되는 일반 원칙은 Claude 프롬프트 엔지니어링 모범사례에서 이미 다룬 바 있으므로, 이 글은 그 위에 얹히는 Fable 5 고유의 행동 차이에 집중해 보도록 하겠습니다. 한 가지 미리 알아둘 점이 있습니다. Claude Fable 5는 공격적 사이버 보안 기법(익스플로잇, 멀웨어, 공격 도구 제작 등), 생물학 및 생명과학 콘텐츠(실험 방법, 분자 메커니즘 등), 그리고 모…

---

## [agentic-ai-prompt-research: 에이전트형 AI 코딩 도구의 프롬프트 구조를 재구성한 연구](https://discuss.pytorch.kr/t/agentic-ai-prompt-research-ai/10728)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [6월 26, 2026, 8:30오전 UTC](https://discuss.pytorch.kr/t/agentic-ai-prompt-research-ai/10728 "2026-06-26T08:30:45Z")

</div>

agentic-ai-prompt-research 소개 Claude Code 같은 에이전트형 AI 코딩 어시스턴트는 한 번의 요청을 처리하기 위해 시스템 프롬프트를 조립하고, 여러 하위 에이전트를 조율하고, 도구 호출을 자동으로 승인할지 판단합니다. 이 과정의 상당 부분은 사용자에게 보이지 않습니다. agentic-ai-prompt-research는 이런 내부 설계 패턴을 외부에서 관찰 가능한 행동을 근거로 재구성해 정리한 연구 저장소입니다. 프로젝트는 자신을 분명하게 규정합니다. 여기 정리된 프롬프트들은 행동 관찰과 출력 분석, 커뮤니티 논의, 공개된 정보를 바탕으로 한 재구성된 근사치이며 원문을 그대로 옮긴 사본이 아닙니다. 저자는 이 저장소가 어떤 독점 시스템의 유출이나 덤프가 아니라고 명시하고, Anthropic과 제휴하거나 보증받은 관계가 아니라는 점도 함께 밝혀 두었습니다. 즉 "이렇게 동작할 것"이라는 하나의 해석으로 읽어야 하는 자료입니다. 이 전제를 받아들이면 저장소의 가치는 분명해집니다. 프로젝트의 목표는 AI 엔지니어와 연구자, 빌더가 프로덕션급 에이전트 코딩 도구의 아키텍처 패턴을 학습하고 자신의 프로젝트에 응용하도록 돕는 것입니다. 시스템 프롬프트가 런타임에 어떻게 조립되는지, 여러 전문 하위 에이전트가 어떻게 협업하는지, 도구 호출을 어떻게 안전하게 분류하고 자동 승인하는지, 긴 세션에서 컨텍스트를 어떻게 압축하는지 같은 질문을 다룹니다. agentic-ai-prompt-research가 문서화한 프롬프트 패턴 저장소의 prompts/ 디렉토리에는 1번부터 30번까지 번호가 매겨진 패턴 문서가 주제별로 묶여 있습니다. 저자는 이 30개 문서를 핵심 정체성, 오케스트레이션, 전문 에이전트, 보안·권한, 컨텍스트·동적 동작, 유틸리티·도구·스킬의 여섯 영역으로 정리합니다. 핵심 정체성(Core Identity)에는 모듈식 섹션으로 조립되는 메인 시스템 프롬프트, 경량 동작을 위한 단순 모드, 모든 하위 에이전트가 상속하는 …

---

## [ponytail: AI 코딩 에이전트가 꼭 필요한 코드만 쓰게 만드는 규칙셋](https://discuss.pytorch.kr/t/ponytail-ai/10859)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [6월 22, 2026, 4:00오전 UTC](https://discuss.pytorch.kr/t/ponytail-ai/10859 "2026-06-22T04:00:47Z")

</div>

ponytail 소개 AI 코딩 에이전트에게 날짜 선택기를 만들어 달라고 하면, 에이전트는 flatpickr 같은 라이브러리를 설치하고 래퍼 컴포넌트를 작성한 뒤 스타일시트를 추가하고 타임존 처리를 어떻게 할지 논의하기 시작합니다. 정작 필요한 것은 브라우저에 이미 들어 있는 \<input type="date"\> 한 줄인데도 그렇습니다. ponytail은 이렇게 에이전트가 과제에 비해 과하게 코드를 만들어내는 문제를 겨냥한 크로스 에이전트(cross-agent) 규칙셋입니다. ponytail은 에이전트가 코드를 쓰기 전에 먼저 "이게 정말 필요한가, 더 적게 쓸 방법은 없는가"를 따지도록 만드는 규칙을 주입합니다. 저자는 이 규칙을 "회사보다 오래 근무한, 긴 머리를 묶은 시니어 개발자" 에 비유합니다. 오십 줄짜리 코드를 보여주면 아무 말 없이 한 줄로 바꿔놓는 그런 인물을 에이전트 안에 넣는다는 것입니다. 다만 핵심 원칙은 "가장 적은 토큰" 이 아니라 "과제에 필요한 만큼만 쓰되, 검증·에러 처리·보안·접근성은 절대 깎지 않는다" 입니다. 게으르지만 부주의하지는 않다는 것이 이 도구가 강조하는 선입니다. ponytail은 특정 에이전트에 묶이지 않고 14종의 에이전트에서 동작합니다. Claude Code, Codex, GitHub Copilot CLI 등에는 플러그인이나 스킬 형태로 설치되고, Cursor나 Windsurf 같은 편집기형 에이전트에는 규칙 파일을 복사해 적용합니다. 적용 강도는 lite, full, ultra, off 네 단계로 조절할 수 있고, 변경된 코드를 점검하는 /ponytail-review 같은 보조 명령도 함께 제공합니다. ponytail의 동작 원리 ponytail의 규칙은 에이전트가 코드를 작성하기 직전에 아래 사다리(ladder)를 위에서부터 훑어 내려가다가, 처음으로 성립하는 단(rung)에서 멈추도록 합니다. 1. 이 기능이 존재할 필요가 있는가? → 없다: 만들지 않는다 (YAGNI) 2. 표준 라…

---

## [Skills For Real Engineers: Matt Pocock이 정리한, 실전 엔지니어링을 위한 Claude Code 스킬 모음](https://discuss.pytorch.kr/t/skills-for-real-engineers-matt-pocock-claude-code/10188)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [6월 12, 2026, 11:30오전 UTC](https://discuss.pytorch.kr/t/skills-for-real-engineers-matt-pocock-claude-code/10188 "2026-06-12T11:30:15Z")

</div>

Skills For Real Engineers 소개 Skills For Real Engineers(이하 skills)는 Total TypeScript와 ai-hero.dev로 잘 알려진 매트 포코크(Matt Pocock)가 자신의 ~/.claude 디렉토리에서 매일 사용하는 에이전트 스킬(Agent Skill)을 그대로 공개한 오픈소스 프로젝트입니다. 이 저장소는 "Vibe Coding"이 아닌 "실전 엔지니어링(Real Engineering)"을 코딩 에이전트와 함께 수행하기 위한 작은 단위의 스킬들을 모아 두었습니다. 게시 시점에 이미 75,000개가 넘는 GitHub 스타가 모일 정도로 빠르게 확산되며, 매트 포코크가 운영하는 6만 명 이상의 뉴스레터 구독자층과 함께 Claude Code, Codex 등 다양한 코딩 에이전트 사용자의 표준 워크플로우 후보로 자리잡고 있습니다. 이 프로젝트가 흥미로운 이유는 GSD(Get Shit Done), BMAD, Spec-Kit 같이 프로세스 전체를 통째로 가져가는 거대한 프레임워크와 달리, 각 스킬이 "작고(small)", "수정하기 쉽고(easy to adapt)", "조합 가능한(composable)" 단위라는 점입니다. 한 스킬이 한 가지 실패 모드(failure mode)에 대응하도록 설계되어 있기 때문에, 사용자는 필요한 스킬만 골라서 자신의 저장소에 설치하고 원하는 대로 손볼 수 있습니다. 모델 종속성이 없어 Claude Code 외에 다른 코딩 에이전트와도 함께 쓸 수 있는 점도 장점입니다. 매트 포코크는 이 스킬들이 "코딩 에이전트가 흔히 보이는 실패 모드"를 해결하기 위한 시도라고 설명합니다. 에이전트가 사용자의 의도를 잘못 이해하거나(misalignment), 지나치게 장황한 결과물을 내놓거나(verbose), 동작하지 않는 코드를 만들거나(broken), 점점 누더기처럼 변해가는(ball of mud) 네 가지 문제를 각각 다른 스킬로 다루며, 이를 위해 도메인 주도 설계(DDD), 테…

---

## [Claude 프롬프트 엔지니어링 모범사례: Anthropic 공식 가이드 총정리](https://discuss.pytorch.kr/t/claude-anthropic/10447)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [5월 30, 2026, 10:30오전 UTC](https://discuss.pytorch.kr/t/claude-anthropic/10447 "2026-05-30T10:30:11Z")

</div>

Claude 프롬프트 엔지니어링 가이드 소개 Anthropic이 Claude 최신 모델군을 위한 프롬프트 엔지니어링 모범사례(Best Practices) 문서를 단일 레퍼런스로 정리해 공개했습니다. 이 가이드는 새로 출시된 Claude Opus 4.8을 비롯해 Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 4.6, Claude Haiku 4.5까지를 대상으로, 기초적인 명료성 원칙부터 출력 제어, 도구 사용, 사고(thinking), 그리고 에이전트 시스템 설계에 이르는 내용을 한 곳에 담고 있습니다. 흥미로운 점은 이 문서가 단순한 팁 모음이 아니라, 모델 세대가 바뀔 때마다 어떤 프롬프트를 어떻게 다시 손봐야 하는지에 대한 마이그레이션 관점을 전면에 내세우고 있다는 것입니다. 프롬프트 엔지니어링은 한때 "마법 주문 찾기"처럼 여겨졌지만, 최신 모델이 지시를 점점 더 문자 그대로(literal) 따르게 되면서 그 성격이 달라졌습니다. 과거에는 모델이 알아서 의도를 추측해주길 기대하며 모호한 프롬프트를 던졌다면, 이제는 원하는 동작을 명확히 명시하고 모델 세대별 기본값(default)의 변화를 이해하는 것이 핵심 역량이 되었습니다. 특히 Claude Opus 4.6 이후 모델들은 시스템 프롬프트에 훨씬 민감하게 반응하기 때문에, 이전 모델을 위해 작성된 "CRITICAL: 반드시 ~하라" 같은 강한 표현이 오히려 과잉 동작(overtriggering)을 유발하는 역설이 나타납니다. 이 게시물은 원문 가이드를 바탕으로, Claude API와 Claude Code 같은 에이전트 환경에서 모델을 다루는 개발자가 알아야 할 핵심 원칙들을 주제별로 재구성한 것입니다. 각 절에는 원문의 권장 프롬프트 스니펫을 영어 원문 그대로 함께 실어, 실제 시스템 프롬프트에 바로 옮겨 쓸 수 있도록 했습니다. 새로 추가된 Claude Opus 4.8 전용 프롬프팅부터 살펴보겠습니다. Claude Opus 4.8 전용 프롬프팅: 새 모…

---

## [12-Factor Agents: 운영 환경에서 신뢰할 수 있는 LLM 에이전트를 만들기 위한 12가지 원칙](https://discuss.pytorch.kr/t/12-factor-agents-llm-12/10384)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [5월 28, 2026, 12:30오전 UTC](https://discuss.pytorch.kr/t/12-factor-agents-llm-12/10384 "2026-05-28T00:30:20Z")

</div>

12-Factor Agents 소개 12-Factor Agents는 "What are the principles we can use to build LLM-powered software that is actually good enough to put in the hands of production customers?" 라는 한 줄 질문에서 출발하는 LLM 에이전트 설계 원칙 모음입니다. HumanLayer의 Dex가 정리해 공개한 12개의 원칙 으로, 이름에서 짐작되듯이 12 Factor Apps 의 정신을 LLM 기반 소프트웨어에 옮긴 형태를 취합니다. 저자는 plug-and-play 프레임워크(예: CrewAI, LangChain)부터 minimalist smolagents, production-grade LangGraph, Griptape에 이르기까지 "every agent framework out there" 를 다 사용해 본 뒤, 실제 운영에서 고객을 대상으로 동작하는 에이전트 대부분이 결국 "mostly just software" 라는 결론에 도달했다고 12-Factor Agents 저장소에서 밝힙니다. 즉, "goal과 tool 한 바구니, loop until done" 류의 패턴(Anthropic의 Building Effective Agents 글에서 정의된 형태)을 그대로 따르는 제품은 운영 단계에서 잘 살아남지 못한다는 진단입니다. 전통적인 코드는 본질적으로 모든 엣지가 사람 손으로 정의된 방향 그래프(Directed Graph, DG) 이고, 지난 20년간 Airflow / Prefect / Dagster / Inngest / Windmill 같은 DAG 오케스트레이터가 그 위에 관측성·재시도·관리 기능을 얹어 왔습니다. 12-Factor Agents 저장소에서는 "에이전트의 약속은 이 DAG를 던져 버리는 것" 이라고 정리합니다. 엔지니어가 노드와 엣지를 모두 코딩하는 대신 "목표(goal)와 가능한 전이(transitions)만…

---

## [Awesome GPT Image 2 API & Prompts: GPT-Image-2를 위한 359개 이상의 큐레이션된 프롬프트와 API 워크플로우 모음](https://discuss.pytorch.kr/t/awesome-gpt-image-2-api-prompts-gpt-image-2-359-api/10134)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [5월 11, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/awesome-gpt-image-2-api-prompts-gpt-image-2-359-api/10134 "2026-05-11T06:30:15Z")

</div>

Awesome GPT Image 2 API & Prompts 소개 OpenAI가 ChatGPT에 통합 형태로 공개한 GPT-Image-2(gpt-image-2)는 텍스트로부터 이미지를 생성하고 기존 이미지를 텍스트 지시로 편집하는 멀티모달(Multimodal) 이미지 모델입니다. 이전 모델인 DALL·E 3 대비 프롬프트 충실도(Prompt Adherence)가 크게 개선되었고, 이미지 안에 정확한 텍스트를 렌더링하거나, 종횡비와 투명 배경을 직접 지원하며, 동일한 캐릭터의 일관성(Consistent Character Generation)을 유지한 채 여러 장면을 생성할 수 있다는 점이 가장 큰 차별점입니다. ChatGPT 인터페이스에서는 자연어 대화로 반복 편집(Iterative Refinement)이 가능하고, OpenAI API의 /v1/images/generations 엔드포인트를 통해 동일한 모델을 코드에서 호출할 수 있어 마케팅, 커머스, UI 디자인 등 다양한 워크플로에 결합하기 좋습니다. Awesome GPT Image 2 API & Prompts(공식 저장소 이름은 awesome-gpt-image-2-API-and-Prompts)는 이러한 GPT-Image-2의 잠재력을 실제 결과물 수준에서 정리한 큐레이션 모음입니다. 359개 이상의 검증된 프롬프트와 실제 출력 이미지가 7개 카테고리로 분류되어 있으며, 각 케이스는 별도의 출처 트윗과 작성자가 명시되어 있습니다. 단순한 한두 줄짜리 예시 모음이 아니라, 실제 광고 캠페인이나 e-커머스 메인 이미지처럼 production-ready 수준의 긴 프롬프트가 그대로 수록되어 있어 그대로 복제해 변수만 치환하는 식으로 활용할 수 있습니다. 또한 각 프롬프트에는 {argument name="..." default="..."} 형식의 인자(Argument) 슬롯이 포함되어 있어 브랜드명, 슬로건, 색상 같은 부분을 손쉽게 교체할 수 있도록 설계되어 있습니다. Awesome GPT Image 2 …

---

## [Prompt Master: 다양한 AI 도구를 위한 최적의 프롬프트를 자동으로 작성해주는 Claude 스킬](https://discuss.pytorch.kr/t/prompt-master-ai-claude/9910)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 2\
**마지막 업데이트:** [5월 5, 2026, 1:44오전 UTC](https://discuss.pytorch.kr/t/prompt-master-ai-claude/9910 "2026-05-05T01:44:56Z")

</div>

Prompt Master 소개 AI 도구를 활용하다 보면 같은 작업을 반복적으로 재시도하는 데 시간과 비용을 낭비하는 경우가 많습니다. 의도를 모호하게 전달하거나 형식을 지정하지 않으면, 모델은 잘못된 가정을 세우고 엉뚱한 결과물을 생성합니다. 이렇게 쌓이는 낭비는 하루에 50개의 프롬프트를 작성할 경우 수십 번의 재시도로 이어지며, 실제 비용과 시간에 직접적인 영향을 미칩니다. Prompt Master는 이 문제를 해결하기 위해 설계된 Claude 스킬(Skill)로, 어떤 AI 도구에도 최적화된 프롬프트를 단번에 작성해 줍니다. Prompt Master의 핵심 철학은 "가장 좋은 프롬프트는 가장 긴 프롬프트가 아니라, 모든 단어가 결과에 기여하는 프롬프트"입니다. 대부분의 프롬프트 생성 도구들이 프롬프트를 더 길게 만드는 방향으로 동작하는 것과 달리, Prompt Master는 프롬프트를 더 날카롭게(sharper) 만드는 데 집중합니다. 사용자의 요청을 9가지 차원(작업, 입력, 출력, 제약, 맥락, 청중, 기억, 성공 기준, 예시)으로 분해하고, 누락된 핵심 정보가 있을 때는 최대 3개의 명확화 질문만 요청합니다. 그 결과 불필요한 반복 없이 목표에 정확히 도달하는 프롬프트를 자동으로 생성합니다. Prompt Master는 Claude, ChatGPT, Gemini, o1/o3, Cursor, Claude Code, GitHub Copilot, Midjourney, DALL-E, Stable Diffusion, Sora, ElevenLabs, Zapier, Make 등 18개 이상의 AI 도구 프로파일을 내장하고 있습니다. 각 도구의 특성에 맞는 9가지 프롬프트 프레임워크인 RTF, CO-STAR, RISEN, CRISPE, Chain of Thought, Few-Shot, File-Scope Template, ReAct, Visual Descriptor 등을 자동으로 선택하고, 35가지 일반적인 프롬프트 실수 패턴을 감지해 교정합니다. 프레임…

---

## [Wharton 생성형 AI 연구실의 프롬프트에 대한 연구(Prompting Science Report) 1~4편: 프롬프트 엔지니어링, CoT, 동기부여, 페르소나 부여](https://discuss.pytorch.kr/t/wharton-ai-prompting-science-report-1-4-cot/8512)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [12월 25, 2025, 3:30오전 UTC](https://discuss.pytorch.kr/t/wharton-ai-prompting-science-report-1-4-cot/8512 "2025-12-25T03:30:39Z")

</div>

Wharton 생성형 AI 연구실(GAIL, Generative AI Labs) 소개 Wharton Generative AI Labs(GAIL)는 펜실베이니아 대학교 와튼 스쿨(The Wharton School) 산하의 연구 기관으로, 생성형 AI의 기술적 발전과 비즈니스 및 교육적 활용을 연결하는 것을 목표로 합니다. 이 연구소는 단순한 이론적 연구를 넘어, 실제 프로토타입을 개발하고 엄격한 테스트를 거쳐 인간이 AI와 함께 성장하고 성공할 수 있는 방법을 모색합니다. 특히 AI가 교육과 업무 방식을 어떻게 변화시킬 수 있는지에 대해 과학적이고 실증적인 접근을 취하고 있습니다. GAIL은 엄격한 테스트(Rigorous Testing) 를 핵심 가치로 삼습니다. AI 커뮤니티에 만연한 '검증되지 않은 프롬프트 팁(folk prompting)'이나 과대광고(hype)를 배제하고, 통계적으로 유의미한 실험을 통해 무엇이 실제로 작동하는지를 밝혀냅니다. Primer Initiative: 교육자를 위한 AI 도구 개발 프로젝트로, 기술적 전문 지식 없이도 맞춤형 학습 경험을 만들 수 있도록 지원합니다. The Studio: 학생들이 실제 작동하는 AI 프로토타입을 개발하는 프로그램입니다. Prompting Science Reports: 본 보고서 시리즈와 같이, 최신 LLM(Large Language Model)의 프롬프트 엔지니어링 기법을 과학적으로 검증하여 공개합니다. Prompting Science Report 1편: 프롬프트 엔지니어링은 복잡하고 상황에 따라 다르다 (Prompt Engineering is Complicated and Contingent) 연구 개요 Prompting Science Report의 첫번째 연구는 AI 프롬프트 엔지니어링에 대한 일반적인 믿음, 예를 들어 "AI에게 예의 바르게 말하면 성능이 좋아진다"거나 "특정 형식을 지정하면 더 잘한다"는 주장이 항상 참인지 검증합니다. 실험 결과, 단일한 '매직 프롬프트'는 …

---

## [AdalFlow: 자동 프롬프트 최적화 및 LLM 워크플로우 구현을 위한 오픈소스 라이브러리](https://discuss.pytorch.kr/t/adalflow-llm/7260)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 15, 2025, 1:30오전 UTC](https://discuss.pytorch.kr/t/adalflow-llm/7260 "2025-07-15T01:30:07Z")

</div>

AdalFlow 소개 요즘 자연어처리(NLP)와 생성형 AI(Generative AI)의 중심에는 LLM(Large Language Model)이 자리하고 있습니다. 챗봇, 질의응답 시스템, 문서 요약, 코드 생성 등 다양한 영역에서 LLM은 핵심 기술로 활용되고 있지만, 실제 애플리케이션으로 LLM을 적용하는 과정은 여전히 복잡합니다. 특히, 프롬프트를 수동으로 작성하고 모델의 성능을 개선하기 위해 반복적인 실험을 수행하는 과정은 비효율적이고 확장성도 떨어지는 방식입니다. 이런 상황에서 등장한 것이 바로 AdalFlow입니다. AdalFlow는 PyTorch 스타일로 설계된 LLM 응용 프로그램 빌딩 및 최적화 프레임워크로, 프롬프트 튜닝 및 다양한 LLM 응용 워크플로우를 자동화하는 데 중점을 둔 오픈소스 라이브러리입니다. 자동 미분(auto-differentiation) 기법을 통해 프롬프트 최적화를 수행하며, 특정 LLM 제공자에게 종속되지 않고 다양한 LLM을 손쉽게 교체할 수 있도록 설계된 것이 큰 특징입니다. 특히 RAG(Retrieval-Augmented Generation), Agent 시스템, 텍스트 분류 등의 작업을 일관된 방식으로 처리할 수 있게 해주는 강력한 구성 요소들을 제공합니다. DSPy와 AdalFlow의 차이점 AdalFlow는 Stanford NLP에서 만든 DSPy와 유사한 목표를 가지고 있습니다. 두 라이브러리 모두 few-shot 프롬프트 최적화, 구성형 워크플로우, 모델-비종속 구성 요소를 지향하지만 다음과 같은 차이가 있습니다: 자동 미분 최적화: AdalFlow는 Micrograd 스타일의 텍스트 자동 미분을 통해 최적화된 프롬프트를 학습합니다. 반면 DSPy는 search 기반 또는 부트스트랩 방식의 최적화를 제공합니다. 구성 요소 설계: PyTorch의 Component, Sequential, Parameter 구조에서 영감을 받아 구조적이고 직관적인 API를 제공합니다. 파이프라인 학습: Ad…

---

## [AgentMark: 개발자를 위한 AI 프롬프트 엔지니어링 플랫폼](https://discuss.pytorch.kr/t/agentmark-ai/7245)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 11, 2025, 9:30오전 UTC](https://discuss.pytorch.kr/t/agentmark-ai/7245 "2025-07-11T09:30:49Z")

</div>

AgentMark 소개 AgentMark는 AI 시대의 프롬프트 엔지니어링을 위해 설계된 차세대 오픈소스 플랫폼입니다. 이 프로젝트는 LLM(대규모 언어 모델) 애플리케이션 개발에서 필수적인 ‘프롬프트’와 ‘에이전트’의 설계·테스트·관리를 한층 직관적이고 강력하게 만들어 줍니다. 기존에는 자연어 프롬프트를 코드에 하드코딩하거나, JSON/YAML 등 복잡한 템플릿을 사용하여 프롬프트를 다뤄야 했지만, AgentMark는 마크다운(Markdown) 의 가독성과 JSX(React의 컴포넌트 구조와 유사한 문법)의 유연성을 결합하여 새로운 개발 경험을 제공합니다. 특히 AgentMark는 “코드와 프롬프트, 모델 설정의 완전 분리”를 목표로 하고 있습니다. 덕분에 프롬프트 파일 하나만으로도 AI 워크플로우를 설계하고, 코드 및 모델의 변화와 상관없이 손쉽게 재사용할 수 있습니다. 또한 AgentMark는 OSS(Open Source Software) 런타임을 통해 모든 프롬프트와 에이전트 로직을 로컬 환경에서 안전하게 실행할 수 있어, 기업 보안과 민감 정보 활용에도 유리합니다. AgentMark의 등장 배경과 필요성 최근 ChatGPT, GPT-4, Claude 등 다양한 LLM의 등장과 함께, AI 서비스·에이전트 개발의 초점이 “프롬프트 엔지니어링”으로 이동하고 있습니다. 더 이상 단순한 입력-출력 수준의 프롬프트로는 복잡한 사용자 요구나 다단계 에이전트 플로우를 구현하기 어렵습니다. 하지만 기존 프롬프트 관리 방식은 다음과 같은 한계가 있었습니다: 가독성 부족: 코드 속에 프롬프트가 하드코딩되어 있거나, 비직관적인 JSON 템플릿으로 관리되어 실제 LLM에게 어떤 입력이 전달되는지 파악하기 어렵습니다. 재사용성·이식성 미약: 프롬프트가 코드·모델 설정과 뒤섞여 있어, 프로젝트 간 재활용이나 환경 이전이 번거롭습니다. 동적/복잡한 로직 한계: 조건 분기, 반복, 데이터 변환 등 동적 처리가 필요한 경우 별도 코드 작…

---

## [Chain-of-Draft(CoD): 더 적게 쓰고 더 빠르게 생각하면서 LLM 추론 성능을 높이는 기법에 대한 연구 (feat. Zoom)](https://discuss.pytorch.kr/t/chain-of-draft-cod-llm-feat-zoom/6350)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [3월 9, 2025, 9:30오후 UTC](https://discuss.pytorch.kr/t/chain-of-draft-cod-llm-feat-zoom/6350 "2025-03-09T21:30:36Z")

</div>

Chain-of-Draft (CoD) 연구 소개 대규모 언어 모델(LLM, Large Language Model)의 성능을 높이는 방법 중 하나로, 생각의 사슬(CoT, Chain-of-Thought)과 같은 프롬프팅 기법이 사용되고 있습니다. 생각의 사슬(CoT)은 복잡한 추론 문제를 해결하는데 있어, 단계별로 상세한 추론 과정을 제공하는 방식입니다. 하지만 CoT는 추론 과정에서 상당한 연산 자원을 필요로 하며, 결과적으로 장황한 출력을 생성하고 지연 시간을 증가시키는 문제가 있습니다. 반면, 인간은 문제를 해결할 때 긴 설명을 적는 것이 아니라 핵심적인 정보만을 요약한 초안(draft)이나 메모를 작성하는 방식을 선호합니다. 초안의 사슬(CoD, Chain-of-Draft)라는 이름의 연구는 인간과 같이 초안이나 메모를 작성하는 방식의 새로운 프롬프팅 전략을 제안하고 있습니다. 즉, 기존의 CoT 방법보다 더 인간적인 사고와 유사하게 '효율성과 최소주의'를 추구합니다. CoD는 추론 중간에 장황한 설명 대신 핵심 정보만 간결하게 포함하는 방식으로 모델을 유도하여 추론 속도와 연산 비용을 줄이면서도 정확도를 유지할 수 있습니다. 저자들은 CoD의 효과를 검증하기 위해, 수학적 추론(arithmetic reasoning), 상식적 추론(commonsense reasoning), 기호적 추론(symbolic reasoning) 등 다양한 벤치마크에서 실험을 수행하였습니다. 그 결과, CoD는 기존 CoT와 동일하거나 더 높은 정확도를 기록하면서도 토큰 사용량과 지연 시간을 대폭 절감하는 것으로 나타났습니다. Chain-of-Draft 프롬프팅 기법 소개 CoT(Chain-of-Thought) 기법은 단계별(Step-by-Step)로 추론을 수행하는 방식으로 복잡한 문제 해결에 효과적이라는 점은 이미 입증되었습니다. 하지만, CoT 방식은 추론 과정이 지나치게 장황해지고 토큰 사용량이 많은 단점이 있습니다. 즉, CoT는 문제 해결 과정을…

---

## [Claude 개발사 Anthropic, 여러 분야의 프롬프트를 공유하는 Prompt Library 공개](https://discuss.pytorch.kr/t/claude-anthropic-prompt-library/3840)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [3월 23, 2024, 4:26오전 UTC](https://discuss.pytorch.kr/t/claude-anthropic-prompt-library/3840 "2024-03-23T04:26:02Z")

</div>

Cluade 개발사 Anthropic이 최근 다양한 비즈니스 및 개인 작업을 위해 최적화된 프롬프트를 제공하는 프롬프트 라이브러리를 공개했습니다. LLM이 직간접적으로 서비스에 적용되며 프롬프트 기반의 상호 작용은 개발자 뿐만 아니라 일반 사용자들에게도 점점 중요해지고 있습니다. Anthropic의 이번 공개는 LLM의 실제 적용 사례와 함께, 프롬프트 설계와 구현에 대한 심층적인 이해를 제공합니다. AI 분야에서 프롬프트 라이브러리의 공개는 이론과 실제의 간극을 좁히고, 더 나아가 사용자와 AI간의 상호작용을 풍부하게 만드는 기회를 제공할 것으로 예상합니다. 소개 Anthropic의 프롬프트 라이브러리는 개인화된 상호작용, 데이터 처리, 문서 작성 등 다양한 작업을 위해 설계된 최적화된 프롬프트의 집합입니다. 이 라이브러리는 사용자들이 자신의 프로젝트나 작업에 쉽게 적용할 수 있도록 구체적인 예시와 코드 스니펫을 제공합니다. 프롬프트 엔지니어링은 AI 개발에서 중요한 부분으로 자리잡고 있으며, Anthropic의 이번 공개는 이 분야에 대한 관심과 연구를 촉진시킬 것으로 보입니다. 주요 기능 이 라이브러리는 비즈니스 보고서 분석, 웹사이트 생성, 엑셀 수식 작성, 구글 앱스 스크립트 생성 등 다양한 주제를 아우릅니다. 또한, Python 코드 디버깅, SQL 쿼리 생성, 문서의 PII(Personally Identifiable Information) 제거 등 개발자와 기술 전문가들이 자주 마주치는 문제들을 해결하기 위한 프롬프트도 포함되어 있습니다. 사용자 제출 프롬프트 기능은 이 라이브러리를 지속적으로 성장시키고, AI 커뮤니티의 참여를 독려하는 중요한 역할을 합니다. 프롬프트 예시 Email Extractor 프롬프트 이 프롬프트는 문서에서 이메일 주소를 추출하여 JSON 형식의 리스트로 변환하는 기능을 제공합니다. 이는 이메일 마케팅 캠페인, 연락처 관리, 데이터 정리 작업 등에서 유용하게 사용될 수 있습니다. 사용자가 제공하는 문서에서 이…

---

## [\[GN⁺\] 나의 LLM 코드생성 워크플로우](https://discuss.pytorch.kr/t/gn-llm/6181)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 1\
**마지막 업데이트:** [2월 20, 2025, 12:31오후 UTC](https://discuss.pytorch.kr/t/gn-llm/6181 "2025-02-20T12:31:34Z")

</div>

글 요약 (TL;DR) tldr: 스펙을 브레인스토밍하고, 계획을 세운 다음, LLM codegen을 이용해 실행함. 개별 반복 루프. 그러면 마법이 일어남 나는 LLM을 이용해 다양한 소규모 제품을 빠르게 만들고 있음. 재미있고, 유용함 그러나 잘못된 접근에 빠지면 시간을 크게 낭비할 수 있음 많은 개발자들이 서로 비슷한 접근 방식을 가지고 있고, 아래는 나의 워크플로우임 "지금은 잘 작동하고 있지만 2주 후에는 작동하지 않거나 두 배로 작동할 수 있음" 개발 하는 방법은 2가지가 있음 그린필드 코드: 새로운 프로젝트를 시작 레거시 모던 코드: 기존 코드베이스를 개선하거나 확장 Greenfield: 처음부터 새로 시작하기 “처음부터 시작하는” 상황에 잘 맞는 프로세스임 아이디어를 브레인스토밍하고, 문서화하고, 작은 단계별 계획을 세운 뒤 코드 생성 툴을 사용해 구현하는 흐름임 Step 1: 아이디어 구체화 ChatGPT 같은 LLM에 아이디어를 설명하면서, 하나씩 질문을 유도해 구체적인 스펙으로 정제함 마지막에는 상세한 스펙(spec.md)을 만들어 개발자에게 넘길 수 있는 문서 형태로 정리함 필요하면 Deep Research 같은 툴로 아이디어에 대한 근거 자료를 얻을 수도 있음 Step 2: 계획 수립 스펙을 기반으로, 더 강력한 “이해·추론” 모델에게 세부 단계별 청사진을 생성하도록 요청함 TDD 방식이든 아니든, 각 단계별로 작은 작업 단위를 만들고 순서대로 정리함 이런 프로세스를 통해 prompt\_plan.md와 todo.md를 생성함 prompt\_plan.md는 코드 생성에 필요한 프롬프트 설계를, todo.md는 체크리스트를 포함함 이 계획 수립은 15분 정도면 충분한 편이며, 나중에 참조하기도 쉬움 Step 3: 실행 Aider, Cursor, Claude 등 다양한 코드 생성·도움 툴을 사용해 실제 코드를 작성함 대표적으로 Claude와 Aider를 예로 들 수 있음 Claude 방식 미리 프로젝트…

---

## [\[2024/08/05 ~ 08/11\] 이번 주의 주요 ML 논문 (Top ML Papers of the Week)](https://discuss.pytorch.kr/t/2024-08-05-08-11-ml-top-ml-papers-of-the-week/5018)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [8월 11, 2024, 9:25오후 UTC](https://discuss.pytorch.kr/t/2024-08-05-08-11-ml-top-ml-papers-of-the-week/5018 "2024-08-11T21:25:46Z")

</div>

\[2024/08/05 ~ 08/11\] 이번 주의 주요 ML 논문 (Top ML Papers of the Week) PyTorchKR​:fire::south\_korea: :thinking::speech\_balloon: 이번 주에 선정된 논문들에서는 몇 가지 두드러진 트렌드가 관찰되었습니다. 첫 번째로, 대규모 언어 모델(LLMs)을 활용한 연구가 주를 이루고 있습니다. 논문 제목을 보면, 'From LLMs to LLM-based Agents for Software Engineering', 'Enhancing LLMs for RAG', 'Synthesizing Text-to-SQL Data from Weak and Strong LLMs'와 같은 제목들이 포함되어 있습니다. 이는 대규모 언어 모델의 응용과 관련된 연구가 활발히 진행되고 있다는 것을 보여줍니다. 두 번째 트렌드는 설명 가능 인공지능(XAI)과 관련된 연구입니다. 이 주제는 'Transformer Explainer' 논문에서 잘 드러나며, 그 외에도 'Self-Taught Evaluators'와 같은 논문이 이와 관련된 내용을 다루고 있습니다. 이러한 연구들은 인공지능 모델의 내부 작동 방식을 더 잘 이해하고 설명할 수 있는 기법들을 개발하는 데 초점을 맞추고 있습니다. 이러한 트렌드가 두드러지는 이유는 여러 가지가 있습니다. 첫째, 대규모 언어 모델은 최근 몇 년 동안 비약적인 성능 향상을 보여 왔기 때문에 많은 연구자들이 이를 다양한 도메인에 적용하여 새로운 가능성을 탐구하고 있습니다. 특히 소프트웨어 엔지니어링이나 데이터 기반 질의 생성 등 특정 분야에 특화된 LLM 사용 사례가 증가하고 있습니다. 둘째, 설명 가능 인공지능(XAI, eXplainable AI)에 대한 관심은 인공지능 모델의 투명성과 신뢰성을 높이기 위한 필수 요소로 자리매김하고 있습니다. 모델의 결정 과정을 이해하고 설명할 수 있는 능력은 다양한 실세계 응용 분야에서 필수적입니다. 따라서 XAI 기술을 연구…

---

## [\[2024/07/15 ~ 07/21\] 이번 주의 주요 ML 논문 (Top ML Papers of the Week)](https://discuss.pytorch.kr/t/2024-07-15-07-21-ml-top-ml-papers-of-the-week/4894)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 22, 2024, 1:02오전 UTC](https://discuss.pytorch.kr/t/2024-07-15-07-21-ml-top-ml-papers-of-the-week/4894 "2024-07-22T01:02:57Z")

</div>

\[2024/07/15 ~ 07/21\] 이번 주의 주요 ML 논문 (Top ML Papers of the Week) PyTorchKR​:fire::south\_korea: :thinking::speech\_balloon: 이번 주에 선정된 논문들을 살펴볼 때, 큰 트렌드 중 하나는 LLMs(대규모 언어 모델)과 관련된 연구가 주를 이루고 있다는 점입니다. "Improving Legibility of LLM Outputs", "SpreadsheetLLM", "A Survey of Prompt Engineering Methods in LLMs", "Does Refusal Training in LLMs Generalize to the Past Tense?", "Can LLMs Do Retrieval and Reasoning in 1 Million Context Window?"와 같은 제목을 통해, 연구자들이 LLMs의 다양한 측면을 탐구하고 있음을 알 수 있습니다. 이는 LLMs가 인공지능 연구와 응용에 있어 중요한 분야로 자리 잡고 있음을 나타내며, 특히 이러한 모델의 효율성, 이해력, 그리고 범용성 향상에 초점이 맞춰져 있는 것으로 보입니다. 또한, 여러 논문들은 LLMs의 성능을 개선하거나 이해하기 위한 새로운 방법론들을 제안하고 있습니다. 예를 들어, "Distilling System 2 into System 1"이나 "Weak-to-Strong Reasoning"은 추론 과정과 LLMs의 결론 도출 메커니즘을 보다 효율적으로 만들고자 하는 시도를 담고 있습니다. 이는 인공지능 분야에서 추론(reasoning)과 지식 표현(knowledge representation)의 중요성이 점점 더 강조되고 있음을 시사합니다. 반면, "Beyond Euclid"는 좀 더 이론적이거나 추상적인 수학적 개념을 LLMs와 연결짓는 시도로 보이며, 이는 LLMs의 적용 범위를 확장하고자 하는 노력의 일환으로 해석될 수 있습니다. 종합하자면, 이번 주 선택된 논문들은 …

---

## [\[2024/06/03 ~ 06/09\] 이번 주의 주요 ML 논문 (Top ML Papers of the Week)](https://discuss.pytorch.kr/t/2024-06-03-06-09-ml-top-ml-papers-of-the-week/4600)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [6월 10, 2024, 5:51오전 UTC](https://discuss.pytorch.kr/t/2024-06-03-06-09-ml-top-ml-papers-of-the-week/4600 "2024-06-10T05:51:32Z")

</div>

\[2024/06/03 ~ 06/09\] 이번 주의 주요 ML 논문 (Top ML Papers of the Week) PyTorchKR​:fire::south\_korea: :thinking::speech\_balloon: 이번 주에 선정된 논문들을 살펴보면, 대부분의 논문이 대규모 언어 모델(LLMs)에 초점을 맞추고 있는 경향이 있습니다. 구체적으로는, 대규모 언어 모델의 개념 추출(Extracting Concepts from GPT-4), 효율성 향상(MatMul-free LLMs), 모델의 사고 과정 이해(Buffer of Thoughts), LLMs의 기하학적 구조(The Geometry of Concepts in LLMs), 그리고 이들 모델의 정렬(Aligning LLMs with Demonstrated Feedback, Towards Scalable Automated Alignment of LLMs)에 대한 연구로 요약할 수 있습니다. 이들 주제는 인공지능 분야에서 LLMs의 이해, 개선, 그리고 적용 가능성을 탐색하는 현재의 관심사를 반영하고 있습니다. 비록 모든 논문의 내용을 상세히 살펴본 것은 아니지만, 제목만으로도 최근 연구의 경향을 파악하는 데 충분해 보입니다. 이 같은 경향은 몇 가지 이유로 설명될 수 있습니다. 먼저, GPT-4와 같은 대규모 언어 모델의 성공 이후 인공지능 연구 분야에서 이러한 모델들에 대한 관심이 급증했습니다. 이러한 모델들은 자연어 처리(NLP)는 물론, 다양한 지식 작업에서 인간 수준의 성능을 달성하는 데 중요한 역할을 하고 있습니다. 두 번째로, LLMs의 이해와 발전은 더 복잡하고 창의적인 작업을 수행할 수 있는 AI 시스템 개발로 이어질 수 있는 기회를 제공합니다. 마지막으로, 이러한 연구는 AI의 안전성과 윤리적 사용을 강화하는 데 필수적인, 모델의 행동을 이해하고 조절할 수 있는 기술 발전에 기여할 수 있습니다. 결과적으로, 이번 주 선택된 논문들은 AI 기술, 특히 대규모 언어 모델 발전의 최전선에…

[다음 페이지](https://discuss.pytorch.kr/tag/prompt-engineering/164.md?match_all_tags=true&page=1&tags%5B%5D=prompt-engineering)
