
아이티센 프로젝트 매니저들과 2일을 보냈습니다. “프롬프트 잘 쓰기”가 아니라, 온톨로지에서 실제 공공 제안요청서(RFP) 사업관리까지 한 줄기로 꿰어 ‘내 PM 비서 에이전트’를 만들고 실전에 투입한 이틀의 흐름과, 참여자 설문 25건의 목소리를 정리했습니다.
① 이틀 만에 정체성이 이동했습니다 — “AI 이용자(채팅 소비)”에서 “AI 활용자(에이전트·RAG를 만드는 사람)”로.
② 이 워크숍은 단 하나의 식을 가르쳤습니다 — 민첩성 = [사람이 만드는 베이스라인·대시보드·선순환] × [AI 도구·하네스·RAG]. 곱셈이라 한 인자가 0이면 결과도 0입니다.
③ 가장 또렷한 한 목소리는 “실습 더, 토큰 더, 전 직원에게”였습니다.
채팅창을 닫고, 에이전트를 만들기 시작했다
마지막 날 마무리 설문에서 한 PM이 이렇게 적었습니다.
같은 종이의 다른 칸에는 이런 문장도 있었습니다.
이 두 줄에 이번 워크숍의 전부가 들어 있습니다. 하나는 정체성이 바뀌었다는 증거(이용자 → 활용자)이고, 다른 하나는 그 전환이 진짜였다는 증거(더 하고 싶은데 연료가 모자라더라)입니다. 2026년 6월 24~25일, 공공·금융 시스템통합(SI) 기업 아이티센의 PM들과 이틀을 보냈고, 저는 강의실을 나오며 이 두 문장을 가장 먼저 메모했습니다.
이 워크숍이 가르친 단 하나의 식
다른 Agentic PM 워크숍과 시나리오가 달랐습니다. “프롬프트 잘 쓰기”에서 멈추지 않고, 온톨로지 → 시스템프롬프트(myDNA) → 운영 규칙서(CLAUDE.md) → 검색증강생성(RAG) → 실제 RFP 기반 사업관리 전 과정을 한 줄기로 꿰었습니다. 목표는 단순했습니다 — “내 PM 비서 에이전트를 만들어 실전에 투입한다.”
여기서 제가 가장 강조한 두 가지가 있습니다.
② 사람이 먼저, AI가 나중입니다. 왼쪽 괄호(사람의 PM 역량)가 베이스라인이고, 오른쪽 괄호(도구)가 증폭기입니다. 도구만 켜면 일머리 없는 산출물이 나옵니다.
대부분의 도구 교육은 오른쪽 괄호에서 멈춥니다. “이 도구로 이런 걸 할 수 있어요”까지요. 이번 워크숍이 달랐던 건, 오른쪽으로 왼쪽을 실제 공공 RFP에 적용해 베이스라인–대시보드–선순환을 한 사이클 돌려봤다는 점입니다. 그래서 손에 남는 게 도구 사용법이 아니라 ‘일하는 방식’이었습니다.
이틀 동안 6개의 층을 차례로 쌓았다
워크숍에서 실행한 모든 작업은 아래 6개 층 중 하나에 속합니다. 재현할 때도 “지금 내가 어느 층을 만들고 있나”를 먼저 정하면 길을 잃지 않습니다.
| 층 | 무엇을 만드나 | 입력 → 산출물 |
|---|---|---|
| L0 · 사람 베이스라인 | 일머리·표준을 몸에 익힘 (AI 이전) | 학습 → 역량 |
| L1 · 그라운딩 | 내 레퍼런스 → RAG → 3층 온톨로지 | S급 산출물 → 지식 원소 → ontology.md |
| L2 · 하네스 | 시스템프롬프트 → 운영 규칙서 | 온톨로지 → myDNA.md → CLAUDE.md |
| L3 · 전략 | RFP 분석 → 사전 정보요청(RFI) | RFP 원문 → 분석서 → RFI |
| L4 · 범위 베이스라인 | 이해관계자 → 요구 → 작업분해(WBS)/백로그 → 완료조건(DoD) | RFP → 기획 산출물 |
| L5 · 대시보드 | 건강도 3관점(고객·팀·임원) | 베이스라인 → 대시보드 |
| L6 · 선순환 | (a) 프로젝트 재베이스라인 (b) 하네스 회고 → 규칙 갱신 | 대시보드·세션 → 다음 주기 |
핵심은 L1·L2를 건너뛰지 않는 것입니다. 이번 워크숍이 다른 과정과 갈린 지점이 여기입니다. 보통은 RFP 분석(L3)부터 시작하지만, 우리는 먼저 내 손으로 만든 S급 레퍼런스 10~20개를 AI가 읽을 수 있는 지식 원소로 분해하고(L1), 그 위에 도메인·비즈니스·기술 3층 온톨로지를 세운 뒤(L1), 이것을 항상 작동하는 페르소나(myDNA)와 운영 규칙서(CLAUDE.md)로 응고시켰습니다(L2).
도중에 한 가지 기술을 더 보여드렸습니다. 두 개의 에이전트로 같은 산출물을 동시에 만들어 서로 보강하는 방식입니다. 한쪽이 놓친 요구사항을 다른 쪽이 잡아내더군요.
참여자들은 무엇을 가져갔나
마무리 설문은 두 칸으로 받았습니다. ① “회사 가서 무엇을 응용하겠다” ② “교육팀에 바란다”. 먼저 ①을 빈도순으로 묶으면 이렇습니다.
| 갈래 | 적용 방향 | 대표 목소리(원문 발췌) |
|---|---|---|
| 하네스 + RAG 도메인 최적화 | 도메인 특화로 산출물 품질을 끌어올림 | “프롬프트·하네스·RAG로 도메인 최적화” |
| 회고 선순환 | 자료 수집 → 자가점검 → 지속 발전 | “회고를 통한 선순환 체계는 유용” |
| RFP → 제안서 lifecycle | 입찰~종료 전 과정, 요구 누락 방지 | “요구사항을 놓치지 않을 것” |
| “이용 → 활용” 전환 | 채팅에서 에이전트 생성·지식 고도화로 | “이용에서 활용으로” |
| 대시보드·측정지표 | 프로젝트/프로덕트 건강도 모니터링 | “마일스톤 기반 일정 모니터링” |
| HITL·HOTL + 보안/폐쇄망 | 루프 안 승인(HITL)·루프 위 감독(HOTL)·망분리 체득 | “보안구역 외 자료 반출 금지” |
| 내 자원으로 고품질 | 웹 의존을 줄이고 로컬 자원으로 | “처음 들어본 도구를 주력으로” |
상위 갈래가 하네스·RAG(기술 고도화)와 RFP → 제안서 lifecycle(실무 직결) 두 축으로 또렷하게 갈렸습니다. “이용 → 활용” 전환이 직접 언급됐다는 것은, 워크숍이 의도한 메시지가 참여자 언어로 정확히 반사됐다는 신호입니다.
신호는 분명했다 — 실습 더, 토큰 더, 전 직원에게
②칸(교육팀 요청)에서는 두 목소리가 압도적이었습니다.
특히 두 번째는 단순한 만족도 코멘트가 아니었습니다. “토큰 부족으로 개인 실습을 중단했다”는 운영 장애로 반복 보고됐습니다. 학습 의욕(강화학습·RAG로 더 깊이)과 인프라 제약(토큰이 막아 실습이 끊김) 사이의 갭 — 이것이 이번 회고의 가장 또렷한 신호입니다.
| 요청 | 의미 |
|---|---|
| 실습 중심 과정 정기 개설 | 일회성이 아니라 반복·난이도별 |
| 토큰/사용료 지원 | 실습 중단의 실제 원인 |
| 수강 대상 확대 | PM 외 전 직원, 본사+파견 |
| 심화/업그레이드 과정 | 이번 과정의 후속 |
| 교육 시간 연장 | 사례 제작 시간 부족 |
그런데 토큰은 따로 떨어진 변수가 아닙니다. 기업 현장에서 진짜 중요한 건 도구를 하나 더 켜는 일이 아니라, 다섯 가지를 하나로 묶는 통합입니다.
자료가 얇으면, AI도 일반론을 말한다
이틀 동안 가장 자주 되돌아온 깨달음이 있습니다. “AI가 약한 게 아니라, AI에게 줄 내 자료가 얇았다.”
이것이 앞의 곱셈식에서 RAG 인자가 의미하는 바입니다. 같은 모델, 같은 프롬프트라도 내가 쌓아 둔 도메인 지식(개인 RAG)이 연료처럼 붙어 있느냐에 따라 산출물의 깊이가 갈립니다. 연료가 없으면 “공공 사업관리”라는 일반론이 나오고, 연료가 붙으면 우리 회사의 입찰 관행과 평가 배점이 반영된 산출물이 나옵니다.
그래서 순서가 중요합니다. 도구를 켜기 전에 내 손으로 만든 S급 레퍼런스를 먼저 정리해야 합니다. 화려한 프롬프트보다, 잘 정리된 내 자료 한 폴더가 산출물의 품질을 더 크게 바꿉니다. 이것이 “사람 먼저, AI 나중”의 실무적 의미입니다.
덧붙이면, 이 하네스×RAG 방식은 제가 즉석에서 꺼낸 이론이 아닙니다. 지난 10년간 삼성·LG·SKT·신한EZ를 비롯한 여러 기업 현장에서 코치/컨설턴트로서 직접 운영하며 유용성을 검증해 온 체계이고, 이번 아이티센 워크숍도 같은 결과를 확인해 주었습니다 — 도구가 아니라 ‘통제된 하네스 + 내 자료 RAG’가 산출물의 품질을 만든다는 것. 현업에서 반복적으로 재현되는 결과라야 ‘방식’이라 부를 수 있습니다.
월요일 아침에 시작할 수 있는 것
거창한 설치가 아니라, 연료부터 모으는 일입니다.
여기까지가 앞의 L1·L2입니다. 이 두 층만 세워도, 다음에 RFP를 분석할 때 산출물의 깊이가 달라집니다.
같은 엔진을, 다른 현장에서
이 워크숍의 흐름을 자동차 SW 협업 현장에서 다시 돌려본 기록, 그리고 “연료(RAG)부터 모으는 일”의 구체적 절차를 아래 AX 시리즈에서 이어 읽어 보시기를 권합니다.
AX Series · 하네스·RAG
AX Series · 도구 온보딩
AX Series · 조직 전환
AX Series · 현장 검증