UI 앱에서 UI 코드는 몇 %일까 — 모두가 인용하는 48%의 출처를 따라가 봤다

개인 웹 앱을 몇 개 운영하다 보니 문득 궁금해졌다. 화면이 있는 앱에서 UI 관련 코드는 전체의 몇 %나 될까? 체감으로는 "생각보다 많다"인데, 체감은 근거가 아니다. 그래서 학계와 오픈 커뮤니티에 실측 자료가 있는지 찾아봤고, 마지막에는 내 프로젝트 세 개를 직접 재봤다.

결론부터 적으면 이렇다. 학계의 대표 수치는 "코드의 48%, 구현 시간의 50%"다. 그런데 이 숫자를 따라가면 놀라운 사실이 하나 나온다 — 출처가 1992년의 설문조사 하나이고, 30년이 넘도록 이만한 규모의 재측정이 없어 W3C 문서까지 아직 이 숫자를 인용하고 있다. 그리고 내 프로젝트를 직접 재보니, 이 오래된 숫자는 지금도 대체로 유효했다.

이 질문에 답이 되는 세 갈래 자료

조사해 보니 "UI 코드가 몇 %인가"에 대한 근거는 세 갈래로 정리된다.

다이어그램 설명. "질문"에서 출발해 세 갈래의 근거로 갈라진다 — "학계"의 1992년 설문, 그 수치를 재인용하는 "표준 문서", 그리고 "직접 실측"이다. 세 갈래가 서로 독립적인 방법(자기보고 설문 / 문헌 인용 / 코드 줄 수 측정)인데도 모두 "절반 안팎"이라는 같은 대역을 가리킨다는 점이 이 글의 핵심이다. 어느 하나만 보면 "오래된 설문", "재인용", "표본 3개짜리 측정"이라 각각 약점이 있지만, 서로 다른 약점을 가진 세 근거가 같은 곳을 가리키면 신뢰가 생긴다.

1992년, 74명에게 물었다 — 코드의 48%

대표 수치의 출처는 Brad Myers와 Mary Beth Rosson이 CHI '92(인간-컴퓨터 상호작용 분야의 최상위 학회)에 발표한 "Survey on User Interface Programming"이다. 다양한 조직의 개발자들에게 설문을 배포해 74건의 응답을 받았고, 자신이 참여한 실제 프로젝트에서 UI가 차지하는 비중을 물었다. 결과는 이렇다.

측정 항목	UI가 차지하는 비중 (평균)
애플리케이션 코드	48%
설계(design) 시간	45%
구현(implementation) 시간	50%
유지보수(maintenance) 시간	37%

코드로도, 노력으로도 절반이다. "UI는 앱에 씌우는 껍데기"라는 직관과 정면으로 부딪히는 숫자다 — 껍데기가 아니라 본체의 반쪽이다. 왜 이렇게 큰가를 생각해 보면 오히려 자연스럽다. 사용자 입력은 언제 어떤 순서로 올지 모르고(이벤트 기반 프로그래밍), 상태가 바뀔 때마다 화면을 일관되게 갱신해야 하며, 오류·빈 값·로딩 같은 경계 상황마다 보여줄 화면이 따로 필요하다. 데이터 처리 로직은 입력과 출력이 정해진 함수로 닫히지만, UI는 사람이라는 예측 불가능한 입력원을 상대한다.

이 조사에서 놓치기 쉬운 디테일이 하나 더 있다. 어떤 도구를 쓰느냐에 따라 비중이 41%에서 60%까지 움직였다. 툴킷(버튼·메뉴 같은 위젯 부품 라이브러리)만 쓴 프로젝트는 UI에 시간·코드의 60% 안팎을 쏟았고, 인터페이스 빌더(화면을 마우스로 조립하는 도구)나 UIMS(User Interface Management System — UI 명세에서 코드를 생성해 주는 당시의 상위 도구)를 쓴 프로젝트는 41% 안팎까지 내려갔다. 즉 이 비율은 자연 상수가 아니라 도구 수준의 함수다 — 추상화가 높은 도구를 쓸수록 UI 비중이 내려간다는, 지금의 프레임워크·디자인 시스템 논의와 정확히 같은 구도가 34년 전에 이미 측정돼 있었다.

그 후 34년 — 아무도 다시 크게 재지 않았다

흥미로운 것은 그다음이다. 이 주제를 검색하면 학술 논문, 표준 문서, 블로그 어디서나 같은 48%가 나오는데, 전부 1992년 조사를 인용한 것이다. W3C의 모델 기반 UI 소개 문서는 이 수치를 인용하면서 "90년대 초에 측정된 값이며, 음성·제스처 같은 새 상호작용 방식이 퍼지면서 이 비중은 극적으로 늘었다"고 덧붙인다 — 늘었다는 방향 추정만 있고, 재측정 수치는 제시하지 못한다.

왜 재측정이 없을까? 짐작 가는 이유가 있다(이 단락은 추정이다). 첫째, "UI 코드"의 경계가 그때보다 흐려졌다. React 컴포넌트 하나에는 화면 구조와 상태 관리와 데이터 요청이 한 파일에 섞여 있어, 어디까지가 UI인지 자르는 기준부터 논쟁거리다. 둘째, 학계의 관심이 "비율 측정"에서 다음 단계로 넘어갔다. 최근 연구들은 UI 코드가 많다는 것을 전제로 깔고, GUI 테스트 자동화나 GUI 결함 분류처럼 그 많은 UI 코드를 어떻게 검증하느냐를 판다. 예컨대 GUI 결함 분류 연구는 오픈소스 5개(Inkscape, JabRef, Firefox Android 등)의 버그 리포트를 분석하는 식으로, 비율이 아니라 결함의 성질을 측정한다. 절반이라는 사실 자체는 이미 상식이 된 셈이다.

그래서 직접 재봤다 — 46%, 72%, 75%

문헌만으로는 아쉬워서, 운영 중인 개인 웹 앱 세 개의 코드를 직접 재봤다. 각각 대시보드 포털(프로젝트 A), 글쓰기 도구(프로젝트 B), 문서 브라우저·편집기(프로젝트 C)다. 셋 다 Python 서버 + 브라우저 화면 구조의 전형적인 소형 웹 앱이다.

# 측정 방법: 파일 확장자를 기준으로 한 거친 프록시(proxy)
# UI 코드   = *.html, *.css, *.js  (화면 구조·스타일·브라우저 동작)
# 서버 코드 = *.py                 (API·데이터 처리, 테스트 코드는 제외)
# .venv, node_modules, lib 등 외부 의존성 디렉터리도 제외
ui=$(find . -name '*.html' -o -name '*.css' -o -name '*.js' | xargs cat | wc -l)
py=$(find . -name '*.py' ! -path '*/tests/*' | xargs cat | wc -l)
echo "UI 비율: $((ui * 100 / (ui + py)))%"

코드 설명. 파일 확장자로 UI와 서버를 가르는, 의도적으로 단순한 측정이다. 한계를 분명히 해 두면 — Python 서버 코드 안에도 화면에 뿌릴 HTML을 조립하는 UI성 로직이 있을 수 있고, 반대로 JavaScript 안에도 화면과 무관한 데이터 가공 로직이 있다. 즉 이 숫자는 "UI 코드의 정확한 양"이 아니라 자릿수를 확인하는 프록시(대리 지표)다. 1992년 조사가 자기보고 설문이라는 다른 종류의 프록시였던 것과 마찬가지다.

프로젝트	UI 코드 (줄)	서버 코드 (줄)	UI 비율
A — 대시보드 포털	1,688	1,953	46%
B — 글쓰기 도구	3,418	1,110	75%
C — 문서 브라우저·편집기	3,523	1,383	72%

대시보드 포털은 1992년의 평균과 거의 같은 46%가 나왔고, 화면 상호작용이 많은 두 앱(에디터·브라우저류)은 70%를 넘겼다. 표본 3개짜리 측정이니 일반화할 수는 없지만, 방향은 문헌과 정확히 일치한다 — 절반은 기본이고, 상호작용이 밀도 높은 앱일수록 그 위로 올라간다. 에디터처럼 "앱 자체가 UI"인 부류에서 비중이 치솟는 것은 1992년 조사에서 도구에 따라 41~60%로 움직였던 것과 같은 이치다 — 이 비율을 결정하는 것은 앱의 성격과 도구이지, 시대가 아니었다.

정리 — 절반이라는 사실보다, 절반을 어떻게 대하느냐

UI 앱에서 UI 관련 코드는 대략 절반, 앱 성격에 따라 그 이상이다. 1992년의 설문(코드 48%·구현 시간 50%)과 2026년의 내 실측(46~75%)이 같은 대역에서 만난다. 34년 동안 프레임워크가 몇 세대나 바뀌었는데 비율이 그대로라는 것은, 도구가 UI 코드를 줄여 온 만큼 우리가 UI에 기대하는 수준도 함께 올라왔다는 뜻일 것이다(이 해석은 추정이다).

남는 교훈은 숫자보다 태도다. 코드의 절반이 UI라면, 테스트·리뷰·자동화 같은 개발 규율의 절반도 UI를 향해야 계산이 맞는다. 서버 로직에는 테스트 커버리지를 재면서 UI 코드는 눈으로 확인하고 넘어가고 있다면, 코드베이스의 절반이 규율 밖에 있는 셈이다. 내 프로젝트들의 다음 할 일도 여기서 나왔다 — 70%짜리 앱의 70%를 위한 검증부터 채우는 것이다.

---

참고한 공개 자료:

• Myers & Rosson, "Survey on User Interface Programming", CHI '92: https://dl.acm.org/doi/10.1145/142750.142789 (저자 공개 PDF: http://www.cs.cmu.edu/~bam/papers/surveymyersrosson92.pdf)
• W3C, "Introduction to Model-Based User Interfaces" (1992년 수치 재인용 및 증가 추정): https://www.w3.org/2011/mbui/drafts/mbui-intro/
• Lelli et al., "Classifying and Qualifying GUI Defects" (비율 대신 결함을 측정하는 최근 연구 흐름의 예): https://arxiv.org/pdf/1703.09567

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.