Honsal's Dailylife

Nest.js 빌드 후 진입점이 이상한 위치에 생기는 이유는? 레거시 Nest.js 백엔드를 재작성하는 솔루션을 진행하던 중, 특이한 일이 발생했다. 재사용성과 유지보수성을 위해 공용 라이브러리 및 DB 스키마 등을 별도의 GitHub Private Packages로 분리해두고 있었는데, 그러던 중 갑자기 Nest.js 백엔드 빌드가 안 되는 문제가 발생한 것이다. 처음에는 Error: Cannot find module '[CENSORED]/dist/admin' 같은 에러가 떴다. 문제는 소비측 프로젝트와 라이브러리 패키지 프로젝트 둘 다에서 package.json, tsconfig.json, nest-cli.json 등 빌드에 관련된 파일을 하나도 건드리지 않았다는 것이다. 첫 번째 시도: nest start 진입점 변경 시간에 쫓기는 상황이라, 급하게 dist/ 디렉터리 구조를 파악한 뒤 소스 루트를 통째로 옮겨보려고 했다. 그런데 여기서 또 특이한 점이 있었는데, 디렉터리 구조가 평탄화된 상태가 아니라 재귀적인 구조로 바뀌어 있었다. 예를 들어, 이전에는 빌드하면 다음과 같은 디렉터리 구조가 나타났다. proj - dist - main.ts - .. . 그런데 지금은 아래와 같이 변경되어 있었다. proj - dist - lib - [ 라이브러리 프로젝트명 ] - src - .. . - [ 프로젝트명 ] - src - main.ts - .. . 뭔가 괴상하다는 느낌은 있었지만, 시간이 없어서 npm 스크립트에서 nest start 부분의 진입점을 변경해 시작해보려 했다. 당연히 문제가 발생했다. 문제 발생: This is likely not portable... 문제는 바로 아래와 같은 에러였다. src / decorators / public . decorator . ts :...

윈도우 11과 우분투 24.04 듀얼부팅 시 윈도우에서 발생하는 시간 오류 문제 최근 우분투 24.04 LTS 버전을 설치해 윈도우 11과 듀얼부팅으로 사용하고 있다. 일차적인 이유는 업무상 필요성이고, 추가로 NTFS 및 ReFS 파일 시스템의 느린 성능과 윈도우 11의 전반적인 느린 동작 등 여러 불만 사항을 해소하기 위함이다. 물론 우분투만 사용할 수 없으므로, HDR 콘텐츠 감상이나 게임 등 휴식을 위해 윈도우도 사용한다. 그런데 듀얼부팅 환경에서 한 가지 이상한 증상이 나타났다. 윈도우에서 단독 부팅하거나, 윈도우 → 우분투, 우분투 → 우분투로 부팅할 때는 시스템 시간이 정상적으로 표시되지만, 우분투로 부팅한 후 윈도우로 재부팅하면 하드웨어 시계가 UTC 기준으로 설정되어 있어 윈도우에서 시간이 잘못 표시된다. 우분투 사용 후 윈도우에서 시간이 잘못 표시되는 이유 이 문제의 원인은 우분투를 비롯한 대부분의 리눅스 배포판이 기본적으로 하드웨어 시계를 UTC 기준 으로 관리하는 반면, 윈도우는 하드웨어 시계를 **로컬 시간(지역 시간)**으로 관리하기 때문이다. 우분투 측 우분투는 부팅 시 인터넷 시간과 동기화하면서 하드웨어 시계를 UTC 기준으로 저장한다. 그리고 시스템에서는 KST(서울, UTC+9)를 적용해 사용자에게 올바른 지역 시각으로 표시한다. 윈도우 측 윈도우는 하드웨어 시계를 로컬 시간으로 인식하여 그대로 표시한다. 따라서 우분투에서 저장한 UTC 값이 그대로 적용되므로, 실제 시간보다 9시간 늦은 시각이 표시되는 것이다. 해결 방안 문제 해결은 간단하다. 우분투에서 하드웨어 시계를 로컬 시간으로 관리하도록 설정하면 된다. 터미널에서 아래 명령어를 실행하여 우분투가 하드웨어 시계를 로컬 시간으로 해석하도록 변경한다. timedatectl set-local-rtc 1 --adjust-system-clock 설정이 제대로 적용되었는지 확인하려면 다음 명령...