기록하는 프로그래머

[Jenkins] 2.541 Update, new GPG key 갱신 필요

종벌 — Tue, 27 Jan 2026 10:15:43 +0900

Jenkins 업데이트를 진행했더니 아래와 같은 GPG key 에러가 발생했다.

Public key for jenkins-2.541.1-1.noarch.rpm is not installed
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED

젠킨스 업데이트 변경사항을 확인하기 위해 찾아 들어갔다.

역시 새로운 GPG key 가 나왔으니 새로 설치하고 업데이트 하라고 공지 되어있다.

Jenkins ChangeLog 참고

Jenkins 2.543 and 2.541.1: New Linux Repository Signing Keys

This article announces new Linux repository signing keys. Repository signing keys will change with the release of Jenkins weekly 2.543 and Jenkins LTS 2.541.1. The previous repository signing keys will not be used after the release of Jenkins weekly 2.542.

www.jenkins.io

리눅스 버전에 따라 방법을 제공해주니 환경에 맡게 복붙하여 수행하면 되겠다.

# Debian/Ubuntu LTS release
curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2026.key | sudo tee \
  /usr/share/keyrings/jenkins-keyring.asc > /dev/null
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
  https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null
  
  
# Red Hat/CentOS LTS release
sudo rpm --import https://pkg.jenkins.io/rpm-stable/jenkins.io-2026.key

그리고 다시 Jenkins 업데이트를 수행하면 문제 없이 업데이트 되는 것을 볼 수 있다.

Total                                                                                       15 MB/s |  92 MB     00:06
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                   1/1
  Running scriptlet: jenkins-2.541.1-1.noarch                                                                          1/1
  Running scriptlet: jenkins-2.541.1-1.noarch                                                                          1/2
  Upgrading        : jenkins-2.541.1-1.noarch                                                                          1/2
  Running scriptlet: jenkins-2.541.1-1.noarch                                                                          1/2
  Running scriptlet: jenkins-2.528.1-1.1.noarch                                                                        2/2
  Cleanup          : jenkins-2.528.1-1.1.noarch                                                                        2/2
  Running scriptlet: jenkins-2.528.1-1.1.noarch                                                                        2/2
  Verifying        : jenkins-2.541.1-1.noarch                                                                          1/2
  Verifying        : jenkins-2.528.1-1.1.noarch                                                                        2/2

Upgraded:
  jenkins-2.541.1-1.noarch

[SVN] svnsync 동기화 URL relocate 하기

종벌 — Thu, 27 Nov 2025 18:18:45 +0900

사내 레거시 사이트 중에 svn 을 사용하는 프로젝트가 하나 있는데

개발쪽에서 svn 에 커밋하면

그 외 실제 운영 서버 svn 서버 레파지토리에 svnsync 로 자동 update 하게 설정이 되어 있었다.

개발에서 커밋하는 svn 도메인이 변경되어 이를 변경하고자 한다.

먼저 svnsync 가 어떻게 설정되어있는지 확인한다.

> svn propget --revprop -r0 svn:sync-from-url file:///D:/repository/project
https://legacy.domain.com/svn/project

해당 레파지토리의 연결된 svn 주소가 출력된다.

이전 도메인인것을 확인하고 연결을 삭제하고 재등록 해준다.

> svn propdel --revprop -r0 svn:sync-from-url  file:///D:/repository/project
property 'svn:sync-from-url' deleted from repository revision 0

변경된 도메인으로 설정해준 후 다시 propget 해보면 변경된 것을 확인할 수 있다.

> svn propset --revprop -r0 svn:sync-from-url https://svn.domain.com/svn/project file:///D:/repository/project
property 'svn:sync-from-url' set on repository revision 0

이후에 다시 동기화 시켜주면 변경 끝.

> svnsync sync file:///D:/repository/project

[Git] fork 못하는 private repo clone 해오기.

종벌 — Mon, 17 Nov 2025 15:51:58 +0900

조직 깃헙에서 내가 만든 모듈을 내 개인 repo에도 게시하고 싶을때가 있다.

보통 조직 깃헙은 private repo 라서 fork 가 disabled 처리 되어 있어서 할수 없어서

조직 깃헙 레포를 복사해서 게시한다.

fork 못함 ㅠㅠ

gg@PARKJB MINGW64 /d/GitHub
$ git clone --mirror https://github.com/조직/Jenkins-Pipeline-Libraries.git
Cloning into bare repository 'Jenkins-Pipeline-Libraries.git'...
remote: Enumerating objects: 16, done.
remote: Counting objects: 100% (16/16), done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 16 (delta 3), reused 13 (delta 3), pack-reused 0 (from 0)
Receiving objects: 100% (16/16), done.
Resolving deltas: 100% (3/3), done.

먼저 조직에 repo 를 clone --mirror 를 통해 복사한다.

그러면 repository명.git 폴더가 복사떠진다.

gg@PARKJB MINGW64 /d/GitHub
$ cd Jenkins-Pipeline-Libraries.git

복사떠진 폴더로 이동해서 내 repo로 push 해주면 된다.

gg@PARKJB MINGW64 /d/GitHub/Jenkins-Pipeline-Libraries.git (BARE:main)
$ git push --mirror https://github.com/개인/Jenkins-Pipeline-Libraries.git
Enumerating objects: 16, done.
Counting objects: 100% (16/16), done.
Delta compression using up to 12 threads
Compressing objects: 100% (11/11), done.
Writing objects: 100% (16/16), 2.99 KiB | 2.99 MiB/s, done.
Total 16 (delta 3), reused 16 (delta 3), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (3/3), done.

내 레파지토리에 복사가 동일하게 된 것을 확인 할 수 있다.

[IntelliJ] Artifacts recursion directory 문제해결.(feat.war_exploded)

종벌 — Wed, 5 Nov 2025 17:14:59 +0900

Spring + 외장 Tomcat 으로 동작하는 프로젝트가 있었다.

초반에 로컬에서 인텔리제이로 테스트할때는 속도가 꽤 좋았다. (springboot 내장 tomcat에 비하면 떨어지지만)

간단한 테스트를 하려고 하는데 톰캣 재기동도 아니고

빌드하고 클래스파일 갱신하는데 진짜 5분 이상 걸리는 것이다.

이때까지는 원인을 몰랐다.

내가 설계한 프로젝트가 아니라서 설정을 잘못구성해서 느리나 했다.

한가지 의문점은 초반에는 이정도로 느리지 않았다는 것이다. (빌드+톰캣 배포+실행 까지 2분 내 걸리긴 했다만...)

하루종일 클래스를 갱신하거나 재배포 하니까

인텔리제이 자체가 무지막지하게 딜레이가 걸리기 시작했고 더 이상 로컬에서 개발 할 수 없는 상태에 빠졌다.

배포파일을 톰캣에 올리기만 하는데 왜 이렇게 느릴까란 생각에

Tomcat Catalina log 를 열어보니 이상한 경로가 중복적으로 보이면서 여유공간이 부족해 캐시크기를 늘리라는 것이었다.

그래서 배포된 artifacts 폴더를 한번 열어봤다.

그리고 나는 경악했다.

배포파일이 classes 폴더 하위로 계속 쌓여있는 것이 아닌가...

수많은 배포판이 중복적으로 쌓여서 동작하고 있었고 무한 반복이었다.

classes/
  └─ artifacts/
      └─ Project_war_exploded/
          └─ WEB-INF/
              └─ classes/
                  └─ artifacts/
                      └─ ... 무한 순환 ...

원인은 무엇이었을까?

이 프로젝트의 artifacts output directory 는 다음과 같았다.

D:\workspace\Project\classes\artifacts\Project_war_exploded

인간적인 시점에서는 이게 뭐가 문제가 되냐 할 수 있는 부분인데...

디렉토리 경로 가운데 있는 classes 경로에 아티팩트를 생성했기 때문에 문제를 일으킨건데

프로젝트 빌드가 되면 ROOT/classes 경로에 컴파일된 클래스들을 생성해 놓고

아티팩트 output directory/WEB-INF/classes 에 복사한다.

근데 그 아티팩트가 classes 경로에 생성되었으니 최초 생성시에는 문제가 되지 않으나

다음번 빌드할때 이것이 복사되어 아티팩트내에 아티팩트가 또 생성이 된 상태가 되고

이것이 반복되면 그 아래로 계속 복사가 되게 된다.

D:\workspace\Project\classes\artifacts\Project_war_exploded/WEB-INF/classes/artifacts/Project_war_exploded/...

결국 이것이 쌓이고 쌓이다 보면 점차 배포 파일 자체가 커져 아티팩트를 생성하는데 오래 걸리게 되고

톰캣이 힘들어지게 된다.

(파일 사이즈 봤더니 2기가가 넘었음 ^^;;)
(왜 저렇게 설정을 잡아놨나 의문^^;;)

그래서 아티팩트 생성위치를 바꿔주고 다시 빌드해서 해결 하였다.

D:\workspace\Project\output\artifacts\Project_war_exploded

이후로 프로젝트 동작하는데 부하가 걸리거나 버벅이는 증상은 완전 해소 되었다.

[Jenkins] docker build 수행시 권한 문제 해결.(permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock)

종벌 — Fri, 31 Oct 2025 15:27:24 +0900

젠킨스 파이프라인 Jenkinsfile 을 이용해 도커 빌드를 해야하는데

권한 설정을 해주지 않으면 아래와 같은 에러가 발생하게 된다.

[Pipeline] sh
+ docker build -t test:1.0 -f Dcokerfile .
ERROR: permission denied while trying to connect to the Docker daemon socket at 
unix:///var/run/docker.sock: Head "http://%2Fvar%2Frun%2Fdocker.sock/_ping": 
dial unix /var/run/docker.sock: connect: permission denied

딱봐도 권한 에러

도커 데몬은 root 권한에서 실행하며 /var/run/docker.sock 의 소유자는 root:docker 이다.

그래서 젠킨스가 docker 를 수행하려고 하면 권한 에러가 발생한다.

간단하게 젠킨스를 docker 그룹에 포함시키면 된다.

usermod -aG docker jenkins

[root@localhost /]# id jenkins
uid=993(jenkins) gid=989(jenkins) groups=989(jenkins),986(docker)

젠킨스계정이 젠킨스그룹과 도커그룹에 포함된 것을 확인 할 수 있다.

다시 젠킨스 job 을 수행하면 아까의 권한 문제는 해결 되고 도커 이미지 빌드가 잘 되는 것을 확인 할 수 있다.

권한 그룹에 추가하는 것 말고도 docker.sock 파일의 권한을 666 으로 주는 경우도 있는데

모든 권한에서 접근 가능하므로 지양하는 것이 좋겠다.

[Docker] 리눅스에 설치하기. (RHEL 계열)

종벌 — Tue, 28 Oct 2025 17:47:09 +0900

레드헷 계열 리눅스에 도커를 설치하려고 하면 내가 원하는 도커는 없고 이상한 녀석이 있다.

[root@localhost ~]# dnf install docker
Last metadata expiration check: 1:09:09 ago on Tue 28 Oct 2025 04:00:26 PM KST.
Dependencies resolved.
=====================================================================================================================
 Package                          Arch        Version                                           Repository      Size
=====================================================================================================================
Installing:
 podman-docker                    noarch      4:4.9.4-23.module+el8.10.0+2064+309a12a4          appstream      117 k
Installing dependencies:
 conmon                           x86_64      3:2.1.10-1.module+el8.10.0+2001+6a33db9f          appstream       57 k
 container-selinux                noarch      2:2.229.0-2.module+el8.10.0+2001+6a33db9f         appstream       70 k
 containernetworking-plugins      x86_64      1:1.4.0-6.module+el8.10.0+2001+6a33db9f           appstream       23 M
 containers-common                x86_64      2:1-82.module+el8.10.0+2001+6a33db9f              appstream      147 k
 ...
Enabling module streams:
 container-tools                              rhel8

Transaction Summary
=====================================================================================================================
Install  21 Packages

레드헷 진영에서 밀고 있는 컨테이너 엔진이라고 한다.

진짜 도커와 다르므로 삭제하고 실제 도커를 설치하는 것이 좋겠다.

충돌이 날 수 있으니 모두 삭제를 수행하고

도커 레포지토리를 바라보게 한 후 설치를 진행한다.

dnf remove docker \
 docker-client \
 docker-client-latest \
 docker-common \
 docker-latest \
 docker-latest-logrotate \
 docker-logrotate \
 docker-engine \
 podman \
 runc

dnf -y install dnf-plugins-core
dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

[root@localhost ~]# dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
Last metadata expiration check: 0:01:05 ago on Tue 28 Oct 2025 05:21:50 PM KST.
Dependencies resolved.
=====================================================================================================================
 Package                       Arch       Version                                         Repository            Size
=====================================================================================================================
Installing:
 containerd.io                 x86_64     1.7.28-1.el8                                    docker-ce-stable      49 M
 docker-buildx-plugin          x86_64     0.29.1-1.el8                                    docker-ce-stable      17 M
 docker-ce                     x86_64     3:28.5.1-1.el8                                  docker-ce-stable      21 M
 docker-ce-cli                 x86_64     1:28.5.1-1.el8                                  docker-ce-stable     8.7 M
 docker-compose-plugin         x86_64     2.40.2-1.el8                                    docker-ce-stable      15 M
Installing dependencies:
 container-selinux             noarch     2:2.229.0-2.module+el8.10.0+2001+6a33db9f       appstream             70 k
 fuse-common                   x86_64     3.3.0-19.el8                                    baseos                21 k
 fuse-overlayfs                x86_64     1.13-1.module+el8.10.0+2001+6a33db9f            appstream             69 k
 fuse3                         x86_64     3.3.0-19.el8                                    baseos                54 k
 fuse3-libs                    x86_64     3.3.0-19.el8                                    baseos                95 k
 libcgroup                     x86_64     0.41-19.el8                                     baseos                69 k
 libslirp                      x86_64     4.4.0-2.module+el8.10.0+2001+6a33db9f           appstream             70 k
 slirp4netns                   x86_64     1.2.3-1.module+el8.10.0+2001+6a33db9f           appstream             55 k
Installing weak dependencies:
 docker-ce-rootless-extras     x86_64     28.5.1-1.el8                                    docker-ce-stable     3.4 M
Enabling module streams:
 container-tools                          rhel8

Transaction Summary
=====================================================================================================================
Install  14 Packages

[root@localhost ~]# docker -v
Docker version 28.5.1, build e180ab8

도커가 잘 설치 되었고 도커를 실행하면 된다.

systemctl enable --now docker

도커 공식 참고자료

RHEL

Learn how to install Docker Engine on RHEL. These instructions cover the different installation methods, how to uninstall, and next steps.

docs.docker.com

[Oracle] Flashback Query 사용하여 삭제된 데이터 복구하기.

종벌 — Tue, 21 Oct 2025 11:39:28 +0900

보통 Delete 쿼리를 조건절 잘못작성하여 삭제되지 말아야할 데이터가 삭제되는 경우가 있다.

급하게 일처리 하다 보면 실수를 하기 마련...

다행히 oracle 은 일정시간 동안, UNDO(undo_retention) 보관시간 내에 데이터를 조회 할 수 있다.

예를 들어 조건절 없이 table 에 데이터를 모두 삭제했다고 치자

DELETE FROM sample
-- where ...

OMG...

당황하지 말고 삭제 시점 전 으로 조회하여 데이터 추출하여 복구하면 된다.

예를 들어 내가 09:03:45 경 삭제를 했다고 치자

SELECT * FROM sample AS OF TIMESTAMP TO_TIMESTAMP('2025-10-21 09:02:00','YYYY-MM-DD HH24:MI:SS')

이렇게 분,초 까지 세분화해서 삭제된 데이터를 추출할 수 있다.

* 직접 날짜시분초를 작성하지 않고 SYSDATE에서 분을 빼도 된다.

일단 데이터가 존재하지 얼마나 다행인가

이제 복구할때는 여러가지 방법이 있다.

테이블이 완전 비어져 있다면

INSERT INTO sample
SELECT * FROM sample AS OF TIMESTAMP TO_TIMESTAMP('2025-10-21 09:02:00','YYYY-MM-DD HH24:MI:SS')

이렇게 해도 상관 없겠지만

데이터가 계속 인입되고 있다거나 일부만 삭제했다면 temp 테이블에 먼저 백업을 떠논 후 데이터를 넣어주는 것이 안전하겠다.

NOT EXISTS 조건 걸어서 중복 제거하고 넣어줘도 된다.

CREATE TABLE sample_tmp as
SELECT * FROM sample AS OF TIMESTAMP TO_TIMESTAMP('2025-10-21 09:02:00','YYYY-MM-DD HH24:MI:SS')

이렇게 temp 테이블 만들어서 빼놓고 조정을 하고 복구해도 된다.

그럼 UNDO 보관시간은 얼마나 되냐 궁금할 수 있는데

SELECT name, value
FROM v$parameter
WHERE name = 'undo_retention';

undo 유지 시간은 디폴트로 900 일 것이다.

대략 15분 (900/60) 인데

이것이 15분간만 유지하겠다는 아니고 최소한 15분은 유지하려고 노력하겠다여서

UNDO_RETENTION은 “최소 보존 목표값”일 뿐, 절대값이 아님

오라클 공식 문서의 표현:

“UNDO_RETENTION specifies the minimum time in seconds that Oracle attempts to retain old undo information for consistent read and flashback.”
‘900초 동안은 최소한 유지하려고 노력하지만, 공간이 남으면 더 오래 유지한다’

따라서

UNDO 테이블스페이스에 공간 여유가 많을 경우,
이전 트랜잭션의 UNDO 블록이 덮이지 않고 그대로 남아 있음 → 그만큼 과거 시점으로 Flashback Query가 가능해지는 것이다.

그래서 더 오래 남겨야한다면 조정을 통해 유지하게 끔 해줄 필요는 있다.

[Linux] PuTTy 테마 색상 바꾸기 (기존 세션까지 바꾸기)

종벌 — Thu, 4 Sep 2025 15:05:06 +0900

리눅스 서버 관리 툴로 Putty 를 가장 많이 사용하는데

블랙화면이 지겨워 기분전환으로 테마를 바꿔보고자 한다.

putty-color-themes-master.zip

0.45MB

putty-color-themes/images/readme.md at master · AlexAkulov/putty-color-themes

PuTTY Color Themes. Contribute to AlexAkulov/putty-color-themes development by creating an account on GitHub.

github.com

위 깃허브에서 테마 색상 한눈에 보시면 되고

직접 해당 깃허브에서 다운로드 받으셔도 되고 제가 올려놓은 zip 파일 다운로드 받으셔도 됩니다.

받으신 zip 파일 압축을 풀고

_puttycolor.js 파일만 기존 putty 설치 경로에 복붙해줍니다.

zip 압축 해제 파일

putty 설치경로

그리고 위 깃허브 링크에서 테마 색상을 보신 뒤

원하는 색상의 레지스트리를 실행하시면 일단 putty 의 기본 default 색상은 변경되게 됩니다.

putty 기본 색상 변경 확인

서버 아무대나 새롭게 들어가면 색상이 변경된 것을 확인 할 수 있습니다.

하지만 문제는 기존에 저장되어있는 세션들은 색상이 바뀌질 않습니다.

이미 색상이 포함되어 저장 되어 있기 때문에 그 저장된 색상을 바꿔주지 않는 이상 옛날 검정색으로 나옵니다.

세션이 한두개면 상관없지만 수십개의 세션이 있다면....

그래서 일괄로 변경된 컬러로 바꿔주는 스크립트를 아래에 공유 합니당 (w GPT)

# PuTTY/KiTTY 기존 세션에 Default Settings의 Colour0~21을 강제 복사
# (32/64비트/ KiTTY 레지스트리 경로 모두 시도)

$roots = @(
  'HKCU:\Software\SimonTatham\PuTTY\Sessions',                  # 64비트 PuTTY
  'HKCU:\Software\WOW6432Node\SimonTatham\PuTTY\Sessions',      # 32비트 PuTTY
  'HKCU:\Software\9bis.com\KiTTY\Sessions'                      # KiTTY(레지스트리 사용시)
)

$colourKeys = 0..21 | ForEach-Object { "Colour$_" }

foreach ($root in $roots) {
  if (!(Test-Path $root)) { continue }

  $def = Join-Path $root 'Default%20Settings'
  if (!(Test-Path $def)) { Write-Host "Default Settings 없음 → $root"; continue }

  # Default Settings에서 색상 읽기
  $vals = @{}
  foreach ($k in $colourKeys) {
    try {
      $v = (Get-ItemProperty -Path $def -Name $k -ErrorAction Stop).$k
      if ($null -ne $v) { $vals[$k] = $v }
    } catch {}
  }
  if ($vals.Count -eq 0) { Write-Host "Colour* 없음 → $def"; continue }

  # 모든 세션에 덮어쓰기
  Get-ChildItem $root | Where-Object { $_.PSChildName -ne 'Default%20Settings' } | ForEach-Object {
    $path = $_.PsPath
    foreach ($k in $colourKeys) {
      New-ItemProperty -Path $path -Name $k -Value $vals[$k] -PropertyType String -Force | Out-Null
    }
    New-ItemProperty -Path $path -Name UseSystemColours -Value 0 -PropertyType DWord -Force | Out-Null
    Write-Host "색상 적용 → $($_.PSChildName)"
  }
}
Write-Host "완료. PuTTY 다시 실행해서 확인하세요."

위 쉘 스크립트를 복사해서 PowerShell 에 복붙하시면

putty 의 모든 세션이 내가 고른 테마색상으로 일괄 치환됩니다.

저장된 세션을 로드해보면 변경된 것을 확인 할 수 있습니다.

PuTTY Color Themes (색상 테마 변경)

터미널을 오랫동안 보면 눈의 피로도가 높아집니다. 피로도가 적은 색상으로 변경해서 사용하면 좋습니다. PuTTY Color Themes https://github.com/AlexAkulov/putty-color-themes GitHub - AlexAkulov/putty-color-themes: PuTTY

zosystem.tistory.com

[Linux] rsync - 리눅스간 파일/폴더 전송.

종벌 — Tue, 26 Aug 2025 11:01:44 +0900

리눅스간 파일, 폴더를 복사할때 scp 를 이용해 통째로 복사를 수행한적이 있다.

최초로 데이터를 복사할때는 scp 를 써도 무방하지만

기존에 데이터가 있는 상태에서 scp 를 사용하면 전체 파일을 전부 복사해서

중복된 자료는 덮어쓰기가 된다.

즉, 불필요한 전송 리소스를 사용하게 되는 것.

[Linux] scp - 리눅스간 파일/폴더 전송.

서로 다른 리눅스 서버간 파일을 통째로 옮겨야 해서 scp (secure copy) 를 써보기로 했다.(얘 없었으면 ftp로 내컴에 옮긴담에 목적지 서버에 밀어 넣는 짓을 하고 있었겠지...? ㅋ) scp 대상파

jong-bae.tistory.com

이번에는 rsync 를 사용하여 없는 파일 또는 업데이트 되어질 파일만 전송해보려고 한다.

rsync

사용법은 간단한 옵션을 부여하여 중복, 업데이트 만 체크할 수 있다.

rsync -avz /home/test/ user@127.0.0.1:/home/test2

옵션 설명:

-a : 권한, 시간, 심볼릭 링크 등 보존 (archive 모드)
-v : verbose (상세 출력)
-z : 전송 시 압축
-n : 전송은 하지 않고 실행결과만 출력 (시뮬레이션 모드)
--ignore-existing : 대상에 이미 존재하는 파일은 덮어쓰지 않음
--update : 수정 시간이 더 최신인 경우에만 덮어씀

데이터 전송전에 복사될 파일들을 체크하기 위해 -n 을 붙여주면 실제 전송은 수행하지 않는다.

같은 서버내에서 복사시에는 -z 압축 전송 옵션은 굳이 필요 없어보인다. (타 서버에 옮길때는 좋음)

# 새로운 파일만 추가 (기존 파일은 절대 덮어쓰지 않음)
rsync -avz --ignore-existing /home/test/ user@127.0.0.1:/home/test2

# 기존 파일보다 새로운 게 있으면 업데이트
rsync -avz --update /home/test/ user@127.0.0.1:/home/test2

# 시뮬레이션만 (어떤 파일이 이동될지 확인)
rsync -avzn --update /home/test/ user@127.0.0.1:/home/test2
rsync -avzn --ignore-existing /home/test/ user@127.0.0.1:/home/test2

-avzn 옵션으로 중복, 업데이트 시뮬레이션 해보면 어떤 파일들이 추가되고 변경되었는지 확인 할 수 있고

-n 옵션을 제거하고 수행하면 시뮬레이션 대로 파일 전송을 수행한다.

* 최상위 폴더에서 시뮬레이션 돌려보면 파일 외에도 기존에 있는 폴더들도 다 조회되는데 파일들만 따로 보고 싶다면 아래와 같이 grep 하여 파일만 따로 확인 하는게 좋겠다.

rsync -avzn --ignore-existing /home/test/ user@127.0.0.1:/home/test2 | grep -v '/$'
rsync -avzn --update /home/test/ user@127.0.0.1:/home/test2 | grep -v '/$'

[Docker] Nodejs 모듈 버전 충돌 이슈, 다운그레이드 실행하기

종벌 — Mon, 18 Aug 2025 17:21:15 +0900

노드 템플릿을 하나 사용하게 되어 셋팅 후 npm install 을 수행했는데

아래와 같이 오류가 났다.

npm error code 3221225477 
npm error path D:\...\node_modules\node-sass 
npm error command failed 
npm error command C:\WINDOWS\system32\cmd.exe /d /s /c 
node scripts/install.js 
npm error A complete log of this run can be found in: C:\...\AppData\Local\npm-cache\_logs\2025-08-18T03_06_28_934Z-debug-0.log

node-sass의 문제인건 아는데 정확하게 뭔지 알 수 없기에 로그 파일을 찾아 열어보았다.

verbose pkgid node-sass@7.0.3 
error code 3221225477
...

node-sass 7 버전으로 내 pc에 설치된 nodejs 와의 버전 호환 문제였다.

설치된 나의 node 버전은 22였다.

Node 20 → node-sass 9.0+ 필요
Node 18 → node-sass 8.0+ 필요
Node 17 → node-sass 7.x 가능
Node 16 → node-sass 6.x+ 가능

node 17 로 다운그레이드가 필요한 상황인데

어차피 템플릿 빌드용으로 필요해서 도커를 이용해서 해당 문제를 해결하기로 했다.

Docker

docker pull node:17.9.1
docker run -it --name node17 -v {#템플릿경로}:/app -v ats_node_modules:/app/node_modules -w /app node:17.9.1

모듈 호환되는 노드17 버전을 가져온 후 실행했다.

템플릿 경로에서 docker 를 실행하면 경로를 .(dot) 으로 간편하게 작성할 수 있다.

그리고 그렇게 진행하니 이슈가 하나 있었는데

도커 Volume 명을 기존 템플릿 경로에 있는 폴더(node_modules)랑 동일하게 했더니

도커 Volume 을 보는게 아니라 실제 경로를 바라보게 되었다.

그래서 정확하게 마운트 지점을 알려주거나

볼륨명을 다르게 하면 도커 볼륨으로 잘 마운트 되는 것을 확인했다.

이제 도커 노드에서 npm install 을 수행하니 버전 충돌 오류 없이 잘 모듈들이 생성되었고

템플릿을 컴파일할 gulp 로 태스크 러너가 잘 동작하는 것을 확인 했다.

# npx gulp
[08:15:41] Using gulpfile /app/gulpfile.js
[08:15:41] Starting 'default'...
[08:15:41] Starting 'clean'...
[08:15:41] Finished 'clean' after 228 ms
[08:15:41] Starting 'fileIncludeAll'...
[08:15:43] Finished 'fileIncludeAll' after 1.6 s
[08:15:43] Starting '<anonymous>'...
[08:15:43] Finished '<anonymous>' after 168 ms
[08:15:43] Starting 'scss'...
[08:15:47] Finished 'scss' after 3.68 s
[08:15:47] Starting 'browserSync'...
[08:15:47] Finished 'browserSync' after 10 ms
[08:15:47] Starting 'watch'...
[Browsersync] Access URLs:
 ----------------------------------------------
       Local: http://localhost:3000/index.html
    External: http://172.17.0.3:3000/index.html
 ----------------------------------------------
          UI: http://localhost:3001
 UI External: http://localhost:3001
 ----------------------------------------------
[Browsersync] Serving files from: ./src/.tmp
[Browsersync] Serving files from: ./src
[Browsersync] Serving files from: ./
[Browsersync] Watching files...
[Browsersync] Couldn't open browser (if you are using BrowserSync in a headless environment, you might want to set the open option to false)