[25일차]프로젝트 설계 후기, 방법론 정리

1. 프로젝트 설계 회고

이번 북스토어 프로젝트의 전체적인 기능 명세와 UI, 그에 따른 API와 데이터베이스 스키마를 통합적으로 설계하는 과정은 결코 쉽지 않은 경험이었다. 이전까지는 단일 기능을 구현하거나, 강의를 통해 주어진 명세에 따라 코드를 작성하는 데 집중해왔기에, '설계'라는 과정이 이토록 깊은 고민과 통찰을 요구하는지 미처 알지 못했다.

"건축에서 기초 공사가 8할을 차지한다"는 말처럼, 소프트웨어 개발에서도 초기 설계가 프로젝트의 성패를 좌우한다는 것을 체감할 수 있었다. 견고한 설계 없이는 기능 추가나 변경에 유연하게 대처하기 어렵고, 결국 기술 부채로 돌아온다는 사실을 이론이 아닌 현실로 깨닫게 되는 계기가 되었다.

특히 이번 경험을 통해 단순히 코드를 작성하는 '코더(Coder)'를 넘어, 전체 시스템의 청사진을 그리는 '개발자(Developer)'의 역량이 바로 이 설계 단계에서 발현된다는 점을 명확히 인지하게 되었다. 기능의 논리적 흐름을 구체화하고, 데이터의 관계를 정의하며, 각 컴포넌트가 어떻게 상호작용할지를 미리 구상하는 과정이야말로 진정한 개발의 시작이라는 것을 깨닫게 되었다.

개인 프로젝트를 설계하는 것만으로도 이 정도의 어려움을 느꼈는데, 실제 현업에서 고객의 추상적인 요구사항을 명확히 파악하고, 이를 기술적 설계로 변환하며, 지속적으로 조율해나가는 과정이 얼마나 더 높은 수준의 역량을 요구하는지 생각해보게 되는 계기였다. 이번 설계 경험은 앞으로의 개발 여정에서 가장 중요한 자산이 될 것이라 확신한다.

---

2. 효과적인 프로젝트 계획 및 설계를 위한 가이드

프로젝트의 성공은 체계적인 계획과 설계에서 시작된다. 아래는 복잡한 요구사항을 명확한 설계로 변환하고, 좋은 계획서를 작성하기 위한 몇 가지 팁이다.

---

2.1. 좋은 계획서를 작성하는 방법

좋은 계획서는 단순한 기능 나열이 아니라, 프로젝트의 '지도' 역할을 해야 한다.

1. 'Why'에서 시작하기 (프로젝트 목표 명확화)

   • 무엇을: 이 프로젝트가 해결하려는 핵심 문제는 무엇인가?
   • 누구를 위해: 주요 사용자는 누구이며, 그들에게 어떤 가치를 제공하는가?
   • 성공의 기준: 프로젝트가 성공했다고 판단할 수 있는 기준(e.g., 사용자 수, 매출, 재방문율)은 무엇인가?
   • 팁: 목표가 명확하면, 기능의 우선순위를 정하고 팀원들을 설득하기 용이하다.

2. 범위(Scope)를 명확히 정의하기

   • MVP(최소 기능 제품) 정의: 프로젝트의 가장 핵심적인 가치를 전달할 수 있는 최소한의 기능 집합을 정의한다.
   • MoSCoW 기법 활용:
     • Must-have: 없으면 안 되는 필수 기능 (e.g., 회원가입, 도서 조회)
     • Should-have: 필수적이지는 않지만, 포함되면 좋은 중요한 기능 (e.g., 리뷰, 좋아요)
     • Could-have: 있으면 좋지만, 큰 영향은 없는 부가 기능 (e.g., 추천 알고리즘 고도화)
     • Won't-have: 이번 버전에서는 포함하지 않을 기능
   • 팁: "이것도 추가하자"는 유혹에서 벗어나, 정해진 범위에 집중하는 것이 성공의 열쇠다.

3. 단계별 계획(Phase) 수립

   • 전체 프로젝트를 논리적인 단계(Phase 1, Phase 2...)로 나눈다.
   • 각 단계별 목표와 완료해야 할 구체적인 작업(Task) 목록을 작성한다.
   • 팁: 거대한 프로젝트를 작게 나누면 진행 상황을 추적하기 쉽고, 팀원들에게 성취감을 부여할 수 있다.

---

2.2. UI, API, DB를 매끄럽게 설계하는 방법

세 요소는 톱니바퀴처럼 맞물려 돌아가므로, 통합적인 관점에서 설계해야 한다.

1. 사용자 여정(User Journey)에서 시작하기

   • UI, API, DB를 각각 따로 생각하지 말고, 사용자의 행동 흐름을 따라가며 설계한다.
   • 예시: "사용자가 '주문하기' 버튼을 누른다"
     1. UI: '주문하기' 버튼과 주문 정보를 표시할 페이지가 필요하다.
     2. API: 해당 버튼 클릭 시 호출될 POST /api/orders API가 필요하다. 이 API는 배송 정보와 주문할 상품 ID 목록을 받아야 한다.
     3. DB: API가 호출되면, orders 테이블에 새로운 주문 정보를, order_details 테이블에 상품 상세 정보를 기록해야 한다.
   • 팁: 이처럼 하나의 사용자 시나리오를 중심으로 세 요소를 함께 구상하면 설계의 누락이나 비효율을 막을 수 있다.

2. API를 '계약서'처럼 설계하기 (API-First Design)

   • 백엔드와 프론트엔드 개발을 동시에 진행하기 위해, 실제 코드 작성 전에 API 명세부터 확정한다.
   • 이전 대화에서 우리가 만들었던 API 설계 보고서가 바로 이 '계약서' 역할을 한다.
   • 장점: 프론트엔드 팀은 백엔드 개발이 완료될 때까지 기다릴 필요 없이, 확정된 API 명세에 따라 Mock API를 만들어 UI 개발을 진행할 수 있다.

3. 데이터베이스를 '정보의 근원'으로 설계하기

   • UI에 어떤 정보가 필요한지를 먼저 생각하고, 그 정보를 저장할 DB 스키마를 설계한다.
   • 정규화와 비정규화의 균형: 데이터 무결성이 중요하다면 정규화(테이블 나누기)를, 조회 성능이 중요하다면 비정규화(JOIN 줄이기 위해 일부 중복 허용)를 전략적으로 선택한다. 내 주문 목록 조회 API에서 JOIN을 통해 데이터를 조합한 것이 좋은 예시다.

---

2.3. 고객의 요구사항을 효과적으로 개념화하는 방법

고객의 말은 '기능 명세'가 아닌 '기대'와 '문제'에 가깝다. 이를 기술적 설계로 변환하는 것이 핵심이다.

1. 요구사항을 '사용자 스토리' 형식으로 변환하기

   • 고객의 모호한 요청을 구체적인 사용자 관점의 문장으로 재구성한다.
   • 형식: "나는 [사용자 유형]으로서, [어떤 목표]를 위해 [어떤 기능]을 할 수 있으면 좋겠다."
   • 예시:
     • 고객 요청: "책을 좀 더 쉽게 찾게 해주세요."
     • 사용자 스토리: "나는 쇼핑몰 방문자로서, 내가 원하는 분야의 책을 빨리 찾기 위해 카테고리별로 도서를 필터링할 수 있으면 좋겠다."
   • 팁: 사용자 스토리는 개발자가 '왜' 이 기능을 만드는지 이해하게 도와주며, 더 나은 해결책을 제안할 수 있게 한다.

2. 핵심 질문 던지기

   • 고객과의 대화에서 아래 질문들을 통해 숨은 의도와 맥락을 파악한다.
     • "이 기능이 왜 필요하다고 생각하시나요?" (근본적인 문제 파악)
     • "이 기능이 성공적으로 동작했다는 것을 어떻게 알 수 있을까요?" (성공 기준 구체화)
     • "혹시 생각하고 계신 구체적인 화면이나 과정이 있으신가요?" (아이디어 구체화)
     • "만약 이 기능을 가장 단순하게 만든다면 어떤 모습일까요?" (MVP 파악)

3. 시각적 도구 활용하기

   • 복잡한 아이디어는 글보다 그림이 효과적이다.
   • 와이어프레임(Wireframe) 또는 프로토타입(Prototype): 간단한 화면 구성을 그려 고객과 함께 리뷰하면, 서로의 이해도를 높이고 잠재적인 문제를 조기에 발견할 수 있다.
   • 플로우차트(Flowchart): 사용자의 행동 흐름이나 데이터 처리 과정을 다이어그램으로 그려 복잡한 로직을 명확하게 정리한다.

이러한 과정들은 처음에는 번거롭고 어렵게 느껴질 수 있지만, 반복적으로 훈련하면 견고하고 유연한 시스템을 만드는 개발자로 성장하는 데 가장 큰 밑거름이 될 것이다.