728x90
1. next vs _next: Express 미들웨어에서 자주 보이는 표기
Express에서의 미들웨어 함수는 다음과 같은 시그니처를 가집니다:
(req: Request, res: Response, next: NextFunction) => void
next – 일반적인 다음 미들웨어 호출용 인자
(req, res, next) => {
next(); // 다음 미들웨어로 이동
}
이 표기는 실제로 next()를 호출하는 경우에 사용됩니다.
_next – 사용하지 않을 인자에 대한 표시
(req, res, _next) => {
// 여기서는 next()를 호출하지 않음
}
- 변수 앞에 _(언더스코어)를 붙이는 관례는 **“이 변수는 사용되지 않는다”**는 의미
- ESLint, TypeScript 설정에서 정의한 변수지만 사용하지 않음으로 인한 경고 방지
- 에러 핸들러 미들웨어에서 자주 사용
(err, req, res, _next) => {
res.status(500).send("Internal Server Error");
}
2. 기타 실무에서 자주 사용하는 관례적 표기
_ (언더스코어) 접두어
표기 | 의미 |
_var | "이 변수는 현재 사용되지 않음" 또는 "내부 전용 변수" |
_next | Express에서 사용하지 않을 미들웨어 인자 표시 |
_this | 바인딩된 this를 저장해두는 전통적인 방식 (ES5 코드에서 자주 사용됨) |
__ (더블 언더스코어)
- 일반적으로 잘 사용되지는 않지만, 테스트 더블(Mock, Stub)이나 시스템 내부 식별자 등으로 사용되는 경우도 있음
const __mockUser = { name: 'test' }; // 테스트 전용
_ (혼자 사용되는 경우)
- lodash 라이브러리를 import할 때 관례적으로 _ 변수명을 사용
- unused placeholder로도 간혹 사용됨 (예: 구조 분해에서 무시)
import _ from 'lodash';
const [_, importantValue] = arr; // 첫 번째 값 무시
3. ESLint/TS 환경에서의 관례적 이득
ESLint 설정 예시
{
"rules": {
"@typescript-eslint/no-unused-vars": ["warn", { "argsIgnorePattern": "^_" }]
}
}
이렇게 설정하면 _next, _unused, _dummy 등의 변수는 "사용되지 않음" 경고에서 제외됩니다.
4. 정리
표기 | 의미 | 주 사용처 |
next | 다음 미들웨어 호출 | Express 미들웨어 |
_next | 사용하지 않을 예정 | 에러 핸들러 등 |
_ | 구조 분해 생략, lodash | 다양한 곳 |
_var | 미사용 변수, 의도적 무시 | 함수 인자, 로직 생략 시 |
__mock | 테스트용 변수 | 유닛 테스트 환경 |
5. 이 내용을 정리하게 된 계기: errorHandler 리팩토링 중 고민
현재 Express 기반 인증 서비스에서 errorHandler를 리팩토링하면서, 다음과 같은 상황을 마주하게 되었습니다.
const errorHandler = (err: Error, req: Request, res: Response, next: NextFunction) => {
// next는 사용되지 않지만 타입 시그니처상 필요
res.status(500).json({ message: err.message });
};
여기서 next는 사용되지 않음에도 불구하고, 타입 정의상 포함되어 있어야 했습니다. 하지만 next로 그대로 두면 “이 변수를 사용할 것 같은” 인상을 주고, ESLint에서도 경고가 발생할 수 있습니다.
그래서 다음과 같이 _next로 변경했습니다:
const errorHandler = (err: Error, req: Request, res: Response, _next: NextFunction) => {
res.status(500).json({ message: err.message });
};
이렇게 하면:
- 해당 변수가 사용되지 않을 것이라는 의도를 명확히 전달할 수 있고,
- ESLint “정의했지만 안 씀” 경고도 피할 수 있습니다
즉, 단순한 관례가 아니라 실무적인 리팩토링 과정에서의 필요로 인해 이 내용을 정리하게 되었습니다.
반응형
'개발 기록' 카테고리의 다른 글
axios.post()만 써도 충분한가요? async/await로 감싸는 이유와 API 구조화 패턴 비교 (0) | 2025.07.02 |
---|---|
개인 서버를 AWS처럼 운영하는 방법 - Ubuntu 보안부터 배포까지 (0) | 2025.05.22 |
도메인 객체 생성을 위한 Factory 패턴 도입기 (1) | 2025.05.09 |