SITE SEARCH

검색

사이트 전체 글을 빠르게 찾을 수 있습니다.

RSS FEED

RSS 구독

RSS 리더에서 Project Research의 새 글을 바로 받아볼 수 있습니다.

EMAIL SUBSCRIBE

이메일 구독

새 글을 이메일로 받아봅니다. RSS는 별도 RSS 아이콘을 눌러 동일한 크기의 패널에서 열 수 있습니다.

이메일로 블로그 구독하기

이 블로그를 구독하고 이메일로 새글의 알림을 받으려면 이메일 주소를 입력하세요







나의 Agent 비서, 블록 12개로 조립한다 — 현장 실측이 찾아낸 재사용 블록과 77%의 법칙

시리즈

AX Series · 실전 도구

“나만의 AI 비서를 만들라”는 조언은 넘칩니다. 문제는 매번 백지에서 시작하다 좌초한다는 것. 기업 워크숍에서 실무자 14명의 비서 아이디어를 기능 단위 53건으로 분해해 보니, 반복되는 재사용 블록은 딱 12종이었고 상위 6개가 쓰임의 77%였습니다. 비서는 짓는 게 아니라, 조립하는 것입니다.

바쁜 분을 위한 3줄 요약

① 실무자들의 비서 아이디어를 분해하면 재사용 블록 12종으로 수렴합니다 — 개인화는 그 위의 얇은 층(약 20%)입니다.
수집·초안·리서치·근거검증·요약·정기브리핑 — 이 6개 블록이 전체 쓰임의 77%. 공유 블록을 먼저 만들면 조직 전체가 같이 빨라집니다.
③ 모든 비서의 바닥에는 7-스키마 기초(페르소나~안전·HITL)가 깔립니다 — 특히 “최종 확정은 사람”이라는 안전 게이트는 협상 불가입니다.

들어가며

백지의 저주 — ‘나만의 비서’가 좌초하는 이유

워크숍에서 “각자 나만의 AI 비서를 설계해 보세요”라고 하면, 처음 20분은 늘 비슷하게 흘러갑니다. 백지 앞에서 막막해하다가, 옆 사람 것을 흘끔 보다가, “저는 딱히 시킬 게 없는데요”가 나옵니다. 비서를 하나의 완성품으로 상상하기 때문입니다 — 그건 어렵습니다.

그런데 발상을 바꿔서, 이미 나온 비서 아이디어들을 기능 단위로 분해해 보면 어떨까요? 최근 한 통합보안 기업 워크숍(SK쉴더스 편)에서 실무자 14명이 설계한 비서를 기능 단위로 쪼개 봤습니다. 나온 조각은 총 53건 — 그리고 그 53건은 단 12종의 블록으로 전부 분류됐습니다.

이 글의 데이터에 대해. 블록 빈도(53건·77%)는 보안 기업 단일 차수의 관측+추론 집계입니다(통계적 일반화 아님). 대신 이 추론은 한 현장에 기대지 않습니다 — 통신사 15건 제안(1인 1건, SKT 편), 금융사 25건 아이디어(신한EZ손해보험 편), 그리고 조직형 사례인 삼성 GAUSS PM Agent의 모듈 구성(G-1)를 같은 블록 어휘로 재분류해 패턴이 재현되는지 교차 검증했습니다(다음 절).
Part 1 · 블록 카탈로그

비서를 분해하면 12개의 블록이 나온다

14명 × 비서 1개씩을 분해한 53건의 기능 조각을, 같은 것끼리 묶으면 이렇게 됩니다.

표 1 · 재사용 블록 12종 — 사용 빈도순 (53건 분해 실측)
#블록무엇을 하나관측
B1수집·정규화 (Ingest)메일·문서·뉴스·데이터를 모아 지식베이스에 정리11
B5문서 초안 (Draft)기획서·제안서·보고서·답변 초안8
B4리서치·시장분석 (Research)시장·경쟁·트렌드 조사6
B6근거·출처 검증 (Ground)인용·출처 표기·날조 차단6
B2요약 (Summarize)긴 자료를 핵심 요지로5
B8정기 브리핑 (Digest)매일/주간 자동 브리핑5
B7요구·준수 매핑 (Trace)제안요청서→목차, 요구→추적표3
B3분류·태깅 (Classify)완료/진행/할일·위험도 분류2
B9리마인드·추적 (Track)마감·미완료·진척 넛지2
B10데이터 처리 (DataOps)엑셀·집계·지표 계산2
B12HITL 승인 (Gate)발송·확정 전 사람 승인2
B11코칭·비평 (Critique)구조·문장 개선 피드백1
Source: 보안 기업 워크숍 개인별 비서 14건의 기능 분해(53 인스턴스) — 관측+추론 집계 · HITL=사람 사전 승인(Human-in-the-Loop)

여기서 중요한 발견 하나. 굵게 표시한 상위 6개 블록(B1·B5·B4·B6·B2·B8)의 관측 합이 41건 — 전체 53건의 77%입니다. 이른바 파레토(Pareto)의 ‘결정적 소수’가 비서 설계에서도 그대로 나타난 겁니다.

B1
수집·정규화
자료를 모은다
B4·B2
리서치 · 요약
읽고 간추린다
B5
문서 초안
초안을 쓴다
B6
근거 검증
출처를 단다
B8
정기 브리핑
주기적으로 알린다

도식 1 · ‘결정적 소수’ 6블록은 사실상 지식노동의 한 줄기 파이프라인입니다 — 그래서 어느 직무에서나 반복됩니다.

Part 1.5 · 교차 검증

다른 현장에서도 같은 블록이 나온다 — 배합비만 다르다

블록 12종이 보안사 한 곳의 우연이라면 쓸모가 없겠지요. 그래서 다른 세 현장의 에이전트 목록을 같은 블록 어휘로 재분류해 봤습니다.

표 2 · 4현장 교차 검증 — 블록 어휘는 재현되고, 배합비는 도메인이 결정한다
현장표본강하게 나타난 블록
보안사 (블록 빈도 정본)14명 · 53건 분해수집(B1)·초안(B5)·리서치(B4)·근거검증(B6)·요약(B2)·브리핑(B8) — 상위 6블록 77%
통신사 (SKT 기업문화센터)15건 제안 (1인 1건)초안(B5)이 압도(문서·콘텐츠·디자인 8건) + 데이터처리(B10)·리마인드(B9)·분류(B3) — 운영지원 직군 특성. 최고 평점 3건도 전부 블록 2개 조합이었습니다: 안내메일(분류+초안)·예산 모니터링(데이터처리+브리핑)·법정교육 운영(리마인드+데이터처리)
금융사 (신한EZ손해보험)25명 · 아이디어 25건리서치(B4)·근거검증(B6)·데이터처리(B10) + HITL 승인(B12)이 명시적으로 강화 — 프라이싱·보험금·요율처럼 정확성이 걸린 직무가 안전 블록을 키웁니다
삼성전자 (GAUSS PM Agent · 조직형)프로그램 모듈 7요약(B2)+초안(B5)의 회의록→할일 흐름 · 요구·의존성 매핑(B7) · 검증 게이트에서 인간 판정 강제(B12) — 개인 비서가 아니라 조직 하네스인데도 같은 블록 어휘로 기술됩니다
Source: 각 현장 산출물 재분류 — 통신사 15건(포트폴리오 보고서 실측) · 금융사 25건(사전응답 분석, 과제 정의 수준) · 삼성 GAUSS(프로그램 매핑 문서) · 빈도 수치의 정본은 보안사 53건 분해뿐이며 타 현장은 재현 여부만 검증

두 가지가 보입니다. 첫째, 블록 어휘 자체는 어디서나 재현됩니다 — 특히 수집(B1)과 초안(B5)은 예외가 없습니다. 둘째, 배합비는 도메인이 결정합니다. 운영지원 직군은 초안·리마인드로, 금융은 근거검증·사람 승인으로, 조직형 하네스는 요구 매핑·검증 게이트로 무게가 이동합니다. 그러니 표 1의 빈도를 정답이 아니라 출발 배합비로 읽으세요 — 여러분 도메인의 배합비는 여러분 현장이 정합니다.

Part 2 · 기초 공사

블록보다 먼저 — 모든 비서가 공유하는 7-스키마

블록을 조립하기 전에, 모든 비서의 바닥에 깔리는 공통 기초가 있습니다. 어떤 블록을 조합하든 이 7가지가 명시돼 있지 않으면 비서는 “가끔 그럴듯한 말을 하는 챗봇”에 머뭅니다.

표 3 · Foundation 7-스키마 — 비서 1개당 한 장씩 채우는 계약서
#항목계약 내용
1페르소나 (시스템프롬프트)누구로서 · 무엇을 위해 · 어떤 톤 — 역할·전문성·제약 명시
2Input (자료 계약)필요 자료·형식·최신성·접근 권한 — 그리고 망분리 준수
3Tools & Techniques지식베이스(RAG)·프롬프트 체인·요약·분류 — 어떤 기법으로 처리하나
4Output (산출 계약)형식(문서/표/메일 초안)·분량·필수 섹션
5기대수준무엇을 얼마나 잘해야 하는가 — 품질 눈높이
6수용기준 (AC/DoD)측정 가능한 완료조건 3개 (수치 · 0건 · 시연 · 검수 통과)
7안전 게이트최종 확정은 사람 — 사람 사전 승인(HITL) · 개인정보/망분리 · 환각·출처 검증
Source: 워크숍 정본 스키마 — AC=인수기준 · DoD=완료의 정의 · RAG=검색증강생성
7번은 협상 불가입니다. 도메인이 위험할수록 안전 게이트가 강해집니다 — 금융이면 “투자자문 아님 + 수치 단정 금지”, 보안·법무면 “규정 인용은 정본에서만 + 사람 승인 필수”, 인사면 “개인정보 비식별 + 평가 확정은 사람”. 비서가 유능해질수록, 이 줄이 비서를 지켜줍니다.
Part 3 · 조립 레시피

직무군별 레시피 — 새로 짜지 말고, 조합을 바꿔라

블록 12종과 기초 7-스키마가 있으면, 비서 설계는 “무엇을 만들까”가 아니라 “어떤 블록을 몇 개 조합할까”가 됩니다. 현장에서 일반화한 대표 레시피 6종입니다 (설계 제안이므로 현장에서 가감하세요).

표 4 · 직무군별 조립 레시피 — 비서 1개 = 기초 + 블록 3~5개
직무군레시피예시
업무정리·비서형B1+B2+B3+B8+B12일일 업무 브리핑 (완료/진행/할일 + 우선순위)
기획·제안서형B1+B4+B5+B6시장분석 → 기획서 초안 (근거 출처 표기)
수주·제안형B1+B7+B5제안요청서(RFP) → 목차 매핑 → 제안서 초안
자료분석·리서치형B1+B4+B2+B6+B8자료 취합 → 요약 → 출처 검증 → 정기 브리핑
보안·컴플라이언스형B1+B6+B3+B5+B12규정 근거 → 위험 분류 → 보고 초안 → 사람 승인
운영·PM형B1+B10+B7+B9데이터 집계 → 준수 매핑 → 진척 추적
Source: 보안사 14명·통신사 15건·금융사 25건 실측에서 일반화 — 레시피는 설계 제안(현장 가감 전제) · RFP=제안요청서

눈치채셨겠지만 모든 레시피가 B1(수집·정규화)로 시작합니다. 비서의 품질은 조립 솜씨보다 “내 자료가 얼마나 들어가 있느냐”가 먼저 결정합니다 — 자료가 곧 품질입니다. 이것이 개인 지식베이스(RAG)를 비서와 한 몸으로 봐야 하는 이유입니다.

Part 4 · 조립 순서

조립 6단계 — 공유 블록 먼저, 개인화는 얇게

1
공유 블록 먼저. 결정적 소수 6개(수집·초안·리서치·근거검증·요약·브리핑)를 재사용 가능한 프롬프트 블록으로 팀에서 1회만 만듭니다. 최대의 투자수익 구간입니다.
2
기초 고정. 7-스키마 템플릿 1장을 팀 표준으로 채택합니다.
3
레시피대로 조립. 각 비서 = 기초 + 블록 3~5개. 새로 짜지 않고 결합합니다.
4
개인화는 얇게(약 20%). 페르소나·현장 용어·데이터 소스만 개인별로 바꿉니다.
5
수용기준으로 검증. 블록별 완료조건 + 개인 완료조건을 시연으로 확인 — 통과 못 하면 블록을 교체합니다.
6
개선 루프. 공유 블록을 한 곳 고치면 전원의 비서가 동시에 좋아집니다 — 이것이 블록 방식의 숨은 배당입니다.
도구는 바꿔 끼울 수 있습니다. 파일 업로드형 ‘프로젝트 지식’은 B1·B6을, 시스템프롬프트/사용자 지침은 기초+블록을, 예약·스케줄 기능은 B8을 실행하는 자리입니다. 블록은 개념이고, 도구는 실행 경로일 뿐입니다 — 특정 도구에 잠기지 마세요.
오늘 시작

이번 주에 해볼 것 세 가지

1
내 업무를 블록 언어로 번역해 봅니다. “이번 주 한 일”을 표 1의 12블록에 매핑해 보면, 내 비서의 첫 레시피가 보입니다.
2
7-스키마 한 장을 채웁니다. 특히 6번(측정 가능한 완료조건 3개)과 7번(사람이 확정하는 지점)을 먼저.
3
B1부터 켭니다. 내 문서 10개를 지식베이스에 넣고, 넣기 전/후 같은 질문을 던져 차이를 확인해 보세요.
다음 이야기 · 관련 글

이 블록들이 현장에서 실제로 돌아간 기록

📈 AX 전략·조직 전환 (Lv4)
🏢 현장 검증·사례 (Lv1–4)

Project Research에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기