Project란 무엇인가 — 그리고 R&D Project는 왜 다른가

실무이야기 - 1

들어가며

지난 글에서 저희는 이렇게 말씀드렸습니다.

산업마다, 기업마다 프로젝트의 성격이 다르기 때문에 하나의 표준 답안이 존재할 수 없다는 이야기였습니다.

오늘은 그 말의 근거를 풀어보려고 합니다. 애초에 Project란 무엇인지, 그리고 R&D Project는 어떤 점에서 다른지를 짚어보겠습니다.

조금 원론적인 이야기로 들릴 수 있습니다. 하지만 저희가 25년간 현장에서 본 모습은 이렇습니다.

시스템 구축 자체는 대부분 무리 없이 끝납니다. 일정에 맞춰 오픈하고, 교육도 하고, 프로젝트 완료 보고도 문제없이 올라갑니다. 문제는 그 다음입니다. 운영 단계에 들어가면서 여기저기서 불편이 터져 나오고, 결국 시스템이 제대로 자리 잡지 못한 채 방치되는 경우가 적지 않습니다.

그 원인을 거슬러 올라가 보면, 상당수가 바로 이 지점을 건너뛴 데서 시작됩니다. 우리 회사의 프로젝트가 어떤 성격을 갖는지 규명하지 않은 채 시스템부터 만든 것입니다.

1. Project란 무엇인가 — PMI의 정의

프로젝트 관리 분야의 국제 표준을 만드는 PMI(Project Management Institute)는 Project를 이렇게 정의합니다.

짧은 문장이지만 핵심은 두 단어에 다 들어 있습니다.

• 한시성(Temporary) — 시작과 끝이 있습니다. 영원히 계속되는 활동은 프로젝트가 아닙니다.
• 고유성(Unique) — 이전에 했던 것과 똑같지 않습니다. 매번 같은 것을 반복한다면 그것도 프로젝트가 아닙니다.

Routine Work와 Project는 관리 방식이 다릅니다

기업의 업무는 크게 두 가지로 나뉩니다.

Routine Work(반복 업무)는 Target으로 관리합니다. 생산량, 불량률, 매출액처럼 목표 수치를 정해두고 달성 여부를 봅니다. 업무 자체는 이미 정형화되어 있으므로 "얼마나 잘했는가"만 측정하면 됩니다.

Project는 Plan과 Schedule로 관리합니다. 매번 다른 일이므로 무엇을 언제까지 어떻게 할지를 먼저 세우고, 그 계획 대비 진행 상황을 봅니다.

이 차이가 시스템 선택을 가릅니다. 재무, 회계, 생산, 품질, 재고 같은 Routine Work 영역에는 ERP, MES, SCM, WMS 같은 성숙한 패키지가 있습니다. 업무 형태가 표준화되어 있으니 검증된 패키지를 쓰는 것이 합리적입니다.

하지만 Project는 다릅니다. 그리고 Project 중에서도 R&D Project는 또 다릅니다. 왜 그런지 보려면, 프로젝트 관리라는 것이 애초에 어디서 만들어졌는지부터 봐야 합니다.

2. 프로젝트 관리는 어디서 시작되었나

지금 우리가 쓰는 프로젝트 관리 기법들은 대부분 1950~60년대에 만들어졌습니다. 그리고 그 출생지가 상당히 특정되어 있습니다.

• 1957년, 듀폰(DuPont)의 화학공장. 화학 플랜트의 정기 보수 일정을 최적화하기 위해 듀폰과 레밍턴 랜드가 공동으로 CPM(Critical Path Method, 주공정법)을 개발했습니다. 도입 첫해에 100만 달러를 절감한 것으로 알려져 있습니다.
• 1958년, 미 해군의 폴라리스(Polaris) 미사일 사업. 잠수함 발사 탄도미사일 개발에 수천 개의 협력업체가 얽히자, 미 해군 특수사업국(Special Projects Office)과 부즈 앨런 해밀턴이 PERT(Program Evaluation and Review Technique)를 만들었습니다. 각 작업에 낙관치·최빈치·비관치 세 가지 추정을 넣어 불확실성을 계산에 반영한 기법입니다.
• 1962년, 미 국방부와 NASA. 폴라리스 사업의 경험을 정리해 발간한 PERT/COST 지침에서 WBS(Work Breakdown Structure, 작업분류체계)가 공식적으로 정의되었습니다. 1968년 MIL-STD-881로 표준화되어 지금까지 이어지고 있습니다.
• 1967년, 미 국방부. 대형 방위사업의 비용 초과를 통제하기 위해 C/SCSC(비용·일정 통제 시스템 기준)가 제정되었습니다. 오늘날 EVM(Earned Value Management, 획득가치관리)의 직접적인 뿌리입니다.
• 1969년, PMI 설립. 이렇게 축적된 기법들이 하나의 전문 분야로 정리되고 표준화되어 산업 전반으로 퍼져나갔습니다.

이 프로젝트들의 공통점

목록을 다시 보시면 한 가지가 눈에 띕니다. 화학 플랜트, 미사일, 우주선, 대형 방위사업. 전부 대규모 중후장대형 프로젝트입니다.

그리고 이들에게는 결정적인 공통점이 하나 있습니다.

무엇을 만들지는 이미 정해져 있었습니다. 잠수함에서 발사되는 미사일, 정해진 사양의 화학 플랜트. 남은 문제는 오직 하나였습니다. "그것을 어떻게 정해진 기간과 예산 안에 만들어낼 것인가."

그래서 이 시기에 만들어진 도구들은 전부 그 질문에 답하도록 설계되었습니다.

• WBS — 해야 할 일을 빠짐없이 쪼개는 도구
• CPM/PERT — 쪼갠 작업들의 순서와 최단 경로를 계산하는 도구
• EVM — 계획 대비 실제 진척과 비용을 측정하는 도구
• MS-Project, P3(Primavera), Artemis — 표준화된 프로젝트 관리 툴

여기서 문제가 시작됩니다

R&D는 착수 시점에 계획을 확정할 수 없는 영역입니다.

물론 R&D도 계획을 세웁니다. 다만 그 계획은 확정된 공정표가 아니라 "이렇게 하면 될 것이다"라는 가설에 가깝습니다. 이번 실험 결과 하나에 따라 다음 단계 계획이 통째로 바뀔 수 있고, 그것이 비정상이 아니라 정상입니다. 계획이 바뀌었다는 것은 오히려 새로운 사실을 알아냈다는 뜻이니까요.

그런데 R&D 관리는 "계획은 착수 시점에 확정되는 것이며, 이후의 변경은 관리 실패다"라는 전제 위에서 만들어진 도구 일체를 그대로 물려받았습니다.

이 전제 위에서는 계획을 자주 바꾸는 연구책임자가 관리를 못 하는 사람이 되고, 계획을 안 바꾸는 사람이 관리를 잘하는 사람이 됩니다. 실제 연구의 품질과는 정반대의 신호입니다.

이것이 많은 기업의 R&D 관리가 겉도는 근본 원인입니다.

3. 수주형 Project와 R&D Project — 결정적 차이

이 차이를 가장 선명하게 보여주는 것이 수주형 Project와 R&D Project의 대비입니다.

수주형 Project — 건설, 조선, 플랜트(EPC)처럼 발주처의 요구사항이 계약서에 명시되어 있는 프로젝트입니다. 관리의 목표는 QCD, 즉 Quality(품질) · Cost(원가) · Delivery(납기)입니다. 정해진 품질과 납기를 준수하면서 원가를 최대한 낮추고 이익을 극대화하는 것입니다.

R&D Project — 관리의 목표가 QCD가 아니라 Outcome(성과)입니다. 그 Outcome은 새로운 Product이거나, Technology이거나, Service입니다. 수주형 프로젝트의 결과물이 계약의 종착점이라면, R&D의 결과물은 사업의 출발점입니다.

수주형 프로젝트에서 "계획 대비 지연"은 명백한 관리 실패입니다. 하지만 R&D에서 계획 변경은 연구가 제대로 진행되고 있다는 신호일 수도 있습니다. 새로운 사실을 알게 되었으니 경로를 수정하는 것이니까요.

같은 지표를 같은 방식으로 읽으면 안 되는 이유가 여기 있습니다.

4. R&D Project 안에서도 또 나뉩니다

여기서 한 단계 더 들어가야 합니다. "R&D Project"라고 뭉뚱그리는 순간 또 다른 문제가 생기기 때문입니다.

Research와 Development는 다릅니다

Research(연구)는 목표 자체가 탐색적입니다. "이 물질이 이런 특성을 보이는가"를 확인하는 단계이므로 결과를 예측하기 어렵고, 일정도 단정할 수 없습니다.

Development(개발)는 상대적으로 목표가 구체적입니다. 확보된 기술을 실제 제품으로 만드는 단계이므로 일정과 산출물을 어느 정도 특정할 수 있습니다.

이 둘을 하나의 양식, 하나의 진척률 기준으로 관리하면 반드시 한쪽이 왜곡됩니다. Research 과제가 "만년 지연 과제"로 분류되거나, Development 과제의 관리가 지나치게 느슨해지거나 둘 중 하나입니다.

규모에 따라서도 달라집니다

• 참여 인력과 수행 기간
• 참여자가 전담(Full Time)인가 겸임(Part Time)인가
• 전문 PM 조직(PCM)이 있는가, 연구책임자가 관리까지 겸하는가

3명이 6개월간 겸임으로 수행하는 과제와, 30명이 3년간 전담으로 수행하는 과제에 같은 관리 절차를 요구하면, 앞쪽은 시스템 입력이 연구보다 무거워집니다.

실제 기업에는 이런 유형들이 공존합니다

한 연구소 안에도 성격이 전혀 다른 프로젝트가 섞여 있습니다.

• Research — 탐색 연구
• Development — 제품·기술 개발
• Feasibility — 타당성 검토
• Outsourcing — 외부 위탁 연구
• M&A — 기술 확보를 위한 인수
• X&D — C&D(Connect & Development) 등 외부 역량과의 결합
• 여기에 고객 의뢰 과제와 국가 R&D 과제까지

이 유형들은 관리 항목도, 승인 절차도, 성과 판단 기준도 전부 다릅니다.

그래서 저희는 시스템 구축의 첫 단계를 언제나 '프로젝트 유형 구분'으로 잡습니다. 유형을 나누지 않고 하나의 틀을 강제하는 순간, 그 시스템은 어느 유형에도 맞지 않게 됩니다.

그리고 위아래로도 연결되어야 합니다

개별 과제는 홀로 존재하지 않습니다. 위로는 중장기 경영전략, TRM(기술 로드맵), PRM(제품 로드맵)과 정렬(Alignment)되어야 하고, 아래로는 세부 과제와 활동으로 이어집니다.

이 계층(Project Hierarchy)이 시스템에 반영되지 않으면, 개별 과제 관리는 되는데 "우리가 지금 전략적으로 옳은 곳에 자원을 쓰고 있는가"라는 질문에는 답할 수 없게 됩니다.

5. 정리하면, R&D Project의 속성은 이렇습니다

지금까지의 이야기를 속성으로 정리하면 다음과 같습니다.

• 결과의 불확실성 — 목표는 있으나 도달 여부와 경로를 알 수 없습니다. 실패도 유효한 결과인 거의 유일한 영역입니다. → 실패한 시도가 기록으로 남는 구조가 필요합니다.
• 목표의 점진적 구체화 — 착수 시점에 범위를 확정할 수 없고, 진행하며 구체화됩니다. → 계획 변경이 예외가 아니라 정상 절차여야 합니다.
• 비선형적 진행 — 되돌아가고 반복합니다. 선형 WBS와 진척률(EVM)이 잘 맞지 않습니다. → 단계별 의사결정(Gate) 중심의 관리가 더 유효합니다.
• 무형의 산출물 — 결과물이 지식, 데이터, 노하우, IP입니다. → 산출물 관리가 곧 지식관리여야 합니다.
• 인적 자원 의존성 — 사람이 곧 역량이라 대체 투입이 어렵습니다. → 개인에게 축적된 것을 조직 자산으로 옮기는 장치가 필요합니다.
• 유형의 혼재 — Research, Development, Feasibility, Outsourcing, M&A, X&D, 국가과제가 한 조직에 공존합니다. → 유형별로 다른 관리 절차를 수용해야 합니다.
• 포트폴리오 관점 — 개별 과제의 성패보다 전체 조합의 성과가 중요합니다. → 과제 단위를 넘어선 분석 관점이 필요합니다.
• 전략과의 정렬 — 경영전략·TRM·PRM과 연결되어야 의미가 생깁니다. → 계층 구조가 시스템에 반영되어야 합니다.

6. 그래서 관리 도구도 달라야 합니다

R&D Project를 시스템으로 관리한다고 할 때, 다뤄야 할 항목은 크게 두 층위입니다.

Project Level — 일정(Time), 연구비(Cost), 인력(Manpower), 산출물

• 일정: Gantt/Bar Chart, Milestone, Check List, Activity 계층, PERT/CPM
• 연구비: 총액(Lump Sum) 관리 / 비목별 관리 / 기간별·비목별 관리 / 회계 데이터 연동(연구 비목과 회계 비목의 대응 체계 필요)
• 인력: 참여자, 참여 기간, 참여율(Weight), 계획 대비 실적(MH·MM)
• 산출물: 보고서, 데이터, 특허, 논문, 시제품

Strategy Level — 포트폴리오·전략·로드맵

• Risk & Return 분석
• 전략·TRM(Technology Roadmap)·PRM(Product Roadmap) 계층 관리
• 포트폴리오 분석

그리고 도구는 성격에 따라 세 갈래로 나뉩니다.

• 스케줄러 (MS-Project, P3/Primavera, Artemis) — 일정 계산에 특화. 앞서 본 중후장대형 프로젝트의 직계 후손입니다.
• 관리 시스템 (PMS, PLM, KMS) — 과제·제품수명주기·지식을 통합 관리
• 기업 필수 인프라 (ERP, MIS, 그룹웨어) — 회계·인사·결재 등 연동 대상

여기서 자주 발생하는 오해가 있습니다. 프로젝트 관리 전문 툴(MS-Project, P3, Artemis 등) 스케줄러를 도입하면 R&D 관리가 된다고 생각하는 경우입니다. 스케줄러는 "정해진 작업들의 순서를 계산하는 도구"입니다. 무엇을 할지가 정해지지 않은 R&D의 앞단에서는 할 수 있는 일이 거의 없습니다.

반대로 ERP에 연구비 코드를 하나 만들어두고 R&D 관리를 한다고 여기는 경우도 있습니다. 이것은 돈의 흐름만 보는 것이지, 연구가 어디로 가고 있는지는 보지 않는 것입니다.

R&D 관리에 필요한 것은 무형의 업무, 즉 기업의 방향성을 관리하는 체계입니다. 전략과 프로젝트와 태스크가 연결되고, 그 과정에서 나온 판단과 지식이 축적되는 구조입니다. 이것은 기존 패키지가 대신해 줄 수 없는 영역입니다.

마치며

정리하겠습니다.

프로젝트 관리는 산출물이 명확한 대규모 중후장대형 프로젝트에서 태어났습니다. 그 시대의 도구들은 훌륭했고, 지금도 건설과 플랜트 영역에서는 유효합니다.

문제는 R&D가 그 전제를 공유하지 않는다는 점입니다. R&D Project는 QCD가 아니라 Outcome을 관리해야 하고, 유형이 혼재하며, 결과가 불확실하고, 산출물이 무형입니다.

그러므로 R&D 관리체계를 만드는 일은 좋은 패키지를 고르는 문제가 아니라, 우리 회사의 프로젝트가 어떤 속성을 갖는지 규명하는 문제입니다. 이것이 1편에서 말씀드린 "정답이 없다"의 실제 의미입니다.

다음 편 예고

다음 편에서는 한 걸음 더 들어가 보겠습니다.

프로젝트 관리 방법에는 그 기업의 문화가 그대로 담깁니다. 그렇다면 압축 성장을 거쳐온 국내 기업들의 R&D 관리체계에는 무엇이 담겨 있을까요. Fast Follower 시대에 최적화된 체계로 First Mover를 할 수 있을까요.

다음 글에서 이어가겠습니다.