공공 프로젝트(SI) 설계 단계: 문서 지옥의 설계 단계, 찐으로 파헤치기! (PM 필독!)

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

지난번 '분석 단계'에서 고객의 '진짜 속마음'과 시스템의 '무엇을 만들지'를 확정하며 첫 고비를 넘으셨죠? 휴~ 이제는 그 어렵고도 중요한 요구사항을 바탕으로 '어떻게 만들지'에 대한 구체적인 청사진을 그릴 차례입니다! 바로 '설계 단계'죠! 🏗️ (PM의 진정한 고난이 시작되는... 읍읍! 🤐)

설계 단계는 마치 건축가가 건물의 뼈대를 세우고, 방마다 어떤 기능을 할지, 배관은 어디로 빼고 전선은 어떻게 연결할지 세부 도면을 그리는 것과 같아요. 이 단계에서 정의되는 모든 구조와 기능이 앞으로의 개발 방향을 결정하고, 시스템의 견고함과 품질을 좌우하게 된답니다.

이 중요한 시기에는 사업단(우리 팀!)이 피 땀 눈물(?)을 흘리며 멋진 설계 산출물들을 만들어내고, 운영 관련 부서(고객님들!)는 '매의 눈'으로 이를 꼼꼼히 검토하는 역할을 수행합니다. 가장 많은 산출물을 쏟아내는 그야말로 '역경의 시간'이지만, 이 고비를 넘겨야만 프로젝트의 성공을 담보할 수 있어요!

저희는 오늘, CBD(Component-Based Development) 방법론과 폭포수(Waterfall) 개발 방식을 기준으로, 설계 단계에서 생성되는 주요 핵심 산출물들을 중심으로 다시 한번 찐으로 파헤쳐 볼 거예요!

---

💡 잠깐! CBD & 폭포수 개발방식, PM이라면 이 정도는 알아야죠!

• CBD(Component-Based Development) 방법론이 뭐냐구요? 쉽게 말해, 재사용이 가능한 '레고 블록(컴포넌트)'들을 미리 만들거나 사서, 그걸 조합해서 애플리케이션을 뚝딱! 만드는 방식이에요. 🧩 이렇게 하면 개발 생산성과 품질이 확~ 올라가고, 나중에 시스템 고치거나 업그레이드할 때도 훨씬 편하답니다! (유지보수 비용도 절감! 💸) 게다가 반복적으로 발전시키는 개발 프로세스를 제공하고 표준화된 산출물 작성을 특징으로 해요.
• 폭포수(Waterfall) 개발 방식이란? 우리가 흔히 아는 분석 → 설계 → 구현 → 테스트 → 완료 후 유지보수 순으로 단계별 '단방향'으로 개발을 진행하는 방식입니다. 폭포수가 위에서 아래로 흐르듯이, 한번 다음 단계로 넘어가면 이전 단계로 돌아가기가 굉~장히 어렵다는 특징이 있어요. 🏞️ 때문에 초기 계획과 산출물 작성이 너~무 중요하답니다. (PM의 어깨가 무거워지는 소리가 들린다...)
• 최근에는 프로토타입이나 애자일 방법론처럼 초반부터 결과물을 예측하고, 요구사항 변경에 좀 더 유연하게 대응하는 방식들이 뜨고 있지만, 기간과 비용, 그리고 까다로운 절차 등 여러 제약이 많은 '공공기관'에서는 아직도 이 '폭포수 개발'이 대세라는 사실! 그래서 PM님들이 이 방식에 대한 이해가 필수적이에요! 😉

---

그럼, 이제 설계 단계에서 어떤 활동들을 하고, 어떤 보물 같은 산출물들이 탄생하는지 함께 살펴볼까요? 🚀 (PM의 무기들 대방출!)

---

2. 설계 단계에서 수행해야 할 주요 활동들 (PM의 체크리스트! 꼼꼼하게 챙겨야 할 것들!)

설계 단계는 PM의 세심한 눈과 귀, 그리고 강력한 조율 능력이 필요한 시기입니다. 꼼꼼하게 챙겨야 할 핵심 활동들을 살펴볼까요?

• 시스템의 '뼈대'와 '내장'을 디자인하기: 분석 단계에서 도출된 요구사항을 바탕으로, 시스템의 전체적인 구조(아키텍처), 각 프로그램의 기능, 데이터가 어떻게 저장되고 흐를지, 그리고 다른 시스템과는 어떻게 통신할지 등을 구체적으로 그려내는 작업입니다. 마치 인체의 뼈대와 주요 장기들의 위치를 설계하는 것과 같아요. (여기서 설계가 잘못되면... 나중에 뼈 부러지고 장기 꼬입니다... 😱)
• UI/UX는 '사용자 관점'에서 생각하기: 화면 설계할 때는 '개발자' 관점보다는 '사용자'가 얼마나 편하게 쓸 수 있을지, 보기에는 어떤지(UI), 사용했을 때 어떤 경험을 줄지(UX)를 최우선으로 생각해야 합니다. 우리의 고객은 결국 사용자니까요! 👩‍💻👨‍💻 예쁘기만 하고 쓰기 불편하면 아무도 안 쓰겠죠? 😉
• 데이터는 '미래'를 보고 설계하기: 데이터는 시스템의 '뇌'이자 '기억'입니다. 초기부터 중복 없이 체계적으로 관리될 수 있도록 꼼꼼하게 설계하고 표준화하는 것이 중요해요. 잘못된 데이터 설계는 나중에 엄청난 혼란을 가져올 수 있답니다. (데이터가 꼬이면 PM도 꼬여요... 😵‍💫 야근 예약! ㅠㅠ)
• 테스트 계획은 '미리미리' 세우기: "개발 다 하고 나서 테스트하지 뭐~"라는 생각은 금물! 설계 단계에서부터 어떤 부분을 어떻게 테스트할지, 누가 테스트할지, 어떤 기준으로 통과시킬지 등 구체적인 계획을 세워야 합니다. 그래야 나중에 '버그 지옥'에 빠지지 않을 수 있어요! 🐛 (PM의 숙면을 위해서도 필수!)
• 보안은 '설계부터 DNA처럼' 심기: 분석 단계에서 파악된 보안 요구사항들을 설계 단계에서부터 시스템 아키텍처와 프로그램 곳곳에 녹여내야 합니다. 마치 건물을 지을 때 설계 단계부터 내진 설계를 하는 것과 같아요. 나중에 덧붙이려면 시간과 비용이 훨씬 더 많이 든답니다. (보안 설계서 내용은 별도 산출물에서 다루거나 구현 단계에서 상세화되니, 걱정 마세요!)
• 산출물은 '고객 승인'이 생명!: 각 설계 산출물이 완성되면, 고객(운영 관련 부서)의 검토와 최종 승인을 받아야 합니다. 이는 모든 이해관계자가 같은 그림을 보고 있다는 명확한 증거가 되며, 향후 발생할 수 있는 오해와 책임 소재를 분명히 하는 PM의 가장 중요한 역할입니다. (도장 없이는 다음 단계로 못 갑니다! 쾅쾅! 🖊️)

---

3. 설계 단계의 핵심 산출물 완전 정복 (PM의 든든한 무기들! 🛡️)

소프트웨어 개발 프로젝트의 설계 단계에서는 프로젝트의 성공적인 수행을 위해 정말! 다양한 핵심 산출물들이 정의되고 활용됩니다. 이 문서들은 프로젝트의 방향을 정립하고, 잠재적인 문제를 조기에 발견하며, 개발 전 과정의 품질을 보증하는 데 필수적인 역할을 수행합니다. 각 산출물이 상호 유기적으로 연결되어 프로젝트의 투명성과 성공 가능성을 높이는 데 기여합니다.

3.1. 아키텍처 설계 (시스템의 뼈대 세우기! 뼈대가 튼튼해야 무너지지 않아요!)

시스템의 전체적인 청사진을 제시하는 단계입니다. 단순히 그림 그리는 게 아니라, 시스템의 모든 기능과 성능을 지탱할 튼튼한 '뼈대'를 세우는 과정이죠!

• 아키텍처 설계서: 이 문서는 시스템의 가장 큰 그림을 보여줘요. 소프트웨어 아키텍처는 우리가 만들 프로그램들이 어떻게 구성되고 서로 어떻게 대화할지(컴포넌트, 연결 방식 등)를 보여주는 청사진입니다. 마치 집의 방 배치와 각 방이 어떻게 연결될지 보여주는 도면 같아요. 시스템 아키텍처는 이 프로그램들이 어떤 하드웨어(서버!), 어떤 운영체제(시스템 소프트웨어!), 어떤 네트워크(인터넷 연결!) 위에서 돌아갈지를 설명합니다. 시스템 전체의 큰 그림을 보여주는 거죠. 여기에는 시스템의 품질(얼마나 안정적일지), 성능(얼마나 빠를지), 장애 복구(문제 생기면 어떻게 복구할지) 같은 중요한 요구사항들이 어떻게 구현될지 기술됩니다. 물론 보안 관련 요구사항도 포함되지만, 구체적인 내용은 다른 곳에서 상세히 다룰 거예요. (PM 찐팁: 성능 테스트 단계에서 아키텍처 설계가 부실하다는 소리가 나오면... 그때는 정말 답이 없습니다. ㅠㅠ 처음부터 다시 뜯어고쳐야 하는 재앙이 발생할 수도 있어요. 미리미리 꼼꼼하게! 🚨)

3.2. 애플리케이션 설계 (시스템에 살을 붙이고 디테일을 채우는 과정! 🧑‍🎨)

이제 시스템의 뼈대에 살을 붙이고, 실제로 어떤 기능을 할지 구체적으로 정의하는 단계입니다. 프로그램 하나하나의 설계도가 여기에서 나옵니다.

• 클래스 설계서: 개발자들이 프로그램을 짤 때 가장 기본이 되는 '부품(클래스)'들을 정의하는 문서예요. 모든 유스케이스(사용자 시나리오)가 이 클래스들로 구현될 수 있는지 꼼꼼히 확인해야 합니다.
• UI/UX 사용자 인터페이스 설계서 (화면 설계서): 말 그대로 '화면'을 설계하는 문서입니다. 사용자에게 보여지는 시스템의 '얼굴마담'이죠! 🖼️ 모든 유스케이스가 화면에 잘 녹아들었는지, 웹 구성도는 어떤지, 화면 ID는 명확한지 등을 확인합니다. 특히 사용자 편의성(UI)과 효율성(UX)을 최고로 고려해야 해요. 예쁘기만 하고 쓰기 불편하면 아무도 안 쓰겠죠? 😉
• 컴포넌트 설계서: CBD 방법론의 핵심! 재사용 가능한 '레고 블록(컴포넌트)' 하나하나를 정의하는 문서입니다. 각 컴포넌트의 고유 ID, 이름, 어떤 유스케이스와 연결되는지, 그리고 그 안에 어떤 클래스들이 들어가는지 상세히 기술해요. 컴포넌트 간의 관계를 보여주는 구조도도 포함되어야 합니다. 이게 잘 되어 있어야 나중에 블록 조립하듯이 척척 시스템을 만들 수 있어요!
• 인터페이스 설계서: 우리 시스템이 다른 시스템(외부 시스템, 다른 내부 시스템 등)과 어떻게 '대화'할지 정하는 문서예요. 📞 어떤 데이터를 주고받을지, 데이터 형식은 뭔지, 연계했을 때 다른 시스템에는 어떤 영향을 줄지 등 상세한 정보를 명시해야 합니다. 이게 잘 안되면 나중에 시스템끼리 말 안 통한다고 싸울 수 있어요! 😱
• 프로그램 정의서: 제안요청서(RFP)에 명시된 프로그램에 대한 전체적인 기능과 구조를 정의하는 문서입니다. 위에서 설명한 클래스, 컴포넌트, 인터페이스 설계서 등을 아우르는 개념으로, '어떤 프로그램들이 어떤 기능을 할 거야!'라고 최종적으로 정리하는 거죠. 요구사항 추적표에서 이 프로그램 ID가 구현 단계로 쭉~ 연결되는 아주 중요한 역할을 합니다.

 

3.3. 데이터 구조 설계 (시스템의 뇌, 데이터의 집을 짓는 단계! 🧠)

시스템이 사용할 모든 데이터의 구조를 정의하고 표준화하는 단계입니다. 데이터가 튼튼해야 시스템이 똑똑해지고 안정적이죠!

• 엔티티 관계 모형 기술서 (ERD): 데이터들 간의 관계를 한눈에 볼 수 있는 '데이터의 지도' 같은 거예요. 🗺️ 엔티티(데이터 덩어리), 속성(세부 정보), 관계(서로 어떻게 연결되는지) 등을 그림으로 표현합니다. 업무 규칙이 데이터에 잘 반영되었는지, 그리고 데이터가 중복되거나 꼬이지 않게 '정규화'가 잘 되었는지 검증해야 합니다. (PM 찐팁: ERD만 봐도 이 프로젝트가 얼마나 깔끔하게 설계되었는지 알 수 있어요!)
• 데이터베이스 설계서 (테이블 설계서): ERD를 바탕으로 실제 데이터가 저장될 '집(데이터베이스)'을 어떻게 지을지 구체적으로 설계하는 문서입니다. 데이터베이스의 논리적인 구조와 실제 물리적인 서버 구성, 테이블(표) 설계 등을 기술해요. 모든 기능이 사용할 데이터와 잘 맞는지, 데이터 중복은 없는지 꼼꼼히 확인해야 합니다.
• 데이터베이스 관련 산출물 (표준화가 생명!): 데이터는 표준이 중요합니다! 공공 데이터베이스 표준화 지침에 따라 표준 용어/단어, 도메인(데이터 유형), 엔티티, 테이블, 컬럼(열) 정의서 등 다양한 문서를 작성하고 관리해야 합니다. 이전 분석 단계에서 말씀드렸던 '용어 사전'과도 긴밀하게 연결돼요! 통일된 용어를 사용해야 데이터가 꼬이지 않는답니다. (PM 찐팁: 나중에 데이터 연동할 때 표준 안 지켜져서 고생하는 일은 다반사! ㅠㅠ 미리미리 철저하게!)
• 데이터 전환 및 초기 데이터 설계서: 기존에 사용하던 시스템의 데이터를 새로운 시스템으로 '이사'시키는 계획서입니다. 📦 언제, 어떻게, 얼마나 옮길지, 어떤 데이터는 이사 오고 어떤 데이터는 버릴지 등을 상세히 제시해야 합니다. 특히 민감한 데이터(개인정보 등!)는 안전하게 옮기는 보안 방안을 꼭 포함해야 해요. 이사하기 전에 백업 계획, 복구 방안, 그리고 이사할 데이터에 오류는 없는지 미리미리 확인하는 것도 필수입니다! (이사가 쉬운 일은 아니죠? 데이터 이사도 마찬가지!)

 

3.4. 테스트 계획 설계 (시스템의 품질을 책임지는 품질 보증 설계! 🔍)

개발된 결과물이 우리의 요구사항을 잘 충족하고, 버그 없이 튼튼하게 작동하는지 확인하기 위한 '테스트 전략'을 세우는 단계입니다. PM의 마음을 편안하게 해주는 중요한 과정이죠!

• 총괄 테스트 계획서: 테스트의 '큰 그림'을 그리는 문서입니다. 🗺️ 언제, 어떤 방법으로, 어떤 환경에서 테스트할지 전체적인 일정을 세우고 계획을 수립합니다. 품질 목표를 달성했는지, 어떤 기준으로 테스트를 통과시킬지 등 전반적인 가이드라인을 제시해요.
• 단위 시험 케이스: 개발자들이 본인이 만든 '작은 프로그램 부품(컴포넌트)'이 제대로 작동하는지 스스로 확인하는 시험 케이스입니다. 마치 각 부품이 공장에서 잘 만들어졌는지 확인하는 것과 같아요. ⚙️ 주로 엑셀로 만들어지는 경우가 많아요.
• 통합 시험 시나리오: 따로따로 잘 돌아가던 부품들을 합쳤을 때, '과연 서로 잘 대화하고 문제없이 작동하는지' 확인하는 시험 시나리오입니다. (예: 로그인 -> 게시글 작성 -> 로그아웃) 여러 부품이 모여 하나의 기능을 할 때 문제가 없는지 확인하죠.
• 시스템 시험 시나리오: 모든 부품이 다 합쳐진 '완성된 시스템'이 원래의 요구사항을 모두 충족하는지, 그리고 성능이나 보안 같은 '비기능 요구사항'까지 잘 지켜지는지 확인하는 최종 시험 시나리오입니다.
• 사용자 테스트 시나리오: 이제는 '실제 사용자'가 시스템을 써보고 불편한 점은 없는지, 원하는 기능이 제대로 되는지 직접 확인하는 시나리오입니다. 사용자의 입장에서 시스템을 검증하는 중요한 단계죠. 👨‍👩‍👧‍👦
• 인수 테스트 시나리오: 고객(발주처)이 최종적으로 시스템을 '인수'하기 전에, 모든 기능과 요구사항이 제대로 구현되었는지 확인하는 '최종 검수 시험'입니다. 이 시나리오에 따라 테스트를 수행하고, 모든 기준을 통과해야 비로소 프로젝트가 성공적으로 마무리될 수 있습니다. PM의 마지막 관문이자, 승리의 깃발을 꽂는 순간이죠! 🏆

 

3.5. 프로젝트 관리 산출물 (설계 단계를 위한 PM의 필수 관리 도구! 🛠️)

설계 단계의 진행 상황을 투명하게 관리하고 추적하기 위한 PM의 핵심 관리 도구들입니다. 설계 단계 자체의 결과물은 아니지만, 이 단계의 성공적인 진행을 위해 반드시 필요해요!

• WBS (Work Breakdown Structure): 분석 단계에서 만들었던 WBS가 이제는 '설계 단계'의 세부 활동들로 더욱 촘촘하게 채워집니다. 누가, 언제, 어떤 설계 산출물을 만들지, 어떤 작업이 진행될지 등 모든 설계 활동을 계층적으로 분류하고 일정을 계획하는 데 활용됩니다. 우리 프로젝트의 '네비게이션' 역할을 톡톡히 하는 녀석이죠! 🧭
• 요구사항 추적표: 분석 단계에서 나온 요구사항들이 '설계 산출물'에 제대로 반영되었는지, 그리고 어디에 어떻게 반영되었는지 '추적'하기 위해 사용됩니다. 요구사항의 변경이 있었다면 고객의 공식 승인(회의록, 변경 요청서 등) 근거도 함께 관리해야 해요. 이 표가 있어야 '이 요구사항은 어디에 반영됐지? 헉!' 하고 헤매지 않습니다! (PM 찐팁: 보통은 요구사항 정의서를 복사해서 추적 항목을 추가하는 방식으로 많이 만들어요! 👍)
• 설계 단계 점검 결과서 및 조치 결과서: 설계 단계에서 만들어진 모든 산출물에 대해 꼼꼼하게 점검(QA나 PMO)을 수행한 결과와, 발견된 문제점들을 어떻게 조치했는지 기록하는 문서입니다. '문제가 있었는데 이렇게 해결했어요!' 라고 투명하게 보여주는 증거자료가 되죠. 요구사항이 잘 반영되었는지, 개발 표준을 잘 지켰는지 등을 점검합니다. (PM 찐팁: 이 문서가 깔끔할수록 나중에 문제 발생률이 확 줄어듭니다! 경험담...😂)

---

 

<오늘의 수다쟁이 PM Tip> (설계 단계 성공의 핵심 열쇠! 🔑)

설계 단계는 '어떻게 만들지'를 확정하는 만큼, '고객과의 합의'가 가장! 가장! 중요한 단계입니다. 분석 단계에서 확인한 '요구사항'을 바탕으로, 우리가 제안하는 '기술적 해결책'을 고객에게 명확히 설명하고 이해시켜야 해요.

만약 이 단계에서 설계에 대한 합의가 제대로 이루어지지 않으면, 구현 단계에 들어가서 "이거 제가 생각한 거랑 다른데요? 🤯" 라는 고객의 말에 PM은 뒤통수를 세게 맞고... 다시 설계 단계로 돌아가는 '폭포수 역류' 사태가 발생할 수 있습니다. 🌊 각 설계 산출물을 하나하나 설명하고, 고객의 궁금증을 해소하며, 최종적으로 '승인'을 받아내는 것이 PM의 숙명이자, 프로젝트 성공의 지름길입니다!

각 산출물의 서식은 "CBD SW 개발 표준 산출물 관리 가이드"와 "전자정부지원사업 사업관리매뉴얼"을 참고하시면 됩니다. (공공기관 프로젝트의 필수 지침서!)

물론 설계는 정답이 없기에 완벽한 설계는 불가능합니다. 하지만 최대한 많은 이해관계자들과의 소통과 검토를 통해 '모두가 공감하는 최선의 설계'를 만들어내는 것이 PM의 역량이라고 할 수 있습니다! 🧑‍💻👩‍💻

---

<수다쟁이 PM의 AI 활용 꿀팁!>

설계 단계에서는 수많은 다이어그램(클래스 다이어그램, 시퀀스 다이어그램 등)과 상세 문서들을 작성해야 합니다. 이 작업, 보통 일이 아니죠? 😵‍💫 이때 AI를 '설계 보조 도구'로 활용해 보세요!

• "요구사항 정의서의 이 유스케이스(XXX)에 대한 클래스 다이어그램 초안을 그려줘!"
• "이 시스템 인터페이스의 송신/수신 데이터 명세 초안을 작성해줘!"
• "우리 프로젝트의 개발 표준 정의서에 맞는 '로그인' 기능의 상세 설계 가이드라인을 작성해줘!"
• "ERD에서 이 엔티티(OOO)와 관련된 정규화 원칙들을 설명해주고, 데이터 중복을 피하는 방법을 알려줘!"

복잡한 설계 문서를 작성할 때 AI에게 초안을 요청하거나, 특정 설계 원칙에 대해 질문하여 아이디어를 얻을 수 있습니다. AI가 제공하는 정보를 바탕으로 PM과 설계자들이 수정 및 보완 작업을 진행하면, 훨씬 빠르고 정확하게 산출물을 만들어낼 수 있을 거예요! 우리 PM님들의 칼퇴를 위해! 🚀

---

[다음 글에서는...]

오늘 우리는 시스템의 뼈대와 살을 붙이는 '설계 단계'의 모든 것을 알아봤습니다. 이제 이 멋진 설계도를 가지고 실제 시스템을 만들어나가는 '구현 단계'로 넘어갈 차례입니다! 코딩, 빌드, 테스트, 그리고 배포까지! PM이 알아야 할 구현 단계의 모든 꿀팁을 다음 글에서 아낌없이 풀어드릴게요! 기대해주세요! 😉