os_js.log

파일 무결성 검사

Tue, 14 Jul 2026 01:19:53 GMT

Agent에서 사용하는 파일 무결성 검증 방식

Agent에서 맵 파일을 배포할 때는 파일을 다운로드한 뒤 무결성 검증을 수행한다.

여기서 무결성 검증이란 Agent가 다운로드한 파일이 서버에서 전달한 원본과 동일한지 확인하는 과정이다.

파일이 네트워크를 통해 전송되는 동안 일부 데이터가 손상되거나 잘못된 파일이 전달되면, 이후 압축 해제나 맵 로드 과정에서 문제가 발생할 수 있다.

이를 방지하기 위해 Agent는 파일을 다운로드한 직후 무결성을 확인한다. 검증에 실패하면 압축 해제나 맵 적용 단계로 넘어가지 않고 배포를 중단한다.

맵 파일 다운로드
        ↓
파일 무결성 검증
        ↓
검증 성공 여부 확인
   ┌────┴────┐
   │         │
 성공       실패
   │         │
압축 해제   배포 중단
   │
맵 로드

파일 무결성을 확인하는 방법

파일 무결성을 확인하는 방법에는 여러 가지가 있다.

대표적으로 다음과 같은 방식을 생각해볼 수 있다.

CRC32와 같은 단순 체크섬
BLAKE3와 같은 암호학적 해시
Merkle Tree 기반 검증

각 방식은 검증 목적과 파일 전달 구조에 따라 장단점이 다르다.

단순 체크섬

체크섬은 파일 내용을 바탕으로 짧은 검증 값을 계산하는 방식이다.

서버가 원본 파일의 체크섬을 미리 계산하고, Agent가 파일을 다운로드한 뒤 같은 방식으로 다시 체크섬을 계산한다.

서버의 체크섬 값
        ↕ 비교
Agent가 계산한 체크섬 값

두 값이 같으면 파일이 정상적으로 전달된 것으로 판단하고, 값이 다르면 전송 과정에서 파일이 손상되었거나 다른 파일이 전달된 것으로 판단한다.

CRC32와 같은 단순 체크섬은 계산 속도가 빠르고 구현이 간단하다. 따라서 네트워크 전송 중 발생할 수 있는 우발적인 데이터 손상을 확인하는 용도로 널리 사용된다.

하지만 파일 동일성을 더 강하게 확인해야 하는 상황에서는 한계가 있다.

단순 체크섬은 충돌 가능성이 상대적으로 높고, 의도적으로 변경된 파일을 검증하는 용도로 설계된 방식도 아니다.

따라서 중요한 배포 파일을 검증할 때는 일반적으로 암호학적 해시를 사용하는 것이 더 적합하다.

BLAKE3

BLAKE3는 파일 내용을 기반으로 고정된 길이의 해시 값을 계산하는 암호학적 해시 함수다.

파일 내용이 아주 조금만 달라져도 이전과 전혀 다른 해시 값이 생성된다.

예를 들어 파일에서 한 바이트만 변경되더라도 계산 결과는 크게 달라진다.

원본 파일
→ 7b4c...

일부가 변경된 파일
→ a19f...

서버와 Agent가 같은 파일을 대상으로 BLAKE3 해시를 계산했을 때 결과가 같다면, 두 파일의 내용이 동일하다고 판단할 수 있다.

BLAKE3의 주요 장점은 다음과 같다.

대용량 파일에서도 빠르게 계산할 수 있다.
파일 내용 변경에 민감하다.
병렬 처리를 고려해 설계되었다.
단순 체크섬보다 충돌 가능성이 매우 낮다.
전체 파일 동일성 검증에 적합하다.

즉, BLAKE3는 파일 검증의 정확성을 유지하면서도 처리 시간을 줄이기 좋은 방식이다.

Merkle Tree

Merkle Tree는 파일 전체를 하나의 값으로만 검증하지 않고, 파일을 여러 개의 블록으로 나눠 각각의 해시를 계산하는 방식이다.

각 블록의 해시는 다시 상위 해시로 결합되고, 최종적으로 하나의 Root Hash가 만들어진다.

             Root Hash
            /         \
       Hash A         Hash B
       /   \           /   \
  Block 1 Block 2  Block 3 Block 4

Merkle Tree의 가장 큰 장점은 부분 검증이 가능하다는 것이다.

예를 들어 대용량 파일의 일부만 변경되었거나 손상된 경우, 전체 파일을 다시 비교하지 않고 문제가 있는 블록만 찾아낼 수 있다.

다음과 같은 환경에서는 Merkle Tree가 유리하다.

파일 일부만 다시 다운로드하는 구조
블록 또는 Chunk 단위 데이터 검증
여러 노드에 데이터가 분산된 저장소
데이터 일부를 병렬로 검증하는 구조
변경된 부분만 동기화하는 시스템

하지만 Merkle Tree를 사용하려면 파일 분할 기준, 블록별 해시, 트리 구성 정보 등을 별도로 관리해야 한다.

전체 파일을 한 번에 다운로드한 뒤 정상 여부만 확인하는 구조라면, 이러한 복잡도에 비해 얻을 수 있는 이점이 크지 않을 수 있다.

현재 Agent에서 사용하는 방식

현재 Agent는 맵 파일의 무결성을 확인하기 위해 BLAKE3 기반 해시 검증을 사용한다.

검증 흐름은 다음과 같다.

1. 서버가 원본 맵 파일의 BLAKE3 해시를 계산한다.
2. Agent가 맵 파일과 해시 값을 전달받는다.
3. Agent가 다운로드한 파일의 BLAKE3 해시를 계산한다.
4. 서버에서 받은 해시와 Agent가 계산한 해시를 비교한다.
5. 값이 다르면 배포를 중단한다.
6. 값이 같으면 압축 해제와 맵 로드를 진행한다.

검증은 압축 파일을 해제하기 전에 수행한다.

파일 다운로드
      ↓
BLAKE3 해시 계산
      ↓
서버 해시와 비교
      ↓
   일치 여부
   ┌──┴──┐
   │     │
 일치   불일치
   │     │
압축 해제 배포 실패
   │
맵 로드

파일이 손상되었거나 원본과 다른 경우에는 후속 작업을 실행하지 않는다.

이를 통해 잘못된 파일이 실제 배포 경로로 진입하는 것을 방지할 수 있다.

단순 체크섬을 사용하지 않은 이유

CRC32와 같은 단순 체크섬은 빠르고 구현하기 쉽다.

하지만 현재 Agent가 검증하는 파일은 단순한 로그나 임시 데이터가 아니다. 실제 Robot의 맵 배포에 사용되는 중요한 파일이다.

맵 파일에 문제가 생기면 단순히 압축 해제에 실패하는 것으로 끝나지 않을 수 있다.

잘못된 맵이 로드될 수 있다.
기존 맵과 다른 데이터가 적용될 수 있다.
Robot의 위치 추정이나 주행에 영향을 줄 수 있다.
배포된 장비마다 서로 다른 파일이 적용될 수 있다.

따라서 단순히 전송 과정에서 데이터가 깨졌는지를 확인하는 것보다, Agent가 받은 파일이 서버의 원본과 동일한지를 확인하는 것이 중요하다.

BLAKE3는 단순 체크섬보다 강한 동일성 검증을 제공하면서도 대용량 파일을 빠르게 처리할 수 있다.

이러한 이유로 현재 배포 구조에서는 속도와 검증 신뢰성 사이의 균형이 좋은 선택이라고 판단했다.

Merkle Tree를 사용하지 않은 이유

Merkle Tree는 부분 검증과 Chunk 단위 동기화에 강한 방식이다.

하지만 현재 Agent의 파일 배포 구조에서는 파일 일부만 다운로드하거나 변경된 블록만 다시 전송하지 않는다.

서버에서 하나의 배포 파일을 다운로드한 뒤, 파일 전체가 정상인지 확인하고 다음 단계로 넘어간다.

현재 Agent에 필요한 검증은 다음과 같다.

다운로드한 전체 파일이 서버의 원본과 같은가?

반면 Merkle Tree는 다음과 같은 요구사항에서 더 큰 장점을 가진다.

파일의 어느 부분이 변경되었는가?
어떤 Chunk만 다시 다운로드해야 하는가?
일부 데이터만 빠르게 검증할 수 있는가?

현재 구조에 Merkle Tree를 적용하면 블록별 해시와 트리 데이터를 추가로 관리해야 하지만, 실제 배포 과정에서 얻는 이점은 제한적이다.

따라서 Agent에서는 더 단순하고 관리하기 쉬운 BLAKE3 기반 전체 파일 검증을 선택했다.

BLAKE3만으로 모든 보안 문제가 해결되는가

BLAKE3 해시가 일치하면 Agent가 받은 파일의 내용이 서버에서 계산한 파일과 동일하다는 것을 확인할 수 있다.

다만 해시 값과 파일이 모두 신뢰할 수 없는 경로를 통해 함께 전달된다면, 공격자가 파일과 해시를 동시에 바꾸는 상황까지 막을 수는 없다.

파일만 변경
→ 해시 비교로 감지 가능

파일과 해시를 함께 변경
→ 별도의 신뢰 수단이 필요

악의적인 파일 교체까지 방지해야 한다면 다음과 같은 방법을 추가로 고려할 수 있다.

HTTPS 또는 TLS를 통한 전송 구간 보호
HMAC을 이용한 해시 인증
전자서명을 이용한 배포 파일 검증
신뢰할 수 있는 별도 경로로 해시 전달

현재 BLAKE3 검증의 주된 목적은 다운로드 과정에서 발생한 손상이나 잘못된 파일 전달을 확인하는 것이다.

향후 배포 파일의 출처까지 검증해야 한다면 전자서명이나 HMAC 기반 검증을 추가할 수 있다.

정리

파일 무결성을 확인하는 대표적인 방식으로는 단순 체크섬, BLAKE3, Merkle Tree가 있다.

단순 체크섬은 빠르고 구현하기 쉽지만, 주로 우발적인 데이터 손상을 감지하는 데 적합하다.

Merkle Tree는 파일을 여러 블록으로 나눠 부분적으로 검증할 수 있다는 장점이 있지만, 전체 파일을 하나의 단위로 배포하는 현재 구조에서는 복잡도가 높다.

현재 Agent는 맵 파일을 하나의 배포 단위로 다운로드한 뒤, 서버가 전달한 원본과 동일한지만 확인하면 된다.

따라서 Agent에서는 다음과 같은 이유로 BLAKE3를 사용한다.

대용량 파일을 빠르게 처리할 수 있다.
파일의 작은 변경도 감지할 수 있다.
단순 체크섬보다 강한 동일성 검증이 가능하다.
Merkle Tree보다 구현과 운영이 단순하다.
현재의 전체 파일 배포 방식과 잘 맞는다.

결국 현재 Agent의 무결성 검증은 복잡한 검증 시스템을 구축하기 위한 것이 아니다.

배포 과정에서 가장 중요한 다음 질문에 빠르고 정확하게 답하기 위한 방식이다.

Agent가 다운로드한 파일은 서버가 전달한 원본 파일과 동일한가?

테스트..

merkle tree는 애초에 우리가 사용하고 있던 방식과 다르기 때문에 테스트를 진행하지 않았다.
이후 더욱 고도화를 위한 방식으로는 생각해볼 수 있다.

zenoh 사용(nestjs)

Mon, 13 Jul 2026 05:39:36 GMT

NestJS에서 Zenoh Remote API와 WebSocket으로 통신하는 방식

현재 NestJS 서버는 Zenoh 네트워크와 통신하기 위해 zenoh-plugin-remote-api를 사용한다.

여기서 중요한 점은 NestJS가 Zenoh Router의 Native WebSocket Listener에 직접 연결되는 것이 아니라, Remote API가 제공하는 WebSocket Endpoint에 연결한다는 것이다.

전체적인 구조는 다음과 같다.

NestJS
  │
  │ WebSocket
  ▼
zenoh-plugin-remote-api
  │
  ▼
Zenoh Router
  │
  ▼
Robot / Edge Device

NestJS에서는 @eclipse-zenoh/zenoh-ts 패키지를 사용해 Zenoh Session을 생성한다.

코드상으로는 NestJS가 Zenoh Session을 직접 사용하는 것처럼 보이지만, 내부적으로는 Remote API Endpoint와 WebSocket 연결을 생성하고 그 연결을 통해 Zenoh 요청과 메시지를 주고받는다.

왜 WebSocket을 사용하는가

@eclipse-zenoh/zenoh-ts는 Node.js와 TypeScript 환경에서 Zenoh를 사용하기 위한 클라이언트 라이브러리다.

현재 프로젝트에서는 이 클라이언트가 zenoh-plugin-remote-api의 WebSocket Endpoint에 연결하는 방식으로 Zenoh를 사용한다.

따라서 NestJS 코드에서 Session.open()을 호출하면 내부적으로 다음과 같은 과정이 진행된다.

Session.open()
  │
  ▼
Remote API WebSocket 연결 생성
  │
  ▼
Zenoh Session 생성
  │
  ▼
Zenoh 기능 사용 가능

Session이 생성된 이후에는 해당 Session을 통해 다음과 같은 Zenoh 기능을 사용할 수 있다.

Publish
Subscribe
Query
Liveliness

즉, 애플리케이션에서는 Zenoh API를 사용하지만 실제 통신은 Remote API와 연결된 WebSocket 위에서 이루어진다.

NestJS에서는 어떻게 연결하는가

NestJS에서는 RobotZenohService가 Zenoh 연결을 담당한다.

이 서비스는 @eclipse-zenoh/zenoh-ts를 불러오고, 설정된 Remote API 주소를 기반으로 Zenoh Session을 생성한다.

전체적인 초기화 흐름은 다음과 같다.

RobotZenohService 초기화
  │
  ▼
zenoh-ts 로드
  │
  ▼
Remote API WebSocket Endpoint 설정
  │
  ▼
Session.open()
  │
  ▼
Subscriber 등록
  │
  ▼
Robot 메시지 수신 시작

Session.open()이 성공하면 NestJS는 Zenoh Session을 사용할 수 있는 상태가 된다.

이후 해당 Session을 이용해 Robot이 보내는 데이터를 구독하거나 Robot으로 명령을 발행한다.

예를 들어 Robot의 상태 정보를 수신하기 위해 다음과 같은 Key Expression을 구독할 수 있다.

robot/{robotId}/state
robot/{robotId}/navigation/state

서버에서 Robot으로 명령을 전달할 때도 같은 Session을 사용한다.

robot/{robotId}/command/move
robot/{robotId}/command/path

이 토픽들은 실제 프로젝트 토픽이 아니라 통신 구조를 설명하기 위한 예시다.

NestJS 코드에서는 일반적인 Zenoh API를 사용하는 것처럼 보이지만, 실제 메시지는 Remote API와 연결된 WebSocket을 통해 전달된다.

WebSocket 연결 상태를 별도로 감지하는 이유

Remote API 연결은 WebSocket을 기반으로 하기 때문에 네트워크 문제나 Remote API 재시작 등으로 인해 연결이 끊길 수 있다.

일반적으로는 Zenoh Session 상태를 통해 연결 종료를 감지할 수 있다. 하지만 일부 비정상적인 단절 상황에서는 Session 상태만으로 연결 문제를 즉시 확인하기 어려울 수 있다.

이를 보완하기 위해 현재 구조에서는 zenoh-ts 내부에서 사용하는 WebSocket의 close 및 error 이벤트도 함께 감지한다.

Zenoh Session 상태 확인
  │
  ├─ Session 오류 감지
  │
  └─ WebSocket close/error 감지
             │
             ▼
       연결 종료 처리

이처럼 Session과 내부 WebSocket 상태를 함께 확인하면 Remote API 연결이 비정상적으로 종료된 경우에도 NestJS가 빠르게 문제를 감지할 수 있다.

연결이 끊기면 어떻게 처리하는가

Remote API와의 WebSocket 연결이 끊기면 기존 Zenoh 리소스를 정리하고 새로운 연결을 생성한다.

재연결 과정은 다음과 같다.

WebSocket close/error 감지
  │
  ▼
기존 Zenoh Session 종료
  │
  ▼
등록된 Subscriber 정리
  │
  ▼
일정 시간 대기
  │
  ▼
Remote API Endpoint로 재연결
  │
  ▼
Subscriber 재등록

기존 Session과 Subscriber를 먼저 정리하는 이유는 재연결 과정에서 동일한 Subscriber가 중복으로 등록되는 것을 방지하기 위해서다.

Subscriber가 중복으로 등록되면 하나의 메시지가 여러 번 처리되거나 동일한 이벤트가 반복해서 발생할 수 있다.

따라서 재연결 전에는 기존 연결과 관련된 리소스를 확실하게 정리해야 한다.

재연결 간격을 두는 이유

연결이 실패했다고 해서 즉시 무한 반복으로 재연결을 시도하지는 않는다.

Remote API나 Zenoh Router가 재시작 중이라면 짧은 시간 동안 연결할 수 없는 상태가 계속될 수 있다. 이때 반복적으로 연결을 시도하면 불필요한 CPU 및 네트워크 사용이 발생한다.

이를 방지하기 위해 재연결 시도 사이에 대기 시간을 두는 Backoff 방식을 사용한다.

첫 번째 실패
  ↓
짧은 시간 대기

연속 실패
  ↓
대기 시간 증가

연결 성공
  ↓
대기 시간 초기화

처음에는 짧은 간격으로 재연결을 시도하고, 실패가 반복되면 점차 대기 시간을 늘린다.

연결에 성공하면 재연결 횟수와 대기 시간을 초기화하고 정상적인 메시지 구독을 다시 시작한다.

Health Check를 함께 사용하는 이유

WebSocket의 close와 error 이벤트만으로 모든 연결 장애를 감지할 수 있는 것은 아니다.

TCP 또는 WebSocket 연결이 형식적으로는 남아 있지만, 실제로 메시지를 주고받을 수 없는 비정상 상태가 발생할 수 있기 때문이다.

이를 확인하기 위해 NestJS에서는 주기적으로 가벼운 Zenoh 요청을 보내 연결 상태를 검사한다.

주기적으로 Health Check 요청
  │
  ├─ 성공 → 연결 유지
  │
  └─ 실패 → 연결 이상으로 판단
                 │
                 ▼
          Session 정리 및 재연결

Health Check는 WebSocket 이벤트가 발생하지 않은 채 연결이 비정상적으로 멈춰 있는 상황을 감지하기 위한 보조 수단이다.

따라서 현재 구조에서는 다음과 같은 신호를 함께 사용해 연결 상태를 판단한다.

Zenoh Session 오류
WebSocket close 이벤트
WebSocket error 이벤트
Health Check 실패
Publish 또는 Query 실패

여러 감지 방식을 함께 사용하면 네트워크 장애나 Remote API 재시작 상황에 더 안정적으로 대응할 수 있다.

전체 연결 흐름

NestJS와 Zenoh 사이의 전체 연결 흐름을 정리하면 다음과 같다.

┌──────────────────────────┐
│          NestJS          │
│                          │
│  RobotZenohService       │
│  Session / Subscriber    │
└────────────┬─────────────┘
             │
             │ WebSocket
             ▼
┌──────────────────────────┐
│  zenoh-plugin-remote-api │
└────────────┬─────────────┘
             │
             │ Zenoh
             ▼
┌──────────────────────────┐
│       Zenoh Router       │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│   Robot / Edge Device    │
└──────────────────────────┘

NestJS가 직접 Zenoh Router의 Native Transport에 연결되는 것은 아니다.

NestJS는 Remote API가 제공하는 WebSocket Endpoint에 연결하고, Remote API가 NestJS의 요청을 Zenoh 네트워크로 전달한다.

정리

현재 NestJS 서버는 Zenoh와 통신하기 위해 zenoh-plugin-remote-api의 WebSocket Endpoint를 사용한다.

NestJS에서는 @eclipse-zenoh/zenoh-ts를 통해 Session을 생성하며, 생성된 Session으로 Publish, Subscribe, Query 등의 Zenoh 기능을 사용한다.

코드에서는 일반적인 Zenoh API를 사용하는 것처럼 보이지만, 실제 통신은 다음 경로를 거친다.

NestJS
  ↓
Remote API WebSocket
  ↓
Zenoh Router
  ↓
Robot / Edge Device

또한 WebSocket 연결은 네트워크 문제나 Remote API 재시작으로 끊길 수 있기 때문에 다음과 같은 연결 감지 및 복구 기능을 함께 사용한다.

Zenoh Session 오류 감지
내부 WebSocket의 close 및 error 이벤트 감지
주기적인 Health Check
기존 Session과 Subscriber 정리
Backoff 기반 자동 재연결
재연결 이후 Subscriber 재등록

이 구조의 핵심은 NestJS가 Zenoh Router에 직접 연결되는 것이 아니라, Remote API의 WebSocket 연결을 통해 Zenoh 네트워크에 접근한다는 점이다.

번외..

zenoh remote api websocket연결 이벤트 핸들러 등록...

우리가 zenoh remote api와 websocket 연결을 할때, 기본적인 websocket 연결에 대한 이벤트 제어를 할 수 없다.왜냐하면 websocket관련 로직은 zenoh-ts 모듈에 존재하기 때문이다.
session연결시 단순 zenoh.session() 형태로 사용되기 때문에 우리는 zenoh session값을 받을뿐 websocket에 대한 내용을 가져올 순 없다.
여기서 우리는 전역으로 websocket을 만들때, proxy로 감싸서 websocket 생성시 websocket 자체를 우리가 다룰 수 있게 한다.

Zenoh

Sun, 12 Jul 2026 07:05:40 GMT

Zenoh란 무엇인가? 로봇과 IoT 통신에서 주목받는 이유

로봇이나 IoT 시스템을 개발하다 보면 여러 장치와 서비스 사이에서 데이터를 실시간으로 전달해야 하는 상황이 자주 발생한다.

예를 들어 자율주행 로봇 시스템에서는 다음과 같은 데이터가 끊임없이 오간다.

로봇의 현재 위치
배터리 상태
이동 명령과 실행 결과
장애물 및 센서 데이터
장치 연결 상태
지도와 작업 정보

처음에는 HTTP나 WebSocket만으로도 시스템을 구성할 수 있다. 하지만 연결되는 로봇과 서비스가 많아지면 서버가 각 연결과 메시지 전달 경로를 직접 관리해야 하고, 요청·응답과 연결 상태 확인을 위한 별도의 규칙도 필요해진다.

이러한 분산 환경에서 사용할 수 있는 통신 프로토콜 중 하나가 Zenoh다.

Zenoh란?

Zenoh는 데이터를 발행하고 구독하는 Pub/Sub 방식과 필요한 데이터를 요청하는 Query 방식을 하나의 프로토콜에서 제공한다.

Zenoh 공식 문서에서는 Zenoh를 다음 요소를 통합하는 Pub/Sub/Query 프로토콜로 설명한다.

이동 중인 데이터
저장된 데이터
데이터에 대한 연산

즉, 단순히 메시지를 전달하는 통신 채널을 넘어 실시간 데이터 전달, 데이터 조회, 저장소 연동을 하나의 데이터 공간에서 다루도록 설계된 프로토콜이다.

Zenoh라는 이름은 Zero Overhead Network Protocol에서 유래했다. 여기서 Zero Overhead는 실제 오버헤드가 완전히 0이라는 의미보다는, 다양한 네트워크와 장치 환경에서 통신 비용을 작게 유지하겠다는 설계 방향을 나타낸다고 이해하는 편이 적절하다.

Zenoh는 Eclipse Foundation에서 관리되는 오픈소스 프로젝트이며, 데이터센터와 클라우드뿐만 아니라 엣지 장치, 로봇, IoT 장비와 같은 제한된 환경까지 연결하는 것을 목표로 한다. 실제 활용 분야로는 로보틱스, 자동차, IoT, 엣지 컴퓨팅 등이 소개되고 있다.

Zenoh의 기본 데이터 구조

Zenoh에서는 데이터를 경로 형태의 키로 구분한다.

예를 들어 로봇의 상태를 다음과 같은 키로 표현할 수 있다.

robot/A001/status
robot/A001/battery
robot/A001/position
robot/A001/move/result

Zenoh는 이러한 키와 값을 기반으로 데이터를 전달한다. 값에는 문자열, JSON, 바이너리 데이터 등 다양한 형식을 사용할 수 있다.

특정 로봇의 배터리 상태를 받고 싶다면 다음 키를 구독할 수 있다.

robot/A001/battery

모든 로봇의 상태를 받고 싶다면 와일드카드가 포함된 Key Expression을 사용할 수 있다.

robot/*/status

또는 로봇과 관련된 모든 데이터를 구독할 수도 있다.

robot/**

Zenoh Router는 메시지의 Key Expression을 기준으로 데이터를 필요한 Subscriber에게 전달한다. 이 덕분에 Publisher는 데이터를 누가 받는지 직접 알 필요가 없다.

Zenoh의 주요 통신 방식

1. Publish/Subscribe

Publisher가 특정 키로 데이터를 발행하면 해당 키를 구독하고 있는 Subscriber가 데이터를 전달받는다.

AMR
  └─ robot/A001/status 발행
                  ├─ 관제 서버
                  ├─ 상태 관리 서비스
                  ├─ 로그 수집 서비스
                  └─ 모니터링 UI

로봇은 자신의 데이터를 누가 사용하는지 알 필요가 없다. 새로운 서비스가 추가되더라도 로봇 프로그램을 수정하지 않고 동일한 키를 구독하면 된다.

이러한 구조를 사용하면 데이터 생산자와 소비자 사이의 의존성을 낮출 수 있다.

2. Query/Reply

Pub/Sub는 실시간으로 발생하는 데이터를 전달하는 데 적합하다. 하지만 특정 시점의 정보가 필요할 때는 Query를 사용할 수 있다.

예를 들어 서버가 특정 로봇의 현재 네트워크 설정을 조회한다고 가정해 보자.

Query:
robot/A001/network/current

로봇이나 Agent는 해당 키에 Queryable을 등록하고 요청을 받았을 때 결과를 반환한다.

WebSocket으로 같은 기능을 구현하려면 일반적으로 요청 ID, 응답 매칭, 타임아웃, 오류 응답 규칙을 직접 설계해야 한다. Zenoh에서는 Query와 Queryable이라는 추상화를 통해 요청·응답 통신을 제공한다.

3. Storage

Zenoh Storage는 특정 Key Expression을 구독하여 데이터를 저장하고, Query 요청이 들어왔을 때 저장된 최신 값을 반환할 수 있다.

예를 들어 로봇이 주기적으로 상태를 발행한다고 가정해 보자.

robot/A001/status

이 데이터를 Storage에 저장하면 새롭게 접속한 서비스가 Query를 통해 최근 상태를 조회할 수 있다. 이후에는 Subscriber를 통해 실시간 변경을 계속 전달받을 수 있다.

Zenoh의 Storage는 Subscriber와 Queryable을 결합한 구조로 설명할 수 있다. 다만 Zenoh Router를 실행한다고 해서 데이터가 자동으로 영구 저장되는 것은 아니며, Storage Plugin이나 별도의 저장소 구성이 필요하다.

Zenoh의 장점

데이터 생산자와 소비자를 분리할 수 있다

WebSocket 기반 시스템에서는 서버가 연결된 클라이언트를 직접 관리하는 경우가 많다.

robotId → WebSocket 연결

특정 로봇의 데이터를 여러 서비스에 전달하려면 서버가 수신자를 찾아 각각 메시지를 보내야 한다.

Zenoh에서는 Publisher가 Key Expression을 기준으로 데이터를 발행하고 Subscriber가 필요한 데이터를 선택해서 구독한다.

Publisher → Zenoh Network → Subscriber

Publisher는 Subscriber의 주소, 개수 또는 위치를 몰라도 된다. 새로운 모니터링 서비스나 분석 서비스가 추가되어도 기존 Publisher를 수정할 필요가 줄어든다.

Pub/Sub와 요청·응답을 함께 사용할 수 있다

분산 시스템에서는 실시간 데이터뿐 아니라 현재 상태를 조회해야 하는 경우도 많다.

일반적인 시스템에서는 역할에 따라 여러 기술을 조합한다.

실시간 상태 전달 → WebSocket
상태 조회       → HTTP API
메시지 전달     → Message Broker
최근 값 조회    → Redis 또는 Database

Zenoh에서는 Pub/Sub, Query/Reply, Storage를 동일한 Key/Value 데이터 공간에서 사용할 수 있다.

물론 Zenoh가 데이터베이스나 HTTP API를 모두 대체한다는 의미는 아니다. 다만 장치와 서비스 간 통신에서 사용해야 하는 프로토콜과 데이터 모델을 줄일 수 있다는 장점이 있다.

다양한 네트워크 구조를 지원한다

Zenoh 애플리케이션은 시스템 환경에 따라 Client, Peer, Router 중심 구조로 배치할 수 있다.

Peer ↔ Peer

Client → Router ← Client

Robot → Edge Router → Central Router → Server

Peer 모드에서는 다른 Peer 또는 Router를 탐색하여 연결할 수 있다. Client 모드에서는 하나 이상의 Router Endpoint를 지정할 수 있다.

이러한 구조는 로봇 내부 네트워크, 공장 내부 네트워크, 원격 서버가 함께 존재하는 시스템에서 유용하다.

다만 Zenoh를 사용한다고 해서 자동으로 장애에 강한 시스템이 되는 것은 아니다. 하나의 Router에 모든 Client가 의존한다면 그 Router는 여전히 단일 장애 지점이 될 수 있다. 고가용성이 필요하다면 여러 Router 연결과 재접속 정책을 별도로 설계해야 한다.

계층적인 Key Expression을 사용할 수 있다

Zenoh에서는 데이터를 단순한 문자열 Topic이 아니라 계층적인 Key Expression으로 관리할 수 있다.

factory/line1/robot/A001/status
factory/line1/robot/A002/status
factory/line2/robot/A003/status

이 구조를 사용하면 서비스마다 필요한 범위만 구독할 수 있다.

factory/line1/robot/*/status
factory/**/robot/A001/**
factory/line2/**

로봇 수와 서비스 수가 증가해도 데이터의 의미와 범위를 비교적 일관된 규칙으로 관리할 수 있다.

장치와 서비스의 연결 상태를 표현할 수 있다

Zenoh는 Liveliness 기능을 제공한다. 애플리케이션이 특정 Key Expression에 Liveliness Token을 선언하면 다른 서비스가 해당 Token의 생성과 삭제를 관찰할 수 있다.

예를 들어 다음과 같은 키를 사용할 수 있다.

robot/A001/liveliness

이를 통해 로봇이나 Agent가 현재 Zenoh 네트워크에 참여하고 있는지 추적할 수 있다. Zenoh의 접근 제어 문서에서도 Liveliness Token이 별도의 메시지 유형으로 다뤄지고 있다.

다만 실제 운영 환경에서는 Liveliness 하나만으로 모든 장애를 판별하기보다 다음 방법을 함께 사용하는 것이 안전하다.

Liveliness
+ 마지막 메시지 수신 시간
+ Heartbeat
+ 애플리케이션 Watchdog

전원 강제 종료나 네트워크 단절에서는 장애 감지까지 시간이 걸릴 수 있기 때문이다.

엣지 장치와 저사양 장치를 고려할 수 있다

Zenoh는 Rust, Python, C, C++, Java, Kotlin 등의 API를 제공하며, 제한된 장치를 위한 C 기반 Zenoh-Pico도 제공한다.

따라서 중앙 서버뿐 아니라 로봇 제어 PC, 임베디드 장치, 센서 노드 등 다양한 환경에서 같은 데이터 모델을 사용할 수 있다.

WebSocket과는 무엇이 다른가?

WebSocket은 하나의 TCP 연결에서 클라이언트와 서버가 양방향 메시지를 주고받기 위한 프로토콜이다. HTTP 기반 핸드셰이크 후 기본적인 메시지 프레이밍을 제공한다.

반면 Zenoh는 메시지를 주고받는 연결뿐 아니라 다음 기능을 함께 제공한다.

Key Expression 기반 라우팅
Publisher와 Subscriber
Query와 Queryable
분산 Storage 연동
Peer 및 Router 기반 배포
Liveliness
Discovery

따라서 둘은 완전히 같은 계층의 기술이라고 보기 어렵다.

WebSocket
= 연결된 두 프로그램 사이의 양방향 통신 채널

Zenoh
= 다수의 장치와 서비스를 연결하기 위한 분산 데이터 통신 체계

WebSocket에서도 Pub/Sub나 요청·응답 기능을 구현할 수 있다. 하지만 연결 관리, Topic 규칙, 요청 ID, 타임아웃, 재연결, 메시지 라우팅 등을 애플리케이션이나 서버에서 직접 설계해야 한다.

Zenoh는 이러한 분산 통신 기능을 프로토콜 수준의 추상화로 제공한다.

반대로 브라우저와 웹 서버 사이의 단순한 실시간 통신에서는 WebSocket이 더 간단하고 적합할 수 있다. 브라우저는 WebSocket을 기본적으로 지원하지만, Zenoh를 웹 환경에서 사용하려면 REST Plugin이나 별도의 Bridge가 필요할 수 있다. Zenoh는 REST Plugin을 통해 Key/Value 공간에 HTTP로 접근하는 방법도 제공한다.

따라서 모든 WebSocket을 Zenoh로 교체하기보다는 시스템의 역할에 따라 기술을 구분하는 것이 좋다.

로봇·Agent·백엔드 서비스 간 통신
→ Zenoh

브라우저 UI와 백엔드 간 실시간 통신
→ WebSocket 또는 Socket.IO

대용량 파일 다운로드
→ HTTP 또는 Object Storage

파일 배포 명령과 진행 상태 전달
→ Zenoh

Zenoh가 적합한 경우

Zenoh는 다음과 같은 환경에서 특히 유용하다.

여러 대의 로봇이나 IoT 장치가 연결되는 시스템
하나의 데이터를 여러 서비스가 소비하는 시스템
실시간 상태 전달과 요청·응답이 모두 필요한 시스템
로컬 네트워크와 원격 서버를 연결해야 하는 시스템
중앙 서버뿐 아니라 엣지 장치 간 통신이 필요한 시스템
서비스가 지속해서 추가되거나 변경되는 분산 시스템

반대로 서버 한 대와 브라우저 몇 개가 연결되는 단순한 시스템이라면 WebSocket만으로도 충분할 수 있다. Zenoh를 도입하면 Router 운영, Key Expression 설계, 네트워크 모드 설정 등 추가로 관리해야 할 요소가 생기기 때문이다.

마무리

Zenoh는 단순히 WebSocket보다 빠른 통신 기술이라고 설명하기에는 부족하다.

Zenoh의 핵심적인 장점은 다수의 장치와 서비스가 데이터를 발행하고, 구독하고, 조회할 수 있는 공통 데이터 공간을 제공한다는 점이다.

WebSocket이 연결된 두 프로그램 사이의 통신 채널이라면 Zenoh는 로봇, Agent, 서버, Storage와 같은 여러 구성 요소를 느슨하게 연결하는 데이터 통신 백본에 가깝다.

특히 로봇과 IoT 시스템처럼 장치 수가 많고 네트워크 구조가 복잡하며, 동일한 데이터를 여러 서비스에서 사용해야 하는 환경에서는 Zenoh의 Pub/Sub, Query, Key Expression, Liveliness 기능이 시스템 구조를 단순화하는 데 도움이 될 수 있다.

다만 Zenoh를 도입한다고 해서 연결 복구, 데이터 유실 처리, Router 이중화와 같은 운영 문제가 자동으로 해결되는 것은 아니다. Zenoh가 제공하는 기능을 이해하고 시스템 특성에 맞는 장애 처리와 데이터 정책을 함께 설계해야 한다.

결국 Zenoh의 가치는 단순한 메시지 전송 성능보다 다음 문장으로 정리할 수 있다.

Zenoh는 분산된 장치와 서비스가 데이터의 위치와 상대방의 연결 구조에 덜 의존하면서 통신할 수 있도록 만들어 주는 프로토콜이다.

scp window to rhel

Thu, 19 Mar 2026 05:47:07 GMT

윈도우 to RHEL 파일 전송.

문제 발생.

윈도우에서 scp 를 통해서 원격 서버의 특정 폴더로 파일들을 전송하려고 하였음. 하지만 아래와 같은 오류 발생 원격 서버에서의 폴더 구조를 확인했으나 폴더 자체는 존재하는걸로 확인.

문제 해결

GPT 답변

윈도우의 scp가 기본적으로 SFTP 방식으로 동작하면서 원격 경로를 엄격하게 검사하는 경우입니다. OpenSSH 9.0부터 scp는 기본적으로 legacy SCP가 아니라 SFTP 프로토콜을 사용합니다. 그래서 예전에는 되던 경로가 지금은 realpath, path canonicalization failed 같은 에러로 실패할 수 있습니다. -O 옵션을 주면 예전 SCP 방식으로 강제할 수 있습니다.

내가 찾은 답변

https://stackoverflow.com/questions/26346277/scp-files-from-local-to-remote-machine-error-no-such-file-or-directory

두 답변 모두 -O 옵션을 통해서 문제 해결 제시.

결과

-O 옵션을 통해서 문제 해결 가능했음.

AWS (7) - S3, CloudFront

Fri, 20 Feb 2026 16:34:19 GMT

CloudFront

CloudFront란?

AWS에서 정적 웹 사이트를 배포할때는 EC2, ELB 대신 S3와 CloudFront를 사용할 수있음.
두개의 서비스는 정적 콘텐츠를 더 효율적으로 관리하고 제공할 수 있기 때문.
정적 웹사이트 호스팅의 한계점
- S3를 통해서 웹사이트를 호스팅 할 수 있지만 사용자 위치에 따른 콘텐츠 전송속도가 달라질 수 있다. 만약, 버킷이 한국 리전에 있다면 한국이 아닌 다른 나라에 있는 사용자는 파일을 받기 위해 좀 더 오랜 시간을 기다려야한다.
AWS에서는 이러한 문제를 해결하기 위해 전 세계에 파일의 복사본을 저장하는 임시 저장소를 구축했다. 사용자는 가까운 임시 저장소에서 파일을 가져올 수 있어 컨텐츠를 빠르게 받을 수 있다.
이러한 서비스를 CDN(Content Delivery Network)라고 한다.
AWS에서 CloudFront라는 CDN 서비스를 제공함.
CloudFront는 HTTPS를 사용하여 데이터를 전송할때 암호활르 제공함으로써 보안을 강화할 수 있으며, ACM과 연동하여 SSL/TLS 인증서를 무료로 발급하고 갱신할 수 있다.

정적 웹사이트 호스팅용 S3 버킷 준비

S3 버킷 생성 이전 버킷 생성편을 참고하여 버킷 이름 : 고유한 이름 객체 소유권 : ACL 비활성화 모든 퍼블릭 액세스 차단 : 모두해제 버킷 버전 관리 : 비활성화
버킷 정책 설정 서비스 : S3 작업 : GetObject 리소스 : 버킷내 모든 객체 보안주체 : 모든 사용자(*)
S3 정적 웹사이트 호스팅
데스크탑 또는 노트북 로컬 파일 index.html 생성 후 업로드
버킷 상세 페이지로 들어가서 -> 속성 탭 클릭
하단에 정적 웹사이트 호스팅 -> 우측 편집클릭
하단의 변경사항 저장 클릭 후 마무리
다시 버킷 상세 페이지에서 속성 탭 -> 가장 하단의 정적 웹사이트 호스팅에 보면 접속 url이 존재한다.
정상적으로 나오는거 확인

CloudFront 구성

cloudFront 콘솔 접속
배포 생성 클릭
요금제 선택(무료가 있으니 무료 선택)
도메인 정보 및 태그 정보 입력(가장 상단의 Distribution name만 입력후 나머지 비워둔 후 진행)
Origin Type 우리가 사용할 것은 S3이므로 S3 선택
Origin 우측 Browse S3 클릭후 원하는 버킷 선택후 Choose 선택
정상적으로 주소가 입력되는 것 확인후 웹 사이트 엔드포인트 사용 을 눌러서 cloudFront가 웹 사이트 엔드 포인트를 사용해서 버킷에 접근하도록 설정.
Next 클릭
Enable Security -> 그대로 Next 클릭
create distribution 클릭 후 마무리
대표 도메인을 복사해서 접속하면 index.html파일 내용이 정상적으로 뜸.

새로운 도메인 HTTPS 적용

HTTPS 적용을 위한 인증서 발급

ACM 콘솔 진입
CloudFront에서 HTTPS를 적용하려면 인증서를 버지니아 북부에서 발급 받아야 함. 리전을 변경
우측의 요청 버튼을 통해서 인증서 요청 도메인 이름 : 가지고 있는 도메인. 검증 방법 : DNS 키 알고리즘 : RSA 2048
CloudFront 인증서 적용
CloudFront 콘솔 메뉴에서 배포 -> 배포 ID 클릭
일반 탭의 설정에 있는 편집 클릭
Alternative Domain name에 SSl/TLS 인증서를 발급당르 때 썼던 도메인을 그대로 작성. 이 도메인은 기본으로 제공되는 도메인 대신 사용할 대체 도메인을 의미함. 그리고 Custom SSL certificate에서는 ACM에서 발급받은 SSL/TLS 인증서를 선택.
나머지는 그대로 두고 우측 하단 변경 사항 저장 클릭
CloudFront에 도메인을 연결하기 위해서 Route 53 콘솔에서 해당 도메인의 레코드 목록 화면으로 이동한 뒤 레코드 생성 버튼 클릭.
별칭 옵션 활성화 -> 트래픽 라우팅 대상에서 CloudFront 배포에 대한 별칭 선택 -> 앞에서 만든 CloudFront 선택후 레코드 생성클릭
이렇게 설정하면 CloudFront 의 배포 도메인과 Route53 의 도메인 접속시 동일하게 나오는걸 확인할 수 있다.

AWS (6) - S3, IAM

Wed, 18 Feb 2026 15:46:50 GMT

S3

S3란?

서비스를 배포하고 운영하면 백엔드 서버에서 이미지나 문서같은 파일을 저장하고 관리하면서 안정적인 저장소가 필요하다. AWS 에서는 이러한 파일 저장소로 S3를 활용한다.
S3는 파일 용량에 제한이 없고 사용자의 필요에따라 자동으로 확장됨.
데이터를 여러 물리적 위치에 분산하여 저장하기 때문에 데이터가 손실될 확률이 아주 희박.

버킷

구글 드라이브에서 공유 드라이브를 여러 개 만들 수 있는 것처럼 S3 에서도 저장소를 여러 개 만들 수 있다. S3에서는 이렇게 만들어진 저장소를 버킷(bucket)이라고 한다.

객체

버킷에 업로드한 파일을 객체(object)라고 한다. 객체는 키-값으로 이루어지는데, 여기서 키는 객체에 할당한 이름, 값은 업로드한 콘텐츠 자체를 의미한다. 객체의 값은 바이트 형태로 저장됨.

이미지 업로드 과정

사용자가 EC2 인스턴스에 동작중인 백엔드 서버로 업로드 요청.
EC2에서 S3로 이미지를 업로드
S3에서 저장된 URL 주소 반환
EC2에서 RDS로 반환된 URL 주소 저장.

이미지 다운로드 과정

이미지 조회 API EC2로 전송.
EC2에서 RDS로 이미지 조회 쿼리 전송.
RDS에서 EC2로 이미지 URL 반환.
사용자에게 이미지 URL 반환.
사용자가 URL을 통해 다운로드시 S3를 통해 직접 다운로드.

백엔드 서버 자체에서 이미지를 전달해주는게 아니라 S3에서 직접 다운로드 받습니다.

S3 버킷 만들기

S3 콘솔 이동
우측 상단 리전 메뉴 서울 선택
버킷 만들기 클릭
버킷 이름 작성(AWS 전체 내에서 공유해야함 - 이제까지 다른 이름들도 마찬가지)
퍼블릭 액세스 차단 해제 익명의 사용자도 S3에서 객체를 내려받을 수 있도록 하기 위한 절차.
버킷 만들기 클릭
버킷 생성 완료 아직 사용자들이 해당 버킷에 접근이 불가능한 상태.

버킷 정책 추가

생성한 버킷 들어가기
권한 -> 버킷 정책 -> 편집
정책 추가(새 문 추가 클릭)
왼쪽에 JSON 형식 이 나타나고, 오른쪽에는 작업 추가 화면이 나옴. S3 관련된 권한 추가를 위해 서비스 선택 검색 창에 s3 입력하여, S3 클릭
우측 검색창에 GetObject 입력후 아래 액세스 수준 - 읽기 에서 GetObject 선택후 리소스 추가의 추가 클릭 GetObject는 객체를 조회 하겠다는 뜻이며, 파일을 내려받을 수 있는 권한을 허용하는 문구를 추가한 것임.
리소스 추가하기 리소스 유형에 object를 선택. (S3에는 여러 버킷이 있고, 하나의 버킷 안에는 다양한 객체가 존재하는데 경우에 따라 특정 버킷 또는 특정 객체에만 접근하게 설정할 수 있음.) object로 선택하면 아래 리소스 ARN이 arn:aws:s3:::{BucketName}/{ObjectName} 으로 변경되는데, BucketName : 접근 허용 버킷 ObjectName : 접근 허용할 특정 객체(* 를 쓰면 버킷의 모든 객체 허용)

여기서는 * 로 작성

리소스 추가 버튼을 클릭하면 JSON 에 Resource 부분 이 추가된걸 확인
누구에게 권한을 부여할 것인가. 부여대상을 설정하기 위한 속성이 Principal. 여기서 우리는 모든 사용자에게 이미지를 볼 수 있게 하기위해 * 로 변경.
우측 하단 변경사항 저장 으로 마무리

IAM

IAM 이란?

앞에서 S3의 설정으로 사용자들은 S3에 저장된 파일을 내려받을 수 있게 되었다.
하지만 백엔드 서버는 S3에 접근할 수 없는데, AWS SDK 라이브러리를 사용해 S3와 같은 AWS의 서비스에 요청을 보내는데, 이때 서비스에 접근할 수 있는 권한이 필요하기 때문이다.
IAM(Identity and Access Management) AWS 자원에 대한 접근 권한을 제어하는 서비스.
IAM의 사용자에게 액세스 키, 비밀 액세스 키 가 주어진다. 액세스키는 아이디 같은 역할, 비밀 액세스키는 비밀번호 같은 역할을 함.
IAM 액세스키 발급 받기
IAM 콘솔 진입
사용자 메뉴 -> 사용자 생성 클릭
사용자 이름 작성(각 사용자 구분 가능한 이름으로)
권한 설정 -> 직정 정책 연결 선택 권한 정책 -> s3에 대한 접근 권한이 필요하므로 s3full 검색 -> 체크박스 체크 -> 다음 클릭
세부정보 확인후 사용자 생성 클릭
사용자 메뉴로 들어가서 사용자 이름 클릭
보안자격 증명 탭 -> 액세스키 만들기 클릭(우측, 중앙 중 아무거나 동일)
액세스키 모범 사례 및 대안 에서 우리는 AWS EC2에서 실행되는 서비스가 접근할 예정이므로, AWS 컴퓨팅 서비스에서 실행되는 애플리케이션 선택 후 다음 클릭
설명 태그 설정 -> 설정 태그 값 은 비워두고 -> 엑세스 키 만들기 클릭
사진과 같이 생성된 액세스 키가 보임.

비밀 액세스키의 경우 위에 알림이 뜨는것과 같이 해당 페이지에서 벗어나면 다시는 볼 수 없어서 새로 액세스키를 만들어야 하니 복사해 놓아야 함

백엔드 연동

프로젝트 다운로드

$ cd ~
$ git clone https://github.com/JSCODE-BOOK/aws-s3-springboot.git
$ cd aws-s3-springboot/src/main/resources
$ vi application.yml

application.yml 내부

server:
port: 80
spring:
datasource:
  url: jdbc:mysql://_________:3306/ # RDS 인스턴스 엔드포인트 / DB이름
  username: ______ # (RDS 인스턴스 생성 시 셋팅한) RDS 마스터 사용자 이름
  password: ______ # (RDS 인스턴스 생성 시 셋팅한) RDS 마스터 비밀번호
  driver-class-name: com.mysql.cj.jdbc.Driver
jpa:
  hibernate:
    ddl-auto: create
  show-sql: true
cloud:
  aws:
    credentials:
      access-key: _________ # IAM 통해서 발급받은 액세스 키
      secret-key: _________ # IAM 통해서 발급받은 비밀 액세스 키
    s3:
      bucket: _________ # 생성한 버킷명
    region:
      static: ap-northeast-2

빌드 및 배포

$ cd ~/aws-s3-springboot
$ ./gradlew clean build -x test # 스프링 부트 프로젝트 빌드
$ cd build/libs
$ sudo nohup java -jar aws-s3-springboot-0.0.1-SNAPSHOT.jar & # JAR파일 실행

https://api.<도메인주소>/health 입력
PostMan 을 사용할 겁니다.
전송시 사진과 같은 결과가 반환됨.
S3 메뉴에서 버킷 클릭시 사진이 업로드 된 걸 확인 가능.
게시글 조회를 위한 GET 요청시 정상 반환 확인

AWS (5) - RDS

Wed, 18 Feb 2026 15:46:38 GMT

RDS

RDS란?

RDS(Relational Database Service)의 줄임말로, AWS로부터 관계형 데이터베이스르 빌려서 사용할 수 있는 서비스이다.
MariaDB, Postgresql 등 다양한 데이터베이스를 지원한다.
또한 백업, 업데이트, 자동 확장 기능을 제공함.

RDS 인스턴스

데이터베이스가 설치되어있는 컴퓨터 한 대를 RDS 인스턴스라고 함.
엔진 유형 : MySQL, Postgresql, MariaDB, Amazon Aurora 등이 존재. 인스턴스 클래스: RDS에서 인스턴스 클래스란 컴퓨터의 성능을 뜻함. EC2 서비스에서 인스턴스 유형과 비슷한 뜻으로 고성능 컴퓨터일수록 많은 양의 데이터를 처리할 수 있음. 스토리지 : 데이터베이스가 데이터를 저장하는 공간.

RDS 인스턴스 생성

RDS 콘솔 진입.
리전 서울 선택
데이터베이스 생성클릭
데이터 생성 방식 및 엔진 설정
템플릿 선택
설정 정보 입력
인스턴스 유형 선택
스토리지 선택
연결 설정

RDS에서 퍼블릭 액세스를 사용할경우 시간당 요금이 부과됩니다. RDS 인스턴스를 사용하지 않을때는 인스턴스 삭제를 추천합니다.

퍼블릭 액세스를 통해서 외부에서 데이터베이스에 접근할 수 있게 만들 수 있습니다. 또한 데이터 베이스에 접근하는 트래픽을 허용하기 위해 보안그룹을 새로 생성합니다.

하단의 추가 구성을 펼쳐서 초기 데이터 베이스 이름을 작성
가장 밑에 데이터베이스 생성 버튼으로 생성 마무리
데이터베이스의 DB 식별자 를 클릭하여 상세 페이지로 이동

RDS 보안그룹 수정

상세 페이지로 이동했으면, 하단의 연결 및 보안 부분에서 VPC 보안 그룹 클릭
보안그룹에 대한 인바운드 규칙 편집
소스를 Anywhere-IPv4로 수정후 규칙 저장

RDS 인스턴스 접속

RDS 메뉴에서 데이터베이스 클릭후 -> DB식별자를 클릭 후 -> 연결 보안 -> 엔드포인트 선택
엔드포인트 와 포트를 사용하여 접속 시도.
HediSQL을 통해서 접속했음. 데이터베이스 생성하면서 만들었던 integration 데이터베이스도 존재함.

파라미터 그룹 설정

데이터베이스의 저장되는 날짜 데이터를 한국시간을 기준으로 저장하거나 인코딩 방식을 설정한다거나 하는 경우. RDS에서는 파라미터 그룹을 사용하여 데이터베이스 설정이 가능하다.
RDS 메뉴에서 파라미터 그룹 -> 파라미터 그룹 생성 클릭
사진과 같이 입력후 생성 파라미터 그룹이나 설명은 알아서 작성.

여기서 중요한점은 위에서 생성한 Mysql 버전이 8.4.7 이었기 때문에 파라미터 그룹 패밀리 항목을 mysql8.4로 변경해줘야 함.

생성된 파라미터 그룹의 이름을 클릭하여 세부정보로 들어감
편집 클릭
수정 가능한 파라미터에 character_set 입력후 검색
utf8보다는 utf8mb4를 통해서 한글뿐 아니라 이모티콘도 같이 지원할 수 있도록 함. 파라미터에 대한 값 입력 부분에 utf8mb4 작성후 변경사항 저장
다시 편집을 눌러 collation 검색후 나온 값들에 대해서 utf8mb4_unicode_ci 입력후 저장
다시 편집을 눌러 time_zone 검색후 Asia/Seoul 입력후 저장. (시간대를 한국 기준으로 맞추기 위함)

RDS 파라미터 그룹 변경

RDS 메뉴에서 데이터베이스 선택후 -> 수정 클릭
추가구성 항목에서 위에서 생성한 파라미터 그룹을 선택 후 저장.
즉시 적용
데이터 베이스가 수정중에서 사용가능으로 변경되면 우측 상단의 작업 에서 재부팅 클릭. 이 과정을 진행해야 적용되므로 반드시 수행.
사용가능 상태가 되면 DB 식별자 클릭 후 세부 사항으로 이동.
하단의 구성탭을 누르면, DB 인스턴스 파라미터 그룹이 내가 선택한 그룹이 된다.

백엔드와 연동

예제 프로젝트 가져오기 git clone https://github.com/JSCODE-BOOK/aws-rds-springboot.git

cd aws-rds-springboot/src/main/resources vi application.yml

server:
port: 80
spring:
datasource:
  url: jdbc:mysql://___________:3306/instagram # RDS 인스턴스 엔드포인트,
  # 가장 끝에 instagram은 본인이 만든 데이터베이스 이름으로 수정
  username: ______ # RDS 마스터 사용자 이름
  password: ______ # RDS 마스터 비밀번호
  driver-class-name: com.mysql.cj.jdbc.Driver
jpa:
  hibernate:
    ddl-auto: update
  show-sql: true

빌드 및 실행

$ sudo kill {PID 값} # 80번 포트에서 실행되는 프로세스가 있다면 종료
$ cd ~/aws-rds-springboot
$ ./gradlew clean build -x test # 스프링 부트 프로젝트 빌드
$ cd build/libs 
$ sudo nohup java -jar aws-rds-springboot-0.0.1-SNAPSHOT.jar & # JAR 파일 실행

결과

AWS - 삭제

Wed, 18 Feb 2026 09:18:20 GMT

EC2

인스턴스 종료 후에도 콘솔에 표시될 수 있다고 함.

참고 링크

탄력적 IP

EC2 인스턴스 삭제 후 릴리즈 가능

CloudFront

비활성화 후 삭제가 가능한데, 바로 삭제가 가능하진 않고 좀 시간을 두고 기다리면 삭제 버튼이 활성화 되는데. 바로 또 되지도 않음.
배포시에 요금제를 선택하는데, 이 요금제를 취소하고 플랜기간이 지나면 그때 삭제가 가능하다고함.
플랜 취소는 이름 클릭해서 세부 사항 에 Manage Plan이 있다. 누르면 우측에 창이 뜨는데 거기서 취소하면됨. 그러면 아래 사진처럼 뜬다. 난 3월1일 이후에 삭제가 가능.

AWS (4) - ELB, ACM

Wed, 18 Feb 2026 03:21:31 GMT

ELB

ELB란?

일반적인 백엔드와 프론트엔드는 서로 데이터를 주고 받는다. 이때주고받는 데이터가 외부에 노출되지 않도록 하려면 HTTPS를 사용하여 통신할 수 있게 해줘야 한다. 우리는 HTTPS를 적용하기 위해 ELB 서비스를 이용한다.
ELB(Elastic Load Balancing)은 AWS에서 제공하는 로드 밸런서 서비스를 말한다.
ELB에서는 트래픽 분산 기능을 제공하고, 추가적으로 특정 포트에서 HTTPS요청을 처리하도록 설정할 수 있으므로 보안이 필요한 웹사이트나 API 서버에서도 많이 사용함.

구성요소

학습전 리전은 항상 서울로 선택
리스너
ELB로 들어오는 요청을 어떻게 처리할지 결정하는 규칙을 관리함.
특정 포트와 프로토콜을 사용하여 클라이언트의 요청을 기다리고, 해당 요청을 ELB에서 설정된 규칙에 따라 적절한대상 그룹으로 전달.

대상그룹

ELB가 수신한 트래픽을 전달할 서버들의 집합을 의미.
ELB로 들어온 요청을 어떤 곳으로 전달할지 정해야 하는데, 여기서 어떤 곳을 ELB 에서는 대상 그룹이라고 표현함.
또한 ELB는 트래픽의 전달 대상이 되는 서버들의 health check를 진행하여 전달 목적지를 정한다. 대상 그룹을 만들때 상태 검사를 할 경로와 포트를 지정한다.

대상그룹 만들기

ec2메뉴 접속후 대상그룹 메뉴 선택 -> 우측 상단 대상 그룹 생성 클릭
대상 유형 : 이전에 생성했던 EC2 인스턴스에 연결할 목적이니 인스턴스 선택 대상 그룹 이름 : 직관적인 이름으로 작성 트래픽 전달 방식 : 현재 EC2 인스턴스는 IPv4 주소를 가지며, 백엔드 서버는 80 포트를 사용중이고, HTTP로 통신한다. 이에 맞춰 설정해준다.
상태 검사 설정 대상에 일정한 주기로 전송할 상태 검사를 설정하는 단계. HTTP에 /health 입력 이렇게하면 대상 그룹의 EC2 인스턴스에 HTTP 프로토콜을 사용하여 GET /health 요청을 일정한 주기로 전송.
- 정상적으로 작동하기 위해서는 따로 API를 구축해야함 **
나머지는 그대로 두고 다음 클릭.
대상 등록 등록할 인스턴스 좌측 체크박스 클릭후. 선택한 인스턴스를 위한 포트는 ELB로 들어온 요청을 대상에 추가한 인스턴스의 80번 포트로 전달하겠다는 의미. 하단의 아래에 보류 중인 것으로 포함을 눌러 인스턴스 대상에 추가.
다음 클릭
지금까지 등록한 내용을 전체적으로 보여주는 것이니 확인 후 이상이 없다면 대상 그룹 생성 클릭
좌측 대상 그룹 메뉴에서 확인

로드밸런서 생성

학습전 리전은 항상 서울로 선택
EC2 메뉴에서 로드 밸런서 메뉴 클릭 -> 우측 상단 로드 밸런서 생성 클릭
우리는 HTTP/HTTPS 기반 트래픽 처리가 필요하므로, Application Load Balancer 선택
기본구성 설정
네트워크 매핑 가용영역 및 서브넷 모두 체크
보안그룹 부분에서 새 보안 그룹 생성 클릭
기본 정보 입력
HTTP/HTTPS 트래픽 허용 인바운드 규칙 추가
우측 하단의 보안그룹 생성 클릭후 다시 돌아오기
이전 보안 그룹 에서 방금 추가한 보안 그룹 선택
리스너 및 라우팅에서 대상그룹은 우리가 이전에 추가했던 그룹으로 선택
가장 하단의 로드밸런서 생성 클릭
좌측 로드밸런서 메뉴에서 항목 추가된걸 확인

상태검사 API 추가.

이전에 로드밸런서를 생성할때 상태검사를 할 수 있도록 경로를 지정하였다.
하지만 상태 검사에 사용되는 API를 추가하지 않으면 로드밸런서는 서버가 현재 정상적이지 않다고 판단합니다.
예제 파일 다운로드 git clone https://github.com/JSCODE-BOOK/aws-elb-springboot.git

코드 확인(GET /health 요청시 응답하도록 되어있음)

AppController.java
@RestController
public class AppController {

// GET /health 요청 시 이 메서드 호출 @GetMapping(“health”) public ResponseEntity healthCheck() {

// HTTP 200 OK 응답과 메시지 반환 return ResponseEntity.ok().body(“Success Health Check”); } }

- 인스턴스에서 아래 명령들 실행

$ sudo lsof -i:80 # 80번 포트에서 실행되는 프로세스 확인 $ sudo kill {PID 값} # 80번 포트에서 실행되는 프로세스가 있다면 종료 $ cd ~/aws-elb-springboot $ ./gradlew clean build -x test # 스프링 부트 프로젝트 빌드 $ cd build/libs $ sudo nohup java -jar aws-elb-springboot-0.0.1-SNAPSHOT.jar & # JAR 파일 실행 $ sudo lsof -i:80 # 80번 포트에서 실행되는 프로세스 조회

- 결과
![](https://velog.velcdn.com/images/os_js/post/b37250c3-bfd6-4710-954d-fb65e57f77be/image.png)

### 로드 밸런서로 확인
- 좌측 `로드밸런서` 메뉴 클릭후 로드밸런서 이름을 클릭
![](https://velog.velcdn.com/images/os_js/post/b4427434-b9aa-43f6-ae9a-11e7efe0224d/image.png)

- 세부정보가 나타나는데 우측 하단의 `DNS 이름`을 통해서도 접속이 가능하다.
`http:///health`
![](https://velog.velcdn.com/images/os_js/post/f1603627-ac81-4963-88a1-0a080f19376d/image.png)

- 정상적으로 `Success Health Check` 가 뜬다면 성공.

## 로드 밸런서에 도메인 연결
### EC2와 연결된 Route 53 레코드 편집
- Route 53 메뉴로 들어가서 편집할 레코드 체크.
![](https://velog.velcdn.com/images/os_js/post/259272b0-7dae-4d26-8aed-ee205f07acc1/image.png)
- 우측에 `레코드 편집` 클릭
![](https://velog.velcdn.com/images/os_js/post/b1e084cc-aa9f-4865-9459-4e1fd99097b7/image.png)
- 레코드 편집(별칭 메뉴 옵션을 활성화 하면 하단이 변경된다.)
![](https://velog.velcdn.com/images/os_js/post/35fac4a4-4be8-43c4-8ca1-ab1b6f7b5410/image.png)
- 이제 도메인을 통해서 로드밸런서로 전달된다.
![](https://velog.velcdn.com/images/os_js/post/b03a1741-aee4-4725-8938-3d3e75f6822a/image.png)

## HTTPS 적용
### 적용 단계
1. SSL/TLS 인증서 발급받기
2. 로드 밸런서에 HTTPS용 리스너 추가하기
3. HTTP에서 HTTPS로 리디렉션 설정

### SSL/TLS 인증서 발급받기
- AWS에서 ACM(AWS Certificate Manager)라는 서비스를 활용하여 인증서 발급.
- ACM을 통해서 발급받는 인증서는 대부분 무료.
자세한건 [공식페이지](https://aws.amazon.com/ko/certificate-manager/pricing/) 를 통해서 확인
- ACM 콘솔 접속
![](https://velog.velcdn.com/images/os_js/post/a7055c56-9cce-415b-9b14-0f8bc5150025/image.png)
- 리전을 서울로 꼭 설정하세요.
- 인증서 `요청` 클릭
![](https://velog.velcdn.com/images/os_js/post/6fab6573-d59c-428d-ae74-28383811ea69/image.png)
- 그대로 `퍼블릭 인증서 요청`에 두고 `다음` 클릭
![](https://velog.velcdn.com/images/os_js/post/a4985159-4689-4eb4-ba94-094af8c546fe/image.png)

- 이전에 만들어뒀던 `도메인 주소` 입력
![](https://velog.velcdn.com/images/os_js/post/14e52ea3-3d41-45ad-abbe-ce76a2c56f7d/image.png)
- 나머지 그대로 둔 후 `요청` 클릭
![](https://velog.velcdn.com/images/os_js/post/7ef519fa-1f17-4155-bf4b-0654dcf08b03/image.png)
- 좌측`인증서 나열` 메뉴 클릭후 항목 추가된 것 확인
(정상적인 사용자가 발급한 것인지 확인 후 완료됨)
![](https://velog.velcdn.com/images/os_js/post/001b01ef-b407-43b8-bba2-45dee9a1ba48/image.png)
- 인증서 목록에서 ID 클릭후 상세화면으로 넘어가기.
- 도메인 소유자라는 사실을 인증하기 위해 ACM에서 제공하는 CNAME 이름과 값을 도메인의 레코드에 입력해야함.
`레코드 생성` 클릭을 통해서 쉽게생성할 수 있지만 직접 레코드를 수동으로 생성.
![](https://velog.velcdn.com/images/os_js/post/a3ce2c4a-8d15-4666-bddd-74e1758725f1/image.png)
- `ROUTE 53` 메뉴에서 `호스팅 영역` 클릭후 나오는 도메인 주소 항목중 하나의 ID 클릭후 우측의 `레코드 생성`클릭
![](https://velog.velcdn.com/images/os_js/post/f9e6da5f-5fe8-463a-9bcb-6257166dc826/image.png)
- 레코드 생성 화면에서 `레코드 유형`을 `CNAME`으로 선택.
이전 과정에서 ACM에서 제공되는 `CNAME이름`을 `레코드 이름`에 `CNAME값`을 `값` 에 작성한 후 생성.
> 주의점 : `CNAME 이름`을 복사 붙여넣기 할때, 전부다 붙여넣으면 안되고 도메인이 정상적으로 되도록 해야함.
예를들어, `CNAME 이름`이 `2343535_A.B.C.com` 이라고 치자. 그렇다면 레코드 생성때 뒤에 `B.C.com` 이런식으로 편집 불가능한 메인 도메인이 작성되어 있을 것이다.
그럼 `CNAME 이름`에서 `2343535_A` 부분만 붙여 넣으면 된다. `CNAME 값`은 그대로 작성.

![](https://velog.velcdn.com/images/os_js/post/8c43e911-5a9f-499a-9f06-053f5d0b926d/image.png)
- 다시 `ACM ` 메뉴로 들어와서 검증이 완료되었는지 확인.
(10분이 지나도 안된다면 제대로 입력했는지 레코드 생성값 확인)
![](https://velog.velcdn.com/images/os_js/post/4618c36e-47de-419c-8744-0fe63a70afb9/image.png)

### 로드 밸런서에 HTTPS용 리스너 추가.
- 로드 밸런서에서 HTTP 요청을 받을 수 있는 리스너를 만든 것처럼 HTTPS도 요청을 받을 수 있는 리스너를 추가해야한다.
- `EC2` 콘솔에서 `로드밸런싱` -> `로드 밸런서` 메뉴 이동. 이전에 생성한 로드 밸런서 이름 클릭
- 하단에 `리스너 추가 ` 클릭
![](https://velog.velcdn.com/images/os_js/post/c0184059-3c3c-407f-baf6-700a147a6813/image.png)
- 리스너 구성
![](https://velog.velcdn.com/images/os_js/post/b2576d81-9e76-45c3-b13a-a7e3bfb70b36/image.png)
- 보안 리스너 설정. 이전에 만들었던 인증서 선택
![](https://velog.velcdn.com/images/os_js/post/ba6d9442-2cfa-4133-b359-2af3e2dc4910/image.png)
- 아래로 내려서 `추가` 버튼 클릭으로 생성 마무리.
- 그러면 `리스너 규칙`항목에 추가 됨.
![](https://velog.velcdn.com/images/os_js/post/9a226fe6-5788-47be-bf38-3156c30124ca/image.png)
- 이제 http://<도메인명>/health 뿐만 아니라 https://<도메인명>/health 도 정상 동작함.
![](https://velog.velcdn.com/images/os_js/post/4805c80f-c9d1-4143-8809-e581df958ddf/image.png)

### HTTP에서 HTTPS로 리디렉션 설정.
- HTTPS를 통해서 접속이 가능하더라도 HTTP로 접속또한 가능하다. 이렇게되면 보안이 취약하기때문에 HTTP로 접속하더라도 강제로 HTTPS로 접속하게 수정.
- 기존 HTTP 리스너 삭제
![](https://velog.velcdn.com/images/os_js/post/c6d008ef-d70e-45f2-946f-213512a0b7bf/image.png)
- `리스너 추가` 클릭
HTTP 80 포트로 들어오면 HTTPS 443 포트로 연결 되도록 설정
![](https://velog.velcdn.com/images/os_js/post/4621a7b1-b4a1-4ee9-836d-e3c11f4e2e09/image.png)
- `추가` 버튼으로 생성 마무리
- 이제 http로 접속해도 https로 연결되는걸 확인할 수 있음.

AWS(3) - Route 53

Wed, 18 Feb 2026 03:21:18 GMT

Route 53

Route 53 이란?

우리가 보통 특정 웹사이트를 이용하기 위해서는 192.x.x.x 와 같이 IP를 사용하여 사이트에 접속하지 않고, https://www.google.com/ 와 같이 이름을 통해서 접속하게 된다.
이전에 실습한 EC2 인스턴스에 접속할때 IP를 사용하여 접속을 테스트하였지만 실제 서비스를 배포하게 된다면 IP를 통해서 사용자들이 접속하도록 하진 않을것이다.
그렇다면 우리도 도메인 주소를 사용하여 접속할 수 있도록 해야하고, AWS 에서는 이러한 도메인을 관리할 때 사용하는 것이 Route 53이다.

도메인

도메인이란?

문자로된 컴퓨터 주소라고 보시면 되겠습니다. 위에서도 말씀드렸듯이 숫자로만 이루어진 접속 방법은 사용자에게 불편함을 주기때문에 조금 더 쉽게 접속이 가능하도록 만들어진 개념입니다.

서브 도메인

우리가 네이버를 사용하다보면 naver.com, www.naver.com, map.naver.com과 같은 주소를 보셨을 텐데, xxx.naver.com 형태의 도메인을 서브 도메인이라고 합니다.
서브 도메인은 하나의 도메인 아래에서 여러 서비스를 구분하여 관리할때 사용됩니다.
이름이 다르다고해서 각각 구매하지 않아도 된다는 장점이 있습니다.

도메인을 사용하는 이유

위에서 언급한 것처럼 사용자가 좀 더 쉽게 기억하고 접속할 수 있도록 하는 용도도 있지만, 서비스를 개발할때 API를 호출하게 되는경우 일반적으로 IP 주소는 HTTPS를 적용할 수 없기 때문에 도메인을 사용합니다.

그렇다면 AWS에 서비스를 구축하면 Route 53 을 사용해야 하는가?

그렇지 않음.
DNS마다 제공하는 도메인의 종류와 가격이 다르기 때문에 굳이 Route 53 만을 사용할 필요는 없음.
본인이 원하는 가격 및 도메인 종류에 따라서 다른 DNS를 사용해도 됨.

실습

도메인 구매

유료 플랜으로 변경해야 도메인 구매 가능.. 그리고 따로 프리티어랑 관계없이 도메인 구매 비용이 청구되니 이점 유의...

Route 53 콘솔 접속
우측의 도메인 등록 클릭
사용할 도메인 구매(아래 표준 요금을 통해서 싼 도메인을 구매하고싶으면 확인 후 구매)

결제 진행시 자동 갱신은 본인의 상황에 맞게 체크

구매 완료 후
구매후 바로 사용 가능한 것은 아니고, 좌측 메뉴의 요청 메뉴를 통해 보면 현재 진행상태가 처리중 이라는 것을 볼 수 있다. 빠르면 10 분 늦어도 12시간 안으로 완료 된다고 함.
등록 성공

도메인 연결하기

레코드 생성을 위해 좌측 Route 53 메뉴에서 호스팅 영역메뉴 클릭후 호스팅 영역 이름 영역에 나와있는 도메인 이름을 클릭
레코드 생성 클릭
레코드 이름 : 서브 도메인 입력. 용도에 맞게 쓰면 되는데 우선 백엔드의 api 서버의 도메인 주소를 설정하기 위해
레코드 유형 : 레코드와 EC2 인스턴스의 퍼블릭 IP를 연결하기 위해 A 레코드로 선택.
값 : 이전에 생성했던 EC2 인스턴스의 퍼블릭 IP 작성
레코드 생성 클릭
목록에 생성한 레코드 등록 확인

도메인 연결 확인

이전에 EC2 인스턴스에서 실행했던 스프링 부트 서버를 실행 후 IP, 도메인으로 모두 접속이 가능한지 확인.
결과

무료 도메인

Route 53을 통해서 도메인을 구매하면 비용이 발생한다.
무료로 도메인을 구매할 방법이 없을까?

발급

내도메인한국 사이트 접속
회원가입후 일반 도메인 검색에 원하는 도메인 이름 검색.
검색 클릭시 아래와 같이 사용 가능한 도메인 확인 가능 등록 하기 클릭
보안코드 입력 후 등록 하기 클릭
DNS 레코드 설정
고급설정 에서 IP연결(A) 에 서브도메인 작성후 우측에는 EC2 퍼블릭 IP 작성
접속 확인

AWS (2) - EC2, 보안그룹

Tue, 17 Feb 2026 08:05:40 GMT

EC2란?

AWS의 EC2(Elastic Compute Cloud)는 가상 서버를 제공하는 서비스.

제공 기능

인스턴스 가상 서버.
Amazon Machine Images (AMIs) 서버에 필요한 구성 요소(운영 체제와 추가 소프트웨어 포함)를 패키징하는 인스턴스용 사전 구성 템플릿.
인스턴스 타입 인스턴스의 다양한 CPU, 메모리, 스토리지, 네트워킹 용량 및 그래픽 하드웨어 구성.
Amazon EBS 볼륨 Amazon Elastic Block Store(Amazon EBS)를 사용하는 데이터에 대한 영구 스토리지 볼륨.
인스턴스 스토어 볼륨 인스턴스를 중단, 최대 절전 모드로 전환 또는 종료할 때 삭제되는 임시 데이터용 스토리지 볼륨.
키 페어 인스턴스에 대한 보안 로그인 정보. AWS는 퍼블릭 키를 저장하고 사용자는 프라이빗 키를 안전한 장소에 저장합니다.
보안 그룹 인스턴스에 도달할 수 있는 프로토콜, 포트 및 소스 IP 범위와 인스턴스가 연결할 수 있는 대상 IP 범위를 지정할 수 있는 가상 방화벽.

인스턴스 생성

검색창에 ec2 검색 후 대시보드 접속
우측상단의 리전 선택을 서울로 변경
인스턴스 시작
OS 설정(필요에 따라 변경) [Ubuntu]
인스턴스 유형(자동으로 선택되긴 합니다만 이것도 필요에 따라서 설정)
키페어(현재 진행에서는 따로 사용안함, 필요에따라 진행)
네트워크 설정(현재는 외부에서 80 포트로 진입할 수 있도록 해당ㄴ ㅐ용만 추가)
스토리지 설정
인스턴스 시작

인스턴스 확인

좌측 메뉴의 인스턴스 클릭
생성된 인스턴스 확인 (현재 사용중이 아니라 종료. - 바로 생성하고나면 실행중)
항목에서 인스턴스 ID 클릭. (ip주소 및 현재 상태, 우측 상단의 인스턴스 상태를 통해 중지 및 시작 가능)
밑에 보시면 인스턴스에 대한 상세 메뉴 들이 존재 여기서 사용량 및 성능지표를 확인할 수 있음.

인스턴스 접속

인스턴스가 실행중인 경우 우측 상단에서 연결 버튼을 통해서 인스턴에 연결이 가능함.
그리고 우측 하단의 연결을 클릭
접속이 정상적이면 아래와 같이 접속됨.

탄력적 IP

탄력적 IP란?

탄력적 IP란 동적 클라우드 컴퓨팅을 위해 고안된 정적 IPv4주소를 말합니다.
위에서 보신 퍼블릭 IP의 경우 인스턴스를 중지 후 다시 시작하게 되면 이전 IP와 달라지게 됩니다. 그렇다면 해당 인스턴스와 통신하던 다른 서비스나 인스턴의경우 매번 IP를 변경해줘야 하는데, 이러한 문제가 일어나지 않기 위해 정적 Ip가 필요합니다.

할당

좌측 메뉴 탄력적 IP 선택 -> 우측 상단의 탄력적 IP 주소 할당 클릭
할당 받기
좌측의 체크박스 선택후 우측의 작업 클릭 -> 탄력적 IP 주소 연결 클릭
인스턴스 선택후 우측 하단 연결 클릭
아래와 같은 알람이 뜨면 정상 연결된 것.
이후 다시 인스턴스 메뉴로 돌아가서 IP를 확인해보면 할당받은 IP로 연결된 것을 확인할 수 있음.

간단하게 스프링부트 서버 배포하기

JDK 설치

스프링 부트 3.x.x 버전
JDK 17 버전

설치

sudo apt update
sudo apt install openjdk-17-jdk -y
java -version

결과

스프링 부트 프로젝트

예제 파일 다운로드 git clone https://github.com/JSCODE-BOOK/aws-ec2-springboot.git cd aws-ec2-springboot/src/main/resources
서버 접속 환경 설정 vi application.yml
```
server:
port: 80
```

빌드

cd ~/aws-ec2-springboot/ # build를 위한 이동
./gradlew clean build -x test # build 시작
cd build/libs # jar위치 이동
sudo nohup java -jar aws-ec2-springboot-0.0.1-SNAPSHOT.jar & # jar 실행 시작
sudo lsof -i:80 # 실제 실행중인지 확인

확인

혹시 연결할 수 없다고 나온다면 앞에 http 인지 확인 해보세요.

종료 sudo lsof -i:80 결과에서 PID 칼럼을 확인. sudo kill 종료 sudo lsof -i:80 아무것도 나오지 않으면 성공.

보안그룹(Security Group)

보안그룹 이란?

기본적으로 아무나 접근하지 못하도록 규칙을 정해놓을 수 있음.
EC2, RDS등 AWS의 다양한 자원이 수신/발신하는 트래픽을 제어하는 가상 방화벽 역할.

AWS (1)

Tue, 17 Feb 2026 08:05:06 GMT

클라우드 컴퓨팅

서버를 운영하기 위해서는 물리적인 리소스가 필요하다. 이러한 리소스를 직접 구성하여 운영하려면 현재 필요한 리소스나 이후에 확장을 고려한 서버 설계를 필요로 한다.
클라우드 컴퓨팅은 사용자가 물리적인 리소스 구축을 생각하지 않고 초기에 적은 비용으로 서버를 구축할 수 있게 해주는 서비스이다.
하지만 클라우드가 무조건 적으로 좋다는건 아니니 상황에 맞게 사용해야할 것이다.

on-premise vs cloud

On-premise (온프레미스)

장점
- 보안성: 물리적 접근을 제어할 수 있어, 데이터 유출에 대한 위험을 최소화할 수 있습니다. 특히 중요한 데이터를 다루는 경우, 외부와의 연결을 끊어둘 수 있어 더 안전합니다.
- 완전한 통제: 서버와 네트워크, 데이터베이스 등 시스템의 모든 부분을 완전히 제어할 수 있습니다. 변경 사항이나 업데이트도 자유롭게 할 수 있어, 기업의 요구에 맞는 맞춤화가 가능합니다.
- 규제 준수: 특정 산업에서는 법적 규제를 준수해야 하므로, 데이터를 외부 클라우드로 옮길 수 없는 경우가 많습니다. 온프레미스를 사용하면 이러한 규제를 더 쉽게 충족할 수 있습니다.
- 장기적인 비용 절감: 초기 투자 비용은 크지만, 장기적으로는 클라우드 서비스의 지속적인 요금 지불을 피할 수 있어 비용이 절감될 수 있습니다.
단점
- 초기 설치 및 유지관리 비용: 서버와 하드웨어를 구입하고 유지하는 비용이 발생합니다. 이에는 시스템 설치, 전기, 냉각, 관리인력 등이 포함됩니다.
- 확장성 제한: 서버의 용량이 한정적이므로, 트래픽이 급격하게 증가하거나, 더 많은 자원이 필요할 경우 확장이 어려울 수 있습니다. 이를 위해 추가 하드웨어를 구입하거나 업그레이드해야 하므로 비용과 시간이 많이 듭니다.
- 재해 복구 문제: 자연재해나 서버 고장으로 인한 데이터 손실을 방지하기 위해서는 별도의 백업 시스템과 복구 계획이 필요합니다.
- 운영 및 관리의 복잡성: 서버를 운영하기 위해서는 IT 관리 팀이 필요하며, 시스템이 정상적으로 작동하도록 지속적으로 모니터링하고 문제를 해결해야 합니다.

Cloud (클라우드)

장점
- 비용 효율성: 초기 설치 비용이 없고, 필요한 자원을 필요에 따라 확장할 수 있어 매우 유연합니다. 사용한 만큼만 비용을 지불하기 때문에, 예산 관리가 용이합니다.
- 확장성: 클라우드는 빠르게 확장이 가능합니다. 트래픽이 증가하거나 자원이 부족할 경우, 쉽게 용량을 늘릴 수 있습니다.
- 높은 가용성: 클라우드 서비스 제공자는 여러 지역에 데이터 센터를 운영하며, 서비스가 다운되는 일이 거의 없도록 여러 단계의 이중화와 백업을 제공합니다.
- 자동화 및 관리 편의성: 많은 클라우드 서비스는 자동화된 관리 도구와 모니터링 시스템을 제공하여, 서버 유지보수와 관리가 용이합니다. IT 관리자가 직접 모든 것을 신경 쓸 필요가 없습니다.
단점
- 보안 문제: 클라우드에 데이터를 저장하면, 그 데이터에 대한 외부 접근이 있을 수 있습니다. 보안이 잘 관리되지 않으면, 데이터 유출이나 해킹의 위험이 존재합니다.
- 의존성: 클라우드 제공 업체에 의존하게 되며, 서비스 수준이나 가격 정책이 변경될 수 있어 장기적인 계획에 불확실성이 생길 수 있습니다.
- 규제 및 법적 문제: 일부 산업에서는 클라우드를 사용하는 것에 제한이 있을 수 있습니다. 예를 들어, 특정 국가에서 운영되는 데이터 센터에 데이터가 저장되면, 법적으로 문제가 될 수 있습니다.
- 인터넷 의존성: 클라우드 서비스는 인터넷 연결에 의존하므로, 네트워크 장애가 발생하면 서비스 이용에 큰 영향을 미칠 수 있습니다.

AWS 리전

리전이란?

AWS가 전 세계에서 데이터 센터를 클러스터링하는 물리적 위치를 리전이라고 한다. (컴퓨터들을 설치해놓은 물리적 위치)

AI Agent (5) 음성 텍스트 변환-2

Tue, 17 Feb 2026 02:34:29 GMT

기능 추가

pyannote/speaker-diarization-3.1

해당 모델도 음성을 텍스트로 변환해주는 모델인데, 음성에서 나오는 대상을 구분하여 나타낼 수 있다는 차이점이 있다.
사용하기위해서는 HuggingFace에 접속하여, 회원가입 및 로그인 후 우측 상단의 프로필을 클릭하여 Access Token 항목을 들어가서 토큰을 발급해야 한다.(아직 발급하지말고 아래 읽고 진행)
토큰 발급시 https://huggingface.co/pyannote/segmentation-3.0, https://huggingface.co/pyannote/speaker-diarization-3.1, https://huggingface.co/pyannote/speaker-diarization-community-1 에 접속하여 소속 기관 및 웹사이트 정보를 입력해야 하는데, 연습용 이므로 [company/university]부분에 Personal, [WebSite]에 Nothing이라고 적어둔다.
이후, Access Token 메뉴에 들어가서 사진과 같이 보이는 부분을 모두 선택한 후 발급을 마친다.
발급을 마치면 토큰은 저장해야 한다.

코드 작성

예제 코드

# instantiate the pipeline
from pyannote.audio import Pipeline
pipeline = Pipeline.from_pretrained(
"pyannote/speaker-diarization-3.1",
use_auth_token="HUGGINGFACE_ACCESS_TOKEN_GOES_HERE")

run the pipeline on an audio file

diarization = pipeline("audio.wav")

dump the diarization output to disk using RTTM format

with open("audio.rttm", "w") as rttm: diarization.write_rttm(rttm)

- 내가 작성한 코드(예제와 다르니 참고)

instantiate the pipeline

from pyannote.audio import Pipeline import torch pipeline = Pipeline.from_pretrained( "pyannote/speaker-diarization-3.1",token=token )

if torch.cuda.is_available() : pipeline.to(torch.device("cuda")) print('use cuda') else : print("not use cuda")

pydub을 이용한 변환 예시 (설치: pip install pydub)

from pydub import AudioSegment

audio = AudioSegment.from_file(<파일경로>) audio = audio.set_frame_rate(16000).set_channels(1) # 16kHz, 모노로 변환 audio.export("temp_audio.wav", format="wav")

이후 pipeline에는 변환된 파일을 넣습니다.

diarization = pipeline("temp_audio.wav") ann = diarization.speaker_diarization

dump the diarization output to disk using RTTM format

with open("audio.rttm", "w", encoding='utf-8') as rttm: ann.write_rttm(rttm)


- 오류 해결
1. `user_auth_token` 부분도 오류가 발생해서 `token`으로 변경 후 해결.
2. `.mp3` 파일을 그대로 사용하려 했으나 `file resulted in 439895 samples instead of the expected 441000 samples.` 오류가 지속적으로 발생하여 `.wav`파일로 변환하여 진행하였다.
3. `AttributeError: 'DiarizeOutput' object has no attribute 'write_rttm'` 오류 발생. 내가 사용하는 `pyannote.audio` 버전이 `4.0.4` 이다.
해당 버전은 파이프라인이 `DiarizeOutput`객체를 반환한다.
그래서 DiarizeOutput으로 부터 `Annotation` 을 가져올 수 있도록 코드를 수정했다.

- 결과
실제로 아래와 같이 결과가 정상적으로 나오는 걸 볼 수 있다.
![](https://velog.velcdn.com/images/os_js/post/36d20518-8021-4b54-9214-56eaa8a835bc/image.png)


## 화자별 텍스트 나누기
- 지금까지 작성한 내용을 바탕으로 음성파일에서 텍스트를 추출하고, 화자를 나누어 알맞은 텍스트를 csv 형태로 생성하도록 한다.

import os import pandas as pd from pathlib import Path os.environ["PATH"] += os.pathsep + r"D:\systems\ffmpeg-7.1.1-full_build-shared\bin" os.add_dll_directory(str(Path(r"D:\systems\ffmpeg-7.1.1-full_build-shared\bin")))

from dotenv import load_dotenv import torch from transformers import AutoModelForSpeechSeq2Seq, AutoProcessor, pipeline from pyannote.audio import Pipeline from pydub import AudioSegment

from datasets import load_dataset

load_dotenv() token = os.getenv("HF_TOKEN")

def whisper_stt(audio_file_path:str, output_file_path:str = "./output.csv") : device = "cuda:0" if torch.cuda.is_available() else "cpu" torch_dtype = torch.float32

model_id = "openai/whisper-large-v3-turbo"

model = AutoModelForSpeechSeq2Seq.from_pretrained(
    model_id, torch_dtype=torch_dtype, low_cpu_mem_usage=True, use_safetensors=True
)
model.to(device)

processor = AutoProcessor.from_pretrained(model_id)

pipe = pipeline(
    "automatic-speech-recognition",
    model=model,
    tokenizer=processor.tokenizer,
    feature_extractor=processor.feature_extractor,
    torch_dtype=torch_dtype,
    device=device,
    return_timestamps=True
)

# dataset = load_dataset("distil-whisper/librispeech_long", "clean", split="validation")


result = pipe(audio_file_path)
print(result["text"])

df = whisper_to_dataframe(result, output_file_path)

return result, df

def whisper_to_dataframe(result, output_file_path) : start_end_text = []

for chunk in result['chunks'] :
    start = chunk["timestamp"][0]
    end = chunk["timestamp"][1]
    text = chunk["text"].strip()
    start_end_text.append([start, end,text])
    df = pd.DataFrame(start_end_text, columns=["start", "end", "text"])
    df.to_csv(output_file_path, index=False, sep="|")

return df

def speaker_diarization(audio_file_path:str, output_rttm_file_path:str, output_csv_file_path:str) :

pipeline = Pipeline.from_pretrained(
    "pyannote/speaker-diarization-3.1",token=token
)

if torch.cuda.is_available() :
    pipeline.to(torch.device("cuda"))
    print('use cuda')
else :
    print("not use cuda")

audio = AudioSegment.from_file(audio_file_path)
audio = audio.set_frame_rate(16000).set_channels(1) # 16kHz, 모노로 변환
audio.export("temp_audio.wav", format="wav")

# 이후 pipeline에는 변환된 파일을 넣습니다.
diarization = pipeline("temp_audio.wav")
ann = diarization.speaker_diarization  
# dump the diarization output to disk using RTTM format
with open(output_rttm_file_path, "w", encoding='utf-8') as rttm:
    ann.write_rttm(rttm)


df_rttm = pd.read_csv(output_rttm_file_path,
                    sep=' ',
                    header=None,
                    names=['type', 'file', 'chnl', 'start', 'duration', 'C1', 'C2', 'speaker_id', 'C3', 'C4'])

df_rttm['end'] = df_rttm['start'] + df_rttm['duration']
df_rttm['number'] = None

df_rttm.at[0, "number"] = 0

for i in range(1, len(df_rttm)) :
    if df_rttm.at[i, "speaker_id"] != df_rttm.at[i-1, "speaker_id"]:
        df_rttm.at[i, "number"] = df_rttm.at[i-1, "number"] + 1
    else :
        df_rttm.at[i, "number"] = df_rttm.at[i-1, "number"]


df_rttm_grouped = df_rttm.groupby("number").agg(
    start=pd.NamedAgg(column='start', aggfunc='min'),
    end=pd.NamedAgg(column='end', aggfunc='max'),
    speaker_id=pd.NamedAgg(column='speaker_id', aggfunc='first')
)

df_rttm_grouped["duration"] = df_rttm_grouped["end"] + df_rttm_grouped["start"]

df_rttm_grouped.to_csv(
    output_csv_file_path,
    index=False,
    encoding='utf-8'
)

return df_rttm_grouped

def stt_to_rttm( audio_file_path: str, stt_output_file_path: str, rttm_file_path: str, rttm_csv_file_path: str, final_output_csv_file_path: str ):

result, df_stt = whisper_stt(
    audio_file_path, 
    stt_output_file_path
) 

df_rttm = speaker_diarization(
    audio_file_path,
    rttm_file_path,
    rttm_csv_file_path
) 

df_rttm["text"] = "" 

for i_stt, row_stt in df_stt.iterrows(): 
    overlap_dict = {}
    for i_rttm, row_rttm in df_rttm.iterrows(): 
        overlap = max(0, min(row_stt["end"], row_rttm["end"]) - max(row_stt["start"], row_rttm["start"]))
        overlap_dict[i_rttm] = overlap

    max_overlap = max(overlap_dict.values())
    max_overlap_idx = max(overlap_dict, key=overlap_dict.get)

    if max_overlap > 0: 
        df_rttm.at[max_overlap_idx, "text"] += row_stt["text"] + "\n"

df_rttm.to_csv(
    final_output_csv_file_path,
    index=False,    # 인덱스는 저장하지 않음
    sep='|',
    encoding='utf-8'
)  # ④
return df_rttm

if name == "main" :

audio_file_path = r"초기 입력 음성 데이터"
stt_otuput_file_path = r"./stt.csv"
rttm_file_path = "./stt.rttm"
rttm_csv_file_path='stt_rttm.csv'
final_csv_file_path = "final.csv"

# result, df = whisper_stt(audio_file_path, "./stt.csv")
# df_rttm = speaker_diarization(audio_file_path, rttm_file_path, rttm_csv_file_path)
# print(df_rttm)

df_rttm = stt_to_rttm(
    audio_file_path,
    stt_otuput_file_path,
    rttm_file_path,
    rttm_csv_file_path,
    final_csv_file_path
)

print(df_rttm)

- 결과
![](https://velog.velcdn.com/images/os_js/post/0ba0e189-cca3-426e-b6f6-45ce6c8b30ea/image.png)

AI Agent (5) 음성 텍스트 변환-1

Mon, 16 Feb 2026 08:31:47 GMT

openai의 whisper API

코드 작성

from openai import OpenAI
from dotenv import load_dotenv
import os

load_dotenv()
api_key = os.getenv("OPEN_API_KEY")
client = OpenAI(api_key=api_key)

audio_file = <파일 경로>

with open(audio_file, 'rb') as audio :
    transcription = client.audio.transcriptions.create(
        model='whisper-1',
        file=audio
    )
print(transcription)

HugginFace openai/whisper-large-v3-turbo

모델 사용하기

https://huggingface.co/ 에 접속하여 openai/whisper-large-v3-turbo 검색.
예제를 통해서 실행하면 되지만 기본적으로 ffmpeg이 설치되어 있어야함.
https://www.gyan.dev/ffmpeg/builds/ 에 접속하여 ffmpeg-release-full-shared.7z 다운로드
압축해제후 import torch 전 라인에 os.add_dll_directory(str(Path(<압축 해제한 ffmpeg 폴더의 bin 폴더 경로>))) 추가.

파이썬 3.8 버전부터는 Windows 보안 강화로 인해 os.environ['PATH']에 경로를 추가하는 것만으로는 DLL 파일을 불러올 수 없습니다. 경로내 dll파일이 존재해야합니다.
huggingface의 예제를 그대로 가져와 코드를 추가후. 실행합니다.

혹시, 오류가 발생하지 않으나 결과값이 비어있거나 이상하게 나온다면 torch_dtype = torch.float16 if torch.cuda.is_available() else torch.float32 부분에서 torch.float32로 변경하여 사용해보시기 바랍니다.

정상 작동 코드

import os
from pathlib import Path
os.environ["PATH"] += os.pathsep + r""
os.add_dll_directory(str(Path(r"")))
import torch
from transformers import AutoModelForSpeechSeq2Seq, AutoProcessor, pipeline
from datasets import load_dataset

device = "cuda:0" if torch.cuda.is_available() else "cpu" torch_dtype = torch.float32

model_id = "openai/whisper-large-v3-turbo"

model = AutoModelForSpeechSeq2Seq.from_pretrained( model_id, torch_dtype=torch_dtype, low_cpu_mem_usage=True, use_safetensors=True ) model.to(device)

processor = AutoProcessor.from_pretrained(model_id)

pipe = pipeline( "automatic-speech-recognition", model=model, tokenizer=processor.tokenizer, feature_extractor=processor.feature_extractor, torch_dtype=torch_dtype, device=device, return_timestamps=True )

dataset = load_dataset("distil-whisper/librispeech_long", "clean", split="validation") sample = dataset[0]["audio"]

result = pipe(sample) print(result["text"])


### csv로 저장
- 이렇게 뽑아낸 결과를 통해서 언제 어떤 말을 했는지 알 수 있다.
- csv로 저장해보자.

start_end_text = []

for chunk in result["chunks"] : start = chunk["timestamp"][0] end = chunk["timestamp"][1] text = chunk["text"] start_end_text.append([start, end, text])

import pandas as pd

df = pd.DataFrame(start_end_text, columns=["start", 'end', 'text']) df.to_csv("lsy_audio_2023_58s.csv", index=False, sep="|") display(df)

```

결과

오류 해결

torchcodec 호환성 문제.
다른 기능이 정상적으로 동작하지 않아. torch 버전을 2.8.0 으로 낮췄다. 당연히 다른 것들도..

호환성 참고 : https://pytorch.kr/get-started/compatibility/
여기서 계속 ffmpeg 오류가 발생한 것이다.
내가 사용중인 ffmpeg 버전이 8.0.1 이었고, 다른 곳에서 보니 7.1.1 버전으로 사용했다고 해서 ffmpeg을 7.1.1 버전으로 설치후 동작했더니 정상 작동하였다.

이슈 참고 : https://github.com/meta-pytorch/torchcodec/issues/1108 https://github.com/meta-pytorch/torchcodec/issues/912#issuecomment-3450048176

AI Agent(4) 매우 간단한 챗봇

Mon, 16 Feb 2026 08:06:09 GMT

챗봇 만들기

OpenAI API를 활용하여 챗봇을 만든다.

간단 예제

코드 작성

from openai import OpenAI
import os
from dotenv import load_dotenv

load_dotenv()

client = OpenAI(api_key=os.environ.get("OPEN_API_KEY"))

def chatbot_response(user_message: str) : result = client.responses.create(model="gpt-5-mini", input=user_message) return result

if name == "main" : while True : user_message = input("메시지: ") if user_message.lower() == "exit" : print("대화를 종료합니다.")

        break



    result = chatbot_response(user_message)
    print("챗봇 : " + result.output_text)

- 결과
![](https://velog.velcdn.com/images/os_js/post/2119041e-8867-472a-b910-228811126a17/image.png)
첨부한 결과 이미지와 같이 위 코드로는 챗봇이 이전 대화를 기억하지 못한다.

## 대화 기억
- id를 사용하여 이전에 나누었던 대화를 기억할 수 있도록 코드 작성

from openai import OpenAI import os from dotenv import load_dotenv

load_dotenv()

client = OpenAI(api_key=os.environ.get("OPEN_API_KEY"))

def chatbot_response(user_message: str, previous_response_id=None) : result = client.responses.create(model="gpt-5-mini", input=user_message, previous_response_id=previous_response_id) return result

if name == "main" : previous_response_id = None while True : user_message = input("메시지: ") if user_message.lower() == "exit" : print("대화를 종료합니다.")

        break



    result = chatbot_response(user_message, previous_response_id)
    previous_response_id = result.id
    print("챗봇 : " + result.output_text)

- 결과
![](https://velog.velcdn.com/images/os_js/post/9123c24c-ed0f-4691-a4ec-7edffdd8c1d4/image.png)

- 이제까지 API를 사용한 이력에 대해서는 
https://platform.openai.com/logs 를 통해서 확인 가능하다.

### 어린왕자 페르소나 추가

from openai import OpenAI from dotenv import load_dotenv

import os

load_dotenv() api_key = os.environ.get("OPEN_API_KEY")

openai_client = OpenAI(api_key=api_key)

어린왕자 페르소나

LITTLE_PRINCE_PERSONA = """ 당신은 생텍쥐페리의 '어린 왕자'입니다. 다음 특성을 따라주세요:

순수한 관점으로 세상을 바라봅니다.
"어째서?"라는 질문을 자주 하며 호기심이 많습니다.
철학적 통찰을 단순하게 표현합니다.
"어른들은 참 이상해요"라는 표현을 씁니다.
B-612 소행성에서 왔으며 장미와의 관계를 언급합니다.
여우의 "길들임"과 "책임"에 대한 교훈을 중요시합니다.
"중요한 것은 눈에 보이지 않아"라는 문장을 사용합니다.
공손하고 친절한 말투를 사용합니다.
비유와 은유로 복잡한 개념을 설명합니다.

항상 간결하게 답변하세요. 길어야 2-3문장으로 응답하고, 어린 왕자의 순수함과 지혜를 담아내세요. 복잡한 주제도 본질적으로 단순화하여 설명하세요. """

def chatbot_response(user_message: str, previous_id = None) :

result = openai_client.responses.create(
    model = "gpt-5-mini",
    reasoning={"effort" : "low"},
    instructions=LITTLE_PRINCE_PERSONA,
    input=user_message,
    previous_response_id=previous_id
)

return result

if name == "main" : previous_id = None while True : user_message = input("메시지 : ") if user_message.lower() == "exit": break

    result = chatbot_response(user_message, previous_id)
    previous_id = result.id

    print(f"챗봇 응답 : {result.output_text}")

```

instructions 옵션을 통해서 시스템 프롬프트를 추가할 수 있게 해준다. input을 통해서 넣어줄 수 있지만 그건 토큰을 사용하기에 instrctions에 넣는걸 추천합니다.

AI Agent(3) API 호출 개선

Mon, 16 Feb 2026 08:05:59 GMT

비동기 호출

이전 api 호출을 통한 AI응답을 받는 코드를 작성했었다. 그러나, 한 번의 응답을 받기 위해서는 짧지 않은 시간이 소요된다는걸 알게되었을 것이다. 하나의 질문에 대해서만 응답이 필요하다면 상관 없지만 여러 질문을 하거나 서비스로 제공하여 사용자가 많아진다면 질문의 수 만큼 대기시간이 늘어나게 된다.
이러한 문제를 개선하기위해 비동기로 호출할 수 있도록 코드를 재 작성하자.
```
import asyncio
import os
from dotenv import load_dotenv
```

from openai import AsyncOpenAI

load_dotenv()

openai_client = AsyncOpenAI(api_key=os.environ.get("OPEN_API_KEY"))

async def call_async_openai(prompt:str, model:str="gpt-5-mini") -> str : response = await openai_client.chat.completions.create( model=model, messages=[{"role":"user", "content":prompt}] )

return response.choices[0].message.content

async def main(): print("동시에 2번 API 호출하기") prompt = "비동기 프로그래밍에 대해 두세 문장으로 설명해주세요."

# 비동기 함수 호출시 코루틴 객체 반환(실행은 안됨)
openai_task = call_async_openai(prompt)
openai_task2 = call_async_openai(prompt)

# 두 API 호출 병려렬로 실행하고 완료될 때까지 대기.    
openai_response, openai_response2 = await asyncio.gather(openai_task, openai_task2)
print(f"OpenAI 응답 1 : {openai_response}")
print(f"OpenAI 응답 2 : {openai_response2}")

if name == "main" : asyncio.run(main()) # 비동기 메인 함수를 이벤트 루프에서 실행

- 간단하게 asyncio를 통한 비동기 호출을 만들었다.
실행해보면 응답시간이 질문한 개수만큼 늘어나지 않는다는걸 알 수 있다.

# 오류 처리
- 당연히 API호출이 모두 성공할 수 없다. 그렇다면 실패했을 때의 로직도 필요하다.
- 모듈 설치
```pip install tenacity```
- 코드 작성 (위에서 작성했던 코드에 추가된 버전)

import asyncio import os, logging, random from dotenv import load_dotenv from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type from openai import AsyncOpenAI

logging

logging.basicConfig(level=logging.INFO) logger = logging.getLogger(name)

load_dotenv()

openai_client = AsyncOpenAI(api_key=os.environ.get("OPEN_API_KEY"))

@retry( stop=stop_after_attempt(3), # 최대 3번시도 wait=wait_exponential(multiplier=1, min=2, max=10), # 지수 백오프 : 2초, 4초, 8초.... retry=retry_if_exception_type(), # 모든 예외에 대해 재시도 before_sleep=lambda retry_state : logger.warning( f"API 호출 실패: {retry_state.outcome.exception()}, {retry_state.attempt_number} 번쨰 시도중..." )

) async def call_async_openai(prompt:str, model:str="gpt-5-mini") -> str :

logger.info(f"OpenAI API 호출 시작 : {model}")

await simulate_random_failure()

response = await openai_client.chat.completions.create(
    model=model,
    messages=[{"role":"user", "content":prompt}]
)

logger.info(f"OpenAI API 호출  성공 ")

return response.choices[0].message.content

인위적 실패 생성 함수

async def simulate_random_failure() : if random.random() < 0.5 : logger.warning("인위적 API 호출 실패 생성") raise ConnectionError("인위적 연결 오류 발생")

await asyncio.sleep(random.uniform(0.1, 0.5))

async def main(): try : print("동시에 2번 API 호출하기") prompt = "비동기 프로그래밍에 대해 두세 문장으로 설명해주세요."

    # 비동기 함수 호출시 코루틴 객체 반환(실행은 안됨)
    openai_task = call_async_openai(prompt)
    openai_task2 = call_async_openai(prompt)

    # 두 API 호출 병려렬로 실행하고 완료될 때까지 대기.    
    openai_response, openai_response2 = await asyncio.gather(openai_task, openai_task2)
    print(f"OpenAI 응답 1 : {openai_response}")
    print(f"OpenAI 응답 2 : {openai_response2}")
except Exception as e:
    logger.error(f"처리되지 않은 오류 발생 {e} ")

if name == "main" : asyncio.run(main()) # 비동기 메인 함수를 이벤트 루프에서 실행

```

실행시켜보면 실패 되었을때, 바로 종료되지 않고 retry 어노테이션에 설정된 값과 같이 재시도를 진행하는걸 확인할 수 있다.

AI Agent (2) API

Fri, 13 Feb 2026 12:18:18 GMT

API

Chat Completions API

사용자 입력에 대한 직접적인 응답 생성
대화 문맥을 개발자가 직접 관리.(새로운 대화 시작시 이전 대화 내용을 개발자가 직접 제공해야함)
실제 사용 예시:
- 고객 지원: 고객의 질문에 대해 실시간으로 응답하는 챗봇 시스템.
- 대화형 학습 시스템: 학생이 질문을 던지면, 모델이 적절한 답변을 제공.
- AI 기반 비서: 사용자의 요청에 맞춰 정보를 제공하거나 작업을 처리하는 비서형 응답.

사용

python 모듈 설치

pip install openai==1.70.0
pip install dotenv

파일 작성

import os
from dotenv import load_dotenv
from openai import OpenAI

.env파일에서 환경변수 로드

load_dotenv()

api_key = os.environ.get('OPEN_API_KEY') client = OpenAI(api_key=api_key)

def get_chat_completion(prompt, model="gpt-5-mini") : # OpenAI 챗 컴플리션 API를 사용하여 AI의 응답을 받는 함수

response = client.chat.completions.create(
    model=model,
    messages=[
        {"role" : "system", "content" : "당신은 친절하고 도움이 되는 AI 비서 입니다."},
        {"role":"user", "content":prompt}
    ]
)

return response.choices[0].message.content

if name == "main" : user_prompt = input("AI에게 물어볼 질문을 입력하세요: ") response = get_chat_completion(user_prompt) print("\nAI 응답 : ") print(response)

- 결과
![](https://velog.velcdn.com/images/os_js/post/276216ac-3726-48df-9578-98e8b75bbf1a/image.png)

## Responses API
- 복잡한 AI 어시스턴트 구축을 지원.
- 대화 스레드를 통해 자동으로 문맥을 관리함.
- 웹 검색, 파일검색, 컴퓨터 사용등 다양한 내장 도구 지원.

- 실제 사용 예시:
    - 자율적인 AI 에이전트 개발
    - 멀티모달 입력이 필요한 애플리케이션
    - 대화 상태 관리가 필요한 복잡한 대화형 서비스
    - 웹 검색, 파일 분석 등 외부 데이터 활용이 필요한 시스템

### 사용

import os from dotenv import load_dotenv from openai import OpenAI

.env파일에서 환경변수 로드

load_dotenv()

api_key = os.environ.get('OPEN_API_KEY') client = OpenAI(api_key=api_key)

def get_reponses(prompt, model="gpt-5-mini") : # OpenAI responses API를 사용하여 AI의 응답을 받는 함수

response = client.responses.create(
    model=model,
    tools=[{"type" : "web_search_preview"}], # 웹 검색 도구 활성화
    input=prompt
)

return response.output_text

if name == "main" : prompt = 'https://platform.openai.com/docs/api-reference/responses/create 를 읽어서 리스폰스에 대해 요약 정리해주세요' response = get_reponses(prompt) print("\nAI 응답 : ") print(response)


 - 결과
 ![](https://velog.velcdn.com/images/os_js/post/50b7084a-fff3-4f5d-9aa7-4fdf01f4f3f6/image.png)

## Stream
- 이전 예제는 AI가 응답한 내용을 한 번에 보여주는 방식이었으나, 스트리밍을 통해서 결과값을 바로바로 보여주는 방식도 존재.
- 모듈 설치
``` pip install rich```
- 코드 작성

import os from dotenv import load_dotenv from openai import OpenAI import rich

.env파일에서 환경변수 로드

load_dotenv()

api_key = os.environ.get('OPEN_API_KEY') client = OpenAI(api_key=api_key)

default_model="gpt-5-mini" def stream_chat_completion(prompt, model=default_model) : # OpenAI 챗 컴플리션 API를 사용하여 AI의 응답을 받는 함수

response = client.chat.completions.create(
    model=model,
    messages=[
        {"role" : "system", "content" : "당신은 친절하고 도움이 되는 AI 비서 입니다."},
        {"role":"user", "content":prompt}            
    ],
    stream=True
)

for chunk in response :
    content = chunk.choices[0].delta.content
    if content is not None:
        print(content, end="")

def stream_response(prompt, model=default_model) : with client.responses.stream(model=model, input=prompt) as stream : for event in stream: if "output_text" in event.type : rich.print(event)

rich.print(stream.get_final_response())

if name == "main" : stream_chat_completion("스트리밍이 무엇인가요?") stream_response("저녁 메뉴 추천 10글자로 제한") ```

mqtt HA 설정(kubernetes)

Fri, 13 Feb 2026 12:11:43 GMT

mqtt setup.yml

# 1. Longhorn StorageClass 정의 (레플리카 3개 설정)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: emqx-longhorn-sc
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
numberOfReplicas: "3"      # 레플리카 수를 3으로 명시 (노드가 3개이므로 최적)
staleReplicaTimeout: "30"  # 비정상 레플리카 제거 대기 시간(분)
fromBackup: ""

apiVersion: v1 kind: ConfigMap metadata: name: tcp-services namespace: ingress-nginx data: "1883": "default/emqx-service:1883"

2. RBAC (EMQX 클러스터 검색용 권한)

apiVersion: v1 kind: ServiceAccount metadata: name: emqx-sa

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: emqx-role rules:

apiGroups: [""] resources: ["endpoints"] verbs: ["get", "list", "watch"]

apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: emqx-rb subjects:

kind: ServiceAccount name: emqx-sa roleRef: kind: Role name: emqx-role apiGroup: rbac.authorization.k8s.io

3. Service (Discovery 및 통신용)

apiVersion: v1 kind: Service metadata: name: emqx-headless spec: clusterIP: None ports: - name: cluster-rpc port: 5369 selector: app: emqx

apiVersion: v1 kind: Service metadata: name: emqx-service spec: ports: - name: mqtt port: 1883 - name: dashboard port: 18083 selector: app: emqx

4. StatefulSet (EMQX + 정의한 StorageClass 사용)

apiVersion: apps/v1 kind: StatefulSet metadata: name: emqx spec: serviceName: "emqx-headless" replicas: 3 selector: matchLabels: app: emqx template: metadata: labels: app: emqx spec: # --- 이 부분을 반드시 추가하세요 --- securityContext: runAsUser: 1000 runAsGroup: 1000 fsGroup: 1000 # Longhorn 볼륨의 소유권을 emqx 유저 권한으로 강제 조정 # ----------------------------- serviceAccountName: emqx-sa containers: - name: emqx image: emqx/emqx:5.3.0 env: - name: EMQX_CLUSTER__DISCOVERY_STRATEGY value: "k8s" - name: EMQX_CLUSTER__K8S__ADDRESS_TYPE value: "hostname" - name: EMQX_CLUSTER__K8S__NAMESPACE value: "default" - name: EMQX_CLUSTER__K8S__SERVICE_NAME value: "emqx-headless" - name: EMQX_CLUSTER__K8S__SUFFIX value: "svc.cluster.local" volumeMounts: - name: emqx-data mountPath: /opt/emqx/data volumeClaimTemplates:

metadata: name: emqx-data spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "emqx-longhorn-sc" # 위에서 정의한 SC 사용 resources:
```
requests:
  storage: 1Gi
```


2. 기존 ingress  파일 변경

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: longhorn-ingress namespace: longhorn-system annotations: kubernetes.io/ingress.class: nginx spec: ingressClassName: nginx rules:

host: longhorn.local http: paths:
- path: / pathType: Prefix backend: service:
```
name: longhorn-frontend
port:
  number: 80
```

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: default-ingress namespace: default annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/session-cookie-name: "route" nginx.ingress.kubernetes.io/session-cookie-hash: "sha1" spec: ingressClassName: nginx rules:

host: influxdb.local http: paths:

path: / pathType: Prefix backend: service:

name: influxdb-service # ▒▒▒▒ ▒▒▒▒ ▒▒▒▒ ▒̸▒
port:
  number: 8086

host: mqtt.local http: paths:

path: / pathType: Prefix backend: service:

name: emqx-service # ▒▒▒▒ ▒▒▒▒ ▒▒▒▒ ▒̸▒
port:
  number: 18083

```kubectl apply -f 파일.yml``` 하면 적용됨.
3. ingress-nginx-controller 서비스 파일 백업 및 수정
```kubectl get svc ingress-nginx-controller -n ingress-nginx -o yaml > ingress-svc-update.yaml```

apiVersion: v1 kind: Service metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app.kubernetes.io/component":"controller","app.kubernetes.io/instance":"ingress-nginx","app.kubernetes.io/name":"ingress-nginx","app.kubernetes.io/part-of":"ingress-nginx","app.kubernetes.io/version":"1.8.1"},"name":"ingress-nginx-controller","namespace":"ingress-nginx"},"spec":{"ipFamilies":["IPv4"],"ipFamilyPolicy":"SingleStack","ports":[{"appProtocol":"http","name":"http","port":80,"protocol":"TCP","targetPort":"http"},{"appProtocol":"https","name":"https","port":443,"protocol":"TCP","targetPort":"https"}],"selector":{"app.kubernetes.io/component":"controller","app.kubernetes.io/instance":"ingress-nginx","app.kubernetes.io/name":"ingress-nginx"},"type":"NodePort"}} creationTimestamp: "2026-01-24T11:27:50Z" labels: app.kubernetes.io/component: controller app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx app.kubernetes.io/version: 1.8.1 name: ingress-nginx-controller namespace: ingress-nginx resourceVersion: "55756" uid: cacbc931-e466-4a19-a1cf-d6a59e5f3053 spec: clusterIP: 10.100.46.190 clusterIPs:

10.100.46.190 externalTrafficPolicy: Cluster internalTrafficPolicy: Cluster ipFamilies:
IPv4 ipFamilyPolicy: SingleStack ports:
appProtocol: http name: http nodePort: 32142 port: 80 protocol: TCP targetPort: http
appProtocol: https name: https nodePort: 31171 port: 443 protocol: TCP targetPort: https
추가
name: mqtt port: 1883 targetPort: 1883 protocol: TCP nodePort: 32257 #외부 노출 포트
추가 끝
selector: app.kubernetes.io/component: controller app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/name: ingress-nginx sessionAffinity: None type: NodePort status: loadBalancer: {}

# 3. 수정된 설정 반영
kubectl apply -f 파일이름.yaml

# 4. 포트가 정상적으로 열렸는지 확인
kubectl get svc ingress-nginx-controller -n ingress-nginx

haproxy 접속 설정.

frontend mqtt_dash
 bind *:18083
 mode http
 http-request set-header Host mqtt.local

 default_backend ingress_nginx

frontend mqtt_front bind *:1883 mode tcp

default_backend mqtt_backend

2. MQTT 전용 백엔드 (포트 번호: 32257)

backend mqtt_backend mode tcp balance roundrobin # kubectl에서 확인한 NodePort 32257을 사용합니다. server node3 10.0.2.4:32257 check #위에서 설정한 node port server node2 10.0.2.6:32257 check server node1 10.0.2.5:32257 check

frontend influx_front bind *:8086 mode http

# [핵심] 외부에서 IP로 들어와도 Ingress가 알아먹을 수 있게 이름표를 갈아끼웁니다.
http-request set-header Host influxdb.local

default_backend ingress_nginx

frontend longhorn_front bind *:80 mode http

# [핵심] 80포트로 들어오면 롱혼 이름표를 붙입니다.
http-request set-header Host longhorn.local

default_backend ingress_nginx

backend ingress_nginx mode http balance roundrobin # 각 노드(VM)의 실제 IP와 확인한 NodePort를 적습니다. server node3 10.0.2.4:32142 check server node2 10.0.2.6:32142 check server node1 10.0.2.5:32142 check

frontend k8s-api bind 10.0.2.10:6444 default_backend k8s-masters

backend k8s-masters balance roundrobin server node3 10.0.2.4:6443 check server node1 10.0.2.5:6443 check server node2 10.0.2.6:6443 check



6. TCP 설정 옵션 주입
- 명령을 통한 주입
```kubectl patch deployment ingress-nginx-controller -n ingress-nginx --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--tcp-services-configmap=ingress-nginx/tcp-services"}]'```
- 파일을 통한 주입
```kubectl get deployment -n ingress-nginx ingress-nginx-controller -o yaml > ingress-controller.yaml```
 여기에서 뽑아낸 ingress-controller.yml 파일을 수정후 apply를 통해 시작

apiVersion: apps/v1 kind: Deployment metadata: name: ingress-nginx-controller namespace: ingress-nginx spec:

... (생략) ...

template: spec: containers: - name: controller image: ... args: # <--- 바로 여기입니다! - /nginx-ingress-controller - --election-id=ingress-nginx-leader - --controller-class=k8s.io/ingress-nginx - --ingress-class=nginx - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller # 아래 줄을 리스트의 맨 마지막이나 적당한 곳에 추가하세요. - --tcp-services-configmap=ingress-nginx/tcp-services


- 적용 확인
```kubectl describe deploy -n ingress-nginx ingress-nginx-controller | grep -A 7 "Args"```
- 결과확인

인그레스 컨트롤러 포드 이름 다시 가져오기

INGRESS_POD=$(kubectl get pods -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx -o jsonpath='{.items[0].metadata.name}')

포드 내부에서 1883 리스닝 확인

kubectl exec -n ingress-nginx $INGRESS_POD -- netstat -tuln | grep 1883

```

1883에 대한 정보가 떠야한다.

AI Agent (1) GhatGPT API Key 발급

Fri, 13 Feb 2026 11:06:36 GMT

AI Agent 개발

AI Agent 개발 시작.

ChatGPT API Key 발급

https://openai.com/ko-KR/ 접속
api key 생성
API key를 발급받은 후 저장해 놓으시길 바랍니다. 만약, 저장을 못하셨다면 재발급 받으세요.
GPT Pro 또는 Plus 구독을 했더라도 API 키 사용을 위해서는 반드시 별도의 크레딧 충전이 필요합니다. https://platform.openai.com/settings/organization/billing/overview
위 화면에서 0.0달러로 되어있다면 최소 5달러를 충전해야 API 사용 가능.

kubernetes(influxdb HA)

Sun, 25 Jan 2026 12:16:38 GMT

haproxy 설정 파일 변경(각각의 서비스 구분을 위한 header 변경)

frontend influx_front
 bind *:8086
 mode http

 # [핵심] 외부에서 IP로 들어와도 Ingress가 알아먹을 수 있게 이름표를 갈아끼웁니다.
 http-request set-header Host influxdb.local

 default_backend ingress_nginx

frontend longhorn_front bind *:80 mode http

# [핵심] 80포트로 들어오면 롱혼 이름표를 붙입니다.
http-request set-header Host longhorn.local

default_backend ingress_nginx

backend ingress_nginx mode http balance roundrobin # SERVERID라는 쿠키를 삽입하여 한 번 접속한 노드로 계속 고정합니다. cookie SERVERID insert indirect nocache # 각 노드(VM)의 실제 IP와 확인한 NodePort를 적습니다. server node3 10.0.2.4:32142 check server node2 10.0.2.6:32142 check server node1 10.0.2.5:32142 check

frontend k8s-api bind 10.0.2.10:6444 default_backend k8s-masters

backend k8s-masters balance roundrobin server node3 10.0.2.4:6443 check server node1 10.0.2.5:6443 check server node2 10.0.2.6:6443 check


2. influxdb(telegraf)

apiVersion: v1 kind: ConfigMap metadata: name: telegraf-config labels: app: influxdb-ha data: telegraf.conf: | [agent] interval = "10s" round_interval = true

[[inputs.influxdb_v2_listener]]
  ## 외부에서 데이터를 받을 포트 (Relay 역할)
  service_address = ":8080"

[[outputs.influxdb_v2]]
  ## 첫 번째 InfluxDB 노드 (StatefulSet 0번)
  urls = ["http://influxdb-0.influxdb-service:8086"]
  token = "${INFLUX_TOKEN}"
  organization = "my-org"
  bucket = "my-bucket"

[[outputs.influxdb_v2]]
  ## 두 번째 InfluxDB 노드 (StatefulSet 1번)
  urls = ["http://influxdb-1.influxdb-service:8086"]
  token = "${INFLUX_TOKEN}"
  organization = "my-org"
  bucket = "my-bucket"

[[outputs.influxdb_v2]]
  ## 두 번째 InfluxDB 노드 (StatefulSet 1번)
  urls = ["http://influxdb-2.influxdb-service:8086"]
  token = "${INFLUX_TOKEN}"
  organization = "my-org"
  bucket = "my-bucket"

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: longhorn-influxdb provisioner: driver.longhorn.io allowVolumeExpansion: true parameters:

Longhorn에서 데이터를 몇 군데 복제할지 결정 (보통 3 권장)

numberOfReplicas: "3"

데이터 기록이 완료되었다고 판단하는 기준

staleReplicaTimeout: "30"

노드 장애 시 데이터 자동 재균형

fromBackup: ""

apiVersion: v1 kind: Service metadata: name: influxdb-service spec:

StatefulSet의 개별 Pod에 접근하기 위해 Headless Service 권장

clusterIP: None #내부에서만 ㅅ쓸때 설정

type: NodePort #외부 포트를 열떄 필요. selector: app: influxdb ports: - name: influxdb port: 8086 targetPort: 8086 nodePort: 30086

apiVersion: v1 kind: Service metadata: name: influxdb-write-proxy spec:

쓰기 전용 엔드포인트 (Telegraf Relay로 연결)

selector: app: telegraf ports: - name: write port: 8080 targetPort: 8080

apiVersion: apps/v1 kind: StatefulSet metadata: name: influxdb spec: serviceName: "influxdb-service" replicas: 1 #두개이상시 충돌 selector: matchLabels: app: influxdb template: metadata: labels: app: influxdb spec:
affinity: podAntiAffinity: # required... 는 "무조건 지켜라"라는 뜻입니다. (Hard anti-affinity) # 만약 노드가 2개뿐인데 replicas가 3이면, 1개 Pod는 배포되지 않고 Pending 상태가 됩니다. requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - influxdb topologyKey: "kubernetes.io/hostname"
containers: - name: influxdb image: influxdb:2.7 # 2.x 최신 안정 버전 ports: - containerPort: 8086 env: # 초기 설정 자동화 (최초 실행 시에만 적용) - name: DOCKER_INFLUXDB_INIT_MODE value: setup - name: DOCKER_INFLUXDB_INIT_USERNAME value: - name: DOCKER_INFLUXDB_INIT_PASSWORD value: - name: DOCKER_INFLUXDB_INIT_ORG value: my-org - name: DOCKER_INFLUXDB_INIT_BUCKET value: my-bucket - name: DOCKER_INFLUXDB_INIT_ADMIN_TOKEN value: my-super-secret-token volumeMounts: - name: influxdb-data mountPath: /var/lib/influxdb2 volumeClaimTemplates: - metadata: name: influxdb-data spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "longhorn-influxdb" resources: requests: storage: 2Gi # 스토리지 용량 설정

apiVersion: apps/v1 kind: Deployment metadata: name: telegraf-relay spec: replicas: 3 selector: matchLabels: app: telegraf template: metadata: labels: app: telegraf spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - telegraf topologyKey: "kubernetes.io/hostname" containers: - name: telegraf image: telegraf:latest ports: - containerPort: 8080 env: # ConfigMap에서 사용할 토큰 (InfluxDB와 동일하게 설정) - name: INFLUX_TOKEN value: my-super-secret-token volumeMounts: - name: config mountPath: /etc/telegraf/telegraf.conf subPath: telegraf.conf volumes: - name: config configMap: name: telegraf-config


3. ingress 설정 파일

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: longhorn-ingress namespace: longhorn-system annotations: kubernetes.io/ingress.class: nginx spec: ingressClassName: nginx rules:

host: longhorn.local http: paths:
- path: / pathType: Prefix backend: service:
```
name: longhorn-frontend
port:
  number: 80
```

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: default-ingress namespace: default annotations: kubernetes.io/ingress.class: nginx #influxdb 대시보드 접속시 세션의 유실 문제를 해결하기 위해 아래 3줄 추가 nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/session-cookie-name: "route" nginx.ingress.kubernetes.io/session-cookie-hash: "sha1" spec: ingressClassName: nginx rules:

host: influxdb.local http: paths:

path: / pathType: Prefix backend: service:

name: influxdb-service # 이전에 만든 서비스 이름
port:
  number: 8086


### 문제발생
- influxdb가 떠있는 노드를 강제로 종료시켰을때, Pod가 끝나지 않고 계속 terminating 상태이다.

influxdb statefulset spec 내부에 추가

tolerations:

key: "node.kubernetes.io/unreachable" operator: "Exists" effect: "NoExecute" tolerationSeconds: 30 # 30초만 응답 없으면 바로 다른 노드로 이사 준비
key: "node.kubernetes.io/not-ready" operator: "Exists" effect: "NoExecute" tolerationSeconds: 30

정상 작동 setup yml 파일

apiVersion: v1
kind: ConfigMap
metadata:
name: telegraf-config
labels:
 app: influxdb-ha
data:
telegraf.conf: |
 [agent]
   interval = "10s"
   round_interval = true

 [[inputs.influxdb_v2_listener]]
   ## 외부에서 데이터를 받을 포트 (Relay 역할)
   service_address = ":8080"

 [[outputs.influxdb_v2]]
   ## 첫 번째 InfluxDB 노드 (StatefulSet 0번)
   urls = ["http://influxdb-0.influxdb-service:8086"]
   token = "${INFLUX_TOKEN}"
   organization = "my-org"
   bucket = "my-bucket"

 [[outputs.influxdb_v2]]
   ## 두 번째 InfluxDB 노드 (StatefulSet 1번)
   urls = ["http://influxdb-1.influxdb-service:8086"]
   token = "${INFLUX_TOKEN}"
   organization = "my-org"
   bucket = "my-bucket"

 [[outputs.influxdb_v2]]
   ## 두 번째 InfluxDB 노드 (StatefulSet 1번)
   urls = ["http://influxdb-2.influxdb-service:8086"]
   token = "${INFLUX_TOKEN}"
   organization = "my-org"
   bucket = "my-bucket"

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: longhorn-influxdb provisioner: driver.longhorn.io allowVolumeExpansion: true parameters:

Longhorn에서 데이터를 몇 군데 복제할지 결정 (보통 3 권장)

numberOfReplicas: "3"

데이터 기록이 완료되었다고 판단하는 기준

staleReplicaTimeout: "30"

노드 장애 시 데이터 자동 재균형

fromBackup: ""

apiVersion: v1 kind: Service metadata: name: influxdb-service spec:

StatefulSet의 개별 Pod에 접근하기 위해 Headless Service 권장

clusterIP: None #내부에서만 ㅅ쓸때 설정

type: NodePort #외부 포트를 열떄 필요. selector: app: influxdb ports: - name: influxdb port: 8086 targetPort: 8086 nodePort: 30086

apiVersion: v1 kind: Service metadata: name: influxdb-write-proxy spec:

쓰기 전용 엔드포인트 (Telegraf Relay로 연결)

selector: app: telegraf ports: - name: write port: 8080 targetPort: 8080

apiVersion: apps/v1 kind: StatefulSet metadata: name: influxdb spec: serviceName: "influxdb-service" replicas: 1 # 2개의 노드를 유지 (이중화) selector: matchLabels: app: influxdb template: metadata: labels: app: influxdb spec:
tolerations: - key: "node.kubernetes.io/unreachable" operator: "Exists" effect: "NoExecute" tolerationSeconds: 30 # 10초만 응답 없으면 바로 다른 노드로 이사 준비 - key: "node.kubernetes.io/not-ready" operator: "Exists" effect: "NoExecute" tolerationSeconds: 30 affinity: podAntiAffinity: # required... 는 "무조건 지켜라"라는 뜻입니다. (Hard anti-affinity) # 만약 노드가 2개뿐인데 replicas가 3이면, 1개 Pod는 배포되지 않고 Pending 상태가 됩니다. requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - influxdb topologyKey: "kubernetes.io/hostname"
containers: - name: influxdb image: influxdb:2.7 # 2.x 최신 안정 버전 ports: - containerPort: 8086 env: # 초기 설정 자동화 (최초 실행 시에만 적용) - name: DOCKER_INFLUXDB_INIT_MODE value: setup - name: DOCKER_INFLUXDB_INIT_USERNAME value: # 아무거나 - name: DOCKER_INFLUXDB_INIT_PASSWORD value: # 아무거나 - name: DOCKER_INFLUXDB_INIT_ORG value: my-org - name: DOCKER_INFLUXDB_INIT_BUCKET value: my-bucket - name: DOCKER_INFLUXDB_INIT_ADMIN_TOKEN value: my-super-secret-token volumeMounts: - name: influxdb-data mountPath: /var/lib/influxdb2 volumeClaimTemplates: - metadata: name: influxdb-data spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "longhorn-influxdb" resources: requests: storage: 2Gi # 스토리지 용량 설정

```

os_js.log

파일 무결성 검사

Agent에서 사용하는 파일 무결성 검증 방식

파일 무결성을 확인하는 방법

단순 체크섬

BLAKE3

Merkle Tree

현재 Agent에서 사용하는 방식

단순 체크섬을 사용하지 않은 이유

Merkle Tree를 사용하지 않은 이유

BLAKE3만으로 모든 보안 문제가 해결되는가

정리

테스트..

zenoh 사용(nestjs)

NestJS에서 Zenoh Remote API와 WebSocket으로 통신하는 방식

왜 WebSocket을 사용하는가

NestJS에서는 어떻게 연결하는가

WebSocket 연결 상태를 별도로 감지하는 이유

연결이 끊기면 어떻게 처리하는가

재연결 간격을 두는 이유

Health Check를 함께 사용하는 이유

전체 연결 흐름

정리

번외..

Zenoh

Zenoh란 무엇인가? 로봇과 IoT 통신에서 주목받는 이유

Zenoh란?

Zenoh의 기본 데이터 구조

Zenoh의 주요 통신 방식

1. Publish/Subscribe

2. Query/Reply

3. Storage

Zenoh의 장점

데이터 생산자와 소비자를 분리할 수 있다

Pub/Sub와 요청·응답을 함께 사용할 수 있다

다양한 네트워크 구조를 지원한다

계층적인 Key Expression을 사용할 수 있다

장치와 서비스의 연결 상태를 표현할 수 있다

엣지 장치와 저사양 장치를 고려할 수 있다

WebSocket과는 무엇이 다른가?

Zenoh가 적합한 경우

마무리

scp window to rhel

윈도우 to RHEL 파일 전송.

문제 발생.

문제 해결

결과

AWS (7) - S3, CloudFront

CloudFront

CloudFront란?

정적 웹사이트 호스팅용 S3 버킷 준비

S3 정적 웹사이트 호스팅

CloudFront 구성

새로운 도메인 HTTPS 적용

HTTPS 적용을 위한 인증서 발급

CloudFront 인증서 적용

AWS (6) - S3, IAM

S3

S3란?

버킷

객체

이미지 업로드 과정

이미지 다운로드 과정

S3 버킷 만들기

버킷 정책 추가

IAM

IAM 이란?

IAM 액세스키 발급 받기

백엔드 연동

AWS (5) - RDS

RDS

RDS란?

RDS 인스턴스

RDS 인스턴스 생성

RDS 보안그룹 수정

RDS 인스턴스 접속

파라미터 그룹 설정

RDS 파라미터 그룹 변경

백엔드와 연동

AWS - 삭제