위반 하나, 얼마짜리인가 — KRDS 개선 비용·MM 추정 모델 연구

846개 규칙 위반을 비용과 공수로 환산할 때, 우리는 무엇을 가정하고 무엇을 모른다고 인정해야 하는가

---

들어가며 — "고치는 데 얼마나 걸려요?"라는 질문 앞에서

공공 웹사이트 KRDS 분석을 마치고 나면, 어김없이 하나의 질문이 따라온다.

"이거 다 고치는 데 얼마나 걸려요? 예산은 어느 정도 잡으면 되나요?"

분석을 의뢰한 담당자는 결과표를 들고 예산 회의에 들어가야 한다. 위반 항목 196개, 미통과 규칙 228개 — 이 숫자를 그대로 가져가면 윗선에서 돌아오는 말은 뻔하다. "그래서 얼마요?" 그 질문에 답이 없으면 예산은 잡히지 않고, 예산이 없으면 개선은 시작되지 않는다.

ViewCheck LLM 분석의 24개 기능 중 '비용·MM' 카드는 바로 이 지점을 위해 만들어졌다. 위반 개수와 심각도를 기반으로 개선에 필요한 공수(Man-Month, 이하 MM)와 비용을 추정해 보여주는 기능이다.

그런데 이 글을 시작하면서 가장 먼저 하고 싶은 말은 이것이다. 이건 추정이다. 추정이 아닌 것처럼 포장하면 안 된다. 공사비 견적처럼 설계도가 있고, 자재 가격이 있고, 노무비 기준이 있어서 ±10% 안에 맞출 수 있는 산정이 아니다. 소프트웨어 개발비 산정은 수십 년의 연구사가 있는 분야이고, 그 연구자들조차 "정확한 예측은 어렵다"고 인정한다.

우리가 할 수 있는 건 합리적인 가정의 구조를 만들고, 그 가정을 명시하고, 그 위에서 범위를 제시하는 것이다. '얼마짜리인지 모른다'는 막막함을 '이 범위 안이고, 이 가정이 바뀌면 달라진다'는 구조적 이해로 바꾸는 것. 그게 이 기능의 목표다.

이 글에서는 그 추정 모델의 방법론 — 무엇을 참고했고, 어떤 가정을 세웠으며, 어디서 한계를 인정하는지 — 을 가능한 한 솔직하게 풀어보겠다. 완성된 공식이 아니라, 지금도 다듬어가는 연구 노트로 읽어주기 바란다.

---

소프트웨어 공수 산정, 수십 년의 연구사

"소프트웨어 프로젝트 비용을 어떻게 추정하는가"는 소프트웨어 공학에서 가장 오래된 과제 중 하나다. 1950년대부터 컴퓨터 프로그래밍이 산업화되기 시작하면서, 사람들은 "이 코드를 짜는 데 얼마나 걸리나"를 예측하려 애썼다. 그리고 수십 년이 지난 지금도, 그 예측은 여전히 어렵다.

Barry Boehm이 1981년에 내놓은 COCOMO(COnstructive COst MOdel)는 소프트웨어 비용 추정 분야의 기념비적 모델이다. 그는 Software Engineering Economics라는 책을 통해, 소프트웨어의 규모(코드 라인 수, KLOC)와 개발 공수 사이의 관계를 수식으로 표현했다. 기본 공식은 이렇다.

공수(MM) = a × (KLOC)^b × ΠEM

여기서 a, b는 프로젝트 유형에 따른 상수이고, ΠEM은 복잡도·팀 숙련도·플랫폼 특성 등 여러 비용 인자(Cost Driver)들의 곱이다. 1981년에 63개 프로젝트 데이터를 기반으로 보정된 이 모델은, 이후 COCOMO II라는 이름으로 계속 발전했다. USC(University of Southern California)의 Boehm 연구팀은 1995년부터 COCOMO II를 개발해, 161개 프로젝트 데이터로 보정하고 현대적인 개발 환경(재사용, 객체지향, 나선형 개발 등)에 맞게 갱신했다(Boehm et al., Software Cost Estimation with COCOMO II, Prentice Hall, 2000).

COCOMO II는 세 가지 서브모델로 구성된다. 초기 타당성 검토 단계에서 쓰는 Application Composition 모델, 요구사항이 어느 정도 확정된 초기 설계 단계를 위한 Early Design 모델, 그리고 상세 설계 이후 정밀 추정을 위한 Post-Architecture 모델이 그것이다. 각 단계마다 정보의 완성도가 다르기 때문에, 추정의 정확도도 달라진다.

COCOMO의 한계는 코드 라인 수를 기준으로 한다는 점이다. 코드를 아직 짜지도 않은 기획 단계에서 KLOC를 추정하는 것은 그 자체로 또 하나의 추정이 필요하다. 이 '추정의 추정' 문제를 피하기 위해 나온 것이 기능점수(Function Point) 방법론이다.

---

기능점수(Function Point) — "코드보다 기능을 세자"

기능점수는 1979년 IBM의 Allan Albrecht가 개발한 개념으로, 소프트웨어가 사용자에게 제공하는 '기능의 크기'를 코드가 아닌 기능 단위로 측정한다. 핵심 발상은 이렇다. 소프트웨어를 얼마나 복잡한 코드로 짰느냐는 구현자의 선택이지만, 그 소프트웨어가 사용자에게 무엇을 해주느냐는 요구사항에서 도출할 수 있다.

기능점수는 크게 두 영역을 센다.

• 데이터 기능: 내부 논리 파일(ILF), 외부 인터페이스 파일(EIF) — 시스템이 관리하거나 참조하는 데이터 그룹
• 트랜잭션 기능: 외부 입력(EI), 외부 출력(EO), 외부 조회(EQ) — 시스템이 처리하는 사용자 요청

각 기능 유형에 단순·보통·복잡 세 등급을 매겨 가중치를 곱한 뒤 합산하면 '조정 전 기능점수(UFC)'가 나온다. 여기에 기술적 복잡도 인자들을 적용해 '최종 기능점수'를 얻는다. 이 방법은 IFPUG(International Function Point Users Group)가 국제 표준화를 주도했고, ISO/IEC 20926로 공식 표준이 됐다. 네덜란드 NESMA(Netherlands Software Metrics Users Association)의 방법도 별도로 ISO/IEC 24570으로 표준화돼 있다.

기능점수의 강점은 코드가 없어도 요구사항 단계에서 적용할 수 있다는 점이다. 시스템이 무엇을 해야 하는지 알면, 그 기능의 크기를 측정할 수 있다. 그리고 기능점수와 실제 개발 공수 사이의 역사적 데이터가 쌓이면, 새 프로젝트의 공수를 추정하는 데 쓸 수 있다.

한국에서는 이 기능점수 방법론이 공공 SW 사업 대가 산정의 공식 기준으로 자리잡았다.

---

한국의 공식 기준 — SW사업 대가산정 가이드

한국소프트웨어산업협회(KOSA, 현재는 한국인공지능·소프트웨어산업협회)는 매년 「SW사업 대가산정 가이드」를 개정·공표한다. 이 가이드는 국가기관과 공공기관이 SW 사업을 추진할 때 예산 수립, 사업 발주, 계약 시 적정 대가를 산정하기 위한 기준으로 사용된다. 법적 근거는 「소프트웨어사업 대가의 기준」(과학기술정보통신부 고시, 국가법령정보센터 행정규칙)에 있다.

가이드에서 SW 개발비 산정 방법은 크게 두 가지로 나뉜다.

1. 기능점수(FP) 기반 산정

SW 개발비 = 기능점수(FP) × FP당 단가 × 보정계수

2024년 개정판에서 기능점수당 단가는 기존 553,114원에서 9.5% 인상된 605,784원으로 현행화됐다(CIO Korea, 2024.5.13). 보정계수는 규모, 연계복잡성, 성능 요구 수준, 운영환경 호환성, 보안성 수준 5가지 인자를 반영한다.

2025년 개정판에서는 평균임금 상승폭(4.2%)을 반영해 ISP 단가는 11,290,936원, ISP/BPR 단가는 11,574,855원, EA/ITA 단가는 11,598,238원으로 조정됐다(바이라인네트워크, 2025.8).

2. 투입공수(M/M) 기반 산정

SW 개발비 = Σ(등급별 단가 × 투입 M/M) + 직접경비 + 제경비 + 기술료

M/M 방식은 프로젝트에 투입되는 인력의 등급과 기간으로 비용을 산정한다. 2019년 이후 SW기술자 등급 체계가 개편됐지만, 초급·중급·고급·특급으로 구분되는 직무별 평균임금은 한국소프트웨어산업협회가 매년 실태조사를 통해 공표한다.

2026년 적용 SW기술자 노임단가는 2025년 실태조사를 기반으로 전년 대비 4.7% 상승해 공표됐다(한국소프트웨어산업협회, 2025.12). 한국물가정보에 따르면 등급별 단가가 17개 직무별로 상이하게 책정되어 있다.

제경비율도 중요한데, SW사업의 기획(컨설팅)·운영 단계의 제경비율은 한 차례 개정을 통해 기존 110120%에서 140150%로 상향된 바 있다(전자신문, 2022).

---

KRDS 위반에 기능점수를 어떻게 적용할 수 있을까

자, 이제 본론이다. KRDS 846개 규칙 위반을 개선 비용으로 환산하는 일에, 위에서 소개한 공식 기준들을 어떻게 연결할 수 있을까.

결론부터 말하면 — 직접 연결은 안 된다. 기능점수 방법론과 COCOMO는 '새로운 소프트웨어를 개발하는 공수'를 추정하는 모델이다. KRDS 위반 개선은 기존 소프트웨어를 수정하는 유지보수·리팩토링 작업이다. 성격이 다르다.

새 기능 개발과 기존 결함 개선 사이의 공수 차이는 소프트웨어 공학에서 잘 알려진 주제다. 일반적으로 결함 수정은 새 기능 개발보다 더 많은 '코드 이해 비용'이 든다. 어디를 고쳐야 하는지 찾고, 고쳤을 때 다른 부분이 깨지지 않는지 검증하는 과정이 추가된다. 이 검색-이해-수정-검증 사이클은 '얼마나 잘 설계된 코드인가'에 따라 공수가 크게 달라진다.

그렇다면 KRDS 위반 개선의 공수를 어떻게 추정할 수 있을까. 우리가 접근한 방식은 '규칙 유형별 난이도 분류'와 '기준 단위 공수' 두 가지를 결합하는 것이다.

---

ViewCheck의 추정 접근 — 규칙 유형별 난이도 분류

ViewCheck LLM 분석의 비용·MM 카드가 사용하는 추정 로직의 구조를 설명하겠다. 이건 공식 인증을 받은 표준 방법론이 아니다. 우리가 KRDS 846개 규칙의 특성을 분석하고, 실제 개선 사례에서 수집한 경험적 관찰을 바탕으로 설계한 추정 모델이다. 여기에는 많은 가정이 내포되어 있고, 그 가정들은 사이트마다, 팀마다, 상황마다 달라질 수 있다.

심각도(Severity) 기반 분류

먼저 각 위반을 심각도에 따라 분류한다. ViewCheck는 KRDS 규칙에 P0~P3 네 단계의 우선순위를 부여한다.

• P0 (Critical): 핵심 기능 사용 불가, 접근성 완전 차단 — 예: 화면 낭독기가 전혀 읽을 수 없는 이미지, 키보드 접근 불가 핵심 UI
• P1 (High): 주요 기능에 심각한 장애 — 예: 색상 대비 심각 미달, 폼 오류 안내 없음
• P2 (Medium): 사용성 저하, 법적 기준 미충족 — 예: 버튼 라벨 불명확, ARIA 속성 누락
• P3 (Low): 경미한 개선 권장 사항 — 예: 의미론적 마크업 미세 조정, 스타일 토큰 불일치

작업 유형(Task Type) 분류

동시에 각 위반을 개선 작업의 성격으로 분류한다.

작업 유형	설명	예시
Quick Fix	코드 한두 줄 수정, 속성 추가/변경	img alt 추가, aria-label 추가, CSS 색상값 변경
Component Fix	컴포넌트 하나의 구조적 수정	버튼 마크업 재작성, 폼 필드 aria 재설계
Pattern Fix	여러 페이지에 반복 적용 필요한 패턴 수정	사이트 전체 네비게이션 ARIA 재설계, 일관된 오류 메시지 패턴 적용
Structural Fix	페이지 구조·아키텍처 수준의 변경	헤딩 계층 전면 재설계, 레이아웃 구조 변경

기준 단위 공수(Unit Effort) 설정

각 작업 유형별로 '참조 기준 공수'를 설정했다. 이 값들은 실제 유사 사업 사례와 산업 경험 수치를 참고해 설정한 것이지만, 어디까지나 참고 기준점이지 고정값이 아니다.

작업 유형	참조 기준 공수(시간)	비고
Quick Fix	0.5~2h	속성 추가·CSS값 변경 수준
Component Fix	2~8h	단일 컴포넌트 재설계
Pattern Fix	8~24h	패턴 설계 + 전체 적용
Structural Fix	24~80h	구조 재설계 + 전면 검증

1 Man-Day = 8시간, 1 Man-Month = 21일 = 168시간으로 환산한다.

추정 공식

각 미통과 규칙에 대해 작업 유형을 분류하고 기준 공수를 적용한다.

추정 총 공수(시간) = Σ (규칙별 기준 공수 × 복잡도 보정계수)

복잡도 보정계수:
  - 사이트 규모 소형(~30p): 1.0
  - 중형(31~100p): 1.3
  - 대형(101~500p): 1.6
  - 초대형(500p+): 2.0

추정 MM = 추정 총 공수(시간) ÷ 168

추정 비용 = 추정 MM × 적용 등급 평균 노임단가(월)

노임단가는 상황에 따라 초급(풀스택 작업)과 중급(설계 포함) 단가를 혼합 적용한다.

---

추정에 내재된 불확실성 — 솔직하게 나열하기

이 추정 모델은 많은 가정 위에 서 있다. 그 가정들이 흔들리면 추정치도 흔들린다. 사용자가 이 추정치를 올바르게 해석하려면, 어떤 가정이 어떻게 추정치에 영향을 주는지 이해하는 것이 중요하다.

불확실성 1: 기존 코드 품질 (가장 큰 변수)

개선 공수에 가장 큰 영향을 주는 건 '기존 코드가 얼마나 잘 설계되어 있는가'다. alt 속성 하나를 추가하는 데 5분 걸리는 코드가 있고, 컴포넌트 구조가 얽혀 있어서 같은 변경에 하루가 걸리는 코드도 있다. 외주 개발, 여러 세대 개발자의 손길, 레거시 프레임워크 — 이런 요소들이 코드 수정 비용을 예측 불가하게 만든다. ViewCheck가 DOM과 스크린샷으로 보는 건 '결과물'이지 '코드의 내부 구조'가 아니다. 그래서 우리는 코드 품질에 대해 직접 측정하지 않고, 범위로 제시한다.

불확실성 2: 담당 개발자의 숙련도와 KRDS 이해도

같은 위반이라도 KRDS와 웹 접근성에 익숙한 개발자가 고치는 것과 처음 접하는 개발자가 고치는 건 공수가 다르다. 더 중요한 건, 틀리게 고치는 경우다. 규칙을 잘못 이해하고 수정한 후 재검증을 거쳐야 하면 공수가 크게 늘어난다. 우리 추정치는 '규칙을 이해한 개발자'를 전제로 한다. 교육과 내재화에 필요한 시간은 별도로 고려해야 한다.

불확실성 3: 테스트 및 검증 범위

개선 작업의 공수 중 상당 부분은 '고쳤을 때 다른 곳이 안 깨지는지' 검증하는 데 쓰인다. 자동화 테스트가 잘 갖춰진 사이트라면 이 비용이 낮지만, 그렇지 않은 경우 수동 검증 시간이 개발 시간만큼 걸릴 수 있다. 우리 기준 공수에는 단위 수정 공수만 반영되어 있고, 통합 테스트 공수는 별도 항목으로 추가해야 한다.

불확실성 4: 병렬 개선의 시너지

사이트 전체에서 같은 컴포넌트를 일괄 수정하는 경우, 실제 공수는 '건수 × 단위 공수'보다 작을 수 있다. 컴포넌트 라이브러리를 고치면 여러 페이지에 자동 반영되기 때문이다. 반대로 레거시 코드가 컴포넌트 재사용 없이 복사·붙여넣기 방식으로 구축되어 있다면, 100개 페이지를 하나하나 고쳐야 한다. 우리 모델은 중간을 가정하지만, 실제 현장은 양 극단을 오가는 경우가 많다.

불확실성 5: 비기술적 비용

회의, 검토, 승인, 문서화, 커뮤니케이션 — 개발 공수 외에 프로젝트 관리에 드는 오버헤드는 실제 총 비용의 20~40%를 차지하기도 한다. 우리 추정에는 순수 기술 공수만 반영되어 있다. 제경비·기술료 등은 공식 SW사업 대가산정 기준에 따라 별도 가산이 필요하다.

---

기술부채(Technical Debt)라는 렌즈로 보기

소프트웨어 세계에서 KRDS 위반을 이해하는 또 하나의 유용한 렌즈가 있다. **기술부채(Technical Debt)**다.

기술부채는 Ward Cunningham이 1992년에 제안한 개념으로, 더 오래 걸리는 올바른 방법 대신 빠른 지름길을 택할 때 발생하는 미래의 추가 비용을 빚에 비유한 것이다. 지금 당장 코딩하기 쉬운 방식으로 만든 코드는 나중에 유지보수할 때, 또는 기준을 충족하도록 수정할 때 더 많은 비용을 요구한다.

최근 연구에서는 이 기술부채의 비용을 정량화하려는 시도들이 있었다. 미국 American Impact Review(2026)의 분석에 따르면, 1백만 줄 규모의 코드 프로젝트에서 기술부채로 인한 귀속 비용은 연간 약 30만 6,000달러로 추산된다. 5년 기간으로 환산하면 150만 달러(개발자 2만 7,500시간)에 이른다. 또한 SonarSource의 기술부채 연구에 따르면 조직들이 기술 예산의 20~40%를 신규 혁신이 아닌 기존 부채 해소에 쓰고 있다는 추정도 나온다.

단, 이 수치들도 추정이다. 특히 기술부채 산정은 SonarQube 같은 도구가 자동으로 '수정 시간'을 추정하기도 하지만, 그 추정치의 실증적 검증이 아직 부족하다는 점은 연구자들도 인정한다(ResearchGate, "On the Technical Debt Prioritization and Cost Estimation with SonarQube tool", 2020).

KRDS 위반은 이 기술부채의 특수한 형태다. 처음부터 KRDS 기준을 고려해 만들었다면 추가 비용이 없었을 것을, 나중에 개선하려니 '부채를 갚는' 비용이 드는 구조다. 그리고 부채를 오래 묵힐수록 이자가 쌓이듯, 사이트가 커지고 코드가 복잡해질수록 KRDS 개선 비용도 올라간다.

---

웹 접근성 개선 비용 — 해외 사례와 벤치마크

국내 KRDS 개선 비용에 대한 구체적인 공개 벤치마크는 찾기 어렵다. 반면 미국에서는 ADA(Americans with Disabilities Act) 접근성 준수와 관련한 비용 사례가 비교적 공개적으로 논의된다.

Accessibility.Works에 따르면 웹 접근성 구현 프로세스의 일반적인 비용 구조는 이렇다(Accessibility.Works, "Budgeting for Web Accessibility", 2023). 초기 감사(Assessment) 비용부터 개선 스프린트, 연간 모니터링, 지속적 개발 단계별 비용이 발생하며, 1년차 총 비용이 3만5만 달러 규모가 되는 경우가 흔하다. 그리고 이 비용의 수익률(ROI)은 18개월 안에 400600%에 달한다는 추산도 있다.

이 해외 수치를 국내에 그대로 적용할 수는 없다. 한국의 SW기술자 노임단가 수준, 사이트 구조의 차이, KRDS가 WCAG보다 더 광범위한 범위를 다루는 점 등이 다르다. 하지만 방향성은 참고할 수 있다. 개선을 나중으로 미루면 비용이 더 든다. 처음부터 KRDS를 고려해 만든 사이트보다, 이미 구축된 사이트를 소급 적용하는 비용이 더 높다. htdhealth.com의 분석에서는 "접근성을 나중에 추가하면 처음부터 구현하는 것보다 10배 비용이 더 든다"는 추산도 있다.

---

ViewCheck 추정의 4가지 출력값

ViewCheck 비용·MM 카드가 사용자에게 보여주는 추정치는 단일 숫자가 아니라 구조화된 범위다.

1. 규칙별 작업 목록 (우선순위별 정렬)

미통과 규칙들을 P0~P3 순서로 나열하고, 각 규칙에 예상 작업 유형과 기준 공수 범위를 표시한다. 사용자는 이 목록을 보며 "어디에 얼마를 써야 하는가"를 판단할 수 있다.

2. 총 추정 공수 (범위로 제시)

"최소 X시간 ~ 최대 Y시간"으로 범위를 제시한다. 단일 숫자가 아닌 범위로 제시하는 것은, 위에서 설명한 불확실성들을 직접적으로 반영하기 위해서다. 최소값은 '코드가 잘 설계된 경우, 숙련된 개발자 기준', 최대값은 '레거시 코드, 구조적 수정 필요, 통합 테스트 포함' 기준이다.

3. 우선순위 기반 단계적 개선 추정

모든 위반을 한 번에 고치는 시나리오 외에, P0만 먼저 고치는 시나리오, P0+P1을 1단계로 고치는 시나리오 등 단계별 추정을 제시한다. 실제 예산 집행은 한 번에 이루어지는 경우보다 연도별·단계별로 분산되는 경우가 많기 때문이다.

4. 참조 단가와 비용 범위

추정 MM에 SW기술자 평균 노임단가를 적용한 비용 범위를 표시한다. 단가는 KOSA 공표 기준의 중급 개발자 단가를 기준으로 하되, 사용자가 직접 조정할 수 있게 입력 필드를 제공한다. 우리가 단가를 일방적으로 결정하는 게 아니라, 사용자의 실제 조달 환경에 맞게 조정하는 것이 더 정확하기 때문이다.

---

왜 단일 숫자 대신 범위인가 — 추정의 불가능성에 대하여

소프트웨어 공학에는 '추정의 불가능성(Estimation Impossibility)'에 관한 오래된 논의가 있다. Frederick Brooks는 1975년 The Mythical Man-Month에서 "소프트웨어 개발에서 인력을 단순히 추가하는 것으로 지연된 프로젝트를 만회할 수 없다"는 'Brooks의 법칙'을 통해, 소프트웨어 공수 산정의 비선형적 복잡성을 지적했다. 9명의 여성이 1명의 아기를 한 달 만에 출산할 수 없듯이, 9명의 개발자가 1명이 9개월 할 일을 한 달에 해치울 수 없다는 것이다.

더 최근의 연구들도 추정의 어려움을 증명하는 데이터를 쌓아왔다. Capers Jones의 연구에 따르면 소프트웨어 프로젝트의 실제 공수는 초기 추정치 대비 평균 45~50% 초과하는 경향이 있다. Standish Group의 CHAOS 리포트도 수십 년간 소프트웨어 프로젝트의 예산 초과, 일정 지연 비율이 여전히 높다는 것을 보고해 왔다.

이 역사적 사실이 우리에게 가르쳐 주는 건 "추정하지 말라"가 아니다. "추정의 불확실성을 인정하고, 그 불확실성을 출력에 반영하라"다. 신뢰구간을 제시하는 통계와 같은 원리다. "5억 원이 필요합니다"보다 "3억~7억 원의 범위가 예상됩니다. 이 범위는 코드 복잡도와 팀 숙련도에 따라 달라집니다"가 더 정직하고, 실제로 더 유용하다. 의사결정자는 '정확한 숫자'가 아니라 '합리적 범위와 그 근거'를 필요로 한다.

---

실제 사례로 추정 구조 보기 — 가상 시나리오

구체적인 예시로 추정 구조가 어떻게 작동하는지 보여주겠다. 가상의 광역지자체 홈페이지를 분석했다고 가정하자.

시나리오: A 광역지자체 홈페이지 (가상)

분석 조건	값
분석 페이지 수	85페이지
KRDS 전체 규칙	846개
통과	289개 (34.2%)
미통과	228개 (26.9%)
해당없음	329개 (38.9%)
사이트 규모 분류	중형 (복잡도 보정계수 1.3)

작업 유형별 분류 (미통과 228개)

작업 유형	건수	기준 공수 (평균)	소계
Quick Fix	92건	1.5h	138h
Component Fix	85건	5h	425h
Pattern Fix	38건	16h	608h
Structural Fix	13건	50h	650h
합계 (보정 전)	228건		1,821h

보정계수 1.3 적용 후: 1,821h × 1.3 = 2,367h

테스트/검증 오버헤드(30% 가산): 2,367h × 1.3 = 3,077h

단계별 시나리오 공수 추정

단계	포함 범위	추정 공수	추정 MM
1단계 (P0+P1)	Critical + High (78건)	약 780h	약 4.6MM
2단계 (P2 추가)	+ Medium (120건)	약 1,600h	약 9.5MM
3단계 (P3 포함)	전체 (228건)	약 3,077h	약 18.3MM

2026년 적용 기준 SW 중급 개발자 월 단가(약 600만 원 기준, 제경비 포함 전 참조 수치) 적용 시:

단계	추정 비용 (제경비 제외)	비고
1단계	약 2,760만 원	P0+P1 긴급 개선
2단계	약 5,700만 원	누적
3단계	약 1억 1,000만 원	전체 개선

중요: 이 추정은 가상 시나리오에 기반한 예시다. 실제 비용은 코드 품질, 팀 구성, 테스트 인프라, 조달 방식에 따라 크게 달라질 수 있다. 제경비(140150%)와 기술료는 별도 가산이 필요하며, 이를 포함하면 총 비용은 약 22.5배 수준이 될 수 있다.

---

"그래서 얼마요"에 답하는 법 — 의사결정 지원 프레임

우리는 이 추정치를 어떻게 쓰기를 권장할까.

먼저 명확히 해야 할 건, 이 추정치는 예산 확보의 근거로 쓰는 것이지, 계약 금액의 기준으로 쓰는 게 아니라는 점이다. 실제 발주·계약을 위한 정밀한 산정은 전문 SW 사업 대가 산정 기관이나 공인된 기능점수 측정 전문가의 검토가 필요하다.

ViewCheck의 추정치가 유용한 경우:

1. 예산 수립 단계: "대략 얼마 규모의 예산을 요청해야 하는가"를 판단하는 데 사용. 정밀 산정 전에 규모를 파악하는 출발점.
2. 우선순위 결정: "제한된 예산 내에서 무엇부터 고쳐야 하는가"를 결정하는 데 사용. P0, P1만 먼저 처리하는 단계적 접근의 근거.
3. 이해관계자 커뮤니케이션: "왜 이 개선에 이 만큼의 비용이 필요한가"를 설명하는 데 사용. 위반 건수와 심각도, 작업 유형이 근거로 함께 제시되기 때문에 설명 가능한 추정이 된다.
4. 개선 전후 비교: 개선을 진행한 후 다시 분석을 실행해, 잔여 위반과 잔여 개선 비용이 얼마나 줄었는지 추적하는 데 사용.

ViewCheck의 추정치가 적합하지 않은 경우:

• 실제 계약·발주 금액 산정 — 공식 기관의 심층 검토 필요
• 법적 책임이 따르는 준수율 확인 — 전문 심사기관 인증 필요
• 개별 개발자의 성과 평가 기준 — 이 추정치는 사이트 수준 추정이지 개인 수준이 아님

---

추정 모델의 현재 한계와 개선 방향

솔직하게 우리 모델의 한계를 나열하겠다.

현재 한계

1. 규칙별 작업 유형 분류의 주관성: 현재 Quick Fix / Component Fix / Pattern Fix / Structural Fix 분류는 규칙의 카테고리와 메타데이터를 기반으로 자동 분류되지만, 분류의 정확도가 100%가 아니다. 실제 코드를 보지 않고는 어느 수준의 수정이 필요한지 알 수 없는 경우가 많다.

2. 코드 복잡도 직접 측정 불가: ViewCheck는 DOM과 스크린샷을 본다. 코드의 내부 구조, 컴포넌트 재사용 현황, 테스트 커버리지는 볼 수 없다. 이 정보 없이는 개선 공수의 핵심 변수를 놓치게 된다.

3. 병렬 개선 효과 모델링 미흡: 같은 컴포넌트 수정이 여러 위반을 한 번에 해소하는 경우, 단순 합산 방식은 비용을 과대추정할 수 있다. 이 시너지 효과를 정량화하는 모델이 아직 미흡하다.

4. 검증 데이터 부족: 우리 기준 공수 값들이 실제 KRDS 개선 사업 데이터로 검증되지 않았다. 유사 해외 사례를 참고했지만, 국내 공공 웹 환경에서의 실제 검증 데이터가 쌓여야 모델의 신뢰도가 올라갈 수 있다.

개선 방향

1. 실제 개선 사례 데이터 수집: ViewCheck 사용 기관들이 실제 개선을 진행한 후, 실제 공수와 추정 공수의 차이를 피드백 받아 모델을 보정하는 루프를 만들고 싶다. 이 데이터가 쌓일수록 추정 정확도가 올라갈 수 있다.

2. 코드 복잡도 간접 지표 활용: DOM의 구조 복잡도, 중복 패턴 수, 비표준 마크업 비율 같은 간접 지표로 코드 복잡도를 간접 추론하는 방법을 연구하고 있다. 완벽하진 않지만 없는 것보다 나을 수 있다.

3. 공식 기능점수 연동: 특정 위반을 기능점수로 환산하는 매핑 테이블을 만들어, KOSA의 공식 기준과 연동 가능한 추정 경로를 열어두는 것도 검토 중이다. 공공 조달과의 연계를 위해서는 결국 공식 기준과의 접점이 필요하다.

---

공공 SW 사업과 KRDS 개선 예산 — 제도적 맥락

KRDS 개선 비용을 논할 때, 이걸 독립된 기술 과제가 아니라 공공 SW 사업의 맥락 안에서 봐야 한다는 점도 중요하다.

행안부 「전자정부 웹사이트 품질관리 지침」(고시 제2025-46호)은 공공기관의 웹사이트 품질 관리 의무를 규정한다. 이 지침에 따라 기관들은 정기적인 품질 진단을 받고, 미흡한 항목을 개선해야 한다. 개선 과제는 대개 SW 유지보수 사업이나 개편 사업으로 발주된다.

이때 공식 발주 단계에서는 「SW사업 대가산정 가이드」가 적용된다. 기능점수 방식이나 M/M 방식 중 사업의 성격에 맞는 방식을 선택해 대가를 산정하고, 계약을 맺는다. 우리 ViewCheck 추정치는 이 공식 발주 전 단계 — 예비 예산을 확보하고, 사업의 규모를 가늠하고, 발주 방식을 결정하는 단계 — 에서 유용하게 쓰일 수 있다.

공공 조달에서 "얼마가 필요한지" 모르는 상태로 예산 요청서를 쓸 수는 없다. 그 예산 요청서의 근거를 만드는 데 ViewCheck의 추정치가 쓰인다면, 그게 이 기능이 기여하는 실질적인 가치다.

---

'고치는 비용'과 '안 고치는 비용'

비용 이야기를 할 때 자주 빠지는 관점이 있다. '고치는 데 드는 비용'만 보고, '안 고쳤을 때 드는 비용'은 잘 보지 않는 경향이다.

KRDS나 웹 접근성 기준을 충족하지 않은 채로 운영되는 사이트가 치르는 비용은 여러 형태로 나타난다.

법적 리스크: 「장애인차별금지 및 권리구제 등에 관한 법률」에 따라 공공기관의 웹 접근성 미준수는 차별로 인정될 수 있다. 시정 권고부터 시작해 시정명령, 나아가 행정적 책임까지 이어지는 구조다. 한국인권위원회의 권고 사례 중에는 공공기관이 "예산이 없어 웹접근성을 개선하지 못했다"고 주장했으나, 기재부장관에게 예산 확보 노력을 권고하는 결정이 내려진 사례도 있다(국가인권위원회 보도자료).

사용자 이탈: 접근성 미준수로 인해 장애가 있는 사용자가 서비스를 이용하지 못하면, 그 서비스가 담당하는 행정 서비스의 이용 격차가 발생한다. 디지털 포용의 관점에서 이건 단순한 기술 문제가 아니다.

사이트 개편 때의 누적 비용: 처음부터 KRDS를 고려하지 않고 구축된 사이트를 수년 후 전면 개편할 때, 기술부채가 쌓인 코드를 다루는 비용은 처음부터 제대로 구축했을 때보다 훨씬 크다. "지금 당장 개선 비용을 아끼면, 나중에 더 큰 비용을 치른다"는 공식은 SW 세계 어디서나 반복되는 패턴이다.

htdhealth.com의 분석에 따르면 "접근성을 나중에 추가하면 처음부터 구현하는 것보다 10배 비용이 더 든다"는 추산이 있다. 물론 이 '10배'도 추정이고 맥락마다 다르다. 하지만 방향은 분명하다. 지금 개선하는 게 나중보다 싸다.

---

'예산을 정당화하는 도구'로서의 비용 추정

조금 다른 각도에서 이 기능의 의미를 들여다보자.

많은 공공기관에서 KRDS나 웹 접근성 개선 예산이 배정되지 않는 이유는 "그게 얼마나 드는 일인지" 구체적으로 설명하기 어렵기 때문이다. "접근성이 중요합니다"라는 당위는 있지만, 그걸 예산 회의에서 숫자로 제시하기 어려운 실무자의 딜레마가 있다.

ViewCheck의 비용·MM 카드는 이 딜레마에 도구를 제공하려는 시도다. "846규칙 분석 결과 228개 위반이 있으며, 작업 유형 분류 기준으로 약 3,000시간 개선 공수가 추정됩니다. 우선순위별로 1단계(P0+P1) 약 780시간, 약 2,800만 원 규모의 예산이 필요합니다" — 이 구조를 갖춘 설명이 가능해진다.

추정의 불확실성은 있다. 그러나 아무 숫자도 없는 것보다는, 합리적인 가정이 명시된 범위 추정이 의사결정에 훨씬 유용하다. 담당자가 그 추정치를 들고 예산 회의에 들어갈 수 있다면, 그걸로 충분히 가치 있다.

물론 우리도 안다. 추정치가 실제와 크게 다를 때 생기는 신뢰 문제를. 그래서 우리는 추정이라는 사실을 화면에 명시하고, 가정과 범위를 함께 보여주고, "실제 발주를 위해서는 전문 기관의 심층 산정이 필요합니다"라는 안내를 빼지 않는다. 도구가 한계를 인정하는 것이, 그 도구를 더 신뢰할 수 있게 만든다.

---

추정 모델 설계에서 배운 것들

이 기능을 설계하고 구현하면서 우리가 깨달은 몇 가지를 공유한다.

배움 1: "얼마나 정확한가"보다 "가정이 투명한가"가 더 중요하다

소프트웨어 추정 연구자 Steve McConnell은 그의 책 Software Estimation에서 이렇게 썼다. "소프트웨어 추정의 목표는 미래를 예측하는 것이 아니라, 프로젝트 범위에 대한 충분한 제어력을 갖는 것이다." 정확한 숫자를 내놓으려 애쓰기보다, 어떤 가정 위에 서 있는 숫자인지 명확히 하는 것이 실제로 더 유용하다.

배움 2: 규칙의 심각도가 비용보다 우선이다

처음에는 비용 규모를 보여주는 것을 핵심으로 생각했다. 그런데 실제 사용자 피드백에서 더 유용하게 쓰이는 건 "무엇부터 고쳐야 하는가"였다. P0 위반 3개를 먼저 고치는 것이 P3 위반 50개를 고치는 것보다 훨씬 중요하고, 비용도 작다. 심각도 기반 우선순위가 비용 총액보다 더 유용한 정보였다.

배움 3: 범위 추정은 단일 추정보다 더 신뢰받는다

"약 18MM이 필요합니다"보다 "최소 12MM, 최대 25MM이 추정되며, 이 범위는 코드 복잡도에 따라 달라집니다"가 더 신뢰받는다. 처음에는 직관에 반하는 것처럼 느껴졌다. 하지만 사용자들은 불확실성을 인정하는 추정을 오히려 더 믿었다.

배움 4: 비용 추정은 단독으로 쓰이지 않는다

비용·MM 카드는 항상 다른 카드들과 같이 읽힌다. 법적 리스크 카드("이 위반이 어떤 법적 의무와 연결되는가"), 개선 로드맵 카드("어떤 순서로 개선해야 하는가"), 임원보고서 카드("이걸 한 페이지로 보고해야 한다면"). 이 맥락 안에서 비용 추정이 의미를 가진다.

---

다른 분야의 추정 방법론에서 배울 것

소프트웨어가 아닌 다른 분야는 공수 추정 문제를 어떻게 다루는가.

건설 공사 견적: 설계도가 확정되면, 단위 자재 비용과 단위 노무비에 물량을 곱해 적산(積算)한다. 핵심은 물량(규모)과 단가(비용) 두 가지 변수를 분리해 관리하는 것이다. SW에서 물량은 기능점수 또는 코드량에 해당하고, 단가는 노임단가에 해당한다. KRDS 위반에서 물량은 위반 건수이고, 단가는 위반 유형별 기준 공수다.

법률 서비스 견적: 시간당 단가(hourly rate)에 예상 시간을 곱한다. 문제는 시간을 정확히 예측하기 어렵다는 것. 그래서 상한선(cap)을 설정하거나 단계별 계약을 하는 방식이 일반적이다. 우리가 단계별 시나리오(1단계/2단계/3단계)를 제시하는 것도 비슷한 발상이다.

국방 조달의 파라미터 추정: 미 국방부는 PERT(Program Evaluation and Review Technique)를 써서 "낙관적 추정 / 현실적 추정 / 비관적 추정" 세 값의 가중 평균으로 기댓값을 계산한다. 공식은 E = (O + 4M + P) / 6이다. 이 접근은 단일 숫자 대신 세 시나리오의 분포로 불확실성을 표현한다. 우리가 최소·최대 범위를 제시하는 것과 맥락이 같다.

어느 분야든 불확실성이 클수록, 단일 추정보다 범위 추정이 유용하다. 소프트웨어는 특히 그 불확실성이 크다. KRDS 위반 개선은 그 안에서도 더 불확실성이 큰 영역이다.

---

추정치를 어떻게 검증할 수 있을까

우리 추정 모델의 신뢰도를 높이려면 실제 데이터로 검증이 필요하다. 그 검증 루프는 어떻게 만들 수 있을까.

가장 이상적인 방법은 이렇다. ViewCheck로 분석 → 비용·MM 추정 → 실제 개선 사업 수행 → 실제 공수 데이터 수집 → 추정과 실제의 차이 분석 → 모델 보정 → 다음 추정의 정확도 향상. 이 루프를 돌리려면 데이터가 필요하고, 데이터는 실제 개선 사업이 있어야 쌓인다.

아직 우리는 이 루프를 충분히 돌리지 못했다. 초기 단계라 피드백 데이터가 적다. 그래서 지금의 추정치는 "완성된 모델의 출력"이 아니라 "베이스라인을 잡기 위한 첫 번째 가설"에 가깝다.

이걸 솔직하게 말하는 이유는, 추정치를 가져다 쓰는 사람이 그 한계를 알아야 하기 때문이다. 한계를 모르는 채 추정치를 사용하면, 한계가 드러났을 때 신뢰가 무너진다. 처음부터 한계를 명시하면, 한계가 드러났을 때 "예상된 범위 내의 오차"로 해석될 수 있다.

---

ViewCheck 비용·MM 카드, 실제로는 이렇게 생겼다

실제 화면에서 비용·MM 카드는 어떻게 생겼는지 설명하면, 단계별로 이런 정보를 보여준다.

첫 번째 블록: 전체 요약

• 분석된 총 위반 건수
• 전체 추정 공수 범위 (시간, MM)
• 단계별 시나리오 요약 (P0만, P0+P1, 전체)

두 번째 블록: 우선순위별 상세

• P0: 건수, 주요 위반 목록, 추정 공수
• P1: 건수, 주요 위반 목록, 추정 공수
• P2: 건수, 추정 공수
• P3: 건수, 추정 공수

세 번째 블록: 작업 유형 분류

• Quick Fix 몇 건 / Component Fix 몇 건 / Pattern Fix 몇 건 / Structural Fix 몇 건
• 작업 유형별 추정 공수 소계

네 번째 블록: 비용 추정

• 적용 노임단가 참조값(조정 가능)
• 단계별 비용 범위
• 주요 가정 명시 ("이 추정은 X, Y, Z를 가정합니다")

다섯 번째 블록: 주의사항

• "본 추정치는 참고 목적입니다. 실제 발주·계약을 위해서는 공인 기관의 공식 대가산정이 필요합니다."
• "코드 복잡도, 팀 숙련도에 따라 실제 공수는 추정치의 0.5~2배 범위에서 달라질 수 있습니다."

이 다섯 번째 블록이 가장 중요하다고 우리는 생각한다. 추정치를 보여주는 것 못지않게, 그 추정치의 한계를 명시하는 것이 책임 있는 도구의 태도다.

---

마무리 — "모른다"고 말하는 용기

소프트웨어 공수 산정은 어렵다. KRDS 개선 비용은 특히 더 어렵다. 코드를 직접 보지 않으면 모르는 것들이 너무 많다.

그렇다고 "모르니까 추정하지 않겠다"는 답도 아니다. 예산을 잡고, 우선순위를 세우고, 이해관계자를 설득해야 하는 담당자에게는 어떤 형태로든 숫자가 필요하다.

우리가 찾은 절충점은 이것이다. 합리적인 가정의 구조를 만들고, 그 가정을 명시하고, 범위로 제시하고, 한계를 인정한다. COCOMO II와 기능점수 방법론의 역사를 참고하고, 「SW사업 대가산정 가이드」의 공식 기준을 참조하되, 우리 모델이 그것들과 다른 지점을 솔직하게 밝힌다.

이 기능이 앞으로 어떻게 발전할지는 아직 모른다. 실제 개선 데이터가 쌓여야 모델을 보정할 수 있고, 보정이 쌓여야 신뢰도가 올라간다. 지금은 첫 번째 가설로, 그 가설을 최대한 투명하게 공개한 것이다.

"고치는 데 얼마나 걸려요?"라는 질문에, 우리가 제공할 수 있는 가장 정직한 답은 이렇다.

"위반 228개를 분석한 결과, 최소 12MM에서 최대 26MM 범위가 추정됩니다. 이 범위는 코드 복잡도와 팀 숙련도에 따라 달라집니다. P0와 P1 긴급 과제만 먼저 처리한다면 약 5MM, 3천만 원 안팎의 예비 예산으로 시작할 수 있습니다. 정확한 발주 금액은 전문 기관의 심층 산정이 필요합니다."

이 답에 단정은 없다. 하지만 결정을 내릴 수 있는 구조가 있다. 그게 추정이 줄 수 있는 최선이다.

다음 편에서는 다른 주제로 이어가겠다.

---

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 WebSearch로 검증했다. 국내 공식 기준과 해외 연구를 함께 실었다.

국내 — 공식 기준 / 정책자료

1. 한국인공지능·소프트웨어산업협회(KOSA), 「SW사업 대가산정 가이드 2024년 개정판」, 2024.5.13. https://www.sw.or.kr/site/sw/ex/board/View.do?cbIdx=276&bcIdx=63607&searchExt1=
2. 한국인공지능·소프트웨어산업협회(KOSA), 「SW사업 대가산정 가이드 2025년 개정판」 공표, 2025.8. (2025년 평균임금 상승폭 4.2% 반영, ISP 단가 11,290,936원) https://byline.network/2025/08/8112/
3. 국가법령정보센터, 「소프트웨어사업 대가의 기준」 행정규칙 (과학기술정보통신부 고시). https://www.law.go.kr/LSW/admRulInfoP.do?admRulSeq=5164
4. 한국인공지능·소프트웨어산업협회(KOSA), 「2026년 적용 SW기술자 평균임금 공표」 (2025년 실태조사 기반, 전년 대비 4.7% 상승), 2025.12. https://www.sw.or.kr/site/sw/ex/board/View.do?cbIdx=304&bcIdx=64717&searchExt1=
5. 행정안전부, 「전자정부 웹사이트 품질관리 지침」 (행정안전부고시 제2025-46호, 2025.6.25). https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
6. 국가인권위원회, 공공기관 웹 접근성 개선 권고 보도자료. https://www.humanrights.go.kr/site/program/board/basicboard/view?boardtypeid=24&boardid=7607623&menuid=001004002001
7. CIO Korea, "KOSA, SW사업 대가산정 가이드 개정판 공표 — 단가 9.5% 인상", 2024.5.13. https://www.cio.com/article/3521303/kosa-sw사업-대가산정-가이드-개정판-공표-단가-9-5-인상.html
8. 바이라인네트워크, "소프트웨어 기능점수(FP) 단가 60만5784원, 9.5% 상향 조정", 2024.5.13. https://byline.network/2024/05/13-363/

해외 — 소프트웨어 공학 / 비용 추정 / 기술부채

9. Barry W. Boehm et al., Software Cost Estimation with COCOMO II, Prentice Hall, 2000. (COCOMO II 모델 원전; USC CSSE 리서치 그룹, 161개 프로젝트 데이터 기반 보정) https://boehmcsse.org/tools/cocomo-ii/
10. IFPUG, "Early Function Point Analysis and Consistent Cost Estimating", 2022. (기능점수(FP) 국제 표준 IFPUG, ISO/IEC 20926 관련 자료) https://ifpug.org/wp-content/uploads/2022/06/uTip003EarlyFPAandConsistentCostEstimating.pdf
11. LedaMC, "What are IFPUG Function Points". (IFPUG FP 방법론 설명) https://www.leda-mc.com/en/what-are-function-points/
12. American Impact Review, "Technical Debt Quantification and Its Impact on Software Delivery Performance: A Cost-Benefit Analysis Framework for Enterprise Systems", 2026. (기술부채 1MM LoC당 연 $306,000 비용 추산) https://americanimpactreview.com/article/e2026034
13. SonarSource, "New Research from Sonar on Cost of Technical Debt". (기술 예산의 20~40%가 부채 해소에 소요) https://www.sonarsource.com/blog/new-research-from-sonar-on-cost-of-technical-debt
14. ResearchGate, "On the Technical Debt Prioritization and Cost Estimation with SonarQube tool", 2020. (SonarQube 추정치의 실증 검증 필요성 연구) https://www.researchgate.net/publication/345632101_On_the_Technical_Debt_Prioritization_and_Cost_Estimation_with_SonarQube_tool
15. Accessibility.Works, "Budgeting for Web Accessibility: The Process and Costs of ADA Compliance". (웹 접근성 구현 연도별 비용 구조) https://www.accessibility.works/blog/web-accessibility-process-cost-ada-compliance/
16. htdhealth.com, "The true cost of accessibility: Why adding accessibility later can cost 10x more". (접근성 후발 구현의 10배 비용 추산) https://htdhealth.com/insights/the-true-cost-of-accessibility-why-adding-accessibility-later-can-cost-10x-more/

---