이미지 로딩 중...
AI Generated
2025. 11. 9. · 2 Views
타입스크립트로 비트코인 클론하기 2편 - Node.js 개발 환경 설정하기
비트코인 클론 프로젝트를 위한 Node.js와 TypeScript 개발 환경을 구축하는 방법을 배웁니다. 프로젝트 초기화부터 타입스크립트 설정, 필수 패키지 설치까지 실무에서 바로 사용할 수 있는 환경 설정 가이드를 제공합니다.
목차
- Node.js 프로젝트 초기화
- TypeScript 설치 및 설정
- 개발 편의를 위한 ts-node 설정
- nodemon으로 자동 재시작
- 프로젝트 디렉토리 구조
- ESLint와 Prettier 설정
- Git 설정과 .gitignore
1. Node.js 프로젝트 초기화
시작하며
여러분이 새로운 타입스크립트 프로젝트를 시작할 때 가장 먼저 해야 할 일이 무엇일까요? 많은 초보 개발자들이 이 단계를 건너뛰고 바로 코딩을 시작하다가 나중에 의존성 관리나 빌드 설정에서 문제를 겪곤 합니다.
Node.js 프로젝트의 모든 것은 package.json에서 시작됩니다. 이 파일은 프로젝트의 설계도이자 메타데이터를 담고 있는 핵심 파일입니다.
프로젝트 이름, 버전, 의존성, 실행 스크립트 등 모든 정보가 여기에 담깁니다. 제대로 된 프로젝트 초기화는 향후 몇 달, 몇 년간 유지보수할 프로젝트의 기초를 다지는 중요한 작업입니다.
지금부터 비트코인 클론 프로젝트를 위한 완벽한 초기화 방법을 알아보겠습니다.
개요
간단히 말해서, npm init은 Node.js 프로젝트의 package.json 파일을 생성하는 명령어입니다. 실무에서는 프로젝트마다 수십 개의 외부 라이브러리를 사용하게 됩니다.
이런 의존성들을 관리하고, 팀원들과 동일한 개발 환경을 공유하기 위해서는 표준화된 프로젝트 설정이 필수입니다. package.json은 바로 이런 역할을 담당합니다.
기존에는 수동으로 package.json을 작성해야 했다면, 이제는 npm init 명령어로 대화형 인터페이스를 통해 쉽게 생성할 수 있습니다. -y 옵션을 사용하면 기본값으로 즉시 생성할 수도 있습니다.
핵심 특징은 첫째, 프로젝트 메타데이터를 구조화하여 관리하고, 둘째, 의존성 버전을 명확히 기록하며, 셋째, 실행 스크립트를 정의할 수 있다는 점입니다. 이러한 특징들이 협업 개발과 배포 자동화를 가능하게 만듭니다.
코드 예제
# 프로젝트 디렉토리 생성 및 이동
mkdir bitcoin-clone-typescript
cd bitcoin-clone-typescript
# package.json 생성 (대화형)
npm init
# 또는 기본값으로 즉시 생성
npm init -y
# 생성된 package.json 확인
cat package.json
설명
이것이 하는 일: npm init은 대화형 질문을 통해 프로젝트 정보를 수집하고, 그 정보를 바탕으로 package.json 파일을 자동 생성합니다. 첫 번째로, mkdir와 cd 명령어로 프로젝트 전용 디렉토리를 생성하고 이동합니다.
모든 프로젝트 파일을 한 곳에 모아두는 것은 파일 관리의 기본입니다. 이렇게 하면 나중에 여러 프로젝트를 동시에 관리할 때 혼란을 방지할 수 있습니다.
그 다음으로, npm init을 실행하면 프로젝트 이름, 버전, 설명, 진입점(entry point), 저자 등을 묻는 대화형 프롬프트가 나타납니다. 각 질문에 답하거나 Enter를 눌러 기본값을 사용할 수 있습니다.
-y 옵션을 사용하면 모든 질문을 건너뛰고 기본값으로 package.json을 즉시 생성합니다. 마지막으로, 생성된 package.json 파일에는 프로젝트 이름, 버전(기본 1.0.0), main 파일(기본 index.js), scripts 섹션 등이 포함됩니다.
이 파일은 JSON 형식이므로 언제든지 텍스트 에디터로 수정할 수 있습니다. 여러분이 이 명령어를 사용하면 표준화된 프로젝트 구조를 갖출 수 있고, npm을 통한 패키지 관리가 가능해지며, 다른 개발자들이 여러분의 프로젝트를 쉽게 이해하고 사용할 수 있게 됩니다.
특히 팀 프로젝트에서는 package.json이 있어야 npm install 명령어 하나로 모든 의존성을 설치할 수 있습니다.
실전 팁
💡 npm init -y로 빠르게 생성한 후, 필요한 부분만 package.json 파일을 직접 수정하는 것이 더 효율적입니다.
💡 프로젝트 이름은 소문자와 하이픈만 사용하세요. 대문자나 공백은 npm 패키지 규칙에 어긋나 나중에 문제가 될 수 있습니다.
💡 "private": true를 package.json에 추가하면 실수로 npm 공개 저장소에 배포되는 것을 방지할 수 있습니다.
💡 version 필드는 시맨틱 버저닝(Semantic Versioning)을 따르세요. major.minor.patch 형식으로 관리하면 버전 관리가 명확해집니다.
2. TypeScript 설치 및 설정
시작하며
여러분이 자바스크립트로 대규모 프로젝트를 개발하다 보면 이런 경험을 하게 됩니다. "이 함수의 매개변수 타입이 뭐였지?", "왜 여기서 undefined 에러가 나지?", "리팩토링 했더니 여기저기서 에러가 터지네?".
이런 문제들은 타입 시스템의 부재에서 비롯됩니다. 타입스크립트는 이런 문제를 근본적으로 해결합니다.
코드를 작성하는 시점에 타입 오류를 잡아내고, IDE의 자동완성과 리팩토링 기능을 강력하게 지원하며, 코드의 의도를 명확히 표현할 수 있게 해줍니다. 비트코인 클론 프로젝트처럼 복잡한 로직과 데이터 구조를 다루는 경우, 타입스크립트는 선택이 아닌 필수입니다.
지금부터 타입스크립트를 프로젝트에 도입하는 완벽한 방법을 알아보겠습니다.
개요
간단히 말해서, TypeScript는 자바스크립트에 정적 타입 시스템을 추가한 프로그래밍 언어입니다. 실무에서는 수천 줄의 코드를 다루게 되는데, 이때 타입 시스템이 없으면 코드의 안정성을 보장하기 어렵습니다.
타입스크립트를 사용하면 컴파일 시점에 타입 오류를 발견할 수 있어 런타임 에러를 크게 줄일 수 있습니다. 예를 들어, 블록체인의 트랜잭션 데이터 구조를 다룰 때 타입이 명확하지 않으면 잘못된 데이터가 들어가도 알아채기 어렵습니다.
기존에는 JSDoc 주석으로 타입 정보를 표현했다면, 이제는 타입스크립트의 강력한 타입 시스템으로 컴파일러 수준에서 타입 안정성을 보장받을 수 있습니다. 핵심 특징은 첫째, 정적 타입 검사로 버그를 조기에 발견하고, 둘째, 최신 자바스크립트 문법을 구버전 브라우저에서도 동작하도록 변환하며, 셋째, IDE에서 뛰어난 개발자 경험(DX)을 제공한다는 점입니다.
이러한 특징들이 대규모 프로젝트의 유지보수성을 극적으로 향상시킵니다.
코드 예제
# TypeScript를 개발 의존성으로 설치
npm install --save-dev typescript
# @types/node 설치 (Node.js API 타입 정의)
npm install --save-dev @types/node
# tsconfig.json 생성
npx tsc --init
# 생성된 tsconfig.json 확인
cat tsconfig.json
설명
이것이 하는 일: TypeScript 컴파일러와 Node.js 타입 정의를 설치한 후, 프로젝트에 맞는 컴파일 설정을 구성합니다. 첫 번째로, npm install --save-dev typescript 명령어로 타입스크립트 컴파일러를 개발 의존성으로 설치합니다.
--save-dev 옵션은 이 패키지가 개발 시에만 필요하고 프로덕션 환경에서는 불필요함을 나타냅니다. 타입스크립트는 자바스크립트로 컴파일되므로 실행 환경에서는 필요하지 않습니다.
그 다음으로, @types/node를 설치합니다. Node.js는 원래 자바스크립트로 작성되었기 때문에 타입 정보가 없습니다.
@types/node는 Node.js의 모든 API(fs, path, http 등)에 대한 타입 정의를 제공하여, 타입스크립트에서 Node.js API를 사용할 때 자동완성과 타입 검사를 가능하게 합니다. 마지막으로, npx tsc --init으로 tsconfig.json 파일을 생성합니다.
이 파일은 타입스크립트 컴파일러의 동작 방식을 제어하는 설정 파일입니다. 기본 생성되는 파일에는 수많은 옵션이 주석 처리되어 있으며, 프로젝트 요구사항에 맞게 주석을 해제하고 값을 조정할 수 있습니다.
여러분이 이 설정을 완료하면 .ts 확장자의 타입스크립트 파일을 작성할 수 있고, tsc 명령어로 자바스크립트로 컴파일할 수 있으며, VSCode 같은 IDE에서 강력한 타입 지원을 받을 수 있습니다. 특히 리팩토링 시 타입스크립트가 자동으로 에러를 알려주어 실수를 크게 줄일 수 있습니다.
실전 팁
💡 tsconfig.json에서 "strict": true를 활성화하세요. 처음엔 에러가 많이 나겠지만, 이것이 타입 안정성을 최대한 보장하는 방법입니다.
💡 "outDir": "./dist"와 "rootDir": "./src"를 설정하여 소스 파일과 컴파일된 파일을 분리하면 프로젝트 구조가 깔끔해집니다.
💡 "esModuleInterop": true를 활성화하면 CommonJS 모듈을 import 할 때 문법이 더 자연스러워집니다.
💡 "resolveJsonModule": true를 추가하면 JSON 파일을 타입 안전하게 import 할 수 있어 설정 파일 관리가 편해집니다.
💡 매번 tsc를 실행하기 번거롭다면 "watch": true 모드나 다음에 설명할 ts-node를 활용하세요.
3. 개발 편의를 위한 ts-node 설정
시작하며
여러분이 타입스크립트로 개발하다 보면 이런 불편함을 느끼게 됩니다. 코드를 조금 수정할 때마다 tsc로 컴파일하고, 그 다음 node로 실행하는 과정을 반복해야 합니다.
"고작 한 줄 고쳤는데 왜 이렇게 번거롭지?"라는 생각이 들 때가 많습니다. 이런 문제는 개발 속도를 크게 저하시킵니다.
빠른 피드백 루프는 개발 생산성의 핵심인데, 매번 컴파일 단계를 거치면 집중력이 떨어지고 개발 흐름이 끊깁니다. 바로 이럴 때 필요한 것이 ts-node입니다.
타입스크립트 파일을 컴파일 없이 바로 실행할 수 있게 해주어, 마치 자바스크립트처럼 빠르게 개발할 수 있습니다.
개요
간단히 말해서, ts-node는 타입스크립트 파일을 즉시 실행할 수 있게 해주는 실행 환경입니다. 실무에서는 빠른 반복 개발이 중요합니다.
특히 블록체인 로직을 개발하면서 해시 함수를 테스트하거나, 트랜잭션 검증 로직을 확인할 때 매번 컴파일하는 것은 비효율적입니다. ts-node를 사용하면 타입스크립트를 메모리상에서 즉시 컴파일하고 실행하여 개발 속도를 크게 높일 수 있습니다.
기존에는 tsc로 컴파일한 후 node로 실행했다면, 이제는 ts-node 하나로 두 단계를 한 번에 처리할 수 있습니다. JIT(Just-In-Time) 컴파일 방식으로 동작하여 별도의 빌드 산출물을 생성하지 않습니다.
핵심 특징은 첫째, 컴파일 단계를 건너뛰고 즉시 실행 가능하고, 둘째, tsconfig.json 설정을 자동으로 인식하며, 셋째, REPL(Read-Eval-Print Loop) 모드를 지원한다는 점입니다. 이러한 특징들이 개발 중 빠른 실험과 디버깅을 가능하게 만듭니다.
코드 예제
# ts-node 설치
npm install --save-dev ts-node
# tsconfig.json에 ts-node 설정 추가 (선택사항)
{
"ts-node": {
"transpileOnly": true,
"files": true
},
"compilerOptions": {
// 기존 설정들...
}
}
# 타입스크립트 파일 직접 실행
npx ts-node src/index.ts
설명
이것이 하는 일: ts-node는 타입스크립트 코드를 메모리에서 즉시 자바스크립트로 변환하고 Node.js로 실행합니다. 첫 번째로, npm install --save-dev ts-node로 패키지를 설치합니다.
이것은 개발 도구이므로 역시 devDependencies에 추가됩니다. ts-node는 내부적으로 타입스크립트 컴파일러를 사용하므로, 앞서 설치한 typescript 패키지에 의존합니다.
그 다음으로, tsconfig.json에 ts-node 전용 설정을 추가할 수 있습니다. "transpileOnly": true 옵션은 타입 검사를 건너뛰고 변환만 수행하여 실행 속도를 높입니다.
타입 검사는 IDE나 별도의 tsc --noEmit 명령어로 수행하면 되므로, 실행 시에는 속도를 우선하는 것이 좋습니다. "files": true는 tsconfig.json의 files, include, exclude 설정을 존중하도록 합니다.
마지막으로, npx ts-node src/index.ts 명령어로 타입스크립트 파일을 직접 실행합니다. npx는 로컬에 설치된 패키지의 실행 파일을 찾아 실행하는 npm의 도구입니다.
이 명령어는 index.ts를 읽어 자바스크립트로 변환한 후 즉시 실행하며, dist 폴더 같은 빌드 산출물을 생성하지 않습니다. 여러분이 ts-node를 사용하면 코드 수정 후 즉시 결과를 확인할 수 있어 개발 속도가 빨라지고, 작은 테스트 코드를 빠르게 실험할 수 있으며, REPL 모드(npx ts-node)로 대화형 타입스크립트 환경을 사용할 수도 있습니다.
다만 프로덕션 배포 시에는 반드시 tsc로 컴파일한 자바스크립트를 사용해야 합니다.
실전 팁
💡 package.json의 scripts에 "dev": "ts-node src/index.ts"를 추가하면 npm run dev로 간편하게 실행할 수 있습니다.
💡 transpileOnly 모드를 사용할 때는 별도로 tsc --noEmit을 주기적으로 실행하여 타입 에러를 확인하세요.
💡 ts-node --esm 옵션을 사용하면 ES 모듈 방식의 타입스크립트를 실행할 수 있습니다.
💡 성능이 중요한 경우 ts-node 대신 swc나 esbuild 기반의 실행 도구를 고려해보세요. tsx 패키지가 좋은 대안입니다.
4. nodemon으로 자동 재시작
시작하며
여러분이 개발 서버를 띄워놓고 코드를 수정할 때마다 서버를 수동으로 재시작해본 경험이 있나요? 터미널에서 Ctrl+C로 종료하고, 다시 실행 명령어를 입력하는 과정을 하루에 수십 번 반복하게 됩니다.
이것은 시간 낭비일 뿐만 아니라 개발 흐름을 계속 끊는 주요 원인입니다. 특히 API 서버를 개발하거나 블록체인 노드를 구현할 때는 수정 사항을 빠르게 확인해야 합니다.
한 줄 고칠 때마다 수동으로 재시작한다면 개발 속도가 크게 느려지고, 작은 수정을 테스트하는 것조차 번거로워집니다. 바로 이럴 때 필요한 것이 nodemon입니다.
파일 변경을 감지하여 자동으로 애플리케이션을 재시작해주므로, 코드 수정에만 집중할 수 있습니다.
개요
간단히 말해서, nodemon은 파일 변경을 감지하여 Node.js 애플리케이션을 자동으로 재시작해주는 개발 도구입니다. 실무에서는 개발 생산성이 프로젝트 성공의 핵심 요소입니다.
수백 개의 파일로 구성된 블록체인 프로젝트에서 블록 검증 로직을 수정하거나, P2P 네트워크 코드를 개선할 때 매번 수동으로 재시작하는 것은 비현실적입니다. nodemon을 사용하면 파일을 저장하는 순간 자동으로 재시작되어 즉시 결과를 확인할 수 있습니다.
기존에는 파일 저장 → 터미널로 이동 → 프로세스 종료 → 재실행의 4단계를 거쳤다면, 이제는 파일 저장만 하면 나머지는 자동으로 처리됩니다. 핵심 특징은 첫째, 파일 시스템 변경을 실시간으로 감지하고, 둘째, 특정 파일이나 디렉토리만 감시하도록 설정 가능하며, 셋째, ts-node 같은 다른 실행 도구와 함께 사용할 수 있다는 점입니다.
이러한 특징들이 개발 워크플로우를 크게 개선합니다.
코드 예제
# nodemon 설치
npm install --save-dev nodemon
# package.json에 스크립트 추가
{
"scripts": {
"dev": "nodemon --exec ts-node src/index.ts",
"dev:watch": "nodemon --watch src --ext ts --exec ts-node src/index.ts"
}
}
# nodemon 실행
npm run dev
설명
이것이 하는 일: nodemon은 지정된 디렉토리의 파일 변경을 감시하다가, 변경이 감지되면 현재 실행 중인 프로세스를 종료하고 새로운 프로세스를 시작합니다. 첫 번째로, npm install --save-dev nodemon으로 패키지를 설치합니다.
nodemon은 순수하게 개발 편의를 위한 도구이므로 프로덕션 환경에서는 사용하지 않습니다. 프로덕션에서는 PM2 같은 프로세스 매니저를 사용합니다.
그 다음으로, package.json의 scripts 섹션에 nodemon 실행 명령어를 정의합니다. --exec 옵션은 nodemon이 실행할 명령어를 지정하는데, 여기서는 ts-node를 사용하여 타입스크립트를 직접 실행합니다.
--watch 옵션으로 감시할 디렉토리를 명시하고, --ext로 감시할 파일 확장자를 지정할 수 있습니다. 예를 들어 --ext ts,json은 .ts와 .json 파일의 변경을 모두 감지합니다.
마지막으로, npm run dev를 실행하면 nodemon이 시작되어 src 디렉토리를 감시합니다. 이제 VSCode나 다른 에디터에서 파일을 수정하고 저장하면, 터미널에서 "restarting due to changes..." 메시지와 함께 자동으로 재시작되는 것을 볼 수 있습니다.
여러분이 nodemon을 사용하면 코드 수정 후 즉시 결과를 확인할 수 있어 피드백 루프가 빨라지고, 에디터에만 집중할 수 있어 몰입도가 높아지며, node_modules 같은 불필요한 디렉토리는 자동으로 무시하여 성능도 최적화됩니다. 개발 경험이 극적으로 향상되는 것을 느낄 수 있을 것입니다.
실전 팁
💡 nodemon.json 파일을 만들어 세밀한 설정을 관리하세요. ignore 패턴, delay 시간 등을 프로젝트에 맞게 조정할 수 있습니다.
💡 --delay 옵션으로 재시작 전 대기 시간을 설정하면, 여러 파일을 빠르게 수정할 때 불필요한 재시작을 방지할 수 있습니다.
💡 로그 파일이나 데이터베이스 파일 변경으로 재시작되지 않도록 --ignore 옵션을 활용하세요.
💡 nodemon --inspect로 실행하면 Chrome DevTools를 사용한 디버깅이 가능합니다.
💡 환경변수 변경 시에도 재시작하려면 --watch .env를 추가하세요.
5. 프로젝트 디렉토리 구조
시작하며
여러분이 프로젝트를 시작할 때 모든 파일을 루트 디렉토리에 넣고 개발하다 보면, 얼마 지나지 않아 어디에 무엇이 있는지 찾기 어려워집니다. "블록 클래스가 어디 있었지?", "트랜잭션 검증 함수는 어느 파일에?", 이런 질문을 스스로에게 하게 됩니다.
잘 조직된 디렉토리 구조는 코드를 찾는 시간을 줄이고, 새로운 기능을 추가할 위치를 명확히 하며, 팀원들이 프로젝트를 빠르게 이해할 수 있게 합니다. 특히 블록체인처럼 복잡한 시스템에서는 체계적인 구조가 필수입니다.
지금부터 비트코인 클론 프로젝트에 최적화된, 확장 가능하고 유지보수하기 쉬운 디렉토리 구조를 설계해보겠습니다.
개요
간단히 말해서, 프로젝트 디렉토리 구조는 코드, 설정, 테스트, 빌드 산출물 등을 체계적으로 분리하여 관리하는 파일 시스템 레이아웃입니다. 실무에서는 수십 개의 클래스와 모듈이 서로 의존하면서 복잡한 시스템을 형성합니다.
블록체인 프로젝트의 경우 블록, 트랜잭션, 지갑, P2P 네트워크, 합의 알고리즘 등 여러 도메인이 있고, 각각은 다시 여러 파일로 나뉩니다. 이런 파일들을 논리적으로 그룹화하지 않으면 프로젝트가 금방 관리 불가능한 상태가 됩니다.
기존에는 파일명으로만 구분하거나 기능별로 엉성하게 분류했다면, 이제는 명확한 폴더 구조와 네이밍 컨벤션으로 코드의 위치를 예측 가능하게 만들 수 있습니다. 핵심 특징은 첫째, 관심사의 분리(Separation of Concerns)를 물리적으로 구현하고, 둘째, 모듈 간 의존성을 디렉토리 구조로 시각화하며, 셋째, 새로운 팀원이 쉽게 온보딩할 수 있는 명확한 규칙을 제공한다는 점입니다.
코드 예제
bitcoin-clone-typescript/
├── src/
│ ├── core/ # 핵심 블록체인 로직
│ │ ├── Block.ts
│ │ ├── Blockchain.ts
│ │ └── Transaction.ts
│ ├── wallet/ # 지갑 관련
│ │ └── Wallet.ts
│ ├── network/ # P2P 네트워크
│ │ └── Node.ts
│ ├── utils/ # 유틸리티 함수
│ │ └── crypto.ts
│ └── index.ts # 진입점
├── tests/ # 테스트 파일
├── dist/ # 컴파일된 JS 파일
└── node_modules/ # 의존성
설명
이것이 하는 일: 프로젝트의 모든 파일을 역할과 도메인에 따라 논리적으로 그룹화하여 배치합니다. 첫 번째로, 최상위에 src 디렉토리를 만들어 모든 타입스크립트 소스 코드를 이곳에 배치합니다.
tsconfig.json의 rootDir을 "./src"로 설정하면, 컴파일러가 이 디렉토리를 소스의 루트로 인식합니다. 이렇게 하면 빌드 산출물도 동일한 구조로 dist에 생성되어 관리가 용이합니다.
그 다음으로, src 내부를 도메인별로 세분화합니다. core 폴더에는 블록체인의 핵심 로직인 Block, Blockchain, Transaction 클래스를 배치하고, wallet에는 지갑 관련 코드를, network에는 P2P 통신 코드를 넣습니다.
utils는 암호화 함수나 데이터 검증 같은 범용 유틸리티를 담습니다. 이렇게 도메인별로 분리하면 특정 기능을 수정할 때 관련 코드를 한곳에서 찾을 수 있습니다.
마지막으로, tests 디렉토리는 src와 동일한 구조로 만들어, 각 소스 파일에 대응하는 테스트 파일을 배치합니다. dist는 tsc가 자동으로 생성하므로 직접 건드리지 않으며, .gitignore에 추가하여 버전 관리에서 제외합니다.
node_modules도 마찬가지로 .gitignore에 추가합니다. 여러분이 이런 구조를 사용하면 코드를 찾는 시간이 줄어들고, 새로운 기능을 추가할 위치가 명확해지며, import 경로만 봐도 모듈 간 의존 관계를 파악할 수 있습니다.
또한 팀 프로젝트에서 여러 명이 동시에 작업할 때 파일 충돌이 줄어들고, 코드 리뷰 시 변경 사항의 영향 범위를 빠르게 이해할 수 있습니다.
실전 팁
💡 각 도메인 폴더에 index.ts를 만들어 public API만 export하면, 외부에서는 구현 세부사항을 몰라도 사용할 수 있습니다.
💡 types 폴더를 별도로 만들어 공통 타입 정의를 관리하면, 타입 재사용이 쉬워지고 순환 참조 문제를 피할 수 있습니다.
💡 config 폴더에 환경별 설정 파일을 두면, 개발/스테이징/프로덕션 환경을 쉽게 관리할 수 있습니다.
💡 디렉토리가 너무 깊어지면(3depth 이상) 오히려 복잡해지므로, 적절한 균형을 유지하세요.
6. ESLint와 Prettier 설정
시작하며
여러분이 팀 프로젝트를 하다 보면 이런 상황을 자주 겪게 됩니다. 어떤 팀원은 세미콜론을 쓰고, 어떤 팀원은 안 씁니다.
들여쓰기는 누구는 스페이스 2칸, 누구는 4칸, 또 누구는 탭을 사용합니다. 코드 리뷰 시간의 절반이 스타일 논쟁으로 낭비됩니다.
더 심각한 문제는 잠재적인 버그를 놓치는 것입니다. 사용하지 않는 변수, 타입 불일치, 안전하지 않은 코드 패턴 등은 ESLint 같은 도구 없이는 찾기 어렵습니다.
특히 블록체인 코드는 보안이 중요하므로 정적 분석 도구가 필수입니다. 바로 이럴 때 필요한 것이 ESLint와 Prettier입니다.
ESLint는 코드 품질을, Prettier는 코드 스타일을 자동으로 관리하여 일관성 있고 안전한 코드를 작성할 수 있게 해줍니다.
개요
간단히 말해서, ESLint는 코드 품질과 잠재적 오류를 검사하는 정적 분석 도구이고, Prettier는 코드 포맷팅을 자동화하는 도구입니다. 실무에서는 코드의 일관성이 개인의 선호보다 중요합니다.
블록 생성 로직에서 변수명이 camelCase와 snake_case가 혼재하거나, 어떤 파일은 단일 따옴표를 쓰고 어떤 파일은 이중 따옴표를 쓰면 코드 가독성이 떨어집니다. ESLint와 Prettier를 사용하면 저장할 때마다 자동으로 규칙에 맞게 포맷팅되므로, 스타일 걱정 없이 로직에만 집중할 수 있습니다.
기존에는 코드 리뷰어가 수동으로 스타일 지적을 했다면, 이제는 도구가 자동으로 검사하고 수정하므로 리뷰어는 비즈니스 로직과 아키텍처에 집중할 수 있습니다. 핵심 특징은 첫째, ESLint가 잠재적 버그와 안티패턴을 조기에 발견하고, 둘째, Prettier가 일관된 코드 스타일을 강제하며, 셋째, VSCode 같은 IDE와 통합하여 실시간으로 피드백을 제공한다는 점입니다.
이러한 특징들이 코드 품질을 자동으로 유지하게 만듭니다.
코드 예제
# ESLint와 TypeScript 플러그인 설치
npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin
# Prettier 설치
npm install --save-dev prettier eslint-config-prettier eslint-plugin-prettier
# .eslintrc.json 생성
{
"parser": "@typescript-eslint/parser",
"extends": [
"plugin:@typescript-eslint/recommended",
"plugin:prettier/recommended"
],
"rules": {
"no-console": "warn"
}
}
설명
이것이 하는 일: ESLint는 코드를 분석하여 문제를 찾아내고, Prettier는 설정에 맞게 코드를 재포맷팅합니다. 첫 번째로, ESLint 관련 패키지를 설치합니다.
@typescript-eslint/parser는 타입스크립트 코드를 ESLint가 이해할 수 있게 파싱하고, @typescript-eslint/eslint-plugin은 타입스크립트 전용 린팅 규칙을 제공합니다. 이 두 패키지가 있어야 타입스크립트 프로젝트에서 ESLint를 제대로 사용할 수 있습니다.
그 다음으로, Prettier와 ESLint 통합을 위한 패키지를 설치합니다. eslint-config-prettier는 ESLint의 포맷팅 규칙 중 Prettier와 충돌하는 것들을 비활성화하고, eslint-plugin-prettier는 Prettier를 ESLint 규칙으로 실행할 수 있게 합니다.
이렇게 하면 두 도구가 서로 방해하지 않고 협력합니다. 마지막으로, .eslintrc.json 파일을 만들어 설정을 정의합니다.
parser 필드로 타입스크립트 파서를 지정하고, extends 배열에 추천 규칙 세트를 추가합니다. rules 섹션에서 프로젝트에 맞는 커스텀 규칙을 정의할 수 있습니다.
예를 들어 "no-console": "warn"은 console.log 사용 시 경고를 표시합니다. 여러분이 이 설정을 완료하면 VSCode에서 파일 저장 시 자동으로 포맷팅되고, 잠재적 오류는 밑줄로 표시되며, npm run lint 명령어로 전체 프로젝트를 검사할 수 있습니다.
Git 커밋 전에 린트를 자동 실행하도록 설정하면(husky + lint-staged), 문제가 있는 코드가 저장소에 들어가는 것을 방지할 수 있습니다.
실전 팁
💡 .prettierrc 파일을 만들어 프로젝트의 포맷팅 규칙(세미콜론, 따옴표 종류, 줄 길이 등)을 명시하세요.
💡 VSCode의 "Format On Save" 설정을 활성화하면 파일 저장 시 자동으로 Prettier가 실행됩니다.
💡 package.json에 "lint": "eslint src//*.ts", "format": "prettier --write src//*.ts" 스크립트를 추가하세요.
💡 .eslintignore와 .prettierignore 파일로 dist, node_modules 등을 제외하여 성능을 최적화하세요.
💡 airbnb나 standard 같은 인기 있는 ESLint 설정을 확장하면 검증된 규칙을 빠르게 적용할 수 있습니다.
7. Git 설정과 .gitignore
시작하며
여러분이 프로젝트를 Git으로 관리하기 시작하면서 실수로 node_modules 폴더를 커밋한 적이 있나요? 수천 개의 파일이 저장소에 들어가면서 리포지토리 크기가 수백 MB로 불어나고, 클론 받는 데만 몇 분이 걸리게 됩니다.
또는 .env 파일에 있는 API 키가 공개 저장소에 노출되어 보안 사고가 발생할 수도 있습니다. 이런 문제는 초보 개발자뿐만 아니라 경험 있는 개발자도 자주 겪습니다.
Git은 기본적으로 모든 파일을 추적하려 하기 때문에, 무엇을 추적하지 말아야 하는지 명시적으로 알려줘야 합니다. 바로 이럴 때 필요한 것이 .gitignore 파일입니다.
버전 관리에서 제외해야 할 파일과 디렉토리를 정의하여, 저장소를 깨끗하고 안전하게 유지할 수 있습니다.
개요
간단히 말해서, .gitignore는 Git이 추적하지 않을 파일과 디렉토리를 지정하는 설정 파일입니다. 실무에서는 수많은 파일이 프로젝트에 생성되지만, 모든 파일을 버전 관리할 필요는 없습니다.
빌드 산출물(dist), 의존성(node_modules), 환경 변수(.env), IDE 설정(.vscode), 로그 파일 등은 개발자마다 다르거나 자동 생성되므로 Git에서 제외해야 합니다. 예를 들어, 블록체인 노드를 실행하면서 생성되는 로그 파일이나 테스트 데이터는 저장소에 넣을 필요가 없습니다.
기존에는 .git/info/exclude 파일로 로컬에서만 무시 규칙을 관리했다면, 이제는 .gitignore를 리포지토리에 포함시켜 팀 전체가 동일한 규칙을 공유할 수 있습니다. 핵심 특징은 첫째, 패턴 매칭으로 여러 파일을 한 번에 무시할 수 있고, 둘째, 디렉토리별로 다른 규칙을 적용 가능하며, 셋째, 리포지토리 크기를 최소화하여 클론 속도를 높인다는 점입니다.
이러한 특징들이 효율적인 협업 환경을 만듭니다.
코드 예제
# .gitignore 파일 내용
# 의존성
node_modules/
# 빌드 산출물
dist/
build/
*.js
*.js.map
# 환경 변수
.env
.env.local
# IDE 설정
.vscode/
.idea/
# 로그
*.log
logs/
# OS 파일
.DS_Store
Thumbs.db
설명
이것이 하는 일: Git이 커밋을 생성할 때 .gitignore에 명시된 패턴과 일치하는 파일을 자동으로 제외합니다. 첫 번째로, node_modules/를 무시 목록에 추가합니다.
이 폴더는 npm install로 언제든 재생성할 수 있으므로 버전 관리가 불필요합니다. 대신 package.json과 package-lock.json만 관리하면, 다른 개발자가 동일한 의존성을 설치할 수 있습니다.
슬래시(/)는 디렉토리를 의미하며, 이것이 없으면 파일과 디렉토리 모두를 무시합니다. 그 다음으로, dist/와 *.js 같은 빌드 산출물을 제외합니다.
타입스크립트는 소스 코드이고 자바스크립트는 컴파일 결과물이므로, 소스만 관리하는 것이 원칙입니다. 다만 설정 파일 중 .js로 끝나는 것(예: jest.config.js)은 예외로 추가해야 할 수 있습니다.
!jest.config.js 같은 예외 패턴을 사용하면 됩니다. 세 번째로, .env 파일을 반드시 무시합니다.
이 파일에는 데이터베이스 비밀번호, API 키 같은 민감한 정보가 들어가므로, 공개 저장소에 올라가면 보안 사고가 발생합니다. 대신 .env.example 파일을 만들어 필요한 환경 변수 목록만 공유하고, 실제 값은 각 개발자가 로컬에서 설정하도록 합니다.
마지막으로, .vscode/나 .DS_Store 같은 IDE 및 OS 파일을 제외합니다. 이런 파일들은 개발자마다 다르고 프로젝트 실행에 불필요하므로, 저장소를 깔끔하게 유지하기 위해 무시해야 합니다.
여러분이 .gitignore를 제대로 설정하면 리포지토리 크기가 수십 배 줄어들고, 민감한 정보 유출을 방지하며, git status 출력이 깔끔해져 실제 변경 사항에 집중할 수 있습니다. 프로젝트 시작 시 한 번만 제대로 설정하면 평생 편안합니다.
실전 팁
💡 gitignore.io 웹사이트에서 Node, TypeScript, VSCode 등을 선택하면 완성된 .gitignore 템플릿을 생성해줍니다.
💡 이미 커밋된 파일을 나중에 무시하고 싶다면 git rm --cached <파일명>으로 추적을 해제한 후 .gitignore에 추가하세요.
💡 프로젝트 루트의 .gitignore가 전체에 적용되지만, 서브 디렉토리마다 별도의 .gitignore를 둘 수도 있습니다.
💡 # 주석을 활용하여 각 섹션이 무엇을 무시하는지 설명하면, 나중에 유지보수할 때 이해하기 쉽습니다.
💡 .gitignore는 그 자체로 중요한 설정 파일이므로 반드시 Git에 커밋하세요. 팀원 모두가 동일한 규칙을 사용해야 합니다.