좋은 설계를 하는법

좋은 설계를 하는 법

설계는 항상 어렵다.

특히 팀 프로젝트를 하다 보면 이런 상황이 반복된다.

• 회의는 많이 하는데 설계가 잘 정리되지 않는다
• ERD를 먼저 그리려고 하면 계속 바뀐다
• 아키텍처를 먼저 잡아야 하는지, 데이터 모델을 먼저 잡아야 하는지 헷갈린다
• 결국 한 사람이 설계 문서를 정리한다

이런 경험들을 정리하면서 좋은 설계를 하는 사고 흐름을 정리해보았다.

---

1. 설계는 혼자 만드는 것이 아니라 구조화하는 것이다

설계는 보통 이런 흐름으로 진행된다.

아이디어 생성        → 팀 전체
논의 / 방향 결정      → 팀 전체
설계 문서 정리       → 담당자 1명
리뷰 및 수정         → 팀 전체

즉 설계는

같이 생각하고
→ 한 사람이 구조화하고
→ 다시 같이 검증한다

여러 사람이 동시에 ERD를 작성하는 경우는 거의 없고,
보통 회의에서 합의된 내용을 기반으로 한 사람이 산출물을 정리한다.

그래서 설계 능력은 단순히 시스템 지식이 아니라

• 구조화 능력
• 문서화 능력
• 토론을 통해 합의를 끌어내는 능력

이기도 하다.

---

2. 설계는 완전히 병렬로 진행되기 어렵다

설계는 서로 강하게 연결된 결정들의 집합이다.

예를 들어

데이터 저장소 → PostgreSQL

이 결정 하나로 다음이 영향을 받는다.

ERD 구조
인덱스 전략
ORM 사용 여부
트랜잭션 전략

그래서 설계 초반에는 보통

큰 결정
→ 팀 합의
→ 다음 설계

처럼 직렬적인 흐름이 발생한다.

하지만 방향이 잡히면 이후 작업은 병렬로 진행된다.

예를 들어

A : 데이터 파이프라인 설계
B : 서비스 ERD 설계
C : API 설계
D : 프론트 화면 설계

즉 설계는 보통

Sync (방향 결정)
↓
Async (각자 설계)
↓
Sync (리뷰)

이 구조로 진행된다.

---

3. 설계를 잘하는 사람들의 사고 흐름

좋은 설계자는 보통 아래 순서로 생각한다.

User Action
↓
Domain
↓
Relationship
↓
Data Flow
↓
Query Pattern
↓
Architecture
↓
Scale / Failure

이 과정을 하나씩 살펴보면 다음과 같다.

---

4. 1단계: 유저 행동 (User Action)

좋은 설계는 항상 여기서 시작한다.

유저가 무엇을 하는가?

예를 들어 Dev Portal 서비스라면

기술을 탐색한다
repo를 확인한다
repo를 저장한다
기술을 구독한다
추천을 받는다

이 단계에서 이미 서비스의 핵심 기능이 드러난다.

---

5. 2단계: 도메인 모델 (Domain)

유저 행동을 보면 자연스럽게 객체가 나온다.

 

User
Repo
Tech
Bookmark
Subscription
Trend

이것이 서비스의 도메인 모델이다.

여기까지 오면 사실 ERD의 절반이 완성된 것이다.

---

6. 3단계: 관계 정의 (Relationship)

이제 객체 간 관계를 만든다.

 

User 1:N Bookmark
Repo 1:N Bookmark
User M:N Tech (구독)

이 단계에서

중간 테이블
로그 테이블

같은 구조가 자연스럽게 나온다.

그리고 이것이 ERD의 기본 형태가 된다.

---

7. 4단계: 데이터 흐름 (Data Flow)

다음 질문은 이것이다.

데이터는 어디서 오는가?

 

GitHub API
뉴스
기술 블로그

그리고 보통 데이터는 이런 흐름을 가진다.

raw data
→ processing
→ serving

 

GitHub API
↓
Raw 데이터 저장
↓
Spark/Hadoop 처리
↓
정제 데이터 생성
↓
서비스 DB 저장

이것이 데이터 파이프라인 설계이다.

---

8. 5단계: 조회 패턴 (Query Pattern)

좋은 설계자는 항상 조회 패턴을 먼저 생각한다.

유저는 어떤 데이터를 조회하는가?

 

트렌드 기술 리스트
repo 상세
추천 repo
저장한 repo

이 단계에서

인덱스
캐시
API 구조

같은 것들이 결정된다.

MongoDB 같은 NoSQL 설계도 사실 이 단계에서 결정된다.

---

9. 6단계: 시스템 구조 (Architecture)

이제 시스템을 나눈다.

 

Frontend
API Server
Service DB
Data Pipeline
Raw Storage

그리고 연결한다.

 

Frontend
   ↓
API Server
   ↓
PostgreSQL

데이터 분석 시스템은 보통 별도로 존재한다.

GitHub API
   ↓
Raw Storage
   ↓
Spark Processing
   ↓
Service DB

이 단계에서 아키텍처 다이어그램이 만들어진다.

---

10. 7단계: 확장과 실패 (Scale / Failure)

마지막 질문은 이것이다.

트래픽이 늘어나면?
데이터가 많아지면?
시스템이 실패하면?

이 단계에서 결정되는 것들

캐시
큐
분산 처리
로그
모니터링

이것이 시스템의 확장성과 안정성을 결정한다.

---

11. 설계의 핵심

많은 개발자는 이렇게 생각한다.

설계 = ERD

하지만 실제로는 그렇지 않다.

설계를 잘하는 개발자는 항상 이것을 먼저 본다.

데이터 흐름

즉

데이터가
어디서 생성되고
어디서 처리되고
어디로 전달되는가

이 흐름을 먼저 이해하면

ERD
아키텍처
API 구조

가 자연스럽게 따라온다.

---

12. 결론

좋은 설계의 핵심은 다음과 같다.

1. 유저 행동에서 시작한다
2. 도메인 모델을 정의한다
3. 관계를 통해 데이터 구조를 만든다
4. 데이터 흐름을 이해한다
5. 조회 패턴을 기준으로 설계한다
6. 시스템 구조를 나눈다
7. 확장성과 실패를 고려한다

그리고 설계는 완벽하게 만드는 것이 아니라 계속 수정하는 과정이다.

좋은 팀은 항상 이렇게 접근한다.

완벽한 설계
→ 오래 걸림

빠른 설계
→ 빠른 피드백
→ 빠른 수정

설계의 목표를 완벽한 정답을 찾는 것이 아니라 빠르게 한바퀴 돌리는 것으로 삼아보자!!!

 

이번 프로젝트 진행하면서 느낀점.

우선 회의를 통해 텍스트가 정의되면 그 내용을 가지고 만들어야 하는 산출물을 한명이 맡아서 초안 가져오고 그걸 피드백 받아서 다시 진행하는 방식이 좋은것 같다.

산출물을 다같이 만들어가는 방식을 사용했는데, 서로 가고자 하는 방향이 중구난방이고, 시간이 효율적으로 쓰이지 못함.