엔지니어 소울
안녕하세요 멘토님! 스타트업에서 프론트엔드 개발자로 일하고 있는 4년 차 직장인입니다. 멘토님 책에서 이런저런 공감이 저도 많이 돼서 고민을 털어놓고 싶은 맘에 글을 남깁니다.
저희 팀은 서비스 개선 프로젝트를 진행하면서 UXer, 기획자와 협업하고 있어요. 개발을 하다 보면 자연스럽게 사용자 입장에서 불편하거나 헷갈릴 부분이 보여서 저 역시 의견을 내곤 합니다. 예를 들어, 한 번은 로그인 플로우에서 사용자가 어떤 상황에선 오류 메시지를 이해 못 할 것 같아서 ‘이런 문구가 더 직관적이지 않을까요?’라고 제안했는데요… 돌아오는 답변은 “그건 우리가 고민할 테니까 개발에만 집중해 주세요”였습니다.
사실 개발자는 사용자와 가장 가까운 위치에서 실질적인 사용 시나리오를 테스트하게 되잖아요. 그러다 보니 진짜 사용자의 행동 패턴이 보이기도 하고, 이런 경험을 공유하고 싶은 건데… 매번 ‘너는 개발자니까 개발만 해’라는 분위기가 깔려 있어서 점점 의견 내기도 조심스러워지더라고요.
이런 상황에서 개발자도 사용자 경험에 목소리를 낼 수 있으려면 어떻게 접근해야 할까요? 유관부서와 원활하게 협업하셨던 멘토님의 노하우가 궁금합니다! 답변 기다리겠습니다.
➥ 세상은 매일 새롭게 움직입니다. 그 중심에는 언제나 개발자가 있습니다. 눈에 보이지 않는 수많은 코드와 알고리즘이 세상의 질서를 만들고, 그것을 가능하게 하는 이들이 바로 개발자입니다. 복잡한 시스템을 설계하고, 보이지 않는 오류를 찾아내며, 누구도 의식하지 못한 순간에도 묵묵히 안정적인 서비스를 지켜내는 사람들. 개발자의 논리와 이성은 단단한 토대가 되어 기술을 움직이고, 세상을 앞으로 나아가게 합니다. 그래서 우리는 늘 개발자를 ‘보이지 않는 구조의 건축가’라고도 부릅니다. 이런 이들이 왜 UXer가 되면 안 되죠?
사실 이것은 커뮤니케이션 스킬의 문제고, 글에서만 느껴지는 풍경은 UX 담당자분의 방어 기제가 문제 같기도 합니다. 때문에 답변은 어떻게 하면 같은 말도 좀 더 유하게 전달될까에 초점이 맞춰지는 게 맞겠지만, 여기서는 개발자로서 UXer가 된다는 것에 대한 이야기로 훨씬 심화해서 작성을 해보도록 하겠습니다.
사람이 가까이 가면 자동문은 열린다. 이건 너무나 당연한 이야기입니다. 하지만 가끔 문 앞에 섰는데 문이 열리지 않을 때가 있습니다. "왜지? 고장 났나? 내가 사람처럼 안 보였나?" 여기서 더 나아가,
센서는 뭘 기준으로 사람을 인식하지?
보이지 않는 모든 연결고리를 가만히 두고 보지 못하는 훈련을 받은 이들이 있으니, 이들이 바로 개발자입니다. 개발자는 사실 이런 질문과 호기심을 멈추지 않는 사람들입니다. 논리의 빈틈을 허용하지 않고, A에서 B로 가는 과정이 선형적이며 일관되기를 바랍니다.
이유는 간단합니다. 논리적 완성도가 개발자의 생존과 직결되기 때문입니다. 코드 한 줄의 오류가 전체 시스템을 무너뜨릴 수 있고, 알고리즘의 논리적 비약은 사용자에게 예기치 않은 버그를 안겨주기 때문입니다. 그래서 개발자는 철저하게 논리적입니다. 코드를 하나씩 쌓아 올리고, 무너뜨리고, 다시 세우는 과정을 통해 빈틈없는 시스템을 만들어냅니다.
그런데 이 철저한 논리적 사고는, UX를 다루는 순간 조금 다른 양상을 띠게 됩니다. UX는 논리적 완벽과는 또 다른 차원의 문제입니다. 사용자 경험은 논리의 그물망을 너무나도 쉽게 빠져나가는 생명체와도 같습니다.
아주 완벽한 프로그램이 있다고 상상해 봅시다. 시스템적으로 완벽하고, 성능은 안정적이며, 단 한 줄의 버그도 없습니다. 개발자가 설계한 논리 안에서는 어디 하나 나무랄 데 없는 작품입니다. 그러나 사용자들은 이 프로그램을 사용하다가 갑자기 멈춰 섭니다. "이거 어떻게 쓰지?" "왜 이 버튼이 여기 있어?" "여기서 뭐 해야 하지?" 이런 순간, 사용자는 논리의 흐름을 따라가 주지 않습니다. 논리가 빈틈없이 짜여 있다 해도 사용자가 한 번 길을 잃는 순간, 그 논리는 아무 의미가 없어집니다.
사용자는 합리적이지 않습니다. 그들은 본능적이고, 감정적이며, 때로는 예측 불가능하게 행동합니다. 이 모든 변수를 감안해서 시스템을 설계하는 일이 바로 UX입니다. 개발자의 논리가 A에서 B로, 그리고 B에서 C로 정확하게 이어지는 직선이라면, UX는 A에서 D로 가려는 사용자의 심리를 헤아리고, 때로는 E라는 지름길을 설계하는 일입니다.
개발자는 "이 기능은 논리적으로 이렇게 사용하는 게 맞다"라고 설명할 수 있습니다. 하지만 UX 디자이너는 묻습니다. "그렇다면 사용자는 정말 그렇게 느낄까?"
이쯤에서 흔히 드는 고민이 바로 이겁니다.
개발자(의 사고방식으로)는 UX 하면 안 되는 걸까요?
왜 안 될까요, 당연히 됩니다. 다만, 개발자의 관점과 UX 디자이너의 관점은 출발점이 다르다는 점을 인식해야 합니다. 개발자는 엔지니어 소울을 품고 있습니다. 철저하게 원인을 분석하고, 결과를 도출하는 엔지니어의 본능 말입니다. 이것은 절대 사라지지 않는 본성입니다. 오히려 개발자의 이성적 사고와 논리적 설계 능력은 UX라는 넓은 들판에서 반드시 필요한 자산이 됩니다.
하지만 UXer가 되기 위해서는 이 엔지니어 소울에 날개를 달아야 합니다. 마치 애벌레가 나비가 되듯, 기존의 사고방식을 조금은 달리해야 합니다. 논리적 사고에 감성적 직관을 더하고, 사용자의 무의식적인 행동과 감정을 읽는 훈련이 필요합니다. 이 과정은 단순히 역할을 바꾼다고 되는 일이 아닙니다. 개발자로서 체득한 것을 잠시 내려놓고, 사람을 이해하는 감각을 스스로 다시 일깨워야만 합니다.
개발자는 제품을 ‘만드는’ 사람입니다. 반면 UXer는 사용자가 그 제품을 어떻게 ‘느끼는지’를 설계하는 사람입니다. 만약 개발자가 UX를 하겠다면, 자신이 그동안 얼마나 기능과 성능에 집중해 왔는지를 인식하고, 이제는 사람을, 그리고 그들의 맥락과 감정을 중심에 두고 고민하는 사고 전환이 필요합니다.
엔지니어가 UXer가 되는 것은 가능할 뿐 아니라 멋진 일입니다. 다만, 이는 단순히 포지션을 이동하는 일이 아니라 생각의 프레임을 재구성하는 과정입니다. 엔지니어로서 논리와 정확성을 무기로 삼았다면, UXer로서의 무기는 공감과 직관입니다. 이 직관은 공부로 습득하는 것이 아니라, 사용자와의 수많은 접점에서 관찰하고 고민하며 만들어집니다.
나비가 되기 위해 애벌레는 자신의 몸을 완전히 녹여 새로운 생명체로 다시 태어납니다. 개발자가 UXer가 된다는 것은 이와 비슷한 과정입니다. 기존의 지식과 경험이 무용지물이 되는 것이 아니라, 새로운 틀에 맞게 다시 조합되고 확장되는 과정입니다. 그 변화가 쉽지는 않지만, 오히려 개발자의 논리적 기반 위에 UX 감각이 더해진다면 그 시너지는 매우 강력해집니다.
결국 개발자와 UXer는 어느 한쪽이 다른 쪽을 대체하는 존재가 아닙니다. 개발자는 제품의 논리적 완결성과 기능을 책임지는 사람이고, UXer는 사용자의 경험을 완성하는 사람입니다. 이 둘이 조화를 이룰 때 비로소 좋은 제품이 만들어집니다.
개발자는 자신의 논리가 사용자에게 어떻게 다가가는지에 대해 UXer의 의견을 경청해야 하고, UXer는 개발자가 가진 기술적 한계와 가능성을 충분히 이해해야 합니다. 이 둘은 서로 다른 영역이지만, 서로를 가장 깊이 이해해야 하는 파트너입니다. 개발자가 UX를 고민하는 것, 그리고 UXer가 개발을 이해하려고 하는 것, 이 모든 노력은 제품과 서비스의 완성도를 높이는 길이 됩니다.
개발자는 UX를 해도 됩니다. 하지만 개발자의 논리를 잠시 내려두고 사용자라는 예측 불가능한 존재를 이해하고 싶다면, 그때 비로소 UXer가 될 준비가 된 것입니다. 당신 안의 엔지니어 소울은 여전히 강력한 무기입니다. 단지 그 무기에 직관과 공감이라는 날개를 달아주면 됩니다.
어느 순간 자동문이 동작하는 순간, 문이 열리는 적절한 소리나 부드러운 타이밍 혹은 얼마나 고급스러운지 느낌 등을 예민하게 받아들이고 있다면 이미 UXer가 되어가는 겁니다. 사용자의 관점으로 세상을 다시 보기 시작했으니까요.
Photo by Martin Jernberg on Unsplash