개요, 왜 쓸까?

일반적인 서비스 개발에서는 기획 → 디자인 → 백엔드 → 프론트엔드과 같은 순서로 기능을 개발합니다. 기능에 대한 공통의 이해 없이, 각 단계에서 독립적으로 작업을 수행할 경우 필연적으로 놓치는 것들이 생기기 마련입니다. 왜냐하면, 기획자가 생각하는 모든 맥락을 ‘기획서’에 담을 수 없으며 같은 내용을 보고도 사람에 따라 해석의 기준이 다르기 때문입니다.

기존의 탑-다운 방식으로 작업을 수행할 경우, 1) 백엔드 개발이 완료된 시점에서 다시 프론트엔드의 요구에 따라 API를 추가하는 작업이 생길 수도 있고 2) 디자인이 완료된 시점에서 기획자의 요구에 따라 디자인이 추가/ 변경될 수 있습니다. 즉, 불필요한 커뮤니케이션 비용의 증가로 이어집니다.

‘시스템 디자인’은 미국 빅 테크(FAANG) 기업에서 실시하는 인터뷰 전형입니다. 서비스에서 실제로 사용 되는 혹은 개선이 필요한 ‘기능’에 대한 설계를 요구합니다. 이를 통해 지원자의 전반적인 역량을 평가합니다.

이 프로세스는 팀원 간의 ‘**기능에 대한 공통의 이해’**를 형성함으로써 커뮤니케이션 비용을 최소화합니다. 우선, 시스템 디자인이란 무엇인지 알아보고 구체적인 예시를 통해, 어떻게 사용되는지 설명해 보겠습니다.


System Design이란?

시스템 디자인은 아래와 같은 과정을 거칩니다. 각 기능에 대한 예시는 ‘카카오톡 메세지 전송’ 기능을 통해 설명드리겠습니다.

KakaoTalk_Photo_2025-01-17-22-53-42.jpeg

  1. 요구 사항 정의
    1. 기능적 요구 사항
    2. 비기능적 요구 사항
  2. 핵심 Entity 정의
  3. API 설계
  4. 고 수준 설계
  5. 심층 분석

*Data Flow는 상황에 맞게 생략할 수 있기 때문에 뺐습니다.

1. 요구 사항 정의

‘요구 사항’이란 이 기능을 통해 얻고자 하는 바를 말합니다. 요구 사항은 크게 기능적 요구 사항비기능적 요구 사항으로 나뉩니다. 기능적 요구 사항이 비기능적 요구사항 보다 우선 순위가 높습니다.