mellowg

[Tibero] 암호화 알고리즘 변경 MD5 to SHA256

mellowg — Sat, 6 Jun 2026 18:16:34 +0900

Tibero 암호화 알고리즘 변경 MD5 to SHA256

Tibero 6 버전 암호화 알고리즘 기본값 : MD5

Tibero 7 버전 암호화 알고리즘 기본값 : SHA256

Tibero6 버전에서 암호화 알고리즘을 MD5 에서 SHA256 으로 변경하는 태스크는 다음과 같다.

전제조건

209586c - SHA256 비밀번호 암호화 기능 안정화 및 패치

위 패치가 적용되어있는 바이너리여야 한다.

위 패치가 적용되어 있어야 _CRYPTO_LEVEL 파라미터가 존재한다.

1. 신규 설치시

.tip 파일에 _CRYPTO_LEVEL 파라미터 설정 필요

_CRYPTO_LEVEL=0 (MD5)

_CRYPTO_LEVEL=1 (SHA256)

버전에 따라서 _CRYPTO_LEVEL 이거나 CRYPTO_LEVEL 로 상이할 수 있다.

2. 바이너리 패치시

1) MD5 -> SHA256stem.sql 수행

_CRYPTO_LEVEL=1

DB 재기동

$ tbsql sys/tibero

sys외 모든 유저 패스워드 재생성
SQL> alter user tibero identified by tmax

2) 바이너리 변경 및 패치 태스크 모두 수행

SQL> alter system set _CRYPTO_LEVEL=1;
SQL> DROP TABLE _SHADOW_PASSWORD;
SQL> @$TB_HOME/scrypt/crypto_system.sql

# 모든 유저 패스워드 변경
SQL> alter user sysbackup identified by tibero
SQL> alter user syscat identified by tibero
SQL> alter user sys identified by tibero 
SQL> alter user outln identified by tibero
.
.
.

암호화 알고리즘 변경 후 패스워드 변경을 진행해주지 않으면 해당 계정으로 DB 접속이 불가능하다.

참고

패스워드 암호화 방식(MD5<->SHA256) 변경 패치 적용 시 패치테스크

문서유형ㅣ기술정보 분야ㅣ패치/업그레이드 적용제품버전ㅣTibero 6 문서번호ㅣTPATI003 개요Tibero6의 경우 계정의 패스워드 암호화 방식이 기본적으로 MD5이며, 고객사의 요청에 따라 MD5에서 SHA25

support.tibero.com

[Tibero] 티베로 분석을 위한 명령어 모음

mellowg — Sun, 17 May 2026 09:59:42 +0900

■ 쿼리 메모리 덤프

ALTER SYSTEM DUMP MEMLOG <SID>;
ALTER SYSTEM DUMP PPC 'SQLID' CHILD_NUMBER:

- 5SP1 버전 에서 0번 SID를 메모리 덤프 뜨게 되면 DB Down

- 0번 SID : MGWP

■ 특정 세션 callstack 수집

ALTER SYSTEM DUMP CALLSTACK <SID>;

■ 특정 오류번호의 Callstack Dump On/Off

ALTER SYSTEM DUMP CALLSTACK ON ERROR <ERROR NUM> ON;

ALTER SYSTEM DUMP CALLSTACK ON ERROR <ERROR NUM> OFF;

■ 바이너리 로그 텍스트 추출

$ tbev -ts <eventlog_파일명>
$ tbiv -ts <ilog_파일명>

■ SQL TRACE 기능 실행 후 dump 파일 생성

SQL> ALTER SESSION SET SQL_TRACE=Y;
SQL> <튜닝 필요한 쿼리 수행>
SQL> ALTER SESSION SET SQL_TRACE=N;
=> 이후 SQL_TRACE_DEST 경로에서 <파일명>.TRC 대상으로 SQL_TRACE_DUMP 파일 생성

$ TBPROF <파일명>.TRC <SQL_TRACE_파일명>.TXT SYS=NO AGGREGATE=YES

■ Autotrace 실행

SQL> SET AUTOT TRACE EXP
SQL> SET AUTOT TRACE EXP STAT

- AUTOTRACE는 쿼리 실행 시 실행 계획(Execution Plan)과 SQL 수행 통계(Statistics)를 자동으로 수집하여 결과를 제공하는 기능으로, 쿼리 실행 시 실행 계획과 SQL 수행 통계를 자동으로 수집하여 확인할 수 있으며, 쿼리 튜닝 및 성능 진단 시 유용하게 활용 가능

관련 파라미터

파라미터명	설명
gather_sql_plan_stat	SQL 수행 시 실행계획(Plan)과 관련된 통계정보를 수집 여부 설정 (Y:수집, N:미수집)

관련 View 정보

시스템뷰	설명
v$sql_plan	SQL 문장의 실행 계획 정보
v$sysstat	시스템 통계
v$sql_plan_statistics	SQL 문장의 수행 통계 정보

[Tibero] Tibero 7.2.3 release note

mellowg — Wed, 13 May 2026 20:58:06 +0900

Tibero 7.2.3 release note

※ 나한테 필요할 것 같은 내용만 발췌

1) Auto Purge 기능 추가

Recyclebin 기능 활성화 시 자동으로 공간 확보 해주는 기능이 추가 되었다.

Tablespace 여유 공간 부족 / QUOTA Max 도달 시 Recyclbin Object 자동 Purge

2) SQL Profile 기능 추가

특정 SQL plan의 형태를 고정하고자 할 때 SQL Profile 사용한다.

DBMS_SQLTUNE
DBA_SQL_PROFILES
DBMSHSXP_SQL_PROFILE_ATTR

참고 : Tibero tbPSM

3) Cluster Manager 확장 기능

Prosync를 사용하는 경우 CM에 group / agent 관련 리소스 등록 가능하도록 추가 되었다.

Prosync의 Failover 관련한 기능이다.

4) 권한 추가

CREATE JOB
CREATE ANY JOB (Job/Scheduler 통제 목적)

5) TPR 파티셔닝 기능 추가

기존 TPR 관련 테이블은 통테이블로 구성되어 있었으나, Tibero 7.2.3 부터는 Partition으로 관리하여 공간 회수 및 조회 성능이 개선되었다.

6) 지원 OS 추가

RedHat Enterprise Linux 9.5 / Rocky Linux 9.5 / Oracle Linux 9.5
Ubuntu 22.04

출처 : https://support.tibero.com/hc/ko/articles/14254207222671-Tibero-7-2-3-Release-Notes-2025-03

Tibero 7.2.3 Release Notes [2025.03]

신규 기능DBMS 엔진SQL 표준 기능 내용 현행화SQL-2008 / SQL-2011 / SQL-2016 관련 지원 내용 현행화참고: “SQL 참조 안내서” 1.2.3 Tibero SQL 표준 지원 현황 참고Auto Purge 기능 추가 RECYCLEBIN 기능 활성화 시

support.tibero.com

[Tibero] Tibero 7.2.4 release note

mellowg — Wed, 13 May 2026 19:12:43 +0900

Tibero 7.2.4 release note

※ 내가 참고할 만한 내용만 발췌

1) IF NOT EXISTS / IF EXISTS 문법 추가

CREATE TABLE IF NOT EXISTS TEST_TABLE (COL1 NUMBER, ...);

DROP TABLE IF EXISTS TEST_TABLE;

2) TAC Memory OOM 자동 정상화

이전에는 Shared Pool 메모리 부족 상황이 특정 시간 (default 300초, _MMGR_OOM_SHUTDOWN_TIMEOUT) 이상 지속될 경우 클러스터 매니저 (CM)이 Tibero Instance를 Down 시키기만 했지만, 7.2.4 부터는 _MMGR_REBOOT_ON_OOM 파라미터를 Y로 설정하면 CM이 Tibero Instance를 자동으로 재기동해준다.

3) 지원 OS 추가

RHEL 9.6 / Rocky 9.6 / Orcale Linux 9.6
SUSE Linux Enterprise Server 15 SP6
Windows Server 2025

4) DBMS 설치/패치 시 사용하는 쉘 변경

기존에는 system.sh 하나로 설치 및 패치 모두 사용하였지만, 7.2.4 에서는 설치 시 system_install.sh, 패치 시 system_patch.sh 쉘을 사용하여 불필요한 에러 로그 방지하도록 변경되었다.

5) 설치 시 기본 유지 및 샘플 스미카 변경

TIBERO 권한 변경(DBA 제거)
TIBERO1 제거
샘플 스키마 : LIBRARY / FITNESS 추가 (옵션)
- 생성 / 삭제 스크립트 : $TB_HOME/scripts/sample_user 존재

6) 변경된 Parameter

Parameter name	before	after	description
CPU_COUNT	0	TB_MAX(1, get_ncpu())	인스턴스에 허용되는 CPU 개수를 지정
TB_CM_DISC_TIMEOUT	300	600	TAC 클러스터 Disconnect timeout 변경
TB_LOG_SWITCH_INTERVAL	900	600	Redo Log Switch 주기 단축

7) 추가된 Parameter

Parameter name	default value	description
~~TB_CM_AUTO_RESTART_TIME~~	~~300~~	~~Shared Pool OOM 상태 지속 시 TAC 자동 재시작 임계 시간(초)~~
TB_LOG_ARCHIVE_PARALLEL	4	로그 아카이브 병렬 처리 스레드 수

8) ADAPTIVE_CURSOR_SHARING 기능 관련 파라미터 제거

7.2.4 에서는 ADAPTIVE_CURSOR_SHARING 파라미터가 제거 되었기 때문에, Tibero6 > Tibero7.2.4 patch시 해당 파라미터 제거 필요

출처: https://support.tibero.com/hc/ko/articles/14253979567887-Tibero-7-2-4-Release-Notes-2025-08

Tibero 7.2.4 Release Notes [2025.08]

신규 기능DBMS 엔진TCC (Tibero Columnar Compression) Direct Path Load/Insert 시 Column 기반 압축 기능 제공 ARCHIVE HIGH / ARCHIVE LOW / QUERY HIGH / QUERY LOW 압축 레벨 제공 참고: "Tibero 관리자 안내서" 4.2.5 참고DP(Direct Pat

support.tibero.com

[Tibero] outfile, callstack 로그 파일 차이점

mellowg — Wed, 13 May 2026 18:22:32 +0900

● Outfile

서버 내부에서 sys.log에 정상적으로 기록하기 어려운 긴급 상황이 발생했을 때, stdout으로 직접 출력되는 로그

Internal Error나 SIGSEVG 같은 비정상 종료 또는 긴급 상황에서 생성된다.

outfile은 정상 로그 경로를 타지 못한 비상 출력 성격이 강하다.

● Callstack

Tibero 내부에서 critical error 가 발생했을 때, 원인 분석을 위해 에러가 발생한 함수의 호출 경로를 남기는 로그이다.

주로 Internal Error, SIGSEVG 와 같은 서버 내부 심각한 오류 상황에서 생성된다.

어디서 어떤 흐름으로 오류가 발생했는지를 확인하는 용도이다.

두 로그 모두 심각한 장애 상황에서 발생하지만, outfile은 에러 출력, callstack은 에러 분석 성격이 강하다.

[보험대리점] 보험대리점 시험 3일 컷

mellowg — Mon, 4 May 2026 00:34:09 +0900

보험대리점 시험 신청

https://www.in.or.kr/main/certification/agent/announce.do

www.in.or.kr

보험대리점 교육

https://www.in.or.kr/main/classroom/cyber/studying.do

보험금융 전문인 양성기관 보험연수원에 오신것을 환영합니다. Global Leader Korea Insurance Institute[WSV

※ 개인정보 확인을 통해, 아이디와 비밀번호를 찾을 수 있습니다.

www.in.or.kr

김토리쌤 강의만 듣고 합격!

7월엔 변액보험 들어야지

https://www.youtube.com/@kimtory_ssam

김토리쌤

명강사유투바 김토리쌤 이야기 보험 시험전문 강의(생명보험,손해보험,변액보험,퇴직연금) 멤버십 가입비용 딱 2,990원 강의자료는 채널멤버십(토리야 산책가자 등급) 회원님들 한정 제공해드리

www.youtube.com

[Oracle] 오라클 성능 고도화 (3)

mellowg — Wed, 18 Mar 2026 22:34:23 +0900

01 | 오라클 아키텍처

03 ) 버퍼 Lock

(1) 버퍼 Lock ?

DB 버퍼 캐시 내에서 버퍼 블록을 찾고, 래치를 빠르게 해제하지 않으면 cache buffers chains 래치에 여러 개의 해시 체인이 달렸으므로 래치에 대한 경합 발생 가능성이 증가하게 된다.

캐시된 버퍼 블록을 읽거나 변경하려는 프로세스는 먼저 버퍼 헤더로부터 버퍼 Lock(buffer pin) 을 흭득해야 한다.

버퍼 Lock (buffer pin)을 흭득햇다면 래치를 곧바로 해제해야한다.

버퍼 내용을 읽기만 할 때는 Share 모드, 변경할 때는 Exclusive 모드로 Lock을 설정한다.

액세스를 직렬화하기 위한 메커니즘이므로 당연히 Exclusive 모드 Lock은 한 시점에 하나의 프로세스만 얻을 수 있다. Select 문이더라도 Block Cleanout이 필요할 때는 버퍼 내용을 변경하는 작업이므로 Exclusive 모드 Lock을 요구한다.

Block Cleanout → 성능 최적화를 위해 사용

- 트랜잭션 완료정보를 지연해서 처리하는 최적화기법

- 트랜잭션 완료여부를 블록 내에 표시(clean)하지 않고 남겨뒀다가, 이후 누군가 그 블록을 읽을 때 처리(cleanout)하는 메커니즘

- 성능을 위해서 트랜잭션이 커밋되었을때 모든 블록을 즉시 수정하지 않는다. 대신 해당 트랜잭션이 어떤 블록을 변경했는지, undo, redo 로그에만 저장한다.

- 블록내의 트랜잭션 메타 데이터(Interested Transaction List)는 "나중에" 정리한다. 나중에 정리하는 것이 Block Cleanout이다.

Why 성능 최적화?

▶️ 트랜잭션이 커밋될때마다 모든 관련 블록을 다시 찾아가서 "커밋됨"을 표시하면 디스크 I/O 비용과 latch 경합이 매우 커진다.

ex) 트랜잭션 A가 1000개의 데이터 블록을 변경 → COMMIT → 1000개의 데이터 블록을 모두 찾아가 "COMMIT됨 표시" ▶️ COST 가 큼

트랜잭션 A가 1000개의 데이터 블록을 변경 (ITL 기록; 이 트랜잭션이 수정 중 표시) + UNDO 생성 → COMMIT(redo 기록, SCN 부여) → 트랜잭션 B가 트랜잭션 A가 변경한 데이터블록 접근(ITL확인) → UNDO에 연결된 트랜잭션 상태를 확인한 후 Block Cleanout 처리

버퍼 Lock 대기모드

- 찾아낸 버퍼 캐시상의 대상 버퍼가 타 프로세스에 의해 exclusive lock이 흭득된 상태인 경우 버퍼 헤더에 있는 버퍼 Lock 대기자 목록에 등록 후 대기 (해당 요청을 했던 프로세스에 할당된 cache buffers chain latch는 이 시정에 해지된다.)

- 이렇게 동작해야 또 다른 프로세스가 해당 버퍼 캐시에 요청을 했을때 latch wait이 발생하지 않고 버퍼 lock 대기자 목록에 자신의 정보를 기록할 수 있다.

- buffer busy waits 대기 이벤트 발생

- 목적한 읽기/쓰기 작업을 완료하면 버퍼 헤더에서 버퍼 Lock 을 해제해야 하는데, 이때도 버퍼 헤더를 액세스하려는 다른 프로세스와 충돌이 생길 수 있으므로 해당 버퍼가 속한 체인 래치를 다시 한번 흭득한다. ▶ 버퍼 Lock 해제의 경우 버퍼헤더에서 해당 버퍼 블록에 대한 상태를 수정하는 작업임(pin count 수정), 다른 프로세스가 버퍼 체인 스캔을 하며 버퍼 헤더에 접근하게 되면 충돌이 발생할 수 있다. 그렇기 때문에 Lock 해지할 때에도 Buffer Chains Latch를 재흭득해야 함.

⭐️ 버퍼 블록을 읽을때 대부분 두번의 래치 흭득을 요구한다. (버퍼 헤더 검색 후 pin / Un-pin)

일부 작업의 경우 래치를 흭득한 상태로 버퍼 블록을 읽기 때문에 래치 흭득이 한번만 일어난다. (v$sysstat 뷰에서 consistent gets - examination 통계항목으로 측정)

버퍼 Lock을 해제하고 Latch Lock을 해제해야 비로소 버퍼 블록 읽기가 완료된다.

(2) 버퍼 핸들

버퍼 Lock을 설정하는 것은 자신이 현재 그 버퍼를 사용중임을 표시해 두는 것으로서, 그 버퍼 헤더에 Pin을 걸었다고도 표현한다.

읽기 작업 : 여러 프로세스가 Pin 설정 가능

변경 작업 : 하나의 프로세스만 Pin 설정 가능

버퍼 헤더에 Pin을 설정하려고 사용하는 오브젝트를 버퍼 핸들(Buffer Handle)이라고 부르며, 버퍼 핸들을 얻어 버퍼 헤더에 있는 소유자 목록(Holder Lost)에 연결시키는 방식으로 Pin을 설정한다.

버퍼 핸들도 공유된 리소스이므로 버퍼 핸들을 얻으려면 또 다른 래치가 필요해지는데, 바로 cache buffer handles 래치이다.

버퍼를 Pin하는 작업이 많을수록 cache buffer handles 래치가 경합 지점이 될것이므로, 오라클은 각 프로세스마다 _db_handles_cached 개수만큼의 버퍼 핸들을 미리 할당해 주며, 기본값은 5이다.

각 세션은 이를 캐싱하고 있다가 버퍼를 Pin할때마다 사용하며, 그 이상의 버퍼 핸들이 필요할 때만 cache buffer handles 래치를 얻고 추가로 버퍼 핸들을 할당받는다.

시스템 전체 버퍼 핸들 개수 (_db_handles) = processes * _db_handles_cached

(3) 버퍼 Lock의 필요성

단일 레코드 갱신시의 버퍼 Lock 필요성
- 단일 레코드를 갱신 → 사용자 데이터 변경 시 DML Lock 을 통해서 정합성을 유지
- DML Lock 만으로는 정합성 유지에는 불충분하다. → 하나의 레코드를 갱신하더라도 블록 단위로 I/O를 수행하기 때문에 , 블록 안에 저장된 10개의 레코드를 읽는 짧은 순간 동안 다른 프로세스에 의해 변경이 발생하면 잘못된 결과를 얻게 된다.
- 버퍼 Lock 필요
Row-Level Lock에서의 버퍼 Lock 필요성
- row-level lock 설정 자체도 레코드의 속성을 변경한다.
- 두 프로세스가 동시에 row-level lock을 설정할 경우 문제가 발생한다. ( 대상 로우가 다르더라도 )
- 블록 SCN 변경 / ITL 슬롯 변경도 블록 헤더 내용을 변경하는 작업으로 동시 액세스가 발생하면 Lost Update 문제가 생겨 블록 자체의 정합성이 깨질 수 있다.
- 블록 진입 자체를 직렬화 해야한다.

(4) 버퍼 Pinning

"버퍼 Pinning" 버퍼를 읽고 나서 버퍼 Pin을 즉각 해제하지 않고 데이터베이스 Call이 진행되는 동안 유지하는 기능

같은 블록을 반복적으로 읽을 때 버퍼 Pinning을 통해 래치 흭득 과정을 생략하면 논리적인 블록 읽기(Logical Reads) 횟수를 획기적으로 줄일 수 있다.

같은 블록을 재방문할 가능성이 큰 몇몇 작업들을 수행할 때만 사용한다.

v$sysstat, v$sesstat, v$mystat 등을 조회해 보면, 래치 흭득 과정을 통해 블록을 액세스 할 때는 session logical reads 항목이 증가하고, 래치 흭득 과정 없이 버퍼 Pinning 을 통해 블록을 곧바로 액세스 할 때는 buffer is pinned count 항목의 수치가 증가한다.

버퍼 pinning은 하나의 데이터베이스 Call(Parse call, execute call, fetch call) 내에서만 유효하다. 즉 Call이 끝나고 사용자에게 결과를 반환하고 나면 Pin 은 해제되어야 한다.

전통적으로 버퍼 Pinning이 적용되던 지점은 인덱스를 스캔하면서 테이블을 액세스할 때의 인덱스 리프 블록이다.

Index Range Scan하면서 인덱스와 테이블 블록을 교차 방문할 때 블록 I/O를 보면, 테이블 블록에 대한 I/O만 증가하는 이유가 여기있다. → 클러스터링 팩터가 좋은 인덱스의 경우 효과는 극대화 된다. (= 인덱스 레코드가 가리키는 테이블 rowid 정렬 순서가 인덱스 키 값 정렬 순서와 거의 일치한다면)

이외에도 DML 수행시 Undo 레코드를 기록하는 Undo 블록도 Pinning 적용

[Oralce] 오라클 성능 최적화 (2)

mellowg — Wed, 18 Mar 2026 21:21:18 +0900

01 | 오라클 아키텍처

02 ) DB 버퍼 캐시

빠른 데이터 입출력을 위하 SGA 공유 메모리를 이용한다.

사용자가 입력한 데이터를 데이터파일에 저장하고 이를 다시 읽는 과정에서 거쳐 가는 캐시 영역이 SGA 구성 요소 중 하나인 DB 버퍼 캐시이다.

(1) 블록 단위 I/O

오라클에서 I/O는 블록(block)단위로 이루어진다.

1. DB buffer Cache → Datafile

2. Datafile → DB buffer Cache

두 과정 모두 블록 단위로 I/O 가 이루어진다.

인덱스를 경유한 테이블 액세스 시에는 한 번에 한 블록씩(single block read) 읽어들이지만, Full Scan 시에는 성능 향상을 위해 한 번에 여러 개 블록(multi block)을 읽어들인다.

DBWR 프로세스는 버퍼 캐시로부터 Dirty block을 주기적으로 데이터파일에 기록하는 작업을 수행하느데, 이때도 성능 향상을 위해서 한 번에 여러 블록을 처리한다.

▶ DBWR은 주기적으로 DB Buffer Cache에서 변경된 블록을 데이터파일에 기록 (동기화 과정)

블록 단위로 읽는다는 것은 하나의 레코드에서 하나의 컬럼만 읽고자 하는 경우에도, 레코드가 속한 블록 전체를 읽는다는 것이다.

SQL의 성능을 좌우하는 가장 중요한 성능지표는 블록 개수이며, 옵티마이저의 판단에 가장 영향을 미치는 것도 액세스해야 할 블록 개수이다. 옵티마이저가 인덱스를 이용해 테이블을 액세스할지 아니면 Full Table Scan 할지를 결졍하는 데 있어 가장 중요한 판단 기준은, 읽어야 할 레코드 수가 아니라 블록 개수이다.

(2) 버퍼 캐시 구조

DB Buffer Cache 의 가장 직관적인 그림은 바둑판 모양이다.

SGA 내에서 가장 많이 사용되는 자료구조는 해시 테이블(Hash Table)이다.

DB Buffer Cache 도 Hash Table 구조로 관리된다.

Hash Key : 데이터 블록 주소(DBA; Data Block Address)

Hash Function : DBA 입력한 해쉬 값 리턴

Hash Bucket : 해시 함수에 의해 리턴 받은 해시 값을 저장

Hash Chain : 동일한 해시 값에 의한 Buffer Header 를 Linked List 로 연력한 구조 (실제 데이터 값은 버퍼 헤더에 있는 포인터에 의해 버퍼 블록을 찾아감)

즉, 사용자가 찾고자하는 데이터 블록 주소를 해시값으로 변환해서 해당 해시 버킷에서 체인을 따라 스캔하여 데이터를 찾고, 찾고자한 데이터블록이 있는 경우 그대로 읽고, 없는 경우 디스크에서 읽어 해시 체인에 연결한 후 읽는다.

이렇게 체인에 연결된 데이터는 다른 사용자들도 나중에 읽을 수 있도록 캐싱하는 것이다.

▶ Buffer Header만 Hash Chain에 연결되며, 실제 데이터 값이 필요해지면 버퍼 헤더에 있는 포인터를 이용해 버퍼 블록을 찾아가는 구조이다.

(3) 캐시 버퍼 체인

각 해시 체인은 래치(Latch)에 의해서 보호된다. DB 버퍼 캐시는 공유 메모리 영역인 SGA에 존재하므로 여러 프로세스에 의한 동시 액세스 요청이 일어날 가능성이 높다.

같은 리소스에 대한 액세스를 반드시 직렬화해야 하고, 이를 위해 구현된 일종의 Lock 매커니즘이 Latch이다.

래치를 흭득한 프로세스만이 그 래치에 의해 보호되는 자료구조로의 진입이 허용된다.

두 개 이상의 프로세스가 같은 해시 체인으로 진입해 새로운 버퍼 블록을 연결하고 해제하는 작업을 동시에 진행한다면 문제가 발생할 수 있다. 이를 방지하기 위해서 사용하는 것이 cach buffers chains 래치이다.

cache buffers cahins : 여러개의 해시 체인을 동시에 관리

Oracle 9i 부터 Shared Mode와 Exclusive Mode로 관리

Shared Mode : 해시 체인을 스캔하여 필요한 블록 검색

Exclusive Mode : 체인 구조 변경(체인 추가, 삭제) 혹은 Buffer Pin 설정

해시 버킷 : 해시 체인 = 1 : 1 을 목표 ▶ 해시 체인을 찾고난 후 추가적인 스캔에 의한 비용 최소화

✔︎ Latch 는 데이터 자체를 보호하는 것이 아닌, SGA에 공유되어 있는 자료구조를 보호하는 것이며, 그 중 cache buffers chains 래치는 버퍼 캐시에 연결된 체인구조를 보호하는 것이다.

(4) 캐시 버퍼 LRU 체인

버퍼 헤더는 해시 체인뿐만 아니라 LRU체인에 의해서도 연결되어 있다.

버퍼 캐시는 한번 읽은 데이터 블록을 캐싱해두지만, 유한한 자원이 아니기 때문에 읽은 모든 데이터를 캐싱할 수 없다.

버퍼 캐시가 사용도가 높은 데이터 블록들 위주로 구성될 수 있도록 LRU(Least Recently Used) 알고리즘을 사용해 관리한다.

모든 버퍼 블록 헤더를 LRU체인에 연결해 사용빈도 순으로 위치를 옮겨가다가, Free 버퍼가 필요해질 때마다 액세스 빈도가 낮은 데이터 블록들을 우선하여 알아냄으로써 자주 액세스 되는 블록들이 캐시에 더 오래 남아 있도록 관리한다.

LRU알고리즘

- 가장 최근에 사용한 버퍼 캐시를 MRU(Most Recently Used) End에 위치

- Free Buffer가 필요할 때 LRU(Least Recently Used) End에 위치한 버퍼 캐시부터 밀어냄

LRU List

- Dirty List : 캐시 내에서 변경되었지만, 아직 디스크에 기록되지 않은 Dirty Buffer Block 관리, LRUW(LRU Write) 리스트라고도 한다.

- LRU List : 아직 Dirty 리스트로 옮겨지지 않은 나머지 버퍼 블록들을 관리 ( Pinned Buffer, Free Buffer, Dirty List에 옮겨 가지 않은 Dirty Buffer)

- 모든 버퍼 블록은 둘 중 하나에 반듯 속해 있다.

- LRU List 를 보호하기 위한 래치 : cache buffers lru chain

⭐️ Buffer 상태

1. Free Buffer : Instance 기동 후 한번도 사용 하지 않은 버퍼 / 데이터를 사용하였으나 변경되지 않은 버퍼 / 변경 후 데이터 파일과 동기화된 버퍼

2. Dirty Buffer : 캐시된 후 데이터의 변경이 발생 되었으나 데이터파일에 아직 기록되지 않은 버퍼

3. Pinned Buffer : 읽기 혹은 변경을 위해 현재 액세스 되고 있는 버퍼

[Oracle] 오라클 성능 고도화 (1)

mellowg — Wed, 18 Mar 2026 20:47:13 +0900

01 | 오라클 아키텍처

01 ) 기본 아키텍처

오라클 성능 고도화 그림 1-3

오라클은 데이터베이스와 이를 액세스하는 프로세스 사이에 SGA(System Global Area)라고 하는 메모리 캐시 영역을 두고 있다.

인스턴스 : 메모리 + 프로세스

데이터베이스 : 데이터파일 + redo log file + control file

디스크를 경유하는 I/O는 물리적으로 액세스 암(Arm)이 움직이면서 헤드를 통해 데이터를 읽고 쓴다.

메모리를 통한 I/O는 전기적 신호를 통해 이루어지기 때문에 디스크를 경유하는 경우와 비교할 수 없을 정도로 속도가 빠르다.

디스크 I/O 속도 < 메모리 I/O 속도 (캐시)

기억장치 - 액세스 암

데이터베이스는 많은 사용자들이 동시에 데이터에 액세스하기 때문에 데이터를 보호하기 위해 Lock은 물론 SGA상에 위치한 데이터 구조에 대한 액세스를 직렬화하기 위한 Lock 매커니즘(=래치, Latch)도 필요하다.

트랜잭션의 직렬성 : 여러 트랜잭션이 동시에 병행 수행되더라도 각 트랜잭션이 하나씩 차례대로 수행되는 것과 같은 일관성을 보장하는 수행특성

인스턴스를 구성하는 프로세스에는 서버 프로세스와 백그라운드 프로세스가 존재한다.

서버 프로세스 : 사용자가 던진 명령을 처리

백그라운드 프로세스 : 서버 프로세스가 스스로 처리하지 못하는 작업 (버퍼 캐시로 블록 적재 등)을 처리

오라클에 접속하면 각 클라이언트를 위한 전용 서버 프로세스가 뜨고, 사용자에게 필요한 서비스를 제공한다. SQL을 파싱하고 필요하면 최적화를 수행하며, 커서를 열어 SQL을 실행하면서 블록을 정렬해서 클라이언트가 요청한 결과집합을 만들어 네트워크를 통해 전송하는 일련의 작업들을 모두 서버 프로세스가 처리해 준다.

오라클에서 세션이 수립되는 과정은 다음과 같다.

1. 사용자가 오라클 접속 연결 요청

2. 사용자로부터 연결 요청을 받은 리스너가 서버 프로세스를 생성

3. 서버 프로세스는 PGA를 할당 받음

4. 서버 프로세스 생성 완료에 대한 패킷을 사용자에게 전송

5. 사용자 해당 서버 프로세스로 연결하여 DB접속

▶ 리스너에 연결요청을 하는 순산 하나의 프로세스를 띄우고 (fork) PGA메모리를 할당한다.

프로세스 하나를 띄우고 PGA를 할당하는 과정은 cost가매우 큰 작업으로 SQL문을 실행할 때마다 연결요청을 받아 프로세스를 할당받아 실행하는 것은 성능적은 측면에서 좋지 않다. 그래서 반드시 Connection Pool 기능이 필요하다.

Connection Pool ▶ 한번 커넥션을 맺으면 작업을 완료하더라도 이를 해제하지 않고 애플리케이션 서버에 Pooling 하고 있다가 세션을 반복 재사용을 한다.

[Tibero] Tibero Backup & Recovery [1] Backup & Recovery 개요

mellowg — Sat, 13 Sep 2025 20:59:35 +0900

Tibero Backup & Recovery

Backup & Recovery 개요

백업과 복구는 여러 가지 유형의 장애(시스템 장애, 미디어 장애, 사용자 실수 등)로부터 데이터베이스를 보호하는 핵심적인 기능이다.
- 보호 대상 장애 유형
  1. 하드웨어 장애 : 디스크 손상, 서버 다운 등
  2. 소프트웨어 장애 : DBMS오류 등
  3. 사용자 오류 : 실수로 인한 데이터 삭제, 잘못된 UPDATE/DELETE 실행 등
  4. 재해 상황 : 화재, 정전, 천재지변 같은 예기치 못한 사건
백업의 역할
- 데이터 복원 지점 확보 : 특정 시점의 데이터 상태를 보관
- 서비스 연속성 보장 : 장애 발생 시 신속한 복구 가능
- 데이터 손실 최소화 : 장애 발생 이후 손실되는 데이터를 최소화
복구의 역할
- 장애 직전 시점으로 데이터 회복 : Redo/Undo 로그를 이용해 트랜잭션 적용/취소
- 업무 중단 시간 단축 : 백업 및 복구 전략에 따라 다운타임 최소화
- 데이터 무결설 보장 : 복구 과정에서 트랜잭션의 일관성과 무결성을 유지
관리자는 시스템 장애 시 발생할 손실을 최소화하고 복구 가능한 상태로 데이터베이스를 운용해야 한다.
- 최소한 한 달에 한번 데이터베이스 전체 백업
- 하루에 한번씩 Export 백업 권장
데이터베이스 관리자는 백업에 대한 정책을 수립하고, 꼭 필요한 데이터를 최소한의 양으로 백업
- 백업은 DBA의 주요 역할 중 하나로, 가장 주의가 필요하다.
"RECOVERY에 실패한 DBA는 용서할 수 있지만, BACKUP을 실패한 DBA는 용서할 수 없다."
백업이 정상적으로 수행되었는지 주기적인 검증 권장

▶️ 백업은 예방(사전 대비)이고, 복구는 대응(사후 처리)의 개념이라고 할 수 있다.

여러가지 유형의 장애

#1 명령문의 실패

명령문의 실패 원인에는 다음과 같은 것들이 있다.

테이블의 제약 조건에 위배되는 데이터 INSERT
권한의 부족
테이블 생성 시 또는 데이터 변경 시 테이블스페이스의 공간이 부족한 경우

이러한 장애는 데이터 유실과는 관련이 없는 에러이다.

#2 사용자 프로세스의 실패

비정상적인 종료로 인한 사용자 프로세스의 실패가 대부분
Tibero 의 monitor process가 비정상적인 종료를 감지하고 수행중인 트랜잭션 등은 롤백시킨다.

#3 사용자로 인한 장애

장애 발생 상황
- DROP TABLE
- TRUNCATE TABLE
- DELETE FROM & COMMIT
- 잘못된 UPDATE & COMMIT
해결 방안
- 사용자에 대한 교육 실시
- 백업에서 복구
- Export 받은 파일에서 테이블을 Import
- Time-based 불완전 복구

#4 Instance Fail

정전, CPU나 Memory Fault, Background Process의 비정상적인 종류가 대부분이다.
복구
- 특별한 복구 작업이 필요하지 않음
- tbboot을 통해 DBMS를 기동하면 자동으로 복구됨
- 로그 등을 참고하여 원인 분석

#5 Media Fail

데이터파일이 저장된 하드 디스크의 장애
데이터 파일의 삭제
정해진 복구 전략에 따라 복구 절차가 필요
Media Fail은 반드시 발생할 수 밖에 없다. 하드디스크에도 수명이 존재하기 때문에 24시간 계속 모터가 돌아가다 보면 언젠가 문제가 발생하여 데이터 유실이 발생할 수 있다.

Backup & Recovery 전략 수립

업무적인 요구 사항
- MTBF(Mean Time Between Failure)를 증가시키고, MTTR(Mean Time To Recover)를 감소
- MTBF: 평균 고장 간격
  - 시스템이나 장비가 고장 없이 정상적으로 동작하는 평균 시간
  - 얼마나 신뢰성이 높은지를 나타낸다.
  - MTBF = 총 가동 시간 / 고장 횟수
    - ex) 서버가 1년동안 (8760시간) 4번 다운되었다면 -> MTBF = 8760 / 4 = 2190 시간 → 약 3개월에 한 번꼴로 고장 발생
- MTTR : 평균 복구 시간
  - 장애가 발생했을 때 복구하여 정상 기동까지 걸리는 평균 시간
  - 얼마나 빨리 가용성을 회복할 수 있는지를 나타냄
  - MTTR = 총 복구 시간 / 고장 횟수
    - ex) 장애 4번 동안 복구에 총 20시간이 걸렸다면 → MTTR = 20 / 4 = 5시간 → 한 번 장애 발생 시 평균 5시간 다운타임
- MTBF vs MTTR
  - MTBF → 얼마나 자주 고장이 나는가 (신뢰성 지표)
  - MTTR → 고장이 났을 때 얼마나 빨리 고치는가 (유지보수성 지표)
  - 두 지표는 시스템 가용성(Availability) 계산에 활용된다.
  - Availability = MTBF / MTBF + MTTR
운영 요구 사항
- 24*365 운영, 백업 테스트 및 검증, 데이터베이스의 변경, 백업 데이터의 보관 장소 등
기술적 고려 사항
- 하드웨어, 소프트웨어의 구성, 백업 주기 결정을 위한 트랜잭션 주기, 데이터의 양 등
경영진 합의
- 경영진에서 기대하는 시스템의 가용성, 백업 및 복구 절차에 대한 이해, 백업을 위한 리소스 확보 등

백업 - 파일 변경이 잘 되지 않는 시간대에 백업 전략을 수립해야 한다.

Tibero 동작 방식의 이해

Transaction Durability

Committed Transaction MUST Survive failures (Recoverable)
데이터 입력/수정 작업은 COMMIT을 수행하면 변경된 내용이 확정되어 Durability를 확보하게 된다.
데이터는 Durability가 확보가 안되어 있으면 유실될 수 있다.
데이터가 어떻게 하면 날아가지 안혹 안전하게 보관할 수 있을까?
- 메모리에만 반영되면 장애 시 데이터가 유실 될 수 있기 때문에 영속 저장 장치에 반드시 기록해야 한다. 이때 사용되는 것이 Redo Log(로그 기록)이다.
Commit이 되는 시점에 데이터 변경이력을 파일에 기록함으로써 Durability를 확보한다.

Logging

Redo Log Buffer : TSM에 redo 데이터를 저장하기 위한 영역 → 데이터베이스의 모든 변경이력을 메모리에 저장
Redo Log File : Recovery를 위해 가장 중요한 파일 → 메모리에 저장된 변경 이력을 사라지지 않도록 파일로 저장
Archive : archive log mode 시 redo logfile을 별도의 위치에 backup

⭐️ Redo 저장 대상 범위

1) Physical Logging (물리적 로깅)

데이터 변경이 일어날 때마다 해당 Block 전체를 Redo Log에 남긴다.

변경 작업이 발생할 때마다 Block Size 만큼의 로그가 남아 많은 양 유지가 필요하다.

실제 데이터 블록의 변경된 내용(변경 전/후 이미지나 REDO 정보)을 로그에 기록

장점 : Recovery시 단순히 블록에 그대로 반영하면 되기 때문에 복구가 빠르고 간단하다는 장점이 있다.

단점 : 로그 사이즈가 크다.

2) Logical Logging (논리적 로깅)

UPDATE, DELETE 같은 OPERATION 을 LOG에 남기는 방법으로, 여러 Physical Block들에 대한 수정을 하더라도 OPERATION만 기록되어 Logging 양이 적다.

반드시 순서대로 Change Apply (Recovery때 Log Apply 어려움)

▶️ 논리적 로깅에는, '어느 블록(Block) 몇 번째 Row Slot이 바뀌었다.' 같은 물리적 위치 정보가 들어있지 않고, '이 연산 그대로 다시 실행하라' 는 의미마 남는다. Logical Log는 Opertaion만 기록되어 있기 때문에, 장애가 발생시 DBMS SQL을 모두 순차적으로 실행해야 한다.

장점 : 로그 양이 적다( Operation 하나로 여러 블록 변경을 커버할 수 있다. )

단점 : 복구 시 반드시 순서대로 재적용해야 하며, 인덱스/트리 구조가 변하면 복잡해진다. 또한, 동시에 다른 트랜잭션이 섞여 있으면 복구가 어렵다.

3) Physiological Logging

Physical Logging과 Logical Logging의 장점을 합친 형태

Block의 Physical Change를 기록하는 Change Vector 들로 구성된 REDO RECORD

Change Vector는 Atomic Block Change로, Redo Record는 Atomic Database Change

블록에 대해서는 Physical 하게, 블록 내부 변경 내역은 Logical 하게 기록

Redo Log는 항상 특정 Block을 지정하며, 그 Block 안에서 어떤 Row/Slot/Column을 어떻게 바꿨는지는 논리적 연산으로 기록한다.

Change Vector / Redo Record

Change Vector

Redo Log의 최소 단위
하나의 Atomic Block Change(블록 내에서 더 쪼갤 수 없는 단일 변경)
예 : Block #100의 Row Slot 3 → SAL 값을 800 →900으로 바꿈

Redo Record

하나 이상의 Change Vector를 모아 놓은 것
Atomic Database Change (트랜잭션의 한 DB변경 단위)
예 : UPDATE문 하나가 여러 블록 (Row/Index 블록 등)에 영향을 줄 수 있는데,
- Data Block 변경 Change Vector
- Index Block 변경 Change Vector
- Undo Block 변경 Change Vector
- → 이들을 합친 것이 하나의 Redo Record

※ 티베로는 Physiological Logging 방식으로 동작한다.
데이터는 커밋할 때 Durability를 확보한다. 이것과 관련있는 것이 Redo Log - Redo Log가 기록될 때는 변경 이력만 기록하는 Logical, Block 전체를 기록하는 Physical Logging 이 있다.
기본적으로 Physiological Logging을 하며, 특정 상황에서 Physical Logging을 한다.
특정상황 예시 ) Begin Backup ~ End Backup 사이 시점에서 대상 테이블스페이스의 특정 데이터 블록을 변경하는 경우 Physical Logging 방식으로 로깅한다.

Redo 저장 시 발생

Page fix rule

데이터 블록을 수정하기 전에 반드시 블록에 대한 LOCK을 설정하고, 실제 데이터 버퍼 (Data Buffer)를 수정하기 전에 Redo Record를 먼저 생성한다는 규칙이다.

Redo Log는 복구를 위한 최소 단위이기 때문에, 블록이 변경되면 그 변경 이력이 Redo에 반드시 남아야 Durability를 보장할 수 있다.

✅ Redo Record를 먼저 생성하지 않고 데이터 블록을 수정하게 되면, 장애가 발생했을 때 Redo에 기록이 남아있지 않아 복구가 불가능 할 수 있기 때문에 데이터 블록 수정 전에 Redo Record를 생성하는 것이다.

WAL(Write Ahread Logging)

DB의 핵심 규칙 중 하나이다.

데이터 블록이 변경되기 전에 Redo Record가 먼저 Log Buffer에 기록되어야 한다.

예시 :

사용자가 UPDATE 실행 → DB Buffer에 변경 예정

하지만 DBWR이 Dirty Buffer를 디스크에 Write하기 전에, 해당 변경 Redo가 Log Buffer → Log File에 먼저 기록된다.

이유 : 장애가 발생해도 Log에 기록된 변경 사항으로 복구할 수 있도록 하기 위함이다. 데이터 블록을 디스크에 반영하기 전에, 반드시 그 변경 이력을 먼저 로그(Redo)에 기록해야 하낟.

데이터베이스에서 트랜잭션이 UPDATE/INSERT/DELTE 같은 작업을 하면, 먼저 메모리(Buffer Cache)의 블록이 수정된다. 나중에 DBWR이 Dirty Block을 디스크(Datafile)에 Write한다. 만약 메모리에만 반영된 상태에서 DB가 다운되게 되면, 데이터파일에는 반영이 되어 있지 않았기 때문에 데이터가 유실되게 된다. 따라서 장애 복구를 위해 Redo Log(변경이력)을 먼저 기록해 둬야 한다. DB가 재기동되면, Redo Log를 읽어서 Datafile에 적용(Redo Apply)하면 복구가 가능하다.

Redo Log도 Memory에만 기록되어 있으면 안되고, Redo Log File로 디스크에 기록되어 있어야 한다. Commit을 하게 되면 Redo Log Buffer의 내용이 Redo Log File로 저장된다.

Log force at commit

Commit 발생 시 Log Buffer의 Redo entry를 모두 Log file에 Write

Commit 된 데이터의 보장

Online log switch

Online Log 중 다음의 조건을 만족하는 Log file 로 Switching

Database (Controlfile, Redolog file, Datafile) 동기화 방식

1. TSN

Database의 version 또는 commit version
Data Concurrency Control, Redo Ordering, Recovery 등에 사용
Transaction이 commit 될 때 TSN이 generate 된다.

2. Checkpoint

주기적으로 또는 사용자의 요청에 따라 메모리에 있는 모든 변경된(dirty) block을 디스크에 쓰는 작업
복구에 필요한 logfile의 양을 줄인다.
Checkpoint 발생 상황
- 모든 로그 스위치 발생시
- 인스턴스가 NORMAL, POST_TX, IMMEDIATE 옵션으로 종료
- 사용자 요청에 따라 수동으로 발생 (ALTER SYSTEM CEHCKPOINT;)
ALTER TABLESPACE [BEGIN BACKUP | END BACKUP];
Checkpoint 발생 시, DBWR가 작동하기 전 먼저 LGWR 이 현재 log buffer의 내용을 online log file에 write하여 해당 dirty buffer 에 mark 가 되면, 이 정보를 DBWR이 받아서 모든 marked dirty buffer를 disk에 기록
Checkpoint는 Checkpoint TSN 이전에 발생한 Online log file내의 모든 변경 사항이 Disk 에 저장되었음을 의미

변경이 필요한 블록이 buffer cache에 그대로 있다가 dirty block들을 모아서 한번에 데이터파일에 작성한다. => checkpoint

이렇게 한번에 데이터파일에 작성하는 것이 효율이 더 좋기 때문이다. 데이터 블록을 데이터파일에 계속 즉시즉시 변경이 있을때마다 쓰게 된다면 변경때마다 Disk I/O가 발생하여 효율적이지 못하기 때문이다.

Backup 개요

시스템 장애 발생시 복원을 하거나, 시스템 작동을 유지하기 위한 절차 또는 기법

관리자는 시스템 장애 시 발생할 손실을 최소화하고 복구 가능한 상태로 데이터베이스를 운용해야 한다.

최소 한달에 한 번 데이터베이스 전체 백업(Full Backup)
하루에 한번씩 Export 백업 권장

데이터베이스 관리자는 백업에 대한 정책을 수립하고 꼭 필요한 데이터를 최소한의 양으로 백업

Backup 종류

논리적 백업 ➡️ 나중에 복구할 때 쉽고 빠르게 진행할 수 있음 / 장애 범위가 어떠냐에 따라서 백업본도 문제가 발생할 수 있음
- 데이터베이스의 논리적인 단위 백업
- Table, Index, Constraint, Sequence 등
- Export 툴로 백업
물리적 백업 ➡️ 복구할 때 다시 로컬 서버로 가져와야 해서 네트워크 속도에 따라 오래걸릴 수 있음
- 데이터베이스르르 구성하는 파일을 운영체제 레벨에서 COPY 명령으로 백업
- datafile, controlfile, archive logfile

✅ 각 하나의 백업만 하는 것이 아니라 둘 다 섞어서 백업해도 된다.

속도 : 파일을 그냥 OS 레벨에서 COPY하는 것이기 때문에 물리적 백업이 더 빠름, 논리적 백업은 파일내에서 논리적인 데이터를 뽑아내서 백업하는 것이기 때문에 물리적 백업보다 느리다.

COPY는 티베로 DBMS가 주체가 아니다. 파일을 가지고 있는 주체는 티베로지만, 복사하는 것은 백업을 작업하는 사람이 하는것이다. (보통 백업 소프트웨어를 사용) 논리적 백업 진행하는 작업자가 tbExport를 통해서 선택적으로 백업할 수 있다. (특정 테이블만 백업)

구분	설명
NOARCHIVELOG 모드에서의 백업 (Offline Backup/Cold Backup)	데이터베이스를 구성하는 전체 파일에 대해 운영을 멈춘 상태에서 백업 데이터베이스를 백업 받은 시점으로의 복구만 가능
ARCHIVELOG 모드에서의 백업 (Online Backup/Hot Backup)	운영 중에도 백업가능. Controlfile 생성문, Datafile, Archive logfile 백업 백업된 archive logfile 의 시점에 따라 datafile 백업 시점 이전으로의 복구도 가능
Consistent 백업	정상적인 Shutdown 후의 Backup
Inconsistent 백업	DB 운영 중 Backup 또는 정상종료 되지 않은 상태에서의 Backup

Backup 대상(Controlfile & Redo logfile)

Controlfile 기능

데이터베이스의 구조를 이진 파일 형태로 저장
데이터베이스를 mount할 때 반드시 필요
파일이 없으면 복구를 하거나 재생성
두 개 이상의 contolfile 로 구성 하는 것을 권장, 서로 다른 디스크에 위치

동적뷰

v$controlfile

다중화 방법

데이터베이스를 down(tbdown)
Controlfile 을 다른 위치로 copy
$TB_SID.tip 파일에서 CONTROL_FILES 파라미터에 추가
데이터베이스를 기동(tbboot)

Redo logfile

데이터베이스의 모든 변경 사항을 저장
최소한 2개 이상의 redo log group으로 구성
각 log group 은 하나 이상의 redo logfile로 구성

동적뷰

V$LOG, V$LOGFILE

다중화

Logfile의 손실을 대비하여 각각의 redo log group은 2개 이상의 logfile로 구성할 것을 권장
Log group의 logfile들은 별도의 disk로 분리
Log group의 추가
- ALTER DATABASE ADD LOGFILE GROUP 4 ('/home/tibero6/tbdata/redo41.log', '/home/tibero6/tbdata/redo42.log') SIZE 10m;
Log group에 member 추가
- ALTER DATABASE ADD LOGFILE MEMBER '/home/tibero6/tbdata/redo43.log' TO GROUP 4;

Contolfile 백업

Offline backup : O/S 의 COPY 명령을 통해 별도의 위치에 copy (티베로 종료하고 백업)
Online backup : 다음과 같이 controlfile 구문을 생성해 copy (티베로 종료하지 않고 백업)
- Online 중에는 티베로 인스턴스(프로세스)가 컨트롤 파일을 읽고, 쓰고 있기 때문에, 온라인 중 파일을 COPY하게 되면 컨트롤 파일이 변경되는 와중에 복사하게 된다. 파일의 내용이 깨진채로 COPY가 될 수 있다. 그래서 Online 백업을 하는 방법은 단순 파일 카피가 아닌 구문을 통해서 진행해야 한다.

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS [백업할 파일 경로 및 이름] REUSE NORESETLOGS;

예) 아래와 같은 Controlfile 구문이 담긴 파일 생성

CREATE CONTROLFILE REUSE DATABASE "tibero"
LOGFILE
NORESETLOGS
	GROUP 0 ('/home/tibero6/tbdata/log01.log', '/home/tibero6/tbdata/log02.log') SIZE 3M,
    GROUP 1 ('/home/tibero6/tbdata/log11.log', '/home/tibero6/tbdata/log12.log') SIZE 3M,
    GROUP 2 ('/home/tibero6/tbdata/log21.log', '/home/tibero6/tbdata/log22.log') SIZE 3M
DATAFILE
	'/home/tibero6/tbdata/system001.dtf',
    '/home/tibero6/tbdata/undo001.dtf'
NOARCHIVELOG
MAXLOGFILES 100
MAXLOGMEMBERS 8
MAXDATAFILES 256;

Backup 방식 차이 (NOARCHIVELOG VS ARCHIVELOG)

NOARCHIVELOG MODE

기본적으로 데이터베이스는 NOARCHIVELOG MODE이다.
Redo logfile은 순환하여 사용되고 log switch가 발생하면 이전의 logfile을 overwrite한다. 이전의 log가 없으므로 트랜잭션 기록 중 최근의 부분만 사용가능하다.
백업은 반드시 데이터베이스가 정상 종료된 상태에서 해야 하며 이로 인해 서비스의 중지가 발생한다.

ARCHIVELOG MODE

Redo logfile은 LOGA(LOG Archiver)에 의해 백업이 완료되기 전에는 사용 불가능하다.
Archive logfile은 media recovery에 사용가능하다.
데이터베이스가 기동 중 백업 가능하다.

ARCHIVELOG Mode의 Backup 방식

Archive log mode

Log switch시 Redo logfile을 별도의 분리된 위치로 복사하여 저장하여 운영하는 방법
Archive logfile은 recovery 시 사용되는 매우 중요한 파일
Online Backup 시 반드시 archive log mode로 운영

변경 방법

데이터베이스 down (tbdown)
데이터베이스를 mount 모드까지 기동
- $ tbboot mount
SYS 유저로 접속하여 archive log mode 로 변경
- $ tbsql sys/tibero
- SQL > ALTER DATABASE ARCHIVELOG;
데이터베이스 종료 후 재기동

Archive log mode 확인

V$DATABASE : LOG_MODE 컬럼 조회

Archive log 정보

아카이브 대상 상태 이해
V$ARCHIVE_DEST_FILES : LOG_ARCHIVE_DEST 내의 archive log files의 정보 표시
V$ARCHIVED_LOG : Archive log 정보 표시

Archive log 대상 지정($TB_SID.tip)

LOG_ARCHIVE_DEST

✅ Archive Logfile도 백업 대상임으로, Archive Logfile 저장 사이즈는 하루 발생하는 Redo log 발생량을 고려하여 설정해야 한다.

[Tibero] tbImport/tbExport utility (간략)

mellowg — Wed, 3 Sep 2025 19:27:39 +0900

tbExport

Tibero에서 제공하는 유틸리티로, tbExport를 통해 Tibero 데이터베이스에 저장된 스키마 객체의 전체 또는 일부를 추출해 고유 형식의 파일로 저장하므로 데이터베이스의 백업과 다른 머신 간의 데이터베이스를 전송할 때 유용

tbExport 유틸리티에서 하나의 스키마 객체를 추출하면 그와 연관된 스키마 객체가 자동으로 함께 추출된다. 예를 들어 하나의 테이블을 추출하면 그 테이블에 대해 생성된 인덱스와 제약조건 등이 함께 추출된다. 필요에 따라서 연관된 일부 스키마 객체가 함께 추출되지 않도록 지정할 수 있다.

tbExport 유틸리티를 실행한 결과로 생성된 파일은 운영체제 파일이다. 따라서 Tibero 데이터베이스 파일과는 달리 일반 파일과 같은 작업을 실행할 수 있다.

ex) FTP 를 이용하여 전송하거나 CD-ROM 등에 저장하여 원격지의 Tibero 데이터베이스로 옮길 수도 있다.

Export 모드

Export 모드에는 전체 데이터베이스 모드, 사용자 모드, 테이블 모드가 있다. 각 모드는 파라미터를 사용하여 지정할 수 있다.

전체 데이터베이스 모드

전체 데이터베이스 모드는 Tibero 데이터베이스 전체를 Export하기 위한 모드이다. SYS 사용자를 제외한 모든 사용자의 객체를 Export하기 위해 사용한다.

전체 데이터베이스 모드를 사용하려면 다음과 같이 FULL 파라미터를 Y로 설정한다.

FULL=Y

사용자 모드

사용자 모드는 SYS 사용자를 제외한 지정된 사용자가 소유한 모든 스키마 객체를 Export 하는 모드이다. 지정한 사용자가 소유한 객체를 Export 하기 위해 사용하며 DBA는 하나 이상의 사용자에게 이 모드를 사용할 수 있다.

사용자 모드를 사용하려면 다음과 같ㅇ USER 파라미터를 USER=userlist 형태로 설정한다.

USER=SCOTT, USER1, ...

테이블 모드

테이블 모드는 하나 이상의 테이블을 지정하여 그 테이블과 연관된 인덱스 등의 스키마 객체를 함께 Export하는 모드이다.

테이블 모드를 사용하려면 다음과 같이 TABLE 파라미터를 TABLE=tablelist 형태로 설정한다.

소유한 사용자를 반드시 명시해야 한다.

TABLE=SCOTT.EMP, USER1.TABLE1, ...

실행

$TB_HOME/client/bin 디렉터리에서 tbexport 명령어 입력

$ tbhome
$ cd client/bin

$ tbexport username=tibero password=tibero sid=tibero file=export.dat full=y
$ tbexport cfgfile=export.cfg

tbImport

tbImport 는 Tibero에서 제공하는 import 유틸리티로, 외부 파일에 저장된 스키마 객체를 Tibero 데이터베이스에 다시 저장하므로, tbExport 유틸리티와 함께 데이터베이스의 백업과 다른 머신 간의 데이터베이스 전송 등을 할 때 유용

실행

$ tbimport username=tibero password=tmax sid=tibero file=export.dat full=y
$ tbimport cfgfile=import.cfg

[Linux] 실시간 리눅스 시스템 상태 확인하기 :: top

mellowg — Wed, 6 Aug 2025 20:31:20 +0900

top

top 명령어는 리눅스에서 실시간으로 시스템 상태를 확인하는 명령어이다.

CPU 사용률, 메모리 사용량, 실행 중인 프로세스 정보 등을 실시간으로 보여준다.

top 실행하기

# top 실행하기
$ top

위 명령어를 입력하면 시스템의 상태가 실시간으로 갱신되며 화면에 출력된다. (종료하려면 q 입력)

top 실행 예시화면 (MacOS 기준)

top 실행 예시화면 (Linux 기준)

top 화면 구성 해석하기

상단 요약 정보 (시스템 전체 상태) : Linux

top - 19:53:32 up 1 min, 0 user, load average: 0.54, 0.19, 0.06

시간 : 현재 시각
up : 시스템이 켜진 시간(업타임)
users : 현재 로그인한 사용자 수
load average : CPU 작업 대기열 평균 (1분, 5분, 15분 단위) -> 1.00이면 CPU 1개가 100%로 꽉 차있다는 의미

✔︎ 즉, 현재 리눅스 서버는 19:53:32 시각이며, 시스템이 켜진 시간은 1분, 현재 로그인한 사용자 수는 0명, CPU 평균 부하는 54%, 19%, 6%이다.

상단 요약 정보 및 태스크/CPU/메모리 상태 : MacOS

Processes: 528 total, 3 running, 525 sleeping, 2705 threads 19:57:00

Load Avg: 1.99, 2.50, 2.90 CPU usage: 8.40% user, 5.64% sys, 85.95% idle SharedLibs: 688M resident, 142M data, 56M linkedit.

MemRegions: 307218 total, 3956M resident, 707M private, 2431M shared. PhysMem: 15G used (1278M wired, 0B compressor), 946M unused.

VM: 230T vsize, 4921M framework vsize, 0(0) swapins, 0(0) swapouts. Networks: packets: 37883/32M in, 24766/8573K out. Disks: 217510/4878M read, 127757/3757M written.

1) Processes: 528 total, 3 running, 525 sleeping, 2705 threads 19:57:00

528 total : 총 528개의 프로세스가 실행 중
3 running : 현재 CPU에서 실행중인 프로세스는 3개
525 sleeping : 나머지 525개는 대시 상태 (I/O 나 이벤트 대기 등)
2705 threads : 모든 프로세스의 스레드를 합친 수
19:57:00 : 현재 시각

thread는 프로세스 내부에서 실행되는 작업 단위이고, 일반적으로 하나의 프로세스는 하나 이상의 스레드를 가진다.

2) Load Avg: 1.99, 2.50, 2.90

Load Average : CPU 작업 큐에 대기중인 평균 프로세스 수로, 각 수치는 1분, 5분, 15분 간격의 평균
- 해석
  - 1분 평균 : 1.99
  - 5분 평균 : 2.50
  - 15분 평균 2.90

Mac은 CPU 여러 개일 수 있기 때문에, 예를 들어 CPU 가 4개면 Load Avg가 4를 넘지 않으면 괜찮은 상태라고 볼 수 있다.

3) CPU usage: 8.40% user, 5.64% sys, 85.95% idle

8.40% user : 일반 사용자 프로그램이 사용한 CPU 시간
5.64% sys : 커널/시스템 호출이 사용한 CPU 시간
85.95% idle : 놀고 있는 시간 (CPU가 여유 있음)

idle 이 높을수록 좋음. 여유가 있다는 뜻

4) SharedLibs: 688M resident, 142M data, 56M linkedit.

SharedLibs는 시스템에서 사용하는 공유 라이브러리 관련 메모리 정보
- 912M resident : 실제 물리 메모리에 올라와 있는 라이브러리 메모리
- 142M data : 데이터 부분
- 82M linkedit : 링크 편집 관련 데이터
대부분 시스템/공유 라이브러리에 대한 정보이고, 이 수치는 참고만 하면 된다.

5) MemRegions: 307218 total, 3956M resident, 707M private, 2431M shared.

307218 total : 메모리 영역(region)의 총 개수 (각종 코드/데이터 블록 포함)
3956M resident : 실제 물리 메모리에 상주 중인 총 용량
707M private : 이 프로세스만 단독으로 사용하는 메모리
2431M shared : 다른 프로세스들과 공유하는 메모리

Resident 가 많으면 메모리를 많이 쓰는 거고, Private이 많으면 해당 프로세스가 독점적으로 메모리 쓰는 비중이 크다는 뜻

6) PhysMem: 15G used (1278M wired, 0B compressor), 946M unused.

15 Used : 현재 사용중인 물리 메모리 (RAM)
1278 wired : Wired Memory는 OS나 커널이 반드시 RAM에 고정해둬야 하는 메모리 (절대 swap 불가)
0B compressor : 메모리 압추게 사용된 영역 (현재 없음)
946M unused : 사용 가능한 여유 메모리

wired가 너무 커지면 커널이 RAM을 많이 차지하고 있다는 의미로, 시스템 자원 여유를 줄이게 됨.

7) VM: 230T vsize, 4921M framework vsize, 0(0) swapins, 0(0) swapouts.

230T vsize : 전체 가상 메모리 크기 (굉장히 큰 값이지만 걱정할 필요 없음, 대부분 예약 영역)
4921M framework vsize : macOS 프레임워크가 차지한 가상 메모리
0(0) swapins/swapouts : 디스크로부터 swap 영역을 읽거나 쓴 횟수 및 크기로, 현재 0 - swqp 이 일어나지 않고 있음

8) Networks: packets: 37883/32M in, 24766/8573K out.

packets: 37883/32M in : 37883개의 패킷 / 총 32M 수신(in)
24766/8573K out : 24766개의 패킷 / 총 8573K 송신(out)

네트워크 트래픽 상태. 네트워크 사용량 확인할 수 있음

9) Disks: 217510/4878M read, 127757/3757M written.

217510번 읽기 / 총 4878M 읽음
127757번 쓰기 / 총 3757M 기록

디스크 I/O 활동량, 디스크 과부하 원인 추적 시 유용

Task / CPU/Memory 상태 확인: Linux

Tasks: 3 total, 1 running, 2 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.2 sy, 0.0 ni, 99.6 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
MiB Mem : 7837.6 total, 7313.0 free, 441.2 used, 233.8 buff/cache
MiB Swap: 1024.0 total, 1024.0 free, 0.0 used. 7396.4 avail Mem

✔︎ Tasks & CPU 상태

Tasks: 3 total, 1 running, 2 sleeping, 0 stopped, 0 zombie

3 total : 전체 3개 프로세스
1 running : 현재 CPU에서 실행중인 프로세스 1개
2 sleeping : 대기 중인 프로세스 2개
0 stopped/zombie : 정지되거나 종료되었으나 수거되지 않은 프로세스 없음

좀비(zombie) 는 자식 프로세스가 종료되었지만 부모 프로세스가 wait()로 회수하지 않은 경우이다.

✔︎ CPU 사용율

%Cpu(s): 0.0 us, 0.2 sy, 0.0 ni, 99.6 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st

us (user) : 0.0% -> 사용자 프로세스가 거의 CPU를 사용하지 않음
sy (system) : 0.1% -> 커널/시스템 수준에서 약간의 사용
id (idle) : 99.8% -> CPU가 거의 놀고 있음 (매우 여유 있음)
wa (wait) : 0.0% -> I/O 대기 없음
hi/si : 하드웨어/소프트웨어 인터럽트 거의 없음

✔︎ 메모리 사용량

MiB Mem : 7837.6 total, 7313.0 free, 441.2 used, 233.8 buff/cache

total : 전체 메모리 7.8GB
free : 7.3GB 사용가능 (대부분 사용 안하고 있음)
used : 441MB만 실제로 사용 중
buffer/cache : 234MB는 디스크 캐시 등으로 일시적으로 사용됨

✔︎ 스왑 영역

MiB Swap: 1024.0 total, 1024.0 free, 0.0 used. 7396.4 avail Mem

total : 스왑공간이 1GB 할당되어 있음
free : 남은 스왑공간
used : 스왑 사용량
avail Mem : 애플리케이션이 사용할 수 있는 실질적인 여유 메모리

top 명령어 사용법

키	설명
q	top 종료
P	CPU 사용량 높은 순 정렬(기본 정렬)
M	메모리 사용량 높은 순 정렬
T	실행 시간 순 정렬
k	특정 PID를 입력해 프로세스 강제 종료(kill)
1	CPU 코어별 사용량 보기/숨기기
h	도움말 보기(key 설명)
u	특정 사용자(user)의 프로세스만 보기
f	컬럼 추가/삭제 (고급 사용자용)

자주 사용하는 옵션들

# 자주 사용하는 top 옵션들
$ top -u [사용자명] # 특정 사용자의 프로세스만 보기
$ top -p [PID] # 특정 PID만 추적
$ top -n [횟수] # 지정한 횟수만큼 갱신 후 종료
$ top -d [초] # 갱신 간격 설정 (기본 3초)

# 예시
$ top -u root 
$ top -d 1
$ top -n 5
$ top -p 1234

✅ 관련 명령어

명령어	설명
htop	top을 더 보기 쉽게 만든 명령어 (방향키 지원)
ps aux	프로세스 스냅샵 보기 (실시간 아님)
free -m	메모리 사용량 요약
vmstat	CPU, 메모리, I/O 상태 분석

[Tibero] Tibero 데이터베이스 유지관리 [4] 로그 및 세션 관리

mellowg — Tue, 5 Aug 2025 21:09:42 +0900

리스너 로그 확인

리스너 로그를 통해서 언제 어떤 클라이언트가 접속을 시도했는지 확인할 수 있다. 그러나 client의 접속 요청이 Listener에게 도달하기 전에 문제가 발생한 경우에는 리스너 로그에 아무것도 남지 않는다.

만약 client 접속 요청이 실패하는 경우 리스너로그 확인 후 리스너 로그에 아무런 로그가 남아있지 않다면 네트워크 쪽을 확인해보거나 해야 하며, 로그가 남은 경우에 로그 기록에 따라 조치를 취하면 된다.

리스너 로그 조회

$ cat $TB_HOME/instance/$TB_SID/log/lsnr
$ vi trace_list.log 
# or $ tail -n10 trace_list.log

로그 예시

# 세션에 클라이언트 접속요청 후 접속 성공한 경우 발생하는 로그
2025/07/30 16:08:43.990291 [5] listener:1452 a new client connection detected.
2025/07/30 16:08:43.990326 [5] listener:1371 a client connection from [127.0.0.1:44318] # 접속 요청한 클라이언트 정보
2025/07/30 16:08:43.990332 [5] listener:1494 a client from IP socket
2025/07/30 16:08:43.990344 [5] listener:3104 sent a connection fd to the WTHR process 1 successfully. # 클라이언트 WTHR(WORKER THREAD) 커넥션 성공

리스너 로그가 현재 어떤 포트를 리스닝하는지 확인

$  netstat -tlpn | grep tblistener
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:8629            0.0.0.0:*               LISTEN      2026/tblistener

DB 접속 세션 끊기

DBA가 DB관련 작업을 할 때 모든 세션을 끊고 작업을 해야하는 경우가 있다. 실제 운영중인 서버인 경우 세션이 붙어있을 것이다. 이때는 세션이 연결되지 못하도록 막고, 기존 세션들을 끊는 작업이 필요하다.

반드시 세션이 연결되지 못하도록 막는 것이 선행되어야 한다. (은행 창구에 대입하여 생각하면 이해하기 쉽다.)

은행 번호표 뽑는 것을 막지 않고 기존 고객을 쫒아내더라도 번호표는 계속 뽑히고 있을테니 계속해서 손님은 들어올 것이다. 번호표 기계를 먼저 종료한 후 기존 고객 거래를 끝내야 은행창구에 아무도 없을 것이다.

세션이 연결되지 못하도록 하려면 어떻게 해야할까?

세션을 연결하도록 하는 것은 Listener의 역할이다. Listener가 더이상 세션 연결 요청을 리스닝하지 못하도록 OFF 하는 방법이 있다.

1. 신규 세션 생성 막기

리스닝 OFF

리스닝 off 의 경우 아래 명령어를 실행하면 된다. 반대로 리스닝 ON은 OFF를 ON으로 변경하여 실행하면 된다.

ALTER SYSTEM LISTENER REMOTE OFF;

작업 후 netstat -tlpn | grep tblistener 조회해보면 아무것도 출력되지 않은 것을 확인할 수 있다.

2. 기존 세션 연결 끊기

기존 세션 연결 끊는 명령어는 아래와 같다. SID 와 SERIAL# 값은 V$SESSION 시스템뷰나 tm(tibero monotor)를 통해서 조회할 수 있다. 여기서는 V$SESSION을 통해 조회해보자

ALTER SYSTEM KILL SESSION(SID, SERIAL#);

V$SESSION을 통해 SID, SERIAL# 값 조회하기

VT_MYTID를 통해 나는 어떤 SID를 사용중인지 확인이 꼭 필요하다. 실수로 나의 연결을 끊어버릴 수 있기 때문이다.

SELECT 
	SID, 
	SERIAL#,
	USERNAME,
	PROG_NAME
FROM V$SESSION;

# 조회 결과
#	SID	SERIAL#	USERNAME	PROG_NAME
1	77	6,058	SYS	tbsql
2	87	632	TIBERO	Studio
3	88	1,360	SYS	tbsql
4	89	1,051	SYS	Studio

# 나는 어떤 SID 사용중인지?
SQL > SELECT * FROM VT_MYTID; -- 77

# 기존 접속 끊기
ALTER SYSTEM KILL SESSION(87, 632);
ALTER SYSTEM KILL SESSION(88, 1360);
ALTER SYSTEM KILL SESSION(89, 1051);

[Tibero] Tibero 데이터베이스 유지관리 [3] TIP 파일과 메모리

mellowg — Tue, 5 Aug 2025 20:45:20 +0900

Tibero Instance Paramter 파일 (TIP파일)

TIP 파일은 Tibero 데이터베이스의 초기화 파라미터(Parameter)를 정의한 설정 파일이다.

확장자 : .tip
기본 위치 : $TB_HOME/config/$TB_SID.tip
역할 : DB 인스턴스 구동 시 필요한 환경설정 값 로딩
주요 설정 : 메모리 크기, 로그 경로, 백업 설정, listener 포트

# 파라미터 파일 내용 예시
# DB 이름
DB_NAME=tibero
# 리스너 포트
LISTENER_PORT=8629
# 컨트롤 파일
CONTROL_FILES="/tibero/tbdata/control_1/c1.ctl","/tibero/tbdata/control_2/c2.ctl"
# db에서 생성된 파일 기본 저장 경로
DB_CREATE_FILE_DEST="/tibero/tbdata/data_1"
# 로그 아카이브 파일 경로
LOG_ARCHIVE_DEST="/tibero/tbdata/arch"

# 최대 연결 가능 세션 수
MAX_SESSION_COUNT=20
# 공유 메모리 사이즈
TOTAL_SHM_SIZE=1500M
# 전체 메모리 사이즈
MEMORY_TARGET=2048M

### LOG
# 로그 기본 경로
LOG_DEFAULT_DEST="/tibero/tibero7/instance/tibero/log"
# sys log 전체 최대 사이즈 => 오래된 순서로 삭제됨.
SLOG_TOTAL_SIZE_LIMIT=300M
# 리스너 로그 최대 사이즈
LSNR_LOG_TOTAL_SIZE_LIMIT=300M
# ilog 최대 사이즈
ILOG_TOTAL_SIZE_LIMIT=700M
# dbms 로그 최대 사이즈
DBMS_LOG_TOTAL_SIZE_LIMIT=300M
# sys 로그 파일 하나 당 사이즈
SLOG_FILE_SIZE=100M
# 리스너 로그 파일 하나 당 사이즈
LSNR_LOG_FILE_SIZE=10M
# ilog 파일 하나 당 사이즈
ILOG_FILE_SIZE=10M
# dbms 로그 파일 하나 당 사이즈
DBMS_LOG_FILE_SIZE=100M

### ETC
GATHER_SQL_PLAN_STAT=Y
# 날짜 포맷
NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS"

SQL 쿼리문으로 티베로 파라미터 정보 조회하기

- V$PARAMETERS 라는 시스템뷰를 통해 티베로 파라미터를 조회할 수 있다.

-- 예시코드
SELECT
	NAME
    , VALUE
FROM V$PARAMETERS
WHERE 1=1
AND NAME IN ('MEMORY_TARGET', 'TOTAL_SHM_SIZE')
;

공유 메모리(TSM) 크기 정보 조회

-- FIXED MEMORY (REDO LOG BUFFER, SYSTEM AREA, DATABASE BUFFER CACHE)
-- TSM에서 FIXED MEMORY에 해당하지 않는 것은 SHARED CACHE
SELECT
	NAME
    , ROUND(TOTAL / 1024 / 1024, 1) AS "TOTAL(MB)"
    , ROUND(USED / 1024 / 1024, 1) AS "USED(MB)"
FROM V$SGA;

*SQL WORK AREA → SORT_AREA_SIZE를 통해 사이즈 설정이 가능하다. (DEFAULT PGA의 30%)
*MEMORY TUNER → 티베로 내부적으로 SQL WORK AREA 메모리 사용할 때 3초 단위(감시 단위 변경 가능)로 확인하면서 메모리 사용량을 조절해준다.

-- SORT 작업용 메모리 크기
SORT_AREA_SIZE

-- HASH 조인용 해시테이블 할당 메모리 크기 설정
HASH_AREA_SIZE

-- PGA 메모리의 SQL WORK AREA 공간 크기 검사 주기
EX_MEMORY_COMPENSATE_INTERVAL

* 위 3개 파라미터 조회 쿼리
SELECT NAME, VALUE, DFLT_VALUE
FROM V$PARAMETERS
WHERE 1=1
AND NAME IN ('SORT_AREA_SIZE', 'HASH_AREA_SIZE', 'EX_MEMORY_COMPENSATE_INTERVAL');

[Tibero] Tibero 데이터베이스 유지관리 [2] 티베로 메모리 구조

mellowg — Tue, 5 Aug 2025 20:22:20 +0900

Tibero Process 확인

# 현재 실행중인 티베로 프로세스 조회
$ ps -ef | grep tbsvr 

# 현재 실행중인 티베로 리스너 조회
$ ps -ef | grep tblistener

조회 예시

# 티베로 프로세스 조회
$ ps -ef | grep tbsvr

tibero      2025       1  0 14:09 pts/0    00:00:01 tbsvr          -t NORMAL -SVR_SID tibero # monitor process
tibero      2027    2025  0 14:09 pts/0    00:00:00 tbsvr_MGWP     -t NORMAL -SVR_SID tibero # 관리자 접속용 
tibero      2028    2025  0 14:09 pts/0    00:00:00 tbsvr_FGWP000  -t NORMAL -SVR_SID tibero # Worker Process
tibero      2029    2025  0 14:09 pts/0    00:00:01 tbsvr_FGWP001  -t NORMAL -SVR_SID tibero # Worker Process
tibero      2030    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP000  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2031    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP001  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2032    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP002  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2033    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP003  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2034    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP004  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2035    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP005  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2036    2025  0 14:09 pts/0    00:00:02 tbsvr_AGNT     -t NORMAL -SVR_SID tibero # 에이전트
tibero      2037    2025  0 14:09 pts/0    00:00:00 tbsvr_DBWR     -t NORMAL -SVR_SID tibero # DB Writer process
tibero      2038    2025  0 14:09 pts/0    00:00:00 tbsvr_RCWP     -t NORMAL -SVR_SID tibero # 복구 프로세스

# 리스너 프로세스 조회
$ ps -ef | grep listener 
[tibero@T6:/tibero/tibero7/config]$ ps -ef | grep listener
root         934       1  0 12:12 ?        00:00:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
tibero      2026    2025  0 14:09 pts/0    00:00:00 /tibero/tibero7/bin/tblistener -n 11 -t NORMAL -SVR_SID tibero

Tibero Memory Structure

Tibero Memory 구조는 TSM(Tibero Shared Memroy=SGA)와 PGA(Process Global Area)로 구성되어 있다.

PGA는 프로세스 끼리 서로 공유하지 않는 메모리 공간으로 MEMORY_TARGET - TOTAL_SHM_SIZE 즉, 전체 메모리 크기에서 TSM 크기를 뺀 나머지 사이즈가 PGA 크기이다.
TSM은 인스턴스끼리 공유하는 메모리 영역으로, 사이즈는 TOTAL_SHM_SIZE 파라미터로 지정한다.

TSM (Tibero Shared Memory)

1. DB Buffer Cache

- 최근 테이블, 인덱스의 데이터를 저장한다.

- DB_CACHE_SIZE 파라미터로 크기를 지정한다.

- DB Buffer Cache에 올라온 데이터 블록은 재사용된다.

- DB Buffer Cache Hit 율이 높다. ▶️ 버퍼 캐시 내의 데이터 블록들의 재사용성이 높다. ▶️ Disk I/O가 적다

2. Redo Log Buffer

- 데이터 처리 작업 내용을 저장 한다.

- 기본 10MB 크기이며, LOG_BUFFER 파라미터로 크기를 설정하낟.

- 데이터 수정 내역을 저장한다.

- 여러 사용자들의 Redo Log 들이 Redo Log Buffer에 저장된다.

- Redo Log Buffer 내용은 Redo Log File에 저장된다.

3. System Area

- 전역변수 공간으로, Worker Thread를 관리하는 공간이다.

- 세션정보 관리 공간으로 구성된다.

4. Shared Cache

1) PP Cache(Physical Plan Cache)

- 최근 실행환 쿼리문, 구문 분석(파싱)정보, 실행계획 정보를 저장한다.

2) DD Cache(Dictionray Cache)

- 최근 실행한 SQL에서 사용하는 오브젝트(테이블, 컬럼, 사용자, 권한)의 데이터 사전 정보 저장

PGA(Process Global Area)

Worker Process 간에 공유하지 않는 독립적인 메모리 영역이다.

PGA 크기 = MEMORY_TARGET - TOTAL_SHM_SIZE

1. SQL Work Area

- Worker Thread가 SQL 수행 시 Sorting, Merge 조인, Hash 조인 작업 공간으로 사용

- 크기가 부족하면 임시 세그먼트 (Temporary Tablespace)를 사용하여 성능이 저하된다.

2. Process Memory

- 프로세스가 동작하는 데 필요한 공간

3. SQL Info Area

- 커서 정보 영역으로 SQL문을 처리하는데 필요한 공간

4. Session Info Area

- 로그인 및 세션 관련 정보 저장

✅ 관리자 입장에서의 메모리 관리

1. 각각의 메모리 크기 관리

2. 메모리들이 본래 목적에 맞게 잘 돌아가는지 확인

- Hit율로 확인한다. ➡️ 100%에 가까울수록 좋다 ➡️ Hit율이 높다는 것은 그만큼 프로세스간 메모리 공유가 잘 된다는 것

- 크기, Hit율을 파악하여 조치해야 한다.

✔︎ 메모리 추가

✔︎ 기존 메모리 비율 재설정

✔︎ 기존 메모리를 효율적으로 사용하도록 수정 (ex, SQL Query 튜닝)

*튜닝이 필요한 쿼리 찾기 ➡️ 쿼리 모니터링(PP Cache) ➡️ 쿼리 튜닝을 통해 Temp Tablespace를 적게 사용하도록 하거나, 실행계획을 조금 더 효율적으로 수정하거나 등등,,

OLTP 와 OLAP

OLTP(Online Transaction Processing)
- 온라인 트랜잭션 처리 시스템
- 사용자들이 실시간으로 데이터에 접근하고 처리하는 시스템을 의미
- ex) 은행 ATM 이체, 온라인 쇼핑몰 상품 주문 등
OLAP(Online Analytical Processing)
- 온라인 분석 처리 시스템
- 대량의 데이터를 분석하고 인사이트를 얻기 위한 시스템
- ex) 매출 분석 보고서, 고객 행동 패턴 분석

✔︎ OLTP vs OLAP 비교표

비고	OLTP	OLAP
목적	실시간 업무 처리	데이터 분석
사용자	일반 사용자	관리자, 데이터 분석가
데이터	자주 변경	주로 읽기 전용
트랜잭션	짧고 빠름	길고 복잡함
예시	은행, 쇼핑몰	매출분석, 경영 리포트

업무 성격에 따른 메모리 크기 비율 설정 ( OLTP, OLAP )

1. OLTP → 8(TSM) : 2 (PGA) 비율

- OLTP는 소량 데이터를 여러 세션에서 접근하는 경우가 많다. 소량의 데이터를 버퍼 캐시에서 빠르게 접근하기 때문에 PGA 크기가 많이 필요하지 않다. (소량 데이터라 처리 부담이 적음)

2. OLAP → 5(TSM) : 5 (PGA) 비율

- OLAP는 대량의 데이터를 분석, 집계하는 경우로, 대량 데이터 처리(sorting 등 ) 하는데 작업 공간이 많이 필요하다. PGA가 커야 원할하게 작업을 처리할 수 있다. 대량 데이터 처리 환경에서는 1년치 데이터 or 테이블 모든 데이터 접근 하기 위해서 대량 데이터를 버퍼 캐시에 올려야 한다. 기존 버퍼 캐시 재사용이 잘 되지 않는다.

[Tibero] Tibero 데이터베이스 유지관리 [1] 프로세스 구조

mellowg — Wed, 30 Jul 2025 22:08:56 +0900

Tibero 구조

Client 가 Tibero DB에 접속하기 위해서는 Listener를 거쳐 유휴 Worker Thread를 할당 받아 Session을 맺은 후 여러 작업(SELECT, UPDATE, DELETE 등)을 수행한다.

그렇다면 Listener 는 어떻게 Worker Thread를 할당시켜줄까?

Client가 Tibero Instance에 접속을 요청하면 Listener가 해당 요청(request)를 받아 유휴한 Worker Process에게 해당 요청을 전달한다. 요청을 전달받은 Worker Process는 Control Thread 를 통해 유휴한 Worker Thread 를 배정해주며, 해당 Worker Thread가 Client 의 인증정보를 확인 후 세션을 맺게 된다. ( Connect )

Control Thread는 Worker Process 당 1개씩 존재하며, Worker Thread 는 default 값 10으로 Worker Process당 10개씩 존재한다.

즉, Client 는 Worker Process 와 연결이 되지 않으면 DB에 접근이 불가능하다.

Client 가 DB에 접속을 하지 못하고 있는 상태라면, 어디서 문제가 있는지 다음과 같이 생각해 볼 수 있다.

1. Listener가 Worker Process에게 요청을 던져주기 전

2. Listener가 Worker Process에게 요청을 던져준 후

1번인 상황이라면 네트워크의 문제로 client의 접속요청이 listener 까지 닿지 못했거나, listener 단에서 문제가 발생했다고 가정할 수 있다. 이러한 정보들은 listener log 를 통해서 확인할 수 있다.

2번 상황이라면 티베로 시스템 로그를 확인해 보아야 한다.

리스너의 포트 넘버는 tip 파일에서 설정한다.

# $TB_SID.tip
LISTENER_PROT=8629

요약

< 티베로 접속 과정 >

1. client -> listener 접속 요청

2. listener -> control thread 요청

3. control thread -> 유휴 worker thread 할당

4. client <--> worker thread 인증 절차 후 세션 시작

< 접속정보 5가지 >

- IP

- PORT

- DB NAME

- USERNAME

- PASSWOD

*DB NAME : Instance 는 자기가 관리하는 데이터에비스를 DB NAME으로 인식한다. (DB 설치할 때 이름 부여)

< 리스너 로그를 통해 알 수 있는 정보 >

1. 접속요청한 클라이언트 IP

2. 워커프로세스 할당

* 리스너로그가 남아있지 않다는 것은 LISTENER에게 접속 요청이 오지 않았다는 것으로, 네트워크 문제가 있었을 수 있기 때문에 네트워크를 확인해 보아야 한다.

< 티베로 시스템 로그 >

- LISTENER 로그까지 남아있지만 접속이 안된 경우 확인해보기

프로세스

Listener

- 사용자의 최초 접속 요청시 중계 역할

Worker Process (or Foreground Process)

- Tibero 동시 접속이 가능한 클라이언트의 수를 의미한다.

- (최대 DB 세션 수) = (워커프로세스 수 * 워커프로세스당 워커스레드 개수)

- MAX_SESSION_COUNT (권장하는 파라미터)

- 워커 프로세스를 강제 종료하게 되면 다른 워커프로세스들은 영향을 받지 않고, 죽은 워커프로세스는 다시 살아나지 않는다.

Worker Thread

- Tibero가 기동될 때 생성된 이후 종료할 때까지 계속 존재하는 Thread

- Client와 접속이 끊겨도 종료되지 않는다.

- 워커 스레드를 강제로 Kill 하게 되면 Tibero Instance는 비정상 종료하게 된다.

서비스를 운영하다가 사용자가 급격하게 많아져 워커 스레드가 부족할 수도 있다. 이때 워커스레드의 개수는 동적으로 증가시키는 것은 불가능하다. 워커 스레드의 수를 늘리려면 tip 파일에서 값을 수정 후 DB를 재기동해야 한다.

부족 현상이 일어나지 않도록 사전에 넉넉하게 MAX_SESSION_COUNT 값을 설정해 두어야 한다.

MGWP

- SYS 계정은 두 가지 방식으로 DB Instance 연결이 가능하다.

1. LISTENER 와 WORKER PROCESS를 통해 접속하는 경우

2. MGWP를 통해 접속하는 경우

- Worker Thread를 사용자들이 전부 점유하는 경우 SYS가 붙지 못한다.

- Special Port 는 보통 Listener Process Port (=SERVICE PORT) + 1

- Worker Thread를 통해 접속하는 것과 크게 다르지 않다.

MGWP 를 통해 접속하느 방법은 tbdsn.tbr 에 Special Port 를 추가해 준 후 명시적으로 접속해준다.

# tbdsn.tbr 
special=(
    (INSTANCE=(HOST=localhost)
              (PORT=8630)
              (DB_NAME=tibero)
    )
)

tibero=(
    (INSTANCE=(HOST=localhost)
              (PORT=8629)
              (DB_NAME=tibero)
    )
)

# MGWP로 접속하는 방법
$ tbsql sys/tibero@special

세션 모니터링

- tm 툴 사용하기

- v$session 시스템 뷰 조회

- 워커 스레드 <-----------> 사용자

- 식별자 (SESSION ID (SID), SERIAL#)

- 조회 가능 ( V$SESSION or GV$SESSION )

- 여러 정보들 ( 클라이언트 정보, 쿼리, 메모리 사용량 )

사용자 접속 차단

- 서비스 운영 중 거래가 없는 상태에서 작업을 해야 할 수도 있다. 그럴때는 어떻게 거래를 막아야 할까?

사용자를 두 가지 분류로 나눌 수 있다. 이미 접속해 있는 사용자, 접속을 시도하는 사용자

그렇다면 우선 접속을 시도하는 사용자의 접속이 불가능하도록 막아야한다. 그 후 이미 접속해 있는 사용자의 거래가 끝나길 기다리던가, 강제로 접속을 끊으면 모든 사용자 접속을 차단할 수 있다. (마감시간 은행 창구를 생각하면 이해가 쉽다. )

사용자의 접속 시도는 어떻게 막을 수 있을까?

사용자가 접속 가장 처음 받는 것은 LISTENER 프로세스이다. 사용자가 알고 있는 LISTENER 프로세스의 포트 번호를 바꾸거나, 명령어를 통해 OFF 해준다.

SID, SERIAL#은 V$SESSION을 통해 조회할 수 있다. 잘못해서 내 세션을 끊을수도 있기 때문에 나의 SID를 미리 확인해주자.

SQL > SELECT * FROM VT_MYTID;

-- 리스너 리스닝 OFF
ALTER SYSTEM LISTENER REMOTE OFF;

-- 접속되어 있는 사용자 세션 끊기
ALTER SYSTEM KILL SESSION(SID, SERIAL#);

Tibero DBMS 관련 용어 및 분석

mellowg — Fri, 6 Jun 2025 16:32:36 +0900

Tibero DBMS 관련 용어 및 분석

1. DB Memory Size

Shared Memory Size
- 의미 : 전체 TSM(Tibero Shared Memory) 사이즈
- 분석 : 사이즈가 클수록 성능이 좋다.
Shared Pool Size
- 의미 : Shared Pool Memory 크기를 의미한다. Physical Plan, Data Dictionary 정보를 Working Thread 간 공유하기 위해 쓰이는 메모리 영역의 크기
- 분석 : 사이즈가 클수록 성능이 좋지만, 전체 TSM 크기 내에서 Shared Pool, Buffer Cache, Redo Log Cache의 크기를 조율해야 하기 때문에 적절하게 크기를 조절해주어야 한다.
  [사이즈가 작을 경우; 적재 가능한 DD/PP가 적다. → 디스크 I/O 증가 → 성능 감소]
  [사이즈가 클 경우; 적재 가능한 DD/PP가 많다. → 디스크 I/O 감소 → 성능 향상]
DB Cache Size (= Buffer Cache Size)
- 의미 : DB Buffuer Cache의 크기, 디스크로부터 읽어들인 데이터 블록을 담고 있는 버퍼
- 분석 : 크기가 클수록 성능이 좋다.
  [사이즈가 작을 경우; 적재 가능한 데이터 블록의 수가 적다 → Hit율 감소 & 디스크 I/O 증가 → 성능 감소]
  [사이즈가 클 경우; 적재 가능한 데이터 블록의 수가 많다. → Hit율 증가 & 디스크 I/O 감소 → 성능 향상]
Log Buffer Size (= Redo Log Buffer Size)
- 의미 : Redo Log Buffer Cache의 크기로, DML에 의한 변경 사항을 저장하고 있는 Redo Log Buffer
- 분석 : 크기가 클수록 성능이 좋다.
  [사이즈가 작을 경우; LGWR에 의해 디스크에 많이 쓰인다. → 디스크 I/O 증가 → 성능 감소]
  [사이즈가 클 경우; LGWR에 의해 디스크에 적게 쓰인다. → 디스크 I/O 감소 → 성능 향상]
DB Block Size
- 의미 : 데이터베이스 블록 크기
- 분석 : 적절한 크기 설정이 필요하다.
  [사이즈가 작을 경우; 여러 블록에 데이터가 쪼개서 저장 → 데이터 단편화 증가 → 디스크 I/O 증가 → 성능 감소]
  [사이즈가 클 경우; 하나의 블록에 데이터 저장 가능 → 데이터 단편화 감소 → 디스크 I/O 감소 → 성능 향상 (but, 공간 낭비가 발생할 수 있다. 조각화 문제]

2. SGA Stat

Buffer Cache Hit Ratio
- 의미 : DB Buffer Cache 에서 원하는 데이터를 찾은 비율
- 분석 : 높을수록 성능이 좋은 것
  [Hit율이 높은 경우; 메모리에서 원하는 데이터를 많이 찾음 → 디스크 I/O 감소 → 성능 향상]
  [Hit율이 낮은 경우; 메모리에서 원하는 데이터를 적게 찾음 → 디스크 I/O 증가 → 성능 감소]
SQL Cache Hit Ratio
- 의미 : Shared Pool Memory 내의 SQL Cache(PP Cache)에서 SQL Plan을 찾은 비율
- 분석 : 높을수록 성능이 좋은 것
  [Hit율이 높은 경우; 메모리에서 원하는 SQL Plan을 많이 찾음 →디스크 I/O 감소 → 성능 향상]
  [Hit율이 낮은 경우; 메모리에서 원하는 SQL Plan을 적게 찾음 →디스크 I/O 증가 → 성능 감소]
Dictionary Cache Hit Ratio
- 의미 : Shared Pool Memory 내의 Data Dictionary에서 원하는 DD 정보를 찾은 비율
- 분석 : 높은수록 성능이 좋은 것
  [Hit율이 높은 경우; 메모리에서 원하는 DD 정보를 많이 찾음 →디스크 I/O 감소 → 성능 향상]
  [Hit율이 낮은 경우; 메모리에서 원하는 DD 정보를 적게 찾음 →디스크 I/O 증가 → 성능 감소]
In-Memory Sort
- 의미 : 메모리에서 정렬이 일어난 횟수의 비율(메모리 정렬 수 / 총 정렬 수)
- 분석 : 높은수록 성능이 좋은 것
  [높은 경우; 정렬이 메모리에서 많이 일어남 → Temp Tablespace에서 정렬이 적게 일어남 → 디스크 I/O가 적게 일어났다는 것 → 성능 향상]
  [낮은 경우; 정렬이 메모리에서 적게 일어남 → Temp Tablespace에서 정렬이 많이 일어남 → 디스크 I/O가 많이 일어났다는 것 → 성능 감소]
Shared Cache Free Space
- 의미 : Shared Memroy에서 남은 여유 공간의 크기를 의미
- 분석 : 높을수록 성능 측면에서 좋음
  [여유 공간이 많다; 낭비되고 있는 메모리 영역이 많다. → 그러나 추후 DD, PP가 적재되어 디스크 I/O가 줄어든다. → 메모리 용량 효율 측면에서는 나쁘지만, 디스크 I/O 측면에서는 좋다.]
  [여유 공간이 적다; 낭비되고 있는 메모리 영역이 적다. → 그러나 추후 DD, PP가 적재되어 디스크 I/O가 증가한다. → 메모리 용량 효율 측면에서는 좋지만, 디스크 I/O 측면에서는 나쁘다.]

3. Tablespace Usage

Tablespace Usage
- 의미 : 전체 테이블스페이스 사용량을 의미
- 분석 : 테이블스페이스 사용량이 90%가 넘으면 디스크 공간이 매우 부족한 상태이기 때문에 디스크 증설, 테이블스페이스 분할, 불필요한 데이터 제거 등의 조치를 취해야 한다. 사용량이 100%가 되면 DBMS가 멈추며 장애가 발생한다.
Undo Usage Free
- 의미 : Undo 테이블스페이스에서 사용가능한 공간 비율
- 분석 : 클수록 좋다. Undo Segmet가 덮어씌어질 가능성이 낮아지며, 복구 가능성/롤백 가능성이 증가하게 된다. 또한 트랜잭션이 많아 Undo Segment를 모두 사용하게 되어 트랜잭션이 중지될 가능성이 낮다.
Temp Usage
- 의미 : Temp 테이블스페이스에서 사용중인 공간 비율
- 분석 : 사용량이 낮을수록 좋다. Temp Tablespace 사용량이 낮다는 것은 그만큼 부하가 큰 작업을 수행중인 트랜잭션이 많다는 것이다.

4. Object 점검

Invalid Object 개수
- 의미 : Invalid Object(정상적으로 컴파일 되지 않은 객체)의 수 점검 ( STATUS='INVALID' )
- 분석 : 적을수록 좋다.
  Invalid Object가 있다는 것은 정상적이지 않은 객체가 있다는 것으로, 원인을 파악하고 해결해야 한다. (rebuild, recompile)
통계정보수집 점검
- 의미 : 통계정보(Optimizer가 실행계획을 세울 때 참조하는 정보) 수집 확인
- 분석 : 통계정보는 optimizer가 실행계획을 작성할 때 참조하는 정보로 성능 최적화에 영향을 주기 때문에 최신상태를 유지할 수록 좋다.
NOCYCLE 시퀀스 점검
- 의미 : NOCYCLE 옵션인 시퀀스 중 LAST_NUMBER 값이 MAX_VALUE 90% 이상 도달한 시퀀스의 수를 점검
- 분석 : Nocycle 시퀀스 90% 도달한게 많다는 것은 에러날 확률이 높은 시퀀스가 많다는 것이다. MAX_VALUE를 더 높여주는 등의 조치 필요
Recyclebin 점검(건수, 사이즈)
- 의미 : Recyclebin 에 저장된 삭제된 Segment의 수와 사이즈 점검
- 분석 : Recyclebin에 DROP된 데이터가 저장된다. Recyclebin을 purge해줘야 디스크에서 완전삭제 되며 purge 전에는 계속 쌓인다. (테이블스페이스 부족한 경우도 내부적으로 삭제됨) 주기적으로 recyclebin을 purge 해줘야 한다.

5. Instance 점검

Session Usage
- 의미 : 현재 접속한 세션 수 / 인스턴스에 최대로 접속할 수 있는 세션 수
- 분석 : 작을수록 좋다. 현재 접속한 세션의 수가 MAX_SESSION에 가까워 지면 새로운 세션이 불가능하게 되며 에러가 발생할 수 있다.

6. Redo Swtich Stat

Max Count / Day
- 의미 : 하루 최대 로그 스위치 발생 횟수
- 분석 : Max count가 Avg Count보다 많이 크다면 일별 log swtich 횟수를 확인하고 특정 날짜에 많이 발생한 원인을 파악해야 한다.
Avg Count / Day
- 의미 : 하루 평균 로그 스위치 발생 횟수
- 분석 : 평균적으로 log switch 수가 크다면 log switch가 적게 일어나도록 redo member의 크기를 증가시키는 등의 조치를 취한다. 수가 작다면 redo member의 크기가 너무 큰건 아닌지 확인하고 사이즈를 줄이는 등 조절할 필요가 있다.
Avg Size(MB) / Day
- 의미 : 하루 평균 로그 스위치 사이즈
- 분석 : 하루 평균 로그 스위치 수와 함께 봐야 한다.
  (1) 로그 스위치 횟수 작으면서 사이즈는 크다면 리두 로그 파일이 매우 커서 로그 스위치가 적은 빈도로 일어나고 있을 가능성이 있다. 한번에 대량의 로그가 디스크에 기록되게 된다. → 리두 로그 멤버의 크기를 감소시키는 등 균형을 맞춰줘야 한다.
  (2) 로그 스위치 횟수가 크면서 사이즈가 작다면 리두 로그 파일이 매우 작아서 자주 일어나고 있을 가능성이 있다. 적은 파일의 데이터를 자주 쓰게 되면서 리두 로그 파일을 자주 교체하게 되며 오버헤드 발생 및 성능 저하 가능성이 높다. → 리두 로그 멤버의 크기를 증가시키는 등 균형을 맞춰줘야 한다.

[CS-한 권으로 끝내는 네트워크 기초] 6장. 네트워크 설계와 구축

mellowg — Tue, 3 Dec 2024 16:58:27 +0900

6장. 네트워크 설계와 구축

6.1. 네트워크를 설계﹒구축할 때 할 일

6.1.1. 시스템 개발과 네트워크 설계﹒구축의 관계

네트워크 설계는 처음에 그 시스템이 무엇을 하는 시스템인지 생각하는 것부터 시작한다.

대전제는 '그 시스템은 무엇을 하는 시스템인가?'를 생각하는 것이다. 거기에서 더 나아가 어떤 네트워크가 필요한지 생각한다.

시스템 구성에 따라 필요한 네트워크 구성도 달라진다. 예를들어, 웹 브라우저로 조작할 수 있는 일정 관리 앱을 만들고 싶다고 가정한다. 웹 애플리케이션 A를 회사 내에서만 사용하고 싶다면 사내 랜상에 웹 서버와 DB서버를 구축해서 설치해야 한다. 사용자 규모에 따라서는 웹 서버와 DB 서버를 서버 한 대에서 동작시킬 수도 있다.

한 권으로 끝내는 네트워크 기초 129p

웹 애플리케이션 A를 SaaS로 제공하고 여러 회사에서 인터넷으로 이용하려면, 웹 서버는 인터넷에 공개하지만, DB 서버는 보안 관점에서 인터넷을 거치지 않고 웹 서버와 통신해야 한다.

또 SaaS로 제공하는 경우 사내에서 이용할 때보다 부하가 걸려 더 높은 가용성이 요구된다.

따라서 웹 서버는 한 대가 아니라 여러 대를 준비해서 서버에 집중되는 부하를 분배하거나, DB 서버도 여러 대에 동일한 데이터를 보유하여 데이터 손상이 일어나지 않도록 해야 한다.

한 권으로 끝내는 네트워크 기초 130p

이처럼 어떤 시스템을 만드는지 어느 정도 규모인지에 따라 필요한 네트워크 형태가 달라진다. 시스템 요구사항에 맞는 네트워크를 결정하고 만드는 것이 네트워크를 설계하고 구축할 때 중요하다고 할 수 있다.

6.1.2. 네트워크 설계와 구축(물리 인프라 편)

네트워크 설계의 각 프로세스는 시스템 설계와 크게 다르지 않다. 먼저 요건을 정의하고 어떤 시스템을 만들지, 그 시스템을 위해 어떤 네트워크를 만들지를 결정한 후 그 내용에 따라 기본 설계와 상세 설계를 한다.

기본 설계에서는 요건 정의에서 결정한 내용을 바탕으로 네트워크를 구축하면서 기본적인 사항을 정리한다. 상세 설계에서는 기본 설계에서 정리한 내용을 기반으로 '어떤 기기(서비스)를 사용하여 만드는가' 처럼 구현 방식의 세부 사항을 담는다. 이들 설계는 설계 리뷰를 거쳐 다듬은 후 구축 단계에 들어간다.

요건 정의 - 기본 설계 - 상세 설계 - 설계 리뷰

웹 애플리케이션 A를 SaaS로 제공하는 경우를 예로 들어 구축해보자.

현재 데이터 센터에 랙(전용 선반)을 빌리고 서버와 네트워크 장비를 구입하고 인터넷 회선도 계약한 상태이다. 대략 네트워크 구성을 정했으면 네트워크 구성도로 나타내본다.

네트워크 구성도에는 물리 설계도와 논리 설계도가 있다. 물리 설계도에는 네트워크 기기가 포트별로 어디로 접속하는지와 기록한 포트 표나 랙의 어느 위치에 어떤 기기를 넣을지 기록한 랙 구성도, 케이블을 연결할 곳, 종류, 색 등 정보를 정리한 케이블 결선 표 등이 있다.

물리 설계도에 따라 네트워크 기기와 서버를 랙에 마운트하고 네트워크 케이블이나 전원 케이블 등을 연결한다.

논리 설계도에서는 네트워크 회선의 랜간 라우팅이나 방화벽 규칙 설정, 어드레싱 등을 실시하고, 설계한 내용을 그림으로 나타낸다.

한 권으로 끝내는 네트워크 기초 133p

현장에서 직접 랙에 마운트한 기기에 네트워크를 설정할 수 있고, 네트워크가 미리 설정된 기기를 데이터 센터에 보내고 현장에서는 동작만 확인하는 경우도 있다.

6.1.3. 네트워크 설계와 구축(클라우드 서비스 편)

이번에는 클라우드(IaaS)를 사용하여 같은 방식으로 네트워크를 구축해보자. AWS환경에서 구축하는 경우를 예로든다.

IaaS에서는 사업자가 제공하는 가상화 기반에 시스템을 구축한다. 서버와 네트워크 모두 가상으로 만들어진다. 물리 네트워크는 사람이 기기 설치나 초기 설정 등을 수작업으로 해야 하지만, 클라우드에서는 기기 설치를 대신하여 인스턴스(AWS에서는 가상 서버를 '인스턴스'라고 함) 생성, 초기 설정 같은 모든 작업을 웹 브라우저의 제어판에서 할 수 있다.

IaaS에서 시스템을 구축하는 흐름은 다음과 같다.

서브넷 생성
가상 서버 생성
보안 그룹 설정
Elastic IP 설정

차례대로 살펴보자.

1️⃣ 서브넷 생성(퍼블릭 서브넷, 프라이빗 서브넷)

AWS에서는 서브넷 단위로 네트워크 세그먼트를 나누어 작성한다. 구체적으로는 인터넷에 공개한느 서버를 두는 서브넷(퍼블릭 서브넷)과 인터넷에 공개하지 않는 서버를 두는 서브넷(프라이빗 서브넷)을 생성한다.

가용성을 생각해서 각 서버를 가용 영역(availability zone)(데이터 센터에 해당) 2개로 나누어서 배치하고 각 가용 영역에 퍼블릭 서브넷과 프라이빗 서브넷을 2개씩 총 4개를 배피한다.

2️⃣ 가상 서버(인스턴스) 생성

AWS에서는 가상 서버를 인스턴스라고 한다. 여기에서는 EC2 서비스를 이용하여 웹 서버의 인스턴스를 생성한다. 또 RDS라고 하는 DB 서버 전용 인스턴스를 만들 수 있는 서비스도 있기 때문에 DB서버의 인스턴스는 이곳을 통해서 생성한다.

3️⃣ 보안 그룹 설정

AWS에는 보안 그룹이라는 서버에 연결하는 방화벽과 같은 것이 있다. 필요한 포트만 외부에서 보내는 통신을 통과하도록 작성해서 인스턴스에 할당한다.

4️⃣ Elastic IP설정

Elastic IP란 인스턴스에 결합하는 고정 글로벌 IP이다. 외부에 공개할 웹 서버 인스턴스로 설정한다.

가상화 기반에 설정하는 것이므로 물리적인 작업이 발생하지 않는다. 설정 작업은 웹 브라우저에서 완결된다. 명령어나 정의 파일을 이용함으로써 정형화 및 자동화할 수도 있다.

클라우드는 매우 편리하지만, 물리적인 시스템의 네트워크 구조나 원리 원칙을 이해해야 더욱더 폭넓게 대응하는 엔지니어가 될 수 있다.

6.2. 웹 신뢰성을 높이는 기술

6.2.1. 웹 신뢰성이란?

시스템에 장애가 발생해도 서비스를 지속해서 제공하는 것이 중요하며, 이런 사고방식을 장애 대응 설계(design for failure)라고 한다.

- 로드 밸런싱(처리 분배)

6.2.2. 대칭 키 암호 방식과 공개 키 암호 방식

통신을 할 때 보내는 삶과 받는 사람 사이에서 누군가가 통신 내용을 도청할 수도 있다. 그래서 제삼자가 보더라도 알 수 없도록 암호화할 필요가 있다. 암호화된 것을 원래대로 되돌려서 읽을 수 있는 상태로 만들려면(복호화) 열쇠가 필요하다.

암호화와 복호화 메커니즘에는 세 가지 방식이 있다.

1️⃣ 대칭 키 암호 방식

대칭 키 암호 방식이란 암호화와 복호화에 같은 키(대칭 키)를 이용하는 방식이다. 이 방식은 집 문을 여닫을 때 같은 키를 사용하는 것과 비슷하다. 파일 암호화 등에 자주 이용되는 방식으로, 프로세스는 아래와 같다.

1. 수신자가 발신자에게 키를 건네주고, 수신자도 같은 키를 가지고 있다.

2. 발신자는 암호 키로 암호화한 파일을 수신자에게 보낸다.

3. 수신자는 가지고 있던 같은 키로 파일을 복호화한다.

대칭 키 암호 방식의 문제점은 키를 안전하게 교환하기가 어렵다는 것이다.

2️⃣ 공개 키 암호 방식(비대칭키 암호화 방식)

공개 키 암호 방식은 암호화와 복호화에 별도의 키를 사용하는 방식이다.

암호화에 사용되는 것은 공개 키, 복호화에 사용되는 것은 비밀 키라고 한다.

1. 수신자가 발신자에게 공개 키를 건네준다.

2. 발신자는 공개 키로 암호화한 파일을 수신자에게 보낸다.

3. 수신자는 비밀 키로 파일을 복호화한다.

이 방식은 공개 키로 암호화한 데이터를 복호화할 수 잇는 것은 비밀키를 가진 사람뿐이라는 것이 핵심이다. 키 교환이 간편하고, 암호화가 필요한 데이터를 처리하기 전에 키를 배포하고 취득할 수 있다.

3️⃣ 두 가지 방식을 함께 사용

웹 사이트 암호화에 사용되는 SSL/TLS 통신은 대칭 키 암호 방식과 공개 키 암호 방식을 함께 사용한다.

1. 클라이언트가 서버로 접속 요청

2. 서버가 클라이언트에게 공개키 제공

3. 클라이언트에서 통신용 대칭키를 생성

4. 생성된 대칭키를 서버의 공개키를 활용하여 암호화

5. 암호화된 공개키를 서버로 전송

6. 서버에서 비밀키로 복호화

7. 대칭키를 기반으로 암호 통신을 진행

SSL/TLS 통신을 시작할 때 서버가 클라이언트에 공개 키를 전달하는데, 인증 정보나 공개 키 정보를 하나로 모은 것이 SSL/TLS 서버 인증서 이다. 서버는 SSL/TLS 서버 인증서로 클라이언트에 인증 정보나 공개 키 정보를 세트로 건네주고, 클라이언트는 건네받은 SSL/TLS 서버 인증서로 접속 상대의 정보를 확인하고 통신한다.

6.2.3. 상시 SSL화

상시 SSL/TLS 화란 웹 사이트 전체를 HTTPS화(암호화)하는 것이다. 보통 상시 SSL화라고 하는 경우가 많다.

실제 프로토콜은 SSL의 진화형인 TLS를 상요하지만, 일반적으로 알려진 용어가 SSL이므로 SSL/TLS를 단순히 SSL로 부른다.

이전에는 웹 사이트 전체를 암호화하려면 느려진다는 인식이 일반적이었으나, 최근에는 다음과 같은 이유로 상시 SSL화가 권장되는 추세이다.

1️⃣ HTTP/2에서는 표시 속도가 오히려 빨라진다.

HTTP/2 라는 새로운 프로토콜에서는 이전 HTTP 버전의 문제점이 개선되어 통신 효율이 높아졌다. 클라이언트와 서버 사이의 통신을 암호화하는 사양이 표준으로 정해져 있어 HTTP/2에 대응하려면 상시 SSL화가 필요하고, 이로써 응답 속도 향상을 기대할 수 있다.

2️⃣ SEO의 장점이 있다.

SEO(Search Engine Optimization)는 검색 엔진 최적화로 번역되며, 검색 결과에서 웹 사이트가 좀 더 상위에 표시되게 하는 일련의 대책을 SEO 대책이라고 한다. 오늘날 검색 엔진의 점유율은 구글이 앞도적으로 우위에 있으며, 구글에서는 상시 SSL화를 검색 결과의 평가 기준 중 하나로 삼고 있으며, SEO 대책의 일환으로 상시 SSL화가 되기도 한다.

3️⃣ HTTP일 때 웹 사이트를 열면 현재 웹 브라우저에 경고가 표시된다.

HTTP 웹 사이트를 열면 주소창에 '주의 요함'이라는 경고가 표시된다. 크롬 56부터는 HTTP 페이지에 ID나 패스워드 같은 기밀 정보를 입력하는 폼이 있을 때 보안 경고가 표시되었지만, 지금은 HTTP 웹 사이트 모두에서 경고가 표시된다.

6.2.4. 부하 분산

웹 사이트의 내장애성이나 처리 능력을 높이고자 웹 서버 한 대가 아니라 여러대로 웹 사이트를 호스팅하기도 한다. 이 경우 액세스를 분산해서 할당하는 것을 부하 분산이라고 한다.

DNS 서버 설정이나 전용 기기 및 소프트웨어의 도입, 서비스 등을 이용하여 부하 분산할 수 있다.

1️⃣ DNS 라운드 로빈

DNS 라운드 로빈은 DNS 시스템을 사용해서 요청을 서버 여러 개로 분산하는 방식이. 한 호스트 이름에 IP주소를 여러 개 설정함으로써 요청받은 DNS 서버는 차례대로 IP주소를 반환한다.

DNS 라운드 로빈은 특별한 장비나 소프트웨어를 쓰지 않고도 부하를 분산할 수 있다. 그러나 단점도 존재한다.

DNS 서버가 각 서버를 모니터링해서 동적으로 할당하는 것은 아니기 때문에 다운된 서버의 IP를 반환하는 경우가 있다. 또 서버의 부하 상태와 상관없이 균등하게 할당되므로 처리 능력이 낮은 서버와 처리 능력이 높은 서버에 고르게 할당되면 퍼리 능력이 저하된 서버는 처리 한계에 도달할 가능성도 있다.

2️⃣ NAT형

NAT형이란 VIP라는 가상 IP 주소에 대한 요청을 실제 서버 여러 대에 할당하는 방식이다.

하드웨어/소프트웨어 등으로 제공되는 일반적인 로드 밸런서(L4 스위치/L7 스위치라고도 함)에서 채용된다.

3️⃣ GSLB

글로벌 서버 로드 밸런싱(Global Server Load Balancing)은 여러 위치를 가로지르는 부하 분산을 실현하는 방식이다.

예를 들어 서울과 부산에 있는 데이터 센터에 서버를 설치하고 정상일 때는 양쪽 모두에 요청을 할당하고, 어느 한쪽에 장애가 발생했을 때는 장애가 일어난 데이터 센터 쪽 서버에는 할당하지 않게 하는 등 DNS 라운드 로빈에서 문제였던 '장애가 발생한 서버에도 할당할 수 있는 문제점'을 해결하였다.

이처럼 여러 서버에서 서비스를 제공함으로써 가용성과 성능을 향상시키거나 재해나 장애를 대비하는 등 부하 분산은 웹 사이트 신뢰성 향상에 연결된다.

6.2.5. 리버스 프록시

리버스 프록시란 웹 서버 대신에 클라이언트의 액세스를 받는 프록시 서버의 일종디ㅏ. 보통 웹 사이트와 동일한 네트워크에 설치된다.

프록시란 대리나 대행이라는 뜻으로, 프록시 서버는 클라이언트 쪽에 설치되어 클라이언트가 웹 서버에 액세스하는 것을 중계하는 역할을 한다. 즉 웹서버에 액세스 하는 것을 대행한다.

리버스 프록시는 서버 쪽에 설치되어 서버에 대한 요청을 받아 배후에 있는 서버에 넘겨주는 데 사용된다. 즉, 웹 서버가 받을 요청을 대신해서 받는다.

프록시 서버와 리버스 프록시 서버는 모두 캐시 기능을 제공한다. 이미 요청이 있었던 것을 일정 시간 캐시해 두고, 캐시에 일치하는 것은 웹 서버 대신에 프록시 서버(리버스 프록시)가 응답한다. 이렇게 함으로써 웹 서버의 대한 부담을 줄일 수 있다.

리버스 프록시는 캐시 기능 이외에도 부하 분산 기능, WAF7를 제공하여 웹 사이트의 신뢰성 향상에 기여한다.

6.2.6. CDN

CDN(Content Delivery Network)은 동일한 콘텐츠를 많은 배포처, 예를 들어 많은 사용자의 PC나 휴대 전화에 효율적으로 배포하고자 할 때 사용된다. 주로 웹 사이트에 있는 많은 이미지나 동영상 등 용량이 큰 데이터를 많은 서버와 네트워크 대역을 이용하여 클라이언트에 전달하는 데 사용된다. 또한 윈도우와 휴대 전화 운영 체제 업데이트 등도 CDN을 이용하여 효율적으로 전송할 수 있다.

배포처에 가까운 네트워크(커스터머 에지)에 콘텐츠를 배포하는 서버(에지 서버)를 배치해서 구성한다. 에지 서버는 원본 데이터를 가진 서버(오리진 서버)의 데이터 사본을 캐시로 가지고 있다가, 오리진 서버를 대신해서 클라이언트 요청에 응답한다.

사용자 가까이에 있는 서버에서 배포하고, 또 서버 여러 대에서 배포함으로써 더 빠르고 부하에 강한 시스템을 실현했다.

효율적인 배포 외에 DDos 공격에 대한 대책으로도 사용된다.

아래는 대표적인 CDN 서비스이다.

Akamai

엔터프라이즈급 CDN으로 유명하다.

Amazon CloudFront

AWS 서비스 중 하나로 제공되는 CDN 서비스이다.

Cloudflare

주로 개인용으로 무료 플랜이나 소액 플랜을 갖춘 것으로 알려진 CDN 서비스이다. CDN을 기본으로 하면서 보안이나 DDos 공격 대책에 사용한다.

Fastly

다른 CDN에서는 어렵다고 여기는 동적 콘텐츠 캐시 등 독자적인 기능을 제공하는 CDN 서비스이다.

Imperva Incapsula

CDN기능도 있지만, WAF, DDos 공격에 대응하는 측면으로도 강한 서비스이다.

[CS-한 권으로 끝내는 네트워크 기초] 5장. 인터넷 서비스의 기반

mellowg — Tue, 3 Dec 2024 15:23:14 +0900

5장. 인터넷 서비스의 기반

5.1. 클라우드와 네트워크의 관계

5.1.1. 클라우드와 네트워크

클라우드(클라우드 컴퓨팅)는 컴퓨터를 이용하는 형태 중 하나로, 인터넷 등 네트워크를 통해 서버가 제공하는 서비스를 주의 기기(컴퓨터, 휴대전화 등)를 통해 이용하는 것을 의미한다.

컴퓨터 세계에서 클라우드라는 단어는 복잡하게 연결되는 인터넷을 구름에 비유하여 표현하는데에서 시작되었다.

5.1.2. 클라우드의 종류

클라우드는 제공 범위에 따라 몇 가지로 분류된다. IaaS(Infrastructure as a Service)는 컴퓨터나 네트워크를 가상으로 만들어서 이용하는 형태이다. PaaS(Platform as a Service)는 데이터베이스나 애플리케이션을 실행할 수 있는 환경 등을 서비스로 제공하는 형태이다. IaaS와 조합해서 이용하는 경우도 많다.

한 권으로 끝내는 네트워크 기초 113p

SaaS(Software as a Service)는 완제품 소프트웨어를 네트워크로 서비스하는 형태이다.

한 권으로 끝내는 네트워크 기초 114p

소프트웨어를 구입해서 이요할 때와 차이점은 아래 표와 같다.

구분	요금 체계	제공 범위	이용 방법	버전 업
패키지 소프트웨어	제품 구매	소프트웨어 사용권	컴퓨터에 소프트웨어 설치	새 버전 구매
SaaS	월 또는 연간 요금	소프트웨어 및 서비스	인터넷을 경유해서 이용	자동으로 업데이트

IaaS, Paas, Saas 차이점

5.1.3. 클라우드의 편의성

클라우드가 없던 시절에는 새로운 인터넷 서비스를 시작하려면 우선 서버로 사용할 컴퓨터를 사거나 빌려야만 했다. 그렇기에 초기 투자가 필요했고, 실제로 사용하기까지 시간이 걸렸다. 또한, 서비스가 확대되면 이에 맞춰 컴퓨터 자원을 확장시켜야 했으며 즉각적으로 늘릴 수도 없었다. 그리고 서비스를 중단하면 소유하던 컴퓨터가 남게된다.

클라우드는 이러한 문제를 해결한다.

- 곧바로 사용한다 : 웹 브라우저에서 서버를 생성할 수 있고, 명령어로 자동화할 수도 있다.

- 사용한 만큼만 돈이 든다 : 초기 비용이 들지 않고 시간 단위로 과금된다.

- 쉽게 늘리고 줄일 수 있다 : 소유하지 않고 사용한다.

이처럼 '소유'에서 '이용'으로 변화함에 따라 편리함을 누릴 수 있게 되었다.

5.2. 클라우드 서비스와 호스팅 하우징

5.2.1. 대표적인 클라우드 서비스

Amazon Web Services

아마존 웹 서비스(AWS, Amazon Web Service)는 아마존이 제공하는 클라우드 플랫폼(IaaS, PaaS)이다. 아마존은 매우 많은 서비스를 제공하는 것으로 유명하며, 그중에서도 대표적인 것은 EC2(가상 서버), S3(오브젝트 스토리지), RDS(관계형 데이터베이스 서비스) 등이다.

Microsoft Azure/Microsoft 365

마이크로소프트 애저(Microsoft Azure)는 마이크로소프트가 제공하는 클라우드 플랫폼(IaaS, PaaS)이다. 또한 마이크로소프트는 애저 외에도 Microsoft 365라는 오피스 제품의 구독 서비스(SaaS)를 제공한다.

마이크로소프트는 전통적으로 오피스 스위츠나 기업용 서버에 강하며, 애저와 Microsoft 365의 매출을 합산하면 클라우드 서비스의 매출이 세계 1위이다.

Google Cloud Platform

구글 클라우드 플랫폼(GCP, Google Cloud Platform)은 구글이 제공하는 클라우드 플랫폼(IaaS, PaaS)이다. 구글 내부에서 사용하는 것과 동일한 서비스 플랫폼을 제공하는 것이 특징이다. 다른 클라우드 플래솦ㅁ과 마찬가지로 가상 서버나 객체 스토리지, 관계형 데이터베이스 서비스를 제공하는 한편, 쿠버네티스(Kubernetes)의 개발원이라는 점에서 컨테이너용 플랫폼 서비스에 강하다.

Firebase

파이어베이스(Firebase)는 2011년에 파이어베이스사가 개발한 서비스로, 2014년에 구글에 인수되어 현재 GCP 기능 중 하나로 자리잡았다. Mobile Backend as a Service(mBaaS)로 부르는 서비스로 데이터베이스, 스토리지, 메시징 등 모바일 애플리케이션에 필요한 기능을 서버로 의식하지 않고 사용할 수 있는 것이 특징이다.

Heroku

헤로쿠(Heroku)는 Platform as a Service(PaaS)로 웹 서버나 데이터베이스 같은 웹 서비스를 공개하는 데 필요한 모든 것을 미리 준비해 주는 서비스이다. 서버, OS, 데이터베이스, 프로그램 실행 환경 등 웹 애플리케이션을 공개하는 데 필요한 기능을 세트로 제공하는 것이 특징이다.

KT 클라우드

통신 사업자이자 데이터 센터 사업자인 KT의 클라우드 인프라 서비스는 가격면에서 경쟁력이 있다. 국내 클라우드 제공사 중 매출 규모가 가장 크고, 공공 기관 전용 클라우드 서비스인 G-클라우드를 출시하고 헌법 재판소 등 다수 공공 기관에 클라우드 서비스를 제공하며 사업 영역을 확대하고 있다.

네이버 클라우드 플랫폼

라인, 네이버 웹툰 등 자회사들이 네이버 클라우드 플랫폼을 이용하고 있고, SK텔레콤, LG U+등 대기업도 네이버 클라우드 플랫폼 서비스를 도입했다. 국내 사업자 중 최대 보안 인증을 확보하여 공공 기관 전용 서비스를 출시하는 등 일반 기업 이외에도 공공, 금융, 의료 분야로도 사업 영역을 확대하고 있다.

5.2.2. 호스팅, 하우징

호스팅은 호스팅 사업자가 서버를 보유하고 사용자에게 대여하는 서비스를 총칭한다. 호스팅에는 렌탈 서버, 전용 서버, VPS(Virtual Private Server)등이 있다.

렌탈 서버는 물리 서버 한 대를 여러 사용자가 함께 사용하는 형태이다. 사용자들은 서버의 하드웨어 리소스뿐만 아니라 OS도 함께 사용한다. 이 때문에 렌탈 서버에서는 애플리케이션을 직접 설치할 수 없고, 렌탈 서버에서 제공하는 웹 서버나 애플리케이션이 동작할 수 있는 환경 및 데이터베이스를 이용한다. 각 사용자의 데이터는 논리적으로 분리되어 있어 다른 사용자의 데이터는 볼 수 없다.

전용 서버는 물리 서버 한 대를 점유할 수 있는 서비스이다. 한 대를 통째로 자신의 서버로 사용할 수 있으므로 다른 사용자의 부하 영향을 받지 않고 OS나 애플리케이션도 자유롭게 설치할 수 있다.

VPS는 렌탈 서버와 전용 서버의 장점을 취한 서비스로, 물리 서버 한 대를 여러 사용자가 공용하지만 가상화 기술을 이용해서 가상 서버를 물리 서버 안에 많이 만들 수 있다. VPS에서 제공되는 환경은 전용 서버와 동일하고, OS 및 애플리케이션을 자유롭게 설치할 수 있다.

호스팅 서비스는 서비스 제공 사업자가 물리 서버의 하드웨어 유지 보수 및 운용을 한다.

하우징은 데이터 센터 사업자가 랙(전용 선반)을 대여해 주고, 랙 안에 사용자가 직접 구매한 네트워크 기기나 서버 등을 탑재한다. 경우에 다라서는 사용자가 네트워크 회선을 끌어올수 있는 서비스도 있다.

5.3. 네트워크와 애플리케이션

5.3.1. 일반적인 웹 DB 시스템

대표적인 콘텐츠 관리 시스템(CMS, Content Management System)인 워드프레스 환경을 예로 들어 네트워크 애플리케이션이 어떻게 구성되는지 살펴보자.

워드프레스를 동작시키려면 웹 서버와 DB서버가 필요하다. 그리고 워드프레스는 PHP로 만들어졌기 때문에 PHP 실행 환경도 필요하다.

5.3.2. 구성하는 소프트웨어

OS

프로그램을 실행하려면 우선 기반이 되는 OS가 필요하다. OS에는 다음과 같은 것들이 존재한다.

윈도우(Windows)

마이크로소프트에서 개발한 OS로, 개인용 컴퓨터에서 압도적인 점유율 보유하며, 서버 용도로는 윈도 서버(Windows Server) 에디션이 있다.

리눅스(Linix)

리눅스는 주로 인터넷을 위한 서버 용도로 널리 사용되는 OS이다. 리눅스는 비영리 커뮤니티에서 개발한 것이 특징으로, 무료로 사용할 수 있는 배포판, 기업이 서비스를 제공하는 대신 라이선스를 사서 이용하는 배포판 등 여러 종류가 있다.

맥오에스(macOS)

애플에서 만드는 컴퓨터인 Mac 시리즈에 탑재되는 OS로 예전에는 서버 용도로 사용했지만, 현재는 일반 컴퓨터용으로만 사용한다.

웹 서버 소프트웨어

웹 서버는 OS에 웹 서버 소프트웨어를 설치하고 동작시켜 서버 기능을 한다. 웹 서버 소프트웨어로는 다음과 같은 것들이 있다.

아파치(Apache)

Apache의 정식 명칭은 Apache HTTP Server이지만, 보통 아파치라고 한다.

전 세계에서 가장 많이 사용하는 웹 서버 소프트웨어로, 대규모 상용 웹 사이트부터 개인용 서버까지 폭넓게 이용된다.

엔진엑스(Nginx)

아파치보다 나중에 생긴 웹 서버로, 동작이 빠르고 기능이 풍부하여 최근 들어 채요 사례가 증가하고 있다.

IIS(Internet Information Services)

마이크로소프트의 웹 서버 소프트웨어로, 윈도나 윈도 서버 위에서 동작한다.

DB 서버 소프트웨어

MySQL

MySQL은 세계에서 가장 널리 사용되는 오픈소스 RDBMS이다.

MariaDB

MySQL에서 파생된 소프트웨어로, MySQL과 독립적으로 계속 개발하고 있는 DB Server의 하나이다.

오로라(Aurora)

AWS의 관계형 데이터베이스 서비스인 Amazon RDS 중에서 선택 가능한 RDBMS로, MySQL과 호환성을 강조하면서도 더 뛰어난 성능을 발휘하는 것이 특징이다.

PostgreSQL

오픈 소스 RDBMS이며, MySQL 다음으로 점유율이 높은 DB 서버 소프트웨어이다. PostgreSQL은 신뢰성을 중요시한다고 알려져 비웹 계열 시스템에서 채용하는 예도 많다.

Oracle

오픈 소스가 아닌 RDBMS로, RDBMS 시장 점유율이 가장 높은 상용 DB 서버 소프트웨어이다.

프로그래밍 언어

PHP

동적 웹 페이지 생성 툴을 기원으로 한 프로그래밍 언어로 웹 애플리케이션 개발에 유용한 기능이 풍부하게 들어 있는 것이 특징이다.

Ruby

일본에서 개발된 프로그래밍 언어로, Ruby on Rails라는 웹 애플리케이션 프레임워크를 사용하여 복잡한 웹 애플리케이션을 개발한다.

ASP.NET

프로그래밍 언어가 아니라 웹 애플리케이션 프레임워크의 명칭이다. 비주얼 베이직(Visual Basic)이나 C# 등 주로 마이크로소프트가 제공하는 프로그래밍 언어를 사용할 수 있다.

어떤 OS, 어떤 웹 서버 소프트웨어, 어떤 DB 서버 소프트웨어, 어떤 프로그래밍 언어를 선택할지는 조건에 따라 달라진다.

워드프레스는 DB서버 소프트웨어로 MySQL, 프로그래밍 언어로 PHP를 사용하므로 이 두가지는 고정되어 있다. 그러나 OS나 웹 서버 소프트웨어에 대해서는 특별히 정해진 바가 없다.

시스템을 구축하고 운용하는 엔지니어가 보유한 스킬에 따라 선택하는 것이 일반적이다.

그 밖에 고려할 수 있는 요소는 비용이다. 상용 제품을 사용하는 WISA와 비교하면 LAMP, LEMP는 OSS를 사용하므로 비용을 절감할 수 있다.

[CS-한 권으로 끝내는 네트워크 기초] 4장. 네트워크 장비의 종류

mellowg — Thu, 28 Nov 2024 05:45:35 +0900

4장. 네트워크 장비의 종류

4.1. 연결을 위한 네트워크 장비

4.1.1. 라우터

라우터는 쉽게 말해서 네트워크와 네트워크를 연결하는 것이다. 가정이나 소규모 사무실의 라우터를 생각해보자. 가정이나 소규모 사무실에서 라우터는 컴퓨터 여러 대로 회선 하나를 함께 사용하는 기능을 제공한다.

컴퓨터를 인터넷 회선에 직접 연결하면 연결된 컴퓨터만 외부 네트워크에 접속할 수 있다. 라우터를 이용하면 여러 대의 컴퓨터는 물론, 휴대 전화나 태블릿 등도 인터넷 회선을 공용하여 외부 네트워크에 접속할 수 있다.

라우터에 연결할 때 유선 랜뿐만 아니라 무선 랜을 사용하는 경우도 있다.

회선으로 접속하는 외부 네트워크로 인터넷을 가장 쉽게 생각할 수 있다. 소규모 사무실도 거점이 많은 회사의 한 거점이 될 때는 다른 거점과 VPN으로 접속하기도 한다.

또 라우터에는 DHCP 서버기능이 있어 정해진 범위 안에서 컴퓨터에 IP 주소를 할당하여 충돌이 일어나지 않게 관리한다. 네트워크에 따라서는 DHCP 서버 기능을 사용하지 않고, 모든 IP를 수동으로 관리하는 경우도 있다.

4.1.2. 스위치

L7스위치는 응용 계층의 내용까지 해석해서 데이터를 배분한다. 특정 사용자와 서버의 연결(세션)을 유지하는 기능은 L7 스위치가 구현한다.

4.2. 방어를 위한 네트워크 기기

4.2.1. 방화벽과 UTM

방어를 위한 네트워크 기기로 대표적인 것이 방화벽(firewall)이다. 방화벽은 네트워크가 연결되는 장소에서 통과시켜서는 안되는 통신을 차단하는 시스템이다.

방화벽이 발전한 형태가 UTM(Unified Threat Management)이다. UTM이란 방화벽, VPN, 안티바이러스, IDS/IPS, 콘텐츠 필터링, 안티스팸, 애플리케이션 컨트롤 등의 기능을 한 기기에서 한꺼번에 제공하는 것이다. 이를 시큐리티 어플라이언스 제품이라고도 한다.

나중에 나오는 WAF(Web Application Firewall)는 조금 성격이 다른 보안 제품이기 때문에 UTM에 포함되지 않는 경우가 많다.

** 콘텐츠 필터링은 데이터 손실을 방지하고자 특정 유형, 파일, 프로토콜 명령 등에 기반하여 트래픽을 차단한다.

방화벽 기능 자체는 지금도 유용하지만, 좀 더 다각적으로 위협에 대처하고자 UTM이 만들어졌다. 최근에는 통신을 애플리케이션 단위로 제어하는 기능을 가진 것도 있다.

예시

웹 사이트와 사용자 속성에 근거한 통신 제어
- 예) 마케팅 부서의 SNS에 대한 참조와 투고는 허가하고, 타 부서의 참조와 투고는 금지한다.
웹 사이트와 행동에 근거한 통신 제어
- 예) 웹 메일에서 파일 첨부를 금지한다.
웹 브라우저를 사용하지 않는 HTTP/HTTPS 통신 제어
- 채팅앱이나 파일 교환앱의 통신을 차단한다.

최근에는 많은 애플리케이션이 웹을 기반으로 동작하며, 웹 애플리케이션 이외에도 통신에 HTTP/HTTPS를 이용하는 사례가 증가한 것이 이런 기능이 등장한 배경이다. 따라서기존 프로토콜 기반의 패킷 필터링으로 할 수 없는 제어를 하여 보안을 강화할 필요가 있다.

4.2.2. WAF(Web Application Firewall)

WAF는 웹 사이트의 앞쪽에 배치하여 웹 사이트 및 웹 애플리케이션 등을 노린 공격을 방어하는 보안 대책이다.

WAF로 방어할 수 있는 주된 공격으로는 SQL 인젝션이나 XS, 패스워드 리스트 공격 등을 들 수 있다. WAF 종류에는 다음과 같은 것들이 있다.

어플라이언스 WAF

하드웨어 어플라이언스를 설치하는 형태의 WAF이다.

소프트웨어 WAF

서버에 소프트웨어를 설치하고 운영하는 형태의 WAF이다. (1)웹 서버에 직접 설치하고 운영하는 것과 (2)웹 서버와는 별도의 서버에 설치하여 리버스 프록시로 운영하는 것이 있다.

클라우드형 WAF

클라우드 서비스로 제공되는 형태의 WAF이다. 웹 사이트에 대한 액세스는 일단 클라우드형 WAF를 경유하여 웹 서버에 도달한다.

WAF를 이용할 때 주의

모든 WAF에서 공통인 것은 도입할 때 사전 검증을 철저히 하는 것이다. 도입 후에도 애플리케이션이 정상적으로 동작하는지, 응답에는 문제가 없는지 등을 확인해야 한다.

4.2.3. IDS/IPS

IDS(Intrusion Detection System)(침입 탐지 시스템)와 IPS(Intrusion Prevention System)(침입 방지 시스템)는 네트워크에서 침입을 탐지하고 방지하는 데 이용되는 시스템이다. 모두 보호 대상에 대한 침입을 탐지하는 데 사용된다.

IDS는 '탐지'와 '통지'를 하고, IPS는 '탐지'와 '통지' 및 '방지'를 한다고 할 수 있다. 이 둘을 거의 구별하지 않고 IDS/IPS 처럼 병기하는 경우도 많다.

IDS/IP의 탐지 방법에는 시그니처(signature)형과 어노멀리(anormaly)형 두 종류가 있다.

시그니처형이란 알려진 공격 패턴 등 비정상적인 통신 패턴을 데이터베이스에 보관하고, 통신 내용이 일치하는 경우에 비정상으로 판단하는 탐지방법이다.

어노멀리형은 반대로 정상적인 통신 패턴을 데이터베이스에 보관하고, 통신 내용이 비정상이라고 의심되는 경우에 부정으로 판단하는 탐지 방법이다.

시그니처형은 비정상인 패턴을 매칭하므로 오탐지가 적지만, 데이터베이스에 등록되지 않은 알려지지 않은 부정 액세스 패턴은 탐지할 수 없는 단점이 있다.

어노멀리형은 미지의 공격도 어느 정도 탐지할 수 있다는 장점이 있지만, 시그니처형보다 오탐지가 많아진다는 단점이 있다.

4.2.4. 각각의 관계성

방화벽은 3계층/4계층 수준에서 방어하는 기본적인 보안 시스템이고, IDS/IPS는 좀 더 애플리케이션에 가까운 방어를 주로 하는 등 각각 특성이 다르다. 따라서 필요에 따라 같이 사용하는 것이 좋다.

방화벽은 가장 기본적인 보안 시스템으로 반드시 사용한다.
IDS/IPS는 필요에 따라 이용 여부를 결정한다.

방어 대상이 웹 애플리케이션이라고 확실히 정해져 있다면 WAF를 병용하는 것도 고려한다.

4.3. 소프트웨어로 조작하는 네트워크

4.3.1. SDN

SDN(Software Defined Network)이란 소프트웨어를 이용하여 유연하게 정의할 수 있는 네트워크를 만드는 기술 혹은 그런 콘셉트를 의미한다.

물리적인 네트워크에서는 네트워크 기기나 서버를 추가하거나 네트워크 구성을 변경할 때 실제로 기기를 설치하거나 케이블을 꽂고 빼는 작업이 필요하다. 그리고 공유기와 스위치, 방화벽 등 설정도 각각 변경해야 한다.

SDN에서는 SDN컨트롤러라는 소프트웨어로 논리적인 네트워크를 한곳에서 집중 관리한다. 네트워크를 한곳에 모아서 관리하면 개별적으로 기기를 일일이 설정하지 않아도 되니 효율이 높아진다.

OpenFlow

SDN의 구체적인 구현으로 알려진 기술 중 하나가 바로 오픈프로(OpenFlow)이다. 기존 네트워크 기기에서는 경로 제어와 데이터 전송이 한 네트워크 장비로 구현되어 있다. 각각의 네트워크 기기가 설정에 따라 경로를 제어하고 데이터를 전송하면 부분적인 장애에 강하다는 장점이 있지만, 네트워크 전체에서 본 경로 선택이나 통합적인 관리가 어렵다는 문제점을 안고 있다.

오픈플로는 경로를 제어하는 오픈플로 컨트롤러와 실제 데이터를 전송하는 오픈플로 스위치로 구성되어 있으며, 네트워크를 전체적으로 보았을 때 경로 선택이나 통합적인 관리를 할 수 있다.

오픈플로를 구현하는 방식에는 오버레이 방식과 홉 바이 홉 방식 두 종류가 있다.

오버레이 방식은 가상 서버를 오픈플로를 지원하는 가상 스위치와 연결하여 물리 서버를 걸친 가상 랜을 구성하는 것이다. 기존 네트워크 기기 등을 활용하면서 도입할 수 있다는 장점이 있지만, 네트워크 전체를 보았을 때 세밀하게 경로를 제어할 수 없다는 단점이 있다.

홉 바이 홉 방식은 네트워크 기기도 오픈플로를 지원하는 기기를 이용함으로써 오픈플로가 지향하는 전체 기능을 활용하는 것이 목표이다.

4.3.1. SD-WAN

SD-WAN은 SDN을 랜뿐만 아니라 왠으로도 확대하려는 것이며, 소프트웨어로 자동화된 도입과 운용이 가능한 왠이다.

SD-WAN은 다음과 같은 세 가지 특징이 있다.

소프트웨어로 집중 관리
신규 거점 도입의 용이성
가상화 기반이나 IaaS형 클라우드와의 친화성

기존 왠은 기기마다 설정하여 접속했지만, SD-WAN은 SDN과 마찬가지로 소프트웨어 컨트롤러로 집중적으로 관리하는 것이 목표이며, 단일 관리 화면에서 각종 설정을 할 수 있다. 또 새롭게 접속 거점을 추가할 때도 현장에 네트워크 엔지니어가 가지 않고 도입할 수 있다.

[CS-한 권으로 끝내는 네트워크 기초] 3장. 웹을 구현하는 기술

mellowg — Thu, 28 Nov 2024 04:35:09 +0900

3장. 웹을 구현하는 기술

3.1 웹을 구성하는 구조

3.1.1. 웹과 네트워크

웹(web)은 World Wide Web(WWW)이라는 인터넷에서 제공되는 하이퍼텍스트 시스템이다. 인터넷이라는 표현은 흔히 웹을 가리키지만, 정확히 말해 웹은 인터넷의 한 기능일 뿐이다.

하이퍼텍스트란 문서 안에 다른 문서의 위치 정보를 포함시켜 정보를 서로 연관 지어(하이퍼링크) 참조할 수 있게 만든 문서이다. 이 개념을 인터넷상에서 실현한 것이 웹이다.

웹은 HTML로 대표되는 하이퍼텍스트 언어와 네트워크의 네트워크인 인터넷이 융합되어 탄생하였다.

당초에는 문자 정보만 주고받는 단순한 기술이었지만, 웹 서버에서 동작하는 애플리케이션이나 HTML 언어 자체의 사양이 확장되면서 이용 범위가 확대되었다. 지금은 전자상거래, 온라인 뱅킹, 게임, 동영상 서비스 등 다양한 용도로 활용된다.

3.1.2. 클라이언트와 서버

웹으로 제공되는 서비스 대부분은 서비스를 제공하는 쪽(서버)과 서비스를 받는 쪽(클라이언트)으로 나뉜다. 이를 클라이언트 서버 모델이라고 한다. 서버에 시스템을 설치하고 사용자는 클라이언트에서 서버에 액세스한다.

웹 서비스를 예시로, 서버는 그 역할의 성격상 유지 보수를 해야 하기 때문에 일시적으로 멈출 수 있지만, 기본적으로 언제든지 클라이언트 요구에 대응할 수 있도록 24시간 365일 가동해야 한다.

반면 클라이언트는 서비스를 이용할 때만 동작해야 한다. 사용하지 않을 때는 전원을 끌 수 있으며, 항상 동작하는 것은 아니다. 또 인간이 사용하므로 편의성이나 휴대성 같은 것을 고려해서 만들고 있다.

3.1.3. 웹 서버

웹은 클라이언트 서버 모델을 기반으로 하는 시스템으로, 정보 제공자가 웹 서버를 공개하고 사용자가 웹 브라우저를 통해 웹 서버에 있는 정보에 액세스 하는(브라우징) 형식을 기본으로 한다.

웹 서버는 정보를 전송하거나 서비스를 제공하려고 365일 계속해서 동작하는 컴퓨터를 의미한다. 아파치(Apache)나 엔진엑스(Nginx)처럼 컴퓨터상에서 웹 서버 기능을 제공하는 구체적인 애플리케이션을 가리켜 웹 서버로 지칭할 때도 있으니 주의해야 한다.

웹 서버의 가장 기본적인 역할은 웹 페이지를 공개하는 것이다. HTML로 작성된 문서를 인터넷에 공개하는 역할을 담당한다. 웹 서버에서 애플리케이션을 실행할 수 있는 CGI(Common Gateway Interface) 기술로 인터넷에서는 정보를 양방향으로 교환하게 되었다. 현재는 서버 사이드 언어나 데이터베이스 등과 연계하여 웹에서 많은 일을 할 수 있게 되었다.

3.1.4. HTTP와 HTTPS

HTTP는 서버와 클라이언트 사이에서 데이터를 주고받는 프로토콜이다. 웹이 처음 만들어질 당시에는 정보 공유를 목적으로 한 시스템이었기 때문에 통신 경로에서 정보를 감출 필요가 없었다. 그러나 이용 범위가 확대되면서 웹 서버에 데이터를 전송할 때는 암호화하여 정보 기밀성을 확보할 필요가 생겼다. 그래서 만들어진 것이 HTTPS 프로토콜이다.

HTTPS는 SSL/TLS 구조로 구현되었다. SSL(Secure Sockets Layers)과 TLS(Transport Layer Security)는 인터넷에서 통신을 암호화하여 제삼자가 통신 내용을 훔쳐보거나 조작할 수 없게 하는 기술이다.

SSL은 넷스케이프가 개발한 프로토콜이고, TLS는 SSL을 계승하여 IETF라는 표준화 조직의 TLS 워킹 그룹에서 책정한 프로토콜이다. 현재는 SSL 이 아닌 TLS가 사용되고 있어 TLS라고만 표기해도 되지만, 여전히 SSL 지명도가 높기 때문에 SSL/TLS로 병기하거나 그냥 SSL이라고 할 때도 많다.

3.1.5. SSL 인증서

SSL/TLS를 웹 사이트에서 이용하려면 SSL인증서가 필요하다. SSL 인증서란 인증 기관(CA, Certification Authority)이라는 신뢰할 수 있는 제삼자 기관이 이용자(도메인 소유자)에게 발행하는 것이다.

SSL 인증서의 역할

SSL인증서는 다음 세 가지 목적으로 이용한다.

데이터 암호화:
- SSL 인증서에 포함되는 공개 키를 사용함으로써 암호화 통신을 위한 비밀키를 안전하게 교환할 수 있고, 암호화 통신을 실현할 수 있다.
도메인 소유 증명:
- SSL 인증서로 해당 도메인은 A가 소유하는 도메인이라는 것을 제삼자인 인증기관에서 보증한다.
데이터 변조 방지:
- 제삼자 기관이 보증하는 인증서로 암호화된 통신은 변조되지 않고 확실하게 A의 정보임을 보증한다.

인증 기관 신뢰

인증 기관은 인증 기관 운영 규정이라는 문서를 공개하여 보안 정책을 규정하고, 본사를 둔 국가의 정부 등이 이 문서를 인증함으로써 우리는 인증 기관을 신뢰할 수 있다.

인증 레벨에 따른 종류

SSL 인증서는 인증 레벨에 따라 도메인 인증(DV), 기업 인증(OV), EV인증(EV) 세 가지로 나눌 수 있다. 모든 인증서가 SSL/TLS을 이용한 암호화 통신 기능을 제공하지만, 인증서를 발행하는 조직이 실제로 있는지를 증명하는 범위에는 차이가 있다.

도메인 인증(DV, Domain Validation)은 도메인에 등록된 등록자를 확인하고 발행하는 인증서이다. 도메인 소유만 확인할 뿐 도메인 및 인증서 소유자를 인증하는 것은 아니다. 발행 속도가 빠르고 가격이 저렴하여 개인 사이트뿐만 아니라, 기업체, 각종 미디어 등에 폭넓게 이용된다. 특히 개인정보나 신용 카드 정보 등 민감한 정보를 주고받지 않고, 검색 엔진 최적화(SEO, Search Engine Optimization) 이유로 항상 SSL을 적용해야 하는 웹 사이트에서 도메인 인증서를 많이 사용한다.
기업 인증(OV, Organization Validation)은 도메인과 더불어 웹 사이트를 운영하는 조직의 실재성을 인증하는 인증서이다. 인증서 발행처가 운영 조직의 실재성을 인증하기 때문에 개인 정보나 신용 카드 정보 등 민감한 정보를 주고받는 웹 사이트 등에 이용된다.
EV 인증(EV, Extrended Validation)은 기업의 실재성과 더불어 소재지를 인증한다. 인증서로 웹 사이트 운영 조직을 확인할 수 있다. 기업의 실재성을 인증한다는 점에서 기업 인증(OV)과 같다고 생각할 수 있다. 그러나 소재지 확인 등 더욱 엄격한 심사를 거치고 시각적으로도 확인할 수 있어 개인 정보나 신용 카드 정보 등 민감한 정보를 주고받는 웹사이트와 온라인 뱅킹 및 금융 기관과 연계되는 핀테크(Fintech) 서비스를 제공하는 웹 사이트 등에 이용된다.

	도메인 인증	기업 인증	EV인증
암호화 통신	O	O	O
도메인 소유자 확인	O	O	O
조직의 실재성 확인	X	O	O
와일드카드 인증서 대응	O	O	X
발행 대상자	개인, 법인	법인	법인
가격	6,900원/년~	49,000원/년	400,000원/년~
신뢰성	낮음	중간	높음
용도	1. 질문 폼이나 캠페인 응모 등 각종 폼 2. 개인 정보 입력은 하지 않는 웹 사이트의 상시 SSL화용	1. 개인 정보 입력이 필요한 회원제 사이트 2. 신용 카드 정보나 개인 정보 입력이 필요한 EC 사이트	1. 개인 정보 입력이 필요한 회원제 사이트 2. 신용 카드 정보나 개인 정보 입력이 필요한 EC 사이트 3. 기업 사이트, 온라인 뱅킹
장점	- 개인도 이용할 수 있음. - 1년에 1만 원이 안되는 인증서도 있는 등 낮은 가격 - 신청에서 발행까지 속도가 빠름	- 조직 실재성을 증명 - 와일드카드 인증서를 발행할 수 있음.	- 조직 이름이 표시되어 사이트 신뢰성이 향상
단점	- 조직 실재성을 증명하지 않음	- 조직의 실재성을 증명하지만, 브라우저상 표시 기능이 없음	- 와일드카드 인증서를 발행할 수 없음 - 비교적 고가

3.1.6. URL과 DNS

URL

URL(Uniform Resource Locator)은 인터넷상에서 HTML이나 이미지 등 리소스 위치를 특정할 수 있는 서식으로 탄생했다. URL의 기본 서식은 스킴(프로토콜 + ://)과 서버 주소(또는 호스트 이름 + 도메인)에 다음 두 가지를 /로 연결한 것이다.

디렉터리 이름
파일 이름

DNS

웹 사이트 주소를 http://93.184.216.34/news/index.html처럼 IP 주소로 표기하면 기억하기 어렵다. 호스트 이름과 도메인으로 바꾸어 http://www.example.com/news/index.html로 변경하면 기억하기 쉽고 쓰기도 쉽다.

하지만 인터넷에서는 반드시 IP주소로 접속할 대상을 지정하므로 www.example.com 이 사실을 조회하는 시스템이 필요하다. 이 시스템이 DNS(Domain Name System)이다.

DNS는 인터넷사의 거대한 분산 데이터베이스라고 할 수 있다. DNS는 콘텐츠 DNS서버와 캐시 DNS 서버 두 가지로 구성된다.

콘텐츠 DNS 서버는 각 도메인의 바탕이 되는 기본 정보를 가지고 있고, 캐시 DNS 서버는 컴퓨터나 휴대전화 등 클라이언트가 문의하면 콘텐츠 DNS 서버를 찾아 정보를 요청한다. 캐시 DNS 서버는 콘텐츠 DNS 서버의 조회 결과를 바탕으로 클라이언트에 정보를 전달한다.

3.2. 도메인

도메인이란 인터넷상 주소로, 글로벌 IP주소를 가진 서버가 어디에 있는지 판단하는 정보로 이용된다. 글로벌 IP 주소가 있는 서버는 일반적으로 웹 사이트를 가리킨다.

3.2.1. 도메인 관리 기관

도메인을 전 세계적으로 관리하는 곳은 ICANN이라는 비영리 단체이다. 그 밖에도 도메인을 다루는 조직으로 레지스트리와 레지스트가 있다.

레지스트리는 도메인 관리 기관으로, 각 도메인 정보의 데이터베이스를 관리한다. 레지스트리에 따라서 관리하는 도메인이 달라진다.

레지스트라는 도메인 중개 등록 업체로, 레지스트리가 관리하는 데이터베이스에 직접 도메인 정보를 등록할 수 있다. 도메인을 이용하려면 도메인 이름의 소유자가 누구인지, 어느 DNS 서버에서 관리되는지 같은 정보를 레지스트리 데이터베이스에 기록해야 한다. 이용자가 신청한 정보는 레지스트라를 경유하여 레지스트리의 데이터베이스에 기록된다.

도메인은 레지스트라가 판매하는 것 말고도 레지스트라의 대리점이 판매하는 예도 있다. 국내외로 많은 도메인 판매업자가 있는데 레지스트라가 직접 판매하기도 하고, 레지스트라에서 도메인을 도매로 받아 판매하는 대리점도 있다.

레지스트라는 레지트스리가 관리하는 데이터베이스에 직접 액세스 할 수 있지만, 대리점은 레지스트리가 관리하는 데이터베이스에 액세스할 수 없고 레지스트라를 통해서만 정보를 등록해야 한다.

3.2.2. 도메인 종류

도메인은 크게 두 종류로 나뉜다. gTLD(generic Top Level Domain)와 ccTLD(country code Top Level Domain)이다. 둘 다 ICANN이 관리하지만, 도메인 등록 업무 및 데이터베이스 관리 같은 실제 운영 업무는 레지스트리에 위임한다.

gTLD

gTLD는 전 세계에 등록이 개방된. com,. net,. org와 등록 제한이 있는. edu,. gov,. int,. mil 이렇게 일곱 가지 종류로 시작되었다. 2000년에. biz,. info,. name,. pro,. aero,. coop,. museum 일곱 가지 종류가 추가되었고, 2003년에는. asia,. cat,. jobs,. mobi,. post,. tel,. travel,. xxx가 추가되었다.

2012년부터는 새롭게 창설하는 gTLD 수에 제한을 두지 않고 기술적, 재무적 요건을 충족하는 조직이라면 신청이 가능해져 지금은 매우 많은 gTLD가 존재한다.

일반 이용자도 신청할 수 있는 gTLD 이외에 특정 기업이 전용으로 보유한 gTLD도 있다.

gTLD는 베리사인(Verisign)등의 회사가 레지스트리가 된다.

국내 ICANN인증 레지스트라로는 가비아, 예스닉, 후이즈 등이 있다.

ccTLD(국가 코드 최상위 도메인)

ccTLD는. kr,. us,. uk,. tv 등 전 세계에 200가지 이상이 있으며, 원칙적으로 그 나라에 사는 사람을 대상으로 한다. 하지만 어디까지나 원칙이며, 운영은 각국 네트워크 정보 센처(NIC)에 위임하여 다른 나라 사람에게도 도메인을 개방할 수 있다.

대한민국의 ccTLD는. kr이며, 한국인터넷진흥원(KISA)이 레지스트리로서 운영하고 있다.

. kr의 레지스트라는 가비아, 아이네임즈, 후이즈 등이 있다.

3.2.3. DNS 전환

시스템 전환 작업이나 서버 교체 등 IP 주소가 변경되는 사례는 많이 있다. 이때 DNS 설정도 함께 변경해야 한다.

www.example.com의 IP 주소가 203.0.113.1인 상태가 198.51.1090.1인 상태로 변경해야 하는 경우를 생각해 보자.

원본이 되는 정보는 콘텐츠 DNS 서버가 가지고 있지만, 인터넷상에 여러 개 존재하는 DNS 서버에도 복사된 정보가 있다. (가지고 있지 않은 경우도 있다.) 그리고 캐시 DNS 서버는 한 번 문의한 DNS 정보를 캐시로 보관해 둔다.

캐시 DNS 서버에서 캐시가 사라지고 새로운 정보를 다시 취득할 때 시차가 생긴다. DNS 정보는 스위치처럼 바로 전환할 수 있는 것은 아니고, 새로운 정보가 구석구석 도달하기까지 시간이 걸린다. 원래대로 되돌릴 때도 동일하기 때문에 서버 전환에 실패하고 다시 되돌릴 때도 마찬가지로 시차가 발생한다.

3.3. HTTP와 웹 기술

3.3.1. HTTP

HTTP는 웹 브라우저와 웹 서버 간의 상호 작용을 지원하는 프로토콜이다. HTTP는 데이터를 요청하는 HTTP 요청과 그에 응답하여 데이터를 보내는 HTTP 응답이라는 두 가지 상호 작용을 반복하여 웹 페이지를 표시한다.

HTTP 요청에는 하고 싶은 처리를 나타내는 메서드 이름과 대상 이름이 포함된다.

GET: 리소스를 가져오도록 웹 서버에 요청
POST: 웹 서버에 데이터를 송신
PUT: 웹 서버에 파일을 업로드

HTTP 응답에는 처리 결과를 나타내는 상태 코드와 헤더, 실제 처리 결과인 메시지가 포함된다.

상태 코드	결과 문구	설명
200	OK	요청이 성공했고, 응답과 함께 요청에 따른 정보가 반환된다.
403	Forbidden	금지, 액세스 거부, 액세스 권한이 없는 웹 페에지에 접근하는 경우 등 반환된다.
404	Not Found	미검출, 웹 페에지를 찾지 못했을때
408	Request Timeout	요청 시간이 초과, 요청이 시간 내에 처리되지 않은 경우 반환
410	Gone	소멸, 리소스가 영구적으로 이동하거나 소멸한다. 웹 페이지가 없어진 것을 대외적으로 나타내는 데 이용한다.
500	Internal Server Error	서버 내부 오류, 서버에서 실행 중인 프로그램을 실행하는 데 오류가 발생한 경우 등 반환
503	Service Unavailable	서비스 이용 불가. 일시적으로 과부하 또는 유지 보수로 서비스를 이용할 수 없다. 접속이 몰려 처리 불능에 빠졌을 경우 반환

3.3.2. 쿠키와 세션

세션은 웹 사이트를 방문해서 수행하는 일련의 행동이다. HTTP는 데이터를 요청하고 전송하는 상태 비저장 프로토콜이다. 사용자의 '상태'의 관한 정보를 알기 위해 사용하는 것이 쿠키(Cookie)이다. 쿠키란 웹 사이트를 열람한 사용자 정보를 클라이언트가 보관하고, 두 번째 액세스부터는 그 정보를 클라이언트가 서버로 보낸다. 이렇게 하면 다시 방문할 때 사용자를 식별할 수 있어 사용자의 브라우징 특성에 맞는 광고를 제공하거나 사이트 기능에 대한 설정을 저장하여 웹 사이트의 편의성을 높일 수 있다.

세션을 실현하려면 웹 사이트에 접속할 때 세션 ID라는 고유 ID가 할당되어야 한다. 세션 ID를 이용하여 사용자가 누구인지 식별하고, 제품을 추가하는 등의 정보는 세션 ID에 대응하는 세션 변수에 기록된다. 쿠키에 세션 정보를 기록하고, 실제 값(세션 변수 정보)은 서버 측에서 관리하는 방법이 널리 이용된다.

3.3.3. 인증

인증은 컴퓨터나 시스템을 사용할 때 필요한 본인 확인 절차이다. 시스템을 사용할 때 제삼자가 마음대로 사용하거나 제삼자에게 보이지 않도록 하는 인증이라는 메커니즘이 필요하다.

웹에서 인증은 개인 정보를 바탕으로 서비스를 이용하는 것이다. ID와 암호로 인증하는 것이 대부분이지만, 최근에는 다요소 인증(MFA) 이라고 하는 ID와 암호 이외에 일시적으로 발행되는 일회용 패스워드(one-time password)를 입력하는 인증 방식도 있다. 인증 요소를 늘리면 보안이 강화된다. 일회용 패스워드에는 휴대전화 SMS 전송, 전용 일회용 패스워드 생성 소프트웨어 사용, 물리적 하드웨어 토큰 기계에 표시된 암호 등 여러 종류가 있다.

특정 서비스의 자격 증명을 사용하여 다른 서비스에 로그인할 수 있는 위임 인증 메커니즘도 있다. 이 방식에서 사용되는 기술이 OAuth이다.

기업 시스템의 예

한때 기업의 사내 시스템은 시스템마다 ID와 암호 데이터베이스를 가지고 있는 것이 대부분이었다. 그러나 최근에는 Active Directory나 LDAP라는 인증 기반과 연계되어 ID와 암호 하나만 있으면 사내의 어떤 시스템에도 로그인할 수 있다. 물론 시스템마다 권한에 따라 접근을 제한할 필요가 있다.

3.3.4. 새로운 기술: HTTP/2, Ajax, Web API

HTTP/2

HTTP/2는 HTTP의 새로운 규격이다. HTTP의 메이저 버전업으로 기획된 프로토콜로, 그 기반은 구글이 중심이 되어 개발한 SPDY 프로토콜이다.

HTTP/1.1 에서는 동시에 복수의 요청을 보낼 수 있지만, '요청 하나에 응답 하나'라는 기본 구조는 그대로이다. 그래서 HTML 파일 하나와 이미지 파일 여러 개로 구성된 웹 페이지를 표시할 때도 파일 하나마다 GET 요청을 보내야 한다. 이를 포함하여 HTTP/1.1 사양에는 아래와 같은 문제점이 있었다.

한 번에 파일 하나밖에 가져올 수 없다: JS, CSS, 이미지 파일 등 많은 리소스를 이용하는 HTML을 로딩하는 데 시간이 걸린다.
프로토콜이 텍스트 기반이다: 텍스트 파일(프로그램에서 다룰 수 있는 데이터로 변환)에 시간이 걸린다.
파일을 가져올 때마다 거의 같은 HTTP 헤더를 송수신한다: 같은 내용을 송수신하는 만큼 오버헤드가 커진다.

이런 문제점을 받아들여 HTTP/2는 HTTP와 호환성을 유지하면서 새로운 전송 수단을 제공하여 기존 문제점을 해결하고 좀 더 적은 통신량으로 더 신속하게 주고받을 수 있도록 설계되었다.

HTTP/2는 커넥션 하나로 복수 콘텐츠를 병렬로 전송할 수 있어, HTTP/1.1 보다 효율이 높은 프로토콜이 되었다.

HTTP/2로 웹 콘텐츠를 전달하려면 SSL/TLS가 꼭 필요하다고 할 수 있다.

Ajax

웹의 편의성을 높인 것으로 알려진 Ajax라고 하는 프로그래밍 기법이 있다.

Ajax는 이미 읽은 웹 페이지에서 다시 HTTP 요청을 보내 웹 페이지 전환 없이 데이터를 송수신할 수 있는 기능을 제공하는 XMLHttpRequest 기술을 사용한다.

또 XMLHttpRequest로 비동기 통신은 구현할 수 있지만 서버 측에서 푸시 통신을 하는 등 양방향 통신은 어려웠는데, 이를 해결하기 위해 웹소켓(Websocket)이라는 기술도 탄생했다.

Web API

최근에는 각사의 웹 애플리케이션 기능이 Web API로 제공된다. Web API는 사용자 조작과 상관없이 어떤 웹 애플리케이션에서 다른 웹 애플리케이션을 조작할 수 있는 인터페이스이다.

[CS-한 권으로 끝내는 네트워크 기초] 2장. 네트워크를 실현하는 기술

mellowg — Wed, 27 Nov 2024 14:00:07 +0900

2장. 네트워크를 실현하는 기술

2.1 TCP/IP의 기본

2.1.1. TCP/IP

TCP/IP는 인터넷 프로토콜 스위트라고도 하며, 다른 컴퓨터 벤더나 운영 체제, 서로 다른 회선끼리 통신할 수 있게 하는 통신 프로토콜 세트이다. 인터넷 여명기에 정의되어 현재까지 표준으로 사용하는 TCP(Transmission Control Protocol)와 IP(Internet Protocol)를 따서 TCP/IP라고 한다.

즉, TCP/IP는 TCP와 IP만 가리키는 것이 아니라, 수많은 인터넷 통신 프로토콜 세트를 의미한다. TCP와 IP이외에도 UDP나 ICMP 등 다른 프로토콜도 TCP/IP에 포함된다.

예전에는 TCP/IP 이외에도 다양한 프로토콜이 있었지만, 현재는 대부분 TCP/IP를 사용한다.

TCP/IP 에서 다루는 범위는 역할에 따라 4개의 계층으로 나뉘며, 이를 TCP/IP 4계층 모델이라고 한다. 데이터 송수신에 필요한 작업을 각 층에서 분담해서 처리하는 이미지이다. 데이터 송수신에 필요한 작업을 각 층에서 분담해서 처리하는 이미지이다. TCP/IP에 포함된 프로토콜을 계층별로 나누면 아래와 같다.

응용계층 - HTTP, DNS 등 - 애플리케이션에 맞추어서 통신한다.
전송계층 - TCP, UDP - IP와 애플리케이션을 중개해서 송신된 데이터를 확실하게 전달한다.
인터넷 계층 - IP, ICMP, ARP 등 - 네트워크 주소를 기반으로 수신 측 컴퓨터까지 데이터를 전송한다.
네트워크 접근 계층 - 이더넷, 무선 랜(Wi-Fi) 등 - 컴퓨터를 물리적으로 네트워크에 연결해서 기기 간에 전송할 수 있게 한다.

2.1.2. OSI 참조 모델

또 하나 알아 둘 프로토콜 계층 모델은 OSI 참조 모델(Oepn System Interconnection reference model)이다. 이것은 TCP/IP 4계층 모델처럼 컴퓨터가 가져야만 하는 통신 기능을 계층 구조로 나눈 모델이자 벤더 간에 상호 통신할 수 있는 네트워크 모델로, 통일 규격이다.

OSI 참조 모델은 통신 프로토콜을 7개의 계층으로 나누어 정의한다.

응용계층 - HTTP, DNS 등
표현계층 - HTTP, DNS 등
세션계층 - HTTP, DNS 등
전송계층 - TCP, UDP
네트워크계층 - IP
데이터링크 계층 - 이더넷
물리 계층 - 이더넷

OSI 참조 모델의 각 층을 실제 네트워크 세계와 연결하면 이더넷이 물리 계층과 데이터 링크 계층에 해당한다. TCP/IP의 IP는 네트워크 계층, TCP, UDP는 전송 계층에 해당하ㅗ, 컴퓨터상에서 움직이는 프로그램은 세션 계층, 표현 계층, 응용 계층에 걸치듯이 존재한다.

앞서 말한 TCP/IP 4계층 모델은 OSI 참조 모델과 별개로 만들어졌으며, 완벽하게 대칭은 아니다.

OSI 참조 모델에서 '층' 이라는 요소가 네트워크 세계에서 실제로 어떻게 사용되는지 알아보자.

예를 들어 1장에서 소개한 스위치(네트워크 스위치)를 예로 들어 설명하겠다.

스위치는 랜 케이블을 모으는 장치로, 조건에 맞게 통신을 중계한다. 어떤 계층의 정보를 바탕으로 중계하느냐에 따라 명칭이 달라진다. 이더넷 범위에서 처리하는 것은 L2 스위치, 라우팅이 가능한 것은 L3 스위치라고 한다.

마찬가지로 TCP로 분배할 수 있는 것은 L4 스위치, 응용 프로그램 레벨에서 배분할 수 있는 것은 L7 스위치라고 한다.

L2 스위치, L3 스위피, L4스위치, L7 스위치는 각자 기능에 따라 분류된 네트워크 장비이다.

2.1.3. 주소

통신에서 주소(address) 란 '통신 상대를 특정하는 식별 정보'이다. 주소가 있기에 비로소 원하는 상대방과 통신할 수 있다.

IP 주소

IP 주소는 TCP/IP에서 컴퓨터를 식별하려고 할당되는 번호이다. xxx.xxx.xxx.xxx 형식으로 표기쇤 숫자를 본 적 있을 것이다. 컴퓨터나 휴대전화, 태블릿 등은 물론이고 서버, 라우터, 스위치 등 네트워크 장비에도 각각 IP 주소가 할당된다.

덧붙여 IP 주소에는 프라이빗 IP 주소와 글로벌 IP주소가 있다. 랜 내부에서 사용되는 것이 프라이빗 IP 주소, 인터넷에서 사용되는 것이 글로벌 IP 주소이다.

MAC 주소

IP 주소만 있다고 컴퓨터끼리 통신할 수 있는 것이 아니다. 컴퓨터나 라우터 등 네트워크 기기에 처음부터 할당된 번호인 MAC 주소를 IP 주소와 조합해야 비로소 컴퓨터끼리 통신할 수 있다.

이더넷에서는 하드웨어끼리 통신 상대를 특정하고자 MAC 주소를 사용하고, TCP/IP에서는 통신 상대를 특정하고자 IP주소를 사용하기 때문이다.

주소를 이용한 통신 흐름과 ARP

같은 네트워크에 속한 컴퓨터끼리 통신할 때는 우선 IP 패킷을 보내고 싶은 상대의 MAC 주소를 조사하고, 그 MAC 주소로 패킷을 보내는 흐름이 된다.

IP 패킷을 보내고 싶은 상대의 MAC 주소를 조사할 때 이용하는 것이 ARP(Address Resolution Protocol) 이다. ARP란 IP주소에 대응하는 MAC 주소를 알아내려고 네트워크 전체에 패킷을 보내면(ARP Request), 자신을 찾는 것을 안 컴퓨터가 응답(ARP reply)함으로써 MAC 주소와 IP주소를 연결하여 통신할 수 있게 하는 일련의 시스템을 의미한다.

ARP 요청처럼 '네트워크 전체에 패킷을 보내는 것'을 브로드캐스트라고 한다. 브로드캐스트는 각 발신자가 그룹의 모든 수신자에게 메시지를 전송하는 통신 방법이다.

반면에 다른 네트워크에 속한 컴퓨터와 통신하면 네트워크 사이에 라우터 또는 L3 스위치가 끼어든다.

자신과 다른 네트워크의 IP 주소와 통신할 때 컴퓨터는 미리 지정된 기본 게이트웨이라는 IP 주소로 통신을 보낸다. 기본 게이트웨이는 다른 네트워크로 데이터를 전송하는 방법을 알고 있으며 일반적으로 라우터가 그 역할을 수행한다.

이때 ARP를 사용해서 조사하는 것은 목적지(다른 네트워크)의 IP 주소에 대응하는 MAC 주소가 아니라 기본 게이트웨이에 대응하는 MAC 주소이다.

IPv4와 IPv6

현재 사용되는 IP 주소는 IPv4(IP version 4)와 IPv6(IP version 6)로 두 종류가 있다.
IPv4는 예정부터 사용되었고, 지금도 메인으로 사용된다. 인터넷이 보급되면서 IPv4 주소가 부족해졌고, 이 문제를 극복하고자 새롭게 도입된 것이 IPv6이다. 하지만 IPv6가 등장하고 수년이 지났음에도 아직도 메인으로 사용하고 있지 않다.
가장 큰 이유는 IPv4 주소가 아직도 여전히 쓸 만하다는 데 있다. '쉽게 손에 넣을 수 있는 상황'이 바뀌지 않는 한 현재 상태에도 큰 변화가 없을 것이다.

2.1.4. 패킷

통신할 때 데이터를 교환하는 방법에는 회선 교환과 패킷 교환 두 종류가 있다. 데이터를 보내고 받는 모습을 교환이라고 상상하면 이해하기 더 쉽다.

회선교환이란 전화에 가까운 이미지로 데이터를 교환하는 동안 계속해서 회선을 점유하는 방식을 의미한다. 전화는 기본적으로 일대일로 주고받는 것이고, 통화하는 동안에는 다른 상대와 전화할 수 없다. 그러나 컴퓨터 네트워크에서는 여러 상대와 동시에 데이터를 주고받는 경우가 있어 이런 방식은 효율적이지 않다.

그래서 생겨난 방식이 패킷 교환 이다. 패킷 교환은 주고받는 데이터를 '패킷'이라고 하는 작은 덩어리로 나누고, 회선을 공용해서 복수의 통신을 내보내는 방식이다. 패킷에는 실제로 소포의 운송장퍼럼 화물 이외에도 받는 곳이나 보낸 곳 등의 정보가 부가된다. 운송장에 해당하는 것을 헤더, 화물에 해당하는 것(작게 나눈 데이터)을 페이로드라고한다. 헤더에는 받는 곳이나 보내는 곳 이외에 소분한 데이터 순서 등도 기록된다. 이렇게 함으로써 데이터를 작게 분할하여 전송하더라도 도착한 곳에서 원래대로 복원할 수 있다.

2.2. IP 주소 구조

2.2.1. IP 주소 분석

새 집에 이사왔을 때 인터넷 회선을 설치하고 가정용 라우터(공유기)를 사서 컴퓨터를 연결한다. 컴퓨터를 라우터에 연결하자마자 인터넷을 사용할 수 있다. 컴퓨터가 출하되었을 때는 MAC 주소만 있고 IP주소는 없는 상태이다. 컴퓨터를 라우터에 연결해야 비로소 라우터에서 IP주소를 받아온다.

이렇게 라우터에서 IP 주소를 자동으로 할당받는 기술을 DHCP(Dynamic Host Configuration Protocol)라고 한다.

DHCP에서는 네 단계 흐름에 따라 통신하여 네트워크 설정을 가져온다.

DHCP Discover: DHCP 클라이언트가 DHCP 서버를 찾고자 네트워크에 통신을 하는 것
DHCP Offer: DHCP 서버가 DHCP 클라이언트에 설정을 제안하는 통신을 하는 것
DHCP Request: DHCP 클라이언트가 DHCP 서버에 제안된 설정의 세부사항을 요청하는 통신을 하는 것
DHCK ACK: DHCP 서버가 DHCP 클라이언트에 설정의 세부 사항을 지정하는 통신을 하는 것

그림넣기

일반적으로 회사에서 인터넷(네트워크)을 사용할 수 있게 하는 것은 정보 시스템 부서 사람들이다. 또 서버가 네트워크에 연결되도록 준비하는 사람을 네트워크 엔지니어라고 한다. 최근에는 네트워크 엔지니어와 서버 엔지니어를 한꺼번에 인프라 엔지니어라고도 부른다.

SRE(Stie Reliability Engineering)라고 소프트웨어 엔지니어가 시스템 운용을 설계하는 방식이 퍼지기도 해서, 소프트웨어 엔지니어가 인프라를 담당하는 사례도 있다.

네트워크 엔지니어는 회사의 각 거점끼리 통신할 수 있도록 IP주소를 할당한다. IP주소는 원래 처음부터 할당된 것이 아니고, 네트워크를 설계해서 구현하는 것이다. 최근에는 클라우드를 활용하여 프로그래머가 시스템을 구축할 수도 있게 되었다. 이때 필요한 것이 바로 네트워크 기초 지식이다.

서브넷 마스크

IPv4 주소는 xxx.xxx.xxx.xxx 형식으로 표기한다. 인간이 보기 쉽게 10진수로 표기하지만, 그 실체는 8자리 2진수 4개이다. 또 IP주소는 네트워크부와 호스트부로 나뉜다. 네트워크부는 어떤 네트워크를 나타내는 정보이며, 호스트부는 그 네트워크 안의 컴퓨터를 특정하는 정보이다. 이 두부분으로 IP주소가 구성된다.

IPv4 주소에서 네트워크부가 어디부터 어디까지인지 나타내는 것이 넷마스크(서브넷 마스크)이다. 넷마스크와 서브넷 마스크는 엄밀하게는 의미가 조금 다르다. 그러나 현장에서는 거의 구별 없이 동일하게 사용한다.

이 장에서 지금부터 등장하는 주소는 다음 네 가지이다.

IP주소: 192.168.1.1
서브넷 마스크: 255.255.255.0
네트워크 주소: 192.168.1.0
브로드캐스트 주소: 192.168.1.255

서브넷 마스크의 255.255.255.0을 2진수로 나타내면 11111111.11111111.11111111.00000000 이다. 이 경우 2진수로 나타낸 서브넷 마스크에서 1 부분은 네트워크부, 0 부분은 호스트부가 된다.

서브넷 마스크를 다시 10진수로 치환하면 255.255.255가 네트워크부이고, 끝에 0이 호스브투에 해당한다. 8자리의 2진수 덩어리를 옥텟이라고 하는데, IPv4주소는 옥텟 4개로 되어 있다. 각각을 1옥텟, 2옥텟, 3옥텟, 4옥텟이라고 한다.

이 경우에는 1옥텟에서 3옥텟까지 네트워크부, 4옥텟은 호스트부라고 할 수 있다.

2.2.2. IP주소의 할당과 관리

IP주소는 처음부터 있는 것이 아니라 따로 할당해서 사용한다. 호스트부를 바꾸어 '1은 컴퓨터, 2는 서버, 3은 프린터...' 식으로 IP주소를 할당한다.

호스트부는 2진수 8자리이므로 10진수로 말하면 0~255의 네트워크 호스트부로 사용할 수 있다고 생각할지도 모른다. 하지만 실제로는 할당할 수 없는 숫자가 있다.

그것은 바로 호스트부의 시작 숫자(0)와 마지막 숫자(255)이다. 호스트부가 모두 0으로 된 것을 네트워크 주소라고 하며, 그 네트워크 자체를 나타낸다.

한편 호스트부를 모두 1로 한 것은 브로드캐스트 주소이며, 로컬 네트워크 전체에 통신을 보낼 때 사용한다. 앞서 소개한 ARP는 브로드캐스트 주소를 사용하여 네트워크 전체에 통신을 보낸다.

즉 호스트부의 처음 1개와 마지막 1개 주소는 컴퓨터 등 기기에 할당할 수 없다. IP주소로 사용자가 사용할 수 있는 IP주소 개수는 256에서 네트워크 주소와 브로드캐스트 주소 2개를 뺀 254개이다.

실제로 라우터 등 네트워크 기기에도 IP주소가 필요하므로 컴퓨터나 프린터 등 기기에 할당할 수 있는 IP주소는 더 줄어든다.

네트워크에 접속하는 기기가 많아지면 IP주소를 별도로 관리해야 한다. 자주 사용되는 고전적인 방식은 마이크로소프트의 엑셀처럼 표 계산 소프트웨어를 이용하여 표 형식으로 관리하는 방식이다. 또 표 형식이 아닌 웹 애플리케이션으로 IP 주소 정보를 관리하거나 네트워크에서 자동으로 IP주소 이용 상황 등을 조사하고 관리하는 툴도 있다. (IPAM)

클래스 및 가변 길이 서브넷 마스크

IP주소는 네트워크부 길이에 따라 클래스가 나뉩니다. 주요 클래스는 아래와 같은 A, B, C 세 가지 유형이다.

클래스 A(/8) 11111111 00000000 00000000 00000000
클래스 B(/16) 11111111 11111111 00000000 00000000
클래스 C(/24) 11111111 11111111 11111111 00000000

그러나 서브넷 마스크가 반드시 클래스를 따라야 하는 것은 아니다. 클래스의 서브넷 마스크 길이를 변경하여 네트워크 크기를 바꾼 것을 가변 길이 서브넷 마스크라고 한다.

예를 들어 회사 네트워크 관리자가 되었다고 가정했을 때, 사내 랜을 구축할 경우 192.168.0.0/24인 네트워크 세그먼트 4를 랜에 할당했다. 이후 회사가 성장하면서 직원 수가 늘어나고 컴퓨터 대수가 증가했으면, 휴대전화나 태블릿 등으로 와이파이를 통해 랜에 접속하는 등 IP 주소가 모자라기 시작한다. 그래서 최소한으로 작업할 수 있는 IP 주소를 늘리는 방법으로 서브넷 마스크를 변경해보기로 한다.

네트워크 192.168.0.0의 서브넷 마스크를 255.255.255.0에서 255.255.254.0으로 변경했다. 호스트부가 넓어져 그만큼 할당할 수 있는 IP 주소도 늘어났다. 호스트부가 너무 크면 ARP등으로 브로드캐스트 통신량이 증가하므로 필요한 만큼 적절한 크기로 설정해야 한다.

2.2.3. 데이터가 바르게 전송되는 메커니즘

다른 네트워크에 속한 컴퓨터와 통신할 때 일어나는 메커니즘.

네트워크 A에 속한 컴퓨터 A
네트워크 B에 속한 컴퓨터 B
네트워크 C에 속한 컴퓨터 C

이렇게 3대의 컴퓨터가 있다고 가정한다. 컴퓨터 A에서 컴퓨터 B와 컴퓨터 C로 통신할 때는 어떻게 동작할까?

컴퓨터 A에서 컴퓨터 B로 통신할 때의 흐름을 살펴보자.

컴퓨터 A는 컴퓨터 B에 데이터를 보내고 싶지만, 서로 다른 네트워크에 속해 있기 때문에 직접적으로 데이터를 보낼 수 없다. 그래서 라우터라는 네트워크 기기가 개입하게 된다.

컴퓨터 A가 컴퓨터 B에 데이터를 보낼 때 어떤 라우터로 보내야 할지 모르는 경우, 컴퓨터 A는 기본게이트웨이라고 하는 라우터로 데이터를 송신한다. 기본 게이트웨이란 '규정 수신처'를 의미하며, 전송할 라우터가 정해져 있지 않은 경우에는 반드시 이곳으로 보낸다고 규칙으로 정해 놓았다.

컴퓨터 A의 기본 게이트웨이는 라우터(1)이라고 가정하면, 네트워크 A와 네트워크 B에 모두 소속되어 있으므로 컴퓨터A로부터 통신을 컴퓨터 B로 전송할 수 있다. 라우터가 수행하는 작업을 라우팅이라고 한다.

이번에는 컴퓨터 A에서 컴퓨터 C로 통신할 때 움직임을 살펴보자. 이때 컴퓨터 A는 네트워크 C(컴퓨터 C)로 데이터를 보낼 때 라우터 (2)로 보낸다는 것을 알고 있다. 그 정보는 라우팅 테이블이라는 것에 기록되어 있다.

라우팅 테이블에는 네트워크로의 통신을 어느 라우터로 전달해야 하는지 기록되어 있다. 라우팅 테이블에 따라 기본 게이트웨이로 보내거나 직접 대상 라우터로 보낼 수 있는 구조로 되어 있다.

컴퓨터 A는 라우터 (2)에 데이터를 전송하고, 라우터 (2)는 컴퓨터 C에 데이터를 전송한다.

라우터에서 라우터로 전송

라우터도 자신이 속해 있지 않거나 보낼 곳을 모르는 네트워크와 통신해야 할 상황에 놓일 수 있다. 라우터에도 기본 게이트웨이(라우터의 경우는 기본 라우트라고 부르지만, 거의 의미가 같음)가 있다. 기본 라우터로 통신을 전송하면 기본 라우터가 다시 전송처를 찾는 방식으로 버킷 릴레이를 반복하여 네트워크가 성립된다.

내 PC IP주소와, MAC주소 확인하기

1. Windows

- ipconfig /all

2. MacOS

- ifconfig

2.3. 네트워크 프로토콜

2.3.1. 네트워크 계층

L2 스위치

MAC 주소에 따라 데이터를 전송하는 것이 L2 스위치이다. L2 스위치가 등장하기 전에는 리피터라는 장치가 기기와 기기의 접속을 담당했다. 그러나 리피터는 모든 포트에 같은 데이터를 보내고 목적지와 일치하는 컴퓨터가 데이터를 받는 방식으로 동작하기 때문에 쓸데없는 데이터를 많이 전송한다. L2 스위치는 목적지의 MAC주소를 기억하므로 해당 포트에만 데이터를 보낼 수 있어 더욱 효율적으로 통신할 수 있다.

L3 스위치(와 라우터)

L3 스위치(와 라우터)는 L2 스위치에 다른 네트워크를 연결하는 기능이 추가되었다. 라우터에도 다른 네트워크를 연결하는 기능이 있어 그 점에서는 L3스위치와 라우터를 같다고 할 수도 있지만, 세세한 부분에서 차이가 있다.

L3스위치는 포트가 많다는 특징이 있다. 포트란 랜 케이블을 꽂는 구멍을 의미하며, L2 스위치에서 발전한 L3 스위치는 기기와 기기를 접속하는 역할도 담당하기에 일반적으로 라우터보다 많은 포트를 탑재하고 있다.

라우터의 특징

다양한 회선을 수용할 수 있다.
- 라우터는 전화회선이나 이더넷, 광 회선 등 다양한 회선을 수용할 수 있다.
L3스위치보다 보안 측면에서 강하는 점이 있다.
- L3스위치도 허용할 통신과 차단할 통신을 설정하는 패킷 필터 기능이 있지만, 송수신의 일관성 검사나 위조 방지 같은 패킷 체크 기능은 라우터가 더 뛰어 나다.

L4 스위치, L7 스위치

L4스위치, L7스위치는 로드 밸런서라고도 한다. 로드 밸런싱은 시스템에 대한 요청을 여러 서버에 분산해서 통신량의 균형을 조절하는 기술이다. L4 스위치는 TCP 헤더 등 프로토콜 헤더의 내용을 해석하고 지정된 알고리즘에 근거하여 데이터를 분산해서 전송한다. 주요 배분 방식으로는 라운드 로빈(round robin)과 최소 연결(least connection)이 있다. 라운드 로빈은 분산처 A, B, C에 A->B->C->A-> ... 처럼 순서대로 할당하는 방식이다. 최소 연결은 분산처 A,B,C 중 가장 커넥션이 적은 곳(처리 여유가 있는 곳)으로 데이터를 분산하는 기술로, 각 분산처의 부하를 평준화하는 방식이다.

L7 스위치는 거기에 더해 응용 계층의 내용까지 분석하여 데이터를 분산해서 전송한다. 특정 사용자와 서버의 연결을 유지하는 기능은 L7스위치가 실현한다. 시스템에 따라서는 복수의 서버가 준비되어 있는데, 특정 사용자와 통신을 일정 기간 계속 유지할 필요가 있을 때가 있다.

예를 들어 웹 사이트에서 쇼핑할 때 등이 있다. 이 경우 다른 서버에 연결되어 불일치가 발생하지 않도록 하는 것이 L7 스위치의 역할 중 하나이다.

2.3.2. TCP와 UDP

TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)는 IP의 상위인 OSI 참조 모델 4계층에서 동작하는 프로토콜로, 3계층에서 동작하는 IP와 5~7계층에서 동작하는 애플리케이션(HTTP 등)을 중개한다.

TCP와 UDP는 중개하는 역할은 같지만, 각각 다른 특성이 있다. TCP에는 신뢰할 수 있는 통신을 실현하는 기능이 구현되어 있고, UDP에는 신뢰성 확보를 위한 기능이 없는 대신 TCP보다 처리가 빠르다.

데이터의 일관성이 중요한 애플리케이션은 TCP로, 고속성이나 실시간성을 요구하는 애플리케이션은 UDP로 구분해서 사용한다.

포트 번호

TCP/UDP 모두 포트 번호가 있다. 포트 번호는 통신하는 대상 컴퓨터의 애플리케이션을 특정하는 번호이다.

예를 들어 한 서버에서 웹 서버와 메일 서버를 동시에 실행 중이라고 한다면, 이 경우 IP 주소만으로는 웹 서버로 가는 통신인지 메일 서버로 가는 통신인지 판별할 수 없다. 그래서 목적지 포트 번호를 이용해서 판별하는 것이다.

포트 번호로는 0~65535의 숫자가 사용되며, 세 종류로 분류된다.

타입	범위	개요
잘 알려진 포트 번호 (well-known port)	0~1023	애플리케이션(서버 측)에서 사용하는 포트 번호
등록된 포트 번호 (registered port)	1024~49151	잘 알려진 포트 번호에 없는 독자적으로 만들어진 애플리케이션에서 사용하는 포트 번호
동적 포트 번호 (dynamic port)	49152~65535	애플리케이션(클라이언트 측)에서 사용하는 포트 번호

잘 알려진 포트 번호(0~1023) 중 자주 사용되는 것을 아래 정리했다.

포트 번호	프로토콜 이름	트랜스포트 프로토콜	개요
80	HTTP	TCP	웹 서버 접속
443	HTTPS	TCP	웹 서버 접속(SSL/TLS 암호화)
110	POP3	TCP	메일 박스 읽기
25	SMTP	TCP	메일 서버 간 이메일 전송
22	SSH	TCP	컴퓨터에 원격 로그인
53	DNS	UDP	DNS 서버에 질의
123	NTP	TCP	시간 동기화

일반적으로는 잘 알려진 포트 번호를 사용한다. 그러나 서버 측에서 다른 번호를 설정하여 사용할 수도 있다. 보안성의 이유 등으로 SSH 포트 번호를 잘 알려진 포트 번호 22에서 다른 번호로 변경하는 것을 자주 볼 수 있다.

SSH는 네트워크를 통해 서버에 로그인하여 명령어를 실행할 수 있는 편리한 프로토콜이지만, 서버를 탈취할 수도 있기 때문에 종종 공격 대상이 된다. 그래서 공격받을 가능성을 줄이고, 이 서버가 보안 대책이 끝난 것을 과시하기 위해서라도 포트 번호를 22번에서 다른 번호로 변경한다.

동적 포트 번호는 출발지 접속 포트 번호로 이용된다. 예를 들어 컴퓨터에서 웹 브라우저를 2개 실행하여 같은 웹 사이트를 열 때, 출발지 포트 식별 기능이 없으면 올바르게 통신할 수 없다. 이 경우 웹 브라우저 A의 HTTP 접속과 웹 브라우저 B의 HTTP 접속에 각각 다른 출발ㅈ 포트 번호를 할당하여 구별할 수 있다.

2.3.3. ICMP

ICMP(Internet Control Message Protocol)는 TCP/IP가 구현된 컴퓨터 및 네트워크 기기 사이에서 통신 상태를 확인할 때 이용하는 프로토콜이다. OSI 참조 모델 3계층에서 동작하는 프로토콜이며, 계층은 IP와 동일하지만 IP 위에서 동작하는 프로토콜이다. 연결확인 등에 이용되는 ping이나 tracert 명령어 등이 ICMP 프로토콜을 사용하는 프로그램이다.

2.3.4. NAT

NAT(Network Address Translation)는 IP주소를 변환하는 기술이다.

IP주소에는 프라이빗 IP와 글로벌 IP가 있다. 그중 랜 내에서 사용되는 것이 프라이빗 IP주소이고, 인터넷에서 사용된느 것이 글로벌 IP 주소이다.

여기에서 프라이빗 IP 주소를 가진 컴퓨터로 인터넷상의 글로벌 IP 주소를 가진 서버에 접속한다고 가정한다. 이때 프라이빗 IP 주소인 채로는 인터넷상에서 라우팅할 수 없다. 라우터가 프라이빗 IP 주소를 글로벌 IP 주소로 변환해주어야만 데이터를 전송할 수 있다. 이 기술이 NAT이다.

2.3.5. 프라이빗 IP 주소에 사용할 수 있는 IP 주소

프라이빗 IP주소로 사용할 수 있는 IP 주소는 세 가지 클래스로 정해져 있다. 이런 주소는 글로벌 IP 주소로 사용되지 않으며, 랜 내에서만 사용된다.

클래스 A - 10.0.0.0/8
클래스 B - 172.16.0.0/12
클래스 C - 192.168.0.0/16

클래스 B 프라이빗 IP 주소와 클래스 C 프라이빗 IP 주소는 각 클래스의 서브넷 마스크의 비트 길이보다 짧고 더 큰 네트워크로 할당되어 있지만, 이용할 때는 이 범위에서 다시 /16 이나 /24로 분할한다. 물론 가변 길이 서브넷 마스크로 /23이나 /28처럼 변칙적으로 분할해서 이용할 수도 있다.

2.3.6. CIDR

CIDR(Classless Inter-Domain Routing)은 쉽게 말해 목적지 여러 개를 모은 것이다.

예를 들어 192.168.0.0/24 ~ 192.168.255.0/24 합계인 256개의 네트워크 세그먼트가 있다고 가정한다. 이것을 라우팅 테이블에 한 줄씩 쓰려면 총 256줄을 써야 한다.

여기에서 호스트부를 확장해서 192.168.0.0/16 으로 하면 192.168.0.0/24 ~ 192.168.255.0/24의 합계 256개 네트워크 세그먼트 전체를 나타낸 것과 같아진다. 이렇게 라우팅을 모아서 쓰는 것을 라우팅 집약이라고도 한다.

2.3.7. 정적 라우팅과 동적 라우팅

라우터에는 라우팅 테이블이 있다. 라우팅 테이블에는 네트워크로의 통신을 어떤 라우터로 전달하면 좋은지 기록된다. 라우팅 테이블 정보를 관리하는 방법에는 정적 라우팅(static routing)과 동적 라우팅(dynamic routing) 두 가지가 있다.

정적 라우팅

라우팅 테이블을 수동으로 관리하는 기술이다.

정적 라우팅에서는 네트워크를 구축할 때는 물론, 네트워크 구성을 변경할 때 사람이 직접 모든 라우팅 테이블을 서렂ㅇ한다.

동적 라우팅

정적 라우팅에 대해 라우터끼리 정기적 또는 필요에 따라 네트워크 접속 경로에 관한 정보를 교환하고, 이를 바탕으로 라우팅 테이블을 자동으로 설정하는 방법이다.

동적 라우팅으로 정보를 교환하는 방식을 라우팅 프로토콜이라고 하며, 이것도 몇 가지 종류가 있다.

자동이라고 해도 설정만 하면 끝나는 것이 아니라 도입이나 운용할 때 어느정도 손이 간다.

[Chapter1. HTTP 동작원리]

mellowg — Tue, 26 Nov 2024 03:18:35 +0900

Chapter1. HTTP 동작원리

가. HTML(Hypertext Markup Language)

HTML은 웹 문서를 작성하는 표준 마크업(Markup Language)이다. HTML은 여러 태그로 구성되어 있는데 이러한 태그를 사용해서 개발자가 원하는 형태의 문서 / 그림을 구성할 수 있다. HTML에서 사용하는 명령어를 태그(Tag)라고 하며, 괄호 '<', '>'를 사용하여 태그를 구성한다.

아래의 예제 코드를 통해 HTML의 구조를 살펴보자. HTML 문서는 최상위 태그로 <html>을 사용한다. 하위에는 문서를 정의하는 데이터를 포함하는 <head>태그와 문서의 내용을 작성하는 <body>태그가 올 수 있다.

HTML 파일의 확장자는 *.html 또는 *.htm을 사용한다. html 또는 htm파일을 웹 브라우저에서 로딩하면 웹 페이지를 확인할 수 있다.

<html>
	<head>
    	문서를 정의하는 데이터가 위치함
    </head>
    <body>
    	문서에 표시되는 내용이 위치함
   	</body>
</html>

나. HTTP (Hypertext Transfer Protocol)

HTTP는 웹 서버와 클라이언트(웹 브라우저) 간에 문서 / 데이터를 교환하기 위한 통신 규약(프로토콜)을 의미한다. 즉, HTML 문서와 같은 자원(리소스)을 처리하는 프로토콜(protocol)로 웹 서버와 클라이언트 간 데이터 교환의 기초가 된다. 다른 말로는 요청(Request) 및 응답(Response) 프로토콜로 표현이 가능하다.

예를 들어, 사용자가 웹 브라우저를 통해 인터넷에 접속하면 HTTP를 이용해서 데이터를 요청하고, 웹 서버는 사용자의 요청을 받아서 처리한 정보를 응답한다. HTTP에 대한 보다 세부적인 내용은 IETF사트에서 확인할 수 있다. HTTP 특징에 대해 간략히 살펴보면 다음과 같다.

1) 비연결지향 (Connectionless)

클라이언트가 HTTP 요청(request)을 서버로 보내면, 서버는 클라이언트 요청에 맞는 응답(response)을 보내고 접속을 끝는다. 즉, 클라이언트와 서버가 계속해서 연결되어 있는 상태가 아니라는 것이다.

2) 상태정보 유지안함(Stateless)

클라이언트와 서버와의 통신이 끝나면 상태 정보는 유지하지 않는 것이다. 클라이언트의 요청을 독립적인 트랜잭션으로 보기 때문에 서버는 이전에 클라이언트의 요청을 항상 해석해야 한다.

이러한 구조적인 한계로 인해 서버는 쿠키와 세션을 사용해서 클라이언트를 식별하게 된다. 예를 들어, 우리가 네이버 웹 사이트를 이용할 때 로그인을 한 번 해두면 별도의 재 인증 과정 없이 메일 / 블로그 /카페를 사용할 수 있는 것이다. (세션 타임아웃이라는 설정으로 일정 시간이 지나면 자동 로그아웃이 되도록 설정할 수 있다.)

나-1) 쿠키(Cookie)와 세션(Session)

쿠키(Cookie)는 클라이언트에 저장되는 키와 값들의 작은 데이터 조각을 의미하며, 이름 / 값 / 만료 날짜 / 경로 등의 정보가 포함되어 있다. 일정 시간동안 데이터를 저장할 수 있으며, 클라이언트의 상태 정보를 로컬에 저장하고 참조한다. 쿠키는 아래와 같은 원리로 생성 및 사용된다.

1) 클라이언트가 브라우저로 웹 페이지에 접속
2) 서버는 클라이언트가 요청한 웹 페이지를 처리하고 쿠키를 클라이언트에 파일로 저장
3) 클라이언트는 서버에 재요청 시 쿠키정보를 호라용해서 서버에 전달
4) 서버는 클라이언트의 쿠키를 활용하여 상태 정보를 유지할 수 있도록 처리

익스플로러 기준으로 인터넷 옵션 - 일반 - 검색기록 - 설정 - 임시 인터넷 파일 - 파일 보기를 클릭하면 PC에 저장되어 있는 쿠키 파일들을 확인할 수 있다.

세션은 쿠키와 다르게 서버의 메모리에 저장되는 정보이다. 일정 시간동안 웹 브라우저를 통해 들어오는 요청을 하나의 상태로 보고 유지하는 기술이다. 즉 사용자가 웹 브라우저를 통해 사이트에 접속하게 되면 브라우저를 종료할 때까지 로그인 유지와 같은 상태가 지속된다. 세션은 아래와 같은 원리로 생성 및 사용된다.

1) 클라이언트가 서버의 웹 페이지에서 로그인 시도
2) 서버는 클라이언트가 요청한 로그인 정보가 맞을 경우, 서버 메모리에 세션ID를 생성하고 클라이언트의 ID와 매핑된 정보를 저장
3) 클라이언트는 세션ID를 쿠키로 저장
4) 클라이언트가 요청할 때마다 서버는 쿠키정보를 확인하고 세션ID와 매핑되는 ID를 사용자로 인증

나-2) 히든 필드(Hidden Field)

히든 필드는 사용자가 보거나 수정할 수 없도록 개발자가 웹페이지의 폼(Form)을 통해 데이터를 전송한다. 입력된 데이터는 GET 또는 POST 메소드를 통해 웹 서버에 전달된다. 다음은 DVWA File Upload실습페이지에서 최대 파일업로드 사이즈를 100000으로 제한하기 위해 폼의 히든 필드를 사용한 사례이다.

<form enctype=\"miltipart/form-data\" action=\"#\" method=\"POST\">
	<input type=\"hidden\" name=\"MAX_FILE_SIZE\" value=\"100000\" />
</form>

히든 필드는 인증 시에도 세션 관리를 위해 사용한다. 다음은 DVWA의 CSRF 실습에서 "dvwa/includes/ dvwaPage.inc.php" 파일 내 tokenField() 함수를 정의하여 세션토큰 값을 반환 시 히든 필드를 사용한 사례이다.

function tokenField() { # Return a field for the(CSRF) token
	return "<input type="hidden" name="user_token" value="{$_SESSION["session_token"]}" />";
}

이처럼 쿠키와 세션 뿐만 아니라 히든 필드를 통해 로그인에 대한 인증 값을 유지할 수 있다.

다. URI / URL / URN

1. URI(Uniform Resource Identifier)

URI는 인터넷에 존재하는 리소스를 고유하게 식별하고 위치를 지정하는 표기법(규약)이다. URI는 URL과 URN을 모두 포함하는 개념이다.

2. URL(Uniform Resource Locator)

URL은 인터넷 상 가용한 자원에 대해 문자(열)로 표현하는 것을 의미한다. 일반적으로 웹의 경우에 클라이언트가 서버로 HTTP 프로토콜을 통해 접속하기 위한 경로로 이해할 수 있다.

<scheme>:<scheme-specific-part>

scheme은 프로토콜의 종류를 의미하며, 프로토콜에 따라 URL 표기 방식이 달라진다.

예를 들어 FTP의 경우 "ftp://id:pass@host:port/path"의 형태로 표현이 가능하다.

웹의 경우 "http://host:port/path?query"와 같이 표현이 가능하다.

HTTP의 경우 웹 브라우저의 주소가 URL이라고 생각하면 된다.

3. URN(Uniform Resource Name)

URN은 지속적이면서 특정 위치의 독립적인 자원을 가리키는 지시자이다.

라. HTTP 메시지

1. 요청(Request) 메시지

클라이언트와 서버는 HTTP 프로토콜을 사용하는데 데이터를 패킷 단위로 나눠서 통신을 한다. 다음은 BurpSuite를 통해 DVWA의 Blind SQL Injectionn 공격 패킷을 캡쳐한 내용이다. 요청(Request) 메시지는 크게 (1) Request Line, (2) Reqeust Headers, (3) Message Body로 구성되어 있다.

1-가) Reqeust Line

Request Line은 HTTP 메소드, 클라이언트가 요청하는 Request URI, HTTP 버전으로 구성되어 있다. HTTP 메소드는 키워드 또는 메시지와 같은 개념으로 클라이언트가 웹서버에게 사용자 요청을 하기 위해 요청 목적이나 종류를 알리는 수단을 의미한다.

메소드 종류에는 GET, POST, HEAD, PUT, DELETE, TRACE, OPTIONS, CONNECT 등이 있다.

POST > Method

/dvwa/vulnerabilities/sqli_blind/ > Request URI

HTTP/1.1 > HTTP 버전

1-나) Request Headers

HTTP에서 Header는 General, Request, Entity의 3가지로 구분한다.

General Header: 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더

Request Header: 패치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더

Entity Header: 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더

Request Header는 클라이언트 요청 및 클라이언트 자체에 대한 추가 정보를 웹 서버에 전달할 수 있게 한다. 요청 패킷의 주요 Request Header 내용은 다음과 같다.

Host: 클라이언트가 요청한 서버 정보
User-Agent: 클라이언트 브라우저의 이름, 버전
Accept: 클라이언트가 허용할 수 있는 파일 형식(MIME_TYPE)
Referrer: 현재 페이지가 어떤 웹 페이지에서 요청되었는지에 대한 정보
Accept-Encoding: 클라이언트가 인식할 수 있는 인코딩 형식
Accept-Language: 클라이언트가 익신할 수 있는 언어

1-다) Message Body

HTTP 메소드가 POST인 경우 HTTP Body 영역에 데이터를 넣어서 전송한다. GET 메소드는 URL에 데이터를 실어서 전달하기 때문에 HTTP Body 영역에는 아무것도 존재하지 않게 된다.

2. 응답(Response) 메시지

응답(Response) 메시지 또한 요청(Request)과 유사한 구조를 가지고 있으며 크게 (1) Status Line, (2) Response Header, (3) Message Body로 구성되어 ㅣㅇㅆ다.

2-가) Status Line

Status Line은 HTTP 버전(HTTP Version), 상태 코드(Status Code), 이유 구문(Reason Phase) 3가지로 구성되어 있다.

HTTP 버전은 현재까지 1.0, 1.1, 2.0으로 구분된다.

Status Code는 3자리의 정수로 구성된 결과 코드이며, HTTP 요청에 대한 응답의 결과가 모두 코드로 사전에 정의되어 있다.

이유 구문은 사용자가 이해할 수 있도록 상태 코드에 대한 간단한 설명이 기술되어 있다.

2-나) Response Header

Response Header는 서버가 Status Line에 없는 응답에 대한 추가적인 정보를 전달한다. 즉, Request-URI에 의해 식별되는 추가적으로 접근을 하고자 하는 자원과 서버에 대한 정보를 제공한다.

Accept-Ranges: bytes

서버가 자원에 대해 범위 요청을 수락할 수 있는데, 바이트(bytes) 단위의 범위 요청을 수락한다.

ETag: "307-55c9d62936140-gzip"

ETag는 요청한 변화에 대한 Entity 태그의 현재 값을 제공하며, HTTP 컨텐츠 변경 유무를 검사하는데 사용한다. Entity-tag는 다음과 같이 요청된 값을 고유 형태로 표시한다.

예를 들어, 클라이언트가 동일 URL로 재요청을 할 경우 ETag 값을 요청헤더에 포함시켜서 전송하고, 서버는 수신한 ETag 값과 현재 값을 비교하여 유효성을 검사한다. ETag가 동일하면 기존 데이터 변동이 없음을 알리는 HTTP 304를 반환하고, 동일하지 않을 경우 전체 응답을 전송한다.

Vary: Accept-Encoding

Vary는 클라이언트와 서버 사이의 캐싱을 위해 필요한 필드이다. 클라이언트가 서버에 데이터를 요청 시 중간의 캐시에 저장된 기존 데이터를 반환함으로써 서버의 성능 부하를 줄일 수 있다. 여기서 Vary 는 캐시에 저장된 기존 데이터를 반환할지 여부를 결정하는 역할을 수행한다. 예를 들어, 클라이언트의 요청의 Accept-Encoding이 gzip으로 반영 되어 있다고 가정하자. 서버에서 이를 수신 시 기존 캐쉬에 gzip이 저장되어 있으면 캐쉬에서 Accept-Encoding을 반환하고,그렇지 않을 경우 서버 측에서 처리하게 된다.

마. HTTP 관련 언어 / 기술

1. 자바스크립트(Javascript)

자바스크립트는 웹 페이지와 상호작용할 수 있도록 만들어진 스크립트 언어이다.

2. CSS(Cascading Style Sheets)

CSS 는 HTML, XML과 같은 문서의 스타일을 꾸미기 위해 사용하는 스타일시트 언어이다. HTML로는 웹 페이지의 뼈대를 만들고, CSS는 문서를 예쁘게 꾸며주는 역할을 한다.

일반적으로 HTML문서는 LINK 태그를 사용해서 CSS 파일을 읽어들인다. (HTML 문서 뿐만 아니라 PHP/ASP/JSP 등의 서버 사이드 스크립트 언어에서도 CSS를 로드할 수 있다.) LINK 태그는 HTML 내 외부 문서와의 연결을 지정하는 태그이다.

(1)사용자가 웹 브라우저에서 HTML 파일을 요청하면, (2) HTML 문서는 LINK 태그에 정의되어 있는 CSS 파일을 읽어와서 HTML 문서의 구조를 스타일링하고, (3) 결과를 사용자 웹 브라우저에 보여준다.

3. XML(eXtensible Markup Language)

4. HTML5

5. PHP(Hypertext Preprocessor PHP)

6. ASP(Active Server Page) / ASP.NET

ASP는 마이크로소프트가 인터넷 정보 서비스에서 개발한 언어로, 동적 웹 페이지 생성 용도로 사용하기 위한 서버 사이드 스크립트 언어이다.

7.JSP(Java Server Page)

JSP는 자바(Java)언어를 기반으로 하는 서버 사이드 스크립트 언어이다.

자바 언어를 기반으로 하기 때문에 자바 라이브러리를 가져다 쓸 수 있다. JSP 는 HTML 에 자바 코드를 포함시켜 동적인 웹 페이지를 구성할 수 있다.

클라이언트가 웹 브라우저에서 JSP를 요청하면 자바 서블릿(Servlet) 파일로 변환되며 웹 애플리케이션 서버에서 동작되면서 필요한 기능들을 처리하여 클라이언트에 응답 값을 반환한다.

1) 클라이언트가 웹 브라우저로 서버에 Book.jsp 파일을 요청
2) 서버는 JSP 컨테이너에 처리를 요청하고 JSP 컨테이너는 Book.jsp 파일을 찾아서 로드
3) JSP 컨테이너가 Book.jsp 파일을 자바 서블릿(Servlet) 파일인 BookServlet.java 파일로 변환
4) BookServlet.java 파일을 실행 가능한 BookServlet.class 파일로 컴파일
5) 메모리에 BookServlet.class 파일을 적재하고 실행 결과를 서버로 반환
6) 서버는 클라이언트의 웹 브라우저가 인식할 수 있는 페이지를 구성해서 응답

클라이언트가 웹 브라우저에서 JSP 파일을 요청하면 파싱 / 컴파일 로딩 등의 과정을 거쳐서 서버는 클라이언트가 요청한 웹 페이지 결과를 반환한다.

바. 웹 서버 / WAS / DB 의 이해

웹 서버(Web Server)란 사용자가 웹 브라우저 등을 통해 HTTP(S)와 같은 프로토콜로 데이터를 요청했을 때, 데이터를 처리한 다음 사용자에게 결과를 HTML 형태로 응답해주는 역할을 한다.

웹 서버는 PHP, JSP, ASP와 같은 서버 사이드 언어를 지원하며, 데이터베이스와의 연동을 통해 데이터를 조회하고 수정한다.

웹 서버에서 서버 사이드 언어를 지원할 수 있도록 도와주는 Apache, nginx, Java, WebtoB, IIS 등의 웹 애플리케이션이 필요하다.

웹 서버는 정적인 데이터를 처리하고 WAS(Web Application Server)는 동적인 데이터를 처리하도록 하는 것이 처리 속도면에서 효율적이. 주로 WEB 서버는 캐시 기능이나 프록시 기능 등 웹 클라이언트와 직접 연관된 일을 처리하고, WAS는 애플리케이션과 관련된 기능 및 데이터베이스와의 통신을 수행한다.

웹 브라우저 <-> 웹 서버 <-> WAS <-> 데이터베이스/애플리케이션

기능적인 목적뿐만 아니라 보안적인 측면에서도 웹 서버와 WAS를 분리하는 것이 좋다.

웹 서버에 웹쉘 업로드 등의 침해가 내부 시스템 영역으로 확장되는 것을 방지할 수 있기 때문이다.

[CS-Database] IT(전산) 필기 시험 대비 데이터베이스 뿌시기

mellowg — Tue, 26 Nov 2024 01:58:52 +0900

IT(전산) 필기 시험 대비 데이터베이스 뿌시기

1. KEY

Key란? 검색, 정렬시 Tuple을 구분할 수 있는 기준이 되는 Attribute

1. Candidate Key (후보키)

Tuple을 유일하게 식별하기 위해 사용하는 속성들의 부분 집합 (기본키로 사용할 수 있는 속성들)

2가지 조건 만족

유일성: Key로 하나의 Tuple을 유일하게 식별할 수 있음.
최소성: 꼭 필요한 속성으로만 구성

2. Primary Key (기본키)

후보키 중 선택한 Main Key

특징

Null값을 가질 수 없음
동일한 값이 중복될 수 없음

3. Alternate Key (대체키)

후보키 중 기본키를 제외한 나머지 키 = 보조키

4. Supre Key (슈퍼키)

유일성은 만족하지만, 최소성은 만족하지 못하는 키

5. Foreign Key (외래키)

다른 릴레이션의 기본키를 그대로 참조하는 속성의 집합

2. JOIN

조인이란?

두 개 이상의 테이블이나 데이터베이스를 연결하여 데이터를 검색하는 방법

테이블을 연결하려면, 적어도 하나의 칼럼을 서로 공유하고 있어야 하므로 이를 이용하여 데이터 검색에 활용한다.

JOIN의 종류

INNER JOIN
LEFT OUTER JOIN
RIGHT OUTER JOIN
FULL OUTER JOIN
CROSS JOIN
SELF JOIN

(1) INNER JOIN

교집합으로, 기준 테이블과 join 테이블의 중복된 값을 보여준다.

SELECT 
A.NAME, B.AGE
FROM EX_TABLE A
INNER JOIN JOIN_TABLE B ON A.NO_EMP=B.NO_EMP

(2) LEFT OUTER JOIN

기준 테이블 값과 조인 테이블과 중복된 값을 보여준다.

왼쪽 테이블 기준으로 JOIN을 한다고 생각하면 편하다

SELECT
A.NAME, B.AGE
FROM EX_TABLE A
LEFT OUTER JOIN JOIN_TABLE B ON A.NO_EMP=B.NO_EMP

(3) RIGHT OUTER JOIN

LEFT OUTER JOIN과는 반대로 오른쪽 테이블 기준으로 JOIN하는 것이다.

SELECT
A.NAME, B.AGE
FROM EX_TABLE A
RIGHT OUTER JOIN JOIN_TABLE B ON A.NO_EMP = B.NO_EMP

(4) FULL OUTER JOIN

합집합을 말한다. A와 B 테이블의 모든 데이터가 검색된다.

SELECT
A.NAME, B.AGE
FROM EX_TABLE A
FULL OUTER JOIN JOIN_TABLE B ON A.NO_EMP = B.NO_EMP

(5) CROSS JOIN

모든 경우의 수를 전부 표현해주는 방식이다.

A가 3개, B가 4개면 총 3 * 4개의 데이터가 검색된다.

SELECT
A.NAME, B.AGE
FROM EX_TABLE A
CROSS JOIN JOIN_TABLE B

(6) SELF JOIN

자기자신과 자기자신을 조인하는 것이다.

하나의 테이블을 여러번 복사해서 조인한다고 생각하면 편하다.

자신이 갖고 있는 칼럼을 다양하게 변형시켜 활용할 때 자주 사용한다.

SELECT
A.NAME, B.AGE
FROM EX_TABLE A, EX_TABLE B

3. SQL Injection

해커에 의해 조작된 SQL 쿼리문이 데이터베이스에 그대로 전달되어 비정상적 명령을 실행시키는 공격 기법

공격 방법

1) 인증 우회

보통 로그인을 할때, 아이디와 비밀번호를 input 창에 입력하게 된다. 예시로 이해해보자.

아이디가 abc, 비밀번호가 만약 1234일 때 쿼리는 아래와 같은 방식으로 전송될 것이다.

SELECT * FROM USER WHERE ID = "abc" AND PASSWORD = "1234";

SQL Injection으로 공격할 때, input 창에 비밀번호를 입력함과 동시에 다른 쿼리문을 함께 입력하는 것이다.

1234; DELETE * USER FROM ID = "1";

보안이 완벽하지 않은 경우, 이처럼 비밀번호가 아이디와 일치해서 True가 되고 뒤에 작성한 DELETE 문도 데이터베이스에 영향을 줄 수도 있게 되는 치명적인 상황이다.

이 밖에도 기본 쿼리문의 WHERE 절에 OR문을 추가하여 "1" = "1"과 같은 true문을 작성하여 무조건 적용되도록 수정한 뒤 DB를 마음대로 조작할 수도 있다.

2) 데이터 노출

시스템에서 발생하는 에러 메시지를 이용해 공격하는 방법이다. 보통 에러는 개발자가 버그를 수정하는 면에서 도움을 받을 수 있는 존재이다. 해커들은 이를 역이용해 악의적인 구문을 삽입하여 에러를 유발시킨다.

즉 예를 들면, 해커는 GET방식으로 동작하는 URL쿼리 스트링을 추가하여 에러를 발생시킨다. 이에 해당하는 오류가 발생하면, 이를 통해 해당 웹앱의 데이터베이스 구조를 유추할 수 있고 해킹에 활용한다.

방어 방법

1) input 값을 받을 때, 특수문자 여부 검사하기

로그인 전, 검증 로직을 추가하여 미리 설정한 특수문자들이 들어왔을 때 요청을 막아낸다.

2) SQL서버 오류 발생 시, 해당하는 에러 메시지 감추기

view를 활용하여 원본 데이터베이스 테이블에는 접근 권한을 높인다. 일반 사용자는 view로만 접근하여 에러를 볼 수 없도록 만든다.

3) preparestatement 사용하기

preparestatement를 사용하면, 특수문자를 자동으로 escaping해준다. (statement와는 다르게 쿼리문에서 전달인자 값을 ? 로 받는 것) 이를 활용해 서버 측에서 필터링 과정을 통해서 공격을 방어한다.

4. SQL vs NoSQL의 차이

웹 앱을 개발할 때, 데이터베이스를 선택할 때 고민하게 된다.

MySQL과 같은 SQL을 사용할까? 아니면 MongoDB와 같은 NoSQL을 사용할까?

보통 Spring에서 개발할 때는 MySQL을, Node.js에서는 MongoDB를 주로 사용했을 것이다.

하지만 그냥 다순히 프레임워크에 따라 결정하는 것이 아니다. 프로젝트를 진행하기에 앞서 적합한 데이터베이스를 택해야 한다. 차이점을 알아보자.

SQL(관계형 DB)

SQL을 사용하면 RDBMS에서 데이터를 저장, 수정, 삭제 및 검색 할 수 있음.

관계형 데이터베이스에는 핵심적인 두 가지 특징이 있다.

데이터는 정해진 데이터 스키마에 따라 테이블에 저장된다.
데이터는 관계를 통해 여러 테이블에 분산된다.

데이터는 테이블에 레코드로 저장되는데, 각 테이블마다 명확하게 정의된 구조가 있다. 해당 구조는 필드의 이름과 데이터 유형으로 정의된다.

따라서 스키마를 준수하지 않은 레코드는 테이블에 추가할 수 없다. 즉, 스키마를 수정하지 않는 이상은 정해진 구조에 맞는 레코드만 추가가 가능한 것이 관계형 데이터베이스의 특징 중 하나이다.

또한, 데이터의 중복을 피하기 위해 "관계"를 이용한다.

하나의 테이블에서 중복 없이 하나의 데이터만 관리하기 때문에 다른 테이블에서 부정확한 데이터를 다룰 위험이 없어지는 장점이 있다.

NoSQL(비관계형 DB)

말그대로 관계형 DB의 반대다.

스키마도 없고, 관계도 없다.

NoSQL에서는 레코드를 문서(documents)라고 부른다.

여기서 SQL과 핵심적인 차이가 있는데, SQL은 정해진 스키마를 따르지 않으면 데이터 추가가 불가능했다. 하지만 NoSQL에서는 다른 구조의 데이터를 같은 컬렉션에 추가가 가능하다.

문서(documents)는 Json과 비슷한 형태를 가지고 있다. 관계형 데이터베이스처럼 여러 테이블에 나누어담지 않고, 관련 데이터를 동일한 '컬렉션'에 넣는다.

따라서 위 사진에 SQL에서 진행한 Orders, Users, Products테이블로 나눈 것을 NoSQL에서는 Orders에 한꺼번에 포함해서 저장하게 된다.

따라서 여러 테이블에 조인할 필요없이 이미 필요한 모든 것을 갖춘 문서를 작성하는 것이 NoSQL이다. (NoSQL에는 조인이라는 개념이 존재하지 않음)

그러면 조인하고 싶을 때 NoSQL은 어떻게 할까?

컬렉션을 통해 데이터를 복제하여 각 컬렉션 일부분에 속하는 데이터를 정확하게 산출하도록 한다.

하지만 이러면 데이터가 중복되어 서로 영향을 줄 위험이 있다. 따라서 조인을 잘 사용하지 않고 자주 변경되지 않는 데이터일 때 NoSQL을 쓰면 상당히 효율적이다.

확장 방법

두 데이터베이스를 비교할 때 중요한 Scaling 개념도 존재한다.

데이터베이스 서버의 확장성은 '수직적' 확장과 '수평적' 확장으로 나누어진다.

운여하는 서버의 사용자가 많아질수록 서버에 부하가 증가하여 많은 용량과 성능을 요구하게 된다. 이를 해결하고자 서버를 추가로 설치하는 방법과 기존의 서버의 성능을 높이는 방법이 있다. 서버를 추가로 설치하는 것을 수평적 확장(Scale-Out), 서버의 성능을 높이는 것을 수직적 확장(Scale-Up)이라고 한다.

수직적 확장: 단순히 데이터베이스 서버의 성능을 향상시키는 것 (ex. CPU업그레이드)
수평적 확장: 더 많은 서버가 추가되고 데이터베이스가 전체적으로 분산됨을 의미(하나의 데이터베이스에서 작동하지만 여러 호스트에서 작동)

데이터 저장 방식으로 인해 SQL 데이터베이스는 일반적으로 수직적 확장만 지원함

수평적 확장은 NoSQL 데이터베이스에서만 가능

그럼 둘 중에 뭘 선택?

정답은 없다. 둘 다 훌륭한 솔루션이고 어떤 데이터를 다루느냐에 따라 선택을 고려해야 한다.

SQL장점

명확하게 정의된 스키마, 데이터 무결성 보장
관계는 각 데이터를 중복없이 한번만 저장

SQL단점

덜 유연함. 데이터 스키마를 사전에 계획하고 알려야 함. (나중에 수정하기 힘듬)
관계를 맺고 있어서 조인문이 많은 복잡한 쿼리가 만들어질 수 있음
대체로 수직적 확장만 가능함

NoSQL 장점

스키마가 없어서 유연함. 언제든지 저장된 데이터를 조정하고 새로운 필드 추가 가능
데이터는 애플리케이션이 필요로 하는 형식으로 저장됨. 데이터 읽어오는 속도 빨라짐
수직 및 수평 확장이 가능해서 애플리케이션이 발생시키는 모든 읽기/쓰기 요청 처리 가능

NoSQL 단점

유연성으로 인해 데이터 구조 결정을 미루게 될 수 있음
데이터 중복을 계속 업데이트 해야 함
데이터가 여러 컬렉션에 중복되어 있기 대문에 수정 시 모든 컬렉션에서 수행해야 함.(SQL에서는 중복 데이터가 없으므로 한번만 수행이 가능)

SQL데이터베이스 사용이 더 좋을 때

관계를 맺고 있는 데이터가 자주 변경되는 애플리케이션의 경우

NoSQL에서는 여러 컬렉션을 모두 수정해야 하기 때문에 비효율적

변경될 여지가 없고, 명확한 스키마가 사용자와 데이터에게 중요한 경우

NoSQL데이터베이스 사용이 더 좋을 때

정확한 데이터 구조를 알 수 없거나 변경/확장 될 수 있는 경우
읽기를 자주 하지만, 데이터 변경은 자주 없는 경우
데이터베이스를 수평으로 확장해야 하는 경우(막대한 양의 데이터를 다뤄야 하는 경우)

하나의 제시 방법이지 완전한 정답이 정해져 있는 것은 아니다.

SQL을 선택해서 복잡한 JOIN문을 만들지 않도록 설계하여 단점을 없앨 수도 있고

NoSQL을 선택해서 중복 데이터를 줄이는 방법으로 설계해서 단점을 없앨 수도 있다.

5. 정규화 (Normalization)

데이터의 중복을 줄이고, 무결성을 향상시킬 수 있는 정규화에 대해 알아보자

Normalization

가장 큰 목표는 테이블 간 중복된 데이터를 허용하지 않는 것이다.

중복된 데이터를 만들지 않으면, 무결성을 유지할 수 있고, DB저장 용량 또한 효율적으로 관리할 수 있다.

목적

데이터의 중복을 없애면서 불필요한 데이터를 최소화시킨다.
무결성을 지키고, 이상 현상을 방지한다.
테이블 구성을 논리적이고 직관적으로 할 수 있다.
데이터베이스 구조 확장이 용이해진다.

정규화에는 여러가지 단계가 있지만 대체적으로 1~3단계 정규화까지의 과정을 거친다.

제 1정규화(1NF)

테이블 컬럼이 원자갑(하나의 값)을 갖도록 테이블을 분리시키는 것을 말하낟.

만족해야 할 조건은 아래와 같다.

어떤 릴레이션에 속한 모든 도메인이 원자값으로만 되어 있어야 한다.
모든 속성에 반복되는 그룹이 나타나지 않는다.
기본키를 사용하여 관련 데이터의 각 집합을 고유하게 식별할 수 있어야 한다.

위 테이블은 전화번호를 여러개 가지고 있어 원자값이 아니다. 따라서 1NF에 맞추기 위해서는 아래와 같이 분리할 수 있다.

제 2정규화(2NF)

테이블의 모든 컬럼이 완전 함수적 종속을 만족해야 한다.

쉽게 말하면, 테이블에서 기본키가 복합키(키1, 키2)로 묶여있을 때, 두 키중 하나의 키만으로 다른 컬럼을 결정지을 수 있으면 안된다.

기본키의 부분집합 키가 결정자가 되어선 안된다는 것

Manufacture과 Model이 키가 되어 Model Full Name을 알 수 있다.

Manufacturer Country는 Manufacturer로 인해 결전된다. (부분 함수 종속)

따라서, Model과 Manufacturer Country는 아무런 연관관계가 없는 상황이다.

결국 완전 함수적 종속을 충족시키지 못하고 있는 테이블이다. 부분 함수 종속을 해결하기 위해 테이블을 아래와 같이 나눠서 2NF를 만족할 수 있다.

제 3정규화(3NF)

2NF가 진행된 테이블에서 이행적 종속을 없애기 위해 테이블을 분리하는 것이다.

이행적 종속: A -> B, B -> C 면 A -> C가 성립된다.

아래 두가지 조건을 만족시켜야 한다.

릴레이션이 2NF에 만족하낟.
기본키가 아닌 속성들은 기본키에 의존한다.

현재 테이블에서는 Tournament와 Year이 기본키다.

Winner는 이 두 복합키를 통해 결정된다.

하지만 Winner Date of Birth는 기본키가 아닌 Winner에 의해 결정되고 있다.

따라서 이는 3NF를 위반하고 있으므로 아래와 같이 분리해야 한다.

[CS-한 권으로 끝내는 네트워크 기초] 1장. 네트워크의 전체적인 모습과 종류

mellowg — Fri, 25 Oct 2024 19:37:59 +0900

1장. 네트워크의 전체적인 모습과 종류

1.1 네트워크란 무엇인가?

1.1.1. 컴퓨터를 네트워크에 연결하는 의미

컴퓨터 네트워크는 컴퓨터끼리 연결해서 데이터를 교환하는 시스템을 의미한다.

온라인 시스템이 생기기 전에는 자기 테이프에 데이터를 담아 우편을 통해 전달하고, 업무를 처리 한 후 다시 우편을 통해 처리 결과를 받을 수 있었다.

1960년대 다수의 이용자가 단말기로 통신 회선을 이용해 컴퓨터를 공동으로 사용할 수 있게 되었고(컴퓨터끼리 네트워크로 연결된 것), 이를 온라인 시스템이라고 한다.

1.1.2 현대 네트워크

현대의 네트워크는 다양한 종류가 있다. 가정 네트워크, 기업 네트워크, 데이터센터 네트웤, 클라우드 사업자 네트워크 등.

가정 네트워크의 경우 광 회선이나 케이블TV와 같은 접속 회선을 이용하여 ISP를 통해 인터넷에 연결된다.

기업용 네트워크는 규모가 더 커지며, 컴퓨터 대수는 물론 때에 따라서 복수의 거점 간 통신이 추가된다. 지점 A와 지점B라는 회사 내 사업소끼리 네트워크로 연결하고, 서로 통신할 수 있다. 또 사내에 서버가 있을 경우 사내 컴퓨터에서 서버로 접속할 수 있게 설정하지만, 서버를 사외 데이터 센터에 두거나 클라우드 서버를 이용하는 예도 있다. 이 경우 데이터 센터와 회사의 각 거점을 연결하거나 클라우드 서버를 둔 클라우드와 연결해야 한다.

1.1.3. LAN과 WAN

컴퓨터 네트워크는 범위에 따라 LAN과 WAN 두 가지로 크게 나뉜다.

LAN(Local Area Network)은 가정이나 사무실 등 하나의 거점 내부를 연결하는 네트워크를 의미한다.

WAN(Wide Area Network)은 거점과 거점을 연결하는 네트워크를 의미한다. '거점 내부'를 연결하는 것은 LAN, '거점 <-> 거점' 과 '거점 <-> 인터넷'을 연결하는 것을 WAN이라고 한다.

LAN과 WAN은 용도가 다를 뿐 컴퓨터끼리 통신하게 하는 역할임에는 변함이 없다.

LAN 특징

LAN에는 두 가지 접속 방법이 있다. 케이블로 접속하는 유선 LAN, 전파로 접속하는 무선 LAN

유선 LAN

인터넷 - ONU - 라우터 - 스위치 -(LAN 케이블로 연결) - 컴퓨터

무선 LAN

인터넷 - ONU - 라우터 ((((( 전파로 통신 ))))) 컴퓨터

LAN은 규격을 바탕으로 접속된다.

유선 LAN용 규격의 종류는 다양하지만, 현재는 대부분의 환경에서 이더넷을 사용한다. 이더넷은 LAN에 이용되는 물리적인 회선이나 접속 커넥터에 관해 정해진 규격이고, 이 뒤에 설명하는 OSI 참조 모델의 1층과 2층에 해당한다.

무선 LAN용 규격은 IEEE라는 표준화 기구가 정한 IEEE802.11 시리즈가 표준으로 보급되어 있다.

LAN 역사를 보면 처음에는 모두 유선 LAN이었고 지금보다 속도도 훨씬 느렷다. 네트워크 장비가 고성능, 고기능화되면서 무선 LAN이 등장했고, 유선 LAN도 규격이 업데이트 되면서 속도가 빨라졌다.

WAN 특징

WAN은 거점과 거점을 연결하고자 SKT나 KT 등 통신 사업자가 제공하는 통신 회선 서비스를 이용하는 네트워크이다. 통신 사업자의 설비를 빌려야 하므로 통신 서비스 이용료나 네트워크 기기 임대료를 지불해야 한다.

WAN 회선에는 개인용과는 별도로 법인용 회선도 있다. 법인용 회선은 보증 대역이 정해져 있거나 보안 옵션을 선택할 수 있다. 일반적으로 개인용 회선보다 이용료가 비싸다.

유선으로 연결된 WAN 서비스 이외에도 이동 통신망을 사용하느 무선 통신도 있으며, 휴대폰이 대표적이다. 이를 무선 WAN이라고도 한다.

1.1.4. 네트워크 구성 요소

일반적인 네트워크를 구성할 때 필요한 것부터 시작해서 각각의 요소를 설명한다.

PC, 휴대 전화 등

사용자가 일반적으로 사용하는 단말이다. 단말을 조작하여 회사 내 서비스를 이용하거나 인터넷상의 서비스를 이용한다.

서버

어떤 서비스를 제공하는 컴퓨터를 서버라고 한다. 하드웨어의 부품 구성이나 제작 방법은 일반 PC와 비슷하지만, 365일 쉬지 않고 계속 가동될 것을 예상하여 좀 더 고성능 부품을 사용한다.

스위치

유선 LAN을 묶는 것이 스위치이다. 단순히 유선 LAN을 묶는 것을 L2 스위치, 네트워크와 네트워크를 연결하는 기능이 있는 것을 L3 스위치, 부하 분산 및 애플리케이션에 맞게 통신을 제어할 수 있는 고급 스위치를 L4 스위치나 L7 스위치 등으로 부른다.

ONU

ONU는 자택이나 회사 등에 끌어온 광 회선과 공유기 사이에 설치되어 광 회선과 공유기를 연결하고 광 신호와 디지털 신호를 변환하는 장치이다. 광 회선을 집이나 회사에서 사용할 수 있도록 하는 장치.

라우터

네트워크와 네트워크를 연결하는 기능이 있는 장비이다. 랜과 인터넷의 경계에 설치되어 네트워크 간 다리를 놓거나, 거점과 거점을 연결하너가, 여러 단말기로 네트워크 회선을 공용하는 역할을 담당한다.

방화벽

방화벽은 라우터와 마찬가지로 네트워크 경계에 놓이는 장비이지만, 라우터와 다른 점은 보안과 관련한 기능을 갖추고 있다는 것이다. 통신 동작에 수상한 점이 없는지 확인하거나 안티 바이러스와 안티 스팸, 침입 감지/방어 등 역할을 담당한다.

가상 라우터

퍼블릭 클라우드를 가상 프라이빗 클라우드로 이용하는 VPC(Virtual Private Cloud)라는 기술이 있다.

기존에는 데이터 센터에 기업 시스템 등을 설치하는 것이 일반적이었지만, 최근에는 VPC로 다시 이전하는 사례가 증가하고 있다. VPC는 가상적인 데이터 센터라고 할 수 있다. VPC와 기업 네트워크는 프라이빗 네트워크로 연결되는데, 여기서 VPC 쪽 연결점이 되는 것이 가상 라우터다. 라우터는 전용 하드웨어로 제공하고, 가상 라우터는 클라우드에서 실행되는 소프트웨어로 제공된다.

1.2 네트워크와 인터넷

1.2.1. 인터네트워킹

인터넷은 '네트워크 간 네트워크'나 '복수의 네트워크를 서로 연결한 네트워크'라는 의미의 '인터넷트워크'라는 용어에서 파생된 용어이다.

일반적으로 컴퓨터 네트워크를 확장하는 방법은 다음 두 가지이다.

한 네트워크를 키워 가는 방법
네트워크와 네트워크를 연결하여 넓혀 가는 방법

복수 네트워크를 서로 연결하는 것을 인터네트워킹이라 하는데, 후자의 접근 방식이 인터네트워킹이다. 그리고 전 세계적으로 인터네트워킹하는 것이 인터넷(The Internet)이다.

(The)Internet과 an internet
인터넷트워킹과 인터네트워크는 복수의 네트워크를 연결한다는 의미의 일반 용어로, 거기에서 파생된 '인터넷'은 두 가지 의미가 있다. 전 세계를 연결하는 인터넷을 전신으로 하는 특정한 글로벌 네트워크. 고유 명사로 영어 대문자로 시작하는 Ther Internet또는 Internet으로 표기한다.

다른 하나는 인터넷트워킹으로 구성되는 네트워크를 뜻하고, an internet으로 표기한다.

(The)Internet을 좁은 의미의 인터넷, an internet을 넓은 의미의 인터넷으로 부르기도 한다.

1.2.2. 네트워크와 인터넷의 관계

인터넷 전신인 ARPANET(Advanced Research Projects Agency NETwork)은 미국 국방성의 고등연구계획국이 자금을 대고, 몇 개 대학과 연구 기관이 공동으로 진행한 프로젝트이다. ARPANET은 패킷 통신 네트워크와 TCP/IP 실용화 등에서 오늘날 인터넷의 기술적 방향성에 영향을 주었다.

조직(AS)

인터넷은 전 세계 여러 조직의 네트워크가 서로 연결된 것으로, 조직의 네트워크 간 접속 정책은 인터넷의 공통된 규칙을 따르지만, 조직 내부를 어떤 정책으로 운용할지는 각 조직에게 달렸다.

이 조직 단위를 AS(Autonomous System)(자율 시스템)라고 한다. AS란 인터넷을 구선하는 단위인 어느 하나의 관리 주체로 보유, 운용되는 독립된 네트워크를 의미한다.

AS가 많이 연결되어 인터넷을 형성한다. 이해하기 쉬운 조직의 예는 KT나 SKT, LG U+같은 인터넷 서비스 제공자(ISP)이다. 가정용 네트워크의 예처럼 랜에 연결된 단말기는 일반적으로 ISP를 통해 인터넷에 접속한다.

인터넷 특징 중 하나는 특정 관리 조직이 존재하지 않는다는 것이다. 인터넷에 포함되는 요소(규격이나 기술 등)를 관리하거나 표준화하는 단체는 있지만, 인터넷 자체를 관리하는 조직은 없다. 그렇기 때문에 인터넷에는 중심이 되는 것이 존재하지 않는다.

traceroute 명령어

traceroute(유닉스 계열 OS명령어, window는 tracert) 명령어는 실행한 컴퓨터에서 목적지 컴퓨터까지 가는 네트워크의 IP주소를 조사하는 도구이다.

traceroute google.com 명령을 실행하면 다음과 같이 터미널창에 뜨게 된다.

실행하는 컴퓨터에서 해당 서버에 이르는 경로가 목록으로 표시되는 것을 확인할 수 있다.

인터넷상에는 여러 라우터가 있고, 라우터를 몇 단계나 경유해야 통신이 연결된다는 사실을 알 수 있다.

명령어 실행 결과는 계약한 ISP에 따라 달라진다.

1.2.3. 인터넷과 WAN의 차이

인터넷은 전 세계의 네트워크를 연결한 세계적 규모의 네트워크이다. 네트워크와 네트워크를 연결할 때 통신 사업자의 WAN 회선으로 연결한다. 지금까지 알아본 것처럼 거점과 거점을 연결하는 부분이 WAN이며, WAN으로 연결된 네트워크 전체가 인터넷이다.

1.2.4. 프로토콜

컴퓨터끼리 통신하려면 공통된 약속이 필요하다. 이 공통된 약속을 프로토콜이라고 한다.

여러가지 프로토콜이 있었지만, 지금은 TCP/IP 라는 것이 주류가 되었다.

왜 프로토콜이 필요할까? 만약 전구 소켓의 크기가 제조사마다 다르다면, 근처 상점에 우리집 규격에 맞는 전구가 없더나 크기가 달라서 사용하지 못하는 등 여러 문제가 발생할 수 있다. 또 같은 제조사더라도 생산하는 전구마다 크기가 제각각이면 더욱 규격을 알기 어렵다. 그래서 전자제춤에는 어느 정도 공통 규격이 있다. 이는 컴퓨터 네트워크에서도 똑같이 적용된다.

[Baekjoon][1010] 실버5 다리 놓기 - Python

mellowg — Fri, 25 Oct 2024 16:19:10 +0900

다리 놓기

문제 이해하기 및 풀이 아이디어

서쪽과 동쪽을 이으는 서로 겹치지 않는 다리의 경우의 수를 구해야 한다

✅ 풀이 코드

# 다리 놓기
T = int(input())

def bridge(n, m):
    dp = [[0 for _ in range(m+1)] for _ in range(n+1)]

    for i in range(1, m+1):
        dp[1][i] = i # N이 1일 때

    # N이 2 이상일 때
    for i in range(2, n+1):
        for j in range(i, m+1):
            for k in range(j, i-1, -1):
                dp[i][j] += dp[i-1][k-1]
    return dp[n][m]

for _ in range(T):
    N, M = map(int, input().split())
    print(bridge(N,M))

[CS-Network] IT(전산) 필기 시험 대비 네트워크 뿌시기

mellowg — Fri, 18 Oct 2024 22:47:14 +0900

IT(전산) 필기 시험 대비 네트워크 뿌시기

1. HTTP의 GET와 POST 비교

둘 다 HTTP 프로토콜을 이용해서 서버에 무엇인가를 요청할 때 사용하는 방식이다. 하지만 둘의 특징을 제대로 이해하여 기술의 목적에 맞게 알맞은 용도에 사용해야한다.

GET

우선 GET방식은 요청하는 데이터가 HTTP Request Message의 Header부분에 url이 담겨서 전공된다. 때문에 url 상에 ? 뒤에 데이터가 붙어 request를 보내게 되는 것이다. 이러한 방식은 url이라는 공간에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적이다. 또 보안이 필요한 데이터에 대해서는 데이터가 그대로 url에 노출

되므로 GET방식은 적절하지 않다. (ex. password)

POST

POST방식의 request는 HTTP Request Message의 Body부분에 데이터가 담겨서 전송된다. 때문에 바이너리 데이터를 요청하는 경우 POST방식으로 보내야 하는 것처럼 데이터 크기가 GET방식보다 크고 보안면에서 낫다.(하지만 보안적인 측면에서 암호화를 하지 않는 이상 고만고만하다.)

그렇다면 이러한 특성을 이해한 뒤에는 어디에 적용되는지를 알아봐야 그 차이를 극명하게 이해할 수 있다. 우선 GET은 가져오는 것이다. 서버에서 어떤 데이터를 가져와서 보여준다거나 하는 용도이지 서버의 값이나 상태 등을 변경하지 않는다. SELECT적인 성향을 갖고 있다고 볼 수 있는 것이다. 반면에 POST는 서버의 ㄱ밧이나 상태를 변경하기 위해서 또는 추가하기 위해서 사용된다.

부수적인 차이점을 좀 더 살펴보자면 GET방식의 요청은 브라우저에서 Caching할 수 있다. 때문에 POST방식으로 요청해야 할 것을 데이터의 크기가 작고 보안적인 문제가 없다는 이유로 GET방식으로 요청한다면 기존에 caching되었던 데이터가 응답될 가능성이 존재한다. 때문에 목적에 맞는 기술을 사용해야 한다.

2. 3-way-handshake & 4-way-handshake

연결 성립(Connection Establishment)

1) 클라이언트는 서버에 접속을 요청하는 SYN(a) 패킷을 보낸다.

2) 서버는 클라이언트의 요청인 SYN(a)을 받고 클라이언트에게 요청을 수락한다는 ACK(a+1)와 SYN(b)이 설정된 패킷을 발송한다.

3) 클라이언트는 서버의 수락 응답인 ACK(a+1)와 SYN(b) 패킷을 받고 ACK(b+1)를 서버로 보내면 연결이 성립(establish)된다.

연결 해제 (Connection Termination)

1) 클라이언트가 연결을 종료하겠다는 FIN플래그를 전송한다.

2) 서버는 클라이언트의 요청(FIN)을 받고 알겠다는 확인 메시지로 ACK 를 보낸다.

2-1) 그리고나서는 데이터를 모두 보낼 때까지 잠깐 TIME_OUT된다.

3) 데이터를 모두 보내고 통신이 끝났으면 연결이 종료되었다고 클라이언트에게 FIN플래그를 전송한다.

4) 클라이언트는 FIN메시지를 확인했다는 메시지(ACK)를 보낸다.

5) 클라이언트의 ACK메시지를 받은 서버는 소켓 연결을 close한다.

6) 클라이언트는 아직 서버로부터 받지 못한 데이터가 있을 것을 대비해 일정 시간 동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거친다. (TIME_WAIT)

What is the SYN Packet? ACK Packet?

SYN: Synchronize sequence number
ACK: Acknowledgement

TCP Header에는 Code Bit(Flag Bit)라는 부분이 존재한다. 이 부분은 총 6Bit로 이루어져 있으며 각각 한 bit들이 의미를 갖고 있다. Urg-Ack-Psh-Rst-Syn-Fin 순서로 되어 있으며 해당 위치의 비트가 1이면 해당 패킷이 어떠한 내용을 담고 있는 패킷인지를 나타낸다. SYN 패킷일 경우엔 000010이 되고 ACK 패킷일 경우에는 010000이 되는 것이다.

Why two types of packets?

일단 연결을 성립하려면 서로 통신이 가능한지를 먼저 파악하기 위해 패킷을 먼저 주고받아야 한다는 것까지는 이해가 쉽다. 그런데 두 종류의 패킷을 주고 받는다. 요청과 응답에 대한 패킷을 주고 받아야 하기 때문에 두 종류인 것이다.

Why 3-way? Is not enough 2-way?

일단 클라이언트가 자신의 목소리가 들리는지 물어본다.(SYN) 서버는 클라이언트의 목소리가 들린다고 말한다. (SYN +1) 그리고 자신의 목소리가 들리는지 물어본다. (ACK) 클라이언트는 서버의 목소리가 들린다고 말한다. (ACK + 1)이런 과정인 셈이다.

TCP connection은 양방향성(bidirection) conneciton이다. 클라이언트에서 서버에게 존재를 알리고 패킷을 보낼 수 있다는 것을 알리듯, 서버에서도 클라이언트에게 존재를 알리고 패킷을 보낼 수 있다는 신호를 보내야 한다. 그렇기 때문에 2-way handshake로는 부족하다.

Why randomized sequence number?

처음 클라이언트에서 SYN 패킷을 보낼 때 Sequence Number에는 랜덤한 숫자가 담겨간다. 초기 sequence number를 ISN이라고 한다. ISN이 0부터 시작하지 않고 난수를 생성해서 number를 설정하는 이유는 무엇일까?

Connection을 맺을 때 사용하는 포트(port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다. 서버 측에서는 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순차적인 number가 전송된다면 이전의 connection으로부터 오는 패킷으로 인식할 수 있다. 이러한 문제가 발생할 가능성을 줄이기 위해서 난수로 ISN을 설정하는 것이다.

3. TCP와 UDP의 비교

UDP

UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)는 비연결형 프로토콜이다. IP 데이터그램을 캡슐화하여 보내는 방법과 연결 설정을 하지 않고 보내는 방법을 제공하낟. UDP는 흐름제어, 오류제어 또는 손상된 세그먼트의 수신에 대한 재전송을 하지 않는다. 이 모두가 사용자 프로세스의 몫이다. UDP가 행하는 것은 포트들을 사용하여 IP 프로토콜에 인터페이스를 제공하는 것이다.

종종 클라이언트는 서버로 짧은 요청을 보내고, 짧은 응답을 기대한다. 만약 요청 또는 응답이 손실된다면, 클라이언트는 time out되고 다시 시도할 수 있으면 된다. 코드가 간단할 뿐만 아니라 TCP처럼 초기설정(initial setup)에서 요구되는 프로토콜보다 적은 메시지가 요구된다.

UDP를 사용한 것들에는 DNS가 있다. 어떤 호스트 네임의 IP주소를 찾을 필요가 있는 프로그램은, DNS서버로 호스트 네임을 포함한 UDP 패킷을 보낸다. 이 서버는 호스트의 IP 주소를 포함한 UDP 패킷으로 응답한다. 사전에 설정이 필요하지 않으며 그 후에 해제가 필요하지 않다.

TCP

대부분의 인터넷 응용 분야들은 신뢰성과 순차적인 전달을 필요로 한다. UDP로는 이를 만족시킬 수 없으므로 다른 프로토콜이 필요하여 탄생한 것이 TCP이다. TCP(Transmission Control Protocol, 전송제어 프로토콜)는 신뢰성이 없는 인터넷을 통해 종단간에 신뢰성 있는 바이트 스트림을 전송 하도록 특별히 설계되었다. TCP 서비스는 송신자와 수신자 모두가 소켓이라고 부르는 종단점을 생성함으로써 일어진다. TCP에서 연결 설정(connection establishment)는 3-way handshake를 통해 행해진다.

모든 TCP연결은 전이중(full-duplex), 점대점(point to point)방식이다. 전이중이란 전송이 양방향으로 동시에 일어날 수 있음을 의미하며 점대점이란 각 연결이 정확히 2개의 종단점을 가지고 있음을 의미한다. TCP는 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다.

4. HTTP와 HTTPS

HTTP의 문제점

HTTP는 평문 통신이기 때문에 도청이 가능하다.
ㅇ통신 상대를 확인하지 않기 때문에 위장이 가능하다.
완전성을 증명할 수 없기 때문에 변조가 가능하다.

위 세가지는 다른 암호화하지 않은 프로토콜에도 공통되는 문제점들이다.

TCP/CP는 도청 가능한 네트워크이다

TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것만으로 도청할 수 있다. 평문으로 통신할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 한다.

보완 방법

통신 자체를 암호화 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를 HTTPS(HTTP Secure) or HTTP over SSL이라고 부른다.
콘텐츠르 암호화 말 그대로 HTTP를 사용해서 운반하는 내용인, HTTP메시지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화해서 전송하면 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.

통신 상대를 확인하지 않기 때문에 위장이 가능하다

HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리가 없기 때문에 누구든지 리퀘스트를 보낼 수 있다. IP주소나 포트 등에서 그 웹 서버에 액세스 제한이 없는 경우 리퀘스트가 오면 상대가 누구든지 무언가의 리스폰스를 반환한다. 이러한 특징은 여러 문제점을 유발한다.

리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지를 확인할 수 없다.
리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지 알 수 없다.
통신하고 있는 상대가 접근이 허가된 상대인지 확인할 수 없다.
어디에서 누가 리퀘스트 했는지 확인할 수 없다.
의미없는 리퀘스트도 수신한다. -> Dos 공격을 방지할 수 없다.

보완방법

위 암호화 방법으로 언급된 SSL로 상대를 확인할 수 있다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 된다. 한 가지 이점을 더 꼽자면 클아이언트는 이 증명서로 본인 확인을 하고 웹 사이트 인증에서도 이용할 수 있다.

완전성을 증명할 수 없기 때문에 변조가 가능하다

여기서 완전성이란 정보의 정확성을 의미한다. 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다라는 것을 보장할 수 없는 것이다. 리퀘스트나 리스폰스가 발신된 후에 상대가 수신하는 사이에 누군가에 의해 변조되더라도 이 사실을 알 수 없다. 이와 같이 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle)이라고 부른다.

보완 방법

MD5, SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 확인할 수 있는 것은 아니다. 확실히 방지하기에는 HTTPS를 사용해야 한다. SSL에는 인증이나 암호화, 그리고 다이제스트 기능을 제공하고 있다.

5. HTTPS

HTTP에 암호화와 인증, 그리고 완전성 보호를 더한 HTTPS

HTTPS는 SSL의 껍질을 덮어쓴 HTTP라고 할 수 있다. 즉, HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아니라는 것이다. HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 프로토콜로 대체하는 것 뿐이다. HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다. SSL을 사용한 HTTPS는 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.

HTTPS의 SSL에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다. 고통키 암호화 방식으로 교환한 다음에 다음부터의 통신은 공통키 암호를 사용하는 방식이다.

모든 웹 페이지에서 HTTPS를 사용해도 될까?

평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 하면 추가적인 리소르를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다.

하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 시용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.

6. DNS round robin 방식

DNS round robin 방식의 문제점

서버의 수 만큼 공인 IP주소가 필요함.
- 부하 분산을 위해 서버의 대수를 늘리기 위해서는 그 만큼의 공인 IP가 필요하다.
균등하게 분산되지 않음
- 모바일 사이트 등에서 문제가 될 수 있는데, 스마트폰의 접속은 캐리어 게이트웨이 라고 하는 프록시 서버를 경유한다. 프록시 서버에서는 이름변환 결과가 일정 시간 동안 캐싱되므로 같은 프록시 서버를 경유하는 경우 접속은 항상 같은 서버로 접속된다. 또한 PC용 웹 브라우저도 DNS 결과를 캐싱하기 때문에 균등하게 부하분산 되지 않는다. DNS레코드의 TTL값을 짧게 설정함으로서 어느 정도 해소가 되지만, TTL에 따라 캐시를 해제하는 것은 아니므로 반드시 주의가 필요하다.
서버가 다운되도 확인 불가
- DNS서버는 웹 서버의 부하나 접속 수 등의 상황에 따라 질의 결과를 제어할 수 없다. 웹 서버의 부하가 높아서 응답이 느려지거나 접속수가 꽉 차서 접속을 처리할 수 없는 상황인 지를 전혀 감지할 수가 없기 때문에 어떤 원인으로 다운되더라도 이를 검출하지 못하고 유저들에게 제공한다. 이때문에 유저들은 간혹 다운된 서버로 연결이 되기도 한다. DNS 라운드 로빈은 어디까지나 부하분산을 위한 방법이지 다중화 방법은 아니므로 다른 S/W와 조합해서 관리할 필요가 있다.

Round Robin 방식을 기반으로 단점을 해소하는 DNS 스케줄링 알고리즘이 존재한다. (일부만 소개)

1. Weighted Round Robin(WRR)

- 각각의 웹 서버에 가중치를 가마해서 분산 비율을 변경한다. 물론 가중치가 큰 서버일수록 빈번하게 선택되므로 처리능력이 높은 서버는 가중치를 높게 설정하는 것이 좋다.

2. Least connection

- 접속 클라이언트 수가 가장 적은 서버를 선택한다. 로드밸런서에서 실시간으로 connection 수를 관리하거나 각 서버에서 주기적으로 알려주는 것이 필요하다.

6. 웹 통신의 큰 흐름

우리가 Chrome 을 실행시켜 주소창에 특정 URL 값을 입력시키면 어떤 일이 일어나는가?

in 브라우저

url에 입력된 값을 브라우저 내부에서 결정된 규칙에 따라 그 의미를 조사한다.
조사된 의미에 따라 HTTP Request메시지를 만든다.
만들어진 메시지를 웹 서버로 전송한다.

이 때 만들어진 메시지 전송은 브라우저가 직접하는 것이 아니다. 브라우저는 메시지를 네트워크에 송출하는 기능이 없으므로 OS에 의뢰하여 메시지를 전달한다. 우리가 택배를 보낼 때 직접 보내는게 아니라, 이미 서비스가 이루어지고 있는 택배 시스템(택배 회사)을 이용하여 보내는 것과 같은 이치이다. 단, OS에 송신을 의뢰할 때는 도메인명이 아니라 ip주소로 메시지를 받을 상대를 지정해야 하는데, 이 과정에서 DNS서버를 조회해야 한다.

in 프로토콜 스택, LAN 어댑터

프로토콜 스택(운영체제에 내장된 네트워크 제어용 소프트웨어)이 브라우저로부터 메시지를 받는다.
브라우저로부터 받은 메시지를 패킷 속에 저장한다.
그리고 수신처 주소 등의 제어정보를 덧붙인다.
그런 다음, 패킷을 LAN 어댑터에 넘긴다.
LAN 어댑터는 다음 Hop의 MAC 주소를 붙인 프레임을 전기신호로 변환한다.
신호를 LAN케이블에 송출시킨다.

프로토콜 스택은 통신 중 오류가 발생했을 때, 이 제어 정보를 사용하여 고쳐 보내거나, 각종 상황을 조절하는 등 다양한 역할을 하게 된다. 네트워크 세계에서는 비서가 있어서 우리가 비서에게 물건만 건네주면, 받는 사람의 주소와 각종 유의사항을 써준다! 여기서는 프로토콜 스택이 비서의 역할을 한다고 볼 수 있다.

in 허브, 스위치, 라우터

LAN어댑터가 송신한 프레임은 스위칭 허브를 경유하여 인터넷 접속용 라우터에 도착한다.
라우터는 패킷을 프로바이더(통신사)에게 전달한다.
인터넷으로 들어가게 된다.

in 액세스 회선, 프로바이더

패킷은 인터넷의 입구에 있는 액세스 회선(통신 회성)에 의해 POP(Point tOf Presence, 통신사용 라우터)까지 운반된다.
POP를 거쳐 인터넷의 핵심부로 들어가게 된다.
수 많은 고속 라우터들 사이로 패킷이 목적지를 향해 흘러가게 된다.

in 방화벽, 캐시서버

패킷은 인터넷 핵심부를 통과하여 웹 서버측의 LAN에 도착한다.
기다리고 있던 방화벽이 도착한 패킷을 검사한다.
패킷이 웹 서버까지 가야하는지 가지 않아도 되는지를 판단하는 캐시서버가 존재한다.

굳이 서버까지 가지 않아도 되는 경우를 골라낸다. 액세스한 페이지의 데이터가 캐시서버에 있으면 웹 서버에 의뢰하지 않고 바로 그 값을 읽을 수 있다. 페이지의 데이터 중에 다시 이용할 수 있는 것이 있으면 캐시 서버에 저장된다.

in 웹 서버

패킷이 물리적인 웹 서버에 도착하면 웹 서버의 프로토콜 스택은 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘긴다.
메시지를 받은 웹 서버 애플리케이션은 요청 메시지에 따른 데이터를 응답 메시지에 넣어 클라이언트로 회송하낟.
왔던 방식대로 응답 메시지가 클라이언트에게 전달된다.

[CS] IT(전산) 필기 시험 대비 Java 뿌시기

mellowg — Thu, 17 Oct 2024 23:46:25 +0900

IT(전산) 필기 시험 대비 Java 뿌시기

1. Integer vs int

int

Primitive 자료형
산술 연산이 가능하며, null값을 가질 수 없다.

Integer

Wrapper클래스(객체)
Unboxing을 하지 않으며 산술 연산이 불가능하지만, null값을 가질 수 있다.
Collection, null값이 필요한 경우 사용한다.

Integer와 int의 size 비교

Integer 및 int비여을 1,000,000개 생성한다.
결과
- Integer: 19986824 byte
- int: 3998536 byte
- 4.99배(약 5배)

2. == 와 equals()의 차이

== > 주소 비교

비교를 위한 연산자
비교하고자 하는 대상의 주소값을 비교한다.

equals() > 내용 비교

메소드이며, 객체끼리 내용을 비교할 수 있다.
비교하고자 하는 대상의 내용 자체를 비교한다.

String a = "a";
Stirng b = a;
String c = new String("a"); // 새로운 객체 생성. 주소가 다름.

// 주소값을 비교
a == b; // true
a == c; // false

// 내용(값)을 비교.
a.equals(b); // true
a.eqauls(c); // true

3. Call by value vs Call by Reference

자바는 Call by Value이다.

Primitive Type(원시 자료형)의 경우 Call by Value

int, short, long, float, double, char, boolean

Reference Type(참조 타입)의 경우 Call by Value

Array, 참조 타입

자바에서는 함수의 인자로 전달되는 타입이 기본형(원시 자료형)인 경우 값을 넘기게 되어있다. 이 경우 메모리에는 함수를 위한 별도의 공간이 생성된다. 이는 함수 종료시 사라진다. 따라서 함수 안에서 해당 인자의 값을 변경하더라도 원본 값은 바뀌지 않는 특징이 있다.

public class Test {
	public static void main(String[] args) {
    	int n = 10;
        System.out.println(n);
        test(10);
        System.out.println(n);
        // 값이 바뀌지 않는다는 것을 볼 수 있다.
    }
    
    public static void test(int n) {
    	n -= 5;
        System.out.println(n);
    }
}

// 결과
10
5
10

4. Java의 String에 관하여

Java에서 String은 굉장히 자주 사용되며, 두 가지 생성 방식이 있다.

new연산자를 이용한 방식
리터럴을 이용한 방식

이 두 가지 방식에는 큰 차이점이 존재한다.

new를 통해 String 객체를 생성하면 Heap영역에 존재하게 된다.

리터럴을 이용할 경우, String. Constance Pool이라는 영역에 존재하게 된다.

public class StringMemory {
	public static void main(String[] args) {
    	String literal = "loper";
        String object = new String("loper");
        
        literal == object; // false
        literal.equals(object); // true
    }
}

== 연산의 결과는 false이다. == 연산자는 객체의 주소값을 비교하기 때문에 일반 객체처럼 Heap영역에 생성된 String 객체와 리터럴을 이용해 String Constant Pool에 저장된 String 객체의 주소값은 다를 수 밖에 없다.
equals() 메소드의 수행 결과는 true이다. 이는 문자열 내용을 비교하기 때문에 같은 문자열에 대해서 true를 반환하는 것이 맞다.

왜 이런 결과가 나올까?

이를 위해서는 동작 방식에 대한 이해가 필요하다. String을 리터럴로 선언한 경우, 내부적으로 String의 intern()이라는 메소드가 호출되게 된다.

intern(): 주어진 문자열이 String Constant Pool에 존재하는지 검색하고 있다면 그 주소값을 반환하고 없다면 String Constant Pool에 넣고 새로운 주소값을 반환하게 된다.

public class StringMemoryInternTest{
	public static void main(String[] args) {
    	String literal = "loper";
        String object = new String("loper");
        String intern = object.intern(); // 명시적으로 호출
        
        literal = object; // false
        literal.equals(object); // true
        
        literal == intern; // true
        literal.equals(intern); // true
    }
}

기존에 new를 통해 생성된 String 객체와 리터럴로 생성된 String 객체를 == 연산하였을 경우, false를 반환했지만 new를 통해 생성된 String객체의 intern() 메소드를 호출하여 새로운 String 객체인 intern에 대입할 경우, 리터럴로 생성된 String 객체와 == 연산시 true를 반환하게 된다.

5. String, StringBuilder, StringBuffer 파이

[String]

Immutable하기 때문에 + 등 concat연산 시 원본을 변경하지 않고 새로운 String 객체를 생성한다. 이로 인해 메모리 공간의 낭비가 발생하고 성능이 떨어진다.
JDK1.5 이후부터는 컴파일 타임에 StringBuilder로 변경한다고 한다.
불변 객체이기 때문에 멀티 쓰레드 환경에서 동기화를 신경쓰지 않아도 된다.
문자열 연산이 적고, 조회가 많은 상황에서 쓰기 좋다.

[StringBuilder, StringBuffer]

공통점
- String과 다르게 Mutable한 객체이다.
- 따라서 문자열 연산 시 새롭게 객체를 생성하지 않고, 처음에 만든 객체를 이용해 연산하고 크기를 변경시켜 문자열을 변경한다.
- 따라서 문자열 연산이 자주 발생하는 상황에서 성능적으로 유리하며 쓰기 좋다.
차이점
- StringBuilder: Thread-Safe 하지 않다. 멀티 쓰레드 지원하지 않음.
- StringBuffer: Thread-Safe하다. 멀티 쓰레드 지원함.
- 죽, 동기화 지원의 유무

StringBuilder는 동기화를 고려하지 않는 상황에서 사용.(Thread를 사용하지 않는 상황). 문자열 연산이 많은 싱글 쓰레드 환경

StringBuffer는 동기화가 필요한 멀티 쓰레드 환경에서 사용. 문자열 연산이 많은 멀티 쓰레드 환경

6. final 키워드

final class
- 다른 클래스가 상속받지 못한다.
final method
- 자식 클래스에서 상위 클래스의 final mehtod를 오버라이드 하지 못한다.
final variable
- 변하지 않는 상수 값이 되어 새롭게 값을 할당할 수 없는 변수가 된다.

7. non-static 멤버와 static 멤버의 차이

non-static 멤버
- 공간적 특성: 해당 멤버는 객체마다 별도로 존재한다.
  - 인스턴스 멤버라고 부른다.
- 시간적 특성: 객체 생성 시에 멤버가 생성된다.
  - 객체가 생성될 때, 멤버가 생성되므로 객체 생성 후에 멤버 사용이 가능
  - 객체가 사라지면 해당 멤버도 사라진다.
- 공유의 특성: 공유되지 않는다.
  - 멤버는 객체 내에 각각 독립된 공간을 유지하므로 공유되지 않는다.
static 멤버
- 공간적 특성: 해당 멤버는 클래스 당 하나만 생성된다.
  - 해당 멤버는 객체 내부가 아닌 별도의 공간에 생겅된다.
  - 클래스 멤버라고 부른다.
- 시간적 특성: 클래스 로딩 시에 멤버가 생성된다.
  - 객체가 생성되기 전에 이미 생성되므로 객체를 생성하지 않고도 사용 가능.
  - 객체가 사라져도 해당 멤버가 사라지지 않는다.
  - 해당 멤버는 프로그램이 종료될 때, 사라진다.
- 공유의 특성: 동일한 클래스의 모든 객체들에 의해 공유된다. (하나의 클래스로부터 생성된 여러 객체가 공유한다.)

8. 객체지향 프로그래밍의 개념

객체 지향 프로그래밍은 OOP(Object Oriented Programming)이라고도 한다.

프로그래밍에서 필요한 데이터를 추상화시켜 상태와 행위를 가진 객체를 만들고 그 객체들 간의 유기적인 상호작용을 통해 로직을 구성하는 프로그래밍 방법이.

[장점]

코드의 재사용성이 높다.
- 누군가가 만든 클래스를 가져와 사용할 수 있고 상속을 통해 확장할 수도 있다.
유지보수가 쉽다.
- 수정해야 할 부분이 클래스 내부에 멤버 변수 혹은 메소드로 존재하기 때문에 해당 부분만 수정하면 된다.
대형 프로젝트에 적합하다.
- 클래스 단위로 모듈화시켜서 개발할 수 있으므로 업무 분담하기가 쉽다.

[단점]

처리 속도가 상대적으로 느리다.
객체가 많으면 용량이 커질 수 있다.
설계 시 많은 노력과 시간이 필요하다.

객체 지향 프로그래밍의 특징(추캡상다)

추상화
- 불필요한 정보는 숨기고 필요한 정보만을 표현함으로써 공통의 속성이나 기능을 묶어 이름을 붙이는 것이다.
캡슐화
- 속성과 기능을 정의하는 멤버 변수와 메소드를 클래스라는 캡슐에 넣는 것이다. 즉, 관련된 기능(메소드)과 속성(변수)을 한 곳에 모으고 분류하기 때문에 재활용이 원활하다.
- 목적: 코드를 수정 없이 재활용 하는 것
- 또한, 캡슐화를 통해 정보 은닉이 가능하다.
상속
- 부모 클래스의 속성과 기능을 그대로 이어 받아 사용할 수 있게 하고 기능의 일부분을 변경해야 할 경우, 상속 받은 자식 클래스에서 해당 기능만 다시 수정(정의)하여 사용할 수 있게 하는 것이다.
- 상속을 통해서 클래스를 작성하면 보다 적은 양의 코드로 새로운 클래스를 작성할 수 있다.
- 또한, 코드를 공통적으로 관리하여 코드 추가 및 변경이 용이하다.
다형성
- 하나의 변수며으 함수명 등이 상황에 따라서 다른 의미로 해석될 수 있는 것이다.
- 즉, 오버라이딩, 오버로딩이 가능하다.

객체 지향 설계 원칙

SRP(Single Responsibility Principle): 단일 책임 원칙
- 클래스는 단 하나의 책임을 가져야 하며, 클래스를 변경하는 이유는 단 하나의 이유여야 한다.
OCP(Open Clsoed Principle): 개방 폐쇄 원칙
- 확장에는 열려있고, 변경에는 닫혀있어야 한다.
LSP(Liskov Substitution Principle): 리스코프 치환 원칙
- 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.
ISP(Interface Segregation Principle): 인터페이스 분리 원칙
- 인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.
DIP(Dependency Inversion Principle): 의존 역전 원칙
- 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.

9. 오버라이딩 vs 오버로딩

오버라이딩과 오버로딩은 자주 나오면서도 중요한 개념이다. 하지만, 그만큼 잘 까먹기 때문에 정리하고 넘어가려 한다.

오버라이딩: 상위 클래스가 가지고 있는 메소드를 하위 클래스에서 재정의해서 사용하는 것을 의미한다.
- 상속 시, 상위 클래스의 private멤버를 제외한 모든 멤버를 상속받는다.
오버로딩: 같은 이름의 메소드를 여러 개 가지면서 매개변수의 타입과 개수를 다르게 하여 정의하는 것을 의미한다. 즉, 메소드의 시그니처를 다르게 하여 정의하는 것이다.

구분	오버로딩	오버라이딩
메소드 이름	동일	동일
매개변수, 타입	다름	동일
반환 타입	상관 없음	동일

10. 접근 제어 지시자

public: public으로 선언된 멤버는 어떤 클래스에서라도 접근이 가능하다. public 메소드는 private멤버와 프로그램 사이의 인터페이스 역할을 수행하기도 한다.
protected: protected멤버를 포함하는 클래스가 정의되어 있는 해당 패키지 내 그리고 해당 클래스를 상속 받은 외부 패키지의 자식 클래스에서 접근이 가능하다.
private: private으로 선언된 멤버는 해당 멤버를 선언한 클래스에서만 접근이 가능하다. public메소드를 이용한다면 해당 객체의 private한 멤버에 접근이 가능하다.
Defulat(package private): 같은 클래스의 멤버와 해당 클래스가 정의되어 있는 패키지 내에서만 접근이 가능하다.

참고

private의 경우
- Private멤버나 메소드를 가지고 있는 클래스를 A 라고 하자.
- 그리고 B라는 클래스가 A를 상속받는다. 이 경우, B 클래스는 Protected로 선언된 멤버 혹은 메소드에 접근이 가능하다.
- 따라서 상속을 받더라도 private한 멤버에는 접근이 불가능 하다.
- 대신, public 메소드를 통해 getter를 만들면 private 멤버를 사용할 수 있다.
protected의 경우
- Protected 멤버나 메소드를 가지고 있는 클래스를 A라고 하자.
- 마찬가지로 B라는 클래스가 A를 상속받는다. 이 경우, B클래스는 protected로 선언된 멤버 혹은 메소드에 접근이 가능하다.
- B라는 클래스가 다른 패키지에 선언되었을지라도 A클래스이 멤버에 접근이 가능하다.
- 하지만, 다른 패키지의 A클래스를 상속받지 않은 클래스는 A 클래스의 멤버에 접근할 수 없다. 마치 private처럼.

11. 직렬화

메모리 내에 존재하는 정보를 보다 쉽게 전송 및 전달하기 위해서 byte 코드 형태로 나열하는 것을 말한다.

직렬화가 무엇인가?

자바 직렬화란 자바 시스템 내부에서 사용된느 객체 또는 데이터를 외부으 자바 시스템에서도 사용할 수 있도록 바이트(byte) 형태로 데이터를 변환하는 기술과 바이트로 변환된 데이터를 다시 객체로 변환하는 기술(역직렬화)을 아울러서 이야기 한다.
시스템적으로 이야기하면, JVM(Java Virtual Machine이하 JVM)의 메모리에 상주(힙 또는 스택)되어 있는 객체 데이터를 바이트 형태로 변환하는 기술과 직렬화된 바이트 형태의 데이터를 객체로 변환해서 JVM으로 상주시키는 형태를 같이 이야기 한다.

12. 추상 클래스란?

추상 클래스는 미완성된 클래스이다.
미완성된 클래스는 미완성된 메소드인 추상 메소드를 포함하고 있다.
추상 클래스는 혼자로는 클래스의 역할을 다 못하지만, 새로운 클래스를 작성하는 데 있어 그 바탕이 되는 부모 클래스로서의 중요한 의미를 갖는다. 왜냐하면 클래스를 작성함에 있어서 어느정도 작성된 상태에서 시작할 수 있기 때문이다.
클래스 앞에 abstract 키워드를 붙인다.

abstract class Car {
	abstract void accelrate();
}

[추상 클래스의 목적]

기존의 클래스에서 공통된 부분을 추상화하여 상속하는 클래스에게 구현을 강제화한다. 메소드의 동작은 구현하는 자식 클래스에게 위임한다.
공유의 목적을 갖고 있다.

[추상 클래스의 특징]

추상 클래스는 추상 메소드가 아닌 일반 메소드, 멤버도 포항할 수 있다. 하지만 추상 메소드를 하나라도 포함하고 있다면 추상 클래스로 선언해야 한다.
추상 클래스는 동작이 정의되어 있지 않은 추상 메소드를 포함하고 있으므로 인스턴스를 생성할 수 없다.

abstract class Animal {
	abstract void cry();
}

class Cat extends Animal {
	@Override
    void cry() {
    	System.out.println("냐오옹");
    }
}

class Dog extends Animal {
	@Override
    void cry() {
    	System.out.println("멍머어엉");
    }
}

public class Test {
	public static void main(String[] args) {
    	// Animal animal = new Animal();
        // 추상 클래스는 자체적으로 인스턴스를 생성할 수 없다. 불완전하기 때문에
        
        Cat cat = new Cat();
        Dog dog = new Dog();
        
        cat.cry();
        dog.cry();
    }
}

추상 클래스인 Animal은 추상 메소드인 cry()를 가지고 있으며, Animal 클래스를 상속받는 자식 클래스인 Dog, Cat클래스는 cry()메소드를 오버라이딩해야만 인스턴스를 생성할 수 있다.

추상 메소드
- 선언부만 작성하고 구현부는 작성하지 않는 메소드이며, 앞에 abstract 키워드를 붙인다.
- 구현부를 작성하지 않는 이유는 메소드의 내용이 상속받은 클래스에 따라 달라질 수 있기 때문이다.
- 사용하는 목적은 추상 메소드를 포함한 클래스를 상속받는 자식 클래스가 반드시 추상 메소드를 구현하도록 강제하기 위함이다.
- 추상 클래스를 상속받은 자식 클래스는 오버라이딩을 통해 조상인 추상 클래스의 추상 메소드를 모두 구현해야 한다.
- 만약, 자식 클래스에서 추상 메소드를 하나라도 구현하지 않는다면 자식 클래스 역시 추상 클래스로 지정해야 한다.

13. 추상 클래스와 인터페이스의 차이점

인터페이스
- 클래스가 아니며, 클래스와 관련이 없다.
- 추상 메소드와 상수만을 멤버로 가진다.
- 한 개의 클래스가 여러 인터페이스를 구현할 수 있다. (다중 구현 가능.)
- Java 8부터 default 메소드가 추가되었다.
  - default 키워드가 붙은 메소드는 구현할 수 있으며(일반 메소드처럼), 자식 클래스에서는 이를 오버라이딩할 수 있다.
  - 인터페이스가 변경되면 이를 구현하는 모든 클래스들이 해당 메소드를 다시 구현해야하는 번거로운 문제가 있었다. 이런 문제를 해결하기 위하여 인터페이스에 메소드를 구현할 수 있도록 변경되었다.
- Java 8부터 static 메소드가 추가되었다.
  - 인터페이스에 static 메소드를 선언 가능하게 함으로써, 간단한 기능을 가지는 유틸리티성 인터페이스를 만들 수 있게 되었다.
- 목적 : 구현 객체의 같은 동작을 보장하기 위해 사용한다.

추상 클래스
- 클래스이며, 클래스와 관련이 있다. (주로 베이스 클래스로 사용)
- 추상 메소드 및 일반 메소드와 멤버도 포함할 수 있다.
- 한 개의 클래스가 여러 개의 클래스를 상속받을 수 없다. (다중 상속 불가능.)
- 상속을 받아 기능을 확장시키는 데 목적이 있다.
- 목적 : 기존의 클래스에서 공통된 부분을 추상화하여 상속하는 클래스에게 구현을 강제화한다. 메소드의 동작은 구현하는 자식 클래스로 위임한다.
- 공유의 목적.

14. 클래스와 인터페이스

클래스
- 어떤 문제를 해결하기 위한 데이터를 만들기 위해 추상화를 거쳐 집단에 속하는 속성과 행위를 변수와 메소드로 정의한 것이다.
인스턴스
- 클래스에서 정의한 것을 토대로 실제 메모리 상에 할당된 것으로 실제 프로그램에서 사용되는 데이터를 말한다.
- 인스턴스는 독립된 메모리 공간에 저장된 자신만의 필드를 가질 수 있다. 하지만 해당 클래스의 모든 메소드는 해당 클래스로부터 생성된 모든 인스턴스가 하나의 메소드를 공유하게 되는 특징을 갖고 있다.

15. 값 타입 vs 참조 타입

가장 큰 차이점은 데이터가 저장되는 메모리 상의 위치이다.

편의상 값 타입은 원시 타입(Primitive Type)이라고 부르겠다. 참조 타입(Reference Type)

원시 타입 : 크기가 작고 고정적이기 때문에 스택 영역에 저장된다.
참조 타입 : 크기가 크고 가변적이기 때문에 동적으로 관리되는 힙에 저장된다.

이처럼 저장되는 위치의 차이는 여러 차이점을 만든다.

1. 메모리 및 접근 속도

원시 타입
- 선언시 스택에 즉시 생성되므로 선언 직후부터 데이터를 저장하는 용도로 사용할 수 있다.
참조 타입
- 선언에 의해 참조만 생성될 뿐, 데이터를 저장할 수 있는 실제 메모리가 할당된 것은 아니다. 따라서 선언 즉시 사용할 수 없다. 반드시 new 연산자로 메모리를 할당받아 초기화해야 한다.
- '스택' 메모리에는 참조값만 존재하고 실제 값은 '힙' 메모리에 존재한다. 값을 필요로 할 때마다 언박싱 과정을 거쳐여 하므로 원시타입과 비교해서 접근 속도가 느려진다.

2. 소멸 시점

원시 타입 : 변수를 선언한 메소드가 종료될 때 혹은 소속된 객체가 사라질 때, 소멸된다.
참조 타입 : 더 이상 참조하는 변수가 없을 때 GC에 의해 제거된다.

3. 복사

원시 타입 : 복사에 의해 별개의 복사본이 생성되며 복사 후 원본과 복사본은 별개의 변수이다. 완전히 다른 두 개의 변수가 생성되는 것이다.
참조 타입 : 참조 타입끼리의 대입은 힙 영역에 존재하는 데이터를 참조하는 참조자가 하나 더 늘어날 뿐이다. 따라서 별도의 메모리가 추가로 할당되지 않는다. 그래서 둘 중 하나를 변경하면 다른 참조자는 같은 값을 참조하기 때문에 같이 변경된다. (해결하기 위해서는 Deep Copy 해야 한다.)

4. Null

원시 타입 : Null 값을 저장할 수 없다.
참조 타입 : Null 값을 저장할 수 있다.

결론
성능과 메모리에 장점이 있는 원시 타입을 먼저 고려해본다. 만약, Null을 다뤄야 하거나 제네릭 타입에서 사용되어야 한다면 참조 타입을 사용한다.

Dynamic Programming (다이나믹 프로그래밍/동적 계획법)

mellowg — Wed, 9 Oct 2024 13:42:21 +0900

Dynamic Programming (다이나믹 프로그래밍/동적 계획법)

다이나믹프로그래밍

메모리를 적절히 사용하여 수행 시간 효율성을 비약적으로 향상시키는 방법
이미 계산된 결과(작은 문제)는 별도의 메모리 영역에 저장하여 다시 계산하지 않도록 한다.
DP의 구현은 일반적으로 두 가지가 있다.
- 상향식(Bottom Up)
- 하향식(Top Down)
다이나믹 프로그래밍은 동적 계획법이라고도 부른다.
프로그래밍 분야에서의 Dynamic?
- 자료구조에서 동적 할당(Dynamic Allocation)은 '프로그래밍 실행되는 도중 필요한 메모리할당 기법'이다.
- 반면, Dynamic Programming의 Dynamic은 별다른 의미 없이 사용한다.

다이나믹프로그래밍의 조건

다이나믹 프로그래밍은 문제가 다음의 조건을 만족할 때 사용할 수 있다.

최적 부분 조건(Optimal Substructure):
- 큰 문제를 작은 문제로 나눌 수 있으며, 작은 문제의 답을 모아서 큰 문제를 해결할 수 있다.
중복되는 부분 문제(Overlapping Subproblem)
- 동일한 작은 문제를 반복적으로 해결해야 한다.

피보나치 수열

피보나치 수열은 다음과 같은 형태의 수열이며, 다이나믹 프로그래밍으로 효과적으로 계산할 수 있다.

1 1 2 3 5 8 13 21 34 55 89 ...

점화식이란 인접한 항들의 관계식을 의미
피보나치 수열의 점화식
- An = An-1 + An-2, A1 = 1, A2 = 1
피보나치 수열이 계산되는 과정은 다음과 같이 표현할 수 있다.
n번째 피보나치 수를 f(n)이라고 할 때, 4번째 피보나치수 f(4)를 구하는 과정은 다음과 같다.

def fibo(x):
	if x == 1 or x == 2:
    	return 1
	return fibo(x-1) + fibo(x-2)
print(fibo(4))

피보나치 수열의 시간복잡도

단순 재귀함수로 구현하게 되면 지수 시간 복잡도를 가지게 된다.
f(x)가 여러번 호출되는 것을 확인할 수 있다. (중복되는 문제)
시간복잡도: O(2^N)

피보나치 수열의 효율적인 해법: 다이나믹 프로그래밍

DP 사용조건을 만족하는지 확인
- 최적부분구조: 큰 문제를 작은 문제로 나눌 수 있다.
- 중복되는문제: 동일한 작은 문제를 반복적으로 해결
피보나치수열은 DP 사용 조건을 만족한다.

메모제이션(memozation)

메모제이션은 DP 구현 방법중 하나이다.
한번 해결한 결과를 메모리제 저장하는 기법
같은 문제를 다시 호출하면 메모했던 결과를 그대로 가져옴.
값을 기록해 놓는다는 점에서 캐싱(Caching)이라고도 한다.

Top Down vs Bottom Up

탑다운(메모제이션) 방식은 하향식이라고도 하며, 바텀업은 상향식이라고도 한다.
DP의 전형적인 형태는 바텀업 방식이다.
- 결과 저장용 리스트는 DP 테이블이라고 부른다.
엄밀히 말하면 메모제이션은 이전에 계산된 결과를 일시적으로 저장해 놓는 개념을 의미한다.
- 따라서 메모제이션은 DP에 국한된 개념은 아니다.
- 한번 계산된 결과를 담아 놓기만하고 DP에 활용하지 않을 수도 있다.

1️⃣ Top Down(하향식)

dp = [0] * 100

def fibo(x):
	if x == 1 or x == 2:
    	return 1
	if dp[x] != 0:
    	return dp[x]
	dp[x] = fibo(x-1) + fibo(x-2)
    return dp[x]

2️⃣ Bottom Up(상향식)

dp = [0] * 100

d[1] = 1
d[2] = 1

for x in range(3, n + 1):
	dp[x] = dp[x-1] + dp[x-2]
print(dp[n])

다이나믹프로그래밍 vs 분할정복

DP와 분할정복은 모두 최적 부분 구조를 가질 때 사용할 수 있다.
큰 문제를 작은 문제로 나눌 수 있으며, 작은 문제의 답을 모아서 큰 문제를 해결할 수 있는 상황
DP와 분할정복의 차이점은 부분문제의 중복이다.
분할정복은 동일한 부분 문제가 반복적으로 계산되지 않는다.

분할 정복의 대표적인 예시인 퀵정렬을 살펴보겠다.
- 한 번의 기준 원소(Pivot)가 자리를 변경해서 자리를 잡으면 그 기준 원소의 위치는 바뀌지 않는다.
- 분할 이후에 해당 Pivot을 다시 처리하는 부분 문제는 호출하지 않는다.

DP문제에 접근하는 방법

주어진 문제가 다이나믹 프로그래밍 유형임을 파악하는 것이 중요하다.
가장 먼저, 그리디, 구현, 완전탐색 등의 아이디어로 문제를 해결할 수 있는지를 검토
- 다른 알고리즘 풀이가 떠오르지 않는다면 DP를 고려
일단 재귀함수로 비효율적인 완전탐색 프로그램을 작성한 뒤에(탑다운) 작은문제에서 구한 답이 큰 문제에서 그래도 사용될수 있으면, 코드를 개선
일반적인 코딩테스트 수준에서는 기본 유형의 DP 문제를 출제

[Programmers] 이분탐색 -lv3 입국심사

mellowg — Wed, 9 Oct 2024 01:39:52 +0900

입국심사

문제 설명

n명이 입국심사를 위해 줄을 서서 기다리고 있습니다. 각 입국심사대에 있는 심사관마다 심사하는데 걸리는 시간은 다릅니다.

처음에 모든 심사대는 비어있습니다. 한 심사대에서는 동시에 한 명만 심사를 할 수 있습니다.

가장 앞에 서 있는 사람은 비어 있는 심사대로 가서 심사를 받을 수 있습니다.

하지만 더 빨리 끝나는 심사대가 있으면 기다렸다가 그곳으로 가서 심사를 받을 수도 있습니다.

모든 사람이 심사를 받는데 걸리는 시간을 최소로 하고 싶습니다.

입국심사를 기다리는 사람 수 n, 각 심사관이 한 명을 심사하는데 걸리는 시간이 담긴 배열 times가 매개변수로 주어질 때, 모든 사람이 심사를 받는데 걸리는 시간의 최솟값을 return 하도록 solution 함수를 작성해주세요.

제한사항

입국심사를 기다리는 사람은 1명 이상 1,000,000,000명 이하입니다.
각 심사관이 한 명을 심사하는데 걸리는 시간은 1분 이상 1,000,000,000분 이하입니다.
심사관은 1명 이상 100,000명 이하입니다.

✅ 정답 코드 (풀이 참고)

def solution(n, times):
    answer = 0
    times.sort(reverse=True)
    
    start = 1
    end = max(times) * n
    
    while start < end:
        mid = (start + end) // 2
        result = 0 
        for a in times:
            result += mid // a

        if result >= n:
            end = mid
        else:
            start = mid + 1

    return start

이진 탐색 기초 문제 풀이

mellowg — Wed, 9 Oct 2024 00:50:50 +0900

이전 내용

이진 탐색 이론 및 구현

이진 탐색 기초 문제 풀이

<문제 1> 떡볶이 떡 만들기: 문제 설명

오늘 00이는 여행 가신 부모님을 대신해서 떡집 일을 하기로 했습니다. 오늘은 떡볶이 떡을 만드는 날입니다. 00이네 떡볶이 떡은 재밌게도 떡볶이 떡의 길이가 일정하지 않습니다. 대신에 한 봉지 안에 들어가는 떡의 총 길이는 절단기로 잘라서 맞춰줍니다.
절단이 높이(H)를 지정하면 줄지어진 떡을 한 번에 절단합니다. 높이가 H보다 긴 떡은 H위의 부분이 잘릴 것이고, 낮은 떡은 잘리지 않습니다.
예를 들어 높이가 19, 14, 10, 17cm인 떡이 나란히 있고 절단기 높이를 15cm로 지정하면 자른 뒤 떡의 높이는 15, 14, 10, 15cm가 될 것입니다. 잘린 떡의 길이는 차례대로 4, 0, 0, 2cm입니다. 손님은 6cm 만큼의 길이를 가져갑니다.
손님이 왔을 때 요청한 총 길이가 M일 때 적어도 M만큼의 떡을 얻기 위해 절단기에 설정할 수 있는 높이의 최대값을 구하는 프로그램 작성

문제 풀이 아이디어

적절한 높이을 찾을 때까지 이진 탐색을 수행하여 높이 H를 반복해서 조정하면 된다.
'현재 이 높이로 자르면 조건을 만족할 수 있는가?'를 확인한 뒤에 조건의 만족 여부('예' 혹은 '아니오')에 따라서 탐색 범위를 좁혀서 해결할 수 있다.
절단기의 높이는 0부터 10억까지의 정수 중 하나이다.
- 이렇게 큰 탐색 범위를 보면 가장 먼저 이진 탐색을 떠올려야 한다.
문제에서 제시된 예시를 통해 그림으로 이해해 보자.

이러한 이진 탐색 과정을 반복하면 답을 도출할 수 있습니다.
중간점의 값은 시간이 지날수록 '최적화된 값'이 되기 때문에, 과정을 반복하면서 얻을 수 있는 떡의 길이 합이 필요한 떡의 길이보다 크거나 같을 때마다 중간점의 값을 기록하면 된다.

✅ 내가 작성한 코드

N, M = map(int, input().split())
ddeok = list(map(int, input().split()))
ddeok.sort()

start = 0
end = max(ddeok)

while start <= end:
    mid = (start + end) // 2

    result = 0
    for d in ddeok:
        if d - mid > 0:
            result += d - mid
    if result > M:
        start = mid + 1
    elif result < M:
        end = mid - 1
    else:
        print(mid)
        break

✅ 제시된 정답 코드

n, m = list(map(int, input().split()))

array = list(map(int, input().split()))

start = 0
end = max(array)

result = 0
while (start <= end):
    total = 0
    mid = (start + end) // 2
    for x in array:
        if x > mid:
            total += x - mid
    if total < m:
        end = mid - 1
    else:
        result = mid
        start = mid + 1
print(result)

<문제 2> 정렬된 배열에서 특정 수의 개수 구하기: 문제 설명

N개의 원소를 포함하고 있는 수열이 오름차순으로 정렬되어 있습니다. 이때 이 수열에서 x가 등장하는 횟수를 계산하세요. 예를 들어 수열 {1, 1, 2, 2, 2, 2, 3}이 잇을 때 x = 2 라면, 현재 수열에서 값이 2인 원소가 4개이므로 4를 출력합니다.
단, 이 문제는 시간 복잡도 O(logN)으로 알고리즘을 설계하지 않으면 시간 초과 판정을 받는다.

문제 풀이 아이디어

✅ 제시된 정답 코드

from bisect import bisect_left, bisect_right

def count_by_range(array, left_value, right_value):
    right_index = bisect_right(array, right_value)
    left_index = bisect_left(array, left_value)
    return right_index - left_index

n, x = map(int, input().split())
array = list(map(int, input().split()))

count = count_by_range(array, x, x)
if count == 0:
    print(-1)
else:
    print(count)

[Beakjoon][2110] 골드4 공유기 설치 - Python

mellowg — Wed, 9 Oct 2024 00:30:33 +0900

공유기 설치

문제 풀이 아이디어

떠올리지 못했음.
이진 탐색을 통해 공유기 간의 거리를 업데이트 해나가며 구한다.

✅ 코드 (풀이 참고)

# 공유기 설치
# 이진 탐색 문제
N, C = map(int, input().split())

arr = []

for _ in range(N):
    arr.append(int(input()))
arr.sort()

start = 1 # 공유기 거리 최소
end = arr[-1] - arr[0] # 공유기 거리 최대
result = 0

# 재귀로 적절한 두 공유기 사이의 거리를 찾는다.
while(start <= end):
    mid = (start + end) // 2 # 현재 공유기 거리
    current = arr[0]
    count = 1
    # 공유기 설치 몇 대 할 수 있는지 체크
    for i in range(1, len(arr)):
        if arr[i] >= current + mid:
            count += 1
            current = arr[i]
    # 공유기 설치 수가 목표 보다 크면 공유기 사이 거리 늘림
    if count >= C:
        start = mid + 1
        result = mid
    # 공유기 설치 수가 목표 보다 작으면 공유기 사이 거리 줄임
    else:
        end = mid -1
print(result)

Binary Search (이분 탐색)

mellowg — Wed, 9 Oct 2024 00:13:03 +0900

Binary Search (이분 탐색)

이진 탐색 알고리즘

순차 탐색: 리스트 안에 있는 특정한 데이터를 찾기 위해 앞에서부터 데이터를 하나씩 확인하는 방법
이진 탐색: 정렬되어 있는 리스트에 탐색 범위를 절반씩 좁혀가며 데이터를 탐색하는 방법
- 이진 탐색은 시작점, 끝점, 중간점을 이용하여 탐색 범위를 설정합니다.

이진 탐색 동작 예시

[Step 1] 시작점: 0, 끝점: 9, 중간점: 4 (소수점 이하 제거)

[Step 2] 시작점: 0, 끝점: 3, 중간점: 1 (소수점 이하 제거)

[Step 3] 시작점: 2, 끝점: 3, 중간점: 2 (소수점 이하 제거)

이진 탐색의 시간 복잡도

단계마다 탐색 범위를 2로 나누는 것과 동일하므로 연산 횟수는 log2N에 비례합니다.
예를 들어 초기 데이터 개수가 32개일 때, 이상적으로 1단계를 거치면 16개 가량의 데이터만 남습니다./
- 2단계를 거치면 8개가량의 데이터만 남습니다.
- 3단계를 거치면 4개가량의 데이터만 남습니다.
다시 말해 이진 탐색은 탐색 범위를 절반씩 줄이며, 시간 복잡도는 O(logN)을 보장합니다.

✅ 재귀로 구현

def binary_search(array, target, start, end):
    if start > end:
        return None
    mid = (start + end) // 2

    if array[mid] == target:
        return mid
    elif array[mid] > target:
        return binary_search(array, target, start, mid - 1)
    else:
        return binary_search(array, target, mid + 1, end)

n, target = map(int, input().split())

array = list(map(int, input().split()))

result = binary_search(array, target, 0, n - 1)
if result == None:
    print("원소가 존재하지 않습니다.")
else:
    print(result + 1)

✅ 반복문으로 구현

n, target = map(int, input().split())

array = list(map(int, input().split()))

start = 0
end = n-1

result = None
while start <= end:
    mid = (start + end) // 2
    if array[mid] < target:
        start = mid + 1
    elif array[mid] > target:
        end = mid - 1
    else:
        result = mid
        break
print(None if result == None else result + 1)

[Baekjoon][1021] 실버2 유기농 배추 - Python

mellowg — Tue, 8 Oct 2024 18:27:57 +0900

✅ 정답 코드

# 유기농 배추
from sys import stdin
from collections import deque

input = stdin.readline

def get_position():
    for i in range(N):
        for j in range(M):
            if ground[i][j] == 1:
                return (i, j)
    return (-1, -1)

def bfs(value):
    global ground
    start = get_position()

    queue = deque([start])

    directions = [(-1, 0), (1, 0), (0, -1), (0, 1)]

    while queue:
        x, y = queue.popleft()
        ground[x][y] = value

        for dx, dy in directions:
            nx, ny = x + dx, y + dy
            if 0 <= nx < N and 0 <= ny < M and ground[nx][ny] == 1:
                ground[nx][ny] = value
                queue.append((nx, ny))

    if get_position() != (-1, -1):
        bfs(value + 1)


T = int(input())

for _ in range(T):
    M, N, B = map(int, input().split())
    ground = [[0] * M for _ in range(N)]
    for _ in range(B):
        x, y = map(int, input().split())
        ground[y][x] = 1
    bfs(2)

    max_value = -1
    for g in ground:
        max_value = max(max_value, max(g))
    print(max_value - 1)

[Baekjoon][14499] 골드4 주사위 굴리기 - Python

mellowg — Tue, 8 Oct 2024 17:42:37 +0900

주사위 굴리기

시간 제한: 2초
메모리 제한: 512MB

문제

크기가 N x M인 지도가 존재한다. 지도의 오른쪽은 동쪽, 위쪽은 북쪽이다. 이 지도의 위에 주사위가 하나 놓여져 있으며, 주사위의 전개도는 아래와 같다. 지도의 좌표는 (r, c)로 나타내며, r는 북쪽으로부터 떨어진 칸의 개수, c는 서쪽으로부터 떨어진 칸의 개수이다.

주사위는 지도 위에 윗 면이 1이고, 동쪽을 바라보는 방향이 3인 상태로 놓여져 있으며, 놓여저 있는 곳의 좌표는(x, y)이다.
가장 처음에 주사위에는 모든 면에 0이 적혀져 있다.
지도의 각 칸에는 정수가 하나씩 쓰여져 있다. 주사위를 굴렸을 때, 이동한 칸에 쓰여 있는 수가 0이면, 주사위의 바닥면에 쓰여 있는 수가 칸에 복사된다. 0이 아닌 경우에는 칸에 쓰여 있는 수가 주사위의 바닥면에 복사되며, 칸에 쓰여 있는 수는 0이 된다.
주사위는 지도의 바깥으로 이동시킬 수 없다. 만약 바깥으로 이동시키려고 하는 경우에는 해당 명령을 무시해야 하며, 출력도 하면 안된다.

입력

첫째 줄에 지도의 세로 크기 N, 가로 크기 M(1 <= N, M <= 20), 주사위를 놓은 곳의 좌표 x, y (0 <= x <= N -1, 0 <= y <= M -1), 그리고 명령의 개수 K( 1 <= K <= 1000)가 주어진다.
둘째 줄부터 N개의 줄에 지도에 쓰여 있는 수가 북쪽부터 남쪽으로, 각 줄은 서쪽부터 동쪽 순서대로 주어진다.
주사위를 놓은 칸에 쓰여 있는 수는 항상 0이다.
지도의 각 칸에 쓰여 있는 수는 10미만의 자연수 또는 0이다.
마지막 줄에는 이동하는 명령이 순서대로 주어진다. 동쪽은 1, 서쪽은 2, 북쪽은 3, 남쪽은 4로 주어진다.

출력

이동할 때마다 주사위의 윗 면에 쓰여 있는 수를 출력한다. 만약 바깥으로 이동시키려고 하는 경우에는 해당 명령을 무시해야 하며, 출력도 하면 안 된다.

문제 풀이 아이디어

규칙에 맞춰 단순 구현하면 될 것 같음.
규칙
1. 남쪽이동 ⬇️
  1. front -> down
  2. down -> back
  3. back -> up
  4. up -> front
2. 북쪽이동 ⬆️
  1. front -> up
  2. up -> back
  3. back -> down
  4. down -> front
3. 동쪽이동 ➡️
  1. right -> down
  2. down -> left
  3. left -> up
  4. up -> right
4. 서쪽이동 ⬅️
  1. left -> down
  2. down -> right
  3. right -> up
  4. up -> left

✅ 정답 코드

# 주사위 굴리기
from sys import stdin

input = stdin.readline

N, M, x, y, k = map(int, input().split())
maps = []

for _ in range(N):
    maps.append(list(map(int, input().split())))

commands = list(map(int, input().split()))

up = 0
down = 0
right = 0
front = 0
back = 0
left = 0

SOUTH, NORTH, EAST, WEST = 4, 3, 1, 2

# SOUTH => front
# NORTH => back
# EAST => left
# WEST => right

positions = (x, y)

for c in commands:

    # 이동한 칸에 쓰여 있는 수가 0이면, 주사위의 바닥면에 쓰여 있는 수가 칸에 복사된다.
    # 0이 아닌 경우에는 칸에 쓰여 있는 수가 주사위의 바닥면으로 복사되며, 칸에 쓰여 있는 수는 0이 된다.
    if c == SOUTH:
        nx, ny = positions[0] + 1, positions[1]
    elif c == NORTH:
        nx, ny = positions[0] - 1, positions[1]
    elif c == WEST:
        nx, ny = positions[0], positions[1] -1
    else:
        nx, ny = positions[0], positions[1] + 1

    # 범위 넘어가면 아무것도 안함
    if 0 <= nx < N and 0 <= ny < M:
        positions = (nx, ny)
    else:
        continue

    if c == SOUTH:
        tmp = front
        front = up
        up = back
        back = down
        down = tmp
    elif c == NORTH:
        tmp = up
        up = front
        front = down
        down = back
        back = tmp
    elif c == WEST:
        tmp = left
        left = up
        up = right
        right = down
        down = tmp
    else:
        tmp = right
        right = up
        up = left
        left = down
        down = tmp

    if maps[nx][ny] == 0:
        maps[nx][ny] = down
    else:
        down = maps[nx][ny]
        maps[nx][ny] = 0
    # print()
    # print(' ', back)
    # print(left, up, right)
    # print(' ', front)
    # print(' ', down)
    print(up)

최단 경로 알고리즘 기초 문제 풀이

mellowg — Tue, 8 Oct 2024 14:54:55 +0900

이전 내용

최단 경로 알고리즘 기초 문제 풀이

<문제 1> 전보: 문제 설명

어떤 나라에는 N개의 도시가 있다. 그리고 각 도시는 보내고자 하는 메시지가 있는 경우, 다른 도시로 전보를 보내서 다른 도시로 해당 메시지를 전송할 수 있다.
하지만 X라는 도시에서 Y라는 도시로 전보를 보내고자 한다면, 도시 X에서 Y로 향하는 통로가 설치되어 있어야 한다.
예를 들어 X에서 Y로 향하는 통로는 있지만, Y에서 X로 향하는 통로가 없다면 Y는 X로 메시지를 보낼 수 없다. 또한 통로를 거쳐 메시지를 보낼 때는 일정 시간이 소요된다.
어느날 C라는 도시에서 위급 상황이 발생했다. 그래서 최대한 많은 도시로 메시지를 보내고자 한다.
메시지는 도시 C에서 출발하여 각 도시 사이에 설치된 통로를 거쳐, 최대한 많이 퍼져나갈 것이다.
각 도시의 번호와 통로가 설치되어 있는 정보가 주여졌을 때, 도시 C에서 보낸 메시지를 받게 되는 도시의 개수는 총 몇 개이며 도시들이 모두 메시지를 받는 데까지 걸리는 시간은 얼마인지 계산하는 프로그램을 작성하시오.
시간제한: 1초
메모리 제한: 128MB
입력 조건
- 첫째 줄에 도시의 개수 N, 통로의 개수 M, 메시지를 보내고자 하는 도시 C가 주어진다.
- (1 <= N <= 30000, 1 <= M <= 200000, 1 <= C <= N)
- 둘째 줄부터 M+1번째 줄에 걸쳐서 통로에 대한 정보 X, Y, Z가 주어진다. 이는 특정 도시 X에서 다른 특정 도시 Y로 이어지는 통로가 있으며, 메시지가 전달되는 시간이 Z라는 의미이다.
- (1 <= X, Y <= N, 1 <= Z <= 1000)
출력 조건
- 첫째 줄에 도시 C에서 보낸 메시지를 받는 도시의 총 개수와 총 걸리는 시간을 공백으로 구분하여 출력한다.

<문제 1> 전보: 문제 해결 아이디어

핵심 아이디어: 한 도시에서 다른 도시까지의 최단 거리 문제로 치환할 수 있다.
N과 M의 범위가 충분히 크기 때문에 우선순위 큐를 활용한 다익스트라 알고리즘을 구현한다.

✅ <문제 1> 정답 코드

import heapq
from sys import stdin

input = stdin.readline

def dijkstra(start):
    q = []
    # 시작 노드로 가기 위한 최단 거리는 0으로 설정하여, 큐에 삽입
    heapq.heappush(q, (0, start))
    distance[start] = 0

    while q:
        # 가장 최단 거리가 짧은 노드에 대한 정보를 꺼내기
        dist, now = heapq.heappop(q)
        if distance[now] < dist:
            continue
        for i in graph[now]:
            cost = dist + i[1]
            if cost < distance[i[0]]:
                heapq.heappush(q, (cost, i[0]))

# 노드의 개수, 간선의 개수, 시작 노드를 입력받기
n, m, start = map(int, input().split())

# 각 노드에 연결되어 있는 노드에 대한 정보를 담는 리스트를 만들기
graph = [[] for _ in range(n + 1)]

# 최단 거리 테이블을 모두 무한으로 초기화
INF = int(1e9)

distance = [INF] * (n + 1)

# 모든 간선 정보 입력 받기
for _ in range(m):
    x, y, z = map(int, input().split())
    # x번 노드에서 y번 노드로 가는 비용이 z라는 의미
    graph[x].append((y, z))

# 다익스트라 알고리즘 수행
dijkstra(start)

# 도달할 수 있는 노드의 개수
count = 0

# 도달할 수 있는 노드 중에서, 가장 멀리 있는 노드와의 최단 거리
max_distance = 0
for d in distance:
    # 도달할 수 있는 노드인 경우
    if d != INF:
        count += 1
        max_distance = max(max_distance, d)
# 시작 노드는 제외해야 하므로 count - 1을 추렭
print(count - 1, max_distance)

<문제 2> 미래 도시: 문제 설명

미래 도시에는 1번부터 N번까지의 회사가 있는데 특정 회사끼리는 서로 도로를 통해 연결되어 있다. 방문 판매원 A는 현재 1번 회사에 위치해 있으며, X번 회사에 방문해 물건을 판매하고자 한다.
미래 도시에서 특정 회사에 도착하기 위한 방법은 회사끼리 연결되어 있는 도로를 이용하는 방법이 유일하다.
또한 연결된 2개의 회사는 양방향으로 이동할 수 있다. 공중 미래 도시에서 특정 회사와 다른 회사가 도로로 연결되어 있다면, 정확히 1만큼의 시간으로 이동할 수 있다.
또한 오늘 방문 판매원 A는 기대하던 소개팅에도 참석하고자 한다.
소개팅의 상대는 K번 회사에 존재한다. 방문 판매원 A는 X번 회사에 가서 물건을 판매하기 전에 소개팅 상대의 회사에 찾아가서 함께 커피를 마실 예정이다. 따라서 방문 판매원 A는 1번 회사에서 출발하여 K번 회사를 방문한 뒤에 X번 회사로 가는 것이 목표이다.
이때 방문 판매원 A는 가능한 한 빠르게 이동하고자 한다.
방문 판매원이 회사 사이를 이동하게 되는 최소 시간을 계산하는 프로그램을 작성하시오.

시간제한: 1초
메모리 제한: 128MB
입력 조건
- 첫째 줄에 회사의 개수 N과 경로의 개수 M이 공백으로 구분되어 차례대로 주어진다. (1 <= N, M <= 100)
- 둘째 줄부터 M+1번째 줄에는 연결된 두 회사의 번호가 공백으로 구분되어 주어진다.
- M + 2번째 줄에는 X와 K가 공백으로 구분되어 차례대로 주어진다. (1 <= K <= 100)
- (1 <= X, Y <= N, 1 <= Z <= 1000)
출력 조건
- 첫째 줄에 방문 판매원 A가 K 번 회사를 거쳐 X번 회사로 가는 최소 이동 시간을 출력한다.
- 만약 X번 최사에 도달할 수 없다면 -1을 출력한다.

<문제 2> 미래 도시: 문제 해결 아이디어

핵심 아이디어: 전형적인 최단 거리 문제이므로 최단 거리 알고리즘을 이용해 해결한다.
N의 크기가 최대 100이므로 플로이드 워셜 알고리즘을 이용해도 효율적으로 해결할 수 있다.
플로이드 워셜 알고리즘을 수행한 뒤에 (1번 노드에서 X까지의 최단 거리 + X에서 K까지의 최단 거리)를 계산하여 출력하면 정답 판정을 받을 수 있다.

✅ <문제 2> 정답 코드

from sys import stdin

input = stdin.readline

N, M = map(int, input().split())

INF = int(1e9)

distance = [[INF] * (N+1) for _ in range(N+1)]
for i in range(N+1):
    for j in range(N+1):
        if i == j:
            distance[i][j] = 0


for _ in range(M):
    x, y = map(int, input().split())
    distance[x][y] = 1
    distance[y][x] = 1

for k in range(1, N+1):
    for i in range(1, N+1):
        for j in range(1, N+1):
            distance[i][j] = min(distance[i][j], distance[i][k] + distance[k][j])

X, K = map(int, input().split())

if distance[K][X] == INF:
    print(-1)
else:
    print(distance[1][K] + distance[K][X])

Floyd-Warshall Algorithm (플로이드 워셜 알고리즘)

mellowg — Tue, 8 Oct 2024 13:41:22 +0900

Floyd-Warshall Algorithm (플로이드 워셜 알고리즘)

플로이드 워셜 알고리즘

모든 노드에서 다른 모든 노드까지의 최단 경로를 모두 계산
플로이드 워셜 알고리즘은 다익스트라 알고리즘과 마찬가지로 단계별로 거쳐가는 노드를 기준으로 알고리즘을 수행한다.
- 다만, 매 단계마다 방문하지 않은 노드 중에 최단거리를 갖는 노드를 찾는 과정이 필요하지 않다플로이드 워셜은 2차원 테이블에 최단거리 정보를 계산한다.
플로이드 워셜은 2차원 테이블에 최단거리 정보를 계산한다.
플로이드 워셜 알고리즘은 DP 유형에 속한다.
각 단계마다 특정한 노드 K를 거쳐가는 경로를 확인한다.
- a에서 b로 가는 최단 거리보다 a에서 k를 거쳐 b로 가는 거리가 더 좋은지 검사
점화식
- Dab = min(Dab, Dak + Dkb)

플로이드 워셜 알고리즘: 동작과정 살펴보기

[초기상태] 그래프를 준비하고, 최단거리 테이블 초기화

[Step1] 1번 노드를 거쳐가는 경우를 고려하여 테이블을 갱신

위 단계를 반복

플로이드 워셜 알고리즘 구현 코드

INF = int(1e9) # 무한을 의미하는 값으로 10억을 설정

# 노드의 개수 및 간선의 개수를 입력받기
n = int(input())
m = int(input())

# 2차원 리스트(그래프 표현)를 만들고, 무한으로 초기화
graph = [[INF] * (n + 1) for _ in range(n + 1)]

# 자기 자신에서 자기 자신으로 가는 비용은 0으로 초기화
for i in range(1, n + 1):
    for j in range(1, n + 1):
        if i == j:
            graph[i][j] = 0

# 각 간선에 대한 정보를 입력 받아, 그 값으로 초기화
for _ in range(m):
    # A에서 B로 가는 비용은 C라고 설정
    a, b, c = map(int, input().split())
    graph[a][b] = c

# 점화식에 따라 플로이드 워셜 알고리즘을 수행
for k in range(1, n + 1):
    for a in range(1, n + 1):
        for b in range(1, n + 1):
            graph[a][b] = min(graph[a][b], graph[a][k] + graph[k][b])

# 수행된 결과를 출력
for a in range(1, n + 1):
    for b in range(1, n + 1):
        # 도달할 수 없는 경우, 무한이라고 출력
        if graph[a][b] == INF:
            print('INFINITY', end=' ')
        else:
            print(graph[a][b], end=' ')
    print()

[Beakjoon][14502] 골드4 연구소 - Python

mellowg — Tue, 8 Oct 2024 01:45:17 +0900

연구소

시간제한: 2초
메모리 제한: 512MB

문제

인체에 치명적인 바이러스를 연구하던 연구소에서 바이러스가 유출되었다. 다행히 바이러스는 아직 퍼지지 않았고, 바이러스의 확산을 막기 위해서 연구소에 벽을 세우려고 한다.
연구소는 크기가 N x M인 직사각형으로 나타낼 수 있으며, 직사각형은 1 x 1 크기의 정사각형으로 나누어져 있다. 연구소는 빈 칸, 벽으로 이루어져 있으며, 벽은 칸 하나를 가득 차지한다.
일부 칸은 바이러스가 존재하며, 이 바이러스는 상하좌우로 인접한 빈 칸으로 모두 퍼져나갈 수 있다.
새로 세울 수 있는 벽의 개수는 3개이며, 꼭 3개를 세워야 한다.
예를 들어, 아래와 같이 연구소가 생긴 경우를 살펴보자.

이때, 0은 빈 칸, 1은 벽, 2는 바이러스가 있는 곳이다. 아무런 벽을 세우지 않았다면, 바이러스는 모든 빈 칸으로 퍼져나갈 수 있다.
2행 1열, 1행 2열, 4행 6열에 벽을 세운다면 지도의 모양은 아래와 같아지게 된다.

바이러스가 퍼진 뒤의 모습은 아래와 같아진다.

벽을 3개 세운 뒤, 바이러스가 퍼질 수 없는 곳을 안전 영역이라고 한다.
위의 지도에서 안전 영역의 크기는 27이다.
연구소의 지도가 주어졌을 때 얻을 수 있는 안전 영역 크기의 최댓값을 구하는 프로그램을 작성하시오.

입력

첫째 줄에 지도의 세로 크기 N과 가로 크기 M이 주어진다.( 3 <= N, M <= 8)
둘째 줄 부터 N개의 줄에 지도의 모양이 주어진다. 0은 빈 칸, 1은 벽, 2는 바이러스가 있는 위치이다.
2의 개수는 2보다 크거나 같고, 10보다 작거나 같은 자연수이다.
빈 칸의 개수는 3개 이상이다.

출력

첫째 줄에 얻을 수 있는 안전 영역의 최대 크기를 출력한다.

문제 아이디어

bfs/dfs문제 인 것 같은데 이를 활용하여 어떤 방식으로 구현해야 할지 감이 오지 않아서 다른 사람 풀이에서 주석을 통해 로직만 참고
1. 하나씩 펜스를 친다.
  - 펜스가 3개가 되면 바이러스 전파해서 안전영역 센다.
  - 3개 미만이면 펜스 계속 치기

✅ 정답 코드 (풀이 참고 + GPT 활용)

# 연구소
from sys import stdin
from collections import deque
import copy

input = stdin.readline

# 세로, 가로 입력
N, M = map(int, input().split())

# 연구소 지도 입력
lab = [list(map(int, input().split())) for _ in range(N)]

# 바이러스 위치 저장
viruses = []

# 빈곳 위치 저장
empty_spaces = []

for i in range(N):
    for j in range(M):
        if lab[i][j] == 2:
            viruses.append((i, j))
        elif lab[i][j] == 0:
            empty_spaces.append((i, j))

# 안전영역 최대값 저장
max_safe = -1

def virus_and_return_safe():
    global result
    directions = [(-1, 0), (1, 0), (0, -1), (0, 1)]
    temp_lab = copy.deepcopy(lab)
    queue = deque(viruses)

    while queue:
        x, y = queue.popleft()

        for dx, dy in directions:
            nx, ny = x + dx, y + dy
            if 0 <= nx < N and 0 <= ny < M and temp_lab[nx][ny] == 0:
                temp_lab[nx][ny] = 2
                queue.append((nx, ny))
    cnt = 0
    for i in range(N):
        cnt += temp_lab[i].count(0)

    result = max(result, cnt)



def make_wall(cnt, index):
    if cnt == 3:
        virus_and_return_safe()
        return
    for i in range(index, len(empty_spaces)):
        x, y = empty_spaces[i]
        lab[x][y] = 1
        make_wall(cnt + 1, i + 1)
        lab[x][y] = 0 # 백트래킹
result = 0
make_wall(0, 0)
print(result)

[Baekjoon][2206] 골드3 벽 부수고 이동하기 - Python

mellowg — Tue, 8 Oct 2024 00:16:45 +0900

벽부수고 이동하기

시간제한: 2초
메모리 제한: 192MB

문제

N x M의 행렬로 표현되는 맵이 있다.
맵에서는 0은 이동할 수 있는 곳을 나타내고, 1은 이동할 수 없는 벽이 있는 곳을 나타낸다.
당신은 (1,1) 에서 (N, M)의 위치까지 이동하려 하는데, 이때 최단 경로로 이동하려 한다.
최단경로는 맵에서 가장 적은 개수의 칸을 지나는 경로를 말하는데, 이때 시작하는 칸과 끝나는 칸도 포함해서 센다.
만약에 이동하는 도중에 한 개의 벽을 부수고 이동하는 것이 좀 더 경로가 짧아진다면, 벽을 한 개 까지 부수고 이동하여도 된다.
한 칸에서 이동할 수 있는 칸은 상하좌우로 인접한 칸이다.
맵이 주어졌을 때, 최단 경로를 구해내는 프로그램을 작성하시오.

입력

첫 줄에 N(1 <= N <= 1000), M(1 <= M <= 1000)이 주어진다.
다음 N개의 줄에 M개의 숫자로 맵이 주어진다.
(1,1)과 (N, M)은 항상 0이라고 가정하자.

출력

첫째 줄에 최단 거리를 출력한다. 불가능할 때는 -1을 출력한다.

문제 접근 아이디어

(1, 1)과 (N, M) 각각 하, 우와 상, 좌가 1인 경우 == -1
가다가 길이 끊기는 경우 == -1
DFS 알고리즘

❌ 2% 틀렸습니다.

너무 단순하게 예제 코드에만 맞춰서 생각한 것 같다.
다시 생각해보자.
DFS가 아니라 BFS로 풀어야 하는게 맞는 것 같음!

from sys import stdin

input = stdin.readline

N, M = map(int, input().split())
walls = []

for _ in range(N):
    walls.append(list(map(int, input().strip())))

# (1,1)과 (N,M)이 1로 가로막혀 있는지 확인
start = walls[0][1] and walls[1][0]
end = walls[N-1][M-2] and walls[N-2][M-1]

if start and end:
    print(-1)
    exit()


def dfs(graph, start):
    # start (x, y, value, walls-flag)
    stack = [start]

    # directions
    directionsX = [1, -1, 0, 0]
    directionsY = [0, 0, -1, 1]

    while stack:
        x, y, value, flag = stack.pop()
        # print(x, y, value, flag)
        # for g in graph:
        #     print(g)
        # print()

        graph[x][y] = min(value, graph[x][y]) if graph[x][y] > 1 else value

        for i in range(len(directionsX)):
            nx, ny = x + directionsX[i], y + directionsY[i]
            if 0 <= nx < N and 0 <= ny < M and graph[nx][ny] in [0, 1]:
                if flag:
                    if graph[nx][ny] == 0:
                        stack.append((nx, ny, value + 1, flag))
                else:
                    if graph[nx][ny] == 1:
                        stack.append((nx, ny, value + 1, True))
                    else:
                        stack.append((nx, ny, value + 1, flag))
    return graph

result = dfs(walls, (0, 0, 2, False))

if result[N-1][M-1] > 1:
    print(result[N-1][M-1] - 1)
else:
    print(-1)

❌ 메모리 초과 >> 이런,,

visited check할때 set 사용, 4 tuple 사용 등 이슈로 메모리 초과가 난 것 같다는 예상 >> 3차원 배열로 visited 선언해서 방문 체크로 변경

from sys import stdin
from collections import deque

input = stdin.readline

N, M = map(int, input().split())
walls = []

for _ in range(N):
    walls.append(list(map(int, input().strip())))

# (1,1)과 (N,M)이 1로 가로막혀 있는지 확인
start = walls[0][1] and walls[1][0]
end = walls[N-1][M-2] and walls[N-2][M-1]

if start and end:
    print(-1)
    exit()


def bfs(graph, start):
    # start (x, y, value, walls-flag)
    queue = deque([start])

    # directions
    directionsX = [-1, 1, 0, 0]
    directionsY = [0, 0, 1, -1]

    while queue:
        x, y, value, flag = queue.popleft()
        # print(x, y, value, flag)
        # for g in graph:
        #     print(g)
        # print(graph[x][y], value)
        # print()

        graph[x][y] = min(value, graph[x][y]) if graph[x][y] > 1 else value

        for i in range(len(directionsX)):
            nx, ny = x + directionsX[i], y + directionsY[i]
            if 0 <= nx < N and 0 <= ny < M and graph[nx][ny] in [0, 1]:
                if flag:
                    if graph[nx][ny] == 0:
                        queue.append((nx, ny, value + 1, flag))
                else:
                    if graph[nx][ny] == 1:
                        queue.append((nx, ny, value + 1, True))
                    else:
                        queue.append((nx, ny, value + 1, flag))
    return graph

result = bfs(walls, (0, 0, 2, False))

if result[N-1][M-1] > 1:
    print(result[N-1][M-1] - 1)
else:
    print(-1)


# 7 4
# 0000
# 1110
# 1000
# 1000
# 0000
# 0111
# 0000
# answer: 10

✅ 성공 코드

from sys import stdin
from collections import deque

input = stdin.readline

N, M = map(int, input().split())
walls = []

for _ in range(N):
    walls.append(list(map(int, input().strip())))

def bfs(graph, start):
    queue = deque([start])
    visited = [[[0, 0] for _ in range(M)] for _ in range(N)]
    visited[0][0][0] = 1 # 시작점 방문 표시

    # directions
    directions = [(-1, 0), (1, 0), (0, 1), (0, -1)]

    while queue:
        x, y, flag = queue.popleft()

        if x == N - 1 and y == M - 1:
            return visited[x][y][flag]

        for dx, dy in directions:
            nx, ny = x + dx, y + dy
            if 0 <= nx < N and 0 <= ny < M:
                # 벽이 아니고 아직 방문하지 않은 경우
                if graph[nx][ny] == 0 and visited[nx][ny][flag] == 0:
                    visited[nx][ny][flag] = visited[x][y][flag] + 1
                    queue.append((nx, ny, flag))
                # 벽이고 아직 벽을 부수지 않은 경우
                elif graph[nx][ny] == 1 and flag == 0 and visited[nx][ny][1] == 0:
                    visited[nx][ny][1] = visited[x][y][0] + 1
                    queue.append((nx, ny, 1))
    # 도달할 수 없을 경우
    return -1

print(bfs(walls, (0, 0, 0)))


# 7 4
# 0000
# 1110
# 1000
# 1000
# 0000
# 0111
# 0000
# answer: 10

[Beakjoon][7576] 골드5 - 토마토 Python

mellowg — Mon, 7 Oct 2024 16:43:12 +0900

토마토

시간 제한: 1초
메모리 제한: 256MB

문제

철수의 토마토 농장에서는 토마토를 보관하는 큰 창고를 가지고 있다. 토마토는 아래의 그림과 같이 격자 모양 상자의 칸에 하나씩 넣어서 창고에 보관한다.

창고에 보관되는 토마토들 중에는 잘 익은 것도 있지만, 아직 익지 않은 토마토들도 있을 수 있다.
보관 후 하루가 지나면, 익은 토마토들의 인접한 곳에 있는 익지 않은 토마토들은 익은 토마토의 영향을 받아 익게 된다.
하나의 토마토의 인접한 곳은 왼쪽, 오른쪽, 앞, 뒤 네 방향에 있는 토마토를 의미한다.
대각선 방향에 있는 토마토들에게는 영향을 주지 못하며, 토마토가 혼자 저절로 익는 경우는 없다고 가정한다.
철수는 창고에 보관된 토마토들이 며칠이 지나면 다 익게 되는지, 그 최소 일수를 알고 싶어 한다.
토마토를 창고에 보관하는 격자모양의 상자들의 크기와 익은 토마토들과 익지 않은 토마토들의 정보가 주어졌을 때, 며칠이 지나면 모두 익는지, 그 최소 일수를 구하는 프로그램을 작성하라.
단, 상자의 일부 칸에는 토마토가 들어있지 않을 수도 있다.

입력

첫 줄에는 상자의 크기를 나타내는 두 정수 M, N이 주어진다.
M은 상자의 가로 칸의 수, N은 상자의 세로 칸의 수를 나타낸다.
단, 2 <= M, N <= 1000 이다. 둘째 줄부터는 하나의 상자에 저장된 토마토들의 정보가 주어진다. 즉, 둘째 줄부터 N개의 줄에는 상자에 담긴 토마토의 정보가 주어진다. 하나의 줄에는 상자 가로줄에 들어있는 토마토의 상태가 M개의 정수로 주어진다. 정수 1은 익은 토마토, 정수 0은 익지 않은 토마토, 정수 -1은 토마토가 들어있지 않은 칸을 나타낸다.
토마토가 하나 이상 있는 경우만 주어진다.

출력

여러분은 토마토가 모두 익을 때까지의 최소 날짜를 출력해야 한다.
만약, 저장될 때부터 모든 토마토가 익어있는 상태이면 0을 출력해야 하고, 토마토가 모두 익지는 못하는 상황이면 -1을 출력해야 한다.

문제 풀이 아이디어

알고리즘: BFS
end 조건:
1. 토마토가 모두 익은 상태: set(Tomato) == {1, -1} 인 경우
2. 토마토가 모두 익지 못하는 상황: 0인 토마토 주위에 -1만 있는 경우

❌ 85% 틀렸습니다 코드

어떤 예외처리를 못했을지 고민,,
마지막에 bfs돌린 후 모든 토마토가 익었는지 안익었는지 확인하는 코드를 빼먹음

from sys import stdin
from collections import deque
input = stdin.readline


M, N = map(int, input().split())
# M 가로, N 세로
tomatoes = []
set_tomatoes = set()
day = 0

for _ in range(N):
    inputs = list(map(int, input().split()))
    set_tomatoes.update(set(inputs))
    tomatoes.append(inputs)

# 현재 모든 토마토가 있었는지 확인하기
if len(set_tomatoes) == 1 and set_tomatoes.pop() == 1:
    print(0)
    exit()

# 익은 토마토가 없는 경우
if 1 not in set_tomatoes:
    print(-1)
    exit()

queue = deque([])

# 익은 토마토들 queue에 담기
for x in range(N):
    for y in range(M):
        if tomatoes[x][y] == 1:
            queue.append((x, y))

# bfs
def bfs(graph, queue):
    # 상 하 좌 우
    directionX = [-1, 1, 0, 0]
    directionY = [0, 0, -1, 1]

    next = deque([])

    while queue:
        x, y = queue.popleft()
        for i in range(len(directionX)):
            nx, ny = x + directionX[i], y + directionY[i]
            if 0 <= nx < N and 0 <= ny < M and graph[nx][ny] == 0:
                graph[nx][ny] = 1
                next.append((nx, ny))
    return graph, next

while queue:
    tomatoes, queue = bfs(tomatoes, queue)
    day += 1
    # print(day, queue)
    # 
    # for tomato in tomatoes:
    #     print(tomato)

print(day - 1)

✅ 정답 코드

from sys import stdin
from collections import deque
input = stdin.readline


M, N = map(int, input().split())
# M 가로, N 세로
tomatoes = []
set_tomatoes = set()
day = 0

for _ in range(N):
    inputs = list(map(int, input().split()))
    set_tomatoes.update(set(inputs))
    tomatoes.append(inputs)

# 현재 모든 토마토가 있었는지 확인하기
if len(set_tomatoes) == 1 and set_tomatoes.pop() == 1:
    print(0)
    exit()

# 익은 토마토가 없는 경우
if 1 not in set_tomatoes:
    print(-1)
    exit()

queue = deque([])

# 익은 토마토들 queue에 담기
for x in range(N):
    for y in range(M):
        if tomatoes[x][y] == 1:
            queue.append((x, y))

# bfs
def bfs(graph, queue):
    # 상 하 좌 우
    directionX = [-1, 1, 0, 0]
    directionY = [0, 0, -1, 1]

    next = deque([])

    while queue:
        x, y = queue.popleft()
        for i in range(len(directionX)):
            nx, ny = x + directionX[i], y + directionY[i]
            if 0 <= nx < N and 0 <= ny < M and graph[nx][ny] == 0:
                graph[nx][ny] = 1
                next.append((nx, ny))
    return graph, next

while queue:
    tomatoes, queue = bfs(tomatoes, queue)
    day += 1

for tomato in tomatoes:
    # 익지 않은 토마토가 있는지 확인
    if 0 in tomato:
        print(-1)
        exit()
print(day - 1)

Dijkstra Algorithm(다익스트라 알고리즘) 최단경로 알고리즘

mellowg — Fri, 4 Oct 2024 14:10:54 +0900

Dijkstra Algorithm(다익스트라 알고리즘) 최단경로 알고리즘

최단 경로 알고리즘

최단 경로 알고리즘은 가장 짧은 경로를 찾는 알고리즘을 의미한다.
다양한 문제 상황
- 한 지점에서 다른 한 지점까지의 최단 경로
- 한 지점에서 다른 모든 지점까지의 최단 경로
- 모든 지점에서 모든 지점까지의 최단 경로
각 지점은 그래프에서 노드로 표현
지점 간 연결된 도로는 그래프에서 간선으로 표현

다익스트라 최단 경로 알고리즘 개요

특정 노드에서 출발하여 다른 모든 노드로 가는 최단 경로를 계산한다.
다익스트라 최단 경로 알고리즘은 음의 간선이 없을 때 정상적으로 동작
- 현실세계의 도로는 음의 간선으로 표현되지 않음
다익스트라 최단 경로 알고리즘은 그리디 알고리즘으로 분류된다.
- 매 상황에서 가장 비용이 적은 노드를 선택해 임의의 과정을 반복

다익스트라 동작 과정

출발 노드를 설정한다.
최단 서리 테이블을 초기화한다.
방문하지 않은 노드중에서 최단 거리가 가장 짧은 노드를 선택한다.
해당 노드를 거쳐 다른 노드로 가는 비용을 계산하여 최단 거리 테이블을 갱신한다.
위 과정에서 3번과 4번의 과정을 반복한다.

다익스트라 알고리즘의 특징

그리디 알고리즘: 매 상황에서 방문하지 않은 가장 비용이 적은 노드를 선택해 임의의 과정을 반복
단계를 거치며 한 번 처리된 노드의 최단거리는 고정되어 더 이상 바뀌지 않는다.
- 한 다계당 하나의 노드에 대한 최단거리를 확실히 찾는 것
다익스트라 알고리즘을 수행한 뒤에 테이블에 각 노드까지의 최단거리 정보가 저장된다.
- 완변한 형태의 최단 경로를 구하려면 소스코드에 추가적인 기능을 더 넣어야 한다.

다익스트라 알고리즘: 간단한 구현 방법

단계 마다 방문하지 않은 노드 중에서 최단 거리가 가장 짧은 노드를 선택하기 위해 매 단계마다 1차원 테이블의 모든 원소를 확인(순차 탐색)

from sys import stdin
input = stdin.readline
INF = int(1e9) # 무한을 의미하는 10억을 설정

# 노드의 개수, 간선의 개수를 입력받기
n, m = map(int, input().split())

# 시작 노드 번호를 입력받기
start = int(input())

# 각 노드에 연결되어 있는 노드에 대한 정보를 담는 리스트를 만들기
graph = [[] for _ in range( n + 1 )]

# 방문한 적이 있는지 체크하는 목적의 리스트를 만들기
visited = [False] * ( n + 1 )

# 최단 거리 테이블을 모두 무한으로 초기화
distance = [INF] * (n + 1)

# 모든 간선 정보를 입력받기
for _ in range(m):
    a, b, c = map(int, input().split())
    graph[a].append((b,c))

# 방문하지 않은 노드 중에서, 가장 최단 거리가 짧은 노드의 번호를 반환
def get_smallest_node():
    min_value = INF
    index = 0 # 가장 최단 거리가 짧은 노드(인덱스)
    for i in range(1, n+1):
        if distance[i] < min_value:
            min_value = distance[i]
            index = i
    return index

def dijkstra(start):
    # 시작 노드에 대해서 초기화
    distance[start] = 0
    visited[start] = True

    for j in graph[start]:
        distance[j[0]] = j[1]

    # 시작 노드를 제외한 전체 n -1 개의 노드에 대해 반복
    for i in range(n - 1):
        # 현재 최단 거리가 가장 짧은 노드를 꺼내서, 방문 처리
        now = get_smallest_node()
        visited[now] = True
        # 현재 노드와 연결된 다른 노드를 확인
        for j in graph[now]:
            cost = distance[now] + j[1]
            # 현재 노드를 거쳐서 다른 노드로 이동하는 거리가 더 짧은 경우
            if cost < distance[j[0]]:
                distance[j[0]] = cost

# 다익스트라 알고리즘을 수행
dijkstra(start)

# 모든 노드로 가기 위한 최단 거리를 출력
for i in range(1, n + 1):
    if distance[i] == INF:
        print("INFINITY")
    else:
        print(distance[i])

다익스트라 알고리즘: 간단한 구현 방법 - 성능 분석

총 O(V)번에 걸쳐서 최단거리가 가장 짧은 노드를 매번 선형탐색
따라서 전체 시간복잡도는 O(V^2)이다.
일반적으로 코딩테스트의 최단경로 문제에서 전체 노드의 수가 5000개 이하 이면 이 간단한 구현 방법으로도 가능하다.
- 그러나 노드가 10000개 이상이라면?
  - heapq 자료구조를 이용해야 한다.

우선순위 큐 (Prioirity Queue)

우선순위가 가장 높은 데이터를 가장 먼저 삭제하는 자료구조이다.

힙 (Heap)

우선순위큐를 구현하기 위해 사용하는 자료구조 중 하나이다.
최소힙(Min Heap)과 최대힙(Max Heap)이 있다.
다익스트라를 포함해 다양한 알고리즘에 사용된다.

힙 라이브러리 사용 예제: 최소힙

import heapq

def heapsort(iterable):
	h = []
    result = []
    
    for value in iterable:
    	heapq.heappush(h, value)
	for i in range(len(h)):
    	result.append(heapq.heappop(h))
	return result
    
result = heapsort([1,3,5,7,9,2,4,6,8,0])
print(result)

# [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

다익스트라 알고리즘 - 개선된 구현 방법

단계마다 방문하지 않은 노드중에 최단거리가 가장 짧은 노드를 선택하기 위해 힙(heap) 자료구조를 이용한다.
다익스트라 알고리즘이 동작하는 기본 원리는 동일하다
- 현재 가장 가까운 노드를 저장해 놓기 위해서 힙 자료구조를 추가적으로 이용한다는 점이 다르다.
- 현재의 최단 거리가 가장 짧은 노드를 선택해야 하므로 최소 힙을 사용한다.

import heapq
from sys import stdin

input = stdin.readline
INF = int(1e9) # 무한을 의미하는 값으로 10억을 설정

# 노드의 개수, 간선의 개수를 입력받기
n, m = map(int, input().split())

# 시작 노드 번호를 입력받기
start = int(input())

# 각 노드에 연결되어 있는 노드에 대한 정보를 담는 리스트를 만들기
graph = [[] for _ in range(n + 1)]

# 최단 거리 테이블을 모두 무한으로 초기화
distance = [INF] * (n + 1)

# 모든 간선 정보를 입력받기
for _ in range(m):
    a, b, c = map(int, input().split())
    # a번 노드에서 b노드로 가는 비용이 c라는 의미
    graph[a].append((b,c))

def dijkstra(start):
    q = []
    # 시작 노드로 가기 위한 최단 경로는 0으로 설정하여, 큐에 삽입
    heapq.heappush(q, (0, start))
    distance[start] = 0
    while q: # 큐가 비어있지 않다면
        # 가장 최단 거리가 짧은 노드에 대한 정보 꺼내기
        dist, now = heapq.heappop(q)
        # 현재 노드가 이미 처리된 적이 있는 노드라면 무시
        if distance[now] < dist:
            continue
        # 현재 노드를 거쳐서, 다른 노드로 이동하는 거리가 더 짧은 경우
        for i in graph[now]:
            cost = dist + i[1]
            # 현재 노드를 거쳐서, 다른 노드로 이동하는 거리가 더 짧은 경우
            if cost < distance[i[0]]:
                distance[i[0]] = cost
                heapq.heappush(q, (cost, i[0]))

# 다익스트라 알고리즘을 수행
dijkstra(start)

# 모든 노드로 가기 위한 최단 거리를 출력
for i in range(1, n + 1):
    # 도달할 수 없는 경우, 무한 이라고 출력
    if distance[i] == INF:
        print('INFINITY')
    else:
        print(distance[i])

DFS & BFS 기초 문제 풀이

mellowg — Wed, 2 Oct 2024 01:30:23 +0900

이전 내용

DFS & BFS 기초 문제 풀이

<문제> 음료수 얼려 먹기: 문제 설명

N x M 크기의 얼음 틀이 있습니다. 구멍이 뚫려 있는 부분은 0, 칸막이가 존재하는 부분은 1로 표시됩니다. 구멍이 뚫려 있는 부분끼리 상, 하 , 좌, 우로 붙어 있는 경우 서로 연결되어 있는 것으로 간주합니다.
이때 얼음 틀의 모양이 주어졌을 때 생성되는 총 아이스크림의 개수를 구하는 프로그램을 작성하세요. 다음의 4 x 5 얼음 틀 예시는 아이스크림이 총 3개 생성됩니다.

✅ 문제 풀이 접근 및 내 코드

(0,0)을 start로 BFS를 통해 나누어진 구역의 개수를 카운트 한다.

from collections import deque

n, m = map(int, input().split())
maps = []

# 1. 입력값 세팅
for _ in range(n):
    maps.append(list(input().strip()))

# 2. BFS 메소드 정의
directions = [(-1, 0), (0, -1), (0, 1), (1, 0)]
def bfs(maps, cnt):
    for i in range(len(maps)):
        for j in range(len(maps[0])):
            if maps[i][j] == '0':
                start = (i, j)
                break

    queue = deque([start])
    maps[start[0]][start[1]] = '1'

    while queue:
        x, y = queue.popleft()
        maps[x][y] = cnt
        for dx, dy in directions:
            nx, ny = x + dx, y + dy
            if 0 <= nx < len(maps) and 0 <= ny < len(maps[0]) and maps[nx][ny] == '0':
                queue.append((nx, ny))
                maps[nx][ny] = '1'
    return maps


def check0(maps):
    for m in maps:
        if '0' in m:
            return True
    return False

cnt = 0
while check0(maps):
    cnt += 1
    maps = bfs(maps, cnt)
print(cnt)

문제 해결 아이디어 및 해설 풀이 코드

DFS를 활용하는 알고리즘은 다음과 같다.
1. 특정한 지점의 상, 하, 좌, 우를 살펴본 뒤에 주변 지점 중에 값이 '0'이면서 아직 방문하지 않은 지점이 있다면 해당 지점을 방문
2. 방문한 지점에서 다시 상, 하, 좌, 우를 살펴보면서 방문을 진행하는 과정을 반복하면, 연결된 모든 지점을 방문할 수 있다.
3. 모든 노드에 대하여 1~2번의 과정을 반복하며, 방문하지 않은 지점의 수를 카운트 한다.

# DFS로 특정 노드를 방문하고 연결된 모든 노드들도 방문
def dfs(x, y):
	# 주어진 범위를 벗어나는 경우에는 즉시 종료
    if x <= -1 or x >= n or y <= -1 or y >= m:
    	return False
	# 현재 노드를 아직 방문하지 않았다면
    if graph[x][y] == 0:
		# 해당 노드 방문처리
        graph[x][y] = 1
        dfs(x -1, y)
        dfs(x, y -1)
        dfs(x + 1, y)
        dfs(x, y + 1)
        return True
	return False

# N, M 을 공백을 기준으로 구분하여 입력 받기
n, m = map(int, input().split())

# 2 차원 리스트의 맵 정보 입력 받기
graph = []
for i in range(n):
	graph.append(list(map(int, input()))
    
# 모든 노드(위치)에 대하여 음료수 채우기
result = 0
for i in range(n):
	for j in range(m):
    	# 현재 위치에서 DFS 수행
        if dfs(i, j) == True:
        	result += 1
print(result)

<문제> 미로 탈출: 문제 설명

00이는 N x M 크기의 직사각형 형태의 미로에 갖혔습니다. 미로에는 여러 마리의 괴물이 있어 이를 피해 탈출해야 합니다.
00이의 위치는 (1,1)이며 미로의 출구는 (N, M)의 위치에 존재하며 한 번에 한 칸씩 이동할 수 있습니다. 이때 괴물이 있는 부분은 0으로, 괴물이 없는 부분은 1로 표시되어 있습니다. 미로는 반드시 탈출할 수 있는 형태로 제시됩니다.
이때 00이가 탈출하기 위해 움직여야 하는 최소 칸의 개수를 구하세요. 칸을 셀 때는 시작 칸과 마지막 칸을 모두 포함해서 계산합니다.

✅ 문제 풀이 접근 및 내 코드 >> 최단거리를 구해야 하기 때문에 DFS가 아닌 BFS가 적합

DFS를 활용하여 구현
오른쪽, 아래 이동하는 것을 우선으로 탐색하도록 구현

n, m = map(int, input().split())
maps = []

# 1. 입력값 세팅
for _ in range(n):
    maps.append(list(map(int, input())))

directions = [(0, 1), (1, 0), (-1, 0), (0, -1)]

def dfs(maps, start):
    stack = [(start)]
    visited = set()
    visited.add(start)

    step = 2

    while stack:
        x, y = stack.pop()

        if x == len(maps)-1 and y == len(maps[0])-1:
            maps[x][y] = step
            break
        if maps[x][y] == 1:
            maps[x][y] = step
            step += 1

        for dx, dy in directions:
            nx, ny = x + dx, y + dy
            if 0 <= nx < len(maps) and 0 <= ny < len(maps[0]):
                if maps[nx][ny] == 1:
                    stack.append((nx, ny))
                    break



dfs(maps, (0,0))
print(maps[-1][-1] - 1)



# 5 6
# 101010
# 111111
# 000001
# 111111
# 111111

문제 해결 아이디어 및 해설 풀이 코드

BFS는 시작 지점에서 가까운 노드부터 차례대로 그래프의 모든 노드를 탐색한다.
상, 하, 좌, 우로 연결된 모든 노드로의 거리가 1로 동일하다.
- 따라서 (1,1)지점부터 BFS를 수행하여 모든 노드의 최단 거리 값을 기록하면 해결할 수 있다.

from collections import deque
# BFS 소스코드 구현
def bfs(x, y):
	# 큐 구현을 위해 deque 라이브러리 사용
    queue = deque((x,y))
    
    # 큐가 끝날때까지 반복하기
    while queue:
    	x, y = queue.popleft()
        
        # 현재 위치에서 4가지 방향으로의 위치 확인
        for i in range(4):
        	nx = x + dx[i]
            ny = y + dy[i]
            
            if nx < 0 or nx >= n or ny < 0 or ny >= m:
	            continue
			# 벽인 경우 무시
            if graph[nx][ny] == 0:
            	continue
			# 해당 노드를 처음 방문하는 경우에만 최단 거리 기록
            if graph[nx][ny] == 1:
            	graph[nx][ny] = graph[x][y] + 1
                queue.append((nx, ny))
	return grpah[n-1][m-1]

n, m = map(int, input().split())

graph = []

for i in range(n):
	graph.append(list(map(int, input())))

dx = [-1, 1, 0, 0]
dy = [0, 0, -1, 1]

print(bfs((0,0)))

BFS(Breath-First-Search) Algorithm

mellowg — Wed, 2 Oct 2024 01:05:07 +0900

BFS(Breath-First-Search) Algorithm

BFS는 너비 우선 탐색이라고도 부르며, 그래프에서 가까운 노드부터 우선적으로 탐색하는 알고리즘이다.
BFS는 큐 자료구조를 이용하며, 구체적인 동작 과정은 다음과 같다.
1. 탐색 노드를 큐에 삽입하고, 방문처리한다.
2. 큐에서 노드를 꺼낸 후 해당 노드와 인접한 방문하지 않은 모든 노드를 큐에 삽입하고 방문처리한다.
3. 2번 과정을 더 이상 할 수 없을때까지 반복한다.
사용되는 문제: 각 간선의 비용이 모두 동일한 상황에서 최단거리 찾는문제 등

구현 코드


from collections import deque

# BFS 메서드 정의
def bfs(graph, start, visited):
    # 큐 구현을 위해 deque 라이브러리 사용
    queue = deque([start])
    # 현재 노드를 방문 처리
    visited[start] = True

    # 큐다 빌 때까지 반복
    while queue:
        # 큐에서 하나의 원소를 뽑아 출력하기
        v = queue.popleft()
        print(v, end=' ')

        # 아직 방문하지 않은 인접한 원소들을 큐에 삽입
        for i in graph[v]:
            if not visited[i]:
                queue.append(i)
            visited[i] = True


# 각 노드가 연결된 정보를 표현(2차원 배열)
graph = [
    [],
    [2, 3, 8],
    [1, 7],
    [1, 4, 5],
    [3, 5],
    [3, 4],
    [7],
    [2, 6, 8],
    [1, 7]
]

# 정의된 BFS 함수 호출
bfs(graph, 1, visited=[False] * 9)

# 실행 결과
# 1 2 3 8 7 4 5 6

DFS(Depth-First-Search) Algorithm

mellowg — Wed, 2 Oct 2024 00:53:29 +0900

DFS(Depth-First-Search) Algorithm

DFS는 깊이 우선 탐색이라고도 부르며, 그래프의 깊은 부분을 우선적으로 탐색하는 알고리즘이다.
DFS는 Stack 자료구조(혹은 재귀함수)를 이용하며, 구체적인 동작 과정은 다음과 같다.
1. 탐색 시작노드를 스택에 넣고, 방문처리한다.
2. 스택의 최상단 노드와 인접한 노드 중 방문하지 않은 노드가 있다면, 그 노드를 스택에 넣고 방문처리한다. 방문하지 않은 인접 노드가 없다면 스택 최상단 노드를 pop한다.
3. 2번의 과정을 수행할 수 없을때까지(stack이 empty할때까지) 반복한다.

재귀함수로 DFS 구현

# DFS 메서드 정의
def dfs(graph, v, visited):
	# 현재 노드를 방문 처리
    visited[v] = True
    print(v, end=' ')
    
    # 현재 노드와 연결된 다른 노드를 재귀적으로 방문
    for i in graph[v]:
    	if not visited[i]:
        	dfs(graph, i, visited)

# 각 노드가 연결된 정보를 표현(2차원 배열)
graph = [
	[],
    [2, 3, 8],
    [1, 7],
    [1, 4, 5],
    [3, 5],
    [3, 4],
    [7], 
    [2, 6, 8],
    [1, 7]
]

# 각 노드가 방문된 정보를 표현 (1차원 리스트)
visited = [False] * 9

# 정의된 DFS 함수 호출
dfs(graph, 1, visited)

# 실행 결과
# 1 2 7 6 8 3 4 5

재귀함수로 DFS 구현

# DFS 메서드 정의
def dfs(graph, v):
    visited = [False] * len(graph)
    stack = []
    stack.append(v)

    while stack:
        v = stack.pop()

        if not visited[v]:
            print(v, end=' ')
            visited[v] = True

        for w in sorted(graph[v], reverse=True):
            if not visited[w]:
                stack.append(w)

# 각 노드가 연결된 정보를 표현(2차원 배열)
graph = [
    [],
    [2, 3, 8],
    [1, 7],
    [1, 4, 5],
    [3, 5],
    [3, 4],
    [7],
    [2, 6, 8],
    [1, 7]
]

# 정의된 DFS 함수 호출
dfs(graph, 1)

# 실행 결과
# 1 2 7 6 8 3 4 5

Greedy Algorithm (탐욕 알고리즘)

mellowg — Tue, 1 Oct 2024 02:14:19 +0900

이것이 코딩테스트다 with 파이썬

Greedy Algorithm (탐욕 알고리즘)

현재 상황에서 지금 당장 좋은 것만 고르는 방법
일반적인 상황에서 그리디 알고리즘은 최적의 해를 보장할 수 없다. >> 정당성 분석이 중요!
그러나 코테 문제에서는 일반적으로 탐욕법으로 얻은 해가 최적의 해가 되는 상황에서 이론 추론해야 풀리도록 출제
대표적인 그리디 알고리즘 문제 - 거스름돈 문제

<문제1> 1이 될 때까지: 문제 설명

어떠한 수 N이 1이 될 때까지 다음의 두 과정 중 하나를 반복적으로 선택하여 수행하려고 함.

단, 두 번째 연산은 N이 K로 나누어 떨어질 때만 선택할 수 있음.

1. N에서 1을 뺀다.

2. N을 K로 나눈다.

ex) N이 17, K가 4라고 가정. 이때 1번의 과정을 한 번 수행하면 N은 16이 된다. 이후에 2번의 과정을 두 번 수행하면 N은 1이 된다. 결과적으로 전체 과정을 실행한 횟수는 3 이 된다.

N과 K가 주어질 때 N이 될 때 까지 1번 혹은 2번의 과정을 수행해야 하는 최소 횟수를 구하는 프로그램 작성

# N, K을 공백을 기준으로 구부낳여 입력 받기
N, K = map(int, input().split())

result = 0

while True:
	# N이 K로 나누어 떨어지는 수가 될 때까지 빼기
    target = (N // K) * K
    result += (n - target)
    
    n = target
    # N이 K보다 작을 때(더 이상 K로 나눌 수 없을 때) 반복문 탈출
    if N < K:
    	break
        
    # K로 나누기
    result += 1
    N //= K
# 마지막으로 남은 수에 대하여 1씩 빼기
result += (N -1)
print(result)

<문제2> 곱하기 혹은 더하기: 문제 설명

각 자리가 숫자(0부터 9)로만 이루어진 문자열 S가 주어졌을 때, 왼쪽부터 오른쪽으로 하나씩 모든 숫자를 확인하며 숫자 사이에 'x' 혹은 '+' 연산자를 넣어 결과적으로 만들어질 수 있는 가장 큰 수를 구하는 프로그램 작성

단, +보다 x를 먼저 계산하는 일반적인 방식과는 달리, 모든 연산은 왼쪽에서부터 순서대로 이루어진다고 가정

ex) 02984 라는 문자열로 만들 수 있는 가장 큰 수는 ((((0+2) * 9) * 8) * 4) = 576입니다. 또한 만들어질 수 있는 가장 큰 수는 항상 20억 이하의 정수가 되도록 입력이 주어진다.

대부분의 경우 '+' 보다는 'x'가 더 값을 크게 만듬.
두 수 중에서 하나라도 '0' 혹은 '1'인 경우, 곱하기보다 더하기를 수행하는 것이 효율적
따라서 두 수에 대하여 연산을 진행할 때, 두 수 중에서 하나라도 1 이하인 경우에는 더하며, 두 수가 모두 2 이상인 경우에는 곱하면 정답

strings = list(map(int, input().strip()))

result = 0

for s in strings:
    if s <= 1 or result <= 1:
        result += s
    else:
        result *= s
print(result)

<문제3> 모험가 길드: 문제설명

한 마을에 모험가가 N명이 있다. 모험가 길드에서는 N명의 모험가를 대상으로 '공포도'를 측정했는데, '공포도'가 높은 모험가는 쉽게 공포를 느껴 위험 상황에서 제대로 대처할 능력이 떨어진다.

모험가 길드장인 00이는 모험가 그룹을 안전하게 구성하고자 공포도가 X인 모험가는 반드시 X명 이상으로 구성한 모험가 그룹에 참여해야 여행을 떠날 수 있도록 규정했다.

풀이 방법
1. 공포도 오름차순 정렬
2. 앞에서부터 공포도를 하나씩 확인하며 '현재 그룹에 포함된 모험가의 수'가 '현재 확인하고 있는 공포도' 보다 크거나 같다면 이를 그룹으로 설정하면 된다.

n = int(input())
data =list(map(int, input().split()))
data.sort()

result = 0 # 총 그룹의 수
count = 0 # 현재 그룹에 포함된 모험가의 수

for i in data: # 공포도를 낮은 것부터 하나씩 확인하며
	count += 1 # 현재 그룹에 해당 모험가를 포함시키기
    if count >= i: # 현재 그룹에 포함된 모험가의 수가 현재의 공포도 이상이라면, 그룹 결성
    	result += 1 # 총 그룹의 수 증가
        count = 0 # 현재 그룹에 포함된 모험가의 수 초기화
print(result)

실전에서 자주 사용되는 파이썬 표준 라이브러리

mellowg — Tue, 1 Oct 2024 01:30:17 +0900

실전에서 자주 사용되는 표준 라이브러리

1. itertools: 반복되는 형태의 데이터 처리를 위한 함수 제공

ex) 순열 조합

2. heapq: 힙(Heap) 자료구조 제공

일반적으로 우선순위큐 구현시 사용

3. bisect: 이진 탐색(Binary Search) 기능을 제공

4. collections: 데크(dequeue), 카운터(Counter) 등의 자료구조 제공

5. amth: 필수적인 수학적 기능 제공

ex) 팩토리얼, 최대 공약수(GDC), 최소 공배수(LCM), 파이(Pi) 등 제공

순열과 조합 - itertools 라이브러리

순열 (permutations)
- 서로 다른 n개에서 서로 다른 r개를 선택하여 일렬로 정렬(순서 고려)
- 중복고려 버전 > product()
조합 (combinations)
- 서로 다른 n개에서 서로 다른 r개를 선택 (순서 고려 X)
- 중복고려 버전 > combinations_with_replacement()

Counter - collections 라이브러리

등장 횟수를 세는 라이브러리

from collections import Counter

arr = ['blue', 'blue', 'red', 'blue', 'red', 'yellow', 'blue']
counter = Counter(arr)

print(counter['red'])
print(counter['blue'])
print(counter['yellow'])
print(dict(counter))

# 출력 결과
# 2
# 4
# 1
# {'blue': 4, 'red': 2, 'yellow': 1}

최대공약수와 최소공배수 - math 라이브러리

최대공약수 - GCD
최소공배수 - LCM

[정보보안기사/필기] PART2. 암호학 (1)

mellowg — Sun, 29 Sep 2024 11:42:20 +0900

✅ 암호학기법의 분류

치환 암호(대치 암호): 비트, 문자 또는 문자의 블록을 다른 비트, 문자 또는 블록으로 대체
전치 암호: 비트, 문자 또는 블록이 원래 의미를 감추도록 재배열
블록 암호: 특정 비트 수의 집합을 한 번에 처리하는 암호 알고리즘을 총칭
스트림 암호: 한번에 1비트 혹은 1바이트의 데이터 흐름(스트림)을 순차적으로 처리해가는 암호 알고리즘의 총칭
링크 암호화: 모든 정보는 암호화되고, 패킷은 라우터나 다른 중간에 있는 장비가 이 패킷을 다음에 어디로 보내야 하는지 알아야 하기 때문에 각 홉(hop)에서 해독됨
종단간 암호화: 종단간 암호화에서는 헤더와 트레일러가 암호화되지 않기 때문에 패킷을 각 홉에서 해독하고 암호화할 필요가 없음
하드웨어 암호: 하드웨어로 실현하기 위해 컴퓨터와 통신기기의 내부버스와 외부 인터페이스에 전용 암호처리용 하드웨어를 설치하여 데이터를 암호화
소프트웨어 암호화: 소프트웨어에 의한 실현은 암호처리용 소프트웨어를 사용한 데이터 암호화

✅ 블록 암호와 스트림 암호

스트림 암호:
- 장점: 암호화 속도가 빠름, 에러 전파현상 없음
- 단점: 낮은 확산
- 사례: LFSR, MUX generator
- 암호화 단위: 비트
- 주요 대상: 음성, 오디오/비디오 스트리밍
블록 암호:
- 장점: 높은 확산, 기밀성, 해시함수 등 다양
- 단점: 느린 암호화, 에러 전달
- 사례: DES, IDEA, SEED, RC5, AES
- 암호화 단위: 블록
- 주요 대상: 일반 데이터 전송, 스토리지 저장

✅ 링크 암호화와 종단간 암호화

링크 암호화
- 특징:
  - ISP나 통신업자가 암호화
  - 헤더를 포함한 모든 데이터를 암호화
  - 유저가 알고리즘 통제 불가
- 장점:
  - User-transparent하게 암호화되므로 운영이 간단
  - 트래픽분석을 어렵게 함
  - 온라인으로 암호화
- 단점:
  - 중간 노드에서 데이터가 평문으로 노출
  - 다양한 보안서비스를 제공하는데 한계
  - 모든 노드가 암호화 장비를 갖추어야 하므로 네트워크가 커지면 비용 과다
종단간 암호화
- 특징:
  - 사용자가 암호화
  - 헤더(라우팅정보)는 암호화하지 않음
  - 알고리즘에 대한 통제는 사용자가 함
- 장점:
  - 사용자 인증 등 높은 수준의 보안 서비스를 제공 가능
  - 중간노드에서도 데이터가 암호문으로 존재
- 단점:
  - 트래픽분석이 취약
  - 오프라인으로 암호화

✅ 스테가노그래피, 워터마크, 핑거프린팅

메타데이터(Metadata): 콘텐츠 생명주기 범위 내에서 관리되어야 할 각종 데이터의 구조 및 정보
패키저(Packager): 보호 대상인 콘텐츠를 메타데이터와 함께 Secure Container 포맷으로 패키징 하는 모듈
시큐어 컨테이너(Secure Container): DRM의 보호 범위 내에서 유통되는 콘텐츠의 배포 단위
식별자(Identifier): 콘텐츠를 식별하기 위한 식별자
DRM 제어기(DRM Controller): 콘텐츠를 이용하는 사용자의 PC 또는 디바이스 플랫폼에서 콘텐츠가 라이선스에 명시된 범위 내에서 지속적으로 보호될 수 있도록 프로세스를 제어
클리어링하우스(Clearinghouse): 디지털 허가를 소비자에게 발급해주고 콘텐츠 제공자에게 로열티 수수료를 지불하고, 배금자에게 해당되는 배급 수수료를 지불하는 재정적 거래를 취급 (사용자에게 콘텐츠 라이센스를 발급하고 권한을 부여해 주는 시스템)

✅ 암호분석의 분류

암호문 단독 공격(COA:: Ciphertext Only Attack)
- 개념: 단지 암호문 C만을 갖고 이로부터 평문 P이나 키 K를 찾아내는 방법으로 평문 P의 통계적 성질, 문장의 특성 등을 추정해서 해독하는 방법
- 비고: 암호해독자에게는 가장 불리한 방법
기지 평문 공경(KPA:: Known Plaintext Attack)
- 개념: 암호문 C와 평문 P의 관계로부터 키 K나 평문 P를 추정하여 해독하는 방법
- 비고: 암호문에 대응하는 일부 평문이 사용가능한 상황에서의 공격
선택 평문 공격(CPA:: Choosen Plaintext Attack)
- 개념: 암호기에 접근할 수 있어 평문 P를 선택하여 그 평문 P에 해당하는 암호문 C를 얻어 키K나 평문P를 추정하여 암호를 해독하는 방법
- 비고: 평문을 선택하면 대응하는 암호문을 얻을 수 있는 상황에서의 공격
선택 암호문 공격(CCA:: Choosen Ciphertext Attack)
- 개념: 암호 복호기에 접근할 수 있어 암호문 C에 대한 평문 P를 얻어내 암호를 해독하는 방법
- 비고: 암호문을 선택하면 대응하는 평문을 얻을 수 있는 상황에서의 공격

✅ 암호 기술 평가

암호 알고리즘 평가
- 정보보호제품에 탐재된 암호 알고리즘에 대한 안정성 평가
암호모듈 평가
- 알고리즘 자체의 이론적 안정성과는 별도로 암호서비스 기능을 제공하는 암호모듈의 안정성에 대한 평가(CMVP, KCMVP)
정보보호제품평가
- 암호모듈을 탑재한 정보보호 제품(예: 침입차단시스템)에 대한 안정성을 평가
응용시스템 평가
- 각 제품을 상호 연동하여 구성되는 시스템(예: 항공관제센터의 안전성 평가)에 대한 안전성 평가

✅ P 박스

입력(n), 출력(m)
단순(straight):
- m = n
- 역함수 O
축소(compression)
- n > m
- 역함수 X
- 비트수 줄이고자
확장(expansion)
- n < m
- 역함수 X
- 비트수 증가시키고자

✅ 확산(Diffusion)과 혼돈(Conclusion)

확산(Diffusion)
- 암호문과 평문 사이의 관계를 숨기는 것
- 암호문에 대한 통계 테스트를 통해서 평문을 찾고자 하는 공격자를 좌절시킴
혼돈(Conclusion)
- 암호문과 키의 관계를 숨기는 것
- 암호문을 이용하여 키를 찾고자하는 공격자를 좌절시킴
- 키의 단일 비트가 변하면 암호문의 거의 모든 비트가 변함

✅ 페이스텔(Feistel)과 SPN 구조

Feistel
- 입력을 좌우 블록으로 분할하여 한 블록을 라운드 함수에 적용시키 ㄴ후의 출력 값을 다른 블록에 적용하는 과정을 좌우블록에 대해 반복적으로 시행하는 방식
- 강도를 결정짓는 요소는 평문 블록의 길이, 키의 길이, 라운드의 수
- 복호화 과정은 암호화 과정과 동일
- 3라운드 이상이먀, 짝수 라운드로 구성
- 종류:
  - DES, LCKI, CAST, Blowfish, MISTY, RC5, RC6, CAST256, E2, Twoifsih, Mars
SPN
- Substitution Chipher와 Permutation Cipher를 중첩하는 형태로 개발한 암호
- S-box의 출력을 P-box로 전치(permutation)하는 과정을 반복하는 방식
- 병렬성을 제공
- 종류:
  - SAFER, SHARK, Square, CRYPTON, Rijndael, SAFER+, Serpent, PRESENT

✅ 스트림 암호

동기식
- 키는 평문 or 암호문 독립적
- 종류
  - One time pad
  - FSR(Feedback Shift Register)
  - LFSR
  - NLFSR
  - OFB모드
비동기식
- 키는 평문 or 암호문 종속적
- 종류
  - CFB모드

✅ 블록 알고리즘 종류와 특징

DES
- 미국
- 1972년
- NIST에서 표준으로 공표
- 블록크기 64
- 키의길이 56
- 라운드수 16
IDEA
- 유럽
- 1990년
- PGP채택
- 블록크기 64
- 키의 길이 128
- 라운드수 8
Rijndael
- 벨기에
- 1998년
- 2000년 AES알고리즘으로 선정
- 블록크기 128
- 키의 길이 128, 192, 256
- 라운드수 10, 12, 14
SEED
- 한국
- 1999년
- 한국표준 블록암호 알고리즘
- 블록크기 128
- 키의 길이 128, 256
- 라운드 수 16, 24
CRYPTON
- 한국
- 1998년
- AES후보 중 하나
- 블록 크기 128
- 키의 길이 128, 192, 256
- 라운드수 12
RC5
- 미국
- 1994년
- 알고리즘이 간단, 속도가 빠름
- 블록크기 32, 64, 128
- 키의 길이 0-2040
- 라운드수 1-255
FEAL
- 일본
- 1987년
- S/W구현에 적합
- 블록크기 64, 128
- 키의 길이 64
- 라운드수 4, 8,32
MISTY
- 일본
- 1996년
- 차분/선형공격에 안전성증명구조
- 블록크기 64
- 키의길이 128
- 라운드수 8
SKIPJACK
- 미국
- 1990년
- Fortezza카드에 사용
- 블록크기 64
- 키의 길이 80
- 라운드수 32

[정보보안기사/필기] PART1. 정보보호 개요

mellowg — Fri, 27 Sep 2024 20:09:30 +0900

PART1. 정보보호 개요

✅ 정보보호의 목표

기밀성 (Confidentiality)
- 오직 인가된 사람, 인가된 프로세스, 인가된 시스템만이 알 필요성에 근거하여 시스템에 접근해야 한다는 원칙
- 위협요소: 도청, 사회공학
무결성 (Integrity)
- 정보의 내용이 불법적으로 생성 또는 변경되거나 삭제되지 않도록 보호되어야 하는 성질
- 위협요소: 논리 폭탄, 백도어, 바이러스
가용성 (Availability)
- 정당한 사용자가 정보시스템의 데이터 또는 자원을 필요할 때 지체 없이 원하는 객체 또는 자원에 접근하여 사용할 수 있는 성질
- 위협요소: Dos, DDos, 지진, 홍수, 화재
인증성 (Authentication)
- 임의 정보에 접근할 수 있는 객체의 자격이나 객체의 내용을 검증하는데 사용되는 성질
책임추적성 (Accountability)
- 보안 목적에는 개체의 행동을 유일하게 추적해서 찾아낼 수 있어야 한다는 사항
부인방지 (Non-repudiation)
- 행위나 이벤트의 발생을 증명하여 나중에 그런 행위나 이벤트를 부인할 수 없도록 하는 것

✅ 정보보호 관리와 정보보호 대책

기술적 보호대책
- 정보 시스템, 통신망, 정보(데이터)를 보호하기 위한 가장 기본적인 대책
물리적 보호대책
- 화재, 수해, 지진, 태풍 등과 같은 자연재해로부터 정보시스템이 위치한 정보처리시설을 보호하기 위한 자연재해 대책
관리적 보호대책
- 법, 제도, 규정, 교육 등을 확립하고, 보안 계획을 수립하여 이를 운영(보안등급, 액세스 권한 등)하며, 위험 분석 및 보안감사를 시행하여 정보시스템의 안전성과 신뢰성을 확보하기 위한 대책

✅ 보안 목표와 관련된 공격의 분류

기밀성 : Snooping, Traffic analysis
- 스누핑(Snooping): 송수신하는 데이터에 대해 불법으로 접근하여 정보를 탈취
- 트래픽 분석(Traffic Analysis): 트래픽을 분석하여 송신자의 메일 주소나, 기타 트래픽 정보를 습득
무결성 : Modification, Masquerading, Replaying, Repudiation
- 변경(Modification): 메시지를 불법으로 수정
- 가장(Masquerading): 한 개체가 다른 개체로 신분을 위장하여 다른 공격들과 병행하여 수행
- 재연(Replaying): 획득한 데이터 단위를 보관하고 있다가 시간차를 두고 재전송 함으로써 인가되지 않은 정보에 접근
- 부인(Repudiation): 메시지의 송수신자의 송수신 행위를 부인
가용성 : Denial of Service
- 서비스 거부(Dos: Denial of Service): 서비스를 지연 혹은 다운시켜 사용자가 사용하지 못하게 하는 공격

✅ 소극적 공격과 적극적 공격

소극적 공격 : 시스템으로부터 정보를 획득하거나 사용하려는 시도를 말하고, 시스템 자원에는 영향을 끼치지 않는 공격 형태
적극적 공격 : 시스템 자원을 변경하거나 시스템 작동에 영향을 끼치는 공격 형태

✅ 수동적 공격과 능동적 공격

스누핑(Snooping), 트래픽 분석(Traffic Analysis): 소극적(Passive) / 기밀성(Confidentiality)
변경(Modification), 가장(Masquerading), 재연(Replaying), 부인(Repudiation): 적극적(Avtive) / 무결성(Integrity)
서비스 거부(Denial of Service) : 적극적(Active) / 가용성(Availability)

✅ 시스템 통제 (Control)

예방통제(Preventive): 사전에 위협과 취약점을 대처하는 통제
탐지통제(Detective): 위협을 탐지하는 통제
교정통제(Corrective): 탐지된 위협이나 취약점에 대처하거나 위협을 줄이거나 취약점을 감소시키는 통제

✅ 기본 보안용어 정리

공격자: 시스템을 공격하거나 위협하는 존재
공격: 시스템의 보안 서비스를 회피하여 보안 정책을 위반하려는 의도된 시도
대응: 피해의 최소화 및 적절한 대응을 위해 탐지, 보고하여 위험, 노출, 공격을 제거하거나 방지하는 행위, 장비, 기법
위험: 특정 위협이 가져올 피해가 확률적으로 표현되는 예상 손실
보안정책: 시스템이나 기관이 민감하고 중요한 시스템 자원들에 보안 서비스를 제공하기 위해 명시한 규정과 업무
자산: 정보 시스템 내의 데이터, 시스템의 서비스, 처리 기능, 통신 대역폭, 시스템 장비(하드웨어, 펌웨어, 소프트웨어, 문서), 시스템 장비 설비
위협: 보안을 침해하고 손해를 가져올 수 있는 상황, 행위, 이벤트가 존재할 때의 잠재적 보안 위반
취약점: 시스템 보안 정책을 위반할 수 있는 시스템 설계, 구현, 혹은 운여으 관리상의 오류 및 약점

[Programmers] BFS/DFS -lv2 게임 맵 최단거리

mellowg — Sun, 8 Sep 2024 16:01:08 +0900

게임 맵 최단거리

문제 설명

ROR 게임은 두 팀으로 나누어서 진행하며, 상대 팀 진영을 먼저 파괴하면 이기는 게임입니다. 따라서, 각 팀은 상대 팀 진영에 최대한 빨리 도착하는 것이 유리합니다.

지금부터 당신은 한 팀의 팀원이 되어 게임을 진행하려고 합니다. 다음은 5 x 5 크기의 맵에, 당신의 캐릭터가 (행: 1, 열: 1) 위치에 있고, 상대 팀 진영은 (행: 5, 열: 5) 위치에 있는 경우의 예시입니다.

위 그림에서 검은색 부분은 벽으로 막혀있어 갈 수 없는 길이며, 흰색 부분은 갈 수 있는 길입니다. 캐릭터가 움직일 때는 동, 서, 남, 북 방향으로 한 칸씩 이동하며, 게임 맵을 벗어난 길은 갈 수 없습니다.
아래 예시는 캐릭터가 상대 팀 진영으로 가는 두 가지 방법을 나타내고 있습니다.

첫 번째 방법은 11개의 칸을 지나서 상대 팀 진영에 도착했습니다.

두 번째 방법은 15개의 칸을 지나서 상대팀 진영에 도착했습니다.

위 예시에서는 첫 번째 방법보다 더 빠르게 상대팀 진영에 도착하는 방법은 없으므로, 이 방법이 상대 팀 진영으로 가는 가장 빠른 방법입니다.

만약, 상대 팀이 자신의 팀 진영 주위에 벽을 세워두었다면 상대 팀 진영에 도착하지 못할 수도 있습니다. 예를 들어, 다음과 같은 경우에 당신의 캐릭터는 상대 팀 진영에 도착할 수 없습니다.

게임 맵의 상태 maps가 매개변수로 주어질 때, 캐릭터가 상대 팀 진영에 도착하기 위해서 지나가야 하는 칸의 개수의 최솟값을 return 하도록 solution 함수를 완성해주세요. 단, 상대 팀 진영에 도착할 수 없을 때는 -1을 return 해주세요.

제한 사항

maps는 n x m 크기의 게임 맵의 상태가 들어있는 2차원 배열로, n과 m은 각각 1 이상 100 이하의 자연수입니다.
n과 m은 서로 같을 수도, 다를 수도 있지만, n과 m이 모두 1인 경우는 입력으로 주어지지 않습니다.
maps는 0과 1로만 이루어져 있으며, 0은 벽이 있는 자리, 1은 벽이 없는 자리를 나타냅니다.
처음에 캐릭터는 게임 맵의 좌측 상단인 (1, 1) 위치에 있으며, 상대방 진영은 게임 맵의 우측 하단인 (n, m) 위치에 있습니다.

입출력 예

코드

from collections import deque


def solution(maps):
    # 상 하 좌 우
    directions = [[1, 0], [-1, 0], [0, 1], [0, -1]]
    answer = 0

    n = len(maps[0])
    m = len(maps)

    visited = [[-1] * n for _ in range(m)]
    visited[0][0] = 1

    # 도착지점에 갈 수 없는 경우
    if maps[m - 2][n - 1] == 0 and maps[m - 1][n - 2] == 0:
        return -1

    queue = deque([(0, 0)])

    while queue:
        x, y = queue.popleft()

        for d in directions:
            dx, dy = x + d[0], y + d[1]
            if 0 <= dx < m and 0 <= dy < n and visited[dx][dy] == -1 and maps[dx][dy] == 1:
                queue.append((dx, dy))
                visited[dx][dy] = visited[x][y] + 1

    return visited[m - 1][n - 1]

[Programmers] BFS/DFS - lv3 네트워크

mellowg — Sun, 8 Sep 2024 14:34:37 +0900

네트워크

문제 설명

네트워크란 컴퓨터 상호 간에 정보를 교환할 수 있도록 연결된 형태를 의미합니다. 예를 들어, 컴퓨터 A와 컴퓨터 B가 직접적으로 연결되어있고, 컴퓨터 B와 컴퓨터 C가 직접적으로 연결되어 있을 때 컴퓨터 A와 컴퓨터 C도 간접적으로 연결되어 정보를 교환할 수 있습니다. 따라서 컴퓨터 A, B, C는 모두 같은 네트워크 상에 있다고 할 수 있습니다.

컴퓨터의 개수 n, 연결에 대한 정보가 담긴 2차원 배열 computers가 매개변수로 주어질 때, 네트워크의 개수를 return 하도록 solution 함수를 작성하시오.

제한 사항

컴퓨터의 개수 n은 1 이상 200 이하인 자연수입니다.
각 컴퓨터는 0부터 n-1인 정수로 표현합니다.
i번 컴퓨터와 j번 컴퓨터가 연결되어 있으면 computers[i][j]를 1로 표현합니다.
computer[i][i]는 항상 1입니다.

입출력 예

코드

from collections import deque

def solution(n, computers):
    answer = 0
    visited = [False] * n
    wait = deque([0])
    
    
    while False in visited:
        if len(wait) == 0 and False in visited:
            answer += 1
            for idx in range(len(visited)):
                if visited[idx] == False:
                    wait.append(idx)
                    break
                    
        cur = wait.popleft()
        visited[cur] = True
        
        for idx, c in enumerate(computers[cur]):
            if c == 1 and not visited[idx]:
                wait.append(idx)
    
    return answer + 1

mellowg

[Tibero] 암호화 알고리즘 변경 MD5 to SHA256

Tibero 암호화 알고리즘 변경 MD5 to SHA256

전제조건

1. 신규 설치시

2. 바이너리 패치시

[Tibero] 티베로 분석을 위한 명령어 모음

■ 쿼리 메모리 덤프

■ 특정 세션 callstack 수집

■ 특정 오류번호의 Callstack Dump On/Off

■ 바이너리 로그 텍스트 추출

■ SQL TRACE 기능 실행 후 dump 파일 생성

■ Autotrace 실행

[Tibero] Tibero 7.2.3 release note

Tibero 7.2.3 release note

1) Auto Purge 기능 추가

2) SQL Profile 기능 추가

3) Cluster Manager 확장 기능

4) 권한 추가

5) TPR 파티셔닝 기능 추가

6) 지원 OS 추가

[Tibero] Tibero 7.2.4 release note

Tibero 7.2.4 release note

1) IF NOT EXISTS / IF EXISTS 문법 추가

2) TAC Memory OOM 자동 정상화

3) 지원 OS 추가

4) DBMS 설치/패치 시 사용하는 쉘 변경

5) 설치 시 기본 유지 및 샘플 스미카 변경

6) 변경된 Parameter

7) 추가된 Parameter

8) ADAPTIVE_CURSOR_SHARING 기능 관련 파라미터 제거

[Tibero] outfile, callstack 로그 파일 차이점

● Outfile

● Callstack

[보험대리점] 보험대리점 시험 3일 컷

[Oracle] 오라클 성능 고도화 (3)

01 | 오라클 아키텍처

03 ) 버퍼 Lock

[Oralce] 오라클 성능 최적화 (2)

01 | 오라클 아키텍처

02 ) DB 버퍼 캐시

[Oracle] 오라클 성능 고도화 (1)

01 | 오라클 아키텍처

01 ) 기본 아키텍처

[Tibero] Tibero Backup & Recovery [1] Backup & Recovery 개요

Tibero Backup & Recovery

Backup & Recovery 개요

여러가지 유형의 장애

#1 명령문의 실패

#2 사용자 프로세스의 실패

#3 사용자로 인한 장애

#4 Instance Fail

#5 Media Fail

Backup & Recovery 전략 수립

Tibero 동작 방식의 이해

Transaction Durability

Logging

관련 background process

⭐️ Redo 저장 대상 범위

1) Physical Logging (물리적 로깅)

2) Logical Logging (논리적 로깅)

3) Physiological Logging

Change Vector / Redo Record

Redo 저장 시 발생

Database (Controlfile, Redolog file, Datafile) 동기화 방식

1. TSN

2. Checkpoint

Backup 개요

Backup 종류

Backup 대상(Controlfile & Redo logfile)

Controlfile 기능

동적뷰

다중화 방법

Redo logfile

동적뷰

다중화

Contolfile 백업

Backup 방식 차이 (NOARCHIVELOG VS ARCHIVELOG)

NOARCHIVELOG MODE

ARCHIVELOG MODE