컴퓨터 원격 서비스

https://youtu.be/eNmE9KqlbIo?si=FHWh0631GWXHTCJq

1. 정보처리기사 자격증 이해와 준비 전략

1-1. 정보처리기사 자격증의 이해
- 정보처리기사 자격증은 IT 시스템 관련 업무 수행 능력을 검증하는 자격증임
- 1년에 3번 시행되며, 졸업 전공과 관계없이 응시 가능함
- 필기 합격률은 절반이 넘고, 실기 합격률은 약 20%를 유지함
- (중요) 자격증은 취업에 가산점 혹은 수당을 제공하는 경우가 많음
- 정보처리기사 자격증은 IT 프로젝트의 전반적인 흐름 이해를 돕는 자격증임

1-2. 정보처리기사 시험의 구성과 평가 방법
- 정보처리기사 시험은 필기와 실기 과목으로 구성되며, 각각 5개 과목과 1개 과목으로 구성됨
- 필기시험은 소프트웨어 설계부터 정보처리 시스템 구축, 관리까지 총 5개 과목으로 이루어짐
- 실기시험은 정보처리 실무라는 1개 과목으로 이루어지며, 객관식과 주관식 문제가 모두 포함됨
- 필기시험은 객관식, 주관식 각각 20문항씩 총 100점 만점임
- (중요) 실기시험은 필기시험의 전과목 평균 60점 이상을 받아야 합격함

1-3. 정보처리기사 시험의 필요성과 중요성
- 정보처리기사 자격증은 IT 산업의 중요한 구성 요소임
- 특히 제조업과 관련 있는 음료수 회사 등의 경우, 정보처리기사 자격증은 필수적인 시스템 관리 역할을 수행함
- 정보처리기사 자격증은 프로젝트의 전반적인 흐름을 이해하고, 이해를 바탕으로 한 문제 해결 능력을 요구함
- 전공자라 하더라도 정보처리기사 자격증을 공부하면 유용한 역량을 갖출 수 있음
- 이외에도 다양한 산업군에서 활용되며, 기업 내에서도 광범위한 지식을 갖추는 데 도움이 됨

2. 소프트웨어 요구사항 확인과 분석

2-1. 소프트웨어 요구사항 확인의 중요성
- 소프트웨어 개발 시, 시스템 분석과 요구사항 확인이 첫 단추를 끼움
- 요구사항 확인은 시스템 개발의 첫 단추로, 요구사항의 명확한 정의를 위해 중요함
- 시스템에 플랫폼, 운영체제, DBMS 등 다양한 요소를 고려해 분석함
- 요구사항 분석을 통해 시스템의 강점과 약점을 파악할 수 있음
- (중요) 요구사항 분석은 개발 비용이 적게 들고, 자료 흐름이 효율적임

2-2. 요구사항 분석의 특징과 고려 사항
- 요구사항 분석은 시스템이 무엇을 해야 하는지 추적하는 과정임
- (중요) 요구사항 분석 후에는 설계, 구현, 테스트, 유지보수 단계로 이어짐
- 개발 기술보다 커뮤니케이션 기술이 중요하며, 고객의 요구를 잘 이해해야 함
- 요구사항 분석은 기능적인 요구사항과 비기능적 요구사항으로 나뉨
- 기능적 요구사항은 시스템이 무엇을 해야 하는지에 초점을 맞춤

2-3. 요구사항 정의와 중요성
- 요구사항 분석 결과를 바탕으로, 사용자의 요구를 추출하고 목표를 정함
- 목표 해결 방식은 사용자의 요구를 충족시키는 방식을 결정함
- 요구사항 정의는 소프트웨어 개발의 출발점이자 실질적인 첫 단계임
- 요구사항 정의는 개발 비용이 적게 들고, 자료 흐름이 효율적임
- (중요) 요구사항 정의는 목표를 충족시키는 방식을 결정하는 중요한 단계임

3. 시스템 요구사항 분석

3-1. 요구사항 분석 개요
- 시스템 요구사항 분석을 통해 개발팀은 시스템이 어떻게 작동해야 하는지 명확히 이해할 수 있음
- 요구사항은 기능적인 측면과 비기능적인 요구 사항으로 나뉨
- 기능적인 요구사항은 시스템이 어떻게 동작해야 하는지에 초점을 맞춤
- 비기능적인 요구 사항은 성능, 품질, 보안 등 시스템의 기능과 밀접한 관련이 있음
- 요구사항 분석을 통해 시스템의 기능과 데이터의 구조를 명확히 정의할 수 있음

3-2. 데이터 흐름도와 자료 사전
- 데이터 흐름도는 데이터가 프로세스를 따라 흐르면서 어떻게 변화하는지 시각적으로 표현함
- 구조적인 분석 기법을 사용하여 데이터의 흐름에 중심을 두고 표현함
- 시간의 흐름을 명확하게 표현하기 어려움
- 데이터 흐름도의 구성 요소는 처리기, 데이터 흐름, 데이터 저장소, 단말임
- (중요) 자료 사전은 시스템이나 데이터베이스에서 사용되는 데이터 요소들의 정의, 속성, 제약, 조건, 관계를 체계적으로 정리한 문서임

3-3. UML 다이어그램
- UML은 객체 지향 소프트웨어 개발 시 산출물을 명세화하고 시각화하기 위한 표준화된 모델링 언어임
- UML은 사물, 관계, 다이어그램의 세 가지 요소로 구성됨
- UML 다이어그램은 구조적 다이어그램과 행위적 다이어그램으로 나뉨
- 구조적 다이어그램은 시스템의 정적 구성 요소와 그들 간의 관계를 표현함
- 행위적 다이어그램은 시스템의 동적인 구성 요소와 그들 간의 관계를 보여줌

4. 소프트웨어 개발 및 다이어그램 모델의 이해

4-1. 다이어그램의 종류 및 유즈 케이스 다이어그램의 구성 요소
- 소프트웨어 개발에서 사용하는 다이어그램에 대해 설명함
- 행위적 다이어그램과 동적 다이어그램의 개념과 차이점을 설명함
- 유즈 케이스 다이어그램이 시스템의 기능과 사용자 상호작용을 표현하는 데 활용됨
- 유즈 케이스 다이어그램의 구성 요소로 시스템, 사용자, 경계를 포함함
- (중요) 맨션 기능을 유즈 케이스로 설정하여 상호작용을 표현함

4-2. 유즈 케이스 다이어그램의 활용 예시
- 맨션 기능을 유즈 케이스로 설정하여 상호작용을 표현하는 예시를 제시함
- (중요) 일반화를 활용하여 상품권과 구매하기의 예를 들어 설명함
- 시퀀스 다이어그램의 구성 요소인 시스템, 메시지, 상태 다이어그램을 설명함
- 상호작용과 메시지 전달 과정을 강조하는 다이어그램의 특징을 소개함

4-3. 애자일 방법론의 특징과 그 적용
- 애자일 방법론이란 소프트웨어 개발 및 프로젝트 관리에서 유연하고 신속한 변화에 대응하는 접근 방식임
- 애자일 방법론의 특징 중 하나로 개인과 소통을 강조하고, 계획을 엄격하게 따르지 않음
- (중요) 실질적으로 사용자에게 가치를 제공하는 기능 중심의 개발 방식을 선호함
- 고객의 피드백을 중요시하여 지속적인 제품 개선을 꾀함
- 프로젝트의 요구사항을 모듈 중심이 아닌 기능 중심으로 개발함

5. 소프트웨어 설계의 초기 단계

5-1. 소프트웨어 개발의 접근 방식과 기능 중심 접근
- 소프트웨어 개발 방식 중 기능 중심 접근은 기능별로 상품 검색, 장바구니 담기, 결제 시스템 등을 개발함
- 기능 중심 접근을 통해 사용자에게 유용한 결과물을 빠르게 제공하고 변화하는 요구사항에 빠르게 대응 가능
- 애자일 방법론은 개인과의 상호작용을 중시하며, 작동하는 소프트웨어를 만드는 것이 중요
- 애자일 방법론은 스크럼, 린, 칸만, 크리스탈, 여드 등을 포함

5-2. 소프트웨어 모델의 이해
- 소프트웨어 모델은 복잡한 시스템을 간소화하고 기호나 그림으로 이해하기 쉽게 표현
- 모델링은 이해 당사자 간의 의사소통을 향상시키고, 개발자, 디자이너, 고객 모두가 같은 그림을 보는 데 도움을 줌
- 모델링 작업의 결과가 다른 모델링 작업에 영향을 줄 수 있음
- (중요) 모델링은 데이터 딕셔널과 같은 방식을 통해 활용

5-3. 소프트웨어 설계 도구: UI
- UI는 사용자 인터페이스의 약자로 사용자가 프로그램과 소통하는 방법을 의미
- UI 설계는 사용자 프로그램 사용을 계획하는 과정으로, 요구사항 확인부터 시작
- (중요) UI 설계는 사용자 프로그램에 대한 화면 구성과 사용자 인터페이스를 결정
- UI는 상위 케이스와 하위 케이스로 나뉘며, 상위 케이스는 전체 시스템을, 하위 케이스는 상위 케이스의 작업을 구체화

6. 애플리케이션 설계

6-1. 애플리케이션과 UI
- 애플리케이션은 사용자 중심의 인터페이스를 제공함
- 사용자 편의를 위한 기능적이고 시각적인 요소를 포함함
- 애플리케이션은 사용자 편의를 위한 다양한 기능을 제공함
- 사용자 편의를 위해 애플리케이션은 모듈화되어 개발됨
- (중요) UI는 시각적이고 기능적인 요소의 집합으로, 사용자의 편의를 위한 도구임

6-2. UI의 원칙과 유형
- UI 설계 시 직관성, 사용자 목표 달성, 학습성, 유연성 등 4가지 원칙을 고려함
- UI 유형에는 씨엘아이 커맨드 라인 인터페이스, GUI(그래픽 유저 인터페이스), nUI(내추럴 유저 인터페이스),oli(올거닉 유저 인터페이스)가 있음
- UI는 사용자의 실수를 최소화하고 사용 편의를 위한 설계가 되어야 함
- UI 화면은 다양한 구성 요소로 구성되며, 사용성, 주의와 경고, 설계 편의 등을 고려해야 함

6-3. UI 구성 요소와 도구
- UI를 설계할 때 밑그림 그리기, 모형과 스토리보드, 프로토타입 등을 활용하여 시각화를 돕는 도구가 있음
- 프로토타입은 UI와 상호작용하는 요소까지 포함한 모델로, 기능 구현이 100% 안 되어도 데모 형태로 제공됨
- (중요) 애플리케이션 설계 시, UI 설계를 통해 사용자 편의를 극대화하는 것이 중요함

7. 소프트웨어 모듈의 개념과 중요성

7-1. 소프트웨어 모듈의 개요와 역할
- 소프트웨어는 여러 모듈들이 협력하여 작동하며, 이를 모듈이라 부름
- 모듈은 사용자 인증, 채팅, 알림 전달, 연락처 관리 등 다양한 기능을 구현
- (중요) 모듈화를 통해 프로그램을 쉽게 만들고 관리할 수 있음
- 모듈 간의 상호작용은 모듈의 크기를 작게 하되, 그 영향을 최소화

7-2. 모듈화의 특징과 장점
- 모듈은 프로그래밍 언어에서 함수나 서브루틴으로 표현
- 모듈 수가 많아지면 각 모듈의 크기는 작아지지만, 모듈 간의 상호작용은 늘어남
- 모듈은 복잡한 시스템을 쉽게 관리할 수 있어, 독립적인 컴파일이 가능
- (중요) 모듈은 고유한 이름을 가져야 하며, 다른 모듈이 그 이름을 찾아가는 것이 가능

7-3. 모듈화의 응집도와 결합도 이해
- 모듈 간의 독립성을 보여주는 응집도와 모듈 간의 의존성을 보여주는 결합도를 고려해야 함
- 응집도는 모듈이 한 가지 일에 집중하는 정도를, 결합도는 모듈 간의 연관된 정도를 나타냄
- 응집도는 상황에 따라 7가지 유형으로 나뉘며, 결합도는 6가지 유형으로 나뉨
- (중요) 결합도가 높을수록 모듈의 독립성이 높아져 유지보수가 쉬워지고 재사용성이 높아짐

8. 소프트웨어 설계와 오류 이해

8-1. 소프트웨어 설계의 유형과 특징
- 소프트웨어 설계 유형은 자료 구조 설계, 아키텍처 설계, 인터페이스 설계, 프로시저 설계, 협약에 의한 설계로 나뉨
- 각 설계 유형은 시스템 전반적인 구조와 동작 원리를 결정
- (중요) 모듈 설계는 하위 설계에 해당하며, 더 세부적인 내용을 설계
- 상향식 설계는 최하위 수준에서 큰 단위부터 설계 시작
- 하향식 설계는 가장 큰 단위에서 작은 단위로 나누어 개발

8-2. 코드 설계와 오류 이해
- 코드 설계는 데이터를 분류하거나 사물을 표현하는 과정
- 코드 설계 방식에는 연상 코드, 블록 코드, 순차 코드, 표의 숫자 코드 등이 있음
- 각 코드 설계 방식은 데이터 처리에 기여
- (중요) 코드 오류에는 트랜스크립션 오류, 전이 오류, 생략 오류, 이중 전이 오류, 복합 오류 등이 있음

8-3. 소프트웨어 아키텍처의 이해
- 소프트웨어 아키텍처는 소프트웨어의 기본 구조를 나타냄
- (중요) 하향식 소프트웨어 개발을 위한 가이드라인으로 작용
- 소프트웨어 아키텍처는 기능과 데이터의 관계를 쉽게 표현
- (중요) 소프트웨어 아키텍처는 고객의 품질 요구 사항을 반영하여 품질 속성을 결정

9. 소프트웨어 아키텍처와 객체지향 설계

9-1. 소프트웨어 아키텍처의 다섯 가지 뷰
- 소프트웨어 아키텍처는 사용자 요구사항을 정리한 시나리오를 다양한 관점으로 바라봄
- (중요) 시나리오 뷰, 논리뷰, 프로세스 뷰, 배포 뷰의 다섯 가지 뷰를 통해 소프트웨어의 여러 측면을 종합적으로 이해함
- 시험에서는 아키텍처 뷰의 유형이 아니라, 이를 변형하여 내는 형태를 주로 봄
- (중요) 각 뷰가 무엇을 의미하는지 이해하는 것이 시험에서 중요함

9-2. 소프트웨어 아키텍처 패턴과 적용 사례
- 소프트웨어 아키텍처 패턴은 설계 문제를 해결하기 위한 템플릿으로 볼 수 있음
- 계층화 패턴은 시스템을 여러 층으로 나누어 데이터베이스, 비즈니스 로직, 사용자 인터페이스 등으로 구분함
- 클라이언트-서버 패턴은 시스템을 클라이언트와 서버로 나누어 사용하며, 웹 어플리케이션에 대표적임
- (중요) 파이프 필터 패턴은 데이터 처리를 여러 단계로 나누어 설계, 유연한 시스템 구현 가능

9-3. 객체 지향 설계의 개념과 요소
- 객체 지향 설계는 실세계에 존재하는 모든 것을 객체로 바라보는 사고를 말함
- 객체의 속성은 객체가 가진 특징, 동작은 객체가 할 수 있는 일을 의미함
- (중요) 객체 지향적 사고를 통해 복잡한 현실 세계를 프로그래밍으로 표현 가능
- 객체 지향 설계의 핵심 요소로 고유 식별자, 객체 속성, 동작 메소드 등을 들 수 있음
- 객체는 자신의 속성과 동작을 통해 다른 객체와 상호 작용하며 전체 시스템을 동작하게 함

10. 객체지향 설계

10-1. 객체지향 설계의 개요
- 소프트웨어를 객체로 나누고 객체 간 상호작용으로 프로그램 만듦
- 메신저 앱의 맨션화기, 선물하기 기능을 객체지향적으로 설계
- 기능을 여러 객체로 나누어 각 객체를 독립적으로 개발, 테스트 가능
- 기능 수정 및 확장 시, 객체를 수정하는 것만 하면 됨
- 객체 지향 설계의 주요 구성 요소와 원칙 이해가 중요함

10-2. 객체 지향 설계의 구성 요소
- 객체는 실 세계에 존재하거나 생각할 수 있는 모든 것
- 메서드는 객체가 수행할 수 있는 동작이나 기능
- 속성은 객체의 상태를 나타내는 데이터
- 클래스는 비슷한 특성들을 가진 객체를 묶어 정의
- 인스턴스는 클래스를 바탕으로 실제로 생성된 객체

10-3. 객체 지향 설계의 원칙
- (중요) 단일 책임의 원칙, 개방 폐쇄의 원칙, 리스코프 치환의 법칙 등
- 필요 없는 기능은 과감하게 제거하고, 추상화를 통해 상호 의존을 줄임
- 상위 수준 모듈은 낮은 수준의 모듈에 의존하지 않아야 함
- 추상화를 통해 구체적인 행동보다 큰 틀에서 작업을 정의
- 객체 지향 설계의 주요 특징을 이해해야 함

11. 객체지향 설계

11-1. 객체 지향 설계의 기본 개념
- 객체지향 설계란 현실 세계를 모방한 프로그래밍의 한 방법임
- (중요) 객체지향 설계의 핵심은 소프트웨어 모델링, 인터페이스 설계, 객체 캡슐화, 상속, 추상화, 상호 의존성, 정보 은닉, 관계성 등임
- 소프트웨어 모델링은 현실 세계를 모방한 프로그래밍 모델을 의미함
- 인터페이스 설계는 객체와 소프트웨어 간의 인터페이스를 정의하는 것임
- 객체 캡슐화는 객체의 속성과 메서드를 하나로 묶고 은닉하는 것임

11-2. 객체 캡슐화와 상호 의존성
- 객체 캡슐화는 코드의 복잡성을 줄이고 오류의 파급 효과를 줄여줌
- 상호 의존성은 객체들이 상호 의존적인 관계를 갖는 것을 의미함
- (중요) 객체 지향 설계의 세 번째 특징은 캡슐화로, 정보 은닉과 밀접한 관련이 있음
- 상호 의존성은 객체 지향 설계의 다섯 번째 특징으로, 정보 은닉에 이어 두 번째 중요한 특징임
- 추상화는 복잡한 시스템에서 핵심 개념만 드러내고 세부 사항을 감추는 것임

11-3. 정보 은닉과 관계성
- 정보 은닉은 객체의 속성과 연산 일부를 감추어 외부에서 접근하거나 수정하지 못하게 함
- (중요) 정보 은닉의 근본적인 목적은 고려하지 않은 영향을 최소화하여 유지 보수성과 확장성을 높이는 것임
- 정보 은닉을 통해 모듈 간의 독립성을 유지하고, 모듈 내부의 자료 구조와 접근 동작을 쉽게 수정할 수 있음
- 관계성은 객체들 사이의 다양한 관계를 나타내는 기법으로, 연관화, 분류화, 집단화, 일반화, 특수화가 있음
- 연관화는 객체 간의 일반적인 관계, 분류화는 객체를 공통된 특성에 따라 그룹화함

12. 소프트웨어 개발 기법과 디자인 패턴 이해

12-1. 소프트웨어 개발 기법과 집단화, 일반화, 특수화 관계 이해
- 소프트웨어 개발 기법에는 집단화, 일반화, 특수화 관계가 포함됨
- 집단화 관계는 개별 요소들이 독립적으로 존재하며, 전체와 부분의 관계를 나타냄
- 일반화 관계는 클래스의 공통적인 특성을 추출해 상위 클래스를 만드는 것을 의미함
- 특수화 관계는 더 구체적이고 특수한 하위 클래스를 만드는 것을 의미함

12-2. 객체 지향 분석과 이의 활용 방법
- 객체 지향 분석은 비즈니스 문제를 객체 지향적인 관점으로 바라보는 과정임
- (중요) 시스템을 객체화 속성 클래스와 멤버 전체화 부분으로 나누어 분석함
- 객체 지향 분석을 통해 생산성을 향상시키고 요구 사항 변경에 따른 시스템 수정을 용이하게 함
- 코드 재사용을 통해 프로그램의 생산성을 향상시키고 요구 사항 변경에 따른 시스템 수정을 용이하게 함

12-3. 디자인 패턴의 이해와 활용
- 디자인 패턴은 소프트웨어 설계에서 자주 발생하는 문제들에 대한 해결책임
- 디자인 패턴을 통해 문제를 해결하며, 소프트웨어의 구조 파악이 용이해짐
- (중요) 객체 지향 설계의 생산성을 높이고, 재사용성을 확보하며, 유지 보수성을 향상시킴
- 주요 디자인 패턴에는 생성 패턴, 구조 패턴, 행위 패턴 등이 있음

13. 소프트웨어 설계

13-1. 인터페이스 설계 개요
- 인터페이스란 두 시스템이나 장치가 서로 소통할 수 있도록 연결해주는 매개체임
- 유저 인터페이스, 응용 프로그래밍 인터페이스 등이 예시임
- (중요) 인터페이스 설계의 핵심은 요구사항 확인, 분석, 명세, 확인, 검증의 단계로 이루어짐
- 요구사항을 분석하고 정형, 비정형 명세 기법으로 명세하는 방법이 있음
- 정형 명세 기법은 객관적이고 수학적인 공식을 사용해 요구 사항을 명확하게 표현함

13-2. 요구사항 명세 및 검증
- 요구사항 명세 기법에는 워크스루, 동료 검토, 인스펙션 등이 있음
- 워크스루는 명세서를 배포해 사전 검토한 후 짧은 검토 회의를 통해 오류를 조기에 발견하는 방법임
- 동료 검토는 명세서를 작성자가 직접 설명하고, 이해관계자들이 결함을 발견하는 방식임
- 인스펙션은 외부 전문가가 검토하는 공식적인 방법임
- (중요) 정형 명세 기법을 사용할 때는 제품 검토에 집중하고, 문제 영역을 명확하게 표현하며, 협력적인 분위기에서 진행하며, 참석자 수를 제한해야 함

13-3. 인터페이스 설계 과정
- 인터페이스 설계 과정은 요구사항 확인, 분석, 명세, 검증의 단계로 이루어짐
- 요구사항 확인은 고객의 요구를 수집하고, 분석은 요구사항이 논리적으로 맞는지 검토하는 과정임
- 명세 단계에서는 시간과 비용, 제약 등을 설정하고, 문서화까지 진행함
- 정형 명세 기법은 객관적이고 수학적인 공식을 사용해 명세를 표현함
- 비정형 명세 기법은 자연어를 기반으로 사용자의 요구를 구두로 서술함

14. 소프트웨어 개발과 데이터 입력/출력 구현

14-1. 인터페이스 시스템의 구성과 동작 원리
- 인터페이스 시스템은 서로 다른 시스템이나 구성 요소들이 상호작용할 수 있도록 연결하는 역할을 함
- 송신 시스템, 수신 시스템, 중계 서버의 세 가지 주요 시스템이 인터페이스 시스템을 구성함
- 각 시스템은 데이터를 주고받으면서 협력하는 것이 인터페이스 시스템의 핵심임
- 소켓, 데이터베이스 링크, API 등의 기술들이 송수신과 연계하는 부분임
- (중요) 소켓은 통신을 위한 프로그램을 생성해서 포트를 할당하고 클라이언트와 서버 간에 연결해줌

14-2. 메들웨어의 기능과 종류
- 메들웨어는 클라이언트와 서버 간의 통신을 담당하는 소프트웨어로 서로 다른 환경 간의 원활한 통신을 지원함
- 메들웨어는 위치 투명성을 제공해서 사용자가 리소스나 서비스에 실제로 물리적인 위치를 알 필요 없이 접근할 수 있게 해줌
- 메들웨어 솔루션에는 메세지 지향 미들웨어, 송신 측과 수신 측을 연결하는 방법, 원격 프로시저를 호출하는 방법 등이 있음
- (중요) 객체 기반 미들웨어로써 코브라 표준 스펙을 구현한 방법이 있음

14-3. 데이터의 입출력 구현과 자료 구조의 필요성
- 자료 구조는 데이터를 효율적으로 저장하고 관리하기 위한 방법론으로, 선형 구조와 비선형 구조로 나눔
- 선형 구조는 순차적으로 데이터를 저장하는 방식으로 리스트, 스택, 큐, 데코 등이 속함
- 비선형 구조는 트리나 그래프와 같이 데이터를 체계적으로 정리하는 방식으로, 연결 리스트와 같이 다양한 자료 구조들이 속함
- 데이터를 효과적으로 저장하고 관리함으로써 시스템의 성능을 향상시킬 수 있음
- (중요) 자료 구조는 시스템 개발의 중요한 과정이며, 이에 따라 기존의 데이터 입력/출력 방식을 개선해야 함

15. 자료구조와 트리

15-1. 스택과 큐의 특성 이해
- 스택의 특성 이해함 - 마지막에 들어간 요소가 먼저 나옴
- 스택에서 다라나가 먼저 팝되면, 가 나 다는 순서대로 나옴
- 큐는 삽입, 삭제, 인쇄 대기열, 작업 스케줄링 시 유용함
- 큐는 양쪽 끝에서 삽입과 삭제가 가능함
- (중요) 데크는 양방향에서 모두 입출력이 가능한 자료 구조임

15-2. 그래프와 트리의 구조
- 그래프는 정점과 간선으로 구성된 자료 구조임
- 간선의 방향에 따라 방향 그래프와 무방향 그래프로 나뉨
- 정점 간 순환 구조인 트리의 특성 이해함 - 루트를 포함한 순환 구조
- 트리의 차수는 특정 노드에 연결된 자식 노드 중 가장 큰 값을 말함
- (중요) 트리 탐색 방법 - 전위, 중위, 후위 순회로 나뉨

15-3. 트리 탐색과 곱셈의 응용
- 트리의 전위 순회 - 루트 노드를 기준으로 좌우측 노드 순회
- 중위 순회 - 좌우측 노드를 기준으로 각각 방문 후 다시 올라감
- 후위 순회 - 왼쪽 루트 노드에서부터 모든 노드를 순회하며 방문함
- 트리의 차수 계산은 복잡한 데이터 효율적 관리와 알고리즘 분석에 사용됨
- (중요) 트리 곱셈의 응용 - 비선형 데이터에서 자주 사용됨

16. 트리 탐색과 알고리즘

16-1. 트리 탐색의 종류와 특징
- 트리 탐색 방식은 왼쪽 자식 노드의 값이 항상 부모보다 작고, 오른쪽 자식 노드의 값이 항상 부모보다 크다는 특성
- (중요) 깊이 우선 탐색은 트리의 균형을 유지하면서 가장 깊은 노드를 탐색하는 방식
- 너머로 가려고 하는 노드의 수에 따라 탐색의 방식을 결정하며, 이는 복잡성에 따라 선택

16-2. 순회 방식과 표현 방식
- 순회 방식은 연산자의 위치에 따라 결정되며, 루트를 먼저 방문하면 전위 순회, 중간에 방문하면 중위 순회, 마지막으로 방문하면 후위 순회
- 트리의 표현 방식은 전위식, 중위식, 후위식의 세 가지로 나뉘며, 연산자의 위치에 따라 결정
- (중요) 각 표현 방식에 따라 연산의 우선순위에 따라 순회 방식이 결정되며, 중위식을 전위식으로 변환하는 과정을 예시로 설명

16-3. 트리 탐색 알고리즘
- 이진 탐색트리는 왼쪽 자식 노드의 값이 항상 부모보다 작고, 오른쪽 자식 노드의 값이 항상 부모보다 큼
- 이진 탐색트리는 데이터 검색이 빠르지만, 최악의 경우 검색 효율이 가장 낮음
- (중요) 레드블랙트리는 트리의 균형을 유지하면서, 검색이 효율적으로 이루어짐

17. 미로 탐색과 통합구현

17-1. 미로 탐색 방법
- 미로를 탐색할 때 깊이 내려가고 옆으로 이동하는 방법과 같은 방식으로 탐색 진행함
- (중요) 가장 먼저 가는 길을 찾은 후, 해당 길 아래의 다른 길을 탐색함
- 둘째로 탐색할 때는 현재 위치에서 가는 모든 곳을 먼저 탐색한 후 다음 단계로 넘어가는 방식임
- 예시 그림에서 알파벳 순서가 빠른 방향을 먼저 탐색함
- 이 방식은 문제의 특성에 따라 적절한 방법을 선택해서 사용해야 함

17-2. 소프트웨어 재사용
- 소프트웨어 재사용에는 제공학과 재개발의 두 가지 방법이 있음
- 제공학은 기존 소프트웨어 유지하면서 기능 개선하거나 재활용하는 재사용 기법임
- 분석, 재구조, 역공학, 이식 등이 제공학의 주요 활동임
- 분석은 소프트웨어 설계 확인해 동작 이해하는 단계임
- 재구조는 추상적 수준에서 구조를 다른 형태로 바꾸는 작업임

17-3. 통합구현과 마이그레이션
- 통합구현은 개별적으로 만들어진 소프트웨어들을 하나로 모아 완성된 프로그램을 만드는 과정임
- 모듈은 소프트웨어 구조를 이루면서 다른 것들과 구별되는 독립적인 기능을 가짐
- 모듈이 모여 하나의 완전한 프로그램을 만들어내는 것이 소프트웨어 재사용임
- 소프트웨어 재사용에는 위험 부담 감소, 비용 절감 등 장점이 있음
- 한글 문서를 워드 파일로 변환할 때 마이그레이션을 통해 위험 부담을 줄이고 비용을 절감할 수 있음

18. 소프트웨어 개발 과정의 통합 구현과 제품 패키징

18-1. 소프트웨어 개발 과정의 통합 구현 도구
- (중요) 통합 구현 관리 도구인 아이디는 프로그램 개발과 관련된 모든 작업을 한 곳에서 처리할 수 있도록 함
- 아이디의 주요 기능은 코딩, 디버깅, 디플로이먼트 등을 제공함
- 이클립스나 비주얼 스튜디오 같은 프로그램들을 사용하여 다양한 프로그래밍 언어를 지원함
- 아이디 사용은 개발 과정을 효율적으로 만들어주고 프로그래머가 코드 작성에 더 집중할 수 있게 함

18-2. 소프트웨어 형성 관리와 그 필요성
- 소프트웨어 형성 관리란 소프트웨어 개발에서 일어나는 모든 변경 사항들을 체계적으로 관리하는 활동임
- (중요) 형상 관리의 주요 목적은 소프트웨어 개발의 전체적인 비용을 줄이고 개발 과정에 방해 요인들을 최소화함
- 형상 관리의 대상은 프로젝트 계획, 분석서, 설계서, 프로그램 테스트 케이스 등이 있음
- 쓰는 도구로는 쿠션, 비주얼 스파이더, 스타일, 쿠션, 본문이 있음

18-3. 제품 소프트웨어 패키징과 그 중요성
- 제품 소프트웨어 패키징은 사용자가 쉽게 설치하고 실행할 수 있도록 배포 가능한 단위로 묶는 과정임
- 패키징은 사용자 중심으로 진행되어야 하며, 패키징된 소프트웨어는 다양한 환경에서 사용이 가능해야 함
- 패키징 도구 사용 시 고려사항에는 보안, 사용자 편의성, 제품 특성에 맞는 암호화 알고리즘 적용 등이 있음
- (중요) 제품 패키징은 다양한 기기와의 이기종 연동을 고려해야 함

19. 소프트웨어 공학의 이해

19-1. 소프트웨어 기술 요소
- (중요) DRM 시스템의 구성 요소 이해가 중요함
- 저작권자나 기관, 콘텐츠 소비자, 콘텐츠 분배자 등이 있음
- 음원 스트리밍 서비스에서 키 관리와 라이센스 발급이 담당함
- DRM 콘텐츠는 DRM 기술로 보호된 디지털 콘텐츠임
- 패키전은 콘텐츠를 메타 데이터와 함께 배포하는 단위임

19-2. 소프트웨어 매뉴얼
- 소프트웨어 매뉴얼은 사용자가 소프트웨어를 설치하고 사용하는 데 필요한 정보를 제공하는 문서임
- 매뉴얼 작성 시 사용자 관점에서 작성되어야 함
- 구성 요소별로 내용을 작성하고, 사용 설명서를 검토하여 수정함
- 잘 작성된 매뉴얼은 사용자의 만족도를 높이고 소프트웨어의 효율적인 사용을 돕기 때문에 중요함
- 소프트웨어 품질 평가 국제 표준이 존재함

19-3. 소프트웨어 품질 평가
- 포터블리티, 릴라이어빌리티, 효율성, 유지보수성, 사용성, 기능, 부특성, 정확성, 상호 운용성, 보안성 준수성 등이 품질 특성임
- 국제 표준과 함께 개발자 관점에서 고려해야 할 주요 항목으로는 정확성, 무결성, 사용성, 신뢰성, 효율성, 유연성, 이식성, 상호 운용성, 보안성 준수성을 포함함
- 개발자들은 현대 프로그래밍 기술을 적용하고, 지속적인 테스트와 검증을 통해 품질을 유지해야 함
- 공학적으로 잘 만들어진 소프트웨어는 신뢰성이 높고 유지 보수가 용이하며, 사용자 수준에 맞는 인터페이스를 제공함
- 소프트웨어 공학의 목표는 소프트웨어의 품질을 높이고 생산성과 개발자들의 작업 만족도를 올리는 것임

20. 소프트웨어 개발

20-1. 소프트웨어 공학의 기초
- 프로젝트 완성 지연은 인력 추가로 인해 발생함
- 단기적으론 생산성이 떨어지고, 장기적으로 봤을 때 비효율적임
- 파레토의 법칙은 테스트 시 오류의 80%는 핵심 모듈에서 발견된다는 점을 강조함
- (중요) 소프트웨어 개발 프로젝트 관리와 효율성 향상을 위해 파레토의 법칙을 이해해야 함
- 소프트웨어 버전 관리는 코드 변경 사항을 추적하고 관리하는 작업임

20-2. 버전 관리 도구
- 버전 관리 도구는 소프트웨어의 변경 사항을 체계적으로 추적하고 통제하는 활동임
- (중요) 도구는 버전 관리 도구의 서버에 업로드되어, 버전 간 일치 여부를 확인함
- 형상 관리 기능을 통해 이전 버전이나 리비전 정보에 쉽게 접근 가능함
- 권한 있는 개발자만 코드 수정 가능하도록 제어하고, 여러 개발자가 동시에 같은 프로젝트 개발 가능함
- 오류 발생 시 빠르게 복구할 수 있도록 해줌

20-3. 빌드 자동화 도구
- 빌드 자동화 도구는 소스 코드를 컴파일, 테스트, 패키징하는 일련의 과정을 자동화함
- (중요) 지속적인 통합 환경에서 유용하며, 특히 컨티뉴어스 인테그레이션을 지원함
- 엔트, 젠킨스 등이 대표적인 빌드 자동화 도구로, 다양한 버전 관리 도구를 지원함
- 빌드 자동화 도구를 사용하면 반복적인 작업을 자동화하여 개발자의 생산성과 만족도를 높이고, 피드백 루프를 개선할 수 있음
- 빌드 자동화 도구는 결과적으로 더 높은 품질의 소프트웨어를 빠르게 개발할 수 있게 함

00:00
안녕하세요. 여러분 비전공자를 위한 오일 정보처리 기사의 첫 강의 시작하겠습니다. 오늘 강의 첫 강의인 만큼 정보처리기사가 어떤 자격증이고 또 어떻게 준비하면 좋을지 위주로 설명을 드리려고 합니다. 먼저 정보처리기사 자격증은 it 시스템 관련된 업무를 수행할 수 있는지 그 능력을 검증하는 자격증입니다. 1년에 3번 정도 시행이 되고요. 역사가 꽤 깊은 자격증인데 2020년부터 ncs 표준에 맞춰서 좀 대폭 개편이 있었습니다. 그래서 난이도가 좀 올라간 부분도 있습니다. 최근 응시 경향을 보면은 23년도에 응시한 수험생 수가 약 6만 명 정도가 됩니다.

00:47
6만 명이면 적은 숫자는 아니고 자격증 시험 중에서는 사실 가장 많은 수치인데 필기 합격률은 절반이 조금 넘고 있고 실기 합격률은 개편 이후에는 크게 떨어져서 약 20% 정도를 유지하고 있습니다. 이 자격증은 또 졸업 전공과는 관계없이 응시가 가능한 몇 안 되는 it 자격증입니다. 그래서 많은 수험생들께서 응시를 하기도 하고 졸업 예정자도 응시가 가능한 자격증입니다. 정보 처리 기사 시험을 응시하시는 목적은 다양하게 있겠지만, 제가 생각하는 정보 처리 기사가 필요한 이유에 대해 좀 말씀을 드리겠습니다.

01:32
사실 정보 처리 기사는 it 전반의 프로세스를 다루는 자격증이지만 it 직무뿐만 아니라 it와 관계없는 직무에 대해서도 이 정보 처리 기사 자격이 있다면 취업에 가산점을 준다던가 자격수당을 준다던가 하는 경우가 굉장히 많습니다. 그렇기 때문에 1차적으로 취업을 위해서 가산점이나 수당을 위해서 따른 분들이 많고 또 제 강의를 듣게 되실 대부분의 수강생분들도 마찬가지실 겁니다. 그런데 한편으로는 내가 전공자도 아니고 취업을 it 쪽으로 할 것도 아닌데 정보처리기사 자격증이 나중에 도움이 될까 라고 고민하실 수도 있겠죠. 제 생각에는 분명 도움이 됩니다. 여기 왼쪽에 제가 우리나라의 산업군에 대해서 이렇게 빙하로써 그림을 그려보았는데요. 먼저 수면 위에 있는 빙하를 보시면은 네이버나 카카오라인 같은 일반적인 it 서비스 기업들이 있고요.

02:30
그 아랫단에는 엄청나게 큰 비율로 자동차 뭐 무역 패션 이런 다른 산업군들이 표시되어 있죠. 이렇게 대한민국에는 it 산업군뿐만 아니라 다양한 산업들이 있는데, 비단 it 기업뿐 아니라 자동차나 무역 같은 비 it 산업에서도 it는 필수적으로 활용되고 심지어 그 규모는 it 서비스 기업보다 훨씬 크다는 것이 제가 먼저 드리고 싶은 말씀입니다. 왜 제조업처럼 it랑 별로 상관이 없어 보이는 곳이 it가 필요하고 또 많이 사용될까요? 여기 오른쪽을 보겠습니다. 먼저 제가 it와 상관없는 음료수 회사 음료수 회사에 다니고 있는 직원이라고 해보겠습니다. 우선 음료수 회사에 맞는 필수적인 몇 가지 시스템들이 있을 겁니다. 예를 들어서 음료수의 재고를 담당하는 부서를 위한 음료수의 재고를 관리하는 시스템을 먼저 있어야 될 것 같습니다.

03:27
어느 정도는 이런 거를 엑셀로 관리할 수도 있겠지만, 조금만 규모가 커져도 재고 관리를 전문적으로 수행할 수 있는 특화된 프로그램이 필요할 겁니다. 또 전체 직원들을 위한 직원의 인사 정보를 관리하는 시스템도 활용을 하게 될 겁니다. 직원들은 인사 정보 관리 시스템을 통해서 연차도 내고 성과도 관리하고 평가도 진행을 하겠죠. 특히 내가 일반적인 부서가 아니라 it 부서라면 더하겠죠. it 부서의 직원이라면 재고관리 시스템에 대한 유지보수를 진행해야 될 수도 있겠고 또 누군가가 새로운 기능을 만들어줘 라고 했을 때 그 기능에 대해서 개발을 직접 하거나 개발을 하지 않는다면은 외주를 주어서 그 개발 업체를 관리하고 이를 그분들께 맡기기 위해 이를 잘 전달해 줄 줄도 알아야 될 겁니다.

04:28
그러면 내가 it 부서의 직원이 아니다고 하더라도 it가 필요한가 하면은 네 필요합니다. 제가 마케팅 부서의 직원을 예로 들어보겠습니다. 마케팅 부서의 직원들은 마케팅에 활용하기 위해서 재고 프로그램으로 재고의 수준을 파악하고 또 재고 시스템에 혹시 원인을 알지 못할 오류가 난다던가 혹은 재고 시스템에 뭔가가 불편해서 기능을 개선하고 싶다고 하면은 그걸 만든 it 부서에 요구를 해야 될 때도 있을 겁니다. 그럴 때 it에 대해 모르는 것과 it를 조금이라도 아는 것은 큰 차이를 만들어냅니다.

05:05
개발자 관점에서 소프트웨어를 평가하고, 개선을 요구할 줄 알게 된다면 it 부서와의 의사소통의 간격을 줄여 훨씬 빠르고 이해하기 쉽게 소통을 할 수 있고 또 본인이 직접 이런 기능이 있으면 좋겠다라고 생각을 했을 때 심지어는 직접 개발을 해서 업무 자동화를 실현할 수도 있겠죠. 바로 이런 사례들이 있기 때문에 it 기업이 아니고 또 그 안에서 it 부서가 아니더라도 it에 대한 전반적인 이해는 필수적이라고 생각합니다. 그중에서 정보 처리 기사 자격증은 그런 it 프로젝트의 전체적인 흐름에 대한 전반적인 이해를 도와줄 수 있는 자격증이라고 생각합니다.

05:53
소프트웨어를 설계하는 것부터 정보 처리 시스템을 구축하고 관리하는 것까지 이 it 프로젝트의 전반적인 생명 주기를 다루는 시험이기 때문에 이런 부분에 있어서 이해를 하는 데 도움이 될 거라고 생각합니다. 다시 시험에 대해 좀 설명해 보겠습니다. 앞서 말씀드렸듯이 모든 학과 상관없이 응시가 가능한 시험이라고 설명을 먼저 드렸고요. 시험 과목은 필기랑 실기가 좀 다르게 묘사가 되어 있지만 사실 비슷합니다. 필기는 소프트웨어 설계부터 정보 처리 시스템 구축 관리까지 총 5개 과목으로 이루어져 있고 실기는 정보 처리 실무라는 1가지 과목으로 묘사되어 있지만 사실은 필기시험을 준비하면서 배우신 5가지 과목이 모두 섞여 있다고 보시면 되겠습니다. 검정 방법의 경우에는 필기 같은 경우에는 객관식 사지선다 택일형으로 진행이 되고요.

06:53
과목당 30분씩 20문항으로 진행이 됩니다. 실기 같은 경우에는 필답형 주관식 문제로 진행이 되는데요. 2시간 반 정도 진행이 되고 20문항 내외로 시험이 진행됩니다. 기준이 필기와 실기가 좀 달라요. 필기는 100점 만점에 각 과목당 40점 이상을 무조건 받아야 되고요. 40점을 넘기지 못하면 과락으로 떨어지게 됩니다. 그리고 전과목 평균 60점 이상을 받아야 됩니다. 필기시험 같은 경우에는 과목이 하나다 보니 100점을 만점으로 해서 60점만 넘기면 됩니다. 이 필기시험 같은 경우에는 과락이 있고 또 평균 60점을 넘겨야 되다 보니까 공부를 좀 전략적으로 접근해서 학습할 필요가 있겠습니다. 필기시험 과목에 대해 좀 더 구체적으로 설명드리겠습니다.

07:50
5가지 과목이 있다고 말씀드렸는데요. 첫 번째 과목은 소프트웨어 설계 과목입니다. 이 과목은 요구사항을 분석하고 설계를 어떻게 하면 될지 그 방법론을 공부하는 과목이 되겠습니다. 이 과목은 사실 개념적인 방법론을 알아가는 게 맞기 때문에 좀 암기 위주의 과목이라고 할 수 있겠습니다. 두 번째 과목은 소프트웨어 개발인데 이 과목에서는 데이터 입출력을 비롯해서 각종 구현과 테스트 관리 방법에 대해 배우게 됩니다. 암기도 있지만 수학 문제처럼 개념을 이해하고 응용하는 문제들도 있습니다. 세번째 과목은 데이터베이스 구축으로 sql이라는 데이터베이스를 조회하는 언어를 활용하고 또 그 기반이 되는 데이터베이스를 어떻게 설계할지 배우는 과목입니다.

08:44
네 번째 과목은 프로그래밍 언어 활용 과목으로 응용의 비중이 아주 높습니다. 프로그래밍 언어 알고리즘 운영체제 네트워크와 같이 복잡한 개념들에 대해 배우게 되고 또 특정 코드가 실행될 때의 결과 운영체제의 성능 최적화를 실제로 구현하는 알고리즘 등등을 바탕으로 시험이 출제되기 때문에 가장 난이도가 높은 과목이라고 생각합니다. 얘는 개념을 이해하는 거 반 응용해서 문제를 푸는 거 반반 이렇게 반반이라고 생각을 합니다. 마지막 과목은 정보 시스템 구축 관리인데요. 이 부분에서는 유지 보수나 보안과 관련된 개념들을 배우게 됩니다. 이 과목은 전공자라 하더라도 조금은 낯설고 또 많은 개념들을 머리에 넣어야 해서 암기량이 많은 과목입니다.

09:38
생소한 5가지 과목을 다루게 되어서 양도 많고 막막하게 느끼실 수도 있지만 강의는 정보처리 기사를 준비하는 모든 분 특히 비전공자를 대상으로 반복 학습을 할 경우에 단 5일 준비로 합격할 수 있는 강좌를 준비하였습니다. 강의의 목표는 이렇게 5일 안에 최단 기간 집중 학습을 통한 합격이기 때문에 강의만 반복해로 들어도 합격할 수 있는 총 10시간 분량의 강의를 준비하였습니다. 특히 합격의 가능성을 더 높이기 위해서 저는 20년도 개정 이후에 기출 문제에 대해서 또 역시 반복 학습하는 거를 함께 하는 거를 추천드립니다. 제 강의를 먼저 들으시고 기출 문제를 푸는 과정을 반복한다면, 강의의 내용이 훨씬 머리에 깊게 새겨질 수 있겠죠. 특히 제가 수강생 여러분들의 빠른 합격을 위해 기존의 일반적인 정보 처리 기사 강좌와 차이를 만든 점은 이렇게 4가지입니다.

10:39
먼저 20년도 개정 이후에 빈출 개념 위주로만 내용을 구성하였습니다. ncs 기준을 맞추어 20년도의 개정이 일어난 뒤로 출제 유형과 개념이 크게 변경되었기 때문에 20년도 개정 이후에도 자주 나오는 개념들을 위주로 강의를 구성하였습니다. 두 번째는 비전공자를 위한 쉬운 비유와 예시입니다. 전공자가 아니더라도 어려운 개념을 쉽게 이해할 수 있게끔 최대한 많은 비유와 설명을 추가하였습니다. 여러분들께서 수강하실 강의는 단순히 명시된 정의를 읽는 것에서 끝나는 것이 아니라 아 하고 무릎을 탁 칠 수 있는 쉬운 비유와 예시로 가득 채웠습니다. 세 번째로, 자주 묻는 선지는 이렇게 형광으로 강조를 하였습니다. 특히 정보처리 기사의 필기시험은 사지선다 객관식 시험이다. 보니까 개념 문제 유형들이 크게 3가지로 나뉩니다.

11:34
틀린 개념 속에서 옳은 개념을 찾는 거 뭐 옳은 개념 속에서 틀린 개념을 찾는 거 아니면 4개 중에서 다른 하나를 찾는 거 그렇기 때문에 항상 맞는 개념을 살짝 비틀거나 헷갈리는 개념을 선지로 두는 경우가 굉장히 많습니다. 이런 개념들 가만히 두지 않고 형광 표시를 강조해서 여러분들께서 다시 한번 눈으로 익힐 수 있도록 하였습니다. 마지막으로, 비록 심화 개념이고 자주 나오지 않는 개념이라 하더라도 실무에서 정말 많이 쓰이고 또 놓칠 수 없는 개념들은 제가 추가하였습니다. 그런 내용들이 많지는 않지만 최대한 여러분들께서 정보 처리 기사 시험뿐 아니라 실무에 나가서도 잊지 않도록 마찬가지로 쉬운 설명으로 강의 진행하였습니다. 이렇게 정보처리기사 시험과 필기시험 합격을 위한 방향 마지막으로, 제 강의의 강점에 대한 소개를 마쳤습니다.

12:30
짧고 굵게 비전공자를 위한 오일정보처리기사 강의 앞으로 진행하도록 하겠습니다. 감사합니다. 안녕하세요. 여러분 오늘은 소프트웨어 설계의 첫 단계인 요구사항 확인에 대해 알아보겠습니다. 우리가 집을 지을 때 설계도가 필요하듯이 소프트웨어를 만들 때도 설계가 필요합니다. 그리고 이 설계의 시작이 바로 요구사항 확인입니다. 이 과정은 크게 3가지로 나눌 수 있어요. 현재 시스템을 분석하고 요구사항을 확인하고 마지막으로, 분석 모델을 확인하는 단계입니다. 이 3단계를 통해서 우리는 만들고자 하는 소프트웨어의 청사진을 그리게 되는 거죠. 요구사항이 무엇인지 예를 들어서 설명을 해드리겠습니다.

13:21
여러분들께서 회사에서 사내 메신저 앱을 사용하고 있다고 가정해 봅시다 어느 날 우리 회사의 메신저 앱에도 맨션 기능이 있으면 좋겠다라는 생각이 들었어요. 이런 생각이 바로 요구사항의 시작입니다. 이런 아이디어를 개발자한테 전달하게 되면은 개발자는 이렇게 아이디어를 더 구체화하고 명확하게 만들어 달라고 요청할 거예요. 왜냐면은 맨션 기능 추가라는 말로는 정확하게 어떤 기능을 원하는지 알기 어렵기 때문이죠. 이렇게 요구사항을 명확하게 하는 과정이 바로 요구사항 확인 및 분석입니다. 이거는 시스템 개발의 첫 단계로서 첫 단추를 깨는 거기 때문에 매우 중요한 과정입니다. 자 이제 시스템을 분석해서 요구사항을 도출할 때 고려해야 할 사항들을 살펴보겠습니다.

14:14
제일 먼저 플랫폼이라는 말이 나오는데 여기서 플랫폼이라는 것은 애플리케이션이나 서비스를 개발하고 실행할 수 있는 기반 환경을 의미해요. 주로 소프트웨어를 의미하죠. 그리고 이런 플랫폼의 성능을 분석할 때는 4가지 주요 항목을 고려하게 됩니다. 첫째, 경과 시간은 작업이 완료될 때까지 걸리는 시간을 말합니다. 두 번째 사용률은 cpu나 메모리 같은 자원을 얼마나 사용하는지를 나타냅니다. 셋째, 응답 시간은 작업 요청에 대한 응답이 올 때까지의 시간을 의미해요. 마지막으로, 가용성은 시스템이 얼마나 안정적인지 즉 장애 가능성은 얼마나 되는지를 나타내게 됩니다. 보통 가용성이라는 거는 %로 나타내지는 게 되는데 가용성이 1년에 99%다 라고 하면은 1년 중에 4일은 장애가 날 수도 있다라는 말이랑 같은 말이 되는 거죠.

15:10
제가 이렇게 앞으로도 강의 중에 내용에 빨간색이랑 여기 형광펜을 친 내용들이 되게 많을 텐데 이거 좀 간단하게 설명드리겠습니다. 가장 기본이 되는 개념에는 좀 강조를 위해서 제가 밝은 빨간색으로 표시를 하고 그것과 연관된 개념이라면 어두운 빨간색을 사용할 거예요. 그리고 시험에 자주 출제되는 경우에 물론 기본적으로 여기 있는 자료들은 모두 시험에 나오는 내용만 잡은 자료들이지만 그중에서도 여러 번 출제가 된 내용들은 제가 형광펜으로 표시를 할 거예요. 이 선지 같은 경우는 사지선다 중의 하나를 꼬아서 낼 수 있겠죠. 예를 들어서 플랫폼 성능을 분석할 때 고려하는 항목이 아닌 것은 해놓고, 경과 시간이 아니라 다른 걸 넣어 놓는 식으로요 앞으로 나올 개념들에 대해서도 제가 이렇게 표시를 해 가지고 여러분들께서 최대한 빨리 이해하고 암기할 수 있게끔 도와드릴 예정이니까. 참고해 주시면 감사하겠습니다.

16:06
현행 시스템을 분석할 때는 플랫폼뿐만 아니라 여러 가지 요소를 고려해야 됩니다. 여기서 시스템이란 특정 기능을 수행하기 위해서 다양한 구성요소들이 상호작용하는 통합된 구조를 말해요. 여기서는 플랫폼이랑은 다르게 소프트웨어에다가 하드웨어에 대한 개념까지 포함이 되게 됩니다. 분석 항목으로는 운영체제 그리고 데이터베이스를 저장하고 관리하는 시스템인 dbms 네트워크 등을 분석하게 됩니다. 그리고 이 안에서도 특히 dbms를 분석할 때 어떤 걸 고려하냐라는 시험 문제가 간간히 출제되는데 이것들을 분석할 때는 성능 가용성 상호보완성 기술지원 구축비용 등을 고려하게 됩니다. 이런 분석을 통해서 현재 시스템의 강점과 약점을 파악할 수 있겠습니다. 이제 요구사항 분석에 대해서 자세하게 알아보겠습니다. 요구사항 분석이란 시스템이 무엇을 해야 되는지를 추적해서 요구사항 명세를 본격적으로 작업하는 단계입니다.

17:06
쉽게 말해서 사용자의 요구를 추출해서 목표를 정하고 이 목표를 어떤 방식으로 해결할 것인지 결정하는 단계예요. 이거는 소프트웨어 개발의 출발점이자 실질적인 첫 번째 단계가 됩니다. 요구사항을 분석한 이후에 설계 구현 테스트 유지보수 단계까지 이어지게 됩니다. 요구사항 분석의 특징을 몇 가지 살펴보면은 먼저 이 단계에서는 개발 비용이 사실 그렇게 많이 들지 않습니다. 오히려 유지 보수 단계에서 비용이 가장 많이 들어요. 그리고 자료 흐름도 자료 사전 소단위 명세서 등의 문서 양식들이 효과적으로 이용이 될 수 있습니다. 마지막으로, 이 단계에서는 코딩이나 개발 기술보다는 청취 인터뷰 중재 등의 커뮤니케이션 기술이 되게 중요합니다.

17:55
고객들을 통해서 어떤 것이 필요한지 잘 이해를 하고 상호작용을 해야 되는 경우가 되게 많기 때문에 말이 되게 중요한 거죠. 그리고 이런 요구사항은 크게 기능적인 요구사항과 비기능적 요구사항으로 나눌 수 있습니다. 먼저 기능적인 요구사항은 시스템이 무엇을 해야 하는지에 초점을 맞추게 됩니다. 예를 들어서 우리가 앞서 언급한 맨션 기능의 경우에 사용자가 골뱅이 뒤에 다른 사람의 이름을 붙여서 메시지를 전송하면은 언급된 사람한테 별도의 알림이 가게 한다와 같이 구체적으로 그 기능을 명시할 수 있겠죠. 반면에 비기능적인 요구사항은 이 시스템이 어떻게 동작을 해야 되는지에 초점을 맞추게 됩니다. 이거는 주로 성능이나 품질 보안 같은 기능들과 연관이 있어요.

18:50
예를 들어서 시스템은 사용자가 맨션 기능을 수행했을 때 0.2초 안에 알림을 처리해야 한다와 같이 성능적인 측면에서 명시를 할 수 있겠습니다. 이렇게 기능적인 비기능적인 요구 사항들을 명확하게 정의함으로써 이제 개발팀은 무엇을 어떻게 만들어야 할지 정확하게 이해할 수 있게 됩니다. 이제 그다음 단계로 데이터 흐름도 줄여서 dfd에 대해서 알아보겠습니다. dfd는 데이터가 프로세스를 따라 흐르면서 어떻게 변화하는지를 보여주는 시각적인 표현입니다. 이거를 자료흐름그래프 또는 버블차트라고 부르기도 합니다. dft는 구조적인 분석 기법에 이용되면서 데이터의 흐름에 가장 중심을 두게 됩니다.

19:35
여기서 말하고 있는 구조적인 분석 기법은 뒤에서도 자주 나올 말인데 복잡한 시스템을 더 작은 하위 시스템으로 분해를 하면서 이해하고 시스템의 기능과 데이터를 구조적으로 표현하는 분석 기법을 의미합니다. 하지만 이 데이터 흐름도 같은 경우에는 논리적인 흐름을 위주로 그림으로 표현한 거기 때문에 시간의 흐름을 명확하게 표현하기 어렵다는 점을 좀 기억해 두시면 좋겠습니다. 이런 데이터 흐름도의 구성 요소는 크게 네 가지입니다. 첫 번째로, 처리기는 데이터를 처리하는 활동이나 기능을 표현하고 이거를 원으로 표현하게 됩니다. 두 번째 데이터 흐름은 프로세스 간의 데이터 흐름을 나타내고 화살표로 표현하게 됩니다. 셋째, 데이터 저장소는 데이터가 저장되는 장소를 나타내면서 두 개의 평행선으로 표현하게 됩니다. 마지막으로, 단말은 프로세스의 시작과 끝을 나타내게 되고 사각형으로 표현하게 됩니다.

20:34
예를 들어서 제가 여기 오른쪽에다가 맨션 기능의 dfd를 그린다면 어떻게 될까를 좀 그려봤습니다. 먼저 맨션된 직원을 식별하고 언급된 알림을 이제 맨션 된 직원한테 전송한다와 같은 프로세스들이 있을 거고, 그리고 여기서 오가는 메시지나 직원 데이터를 저장하는 데이터 저장소 그리고 이들 간의 데이터 흐름을 화살표로도 요렇게 표현을 해볼 수 있겠죠. 다음으로, 자료사전에 대해 알아보겠습니다. 자료사전은 시스템이나 데이터베이스에서 사용되는 데이터 요소들의 정의 속성 제약 조건 및 관계를 체계적으로 정리한 문서입니다. 이는 모든 데이터 요소들을 통일된 형식으로 정의해서 요구사항 분석과 의사소통을 효율적으로 지원합니다.

21:28
자료 사전에서는 여러 가지 기호를 사용하게 되는데요. 예를 들어서 여기 는 기호는 뭐는 뭐로 구성되어 있다와 같은 자료의 정의를 나타내고 플러스는 뭐에는 뭐랑 뭐가 있다와 같은 자료의 연결을 나타내게 됩니다. 그리고 중괄호는 자료의 반복을 소괄호는 자료가 생략 가능함을 그리고 여기 대괄호는 자료의 선택을 표현하게 됩니다. 뭐랑 뭐 중에 하나를 선택한다. 이런 걸요 그리고 이 별별 같은 경우에는 이제 주석으로써 자료에 대한 설명을 나타내게 됩니다. 이런 기호들을 통해서 데이터의 구조와 의미를 명확하게 정의할 수 있습니다. 이는 개발 과정에서 일관성 있는 데이터 관리와 효율적인 의사소통을 가능하게 합니다. 제가 자료 사전에 실제 예를 한번 살펴보겠습니다.

22:22
사내 메신저 앱에 직원 리스트 데이터라는 게 있다고 가정을 하고 이거를 자료 사전으로 제가 한번 표현해 보겠습니다. 이 데이터셋이죠. 먼저 직원 같은 경우에는 고유 코드부터 이름 전화번호 부서명 직급 별명 뭐 여러 개 인사 이력들로 변경 이력들로 구성이 되게 됩니다. 어 이거를 자료 사전으로 표현을 하게 되면은 이렇게 되는데 먼저 직원 같은 경우에는 고유 코드 더하기 이름 더하기 점점 해가지고 이런 형태로 구성이 되어 있는데, 데이터를 플러스로써 연결을 해가지고 직원이라는 데이터에는 뭐랑 뭐랑 뭐가 있다. 라는 의미임을 한눈에 알 수 있죠. 그리고 별명 같은 경우에는 이렇게 소과라고 쳐져 있는데, 별명은 있어도 되고 없어도 된다. 라는 생략의 기능을 표시하고 있습니다.

23:16
그리고 고유 코드 같은 경우에는 이제 입사년도랑 부석 코드로 구성이 되게 되고 여기 별별 표시를 통해서 이게 직원의 사원 정보라는 설명까지 추가가 되어 있습니다. 그리고 부서명은 개발부 재무부 인사부 마케팅 중 하나를 선택하게 된다는 거를 알 수 있습니다. 여기 대괄호를 통해서요. 마지막으로, 여기 인사 변경 이력을 보면은 입사 및 승진 일자를 날짜 대 직급의 규칙으로 표현을 하고 최소 0개에서 10개까지 가질 수 있다는 걸 알 수 있습니다. 이렇게 자료 사전을 통해서 데이터의 구조와 의미를 명확하게 정의함으로써 개발 과정에서 일관성 있는 데이터 관리가 가능해지게 됩니다. 이제 uml 유니파이드 모델링 랭귀지에 대해서 알아보겠습니다.

24:10
uml은 오른쪽 그림처럼 주로 객체 지향 소프트웨어를 개발할 때 산출물을 명세화하고 시각화하기 위한 표준화된 모델링 언어를 의미합니다. uml의 주요한 목적 중에 하나는 개발할 시스템을 이해하기 쉬운 형태로 표현해서 개발자와 기획자 사이에 효율적인 의사소통을 가능하게 한다는 점입니다. 여기서 주의할 점은 uml이라는 거는 어떤 개발 방법론이나 프로세스가 아니라 표준화된 모델링 언어라는 점입니다. uml은 크게 사물 관계 다이어그램의 세 가지 요소로 구성이 되는데 어떤 주제를 나타내는 요소인 사물 그리고 그런 사물과 사물을 연결하는 관계 마지막으로, 사물과 관계를 모아서 그림으로 표현한 다이어그램으로 구성이 되어 있습니다.

25:00
이 uml 정의 자체도 되게 중요하지만은 시험에서는 uml의 구성 요소가 아닌 것은 해 가지고 이 3개 사이에 다른 하나를 끼워 넣고 문제가 자주 나온다는 사실을 참고하시면 좋을 것 같아요. uml 다이어그램은 크게 두 가지로 나눌 수 있습니다. 첫 번째로, 구조적 또는 정적이라고 부르는 다이어그램과 행위적 또는 동적이라고 부르는 다이어그램입니다. 이 구조적 다이어그램은 시스템의 정적인 구성 요소와 그들 간의 관계를 보여주게 됩니다. 여기에는 클래스 다이어그램부터 패키지 다이어그램까지 포함이 되게 됩니다. 기본적으로 구조적 다이어그램에 어떤 다이어그램들이 포함되어 있는지 알고 가시면 좋고 여기서 널리 사용되고 또 시험에 자주 나오는 몇 가지 다이어그램들을 먼저 소개해 드리겠습니다. 클래스 다이어그램은 가장 널리 사용되는 다이어그램 중 하나입니다.

25:53
이거는 주제를 나타내는 사물을 의미하는 클래스 속성 메서드 등을 사용해서 시스템의 정적 구조를 표현하게 됩니다. 먼저 이 클래스라는 거는 주제를 나타내는 어떤 사물을 의미하고요. 클래스명은 그런 사물들의 클래스의 이름을 나타내게 됩니다. 두 번째로, 속성은 그런 클래스가 가지고 있는 특징이나 성질을 의미하는 단어예요. 앞으로도 속성 또는 atribut는 대개 데이터베이스나 뭐 다른 곳에서 많이 쓰이게 될 단어인데요. 아무튼 이 사람이라는 클래스의 속성에는 여러 가지가 있겠죠. 뭐 이름이나 나이가 이 사람의 특징을 표현하는 게 될 수 있고 이외에도 많은 속성을 가질 수 있을 거예요. 연산은 클래스가 수행할 수 있는 동작을 의미합니다. 예를 들어서 사람 클래스의 경우에는 걷다랑 말하다 뭐 이런 연산을 할 수 있겠습니다.

26:45
마지막으로, 접근 지원자는 누가 그 클래스를 사용할 수 있는지 표현하게 됩니다. 마이너스 등의 기호를 통해서 표현할 수 있는데, 모든 클래스에서 이 클래스에 접근 가능하거나 아니면 이 해당 클래스 안에서만 접근 가능하다 뭐 이런 여러 가지 접근 조건들을 제어하는 연산자라고 생각을 하시면 될 것 같습니다. 두 번째로, 행위적 다이어그램 또는 동적 다이어그램은 시스템의 동적인 구성 요소와 그들 간의 관계를 보여줍니다. 여기에는 유즈 케이스 다이어그램부터 타이밍 다이어그램까지 포함이 되게 되고요. 이것도 마찬가지로 어떤 것들이 이 행위적 다이어그램에 포함되어 있는지 외우시면 좋은 게 이 중에 뭐 행위적 다이어그램 아니면 동적 다이어그램이 아닌 것은 이런 식으로 시험에 나오기 때문에 암기를 미리 해두시면 좋겠습니다.

27:43
네 그중에서 유즈 케이스 다이어그램은 특히 시험에 많이 나오는 다이어그램 중 하나인데요. 이거는 시스템의 기능과 사용자와의 상호작용을 시각적으로 표현한 다이어그램입니다. 이런 유즈 케이스 다이어그램의 구성 요소로는 크게 세 가지가 있는데요. 먼저 시스템이 제공하는 특정 기능이나 서비스를 의미하는 유즈 케이스 그리고 시스템과 상호작용하는 사용자 또는 다른 시스템을 나타내는 액터 그리고 이런 유즈 케이스들이 수행되는 경계를 나타내는 사각형인 시스템으로 이렇게 세 개의 요소로 구성이 되어 있습니다. 예를 들어서 우리의 메신저 시스템에서는 맨션 기능을 유즈 케이스 다이어그램으로 이렇게 동그라미로 표현할 수 있습니다. 여기서 직원이 이런 맨션 기능을 수행하는 액터가 되는 거고, 맨션 자체가 유즈 케이스가 되는 거죠.

28:41
유스케이스 다이어그램에서는 다양한 관계를 표현할 수 있습니다. 먼저 연관은 액터와 유즈 케이스 간의 상호작용을 나타내고 실선으로 표현을 하게 됩니다. 포함은 하나의 유즈 케이스가 다른 유즈 케이스를 반드시 포함해야 할 때 사용합니다. 확장은 특정 조건이 만족될 때 유지 케이스가 다른 케이스로 확장이 될 때를 포함합니다. 사용합니다. 일반화 같은 경우는 비슷한 일들을 더 일반적으로 묶을 때 활용합니다. 여기 아래에 제가 예시 그림들을 몇 가지 그려 놓았는데 맨션 기능을 바탕으로 뮤직 케이스 다이어그램을 어떻게 활용할 수 있을지 그려봤습니다. 먼저 맨션 기능은 직원들이 사용하면서 상호작용이 이루어지는 것이니 이렇게 실선으로 직원과 사용자 맨션을 이어줄 수 있고 이거를 연관 관계로 표현할 수 있습니다.

29:35
또 맨션 된 사람들에게 알림이라는 유즈 케이스는 어쨌든 사용자 맨션을 무조건 해야 알림을 할 수 있는 거기 때문에 사용자 맨션을 포함하는 형태의 관계가 될 수 있습니다. 확장 같은 경우에는 구매하기라는 유즈 케이스는 측정 조건에서 할인 코드 적용이라는 유즈 케이스로 확장이 될 수 있습니다. 확장된 유즈 케이스에서 기존의 유즈 케이스 방향으로 점선을 그리고 이런 익스텐드와 같은 스테레오드 타입을 덧붙여줍니다. 마지막으로, 일반화는 삼각형이 달린 화살표 형태로 표현할 수 있는데, 오른쪽 그림처럼 구체적인 일들을 예로 들어서 상품권으로 구매하기 또 무슨 페이로 구매하기 이런 것들을 구매하기라는 하나의 카테고리로 묶어볼 수 있겠습니다. 시퀀스 다이어그램이라는 것도 있는데요.

30:28
이거 역시 동적 다이어그램의 일부로서 시스템의 동적인 측면을 모델링하고 또 객체 간의 상호작용을 시간 순서에 따라 시각적으로 보여줍니다. 그리고 시간의 흐름에 따라 객체들이 주고받는 메시지의 전달 과정을 강조한다는 특징도 있습니다. 상태 다이어그램이라는 것도 있는데, 특정 객체가 가질 수 있는 상태와 상태 간의 전위를 강조해서 표현한다는 것 정도를 알면 좋습니다. 그리고 이런 두 다이어그램은 각각 고유한 구성 요소를 가지고 있습니다. 시퀀스 다이어그램은 객체부터 회계 메시지 상태 다이어그램 같은 경우는 상태부터 전이 조건까지 이렇게 구성이 되어 있는데, 구성 요소에 대해서 시험 문제에서 물어보는 경우가 되게 많으니까 챙겨보시면 좋을 것 같습니다. 앞서 유즈 케이스 다이어그램에서 몇 가지 예시를 들어드린 것처럼 uml에서는 다양한 관계를 표현할 수 있습니다.

31:24
영과는 서로 어떤 방식으로 연결되어 있는지를 표현합니다. 일반화는 상위 개념과 하위 개념 간의 관계를 나타냅니다. 예를 들어서 과일과 사과의 관계가 이에 해당합니다. 의존은 한 요소가 다른 요소에게 종속적일 때의 관계를 나타냅니다. 주문을 해야 결제가 이루어지니 주문과 결제의 관계가 이에 해당할 수 있죠. 실체와는 추상화된 개념과 이를 실제로 구현하는 개념 사이의 관계를 나타냅니다. 추상화라는 단어가 조금 와닿지 않을 수도 있는데, 추상화된 수영이라는 개념과 수영을 실제로 구현하는 수영 선수 간의 관계를 생각하시면 될 것 같습니다. 포함은 전체와 부분 간의 강한 관계를 의미합니다.

32:12
강한 관계라는 거는 전체 객체가 사라지면 부분 객체도 같이 사라지는 걸 의미하는데 집이 없어지면은 방도 없어지는 거니까 집과 방을 강한 관계라고 볼 수 있겠습니다. 집합의 경우에는 전체와 부분 간의 느슨한 관계를 의미합니다. 전체 객체와 부분 객체가 독립적으로 존재할 수 있고 예가 없어져도 예는 있을 수 있는 경우를 의미합니다. 도서관과 책의 예시가 이에 해당할 수 있겠습니다. 애자일 방법론에 대해 알아보겠습니다. 애자일이라는 거는 영어로 기민하고 빠른 뭐 이런 뜻인데요. 이 애자일 방법론은 소프트웨어 개발 및 프로젝트 관리에서 유연하고 신속하게 변화에 대응할 수 있도록 고안된 접근 방식입니다.

33:06
전통적인 방식과는 다르게 애자일은 유연하고 신속하게 변화에 대응할 수 있도록 고안됐습니다. 특히 고객들의 요구사항 변화에 빠르게 적응하고 개발 과정에서 지속적으로 내용들을 개선해 나가는 것이 핵심이죠. 전통적인방법론과 애자일 방법론을 한번 비교해 보겠습니다. 전통적인 방법론은 한 번에 모든 걸 계획하고 실행하는 방식이에요. 모든 거를 최초의 계획을 하고 그 계획에 맞게 한 단계씩 나아가는 방식입니다. 예를 들어서 이 신발 가게를 운영한다고 가정했을 때 대대적인 마케팅을 통해서 신발을 팔려고 계획을 하고 마케팅에 앞서 수요를 예측해서 한 번에 최초의 모든 재고를 채워 넣게 됩니다. 마케팅을 잘 해가지고 신발이 잘 팔리면 되게 좋을 텐데 신발이 팔리지 않을 경우에는 큰 손해를 보게 됩니다.

34:01
한마디로 이 방식은 최초의 예측을 다 하기 때문에 안정적이지만 이런 신발이 잘 팔리지 않고 마케팅이 잘 안 됐을 때 이런 변화에 대응하기 어렵다는 단점이 조금 있습니다. 반면에 애자일 방법론 같은 경우에는 몇 가지 인기 신발만 소량을 파는 방식으로 시작하게 됩니다. 유행을 직접 관찰하고 피드백을 받아가면서 빠르게 제품들의 재고를 조정하고 고객들이 원하는 신발을 더 많이 만들어 나가는 방식이죠. 이게 요리사가 손님들의 반응을 보면서 요리를 조금씩 개선해 나가는 거랑 비슷하다 보니까 조금 더 유리한 부분이 있습니다. 결론적으로 애자의 방법론은 작은 단위로 시작을 해 가지고 고객들의 피드백을 반영하면서 지속적으로 개선해 나가는 유연한 개발 접근 방식입니다.

34:51
현대에 빠르게 변화하는 시장 환경에 매우 적합한 방법이라고 할 수 있겠고 최근에 it 기업을 넘어서 일반 기업들 사이에서도 도입을 추진하는 방법론이기도 합니다. 이런 애자일 방법론의 특징에 대해서 더 자세하게 알아보겠습니다. 애자일 방법론은 전통적인 개발 방식과는 다른 좀 몇 가지 접근 방식들을 취하게 됩니다. 먼저 애자일이라는 거는 절차와 도구보다 개인과 소통을 더 중요하게 여깁니다. 팀원들 간의 직접적인 의사소통을 훨씬 강조해요. 두 번째로, 계획을 엄격하게 따르기보다는 요구사항 변화에 유연하게 대응하는 걸 중요하게 생각합니다. 이거는 변화하는 비즈니스 환경에 빠르게 적응할 수 있도록 도와주죠 세 번째로, 소프트웨어 자체가 잘 실행되는 데 가치를 주게 됩니다. 뭔가 문서로써 이력을 남기는 것보다는 실제로 그냥 작동하는 소프트웨어를 잘 개발하는 거에 초점을 맞춘다는 의미입니다.

35:51
네 번째로, 고객과의 피드백을 중요하게 생각합니다. 지속적인 고객의 피드백을 받음으로써 제품을 지속적으로 개선해 나가죠 마지막으로, 프로젝트의 요구사항을 모듈 중심이 아닌 기능 중심으로 개발하게 됩니다. 실질적으로 사용자에게 가치를 제공하는 기능을 우선적으로 개발한다는 걸 의미하게 됩니다. 이 말이 두 개가 같은 게 아니야 라고 좀 헷갈리실 수도 있는데, 우리가 온라인 쇼핑몰 사이트를 만든다고 생각해 봅시다 모듈 중심의 접근은 프로그램의 각 부분을 독립적으로 만드는 방식 즉 데이터베이스 사용자 인터페이스 결제 시스템 등을 각각 독립적으로 만든 다음에 통합을 하는 방식입니다.

36:36
근데 이제 기능 중심 접근이라 하면은 아까 뭐 데이터베이스면 데이터베이스 이렇게 분리를 하는 게 아니라 기능별로 상 소비자들이 이해할 수 있는 기능을 중심으로 상품 검색 장바구니 담기 기능 결제하기 같은 기능을 먼저 개발해서 사용자가 어쨌든 쇼핑을 할 거면 하고 결제를 할 거면 할 수 있게 만들어 버립니다. 이렇게 기능을 먼저 개발할 경우에 사용자들에게 좀 더 유용한 결과물을 빠르게 제공할 수 있고 변화하는 요구사항에 더 빨리 대응을 할 수 있게 되는 거죠. 애자일 선언문이라는 게 있는데, 이 애자일 방법론이 나올 때 함께 나온 선언문입니다. 여기에 네 가지 핵심 가치가 있는데, 이것도 한 번씩 살펴보겠습니다. 프로세스와 도구보다는 개인과의 상호작용을 더 가치 있게 여긴다 팀원 간의 직접 소통을 더 중시한다는 의미이고요.

37:33
방대한 문서보다는 작동하는 소프트웨어를 만드는 게 더 중요하다 그리고 계약 협상보다는 고객과의 협력 지속적으로 소통하는 게 더 중요하다는 의미이고 계획을 따르는 것보다는 변화에 대응하는 걸 다 가치 있게 여긴다 미리 세운 계획을 고수하기보다는 상황의 변화에 유연하게 대응하는 것이 중요하다는 의미입니다. 이런 가치관들을 바탕으로 애자일 방법론은 빠르게 변화하는 it 환경에서 효과적인 소프트웨어 개발 방식으로 자리 잡았습니다. 애자의 방법론은 다양한 프레임워크를 통해서 실제로 구현이 되는데요. 이 중에 가장 널리 알려진 것 중의 하나가 먼저 스크럼입니다. 스크럼은 팀이 복잡한 프로젝트를 관리하고 수행하는 데 도움을 주는 프레임워크입니다. 짧은 시간 동안 여러 단계의 반복을 통해서 스프린트라고 불리는 여러 번의 작업 반복과 피드백을 통해서 소프트웨어를 개발하는 방법론이라고 이해를 하시면 되겠습니다.

38:34
이런 스크럼에는 여러 가지 주요 용어가 있습니다. 첫 번째로, 스프린트라는 단어는 일반적으로 1주에서 4주 동안 지속되는 짧은 단위의 반복적인 작업 주기를 의미합니다. 스크럼 팀은 스크럼 마스터 뭐 제품 책임자 개발팀으로 구성된 이 스크럼을 진행하기 위한 팀을 의미하고요. 여기서 스크럼 마스터는 팀이 스크럼을 잘 따를 수 있도록 돕고 장애물을 제거하는 일종의 리더와 비슷한 역할을 하게 됩니다. 그리고 개발팀 제품 백로그 이런 요소들이 있으니까 한 번씩 읽어보면 좋을 것 같습니다. 이런 요소들이 유기적으로 작동하면서 애자일 방식의 소프트웨어 개발이 이루어지는 것입니다. 엘자일 프레임워크에는 스크럼 외에도 다양한 방법론들이 있는데, 제가 몇 가지를 가져왔습니다. 첫 번째로, 익스트림 프로그래밍의 줄임말인 엑스피는 소프트웨어 품질을 높이고 개발팀이 변화에 빠르게 대응할 수 있도록 하는 데 중점을 둔 방법론입니다.

39:34
xp는 기술적인 실전과 지속적인 코드 개선 등 좀 실용성에 중점을 둔 방법론입니다. xp에는 다섯 가지 가치가 있는데, 용기 단순성 의사소통 피드백 존중 이렇게 다섯 가지 요소가 있습니다. 두 번째로, 린 같은 경우에는 간결하다는 의미를 가진 단어인데요. 도요타의 품질관리 기법을 개발 프로세스에 적용한 것입니다. 이 방법론은 낭비를 줄이고 가치를 극대화하는 데 초점을 맞추게 됩니다. 뭐 칸반보드라는 거와 저스틴 타임 생산방식이 린 방법론의 대표적인 도구입니다. 칸만이라는 거는 일본어로 간판 즉 일종의 칠판인데요. 칠판에다가 이렇게 영역을 세 개로 나누고 여기 있는 작업 전 작업 중인 것 완료 이렇게 영역을 나눠 가지고 포스트잇을 영역별로 붙입니다.

40:30
내가 뭘 아직 하기 전이고 뭘 하고 있고 뭘 완료했는지 이런 거를 한눈에 파악하는 방식이라고 보실 수 있겠습니다. 그리고 크리스탈 방법론은 프로세스보다 사람에게 더 중점을 두는 방법론입니다. 나머지 또 asd 어댑티브 소프트웨어 디벨롭먼트는 개발을 혼란으로 규정하고 그에 적응할 수 있는 방법을 제시한 방법론입니다. 이 방법론은 지속적인 학습과 적응을 강조하게 됩니다. fdd 같은 경우에는 개발을 상품이나 서비스 단위가 아닌 기능 단위로 하는 개발 방법론입니다. 이 방법론은 기능 중심의 반복적인 개발 과정을 강조하게 됩니다. 지금까지 여러 모델들과 방법론들을 소개시켜 드렸는데 이런 모델들을 모두 소프트웨어 모델이라고 부르게 됩니다.

41:23
복잡한 시스템을 간소화하고 기호나 그림 등으로 이해하기 쉽게 표현한 형태죠 모델을 통해서 소프트웨어에 대한 이해도를 향상시킬 수 있습니다. 실제로 코드를 보기 전에 전체 구조를 파악할 수 있어 되게 유용해요. 모델은 이해 당사자 간의 의사소통을 향상시킵니다. 개발자 디자이너 고객 모두가 같은 그림을 보면서 이야기를 할 수 있으니까 오해의 소지가 훨씬 줄어들겠죠. 그리고 모델을 통해서 향후 개발된 시스템에 대한 유출도 가능하게 됩니다. 소프트웨어 모델링의 특징도 있는데요. 아까 말씀드린 것처럼 이해하기 쉬운 형태로 표현하는 기법이 될 테고요. 모델링 작업의 결과물이 다른 모델링 작업에 영향을 줄 수도 있습니다.

42:15
퍼즐 조각들이 서로 맞물려 가지고 전체 그림을 완성하듯이 이 모델의 결과가 다른 모델링에 영향을 미칠 수도 있는 거죠. 그리고 설계 구현 유지 보수 이 개발의 전체적인 영역에 어떤 영역이 한정되지 않고 전체적으로 활용되고 있습니다. 그리고 구조적인 방법론에서는 dfd 데이터 딕셔너리와 같은 방식을 통해서 활용하고 있다는 걸 아까 여러 가지 설명들을 통해서 전달을 드렸고요. 객체 지향 방법론에서는 uml 표기법을 주로 활용한다. 정도 아시면 좋을 것 같습니다. 마지막으로, 케이스에 대해서 알아보겠습니다. 케이스는 컴퓨터 aded 소프트웨어 엔지니어링의 줄임말인데요. 소프트웨어 생명주기의 전 단계를 연결해 주고 자동화해 주는 소프트웨어 도구입니다.

43:09
소프트웨어 하드웨어부터 테스트까지 전체 단계에 걸쳐서 이것들을 통합해서 소프트웨어를 개발하는 통합된 환경을 조성해주는 도구이고요. 이런 도구를 통해서 개발한 과정의 속도를 향상시킬 수 있고 또 소프트웨어 부품들을 재사용할 수 있게 도와줍니다. 케이스의 주요 기능은 아래와 같이 네 가지가 있습니다. 첫 번째로, 시스템 설계를 시각적으로 표현하는 그래픽을 지원하고요. 이 생명주기 전 단계의 연결을 통해서 요구사항 분석부터 유지보수까지 전 과정을 지원하게 됩니다. 또 여러 개발 모형들을 지원하고 표준화된 개발 환경 구축과 문서 자동화를 통해서 일관된 개발 환경을 제공한다는 장점이 있습니다. 케이스는 또 상위 케이스와 하위 케이스로 나눌 수 있겠습니다. 상위 케이스는 상위라는 말처럼 전체 시스템이나 프로젝트의 큰 틀을 다루는 데 활용이 되고요.

44:08
하위 케이스는 상위 케이스의 작업들을 실제로 구체화하는 소스 코드를 생성하는 작업들에 활용이 되게 됩니다. 이것으로 소프트웨어 설계의 요구사항 확인에 대한 강의를 마치겠습니다. 오늘 배운 내용은 소프트웨어 개발의 초기 단계에서 매우 중요한 역할을 하는 것들입니다. 이것들을 잘 이해하고 적용한다면, 더 효율적이고 성공적인 소프트웨어 개발이 가능할 것 같습니다. 감사합니다. 안녕하세요. 여러분 오늘은 소프트웨어 설계 특히 화면 설계에 대해 알아보겠습니다. 소프트웨어를 만들 때 가장 중요한 것 중 하나가 바로 사용자가 어떻게 프로그램을 사용할지를 계획하는 것입니다. 이걸 우리는 ui 설계라고 부릅니다. ui 요구사항을 확인하고 실제로 ui를 어떻게 설계하는지 배워보겠습니다. ui는 유저 인터페이스의 약자로 사용자가 프로그램과 소통하는 방법에 대한 내용입니다.

45:00
사용자가 프로그램과 소통을 하기 위해서는 사용자가 프로그램과 마주 볼 수 있는 화면 같은 것이 필요하겠죠. 소프트웨어나 하드웨어와 상호작용할 수 있도록 돕는 시각적이고 기능적인 요소들의 집합을 ui라고 합니다. 이 ui는 우리가 화면이라고 그냥 부르기도 하는데 이렇게 시각적이고 기능적인 요소의 집합이라는 개념적인 부분도 이해를 하시면 좋겠습니다. 어쨌든 이런 ui를 잘 설계하기 위해서는 4가지 원칙을 따라야 됩니다. 첫번째 직관성입니다. 누구나 화면을 보자마자 ui를 보자마자 이 ui가 어떤 기능을 하는지 쉽게 이해하고 사용할 수 있어야 됩니다. 두 번째는 유효성입니다. 사용자가 원하는 목표를 정확하게 달성할 수 있어야 합니다. 세 번째 학습성입니다.

45:59
누구나 그 화면을 쉽게 배우고 또 어떤 기능을 가지고 있는지 뭐 그런 것들을 쉽게 배우고 사용할 수 있게 제작이 되어야 되겠습니다. 마지막으로, 유연성입니다. 사용자의 실수를 최소화할 수 있도록 설계가 되어야 됩니다. 이런 원칙들을 지키면은 사용자들이 우리 프로그램을 더 쉽고 편하게 사용할 수 있겠습니다. ui의 유형에는 여러 가지가 있고 시간의 흐름에 따라 지금도 계속 발전하고 있습니다. 그중에서 가장 기본이 되는 것이 씨엘아이 커맨드 라인 인터페이스입니다. 커맨드 라인 인터페이스라는 말처럼 텍스트로만 명령어를 입력해서 사용자가 상호작용을 하는 방식입니다. 이거는 도스나 유닉스 같은 조금 오래된 운영체제에서 주로 사용되었던 방식입니다. 그 다음으로는 우리가 현재 가장 많이 보고 있는 gui 그래픽 유저 인터페이스입니다.

46:52
이거는 이제 시각적으로 뭔가 직접 쉽게 이해할 수 있는 그래픽 환경을 기반으로 한 인터페이스로 키보드나 마우스로 조작을 하게 됩니다. 현재 우리가 윈도우나 맥 os에서 가장 편하고 가장 많이 보는 환경입니다. 최근에는 조금 더 발전된 형태의 ui도 나오고 있는데요. nui 내추럴 유저 인터페이스가 바로 그런 형태입니다. 이거 같은 경우는 키보드나 마우스 없이 신체를 곧바로 활용하는 방식인데요. 예를 들어서 제스처를 인식하거나 음성 인식 이런 것들이 nui에 해당되게 됩니다. 최근에 애플에서 비전 프로라는 제품을 내놓은 것으로 알고 있는데, 이 제품들이 보면은 제스처랑 눈을 통해서 쉽게 제어할 수 있다고 합니다. 이런 게 nui에 포함될 수 있겠죠. 마지막으로, oui는 올거닉 유저 인터페이스의 줄임말입니다.

47:48
모든 사물이 interface가 된다는 개념이고 아직은 조금 추상적인 개념입니다. 내가 보고 듣고 있는 모든 것들이 내가 시스템과 소통할 수 있는 개념이 된다는 겁니다. 앞서도 말씀드렸지만 ui를 설계할 때 가장 중요한 것은 바로 사용성입니다. 사용성을 위해서 고려해야 되는 지침들이 몇 가지가 있습니다. 먼저 아무리 예뻐도 심미성이 좋아도 사용하기가 어려우면은 좋은 ui가 아니에요. 그렇기 때문에 사용성을 가장 우선적으로 고려해야 합니다. 그리고 오류가 발생했을 때는 사용자에게 명확하게 알려주는 것이 좋습니다. 뭐 빨간색이라던가 아니면은 큰 경고음 이런 것들을 통해서 주의를 끌 수 있겠죠. 마지막으로, ui는 항상 개발자가 아니라 사용자 중심으로 설계가 되어야 됩니다.

48:39
뭐 첫 번째 개념과 좀 비슷하다고 볼 수 있겠지만, 이게 어쨌든 개발자가 ui를 개발하는 거다 보니까 개발자 입장에서는 편한데 사용자 입장에서는 어 이걸 어떻게 하지 라는 생각이 들 때가 되게 많거든요. 그렇기 때문에 실제 사용자들이 편리하게 사용할 수 있도록 그 부분을 항상 고려하면서 설계를 진행해야 되겠습니다. ui 화면에는 다양한 구성 요소들이 있어요. 먼저 콤보박스 같은 경우에는 여러 옵션 중에 하나를 선택할 수 있는 드롭다운 메뉴입니다. 토글 버튼은 켜기랑 끄기처럼 두 가지 상태를 전환하는 버튼이에요. 라디오버튼은 여러 옵션 중에서 하나만 선택을 할 수 있는 버튼입니다. 내가 라디오 버튼 원을 눌렀다가 다시 라디오 버튼 투를 누르게 되면은 자동으로 라디오 버튼 원에다가 입력을 했던 거는 빠지게 돼요.

49:32
이게 이름이 왜 라디오 버튼이냐 하면은 재미있는 예시가 하나 있는데, 옛날에 라디오가 그 카세트를 생각해보면은 이렇게 생겼었죠. 여기에 버튼들이 플레이 일시정지 또 다른 것들이 여러 가지 있었고, 여기 스피커가 있는 이런 형태였는데 제가 만약에 플레이 버튼을 눌렀으면은 나머지들 그리고 플레이 버튼을 누르고 일시정지를 다시 눌렀다라고 하면은 자동으로 이 일시정지 버튼을 누를 때는 얘가 다시 튀어오르게 돼요. 이 방식을 보고 라디오 버튼을 이라고 불렀다라고 생각을 하시면 되겠습니다. 마지막으로, 체크박스 같은 경우에는 라디오 버튼하고는 다르게 여러 개를 동시에 선택을 할 수 있는 옵션이에요. 이렇게 네모로 구분이 되어 있죠. 그리고 ui의 제스처도 여러 가지 구성 요소가 있을 텐데 특히 요즘에 스마트폰으로 터치를 하게 되면서 더 다양하고 또 많아졌습니다.

50:28
가장 먼저 탭 같은 경우는 가장 단순하게 화면을 그냥 터치만 하는 경우를 말하고 드래그는 터치를 한 상태에서 화면을 끌기 플릭은 짧고 빠르게 화면을 삭 쓰는 경우 펜은 터치 상태에서 아주 천천하게 움직이는 경우 핀치 같은 경우는 우리 카메라로 줌 인 줌 아웃을 할 때처럼 두 손가락으로 모으거나 벌리는 동작을 의미합니다. 용어가 전부 비슷비슷하다 보니까 혼동이 되지 않게 잘 외워두시는 게 되게 중요하겠습니다. ui를 설계할 때 사용하는 도구들도 있습니다. 전부 실제 화면을 개발하기 이전에 어떤 느낌인지 감을 잡을 수 있도록 밑그림을 그리는 과정이라고 생각하시면 되겠습니다. 먼저 와이어프레임 같은 경우는 화면의 구조와 요소 배치를 간단하게 기본 뼈대로 나타내는 경우입니다. 그냥 연필 가지고 간단한 그림을 그린다라고 생각을 하시면 될 것 같고요.

51:27
모각 같은 경우에는 실제로 그 디자인 요소들을 평가하기 위해서 실제 화면과 그래도 유사하게 만든 정적인 형태의 모형입니다. 여기서부터는 어느 정도 시각적으로 실제 프로그램과 비슷하게 되기는 하지만 그냥 정적인 그림이기 때문에 이 단계에서도 실제로 구현이 되지는 않습니다. 세 번째로, 스토리보드는 사용의 흐름을 시각화한 스크립트나 그림을 담은 문서입니다. 내가 이 화면에서 이걸 누르면 여기로 간다 뭐 이런 정보들이 스크립트 또는 그림으로 담겨 있고요. 이 단계부터는 사실 서비스 구축을 위한 대부분의 정보들이 담겨 있다고 보시면 되겠습니다. 다만 구현되지는 않습니다. 마지막으로, 프로토타입 같은 경우에는 ui와 어떤 상호작용하는 요소까지 포함이 된 모델입니다.

52:23
여기서부터는 사실 어느 정도 구현이 간단하게 되어서 실제로 기능을 100% 구현하지 못하더라도 단순하게 데모 형태로는 조금 볼 수 있는 정도입니다. 그렇기 때문에 그냥 상상 속으로 그림만 살짝 그린 와이어 프레임보다는 훨씬 정교하고 목업보다는 또 약간 동적이기 때문에 상호작용 요소도 많아지게 됩니다. 이런 도구들을 활용하면은 실제 개발에 들어가기 이전에 ui를 효과적으로 계획하고 테스트할 수 있게 됩니다. 이상으로 오늘 강의 마치겠습니다. 감사합니다. 안녕하세요. 오늘은 애플리케이션 설계에 대해 알아보겠습니다. 애플리케이션 설계의 경우 공통 모듈 설계와 객체 지향 설계 이렇게 두 단원으로 나뉘어져 있는데, 각각의 양이 많아 하나씩 나누어 진행하고자 합니다. 먼저 공통 모듈설계에 대해 알아보겠습니다. 모듈이란 뭘까요? 쉽게 말해서 모듈은 프로그램의 독립적인 부품이라고 생각하시면 됩니다.

53:20
다른 것들과 구별될 수 있는 독립적인 기능을 가진 단위죠 자동차로 비유를 해볼까요? 자동차도 엔진 바퀴 브레이크와 같이 여러 개의 부품들로 이루어져 있죠. 이런 부품들이 바로 모듈과 같은 거예요. 각 부품들이 자기 역할을 하면서 전체 자동차가 움직이는 것처럼 소프트웨어도 여러 모듈들이 협력을 해서 작동하는 거죠. 예를 들어서 우리 첫 시간에 보았던 메신저 앱을 다시 생각해 볼까요? 이 앱에는 이제 여러 가지 기능이 있죠. 뭐 사용자를 인증한다거나 채팅을 하는 모듈 알림을 하고 알림을 전달하고 연락처를 관리하고 미디어 전송 등등 뭐 이런 각각의 기능들을 구현하는 코드를 모듈이라고 부를 수 있어요. 모듈을 이렇게 작은 단위로 되게 잘게 쪼갤 수도 있고 또 사용자 관리와 인증을 합치고 메시지와 미디어 뭐 이런 것들을 합쳐가지고 조금 더 크게 모듈을 만들 수도 있습니다.

54:19
어쨌든 이렇게 모듈화를 하면은 프로그램을 좀 더 쉽게 만들고 또 쉽게 관리할 수가 있게 됩니다. 모듈의 특징에 대해서 좀 더 자세하게 알아보겠습니다. 첫째, 모듈은 프로그래밍 언어에서 함수나 서브루틴 등으로 표현이 될 수 있습니다. 두 번째 모듈의 수가 많아지면 각 모듈의 크기는 작아지지만 모듈 간의 상호작용은 늘어나게 됩니다. 사용자를 인증하고 연락처를 관리하는 기능 두 개가 나뉘어져 있을 때랑 합쳐져서 한 모듈일 때를 생각하면은 당연한 말입니다. 세 번째 모듈하는 복잡한 시스템을 좀 더 쉽게 관리할 수 있게 해줍니다. 그리고 독립적인 컴파일도 가능합니다.

55:04
컴파일이라는 거는 어떤 프로그램을 동작 가능하게 만든다는 의미인데 이 큰 하나의 프로그램을 여러 모듈로 잘게 쪼개더라도 각각의 모듈은 독립적으로 기능한다는 의미이기도 합니다. 또 다섯 번째로, 모듈 모듈은 고유한 이름을 가져야 됩니다. 마지막으로, 다른 모듈에서도 특정 모듈에 접근을 할 수 있어야 돼요. 이런 특징들 덕분에 모듈화는 큰 프로그램을 만들 때 유용한 방법이 됩니다. 모듈화의 장점에 대해서도 알아보겠습니다. 첫 번째로, 오류가 발생해도 그 영향 즉 오류의 파급 효과를 최소화할 수 있습니다. 기능별로 모듈을 분리하였기 때문에 한 모듈에 문제가 생겨도 다른 모듈에는 영향을 덜 줄 수 있기 때문이에요.

55:56
뭐 예를 들어서 뭐 여기 메신저 앱에 선물하기라는 모듈이 또 있다고 가정했을 때 선물하기 앱이 고장 났다 하더라도 채팅 모듈에는 기본적인 채팅의 기능에는 당장 지장이 없겠죠. 뭐 내가 채팅으로 선물을 하려고 하면은 뭐 지장이 있을 수도 있겠지만요 두 번째로, 기능을 분리할 수 있어서 interface가 단순해집니다. 이 interface라는 말은 앞으로도 계속 나올 단어이고 아까 앞전에 강의에서 유저 인터페이스 이런 말에도 나온 단어인데 여기서는 모듈 간의 상호작용이 명확하고 단순해진다라고 이해를 하시면 되겠습니다. 셋째, 모듈의 분리를 통해서 재사용을 할 수 있기 때문에 개발과 유지 보수가 쉬워집니다. 그리고 당연하게도 프로그램을 더 효율적으로 관리할 수 있게 됩니다. 모듈을 제가 재사용할 수 있다고 했는데 재사용에는 세 가지 유형이 있어요. 컴포넌트 재사용 애플리케이션 재사용 함수 및 객체 재사용이죠.

56:54
이렇게 재사용을 하게 되면은 개발 시간도 줄이고 안정성도 높일 수 있게 됩니다. 이런 모듈화가 얼마나 잘 이루어졌는지 측정을 하는 두 가지 중요한 지표가 있습니다. 바로 응집도랑 결합도입니다. 응집도는 먼저 각 모듈의 독립성을 나타내는 개념으로 한 모듈의 내부 요소들이 얼마나 관련이 있는지를 나타냅니다. 쉽게 말해서 한 모듈이 얼마나 그 모듈이 해야 되는 한 가지 일에 집중하고 있는지를 보는 거예요. 그렇기 때문에 응집도라는 거는 높을수록 더 좋습니다. 두 번째로, 결합도는 모듈과 모듈 사이에 연관된 정도를 나타냅니다. 모듈 간에 의존성이 얼마나 있는지를 보는 거죠. 근데 모듈과 모듈 간은 서로 독립적일수록 좋기 때문에 이 결합도라는 거는 낮을수록 좋습니다.

57:53
좋은 모듈화의 원칙들은 복잡도와 중복성을 줄이고 또 일관성을 유지하는 것입니다. 그리고 유지보수도 용이해야 되겠구요. 응집도는 강하고 결합도가 약해야 독립적인 모듈이 될 수 있습니다. 모듈 간의 효과적인 제어를 위해서 이제 설계상에서도 계층적으로 구조를 설계할 필요가 있겠고요. 모듈의 기능도 예측할 수 있도록 잘 정의되어야 되겠습니다. 예를 들어서 내가 메신저 앱에 채팅 모듈을 만들어야 되는데 거기에 다른 기능들도 살짝살짝 섞여 있으면 조금 이해를 하기도 어렵겠고 모듈의 기능이 예측도 잘 안 되겠죠. 마지막으로, 다른 환경에서도 이 모듈을 재사용할 수 있게끔 이식성을 고려해서 설계가 되어야 되겠습니다. 응집도에 대해서 조금 더 자세하게 알아보겠습니다.

58:49
이 응집도는 응집도가 낮은 것부터 높은 것까지 7가지 유형이 있어요. 가장 낮은 응집도는 우연적인 응집도예요. 이는 모듈 내의 요소들이 서로 아무런 관련이 없는 경우예요. 그다음으로, 논리적인 응집도가 있는데, 이제부터는 비슷한 성격의 요소들이 그래도 한 모듈에 있는 경우입니다. 다음으로, 시간적 응집도는 같은 시간에 실행되는 요소들이 그래도 한 모듈에 있는 경우를 말해요. 조금 더 강화된 개념이죠. 절차적인 응집 또는 요소들이 순차적으로 실행되는 경우를 말해요. 통신적인 응집도는 같은 입출력을 사용하는 요소들이 한 모듈에 있는 경우예요.

59:41
순차적인 응집도는 한 요소의 출력이 다른 요소의 입력으로써 사용되면서 이렇게 체인처럼 연계가 되어서 동작을 하는 경우입니다. 응집도가 아참 마지막으로, 가장 높은 응집도인 기능적 응집도는 모듈 내에 모든 요소가 단일한 목적을 위해 수행되는 이상적인 경우의 응집도입니다. 이렇게 응집도가 높을수록 모듈의 독립성이 높아져서 유지보수가 쉬워지고 재사용성이 되게 높아지게 됩니다. 이번에는 결합도에 대해 알아보겠습니다. 결합도는 모듈과 모듈 간의 연관된 정도를 나타내는 척도이고 낮은 것이 좋다고 말씀드렸습니다. 결합도도 높은 것부터 낮은 것까지 6가지 유형이 있습니다. 먼저 가장 높은 결합도는 내용 결합도입니다. 한 모듈이 다른 모듈의 내부를 직접 참조하는 경우예요.

1:00:40
다음으로, 공통 결합도는 여러 모듈이 같은 전역 데이터를 사용하는 경우를 말합니다. 참고로 전역 데이터라는 것은 어떤 모듈에서도 접근 가능한 데이터를 의미합니다. 외부결합도는 모듈들이 외부에서 선언한 데이터를 참조하는 경우예요. 제어결합 또는 한 모듈이 다른 모듈의 내부 논리를 제어하는 경우에요. 스탬프 결합도는 모듈 간의 배열이나 객체 등 복잡한 데이터 구조를 주고받는 경우를 말해요. 마지막으로, 가장 낮은 결합도인 자료 결합도는 모듈 간에 필요한 데이터만 주고받는 경우입니다. 결합도가 낮을수록 모듈 간의 독립성이 높아져서 유지보수가 쉬워지고 재사용성이 높아집니다. 때문에 우리는 항상 결합도를 낮추는 방향으로 설계를 해야 됩니다.

1:01:36
이제 팬 인과 팬아웃에 대해서 알아보겠습니다. 이 개념들은 모듈 간의 관계를 이해하는 데 도움이 됩니다. 먼저 팬 인은 어떤 모듈을 제어하는 모듈의 수를 의미합니다. 쉽게 말해서 그 모듈을 호출하는 다른 모듈의 수예요. 펜 아웃은 한 모듈이 제어하는 다른 모듈의 수를 의미합니다. 즉 그 모듈이 호출하는 다른 모듈의 수를 말하는 거죠. 예를 들어서 여기 모듈 d에 fan in과 fan out을 계산한다고 가정해 봅시다 위에서 아래로 모듈이 진행된다고 가정했을 때 d로 화살표가 들어오는 모듈은 a와 b 2개입니다. 그래서 d의 fane는 2개입니다. 모듈이 이 모듈에 의해서 호출이 되기 때문에 이렇게 펜 e는 e다 라고 할 수 있겠고요.

1:02:33
반대로 d에서 나가는 화살표는 여기 f와 gh 세 개가 있죠. 그렇기 때문에 제어를 하는 모듈의 수는 3개 즉 팬아웃은 3개다라고 할 수 있겠습니다. 일반적으로 팬인이 높고 팬아웃이 낮은 모듈이 좋은 모듈로 평가가 됩니다. 이 모듈이 많이 재사용되면서도 다른 모듈에 대한 의존성은 낮다는 것을 의미하기 때문에 fane는 높을수록 좋고 fan out은 낮을수록 좋습니다. 모듈에 기반한 소프트웨어 설계에는 5가지 유형이 있습니다. 먼저 여기 5가지 설계가 있는데요.

1:03:25
첫 번째로, 자료 구조 설계는 데이터를 어떻게 저장하고 접근하는지 결정하는 것입니다. 두 번째로, 아키텍처 설계는 시스템의 전체적인 구조를 결정하는 것이에요. 세 번째로, 인터페이스 설계는 시스템 내부와 외부 사이의 데이터와 기능 교환 방식을 정의합니다. 프로시저 설계는 모듈의 작업 단위와 그들 간의 관계를 정의하는 것이에요. 마지막으로, 협약에 의한 설계는 소프트웨어 컴포넌트 간의 상호작용을 명확하게 정의해서 상호작용을 보장하는 그런 설계 방식입니다. 이 중에서 위에 5개의 설계는 모두 상위 설계라고 부릅니다. 조금 높은 곳에서 시스템 전반적인 구조와 동작 원리를 결정한다고 생각을 하시면 될 것 같구요.

1:04:20
저희가 말씀 얘기했던 모듈 설계 같은 경우에는 이제 각 모듈의 세부적인 내용을 설계하는 거기 때문에 하위 설계에 해당이 됩니다. 이렇게 다양한 설계 유형을 이해하고 적절히 활용하면 더 효율적이고 유지 보수가 쉬운 소프트웨어를 만들 수 있겠습니다. 소프트웨어 설계 과정은 크게 두 가지 접근 방식으로도 분류를 할 수 있습니다. 상향식 설계와 하향식 설계인데요. 상향이라는 말처럼 이제 아까 말씀드렸던 상위 설계와 하위 설계랑은 좀 다른 개념입니다. 상향은 말 그대로 방향이 있다 보니까 아래에서 위를 본다 그리고 하향은 위에서 아래를 본다 이렇게 이해를 하시면 될 것 같아요. 상향식 설계는 가장 작은 단계인 최하위 수준에서부터 각각의 모듈을 설계를 시작해서 점점 큰 단위로 올라가면서 설계하는 방식입니다.

1:05:18
마치 작은 레고 블록들을 하나씩 쌓아올리는 것과 비슷하죠. 각각의 작은 모듈을 만들고 테스트한 다음에 이것들을 조합을 해가지고 더 큰 하나의 시스템까지 만들어 갑니다. 반면에 하향식 설계 같은 경우에는 가장 큰 단위에서 시작을 해가지고 점점 작은 단위로 분할을 해나가면서 개발하는 방식입니다. 설계하는 방식입니다. 전체 시스템의 주요 기능부터 시작을 해 가지고 이를 더 작은 기능들로 나누어 가는 거죠. 큰 그림을 그리고 나서 세부 사항을 채워나가는 방식과 비슷합니다. 이런 하향식 설계의 장점은 시스템의 구조를 먼저 파악을 할 수 있다는 겁니다. 또 모듈 간의 interface가 미리 정의되어 있기 때문에 나중에 통합을 하기가 더 쉽습니다. 근데 하향식 설계에서는 낮은 레벨의 데이터 구조에 대한 세부 사항이 초기 단계에서부터 어느 정도는 필요할 수 있다는 점을 유의해야 되겠습니다.

1:06:17
그리고 이거는 때때로 설계할 초기에 너무 많은 세부 사항을 고려해야 돼서 어쩌면 상향식 설계에서 최하위 수준의 각각의 모듈을 설계하는 것과 크게 달라지지 않을 수도 있다라는 점을 좀 주의할 필요가 있겠습니다. 실제 프로젝트에서는 상황에 따라서 이 2가지 방식들을 적절하게 혼합을 해서 사용하는 경우가 되게 많습니다. 또 이를 통해서 각 방식의 장점을 극대화할 수 있겠죠. 이번에는 코드 설계에 대해 알아보겠습니다. 코드 설계란 데이터를 분류하거나 사물을 표현하기 위해 코드를 만드는 과정을 말합니다. 코드는 여러 가지 기능을 합니다. 정보를 간소화할 수도 있고 표준화할 수도 있고 분류하고 식별하는데 또 도움을 주게 됩니다. 코드 설계에는 여러 가지 종류가 있는데, 4가지를 제가 가져왔습니다. 첫 번째로, 연상 코드입니다. 코드만 보고도 대상을 떠올릴 수 있게 약호를 통해서 대상을 연상할 수 있게끔 하는 코드입니다.

1:07:17
예를 들어서 제가 영어 네 자리로 약호를 만들기로 정했다고 가정하면은 이 테슬라라는 회사를 tsla 이런 식으로 약호를 지어서 연산 코드를 만들 수 있겠죠. 두 번째는 블록 코드입니다. 공통점이 있는 것들을 블록으로 묶고 각 블록 내에서 번호를 매기는 방식입니다. 우편번호가 대표적인 예시죠. 세 번째는 순차 코드입니다. 기준에 따라서 순서대로 번호를 매기는 단순한 방식입니다. 1번 2번 3번 이런 식으로 이어지게요 마지막으로, 표의 숫자 코드는 물건의 무게나 면적 같은 물리적인 수치를 이용해서 만든 코드입니다.

1:08:07
예를 들어서 옷 사이즈 170 70이라 하면은 170cm의 키를 가지고 몸무게가 70인 사람한테 맞는 옷이다. 뭐 이런 의미를 나타낼 수 있겠습니다. 이렇게 다양한 코드 설계 방식을 이해하고 적절하게 활용하면은 데이터를 더 효율적으로 관리하고 처리할 수 있습니다. 그런데 이런 코드들을 사용할 때 내가 코드의 규칙을 잘 못 지켜서 오류가 나는 경우들이 간혹 있는데, 그런 경우들의 종류에 대해서도 알아봅시다 이런 종류가 어떤 종류의 오류인지 물어보는 시험 문제들이 간혹 나오기 때문에 제가 이 부분도 정리했습니다. 먼저 4번 트랜스크립션 오류입니다. 한 글자를 잘못 쓴 경우입니다. 예를 들어서 코리아 대신에 코레스라고 순서를 잘못 쓴 경우죠 글자를 잘못 쓴 경우죠 두 번째로, 전이 오류입니다.

1:09:03
연속된 두 글자의 순서가 바뀐 경우입니다. 코리아를 a와 e의 순서를 바꿔 쓴 경우가 이거에 해당합니다. 생략은 이렇게 한 글자를 빼먹은 경우를 말하고요. 처음과는 반대로 불필요한 글자가 한 글자 더 들어간 경우를 말합니다. 이중 전이 오류는 이런 전이 오류가 두 번 발생한 경우입니다. 글자가 두 번이 바뀐 거죠. 마지막으로, 이미 오류는 이런 오류들이 여러 가지가 두 가지 이상 복합적으로 발생한 경우를 의미합니다. 이렇게요 이렇게 이런 오류들이 어떤 오류인지 이해하고 더 주의한다면은 코드 사용 시 발생할 수 있는 실수를 줄일 수 있습니다. 그리고 이런 오류를 사전에 감시해서 예외 처리하는 시스템을 설계할 때도 도움이 됩니다.

1:09:58
이제 하이포와 소프트웨어 아키텍처에 대해 알아보겠습니다. 하이포는 하이에라키 인풋 프로세스 아웃풋의 약자로 하향식 소프트웨어 개발을 위한 문서와 도구입니다. 이 문서와 도구는 가시적인 도표 가시적 도표 총체적 도표 세부적 도표의 세 종류의 도표로 구성이 되고요. 하이폰은 기능과 데이터의 관계를 쉽게 표현할 수 있고 또 보기 쉽고 이해하기 쉽다는 장점들이 있습니다. 요런 도표들을 예시로 생각을 하시면 될 것 같아요. 소프트웨어 아키텍처는 소프트웨어의 기본 구조를 나타냅니다. 마치 건물의 설계도와 같은 역할을 하게 되는데 이런 아키텍처는 소프트웨어를 설계하고 개발할 때 가이드라인이 되고 고객들의 품질 요구 사항을 반영해서 품질 속성을 결정하는 데 도움을 줍니다.

1:10:56
소프트웨어 아키텍처를 표현하는 방법 중의 하나로 4 플러스 1 원 뷰라는 게 있습니다. 고객의 요구사항을 정리한 시나리오를 다양한 관점으로 바라보는 방법인데요. 유즈케이스 뷰 논리뷰 프로세스 뷰 구현 뷰 배포 뷰의 다섯 가지 뷰로 구성이 됩니다. 이거를 통해서 소프트웨어의 여러 측면을 종합적으로 이해할 수 있습니다. 간혹 시험에서 이 4 플러스 원 뷰의 아키텍처가 어떤 뷰가 있냐 뭐 이렇게 물어보는 경우가 있는데, 이 각각의 뷰가 뭘 말하는지에 대해서 깊게 이해하실 수도 있겠지만, 시험 문제에서는 보통 여기 중에 하나를 살짝 바꿔 가지고 내는 형태이기 때문에 시험이 급하다면은 그냥 이런 뷰가 있다고만 이해를 하셔도 되겠습니다. 소프트웨어 아키텍처 패턴에 대해서도 알아보겠습니다.

1:11:55
아키텍처 패턴은 자주 발생하는 설계의 문제를 해결하기 위한 일종의 템플릿이라고 볼 수 있겠습니다. 특정 소프트웨어의 설계에 이미 있는 아키텍처 패턴을 적용한다면은 설계를 단순화하고 유지 보수성을 높일 수 있겠죠. 제가 몇 가지 시험에 자주 출제되는 주요 패턴들을 소개를 해드리겠습니다. 첫번째로, 계층화패턴입니다. 계층화 패턴은 시스템을 여러 층으로 나누는 방식입니다. 이 층은 특정한 역할을 담당하게 되는데 데이터베이스 층 비즈니스 로직층 사용자 인터페이스층 등등으로 나누어 가지고 볼 수 있겠습니다. 두 번째는 클라이언트 서버 패턴인데요. 시스템을 클라이언트와 서버 이렇게 두 부분으로 나누어져 있다고 구성한 나누고 구성한 패턴입니다. 클라이언트는 서비스를 요청하고 서버는 클라이언트의 그런 요청을 처리하게 됩니다.

1:12:54
가장 대표적인 걸로 웹 어플리케이션이 그 예시인데요. 네이버나 구글 같은 검색엔진을 생각해 보시면은 사용자는 검색창에 이렇게 네모난 검색창에다가 검색어를 넣게 되고 검색 버튼을 누르면 서버는 그 요청을 처리해서 키워드에 맞는 결과물을 내놓게 되는 거죠. 세 번째로, mvc 패턴입니다. mvc 패턴은 모델 뷰 컨트롤러 시스템을 구분하게 됩니다. 여기서 가장 중요한 점은 데이터와 데이터를 처리하는 노직을 모델로 묶고 사용자 ui는 뷰로 묶고 그리고 그 사이에 상호작용을 담당하는 컨트롤러를 따로 두었다는 점입니다.

1:13:48
그림으로 표현하자면 이게 모델 그리고 여기에는 뷰가 있고 사용자가 볼 수 있는 화면들이 여기 있겠죠. 이 사이에 사용자와 즉 뷰에서 온 요청과 모델의 상호작용을 관리하는 컨트롤러가 이 중간에 있는 구조라고 이해를 하시면 되겠습니다. 파이프필터패턴입니다. 파이프 필터 패턴은 데이터 처리를 여러 단계로 나누어 설계한 패턴입니다. 각 단계를 필터로써 구현하는데 데이터는 파이프를 통해 필터 간을 이동합니다. 이 패턴은 데이터 처리 과정을 유연하게 조정할 수 있게 해줍니다.

1:14:40
마스터 슬레이브 패턴은 중앙에 있는 마스터가 여러 대의 슬레이브를 제어하는 구조입니다. 여러 대의 장비가 있는 분산 시스템에서 주로 사용이 됩니다. 예를 들어서 한 대의 마스터가 있고 여러 대의 데이터베이스 서버가 있다면은 특정 연산이 복잡한 연산이 들어왔을 때 이 마스터 하나가 너는 무슨 일을 하고 너는 무슨 일을 하고 이런 식으로 균일하게 작업을 분배하는 형태인 거죠. 마지막으로, 브로커 패턴은 클라이언트와 서버 사이에 브로커라는 중개자를 두는 방식입니다. 브로커는 클라이언트의 요청을 적절한 서버로 전달하는 역할을 합니다. 이런 패턴들은 각각 장단점이 있고 상황에 따라서 적절한 패턴을 선택하거나 여러 패턴을 조합해서 사용하게 됩니다.

1:15:36
이를 통해서 효율적이고 유지보수가 쉬운 소프트웨어를 설계할 수 있습니다. 이상으로 오늘 강의 마치겠습니다. 감사합니다. 안녕하세요. 여러분 오늘은 애플리케이션 설계 두 번째 시간입니다. 애플리케이션 설계의 경우 공통 모듈 설계와 객체 지향 설계 두 단원으로 나뉘어져 있는데, 각각의 양이 많아 하나씩 나누어서 진행하고 있습니다. 오늘은 두 번째로, 객체지향 설계에 대해 알아보겠습니다. 객체지향 설계의 핵심 개념인 객체에 대해 알아봅시다 객체란 무엇일까요? 실세계에 존재하거나 생각할 수 있는 우리 주변에 있는 모든 것들이 객체가 될 수 있습니다. 예를 들어서 여러분들이 지금 앉아있는 의자도 객체고 여러분들이 들고 있는 펜도 객체입니다. 심지어 여러분 자신도 하나의 객체라고 볼 수 있어요. 객체는 중요한 두 가지 특성을 가지고 있습니다. 바로 속성과 동작입니다.

1:16:36
속성은 객체가 가진 특징이고 동작은 객체가 할 수 있는 일입니다. 예를 들어서 사람이라는 객체를 한번 생각해 봅시다 사람의 속성으로는 이름이나 나이 성별 등이 있겠죠. 동작으로는 뭐 사람이니까. 걸을 수도 있고 말을 할 수도 있고 책을 읽을 수도 있고 또 더 있겠죠. 이번에는 다른 예를 들어서 또 한번 봅시다 자동차를 객체로 생각해 볼까요? 자동차의 속성으로는 어떤 것들이 있을까요? 뭐 색상 모델 제조년도 등이 있겠죠. 예를 들어서 빨간색 세단 2020년식 이런 것들이 속성이 됩니다. 자동차의 동작은 무엇이 있을까요? 달리기 멈추기 방향 전환하기 등등이 있겠네요. 이런 것들을 객체 지향 설계에서는 동작을 method라고 부르기도 합니다.

1:17:33
이렇게 자동차라는 하나의 객체를 속성과 동작 즉 method로 생각을 할 수 있습니다. 실제 자동차를 생각할 때 그 특징과 기능을 나눠서 생각하는 것과 비슷하죠. 이런 방식으로 우리 주변의 모든 것들을 객체로 바라보고 그 특성을 속성과 동작으로 나누어 생각하는 것이 객체 지향적 사고의 기본입니다. 그리고 이를 통해서 복잡한 현실 세계를 프로그래밍으로 표현할 수 있게 되는 거죠. 그리고 속성과 동작뿐만 아니라 여기 고유 식별자도 객체를 정의하는 데 꼭 필요합니다. 저희 개개인이 고유한 주민등록번호나 자동차의 경우 차량 넘버를 통해서 고유성을 부여하듯이 고유한 식별자가 각 객체에도 부여가 돼야 되는 거죠. 그리고 그런 객체에 속성값을 부여함으로써 객체의 상태가 정의됩니다.

1:18:30
이번엔 좀 더 추상적인 개념의 객체를 한번 살펴보겠습니다. 예를 들어서 저희가 계속 사용하고 있는 메신저 앱에 알림 기능을 객체라고 생각을 해 보겠습니다. 알림 객체의 속성으로는 어떤 것들이 있을까요? 먼저 뭐 메세지 알림 타입이 있을 거고, 그리고 이런 알림의 제목 시간 보낸 사람 등등이 있을 수 있어요. 예를 들어서 다양한 타입 중에 메세지 타입의 알림이 있고 제목은 첫인사 내용은 헬로 시간은 오후 5시 보낸 사람은 홍길동이라고 정의를 할 수 있겠죠. 그러면 이런 알림 객체의 동작 메소드는 무엇이 있을까요? 알림을 사용자에게 보여주거나 알림을 저장하거나 알림을 삭제하는 과정 등등이 있을 수 있습니다. 이처럼 저희가 일상에서 접하는 모든 것 심지어 눈에 보이지 않는 알림이라는 추상적인 개념까지도 객체를 표현할 수 있습니다.

1:19:28
이런 것들이 바로 객체 지향적 사고의 핵심입니다. 이런 방식으로 생각을 하면은 복잡한 메신저 앱이라는 시스템들도 여러 개의 객체로 나누어서 설계를 할 수 있게 됩니다. 각각의 객체들은 자신만의 속성과 동작을 가지게 되고 이것들이 서로 상호 작용하면서 전체 시스템이 동작하게 되는 거죠. 제가 메신저 앱의 알림 기능을 실제로 구현한 간단한 코드도 함께 공유 드립니다. 실제로 개발을 할 때는 이렇게 동작들이 함수가 되어서 서로 상호 작용하면서 객체가 구현되는구나라고 참고 정도만 하시면 될 것 같습니다. 이제 객체지향 설계에 대해서 좀 더 본격적으로 알아볼까요? 객체지향 설계란 소프트웨어를 여러 객체로 나누고 이 객체들이 서로 상호작용을 하게 하면서 프로그램을 만들어나가는 방법입니다.

1:20:27
쉽게 이해하기 위해서 메신저 앱을 다시 예로 들어 볼게요 메신저 앱의 맨션화기 기능을 만든다고 생각해 봅시다 이 맨션화기 기능을 객체지향적으로 설계하려면 어떻게 해야 될까요? 또 우선 이 기능을 맨션하기라는 기능을 여러 개의 객체로 잘게 쪼갤 수가 있습니다. 벤션을 하기 위해서는 누군가를 언급해야 될 거고, 그 언급을 하는 거를 메시지로 또 날려야 되니까. 언급 객체와 메시지 객체가 필요하겠죠. 그리고 누구를 맨션할지 명시해야 되니까. 연락처를 검색하는 객체 그리고 맨션된 사용자한테 알림을 보내는 알림 객체까지 여러 가지로 나눌 수가 있겠죠. 이런 객체들이 서로 정보들을 주고받으면서 최종적으로 맨션하기라는 기능 하나가 완성이 되는 거죠. 이번엔 다른 예를 한번 들어볼까요?

1:21:20
메신저 앱의 선물하기 기능을 한번 객체 지향적으로 설계해 봅시다 선물하기 기능은 어떤 객체들로 구성이 될 수 있을까요? 먼저 선물을 할 사람을 찾기 위해서 연락처 검색 객체가 동작을 하고 선물을 고를 때는 선물 검색 객체가 활성화될 겁니다. 선물을 결제할 때는 결제 객체가 선물이 전송이 되면은 선물을 받는 사람한테 알림 객체를 통해서 알림이 가겠죠. 이렇게 기능들을 여러 객체로 나누게 되면은 각 객체들을 독립적으로 개발하고 테스트할 수 있어요. 또 나중에 기능을 수정하거나 확장할 때도 더 쉽게 할 수 있습니다. 예를 들어서 결제 방식을 내가 무슨 무슨 페이를 또 도입해 가지고 추가하고 싶다라고 하면은 결제 객체만 살짝 수정을 하면 되는 거고, 새로운 종류의 선물을 추가하고 싶다면은 선물을 검색하는 객체만 수정을 하면 됩니다.

1:22:17
이렇게 독립적으로 각 객체들을 수정할 수 있는 것이 바로 객체 지향 설계의 장점이기도 합니다. 이제 객체 지향 설계의 주요 구성 요소에 대해서 좀 더 자세하게 알아보겠습니다. 첫 번째로, 객체입니다. 객체는 우리가 앞서 배운 대로 실 세계에 존재하거나 생각할 수 있는 모든 것들을 말합니다. 두 번째는 메서드입니다. 메서드는 객체가 수행할 수 있는 동작이나 기능을 말합니다. 예를 들어서 자동차 객체의 달리기나 멈추기 같은 행위들이 메서드가 됩니다. 번째는 속성입니다. 객체의 상태를 나타내는 데이터입니다. 자동차 객체에서는 색상이나 모델이 속성이 되겠죠. 네 번째는 클래스입니다. 클래스는 비슷한 특성들을 가진 객체를 묶어 정의한 것입니다. 예를 들어서 자동차라는 클래스에는 세단 트럭 경차 등의 객체가 포함될 수 있습니다.

1:23:15
다섯 번째는 인스턴스입니다. 이는 클래스를 바탕으로 실제로 생성된 객체를 말합니다. 소나타라는 특정 자동차가 자동차 클래스의 인스턴스가 되는 거죠. 마지막으로, 메시지입니다. 메시지는 객체들이 서로 통신하는 방법입니다. 객체들에게 어떤 동작을 수행하도록 요청하는 것을 메세지로 보낸다고 표현합니다. 이런 구성 요소들을 이용해서 소프트웨어를 설계하면 현실 세계의 모습을 더 잘 반영할 수 있고 직관적으로 이해하기 쉬운 프로그램을 만들 수 있습니다. 객체 지향 설계에는 솔리드라는 다섯 가지 중요한 원칙이 있습니다. 이 원칙들은 유지보수와 확장성에 도움을 주는 좋은 소프트웨어를 만들기 위한 가이드라인이라고 생각을 하시면 되겠습니다.

1:24:12
각각의 원칙들은 시험에 정말 자주 출제되고 뭐 이런 특성을 가진 법칙이 무엇일까요? 라는 형태로 많이 출제가 되니까. 참고해 주세요. 각각의 원칙들을 간단하게 설명드리겠습니다. 첫 번째는 단일 책임의 원칙입니다. 한 클래스는 하나의 책임만 가져야 된다는 원칙입니다. 예를 들어서 뭐 한 사람이 여러 가지 일을 동시에 하면 힘들듯이 하나의 클래스도 하나의 기능이나 역할만 담당해야 효율적이라는 것입니다. 두 번째는 개방 폐쇄의 원칙입니다. 말이 좀 어려울 수도 있는데, 소프트웨어 객체들은 확장에 대해서는 열려 있어야 하고 변경 수정에 대해서는 닫혀 있어야 된다는 원칙입니다. 새로운 기능을 추가할 때 기존 것들은 수정하지 않아야 되고 그대로 둘 수 있어야 된다는 의미입니다. 세 번째는 리스코프 치환의 법칙입니다.

1:25:09
프로그램의 객체는 프로그램의 정확성을 떨어뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 된다는 원칙입니다. 쉽게 말해서 부모 클래스를 상속받은 자식 클래스는 부모 클래스의 역할을 완벽히 수행할 수 있어야 한다는 원칙입니다. 뒤에 상속과 관련된 내용도 나오니까 그 부분을 한번 보시고 다시 이 내용을 곱씹어 보시면 이해가 되실 거라고 생각이 됩니다. 네 번째는 인터페이스 분리의 원칙입니다. 이 원칙은 클라이언트가 자신이 사용하지 않는 메서드에 의해서 의존하도록 강요받지 않아야 한다는 것입니다. 쉽게 말해서 필요 없는 기능은 과감하게 제거되어야 된다는 뜻입니다. 마지막으로, 의존성 역전의 원칙입니다. 이 원칙은 상위 수준 모듈이 낮은 수준의 모듈에 의존해서는 안 되고 둘 다 어느 정도는 추상화에 의존해야 된다는 겁니다.

1:26:07
구체적인 것보다는 추상적인 것에 더 의존해야 된다는 건데요. 추상적인 추상화라는 개념이 뭐냐면은 어떤 작업을 세부 작업 없이 일단은 큰 틀에서 정의하는 걸 말해요. 그러면은 그 작업을 어떻게 할지 세부적으로 신경 쓰지 않고 나중에 구체적인 행동을 바꿀 수 있게 되기 때문이에요. 이런 솔리드 원칙들을 잘 따르면은 유지 보수가 쉽고 확장성 있는 소프트웨어를 만들 수 있습니다. 참고로 시험에 나올 때 이런 내용들을 선지로 제시하고 원칙에 대해서 물어볼 수 있는데, 이런 원칙을 꼭 한글로 물어본다는 법이 없어요. 그냥 저희가 객관식 선지에는 이렇게 영어로만 4개가 나올 수도 있기 때문에 항상 영어 표현에 대해서도 주의를 하시면 좋겠습니다. 제가 항상 영어로 선지가 나올 법한 것들에는 이렇게 영어로 부연 설명을 더 달아놓겠습니다.

1:27:05
이제 객체 지향 설계의 주요 특징들에 대해서 알아보겠습니다. 다형성부터 관계성까지 여섯 가지의 특징이 있습니다. 이 특징들에 대해서는 특징 자체를 다음 중에 객체 지향 설계의 특징이 아닌 것은 하고 물어볼 때도 있고 개별 특성의 설명에 대해서 물어볼 때도 있어서 개별 특성에 대해서 여러 번 자세히 보시면 좋을 것 같습니다. 하나씩 제가 설명을 드리겠습니다. 첫 번째 특징은 다형성입니다. 다형성이란 하나의 부모 즉 상위 객체를 여러 형태로 활용할 수 있게 되는 것을 의미합니다. 한 단어가 여러 의미를 가질 수 있는 것이랑 비슷합니다. 예를들어서, 뭐 동물이라는 클래스 안에 소리내기라는 메서드가 있다고 가정을 해보겠습니다.

1:27:59
이런 객체의 특징을 그대로 상속받은 하위 클래스가 있을 수 있어요. 바로 개클래스랑 고양이 클래스예요. 여기도 마찬가지로 각각 소리라는 메서드가 들어가 있을 텐데 이 소리라는 거는 상위 클래스의 동작을 그대로 넘겨받았지만 개에서는 개가 소리를 낼 때는 이 소리라는 method는 먹먹이라는 소리를 낼 거고, 고양이 객체에서는 야옹이라는 소리를 낼 거예요. 같은 이름의 method지만 객체에 따라서 다른 동작을 하게 되는 거예요. 제가 방금 말씀드린 게 바로 오버라이딩이라는 개념입니다.

1:28:48
오버라이딩은 크게 2가지 방식으로 구현이 되는데 이렇게 부모 클래스에서 정의한 소리라는 메서드를 하위 클래스에서 다르게 각각 재정의할 수 있는 거를 오버라이딩이라고 부르게 돼요. 다른 하나는 오버로딩인데 같은 객체 내에서 매개변수의 유형과 개수를 다르게 해서 같은 이름의 메서드를 여러 개 정의할 수 있는 거예요. 뭐 예를 들어서 개의 클래스에서 소리라는 클래스를 여러 번 쓸 수 있는 거죠. 이 소리라는 클래스에 분노라고 들어가면 화났을 때 짖는 소리를 하나 나타내는 메서드가 되는 거고, 분노가 아니라 간신 이라고 하면은 간식을 찾을 때 내는 소리가 되는 거죠. 이런 식으로 같은 클래스 안에서도 여러 개의 메서드를 여러 개 정의할 수 있습니다.

1:29:46
객체지향 설계의 두 번째 주요 특징은 캡슐화입니다. 캡슐화란 객체의 속성과 메서드를 하나로 묶고 실제 구현 내용의 일부를 외부에 감추어 은닉하는 것을 의미합니다. 예를 들어서 스마트폰은 복잡한 내부 구조를 가지고 있지만 사용자는 사실 그 내부 구조를 알 필요가 없잖아요. 그렇기 때문에 화면만 눌러서 원하는 기능을 다 사용할 수 있죠. 이렇게 굳이 알 필요가 없는 내부의 구조를 잘 숨기는 거를 캡슐화라고 부르게 됩니다. 캡슐어 같은 경우는 객체 데이터를 이렇게 보호할 수 있고 정보를 숨겨서 필요한 interface만 밖으로 드러내기 때문에 객체 지향 설계의 또 다른 특징인 정보 은닉하고 가장 관계가 있는 개념입니다. 캡슐화의 장점은 아래와 같습니다. 첫 번째로, 코드의 복잡성을 줄이고 인터페이스가 단순화됩니다. 때문에 소프트웨어의 재사용성을 높일 수 있게 됩니다.

1:30:46
그리고 객체 내부 구현을 변경하더라도 외부 사용자 입장에서는 영향을 미치지 않기 때문에 오류의 파급 효과가 줄어듭니다. 오류가 생겨도 실제로 사용자에게 느껴지는 바는 적어질 거다 이런 의미이죠. 객체 지향 설계의 세 번째 주요 특징은 상속입니다. 상속은 이미 정의된 클래스의 속성과 메서드를 하위 객체가 물려받는 것을 말합니다. 우리가 부모님으로부터 어떤 닮은 부분을 물려받는 것과 비슷한 개념이죠. 예를 들어서 자동차라는 클래스 객체가 있다고 생각해 봅시다 이런 클래스는 모든 차량의 공통적인 속성과 동작 예를 들면은 색상 모델 달리기 멈추기 이런 특성들을 가지고 있어요.

1:31:39
이를 바탕으로 한 하위 클래스인 오픈카라는 클래스를 만들 때 얘네들은 자동차라는 클래스를 베이스로 해서 이거를 상속받아서 만들 수 있습니다. 이렇게 되면은 오픈카의 클래스는 상속을 받은 차량 클래스에 모든 속성을 자동으로 가지게 되고 여기에 추가로 각자의 고유한 특성을 정의할 수 있습니다. 예를 들어서 뭐 오픈카 클래스니까 뚜껑 열기라는 메서드를 추가할 수 있고 오토바이라면은 기울이기라는 메서드를 추가할 수 있겠죠. 상속의 장점은 여러 가지가 있는데요. 뭐 코드의 재사용성도 높이고 기존 객체를 단순히 확장해서 새로운 객체를 쉽게 만들 수 있다는 장점이 있습니다. 그치만 상속이라는 거를 과도하게 사용해버리면은 클래스 간의 관계가 또 복잡해질 수 있기 때문에 어느 정도 주의는 필요하겠습니다. 객체 지향 설계의 네 번째 주요 특징은 추상화입니다.

1:32:38
추상화란 복잡한 시스템에서 가장 중요한 핵심적인 개념만 드러내고 세부 사항은 감추는 것을 의미합니다. 지도를 그릴 때 세세한 정보를 다 표현하지 않고 필요한 정보만 선별해서 나타내는 것과 비슷합니다. 예를 들어서 자동차를 프로그래밍으로 표현한다고 가정을 해보면은 자동차의 모든 부품과 기능을 다 구현하려면 너무 복잡할 거예요. 대신에 우리는 출발하기 멈추기 방향 전환하기와 같은 핵심 기능만 추상화해서 먼저 구현을 할 수 있겠습니다. 상위 레벨에서는 이렇게 공통적인 특성을 위주로 정의를 하고 구체적인 특성으로 갈 때는 상속을 받아가지고, 거기서 구체화를 한다. 이렇게 생각을 하시면 될 것 같애요. 소프트웨어 설계를 할 때 추상화 기법으로는 크게 자료를 추상화하고 제어를 추상화하고 과정을 추상화하는 3가지로 나뉘어지게 됩니다.

1:33:38
각각이 무엇인지에 대해서는 조금 더 찾아보셔도 되겠지만, 시험에서는 사실 이렇게 3개 중에 1를 다른 걸 끼워 넣어 가지고 물어보는 경우가 되게 많아서 여기서는 이런 것들이 있다. 정도만 다루도록 하겠습니다. 객체지향 설계의 다섯 번째 주요 특징은 정보 은닉입니다. 정보 은닉은 객체가 가지고 있는 속성과 연산 일부를 감추어서 객체 외부에서는 직접 접근이 불가능하도록 만드는 개념입니다. 아 캡슐화와 밀접한 관련이 있기는 한데 좀 더 구체적으로 데이터를 보호하는 측면에 초점을 맞추게 됩니다. 예를 들어서 은행 계좌라는 객체가 있다고 생각을 해봅시다 계좌 잔액이라는 중요한 속성이 있을 텐데 이 계좌 잔액은 직접적으로 외부에서 접근하거나 수정할 수 없도록 해야 됩니다.

1:34:37
대신에 입금하기나 출금하기라는 저희가 정의한 메서드를 통해서만 잔액을 변경할 수 있도록 하는 것이 바로 정보 은닉의 예시입니다. 이렇게 중요한 정보들이나 물리적인 코드 또는 상세한 데이터 구조들을 숨길 수가 있어요. 정보 은닉의 근본적인 목적은 이렇게 객체 내부의 복잡한 동작 또는 비밀스러운 데이터를 다른 코드가 직접 접근하지 못하도록 막아서 다시 말해서 고려하지 않은 영향을 최소화해서 유지 보수성과 확장성을 높이는 데 있습니다. 또 정보 은닉을 통해서 모듈 간의 독립성을 유지하는 데도 도움을 줄 수 있겠죠. 대신에 장점으로는 코드 수정의 유연성도 높이게 됩니다.

1:35:24
요구사항이 바뀌어도 외부에는 영향을 주지 않고 내부 구현만 바꿀 수 있기 때문에 요구사항 변화에 따라 모듈 내부의 자료 구조와 접근 동작들을 쉽게 수정할 수 있다는 장점도 있겠습니다. 객체 지향 설계의 마지막 주요 특징은 관계성입니다. 객체들 사이에 다양한 관계들을 나타내는 기법을 말하는데요. 주요 관계성 유형에는 연관화 분류화 집단화 일반화 특수화 정도가 있습니다. 먼저 연관하는 객체 간의 일반적인 관계를 말합니다. 예를 들어서 학생과 교수의 관계가 있습니다. 연관 말 그대로 연관이 되어 있다는 그런 일반적인 관계를 의미하고 영어로도 표현을 하는데 is 멤버 업이라고 표현을 합니다.

1:36:24
분류와 같은 경우에는 객체를 공통된 특성에 따라서 그룹화하는 것을 의미합니다. 예를 들어서 뭐 동물을 포유류 조류 어류로 그룹화할 수 있겠고 이거는 영어로 이즈 인스턴스 오브의 관계다 라고도 말을 하기도 합니다. 집단화는 전체와 부분의 관계를 나타냅니다. 이 부분은 독립적으로 존재를 할 수 있죠. 예를 들어서 팀과 선수의 관계를 예로 들 수 있겠는데 선수 개별은 개개인별로 독립적으로 존재할 수 있고 이런 관계를 집단화 관계라고 합니다. 영어로는 isofaltop 관계라고 합니다. 일반화 관계는 여러 클래스의 공통적인 특성을 추출해서 상위 클래스를 만드는 걸 의미합니다. 추상화랑 비슷한 개념인데요. 개랑 고양이의 공통적인 특성을 추출해서 동물이라는 상위 클래스를 만드는 게 그 예시가 될 수 있겠죠. is 어 관계라고 하고요.

1:37:24
특수와 관계도 비슷한데 반대 개념이에요. 상위 클래스를 기반으로 더 구체적이고 특수한 하위 클래스를 만드는 걸 의미합니다. 마찬가지로 영어로 이저 관계고요. 동물 클래스를 특수화해서 하위 클래스인 개와 고양이 클래스를 만들었던 예시를 생각하시면 될 것 같아요. 이런 관계성을 잘 활용하면은 현실 세계의 복잡한 관계를 프로그램에 효과적으로 반영할 수 있겠습니다. 이제 객체 지향 분석에 대해서 알아보겠습니다. 객체 지향 분석은 소프트웨어를 개발하기 위해 비즈니스 문제를 객체 지향적인 관점으로 바라봐서 분석하는 과정인데요. 시스템을 객체화 속성 클래스와 멤버 전체화 부분 등으로 잘게 나누어서 분석을 하게 됩니다.

1:38:18
이 경우에 시스템 안에 객체들이 어떻게 상호작용하는지 그 방식을 설계하는 동적 모델링이라는 기법을 사용할 수도 있습니다. 보통 또 객체 지향 분석을 할 때는 세부적인 객체들을 아랫단에서 먼저 설계하고 그것들을 하나하나씩 통합해서 최종적으로 전체 시스템을 만드는 상향식 방식을 사용합니다. 그리고 데이터와 행위를 하나로 묶어서 객체를 정의하고 이를 추상화하게 됩니다. 마지막으로, 코드 재사용을 통해서 객체 지향 분석을 통해 프로그램의 생산성을 향상하고 요구 사항 변경에 따른 시스템의 수정을 용이하게 만들게 됩니다. 이렇게 객체 지향 분석을 통해서 우리는 복잡한 문제를 더 이해하고 해결할 수 있는 구조를 만들 수 있습니다. 효율적이고 유지 보수가 쉬운 소프트웨어를 개발하는데 객체 지향 분석은 큰 도움이 됩니다.

1:39:17
객체 지향 분석을 수행하기 위한 여러 가지 방법론들도 있습니다. 오늘은 그 중에서 대표적인 몇 가지 방법론에 대해 알아보겠습니다. 먼저 코드 요돈 방법론인데요. 이 방법론은 주로 데이터 간의 관계를 나타낼 때 쓰는 엔티티 릴레이션십 줄여서 er 다이어그램을 사용해서 객체 행위를 데이터 모델링하는 데 초점을 둔 방법입니다. 두 번째로, 런바오 방법론입니다. 시험에 굉장히 많이 나오는 개념이고요. 이 방법론은 객체 동적 기능 모델 순서로 3가지 모델을 순차적으로 만들어 나가는 방법이에요. 먼저 처음 만드는 객체 모델은 시스템에 필요한 객체를 찾아내서 속성과의 관계를 규정하고 이거를 다이어그램으로 표시하는 모델링 기법입니다.

1:40:10
두 번째로, 동적 모델은 객체 간의 상호작용을 상태 다이어그램이나 사건 흐름 다이어그램 등을 통해서 시간 순으로 표현하는 방법이에요. 세 번째는 시스템의 기능을 자료 흐름도로 표현하는 방법입니다. 약간 비유를 하자면은 영화를 만들 때랑 비슷한데 이 객체라는 거는 어떻게 보면은 영화의 등장인물이 되겠고 처음에 객체라는 모델을 통해서 등장인물을 설정하고 그리고 그 등장인물들 간의 상호작용을 설정하는 스토리보드를 만들고 그리고 각 스토리보드 안에 세부 장면들의 세부 장면을 만드는 기능 모델이 있다. 이렇게 생각을 하셔도 괜찮을 것 같아요. 다음으로, 부치 방법론입니다. 부치 방법론은 설계 문서화를 굉장히 중요하게 여기고 또 다양한 다이어그램을 통해서 시스템을 표현하는 방법이에요.

1:41:10
야콥슨 방법론은 유즈 케이스라는 개념을 중심으로 분석을 수행하는 방법론이에요. 유즈 케이스는 참고로 1장에서 나온 개념인데 시스템이 사용자에게 제공해야 할 기능들을 시나리오 형태로 기술한 것을 의미합니다. 프로젝트의 특성에 따라서 적절한 방법론을 선택하거나 혼합해서 사용을 할 수 있겠죠. 디자인 패턴에 대해서 알아보겠습니다. 디자인 패턴은 소프트웨어 설계에서 자주 발생하는 문제들에 대해 일반적으로 사용하고 또 재사용 가능한 해결 기법들을 말합니다. 프로그래머들이 자주 사용하는 효과적인 코드 구조를 정리한 거라고 생각을 하시면 될 것 같은데요. 이런 디자인 패턴을 사용할 때 여러 가지 장점이 있습니다. 특정 패턴을 사용했다라고만 말해도 이 소프트웨어가 어떤 소프트웨어의 구조를 가지고 있는지 그 구조 파악이 되게 용이해집니다.

1:42:08
그리고 객체 지향 설계의 생산성을 높일 수 있습니다. 또 재사용을 위해서 개발 시간이 단축될 수 있습니다. 재사용성과 유지 보수성이 향상되기 때문이에요. 디자인 패턴은 패턴명 문제 및 배경 솔루션 사례 결과 샘플 코드 등으로 디자인 패턴을 구성시킬 수 있겠습니다. 이렇게 디자인 패턴을 잘 활용하면 더 효율적이고 유지 보수가 쉬운 소프트웨어를 개발할 수 있어요. 디자인 패턴의 대표적인 예시로 지오에프 갱 오브 4라고 불리우는 4명의 소프트웨어 전문가들이 제안한 디자인 패턴이 있는데, 이 디자인 패턴에 대해서 한번 살펴보겠습니다.

1:42:53
먼저 zof의 디자인 패턴은 크게 세 가지 구분 생성패턴 구조패턴 행위패턴으로 나눌 수 있고 이것들이 또 이 안에서 23개의 패턴으로 세분화됩니다. 생성패턴은 객체를 어떻게 생성하고 초기화할지에 대한 얘기를 하는 패턴들이에요. 이 생성패턴에는 빌더 싱글톤부터 이렇게 여러 가지 패턴들이 있게 됩니다. 구조 패턴은 클래스와 객체를 더 큰 구조로 조합하는 방법에 대한 패턴들이에요. 어댑터부터 컴퍼시까지 여러 가지 패턴들이 마찬가지로 있습니다. 행위 패턴은 정말 많은데 객체 간의 상호작용과 책임 분배를 어떻게 할지에 대한 패턴들이에요. 미디어터 비지터 커맨드 등등 여러 가지 패턴들이 있습니다.

1:43:47
이런 패턴들은 소프트웨어 개발에서 자주 발생하는 문제들에 대한 검증된 해결책을 제공합니다. 이거를 통해서 우리는 더 유연하고 재사용 가능한 코드를 작성할 수 있게 됩니다. 이번에는 gop의 주요 디자인 패턴 중에서 일부를 더 자세하게 살펴보겠습니다. 저희 필기시험에서 자주 나온 패턴 유형에 대해서만 정리를 해 보았고요. 시험이 얼마 남지 않았다. 하루 이틀밖에 안 남았다라고 하시면은 어떤 구분에 어떤 패턴이 있는지 제가 앞장에 정리해 놓은 거 정도로만 정리를 하셔도 좋겠습니다. 먼저 생성 패턴부터 시작하겠습니다. 팩토리 메서드 패턴 같은 경우에는 객체 생성을 위한 인터페이스를 정의하지만 어떤 클래스의 인스턴스를 생성할지에 대해서는 서브 클래스가 결정하도록 합니다.

1:44:41
이 패턴은 객체를 만드는 로직 자체를 캡슐화해서 코드의 유연성을 높이는 데 도움을 주게 됩니다. 프로토타입 패턴은 일단 프로토타입을 먼저 생성하고 인스턴스를 복제해서 사용하는 구조입니다. 이 패턴은 객체 생성 비용이 높을 때 되게 유용하고 기존 객체를 복제함으로써 새로운 객체를 효율적으로 생성할 수 있습니다. 싱글톤 패턴은 한 클래스에 1가지 객체만 존재하도록 제한합니다. 때문에 이 패턴은 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하고요. 생성된 객체를 어디서든지 참조할 수 있도록 하게 됩니다. 리소스 공유나 설정 관리 등에 유용하게 쓰이는 패턴입니다. 구조 패턴 같은 경우는 시험에 나온 경우가 없어 가지고 제가 제외를 시켰고 행위 패턴은 두 가지 패턴이 나온 적이 있어요.

1:45:36
먼저 스트레디지 패턴은 다양한 알고리즘을 캡슐화해서 알고리즘의 대체가 가능하도록 하는 회의 패턴입니다. 두 번째로, 미디어터 패턴은 객체 간의 통신과 지시의 역할을 하는 중재자를 두어서 객체 지향의 목표를 달성할 수 있도록 합니다. 이 패턴은 많은 패턴 간의 복잡한 상호작용을 중재자를 줌으로써 단순화하는 데 도움을 줍니다. 이런 패턴들은 각각 특정한 상황에서 유용하게 사용될 수 있고 코드의 구조와 유지보수성을 개선하는 데 도움을 줍니다. 오늘 강의는 이것으로 마치겠습니다. 감사합니다. 안녕하세요. 오늘은 소프트웨어 설계 중에서도 인터페이스 설계에 대해 다루어 보겠습니다. 소프트웨어가 복잡해짐에 따라 다양한 시스템들이 서로 통신하고 데이터를 주고받는 것이 중요해졌습니다. 이때 중요한 것이 바로 인터페이스 설계입니다.

1:46:31
오늘 강의에서는 인터페이스 설계의 전반적인 개념부터 실제적인 설계 방법까지 한번 살펴보겠습니다. 인터페이스란 무엇일까요? 쉽게 말해서 두 시스템이나 장치가 서로 소통할 수 있도록 연결해주는 매개체입니다. 우리가 흔히 사용하는 유저 인터페이스도 하나의 예시죠. 여러분들이 스마트폰을 사용할 때 화면을 터치하고 그 결과를 받는 것 이게 바로 유저 인터페이스입니다. 또 다른 중요한 인터페이스는 응용 프로그래밍 인터페이스 줄여서 api입니다. api는 시스템 간의 데이터 교환을 가능하게 하는 중요한 도구로 메신저 앱과 날씨 앱 간의 정보 교환을 예시로 한번 설명드려 보겠습니다. api의 개념을 좀 더 구체적으로 살펴보겠습니다.

1:47:26
예를 들어서 메신저 앱에서 날씨를 맨션하면은 오늘의 날씨를 알려주는 기능이 있다고 합시다. 그런데 메신저 앱 내부에는 오로지 메신저와 관련된 기능들만 있기 때문에 날씨를 알아오기 위해서는 메신저 앱이 날씨를 실제 날씨 정보를 어디선가 끌어와야 합니다. 우리가 날씨가 궁금하면은 날씨 앱을 바로 들어가서 확인하듯이 메신저 앱도 날씨 앱과 연계가 되어서 서로 확인을 해줄 필요가 있고 이렇게 어플리케이션 간에 연결이 되어 가지고 정보를 주고받는 과정을 응용 프로그래밍 인터페이스 api라고 부르는 것입니다. 메신저 앱은 날씨 앱에 정보를 요청하고 날씨 앱은 다시 메신저 앱의 정보를 돌려줌으로써 메신저 앱이 날씨 정보를 갖게 되는 것이죠.

1:48:24
좀 더 구체적으로 보면은 메신저 앱은 날씨 정보를 제공하는 날씨 앱의 서버에 요청을 보내게 됩니다. 예를 들어서 api merprovid 닷컴에 ct는 서울로 해서 서울에 날씨를 요청을 하게 되면은 해당 요청에 대해서 날씨 서버는 서울의 날씨를 다시 회신하게 됩니다. 어 이런 제이슨 파일 형태로요 이렇게 서로 다른 시스템이 api를 통해서 데이터를 주고받는 방식이 바로 인터페이스 설계의 핵심입니다. 인터페이스 설계 첫 단계도 역시 요구사항 확인입니다. 요구사항은 요구사항을 도출하고 분석하고 명세하고 확인 및 검증 이렇게 4단계로 진행이 되게 됩니다. 먼저 요구사항 도출의 단계에서는 고객의 요구를 식별하고 수집하게 됩니다.

1:49:19
그다음으로, 두 번째로, 분석을 통해서 요구사항이 논리적으로 맞는지 일관성이 있는지 검토를 하게 됩니다. 이 분석 단계에서는 요구 사항 구현을 위해 최대 얼마나 시간과 비용이 걸릴지 그 최대 제약을 설정하고 요구 사항이 타당한지 정의해서 최종적으로 문서화까지 진행하게 됩니다. 요구사항을 명세하는 방법에도 여러 가지가 있습니다. 정형명세기법과 비정형 명세기법 두 가지가 있는데, 정형 명세 기법은 사용자의 요구를 표현할 때 수학적 원리와 표기법을 이용해서 명확하게 요구사항을 표현하는 방법입니다. 예를 들어서 제테스키마 언어나 패트리넷과 같은 수학적인 도구를 사용하는 거죠. 이 방식은 비정형 명세 기법에 비해서 표현이 간결하고 누구나 객관적으로 정해진 수식을 사용해 표현하기 때문에 객관적으로 이해를 할 수 있다는 장점이 있습니다.

1:50:19
두 번째는 비정형 명세 기법인데요. 이 방식은 자연어를 기반으로 즉 우리가 하는 그냥 말을 바탕으로 사용자의 요구를 구두로 서술하는 거를 의미합니다. 자연어를 사용하게 되면은 좀 직관적일 수는 있겠지만, 명확성에 문제가 생길 수 있습니다. 객관적인 수학적인 공식이 아니라 우리가 늘상 하는 말이나 글을 통해서 하는 거기 때문에 의사소통에 문제가 있을 수 있는 거죠. 요구 사항이 불명확한 경우에 그리고 그런 불명확한 요구가 글로 담길 경우에 개발자가 이게 무슨 말인가 하고 이해를 잘 못할 수도 있겠죠. 그래서 상황에 따라서 적절한 명세 방법을 선택하는 것이 또 중요합니다. 요구사항 확인 및 검증 단계는 요구사항이 고객이 정말로 원하는 시스템을 제대로 정의하고 있는지 점검하는 단계입니다.

1:51:15
이 단계는 사실 되게 중요한 단계인데 왜 그러냐면 개발이 완료된 이후나 개발이 후반에 갔을 때 문제점이 발견될 경우에 막대한 재작업 비용이 들 수 있기 때문입니다. 때문에 검증 단계에서는 고객들의 요구사항이 실제 요구를 반영하는지 문서상의 요구사항들이 서로 상충되지는 않은지 등을 잘 점검해야 합니다. 물론 이렇게 하더라도 모든 요구사항 문제를 발견하기는 어렵습니다마는 이런 검증 과정을 통해서 최소화할 수는 있습니다. 이를 위해서 정형 기술 검토라는 기법을 사용하게 되고 여기에는 뒷장에 나올 워크스루 동료 검토 인스펙션과 같은 방법들이 포함됩니다. 정형 기술 검토 기법에 대해 좀 더 구체적으로 알아보겠습니다. 워크스루입니다.

1:52:02
워크스루는 요구사항 명세서를 미리 배포해서 사전 검토를 한 이후에 짧은 검토 회의를 통해서 오류를 조기에 검출하는 데 목적을 두는 방법입니다. 이 단계에서 단순한 테스트 케이스를 미리 이용해서 프로덕트를 수작업으로 한번 수행해 볼 수도 있겠고 사용 사료를 확장해서 명세하거나 설계 다이어그램 원시 코드 테스트 케이스 등에서도 이 워크 스롤을 적용할 수 있습니다. 때문에 복잡한 알고리즘이나 실시간 동작 병행처리와 같은 복잡한 기능이나 동작을 사전에 이해하려고 할 때 유용한 방법입니다. 두 번째로, 동료 검토는 명세서를 작성자가 직접 설명하고 이해관계자들이 그 설명을 듣고 결함을 발견하는 방식입니다. 마지막으로, 인스펙션은 외부 전문가들이 검토하는 공식적인 방법으로 가장 철저한 검토 방식입니다.

1:53:01
이 세 방식이 모든 요구사 모두 요구사항을 검토한다는 점은 동일한데 요구사항이 개발자가 사전에 받은 명세서를 혼자 보고 미리 검토를 해보냐 아니면은 요구사항 작성자의 설명을 직접 들으면서 검토하냐? 아니면은 요구사항 작성자 외에 제3의 다른 전문가나 팀이 와 가지고 아주 깊게 오류를 검토해 보냐 뭐 이런 차이가 있습니다. 이런 정형 기술 검토를 진행할 때 몇 가지 지침 사항들이 있습니다. 첫 번째 제품의 검토에만 집중해야 합니다. 검토 회의에서는 특정 제품이나 기능 코드에 대한 논의만 집중하고 다른 부분으로 논점이 흐려지지 않도록 해야 합니다. 두 번째 문제 영역을 명확하게 표현하는 것이 중요합니다. 문제가 될 수 있는 부분을 명확하게 제시해서 참석자들이 혼동 없이 이해할 수 있게 해야 합니다.

1:54:01
세 번째 논쟁과 반박을 제한해야 합니다. 제한한다는 말이 조금 와닿지 않을 수 있는데, 검토 회의는 협력적인 분위기에서 진행돼야 되고 논쟁이 길어지게 되면은 생산성이 떨어질 수 있기 때문에 최대한 짧고 굵게 진행한다는 의미에서 논쟁과 반박을 제한하게 됩니다. 비슷한 이유로 참가자의 수를 제한하고 사전 준비를 강요하는 것이 중요합니다. 너무 많은 인원이 참여하게 되면은 논의가 산만해질 수 있으므로 핵심 인원만 참여하도록 하고 모든 참가자들은 사전에 충분히 준비를 해서 검토 과정이 효율적으로 진행될 수 있도록 합니다. 인터페이스 시스템은 서로 다른 시스템이나 구성 요소들이 상호작용할 수 있도록 연결해 주는 역할을 합니다. 크게 세 가지 시스템으로 구성이 되어 있는데요. 송신 시스템 수신 시스템 그리고 중계 서버입니다.

1:54:56
먼저 송신 시스템은 연계할 데이터를 db 또는 어플리케이션으로부터 받아서 이를 송신하게 되는 역할을 하고 수신 시스템은 이런 데이터들을 받아서 처리하고 사용자에게 제공하는 역할을 하게 됩니다. 마지막으로, 중계 서버는 이 두 가지 시스템 사이에서 데이터를 중계하고 경로를 관리하는 역할을 합니다. 이렇게 각각의 시스템이 데이터를 주고받으면서 협력하는 것이 인터페이스 시스템의 핵심입니다. 시스템과 더불어서 내외부의 데이터를 송수신하고 연계하는 몇 가지 기술에 대해서도 알아보겠습니다. 먼저 소켓은 통신을 위한 프로그램을 생성해서 프로그램에 포트를 할당하고 클라이언트의 통신 요청이 있을 때 클라이언트와 서버 간을 연결해주는 역할을 하게 됩니다. 웹사이트를 접속할 때 사용하는 기술이 바로 이 소켓통신입니다.

1:55:51
두 번째로, 데이터베이스 링크는 서로 다른 데이터베이스 간에 테이블을 공유할 수 있도록 데이터베이스 링크 객체들을 만들어서 이를 이용해 서로 다른 데이터베이스 간의 테이블을 공유할 수 있도록 하는 기술입니다. 마지막으로, api는 소프트웨어가 다른 애플리케이션과 상호작용할 수 있도록 인터페이스를 제공하는 기술입니다. 아까 제가 메신저 앱과 날씨 앱을 예시로 설명드렸었던 것 같습니다. 인터페이스의 상세 설계 단계입니다. 여기서 중요한 개념 중에 하나가 미들웨어입니다. 미들웨어는 클라이언트와 서버 간의 통신을 담당하는 소프트웨어로 서로 다른 환경 간의 원활한 통신을 지원하게 됩니다.

1:56:37
여러 2기종 소프트웨어 컴포넌트들을 연결하기 위해서 준비된 인프라 구조를 제공하게 되고 컴포넌트들의 요구에 따라서 이런 컴포넌트들을 1대1 일대다 다대다 등 여러 가지 형태로 연결할 수 있게 됩니다. 또 미들웨어는 위치 투명성을 제공해서 사용자가 리소스나 서비스에 실제로 물리적인 위치를 알 필요 없이 접근할 수 있게 해주고 또 재사용 가능한 서비스의 구현을 제공하게 됩니다. 이런 미들웨어 솔루션에도 다양한 유형이 있습니다. 먼저 메세지 지향 미들웨어입니다메섹지 지향 미들웨어는 애플리케이션 간의 통신을 메세지를 통해서 비동기 방식으로 지원하는 미들웨어입니다. 비동기 방식이란 애플리케이션 간의 통신이 동시에 이루어지지 않아도 되는 방식을 의미합니다.

1:57:32
때문에 애플리케이션 에이와 비가 있을 때 에이가 어떤 요청을 보냈을 때 비가 곧바로 응답을 하지 않아도 돼요. 그렇기 때문에 느리고 안정적인 응답을 필요할 때 적합한 방법입니다. 또 송신 측과 수신 측을 연결할 때 메시지 큐라는 것을 활용하는 방법이기도 합니다. rpc는 원격 프로시저를 호출할 때 로컬 프로시저처럼 사용을 할 수 있는 방식입니다. tp 모니터는 트랜잭션의 올바른 처리를 감시하는 미들웨어이고 왓슨은 웹 어플리케이션을 실행하기 위한 소프트웨어 환경을 제공하는 미들웨어입니다. 마지막으로, 객체 기반 미들웨어 줄여서 orb는 객체 기반의 미들웨어로 코브라 표준 스펙을 구현한 방법입니다. 이상으로 오늘 강의를 마치도록 하겠습니다. 감사합니다. 안녕하세요. 오늘부터는 이장 소프트웨어 개발에 대해 다루어 보겠습니다.

1:58:33
1장에서 요구사항을 어떻게 다루고 관리하는지 배웠다면 2장에서는 실질적으로 소프트웨어 개발을 위해 무엇을 하는지를 알아보겠습니다. 이번에는 데이터 입출력 구현에 초점을 맞추겠습니다. 데이터의 입출력에 대해 공부하기 전에 먼저 자료 구조라는 말을 아실 필요가 있습니다. 저희가 책을 빌리러 도서관에 가면은 책들이 무질서하게 널브러져 있는 게 아니라 가나다 또는 알파벳 순으로 정렬이 되어 있고 또 그런 책들이 역사면 역사 뭐 과학이면 과학 이렇게 카테고리별로 분류가 되어 있어서 그 많은 책들 사이에서 저희가 빌리려는 책을 빨리 찾을 수 있죠. 어 근데 이런 책들이 무질서하게 널브러져 있었다면은 책을 찾는 데 훨씬 더 오랜 시간이 걸렸을 겁니다. 시스템도 마찬가지입니다.

1:59:22
어떤 앱이나 시스템이 사용자로부터 데이터를 입력 받거나 반대로 데이터를 보여주기 위해서는 데이터를 시스템 내부에 효과적으로 저장할 필요가 있고 무엇보다도 최대한 효율적인 구조로 저장해서 빠른 속도로 사용자에게 입력 받거나 데이터를 출력할 필요가 있겠죠. 자료 구조는 이렇게 데이터를 효율적으로 저장하고 관리하기 위한 방법들이고 또 입출력 과정에서 최고의 성능을 내기 위해서 고안된 방법론입니다. 자료 구조는 크게 선형 구조와 비선형 구조 두 가지로 나눌 수 있습니다. 먼저 선형 구조는 마치 줄이 서 있는 것처럼 이렇게 일렬로 데이터를 저장하는 방식이에요. 리스트 스택 큐 데크라는 것이 이 선형 구조에 속하게 됩니다. 비선형 구조는 조금 더 복잡한데 트리나 그래프 같은 거를 말합니다. 예를 들어서 뭐 가계도나 조직도 같은 거를 생각하면 돼요.

2:00:21
여기 보이는 그림처럼 동물을 분류할 때도 이런 구조를 사용하시는 걸 보신 적 있으실 겁니다. 척추동물 무척추동물로 나누고 그 아래에 다시 세부 분류를 하는 식이죠. 이렇게 자료를 체계적으로 정리하게 되면은 나중에 필요한 정보를 빨리 찾을 수 있게 됩니다. 이제 리스트에 대해 알아보겠습니다. 리스트는 가장 기본적인 자료 구조 중의 하나인데 데이터를 순서대로 저장하는 방식이에요. 기차처럼 데이터들이 줄지어 있다고 생각을 하면 되겠습니다. 리스트에는 두 가지 종류가 있는데, 하나는 선형 리스트고 하나는 연결 리스트예요. 선형 리스트는 메모리에 연속된 공간에 데이터를 순차적으로 저장합니다. 마치 아파트의 동호수처럼 뭐 101호 102호 103호 이런 식으로 순서대로 있고 거기에 데이터가 순서대로 저장이 되어 있는 거죠.

2:01:16
반면에 연결 리스트는 조금 다른데 각각의 요소가 데이터랑 다음 요소에 대한 포인터라는 거를 함께 포함해서 저장을 하고 있습니다. 약간 보물 찾기 게임 같은 거를 할 때 이제 우리가 보물을 바로 찾는 게 아니라 처음에는 그냥 다른 데이터가 있고 그 다음 단서가 또 어디 있는지 그 위치 정보를 알려주는 경우가 있죠. 이렇게 다음 단서에 대한 위치 정보를 알려주는 것과 비슷하다고 할 수 있겠습니다. 이렇게 하게 되면은 데이터를 메모리 공간 사이사이에 띄엄띄엄 저장하더라도 중간에 데이터를 쉽게 저장하거나 삭제할 수 있고 또 연속적으로 데이터를 저장한 것과 비슷한 효과를 준다는 장점이 있습니다. 두 번째는 스택입니다. 스택은 쌓다라는 뜻을 가진 영어 단어인데 실제로 이렇게 카드처럼 데이터를 쌓아 올리는 구조예요.

2:02:15
책상 위에 카드를 쌓는다고 생각을 해보시면 마지막 카드는 항상 가장 위에 올라가고 카드를 꺼낼 때도 맨 위에서부터 꺼내죠 이게 바로 스택의 원리입니다. 컴퓨터 용어로는 데이터를 밀어넣는 거를 푸시 삽입이라고 부르고 데이터를 꺼내는 거를 삭제 또는 팝이라고 불러요 이런 연산을 통해서 데이터를 넣고 꺼내는 리스트가 스택의 원리입니다. 그리고 이런 특성들을 레스트 인 퍼스트 아웃이라고 부르는데 마지막에 들어온 게 가장 처음 나간다 라는 의미입니다. 이런 특성들 덕분에 스택들은 웹브라우저의 뒤로 가기 같은 연산을 할 때 굉장히 도움이 됩니다.

2:03:03
브라우저가 우리가 접속했던 사이트들을 순서대로 이렇게 쌓아놓다가 사용자가 뒤로 가기 버튼을 누르면은 그 쌓인 스택에서 가장 위에 있는 사이트를 팝 처리하는 거죠. 근데 주의할 점이 하나 있는데, 이 스택이 아예 비어있는 데 데이터를 꺼내려고 하면은 언더플로우라는 오류가 발생할 수 있으니까 스택을 활용할 때는 이런 부분들을 주의해서 설계를 해야겠죠. 이런 스택은 인터럽트 처리 함수 호출 후위 표현의 연산 깊이 우선 탐색 등등에 유용하게 사용됩니다. 스택을 이용한 문제를 하나 가지고 왔습니다. 순서가 가 나 다 라로 정해진 입력 자료를 스택에 넣었다가 뺐을 때 어떤 순서로 출력이 가능할까요? 여러분 한번 생각해 보세요. 스택의 특성을 잘 생각해 보면 답을 찾을 수 있을 거예요.

2:04:04
정답은 1번 라다나가와 2번 다라나가에요. 왜 그럴까요? 스택은 마지막에 들어간 게 가장 처음으로 나온다는 점을 기억하셔야 됩니다. 그래서 가를 먼저 넣고 그 다음에 나를 넣고 이것들을 이때 팝을 하면 나가 먼저 나오게 되는 거죠. 첫번째경우는 가 나 다라가 순서대로 입력되고 이거를 다시 순서대로 팝한 경우입니다. 그렇기 때문에 라가 먼저 출력되고 그다음 다 나 가 이렇게 출력이 된 결과입니다. 때문에 가능한 결과이죠. 그럼 두 번째는 뭘까요?

2:04:57
다라나가인데 이 경우는 가나 다까지만 푸시를 하고 다를 먼저 팝을 해요. 그러면 다는 출력이 되었고 현재 스택에는 가랑 나밖에 없죠 이때 라가 다시 한번 푸시가 됩니다. 그리고 이때 다시 역순으로 팝을 해요. 그러면은 라가 나올 거고, 나가 나올 거고, 마지막으로, 가가 나오게 됩니다. 스택을 통해서 출력이 가능한 연산이죠. 하지만 가 라 나 다의 경우에는 불가능해요.

2:05:44
가가 맨 처음에 나오려면은 다른 모든 것들이 들어간 후에 가를 넣어야 하는데 그러면은 가는 어쨌든 맨 마지막에 나올 수밖에 없는 거예요. 그렇기 때문에 이 출력 결과는 불가능한 결과입니다. 이번에는 데크와 큐에 대해서 알아보겠습니다. 큐는 우리가 일상에서 자주 경험하는 대기열과 비슷해요. 먼저 온 사람이 먼저 서비스를 받는 것처럼 큐는 퍼스트 인 퍼스트 아웃 선입선출의 방식으로 동작하게 됩니다. 이런 큐에 데이터를 넘는 거를 삽입 또는 nq 빼는 거를 삭제 또는 dq 작업이라고 해요. 이런 큐는 프린터의 인쇄 대기열이나 컴퓨터의 작업 스케줄링 너비 우선 탐색처럼 순차적으로 이루어져야 하는 작업 상황에서 유용하게 사용이 되는 방식입니다.

2:06:43
데크는 더블 앤디드 큐의 줄임말인데 이름처럼 양쪽 끝 양방향에서 모두 입출력이 가능한 자료 구조입니다. 두 개의 포인터를 이용해서 데크의 양쪽 끝 모두에서 삽입과 삭제가 가능한 자료 구조입니다. 이제 그래프에 대해 알아보겠습니다. 그래프는 지하철 노선도처럼 우리 주변에서 가장 많이 볼 수 있는 자료 구조 중 하나인데요. 그래프는 정점과 간선으로 구성된 자료 구조입니다. 정점은 노선도에서 각 역이라고 생각을 하시면 되고 간선은 역 사이를 연결하는 선이라고 생각하시면 됩니다. 즉 정점은 개체나 데이터를 나타내고 간선은 정점을 연결하는 관계가 되는 거죠. 그래프는 이런 간선에 방향이 있느냐 없느냐에 따라 방향 그래프와 무방향 그래프로 나뉘어요.

2:07:40
이런 그래프의 최대 간선수를 계산할 수도 있습니다. 시험에 자주 나오는 유형인데요. 정점이 n개인 방향 그래프가 가질 수 있는 최대 간선수는 n 곱하기 n 마이너스 1이고 무방향 그래프의 최대 간선수는 이거를 2로 나눈 거예요. 왜 이렇게 되는지 한번 생각을 해보면요 방향 그래프는 모든 정점에서 자기 자신을 제외한 모든 정점으로 화살표를 그릴 수 있고 또 이게 일로 가는 방향이랑 반대로 가는 방향 이렇게 해서 두 가지 경우의 수를 만들 수 있어요. 반면에 무방향 그래프 같은 경우에는 이거를 퉁쳐가지고 하나의 간선으로 보니까 2를 나눈 결과값이 되는 거죠. 이런 계산과 그래프 자체는 네트워크 설계나 알고리즘 분석에서 유용하게 쓰입니다.

2:08:40
이제 트리에 대해 알아보겠습니다. 트리는 그래프의 특수한 형태로 노드와 가지라고도 부르는 선분으로 구성이 되어 있습니다. 가계도나 회사의 조직도를 생각해 보시면은 위에서 아래로 가지가 뻗어나가는 모양이죠. 이게 바로 트리 구조예요. 트리는 그래프의 특수한 형태로 정점 간에 순환하는 사이클이 없고 계층 구조를 나타낼 때 가장 유용한 비선형 구조입니다. 트리와 관련해서 시험에 자주 나오는 개념 중의 하나가 바로 차수 계산인데 차수라는 거는 특정 노드에 연결된 자식 노드 중에 가장 큰 값을 말해요. 여기서는 특정 노드에 연결된 자식 노드의 수 중에 가장 큰 값이 여기 b에 연결된 자식 노드들이에요. b에서는 자식 노드를 3개 가지고 있기 때문에 이 트리 전체의 차수를 3이라고도 할 수 있어요.

2:09:40
이런 트리 구조는 컴퓨터 과학에서 정말 많이 쓰입니다. 파일 시스템이나 데이터베이스 인덱싱 뭐 의사결정 트리 같이 다양한 곳에서 사용이 되다 보니까 트리를 잘 이해하면은 복잡한 데이터를 효율적으로 관리하고 검색하시는데 도움이 되실 겁니다. 트리를 탐색하는 방법에 여러 가지 방법이 있습니다. 전위순회 중위순회 후위순회 세 가지로 나뉘어지는데요. 각 트리의 어떤 부분을 먼저 탐색하느냐에 따라서 순회의 방식이 달라지게 되는 것입니다. 전이순회부터 살펴보면은 이렇게 두 개의 노드가 연결된 트리가 있을 때 먼저 루트 노드를 탐색하고 그다음에 좌측 노드 마지막으로, 오른쪽의 노드를 방문하게 되는 순서가 전위 순회 방식입니다.

2:10:30
왼쪽에 좀 더 큰 트리를 가지고 예시를 한번 살펴보면요 가장 먼저 당연히 탑에 있는 a를 가게 될 거고, a의 관점에서 왼쪽을 다시 가게 됩니다. 그렇기 때문에 b로 이동을 하게 돼요. b로 이동을 하게 되면은 b에서 끝이 나는 게 아니라 b 입장에서도 트리가 하나 더 있죠. 그렇기 때문에 트리가 더 이상 나오지 않을 때까지 파고들게 돼요. b를 기준으로 b라는 루트를 방문했으니까 왼쪽 노드인 d를 방문하게 되고 d 입장에서는 추가적인 트리가 더 없죠 그렇기 때문에 여기서는 이 트리가 마지막이라는 걸 알고 다시 위로 올라갔다가 2를 방문하게 됩니다. 그러면 여기 좌측은 탐색을 다 한 게 되기 때문에 루트와 왼쪽 노드는 탐색을 다 한 거예요.

2:11:30
이제 오른쪽 노드를 방문해야죠 처음에 c를 가게 됩니다. c를 가게 되면 c에서 끝이 나는 게 아니라 또 c가 루트 노드가 되는 또 하나의 트리가 있죠. 그렇기 때문에 c를 기준으로 좌측 노드인 f를 다시 가게 되고 f 기준으로는 끝이 났기 때문에 오른쪽 노드인 g를 다시 보게 됩니다. 이런 식으로 전체의 트리를 순환하게 됩니다. 그러면 중위순회를 한번 살펴보겠습니다. 중위 수뇌 같은 경우에는 이번에는 루트를 가장 먼저 가는 게 아니라 두 번째로, 방문하게 됩니다. 왼쪽을 가장 먼저 방문하고 그 다음 루트 그 다음 오른쪽을 방문하는 경우입니다.

2:12:25
다시 왼쪽 예시를 한번 보면 a를 기준으로 이렇게 트리가 있지만 a를 먼저 방문하지 않습니다. 가장 먼저 이 왼쪽 노드를 살펴보게 되는데 왼쪽 노드를 기준으로는 b가 또 루트 노드이기 때문에 다시 왼쪽 노드인 d를 먼저 가게 됩니다. d를 기준으로는 더 아래에 추가적인 트리 구조가 없기 때문에 d가 진짜 왼쪽 노드가 맞죠. 그렇기 때문에 d를 가장 먼저 보게 되고 왼쪽을 먼저 봤으니까 이제 이 트리를 기준으로 b가 루트가 되죠. 그렇기 때문에 b를 다시 보게 됩니다. 그다음에 오른쪽 노드인 2를 보게 되고요. 왼쪽 노드를 다 봤습니다.

2:13:13
그러면 다시 루트 a를 기준으로는 a가 루트니까 a를 보게 되고 이제 오른쪽을 방문할 차례죠 a를 기준으로 이트리를 보게 되면 되는데 cfg 이트리 구조 중에서 f가 또 왼쪽에 있으니까 f를 방문하게 되고 또 루트인 c를 방문하고 마지막으로, 지를 방문하게 되는 이 순서가 되게 됩니다. 후이순의 방식은 이제는 왼쪽 오른쪽을 먼저 갔다가 루트를 방문하는 거예요.

2:14:02
다시 예시를 가지고 설명을 해드리면은 왼쪽을 먼저 방문하기 때문에 a를 봤는데 a를 기준으로 왼쪽 b 쪽으로 가게 되고 b가 끝이 아니고 b를 기준으로 했을 때 또 왼쪽이 d다 보니까 d를 먼저 보게 돼요. 그다음에 오른쪽인 e를 보고 마지막인 b를 방문하게 됩니다. 그럼 또 왼쪽은 다 봤고 a를 기준으로 이를 기준으로 왼쪽은 다 봤으니까 이제 오른쪽을 볼 차례죠 오른쪽을 보게 되면 또 하나 트리가 있어요. 이 트리를 기준으로 왼쪽인 에프를 또 보고 g를 보고 루트인 c를 보게 되고 최종적으로 a를 보게 되는 겁니다.

2:14:44
이런 식으로 방문의 방식에 따라서 어떤 종류의 순회인지 결정이 되는데 자세히 보시면은 루트를 먼저 방문하면은 전위순회 루트를 중간에 방문하면은 중위순회 루트를 마지막으로, 방문하면 후위순회라는 사실을 알 수 있어요. 이 사실을 참고하셔서 나중에 순회를 할 때 운행 결과를 묻는 문제를 잘 풀어나가시면 되겠습니다. 이번에는 수식을 트리 구조로 표현하고 이를 다양한 방식으로 읽는 법에 대해 알아보겠습니다. 표현 방식은 전위식과 중의식 후의식의 세 가지로 나뉘어지는데요. 아까 순회 방식과 마찬가지로 연산자의 위치에 따라서 순회 방식이 결정되는 구조입니다.

2:15:37
즉 루트 또는 연산자의 위치에 따라서 순회 방식이 결정된다고 생각을 하시면 될 것 같아요. 저희가 일반적으로 보아왔던 연산의 표현은 사실 모두 중위식입니다. 왼쪽에 피연산자 하나 오른쪽에 피연산자 둘 그리고 중간에 루트가 오는 경우였죠 전이식은 이거랑 다르게 루트 연산자가 루트 또는 연산자가 앞에 오고 그다음에 피연산자 2개가 오는 경우입니다. 그렇기 때문에 이렇게 연산자가 앞에 오게 되는데 제가 전이식을 중위식으로 바꾸고 중이식을 전이식으로 바꾸는 방식이 어떻게 진행되는지 한번 보여드리겠습니다. 먼저 중이식을 전이식으로 바꿔볼게요 이런 문제들이 되게 자주 나오는데 먼저 중위식을 전위식으로 바꾸기 위해 가장 먼저 해야 될 거는 연산의 우선순위에 따라서 괄호를 치는 방식이에요.

2:16:32
가장 먼저 여기 괄호가 이미 쳐져 있는데, 이 괄호 연산이 먼저죠 그렇기 때문에 이 연산은 그대로 두고 그 다음에 우선으로 해야 될 거는 여기 a를 곱해주거나 d를 나누어 준 연산이에요. 저는 a를 먼저 해주고 이 연산에다가 다시 괄호를 쳐줄게요 그리고 다음으로, 해야 될 게 d를 나누는 연산이니까. 또 d를 나누는 연산 자체에다가 괄호를 쳐주겠습니다. 그리고 e랑 f의 연산도 해야 되는데 여기에도 괄호를 쳐주고 최종적으로 저희 빼기 연산을 해야 되니까. 그거에 대해서도 괄호를 쳐줍니다. 그리고 이 괄호들을 하나씩 풀어나가면서 순서를 바꾸는 거예요.

2:17:28
여기 b랑 c가 있는데, 이게 가장 먼저 풀어나가야 될 연산이니까. b랑 c의 순서를 뒤로 빼고 연산자인 플러스를 앞으로 가져옵니다. 이 괄호상으로 봤을 때 두 번째로, 해야 될 거는 이 곱하기 연산이죠. 곱하기연산도 마찬가지로 곱하기를 앞으로 보내고 연산자 두 개를 뒤로 뺀다 그럼 그 다음으로, 해야 될 거는 이거랑 이거를 뒤로 나누는 연산이죠. 마찬가지로 이 앞으로 빼고 나머지 연산자 두 개는 뒤로 가져갑니다. 여기는 일단 두고 다시 뒤로 가서 e랑 f의 연산도 순서를 바꿔줘야 되겠죠.

2:18:25
이렇게 곱하기를 앞으로 뺀다 그럼 이제 마지막 하나가 남았는데 여기 마이너스 연산을 앞으로 빼게 되면 최종적으로 연산이 완료됩니다. 이 상태로 가져갈 수는 없으니까 괄호를 이제 다 없애줘요 이렇게 가져가면 조금 생소하지만 이게 전이식 연산이 되는 겁니다. 그러면 이번에는 이렇게 만든 전이식을 다시 중위식으로 바꾸어 보는 연산을 해보겠습니다. 전이식의 경우에 연산자가 앞에 있고 앞쪽에 있을수록 더 나중에 해야 될 연산이기 때문에 가장 뒤에서부터 괄호를 쳐 나가는 거예요. 뒤에 있을 별 연산자가 가장 처음으로 연산돼야 될 연산자라고 생각을 하시고 다시 2개의 피연산자들을 묶어주게 됩니다.

2:19:26
그리고 또 다시 왼쪽으로 가보면은 b랑 c가 있는데, 그 앞에 플러스가 있죠. 그러면 또 이 b랑 c를 괄호로써 플러스랑 같이 묶어주게 되는 겁니다. 그 다음에 또 왼쪽으로 가다 보면은 별이 나오는데 별을 뒤를 한번 보면 별의 뒤를 한번 보면은 a가 있고 괄호로 묶여진 플러스 bc가 있죠. 그러면은 별의 연산자는 a랑 이 괄호로 묶여진 플러스 bc인 거죠. 그렇기 때문에 다시 이렇게 묶어줍니다. 그리고 또 하나 나누기가 나오는데 나누기의 피연산자는 괄호로 묶여진 얘랑 d겠죠. 그렇기 때문에 이렇게 다시 묶어주고 마지막으로, 이 대괄호 두 개를 다시 마이너스로 묶어주는 겁니다.

2:20:21
이렇게 괄호를 치는 게 시작이에요. 괄호를 치고 다시 이 순서를 바꿔줄 거예요. 먼저 이 괄호를 풀 건데 중식으로 바꾸려면 플러스를 중앙에 넣어줘야겠죠. 그러면 이제 다음으로, 풀 거는 얘인데 여기 별을 이렇게 다시 중간에 넣어줘요 이제 풀 거는 얘인데 여기 나누기 2를 또 여기 중간에 넣어주는 거죠. 그다음에 여기 2f 중에 별을 또 중간에 넣어줘요 그러면 괄호를 다시 자세히 보시면 결국에 얘랑 얘 연산이에요.

2:21:16
그렇기 때문에 여기 마이너스를 빼고 여기 넣어줘요 이제 덮을 게 없죠 그러면은 다시 괄호를 다 없애줘요 얘는 그대로 두고 이런 식으로 다시 중위식으로 변환을 할 수 있는 겁니다. 이렇게 다양한 방식을 통해서 전이식과 중이식 후이식으로 자유롭게 변환을 할 수 있고 특히 후이식 같은 경우에는 스택을 이용해서 쉽게 계산할 수 있는 방식이라 프로그래밍에서 자주 활용되는 방식입니다. 제가 방금 보여드린 것처럼 전이식 중이식 후이식을 서로 바꾸어 표현할 때는 결국에 이렇게 네 가지 단계를 따라가게 됩니다. 먼저 표현방식에 맞는 형태를 찾아서 묶습니다.

2:22:14
그다음에 연산자 우선순위에 따라서 순서대로 괄호를 씌웁니다. 그리고 방식에 맞게 연산자 또는 루트의 위치를 변환합니다. 마지막으로, 괄호를 제거합니다. 이렇게 변환 능력은 프로그래밍에서 매우 유용하고 컴파일러나 인터프릭터를 만들 때 이런 기술들이 쓰인다는 점을 참고하시면 좋을 것 같습니다. 마지막으로, 트리의 여러 종류에 대해서 알아보겠습니다. 먼저 이진 탐색트리입니다. 이 트리는 왼쪽 자식 노드의 값이 항상 부모보다 작고 오른쪽 자식 노드의 값이 항상 부모 노드값보다 큰 트리입니다. 이 특성 덕분에 데이터 검색이 매우 빠르지만 최악의 경우에는 검색 효율이 가장 나쁜 틀이기도 합니다. 다음으로, abr트리입니다.

2:23:07
이 트리는 각 노드에서 왼쪽 서브트리와 오른쪽 서브트리의 높이 차이가 1 이하로 유지되는 균형 잡힌 트리입니다. 이를 통해서 향상 효율적인 검색을 보장합니다. 마지막으로, 레드블랙트리입니다. 이 트리는 각 노드가 빨간색 또는 검정색을 가지며 특정 규칙에 따라서 트리의 균형을 유지하게 됩니다. 이 구조 역시 효율적인 검색을 가능하게 합니다. 이런 다양한 트리 구조들은 각각의 장단점이 있어서 상황에 따라서 적절한 구조를 선택하면서 사용하는 것이 되게 중요합니다. 마지막으로, 트리나 그래프를 탐색하는 두 가지 주요 방법에 대해 알아보겠습니다. 첫 번째는 깊이 우선 탐색입니다. 이 방법은 최대한 깊이 내려간 뒤에 옆으로 이동해서 다른 경로를 탐색하는 방법입니다.

2:24:01
미로에서 한 길을 끝까지 가보고 막히면 되돌아와서 다른 길을 탐색하는 것과 비슷합니다. 예시 그림을 한번 볼까요? 가장 깊이 내려가고 옆으로 이동해서 다른 경로를 탐색한다고 했으니 가장 먼저 a를 갑니다. a 아래에는 b랑 c가 있는데, b가 알파벳 순서가 더 빠르니까 b를 먼저 탐색합니다. b 아래에도 d랑 e가 있으니까 이 중에서 d를 먼저 가게 됩니다. d를 가게 되면은 d 아래에는 아무것도 없으니까 이제는 옆으로 이동합니다. 이를 가게 되고요. 이 아래에는 또 지가 있죠. 지를 갔다가 지 아래에는 또 뭐가 없으니까 다시 e로 돌아온 다음에 에프로 이동하게 됩니다. 에프로 이동하고 아래에 또 뭐가 없으니까 마지막으로, 씨를 가게 되면서 탐색이 종료되는 거죠. 두 번째는 너비우선 탐색입니다.

2:25:01
이 방식은 현재 위치에서 갈 수 있는 모든 곳을 먼저 탐색한 후에 다음 단계로 넘어가는 방식입니다. 예를 들어서 가장 먼저 a를 탐색한 다음에 a와 인접한 노드는 b랑 c가 있는데, 가장 먼저 알파벳 순서가 빠른 그리고 c를 방문하게 됩니다. a에서는 더 갈 곳이 없기 때문에 제가 a 다음으로, 봤던 b 노드를 다시 살펴봅니다. b 노드에서는 c d e가 연결되어 있는데, c를 아까 갔었고 b를 기준으로 했을 때 그다음 노드인 d랑 e를 가게 됩니다. 그다음에 e까지 갔고 세 번째로, 본 노드가 b 다음에 c였죠 c에서 다시 어디로 갈 수 있는지 살펴보니까 b e f가 있는데, b e는 갔었고 그다음에 f를 가게 되는 겁니다.

2:25:55
다시 살펴보면은 d에서는 갈 곳이 e인데 e는 갔었고 e에서 다시 살펴보면은 f는 갔었고 g가 남아있죠. 때문에 g를 마지막으로, 탐색한 후에 끝이 나는 겁니다. 이 두 가지 탐색 방법은 각각 장단점이 있어서 문제의 특성에 따라 적절한 방법을 선택해서 사용해야 됩니다. 이로써 데이터 구조와 탐색 방법에 대한 기본적인 내용들을 모두 다루었습니다. 이러한 개념들은 효율적인 프로그램을 작성하는데 매우 중요하기 때문에 잘 이해하고 적용할 수 있도록 연습해 주시기 바랍니다. 감사합니다. 안녕하세요. 여러분 오늘은 소프트웨어 개발단원의 두 번째 강의로 통합구현에 대해 알아보겠습니다. 통합구현은 개별적으로 만들어진 소프트웨어들을 하나로 모아 완성된 프로그램을 만드는 과정입니다. 통합구현에 대해 자세하게 알아보겠습니다.

2:26:54
그 전에 먼저 모듈이라는 것에 대해 알아보겠습니다. 모듈이란 무엇일까요? 모듈은 소프트웨어 구조를 이루면서 다른 것들과 구별될 수 있는 독립적인 기능을 가진 단위를 말합니다. 모듈은 제각기 독립적인 기능을 수행하고 있고 특정한 기능을 구현하기 위해 만들어진 명령어들의 집합이기도 합니다. 이런 명령어들과 또는 모듈이 서로 모여서 하나의 완전한 프로그램을 만들어내는 것입니다. 모듈을 구현할 때 작업 절차는 아래와 같습니다. 먼저 코딩 작업 계획을 세우고 실제로 코딩을 하고 컴파일을 거치고 테스트를 진행하는 4가지 단계로 이루어져 있습니다.

2:27:43
여기서 컴파일이라는 말과 테스트라는 말이 조금 의미가 달리 쓰일 수도 있고 생소하실 수도 있는데, 먼저 컴파일에 대해서 간단하게 설명을 드리면은 컴파일은 사용자가 코딩을 할 때 썼던 고수준의 언어를 저수준의 언어 즉 컴퓨터가 이해할 수 있는 0과 1에 가까운 수준의 언어로 변환하는 작업이에요. 그리고 테스트는 오류를 찾는 작업을 말합니다. 오류를 찾는 작업이 아니면 뭐냐 라고 또 궁금해 하실 수도 있는데, 비슷한 단어로 디버그가 있습니다. 테스트랑 디버그라는 단어는 비슷하지만 조금 달라요. 테스트는 제가 말씀드린 것처럼 오류를 찾을 때 하는 작업이고 디버그는 오류를 수정하는 작업입니다. 이 차이가 있다는 점을 기억해두세요.

2:28:41
이번에는 소프트웨어 재사용에 대해 알아보겠습니다. 소프트웨어 재사용이란 이름과 같이 이미 개발된 소프트웨어의 전체 또는 일부분을 재사용하는 기법입니다. 소프트웨어 재사용에는 크게 제공하기랑 재개발이라는 두 가지 방법이 있습니다. 먼저 제공학에 대해 알아볼까요? 재공학은 기존 소프트웨어를 유지하면서 기능을 개선하거나 재활용하는 재사용 기법입니다. 제공학의 주요 활동으로는 분석 재구조 역공학 이식 등이 있습니다. 이 4가지를 간단하게 설명드리면은 먼저 분석은 제공학을 수행하기 위해서 기존의 소프트웨어 설계를 확인해 동작을 이해하는 단계 재구조는 추상적인 수준에서 구조를 다른 형태로 바꾸어 보는 작업을 의미하고요.

2:29:40
역공학은 리버스 엔지니어링이라는 말처럼 기존에 만들어진 소프트웨어를 분석해 그 설계를 알아내는 방법입니다. 우리가 설계를 하고 소프트웨어를 개발하는 것과 반대 방향으로 진행되는 거죠. 마지막으로, 이 식은 영어로 마이그레이션이라고 하는데 기존 소프트웨어를 새로운 하드웨어 또는 소프트웨어 환경에서 사용할 수 있게 변환하는 작업이죠. 제가 생각하기로 자주 겪고 간단한 예시로 저희 한글 문서로 작성된 한글 파일로 작성된 문서를 워드 파일로 마이크로소프트의 워드 파일을 활용해 변환하는 예시가 있겠는데 저희가 한글로 만들어진 파일을 그대로 워드로 변환하게 되면은 프로그램도 깨지고 오류가 나겠죠.

2:30:28
그렇기 때문에 한글로 만든 내용과 형식을 이제 워드가 제공하는 어떤 형식과 기능에 맞추어 변환하는 작업을 마이그레이션의 간단한 예시라고 생각해 보시면 좋을 것 같아요. 반면에 재개발은 기존에 있던 시스템 내용을 참조해서 완전히 새로운 시스템을 개발하는 방법입니다. 기존의 것들을 완전히 허물고 참조만 해서 새로 짓는 것과 비슷하죠. 이런 소프트웨어 제공학이 기존의 소프트웨어 재개발에 비해 갖는 장점이 크게 3가지 정도가 있습니다. 첫 번째로, 위험 부담이 감소합니다. 어쨌든 새로운 시스템을 만드는 게 아니라 기존에 있던 시스템을 기반으로 하기 때문에 위험 부담이 감소하게 됩니다. 두 번째로, 모든 걸 새로 만드는 것보다 기존의 것을 활용하게 되기 때문에 비용도 절감됩니다.

2:31:28
그리고 이미 검증된 기존 시스템을 기반으로 하기 때문에 명세에 기반한 어떤 새로운 오류가 발생할 가능성도 낮아지게 됩니다. 이번에는 통합 구현 관리와 관련된 중요한 도구인 ide 인테그레이티드 디벨롭먼트 인바이런먼트 도구에 대해 알아보겠습니다. ida란 무엇일까요? ida는 코딩 디버그 배포와 같이 프로그램 개발과 관련된 모든 작업들을 한 곳에서 처리할 수 있도록 하는 프로그램입니다. 쉽게 말해서 저희가 코딩을 그냥 컴퓨터의 메모장에다가 해버리면은 그거는 코드를 만들 수도 없고 배포를 할 수도 없는데 어 그런 것들을 실제로 프로그램으로 구현할 수도 있고 배포할 수도 있는 통합된 환경을 제공해주는 프로그램을 의미하는 거예요.

2:32:23
아마 직접 개발을 해보시게 되면은 많은 프로그램들을 접하시겠지만, 이클립스나 비주얼 스튜디오 같은 프로그램들을 되게 많이 사용합니다. 이런 것들은 각각 자바를 지원한다던가 c를 지원한다던가 다양한 프로그래밍 언어를 지원하고 있죠. 이런 아이디의 주요 기능을 살펴보겠습니다. 먼저 코딩입니다. 코딩은 프로그래밍 언어를 가지고 컴퓨터 프로그램을 작성할 수 있는 기본 환경을 제공합니다. 컴파일은 고급 언어의 프로그램을 저급 언어로 컴퓨터가 이해할 수 있는 0과 1에 가까운 수준의 언어 프로그램으로 변환하는 기능을 가지고 있습니다. 디버깅은 프로그램에서 발견되는 버그를 찾아서 수정할 수 있는 기능을 제공합니다.

2:33:16
마지막으로, 디플로이먼트는 배포라는 영어 단어인데 소프트웨어를 완성시키고 나서 최종 사용자들에게 전달하기 위한 기능입니다. 이런 아이디의 사용은 개발 과정을 더 효율적으로 만들어주고 프로그래머가 코드 작성에 더 집중할 수 있게 해주고 이번에는 소프트웨어 형성 관리에 대해 알아보겠습니다. 소프트웨어 형성 관리란 무엇일까요? 소프트웨어 개발에서 일어나는 모든 변경 사항들을 체계적으로 알아내고 관리하는 활동을 의미합니다. 마치 역사가가 시대의 변화를 잘 기록하고 관리해야 후대에 우리가 역사 속에서 어떤 일이 일어났고 그 결과가 어땠는지 알 수 있듯이 소프트웨어 개발자도 소프트웨어에서 일어나는 수정이나 버전 변경을 잘 파악해서 관리할 필요가 있겠습니다.

2:34:09
이런 형상 관리의 주요한 목적은 소프트웨어 개발의 전체적인 비용을 줄이고 개발 과정에 여러 가지 방해 요인들을 최소화하는 것입니다. 이를 통해서 소프트웨어의 품질을 높일 수 있습니다. 형상관리의 대상은 매우 광범위한데 프로젝트 계획 분석서 설계서 프로그램 테스트 케이스 등 개발과 관련된 모든 산출물이 관리 대상이 됩니다. 또 형상관리는 유지보수 단계뿐 아니라 개발단계에서도 자주 사용이 됩니다. 그리고 이런 대표적인 형상 관리를 할 때 쓰는 도구들은 크게 3개 cbs svn git 등등이 있습니다. 옛날에는 cbs나 sbn을 많이 썼는데 요즘은 gitable을 많이 쓰게 되면서 git을 훨씬 많이 쓰는 것 같습니다. 이제 형상관리도구의 주요한 기능에 대해서 알아보겠습니다.

2:35:06
체크인 체크아웃 커밍 세트 세 가지가 있는데, 먼저 체크인입니다. 체크인은 새로운 버전의 파일을 형상을 저장하는 저장소에 올려 갱신하는 것입니다. 두 번째는 체크아웃입니다. 특정 버전의 파일을 저장소 형상 관리 도구가 되겠죠. 저장소에서 작업 공간으로 다시 가져오는 것을 말합니다. 세번째는 커밋입니다. 커밋은 코드의 변경사항을 저장소에 기록하고 버전의 이력을 업데이트하는 것입니다. 이런 형상관리 과정과 도구들은 소프트웨어 개발 과정을 체계적으로 관리할 수 있게 하고 팀원들 간의 협업을 원활하게 만듭니다. 이제 형상 관리의 구체적인 개념과 절차에 대해 알아보겠습니다.

2:35:57
형상 관리라는 것이 개발 과정의 변경 사항을 관리하는 것이라고 하였는데 변경이 필요할 때마다 변경 요구에 따라서 곧바로 소프트웨어가 변경돼야 될까요? 그렇지 않습니다. 소프트웨어의 변경이 오류를 낳을 수도 있고 이력 관리를 통해서 안정적인 소프트웨어를 유지를 하는 거를 보장해야 되기 때문에 여러 가지 절차들을 거쳐서 형성 관리를 진행하게 됩니다. 형상 관리는 크게 4가지 단계로 이루어집니다. 형상 식별 형상 통제 형상 감사 형상 기록 이렇게 4가지이고요. 먼저 형상 식별입니다. 형상 식별은 형상 관리 계획을 바탕으로 형상 관리의 대상이 무엇일지 식별을 하는 단계입니다. 그다음은 형상통제입니다. 2단계에서는 ccb라고 불리우는 형상통제위원회가 주요한 역할을 하게 됩니다.

2:36:50
ccb는 변경사항의 승인을 결정하고 승인된 변경들이 제대로 실행될 수 있게끔 관리하는 활동을 진행하게 됩니다. 이렇게 형상 항목이 변경됨을 승인하게 되면은 변경을 진행하게 되는데요. 이 변경을 진행하는 단계에서도 형상감사라는 단계를 통해서 형상관리가 계획적으로 형상관리와 변경이 잘 진행되고 있는지 살펴보는 단계가 또 진행됩니다. 형상감사입니다. 마지막으로, 형상기록입니다. 여태까지 진행해온 모든 형상관리 활동의 결과를 문서화하는 단계입니다. 이것으로 오늘의 강의를 마치겠습니다. 소프트웨어 개발에서 통합구현과 형상관리가 얼마나 중요한지 이해하셨기를 바라겠습니다. 감사합니다. 안녕하세요.

2:37:44
여러분 오늘은 소프트웨어 개발 과정 중 하나인 제품 소프트웨어 패키징에 대해 알아보겠습니다. 이 단원 소프트웨어 개발 단원의 경우에 암기할 내용은 되게 많지만 암기한 만큼 고득점을 그대로 가져갈 수 있기 때문에 잘 공부하셔서 꼭 이 단원은 고득점을 가져가도록 합시다. 우리가 다룰 내용은 크게 세 가지입니다. 첫 번째 소프트웨어 패키징 자체에 대해 알아볼 거고, 소프트웨어 매뉴얼 작성 방법을 배우며 마지막으로, 이런 제품 소프트웨어의 버전 관리를 하는 방법에 대해 알아보겠습니다. 본격적으로 제품 소프트웨어 패키징에 대해 알아보겠습니다. 소프트웨어 패키징이란 무엇일까요? 간단히 말해서 개발이 완료된 소프트웨어를 사용자가 쉽게 설치하고 실행할 수 있도록 배포 가능한 단위로 묶는 과정입니다.

2:38:40
이 과정에서 가장 중요한 점은 패키징은 사용자 중심으로 진행되어야 된다는 점입니다. 아무리 뛰어난 기능을 가진 소프트웨어라 하더라도 사용자가 설치하고 사용하기 어렵다면 가치가 떨어지겠죠. 패키징 과정에서는 이렇게 새로 개발된 소스나 변경된 소스를 식별하고 이를 모듈화해서 상용 제품으로 만들게 됩니다. 그리고 사용자 고객의 편의성을 위해서 매뉴얼을 제공하고 지속적인 버전 관리를 업데이트를 통해 수행하게 됩니다. 주의할 점은 패키징된 소프트웨어가 다양한 환경에서 사용이 가능하도록 일반적인 배포 형태로 만들어져야 한다는 것입니다. 예를 들어서 윈도우용으로만 개발된 프로그램을 맥이나 리눅스 os의 사용자도 쉽게 설치할 수 있도록 해야 하는 것이죠. 패키징 도구를 사용할 때는 몇 가지 고려사항이 있습니다. 첫 번째 보안을 최우선으로 생각해야 됩니다.

2:39:38
두 번째로, 사용자 편의성을 위해 복잡성을 줄이고 효율성을 높여야 합니다. 셋째, 제품의 특성에 맞는 암호화 알고리즘을 적용해야 합니다. 마지막으로, 다양한 기기와의 이기종 연동을 고려해야 합니다. 아까 범용 환경에서 사용이 가능해야 한다는 말과 동일한 의미입니다. 이런 과정을 거쳐서 만들어진 패키지는 대부분의 사용자 환경에서 문제없이 작동할 수 있게 됩니다. 이번에는 trm 디지털 라이트 매니지먼트에 대해 알아보겠습니다. trm은 디지털 콘텐츠의 불법 복제와 무단 사용을 방지해주는 기술입니다.

2:40:26
예를 들어서 여러분들께서 음원 스트리밍이나 넷플릭스 같은 플랫폼을 이용할 때 콘텐츠들이 이제 로컬에 자기 pc나 핸드폰에 다운받는 건 가능하지만 그거를 친구한테는 자유롭게 공유하기가 어렵죠 이런 콘텐츠들이 무단으로 복제되거나 공유되지 않도록 하는 기술이 바로 drm입니다. drm은 단순히 복제를 막는 것뿐만 아니라 디지털 미디어의 전체 생명주기 동안 발생하는 사용 권한을 관리하고 또 과금 유통 단계까지 제어하고 관리해 주는 기술입니다. 이걸 위해 다양한 기술요소들이 사용되는데 방지 정책 관리 암호화 키 관리 식별 기술 저작권 표현 암호화 파일 생성 인증 등의 다양한 기술 요소가 사용됩니다. trm에서 어떤 기술 요소가 있는지 물어보는 문제는 거의 매번 시험문제에 나왔습니다.

2:41:22
뭐 예를 들어서 여기에 한 3개 정도를 골라놓고 거기에 뭐 방화벽 기술 같이 drm 기술 요소가 아닌 걸 끼워놓고 이 중에 drm 기술 요소가 아닌 것은 이런 식으로 묻게 되는데요. 때문에 이런 기술 요소가 뭐가 있는지 정도는 암기를 하셔도 좋을 것 같습니다. drm 시스템은 여러 구성 요소로 이루어져 있습니다. 먼저 콘텐츠 제공자가 있는데, 저작권을 가진 사람이나 기관을 의미합니다. 그리고 콘텐츠를 실제로 사용하는 사용하는 최종 사용자인 콘텐츠 소비자가 있습니다. 중간에서 콘텐츠를 유통하는 역할을 하는 콘텐츠 분배자도 있습니다. 음원 스트리밍 서비스 같은 것들이죠. 클리어링 하우스는 키 관리와 라이센스 발급을 담당합니다.

2:42:15
drm 콘텐츠는 drm 기술로 보호된 디지털 콘텐츠를 의미하고 패키전은 이 콘텐츠를 메타 데이터 즉 콘텐츠가 어떤 콘텐츠인지 설명하기 위한 데이터와 함께 배포 가능한 단위를 묶는 도구입니다. drm 컨트롤러는 배포된 콘텐츠의 이용 권한을 통제하고 보안 컨테이너는 콘텐츠를 암호화해서 무단 접근을 방지하게 됩니다. 이렇게 복잡한 시스템을 통해서 디지털 콘텐츠의 저작권이 보호되고 적절한 유통과 사용이 이루어지는 것입니다. 이제 제품 소프트웨어의 매뉴얼 작성에 대해 알아보겠습니다. 소프트웨어 매뉴얼은 사용자가 소프트웨어를 설치하고 사용하는 데 필요한 모든 정보를 제공하는 문서입니다. 설치 매뉴얼이나 사용자 매뉴얼 같은 것들이 예시가 될 수 있겠죠.

2:43:13
매뉴얼 작성 시에 가장 중요한 점은 개발자가 아니라 사용자 관점에서 작성되어야 된다는 것입니다. 아무리 잘 만들어진 소프트웨어라 하더라도 사용자가 사용 방법을 이해하기가 어려우면 그 가치가 떨어지겠죠. 이런 소프트웨어의 사용자 매뉴얼을 작성하는 절차는 아래와 같습니다. 먼저 컴포넌트 명세서를 확인합니다. 이 명세서는 소프트웨어의 각 구성 요소에 대한 상세한 정보를 담고 있지만 개발자 관점에서 작성된 내용일 수가 있습니다. 때문에 어떻게 사용자들한테 보여야 될지 작성 지침들을 정의합니다. 사용할 문서나 문서의 형식이나 스타일 용어들이 포함되겠죠. 그다음으로, 사용 설명서의 구성 요소를 정의합니다.

2:44:01
일반적으로는 프로그램의 개요 설치 관련 파일에 대한 설명 어떤 파일들이 깔리는지 삭제를 어떻게 하는지 그 방법 고객 지원 방법 같은 섹션들이 포함이 되게 됩니다. 그렇지만 개발 프로젝트가 얼마나 걸렸는지 개발 기관과 같은 사용자 입장에서 굳이 아예 필요 없는 정보들은 들어가지 않아도 되겠죠. 이후에는 각 구성 요소별로 내용을 작성합니다. 이렇게 내용 작성이 완료되면은 마지막으로, 작성된 사용 설명서를 검토합니다. 이 과정에서 오류나 불명확한 부분을 수정하고 실제 사용자의 피드백을 반영할 수 있습니다. 잘 작성된 매뉴얼은 사용자의 만족도를 높이고 소프트웨어의 효율적인 사용을 돕습니다. 따라서 매뉴얼 작성에 충분한 시간과 노력을 투자하는 것이 중요합니다.

2:44:58
소프트웨어 품질은 매우 중요한 요소이기 때문에 이거를 평가하기 위해서 국제적으로 여러 표준이 지정되어 있습니다. 대표적인 것들이 여기 isoic926을 포함한 몇 가지들이 있습니다. 이런 국제적인 표준들은 소프트웨어 품질을 평가할 수 있는 국제적인 지표로서 전 세계 기업들이 동일한 품질관리 기준을 적용할 수 있도록 돕기 때문에 소비자 입장에서는 어느 나라에서라도 동일한 수준의 품질을 기대할 수 있다는 장점이 있죠. 먼저 isyc9126에 대해 알아보겠습니다. 소프트웨어 품질을 측정하고 평가하기 위해서 아래와 같은 소프트웨어의 품질 특성들을 정의하였는데요. 하나씩 살펴보겠습니다. 먼저 포터블리티 이식성입니다. 소프트웨어가 다른 환경에서도 쉽게 작동할 수 있는 능력을 말합니다.

2:45:53
윈도우에서 개발된 프로그램이 맥에서도 잘 동작한다면은 이식성이 높다고 할 수 있겠죠. 두 번째는 릴라이어빌리티 신뢰성입니다. 소프트웨어가 일정 시간 동안 주어진 조건에서 오류 없이 요구된 기능을 수행할 수 있는 정도를 말합니다. 은행 시스템처럼 중요한 소프트웨어일수록 높은 신뢰성이 요구됩니다. 세 번째는 효율성입니다. 자원의 양에 따라서 요구된 성능을 잘 제공하는 소프트웨어의 능력을 의미합니다. 이런 효율성의 품질 부특성으로 시간 반응성 자원효율성 준수성 등이 있는데, 뭐 부특성으로 이러 이런 걸 가지고 있는 품질 목표는 해서 문제가 나올 수도 있으니까 참고 부탁드립니다. 여기 메인터널시는 유지보수성을 의미하는데요.

2:46:50
소프트웨어가 얼마나 쉽게 수정되고 업데이트 될 수 있는지를 나타냅니다. 잘 구조화된 코드일수록 이런 유지보수성이 높아지겠죠. 다섯번째는 userbility 사용성입니다. 사용자가 소프트웨어를 얼마나 쉽게 배우고 사용할 수 있는지를 나타냅니다. 직관적인 인터페이스를 가진 소프트웨어가 사용성이 훨씬 높겠죠. 마지막으로, functionality는 기능성입니다. 소프트웨어가 요구된 기능들을 얼마나 잘 수행하는지를 나타내는 지표고요. 부특성으로 적합성 정확성 상호 운용성 보안성 준수성 등이 포함됩니다. 이런 품질 특성들을 고려해서 소프트웨어를 개발하고 평가함으로써 더 나은 품질의 소프트웨어를 만들 수 있습니다.

2:47:44
소프트웨어 품질 평가와 관련된 여러 국제 표준들 몇 가지를 더 알아보겠습니다. 먼저 isyc 149598은 소프트웨어 품질을 체계적이고 일관되게 평가할 수 있는 기준을 제공합니다. 이걸 통해서 다양한 소프트웨어를 동일한 기준으로 평가할 수 있게 됩니다. isyc 2만 5천 일명 스퀘어라고 부르는 이것은 소프트웨어의 품질 평가를 위한 통합된 표준을 제공합니다. 이거는 기존의 평가 절차 모델과 품질 평가 모델이었던 iso 9126과 14598을 통합한 모델로서 더욱 포괄적이고 일관된 품질 평가 체계를 제공합니다. isoic 12119는 패키지 소프트웨어의 일반적인 품질 요구사항과 테스트를 위한 국제 표준입니다. 특히 상용소프트웨어 제품의 품질을 평가하는데 중요한 기준이 됩니다.

2:48:43
이런 공식적인 품질 평가 기준 외에도 개발자 관점에서 소프트웨어 품질을 측정할 때 고려해야 할 주요 항목으로는 정확성 무결성 사용성 신뢰성 효율성 유연성 이식성 상호 운용성 등이 있습니다. 이런 요소들을 모두 고려해서 개발을 진행해야 높은 품질의 소프트웨어를 만들 수 있습니다. 필기시험에서는 주로 이런 특징을 가진 표준의 이름은 이런 식으로 나오거나 아니면 iso 2만 5천의 특징이 아닌 것은 이런 식으로 나오니까 학습에 참고하시면 되겠습니다. 이번에는 소프트웨어 공학에 대해 알아보겠습니다. 소프트웨어 공학은 소프트웨어의 개발 운용 유지 보수 및 파기에 이르는 전체 생명 주기에 대한 체계적인 접근 방법을 제공합니다.

2:49:39
소프트웨어 공학의 주요한 목적은 소프트웨어의 품질을 높이고 생산성과 개발자들의 작업 만족도를 올리는 것입니다. 궁극적으로는 더 나은 품질의 소프트웨어를 더 효율적으로 만드는 것이 목표라고 할 수 있겠습니다. 이런 소프트웨어 공학의 기본 원칙에는 세 가지가 있습니다. 첫 번째로, 현대 프로그래밍 기술을 계속적으로 적용해야 합니다. 기술은 빠르게 발전하기 때문에 개발자들은 항상 새로운 기술을 배우고 적용할 준비가 되어 있어야 합니다. 두 번째로, 품질 유지를 위한 지속적인 검증이 필요합니다. 개발 과정 중에 정기적인 테스트와 검증이 필수적입니다. 세 번째 결과에 대해서 명확한 기록을 유지해야 합니다. 나중에 유지 보수나 개선에 큰 도움이 되기 때문이에요.

2:50:33
이런 원칙들을 잘 지키고 공학적으로 잘 만들어진 소프트웨어들은 몇 가지 특징을 가지게 됩니다. 먼저 신뢰성이 높고 유지 보수가 용이해야 합니다. 그리고 사용자의 수준에 맞는 interface를 제공해야 되고 출시 전에 충분한 테스팅을 거쳐야 합니다. 이런 원칙과 특성을 지키면서 소프트웨어를 개발하는 것이 소프트웨어 공학의 핵심입니다. 이걸 통해서 우리는 더 나은 품질의 소프트웨어를 더 효율적으로 만들 수 있습니다. 소프트웨어 공학과 관련된 중요한 법칙들 두 가지에 대해 알아보겠습니다. 먼저 브룩스의 법칙입니다. 이 법칙은 소프트웨어 프로젝트의 일정이 지연된다고 해서 프로젝트 말기에 또 새로운 인원을 추가 투입하게 되면은 오히려 프로젝트는 더욱 지연된다는 것입니다.

2:51:26
되게 중요한 프로젝트 관리 원칙인데 예를 들어서 완성에 6개월이 걸릴 것으로 예상했던 프로젝트가 5개월 차에 아직 절반도 완성되지 않았다고 가정해 봅시다 이때 새로운 개발자를 투입하면 어떻게 될까요? 새로운 개발자는 프로젝트를 이해하는 데도 시간이 필요할 거고, 기존 개발자들은 새 개발자를 교육하는 데 또 시간을 써야 됩니다. 그렇기 때문에 단기적으로는 새 개발자가 투입된다 하더라도 생산성이 더 떨어지게 되는 것입니다. 다음은 파레토의 법칙입니다. 이 법칙은 소프트웨어에 한정해서 쓰는 말은 아니고 소득의 분배를 비롯한 여러 관점에서 두루두루 쓰이는 말인데 이것이 소프트웨어 테스트에 적용돼서 오류의 80%는 전체 모듈의 20%에서 발견된다 라고 말합니다.

2:52:22
이거는 테스팅 전략을 세울 때 매우 유용한 지침이 되는데 이 법칙을 잘 이해하면은 테스트 시의 모든 모듈에 동일한 노력을 기울이는 것보다 문제가 발생할 가능성이 높은 핵심 모듈에 더 집중할 수 있게 됩니다. 이걸 통해서 더 효율적인 테스팅을 할 수 있겠죠. 이런 법칙들은 소프트웨어 개발 프로젝트를 관리하고 효율적으로 진행하는 데 큰 도움이 됩니다. 실제 개발 현장에서도 이런 원칙들을 적용하면 프로젝트의 성공 가능성을 더 높일 수 있습니다. 이제 소프트웨어 버전 관리에 대해 알아보겠습니다. 소프트웨어 버전 관리는 개발 과정에서 코드의 변경 사항을 추적하고 관리하는 중요한 작업입니다. 그리고 소프트웨어 버전 관리 도구는 이런 작업들을 효과적으로 수행할 수 있게 해줍니다. 그리고 이 도구들은 형상 관리라는 중요한 역할도 수행하게 됩니다.

2:53:22
형상 관리란 앞선 단원에서도 말씀드렸던 소프트웨어의 변경 사항을 체계적으로 추적하고 통제하는 활동을 의미합니다. 오른쪽 아래 그림처럼 각 개발자들이 본인의 pc에서 소프트웨어를 수정하고 각각의 버전을 소프트웨어 버전 관리 도구의 서버에 업로드하면 버전 관리 도구는 각 버전을 다시 한 버전으로 합치거나 같은 파일을 누가 동시에 작업하지는 않았는지 등을 체크하게 되죠. 이런 버전 관리 도구의 형성 관리 역할에 대한 기능들을 아래와 같이 적어보았습니다. 먼저 형상 관리를 통해서 이전 버전이나 리비전에 대한 정보에 쉽게 접근할 수 있게 해줍니다. 이거는 문제가 발생했을 때 빠르게 이전 버전으로 돌아갈 수 있게 유용하게 관리를 할 수 있도록 도와줍니다. 두 번째로, 불필요한 소스 수정을 제안합니다. 권한이 있는 개발자만 코드를 수정할 수 있도록 제어합니다.

2:54:19
세 번째로, 여러 개발자가 동시에 같은 프로젝트를 개발할 수 있게 해줍니다. 대규모 프로젝트에서 여러 명의 개발자가 붙어 작업해야 되는 경우에 특히 중요합니다. 네 번째로, 오류가 발생했을 때 빠르게 복구할 수 있도록 해줍니다. 기능들 덕분에 개발팀은 더 효율적으로 협업할 수 있고 소프트웨어의 품질을 높일 수 있습니다. 때문에 실제 개발 현장에서는 이런 버전 관리 도구의 사용이 사실 필수적입니다. 소프트웨어 버전 관리 도구는 크게 세 가지 유형으로 나눌 수 있습니다. 각각의 특징을 살펴보겠습니다. 첫번째는 클라이언트 서버 방식입니다. 이 방식에서는 중앙 서버의 모든 파일과 변경 이력을 저장하고 개발자들은 이 서버에서 필요한 파일을 가져와 작업합니다.

2:55:17
대표적인 예로 cbs와 svn이 있습니다. 이 방식의 장점은 중앙 집중식 관리가 가능하다는 것이지만 이 서버에 문제가 생기게 되면 작업이 어려워질 수 있다는 장점이 있습니다. 두번째는 공유 폴더 방식입니다. 이거는 네트워크 공유 폴더를 통해서 파일을 저장하고 버전을 관리하는 방식입니다. rcs나 드랍박스 같은 방식이 이거에 해당합니다. 사용이 간단하다는 장점이 있지만 동시에 작업하기가 어렵고 때문에 충돌 관리도 쉽지 않다는 단점이 있습니다. 마지막으로, 분산 저장소 방식이 있습니다. 이 방식에서는 각 개발자가 전체 저장소의 복사본을 가지고 독립적으로 작업을 하게 되고 필요할 때만 서로의 변경 사항을 동기화하게 됩니다. 기시대표적인 예입니다.

2:56:12
이 방식은 오프라인 작업이 가능하고 브랜치 관리가 용이하다는 장점이 있지만 위 방법들보다는 조금 배우는 데 더 시간이 걸린다는 단점이 있습니다. 각 방식은 장단점이 있기 때문에 프로젝트의 특성과 팀의 상황에 잘 맞는 도구를 선택하는 것이 중요합니다. 마지막으로, 빌드 자동화 도구에 대해 알아보겠습니다. 빌드 자동화 도구는 소스 코드를 컴파일하고 테스트하고 패키징하는 일련의 과정을 자동화해주는 소프트웨어입니다. 이런 도구들은 특히 지속적으로 통합이 일어나는 환경에서 매우 유용합니다. 지속적인 통합이란 컨티뉴어스 인테그레이션이라고도 하는데 개발자들이 변경 사항을 중앙 저장소에 하루에도 여러 번씩 자주 통합하는 소프트웨어 개발 방식을 의미합니다.

2:57:07
대표적인 빌드 자동화 도구로는 엔트 젠킨스 그래들 등이 있습니다. 엔트는 자바 기반의 빌드 자동화 도구로 xml로 작성된 스크립트를 활용해 빌드 작업을 자동화합니다. 그래들은 그루비 등을 사용해서 빌드 스크립트를 작성하고 실행할 처리 명령들을 모아서 태스크 단위로 실행합니다. 복잡한 빌드 프로세스를 효과적으로 관리할 수 있게 해줍니다. 젠킨스는 자바 기반의 오픈 소스 빌드 자동화 도구로 다양한 버전 관리 도구를 지원합니다. 젠킨스는 플러그인 시스템을 통해서 확장성이 뛰어나고 또 거의 모든 언어와 소스 코드 저장소에 대한 통합이 가능합니다. 이런 빌드 자동화 도구를 사용하게 되면 개발 프로세스를 크게 개선할 수 있습니다.

2:57:59
반복적인 작업을 자동화함으로써 개발자들의 생산성과 만족도를 높이고 더 빠른 피드백 루프를 만들 수 있습니다. 결과적으로 더 높은 품질의 소프트웨어를 더 빨리 개발할 수 있게 되는 것입니다. 이것으로 오늘 강의를 마치겠습니다. 감사합니다.