24년 12월, 25년 1월 회고

Keep

DX 개선

Google Analytics 이벤트 코드가 여기저기 분산되어 있어 수정할 때 여기저기 찾아다녀야 하는 불편함이 생길 것 같아 마음에 들지 않았다. 그래서 사용자 동작이 중요하지 않은 단순 데이터 수집 이벤트라면 vuex plugin을 통해 한곳에서 이벤트 전송 코드를 관리하도록 개선했다. 기능 개발도 중요하지만 DX도 고려해서 개발하는 습관을 들여야겠다.

import { trackUserCpk, trackUserId, resetUserInfo } from "@/helpers/tracking";
export default function sendUserEventPlugin(store) {
  store.subscribe((mutation, state) => {
    const {type} = mutation;
    if (type === 'auth/fetchUserSuccessful') {
      trackUserId(String(state.auth.user.id))
    }
    if(type === 'auth/setContentProviderKey') {
      trackUserCpk(state.auth.selectedContentProviderKey);
    }
    if(mutation.type === 'auth/logout') {
      resetUserInfo();
    }
  });
};

Problem

기획과 개발 구조의 불일치

프론트에서 axios interceptor를 통해 상태 코드별로 동일하게 에러 핸들링을 하고 있다. 그런데 기획에서 종종 다르게 핸들링 처리를 요청하는 경우가 있다. (422 에러라면 에러 항목 하단에 메세지를 보여주는 것이 아니라 토스트 팝업을 띄워줘도록 요청)

물론 기획에 맞춰서 개발했지만 예외 케이스가 계속 생겨서 코드가 좀 복잡해졌다. 페이지가 달라도 동일한 API의 에러 처리는 같은 UI로 보여주는 게 맞지 않나? 라는 생각이 들었었다. 왜냐면 기획 논의할 때 대체로 UI/UX 통일성을 강조하기 때문이다.

Try

개발 구조를 기획에 맞추자

위에서 얘기한 기획과 개발 구조에 대해 사수분과 얘기를 나눴고 현명한 말씀을 해주셨다. 기획을 개발에 맞추지 말고 개발을 기획에 맞춰야 한다. 기획에서 다르게 처리하도록 의도한 것이라면 그것을 따라야 하며 프로젝트 설계 구조와 기획이 맞지 않다면 구조에 대해 고민해봐야 한다고 말씀하셨다. 그동안 편협한 생각을 했던 것 같다... 기획에 따라 제품이 개발되기에 일단 기획을 따라가는 게 맞는 것 같다.

B2B 서비스를 개발할 때 마인드

현재 개발중인 서비스의 월 사용자 중 약 10%가 모바일 사용자인데 현재 서비스는 모바일을 고려하지 않았기에 모바일로 접속시 UI가 굉장히 불편하다. 그래서 모바일 서비스도 있으면 좋지 않을까 싶어 사수분과 논의했었다. 고객의 요구사항으로 들어온 건 아니지만 우리가 새로운 기능을 개발해 역으로 고객에게 제안할 수 있지 않을까? 싶었다.

사수분께서는 사업팀에서 좋아하겠지만 리소스가 많이 들어간다면 중요한 기능이 아니라 판단되어 우선순위가 많이 밀려날 수 있다고 하셨다. 실제로 전에 건의했었을 때도 리소스 부족으로 무산되었다고 한다. 

만약 고객사에서 모바일 버전 콘솔이 있으면 계약할게! 라고 한다면 그때 진행될 수도 있겠지만 현재는 어려울 거라고 하셨다. (중요도 높은 다른 업무들도 있기에...)

그래서 B2B 회사의 경우, 대형 고객사가 제일 중요하기에 새로운 기능 개발로 고객에게 제안하는 것보단 고객 요구사항 만족과 리소스 관리가 제일 중요한 것 같다.