214 lines
19 KiB
Markdown
214 lines
19 KiB
Markdown
# IT 및 개발 필수 용어 가이드
|
|
|
|
이 문서는 현대 IT 및 소프트웨어 개발 현업에서 자주 사용되는 핵심 용어들을 쉽게 설명하기 위해 작성되었습니다.
|
|
|
|
---
|
|
|
|
## 📌 용어 요약 요약표
|
|
|
|
| 용어 | 약자 풀이 | 한 줄 요약 |
|
|
| :--- | :--- | :--- |
|
|
| **OSI 7 Layer** | Open Systems Interconnection 7 Layer | 데이터가 전송되는 물리적 케이블부터 화면 표시까지의 국제 표준 7단계 체계 |
|
|
| **L3 / L4 / L7** | Layer 3 / Layer 4 / Layer 7 | 네트워크 계층별 장비 종류 (라우팅, 포트 분산, 콘텐츠/보안 처리) |
|
|
| **LF / CRLF** | Line Feed / Carriage Return Line Feed | 텍스트 파일의 줄바꿈을 처리하는 운영체제별 방식 |
|
|
| **RP (Repository)** | Repository | 소스 코드와 문서의 과거 변경 이력까지 모두 기록하는 저장소 |
|
|
| **CI/CD** | Continuous Integration / Continuous Deployment | 코드 검증부터 서버 반영까지의 과정을 자동으로 처리하는 파이프라인 |
|
|
| **LLM** | Large Language Model | 인간의 자연어를 이해하고 문장을 생성하는 거대 인공지능 모델 |
|
|
| **CLI** | Command Line Interface | 마우스 대신 텍스트 명령어를 직접 입력하여 컴퓨터를 제어하는 환경 |
|
|
| **Bare Metal** | Bare Metal | 가상화 레이어 없이 물리 서버 하드웨어에 OS를 직접 설치해 성능을 100% 쓰는 환경 |
|
|
| **Auth** | Authentication / Authorization | 신원을 확인하는 '인증'과 권한을 검증하는 '인가'의 보안 프로세스 |
|
|
| **Proxy / VPN** | Proxy / Virtual Private Network | 클라이언트와 서버 사이에서 IP 우회, 보안, 암호화 통신을 돕는 기술 |
|
|
| **Deployment** | Deployment Strategy | 블루/그린, 롤링, 카나리 등 서비스 중단 없이 신버전을 반영하는 전략 |
|
|
|
|
---
|
|
|
|
## 0. 네트워크 OSI 7계층 체계 및 핵심 장비 (L3 / L4 / L7)
|
|
네트워크 통신은 **"내가 보낸 데이터가 상대방의 화면에 뜨기까지"**의 과정입니다. 물리적인 케이블 연결(1계층)부터 사용자가 보는 프로그램 화면(7계층)까지 총 7단계로 나뉘며, 상위 계층으로 갈수록 장비가 데이터의 더 깊은 곳(상세한 정보)까지 들여다보고 지능적으로 처리합니다.
|
|
|
|
### 📦 OSI 7계층 전체 체계 일람
|
|
|
|
| 계층 | 이름 | 데이터 단위 | 핵심 역할 | 대표 장비 및 예시 |
|
|
| :--- | :--- | :--- | :--- | :--- |
|
|
| **L7** | 응용 (Application) | Data | 사용자 인터페이스 제공 및 콘텐츠 분석 | HTTP, 웹 브라우저, **L7 스위치**, WAF |
|
|
| **L6** | 표현 (Presentation) | Data | 데이터 암호화, 압축, 형식 변환 | JPEG, MP3, SSL/TLS, 암호화 모듈 |
|
|
| **L5** | 세션 (Session) | Data | 통신 연결 유지 및 동기화 관리 | NetBIOS, RPC, 로그인 상태 유지 |
|
|
| **L4** | 전송 (Transport) | Segment | 포트 기반 통신 및 데이터 신뢰성 확보 | TCP, UDP, **L4 스위치 (로드밸런서)** |
|
|
| **L3** | 네트워크 (Network) | Packet | IP 기반 최적의 경로 설정 (Routing) | IP, **라우터**, **L3 스위치** |
|
|
| **L2** | 데이터 링크 (Data Link) | Frame | MAC 주소 기반 인접 장비 간 연결 | Ethernet, **L2 스위치**, 브릿지 |
|
|
| **L1** | 물리 (Physical) | Bit (0,1) | 전기적/광학적 신호 전송 | 케이블, 허브, 리피터 |
|
|
|
|
### 🛠️ 주요 네트워크 장비 직관적으로 이해하기 (L3, L4, L7)
|
|
|
|
#### ① L3 스위치 / 라우터: "전국구 택배 물류센터"
|
|
* **핵심 식별 정보:** IP 주소
|
|
* **하는 일:** 편지봉투의 '보내는 사람 주소'와 '받는 사람 주소'만 확인하는 단계입니다. 목적지 IP를 읽고 데이터가 어떤 길로 가야 가장 빠를지 최적의 경로(Routing)를 찾아 안내합니다. 우리가 집에서 쓰는 공유기도 일종의 소형 라우터 역할을 합니다.
|
|
|
|
#### ② L4 스위치 (로드 밸런서): "동·호수 확인 및 배달원 배정"
|
|
* **핵심 식별 정보:** IP 주소 + 포트 번호 (Port)
|
|
* **하는 일:** 똑같은 IP 주소(아파트 주소)라도 80번 포트(웹)인지 21번 포트(FTP)인지에 따라 서비스가 다릅니다. L4 스위치는 포트 번호를 보고 데이터를 분류하며, 특정 서버에 트래픽이 몰리지 않도록 여러 대의 서버로 공평하게 부하를 분산(Load Balancing)해 줍니다. 단, 데이터 내용(알맹이)은 보지 못합니다.
|
|
|
|
#### ③ L7 스위치 / WAF (웹 방화벽): "내용물 검사 및 맞춤형 서비스"
|
|
* **핵심 식별 정보:** IP + 포트 + 애플리케이션 콘텐츠 (URL, 문자열, 쿠키 등)
|
|
* **하는 일:** 네트워크의 마스터 지배인입니다. 패킷의 내부 알맹이(HTTP URL, 쿠키 등)까지 전부 열어보고 판단합니다. 사용자가 요청한 URL을 보고 이미지 서버나 동영상 서버로 똑똑하게 갈라쳐 주는 **콘텐츠 기반 분산**이 가능하며, 정상 주소로 위장해 들어오는 악성 코드나 SQL 인젝션 공격을 찾아내는 **지능형 보안**을 수행합니다.
|
|
|
|
---
|
|
|
|
## 1. LF / CRLF (줄바꿈 방식)
|
|
텍스트 파일에서 **"여기서 줄을 바꾸고 다음 줄로 넘어가라"**라고 컴퓨터에게 지시하는 방식입니다. 과거 타자기 시절의 작동 방식에서 유래되었습니다.
|
|
|
|
* **CR (Carriage Return):** 커서를 줄의 맨 앞으로 이동 (`\r`)
|
|
* **LF (Line Feed):** 커서를 한 줄 아래로 이동 (`\n`)
|
|
|
|
### 운영체제별 줄바꿈 표준
|
|
* **LF (`\n`):** Linux, macOS, Git 시스템 기본 환경
|
|
* **CRLF (`\r\n`):** Windows 오퍼레이팅 시스템
|
|
|
|
> 💡 **현업 실무 팁**
|
|
> Windows 환경에서 작성한 소스 코드(CRLF)를 Linux 서버(LF)로 그대로 가져가면, 눈에 보이지 않는 `\r` 문자 때문에 구문 에러가 발생하거나 쉘 스크립트가 오작동할 수 있습니다. 프로젝트 시작 전 팀 내 줄바꿈 설정을 통일하는 것이 좋습니다.
|
|
|
|
---
|
|
|
|
## 2. RP (Repository / 레포지토리)
|
|
개발자들 사이에서 흔히 **"레포"** 또는 **"저장소"**라고 부르는 프로젝트의 핵심 보관소입니다.
|
|
|
|
* 단순히 소스 코드 파일만을 모아두는 일반 폴더와는 다릅니다.
|
|
* 파일의 생성, 수정, 삭제 등 **과거 모든 변경 이력(버전)이 타임라인 형태로 기록·보관**되는 지능형 저장소입니다.
|
|
* **로컬 저장소 (Local Repository):** 개발자 개인 PC에 존재하는 독립적인 작업 공간
|
|
* **원격 저장소 (Remote Repository):** GitHub, GitLab 등 네트워크상에 존재하며 팀원들과 코드를 공유하고 협업하는 중앙 공간
|
|
|
|
---
|
|
|
|
## 3. CI/CD (지속적 통합 / 지속적 배포)
|
|
개발자가 코드를 수정하여 저장소에 반영한 순간부터, 이를 **자동으로 검증하고 실제 운영 서버에 안전하게 반영해 주는 자동화 시스템**을 의미합니다.
|
|
|
|
* **CI (지속적 통합):** 여러 개발자가 각자 수정한 코드를 하나의 저장소에 모을 때, 시스템이 **자동으로 빌드하고 테스트(에러 검사)를 수행**하여 코드의 건전성을 상시 유지하는 과정입니다.
|
|
* **CD (지속적 배포):** CI 단계를 통과하여 검증이 완료된 코드를 사용자가 사용할 수 있는 **운영 서버에 사람의 개입 없이 자동으로 반영(배포)**하는 과정입니다.
|
|
|
|
> 💡 **시스템 비유**
|
|
> 수동 배포가 음식을 사람이 일일이 검수하고 직접 배달하는 방식이라면, CI/CD는 **"조리 직후 센서가 자동으로 위생과 맛을 검사(CI) $\rightarrow$ 통과 즉시 드론이 고객에게 자동 배송(CD)"**하는 지능형 자동화 공정 라인과 같습니다.
|
|
|
|
---
|
|
|
|
## 4. LLM (Large Language Model / 거대 언어 모델)
|
|
인터넷상의 수많은 텍스트 데이터를 기반으로 학습하여, **사람의 언어(자연어)를 이해하고 문맥에 맞는 텍스트를 생성하도록 설계된 초대형 인공지능(AI) 신경망 모델**입니다.
|
|
|
|
* 현재 대화 중인 시스템을 비롯해 ChatGPT, Claude 등이 모두 LLM을 기반으로 작동합니다.
|
|
* 방대한 양의 언어 규칙과 지식을 내재하고 있어 문맥 파악, 문서 요약, 외국어 번역뿐만 아니라 **프로그래밍 소스 코드 작성 및 디버깅**과 같은 고도의 언어적 업무를 훌륭히 수행합니다.
|
|
|
|
---
|
|
|
|
## 5. CLI (Command Line Interface / 명령줄 인터페이스)
|
|
그래픽 화면 및 마우스를 사용하는 대신, **텍스트 형태의 명령어를 직접 타이핑하여 컴퓨터 시스템을 제어하고 소통하는 인터페이스 방식**입니다.
|
|
|
|
* **GUI (Graphic User Interface):** 일반적인 사용자 환경. 윈도우 창, 그래픽 아이콘, 마우스 클릭 중심의 조작.
|
|
* **CLI (Command Line Interface):** 개발자 및 서버 관리자 환경. `cd /var/www`, `git commit` 같은 텍스트 기반 명령어 조작.
|
|
|
|
### 굳이 CLI를 사용하는 이유?
|
|
1. **고성능 및 자원 효율성:** 그래픽을 표현하는 데 필요한 메모리와 CPU 자원을 소모하지 않으므로 서버 운영에 최적화되어 있습니다.
|
|
2. **반복 작업의 자동화:** 자주 사용하는 일련의 명령어들을 쉘 스크립트(Shell Script) 파일로 묶어두면, 단 한 번의 실행으로 수백 가지의 복잡한 프로세스를 순식간에 자동 처리할 수 있습니다.
|
|
|
|
---
|
|
|
|
## 6. 베어 메탈 (Bare Metal)
|
|
**베어 메탈(Bare Metal)**은 하이퍼바이저(Hypervisor) 같은 가상화 계층 없이, **물리적 하드웨어에 직접 운영 체제(OS)나 애플리케이션을 설치하고 구동하는 환경**을 뜻합니다.
|
|
|
|
다른 사용자와 하드웨어 자원을 공유하지 않고 통째로 독점하여 사용하기 때문에, 물리 서버가 가진 본연의 성능을 100% 온전히 발휘할 수 있는 단독 서버 환경입니다.
|
|
|
|
### 🆚 베어 메탈 vs 가상 머신 (VM) 비교
|
|
|
|
| 구분 | 베어 메탈 (Bare Metal) | 가상 머신 (VM, Virtual Machine) |
|
|
| :--- | :--- | :--- |
|
|
| **자원 사용** | 물리 서버 1대를 단독으로 사용 (단독 격리 환경) | 1대의 물리 자원을 하이퍼바이저를 통해 분할하여 공유 |
|
|
| **성능 및 안정성** | 다른 사용자의 간섭(**Noisy Neighbor**)이 없어 최고의 성능 유지 | 공유 자원이므로 타 사용자의 작업량에 따라 성능 간섭 발생 가능 |
|
|
| **제어 권한** | 하드웨어 레벨에 직접 접근하여 모든 제어 권한 완전 통제 | 가상화 계층을 거치므로 하드웨어 직접 제어에 제한적 |
|
|
| **구축 시간** | 물리적 장치 준비 및 랙 마운팅 등으로 시간이 더 소요됨 | 가상 환경 위에서 클릭 몇 번으로 즉시 생성 및 복제 가능 |
|
|
| **비용 구조** | 하드웨어 전체를 독점하므로 초기/유지 비용이 상대적으로 높음 | 필요한 만큼만 자원을 쪼개어 쓰고 사용한 만큼 지불해 효율적 |
|
|
|
|
### 🛠️ 주요 활용 시나리오 (Use Cases)
|
|
* **데이터 집약적 워크로드:** 입출력(I/O) 병목 현상이 없어야 하는 대규모 RDBMS, 빅데이터 분석 시스템(Hadoop 등), 고성능 컴퓨팅(HPC) 환경.
|
|
* **엄격한 보안 및 규제 준수:** 가상화 환경의 자원 공유로 인한 취약점을 차단하고, 물리적 인프라 격리가 필수적인 금융권 및 공공기관 시스템.
|
|
* **극도의 성능 요구 서비스:** 지연 시간(Latency) 최소화가 필수적인 실시간 게임 서버, 고빈도 매매(HFT) 시스템.
|
|
|
|
> 💡 **베어 메탈 클라우드 (Bare Metal Cloud)**
|
|
> 최근 클라우드 생태계에서는 물리 서버를 퍼블릭 클라우드처럼 웹 콘솔이나 API를 통해 몇 분 만에 자동으로 할당받고 반납할 수 있는 서비스 형태로 널리 제공되고 있습니다. (예: 카카오클라우드 베어메탈 서버, 삼성SDS 베어메탈 컴퓨팅 등)
|
|
|
|
---
|
|
|
|
## 7. 인증(Authentication)과 인가(Authorization)
|
|
인증과 인가는 웹 보안 및 시스템 접근 제어의 핵심 개념입니다. 두 용어는 비슷해 보이지만 명확히 다른 역할을 수행합니다.
|
|
|
|
* **인증 (Authentication):** **"당신은 누구입니까? (Who are you?)"**를 검증합니다. 사용자가 주장하는 본인의 신원이 맞는지 확인하는 과정입니다. (예: ID/비밀번호 입력, 생체 인식, 사원증 태그)
|
|
* **인가 (Authorization):** **"당신은 무엇을 할 수 있습니까? (What are you allowed to do?)"**를 검증합니다. 신원이 확인된 사용자가 특정 리소스에 접근하거나 기능을 수행할 권한이 있는지 확인하고 허용하는 과정입니다. (예: 관리자 권한 부여, 일반 직원의 서버실 접근 제한)
|
|
|
|
### 🔄 JWT 기반 인증/인가 아키텍처 흐름
|
|
세션을 서버에 저장하지 않고, 클라이언트가 발급받은 토큰을 직접 증명서처럼 들고 다니는 방식의 흐름입니다.
|
|
|
|
1. **인증 요청 (로그인):** 클라이언트가 ID/PW를 서버에 전송합니다.
|
|
2. **토큰 발급:** 서버가 DB를 확인하여 신원이 검증되면, 사용자 정보(Id, Role 등)를 담은 **Access Token(JWT)**을 생성하여 반환합니다.
|
|
3. **인가 요청 (API 호출):** 클라이언트는 권한이 필요한 API를 호출할 때, HTTP Header의 `Authorization: Bearer <JWT>`에 토큰을 실어 보냅니다.
|
|
4. **토큰 검증 및 허가:** 서버는 토큰의 위변조 여부와 만료일을 검증한 뒤, 토큰 내부의 권한(Role)을 확인하여 요청을 최종 승인하거나 차단합니다.
|
|
|
|
> 💡 **한 줄 요약**
|
|
> **인증**은 문을 열고 들어가기 위한 **열쇠**이고, **인가**는 방 안에 들어간 후 특정 물건을 만질 수 있는 **허가증**입니다.
|
|
|
|
---
|
|
|
|
## 8. 프록시 (Proxy)와 VPN
|
|
**프록시(Proxy)**는 영어로 '대리'라는 뜻입니다. 컴퓨터 네트워크에서는 **클라이언트(사용자)와 서버(웹사이트) 사이의 '중개인' 역할**을 하는 서버를 의미합니다. 내가 직접 웹사이트에 접속하는 대신, 중간에 있는 프록시 서버가 내 요청을 대신 전달하고 결과를 받아옵니다.
|
|
|
|
* **직접 접속:** `나` ➡️ `웹사이트` (웹사이트가 내 진짜 IP와 위치를 파악 가능)
|
|
* **프록시 접속:** `나` ➡️ **`프록시 서버`** ➡️ `웹사이트` (웹사이트는 프록시 서버의 IP 정보만 인식)
|
|
|
|
### 🛡️ 프록시를 사용하는 주요 이유
|
|
1. **익명성 및 보안:** 내 진짜 IP 주소를 숨기고 활동할 수 있으며, 해커의 직접적인 접근을 막는 방화벽 역할을 수행합니다.
|
|
2. **차단 우회 및 지역 제한 해제:** 사내망이나 특정 국가에서 막아둔 사이트를 차단되지 않은 다른 지역의 프록시 서버를 거쳐 우회 접속할 수 있습니다.
|
|
3. **속도 향상 및 대역폭 절약 (캐싱):** 자주 방문하는 사이트의 이미지나 데이터를 프록시 서버에 임시 저장(캐시)해 두고, 다음 접속 시 서버에서 바로 불러와 로딩 속도를 높입니다.
|
|
|
|
### ⚙️ 포워드 프록시 vs 리버스 프록시
|
|
* **포워드 프록시 (Forward Proxy):** 사용자(클라이언트) 앞에 위치합니다. 주로 내부 사용자들이 유해 사이트에 접속하지 못하도록 통제하거나 개인이 IP를 우회할 때 씁니다.
|
|
* **리버스 프록시 (Reverse Proxy):** 웹사이트(서버) 앞에 위치합니다. 대량의 사용자가 몰릴 때 요청을 여러 서버로 나누어 주는 로드 밸런싱 역할을 하며, 실제 서버의 IP를 숨겨주기 때문에 서버 보안에 필수적입니다.
|
|
|
|
### 🆚 프록시 (Proxy) vs VPN 상세 비교
|
|
많은 사람이 프록시와 VPN을 비슷하게 생각하지만, 핵심 차이는 **'암호화 및 적용 범위'**에 있습니다.
|
|
|
|
| 구분 | 프록시 (Proxy) | VPN |
|
|
| :--- | :--- | :--- |
|
|
| **핵심 역할** | 단순 요청 대리 및 중개 | 데이터 암호화 및 가상 터널 생성 |
|
|
| **적용 범위** | 특정 웹 브라우저나 일부 앱에만 적용 | 기기 전체의 모든 인터넷 트래픽에 적용 |
|
|
| **보안 수준** | 데이터가 암호화되지 않아 보안에 취약함 | 강력한 암호화로 패킷 탈취 및 해킹으로부터 안전함 |
|
|
|
|
---
|
|
|
|
## 9. 시스템 배포 방식 (Deployment Strategy)
|
|
개발이 완료된 신버전의 소프트웨어를 실제 운영 서버에 반영할 때, **서비스 중단(Downtime)을 최소화하고 안정성을 확보하기 위해 사용하는 전략**들입니다. 주로 CI/CD 파이프라인의 최종 단계나 로드밸런서(L4/L7 스위치)의 라우팅 설정을 제어하여 구현합니다.
|
|
|
|
### 9.1 블루/그린 배포 (Blue/Green Deployment)
|
|
구버전 환경(Blue)과 동일한 신버전 환경(Green)을 하나 더 구축한 후, 로드밸런서(라우터)의 스위치를 한 번에 전환하여 트래픽을 교체하는 방식입니다.
|
|
|
|
* **작동 방식:** `기존 서버(Blue) 100%` → `신규 서버(Green)로 트래픽 100% 순간 전환`
|
|
* **장점:**
|
|
* 구버전과 신버전이 완전히 분리되어 시스템 간 상호작용 오작동 리스크가 낮음
|
|
* 문제가 생겼을 때 로드밸런서 스위치만 원복하면 되므로 **롤백이 매우 빠름**
|
|
* **단점:** 전체 인프라 자원을 일시적으로 2배 구축해야 하므로 **비용 부담이 큼**
|
|
|
|
### 9.2 롤링 배포 (Rolling Deployment)
|
|
전체 서버 중 일부 서버씩 순차적으로 신버전으로 교체해 나가는 방식입니다.
|
|
|
|
* **작동 방식:** 전체 서버 풀 중 일부(예: 20%)를 순차적으로 서비스에서 제외 후 업데이트하여 다시 투입하는 과정을 반복
|
|
* **장점:** 추가 인프라 자원을 크게 늘릴 필요가 없어 **인프라 비용이 매우 절약됨**
|
|
* **단점:** 배포가 진행되는 동안 구버전과 신버전이 동시에 서비스되므로 **버전 간 호환성 문제**를 고려해야 함 (DB 스키마 등)
|
|
|
|
### 9.3 카나리 배포 (Canary Deployment)
|
|
소수의 사용자(예: 5~10%)에게 신버전을 먼저 노출하여 실환경 안정성을 검증한 뒤, 이상이 없으면 전체로 점진 확대하는 방식입니다. 과거 광부들이 유독가스를 감지하기 위해 카나리아 새를 새장에 넣어 들어갔던 것에서 유래했습니다.
|
|
|
|
* **작동 방식:** `일부 트래픽(예: 5%) 신버전 투입` → `로그 및 모니터링 검증` → `100%까지 점진적 확대`
|
|
* **장점:** 리스크를 최소화한 상태로 안전하게 신기능을 검증할 수 있음 (A/B 테스트로 비즈니스 지표 확인 가능)
|
|
* **단점:** 트래픽을 세밀하게 쪼개어 제어(라우팅)해야 하므로 설정이 복잡하며, 구/신버전 동시 존재에 따른 API 호환성 유지가 필수적임
|
|
|
|
### 📊 배포 방식 한눈에 보기
|
|
|
|
| 배포 방식 | 자원(비용) 부담 | 롤백 속도 | 핵심 특징 | 추천 적용 상황 |
|
|
| :--- | :---: | :---: | :--- | :--- |
|
|
| **블루/그린** | 높음 (2배) | 매우 빠름 | 버전 혼재 없음 | 비용 여유가 있고 미션 크리티컬한 서비스 안정성이 최우선일 때 |
|
|
| **롤링** | 낮음 | 보통 | 순차적 서버 교체 | 자원이 제한적이고 일반적인 주기적 시스템 업데이트 시 |
|
|
| **카나리** | 보통 | 빠름 | 소수 사용자 선검증 | 대규모 서비스에서 신기능의 리스크 검증 및 A/B 테스트 필요 시 | |