서론

저는 백엔드 엔지니어(풀스택에 가까운)이며, 현재 어떤 프로젝트에서 스크럼 마스터(Scrum Master) 겸 테크 리드(Tech Lead)를 맡고 있습니다. 프로젝트에서는 업무 시스템을 Next.js + FastAPI로 구축하고 있습니다.

저 자신은 지금까지 업무 시스템의 관리 화면을 보거나, 수정 및 교체(Replace)해 온 경험이 있기 때문에 '업무 시스템의 관리 화면'이라는 것에는 비교적 익숙하다고 생각합니다. 반면, 전문적으로 프론트엔드(Frontend)나 UI를 공부해 온 것은 아닙니다.

팀 구성은 백엔드 중심의 엔지니어가 주를 이루고 있으며, 디자이너는 없고 프론트엔드 전담 인원도 없습니다. Next.js 코드를 읽고 작성할 수 있는 멤버들은 갖춰져 있지만, 디자인이나 UI/UX 관점은 팀 전체적으로 약한 것이 솔직한 심정입니다.

게다가 최근에는 AI를 통해 어느 정도 화면을 만들 수도 있는 상황이 생겨났습니다. 하지만 'AI가 있으니 프론트엔드는 통째로 맡겨도 OK'라고 할 만큼 이야기가 단순하지 않다는 것을, 실제 프로젝트를 진행하며 강하게 실감하고 있습니다.

이 기사는 그러한 상황 속에서, 백엔드 엔지니어 출신인 제가 OOUI와 SocioMedia의 '휴먼 인터페이스 가이드라인(Human Interface Guidelines, HIG)'을 공부하고, 프로젝트에서 실천해 본 기록입니다. 비슷한 입장에 있는 엔지니어 분들에게 무언가 도움이 되기를 바랍니다.

안고 있던 과제

화면을 설계하고 나름대로 정돈된 형태로 구현할 수 있는 엔지니어가 팀 내에 저뿐인 상황이었습니다. 팀에서 분담하여 프론트엔드 측 구현도 진행하지만, 'UI의 좋고 나쁨을 판단하는 눈'이 팀 전체적으로 길러지지 않았다는 과제가 있습니다.

마침 저 자신도 최근 '디자인이 정말 중요하구나'라고 느끼는 일이 많아지던 타이밍이었기에, 우선 개인적인 흥미로서 다음과 같은 순서로 인풋(Input)을 해보았습니다. 결과적으로 그것이 팀에 전개하기 위한 발판이 되고 있습니다.

• OOUI(Object-Oriented UI 디자인) 책 읽기
• SocioMedia의 '휴먼 인터페이스 가이드라인(Human Interface Guidelines)' 읽기
• 그 후에 실제 프로젝트에서 실천하기

SocioMedia의 HIG를 의식한 구현

가이드라인을 읽으면서 특히 의식하려고 노력하는 포인트들을 나열해 보겠습니다.

버튼을 누를 수 있는지 여부를 외관으로 전달하기

참고: HIG 「4. 시그니파이어(Signifier)」

'누를 수 있는 것은 누를 수 있다는 것을 알 수 있게'를 철저히 했습니다. AI가 만드는 화면은 겉모습이 너무 플랫(Flat)해서 누를 수 없어 보이는 버튼이 많은 인상을 받습니다.

• 누를 수 없을 때는 명확하게 disabled 상태로 만들기
• 누를 수 있을 때는 '누를 수 있을 것 같다'는 느낌이 들도록 제대로 보여주기
• 입력이 완료될 때까지는 누를 수 없다는 상태를 시각적으로 알 수 있게 하기

페이지마다 새로운 컴포넌트를 만들지 않기

참고: HIG 「6. 일관성(Consistency)」

AI에게 맡기면 페이지 단위로 컴포넌트를 차례차례 만들어 버려서, '언뜻 보기에는 비슷하지만 미묘하게 다른 UI'가 양산되기 쉽습니다. 이는 Claude Code의 Skill 등을 활용하여 AI를 활용(Harness)함으로써, 기존 컴포넌트를 재사용하도록 유도하고 있습니다.

라벨(Label)이나 항목명은 회의에서 나온 용어로 맞추기

회의나 업무 중에서 사용자가 실제로 사용하는 용어를 그대로 화면의 라벨이나 버튼명에 반영합니다. 이것만으로도 화면의 이해도가 상당히 달라집니다. AI에게 맡기면 일반적인 용어로 멋대로 바뀌어 버리기 때문에, 명명(Naming)은 반드시 멈춰 서서 확인합니다.

'대체로 이것이 선택된다'를 기본값(Default value)으로 넣어두기

참고: HIG 「42. 좋은 기본값(Good Defaults)」

'대체로 이것이 선택된다'라는 선택지가 있다면 기본값으로 넣어둡니다. 그것만으로도 조작 공수가 확 줄어듭니다.

아이콘은 억지로 사용하지 않기

아이콘은 명사(대상물)나 상태를 나타내는 데는 능숙하지만, 동사(처리)를 나타내는 데는 서툽니다. 동작 계열의 아이콘은 의미를 사전에 알지 못하면 전달되지 않습니다. 따라서 '이것밖에 없다'라고 생각되는 것 외에는 억지로 아이콘으로 만들지 않고 글자로 쓰도록 하고 있습니다. '대충 맞는' 아이콘을 나열할 바에는 라벨로 명기하는 편이 화면 전체의 신뢰감을 유지할 수 있습니다. AI에게 맡기면 '그 아이콘은 다운로드 같은 느낌인데'와 같은 일이 자주 일어나는 것 같습니다.

버튼을 누르기만 하면 되는 공정은 그대로 자동으로 진행하기

참고: HIG 「29. 사용자가 취할 수 있는 조작이 하나뿐이라면 자동화하라」

예를 들어 모달(Modal) 내에서 파일을 업로드하는 화면에서, 업로드 완료 후에 「완료하기」 버튼을 누르게 했었는데, 누르기만 하면 되는 조작이라면 업로드 완료 시점에 모달을 닫고 토스트(Toast)로 결과를 전달하도록 변경했습니다. 「사용자의 조작을 줄인다」는 관점에서는 당연한 일이지만, AI에게 맡기면 매번 확인 버튼을 두는 경향이 있습니다.

OOUI의 실천

OOUI에서 저에게 가장 큰 임팩트를 주었던 것은 「오브젝트(Object)를 기점으로 생각한다」는 관점이었습니다.

• 명사 → 동사 순으로 생각하기 (오브젝트를 선택한 후 액션(Action)을 결정한다)
• 태스크(Task)를 기점으로 한 절차형(Procedural) 화면을 만들지 않기

엔지니어로서 개발을 진행할 때, 가장 먼저 데이터 모델링(Data Modeling)을 합니다. 그렇게 모델링한 메인 테이블에 대해,

• 목록 페이지
• 상세 페이지

를 먼저 이미지화합니다. 거기서부터 CRUD · 다운로드 · LLM을 통한 분석 · 외부 API와의 연동 등의 액션을 확장해 나가면, 자연스럽게 「명사 → 동사」의 OOUI 구조가 됩니다.

특히, 여러 개를 선택하여

• 일괄 다운로드
• 일괄 삭제
• 일괄 LLM 분석

과 같은 액션은 업무 시스템에서 도처에 등장합니다. 「오브젝트의 리스트 × 액션」이라는 발상에 익숙해지면, 화면 구조를 생각하는 부하도 훨씬 줄어듭니다.

실무적으로도 효과적입니다. 고객과 대화하다 보면 아무래도 「~를 하고 싶다」라는 태스크 기반의 대화로 흐르기 쉽고, 그것을 그대로 화면에 옮기고 싶어지곤 합니다. 하지만 매번 태스크 단위로 화면을 만들다 보면, 요구사항의 수만큼 화면이 계속해서 늘어나는 상황이 되기 쉽습니다. 일단 멈춰 서서 「어떤 오브젝트에 대한, 어떤 액션인가」라고 다시 파악하고, 선택 → 액션의 형태로 묶을 수 없는지 고민하는 것만으로도 화면의 비대화를 상당히 억제할 수 있습니다.

절차형 화면으로 만들지 않기

관리 화면에서 「위에서부터 순서대로 절차를 진행해 나가는」 화면을 만들기 쉽지만, 업무 시스템의 이용자는 기본적으로 그 작업에 익숙한 사람들입니다. 학습 비용(Learning Cost)도 그리 높지 않은 경우가 많습니다. 그런 사람들에게 절차형 화면은 처음 몇 번을 제외하고는 오히려 번거로움이 됩니다.

오브젝트 단위의 「목록」과 「상세」를 팀에서 공유하기

조금 다른 측면이지만, 미경험 엔지니어나 운영 중인 시스템에 들어간 경험이 적은 엔지니어에게는 「오브젝트 단위의 목록과 상세가 있고, 각각에 액션이 매달려 있다」라는 패턴 자체가 당연한 것이 아니라는 점을 깨달았습니다.

마찬가지로, 상세 화면에서 요소를 어떤 순서와 어떤 그룹화(Grouping)로 배치할 것인가와 같은 「관리 화면의 이디엄(Idiom)」도, 백엔드 위주의 인원들만 있는 팀에서는 의외로 공유되지 않습니다. 「보통 그런 순서로 항목을 나열하지 않을 텐데」라는 수준의 결과물이 나오고 나서야 비로소 깨닫게 되는 것이 실정입니다.

그래서 코드 리뷰(Code Review) · 페어 프로그래밍(Pair Programming) · 화면 리뷰 회의를 할 때, 이러한 기본 패턴을 공유하는 것부터 시작해야 하는 상황도 있습니다. 또한, 평소 사용하는 서비스를 「UI 관점에서 보면 재미있어」라고 팀에 권장하기도 합니다. 일상적으로 인풋(Input)을 얻을 수 있는 장소가 늘어나기 때문입니다.

그 외에 의식하고 있는 것

명명(Naming)에서 멈추기

사용자가 쓰지 않는 용어를 우리의 편의를 위해 새로 정의해야 하는 상황에서는, 그 명칭이 사용자에게 전달될지를 반드시 확인합니다. AI가 마음대로 결정한 명칭 그대로 진행하지 않는 것을 규칙으로 삼고 있습니다.

3초 이상 걸리는 처리는 비동기(Asynchronous)로 하기

응답에 3초 이상 걸릴 것 같은 처리는 동기(Synchronous) 처리로 하지 않고, 페이지를 전환시켜 비동기로 처리합니다. 로딩 스피너(Loading Spinner)로 계속 기다리게 하는 것은 업무 시스템에서 경험을 크게 해칩니다.

프로젝트에서 깨달은 점: 「AI로 관리 화면 정도는 누구나 만들 수 있다」가 아니다

지금까지 써온 이야기는 「내가 화면을 설계/구현할 때 의식하고 있는 것」이었습니다. 반면, 팀 개발에서는 당연히 나 이외의 엔지니어에게도 화면 구현을 맡깁니다. 거기서 깨달은 것은,

업무 이해도가 낮은 엔지니어에게 화면 구현을 맡기면, 기본적으로 재작업(Rework)이 발생한다

는 것입니다.

데이터 정의(테이블 설계나 API 스키마)가 끝났다면 관리 화면 정도는 만들 수 있겠지, 하물며 AI가 있다면 프롬프트(Prompt)를 작성하기만 하면 되겠지라고 생각하기 쉽지만, 실제로는 그렇게 만만하지 않습니다.

어떤 일이 벌어지냐면,

• 사용자가 해당 화면에서 무엇을 하고 싶은지 상상할 수 없어서, 불필요한 액션(Action)을 추가하거나 필요한 액션이 누락됨
• 사용자가 평소 사용하는 언어가 아닌, 개발자 관점의 언어로 레이블(Label)이나 버튼이 명명됨
• 목록 페이지의 필터(Filter)나 정렬(Sort)이 업무상의 사용 방식과 어긋남
• 상세 페이지에서 돌아왔을 때의 상태 유지(State Retention) 등, 업무 흐름에 따른 동작이 이루어지지 않음

이와 같은 일들이 일어납니다. 이것들은 모두 AI에게 깔끔한 프롬프트(Prompt)를 작성하면 해결되는 종류의 것이 아닙니다. 업무 측면에서 '무엇을 하고 싶은지·무엇을 하고 있는지'를 이해하지 못하면, 애초에 적절한 프롬프트를 작성할 수 없기 때문입니다.

그래서 화면 구현을 맡기기 전 단계에서,

• 해당 오브젝트(Object)가 업무의 어느 부분에서 사용되는지
• 사용자가 해당 페이지에 들어올 때의 전형적인 동기
• 해당 페이지에서 다음에 어디로 가고 싶어 하는지

이런 부분들을 공유하도록 하고 있습니다. 반대로 이 부분을 생략해 버리면, AI로 구현 속도가 올라가더라도 그 이후의 리뷰(Review)나 재작업(Rework)에서 결국 시간을 쓰게 됩니다.

예를 들어, 저 자신은 사용자와 직접 대화하는 과정에서 "여기는 다운로드 기능이 필요하겠네", "이것은 일괄 처리로 하고 싶겠지"라는 것이 보이더라도, 그것을 구현자에게 공유하지 않으면 당연히 전달되지 않습니다. "구현자 측에서 상상해 주세요"라는 식으로는 성립되지 않으므로, 공유할 수 있는 제도와 메커니즘을 만드는 것이 전제 조건이 됩니다. 사양(Specification)을 공유할 수 없으면 백엔드(Backend) 개발이 성립되지 않는 것과 마찬가지로, 프론트엔드(Frontend) 개발도 본질적으로는 그만큼 어렵다는 것을 실감하고 있습니다 (사용자 관리와 같이 어느 시스템에서나 공통적인 화면이라면, 적당한 프롬프트만으로도 어느 정도 동작하는 것은 만들 수 있습니다만).

팀으로서 실천하기로 한 것

UI 구현의 어려움을 실감하면서, 팀에서는 다음과 같은 프로세스를 돌리기로 했습니다.

• "화면 구현은 짬짬이 할 수 있는 것이 아니다"라는 인식 맞추기: 데일리(Daily)나 회고(Retrospective)에서 반복적으로 공유한다. 한 번 이야기하고 끝내지 않는다.
• 화면 리뷰회 설치: "하면 좋은 것"이 아니라 "필요한 것"으로서 팀 내에 위치시킨다.
• 화면 리뷰회에서 잘된 점과 잘못된 점을 논의하기: 케이스 워크(Case work)로서 팀원 전체의 지식으로 축적한다. 개인의 감각에 가두지 않는다.
• "리뷰는 인격 부정 이 아니다"라고 입이 닳도록 말하기: 코드 리뷰(Code Review)에서도 마찬가지지만, 화면은 더 주관적으로 보이기 쉬우므로 더욱 명시적으로 전달한다.

포인트는, 의식의 공유와 **구체적인 액션(리뷰회)**을 양 바퀴로 돌리는 것입니다. 어느 한쪽만 있어서는 지속될 수 없습니다.

AI에게 맡겼을 때 곤란한 점

AI에게 화면 구현을 맡기면서 자주 나타나는 신경 쓰이는 포인트들을 나열해 봅니다.

• 목록 페이지의 필터 입력값을 쿼리 파라미터(Query Parameter)로 유지해 주지 않음
• 목록에서 필터를 적용한 뒤 상세 페이지로 이동했다가 "뒤로 가기"를 누르면 필터 조건이 전부 파기됨
• 상세 화면을 만들지 않고 모달(Modal) 표시로 끝내버림 (목록과 상세라는 기본 구조가 무너짐)
• 버튼을 누를 수 있는지 알 수 없는 시그니파이어(Signifier)
• 일관된 컴포넌트(Component)를 재사용하지 않음 (페이지마다 처음부터 새로 만듦)
• 신규 사용자 추가와 같은 단순한 관리 화면에서도, 추가 결과가 실시간으로 반영되지 않아 새로고침이 필요함
• 과도하게 색상을 사용함
• 과도하게 아이콘을 사용하고 싶어 함 (동사 레이블 옆에 의미 없는 아이콘을 추가하는 등)
• 숫자 입력에 가로 방향의 인크리먼트(Increment)·데크리먼트(Decrement) 화살표가 멋대로 붙음
• "액션이 완료되었습니다"라는 모달을 매번 띄움

하나하나가 작은 일이지만, 쌓이면 UI 전체의 인상을 단번에 떨어뜨립니다. Skill이나 프롬프트, PR 리뷰를 통해 하나씩 해결하고 있는 것이 현상황입니다.

어떻게 해결하고 있는가

기본적인 방법은 심플합니다. 신경 쓰이는 동작을 발견하면 Skill에 규칙을 추가해 나가는 것을 반복하고 있을 뿐입니다.

예를 들어,

• "필터 조건은 URL의 쿼리 파라미터로 가진다. 상세 페이지에서 돌아왔을 때 복원되어야 한다."
• "화면을 만들 때는 기존의 컴포넌트 목록에서 선택한다. 신규 생성은 최후의 수단이다."
• "액션 완료는 토스트(Toast)로 알린다. 확인 모달은 파괴적인 조작(Destructive Operation)일 때만 사용한다."

이와 같은 규칙을 리뷰나 동작 확인 중 신경 쓰일 때마다 Skill에 추가해 나갑니다. Skill 자체는 AI에게 요청하여 작성하게 합니다.

"하고 싶지 않은 동작"을 찾아내는 눈은 자신이 갖고, 규칙화와 운용은 AI에게 맡기는 분업 방식입니다.

소감

가이드라인을 읽으며 강하게 느낀 점은, "특별히 새로운 것을 배웠다"기보다는 "이미 봐왔던 UI에 대해 왜 그것이 좋은지를 인식할 수 있게 되었다"는 감각이었습니다. 평소 사용하는 서비스에서 "왠지 사용하기 편하다"라고 느끼던 것을 구조로서 이해할 수 있게 되었다는 표현이 더 적절할 것 같습니다.

프론트엔드 엔지니어나 디자이너가 아니기에, 컴포넌트 자체의 완성도(마이크로 인터랙션 (Micro-interaction)이나 세밀한 애니메이션 등)까지 손을 뻗지는 못하고 있다고 생각합니다. 반면, AI가 있음으로써 "좋은 UI의 이미지"만 우리가 가지고 있다면, 그것을 비교적 빠르게 형상화할 수 있다는 체감은 있었습니다.

여기서부터는 조금 다른 이야기입니다만, AI가 침투해 가는 시대에 CLI (Command Line Interface) 도구의 발달도 있어 "UI가 필요 없다"라고 말해지는 상황도 있을지 모릅니다. 우리 백엔드 엔지니어들은 테이블 설계나 데이터 모델 (Data Model)부터 시작하여, 데이터를 뇌 속에 매핑하고 처리를 그려나가며 진행하는 스타일이 많기에, 극단적으로 말해 UI가 없어도 DB (Database)를 직접 보면 어떻게든 된다는 실감이 있습니다.

하지만 일반적인 사용자는 GUI (Graphical User Interface)를 통해 데이터를 기억하거나 업무를 이해해 나갈 것입니다. 따라서 "업무 시스템에서 GUI가 사라지는" 것과 같은 미래는 쉽게 오지 않을 것이라고 생각합니다.

세상의 흐름으로서도, AI의 보급에 따라 백엔드와 프론트엔드의 경계는 점점 모호해지고 있습니다.

특히 중소기업 현장에서는 디자이너나 프론트엔드 전담 인력을 새로 채용하는 것이 경영적으로 쉽지 않아, 결과적으로 백엔드 엔지니어가 화면까지 담당할 수밖에 없는 사정이 있습니다. "AI를 사용하면 BE (Backend) 엔지니어도 척척 화면을 만들 수 있어 최고다"라기보다는, "인원을 늘릴 수 없는 이상, 그렇게 할 수밖에 없다"는 것이 솔직한 심정입니다.

다만, UI/UX (User Interface/User Experience) 관점을 갖지 못한 백엔드 엔지니어가 AI에게 맡겨 화면을 만들면, 완성되는 결과물은 그리 좋은 것이 되지 않습니다. 동작은 하지만 시그니파이어 (Signifier)가 빠져 있거나, 사용자의 언어와 괴리가 있거나, 조작의 일관성이 없거나 합니다. 그럼에도 불구하고 "AI가 있다면 만들 수 있겠지"라는 전제로 맡겨지는 기회는 앞으로도 계속 늘어날 것입니다.

그렇기에 백엔드 엔지니어 측에서도 UI/UX 관점을 최소한으로 갖추고 있는 것이 향후에는 전제 조건이 될 것이라고 느낍니다. AI를 사용하여 대충 양산하는 쪽이 될 것인가, AI를 사용하여 제대로 된 것을 만들 수 있는 쪽이 될 것인가, 그 차이는 생각보다 큽니다. 저 자신도 계속해서 이 부분을 단련해 나가고 싶다고 다시 한번 느꼈습니다.

요약

• AI가 있는 시대에도 "좋은 UI의 이미지"를 가진 엔지니어의 가치는 떨어지지 않는다
• SocioMedia의 HIG와 OOUI는 백엔드 엔지니어가 첫 발판을 마련하기에 딱 좋다
• AI에게 맡기기 때문에 오히려 시그니파이어, 명명 (Naming), 컴포넌트의 일관성 등은 규칙으로 만들어 기술 (Skill)이나 프롬프트 (Prompt)로 녹여내는 것을 추천한다
• 화면 구현은 "데이터 정의가 끝나 있으면 누구나 만들 수 있다", "AI에게 프롬프트를 쓰면 끝난다"와 같은 것이 아니라, 업무 이해가 동반되어야 비로소 성립된다

참고한 것

SocioMedia 주식회사 「Sociomedia Human Interface Guideline」

SocioMedia 주식회사, 우에노 마나부, 후지이 코타 저 / 우에노 마나부 감수 『객체 지향 UI 디자인 ── 사용하기 쉬운 소프트웨어의 원리』 기술평론사, 2020년 (WEB+DB PRESS plus 시리즈, ISBN 978-4-297-11351-3)

Discussion