[실전 공공 프로젝트 바로 투입~] 🚀 두 번째 이야기: 분석의 완성, 설계의 시작! (2개월차: 분석 & 설계 단계)

수다쟁이PM 2025. 6. 18. 00:03

[실전 공공 프로젝트 바로 투입~] 🚀 두 번째 이야기: 분석의 완성, 설계의 시작! (2개월차: 분석 & 설계 단계)

안녕하세요, 여러분의 든든한 수다쟁이 PM입니다! 👋

지난 한 달, 정신없이 프로젝트의 첫 발을 내딛고 초기 세팅을 마무리하느라 정말 고생 많으셨습니다! 이제 조금 숨 돌릴 만한가 싶지만… 쉴 틈은 없습니다! 공공정보화사업의 특성상 우리는 언제나 시간과의 싸움을 해야 하니까요. 🏃‍♂️💨

2개월차는 프로젝트의 방향성을 명확히 하고, 분석 단계를 단단하게 마무리함과 동시에, 본격적인 시스템의 뼈대를 세우는 '설계 단계'로 전환이 이루어지는 매우 중요한 시기입니다. 이상적으로는 분석 단계를 완벽하게 끝내고 설계로 넘어가는 것이 좋겠지만, 촉박한 일정 속에서는 분석 단계의 최종 검토 및 승인 과정에서 설계 단계를 중첩하여 시작하는 것이 일반적이죠. 🔄 (네, 알아요... PM의 숙명! 😉)

이번 2개월차 글에서는 5주차부터 9주차까지의 과정을 다루면서 분석 단계의 매듭을 어떻게 지어야 하는지, 그리고 설계의 첫 삽을 뜨면서 어떤 점들을 놓치지 말아야 하는지 상세하게 알려드릴게요! (물론, 프로젝트 상황에 따라 분석 단계가 7~8주차까지 늘어지는 경우도 허다하다는 점, PM님들은 이미 아실 겁니다! 🤦‍♀️)

자, 그럼 이제 프로젝트의 본질에 더 깊이 파고드는 2개월차, 함께 시작해 볼까요? 🧐✨

프로젝트 2개월 차: 분석의 정교함, 설계의 시작점

5주차: 요구사항, 바늘구멍까지 꿰어 맞추기 (분석단계 심화)

분석 단계의 핵심은 바로 '요구사항'입니다. 5주차에는 지난주부터 이어온 요구사항 분석 및 정의 작업을 더욱 심층적으로 진행하며, 시스템이 나아갈 방향을 구체화하는 데 집중합니다.

1. 요구사항 정의서 상세화

PL/개발팀 주도로 시스템이 무엇을 '해야 하는지'를 넘어, 어떻게 '잘' 해야 하는지를 정의하는 시기입니다. 기능적 요구사항(사용자 스토리, 유스케이스 등)은 물론, 성능, 가용성, 보안, 사용자 편의성, 유지보수성, 확장성 등 비기능적 요구사항을 상세하게 정의하고 구체화하는 것이 무엇보다 중요합니다.
PM/QA는 CBD_한국정보화진흥원_SW_표준산출물_관리가이드의 '1.1 사용자 요구사항 정의서' 양식을 기반으로, 마치 돋보기로 들여다보듯 꼼꼼하게 내용의 적정성을 검토하고 지원합니다! 🔍

2. 요구사항 정의서 리뷰 (고객과 함께하는 밀당)

PM은 작성된 현행분석서와 요구사항 정의서를 가지고 고객과 심도 깊은 리뷰를 주도합니다. 모든 요구사항을 일일이 리뷰하기에는 고객의 시간이 한정적일 수 있으니, PM의 현명한 판단이 필요합니다. 향후 논쟁의 소지가 있거나, 시스템의 핵심 기능과 관련된 내용에 대해서는 특히 집중적으로 고객과 요구사항을 명확하게 합의해야 합니다.
PL/개발팀은 요구사항에 대한 기술적 설명과 구현 가능성을 제시하고, QA는 품질 관점에서 모호한 부분이나 일관성 없는 부분을 짚어줍니다.
RFP 외 '추가 요구사항' 관리: RFP(제안요청서)에 명시되지 않았지만 고객이 추가적으로 요구하는 사항은 '추가 요구사항'으로 명확히 식별하여 요구사항 정의서에 표기해야 합니다. RFP 상의 요구사항은 특별한 이슈가 없는 한 '수용'이 원칙입니다. 반면, '추가 요구사항'에 대해서는 고객과 충분히 협의하여 수용 가능 여부를 '수용' 또는 '미수용'으로 결정해야 합니다. 무조건 'Yes'만 외치거나 무조건 'No'만 하는 것은 좋지 않습니다. PM의 뛰어난 소통 능력이 빛을 발하는 순간이죠! 고객의 '간지러운 부분'은 우리가 쉽게 긁어줄 수 있고, 때로는 우리의 '시린 부분'이 고객에게는 '빼도 되는 별것 아닌' 경우일 때도 많습니다. 유연한 사고와 협상이 프로젝트 성공의 지름길입니다! 🤝

3. 처리 대상 정보 및 보안 항목 식별

PL/개발팀 주도로 시스템이 처리할 정보와 기능을 명확히 식별하고, 해당 정보에 적용되어야 할 보안 항목을 구체적으로 식별합니다.
PM/QA는 기관 내 개인정보 보호 규정, 정보보안 관련 규정 등 내부 정책 자료는 물론, 개인정보 보호법, 정보통신망법, 금융거래법 등 외부 법규 및 정책 자료를 철저히 검토하여 기반을 다지도록 지시하고 검토합니다. 이는 향후 보안 설계의 중요한 밑그림이 됩니다. (보안은 아무리 강조해도 지나치지 않습니다, PM님! 🔒)

<주요 산출물>

요구사항 정의서
현행 분석서

6주차: 분석 단계의 종착역, 그리고 설계의 예비 신호 (분석 단계 검토 & 설계 단계 준비)

이제 분석 단계의 마침표를 찍고, 다음 단계인 설계의 준비를 본격적으로 시작하는 시기입니다. 이 시기에 이루어지는 산출물 검토와 감리 준비는 프로젝트의 품질과 직결됩니다.

1. 요구사항 정의서 최종화 및 요구사항 추적표 초안 작성

PL/개발팀 주도로 요구사항 정의서 작성을 최종 완료하고, 이를 기반으로 요구사항 추적표의 초안을 작성합니다.
PM/QA는 이 추적표가 설계 단계의 중요한 입력물이 되며, 향후 개발 및 테스트 단계에서 모든 요구사항이 누락 없이 반영되었는지를 검증하는 핵심 도구가 되므로, CBD_한국정보화진흥원_SW_표준산출물_관리가이드에 명시된 요구사항 추적 매트릭스 작성을 고려하며 이 표 하나로 우리는 길을 잃지 않을 겁니다! 🧭

2. 분석단계 산출물의 품질 검증

QA 주도로 분석 단계에서 작성된 모든 산출물(현행분석서, 요구사항 정의서 등)에 대해 품질 검증 활동을 진행합니다. 산출물의 완전성, 일관성, 명확성 등을 확인하고, 미비점이나 오류를 식별하여 보완을 요청합니다. QA는 PM의 눈과 귀가 되어준다는 사실, 잊지 마세요! 👀👂

3. 고객에게 검토 및 승인 요청

PM 주도로 최종 완성된 분석 단계 산출물에 대해 고객(주관기관)에게 공식적으로 검토 및 승인을 요청합니다. 이는 다음 단계로의 진행을 위한 필수적인 절차입니다. 승인 도장은 우리의 노력에 대한 보상이죠! 💯

4. 분석 단계 정보시스템 감리 준비

QA 주도로 공공정보화사업의 특성상 분석 단계에 대한 정보시스템 감리가 예정되어 있는 경우가 많은 경우, 감리 준비 활동을 주도합니다. 감리법인이 사업자가 제출한 산출물을 점검하고 시정 조치를 요구할 수 있으니, 예상 질의에 대한 답변, 자료 준비, 현장 대응 계획 등을 수립합니다. PM/PL/PMO는 QA를 적극 지원하고, 전자정부지원사업 사업관리매뉴얼 V6.0의 감리 관련 절차를 숙지하고 대비해야 합니다. 첫 감리, 두근거리는 마음으로 맞이할 준비 되셨나요? 😨

5. 분석단계 WBS(Work Breakdown Structure) 작성

PMO 주도로 분석 단계에서 수행된 모든 작업에 대한 WBS를 최종적으로 정리합니다. 이는 2~4레벨 정도의 깊이까지 작성되며, 전체 프로젝트의 범위를 개략적으로 파악하고 초기 계획 수립 및 주요 산출물 도출을 목적으로 합니다. PM은 이를 검토하고 최종 승인합니다.

6. (설계단계 시작) 논리 데이터 모델링 착수

PL/개발팀 주도로 분석 단계에서 도출된 정보와 관계를 바탕으로, 논리 데이터 모델링을 통해 엔티티(개체) 간의 관계를 정의하고, 주제 영역, 개념 모델, 논리 모델 관련 사항을 명확히 합니다. 이는 데이터베이스 설계의 첫걸음입니다. PM/QA는 이를 검토하며, 데이터 모델링은 시스템의 뼈대를 세우는 중요한 작업이니, 신중하게 접근해야겠죠? 🏗️

<주요 산출물>

요구사항 정의서(최종)
요구사항 추적표(초안)
개념 데이터 모델/논리 데이터 모델 정의서
엔터티(개체) 정의서

7주차: 설계의 첫 문을 열고, 뼈대를 세우다 (설계 단계 착수 및 시스템 아키텍처 설계)

이제 분석의 울타리를 넘어, 시스템의 큰 그림을 그리는 설계 단계의 문이 활짝 열립니다. 7주차에는 시스템의 전반적인 구조와 핵심 기술을 정의하는 아키텍처 설계에 집중합니다.

1. 설계 단계 착수 및 시스템 아키텍처 및 고수준 설계 시작

PL 주도로 드디어 설계 단계에 공식적으로 착수하여, 시스템 전체의 아키텍처 및 고수준(High-Level) 설계를 시작합니다. 이는 시스템의 주요 구성 요소와 이들 간의 상호작용 방식, 기술 스택 등을 정의하는 중요한 작업입니다.
PM은 CBD_한국정보화진흥원_SW_표준산출물_관리가이드의 '1.3 시스템 아키텍처 설계서' 양식을 참고하여 우리 시스템의 웅장한 청사진을 그려나갈 시간입니다! 🏙️

2. 기능적/비기능적 요구사항의 설계 반영

PL/개발팀 주도로 분석 단계에서 도출된 모든 기능적 요구사항은 물론, 성능, 보안, 가용성 등 비기능적 요구사항을 시스템 설계에 체계적으로 반영하기 시작합니다. 특히 보안 요구사항은 초기 아키텍처 단계부터 깊이 있게 고려되어야 합니다. PM/QA는 이를 면밀히 검토합니다. 보안은 기본 중의 기본, 아니 이제는 핵심입니다! ✨

3. 공공 데이터베이스 표준화에 따른 데이터 구조 설계

PL/개발팀 주도로 공공데이터베이스 표준화 관리 매뉴얼에 따라 데이터 구조 설계를 진행하며, 논리/물리 데이터 모델링 시 준수해야 할 기준과 규칙, 고려사항을 적극 반영합니다. 이는 데이터 품질 관리의 중요한 부분이며, 표준화된 데이터 구조는 향후 시스템의 안정성과 확장성에 크게 기여합니다.
QA는 데이터 품질 관점에서 이를 검토하고, PM은 고객과의 최종 합의를 조율합니다.
Tip! 데이터베이스 산출물 관리: PM님들의 현장에서의 효율성을 고려하여, 데이터베이스 산출물(ERD 등)은 테일러링 단계에서 통합 관리하거나, 필요한 경우 간단한 스크립트를 통해 자동화 생성을 고려할 수 있습니다. 수다쟁이PM은 효율성을 지지합니다! 😉

4. 분석단계 감리 수검

PM 주도로 3단계 감리(분석/설계/종료)를 수검한다면 첫 번째 감리가 보통 이 시점에 들어옵니다. 감리 수검 최소 1주일 전에는 QA와 함께 분석단계의 전체 산출물을 점검하세요. 분석단계의 감리에서는, 과업대비표와 요구사항 정의서 위주로 점검을 합니다. (이 두 개의 산출물은 테일러링 단계에서 고객과 협의하여 요구사항 정의서로 하나로 통합할 수 있습니다) PL/개발팀은 감리 질의에 대한 기술적 설명을 지원합니다. 첫 감리, 긴장되시겠지만 침착하게 우리의 노력을 보여줍시다! 🧘‍♀️

<주요 산출물>

아키텍처 설계서 (또는 시스템 아키텍처 설계서) [1, CBD_133]
초기 데이터베이스 설계 산출물 (논리/물리 ERD 등)

8주차: 상세 설계와 보안의 심화 (상세 설계 및 보안 설계 강화)

시스템의 뼈대가 세워졌으니, 이제 각 부분의 살을 붙이고 혈액순환을 원활하게 할 상세 설계를 진행합니다. 특히 공공 프로젝트에서 생명과도 같은 '보안'은 이 단계에서 더욱 강화됩니다.

1. 상세 시스템 설계 진행

PL/개발팀 주도로 각 구성 요소와 모듈, 그리고 이들 간의 인터페이스를 구체적이고 상세하게 정의하는 설계 작업을 진행합니다. 이 단계에서는 실제 개발에 필요한 모든 기술적 명세가 포함됩니다. 설계는 곧 개발의 설명서이니, 빈틈없이 채워야 합니다! 📘

2. 보안 설계 강화 및 구체화

PL/개발팀 주도로 5주차에 식별한 보안 요구사항을 바탕으로, 시스템 전반에 걸쳐 보안 설계를 심화하고 구체화합니다.
- 인증 및 세션 통제: 로그인 시도 횟수 제한, 계정 잠금 정책, 임시 비밀번호 발급 시 보안 강화 등 인증 관련 정책을 상세 설계에 반영합니다.
- 비밀번호 관리 규칙: 주기적인 비밀번호 변경, 만료 기간 설정, 마지막 로그인 시간 관리 등 강력한 비밀번호 관리 규칙을 설계에 포함합니다. 안전한 비밀번호, 기본 중의 기본이죠! 🔑
- 중요 정보 전송: 민감한 정보(인증정보, 개인정보, 쿠키 등) 전송 시에는 안전한 암호화 모듈 사용 또는 보안 통신 채널(HTTPS 등) 사용을 필수적으로 설계합니다.
- 암호화 알고리즘 및 키 관리: 한국인터넷진흥원의 암호 키 관리 안내서에 따라 암호 키 관리 규칙(생성, 분배, 사용, 폐기)을 수립하고, 충분한 키 길이와 예측 불가능한 난수 사용을 설계에 명시합니다.
- 오류 처리: 오류 메시지에 민감한 시스템 정보나 개인 정보가 노출되지 않도록 정의된 최소한의 정보만 제공하도록 설계합니다. 친절한 오류 메시지도 좋지만, 보안을 위해선 '덜' 친절해야 할 때도 있습니다! 🤫
QA는 보안 품질 관점에서 이를 검토하고, PM은 최종 승인 및 고객과의 협의를 담당합니다.

3. 데이터베이스 물리적 특징 및 관리 기준 기술

개발팀 주도로 테이블 설명, 보존기간, 발생주기 등 데이터베이스의 물리적 특징과 운영 및 관리 기준을 상세하게 기술합니다. 이는 데이터베이스 운영팀과의 협업 및 향후 유지보수에 중요한 정보가 됩니다.

<주요 산출물>

어플리케이션 설계 산출물들 (모듈 정의서, 프로그램 명세서, 인터페이스 정의서 등)
테스트 계획서들 (총괄 테스트 계획서, 단위 테스트 계획서, 통합 테스트 계획서, 시스템 테스트 계획서 등)

9주차: 설계의 완성, 요구사항과의 마지막 점검 (설계 산출물 통합 및 검토)

2개월차의 마지막 주는 그동안 진행된 설계 결과물들을 통합하고, 모든 퍼즐 조각이 제자리를 찾았는지 확인하는 중요한 시간입니다.

1. 완성된 설계 산출물 통합 및 정리

PMO/PL 주도로 시스템 설계서, 데이터베이스 설계서, 인터페이스 설계서 등 완성된 모든 설계 산출물들을 체계적으로 통합하고 정리합니다. 이는 향후 개발 단계의 가이드라인이 됩니다. 이제 진짜 설계 도면이 한 권으로 묶이는 느낌이죠! 🏗️
PM은 최종적으로 산출물들의 완성도와 일관성을 검토합니다.

2. 요구사항 추적표 기반 내부 검토

PM/QA 주도로 업데이트된 요구사항 추적표를 활용하여 요구사항의 내용과 설계 산출물을 꼼꼼히 매핑합니다. 이를 통해 빠진 요구사항이 없는지, 각 요구사항의 내용이 설계에 모두 적절하게 반영되었는지 면밀한 내부 검토를 진행합니다.
PL/개발팀은 검토에 참여하여 기술적 적정성을 확인합니다. 이 과정은 잠재적 오류를 최소화하고, 고객에게 최종 승인을 받기 위한 마지막 점검입니다. 숨바꼭질하듯 숨어있을지 모를 누락된 요구사항을 찾아내는 시간입니다! 🧐

3. 설계 단계 WBS 작성

PMO 주도로 설계 단계의 상세 WBS를 작성합니다. 이는 4~5레벨 정도의 깊이까지 작성되어야 하며, 개발 단계의 상세 공수 및 일정 계획 수립의 근거가 됩니다. PM은 이를 검토하고 승인하며, 향후 개발 진행의 이정표가 됩니다.

<주요 산출물>

최종 설계 산출물 일체 (아키텍처 설계서, 어플리케이션 설계서, DB 설계서, 테스트 계획 설계서 등)
요구사항 추적표
설계 단계 WBS

[수다쟁이PM의 Know-How!💎] 2개월차 생존 전략

분석과 설계의 경계에서 줄타기를 하는 2개월차, PM은 이런 점들을 놓치지 마세요! 🌟

회의록의 중요성, '말'은 휘발되지만 '글'은 남습니다! 📝: 고객과의 회의, 팀 내부 회의 등 모든 주요 논의와 결정 사항은 반드시 회의록으로 남겨야 합니다. "그때 그렇게 말씀하시지 않았나요?" 하는 곤란한 상황에서 회의록은 PM의 강력한 증거이자 방패가 됩니다. 논의 내용, 결정 사항, 담당자, 기한 등을 명확히 기록하고 모두가 동의했음을 확인하세요.
'협업 인프라'는 프로젝트의 혈액순환! 🩺: 폐쇄망 환경의 공공 프로젝트에서는 더욱 중요합니다. 네트워크 공유 폴더를 통한 산출물 및 공통 자료 관리, 팀원 소통을 위한 메신저 활용, 그리고 주기적인 백업 등 효율적인 협업 환경 구축은 필수적입니다. 폴더 구조, 파일 명명 규칙 등을 초반에 합의하고 철저히 준수하도록 독려하세요. 프로젝트의 데이터 유실은 곧 사망 선고나 다름없으니, 안정적인 주기적 백업은 아무리 강조해도 지나치지 않습니다. 이러한 협업 인프라를 구축하는 데 있어 '시놀로지 NAS'는 훌륭한 대안이 될 수 있습니다. (저 시놀로지 관계자 아닙니다!!) 자체 백업 기능이 뛰어나고 폐쇄망에서도 유연하게 활용 가능하며, 파일 공유 및 심지어 자체 메신저 기능을 통해 팀원 간 소통까지 지원하여 PM의 걱정을 한시름 덜어줄 겁니다! 💾
보안, 아무리 강조해도 부족합니다! 🚨: 공공 프로젝트에서 보안은 생명과도 같은 요소입니다. 고객이 가장 까다롭게 보고, 사고 발생 시 가장 큰 피해로 이어지기 때문입니다.
- 사무실 보안: 출입 통제, 외부인 관리, 비인가 장비 반입 금지 등을 철저히 지켜야 합니다.
- 개발 보안: 소스코드 보안, DB 접근 통제, 개발망/운영망 분리 등 기술적 보안도 간과할 수 없습니다.
- 인적 보안: 팀원들의 보안 의식을 높이는 것이 핵심입니다. 출입구 잘 보이는 곳에 <보안 규칙 및 최종 퇴실 시 체크리스트>를 프린트해서 붙여놓고 매일 확인하도록 독려하는 것도 아주 좋은 방법입니다. 퇴근 전 마지막 불 끄는 사람이 보안 지킴이! 👮
감리는 우리의 '동반자적 감시자'! 🤝: 감리 조직은 물론 우리 사업자를 감시하는 역할도 하지만, 동시에 고객을 감시하는 조직이기도 합니다. 프로젝트는 고객, 감리, 사업자 3자 책임인 만큼, 감리도 프로젝트의 성패에 영향을 받게 됩니다. 만약 고객이 산출물 승인 절차를 지연하거나, 비합리적인 요구를 하는 등 협의 진행이 원활하지 않을 경우, 감리 사업단에게 객관적인 입장에서의 협조를 구하는 것도 현명한 방법입니다. '감리'를 잘 활용하는 PM이 진정한 고수입니다! 🎯

<수다쟁이 PM의 AI 활용 꿀팁!> 2개월차, AI로 효율 UP! 🤖

분석과 설계의 복잡한 과정 속에서 AI는 PM의 든든한 지원군이 될 수 있습니다! 🚀

회의 녹음 및 AI 요약 (고객 동의 필수! 🎙️): 고객과 동의하여 회의 내용을 음성으로 녹음하고, AI에게 요약을 요청해 보세요. 회의록 작성 시간을 획기적으로 줄이고, 중요한 결정 사항이나 액션 아이템을 놓치지 않고 정확하게 기록하는 데 큰 도움이 됩니다. '회의록의 노예'에서 해방될 시간입니다! 💡
요구사항 상세화 보조 (작문은 AI에게 맡기고 논리에 집중! ✍️): 작문 능력보다 논리에 강한 개발팀에게는 생각보다 요구사항 상세화가 어렵습니다. 앞서 KMS를 통해 유사사업들의 정보를 업데이트했다면, 이를 통해서 AI에게 요구사항 상세화 초안을 작성하도록 해보세요. AI가 제안하는 구조와 표현을 바탕으로 본 사업에 맞게 수정해가면 작문 부담이 훨씬 줄어들고, 더욱 구체적인 요구사항 정의서를 만들어갈 수 있습니다.
산출물 품질 검토 보조: 작성된 요구사항 정의서나 현행분석서를 AI에 업로드하여 문법적 오류, 일관성 부족, 모호한 표현 등을 검토하도록 할 수 있습니다. CBD_한국정보화진흥원_SW_표준산출물_관리가이드의 특정 섹션을 미리 업로드하여 검토시켜서, 해당 가이드라인에 부합하는지 여부를 검토하도록 시도해 볼 수도 있습니다. 이는 QA팀의 업무 부담을 줄이고, 초기 품질을 높이는 데 기여할 수 있습니다. 우리 팀의 문서 퀄리티, AI가 업그레이드 시켜줍니다! 📈

AI를 활용하여 반복적이거나 정보 분석에 시간이 많이 소요되는 작업을 자동화하고, PM은 더 전략적인 의사결정과 고객 및 팀원 관리에 집중하세요!

[수다쟁이 PM의 다음 이야기...]

다음 주에는 드디어 설계 단계의 모든 퍼즐 조각을 맞춰 최종 승인 도장을 받아내고, 이제부터는 눈에 보이는 결과물을 만들어나갈 '구현 단계'의 막을 올릴 시간입니다! 🏗️💻 단순히 코딩만 하는 것이 아니라는 것, PM님들은 다 아시죠? 효율적이고 견고한 시스템을 만들기 위한 진짜 싸움이 시작될 겁니다!

다음 주에 [실전 공공 프로젝트 바로 투입~] 🚀 세 번째 이야기: 설계의 최종 승인! 이제는 코딩으로 승부다! (3개월차: 설계 마무리 & 구현 착수)' 로 다시 찾아뵙겠습니다! 기대해주세요! Peace out~! ✌️😎