+ 시간대·검증·SSR 차이까지 구체적으로 짚었다.
- 6번을 먼저 확인한 뒤 다시 배치해 순서가 겹친다.
직접 짤지 의존성을 추가할지 기준으로 갈라줍니다. 나중에 걷어낼 때 비용도 셉니다.
| 분류 | 개발 › 코딩 |
|---|---|
| 태그 | 분석검토개발자 |
Help me decide whether to add this dependency. Work through: 1. What I actually need — the narrowest statement of it. Often much smaller than what the library does. 2. Rough size of writing it myself, for that narrow need only. 3. What the dependency brings beyond my need, and what that costs — bundle size, transitive dependencies, API surface I now must track. 4. Removal cost. How deeply would it spread through the codebase, and how hard would it be to take out in two years. 5. Failure modes — unmaintained, breaking changes, a security advisory I must respond to. 6. Whether the standard library or something already installed covers it. Then: a recommendation with the condition that would flip it. Rules: - *Check step 6 before anything else.* Adding a dependency for something already available is the most common version of this mistake. - For a need measured in a few dozen lines, the bar for a dependency should be high. - *Do not assert facts about the library's maintenance status, size, or popularity* — I cannot verify what you recall. Say what to check instead.
의존성 추가는 쉽고 제거는 어렵다. 이 프롬프트는 지금 절약하는 시간과 나중에 드는 비용(버전 고정, 보안 추적, 제거 난이도)을 같이 세워 비교한다.
ChatGPT가 입력 검증과 시간대 위험까지 다뤄 가장 정확하고 실용적이다. Gemini도 결론은 적절하지만 일부 단정과 과한 분량이 있으며, [C]는 답안이 없다.
+ 시간대·검증·SSR 차이까지 구체적으로 짚었다.
- 6번을 먼저 확인한 뒤 다시 배치해 순서가 겹친다.
+ 기존 date-fns 우선 활용 근거가 명확하다.
- ISO 기본 지원과 제거 난이도를 다소 단정했다.
| 기준 | ChatGPT | Gemini | 앞선 모델 |
|---|---|---|---|
| 지시 준수 | 9 | 9 | 동점 |
| 정확성 | 9 | 8 | ChatGPT +13% |
| 구체성 | 10 | 9 | ChatGPT +11% |
| 구성·가독성 | 9 | 9 | 동점 |
| 분량 적정성 | 9 | 7 | ChatGPT +29% |
gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-24). 측정값이 아니라 AI 심사 결과입니다.
같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.
필요한 기능: 날짜 문자열을 여러 포맷(YYYY-MM-DD, MM/DD/YYYY, ISO 8601)으로 파싱하고 '3일 전' 같은 상대 시간으로 표시하는 기능 후보 라이브러리: dayjs 프로젝트 상황: Next.js 14 기반 사내 어드민 대시보드(주문/정산 조회용), 팀 인원 2명. 일부 컴포넌트에서 이미 date-fns를 쓰고 있고, 번들 사이즈보다는 유지보수 부담을 줄이는 게 우선
먼저 6번부터 보면, 이미 일부 컴포넌트에서 date-fns를 사용 중이므로 우선 기존 의존성으로 해결하는 것이 맞습니다. 표준 API도 상대 시간 표시에는 Intl.RelativeTimeFormat을 제공합니다.
YYYY-MM-DD, MM/DD/YYYY, ISO 8601 문자열을 날짜로 변환3일 전, 2시간 전처럼 표시날짜 전체 기능이나 범용 날짜 객체 API가 필요한 것은 아닙니다.
간단한 입력 규칙만 지원한다면 대략 수십 줄입니다.
Intl.RelativeTimeFormat: 20~30줄다만 ISO 8601의 시간대, 오프셋, 밀리초, DST까지 직접 다루기 시작하면 범위가 빠르게 커집니다.
dayjs가 추가로 가져오는 것dayjs는 다음과 같은 범용 기능을 제공합니다.
현재 요구에는 이 중 일부만 필요합니다. 그 대가로 확인해야 할 것은 다음입니다.
package.json과 lockfile 확인date-fns와 dayjs가 함께 사용되면서 날짜 타입과 처리 방식이 이원화되는 비용특히 이미 date-fns를 쓰고 있으므로 dayjs를 추가하면 라이브러리 선택지가 두 개가 됩니다.
도입 범위를 한 곳의 dateAdapter 또는 formatRelativeDate() 함수로 제한하면 제거 비용은 낮습니다. 반대로 컴포넌트 곳곳에서 dayjs()를 직접 호출하고 플러그인·locale에 의존하면 2년 후 제거 시 전체 검색과 단계적 치환이 필요합니다.
도입한다면 반드시 내부 래퍼 뒤에 숨기는 편이 안전합니다.
확인할 항목은 다음입니다.
YYYY-MM-DD를 UTC로 해석할지 로컬 날짜로 해석할지라이브러리의 유지보수 상태나 보안 상태는 현재 확인 없이 단정하지 않는 것이 좋습니다.
현재 조건에서는 대안이 충분합니다.
date-fnsparse, parseISO, isValidformatDistanceToNow 또는 formatDistanceToNowStrictIntl.RelativeTimeFormat('ko', { numeric: 'auto' })Intl.DateTimeFormatdate-fns가 지원하지 않는 입력 형식만 작은 파서로 정규화한 뒤, 날짜 계산과 상대 시간 출력은 기존 도구에 맡길 수 있습니다.
추천
dayjs는 추가하지 않는 것을 권합니다. 이미 date-fns가 있고, 필요한 기능의 범위가 좁으며, 두 날짜 라이브러리를 함께 운영하는 유지보수 비용이 이득보다 커 보입니다.
권장 구조는 다음과 같습니다.
parseAdminDate(input: string): Date | null
formatRelativeAdminDate(date: Date): string
이 두 함수 안에서 입력 포맷과 상대 시간 정책을 통일하세요.
다음 조건이면 dayjs 도입을 재검토할 수 있습니다.
date-fns와 자체 유틸리티로 처리하는 코드가 라이브러리 도입보다 커지며| 방산 CV 12개월 로드맵 프롬프트 | |
| 2046 퍼즐 게임 제작 프롬프트 | |
| React 컴포넌트 통합 프롬프트 | |
| 3D 아바타 팩토리 요구 프롬프트 | |
| 3D FPS 게임 개발 프롬프트 |