Ver3.5 JavaScript 코드 품질 관리와 ESLint · Prettier 완전 정복 가이드

JavaScript 코드 품질 관리와 ESLint · Prettier 완전 정복 가이드
야 솔직히 말해봐 ㅋㅋㅋ 혼자 개발할 때 코드 스타일 신경 쓴 적 있어?
변수명은 camelCase였다가 snake_case였다가, 세미콜론은 있다가 없다가, 들여쓰기는 2칸이었다가 4칸이었다가... 😅
그러다 팀 프로젝트 들어가면 진짜 대참사 나는 거 알지? ㅋㅋㅋ
근데 이게 단순히 "보기 싫다"의 문제가 아니야. 코드 품질은 버그 발생률, 유지보수 비용, 팀 생산성에 직결되는 진짜 중요한 이슈거든.
오늘은 JavaScript 개발자라면 반드시 알아야 할 ESLint와 Prettier를 제대로 파헤쳐볼게! 🔥
먼저 "코드 품질"이 뭔지부터 제대로 짚고 가자.
코드 품질은 단순히 "돌아가냐 안 돌아가냐"의 문제가 아니야. 아래 요소들을 종합적으로 봐야 해.
1. 가독성 (Readability)
다른 사람이 (혹은 3개월 후의 나 자신이) 코드를 읽었을 때 바로 이해할 수 있어야 해.
변수명이 a, b, temp1 이런 거면... 진짜 나중에 본인도 모름 ㅋㅋㅋ
2. 유지보수성 (Maintainability)
기능 추가하거나 버그 수정할 때 다른 부분을 건드리지 않고 안전하게 수정할 수 있어야 해.
스파게티 코드는 진짜 손대기 무서움... 😱
3. 일관성 (Consistency)
팀 전체가 같은 스타일로 코드를 작성해야 해.
어떤 파일은 세미콜론 있고, 어떤 파일은 없고... 이러면 코드 리뷰가 지옥이 됨 ㅠㅠ
4. 안전성 (Safety)
잠재적인 버그나 보안 취약점이 없어야 해.
== 대신 === 써야 하는 이유, ESLint가 알려줌!
코드 품질에 투자하는 게 장기적으로 훨씬 이득이라는 거 수치로도 증명된 거야!
그래서 등장한 게 바로 린터(Linter)와 포매터(Formatter)야.
JavaScript 생태계에서 가장 널리 쓰이는 조합이 바로 ESLint + Prettier인데,
이 둘은 역할이 달라서 같이 쓰면 시너지가 엄청남! 🔥
ESLint는 2013년 Nicholas C. Zakas가 만든 JavaScript 정적 분석 도구야.
"정적 분석"이라는 게 뭐냐면, 코드를 실제로 실행하지 않고도 문제를 찾아내는 거야.
마치 맞춤법 검사기처럼 코드를 쭉 훑으면서 "야 이거 이상한데?" 하고 알려주는 거지 ㅋㅋㅋ
Node.js 프로젝트에서 ESLint 설치는 이렇게 해:
# npm 사용 시
npm install --save-dev eslint
# yarn 사용 시
yarn add --dev eslint
# pnpm 사용 시
pnpm add --save-dev eslint
설치 후 초기 설정 파일 생성:
# ESLint 9.x 이상 (Flat Config 방식)
npx eslint --init
# 또는 직접 설정 파일 생성
touch eslint.config.js
ESLint 9.x 버전부터는 Flat Config 방식이 기본이야.
기존의 .eslintrc.js 방식에서 eslint.config.js로 바뀐 거야.
// eslint.config.js (ESLint 9.x Flat Config)
import js from "@eslint/js";
export default [
js.configs.recommended,
{
rules: {
// 미사용 변수 경고
"no-unused-vars": "warn",
// console.log 경고
"no-console": "warn",
// === 사용 강제
"eqeqeq": "error",
// var 사용 금지
"no-var": "error",
// const 선호
"prefer-const": "warn",
}
}
];
구버전 방식 (.eslintrc.js)도 아직 많이 쓰이니까 알아두자:
// .eslintrc.js (구버전 방식)
module.exports = {
env: {
browser: true,
es2021: true,
node: true,
},
extends: [
"eslint:recommended",
],
parserOptions: {
ecmaVersion: "latest",
sourceType: "module",
},
rules: {
"no-unused-vars": "warn",
"no-console": "warn",
"eqeqeq": "error",
"no-var": "error",
"prefer-const": "warn",
},
};
ESLint 규칙에는 3가지 레벨이 있어:
| 레벨 | 값 | 의미 | 동작 |
|---|---|---|---|
| 🔕 off | 0 | 규칙 비활성화 | 아무것도 안 함 |
| ⚠️ warn | 1 | 경고 | 노란 경고 표시, 빌드는 됨 |
| 🚨 error | 2 | 오류 | 빨간 오류 표시, CI/CD 실패 |
error로 설정된 규칙을 위반하면 eslint 명령어가 exit code 1로 종료돼.CI/CD 파이프라인에서 빌드가 실패하게 되니까 팀에서 어떤 규칙을 error로 할지 신중하게 결정해야 해!
변수 관련:
{
"no-unused-vars": "warn", // 미사용 변수 경고
"no-undef": "error", // 미정의 변수 사용 금지
"no-var": "error", // var 사용 금지 (let/const 사용)
"prefer-const": "warn", // 재할당 없으면 const 권장
"no-shadow": "warn", // 상위 스코프 변수 가리기 금지
}
코드 품질 관련:
{
"eqeqeq": ["error", "always"], // === 사용 강제
"no-console": "warn", // console.log 경고
"no-debugger": "error", // debugger 사용 금지
"no-alert": "warn", // alert 경고
"no-eval": "error", // eval() 사용 금지 (보안!)
"no-implied-eval": "error", // 암묵적 eval 금지
}
ES6+ 관련:
{
"arrow-body-style": ["warn", "as-needed"], // 화살표 함수 간결하게
"prefer-arrow-callback": "warn", // 콜백에 화살표 함수 권장
"prefer-template": "warn", // 템플릿 리터럴 권장
"object-shorthand": "warn", // 객체 단축 표기 권장
"no-duplicate-imports": "error", // 중복 import 금지
}
ESLint의 진짜 강점은 플러그인 생태계야!
React, TypeScript, Vue 등 다양한 환경에 맞는 플러그인이 있어:
# React 프로젝트용
npm install --save-dev eslint-plugin-react eslint-plugin-react-hooks
# TypeScript 프로젝트용
npm install --save-dev @typescript-eslint/parser @typescript-eslint/eslint-plugin
# Import 관련
npm install --save-dev eslint-plugin-import
# 접근성 관련
npm install --save-dev eslint-plugin-jsx-a11y
React 프로젝트 설정 예시:
// .eslintrc.js (React + TypeScript)
module.exports = {
extends: [
"eslint:recommended",
"plugin:react/recommended",
"plugin:react-hooks/recommended",
"plugin:@typescript-eslint/recommended",
],
plugins: ["react", "react-hooks", "@typescript-eslint"],
parser: "@typescript-eslint/parser",
settings: {
react: {
version: "detect", // React 버전 자동 감지
},
},
rules: {
"react/react-in-jsx-scope": "off", // React 17+ 불필요
"react/prop-types": "off", // TypeScript 사용 시 불필요
},
};
# 현재 디렉토리 전체 검사
npx eslint .
# 특정 파일 검사
npx eslint src/index.js
# 자동 수정 가능한 오류 자동 수정
npx eslint . --fix
# 특정 확장자만 검사
npx eslint . --ext .js,.jsx,.ts,.tsx
package.json에 스크립트 추가해두면 편해:
{
"scripts": {
"lint": "eslint .",
"lint:fix": "eslint . --fix"
}
}
Prettier는 2017년 James Long이 만든 Opinionated Code Formatter야.
"Opinionated"라는 게 핵심인데, 이건 "우리가 이미 결정해놨으니까 너는 그냥 따라와" 라는 뜻이야 ㅋㅋㅋ
ESLint가 "이 코드 이상해요!" 라고 알려주는 거라면,
Prettier는 "내가 그냥 다 고쳐줄게!" 하고 코드를 자동으로 포맷팅해주는 거야.
진짜 편함... 😍
탭이냐 스페이스냐, 세미콜론이냐 아니냐... 이런 소모적인 논쟁 대신 Prettier가 정해주는 대로 따르면 돼!
# npm
npm install --save-dev prettier
# yarn
yarn add --dev prettier
# pnpm
pnpm add --save-dev prettier
설정 파일 생성 (.prettierrc 또는 prettier.config.js):
// .prettierrc (JSON 형식)
{
"semi": true,
"singleQuote": true,
"tabWidth": 2,
"useTabs": false,
"printWidth": 80,
"trailingComma": "es5",
"bracketSpacing": true,
"arrowParens": "always"
}
또는 JS 형식으로:
// prettier.config.js
module.exports = {
semi: true, // 세미콜론 사용
singleQuote: true, // 작은따옴표 사용
tabWidth: 2, // 들여쓰기 2칸
useTabs: false, // 탭 대신 스페이스
printWidth: 80, // 한 줄 최대 80자
trailingComma: "es5", // ES5 호환 후행 쉼표
bracketSpacing: true, // 객체 괄호 안 공백
arrowParens: "always",// 화살표 함수 매개변수 괄호
};
| 옵션 | 기본값 | 설명 |
|---|---|---|
printWidth |
80 | 한 줄 최대 글자 수 |
tabWidth |
2 | 들여쓰기 칸 수 |
useTabs |
false | 탭 문자 사용 여부 |
semi |
true | 세미콜론 사용 여부 |
singleQuote |
false | 작은따옴표 사용 여부 |
trailingComma |
"all" | 후행 쉼표 (none/es5/all) |
bracketSpacing |
true | 객체 괄호 내 공백 |
arrowParens |
"always" | 화살표 함수 매개변수 괄호 |
endOfLine |
"lf" | 줄바꿈 문자 (lf/crlf/cr/auto) |
포맷팅 전 (엉망진창 ㅋㅋㅋ):
const obj={name:'홍길동',age:25,job:'개발자'}
const greet=(name)=>{return `안녕하세요, ${name}님!`}
function add(a,b){
return a+b
}
const arr=[1,2,3,4,5]
if(arr.length>0){console.log('배열에 요소가 있어요')}
포맷팅 후 (Prettier 적용):
const obj = { name: '홍길동', age: 25, job: '개발자' };
const greet = (name) => {
return `안녕하세요, ${name}님!`;
};
function add(a, b) {
return a + b;
}
const arr = [1, 2, 3, 4, 5];
if (arr.length > 0) {
console.log('배열에 요소가 있어요');
}
훨씬 읽기 편하지? 이게 자동으로 되는 거야! 😎
# 특정 파일 포맷팅
npx prettier --write src/index.js
# 전체 파일 포맷팅
npx prettier --write .
# 포맷팅 확인만 (수정 안 함)
npx prettier --check .
# 특정 확장자만
npx prettier --write "src/**/*.{js,jsx,ts,tsx,css,json}"
package.json 스크립트:
{
"scripts": {
"format": "prettier --write .",
"format:check": "prettier --check ."
}
}
포맷팅에서 제외할 파일/폴더를 지정할 수 있어:
# .prettierignore
node_modules
dist
build
.next
coverage
*.min.js
public/
ESLint와 Prettier를 같이 쓸 때 문제가 생길 수 있어.
왜냐면 ESLint도 일부 포맷팅 규칙을 가지고 있거든.
예를 들어 들여쓰기 규칙 같은 거... 이게 Prettier 설정이랑 충돌하면 진짜 난리남 ㅋㅋㅋ
이 문제를 해결하는 방법이 있어!
방법 1: eslint-config-prettier 사용 (권장!)
# 설치
npm install --save-dev eslint-config-prettier
// .eslintrc.js
module.exports = {
extends: [
"eslint:recommended",
"prettier", // 반드시 마지막에 추가! Prettier와 충돌하는 ESLint 규칙 비활성화
],
rules: {
// 여기에는 포맷팅 관련 규칙 넣지 말기!
// 로직/품질 관련 규칙만 넣기
"no-unused-vars": "warn",
"eqeqeq": "error",
},
};
방법 2: eslint-plugin-prettier 사용
# 설치
npm install --save-dev eslint-plugin-prettier eslint-config-prettier
// .eslintrc.js
module.exports = {
extends: [
"eslint:recommended",
"plugin:prettier/recommended", // 이 한 줄로 해결!
],
};
Prettier 공식 문서에서는
eslint-config-prettier만 사용하고,ESLint와 Prettier를 별도로 실행하는 방식을 권장해.
eslint-plugin-prettier는 편리하지만 성능이 약간 느릴 수 있어.
// .eslintrc.js
module.exports = {
env: {
browser: true,
es2021: true,
node: true,
},
extends: [
"eslint:recommended",
"plugin:react/recommended",
"plugin:react-hooks/recommended",
"plugin:@typescript-eslint/recommended",
"prettier", // 항상 마지막!
],
parser: "@typescript-eslint/parser",
parserOptions: {
ecmaVersion: "latest",
sourceType: "module",
ecmaFeatures: {
jsx: true,
},
},
plugins: ["react", "react-hooks", "@typescript-eslint"],
settings: {
react: { version: "detect" },
},
rules: {
"react/react-in-jsx-scope": "off",
"react/prop-types": "off",
"@typescript-eslint/no-unused-vars": "warn",
"@typescript-eslint/explicit-function-return-type": "off",
"no-console": ["warn", { allow: ["warn", "error"] }],
"eqeqeq": "error",
"prefer-const": "warn",
},
};
// .prettierrc
{
"semi": true,
"singleQuote": true,
"tabWidth": 2,
"useTabs": false,
"printWidth": 100,
"trailingComma": "es5",
"bracketSpacing": true,
"arrowParens": "always",
"endOfLine": "lf"
}
매번 터미널에서 명령어 치는 거 귀찮잖아 ㅋㅋㅋ
VS Code에서 파일 저장할 때 자동으로 ESLint 검사하고 Prettier 포맷팅 되게 설정해보자!
VS Code 마켓플레이스에서 아래 두 개 설치해:
ESLint - dbaeumer.vscode-eslint
Prettier - esbenp.prettier-vscode
프로젝트 루트에 .vscode/settings.json 파일 만들어:
{
// 저장 시 자동 포맷팅
"editor.formatOnSave": true,
// 기본 포매터를 Prettier로 설정
"editor.defaultFormatter": "esbenp.prettier-vscode",
// 저장 시 ESLint 자동 수정
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
},
// JavaScript/TypeScript에서 Prettier 사용
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[javascriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
// ESLint 검사할 파일 타입
"eslint.validate": [
"javascript",
"javascriptreact",
"typescript",
"typescriptreact"
]
}
이제 파일 저장하면 자동으로 포맷팅되고 ESLint 오류도 자동 수정돼! 🎉
VS Code 설정은 개인 설정이라 팀원이 안 따를 수도 있잖아 ㅋㅋㅋ
그래서 Git Hooks를 사용해서 커밋 전에 자동으로 검사하게 만들어버리는 거야!
이러면 품질 안 좋은 코드는 아예 커밋이 안 됨 😈
Husky: Git Hooks를 쉽게 관리해주는 도구
lint-staged: 스테이징된 파일에만 린트 실행 (전체 파일 검사하면 너무 느리니까)
# 설치
npm install --save-dev husky lint-staged
# Husky 초기화
npx husky init
이러면 .husky/ 폴더가 생기고 pre-commit 파일이 만들어져.
# .husky/pre-commit
npx lint-staged
package.json에 lint-staged 설정 추가:
{
"lint-staged": {
"*.{js,jsx,ts,tsx}": [
"eslint --fix",
"prettier --write"
],
"*.{css,scss,json,md}": [
"prettier --write"
]
}
}
git commit 할 때마다 자동으로 ESLint 검사 + Prettier 포맷팅이 실행돼!오류가 있으면 커밋이 실패하고, 자동 수정 가능한 건 수정 후 커밋돼. 팀 코드 품질 유지에 최고야!
커밋 메시지 컨벤션도 강제하고 싶다면 commitlint를 추가해:
# 설치
npm install --save-dev @commitlint/cli @commitlint/config-conventional
# commitlint 설정
echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
# .husky/commit-msg
npx --no -- commitlint --edit $1
이제 커밋 메시지도 feat:, fix:, docs: 같은 형식을 따라야 해!
# 올바른 커밋 메시지 예시
git commit -m "feat: 로그인 기능 추가"
git commit -m "fix: 버튼 클릭 이벤트 오류 수정"
git commit -m "docs: README 업데이트"
git commit -m "refactor: 인증 로직 리팩토링"
로컬에서 검사하는 것도 중요하지만, CI/CD에서도 검사해야 완벽해!
GitHub Actions 예시를 보여줄게:
# .github/workflows/code-quality.yml
name: Code Quality Check
on:
push:
branches: [main, develop]
pull_request:
branches: [main, develop]
jobs:
lint-and-format:
runs-on: ubuntu-latest
steps:
- name: 코드 체크아웃
uses: actions/checkout@v4
- name: Node.js 설정
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- name: 의존성 설치
run: npm ci
- name: ESLint 검사
run: npm run lint
- name: Prettier 포맷 확인
run: npm run format:check
이제 PR 올릴 때마다 자동으로 코드 품질 검사가 실행돼!
검사 실패하면 머지 못 하게 막을 수도 있어. 팀 코드 품질 관리 완벽 ✅
가끔은 특정 줄에서 규칙을 무시해야 할 때가 있어:
// 다음 줄 전체 규칙 비활성화
// eslint-disable-next-line
console.log('디버깅용');
// 특정 규칙만 비활성화
// eslint-disable-next-line no-console
console.log('디버깅용');
// 블록 전체 비활성화 (남용 금지!)
/* eslint-disable no-console */
console.log('여러 줄');
console.log('비활성화');
/* eslint-enable no-console */
// 파일 전체 비활성화 (진짜 남용 금지!!)
/* eslint-disable */
eslint-disable은 진짜 필요할 때만 써야 해!남용하면 ESLint 쓰는 의미가 없어짐 ㅋㅋㅋ 코드 리뷰에서 지적받을 수 있어.
문제 1: ESLint와 Prettier 들여쓰기 충돌
// 잘못된 설정 - ESLint에 indent 규칙이 있으면 충돌!
rules: {
"indent": ["error", 2], // 이거 지워야 해!
}
// 올바른 설정 - prettier가 들여쓰기 담당
// ESLint에서 indent 규칙 제거하고 prettier에서 tabWidth 설정
문제 2: 줄 끝 문자 (CRLF vs LF) 문제
// .prettierrc
{
"endOfLine": "lf" // Windows에서도 LF 사용
}
// .gitattributes
* text=auto eol=lf
문제 3: TypeScript 파일에서 ESLint 파서 오류
// .eslintrc.js
module.exports = {
parser: "@typescript-eslint/parser", // 이거 꼭 추가!
parserOptions: {
project: "./tsconfig.json", // TypeScript 설정 파일 경로
},
};
프로젝트가 커지면 ESLint 실행이 느려질 수 있어. 이렇게 해결해:
// .eslintrc.js - 성능 최적화
module.exports = {
// 캐시 사용 (CLI에서 --cache 옵션)
// npx eslint . --cache
// 불필요한 파일 제외
ignorePatterns: [
"node_modules/",
"dist/",
"build/",
"*.min.js",
"coverage/",
],
};
# package.json scripts
{
"scripts": {
"lint": "eslint . --cache", // --cache 옵션으로 속도 향상
"lint:fix": "eslint . --cache --fix"
}
}
Next.js는 자체 ESLint 설정을 제공해:
# Next.js 프로젝트 생성 시 자동 설정됨
# 수동으로 추가할 경우:
npm install --save-dev eslint-config-next
// .eslintrc.js
module.exports = {
extends: [
"next/core-web-vitals", // Next.js 권장 설정
"prettier",
],
rules: {
// 추가 규칙
},
};
npm install --save-dev eslint-plugin-vue
// .eslintrc.js
module.exports = {
extends: [
"eslint:recommended",
"plugin:vue/vue3-recommended", // Vue 3 권장 설정
"prettier",
],
parser: "vue-eslint-parser",
parserOptions: {
parser: "@babel/eslint-parser",
requireConfigFile: false,
},
};
npm install --save-dev @typescript-eslint/parser @typescript-eslint/eslint-plugin
// .eslintrc.js
module.exports = {
extends: [
"eslint:recommended",
"plugin:@typescript-eslint/recommended",
"plugin:@typescript-eslint/recommended-requiring-type-checking",
"prettier",
],
parser: "@typescript-eslint/parser",
parserOptions: {
project: true,
tsconfigRootDir: __dirname,
},
rules: {
"@typescript-eslint/no-explicit-any": "warn",
"@typescript-eslint/no-floating-promises": "error",
},
};
ESLint와 Prettier는 코드 품질 관리의 시작이야.
더 넓은 관점에서 보면 이런 도구들도 함께 쓰면 좋아:
| 도구 | 역할 | 특징 |
|---|---|---|
| ESLint | 정적 분석 / 린팅 | 코드 오류 및 패턴 검사 |
| Prettier | 코드 포맷팅 | 스타일 자동 통일 |
| TypeScript | 타입 검사 | 컴파일 타임 오류 방지 |
| Jest / Vitest | 단위 테스트 | 기능 동작 검증 |
| SonarQube | 코드 품질 분석 | 복잡도, 중복 코드 분석 |
| Husky | Git Hooks 관리 | 커밋 전 자동 검사 |
도구를 설정해놓고 끝이 아니라, 팀 전체가 왜 이 규칙이 필요한지 이해하고 따르는 게 중요해.
재능넷 같은 플랫폼에서 개발 관련 재능을 거래할 때도,
ESLint/Prettier 설정이 잘 되어있는 프로젝트를 납품하면 클라이언트 만족도가 훨씬 높아!
코드 품질은 프로 개발자의 기본 소양이니까 꼭 챙기자 💪
자 이제 ESLint와 Prettier에 대해 꽤 깊게 알아봤어!
처음에는 설정하는 게 귀찮고 복잡하게 느껴질 수 있어.
근데 한 번 제대로 설정해놓으면 그 다음부터는 자동으로 다 해줘서 진짜 편함 ㅋㅋㅋ 😄
ESLint 코드의 논리적 오류와 패턴을 검사하는 린터
Prettier 코드 스타일을 자동으로 통일해주는 포매터
eslint-config-prettier 두 도구의 충돌을 방지하는 설정
Husky + lint-staged 커밋 전 자동 검사로 품질 강제
GitHub Actions CI/CD에서 코드 품질 자동 검증
개발 실력을 키우고 싶다면 재능넷에서 JavaScript 관련 멘토링이나 코드 리뷰 서비스를 찾아보는 것도 좋은 방법이야!
경험 많은 개발자에게 직접 피드백 받으면 성장 속도가 훨씬 빨라지거든 😊
코드 품질 관리는 단순히 "예쁜 코드"를 위한 게 아니야.
버그를 줄이고, 팀 생산성을 높이고, 유지보수 비용을 절감하는 실질적인 가치가 있어.
오늘 배운 내용으로 프로젝트에 바로 적용해봐! 처음엔 어색해도 금방 익숙해질 거야 💪
나중에 기존 코드에 적용하면 수백 개의 오류가 한꺼번에 뜨는 지옥을 경험하게 됨 ㅋㅋㅋ 😅
관련 키워드
댓글 작성
이 글에 대한 여러분의 생각을 들려주세요
로그인이 필요합니다
댓글을 작성하려면 먼저 로그인해주세요.
댓글 0
지식인의 숲 - 지적 재산권 보호 고지
지적 재산권 보호 고지
- 저작권 및 소유권: 본 컨텐츠는 재능넷의 독점 AI 기술로 생성되었으며, 대한민국 저작권법 및 국제 저작권 협약에 의해 보호됩니다.
- AI 생성 컨텐츠의 법적 지위: 본 AI 생성 컨텐츠는 재능넷의 지적 창작물로 인정되며, 관련 법규에 따라 저작권 보호를 받습니다.
- 사용 제한: 재능넷의 명시적 서면 동의 없이 본 컨텐츠를 복제, 수정, 배포, 또는 상업적으로 활용하는 행위는 엄격히 금지됩니다.
- 데이터 수집 금지: 본 컨텐츠에 대한 무단 스크래핑, 크롤링, 및 자동화된 데이터 수집은 법적 제재의 대상이 됩니다.
- AI 학습 제한: 재능넷의 AI 생성 컨텐츠를 타 AI 모델 학습에 무단 사용하는 행위는 금지되며, 이는 지적 재산권 침해로 간주됩니다.
아직 댓글이 없습니다.