소프트웨어

## 컴파일러와 인터프리터
- app은 모바일, pc 모두 사용자가 사용하는 프로그램이라 할 수 있다. 계산기, 에어컨, 키오스크, 스피커도 app이다. 
// 하지만 코딩을 하면 영어와 숫자가 섞인, 코드가 만들어질 텐데, 어떻게 이런 프로그래밍 코드가 실행할 수 있는 애플리케이션으로 바뀌는 걸까요?
어떤 소프트웨어가 이 프로그래밍 코드를 실행할 수 있는 애플리케이션으로 바꿔주기 때문인데, 컴파일러와 인터프리터가 프로그래밍 코드를 실제 동작하는 프로그램으로 바꿔 주는 겁니다.

- 프로그래밍 언어는 많지만,  컴퓨터가 이해하는 언어는 Machine code밖에 없다. 컴파일러는 프로그래밍 언어의 번역기이다. 개발자코드에서 고급언어->컴파일러->머신코드. 그리고 이 머신코드를 사용자 컴퓨터에 던져서 실행하게된다.     이미 개발자들이 개발해놔서 그냥 쓰면 된다. 다만, 단점은 빠르게 개발 불가(코드 작성->컴파일->코드실행 하기에 시간이 걸린다)
==> 컴파일 상관없이 고급언어를 실행할 수 있는 방법으로 인터프리터가 나왔다. 컴파일없이 코드를 즉시 실행한다. 개발 속도가 빨라진다. 다만, 머신코드를 사용자에게 던져서 실행속도가 빠른 컴파일러와 달리, 그냥 코드 자체를 사용자 컴퓨터에 던지기에 인터프리터가 있어야하고, 실행하는데 시간이 걸린다. + 코드가 유출될 위험성도 있다. 
// 많은 프로그래밍 언어들은 둘 중 한가지 방식을 통해 실행하도록 설계됩니다! Java는 둘 다 가능하긴 한데

// 인터프리터도 머신코드로 번역을 하게 됩니다. 컴파일러 방식은 전체 코드를 머신코드로 번역을 하게 되는 것이고,
인터프리터 방식은 필요시 소스 코드를 분석하고 수행합니다. 인터프리터가 수행시 하는 일이 머신코드로 변환하는 일입니다.

//첫 번째 컴파일러를 만들 때는 컴파일러가 없었을 텐데, 어떻게 이 컴파일러 프로그램을 번역해서 실행할 수 있었을까요? 정답은 "번역을 하지 않고 컴퓨터의 언어로 사람이 직접 작성했다.” 입니다.

출처: 코드잇

컴파일러와 인터프리터의 차이 (출처: 코드잇 )

## 운영체제 개요
- 운영체제: 애플리케이션을 도와주는 프로그램
// OS가 발전하는 목적을 한 마디로 한다면 하드웨어의 기술적 한계를 개선하기 위함에 있습니다.

# 역할
1. 입출력
- 입력과 출력 사이에 운영체제를 거친다. 키보드, 스피커 등의 다양한 하드웨어들이 애플리케이션과도 잘 연결되는 것(입력)은 운영체제가 안정적으로 연결해주기에 애플리케이션들이 하드웨어를 사용할 수 있게 된다. (출력)

2. 저장과 불러오기
- 저장의 종류
(1) 휘발성메모리(RAM), 비휘발성메모리(HDD)
(2) 빠른 저장장치, 느린 저장장치. 
(3) 수정 가능, 수정 불가(ROM, 컴퓨터 기본세팅)

-> 이를 상황, 목적에 맞게 운영체제가 결정해서 해당하는 저장장치에 저장한다.

3. 여러 프로그램 동시에 빠르게 실행하기
- 저장공간 조정(저장공간 겹치지않게), 대기줄(우선순위 부여). 멀티태스킹 관리

# 종류
- 용도에 따른 종류: 데스크톱/랩톱(윈도우, 맥 os, Linux), 모바일(안드로이드, ios 등), 서버(우분투, 리눅스, cenTOS 등), 임베디드(종류, 환경이 다양해서 운영체제가 많다. 실시간 운영체제[RTOS] 등)로 나눌 수 있다. 
- windows, android: 사용자 설정을 더 쉽게 바꿀 수 있다. but 바이러스 취약
- macOs, Ios: 보안 강하지만 환경설정 변경 제한적

=> 많은 운영체제가 UNIX 토대로 만들어졌다. 유닉스의 기준을 충족하는 다양한 운영체제.

 

서버에 파일이 저장되는 과정(출처: 코드잇 )

 

## 애플리케이션

플랫폼은 상대적인 환경. 운영체제도 소프트웨어이고, 하드웨어는 운영체제의 플랫폼이다. (출처: 코드잇 )

- 플랫폼: 프로그램이 실행되는 하드웨어, 소프트웨어 환경(상대적이다)
--> 프로그램이 제대로 실행되려면, 각 플랫폼에 맞게 프로그램을 만들어야한다.
====> 이런걸 플랫폼 의존성이라고 한다----> 앱을 만드는 개발자로서 고충. 하드웨어->운영체제->애플리케이션->사용자로 진행되기에.
문제- 플랫폼의 파편화: 플랫폼이 여러 개로 쪼개졌다는 것을 의미합니다. 같은 기능 어플리케이션을 만들어도 컴퓨터에 설치해서 실행되는 데스크톱 어플리케이션, 웹 상에서 돌아가는 웹 어플리케이션, 삼성 갤럭시에서 돌아가는 Android 어플리케이션 등등 다양한 플랫폼을 사용하게 되면서, 개발자는 각각에 호환되는 소프트웨어를 만들어야하는 것이죠.

=> 해결책은 표준화
- 크로스 플랫폼: 여러 os,Cpu 등에서 동일하게 실행할 수 있는 환경
===> 어떤 플랫폼에도 맞는 가상의 컴퓨터(어댑터라고 생각하면 된다)를 개발하여 이에 맞는 프로그램만을 개발.
ex) JVM(자바를 이용한 가상의 컴퓨터)-Java 프로그램. 프로그램을 JVM에서 실행.
ex) 브라우저(가상의컴퓨터)- 웹페이지(HTML, JS). 웹페이지 작성 후, 브라우저에서 실행. (웹 규격에 맞춰 제작)
==> 웹은 더 간편하게 크로스 플랫폼을 만들 수 있고, 이를 반응형 웹 디자인이라고 한다. 
===> 더 나아가 국제 표준화 규격이 있고, 아예 모든 걸 웹 기술로 개발하자는 말이 있다. => JS 각광

but 웹의 단점: 브라우저 호환성 문제(최신 버전 권장 + 브라우저별 차별화 등..) 브라우저가 웹 표준을 얼마나 잘 지키는가?? 를 고려해야 완벽한 크로스 플랫폼이 가능하다..

- 네이티브애플리케이션(웹을 거치지않고 기기OS에서 바로 실행한다) vs 웹 애플리케이션(브라우저에서 실행)
=> 동작방식이 다르다. 
ex) 웹애플리케이션 : OS -> 크로스플랫폼(크롬) ->네이버(길찾기)
      네이티브 애플리케이션: OS -> 플레이스토어(길찾기)

네이티브app: 기기os에 내장된 기능 활용 및 다운로드로 인터넷없이도 사용가능 but 설치, 배포(앱 마켓을 거쳐야하기에 앱 마켓 등록-업데이트 등의 과정이 필요)
웹 app: 설치, 배포 문제 x. 사용자가 웹 주소로 접속하면 실행가능. 업데이트 시 실시간 반영. // 적은 투자와 노력으로 서비스 런칭 가능(웹의 발전)

# 웹의 발전
1. single-page Application ex) 페북, gmail, 지도, 구글드라이브 등
- 다른 페이지 옮기지않아서 일반 app 처럼 느껴진다. 
2. Hybrid Web Application 
- 앱에서 자주 바꾸는 곳에 빈 공간을 두고 api를 가져와서..
3. Progressive Web Appliction(PWA): 웹과 native 앱의 장점을 합친 것
- 인터넷이 연결되지않은 오프라인에서도 동작, 홈 화면에 설치 가능, OS 기능 사용가능, 웹의 내용을 실시간 업데이트 가능 but 가장 큰 단점은 브라우저 호환성 문제일 것 같습니다. 
예시) https://app.starbucks.com/    https://www.pinterest.co.kr/