기준 문서를 내 업무로 다시 쓰자 비서가 우리 일의 말로 답했습니다 — FITI시험연구원 관리자 AX 워크숍, 같은 대본으로 달린 두 번의 하루

현장 검증 · FITI시험연구원 관리자 AX 워크숍 · 코치 회고

AI 비서가 우리 부서의 말로 답하게 만든 것은 새 도구가 아니라, 내 업무로 다시 쓴 기준 문서 한 장이었습니다. “방법론 하나를 찾은것 같음.” 첫 회차 회고에서 이 짧은 문장에 오래 머물렀습니다. 하루짜리 과정에서 도구가 아니라 일하는 방법을 가져갔다는 뜻이기 때문입니다.

기관 소개에 따르면 FITI시험연구원은 한국인정기구(KOLAS)의 제1호 국제공인시험기관입니다. 사업은 시험·검사, 인증, 연구개발, 교육으로 나뉩니다. 이번 과정은 부서장과 관리자를 위한 하루짜리 AX(AI 전환) 워크숍이었고, 같은 대본을 본원과 분원에서 한 번씩 진행했습니다. 두 회차는 참가자가 서로 달랐으므로 한 팀의 첫날·둘째 날이 아닙니다. 그래서 저는 이 과정을 ‘첫 회차의 회고로 둘째 회차를 고치는 하루’로 운영했습니다.

위의 네 막은 둘째 회차 강의록의 모듈 열두 개를 묶은 하루 지도입니다.

하루의 공식일머리 세 가지는 표준에서 온 말이었습니다

오전 첫머리에 적은 공식은 ‘Agility = 일머리 × AI’였습니다. AI만 배우면 된다는 기대를 먼저 내려놓자는 뜻입니다. 일머리에는 세 가지 기본기를 두었습니다. 베이스라인, 대시보드, 선순환입니다.

이 세 단어는 제가 PM 교육에서 쓰는 PMBOK 6판의 개념을 일상 언어로 옮긴 것입니다.

표 1. 일머리 세 기본기와 PMBOK 개념의 대응 — 대응은 교육용 정리입니다.

AI 쪽은 지능과 기억 두 가지였습니다.

지능은 판단의 기준을 적은 문서이고, 기억은 결과물이 쌓이는 폴더입니다. 폴더에 쌓인 자료를 근거로 답하게 하는 방식은 검색 증강 생성(RAG)의 가장 가벼운 형태입니다. 다음 작업에서도 최신 기준 문서와 필요한 업무 자료를 참조하도록 설정해 두면, 쓸수록 내 업무에 맞춰집니다.

오전결과물보다 지시서를 먼저 다듬었습니다

오전은 문법을 심는 시간이었습니다. 처음에는 한 줄 프롬프트로 시계 화면을 만들고, 결과를 보며 고쳐 달라고 주고받았습니다. 이것이 바이브 코딩입니다. 다음에는 결과물 대신 작업 지시서를 먼저 쓰게 하고, 지시서를 다듬은 뒤 한 번에 수행시켰습니다. 저는 이것을 바이브 매니징이라고 부릅니다.

AI가 끌어온 규격의 이름과 번호는 원문과 대조하기 전까지 초안입니다. 관리자에게 이 구분은 낯설지 않았습니다. 성적서를 내기 전에 검토하고 서명하는 일이 이미 매일의 업무이기 때문입니다.

오후강사가 만든 기준 문서를 내 업무 파일로 다시 썼습니다

오후는 지능을 만드는 시간이었습니다. 먼저 아무것도 깔지 않은 상태에서 “내 부서의 업무 온톨로지 맵을 그려 줘”라고 물었습니다. 못 맞히는 상태를 먼저 보여 주기 위해서입니다. 그다음 제가 기관의 공개 자료로 만든 기준 문서 myDNA를 깔고 같은 질문을 다시 했습니다.

첫 회차에서는 여기서 신호가 왔습니다. “너무 크다”, “우리 업무와 안 맞는다”는 반응이었습니다. 공개 자료로 만든 기준 문서는 기관 전체를 넓게 훑기 때문에 부서의 일과는 거리가 있었습니다. 저는 그 자리에서 순서를 바꿔, 각자의 업무 파일로 기준 문서를 다시 쓰는 20분을 먼저 넣었습니다.

마지막 확인이 검증 단계입니다. 파일을 넣었다고 들어간 것이 아니라, 요약이 내 업무의 말로 읽혀야 들어간 것입니다. 같은 질문을 지능 없이 한 번, 강사의 기준 문서로 한 번, 내 기준 문서로 한 번 던져 결과를 나란히 놓았습니다.

실제 답변은 참가자의 업무 자료라 싣지 않고, 화면에서 판정한 기준만 옮겼습니다.

둘째 회차에서는 이 20분을 처음부터 정규 순서로 넣고, 강사의 기준 문서를 ‘초안’으로 소개했습니다. 전후를 비교하는 질문도 기관 내부의 약어와 규칙을 알아야 답할 수 있는 것으로 바꿨습니다. 첫 회차에서 뚜렷하지 않던 전후 차이가 둘째 회차에서는 화면에서 보였습니다.

사람이 확정하는 자리시험·인증의 신뢰는 여덟 곳에서 나옵니다

기준 문서에 가장 먼저 적게 한 것은 할 일이 아니라 사람이 확정할 자리였습니다. 시험·인증 기관에서는 누가 판정하고 서명했는지가 성적서의 신뢰를 이룹니다. 그래서 기준 문서에 사람이 확정하는 여덟 지점을 적었습니다.

표 2. 기준 문서에 적은 사람 확정 지점 — 교육용 기준 문서의 정리이며, 실제 적용은 기관의 품질문서가 정본입니다. 다른 업종이라면 우리 조직의 서명·승인·판정 지점으로 바꿔 씁니다.

이 가운데 측정불확도, 부적합 업무, 불만 처리는 시험기관 인정 표준이 요구하는 활동입니다. 시험·교정기관의 인정 표준은 ISO/IEC 17025:2017입니다. AI가 못 해서가 아니라 사람이 책임져야 해서 사람의 자리입니다.

둘째 회차 뒤에 참가자들의 요구를 설계서로 옮기면서, 이 원칙을 코드·AI·사람의 역할 분담으로 다시 정리했습니다.

표 3. 코드·AI·사람의 경계 — 설계서 검토에서 정리한 원칙입니다.

한 줄로 줄이면 이렇습니다. 숫자와 상태는 코드가 계산하고, AI는 근거 안에서 설명하며, 책임 있는 사람이 결정합니다.

두 번의 하루첫 회차의 회고로 둘째 회차를 고쳤습니다

첫 회차 회고 20건의 좋았던 점은 일곱 갈래였습니다.

표 4. 첫 회차 회고의 좋았던 점 — 한 응답이 여러 갈래에 들어갈 수 있습니다.

아쉬움도 분명했습니다. 업무 파일을 미리 준비하라는 안내가 없었고, 실습 중 도구 사용량이 바닥난 경우가 있었고, 하루가 짧았습니다. 둘째 회차에 바로 고쳤습니다.

표 5. 첫 회차의 아쉬움과 둘째 회차의 보정 — 회고 문항이 회차마다 같지 않아 엄밀한 비교가 아니라 관측입니다.

오전과 오후에 깔아 둔 개념은 참가자의 적용 계획 문장으로 되돌아왔습니다.

표 6. 개념이 참가자의 문장으로 돌아온 지점 — 오른쪽 열은 첫 회차 회고·적용 계획 원문의 일부입니다.

러닝 시계로 설명한 예측이 시험 접수 업무의 말로 번역되어 돌아왔습니다. 저는 이 문장을 그날 설계가 현장에 닿은 가장 분명한 신호로 읽었습니다.

적용 계획에서는 집계·대시보드를 하겠다는 응답이 가장 많았습니다. 그날의 마지막 실습이 대시보드였습니다. 마지막 실습의 영향일 수 있다고 해석했습니다. 그래서 둘째 회차에서는 대조·검증 실습을 앞쪽으로 옮겼고, 이 순서 변경은 저의 설계 판단입니다.

요구에서 설계서로설계서 21건을 묶어 보니 공통 바닥 다섯 개로 모였습니다

둘째 회차에서는 시트에 질문을 하나 더 넣었습니다. “나에게 myAgent가 어떤 역할을 수행하면 내가 진짜 편해지겠다”입니다. 요구가 18건, 회고가 12건, 적용 선언이 6건 걷혔습니다. 소감보다 요구가 더 잘 걷혔고, 걷힌 문장은 그대로 설계서의 씨앗이 됐습니다.

표의 구분은 반복해 쓰는 제품형(프로덕트), 여러 사업을 묶어 보는 관리형(프로그램), 한 번의 실험(프로젝트), 개인 업무로 나눴습니다.

표 7. 둘째 회차 요구 18건의 분류 — 지역·사이트 주소는 빼고 업무를 일반화했으며, 구분은 코치의 정리입니다.

과정이 끝난 다음 날 개인 에이전트 설계서 21건을 만들었습니다. 요구 18건에, 요구 칸을 비운 두 분의 초안 2건과 강사의 모범 예시 1건을 더한 것입니다. 설계서마다 요구 원문, 만드는 순서, 사람이 확정할 지점, 하지 않을 범위를 적었습니다. 처리 결과는 “N건 중 M건 처리, K건 미매핑”으로 보고하게 했습니다. 틀린 채로 조용히 계속 도는 자동화를 막기 위해서입니다.

표 8. 설계서 21건의 투자 판정 — 교육·자가 개발 착수용 판정이며 운영 배포 승인이 아닙니다.

보류 2건은 실패가 아니라 원칙입니다. 문제의 주인이 없는 요구는 아무리 잘 만들어도 다른 사람의 문제를 자동화하게 됩니다.

설계서 21건을 검토해 보니 같은 바닥이 반복됐습니다. 그래서 21개를 따로 만들지 않고 다섯 개의 공통 제품군 위에 개인 비서를 얹는 구조를 권했습니다. 설계 단계의 판단이며, 이 구조가 충분한지는 제한 파일럿 뒤에 확인할 일입니다.

회고관리자들은 방향과 방법을 가져갔습니다

둘째 회차 회고 12건의 좋았던 점은 세 갈래로 모였습니다.

한 응답이 여러 갈래에 들어갈 수 있고, 미응답자의 의견은 담기지 않았습니다.

더 원한 것도 함께 적혔습니다. 실습 시간이 짧다는 의견이 2건, 계정이 바뀌어도 학습이 이어지기를 바라는 의견이 1건, 부서별 니즈를 파악한 심화 교육 제안이 1건이었습니다. 저는 이것을 다음 과정의 설계 요청서로 읽었습니다.

관리자의 자리에서 나온 적용 계획도 눈에 띄었습니다. 자기 업무를 넘어 직원과 조직으로 넓히겠다는 문장입니다.

정리표준 × AI 리터러시가 관리자에게 남긴 것

이 과정의 목표는 하나였습니다. 관리자가 PMBOK과 시험기관 인정 표준을 자로 삼고, AI 리터러시로 자기 역량과 부서 업무의 건강도를 스스로 점검하게 하는 것입니다. 두 번의 하루를 그 틀로 다시 읽으면 이렇습니다.

표 9. 코치가 정리한 과정 인사이트 — 두 회차의 실습·회고와 둘째 회차 뒤의 설계 검토를 층위별로 묶었습니다. 에이전트 행은 둘째 회차만의 관측입니다.

앞으로내 기준 문서를 매일 키우는 길

하루에서 가져간 것을 현업에서 이어 가는 길은 내 파일에서 시작해 부서의 공통 바닥으로 넓어집니다.

과정의 발전 방향은 세 가지입니다. 첫째, 참가자가 직접 제안한 부서별 심화 과정을 설계합니다. 둘째, 실습 계정이 정리된 뒤에도 학습이 이어지도록 개인 환경으로 옮기는 절차를 커리큘럼 안에 넣습니다. 셋째, 설계서마다 현재 처리 시간·오류·재작업의 4주 기준선을 먼저 재고, 제한 파일럿으로 효과를 계측합니다.

닫으며여러분의 업무 파일로 기준 문서 한 장을 써 보는 것으로 시작할 수 있습니다

두 번의 하루에서 제가 가장 크게 배운 것이 있습니다. 관리자의 AI 리터러시는 도구를 다루는 능력보다 자기 일을 기준 문서로 적는 능력에 가깝다는 것입니다.

혼자서도 시작할 수 있습니다. 준비물은 두 가지입니다. 규정·업무 문서 같은 내 업무 파일 10~20개, 그리고 파일을 첨부하거나 폴더를 읽을 수 있는 사내 허용 AI 도구입니다. 고객 정보는 가리고 씁니다. 워크숍에서는 이 다시 쓰기에 20분을 썼습니다.

보내기 전에 한 칸은 직접 적습니다. 우리 부서에서 사람이 확정하는 자리 3~8개입니다. 이 자리를 AI가 파일에서 추정하게 두지 않기 위해서입니다. 아래 프롬프트를 보내면 ‘우리 부서 기준 문서’ 초안 한 장이 나옵니다.

[역할] 당신은 우리 부서의 업무를 돕는 AI 비서입니다. 판단은 사람이 하고, 당신은 근거가 붙은 초안을 만듭니다.
[내가 먼저 적은 칸] 우리 부서에서 사람이 확정하는 지점: ___ (3~8개)
[자료] 이 폴더에 넣은 내 업무 파일만 근거로 씁니다. 먼저 읽은 파일과 읽지 못한 파일을 목록으로 보고합니다.
[할 일] 파일을 종합해 '우리 부서 기준 문서' 초안을 만듭니다. ① 업무의 목적과 고객 ② 일이 흐르는 순서 ③ 자주 쓰는 용어와 약어를 담습니다. ④ 내가 적은 확정 지점별 근거 ⑤ AI가 하지 말아야 할 일 ⑥ 코드·AI·사람이 나눠 맡을 일도 담습니다.
[출력] 한 장 분량으로 정리하고, 항목마다 근거 파일 이름을 적습니다.
[확인] 마지막에 이 기준 문서를 세 줄로 요약합니다. 근거가 없는 칸은 [U]로 남기고 지어내지 않습니다. 확정 지점은 바꾸지 않고, 빠진 것 같은 지점은 후보로만 제안합니다.

받은 초안은 두 가지로 확인합니다. 먼저 같은 질문을 지능 없이 한 번, 이 기준 문서로 한 번 던져 답이 우리 부서의 말로 달라지는지 봅니다. 다음으로 ④·⑤와 [U]를 동료와 함께 현행 품질문서의 해당 조항에 대조합니다. 확정권자와 승인 범위가 확인되지 않은 항목은 [U]로 둡니다.

다음 읽을 글