가장 많이 질문을 받았던 왜 프론트 엔드인가요?
사실 나는 프론트 엔드를 시작하게 된 이유는 명확했다.(라고 생각했다.)
1) 여러 기술스택이 나와서 계속 무언가를 배울 수 있다.
2) 내가 노력한 결과를 누군가가 알아봐 줄 수 있다.
3) 지식을 공유하고 새로운 가치를 창출 할 수 있다.
로 생각했었는데, 이 답이 충분하지 않다는 것을 알았다.
이건 왜 프론트엔드일까요 가 아닌, 왜 개발자로 전직을 하셨나요?에 더 적합한 답인것 같다.
그렇다면 백엔드니 데브옵스니 등등 많은 분야가 있는데 그중 왜 나는 프론트 엔드의 길을 걷게 되었을까?
1. 유저와의 접점
가장 재밌다고 느낀부분은 유저의 측면에서 기술적으로 어떤 경험을 제공할 수 있을까를 고민할 수 있었던 부분인것 같다.
예를들면, 화면 로딩이 느릴때 그 시간에 따라 유저의 이탈율이 높을까?
답은 당연하게도 yes다.
구글 리서치 자료에 따르면 모바일 웹 사이트의 로딩 시간이 3초 이상일때 32%, 5초 이상일때 90%, 등 로딩 시간에 따라 이탈율이 급격하게 증가한다. 특히 이 반응은 핀테크 쪽에서 더 예민하게 나타나는 것으로 알고 있다.
성능 개선
그렇다면 1) 성능을 개선하여 로딩시간을 줄이던가,
핀터레스트는 로딩 시간을 40%로 줄이면서 검색 유입률과 가입자수를 15% 늘렸고, COOK은 평균 페이지 로드 시간을 850밀리초로 줄여 세션당 페이지 조회 수를 10% 늘렸고, 이탈률은 7% 감소시켰다.
성능 개선이 어렵다면
2) 불가하다면 어떻게 이탈을 막을 것인가로 나눠볼 수 있을 것이다.
그러면 또 2)에 파생되어
2-1) 사이트가 에러난것처럼, 멈춰진 것으로 느껴짐에서 오는 이탈인지
-> 로딩이 되고 있음을 표시
2-2) 로딩이 되는지는 알지만 언제 로딩될지 모르겠고, 기다림이 힘듬에서 나오는 이탈인지
2-2-0) 심리적인 부분으로 기다림이 짧게 느껴지는 속임수 사용(데이터이외 데이터를 넣을 뼈대인 정적 요소부터 렌더링)
2-2-1) 기다림이라고 안느껴지도록 게임 등 배치
그래서,
이렇게 프론트는 더 나은 사용자 경험을 어떻게 개선할 수 있을 것인가 대한 고민에 관련된 여러 가상의 해결법들을 실제로 실현시켜줄 엔지니어라고 할 수 있을 것 같다. 이로 인해 가입률/전환율을 높이고 이탈률은 낮추어 더 많은 수익 창출에 영향을 미칠 수 있다.
유저가 있어야 프로덕트가 존재할 수 있다.
많은 경쟁 프로덕트들 사이에서 어떻게 우리의 프로덕트/브랜드를 유저에게 각인 시킬 수 있을까, 편의성을 제공해 줄 수 있을까를 기술적으로 고민할 수 있는 분야였기 때문에, 다른 분야보다는 프론트를 더 흥미롭다고 느낀 것 같다.
그리고 번외로,
유저에게 접하는 위치이기 때문에, 항상 변동의 가능성이 있기 때문에 확장성, 또는 유지보수가 강조가 되는 것 같다. 검증->보수/확장->검증->보수/확장->..이랄까?
2. 기술중심과 인간중심의 역할의 브릿지
기술 중심의 분야와 인간 중심의 분야의 브릿지로 일명 통역가라고 생각한다. 하나의 목표로 함께 나아가지만 각각의 역할마다 주어지는 롤과 상황 그리고 각 분야에 대한 이해도가 다르며 이로인해 갈등이 빚어지기도 한다.
예를들면 모두 회사의 더 큰 성공을 바라며 마케팅 부서는 데이터를 봤을때 이건 무조건 성공이다!라고 생각하며 몇 십억 예산을 받으려 할때, 재무 부서는 이게 성공가능하다고 생각되어지는 근거가 무엇인지, 타당한지 검증하며 예산 편성에 no를 외칠 수도 있다.
칼이 있으면 방패가 있듯이, 누군가는 공격적으로 전략을 짤때 누군가는 방어적으로 그 전략의 뒷정리를 해준다. 닭과 달걀처럼 부서들은 모두 유기적으로 연결되고 부서특성상 상하위가 있는 것 처럼 보이나 실은 모두 하나의 목표를 향해 달려가는 같은 레벨의 팀일뿐이다.라고 믿는 편이다.
그래서 이런 이해관계가 다르며 빚어지는 갈등을 중재하는 역할을 꽤나 자처하는 편이다.
bm일때
예전에 BM으로 일을하며 중간다리 역할을 많이 했다.
예를 들면, 다른부서에서 이벤트 관련하여 푸시가 내려오는 상황이었는데 이는 디자인팀에 업무가 가야되는 상황이었다. 그때 이미 스케줄이 밀려있던 상황으로 푸시된 오더를 실행할 수가 없었다.
이에 푸시가 현시점에서 합당한지, 어떤부분에서 어느정도로 합당한지 이로인한 기회비용은 무엇인지에 대한 검증 후, 그렇다면 이중 어느부분까지는 실행가능한지 그리고 해당 부분이 실행되면 다른 어떤부분을 잘라야하는지 정리하였다. 이후 정리와 함께 디자인팀에 왜, 무엇을 어떻게에 대해 설명하면서 디자인팀도 납득하며 기꺼이 오케이를 외치며 스케줄을 간신히 맞춘 경험이 있다.
파이널 프로젝트에서
또, 팀프로젝트 진행시 팀원끼리 생각하는 것도 다르고, 프로덕트에 대한 이해도 다르면서 소통이 어려웠던 적이 있다. 하지만 그 말을 카테고리마다 쪼갤 수 있도록,
왜? 무엇을? 어떻게를 각각에게 물어보면 실제로 그들이 어떤 주장을 하는지, 어떤 근거로, 그리고 왜 그 말을 하는지에 대해 좀 더 명확하게 다가갈 수 있다. 그렇게 이해한 바를 토대로 다른이에게 조금 더 풀어서, 범용적인 설명으로 다가가면 그렇게 큰 갈등이 빚어지진 않는것 같다.
한번은 프론트랑 백이랑 소통이 어려웠던 적이 있었는데, 프론트에서 말이 왔다갔다해서 백에서는 그거 기반으로 설계가 바뀌어야되니까 정확하게 말하기를 원했다. 프론트끼리 말이 다른부분을 위와 같이 무엇을, 어떻게, 왜를 정리해보니, 한분은 mvp 이후 추가 확장부분에 대해 이야기하고 있었고, 한분은 현재 mvp 기준으로 이야기를 하고 있었다. 이에 백엔드에 정리해서 초반은 이렇게, 이후 이렇게 될거같다고 전달 하면서 서로간의 오해없이 잘 마무리 되었다.
그래서,
이렇게 서로 이해관계에 따라, 또는 사람마다 이해도에 따라 소통이 어려울때 사이에서 소통을 도와 결과적으로 성과가 잘 나오니 보람도 있더라.
이런 성향이 기술관점인 분야 (백엔드라던지..)와 사람관점인 분야(기획/ux디자인이라던지 ..)사이에서 브릿지 역할을 해주는 프론트 엔드에 더 잘 맞는다고 생각이 들었다.
그리고 나머지는
위에 말했던 것 처럼, 지속적으로 공부를 할 수 있는 환경이라던가, 내 노력을 누군가는 알아봐 줄 수 있는것(반대로 노력을 안하는것 또한 알 수 있다.) 등등 자기 성장과 관련된 이야기들이다.
아직 공부한지 아주 오랜시간이 되진않았지만, 잘 시작한것 같다.
일단 아직은 재밌고 & 재밌고 & 재밌고~
