방법론은 왜 그렇게 생겼는가 (01/10)

AI 시대의 프로젝트 방법론 · Ep.01

절차는 남았다.
이유는 잊혔다.

방법론은 왜 그렇게 생겼는가 · HFC Consulting

---

방법론 표준 개정 회의. 입사 3년 차 개발자가 손을 든다. "AI로 반나절이면 만드는 화면인데, 설계서 승인에는 왜 일주일이 걸립니까?" 회의실이 조용해진다. PM은 "표준이니까"라고 답하고 싶은 것을 참는다. 그 표준이 왜 그렇게 정해졌는지, 이 회의실에서 정확히 설명할 수 있는 사람이 없기 때문이다. 절차는 20년을 살아남았는데, 절차의 이유는 잊혔다.

방법론을 재검토하려면 순서가 있다. 무엇을 바꿀지 묻기 전에, 그것이 왜 그렇게 생겼는지를 먼저 물어야 한다. 이유를 모르고 바꾸면 버려야 할 것을 지키고, 지켜야 할 것을 버리게 된다. 이 연재 전체가 그 순서를 따른다.

전제 — 방법론이 서 있던 세 개의 기둥

우리가 아는 프로젝트 방법론 — 정교한 계획, 단계별 게이트, 문서 승인 절차 — 는 임의로 생긴 것이 아니다. 특정한 경제적 전제 위에 설계된 합리적 장치였다.

시대의 전제	그래서 생긴 장치	AI 이후의 균열
만드는 것이 비싸다 (인력 희소)	착수 전 정교한 계획과 산정 — 잘못 만들면 손실이 크므로	생성 비용 급락 — 만들어 보고 판단하는 것이 더 쌀 수 있음
생산이 느리고 순차적이다	단계별 게이트와 승인 — 다음 공정 착수 전 확정이 경제적이므로	생산 구간만 압축 — 게이트가 병목의 새 주소가 됨
의도는 문서로 전달된다	설계서·승인 문서 체계 — 사람 사이의 유일한 전달 수단이므로	의도가 프롬프트로 직행 — 문서를 거치지 않는 경로가 생김

세 번째 열이 1기 연재에서 진단했던 현상들의 뿌리다. 일정표가 안 줄어드는 것도, 산출물이 사라지는 것도, 검수 기준이 무너지는 것도 — 개별 사건이 아니라 전제의 균열이라는 하나의 지각 변동이다.

존속 — 그러나 방법론의 목적은 깨지지 않았다

여기서 성급한 결론을 경계해야 한다. "전제가 깨졌으니 방법론을 버리자"는 주장은, 방법론의 수단과 목적을 혼동한 것이다. 방법론의 목적은 계획서나 게이트가 아니다. 불확실성 속에서 여러 사람의 작업을 약속된 품질로 수렴시키는 것이다. 그 목적을 지탱하는 네 가지 — 책임의 소재, 검증의 관문, 요구의 합의, 판단의 기록 — 는 AI가 아무것도 깨뜨리지 않았다. 오히려 2기(계약)와 3기(거버넌스)에서 봤듯, AI 시대에 더 무거워졌다.

그러므로 재검토의 질문은 "버릴 것인가"가 아니다. "이 절차는 목적을 지키는 장치인가, 옛 전제의 화석인가"이다. 절차마다 답이 다르고, 그 판별이 이 연재가 하려는 일이다.

재구성 — 이 연재의 판별 프레임

① 전제 — 이 방법은 어떤 전제 위에 설계되었는가

② 균열 — AI가 그 전제 중 무엇을 깨뜨렸는가

③ 존속 — 무엇은 여전히 유효한가 (버릴 것과 지킬 것의 구분)

④ 재구성 — 그래서 AI 시대에는 어떻게 실행하는가

앞으로 아홉 편, 관리방법론 네 영역과 개발방법론 네 계보를 이 프레임으로 통과시킨다. 매회 AI 이전과 이후를 나란히 놓은 비교표가 함께 간다.

이 연재의 지도

회차	주제 (클릭하면 이동)	비교 대상
02	관리 ① 범위·일정	WBS·간트 vs 압축 시대의 일정 설계
03	관리 ② 품질·리스크	단계말 게이트 vs 상시 자동 검증
04	관리 ③ 의사소통·보고	주간보고 vs 실시간 대시보드
05	관리 ④ 변경·형상	변경통제위원회 vs 확장 속도의 통제
06	개발 ① Waterfall의 재평가	누명과 실제 한계의 구분
07	개발 ② Agile은 살아남는가	스프린트·의식(儀式)별 존속 판정
08	개발 ③ DevOps와 파이프라인	CI/CD vs AI 생성 코드 시대의 게이트
09	개발 ④ AI 네이티브 개발	코드 중심 vs 스펙·Agent 협업 구조
10	하이브리드 설계 원칙 (완결)	단일 방법론 vs 사업 특성별 조합 매트릭스

방법론은 시대의 경제학이 절차의 형태로 굳은 것이다. 경제가 바뀌면 절차도 다시 물어야 한다. 묻지 않는 조직은 두 종류다 — 화석을 지키느라 느려지거나, 목적까지 버려서 무너지거나. 다음 편부터 하나씩 묻는다. 시작은 모든 계획의 뼈대, WBS와 일정이다.

※ 본 연재의 비교·재구성 원칙은 일반적 참고용이며, 조직의 표준과 사업 특성에 맞는 조정이 필요합니다.

📎 더 읽을거리
· Royce, "Managing the Development of Large Software Systems" (1970, PDF) — 폭포수 모델의 기원이 된 원논문
· PMBOK Guide (PMI) — 관리방법론의 국제 표준 지식체계

HFC Consulting의 관점

조직의 방법론 표준이 어느 전제 위에 서 있는지 함께 진단해 드립니다. 현재 쓰시는 표준 절차의 목차만 보내 주셔도, 화석이 된 절차와 지켜야 할 절차를 구분해 드리겠습니다.

✉ changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

---

📚 연재 · AI 시대의 프로젝트 방법론
다음 편 ▶ (02/10) 관리 ① 범위·일정: WBS는 살아남는가
이전 연재 AI 거버넌스 구축 가이드 · 발주자를 위한 AI 계약 가이드 · AI시대의 사업관리
연재 전체 보기 →