에이전트, 루프, 그래프. 대부분은 이 중 첫 칸도 안 쓰고 있습니다. 붙여넣기만 하면 되는 한글 프롬프트를 전부 넣었습니다.
AI를 쓰는 방식이 대부분 똑같습니다. 물어보고, 읽고, 고쳐 말하고, 다시 물어봅니다. 되긴 됩니다. 다만 가장 느린 방법입니다.
더 빠른 방식이 있습니다. 크게 셋입니다. 한 단계씩 손을 잡고 끌어주지 않아도 스스로 계획하고 움직이는 에이전트, 결과가 기준을 넘을 때까지 알아서 다시 하는 루프, 한 번의 질문으로는 절대 못 하는 일을 여러 일꾼이 동시에 나눠 처리하는 그래프입니다. 셋 다 지금 쓰는 클로드에서 됩니다.
어려워서 안 쓰는 게 아닙니다. 세 개가 한자리에 모여 있는 걸 볼 일이 없어서입니다. 그래서 여기 모아뒀습니다.
세 개는 따로 노는 기술이 아닙니다. 하나가 다음 하나를 받칩니다.
지시 대신 목표를 줍니다. 중간에 손대지 않아도 알아서 끝까지 갑니다.
그 결과를 믿을 만하게 만듭니다. 스스로 채점하고, 약한 데를 고치고, 기준을 넘을 때까지 반복합니다.
그 일을 빠르게 합니다. 서로 상관없는 일을 동시에 돌리고 마지막에 하나로 합칩니다.
클로드에게 "이 글 요약해줘"라고 하는 건 에이전트가 아닙니다. 그냥 채팅입니다.
클로드에게 "이 주제에서 가장 많이 인용된 논문 세 편을 찾고, 각각의 핵심 주장을 뽑고, 서로 교차 검증한 다음, 한 장짜리 브리핑으로 써줘"라고 하고, 그 사이에 내가 아무것도 건드리지 않았는데 그걸 다 해내면, 그게 에이전트입니다.
차이는 더 좋은 AI를 써서가 아닙니다. AI 주변에 뭘 붙였느냐입니다. 에이전트에는 일반 채팅에 없는 세 가지가 있습니다.
검색, 파일, 코드 실행, 외부 서비스 연결. 정보를 가져다줄 때까지 기다리지 않고 직접 가지러 갑니다.
한 세션 안에서만이 아니라 작업 사이에도 남습니다. 뭘 이미 해봤는지, 뭐가 됐는지, 뭘 정했는지 압니다.
한 번 답을 뱉으면 멈추는 게 아니라 일이 끝날 때까지 돕니다. 매 단계 나한테 일을 다시 넘기지 않습니다.
셋이 다 갖춰지면 클로드는 말 상대에서 일꾼으로 바뀝니다.
첫날부터 완전 자동을 만들 필요는 없습니다. 단계가 있고, 한 칸만 올라가도 대부분이 쓰는 것보다 강해집니다.
| 단계 | 어떤 상태인가 | 내가 하는 일 |
|---|---|---|
| 1단계 채팅 |
묻고, 답을 받고, 대화가 끝납니다. 도구도 기억도 이어지는 목표도 없습니다. | 내가 다 굴려야 합니다. 클로드는 손에 든 도구입니다. |
| 2단계 도구 사용 |
답하기 전에 웹을 검색하거나, 파일을 읽거나, 코드를 돌려 자기 답을 검산합니다. 이미 살짝 에이전트입니다. | 한 단계씩 시키지 않았는데 필요하다고 판단해서 한 겁니다. |
| 3단계 다단계 작업 |
목표를 주면 스스로 쪼개고, 하나씩 실행하고, 결과를 확인해서 완성본을 냅니다. | 중간에 내가 끼어들지 않습니다. |
| 4단계 완전 자동 |
일정이나 신호에 따라 돌고, 입력을 감시하고, 외부 서비스를 부르고, 사람 없이 복잡한 일을 끝냅니다. | 목표를 한 번 정해두고 결과만 확인합니다. |
1단계와 4단계의 차이는 더 비싼 AI가 아닙니다. 도구·기억·반복 이 셋을 붙였느냐입니다. 하나씩 붙이면 한 단계씩 올라갑니다.
에이전트의 성격은 시스템 프롬프트, 그러니까 대화를 시작하기 전에 미리 걸어두는 지시문이 정합니다. 웬만한 일은 아래 셋으로 됩니다. 맞는 걸 골라 복사하고, 내 상황에 맞게 세부만 바꾼 다음, 시스템 프롬프트 자리에 붙여넣으시면 됩니다.
CLAUDE.md 에 넣으시면 됩니다. 둘 다 없으면
그냥 새 대화 첫 메시지로 붙여넣어도 그 대화 동안은 똑같이 작동합니다.
있는 걸 다 긁어오는 게 아니라 진짜 중요한 것만 남기는 역할입니다.
너는 리서치 에이전트다. 존재하는 정보를 나열하는 게 아니라 진짜로 중요한 것을 찾아내는 것이 네 일이다. 리서치 과제를 받으면: 1. 답할 가치가 있는 구체적인 하위 질문 3~4개로 쪼갠다 2. 각각을 따로 검색한다 3. 발견마다 자문한다. 이건 질문에 직접 답하는가, 관련만 있는가? 4. 직접 답하는 것만 남기고 나머지는 버린다 5. 구조화된 요약으로 전달한다. 핵심 발견, 각각의 출처, 그리고 찾지 못한 것 규칙: - 모든 주장에는 출처가 있어야 한다. 예외 없다. - 두 출처가 서로 모순되면 그 사실을 표시한다. 한쪽 편을 들지 않는다. - 믿을 만한 답을 못 찾았으면 빈칸을 메우지 말고 못 찾았다고 명시한다.
You are a research agent. Your job is to find what actually matters, not just what exists. When given a research task: 1. Break it into 3-4 specific sub-questions worth answering 2. Search each one independently 3. For each finding, ask: does this directly answer the question, or just relate to it? 4. Keep only what directly answers. Discard the rest. 5. Deliver a structured summary: key findings, the source behind each one, and what you could not find Rules: - Every claim needs a source. No exceptions. - If two sources contradict each other, flag it — don't pick a side. - If you cannot find a reliable answer, say so explicitly instead of filling the gap.
데이터에 뭐가 들었는지 설명하는 게 아니라 뭘 말하는지 읽는 역할입니다.
너는 데이터 분석 에이전트다. 데이터에 무엇이 들어 있는지 설명하는 게 아니라 데이터가 실제로 무엇을 말하는지 찾아내는 것이 네 일이다. 데이터나 숫자를 받으면: 1. 이게 어떤 종류의 데이터이고 현실적으로 어떤 질문에 답할 수 있는지 규정한다 2. 평균만 보지 말고 패턴, 이상치, 추세를 본다 3. 발견마다 자문한다. 이게 흥미로운가, 당연한가? 당연한 건 잘라낸다. 4. 이상해 보이는 건 표시한다. 결측값, 수상한 급등, 앞뒤가 안 맞는 값. 5. 데이터에 나온 순서가 아니라 중요도 순으로 정렬해 전달한다 규칙: - 데이터에 무엇이 있는지 서술하지 마라. 그게 무슨 뜻인지 해석해라. - 숫자가 의외라면 왜 의외인지 설명해라. - 데이터가 그 질문에 답할 수 없으면 억지로 늘려 해석하지 말고 그렇다고 말해라. - 모든 분석은 한 문장으로 끝낸다. 이 데이터가 시사하는 가장 중요한 행동 하나.
You are a data analysis agent. Your job is to find what the data is actually saying, not just describe what is in it. When given a dataset or numbers: 1. Identify what kind of data this is and what questions it can realistically answer 2. Look for patterns, outliers, and trends - not averages alone 3. For every finding, ask: is this interesting or is this obvious? Cut the obvious. 4. Flag anything that looks wrong - missing values, suspicious spikes, inconsistencies 5. Deliver findings ranked by importance, not by where they appear in the data Rules: - Never describe what the data contains. Interpret what it means. - If a number is surprising, explain why it is surprising. - If the data cannot answer the question being asked, say so directly instead of stretching the interpretation. - End every analysis with one sentence: the single most important thing this data suggests you should do.
그럴듯한 코드가 아니라 돌아가는 코드를 내놓는 역할입니다.
너는 코드 에이전트다. 그럴듯해 보이는 코드가 아니라 실제로 돌아가는 코드를 만드는 것이 네 일이다. 코딩 과제를 받으면: 1. 뭘 쓰기 전에 이 코드가 무엇을 해야 하는지 네 이해를 먼저 밝힌다 2. 각 부분이 뭘 하는지 주석을 달아 해결책을 작성한다 3. 이걸 깨뜨릴 수 있는 예외 상황을 짚는다 4. 에러가 나면 도움을 청하기 전에 먼저 디버깅한다 규칙: - 의미 있는 변수명으로 깔끔하게 작성한다 - 에러 처리는 항상 넣는다 - 요구사항이 불명확하면 합리적으로 가정하고, 그 가정을 밝히고, 계속 진행한다 - 머릿속으로 한 번도 따라가 보지 않은 코드는 절대 내놓지 않는다 버그를 찾으면: 원인을 한 문장으로 설명한 다음 고친다. 조용히 고치기만 하지 않는다.
You are a code agent. Your job is to produce working code, not promising code. When given a coding task: 1. State your understanding of what the code must do before writing anything 2. Write the solution with clear comments explaining each section 3. Identify edge cases that could break it 4. If there are errors, debug them before asking for help Rules: - Write clean code with meaningful variable names - Always include error handling - If the requirements are unclear, make a reasonable assumption, state it, and continue - Never deliver code you have not mentally traced through at least once When you find a bug: explain what caused it in one sentence, then fix it. Do not just fix it silently.
에이전트가 가장 자주 무너지는 자리입니다. 이렇게 셋입니다.
원래 목표, 이미 내린 결정, 내가 건 제약이 전부 밀려 나갑니다. 계속 일은 하는데 뭘 향해 가는지를 조용히 잊은 상태입니다.
대화를 닫고 새로 열면 처음부터 시작합니다. 이전 작업의 모든 게 사라집니다.
돌아왔을 때 어디서 멈췄는지, 뭘 이미 해봤는지, 뭐가 실패했는지 기록이 없습니다.
셋 다 해결책이 같습니다. 에이전트한테 자기 기억을 직접 적게 시키는 겁니다. 아래 세 프롬프트가 그 일을 합니다.
계속하기 전에 체크포인트를 작성해라: 1. 지금까지 완료한 것은 무엇인가? 2. 어떤 결정을 왜 내렸는가? 3. 아직 남은 일은 무엇인가? 4. 새 세션에서 이걸 이어받으려면 무엇이 필요한가? 150단어 이내로. 구체적으로 — 모호한 체크포인트는 쓸모가 없다.
Before we continue, write a checkpoint: 1. What have you completed so far? 2. What decisions were made and why? 3. What still needs to happen? 4. What would you need to resume this in a new session? Keep it under 150 words. Be specific - vague checkpoints are useless.
대화가 길어지고 있다. 중요한 것만 요약으로 압축해라: 1. 원래 목표 2. 무엇을 했고 무엇을 발견했는가 3. 내린 핵심 결정 4. 아직 남은 일 요약을 쓴 다음 거기서부터 이어간다. 그 요약을 새 출발점으로 취급해라.
The conversation is getting long. Compress what matters into a summary: 1. The original goal 2. What has been done and what was found 3. Key decisions made 4. What still needs to happen After writing the summary, continue from there. Treat it as the new starting point.
이전 세션에서 이어서 진행한다. 맥락은 다음과 같다: [여기에 체크포인트를 붙여넣는다] 우리가 어디까지 왔는지 네 이해를 확인해서 말하고, 다음 단계를 짚고, 이미 한 일을 반복하지 말고 이어서 진행해라.
We are resuming from a previous session. Here is the context: [paste your checkpoint here] Confirm your understanding of where we are, identify the next step, and continue without repeating work already done.
프롬프트는 클로드에게 지시 하나를 건네고 다음에 뭘 할지 내가 정하기를 기다립니다. 루프는 목표를 건네고 거기까지 가는 방법을 알아서 찾게 합니다.
실제 차이는 이겁니다. 프롬프트는 뭔가 생성되면 멈춥니다. 루프는 일이 실제로 끝나면 멈춥니다.
모든 루프는 같은 사이클을 돕니다.
PLAN - work out what the task actually requires EXECUTE - do the work CHECK - measure the result against the goal ITERATE - if it didn't pass, find the weakest part and fix it STOP - when it passes, or when a hard limit is reached
다섯 중 세 자리에서 루프가 되거나 무너집니다.
검사가 있어야 루프입니다. 결과에 실제 시험이 없으면 루프가 아니라 초안을 만들어놓고 다 됐다고 부르는 것뿐입니다. 검사가 반복을 진전으로 바꿉니다. 그러려면 실제로 떨어질 수 있는 것이어야 합니다. 통과하거나 못 하는 시험, 기준선을 넘거나 못 넘는 점수, 잣대가 분명한 채점표. 느슨한 검사는 검사 구실을 못 합니다.
정지 조건이 영원히 도는 걸 막습니다. 모든 루프에는 멈추는 길이 두 개 있어야 합니다. 일이 끝났거나, 한도에 걸렸거나. "8번 시도 후 멈추고 무슨 일이 있었는지 보고해라"는 선택이 아닙니다. 풀지 못하는 문제를 붙잡고 도는 동안 조용히 요금이 쌓이는 걸 막는 장치입니다.
루프는 만들면 다 이득인 게 아닙니다. 네 가지가 동시에 맞을 때만 만들 만합니다.
언젠가가 아니라 정기적으로. 한 번 하고 마는 일은 루프를 만들 자격이 없습니다.
내 눈이 필요 없는 검사가 어딘가 있어야 합니다. 나 없이 통과하거나 떨어지는 조건 말입니다.
중간 어딘가에서 내가 들어가야 한다면 그건 루프가 아닙니다.
충분히 좋은지 판단하는 데 감이 필요하다면, 루프는 그 판정을 못 내립니다.
넷 중 하나라도 빠지면 루프는 아끼는 것보다 더 씁니다.
그래서 대부분은 아직 무거운 버전의 루프가 필요 없습니다. 지금 당장 쓸 수 있는 건 자가 검증 루프입니다. 일정도, 서버도, 평소 사용량 외의 비용도 필요 없습니다.
첫 루프를 돌리는 데 서버도 스케줄러도 별도 설정도 필요 없습니다. 전부 프롬프트 하나에 들어갑니다. 아래를 클로드에 붙여넣고 대괄호만 바꾸시면 됩니다.
아래 모든 기준을 통과할 때까지 루프로 작업해라. 중간에 멈추지 마라. 목표: [무엇을 만들어야 하는지 정확히 적는다] 기준 — 대충 넘어갈 수 없게 구체적으로: - [잘된 상태가 어떤 건지, 잴 수 있게] - [잘된 상태가 어떤 건지, 잴 수 있게] - [잘된 상태가 어떤 건지, 잴 수 있게] 매 회차: 1. 초안 - 결과물을 만들거나 개선한다 2. 채점 - 기준마다 1~10점으로 매긴다. 후하게 주지 마라. 3. 미흡 - 아직 약한 지점을 정확히 나열한다 4. 판정 - 모든 점수가 8점 이상이면 "완료"라고 쓰고 멈춘다. 아니면 "다음 회차"라고 쓰고 가장 약한 곳부터 고친다. 규칙: - 모든 기준이 8점을 넘기 전에는 절대 완료라고 하지 마라. - 매 회차는 직전 회차에서 가장 낮은 점수 하나를 고친다. - 질문하지 마라. 합리적으로 가정하고, 그 가정을 밝히고, 계속 간다.
Work in a loop until the output clears every criterion below. Do not stop early. GOAL: [describe exactly what you want produced] CRITERIA — be specific, no soft passes: - [what good looks like, measurable] - [what good looks like, measurable] - [what good looks like, measurable] EACH PASS: 1. DRAFT - produce or improve the work 2. SCORE - rate the result 1–10 against each criterion, be harsh 3. GAPS - list exactly what is still weak 4. CALL - if every score is 8 or above, write DONE and stop. If not, write NEXT PASS and fix the weakest gap first. RULES: - Never call it done until every criterion clears 8. - Each pass fixes the single weakest score from the last round. - No questions. Make a reasonable assumption, note it, keep going.
돌려보시면 이렇게 됩니다. 클로드가 초안을 쓰고, 내가 준 기준으로 자기 결과를 채점하고, 가장 약한 지점을 찾고, 다시 쓰고, 기준을 실제로 넘을 때까지 계속합니다. 그럴듯해 보이는 게 나올 때까지가 아니라, 통과할 때까지입니다.
그게 루프입니다. 프롬프트 하나로 만든 겁니다.
실전에서 루프가 안 깨지는 순서가 따로 있습니다. 거의 모두가 한 단계를 건너뜁니다.
자동화하기 전에 대화 하나 안에서 손으로 끝까지 해봅니다. 거기서 안정적으로 안 되면 일정에 걸어도 안정적으로 안 됩니다. 더 빨리 실패하고 더 많이 쓸 뿐입니다.
지시와 기준과 규칙을 다시 불러 쓸 수 있는 형태로 저장합니다. 대화 하나 안에만 사는 루프는 그 대화가 닫히면 같이 죽습니다.
결과를 떨어뜨릴 수 있는 검사, 그리고 몇 번까지 시도할지 정한 한도. 둘 다 없으면 루프가 아니라 자동으로 돈 쓰는 장치입니다.
볼 숫자는 총 사용량이 아닙니다. 실제로 건진 결과물의 개수 입니다. 열 번 돌려 여섯 개를 버렸다면 넷을 얻으려고 열을 낸 겁니다. 건지는 비율이 50% 아래면 직접 하는 게 쌉니다.
차트가 아닙니다. 시각화도 아닙니다. AI 작업에서 그래프는 무슨 일을 해야 하고 그게 뭐에 매여 있는지 그린 지도 입니다.
구조는 딱 둘입니다.
노드를 쓸모 있게 만드는 건 정해진 출력 모양입니다. 결과를 줄글로 내놓으면 사람이 읽어서 다음 일로 옮겨야 합니다. 내놓는 모양을 미리 정해두면 다음 일이 그대로 받아 쓰기 때문에 중간에 사람이 붙지 않아도 됩니다.
JOB: research one competitor's pricing - one task, nothing else
IN: { competitor: "name", url: "https://..." }
OUT: { price: number, plan: string, source: url, date: "YYYY-MM-DD" }
RULE: if the output doesn't match this shape, reject and retry
구분해야 할 건 순서와 의존입니다. 순서는 내가 적은 차례입니다. 의존은 앞 일이 만든 것 없이는 뒤 일이 시작조차 못 하는 상태입니다. 순서는 내가 지어낸 것이고, 의존은 원래 있던 것입니다. 그래프는 그걸 보이게 만들 뿐입니다.
대부분의 작업에는 둘이 섞여 있고, 대부분은 이걸 분리해본 적이 없습니다.
이 테스트는 지금 하는 작업 아무거나 잡고 5분이면 됩니다.
순서대로 이어지는 짝마다 화살표를 하나씩 긋습니다.
이 단계가 만든 데이터가 실제로 다음 단계로 들어가나. 들어가면 남기고, 안 들어가면 지웁니다.
지운 자리가 곧 동시에 돌려도 되는 지점입니다.
나가는 화살표가 없는 건 최종 결과물입니다. 그림이 그대로 실행 계획이 됩니다.
아무 작업이나 그려보면 가짜 화살표가 두세 개는 나옵니다. 그 하나하나가 공짜로 내주고 있던 시간입니다. 필요하지도 않은 일 뒤에서 줄 서서 기다리던 작업들입니다.
가짜 화살표를 지우기 시작하면 한 모양이 유독 자주 나타납니다.
일이 서로 독립적인 여러 갈래로 갈라져 동시에 돌고, 그것들이 전부 마지막 한 단계로 모여 합쳐집니다. 그려놓으면 가운데가 넓고 양끝이 좁은 다이아몬드 모양입니다. 정식 이름은 펼쳤다가 모으기(fan out, then converge)입니다.
실제로 보면 이렇습니다. 경쟁사 세 곳을 조사한다고 해봅시다. 직선 방식은 하나 끝내고 다음 시작, 그거 끝내고 또 다음입니다. 다이아몬드 방식은 셋을 한꺼번에 돌리고 가장 느린 하나가 끝나기만 기다렸다가 종합 단계로 넘어갑니다. 같은 입력, 같은 출력, 시간은 몇 분의 일입니다.
되는 이유는 화살표 구조에 있습니다. 종합 단계는 세 조사 결과를 다 써야 합니다. 그 화살표는 실제로 있습니다. 그런데 세 조사끼리는 서로 매여 있지 않습니다. 그런 화살표는 없습니다. 그래서 동시에 돌고, 기다림은 어차피 피할 수 없는 마지막 한 번뿐입니다.
다이아몬드를 코드로 쓰면 이렇게 생겼습니다.
# the diamond — one pattern, any job
angles = [
"pricing vs the top 3 competitors",
"what buyers complain about in reviews",
"gaps the market hasn't filled yet",
]
# FAN OUT — one worker per angle, all at once
raw = run_in_parallel([
agent(task=f"research: {a}. every claim needs a source and date.")
for a in angles
])
# REDUCE — plain code, no model, no tokens spent
findings = deduplicate(filter(None, raw))
# VERIFY — a fresh skeptic per finding, tries to disprove it
survivors = [
f for f, verdict in zip(findings, run_in_parallel([
agent(task="try to disprove this. return keep or drop.",
input=f,
fresh_context=True)
for f in findings
]))
if verdict == "keep"
]
# SYNTHESIZE — one agent writes from what survived
return agent(task="one report, ranked by confidence, sources attached.",
input=survivors)
결과물을 쓴 에이전트는 그걸 검사할 사람으로는 최악입니다.
숨기려 해서가 아니라, 자기 사각지대를 못 봐서입니다. 실수를 만든 그 추론이 실수를 찾는 데 그대로 쓰입니다. 그래서 자기가 쓴 걸 자기가 검사하면 대부분 통과시킵니다.
그래서 규칙은 간단합니다. 일한 에이전트는 그 일을 검사하지 않는다.
일꾼들과 마지막 단계 사이에 별도 노드를 하나 둡니다. 그 노드의 유일한 일은 각 발견이 앞으로 넘어가기 전에 깨뜨려보는 겁니다. 개선하는 게 아니고, 요약하는 것도 아니고, 이걸 버려야 할 이유를 찾는 겁니다.
검사는 세 갈래로 나눕니다. 서로 다른 각도에서 그 발견을 죽이려 드는 질문 세 개입니다.
검증 노드 입력: 발견 내용만 — 일꾼의 대화는 절대 주지 않는다 맥락: 비어 있는 새 맥락. 판정할 작업을 본 적이 없는 상태. 세 가지 검사, 동시에 실행: 1. 맞는가? 그 주장이 실제로 성립하는가? 2. 최신인가? 출처가 오래된 것은 아닌가? 3. 출처가 진짜인가? 링크가 주장하는 그 내용으로 실제 연결되는가? 통과: 과반이 통과하면 그 발견을 남긴다 탈락: 마지막 단계에 도달하기 전에 버린다
VERIFIER NODE INPUT: the finding only — never the worker's conversation CONTEXT: fresh and empty, has not seen the work it is judging THREE CHECKS, run in parallel: 1. Is it correct? Does the claim actually hold up? 2. Is it current? Is the source recent, not something stale? 3. Is the source real? Does the link resolve to what it claims? PASS: keep the finding if the majority of checks clear FAIL: drop it before it reaches the final step
기억할 규칙은 이겁니다. 일꾼과 그 검사자는 절대 맥락을 공유하면 안 됩니다. 공유하는 순간 자기 숙제를 자기가 채점하는 상태로 돌아갑니다. 청구서만 더 커진 채로 말입니다.
여기까지는 전부 머릿속 모형입니다. 클로드가 실제로 돌릴 수 있는 걸 줘야 실물이 됩니다.
단어 하나가 클로드의 처리 방식을 바꿉니다.
workflow입니다.
이 단어가 없으면 클로드는 적어준 순서대로 하나씩 처리합니다. 이 단어가 있으면 짧은 조율 스크립트를 먼저 쓰고, 의존이 없는 노드를 골라내서, 그것들을 알아서 동시에 돌립니다. 나는 그래프를 설명하고, 실행 순서는 클로드가 정합니다.
아래 형식은 코드가 아니라 일 목록입니다. 이름 붙인 일을 적고, 어떤 일이 어떤 일을 기다려야 하는지만 표시한 것입니다. 대괄호 안만 바꿔 쓰시면 되고, 기획 일에 같은 구조를 옮긴 한글판 하나를 제가 뒤에 더 붙여뒀습니다.
output: 줄은 "이 이름의 섹션으로 나눠서 답해라" 정도로
작동합니다. 병렬로 도는 실제 이득은 클로드 코드 쪽이 큽니다.
workflow: competitive-research
nodes:
research_a:
task: "Research [Company A]. Cover pricing, core features,
recent changes, public sentiment. Output a structured summary."
output: company_a.md
research_b:
task: "Research [Company B]. Cover pricing, core features,
recent changes, public sentiment. Output a structured summary."
output: company_b.md
research_c:
task: "Research [Company C]. Cover pricing, core features,
recent changes, public sentiment. Output a structured summary."
output: company_c.md
checker:
task: "Review all three summaries. Flag anything incomplete,
outdated, or off-topic."
depends_on: [research_a, research_b, research_c]
output: checker.md
synthesize:
task: "Using the summaries and checker report, write a comparison
across price, features, and positioning."
depends_on: [checker]
output: comparison.md
workflow: code-review
nodes:
review_auth:
task: "Review auth.py for security issues, edge cases,
and code quality. Be specific."
output: review_auth.md
review_api:
task: "Review api.py for security issues, edge cases,
and code quality. Be specific."
output: review_api.md
review_db:
task: "Review db.py for security issues, edge cases,
and code quality. Be specific."
output: review_db.md
checker:
task: "Read all three reviews. Flag issues appearing in more than
one file. Note cross-file dependencies that could cause problems."
depends_on: [review_auth, review_api, review_db]
output: checker.md
summary:
task: "Write a prioritized fix list — critical first,
then medium, then low."
depends_on: [checker]
output: final_review.md
위 두 개는 개발자 쪽 예시입니다. 같은 구조를 기획 일에 옮겨 하나 더 만들었습니다. 소재 세 개를 동시에 조사하고, 체커가 거르고, 마지막에 하나를 고릅니다.
workflow: 소재-고르기
nodes:
소재_A:
task: "[소재 A]를 조사한다. 이미 나온 콘텐츠, 사람들이 실제로 묻는 질문,
반응이 터진 앵글, 아직 아무도 안 다룬 각도. 구조화된 요약으로."
output: 소재_a.md
소재_B:
task: "[소재 B]를 조사한다. 같은 항목으로."
output: 소재_b.md
소재_C:
task: "[소재 C]를 조사한다. 같은 항목으로."
output: 소재_c.md
체커:
task: "세 요약을 읽고 거른다. 출처 없이 단정한 것, 이미 포화된 앵글,
우리가 직접 검증할 수 없는 주장을 표시한다. 개선하지 말고 탈락 사유만."
depends_on: [소재_A, 소재_B, 소재_C]
output: 체커.md
결정:
task: "살아남은 것만으로 하나를 고른다. 고른 이유, 탈락 두 개의 사유,
그리고 첫 문장 후킹 3개 후보를 쓴다."
depends_on: [체커]
output: 결정.md
여기서 알아야 할 줄은 depends_on 하나뿐입니다. 적어둔 일이 끝나기를 기다렸다가 하라는 뜻이고, 이 줄이 없으면 기다리지 않고 바로 같이 돌아갑니다. 그래프 설계는 이걸로 끝입니다.
개발자가 아니어도 오늘 바로 쓸 수 있는 자리를 골라봤습니다.
네 개 다 같은 틀입니다. 목표 · 재료 · 지켜야 할 것 · 끝내는 조건 네 칸이고, 내 일에 맞는 것을 골라 대괄호만 채워 붙여넣으시면 됩니다.
목표: 이번 주 업무 보고 재료: [이번 주에 한 일을 생각나는 대로 적은 메모] 지켜야 할 것: - 숫자가 나오는 문장마다 어디서 본 값인지 함께 적는다 - 상사가 물어볼 질문 세 개를 미리 답해둔다 - A4 한 장을 넘지 않는다 - 다음 주에 할 일은 담당자와 날짜까지 적는다 끝내는 조건: 위 항목을 하나씩 스스로 채점하고, 전부 통과할 때까지 고쳐서 다시 쓴다. 통과했다고 판단한 근거를 마지막에 한 줄로 적는다.
목표: 근처 경쟁 매장 세 곳 비교표 재료: [가게 이름 세 개와 위치] 지켜야 할 것: - 세 곳을 각각 따로 조사한다. 한 곳 결과를 다른 곳 조사에 쓰지 않는다 - 항목은 대표 메뉴와 가격대, 영업시간, 리뷰에서 반복되는 칭찬과 불만 - 확인이 안 된 것은 지어내지 말고 "확인 필요"로 적는다 - 세 곳 조사가 다 끝난 뒤에 비교표를 만든다 끝내는 조건: 비교표 다음에 우리가 이번 달에 바꿀 수 있는 것 세 개를 고르고, 왜 그것인지 한 줄씩 적는다.
셋을 따로 조사하라고 못 박는 이유가 있습니다. 그냥 시키면 앞에서 본 가게 인상이 뒤 조사에 묻어 들어옵니다. 서로 안 보게 나눠놓아야 마지막 비교가 공평해집니다.
목표: 앞으로 내 콘텐츠 작업을 도울 때 항상 지킬 규칙
재료: 채널 [채널명] · 다루는 것 [주제] · 보는 사람 [나이대와 상황]
말투 [예: 존댓말, 문장 짧게] · 안 쓰는 표현 [금지어 그대로]
지켜야 할 것:
- 초안은 서로 다른 각도로 세 개를 낸다
- 내가 고른 것만 다듬는다. 안 고른 건 다시 꺼내지 않는다
- 확인 안 된 수치는 쓰지 말고 "확인 필요"로 표시한다
- 분량은 [분량]에 맞춘다. 넘치면 잘라서 준다
끝내는 조건: 이 규칙은 대화가 길어져도 계속 적용한다. 어긋났다는 걸
알아채면 스스로 고치고 뭐가 어긋났는지 알려준다.
이건 매번 새로 치는 게 아니라 한 번 넣어두는
것입니다. 클로드 앱이면 프로젝트 지침 칸, 클로드 코드면
CLAUDE.md 입니다.
목표: [과제명] 초안 재료: [과제 안내문과 채점 기준] · [내가 조사한 자료] 지켜야 할 것: - 주장마다 근거를 하나 이상 붙이고, 근거에는 출처를 적는다 - 강의에서 다룬 개념을 [N]개 이상 쓰되, 쓸 때 뜻을 먼저 밝힌다 - 인용한 문장과 내가 쓴 문장을 구분한다 - 분량은 [N]자 안에 들어온다 - 마지막 문단은 요약이 아니라 내 결론이다 끝내는 조건: 위 항목을 하나씩 스스로 채점하고, 전부 통과할 때까지 고쳐서 다시 쓴다. 자료가 모자라 못 채운 항목은 그렇다고 알려준다.
세 개를 한꺼번에 붙이면 어디서 깨졌는지 알 수 없습니다. 저는 이 순서를 권합니다.
오늘 하는 긴 작업에서 체크포인트 프롬프트를 한 번 써봅니다. 다른 건 건드리지 않습니다.
가장 싸고, 효과가 바로 보이는 자리입니다.
매주 반복하는 일 딱 하나를 골라 기준 3개를 문장으로 적어봅니다. 기준을 못 적겠으면 그 일은 아직 루프 대상이 아닙니다.
기준을 적는 과정 자체가 절반입니다. 뭐가 잘된 건지 스스로도 몰랐다는 걸 여기서 알게 됩니다.
이미 하고 있는 작업 하나를 종이에 네모로 그리고 화살표를 지웁니다. 5분 걸립니다.
여기서 지운 화살표 개수가 그래프를 만들 가치가 있는지 알려줍니다. 하나도 안 지워졌으면 안 만드셔도 됩니다.
지운 화살표가 두 개 이상일 때만 위 워크플로 형식으로 옮깁니다. 그 전에는 손으로 하는 게 빠릅니다.
실제로 자주 나오는 증상과 어디를 보는지입니다.
| 증상 | 거의 항상 이 원인 | 이렇게 고칩니다 |
|---|---|---|
| 루프가 두 번 돌고 "완료"라고 함 | 기준이 느슨합니다. 감으로 판정되는 문장이면 그냥 통과시켜 버립니다. | 기준을 잴 수 있는 문장으로 바꿉니다. "읽기 좋게" 대신 "한 문단이 4줄을 안 넘는다". |
| 루프가 끝없이 돎 | 정지 조건이 없습니다. | "8회 시도 후 멈추고 무슨 일이 있었는지 보고해라"를 규칙에 넣습니다. |
| 중간부터 딴소리를 함 | 앞이 밀려 나갔습니다. | 체크포인트를 받고, 압축 프롬프트를 돌리고, 필요하면 새 창에서 복원 프롬프트로 다시 시작합니다. |
| 동시에 돌린다는데 순서대로 돎 |
workflow 단어가 없거나, 노드마다 의존이 걸려
있습니다.
|
depends_on을 다시 봅니다. 앞 결과를 진짜 안 쓰는
노드에서 줄을 지웁니다.
|
| 검사를 붙였는데 다 통과함 | 검사자가 작업자와 같은 대화 안에 있습니다. | 검사는 새 대화에서, 발견 내용만 붙여넣고 돌립니다. 앞 대화는 주지 않습니다. |
| 돌리고 나면 쓸 게 별로 없음 | 건지는 비율이 낮습니다. | 버린 개수를 세봅니다. 절반 아래로 건지고 있으면 그 일은 직접 하는 게 쌉니다. |
이 글의 프롬프트는 전부 일반 대화창에 붙여넣는 것이라 요금제와 무관하게 작동합니다. 다만 루프는 회차마다 맥락이 통째로 다시 돌기 때문에 사용량을 꽤 먹습니다. 무료로 쓰신다면 회차 한도를 5회 정도로 낮춰 잡으시는 걸 권합니다.
프롬프트 형식 자체는 특정 회사 기능이 아니라 지시문이라 다른
모델에도 붙여넣을 수 있습니다. 다만 이 글은 클로드 기준으로
정리했고, 특히
workflow 단어로 병렬 실행이 붙는 부분은 클로드 코드
환경을 전제합니다. 다른 도구에서도 되는지는 제가 확인하지
않았습니다.
대괄호 안만 바꾸시면 됩니다. 회사명, 파일명, 소재명 자리입니다. 나머지 구조는 안에 뭘 넣든 그대로 둡니다.
10점을 요구하면 영원히 안 끝나고, 6점이면 어설픈 결과도 통과합니다. 8점은 그 사이에서 실용적으로 걸리는 선입니다. 내 기준이 더 높으면 9로 올리시되 회차 한도도 같이 올려야 합니다.
기억 프롬프트입니다. 세 개 중 가장 싸고, 준비할 게 없고, 오늘 하는 작업에서 바로 차이가 납니다. 루프와 그래프는 반복되는 일이 생긴 다음입니다.