#개발 #기술블로그 #UX #개발 #인사이트 #아티클
최근 진행 중인 프로젝트에서 특정 기능 도입 여부를 두고 개발팀 논의가 열렸다.
기능 자체의 기술적 구현 가능성이나 공수보다, 정작 중요한 질문은 따로 있었다.
> **이 기능이 실제 사용자 경험에 도움이 되는가?**
백엔드 개발자인 나는 사실 그 질문을 먼저 떠올리지 못했다. 😅 다른 팀원들이 UX 관련 관점을 제시해주어서 이 관점을 뒤늦게 생각해보게 되었는데... (내가 ㅎㅎ 기능좋아 기능넣자 코딩재밌으니까 로만 생각한 것도 좀 있다)
아직 논의가 완전히 끝난 건 아니지만, 이 경험을 하면서 이런 질문을 떠올리게 되었다.
<p style="text-align: center; font-size: 2em; font-weight: bold;">
🤔 백엔드 개발자에게도 UX 감각이 필요한가?
</p>
그래서~ 이왕 생각난 김에
'백엔드 개발자에게도 UX 감각이 필요하다'는 논지의 아티클들을 찾아보게 되었다.
그래서 클로드로 1차 번역 돌리고 나도 읽어봤는데 아카이빙용으로 올려둔다~
번역한 건 아래 셋이다
<div>
<a href="https://blog.boot.dev/clean-code/backend-ux-design/" target="_blank" style="display:block; border:1px solid #ddd; border-radius:8px; padding:16px; text-decoration:none; color:inherit; margin-bottom:8px;">
<div style="font-weight:bold; margin-bottom:4px;">Backend Developers Are UX Designers Too</div>
<div style="font-size:0.85em; color:#888;">blog.boot.dev</div>
</a>
<a href="https://dev.to/koladev/why-should-backend-developers-care-about-ux-48op" target="_blank" style="display:block; border:1px solid #ddd; border-radius:8px; padding:16px; text-decoration:none; color:inherit; margin-bottom:8px;">
<div style="font-weight:bold; margin-bottom:4px;">Why should backend developers care about UX?</div>
<div style="font-size:0.85em; color:#888;">dev.to</div>
</a>
<a href="https://10clouds.com/blog/design/ux-designer-backend-developer/" target="_blank" style="display:block; border:1px solid #ddd; border-radius:8px; padding:16px; text-decoration:none; color:inherit; margin-bottom:8px;">
<div style="font-weight:bold; margin-bottom:4px;">UX Designer and Back-end Developer: Brothers in Arms</div>
<div style="font-size:0.85em; color:#888;">10clouds.com</div>
</a>
</div>
---
<p style="text-align: center; font-size: 2em; font-weight: bold;">
1️⃣ 백엔드 개발자도 UX 디자이너다
</p>
<a href="https://blog.boot.dev/clean-code/backend-ux-design/" target="_blank" style="display:block; border:1px solid #ddd; border-radius:8px; padding:16px; text-decoration:none; color:inherit; margin-bottom:8px;">
<div style="font-weight:bold; margin-bottom:4px;">Backend Developers Are UX Designers Too</div>
<div style="font-size:0.85em; color:#888;">blog.boot.dev</div>
</a>
# 1. 백엔드 개발자도 UX 디자이너다
나는 백엔드 작업에서 UX 디자인이라는 개념을 너무 자주 등한시해왔다. UX 디자인의 목표는 사용자가 쓰기 쉬운 제품을 만드는 것이다. 프론트엔드 개발의 세계에서는 보통 사이트 탐색을 직관적으로 만들고, 널리 통용되는 아이콘을 쓰고, 전경과 배경의 명도 대비를 높여 읽기 쉽게 만드는 것을 의미한다.
나는 백엔드 개발에서도 UX가 매우 중요하다고 주장하고 싶다. 다만 차이가 있다면, 우리의 사용자는 최종 제품의 유저가 아니라 다른 개발자들, 때로는 내부 직원들이라는 점이다.
## UX(사용자 경험) 디자인이란?
> 사용자 경험 디자인(UXD, UED, XD)은 제품과의 상호작용에서 사용성, 유용성, 욕구 충족을 통해 사용자 행동을 지원하는 프로세스다. UX 디자인은 전통적인 인간-컴퓨터 상호작용(HCI) 설계를 포괄하며, 사용자가 인식하는 제품 또는 서비스의 모든 측면을 다루는 것으로 확장된다.
> — Wikipedia
다시 말해, UX 디자인은 사용자가 제품과 쉽게 상호작용하고 작업을 간단하게 완수할 수 있도록 만드는 것이다.
## UX 디자인의 예시
나쁜 예시를 통해 이해하는 것이 더 쉬울 때가 있다. 손잡이가 달린 문에 "미세요(PUSH)"라고 적혀 있는 경우를 생각해보자. 당길 수도 없는 문에 왜 손잡이가 달려 있는가? 이건 그냥 나쁜 UX이고, 엇갈리는 신호를 준다. 처음부터 푸시 플레이트를 썼다면 글자 따위는 필요 없었을 것이다. 단순함이 이해를 낳는다.
나는 좋은 UX 디자인을 사용 설명서의 죽음이라고 생각한다. 사용 설명서 기억하는가? 공구나 가전제품에서 여전히 볼 수 있다. 소프트웨어 초창기에는 CD-ROM 제품에 사용 설명서가 함께 들어있곤 했다. Facebook에 로그인하려고 사용 설명서를 펼쳐야 한다고 상상이나 할 수 있는가? UX의 목표는 소프트웨어(또는 제품)를 명시적인 안내 없이도 거의 질문이 필요 없을 만큼 쉽게 만드는 것이다.
## 백엔드 코드에서 이게 왜 중요한가?
결국 하나로 귀결된다. 깔끔한 API. 백엔드 개발자로서 우리의 사용자는 다른 개발자들이다. 낡고 엉성하게 작성된 API 문서를 뒤적여본 경험이 있다면, 내가 하려는 말을 이해할 것이다.
나쁘게 설계된 REST API 예시를 보자.
```
# Users API - 엔드포인트 목록
## 새 유저 생성
POST /user/create
### 요청 바디
{
"email": "
[email protected]",
"password": "somethingsecure"
}
### 응답
{
"id": "some-new-id"
}
## 유저 삭제
POST /users/delete/{email}
## 유저 조회
GET /user/{id}
## 유저 수정
PUT /user
{
"id": "some-id-here",
"email": "
[email protected]",
"password": "somethingsecure"
}
```
문제가 한둘이 아니다. 이 API가 쓸 수는 있겠지만, 눈물이 날 것 같다. 어느 것 하나 직관적이지 않고, 내부 패턴도 전혀 지켜지지 않는다. RESTful하지 않은 것 자체는 크게 신경 쓰지 않는다. 하지만 비RESTful하더라도 최소한 일관되게 비RESTful할 수는 없는가?
**문제 #1 — 단복수가 제멋대로다**
어떤 엔드포인트는 `/users`를 쓰고 어떤 것은 `/user`를 쓴다. 언제 어느 쪽을 써야 하는지 알 수 없다. 결국 다시 사용 설명서(문서)를 뒤적이게 된다.
**문제 #2 — 경로에 동사가 들어가는 기준이 없다**
생성과 삭제 엔드포인트에는 경로에 동사("create", "delete")가 포함되어 있다. 그런데 GET 엔드포인트는 왜인지 루트 `/users` 경로에 바로 동작한다. 이유를 알 수 없다.
**문제 #3 — HTTP 메서드 사용이 일관되지 않다**
GraphQL 같은 API는 항상 POST만 쓰거나 GET만 쓰기도 한다. 그건 괜찮다. 적어도 일관성이 있으니 뭘 기대해야 할지 안다. 이 API는 표준 RESTful 동사인 GET, PUT, POST, DELETE를 쓰는 것처럼 보이지만, 유저 삭제 엔드포인트가 어째서인지 DELETE 대신 POST를 쓴다. 그냥 헷갈리게 하려는 것 같다.
**문제 #4 — 기본 키가 일관되지 않다**
RESTful스러운 API라면 리소스 경로에 사용하는 기본 키가 동일할 것이다. 예를 들어 수정은 `PUT /users/{id}`, 삭제는 `DELETE /users/{id}` 식으로. 그런데 이 API에서는 수정 시 id가 요청 바디 안에 들어있고, 삭제는 경로에 email을 쓰고, 조회는 경로에 id를 쓴다.
## UX를 생각하라
UX를 고민한다면 이미 많은 백엔드 개발자보다 한 발 앞서 있는 것이다.
API를 이해하기 쉽고 쓰기 편하게 만들기 위해 노력하자. Stripe나 Mailgun 같은 회사들은 API 자체가 제품인 서비스를 만들었다. 그런 만큼 API UX 설계는 그들에게 가장 중요한 것이다.
REST만의 이야기가 아니다. 방금은 그냥 빠른 예시였을 뿐이다. 라이브러리나 패키지를 만들 때도 API가 있으니, 잘 만들자. 인증 프로토콜은 단순하게 유지하라. 내 쪽에서 코드가 조금 더 필요하더라도, 사용자의 삶을 단순하게 만드는 결정을 내려라. 내부 로직은 쉽게 바꿀 수 있지만, 나쁜 API를 고치는 건 어렵다 — breaking change와 메이저 버전 업그레이드가 필요하다.
---
<p style="text-align: center; font-size: 2em; font-weight: bold;">
2️⃣ 백 개발자가 왜 UX에 관심을 가져야 하는가?
</p>
<a href="https://dev.to/koladev/why-should-backend-developers-care-about-ux-48op" target="_blank" style="display:block; border:1px solid #ddd; border-radius:8px; padding:16px; text-decoration:none; color:inherit; margin-bottom:8px;">
<div style="font-weight:bold; margin-bottom:4px;">Why should backend developers care about UX?</div>
<div style="font-size:0.85em; color:#888;">dev.to</div>
</a>
# 2. 백엔드 개발자가 왜 UX에 관심을 가져야 하는가?
**백엔드 개발자인 당신이 UX는 내 문제가 아니라고 생각한다면, 그게 틀렸다는 걸 증명해 보이겠다.**
사실 새로운 이야기는 아니다. 지난 10년 초반부터 기업들은 사용자 중심 제품 철학의 중요성을 이해하기 시작했다.
이는 팀 워크플로우의 진화, 기술 산업에서 디자이너 역할에 대한 더 나은 평가, 그리고 개발과 마케팅의 변화로 이어졌다.
그러나 UX의 중요성을 제대로 인식하는 기업은 아직 많지 않다. 그리고 개발자들, 특히 백엔드 개발자들은 UX가 자신의 문제가 아니라고 생각한다.
명확히 짚고 넘어가자.
## UX는 UI가 아니다
디자이너가 아닌 사람들이 흔히 갖는 첫 번째 오해는 UX와 UI가 같다는 것이다.
완전히 틀린 말은 아니지만, 두 개념은 혼동해선 안 된다.
UI는 본질적으로 어떻게 보이는가이고, UX는 사용자 경험에 어떤 영향을 주는가이다. 그리고 훌륭한 UI가 훌륭한 UX를 보장하지는 않는다.
## UX는 성능, 확장성, 그리고 관용에 기반한다
이 특성들은 백엔드와 직결된다. 사용자에게 가장 중요한 것 중 하나는 시스템의 반응성이다.
무의식적인 과정이지만, 애플리케이션이 느리면 사용자는 다음에 그것을 사용하지 않을 가능성이 높다.
예를 들어, 의사들이 서로 연결하고 메시지로 연락할 수 있는 의료진 소셜 미디어 앱이 있다고 하자.
특정 의사를 찾는 사람의 첫 번째 행동은 검색창을 이용하는 것이다.
요청이 전송되면, 백엔드는 이름, 연락처, 병원, 프로필 사진 등의 정보를 담은 JSON 페이지네이션 응답(50건)을 반환한다.
이제 수백, 수천 명의 의사가 동시에 이 작업을 한다고 상상해보자. 백엔드가 반응성을 유지해야 한다는 건 자명하다.
모든 프로젝트에서 백엔드에 적합한 설정과 도구를 선택하는 것은 훌륭한 UX를 위해 매우 중요하다.
## UX 담당자와 백엔드 개발자의 소통이 좋을수록 제품도 좋아진다
커뮤니케이션은 모든 협업 팀에서 필수적인 역량이다. 모든 IT 종사자는 최소한 다른 팀과 명확하게 소통하며 자신의 작업의 한계와 가능성을 이해시킬 수 있어야 한다고 생각한다.
이는 백엔드 개발자와 UX 디자이너 모두에게 해당된다. 백엔드 개발자는 UX 프로세스에 참여해야 한다.
그들은 UX 디자이너가 데이터를 가져오는 데 왜 시간이 걸리는지, 왜 에러가 발생하는지, 언제 어떻게 사용자에게 알림을 줘야 하는지, 그리고 언제 사용자가 모르게 수정할 수 있는지 등 백그라운드에서 일어나는 일들을 이해하도록 도울 수 있다.
## UX 옹호자가 되어라
UX 옹호자가 되는 것은 UX가 무엇인지, 그 중요성, 그리고 UX 디자이너가 실제로 무엇을 하는지 이해하는 것에서 시작된다.
왜 옹호해야 하는가?
모든 사람이 UX에 영향을 미친다.
모든 비즈니스적 결정과 기술적 결정은 UX에 영향을 준다. 그리고 많은 기업들이 이를 인식하지 못하는 경우가 많다. 사용자 중심 제품 문화는 다음과 같은 수많은 장점을 가진다:
- 생산성 향상
- 매출 및 수익 증가
- 교육 및 지원 비용 절감
- 개발 시간 및 비용 단축
- 유지보수 비용 절감
- 고객 만족도 향상
논쟁의 여지가 없다. 오늘날 제품이 성공하려면 반드시 사용자 중심이어야 한다.
UX 공부를 시작하기 위해, [개발자를 위한 UX](https://uxengineer.com/blog/ux-for-developers) 블로그와 Medium publication [UXPlanet](https://uxplanet.org)을 추천한다. 개발자를 위한 UX: 일상적인 개발 업무에 사용자 중심 설계 원칙을 통합하는 방법([UX for Developers: How to Integrate User-Centered Design Principles Into Your Day-to-Day Development Work](https://www.amazon.com/Developers-User-Centered-Day-Day-Development/dp/1484242262))이라는 책도 읽어볼 수 있다. 이 책은 UX와 비즈니스에서의 중요성을 내게 알려준 책이기도 하다. UX 개념을 한 번도 접해본 적 없다면 시작하기에 아주 좋은 책이다..
## 마치며
백엔드 개발자라면, UX 프로세스에서 당신이 얼마나 중요한지 충분히 납득했기를 바란다.
UX 옹호자가 되는 것은 큰 요구이고, 때로는 시간의 문제이기도 하다는 걸 안다.
하지만 당신이 만들고 있는 제품은 반드시 성공해야 한다. 만약 당신의 조직이 아직 UX 성숙도에 도달하지 못했다면, 경험을 근본적으로 변화시키는 것이 아니라 사소한 디자인 개선만 하는 데 그치게 될 것이다.
---
<p style="text-align: center; font-size: 2em; font-weight: bold;">
3️⃣ UX 디자이너와 백엔드 개발자: 특별한 관계
</p>
<a href="https://10clouds.com/blog/design/ux-designer-backend-developer/" target="_blank" style="display:block; border:1px solid #ddd; border-radius:8px; padding:16px; text-decoration:none; color:inherit; margin-bottom:8px;">
<div style="font-weight:bold; margin-bottom:4px;">UX Designer and Back-end Developer: Brothers in Arms</div>
<div style="font-size:0.85em; color:#888;">10clouds.com</div>
</a>
# 3. UX 디자이너와 백엔드 개발자: 특별한 관계
디자인 프로세스의 궁극적인 목표는 문제를 해결하는 것이다. 그것만큼 단순한 이야기는 없다. 하지만 프로세스를 깊이 파고들수록 점점 복잡해지고, 점점 더 많은 도전과 질문에 직면하게 된다. 그렇다면 UX 디자이너와 백엔드 개발자의 관계를 최대한 생산적으로 만들기 위해 무엇을 할 수 있을까?
예를 들어, 핵심 이슈를 파악하고, 사용자 니즈와 비즈니스 목표 사이, 그리고 디자인과 기술적 측면 사이에서 완벽한 균형을 찾아야 한다. 이 모든 것을 고려해 최선의 해결책을 내놓는 것이 디자이너의 역할이다. 하지만 우리는 혼자 싸우는 게 아니다. 백엔드 개발자와 힘을 합치는 것이 결과물을 위해 최선이다.
## 협력이 전반적인 사용자 경험을 향상시킨다
우리는 진공 속에서 일하지 않는다는 걸 기억해야 한다. 디자이너로서 우리는 항상 더 큰 팀의 일부다. 애자일 방법론 안에서 일할 때 이는 특히 중요한데, 이런 환경에서는 상황이 빠르게 변하고 많은 사람들이 최종 제품의 완성에 영향을 미치기 때문이다. 더 나은 제품을 만들고 싶다면, 개발자들과 문제와 해결책에 대해 더 많은 시간을 들여 이야기해야 한다. 하지만 여기서 자주 맞닥뜨리는 큰 문제가 있다. 바로 디자이너와 개발자 사이의 공통 언어를 찾기가 어렵다는 것이다.
디자이너들은 HTML/CSS/Javascript 코딩을 배우는 것이 해답이라고 생각하는 경향이 있다. 기술에 대한 이해를 논할 때 대부분의 논의가 프론트엔드에만 집중되는 경우가 많다. 하지만 디자인을 만들 때는 훨씬 더 많은 것을 고려해야 한다. 진정한 몰입감 있는 경험을 만들기 위해 백엔드 개발자와 그들의 관점을 전체 프로세스에 포함시켜야 한다.
## 물어봐야 할 질문들이 많다
"그건 안 됩니다" — 개발자에게서 이 말을 들어본 적이 한 번쯤은 있을 것이다. 연락처 폼의 이름과 성 필드를 나누는 것처럼 사소한 것에서도 말이다.
사실 우리는 개발 제약과 제품 범위 안에서 무엇이 실현 가능한지조차 인식하지 못할 때가 많다. 완벽한 해결책을 그리기 시작하기 전에 마지막으로 스스로에게 이런 질문을 던져본 게 언제였는가:
- 데이터베이스를 직접 만드는 것으로 충분한가, 아니면 서드파티에서 데이터를 가져와야 하는가?
- 사용자가 프로세스를 완료하지 않은 경우에도 모든 데이터를 저장해야 하는가? 다른 기기에서 이어서 하고 싶다면?
- 어느 시점에 사용자 요청을 데이터베이스에 쿼리로 보내는가?
- 나중에 활용할 수 있도록 데이터베이스의 모든 정보를 어떻게 구조화할 것인가?
- 오프라인 모드에서 앱은 어떻게 동작해야 하는가? 기본 기능은 사용할 수 있어야 하는가?
- 사용자 생성 콘텐츠는 캐시해뒀다가 온라인 상태가 되면 서버로 보내야 하는가? 어떤 상황에서도 사용자에게 어떤 정보를 보여줘야 하는가?
- 앱을 나중에 관리하는 담당자가 CMS에서 사용할 수 있는 옵션은 무엇인가?
- 그리고 내가 가장 좋아하는 질문: 이 백엔드의 마법을 사용자에게 유리하게 어떻게 활용할 수 있는가?
## 실행 취소
Google Drive에서 중요한 파일을 실수로 삭제해본 적 있는가? 걱정하지 않아도 된다. "실행 취소"를 클릭하면 파일을 복원할 수 있는데, 이는 단 하나의 간단한 트릭 덕분이다. 파일이 아직 실제로 삭제되지 않았기 때문이다. 삭제됐다는 알림을 받더라도, 백엔드에서는 아무 행동도 취해지지 않은 상태다.
알림이 몇 초 후에 사라질 때 비로소 파일이 실제로 삭제된다. 즉 "실행 취소"는 실제로 무언가를 되돌리는 게 아니라, 서버가 행동을 취하는 것을 막는 것이다.
## 성능 높이기
Instagram에서 사용자 행동의 성능을 높이기 위해 많은 동작들이 낙관적으로 처리된다. 하트 아이콘을 클릭하면 연결이 끊겨 있어도 항상 불이 켜진다. 물론 연결이 없으면 데이터가 서버에 업로드되지 않지만, 앱은 서버의 확인을 기다리지 않고 마치 성공한 것처럼 반응한다. 서버가 승인을 확인하지 않았더라도 행동의 결과가 즉시 나타난다.
또 다른 예시로, Instagram은 사용자가 사진을 선택하는 순간 서버에 업로드를 시작한다. "사진 게시" 버튼을 클릭할 때쯤이면 대부분의 경우 이미 서버에 업로드가 완료되어 피드에 표시될 준비가 된 상태다.
## 폼 작성 도움
사용자가 더 적은 오류로 폼을 작성하게 하고 싶은가? 프로세스를 단순화할수록 오류가 줄어든다. 서드파티 데이터베이스에서 우편번호를 가져올 수 있을 때 이 방법을 써보자. 필드 순서를 바꿔서 사용자가 우편번호를 먼저 입력하게 하는 것이다. 우편번호가 입력되면 데이터베이스가 자동으로 도시와 지역 필드를 채워준다.
## 마치며
백엔드 세계는 많은 디자이너에게 미지의 영역이다. 처음에는 어렵게 느껴질 수 있지만, 몰입감 있는 제품 경험을 만들기 위해서는 이를 이해하고 디자인 프로세스에 포함시키는 것이 중요하다.
디자인은 대화라는 것을 기억하자. 개발 과정에서 팀 전체와 나누는 대화, 그리고 출시 후 사용자와 나누는 대화다.
훌륭한 제품을 만들고 싶다면, 다른 팀원들이 하는 말에 귀를 기울여야 한다. 그때 비로소 마법이 일어난다.