.NET UNIVERSEBUSAN EDITION · 2608

격월 부산×서울 지역 닷넷 개발자 밋업 · 50분 세션

사용할수록
정리되는
바이브 코딩

운영 프롬프트로 Agent가
비정형→정형 · 수동→자동을 이끄는 방법

80:20 → 20:80 발표 · 디모이

Event: .NET Universe: Busan Edition, 2608 · 2026.08.16 · 라운지J

BUILDER · EDUCATOR · COMMUNITY DIMOHY

HELLO, I’M

디모이

기술을 가르치고, 커뮤니티를 잇고,
새로운 것을 직접 만듭니다.

01신구대학교 컴퓨터소프트웨어학과 겸임교수

02닷넷데브(.NET Dev) 운영진

03Microsoft MVP

Sollang

복잡한 아이디어를 명확하고 조합 가능한 코드로 표현하기 위해 만든 네이티브 프로그래밍 언어

GitHub ↗ Playground ↗

Photo & profile: .NET Universe · Sollang: GitHub / Playground

손들어 보기

가볍게 시작하겠습니다

AI에게 부탁해서
뭔가 작동하게 만들어본 적 있나요?

문서 정리 · 엑셀 자동화 · 간단한 앱 · 반복 업무

첫 성공의 함정

“앱이 만들어졌습니다.”
그런데 다음 달에도 됩니까?

담당자가 바뀌어도?

설명을 처음부터 다시 하지 않고

입력이 달라져도?

새로운 사례를 안전하게 처리하고

실수해도?

어디가 잘못됐는지 확인할 수 있는가

처음 화면이 뜨고 버튼이 움직이면 정말 기쁘죠. “됐다!” 싶은 순간입니다. 그런데 실제 업무에서는 질문이 더 남습니다. 이게 다음 달에도 될까요? 담당자가 바뀌거나 입력 형식이 달라져도 쓸 수 있을까요? 실수했을 때 어디가 문제인지 찾을 수 있을까요? 이번 달 참가자 명단을 AI가 정리했다고 해보겠습니다. 다음 달 신청 형식이 달라질 때 같은 설명을 처음부터 반복하고, 취소자와 대기자 규칙도 다시 알려줘야 한다면 결과물은 생겼지만 업무는 아직 정리되지 않은 겁니다. 반복 가능한 솔루션이라면 입력 항목, 상태가 바뀌는 조건, 오류 확인 기준이 남아 있어야 합니다. 다른 사람이 같은 원본을 넣어도 비슷한 결과를 얻고, 문제가 나면 어디서 멈췄는지 알아야 하죠. 한 번 작동했다는 것과 다음에도 쓸 수 있다는 것은 다릅니다.

오늘 끝까지 가져갈 한 질문

첫 번째보다
두 번째 실행이 더 쉬워졌는가?

판정 기준은 프롬프트의 길이가 아니라
재설명 · 수동 판단 · 오류가 줄었는가입니다.

우리가 실제로 받는 입력

현실의 업무는
깔끔한 표로 오지 않습니다

카카오톡 대화와 전화 메모
제각각인 신청서와 문서
“보통은 이렇게 해요”라는 경험
상황마다 달라지는 예외

사람은 맥락으로 이해하지만,
반복하려면 기억할 칸이 필요합니다.

현실의 업무는 처음부터 깔끔한 표로 오지 않습니다. 대화, 메모, 문서, 오래 일한 분의 감각 속에 있습니다. 오늘은 이런 입력을 비정형이라고 부르겠습니다. 사람의 업무에는 풍부한 맥락이 있기 때문입니다. “이번 참가자는 처음이고 친구와 함께 온대요”라는 카톡에도 이름, 참여 이력, 동반 인원 같은 정보가 섞여 있습니다. 사람은 문맥으로 이해하지만, 반복하려면 무엇을 기억할지 정해야 합니다. 원문은 보존하되 반복해서 쓸 정보는 이름과 날짜 같은 항목으로 옮깁니다. 신청, 입금, 확정처럼 상태를 구분하고 바뀌는 규칙도 남깁니다. 정상 결과와 오류를 가르는 기준도 필요합니다. 비정형을 없애는 것이 아니라 다시 쓸 부분을 꺼내는 겁니다.

정형화의 진짜 의미

정형화는 표 한 장이 아니라
판단이 이동하는 과정입니다

흩어진 입력이 기억, 상태, 규칙, 검증, 자동화와 학습 순환으로 점진적으로 정리되는 개념 이미지

비정형에서 정형으로 — 한 번에 점프하지 않는다

원본대화·문서·경험

판단의미·모호함·예외

기억남겨야 할 항목

상태지금 어디인가

규칙언제 바뀌는가

검증맞는지 확인

반복다음 입력 자동 처리

정형화라고 하면 엑셀 표부터 떠올리기 쉽죠. 하지만 표는 ‘기억할 칸’의 한 모습일 뿐입니다. 대화와 경험에서 바로 자동화로 점프하는 건 아닙니다. 먼저 사람과 AI가 의미와 예외를 찾습니다. 그런 다음 기억할 항목, 현재 상태, 변화 규칙, 정답 여부를 붙잡아 이미 배운 판단부터 반복 처리로 옮깁니다. 비정형에서 정형으로 간다는 건 사람의 판단을 없애자는 뜻이 아닙니다. 새롭고 모호한 판단은 사람이 맡고, 한 번 배운 판단은 시스템이 다시 쓰게 옮기는 겁니다. 네 가지를 붙잡으면 됩니다. 첫째는 이름, 날짜, 금액 같은 데이터입니다. 둘째는 접수, 검토, 완료 같은 상태입니다. 셋째는 조건과 행동을 정하는 규칙, 넷째는 결과를 확인할 검증 사례입니다. “입금하면 확정”은 단순한 메모가 아닙니다. 확인 전에는 신청, 확인되면 확정으로 바뀌는 규칙입니다. 정원이 찼다면 대기로 보내고, 연락처가 잘못됐다면 저장 전에 멈춰야 합니다. 데이터, 상태, 규칙, 검증이 함께 있어야 다음 실행을 시스템이 이어받습니다.

결과물과 솔루션의 차이

화면이 있느냐보다
다시 돌릴 수 있느냐

판정 기준	일회성 결과	반복 가능한 솔루션
다음 입력	프롬프트를 다시 설명	정해진 칸에 넣으면 처리
예외	그때그때 수동 수정	규칙으로 흡수
검증	눈으로 대충 확인	체크 기준과 기록이 있음
담당자	만든 사람만 이해	다른 사람도 같은 흐름 사용

왼쪽을 볼까요? 결과물은 나왔지만 매번 다시 설명하고 고쳐야 하며, 만든 사람만 알고 있습니다. 오른쪽에는 입력할 칸과 예외 규칙, 검증 기준이 있습니다. 그래서 다른 사람도 같은 흐름을 쓸 수 있습니다. 왼쪽 엑셀에 이번 명단만 있고 확정과 대기 판단이 담당자 머릿속에만 있다면, 다음 사람은 파일을 보고도 처리할 수 없습니다. 오류의 원인도 찾기 어렵습니다. 오른쪽은 같은 입력 양식과 상태값을 다시 씁니다. 새 예외가 나오면 규칙과 검증 사례를 갱신합니다. 담당자가 바뀌거나 다음 달 데이터가 와도 처음부터 만들지 않습니다. 바이브 코딩의 목표를 앱 하나로 잡으면 왼쪽에서 멈춥니다. 두 번째에도 작동하는 업무 흐름을 목표로 해야 오른쪽으로 갈 수 있습니다.

근거를 섞지 않겠습니다

이 발표는 세 층으로 말합니다

검증된 사실

AI는 추출·구조화·실행 자동화에 실제 사용된다

1

연구가 지지하는 판단

성과는 지식·업무 구조·검증 환경에 좌우된다

2

발표자의 모델

성숙 방향을 80:20→20:80으로 기억한다

3

1층 · 검증된 사실

AI는 비정형 정보에서
정해진 항목을 추출할 수 있습니다

문서·이미지

필드, 표, 키-값 쌍을 추출

출력 계약

정해진 스키마에 맞춘 구조화 출력

후속 처리

저장·검토·업무 흐름으로 연결

권위 범위: 공급자의 공식 기능·참조 아키텍처를 확인하는 1차 자료

근거: OpenAI · Structured Outputs · Microsoft Learn · AI document processing architecture

먼저 첫 번째로 확인할 수 있는 사실입니다. AI는 문서나 이미지처럼 모양이 제각각인 자료에서 이름, 날짜, 금액, 표 같은 항목을 뽑아 정해진 구조로 출력하는 데 실제로 쓰이고 있습니다. 이것이 비정형 입력을 정형 데이터로 옮기는 출발점입니다. OpenAI의 구조화 출력은 결과를 개발자가 정한 스키마에 맞추는 기능이고요. Microsoft의 참조 아키텍처를 보면 문서 수집부터 추출, 검토, 저장, 후속 흐름까지 어떻게 연결하는지 확인할 수 있습니다. 다만 이 자료들은 공급자의 공식 문서입니다. 기능이 실제로 존재하고 어떻게 쓰이는지를 확인하기에는 좋은 자료지만, 모든 현장에서 성과가 난다고 독립적으로 증명하는 자료는 아니라는 점도 함께 보셔야 합니다.

1층 · ‘알아서’의 실제 의미

운영 프롬프트가 방향을 잡으면
Agent가 다음 단계를 스스로 선택합니다

비정형 원본 탐색

→

질문·구조화

→

도구 실행·검증

→

예외 흡수·다음 순환

알아서 = 질문하고, 결과를 보고, 다음 행동을 고르는 순환

근거: OpenAI Agents SDK · Anthropic Engineering · Microsoft Agent Framework

여기서 오늘 말하는 ‘알아서’가 무엇인지 짚고 갈게요. 운영 프롬프트는 답 한 번을 잘 쓰게 하는 문장이 아닙니다. Agent에게 원본을 살피고, 모르는 것을 질문하고, 구조를 만들고, 결과를 검증한 뒤 다음 단계를 고르라는 반복 규칙을 줍니다. 현재 Agent 프레임워크에는 모델이 도구를 호출하고 실행 결과를 다시 받아 다음 행동을 고르는 루프가 있습니다. 구조화 출력, 사람 승인, 검증과 실행 기록도 연결할 수 있습니다. 그래서 Agent가 정형화와 자동화의 다음 단계를 먼저 제안하게 만들 수 있습니다. 다만 미정 정책까지 마음대로 정한다는 뜻은 아닙니다. 모르는 정책과 위험한 실행에서는 질문하고 멈춥니다. 사람이 답하면 그 판단을 데이터·규칙·검증에 반영해 다음부터 재사용합니다. 이 경계가 있어야 ‘알아서’가 안전한 운영 방식이 됩니다. [Sources] - Agent loop·tools·guardrails·human-in-the-loop·tracing: https://openai.github.io/openai-agents-python/ - Agent가 동적으로 프로세스와 도구 사용을 지휘한다는 구분: https://www.anthropic.com/engineering/building-effective-agents - Agent·workflow·human interaction·external integration: https://learn.microsoft.com/en-us/agent-framework/workflows/

2층 · 여러 연구가 지지하는 판단

AI를 잘 쓰는 차이는
현장을 얼마나 아는가에서 커집니다

40만+Claude Code 상호작용 관찰

숙련자는 계획·검증·맥락 제공을 더 적극적으로 사용

비개발자의 약점은 코드를 모르는 것이 아니라,
업무를 설명할 언어가 없는 것입니다.

근거: Anthropic Research · How AI assistance impacts expertise (대규모 관찰 연구, 인과 증명은 아님)

여기서 중요한 판단이 하나 나옵니다. 성과는 단순히 도구를 켰느냐보다, 사용자가 현장을 얼마나 알고 목표와 검증 기준을 얼마나 잘 설명하느냐에 더 크게 좌우됩니다. 같은 AI를 써도 업무 맥락을 설명하는 깊이에 따라 결과가 달라집니다. Anthropic은 40만 건이 넘는 코딩 상호작용을 관찰해서 숙련도에 따라 사용 방식이 어떻게 달라지는지 분석했어요. 관찰 연구라 인과관계를 확정할 수는 없지만, 규모가 크고 실제 사용 모습을 보여준다는 의미가 있습니다. 비개발자는 코드 지식이 부족할 수 있어요. 하지만 자기 업무에 대한 지식은 가지고 계시죠. 그 지식을 질문, 항목, 규칙, 예외로 표현할 수 있다면 오히려 큰 강점이 됩니다. AI에게는 코딩 용어보다 이 현장 언어가 더 중요한 입력일 수 있습니다.

2층 · 여러 연구가 지지하는 판단

AI는 조직의 강점을 확대하고
약점도 확대합니다

빠른 피드백

결과를 작게 만들고 빨리 확인

명확한 품질 기준

“좋다”를 검사 가능한 조건으로

안전한 변경 흐름

잘못되면 찾고 되돌릴 수 있게

근거: Google Cloud · 2025 DORA Report · DORA AI Capabilities Model

DORA 2025 연구도 한번 볼게요. 거의 5천 명을 대상으로 한 설문과 질적 연구를 바탕으로, AI를 조직의 강점과 약점을 함께 키우는 증폭기라고 설명합니다. 빠른 피드백, 명확한 품질 기준, 안전한 변경 흐름이 있는 곳에서는 AI의 속도가 성과로 이어질 가능성이 큽니다. 반대로 일이 정리되지 않은 곳이라면 어떨까요? 더 많은 결과물이 더 빠르게 쌓이면서 오히려 혼란이 커질 수도 있습니다. 그래서 오늘 계속 이야기하는 “사용할수록 정리되는가?”라는 질문이 중요합니다. AI 도입 전에 모든 업무를 완벽하게 정리하라는 뜻은 아닙니다. 다만 빠르게 만든 결과를 어디에서 확인하고, 틀렸을 때 어떤 규칙을 고칠지는 보여야 합니다. 피드백이 구조로 돌아오는 길이 있을 때 속도가 학습이 되고, 그 길이 없으면 속도는 미처리 결과물의 양만 늘릴 수 있습니다.

수치를 정직하게 읽기

AI가 항상 빠르다는 결론은
근거와 맞지 않습니다

연구 맥락	관찰 결과	읽어야 할 한계
GitHub 통제 과제	55.8% 더 빠름	좁은 과제·특정 도구
Google 기업 RCT	약 21% 시간 감소 추정	신뢰구간이 넓음
METR 숙련 OSS 개발자	초기 2025 도구에서 19% 느림	16명·익숙한 저장소

공통 결론: 도구 효과는 맥락과 구조에 따라 달라진다.

근거: GitHub Research · Google RCT · METR RCT

연구 결과를 보면 숫자가 한 방향으로만 나오지는 않습니다. 좁고 잘 정의된 과제에서는 큰 속도 향상이 관찰됐고요. 기업 환경에서도 시간이 줄었다는 결과가 있습니다. 그런데 METR의 무작위 통제 실험에서는 반대 결과가 나왔어요. 익숙한 오픈소스 저장소를 다루던 숙련 개발자들이 당시 도구를 썼을 때 오히려 19퍼센트 느려졌습니다. 어느 숫자가 진짜냐고 싸울 필요는 없습니다. 과제도 다르고, 사람의 숙련도도 다르고, 도구와 검증 비용도 다르니까요. 여기서 가져갈 공통점은 하나입니다. AI를 쓴다는 사실만으로 성과가 결정되는 게 아니라, 일이 얼마나 잘 정의되어 있고 확인할 기준이 있는지가 함께 결정한다는 겁니다.

3층 · 발표자의 모델

비정형 중심에서
정형·반복 중심으로

사람은 새롭고 모호한 판단을 맡고 시스템은 이미 배운 반복 처리를 담당하는 협업 이미지

80:20

해석·탐색구조·반복

→

20:80

새 판단재사용 처리

사람이 매번 지시

Agent가 다음 단계 주도

사람이 반복 실행

새 판단만 사람에게

※ 연구 수치가 아니라, 성숙 방향을 기억하기 위한 상징

이제 오늘 이야기를 한 장으로 묶어볼게요. 처음에는 비정형 활동이 클 수밖에 없어요. 무슨 문제를 풀어야 하는지 찾고, 사람의 말을 이해하고, 숨어 있는 예외도 발견해야 하니까요. 그런데 잘 설계된 운영 프롬프트를 Agent에게 주면 이야기가 달라집니다. Agent가 반복해서 원본을 분석하고 질문하며, 사람의 답을 데이터 항목, 규칙, 검증 사례, 실행 흐름으로 하나씩 옮길 수 있습니다. 같은 규칙이 확인되면 다음에는 도구 실행과 자동화 후보를 먼저 제안하고, 새롭고 모호한 예외만 사람에게 돌립니다. 화면의 80대20과 20대80은 측정값이나 정답 비율이 아닙니다. 처음에는 사람이 설명하고 확인하는 비중이 크지만, 순환할수록 Agent가 스스로 구조화하고 실행하는 비중이 커지는 방향을 기억하기 위한 상징입니다. 핵심 질문은 “사람이 다시 지시하지 않아도 Agent가 다음 정형화·자동화 단계를 먼저 이끄는가?”입니다. 여기서 사람의 일이 없어지는 것은 아닙니다. 이미 합의한 판단을 반복하는 시간은 줄이고, 처음 만나는 예외와 중요한 승인에 더 집중하는 겁니다. Agent가 더 많이 처리한다는 말은 권한을 무조건 넘긴다는 뜻이 아니라, 검증된 일을 더 많이 재사용한다는 뜻입니다.

잠깐 멈춰서

올바른 바이브 코딩은
사용할수록 정리됩니다.

새 판단이 프롬프트 더미가 아니라
데이터 · 규칙 · 검증으로 남기 때문입니다.

비개발자도 느낄 수 있는 차이

작업의 흔적이 짐이 되는가,
자산이 되는가

복사본과 수동 수정이 쌓이는 혼란스러운 작업과 재사용 가능한 구조로 정리된 시스템의 대비 이미지

작업의 흔적이 이동해야 할 자리

프롬프트 조각→공유된 업무 지식

파일 복사본→단일 데이터 흐름

그때그때 예외→명시된 업무 규칙

눈대중 확인→검증 기준과 기록

다음번 더 복잡→다음번 더 단순

왼쪽은 프롬프트 조각과 파일 복사본이 늘고, 예외를 그때그때 손으로 고칩니다. 같은 일을 할 때 지난 기록을 다시 찾아야 하니 작업의 흔적이 짐이 됩니다. 오른쪽은 새롭게 알게 된 내용을 데이터 항목, 업무 규칙, 검증 기준, 반복 흐름 가운데 알맞은 곳에 넣습니다. 다음 실행이 그 판단을 다시 씁니다. 구분법은 간단합니다. 오늘 만든 흔적 때문에 다음번이 더 복잡해졌나요, 더 단순해졌나요? 단순해졌다면 정리되는 방향입니다. 차이는 파일 개수가 아니라 판단이 어디에 남았느냐입니다. 교정이 대화나 담당자의 기억에 흩어지면 같은 예외를 다시 고칩니다. 허용값, 상태 변화, 업무 규칙이나 실패 사례에 들어가면 시스템이 기억합니다. 연락처 형식 때문에 문자가 실패했을 때 이번 번호만 고치면 다음 달에도 같은 오류가 납니다. 입력 단계에 형식 검사를 넣고 잘못된 번호는 발송 전에 멈추는 실패 사례를 추가해야 합니다. 같은 문제가 두 번 나타났는데도 손으로 고친다면 아직 학습하지 않은 시스템입니다. 한 번의 교정이 다음 실행의 기본 동작이 될 때, 비로소 사용할수록 정리된다고 말할 수 있습니다.

고개 끄덕이기

정리되고 있다는 신호

두 번째에는
이 네 가지가 줄어야 합니다

재설명

처음부터 맥락 말하기

수동 판단

사람이 매번 고르기

예외 패치

한 건만 억지로 고치기

불안한 확인

맞는지 눈으로 헤매기

줄었다면 구조가 생긴 것 · 늘었다면 아직 결과물 더미

한 사례에서 벗어나 보기

어떤 업무든 같은 방향으로 바뀝니다

회의, 고객 문의, 콘텐츠 제작이 각각 비정형 입력에서 반복 가능한 구조로 전환되는 세 장면 이미지

서로 다른 업무, 같은 변환 공식

회의 녹음·메모→결정 · 담당자 · 기한 · 상태

메일·전화·채팅→유형 · 긴급도 · 담당 · 상태

아이디어·피드백→대상 · 메시지 · 검수 · 배포

결과 파일을 예쁘게 만드는 것이 아니라
다음 실행이 기억할 구조를 만듭니다.

이 방식은 행사 운영에만 해당하지 않습니다. 여러분 업무에 가까운 예를 대입해 볼게요. 회의록은 녹음을 요약하는 데서 멈추지 않고 결정사항, 담당자, 기한, 진행 상태를 남겨야 다음 회의에서 이어집니다. 고객 문의는 유형, 긴급도, 담당 부서, 처리 상태가 필요합니다. 콘텐츠 제작은 대상, 핵심 메시지, 검수 기준, 배포 상태를 기억해야 합니다. 업무는 달라도 방향은 같습니다. 결과 파일 하나가 아니라 다음 입력에 다시 쓸 구조를 만드는 겁니다. 회의록에서 담당자와 기한이 없는 항목을 어떻게 다룰지, 완료된 일은 어디로 옮길지 정하면 다음 회의에서 상태를 이어갈 수 있습니다. 고객 문의는 환불, 장애, 일반 문의를 같은 기준으로 분류하고 긴급한 건 사람이 먼저 확인하게 해야 합니다. 콘텐츠 제작은 대상, 검수 단계, 승인 여부와 배포 채널이 남아야 같은 기준으로 움직입니다. 세 사례에서 공통으로 줄어드는 것은 재설명입니다. 두 번째부터 Agent는 확정한 구조를 사용하고 처음 보는 예외만 질문합니다. 결과물보다 다음 입력을 받을 준비가 남았는지 확인해 보세요.

비개발자는 원본을 주고, Agent가 구조를 찾습니다

잘 설계된 프롬프트가 Agent에게
여섯 질문을 반복하게 합니다

① 원본무엇이 들어오는가?

② 판단사람이 매번 무엇을 고르는가?

③ 기억다음에도 남길 칸은?

④ 상태무엇이 어떤 조건에서 바뀌는가?

⑤ 검증맞고 틀림을 어떻게 아는가?

⑥ 반복새 사례를 어디에 넣는가?

모르는 것은 규칙으로 꾸미지 않습니다. ‘미정’으로 남기고, 사람이 답해야 할 질문으로 돌립니다.

그럼 내 업무에서는 어디서부터 시작하면 될까요? 비개발자가 매번 이 여섯 질문을 직접 떠올릴 필요는 없습니다. 다음 장의 운영 프롬프트에 질문 틀을 넣어두면 Agent가 원본을 읽고 필요한 질문부터 순서대로 고릅니다. 첫째, 실제로 들어오는 원본은 무엇인가요? 카톡인지, 메일인지, 녹음인지 먼저 적습니다. 둘째, 그걸 받은 사람이 매번 무엇을 판단하나요? 긴급한지, 승인할지, 누구에게 보낼지 같은 판단입니다. 셋째, 다음에도 기억해야 할 항목은 무엇인가요? 이름, 날짜, 상태처럼 칸으로 남길 수 있는 것들이죠. 넷째, 상태는 언제 바뀌나요? 신청에서 확정으로, 접수에서 완료로 이동하는 조건을 찾습니다. 다섯째, 결과가 맞다는 걸 어떻게 확인하나요? 정상 사례뿐 아니라 경계와 실패 사례가 필요합니다. 마지막으로 새 사례는 어디에 넣으면 다시 처리될까요? 여기서 Agent가 답을 모르는 항목은 규칙으로 꾸미지 않습니다. ‘미정’이라고 표시하고 현업 담당자가 답할 질문으로 돌립니다. 사람이 답하면 Agent가 기억·상태·규칙·검증을 갱신하고 다음 자동화 수준을 제안합니다. 이 여섯 질문을 스스로 반복하게 만드는 것이 첫 번째 Agent 설계입니다. 중요한 건 여섯 답을 한 번에 완벽하게 만드는 게 아닙니다. 실제 원본 한 건에서 시작하고, 두 번째 원본을 넣었을 때 빠진 항목과 새 예외를 발견해 구조를 갱신하면 됩니다. 처음에는 여섯 질문을 모두 확인하더라도, 구조가 쌓이면 Agent는 새로 등장한 예외만 묻게 됩니다. 질문이 줄고 기존 판단이 재사용되는지가 진화의 증거입니다.

그대로 복사해서 쓰는 마스터 프롬프트 ①

한 번 답하게 하지 말고
다음 단계까지 스스로 이끌게 합니다

80:20 → 20:80 업무 진화 Agent 프롬프트

너는 내 반복 업무를 비정형→정형→자동 실행으로 진화시키는 Agent야.
내가 업무 설명과 실제 원본을 주면 다음 순환을 스스로 주도해.

Explore: 원본 근거만 읽고 모호함·반복 판단·예외를 질문해.
Capture: 사람의 답을 확정/미정으로 구분해 기록해.
Structure: 데이터·상태·규칙·정상/경계/실패 검증으로 바꿔.
Automate: 수동·승인 후 Agent 실행·자동 실행 후보를 구분해.
Integrate: 연결된 도구가 있으면 승인 후 만들고 실제 결과를 검증해.
Learn: 새 예외를 항목·규칙·검증에 흡수하고 다시 실행해.

각 단계에서 산출물·사람이 결정할 것·다음 행동을 보여줘.
미정 정책과 위험한 실행에서는 질문하고 멈춰.

이제 오늘의 핵심 프롬프트입니다. 이 프롬프트는 답을 한 번 잘 받기 위한 문장이 아니라, Agent가 업무를 어떤 방향으로 계속 진화시킬지 정하는 운영 계약입니다. 사용자는 처음에 업무 설명과 개인정보를 가린 실제 원본 한 건만 줍니다. 그러면 Agent가 Explore에서 근거를 읽고 필요한 질문을 스스로 고릅니다. 사람이 답하면 Capture에서 확정과 미정을 나누고, Structure에서 데이터·상태·규칙·검증 사례로 바꿉니다. 여기까지 사용자가 매번 다음 프롬프트를 생각해 낼 필요가 없습니다. Agent가 앞 단계의 결과를 보고 다음 단계를 이끕니다. 반복 규칙과 검증 사례가 확인되면 Agent가 Automate 단계에서 수동으로 남길 일, 사람 승인 뒤 실행할 일, 자동 실행 후보를 구분합니다. 도구가 연결되어 있다면 Integrate에서 시트나 폼, 워크플로를 만들고 실제 결과를 검증할 수 있습니다. 새 예외가 나오면 Learn에서 그 건만 고치는 대신 구조와 검증을 갱신하고 다시 실행합니다. 이것이 사용자가 말씀하신 ‘알아서’입니다. Agent가 다음 단계를 주도하지만, 미정 정책과 위험한 실행은 사람에게 질문하고 멈춥니다. 사람은 모든 단계를 명령하는 대신 새로운 판단만 제공하고, 반복 순환은 Agent가 맡습니다. 실행할 때는 각 단계의 산출물을 남기게 합니다. 원본 근거, 질문과 답, 확정된 구조, 검증 결과가 이어져야 다음 실행이 앞선 판단을 사용할 수 있습니다. Agent가 지금 어느 단계인지와 다음에 무엇을 확인해야 하는지를 보여 주면 사람은 필요한 지점에서만 개입할 수 있습니다.

마스터 프롬프트 뒤에 붙이는 출력 계약 ②

Agent가 매 순환마다
구조와 자동화 수준을 갱신합니다

매 순환에서 유지할 산출물 계약

매 순환에서 아래 6개를 최신 상태로 유지해.
① 데이터: 이름·의미·형식·필수·허용값·원문 근거
② 상태: 시작·변경 조건·종료·예외 상태
③ 규칙: 조건·처리·결과·확정/미정
④ 검증: 정상·경계·실패 입력과 기대 결과
⑤ 재실행: 다음 사례를 넣는 최소 입력 양식
⑥ 실행 수준: 수동 / 사람 승인 후 Agent / 자동

다음 수준으로 올릴 때는 근거를 보여줘.
반복 규칙·검증 통과·도구 권한·실패 복구·기록이 없으면 올리지 마.
새 예외는 기존 구조의 어느 부분을 바꿨는지 표시하고 다시 검증해.

두 번째 프롬프트는 Agent가 매 순환마다 무엇을 남길지 정하는 출력 계약입니다. 마스터 프롬프트 뒤에 붙이면 사용자가 표, 규칙, 자동화를 매번 따로 명령할 필요가 줄어듭니다. Agent는 데이터 항목과 원문 근거를 유지하고, 시작·변경·종료와 예외 상태를 정리합니다. 조건·처리·결과를 규칙으로 남기고 확정과 미정을 표시합니다. 정상·경계·실패 사례와 기대 결과, 다음 사례를 넣을 최소 입력도 만듭니다. 여섯 번째가 80대20에서 20대80으로 움직이는 핵심입니다. Agent가 각 처리를 수동, 사람 승인 뒤 실행, 자동 실행 중 어디에 둘지 평가합니다. 반복 규칙과 검증 사례, 도구 권한, 실패 복구, 실행 기록이 준비되면 다음 수준을 제안하고, 부족하면 필요한 조건부터 알립니다. 새 예외가 나오면 그 건만 고치지 않습니다. 데이터, 상태, 규칙, 검증 중 무엇이 바뀌었는지 표시하고 전체 검증을 다시 돌립니다. 사람의 일은 모든 단계 지시에서 새 정책과 위험한 승인 결정으로 줄어듭니다. 참가자 명단에 31번째 신청자가 들어왔다고 해보겠습니다. 정원과 대기 규칙, 경계 사례가 확인됐다면 Agent는 새 명령 없이 대기 상태와 번호를 계산합니다. 동반 신청 상한처럼 미정인 정책은 자동 처리하지 않고 사람에게 돌립니다. 승격은 느낌으로 결정하지 않습니다. 같은 규칙이 여러 입력에서 통과했는지, 실패 때 되돌릴 수 있는지, 승인이 기록되는지 확인합니다. 조건이 부족하면 현재 단계에서 안전하게 반복할 방법을 남깁니다. 각 산출물은 연결됩니다. 데이터 항목은 상태와 규칙에서 같은 이름으로 참조하고, 검증 사례는 확인할 규칙과 연결합니다. 승격 때도 통과 사례와 남은 위험을 기록합니다. 이 계약이 있으면 매번 다른 답을 받지 않습니다. 사람도 데이터, 상태, 규칙, 검증, 실행 수준 순서로 검토해 빠진 것을 빨리 찾습니다.

LLM Wiki 도구가 연결된 Agent에서 쓰는 프롬프트 ③

다음 작업 전에 기억을 회상하고,
끝난 뒤에는 배운 판단만 남깁니다

LLM Wiki 회상·학습 프롬프트

먼저 LLM Wiki 도구를 사용할 수 있는지 확인해.
없으면 기억했다고 말하지 말고 이번 대화에만 적용해.

[작업 시작 전]
이 프로젝트·산출물·스타일과 관련된 이전 결정·선호·
판단 기준·실패 원인을 좁게 회상해 적용해.
현재 요청과 충돌하면 현재 요청을 우선해.

[작업 종료 전]
작업이 끝나면 이번에 새로 확인된 내용 중
다음에도 재사용할 수 있는 암묵지만 후보로 분리해줘.
기존 관련 기억이 있으면 읽고 병합하고, 없을 때만 새로 저장해.
일회성 상태·민감정보·검증되지 않은 추측은 저장하지 마.

현재 요청 우선관련 기억은 병합재사용할 판단만민감정보는 제외

세 번째는 LLM Wiki를 사용할 때의 프롬프트입니다. 먼저 전제가 하나 있어요. 사용하는 AI Agent에 LLM Wiki 도구가 실제로 연결되어 있어야 합니다. 연결이 없다면 이 문장을 붙여도 장기 기억에 저장되는 것은 아닙니다. 그래서 첫 줄에서 도구 사용 가능 여부를 확인하게 했습니다. 업무 구조를 표와 규칙으로 남기는 것처럼, 나와 AI가 함께 일하며 알게 된 선호와 판단 기준도 다음 작업에 이어 줄 수 있어요. 예를 들어 제가 “발표 대사는 문서처럼 쓰지 말고 실제로 말하듯 써달라”고 교정했다면, 다음 발표에서도 다시 쓸 수 있는 판단 기준입니다. 사용 순서는 두 번입니다. 일을 시작하기 전에는 프로젝트와 산출물에 관련된 기억만 좁게 찾아 적용합니다. 작업이 끝난 뒤에는 이번에 새로 확인된 내용 중 다음에도 쓸 판단만 저장 후보로 고릅니다. 그렇다고 모든 대화와 결과를 통째로 저장하는 건 아닙니다. 다음에도 재사용할 수 있는 선호, 산출물 형식, 검증 기준, 확인된 실패 원인만 골라 기존 기억과 합칩니다. 원본 파일에서 쉽게 다시 확인할 사실도 기억에 중복 저장하지 않습니다. 오늘만 필요한 상태, 개인정보, 비밀번호, 아직 검증되지 않은 추측은 남기지 않고요. 또 과거 기억보다 지금 사용자의 요청이 우선입니다. 기억을 많이 쌓는 게 목적이 아니라, 관련된 판단만 정확히 다시 사용해서 원하는 첫 결과에 더 빨리 가까워지는 게 목적이에요. LLM Wiki는 참가자 명단이나 주문 내역을 보관하는 업무 데이터베이스가 아니라, 내가 확인한 작업 방식과 판단 기준을 이어주는 기억이라고 구분하시면 됩니다.

마스터 프롬프트 검증 사례 · 행사 운영을 솔루션으로

처음 손에 있는 것은
흩어진 말과 파일입니다

카톡 원본

“저 처음 참가해요. AI 자동화에 관심 있고요. 친구와 같이 가도 될까요?”

담당자 메모

정원 30명 · 입금 후 확정 · 취소 시 대기자에게 연락

아직 모르는 것

동반 신청 인원 · 대표 연락처 · 자동 승급 여부

첫 질문: 어떤 앱을 만들까?
→ 다음에도 기억해야 할 것은 무엇일까?

그럼 이 프롬프트가 실제로 어떻게 움직이는지, 행사 신청 업무로 한번 따라가 볼게요. 참가자가 카톡으로 “처음 참가하고 AI 자동화에 관심이 있는데 친구와 같이 가도 되나요?”라고 물었습니다. 담당자에게는 정원 30명, 입금 후 확정, 취소 시 대기자에게 연락한다는 메모가 있고요. 이 업무 설명과 원본을 Agent에게 넣습니다. 이때 참가자의 실제 문장과 담당자의 운영 메모는 근거가 다르므로 섞지 않고 출처를 구분해 둡니다. 사용자가 “먼저 질문해”, “그다음 표를 만들어”라고 단계마다 지시하지 않습니다. 마스터 프롬프트가 Agent에게 Explore부터 시작하라고 이미 알려줬기 때문에, Agent가 동반 신청 인원과 대표 연락처, 자동 승급 여부처럼 아직 모르는 정책을 먼저 찾습니다.

Agent가 스스로 선택한 Explore 단계

첫 번째 출력은 앱이 아니라
좋은 질문입니다

AI가 묻습니다

정원이 차면 어떻게 하나요?

동반 신청은 몇 명까지인가요?

사람이 확정합니다

초과 신청은 접수 순서대로 대기

동반 신청은 최대 5명, 대표 연락처 필수

답을 모르면 ‘미정’으로 남깁니다. AI가 정책을 대신 만들게 두지 않습니다.

원본을 받은 Agent는 마스터 프롬프트의 Explore 규칙에 따라 첫 행동으로 질문을 선택합니다. 사용자가 질문 목록을 따로 설계하지 않아도 됩니다. “정원이 차면 어떻게 하나요?”, “동반 신청은 몇 명까지 가능한가요?”, “취소가 생기면 대기자를 자동으로 올리나요?” 같은 질문이 나오겠죠. 이제 사람이 답합니다. 초과 신청은 접수 순서대로 대기, 동반 신청은 최대 5명, 대표 연락처는 필수라고 확정합니다. 아직 답을 정하지 못한 질문이 있다면 억지로 채우지 않고 ‘미정’으로 둡니다. 담당자끼리 합의해야 할 정책을 AI가 대신 만들어 버리면, 틀린 구조가 아주 빠르게 자동화될 수 있으니까요. 이 단계에서 사람이 하는 일은 다음 명령을 만드는 것도, 코딩하는 것도 아닙니다. Agent가 찾아낸 모호한 부분 가운데 실제 정책만 답하고, 아직 결정하지 못한 것은 미정으로 두는 일입니다. 답을 받으면 Agent는 스스로 Capture와 Structure로 넘어갑니다. 질문에도 우선순위가 있습니다. 결과를 크게 바꾸거나 잘못 처리하면 되돌리기 어려운 질문부터 묻고, 한 번에 너무 많은 질문을 쏟아내지 않습니다. 이 사례에서는 정원 초과 처리와 동반 신청 기준이 먼저고 화면 색상 같은 선택은 뒤로 미뤄도 됩니다. 각 질문 옆에는 왜 필요한지와 어느 원문에서 나온 의문인지 근거를 붙입니다. 그러면 담당자는 AI의 추측을 사실로 받아들이지 않고 자신의 업무 지식이 필요한 지점을 바로 확인할 수 있습니다. 답을 받은 Agent는 확정, 미정, 추정 금지를 구분해 다음 구조로 넘깁니다. 이 구분이 이후 자동화의 안전 경계가 됩니다.

사람의 답을 받은 Agent가 Capture → Structure로 진행

말이 기억할 칸으로 바뀝니다

기억할 항목	형식	필수	허용값·조건
이름	짧은 글	예	빈 값 불가
연락처	전화번호	예	형식 검사
첫 참여	예/아니요	예	둘 중 하나
관심 주제	복수 선택	아니요	AI · 웹 · 데이터 · 기타
신청 단위	선택	예	개인 · 단체

AI가 초안을 만들고, 현업 담당자가 항목·형식·필수 여부를 확정합니다.

사람이 질문에 답하면 에이전트는 그 말을 다음에도 쓸 칸으로 바꿉니다. 표의 열을 일일이 지정하지 않아도 앞의 약속에 따라 항목을 정리합니다. 이름은 짧은 글이고 필수입니다. 연락처는 전화번호 형식으로 검사합니다. 첫 참여 여부는 예와 아니요 중 하나, 관심 주제는 여러 개를 고릅니다. 동반 신청을 받으려면 신청 단위도 개인과 단체로 구분합니다. 중요한 건 AI가 표를 만든 사실이 아닙니다. 현업 담당자가 다음 행사에도 필요한지, 필수 여부와 허용값이 맞는지 확인하고 확정했다는 사실입니다. 확정된 표는 엑셀이나 구글 시트에 옮겨도 됩니다. 앱이 없어도 업무의 기억이 생겼고, 다음 행사에서는 같은 말을 다시 해석하지 않고 값을 넣습니다. 원문 근거도 남겨야 합니다. 동반 인원 두 명이 어느 카톡 문장에서 나왔는지 연결하면 추출 결과를 확인할 수 있습니다. 값만 남기면 잘못 추출했을 때 고칠 근거를 찾기 어렵습니다. 필수와 선택, 허용값과 형식, 개인정보 여부도 구분합니다. 이름은 필수지만 관심 주제는 선택일 수 있고, 연락처는 저장 기간과 접근 권한을 정합니다. 이 계약으로 Agent는 빠진 값을 질문하고 허용되지 않은 값은 추측하지 않습니다. 한 행뿐 아니라 각 열의 의미와 허용값을 정한 스키마가 다음 입력에도 재사용됩니다. 거대한 데이터베이스부터 만들 필요는 없습니다. 다음 사례에 꼭 필요한 항목부터 시작해 실제 예외가 나올 때 근거와 함께 확장합니다. 작은 표라도 입력 규칙과 검증이 있으면 복사된 파일보다 오래 사용할 수 있습니다.

구조를 읽은 Agent가 상태·규칙으로 확장

말이 변화의 규칙으로 바뀝니다

신청

→

입금 확인

→

참가 확정

→

출석 / 취소

정원 초과이면 대기 · 취소 발생이면 대기 순서대로 승급 · 모든 변화는 기록

Agent는 데이터 칸에서 멈추지 않습니다. 참가자의 현재 상태와 다음 상태로 이동할 조건도 정리합니다. 이 사례는 ‘신청’으로 들어와 입금이 확인되면 ‘참가 확정’으로 바뀝니다. 정원을 넘으면 ‘대기’가 되고, 확정자가 취소하면 첫 대기자를 승급합니다. 규칙은 “조건·처리·결과”로 적습니다. “확정 인원이 정원 이상이면 새 신청을 대기로 바꾸고 접수 순서대로 번호를 부여한다.” 같은 식입니다. 처음에는 담당자가 체크리스트로 실행해도 됩니다. 반복해서 규칙이 맞는지 확인한 뒤 알림이나 상태 변경을 자동화합니다. 정형화가 먼저입니다. 상태 이름은 겹치지 않아야 합니다. 신청과 확정 사이에 입금 확인 중이 필요한지, 취소와 환불 완료를 나눌지도 현업이 정합니다. 시작과 종료가 분명해야 동시에 확정과 대기로 남는 모순을 막습니다. 규칙에는 우선순위도 필요합니다. 정원이 찬 뒤 입금된 경우 무엇을 먼저 적용할지, 취소자가 여러 명이면 누구를 올릴지 정합니다. 미정인 충돌은 Agent가 풀지 않고 검토로 보냅니다. 상태 변화에는 이유와 시각을 기록합니다. 누가 입금을 확인했고 어떤 규칙으로 대기 1번이 확정됐는지 남겨야 잘못된 결과의 원인을 찾습니다. 자동화할수록 실행 기록이 중요합니다. 금지된 이동도 적습니다. 취소 참가자를 바로 확정하지 못하게 하고, 같은 입금을 두 번 처리해도 상태가 중복되지 않게 합니다. 체크리스트로 빠진 전이와 예외를 찾고 정상·경계·실패 사례가 통과한 뒤에만 자동화합니다. 사람이 하던 순서가 합의된 규칙인지 먼저 확인하는 겁니다.

Agent가 자동화 승격 전에 검증 기준을 생성

“잘 돼야 해요”를
확인 가능한 사례로 바꿉니다

정상

신청 20명

20명 모두 접수, 입금 확인 후 확정

경계

31번째 신청

정원 30명일 때 대기 1번

실패

잘못된 연락처

저장·발송 전에 오류 표시

세 사례의 기대 결과를 사람이 확인한 뒤, 다음 실행의 기준으로 남깁니다.

다음으로 에이전트는 “잘 돼야 해요”를 확인 가능한 사례로 바꿉니다. 검증 사례가 없으면 자동 실행으로 올리지 않습니다. 정상 사례는 신청 스무 명이 접수되고 입금 뒤 확정되어야 합니다. 경계 사례는 서른한 번째 신청자가 대기 1번이 되어야 합니다. 실패 사례는 잘못된 연락처를 저장하거나 문자를 보내기 전에 오류가 나야 합니다. 기대 결과도 사람이 확인합니다. 사례를 먼저 적으면 엑셀 수식, 자동화, 앱 모두 같은 기준으로 검사할 수 있습니다. AI를 믿어서가 아니라 내가 확정한 사례와 일치해서 통과시키는 겁니다. 검증 사례에는 입력, 실행 조건, 기대 결과를 적습니다. 참가자 수와 입금 여부를 넣고 최종 상태와 알림까지 확인해야 도구가 바뀌어도 비교할 수 있습니다. 새 예외는 검증 목록에 추가합니다. 고친 연락처 오류가 다음 변경 뒤 재발하지 않는지 전체 사례로 확인합니다. 실패가 재현 가능한 사례로 남아야 수동 확인을 줄이면서 품질을 지킵니다. 이렇게 쌓인 사례는 회귀 검증 묶음이 됩니다. 규칙이나 화면을 바꿀 때마다 에이전트가 전체 사례를 다시 실행하고, 어느 입력이 어떤 기대 결과와 달라졌는지 보여줍니다. 사람은 달라진 결과가 의도한 변경인지 확인해 승인 기록을 남깁니다.

미니 데모 · 정형 구조를 재사용하고 새 예외만 반환

다음 달 행사를 넣어봅니다

9월 부산 모각코

정원40명

신청43명

확정 취소2명

새 조건단체 신청 있음

처리 결과

확정40명

대기1명

자동 승급2명

검토 필요단체 신청 규칙

이제 진짜 판정 순간입니다. Agent가 지난 행사를 복사해서 다시 고치라고 묻는 대신, 자신이 만든 최소 입력 양식에 다음 달 행사 값만 받습니다. 정원은 40명, 신청은 43명이고 확정자 가운데 두 명이 취소했습니다. 여기까지는 이미 데이터와 규칙이 있어요. 그럼 같은 규칙으로 한번 처리해 볼게요. 에이전트는 먼저 43명을 접수 순서대로 정렬합니다. 정원 40명까지 확정하고 나머지 세 명에게 대기 번호를 부여합니다. 그다음 확정자 두 명의 취소를 처리하고 대기 1번과 2번을 차례로 승급합니다. 그래서 확정 인원은 다시 40명, 남은 대기는 한 명이 됩니다. 사람이 계산 순서를 지시한 것이 아니라 지난번 규칙이 실행된 겁니다. 결과가 나왔습니다. 확정 40명, 대기 1명, 자동 승급 2명입니다. 지난번에 합의한 정원·대기·취소 규칙을 다시 설명하지 않았는데도 Agent가 같은 구조와 검증 기준을 사용했습니다. 바로 이 부분이 80대20에서 20대80으로 이동한 효과입니다. 그런데 이번에는 단체 신청이라는 새 조건이 들어왔습니다. 아직 단체 신청 규칙이 구조에 없다면 시스템이 임의로 승인하거나 거절하면 안 되겠죠. 그래서 ‘검토 필요’로 남기고 사람에게 돌려줍니다. 여기서 중요한 것은 멈춘 범위입니다. 이미 확정된 개인 신청과 대기 승급까지 전부 사람에게 되돌리지 않습니다. 단체 신청 한 건만 격리하고, 몇 명까지 허용할지와 대표 연락처 하나로 충분한지를 질문합니다. 사람이 답하면 그 결정은 신청 단위의 허용값과 검증 사례에 추가되어 세 번째 실행부터 재사용됩니다. 두 번째 실행이 성공했다는 기준은 화면이 빨리 나왔다는 것이 아닙니다. 지난번에 설명했던 판단이 다시 쓰였고, 기존 사례가 통과했으며, 처음 보는 정책만 사람에게 돌아왔는지를 봅니다. 실행 시간이 아니라 재설명과 수동 판단의 감소를 측정하는 겁니다. 두 번째 실행에서는 Agent가 입력을 구조에 넣고, 기존 규칙을 적용하고, 결과를 검증하고, 모르는 단체 신청만 사람에게 돌렸습니다. 사람이 네 단계를 각각 지시하지 않았습니다. 이미 배운 판단은 Agent가 이어서 처리하고 새로운 판단만 사람에게 묻는 상태, 바로 이것이 우리가 말하는 ‘알아서’입니다.

사람이 새 정책을 답하면 Agent가 Learn 단계로 진행

한 번 판단하고
시스템의 자산으로 흡수합니다

새로운 단체 신청 예외가 사람의 판단을 거쳐 데이터, 규칙, 검증으로 흡수되고 다음에는 자동 처리되는 이미지

예외를 재발하지 않는 구조로 바꾸는 네 단계

1

새 예외 발견단체 신청은 기존 규칙으로 처리 불가

↓

2

사람이 정책 결정최대 5명 · 대표 연락처 필수

↓

3

데이터·규칙·검증 추가판단을 시스템이 다시 쓸 구조로 기록

↓

4

다음부터 자동 처리같은 예외를 다시 설명하지 않음

사람이 단체 신청 정책을 답하면 Agent는 Learn 단계로 진행합니다. 단체 신청을 이번 건만 손으로 승인하고 끝내면 다음 행사에서도 똑같이 물어봐야 한다는 것을 운영 프롬프트가 알고 있기 때문입니다. 먼저 사람이 정책을 정합니다. 예를 들어 최대 5명까지 가능하고 대표 연락처는 반드시 받는다고 합의합니다. 그러면 데이터에는 신청 단위, 단체 인원, 대표 연락처를 추가합니다. 규칙에는 5명을 넘으면 검토 필요로 보내고, 대표 연락처가 없으면 접수를 막는 조건을 넣습니다. Agent는 검증 사례도 보탭니다. 5명 신청은 정상 접수, 6명 신청은 검토 필요, 대표 연락처가 없으면 오류라는 기대 결과를 만들고 다시 실행합니다. 통과하면 다음부터 이 예외를 자동 처리하는 수준으로 올릴 수 있다고 먼저 제안합니다. 이렇게 하면 예외 때문에 시스템이 무작정 복잡해지는 게 아닙니다. 한 번 내린 판단이 데이터·규칙·검증으로 들어가서 시스템의 지식이 되고, 다음부터는 같은 설명이 사라집니다.

80:20 → 20:80은 한 번에 점프하지 않습니다

Agent가 현재 단계를 진단하고
다음 자동화 후보를 먼저 제안합니다

① 비정형 탐색Agent가 질문·근거 수집

② 구조 초안시트·체크리스트로 정리

③ 입력 정형화폼·스키마로 빠짐 방지

④ Agent 실행도구 사용 · 사람 승인

⑤ 자동 순환검증·기록 · 예외는 반환

사람은 새 판단만 답합니다. 단계 진단·산출물 갱신·다음 제안·재검증은 Agent가 이어갑니다.

여기쯤 오면 이런 질문이 생길 수 있어요. “프롬프트만 잘 설계하면 AI Agent가 알아서 수동 업무를 자동화 쪽으로 이끌어 주나요?” 네. 방금 본 운영 프롬프트와 필요한 도구가 연결되어 있다면, Agent가 이 사다리의 다음 단계를 먼저 제안하도록 만들 수 있습니다. 처음에는 Agent가 비정형 원본을 읽고 질문과 근거를 모읍니다. 다음에는 시트나 체크리스트 형태의 구조 초안을 만들고, 빠지는 입력이 보이면 폼과 스키마를 제안합니다. 규칙과 검증 사례가 갖춰지면 연결된 도구를 사용하되 사람 승인을 받는 실행을 제안하고요. 그 실행이 반복해서 검증되면 자동 순환 후보로 올립니다. 사람이 매번 “다음에는 표를 만들어”, “이제 폼을 만들어”, “이제 자동화해”라고 세세하게 지시하는 게 아닙니다. Agent가 현재 구조와 검증 결과를 보고 다음 후보를 먼저 제안하고, 필요한 도구가 있으면 승인 뒤 실행합니다. 사람은 새 정책과 위험한 승인만 답합니다. 이때 사람의 반복 지시가 80에서 20으로 줄고 Agent의 구조화·실행 비중이 20에서 80으로 올라갑니다.

업무 데이터는 시트·DB에, 재사용할 판단은 LLM Wiki에

기억을 많이 쌓는 것이 아니라
관련 판단을 다음 실행에 이어줍니다

반복된 교정과 선호가 개인의 지식 라이브러리에 축적되고 다음 작업 전에 관련 기억으로 회상되는 학습 순환 이미지

시작 전 회상 → 작업 → 확인 → 병합

1

관련 기억을 좁게 회상프로젝트 · 산출물 · 스타일 기준

↓

2

현재 요청과 비교해 적용충돌하면 지금 요청이 우선

↓

3

결과를 사람이 확인·교정원하는 방향과 실패 원인을 확인

↓

4

재사용할 판단만 병합민감정보 · 일회성 상태 · 추측은 제외

다음 작업을 시작할 때 관련 기억을 다시 회상

그럼 LLM Wiki는 실제로 어떻게 쓰는지 순서대로 볼게요. 먼저 업무 데이터와 LLM Wiki를 구분해야 해요. 행사 참가자 명단, 신청 상태, 금액 같은 업무 데이터는 엑셀·시트·데이터베이스에 둡니다. LLM Wiki에는 “발표 대사는 말하듯 쓴다”, “PDF도 전체 페이지를 검수한다”처럼 다음 작업에도 쓸 작업 방식과 판단 기준을 남깁니다. 첫 번째, 작업을 시작하기 전에 프로젝트·산출물·스타일에 관련된 기억을 좁게 회상합니다. 두 번째, 과거 기억과 지금 요청을 비교하고 충돌하면 지금 요청을 우선합니다. 세 번째, 결과를 본 사람이 맞는 방향과 고쳐야 할 실패를 확인합니다. 네 번째, 그 교정 가운데 다음에도 쓸 판단만 기존 관련 기억과 합칩니다. 예를 들어 “대사를 말하듯 써줘”라는 교정을 그대로 한 줄 저장하는 데서 끝내지 않습니다. 적용 범위는 발표자료, 원치 않았던 것은 화면을 읽는 문어체, 원하는 것은 실제 무대 구어체, 확인 방법은 소리 내어 읽기라고 정리해 두면 다음 발표에서 더 정확하게 재사용할 수 있습니다. 이건 AI가 저절로 내 마음을 읽거나 결과를 보장한다는 뜻이 아닙니다. 내가 직접 말하고 확인한 기준을 관련 작업에서 다시 사용하는 겁니다. 그래서 같은 설명과 이미 고친 실패가 줄어들고, 원하는 첫 결과에 더 빨리 가까워질 가능성이 커집니다. 도구가 연결되어 있지 않다면 장기 기억은 생기지 않습니다. 또 연결되어 있어도 개인정보, 비밀번호, 일회성 상태, 아직 확인되지 않은 추측은 저장하지 않습니다.

발표 후 20~30분 · 혼자 따라 하는 실습 가이드

한 번에 자동화하지 말고
두 번 실행해 차이를 확인합니다

1단계 시작 프롬프트 · 첫 응답은 질문까지만

내 반복 업무를 점진적으로 정형화하는 Agent로 일해줘.
지금은 첫 단계만 수행해.

1. 아래 원본에서 확인된 사실과 미정을 구분해.
2. 반복할 때 꼭 결정해야 할 질문을 최대 3개만 물어봐.
3. 정책을 추측하거나 자동화를 제안하지 말고 내 답을 기다려.

[내 업무 설명]
[개인정보를 가린 실제 원본 1건]

준비 · 반복 업무 설명과 실제 원본 한 건
첫 응답 확인 · 질문 3개 이내로 묻고 멈추는가?
사람이 답하기 · 미정 정책 하나씩 확정
구조 갱신 · 입력·상태·규칙·검증과 다음 단계 하나
두 번째 실행 · 같은 설명 없이 새 예외만 묻는가?

완료 기준 · 두 번째 원본에서 재설명과 반복 판단이 줄었다.

이 페이지는 지금 여기서 4분 안에 결과물을 완성하는 실습이 아니에요. 발표가 끝난 뒤 20분에서 30분 정도 시간을 잡고, 여러분의 실제 업무로 따라 해보는 안내서입니다. 필요하시면 화면을 사진으로 찍어 두셔도 좋습니다. 목표부터 분명히 할게요. AI에게 멋진 표 하나를 받는 게 목표가 아닙니다. 첫 번째 실행보다 두 번째 실행에서 내가 설명할 말과 직접 판단할 일이 줄어드는지 확인하는 겁니다. 이 차이가 보여야 Agent가 비정형을 정형으로, 수동을 자동으로 이끌고 있다고 말할 수 있어요. 먼저 매주나 매달 되풀이하는 일을 하나 고르세요. 행사 신청 정리, 회의록에서 할 일 뽑기, 견적 요청 분류처럼 실제로 반복하는 일이면 됩니다. 그리고 개인정보를 가린 카톡이나 메일, 메모 한 건을 준비합니다. 지금 머릿속으로 업무 하나를 떠올려 보실까요? 새 담당자에게 넘길 때 설명이 길어지는 일, 할 때마다 같은 결정을 다시 묻는 일이라면 좋은 후보입니다. 준비가 됐다면 화면 왼쪽 프롬프트만 먼저 넣으세요. 일부러 첫 단계만 시키는 프롬프트입니다. 처음부터 표와 규칙과 자동화를 한꺼번에 요구하면 Agent가 모르는 정책까지 추측할 수 있고, 우리는 무엇이 사실이고 무엇이 가정인지 확인하기 어려워집니다. 첫 답에서는 두 가지만 봅니다. 확인된 사실과 아직 정하지 않은 내용을 나눴는가. 그리고 정말 중요한 질문을 세 개 이내로 묻고 멈췄는가. Agent가 바로 자동화를 제안하거나 회사 정책을 마음대로 정했다면 아직 성공이 아닙니다. 행사 신청 업무라면 “정원이 차면 대기로 돌리나요?”, “취소가 생기면 누구를 먼저 올리나요?”, “단체 신청은 몇 명까지 받나요?” 같은 질문이 나오겠죠. 이때 우리가 할 일은 표의 열을 설계하는 게 아니라 실제 정책을 답하는 겁니다. 아직 합의하지 못한 건 ‘미정’이라고 답해도 됩니다. 질문에 답한 뒤에는 이렇게 이어가세요. “방금 답을 반영해서 입력 항목, 상태, 규칙, 정상·경계·실패 사례를 정리하고, 지금 할 다음 단계 하나만 제안해줘.” 여기서는 ‘다음 단계 하나만’이 중요합니다. Agent가 너무 멀리 뛰지 않고 지금 확인할 수 있는 변화만 제안하게 만드는 거예요. 구조가 나오면 빠진 입력은 없는지, 규칙의 조건과 결과가 맞는지, 실패 사례에서 정말 멈추는지 확인합니다. 틀렸다면 왜 틀렸는지 말해 주세요. 그 교정이 다음 실행에서 다시 쓸 규칙과 검증 기준이 됩니다. 이제 같은 종류의 원본을 하나 더 넣습니다. 두 번째에도 정원과 대기 규칙을 처음부터 설명해야 할까요? 아니죠. 이미 정한 내용은 그대로 처리하고, 이번에 처음 나온 예외만 질문해야 합니다. 여기서 잠깐 첫 번째 답과 두 번째 답을 나란히 놓고 보세요. 질문 수가 줄었는지, 이미 확정한 정책을 다시 묻지 않는지, 새 예외가 분리되어 있는지를 확인하면 됩니다. 두 번째 원본을 기존 정책 설명 없이 처리하고 새 예외만 묻는다면 성공입니다. 같은 질문을 반복하거나 임의 정책을 만들었다면 기억할 구조나 멈춤 조건을 보완하면 됩니다. 완료 기준은 앱 하나를 만든 상태가 아닙니다. 첫 번째보다 두 번째 실행에서 재설명과 반복 판단이 줄어든 상태예요. 그 변화가 보이면 사람의 반복 지시는 줄고 Agent가 재사용하는 비중은 커집니다. 바로 그때 80대20이 20대80으로 움직이기 시작합니다.

내 답에 표시

우선순위

자주 반복되고, 자주 틀리고,
판단 비용이 큰 것부터

①반복 빈도

매주·매달 다시 하는가?

②실수 비용

틀리면 고객·시간·돈에 영향?

③설명 비용

새 담당자에게 오래 설명?

완료를 판정하는 법

“됐다”가 아니라
다섯 가지 변화를 측정합니다

✓

재실행 시간이 줄었다

✓

재설명 문장이 줄었다

✓

수동 판단 수가 줄었다

✓

오류를 먼저 발견한다

✓

다른 사람도 실행한다

→

두 번째가 더 쉽다

성숙의 순환

사람이 다음 명령을 만드는 단계에서
Agent가 다음 구조를 제안하는 단계로

① 운영 프롬프트

→

② Agent 탐색·질문

→

③ 구조·도구·검증

→

④ 자동 실행·예외 학습

내일부터 Agent에게 맡길 세 질문

① 내 비정형 원본에서 무엇을 찾아야 하는가?

② 무엇을 구조·규칙·검증으로 옮길 수 있는가?

③ 다음 자동화 단계는 무엇이며, 무엇이 더 필요한가?

한 문장으로 마칩니다

Agent가 답만 만들게 하지 말고,
다음 정형화와 자동화를 스스로 이끌게 하십시오.

비정형에서 정형으로 · 수동에서 자동으로 · 80:20에서 20:80으로

Q&A · 발표 50분 이후 별도 6분

질문을 받겠습니다

자주 나오는 질문

처음부터 완벽하게 구조화해야 하나요?
AI가 잘못 추출하면 어떻게 하나요?
Agent가 정말 다음 단계를 알아서 이끄나요?

짧은 답

완벽하게가 아니라 반복 판단 하나씩 옮깁니다.

중요한 값은 사람의 확인과 검증 규칙을 둡니다.

운영 프롬프트와 도구가 있으면 Agent가 질문·구조화·실행·재검증을 이어갑니다.

전체 근거 링크: OpenAI · Microsoft Learn · Anthropic Research/Engineering · Google DORA · METR · Google RCT · GitHub Research

준비한 이야기는 여기까지입니다. 이제 궁금하신 점을 편하게 말씀해 주세요. 먼저 자주 나오는 질문 세 가지부터 짧게 답해볼게요. “처음부터 완벽하게 구조화해야 하나요?” 전혀 그렇지 않습니다. 반복 판단 하나부터 옮기고 실제로 써보면서 다음 예외를 배우면 됩니다. “AI가 잘못 뽑으면 어떻게 하나요?” 그래서 중요한 값에는 사람의 확인 단계를 두고, 정상·경계·실패 사례로 검증합니다. 오류가 났을 때 무엇이 틀렸는지도 기록해 다음 규칙에 반영하고요. “Agent가 정말 다음 단계를 알아서 이끄나요?” 네. 운영 프롬프트에 반복 순환과 산출물 계약을 주고 구조화 출력, 도구, 승인, 검증을 연결하면 Agent가 질문·구조화·실행·재검증을 이어갈 수 있습니다. 공식 Agent 프레임워크에도 이 루프와 도구 호출, 사람 승인, 추적 기능이 구현되어 있습니다. 다만 미정 정책과 위험한 실행은 사람에게 돌린다는 경계까지 함께 설계해야 합니다. 다른 질문도 편하게 말씀해 주세요.

사용할수록정리되는바이브 코딩

AI에게 부탁해서뭔가 작동하게 만들어본 적 있나요?

“앱이 만들어졌습니다.”그런데 다음 달에도 됩니까?