플레이스토어 병아리게임 출시!!!~~ [많은 이용 부탁드립니다!]

📝Timezone 설정

📝Certbot

📝연간 반복 수익(AARRR)

A : Acquisition (고객 유치) 100명
= 고객에게 우리 서비스를 어떻게 광고할 것인가?

A : Activation (활성화) 50명
= 고객이 우리 서비스를 다운로드 및 이용할 수 있게 할 것인가?

R : Retention (리텐션) 20명
= 고객이 우리 서비스를 지속적으로 이용하는가?

R : Revenue (수익화) 10명
= 고객이 우리 서비스의 유료 기능을 사용하는가?

R : Referral (추천) 5명
= 이용 고객들이 지인들에게 소개, 추천하는가?

A→A→R→R→R을 거친 고객은 다시 다른 지인들에게 소개시키며 지인은 AARRR을 경험하게 되며 반복 수익이 나게된다.

📝AARRR 효과적인 방안

1. AARRR을 높이는 가장 효과적인 방법 중 하나는 고객 성공에 집중하는 것
2. AARRR을 높이는 또 다른 방법은 기존 고객에게 업그레이드 및 추가 기능을 제공
3. 비즈니스 모델을 개선
4. 기존 고객을 유지하는 것도 중요하지만 신규 고객을 확보
5. 이탈한 고객은 AARRR에 상당한 영향을 미칠 수 있습니다. 이탈률을 줄이면 더 많은 고객이 구독을 갱신
   
   

📝양적완화 (QE)

양적완화는 금융시장이 정상적으로 작동하지 않을 때, 중앙은행이 시중에 돈을 직접 공급하여 금융시장을 안정시키는 정책인 것이다. 부동산으로 치면 주택시장이 과열되어 있을 때 신도시를 지어 주택시장을 안정시키는 것이라고 보면 된다.

중요한 것은 '금융시장'이 '정상적으로 작동하지 않을 때'다. 

실물경기 자체가 안좋거나, 정상적으로 작동하는 경제를 촉진시키려고 양적완화를 시행하면 바로 인플레이션 폭탄이 된다 → 외부적 이유로 공급이 받쳐주지 못하는데 통화량이 늘면 초인플레이션 발생

📝대차대조표 (Balance Sheet, B/S)

재무상태표라고 불리기도 하는 대차대조표는 회사 또는 조직의 가치를 반영하기 위해 고안된 재무제표

📝순자산

순자산이란 대차대조표의 자산에서 부채를 차감한 후의 자산을 말한다.

📝주가순자산비율 (PBR)

주가순자산비율 (PBR) = 주가 / 주당순자산

• PBR < 1
  • 0.5일시 100만원 기업을 주식으로사면 50만원으로 살 수 있다 → 저평가
• PBR = 1
  • 주가가 1주당 자산가치와 같다 즉, 100만원 기업을 주식으로사면 100만원으로 살 수 있다.
• PBR > 1
  • 1.5일시 100만원 기업을 주식으로 사면 150만원으로 살 수 있다. → 고평가

📝주당순이익 (EPS)

주당순이익 = 순자산 / 주식수

회사가 영업하지 않고 문을 닫을 때 빚을 청산한 후에 남은 돈은 주주들에게 돌아가는데 주식을 가지고 있는 사람들이 주식 한장당 얼마나 챙길 수 있는지 알려주는 것

예) 자산이 1억이고, 주식이 10만장 있다면 주당순자산은 1만원

📝QoQ (Quarter on Quarter)

QoQ는 Quarter on Quarter의 약어인데, 직전 분기 대비 증감율로 지금이 3분기라면 2분기의 실적과 비교하는 것이다

📝닛케이지수

도쿄 증권거래소의 주요 주가 지수로 산출과 발표 주체는 도쿄증권거래소가 아닌 니혼게이자이신문 (약칭 닛케이)이다

📝Google 알파벳(Alphabet)A, 알파벳(Alphabet)B, 알파벳(Alphabet) C 차이

알파벳 A (GOOGL) : 1주당 의결권 1표
알파벳 B : 1주당 의결권 10표 (비상장 주식, 창립자인 페이지, 브린 소유)
알파벳 C (GOOG) : 무의결권

구글에서 독점적인 지배구조 약화를 위해 나눈 형태이다

일반적인 투자 방향 → 장기보유시 알파벳A, 단기보유시 알파벳C 투자

🔗 참고 및 출처

https://m.blog.naver.com/syu-syu/221948677408

https://invest.kiwoom.com/inv/30271

https://blog.naver.com/how2invest/221625660185#:~:text=QoQ%EB%8A%94%20Quarter%20on%20Quarter,%EB%A1%9C%20%EC%A0%84%EC%9B%94%20%EB%8C%80%EB%B9%84%20%EC%A6%9D%EA%B0%90%EC%9C%A8%EC%9E%85%EB%8B%88%EB%8B%A4.

https://ecodemy.cafe24.com/w2-29.html
https://econowide.com/1785
https://schatz37.tistory.com/9

📝실행계획

옵티마이저가 SQL문을 가장 효율적으로 처리하기 위해 실행하는 계획을 선택하는 것을 의미한다.

📝FULL TABLE SCAN

테이블 전체 데이터를 읽어 조건에 맞는 데이터를 추출하는 방식

📝ROWID SCAN

ROWID기준으로 데이터를 추출하는 방식으로 단일행 접근시 가장 빠르다

📝INDEX SCAN

원하는 데이터 추출을 위해 인덱스를 사용하여 검색하는 방식

📝INDEX SCAN이 무조건 좋은가?

FULL TABLE SCAN이 무조건 성능에 좋지 않고 INDEX SCAN이 성능에 좋다는 것이라는 생각은 잘못 된 것이다.

데이터가 많은 테이블로부터 일부의 데이터를 추출해야하는 INDEX SCAN이 유용한 건 사실이지만 반대로 테이블에 있는 대부분의 데이터를 추출해야하면 FULL TABLE SCAN이 더 효과적일 수 있다.

📝INDEX SCAN 종류

INDEX UNIQUE SCAN

1. UNIQUE INDEX를 이용하여 필요한 데이터 블록을 접근하는 방식
2. 한건 이하의 ROWID를 반환하는 INDEX SCAN 방식으로 모든 컬럼의 조건절에 '='로 명시된 경우를 의미한다.

INDEX RANGE SCAN

1. 인덱스를 이용하여 필요한 데이터 블록을 접근하는 방식 중 가장 일반적인 형태
2. 한건 이상의 필요한 데이터가 포함된 일정 범위의 인덱스 블록을 오름차순으로 접근하는 방식
3. 동일 INDEX KEY 값에 대해서는 ROWID 기준으로 오름차순 정렬
4. INDEX UNIQUE SCAN을 제외한 모든 INDEX SCAN에 사용, 대소비교(<.>)가 하나라도 들어간 경우 예) menu_price > 2000
5. 와일드 카드 문자(%)가 조건 값 뒤에 존재하는 경우 예) like 'abc%'

INDEX RANGE SCAN DESCENDING

1. INDEX RANGE SCAN과 기본적인 접근 방식은 동일
2. 오름차순이 아닌 내림차순으로 인덱스 블록을 접근하는 방식
3. INDEX RANGE SCAN을 수행함과 동시에 ORDER BY DESC절을 만족하는 경우

INDEX SKIP SCAN

1. 결합 인덱스의 선행 컬럼을 건너뛰는 형태로 인덱스 블록에 순차적으로 접근
2. 선두 칼럼의 고유 값의 개수가 적고 후행 칼럼의 고유 값이 많을 때 효과적입니다 예) 부서A, B, C가 있고 급여가 500만원 ~ 700만원인 사람을 추려내야할 때 인덱스를 (부서, 급여)로 만들어서 A부서에서 500만원 ~ 700만원까지 [인덱스라서 정렬된 상태] 찾은 후 그 앞이나 뒤는 안 찾고 B부서로 넘어가는 방식

INDEX FULL SCAN

1. 인덱스 리프 블록 전체를 SCAN하는 방식
2. 단일 블록 순차 접근으로 병렬 처리는 불가능하나 인덱스 키순 정렬이 보장된다.
3. 모든 데이터를 가져오는데 조건절은 없이 정렬이 있는 경우에 해당한다 예) SELECT * FROM MEMBER ORDER BY MEMBER_ID

INDEX FAST FULL SCAN

1. 인덱스 리프 블록 전체를 SCAN하는 방식
2. 병렬 처리가 가능해 빠르나 인덱스 키 순으로 정렬은 보장 불가능
3. INDEX FAST FULL SCAN은 TABLE FULL SCAN의 INDEX VERSION이라고 생각하면 좋다.
4. HINT를 이용해 유도해야하는 걸로 알고 있음

📝옵티마이저가 FULL TABLE SCAN을 선택하게되는 이유

1. 조건절에서 비교한 컬럼에 인덱스가 없는 경우
2. 인덱스는 있으나 데이터가 테이블의 많은 양을 차지해 FULL TABLE SCAN의 비용이 INDEX SCAN보다 적다고 판단하는 경우
3. 최적한 인덱스는 있으나 테이블 데이터 자체가 적어 FULL TABLE SCAN 비용이 INDEX SCAN보다 적다고 판단하는 경우

📝실행 계획 테이블 (PLAN_TABLE)

ORACLE에서 실행 계획을 테이블에 저장하게 되는데 해당 테이블 이름은 PLAN_TABLE이다.

EXPLAIN PLAN -- EXPLAIN PLAN 선언부
SET STATMENT_ID = 'EP_TEST' -- SQL에 임의 ID 부여
FOR
SELECT E.empno, E.ename, D.deptname
FROM emp E, dept D
WHERE E.deptno=D.deptno;

해당 SQL은 SQL의 실행 계획을 저장하는 것일 뿐 실제로 SQL이 실행되는 것이 아니다.

이거는 옵션에 따라 직접 실행시키면서 SQL 실행 계획을 저장할 수도 있다.

PLAN_TABLE에서 DBMS_XPLAN 패키지를 이용해 조회가 가능하다

실행 계획 순서는 위에서 아래로 진행되며 가장 들여쓰기가 많이 된 곳에서 부터 시작되며 실행 순서는 위에서 아래로 진행된다. 같은 수준에서 위에서 아래로 실행된 게 그 이후에 없으면 상위로 올라가며 반복된다.

해당 실행 계획의 순서는 5 → 3 → 4 → 2 → 1 → 0 이다

📝실행계획 요소 (PLAN_TABLE)

그외 더 다양한 정보가 있습니다.

📝SQL TRACE

실행 계획은 물론 여러 세션에서 수행한 SQL 통계 정보 수행 시간, 결과 등을 TRACE로 기록하여 파일 형태로 저장하는 방법이다. 이걸 이용해 필요한 부분의 SQL문의 실행 정보를 수집할 수도 있다.

🔗 참고 및 출처

https://harris91.vercel.app/query-plan
https://myjamong.tistory.com/237

발췌 : 실전 사례로 살펴보는 SQL 튜닝 비법

📝SQL 튜닝

최소한의 CPU I/O 메모리를 사용해 최대한 빠른 시간내 원하는 데이터 작업을 수행시키는 것
아무리 쿼리의 성능을 튜닝해도 근본적인 스키마 구조가 문제라면 밑빠진 독에 물 붓기이기 때문에 이런 경우 아예 근본적인 스키마 구조부터 뜯어고쳐야할 수 있다.
데이터 모델링을 할 때는 일반적으로 사용자의 이용 빈도(자주 사용하는 화면)를 고려하며 설계 하는 게 좋다

📝옵티마이저

DBMS의 두뇌라고 표현할 수 있다. SQL이 들어오면 문법 에러 및SQL문을 처리하는 최적의 방법을 도출해서 실행하게 한다.

📝SQL 실행 순서

1. 문법 오류 검사
2. 실행한 적이 있는 SQL문인지 메모리(SHARED POOL)에서 체크 후 실행
   1. 실행한 적 있으면 기존 방식으로 실행(SOFT PARSING) → 
   2. 실행한 적 없으면 처리 방식에 대한 실행 계획 수립(HARD PARSING) 그 이후 SHARED POOL에 실행 계획 저장

📝옵티마이저 종류

규칙 기반 옵티마이저

• 특정 규칙을 기반으로 실행 계획 수립하고 우선순위가 높은 걸 우선시한다.

1. ROWID에 의한 단일행 실행
2. 클러스터 조인에 의한 단일행 실행
3. AHSH CLUSTER KEY에 의한 단일행 실행
4. UNIQUE KEY 또는 PRIMARY KEY에 의한 단일행 실행
5. 클러스터 조인
6. HASH CLUSTER KEY
7. INDEXED CLUSTER KEY
8. 결합 인덱스
9. 단일 컬럼 인덱스
10. 인덱스에 의한 컬럼 BOUNDED RANGE
11. 인덱스에 의한 컬럼의 UNBOUNDED RANGE
12. SORT MERGE JOIN
13. 인덱스로 구성된 컬럼의 MAX 또는 MIN 처리
14. 인덱스로 구성된 컬럼의 ORDER BY
15. FULL TABLE SCAN

예를 들어 아래와 같은 쿼리문이 존재할 때 emp_no가 PRIMARY KEY 설정(인덱스)가 안 되어있는 경우 15번의 FULL TABLE SCAN 방식으로 실행될 것이고 있는 경우는 4번의 방식으로 실행되게 된다.

SELET E.e_name
FROM emp E
WHERE E.emp_no = '12345';

우선 순위가 정해져있기 때문에 미리 예측을 할 수 있다는 장점이 있다. 그렇기 때문에 SQL을 통제하는 것이 가능하다

하지만 이러한 규칙이 항상 유리하지 않다
성별인 남자이고 입사일이 2013년 1월 1일 ~ 2013년 1월 3일인 사람을 검색하는 SQL을 작성하고자할 때 아래 SQL과 같이 작성하는 경우 성별인 남자인 직원을 걸러내는 인덱스를 사용하는 것보다 3일 사이에 입사한 직원을 걸러내는게 더 효율적이다. 
→ 남자인 사람에서 입사일을 걸러내는 것보다 입사일에서 남자인 사람을 걸러내는게 불필요한 데이터를 많이 읽게 되는 걸 줄일 수 있다

SELECT E.e_name
FROM emp E
WHERE E.gender = '남자'
AND E.hiredate BETWEEN '20130101' AND '20130103'

위와 같은 쿼리를 좀더 효율적으로 하기 위해 인덱스를 안 타게끔 아래와 같이 조정이 가능하긴 하다.

SELECT E.e_name
FROM emp E
WHERE E.gender || '' = '남자'
AND E.hiredate BETWEEN '20130101' AND '20130103'

또한 규칙기반 옵티마이저에서는 이러한 단점들이 존재한다.

1. 힌트를 사용할 수 없다
2. HASH JOIN을 사용 할 수 없다
3. 거의 사용하지 않는 추세이며 ORACLE의 경우 10g 이후 공식적으로 지원하지 않는다.
   
   

비용  기반 옵티마이저

• 최소 비용으로 처리할 수 있는 실행 계획 수립, 가장 많이 쓰이는 형식의 옵티마이저
• 하나의 SQL을 받으면 최대 2,000개의 실행 계획을 만들고 가장 적은 비용이 드는 실행계획을 사용자에게 제시한다.
  
  
  

📝동작방식 (SQL → Parsing → Query Transformer → Estimator → Plan Generator)

Query Transformer

PARSING 과정을 거친 SQL은 PARSING 트리 형태로 변형되어 Query Transformer는 넘겨 받은 SQL을 보고 같은 결과를 도출하되 좀 더 나은 실행 계획을 갖는 SQL로 변형이 가능한지 판단해 변환 작업을 수행
예를 들면 복잡한 서브쿼리나 뷰를 사용한 SQL을 일반적인 조인 형태의 SQL로 변환해 실행 계획을 도출하기 좋은 상태로 만든다.

Estimator

Query Transformer를 통해 변환 작업을 마치고난 SQL은 Estimator로 넘겨지게 되는데 이때 수행하는데 드는 총 비용을 계산한다.

Plan Generator

Estimator를 통해 계산된 값들을 토대로 후보군 실행계획 도출 Row Source Generator를 통해 출력이 가능한 코드 형태로 바꾼다.

📝FIRST_ROWS_n

비용기반 옵티마이저는 CHOOSE, FIRST_ROWS와 같은 모드도 존재하지만 현재는 사용하지 않고 DBMS에서도 FIRST_ROWS_n을 권장하며 실행 결과를 출력하는데 걸리는 응답 속도를 최적화 하는게 목표이다.

📝ALL_ROWS

SQL 실행 결과 전체를 빠르게 처리하는데 최적화된 실행 계획을 세우는 것입니다. ORACLE의 경우 10g 이후에 이값이 기본적으로 설정되어있다.

📝옵티마이저 이용 통계정보

옵티마이저의 경우 통계 정보를 따라 자동적으로 최적의 실행계획을 세운다 이용하는 통계정보는 아래와 같다

시스템 운영중 DBMS 전체의 옵티마이저 모드를 변경하는 작업은 가급적 하지 않는 것이 좋다.

📝옵티마이저 한계

잘못된 비용 계산의 한계

복잡한 쿼리문때문에 정확하지 않은 통계자료 발생

동시성 배제한 비용 계산의 한계

비용 예측시 한 개의 SQL만 실행된다는 전제로 진행하게 되는데 실제 운영 환경에서 같은 블록을 접근하는 등 상황이 발생해 대기상태가 될 수 있다.

컬럼 타입에 대한 비용 에측의 한계

날짜 유형의 데이터를 날짜 데이터 타입이 아닌 문자 데이터 타입을 컬럼으로 사용할 경우 비용 계산 방식이 달라져 예측이 어려워질 수 있다
예를 들면 날짜 데이터를 DATE타입으로 선언하면 특정 월에는 1부터 최대 31까지의 날짜만 존재하지만 YYYYMMDD 형식을 갖는 VARCHAR 타입의 데이터를 선언하면
이는 연속된 문자열이기 때문에 31일 이후의 날짜가 존재할 수 있다고 판단한다. 그 결과 예측되는 최종비용 또한 정확성이 떨어지게 된다.

발췌 : 실전 사례로 살펴보는 SQL 튜닝 비법

📝Single Block I/O

DB에서 데이터들은 일반적으로 HDD에 저장되는데 레코드를 한번의 I/O Call에 한줄(하나의 데이터 블록)씩 읽어오는 걸 의미한다.
인덱스를 이용한 실행계획일 때 Single Block I/O 방식으로 이용하게 된다.
그 이유는 인덱스는 블록간 논리적 순서는 물리적으로 데이터파일에 저장된 순서가 달라 그 블록들이 논리적 순서로는 한참 뒤쪽에 위치할 수 있습니다. 
소량데이터를 읽을때 주로 사용하는 방식입니다.

📝Multi Block I/O

DB에서 데이터들은 일반적으로 HDD에 저장되는데 I/O Call 시점에 인접한 블록들을 같이 읽어 메모리에 적재하는 것을 의미합니다.
테이블 전체를 스캔할때 이 방식을 사용하며 테이블이 클수록 Multiblock I/O 단위도 크면 좋고 많은 데이터 블록을 읽을때 주로 사용합니다.
하지만 OS가 일반적으로 허용하는 I/O 단위가 1MB이면 1MB만큼만 읽습니다.

db file sequential read : Single Block I/O방식으로 I/O요청할때 발생
db file scattered read : Multiblock I/O 방식으로 I/O요청할때 발생

대량의 데이터를 Multiblock I/O방식으로 읽을 때 Single Block I/O보다 성능상 유리한 것은 I/O Call 발생횟수를 줄여주기 때문입니다.

📝바인드 변수 

고정적인 쿼리문이 있을 뿐더러 동적으로 쿼리문이 들어가는 경우도 존재합니다.
이렇게 ?와 같이 동적으로 변하는 부분의 변수는 바인드 변수라고 합니다.
예) select * from tab where id = ? 

해당 변수의 목적은 Hard Parse 를 줄이기에 있습니다.
바인드 변수를 사용할 경우 변수의 값이 달라져도 같은 문장으로 인식하기 때문에 불필요한 Hard Parse를 줄일 수 있습니다.

SQL 문의 경우 Hard parsing 이 많아지면 자원소모가 많아지며 실행이 느려지게 됩니다.

자바로 설명하겠습니다.

Connection con = null; 
String query = "select * from shop where id = " + id; 

Statement stmt = con.createStatement(stmt); 
ResultSet rs = stmt.executeQuery(); 

이런식으로 코딩하게 될 경우 아래와 같이 쿼리문이 들어가게 됩니다.

select * from shop where id = 1; 
select * from shop where id = 2; 
select * from shop where id = 3; 

다른 문장으로 처리가 되기 때문에 Hard Parse를 하게 되어 느려지게 됩니다.

하지만 아래와 같이 바인드변수를 이용할 경우 모두 같은 실행 계획을 세우게 되고 Soft Parse가 되기 때문에 실행계획을 안 세워서 빠르게 결과를 받을 수 있습니다.
select * from shop where id = ? 

아래와 같은 방식으로 처리할 경우 바인드 변수 처리가 되지 않습니다.
String query = "select * from shop where id = " + id; 
PreparedStatement pstmt = con.prepareStatement(query); 

아래와 같은 형식으로 처리해야 바인드변수 처리가 됩니다. 고로 바인드 변수는 무조건 이용하되 라이브러리가 지원해주는 형식으로 사용하는 방법을 찾아서 써야합니다.
String query = "select * from shop where id = ?" 
PreparedStatement pstmt = con.prepareStatement(query); 
pstmt.setInt(1, id); 

Parse해 실행계획을 처리할 경우 CPU 점유율 차이가 20%나 차이가 난다고 합니다.
또한 바인드 변수 사용할 때 해당 바인드 변수를 이용하는 조건절따위에 인덱스가 걸려있어도 형변환으로 인해 인덱스를 안 탈 수도 있기 때문에 주의해야한다.

📝SQL 실행 순서

SQL을 입력 받을시 제일 먼저 실행하려고 문법 오류를 검사한다.
그 후 SQL 이전 실행한 적 있는지 메모리(SHARED POOL)를 검사한다 있다면 기존에 실행한 방식으로 실행한다 이것을 SOFT PARSING이라고 한다.
하지만 그와 같은 기록이 없다면 SQL을 어떤 방식으로 처리할 것인지 실행 계획을 세운다. 이것을 HARD PARSING이라고 한다. 그 이후에 SHARED POOL에 실행 게획을 저장한다.

📝SQL 동작방식 

Soft Parse : Parsing → syntax → semantic → Execution  

Hard Parse : Parsing → syntax → semantic → Query Transformer → Estimator → Plan Generator → Execution  

Query Transformer

PARSING 과정을 거친 SQL은 PARSING 트리 형태로 변형되어 Query Transformer는 넘겨 받은 SQL을 보고 같은 결과를 도출하되 좀 더 나은 실행 계획을 갖는 SQL로 변형이 가능한지 판단해 변환 작업을 수행
예를 들면 복잡한 서브쿼리나 뷰를 사용한 SQL을 일반적인 조인 형태의 SQL로 변환해 실행 계획을 도출하기 좋은 상태로 만든다.

Estimator

Query Transformer를 통해 변환 작업을 마치고난 SQL은 Estimator로 넘겨지게 되는데 이때 수행하는데 드는 총 비용을 계산한다.

Plan Generator

Estimator를 통해 계산된 값들을 토대로 후보군 실행계획 도출 Row Source Generator를 통해 출력이 가능한 코드 형태로 바꾼다.

📝실행시간 (Execution time) vs 패치시간 (Fetch time)

실행 시간은 SQL문을 Parse해 실행 계획을 세워 실행하는데까지 걸리는 시간이다.

패치 시간은 실행해서 나온 결과를 전송하는 데 걸리는 시간을 측정한다 (Binary로 전달하기 때문에 네트워크 연결에 의존한다)

🔗 참고 및 출처

https://blogingming.tistory.com/entry/%EC%8B%A4%ED%96%89%EC%8B%9C%EA%B0%84-Execution-time-vs-%ED%8C%A8%EC%B9%98%EC%8B%9C%EA%B0%84-Fetch-time
 https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=gh2501&logNo=115281737

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=gh2501&logNo=115281737
https://sksstar.tistory.com/89
http://wiki.gurubee.net/display/STUDY/03.+Single+Block+vs+Multiblock+IO 
https://argolee.tistory.com/60

📝코스피 KOSPI(Korea composite stock price index)

우리나라의 상장된 주식의 총 가격을 표시한 것으로 대략적인 한국의 성장세를 볼 수 있습니다.
코스피 대표기업으로 삼성전자, 네이버, 현대자동차 등 대기업들이 포진되어 있고 그만큼 코스피 상장은 요건이 까다롭습니다. 즉, 코스피는 한국을 이끄는 대표적 기업의 주가 지수들을 종합적으로 보여주는 것이라고 생각하시면 됩니다.

📝코스닥 KOSDAQ(Korea securities dealers automated quotation)

코스닥은 코스피보다 상장요건이 덜하며 코스피 상장 기업 외(벤처, 유망주기업)가 들어가있습니다.

📝나스닥

나스닥은 미국 대표적인 증권거래소로 기술산업들이 많이 포진되어있고 다양한 세계적인 기업, 벤처기업들이 포진되어있습니다. 약 7000여개의 기업이 포함되어있으며 나스닥을 통해 미국 시장 흐름을 파악하기 용이합니다.

📝다우지수

미국 다우존스에서 미국 증권거래소에 상장된 종목중 전세계 안정적 주식 30개를 표본 산출한 지수 나스닥이 대기업들이 많다면 다우지수는 안정적 기업들의 대표 지수입니다.

📝S&P 500

S&P 500은 미국 신용평가사 S&P Global이 미국에 상장된 시가총액 상위 500개 기업의 주식들을 모아 지수로 묶어 주기적으로 수정하고 발표한다 즉, 미국 시장 흐름을 파악하기 용이합니다.

📝ETF (Exchange Traded Fund)

테마(카테고리)별로 자산을 모아 쉽게 투자할 수 있게 하는 겁니다.
예를 들면 전기차가 유망하다고하면 그 관련 기업들을 찾는게 아닌 하나의 상품으로 묶어서 분할 투자하게끔 하는 상품이죠

📝PG

PG사 존재 이유 온라인 쇼핑몰의 경우 실물이 존재하지 않기 때문에 PG사가 심사를 거쳐서 대신해서 담보를 해준다.

📝VAN

외국에서는 카드 결제할 때 해당 카드가 이용가능한 카드인지 확인을 해야하는데 VAN사는 모든 카드사로부터 결제 가능에 대한 권한이 있어서 어떤 카드를 사용하든 상관없게 중계해주는 역할을 한다.

📝온라인쇼핑몰

온라인 쇼핑몰의 경우 실물이 존재하지 않아 PG사가 대표 가맹점 역할을 해준다.

온라인쇼핑몰에서 10,000원의 옷을 구매할 때 PG사의 결제 시스템을 이용해 승인 요청을 하고 VAN사에 요청해 모든 카드사로부터의 결제 시스템을 이용할 수 있게 허가를 받는다.  

신용카드사에서는 수수료를 가져가는데 2%라고 가정했을 때 200원을 가져갑니다. 

신용카드사는 VAN사에 받은 수수료(200원)에 수수료를 또 가져갑니다. 25%라고 할 때 50원을 VAN사에 지급하게 됩니다.

9,800원이 바로 온라인쇼핑몰에 바로 가는게 아닌 대표가맹점 인 PG사로 먼저 갑니다.

PG사에서는 정산일을 정해 온라인쇼핑몰에 결제 대금을 추후 지급하게되고 수수료를 챙기게 됩니다.

📝O2O (Online To Offline)

온라인으로 결제하고 서비스만 오프라인으로 받음 

예) 배달 시스템, 온라인 매장

📝O4O (Online For Offline)

온라인에서 성공한 기업들이 자기의 브랜드 가치를 높이기 위해서(고객과의 접점) 사업을 오프라인으로 확장

예) 무신사의 무신사 스테이션 (무신사는 온라인 서비스이지만 무신사 스테이션이라는 지점을 만들어(오프라인) 운영

🔗 참고 및 출처

https://www.youtube.com/watch?v=BKLZa05hll0

📝Hot Reload

소스 코드 수정 후 반영때까지 톰캣이 재기동하면서 다시 클래스 파일 생성하면서 시간이 10초 15초정도 소요 특히

XML 수정같은 경우는 (Mapper) 톰캣 자체를 아예 재기동 필요(톰캣의 변화 감지는 Java파일 및 JSP 따위만 판단)

위와 같은 불편한 점을 해소시키기 위한 기술이 Hot Reload란 기술

📝사용 가능한 방법

1. IntelliJ 사용 - 기본 지원 (유료)
2. 스프링부트 사용 (설정 추가하면 지원) [추천]
3. Spring Loadded Jar 사용해 Tomcat 설정 추가 (JDK 8버전에서 동작) [11버전에서는 돌아가지 않는 거 같다]
4. JRebel 사용 - (유료) 

📝적용 방법

1. IntelliJ 사용

유료이기 때문에 구매해서 사용

2. 스프링 부트 사용

요즘 대세이고 신규인데 부트로 개발 안 하는 곳이 거의 없다시피하기 때문에 스프링 부트 3.0이상 버전을 사용하는게 좋다. 또 3.0 사용하려면 JDK 17이상은 써야함

하기 블로그 참조 

https://blog.egstep.com/spring-boot/2017/12/10/springboot-reload/

3. Spring Loadded Jar

하기 블로그 참조

https://guiyomi.tistory.com/67

4. JRebel

유료이기 때문에 구매해서 사용 (사용시 하기 블로그 참고) [14일 Trieal 존재]

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=sue227&logNo=221195660703 

🔗 참고 및 출처

https://blog.egstep.com/spring-boot/2017/12/10/springboot-reload/

https://guiyomi.tistory.com/67

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=sue227&logNo=221195660703 

📝Server Side Template Engine

페이지 렌더링 전에 필요한 데이터를 모두 받아서 정의된 Template에 넣어 Html을 그려 클라이언트에 전달해준다 → 서버에서 처리함

📝Client Side Template Engine

페이지가 모두 렌더링 된 상태에서 필요한 부분만 다시 정의하기 위해서 프론트단에서 HTTP 통신해 데이터를 다시 받아와 그려주는 역할을 한다 → 클라이언트에서 요청 후 다시 그려준다

📝Template Engine (템플릿엔진)

HTML만 가지고서 데이터를 받아와 화면에 보여주고 하는 그런 행위는 불가능하다
정해진 템플릿 양식이 있으면 데이터를 받아와 화면에 보여줄 HTML을 재구성해서 보여주는 소프트웨어를 의미한다.

📝템플릿 엔진(Template Engine)의 필요성

• 많은 코드를 줄일 수 있다
• 대부분의 Template Engine은 기존의 HTML에 비해서 간단한 문법을 사용한다.
• 재사용성이 높다
• 웹페이지 혹은 웹앱을 만들 때 똑같은 디자인의 페이지에 보이는 데이터만 바뀌는 경우가 굉장히 많다.
• 유지보수에 용이하다
• 하나의 Template을 만들어 여러 페이지를 렌더링하는 작업에는 또 다른 이점이 있다.
  
  

📝템플릿엔진 종류

레이아웃 템플릿 엔진

페이지 마다 include를 두는게 아닌 최상위 레이아웃이 있어서 해당 레이아웃에 Include해서 사용하게 도와준다
페이지 별 Include가 있을 시 헤더 또는 푸터 등의 경로 변경이 있거나 전체적인 레이아웃 구조가 변경될 때 모든 페이지를 다 수정해야하는 불상사를 최상위 레이아웃만 수정해서 간단하게 처리 가능 (모듈화)
예) Apache Tiles

텍스트 템플릿 엔진

템플릿 양식에 적절한 데이터를 넣어 결과를 문서에 출력합니다. 
예) JSP, Thymeleaf

🔗 참고 및 출처

https://gmlwjd9405.github.io/2018/12/21/template-engine.html%EF%BB%BF