es mio

터미널에서 gui 여는법 - open ./

esoesmio — Tue, 25 Jun 2024 23:24:34 +0900

터미널에서 gui 여는법 - open ./

컨트롤러 코드 취약점 오류

esoesmio — Tue, 18 Jun 2024 23:22:20 +0900

컨트롤러 코드에서 발생할 수 있는 여러 보안 취약점 및 오류를 살펴보고, 그 예시와 예방 방법을 설명하겠습니다.

### 잠재적인 보안 취약점 및 오류

1. **Cross-Site Scripting (XSS)**
2. **SQL Injection**
3. **Input Validation 부족**
4. **Unauthorized Access**
5. **Data Exposure**
6. **Improper Error Handling**

### 1. Cross-Site Scripting (XSS)

**문제**: 사용자가 입력한 데이터를 검증하지 않고 그대로 렌더링할 때 발생할 수 있습니다. 예를 들어, `description` 필드에 스크립트를 삽입할 수 있습니다.

**예시**:
```json

{
  "description": "<script>alert('XSS');</script>"
}

```

이 데이터가 검증 없이 렌더링되면, 스크립트가 실행되어 XSS 공격이 발생합니다.

**예방 방법**:
- 입력 데이터 검증 및 이스케이프 처리
- 서버에서 데이터 저장 전에 sanitize 처리

**코드**:
```typescript

import sanitizeHtml from 'sanitize-html';

// Sanitize description to prevent XSS
const sanitizedDescription = sanitizeHtml(body.description);
await this.sellersService.changeDescription(sellerId, sanitizedDescription);

```

### 2. SQL Injection

**문제**: 사용자 입력이 직접 SQL 쿼리에 포함될 때 발생할 수 있습니다. ORM을 사용하면 대부분의 경우 방지할 수 있지만, 직접 쿼리를 작성할 때는 주의해야 합니다.

**예시**:
```json

{
  "sellerId": "1 OR 1=1"
}

```

**예방 방법**:
- 파라미터화된 쿼리 사용
- ORM을 사용할 경우 ORM의 보안 기능 사용

**코드**:
ORM을 사용하면 보통 안전하지만, 직접 쿼리를 작성할 경우 다음과 같이 작성해야 합니다:
```typescript

const seller = await this.sellerRepository.findOne({
  where: { id: sellerId }
});

```

### 3. Input Validation 부족

**문제**: 입력 값의 유효성을 검증하지 않으면, 예상치 못한 입력이 시스템에 영향을 줄 수 있습니다.

**예시**:
- `sellerId`에 숫자가 아닌 값을 입력
- `shippingCharge`에 음수 값을 입력

**예방 방법**:
- DTO(Data Transfer Object)와 class-validator를 사용하여 입력 값 검증

**코드**:
```typescript

import { IsInt, IsString, IsPositive } from 'class-validator';

class SellerIdParam {
  @IsInt()
  sellerId: number;
}

class ModifyUserRequest {
  @IsString()
  description: string;

  @IsString()
  csPath: string;

  @IsString()
  shippingType: string;

  @IsPositive()
  shippingCharge: number;

  @IsString()
  plan: string;

  @IsArray()
  @IsString({ each: true })
  imageUrls: string[];

  @ValidateNested()
  bankInformation: BankInformation;
}

class BankInformation {
  @IsString()
  bank: string;

  @IsString()
  accountNumber: string;

  @IsString()
  customerName: string;
}

```

### 4. Unauthorized Access

**문제**: 인증되지 않은 사용자가 리소스에 접근할 수 있습니다.

**예시**: 인증이 필요한 엔드포인트에 인증 없이 접근

**예방 방법**:
- JWT 또는 OAuth를 사용하여 인증 처리
- 권한 검사를 통해 특정 사용자만 접근 가능하도록 설정

**코드**:
```typescript

// 인증 및 권한 검사 미들웨어 사용
import { UseGuards } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';

@UseGuards(AuthGuard('jwt'))
@Patch('update')
async updateSeller(
  @User() user,
  @Body() body: ModifyUserRequest,
  @Param() param: SellerIdParam,
) {
  // ...
}

```

### 5. Data Exposure

**문제**: 민감한 정보가 외부에 노출될 수 있습니다.

**예시**: 응답 데이터에 민감한 정보가 포함될 경우

**예방 방법**:
- 필요하지 않은 민감한 정보는 응답에서 제외
- 데이터 전달 전에 필요한 부분만 선택적으로 전달

**코드**:
```typescript

const seller = await this.sellersService.findSeller(sellerId);
// 필요한 데이터만 응답
return {
  id: seller.id,
  name: seller.name,
  description: seller.description,
  // 기타 필요한 필드만 포함
};

```

### 6. Improper Error Handling

**문제**: 에러 메시지가 너무 상세하여 공격자에게 시스템 정보를 제공할 수 있습니다.

**예시**: 데이터베이스 에러 메시지를 그대로 사용자에게 전달

**예방 방법**:
- 에러 메시지를 사용자 친화적으로 작성
- 내부 에러 메시지를 로깅 시스템에만 기록

**코드**:
```typescript

if (!seller) {
  throw new NotFoundException({
    status: HttpStatus.NOT_FOUND,
    error: 'Not Found Seller',
    message: '셀러를 찾을 수 없습니다.',
  });
}

```

### 결론

위에서 언급한 보안 취약점 및 오류를 예방하기 위해서는 입력 데이터의 철저한 검증, 인증 및 권한 검사, 민감한 정보의 보호, 그리고 적절한 에러 처리가 필요합니다. 각 예시에 대한 해결 방법을 통해 보안을 강화할 수 있습니다.

물론입니다. 더 많은 보안 취약점 및 오류를 포함한 예시와 그에 대한 예방 방법을 추가로 설명하겠습니다.

### 7. **Mass Assignment**

**문제**: 사용자가 의도하지 않은 데이터 필드를 변경할 수 있습니다.

**예시**: 클라이언트에서 전달된 데이터가 직접적으로 객체에 할당될 때, 악의적인 사용자가 권한이 없는 필드를 변경할 수 있습니다.

**예방 방법**:
- DTO(Data Transfer Object)를 사용하여 변경 가능한 필드를 명시적으로 정의
- 안전한 객체 할당 방법 사용

**코드**:
```typescript

class UpdateSellerDto {
  @IsString()
  description: string;

  @IsString()
  csPath: string;

  @IsString()
  shippingType: string;

  @IsPositive()
  shippingCharge: number;

  @IsString()
  plan: string;

  @IsArray()
  @IsString({ each: true })
  imageUrls: string[];

  @ValidateNested()
  bankInformation: BankInformation;
}

// 서비스 메서드에서만 DTO를 통해 값을 할당
await this.sellerRepository.update(sellerId, updateSellerDto);

```

### 8. **File Upload Security**

**문제**: 파일 업로드 기능에서 악성 파일을 업로드할 수 있습니다.

**예시**: 악의적인 사용자가 스크립트나 바이러스가 포함된 파일을 업로드

**예방 방법**:
- 파일 확장자 및 MIME 타입 검증
- 파일 크기 제한
- 업로드된 파일의 경로를 안전하게 처리

**코드**:
```typescript

import { diskStorage } from 'multer';
import { extname } from 'path';

const storage = diskStorage({
  destination: './uploads',
  filename: (req, file, callback) => {
    const uniqueSuffix = Date.now() + '-' + Math.round(Math.random() * 1E9);
    callback(null, file.fieldname + '-' + uniqueSuffix + extname(file.originalname));
  },
});

const fileFilter = (req, file, callback) => {
  if (!file.originalname.match(/\.(jpg|jpeg|png|gif)$/)) {
    return callback(new Error('Only image files are allowed!'), false);
  }
  callback(null, true);
};

@Controller('upload')
export class UploadController {
  @Post('image')
  @UseInterceptors(FileInterceptor('file', { storage, fileFilter }))
  uploadFile(@UploadedFile() file) {
    // 파일 업로드 처리
  }
}

```

### 9. **Rate Limiting**

**문제**: 서비스가 무차별 대입 공격 또는 과도한 요청으로 인해 장애가 발생할 수 있습니다.

**예시**: 동일한 IP에서 다수의 로그인 시도

**예방 방법**:
- 요청 횟수 제한 (Rate Limiting)
- 특정 시간 동안 허용된 요청 횟수를 초과하면 요청을 차단

**코드**:
```typescript

import { Throttle, ThrottlerGuard } from '@nestjs/throttler';
import { UseGuards } from '@nestjs/common';

@Controller('auth')
@UseGuards(ThrottlerGuard)
export class AuthController {
  @Throttle(5, 60) // 1분에 최대 5번 요청 가능
  @Post('login')
  async login(@Body() loginDto: LoginDto) {
    // 로그인 처리
  }
}

```

### 10. **CSRF (Cross-Site Request Forgery)**

**문제**: 사용자가 의도하지 않은 요청을 다른 사이트에서 보낼 수 있습니다.

**예시**: 악의적인 웹사이트에서 사용자의 인증 정보를 사용하여 요청을 보냄

**예방 방법**:
- CSRF 토큰 사용
- 서버에서 요청 시마다 CSRF 토큰을 검증

**코드**:
```typescript
import { CsrfModule, CsrfGuard } from 'nestjs-csrf';

import { UseGuards } from '@nestjs/common';

@Module({
  imports: [CsrfModule],
})
export class AppModule {}

@Controller('form')
@UseGuards(CsrfGuard)
export class FormController {
  @Post('submit')
  submitForm(@Body() formData: FormData) {
    // 폼 처리
  }
}

```

### 11. **Sensitive Data Exposure**

**문제**: 로그 또는 응답에서 민감한 데이터가 노출될 수 있습니다.

**예시**: 비밀번호나 신용카드 정보가 로그에 기록됨

**예방 방법**:
- 민감한 데이터는 절대 로그에 기록하지 않음
- 필요 시 민감한 데이터를 마스킹 처리

**코드**:
```typescript

class UserDto {
  @Exclude()
  password: string;

  @Expose()
  username: string;

  @Expose()
  email: string;
}

// User 엔티티를 UserDto로 변환하여 응답
const userDto = plainToClass(UserDto, user);
return userDto;

```

### 12. **Insecure Direct Object References (IDOR)**

**문제**: 사용자가 권한이 없는 리소스에 접근할 수 있습니다.

**예시**: URL에 다른 사용자의 ID를 입력하여 그 사용자의 정보에 접근

**예방 방법**:
- 접근 권한을 철저히 검증
- 사용자의 요청에 대해 권한 확인

**코드**:
```typescript

async updateSeller(
  @User() user,
  @Body() body: ModifyUserRequest,
  @Param() param: SellerIdParam,
) {
  const sellerId = param.sellerId;
  const detail = await this.sellersService.isExist(sellerId);
  if (!detail || detail.ownerId !== user.id) {
    throw new NotFoundException({
      status: HttpStatus.NOT_FOUND,
      error: 'Not Found Seller',
      message: '셀러를 찾을 수 없거나 접근 권한이 없습니다.',
    });
  }
  // 업데이트 로직
}

```

### 13. **Improper Logging**

**문제**: 로그에 민감한 정보가 포함될 수 있습니다.

**예시**: 사용자 비밀번호, 토큰, 신용카드 정보 등이 로그에 기록

**예방 방법**:
- 민감한 정보는 로그에 포함하지 않음
- 로그 레벨을 적절히 설정

**코드**:
```typescript

const sensitiveFields = ['password', 'token', 'creditCard'];
const filteredBody = Object.keys(body)
  .filter(key => !sensitiveFields.includes(key))
  .reduce((obj, key) => {
    obj[key] = body[key];
    return obj;
  }, {});

this.logger.log(`Request body: ${JSON.stringify(filteredBody)}`);

```

### 결론

위에서 설명한 보안 취약점 및 오류들은 실무에서 자주 발생할 수 있는 문제들입니다. 이를 예방하기 위해서는 철저한 입력 검증, 적절한 인증 및 권한 검사, 민감한 정보 보호, 그리고 적절한 에러 처리가 필요합니다. 각 예시에 대한 해결 방법을 통해 시스템의 보안성을 강화할 수 있습니다.

[javascript] 프로토타입이 무엇인가

esoesmio — Wed, 12 Jun 2024 23:32:47 +0900

프로토타입은 자바스크립트의 객체 지향 프로그래밍에서 매우 중요한 개념으로, 객체가 다른 객체의 메서드와 속성을 상속받을 수 있게 하는 메커니즘입니다. 이를 이해하기 위해 프로토타입의 정의와 동작 방식, 그리고 실생활 비유와 예제를 통해 설명하겠습니다.

프로토타입의 정의

프로토타입은 자바스크립트의 모든 객체가 가지고 있는 숨겨진 속성으로, 다른 객체로부터 메서드와 속성을 상속받는 데 사용됩니다. 자바스크립트는 프로토타입 기반 언어로, 클래스 기반 언어와 달리 상속을 구현하기 위해 프로토타입 체인을 사용합니다.

실생활 비유

프로토타입을 실생활에 비유하면 이해가 쉬워집니다. 예를 들어, 가구 공장에서 테이블을 만드는 과정을 생각해봅시다.

템플릿(원형): 공장에서는 테이블을 만들기 위해 "테이블 템플릿"을 가지고 있습니다. 이 템플릿에는 테이블의 기본 구조와 기능이 정의되어 있습니다. 이 템플릿이 프로토타입이라고 생각할 수 있습니다.
개별 테이블: 이 템플릿을 사용하여 만들어진 각각의 테이블은 개별 객체입니다. 모든 테이블은 템플릿의 특성을 공유하지만, 개별 테이블마다 색상이나 크기와 같은 고유한 특성을 가질 수 있습니다.
상속: 만약 "책상"이라는 새로운 종류의 테이블을 만든다면, 이 책상은 "테이블 템플릿"을 기반으로 만들되, 추가적으로 서랍이나 책꽂이 같은 기능을 더할 수 있습니다. 이때 책상은 테이블 템플릿의 특성을 상속받아 기본 기능을 유지하면서도 새로운 기능을 추가합니다.

자바스크립트에서 프로토타입

자바스크립트에서 모든 객체는 프로토타입이라는 숨겨진 속성을 가집니다. 이 프로토타입은 객체가 다른 객체의 메서드와 속성을 사용할 수 있게 합니다. 객체의 프로토타입은 [[Prototype]]이라는 내부 프로퍼티로 참조되며, 이는 Object.getPrototypeOf(obj)를 통해 접근할 수 있습니다.'

// Bird 생성자 함수
function Bird(name, sound) {
    this.name = name;
    this.sound = sound;
}

// Bird 프로토타입에 메서드 추가
Bird.prototype.fly = function () {
    console.log(`${this.name} ${this.sound} 비행중`);
};

// Eagle 생성자 함수
function Eagle(name, sound, prey) {
    Bird.call(this, name, sound);  // Bird 생성자 호출
    this.prey = prey;
}

// Eagle이 Bird를 상속받도록 설정
Eagle.prototype = Object.create(Bird.prototype);
Eagle.prototype.constructor = Eagle;

// Eagle 프로토타입에 메서드 추가
Eagle.prototype.hunt = function () {
    console.log(`${this.name} ${this.prey} 사냥중`);
};

// 인스턴스 생성
const eagle = new Eagle('독돌이', '푸드덕', '토끼');

// 메서드 호출
eagle.fly();  // 독돌이 푸드덕 비행중
eagle.hunt(); // 독돌이 토끼 사냥중

// 프로토타입 체인 확인
console.log(eagle instanceof Eagle); // true
console.log(eagle instanceof Bird);  // true

프로토타입 체인

자바스크립트 객체는 프로토타입 체인을 통해 다른 객체의 속성과 메서드를 사용할 수 있습니다. 프로토타입 체인은 객체가 특정 속성이나 메서드를 찾지 못하면, 프로토타입 체인을 따라 상위 객체의 프로토타입에서 해당 속성이나 메서드를 찾는 방식으로 동작합니다.

예제 설명

객체 생성:

const eagle = new Eagle('독돌이', '푸드덕', '토끼');

Eagle 생성자를 통해 eagle 객체가 생성됩니다. 이 객체는 Eagle의 프로토타입을 통해 Bird의 메서드도 사용할 수 있습니다.

2. 메서드 호출

eagle.fly();  // 독돌이 푸드덕 비행중
eagle.hunt(); // 독돌이 토끼 사냥중

eagle.fly()를 호출하면 Eagle의 프로토타입 체인을 따라 Bird.prototype에 있는 fly 메서드가 호출됩니다. eagle.hunt()는 Eagle.prototype에 정의된 메서드를 직접 호출합니다.

3. 프로토타이 ㅂ체인 확인

console.log(eagle instanceof Eagle); // true
console.log(eagle instanceof Bird);  // true

eagle 객체는 Eagle과 Bird의 인스턴스입니다. 이는 Eagle이 Bird를 상속받았기 때문에 가능한 일입니다.

결론

프로토타입은 자바스크립트의 객체가 다른 객체의 메서드와 속성을 상속받는 데 사용하는 메커니즘입니다. 이를 통해 객체는 메모리를 절약하고, 공통 기능을 공유하며, 객체 간 상속 관계를 설정할 수 있습니다. 프로토타입 체인은 객체가 특정 속성이나 메서드를 찾을 때 상위 객체의 프로토타입을 따라가는 경로로, 이를 통해 효율적인 코드 재사용과 상속을 구현할 수 있습니다.

정적바인딩, 동적바인딩

esoesmio — Wed, 12 Jun 2024 18:36:51 +0900

JavaScript의 this 키워드는 함수 호출 방식에 따라 동적으로 바인딩되거나, 특별한 경우에 정적으로 바인딩될 수 있습니다. 이를 이해하기 위해 먼저 동적 바인딩과 정적 바인딩이 무엇인지 살펴보겠습니다.

동적 바인딩 (Dynamic Binding)

동적 바인딩은 함수 호출 시점에 this가 결정되는 것을 의미합니다. 이는 JavaScript의 일반적인 함수 호출 방식에서 주로 발생합니다. this는 호출 컨텍스트에 따라 다르게 바인딩될 수 있습니다.

주요 동적 바인딩 예시

전역 컨텍스트에서 호출된 함수:

function foo() {
    console.log(this);
}
foo(); // window (브라우저 환경에서) 또는 global (Node.js 환경에서)

2. 객체의 메서드로 호출된 함수:

const obj = {
    name: 'Alice',
    greet: function() {
        console.log(this.name);
    }
};
obj.greet(); // "Alice"

3. 함수에서 call, apply, bind 메서드를 사용한 경우:

function greet() {
    console.log(this.name);
}
const user = { name: 'Bob' };
greet.call(user);  // "Bob"
greet.apply(user); // "Bob"

const boundGreet = greet.bind(user);
boundGreet(); // "Bob"

4. 생성자함수

function Person(name) {
    this.name = name;
}
const person = new Person('Charlie');
console.log(person.name); // "Charlie"

정적 바인딩 (Static Binding)

정적 바인딩은 this가 함수 정의 시점에 결정되는 것을 의미합니다. JavaScript에서는 주로 화살표 함수(arrow function)에서 발생합니다. 화살표 함수는 자신만의 this 바인딩을 가지지 않고, 정의될 때의 상위 스코프의 this를 그대로 사용합니다.

화살표 함수의 정적 바인딩 예시

상위 스코프의 this를 사용하는 화살표 함수:

const obj = {
    name: 'Dave',
    greet: function() {
        const inner = () => {
            console.log(this.name);
        };
        inner();
    }
};
obj.greet(); // "Dave"

2. 전역 컨텍스트에서 화살표 함수:

const arrowFunc = () => {
    console.log(this);
};
arrowFunc(); // window (브라우저 환경에서) 또는 global (Node.js 환경에서)

차이점 요약

동적 바인딩: 함수 호출 방식에 따라 this가 달라짐. 일반적인 함수 및 메서드에서 주로 발생.
정적 바인딩: this가 함수 정의 시점에 결정됨. 주로 화살표 함수에서 발생.

예제 코드

동적 바인딩 예제:'

function dynamicThis() {
    console.log(this);
}

const obj = {
    name: 'Eve',
    dynamicThis: dynamicThis
};

dynamicThis(); // 전역 객체 (window 또는 global)
obj.dynamicThis(); // obj 객체

정적 바인딩 예제:

const staticThis = () => {
    console.log(this);
};

const anotherObj = {
    name: 'Frank',
    staticThis: staticThis
};

staticThis(); // 전역 객체 (window 또는 global)
anotherObj.staticThis(); // 여전히 전역 객체

이렇게 this의 동적 바인딩과 정적 바인딩은 함수가 어떻게 호출되었는지에 따라 달라지며, 특히 화살표 함수는 정의 시점의 상위 스코프의 this를 사용함으로써 정적 바인딩의 특성을 가집니다.

[nestJS] nesJS 설명 좋은 블로그

esoesmio — Sat, 25 May 2024 16:55:23 +0900

https://cdragon.tistory.com/entry/NestJS-1-NestJS%EC%9D%98-%EA%B5%AC%EC%A1%B0-%EB%B0%8F-%EA%B4%80%EB%A0%A8-%EC%9A%A9%EC%96%B4-%EC%A0%95%EB%A6%AC%EB%B0%B1%EC%97%94%EB%93%9C%EC%9D%98-%EB%AA%A8%EB%93%A0-%EA%B2%83

[nestJS] 경로파라미터 일반경로 충돌 /seller/search /seller/:sellerID

esoesmio — Fri, 24 May 2024 15:16:12 +0900

  @ApiOperation({
    summary: "셀러 상세 조회",
    description: ""
  })
  @Get(":sellerId")
  async detail(@User() user, @Param() param: SellerIdParam) {
    const isExist = await this.sellersService.isExist(param.sellerId);
    if (!isExist) {
      throw new NotFoundException({
        status: HttpStatus.NOT_FOUND,

이것이 위에있고

  @ApiOperation({
    summary: "특정 셀러 조회",
    description: "핸드폰 번호 또는 닉네임을 기반으로 특정 셀러 정보를 조회합니다."
  })
  @Get("search")
  async findOne(
    @Query("information") information: string
  ) {
    console.log("wecametoinformation");
    console.log("information", information);

이것이 아래있었을때

sellerID를 안쳤다고 에러가 남. 왜그럴까?

/////////////////////////////////////////////////////////////////

NestJS에서 메소드의 순서가 영향을 미치는 이유는 특히 라우팅과 관련하여 발생할 수 있습니다. NestJS는 데코레이터를 사용하여 라우트를 등록하고, 이 라우트 등록은 컨트롤러 파일을 파싱하는 순서대로 이루어집니다. 따라서 메소드의 순서가 라우트 처리 순서에 영향을 줄 수 있습니다.

### 경로 파라미터와 일반 경로의 충돌
예를 들어, 다음과 같은 두 경로가 있을 때:

1. `@Get(":sellerId")` – 동적 경로 파라미터를 포함하는 경로
2. `@Get("search")` – 고정 경로

만약 `@Get(":sellerId")`가 `@Get("search")`보다 먼저 정의되어 있다면, `search`라는 문자열도 `:sellerId`의 파라미터로 해석될 수 있습니다. 이는 `search`가 동적 경로 파라미터 `:sellerId`에 해당할 수 있는 유효한 문자열로 인식되기 때문입니다. 따라서 `/sellers/search` 경로를 호출하면 `:sellerId`가 `search`로 설정된 `detail` 메소드가 호출될 수 있습니다.

### 문제 해결
메소드의 순서를 변경하여 고정 경로를 먼저 처리하도록 하면, NestJS는 먼저 고정 경로를 확인하고 일치하는 경로가 없을 때만 동적 경로를 확인합니다. 따라서, 다음과 같은 순서로 메소드를 정의하면:

1. `@Get("search")` – 고정 경로
2. `@Get(":sellerId")` – 동적 경로 파라미터

`/sellers/search` 요청이 들어올 때 `search`라는 문자열을 `sellerId` 파라미터로 해석하는 것이 아니라, `search` 경로를 처리하는 `findOne` 메소드를 정상적으로 호출하게 됩니다.

### 권장 사항
라우팅 관련 이슈를 방지하기 위해, 가능하면 다음과 같은 규칙을 따르는 것이 좋습니다:

- 고정 경로는 동적 경로보다 먼저 정의합니다.
- 동적 경로 파라미터를 포함하는 경로는 가장 마지막에 위치시키는 것이 안전합니다.
- 라우트의 구조와 순서를 명확히 문서화하여 유지보수 시 혼란을 방지합니다.

이러한 접근 방식은 경로 해석 과정에서의 예기치 않은 충돌과 버그를 방지하는 데 도움이 됩니다.

Swagger 사용법

esoesmio — Tue, 21 May 2024 12:47:54 +0900

https://cdragon.tistory.com/entry/NestJS-NestJS%EC%97%90%EC%84%9C-Swagger-%EC%82%AC%EC%9A%A9%EB%B2%95-feat-API-Documentation

[nestJS] 실행 오류 해결

esoesmio — Mon, 20 May 2024 22:50:20 +0900

NestJS 프로젝트에서 `npm install` 실행 중 발생한 오류는 `@nestjs/typeorm` 모듈과 `typeorm` 모듈 간의 의존성 충돌 때문입니다. 오류 메시지에 따르면, `@nestjs/typeorm@8.1.4`는 `typeorm`의 `^0.3.0` 버전을 요구하지만, 현재 프로젝트에 설치된 `typeorm`의 버전은 `0.2.45`입니다. 이는 `@nestjs/typeorm`의 필요 조건을 충족시키지 못하기 때문에 발생하는 문제입니다.

### 해결 방법

1. **의존성 버전 명시적 업데이트**
   - 프로젝트에서 사용 중인 `typeorm`의 버전을 `^0.3.0` 이상으로 업데이트해야 합니다. 이는 `@nestjs/typeorm@8.1.4`가 요구하는 최소 버전과 호환됩니다.
   - 다음 명령을 사용하여 `typeorm`을 업데이트할 수 있습니다:
     ```bash

     npm install typeorm@^0.3.0

```
   - 이렇게 하면 최신 버전의 `typeorm`이 설치되며, `@nestjs/typeorm`과의 의존성 충돌이 해결됩니다.

2. **`--force` 옵션 사용**
   - `npm install --force` 명령을 사용하여 강제로 의존성을 설치할 수 있습니다. 이 방법은 충돌을 간단히 무시하고 설치를 강제로 진행하지만, 호환성 문제로 인해 실행 시 예상치 못한 오류가 발생할 수 있습니다.
   - 사용 방법:
     ```bash

     npm install --force

```

3. **`--legacy-peer-deps` 옵션 사용**
   - NPM 7 이상에서는 기본적으로 피어 의존성 충돌을 엄격하게 처리합니다. `--legacy-peer-deps` 옵션을 사용하면 이전 버전의 NPM처럼 피어 의존성 충돌을 덜 엄격하게 처리할 수 있습니다.
   - 사용 방법:
     ```bash

     npm install --legacy-peer-deps

```

### 추천 방법

의존성 문제를 근본적으로 해결하기 위해서는 프로젝트의 `typeorm` 버전을 업데이트하는 것이 가장 권장되는 방법입니다. 이렇게 하면 나중에 다른 의존성 문제를 방지하고, 최신 기능과 버그 수정 혜택을 받을 수 있습니다. `--force`나 `--legacy-peer-deps`는 일시적인 해결책으로, 잠재적인 호환성 문제가 있을 수 있으므로 주의해서 사용해야 합니다.

깃 오류.

git rm -r --cached node_modules
git commit -m "Remove node_modules from tracking"

`.gitignore` 파일이 있음에도 불구하고 `node_modules` 디렉터리 내의 파일들이 git 커밋에 포함되는 문제는 일반적으로 몇 가지 가능한 원인으로 발생할 수 있습니다. 여기서 몇 가지 가능성과 그에 따른 해결 방법을 살펴보겠습니다.

### 1. `.gitignore` 파일의 위치
`.gitignore` 파일이 프로젝트의 루트 디렉터리에 위치해 있는지 확인하세요. `.gitignore` 파일은 그것이 위치한 디렉터리와 그 하위 디렉터리에만 영향을 미칩니다. 따라서, 이 파일이 프로젝트의 루트가 아닌 다른 곳에 위치해 있다면 `node_modules` 폴더를 올바르게 무시하지 못할 수 있습니다.

### 2. 이미 추적 중인 파일
`.gitignore` 파일은 아직 추적(tracked)되지 않은 파일에만 영향을 미칩니다. 만약 `node_modules` 폴더의 파일들이 이미 git에 의해 추적되고 있다면, `.gitignore`에 해당 경로를 추가해도 이미 추적 중인 파일들은 계속 추적됩니다.

#### 해결 방법:
- `node_modules` 폴더를 git 추적에서 제거합니다. 이 작업은 폴더를 실제로 삭제하지는 않지만, git 추적 목록에서는 제거됩니다.
```bash

  git rm -r --cached node_modules
  git commit -m "Remove node_modules from tracking"

```

### 3. `.gitignore` 파일의 규칙 확인
`.gitignore` 파일 내의 규칙을 정확히 작성했는지 다시 한번 확인하세요. 예를 들어, `/node_modules`는 프로젝트 루트 디렉터리 바로 아래의 `node_modules` 폴더만을 지칭합니다. 만약 프로젝트 구조가 다르거나 `node_modules` 폴더가 다른 위치에 있을 경우, 이 경로가 정확히 매치되지 않을 수 있습니다.

### 4. 기타 `.gitignore` 충돌
다른 `.gitignore` 파일(예: 전역 `.gitignore` 파일)이 있어서 설정이 충돌하는 경우도 있습니다. 프로젝트 또는 사용자의 홈 디렉터리에 다른 `.gitignore` 설정이 있는지 확인해 보세요.

### 5. Git 캐시 확인
위의 단계를 완료한 후에도 문제가 해결되지 않는다면, git 캐시를 리셋해 보는 것이 좋습니다. 때로는 이전의 git 인덱스가 영향을 줄 수 있기 때문입니다.
```bash

git rm -r --cached .
git add .
git commit -m "Fixed untracked files"

```

위의 명령은 모든 파일을 캐시에서 제거한 다음 다시 추가하고, `.gitignore`의 규칙에 따라 제외할 파일을 제외한 상태로 커밋합니다. 이 방법으로 `node_modules`가 정상적으로 무시되는지 확인할 수 있습니다.

[nestJS] pm2를 쓰는 이유

esoesmio — Mon, 20 May 2024 22:49:11 +0900

pm2 공식 사이트의 한줄 소개를 보면 ,

"Advanced, production process manager for node.js" 라고 소개되어있다.

node.js를 위한 발전된 상품 프로세스 매니져 !

*process : 컴퓨터에 저장된 프로그램이 실행돼서 메모리에 올라간 상태. 즉 동작중인 프로그램을 말함.

즉 pm2란 node.js로 만들어진 프로그램을 잘 관리해주는 아이라는 것.

pm2는 여러가지 기능이 있는데, 예를들어

1. 프로그램이 꺼지면 자동으로 다시 켜줄 수 있다.

pm2로 start한 경우 , pm2로 끄 지 않으면

프로세스가 예기치 못하게 꺼졌을때, pm2로 시작한 경우 그냥 재시작 된다.

# pm2 start app.js

위 명령을 해주면 app.js 라는 프로그램을 프로세스로 만든것이고 , 이 프로세스는 백그라운드로 돌아가게 된다. 그래서 바로 다른 명령을 수행할 수 있는 상태인채로 실행되는것 !

2. 코드가 바뀌었을 때 , 자동으로 프로세스를 컸다 켜준다 (즉, 리소스 수정시 자동 반영)

# pm2 start app.js --watch

만약 내가 개발을 하다가 파일의 코드를 수정했다고 치자.

이때 파일이 수정됐다고 해서 메모리 상에서 동작되고있는 프로세스에 반영되는 것은 아니다.

즉 , 내가 코드를 수정해서 저장버튼을 누른다고 해서, 실행중인 앱에 변화가 생기지는 않는다는 것.

그런데 pm2를 쓰면 코드를 수정했을 때 자동으로 프로세스를 껐다가 켜준다.(--watch 지켜보고있다가 변화가 생기면 껐다 켜준다 !)

3. 로그를 한번에 볼수있는 화면 지원

# pm2 log

- 현재 실행중인 프로세스들의 로그들을 하나의 화면에서 모아서 보여줌. 콘솔이랑 리로드됐을때 표시 등등

4. 짱편한 개발자 모드

# pm2-dev app.js

=> watch + log 기능 이라고 생각하면 됨

5. pm2 클러스트 기능

# pm2 start app.js -i max

프로세스를 실행시킬 때 가능한 스레드의 숫자만큼 실행시키라는 뜻.

node.js 는 싱글 스레드라서 하나의 스레드만 사용함. 하지만 그 컴퓨터의 가능한 스레드가 더 많은데 하나만 쓰는것보다,

여러대의 스레드에 프로세스를 돌리면 더 많은 사용자의 접속을 받을 수 있음 .

16개의 스레드를 지원하는 컴퓨터 환경인데 1개의 스레드만 쓴다면 아까우니까 , 16개의 프로세스를 돌리는거임 ! (싱글 스레드 x 16개)

이렇게!!!

6. 컴퓨터가 꺼졌다가 켜졌을 때 , 프로세스를 자동으로 실행시켜주는 기능

# pm2 start app.js

# pm2 save

- 해당 경로에 현재 실행되고 있는 프로세스들에 대한 상태가 저장됨.

# pm2 startup

- 각각의 운영체제별로, 그 운영체제가 실행됐을 때 프로세스들을 실행시켜주는 명령어가 있는데 , 그 명령어를 알려줌.

이제 그 명령어를 복사해서 붙여넣고 실행 시키면, 컴퓨터가 꺼졌다가 켜졌을 때

save를 통해 저장해놓은 프로세스들의 상태를 복원해서 재실행시켜준다. pm2가 이걸 대신 다~~~~ 해주는 매니져 !

[nestJS] webpack을 쓰는 이유

esoesmio — Mon, 20 May 2024 16:50:14 +0900

Webpack을 사용해야 하는 이유

Webpack을 사용하는 이유를 이해하기 위해 간단한 예시를 통해 설명해보겠습니다.

상황: 웹 애플리케이션을 개발하고 있으며, 여러 개의 JavaScript 파일과 CSS 파일이 프로젝트에 포함되어 있습니다. 각 파일은 모듈화되어 있어서 코드를 구성하고 유지 관리하기 용이하지만, 이들을 브라우저에서 로드하려면 여러 번의 HTTP 요청이 필요하고, 파일 크기가 큰 경우 로딩 시간이 길어질 수 있습니다.

이제 Webpack을 사용하는 이유를 예시로 설명해보겠습니다.

사용 전:

<!DOCTYPE html>
<html>
<head>
    <title>웹 애플리케이션</title>
    <link rel="stylesheet" href="style1.css">
    <link rel="stylesheet" href="style2.css">
</head>
<body>
    <script src="module1.js"></script>
    <script src="module2.js"></script>
    <script src="module3.js"></script>
</body>
</html>

위 예시에서는 각 모듈과 스타일 시트를 별도의 파일로 로드하고 있으며, 각각의 파일은 별도의 HTTP 요청을 생성합니다.

사용 후(Webpack 적용): Webpack을 사용하면 이러한 파일들을 번들로 묶을 수 있습니다. 예를 들어, app.js와 app.css로 번들링한 경우:

<!DOCTYPE html>
<html>
<head>
    <title>웹 애플리케이션</title>
    <link rel="stylesheet" href="app.css">
</head>
<body>
    <script src="app.js"></script>
</body>
</html>

Webpack을 사용한 경우, 모든 JavaScript 모듈과 스타일 시트가 하나의 번들로 묶여 하나의 HTTP 요청으로 처리됩니다. 이로써 다음과 같은 이점이 있습니다:

로딩 속도 향상: 하나의 번들 파일을 로드하기 때문에 초기 로딩 속도가 향상됩니다.
모듈 관리 용이성: 모듈화된 코드를 사용하여 개발 및 유지 관리가 쉽습니다.
최적화 기회: Webpack은 코드 최적화 및 압축을 수행할 수 있으며, 불필요한 코드를 제거하고 성능을 향상시킬 수 있습니다.

이것은 Webpack의 간단한 예시이며, 실제 프로젝트에서는 더 복잡한 모듈 시스템 및 플러그인을 사용하여 더 많은 기능을 활용할 수 있습니다. Webpack은 모던 웹 개발에서 코드 관리와 최적화에 큰 도움을 주는 핵심 도구 중 하나입니다.

Webpack을 사용하는 실제 사례

Webpack은 많은 웹 개발 프로젝트에서 사용되며, 다양한 실제 사례가 있습니다. 이 중에서도 가장 대표적인 몇 가지 실제 사례를 살펴보겠습니다:

React 프로젝트: React는 단일 페이지 애플리케이션(SPA)을 개발하기 위한 인기 있는 라이브러리 중 하나입니다. React 프로젝트에서는 Webpack을 주로 사용하여 모듈 번들링 및 개발 서버 설정을 관리합니다. React 앱은 컴포넌트 기반으로 구성되며, 각 컴포넌트는 자체적인 JavaScript 및 CSS 파일을 가지고 있습니다. Webpack은 이러한 컴포넌트 및 리소스 파일을 번들로 묶어 최적화된 번들을 생성합니다.
Vue.js 프로젝트: Vue.js 역시 React와 마찬가지로 모듈 번들링에 Webpack을 사용하는 프레임워크입니다. Vue.js는 컴포넌트 기반의 웹 애플리케이션을 개발할 때 사용되며, Vue 파일 내에 HTML, JavaScript, CSS 코드를 포함하는데, Webpack은 이러한 Vue 파일을 처리하고 번들로 묶어줍니다.
Angular 프로젝트: Angular는 Google에서 개발한 웹 애플리케이션 프레임워크로, Webpack을 사용하여 애플리케이션의 모듈과 의존성을 효과적으로 관리합니다. Angular 애플리케이션은 TypeScript로 작성되며, Webpack은 TypeScript 코드를 컴파일하고 번들로 묶어 최적화된 결과물을 생성합니다.
웹 애플리케이션 번들링: 이전에 언급한 프레임워크 외에도 많은 웹 애플리케이션에서 Webpack을 사용합니다. 예를 들어, 웹 애플리케이션의 스크립트 파일, 스타일 시트, 이미지, 폰트 등을 효과적으로 번들로 묶어 최적화된 형태로 서비스하는 데 사용됩니다.
라이브러리 개발: 라이브러리 및 패키지 개발자들도 Webpack을 사용하여 라이브러리를 번들로 묶고 제공합니다. 번들된 라이브러리를 사용하는 개발자들은 쉽게 가져와서 자신의 프로젝트에 통합할 수 있습니다.
코드 스플리팅: 대규모 웹 애플리케이션에서 코드 스플리팅을 사용하여 초기 로딩 시간을 최소화하고 필요한 코드만 로드하는 경우에도 Webpack이 사용됩니다. 이것은 라우팅 기반의 웹 애플리케이션에서 특히 유용합니다.

이러한 실제 사례들은 Webpack이 얼마나 다양한 웹 프로젝트에서 사용되고 있다는 것을 보여줍니다. Webpack을 사용하면 모듈화된 코드를 효과적으로 관리하고 최적화하여 웹 애플리케이션의 성능을 향상시킬 수 있습니다.

Webpack 직접 사용하는 법

Webpack을 사용하여 웹 애플리케이션을 번들링하고 최적화하는 기본적인 단계를 소개합니다. Webpack의 사용법은 다양하고 프로젝트에 따라 다를 수 있지만, 아래는 가장 기본적인 예제와 사용법입니다.

1. Node.js 설치: Webpack을 사용하려면 Node.js가 설치되어 있어야 합니다. Node.js를 설치하지 않았다면 공식 웹사이트에서 다운로드하고 설치하세요.

2. 프로젝트 디렉토리 생성: 웹 애플리케이션 프로젝트 디렉토리를 생성하고 해당 디렉토리로 이동합니다.

3. 프로젝트 초기화: 프로젝트 디렉토리에서 다음 명령을 실행하여 프로젝트를 초기화합니다.

npm init -y

이 명령은 package.json 파일을 생성합니다.

4. Webpack 및 관련 모듈 설치: 다음 명령을 사용하여 Webpack과 필요한 모듈을 설치합니다.

npm install webpack webpack-cli --save-dev

5. 웹팩 설정 파일 생성: 프로젝트 루트 디렉토리에 webpack.config.js라는 웹팩 설정 파일을 생성합니다. 이 파일은 웹팩 번들링의 설정을 정의합니다.

예를 들어, 간단한 설정 파일은 다음과 같이 생길 수 있습니다:

const path = require('path');

module.exports = {
  entry: './src/index.js', // 애플리케이션 진입점 파일
  output: {
    filename: 'bundle.js', // 번들된 결과물 파일 이름
    path: path.resolve(__dirname, 'dist'), // 번들된 파일의 출력 경로
  },
};

6. 번들링 스크립트 작성: 프로젝트 디렉토리에 애플리케이션 코드 파일(index.js)을 생성하고, 이 파일에 자바스크립트 코드를 작성합니다.

7. 번들링 실행: 다음 명령을 사용하여 웹팩을 실행하고 번들링합니다.

npx webpack

8. HTML 파일 생성: 프로젝트 디렉토리에 HTML 파일을 생성하고, 번들된 스크립트를 로드하도록 설정합니다.

<!DOCTYPE html>
<html>
<head>
  <title>Webpack 예제</title>
</head>
<body>
  <script src="dist/bundle.js"></script>
</body>
</html>

9. 애플리케이션 실행: 생성한 HTML 파일을 브라우저에서 열어 애플리케이션을 실행합니다.

이것은 가장 기본적인 Webpack 사용법 예제입니다. 물론 복잡한 프로젝트에서는 추가 설정 및 모듈 로더, 플러그인 등을 사용하여 세부적으로 구성할 수 있습니다. 또한, 개발 환경과 프로덕션 환경 간의 설정을 분리하고 최적화 설정을 추가할 수도 있습니다. Webpack의 공식 문서와 강좌를 참조하여 더 자세한 사용법을 학습하실 수 있습니다.

Wbpack의 정의

Webpack은 자바스크립트 애플리케이션을 위한 모듈 번들러(Module Bundler)입니다. 모듈 번들러는 다수의 모듈로 나뉜 자바스크립트 파일 및 다른 종속성 파일들을 하나로 묶어서 웹 애플리케이션을 최적화하고 관리하는 도구입니다. Webpack은 웹 개발에서 자주 사용되며, 다음과 같은 주요 기능을 제공합니다:

모듈 번들링: Webpack은 여러 개의 자바스크립트 파일 및 다른 리소스 파일을 하나의 번들로 묶어줍니다. 이를 통해 여러 파일을 하나의 HTTP 요청으로 처리할 수 있어 웹 페이지의 로딩 속도를 향상시킵니다.
로더(Loader): Webpack은 다양한 로더를 사용하여 이미지, 스타일 시트, JSON 파일 등 다양한 유형의 파일을 처리할 수 있습니다. 로더를 통해 파일을 변환하거나 최적화할 수 있습니다.
플러그인(Plugin): Webpack은 다양한 플러그인을 제공하며, 이를 사용하여 코드 최적화, 환경 변수 주입, 번들 분석, 코드 스플리팅 등 다양한 작업을 수행할 수 있습니다.
번들 최적화: Webpack은 코드 스플리팅(Code Splitting)을 지원하여 애플리케이션의 번들을 여러 청크로 나눌 수 있습니다. 이를 통해 초기 로딩 시간을 줄이고 필요한 코드만 로드할 수 있습니다.
HMR(Hot Module Replacement): Webpack은 개발 서버와 함께 사용할 때 HMR을 지원하여 코드 수정 시 브라우저를 새로 고치지 않고도 모듈을 업데이트할 수 있습니다. 이로써 개발자는 실시간으로 코드 변경을 확인할 수 있습니다.
다양한 환경 지원: Webpack은 브라우저 환경 뿐만 아니라 Node.js 환경에서도 사용할 수 있으며, 서버 사이드 렌더링 및 다른 환경에서도 유용하게 활용됩니다.

Webpack은 모던 웹 개발에서 필수적인 도구 중 하나로, 모듈화된 코드를 효율적으로 관리하고 최적화하여 웹 애플리케이션의 성능을 향상시키는 데 도움을 줍니다.