Nest.js 빌드 후 진입점이 이상한 위치에 생기는 이유는?

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 :...

우분투와 윈도우 듀얼부팅 시, 윈도우 측 시계가 UTC로 표시된다면?

윈도우 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 설정이 제대로 적용되었는지 확인하려면 다음 명령...

로컬에선 잘 되는데... 원격지에서 클론한 레포지토리에서 특정 파일에 대해 module not found가 뜬다면?

로컬에선 잘 되는데... 원격지에서 클론한 레포지토리에서 특정 파일에 대해 module not found가 뜬다면? Case-Sensitive 주의 그렇다면 무조건 대소문자 문제가 아닌지 확인하도록 하자. 하필이면 딱 한 글자, i와 I의 차이로 인해 3시간이 넘도록 개 뻘짓을 해버렸다. 부디 이 글을 읽고 향후에 이런 개떡같은 운명에 마주치지 않길 바란다. git config core.ignorecase 일단, 첫 번째로 할 건 case-insensitive OS, 특히 윈도우를 사용 중일 때 레포지토리 루트에서 다음 명령어를 실행하는 것이다. git config core . ignorecase false 그렇지 않으면 나처럼 일을 두 번 하게 될 것이다. 위 git config를 적용하면, git이 이후 해당 레포지토리 내의 파일의 대소문자 변경을 감지하게 된다. 즉, headerIcon.png 파일이 headericon.png 로 변경됐을 때 headerIcon.png 파일은 없어진 것으로 판단하고, headericon.png 파일은 새로 생긴 것으로 판단하게 된다. 이 설정을 선행하지 않고 아래 지침을 따르게 되면 파워쉘 스크립트나 배치 파일로(혹은 일일히 UI로) 파일명을 바꿨다가 다시 원본 파일명으로 돌려야 하게 될 것이다. Case-Sensitive한 파일명 변경 이제 코드에서 사용하는 경로와 일치하도록 파일명을 변경한다. 예를 들어, 코드에서 import HeaderIconImage from "@images/icons/headericon.png" 를 사용한다면 headerIcon.png 를 headericon.png 로 변경하면 된다. 나 같은 경우에는 다른 개발자의 프로젝트 파일을 그대로 복사해왔는데… 설마 같은 폴더 내의 수십개의 headericon-*.png 파일이 각각 i 와 I 가 번갈아가며 썼을 줄은 몰랐다. 후… 가능하면 이름 컨벤션은 일치시키도록 하자...

MSTSC를 통한 저장된 자격 증명으로 원격 연결 시 Defender Credential Guard가 허용하지 않는 문제

이미지
MSTSC를 통한 저장된 자격 증명으로 원격 연결 시 Defender Credential Guard가 허용하지 않는 문제 원격 연결, MSTSC 업무를 하다 보면 자주 다른 컴퓨터에 원격으로 연결해야 할 일이 생깁니다. 리눅스 계열은 SSH로, 윈도우 계열은 SSH를 쓸 때도 있지만 대부분 RDP를 통해 GUI로 원격 연결해 사용하게 됩니다. 그러나 최근 일 년간은 윈도우 서버에 연결할 일이 거의 없다시피 하여 MSTSC.EXE라는 실행 파일 이름조차 잊고 지내다가 다시 윈도우 서버로 연결할 일이 생겨서 연결하려 했는데 다음과 같은 문제가 생겼습니다. Windows Defender Credential Guard, 넌 못 지나간다 자격 증명이 허용되지 않아 두 번째 연결부터 위처럼 Windows Defender Credential Guard가 길을 가로막아버리는 것이 바로 그 문제였습니다. 뭐 그룹 정책 관리자에서 어쩌구… RDP 파일을 저장해서 저쩌구… 이런 건 전부 작동하지 않았습니다. 심지어 비밀번호도 드럽게 길어서 매번 연결할 때마다 패스워드를 복붙하는 과정도 엄청나게 귀찮았습니다. 해결 방법 해결 방법은 생각보다 간단했습니다. 구글에 검색하니 바로 이런 스택 익스체인지 글 이 나와서 따라하니 바로 되더라고요. 해결 방법만 적자면 다음과 같습니다. cmdkey /list:TERMSRV/* 명령을 통해 대상 원격 연결을 확인. (한 번도 연결한 적 없는 서버라면 생략 가능) cmdkey /delete:[확인된 대상] 명령을 통해 기존 대상 삭제. (한 번도 연결한 적 없는 서버라면 생략 가능) 예: cmdkey /delete:TERMSRV/1.2.3.4 cmdkey /generic:TERMSRV/[IP] /user:[로그온 유저] /pass:[로그온 패스워드] 명령을 통해 새로운 자격 증명 등록 예: cmdkey /generic:TERMSRV/1.2.3...

ASP.NET에서 인증 필터를 만들어 쓰는데 DbContext 에러가 났다.

ASP.NET에서 인증 필터를 만들어 쓰는데 DbContext 에러가 났다. 어처구니 없는 실패 ASP.NET에서 권한 레벨 기능을 도입하는 중에 IAuthorizationFilter를 구현한 커스텀 필터를 제작해 사용하려 했는데, 다음과 같은 에러가 지속적으로 발생했다. System . InvalidOperationException : A second operation was started on this context instance before a previous operation completed . This is usually caused by different threads concurrently using the same instance of DbContext . For more information on how to avoid threading issues with DbContext , see https : / / go . microsoft . com / fwlink / ? linkid = 2097913 . at Microsoft . EntityFrameworkCore . Infrastructure . Internal . ConcurrencyDetector . EnterCriticalSection ( ) at Microsoft . EntityFrameworkCore . Query . Internal . SingleQueryingEnumerable` 1 . AsyncEnumerator . MoveNextAsync ( ) at Microsoft . EntityFrameworkCore . EntityFrameworkQueryableExtensions . ToListAsync [ TSource ] ( IQueryable` 1 source , CancellationToken cancellationToken ) at Microsoft . EntityFrameworkCore . EntityFram...

WPF에서 폰트 설치 없이 외부 폰트를 사용하는 방법

WPF에서 폰트 설치 없이 외부 폰트를 사용하는 방법 외부 폰트 사용: WPF 앱에서 폰트 설치 없이 사용하기 WPF(Windows Presentation Foundation) 앱 개발 중 외부 폰트를 사용해야 하는 상황이 발생할 수 있습니다. 흔한 경우는 아니지만, 특정 디자인 요구사항이나 클라이언트 요청에 따라 외부 폰트를 적용해야 할 때가 있습니다. 외부 폰트는 시스템에 기본적으로 설치되어 있지 않은 폰트를 의미하며, 앱 실행 시 폰트 설치 없이 사용할 수 있도록 하는 것이 중요합니다. 외부 폰트가 필요한 경우 대부분의 WPF 앱은 설치 파일 형태로 배포되기 때문에, 설치 과정에서 폰트를 함께 설치할 수 있습니다. 하지만, 포터블 방식으로 배포되는 앱의 경우, 관리자 권한이 없을 경우 폰트 설치가 불가능하므로 외부 폰트를 사용해야 합니다. 외부 폰트 사용 방법: 폰트 리소스 활용 외부 폰트를 사용하는 가장 효율적인 방법은 폰트 파일을 어셈블리 리소스에 포함시키는 것입니다. 이렇게 하면 폰트 설치 없이 앱 실행 시 폰트를 로드하여 사용할 수 있습니다. 1. 폰트 파일을 프로젝트에 포함: 원하는 폰트 파일(.ttf)을 WPF 프로젝트에 추가하고, 빌드 작업을 "리소스"로 설정합니다. XML <ItemGroup> <Resource Include="Fonts\내폰트.ttf" /> </ItemGroup> 2. FontFamily 속성에 폰트 로드: 컨트롤(예: TextBlock)의 FontFamily 속성에 리소스에 포함된 폰트를 로드하여 사용합니다. 이때, 주의할 점은 폰트 파일명이 아닌 실제 폰트 이름 을 사용해야 한다는 것입니다. XML <TextBlock FontFamily="Fonts/#Pretendard Variable" /> 주의 사항: 폰트 이름 확인: 폰트 파일을 탐색기...

Next.js와 MUI의 병용이 더 쉬워졌다!

Next.js와 MUI의 병용이 더 쉬워졌다! Next.js 및 MUI를 함께 사용하자 (feat. Tailwind CSS) 바로 저번 주까지만 해도 Next.js와 MUI를 함께 사용하려면 캐시 처리 및 인젝션 오더 설정용 프로바이더를 직접 공식 문서에 따라 만들고 커스텀해 삽입하는 노가다가 필요했다. 하지만 이제 그럴 필요가 없어진 것 같다. 포트폴리오용 사이트를 제작하기 위해 MUI 문서 를 들어가보니 새로운 방법이 제시되어 있었기 때문이다. 변경된 사용 방법 우선 각 단계를 진행하기 전에 기본적인 MUI 구성 은 완료되어 있어야 한다. 또한 문서에서는 Next.js 13 이상에서 진행하기를 권장하고 있다. 나는 pnpm 패키지 매니저를 사용하므로 다른 패키지 매니저를 사용한다면 적절히 변환해서 사용하면 된다. App Router에서 사용하기 1. 필요한 패키지 설치 : pnpm add @mui/material-nextjs @emotion/cache 명령어로 필요한 의존성을 추가한다. 2. 설정 : app/layout.tsx 에서 AppRouterCacheProvider 를 사용해 <body> 안의 요소를 감싼다. // app/layout.tsx + import { AppRouterCacheProvider } from '@mui/material-nextjs/v13-appRouter'; // or `v14-appRouter` if you are using Next.js v14 export default function RootLayout(props) { const { children } = props; return ( <html lang="en"> <body> + <AppRouterCacheProvider>{children}</AppRouterCacheProvider> ...