2025년 7월 27일·7분
프레임워크 선택이 장기 기술 부채를 결정하는 이유
프레임워크 결정은 유지보수 비용, 업그레이드 경로, 채용, 안정성에 영향을 줍니다. 장기 기술 부채를 줄이기 위한 트레이드오프 평가 방법을 알아보세요.
프레임워크 결정은 유지보수 비용, 업그레이드 경로, 채용, 안정성에 영향을 줍니다. 장기 기술 부채를 줄이기 위한 트레이드오프 평가 방법을 알아보세요.
기술 부채는 도덕적 실패나 모호한 “코드 품질” 불만이 아닙니다. 실제 프로젝트에서는 배포한 것과 앞으로 안전하게 계속 배포하기 위해 필요한 것 사이의 간극입니다.
보통 세 가지 실용적 통화로 측정할 수 있습니다:
개념에 대한 빠른 복습이 필요하면 /blog/technical-debt-basics를 참고하세요.
프레임워크 선택은 단순한 라이브러리 이상의 영향을 미칩니다—팀이 코드를 구성하는 방식, 의존성이 끌려오는 방식, 시간이 지남에 따라 변화가 일어나는 방식을 규정합니다.
프레임워크는 다음과 같을 때 부채를 줄일 수 있습니다:
반대로 프레임워크는 다음과 같을 때 부채를 증폭시킬 수 있습니다:
모든 프레임워크는 트레이드오프의 묶음입니다: 오늘의 속도 vs. 이후의 유연성, 의견이 강한 구조 vs. 커스터마이징, 폭넓은 생태계 vs. 의존성 리스크. 목표는 부채를 완전히 피하는 것이 아니라(비현실적임) 당신이 감당할 수 있는 종류의 부채를 선택하는 것입니다—깜짝 이자가 복리로 불어나는 대신 작고 계획된 상환을 하는 식으로요.
몇 년이 지나면 프레임워크의 기본값이 프로젝트 습관이 됩니다. 그 습관은 유지보수를 예측 가능하게 만들거나 일상적인 작업을 조용한 세금으로 바꿔 버립니다.
팀은 드물게 ‘앞으로 5년’을 위해 프레임워크를 고릅니다. 보통은 이번 분기에 무언가를 출시하기 위해 선택합니다.
단기적 이유들은 대부분 타당합니다: 첫 출시까지의 속도, 익숙함(“이미 알고 있다”), 탁월한 기능(라우팅, 인증, 실시간), 풍부한 예제와 템플릿, 또는 결정 수를 줄여주는 의견형 프레임워크의 약속. 때로는 채용 측면에서의 단순한 이유—“이 스택에 개발자를 구할 수 있다”—가 결정적입니다.
초기 이점은 제품이 성장하면 제약으로 바뀝니다. 프레임워크는 단순히 대체 가능한 라이브러리가 아니라 상태 관리, 데이터 접근, 테스트, 배포, 팀의 코드 조직 방식에 대한 패턴을 정의합니다. 이러한 패턴이 여러 화면·서비스·모듈에 퍼지면 방향을 바꾸는 것이 비싸집니다.
일반적인 ‘나중 청구서’는 다음과 같습니다:
프로토타입에 완벽하게 느껴지는 프레임워크는 모멘텀을 위해 최적화되어 있습니다: 빠른 스캐폴딩, 많은 마법, 최소 설정. 반면 제품은 예측 가능성을 위해 최적화됩니다: 명확한 경계, 테스트 가능성, 관찰성, 통제된 변경.
프로토타입은 ‘나중에 정리하자’는 약속을 견딜 수 있습니다. 제품은 결국 그 약속에 대한 이자를 지불합니다—특히 원래 문맥을 공유하지 않는 신규 개발자를 온보딩할 때 더 크게 드러납니다.
“v1을 얼마나 빨리 만들 수 있나?” 대신 프레임워크 수명주기 전반의 비용을 평가하세요:
프레임워크 선택은 하나의 방식으로 구축하는 데 대한 약속입니다. 일회성 구매가 아니라 다년 계약처럼 취급하세요.
업그레이드는 ‘미래의 당신’이 오늘의 프레임워크 결정을 대신 지불하는 곳입니다. 예측 가능한 버전 수명주기가 있는 프레임워크는 유지보수를 지루하게(좋은 의미로) 만들 수 있습니다. 반대로 잦은 브레이킹 변경이 있는 프레임워크는 루틴 업데이트를 작은 프로젝트로 바꿔 제품 작업을 빼앗아갑니다.
프레임워크의 릴리스 정책을 요금표 읽듯이 먼저 읽어보세요.
메이저 업그레이드는 API, 설정 형식, 빌드 도구, 권장 아키텍처 패턴까지 깨뜨릴 수 있습니다. 비용은 단순히 ‘컴파일이 되게 만드는 것’이 아닙니다: 코드 리팩터, 테스트 업데이트, 팀 재교육, 엣지 케이스 재검증이 필요합니다.
유용한 사고 실험: 주요 버전 두 개를 건너뛰었다면 현실적으로 일주일 안에 업그레이드할 수 있는가? 정직한 답이 “아니오”라면 반복되는 부채 상환에 직면해 있는 것입니다.
권고 중단은 잡음이 아닙니다—카운트다운 타이머입니다. 실천 방법:
방치하면 일련의 작은 안전한 변경들이 하나의 위험한 마이그레이션으로 바뀝니다.
프레임워크를 채택하기 전에 지난 1–2회의 메이저 릴리스용 공식 마이그레이션 가이드를 훑어보세요. 가이드가 길고 모호하거나 많은 수작업이 필요하면 즉시 결정 불가 사유는 아니지만, 명확히 수용해야 할 유지보수 예산 항목입니다.
프레임워크는 핵심 API 이상입니다. 서드파티 라이브러리와 패키지, 플러그인, 빌드 도구, 테스트 유틸리티, 문서, 예제, 통합(auth, 결제, 분석), 그리고 문제 해결을 돕는 커뮤니티 지식까지 포함한 생태계를 가집니다.
도입하는 모든 의존성은 당신이 완전히 통제하지 않는 또 하나의 움직이는 부품이 됩니다. 많은 서드파티 패키지에 의존하면 다음과 같은 위험이 커집니다:
간단한 기능(예: 파일 업로드 플러그인)이 조용히 장기 유지보수 약속으로 바뀌는 방식입니다.
패키지나 도구를 채택하기 전에 몇 가지 실용적 신호를 확인하세요:
두 개의 유사한 의존성 중에서 결정해야 한다면 지루하고 잘 유지되는 쪽, 버전 정렬이 잘된 쪽을 선택하세요.
‘절대 깨지면 안 되는’ 의존성 수를 작게 유지하도록 노력하세요. 인증·데이터 접근·큐 같은 핵심 워크플로우에는 널리 지지되는 옵션을 선택하거나 얇은 내부 어댑터를 만들어 나중에 구현을 교체할 수 있게 하세요.
또한 각 의존성 결정에 대해 왜 필요한지, 무엇을 대체하는지, 누가 업그레이드를 담당하는지, 종료 계획은 무엇인지 문서화하세요. 리포지토리에 가벼운 ‘의존성 레지스터’를 두면 잊힌 패키지가 영구적 부채로 남는 것을 막을 수 있습니다.
프레임워크는 단순히 API를 제공하는 것이 아니라 코드 조직의 특정 패턴으로 유도합니다. 어떤 프레임워크는 ‘모든 것이 컨트롤러/컴포넌트’ 사고를 장려하고, 다른 프레임워크는 모듈, 서비스, 도메인 레이어로 밀어넣습니다. 프레임워크의 패턴이 제품 형태와 맞으면 팀은 빠르게 움직입니다. 맞지 않으면 어색한 우회책을 쓰게 되고 그것이 영구화됩니다.
결합의 흔한 징후:
비용은 이후 프레임워크를 교체하거나 데이터베이스 레이어를 바꾸거나 배경 작업에서 로직을 재사용하려 할 때 드러납니다. 모든 것이 얽혀 있으면 작업이 비싸집니다.
실용적 접근은 프레임워크를 외부 ‘전달 계층’으로 보고 핵심 로직을 일반 모듈/서비스에 두는 것입니다. 어댑터와 인터페이스, 서비스 레이어를 사용해 프레임워크를 아는 코드를 최소화하세요.
얇은 프레임워크 계층 예시:
UserRepository)에 의존프레임워크가 도처에 있는 예시:
원하는 아키텍처에 맞는 프레임워크를 선택하고 초기에 경계를 강제하면 향후 마이그레이션이 작아지고 테스트가 단순해지며 새 기능이 숨겨진 부채를 쌓는 일이 줄어듭니다.
테스트 부채는 보통 하나의 무서운 티켓으로 나타나지 않습니다. 조용히 쌓입니다: 커버되지 않은 ‘빠른 수정’들, 리팩터가 위험하게 느껴지는 순간들, 수동 점검과 긴장감을 동반한 릴리스.
프레임워크 선택은 테스트 습관을 형성합니다. 관습이 테스트를 기본 경로로 만드는지, 아니면 추가 노동으로 만드는지를 결정합니다.
일부 프레임워크는 라우팅/컨트롤러, 비즈니스 로직, 데이터 접근 간의 분리를 장려해 작은 단위로 테스트하기 쉽습니다. 다른 프레임워크는 그 경계를 흐려 ‘갓 오브젝트’ 같은 큰 덩어리를 유도해 격리 테스트가 어렵습니다.
의존성 주입, 목킹, 관심사의 분리를 자연스럽게 지원하는 내장 패턴을 찾으세요. ‘해피 패스’가 전역 상태나 암시적 마법에 밀착되어 있다면 테스트는 복잡한 설정과 깨지기 쉬운 검증으로 기울어집니다.
건강한 테스트 스위트는 보통 둘을 섞습니다:
의존성을 목킹하고 구성 요소를 격리해 실행할 수 있는 프레임워크는 유닛 테스트 비용을 낮춥니다. 전체 앱을 띄워야만 테스트할 수 있는 프레임워크는 팀을 느린 통합 테스트에 의존하게 할 수 있습니다.
느린 테스트는 숨은 세금입니다. 전체 스위트가 20–40분 걸리면 사람들이 덜 자주 실행합니다. 변경을 묶어 커다란 실패를 만들고 디버깅에 더 많은 시간을 쏟게 됩니다.
프레임워크 수준의 병렬 실행, 결정적 테스트 환경, 경량 ‘테스트 모드’ 지원은 테스트를 빠른 루프로 만들어 품질을 유지하는 데 도움이 됩니다.
성숙하고 널리 채택된 테스트 도구와 다음과 같은 명확한 패턴을 제공하는 프레임워크를 선택하세요:
공식 문서가 테스트를 1순위 주제로 다루면 장기적으로 낮은 커버리지로 인해 모든 변경이 위험하게 느껴질 가능성이 줄어듭니다.
프레임워크 결정은 사람에 관한 결정이기도 합니다. 이론적으로 멋진 아키텍처도 팀이 편하게 빌드·리뷰·유지할 수 없으면 장기 기술 부채를 만들 수 있습니다.
학습 곡선이 가파른 프레임워크는 기능 작업을 지연시킬 뿐 아니라 자신감도 늦춥니다. 신규 채용자는 안전하게 변경을 배포하는 데 더 오래 걸리고, 코드 리뷰는 더 느려집니다. 프로덕션 인시던트 진단에도 시간이 더 걸립니다.
이 지연은 팀을 ‘빠른 해결’로 밀어넣어 최선 사례를 우회하게 만들고(테스트 건너뛰기, 이해 없이 패턴 복사, 리팩터 회피) 이러한 지름길은 다음 세대 팀원이 물려받는 부채로 쌓입니다.
어떤 프레임워크는 인재 풀이 깊고, 다른 프레임워크는 전문가가 필요합니다. 채택이 채용을 좁히면 다음과 같은 비용을 지불합니다:
현재 팀이 새로운 것을 배우는 데 열정적이라 해도 향후 2–3년 동안 지속적으로 사람을 뽑아 온보딩할 수 있는지 고려하세요.
프레임워크가 문서화되지 않은 관습(커스텀 래퍼, ‘마법’ 규약, 한 사람만 아는 빌드 단계)을 조장하면 부채가 가장 빠르게 증가합니다. 해당 인력이 떠나면 회사는 단지 속도를 잃는 것이 아니라 안전하게 변경할 능력을 잃습니다.
완화책:
가벼운 ‘우리는 이렇게 빌드한다’ 가이드와 템플릿 리포지토리는 온보딩을 고고학에서 체크리스트로 바꿉니다. 내부 문서를 이미 유지한다면 템플릿을 /engineering/standards 같은 중앙 페이지에 링크해 쉽게 찾고 최신으로 유지하세요.
성능 부채는 대개 프레임워크 기본값을 맞추기 위해 한 임시 타협으로 시작됩니다. 그런데 이 타협들이 코드베이스 전반에 굳어져 퍼지고 트래픽이나 데이터가 늘었을 때 되돌리기 어려워집니다.
프레임워크는 보통 개발자 속도에 최적화되어 있습니다. 문제는 이러한 기본값이 우연히 확장 전략으로 사용될 때입니다.
흔한 함정:
이들은 ‘나쁜 프레임워크’라기보다 사용하기 쉬운 추상화의 예측 가능한 결과입니다.
초기에 성능 압박을 느끼면 팀은 프레임워크와 싸우는 임시 해결책을 덧붙일 수 있습니다: 여기저기 흩어진 커스텀 캐싱, 수동 DOM 해킹, 라우팅 관습 우회, 느린 경로를 피하려 로직 복제 등.
이러한 우회책은 종종 다음을 초래합니다:
해결책을 만들기 전에 프로덕션과 유사한 데이터와 사용자 행동으로 기준을 수립하세요. 엔드투엔드(요청 → DB → 응답) 및 UI(상호작용 → 렌더) 측정을 하세요. 반복 가능한 시나리오 몇 개가 긴 마이크로벤치마크 목록보다 낫습니다.
간단한 규칙: 앱 전반에 반복될 새로운 의존성이나 패턴을 도입할 때 측정하세요.
기준에서 명확한 병목이 보이거나 해당 패턴이 널리 복제될 경우(목록 페이지, 검색, 인증, 리포팅) 최적화하세요. 기능이 아직 자주 바뀌거나 최적화가 관습을 깨야 하는 경우에는 단순함을 유지하세요.
프레임워크 선택이 중요한 이유는 장기적으로 ‘빠른 경로(fast path)’가 일반 경로가 되게 해 불필요한 우회 비용을 지불하지 않게 해주기 때문입니다.
기술 부채는 단지 ‘오래된 코드’만의 문제가 아닙니다. 프레임워크가 같은 문제를 여러 방식으로 풀 수 있게 허용하거나 장려하면 유지보수가 빠르게 느려집니다. 팀마다, 스프린트마다, 개발자마다 패턴이 다르면 모든 기능이 서로 다르게 보입니다.
패턴이 팀별로 다르면 유지보수가 느려지는 이유는 의사결정 포인트가 늘어나기 때문입니다. 버그 픽스가 ‘이 부분은 어떤 패턴을 사용했나?’가 되고, 새 기능은 ‘세 가지 승인된 접근 방식 중 어느 것을 따라야 하나?’가 됩니다. 시간이 지나면 이 인지적 부하가 개발자 생산성에 영구적인 세금으로 작용합니다.
규약은 자동으로 강제될 때 자리잡습니다:
최고의 도구는 기본으로 실행되어 규칙이 깨지면 크게 실패하게 하는 도구입니다.
코드베이스가 커지기 전에 표준을 결정하세요: 폴더 구조, 네이밍, 모듈 경계, 테스트 기대치, 프레임워크 사용 방식(하나의 라우팅 접근, 하나의 상태 전략, 하나의 데이터 페칭 패턴 등).
그다음 CI 검사(린트, 타입 체크, 테스트, 포맷 검사)로 고정하세요. 프리커밋 훅을 추가하면 도움이 될 수 있지만 CI를 최종 관문으로 삼아 스타일 drift가 조용히 장기 부채로 변하는 것을 막으세요.
반짝이는 프레임워크는 분명 매력적입니다: 빠른 빌드, 깔끔한 API, ‘모던’ 패턴. 하지만 트렌디함과 성숙도를 혼동하면 장기 기술 부채의 흔한 원인이 됩니다.
성숙한 프레임워크는 단지 오래된 것이 아니라 잘 이해된 것입니다. 특징:
성숙도는 surprise rewrite와 지속적 우회책 같은 ‘알 수 없는 알 수 없음’을 줄여줍니다.
초기 단계 프레임워크는 빠르게 변화합니다. 실험에는 생산적일 수 있지만 그 프레임워크가 수익 관련 핵심 앱이나 공유 플랫폼의 중심에 자리 잡으면 비용이 커집니다.
흔한 부채 패턴: 잦은 마이그레이션, 프레임워크 릴리스마다 깨지는 서드파티 패키지, 기능 결여를 보완하기 위한 내부 ‘패치 레이어’ 구축. 시간이 지나면 팀은 제품 대신 프레임워크의 빈틈을 유지보수하게 됩니다.
새 툴을 완전히 무시할 필요는 없습니다. 실용적 전략은 트렌디한 프레임워크를 비핵심 영역(내부 대시보드, 프로토타입, 격리된 서비스)에서 파일럿으로 사용하고, 환경에서 안정성이 증명되면 점진적으로 채택하는 것입니다. 이렇게 하면 선택권은 보존하면서도 너무 이른 전사적 약속을 피할 수 있습니다.
도입 전에 다음을 스캔하세요:
트렌디함은 진보를 촉진할 수 있지만, 진전이 저렴하게 유지되게 하는 것은 성숙도입니다.
프레임워크를 고르는 것은 ‘무엇이 최고인가’가 아니라 제품, 제약, 팀에 무엇이 맞는지를 따지는 일입니다. 방어 가능한 결정을 돕는 가벼운 체크리스트가 있으면 후회 없는 선택을 할 수 있습니다.
옵션을 비교하기 위해 1–5점 스코어링을 빠르게 해보세요. 지루하고 계량 가능한 항목으로 유지하세요.
| 요소 | 무엇을 점수화할 것인가 | 부채 관점에서 중요한 이유 |
|---|---|---|
| 비즈니스 요구 | 시장 출시 시간, 로드맵 적합성, 규정 준수 | |
| 위험 | 벤더 락인, 수명주기 안정성, 보안 태세 | |
| 팀 역량 | 현재 전문성, 학습 곡선, 채용 풀 |
기능에서는 이겨도 위험이나 팀 역량에서 크게 밀리면 종종 ‘미래 유지보수에서 빌리는’ 셈이 됩니다.
더 깊은 평가 방법은 /blog/how-to-evaluate-tech-stack-choices를 참조하세요.
짧은 결정 기록을 작성하세요: 고려한 옵션, 점수, 주요 가정, 수용한 레드플래그. 분기별(또는 주요 로드맵 변화 시)로 재검토 일정을 잡아 가정이 여전히 유효한지 확인하고 업그레이드를 긴급한 일이 아니라 계획된 작업으로 만드세요.
AI 보조 개발은 코드 생성 속도를 바꿀 수 있지만 프레임워크 주도의 부채를 없애지는 못합니다. 오히려 기본값과 규약이 더 중요해집니다. 코드가 더 빨리 생성되면 불일치도 더 빨리 확산되기 때문입니다.
예를 들어 Koder.ai 같은 플랫폼(React 웹 앱, Go + PostgreSQL 백엔드, Flutter 모바일 앱을 위한 채팅 기반 vibe-coding 워크플로)을 사용할 때는 생성된 결과물을 다른 프레임워크 투자처럼 취급하세요:
속도는 승수입니다. 올바른 가드레일이 있으면 전달력을 배가시키고, 없으면 미래 유지보수 비용을 배가시킵니다.
기술 부채는 배포한 것과 앞으로 안전하게 계속 배포하기 위해 필요한 것 사이의 차이입니다.
실무에서는 다음과 같이 나타납니다:
프레임워크는 구조, 의존성 관리, 테스트 방식, 업그레이드 메커니즘에 대한 기본값을 설정합니다.
프레임워크는 반복 가능한 패턴을 강제하고 테스트를 쉽게 만들며 예측 가능한 릴리스 방식이 있을 때 부채를 줄입니다. 반대로 많은 연결 코드가 필요하거나, 강하게 결합되는 패턴을 유도하거나, 안정적인 마이그레이션 경로 없이 자주 깨지는 변경을 요구하면 부채를 키웁니다.
단기 출시 속도만 최적화하지 마세요. 대신 수명 주기 비용을 평가하세요:
프레임워크는 일회성 설치가 아니라 수년짜리 계약에 가깝습니다.
약속하기 전에 다음 네 가지를 확인하세요:
권고 중단(Deprecation)은 단순한 잡음이 아니라 카운트다운 타이머입니다.
실용적 접근:
권고 중단을 방치하면 작고 안전한 변경들이 한 번의 위험한 마이그레이션으로 합쳐질 수 있습니다.
서드파티 패키지가 늘어나면 통제하지 못하는 움직이는 부품이 늘어납니다.
주요 위험:
핵심 워크플로우(auth, 데이터 접근, 큐 등)에 대해서는 널리 지원되는 옵션을 선택하거나 얇은 내부 래퍼를 만들어 나중에 교체할 수 있게 하세요. 또한 각 의존성 결정 이유, 대체 대상, 업그레이드 담당자, 종료 계획을 문서화하세요.
핵심 비즈니스 로직이 프레임워크 없이는 존재할 수 없을 때 결합이 발생합니다.
징후:
완화 방법: 프레임워크를 외부 '전달 메커니즘'으로 취급하고, 핵심 로직은 일반 모듈/서비스로 유지하세요. 어댑터, 인터페이스, 서비스 레이어 같은 경계로 프레임워크 의존 구역을 얇게 만드세요.
프레임워크는 테스트가 기본 경로인지, 아니면 추가 작업인지를 결정합니다.
우선순위:
느리고 작성하기 어려운 테스트는 장기적인 생산성 세금이 됩니다.
부채는 소수만 스택을 잘 아는 상황에서 빠르게 늘어납니다.
프레임워크 선택이 비용을 높이는 방식:
완화책: 폴더 구조, 네이밍, 에러 처리, 상태 관리, API 패턴 등 규약을 문서화하고, 린팅·포맷팅·테스트 설정·CI 체크를 포함한 스타터 템플릿 저장소와 짧은 ‘우리는 이렇게 개발한다’ 가이드를 제공하세요. 내부 문서가 있다면 /engineering/standards 같은 중앙 페이지에 템플릿 링크를 걸어 쉽게 찾게 하세요.
경계 없는 기본값 때문에 성능 타협이 고착화되면 나중에 데이터를 늘리거나 트래픽이 증가할 때 이를 되돌리는 데 큰 비용이 듭니다.
흔한 성능 함정:
최적화 시점: 프로덕션과 유사한 데이터와 유저 행동으로 기준을 측정한 후 병목이 명확할 때 최적화하세요. 이 패턴이 반복될 경우 미리 손보는 것이 낫습니다.
일관성 결여는 여러 방식으로 같은 문제를 해결하게 만들어 유지보수를 느리게 합니다. 팀·스프린트·개발자마다 패턴이 다르면 새 엔지니어는 어디에 로직이 있는지 예측할 수 없고, 리팩터는 위험해집니다.
일관성을 유지하려면 자동화된 도구를 활용하세요:
합의는 초기에 하고 CI에서 강제하세요(린트, 타입 체크, 테스트, 포맷 검사). 이는 스타일 drift가 장기 기술 부채로 이어지는 것을 막습니다.
반짝이는 신기술은 매력적이지만 성숙도와 혼동하면 장기 부채의 원인이 됩니다.
성숙한 프레임워크의 특징:
새로운 프레임워크는 핵심 시스템에 적용하기 전에 내부 프로젝트나 프로토타입에서 파일럿으로 시험한 뒤 점진적으로 도입하세요. 트렌디함은 실험에는 좋지만 핵심 시스템에는 성숙함이 필요합니다.
간단 체크리스트:
프레임워크 선택은 제품, 제약, 팀에 맞는지를 보는 문제입니다. 방어 가능한 결정을 위해 간단한 체크리스트를 사용하세요.
결정 매트릭스(1–5 점) 예시:
또한 짧은 결정 기록(대안, 가정, 수용된 레드플래그)을 작성하고 분기별로 재검토 일정을 잡아 업그레이드와 변경을 계획된 작업으로 유지하세요.
더 깊은 평가 방법은 /blog/how-to-evaluate-tech-stack-choices를 참고하세요.
AI 보조 개발은 코드 생성 속도를 높이지만 프레임워크 기반 부채를 제거하지는 않습니다. 오히려 기본값과 규약이 더 중요해집니다. 코드가 더 빠르게 생성되면 일관성이 깨지는 속도도 빨라지기 때문입니다.
실무 팁:
속도는 승수입니다. 적절한 가드레일이 있으면 전달력을 곱하지만, 없으면 유지보수 비용을 곱합니다.