CS WIND 글로벌 UX/UI 표준

CS WIND는 풍력 발전기 타워를 만든다. 2021년부터 2023년까지 미국·포르투갈·베트남·덴마크의 제조사를 연달아 인수하면서 회사가 빠르게 커졌다. 매출은 2023년 1조 5,201억 원에서 2024년 3조 725억 원으로 한 해 만에 두 배가 됐다. 2025년 말 기준 연결 종속회사는 39개사다.

이 프로젝트는 성장이 인수로 이뤄졌다는 사실에서 출발했다. 늘어난 거점은 원래 다른 회사였고, 각자의 업무 방식과 화면을 그대로 안고 들어왔다. 회사는 이 법인들이 하나의 시스템을 쓰도록 사내 업무 플랫폼을 새로 구축하기 시작했다. 그러려면 어느 법인에서 만들든 같은 규칙을 따르는 화면 표준이 먼저 있어야 했다. 우리가 맡은 것이 그 글로벌 표준이다.

문제 — 같은 회사인데 화면마다 문법이 달랐다

CS WIND의 업무 화면은 디자이너 손을 거치지 않았다. 각 모듈을 맡은 담당자들이 저마다 화면 초안, 곧 목업을 그렸다. 쓰는 도구부터 달랐다. 요구사항정의서에 적힌 표현 그대로 옮기면 "HTML로 대시보드 16개 목업 작성", "PPT로 대시보드 목업 작성", "SAP화면 캡쳐하여 목업 작성", "목업 미존재(PPT에 텍스트로 정의)"였다.

도구가 제각각인 것은 겉으로 드러난 문제였다. 더 큰 문제는 성격이 같은 화면끼리도 사용자가 판단하는 순서가 서로 달랐다는 데 있었다. 목록 화면 맨 위에는 지금 처리해야 할 항목이 아니라 누적 총계가 놓여 있었다. 인증서 관리 화면은 만료 경고를 빨간 배너로 띄우고 갱신 기능은 별도 버튼으로 떼어 두었다. 급한 것을 알리는 자리와 그것을 처리하는 자리가 서로 떨어져 있었다.

색의 의미도 화면마다 어긋나 있었다. 생산 단계를 표시한 막대는 Black Tower가 초록, Internal Mounting이 빨강이었다. 같은 시스템 안에서 초록과 빨강은 완료와 지연을 가리키는 색이다. 감사 유형에서는 빨강 하나가 정부 감사와 기한 초과를 동시에 나타냈다. 하나의 색이 두 가지를 가리키면 사용자는 색만 보고 상황을 판단할 수 없다.

코드에도 같은 상황이 그대로 남아 있었다. EHS 모듈의 여덟 화면에 색상값이 314번 직접 넣어져 있었고, 그중 서로 다른 6자리 색이 41종이었다. 여덟 파일 가운데 여섯 개는 색을 정의한 부분이 완전히 동일했다. 한 파일을 복사해 나머지를 만든 것으로 보인다. 이런 상태에서는 화면 하나를 고쳐도 나머지 화면이 따라오지 않는다.

고객이 말한 진짜 문제

만들 사람이 없다는 것이었다. 화면은 계속 나올 텐데 사내에 디자인을 할 사람이 없었다. 요구사항정의서가 2026년 4월에 집계한 메뉴는 123개, 하위 메뉴는 460개다. 본사 인원은 98명이고, 정보보호 공시에 적힌 정보기술부문 인력은 22.8명이다. 가이드 문서를 써 주는 것만으로는 풀리지 않는 문제였다.

도출 — 열아홉 화면, 일곱 갈래

고객이 건넨 화면 열아홉 종을 특징별로 묶었다. 리스트·레지스터, 대시보드·개요, 상세+승인, 폼·포착, 마스터-디테일·평가, 캘린더·트래커, 라이브러리로 일곱 그룹이 나왔다. 그룹별 화면 수를 더하면 스물넷이다. 한 화면이 여러 특징을 가지면 여러 그룹에 함께 들어가기도 한다. RFQ 관리 화면은 목록이면서 승인 화면이었다.

묶은 기준은 화면의 특징이었다. 그룹마다 그 화면에서 내려야 하는 결정을 함께 정했다. 목록 화면의 직무는 "무엇부터 처리할까"이고, 승인 화면은 "지금 유효한가"를 결정 앞에 세운다. 일곱 그룹에서 표준 템플릿 열두 개를 뽑았다. 폼·점검형처럼 한 그룹이 둘로 갈리기도 해서, 그룹은 일곱인데 템플릿은 열둘이 됐다.

산출물의 형태는 문서가 아니라 파일로 정했다. 고객이 참고 자료로 준 가이드 샘플은 두 건 다 정적 PDF였다. 화면별 간격과 색을 px와 hex로 적어 둔 사양서 형식이다. 이런 문서는 내용을 읽고 화면에 옮겨 줄 사람이 있어야 작동한다. CS WIND에 없는 것이 바로 그 사람이었다.

전략 — 규칙·부품·완성품 세 개 층

표준을 세 개 층으로 나눠 세웠다. 맨 아래는 디자인 토큰이다. 색·간격·글자 크기·그림자처럼 화면을 이루는 값에 이름을 붙여 한곳에 모아 둔 목록으로, 이 프로젝트에서는 266개를 정의했다. 화면을 만드는 쪽은 숫자를 직접 적지 않고 이 이름을 부른다. 브랜드 색이 바뀌면 목록의 한 줄만 고치면 된다.

가운데 층은 컴포넌트 스타일시트다. 버튼·표·카드·모달처럼 화면을 구성하는 부품의 생김새와 동작을 정의하고, 그 안에서는 토큰 이름만 참조한다. 참조 횟수는 2,195회이고 직접 적은 색상값은 0건이다. 부품 하나를 고치면 그 부품을 쓴 화면이 모두 함께 바뀐다. 화면 수가 늘어도 관리해야 할 자리는 늘지 않는다.

맨 위는 골든마스터 템플릿이다. 부품을 조립해 미리 완성해 둔 화면으로, 새 화면은 여기서 복사해 내용만 바꾼다. 어떤 업무에 어떤 템플릿을 쓸지는 README에 표로 지정했다. 목록에서 무엇부터 처리할지 판단하는 화면은 pg-list-register, 한 건을 승인하고 전자서명하는 화면은 pg-detail-approval을 출발점으로 삼는 식이다. 만들 화면의 성격만 정하면 어디서 시작할지가 함께 정해진다.

고칠 자리를 한곳으로 모으려고 세 층으로 나눴다. 화면에 색을 직접 적으면 그 화면만 표준에서 벗어나고, 나중에 브랜드가 바뀔 때 사람이 일일이 찾아 고쳐야 한다. 그래서 하드코딩 금지를 규칙의 첫 줄에 뒀다. 표준을 지키는 일이 개인의 성실함에 기대지 않게 하려는 것이다.

해결 1 · 한 색, 한 뜻

색의 의미가 겹치던 문제부터 규칙으로 정리했다. 완료는 초록, 연체는 빨강, 임박은 노랑이며 이 셋은 상태 표시에만 쓴다. 분류에는 별도의 범주색을 배정하고, 긴급도는 태그와 배지로 나타낸다. 감사 유형은 내부·외부·정부·고객 네 가지가 전용 색을 하나씩 가진다. 빨강이 정부 감사와 기한 초과를 동시에 나타내던 충돌은 이 규칙으로 해소했다.

파랑도 둘로 나눴다. 브랜드 파랑 #0085FF는 흰 글자를 얹으면 대비가 3.6:1이라 작은 텍스트에서 웹 접근성 기준 AA를 통과하지 못한다. 그래서 이 색은 포커스 링과 큰 요소에만 두고, 버튼·링크·탭처럼 작은 글자를 담는 자리는 #006FD6이 맡는다. 후자는 흰 배경에서 4.95:1이다. 간트 바의 공정 단계 색도 흰 라벨이 AA를 넘도록 어둡게 조정했다.

해결 2 · 맨 위에는 처리할 일부터

화면 맨 위 자리를 누적 총계에서 처리할 일로 바꿨다. 목록 화면은 연체·고위험 항목을 맨 위 주의 영역에 모아 긴급도순으로 정렬한다. 대시보드는 조치가 필요한 항목을 좌상단에, 전체 지표를 그 아래에 둔다. 승인 화면은 유효기간과 남은 시간을 결정 카드 위에 올린다. 승인 버튼을 누르기 전에 "지금 유효한가"가 먼저 보이게 하기 위해서다.

법인이 여럿이면 모든 화면이 "어느 법인 이야기인가"를 먼저 묻는다. 처음에는 법인 선택이 다른 필터들과 필터바 안에 섞여 있었다. 2026년 6월 30일 이것을 필터바에서 빼내 페이지 제목 바로 아래 독립 행으로 올리고, 상단바에 남아 있던 중복 표시를 지웠다. 레지스터·대시보드·트래커까지 같은 자리로 통일했다. 화면이 달라져도 법인을 고르는 자리는 달라지지 않는다.

해결 3 · 그대로 쓰는 완성 화면

템플릿은 브라우저에서 그대로 열리는 화면으로 만들었다. 파일 열세 개 가운데 열두 개는 앱 셸이 붙어 있고, 결정을 내려야 하는 여섯 화면에는 확인 모달까지 들어 있다. 사고 보고 폼은 중대성을 먼저 묻고 그 답에 따라 뒤 질문을 바꾼다. 경미한 건은 짧게 끝난다. 기록 대상부터는 근본원인과 시정조치가 열리고, 중대한 사고에는 신고 기한 안내까지 따라붙는다.

인증서 자료실은 만료가 임박한 항목을 검색창보다 위에 배치한다. 만료된 인증서에는 이 화면에서 유일하게 결과가 뒤따른다. 비파괴검사 승인을 막는다.

빈 화면·로딩·오류·권한 없음은 템플릿마다 복제하지 않았다. UI 가이드에 한 번만 문서화하고 템플릿에는 그 위치를 가리키는 주석을 남겼다. 파일 열 개에 그 주석이 들어 있다.

해결 4 · AI용 제작 지시서

여기까지 만든 것은 AI도 읽는다. README에 폴더째 AI에게 주고 "이 시스템으로 ○○ 화면 만들어줘"라고 시키는 절차를 적었다. 새 컴포넌트를 발명하지 말 것, 가장 가까운 템플릿을 복사해 시작할 것, 도메인 사실(수치·규제·고객명)을 지어내지 말 것. 끝나면 여섯 항목으로 스스로 검수한다. 하드코딩 색상값 0 · 1px 헤어라인 · 토큰 사용 · 대비 AA · 결정 우선 배치 · 분류색과 상태색 분리다. 마크업의 정답은 ui-guide에서, 설계 의도는 ux-guide에서 찾도록 근거 문서까지 지정했다.

결과 — 표준으로 다시 세운 열아홉 화면

표준이 실제로 쓸 만한지는 직접 적용해 봐야 알 수 있었다. 고객이 건넨 목업 열아홉 종을 이 표준으로 전부 다시 설계해, 원본과 나란히 놓아 전달했다.

무엇이 달라졌는지는 수치로 확인했다. 화면에 직접 적혀 있던 색상값은 EHS 여덟 화면 기준 314번에서 0건이 됐다. 스크린리더가 화면을 읽을 수 있게 하는 접근성 속성은 원본 여덟 파일 전부 0개였던 것이 화면당 40~168개가 됐다. 제목과 카드 이름에 섞여 있던 이모지도 최대 서른아홉 개에서 0개가 됐다.

표준이 실제 업무 흐름을 감당하는지도 확인했다. 고객이 준 액티비티 정의서의 RFQ 관리와 검사원 관리 시나리오를 클릭되는 프로토타입으로 만들었다. 정의서가 규정한 활동 13개와 액션 91개 전부에 대응시켰고, 각 단계마다 충족하는 액션 번호와 정의서 출처 페이지를 함께 적었다. 빠진 액션이 있는지는 문서로 대조하면 드러난다.