Coder's Cattitude

[Drone] MAVLink - 드론과 지상이 통신하는 언어

말하는 알감자 — Tue, 14 Jul 2026 13:27:38 +0900

목표: 드론이 MQTT로 보내는 raw MAVLink 데이터를 받아 디코딩 및 처리하는 시스템 만들기위해서 그 데이터인 MAVLink 프로토콜 자체를 정리한다. (이전 글에서 "펌웨어가 데이터의 생산자"라고 했는데, 그 데이터가 바로 MAVLink 메시지!)

0. 용어 정리 (프로토콜 / Protobuf / 페이로드)

프로토콜(protocol)이란

통신 규칙(약속)이다. "이런 순서로, 이런 형식으로 데이터를 주고받자"는 합의.

비유: 편지 봉투에 "왼쪽 위 = 보내는 사람, 오른쪽 위 = 우표" 같은 약속. 양쪽이 같은 약속을 지켜야 배달된다.
HTTP, TCP, MAVLink 모두 각자의 "주고받는 규칙"이다.

프로토콜은 층(layer)으로 쌓인다 — TCP/UDP와의 관계

네트워크 수업에서 배운 계층 개념 그대로다.

TCP/UDP = "데이터를 어떻게 실어 나를까"를 담당하는 운송 계층. 트럭. 안에 뭐가 실렸는지는 신경 쓰지 않는다.
MAVLink = 그 트럭에 실리는 상자의 내용물 규격. "이 상자엔 위도·경도·고도를 이 순서로 담는다"는 약속. 즉 TCP/UDP보다 위층이다.

[ MAVLink 메시지 ]   ← 상자 내용물 규격 (뭘 담을지) ← 내가 디코딩하는 대상
        ↓ 이걸 실어서
[ TCP / UDP / MQTT ] ← 운송 계층 (어떻게 나를지)
        ↓
[ IP, 무선 링크 ]    ← 실제 물리적 배달

내 시스템의 흐름: 드론이 MAVLink 메시지(내용물)를 만든다 → MQTT/TCP(트럭)에 실어 보낸다 → 내가 받아 트럭에서 상자를 꺼낸다(MQTT 수신) → 상자 내용물(MAVLink)을 규격대로 뜯는 게 디코딩.

페이로드(payload)란

포장·주소·검증용 부가정보를 뺀 진짜 알맹이 데이터

비유: 택배에서 송장·완충재·테이프를 뺀 안의 진짜 물건. 편지로 치면 봉투가 아니라 편지 본문
네트워크 수업의 "헤더 빼고 남는 게 페이로드"와 정확히 같은 개념

Protobuf(Protocol Buffers)란

구글이 만든 데이터 직렬화 포맷

직렬화(serialize): 프로그램 안의 데이터를 네트워크로 보내려고 한 줄의 바이트로 쭉 펴는 것. 받아서 되돌리는 게 역직렬화.
JSON도 직렬화 포맷이지만, 사람이 읽으라고 글자로 편다({"latitude": 37.12}) → 편하지만 무겁다.
Protobuf는 가독성을 포기하고 바이너리로 빽빽하게 편다. 대신 미리 스키마(필드 타입·순서 정의서)를 양쪽이 공유해야 복원 가능하다. 글자 라벨을 안 보내고 순서로만 구분하기 때문.

"MAVLink가 Protobuf 같다"는 건 같은 발상이라는 뜻이다: 라벨 없이 바이너리로 빽빽하게, 미리 정한 스키마(= dialect의 메시지 정의)로만 해독

1. MAVLink란

Micro Air Vehicle Link의 약자. 소형 무인기와 통신하기 위한 프로토콜이다.
성격은 우리가 아는 것 중 Protobuf(protocol buffers)에 가장 가깝다.

왜 Protobuf와 비슷한가

사람이 읽는 JSON이 아니라, 바이너리로 빽빽하게 압축된 포맷
미리 정해진 스키마(메시지 정의)가 있어야 디코딩 가능
필드마다 타입과 순서가 정해져 있음

왜 JSON을 안 쓰고 이렇게 만들었나

드론은 대역폭과 자원이 부족한 환경이다. MAVLink는 자원 및 대역폭이 제한된 소형 무인기와 통신하기 위한 효율적 텔레메트리 프로토콜 무선 링크로 초당 수십~수백 개 메시지를 날려야 하는데, {"latitude": 37.1234567} 같은 텍스트를 매번 보내면 너무 무겁고 느리다.
→ 그래서 "위도"를 4바이트 정수 하나에 욱여넣는 식으로 극한까지 압축했다.

2. 메시지가 "종류별로" 나뉜다는 것

MAVLink 통신은 한 덩어리로 흐르지 않는다. 종류가 정해진 메시지들이 각자 따로 날아오는 구조다.

비유: 드론이 지상국에 여러 종류의 엽서를 계속 부친다. 엽서마다 종류(양식)가 정해져 있다.

메시지	뜻
HEARTBEAT	"나 살아있어요" (심장박동)
GLOBAL_POSITION_INT	"제 현재 위경도/고도는 이거예요"
ATTITUDE	"제가 지금 이만큼 기울어져 있어요"
SYS_STATUS	"배터리 잔량, 센서 상태는 이래요"
GPS_RAW_INT	"GPS 원시 데이터예요"

각 메시지(엽서)에는 고유 번호(message ID)와 정해진 칸(필드)이 있다.

HEARTBEAT: ID 0번. "기체 타입, 자동조종 종류, 비행 모드, 시스템 상태" 등의 칸.
GLOBAL_POSITION_INT: ID 33번. "타임스탬프, 위도, 경도, 고도, 속도" 등의 칸.

raw MAVLink를 디코딩한다는 건: "날아온 바이트 덩어리 → 몇 번 엽서인지 알아내고 → 그 양식에 맞춰 칸을 하나씩 꺼내는" 작업 Protobuf 메시지를 .proto 스키마로 파싱하는 것과 같은 개념

3. 메시지 하나가 실제로 어떻게 생겼나 (프레임 구조)

엽서 하나(= 한 메시지)는 이런 봉투에 담겨 날아온다. 아래는 MAVLink v2.0 기준. 앞부분(STX~CHECKSUM)은 항상 있고, 맨 뒤 SIGNATURE는 옵션(서명 켠 경우에만 붙음)이다.

순서	필드	크기	비유	역할
1	STX	1 byte	봉투 시작 표시	"여기서부터 새 엽서 시작". v2 = 0xFD (v1 = 0xFE)
2	LEN	1 byte	내용물 분량	PAYLOAD가 몇 바이트인지 (0~255)
3	INC FLAGS (incompatible)	1 byte	봉인 방식 표시	모르면 메시지를 버려야 하는 플래그. 서명 여부 등이 여기
4	CMP FLAGS (compatible)	1 byte	참고용 메모	몰라도 무시하고 읽으면 되는 부가 정보
5	SEQ	1 byte	엽서 일련번호	0~255 순환. 건너뛴 번호로 유실 감지
6	SYS ID	1 byte	보낸 기체 주소	어느 시스템(드론)이 보냈나
7	COMP ID	1 byte	보낸 부품 주소	그 기체 안 어느 부품(FC, 카메라 등)이 보냈나
8	MSG ID	3 bytes	엽서 종류 번호	HEARTBEAT(0)인지 GLOBAL_POSITION_INT(33)인지. v2에서 3바이트로 확장
9	PAYLOAD	0~255 bytes	엽서 본문	실제 데이터(위도, 고도 등) = 알맹이
10	CHECKSUM	2 bytes	봉인 도장	중간에 깨지지 않았는지 검증
11	SIGNATURE (옵션)	13 bytes	인감 도장	위조 방지 전자 서명. link id(1) + timestamp(6) + signature(6)

핵심: 메시지 ID를 봐야 페이로드를 어떻게 해석할지 결정된다. ID가 33번이면 "페이로드를 GLOBAL_POSITION_INT 양식으로 읽어야겠다"가 된다. 봉투를 뜯기 전엔 안쪽 바이트는 그냥 의미 없는 숫자 뭉치다.

INC FLAGS vs CMP FLAGS (v2에서 새로 생긴 부분)

둘 다 "이 플래그를 모르는 디코더가 만났을 때 어떻게 할래?"에 대한 답이다.

INCompatible flags → 모르면 메시지를 버려라. (모른 채 읽으면 잘못 읽음. 서명이 붙었다는 표시가 대표 예시)
COMpatible flags → 모르면 무시하고 읽어라. (몰라도 본문 해석엔 지장 없음)

비유(HTTP 헤더): "이해 못 하면 요청 자체를 거부해야 하는 헤더" vs "몰라도 그냥 무시하면 되는 부가 헤더"의 차이.

SIGNATURE (맨 뒤 옵션 13바이트)

메시지 위조 방지용 전자 서명. "진짜 우리 드론이 보냈고 중간 조작이 없었다"를 보증한다. 서명 기능을 켠 경우에만 붙고(그림에서 점선), 안 쓰면 CHECKSUM에서 메시지가 끝난다.

실무에서 디코딩되는 순서

STX로 메시지 시작을 찾는다 (0xFD면 v2)
INC FLAGS로 서명 여부 등 해석 가능 여부를 확인
MSG ID(3바이트)로 어떤 메시지인지 판별
PAYLOAD를 해당 dialect 스키마로 해석
CHECKSUM으로 무결성 검증

실제로는 pymavlink 같은 라이브러리가 이 프레임 해체를 자동으로 해준다. 바이트를 손으로 자를 일은 거의 없고, 라이브러리가 "MSG ID는 33, 필드는 이거"라고 객체로 건네준다. 다만 구조를 알아야 에러(서명 파싱 실패, v1/v2 혼동 등) 원인을 짚을 수 있다.

여기서 dialect가 다시 등장

메시지 ID ↔ 양식의 대응표(어느 ID가 무슨 메시지고 칸이 뭔지)가 바로 dialect에 정의돼 있다. 표준 MAVLink에 공통 메시지가 있고, ardupilotmega 방언에 ArduPilot 고유 메시지가 추가돼 있다. → 디코더에게 방언을 알려줘야 ID→양식 대응표를 갖고 제대로 파싱할 수 있다.

한 줄 요약(실무 연결): MAVLink 디코딩이란 "바이너리 봉투에서 메시지 ID를 읽고, 해당 dialect 스키마로 페이로드 칸을 꺼내는 일"이며, 이게 내 시스템의 심장부다.

Q&A

Q. MAVLink를 JSON이 아니라 Protobuf 같은 바이너리 스키마 포맷으로 만든 이유는?
드론은 자원이 부족한 환경이라 JSON처럼 무거운 텍스트를 쓸 수 없어서, 바이너리 스키마 포맷으로 최대한 경량화했다.

Q. "메시지가 종류별로 나뉜다"는 게 무슨 뜻? (HEARTBEAT / GLOBAL_POSITION_INT)
메시지마다 고유 ID가 있어 구별된다. ID가 0이면 HEARTBEAT 정보가, 다른 ID면 GLOBAL_POSITION_INT 등 해당 메시지의 데이터가 들어온다.

Q. 디코딩할 때 왜 메시지 ID를 먼저 봐야 하나?
메시지마다 담긴 데이터(필드)가 다르기 때문에, ID를 먼저 봐야 어떤 양식으로 칸을 꺼낼지 알 수 있다.

Q. INC FLAGS와 CMP FLAGS의 차이는? (v2)
둘 다 "이 플래그를 모르는 디코더가 만났을 때 어떻게 할지"를 정한다.

INC(incompatible): 모르면 메시지를 버려야 한다. (서명 여부 등이 여기)
CMP(compatible): 몰라도 무시하고 읽으면 된다.

참고 자료

MAVLink 공식 문서: https://mavlink.io/en/
MAVLink 메시지 정의(common): https://mavlink.io/en/messages/common.html
MAVLink 메시지 정의(ArduPilot 방언): https://mavlink.io/en/messages/ardupilotmega.html
pymavlink: https://github.com/ArduPilot/pymavlink
Protocol Buffers 개요: https://protobuf.dev/overview/

[Drone] FC와 Ardupilot/PX4

말하는 알감자 — Mon, 13 Jul 2026 17:58:27 +0900

드론 제어 시스템을 구축하는데 드론에 대한 공부가 부족한 것 같아서 스스로 이해하고 있는 내용을 적어보고 계속해서 보완해 볼 예정입니다. 회사에서 선배님들께 들은 용어들 적어놓고 추가적으로 공부해서 계속해서 업데이트 할 예정. 제품개발부에서 들은 하드웨어 용어도 다시 점검할 예정!

1. FC (Flight Controller) 란

드론 안에는 비행 컨트롤러 (Flight Controller, FC)라는 손바닥보다 작은 회로 기판(보드)가 들어있다.
자이로, 가속도계, 기압계, GPS와 같은 센서가 여기에 연결되고, 모터로 나가는 출력도 여기서 나온다.

- 비유 : FC는 드론의 소뇌와 가깝다. "기체가 3도 기울었다. -> 왼쪽 모터 출력을 살짝 높인다." 와 같은 판단을 초당 수백 번씩 자동으로 한다.
- 사람이 걸을 때 넘어지지 않으려고 무의식적으로 균형을 잡는 일을 FC가 대신 해준다고 생각하면 된다.

캐리어 보드 (carrier board)란?
Pixhawk 같은 FC는 보통 캐리어 보드 (베이스 보드) 위에 꽂힌다.
FC 본체 = 센서 및 연산 담당 핵심 모듈, carrier board = 전원 분배와 각종 포트 (GPS, 텔레메트리, 모터 신호선) 연결 담당
비유하자면 FC = CPU 모듈, carrier board = 메인 보드 같은 느낌

FC vs 펌웨어

FC는 하드웨어 (보드)이고 그 위에서 도는 소프트웨어 (펌웨어)가 따로 있다.

구분	비유	설명
FC 보드	서버(물리 머신)	센서·연산·출력을 담당하는 하드웨어
펌웨어	그 서버에 설치하는 OS	하드웨어를 직접 제어하는 소프트웨어 = ArduPilot / PX4

같은 보드에 ArduPilot을 깔 수도, PX4를 깔 수도 있다. 마치 같은 서버에 Ubuntu를 깔 수도, Debian을 깔 수도 있는 것처럼.

펌웨어(firmware)란? software(무른)와 hardware(딱딱한)의 중간(firm). 일반 앱은 OS 위에 여러 계층을 두고 돌지만, 펌웨어는 그 계층이 거의 없이 하드웨어에 딱 붙어 센서 값을 직접 읽고 모터 신호를 직접 만든다. 특정 하드웨어에 맞춰져 있고, 웬만해선 자주 안 바꾼다.

Pixhawk란

FC = 카테고리 (드론의 뇌 역할을 하는 보드 일반, "노트북")
Pixhawk = 그 카테고리의 대표 제품 브랜드 ("맥북")
ArduPilot / PX4 = 그 위에 까는 펌웨어(OS 격)

Pixhawk가 사실상 표준처럼 자리 잡아서, FC를 말할 때 대명사처럼 쓰이곤 한다. (이름이 비슷한 PX4 펌웨어와 Pixhawk 보드는 초기 같은 프로젝트에서 갈라져 나온 형제지만, 지금은 별개다. Pixhawk 보드에 ArduPilot도 얼마든지 설치 가능.)

2. Ardupilot vs PX4

둘 다 오픈소스 autopilot 펌웨어이다. 같은 FC 보드에 골라서 설치한다.

	ArduPilot	PX4
성격	오래됨, 기능 방대, 커뮤니티 중심	상대적으로 모던, 기업/연구 친화, 구조가 깔끔
라이선스	GPLv3 (강한 카피레프트)	BSD (상업적으로 부담 적음)
지원 기체	멀티콥터·고정익·로버·잠수정 등 매우 광범위	주로 드론(멀티콥터·VTOL) 중심
개발자 관점	설정 옵션이 많고 "뭐든 된다" 스타일	코드가 모듈화되어 있고 정돈된 스타일

- Ardupilot = 방대한 기능, 뭐든 되고 옵션이 많음
- PX4 = 구조가 깔끔한 잘 설계된 프레임워크

+) 라이선스가 왜 실무적으로 중요한가?

ArduPilot(GPL): 소스를 수정하면 그 수정 사항을 오픈소스로 공개해야 한다.
PX4(BSD): 수정 내용을 공개하지 않아도 된다 → 상업적으로 부담이 적어 기업이 선호하기도 한다.

즉, 라이선스는 단순 표기가 아니라 회사가 어느 펌웨어를 고르느냐에 실제로 영향을 주는 요소다.

3. 데이터를 단순히 받기만 하는 내가 왜 FC/펌웨어를 알아야 할까

핵심: 나는 FC 펌웨어를 직접 수정하지 않는다. ArduPilot/PX4는 이미 완성된 펌웨어이고, 나는 그게 내보내는 데이터를 받는 소비자(consumer) 쪽이다. (백엔드로 치면, 남이 운영하는 외부 API의 응답을 파싱하는 입장. API 서버 코드를 고치는 입장이 아니다.)

그럼에도 이 둘을 알아야 하는 이유:

MAVLink 데이터를 만들어내는 주체가 바로 이 펌웨어다. 데이터의 출처이자 생산자. 어느 펌웨어인지에 따라 보내는 메시지 종류·주기·dialect가 미묘하게 다를 수 있다.
SITL로 가짜 드론을 띄울 때 ArduPilot 계열이냐 PX4 계열이냐를 골라야 한다. (시뮬레이터가 다름)
비행 모드 번호, 파라미터 이름이 펌웨어마다 조금씩 다르다. 디코딩한 값을 해석할 때 해당 펌웨어 문서를 봐야 한다.

dialect(방언)란? MAVLink는 드론↔지상의 공통 언어(프로토콜) = 표준어. 그 위에 특정 진영이 얹은 추가 어휘 묶음이 방언이다. (영어는 공통이지만 미국식엔 영국엔 없는 단어가 있는 것과 같다.) ArduPilot의 방언 이름은 ardupilotmega. 나중에 pymavlink로 디코딩할 때 이 방언을 지정하게 된다.

참고: MAVLink는 펌웨어 공통

MAVLink 프로토콜 자체는 ArduPilot·PX4 공통이다. 그래서 "ArduPilot이냐 PX4냐"를 지금 급하게 정할 필요는 없다. (다만 회사가 ArduPilot을 쓴다면, 실습과 문서는 ArduPilot 기준으로 몰아서 배우는 게 효율적이다.) 또한 둘 다 MAVLink를 쓰기 때문에 QGroundControl 같은 지상국 소프트웨어가 양쪽 모두와 호환된다.

참고: MAVLink에는 v1.0 / v2.0 두 버전이 있고, v2는 v1과 하위 호환된다. 나중에 디코더가 어느 버전을 파싱하는지가 실무에서 중요해진다.

이해 점검 (셀프 Q&A)

Q. FC 하드웨어와 펌웨어의 관계를 서버/OS 비유로?

보드 = 서버, 펌웨어 = 서버에 설치하는 OS. Windows/Linux를 고르듯 ArduPilot/PX4를 고른다.

Q. 나는 펌웨어 코드를 수정하나, 데이터를 받나?

받는 쪽. ArduPilot/PX4는 완성된 펌웨어이고, 나는 그 출력을 소비한다.

Q. ArduPilot/PX4를 지금 안 정해도 되는 이유?

MAVLink 프로토콜이 공통이라, 펌웨어별 차이는 나중에 생각해도 된다.

참고 자료

ArduPilot 공식 문서: https://ardupilot.org/ardupilot/
PX4 공식 문서: https://docs.px4.io/
MAVLink 공식 문서: https://mavlink.io/en/
pymavlink (파이썬 MAVLink 라이브러리): https://github.com/ArduPilot/pymavlink
Intro to ArduPilot and PX4 (Circuit Cellar): https://circuitcellar.com/research-design-hub/intro-to-ardupilot-and-px4-part-1/
PX4 vs ArduPilot 비교 (ThinkRobotics): https://thinkrobotics.com/blogs/learn/px4-vs-ardupilot-complete-comparison-guide-for-drone-developers

[NLP] NLP란?

말하는 알감자 — Mon, 6 Jul 2026 11:19:06 +0900

1. 자연어 처리란?

자연어(Natural Language) 란 우리가 일상생활에서 사용하는 언어를 말한다.
자연어 처리(Natural Language Processing, NLP) 란 이러한 자연어의 의미를 분석하여 컴퓨터가 처리할 수 있도록 하는 일을 말한다.

NLP는 다음과 같은 다양한 분야에서 사용된다.

음성 인식
내용 요약
번역
사용자의 감성 분석
텍스트 분류 (스팸 메일 분류, 뉴스 기사 카테고리 분류 등)
질의 응답 시스템
챗봇

한마디로 NLP는 기계에게 인간의 언어를 이해시키기 위한 분야라고 할 수 있다.

2. 머신 러닝 워크플로우

데이터를 수집하고 머신 러닝을 수행하는 과정은 크게 6단계로 나눌 수 있다.
(딥 러닝 또한 머신 러닝의 한 갈래이므로 딥 러닝 워크플로우도 같은 흐름으로 볼 수 있다.)

출처 : https://wikidocs.net/31947

1) 수집 (Acquisition)

머신 러닝을 하려면 먼저 기계에 학습시킬 데이터가 필요하다.

자연어 처리에서는 이 자연어 데이터를 말뭉치 또는 코퍼스(corpus) 라고 부른다. 코퍼스란 조사나 연구 목적에 의해 특정 도메인으로부터 수집된 텍스트 집합을 의미한다.

파일 형식: .txt, .csv, .xml 등 다양
출처: 음성 데이터, 웹 크롤러로 수집한 데이터, 영화 리뷰 등 다양

2) 점검 및 탐색 (Inspection and Exploration)

데이터가 수집되었다면 이제 데이터를 점검하고 탐색하는 단계다. 데이터의 구조, 노이즈, 어떻게 정제해야 할지 등을 파악한다.

이 단계를 탐색적 데이터 분석(Exploratory Data Analysis, EDA) 단계라고도 부른다.

독립 변수, 종속 변수, 변수 유형, 데이터 타입 등을 점검
데이터의 특징과 내재하는 구조적 관계를 파악
이 과정에서 시각화와 간단한 통계 테스트를 진행하기도 함

3) 전처리 및 정제 (Preprocessing and Cleaning)

데이터에 대한 파악이 끝났다면, 워크플로우에서 가장 까다로운 작업 중 하나인 데이터 전처리 과정에 들어간다.

자연어 처리라면 다음과 같은 단계를 포함한다.

토큰화 (Tokenization)
정제 (Cleaning)
정규화 (Normalization)
불용어 제거 (Stopword Removal)

빠르고 정확한 전처리를 위해서는 사용하는 툴(파이썬 등)의 다양한 라이브러리에 대한 지식이 필요하다. 정말 까다로운 경우에는 전처리 과정에서 머신 러닝이 사용되기도 한다.

4) 모델링 및 훈련 (Modeling and Training)

전처리가 끝났다면 머신 러닝 코드를 작성하는 모델링 단계에 들어간다. 적절한 알고리즘을 선택해 모델링이 끝나면, 전처리된 데이터를 알고리즘에 넣어 기계를 학습(training) 시킨다.

학습이 제대로 되면 기계는 번역, 음성 인식, 텍스트 분류 등 우리가 원하는 작업을 수행할 수 있게 된다.

⚠️ 주의: 모든 데이터를 학습에 쓰면 안 된다!

데이터 일부는 테스트용으로 남겨두고 훈련용 데이터만 훈련에 사용해야 한다. 그래야 학습 후 테스트용 데이터로 성능을 측정할 수 있고, 과적합(overfitting) 을 막을 수 있다.

사실 최선은 두 가지가 아니라 세 가지로 나누는 것이다.

출처 : https://wikidocs.net/31947

검증용 vs 테스트용의 차이

수능 시험에 비유하면 이해가 쉽다.

데이터	비유	역할
훈련용 (Train)	학습지	기계를 학습시키는 데 사용
검증용 (Validation)	모의고사	학습이 얼마나 됐는지 판단하고 성능을 개선하는 데 사용
테스트용 (Test)	수능 시험	모델의 최종 성능을 수치화하여 평가 (채점 단계)

검증용 데이터는 모델의 성능을 개선하는 데 쓰고, 테스트용 데이터는 개선이 아니라 평가에만 쓴다는 점이 핵심이다.
현업에서 최선은 검증용 데이터까지 사용하는 것이다.

5) 평가 (Evaluation)

학습이 완료되면 테스트용 데이터로 성능을 평가한다. 평가 방법은 기계가 예측한 값이 테스트용 데이터의 실제 정답과 얼마나 가까운지를 측정하는 것이다.

6) 배포 (Deployment)

평가 단계에서 성공적으로 훈련된 것으로 판단되면, 완성된 모델을 배포한다.

다만 배포 후 전체적인 피드백으로 인해 모델을 업데이트해야 하는 상황이 오면, 다시 수집 단계로 돌아갈 수 있다.

[데이터베이스] 1. 데이터베이스의 기본

말하는 알감자 — Tue, 12 May 2026 16:41:39 +0900

데이터베이스란?

데이터베이스(DB, DataBase) 는 일정한 규칙, 혹은 규약을 통해 구조화되어 저장되는 데이터의 모음이다.
해당 데이터베이스를 제어, 관리하는 통합 시스템을 DBMS(DataBase Management System) 라고 한다.

데이터베이스 안에 있는 데이터들은 특정 DBMS마다 정의된 쿼리 언어(query language)를 통해 삽입, 삭제, 수정, 조회 등을 수행할 수 있다. 또한, 데이터베이스는 실시간 접근과 동시 공유가 가능하다.

응용 프로그램
    ↕
  DBMS
    ↕
데이터베이스

데이터베이스 위에 DBMS가 있고 그 위에 응용 프로그램이 있으며, 이러한 구조를 기반으로 데이터를 주고받는다.

예를 들어 MySQL이라는 DBMS가 있고 그 위에 응용 프로그램에 속하는 Node.js나 PHP에서 해당 데이터베이스 안에 있는 데이터를 끄집어내 관련 로직을 구축할 수 있다.

1.1. 엔터티 (Entity)

엔터티는 사람, 장소, 물건, 사건, 개념 등 여러 개의 속성을 지닌 명사를 의미한다.

예를 들어 '회원'이라는 엔터티가 있다고 해보자. 회원은 다음과 같은 속성을 갖는다.

이름
아이디
주소
전화번호

물론 이보다 많은 속성이 있지만 서비스의 요구 사항에 맞춰 속성이 정해진다. 주소라는 속성이 서비스의 요구 사항과 무관하다면 주소라는 속성은 사라지게 된다.

약한 엔터티와 강한 엔터티

약한 엔터티: 혼자서는 존재하지 못하고 다른 엔터티에 종속적인 엔터티
강한 엔터티: 단독으로 존재할 수 있는 엔터티

예: '방'은 '건물' 안에만 존재하므로 방은 약한 엔터티, 건물은 강한 엔터티.

1.2. 릴레이션 (Relation)

릴레이션은 데이터베이스에서 정보를 구분하여 저장하는 기본 단위다. 엔터티에 관한 데이터를 데이터베이스는 릴레이션 하나에 담아서 관리한다.

부르는 이름 데이터베이스 종류

테이블(Table)	관계형 데이터베이스 (MySQL 등)
컬렉션(Collection)	NoSQL 데이터베이스 (MongoDB 등)

테이블과 컬렉션의 구조

MySQL: 레코드 → 테이블 → 데이터베이스
MongoDB: 도큐먼트 → 컬렉션 → 데이터베이스

레코드(또는 도큐먼트)가 쌓여서 테이블(또는 컬렉션)이 되고, 그것들이 쌓여 데이터베이스가 된다.

1.3. 속성 (Attribute)

속성은 릴레이션에서 관리하는 구체적이며 고유한 이름을 갖는 정보다.

예를 들어 '차'라는 엔터티의 속성을 뽑아보자.

차 넘버
바퀴 수
차 색깔
차종

이 중에서 서비스의 요구 사항을 기반으로 관리해야 할 필요가 있는 속성들만 엔터티의 속성이 된다.

1.4. 도메인 (Domain)

도메인이란 릴레이션에 포함된 각각의 속성들이 가질 수 있는 값의 집합을 말한다.

예를 들어 '성별'이라는 속성이 있다면 이 속성이 가질 수 있는 값은 {남, 여}라는 집합이 된다.

1.5. 필드와 레코드

위 개념들을 기반으로 데이터베이스에서 필드와 레코드로 구성된 테이블을 만들 수 있다.

member 테이블 예시

name	ID	address	phonenumber
큰돌	kundol	서울	112
가영	kay	대전	114
빅뱅	big	카이루	119

필드(field): 컬럼(name, ID, address, phonenumber)
레코드(record) = 튜플(tuple): 행 단위의 데이터

필드 타입

필드는 타입을 갖는다. 이름은 문자열이고 전화번호는 숫자다. 이러한 타입들은 DBMS마다 다르다. (이하 MySQL 기준)

숫자 타입

타입	용량(바이트)	최솟값(부호 있음)	최댓값(부호 있음)
TINYINT	1	-128	127
SMALLINT	2	-32,768	32,767
MEDIUMINT	3	-8,388,608	8,388,607
INT	4	-2,147,483,648	2,147,483,647
BIGINT	8	-2⁶³	2⁶³-1

날짜 타입

DATE: 날짜 부분은 있지만 시간 부분은 없는 값. 1000-01-01 ~ 9999-12-31. 3바이트.
DATETIME: 날짜 및 시간 부분을 모두 포함. 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59. 8바이트.
TIMESTAMP: 날짜 및 시간 부분을 모두 포함. 1970-01-01 00:00:01 ~ 2038-01-19 03:14:07. 4바이트.

문자 타입

CHAR: 고정 길이 문자열, 0~255 사이. 선언한 길이로 '고정' 저장. CHAR(100)으로 선언 후 10글자를 저장해도 100바이트로 저장.
VARCHAR: 가변 길이 문자열, 0~65,535 사이. 입력된 데이터에 따라 용량 가변. 10글자 이메일 저장 시 → 10바이트 + 길이기록용 1바이트.
TEXT: 큰 문자열 저장 (게시판 본문 등).
BLOB: 이미지, 동영상 등 큰 데이터 저장. 보통은 S3 같은 외부에 파일을 올리고 그 경로를 VARCHAR로 저장.
ENUM: ENUM('x-small', 'small', 'medium', 'large', 'x-large') 형태. 단일 선택. 최대 65,535개 요소. 메모리 절약 가능.
SET: ENUM과 비슷하지만 여러 개 선택 가능, 비트 단위 연산. 최대 64개 요소.

CHAR vs VARCHAR: 유동적이지 않은 길이의 데이터는 CHAR, 유동적인 길이는 VARCHAR가 효율적.

1.6. 관계 (Relationship)

데이터베이스에 테이블은 하나만 있는 것이 아니다. 여러 개의 테이블이 있고, 이러한 테이블은 서로 관계가 정의되어 있다. 이 관계를 관계화살표로 나타낸다.

관계 의미

1:1	하나의 A는 하나의 B로 구성되어 있다
1:N	하나의 A는 하나 이상의 B로 구성되어 있다
1:0~1	하나의 A는 하나 이하의 B로 구성되어 있다
1:0~N	하나의 A는 0 또는 하나 이상의 B로 구성되어 있다

1:1 관계

유저당 유저 이메일은 한 개씩 있는 경우. 테이블을 두 개의 테이블로 나눠 구조를 더 이해하기 쉽게 만들어준다.

1:N 관계

쇼핑몰에서 한 유저당 여러 개의 상품을 장바구니에 넣는 경우. 한 개체가 다른 많은 개체를 포함하는 관계.

N:M 관계

학생과 강의의 관계처럼 양쪽 모두 다수가 다수에 속하는 경우. N:M은 테이블 두 개를 직접 연결해서 구축하지 않고 1:N, 1:M 관계를 갖는 테이블 두 개로 나눠서 설정한다. (학생, 강의 사이에 학생_강의 테이블이 끼게 된다.)

1.7. 키 (Key)

테이블 간의 관계를 명확하게 하고 테이블 자체의 인덱스를 위해 설정된 장치. 다음 다섯 가지가 있다.

           ┌─ 슈퍼키 (유일성) ─┐
           │                │
           │  ┌─ 후보키 ─┐    │
           │  │ (최소성) │    │
           │  │ ┌────┐ │     │
           │  │ │기본키│ │     │ ← 대체키
           │  │ └────┘  │    │
           │  └─────────┘    │
           └─────────────────┘

유일성: 중복되는 값이 없음
최소성: 필드를 조합하지 않고 최소 필드만 써서 키를 형성

1) 기본키 (Primary Key, PK)

유일성과 최소성을 만족하는 키. 자연키 또는 인조키 중에 골라 설정한다.

- 자연키 (Natural Key)

자연스럽게 뽑아내는 키. 예: 주민등록번호. 언젠가는 변하는 속성을 가진다.

- 인조키 (Surrogate Key)

인위적으로 부여한 고유 식별자. 오라클은 sequence, MySQL은 auto_increment 등으로 설정. 변하지 않음.
따라서 보통 기본키는 인조키로 설정한다.

2) 외래키 (Foreign Key, FK)

다른 테이블의 기본키를 그대로 참조하는 값으로, 개체와의 관계를 식별. 중복되어도 괜찮다.

3) 후보키 (Candidate Key)

기본키가 될 수 있는 후보들이며 유일성과 최소성을 동시에 만족하는 키

4) 대체키 (Alternate Key)

후보키가 두 개 이상일 경우 어느 하나를 기본키로 지정하고 남은 후보키들

5) 슈퍼키 (Super Key)

각 레코드를 유일하게 식별할 수 있는 유일성을 갖춘 키

[운영체제] 2. 메모리

말하는 알감자 — Sun, 3 May 2026 12:05:07 +0900

2.1 메모리 계층

메모리 계층은 레지스터 → 캐시 → 메모리(RAM) → 저장장치(HDD/SDD) 순으로 구성됨

     속도 빠름, 용량 작음, 가격 비쌈
             ▲
             │   ┌─────────────┐
             │   │   레지스터    │  ← CPU 안에 있는 작은 메모리
             │   ├─────────────┤
             │   │  캐시(L1,L2) │  ← 빠른 임시 저장소
             │   ├─────────────┤
             │   │  메모리(RAM)  │  ← 주기억장치
             │   ├─────────────┤
             │   │  HDD / SSD  │  ← 보조기억장치
             ▼   └─────────────┘
    속도 느림, 용량 많음

계층별 특징

계층	휘발성	속도	용량
레지스터	휘발성	가장 빠름	가장 적음
캐시 (L1, L2)	휘발성	빠름	적음
주기억장치 (RAM)	휘발성	보통	보통
보조기억장치 (HDD/SDD)	비휘발성	느림	많음

왜 계층 구조가 존재하는가?

계층 구조가 있는 이유는 경제성과 캐시 때문

16GB RAM → 약 8만 원
16GB SDD → 훨씬 더 싼 가격

계층 위로 올라갈수록 가격을 비싸지는데 용량은 작아지고 속도는 빨라지는 특징이 있음
이러한 경제성 때문에 계층을 둬서 관리

로딩 중 메시지 = HDD/SSD(보조기억장치) → RAM(주기억장치)으로 데이터를 전송하는 과정이 아직 끝나지 않음을 의미

2.1.1 캐시 (Cache)

캐시는 데이터를 미리 복사해 놓는 임시 저장소이자 빠른 장치와 느린 장치에서 속도 차이에 따른 병목 현상을 줄이기 위한 메모리를 말함

실제로 메모리와 CPU 사이의 속도 차이가 너무 크기 때문에, 그 중간에 레지스터 계층을 두어 속도 차이를 해결
이렇게 속도 차이를 해결하기 위해 계층과 계층 사이에 있는 계층을 캐싱 계층이라고 함

지역성의 원리

캐시를 직접 설정할 때는 자주 사용하는 데이터를 기반으로 설정해야 함
자주 사용하는 데이터의 근거가 되는 것이 바로 지역성

시간 지역성 (Temporal Locality)

최근 사용한 데이터에 다시 접근하려는 특성

// 변수 i는 매 반복마다 계속 접근됨 → 시간 지역성
for (let i = 0; i < 10; i += 1) {
    arr[i] = i;
}

공간 지역성 (Spatial Locality)

최근 접근한 데이터를 이루고 있는 공간이나 그 가까운 공간에 접근하려는 특성

// 배열 arr의 각 요소에 순서대로 연속 접근 → 공간 지역성
for (let i = 0; i < 10; i += 1) {
    arr[i] = i;  // arr[0], arr[1], arr[2]... 연속된 공간 접근
}

2.1.2 캐시히트와 캐시 미스

용어	설명
캐시히트	캐시에서 원하는 데이터를 찾은 경우 CPU 내부 버스를 기반으로 작동하여 빠름
캐시미스	해당 데이터가 캐시에 없어 주 메모리로 가서 데이터를 찾아오는 것 시스템 버스를 기반으로 작동하여 느림

캐시매핑

캐시매핑이란 캐시가 히트되기 위해 매핑하는 방법을 말함
CPU 레지스터와 주 메모리(RAM) 간에 데이터를 주고받을 때를 기반으로 설명

이름	설명
직접 매핑 (Diredted Mapping)	메모리 1 ~ 100이 있고 캐시가 1 ~ 10이 있다면 1 : 1~10, 2 : 20~30 이런 식으로 매핑 처리가 빠르지만 충돌 발생이 잦음
연관 매핑 (Associative Mapping)	순서를 일치시키지 않고 관련 있는 캐시와 메모리를 매핑 충돌이 적지만 모든 블록을 탐색해야 해서 속도가 느림
직접 연관 매핑 (Set Associative Mapping)	직접 매핑과 연관 매핑을 합쳐놓은 것 캐시 1~5에는 1~50의 데이터를 무작위로 저장

웹 브라우저의 캐시

소프트웨어적인 대표적인 캐시로는 웹 브라우저의 작은 저장소 쿠키, 로컬 스토리지, 세션 스토리지가 있음

저장소	만료 기한	용량	특징
쿠키	있음	4KB	same site 옵션을 strict로 설정하지 않으면 다른 도메인에서 요청 시 자동 전송 httponly 옵션을 서버, 클라이언트 어디에서도 수정 가능하지만 보통 서버에서 정함
로컬 스토리지	없음	10MB	웹 브라우저를 닫아도 유지됨 도메인 단위로 저장 클라이언트에서만 수정 가능
세션 스토리지	없음	5MB	탭 단위로 생성 탭을 닫을 때 데이터 삭제 클라이언트에서만 수정 가능

데이터베이스의 캐싱 계층 : 메인 데이터베이스 위에 레디스(redis) 데이터베이스 계층을 '캐싱 계층'으로 두어 성능을 향상하기도 함

2.2 메모리 관리

운영체제의 대표적인 할 일 중 하나. 컴퓨터 내의 한정된 메모리를 극한으로 활용

2.2.1 가상 메모리 (Virtual Memory)

가상 메모리는 메모리 관리 기법의 하나로 컴퓨터가 실제로 이용 가능한 메모리 자원을 추상화하여 이를 사용하는 사용자들에게 매우 큰 메모리로 보이게 만드는 것

 프로세스 A    프로세스 B    프로세스 C
가상 0x0000  가상 0x0000  가상 0x0000
    ↓           ↓            ↓
   ┌─────────────────────────┐
   │     MMU (메모리관리장치)    │
   └─────────────────────────┘
    ↓           ↓            ↓
RAM 0x1000  RAM 0x5000  RAM 0x9000
        (실제로는 서로 다른 공간)

각 프로세스는 "혼자 메모리 전체를 사용하는" 착각을 하게 됨
개발자는 실제 메모리의 물리적 위치를 신경 쓰지 않고 프로그램을 구축할 수 있게 됨

가상 주소 VS 실제 주소

용어	설명
가상 주소 (logical address)	프로세스가 바라보는 주소. 각 프로세스에게 독립적으로 부여
실제 주소 (physical address)	RAM 위에 실제로 존재하는 주소

가상 주소는 MMU(메모리 관리 장치)에 의해 실제 주소로 변환됨
가살 메모리는 가상 주소와 실제 주소가 매핑되어 있는 페이지 테이블로 관리됨

TLB

TLB는 메모리와 CPU 사이에 있는 주소 변환을 위한 캐시
페이지 테이블에 있는 리스트를 보관하며, CPU가 페이지 테이블까지 가지 않아도 되도록 속도를 향상하는 캐시 계층

스와핑 (Swapping)

가상 메모리에는 존재하지만 실제 메모리인 RAM에는 현재 없는 데이터나 코드에 접근할 경우 페이지 폴트가 발생
이때 메모리에서 당장 사용하지 않는 영역을 HDD/SSD로 옮기고, HDD/SDD의 일부분을 마치 메모리처럼 불러와 쓰는 것이 스와핑
이를 통해 마치 페이지 폴트가 일어나지 않은 것처럼 만듦

페이지 폴트 (Page Fault)

프로세스의 주소 공간에는 존재하지만 지금 이 컴퓨터의 RAM에는 없는 데이터에 접근했을 경우 발생

프로세스 가상 주소 공간 (페이지 테이블)
        ↓
   RAM에 있음? ────YES───→ 정상 접근
        ↓ NO
   페이지 폴트 발생
        ↓
  HDD/SSD(스왑 영역)에서 RAM으로 불러옴
        ↓
    스와핑 발동

페이지 폴트 처리 과정

1. CPU가 물리 메모리를 확인하여 해당 페이지가 없으면 트랩을 발생시켜 운영체제에 알림
2. 운영체제는 CPU 동작을 잠시 멈춤
3. 운영체제가 페이지 테이블을 확인하여 가상 메모리에 페이지가 존재하는지 확인
없으면 프로세스를 중단하고 물리 메모리에 비어있는 프레임을 찾음
물리 메모리에도 없다면 스와핑 발동
4. 비어있는 프레임에 해당 페이지를 로드하고 페이지 테이블 최신화
5. 중단되었던 CPU를 다시 시작

페이지(page)와 프레임(frame)
페이지는 가상 메모리를 사용하는 최소 크기 단위
프레임은 실제 메모리를 사용하는 최소 크기 단위

2.2.2 스레싱(Thrashing)

메모리의 페이지 폴트율이 높은 것을 의미하며, 컴퓨터의 심각한 성능 저하를 초래
드레싱의 근본 원인은 RAM이 부족해서 프로세스들이 서로 페이지를 차지하려고 경쟁하는 것

스레싱 발생 원인 (악순환)

너무 많은 프로세스가 메모리에 올라옴
        ↓
스와핑이 빈번하게 발생
        ↓
페이지 폴트 발생 → CPU 이용률 낮아짐
        ↓
운영체제: "CPU가 한가한가?" → 더 많은 프로세스를 메모리에 올림
        ↓
다시 스와핑 증가...   (악순환)

→ 페이지 폴트가 너무 자주 발생해서 CPU가 실제 연산을 못하게 되는 상황

스레싱 해결 방법

① 작업 세트 (working set)

"자주 쓸 페이지를 미리 RAM에 올려놓자" → "예방"

프로세스의 과거 사용 이력인 지역성(locality)을 통해 결정된 페이지 집합을 만들어서 미리 메모리에 로드하는 방법
미리 메모리에 로드하면 탐색에 드는 비용을 줄일 수 있고 스와핑 또한 줄일 수 있음

미리 RAM에 올려둠
    ↓
페이지 폴트 자체가 안 발생
    ↓
스와핑 횟수 감소 → 스레싱 완화 ✅

② PFF (Page Fault Frequency)

"페이지 폴트 빈도 자체를 직접 조절하자" → "실시간 모니터링 및 조절"

페이지 폴트 빈도를 조절하는 방법으로 상한선과 하한선을 만드는 방법
상한선에 도달하면 프레임을 늘리고, 하한선에 도달하면 프레임을 줄임

페이지 폴트율이 상한선 초과
    ↓ 프레임 수 늘림
해당 프로세스에 RAM 더 할당
    ↓
페이지 폴트 감소 ✅

페이지 폴트율이 하한선 미달
    ↓ 프레임 수 줄임
RAM을 다른 프로세스에 양보
    ↓
전체 메모리 효율 증가 ✅

③ 메모리를 늘림

"근본적인 원인인 메모리 부족 자체를 해결하자" → 가장 직접적이고 비용이 드는 물리적 해결책

RAM 부족
    ↓
여러 프로세스가 RAM 자리를 두고 경쟁
    ↓
페이지 폴트 폭발 → 스레싱

RAM을 늘리면
    ↓
모든 프로세스가 충분한 프레임 확보
    ↓
페이지 폴트 자체가 줄어듦 ✅

④ HDD를 SDD로 바꿈

"스와핑 자체는 피할 수 없다면, 스와핑 속도를 빠르게 하자"

HDD 스와핑 속도: 매우 느림  
    ↓
페이지 폴트 발생 시 HDD에서 가져오는 데 오래 걸림
    ↓
CPU가 오래 대기 → 이용률 급감 → 스레싱 심화
────────────────────────────────────────────
SSD로 교체하면
    ↓
스와핑 속도가 훨씬 빨라짐
    ↓
페이지 폴트 처리 시간 단축
    ↓
CPU 대기 시간 감소 → 스레싱 완화 ✅

2.2.3 메모리 할당

메모리에 프로그램을 할당할 때는 시작 메모리 위치, 메모리의 할당 크기를 기반으로 할당
연속 할당과 불연속 할당으로 나뉨

연속 할당

메모리에 '연속적으로' 공간을 할당하는 것

① 고정 분할 방식 (Fixed Partition Allocation)

메모리를 미리 나누어 관리하는 방식
융통성 없음
내부 단편화 발생

② 가변 분할 방식 (Variable Partition Allocation)

매 시점 프로그램의 크기에 맞게 동적으로 메모리를 나눠 사용
외부 단편화 발생 가능

방식	설명
최초 적합 (First Fit)	위쪽이나 아래쪽부터 시작해서 홀을 찾으면 바로 할당
최적 적합 (Best Fit)	프로세스의 크기 이상인 공간 중 가장 작은 홀부터 할당
최악 적합 (Worst Fit)	프로세스의 크기와 가장 많이 차이나는 홀에 할당

단편화 용어 정리

용어	설명
내부 단편화 (Internal Fragmentation)	메모리를 나눈 크기보다 프로그램이 작아서 들어가지 못하는 공간이 많이 발생하는 현상
외부 단편화 (External Fragmentation)	메모리를 나눈 크기보다 프로그램이 커서 들어가지 못하는 현상 ex) 100MB를 55MB, 45MB로 나눴지만 프로그램이 70MB일 때
홀 (Hole)	할당할 수 있는 비어 있는 메모리 공간

불연속할당

메모리를 연속적으로 할당하지 않는 현대 운영체제가 쓰는 방법

① 페이징 (Paging)

동일한 크기의 페이지 단위로 나누어 메모리의 서로 다른 위치(RAM의 빈 프레임 아무 곳에나)에 프로세스를 할당
홀의 크기가 균일하지 않은 문제가 없어지지만 주소 변환이 복잡해짐

주소 변환이 복잡해지는 이유 : 페이징이 주소 변환이 복잡한 이유는 프로세스가 연속된 공간이 아닌 흩어진 프레임에 저장되기 때문에, CPU가 데이터에 접근할 때마다 "이 페이지가 RAM의 어느 프레임에 있는지"를 페이지 테이블에서 반드시 조회해야 하기 때문

→ 조회 비용을 줄이기 위해 TLB(주소 변환 캐시) 등장

② 세그멘테이션 (Segmentation)

페이지 단위가 아닌 의미 단위인 세그먼트(Segment)로 나누는 방식
프로세스를 이루는 메모리는 코드 영역, 데이터 영역, 스택 영역, 힙 영역으로 이루어지는데, 코드와 데이터로 나누거나 코드 내의 작은 함수를 세그먼트로 나눌 수도 있음
공유와 보안 측면에서 장점을 가지지만 홀 크기가 균일하지 않은 단점이 있음

③ 페이지 세그멘테이션 (Page Segmentation)

프로그램을 의미 단위인 세그먼트로 나눠 공유나 보안 측면에서 장점을 두고, 임의의 길이가 아닌 동일한 크기의 페이지 단위로 나누는 것

2.2.4 페이지 교체 알고리즘

메모리는 한정되어 있기 때문에 스와핑이 자주 발생
스와핑은 많이 일어나지 않도록 설계되어야 하며, 이는 페이지 교체 알고리즘을 기반으로 함

알고리즘	설명	특징
오프라인 알고리즘	먼 미래에 참조되는 페이지와 현재 할당하는 페이지를 바꾸는 방법	가장 좋지만 미래를 알 수 없어 사용 불가 다른 알고리즘의 상한기준 (upper_bound)제공
FIFO	가장 먼저 온 페이지를 교체 영역에 가장 먼저 놓는 방법	구현 단순 자주 쓰는 페이지도 오래됐다는 이유로 교체될 수 있음
LRU	참조가 가장 오래된 페이지를 바꿈	각 페이지마다 계수기, 스택을 두어야하는 문제점 존재
NUR (clock 알고리즘)	0과 1의 비트를 두고 시계 방향으로 돌면서0을 찾아 교체하고 1로 바꿈	LRU에서 발전한 방식
LFU	가장 참조 횟수가 적은 페이지를 교체	많이 사용되지 않은 것을 교체

LRU 구현 방법

LRU를 프로그래밍으로 구현할 때는 보통 해시 테이블 + 이중 연결 리스트 두 개의 자료구조로 구현

자료구조	역할
해시 테이블	이중 연결 리스트에서 특정 페이지를 O(1) 에 빠르게 찾을 수 있도록
이중 연결 리스트	한정된 메모리를 나타냄. 가장 최근에 사용된 순서 유지

[운영체제] 1. 운영체제와 컴퓨터

말하는 알감자 — Sat, 2 May 2026 16:51:31 +0900

1.1 운영체제

운영체제 (OS, Operating System)은 사용자가 컴퓨터를 쉽게 다루게 해 주는 인터페이스
한정된 메모리나 시스템 자원을 효율적으로 분배하는 일꾼

펌웨어(firmware) : 운영체제와 유사하지만 소프트웨어를 추가로 설치할 수 없는 것

1.1.1 운영체제의 역할

역할	설명
CPU 스케줄링과 프로세스 관리	CPU 소유권을 어떤 프로세스에 할당할 지, 프로세스의 생성, 삭제, 자원 할당 및 반환 관리
메모리 관리	한정된 메모리를 어떤 프로세스에 얼마큼 할당해야 하는지 관리
디스크 파일 관리	디스크 파일을 어떠한 방법으로 보관할지 관리
I/O 디바이스 관리	I/O 디바이스인 마우스, 키보드, 컴퓨터 간에 데이터를 주고받는 것을 관리

1.1.2 운영체제의 구조

유저 프로그램
    ↓
   GUI          ← 사용자가 보는 화면            ┐
    ↓                                       
 시스템콜         ← 커널에 접근하기 위한 인터페이스   │  
    ↓                                         운영체제
   커널          ← 운영체제의 핵심               │ 
    ↓                                        
 드라이버         ← 하드웨어를 제어하는 소프트웨어    ┘
    ↓
 하드웨어

GUI : 사용자가 전자장치와 상호 작용할 수 있도록 하는 인터페이스
CUI : 그래픽이 아닌 명령어로 처리하는 인터페이스 (ex. 리눅스 서버)
시스템콜 : 운영체제가 커널에 접근하기 위한 인터페이스
커널 : 운영체제의 핵심 부분, 시스템콜 인터페이스를 제공하며 운영체제의 중추적인 역할 수행
드라이버 : 하드웨어를 제어하기 위한 소프트웨어

시스템콜

시스템콜이란 운영체제가 커널에 접근하기 위한 인터페이스
유저 프로그램이 운영체제의 서비스를 받기 위해 커널 함수를 호출할 때 사용

시스템콜의 역할

시스템콜은 추상화 계층의 역할을 수행

네트워크 통신, 데이터베이스 같은 낮은 단계의 처리를 직접 구현하지 않아도 됨
fs.readfile()같은 함수 호출만으로 파일 시스템에 접근 가능

동작 흐름 (I/O 요청 예시)

유저 프로그램이 fs.readFile() 호출
        ↓
    시스템콜 호출 (트랩 발생)
        ↓
  modebit 1 → 0 (유저모드 → 커널모드)
        ↓
    파일 시스템에서 파일 읽기 수행
        ↓
  modebit 0 → 1 (커널모드 → 유저모드)
        ↓
    이후 유저 프로그램 로직 수행

이 과정을 통해 컴퓨터 자원에 대한 직접 접근을 차단하고, 프로그램을 다른 프로그램으로부터 보호할 수 있음

modebit

시스템콜이 작동될 때 modebit을 참고해서 유저 모드와 커널 모드를 구분
modebit은 1또는 0의 값을 가지는 플래그 변수

modebit	mode	설명
1	유저 모드	유저가 접근할 수 있는 영역을 제한적으로 두며, 컴퓨터 자원에 함부로 침범하지 못하는 모드
0	커널 모드	모든 컴퓨터 자원에 접근할 수 있는 모드

modebit이 필요한 이유

카메라, 키보드와 같은 I/O 디바이스는 반드시 운영체제를 통해서만 작동을 해야 함
만약 유저 모드에서 직접 제어가 가능하다면, 공격자가 사용자의 동의 없이 카메라를 켜거나 키 입력을 가로채는 일이 가능해짐

1.2 컴퓨터의 요소

컴퓨터는 운영체제, CPU, DMA 컨트롤러, 메모리, 타이머, 디바이스 컨트롤러 등으로 이루어져 있음

컴퓨터의 요소

1.2.1 CPU

CPU (Central Processing Unit)은 산술논리연산장치, 제어장치, 레지스터로 구성되어 있는 컴퓨터 장치를 말함
인터럽트에 의해 단순히 메모리에 존재하는 명령어를 해석해서 실행하는 일꾼

CPU의 구성요소

구성 요소	설명
제어 장치 (CU, Control Unit)	프로세스 조작을 지시하는 CPU의 한 부품 입출력장치 간 통신을 제어하고 명령어를 읽고 해석하며 데이터 처리를 위한 순서 결정
레지스터 (register)	CPU 안에 있는 매우 빠른 임시기억장치 CPU와 직접 연결되어 있어 연산 속도가 메모리보다 수십 ~ 수백 배 빠름 CPU는 자체적으로 데이터를 저장할 방법이 없기 때문에 레지스터를 거쳐 데이터를 전달
산술논리연산장치 (ALU, Arithmetic Logic Unit)	덧셈, 뺄셈 같은 두 숫자의 산술 연산과 배타적 논리합, 논리곱 같은 논리 연산을 계산하는 디지털 회로

CPU 연산 처리 흐름

① 제어장치가 메모리에 계산할 값을 로드 + 레지스터로 로드
② 제어장치가 레지스터에 있는 값을 계산하라고 산술논리연산장치에 명령
③ 제어장치가 계산된 값을 다시 '레지스터에서 메모리로' 저장

인터럽트(Interrupt)

인터럽트란 어떤 신호가 들어왔을 때 CPU를 잠깐 정지시키는 것

인터럽트가 발생하면 인터럽트 벡터로 이동해 인터럽트 핸들러 함수가 실행됨
인터럽트 간에는 우선순위가 있고, 그 우선순위에 따라 실행됨

인터럽트 종류

종류	설명	예시
하드웨어 인터럽트	IO 디바이스에서 발생하는 인터럽트	키보드 연결, 마우스 클릭
소트트웨어 인터럽트 (= 트랩)	프로세스 오류 등으로 프로세스가 시스템콜을 호출할 때 발생	0으로 나누기, 프로세스 오류

인터럽트 핸들러 함수 : 인터럽트가 발생했을 때 이를 핸들링하기 위한 함수
커널 내부의 IRQ를 통해 호출되며 request_irq()를 통해 등록

1.2.2 DMA 컨트롤러

DMA 컨트롤러는 I/O 디바이스가 메모리에 직접 접근할 수 있도록 하는 하드웨어 장치

CPU에만 너무 많은 인터럽트 요청이 들어오기 때문에 CPU 부하를 막아주는 보조 일꾼
하나의 작업을 CPU와 DMA 컨트롤러가 동시에 하는 것을 방지

1.2.3 메모리(Memory)

메모리(RAM)은 전자회로에서 데이터나 상태, 명령어 등을 기록하는 장치
CPU는 계산을 담당하고 메모리는 기억을 담당

공장에 비유하자면 CPU는 일꾼이고, 메모리는 작업장
작업장이 클수록 창고에서 물건을 많이 가져다 놓고 많은 일을 할 수 있듯이, 메모리가 크면 클수록 많은 일을 동시에 할 수 있음

1.2.4 타이머(Timer)

타이머는 몇 초 안에는 작업이 끝나야 한다는 것을 정하고 특정 프로그램에 시간 제한을 다는 역할

시간이 많이 걸리는 프로그램이 작동할 때 제한을 걸기 위해 존재
타이머가 없다 -> 하나의 프로그램이 CPU를 무한정 독점하는 상황 발생

1.2.5 디바이스 컨트롤러 (Device Controller)

디바이스 컨트롤러는 컴퓨터와 연결되어 있는 IO 디바이스들의 작은 CPU
옆에 붙어 있는 로컬 버퍼는 각 디바이스에서 데이터를 임시로 저장하기 위한 작은 메모리

[Langflow] Langflow API Key 생성

말하는 알감자 — Wed, 17 Dec 2025 15:33:38 +0900

1. API keys 와 authentication(인증)

LangFlow는 외부 요청과 내부 서비스 연결을 보호하기 위해 인증 자격 증명(Authentication credentials) 을 사용합니다.

인증 자격 증명의 종류는 다음 3가지입니다.

LangFlow API Keys→ Flow 실행, 파일 업로드 등 서버 측 작업 승인에 사용
→ LangFlow 서버 자체를 호출하기 위한 인증 키
Component API Keys→ 예: OpenAI, Gemini, 서드파티 API 등
→ 모델 제공자 또는 외부 서비스(API)와 통신할 때 사용하는 키
Authentication Environment Variables
→ LangFlow 서버의 사용자 인증(Authentication) 및 권한 부여(Authorization) 동작을 설정하는 환경 변수

+) ⚠️ 보안 관련 주의 사항

LangFlow 포트를 아무 보안 설정 없이 인터넷에 직접 노출하는 것은 권장되지 않음
다음 보안 설정을 함께 사용하는 것을 권장함
- LANGFLOW_AUTO_LOGIN=False 설정
- 기본값이 아닌 커스텀 LANGFLOW_SECRET_KEY 사용
- 인증이 활성화된 Reverse Proxy 뒤에 LangFlow 서버 배포

2. LangFlow API Keys

LangFlow API Key는 LangFlow를 코드나 외부 애플리케이션에서 프로그래밍 방식으로 사용하기 위해 사용됩니다.

LangFlow API Key를 사용하면 LangFlow 서버와 API를 통해 상호작용할 수 있습니다.
기본적으로 LangFlow의 대부분 API 엔드포인트는 LangFlow API Key 인증이 필요합니다.
- 예: /api/v1/run/{FLOW_ID}
LangFlow API Key는 다음과 같은 서버 측 작업을 승인합니다.
- Flow 실행
- 파일 업로드
- 기타 LangFlow API 호출

※ LangFlow MCP 서버의 인증 설정에 대해서는 Use Langflow as an MCP server 문서(https://docs.langflow.org/mcp-server) 를 참고합니다.

3. API Key 권한

기본 동작 방식

LangFlow API Key는 생성한 사용자의 권한을 그대로 상속합니다.
즉, API Key는 별도의 권한을 가지지 않으며,
API Key를 만든 사용자와 동일한 권한과 접근 범위를 가집니다.

API Key로 접근 가능한 범위는 다음을 포함합니다.

본인이 생성한 Flow
사용 가능한 컴포넌트
LangFlow 데이터베이스 리소스

단, LangFlow API Key는 자신의 LangFlow 서버 외부 리소스에는 접근할 수 없습니다.

환경별 권한 동작 차이

① 싱글 유저 환경 (Single-user)

서버 사용자는 항상 슈퍼유저(superuser) 로 동작
생성한 LangFlow API Key 역시 항상 슈퍼유저 권한을 가짐

② 멀티 유저 환경 (Multi-user)

슈퍼유저가 아닌 사용자는
- 다른 사용자의 리소스에 접근할 수 없음
사용자 관리 및 일반 사용자 계정을 사용하려면
- LangFlow 서버를 authentication enabled 상태로 실행해야 함

4. LangFlow API Key 생성 방법

LangFlow API Key는 다음 두 가지 방법으로 생성할 수 있습니다.

LangFlow Settings(UI)
LangFlow CLI

4.1 LangFlow Settings에서 생성

LangFlow 프론트엔드(UI)가 실행 중인 경우 사용할 수 있는 방법입니다.

생성 절차

1. LangFlow 상단 헤더에서 프로필 아이콘 클릭

2. Settings 선택

3. LangFlow API Keys 클릭

4. Add New 클릭

5. API Key 이름 입력

6. Create API Key 클릭

7. 생성된 API Key를 복사하여 안전하게 저장

⚠️ API Key는 생성 직후에만 전체 값을 확인할 수 있으므로 반드시 저장해야 합니다.

4.2 LangFlow CLI에서 생성

LangFlow 서버가 --backend-only=true 모드로 실행 중인 경우에는

프론트엔드가 없기 때문에 Settings UI에서 API Key를 생성할 수 없습니다.

이 경우 LangFlow CLI를 사용해야 합니다.

CLI 생성이 필요한 경우

LangFlow 서버가 --backend-only=true 모드로 실행 중인 경우
프론트엔드(UI)가 실행되지 않는 환경

API Key 생성 명령어

uv run langflow api-key

4.3 인증 활성화 권장 사항 (추천)

LangFlow 팀은 보안상의 이유로 인증을 활성화한 상태로 서버를 실행할 것을 권장합니다.

인증이 활성화된 경우
- 무단 API Key 생성 방지 가능
- 슈퍼유저 계정 관리 가능
인증이 비활성화된 경우
- 모든 사용자가 사실상 슈퍼유저
- 누구나 CLI를 통해 API Key 생성 가능
(LANGFLOW_AUTO_LOGIN=True)

특히 운영(Production) 환경에서는 인증 활성화가 권장됩니다.

4.4 CLI로 생성된 API Key의 권한

LangFlow CLI로 생성된 API Key는 항상 슈퍼유저 권한을 가짐
이유:
- langflow api-key 명령은 슈퍼유저 인증을 필요로 함
- LangFlow API Key는 생성한 사용자의 권한을 그대로 상속함

5. LangFlow API Key 사용 방법

LangFlow API 요청 시 인증을 위해

LangFlow API Key를 헤더 또는 쿼리 파라미터로 전달해야 합니다.

5.1 HTTP Header 방식 (권장)

curl -X POST \\
  "http://$LANGFLOW_SERVER_ADDRESS/api/v1/run/$FLOW_ID?stream=false" \\
  -H "Content-Type: application/json" \\
  -H "x-api-key: $LANGFLOW_API_KEY" \\
  -d '{"inputs": {"text":""}, "tweaks": {}}'

x-api-key 헤더에 LangFlow API Key 전달
공식 문서에서 기본 예제로 사용하는 방식

5.2 Query Parameter 방식 (대안)

curl -X POST \\
  "http://$LANGFLOW_SERVER_ADDRESS/api/v1/run/$FLOW_ID?x-api-key=$LANGFLOW_API_KEY" \\
  -H "Content-Type: application/json" \\
  -d '{"inputs": {"text":""}, "tweaks": {}}'

URL 쿼리 파라미터로 API Key 전달
헤더 사용이 어려운 경우의 대안

6. API Key 사용 기록(Tracking)

기본적으로 LangFlow는 API Key 사용 정보를 DB에 기록함
- total_uses
- last_used_at

사용 기록 비활성화

LANGFLOW_DISABLE_TRACK_APIKEY_USAGE=True

높은 동시성 환경에서
- DB 경합(Database contention)을 줄이기 위한 용도

7. LangFlow API Key 삭제(Revoke)

API Key를 삭제하면 즉시 무효화됩니다.

삭제 절차

1. LangFlow 상단 헤더 → 프로필 아이콘 클릭

2. Settings

3. LangFlow API Keys

4. 삭제할 Key 선택

5. Delete(쓰레기통 아이콘) 클릭

8. Component API Keys

개념

Component API Key는
- Flow 내 컴포넌트가 호출하는 외부 서비스 인증용 키
LangFlow API Key와는 완전히 별개

사용 예

LLM 모델 제공자 (OpenAI, Gemini 등)
데이터베이스
서드파티 API

관리 방식

Component API Key는
- 서비스 제공자 플랫폼에서 직접 생성·관리
LangFlow는
- 암호화된 키 값 또는
- 외부 저장소의 안전한 참조만 저장

⚠️ LangFlow에서 변수를 삭제해도

→ 실제 서비스 제공자의 API Key는 삭제되지 않음

→ 반드시 제공자 측에서 직접 삭제 또는 회전 필요

보안 옵션

LANGFLOW_REMOVE_API_KEYS=True

Flow 데이터 DB에서
- API Key / Token 제거
Flow JSON Export 시
- API Key 제외 가능

9. Authentication Environment Variables

LangFlow 인증 동작을 제어하는 환경 변수들입니다.

.env.example 파일을 템플릿으로 사용 가능

9.1 LANGFLOW_AUTO_LOGIN

LangFlow 서버 접근 시 인증 요구 여부를 제어합니다.

LANGFLOW_AUTO_LOGIN=False

자동 로그인 비활성화
요구 사항
- 시각적 에디터 로그인 필요
- CLI 일부 명령은 슈퍼유저 인증 필요
- API 요청 시 LangFlow API Key 필요
권장 설정
- LANGFLOW_SUPERUSER
- LANGFLOW_SUPERUSER_PASSWORD 명시적 설정

LANGFLOW_AUTO_LOGIN=True (기본값)

시각적 에디터가 비밀번호 없이 슈퍼유저로 자동 로그인
모든 사용자가 슈퍼유저로 동작
CLI 명령 슈퍼유저 권한으로 실행 가능
API 요청은 여전히 LangFlow API Key 필요

→ 운영 환경에서는 권장되지 않음

10. 기본 인증 정책 및 버전별 변화

LangFlow v1.6 기준

기본값
- LANGFLOW_AUTO_LOGIN=True
- LANGFLOW_SKIP_AUTH_AUTO_LOGIN=False
API 요청에 대해서만 인증 강제

이전 버전 호환성

v1.5
- API 인증 강제 도입
- 하위 호환을 위해 LANGFLOW_SKIP_AUTH_AUTO_LOGIN 추가
v1.5 이전
- API 요청 인증 없음
- 모든 사용자가 슈퍼유저

⚠️ 향후 버전에서는

LANGFLOW_AUTO_LOGIN=False 기본값 예정
LANGFLOW_SKIP_AUTH_AUTO_LOGIN 제거 예정

11. 인증 및 슈퍼유저 관련 환경 변수

11.1 LANGFLOW_ENABLE_SUPERUSER_CLI

LangFlow CLI에서 langflow superuser 명령 사용 가능 여부를 제어
기본값: True
보안상 권장값: False

의미

True일 경우:
- 누구든지 CLI를 통해 슈퍼유저 계정 생성 가능
False일 경우:
- 무제한 슈퍼유저 생성 방지

**12. CORS 설정 (LANGFLOW_CORS_*)**

CORS(Cross-Origin Resource Sharing) 설정은

LangFlow 프론트엔드와 백엔드가 서로 다른 Origin에서 제공될 때,

인증 정보(쿠키, 인증 헤더 등)를 어떻게 처리할지 제어합니다.

12.1 CORS 관련 환경 변수

변수 기본값 설명

LANGFLOW_CORS_ALLOW_CREDENTIALS	True	쿠키, Authorization 헤더 등 인증 정보 허용 여부
LANGFLOW_CORS_ALLOW_HEADERS	*	허용할 HTTP 헤더 목록
LANGFLOW_CORS_ALLOW_METHODS	*	허용할 HTTP 메서드 목록
LANGFLOW_CORS_ORIGINS	*	허용할 Origin 목록

12.2 기본 CORS 설정 (Default)

기본 설정은 모든 Origin, Header, Method를 허용합니다.

LANGFLOW_CORS_ORIGINS=*
LANGFLOW_CORS_ALLOW_CREDENTIALS=True
LANGFLOW_CORS_ALLOW_HEADERS=*
LANGFLOW_CORS_ALLOW_METHODS=*

⚠️ 보안 주의 사항

기본 CORS 설정은 운영 환경에서 보안 위험이 될 수 있음
어떤 웹사이트든 LangFlow API 호출 가능
인증 쿠키 및 Authorization 헤더도 포함 가능

12.3 운영 환경 권장 CORS 설정 예시

운영 환경에서는 명시적인 Origin만 허용하는 것이 권장됩니다.

LANGFLOW_CORS_ORIGINS=https://yourdomain.com,<https://app.yourdomain.com>
LANGFLOW_CORS_ALLOW_CREDENTIALS=True
LANGFLOW_CORS_ALLOW_HEADERS=Content-Type,Authorization
LANGFLOW_CORS_ALLOW_METHODS=GET,POST,PUT

13. 인증이 활성화된 LangFlow 서버 실행

이 설정은 다음과 같은 환경에 권장됩니다.

LangFlow가 공용 또는 공유 네트워크에 노출되는 경우
여러 사용자가 하나의 LangFlow 서버를 사용하는 경우

13.1 인증 활성화 시 동작

모든 사용자는 시각적 에디터 로그인 필요
API 요청은 LangFlow API Key 인증 필수
사용자 관리 및 슈퍼유저 작업은 슈퍼유저 로그인 필요

13.2 .env 파일 설정 예시

LANGFLOW_AUTO_LOGIN=False
LANGFLOW_SUPERUSER=administrator
LANGFLOW_SUPERUSER_PASSWORD=securepassword
LANGFLOW_SECRET_KEY=dBuu...2kM2_fb
LANGFLOW_NEW_USER_IS_ACTIVE=False
LANGFLOW_ENABLE_SUPERUSER_CLI=False

예시는 인증 관련 변수만 포함
실제 환경에서는 강력한 자격 증명 사용 권장

13.3 LangFlow 서버 실행

uv run langflow run --env-file .env

.env 파일에 정의된 설정으로 LangFlow 실행
실행 시 자동으로 슈퍼유저로 인증됨

13.4 서버 실행 확인

기본 접속 주소
<http://localhost:7860>

14. 사용자 관리 (관리자 / 슈퍼유저)

14.1 슈퍼유저 최초 로그인

접속 주소
<http://localhost:7860/login>
.env에 설정한 슈퍼유저 계정으로 로그인

14.2 관리자 페이지 접근

주소 예시
<http://localhost:7860/admin>
또는 프로필 아이콘 → Admin Page

14.3 사용자 관리 기능

슈퍼유저는 다음 작업을 수행할 수 있습니다.

사용자 추가
권한 설정
비밀번호 재설정
계정 삭제

14.4 사용자 추가 절차

New User 클릭
사용자 정보 입력
- Username
- Password
계정 활성화 여부 설정
- Active 체크 시 즉시 로그인 가능
슈퍼유저 권한 여부 설정
Save 클릭

14.5 권한 확인

일반 사용자는 /admin 접근 불가
접근 시 /flows 페이지로 리다이렉트됨

[Langflow] OpenAI API key 생성

말하는 알감자 — Tue, 16 Dec 2025 15:35:58 +0900

LLM 지원 목록 정리

LangFlow 기본 지원 LLM Provider
- OpenAI (GPT 계열)
- Google Gemini
- Anthropic (Claude)
- Groq
- Azure OpenAI
- Hugging Face Inference API
기타 LLM 연결 방식
- Connect other models 옵션 제공
- 기본 Provider 목록에 없는 모델 직접 연결 가능
- 자체 호스팅 LLM 서버 연동 가능
- 사내 전용(private) LLM 연동 가능
- 커스텀 REST API 형태의 LLM 연결 가능
LLM 외 연계 가능 요소
- Agent Tool로 외부 API 사용 가능
- MCP(Model Context Protocol) 서버 연결 가능
- LangFlow 자체를 MCP 서버로 사용 가능

따라서 Langflow는

→ LangFlow는 특정 LLM에 종속되지 않음

→ OpenAI는 여러 선택지 중 하나임

→ 모델 선택 및 교체가 자유로운 구조

OpenAI API key 생성 방법

1. OpenAI API Keys 페이지 접속

https://platform.openai.com/api-keys 에 접속합니다.

이미 계정이 있다면 로그인, 계정이 없다면 회원가입을 진행합니다.

2. API Keys 메뉴 이동

로그인 후 좌측 메뉴에서 API Keys 페이지로 이동합니다.

3. 새 API Key 생성

Create new secret key 버튼을 선택합니다.

키 생성 팝업이 표시됩니다.

테스트 목적이라면 기본 설정 그대로 생성해도 됩니다.

4. API Key 복사 및 보관 ⭐️

생성된 API Key는 이 시점에만 전체 문자열을 확인할 수 있습니다.
화면을 닫으면 다시 전체 키를 확인할 수 없습니다.

따라서 반드시 다음을 수행해야 합니다.

생성 직후 복사
안전한 장소에 즉시 저장

⚠️ 이미 생성된 키의 전체 값을 다시 확인하는 공식적인 방법은 없습니다.

(공식 콘솔에서는 재노출 기능을 제공하지 않습니다)

5. API Key 관리 (이름 및 권한)

생성된 API Key 목록에서 수정(연필) 아이콘을 통해 다음 작업이 가능합니다.

Key 이름(Name) 변경
권한(Permissions) 수정
- 사용 가능한 API 범위 제한 가능

※ 키 자체의 값(secret)은 변경할 수 없으며, 필요 시 기존 키를 삭제하고 새 키를 생성해야 합니다.

6. 보안 관련 공식 권장 사항

OpenAI 공식 문서 기준 권장 사항은 다음과 같습니다.

API Key를 소스 코드에 직접 하드코딩하지 말 것
.env 파일 또는 환경 변수로 관리
GitHub 등 공개 저장소에 절대 커밋하지 말 것
유출이 의심되면 즉시 키 삭제 후 재발급

7. LangFlow에서 사용 시 참고 사항

LangFlow Quickstart에서는:
- OpenAI API Key를 Agent 컴포넌트에 직접 입력하거나
- Global Variable / 환경 변수로 사용 가능
OpenAI API Key는 LangFlow 내부에 저장되지 않으며, Flow 실행 시 모델 호출에만 사용됩니다.

[Langflow] Lanflow 설치하기

말하는 알감자 — Tue, 16 Dec 2025 11:36:16 +0900

1. LangFlow란?

LangFlow는 오픈소스, Python 기반의 AI 애플리케이션 구축 프레임워크입니다.

다음과 같은 특징을 공식적으로 지원합니다.

특정 LLM에 종속되지 않음
특정 Vector Store에 종속되지 않음
Agent 기능 지원
MCP(Model Context Protocol) 지원
시각적 에디터 기반 워크플로우 설계

1.1 LangFlow의 핵심 목적

AI 애플리케이션의 워크플로우를 빠르게 설계
복잡한 로직을 시각적으로 구성
실시간 테스트를 통해 빠른 프로토타이핑
완성된 Flow를 API 또는 서버 형태로 제공

1.2 주요 개념 정리

① Flow

하나의 AI 애플리케이션 워크플로우
여러 컴포넌트(Component)로 구성
LangFlow의 가장 핵심적인 단위

② Component

워크플로우의 단일 처리 단계
노드(Node) 형태로 연결됨

대표적인 컴포넌트 예시

Input / Output
Prompt
LLM
Agent
Tool
Vector Store
Embedding Provider

각 컴포넌트는 설정 가능한 파라미터를 가짐

1.3 시각적 에디터

LangFlow는 Drag & Drop 방식의 시각적 에디터를 제공합니다.

가능한 작업:

① 컴포넌트 선택

② 노드 연결

③ 파라미터 설정

④ 즉시 실행 및 테스트

이를 통해 코드 작성 없이도 워크플로우 구조를 빠르게 확인 가능

1.4 실시간 테스트 (Playground)

LangFlow는 Playground 기능을 제공합니다.

Playground에서 가능한 작업:

전체 Flow 실행 테스트
개별 컴포넌트 단독 실행
의존성 문제를 단계별로 검증

→ 전체 애플리케이션을 만들기 전에 로직 검증 가능

1.5 Flow 실행 및 활용 방식

LangFlow에서 만든 Flow는 다음 방식으로 활용할 수 있습니다.

① 프로토타입 용도

아이디어 검증
로직 테스트

② API 연동

LangFlow API를 통해 Flow 호출
외부 애플리케이션에 임베드 가능

③ 서버 배포

LangFlow 서버 실행
퍼블릭 인터넷 제공 가능
Docker 컨테이너 배포 지원

1.6 컴포넌트 확장성

LangFlow는 기본 컴포넌트 외에도 확장을 지원합니다.

외부에서 만든 커스텀 컴포넌트 사용 가능
Python으로 직접 커스텀 컴포넌트 개발 가능
개인용 또는 공유용 컴포넌트 제작 가능

1.7 Agent 및 MCP 지원

LangFlow는 공식적으로 다음 기능을 지원합니다.

LangFlow Agent 사용
Flow를 Agent Tool로 사용
LangFlow를 MCP 서버로 사용
LangFlow를 MCP 클라이언트로 사용

→ Agent 중심 AI 애플리케이션 구축 가능

1.8 활용 가능한 AI 애플리케이션 예시

공식 문서 기준으로 LangFlow는 다음과 같은 애플리케이션에 활용 가능합니다.

챗봇
문서 분석 시스템
콘텐츠 생성기
Agent 기반 애플리케이션

2. LangFlow 설치 방법

LangFlow는 총 4가지 방식으로 설치할 수 있습니다.

설치 방식에 따라 목적과 사용 환경이 다릅니다.

자세한 설치 방법이 궁금하다면 다음 링크를 참조해주세요

https://docs.langflow.org/get-started-installation

설치 방식

설치 방식 설명 특징

LangFlow Desktop	데스크톱 앱 형태	가장 간단한 설치
Docker	컨테이너 실행	환경 격리
Python 패키지 (OSS)	Python 라이브러리 설치	환경 제어 가능
소스 코드 설치	GitHub 소스 사용	기여 목적

※ 모든 로컬 설치 방식은 회원가입·로그인 없이 사용 가능

2.1 LangFlow Desktop (권장)

개요

LangFlow를 데스크톱 애플리케이션으로 설치
의존성 관리 및 업그레이드가 자동으로 처리됨
가장 설정이 단순한 방식

특징

일부 기능 미지원
(Shareable Playground, Voice Mode 등)

지원 환경

macOS 13 이상
Windows 지원

설치 절차 (macOS 기준)

1. LangFlow Desktop 페이지 접속 (Langflow 홈페이지 : https://www.langflow.org/)

2. Get Started for Free 클릭

3. 연락처 정보 입력 후 다운로드

company의 경우는 그냥 다니는 대학 검색해서 넣었습니다.

4. 애플리케이션 설치

본인 컴퓨터에 맞는 것으로 골라서 다운로드 받습니다.

저는 맥북 유저니까 macOS(Apple Siicon)을 다운받습니다.

5. LangFlow 실행

continue를 클릭하면 다운로드가 시작됩니다.

설치 완료 후 화면

6. create first flow 클릭

2.2 Docker로 설치

개요

LangFlow를 Docker 컨테이너로 실행
실행 환경을 완전히 분리 가능

특징

회원가입 / 로그인 불필요
서버 및 배포 환경에 적합

설치 및 실행

docker run -p 7860:7860 langflowai/langflow:latest

접속 주소

<http://localhost:7860/>

2.3 LangFlow OSS Python 패키지 설치

개요

Python 환경에 LangFlow를 직접 설치
환경·버전·의존성을 직접 제어 가능

필수 조건

Python 버전
- macOS / Linux: 3.10 ~ 3.13
- Windows: 3.10 ~ 3.12
uv 설치 필요

권장 시스템 사양

최소: Dual-core CPU, RAM 2GB
권장: Multi-core CPU, RAM 4GB 이상

설치

uv pip install langflow

특정 버전 설치:

uv pip install langflow==1.4.22

실행

uv run langflow run

접속 주소

<http://127.0.0.1:7860>

2.4 소스 코드에서 설치

개요

LangFlow GitHub 소스를 직접 사용
LangFlow 코드 또는 문서에 기여하기 위한 방식

특징

일반 사용 목적에는 권장되지 않음
개발자 및 기여자 대상

설치 방식 선택 정리

처음 사용 → LangFlow Desktop
서버·배포 환경 → Docker
개발·커스터마이징 → Python 패키지
기여 목적 → 소스 코드 설치

[Dify] Dify 내장 도구 소개

말하는 알감자 — Mon, 15 Dec 2025 10:55:08 +0900

Dify에는 검색, 번역, 데이터 변환, 음성 처리 등 다양한 기능을 수행할 수 있는 도구들이 연동되어 있습니다.

AI 에이전트나 챗봇을 만들 때 이러한 도구들을 함께 사용하면, 단순한 대화 응답을 넘어 실제 작업을 수행하는 애플리케이션을 만들 수 있습니다.

이번에는 실무에서 자주 활용되는 Dify 도구들을 살펴보겠습니다.

1. Dify 상단 메뉴에서 도구를 클릭합니다.

도구 화면에서는 다음과 같은 항목들을 확인할 수 있습니다.

내장
: Dify에 기본으로 포함되어 있거나 사용자가 설치한 도구들을 확인할 수 있습니다.
커스텀
: 사용자가 직접 정의한 커스텀 도구들을 확인할 수 있습니다.
워크플로우
: Dify 워크플로우를 도구 형태로 만들어 재사용할 수 있습니다.
Marketplace
: Dify와 연동 가능한 다양한 외부 솔루션 도구들을 검색하고 설치할 수 있습니다.

2. CurrentTime

CurrentTime은 현재 시간 정보를 가져오는 도구입니다.

현재 시각 조회뿐 아니라, 특정 시간대를 다른 시간대로 변환하거나 특정 날짜가 무슨 요일인지 계산하는 기능도 제공합니다.

시간 계산이 필요한 자동화 시나리오에서 유용하게 사용할 수 있습니다.

3. Code Interpreter

Code Interpreter는 코드를 실행하고 그 결과를 반환해주는 도구입니다.

LLM에게 코드를 작성하도록 요청한 뒤, 해당 코드를 실제로 실행하고 결과를 확인할 때 사용합니다.

간단한 계산, 데이터 처리, 파일 변환 작업 등에 활용할 수 있습니다.

4. DALL-E

DALL-E는 OpenAI에서 개발한 이미지 생성 AI 도구로, 텍스트 프롬프트를 기반으로 이미지를 생성합니다.

Dify에서 사용하려면 외부 솔루션 플러그인을 설치해야 하며, OpenAI API 키 설정이 필요합니다.

이미지 생성이 필요한 챗봇이나 콘텐츠 제작 자동화에 활용할 수 있습니다.

OpenAI API 키 설정

5. Tavily

Tavily는 웹사이트에서 필요한 정보를 검색하고, 웹페이지의 내용을 구조화된 형태로 가져오는 AI 검색 도구입니다.

실시간 웹 검색과 요약에 강점이 있으며, 사용을 위해서는 플러그인 설치와 Tavily API 키 입력이 필요합니다.

API 키는 https://app.tavily.com/home 에서 회원가입 후 발급받을 수 있습니다.

6. Wikipedia

Wikipedia 도구는 위키백과를 검색하여 필요한 정보를 가져오는 도구입니다.

위키 문서에서 핵심 내용을 추출해 응답에 활용할 수 있어, 일반 지식 기반 질의응답에 적합합니다.

7. ArXiv

ArXiv는 과학 논문 저장소인 arXiv에서 연구 논문을 검색할 수 있는 도구입니다.

AI 애플리케이션에서 학술 자료, 연구 동향, 논문 정보를 검색하고 활용할 수 있습니다.

8. SearchApi

SearchApi는 구글 검색, 구글 채용 정보, 유튜브, 구글 뉴스 등 다양한 검색 서비스를 하나의 API로 제공하는 도구입니다.

실시간 검색 결과를 구조화된 데이터 형태로 받아볼 수 있어 정보 수집 자동화에 유용합니다.

9. Firecrawl

Firecrawl은 웹사이트의 내용을 자동으로 수집하고 정리해주는 웹 크롤링 도구입니다.

웹페이지 주소를 입력하면 해당 사이트의 텍스트와 구조화된 콘텐츠를 추출합니다.

API 키는 https://www.firecrawl.dev/ 에서 회원가입 후 발급받을 수 있습니다.

10. AntV Visualization Chart

AntV Visualization Chart는 데이터를 시각화하여 표현하는 도구입니다.

막대 그래프, 선 그래프, 원 그래프 등 다양한 차트를 생성할 수 있어, 데이터 분석 결과를 직관적으로 전달할 때 유용합니다.

11. Mistral OCR

Mistral OCR은 PDF나 이미지 파일에 포함된 텍스트를 추출하는 도구입니다.

문서의 레이아웃과 구조를 최대한 유지하면서 글자를 인식하여 텍스트로 변환합니다.

API 키는 https://console.mistral.ai/api-keys 에서 회원가입 후 발급받을 수 있습니다.