개발자의 축구 기행문

VS Code에서 Spring Boot 애플리케이션 실행 시 프로파일 선택하는 방법

VS Code에서 Spring Boot 애플리케이션을 실행할 때, 특정 프로파일을 선택하여 애플리케이션을 실행하려면 몇 가지 설정을 해줘야 합니다. 이 글에서는 launch.json 파일을 수정하여 실행할 프로파일을 선택하는 방법을 설명합니다.

launch.json 설정 파일 수정

VS Code에서 Spring Boot 애플리케이션을 실행할 때 사용할 프로파일을 설정하려면, 먼저 launch.json 파일을 수정해야 합니다.

1. Run and Debug 탭을 클릭합니다.
2. Create a launch.json file을 선택하고, spring-boot 템플릿을 선택하거나 기존의 launch.json 파일을 수정합니다.

launch.json 설정 예시

launch.json 파일을 다음과 같이 수정합니다. 이 예시에서는 SPRING_PROFILES_ACTIVE 환경변수를 사용해 dev 프로파일을 설정하고 있습니다.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Spring Boot",
      "type": "java",
      "request": "launch",
      "mainClass": "com.example.MainApplication",
      "env": {
        "SPRING_PROFILES_ACTIVE": "dev"  // 원하는 프로파일 (dev, prd 등)로 설정
      }
    }
  ]
}

PowerShell 프로필 스크립트($PROFILE)에 설정을 추가하면 매번 실행할 필요 없이 자동으로 인코딩이 UTF-8이 적용됩니다.

1. 프로필 스크립트 확인 및 생성

먼저, 프로필 스크립트가 있는지 확인하고, 없으면 생성합니다.

if (!(Test-Path $PROFILE)) { New-Item -Path $PROFILE -ItemType File -Force }

2. 프로필 파일에 UTF-8 설정 추가

프로필 파일을 열어서 UTF-8 설정을 추가해야 합니다.

notepad $PROFILE

위 명령어를 실행하면 notepad가 열립니다.

그 안에 아래 내용을 추가하고 저장하세요.

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$PSDefaultParameterValues['Out-File:Encoding'] = 'utf8'

3. 변경 사항 적용

이제 PowerShell을 닫고 다시 실행하면 자동으로 UTF-8 인코딩이 적용됩니다.

즉, 새 PowerShell 창을 열더라도 한글이 깨지지 않습니다.

4. 스크립트 적용

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

Pushing to https://github.com/myid/myrepo.git
remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
fatal:Authentication failed for 'https://github.com/myid/myrepo.git/' In a case you entered incorrect password, please update it in Keychain Access application.

오랜만에 개인 기기로 작업을 좀 한 뒤, github에 push 했습니다.

그런데 해당 에러가 발생하며 push 가 안되는 현상이 발생하여, push가 완료되지 않았습니다.

분명히 예전에 기한 제한 없이 token 을 발급 받아서 설정 했던 것 같은데🤔

하지만, 막상 Github에 들어가보니, 지난번에 생성한 token 들이 모두 만료되었네요 ㅎㅎ

This token has expired

만료가 되었을 경우, 삭제 해주시고 새로운 토큰을 발급 받아주시면 됩니다.

새로운 토큰 발급 방법은 아래 링크에 자세히 설명되어 있습니다 😊

Username for 'https://github.com': myid
Password for 'https://myid@github.com' :
remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ fatal: Authentication failed for 'https://github.com/myid/myrepo.git/'

프로젝트에 최초로 git init을 한 경우, 이후 GitHub의 origin 저장소에 push를 시도하면 인증 관련 에러가 발생할 수 있습니다.

이는 GitHub에서 2021년 8월부로 비밀번호 인증을 더 이상 지원하지 않고, 대신 Personal Access Token(PAT) 을 사용하여 인증하도록 변경되었기 때문입니다.

따라서 GitHub 홈페이지에서 새로운 토큰을 발급받고, 이를 로컬 Git에 연동해주어야 합니다.

아래 내용을 따라 진행해주세요.

✅ 새로운 Personal Access Token 생성 방법 (Classic 방식)

1. GitHub 접속 → 로그인
2. 우측 상단 프로필 클릭 → Settings
3. 좌측 메뉴에서 아래로 스크롤 → Developer settings
4. Personal access tokens → Fine-grained tokens 선택
5. 우측 상단 "Generate new token" 클릭

🔧 설정할 항목들

1. Token name (이름)

• 예: study-token

2. Resource owner

• 로그인된 계정 및 추가 사용자

3. Expiration (만료일)

• 90일, 180일, 1년, 또는 No expiration (보안상 90일 추천)
• 개인 스터디 용으로 사용 시 'No expiration'도 사용가능하긴 합니다.

4. Repository access (저장소 접근 권한)

최소 권한 설정 방법

1. Repository Permissions:
   • 기본적으로 Contents, Issues, Pull requests 권한을 선택하면 대부분의 작업 가능
   • 추가적으로 CI/CD가 필요하면 Actions, 보안 관리가 필요하면 Code scanning alerts 권한 추가
2. Account Permissions:
   • 대부분의 경우 기본적인 계정 권한만 필요하므로, Profile, Email addresses 정도만 선택하면 충분합니다.

이후 'Generate token' 클릭 시 아래처럼 새로운 토큰이 생성됩니다.

🛠️ Git에 토큰 저장하기

다음 push에서 GitHub 계정과 토큰을 사용할 수 있도록 설정해야 합니다. 

아래 명령어 입력 시 popup 창이 뜨고, 내용을 입력해주세요.

git push origin main

• 사용자명: GitHub 아이디
• 비밀번호: 방금 만든 토큰

🛠️ 설정 및 토큰 갱신 절차 (macOS/Windows 공통)

1. 기존 인증 정보 삭제

• macOS: Keychain Access에서 github.com 항목 삭제
• Windows: 자격 증명 관리자에서 git:https://github.com 항목 삭제

공장 자동화나 스마트 팩토리 같은 산업 환경에서 자주 등장하는 용어 중에 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을 사용하는 것이 효율적일 수 있습니다.