<div id="readability-page-1" class="page"><div itemprop="articleBody">
            <p>이력서를 보다 보면, “UX/UI의 중요성을 높게 생각하는 개발자” 또는 “UX/UI에 관심이 많은 개발자”라는 표현을 종종 접하곤 한다. 사실 나 역시 이와 유사한 문구를 이력서에 써왔는데, 이런 생각이 들었다. 프론트엔드 개발자는 UX/UI를 어디까지 깊게 고민해야 할까? 그리고 그 경험을 현실적으로 어떻게 진행할 수 있을까? 이러한 질문에서 시작된 고민을 글로 풀어보고자 한다. <del>반성의 의미도 조금 담아보면서.</del></p>
<p><strong>TL;DR</strong> 유저 중심적으로 생각해야 하며, 그 깊이는 PM이나 디자이너와 맞먹어야 한다.</p>
<p>프론트엔드 개발에서 자주 마주치는 과제들, 예를 들어 성능 최적화, 캐싱 전략, 유연한 상태 관리 같은 작업은 왜 필요한 걸까?<br>“기능 개발만으로도 충분히 바쁜데, 이런 작업들을 할 여유가 있을까?”라는 의문이 들 수도 있다.<br>하지만 이 질문 자체에서 관점을 바꿔 단순히 요구사항만 구현하는 개발자가 아닌, 유저 중심적 사고로 개발에 접근해야 더 높은 만족을 줄 수 있는 서비스를 만들 수 있다.</p>
<h2 id="사용자-중심적-개발"><a name="user-centered"></a><a href="#사용자-중심적-개발" title="사용자 중심적 개발"></a>사용자 중심적 개발</h2><p>서비스 개발에서 프론트엔드 개발자가 다뤄야 할 작업은 크게 세 가지로 나뉜다.</p>
<p><strong>1️⃣ 기획 의존적인 기능 개발</strong><br>서비스의 기본적인 뼈대와 콘텐츠를 구현하는 작업이다. 이 과정에서는 빠르게 시장 검증을 돕거나, 비즈니스 목표를 실현하는 데 중점을 둔다.</p>
<p><strong>2️⃣ 기능 외 작업</strong><br>리팩토링, POC(개념 증명), 테스트 코드 작성 등 기술적 안정성을 높이는 작업이 포함된다. 이 과정은 프로젝트의 지속가능성과 확장성을 보장한다.</p>
<p><strong>3️⃣ 유저 중심적 개선 작업</strong><br>서비스를 이용하는 유저 경험을 개선하는 작업이다. 예를 들어, 성능 최적화, 사용자 접근성 개선, 로딩 속도 최적화 등이 이에 해당한다.</p>
<p><strong>개발자는 유저가 웹 서비스를 이용하는 전체적인 흐름을 이해하고, 이 흐름을 방해하는 요소들을 식별하고 개선해야 한다.</strong><br>이러한 노력은 결국 <strong>유저의 락인(lock-in)</strong> 을 강화하고, 이탈률을 줄이며, 서비스 충성도를 높이는 결과로 이어진다. 이는 서비스 차원에서 매우 큰 임팩트를 남기는 작업이다.</p>
<p>조직의 방향성과 성숙도에 따라 작업 우선순위는 달라질 수 있다.<br>초기 스타트업의 경우 빠른 시장 검증과 MVP 출시가 중요하기 때문에 기능 개발(1번)만으로도 충분히 바쁜 경우가 많다.<br>성장 단계의 조직에서는 2번, 3번 작업이 점차 강조되며, 기술적 토대를 튼튼히 다지기 시작한다.<br>개발자는 조직의 현재 단계와 방향성에 맞춰 적응하면서도, <strong>스스로 2번과 3번 작업을 챙기는 역량을 길러야 한다.</strong></p>
<h2 id="Action"><a name="action"></a><a href="#Action" title="Action"></a>Action</h2><p>TDD책에서 이런말이 나온다. </p>
<blockquote>
<p>테스트를 언제 작성하는 것이 좋을까?<br>테스트 대상이 되는 코드를 작성하기 직전에 작성하는 것이 좋다.<br>코드를 작성한 후에는 테스트를 만들지 않을 것이다. (…)<br>[테스트 주도 개발] 중 일부…</p>
</blockquote>
<p>사용자 경험을 ‘좋게’만드는 작업들을 기능개발을 하면서 진행하게 된다면 나중에 진행하는 것보다 비용측면에서도 효율적일 것이다. (진행비용, 설득비용, …)</p>
<p>개발을 시작하기 이전에 간단하게 계획해보고 추적해보면된다.</p>
<ol>
<li>타겟 유저의 이해도를 올린다.</li>
<li>어떻게 구현할지 계획하며 사용자 경험을 올릴 수 있는 point를 되짚어보고 나열해본다.</li>
<li>나열된 task를 impact와 리소스를 고려하여 우선순위를 지정한다.</li>
</ol>
<p>기본적인 원칙은 유저는 특정 액션 이후에는 <strong>예상가능한 다음 단계를 빠르게 제공해줘야한다.</strong> 이미 학습되어있는 액션을 무의식적으로 했을 때, 동작할 수 있도록 해야하며, 다양한 환경에서 접근 하는 유저를 커버해야한다.</p>
<h3 id="1-타겟-유저-이해하기"><a href="#1-타겟-유저-이해하기" title="1. 타겟 유저 이해하기"></a>1. 타겟 유저 이해하기</h3><p>개발자가 자신이 구현해야할 기능을 사용할 유저가 아닐지라도 목표 유저의 특성을 이해하려고 노력하면 좋다.<br>유저 테스팅, UX 리뷰, 행동 분석 등을 통해 이해도를 올릴 수 있다. (옵저버라도 적극적으로 참여해보자.)<br>유저의 이해도를 올리면 기술적 해결책을 사용자의 관점에서 접근할 수 있게된다.</p>
<h3 id="2-계획해보기"><a href="#2-계획해보기" title="2. 계획해보기"></a>2. 계획해보기</h3><ol>
<li>내가 개발하는 기능의 유저 시나리오를 나열합니다.<ul>
<li>유저는 어떤 문제를 해결하기 위해 이 기능을 사용하는가?</li>
<li>이 기능의 어느 단계에서 불편을 겪을 가능성이 있는가?</li>
</ul>
</li>
<li>개선 가능한 영역을 정의한다.<ul>
<li>기술적으로 해결할 수 있는 부분은 무엇인가?</li>
<li>디자이너와 협업이 필요한 부분은 무엇인가?</li>
</ul>
</li>
<li>우선순위를 설정한다.<ul>
<li>이탈률, 사용자 비중, 개선 효과 등을 기준으로 순위를 매깁니다.</li>
<li>구현에 필요한 리소스도 고려해봅니다.</li>
</ul>
</li>
</ol>
<p>기능별로 현재의 상태와 입력하는 데이터, 액션 이후의 예상하는 반응을 고려하면서 위 질문에 답해보면 된다.</p>
<h3 id="3-간단한-예시"><a href="#3-간단한-예시" title="3. 간단한 예시"></a>3. 간단한 예시</h3><p>유저는 가계부를 관리할 수 있다.</p>
<ul>
<li><p>목적: 유저는 돈관리를 위해서 매일매일 가계부를 작성하여 소비내역을 추적한다.</p>
</li>
<li><p><strong>기능1</strong>: 유저는 소비한 내역을 등록할 수 있다.</p>
<ul>
<li>소비한 금액을 작성할 수 있다.</li>
<li>날짜를 입력할 수 있다.</li>
</ul>
</li>
</ul>
<ol start="0">
<li>화면 목표: 소비내역을 작성하고 제출하고 싶다.</li>
<li>환경: 키보드 입력, 모바일, 오른손잡이, …</li>
<li>불편요소: 이 기능의 어느 단계에서 불편을 겪을 가능성이 있는가?<ul>
<li>입력: 금액을 입력할 때 금액 단위를 바로 파악하기 힘들 수 있다.</li>
<li>이동: 금액 입력 후 날짜 입력으로 이동할 때 번거로울 수 있다. (focus out, focus in, …)</li>
</ul>
</li>
<li>개선가능<ul>
<li>입력: 금액을 입력할 때 쉼표표기가 보이도록 한다.</li>
<li>이동: enter를 누르면 다음 input이 포커스되도록 한다.</li>
</ul>
</li>
</ol>
<p>구체적인 예시는 다음 포스팅 때 상세하게 나열해보려고한다.</p>
<h2 id="마무리"><a href="#마무리" title="마무리"></a>마무리</h2><p>작은 부분이라도 사용자의 여정을 개선하는 데 집중한다면, 그것이 곧 더 나은 사용자 경험과 성공적인 서비스로 이어질 것이다.<br>지금 구현하는 기능의 유저를 생각하며, 그들이 어떤 행동을 하고 어떤 기대를 가질지를 고려해봐야한다. 그리고 현실적으로 이 부분을 실제 구현해보며 습관화를 들여야한다.</p>

        </div></div>

필오의 개발일지

이력서를 보다 보면, “UX/UI의 중요성을 높게 생각하는 개발자” 또는 “UX/UI에 관심이 많은 개발자”라는 표현을 종종 접하곤 한다. 사실 나 역시 이와 유사한 문구를 이력서에 써왔는데, 이런 생각이 들었다. 프론트엔드 개발자는 UX/UI를 어디까지 깊게 고민해야 할까? 그리고 그 경험을 현실적으로 어떻게 진행할 수 있을까? 이러한 질문에서 시작된 고민을 글로 풀어보고자 한다. 반성의 의미도 조금 담아보면서.
TL;DR 유저 중심적으로 생각해야 하며, 그 깊이는 PM이나 디자이너와 맞먹어야 한다.
프론트엔드 개발에서 자주 마주치는 과제들, 예를 들어 성능 최적화, 캐싱 전략, 유연한 상태 관리 같은 작업은 왜 필요한 걸까?
“기능 개발만으로도 충분히 바쁜데, 이런 작업들을 할 여유가 있을까?”라는 의문이 들 수도 있다.
하지만 이 질문 자체에서 관점을 바꿔 단순히 요구사항만 구현하는 개발자가 아닌, 유저 중심적 사고로 개발에 접근해야 더 높은 만족을 줄 수 있는 서비스를 만들 수 있다.
사용자 중심적 개발
서비스 개발에서 프론트엔드 개발자가 다뤄야 할 작업은 크게 세 가지로 나뉜다.
1️⃣ 기획 의존적인 기능 개발
서비스의 기본적인 뼈대와 콘텐츠를 구현하는 작업이다. 이 과정에서는 빠르게 시장 검증을 돕거나, 비즈니스 목표를 실현하는 데 중점을 둔다.
2️⃣ 기능 외 작업
리팩토링, POC(개념 증명), 테스트 코드 작성 등 기술적 안정성을 높이는 작업이 포함된다. 이 과정은 프로젝트의 지속가능성과 확장성을 보장한다.
3️⃣ 유저 중심적 개선 작업
서비스를 이용하는 유저 경험을 개선하는 작업이다. 예를 들어, 성능 최적화, 사용자 접근성 개선, 로딩 속도 최적화 등이 이에 해당한다.
개발자는 유저가 웹 서비스를 이용하는 전체적인 흐름을 이해하고, 이 흐름을 방해하는 요소들을 식별하고 개선해야 한다.
이러한 노력은 결국 유저의 락인(lock-in) 을 강화하고, 이탈률을 줄이며, 서비스 충성도를 높이는 결과로 이어진다. 이는 서비스 차원에서 매우 큰 임팩트를 남기는 작업이다.
조직의 방향성과 성숙도에 따라 작업 우선순위는 달라질 수 있다.
초기 스타트업의 경우 빠른 시장 검증과 MVP 출시가 중요하기 때문에 기능 개발(1번)만으로도 충분히 바쁜 경우가 많다.
성장 단계의 조직에서는 2번, 3번 작업이 점차 강조되며, 기술적 토대를 튼튼히 다지기 시작한다.
개발자는 조직의 현재 단계와 방향성에 맞춰 적응하면서도, 스스로 2번과 3번 작업을 챙기는 역량을 길러야 한다.
Action
TDD책에서 이런말이 나온다. 
테스트를 언제 작성하는 것이 좋을까?
테스트 대상이 되는 코드를 작성하기 직전에 작성하는 것이 좋다.
코드를 작성한 후에는 테스트를 만들지 않을 것이다. (…)
[테스트 주도 개발] 중 일부…
사용자 경험을 ‘좋게’만드는 작업들을 기능개발을 하면서 진행하게 된다면 나중에 진행하는 것보다 비용측면에서도 효율적일 것이다. (진행비용, 설득비용, …)
개발을 시작하기 이전에 간단하게 계획해보고 추적해보면된다.
타겟 유저의 이해도를 올린다.
어떻게 구현할지 계획하며 사용자 경험을 올릴 수 있는 point를 되짚어보고 나열해본다.
나열된 task를 impact와 리소스를 고려하여 우선순위를 지정한다.
기본적인 원칙은 유저는 특정 액션 이후에는 예상가능한 다음 단계를 빠르게 제공해줘야한다. 이미 학습되어있는 액션을 무의식적으로 했을 때, 동작할 수 있도록 해야하며, 다양한 환경에서 접근 하는 유저를 커버해야한다.
1. 타겟 유저 이해하기
개발자가 자신이 구현해야할 기능을 사용할 유저가 아닐지라도 목표 유저의 특성을 이해하려고 노력하면 좋다.
유저 테스팅, UX 리뷰, 행동 분석 등을 통해 이해도를 올릴 수 있다. (옵저버라도 적극적으로 참여해보자.)
유저의 이해도를 올리면 기술적 해결책을 사용자의 관점에서 접근할 수 있게된다.
2. 계획해보기
내가 개발하는 기능의 유저 시나리오를 나열합니다.
유저는 어떤 문제를 해결하기 위해 이 기능을 사용하는가?
이 기능의 어느 단계에서 불편을 겪을 가능성이 있는가?
개선 가능한 영역을 정의한다.
기술적으로 해결할 수 있는 부분은 무엇인가?
디자이너와 협업이 필요한 부분은 무엇인가?
우선순위를 설정한다.
이탈률, 사용자 비중, 개선 효과 등을 기준으로 순위를 매깁니다.
구현에 필요한 리소스도 고려해봅니다.
기능별로 현재의 상태와 입력하는 데이터, 액션 이후의 예상하는 반응을 고려하면서 위 질문에 답해보면 된다.
3. 간단한 예시
유저는 가계부를 관리할 수 있다.
목적: 유저는 돈관리를 위해서 매일매일 가계부를 작성하여 소비내역을 추적한다.
기능1: 유저는 소비한 내역을 등록할 수 있다.
소비한 금액을 작성할 수 있다.
날짜를 입력할 수 있다.
화면 목표: 소비내역을 작성하고 제출하고 싶다.
환경: 키보드 입력, 모바일, 오른손잡이, …
불편요소: 이 기능의 어느 단계에서 불편을 겪을 가능성이 있는가?
입력: 금액을 입력할 때 금액 단위를 바로 파악하기 힘들 수 있다.
이동: 금액 입력 후 날짜 입력으로 이동할 때 번거로울 수 있다. (focus out, focus in, …)
개선가능
입력: 금액을 입력할 때 쉼표표기가 보이도록 한다.
이동: enter를 누르면 다음 input이 포커스되도록 한다.
구체적인 예시는 다음 포스팅 때 상세하게 나열해보려고한다.
마무리
작은 부분이라도 사용자의 여정을 개선하는 데 집중한다면, 그것이 곧 더 나은 사용자 경험과 성공적인 서비스로 이어질 것이다.
지금 구현하는 기능의 유저를 생각하며, 그들이 어떤 행동을 하고 어떤 기대를 가질지를 고려해봐야한다. 그리고 현실적으로 이 부분을 실제 구현해보며 습관화를 들여야한다.

사용자 중심의 프론트엔드 개발

댓글