내가 개발자가 되고나서 기획, 디자인 리뷰에 들어가면 나 스스로에게 한 질문이다. 가서 리뷰를 듣고 있자면 내가 기획자에게 무슨 역할을 해야하는지 잘 모르겠다는 생각이 들었다. 기획자에게 개발자는 "안됩니다." 커맨드를 연타하는 얌생이가 아닐까 하는 생각도 들었다. 그에 대한 반발심 때문인지 몰라도 "네 해드릴게요."라는 말을 함부로(?) 했던 것 같다.

어느날 공통 컴포넌트가 어떻게 동작하는지 잘 모르는 상태에서 서식 컴포넌트 row 안에 버튼을 넣어줄수 있냐는 말에 그냥 알겠다고 대답했다. 왜냐하면 내가 생각해도 select input과 button은 그렇게 나란히 있어야만 할 것 같았다. 하지만 당연히 가능할 거라 생각했던 코드에는 너무 당연하게도 가능하지 않았다. 식은땀을 흘리면서 다른 곳에 영향이 가지 않도록 버튼을 넣었다. 그리고 식은땀을 흘리며 모든 페이지를 돌아다녔고 식은땀을 흘리며 팀장님에게 보고를 해야했다. 코드 리뷰때도 진땀을 흘리면서 안전하다는 것을 알려야했다. 하지만 확장성이 일도 없는 단순 그 기획을 위해서 끼워 넣은 그 버튼을 볼때마다 아쉬움이 든다. 그래서 그때부터는 "되는지 확인해보고 알려드리겠습니다."라고 더 많이 말한다.

연차가 조금 쌓인 어느날 어떤 기능에 대해서 개발자들에게 의견을 묻기 위해서 회의를 열었다. 기획자의 이야기를 듣다가 내가 아는 도메인 지식으로는 문제가 될것 같다고 생각이 들었다. 그래서 모두가 알지만 하지만 아직 말하지 않은 진실을 이야기했다.

"아... 그렇네..."

기획자는 다른 방법을 생각해보겠다고 했다.

도메인 지식은 그 회사의 구성원이 공통으로 가지고 있는 일종의 집단 무의식 같은 것이다. 프러덕트를 제작할때 본능적으로 행동하는 것들과 인식하지 못하고 그냥 지나치는 것들이 모두 포함 되어있다. 그래서 누군가 미처 생각하지 못한 것을 다른 사람은 의식적으로 짚어줄 수 있다. 그 안에서 개발자는 기술적인 부분에서 제안을 할 수 있어야 한다고 생각한다. 하지만 도메인 지식을 기반으로 기술적 조언을 하는 것은 꼭 개발자의 역할이라고 볼수 없다. 프론트엔드 엔지니어만 할 수 있는 역할도 있다.

브라우저 이벤트

이번에 제품을 만들면서 모바일 위에서 동작하는 브라우저의 이벤트를 제어 할 일이 많았다. visibilitychange 이벤트를 사용해서 사용자가 앱에 진입, 이탈 하는 순간에 그 여부를 다른 프러덕트가 알 수 있게 해야했다. 처음에 프로토타입으로 visibilitychange 이벤트를 사용해서 진입 이탈을 구현했을 때는 이 이벤트가 아주 잘 동작한다고 생각했다. 하지만 사용자가 모바일 브라우저 내에서 할 수 있는 모든 행동의 경우의 수를 생각하지 않았다.

사용자가 모바일에서 브라우저에서 할 수 있는 동작들

진입

1. 메신저 등 브라우저로 진입하기
2. 핸드폰 기본 브라우저로 진입하기
3. QR 코드로 진입하기
4. 탭으로 진입하기

이탈

1. 사용하다 전원 눌러서 끄기
2. 브라우저 앱의 뒤로가기 버튼 대신 브라우저의 뒤로가기 버튼 누르기, 안드로이드 뒤로가기 버튼 누르기
3. 밀어서 끄기
4. 밀어서 강제로 종료하기
5. 브라우저 내에서 탭으로 이동하기

이 경우의 수를 모두 생각하지 않았다. 결국 개발 내내 이 이벤트 관리가 발목을 잡았다. visibilitychange 이벤트는 99% 확률로 동작하지 않았다. 내가(인공지능이) 발견하지 못한 것일수도 있지만 결국 navigate.sendBeacon, fetch의 keep-alive 이벤트를 사용했지만 그것도 100%로 제어 할 수 없었다.(대부분 나와 같은 경험을 하는듯 하다.)

제품과 환경

제품이 동작하는 환경은 브라우저다. 모바일 브라우저는 브라우저라는 명사로 동일한 환경으로 묶을 수 없다. 크롬, 사파리, 삼성, 파이어폭스를 개별 환경이라고 봐야한다. 몇몇 브라우저는 표준 이벤트가 동작하지 않기도 한다. 다른 브라우저가 동일하게 동작하는 이벤트가 B 브라우저만 재현이 안될 수 있다.(나의 경우에는 삼성 브라우저) 네이티브 동작에 브라우저가 영향을 받을 수도 있다. 그런데 어떤 브라우저 또는 OS 마다 이벤트가 동작하는 플로우가 다르기도 한다. 엔지니어는 결국 자기 제품이 운영되는 환경을 어느정도 예측하거나 알아야하지 않을까 하는 생각이 들었다. 만약 내가 미리 예측했더라면 기획 회의 때 미리 다른 방향으로 또는 더 간단한 방법으로 가도록 조언했을 지 모른다.

프로젝트를 함께 하는 백엔드 개발자와 밥을 먹다가 문득 '이벤트를 관리하지 않는게 정답이다'라는 생각이 들어 공유했다. '역으로 이벤트 발생의 주체를 모바일 브라우저에서 다른 프러덕트로 옮겨보는 건 어떨까?' 이야기는 빠르게 진행됐다. 거의 대부분의 제품에서 클릭 이벤트는 거의 대부분 제어할 수 있다. 역으로 생각하면 브라우저는 HTTP get은 대부분의 경우 사용자가 화면에 머물러 있고 클릭 이벤트와 조합되면 성공률이 다른 이벤트에 비해서 매우 높은 편이다. 조건 제어도 매우 쉽다.

타사의 동일한 프러덕트를 리서치 했을 때도 특별히 브라우저를 제어하려는 흔적이 보이지는 않았다. 오히려 '주문'이라는 핵심 타겟만 집중해서 만들어진 흔적이 보였다. 앞으로는 제품을 만들때 제품이 동작하는 환경을 이전보다 더 많이 고려해봐야겠다. 더 좋은 제품이라는 목표에 빠르고 안전하게 도달할 수 있게 프론트엔드 개발자 입장에서 합리적인 제안을 할 수 있도록 성장 할 수 있으면 좋겠다.