inroot

1. 소프트웨어 생명 주기

 ① 소프트웨어 공학

  ㆍ소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문임

  ㆍ소프트웨어의 개발, 운용, 유지보수에 대한 체계적인 접근 방법임

  ㆍ소프트웨어 품질과 생산성을 향상시킬 목적으로 함
  ㆍ경제적인 비용을 들여 신뢰성 높은 소프트웨어를 개발하기 위해 공학적 원리를 정립하고 이를 적용하는 것임

 ② 소프트웨어 공학의 기본 원칙
  ㆍ현대적인 프로그래밍 기술을 계속적으로 적용해야 함
  ㆍ개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야함
  ㆍ소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야함

 ③ 폭포수 모형(Waterfall Model)
  ㆍ이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론
  ㆍ보헴(Boehm)이 제시한 고전적 생명 주기 모형임
  ㆍ가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형임
  ㆍ개발 과정에서 발생하는 요구사항을 반영하기 어려움

 ④ 프로토타입 모형(Prototype Model, 원형 모형)
  ㆍ사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본(시제)품(Prototype)을 만들어 최종 결과물을 예측하는 모형
  ㆍ시제품은 의뢰자나 개발자 모두에게 공동의 참조 모델이 됨
  ㆍ시스템의 일부 혹은 시스템의 모형을 만드는 과정으로서 요구된 소프트웨어를 구현하는데, 이는 추후 구현단계에서 사용될 골격 코드가 됨
  ㆍ새로운 요구사항이 도출될 떄마다 이를 반영한 프로토타입을 새롭게 만들면서 소프트웨어를 구현하는 방법임
  ㆍ단기간 제작 목적으로 인하여 비효율적인 언어나 알고리즘이 사용될 수 있음

 ⑤ 나선형 모형(Spiral Model, 점진적 모형)
  ㆍ보헴(Boehm)이 제안한 것으로, 폭포수 모형과 프로토타입의 모형의 장점에 위험 분석 기능을 추가한 모형
  ㆍ나선을 따라 돌듯이 여러번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것
  ㆍ'계획 수립 → 위험 분석 → 개발 및 검증 → 고객 평가' 과정이 반복적으로 수행됨

  ㆍ핵심 기술에 문제가 있거나 사용자의 요구사항이 이해하기 어려운 경우에 적합한 모델임

 ⑥ 애자일 모형(Agile Model)

  ㆍ고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행함

  ㆍ애자일 모형을 기반으로 하는 소프트웨어 개발 모형

   - 스크럼(Scrum)

   - XP(eXtreme Programming)

   - 칸반(Kanban)

   - 린(Lean)

   - 크리스탈(Crystal)

   - ASD(Adaptive Software Development)

   - 기능 중심 개발(FDD ; Feature Driven Development)

   - DSDM(Dynamic System Development Method)

   - DAD(Disciplined Agile Delivery) 등

 ⑦ 애자일 개발 4가지 핵심 가치

  ㆍ프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다

  ㆍ방대한 문서보다는 실행되는 SW에 더 가치를 둔다

  ㆍ계획에 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다

2. 스크럼(Scrum) 기법

 ① 스크럼(Scrum) 팀

  ㆍ제품 책임자(PO; Product Owner)

   - 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정하는데, 주로 개발 의뢰자나 사용자가 담당

   - 이해관계자들의 의견을 종합하여 제품에 대한 요구사항을 작성하는 주체

   - 요구사항이 담긴 백로그(Backlog)를 작성하고 백로그에 대한 우선순위를 지정

  ㆍ스크럼 마스터(SM; Scrum Master) : 스크럼 팀이 스크롬을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할을 수행

  ㆍ개발팀(DT; Development Team) : 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로, 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상이 됨

 ② 스크럼 개발 프로세스

  ㆍ제품 백로그(Product Backlog) : 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 목록

  ㆍ스프린트 계획 회의(Sprint Planning Meeting) : 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 것

  ㆍ스프린트(Sprint) : 실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행

  ㆍ일일 스크럼 회의(Daily Scrum Meeting) : 모든 팀원이 매일 약속된 시간에 약 15분 정도의 짧은 시간동안 진행상황 점검

  ㆍ스프린트 검토 회의(Sprint Review) : 부분 또는 전체 완성제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅 수행

  ㆍ스프린트 회고(Sprint Retrospective) : 스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인하고 기록

3. XP(eXtreme Programming) 기법

 ① XP(eXtreme Programming)의 개요

  ㆍ수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법

  ㆍ대표적인 애자일 개발 방법론 중 하나

  ㆍ짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 함

  ㆍ자동화된 테스팅 도구를 사용하여 테스트를 지속적으로 수행

  ㆍ애자일 개발 방법론을 기반으로 수행

 ② XP의 핵심 가치

  ㆍ의사소통(Communication)

  ㆍ단순성(Simplicity)

  ㆍ용기(Courage) 

  ㆍ존중(Respect)

  ㆍ피드백(Feedback)

 ③ XP 개발 프로세스

  ㆍ사용자 스토리(User Story) : 고객의 요구사항을 간단한 시나리오로 표현

  ㆍ릴리즈 계획 수립(Release Planning) : 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 공개하는 것을 릴리즈라고 함

  ㆍ스파이크(Spike) : 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램

  ㆍ이터레이션(Iteration) : 하나의 릴리즈를 더 세분화 한 한단위를 이터레이션이라고 함

  ㆍ승인 검사(Acceptance Test, 인수 테스트) : 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트

  ㆍ소규모 릴리즈(Small Release) : 릴리즈를 소규모로 하게 되면, 고객의 반응을 기능별로 확인할 수 있어, 고객의 요구사항에 좀 더 유연하게 대응 가능

 ④ XP의 주요 실천 방법

  ㆍPair Programming(짝 프로그래밍) : 다른  사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경 조성

  ㆍCollective Ownership(공동 코드 소유) : 개발 코드에 대한 권한과 책임을 공동으로 소유

  ㆍContinuous Integration(계속적인 통합) : 모듈 단위로 나눠서 개발된 코드들은 하느이 작업이 마무리될 때마다 지속적으로 통합

  ㆍRefactoring(리팩토링) : 프로그램 기능의 변경 없이, 단순화, 유연성 강화 등을 통해 시스템의 내부 구조를 재구성

4. 현행 시스템 파악

 ① 현행 시스템 파악 절차

  ㆍ1단계 : 시스템 구성, 시스템 기능, 시스템 인터페이스 파악

  ㆍ2단계 : 아키텍처 구성, 소프트웨어(DBMS, 운영체제 등) 구성 파악

  ㆍ3단계 : 하드웨어 구성, 네트워크 구성 파악

5. 개발 기술 환경 파악

 ① DBMS 분석 시 고려사항 

  ㆍ가용성

  ㆍ성능

  ㆍ기술 지원

  ㆍ상호 호환성 

  ㆍ구축 비용

 ② WAS(Web Application Server) 

  ㆍ정적인 콘텐츠 처리를 하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어

  ㆍ종류 : Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere 등

6. 요구사항 정의

 ① 기능 요구사항

  ㆍ시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항

  ㆍ시스템의 입력이나 출력으로 무엇이 포함되어야 하는지, 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항

  ㆍ시스템이 반드시 수행해야 하는 기능

  ㆍ사용자가 시스템을 통해 제공받기를 원하는 기능

 ② 비기능 요구사항

  ㆍ성능 요구사항 : 처리속도 및 시간, 처리량 등의 요구사항

  ㆍ보안 요구사항 : 시스템의 데이터 및 기능, 운영 접근을 통제하기 위한 요구사항

  ㆍ품질 요구사항  : 품질 평가 대상에 대한 요구사항

 ③ 요구사항 개발 프로세스

  ㆍ도출(Elicitation) → 분석(Analysis) → 명세(Specification) → 확인(Validation)

 ④ 요구사항 도출(Requirement Elicitation, 요구사항 수집)

  ㆍ시스템, 사용자, 그리고 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정

  ㆍ요구사항 도출 기법 : 청취와 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등

 ⑤ 요구사항 명세 기법

 ⑥ 요구사항 확인(요구사항 검증)

  ㆍ분석가가 요구사항을 정확하게 이해한 후 요구사항 명세서를 작성했는지 확인하는 것이 필요

  ㆍ요구사항이 실제 요구를 반영하는지, 서로 상충되는 요구사항은 없는지 등을 점검

  ㆍ개발이 완료된 후 문제가 발견되면 재작업 비용이 발생할 수 있으므로 요구사항 검증은 매우 중요

  ㆍ요구사항 검증 과정을 통해 모든 문제를 확인할 수 있는 것은 아님

7. 요구사항 분석

 ① 요구사항 분석의 개요

  ㆍ소프트웨어 개발의 실제적인 첫 단계로 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동

  ㆍ사용자의 요구를 정확하게 추출하여 목표를 정하고, 어떤 방식으로 해결할 것인지를 결정

  ㆍ사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약 설정

  ㆍ개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정

  ㆍ사용자의 요구사항은 예외가 많고 지속적으로 변하므로 열거와 구조화가 어려움

  ㆍ내용이 중복되거나 하나로 통합되어야 하는 등 서로 상충되는 요구사항이 있으면 이를 중재하는 과정

  ㆍ요구사항 분석을 위해 애자일(Agile) 방법, UML(Unified Modeling Language), 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec), 개체 관계도(ERD), 상태 전이도(STD), 제어 명세서 등의 도구 이용

 ② 자료 흐름도의 구성 요소

 ③ 자료 흐름도의 작성 지침

  ㆍ자료 흐름은 처리(Process)를 거쳐 변환될 떄마다 새로운 이름을 부여함

  ㆍ어떤 처리(Process)가 출력 자료를 산출하기 위해서는 반드시 입력 자료가 발생해야 함

  ㆍ상위 단계의 처리(Process)와 하위 자료 흐름도의 자료 흐름은 서로 일치되어야 함

  ㆍ입력 화살표가 있다고 반드시 출력 화살표가 있어야 하는 것은 아님

 ④ 자료 사전의 표기 기호

8. 요구사항 분석 CASE와 HIPO

 ① SADT

  ㆍSoftTech사에서 개발한 구조적 분석 및 설계 도구

  ㆍ블록 다이어그램을 채택한 자동화 도구

 ② HIPO

  ㆍ시스템의 분석 및 설계나 문서화할 때 사용되는 기법으로, 시스템 실행 과정인 입력, 처리, 출력의 기능을 나타냄

  ㆍ하향식 소프트웨어 개발을 위한 문서화 도구

  ㆍ기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉬움

  ㆍ기능과 자료의 의존 관계를 동시에 표현할 수 있음

  ㆍ시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스 계층 구조로 표현한 것을 HIPO Chart라고 함 

 ㆍHIPO Chart의 종류: 가시적 도표(Visual Table of Contents), 총체적 도표(Overview Diagram), 세부적 도표(Detail Diagram)

9. UML(Unifled Modeling Language) 

 ① UML의 개요

  ㆍ시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어

  ㆍ구성 요소 : 사물(Things), 관계(Relationships), 다이어그램(Diagram)

 ② 사물(Things)

  ㆍ모델을 구성하는 가장 중요한 기본 요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말함

  ㆍ종류 : 구조 사물(Structural Things), 행동 사물(Behaviaral Things), 그룹 사물(Grouping Things), 주해 사물(Annotation Things)

 ③ 의존(Dependency) 관계

  ㆍ연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현

  ㆍ일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우에 나타나는 관계

 ④ 실체화(Realization) 관계

  ㆍ사물이 할 수 있거나 해야하는 기능(오퍼레이션, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현

  ㆍ한 사물이 다른 사물에게 오퍼레이션을 수행하도록 지정하는 의미적 관계

 ⑤ 일반화(Generalization) 관계

  ㆍ하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현

  ㆍ예를 들어 차는 버스, 트럭, 택시보다 일반적인 개념이고 반대로 버스, 트럭, 택시는 차보다 구체적인 개념임

 ⑥ 구조적(정적) 다이어그램의 종류

  ㆍ클래스 다이어그램

  ㆍ객체(Object) 다이어그램

  ㆍ컴포넌트 다이어그램

  ㆍ배치(Deployment) 다이어그램

  ㆍ복합체 구조(Composite Structure) 다이어그램

  ㆍ패키지 다이어그램

 ⑦ 행위(동적) 다이어그램의 종류

  ㆍ유스케이스 다이어그램

  ㆍ순차(Sequence) 다이어그램

  ㆍ커뮤니케이션 다이어그램

  ㆍ상태(State) 다이어그램

  ㆍ활동(Activity) 다이어그램

  ㆍ상호작용 개요(Interaction Overview) 다이어그램

  ㆍ타이밍 다이어그램

 ⑧ 상태(State) 다이어그램

  ㆍ하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지 표현

  ㆍ객체들 사이에서 발생하는 이벤트(event)에 의한 객체들의 상태 변화를 그림으로 표현

  ㆍ럼바우(Rumbaugh) 객체지향 부석 기법에서 동적 모델링에 활동

 ⑨ 활동(Activity) 다이어그램

  ㆍ시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현

  ㆍ오퍼레이션이나 처리 과정이 수행되는 동안 일어나는 일들을 단계적으로 표현

 ⑩ 스테레오 타입(Stereotype)

  ㆍUML에서 표현하는 기본 기능 외에 추가적인 기능을 표현

  ㆍ길러멧이라고 부르는 겹화살괄호(《》) 사이에 표현할 형태 기술

10. 주요 UML 다이어그램

 ① 유스케이스 다이어그램의 구성 요소

  ㆍ시스템/시스템 범위 : 시스템 내부에서 수행되는 기능을 외부 시스템과 구분하기 위해 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위 표현

  ㆍ액터 : 시스템과 상호작용을 하는 모든 외부 요소로, 사람이나 외부 시스템을 의미함

   - 주액터 : 시스템을 사용함으로써 이득을 얻는 대상으로, 주로 사람이 해당

   - 부액터(시스템 액터) : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템으로, 조직이나 기관 등이 될 수 있음

  ㆍ유스케이스 : 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능을 표현한 것

  ㆍ관계(Relationship) : 유스케이스 다이어그램에서 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있으며, 연관 관계, 포함 관계, 확장 관계, 일반화 관계를 표현할 수 있음

 ② 유스케이스 확장 관계

  ㆍ유스케이스가 특정 조건에 부합되어 유스케이스의 기능의 확장될 떄 원래의 유스케이스와 확장된 유스케이스와의 관계

 ③ 클래스 다이어그램 - 오퍼레이션(Operation)

  ㆍ클래스가 수행할 수 있는 동작으로, 함수(메소드)라고도 함

 ④ 순차 다이어그램의 개요

  ㆍ시스템이나 객체들이 메세지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 액터, 객체, 메세지 등의 요소를 사용하여 그림으로 표현한 것

  ㆍ순차 다이어그램은 시스템이나 객체들의 상호 작용 과정에서 주고받는 메세지를 표현

  ㆍ순차 다이어그램에서는 수직 방향은 시간의 흐름을 나타냄

 ⑤ 순차 다이어그램의 구성 요소

  ㆍ액터(Actor)

  ㆍ객체(Object)

  ㆍ생명선(Lifeline)

  ㆍ실행 상자(Active Box)

  ㆍ메세지(Message)

  ㆍ회귀 메세지(Reply/Reture Message)

  ㆍ제어 블록(Loop)

안녕하세요. inroot 입니다.

제가 인터넷가입을 해야할 일이 생겨서 알아보다가 "인잘알"에서 가입을 해봤는데요.

너무 만족스러워서 후기로 작성해보고자 합니다 😶

저는 한번도 인터넷가입을 개별로 해본적이 없는데요. 그래서 무작정 후기를 찾아보고 연락하게 되었습니다.

저는 굉장히 소심한 성격이고, 인터넷 가입에 대해서 아는게 하나도 없어서 걱정을 많이했는데

상담사님이 일단 굉장히 친절하시고 초보자도 알기쉽게 설명해주십니다. ☺️(감사합니다.)


다 하나하나 설명해주시고 보내주시는 양식을 작성해야 합니다.

저는 티비와 컴퓨터도 연결할거라 500MB로 가입하게 되었답니다!!!!

오늘 오후에 상담사님이랑 통화하고 접수를 했는데 당일 5시 경 기사님이 방문해주셨어요!!
와이파이도 안되고 티비도 못보는 저를 구원해주신 기사님 감사합니다. 😢😢

인잘알을 이용해보고 추천해드리는 이유는 다음과 같습니다

1. 친절하신 설명
2. 알아보기 쉬운 양식
3. 빠른 접수 및 설치
4. 사은품 및 지원금 지급
    + 카톡 상담사님이 굉장히 답변이 빠르고 지급도 바로바로 해주신답니다!! ☺️☺️☺️


인터넷가입을 하실일이 있으면 사은품이나 지원급 비교도 어렵고 어떤 곳에 가입해야할지 하나도 감이 안오실텐데, 이럴때는 인잘알을 적극적으로 추천드립니다 :)

#01_리눅스 설치 개요

(1) 리눅스 설치 파일은 해당 배포본의 홈페이지에서 다운로드 가능

(2) 리눅스는 단 하나의 제품 또는 한 종류의 제품군만 있는 것이 아님

(3) 특수한 목적으로 개발된 임베디드 디바이스에 적용된 리눅스부터 일반 사용자를 위해 만들어진 PC 또는 노트북과 같은 하드웨어에 사용할 수 있는 리눅스까지, 많은 종류의 리눅스 운영체제 존재

(4) 리눅스 배포판마다 설치 환경과 과정이 상이

(5) 리눅스 설치 유형은 배포판마다 다르지만 패키지에 따라 데스크톱형, 서버형, 사용자 정의형으로 구분

 - 사용자 설정 시스템을 제외한 다른 설치 유형을 선택하게 되면 인스톨에서 하드디스크를 자동으로 재구성하므로 기존 데이터 모두 제거

(6) 설치 전에 시스템에 있는 모든 파일은 반드시 백업

 - 디스크를 파티션하면 파티션 프로그램으로 어떤 프로그램을 사용하든 간에 그 디스크에 있는 모든 파일 지워짐

(7) 멀티 부팅 시스템을 만든다면, 현재 운영체제의 배포 미디어를 가지고 있어야 함

(8) 부팅 드라이브를 다시 파티션하는 경우라면, 운영체제의 부트로더를 다시 설치해야 할수도 있고, 더 많은 경우에 운영체제 전체를 해당 파티션에 다시 설치해야 함

#02_리눅스 설치를 위한 하드웨어 정보 파악

(1) 하드웨어 정보

 - 최근 리눅스 배포판들은 하드웨어 호환성이 우수

 - 설치 마법사의 Plug and Play(PNP) 기능으로 자동으로 하드웨어 검색

 - 설치 전에 하드웨어에 대한 정보를 알아두는 것이 설치 작업에 용이

 - 하드웨어 정보 파악은 하드웨어 문제가 발생했을 때 장애처리의 실마리가 될 수 있음

 - 설치를 위한 하드웨어 정보를 파악하여야 함

 - 필요한 시스템 정보를 얻을 수 있는 방법은 아래와 같음

  ㆍ시스템 구매 시 받은 제품 설명서

  ㆍBIOS 설정 화면 : 시스템에 전원을 넣고 [F2] 또는 [Delete]를 누르면 BIOS 설정 화면 표시

  ㆍ장치 관리자 : 윈도우 시스템이 설치되어 있다면 [제어판] → [시스템 및 보안] → [장치 관리자] 선택 실행

  ㆍ시스템 정보 수집 프로그램 사용

 - 시스템이 네트워크에 연결되어 있는 상태라면 네트워크 정보를 정확히 기록

 - 시스템의 이름 정보(호스트 이름, 도메인 이름)와 TCP/IP 주소 정보(IP 주소, 넷마스크, 게이트웨이 주소, DNS 주소) 필요

 - 윈도우에서는 [제어판] → [네트워크 및 인터넷] → [네트워크 및 공유 센터] 를 선택하고 필요한 정보 수집

(2) 하드웨어 호환성

 - 리눅스는 많은 하드웨어 제품들에서 문제없이 작동하지만 다른 운영체제들(ex.Windows)만큼 다양한 종류를 하드웨어에서 동작하지 못함

 - 하드웨어 호환성은 다음의 방법으로 확인 가능

  ㆍ제조사의 웹 사이트에서 새 드라이버 확인

  ㆍ웹 사이트와 맨얼에서 에뮬레이션에 대한 정보 찾기(덜 알려진 상표의 제품이 더 많이 알려진 제품의 드라이버와 설정들을 그대로 사용)

  ㆍ해당 아키텍처에 관한 웹사이트에서 리눅스 하드웨어 호환성 목록 확인

(3) 네트워크 설정

 - 시스템 관리자는 네트워크 설정에 대한 정보를 알고 있어야 함

  ㆍ호스트명과 도메인

  ㆍ컴퓨터의 IP 주소, 서브넷 마스크

  ㆍ게이트웨이 주소

  ㆍDNS 서버 주소

 - 무선 네트워크를 사용한다면 무선 네트워크 SSID와 보안키를 사용할 경우 WEP 키 확인

#03_리눅스 설치

(1) CentOS 리눅스 주요 버전은 다음과 같음

(2) CentOS 7부터 커널 3.X 이상을 사용

(3) 커널(Kernel)

 - 운영체제의 핵심 부분으로 CPU나 메모리, 기타 디바이스 등의 시스템 자원을 관리하고 사용자 프로그램이 사용할 수 있도록 함

 - 커널 버전은 검증이 완료된 안전 버전과 개발 중인 개발 버전으로 분류

 - 커널명은 '주버전.부버전,배치버전'으로 구성

 - 부버전이 짝숭면 안정 커널이고, 홀수이면 개발 커널임

(4) 다음은 CentOS 7을 설치하기 위한 최소 하드웨어 요구사항임

#01_GNU(GNU's Not UNIX)

(1) 리처드 스톨만이 자유 소프트웨어 재단에서 진행하며 유지중인 운영체제 프로젝트

(2) 리처드 스톨만이 1983년에 GNU 개발 시작

 - GNU는 'GNU(그누)는 유닉스가 아니다(GNU's Not UNIX).'의 약자

(3) GNU 프로젝트를 통하여 개발하 유닉스 계열 컴퓨터 운영체제로 '완전한 유닉스 호환 소프트웨어 시스템'이 되는 것이 목표

#02_자유 소프트웨어 재단(FSF, Free Software Foundation)

(1) 1985년 리처드 스톨만이 설립한 재단

(2) 자유 소프트웨어는 사용자가 소프트웨어를 실행, 복제, 배포, 학습, 개작, 향상할 수 있는 소프트웨어

(3) 자유 소프트웨어의 특징은 다음과 같음

 - 어떤 목적이든 원하는대로 프로그램을 실행시킬 수 있는 자유

 - 무료 또는 유료로 프로그램 복제물을 재배포할 수 있는 자유

 - 필요에 따라 프로그램을 개작할 수 있는 자유

 - 공동체 전체가 개선된 이익을 나눌 수 있게 개작한 프로그램을 배포할 수 있는 자유

(4) 자유는 금전적인 측면과 관계가 없기 때문에 자유 소프트웨어를 유료로 판매할 때 문제가 생기지는 않음

#03_오픈 소스 소프트웨어(Open Source Software)

(1) 1998년 일부 커뮤니티에서 '자유 소프트웨어' 대신 '오픈 소스 소프트웨어'라는 용어를 사용하기 시작

(2) 이것은 자유가 가진 무료라는 의미가 일으키는 혼동을 피하기 위함

#04_GNU GPL(General Public License)

(1) GPL은 Free Software Foundation(FSF)에서 만든 Free 소프트웨어 라이선스

(2) 1989년 1차 버전, 1991년 2차 버전, 2007년 3차 버전까지 발표

(3) 기본적으로 어떤 프로그램을 개발할 때, GPL 코드를 일부라도 사용하게 되면 해당 프로그램은 GPL이 됨. GPL을 가진 프로그램을 유료로 판매하는 것은 가능하지만, 반드시 전체 소스코드는 무료로 공개

(4) GPL 코드를 사용한 소프트웨어를 내부적인(개인, 기관, 단체 등) 목적으로만 사용할 땐 소스코드를 공개할 필요가 없지만 어떤 형태(유료, 무료)로든 외부에 공표 및 배포할 때는 전체 소스코드를 공개

(5) GPL 전문 : 만일 배포하고자 하는 프로그램의 특정 부분이 GPL 코드로부터 파생된 것이 아닌 독립적인 저작물일 경우에는 독립 저작물 모듈의 개별적인 배포에는 GPL이 적용되지 않음(즉, 코드를 공개할 필요 없음). 하지만 프로그램을 전체(GPL 코드에서 파생된 모듈 + 독립 저작물 모듈)적으로 배포할 때에는 GPL을 따라야 함

#05_GNU LGPL(Lesser General Public License)

(1) LGPL은 GPL보다 훨씬 완화된 조건의 공개 소프트웨어 라이선스

(2) LGPL이 적용된 라이브러리를 이용하여 개발하였을 경우 프로그램 소스코드는 공개하지 않아도 됨

(3) LGPL 코드를 사용했음만 명시하면 됨

(4) LGPL 코드를 단순히 이용하는 것이 아니라 이를 수정한 또는 이로부터 파생된 라이브러리를 개발하여 배포하는 경우에는 전체 코드 공개

#06_BSD(Berkeley Software Distribution) 라이선스

(1) 버클리 캘리포니아 대학의 자유 소프트웨어 저작권의 한가지

(2) BSD 계열의 소프트웨어를 포함한 많은 프로그램에서 사용

(3) 소스코드 공개 의무가 없으며 상용 소프트웨어에서도 무제한 사용 가능한 라이선스

 - 해당 소프트웨어는 아무나 개작할 수 있고, 수정한 것을 제한 없이 배포할 수 있음

 - 수정본의 재배포는 의무적인 사항이 아니므로 상용 소프트웨어에서도 사용 가능

 - GPL은 파생된 소프트웨어여도 GPL과 같은 라이선스를 갖도록 의무화하고 있다는 것에 BSD와 차이를 둠

(4) OpenCV는 BSD 라이선스를 따름

#07_아파치(Apache) 라이선스

(1) 아파치 소프트웨어 재단에서 자체적으로 만든 소프트웨어에 대한 라이선스 규정

(2) 아파치 2.0 라이선스는 누구나 해당 소프트웨어에서 파생된 프로그램을 제작할 수 있으며 저작권을 양도, 전송할 수 있는 라이선스 규정

 - 누구든 자유롭게 아파치 소프트웨어를 다운로드 받아 부분 또는 전체를 개인적 혹은 상업적 목적으로 이용 가능

 - 재배포 시 원본 소스코드 또는 수정한 소스코드를 반드시 포함시켜야 하는 것은 아니지만 아파치 라이선스 버전 2.0을 포함시켜야 하며, 아파치 소프트웨어 재단에서 개발된 소프트웨어라는 것을 명확하게 밝혀야 함

#08_MIT(Massachusetts Instiute of Technology) 라이선스

(1) 미국 매사추세츠 공과 대학교에서 본교의 소프트웨어 공학도들을 돕기 위해 개발한 허가서

(2) BSD 라이선스를 기초로 작성된 BSD 계열 라이선스 중 하나

(3) 해당 소프트웨어는 누구나 개작할 수 있고, 수정본의 재배포 시에 소스코드 비공개가 가능

(4) 이 라이선스가 적용된 소프트웨어는 X Window System, JQuery, Node.js 등이 존재

(5) 소프트웨어를 개조한 제품을 반드시 오픈소스로 배포해야 한다는 규정이 없으며, GNU 일반 공중 허가서의 엄격함을 피하려는 사용자들에게 인기

 - GNU 일반 공중 사용 허가서(GPL) 등과 달리 카피 레프트는 아니며, 오픈소스 여부에 관계 없이 재사용 인정

(6) MIT 허가서를 따르는 대표적 소프트웨어로 X 윈도우 시스템(X11) 존재

#09_MPL(Mozila Public License)

(1) 오픈소스와 자유 소프트웨어 라이선스

(2) 1.0판은 넷스케이프 커뮤니케이션즈 코퍼레이션의 변호사로 일하고 있던 미첼 베이커에 의해 작성되었고, 1.1판은 모질라 재단이 작성

(3) MPL은 변형 BSD 사용 라이선스와 GNU 일반 공중 사용 라이선스의 혼합적 성격

(4) 모질라 어플리케이션 스위트, 모질라 파이어폭스, 모질라 선더버드 및 그 외의 모질라 소프트웨어들에 적용

(5) MPL의 특징은 소스코드와 실행파일의 저작권을 분리했다는 점

(6) 수정한 2차 소스코드는 MPL로 공개하고 원저작자에게 수정한 부분에 대해 알려야 하지만, 실행 파일은 독점 라이선스로 배포

(7) 사용한 MPL 소프트웨어와 수정한 MPL 소프트웨어에 대한 공개 의무만 가지며, 별도의 소스코드와 실행파일은 독점 라이선스를 가질 수 있음

#01_1960년대 후반

(1) 1965년 MIT, AT&T 벨 연구소, General Electric에서는 Multics라는 실험적인 운영체제를 공동으로 개발하는 프로젝트 진행

(2) 이 프로젝트 팀은 멀티태스킹, 멀티유저를 지원하는 초기 형태의 시분할 운영체제 제작

(3) 1969년 프로젝트에 참여했던 벨 연구소 연구원 켄 톰슨(Ken Thompson)이 초기 형태의 UNIX 개발 

#02_1970년대

(1) 1971년 벨 연구소의 데니스 리치(Dennis Ritchie)가 C언어를 개발함으로써, 어셈블리 언어로 되어 있던 UNIX가 C언어로 재작성 됨

(2) C언어로 개발된 UNIX는 이식성과 호환성 있는 시스템으로 발전

 - 소스 프로그램이 공개되어 있었던 UNIX는 Berkeley UNIX(BSD)와 SYSV로 분열되어 발전

#03_1980년대 초중반

(1) MIT 연구소의 연구원이었던 리처드 스톨먼(Richard Stollman)은 소스를 공개하지 못하도록 하는 분위기와 기술을 상업화하려는 조류에 대한 반감으로 GNU(GNU is Not Unix) 프로젝트를 시작

(2) 1985년 리처드 스톨먼은 FSF(Free Software Foundation, 자유 소프트웨어 재단)라는 비영리단체를 설립 후 'GNU 선언문(Manifesto)'을 발표

 - 개발이 진행된 프로그램들은 GNU 프로그램들의 배포 라이선스인 GPL하에서 판매

(3) 1987년 앤드루 타넨바움(Andrew Tanenbaum)은 미닉스(MINIX)를 개발

 - 미닉스는 자유/오픈 소스 소프트웨어로 교육용 유닉스 계열 운영체제

#04_1990년대 초중반

(1) 핀란드의 헬싱키 대학의 리누스 토발즈(Linux Torvalds)가 Minix의 커널 소스를 고쳐 GNU 시스템에 적합한 커널 개발

(2) 스톨먼과 FSF는 유닉스 커널과 호환 가능한 커널인 리눅스를 GNU 시스템의 커널로 채택

(3) 1994년에 리눅스 커널 버전 1.0 발표

(4) 1996년에 리눅스 커널 버전 2.0 발표

#1_리눅스 특징 및 장단점

(1) 리눅스의 특징

 - 오픈 소스 운영체제

  ㆍ소스코드 및 모든 관련 자료가 공개되어 있는 운영체제

 - 멀티유저(다중 사용자), 멀티태스킹(다중 작업) 운영체제

  ㆍ멀티유저 기능이란 여러 사용자가 동시에 동일한 시스템에 접근이 가능한 것을 의미

  ㆍ멀티태스킹은 여러 개의 테스크를 동시에 실행하고, 교대로 컴퓨터의 자원을 사용할 수 있는 기능

  ㆍ가상 터미널 환경으로 하나의 모티러에 여러 개의 가상 화면을 두어 화면마다 다른 작업 실행 가능

 - 다중 스레드를 지원하는 네트워크 운영체제

  ㆍ하나의 프로세스 내에서 여러 개의 네트워크 작업을 동시에 처리할 수 있기 때문에 강력한 네트워크 지원 가능

  ㆍ네트워크 서버로 사용이 가능하며 인터넷과 이더넷에 안정적으로 연결 가능

  ㆍ웹 브라우저, 메일, 뉴스, 웹 서버 등의 모든 인터넷 서비스 기능을 갖춤

 - 여러 종류의 파일 시스템 지원

  ㆍ리눅스의 기본 파일 시스템인 ext2, ext3, ext4, DOS의 FAT16, Windows의 FAT32, NTFS, 네트워크 파일 시스템 SMB, CIFS, NFS 등 지원

 (2) 리눅스의 장점

 - 리눅스는 유닉스와 완벽하게 호환 가능

  ㆍ리눅스는 POSIX(Portavle Operating System Interface) 규격을 따름

  ㆍPOSIX는 유닉스 운영체제에기반을 두고 있는 표준 운영체제 인터페이스를 말함

  ㆍ리눅스는 POSIX 표준화를 기반하기 때문에 유닉스 소스코드를 전혀 사용하지 않고 개발됨

  ㆍPOSIX 규격을 따르기 때문에 유닉스용 프로그램은 별도의 수정 없이 리눅스에서 동작할 수 있음

 - 리눅스는 PC용 운영체제보다 안정적

  ㆍ일반 PC는 업무가 끝나면 전원을 끄지만 리눅스는 네트워크 사용을 전제로 설계되었기 때문에 특별한 사항을 제외하고 항상 켜 놓아도 안정적으로 운영

  ㆍ리눅스는 네트워크 기반 하의 멀티유저, 멀티태스킹이 가능하여 많은 작업자가 동시에 사용해도 안정적인 시스템 운영 가능

 - 하드웨어 기능을 효과적으로 사용

  ㆍ다른 운영체제보다 적은 양의 메모리를 필요로 함

  ㆍSWAP 방식을 통해 램(RAM)이 부족한 경우 Swap 영역을 늘려 메모리의 효율성을 높일 수 있음

 - 리눅스는 오픈 소스 운영체제임

  ㆍ많은 인재가 확보되어 있기 때문에 우수한 소프트웨어 개발이 가능하고 여러 배포판 개발 업체들이 있어 사용자에게 넓은 선택권이 주어짐

  ㆍ다양한 배포판이 존재하여 운영체제뿐만 아니라 여러가지 유틸리티 프로그램 및 응용 프로그램을 무료로 제공

(3) 리눅스의 단점

 - 공개 운영체제이기 때문에 문제점 발생 시 기술 지원의 한계

  ㆍRHEL과 SUSE과 같은 몇몇 엔터프라이즈용 리눅스 들은 기술 지원이 유료로 제공되고 있으나 대부분은 예상치 못한 오류 발생 시 개발자들의 기술 지원을 직접적으로 받는 것이 불가능

 - 한글 지원 미흡

  ㆍ배포판마다 별도의 한글 지원 패키지를 설치한 후 사용해야 한다는 불편함 존재

 - 보안상의 취약점이 쉽게 노출될 가능성 존재

  ㆍ공개 운영체제이기 때문에 보안에 취약할 것이라는 선입관이 있으나 꾸준한 기술 개발로 비교적 높은 보안성 지원

  ㆍ많은 프로그래머들이 리눅스를 연구하고 있기 때문에, 보안 문제가 발생하였을 경우 신속하게 해결 가능

#2_리눅스 디렉터리 종류와 특징

(1) 디렉터리란 파일 저장소를 의미하며, 리눅스 디렉터리는 최상위 디렉터리(/)를 기준으로 하위 디렉터리들이 존재하는 계층적 트리 구조로 구성

(2) 디렉터리 간에는 부모와 자식의 관계를 가지므로 상위 디렉터리와 하위 디렉터리는 부모 디렉터리와 자식 디렉터리로 구분

(3) 디렉터리별 저장 내용은 아래 표와 같음

 - 디렉터리 /proc

  ㆍ가상 파일 시스템

  ㆍ시스템에서 운영되고 있는 다양한 프로세스들에 관한 내용과 프로그램에 대한 정보 포함

  ㆍ디렉터리에서 볼 수 있는 것은 실제 드라이브가 아니라 메모리 상에 저장

  ㆍ사용자가 /proc이나 하위 파일에 접근할 때마다 커널에서 파일 내용을 동적으로 생성

  ㆍ각 프로세스는 고유의 식별자를 가지고 있으며, 이 식별자를 가진 디렉터리 밑에 정보 저장

 - 디렉터리 /lib

  ㆍ동적 공유 라이브러리 저장

  ㆍ공유 라이브러리에는 많은 프로그램에서 공통으로 사용하는 함수들이 들어있어 디스크의 공간을 절약할 수 있으며, 프로그램마다 동일한 코딩을 할 필요가 없음

  ㆍ라이브러리 공유 방법에는 정적 라이브러리와 동적 라이브러리 두 가지 방법 존재

  ㆍ정적 라이브러리는 컴파일 과정에서 공유 라이브러리의 루틴을 사용하지 않고 프로그램 내에 라이브러리 루틴의 복사본을 갖도록 컴파일

  ㆍ동적 라이브러리는 실행 파일 내부에 라이브러리를 넣어두지 않고 프로그램을 실행할 때 가져와 사용하므로 메모리의 효율성이 높음

 - 디렉터리 /dev

  ㆍ하드디스크, 프리넡, 입출력장치 등과 같은 장치들을 파일화하여 관리하므로 특정장치를 실행하기 위해서는 해당 장치파일을 실행해야함

  ㆍ장치 파일(device file) 또는 특수 파일(special file)은 장치 드라이버임

  ㆍ블록 장치 파일(block device)은 하드디스크, CD/DVD, 플로피 디스크와 같은 저장 장치들이며, 문자 장치 파일(character device)은 키보드, 마우스, 테이프, 모니터, 프린터 드의 같은 입출력장치들임

  ㆍ리눅스의 표준 입력장치는 키보드이며, 표준 출력장치는 모니터

 - 디렉터리 /etc

  ㆍ시스템 환경설정 파일과 부팅 관련 스크립트 파일들이 저장되어 있는 디렉터리

  ㆍ사용자 정보 및 암호 정보 파일, 보안 파일 등을 저장

 - 디렉터리 /usr

  ㆍ시스템이 아닌 일반 사용자들이 사용하는 디렉터리

  ㆍ공유 가능한 프로그램들이 설치되며 네트워크를 이용해서 여러 개의 시스템을 연결할 경우 이 디렉터리를 공유해서 설치된 프로그램들을 활용할 수 있음

  ㆍ/usr 디렉터리는 읽기 전용으로 마운트 되어야 하며, 가변 자료들은 /var 디렉터리로 심볼릭 링크로 이동

 - 디렉터리 /var

  ㆍ시스템에서 사용되는 가변적인 파일들을 저장하는 디렉터리

  ㆍ가변적인 파일들로는 로그파일, 스풀링, 캐싱 등 존재

 - 디렉터리 /lost+found

  ㆍ파일 시스템의 이상 유무를 진단하고 복구하는 fsck에 의해서 사용되는 디렉터리

  ㆍ손상된 파일이나 디렉터리를 /lost+found 디렉터리로 연결한 뒤에 오류를 수정하게 되며 평상시에는 null 파일 링크에 의해서 비어있는 상태로 존재

  ㆍ리눅스 파일 시스템 ext2에 의한 fsxk, ext2 프로그램도 해당 디렉터리를 사용

#3_리눅스 배포판

(1) 특징

 - 리눅스 배포판은 리눅스 전체 시스템을 구성하는 소프트웨어 패키지 형태로 구성

 - 리눅스 커널, GNU 소프트웨어 및 여러가지 자유 소프트웨어로 구성된 운영체제

  ㆍ운영체제는 리눅스 커널과 GNU 프로젝트에서 가져온 라이브러리와 유틸리티, X 윈도우 시스템의 그래픽으로 구성되며, 워드 프로세서, 스트레드시트, 미디어 플레이어, 데이터베이스 등 여러 가지 소프트웨어 애플리케이션들도 포함

 - 전 세계에 300여가지 배포판이 있으며, 배포판을 구성하는 소프트웨어도 자유롭게 구성되어 있음

  ㆍ용량을 맞춰서 X 윈도우를 빼거나 용량이 작은 GNU 유틸리티를 선택하기도 함

 - 대표적인 배포판은 슬랙웨어, 데비안, 레드햇 등 존재

  ㆍ페도라(Fedora)는 레드햇, openSUSE는 노벨, 우분투(Ubuntu)는 캐노니컬 등의 기업이 관리하는 배포판

  ㆍ데비안(Debian)이나 젠투(Gentoo)는 리눅스 커뮤니티 기반 배포판

(2) 종류

 - 슬랙웨어 리눅스(Slackware Linux)

  ㆍ배포판 가운데 가장 먼저 대중화된 배포판으로 1992년 패드릭 볼커딩에 의해 출시

  ㆍ최근 패키지 관리의 문제점으로 인하여 인기가 다소 떨어짐

  ㆍ구조가 간결하고 파악하기 쉽게 때문에 유닉스 학습에 리눅스를 사용하고 싶어 하는 사용자들에게 적합

 - 데비안(Debian)

  ㆍ1994년 이안머독(Ian Murdock)에 의해 비영리 조직으로 데비안 프로젝트 설립

  ㆍ데비안 프로젝트에서 만들어 배포하는 공개 운영체제로 GNU의 공식적인 후원을 받고 있는 유일한 배포판

  ㆍ리눅스 커널을 탑지한 대비안 GNU/리눅스, GNU 허드 커널을 탑재한 데비안 GUN/허드, FreeBSD 커널을 탑재한 데비안 GNU/KFreeBSD, NetBSD 커널을 탑재한 데비안 GNU/NetBSD 등으로 나뉘며 현재 이 가운데 정식판이 존재하는 것은 데비안 GNU/리눅스 뿐임

  ㆍ데비안은 패키지 설치 및 업그레이드 과정이 단순하며, 인스톨 후 패키지 매니저인 apt 등을 이용하면 소프트웨어의 설치가 업데이트에서 다른 패키지와의 의존성 확인, 보안관련 업데이트 자동으로 수행 가능

 - 우분투(Ubuntu)

  ㆍ데비안 GNU/리눅스(Debian GNU/Linux)에 기초한 운영체제

  ㆍ고유한 데스크탑 환경인 유니티를 사용하는 리눅스 배포판

  ㆍ영국에 기반을 둔 회사인 캐노니컬의 지원을 받음

  ㆍ여섯 달마다 새 버전이 하나씩 배포, GNOME의 새 버전이 나오는 시기와 유사

  ㆍ사용자 편의성에 초점

 - 레드햇

  ㆍ미국의 레드햇사가 개발하던 리눅스 배포판

  ㆍ현재는 레드햇사가 유료로 기술지원을 하는 기업용 레드햇 엔터프라이즈 리눅스(RHEL)와 페도라 프로젝트에서 개발하고 있는 페도라로 분류

  ㆍ레드햇은 기업용 유료 리눅스 배포판인 RHEL의 개발을 지원

 - RHEL(Red Hat Enterprise Linux)

  ㆍ레드햇이 개발하여 판매하고 있는 상용 리눅스 배포판

  ㆍ18~24개월에 한번씩 새로운 버전이 공개되며 라이선스는 별도로 판매하지 않음

  ㆍ서브 스크립션의 형태로 요금을 지불하는 방식으로 계약

  ㆍ기술 지원은 버전마다 출시 시점으로부터 7년동안 제공

  ㆍ계약기간 중에는 추가 비용 없이 업그레이드 및 다운그레이드를 자유롭게 실시할 수 있음

  ㆍ상업용 패키지는 구입해야 하지만 소스코드는 레드햇의 FTP 사이트를 통하여 공개

 - 페도라

  ㆍ리눅스 커널에 기반한 운영체제와 레드햇의 후원과 개발 공동체의 지원 아래 개발된 배포판

  ㆍ일반적인 목적을 가진 RPM 기반의 소프트웨어가 결합된 운영체제

  ㆍ6개월 간격으로 새로운 버전이 배포되며 지원기간은 각 버전마다 13개월

  ㆍ소프트웨어 개발이 안정적으로 이루어지기 위해서는 새 버전으로 계속 교체되어야 한다는 문제점 존재

 - CentOS

  ㆍ업스트림 소스인 레드햇 엔터프라이즈 리눅스와 완벽하게 호환되는 무료 기업용 컴퓨팅 운영체제

  ㆍ플랫폼을 제공할 목적으로 만들어진 리눅스 운영체제

  ㆍ자체 커뮤니티에 의하여 관리

  ㆍ기본적으로 포함되는 소프트웨어와 업데이트되는 소프트웨어를 아울러 이전 파일에 대한 상위판과 100%에 최대한 가까운 호환성을 유지하는 것이 원칙

  ㆍ레드햇의 기술 지원은 받지 않음

 - 수세(SUSE)

  ㆍ독일에서 출시된 배포판으로 유럽에서 인기

  ㆍ풍부한 기능과 안정성, 보안 기능 포함

  ㆍ정기적인 배포판이 존재한다기보다는, 언제든지 새로운 버전이 출시되면 업데이트가 가능한 롤링 릴리즈(rolling release) 방식 사용

  ㆍ오픈 수세, 수세 엔터프라이즈 리눅스로 분류

요즘 안드로이드 기반 악성코드가 지속적으로 유포되고 있습니다.

이번에 분석할 악성코드는 SNS나 채팅 등으로 유포되고 있는 "OPlayer Lite.apk" 악성코드 입니다.

파일명 : OPlayer Lite.apk
MD5   : a3240dcede5740819fe68ec38c535086
SHA-1 : 3f2ce5445dfc43a5086877a803c755fa45217afd
SHA-256 : 2c25e9ed36e4c63456c719392783d6b129103eeeeaba94bc3fa1e2f899ed8525

해당 악성코드는 실행 시, 전화번호 기재 란을 볼 수 있으며 SMS, 연락처 등의 권한 요청을 수행하게 됩니다.

악성코드가 요청하는 권한을 살펴보면 CONTACTS, SMS, STORAGE 등 핸드폰 내부 정보 탈취가 가능한 여러 퍼미션들이 포함되어 있는 것을 확인 할 수 있습니다.

파일(index.android.bundle) 코드 분석 결과, 다음과 같은 도메인과 통신함을 확인할 수 있습니다.

http[s://www.hd]playerhub.xyz/

해당 악성코드 설치 및 실행 시, 어떤 악의적인 동작을 하는지 살펴보도록 하겠습니다.

(1) "악성 도메인/index/Phone_Obtain/add" 로 핸드폰 정보를 전송합니다.

(2) "악성 도메인/index/Phone_user/add"로 주소록 내용을 전송합니다.

(3) "악성 도메인/index/Phone_sms/add"로 SMS 기록을 전송합니다.

그 외에도 이미지 파일 등의 정보 전송을 요청하는 것을 확인할 수 있습니다.

해당 악성코드 바이러스 토탈 조회 결과, 국내 백신에서는 탐지되지 않아 각별한 주의가 필요해보입니다.

# 악성코드 분석은 https://open.kakao.com/o/s6vnducc 으로 문의주세요. #

※본 게시물에는 결정적인 스포가 포함되어 있습니다※

귀멸의 칼날 극장판이 드디어 개봉했다!!!

몇달동안 기다려 와서 되게 반가운 소식 ㅠㅠㅠㅠㅠ

처음은 "메가박스" 일반 상영관에서 관람을 했다.

사실 극장판에 대한 큰 재미는 기대 안했지만 귀멸의 칼날 애니메이션을 너무 재밌게 봐서 시간되자마자 바로 달려갔다.

후기를 한마디로 표현하자면, "기대 이상이였다" 

적절한 교훈과 감동을 주는 부분도 맘에 들었으며, 특히 액션씬에서는 눈을 뗄수가 없었다.

그리고 지루한 부분이 전혀 없었다. 2시간이 훅 지나가버렸다.

마지막 부분에서는 울고 있는 나를 발견할 수 있었다 ㅠㅠ

가장 인상깊었던 부분은 단연 "렌고쿠 쿄쥬로"다.

사실 나는 애니메이션을 볼때 렌고쿠 쿄쥬로 라는 인물에 대해 큰 관심을 느끼지 않았다.

그냥 염주가 저 인물이구나.. 정도?

하지만 귀멸을 칼날 극장판을 보고 나서 최애 인물이 되어버렸다.

극장판 상에서 렌고쿠 쿄쥬로의 가치관을 잘 보여주는데, 나도 내 인생 가치관에 대해 다시 한번 생각해보는 계기가 될 정도로 크게 와닿았다.

최애 인물이 되자마자 돌아가셔서 유감일 따름이다 :(

"4DX로 재관람"

몇일이 지나지 않아 CGV대전터미널에서 "4DX"로 재관람을 했다.

의자가 흔들리고, 바람이 나오고 .. 어떻게 보면 영화 자체에 집중할 수 없는 분위기를 형성할 수 있겠지만

마지막에 또 울고있는 나를 발견했다.

이 영화 자체의 대부분이 "열차 안"에서 진행되기 때문에 4DX로 보니 현장에 있는거 같은 생동감이 느껴졌다.

그리고 4DX 표현력이 좋았다.(이상한 연기가 가끔 나올때 빼고는..)

4DX로 귀멸의칼날 극장판 관람을 적극 추천드린다!!

<전체 관람 후기>

사실상 애니메이션을 안봐도 충분한 재미를 느낄 수 있지만, 캐릭터 특성이라던지 배경에 따라 받는 재미가 확 다르기 때문에 애니메이션을 보고 극장판을 관람하는것을 추천한다.

액션씬은 눈이 항상 즐거웠다 못해 황홀했으며, 적절한 교훈과 감동이 섞여있어서 맘에 들었다.

그리고 2시간의 짧은 시간동안에 "꿈"이라는 소재로 등장인물들의 특성과 가치관을 잘 표현해준거 같다.

극장 스크린에서 느껴지는 웅장한 감동이 있으니, 방역수칙을 잘 지키며 극장에서 관람하는 것을 추천한다.