Booil Jung

서브시스템 단위의 효과적인 상세 설계서(SDS) 작성을 위한 종합 가이드

소프트웨어 개발 프로젝트에서 ‘SDS’라는 약어는 두 가지 완전히 다른 개념으로 사용되어 혼선을 빚는 경우가 많다. 이 가이드에서 다루는 SDS는 소프트웨어 상세 설계서(Software Design Specification)를 지칭한다. 이는 소프트웨어 개발 수명주기(SDLC)의 설계 단계에서 요구사항을 실제 구현 가능한 기술적 명세로 변환하는 핵심적인 문서이다.1

이와 혼동될 수 있는 다른 용어는 소프트웨어 정의 스토리지(Software-Defined Storage)이다. 이는 스토리지 관리 소프트웨어를 물리적 하드웨어로부터 분리하여 스토리지 자원을 가상화하고 자동화하는 기술 패러다임을 의미한다.3 이 기술은 데이터센터 인프라 현대화의 중요한 축이지만, 본 가이드에서 다루는 소프트웨어 설계 문서화와는 전혀 다른 분야이다.

이러한 용어의 모호함은 단순히 의미론적인 문제를 넘어, 프로젝트 초기에 팀원 간의 의사소통 오류를 유발하는 실질적인 위험 요소로 작용할 수 있다. 예를 들어, 인프라 엔지니어는 ‘SDS’를 스토리지 솔루션으로 이해하고 관련 기술을 조사하는 반면, 개발팀은 구현을 위한 설계 문서를 기다리는 상황이 발생할 수 있다. 따라서 모든 기술 문서, 특히 SDS의 서두에서는 프로젝트 내에서 사용할 핵심 용어를 명확히 정의하는 용어 정의(Glossary) 섹션을 포함하는 것이 필수적이다. 이는 사소한 절차가 아니라, 프로젝트의 방향성을 통일하고 잠재적 리스크를 사전에 제거하는 중요한 첫걸음이다.5

SDS는 단순한 형식적 문서가 아니며, 성공적인 소프트웨어 개발을 위한 여러 핵심적인 역할을 수행한다.

첫째, SDS는 기술적 청사진(Technical Blueprint)으로 기능한다. 소프트웨어 요구사항 명세서(SRS)가 ‘무엇을(What)’ 만들 것인지를 정의한다면, SDS는 그것을 ‘어떻게(How)’ 만들 것인지를 시스템의 구조, 컴포넌트, 인터페이스, 데이터 모델 등의 관점에서 구체적으로 기술한다.1 이는 추상적인 요구사항과 실제 코드 구현 사이의 논리적 간극을 메우는 필수적인 다리 역할을 한다.7

둘째, SDS는 개발팀을 위한 단일 진실 공급원(Single Source of Truth) 역할을 한다. 복잡한 시스템을 여러 개발자가 협업하여 개발할 때, 각자의 가정이나 해석에 따라 구현이 달라지는 것을 방지한다. 잘 작성된 SDS는 모든 팀원이 동일한 아키텍처와 설계 원칙을 공유하게 하여, 일관성 있고 통합된 결과물을 만들어내는 기반이 된다.8

셋째, SDS는 프로젝트 리스크 관리 도구이다. 설계 단계에서 시스템의 아키텍처, 컴포넌트 간의 상호작용, 데이터 흐름 등을 상세히 모델링하는 과정에서 잠재적인 기술적 문제점, 병목 현상, 설계상의 결함을 조기에 발견할 수 있다. 이를 통해 개발 후반부에 발생할 수 있는 치명적인 오류나 대규모 재작업을 예방하고, 프로젝트의 일정 및 비용 예측 정확도를 높일 수 있다.10

마지막으로, SDS는 시스템의 유지보수성과 확장성을 위한 핵심 자산이다. 시스템이 운영에 들어가면 필연적으로 버그 수정, 기능 개선, 성능 최적화 등의 유지보수 활동이 발생한다. 이때 SDS는 시스템의 구조와 동작 원리를 이해하는 가장 중요한 참조 자료가 된다. SDS 없이는 기존 코드를 분석하는 데 막대한 시간이 소요되며, 변경으로 인한 예기치 않은 부작용(side effect)이 발생할 위험이 커진다.1

독자적인 양식 대신 국제 표준, 특히 IEEE Std 1016-2009를 따르는 것은 SDS의 품질을 보증하는 가장 효과적인 방법이다. 이 표준은 소프트웨어 설계 기술서(Software Design Description, SDD)에 반드시 포함되어야 할 정보와 권장되는 구성을 체계적으로 정의하고 있다.8

표준을 준수함으로써 얻는 이점은 명확하다.

• 품질 및 완전성 보장: 표준은 설계 문서를 작성할 때 놓치기 쉬운 필수 정보들을 체계적으로 요구하므로, 문서의 완전성을 높인다.
• 의사소통 효율 증대: 개발자, QA 엔지니어, 프로젝트 관리자, 유지보수 담당자 등 다양한 이해관계자들은 표준화된 구조의 문서를 통해 필요한 정보를 빠르고 정확하게 찾을 수 있다.6 이는 팀 간의 의사소통 비용을 줄이고 오해의 소지를 없앤다.
• 일관성 유지: 여러 프로젝트나 팀에서 동일한 표준을 사용하면, 조직 전체의 문서화 수준이 상향 평준화되고 일관성이 유지된다.

IEEE 1016 표준의 가장 큰 특징은 단일한 관점에서 설계를 기술하는 것이 아니라, 여러 관점(Viewpoint)을 통해 시스템을 다각적으로 조명한다는 점이다. 이는 “하나의 문서가 모든 사람을 만족시킬 수 없다”는 현실적인 문제에 대한 직접적인 해결책이다. 프로젝트 관리자는 마일스톤에, 데이터베이스 관리자(DBA)는 스키마에, 프론트엔드 개발자는 API 명세에 관심이 있다. 이들의 각기 다른 요구를 하나의 획일적인 문서로 충족시키기는 어렵다.

IEEE 1016은 다음과 같은 핵심 개념을 통해 이 문제를 해결한다.

• 이해관계자(Stakeholders): 설계를 작성, 사용, 평가하는 모든 개인이나 그룹. 개발자, 테스터, 아키텍트, 프로젝트 관리자 등이 해당된다.6
• 관심사(Concerns): 이해관계자가 설계에 대해 갖는 특정 관심 영역. 예를 들어, 성능, 보안, 유지보수성, 기능성, 비용 등이 있다.13
• 관점(Viewpoint): 특정 관심사를 해결하기 위해 설계를 표현하는 방법, 표기법, 모델링 기법의 집합. 즉, 설계 뷰를 작성하기 위한 일종의 ‘템플릿’ 또는 ‘렌즈’이다. 예를 들어, ‘논리적 관점(Logical Viewpoint)’은 시스템의 정적 구조를 클래스 다이어그램으로 표현하도록 규정한다.8
• 뷰(View): 특정 관점에 따라 실제로 작성된 설계의 표현물. 하나의 SDS는 여러 개의 뷰로 구성되며, 각 뷰는 특정 이해관계자의 특정 관심사를 집중적으로 다룬다.8

이 모델을 통해 SDS는 하나의 거대한 문서 덩어리가 아닌, 여러 개의 목표 지향적인 ‘미니 문서’들의 집합으로 구성될 수 있다. 예를 들어, DBA는 ERD와 데이터 사전이 포함된 ‘정보 뷰(Information View)’를 주로 참고하고, 프론트엔드 개발자는 API 명세가 담긴 ‘인터페이스 뷰(Interface View)’를 집중적으로 활용할 수 있다. 이러한 모듈적 접근 방식은 SDS를 훨씬 더 실용적이고 유지보수하기 쉬운 ‘살아있는’ 도구로 만들어 준다.

IEEE 1016-2009 Annex C 6와 업계의 모범 사례 5를 종합하여, 실무에 바로 적용할 수 있는 표준 SDS 목차는 다음과 같다.

• 표지 (Front Matter)
  • 문서 제목, 버전, 상태(초안, 최종), 최종 수정일
  • 작성자, 검토자, 승인자
  • 변경 이력 (Change History)
• 1. 소개 (Introduction)
  • 1.1. 목적 (Purpose): 이 문서가 왜 작성되었는가?
  • 1.2. 범위 (Scope): 이 문서가 다루는 시스템 또는 서브시스템의 경계는 어디까지인가?
  • 1.3. 시스템 컨텍스트 (System Context): 개발될 소프트웨어가 어떤 환경에서 동작하고, 어떤 외부 시스템과 상호작용하는가?
  • 1.4. 참고 자료 (References): 본 문서와 관련된 SRS, 아키텍처 문서, 기술 표준 등
  • 1.5. 용어 정의 (Glossary): 문서 내에서 사용되는 주요 기술 용어, 약어, 개념 정의
• 2. 설계 개요 (Design Overview)
  • 2.1. 시스템 아키텍처 (System Architecture): 고수준 아키텍처 다이어그램과 설명
  • 2.2. 설계 제약사항 및 가정 (Constraints and Assumptions): 기술적, 비즈니스적 제약 조건과 설계의 기반이 된 가정
  • 2.3. 요구사항 추적성 (Requirements Traceability): 요구사항과 설계 항목 간의 연결성
• 3. 설계 뷰 (Design Views)
  • 이 섹션이 SDS의 핵심이며, 서브시스템의 특성에 따라 필요한 뷰를 선택하고 상세하게 기술한다.
  • 3.1. 컨텍스트 뷰 (Context View): 시스템과 외부 사용자/시스템(액터) 간의 관계와 상호작용을 정의.13
  • 3.2. 논리 뷰 (Logical View): 시스템의 정적 구조를 클래스, 인터페이스, 객체 및 그들 간의 관계로 표현.13
  • 3.3. 인터페이스 뷰 (Interface View): 시스템이 외부에 제공하는 API 또는 내부 컴포넌트 간의 인터페이스를 상세히 명세.8
  • 3.4. 정보 뷰 (Information View): 데이터 모델, ERD, 데이터 사전 등 데이터의 구조와 흐름을 기술.8
  • 3.5. 상호작용 뷰 (Interaction View): 특정 시나리오에서 객체 간의 메시지 교환 순서를 시퀀스 다이어그램으로 표현.13
  • 3.6. 알고리즘 뷰 (Algorithm View): 핵심적인 비즈니스 로직이나 복잡한 계산을 의사코드나 순서도로 기술.8
  • 3.7. 리소스 뷰 (Resource View): 시스템이 사용하는 물리적/논리적 리소스(메모리, CPU, 스레드 풀 등)의 관리 방안을 기술.8
• 4. 설계 근거 (Design Rationale)
  • 주요 아키텍처 및 설계 결정에 대한 이유를 설명한다. 고려했던 다른 대안들은 무엇이었으며, 왜 현재의 설계를 선택했는지에 대한 트레이드오프(trade-off) 분석을 포함한다.6 이는 미래에 설계를 변경하거나 평가할 때 매우 중요한 역사적 기록이 된다.
• 부록 (Appendices)
  • 필요한 경우 추가적인 기술 자료나 다이어그램을 첨부한다.

이 섹션에서는 특정 서브시스템에 국한되지 않고, 전체 시스템의 설계 기반을 형성하는 공통적인 요소들을 정의한다.

시스템 아키텍처는 집을 짓기 전의 조감도와 같다. 시스템을 구성하는 주요 컴포넌트(예: 웹 서버, 애플리케이션 서버, 데이터베이스, 메시지 큐)들이 어떻게 배치되고 서로 통신하는지를 고수준에서 보여준다.5

• 아키텍처 다이어그램: C4 모델, 4+1 뷰 모델 등 표준적인 방법을 사용하여 시스템의 논리적, 물리적 구조를 시각적으로 표현한다.
• 아키텍처 스타일: 시스템 전체에 적용된 핵심 아키텍처 패턴을 명시하고 그 선택 이유를 밝힌다. 예를 들어, “본 시스템은 MSA(Microservices Architecture)를 채택하여 각 서비스의 독립적인 개발, 배포, 확장을 용이하게 한다”와 같이 기술한다.
• 주요 기술 스택 및 결정: 프로그래밍 언어(Java, Python), 프레임워크(Spring, Django), 데이터베이스(MySQL, PostgreSQL, MongoDB), 클라우드 플랫폼(AWS, GCP) 등 핵심 기술 스택을 명시한다. 왜 특정 기술이 선택되었는지, 그로 인해 어떤 장점과 단점(trade-offs)이 발생했는지를 명확히 기록하는 것이 중요하다.5

데이터는 현대 애플리케이션의 심장과 같다. 데이터 설계는 데이터가 어떻게 구조화되고, 저장되며, 시스템 내에서 흐르는지를 정의한다.

• 엔티티-관계 다이어그램 (ERD - Entity-Relationship Diagram): ERD는 데이터베이스의 논리적 구조를 시각적으로 표현하는 가장 강력한 도구다. 주요 구성 요소는 다음과 같다.15

  • 엔티티(Entity): 저장해야 할 데이터의 대상. 일반적으로 데이터베이스의 테이블에 해당한다 (예: User, Product, Order).

  • 속성(Attribute): 엔티티가 갖는 속성. 테이블의 컬럼에 해당한다 (예: User 엔티티의 name, email).

  • 관계(Relationship): 엔티티 간의 연관성 (예: User가 Order를 ‘생성한다’).

  • 카디널리티(Cardinality): 관계에 참여하는 인스턴스의 수를 나타낸다 (예: 일대일, 일대다, 다대다).

    ERD는 데이터베이스 설계의 청사진일 뿐만 아니라, 개발자와 비기술적 이해관계자가 데이터 구조에 대해 소통하는 공통 언어 역할을 한다.15

• 데이터 사전 (Data Dictionary): ERD가 데이터의 구조를 시각적으로 보여준다면, 데이터 사전은 각 구성 요소를 텍스트로 상세하게 설명하는 명세서다.18 ERD의 각 테이블과 컬럼에 대해 다음 정보를 포함해야 한다.

  • 테이블/컬럼의 논리명 및 물리명

  • 설명 (비즈니스적 의미)

  • 데이터 타입 (예: VARCHAR(100), INT, TIMESTAMP)

  • 길이/크기

  • 제약 조건 (예: Primary Key, Foreign Key, Not Null, Unique)

  • 기본값 (Default value)

  • 허용되는 값의 범위나 목록

    일관된 명명 규칙을 적용하고, 모든 항목에 대해 명확하고 간결한 설명을 제공하며, 데이터베이스 스키마 변경 시 반드시 함께 업데이트해야 한다.20

컴포넌트나 시스템 간의 상호작용은 인터페이스를 통해 이루어진다. 이 인터페이스의 계약(contract)을 명확히 정의하는 것은 통합 과정에서의 오류를 줄이는 데 매우 중요하다.

• 데이터 교환 형식 (Data Exchange Formats): 데이터 교환 형식의 선택은 성능, 개발 편의성, 시스템 간 상호운용성에 장기적인 영향을 미치는 중요한 아키텍처 결정이다. 가장 널리 사용되는 JSON과 XML의 특징을 이해하고 상황에 맞게 선택해야 한다.

구분 (Feature)	XML (eXtensible Markup Language)	JSON (JavaScript Object Notation)
구문 (Syntax)	태그 기반의 계층적 구조 <tag>value</tag>	키-값 쌍(Key-Value Pairs) 기반 {"key": "value"}
가독성 (Readability)	태그 때문에 장황하지만 구조가 명확함	간결하고 사람이 읽기 쉬움
파싱 성능	일반적으로 DOM/SAX 파서가 필요하며, JSON보다 무거움	특히 JavaScript 환경에서 네이티브 파싱이 매우 빠름
스키마/유효성 검증	DTD, XSD를 통해 강력하고 표준화된 스키마 정의 및 유효성 검증 가능 22	JSON Schema를 통해 가능하지만, XML만큼 표준화되거나 널리 쓰이지는 않음 22
메타데이터 지원	속성(attribute)을 통해 태그에 대한 추가 정보(메타데이터) 표현 용이	기본적으로 지원하지 않음. 별도의 키-값 쌍으로 표현해야 함
파일 크기	태그 때문에 상대적으로 파일 크기가 큼	간결하여 파일 크기가 작음
주요 사용 사례	SOAP 웹 서비스, 복잡한 문서 구조, 설정 파일, 레거시 시스템 연동 23	RESTful API, 웹 애플리케이션, 모바일 앱, 경량 데이터 교환 24

요구사항 추적성은 개발 중인 시스템이 실제로 비즈니스 요구사항을 충족시키고 있음을 증명하는 핵심 활동이다.26 RTM은 모든 비즈니스/기능 요구사항(SRS)과 이를 구현하기 위한 설계 요소, 코드, 테스트 케이스를 명시적으로 연결하는 표이다.

RTM의 가장 큰 가치는 변경 관리(Change Management)에서 드러난다. 특정 요구사항이 변경되었을 때, RTM을 통해 이 변경이 어떤 설계 문서, 어떤 소스 코드 파일, 어떤 테스트 케이스에 영향을 미치는지 즉시 파악할 수 있다.26 이는 변경으로 인한 누락이나 예기치 않은 오류를 방지하고, 변경 작업의 범위를 정확하게 산정하는 데 도움을 준다.

요구사항 ID (Req ID)	요구사항 설명 (Description)	출처 (Source)	SDS 섹션/항목 (SDS Section)	설계 컴포넌트 (Design Component)	테스트 케이스 ID (Test Case ID)	상태 (Status)
REQ-001	사용자는 ID와 비밀번호로 로그인할 수 있어야 한다.	SRS 1.1	3.5 (상호작용 뷰), 4.2 (API 명세)	AuthService, UserController, POST /login API	TC-LOGIN-01, TC-LOGIN-02	Implemented
REQ-002	관리자는 사용자 목록을 조회할 수 있어야 한다.	SRS 1.2	3.3 (인터페이스 뷰), 4.2 (API 명세)	AdminController, UserService, GET /users API	TC-USER-LIST-01	In Progress
REQ-003	모든 비밀번호는 암호화되어 저장되어야 한다.	SRS 2.1 (보안 요구사항)	3.2 (데이터 설계)	User 테이블 password 컬럼, BCryptPasswordEncoder	TC-SECURITY-01	Designed

이 섹션에서는 개별 서브시스템 또는 모듈 내부의 설계를 구체적으로 기술하는 방법을 다룬다.

• UML 클래스 다이어그램 (UML Class Diagram):

  클래스 다이어그램은 객체 지향 설계의 핵심을 이루는 다이어그램으로, 시스템의 정적인 구조와 구성 요소 간의 관계를 명확하게 보여준다.28 잘 그려진 클래스 다이어그램은 그 자체로 개발자에게 훌륭한 구현 가이드가 된다.

  • 클래스와 인터페이스: 시스템의 주요 추상화 단위인 클래스와 인터페이스를 사각형으로 표현한다. 사각형 내부는 이름, 속성(attributes), 행위(methods/operations) 세 부분으로 나뉜다.29
  • 속성과 행위: 클래스가 가지는 데이터(필드)와 수행할 수 있는 동작(메서드)을 명시한다.
  • 가시성(Visibility): 각 속성과 행위 앞에 +(public), -(private), #(protected) 기호를 붙여 접근 제어 수준을 명시함으로써 캡슐화 원칙을 설계에 반영한다.29
  • 관계(Relationships): 클래스 간의 다양한 관계를 선과 화살표로 표현한다.
    • 일반화/상속 (Generalization): ‘is-a’ 관계. 자식 클래스가 부모 클래스의 속성과 행위를 물려받는다.
    • 연관 (Association): 클래스 간의 일반적인 연결. 한 클래스의 인스턴스가 다른 클래스의 인스턴스를 참조한다.
    • 집합 (Aggregation): ‘has-a’ 관계. 전체(whole)와 부분(part)의 관계지만, 생명주기가 독립적이다.
    • 구성 (Composition): 강력한 집합 관계. 부분의 생명주기가 전체에 종속된다.
    • 의존 (Dependency): 한 클래스가 다른 클래스를 사용하는 일시적인 관계.

명확한 API 계약(contract)은 프론트엔드와 백엔드, 또는 마이크로서비스 간의 협업을 원활하게 하는 가장 중요한 요소다. 모호한 API 명세는 통합 단계에서 수많은 버그와 재작업을 유발한다. 따라서 각 API 엔드포인트는 다음 템플릿에 따라 빈틈없이 명세되어야 한다.31

항목	예시
Endpoint	POST /users/{userId}/profile
Description	특정 사용자의 프로필 정보를 생성하거나 업데이트한다. (Idempotent)
Request - Path Parameters	userId (string, UUID): 대상 사용자의 고유 식별자
Request - Body (application/json)	Schema: UserProfile (스키마 정의 참조) Example: json<br>{<br> "nickname": "dev_master",<br> "bio": "Expert software architect",<br> "interests": ["system design", "cloud"]<br>}<br>
Response - 200 OK (application/json)	Description: 성공적으로 프로필이 업데이트되었을 때. 업데이트된 프로필 객체를 반환한다. Schema: UserProfile Example: (요청 본문과 동일)
Response - 400 Bad Request	Description: 요청 본문의 형식이 잘못되었거나 필수 필드가 누락된 경우. Example: json<br>{<br> "error_code": "INVALID_INPUT",<br> "message": "Nickname cannot be empty."<br>}<br>
Response - 404 Not Found	Description: userId에 해당하는 사용자를 찾을 수 없는 경우. Example: json<br>{<br> "error_code": "USER_NOT_FOUND",<br> "message": "User with id... does not exist."<br>}<br>
Authentication	Bearer Token 필요. Admin 또는 Owner 역할(role)만 접근 가능.
Rate Limiting	사용자당 분당 100회 요청으로 제한 (100 requests/minute/user).

• UML 시퀀스 다이어그램 (UML Sequence Diagram):

  정적 구조를 보여주는 클래스 다이어그램과 달리, 시퀀스 다이어그램은 시스템의 동적인 행위를 모델링한다.33 특정 유스케이스나 기능(예: ‘사용자 로그인’, ‘상품 주문’)이 실행될 때, 관련된 객체나 컴포넌트들이 시간의 흐름에 따라 어떤 순서로 메시지를 주고받는지를 시각적으로 보여준다.35

  • 라이프라인(Lifeline): 다이어그램 상단에 위치한 객체를 나타내며, 아래로 뻗은 점선은 해당 객체의 생명선을 의미한다.

  • 메시지(Message): 객체 간의 상호작용. 화살표로 표현되며, 동기(synchronous, 채워진 화살촉) 메시지와 비동기(asynchronous, 열린 화살촉) 메시지를 구분하여 표현할 수 있다.35

  • 활성 상자(Activation Box): 라이프라인 위에 그려진 사각형으로, 해당 객체가 메시지를 처리하느라 활성화된 기간을 나타낸다.

  • 상호작용 프레임(Interaction Frame): loop(반복), alt(대안, if-else), opt(선택, if) 등 복잡한 제어 흐름을 표현하는 데 사용된다.33

    시퀀스 다이어그램은 복잡한 로직을 코딩하기 전에 개발자가 그 흐름을 명확하게 이해하고 잠재적인 문제를 미리 파악하도록 돕는다.37

시스템의 성능이나 비즈니스 로직에 결정적인 영향을 미치는 복잡한 알고리즘은 코드 수준의 상세함으로 설계해야 한다.

• 의사코드 (Pseudocode):

  특정 프로그래밍 언어의 문법에 구애받지 않고, 자연어와 프로그래밍 언어의 중간 형태로 알고리즘의 논리를 단계별로 서술하는 방식이다.38 예를 들어, “만약 사용자의 등급이 ‘VIP’이고 구매 금액이 100달러 이상이면, 10% 할인을 적용한다”와 같은 복잡한 비즈니스 규칙을 명확하게 표현할 수 있다. 의사코드는 개발자가 실제 코드를 작성하기 전에 로직의 정확성을 검토하고 동료와 공유하는 데 매우 효과적이다.

• 순서도 (Flowchart):

  알고리즘의 논리적 흐름을 표준화된 도형(타원형: 시작/종료, 사각형: 처리, 마름모: 판단, 평행사변형: 입/출력)과 화살표를 사용하여 시각적으로 표현하는 방법이다.39 순서도는 특히 조건 분기나 반복문이 많은 복잡한 로직의 흐름을 한눈에 파악하는 데 유용하다. 의사코드와 순서도를 함께 사용하면, 텍스트와 그림을 통해 알고리즘을 이중으로 검증하고 이해도를 높일 수 있다.

SDS는 모든 서브시스템에 동일하게 적용되는 획일적인 문서가 아니다. 서브시스템의 특성에 따라 강조해야 할 설계 요소와 상세화 수준이 달라져야 한다. 프론트엔드 시스템은 사용자 상호작용에, 배치 시스템은 데이터 처리량과 안정성에, API 연동 모듈은 외부 의존성 관리에 초점을 맞춰야 한다. 이처럼 SDS를 적응 가능한 프레임워크로 활용하여, 각 서브시스템의 고유한 문제에 맞는 맞춤형 설계를 제공해야 한다.

프론트엔드 서브시스템의 SDS는 사용자에게 보여지는 화면과 사용자의 상호작용을 중심으로 기술되어야 한다.40

• 사용자 인터페이스(UI) 설계: 단순히 “예쁘게” 만드는 것을 넘어, 각 화면의 구조와 컴포넌트의 역할을 명확히 정의해야 한다. 와이어프레임(wireframe)이나 목업(mockup)을 첨부하여 버튼, 입력 필드, 데이터 테이블 등의 위치, 크기, 상호작용 방식을 시각적으로 보여준다.5
• 사용자 경험(UX) 흐름: 주요 사용자 시나리오(예: 회원가입, 상품 검색, 결제)에 대한 화면의 흐름을 사용자 흐름 다이어그램(User Flow Diagram)으로 표현한다. 이를 통해 사용자가 목표를 달성하기까지의 경로에서 발생할 수 있는 문제점을 미리 파악하고 개선할 수 있다.5
• 상태 관리(State Management) 아키텍처: 현대 프론트엔드 애플리케이션의 복잡성은 상태 관리에서 비롯된다. 서버로부터 받은 데이터, 사용자 입력 값, UI의 현재 상태 등 다양한 상태를 어떻게 관리할지 설계해야 한다. 전역 상태(Global State)와 컴포넌트 지역 상태(Local State)를 구분하고, Redux, MobX, Zustand 등 상태 관리 라이브러리를 사용할 경우 그 구조(스토어, 액션, 리듀서 등)를 다이어그램으로 명확히 설계한다.
• 컴포넌트 설계: 재사용성을 극대화하기 위해 시스템을 컴포넌트 단위로 분해하여 설계한다. 각 컴포넌트가 받는 속성(props)과 부모로 전달하는 이벤트(events)의 명세를 명확히 정의하여 컴포넌트 간의 계약을 수립한다.
• API 연동: 어떤 화면이나 컴포넌트가 어떤 백엔드 API 엔드포인트를 호출하는지, 그리고 API 응답 데이터를 어떻게 화면에 표시하는지를 명확하게 매핑한다.

외부 서비스(Third-party API)에 의존하는 서브시스템은 외부 요인의 불확실성을 관리하는 것이 설계의 핵심이다.

• API 연동 패턴: 외부 API를 직접 호출하는 대신, 중간 계층을 두어 의존성을 관리하는 것이 좋다.
  • Adapter 패턴: 외부 API의 복잡한 인터페이스를 시스템 내부에서 사용하기 쉬운 인터페이스로 변환하는 래퍼(wrapper) 모듈을 만든다. 이를 통해 향후 다른 API로 교체하더라도 시스템 전체의 변경을 최소화할 수 있다.
  • API Gateway 패턴: 여러 개의 외부 또는 내부 마이크로서비스 API를 조합하여 클라이언트에게 단일화된 엔드포인트를 제공한다. 인증, 로깅, 캐싱 등 공통 기능을 이 게이트웨이에서 처리할 수 있다.42
• 오류 처리 및 복원성(Resilience): 외부 API는 언제든지 네트워크 문제, 서버 다운 등의 이유로 실패할 수 있다. 이를 가정하고 시스템이 장애로부터 스스로 회복할 수 있도록 설계해야 한다.44
  • 재시도(Retry) 로직: 일시적인 오류(transient errors)에 대비해, 실패한 API 호출을 즉시 포기하지 않고 일정 간격을 두고 몇 차례 더 시도하는 로직을 구현한다. 이때 Exponential Backoff(실패할수록 재시도 간격을 지수적으로 늘리는 방식) 전략이 효과적이다.44
  • 서킷 브레이커(Circuit Breaker) 패턴: 특정 외부 API에 대한 호출이 지속적으로 실패하면, 전기 회로의 차단기처럼 일시적으로 해당 API 호출 경로를 차단한다. 이를 통해 장애가 발생한 서비스에 불필요한 부하를 주지 않고, 시스템 전체로 장애가 전파되는 것을 막는다.
  • 폴백(Fallback): API 호출이 최종적으로 실패했을 때, 무작정 오류를 반환하는 대신 대체 동작을 정의한다. 예를 들어, 이전에 성공했던 호출 결과를 캐시에서 가져오거나, 기본값 또는 정적인 데이터를 반환하여 사용자 경험의 저하를 최소화한다.44
• 인증 및 보안: API 키, OAuth 토큰과 같은 민감한 인증 정보는 소스 코드에 하드코딩해서는 안 된다. Vault나 AWS Secrets Manager와 같은 보안 저장소에 저장하고, 런타임에 안전하게 불러와 사용하는 방법을 명시해야 한다.5
• 로깅 및 모니터링: 모든 외부 API 요청과 응답, 특히 오류가 발생했을 때의 상태 코드, 요청 파라미터, 응답 본문 등을 상세하게 로깅해야 한다. 이를 통해 문제 발생 시 원인을 신속하게 추적하고 분석할 수 있다.46

배치(Batch) 처리는 대량의 데이터를 정해진 시간에 일괄적으로 처리하는 시스템이다. 설계 시에는 대용량 데이터 처리 성능, 안정성, 운영의 편의성이 핵심 고려사항이다.47

• 아키텍처 개요: 전체 배치 프로세스의 흐름을 데이터 흐름도(Data Flow Diagram)로 표현한다. 데이터가 어디서 와서(Source), 어떤 단계를 거쳐 처리되고(Processing), 최종적으로 어디에 저장되는지(Sink/Target)를 명확히 보여준다.47
• 작업(Job) 및 단계(Step) 정의: 하나의 거대한 배치 로직을 논리적 실행 단위인 Job으로 분할한다. 각 Job은 다시 순차적인 Step으로 세분화된다. 예를 들어, ‘일일 사용자 통계 생성’이라는 Job은 ‘1. 어제 자 사용자 활동 로그 읽기(Read)’, ‘2. 사용자별 활동 집계(Process)’, ‘3. 통계 테이블에 저장(Write)’의 3개 Step으로 구성될 수 있다.49 이러한 구조는 배치 로직을 모듈화하여 개발과 테스트를 용이하게 한다.
• 데이터 처리 방식: 수백만 건 이상의 대용량 데이터를 한 번에 메모리에 올리는 것은 메모리 초과(Out of Memory) 오류를 유발한다. 이를 방지하기 위해 데이터를 일정한 크기의 덩어리, 즉 청크(Chunk) 단위로 나누어 읽고, 처리하고, 쓰는 방식으로 설계해야 한다.
• 스케줄링: 배치 Job이 언제, 어떤 조건으로 실행될지를 명시한다. cron 표현식을 사용하여 “매일 오전 3시에 실행” 또는 “매시간 15분에 실행”과 같이 구체적으로 정의한다.
• 오류 처리 및 재시작성(Restartability): 긴 시간 실행되는 배치 Job이 중간에 실패했을 때, 처음부터 다시 실행하는 것은 매우 비효율적이다. 설계 시, 실패한 Step부터 이어서 실행할 수 있는 재시작성을 고려해야 한다. 또한, 특정 레코드의 오류가 전체 Job의 실패로 이어지지 않도록, 특정 예외는 로깅만 하고 건너뛰는 건너뛰기(Skip) 정책도 정의할 수 있다.

• 로깅 및 모니터링: 각 Job과 Step의 시작 시간, 종료 시간, 총 실행 시간, 읽은 레코드 수, 처리된 레코드 수, 실패 및 건너뛴 레코드 수 등을 상세히 로깅해야 한다. 이는 배치 작업의 성공 여부를 판단하고, 성능 병목을 분석하며, 데이터 정합성을 검증하는 데 필수적인 정보다.47

• 명확성 및 간결성 (Clarity and Conciseness): 기술 문서는 소설이 아니다. 복잡한 기술 용어나 내부에서만 통용되는 약어(jargon)의 사용을 최소화해야 한다. 불가피하게 사용해야 할 경우, 문서 서두의 용어 사전에 반드시 정의해야 한다. 모든 팀원이, 심지어 프로젝트에 새로 합류한 사람도 쉽게 이해할 수 있도록 평이하고 명확한 문장으로 작성하는 것이 중요하다.5
• 일관성 (Consistency): 문서 전체에 걸쳐 용어, 표기법, 다이어그램 스타일, 포맷팅을 일관되게 유지해야 한다. 예를 들어, 어떤 곳에서는 ‘사용자’라고 하고 다른 곳에서는 ‘고객’이라고 쓴다면 혼란을 유발한다. 일관성은 문서의 전문성과 가독성을 높이는 기본 요소다.5
• 시각화 (Visualization): “백문이 불여일견”이라는 말처럼, 복잡한 시스템 구조, 데이터 흐름, 컴포넌트 간의 상호작용은 글만으로 설명하기 어렵다. UML 다이어그램, ERD, 순서도, 아키텍처 다이어그램 등 시각적 자료를 적극적으로 활용하여 이해를 돕는 것이 매우 효과적이다.5
• 살아있는 문서 (Living Document): SDS는 프로젝트 초기에 한 번 작성하고 방치되는 ‘죽은 문서’가 되어서는 안 된다. 소프트웨어 설계는 프로젝트가 진행됨에 따라 필연적으로 변경되고 개선된다. 이러한 변경 사항이 즉시 SDS에 반영되어, 문서가 항상 현재 시스템의 상태를 정확하게 나타내도록 유지해야 한다. 이를 위해 Confluence와 같은 위키 시스템이나, 코드와 함께 Git 저장소에서 마크다운 형식으로 문서를 관리하는 것이 효과적이다.5

소프트웨어 설계 과정에서 흔히 발생하는 실수들은 서로 연결되어 ‘기술 부채의 악순환’을 만드는 경향이 있다. 예를 들어, 불분명한 요구사항은 필연적으로 설계 결함으로 이어진다. 개발자는 이 결함을 메우기 위해 과도하게 복잡한 해결책이나 임시방편적인 ‘땜질’ 코드를 작성하게 된다. 이는 코드의 유지보수성을 떨어뜨리고, 결과적으로 문서 업데이트를 소홀히 하게 만든다. 이 악순환은 기술 부채와 지식의 파편화를 낳아 미래의 개발을 더디고 위험하게 만든다. 이러한 함정을 피하는 것은 개별 실수를 수정하는 것을 넘어, 이 부정적인 피드백 고리를 끊는 총체적인 전략을 요구한다.

• 불분명한 요구사항에서 시작된 설계: 요구사항이 모호하면 설계도 모호해질 수밖에 없다. “사용자 친화적인 인터페이스”와 같은 추상적인 요구사항은 설계의 기반이 될 수 없다. 설계에 착수하기 전에 PM이나 기획자와의 긴밀한 소통을 통해 모든 요구사항을 구체적이고 측정 가능하며 테스트 가능한 수준으로 명확히 해야 한다.53 RTM을 작성하는 과정 자체가 요구사항의 모호성을 검증하는 좋은 기회가 된다.
• 과도한 복잡성 (Over-engineering): 미래의 모든 가능성을 예측하여 지나치게 유연하고 복잡한 설계를 하는 것은 종종 불필요한 비용과 시간을 낭비하게 한다. “YAGNI (You Ain’t Gonna Need It, 당신은 그것이 필요하지 않을 것이다)”와 “KISS (Keep It Simple, Stupid)” 원칙을 항상 기억해야 한다. 현재의 명확한 요구사항을 해결하는 가장 단순한 설계를 우선하고, 미래의 확장은 필요할 때 리팩토링을 통해 대응하는 것이 더 효율적이다.53
• 유지보수성 무시: 당장의 구현 편의성에만 집중하여 미래의 변경 용이성을 고려하지 않는 설계는 최악의 기술 부채를 남긴다. 설계 단계에서부터 모듈화, 낮은 결합도(Low Coupling), 높은 응집도(High Cohesion)와 같은 객체 지향 설계 원칙(SOLID)을 철저히 준수해야 한다. 이는 변경의 영향 범위를 최소화하고, 코드를 이해하고 수정하기 쉽게 만들어 장기적인 유지보수 비용을 절감한다.53
• 성능 및 보안 간과: 성능과 보안은 개발 막바지에 추가할 수 있는 기능이 아니다. 설계 초기 단계부터 시스템의 성능 목표(예: 응답 시간, 처리량)와 보안 요구사항(예: 데이터 암호화, 접근 제어, 입력값 검증)을 명시하고 아키텍처에 반영해야 한다. 나중에 이를 해결하려면 아키텍처 자체를 변경해야 하는 대규모 작업이 될 수 있다.53

잘 작성된 설계는 엄격한 검토 과정을 통해 완성된다.

• 동료 검토 (Peer Review): 작성된 SDS는 반드시 다른 시니어 개발자나 아키텍트의 검토를 거쳐야 한다. 제3자의 객관적인 시각은 작성자가 미처 발견하지 못한 설계의 논리적 오류, 불일치, 누락, 비효율적인 부분을 찾아내는 데 매우 효과적이다.
• 이해관계자 피드백: 개발팀 외부의 관련 이해관계자(프로젝트 관리자, 기획자, QA팀)에게도 문서를 공유하고 피드백을 받아야 한다. 이를 통해 설계가 비즈니스 요구사항을 올바르게 해석하고 반영했는지, 그리고 테스트 가능한 형태로 설계되었는지를 검증할 수 있다.
• 버전 관리 (Version Control): SDS 문서는 소스 코드와 마찬가지로 Git과 같은 버전 관리 시스템을 통해 관리되어야 한다. 모든 변경 사항에 대해 “누가, 언제, 무엇을, 왜” 변경했는지를 명확히 알 수 있도록 의미 있는 커밋 메시지를 작성하는 습관이 중요하다.53 이를 통해 변경 이력을 추적하고, 필요한 경우 이전 버전으로 쉽게 되돌아갈 수 있다.

본문 II-2.3에서 제시한 구조를 기반으로 한 마크다운 형식의 템플릿은 다음과 같다. 이 템플릿을 프로젝트의 Git 저장소에 DESIGN.md 파일로 포함하여 관리할 수 있다.

# [프로젝트/서브시스템 명] 소프트웨어 상세 설계서 (SDS)

- **Version:** 1.0
- **Status:** Draft
- **Last Updated:** YYYY-MM-DD
- **Author(s):** [작성자 이름]
- **Reviewer(s):** [검토자 이름]

------

### 변경 이력

| 버전 | 날짜       | 작성자 | 변경 내용      |
| ---- | ---------- | ------ | -------------- |
| 1.0  | YYYY-MM-DD | [이름] | 초안 작성      |
| 0.9  | YYYY-MM-DD | [이름] | 검토 의견 반영 |

------

### 1. 소개

#### 1.1. 목적

#### 1.2. 범위

#### 1.3. 시스템 컨텍스트

#### 1.4. 참고 자료

#### 1.5. 용어 정의

### 2. 설계 개요

#### 2.1. 시스템 아키텍처

#### 2.2. 설계 제약사항 및 가정

#### 2.3. 요구사항 추적성 매트릭스 (RTM)

### 3. 설계 뷰

#### 3.1. 컨텍스트 뷰

#### 3.2. 논리 뷰 (클래스 다이어그램 등)

#### 3.3. 인터페이스 뷰 (API 명세 등)

#### 3.4. 정보 뷰 (ERD, 데이터 사전 등)

#### 3.5. 상호작용 뷰 (시퀀스 다이어그램 등)

#### 3.6. (기타 필요한 뷰...)

### 4. 설계 근거

- 주요 설계 결정 사항과 그 이유, 고려된 대안, 트레이드오프 분석을 기술한다.

### 부록

- (필요 시 추가 자료 첨부)

### B. 상세 설계 검토를 위한 체크리스트

SDS 초안이 완료되면, 아래 체크리스트를 사용하여 자체 검토 및 동료 검토를 진행한다. 이는 설계의 품질을 한 단계 높이는 데 도움이 된다.56

**[완전성 (Completeness)]**

- [ ] 모든 기능적/비기능적 요구사항이 설계에 반영되었는가? (RTM 참조)
- [ ] 모든 외부 인터페이스(API, UI)가 명확하게 정의되었는가?
- [ ] 데이터 모델(ERD, 데이터 사전)이 모든 영속성 데이터를 포함하는가?
- [ ] 오류 처리 및 예외 상황에 대한 설계가 모든 주요 시나리오에 대해 기술되었는가?
- [ ] 로깅, 모니터링, 알림에 대한 계획이 포함되었는가?

**[일관성 (Consistency)]**

- [ ] 문서 전체에서 용어, 표기법, 다이어그램 스타일이 일관적인가?
- [ ] 각 설계 뷰(View) 간에 내용이 서로 모순되지 않는가? (예: 클래스 다이어그램의 메서드가 시퀀스 다이어그램의 메시지와 일치하는가?)
- [ ] 설계가 상위 아키텍처 원칙 및 가이드라인을 준수하는가?

**[명확성 (Clarity)]**

- [ ] 제3자가 문서를 읽고 시스템의 구조와 동작을 명확하게 이해할 수 있는가?
- [ ] 모호하거나 여러 가지로 해석될 수 있는 표현은 없는가?
- [ ] 모든 다이어그램에 충분한 설명과 범례가 제공되었는가?

**[실현 가능성 및 품질 (Feasibility & Quality)]**

- [ ] 제안된 설계가 현재의 기술 스택과 팀의 역량으로 구현 가능한가?
- [ ] 성능, 확장성, 보안, 안정성 등 비기능적 요구사항을 만족시키는 설계인가?
- [ ] 설계가 유지보수와 테스트 용이성을 고려하여 모듈화되었는가? (낮은 결합도, 높은 응집도)
- [ ] 설계 결정에 대한 근거와 트레이드오프가 합리적으로 설명되었는가?

1. 소프트웨어 문서 - Lina’s Toolbox - 티스토리, accessed July 29, 2025, https://kimwoolina.tistory.com/51
2. SRS,SDS,SCS - rockpell’s blog, accessed July 29, 2025, https://rockpell.github.io/SRS,SDS,SCS/
3. 소프트웨어 정의 스토리지(SDS)란? - Simplyblock, accessed July 29, 2025, https://www.simplyblock.io/ko/blog/what-is-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%A0%95%EC%9D%98-%EC%8A%A4%ED%86%A0%EB%A6%AC%EC%A7%80-sds/
4. 소프트웨어 정의 스토리지(SDS)란 무엇인가요? - IBM, accessed July 29, 2025, https://www.ibm.com/kr-ko/think/topics/software-defined-storage

5. Software Design Document [Tips & Best Practices]

   The Workstream - Atlassian, accessed July 29, 2025, https://www.atlassian.com/work-management/knowledge-sharing/documentation/software-design-document

6. IEEE Std 1016-2009 (Revision of IEEE Std 1016-1998), IEEE …, accessed July 29, 2025, https://cengproject.cankaya.edu.tr/wp-content/uploads/sites/10/2017/12/SDD-ieee-1016-2009.pdf
7. Specification(SRS) 쉽게 이야기하기 - 둥그런 일상 - 티스토리, accessed July 29, 2025, https://circlezoo.tistory.com/30
8. Software design description - Wikipedia, accessed July 29, 2025, https://en.wikipedia.org/wiki/Software_design_description
9. How To Write an Excellent Software Design Document - Scribe, accessed July 29, 2025, https://scribehow.com/library/software-design-document
10. 소프트웨어 개발 수명 주기(SDLC)란 무엇인가요? - AWS, accessed July 29, 2025, https://aws.amazon.com/ko/what-is/sdlc/

11. IEEE Std 1016 - IEEE Standard for Information Technology-Systems Design - Software Design Descriptions

    SE Goldmine, accessed July 29, 2025, https://segoldmine.ppi-int.com/node/45349

12. IEEE Recommended Practice For Software Design Descriptions - IEEE Std 1016-1998, accessed July 29, 2025, http://dslab.konkuk.ac.kr/Class/2010/10SE/Reading%20Log/IEEE%20Standard%201016-1998%20-%20Recommended%20Practice%20for%20Software%20Design%20Descriptions.pdf
13. Software Design Descriptions (SDD), accessed July 29, 2025, https://wildart.github.io/MISG5020/SDD.html
14. How to write a good software design doc - Medium, accessed July 29, 2025, https://medium.com/free-code-camp/how-to-write-a-good-software-design-document-66fcf019569c
15. Entity Relationship Diagram: ERD Basics Explained - Atlassian, accessed July 29, 2025, https://www.atlassian.com/work-management/project-management/entity-relationship-diagram
16. What is an Entity Relationship Diagram (ERD)? - Lucidchart, accessed July 29, 2025, https://www.lucidchart.com/pages/er-diagrams
17. What is an Entity Relationship Diagram? - IBM, accessed July 29, 2025, https://www.ibm.com/think/topics/entity-relationship-diagram
18. 데이터 사전, accessed July 29, 2025, https://help.blackboard.com/ko-kr/Anthology_Illuminate/Developer/Data_Dictionary

19. Data Dictionaries

    U.S. Geological Survey - USGS.gov, accessed July 29, 2025, https://www.usgs.gov/data-management/data-dictionaries

20. Data Dictionary Best Practices - Secoda, accessed July 29, 2025, https://www.secoda.co/learn/data-dictionary-best-practices
21. Data Dictionary: Examples, Templates, & Best practices - Atlan, accessed July 29, 2025, https://atlan.com/what-is-a-data-dictionary/
22. XML vs JSON: A Comprehensive Comparison - Leapcell, accessed July 29, 2025, https://leapcell.io/blog/xml-vs-json-a-comprehensive-comparison
23. JSON vs. XML: Comparing Popular Data Exchange Formats - Hostman, accessed July 29, 2025, https://hostman.com/tutorials/json-vs-xml/
24. EDI vs. XML vs. JSON: The Ultimate Guide to Structured Data for Business Integration, accessed July 29, 2025, https://www.edi2xml.com/blog/edi-vs-xml-vs-json-the-ultimate-guide-to-structured-data-for-business-integration/

25. Web Data Serialization - JSON, XML, YAML & More Explained

    Beeceptor, accessed July 29, 2025, https://beeceptor.com/docs/concepts/data-exchange-formats/

26. Requirements Traceability - HHS.gov, accessed July 29, 2025, https://www.hhs.gov/sites/default/files/ocio/eplc/EPLC%20Archive%20Documents/24%20-%20Requirements%20Traceability%20Matrix/eplc_requirements_traceability_practices_guide.pdf
27. What are the Traceability Relationships Between SSS/SSDD/SRS? - PPI, accessed July 29, 2025, https://www.ppi-int.com/resources/systems-engineering-faq/what-are-the-traceability-relationships-between-sss-ssdd-srs/
28. Unified Modeling Language (UML) - Class Diagram - GeeksforGeeks, accessed July 29, 2025, https://www.geeksforgeeks.org/system-design/unified-modeling-language-uml-class-diagrams/
29. UML Class Diagram Tutorial - Visual Paradigm, accessed July 29, 2025, https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
30. [정보처리기사] UML 다이어그램 (클래스, 컴포넌트, 객체, 패키지, 유즈케이스, 행동, 상태, 시퀀스 다이어그램) - 원하는 것을 만드는 수단, accessed July 29, 2025, https://myallinone.tistory.com/entry/UML-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8-%ED%81%B4%EB%9E%98%EC%8A%A4-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8-%EA%B0%9D%EC%B2%B4-%ED%8C%A8%ED%82%A4%EC%A7%80-%EC%9C%A0%EC%A6%88%EC%BC%80%EC%9D%B4%EC%8A%A4-%ED%96%89%EB%8F%99-%EC%83%81%ED%83%9C-%EC%8B%9C%ED%80%80%EC%8A%A4-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8
31. How to Write API Documentation: a Best Practices Guide - Stoplight, accessed July 29, 2025, https://stoplight.io/api-documentation-guide
32. API documentation Collection Template - Postman, accessed July 29, 2025, https://www.postman.com/templates/collections/api-documentation/
33. UML 2 Tutorial - Sequence Diagram - Sparx Systems, accessed July 29, 2025, https://sparxsystems.com/resources/tutorials/uml2/sequence-diagram.html
34. Sequence Diagrams - Unified Modeling Language (UML) - GeeksforGeeks, accessed July 29, 2025, https://www.geeksforgeeks.org/system-design/unified-modeling-language-uml-sequence-diagrams/

35. UML Sequence Diagram Tutorial

    Lucidchart, accessed July 29, 2025, https://www.lucidchart.com/pages/uml-sequence-diagram

36. Create a UML sequence diagram - Microsoft Support, accessed July 29, 2025, https://support.microsoft.com/en-us/office/create-a-uml-sequence-diagram-c61c371b-b150-4958-b128-902000133b26
37. CSE 403 Software Design Specification (SDS) - Washington, accessed July 29, 2025, https://courses.cs.washington.edu/courses/cse403/13sp/homework/sds.pdf
38. Advice on writing pseudo code? : r/gamedev - Reddit, accessed July 29, 2025, https://www.reddit.com/r/gamedev/comments/1ikix0e/advice_on_writing_pseudo_code/
39. Pseudocode and Flowchart: Complete Beginner’s Guide - Codecademy, accessed July 29, 2025, https://www.codecademy.com/article/pseudocode-and-flowchart-complete-beginners-guide
40. What’s the Difference Between Frontend and Backend in Application Development? - AWS, accessed July 29, 2025, https://aws.amazon.com/compare/the-difference-between-frontend-and-backend/

41. The Difference Between Front-End vs. Back-End

    ComputerScience.org, accessed July 29, 2025, https://www.computerscience.org/bootcamps/resources/frontend-vs-backend/

42. External API - LEARNCSDESIGN, accessed July 29, 2025, https://www.learncsdesign.com/category/microservices/external-api/

43. Microservices External API Integration Patterns

    by Neeraj Kushwaha - Medium, accessed July 29, 2025, https://learncsdesigns.medium.com/microservices-external-api-integration-patterns-22d1bc866f42

44. Third-Party Integrations: Strategies for Integrating External APIs Seamlessly, accessed July 29, 2025, https://www.refontelearning.com/blog/third-party-integrations-strategies-for-integrating-external-apis-seamlessly
45. Data Pipeline Architecture: Patterns, Best Practices & Key Design Considerations - Estuary, accessed July 29, 2025, https://estuary.dev/blog/data-pipeline-architecture/
46. Microservices Observability Design Patterns - LEARNCSDESIGN, accessed July 29, 2025, https://www.learncsdesign.com/microservices-observability-design-patterns/
47. Data Analytics Lens - AWS Well-Architected Framework, accessed July 29, 2025, https://docs.aws.amazon.com/pdfs/wellarchitected/latest/analytics-lens/analytics-lens.pdf

48. A Story of A Million Rows: Building a Lightweight Batch Pipeline with Temporal and DuckDB

    by Tal Wanish

    Riskified Tech

    May, 2025

    Medium, accessed July 29, 2025, https://medium.com/riskified-technology/a-story-of-million-rows-building-a-lightweight-batch-pipeline-with-temporal-and-duckdb-3c0a8aa88cca

49. 12 Batch Implementation Design Considerations - ECS Solutions, accessed July 29, 2025, https://ecssolutions.com/12-batch-implementation-design-considerations/
50. 7 Best Practices for Creating Clear Software Documentation - Folge.me, accessed July 29, 2025, https://folge.me/blog/7-best-practices-for-creating-clear-software-documentation
51. Knowledge Software Documentation Best Practices [With Examples] - Helpjuice, accessed July 29, 2025, https://helpjuice.com/blog/software-documentation
52. bflorat/architecture-document-template: Product … - GitHub, accessed July 29, 2025, https://github.com/bflorat/architecture-document-template
53. What are the Common Mistakes in Software Development? - Security Compass, accessed July 29, 2025, https://www.securitycompass.com/blog/common-mistakes-in-software-development/
54. Common Challenges Faced in Software Requirements Specification and How to Overcome Them- Your Ultimate Guide! - Practical Logix, accessed July 29, 2025, https://www.practicallogix.com/common-challenges-faced-in-software-requirements-specification-and-how-to-overcome-them-your-ultimate-guide/

55. SSDLC(보안 소프트웨어 개발 수명 주기): 종합 가이드

    스코픽 - Scopic, accessed July 29, 2025, https://scopicsoftware.com/ko/blog/secure-software-development-life-cycle-ssdlc-guide/

56. Design Documentation Checklist

    Manifestly Checklists, accessed July 29, 2025, https://www.manifest.ly/use-cases/software-development/design-documentation-checklist