프로세스

소스 코드: lib/process.js

process 객체는 현재 Node.js 프로세스에 대한 정보와 제어 기능을 제공합니다.

ESM

import process from 'node:process'

CJS

const process = require('node:process')

프로세스 이벤트

process 객체는 EventEmitter의 인스턴스입니다.

이벤트: 'beforeExit'

추가된 버전: v0.11.12

Node.js가 이벤트 루프를 비우고 더 이상 예약할 작업이 없을 때 'beforeExit' 이벤트가 발생합니다. 일반적으로 Node.js 프로세스는 예약된 작업이 없으면 종료되지만, 'beforeExit' 이벤트에 등록된 리스너는 비동기 호출을 수행하여 Node.js 프로세스가 계속되도록 할 수 있습니다.

리스너 콜백 함수는 process.exitCode 값을 유일한 인수로 전달하여 호출됩니다.

'beforeExit' 이벤트는 process.exit() 호출 또는 포착되지 않은 예외와 같이 명시적 종료를 유발하는 조건에서는 발생하지 않습니다.

추가 작업을 예약하려는 의도가 아니라면 'beforeExit'를 'exit' 이벤트의 대안으로 사용해서는 안 됩니다.

ESM

import process from 'node:process'

process.on('beforeExit', code => {
  console.log('Process beforeExit event with code: ', code)
})

process.on('exit', code => {
  console.log('Process exit event with code: ', code)
})

console.log('This message is displayed first.')

// 출력:
// This message is displayed first.
// Process beforeExit event with code: 0
// Process exit event with code: 0

CJS

const process = require('node:process')

process.on('beforeExit', code => {
  console.log('Process beforeExit event with code: ', code)
})

process.on('exit', code => {
  console.log('Process exit event with code: ', code)
})

console.log('This message is displayed first.')

// 출력:
// This message is displayed first.
// Process beforeExit event with code: 0
// Process exit event with code: 0

이벤트: 'disconnect'

추가된 버전: v0.7.7

Node.js 프로세스가 IPC 채널과 함께 생성된 경우(자식 프로세스 및 클러스터 문서 참조), IPC 채널이 닫힐 때 'disconnect' 이벤트가 발생합니다.

이벤트: 'exit'

추가된 버전: v0.1.7

• code <integer>

'exit' 이벤트는 다음과 같은 이유로 Node.js 프로세스가 종료되려고 할 때 발생합니다.

• process.exit() 메서드가 명시적으로 호출된 경우;
• Node.js 이벤트 루프가 더 이상 수행할 추가 작업이 없는 경우.

이 시점에서 이벤트 루프의 종료를 막을 방법은 없으며, 모든 'exit' 리스너의 실행이 완료되면 Node.js 프로세스가 종료됩니다.

리스너 콜백 함수는 process.exitCode 속성 또는 process.exit() 메서드에 전달된 exitCode 인수에 의해 지정된 종료 코드로 호출됩니다.

ESM

import process from 'node:process'

process.on('exit', code => {
  console.log(`종료 코드: ${code}로 종료하려고 합니다.`)
})

CJS

const process = require('node:process')

process.on('exit', code => {
  console.log(`종료 코드: ${code}로 종료하려고 합니다.`)
})

리스너 함수는 동기식 작업만 수행해야 합니다. Node.js 프로세스는 'exit' 이벤트 리스너를 호출한 직후에 종료되어 이벤트 루프에 여전히 대기 중인 추가 작업을 모두 포기하게 됩니다. 예를 들어 다음 예제에서 타임아웃은 발생하지 않습니다.

ESM

import process from 'node:process'

process.on('exit', code => {
  setTimeout(() => {
    console.log('이것은 실행되지 않습니다.')
  }, 0)
})

CJS

const process = require('node:process')

process.on('exit', code => {
  setTimeout(() => {
    console.log('이것은 실행되지 않습니다.')
  }, 0)
})

Event: 'message'

추가된 버전: v0.5.10

• message <Object> | <boolean> | <number> | <string> | <null> 파싱된 JSON 객체 또는 직렬화 가능한 기본 값입니다.
• sendHandle <net.Server> | <net.Socket> net.Server 또는 net.Socket 객체 또는 undefined입니다.

Node.js 프로세스가 IPC 채널과 함께 스폰된 경우( 자식 프로세스 및 클러스터 문서 참조), 'message' 이벤트는 부모 프로세스가 childprocess.send()를 사용하여 보낸 메시지가 자식 프로세스에 의해 수신될 때마다 발생합니다.

메시지는 직렬화 및 파싱을 거칩니다. 결과 메시지는 원래 전송된 것과 동일하지 않을 수 있습니다.

프로세스를 스폰할 때 serialization 옵션을 advanced로 설정한 경우, message 인수는 JSON이 나타낼 수 없는 데이터를 포함할 수 있습니다. 자세한 내용은 child_process 고급 직렬화를 참조하세요.

Event: 'multipleResolves'

추가된 버전: v10.12.0

더 이상 사용되지 않음: v17.6.0, v16.15.0

[Stable: 0 - 더 이상 사용되지 않음]

Stable: 0 안정성: 0 - 더 이상 사용되지 않음

• type <string> 해결 유형. 'resolve' 또는 'reject' 중 하나입니다.
• promise <Promise> 한 번 이상 resolve 또는 reject된 Promise입니다.
• value <any> 원래 resolve된 후 Promise가 resolve 또는 reject된 값입니다.

'multipleResolves' 이벤트는 Promise가 다음 중 하나일 때마다 발생합니다.

• 한 번 이상 resolve되었습니다.
• 한 번 이상 reject되었습니다.
• resolve 후 reject되었습니다.
• reject 후 resolve되었습니다.

이것은 Promise 생성자를 사용하는 동안 여러 resolve가 조용히 무시되므로 애플리케이션의 잠재적인 오류를 추적하는 데 유용합니다. 그러나 이 이벤트의 발생이 반드시 오류를 나타내는 것은 아닙니다. 예를 들어, Promise.race()는 'multipleResolves' 이벤트를 트리거할 수 있습니다.

위의 Promise.race() 예와 같은 경우에서 이벤트의 신뢰성이 떨어지기 때문에 더 이상 사용되지 않습니다.

ESM

import process from 'node:process'

process.on('multipleResolves', (type, promise, reason) => {
  console.error(type, promise, reason)
  setImmediate(() => process.exit(1))
})

async function main() {
  try {
    return await new Promise((resolve, reject) => {
      resolve('First call')
      resolve('Swallowed resolve')
      reject(new Error('Swallowed reject'))
    })
  } catch {
    throw new Error('Failed')
  }
}

main().then(console.log)
// resolve: Promise { 'First call' } 'Swallowed resolve'
// reject: Promise { 'First call' } Error: Swallowed reject
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// First call

CJS

const process = require('node:process')

process.on('multipleResolves', (type, promise, reason) => {
  console.error(type, promise, reason)
  setImmediate(() => process.exit(1))
})

async function main() {
  try {
    return await new Promise((resolve, reject) => {
      resolve('First call')
      resolve('Swallowed resolve')
      reject(new Error('Swallowed reject'))
    })
  } catch {
    throw new Error('Failed')
  }
}

main().then(console.log)
// resolve: Promise { 'First call' } 'Swallowed resolve'
// reject: Promise { 'First call' } Error: Swallowed reject
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// First call

Event: 'rejectionHandled'

추가된 버전: v1.4.1

• promise <Promise> 늦게 처리된 프로미스입니다.

'rejectionHandled' 이벤트는 Promise가 거부되었고 Node.js 이벤트 루프의 한 턴 이후에 (예를 들어 promise.catch()를 사용하여) 오류 핸들러가 연결될 때마다 발생합니다.

Promise 객체는 이전에 'unhandledRejection' 이벤트에서 방출되었을 것이지만 처리 과정에서 거부 핸들러를 얻었습니다.

거부가 항상 처리될 수 있는 Promise 체인의 최상위 레벨이라는 개념은 없습니다. 본질적으로 비동기적인 특성으로 인해 Promise 거부는 'unhandledRejection' 이벤트가 방출되는 이벤트 루프 턴보다 훨씬 늦은 미래 시점에서 처리될 수 있습니다.

이를 다르게 표현하면, 처리되지 않은 예외 목록이 계속 증가하는 동기 코드와 달리 프로미스를 사용하면 처리되지 않은 거부 목록이 증가했다가 줄어들 수 있습니다.

동기 코드에서 처리되지 않은 예외 목록이 증가하면 'uncaughtException' 이벤트가 발생합니다.

비동기 코드에서 처리되지 않은 거부 목록이 증가하면 'unhandledRejection' 이벤트가 발생하고 처리되지 않은 거부 목록이 줄어들면 'rejectionHandled' 이벤트가 발생합니다.

ESM

import process from 'node:process'

const unhandledRejections = new Map()
process.on('unhandledRejection', (reason, promise) => {
  unhandledRejections.set(promise, reason)
})
process.on('rejectionHandled', promise => {
  unhandledRejections.delete(promise)
})

CJS

const process = require('node:process')

const unhandledRejections = new Map()
process.on('unhandledRejection', (reason, promise) => {
  unhandledRejections.set(promise, reason)
})
process.on('rejectionHandled', promise => {
  unhandledRejections.delete(promise)
})

이 예제에서 unhandledRejections Map은 시간이 지남에 따라 증가했다가 줄어들면서 처리되지 않은 상태로 시작했다가 처리되는 거부를 반영합니다. 이러한 오류는 오류 로그에 주기적으로 기록하거나 (장시간 실행되는 애플리케이션에 가장 적합할 가능성이 높음) 프로세스 종료 시 (스크립트에 가장 편리할 가능성이 높음) 기록할 수 있습니다.

Event: 'workerMessage'

추가된 버전: v22.5.0

• value <any> postMessageToThread()를 사용하여 전송된 값입니다.
• source <number> 전송하는 워커 스레드 ID 또는 메인 스레드의 경우 0입니다.

'workerMessage' 이벤트는 postMessageToThread()를 사용하여 다른 파티에서 보낸 모든 수신 메시지에 대해 발생합니다.

Event: 'uncaughtException'

[기록]

버전	변경 사항
v12.0.0, v10.17.0	origin 인수가 추가되었습니다.
v0.1.18	추가된 버전: v0.1.18

• err <Error> 잡히지 않은 예외입니다.
• origin <string> 예외가 처리되지 않은 거부 또는 동기 오류에서 발생하는지 여부를 나타냅니다. 'uncaughtException' 또는 'unhandledRejection'일 수 있습니다. 후자는 Promise 기반 비동기 컨텍스트에서 예외가 발생하거나 Promise가 거부되고 --unhandled-rejections 플래그가 strict 또는 throw(기본값)로 설정되어 있으며 거부가 처리되지 않거나, 명령줄 진입점의 ES 모듈 정적 로딩 단계에서 거부가 발생하는 경우에 사용됩니다.

'uncaughtException' 이벤트는 잡히지 않은 JavaScript 예외가 이벤트 루프로 다시 버블링될 때 발생합니다. 기본적으로 Node.js는 이러한 예외를 stderr에 스택 추적을 출력하고 코드 1로 종료하여 이전에 설정된 process.exitCode를 덮어씀으로써 처리합니다. 'uncaughtException' 이벤트에 대한 핸들러를 추가하면 이 기본 동작이 재정의됩니다. 또는 'uncaughtException' 핸들러에서 process.exitCode를 변경하면 제공된 종료 코드로 프로세스가 종료됩니다. 그렇지 않으면 이러한 핸들러가 있는 경우 프로세스는 0으로 종료됩니다.

ESM

import process from 'node:process'
import fs from 'node:fs'

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(process.stderr.fd, `Caught exception: ${err}\n` + `Exception origin: ${origin}\n`)
})

setTimeout(() => {
  console.log('This will still run.')
}, 500)

// 의도적으로 예외를 발생시키지만 잡지 않습니다.
nonexistentFunc()
console.log('This will not run.')

CJS

const process = require('node:process')
const fs = require('node:fs')

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(process.stderr.fd, `Caught exception: ${err}\n` + `Exception origin: ${origin}\n`)
})

setTimeout(() => {
  console.log('This will still run.')
}, 500)

// 의도적으로 예외를 발생시키지만 잡지 않습니다.
nonexistentFunc()
console.log('This will not run.')

'uncaughtExceptionMonitor' 리스너를 설치하여 프로세스를 종료하는 기본 동작을 재정의하지 않고도 'uncaughtException' 이벤트를 모니터링할 수 있습니다.

경고: 'uncaughtException'을 올바르게 사용하기

'uncaughtException'은 최후의 수단으로만 사용해야 하는 예외 처리의 임시적인 메커니즘입니다. 이 이벤트는 On Error Resume Next와 동일한 용도로 사용해서는 안 됩니다. 처리되지 않은 예외는 본질적으로 애플리케이션이 정의되지 않은 상태에 있음을 의미합니다. 예외로부터 적절히 복구하지 않고 애플리케이션 코드를 다시 시작하려고 하면 추가적인 예측 불가능한 문제가 발생할 수 있습니다.

이벤트 핸들러 내에서 발생한 예외는 포착되지 않습니다. 대신 프로세스가 0이 아닌 종료 코드로 종료되고 스택 추적이 출력됩니다. 이는 무한 재귀를 방지하기 위한 것입니다.

처리되지 않은 예외 후 정상적으로 재개하려고 하는 것은 컴퓨터를 업그레이드할 때 전원 코드를 뽑는 것과 비슷할 수 있습니다. 열 번 중 아홉 번은 아무 일도 일어나지 않습니다. 하지만 열 번째에는 시스템이 손상됩니다.

'uncaughtException'의 올바른 사용법은 프로세스를 종료하기 전에 할당된 리소스(예: 파일 디스크립터, 핸들 등)의 동기식 정리 작업을 수행하는 것입니다. 'uncaughtException' 후에 정상 작동을 재개하는 것은 안전하지 않습니다.

'uncaughtException'이 발생하든 그렇지 않든 크래시된 애플리케이션을 보다 안정적인 방식으로 재시작하려면 애플리케이션 실패를 감지하고 필요에 따라 복구하거나 재시작하기 위해 별도의 프로세스에서 외부 모니터를 사용해야 합니다.

이벤트: 'uncaughtExceptionMonitor'

추가 버전: v13.7.0, v12.17.0

• err <Error> 처리되지 않은 예외입니다.
• origin <string> 예외가 처리되지 않은 거부에서 발생했는지 아니면 동기 오류에서 발생했는지 나타냅니다. 'uncaughtException' 또는 'unhandledRejection'일 수 있습니다. 후자는 Promise 기반 비동기 컨텍스트에서 예외가 발생하거나 Promise가 거부된 경우 및 --unhandled-rejections 플래그가 strict 또는 throw(기본값)로 설정되고 거부가 처리되지 않거나, 명령줄 진입점의 ES 모듈 정적 로드 단계에서 거부가 발생한 경우에 사용됩니다.

'uncaughtExceptionMonitor' 이벤트는 'uncaughtException' 이벤트가 발생하기 전이나 process.setUncaughtExceptionCaptureCallback()을 통해 설치된 후크가 호출되기 전에 발생합니다.

'uncaughtExceptionMonitor' 리스너를 설치해도 'uncaughtException' 이벤트가 발생하면 동작이 변경되지 않습니다. 'uncaughtException' 리스너가 설치되어 있지 않으면 프로세스가 계속 크래시됩니다.

ESM

import process from 'node:process'

process.on('uncaughtExceptionMonitor', (err, origin) => {
  MyMonitoringTool.logSync(err, origin)
})

// 의도적으로 예외를 발생시키지만 포착하지는 않습니다.
nonexistentFunc()
// 여전히 Node.js가 크래시됩니다.

CJS

const process = require('node:process')

process.on('uncaughtExceptionMonitor', (err, origin) => {
  MyMonitoringTool.logSync(err, origin)
})

// 의도적으로 예외를 발생시키지만 포착하지는 않습니다.
nonexistentFunc()
// 여전히 Node.js가 크래시됩니다.

Event: 'unhandledRejection'

[기록]

버전	변경 사항
v7.0.0	Promise 거부 처리를 안 하는 것은 더 이상 사용되지 않습니다.
v6.6.0	처리되지 않은 Promise 거부는 이제 프로세스 경고를 발생시킵니다.
v1.4.1	추가됨: v1.4.1

• reason <Error> | <any> 약속이 거부된 객체입니다 (일반적으로 Error 객체).
• promise <Promise> 거부된 약속입니다.

'unhandledRejection' 이벤트는 Promise가 거부되고 이벤트 루프의 한 턴 내에 약속에 오류 처리기가 연결되지 않을 때마다 발생합니다. 약속으로 프로그래밍할 때 예외는 "거부된 약속"으로 캡슐화됩니다. 거부는 promise.catch()를 사용하여 포착하고 처리할 수 있으며 Promise 체인을 통해 전파됩니다. 'unhandledRejection' 이벤트는 아직 처리되지 않은 거부로 거부된 약속을 감지하고 추적하는 데 유용합니다.

ESM

import process from 'node:process'

process.on('unhandledRejection', (reason, promise) => {
  console.log('처리되지 않은 거부:', promise, '이유:', reason)
  // 여기에 애플리케이션별 로깅, 오류 발생 또는 기타 로직
})

somePromise.then(res => {
  return reportToUser(JSON.pasre(res)) // 오타 (`pasre`) 주의
}) // `.catch()` 또는 `.then()` 없음

CJS

const process = require('node:process')

process.on('unhandledRejection', (reason, promise) => {
  console.log('처리되지 않은 거부:', promise, '이유:', reason)
  // 여기에 애플리케이션별 로깅, 오류 발생 또는 기타 로직
})

somePromise.then(res => {
  return reportToUser(JSON.pasre(res)) // 오타 (`pasre`) 주의
}) // `.catch()` 또는 `.then()` 없음

다음은 'unhandledRejection' 이벤트가 발생하도록 트리거합니다.

ESM

import process from 'node:process'

function SomeResource() {
  // 처음에는 로드된 상태를 거부된 약속으로 설정합니다.
  this.loaded = Promise.reject(new Error('리소스가 아직 로드되지 않았습니다!'))
}

const resource = new SomeResource()
// 적어도 한 턴 동안 resource.loaded에 .catch 또는 .then이 없음

CJS

const process = require('node:process')

function SomeResource() {
  // 처음에는 로드된 상태를 거부된 약속으로 설정합니다.
  this.loaded = Promise.reject(new Error('리소스가 아직 로드되지 않았습니다!'))
}

const resource = new SomeResource()
// 적어도 한 턴 동안 resource.loaded에 .catch 또는 .then이 없음

이 예시의 경우 다른 'unhandledRejection' 이벤트의 일반적인 경우와 마찬가지로 개발자 오류로 거부를 추적할 수 있습니다. 이러한 실패를 해결하려면 작동하지 않는 .catch(() => { }) 처리기를 resource.loaded에 연결하여 'unhandledRejection' 이벤트가 발생하는 것을 막을 수 있습니다.

이벤트: 'warning'

추가된 버전: v6.0.0

• warning <Error> 경고의 주요 속성은 다음과 같습니다.
  • name <string> 경고의 이름입니다. 기본값: 'Warning'.
  • message <string> 시스템에서 제공하는 경고 설명입니다.
  • stack <string> 경고가 발생한 코드 위치에 대한 스택 추적입니다.

'warning' 이벤트는 Node.js가 프로세스 경고를 발생시킬 때마다 발생합니다.

프로세스 경고는 사용자에게 주의를 기울이도록 하는 예외적인 조건을 설명한다는 점에서 오류와 유사합니다. 그러나 경고는 일반적인 Node.js 및 JavaScript 오류 처리 흐름의 일부가 아닙니다. Node.js는 최적의 애플리케이션 성능, 버그 또는 보안 취약성을 초래할 수 있는 잘못된 코딩 방식을 감지할 때마다 경고를 발생시킬 수 있습니다.

ESM

import process from 'node:process'

process.on('warning', warning => {
  console.warn(warning.name) // 경고 이름 출력
  console.warn(warning.message) // 경고 메시지 출력
  console.warn(warning.stack) // 스택 추적 출력
})

CJS

const process = require('node:process')

process.on('warning', warning => {
  console.warn(warning.name) // 경고 이름 출력
  console.warn(warning.message) // 경고 메시지 출력
  console.warn(warning.stack) // 스택 추적 출력
})

기본적으로 Node.js는 프로세스 경고를 stderr에 출력합니다. --no-warnings 명령줄 옵션을 사용하여 기본 콘솔 출력을 억제할 수 있지만 'warning' 이벤트는 여전히 process 객체에 의해 발생합니다. 현재는 더 이상 사용되지 않는 경고 외에는 특정 경고 유형을 억제할 수 없습니다. 더 이상 사용되지 않는 경고를 억제하려면 --no-deprecation 플래그를 확인하십시오.

다음 예제는 이벤트에 너무 많은 리스너가 추가되었을 때 stderr에 출력되는 경고를 보여줍니다.

$ node
> events.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> (node:38638) MaxListenersExceededWarning: Possible EventEmitter memory leak
detected. 2 foo listeners added. Use emitter.setMaxListeners() to increase limit

반대로 다음 예제는 기본 경고 출력을 끄고 'warning' 이벤트에 사용자 정의 핸들러를 추가합니다.

$ node --no-warnings
> const p = process.on('warning', (warning) => console.warn('Do not do that!'));
> events.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> Do not do that!

--trace-warnings 명령줄 옵션을 사용하여 경고에 대한 기본 콘솔 출력에 경고의 전체 스택 추적을 포함할 수 있습니다.

--throw-deprecation 명령줄 플래그를 사용하여 Node.js를 시작하면 사용자 정의 더 이상 사용되지 않는 경고가 예외로 throw됩니다.

--trace-deprecation 명령줄 플래그를 사용하면 사용자 정의 더 이상 사용되지 않음이 스택 추적과 함께 stderr에 출력됩니다.

--no-deprecation 명령줄 플래그를 사용하면 사용자 정의 더 이상 사용되지 않음에 대한 모든 보고가 억제됩니다.

*-deprecation 명령줄 플래그는 이름이 'DeprecationWarning'인 경고에만 영향을 줍니다.

사용자 정의 경고 발생

사용자 정의 또는 애플리케이션 특정 경고를 발행하려면 process.emitWarning() 메서드를 참조하세요.

Node.js 경고 이름

Node.js에서 발행하는 경고 유형(name 속성으로 식별됨)에 대한 엄격한 지침은 없습니다. 새로운 유형의 경고는 언제든지 추가될 수 있습니다. 가장 일반적인 경고 유형은 다음과 같습니다.

• 'DeprecationWarning' - 더 이상 사용되지 않는 Node.js API 또는 기능의 사용을 나타냅니다. 이러한 경고에는 사용 중단 코드를 식별하는 'code' 속성이 포함되어야 합니다.
• 'ExperimentalWarning' - 실험적인 Node.js API 또는 기능의 사용을 나타냅니다. 이러한 기능은 언제든지 변경될 수 있으며 지원되는 기능과 동일한 엄격한 시맨틱 버전 관리 및 장기 지원 정책이 적용되지 않으므로 주의해서 사용해야 합니다.
• 'MaxListenersExceededWarning' - EventEmitter 또는 EventTarget에 지정된 이벤트에 대해 너무 많은 리스너가 등록되었음을 나타냅니다. 이는 종종 메모리 누수의 표시입니다.
• 'TimeoutOverflowWarning' - 32비트 부호 있는 정수 내에 맞지 않는 숫자 값이 setTimeout() 또는 setInterval() 함수에 제공되었음을 나타냅니다.
• 'TimeoutNegativeWarning' - 음수가 setTimeout() 또는 setInterval() 함수에 제공되었음을 나타냅니다.
• 'TimeoutNaNWarning' - 숫자가 아닌 값이 setTimeout() 또는 setInterval() 함수에 제공되었음을 나타냅니다.
• 'UnsupportedWarning' - 오류로 처리하기보다는 무시될 지원되지 않는 옵션 또는 기능의 사용을 나타냅니다. 한 가지 예는 HTTP/2 호환성 API를 사용할 때 HTTP 응답 상태 메시지를 사용하는 것입니다.

이벤트: 'worker'

추가된 버전: v16.2.0, v14.18.0

• worker <Worker> 생성된 <Worker>입니다.

새로운 <Worker> 스레드가 생성된 후 'worker' 이벤트가 발생합니다.

시그널 이벤트

Node.js 프로세스가 시그널을 수신하면 시그널 이벤트가 발생합니다. 'SIGINT', 'SIGHUP' 등과 같은 표준 POSIX 시그널 이름 목록은 signal(7)을 참조하십시오.

시그널은 Worker 스레드에서는 사용할 수 없습니다.

시그널 핸들러는 시그널 이름 ('SIGINT', 'SIGTERM' 등)을 첫 번째 인수로 받습니다.

각 이벤트의 이름은 시그널의 대문자 일반 이름입니다(예: SIGINT 시그널의 경우 'SIGINT').

ESM

import process from 'node:process'

// 프로세스가 종료되지 않도록 stdin에서 읽기를 시작합니다.
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('SIGINT를 수신했습니다. Control-D를 눌러 종료하십시오.')
})

// 여러 시그널을 처리하는 단일 함수 사용
function handle(signal) {
  console.log(`수신된 시그널 ${signal}`)
}

process.on('SIGINT', handle)
process.on('SIGTERM', handle)

CJS

const process = require('node:process')

// 프로세스가 종료되지 않도록 stdin에서 읽기를 시작합니다.
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('SIGINT를 수신했습니다. Control-D를 눌러 종료하십시오.')
})

// 여러 시그널을 처리하는 단일 함수 사용
function handle(signal) {
  console.log(`수신된 시그널 ${signal}`)
}

process.on('SIGINT', handle)
process.on('SIGTERM', handle)

• 'SIGUSR1'은 디버거를 시작하기 위해 Node.js에서 예약되었습니다. 리스너를 설치할 수는 있지만 그렇게 하면 디버거를 방해할 수 있습니다.
• 'SIGTERM' 및 'SIGINT'는 Windows가 아닌 플랫폼에서 코드 128 + 시그널 번호로 종료하기 전에 터미널 모드를 재설정하는 기본 핸들러를 가지고 있습니다. 이러한 시그널 중 하나에 리스너가 설치되어 있으면 기본 동작이 제거됩니다(Node.js는 더 이상 종료되지 않음).
• 'SIGPIPE'는 기본적으로 무시됩니다. 리스너를 설치할 수 있습니다.
• 'SIGHUP'은 콘솔 창이 닫힐 때 Windows에서 생성되고, 다른 플랫폼에서는 다양한 유사한 조건에서 생성됩니다. signal(7)을 참조하십시오. 리스너를 설치할 수 있지만, Windows에서는 약 10초 후에 Node.js가 무조건 종료됩니다. Windows가 아닌 플랫폼에서는 SIGHUP의 기본 동작은 Node.js를 종료하는 것이지만, 리스너가 설치되면 기본 동작이 제거됩니다.
• 'SIGTERM'은 Windows에서 지원되지 않지만 수신할 수 있습니다.
• 터미널의 'SIGINT'는 모든 플랫폼에서 지원되며 일반적으로 + 키로 생성할 수 있습니다(구성 가능할 수 있음). 터미널 원시 모드가 활성화되고 + 키가 사용되면 생성되지 않습니다.
• 'SIGBREAK'는 + 키를 누르면 Windows에서 전달됩니다. Windows가 아닌 플랫폼에서는 수신할 수 있지만 전송하거나 생성할 방법이 없습니다.
• 'SIGWINCH'는 콘솔 크기가 조정되면 전달됩니다. Windows에서는 커서가 이동 중이거나 원시 모드에서 읽을 수 있는 tty가 사용될 때 콘솔에 쓸 때만 발생합니다.
• 'SIGKILL'은 리스너를 설치할 수 없으며 모든 플랫폼에서 Node.js를 무조건 종료합니다.
• 'SIGSTOP'은 리스너를 설치할 수 없습니다.
• kill(2)를 사용하여 인위적으로 발생하지 않은 경우 'SIGBUS', 'SIGFPE', 'SIGSEGV' 및 'SIGILL'은 본질적으로 JS 리스너를 호출하기에 안전하지 않은 상태로 프로세스를 남깁니다. 그렇게 하면 프로세스가 응답하지 않을 수 있습니다.
• 프로세스의 존재 여부를 테스트하기 위해 0을 보낼 수 있습니다. 프로세스가 있으면 아무런 효과가 없지만 프로세스가 없으면 오류를 발생시킵니다.

Windows는 시그널을 지원하지 않으므로 시그널에 의한 종료와 동일한 기능이 없지만 Node.js는 process.kill() 및 subprocess.kill()을 사용하여 일부 에뮬레이션을 제공합니다.

• SIGINT, SIGTERM 및 SIGKILL을 보내면 대상 프로세스가 무조건 종료되고, 그 후 하위 프로세스는 시그널에 의해 프로세스가 종료되었음을 보고합니다.
• 시그널 0을 보내는 것은 프로세스의 존재 여부를 테스트하는 플랫폼 독립적인 방법으로 사용할 수 있습니다.

process.abort()

추가된 버전: v0.7.0

process.abort() 메서드는 Node.js 프로세스를 즉시 종료하고 코어 파일을 생성합니다.

이 기능은 Worker 스레드에서는 사용할 수 없습니다.

process.allowedNodeEnvironmentFlags

추가된 버전: v10.10.0

• <Set>

process.allowedNodeEnvironmentFlags 속성은 NODE_OPTIONS 환경 변수 내에서 허용되는 플래그의 특별한 읽기 전용 Set입니다.

process.allowedNodeEnvironmentFlags는 Set을 확장하지만 여러 가지 가능한 플래그 표현을 인식하도록 Set.prototype.has를 재정의합니다. process.allowedNodeEnvironmentFlags.has()는 다음 경우에 true를 반환합니다.

• 플래그는 선행 단일 (-) 또는 이중 (--) 대시를 생략할 수 있습니다. 예를 들어, --inspect-brk의 경우 inspect-brk 또는 -r의 경우 r입니다.
• V8로 전달되는 플래그(예: --v8-options에 나열됨)는 하나 이상의 선행되지 않는 대시를 밑줄로 바꾸거나 그 반대로 바꿀 수 있습니다. 예를 들어, --perf_basic_prof, --perf-basic-prof, --perf_basic-prof 등이 있습니다.
• 플래그는 하나 이상의 등호(=) 문자를 포함할 수 있습니다. 첫 번째 등호를 포함하여 그 이후의 모든 문자는 무시됩니다. 예를 들어, --stack-trace-limit=100입니다.
• 플래그는 NODE_OPTIONS 내에서 허용되어야 합니다.

process.allowedNodeEnvironmentFlags를 반복할 때 플래그는 한 번만 나타납니다. 각 플래그는 하나 이상의 대시로 시작됩니다. V8로 전달되는 플래그에는 선행되지 않는 대시 대신 밑줄이 포함됩니다.

import { allowedNodeEnvironmentFlags } from 'node:process'

allowedNodeEnvironmentFlags.forEach(flag => {
  // -r
  // --inspect-brk
  // --abort_on_uncaught_exception
  // ...
})

const { allowedNodeEnvironmentFlags } = require('node:process')

allowedNodeEnvironmentFlags.forEach(flag => {
  // -r
  // --inspect-brk
  // --abort_on_uncaught_exception
  // ...
})

process.allowedNodeEnvironmentFlags의 메서드 add(), clear(), 및 delete()는 아무 작업도 수행하지 않으며 자동으로 실패합니다.

Node.js가 NODE_OPTIONS 지원 없이 컴파일된 경우(process.config에 표시됨) process.allowedNodeEnvironmentFlags에는 허용되었을 내용이 포함됩니다.

process.arch

추가된 버전: v0.5.0

• <string>

Node.js 바이너리가 컴파일된 운영 체제 CPU 아키텍처입니다. 가능한 값은 다음과 같습니다: 'arm', 'arm64', 'ia32', 'loong64', 'mips', 'mipsel', 'ppc', 'ppc64', 'riscv64', 's390', 's390x', 및 'x64'.

ESM

import { arch } from 'node:process'

console.log(`이 프로세서 아키텍처는 ${arch}입니다`)

CJS

const { arch } = require('node:process')

console.log(`이 프로세서 아키텍처는 ${arch}입니다`)

process.argv

추가된 버전: v0.1.27

• <string[]>

process.argv 속성은 Node.js 프로세스가 시작될 때 전달된 명령줄 인수를 포함하는 배열을 반환합니다. 첫 번째 요소는 process.execPath입니다. argv[0]의 원래 값에 접근해야 하는 경우 process.argv0을 참조하십시오. 두 번째 요소는 실행 중인 JavaScript 파일의 경로입니다. 나머지 요소는 추가 명령줄 인수가 됩니다.

예를 들어, process-args.js에 대한 다음 스크립트를 가정해 보겠습니다.

ESM

import { argv } from 'node:process'

// process.argv 출력
argv.forEach((val, index) => {
  console.log(`${index}: ${val}`)
})

CJS

const { argv } = require('node:process')

// process.argv 출력
argv.forEach((val, index) => {
  console.log(`${index}: ${val}`)
})

다음과 같이 Node.js 프로세스를 시작합니다.

node process-args.js one two=three four

다음과 같은 출력이 생성됩니다:

0: /usr/local/bin/node
1: /Users/mjr/work/node/process-args.js
2: one
3: two=three
4: four

process.argv0

추가된 버전: v6.4.0

• <string>

process.argv0 속성은 Node.js가 시작될 때 전달된 argv[0]의 원래 값의 읽기 전용 복사본을 저장합니다.

$ bash -c 'exec -a customArgv0 ./node'
> process.argv[0]
'/Volumes/code/external/node/out/Release/node'
> process.argv0
'customArgv0'

process.channel

[History]

버전	변경 사항
v14.0.0	이 객체는 더 이상 실수로 네이티브 C++ 바인딩을 노출하지 않습니다.
v7.1.0	추가됨: v7.1.0

• <Object>

Node.js 프로세스가 IPC 채널과 함께 스폰된 경우( 자식 프로세스 문서 참조), process.channel 속성은 IPC 채널에 대한 참조입니다. IPC 채널이 없는 경우 이 속성은 undefined입니다.

process.channel.ref()

추가됨: v7.1.0

이 메서드는 .unref()가 이전에 호출된 경우 IPC 채널이 프로세스의 이벤트 루프를 계속 실행하도록 만듭니다.

일반적으로 이는 process 객체에서 'disconnect' 및 'message' 리스너의 수를 통해 관리됩니다. 그러나 이 메서드를 사용하여 특정 동작을 명시적으로 요청할 수 있습니다.

process.channel.unref()

추가됨: v7.1.0

이 메서드는 IPC 채널이 프로세스의 이벤트 루프를 계속 실행하지 않도록 하고 채널이 열려 있는 동안에도 완료되도록 합니다.

일반적으로 이는 process 객체에서 'disconnect' 및 'message' 리스너의 수를 통해 관리됩니다. 그러나 이 메서드를 사용하여 특정 동작을 명시적으로 요청할 수 있습니다.

process.chdir(directory)

추가됨: v0.1.17

• directory <string>

process.chdir() 메서드는 Node.js 프로세스의 현재 작업 디렉토리를 변경하거나 실패할 경우(예: 지정된 directory가 존재하지 않는 경우) 예외를 발생시킵니다.

ESM

import { chdir, cwd } from 'node:process'

console.log(`시작 디렉토리: ${cwd()}`)
try {
  chdir('/tmp')
  console.log(`새 디렉토리: ${cwd()}`)
} catch (err) {
  console.error(`chdir: ${err}`)
}

CJS

const { chdir, cwd } = require('node:process')

console.log(`시작 디렉토리: ${cwd()}`)
try {
  chdir('/tmp')
  console.log(`새 디렉토리: ${cwd()}`)
} catch (err) {
  console.error(`chdir: ${err}`)
}

이 기능은 Worker 스레드에서 사용할 수 없습니다.

process.config

[기록]

버전	변경 사항
v19.0.0	process.config 객체가 이제 고정되었습니다.
v16.0.0	process.config 수정이 더 이상 사용되지 않습니다.
v0.7.7	v0.7.7에 추가됨

• <Object>

process.config 속성은 현재 Node.js 실행 파일을 컴파일하는 데 사용된 구성 옵션의 JavaScript 표현을 포함하는 고정된 Object를 반환합니다. 이는 ./configure 스크립트를 실행할 때 생성된 config.gypi 파일과 동일합니다.

가능한 출력 예시는 다음과 같습니다.

{
  target_defaults:
   { cflags: [],
     default_configuration: 'Release',
     defines: [],
     include_dirs: [],
     libraries: [] },
  variables:
   {
     host_arch: 'x64',
     napi_build_version: 5,
     node_install_npm: 'true',
     node_prefix: '',
     node_shared_cares: 'false',
     node_shared_http_parser: 'false',
     node_shared_libuv: 'false',
     node_shared_zlib: 'false',
     node_use_openssl: 'true',
     node_shared_openssl: 'false',
     target_arch: 'x64',
     v8_use_snapshot: 1
   }
}

process.connected

v0.7.2에 추가됨

• <boolean>

Node.js 프로세스가 IPC 채널로 생성된 경우( 자식 프로세스 및 클러스터 문서 참조), process.connected 속성은 IPC 채널이 연결되어 있는 한 true를 반환하고 process.disconnect()가 호출된 후에는 false를 반환합니다.

process.connected가 false가 되면 process.send()를 사용하여 IPC 채널을 통해 메시지를 더 이상 보낼 수 없습니다.

process.constrainedMemory()

[기록]

버전	변경 사항
v22.0.0, v20.13.0	uv_get_constrained_memory와 반환 값을 일치시켰습니다.
v19.6.0, v18.15.0	v19.6.0, v18.15.0에 추가됨

[안정성: 1 - 실험적]

안정성: 1 안정성: 1 - 실험적

• <number>

OS에서 부과한 제한을 기반으로 프로세스에서 사용할 수 있는 메모리 양(바이트 단위)을 가져옵니다. 그러한 제한이 없거나 제한이 알려지지 않은 경우 0이 반환됩니다.

자세한 내용은 uv_get_constrained_memory를 참조하세요.

process.availableMemory()

추가된 버전: v22.0.0, v20.13.0

[안정성: 1 - 실험적]

안정성: 1 안정성: 1 - 실험적

• <number>

프로세스에서 사용할 수 있는 여유 메모리 양(바이트 단위)을 가져옵니다.

자세한 내용은 uv_get_available_memory를 참조하십시오.

process.cpuUsage([previousValue])

추가된 버전: v6.1.0

• previousValue <Object> process.cpuUsage() 호출에서 이전 반환 값
• 반환 값: <Object>
  • user <integer>
  • system <integer>

process.cpuUsage() 메서드는 현재 프로세스의 사용자 및 시스템 CPU 시간 사용량을 user 및 system 속성을 가진 객체로 반환하며, 이 값은 마이크로초 값(백만분의 1초)입니다. 이러한 값은 각각 사용자 및 시스템 코드에서 소요된 시간을 측정하며, 여러 CPU 코어가 이 프로세스에 대한 작업을 수행하는 경우 실제 경과 시간보다 클 수 있습니다.

process.cpuUsage()에 대한 이전 호출의 결과를 함수의 인수로 전달하여 차이 값을 얻을 수 있습니다.

ESM

import { cpuUsage } from 'node:process'

const startUsage = cpuUsage()
// { user: 38579, system: 6986 }

// 500밀리초 동안 CPU를 돌립니다.
const now = Date.now()
while (Date.now() - now < 500);

console.log(cpuUsage(startUsage))
// { user: 514883, system: 11226 }

CJS

const { cpuUsage } = require('node:process')

const startUsage = cpuUsage()
// { user: 38579, system: 6986 }

// 500밀리초 동안 CPU를 돌립니다.
const now = Date.now()
while (Date.now() - now < 500);

console.log(cpuUsage(startUsage))
// { user: 514883, system: 11226 }

process.cwd()

추가된 버전: v0.1.8

• 반환 값: <string>

process.cwd() 메서드는 Node.js 프로세스의 현재 작업 디렉토리를 반환합니다.

ESM

import { cwd } from 'node:process'

console.log(`현재 디렉토리: ${cwd()}`)

CJS

const { cwd } = require('node:process')

console.log(`현재 디렉토리: ${cwd()}`)

process.debugPort

추가된 버전: v0.7.2

• <number>

Node.js 디버거가 활성화되었을 때 사용하는 포트입니다.

ESM

import process from 'node:process'

process.debugPort = 5858

CJS

const process = require('node:process')

process.debugPort = 5858

process.disconnect()

추가된 버전: v0.7.2

Node.js 프로세스가 IPC 채널을 사용하여 생성된 경우(자식 프로세스(/api/child_process) 및 클러스터(/api/cluster) 문서 참조), process.disconnect() 메서드는 부모 프로세스와의 IPC 채널을 닫아 자식 프로세스가 다른 연결이 없어서 활성 상태를 유지할 필요가 없을 때 정상적으로 종료될 수 있도록 합니다.

process.disconnect()를 호출하는 효과는 부모 프로세스에서 ChildProcess.disconnect()를 호출하는 것과 같습니다.

Node.js 프로세스가 IPC 채널 없이 생성된 경우, process.disconnect()는 undefined가 됩니다.

process.dlopen(module, filename[, flags])

[기록]

버전	변경 사항
v9.0.0	flags 인수에 대한 지원이 추가되었습니다.
v0.1.16	추가됨: v0.1.16

• module <Object>
• filename <string>
• flags <os.constants.dlopen> 기본값: os.constants.dlopen.RTLD_LAZY

process.dlopen() 메서드를 사용하면 공유 객체를 동적으로 로드할 수 있습니다. 이 메서드는 주로 require()에서 C++ Addon을 로드하는 데 사용되며, 특수한 경우를 제외하고는 직접 사용하지 않아야 합니다. 즉, 사용자 정의 dlopen 플래그 또는 ES 모듈에서 로드하는 것과 같은 특정 이유가 없는 한 process.dlopen()보다는 require()를 사용하는 것이 좋습니다.

flags 인수는 dlopen 동작을 지정할 수 있는 정수입니다. 자세한 내용은 os.constants.dlopen 문서를 참조하십시오.

process.dlopen()을 호출할 때 중요한 요구 사항은 module 인스턴스를 전달해야 한다는 것입니다. C++ Addon에서 내보낸 함수는 module.exports를 통해 액세스할 수 있습니다.

아래 예는 foo 함수를 내보내는 local.node라는 C++ Addon을 로드하는 방법을 보여줍니다. RTLD_NOW 상수를 전달하여 호출이 반환되기 전에 모든 기호가 로드됩니다. 이 예에서는 상수를 사용할 수 있다고 가정합니다.

ESM

import { dlopen } from 'node:process'
import { constants } from 'node:os'
import { fileURLToPath } from 'node:url'

const module = { exports: {} }
dlopen(module, fileURLToPath(new URL('local.node', import.meta.url)), constants.dlopen.RTLD_NOW)
module.exports.foo()

CJS

const { dlopen } = require('node:process')
const { constants } = require('node:os')
const { join } = require('node:path')

const module = { exports: {} }
dlopen(module, join(__dirname, 'local.node'), constants.dlopen.RTLD_NOW)
module.exports.foo()

process.emitWarning(warning[, options])

추가된 버전: v8.0.0

• warning <string> | <Error> 발생시킬 경고입니다.
• options <Object>
  • type <string> warning이 String일 때, type은 발생되는 경고의 유형에 사용할 이름입니다. 기본값: 'Warning'.
  • code <string> 발생되는 경고 인스턴스의 고유 식별자입니다.
  • ctor <Function> warning이 String일 때, ctor는 생성된 스택 추적을 제한하는 데 사용되는 선택적 함수입니다. 기본값: process.emitWarning.
  • detail <string> 오류에 포함할 추가 텍스트입니다.

process.emitWarning() 메서드는 사용자 정의 또는 애플리케이션 특정 프로세스 경고를 발생시키는 데 사용할 수 있습니다. 이러한 경고는 'warning' 이벤트에 핸들러를 추가하여 수신할 수 있습니다.

ESM

import { emitWarning } from 'node:process'

// 코드와 추가 세부 정보와 함께 경고를 발생시킵니다.
emitWarning('무언가가 발생했습니다!', {
  code: 'MY_WARNING',
  detail: '추가 정보입니다',
})
// 출력:
// (node:56338) [MY_WARNING] Warning: 무언가가 발생했습니다!
// 추가 정보입니다

CJS

const { emitWarning } = require('node:process')

// 코드와 추가 세부 정보와 함께 경고를 발생시킵니다.
emitWarning('무언가가 발생했습니다!', {
  code: 'MY_WARNING',
  detail: '추가 정보입니다',
})
// 출력:
// (node:56338) [MY_WARNING] Warning: 무언가가 발생했습니다!
// 추가 정보입니다

이 예에서 Error 객체는 process.emitWarning()에 의해 내부적으로 생성되어 'warning' 핸들러로 전달됩니다.

ESM

import process from 'node:process'

process.on('warning', warning => {
  console.warn(warning.name) // 'Warning'
  console.warn(warning.message) // '무언가가 발생했습니다!'
  console.warn(warning.code) // 'MY_WARNING'
  console.warn(warning.stack) // 스택 추적
  console.warn(warning.detail) // '추가 정보입니다'
})

CJS

const process = require('node:process')

process.on('warning', warning => {
  console.warn(warning.name) // 'Warning'
  console.warn(warning.message) // '무언가가 발생했습니다!'
  console.warn(warning.code) // 'MY_WARNING'
  console.warn(warning.stack) // 스택 추적
  console.warn(warning.detail) // '추가 정보입니다'
})

warning이 Error 객체로 전달되면, options 인수는 무시됩니다.

process.emitWarning(warning[, type[, code]][, ctor])

Added in: v6.0.0

• warning <string> | <Error> 내보낼 경고.
• type <string> warning이 String일 때, type은 내보낼 경고의 유형에 사용할 이름입니다. 기본값: 'Warning'.
• code <string> 내보낼 경고 인스턴스의 고유 식별자입니다.
• ctor <Function> warning이 String일 때, ctor는 생성된 스택 추적을 제한하는 데 사용되는 선택적 함수입니다. 기본값: process.emitWarning.

process.emitWarning() 메서드는 사용자 정의 또는 애플리케이션 특정 프로세스 경고를 내보내는 데 사용할 수 있습니다. 이러한 경고는 'warning' 이벤트에 핸들러를 추가하여 수신할 수 있습니다.

ESM

import { emitWarning } from 'node:process'

// 문자열을 사용하여 경고를 내보냅니다.
emitWarning('Something happened!')
// 출력: (node: 56338) Warning: Something happened!

CJS

const { emitWarning } = require('node:process')

// 문자열을 사용하여 경고를 내보냅니다.
emitWarning('Something happened!')
// 출력: (node: 56338) Warning: Something happened!

ESM

import { emitWarning } from 'node:process'

// 문자열과 유형을 사용하여 경고를 내보냅니다.
emitWarning('Something Happened!', 'CustomWarning')
// 출력: (node:56338) CustomWarning: Something Happened!

CJS

const { emitWarning } = require('node:process')

// 문자열과 유형을 사용하여 경고를 내보냅니다.
emitWarning('Something Happened!', 'CustomWarning')
// 출력: (node:56338) CustomWarning: Something Happened!

ESM

import { emitWarning } from 'node:process'

emitWarning('Something happened!', 'CustomWarning', 'WARN001')
// 출력: (node:56338) [WARN001] CustomWarning: Something happened!

CJS

const { emitWarning } = require('node:process')

process.emitWarning('Something happened!', 'CustomWarning', 'WARN001')
// 출력: (node:56338) [WARN001] CustomWarning: Something happened!

이전의 각 예에서 Error 객체는 process.emitWarning()에 의해 내부적으로 생성되어 'warning' 핸들러로 전달됩니다.

ESM

import process from 'node:process'

process.on('warning', warning => {
  console.warn(warning.name)
  console.warn(warning.message)
  console.warn(warning.code)
  console.warn(warning.stack)
})

CJS

const process = require('node:process')

process.on('warning', warning => {
  console.warn(warning.name)
  console.warn(warning.message)
  console.warn(warning.code)
  console.warn(warning.stack)
})

warning이 Error 객체로 전달되면 수정되지 않고 'warning' 이벤트 핸들러로 전달되며 선택적 type, code 및 ctor 인수는 무시됩니다.

ESM

import { emitWarning } from 'node:process'

// Error 객체를 사용하여 경고를 내보냅니다.
const myWarning = new Error('Something happened!')
// Error name 속성을 사용하여 유형 이름을 지정합니다.
myWarning.name = 'CustomWarning'
myWarning.code = 'WARN001'

emitWarning(myWarning)
// 출력: (node:56338) [WARN001] CustomWarning: Something happened!

CJS

const { emitWarning } = require('node:process')

// Error 객체를 사용하여 경고를 내보냅니다.
const myWarning = new Error('Something happened!')
// Error name 속성을 사용하여 유형 이름을 지정합니다.
myWarning.name = 'CustomWarning'
myWarning.code = 'WARN001'

emitWarning(myWarning)
// 출력: (node:56338) [WARN001] CustomWarning: Something happened!

warning이 문자열 또는 Error 객체 이외의 다른 것이면 TypeError가 발생합니다.

프로세스 경고는 Error 객체를 사용하지만 프로세스 경고 메커니즘은 일반적인 오류 처리 메커니즘을 대체하는 것이 아닙니다.

경고 type이 'DeprecationWarning'인 경우 다음과 같은 추가 처리가 구현됩니다.

• --throw-deprecation 명령줄 플래그를 사용하는 경우, 더 이상 사용되지 않는 경고는 이벤트로 내보내지는 대신 예외로 발생합니다.
• --no-deprecation 명령줄 플래그를 사용하는 경우, 더 이상 사용되지 않는 경고는 억제됩니다.
• --trace-deprecation 명령줄 플래그를 사용하는 경우, 더 이상 사용되지 않는 경고는 전체 스택 추적과 함께 stderr에 출력됩니다.

중복 경고 방지

모범 사례로서, 경고는 프로세스당 한 번만 발생해야 합니다. 그렇게 하려면 emitWarning()을 불리언 뒤에 배치하세요.

ESM

import { emitWarning } from 'node:process'

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true
    emitWarning('한 번만 경고합니다!')
  }
}
emitMyWarning()
// 출력: (node: 56339) 경고: 한 번만 경고합니다!
emitMyWarning()
// 아무것도 출력하지 않음

CJS

const { emitWarning } = require('node:process')

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true
    emitWarning('한 번만 경고합니다!')
  }
}
emitMyWarning()
// 출력: (node: 56339) 경고: 한 번만 경고합니다!
emitMyWarning()
// 아무것도 출력하지 않음

process.env

[기록]

버전	변경 사항
v11.14.0	워커 스레드는 이제 기본적으로 부모 스레드의 process.env 사본을 사용하며, Worker 생성자의 env 옵션을 통해 구성할 수 있습니다.
v10.0.0	변수 값을 문자열로 암시적 변환하는 것이 더 이상 사용되지 않습니다.
v0.1.27	v0.1.27에 추가됨

• <Object>

process.env 속성은 사용자 환경을 포함하는 객체를 반환합니다. environ(7)을 참조하세요.

이 객체의 예는 다음과 같습니다.

{
  TERM: 'xterm-256color',
  SHELL: '/usr/local/bin/bash',
  USER: 'maciej',
  PATH: '~/.bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin',
  PWD: '/Users/maciej',
  EDITOR: 'vim',
  SHLVL: '1',
  HOME: '/Users/maciej',
  LOGNAME: 'maciej',
  _: '/usr/local/bin/node'
}

이 객체를 수정할 수 있지만, 이러한 수정은 Node.js 프로세스 외부나 (명시적으로 요청되지 않는 한) 다른 Worker 스레드에 반영되지 않습니다. 즉, 다음 예제는 작동하지 않습니다.

node -e 'process.env.foo = "bar"' && echo $foo

반면 다음은 작동합니다.

ESM

import { env } from 'node:process'

env.foo = 'bar'
console.log(env.foo)

CJS

const { env } = require('node:process')

env.foo = 'bar'
console.log(env.foo)

process.env에 속성을 할당하면 값이 암시적으로 문자열로 변환됩니다. 이 동작은 더 이상 사용되지 않습니다. Node.js의 이후 버전에서는 값이 문자열, 숫자 또는 부울이 아닌 경우 오류를 발생시킬 수 있습니다.

ESM

import { env } from 'node:process'

env.test = null
console.log(env.test)
// => 'null'
env.test = undefined
console.log(env.test)
// => 'undefined'

CJS

const { env } = require('node:process')

env.test = null
console.log(env.test)
// => 'null'
env.test = undefined
console.log(env.test)
// => 'undefined'

process.env에서 속성을 삭제하려면 delete를 사용하세요.

ESM

import { env } from 'node:process'

env.TEST = 1
delete env.TEST
console.log(env.TEST)
// => undefined

CJS

const { env } = require('node:process')

env.TEST = 1
delete env.TEST
console.log(env.TEST)
// => undefined

Windows 운영 체제에서 환경 변수는 대소문자를 구분하지 않습니다.

ESM

import { env } from 'node:process'

env.TEST = 1
console.log(env.test)
// => 1

CJS

const { env } = require('node:process')

env.TEST = 1
console.log(env.test)
// => 1

Worker 인스턴스를 생성할 때 명시적으로 지정하지 않는 한, 각 Worker 스레드는 부모 스레드의 process.env를 기반으로 하거나, Worker 생성자에 대한 env 옵션으로 지정된 내용을 기반으로 자체 process.env 사본을 갖습니다. process.env에 대한 변경 사항은 Worker 스레드에서 볼 수 없으며, 메인 스레드만 운영 체제 또는 네이티브 추가 기능에서 볼 수 있는 변경 사항을 만들 수 있습니다. Windows에서 Worker 인스턴스의 process.env 사본은 메인 스레드와 달리 대소문자를 구분하여 작동합니다.

process.execArgv

추가된 버전: v0.7.7

• <string[]>

process.execArgv 속성은 Node.js 프로세스가 시작될 때 전달된 Node.js 특정 명령줄 옵션 집합을 반환합니다. 이러한 옵션은 process.argv 속성에 의해 반환된 배열에 나타나지 않으며, Node.js 실행 파일, 스크립트 이름 또는 스크립트 이름 뒤에 오는 옵션을 포함하지 않습니다. 이러한 옵션은 부모와 동일한 실행 환경에서 자식 프로세스를 생성하기 위해 유용합니다.

node --icu-data-dir=./foo --require ./bar.js script.js --version

결과 process.execArgv:

["--icu-data-dir=./foo", "--require", "./bar.js"]

그리고 process.argv:

;['/usr/local/bin/node', 'script.js', '--version']

이 속성을 사용하는 워커 스레드의 자세한 동작은 Worker 생성자를 참조하십시오.

process.execPath

추가된 버전: v0.1.100

• <string>

process.execPath 속성은 Node.js 프로세스를 시작한 실행 파일의 절대 경로명을 반환합니다. 기호 링크가 있는 경우 해당 기호 링크가 해결됩니다.

'/usr/local/bin/node'

process.exit([code])

[히스토리]

버전	변경 사항
v20.0.0	숫자 유형 또는 정수를 나타내는 경우 문자열 유형의 코드만 허용합니다.
v0.1.13	추가된 버전: v0.1.13

• code <integer> | <string> | <null> | <undefined> 종료 코드입니다. 문자열 유형의 경우 정수 문자열(예: '1')만 허용됩니다. 기본값: 0.

process.exit() 메서드는 Node.js에게 종료 상태 code로 프로세스를 동기적으로 종료하도록 지시합니다. code를 생략하면 종료 시 '성공' 코드 0 또는 설정된 경우 process.exitCode의 값을 사용합니다. Node.js는 모든 'exit' 이벤트 리스너가 호출될 때까지 종료되지 않습니다.

'실패' 코드로 종료하려면:

ESM

import { exit } from 'node:process'

exit(1)

CJS

const { exit } = require('node:process')

exit(1)

Node.js를 실행한 셸은 종료 코드를 1로 인식해야 합니다.

process.exit()를 호출하면 process.stdout 및 process.stderr에 대한 I/O 작업을 포함하여 아직 완전히 완료되지 않은 비동기 작업이 보류 중이더라도 가능한 한 빨리 프로세스가 강제로 종료됩니다.

대부분의 경우 process.exit()를 명시적으로 호출할 필요는 없습니다. Node.js 프로세스는 이벤트 루프에서 추가 작업이 보류 중이지 않은 경우 저절로 종료됩니다. process.exitCode 속성을 설정하여 프로세스가 정상적으로 종료될 때 사용할 종료 코드를 프로세스에 알릴 수 있습니다.

예를 들어 다음 예제는 stdout에 인쇄된 데이터가 잘리고 손실될 수 있는 process.exit() 메서드의 잘못된 사용을 보여줍니다.

ESM

import { exit } from 'node:process'

// 이것은 *하지 말아야 할* 예입니다:
if (someConditionNotMet()) {
  printUsageToStdout()
  exit(1)
}

CJS

const { exit } = require('node:process')

// 이것은 *하지 말아야 할* 예입니다:
if (someConditionNotMet()) {
  printUsageToStdout()
  exit(1)
}

이것이 문제가 되는 이유는 Node.js에서 process.stdout에 대한 쓰기가 때로는 비동기적이며 Node.js 이벤트 루프의 여러 틱에 걸쳐 발생할 수 있기 때문입니다. 그러나 process.exit()를 호출하면 stdout에 대한 추가 쓰기가 수행되기 전에 프로세스가 강제로 종료됩니다.

process.exit()를 직접 호출하는 대신 코드는 process.exitCode를 설정하고 이벤트 루프에 대한 추가 작업을 예약하지 않음으로써 프로세스가 자연스럽게 종료되도록 해야 합니다.

ESM

import process from 'node:process'

// 프로세스가 정상적으로 종료되도록 하면서
// 종료 코드를 올바르게 설정하는 방법.
if (someConditionNotMet()) {
  printUsageToStdout()
  process.exitCode = 1
}

CJS

const process = require('node:process')

// 프로세스가 정상적으로 종료되도록 하면서
// 종료 코드를 올바르게 설정하는 방법.
if (someConditionNotMet()) {
  printUsageToStdout()
  process.exitCode = 1
}

오류 조건으로 인해 Node.js 프로세스를 종료해야 하는 경우 포착되지 않은 오류를 발생시키고 그에 따라 프로세스가 종료되도록 하는 것이 process.exit()를 호출하는 것보다 더 안전합니다.

Worker 스레드에서 이 함수는 현재 프로세스가 아닌 현재 스레드를 중지합니다.

process.exitCode

[기록]

버전	변경 사항
v20.0.0	숫자 타입 또는 정수를 나타내는 문자열 타입의 코드만 허용합니다.
v0.11.8	v0.11.8에 추가됨

• <integer> | <string> | <null> | <undefined> 종료 코드. 문자열 타입의 경우 정수 문자열(예: '1')만 허용됩니다. 기본값: undefined.

프로세스가 정상적으로 종료되거나, 코드 지정 없이 process.exit()를 통해 종료될 때 프로세스 종료 코드가 될 숫자입니다.

process.exit(code)에 코드를 지정하면 process.exitCode의 이전 설정이 무시됩니다.

process.features.cached_builtins

v12.0.0에 추가됨

• <boolean>

현재 Node.js 빌드가 내장 모듈을 캐싱하는 경우 true인 부울 값입니다.

process.features.debug

v0.5.5에 추가됨

• <boolean>

현재 Node.js 빌드가 디버그 빌드인 경우 true인 부울 값입니다.

process.features.inspector

v11.10.0에 추가됨

• <boolean>

현재 Node.js 빌드에 인스펙터가 포함된 경우 true인 부울 값입니다.

process.features.ipv6

v0.5.3에 추가됨

v23.4.0부터 사용 중단됨

[안정성: 0 - 사용 중단됨]

안정성: 0 안정성: 0 - 사용 중단됨. 이 속성은 항상 true이며, 이를 기반으로 하는 모든 검사는 불필요합니다.

• <boolean>

현재 Node.js 빌드에 IPv6 지원이 포함된 경우 true인 부울 값입니다.

모든 Node.js 빌드에 IPv6 지원이 있으므로 이 값은 항상 true입니다.

process.features.require_module

추가된 버전: v23.0.0

• <boolean>

현재 Node.js 빌드가 require()를 사용하여 ECMAScript 모듈 로딩을 지원하는 경우 true인 부울 값입니다.

process.features.tls

추가된 버전: v0.5.3

• <boolean>

현재 Node.js 빌드가 TLS 지원을 포함하는 경우 true인 부울 값입니다.

process.features.tls_alpn

추가된 버전: v4.8.0

지원 중단된 버전: v23.4.0

[안정성: 0 - 지원 중단됨]

안정성: 0 안정성: 0 - 지원 중단됨. process.features.tls를 대신 사용하세요.

• <boolean>

현재 Node.js 빌드가 TLS에서 ALPN 지원을 포함하는 경우 true인 부울 값입니다.

Node.js 11.0.0 이상 버전에서는 OpenSSL 종속성이 무조건적인 ALPN 지원을 제공합니다. 따라서 이 값은 process.features.tls의 값과 동일합니다.

process.features.tls_ocsp

추가된 버전: v0.11.13

지원 중단된 버전: v23.4.0

[안정성: 0 - 지원 중단됨]

안정성: 0 안정성: 0 - 지원 중단됨. process.features.tls를 대신 사용하세요.

• <boolean>

현재 Node.js 빌드가 TLS에서 OCSP 지원을 포함하는 경우 true인 부울 값입니다.

Node.js 11.0.0 이상 버전에서는 OpenSSL 종속성이 무조건적인 OCSP 지원을 제공합니다. 따라서 이 값은 process.features.tls의 값과 동일합니다.

process.features.tls_sni

추가된 버전: v0.5.3

지원 중단된 버전: v23.4.0

[안정성: 0 - 지원 중단됨]

안정성: 0 안정성: 0 - 지원 중단됨. process.features.tls를 대신 사용하세요.

• <boolean>

현재 Node.js 빌드가 TLS에서 SNI 지원을 포함하는 경우 true인 부울 값입니다.

Node.js 11.0.0 이상 버전에서는 OpenSSL 종속성이 무조건적인 SNI 지원을 제공합니다. 따라서 이 값은 process.features.tls의 값과 동일합니다.

process.features.typescript

추가된 버전: v23.0.0

[안정성: 1 - 실험적]

안정성: 1 안정성: 1.1 - 활발한 개발 중

• <boolean> | <string>

Node.js가 --experimental-strip-types로 실행된 경우 "strip", --experimental-transform-types로 실행된 경우 "transform", 그 외에는 false 값입니다.

process.features.uv

추가된 버전: v0.5.3

지원 중단된 버전: v23.4.0

[안정성: 0 - 지원 중단]

안정성: 0 안정성: 0 - 지원 중단. 이 속성은 항상 true이며, 이를 기반으로 한 검사는 불필요합니다.

• <boolean>

현재 Node.js 빌드에 libuv 지원이 포함된 경우 true인 boolean 값입니다.

libuv 없이 Node.js를 빌드하는 것은 불가능하므로 이 값은 항상 true입니다.

process.finalization.register(ref, callback)

추가된 버전: v22.5.0

[안정성: 1 - 실험적]

안정성: 1 안정성: 1.1 - 활발한 개발 중

• ref <Object> | <Function> 추적할 리소스에 대한 참조입니다.
• callback <Function> 리소스가 완료될 때 호출될 콜백 함수입니다.
  • ref <Object> | <Function> 추적할 리소스에 대한 참조입니다.
  • event <string> 완료를 트리거한 이벤트입니다. 기본값은 'exit'입니다.

이 함수는 ref 객체가 가비지 수집되지 않은 경우 프로세스가 exit 이벤트를 발생시킬 때 호출될 콜백을 등록합니다. 객체 ref가 exit 이벤트가 발생하기 전에 가비지 수집된 경우, 콜백은 완료 레지스트리에서 제거되고 프로세스 종료 시 호출되지 않습니다.

콜백 내부에서 ref 객체에 의해 할당된 리소스를 해제할 수 있습니다. beforeExit 이벤트에 적용되는 모든 제한 사항이 callback 함수에도 적용된다는 점을 인지해야 합니다. 즉, 특별한 상황에서는 콜백이 호출되지 않을 가능성이 있습니다.

이 함수의 아이디어는 프로세스 종료가 시작될 때 리소스를 해제하는 데 도움이 되지만, 객체가 더 이상 사용되지 않는 경우 가비지 수집되도록 하는 것입니다.

예: 버퍼를 포함하는 객체를 등록할 수 있습니다. 프로세스 종료 시 해당 버퍼가 해제되도록 해야 하지만, 프로세스 종료 전에 객체가 가비지 수집된 경우 더 이상 버퍼를 해제할 필요가 없으므로 이 경우 완료 레지스트리에서 콜백만 제거합니다.

CJS

const { finalization } = require('node:process')

// finalization.register()에 전달된 함수가 불필요한 객체를 둘러싼 클로저를 생성하지 않는지 확인하십시오.
function onFinalize(obj, event) {
  // 객체로 원하는 작업을 수행할 수 있습니다.
  obj.dispose()
}

function setup() {
  // 이 객체는 안전하게 가비지 수집될 수 있으며,
  // 결과 종료 함수는 호출되지 않습니다.
  // 누출은 없습니다.
  const myDisposableObject = {
    dispose() {
      // 리소스를 동기적으로 해제합니다.
    },
  }

  finalization.register(myDisposableObject, onFinalize)
}

setup()

ESM

import { finalization } from 'node:process'

// finalization.register()에 전달된 함수가 불필요한 객체를 둘러싼 클로저를 생성하지 않는지 확인하십시오.
function onFinalize(obj, event) {
  // 객체로 원하는 작업을 수행할 수 있습니다.
  obj.dispose()
}

function setup() {
  // 이 객체는 안전하게 가비지 수집될 수 있으며,
  // 결과 종료 함수는 호출되지 않습니다.
  // 누출은 없습니다.
  const myDisposableObject = {
    dispose() {
      // 리소스를 동기적으로 해제합니다.
    },
  }

  finalization.register(myDisposableObject, onFinalize)
}

setup()

위의 코드는 다음 가정을 기반으로 합니다.

• 화살표 함수는 피합니다.
• 일반 함수는 전역 컨텍스트(루트) 내에 있는 것이 좋습니다.

일반 함수는 obj가 있는 컨텍스트를 참조하여 obj를 가비지 수집 불가능하게 만들 수 있습니다.

화살표 함수는 이전 컨텍스트를 유지합니다. 예를 들어 다음을 고려하십시오.

class Test {
  constructor() {
    finalization.register(this, ref => ref.dispose())

    // 심지어 다음과 같은 것도 매우 권장하지 않습니다.
    // finalization.register(this, () => this.dispose());
  }
  dispose() {}
}

이 객체가 가비지 수집될 가능성은 매우 낮지만(불가능하지는 않음) 그렇지 않으면 process.exit가 호출될 때 dispose가 호출됩니다.

콜백이 모든 상황에서 호출된다는 보장이 없으므로 중요한 리소스 삭제를 위해 이 기능에 의존하지 않도록 주의해야 합니다.

process.finalization.registerBeforeExit(ref, callback)

Added in: v22.5.0

[안정성: 1 - 실험적]

안정성: 1 안정성: 1.1 - 활발한 개발 중

• ref <Object> | <Function> 추적 중인 리소스에 대한 참조.
• callback <Function> 리소스가 완료될 때 호출되는 콜백 함수.
  • ref <Object> | <Function> 추적 중인 리소스에 대한 참조.
  • event <string> 완료를 트리거한 이벤트. 기본값은 'beforeExit'입니다.

이 함수는 register와 정확히 동일하게 작동하지만, ref 객체가 가비지 컬렉션되지 않은 경우 프로세스가 beforeExit 이벤트를 발생시킬 때 콜백이 호출됩니다.

beforeExit 이벤트에 적용되는 모든 제한 사항이 callback 함수에도 적용된다는 점에 유의하십시오. 이는 특수한 상황에서 콜백이 호출되지 않을 가능성이 있다는 것을 의미합니다.

process.finalization.unregister(ref)

Added in: v22.5.0

[안정성: 1 - 실험적]

안정성: 1 안정성: 1.1 - 활발한 개발 중

• ref <Object> | <Function> 이전에 등록된 리소스에 대한 참조.

이 함수는 완료 레지스트리에서 객체 등록을 제거하므로 콜백이 더 이상 호출되지 않습니다.

CJS

const { finalization } = require('node:process')

// finalization.register()에 전달된 함수가 불필요한 객체에 대한 클로저를 생성하지 않도록 하십시오.
function onFinalize(obj, event) {
  // 객체로 원하는 작업을 수행할 수 있습니다.
  obj.dispose()
}

function setup() {
  // 이 객체는 안전하게 가비지 컬렉션될 수 있으며,
  // 결과로 생성되는 종료 함수는 호출되지 않습니다.
  // 누수는 없습니다.
  const myDisposableObject = {
    dispose() {
      // 리소스를 동기적으로 해제합니다.
    },
  }

  finalization.register(myDisposableObject, onFinalize)

  // 무언가를 수행합니다.

  myDisposableObject.dispose()
  finalization.unregister(myDisposableObject)
}

setup()

ESM

import { finalization } from 'node:process'

// finalization.register()에 전달된 함수가 불필요한 객체에 대한 클로저를 생성하지 않도록 하십시오.
function onFinalize(obj, event) {
  // 객체로 원하는 작업을 수행할 수 있습니다.
  obj.dispose()
}

function setup() {
  // 이 객체는 안전하게 가비지 컬렉션될 수 있으며,
  // 결과로 생성되는 종료 함수는 호출되지 않습니다.
  // 누수는 없습니다.
  const myDisposableObject = {
    dispose() {
      // 리소스를 동기적으로 해제합니다.
    },
  }

  // finalization.register()에 전달된 함수가 불필요한 객체에 대한 클로저를 생성하지 않도록 하십시오.
  function onFinalize(obj, event) {
    // 객체로 원하는 작업을 수행할 수 있습니다.
    obj.dispose()
  }

  finalization.register(myDisposableObject, onFinalize)

  // 무언가를 수행합니다.

  myDisposableObject.dispose()
  finalization.unregister(myDisposableObject)
}

setup()

process.getActiveResourcesInfo()

추가된 버전: v17.3.0, v16.14.0

[안정성: 1 - 실험적]

안정성: 1 안정성: 1 - 실험적

• 반환 값: <string[]>

process.getActiveResourcesInfo() 메서드는 현재 이벤트 루프를 활성 상태로 유지하는 활성 리소스 유형을 포함하는 문자열 배열을 반환합니다.

ESM

import { getActiveResourcesInfo } from 'node:process'
import { setTimeout } from 'node:timers'

console.log('이전:', getActiveResourcesInfo())
setTimeout(() => {}, 1000)
console.log('이후:', getActiveResourcesInfo())
// 출력:
//   이전: [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   이후: [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]

CJS

const { getActiveResourcesInfo } = require('node:process')
const { setTimeout } = require('node:timers')

console.log('이전:', getActiveResourcesInfo())
setTimeout(() => {}, 1000)
console.log('이후:', getActiveResourcesInfo())
// 출력:
//   이전: [ 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   이후: [ 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]

process.getBuiltinModule(id)

추가된 버전: v22.3.0, v20.16.0

• id <string> 요청된 내장 모듈의 ID입니다.
• 반환 값: <Object> | <undefined>

process.getBuiltinModule(id)는 전역으로 사용 가능한 함수에서 내장 모듈을 로드하는 방법을 제공합니다. 다른 환경을 지원해야 하는 ES 모듈은 Node.js에서 실행될 때 조건부로 Node.js 내장을 로드하기 위해 이 함수를 사용할 수 있습니다. Node.js 환경이 아닌 곳에서 import에 의해 발생하는 해결 오류를 처리하거나 모듈을 비동기 모듈로 변환하거나 동기 API를 비동기 API로 변환하는 동적 import()를 사용하지 않아도 됩니다.

if (globalThis.process?.getBuiltinModule) {
  // Node.js에서 실행 중, Node.js fs 모듈을 사용합니다.
  const fs = globalThis.process.getBuiltinModule('fs')
  // 사용자 모듈을 로드하기 위해 `require()`가 필요한 경우 createRequire()를 사용합니다.
  const module = globalThis.process.getBuiltinModule('module')
  const require = module.createRequire(import.meta.url)
  const foo = require('foo')
}

id가 현재 Node.js 프로세스에서 사용 가능한 내장 모듈을 지정하면 process.getBuiltinModule(id) 메서드는 해당 내장 모듈을 반환합니다. id가 내장 모듈에 해당하지 않으면 undefined가 반환됩니다.

process.getBuiltinModule(id)는 module.isBuiltin(id)에서 인식하는 내장 모듈 ID를 허용합니다. 일부 내장 모듈은 node: 접두사와 함께 로드해야 합니다. 필수 node: 접두사가 있는 내장 모듈을 참조하세요. process.getBuiltinModule(id)에서 반환된 참조는 사용자가 require.cache를 수정하여 require(id)가 다른 것을 반환하더라도 항상 id에 해당하는 내장 모듈을 가리킵니다.

process.getegid()

추가된 버전: v2.0.0

process.getegid() 메서드는 Node.js 프로세스의 숫자 유효 그룹 ID를 반환합니다. (getegid(2) 참조).

ESM

import process from 'node:process'

if (process.getegid) {
  console.log(`현재 gid: ${process.getegid()}`)
}

CJS

const process = require('node:process')

if (process.getegid) {
  console.log(`현재 gid: ${process.getegid()}`)
}

이 함수는 POSIX 플랫폼(즉, Windows 또는 Android가 아님)에서만 사용할 수 있습니다.

process.geteuid()

추가된 버전: v2.0.0

• 반환값: <Object>

process.geteuid() 메서드는 프로세스의 숫자 유효 사용자 ID를 반환합니다. (geteuid(2) 참조).

ESM

import process from 'node:process'

if (process.geteuid) {
  console.log(`현재 uid: ${process.geteuid()}`)
}

CJS

const process = require('node:process')

if (process.geteuid) {
  console.log(`현재 uid: ${process.geteuid()}`)
}

이 함수는 POSIX 플랫폼(즉, Windows 또는 Android가 아님)에서만 사용할 수 있습니다.

process.getgid()

추가된 버전: v0.1.31

• 반환값: <Object>

process.getgid() 메서드는 프로세스의 숫자 그룹 ID를 반환합니다. (getgid(2) 참조).

ESM

import process from 'node:process'

if (process.getgid) {
  console.log(`현재 gid: ${process.getgid()}`)
}

CJS

const process = require('node:process')

if (process.getgid) {
  console.log(`현재 gid: ${process.getgid()}`)
}

이 함수는 POSIX 플랫폼(즉, Windows 또는 Android가 아님)에서만 사용할 수 있습니다.

process.getgroups()

추가된 버전: v0.9.4

• 반환값: <integer[]>

process.getgroups() 메서드는 보조 그룹 ID 배열을 반환합니다. POSIX는 유효 그룹 ID가 포함되는지 여부를 지정하지 않지만 Node.js는 항상 포함되도록 보장합니다.

ESM

import process from 'node:process'

if (process.getgroups) {
  console.log(process.getgroups()) // [ 16, 21, 297 ]
}

CJS

const process = require('node:process')

if (process.getgroups) {
  console.log(process.getgroups()) // [ 16, 21, 297 ]
}

이 함수는 POSIX 플랫폼(즉, Windows 또는 Android가 아님)에서만 사용할 수 있습니다.

process.getuid()

추가된 버전: v0.1.28

• 반환 값: <integer>

process.getuid() 메서드는 프로세스의 숫자 사용자 ID를 반환합니다. (getuid(2) 참조).

ESM

import process from 'node:process'

if (process.getuid) {
  console.log(`현재 uid: ${process.getuid()}`)
}

CJS

const process = require('node:process')

if (process.getuid) {
  console.log(`현재 uid: ${process.getuid()}`)
}

이 함수는 POSIX 플랫폼(즉, Windows 또는 Android가 아님)에서만 사용할 수 있습니다.

process.hasUncaughtExceptionCaptureCallback()

추가된 버전: v9.3.0

• 반환 값: <boolean>

process.setUncaughtExceptionCaptureCallback()을 사용하여 콜백이 설정되었는지 여부를 나타냅니다.

process.hrtime([time])

추가된 버전: v0.7.6

[안정성: 3 - 레거시]

안정성: 3 안정성: 3 - 레거시. 대신 process.hrtime.bigint()를 사용하세요.

• time <integer[]> process.hrtime()을 이전 호출한 결과
• 반환 값: <integer[]>

이것은 JavaScript에 bigint가 도입되기 전의 process.hrtime.bigint()의 레거시 버전입니다.

process.hrtime() 메서드는 현재 고해상도 실시간 시간을 [초, 나노초] 튜플 Array로 반환하며, 여기서 나노초는 초 단위로 나타낼 수 없는 실시간 시간의 나머지 부분입니다.

time은 현재 시간과 차이를 구할 이전 process.hrtime() 호출의 결과여야 하는 선택적 매개변수입니다. 전달된 매개변수가 튜플 Array가 아니면 TypeError가 발생합니다. 이전 process.hrtime() 호출의 결과 대신 사용자 정의 배열을 전달하면 정의되지 않은 동작이 발생합니다.

이러한 시간은 과거의 임의의 시간을 기준으로 하며, 하루 중 시간과 관련이 없으므로 클록 드리프트의 영향을 받지 않습니다. 주요 용도는 간격 사이의 성능을 측정하는 것입니다.

ESM

import { hrtime } from 'node:process'

const NS_PER_SEC = 1e9
const time = hrtime()
// [ 1800216, 25 ]

setTimeout(() => {
  const diff = hrtime(time)
  // [ 1, 552 ]

  console.log(`벤치마크에 ${diff[0] * NS_PER_SEC + diff[1]} 나노초가 걸렸습니다.`)
  // 벤치마크에 1000000552 나노초가 걸렸습니다.
}, 1000)

CJS

const { hrtime } = require('node:process')

const NS_PER_SEC = 1e9
const time = hrtime()
// [ 1800216, 25 ]

setTimeout(() => {
  const diff = hrtime(time)
  // [ 1, 552 ]

  console.log(`벤치마크에 ${diff[0] * NS_PER_SEC + diff[1]} 나노초가 걸렸습니다.`)
  // 벤치마크에 1000000552 나노초가 걸렸습니다.
}, 1000)

process.hrtime.bigint()

추가된 버전: v10.7.0

• 반환값: <bigint>

bigint 버전의 process.hrtime() 메서드는 현재 고해상도 실제 시간을 나노초 단위로 bigint로 반환합니다.

process.hrtime()와 달리, 두 bigint의 차이는 뺄셈으로 직접 계산할 수 있기 때문에 추가적인 time 인자를 지원하지 않습니다.

ESM

import { hrtime } from 'node:process'

const start = hrtime.bigint()
// 191051479007711n

setTimeout(() => {
  const end = hrtime.bigint()
  // 191052633396993n

  console.log(`벤치마크에 ${end - start} 나노초가 걸렸습니다.`)
  // 벤치마크에 1154389282 나노초가 걸렸습니다.
}, 1000)

CJS

const { hrtime } = require('node:process')

const start = hrtime.bigint()
// 191051479007711n

setTimeout(() => {
  const end = hrtime.bigint()
  // 191052633396993n

  console.log(`벤치마크에 ${end - start} 나노초가 걸렸습니다.`)
  // 벤치마크에 1154389282 나노초가 걸렸습니다.
}, 1000)

process.initgroups(user, extraGroup)

추가된 버전: v0.9.4

• user <string> | <number> 사용자 이름 또는 숫자 식별자.
• extraGroup <string> | <number> 그룹 이름 또는 숫자 식별자.

process.initgroups() 메서드는 /etc/group 파일을 읽고 사용자가 멤버인 모든 그룹을 사용하여 그룹 접근 목록을 초기화합니다. 이것은 Node.js 프로세스가 root 접근 권한 또는 CAP_SETGID 기능을 가지고 있어야 하는 권한 있는 작업입니다.

권한을 삭제할 때 주의해야 합니다.

ESM

import { getgroups, initgroups, setgid } from 'node:process'

console.log(getgroups()) // [ 0 ]
initgroups('nodeuser', 1000) // 사용자 전환
console.log(getgroups()) // [ 27, 30, 46, 1000, 0 ]
setgid(1000) // root gid 삭제
console.log(getgroups()) // [ 27, 30, 46, 1000 ]

CJS

const { getgroups, initgroups, setgid } = require('node:process')

console.log(getgroups()) // [ 0 ]
initgroups('nodeuser', 1000) // 사용자 전환
console.log(getgroups()) // [ 27, 30, 46, 1000, 0 ]
setgid(1000) // root gid 삭제
console.log(getgroups()) // [ 27, 30, 46, 1000 ]

이 함수는 POSIX 플랫폼(즉, Windows 또는 Android 제외)에서만 사용할 수 있습니다. 이 기능은 Worker 스레드에서 사용할 수 없습니다.

process.kill(pid[, signal])

Added in: v0.0.6

• pid <number> 프로세스 ID
• signal <string> | <number> 보낼 시그널, 문자열 또는 숫자로 지정. 기본값: 'SIGTERM'.

process.kill() 메서드는 pid로 식별되는 프로세스에 signal을 보냅니다.

시그널 이름은 'SIGINT' 또는 'SIGHUP'과 같은 문자열입니다. 자세한 내용은 시그널 이벤트 및 kill(2)를 참조하십시오.

대상 pid가 존재하지 않으면 이 메서드는 오류를 발생시킵니다. 특수한 경우로, 프로세스 존재 여부를 테스트하는 데 0 시그널을 사용할 수 있습니다. Windows 플랫폼에서는 pid를 사용하여 프로세스 그룹을 종료하려고 하면 오류가 발생합니다.

이 함수의 이름이 process.kill()이지만, 실제로는 kill 시스템 호출과 같이 시그널을 보내는 역할만 합니다. 전송된 시그널은 대상 프로세스를 종료하는 것 외에 다른 작업을 수행할 수도 있습니다.

ESM

import process, { kill } from 'node:process'

process.on('SIGHUP', () => {
  console.log('Got SIGHUP signal.')
})

setTimeout(() => {
  console.log('Exiting.')
  process.exit(0)
}, 100)

kill(process.pid, 'SIGHUP')

CJS

const process = require('node:process')

process.on('SIGHUP', () => {
  console.log('Got SIGHUP signal.')
})

setTimeout(() => {
  console.log('Exiting.')
  process.exit(0)
}, 100)

process.kill(process.pid, 'SIGHUP')

Node.js 프로세스가 SIGUSR1을 받으면 Node.js는 디버거를 시작합니다. 시그널 이벤트를 참조하십시오.

process.loadEnvFile(path)

Added in: v21.7.0, v20.12.0

[Stable: 1 - Experimental]

Stable: 1 Stability: 1.1 - 활발한 개발 중

• path <string> | <URL> | <Buffer> | <undefined>. 기본값: './.env'

.env 파일을 process.env로 로드합니다. .env 파일에서 NODE_OPTIONS을 사용해도 Node.js에는 아무런 영향을 미치지 않습니다.

CJS

const { loadEnvFile } = require('node:process')
loadEnvFile()

ESM

import { loadEnvFile } from 'node:process'
loadEnvFile()

process.mainModule

추가된 버전: v0.1.17

지원 중단된 버전: v14.0.0

[안정성: 0 - 지원 중단됨]

안정성: 0 안정성: 0 - 지원 중단됨: 대신 require.main을 사용하세요.

• <Object>

process.mainModule 속성은 require.main을 검색하는 대안적인 방법을 제공합니다. 차이점은 런타임에 메인 모듈이 변경되는 경우 require.main이 변경이 발생하기 전에 필요했던 모듈에서 원래 메인 모듈을 계속 참조할 수 있다는 것입니다. 일반적으로 두 항목이 동일한 모듈을 참조한다고 가정하는 것이 안전합니다.

require.main과 마찬가지로 항목 스크립트가 없으면 process.mainModule은 undefined가 됩니다.

process.memoryUsage()

[기록]

버전	변경 사항
v13.9.0, v12.17.0	반환된 객체에 arrayBuffers가 추가되었습니다.
v7.2.0	반환된 객체에 external이 추가되었습니다.
v0.1.16	추가된 버전: v0.1.16

• 반환값: <Object>
  • rss <integer>
  • heapTotal <integer>
  • heapUsed <integer>
  • external <integer>
  • arrayBuffers <integer>

바이트 단위로 측정된 Node.js 프로세스의 메모리 사용량을 설명하는 객체를 반환합니다.

ESM

import { memoryUsage } from 'node:process'

console.log(memoryUsage())
// 출력:
// {
//  rss: 4935680,
//  heapTotal: 1826816,
//  heapUsed: 650472,
//  external: 49879,
//  arrayBuffers: 9386
// }

CJS

const { memoryUsage } = require('node:process')

console.log(memoryUsage())
// 출력:
// {
//  rss: 4935680,
//  heapTotal: 1826816,
//  heapUsed: 650472,
//  external: 49879,
//  arrayBuffers: 9386
// }

• heapTotal과 heapUsed는 V8의 메모리 사용량을 나타냅니다.
• external은 V8이 관리하는 JavaScript 객체에 바인딩된 C++ 객체의 메모리 사용량을 나타냅니다.
• rss, Resident Set Size는 모든 C++ 및 JavaScript 객체와 코드를 포함하여 프로세스에 대해 메인 메모리 장치(할당된 총 메모리의 하위 집합)에서 차지하는 공간의 양입니다.
• arrayBuffers는 모든 Node.js Buffer를 포함하여 ArrayBuffers 및 SharedArrayBuffers에 할당된 메모리를 나타냅니다. 이것은 external 값에도 포함됩니다. Node.js를 임베디드 라이브러리로 사용하는 경우 ArrayBuffers에 대한 할당이 해당 경우에 추적되지 않을 수 있으므로 이 값은 0일 수 있습니다.

Worker 스레드를 사용하는 경우 rss는 전체 프로세스에 유효한 값이 되지만 다른 필드는 현재 스레드만 참조합니다.

process.memoryUsage() 메서드는 프로그램 메모리 할당에 따라 느릴 수 있는 메모리 사용량에 대한 정보를 수집하기 위해 각 페이지를 반복합니다.

process.memoryUsage.rss()

추가된 버전: v15.6.0, v14.18.0

• 반환: <정수>

process.memoryUsage.rss() 메서드는 상주 집합 크기(Resident Set Size, RSS)를 바이트 단위로 나타내는 정수를 반환합니다.

상주 집합 크기는 C++ 및 JavaScript 객체와 코드를 포함하여 프로세스에 할당된 총 메모리의 하위 집합인 주 메모리 장치에서 차지하는 공간의 양입니다.

이 값은 process.memoryUsage()에서 제공하는 rss 속성과 동일하지만 process.memoryUsage.rss()가 더 빠릅니다.

ESM

import { memoryUsage } from 'node:process'

console.log(memoryUsage.rss())
// 35655680

CJS

const { memoryUsage } = require('node:process')

console.log(memoryUsage.rss())
// 35655680

process.nextTick(callback[, ...args])

[기록]

버전	변경 사항
v22.7.0, v20.18.0	안정성이 레거시로 변경되었습니다.
v18.0.0	callback 인수에 유효하지 않은 콜백을 전달하면 이제 ERR_INVALID_CALLBACK 대신 ERR_INVALID_ARG_TYPE을 throw합니다.
v1.8.1	callback 뒤에 추가 인수가 지원됩니다.
v0.1.26	추가된 버전: v0.1.26

[안정성: 3 - 레거시]

안정성: 3 안정성: 3 - 레거시: 대신 queueMicrotask()를 사용하세요.

• callback <함수>
• ...args <any> callback을 호출할 때 전달할 추가 인수

process.nextTick()은 callback을 "다음 틱 큐"에 추가합니다. 이 큐는 JavaScript 스택의 현재 작업이 완료된 후, 그리고 이벤트 루프가 계속될 수 있기 전에 완전히 비워집니다. process.nextTick()을 재귀적으로 호출하면 무한 루프를 만들 수 있습니다. 자세한 내용은 이벤트 루프 가이드를 참조하세요.

ESM

import { nextTick } from 'node:process'

console.log('시작')
nextTick(() => {
  console.log('nextTick 콜백')
})
console.log('예약됨')
// 출력:
// 시작
// 예약됨
// nextTick 콜백

CJS

const { nextTick } = require('node:process')

console.log('시작')
nextTick(() => {
  console.log('nextTick 콜백')
})
console.log('예약됨')
// 출력:
// 시작
// 예약됨
// nextTick 콜백

이는 사용자가 객체가 생성된 후이지만 I/O가 발생하기 전에 이벤트 핸들러를 할당할 기회를 제공하기 위해 API를 개발할 때 중요합니다.

ESM

import { nextTick } from 'node:process'

function MyThing(options) {
  this.setupOptions(options)

  nextTick(() => {
    this.startDoingStuff()
  })
}

const thing = new MyThing()
thing.getReadyForStuff()

// thing.startDoingStuff()는 이전이 아니라 지금 호출됩니다.

CJS

const { nextTick } = require('node:process')

function MyThing(options) {
  this.setupOptions(options)

  nextTick(() => {
    this.startDoingStuff()
  })
}

const thing = new MyThing()
thing.getReadyForStuff()

// thing.startDoingStuff()는 이전이 아니라 지금 호출됩니다.

API가 100% 동기 또는 100% 비동기 중 하나여야 하는 것은 매우 중요합니다. 다음 예시를 고려하세요.

// 경고! 사용하지 마세요! 위험합니다!
function maybeSync(arg, cb) {
  if (arg) {
    cb()
    return
  }

  fs.stat('file', cb)
}

이 API는 다음 경우에 위험합니다.

const maybeTrue = Math.random() > 0.5

maybeSync(maybeTrue, () => {
  foo()
})

bar()

foo() 또는 bar() 중 어떤 것이 먼저 호출될지 명확하지 않습니다.

다음 접근 방식이 훨씬 좋습니다.

ESM

import { nextTick } from 'node:process'

function definitelyAsync(arg, cb) {
  if (arg) {
    nextTick(cb)
    return
  }

  fs.stat('file', cb)
}

CJS

const { nextTick } = require('node:process')

function definitelyAsync(arg, cb) {
  if (arg) {
    nextTick(cb)
    return
  }

  fs.stat('file', cb)
}

queueMicrotask() vs. process.nextTick() 사용 시점

queueMicrotask() API는 process.nextTick()의 대안이며, 해결된 Promise의 then, catch, finally 핸들러를 실행하는 데 사용되는 동일한 마이크로태스크 큐를 사용하여 함수의 실행을 지연시킵니다. Node.js 내에서 "다음 틱 큐"가 비워질 때마다 마이크로태스크 큐가 바로 비워집니다.

ESM

import { nextTick } from 'node:process'

Promise.resolve().then(() => console.log(2))
queueMicrotask(() => console.log(3))
nextTick(() => console.log(1))
// 출력:
// 1
// 2
// 3

CJS

const { nextTick } = require('node:process')

Promise.resolve().then(() => console.log(2))
queueMicrotask(() => console.log(3))
nextTick(() => console.log(1))
// 출력:
// 1
// 2
// 3

대부분의 사용자 영역 사용 사례에서 queueMicrotask() API는 여러 JavaScript 플랫폼 환경에서 작동하는 실행 지연을 위한 이식 가능하고 신뢰할 수 있는 메커니즘을 제공하며 process.nextTick()보다 선호되어야 합니다. 간단한 시나리오에서 queueMicrotask()는 process.nextTick()을 대체할 수 있습니다.

console.log('start')
queueMicrotask(() => {
  console.log('microtask callback')
})
console.log('scheduled')
// 출력:
// start
// scheduled
// microtask callback

두 API의 주목할 만한 차이점은 process.nextTick()이 지연된 함수가 호출될 때 인수로 전달될 추가 값을 지정할 수 있다는 것입니다. queueMicrotask()를 사용하여 동일한 결과를 얻으려면 클로저 또는 바인딩된 함수를 사용해야 합니다.

function deferred(a, b) {
  console.log('microtask', a + b)
}

console.log('start')
queueMicrotask(deferred.bind(undefined, 1, 2))
console.log('scheduled')
// 출력:
// start
// scheduled
// microtask 3

다음 틱 큐와 마이크로태스크 큐 내에서 발생한 오류가 처리되는 방식에는 약간의 차이가 있습니다. 큐에 넣은 마이크로태스크 콜백 내에서 발생한 오류는 가능하면 큐에 넣은 콜백 내에서 처리해야 합니다. 그렇지 않은 경우 process.on('uncaughtException') 이벤트 핸들러를 사용하여 오류를 캡처하고 처리할 수 있습니다.

확신이 서지 않으면 process.nextTick()의 특정 기능이 필요한 경우가 아니면 queueMicrotask()를 사용하십시오.

process.noDeprecation

추가된 버전: v0.8.0

• <boolean>

process.noDeprecation 속성은 현재 Node.js 프로세스에 --no-deprecation 플래그가 설정되었는지 여부를 나타냅니다. 이 플래그의 동작에 대한 자세한 내용은 'warning' 이벤트 및 emitWarning() 메서드 문서를 참조하십시오.

process.permission

추가된 버전: v20.0.0

• <Object>

이 API는 --permission 플래그를 통해 사용할 수 있습니다.

process.permission은 현재 프로세스의 권한을 관리하는 데 사용되는 메서드를 가진 객체입니다. 추가 문서는 권한 모델에서 확인할 수 있습니다.

process.permission.has(scope[, reference])

추가된 버전: v20.0.0

• scope <string>
• reference <string>
• 반환값: <boolean>

프로세스가 주어진 범위 및 참조에 액세스할 수 있는지 확인합니다. 참조가 제공되지 않으면 전역 범위로 간주됩니다. 예를 들어 process.permission.has('fs.read')는 프로세스가 모든 파일 시스템 읽기 권한을 가지고 있는지 확인합니다.

참조는 제공된 범위에 따라 의미가 다릅니다. 예를 들어, 범위가 파일 시스템인 경우 참조는 파일 및 폴더를 의미합니다.

사용 가능한 범위는 다음과 같습니다.

• fs - 모든 파일 시스템
• fs.read - 파일 시스템 읽기 작업
• fs.write - 파일 시스템 쓰기 작업
• child - 자식 프로세스 생성 작업
• worker - 워커 스레드 생성 작업

// 프로세스가 README 파일을 읽을 권한이 있는지 확인
process.permission.has('fs.read', './README.md')
// 프로세스가 읽기 권한 작업을 가지고 있는지 확인
process.permission.has('fs.read')

process.pid

추가됨: v0.1.15

• <정수>

process.pid 속성은 프로세스의 PID를 반환합니다.

ESM

import { pid } from 'node:process'

console.log(`이 프로세스의 PID는 ${pid}입니다`)

CJS

const { pid } = require('node:process')

console.log(`이 프로세스의 PID는 ${pid}입니다`)

process.platform

추가됨: v0.1.16

• <문자열>

process.platform 속성은 Node.js 바이너리가 컴파일된 운영 체제 플랫폼을 식별하는 문자열을 반환합니다.

현재 가능한 값은 다음과 같습니다:

• 'aix'
• 'darwin'
• 'freebsd'
• 'linux'
• 'openbsd'
• 'sunos'
• 'win32'

ESM

import { platform } from 'node:process'

console.log(`이 플랫폼은 ${platform}입니다`)

CJS

const { platform } = require('node:process')

console.log(`이 플랫폼은 ${platform}입니다`)

Node.js가 Android 운영 체제에서 빌드된 경우 'android' 값도 반환될 수 있습니다. 그러나 Node.js의 Android 지원은 실험적입니다.

process.ppid

추가됨: v9.2.0, v8.10.0, v6.13.0

• <정수>

process.ppid 속성은 현재 프로세스의 부모의 PID를 반환합니다.

ESM

import { ppid } from 'node:process'

console.log(`부모 프로세스의 PID는 ${ppid}입니다`)

CJS

const { ppid } = require('node:process')

console.log(`부모 프로세스의 PID는 ${ppid}입니다`)

process.release

[기록]

버전	변경 사항
v4.2.0	lts 속성이 이제 지원됩니다.
v3.0.0	추가됨: v3.0.0

• <객체>

process.release 속성은 소스 타르볼 및 헤더 전용 타르볼의 URL을 포함하여 현재 릴리스와 관련된 메타데이터를 포함하는 Object를 반환합니다.

process.release는 다음 속성을 포함합니다:

• name <문자열> 항상 'node' 값이 됩니다.
• sourceUrl <문자열> 현재 릴리스의 소스 코드가 포함된 .tar.gz 파일을 가리키는 절대 URL입니다.
• headersUrl<문자열> 현재 릴리스의 소스 헤더 파일만 포함하는 .tar.gz 파일을 가리키는 절대 URL입니다. 이 파일은 전체 소스 파일보다 훨씬 작으며 Node.js 네이티브 추가 기능을 컴파일하는 데 사용할 수 있습니다.
• libUrl <문자열> | <undefined> 현재 릴리스의 아키텍처 및 버전과 일치하는 node.lib 파일을 가리키는 절대 URL입니다. 이 파일은 Node.js 네이티브 추가 기능을 컴파일하는 데 사용됩니다. 이 속성은 Node.js의 Windows 빌드에만 존재하며 다른 모든 플랫폼에서는 누락됩니다.
• lts <문자열> | <undefined> 이 릴리스의 LTS 레이블을 식별하는 문자열 레이블입니다. 이 속성은 LTS 릴리스에만 존재하며 현재 릴리스를 포함한 다른 모든 릴리스 유형에 대해서는 undefined입니다. 유효한 값에는 더 이상 지원되지 않는 LTS 릴리스 코드 이름을 포함합니다.
  • 14.15.0부터 시작하는 14.x LTS 라인의 경우 'Fermium'.
  • 16.13.0부터 시작하는 16.x LTS 라인의 경우 'Gallium'.
  • 18.12.0부터 시작하는 18.x LTS 라인의 경우 'Hydrogen'. 다른 LTS 릴리스 코드 이름은 Node.js 변경 로그 아카이브를 참조하십시오.

{
  name: 'node',
  lts: 'Hydrogen',
  sourceUrl: 'https://nodejs.org/download/release/v18.12.0/node-v18.12.0.tar.gz',
  headersUrl: 'https://nodejs.org/download/release/v18.12.0/node-v18.12.0-headers.tar.gz',
  libUrl: 'https://nodejs.org/download/release/v18.12.0/win-x64/node.lib'
}

소스 트리의 비 릴리스 버전에서 사용자 정의 빌드의 경우 name 속성만 존재할 수 있습니다. 추가 속성은 존재한다고 의존해서는 안됩니다.

process.report

[기록]

버전	변경 사항
v13.12.0, v12.17.0	이 API는 더 이상 실험적이지 않습니다.
v11.8.0	추가됨: v11.8.0

• <Object>

process.report는 현재 프로세스의 진단 보고서를 생성하는 데 사용되는 메서드가 있는 객체입니다. 추가 문서는 보고서 문서에서 확인할 수 있습니다.

process.report.compact

추가됨: v13.12.0, v12.17.0

• <boolean>

사람이 소비하도록 설계된 기본 다중 행 형식보다 로그 처리 시스템에서 더 쉽게 사용할 수 있는 컴팩트 형식, 단일 행 JSON으로 보고서를 작성합니다.

ESM

import { report } from 'node:process'

console.log(`Reports are compact? ${report.compact}`)

CJS

const { report } = require('node:process')

console.log(`Reports are compact? ${report.compact}`)

process.report.directory

[기록]

버전	변경 사항
v13.12.0, v12.17.0	이 API는 더 이상 실험적이지 않습니다.
v11.12.0	추가됨: v11.12.0

• <string>

보고서가 작성되는 디렉토리입니다. 기본값은 빈 문자열이며, 이는 보고서가 Node.js 프로세스의 현재 작업 디렉토리에 작성됨을 나타냅니다.

ESM

import { report } from 'node:process'

console.log(`Report directory is ${report.directory}`)

CJS

const { report } = require('node:process')

console.log(`Report directory is ${report.directory}`)

process.report.filename

[기록]

버전	변경 사항
v13.12.0, v12.17.0	이 API는 더 이상 실험적이지 않습니다.
v11.12.0	추가됨: v11.12.0

• <string>

보고서가 작성되는 파일 이름입니다. 빈 문자열로 설정하면 출력 파일 이름은 타임스탬프, PID 및 시퀀스 번호로 구성됩니다. 기본값은 빈 문자열입니다.

process.report.filename의 값이 'stdout' 또는 'stderr'로 설정되면 보고서는 각각 프로세스의 stdout 또는 stderr에 작성됩니다.

ESM

import { report } from 'node:process'

console.log(`Report filename is ${report.filename}`)

CJS

const { report } = require('node:process')

console.log(`Report filename is ${report.filename}`)

process.report.getReport([err])

[History]

버전	변경 사항
v13.12.0, v12.17.0	이 API는 더 이상 실험적이지 않습니다.
v11.8.0	추가됨: v11.8.0

• err <Error> JavaScript 스택을 보고하는 데 사용되는 사용자 지정 오류입니다.
• 반환: <Object>

실행 중인 프로세스에 대한 진단 보고서의 JavaScript 객체 표현을 반환합니다. 보고서의 JavaScript 스택 추적은 err가 있는 경우 err에서 가져옵니다.

ESM

import { report } from 'node:process'
import util from 'node:util'

const data = report.getReport()
console.log(data.header.nodejsVersion)

// process.report.writeReport()와 유사합니다.
import fs from 'node:fs'
fs.writeFileSync('my-report.log', util.inspect(data), 'utf8')

CJS

const { report } = require('node:process')
const util = require('node:util')

const data = report.getReport()
console.log(data.header.nodejsVersion)

// process.report.writeReport()와 유사합니다.
const fs = require('node:fs')
fs.writeFileSync('my-report.log', util.inspect(data), 'utf8')

추가 문서는 보고서 문서에서 확인할 수 있습니다.

process.report.reportOnFatalError

[History]

버전	변경 사항
v15.0.0, v14.17.0	이 API는 더 이상 실험적이지 않습니다.
v11.12.0	추가됨: v11.12.0

• <boolean>

true이면 메모리 부족 오류 또는 실패한 C++ 어설션과 같은 치명적인 오류가 발생할 때 진단 보고서가 생성됩니다.

ESM

import { report } from 'node:process'

console.log(`치명적인 오류에 대한 보고서: ${report.reportOnFatalError}`)

CJS

const { report } = require('node:process')

console.log(`치명적인 오류에 대한 보고서: ${report.reportOnFatalError}`)

process.report.reportOnSignal

[History]

버전	변경 사항
v13.12.0, v12.17.0	이 API는 더 이상 실험적이지 않습니다.
v11.12.0	v11.12.0에 추가됨

• <boolean>

true이면, 프로세스가 process.report.signal에 지정된 신호를 수신할 때 진단 보고서가 생성됩니다.

ESM

import { report } from 'node:process'

console.log(`신호에 대한 보고서: ${report.reportOnSignal}`)

CJS

const { report } = require('node:process')

console.log(`신호에 대한 보고서: ${report.reportOnSignal}`)

process.report.reportOnUncaughtException

[History]

버전	변경 사항
v13.12.0, v12.17.0	이 API는 더 이상 실험적이지 않습니다.
v11.12.0	v11.12.0에 추가됨

• <boolean>

true이면, 잡히지 않은 예외에서 진단 보고서가 생성됩니다.

ESM

import { report } from 'node:process'

console.log(`예외에 대한 보고서: ${report.reportOnUncaughtException}`)

CJS

const { report } = require('node:process')

console.log(`예외에 대한 보고서: ${report.reportOnUncaughtException}`)

process.report.excludeEnv

v23.3.0에 추가됨

• <boolean>

true이면 환경 변수 없이 진단 보고서가 생성됩니다.

process.report.signal

[History]

버전	변경 사항
v13.12.0, v12.17.0	이 API는 더 이상 실험적이지 않습니다.
v11.12.0	v11.12.0에 추가됨

• <string>

진단 보고서 생성을 트리거하는 데 사용되는 신호입니다. 기본값은 'SIGUSR2'입니다.

ESM

import { report } from 'node:process'

console.log(`보고서 신호: ${report.signal}`)

CJS

const { report } = require('node:process')

console.log(`보고서 신호: ${report.signal}`)

process.report.writeReport([filename][, err])

[기록]

버전	변경 사항
v13.12.0, v12.17.0	이 API는 더 이상 실험적이지 않습니다.
v11.8.0	v11.8.0에 추가됨

• filename <string> 보고서가 작성되는 파일 이름입니다. 이는 process.report.directory에 지정된 디렉터리 또는 지정되지 않은 경우 Node.js 프로세스의 현재 작업 디렉터리에 추가될 상대 경로여야 합니다.
• err <Error> JavaScript 스택을 보고하는 데 사용되는 사용자 정의 오류입니다.
• 반환 값: <string> 생성된 보고서의 파일 이름을 반환합니다.

진단 보고서를 파일에 씁니다. filename이 제공되지 않으면 기본 파일 이름에는 날짜, 시간, PID 및 시퀀스 번호가 포함됩니다. 보고서의 JavaScript 스택 추적은 존재하는 경우 err에서 가져옵니다.

filename 값이 'stdout' 또는 'stderr'로 설정된 경우 보고서는 각각 프로세스의 stdout 또는 stderr에 기록됩니다.

ESM

import { report } from 'node:process'

report.writeReport()

CJS

const { report } = require('node:process')

report.writeReport()

추가 문서는 보고서 문서에서 확인할 수 있습니다.

process.resourceUsage()

추가된 버전: v12.6.0

• 반환 값: <Object> 현재 프로세스의 리소스 사용량입니다. 이러한 모든 값은 uv_rusage_t 구조체를 반환하는 uv_getrusage 호출에서 가져옵니다.
  • userCPUTime <integer>는 마이크로초 단위로 계산된 ru_utime에 매핑됩니다. process.cpuUsage().user와 동일한 값입니다.
  • systemCPUTime <integer>는 마이크로초 단위로 계산된 ru_stime에 매핑됩니다. process.cpuUsage().system과 동일한 값입니다.
  • maxRSS <integer>는 킬로바이트 단위로 사용된 최대 상주 집합 크기인 ru_maxrss에 매핑됩니다.
  • sharedMemorySize <integer>는 ru_ixrss에 매핑되지만 어떤 플랫폼에서도 지원되지 않습니다.
  • unsharedDataSize <integer>는 ru_idrss에 매핑되지만 어떤 플랫폼에서도 지원되지 않습니다.
  • unsharedStackSize <integer>는 ru_isrss에 매핑되지만 어떤 플랫폼에서도 지원되지 않습니다.
  • minorPageFault <integer>는 프로세스의 마이너 페이지 폴트 수인 ru_minflt에 매핑됩니다. 자세한 내용은 이 기사를 참조하십시오.
  • majorPageFault <integer>는 프로세스의 메이저 페이지 폴트 수인 ru_majflt에 매핑됩니다. 자세한 내용은 이 기사를 참조하십시오. 이 필드는 Windows에서 지원되지 않습니다.
  • swappedOut <integer>는 ru_nswap에 매핑되지만 어떤 플랫폼에서도 지원되지 않습니다.
  • fsRead <integer>는 파일 시스템이 입력을 수행해야 했던 횟수인 ru_inblock에 매핑됩니다.
  • fsWrite <integer>는 파일 시스템이 출력을 수행해야 했던 횟수인 ru_oublock에 매핑됩니다.
  • ipcSent <integer>는 ru_msgsnd에 매핑되지만 어떤 플랫폼에서도 지원되지 않습니다.
  • ipcReceived <integer>는 ru_msgrcv에 매핑되지만 어떤 플랫폼에서도 지원되지 않습니다.
  • signalsCount <integer>는 ru_nsignals에 매핑되지만 어떤 플랫폼에서도 지원되지 않습니다.
  • voluntaryContextSwitches <integer>는 프로세스가 시간 슬라이스가 완료되기 전에 프로세서를 자발적으로 포기(일반적으로 리소스 가용성을 기다리는 경우)하여 발생한 CPU 컨텍스트 스위치 횟수인 ru_nvcsw에 매핑됩니다. 이 필드는 Windows에서 지원되지 않습니다.
  • involuntaryContextSwitches <integer>는 우선 순위가 높은 프로세스가 실행 가능해지거나 현재 프로세스가 시간 슬라이스를 초과했기 때문에 발생한 CPU 컨텍스트 스위치 횟수인 ru_nivcsw에 매핑됩니다. 이 필드는 Windows에서 지원되지 않습니다.

ESM

import { resourceUsage } from 'node:process'

console.log(resourceUsage())
/*
  출력:
  {
    userCPUTime: 82872,
    systemCPUTime: 4143,
    maxRSS: 33164,
    sharedMemorySize: 0,
    unsharedDataSize: 0,
    unsharedStackSize: 0,
    minorPageFault: 2469,
    majorPageFault: 0,
    swappedOut: 0,
    fsRead: 0,
    fsWrite: 8,
    ipcSent: 0,
    ipcReceived: 0,
    signalsCount: 0,
    voluntaryContextSwitches: 79,
    involuntaryContextSwitches: 1
  }
*/

CJS

const { resourceUsage } = require('node:process')

console.log(resourceUsage())
/*
  출력:
  {
    userCPUTime: 82872,
    systemCPUTime: 4143,
    maxRSS: 33164,
    sharedMemorySize: 0,
    unsharedDataSize: 0,
    unsharedStackSize: 0,
    minorPageFault: 2469,
    majorPageFault: 0,
    swappedOut: 0,
    fsRead: 0,
    fsWrite: 8,
    ipcSent: 0,
    ipcReceived: 0,
    signalsCount: 0,
    voluntaryContextSwitches: 79,
    involuntaryContextSwitches: 1
  }
*/

process.send(message[, sendHandle[, options]][, callback])

추가된 버전: v0.5.9

• message <Object>

• sendHandle <net.Server> | <net.Socket>

• options <Object> 특정 유형의 핸들 전송을 매개변수화하는 데 사용됩니다.options는 다음 속성을 지원합니다.

  • keepOpen <boolean> net.Socket 인스턴스를 전달할 때 사용할 수 있는 값입니다. true이면 소켓이 전송 프로세스에서 열린 상태로 유지됩니다. 기본값: false.

• callback <Function>

• 반환 값: <boolean>

IPC 채널을 사용하여 Node.js가 생성된 경우 process.send() 메서드를 사용하여 부모 프로세스에 메시지를 보낼 수 있습니다. 메시지는 부모의 ChildProcess 객체에서 'message' 이벤트로 수신됩니다.

IPC 채널을 사용하여 Node.js가 생성되지 않은 경우 process.send는 undefined가 됩니다.

메시지는 직렬화 및 구문 분석을 거칩니다. 결과 메시지는 원래 전송된 메시지와 다를 수 있습니다.

process.setegid(id)

추가된 버전: v2.0.0

• id <string> | <number> 그룹 이름 또는 ID

process.setegid() 메서드는 프로세스의 유효 그룹 ID를 설정합니다. (setegid(2) 참조) id는 숫자 ID 또는 그룹 이름 문자열로 전달할 수 있습니다. 그룹 이름을 지정하면 이 메서드는 연결된 숫자 ID를 확인하는 동안 차단됩니다.

ESM

import process from 'node:process'

if (process.getegid && process.setegid) {
  console.log(`Current gid: ${process.getegid()}`)
  try {
    process.setegid(501)
    console.log(`New gid: ${process.getegid()}`)
  } catch (err) {
    console.error(`Failed to set gid: ${err}`)
  }
}

CJS

const process = require('node:process')

if (process.getegid && process.setegid) {
  console.log(`Current gid: ${process.getegid()}`)
  try {
    process.setegid(501)
    console.log(`New gid: ${process.getegid()}`)
  } catch (err) {
    console.error(`Failed to set gid: ${err}`)
  }
}

이 함수는 POSIX 플랫폼(즉, Windows 또는 Android가 아님)에서만 사용할 수 있습니다. 이 기능은 Worker 스레드에서 사용할 수 없습니다.

process.seteuid(id)

추가된 버전: v2.0.0

• id <string> | <number> 사용자 이름 또는 ID

process.seteuid() 메서드는 프로세스의 유효 사용자 ID를 설정합니다. (seteuid(2)를 참조하세요.) id는 숫자 ID 또는 사용자 이름 문자열로 전달될 수 있습니다. 사용자 이름이 지정된 경우, 이 메서드는 관련 숫자 ID를 확인하는 동안 차단됩니다.

ESM

import process from 'node:process'

if (process.geteuid && process.seteuid) {
  console.log(`현재 uid: ${process.geteuid()}`)
  try {
    process.seteuid(501)
    console.log(`새 uid: ${process.geteuid()}`)
  } catch (err) {
    console.error(`uid 설정 실패: ${err}`)
  }
}

CJS

const process = require('node:process')

if (process.geteuid && process.seteuid) {
  console.log(`현재 uid: ${process.geteuid()}`)
  try {
    process.seteuid(501)
    console.log(`새 uid: ${process.geteuid()}`)
  } catch (err) {
    console.error(`uid 설정 실패: ${err}`)
  }
}

이 함수는 POSIX 플랫폼(즉, Windows 또는 Android가 아님)에서만 사용할 수 있습니다. 이 기능은 Worker 스레드에서는 사용할 수 없습니다.

process.setgid(id)

추가된 버전: v0.1.31

• id <string> | <number> 그룹 이름 또는 ID

process.setgid() 메서드는 프로세스의 그룹 ID를 설정합니다. (setgid(2)를 참조하세요.) id는 숫자 ID 또는 그룹 이름 문자열로 전달될 수 있습니다. 그룹 이름이 지정된 경우, 이 메서드는 관련 숫자 ID를 확인하는 동안 차단됩니다.

ESM

import process from 'node:process'

if (process.getgid && process.setgid) {
  console.log(`현재 gid: ${process.getgid()}`)
  try {
    process.setgid(501)
    console.log(`새 gid: ${process.getgid()}`)
  } catch (err) {
    console.error(`gid 설정 실패: ${err}`)
  }
}

CJS

const process = require('node:process')

if (process.getgid && process.setgid) {
  console.log(`현재 gid: ${process.getgid()}`)
  try {
    process.setgid(501)
    console.log(`새 gid: ${process.getgid()}`)
  } catch (err) {
    console.error(`gid 설정 실패: ${err}`)
  }
}

이 함수는 POSIX 플랫폼(즉, Windows 또는 Android가 아님)에서만 사용할 수 있습니다. 이 기능은 Worker 스레드에서는 사용할 수 없습니다.

process.setgroups(groups)

추가된 버전: v0.9.4

• groups <정수[]>

process.setgroups() 메서드는 Node.js 프로세스의 보조 그룹 ID를 설정합니다. 이는 Node.js 프로세스가 root 또는 CAP_SETGID 기능을 가져야 하는 권한 있는 작업입니다.

groups 배열에는 숫자 그룹 ID, 그룹 이름 또는 둘 다 포함될 수 있습니다.

ESM

import process from 'node:process'

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501])
    console.log(process.getgroups()) // 새 그룹
  } catch (err) {
    console.error(`그룹 설정에 실패했습니다: ${err}`)
  }
}

CJS

const process = require('node:process')

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501])
    console.log(process.getgroups()) // 새 그룹
  } catch (err) {
    console.error(`그룹 설정에 실패했습니다: ${err}`)
  }
}

이 함수는 POSIX 플랫폼(즉, Windows 또는 Android 아님)에서만 사용할 수 있습니다. 이 기능은 Worker 스레드에서 사용할 수 없습니다.

process.setuid(id)

추가된 버전: v0.1.28

• id <정수> | <문자열>

process.setuid(id) 메서드는 프로세스의 사용자 ID를 설정합니다. (참조: setuid(2).) id는 숫자 ID 또는 사용자 이름 문자열로 전달할 수 있습니다. 사용자 이름을 지정하면 메서드는 연결된 숫자 ID를 확인하는 동안 차단됩니다.

ESM

import process from 'node:process'

if (process.getuid && process.setuid) {
  console.log(`현재 uid: ${process.getuid()}`)
  try {
    process.setuid(501)
    console.log(`새 uid: ${process.getuid()}`)
  } catch (err) {
    console.error(`uid 설정에 실패했습니다: ${err}`)
  }
}

CJS

const process = require('node:process')

if (process.getuid && process.setuid) {
  console.log(`현재 uid: ${process.getuid()}`)
  try {
    process.setuid(501)
    console.log(`새 uid: ${process.getuid()}`)
  } catch (err) {
    console.error(`uid 설정에 실패했습니다: ${err}`)
  }
}

이 함수는 POSIX 플랫폼(즉, Windows 또는 Android 아님)에서만 사용할 수 있습니다. 이 기능은 Worker 스레드에서 사용할 수 없습니다.

process.setSourceMapsEnabled(val)

Added in: v16.6.0, v14.18.0

[안정성: 1 - 실험적]

안정성: 1 안정성: 1 - 실험적

• val <boolean>

이 함수는 스택 추적에 대한 소스 맵 v3 지원을 활성화 또는 비활성화합니다.

--enable-source-maps 명령줄 옵션으로 Node.js 프로세스를 시작하는 것과 동일한 기능을 제공합니다.

소스 맵이 활성화된 후에 로드되는 JavaScript 파일의 소스 맵만 구문 분석되고 로드됩니다.

process.setUncaughtExceptionCaptureCallback(fn)

Added in: v9.3.0

• fn <Function> | <null>

process.setUncaughtExceptionCaptureCallback() 함수는 포착되지 않은 예외가 발생할 때 호출되는 함수를 설정합니다. 이 함수는 첫 번째 인수로 예외 값 자체를 받습니다.

이러한 함수가 설정되면 'uncaughtException' 이벤트가 발생하지 않습니다. 명령줄에서 --abort-on-uncaught-exception이 전달되었거나 v8.setFlagsFromString()을 통해 설정된 경우 프로세스가 중단되지 않습니다. 보고서 생성과 같이 예외 발생 시 수행되도록 구성된 작업도 영향을 받습니다.

캡처 함수를 해제하려면 process.setUncaughtExceptionCaptureCallback(null)을 사용할 수 있습니다. 다른 캡처 함수가 설정된 상태에서 null이 아닌 인수로 이 메서드를 호출하면 오류가 발생합니다.

이 함수를 사용하는 것은 더 이상 사용되지 않는 domain 내장 모듈을 사용하는 것과 상호 배타적입니다.

process.sourceMapsEnabled

Added in: v20.7.0, v18.19.0

[안정성: 1 - 실험적]

안정성: 1 안정성: 1 - 실험적

• <boolean>

process.sourceMapsEnabled 속성은 스택 추적에 대한 소스 맵 v3 지원이 활성화되어 있는지 여부를 반환합니다.

process.stderr

• <Stream>

process.stderr 속성은 stderr(fd 2)에 연결된 스트림을 반환합니다. fd 2가 파일을 참조하지 않는 경우 net.Socket (즉, Duplex 스트림)이지만, 파일을 참조하는 경우 Writable 스트림입니다.

process.stderr는 중요한 면에서 다른 Node.js 스트림과 다릅니다. 자세한 내용은 프로세스 I/O에 대한 참고 사항을 참조하십시오.

process.stderr.fd

• <number>

이 속성은 process.stderr의 기본 파일 설명자의 값을 나타냅니다. 값은 2로 고정되어 있습니다. Worker 스레드에서는 이 필드가 존재하지 않습니다.

process.stdin

• <Stream>

process.stdin 속성은 stdin(fd 0)에 연결된 스트림을 반환합니다. fd 0이 파일을 참조하지 않는 경우 net.Socket (즉, Duplex 스트림)이지만, 파일을 참조하는 경우 Readable 스트림입니다.

stdin에서 읽는 방법에 대한 자세한 내용은 readable.read()를 참조하십시오.

Duplex 스트림으로서, process.stdin은 v0.10 이전의 Node.js용으로 작성된 스크립트와 호환되는 "이전" 모드에서도 사용할 수 있습니다. 자세한 내용은 스트림 호환성을 참조하십시오.

"이전" 스트림 모드에서 stdin 스트림은 기본적으로 일시 중지되므로 읽으려면 process.stdin.resume()을 호출해야 합니다. 또한 process.stdin.resume()을 호출하면 스트림이 "이전" 모드로 전환됩니다.

process.stdin.fd

• <number>

이 속성은 process.stdin의 기본 파일 설명자의 값을 나타냅니다. 값은 0으로 고정되어 있습니다. Worker 스레드에서는 이 필드가 존재하지 않습니다.

process.stdout

• <Stream>

process.stdout 속성은 stdout(fd 1)에 연결된 스트림을 반환합니다. fd 1이 파일을 참조하는 경우가 아니면 net.Socket (Duplex 스트림)입니다. 그렇지 않으면 Writable 스트림입니다.

예를 들어 process.stdin을 process.stdout에 복사하려면 다음을 수행합니다.

ESM

import { stdin, stdout } from 'node:process'

stdin.pipe(stdout)

CJS

const { stdin, stdout } = require('node:process')

stdin.pipe(stdout)

process.stdout는 다른 Node.js 스트림과 중요한 면에서 다릅니다. 자세한 내용은 process I/O 관련 참고 사항을 참조하세요.

process.stdout.fd

• <number>

이 속성은 process.stdout의 기본 파일 설명자 값을 참조합니다. 이 값은 1로 고정되어 있습니다. Worker 스레드에서는 이 필드가 존재하지 않습니다.

process I/O 관련 참고 사항

process.stdout 및 process.stderr는 다른 Node.js 스트림과 중요한 면에서 다릅니다.

이러한 동작은 부분적으로 과거의 이유 때문이며, 이를 변경하면 이전 버전과의 호환성이 깨지기 때문이지만 일부 사용자가 예상하는 동작이기도 합니다.

동기식 쓰기는 console.log() 또는 console.error()로 작성된 출력이 예기치 않게 인터리브되거나 비동기식 쓰기가 완료되기 전에 process.exit()가 호출되는 경우 전혀 작성되지 않는 등의 문제를 피합니다. 자세한 내용은 process.exit()를 참조하세요.

경고: 동기식 쓰기는 쓰기가 완료될 때까지 이벤트 루프를 차단합니다. 파일에 대한 출력의 경우 거의 즉각적일 수 있지만, 시스템 부하가 높거나, 수신 측에서 읽지 않는 파이프 또는 느린 터미널이나 파일 시스템의 경우 이벤트 루프가 자주, 그리고 길게 차단되어 성능에 심각한 부정적 영향을 미칠 수 있습니다. 대화형 터미널 세션에 쓸 때는 문제가 되지 않을 수 있지만, 특히 프로세스 출력 스트림에 프로덕션 로깅을 할 때는 주의해야 합니다.

스트림이 TTY 컨텍스트에 연결되어 있는지 확인하려면 isTTY 속성을 확인하세요.

예를 들어 다음과 같습니다.

$ node -p "Boolean(process.stdin.isTTY)"
true
$ echo "foo" | node -p "Boolean(process.stdin.isTTY)"
false
$ node -p "Boolean(process.stdout.isTTY)"
true
$ node -p "Boolean(process.stdout.isTTY)" | cat
false

자세한 내용은 TTY 문서를 참조하세요.

process.throwDeprecation

추가된 버전: v0.9.12

• <boolean>

process.throwDeprecation의 초기 값은 현재 Node.js 프로세스에 --throw-deprecation 플래그가 설정되었는지 여부를 나타냅니다. process.throwDeprecation은 변경 가능하므로, 더 이상 사용되지 않는 경고가 오류로 이어질지 여부는 런타임에 변경될 수 있습니다. 자세한 내용은 'warning' 이벤트 및 emitWarning() 메서드에 대한 문서를 참조하십시오.

$ node --throw-deprecation -p "process.throwDeprecation"
true
$ node -p "process.throwDeprecation"
undefined
$ node
> process.emitWarning('test', 'DeprecationWarning');
undefined
> (node:26598) DeprecationWarning: test
> process.throwDeprecation = true;
true
> process.emitWarning('test', 'DeprecationWarning');
Thrown:
[DeprecationWarning: test] { name: 'DeprecationWarning' }

process.title

추가된 버전: v0.1.104

• <string>

process.title 속성은 현재 프로세스 제목을 반환합니다(예: ps의 현재 값을 반환). process.title에 새 값을 할당하면 ps의 현재 값이 수정됩니다.

새 값이 할당되면 플랫폼마다 제목에 다른 최대 길이 제한이 적용됩니다. 일반적으로 이러한 제한은 상당히 제한적입니다. 예를 들어 Linux 및 macOS에서 process.title은 바이너리 이름의 크기와 명령줄 인수의 길이로 제한됩니다. process.title을 설정하면 프로세스의 argv 메모리를 덮어쓰기 때문입니다. Node.js v0.8에서는 environ 메모리도 덮어씀으로써 더 긴 프로세스 제목 문자열을 허용했지만 일부 ( 다소 모호한) 경우에 잠재적으로 안전하지 않고 혼란스러울 수 있었습니다.

process.title에 값을 할당해도 macOS 활동 모니터 또는 Windows 서비스 관리자와 같은 프로세스 관리자 애플리케이션 내에서 정확한 레이블이 생성되지 않을 수 있습니다.

process.traceDeprecation

추가된 버전: v0.8.0

• <boolean>

process.traceDeprecation 속성은 현재 Node.js 프로세스에서 --trace-deprecation 플래그가 설정되었는지 여부를 나타냅니다. 이 플래그의 동작에 대한 자세한 내용은 'warning' 이벤트 및 emitWarning() 메서드에 대한 문서를 참조하십시오.

process.umask()

[기록]

버전	변경 사항
v14.0.0, v12.19.0	인자 없이 process.umask()를 호출하는 것은 더 이상 사용되지 않습니다.
v0.1.19	추가된 버전: v0.1.19

[안정성: 0 - 더 이상 사용되지 않음]

안정성: 0 안정성: 0 - 더 이상 사용되지 않습니다. 인자 없이 process.umask()를 호출하면 프로세스 전체 umask가 두 번 기록됩니다. 이로 인해 스레드 간에 경합 조건이 발생하고 잠재적인 보안 취약점이 발생합니다. 안전하고 플랫폼 간 대안 API가 없습니다.

process.umask()는 Node.js 프로세스의 파일 모드 생성 마스크를 반환합니다. 자식 프로세스는 부모 프로세스에서 마스크를 상속합니다.

process.umask(mask)

추가된 버전: v0.1.19

• mask <string> | <integer>

process.umask(mask)는 Node.js 프로세스의 파일 모드 생성 마스크를 설정합니다. 자식 프로세스는 부모 프로세스에서 마스크를 상속합니다. 이전 마스크를 반환합니다.

ESM

import { umask } from 'node:process'

const newmask = 0o022
const oldmask = umask(newmask)
console.log(`Changed umask from ${oldmask.toString(8)} to ${newmask.toString(8)}`)

CJS

const { umask } = require('node:process')

const newmask = 0o022
const oldmask = umask(newmask)
console.log(`Changed umask from ${oldmask.toString(8)} to ${newmask.toString(8)}`)

Worker 스레드에서 process.umask(mask)는 예외를 throw합니다.

process.uptime()

추가된 버전: v0.5.0

• 반환값: <number>

process.uptime() 메서드는 현재 Node.js 프로세스가 실행된 시간을 초 단위로 반환합니다.

반환 값에는 초의 소수점 이하 값이 포함됩니다. 정수 초를 얻으려면 Math.floor()를 사용하세요.

process.version

추가된 버전: v0.1.3

• <string>

process.version 속성은 Node.js 버전 문자열을 포함합니다.

ESM

import { version } from 'node:process'

console.log(`Version: ${version}`)
// Version: v14.8.0

CJS

const { version } = require('node:process')

console.log(`Version: ${version}`)
// Version: v14.8.0

접두사 v 없이 버전 문자열을 얻으려면 process.versions.node를 사용하세요.

process.versions

[기록]

버전	변경 사항
v9.0.0	v8 속성이 이제 Node.js 특정 접미사를 포함합니다.
v4.2.0	icu 속성이 이제 지원됩니다.
v0.2.0	추가된 버전: v0.2.0

• <Object>

process.versions 속성은 Node.js와 그 종속성의 버전 문자열을 나열하는 객체를 반환합니다. process.versions.modules는 C++ API가 변경될 때마다 증가하는 현재 ABI 버전을 나타냅니다. Node.js는 다른 모듈 ABI 버전으로 컴파일된 모듈을 로드하지 않습니다.

ESM

import { versions } from 'node:process'

console.log(versions)

CJS

const { versions } = require('node:process')

console.log(versions)

다음과 유사한 객체를 생성합니다.

{ node: '23.0.0',
  acorn: '8.11.3',
  ada: '2.7.8',
  ares: '1.28.1',
  base64: '0.5.2',
  brotli: '1.1.0',
  cjs_module_lexer: '1.2.2',
  cldr: '45.0',
  icu: '75.1',
  llhttp: '9.2.1',
  modules: '127',
  napi: '9',
  nghttp2: '1.61.0',
  nghttp3: '0.7.0',
  ngtcp2: '1.3.0',
  openssl: '3.0.13+quic',
  simdjson: '3.8.0',
  simdutf: '5.2.4',
  sqlite: '3.46.0',
  tz: '2024a',
  undici: '6.13.0',
  unicode: '15.1',
  uv: '1.48.0',
  uvwasi: '0.0.20',
  v8: '12.4.254.14-node.11',
  zlib: '1.3.0.1-motley-7d77fb7' }

종료 코드

Node.js는 일반적으로 더 이상 비동기 작업이 보류 중이지 않으면 0 상태 코드로 종료됩니다. 다른 경우에는 다음 상태 코드가 사용됩니다.

• 1 포착되지 않은 치명적 예외: 포착되지 않은 예외가 발생했으며, 도메인이나 'uncaughtException' 이벤트 핸들러에서 처리되지 않았습니다.
• 2: 사용되지 않음 (Bash에서 내장 오용을 위해 예약됨)
• 3 내부 JavaScript 구문 분석 오류: Node.js 부트스트래핑 프로세스 내부의 JavaScript 소스 코드에서 구문 분석 오류가 발생했습니다. 이는 매우 드물며 일반적으로 Node.js 자체 개발 중에만 발생할 수 있습니다.
• 4 내부 JavaScript 평가 실패: Node.js 부트스트래핑 프로세스 내부의 JavaScript 소스 코드가 평가될 때 함수 값을 반환하지 못했습니다. 이는 매우 드물며 일반적으로 Node.js 자체 개발 중에만 발생할 수 있습니다.
• 5 치명적인 오류: V8에 복구할 수 없는 치명적인 오류가 발생했습니다. 일반적으로 FATAL ERROR 접두사가 붙은 메시지가 stderr에 인쇄됩니다.
• 6 함수가 아닌 내부 예외 핸들러: 포착되지 않은 예외가 발생했지만 내부 치명적 예외 핸들러 함수가 어떻게든 함수가 아닌 것으로 설정되어 호출할 수 없었습니다.
• 7 내부 예외 핸들러 런타임 실패: 포착되지 않은 예외가 발생했고 내부 치명적 예외 핸들러 함수 자체가 처리하려고 시도하는 동안 오류를 던졌습니다. 이는 예를 들어 'uncaughtException' 또는 domain.on('error') 핸들러가 오류를 던지는 경우에 발생할 수 있습니다.
• 8: 사용되지 않음. 이전 버전의 Node.js에서는 종료 코드 8이 때때로 포착되지 않은 예외를 나타냈습니다.
• 9 잘못된 인수: 알 수 없는 옵션이 지정되었거나 값을 요구하는 옵션이 값 없이 제공되었습니다.
• 10 내부 JavaScript 런타임 실패: Node.js 부트스트래핑 프로세스 내부의 JavaScript 소스 코드가 부트스트래핑 함수가 호출될 때 오류를 던졌습니다. 이는 매우 드물며 일반적으로 Node.js 자체 개발 중에만 발생할 수 있습니다.
• 12 잘못된 디버그 인수: --inspect 및/또는 --inspect-brk 옵션이 설정되었지만 선택한 포트 번호가 유효하지 않거나 사용할 수 없습니다.
• 13 해결되지 않은 최상위 await: await가 최상위 코드의 함수 외부에서 사용되었지만 전달된 Promise가 해결되지 않았습니다.
• 14 스냅샷 실패: Node.js가 V8 시작 스냅샷을 빌드하기 위해 시작되었지만 응용 프로그램 상태의 특정 요구 사항이 충족되지 않아 실패했습니다.
• >128 신호 종료: Node.js가 SIGKILL 또는 SIGHUP과 같은 치명적인 신호를 받으면 종료 코드는 128에 신호 코드 값을 더한 값이 됩니다. 이는 종료 코드가 7비트 정수로 정의되고 신호 종료가 상위 비트를 설정한 다음 신호 코드 값을 포함하기 때문에 표준 POSIX 관행입니다. 예를 들어, SIGABRT 신호 값은 6이므로 예상되는 종료 코드는 128 + 6 또는 134입니다.