PM·컨설턴트를 FDE로 세우는 실무 훈련 — 표준 목차를 내 프로젝트에 대 본 나흘, KT DS AX PO·PM 과정 회고

현장 검증 · KT DS AX PO·PM 과정 1차수 · 코치 회고

“AI 기반의 PMBOK, BABOK을 실제 프로젝트에 적용하기 위한 예행연습과 같아 유용했습니다.” 나흘 과정을 마치고 받은 회고의 한 줄입니다. 저는 이 문장에서 ‘예행연습’이라는 단어에 오래 머물렀습니다. 표준을 외우는 시간이 아니라, 내 프로젝트에 표준을 대 보는 시간이었다는 뜻이기 때문입니다.

FDE(Forward Deployed Engineer)는 고객 현장에 들어가 문제를 찾고, 납기를 지키고, 시스템까지 세우는 사람입니다. 우리말로는 ‘현장 배치 엔지니어’에 가깝습니다. 비즈니스 분석가(BA), 프로덕트 오너(PO), 프로젝트 매니저(PM), 파트 리더(PL)의 일을 한 사람이 오갑니다. 업계의 FDE 정의는 회사마다 조금씩 다르고, 이 글의 세 원은 이번 과정을 위한 교육용 설계안입니다.

이번 과정의 참가자는 공공·제조·그룹사·민간 고객의 사업을 맡은 PM과, 사업 기획·수주를 준비하는 경영·사업개발 담당이었습니다. 셋째 날 실습 업무 흐름에서도 컨설턴트가 고객 니즈 가설과 제안요청서(RFP) 요구 분석을 맡고, PM과 컨설턴트가 함께 변경 영향 분석과 교훈 자산화를 맡았습니다. 그래서 이 과정은 개발자를 키우는 과정이 아니라, 현장의 PM과 컨설턴트를 FDE로 세우는 실무 훈련이었습니다.

그래서 저는 FDE를 세 원이 겹치는 자리로 그립니다. 원 하나하나는 역할이고, 원마다 기준이 되는 표준이 있습니다. 두 원이 겹치는 곳에는 역할 사이를 잇는 산출물이 놓이고, 세 원이 모두 겹치는 한가운데가 FDE입니다.

과정을 설계하며 스스로 물었습니다. 네 역할의 표준을 한 사람이 다 읽을 수 있을까. 제 답은 “다 읽게 하지 말고, 목차를 자기 에이전트에 넣게 하자”였습니다. 이 글은 원 하나씩 1장 BA·PO, 2장 PM, 3장 PL로 읽고, 4장에서 한가운데의 하네스를 봅니다.

실습 재료남의 예제가 아니라 각자의 일을 들고 왔습니다

이 과정의 실습 재료는 참가자 각자가 실제로 맡은 일이었습니다. 첫날 그 일들을 받아 보니 성격이 크게 셋으로 갈렸습니다. 끝이 있는 구축·고도화는 프로젝트, 계속 도는 운영·공급 서비스는 프로덕트, 수주·착수 이전의 사업 기획은 선행입니다. 이것을 다시 고객과 사업 축으로 묶으니 프로그램 다섯 개가 나왔습니다.

표 1. 참가자 과제의 분류 — 고객사명과 사업명은 공개 수준으로 일반화했습니다.

이 표가 왜 중요한지는 셋째 날에 드러났습니다. 같은 “프로젝트 관리”라도 프로젝트는 끝나는 날을 관리하고, 프로덕트는 계속 흐르는 백로그를 관리하고, 선행은 아직 정해지지 않은 가치를 관리합니다. 한 사람이 이 셋을 동시에 들고 있는 것, 그것이 FDE형 역할로 옮겨 가는 분들의 실제 업무 모습이었습니다.

1장 · BA·PO요구에서 시작하려면 표준을 목차로 읽어야 했습니다

첫날 BABOK v3를 처음부터 읽지 않았습니다. 6장(전략 분석)과 7장(요구 분석·설계)의 소제목만 펼쳤습니다. 질문은 하나였습니다. “내 과제에 이 칸이 있습니까?” 비어 있는 칸이 곧 그날 실습할 칸이 됐습니다.

요구를 꺼내는 기법으로는 협업 게임을 썼습니다. 각자 적고, 돌아가며 말하고, 별표로 고르는 순서입니다. 말을 잘하는 한 사람이 회의를 가져가지 않게 하는 장치입니다. 둘째 날에는 FDE 4축을 BABOK 6·7·8장과 겹쳐 보았습니다.

FDE 4축은 이번 과정에서 쓴 교육용 설계안입니다. 시스템·데이터(PL), 현장 문제 발굴(PO·BA), 고위험 거버넌스와 납기(PM), 고객 현장 실행력의 네 축으로 나눴습니다. KT DS의 공식 인증 체계와는 별개이며, 이번 차수에는 성숙도 진단을 하지 않았습니다.

표 2. BA·PO 표준 대조 — 마지막 날 보드 앞에서 함께 판정했습니다(녹취 기준).

7.6이 빠진 이유는 분명합니다. 1·2·3안을 비교하지 않고 최적안 하나로 갔기 때문입니다. AI가 그럴듯한 안을 하나 내놓으면 사람은 비교를 건너뛰기 쉽습니다. 이번에는 저도 시간 안배에서 대안 비교를 충분히 챙기지 못했습니다. BABOK이 대안 비교와 추천을 별도 과업으로 두는 이유가 여기에 있다고 봅니다.

2장 · PM39칸 보드에 동그라미를 치며 기준선을 세웠습니다

프로젝트관리는 ISO 21500:2012의 프로세스 목차를 실습 점검표로 썼습니다. 회고에 나오는 프로젝트관리 지식체계(PMBOK)와 같은 영역을 다룹니다. 이 판의 프로세스는 다섯 프로세스 그룹과 열 개 주제가 만나는 39칸입니다. 현행 판은 ISO 21500:2021과 ISO 21502:2020으로 바뀌었지만, 39칸 목록은 빠진 칸을 찾는 점검표로 여전히 쓸모가 있습니다. 셋째 날부터 실습이 끝날 때마다 해당 칸에 동그라미를 쳤습니다.

다섯 단계를 합하면 39칸 중 36칸입니다. 빠진 세 칸은 원가 산정, 예산 편성, 원가 통제였습니다. 어려워서가 아니라 시간이 모자라서였습니다.

범위 실습에는 참가자들이 각자 Epic을 하나씩 세웠습니다. 데이터 플랫폼 검증, 고객센터 AI 구축, 의료 채널 통합, 교육 플랫폼, 경영계획 수립 같은 과제들입니다. 성격이 이렇게 다른 Epic을 같은 틀로 쪼개 보는 것이 이날의 목표였습니다.

틀은 동사와 명사였습니다. 해야 할 활동은 ‘분석한다·설계한다’ 같은 동사로, 남길 산출물과 백로그 항목은 ‘대시보드·매뉴얼’ 같은 명사로 적습니다. 표준의 정의라기보다 빠진 산출물을 찾기 위한 교육용 틀이고, 작업분류체계(WBS)가 산출물 중심으로 범위를 나누는 것과 같은 방향입니다. 명사 중에는 지표나 규칙처럼 보이지 않는 것도 있는데, 이것을 빠뜨리면 인수 단계에서 완료의 기준이 엇갈립니다.

일정은 두 그림으로 읽었습니다. 간트 차트는 길이와 선후를, 번다운 차트는 기울기를 보여 줍니다. 둘을 같이 봐야 “이 속도면 언제 끝나는가”가 보입니다. 기간은 플래닝 포커로 조원끼리 합의해 정했습니다.

3장 · PL코드가 아니라 문서로 AI를 조종했습니다

둘째 날 강의록의 마지막 문장은 “코드가 아니라 문서로 AI를 조종한다”였습니다. PL의 일은 시스템을 세우는 것이고, 에이전트 시대에는 그 출발점이 제품 요구사항 문서(PRD)입니다. 목적·입력·산출물을 먼저 적고 “이 문서 기준으로 만들어 줘”라고 요청하면, 이 문서가 AI에게 건네는 작업지시서가 됩니다.

둘째 날 오후 개인 실습의 첫 문장은 이것이었습니다. 오늘 만들 것은 에이전트가 아니라 대장 하나입니다. 셋째 날에는 “스킬 = 에이전트 = 프롬프트 팩”이라는 말로 이것을 넓혔습니다. 역할 카드, 규칙, 시험을 묶은 프롬프트 팩을 에이전트가 읽고 매번 같은 방식으로 일한다는 뜻입니다.

참가자들이 자기 과제로 만든 에이전트는 여섯 갈래로 모였습니다.

표 3. 참가자 에이전트 여섯 갈래 — 과제명과 이름은 적지 않았습니다.

여섯 갈래마다 함정도 하나씩 짚었습니다. 판정 에이전트는 기준선이 틀리면 틀린 것을 자동화합니다. 실행 에이전트는 권한이 걸려 있으니 읽기 전용부터 시작합니다. 보고 에이전트는 전사 합의부터 잡으면 첫 단계에서 멈추니, 개인 원장에서 시작해 팀과 전사로 넓힙니다.

마지막 날에는 조별로 RFP 갑·을 에이전트 한 쌍을 만들었습니다. 두 에이전트가 같은 평가 기준을 쓰도록 묶고, 갑·을을 바꿔 서로를 검증하게 했습니다.

가장 많이 오른 조는 7점에서 15점이 됐습니다. 다른 조의 프롬프트를 가장 많이 참고한 조이기도 했습니다. 채점에는 타당성, 관찰 가능성, 변별성, 일관성, 공정성, 비중복의 여섯 기준을 썼습니다. 점수는 단일 평가자의 교육용 점수라는 점을 함께 밝혀 둡니다.

4장 · 한 사람의 하네스네 역할을 묶은 것은 지침과 지식이었습니다

둘째 날 오전에 같은 요청을 두 번 보냈습니다. 한 번은 맥락 파일 없이, 한 번은 myDNA를 둔 폴더에서였습니다. 결과를 나란히 띄우고, 같은 모델이라도 지침이 있느냐에 따라 답의 역할·용어·순서가 어떻게 달라지는지 함께 살폈습니다.

하네스는 모델을 바꾸지 않습니다. 모델에 건네는 지침과 지식을 바꿉니다. 지침은 myDNA라는 마크다운 파일에 역할·규칙·용어·답하는 순서를 적은 것이고, 지식은 검색 증강 생성(RAG)으로 붙이는 내 문서입니다.

RAG는 둘째 날 로컬 노트 그래프로 가장 작게 시작했습니다. 넷째 날에는 표준 요약을 RAG로 얹어 myDNA와 연결했습니다. 목표는 답마다 표준 근거가 따라붙게 하는 것이었습니다. FDE가 네 역할의 표준을 다 외우지 않아도 되게 하자는 것이 이 구성의 의도입니다. 실제로 얼마나 작동하는지는 아직 사례 수준으로만 확인했습니다.

표 4. 4일 회고 12건 — 한 응답이 여러 묶음에 들어갈 수 있어 합계가 12를 넘습니다. 묶음 분류는 코치의 해석이며, 회고를 쓰지 않은 분의 의견은 담기지 않았습니다.

둘째 날 회고는 주로 ‘실습’을 말했고, 넷째 날 회고는 ‘실무에 잇는 법’을 말했습니다. 셋째·넷째 날 실습을 각자의 과제로 돌린 결과로 봅니다. 아쉬움도 분명했습니다.

강의 속도가 빨랐다는 지적, PM 사전 지식이 부족해 내재화가 어려웠다는 지적이 있었습니다. 대규모 언어 모델(LLM) 사용법부터 배우고 싶었다는 의견도 있었습니다. 둘째 날의 아쉬움은 ‘더 보고 싶었다’였는데, 넷째 날에는 ‘사전 지식’으로 옮겨 갔습니다.

반례보고 지표 10건에 건강도는 아직 없었습니다

넷째 날 시트에 경영진이 즐겨 보는 보고 지표를 적는 칸을 두었습니다. 돌아온 답은 진척·진도율, 리스크·이슈, 매출·이익이 대부분이었습니다. 질문이 경영진의 선호를 물었으니 참가자 본인의 보고 관행을 그대로 보여 주는 값은 아니고, 응답도 10건이라 넓게 일반화하기는 이릅니다.

표 5. 참가자가 적은 보고 지표 10건 — 한 응답이 여러 묶음에 들어갑니다.

저는 나흘 동안 “진도율이 아니라 건강도”를 여러 번 말했습니다. 보고서의 칸까지 바꾸려면 강의 밖의 장치가 필요했습니다. 개념을 이해하는 것과 조직의 보고 양식이 바뀌는 것은 다른 속도로 움직이기 때문입니다. FDE 관점으로 말하면, PM 장의 훈련을 PO의 가치 언어로 잇는 다리가 다음 과제입니다. 건강도는 예를 들어 수용 기준이 붙은 요구의 비율, 출처가 있는 요구의 비율, 기준선 대비 편차처럼 잴 수 있습니다. 이 지표들은 교육용 설계안이며 아직 검증하지 않았습니다.

정리표준 × AI 리터러시가 네 역할에 남긴 것

이 과정이 노린 것은 하나였습니다. 실무자가 글로벌 표준을 자로 삼고 AI 리터러시를 손에 쥐어, 자기 역량과 맡은 프로젝트의 건강도를 스스로 잴 수 있게 하는 것입니다. 역할마다 무엇이 남았는지 정리합니다.

표 6. 코치가 정리한 과정 인사이트 — 참가자 회고와 강의록에서 반복된 것만 남겼습니다.

앞으로다음 차수와 그 너머의 발전 방향

다음 차수에서 바꿀 것은 세 가지입니다. 참가자가 쓴 보고 지표를 받아 “건강도·예측도로 바꿔 줘”를 한 번 더 돌립니다. 원가 기준선 실습 30분을 넣습니다. 첫날 오전에는 대규모 언어 모델 사용 기초를 짧게 둡니다.

그 너머로는 성숙도를 재는 기준선을 제안합니다. FDE 4축 자기 진단에 아래 다섯 단계를 붙여 과정 시작과 끝에 같은 질문으로 재는 것입니다. 그래야 차수 사이에 무엇이 자랐는지 말할 수 있습니다.

제 해석으로는 이번 차수가 대체로 셋째 단계까지 실습했습니다. 넷째 단계 ‘측정’은 보고 지표 응답에 건강도가 아직 없었던 것처럼 다음 과제로 남았습니다. 이 사다리는 아직 측정하지 않은 설계안이라는 점을 함께 밝혀 둡니다.

또 하나는 갑·을 에이전트 키트를 각자의 현업 RFP로 옮겨 과정이 끝난 뒤에도 돌려 보는 것입니다. 라운드 3을 강의장이 아니라 내 책상에서 하는 셈입니다.

닫으며여러분의 프로젝트 하나로 오늘 시작할 수 있습니다

혼자서도 시작할 수 있습니다. 준비물은 세 가지입니다. 진행 중인 과제 하나의 문서, 점검할 표준 목차를 한 쪽으로 적은 메모, 파일을 첨부하거나 폴더를 읽을 수 있는 AI 도구입니다. 사내 문서는 회사가 허용한 도구에서만 쓰십시오. 아래 프롬프트를 보내면 ‘빠진 칸 표’ 한 장이 나옵니다.

[역할] 당신은 BA·PO·PM·PL 네 역할을 함께 보는 프로젝트 코치입니다.
[자료] 이 폴더의 과제 문서와 함께 넣은 표준 목차 메모(BABOK v3 6~7장, ISO 21500:2012 기획 프로세스)만 근거로 씁니다. 먼저 읽은 파일 목록을 보고하고, 추측으로 칸을 채우지 않습니다.
[할 일] 목차 항목마다 이 과제에 적용되는지 먼저 판단하고, 적용되는 항목은 근거 문서가 있는지 점검합니다. PL 관점에서는 요구사항 문서(PRD)와 검증 기준이 있는지도 봅니다.
[출력] 항목마다 「적용 안 됨 · 있음 · 없음 · [U] 근거 미확인」과 근거 문서·위치를 표 한 장으로 정리합니다.
[마무리] '없음'은 작성·보완할 일, [U]는 다른 곳에 근거가 있는지 확인할 일로 나누고, 이번 주에 먼저 할 세 가지를 이유와 함께 고릅니다.

‘없음’은 다음 주에 채울 일이고, [U]는 그보다 먼저 근거가 어디 있는지 확인할 일입니다.

다음 읽을 글