CS 과제 정리

[CS] PRD, ERD, UCD 및 API 명세서: 제품 개발과 디자인 문서의 이해

thisnorm 2025. 2. 2. 18:07

 

📌PRD(제품 요구 사항 문서)란?

PRD는 제품 개발 과정에서 요구되는 기능과 특성을 명확히 정의하는 문서이다. PRD는 팀과 이해관계자 간의 공통된 이해를 돕고, 제품의 목표와 방향성을 제시하는 데 중요한 역할을 한다.

https://www.agilealliance.org/glossary/user-story-template/

 

User Story Templates in Agile

The user story template is one of the most commonly recommended aids to write user stories: As a ... I want ... So that ...

www.agilealliance.org

 

 

사용자 스토리 템플릿

PRD 작성 시 사용자 스토리 템플릿이 유용하게 사용된다. 사용자 스토리는 제품이 어떤 기능을 제공해야 하는지를 설명하는 간단한 형식으로, 일반적으로 다음과 같은 구조를 따른다:

  • "As a… I want to… So That…" 형식으로 작성된다.
  • 예시:
  • 역할: 은행 고객으로서
  • 기능: ATM에서 돈을 인출하고 싶습니다.
  • 목적: 영업시간이나 창구 대기열에 얽매이지 않도록.

이 템플릿은 제품이 "무엇"을 하는지, "누구를 위해" 하는지, 그리고 "어떤 목표"를 추구하는지를 명확히 하는 데 도움을 준다.

 

 

 

기대되는 이점

  • 사용자 스토리 템플릿은 팀이 제품의 기능을 정의하고, 사용자 요구를 이해하는 데 도움을 준다.
  • 이 템플릿은 대화의 출발점이 되어, 팀원 간의 소통을 촉진하고, 제품 개발의 방향성을 명확히 한다.

 

 

 

일반적인 함정

  • 초보 팀은 사용자 스토리 형식을 암기적으로 적용하는 경향이 있다. 그러나 이러한 형식은 체크리스트로 사용되기보다는 보다 유연하게 표현하는 것이 중요하다.
  • 사용자 스토리의 세부 사항은 팀원 간의 대화에서 발생하므로, 템플릿에 지나치게 얽매이는 것은 비효율적일 수 있다.

 

 

 

PRD의 역사

  • 사용자 스토리의 "역할-기능-이유" 형식은 2001년 영국의 Connextra에서 발명되었다.

 

 

📌ERD란?

ERD(엔티티 관계 다이어그램)는 시스템 내에서 "엔티티"가 서로 어떻게 관계되는지를 나타내는 일종의 플로우차트이다. 주로 소프트웨어 공학, 비즈니스 정보 시스템, 교육 및 연구 분야에서 관계형 데이터베이스를 설계하거나 디버깅하는 데 사용된다. ERD는 사각형, 다이아몬드, 타원 및 연결선과 같은 정의된 기호 세트를 사용하여 엔티티, 관계 및 속성 간의 상호 연결성을 나타낸다.

 

ERD의 역사

ER 모델은 1970년대에 피터 첸(Peter Chen)에 의해 개발되었으며, 그의 논문 "The Entity-Relationship Model: Toward a Unified View of Data"에서 처음 소개되었다. 이후 여러 연구자들이 ER 모델을 발전시켜 오늘날의 데이터베이스 설계에 기여하였다.

 

 

 

ERD의 용도

  1. 데이터베이스 설계: ERD는 관계형 데이터베이스를 모델링하고 설계하는 데 사용된다.
  2. 데이터베이스 문제 해결: 기존 데이터베이스를 분석하여 논리적 문제를 찾고 해결하는 데 도움을 준다.
  3. 비즈니스 정보 시스템: 비즈니스 프로세스에서 사용되는 관계형 데이터베이스를 설계하거나 분석하는 데 유용하다.
  4. 교육 및 연구: 데이터 구조를 계획하고 분석하는 데 중요한 역할을 한다.

 

 

 

ERD의 구성 요소

  1. 엔티티: 데이터가 저장될 수 있는 정의 가능한 사물(예: 고객, 학생 등)로, 일반적으로 사각형으로 표시된다.
  2. 관계: 엔티티 간의 상호 작용을 나타내며, 일반적으로 다이아몬드로 표시된다.
  3. 속성: 엔티티의 특성이나 속성을 나타내며, 타원으로 표시된다.
  4. 카디널리티: 두 엔티티 간의 관계의 수적 속성을 정의하며, 1:1, 1:N, N:M 관계로 구분된다.

 

 

 

ERD 작성 방법

  1. 목적 및 범위 정의: 분석하거나 모델링할 목적과 범위를 정의한다.
  2. 엔티티 식별: 관련된 엔티티를 식별하고 사각형으로 그린다.
  3. 관계 결정: 엔티티 간의 관계를 결정하고 선으로 연결한다.
  4. 속성 추가: 엔티티의 주요 속성을 추가한다.
  5. 카디널리티 표시: 관계의 카디널리티를 나타낸다.

 

 

 

📌카디널리티(Cardinality)란?

엔티티 간의 관계에서 숫자적 속성을 정의하는 개념이다. 이는 두 엔티티 또는 엔티티 집합 간의 관계가 얼마나 많은 인스턴스를 포함하는지를 나타낸다. 카디널리티는 주로 다음과 같은 세 가지 주요 유형으로 구분된다

1. 일대일(One-to-One)

  • 정의: 한 엔티티의 인스턴스가 다른 엔티티의 인스턴스와 정확히 하나의 관계를 가지는 경우이다.
  • 예시: 한 학생이 하나의 학생증을 가지고 있는 경우.

 

2. 일대다(One-to-Many)

  • 정의: 한 엔티티의 인스턴스가 여러 개의 다른 엔티티의 인스턴스와 관계를 가질 수 있는 경우이다.
  • 예시: 한 고객이 여러 개의 주문을 할 수 있는 경우.

 

3. 다대다(Many-to-Many)

  • 정의: 여러 개의 엔티티 인스턴스가 서로 여러 개의 인스턴스와 관계를 가질 수 있는 경우이다.
  • 예시: 여러 학생이 여러 과목에 등록할 수 있는 경우.

 

카디널리티의 표현

카디널리티는 ER 다이어그램에서 관계의 양쪽에 기호를 사용하여 표시된다. 이러한 기호는 관계의 최소 및 최대 수를 나타내며, 관계의 성격을 명확히 이해하는 데 도움을 준다.

카디널리티는 데이터베이스 설계에서 중요한 요소로, 데이터의 구조와 관계를 명확히 하고, 데이터 무결성을 유지하는 데 기여한다.

 

 

 

ERD의 한계

  • 관계형 데이터에만 적합하다.
  • 비구조적 데이터에는 한계가 있다.
  • 기존 데이터베이스와 통합하는 데 어려움이 있을 수 있다.

 

 

📌UCD(User-Centered Design)란?

UCD는 사용자의 필요와 요구를 중심으로 하는 반복적인 디자인 프로세스이다. UCD의 주요 목표는 사용자가 실제로 사용할 수 있고 접근 가능한 제품을 만드는 것이다. 이 과정에서 디자인 팀은 다양한 연구 및 디자인 기법을 통해 사용자를 지속적으로 참여시킨다.

UCD의 주요 요소

  1. 반복적 프로세스: UCD는 네 가지 주요 단계로 구성된다.
  • 이해: 사용자가 시스템을 사용할 맥락을 이해한다.
  • 요구 사항 식별: 사용자의 요구 사항을 정의한다.
  • 디자인: 해결책을 개발하는 디자인 단계이다.
  • 평가: 디자인의 성과를 평가하여 사용자의 요구와 맥락에 얼마나 잘 부합하는지를 확인한다. 이 과정을 반복하여 최적의 결과를 도출한다.

 

2. 전체 사용자 경험 고려: UCD는 사용자의 작업과 환경에 대한 명확한 이해를 바탕으로 전체 사용자 경험을 포착하고 해결하는 것을 목표로 한다. 이를 위해 다양한 분야의 전문가와 이해관계자, 사용자들이 팀에 포함되어야 한다.

 

 

3. 사용자 참여의 중요성: 사용자를 디자인 과정의 모든 단계에 포함시키는 것은 제품이 사용자의 기대와 요구를 충족할 가능성을 높인다. 이는 판매 증가와 고객 서비스 비용 절감으로 이어질 수 있다.

 

 

4. UCD의 이점:

  • 사용자 요구에 맞춘 제품 개발로 인한 판매 증가.
  • 특정 맥락과 작업에 맞춘 시스템 설계로 인한 인적 오류 감소.
  • 사용자와의 밀접한 접촉을 통한 공감대 형성.
  • 다양한 문화와 인간 가치를 인식하여 지속 가능한 비즈니스로 나아가는 단계.

 

 

UCD는 사용자의 피드백을 통해 디자인을 조정하고 개선하는 강력한 방법론으로, 제품의 사용성과 접근성을 높이는 데 기여한다.

 

 

 

📌API 명세서란?

API 명세서는 API의 기능, 구조, 사용 방법 등을 정의하는 문서로, 개발자와 사용자 간의 원활한 소통을 돕는다. OpenAPI Specification (OAS)은 HTTP API에 대한 표준화된 인터페이스를 제공하며, 이를 통해 사용자는 API의 기능을 이해하고 상호작용할 수 있다.

https://swagger.io/specification/

 

OpenAPI Specification - Version 3.1.0 | Swagger

OpenAPI Specification Version 3.1.1 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RF

swagger.io

 

 

OpenAPI 명세서

OpenAPI 명세서는 API의 표면과 의미를 공식적으로 설명하는 문서로, JSON 또는 YAML 형식으로 작성된다. 이 명세서는 다음과 같은 주요 요소로 구성된다:

  1. OpenAPI 문서: OpenAPI 명세서의 기본 단위로, openapi 필드를 포함하여 OAS의 버전을 지정한다. 이 문서는 최소한 하나의 paths, components, 또는 webhooks 필드를 포함해야 한다.
  2. 스키마(Schema): API의 구문과 구조를 형식적으로 설명하는 것으로, OpenAPI 명세서의 형식을 정의한다.
  3. 엔드포인트(Endpoints): API의 기능을 제공하는 URL로, 각 엔드포인트는 HTTP 메서드(GET, POST 등)와 함께 정의된다.
  4. 정보 객체(Info Object): API에 대한 메타데이터를 제공하며, API의 제목, 설명, 버전, 연락처 정보 등을 포함한다.
  5. 구성 요소(Components Object): 재사용 가능한 객체를 정의하여 API의 다양한 측면을 관리한다.

 

 

 

API 명세서의 이점

  • 자동화 도구 지원: API 명세서는 문서 생성, 코드 생성, 테스트 도구 등 다양한 자동화 도구와 통합되어 사용될 수 있다.
  • 명확한 커뮤니케이션: API의 기능과 사용 방법을 명확히 하여 개발자와 사용자 간의 이해를 돕는다.
  • 유지보수 용이: API의 변경 사항을 명세서에 반영함으로써, API의 일관성을 유지하고 관리할 수 있다.

 

 

 

보안 고려사항

API 명세서는 JSON, YAML, JSON Schema를 사용하므로, 이와 관련된 보안 고려사항을 준수해야 한다. 예를 들어, URL 템플릿을 수동으로 구성할 때는 RFC6570에서 정의한 미정의 값을 올바르게 처리해야 한다.

 

 

 

결론

API 명세서는 API의 기능과 구조를 명확히 정의하여 개발자와 사용자 간의 원활한 소통을 지원하며, OpenAPI Specification을 통해 표준화된 형식으로 제공된다. 이를 통해 API의 사용성과 유지보수성을 높일 수 있다.

 

 

 

📌화면 설계서란?

화면 설계서는 사용자 인터페이스(UI)의 구조와 디자인을 정의하는 문서로, 사용자가 소프트웨어나 애플리케이션과 상호작용하는 방식을 시각적으로 표현한다. 이 설계서는 UI 요소의 배치, 색상, 타이포그래피, 아이콘, 모션 등을 포함하여 사용자 경험(UX)을 최적화하는 데 필요한 정보를 제공한다.

 

주요 요소

  1. 디자인 원칙: 화면 설계서는 특정 디자인 원칙을 따르며, 예를 들어 Windows 11의 경우 다음과 같은 원칙이 있다:
  • Effortless: 사용자가 직관적으로 작업을 수행할 수 있도록 설계.
  • Calm: 시각적으로 부드럽고 정돈된 느낌을 제공하여 사용자가 집중할 수 있도록 함.
  • Personal: 사용자의 개별적인 필요와 선호에 맞춰 조정 가능.
  • Familiar: 기존 Windows 환경과의 연속성을 유지하여 학습 곡선을 최소화.
  • Complete + Coherent: 다양한 플랫폼에서 일관된 경험을 제공.

 

2. 디자인 요소:

  • 색상(Color): 사용자에게 시각적 계층과 구조를 제공하여 작업에 집중할 수 있도록 돕는다.
  • 형상과 기하학(Shapes and Geometry): UI 요소의 형태와 크기를 정의하여 전체 디자인의 일관성을 유지한다.
  • 아이콘(Iconography): 사용자 이해를 돕기 위한 시각적 이미지와 기호를 사용한다.
  • 재료(Materials): UI 표면이 실제 물체처럼 보이도록 하는 시각적 효과를 사용하여 환경과의 연결성을 유지한다.
  • 타이포그래피(Typography): 정보 전달을 극대화하기 위해 글꼴과 텍스트 구조를 정의한다.
  • 모션(Motion): 사용자 상호작용에 대한 반응을 제공하여 피드백을 강화하고 공간적 패러다임을 지원한다.

 

 

 

화면 설계서의 중요성

화면 설계서는 개발자와 디자이너 간의 명확한 커뮤니케이션을 가능하게 하며, 최종 사용자에게 직관적이고 일관된 경험을 제공하는 데 필수적이다. 이를 통해 사용자는 소프트웨어를 쉽게 이해하고 사용할 수 있으며, 전체적인 사용자 만족도를 높일 수 있다.

 

 

 

결론

화면 설계서는 UI/UX 디자인의 핵심 요소로, 사용자의 요구와 기대를 충족시키기 위해 다양한 디자인 원칙과 요소를 통합하여 최적의 사용자 경험을 제공하는 데 중점을 둔다.