#Yobine

다음 내용은 Obsidian 의 정식 Help 싸이트 내용을 ChatGPT 로 번역 후 수정된 내용입니다. Help 싸이트: Sync your notes across devices - Obsidian Help

Obsidian 을 사용하여 Tistory 글 작성은 두번째 이며, 그동안 작성했던 글을, 컴퓨터에만 저장하기 보다는, 외부 클라우드 저장소를 통해 저장하고 불러 들여오고 하면 편할 것 같다는 생각을 하게 되었는데, 마침, 내가 사용하는 PC 외 다른 기기들 (아이폰, 집PC, 회사PC 등) 과 동기화 할 수 있는 방법이 검색되어 해당 내용을 적용해 보며 공유합니다.

동기화란, Obsidian 으로 기록/작성 된 최신의 노트 들을 내가 사용하는 모든 기기 (랩탑 이나 아이폰 등)에서 읽고 작성할 수 있는 기능입니다.

기본적으로 Obsidian 에서 제공하는 Obsidian Sync 와 애플의 iCloud Drive 가 있으며, 이 중 다른 기기 간에 노트를 동기화하는 가장 쉬운 방법은 - Obsidian Sync 를 사용하는 것입니다. 이미 - Obsidian Sync 구독(유로)을 가지고 있다면 - Obsidian Sync 설정 방법을 참조하십시오.

다른 동시에 여러 동기화 서비스를 사용하는 것(예: Obsidian Sync 및 Dropbox)은 데이터 손실, 손상 및 기타 문제를 일으킬 수 있으므로 주의해야 합니다. 다른 서비스와 함께 Obsidian Sync를 사용하는 방법에 대해 자세히 알아보려면 여기 를 확인하십시오.

여러 PC 가 노트 동기화 하기

만약 Obsidian 을 모바일 기기에서 사용하지 않는다면, 로컬 폴더를 클라우드 저장소로의 동기화를 위해 다음과 같은 클라우드 서비스를 사용할 수 있습니다.

• Dropbox
• Google Drive
• iCloud Drive
• OneDrive
• Syncthing

노트를 동기화하려면 사용 중인 서비스의 지침을 따라 로컬 파일 시스템의 폴더를 동기화하고, 그런 다음 모든 데스크톱 기기에서 기존 Valut 로 폴더를 열면 됩니다.

아이폰, 아이패드 와 노트 동기화 하기

iPhone 및 iPad에서 노트 동기화 iPhone 또는 iPad에서 노트를 동기화 하기 위해 다음 클라이드 저장소를 공식적으로 지원합니다:

• Obsidian Sync
• iCloud Drive

참고: 다음 서비스들을 통한 아이폰, 아이패드와 노트 동기화 지원은 되지 않습니다. 이러한 서비스를 사용하여 iOS 기기에서 노트를 동기화하는 방법을 발견하면 커뮤니티 채널에서 알려주세요.

• Dropbox
• Google Drive
• OneDrive
• Syncthing
• iCloud Drive

iCloud Drive

Obsidian은 로컬 파일 시스템으로 iCloud Drive를 사용할 수 있습니다.

macOS에서 iCloud Drive를 사용할 때, 데스크톱 앱의 설치 버전을 v0.13.0 이상으로 업데이트해야 합니다.

노트: iCloud 저장 공간 한도를 초과하지 마십시오. 동기화가 중지될 수 있습니다.

iCloud Drive에 새로운 Vault 만들기

iPhone 또는 iPad에서 iCloud Drive에 새 Vault 를 만들려면 다음 단계를 따르십시오:

1. 새로운 Vault 만들기를 탭합니다.
2. Vault name에 Vault의 이름을 입력하십시오.
3. Store in iCloud를 활성화합니다.
4. Create를 탭합니다.

Obsidian은 iCloud Drive 내부에 새 폴더를 생성합니다. 컴퓨터에서 iCloud Drive 폴더를 Vault로 열려면 다음을 수행하십시오:

1. 컴퓨터에서 Obsidian을 엽니다.
2. Open folder as vault의 오른쪽에서 Open을 선택합니다.
3. iCloud Drive → Obsidian으로 이동합니다.
4. 동기화하려는 Vault 이름으로 폴더를 선택합니다.

기존 Vault 와 iCloud Drive 동기화하기

기존 Vault를 iCloud Drive로 동기화하려면, 우선, iCloud Drive에 비어 있는 Vault를 만들고 다른 기기의 노트를 비어 있는 Vault로 이동해야 합니다.

iCloud Drive에 새로운 비어 있는 Vault를 만들려면 다음을 수행하십시오:

1. Create new vault를 탭합니다.
2. Vault name에 동기화하려는 Vault와 동일한 이름을 입력합니다.
3. Store in iCloud를 활성화합니다.
4. Create를 탭합니다.

노트를 새 iCloud Drive 폴더로 이동하려면 다음을 수행하십니다:

1. 컴퓨터에서 iCloud Drive 폴더를 엽니다.
2. Obsidian 폴더를 엽니다. 몇 분이 걸릴 수 있습니다.
3. 기존 Vault의 파일을 Vault 이름으로 된 폴더로 이동합니다.

iCloud는 파일을 모바일 기기로 동기화합니다. Vault의 크기에 따라 몇 분이 걸릴 수 있습니다.

Working Copy

Working Copy 노트를 Git 리포지토리에 저장하는 경우 Working Copy 라는 iOS용 Git 클라이언트를 사용하는 것을 추천합니다.

Working Copy 를 사용하여 동기화하는 방법:

1. iPhone 또는 iPad에 비어 있는 Vault 를 만듭니다.
2. Setup Folder Sync 동작을 사용하고 비어 있는 Vault 를 선택합니다.
3. Working Copy 앱을 사용하여 Vault에 대한 변경 사항을 커밋하고 푸시합니다.

참고: 이 방법은 공식으로 지원하지 않지만 몇몇 사용자가 Working Copy를 사용하여 노트를 성공적으로 동기화했다고 보고했습니다.

X 사용으로 동기화 불가능한 이유

많은 사용자들이 파일 동기화에 다른 서비스를 사용을 원하는 것을 잘 알고 있습니다.

Obsidian은 iOS 의 다른 Markdown 편집기와는 다르게 작동합니다. 1Writer 및 iA Writer와 같은 편집기는 한 번에 하나의 노트에 액세스하며 내장 문서 지원을 사용할 수 있습니다.

반면에 Obsidian 의 많은 기능들이 Vault 전체에 대한 액세스를 필요로 합니다… 예를 들어 파일 이름을 변경하면 Obsidian은 해당 파일에 링크된 Vault 내의 모든 파일을 업데이트 합니다.

지원되는 위치 이외의 수천 개의 노트로 이루어진 전체 폴더 구조를 읽고 수정하고 모니터링하는 시스템을 구현하는 것은 복잡합니다. 이러한 제한은 앞으로 해결할 예정 입니다.

개발자라면 각 개별 동기화 서비스에 대한 Web API를 사용하는 플러그인을 만들 수 있습니다.

내 Vault는 어디에 저장되나요?

Vault 를 만들 때 iCloud Drive를 사용하지 않는다면 Obsidian은 해당 Vault를 Obsidian 앱의 로컬 파일 시스템에 저장합니다. 다른 앱인 Working Copy와 같이 Obsidian 폴더를 파일 시스템에서 선택하여 Vault에 액세스할 수 있습니다.

주의: Obsidian 앱을 삭제할 때 iOS에서 로컬 파일 시스템에 저장된 노트가 삭제됩니다. Obsidian 앱을 삭제하기 전에 노트를 백업하십시오.

Android에서 노트 동기화

Android 기기에서 노트를 동기화하는 가장 쉬운 방법은Obsidian Sync 를 사용하는 것입니다.

Obsidian은 Android 기기의 로컬 폴더에 노트를 저장하므로, 폴더 동기화를 허용하는 어떠한 앱을 사용할 수 있습니다.

• Dropsync
• FolderSync

Obsidian은 Documents 폴더 내의 Obsidian 폴더를 생성합니다. Documents/Obsidian 하위의 모든 폴더는 Obsidian Vault로 간주됩니다.

일부 클라우드 저장소 서비스인 OneDrive와 같은 서비스는 파일을 사용할 때만 다운로드하고 나중에 로컬에서 제거하여 공간을 확보할 수 있게 해줍니다. 이 파일들은 더 이상 로컬에서 사용할 수 없기 때문에 Obsidian Sync는 이 파일들이 삭제된 것으로 간주하고 원격 보트에서 제거합니다.

Files On-Demand 및 유사한 기능과 함께 Obsidian Sync를 사용하려면 서비스를 구성하여 항상 파일을 장치에 보존하도록 해야 합니다.

<============ Posted using Obsidian ==>

Obsidian - Sharpen your thinking 이라는 메모 툴을 사용하게 되었습니다.

테스트 용도로, Obsidian 메모 툴을 사용하여, 티스토리에 글 남겨봅니다.

Obsidian 은 무료 메모 툴이며, windowsOS, MacOS, LinuxOS 등 모두 지원하며 모바일 어플도 있습니다.

생각보다 사용이 쉽고, 여러가지 기능들과 plug-in 들이 많아서, 자주 사용하게 될 것 같네요.
사용하면서 발견하는 기능들에 대한 생각 공유를 해야 할 것 같아요.

참고로, 이 글은 windowsOS 용 Obsidian 에서 적은 글이며, Tistory 로 보낼 때 사용 된 plug-in 은 GitHub - anpigon/obsidian-tistory-plugin: 옵시디언(Obsidian) 티스토리 플러그인 입니다.

생각보다 설치도 간편하고, 간단하게 글을 보내고 수정할 수 있어서 플러그인 추천합니다.

아직까지는 그림 업로드 기능이 없어서 옵시디언 Imgur 플러그인을 사용하지만, 해당 플러그인 사용도 간단합니다.

<============ Posted using Obsidian ==>

스팀덱 구매 후 설정 관련해서 찾아보면 #CryoByte33 의 #Steam-Deck-Utility 설정 부분이 빠지지 않고 나온다. 설정은 하라는데로 했고, 복잡한 원리는 사실, 게임이 잘 되기 때문에, 알고 싶은 생각은 없었다.  이 설정을 왜 하는지, 향상되는 이유가 무엇인지 궁금하지 않았다.

하지만.. 이 유틸리티의 기본적인 원리? 에 대해 질문을 받았으며, 이를 답변해 주기 위해, 우선 내가 먼저 이해를 해야 했고, 지루한? 유튜브(youtube) 비디오 내용을 시청 하였다. CryoByte33 의 깃허브(Github) 에 공유된 내용도 정리하여 확인 해 보았다.

*참고로 번역은 #ChatGpt (https://chat.openai.com/) 의 도움을 받았다.

- 요약

스팀덱은 알려진 바와 같이 CPU + GPU (그래픽카드) 가 합쳐진 APU 를 사용 하며, 16기가 램을 탑재하였다. 하지만 GPU 용 VRAM 이 별도로 없어서, 탑제된 16GB 의 시스템 램 (RAM) 을 공유 한다. 일 (Task)들을 처리 하면서, 필요하면 서로 램 공간을 사용하는 식으로 작동 되며, 특별히 Valve 에서 1GB 램을 GPU 전용으로 사전 설정하였다. 그래서 15기가의 램 공간이 CPU 와 GPU 간 공유하도록 설정이 되었는 상태이다.

CryoByte33 의 steam deck utilities 는 swap 과 swapiness 의 허용 사이즈 변경 하여, 1GB 의 GPU 용 램 사이즈를 4GB로 높이더라도, CPU 가 필요한 RAM 공간의 대체 공간을 ssd 에 16GB 정도로  설정하여, 보다 안정적으로 메모리 사용의 효율을 높여준다. 

CryoByte33 의 steam deck utilities 는 swap 과 swapiness 의 허용 사이즈 는 "recommended" 로 설정하면 되며, VRAM 사이즈 변경은 스팀덱 부팅 시 BIOS 집입하여 UMA Frame Buffer Size 를 1 - > 4로 변경을 해주면 된다.

다음은, CryoByte33 의 steam deck utilities 를 통해 어떤 부분이 변경이 되었고, 왜 되었으며, 어떻게 되었는지 CryoByte33 의 Github 내용을 ChatGPT 의 번역 기능의 도움을 받아 정리해 보았다.

- Swap Size

- Swappiness

- sysctl 매개 변수라는 스왑니스. sysctl 은 뭘까 궁금해서 찾아보았다.

- Transparent Hugepages

- Shared Memory in Transparent HugePages

- Compaction Proactiveness

- Hugepage Defragmentation

- Page Lock Unfairness

- 마치며

대부분의 내용이 리눅스 (Linux) 관련된 내용으로, 번역한 내용은 크게 와닿는 부분은 없지만, 이를 통해 스팀 OS 및 리눅스 에 대해 궁금한 점도 많아졌고, 그외에도 시스템 적인 부분이 명령어, 혹은 스크립트를 통해 변경이 가능하다는 것도 알게 되었다. 신기한 점은 이렇게 수정이 가능한 것을 알아냈다는 점이다. 내용에 나오는 Emin 이란 분이 이 리눅스 깊숙한 최적화에 큰 도움을 주신 분이라고 한다. 

Emin 의 Github

여하튼, 이 유틸리티를 설치하고, retrodeck 에서 스위치 에뮬레이션이 아주 안정적으로 구동이 되고 있으며, 테스트 해본 게임 중엔 The Division, Death Stranding, Tekken 7, Call of Duty 시리즈 등, 모두 안정적인 프레임 을 유지 했으며, 낮음 설정의 그래픽도, 상향 조정이 가능해질 만큼 게임 내 그래픽 퀄리티 와 성능이 좋아졌다.

이 유틸리티는 개인 적으로도, 그리고 많은 사람들이 강력 추천하는 프로그램이니, 스팀덱으로 게임 진행할 때 버벅거림을 경험한다면 설치해 보도록 한다.

항상, Steam (이하 스팀)이 만든 기기들 (스팀머신, 컨트롤러, 링크 등) 의 소식과 리뷰, 그리고 스팀OS 의 소식도 전해 들으며, 언젠가는 스팀 플랫폼 게임들을 구동시킬 기기 하나, 제대로 만들 것 같은 느낌으로 항상 관심있게 관련 소식을 기다리고 있었는데, 마침내, 2021년에 발표가 되고 2022년 초? 에 #스팀덱이 세상에 선을 보이게 되었다. 생각했던데로 물량이 별로 없어서, 국내엔 작년 8월 초부터 예약을 받아서 2022년 말쯤 배송 시작 된 것으로 기억된다. 

애플 제품들 (아이폰3gs, 아이패드 1세대 등) 과는 다르게, 여러 리뷰들을 보며, 바로 예약 구매 신청은 하지 않았다. 개인적으로 모니터 상의 리뷰들을 통한 간접 경험 보다는 직접 손으로 각 버튼들을 눌러보고, 무게나 화면 크기등을 직접 경험해 보고 싶었기 때문이다. 언젠가, 스팀덱을 구입한 주위 친구들을 통해, 확인해 보거나, 해외 나가서 직접 체험 후, 구입할 기회가 되면 구매를 하려고 했다. 음.. 올해 (2023) 초, 해당 기기를 리뷰해 본 친구의 말을 빌리자면, 스팀덱은 무조껀 구입해야 하는 기기이며, 내가 무척 좋아할 것이라는 말로 날 설레이게 했다.

직접 체험을 고대하는 중에, UMPC 혹은 hand-handled PC 시장엔 오래전부터 나왔던 Ayaneo 에서 window 10을 탑재한 비슷한 제품이 또 출시 되었고, Logitech 에서도, Logitech G Cloud 이라는 이름으로 안드로이드를 탑재하고 출시하면서, UMPC 시장을 나눠먹기 시작했다. 두 기기 모두 훌륭했고, 모양도 비슷했으며 성능도 우수 하다고 리뷰 되었다. 다음 스팀덱과 로지텍G클라우드 의 사양 비교 표에서, 내가 가장 중요하게 본 부분은 1. OS 와 2. 화면크기, 3. 배터리, 4. 확장 그리고  5. 가격 이다. 

이  5가지 사양 중 대부분 로지텍G클라우드 가 스팀덱 보다 우수했다. 단 하나.. 가장 큰 단점은 OS 였고, 그 이유는 다음과 같다. 그동안 스마트 기기들 (스마트폰, 웨어러블, IoT, ai 스피커 등)이 무수히 나오면서, 안드로이드 OS 는 v2.0 부터 v12까지 충분히 스마트폰과 태블릿들로 체험을 했다. 또한, 가지고 있는 기기들이 로지텍G클라우드 보다 성능이 더 좋은 기기들이기도 했고, 게임 관련 악세사리들도 있기 때문에, Logitech G Cloud 의 경험은 집에 있는 기기와 악세사리의 조합으로 충분히 충족이 되어, 구입 목록에서 자연스럽게 제외 되었다.

그에 비해, Ayaneo 는 말 그대로  UMPC (울트라 모바일 PC) 이며 최고의 hand-handle Gaming PC 라고 생각한다. 현재 Ayaneo2 말고도 여러가지 제품들이 나와 있고, 스펙도 어느 PC 못지 않을 성능으로 만들어져 나와서, 안돌아가는 게임이 없을 정도라는 한다. 가장 눈에 띄는 사양은 CPU AMD Ryzen 6800U 이다. 회사 내, 주변에서 이 프로세서를 탑재한 노트북으로 작업 하시는 분들이 꽤 여럿 있는데, 해당 기기에 대한 만족도가 꽤 높았다. (2022-2023). GPU 로 들어가 있는 라데온 기종은 사용해본적이 없어서 잘 모르겠지만, 검색해 보니, 3.4TFlops 의 성능까지 낼 수 있으며 4TFlops 성능을 내는 xbox series S 과 근접한 수치여서 꽤 준수한 그래픽 효과들을 보여줄 수 있을 것 같았다. 

실제로 이 유튜버분 (무적풍화륜) 의 리뷰를 보면,  Ayaneo 2 는 진정, 게임에 최적화된 기기라는 것을 알수 있었다. 리뷰에 나온 모든 게임들이 안정적으로 동작하였고, 디자인도 스팀의 투박한 모습과 비교해 보면 훨씬 좋아 보였다. 

자, 그럼 이 최고 사양의 Ayaneo2 를 구입해야 하는 것이 당연하다는 생각이 들기도 하지만, 가격 대비 만족도를 확인해 봐야 할 것이다. 1년 좀 전 쯤, 구입한 PS5 의 가격은 63만원.. 비슷한 시기에 구입한 인텔12세대 PC 의 가격은 100만원. 이 2가지만 비교했을 경우, 비싼 PC 구매 후 만족도가 컸어야 하지만, 여러가지 (설정 및 추가 구매 등) 생각 해보면 PS5 구매의 기쁨과 사용 시의 만족도는 PC 와는 비교할 수 없을 만큼 컸다. 설정도 간단하고, 사용도 쉬웠다. 그만큼 게임 판매 플랫폼이 있는 기기들은 플랫폼에서 판매되는 모든 소프트웨어들이 해당 기기에 거의 완벽에 가까울 정도로 맞춤 출시를 하기 때문에 설정 및 사용이 쉽게 되어 있다. 반면 모든 곳에서 구입해서 게임을 즐길 수 있는 windowsOS PC 그만큼 설치해아 하는 게임런처들도 많이 있으며 세일 때 구입을 많이 하기 때문에 게임들이 여러 판매 플랫폼에 분산되어 있는 단점이 있다. Ayaneo2 는 windowsSO PC 와 동일한 단점을 가지고 있기도 하지만, 가격 또한 Gaming (이하 게이밍) 노트북 처럼 매우 높게 책정되었다. (16기가 램, 1T SSD 기기 네이버 검색가격 1,790,000 원 2023/07/05) 아쉽게도.. 구매 목록에서 제외 되었다.

사실, WIndowsOS 에서 게이밍 경험이 더 많기도 하고, 게이밍 시 여러모로 수월 하기 때문에, 게임 판매 플랫폼의 이유 보다는 가격의 이유로 Ayaneo  2 를 구매하지 않았다가 좀더 사실적인 이유다. 만약, windowsOS PC 가 집에 없었다면.. 아마 고려 할 만한 기기 이지만, ubisoft 의 the division2 등 fps 만을 위한 pc 를 이미 가지고 있어서, 좀 애매한 기기가 될 것 같았다. (가격이 비싸다라는 다른 말 ㅋ)

결국, 스팀덱만 남았다. 직접 체험 해 보고 구입하자고 마음을 먹기 전에 이것 저것 검색을 통해 알아본 내용은 다음과 같다. 

• 구입 시 모델은 64기가를 구입 후, 필요한 용량은 ssd 혹은 microSD 로 추가한다.
• PD 충전 시 스팀덱이 사용하는 용량은 35W.
• Steam 에서 제공하는 게임 외, 다른 플랫폼에서 제공하는 게임들도 스팀OS 에서 가능하다.
  • Epic Games, GOG, Ubisoft Connect, Battle.Net 등
• 전동 스팀용 DOCK(이하 독) 은 DP 연결을 필요하면 구입하고 아니면 다른 제품들 사용이 가능하다.
• COMODO 에서 구입 시 2주정도 걸리며 배송비는 8,000원. 
• 다른 제품들보다 크고, 무겁고 구입 후 별로 안쓰게 된다. - 헙!@! 이런 글을 보니 중고마켓을 확인해 보았는데, 꽤 많이 등록되어 있어서, 중고 구매도 고민했다.
• Windows OS 설치가 가능하다 (듀얼부팅)

그리고 구입했다. 와이프에게 아주 작은 PC 여서 가지고 싶다고 전했고. #Steam 외 게임유통사들에서 구입한 게임들 중, 가볍게 즐기려고 했지만 PC 에 설치를 안하는 게임들을 하고 싶다는 전하지 않았다.

음.. 일하는데 필!요! 할지도 모른다.. 라고 해서 허가가 났다. 바로 뽀록이 나버렸지만.. ㅡ,.ㅡa

SteamDeck - 64Gb 용량 버전을 구매했으며, 2023-06 월 어느날 일렉트로마트에서 구입이 가능하다는 이야기를 듣고 사무실에서 가장 가까운 일렉트로마트 물량 확인 후 가보려고 했는데, 와이프가 동네 이마트 (일레트로마트가 있는) 간다며 구매해 주겠다고 했다. 

와이프: (일렉트로 마트 직원에게) 혹시 스팀 이라는 컴퓨터 있나요?

직원: 아.. 게임기요? 있습니다. 

딱!!! 걸렸으..  아웅.. 박스도 저렇게 생겼네.. 아놔.. ㅋㅋ

우선 정상적인 제품이 왔는지 꼼꼼하게 확인 해 보라는 글도 있고, 혹시 모르니 영상으로 남겨야 한다는 글도 있어서, 언박싱? 영상을 찍게 되었다. 

https://hbr.org/2020/03/best-practices-for-instant-messaging-at-work  (2020 년 03월 by Dustin York)

이 포스트는 위의 Dustin York 의 Best Practices for Instant Messaging at Work 내용을 ChatGPT 를 통해 요약하였습니다.

- 직장내 인스턴트 메신저 사용에 대한 모범 사례는 다음과 같습니다.

1. 목적과 용도를 명확히 이해하세요: 인스턴트 메시징은 실시간 소통과 빠른 결정에 유용하지만, 전화나 이메일 등 다른 커뮤니케이션 도구와는 목적과 용도가 다릅니다. 간단한 질문, 업무 업데이트, 미팅 일정 확인 등의 일상적인 대화에 사용하되, 복잡한 주제나 중요한 결정에는 더 적합한 도구를 사용하는 것이 좋습니다.

2. 적절한 메시지 전달 시기: 인스턴트 메시징은 실시간으로 이루어지지만, 상대방이 바쁠 수도 있으므로 메시지를 전달할 때 적절한 시간을 선택해야 합니다. 업무 시간에 다른 사람을 방해하지 않도록 주의하고, 긴급한 문제가 아니라면 비즈니스 시간 외에는 보내지 않는 것이 좋습니다.

3. 명확하고 간결한 메시지 작성: 인스턴트 메시징은 일반적으로 짧은 메시지를 주고받기 때문에 명확하고 간결하게 작성하는 것이 중요합니다. 불필요한 세부사항을 제거하고, 필요한 정보를 명확하게 전달하세요. 길고 복잡한 메시지는 효율성과 이해도를 저해할 수 있습니다.

4. 존중과 전문성 유지: 인스턴트 메시징은 빠르고 비공식적인 소통 방법이지만, 직장에서도 존중과 전문성을 유지해야 합니다. 다른 사람의 시간과 일정을 고려하고, 적절한 인사말과 단정한 언어를 사용하세요. 또한, 감정적인 반응이나 논쟁을 피하고, 긍정적이고 협력적인 태도를 유지해야 합니다.

5. 개인정보와 보안 유의: 인스턴트 메시징은 정보를 빠르게 공유하는 도구이므로 개인정보나 기밀 정보를 신중하게 다루어야 합니다. 개인정보를 포함한 민감한 정보는 보안을 강화한 다른 도구를 사용하는 것이 좋습니다. 또한, 악의적인 링크나 파일에 대한 조심도 필요합니다.

6. 적절한 그룹 채팅과 채널 사용: 인스턴트 메시징 플랫폼은 그룹 채팅이나 채널 기능을 제공합니다. 이를 통해 특정 프로젝트나 팀에 대한 대화를 진행할 수 있습니다. 필요한 경우 적절한 그룹 채팅을 만들고 관련 인원들을 초대하여 커뮤니케이션의 효율성을 높일 수 있습니다.

7. 기록과 검색 가능성: 인스턴트 메시징은 대화의 기록을 남기기 때문에 필요한 정보를 나중에 찾을 수 있습니다. 필요한 정보를 빠르게 검색하고 참조할 수 있는 방법을 익히고, 중요한 결정이나 약속은 다른 도구에도 기록하는 것이 좋습니다.

8. 효과적인 알림 관리: 인스턴트 메시징은 즉각적인 알림을 제공하기 때문에 알림 관리가 중요합니다. 중요한 메시지에 대해서만 알림을 받도록 설정하고, 직장 외의 시간에는 알림을 꺼두는 등 개인의 작업 흐름에 맞춰 알림을 관리하세요.

9. 비상 상황에서의 사용: 인스턴트 메시징은 긴급한 상황에서 유용할 수 있습니다. 하지만 심각한 긴급 사태에 대해서는 더욱 빠른 응답이 필요하므로, 전화나 대면 소통을 우선으로 고려하는 것이 좋습니다. 비상 시나리오에 대비하여 대체 커뮤니케이션 방법을 항상 알아두는 것이 좋습니다.

이러한 모범 사례를 따르면 인스턴트 메시징을 효과적으로 활용하여 직장에서의 효율성과 협업을 향상시킬 수 있습니다.

이번 포스팅에서는 Services 내 jenkins 서비스를 찾아 Status 를 Stop 으로 하고 나서,  특정 폴더 내 폴더들 및 파일들을 찾아 삭제를 하는 FolderControlCore 코드를 확인 해 본다.

1. Service (0) 을 던져, 서비스를 멈추고 나서 foreach 를 실행한다. 이때 deleteFolderName 은 스트링 배열로, Main code 에 다음과 같이 선언되어 있다. 

2. 배열 갯수만큼 foreach 가 돌면서 folderName 이 하나씩하나씩 클래스 멤버로 설정이 되며, SearchAndDeleteFolders() 메소드를 실행 시킨다. - 예) lastStable

3. SearchAndDeleteFolders() 메소드 는 설정된 directoryName 으로 폴더를 우선 찾아본다. SearchDirectories() 의 결과를  folderFound 변수에 담아 Count 확인 후, DeleteDirectories() 를 호출한다.

4. SearchDirectories() 메소드는 .Net 에서 지원하는 Directory 클래스 내 GetDirectoreis 메소드를 사용하여 검색한다. 이때 특정 폴더 (upperDirectoryName = %Jenkins HOME% ) 와 지울 폴더 (예) lastStable) 가 있는지 검색 하여 검색 결과를 IEnumerable<string> folderFound 로 전달한다.

5. DeleteDirectories() 메소드에서는 전달받은 폴더 경로들(list) 을 다시 한번 CheckPath() 메소드로 string 이 파일경로 형태의 string 포멧인지를 확인한다. CheckPath() 는 True/False 값을 넘기며, 경로확인이 되었을 때 .net framework 에서 지원하는 Directory 클래스의 Delete() 메소드를 이용하여 경로(path)를 삭제한다.

6. CheckPath() 는 정규 표현식으로 path 문자열을 확인 한다. .net framework 내 Regex 클래스의 IsMatch 메서드는 지정된 패턴과 경로 문자열이 일치하는지 확인하며, 일치하는 경우 메서드는 true를 반환하고, 그렇지 않은 경우 false를 반환한다.

• ^는 문자열의 시작을 나타냄
• (([a-zA-Z]:)|(\))는 드라이브 문자와 : 또는 단일 백슬래시()와 일치하는지 확인
• (\{1}|((\{1})^\)+)는 나머지 경로를 일치시키며, 백슬래시() 다음에는 , :, *, ?, <, >, ", |가 아닌 문자열의 시퀀스가 와야 하며, 이 패턴은 여러 번 반복 가능하다.

7. 각 폴더별 (예: lastStable ) 로 찾은 폴더 갯수 및 삭제한 폴더 갯수, 그리고 지워지지 않은 폴더 갯수를 로그파일에 남긴다. 갯수 위에는 폴더 경로들이 찍히며, 총 4번이 찍히게 된다.

이렇게 foreach() loop 이 완료되면 ServiceControlCore 의 메소드인 ControlService(1) 을 호출하여 Jenkins 서비스를 재시작한다.

사실 현재 사용하는 프로그램에 대한 설명은 완료 되었지만, Jenkins 서비스를 강제 shutdown 시키는 방법보다는 safe-shutdown 시키는 방법을 권장 된다. 이 방법은 Jenkins 내 shutdown 명령어가 적용 될 때, 실행 시작이 된 프로세스가 있는지 확인 하며, 완료 후 shutdown 실행이 되는데, 이 방법을 사용하려면 프로그램 안에서 cmd 명령어를 실행 시켜 진행한다. 다음 포스팅에서 이부분에 대해 알아보려고 한다.

-끝-

youp-han/Jenkins-Restart: it restarts the running Jenkins Service locally (github.com)

젠킨스 (Zenkins) 구성 중에 3분마다 서비스가 살아있는지 확인하는 구성이 하나 있었는데, 처음에 크론탭 (Chrontab) 설정 할때는 다음과 같이 설정하여 3분마다 지속적으로 확인 할 수 있도록 했습니다.

H/3 * * * *

이후에, 서비스 사용하는 시간 동안에만 확인 하도록 설정을 다음과 같이 바꾸게 되었습니다. 사실 크론탭 설정 관련하여 지식이 없어, chatGPT 의 도움을 받았습니다. Schedule 은 월-금, 오전 8시부터 오후 19시 이전까지 걸어놨습니다. 

*/3 8-18 * * 1-5

• */3 in the first field means "every third minute"
• 8-18 in the second field means "between 8:00 AM and 6:59 PM"
• * * in the third and fourth fields means "every day of the month" and "every month of the year" respectively
• 1-5 in the fifth field means "Monday to Friday"
• -- from ( openai.com )

이틀간의 빌드 히스토리를 열어서 UTC 를 한국 시간으로 수정한 결과 입니다.

src/main/webapp directory will be ignored if packaged as a Jar

it works only with War packaging

Tool 개발 로그 - 1-1 #Jenkins #서비스 #재시작 + @작업하는 #Tool 만들기 c# -배경 #시나리오

* 2020년 9월에 작성 된 Tool의 개발 로그, 2번째 프로그램 작성 ServiceControlCore 설명이다. 

- Windows OS 내 Services (서비스) 툴에 등록 된 서비스 를 멈추고 시작하고, 상태를 확인할 때, 유용하게 사용할 수 있도록 제공 된 닷넷 클래스가 있다. 이름은 ServiceController 이며 이에 대한 상세 설명은 다음 링크에 기록되어 있다. -  https://learn.microsoft.com/ko-kr/dotnet/api/system.serviceprocess.servicecontroller?view=dotnet-plat-ext-7.0

이 클래스를 사용하여 서비스 상태를 가지고 오고, 멈춘 뒤, 필요한 작업을 진행 하고, 마지막에 서비스를 다시 시작한다. 해당 프로그램의 배경 시나리오 포스트( https://yobine.tistory.com/582 ) 에서 작성 된 프로그램의 전체 플로우와 동일하다. 

이번 포스팅에서는 ServiceControlCore 클래스 내 있는 Method 들을 살펴 본다. 상단에 언급했듯 이 ServiceControlCore 클래스 에서는 닷넷에서 제공하는 ServiceController 클래스를 사용하여 Jenkins 서비스의 상태를 확인하고 변경한다.

프로그램에서 제일 처음에 호출 하는 작업이 GetServices() 메소드 이다. 

이 메소드는 Jenkins 서비스 상태를 확인하는 부분인데, 리턴 값은 bool 이며. 선언된 serviceName (Jenkins) 과 Services[] 로 받아온 리스트를 비교 하여, ServiceName 이 리스트에 있는지 우선 확인 하며, 서비스 이름이 Services 에 등록되어 있다면 현재 상태를 확인 하고, running 인 경우 true 를 반환한다. 

- 서비스가 언제나 running 인 상태여야 프로그램이 돌기 때문에, 이부분에 대해 수정이 필요할 것 같다. 

다음은 ControlService() 메소드 다. 이 메소드에서 서비스를 실질적으로 멈추고, 시작한다. 우선 int flag 를 인자로 , 0은 서비스 멈춤 (Stop), 1은 서비스 시작 (Start) 으로 약속된 값을 전달 받는다. 실행 중인 Jenkins 서비스(serviceName )를 멈추고(Stop)  20초 timeout 시간을 걸어주는데, 서비스가 멈추는데 걸리는 시간이 대략 최대 20초 정도여서, 멈출 때까지 대기를 하지만, 대부분 20초 전에 멈추기 때문에 대기 시간으로써는 충분한 시간이다.

ControlService() 메소드 에서 flag 값에 따라 분기가 일어나는데, if/else 가 아닌 switch 문을 사용했다. 1과 0 만이 아닌 그외의 명령어 까지 전달을 생각으로 메소드를 작성했다. 내부적으로 시작 혹은 멈추는 명령어를 전달 후, 서비스 상태를 2초마다 확인하는데, 이 메소드 이름은 CheckServiceStatus(int flag) 이다. 이 메소드 는 ControlService(int flag) 메소드에서 전달 받은 동일한 인자 flag 를 받아 GetService() 메소드를 호출하여 상태를 확인 한다. 

서비스를 Stop (0) 을 시켜야 하는데, GetService 의 리턴 값이 true 면, 다시 동일한 flag 값 (0) 을 가지고 재귀호출을 한다. 만약 GetSerivce 의 리턴값이 false 라면, break 가 걸리고, 서비스가 멈추었다는 로그를 남긴다. 

서비스를 Start(1) 하는 내용도 동일하다. 리턴값들이 반대이지만, 동일하게 작동한다. 

해당 프로그램을 실행하면 위의 CMD 화면과 같이 화면에 로그들이 찍힌다. 처음에 Jenkins 서비스를 찾았고, 실행 중인 것이 확인 되어 재시작 프로세스가 시작되었다고 나오며, 서비스를 멈추게 한다. 서비스가 멈춘 후 삭제해야 할 폴더들을 각각 찾아서 삭제를 진행 하게 되며, 작업이 끝난 후에 다시 Jenkins 서비스를 실행 한다. 

-끝-

youp-han/Jenkins-Restart: it restarts the running Jenkins Service locally (github.com)

 * 2020년 9월에 작성 된 Tool의 개발 로그입니다.

회사에서 사용하고 있는 Jenkins 가 간혹 이상 증상을 일으키는데, 그 중 하나는 Windows OS 를 사용하는 Slave-node 들이 모두 off-line 으로 변경 된다.

- 참고로 Jenkins 를 Master-Slave node 로 구성하는 내용은 다른 블로그에 많이 적혀 있으므로 여기서는 생략하며 아래 링크에 간략한 구성도 포함되어 공유한다. 

- https://velog.io/@doontagi/Jenkins-Master-Slave-%EA%B5%AC%EC%84%B1 

다시 본론으로 돌아오면,

사용 중 인 Jenkins 버전 (2.13) 버그여서, Jenkins 를 상위 버전으로 업그레이드를 하게 되면 없어지는 현상이지만, 해당 Jenkins 에 등록되어 배포 중 인 프로젝트들도 많고 (20+), 설치 된 플러그인들 중, 해당 버전의 Jenkins 에서는 잘 사용 중이지만, 상위 버전에서는 지원이 끊겨, 업데이트를 시도 했다가, 여러 문제가 발생하여 다시 현재 버전의 Jenkins 로 롤백하게 되었고, 버그 발생도 감안하며 사용 중 이다.

이 후 2.13 버전의 Jenkins 서비스엔 새로운 개발 프로젝트 등록은 하지 않기로 결정이 났고, 사용 중인 프로젝트들만 요청 시 따로 분리하는 작업을 진행 했지만 원치 않는 부서들이 더 많아서, 오류 발생 연락이 왔을 때, 바로 조치를 취해 줘야 한다.

Windows OS 를 사용하는 Slave-Node 들이 모두 off-line 으로 변경되는 오류 발생 시 취해야 하는 방법은, 인터넷 검색을 통해 다음과 같이 정리 되었다. 

1. safeRestart : https://jenkins.url.com/safeRestart 를 실행 해 준다. CentOS 등을 사용하는 Slave-agent 들이 돌고 있을 수도 있어서 해당 agent 들의 job 이 완료되면 Jenkins 서비스 재실행이 될 수 있도록 한다. (Windows OS 의 Slave-node 로 배포 하는 프로젝트 들은 강제로 끊어줘야 한다. - 배포 job 실행 후 slave node 가 off-line 이여서 slave node 가 on-line 이 되기 를 기다리며서 job 진행 중이 되므로, safeRestart가 불가능하다. 
2. Jenkins 서비스가 멈춘 뒤, 재시작이 진행 되었을 때, 거의 100 이면 100, 모두 오류가 나면서 서비스 재시작 실패를 하는데, 주로 다음과 같은 오류가 난다. 빨간색으로 표기한 lastStable 이라는 폴더 외에도 lastStable 이라를 폴더들 관련 ioException 오류들이 표시됩니다.

3. 이 상태에서는 Jenkins 서비스가 재시작을 계속 실패한다. 이때, %Jenkins HOME%/jobs 폴더 내 프로젝트 구성 폴더들 안에 있는 lastStable, lastSuccessful 폴더들을 모두 검색하여 삭제해야 한다. 이후 Jenkins 서비스를 재시작을 하면 성공적으로 서비스가 재시작 및 실행 중인 걸 확인 할 수 있다.

한동안은 위의 1,2,3 번 스텝을 slave-node 가 off-line 되는 현상이 있을 때마다 수작업으로 진행 하였는데, 서버 접속 해서 cmd 열고, 서비스 stop 명령어 전달 하고 서비스가 멈추고 나면, 3번 스텝에 언급된 폴더들을 검색하여 삭제 하고, jenkins 서비스의 재시작 누른 후.. 실행을 확인 하게 되는데, 걸리는 시간이 서버 및 네트워크 상태에 따라 족히 15분-30분까지도 걸리는 작업이다. 

정규 배포 날에 해당 문제가 발생하면 이전 버전을 그냥 사용하면서 배포 가능한 시간을 기다릴 수 있지만, 오류패치 배포 등 긴급한 상황인 경우엔 15분도 너무 긴 시간이다. 그래서 클릭 한번으로 서비스 내리고, 폴더들 삭제 하고, 다시 서비스를 올리는 프로그램이 필요했고, 그래서 다음과 같이 만들게 되었다.

결론적으로는 프로그램 실행 후 모든 작업이 완료되기까지 소요되는 시간은 평균적으로 2분에서 3분정도 이며 (대부분 미만의 시간이 걸림), 이후 서비스 재시작하기까지 2-3분정도 걸린다. 빠르게 오류 발생 시 대처할 수 있게 되었다.

자 이제부터는 프로그램 코드를 공유 한다. 프로그램 언어는 c# 이며, 사용된 닷넷 버전은 4.0 이다.

서버에서 정기적으로 해당 어플리케이션(.exe) 을 실행 하여 젠킨스 서비스를 재시작하여 불시의 오류를 대비하기 위해 만드는 프로그램이여서, 콘솔앱이며 진행사항을 콘솔 및 로그 파일에 기록한다. - 하지만 불필요하게 서비스를 재시작하기 때문에, 오류 발생 시에만 사용하기로 정하였음.

이제 만들 프로그램은, 기본적으로 app.config 에 들어 있는 위의 정보들을 사용하여, 순차적으로 실행된다. Class 가 2개가 있는데 하나는 ServiceControlCore 라고 이름은 거창하지만, Jenkins 라는 서비스이름 과 타임아웃 시간을 받아 생성되는 객체다. FolderControlCore 역시 이름만 거창할 뿐, 상위 폴더 이름과 삭제할 타겟 폴더 이름을 받아, 폴더 검색, 폴더 확인 및 폴더 삭제를 진행 한다. 

A.     설치된 서버 에서 Windows Services 에 등록되어 있는 특정 서비스 검색 (serviceName = Jenkins ) 후 서비스가 실행 중인지 확인한다. bool 값을 리턴받아 다음 단계를 진행한다. 

B.     실행 중인 Jenkins 서비스(serviceName )를 멈춘다. 멈추고(Stop)  20초 timeout 시간을 걸어주는데, 서비스가 멈추는데 걸리는 시간이 대략 최대 20초 정도이다.

C. 프로그램 상단에 생성 시 객체에 지정 해 준 상위 폴더 (upperDirectoryName = %Jenkins HOME% ) 이름 아래에 있는 삭제할 타겟 폴더 (deleteFolderNameList ) 들을 하나 씩 전달하여 타겟 폴더 갯수 만큼 순차적으로 검색 후 삭제를 진행 한다. 

D. Jenkins 서비스 (serviceName=Jenkins)  를 시작한다.( 시작 후 최대 대기 시간 20초)

E.     Log 추가 (NLog 패키지 활용)

NLog 패키지 설정 및 활용에 대해서는 따로 설명은 생략 하므로 잘 작성 된 블로그를 공유한다.

- 참조: https://icodebroker.tistory.com/9402

이로써 프로그램은 잘 만들어졌고, 이번 프로그램에서 작성 한 FolderControlCore 와 ServiceControlCore 에 대해서 다음에 좀더 자세히 살펴 보기로 한다.

-끝-

youp-han/Jenkins-Restart: it restarts the running Jenkins Service locally (github.com)