개발자의 축구 기행문

공장 자동화나 스마트 팩토리 같은 산업 환경에서 자주 등장하는 용어 중에 OPC UA와 RDP가 있습니다.
두 기술은 서로 완전히 다른 역할을 하지만, 실제 현장에서는 함께 사용되기도 합니다.
이 글에서는 각 기술의 개념과 실제 현장에서의 연관성에 대해 간단하게 정리해보겠습니다.

🔧 OPC UA란?

OPC UA (OPC Unified Architecture)는 공장 설비나 장비, 센서 등이 서로 데이터를 주고받을 수 있도록 만든 산업용 통신 프로토콜입니다.

✅ 주요 특징

• 플랫폼 독립적: Windows, Linux, 임베디드 시스템 등 다양한 환경에서 사용 가능
• 보안 내장: 암호화, 사용자 인증, 데이터 서명 등 강력한 보안 기능 제공
• 객체지향 데이터 구조: 단순한 값뿐 아니라 '장비', '센서' 같은 구조적 데이터 표현 가능
• 높은 확장성: 스마트 팩토리, IIoT, MES, SCADA 등 다양한 시스템에서 활용 가능

💡 예시

• PLC에서 온도 데이터를 OPC UA 서버로 전송
• 클라이언트 프로그램(SCADA, 웹 클라이언트 등)이 해당 데이터를 실시간으로 조회

💻 RDP란?

RDP(Remote Desktop Protocol)는 Microsoft에서 만든 프로토콜로, 다른 컴퓨터에 원격 접속하여 화면을 보고 조작할 수 있게 해주는 기술입니다.

✅ 주요 특징

• 원격 데스크톱 접속: 다른 컴퓨터의 화면을 실시간으로 보며 조작 가능
• 시스템 관리에 유용: IT 관리자, 개발자 등이 원격에서 유지보수할 때 많이 사용
• Windows 기본 기능: 대부분의 윈도우 운영체제에 내장되어 있음

💡 예시

• 본사에서 공장 내부 PC에 RDP로 접속
• 그 PC를 통해 OPC UA 서버 상태를 점검하거나 설정 변경

🔗 OPC UA와 RDP의 연관성은?

두 기술은 기술적으로는 완전히 별개의 프로토콜입니다.

• OPC UA는 장비와 시스템 간 데이터 통신을 위한 것이고,
• RDP는 원격지 컴퓨터에 접속하고 조작하기 위한 것입니다.

하지만 실제 현장에서는 함께 쓰이는 경우가 많습니다.

📌 실제 사용 예시

엔지니어가 공장 현장에 있는 OPC UA 서버를 점검해야 하는 상황
→ 직접 가지 않고, RDP로 공장 내부 PC에 접속
→ 접속한 PC에서 OPC UA 클라이언트를 실행해서 장비 상태를 확인

이처럼, RDP는 원격 접속 수단, OPC UA는 데이터 통신 수단으로 함께 쓰입니다.

🧩 두 기술 요약 비교

✅ 마무리

정리하자면,

• OPC UA는 산업 장비 간 안전하고 구조화된 통신을 위한 프로토콜이고,
• RDP는 원격으로 컴퓨터에 접속해 조작하는 데 사용하는 프로토콜입니다.

서로 다른 역할을 하지만, 스마트 팩토리나 원격 유지보수 환경에서는 함께 사용되는 경우가 많습니다.

최근 Mac을 새로 세팅하면서 개발 환경도 처음부터 다시 구성하게 되었습니다.

그 중 가장 먼저 설치한 도구 중 하나가 Homebrew와 Docker입니다.

혹시 저처럼 처음 설치하시는 분들이 있다면 참고하시라고 정리해봤습니다.

Step 1. Homebrew 설치

Homebrew는 macOS에서 패키지나 앱을 간편하게 설치할 수 있게 도와주는 필수 도구입니다. 터미널을 열고 아래 명령어를 입력하면 설치가 시작됩니다.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

설치가 끝나면 터미널에 추가로 아래와 같은 메시지가 뜰 수 있습니다. 이건 brew 명령어를 제대로 인식시키기 위한 설정이니 꼭 따라 해주셔야 합니다.

* Homebrew 설치를 정상적으로 했는데, 아직 터미널에서 brew 명령어를 인식하지 못할 수 있느니, .zprofile을 추가하라는 의미입니다.

🍎 M1/M2/M3 (Apple Silicon) 사용자의 경우

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile eval "$(/opt/homebrew/bin/brew shellenv)"

💻 Intel Mac 사용자

echo 'eval "$(/usr/local/bin/brew shellenv)"' >> ~/.zprofile eval "$(/usr/local/bin/brew shellenv)"

제대로 설치되었는지 확인하려면 다음 명령어를 입력해봅니다.

brew --version

* homebrew 설치가 정상적으로 완료 되었다면, 버전 정보가 출력됩니다.

Step 2. Docker 설치

이제 Homebrew를 이용해 Docker를 설치해보겠습니다. Docker는 GUI 앱 형태로 설치되기 때문에 --cask 옵션을 사용합니다.

* --cast 옵션은 Homebrew 에서 GUI 애플리케이션을 설치할 때 사용하는 옵션입니다.

brew install --cask docker

* 설치가 완료되면 응용 프로그램 > Docker에서 앱을 실행하거나 아래 명령어로도 실행할 수 있습니다.

처음 실행할 때는 관리자 권한을 요구하거나 로그인을 해야 할 수도 있어요. 실행이 완료되면 화면 오른쪽 상단 메뉴바에 고래 아이콘 이 생기는데, 이 아이콘이 떠 있다면 Docker가 잘 실행된 상태입니다!

Step 3. 설치 확인

마지막으로 Docker가 정상적으로 설치되었는지 확인해보겠습니다.

docker --version

이 명령어를 입력했을 때 버전 정보가 잘 나온다면 성공입니다!

저는 이렇게 macOS에 Homebrew와 Docker를 설치하고 본격적인 개발 환경을 시작했습니다. 혹시 설치 중 막히는 부분이나 궁금한 점 있으시면 댓글 남겨주세요! 😊

다른 기기로 작업을 할 경우 commit을 해도 GitHub 에서 잔디(=커밋 기록)이 제대로 표시되지 않는 경우가 있습니다.

• GitHub에 잔디(=커밋 기록)가 생기려면 커밋할 때 사용한 이름과 이메일이 GitHub 계정 정보와 일치해야 합니다.
• 개인 PC와 회사 PC 등 환경 마다 commit author 가 다를 경우 아래처럼 변경할 수 있습니다.

🧑‍🔧 Git Author 변경하기

git config --global user.name "홍길동"
git config --global user.email "hong@example.com"

• 위에서 hong@example.com이 GitHub 계정에 등록되어 있어야 잔디가 생김

✅ 커밋 기록 이메일 확인:

git log --pretty=full

• Author 와 Commit 이 일치한지 확인 해주세요

🚀 Docker 사용 중 리소스가 부족하다면?

Docker를 사용하다 보면 여러 개의 컨테이너를 실행하게 되고, 결국 CPU와 메모리 리소스가 부족해지는 상황을 겪을 수 있습니다.

특히 Windows에서는 Docker가 WSL(Windows Subsystem for Linux) 을 기반으로 실행됩니다.

그래서 단순히 Docker 설정에서 CPU와 메모리를 변경하는 것이 아니라 WSL의 설정을 수정해줘야 합니다.

🛠 Docker 리소스 설정을 변경해야 하는 이유

Docker는 기본적으로 리눅스 기반으로 동작하는 시스템입니다.

Windows에서는 WSL 2 환경을 통해 리눅스 커널을 실행하고, 그 위에서 Docker가 컨테이너를 구동합니다.

Mac OS의 경우? Mac에서는 Docker가 GUI에서 직접 리소스(CPU, Memory)를 설정할 수 있도록 제공하지만, Windows에서는 이런 설정이 바로 적용되지 않습니다.

Windows에서는 WSL의 .wslconfig 파일을 직접 수정해야만 CPU 및 메모리 리소스를 조절할 수 있습니다.

🔧 WSL 설정 변경하여 Docker 리소스 조절하기

1️⃣ .wslconfig 파일 생성 및 수정

WSL 설정 파일은 C:\\Users\\사용자명 경로에 위치합니다. 만약 .wslconfig 파일이 없다면 직접 만들어야 합니다.

📌 파일 경로:

C:\\Users\\사용자명\\.wslconfig

⚠️ 파일 확장자가 wslconfig.txt 가 되지 않도록 주의하세요

📌 설정 파일 내용:

[wsl2]
memory=4GB   # 최대 메모리 사용량 설정 (예: 4GB)
processors=2  # CPU 코어 수 설정 (예: 2개)
swap=2GB     # 스왑 메모리 설정 (예: 2GB)

🔹 memory=4GB → Docker가 사용할 최대 메모리를 4GB로 설정

🔹 processors=2 → CPU 코어를 2개만 사용하도록 설정

🔹 swap=2GB → 부족한 메모리를 보충할 스왑 공간 2GB 설정

• RAM 이 부족할 경우, 이를 보완하기 위해 디스크의 일부를 임시 메모리처럼 사용하는 기능

🔧 Docker에서 Swap 설정하는 이유

Docker에서 컨테이너가 사용하는 메모리를 제한해도, 컨테이너가 RAM을 초과해서 사용하려고 하면 swap을 활용할 수 있습니다.

즉, swap을 설정하면 RAM 부족으로 인해 컨테이너가 갑자기 종료되는 것을 방지할 수 있습니다.

⚠️ Swap 설정 시 주의할 점

1. 너무 크게 설정하면 성능 저하 🚨
   • Swap은 디스크를 사용하기 때문에 너무 많이 설정하면 속도가 느려질 수 있어.
   • 일반적으로 RAM의 1~2배 정도로 설정하는 것이 좋음.
2. SSD 사용이 권장됨 ⚡
   • Swap은 지속적으로 읽고 쓰는 작업이 많기 때문에, SSD가 아닌 HDD에서는 성능이 크게 떨어질 수 있음.

🔧 Docker Resource 설정하기

1. PowerShell에서 다음 명령어 실행:

notepad C:\\Users\\user\\.wslconfig

2. 내용 입력 후 저장

[wsl2]
memory=4GB
processors=4
swap=2GB

3. Docker Desktop 및 WSL 종료

taskkill /IM "Docker Desktop.exe" /F

wsl --shutdown

4. WSL 재시작 및 wsl root 이동(아래 명령어도 실행/wsl root 이동)

wsl

5. 스펙 확인 명령어 실행

free -h

Docker 가 보편화 되기 이전에는 개발 환경 셋팅에 정말 많은 공수가 필요 했습니다.

하지만 Docker는 애플리케이션과 그 의존성을 컨테이너로 패키징하여 독립성과 경량화 장점을 갖고 있습니다.

물론 빠른 배포, 빠른 스케일링 장점도 있지만 우선 Docker 환경에서 컨테이너를 올려보겠습니다

그러면 mysql 컨테이너를 만들어보겠습니다.

어떻게 Docker 환경에서 mysql 컨테이너를 생성할 수 있을까요?

우선 컨테이너의 생성을 위한 순서는 아래와 같습니다.

1. docker-compose.yml 파일 생성

2. Dockerfile 생성

3. docker-compose up 명령어 실행

    - 1) Dockerfile 정의 내용을 기반으로 이미지 빌드

    - 2) 이미지를 사용하여 컨테이너 생성 및 실행

4. 생성 컨테이너 확인

위의 순서에 맞게 하나씩 진행 해보겠습니다.

1. 프로젝트 최상위 디렉토리에 docker 디렉토리 및 docker-compose.yml 파일 생성 (그림. 프로젝트 디렉토리)

• 저는 스프링 부트 프로젝트 입니다.

version: '1'

services:
  mysql:
    build:
      dockerfile: mysql/Dockerfile
    container_name: mysql
    environment:
      MYSQL_ROOT_PASSWORD: 1234
    ports:
      - "3306:3306"

• service:mysql:builder:dockerfile 에 Dockerfile 경로를 입력 해주세요(mysql/Dockerfile)

2. docker 디렉토리에 mysql 디렉토리 및 Dockerfile 생성 (그림. 프로젝트 디렉토리)

# 베이스 이미지 설정
FROM mysql:latest

• Dockerfile 사용 예시를 공유하기 위해 베이스 이미지 설정만 추가 했습니다.

3. 프로젝트 docker 디렉토리 이동 및 docker 실행

docker-compose up -d

• -d 옵션은 컨테이너를 백그라운드에서 실행하고 터미널 사용 제어권을 반환하는 역할을 합니다.

4. mysql 컨테이너 확인

docker exec -it mysql mysql -uroot -p

• 해당 명령어 입력 후 비밀번호 입력 프롬프트가 표시됩니다. 이때 docker-compose.yml 에 설정한 비밀번호를 입력해주세요.

이렇게 Docker 환경에서 mysql 컨테이너 생성 예제가 완료 되었습니다.

컨테이너의 환경 설정을 docker-compose.yml 파일에 할지, Dockerfile에 할지 정확한 답은 없습니다.

만약 고민이 되신다면 아래 포스트를 참고 해주세요.

https://gabrielyj.tistory.com/225

컨테이너의 환경설정 docker-compose.yml 이랑 Dockerfile 중 어디가 적합하지?

Docker 컨테이너 생성 시 환경설정을 어디에 할지 고민이 될 수 있습니다.

이럴 때에는 장/단점을 따져보고 결정하는게 맞을 것 같습니다.

docker-compose.yml 환경설정

[장점]

• docker-compose.yml 파일은 여러 컨테이너 및 서비스를 정의하고 관리하기가 편리합니다.
• 컨테이너 간의 의존성을 쉽게 정의하고 관리할 수 있습니다.
• 환경 설정을 외부화하여 수정 및 유지 관리가 용이합니다.

[단점]

• 컨테이너에 대한 상세한 설정을 docker-compose.yml 파일에 직접 작성해야 합니다.
• 복잡한 설정을 다루기에는 docker-compose.yml 파일이 적합하지 않을 수 있습니다.

Dockerfile 환경설정

[장점]

• Dockerfile을 사용하여 컨테이너의 이미지를 빌드할 때 더 많은 제어권을 가질 수 있습니다.
• 구체적인 설정을 Dockerfile 내에서 관리하고 변경할 수 있습니다.

[단점]

• Dockerfile을 직접 작성하고 관리해야 하므로 일부 개발자들에게는 복잡할 수 있습니다.
• 다른 컨테이너 및 서비스와의 의존성을 정의하고 관리하기가 더 어려울 수 있습니다.

그래서 어떻게 하지?

• 일반적으로 단일 컨테이너를 실행하는 경우에는 docker-compose.yml 파일을 사용하는 것이 더 효율적일 수 있습니다.
• 복잡한 환경에서 컨테이너 간의 복잡한 의존성이 있거나, 세부적인 커스터마이징이 필요할 경우 Dockerfile을 사용하는 것이 효율적일 수 있습니다.

Dockerfile와 docker-compose.yml 파일의 차이

도커를 생성하셨으면 이제 실제 애플리케이션을 컨테이너화 해야됩니다.

이때 사용되는 파일은 Dockerfile 과 docker-compose.yml 파일입니다.

두 파일 모두 컨테이너화를 위해 사용되는데 서로 다른 목적과 사용 사례를 갖고 있습니다.

Dockerfile 이란?

• 개별 컨테이너 정의 : 단일 도커 이미지를 정의하는데 사용됩니다. 이미지는 컨테이너를 시작하는데 사용되는 템플릿입니다.
• 컨테이너 빌드 지시사항 : 컨테이너를 빌드하기 위한 지시사항을 포함합니다. 기본 이미지, 작업 디렉토리, 파일 복사, 환경 변수 설정 등을 포함합니다.
• 단일 서비스 정의 : 사용하면 하나의 서비스 또는 애플리케이션의 컨테이너를 정의합니다. 보통 하나의 Dockerfile은 하나의 애플리케이션을 컨테이너화하기 위해 사용됩니다.

docker-compose.yml 이란?

• 다중 컨테이너 애플리케이션 정의 : 파일은 다중 컨테이너 애플리케이션의 전체 구성을 정의하는 데 사용됩니다. 여러 서비스 또는 컨테이너를 함께 실행하고 관리할 때 유용합니다.
• 서비스 간 의존성 관리 : 서비스 간의 읜존성과 상호 작용을 정의합니다. 이를 통해 여러 컨테이너를 함께 시작하고 관리할 수 있습니다.
• 환경 설정 및 네트워크 구성 : 각 서비스의 환경 변수, 포트 맵핑, 불륨 마운트, 서비스 간의 네트워크 구성 정의 등을 설정할 수 있습니다.

그래서 Dockerfile 이랑 docker-compose.yml 파일의 차이가 뭐야?

• docker-compose.yml 을 통해 다중 컨테이너 애플리케이션을 정의합니다.
• docker-compose.yml 을 통해 생성되는 컨테이너의 설정은 Dockerfile을 통해 이루어집니다.

즉, docker-compose.yml 을 통해 전체적인 애플리케이션 컨테이너를 생성하고 각 컨테이너의 세부 설정은 Dockerfile을 사용합니다.

[docker-compose.yml 파일과 각 dockerfile 경로]

docker-compose.yml 의 위치는 1depth 로써, 각 컨테이너(mysql, rabbitmq, kafka) 의 경로에 dockerfile 이 존재합니다.

1depth/
│
└── docker-compose.yml
│
├── mysql/
│   └── Dockerfile_mysql
│
├── rabbitmq/
│   └── Dockerfile_rabbitmq
│
└── kafka/
    └── Dockerfile_kafka

[docker-compose.yml 예시]

version: '3'  # Docker Compose 파일의 버전 지정

services:  # 각 서비스를 정의합니다.
  mysql:  # 서비스 이름
    image: mysql:latest  # 사용할 도커 이미지
    container_name: mysql-container  # 컨테이너 이름
    environment:  # 환경 변수 설정
      MYSQL_ROOT_PASSWORD: <password>  # MySQL 루트 비밀번호 설정
    ports:  # 포트 매핑
      - "3306:3306"  # 호스트와 컨테이너의 포트를 매핑

  rabbitmq:
    image: rabbitmq:latest
    container_name: rabbitmq-container
    ports:
      - "5672:5672"
      - "15672:15672"

  kafka:
    image: wurstmeister/kafka:latest
    container_name: kafka-container
    ports:
      - "9092:9092"

결론

1. docker-compose.yml 을 통해 애플리케이션 컨테이너화를 합니다.
2. 각 애플리케이션 컨테이너 경로의 dockerfile을 통해 설정을 합니다.

Docker 설치 방법 in Mac OS

1. Docker 공식 홈페이지로 이동합니다.

• https://docs.docker.com/desktop/install/mac-install/

2. Mac OS 칩셋 선택

M1, M2, M3.. 계열을 구매한 사용자라면 'Apple Silicon' 을 선택하시고,

intel 계열을 구매한 사용자라면 'Intel chip'를 선택해주세요.

3. 다운로드 받은 Docker dmg 파일 실행 및 설치

4. Docker 실행 및 정상 설치 확인

사용자 인증 환경에서 쿠키(cookies)란 ?

• 사용자 인증에서 쿠키는 웹 브라우저에 저장되는 작은 데이터 조각입니다.
• 서버에서 웹 브라우저로 전송되어 클라이언트의 PC에 저장됩니다.
• 클라이언트가 웹 서핑이나 API 를 요청할 때 사용자 식별 및 상태 추적을 위해 사용됩니다.

사용자 인증 환경에서 쿠키의 생명주기는 어떻게 될까요?

• 사용자 로그인 : 아이디와 비밀번호 입력 후 서버 요청(HTTP REQUEST)
• 서버 인증 : 아이디와 비밀번호를 확인하여 유효한 사용자인지 확인 후 사용자를 식별하는 고유한 세션 식별자를 생성
• 쿠키 생성 : 생성된 세션 식별자를 쿠키에 저장하고, 이 쿠키를 에 담아 클라이언트에 응답(HTTP RESPONSE)
• 사용자 요청 시 쿠키 전송 : 클라이언트가 서비스에 새로운 요청을 할 때마다 쿠키를 서버에 함께 요청
  • 서버에서 세션 식별자를 통해 유효성을 검증 합니다.
• 세션 유지 및 로그아웃 : 클라이언트가 활동하는 동안 세션을 유지하고, 로그아웃을 하거나 세션이 만료되었을 경우에는 쿠키를 무효화하고 다시 인증하는 로직을 수행

사용자 인증 환경에서 쿠키를 아직 사용하나요?

• MSA가 보편화된 시점에서 서버는 stateless(상태 없음, 무상태)를 지향합니다. 아니 필수라고 할 수 있습니다. 이럴경우 하나의 서버에서 사용자 인증 세션을 관리하기 어렵습니다. 그렇기 때문에 쿠키-세션 방식은 현재 많이 사용되고 있지 않습니다.
• 하지만, JWT 토큰을 쿠키에 저장하는 방법은 사용되고 있는데 이 부분은 다음 포스트에서 공유 드리겠습니다.

HTTP 와 HTTPS 의 차이를 묻는 질문 빈도는 면접 외에도 정말 자주 있는것 같습니다.

그러면 HTTP 의 기초부터 HTTPS 까지 폭 넓게 알아가보도록 하겠습니다.

HTTP란?

HTTP(Hypertext Transfer Protocol) 은 인터넷을 통해 정보를 전송하는데 사용되는 프로토콜입니다.

또한 HTTP는 상태가 없는 프로토콜 입니다. 클라이언트와 서버 간의 각 요청이 서로 독립적으로 처리되며, 이전 요청과 상태에 대한 정보를 유지하지 않는다는 것을 의미합니다. 

저희는 이것을 무상태성(Stateless) 이라고 표현합니다.

• HTTP 의 특징 
  • 데이터를 암호화하지 않고 평문으로 전송하여 보안성 보장이 안됨 (데이터 도청 및 노출 위험이 있음)
  • 기본적으로 80포트를 사용
  • TCP/IP 프로토콜 스택 위에서 동작, TCP 의 여러 특성(연결 지향성, 신뢰성, 흐름 제어 등)을 사용
  • 요청-응답 구조 : 클라이언트가 서버에 요청을 보내고, 서버는 요청 처리을 처리 후 응답하는 구조
  • 메서드 사용 : GET, POST, PUT, DELETE 등

이러한 HTTP 의 특징은 HTTPS 에서도 동일하게 사용됩니다. 

HTTPS란?

HTTPS(Hypertext Transfer Protocol Secure) 도 인터넷을 통해 정보를 전송하는 프로토콜입니다.

HTTP 와의 차이점은 이름에서 알 수 있듯이 '보안'과 '암호화' 입니다.

• HTTPS의 특징
  • SSL 또는 TLS 프로토콜을 사용하여 데이터를 암호화. 데이터를 안전하게 전송하여 도청이나 데이터 변조를 방지
  • 기본적으로 443 포트를 사용
  • SSL, TLS 프로토콜을 사용하기 위해 서버의 신원을 인정하는 '인증서'를 요구함. 이를 통해 클라이언트에 서버가 신뢰할 수 있는지 여부를 확인할 수 있음
  • SEO(Search Engine Optimization) : HTTPS를 사용하는 웹사이트는 HTTP를 사용하는 웹사이트보다 더 안전하기 때문에, 검색 엔진에서 더 높은 순위를 받을 수 있음. 즉, 검색 엔진 최적화의 필수 요소
  • 쿠키와 세션을 사용하여 데이터가 안전하게 전송되므로 중간자 공격으로부터 보호됨

그럼 결론은?

HTTPS는 HTTP 의 보안 강화 버전으로 생각하시면 됩니다. 전송되는 데이터의 기밀성과 무결성을 보호하는데 사용되며 보안성이 HTTP보다 높습니다.

현재 클라이언트에게 제공 중인 서비스 중 HTTP 를 사용하는건 거의 본적이 없습니다. 만약 HTTP 만 사용하면 chrome, safari 같은 브라우저에서 경고가 뜨거나 접근할 수 없습니다. 그리고 앱스토어 심사에서 불합격할 수 있는 요소입니다.

물론 MSA 구축 시 서버 내부 통신은 http 만 사용할 수 있습니다.