Onejay Lab | Blog

nodenv 환경에서 Node 버전 상관없이 Claude Code 실행하기

Wed, 18 Mar 2026 00:00:00 GMT

“nodenv + npm 으로 설치한 claude code 를 node 버전 상관없이 어느 프로젝트에서나 실행할 수 있는 방법을 설명한다.”

내용

Claude Code 를 설치하는 방법은 여러가지가 있다. curl 로 shell script 를 실행하거나 맥이라면 homebrew 를 사용하거나 node.js 를 사용하는 유저라면 npm 을 이용하는 방법도 있다.

(이 글을 쓰는 시점에 공식사이트를 들어가보면 더 이상 npm 을 이용한 설치는 지원하지 않는 듯하다. Deprecated npm installation)

나는 node.js 가 익숙한 개발자라 npm 을 이용해 설치했었다.

https://www.npmjs.com/package/@anthropic-ai/claude-code

특히 각 프로젝트마다 node.js 의 버전이 달라서 nodenv 를 이용해 프로젝트별로 node 의 버전을 다르게 사용하고 있었다. 그래서 claude code 를 nodenv 의 global 로 설정한 node 버전에 설치를 했다.

이 경우 .node-version 파일이 없는 디렉토리나 프로젝트에서는 global 버전의 node 에서 잘 실행할 수 있는데 global 버전이 아닌 프로젝트(각 .node-version 파일에 지정한 버전)에서는 아래와 같은 에러로 실행이 되지 않았다.

$ claude
nodenv: version `22.21.1' is not installed

global 버전이 24.12.0 인데 프로젝트의 버전이 22.21.1 라서 실행이 되지 않는 것이다.

이런 경우 3가지 정도의 방법이 있다.

IDE 의 플러그인을 사용
.node-version 을 임시로 global 버전과 같은 버전으로 변경
NODENV_VERSION=글로벌버전 claude 으로 실행

1. IDE 의 플러그인을 사용

Visual Studio Code(vscode) 나 WebStorm 등의 IDE 는 Claude Code 플러그인을 지원한다. 이 플러그인들은 node 버전과 관계없이 Claude Code 를 사용할 수 있다.

2. .node-version 을 global 버전과 같은 버전으로 변경

Claude Code 를 실행하고자 하는 프로젝트의 .node-version 의 버전을 nodenv 의 global 버전으로 변경해 준다.(임시로)

nodenv 는 .node-version 파일이 있는 경우, 그 버전을 참조하여 node 를 실행한다. 따라서 임시로 node 버전을 변경해주면 Claude Code 를 실행할 수 있다.

3. `NODENV_VERSION=글로벌버전 claude` 으로 실행

nodenv 의 환경변수인 NODENV_VERSION에 버전을 지정하여 claude 를 실행하면 바로 사용할 수 있다.

NODENV_VERSION=24.12.0 claude

NODENV_VERSION 환경변수는 특정 node 의 버전을 지정할 수 있는 변수이다. 이 환경변수에 global 버전을 지정하고 claude 를 실행하면 어디에서 실행해도 동일한 node 버전으로 사용가능하다.

귀찮다면 alias 를 이용해 간략하게 설정도 가능하다.

결론

nodenv + npm 으로 설치한 claude code 는 여러 버전의 node 가 설치된 pc 에서는 사용하기 까다롭다(귀찮다).

이러한 이유로 Claude Code 측에서도 더 이상 npm 을 이용한 설치는 지원하지 않기로 한 듯하다. Claude Code 를 설치한 PC 에서 언제든지 동일하게 실행할 수 있어야 하는데 node 버전에 따라 실행할 수 없는 케이스도 생기고, 특히나 요즘은 코딩 뿐만 아니라 일반적인 PC 사용에서도 claude code 를 활용하는 경우가 많은데 node 를 따로 설치해야 하는 것은 번거롭기만 하다.

위의 3가지 방식으로 사용하다가 조만간 다른 방식으로 다시 설치해야할 듯하다.

Claude Code 에서 제공하는 마이그레이션 방식은 다음과 같다.

# Install the native binary
curl -fsSL https://claude.ai/install.sh | bash

# Remove the old npm installation
npm uninstall -g @anthropic-ai/claude-code

Refs

Route53 - DNS 레코드 추가 및 확인

Wed, 18 Feb 2026 00:00:00 GMT

“AWS Route53 에서 DNS 레코드를 추가하고 확인하는 방법을 설명한다.”

author: Onejay
createdAt: 2026/02/18
updatedAt: 2026/02/18

Intro

가끔 DNS 레코드를 추가하거나 갱신하는 작업을 맡을 때가 있다. 작업 자체는 간단하지만 할 때마다 각 DNS 레코드의 역할이 자주 헷갈리고는 한다. 어떤 레코드에 어떤 값을 지정해야 하는지가 상당히 헷갈려서 매번 다시 확인하고 작업을 시작햇었다.

이번 기회에 각 레코드의 값을 정리해보고 작업 후에 확인하는 방법까지 정리해보려고 한다.

Body

Root Domain

Apex 도메인 또는 Naked Domain 이라고 한다.
example.com 과 같이 앞에 www 나 api 등이 붙지 않은 도메인을 의미한다.
CNAME 레코드의 값으로 지정할 수 없다.

A 레코드

(서버 인스턴스 등의)IP 값을 저장하는 레코드
도메인 네임(URL) -> IP 로 바꿔주는 레코드이다.
- www.example.com, api.example.com 등의 도메인에 해당하는 IP 값을 지정해두어 서버 인스턴스로 접속할 수 있도록 한다.
AWS Route53 의 경우에는 A 레코드에 IP 이외에 CloudFront URL (XXXXXX.cloudfont.com) 을 지정할 수 있다,
- alias 항목을 ON(Yes) 로 했을 경우에만 사용 가능하다.
- 구조 상 Cloudfront 를 통해 EC2 인스턴스에 액세스한다면 EC2 인스턴스의 IP 가 아닌 Cloudfront URL 을 연결하여

CNAME

서브도메인
루트 도메인으로 연결하는 일종의 alias(별칭)라고 할 수 있다.
example.com 이 루트 도메인이라면 www.example.com, api.example.com 등은 CNAME 으로 지정한 서브 도메인이다.
CNAME 레코드에는 루트 도메인을 지정할 수 없다.
- 루트 도메인으로 연결하기 위한 alias 를 지정하는 것인데 루트 도메인을 지정해버리면 의미가 없다.
- 별명으로 본명을 지어주는 격이다.

NS

네임서버정보
도메인을 관리하는 네임서버가 어느 서버인지를 지정하는 값이다.

DNS Record 확인 방법

dig 명령어

dig(Domain Information Groper): DNS 서버에 질의하여 도메인 정보를 조회할 수 있는 명령줄 도구
- 맥이라면 기본적으로 설치되어 있으나 리눅스나 윈도의 경우 별도로 설치해야할 수도 있다.
- 도메인의 IP 주소, 메일 서버, 네임서버 등 다양한 DNS 정보를 확인할 수 있다.

사용방법

dig @<네임서버> <도메인네임> <옵션>
네임서버와 옵션은 필수 항목이 아니다.

사용 예

example.com 으로 실행해보면 ;; QUESTION SECTION: 에 질의 내용이, ;; ANSWER SECTION: 에 질의 답변이 나온다.
- 질의 내용은 A 레코드를 확인한 것이고 그에 대한 값이 나왔다.

$ dig example.com

...

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;example.com.      IN  A

;; ANSWER SECTION:
example.com.    172  IN  A  104.18.26.120
example.com.    172  IN  A  104.18.27.120

...

CNAME 을 확인

$ dig example.com CNAME

...

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;example.com.      IN  CNAME

;; AUTHORITY SECTION:
example.com.    1220  IN  SOA  elliott.ns.cloudflare.com. dns.cloudflare.com. 2399341694 10000 2400 604800 1800

...

구글 툴 박스

toolbox.googleapps.com/apps/dig/

Conclusion(Outro)

Refs
- Route 53에 등록된 DNS 서버 정보를 dig 명령어로 확인하는 방법에 대해 알아보자!
- dig 명령어로 DNS 조회 및 진단하기

Log Insights로 로그 손쉽게 검색하기

Wed, 14 Aug 2024 00:00:00 GMT

“AWS CloudWatch 의 Log Insights 를 이용해 CloudWatch 의 Log 를 검색한다.”

author: Onejay
createdAt: 2024/05/21
updatedAt: 2024/08/14

Log Insights 로 CloudWatch Log 검색하기

Intro

어플리케이션의 장애가 발생하거나 에러가 발생했을 때 또는 사용자User로부터의 문의를 받았을 때, 가장 먼저해야 할 일은? 당연히 로그Log를 찾아보는 일이다.

현재 운영 중인 서비스는 기본적으로 AWS 서비스(API Gateway + AWS Lambda + DynamoDB)를 이용한 Serverless 아키텍쳐 기반이다. 로그는 CloudWatch + S3를 이용해 저장하고 있다.

CloudWatch 는 실행한 AWS Lambda 의 인스턴스를 기준으로 로그를 기록하기 때문에 원하는 로그를 정확하게 검색하기가 어렵다. 때문에 Log Insights 라는 서비스를 이용하면, Query 를 이용해 간단하게 CloudWatch 로그를 검색할 수 있다.

이번 포스트에서는 CloudWatch 의 로그를 쉽게 검색하기 위한 Log Insights 의 사용 방법 을 정리한다.

CloudWatch 의 로그 구조

CloudWatch 는 로그를 로그 그룹(Log Group)과 로그 스트림(Log Stream)이라는 단위로 작성하고 저장한다. 로그 그룹은 로그 스트림의 모음이며 로그스트림에 실제 로그가 기록 된다.

로그 그룹 및 로그 스트림 작업

Serverless Framework 를 예를 들어 아래의 yaml 을 보면, exmple-service 에 해당하는 로그 그룹이 생성되고, exampleLambdaIndex, exampleLambdaStatistics 라는 Lambda 들(혹은 API Gateway 나 다른 리소스)이 실행될 때마다 각각의 로그 스트림을 만들어 로그를 저장한다.

  service: example-service  # Log Group Name: example-service-dev, example-service-prod, ...

  provider:
    name: aws
    region: ap-northeast-2

  functions:
    exampleLambdaIndex: # Log Stream
      handler: path
      ...
    exampleLambdaStatistics:  # Log Stream
      handler: path

Log Insight 를 사용해야하는 이유

문제는 이 로그 스트림을 이용해 원하는 로그를 확인하기 어렵다는 것이다.

AWS Lambda 의 경우, 로그 스트림은 lambda 가 실행된 인스턴스를 기준으로 생성된다. 1개의 lambda 인스턴스당 1개의 로그 스트림이 생성된다.

lambda 가 실행되면서 1개의 로그 스트림을 만들고 로그를 작성한다.
1)의 처리가 끝나기 전에 또다시 리퀘스트가 있다면 다른 lambda 가 실행되고 별도의 로그 스트림을 만들어 로그를 작성한다.
1)의 처리가 끝난 뒤, lambda 인스턴스가 사라지기 전에 또 다른 리퀘스트가 있다면 1)의 lambda 인스턴스를 재실행하여 그 처리를 시작한다.(warm start)
3)의 경우, 1)의 lambda 인스터스를 그대로 사용하기에 새로운 로그 스트림을 만들지 않고 1)의 로그 스트림에 이어서 로그를 작성한다.
완전히 1)의 lambda 인스턴스가 종료된다면, 더이상 1)의 로그 스트림에는 로그가 작성되지 않는다.

이러한 흐름이기에 같은 시간 동안 실행(병렬처리)된 AWS Lambda 가 1000개라면 1000개의 로그 스트림이 있다고 볼 수 있다. 각각의 로그 스트림은 시간 순서대로 로그를 작성하지만 병렬처리로 동시에 작성된 로그 스트림이 많다면 이를 하나하나 찾아보는건 불가능에 가깝다.

이렇게 AWS Lambda 의 병렬처리로 생성된 수많은 로그들을 쿼리Query로 간편하게 검색할 수 있는 서비스가 Log Insight 이다.

Log Insights Query

Log Insights 는 AWS CloudWatch 콘솔에서 사용할 수 있다. 찾고자 하는 로그의 로그 그룹과 시간을 지정한 뒤, 아래와 같은 쿼리를 이용하면 로그를 손쉽게 검색할 수 있다.

좀더 자세한 내용은 AWS Cloudwatch - Log Insights 검색 쿼리에서 확인할 수 있다.

  filter @message like /${SEARCH_KEYWORD}/
    | sort @timestamp desc

주의점

Log Insights 는 AWS가 제공하는 서비스이다. 따라서 검색 용량에 따른 비용이 발생한다.

Understanding AWS CloudWatch Pricing: A Comprehensive Guide

또한 검색할 수 있는 데이터의 양도 최대 10,000개의 제한이 있다.

“Breaking the Barrier: Resolving the 10K Log Insights Limit in CloudWatch and Consolidating Records into a CSV”

Code Storage Limit 초과 해결 — Serverless Prune Plugin

Wed, 26 Jun 2024 00:00:00 GMT

[Jobː談] AWS Lambda Storage Limit Error 해결: Prune Plugin

author: Onejay
createdAt: 2024-06-26
updatedAt: 2024-08-14

“Serverless Framework 의 Prune Plugin 으로 AWS Lambda 의 Code Storage Limit 을 해결한다.”

Intro

AWS 를 이용한 Serverless 아키텍쳐로 서비스를 운영한다면 AWS Lambda 를 반드시 쓰게 된다. AWS Lambda 는 가장 간편하고 저렴하며 활용도가 높은 서비스 중 하나이기에 다양한 처리에 사용할 수 있다.

지금 운영 중인 서비스에서는 크게 아래와 같이 3가지 용도로 AWS Lambda 를 사용하고 있다.

15분 이내의 간단한 배치Batch 처리

“API Gateway + AWS Lambda” 조합으로 Web Server 로 활용

Step Function 이나 다른 AWS 리소스의 이벤트 전후처리(Cloudfront Edge Function, S3 이미지 업로드 시 썸네일 생성 등) 같은 트랜잭션의 한 부분으로 활용

이렇듯 활용도가 높은 AWS Lambda 이기에 넋 놓고 쓰다보면 금방 코드 스토리지가 부족해질 수 있다.

AWS Lambda 의 코드 스토리지는 75GB이다.
- Refs: Lambda quotas

실제로 최근에 Serverless Framework(이하 sls) 로 deploy 하던 중 Code storage limit exceeded 에러가 났다. 이번 기회에 AWS Lambda 의 코드 스토리지를 효율적으로 관리할 수 있도록 sls 설정을 하고 그 방법에 대해 정리해 본다.

AWS Lambda Code Storage?

AWS Lambda 는 소스코드를 컨테이너Container를 통해 바로 실행하는 구조이기에 소스코드 (직접 코딩한 소스코드 및 의존성 코드) 를 업로드해둘 스토리지 가 필요하다. 이 저장 공간을 코드 스토리지code storage 라 한다.

AWS Lambda 서비스에서 제공하는 코드 스토리지는 75GB 이고 이 스토리지 용량을 모두 사용하면 소스코드를 업로드할 때 아래와 같은 에러가 발생한다. (※ Monitoring Lambda code storage)

  Code storage limit exceeded. (Service: Lambda, Status Code: 400, ...)

해결 방법

sls 로 AWS Lambda 를 Deploy 하던 중 발생한 Code storage limit exceeded 에러를 어떻게 해결해야할까? 우리 팀에서 해결한 방법을 차례로 설명해 본다.

1) 코드 스토리지 용량 확보

코드 스토리지의 용량이 부족하기 때문에 가장 먼저 한 일은 스토리지 용량 확보 이다. 필요없는 람다 함수Lambda Function 를 찾아 삭제하거나 각 람다 함수의 버전Version을 확인해 오래된 버전이 많이 존재한다면 그 버전들을 삭제하는 작업을 진행했다.

필요없는(사용하지 않는) 람다 함수 삭제
람다 함수의 오래된 버전 삭제

조사 결과 필요없는 람다 함수는 없었기에 “람다 함수의 오래된 버전 삭제” 만 진행했다. 이 작업은 팀의 시니어 엔지니어분께서 AWS CLI 를 이용해 수동으로 하나하나 삭제해가며 진행했다.

  $ aws lambda delete-function \
      --function-name ${LAMBDA_FUNCTION_NAME} \
      --qualifier ${LAMBDA_FUNCTION_VERSION}

AWS CLI - delete-function

그리고 이 작업은 한 번이라도 sls 로 deploy 가 가능해질만큼의 용량을 확보할 때까지 계속되었다.

※ Lambda Function Version

AWS Lambda 의 콘솔에서 아무 함수Function를 선택해보면 버전Version 이라는 탭이 있다. 이 “버전”이 이번 코드 스토리지를 가득 차게 한 원인 이었다.

sls 로 새로운 소스코드를 deploy 할 때, AWS Lambda는 버전이라는 형태로 파일을 생성해 코드 스토리지에 저장 한다. 특별한 설정이 없다면, sls 로 deploy 할 때마다 매번 새로운 버전의 파일을 생성하고 저장 한다. (과거의 버전을 그대로 deploy 해서 Rollback 할 수 있는 기능)

5MB 크기의 소스코드를 30번 deploy 했다면 5MB * 30회, 총 150MB를 저장하게 된다.

지금껏 한 번도 이 버전 파일들을 따로 관리한 적이 없었다. 서비스 초반에 만든 어떤 람다함수는 버전 파일만 300개가 넘었다. 이러한 버전 파일들이 쌓이고 쌓여 75GB 의 코드 스토리지를 가득차게 했다.

2) Serverless Framework 설정

sls 로 AWS Lambda 를 deploy 할 수 있을만큼의 최소한의 코드 스토리지의 용량을 확보했다면, sls 의 플러그인Plugin을 이용해 필요없는 버전 파일을 모두 삭제할 수 있도록 했다.

Serverless Prune Plugin

이 플러그인은 sls 로 deploy 하고 난 뒤, 설정한 갯수의 버전 파일만 남겨두고 모든 버전 파일들을 삭제 한다. sls 로 deploy 할 때마다 오래된 버전 파일을 삭제하기 때문에 앞으로는 오래된 버전 파일들이 쌓여 코드 스토리지를 차지하지 않도록 할 수 있다. 지속적으로 관리할 수 있기에 가장 좋은 방법이라 생각한다.

이 플러그인의 설정 방법은 Prune Plugin: AWS Lambda Storage Limit Error 에서 확인 할 수 있다.

3) Deploy

시험 삼아 1개의 Serverless Framework 설정 파일(YAML)에 Serverless Prune Plugin을 설정하고 sls 로 deploy 했다. 예상대로 오래된 버전의 파일들이 모두 삭제되었다. 나머지 Serverless Framework 설정 파일(YAML)에도 플러그인을 설정하고 모두 deploy 를 해서 오래된 버전 파일들을 삭제했다. 개발환경(Dev)의 람다함수들의 deploy 횟수가 많았었기에 개발환경만 deploy 해도 상당한 양의 코드 스토리지를 확보할 수 있었다.

75GB -> 22GB

75GB를 가득채웠던 코드 스토리지 사용 용량이 22GB로 여유로워졌다.

Conclusion

AWS Lambda 를 Deploy 할 때, 버전을 생성하지 않도록 하는 설정이나 방법에 대한 논의도 있었으나 최종적으로는 지금처럼 플러그인을 이용한 방법을 유지하는 것으로 결론이 났다.

이유는 버전을 생성하지 않는 설정이나 방법이 Serverless Framework 를 이용한 방법이 아니라면 따로 문서를 만들어 내용을 관리해야 하기 때문이고 Serverless Framework 를 이용할 수 있는 방법이라도 현재의 플러그인을 이용한 방법과 중복되기 때문이다. 우리 팀은 인프라에 관한 내용은 YAML 파일 자체가 문서로서의 기능을 하기 때문에 최대한 YAML 파일을 통해서만 관리하고 싶어한다.

다소 당황스러운 상황이었지만, 이번 기회를 통해 AWS Lambda 의 버전과 코드 스토리지에 대한 내용을 공부할 수 있어서 좋은 경험이었다.

Refs

Webpack으로 소스코드 용량 줄여 Upload Size Limit 해결하기

Tue, 28 May 2024 00:00:00 GMT

[Jobː談] AWS Lambda Unzipped size must be smaller than 262144000 bytes Error: Webpack

author: Onejay
createdAt: 2024-05-28
updatedAt: 2024-08-16

“Webpack 을 적용하여 AWS Lambda 에 업로드할 소스코드의 용량을 줄이자”

Intro

  Unzipped size must be smaller than 262144000 bytes

최근에 Serverless Framework(이하 sls)로 AWS Lambda 를 Deploy 하면서 나온 에러 메시지다. AWS Lambda 에 업로드할 소스코드의 용량이 (압축하지 않았을 경우에) 약 250MB 보다 적어야 한다는 것이다.

현재 우리 팀의 서비스는 AWS Lambda 와 ECS Fargate 에 Nest.js 프로젝트를 올려 운영하고 있다. ECS Fargate 는 특별히 소스코드 용량 제한이 없지만 AWS Lambda 는 여러가지 용량 제한이 있다.

Lambda quotas - Function configuration, deployment, and execution
- AWS Lambda 에 직접 올릴수 없는 용량이 큰 파일을 S3에 업로드하게 되는데 50MB(압축했을 경우) 또는 250MB(압축하지 않았을 경우) 이하여야한다.

이번 포스트에서는 Webpack 을 이용해 Nest.js 프로젝트의 소스코드 사이즈를 줄이는 방법에 대해 정리해본다.

소스코드의 용량이 늘어난 이유

서비스가 성장하면서 추가한 기능만큼 소스코드도 늘어났지만, 가장 큰 원인은 업로드할 파일에 필요없는 내용이 많은 것이었다.

우리 팀의 프로젝트 구조를 간략히 설명하자면 1개의 Nest.js 프로젝트 내에서 여러가지 마이크로 서비스들을 각각 deploy 하는 방식으로 MSA를 구현하고 있다. 각 마이크로 서비스마다 각각의 Nest.js Application 과 Module 을 통해 필요한 기능들만 import 해서 사용하고 있지만, 의존성Dependencies(node_modules)은 공통이다.

functions:
  exampleLambdaIndex:
    handler: ${PATH}.handler
    package:
      patterns:
        - '!**'
        - dist/** # js transfer result
        - node_modules/** # all of dependencies
      individually: true

가령 A, B, C 라는 의존성이 있을 때, “회원 서비스”에서는 A, C 만 사용하더라도 회원 서비스를 deploy 할 때에는 node_modules 디렉토리에 있는 모든 의존성(A, B, C)을 업로드하는 것이다. 이렇다보니 서비스 초창기에는 별 문제 없었지만, 서비스가 성장하고 소스코드와 의존성이 늘어나면서 이제 더이상은 업로드할 수 없는 상황까지 오게 되었다.

Lambda Layer를 사용해 공통 의존성들을 따로 관리하고 있음에도 이러한 문제가 발생해 막막했다.

Webpack 을 사용하는 이유

웹팩Webpack은 필요없는(사용하지 않는) 코드를 없앨 수 있다. 각 마이크로 서비스에 실제 사용되는 소스코드와 의존성만을 이용해 결과물을 만들어 낸다. 그렇기 때문에 필요없는 코드들을 없앨 수 있고 실제 기능에 필요한 코드만을 업로드할 수 있도록 한다.

위에서 예를 든 “회원 서비스”에서 사용하지 않는 B 의존성을 제거할 수 있다. 필요없는 의존성을 제거할 수 있기에 소스코드의 용량을 획기적으로 줄일 수 있을 것이라 생각했다.

Nest.js Webpack

다양한 웹팩 툴들이 있었지만 Nest.js 의 웹팩 옵션을 사용해 빌드하는 방식을 선택했다. 웹팩을 적용할 때 가장 중요한 조건 중 하나가 Nest.js 와의 호환성이었는데, Nest.js 에서 웹팩을 지원하고 있다면 그 방법이 최선이라고 생각했다.

package.json 파일에 웹팩을 적용해 빌드하도록 설정하고, 웹팩 설정을 위해 webpack.config.js 파일을 만들었다. 좀 더 자세한 내용은 Nest.js Webpack 적용 방법에서 확인할 수 있다.

package.json

  "scripts": {
    "build": "nest build --webpack --webpackPath ${PATH}/webpack.config.js"
  }

webpack.config.js

module.exports = (options, webpack) => {
  return {
    ...options,
    entry: `./src/${NESTJS_APP_PATH}`,
    externals: [],
    output: {
      ...options.output,
      clean: true,
      libraryTarget: 'commonjs2',
    },
    plugins: [
      ...options.plugins,
      new webpack.optimize.LimitChunkCountPlugin({
        maxChunks: 1,
      }),
    ],
  };
};

main.js

웹팩을 적용해 Nest.js 를 빌드하면 dist 디렉토리에 main.js 파일이 생성된다. 이 파일은 웹팩이 적용된 빌드 결과 파일 이다. 파일을 확인해보면 의존성을 포함한 관련 소스코드가 1개의 파일로 만들어져 있다.

main.js 라는 이름은 변경할 수 있으며 기본값이 main.js 이다.

Serverless Framework YAML

Nest.js 프로젝트에 웹팩을 적용했다면 웹팩이 적용된 파일을 deploy 할 수있도록 해야한다. package.json 와 sls YAML 파일을 아래와 같이 수정한다.

package.json

  "scripts": {
    "deploy:example": "nest build --webpack --webpackPath ${PATH}/webpack.config.js && sls deploy -c ./${YAML_PATH}/serverless.yaml"
  }

YAML

main.js 파일을 그대로 업로드 하는 방식이기에 더 이상 Lambda Layer 를 사용하지 않는다.

functions:
  exampleLambdaIndex:
    handler: dist/main.handler # main.js 의 handler 함수
    package:
      patterns:
        - '!**'
        - dist/main.js # webpack result
      individually: true

웹팩 적용을 끝내고 deploy 해보면 문제 없이 소스코드가 업로드되는 것을 확인할 수 있다.

  $ npm run deploy:example

Conclusion

250MB -> 15MB

웹팩을 적용함으로써 deploy 할 때 업로드할 소스코드의 양을 대폭 줄일 수 있었다. 기존의 방식은 프로젝트의 소스코드(dist)와 의존성(node_module)을 모두 업로드하는 방식이었기에 250MB가 넘어가는 용량이었지만 웹팩을 통해 약 15MB 정도의 main.js 만 업로드하는 방식으로 바꾸었다. 이를 통해 S3 의 저장용량도 줄일 수 있었다. (AWS Lambda 의 소스코드는 일정 용량 이상인 경우 S3 에 업로드 된다.)

Build 필수

sls 는 deploy 할 때, patterns 에 지정한 파일들을 그대로 패키징해 업로드한다. 빌드여부는 중요하지 않다. 그래서 가끔 코드를 수정한 뒤, build 를 하지 않고 deploy 했던 경우가 있었다. 그러면 수정 내용이 전혀 반영되지 않는다. webpack 처리를 위해 반드시 build 를 해야하기에 build 가 되지 않은 코드가 deploy 하는 일이 없어졌다.

Build 시간 증가

아쉬운 점은 이를 통해 build 시간이 꽤나 길어졌다는 것이다. webpack 을 적용하는 시간이 걸리면서 약 30초 이상, 경우에 따라서는 약 3분 이상 build 시간이 늘어났다. build 시간은 단축 할 수 있는 다른 툴들도 알아봐야할 필요가 생겼다.

URL Path Variable 숫자 타입 유효성 검사 오류 해결

Thu, 22 Sep 2022 00:00:00 GMT

[Nest.js] must be a number conforming to the specified constraints

author: Onejay
createdAt: 2022-09-22
updatedAt: 2022-09-22

Nest.js 에서 request 을 받을 때 발생한 validate 에러를 해결해 본다.

Intro

Client 에서 URL에 데이터를 넣는 Request (QueryString 또는 Path Variable) 를 보낼 때, 문자열이 아닌 데이터(숫자 등)를 보내면 발생하는 에러를 해결해 본다.

Source Code

Controller

아래의 코드와 같이 주문 상품의 수량을 변경하는 EndPoint 가 있다고 가정한다.

  @Patch('order/prod/count/:id/:count')
  @ApiResponse({
    status: HttpStatus.OK,
    type: OrderProdUpdateResponseDto,
    description: 'update ord prod',
  })
  @HttpCode(HttpStatus.OK)
  @UseGuards(ParamGuard)
  async updateOrdProd(
    @Param() param: OrderProdUpdateDto,
  ): Promise<OrderProdUpdateResponseDto> {
    console.log(TAG, 'patch-ord-prod-req', param);

    const result: OrderProdUpdateResponseDto = await this.orderService.updateOrdProd(
      param.id,
      param.count,
    );

    console.log(TAG, 'patch-ord-prod-res', result);

    return result;
  }

DTO

위의 엔드포인트의 Path Variable (id, count) 에 해당하는 데이터를 정의한다.

import { ApiProperty } from '@nestjs/swagger';
import { IsNotEmpty, IsNumber, IsString } from 'class-validator';
import { Type } from 'class-transformer';

export class OrderProdUpdateDto {
  @ApiProperty()
  @IsNotEmpty()
  @IsString()
  id: string;

  @ApiProperty({
    description: '주문 상품 수량',
  })
  @IsNotEmpty()
  @IsNumber()
  count: number;
}

Error

위의 DTO 코드를 보면 count 는 숫자형 변수이고 데코레이터로도 숫자형 데이터만을 받을 수 있도록 유효성 검사(@IsNumber)를 하고 있다.

그럼에도 불구하고 API 테스트 툴(Postman, Insomnia 등) 나 Swagger를 사용해 Request 를 보내면 아래와 같이 숫자형 데이터가 아니라는 에러가 발생한다.

  count must be a number conforming to the specified constraints

원인 분석

URL의 데이터를 통해 Request 를 받을 때, 숫자형 데이터가 문자열 타입 (URL이 문자열이므로) 그대로 DTO와 Mapping 되는 것

데이터를 RequestBody 와 같이 JSON 형태가 아니라 URL의 문자열로 보냈기 때문에, URL 경로에서 :count에 해당하는 데이터는 아래와 같이 문자열 로 DTO 의 count 필드와 맵핑된다.

Request

  https://www.ooooo.com/api/v1/order/prod/count/ABCD321321-12/3

count 는 숫자 3 이 아닌 문자열 ‘3’ 이다.

  {
    id: 'ABCD321321-12',
    count: '3'
  }

그렇기 때문에 URL 경로의 데이터들을 DTO 객체와 맵핑하는 과정에서 문자열 -> 숫자 로 변경하는 처리가 필요하다.

해결

@Type(() => 변경하고자 하는 타입) 데코레이터

@Type 데코레이터를 사용하면 URL 경로의 데이터들을 DTO 객체와 맵핑하는 과정에서 문자열 -> 숫자 로 변경하는 처리를 할 수 있다.
@Type(() => Number) 를 이용해 URL 경로의 데이터와 DTO의 필드가 맵핑 되기 전 에 숫자로 타입을 변경한다.
```
  @Type(() => Number)
  @IsNumber()
  count: number;
```
데코레이터는 위에서 아래로 적용된다. 따라서 @Type 데코레이터가 @IsNumber 데코레이터 보다 위에 있어야 한다. 반대의 경우, 숫자 타입으로 변경하지 않은 채 @IsNumber 가 적용되어 똑같은 에러가 발생한다.

지금까지 주로 JSON을 사용하여 데이터를 서버로 넘겼기 때문에 이와 같은 에러를 본 적이 없었다. 이번 경우도 URL 경로가 아닌 JSON 형태로 Request 를 보내면 문제없이 처리할 수 있었다.

하지만 QueryString 이나 Path Variable 과 같이 URL 에 직접 데이터를 보내는 경우에는 데이터를 모두 문자열 타입으로 처리하기 때문에 DTO 매핑 단계에서 타입 변경 처리가 반드시 필요하다는 사실을 알 수 있었다.

Refs
- Validating numeric query parameters in NestJS
- [NestJS] must be a number conforming to the specified constraints - body dto 타입 에러 해결

ESLint Parsing Error 해결 — TypeScript 파일 린트 설정

Sat, 28 May 2022 00:00:00 GMT

[React Native] ES Lint - Parsing error

author: Onejay
createdAt: 2022-05-28
updatedAt: 2022-05-28

ReactNative 의 ESLint 에러를 해결해 본다.

Intro

React Native 프로젝트에서 ES Lint 설정을 한 뒤, .eslintrc.js 파일을 조금 수정했다.

Typescript 를 사용하고 있기에 parserOptions 에 project 항목을 추가하여 tsconfig.json 파일을 참조하도록 했다.

.eslintrc.js

  ...

  'parserOptions': {
    'ecmaFeatures': {
      'jsx': true
    },
    'ecmaVersion': 12,
    'project': './tsconfig.json',
  },

  ...

그리고 기본값으로 설정되어 있는 package.json 파일의 lint를 실행했다.

package.json

  "scripts": {
    ...
    "lint": "eslint . --ext .js,.jsx,.ts,.tsx",
    ...
  },

실행

  $ npm run lint

  /${PROJECT_PATH}/${APP_NAME}/.eslintrc.js
    0:0  error  Parsing error: "parserOptions.project" has been set for @typescript-eslint/parser.
  The file does not match your project config: .eslintrc.js.
  The file must be included in at least one of the projects provided

  /${PROJECT_PATH}/${APP_NAME}/babel.config.js
    0:0  error  Parsing error: "parserOptions.project" has been set for @typescript-eslint/parser.
  The file does not match your project config: babel.config.js.
  The file must be included in at least one of the projects provided

  /${PROJECT_PATH}/${APP_NAME}/metro.config.js
    0:0  error  Parsing error: "parserOptions.project" has been set for @typescript-eslint/parser.
  The file does not match your project config: metro.config.js.
  The file must be included in at least one of the projects provided

원인 분석

Error 로그를 읽어보니 .eslintrc.js, babel.config.js, metro.config.js 3개의 설정 파일들이 .eslintrc.js 파일에 방금 추가한 project 속성의 설정과 맞지 않는다고 한다.

Typescript 를 적용하면서 project 속성에 tsconfig.json 을 설정했는데 이게 문제였다.

해결

.eslintrc.js 의 적용 대상에서 3개의 파일을 제외

이 에러에 대해 구글링해보니 의외로 해결 방법은 간단했다. .eslintrc.js 의 적용되는 대상에서 이 3개의 파일들을 제외하면 된다.

es lint 처리는 기본적으로 전체 프로젝트의 코드들을 대상으로 처리하기에 3개의 설정 파일(js)도 포함 된다. 하지만 이 3개의 설정 파일들은 es lint 처리를 할 필요가 없다. (직접적으로 코딩하는 파일이 아니므로)

더욱이 Typescript 로 코딩하기 때문에 ts, tsx 파일들만 lint 처리를 하면 된다.

특정 파일 형식(_.ts, _.tsx) 만 ES Lint 체크 대상에 넣기

package.json

_.js, _.jsx 파일을 대상에서 제외: eslint . --ext .ts,.tsx

  "scripts": {
    ...
    "lint": "eslint . --ext .ts,.tsx",
    ...
  },

특정 디렉토리만 ES Lint 체크 대상에 넣기

package.json

src 디렉토리만 대상으로 하기: eslint . --ext .ts,.tsx src/

  "scripts": {
    ...
    "lint": "eslint . --ext .ts,.tsx src/",
    ...
  },

Refs
- React Native에서 ESLint, Prettier를 프로처럼 사용하기

iOS 빌드 오류 해결 — Podfile.lock & Xcode 시뮬레이터 설정

Sat, 28 May 2022 00:00:00 GMT

[ReactNative] Error: iOS Build Failed

author: Onejay
createdAt: 2022-05-28
updatedAt: 2022-05-28

ReactNative 의 iOS 빌드 에러(xcode, podfile)를 해결해 본다.

Intro

React Native 를 이용해 iOS 빌드 중 아래의 2가지 에러로 빌드에 실패했다. 2가지 에러에 대한 원인을 찾아보고 해결해 보기로 했다.

  error Could not find "Podfile.lock"

  error Could not get the simulator list from Xcode.

Error

빌드 실패 에러는 아래와 같다.

  $ npm run ios

  error Could not find "Podfile.lock" at /${PROJECT_PATH}/ios/Podfile.lock. Did you run "pod install" in iOS directory?
  info Found Xcode project "${APP_NAME}.xcodeproj"
  xcrun: error: unable to find utility "simctl", not a developer tool or in PATH
  error Could not get the simulator list from Xcode. Please open Xcode and try running project directly from there to resolve the remaining issues. Run CLI with --verbose flag for more details.
  Error: Command failed: xcrun simctl list --json devices
  xcrun: error: unable to find utility "simctl", not a developer tool or in PATH

원인 분석

1) Could not find “Podfile.lock”

CocoaPod이 처음부터 잘못 설치된 것이 원인인듯 하다.

Pod 에 관한 에러는 이번이 처음이 아니었다. 처음 React Native 프로젝트 생성 당시에도 아래와 같은 에러가 발생하며 Pod 이 제대로 설치되지 않았다는 것을 알고 있었다.

  error Error: Failed to install CocoaPods dependencies for iOS project, which is required by this template.

다만 그 때는 에러 로그에 나온 방법대로 cd ./${APP_NAME}/ios && pod install 명령어를 통해 임시적으로 해결(묵인)하고 넘겼었다.

React Native 프로젝트 생성 당시의 에러

  $ npx react-native init ${APP_NAME} --template react-native-template-typescript

  ...

  ✔ Downloading template
  ✔ Copying template
  ✔ Processing template
  ✖ Installing CocoaPods dependencies (this may take a few minutes)
  ✖ Installing CocoaPods dependencies (this may take a few minutes)
  error Error: Failed to install CocoaPods dependencies for iOS project, which is required by this template.
  Please try again manually: "cd ./${APP_NAME}/ios && pod install".
  CocoaPods documentation: https://cocoapods.org/

  $ cd ./${APP_NAME}/ios && pod install

2) Could not get the simulator list from Xcode.

Xcode Command Line Tools 의 설치 경로가 잘못되었다.

Xcode Command Line Tools
- Mac에서 개발 환경을 구축하기 위해서는 필수인 Tool 이다. Git부터 Xcode Command Line Tools가 없으면 사용이 불가능하다.
- Xcode IDE 에 포함되어 있기 때문에 Xcode IDE 를 사용한다면 별도의 설치가 필요없다.
  - 다만, 앱 개발을 하는 경우가 아니라면 무겁고 용량도 많이 차지하는 Xcode IDE 보다는 가벼운 Xcode Command Line Tools 만 설치해도 된다.

기존에 이미 설치되어 있었던 Xcode Command Line Tools 를 지우지 않고 Xcode IDE 를 설치했기 때문에, Xcode IDE 의 Xcode Command Line Tools 설치 경로와 기존의 설치 경로가 다르게 되면서 시뮬레이터의 실행에 실패한듯 하다.

Xcode Command Line Tools 설치 경로 확인

  $ xcode-select -print-path

  /Library/Developer/CommandLineTools

Xcode IDE 설치 경로

  /Applications/Xcode.app/Contents/Developer

해결

1) Could not find “Podfile.lock”

CocoaPods 재설치

에러 로그에 나와있듯이 (Did you run "pod install" in iOS directory?) ios 디렉토리로 이동하여 CocoaPods 를 다시 설치 해본다.

ios 디렉토리로 이동
```
  $ cd ios
```

Install cocoapods

  $ pod install

  ...

  [Codegen] Generating ./build/generated/ios/React-Codegen.podspec.json
  Analyzing dependencies
  Fetching podspec for `DoubleConversion` from `../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec`
  [Codegen] Found FBReactNativeSpec
  Fetching podspec for `RCT-Folly` from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`
  Fetching podspec for `boost` from `../node_modules/react-native/third-party-podspecs/boost.podspec`
  Fetching podspec for `glog` from `../node_modules/react-native/third-party-podspecs/glog.podspec`

  ...

  [!] CocoaPods could not find compatible versions for pod "FlipperKit":
    In Podfile:
      FlipperKit (= 0.125.0)

  None of your spec sources contain a spec satisfying the dependency: `FlipperKit (= 0.125.0)`.

  You have either:
  * out-of-date source repos which you can update with `pod repo update` or with `pod install --repo-update`.
  * mistyped the name or version.
  * not added the source repo that hosts the Podspec to your Podfile.

다시 에러가 발생했다. 로그를 보아하니 레포지토리의 업데이트가 필요한 듯하다.

  pod repo update or pod install --repo-update

레포지토리를 업데이트하고 다시 설치한다.

Update Pod Repository

  $ pod repo update

  ...
  ...
  Updating spec repo `trunk`

Install cocoapods

  $ pod install

  ...

  [Codegen] Generating ./build/generated/ios/React-Codegen.podspec.json
  Analyzing dependencies
  Fetching podspec for `DoubleConversion` from `../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec`
  [Codegen] Found FBReactNativeSpec
  Fetching podspec for `RCT-Folly` from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`
  Fetching podspec for `boost` from `../node_modules/react-native/third-party-podspecs/boost.podspec`
  Fetching podspec for `glog` from `../node_modules/react-native/third-party-podspecs/glog.podspec`
  Downloading dependencies
  Installing CocoaAsyncSocket (7.6.5)
  Installing DoubleConversion (1.1.6)

  ...

  Installing glog (0.3.5)
  Installing libevent (2.1.12)
  Generating Pods project
  /${PROJECT_NAME}/${APP_NAME}/ios/Pods/Target Support Files/Pods-${APP_NAME}/Pods-${APP_NAME}.release.xcconfig
  /${PROJECT_NAME}/${APP_NAME}/ios/Pods/Target Support Files/Pods-${APP_NAME}/Pods-${APP_NAME}.debug.xcconfig
  /${PROJECT_NAME}/${APP_NAME}/ios/Pods/Target Support Files/Pods-${APP_NAME}-${APP_NAME}Tests/Pods-${APP_NAME}-${APP_NAME}Tests.release.xcconfig
  /${PROJECT_NAME}/${APP_NAME}/ios/Pods/Target Support Files/Pods-${APP_NAME}-${APP_NAME}Tests/Pods-${APP_NAME}-${APP_NAME}Tests.debug.xcconfig
  React-Core
  Integrating client project

  [!] Please close any current Xcode sessions and use `${APP_NAME}.xcworkspace` for this project from now on.
  Pod installation complete! There are 55 dependencies from the Podfile and 46 total pods installed.

이번에는 성공했다. 일단 첫 번째 에러는 해결된 듯 하다.

2) Could not get the simulator list from Xcode.

Xcode Command Line Tools 의 설치 경로 변경

이 에러는 좀더 간단하다. 터미널에서 몇 개의 명령어만 실행하면 금방 해결할 수 있었다.

① Home 으로 이동
```
  $ cd ~
```

② Xcode Command Line Tools 설치 경로 확인

  $ xcode-select -print-path
  /Library/Developer/CommandLineTools

③ Xcode IDE 설치 경로 확인: finder 등으로 확인한다.
- (내 로컬의 경우) /Applications/Xcode.app/Contents/Developer

④ Xcode Command Line Tools 설치 경로를 Xcode IDE 의 설치 경로로 변경

  $ sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
  Password: 비밀번호 입력

⑤ Xcode Command Line Tools 설치 경로 확인

  $ xcode-select -print-path
  /Applications/Xcode.app/Contents/Developer

iOS Build

2가지 에러가 해결되었는지 확인을 위해 다시 한 번 ios 를 빌드해 본다.

프로젝트 디렉토리로 이동하여 실행

  $ npm run ios

  > ${APP_NAME}@0.0.1 ios
  > react-native run-ios

  info Found Xcode workspace "${APP_NAME}.xcworkspace"
  info Building (using "xcodebuild -workspace ${APP_NAME}.xcworkspace -configuration Debug -scheme ${APP_NAME} -destination ...")
  success Successfully built the app

  ...

  success Successfully launched the app on the simulator

빌드가 성공적으로 끝나고 Xcode 시뮬레이터가 실행되었다. 정상적으로 리액트 기본 앱이 실행되는 것을 확인 할 수 있다.

Refs
- 공식 사이트의 튜토리얼

중첩된 .git 디렉토리로 인한 adding files failed 에러 해결

Sat, 28 May 2022 00:00:00 GMT

[Git] Error: does not have a commit checked out

author: Onejay
createdAt: 2022-05-28
updatedAt: 2022-05-28

Git 의 adding files failed 에러를 알아보고 해결해 본다.

Intro

여러 개의 프로젝트를 하나의 Git Repository 에서 관리하고 있었다. 새롭게 Nest.js 프로젝트를 명령어(nest cli)를 통해 생성했고 생성한 프로젝트를 Git 에 Commit 하려고 하니 add 가 되지 않았다.

GitRepository
├── A Project
├── B Project
├── C Project
├── D Project
└── E Project (new project)

Error

Git Error 의 메시지는 아래와 같았다.

  error: '${PROJECT_NAME}/' does not have a commit checked out
  fatal: adding files failed

원인 분석

에러 메시지를 바탕으로 구글링 해본 결과 아래의 경우가 원인인 듯 했다.

> `.git` 디렉토리가 중복으로 존재하는 경우

한 개의 Git Repository 에는 하나의 .git 디렉토리만 있어야한다. 그런데 이번에 새롭게 추가한 Nest.js 프로젝트는 명령어(nest cli)로 생성할 경우 자동으로 Nest.js 프로젝트 내부에 .git 디렉토리를 생성한다. 이것이 에러의 원인이었다.

Git Repository 의 구조를 정리하면 아래와 같다.

Project Structure

GitRepository
├── A Project
├── B Project
├── C Project
├── D Project
├── E Project (new project)
│ ├── .git # 자동으로 생성된 디렉토리
│ └── .gitignore
├── .git
└── .gitignore

해결

해결 방법은 간단하다.

자동으로 생성된 .git 디렉토리를 삭제 한다.
```
  $ rm -rf .git .gitignore
```

Android 빌드 실패 — JAVA_HOME 환경변수 설정

Fri, 27 May 2022 00:00:00 GMT

[ReactNative] Android Build Failed

author: Onejay
createdAt: 2022-05-27
updatedAt: 2022-05-27

ReactNative 의 안드로이드 빌드 에러(DeviceException)를 해결해 본다.

Intro

React Native 를 이용해 Android 빌드 중 아래의 에러로 빌드에 실패했다.

  Execution failed for task ':app:installDebug'.
  > com.android.builder.testing.api.DeviceException: No connected devices!

Error

빌드 실패 에러는 아래와 같다.

  $ npx react-native run-android

  info Running jetifier to migrate libraries to AndroidX. You can disable it using "--no-jetifier" flag.
  Jetifier found 936 file(s) to forward-jetify. Using 4 workers...
  info JS server already running.
  info Launching emulator...
  error Failed to launch emulator. Reason: Could not start emulator within 30 seconds..
  warn Please launch an emulator manually or connect a device. Otherwise app may fail to launch.
  info Installing the app...

  > Configure project :app
  Unable to detect AGP versions for included builds. All projects in the build should use the same AGP version. Class name for the included build object: org.gradle.composite.internal.DefaultIncludedBuild$IncludedBuildImpl_Decorated.

  > Task :app:installDebug FAILED
  37 actionable tasks: 2 executed, 35 up-to-date

  FAILURE: Build failed with an exception.

  * What went wrong:
  Execution failed for task ':app:installDebug'.
  > com.android.builder.testing.api.DeviceException: No connected devices!

  * Try:
  > Run with --stacktrace option to get the stack trace.
  > Run with --info or --debug option to get more log output.
  > Run with --scan to get full insights.

  * Get more help at https://help.gradle.org

  BUILD FAILED in 9s

  error Failed to install the app. Make sure you have an Android emulator running or a device connected.
  Error: Command failed: ./gradlew app:installDebug -PreactNativeDevServerPort=8081

  FAILURE: Build failed with an exception.

  * What went wrong:
  Execution failed for task ':app:installDebug'.
  > com.android.builder.testing.api.DeviceException: No connected devices!

  * Try:
  > Run with --stacktrace option to get the stack trace.
  > Run with --info or --debug option to get more log output.
  > Run with --scan to get full insights.

  * Get more help at https://help.gradle.org

  BUILD FAILED in 9s

      at makeError (/${PROJECT_PATH}/${APP_NAME}/node_modules/@react-native-community/cli-platform-android/node_modules/execa/index.js:174:9)
      at /${PROJECT_PATH}/${APP_NAME}/node_modules/@react-native-community/cli-platform-android/node_modules/execa/index.js:278:16
      at processTicksAndRejections (node:internal/process/task_queues:96:5)
      at async runOnAllDevices (/${PROJECT_PATH}/${APP_NAME}/node_modules/@react-native-community/cli-platform-android/build/commands/runAndroid/runOnAllDevices.js:109:5)
      at async Command.handleAction (/${PROJECT_PATH}/${APP_NAME}/node_modules/@react-native-community/cli/build/index.js:192:9)
  info Run CLI with --verbose flag for more details.

원인 분석

JAVA_HOME 환경변수가 설정되어 있지 않았기 때문에 jdk 를 찾을 수 없다

이 에러 메시지를 구글링 해보니 JAVA_HOME 환경변수가 설정되어 있지 않았기 때문에 jdk 를 찾을 수 없을 때 나타나는 에러라고 한다.

JAVA_HOME

- Java 프로그래밍이나 jvm 프로그램들을 실행하기 위해서는 **JAVA_HOME** 변수 를 시스템(OS)에 등록해야 한다.
  + 등록하지 않을 경우, 매번 시스템(OS)의 jdk 경로를 지정해줘야 한다.

- **JAVA_HOME** 변수는 일종의 전역 변수(_Global Variable_) 이다.
  + 시스템(OS)의 전역 변수로서 **JAVA_HOME** 이라는 전역 변수를 시스템(OS)에 등록하면 시스템(OS) 어디서든 java 를 실행하고 사용할 수 있다.

- Android Studio 나 IntelliJ, Tomcat 등의 java 를 이용하는 프로그램들이 Build, BootRun, Emulator 등을 실행 할 때, 별도로 jdk 의 경로를 지정해주지 않아도 시스템(OS)의 **JAVA_HOME** 이라는 변수를 불러와 사용한다.
  + JDK 경로는 **JAVA_HOME** 에 저장되어 있다는 약속
  + 이 약속된 변수 **JAVA_HOME** 이 없었기에 빌드에 실패했다. 따라서 이 변수를 지정해주어야 한다.

해결

JAVA_HOME 환경변수 설정

① Home 으로 이동
```
  $ cd ~
```

② JAVA_HOME 환경변수가 없을 경우 가장 아래쪽에 추가

  $ echo export JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home >> .zshrc

③ zshrc 적용
```
  $ source .zshrc
```

④ JAVA_HOME 확인

  $ echo $JAVA_HOME

  /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home

Android Build

에러가 해결되었는지 확인을 위해 다시 한 번 android 를 빌드해 본다.

프로젝트 디렉토리로 이동하여 실행

  $ npx react-native run-android
  info Running jetifier to migrate libraries to AndroidX. You can disable it using "--no-jetifier" flag.
  Jetifier found 936 file(s) to forward-jetify. Using 4 workers...
  info JS server already running.
  info Installing the app...

  > Configure project :app
  Unable to detect AGP versions for included builds. All projects in the build should use the same AGP version. Class name for the included build object: org.gradle.composite.internal.DefaultIncludedBuild$IncludedBuildImpl_Decorated.

  > Task :app:installDebug
  Installing APK 'app-debug.apk' on 'Nexus_6_API_30(AVD) - 11' for app:debug
  Installed on 1 device.

  BUILD SUCCESSFUL in 11s
  37 actionable tasks: 2 executed, 35 up-to-date
  info Connecting to the development server...
  8081
  info Starting the app on "emulator-5554"...
  Starting: Intent { cmp=com.${APP_NAME}/.MainActivity }

빌드가 성공적으로 끝나고 Android 시뮬레이터가 실행되었다. 정상적으로 리액트 기본 앱이 실행되는 것을 확인 할 수 있다.

Refs
- 공식 사이트의 튜토리얼

Onejay Lab | Blog

nodenv 환경에서 Node 버전 상관없이 Claude Code 실행하기

내용

1. IDE 의 플러그인을 사용

2. .node-version 을 global 버전과 같은 버전으로 변경

3. NODENV_VERSION=글로벌버전 claude 으로 실행

결론

Route53 - DNS 레코드 추가 및 확인

Intro

Body

Root Domain

A 레코드

CNAME

NS

DNS Record 확인 방법

dig 명령어

사용방법

사용 예

구글 툴 박스

Conclusion(Outro)

Log Insights로 로그 손쉽게 검색하기

Log Insights 로 CloudWatch Log 검색하기

Intro

CloudWatch 의 로그 구조

Log Insight 를 사용해야하는 이유

Log Insights Query

주의점

Code Storage Limit 초과 해결 — Serverless Prune Plugin

[Jobː談] AWS Lambda Storage Limit Error 해결: Prune Plugin

Intro

AWS Lambda Code Storage?

해결 방법

1) 코드 스토리지 용량 확보

※ Lambda Function Version

2) Serverless Framework 설정

3) Deploy

Conclusion

Webpack으로 소스코드 용량 줄여 Upload Size Limit 해결하기

[Jobː談] AWS Lambda Unzipped size must be smaller than 262144000 bytes Error: Webpack

Intro

소스코드의 용량이 늘어난 이유

Webpack 을 사용하는 이유

Nest.js Webpack

main.js

Serverless Framework YAML

Conclusion

URL Path Variable 숫자 타입 유효성 검사 오류 해결

[Nest.js] must be a number conforming to the specified constraints

Intro

Source Code

Controller

DTO

Error

원인 분석

해결

ESLint Parsing Error 해결 — TypeScript 파일 린트 설정

[React Native] ES Lint - Parsing error

Intro

원인 분석

해결

특정 파일 형식(_.ts, _.tsx) 만 ES Lint 체크 대상에 넣기

특정 디렉토리만 ES Lint 체크 대상에 넣기

iOS 빌드 오류 해결 — Podfile.lock & Xcode 시뮬레이터 설정

[ReactNative] Error: iOS Build Failed

Intro

Error

원인 분석

1) Could not find “Podfile.lock”

2) Could not get the simulator list from Xcode.

해결

1) Could not find “Podfile.lock”

2) Could not get the simulator list from Xcode.

iOS Build

중첩된 .git 디렉토리로 인한 adding files failed 에러 해결

[Git] Error: does not have a commit checked out

Intro

Error

원인 분석

해결

Android 빌드 실패 — JAVA_HOME 환경변수 설정

3. `NODENV_VERSION=글로벌버전 claude` 으로 실행