WBS는 프로젝트, FBS는 제품 — 셋톱박스 제조사가 표준 4개(PMBOK·SEBOK·SWEBOK·CMMI)를 codeBeamer 하나에 녹여 전사 ALM을 정착시킨 방법

PM 컨설턴트 노트 · 휴맥스 전사 ALM 정착 백서

2016년, 휴맥스(HUMAX)는 200개가 넘는 제품 프로젝트가 동시에 도는 셋톱박스·브로드밴드 CPE 제조사였습니다. 문제는 ‘추적성(Traceability)’을 관리자 보고용 서류로 오해한다는 것이었습니다. 프로젝트리서치는 그 인식을 뒤집었습니다 — 요구사항에서 자산화까지 개발 공정 전체를 꿰는 뼈대로. 프로젝트관리 표준(PMBOK)·시스템공학(SEBOK)·소프트웨어공학(SWEBOK)·프로세스 성숙도(CMMI) 네 표준을 ALM 도구(codeBeamer) 하나의 이원축에 접어 넣어, 전사가 같은 뼈대로 개발하게 만든 기록입니다. 한 PM 컨설턴트의 시선으로 정리한 현장 백서입니다.

제조업의 제품개발에는 세 가지가 동시에 흐릅니다 — 하드웨어(HW), 소프트웨어(SW), 그리고 양산 공정. 이 셋이 각자의 관리 도구·엑셀·메일로 흩어지면, “이 요구사항이 지금 어느 단계에 있고, 검증은 됐는가”를 아무도 한눈에 답하지 못합니다. 휴맥스의 과제는 바로 그 흩어진 실을 하나의 도구 안에서 다시 엮는 일이었습니다. 그리고 그 실을 엮는 규칙이, 오래된 네 개의 공학 표준이었습니다.

Background‘관리자 보고용’이라는 오해, 그리고 현장의 네 가지 문제

200개가 넘는 제품 프로젝트가 동시에 도는 조직에서, 프로젝트리서치가 처음 진단한 현장의 문제는 네 가지였습니다. 이건 ‘도구가 없어서’가 아니라 ‘일하는 방식의 기준선(Baseline)이 없어서’ 생긴 문제였습니다.

여기에 결정적인 인식 문제가 하나 더 얹혀 있었습니다 — “추적성은 관리자 보고용”이라는 오해입니다. 추적성이 위로 보고하기 위한 서류라고 여기면, 현장 엔지니어에게는 부담스러운 잡무일 뿐입니다. 이 오해를 깨는 것이 프로젝트 전체의 성패였습니다. 그래서 우리는 추적성을 다르게 프레이밍했습니다 — 관리자를 위한 서류가 아니라, 개발자 자신을 위한 시스템공학(SE) 표준이라고.

The Formula승리 공식 — WBS는 프로젝트, FBS는 제품

승리 공식은 한 문장이었습니다. “WBS는 프로젝트, FBS는 제품.” 프로젝트관리와 제품개발을 하나의 도구 안에서 두 개의 축으로 분리하고, 그 위에 요구추적을 자동화한다는 뜻입니다.

왜 이렇게 나눴을까요. 두 축이 뒤섞이면 PM은 일정만 쫓다가 품질을 놓치고, 팀은 형상만 파다가 고객 약속을 잊습니다. 그래서 보는 리듬까지 분리했습니다.

Four Standards, One Tool표준 네 개를 도구 하나에 접어 넣다

이 프로젝트의 지적 뼈대는 오래된 공학 표준 네 개였습니다. 원래 제안서에는 PMI(프로젝트관리)·CMMI(프로세스)·SAFe 4.0·NASA 시스템공학 핸드북이 인용됐는데, 이를 오늘의 정본 표준체계(BOK, Body of Knowledge)로 정리하면 다음의 네 축이 됩니다. 각 표준은 다른 질문을 담당합니다.

핵심은 이 네 표준을 강의로 가르치고 끝내지 않았다는 점입니다. 각 표준의 산출물이 codeBeamer의 트래커(Tracker) 하나하나로 대응되게 만들어, 표준이 ‘지식’이 아니라 ‘도구를 쓰는 순간의 규칙’이 되게 했습니다. PM이 릴리스를 걸면 PMBOK이 작동하고, 팀이 요구를 분해하면 SEBOK이, 커밋을 올리면 SWEBOK이, 통계가 쌓이면 CMMI가 작동합니다.

Traceability요구추적 8단계 — 비즈니스에서 자산화까지, 하나의 실

이원축과 네 표준이 실제로 맞물리는 곳이 바로 요구추적 8단계입니다. 사용자가 요청한 흐름 — 비즈니스 → 요구스펙 정의 → 관리 WBS와 개발 PBS의 구분 → 테스트케이스 재사용 → 전체 개발 공정의 검증·확인(V&V) 추적성 — 이 여덟 단계 위에 그대로 얹힙니다. 각 단계 오른쪽의 태그는 그 단계를 담당하는 표준을 표시합니다.

➊~➑ 요구추적 8단계. 여기에 교훈(P)·역량(S)·헬스체크(M) 부가 축이 얹혀, 프로젝트가 끝나도 배움이 남습니다.

이 여덟 단계를 관통하는 것이 V&V(검증·확인) 추적성입니다. 하나의 요구를 클릭하면 “어느 명세에서 나왔고 → 어느 모듈로 분해됐고 → 어느 릴리스에 실렸고 → 어느 테스트케이스로 설계·수행됐고 → 어느 결함이 걸렸고 → 어느 자산으로 남았나”가 한 줄로 펼쳐집니다. 이것이 엑셀 추적표와 ALM의 결정적 차이입니다 — 엑셀은 ‘찍어둔 사진’이고, ALM은 ‘살아 있는 연결’입니다.

형상관리까지 하나로 — HW·SW·품질의 세 갈래 SCM

제조업이라 형상관리(Configuration Management)도 세 갈래였습니다. 이 세 갈래를 각자의 도구에 두되 ALM이 참조로 묶어, 요구추적이 형상까지 도달하게 했습니다.

Reusability재사용성과 추적성 — 55%가 ‘파생’이라는 데이터

재사용성을 강조하는 것은 ‘좋은 말’이 아니라 데이터에 근거한 전략이었습니다. 휴맥스 제품 구조를 분석하니, 신규 개발은 45%뿐이고 55%(226건)가 기존 제품의 파생이었습니다. 셋톱박스·CPE는 통신사·지역·규격별로 변형이 쏟아지는 산업이라, 매번 백지에서 시작하지 않습니다.

이 데이터가 FBS와 자산 라이브러리(➑)를 정당화합니다. 파생이 절반이 넘는다면, 승부는 “기존 모듈·테스트케이스를 얼마나 깔끔하게 재사용하느냐”에서 갈립니다. 그래서 codeBeamer의 두 가지 재사용 지표를 대시보드로 상시 노출했습니다.

재사용성과 추적성은 사실 같은 동전의 양면입니다. 추적성이 있어야(“이 모듈이 어느 요구에서 나와 어느 테스트로 검증됐나”) 안심하고 재사용할 수 있고, 재사용이 쌓여야 추적의 가치가 복리로 커집니다. 이 선순환이 ALM 정착의 진짜 인센티브였습니다 — 보고를 위해서가 아니라, 내 다음 프로젝트를 편하게 하려고 쓰게 되는 것.

Tool Selection무엇을 사고 무엇을 포기했나 — V모델 게이트와 ALM vs Jira/Redmine

제품개발의 관문(Phase/Gate)은 NASA 시스템공학 핸드북의 V모델을 기반으로 3개 스테이지로 세웠습니다. 앞단(설계·실현)은 반복(Iterative), 양산은 순차(Waterfall)로 — 이 혼합이 제조업의 현실입니다.

각 스테이지에 ALM 릴리스 마일스톤(Lev1/Lev2)이 걸리고, 요구추적 레벨이 세 스테이지를 관통합니다. 엔지니어링 샘플→설계검증→제품확인→양산의 게이트로 이어집니다.

도구 선정에서 흔한 함정은 “우리 도구가 다 좋다”는 과장입니다. 우리는 반대로 했습니다 — 여덟 개 축으로 정직하게 비교하고, 마지막 축(‘사용성’)에서 ALM이 진다는 것을 숨기지 않았습니다.

Adoption도구가 아니라 거버넌스 — 전사 정착 3종 세트

2016년 8월 전사확대 시점, 조기 안정화를 위해 세 가지 장치를 동시에 걸었습니다. 표어는 단호했습니다 — “ALM 사용 여부는 협의 대상이 아니라 의무다.”

여기에 저항을 줄이는 유예 규칙을 붙인 것이 현명했습니다. 2개월 안에 끝나는 프로젝트는 유예하고, 8월 이후 새로 시작해 3개월 이상 남은 프로젝트만 필수 적용했습니다. 곧 끝날 프로젝트에까지 도구를 강요하지 않아, “왜 지금 이걸”이라는 반발을 미리 눌렀습니다.

Change Management도구로 안 풀리는 문제 — PM 권한 부재와 역할 재정의

도구 컨설턴트가 저지르기 쉬운 실수는, 모든 문제를 도구로 떠넘기는 것입니다. 우리는 반대로, 도구로 안 풀리는 문제를 도구 밖으로 꺼냈습니다. ‘PM 권한 부재'(책임은 있는데 권한이 없어 팀장을 경유해야 하는 구조)는 codeBeamer로 고칠 수 없습니다. 이건 조직이 PM의 역할을 어떻게 정의하느냐의 문제입니다.

그래서 ‘PM 역할 이미지 재정립’이라는 별도 트랙을 검증된 학술 프레임 위에 세웠습니다. 컨설턴트의 의견이 아니라 방법론으로 프레이밍하기 위해서였습니다.

이 트랙은 약 6주에 걸쳐 현황 분석 → 개선 방향·과제 정의(즉시 조정할 Quick Hits + 중장기 역할 명세 재정의) → 사업부장 조정 → 컨센서스 워크숍으로 진행되게 설계했습니다. 결과물은 역할 명세서 재정의와 역량모델이었습니다.

Results숫자로 남은 기록 — 그리고 정직한 성과 구분

보고서 작성을 손으로 하지 않고 대시보드로 자동화한 덕에(“휘발성 보고서 작성 X → 자동화”), 정착의 증거가 실측 통계로 남았습니다. 아래는 전부 관측된 실측치입니다.

가시화는 여섯 종의 대시보드 세트(전사 요약 → 개별 프로젝트 → 제품 → 조직 → 인증)와, 스프린트 단위 1페이지 경영 보고인 OPPM(One Page Project Manager)로 이뤄졌습니다. OPPM의 ‘이슈·리스크’ 행에는 정착 저항까지 정직하게 적었습니다 — 예컨대 “ALM을 단순 도구 대체로 오해하는 직원이 많음” 같은 신호를, 정치적으로 비우지 않고 그대로 기록했습니다.

Lessons컨설턴트의 교훈 — Do / Don’t

돌아보면 이 프로젝트의 본질은 ‘도구 도입’이 아니라 ‘전사가 같은 뼈대로 제품을 개발하게 만드는 일’이었습니다. codeBeamer는 그 뼈대를 담은 그릇이었고, 오래된 네 표준 — PMBOK·SEBOK·SWEBOK·CMMI — 은 그 뼈대의 설계도였습니다. 표준을 강의로 가르치고 끝내는 대신, 도구를 쓰는 매 순간의 규칙으로 접어 넣었기에, 617명의 손끝에서 표준이 살아 움직였습니다. 좋은 도구가 성과를 만드는 게 아닙니다 — 맞는 뼈대를 사람의 일상에 심는 것이 성과를 만듭니다.