정보처리기사 실기 4장. 서버 프로그램 구현_1
4-1. 개발 환경 구축
• 개발 환경 구축
개발 프로젝트를 이해하고 소프트웨어 및 하드웨어 장비를 구축하는 것
‣ 응용 소프트웨어가 운영될 환경과 유사한 구조로 구축
‣ 분석 단계의 산출물을 바탕으로 개발에 필요한 하드웨어와 소프트웨어를 선정
• 하드웨어 환경
1. 클라이언트 (Client) : 사용자와의 인터페이스 역할
‣ 클라이언트의 종류 : 개인용 컴퓨터 (PC), 스마트폰 등
2. 서버 (Server) : 클라이언트와 통신하여 서비스를 제공
| 웹 서버 (Web Server) |
클라이언트로 직접 요청을 받아 처리함 |
| 저용량의 정적 파일들을 제공함 ‣ 정적 파일 : HTML, CSS, 이미지 파일 |
|
| 웹 애플리케이션 서버 (WAS, Web Application Server) |
웹 서버와 데이터베이스 서버 / 웹 서버와 파일 서버 사이에서 인터페이스 역할을 수행 |
| 동적 서비스를 제공함 ‣ 동적 파일 : 사용자의 입력에 따라 다른 결과를 보여주는 서비스 |
|
| 데이터 베이스 서버 (DB Server) |
데이터베이스와 이를 관리하는 DBMS를 운영함 |
| 파일 서버 (File Server) | 서비스 제공을 목적으로 유지하는 파일들을 저장함 |
| 데이터베이스에 저장하기에는 비효율적인 경우에 사용 |
- 웹 서버(Web Server)의 기능
| HTTP/HTTPS 지원 | 브라우저로부터 요청을 받아 응답할 때 사용되는 프로토콜 |
| 통신 기록 (Communication Log) | 처리한 요청들을 로그 파일로 기록하는 기능 |
| 정적 파일 관리 (Managing Static Files) | HTML, CSS, 이미지 등의 정적 파일들을 저장하고 관리하는 기능 |
| 대역폭 제한 (Bandwidth Throtting) | 네트워크 트래픽의 포화를 방지하기 위해 응답 속도를 제한하는 기능 |
| 가상 호스팅 (Virtual Hosting) | 하나의 서버로 여러 개의 도메인 이름을 연결하는 기능 |
| 인증 (Authentication) | 사용자가 합법적인 사용자인지를 확인하는 기능 |
✓ HTTP/HTTPS (HyperText Transfer Protocol [Secure]) HTTP는 하이퍼텍스트 문서를 전송하기 위해 사용하는 프로토콜 HTTPS는 HTTP에 보안 모듈을 결합시킨 프로토콜
• 소프트웨어 환경
1. 시스템 소프트웨어 : 클라이언트와 서버 운영을 위한 소프트웨어
2. 개발 소프트웨어 : 개발에 사용되는 소프트웨어
| 시스템 소프트웨어 | 운영체제 (OS) | |
| 서버 프로그램 | 웹 서버 및 WAS 운용 | |
| DBMS | ||
| 개발 소프트웨어 | 요구사항 관리 도구 | 요구사항의 수집과 분석, 추적 등을 편리하게 도와주는 소프트웨어 |
| 설계/모델링 도구 | UML(통합 모델링 언어)를 지원하며, 개발의 전 과정에서 설계 및 모델링을 도와주는 소프트웨어 |
|
| 구현 도구 | 개발 언어를 통해 애플리케이션의 실제 구현을 지원하는 소프트웨어 | |
| 빌드 도구 | 구현 도구를 통해 작성된 소스의 빌드 및 배포, 라이브러리 관리를 지원하는 소프트웨어 |
|
| 테스트 도구 | 모듈들이 요구사항에 적합하게 구현되었는지 테스트하는 소프트웨어 | |
| 형상 관리 도구 (버전 관리 도구) |
산출물들을 버전별로 관리하여 품질 향상을 지원하는 소프트웨어 |
• 개발 언어의 선정 기준
| 적정성 | 개발하려는 소프트웨어의 목적에 적합해야 함 |
| 효율성 | 코드의 작성 및 구현이 효율적이어야 함 |
| 이식성 | 다양한 시스템 및 환경에 적용이 가능해야 함 |
| 친밀성 | 개발 언어에 대한 개발자들의 이해도와 활용도가 높아야 함 |
| 범용성 | 다른 개발 사례가 존재하고 여러 분야에서 활용되고 있어야 함 |
4-2. 소프트웨어 아키텍처
• 소프트웨어 아키텍처
소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체
- 소프트웨어 아키텍처 설계의 기본 원리 : 모듈화, 추상화, 단계적 분해, 정보 은닉
• 1. 모듈화 (Modularity)
시스템의 기능들을 모듈 단위로 나누는 것을 의미
‣ 소프트웨어의 성능 향상, 시스템의 수정 및 재사용, 유지 관리 등 용이
‣ 모듈의 크기가 너무 작은 경우 : 모듈의 개수 증가 → 통합 비용 증가
‣ 모듈의 크기가 너무 큰 경우 : 모듈의 개수 감소 → 모듈 하나의 개발 비용 증가
• 2. 추상화 (Abstraction)
문제의 전체적이고 포괄적인 개념을 설계한 후 구체화시켜 나가는 것
‣ 불필요한 부분을 생략하고 필요한 부분을 강조하여 모델화
- 추상화의 유형
| 과정 추상화 | 전반적인 흐름만 파악할 수 있게 설계 ‣ 자세한 수행 과정을 정의하지 않음 |
| 데이터 추상화 | 데이터 구조를 대표할 수 있는 표현으로 대체 ‣ 데이터의 세부적인 속성이나 용도를 정의하지 않음 |
| 제어 추상화 | 대표할 수 있는 표현으로 대체 ‣ 이벤트 발생의 정확한 절차나 방법을 정의하지 않음 |
• 3. 단계적 분해 (Stepwise Refinement)
상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법
‣ 대략적인 설계에서 점차 세부적인 설계로 넘어가는 기법
‣ Niklaus Wirth에 의해 제안된 하향식 설계 전략
‣ 소프트웨어의 포괄적인 기능 → 알고리즘, 자료 구조 등 상세한 내역 순으로 구체화
• 4. 정보 은닉 (Information Hiding)
모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
‣ 모듈을 독립적으로 수행
‣ 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정, 시험, 유지보수가 용이
• 상위 설계와 하위 설계
| 상위 설계 | 하위 설계 | |
| 별칭 | 아키텍처 설계, 예비 설계 | 모듈 설계, 상세 설계 |
| 설계 대상 | 시스템의 전체적인 구조 | 시스템의 내부 구조 및 행위 |
| 세부 목록 | 구조, DB, 인터페이스 | 컴포넌트, 자료 구조, 알고리즘 |
• 소프트웨어 아키텍처의 품질 속성
- 품질 평가 요소의 종류
| 시스템 측면 | 성능, 보안, 가용성, 기능성, 사용성, 변경 용이성, 확장성 등 |
| 비즈니스 측면 | 시장 적시성, 비용과 혜택, 예상 시스템 수명, 목표 시장, 공개 일정 등 |
| 아키텍처 측면 | 개념적 무결성, 정확성, 완결성, 구축 가능성, 변경성, 시험성 등 |
• 소프트웨어 아키텍처의 설계 과정
| 설계 목표 설정 | 요구사항을 분석하여 전체 시스템의 설계 목표 설정 |
| ↓ | |
| 시스템 타입 결정 | 시스템과 서브시스템의 타입을 결정하고, 아키텍처 패턴 선택 |
| ↓ | |
| 아키텍처 패턴 적용 | 시스템의 표준 아키텍처 설계 |
| ↓ | |
| 서브시스템 구체화 | 서브시스템의 기능 및 서브시스템 간의 상호작용을 위한 동작과 인터페이스 정의 |
| ↓ | |
| 검토 | 설계 목표, 요구사항, 설계의 기본 원리 등을 만족하는지 아키텍처 검토 |
• 협약(Contract)에 의한 설계
컴포넌트를 설계할 때 클래스에 대한 여러 가정을 공유할 수 있도록 명세한 것
- 명세에 포함될 조건
| 선행 조건 (Precondition) | 오퍼레이션이 호출되기 전에 참이 되어야 할 조건 |
| 결과 조건 (Postcondition) | 오퍼레이션이 수행된 후 만족되어야 할 조건 |
| 불변 조건 (Invariant) | 오퍼레이션이 실행되는 동안 항상 만족되어야 할 조건 |
4-3. 아키텍처 패턴
• 아키텍처 패턴
아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
- 아키텍처 패턴의 종류

• 1. 레이어 패턴 (Layers Pattern)
시스템을 계층으로 구분하여 구성하는 고전 방법의 패턴
‣ 서로 마주보는 두 개의 계층 사이에서만 상호작용 발생
‣ 상위 계층은 하위 계층에 대한 서비스 제공자
‣ 하위 계층은 상위 계층의 클라이언트
‣ OSI 참조 모델

• 2. 클라이언트-서버 패턴 (Client-Server Pattern)
하나의 서버 컨포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
‣ 사용자가 클라이언트를 통해 서버에 요청
‣ 클라이언트가 응답을 받아 사용자에게 제공

• 3. 파이프-필터 패턴 (Pipe-Filter Pattern)
데이터 스트림 절차를 캡슐화하여 파이프를 통해 전송하는 패턴
‣ 시스템의 처리 결과물을 파이프를 통해 전달
‣ 데이터 변환, 버퍼링, 동기화 등에 주로 사용
‣ UNIX의 쉘(Shell)

• 4. 모델-뷰-컨트롤러 패턴 (Model-View-Controller Pattern)
서브 시스템을 모델, 뷰, 컨트롤러로 구조화하는 패턴
‣ 컨트롤러 : 사용자의 요청을 받음
‣ 모델 : 핵심 기능과 데이터 보관
‣ 뷰 : 정보 출력
‣ 여러 개의 뷰 생성 가능
‣ 대화형 애플리케이션에 적합
• 5. 기타 패턴
| 마스터-슬레이브 패턴 (Master-Slave Pattern) |
슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식 |
| 예) 장애 허용 시스템, 병렬 컴퓨팅 시스템 | |
| 브로커 패턴 (Broker Pattern) |
사용자가 원하는 서비스와 특성을 브로커 컴포넌트에 요청 브로커 컴포넌트가 요청에 맞는 컴포넌트와 사용자를 연결 |
| 예) 분산 환경 시스템 | |
| 피어-투-피어 패턴 (Peer-To-Peer Pattern) |
피어(Peer)라 불리는 하나의 컴포넌트가 클라이언트가 될 수도, 서버가 될 수도 있는 패턴 |
| 예) 파일 공유 네트워크 | |
| 이벤트-버스 패턴 (Event-Bus Pattern) |
소스가 특정 채널에 이벤트 메시지를 발행 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리 |
| 예) 알림 서비스 | |
| 블랙보드 패턴 (Blackboard Pattern) |
모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능한 패턴 |
| 예) 음성 인식, 차량 식별, 신호 해석 | |
| 인터프리터 패턴 (Interpreter Pattern) |
프로그램 코드의 각 라인을 수행하는 방법을 지정하고, 기호마다 클래스를 갖도록 구성된 패턴 |
| 예) 번역기, 컴파일러, 인터프리터 |