SLUR / 2026UX·UI SYSTEM PARTNER

DIAGNOSTIC / READY STANDBY01 / 11

디자인과 실제 화면의
차이를 줄이고,
사람이 바뀌어도
유지되는 UI를
만듭니다

진단부터 구현·반영·검수까지 연결하는 시니어 UX/UI 시스템 파트너

UI 문제 상담하기

먼저 문제와 적합성을 확인합니다. 코드 검토와 원인 분석은 유료 진단부터 진행합니다.

SCROLL TO DIAGNOSE

SCAN 01 / SYMPTOM DETECTING02 / 11

증상 수집

이런 상황이
반복되고 있습니까

퍼블리싱만 맡기면 해결될 줄 알았던 문제들입니다.

SCAN 02 / ROOT CAUSE FOUND03 / 11

원인 확정

퍼블리싱이 부족한 것이 아니라,
기준을 지킬 사람이 없는 것입니다

화면은 계속 만들어지는데, 그 화면들이 지켜야 할 기준을 세우고 검수하는 사람이 조직 안에 없습니다. 증상은 화면마다 다르게 나타나지만 원인은 하나입니다.

그래서 SLUR는 진단, 범위 구분, 기준 수립, 구현, 소스 반영, 검수, 운영 QA를 분리하지 않고 연결합니다.

UI 문제 상담하기
EVIDENCE 01 / TRACK RECORD SUSTAINED04 / 11

지속 기록

보여드릴 수 있는 화면은
많지 않습니다.
대신 10년 차의 기록이 있습니다

고객사의 화면은 NDA로 공개하지 않습니다. 그래서 이 페이지에는 포트폴리오 대신, 10년 차가 되도록 지켜 온 일하는 방식만 남습니다.

그렇게 UI 개발만으로 10년 차가 되었습니다. 그 협업이 실제로 어떻게 진행되고 마무리되는지는, 아래 기록이 대신 말합니다.

EVIDENCE 02 / CASE LOG VERIFIED05 / 11

협업 기록

실제 협업은 이렇게 진행되고,
이렇게 마무리됩니다

CASE LOG — RECORDED SESSIONSANONYMIZED

REC · CASE A / DIRECTSESSION CLOSED

여러 개발자가 참여하는 장기 운영 웹 플랫폼이었습니다. 작은 화면 수정에서 시작해, 흩어진 CSS의 영향 범위를 격리하고 화면별 기준을 세우는 안정화 작업으로 이어졌습니다. 안정화가 끝난 뒤에는 내부 팀이 스스로 운영할 수 있는 수준까지 기준과 문서를 인수인계했습니다. 안정화가 마무리되면서 자연스럽게 협업이 종료되었습니다. 이후에는 필요할 때만 찾는 월 단위 컨설팅·유지보수로 전환했습니다. 그것이 서로에게 가장 효율적인 방식이기 때문입니다.

운영 조직에 외부 UI 개발 인력이 계속 상주할 필요는 없습니다. 내부에서 운영할 수 있는 상태를 만들어 드리는 것이 이 협업의 목표입니다.

LOG · T+0 작은 수정 → T+n 기준 인수인계 → 이후 월 단위 유지보수

REC · CASE B / TAKEOVERRECOVERED

중도에 이탈한 담당자가 남기고 간 프로젝트를 이어받았습니다. 문서 없이 남겨진 화면과 CSS의 실체를 먼저 파악하고, 살릴 수 있는 것과 다시 세워야 하는 것을 구분했습니다. 남은 구간에 기준을 세워 마무리하고, 다음 사람이 이어받을 수 있는 상태로 인계했습니다. 이런 인수 사례는 한 번이 아니라 여러 번 반복되었습니다. 무너진 프로젝트에도 끝을 만들 수 있습니다.

LOG · T+0 남겨진 코드 → T+n 인계 가능한 상태

고객사의 이름·화면·수치는 공개하지 않습니다. 모든 경험은 익명으로만 기술합니다.

EVIDENCE 03 / SYSTEM DOCUMENTED06 / 11

기준 체계

SLUR UX/UI System

사람이 바뀌어도 유지되려면 기준이 문서여야 합니다. SLUR는 네 가지 기준으로 화면을 관리합니다.

SPEC SHEET / SLUR UX·UI SYSTEMREV. 2026

NO.PARAMETERSPECIFICATION

SYS-01

구조

STRUCTURE

화면을 역할 단위로 나누고, 이름 규칙으로 고정합니다.

SYS-02

상태

STATE

로딩·오류·빈 화면까지, 모든 상태를 규칙으로 정의합니다.

SYS-03

반응형

RESPONSIVE

기준 뷰포트와 분기 규칙으로 기기 간 차이를 관리합니다.

SYS-04

검수

REVIEW

구현이 기준과 일치하는지 확인하는 절차를 둡니다.

SLUR UX/UI System 자세히 보기 (새 창)
EVIDENCE 04 / LAB INTERNAL07 / 11

자체 실험

SLUR Labs

LAB 01 · DWGBUILD / VERIFY

병원 진료기록 시스템

문제밀도 높은 기록 화면 — 잘못 읽히면 안 되는 정보 구조.

판단장식이 아니라 위계와 상태 규칙으로 풀어야 하는 문제.

구조기록 유형별 컴포넌트와 상태 정의, 공통 토큰으로 구성.

검증반응형·키보드 탐색·상태 전환을 검수 범위로 확인.

SLUR가 기준을 검증하기 위해 자체 제작한 실험 프로젝트입니다. 운영 중인 서비스가 아닙니다.

ONGOING · EXPERIMENT INDEXLOG

진행 중인 실험

  • EXP-01AX 전환 연구 — UI 진단·검수 과정의 자동화 연구개발IN PROGRESS
실험 소식은 블로그에 기록합니다 (새 창)
PROTOCOL 01 / 4-STEP READY08 / 11

진행 절차

첫 의뢰는 항상
진단부터, 작게 시작합니다

  1. STEP 01

    진단

    DIAGNOSIS

    코드와 화면을 직접 확인하고, 문제의 원인과 영향 범위를 문서로 확정합니다. 이 문서가 다음 단계의 범위와 견적 근거가 됩니다.

    80만원~ / 최대 4시간VAT 별도 · 원격 기본, 현장 등은 별도 협의

  2. STEP 02

    안정화

    STABILIZATION

    진단에서 확정한 범위부터, 깨지는 화면을 멈추고 영향 범위를 격리합니다.

    문의 시 안내

  3. STEP 03

    시스템

    SYSTEM

    사람이 바뀌어도 유지되는 화면 기준 — 구조·상태·반응형 규칙을 세웁니다.

    문의 시 안내

  4. STEP 04

    운영

    OPERATION

    새 화면이 기준을 지키는지 확인하는 운영 QA를 이어갑니다.

    문의 시 안내

모든 단계를 계약하는 것이 아닙니다. 진단 결과를 보고 다음 단계를 결정하시면 됩니다.

UI 문제 상담하기
PROTOCOL 02 / SCOPE DEFINED09 / 11

범위 안내

무료와 유료의 경계

FREE무료 상담에서
확인하는 것

  • 문제가 SLUR에 적합한 일인지
  • 코드·화면에 접근이 가능한지
  • 일정과 예산이 맞는지

PAID유료 진단부터
진행하는 것

  • 코드·로그·내부 화면 검토
  • 문제의 원인 분석과 영향 범위 확정

진단 4시간 안에 문제 해결을 보장하지 않습니다. 진단은 원인과 범위를 확정하는 단계입니다.

PROTOCOL 03 / PARTNER OPEN10 / 11

개발사 · SI

고객사 프로젝트에
UI 전문가가 필요하다면

기획과 개발 사이의 화면 기준 공백을 맡습니다. 진단·안정화·검수 단위로 프로젝트에 참여합니다.

기본: 개발사 계약직접 전환: 동의 시에만

기본은 개발사와의 계약으로 진행하며, 고객사와의 직접 계약 전환은 개발사 동의가 있을 때만 진행한다.

개발사 협업 문의
REQUEST / CONTACT INPUT11 / 11

상담 요청

UI 문제,
지금 한 줄로 보내 주세요

문제를 한 줄로만 적어 주시면 됩니다. 첫 문의에서는 코드·로그·내부 자료를 보내지 않으셔도 됩니다. 먼저 문제와 적합성을 확인하고, 코드 검토와 원인 분석은 유료 진단부터 진행합니다.

이메일로 문의하기

MAIL TO / hoseong.lee@slur.co.kr

PREPARINGFORM / STANDBY

폼 접수는 준비 중입니다. 지금은 위 이메일로 문의해 주세요.

영업일 기준 1일 이내 회신

문의 내용을 확인한 뒤 가능한 일정을 안내합니다.