🗺️ 핵심 설계도의 작성 순서와 실질적인 작업 흐름.

🚀 결론부터 말하자면, 엄격한 폭포수 방식(Waterfall Methodology)이 아닌, 서로 영향을 주고받으며 점진적으로 완성해 나가는 것이 일반적 입니다.
하지만 개념적인 순서는 명확하게 존재하며, 그 순서를 이해하는 것은 매우 중요합니다.

📌 이상적인 작성 순서 (개념적 흐름)

마치 집을 짓는 과정처럼, 가장 추상적이고 근본적인 것에서부터 구체적인 것으로 나아갑니다.

1️⃣ 요구사항 명세서 (무엇을 만들 것인가?) 🤔

• 가장 먼저 시작이되어야 합니다.
• 이유 :
  • 어떤 기능을 만들지, 어떤 비즈니스 규칙을 담을지 결정되지 않으면, 기술적인 설계(아키텍처)나 데이터구조(DB)를 논하는 것 자체가 불가능합니다.
  • “고객이 원하는 집”이 어떤 모습인지(방 개수, 층수, 스타일 등)를 먼저 정하는 단계입니다.
• 산출물 :
  • 기능 목록, 비즈니스 규칙, 정책, 제약 조건 등

2️⃣ 시스템 아키텍처 설계서 (어떻게 구조를 잡을 것인가?) 🏗️

• 요구사항이 어느 정도 윤곽을 드러내면 시작됩니다.
• 이유 :
  • 정의된 요구사항을 안정적이고 효율적으로 만족시키기 위해 어떤 기술을 사용하고, 시스템을 어떤 큰 덩어리(모듈, 컴포넌트)로 나눌지 결정해야 합니다.
  • “고객이 원하는 집”을 짓기 위해 어떤 공법(목조, 철근 콘크리트)을 사용할지, 전기/수도 시스템은 어떻게 배치할지 큰 그림을 그리는 단계입니다.
• 산출물 :
  • 기술 스택(Tech Stack), 시스템 구성도, 외부 시스템 연동 방식, 핵심 컴포넌트 설계

3️⃣ 데이터베이스 설계서 (무엇을 저장할 것인가?) 💾

• 요구사항과 아키텍처가 구체화되면서 함께 진행됩니다.
• 이유 :
  • 요구사항에서 필요한 데이터(회원, 상품, 주문)가 무엇인지 식별하고, 아키텍처에서 선택한 데이터베이스 기술(RDBMS, NoSQL 등)에 맞춰 데이터를 어떻게 구조화하여 저장할지 설계합니다.
  • “집의 각 공간”에 어떤 가구를 배치하고 수납공간을 어떻게 만들지 구체적으로 설계하는 단계입니다.
• 산출물 :
  • ERD(Entity-Relationship Diagram), 테이블 명세, 인덱스 설계

🛠️ 실무에서의 현실적인 작업 흐름 - 반복적인 작업 (Iteractive Process)

실제 프로젝트에서는 이 세 가지 설계가 퍼즐을 끼워 맞추듯이 순서대로 진행되지 않습니다.
서로가 서로에게 영향을 미치며 함께 발전해 나가는 반복적인(Iteractive) 과정을 거칩니다.

• 1. (요구사항) : “실시간 인기 상품 추천 기능”이라는 요구사항이 나옵니다.
• 2. (아키텍처) : “이 기능을 구현하려면 대용량 데이터를 빠르게 처리해야 하니, 기존 RDBMS 외에 Redis 같은 인메모리 데이터베이스를 도입하자”라고 아키텍처 결정에 영향을 줍니다.
• 3. (데이터베이스) : Redis를 사용하기로 했으므로, “실시간 인기(랭킹) 데이터를 어떤 구조(예: Sorted Set)로 저장할지” 구체적인 데이터 설계를 진행합니다.
• 4. (다시 요구사항) : 설계를 하다 보니, “추천 상품을 사용자 그룹별로 다르게 보여주는 것”이 기술적으로 가능하다는 것을 발견하고, 이를 원래의 요구사항에 역으로 제안하여 기능을 더 풍부하게 만들 수도 있습니다.

🙋‍♂️ 이처럼 세 설계서는 톱니바귀처럼 맞물려 돌아가며, 프로젝트가 진행됨에 따라 함께 구체화되고 상세해집니다.

⭐️ Important Advice.

• 각 설계 단계를 “완벽” 하게 끝내고 다음으로 넘어가려는 생각보다는, 핵심적인 내용을 먼저 정의하고 개발을 진행하면서 필요한 부분을 계속해서 구체화하고 개선해 나가는 애자일(Agile)한 접근 방식이 현대 소프트웨어 개발 환경에 더 적합합니다.

🥴 Made By Team WAN / BMC Crew