스몰 브랜드부터 엔터프라이즈까지 많은 고객들이 이용하는 서비스 아임웹, 매월 1.3억 명 이상이 아임웹으로 만든 사이트를 방문하고 있습니다. 다양한 사용자가 서비스를 매끄럽게 이용할 수 있는 것은 화면 너머 치열하게 고민하는 프론트엔드 엔지니어들이 있기 때문이죠. 이런 아임웹의 프론트엔드 엔지니어는 고객을 위해 어떤 문제를 해결하고, 그 과정에서 어떻게 성장하고 있는지 알아보았어요!
Chapter 1. 더 나은 고객 경험을 위해 몰입하는 FE
Chapter 2. 레거시를 정면 돌파하며 함께 성장하는 FE
Chapter 3. 변화가 필요하다면 실행하고 Why를 찾는 FE
💡 세 가지 챕터를 통해 아임웹 프론트엔드 엔지니어 AD 스쿼드 종준님, Commerce BO 스쿼드 반석님, End User 스쿼드 흥준님의 이야기를 소개합니다.
Chapter 1. 더 나은 고객 경험을 위해 몰입하는 FE
“프론트엔드 엔지니어는 고객이 마주하는 서비스의 가장 앞단을 개발한다고 생각합니다. 그 과정에서 좋은 사용성을 제공하기 위해 계속해서 노력하고 있어요. 그럼에도 예상하지 못한 엣지 케이스가 발생할 때 ‘많은 사람이 사용하는 큰 서비스 맞구나’ 싶죠.”
종준 프론트엔드 엔지니어는 고객이 직접 사용하는 화면을 설계하기에 서비스의 가장 앞단을 개발한다고 생각합니다. 그만큼 고객이 불편함 없이 서비스를 사용할 수 있도록 개발 과정에서 많은 노력을 기울이고 있어요. 특히, 사용자가 불편을 느끼기 전에 먼저 에러를 발견하고 개선하려고 노력해요. 기능 배포나 업데이트 전에 항상 꼼꼼한 QA를 거치지만, 실제 서비스 환경에서는 QA에서 발견되지 않은 에러들도 종종 발생합니다. 때로는 고객의 직접적인 피드백이 있기 전까지 어떤 에러가 발생했는지 인지하지 못하는 경우도 생기죠.
이런 상황을 방지하기 위해 광고 캠페인 관리를 담당하는 AD 스쿼드에서는 에러 추적 시스템을 개선했어요. 기존에 슬랙 webhook을 error boundary와 연동해 추적했지만, 사용하면서 에러 로그 트래킹의 어려움, 퀄리티 및 제어 측면의 문제 등 여러 한계점을 발견했죠. 그래서 더욱 효율적인 sentry를 도입했습니다. 실시간으로 에러를 추적하고 알림을 보내주어 즉각적인 대응이 가능하고, 소스맵과 연동되어 어느 버전에서 에러가 발생했는지 상세하게 파악할 수 있게 되었어요. 결과적으로 크로스 브라우징 이슈뿐만 아니라 백엔드 API 에러까지 브라우저에서 잡아낼 수 있게 되어, 이슈를 신속하게 해결하고 있습니다.
sentry를 통해 에러를 추적하고 해결하고 있어요!
흥준 기능을 개선하는 과정에서 정말 많은 분들이 아임웹을 사용하고 있다는 걸 느낄 때가 많아요. 올해 초 End User 스쿼드에서는 상품 상세 페이지 이미지 최적화를 진행하면서도 느꼈죠. 기존 아임웹에서는 상세 페이지에 업로드하는 이미지를 모든 기기에서 동일한 원본으로 표시하고 있었죠. 인터넷이 느리거나 화면이 작은 모바일 환경에서는 속도도 느려지고 비효율이었기 때문에 반응형 이미지 구현을 통해 개선하고자 했어요.
FE 과제는 이미지 원본이 담긴 마크업에서 이미지 최적화 API를 활용해 브라우저 런타임에 반응형 이미지를 표시하는 것이었어요. 백엔드에서 Lambda@Edge로 on-the-fly 이미지 최적화 설계를 완성해, 프론트엔드에서 reflow를 최소화하면서 화면을 렌더링하도록 하여 작업을 마무리할 수 있었죠.
업데이트는 잘 배포되었지만 엣지 케이스가 발생했어요. 상세 페이지에서 원본 이미지를 내려받을 수 있다 보니 이미지 저장소로 활용하고 계셨던 고객사가 있던 거예요. 업데이트 후 달라진 이미지 형식을 버그라고 생각하셔서 제보해 주셨어요. 작업할 때 생각하지 못했던 케이스인데, 신기하더라고요.
추가 요청 사항은 없었지만 기존처럼 활용하실 수 있게 디자인 모드에서 반응형 이미지 사용 on/off 옵션을 추가했습니다. 보통 개발할 때, 다양한 고객 케이스를 고려하는데요. 그럼에도 이처럼 예상치 못한 엣지 케이스가 발생할 때 고객사 MAU 합계 1.3억 명 이상이 사용하는 큰 서비스라는 것이 체감되더라고요.
Chapter 2. 레거시를 정면 돌파하며 함께 성장하는 FE
“오래된 코드로 작동하는 기능을 모던하게 재구현하기 위해 더욱 파고들어 공부하고 있습니다. 어려운 과정이지만 문제를 해결했을 때 성장하고 있다는 걸 느껴요.”
흥준 레거시 코드는 오랫동안 운영해 온 서비스라면 필연적으로 발생합니다. 2016년부터 운영된 아임웹도 예외는 아니죠. 그렇기에 현재 FE가 마주한 과제는 과거에 만들어진 코드와 모던 스택을 융합해서 프로덕트를 설계하는 것입니다. 특히, 오래된 코드로 돌아가는 기능을 React로 재구현할 때, 어떻게 접근해야 하는지 고민하다 보면 굉장히 깊은 부분까지 파고들게 돼요. 과거 개발자가 어떤 지식을 바탕으로 왜 이렇게 설계했는지 파악하고, 이 내용을 바탕으로 어떤 방향으로 코드를 다시 모던하게 짤 수 있을지 고민하는 과정에서 더 공부하고 연구하게 되더라고요.
말로 설명하기에도 쉽지 않은 과정이고, 아직 해결해야 할 코드가 많지만 이런 과정을 거쳐 문제를 해결할 때 성장하고 있다는 걸 느껴요. 누구는 레거시 해결이 지루한 업무라고 생각할 수 있지만, 성장하는 개발자라면 레거시도 다룰 줄 알아야 한다고 생각합니다. 레거시 코드 처리와 새로운 기술 적용 사이의 균형을 잡는 데 도움이 될 뿐 아니라 이를 통해 더 나은 사용자 경험을 제공할 수 있기 때문입니다.
종준 저 역시 레거시 코드를 다루면서 과거의 코드를 이해하는 데 어려움을 겪었기 때문에, 새로 작성하는 코드는 더욱 간결하고 유지보수성이 높은 방식으로 개발하려고 합니다. 단순히 동작에만 집중하기보다는 코드의 퀄리티, 즉 클린 코드를 지향하는 것이 개발자의 중요한 덕목이라고 생각해요.
아임웹 디자인 시스템 'Clay'에 기여하면서 많은 인사이트를 얻고 있어요. 최근 Clay의 sidesheet를 만들어야 해서 기존에 controlled로 제어되고 있는 모달을 참고해 sidesheet를 controlled 방식으로 구현했어요. 이후 동료 FE와 코드 리뷰를 진행하면서 uncontrolled 컴포넌트도 고려해 보라는 제안을 받았습니다.
uncontrolled를 만든 적은 없어서 확장성에 대해 고려하지 못했는데, 이번 리뷰를 하면서 확장성 있고 유연한 컴포넌트를 만드는 것의 중요성을 깨달았어요. 기존에는 controlled 방식을 추구하며 치우친 개발을 했었다면, 이 경험을 통해 DX(developer experience)를 고려해서 유연하게 사용자가 원하는 방식을 이용하고 더 나아가 리팩토링이 용이하도록 설계하고 있습니다.
“FE 챕터 기술 세션에서도 많이 배우고 있어요. 기술적인 부분은 물론 문제를 정의하고 해결하는 과정에 대해서도 마찬가지예요.”
반석 아임웹 프론트엔드 엔지니어는 각 스쿼드에도 속해있지만 FE 챕터로도 활동해요. 챕터에서는 업무에서 얻은 인사이트를 공유하는 기술 세션을 종종 진행하고 있어요. 그중 부모창과 iframe 내부 도메인이 달라서 생기는 CORS 문제를 아키텍처로 풀어냈던 경험을 공유한 세션이 기억에 남아요. 그냥 넘길 수 있는 부분을 문제로 인식하고 기술적으로 해결하는 과정이 인상 깊었죠.
이후 불편한 부분을 그냥 넘기지 않고 근본적인 해결책을 찾으려고 노력합니다. 한 가지 예를 들자면, 특정 액션에 반응하여 현 인터페이스 위에 플로팅 되는 모달은 컴포넌트로 관리하는 것이 일반적이에요. 그러나 갈수록 같은 모달을 여러 곳에서 사용하게 됐고, 그때마다 같은 모달을 만들어야 하는 비효율이 발생했어요. 또한 컴포넌트에 의존적이다 보니 해당 컴포넌트를 임포트해주는 wrapper 컴포넌트가 필요한데요. 드롭다운 메뉴 같은 경우에는 드롭다운이 닫히면서 모달이 열리는 동작이 있어요. 그러면 wrapper 컴포넌트인 드롭다운 컴포넌트가 사라진 상태라서 더 상위의 컴포넌트에서 모달을 임포트해야하는 문제가 있었습니다.
이런 문제과 비효율을 개선하기 위해 모달을 기존 컴포넌트 개념에서 벗어나 라우터 기반으로 개선하면 어떨지 동료 FE에게 제안했어요. wrapper 컴포넌트 의존성 없이, 어느 곳에서든 모달을 처음부터 작업할 필요 없이 해당 페이지만 불러오도록 개선할 수 있었습니다. 기존 관성에서 벗어나 생산성을 높였던 작업이에요.
비효율을 개선했던 모달 작업
Chapter 3. 변화가 필요하다면 실행하고 why를 찾는 FE
“변화가 필요하다고 느끼면 일단 실행합니다. 실행해 본 결과를 바탕으로 설득하면 더 신뢰 있는 선택을 할 수 있거든요. 또, 항상 why를 고민해요. 일을 위한 일이 아닌, 근본적인 문제를 해결할 수 있는 가장 큰 원동력이기 때문이에요.”
종준 업무를 수행할 때 중요하게 여기는 것은 빠른 실행입니다. 아임웹의 8가지 일하는 원칙 중 빠르게 실행합니다(Move with urgency)를 가장 중요하게 생각하며 일하고 있어요. 실행하지 않고 후회하기보다 실행 후 배우는 것이 더 가치 있다고 믿기 때문입니다. 변화가 필요하다 싶으면 일단 실행해요. 기술적으로도 ‘무엇을 바꾸면 좋을까’ 고민하는 대신, 먼저 변화를 시도해 보고 결과물을 바탕으로 다른 사람들을 설득해요. 그러면 더 신뢰 있는 의사결정이 가능해집니다.
흥준 저 역시 빠른 실행을 최우선으로 삼고 있어요. 문제를 가장 신속하게 발견할 수 있는 방법은 실행이기 때문인데요. 실행한 후 문제를 발견한다면 why를 고민하며 해결해 나가고 있습니다.
반석 빠른 실행과 더불어 일을 하는 목적과 이유를 찾는 것 또한 중요하다고 생각해서 원칙 중에서는 ‘why’를 생각합니다(Always think ‘why’)를 중심으로 일합니다. 단순히 일을 위한 일이 아니라, 근본적인 문제를 해결할 수 있는 원동력이 되기 때문이에요. 아임웹에서는 고객 사용성 인터뷰 내용을 모든 구성원이 볼 수 있는데요. 덕분에 고객과 직접 소통할 기회가 적은 개발자도 고객의 니즈를 직접 확인할 수 있고, 왜 이 일을 해야 하는지 근본적인 이유를 찾는 데 많은 도움을 받고 있어요.
OMS(Order Management System)를 개발할 때도 마찬가지였어요. Commerce BO 스쿼드에서는 최근 새로운 주문 관리 시스템을 오픈했어요. 당시 모바일 접속자가 아주 적지는 않았으나, 주문 관리처럼 복잡한 처리는 PC에서 진행할 것으로 예상했습니다. 그러나 고객 인터뷰를 통해 실제로 복잡한 액션도 모바일을 통해 관리하는 유저도 많다는 것을 알게 되었죠. 이후 주문 목록을 모바일 환경까지 고려해 개선했고, 모바일 적용 범위를 확장하고 있어요.
무작정 모바일 환경까지 고려해야 한다고 했으면 설득이 어려웠을 거예요. 그러나 ‘왜 해야 하는지’ 이유를 찾았기에 더 효과적으로 서비스를 개선할 수 있었죠. 이런 why를 찾을 수 있는 업무 환경이 더욱 업무에 몰입하는 데 큰 도움이 되고 있습니다.
이처럼 아임웹 프론트엔드 엔지니어들은 최적의 서비스 경험을 제공하기 위해 끊임없이 고민하고 있습니다. 레거시와 모던 스택 사이에서 밸런스를 맞추며, 근본적인 문제 해결 방안을 찾아 실행에 옮기고 있죠. 어제의 시도를 오늘의 성공으로 만드는 아임웹의 프론트엔드 엔지니어의 여정이 더욱 궁금하다면, 지금 아임웹과 함께하세요!
💡 함께 보면 좋을 아임웹 콘텐츠
by communications 승아
imweb Corp.
Imweb Corp.
스몰 브랜드부터 엔터프라이즈까지 많은 고객들이 이용하는 서비스 아임웹, 매월 1.3억 명 이상이 아임웹으로 만든 사이트를 방문하고 있습니다. 다양한 사용자가 서비스를 매끄럽게 이용할 수 있는 것은 화면 너머 치열하게 고민하는 프론트엔드 엔지니어들이 있기 때문이죠. 이런 아임웹의 프론트엔드 엔지니어는 고객을 위해 어떤 문제를 해결하고, 그 과정에서 어떻게 성장하고 있는지 알아보았어요!
💡 세 가지 챕터를 통해 아임웹 프론트엔드 엔지니어 AD 스쿼드 종준님, Commerce BO 스쿼드 반석님, End User 스쿼드 흥준님의 이야기를 소개합니다.
Chapter 1. 더 나은 고객 경험을 위해 몰입하는 FE
“프론트엔드 엔지니어는 고객이 마주하는 서비스의 가장 앞단을 개발한다고 생각합니다. 그 과정에서 좋은 사용성을 제공하기 위해 계속해서 노력하고 있어요. 그럼에도 예상하지 못한 엣지 케이스가 발생할 때 ‘많은 사람이 사용하는 큰 서비스 맞구나’ 싶죠.”
종준 프론트엔드 엔지니어는 고객이 직접 사용하는 화면을 설계하기에 서비스의 가장 앞단을 개발한다고 생각합니다. 그만큼 고객이 불편함 없이 서비스를 사용할 수 있도록 개발 과정에서 많은 노력을 기울이고 있어요. 특히, 사용자가 불편을 느끼기 전에 먼저 에러를 발견하고 개선하려고 노력해요. 기능 배포나 업데이트 전에 항상 꼼꼼한 QA를 거치지만, 실제 서비스 환경에서는 QA에서 발견되지 않은 에러들도 종종 발생합니다. 때로는 고객의 직접적인 피드백이 있기 전까지 어떤 에러가 발생했는지 인지하지 못하는 경우도 생기죠.
이런 상황을 방지하기 위해 광고 캠페인 관리를 담당하는 AD 스쿼드에서는 에러 추적 시스템을 개선했어요. 기존에 슬랙 webhook을 error boundary와 연동해 추적했지만, 사용하면서 에러 로그 트래킹의 어려움, 퀄리티 및 제어 측면의 문제 등 여러 한계점을 발견했죠. 그래서 더욱 효율적인 sentry를 도입했습니다. 실시간으로 에러를 추적하고 알림을 보내주어 즉각적인 대응이 가능하고, 소스맵과 연동되어 어느 버전에서 에러가 발생했는지 상세하게 파악할 수 있게 되었어요. 결과적으로 크로스 브라우징 이슈뿐만 아니라 백엔드 API 에러까지 브라우저에서 잡아낼 수 있게 되어, 이슈를 신속하게 해결하고 있습니다.
흥준 기능을 개선하는 과정에서 정말 많은 분들이 아임웹을 사용하고 있다는 걸 느낄 때가 많아요. 올해 초 End User 스쿼드에서는 상품 상세 페이지 이미지 최적화를 진행하면서도 느꼈죠. 기존 아임웹에서는 상세 페이지에 업로드하는 이미지를 모든 기기에서 동일한 원본으로 표시하고 있었죠. 인터넷이 느리거나 화면이 작은 모바일 환경에서는 속도도 느려지고 비효율이었기 때문에 반응형 이미지 구현을 통해 개선하고자 했어요.
FE 과제는 이미지 원본이 담긴 마크업에서 이미지 최적화 API를 활용해 브라우저 런타임에 반응형 이미지를 표시하는 것이었어요. 백엔드에서 Lambda@Edge로 on-the-fly 이미지 최적화 설계를 완성해, 프론트엔드에서 reflow를 최소화하면서 화면을 렌더링하도록 하여 작업을 마무리할 수 있었죠.
업데이트는 잘 배포되었지만 엣지 케이스가 발생했어요. 상세 페이지에서 원본 이미지를 내려받을 수 있다 보니 이미지 저장소로 활용하고 계셨던 고객사가 있던 거예요. 업데이트 후 달라진 이미지 형식을 버그라고 생각하셔서 제보해 주셨어요. 작업할 때 생각하지 못했던 케이스인데, 신기하더라고요.
추가 요청 사항은 없었지만 기존처럼 활용하실 수 있게 디자인 모드에서 반응형 이미지 사용 on/off 옵션을 추가했습니다. 보통 개발할 때, 다양한 고객 케이스를 고려하는데요. 그럼에도 이처럼 예상치 못한 엣지 케이스가 발생할 때 고객사 MAU 합계 1.3억 명 이상이 사용하는 큰 서비스라는 것이 체감되더라고요.
Chapter 2. 레거시를 정면 돌파하며 함께 성장하는 FE
“오래된 코드로 작동하는 기능을 모던하게 재구현하기 위해 더욱 파고들어 공부하고 있습니다. 어려운 과정이지만 문제를 해결했을 때 성장하고 있다는 걸 느껴요.”
흥준 레거시 코드는 오랫동안 운영해 온 서비스라면 필연적으로 발생합니다. 2016년부터 운영된 아임웹도 예외는 아니죠. 그렇기에 현재 FE가 마주한 과제는 과거에 만들어진 코드와 모던 스택을 융합해서 프로덕트를 설계하는 것입니다. 특히, 오래된 코드로 돌아가는 기능을 React로 재구현할 때, 어떻게 접근해야 하는지 고민하다 보면 굉장히 깊은 부분까지 파고들게 돼요. 과거 개발자가 어떤 지식을 바탕으로 왜 이렇게 설계했는지 파악하고, 이 내용을 바탕으로 어떤 방향으로 코드를 다시 모던하게 짤 수 있을지 고민하는 과정에서 더 공부하고 연구하게 되더라고요.
말로 설명하기에도 쉽지 않은 과정이고, 아직 해결해야 할 코드가 많지만 이런 과정을 거쳐 문제를 해결할 때 성장하고 있다는 걸 느껴요. 누구는 레거시 해결이 지루한 업무라고 생각할 수 있지만, 성장하는 개발자라면 레거시도 다룰 줄 알아야 한다고 생각합니다. 레거시 코드 처리와 새로운 기술 적용 사이의 균형을 잡는 데 도움이 될 뿐 아니라 이를 통해 더 나은 사용자 경험을 제공할 수 있기 때문입니다.
종준 저 역시 레거시 코드를 다루면서 과거의 코드를 이해하는 데 어려움을 겪었기 때문에, 새로 작성하는 코드는 더욱 간결하고 유지보수성이 높은 방식으로 개발하려고 합니다. 단순히 동작에만 집중하기보다는 코드의 퀄리티, 즉 클린 코드를 지향하는 것이 개발자의 중요한 덕목이라고 생각해요.
아임웹 디자인 시스템 'Clay'에 기여하면서 많은 인사이트를 얻고 있어요. 최근 Clay의 sidesheet를 만들어야 해서 기존에 controlled로 제어되고 있는 모달을 참고해 sidesheet를 controlled 방식으로 구현했어요. 이후 동료 FE와 코드 리뷰를 진행하면서 uncontrolled 컴포넌트도 고려해 보라는 제안을 받았습니다.
uncontrolled를 만든 적은 없어서 확장성에 대해 고려하지 못했는데, 이번 리뷰를 하면서 확장성 있고 유연한 컴포넌트를 만드는 것의 중요성을 깨달았어요. 기존에는 controlled 방식을 추구하며 치우친 개발을 했었다면, 이 경험을 통해 DX(developer experience)를 고려해서 유연하게 사용자가 원하는 방식을 이용하고 더 나아가 리팩토링이 용이하도록 설계하고 있습니다.
“FE 챕터 기술 세션에서도 많이 배우고 있어요. 기술적인 부분은 물론 문제를 정의하고 해결하는 과정에 대해서도 마찬가지예요.”
반석 아임웹 프론트엔드 엔지니어는 각 스쿼드에도 속해있지만 FE 챕터로도 활동해요. 챕터에서는 업무에서 얻은 인사이트를 공유하는 기술 세션을 종종 진행하고 있어요. 그중 부모창과 iframe 내부 도메인이 달라서 생기는 CORS 문제를 아키텍처로 풀어냈던 경험을 공유한 세션이 기억에 남아요. 그냥 넘길 수 있는 부분을 문제로 인식하고 기술적으로 해결하는 과정이 인상 깊었죠.
이후 불편한 부분을 그냥 넘기지 않고 근본적인 해결책을 찾으려고 노력합니다. 한 가지 예를 들자면, 특정 액션에 반응하여 현 인터페이스 위에 플로팅 되는 모달은 컴포넌트로 관리하는 것이 일반적이에요. 그러나 갈수록 같은 모달을 여러 곳에서 사용하게 됐고, 그때마다 같은 모달을 만들어야 하는 비효율이 발생했어요. 또한 컴포넌트에 의존적이다 보니 해당 컴포넌트를 임포트해주는 wrapper 컴포넌트가 필요한데요. 드롭다운 메뉴 같은 경우에는 드롭다운이 닫히면서 모달이 열리는 동작이 있어요. 그러면 wrapper 컴포넌트인 드롭다운 컴포넌트가 사라진 상태라서 더 상위의 컴포넌트에서 모달을 임포트해야하는 문제가 있었습니다.
이런 문제과 비효율을 개선하기 위해 모달을 기존 컴포넌트 개념에서 벗어나 라우터 기반으로 개선하면 어떨지 동료 FE에게 제안했어요. wrapper 컴포넌트 의존성 없이, 어느 곳에서든 모달을 처음부터 작업할 필요 없이 해당 페이지만 불러오도록 개선할 수 있었습니다. 기존 관성에서 벗어나 생산성을 높였던 작업이에요.
Chapter 3. 변화가 필요하다면 실행하고 why를 찾는 FE
“변화가 필요하다고 느끼면 일단 실행합니다. 실행해 본 결과를 바탕으로 설득하면 더 신뢰 있는 선택을 할 수 있거든요. 또, 항상 why를 고민해요. 일을 위한 일이 아닌, 근본적인 문제를 해결할 수 있는 가장 큰 원동력이기 때문이에요.”
종준 업무를 수행할 때 중요하게 여기는 것은 빠른 실행입니다. 아임웹의 8가지 일하는 원칙 중 빠르게 실행합니다(Move with urgency)를 가장 중요하게 생각하며 일하고 있어요. 실행하지 않고 후회하기보다 실행 후 배우는 것이 더 가치 있다고 믿기 때문입니다. 변화가 필요하다 싶으면 일단 실행해요. 기술적으로도 ‘무엇을 바꾸면 좋을까’ 고민하는 대신, 먼저 변화를 시도해 보고 결과물을 바탕으로 다른 사람들을 설득해요. 그러면 더 신뢰 있는 의사결정이 가능해집니다.
흥준 저 역시 빠른 실행을 최우선으로 삼고 있어요. 문제를 가장 신속하게 발견할 수 있는 방법은 실행이기 때문인데요. 실행한 후 문제를 발견한다면 why를 고민하며 해결해 나가고 있습니다.
반석 빠른 실행과 더불어 일을 하는 목적과 이유를 찾는 것 또한 중요하다고 생각해서 원칙 중에서는 ‘why’를 생각합니다(Always think ‘why’)를 중심으로 일합니다. 단순히 일을 위한 일이 아니라, 근본적인 문제를 해결할 수 있는 원동력이 되기 때문이에요. 아임웹에서는 고객 사용성 인터뷰 내용을 모든 구성원이 볼 수 있는데요. 덕분에 고객과 직접 소통할 기회가 적은 개발자도 고객의 니즈를 직접 확인할 수 있고, 왜 이 일을 해야 하는지 근본적인 이유를 찾는 데 많은 도움을 받고 있어요.
OMS(Order Management System)를 개발할 때도 마찬가지였어요. Commerce BO 스쿼드에서는 최근 새로운 주문 관리 시스템을 오픈했어요. 당시 모바일 접속자가 아주 적지는 않았으나, 주문 관리처럼 복잡한 처리는 PC에서 진행할 것으로 예상했습니다. 그러나 고객 인터뷰를 통해 실제로 복잡한 액션도 모바일을 통해 관리하는 유저도 많다는 것을 알게 되었죠. 이후 주문 목록을 모바일 환경까지 고려해 개선했고, 모바일 적용 범위를 확장하고 있어요.
무작정 모바일 환경까지 고려해야 한다고 했으면 설득이 어려웠을 거예요. 그러나 ‘왜 해야 하는지’ 이유를 찾았기에 더 효과적으로 서비스를 개선할 수 있었죠. 이런 why를 찾을 수 있는 업무 환경이 더욱 업무에 몰입하는 데 큰 도움이 되고 있습니다.
이처럼 아임웹 프론트엔드 엔지니어들은 최적의 서비스 경험을 제공하기 위해 끊임없이 고민하고 있습니다. 레거시와 모던 스택 사이에서 밸런스를 맞추며, 근본적인 문제 해결 방안을 찾아 실행에 옮기고 있죠. 어제의 시도를 오늘의 성공으로 만드는 아임웹의 프론트엔드 엔지니어의 여정이 더욱 궁금하다면, 지금 아임웹과 함께하세요!
💡 함께 보면 좋을 아임웹 콘텐츠
아임웹 프론트엔드 엔지니어로 합류하기
아임웹 지원하기
by communications 승아