“디자인, 개발, 데이터 분석 다 하라고요?" UI/UX 디자이너의 처절한 화면 설계 생존 썰

1. 온라인 서비스/IT프로그램의 화면을 설계한다는 것에 대하여

made by gemini

온라인 서비스나 시스템을 설계한다는 것은 세상의 불편함을 해소하고, 이를 통해 수익을 창출하는 비즈니스 행위다. 서비스를 지속하기 위해서는 고객의 불편함을 끊임없이 개선해 나가야하며, 개발·경영·마케팅 등 다양한 분야의 전문가들이 모여 조직을 꾸리고 시스템을 관리한다.

이 과정에서 조직의 구성원들은 각자의 관점에 따른 수많은 의견을 낸다. 개발 효율을 위한 화면 구성, 매출 증대를 위한 시스템, 클릭률과 리텐션을 높이기 위한 전략 등 저마다의 목표가 뚜렷하다.

하지만 정교하게 조율되지 않은 내부의 의견은 때로 사용자에게 고통을 전가한다. 지표 향상을 위해 다크 패턴을 서슴없이 사용하거나, 개발 편의를 위해 불필요한 절차를 만드는 식이다. 자연스럽게 이러한 파편화된 관점들을 통합하여 사용성을 수호하고, 제품의 올바른 방향을 결정하는 역할이 중요해진다.

2. 제품의 방향을 결정하는건 UI/UX디자이너인가?

그렇다면 제품의 방향을 결정하는 것은 누구일까? 초기 제품의 대한 의사결정을 하는 것은 스티브잡스와 같은 대표(창업자)가 모든 최종결정을 내리게 된다. 그러나 제품이 발전됨에 따라 점점화면이 복잡해지고 조직의 규모가 커짐에 따라 창업자는 더 큰 비전을 설계해야 하는 경우가 생기고 화면을 설계하는 역할에 대한 위임이 일어나게된다.

그러나 화면이라는 것은 사용자가 시스템에 반응하는 최종 소통창구이다. 사용자가 화면을 통해 시스템과 대화하고, 시스템의 유도에 따라 동작한다. 그렇기 때문에 개발팀도 마케팅팀도 데이터 팀도 결국에는 화면에 대한 변화를 원하게 된다. 매출을 올리기 위해서는, 개발을 더욱 효율적으로 하기 위해서는, 영업을 위해서는 등등 다양한 변경사항을 요구하게 되며 이러한 요구사항들을 잘 수용하여 최종적인 화면을 제안하는 역할이 UI/UX디자이너로서의 역할이다.

모두가 화면에 대한 의견을 가지고 있지만 결국 사용성과 화면에 대한 전문성은 결국 UI/UX 디자이너의 몫이다. 사실 사람들은 생각보다 화면 구조에 대해 깊게 고민하지 않는다. 서비스를 사용하는 유저들도 마찬가지다. 그들은 불편한 시스템을 마주했을 때 "이 요소가 문제네"라며 친절하게 분석해주지 않는다. 그저 안좋은 경험과 불편함에 대해 민원을 넣을 뿐이다.

여기서 디자이너의 진짜 역량이 갈린다. 유저가 뱉어내는 불편함을 곧이곧대로 듣고 화면에 옮기는 건 어쩌면 정말로 문제를 해결하는 것이 아닐 수 있다. 우리는 그 감정 섞인 피드백 뒤에 숨겨진 본질을 찾아야 한다. 날카로운 가설을 세우고, 인터뷰로 파고들고, 데이터를 수집해서 그 가설이 맞는지 체크하는 프로세스가 확립되는 것은 당연하다.~~(예산과 인력이 충분하다면)~~

결국 사용자가 느끼는 불편함을 정확히 정의하고 화면에서 해소하기 위해, UI/UX 디자이너는 기술적 요소(Element)에 대한 이해와 심미적 안목, 그리고 사용자의 인지 프로세스와 HCI 지식을 바탕으로 이를 해결하는 역할을 해내야만 한다.

3. 누가 최종 결정자가 되어야 하는가?

디자인 업무는 전반적으로 경영과 닮아 있다. 모든 것을 해야하며 많은 이와 대화해야 한다. UX의 개척자 이자 애플의 부사장까지 역임했던 도널드 노먼은 다음과 같은 이야기를 했다.

시스템을 디자인할 때는 예상치 못한 결과나 사람들이 오용할 가능성을 생각해야 합니다. 전부 막을 순 없지만, 가능성을 낮추기 위해 고민하고 최선을 다하는 일이 정말 중요해요. 많은 디자이너가 “디자인은 완벽했는데, 마케팅팀이 바꿨어요.” 같은 불평을 하곤 하는데요. 저는 완벽하지 않았기 때문이라고 대답합니다. 그리고 이렇게 말하죠. “디자인할 때 다른 팀이 그 자리에 있었나요? 왜 없었나요? 마케팅이나 엔지니어링팀과 협력해 그들에게 무엇이 필요한지 이해했다면 나중에 디자인을 바꿀 필요도 없었을 텐데요.” 사일로(Silo)에서 일하지 말고, 모든 분야의 사람들과 협력하세요.

차츰차츰 모든 부분에 대해서 공부하다보면 디자인 부터 개발, 데이터 분석, 마케팅 등 모든 분야에 대해서 이해하고 고민하는 지점에 도달하게 된다. 그러다 보면 현타도 온다. 이걸내가 다 이해해야한다고?! 라는 생각과 동시에 많은 일을 하지만 시장논리로 인해 연봉은 제일 낮을 수도 있다는 사실이 스트레스로 다가올 수 있다. 하지만 연봉이 세상의 모든 이의 기준일 필요는 없다. 나도 개발에 대해서 더 공부해서 개발자 테크트리로 굳이 넘어가지 않은 이유는 설계하고 디자인 하는 일의 재미가 있었기 때문이다.

다시 본론으로 돌아와서, UI/UX 디자이너는 결국 조율자가 되어야 한다. 오케스트라를 지휘하는 지휘자처럼 전반적인 그림을 살피고 소리가 부족한 부분은 더욱 크게, 소리가 너무 크게 작동하는 부분은 작게 줄이며 조화로운 선율을 만들어 관객들에게 감동을 전달해주어야 한다. IT 서비스도 마찬가지이다. 개발적인 부분의 효율과 마케팅적인 소구점 등을 분석해 가장 최적의 방안을 제공해야 한다. 물론 이는 유토피아 같은 이야기로 이론적인 접근일 뿐이다.

4. 실전에서 마주한 갈등과 깨달음

그래서 내가 경험했던 UI/UX디자이너의 역할에 대한 갈등 에피소드를 이야기하며, 이 유토피아(이상)와 현실 사이의 고민 지점에 대해 공감을 구하고 나누고자 한다. 체계가 부족한 환경에서 고군분투하는 디자이너들에게 이 기록이 상황 개선을 위한 실마리가 되길 바란다.

Case 01. 경영자 vs 디자이너: "추상을 실체로 만드는 파트너십"

경영진의 결정에 따라 기획의 처음부터 끝까지 통째로 변경되는 상황을 B2C UI/UX 디자이너로서 일을 하면 심심치 않게 경험해봤을 것이다. 나 또한 B2B 회사에서 B2C 회사로 이직을 하며 이러한 상황을 처음 겪고 적잖이 당황했다.

이전 회사에서 B2B 보안 솔루션의 인터페이스를 디자인할 때는 전문 도메인 지식을 바탕으로 연구와 개발을 거쳐 제품을 설계했다. 논리와 기술적 근거가 명확했기에 경영진 차원에서 화면 전체를 뒤집으라고 요구하는 경우는 거의 없었다. 리더들은 전문가의 판단을 존중했고, 그 안에서 기획은 벽돌을 쌓듯 견고하게 다져졌다. 그래서인지 솔직히 처음에는 B2C 기획이 재미없다는 생각도 들었다. B2B만큼 깊은 도메인 전문성이 요구되는 것도 아니었고, 상대적으로 단순해 보이는 화면들을 기획하는 데 방향성에 대한 갈피를 잡지 못하는 상황이 기획의 재미를 반감시키기도 했다.

공들여 설계를 마쳐도 경영진이나 대표의 판단 한마디에 모든 게 원점으로 돌아가는 상황이 반복됐다. 당시의 짧은 생각으로는 ‘왜 기획 히스토리가 관리되지 않을까?’라는 회의감이 앞섰다.

하지만 지금에 와서 돌아보니, 당시 B2C 리더들은 건축가라기보다 ‘변화무쌍한 파도를 넘는 항해사’였다. 그들의 잦은 방향 전환은 사업 초기 단계에서 생존을 위한 최적의 모델을 찾기 위한 필연적인 과정이었다. B2B가 정교한 히스토리를 쌓아가는 과정이라면, B2C는 시장의 반응 혹은 그 반응을 예측하는 경영진의 직관에 맞춰 더 유연하고 빠르게 움직여야 했던 것이다. 결국 서비스의 생리에 따라 리더십의 색깔이 다를 수밖에 없음을 이해하게 되면서, 디자이너 또한 그 파도에 맞춰 대처하는 법을 배워야 한다는 것을 깨달았다.

인하우스 디자이너로서 겪은 이 양극단의 리더십에 대한 경험은, 신생 에이전시를 운영하며 만난 수많은 초기 창업자들과의 관계에서 비로소 완성되었다. 에이전시의 클라이언트들은 확고한 비즈니스 구상은 있었으나, 그것이 어떤 화면으로 구현되어야 하는지에 대해서는 구체적인 밑그림이 없었다. 리더가 제시하는 추상적인 모델이 실제 작동할 수 있도록 우선순위를 정하고 인터페이스로 치환하는 과정에서, UI/UX 디자이너는 단순한 작업자가 아닌 실체를 구축하는 ‘비즈니스 파트너’가 되어야 함을 확인했다.

다양한 형태의 조직과 경영자를 경험하며 내린 결론은 명확하다. 비즈니스의 방향(What & Why)은 경영자가 결정하되, 그것이 사용자에게 닿는 방식(How)은 디자이너에게 전적으로 위임해야 한다는 것이다. 경영자가 디자이너를 믿고 화면에 대한 권한을 맡길 때, 비로소 사업의 성공 가능성도 높아지고 좋은 서비스를 제공할 있지 않을까?

Case 02. 조직적 프로세스의 필요성: "개인의 이해를 넘어선 시스템의 힘"

중소기업에서(그 중에 50인미만) UI/UX 디자이너로 근무한다는 것은 뾰족한 체계가 없는 환경을 감내하는 일이다. 나의 첫 커리어 당시 UI/UX디자인에 대한 이해도가 없던 마케팅 팀에서 자체적으로 기획한 제품기획안(화면구성안)을 가지고 와서 디자인을 부탁했다

하지만 UI/UX디자이너로서 마케팅팀에서 제시한 화면구성안의 사용성은 너무 불편했고 이를 개선하기 위해 다시 UX를 설계하여 방향성을 바꾸는 게 좋지 않겠냐고 가이드를 주었지만 마케팅팀의 차장님이 단호하게 “OO씨는 디자인만 해주면 돼” 라는 이야기를 하셔서 디자인만 해서 전달해드렸다.

UI/UX 디자이너라는 직업명이 생기기전에는 기획자, 웹디자이너, 모바일 디자이너라는 용어가 사용되고 현재까지 프로덕트 디자이너, 기획자, 웹디자이너, 모바일 디자이너, UI/UX디자이너가 혼용되서 사용되고 있다. 이는 모두가 이해하는 UI/UX디자이너라는 정의가 다르기 때문이다.

그래서 회사 내부적으로도 직업에 대한, 역할에 대한 정의를 다시 해야하는 경우가 생긴다. UX본부 조직이 있는 곳으로 이직했을 때 OJT를 진행하면서 신규입사자들과 회사 CFO 임원이랑 대화하는 시간이 있었는데 UX 본부가 왜 필요한지, 뭐하는 부서인지 모르겠다" 라는 이야기를 듣기도 했다.

모든 개개인이 UI/UX 직업에 대해 이해하고 있지도 이해할 필요도 없다는 것이다. 다만 이는 회사의 역량과 직결되기도 한다. 앞서 마케팅팀과의 갈등에서는 회사 내부적으로 UX조직이 존재하지 않고 연구소 내부에 UI/UX디자이너로서의 역할을 하고 있었기 때문에 제품의 방향이 편리성보다는 개발가능성에 초점이 맞추어져 있었다.

하지만 후자의 경우 UX본부라는 조직이 명확했고 한 임원, 한 개개인의 개인적인 생각과 무관하게 회사의 프로세스는 여전히 UX 본부를 중심으로 돌아갔다. 이것이 거버넌스의 힘이다. 중소기업의 디자이너가 끊임없이 스스로의 존재 가치를 증명해야 한다면, 시스템이 갖춰진 조직의 디자이너는 시스템 안에서 전문성을 발휘하는 데 집중할 수 있다.

Case 03. 주니어 시절의 독학: "특이 케이스가 만든 업무 역량의 확장"

나는 스스로를 다소 특이한 케이스라고 생각한다. 특성화고등학교 출신으로 고등학교 1학년 때부터 개발과 디자인, 3D 디자인 등 컴퓨터 전반에 대해 배웠고, 주변에도 기술을 잘 아는 친구들이 많았다. 이런 배경 덕분에 기술적 중요도에 대한 감각을 일찍 가질 수 있었다.

첫 커리어 또한 일반적인 디자인 에이전시나 IT 기업의 디자인팀이 아닌, 데이터를 다루는 보안 솔루션 업체의 연구소에서 시작했다. 2017년 당시 CS 프로그램을 웹 서비스로 변경하는 업무를 맡았는데 도메인 지식도 사수도 없었다. UI/UX 디자이너라는 직함 대신 '연구소 사원'으로 불리며 인터페이스 설계부터 퍼블리싱까지 담당해야 했다.

시스템이 없는 연구소 환경에서 개발자들은 내 화면을 보고 그대로 구현을 시작했다. 그때 깨달았다. 화면을 그린다는 것은 단순히 사용자를 위하는 일을 넘어, 기술 개발의 방향과 가이드라인을 결정하는 일이라는 것을 말이다. 사수 없는 환경에서 살아남기 위해 6년 동안 나름의 프로세스를 정립했고, 보안 회사의 특성상 IT 전문가들과 협업해야 했기 때문에 개발 공부를 멈출 수 없었다.

디자이너로서 시작부터 기술적 맥락에 깊게 발을 담근 나의 배경은 자연스럽게 업무 역량의 범위를 넓혔다. 개발을 이해하면 설계가 견고해진다는 것을 알지만, 모든 디자이너가 개발을 깊게 알아야 한다고 주장하는 것은 아니다. 알면 좋다는 것이고, 사실 알아봤자 연봉을 더 주는 것도 아니다. 하지만 이 특수한 환경에서 길러진 '넓은 역량 범위'는 이후 조직 안에서 디자이너의 역할 정의를 두고 겪게 될 또 다른 견해 차이(Case 04)의 중요한 단초가 되었다.

Case 04. 디자이너 사이의 견해 차이: "분업인가, 통합인가"

앞서 이야기한 UX본부 조직으로 이직했을 때, 디자이너들 사이의 관점 차이를 마주했다. 나는 중소기업에서의 실무 커리어부터 개발, 디자인, 그리고 설계 영역의 모든 부분을 직접 경험하며 쌓아온 통찰을 통해 UI/UX 역량은 통합적이어야 한다고 믿게 되었다. GUI 디자인 역시 설계의 핵심이며, 시각적 완성도는 사용성을 완성하는 요소이자 시스템 설계의 영역이기 때문이다.

당시 팀장님은 GUI 전담팀을 별도로 두어 전문성을 존중하고 팀 단위로 협업하는 방식 선호했다. 반면 나는 UI, UX, 기술적 설계까지 한 사람이 통합적으로 이해했을 때 발생하는 시너지를 중시했다. 한 사람이 시스템 전체를 이해하거나, 적어도 디자인 시스템(Auto Layout, Component, Design Token)을 도입해 시스템적으로 일하는 환경을 구축해야 한다고 주장했다. 소통 비용을 줄이고 설계 의도를 유지하기 위해서는 파편화된 분업보다 통합된 시스템 체계가 중요했기 때문이다. 팀장님은 적기가 아니라고 판단하셨었다.

Case 05. 전문 도메인 지식은 디자이너에게 불필요한가?

이 질문은 내가 다시 재취업하게 된 이유와도 연관이 있다. 내가 인수인계하고 나온 후임 디자이너와 연구소장님 사이에 큰 갈등이 발생하여 해당 디자이너가 퇴사하게 되었고, 회사에서는 이전부터 도메인을 잘 이해하고 있던 나에게 다시 제안을 주셨다.

갈등의 원인은 명확했다. 보안 솔루션이라는 특수한 도메인의 기술적 설명을 이해하고 화면에 반영해야 하는 과정에서, 후임 디자이너는 "사용성에만 집중하고 싶고 기술적인 내용은 알고 싶지 않다"고 선을 그었던 것이다. 개발적 이해도가 없다면 도저히 설계할 수 없는 영역이었기 때문에 발생한 문제였다.

UI/UX 디자이너에게 전문 도메인 지식은 필수적이다. 모든 오프라인 비즈니스가 온라인으로 이동하는 시대에 디자이너가 비즈니스의 본질을 외면해서는 안 된다. 입사 시점에는 지식이 없어도 괜찮지만, 내부 이해관계자들과 소통하며 맥락을 파악하려는 노력이 따라야 한다. 그리고 이러한 노력이 실질적인 결과물로 이어지기 위해서는 앞서 언급한 UX 전용 조직과 시스템의 뒷받침이 필수적이다.

Case 06. 고객이라는 환상: "불만은 해석의 대상이지 정답이 아니다"

가끔 업무를 하다보면 지나치게 고객의 의견을 수용하는 경우가 있다. 하지만 고객의 니즈와 고객이 말하는 불편, 요구사항에서 차이가 발생할 수 있다. 이는 고객은 화면에 대한 설계, 개발, 전문가가 아니기 때문이다.

회의 중 개발팀 차장님이 "고객이 원하니 요청한 대로 만들자"고 한 적이 있다. 별 것도 아닌 간단한 화면이었지만. 하지만 나는 반대했다. 고객은 자신의 불편함(Problem)은 명확히 인지하지만, 그것을 해결할 최적의 대안(Solution)까지 설계할 수는 없기 때문이다. 요구사항을 그대로 '직역'해서 화면에 넣으면 시스템의 일관성은 깨지고, 장기적으로는 더 큰 사용성 저하를 불러온다.

나는 문제의 본질을 해결하는 'B안'을 제시하며 설득했다. 고객이 말하는 해결책은 불편함의 '현상'일 뿐이며, 그 뒤의 맥락을 읽어내어 최선의 구조를 설계하는 것이 디자이너의 전문성이다. 의사를 찾아온 환자가 자신의 통증을 설명할 뿐 스스로 처방을 내리지 않듯, UI/UX 디자인 역시 고객의 목소리를 해석하여 최적의 경험을 '처방'하는 전문가의 영역이다.

Case 07. 요즘 채용 시장과 실무에 대한 단상

최근의 채용 공고를 보면 UI/UX 디자이너에게 QA나 퍼블리싱 능력까지 요구하는 경우가 많다. 공급 과잉의 시대라 그런 조건에도 수백 명씩 지원자가 몰린다. 누군가는 이를 보고 전문성이 떨어진다고 우려하지만, 나는 모든 IT 프로세스를 이해한다는 마음으로 접근하면 실무가 훨씬 수월해진다고 생각한다. 일종의 자기 합리화일 수도 있겠지만, 실제로 전체 맥락을 아는 디자이너의 경쟁력은 분명 다르다. (하지만 가능한한 큰 회사 가는게 좋다고 생각한다.)

면접에서 "비즈니스 해결 방법을 제시해달라"는 요구를 받기도 했다. 포트폴리오에서 문제 해결 능력이 충분히 보이지 않을 때, 자사의 도메인을 설명해주며 BM(비즈니스 모델) 수립을 요구하는 식이다. BM 수립이 디자이너의 주 역할인가에 대해서는 이견이 있을 수 있으나, 이 또한 IT 프로젝트의 일부로 수용할 수 있다. 나 역시 사용자로서 '밀리의 서재 책 선물하기' 같은 비즈니스 아이디어를 구상해보곤 한다. 다만, 면접에서 즉석으로 깊이 있는 BM을 요구하는 것은 지원자 입장에서 다소 과한 요구일 수 있다.

채용 테스트가 늘어나는 것 역시 포트폴리오만으로는 실력을 온전히 판단하기 어렵고, 허위 정보가 섞인 경우도 많기 때문이라 이해한다. 하지만 채용테스트를 진행했을 때 개인적으로 나는 100%의 실력을 보여주지 못했다. 퇴근하고 기간 내에 채용 테스트를 진행한다는게 무리였다.

데이터 중심의 실무 환경에 대해서도 고민이 많다. 나는 주로 B2B 솔루션이나 직접 설치형 환경에서 근무해 사용자 데이터를 실시간 수집하기 어려운 구조였지만, GA4나 GTag 등을 공부하며 시스템을 이해하려 노력했다. A/B 테스트는 개발 인프라가 갖춰져야 가능하며 마케팅적 지표에 대한 공감이 필수적이다. 마케터와는 제품의 본질적인 기능을 유지하려는 쪽과 당장의 수익을 만드는 쪽 사이에서 갈등이 생길 수밖에 없으며, 디자이너는 그 사이에서 균형을 잡는 역할을 해야 한다.

5. 결론: UI/UX디자이너의 존재이유

지금까지 다양한 현장 사례를 통해 개인적인 주석을 붙여 보았다. 많은 디자이너가 비슷한 갈등을 겪었을 것이고, 누군가는 나의 견해를 다 이해하지 못할 수도 있다. 하지만 이 기록이 현장에서 발생하는 다양한 시각차와 고민을 이해하는 계기가 되길 바란다.

결국 UI/UX 디자이너는 극강의 커뮤니케이터다. 어디선가는 중소기업에서 디자이너 혼자 데이터 분석가 없이 GA4와 빅쿼리를 만져야 하고, 개발 인력이 부족하면 퍼블리싱까지 감당하는 디자이너가 있을 것이다. UI/UX라는 직업을 깊게 이해할 수 있는 경험이라고 이야기 해주고 싶다.

그리고 “디자인, 개발, 데이터 분석 다 하라고요? 이 질문에 대한 대답은 기술에 대해서 이해하는 것도 좋지만 기술자들과 대화를 하는 스킬을 익히는 것도 중요하다. 꼭 다 이해할 필요는 없지만 좋은 대화를 하는 방법에 대한 경험을 쌓기를 바란다.

글을 마치며, 정말이지 IT프로그램 개발 과정은 답답하고 막막하고 스트레스를 받는다. 그렇지만 내부 과정을 조율하고 비즈니스에 있는 모든 혼돈을 정리정돈하여 사용자와 만나는 인터페이스의 최종본에 책임지고 편리하게 사용할 수 있도록 변화시키며 나름의 보람을 느낄 수 있는 직업이 UI/UX디자이너라는 직업이라고 생각된다.