24.10.06~24.10.13

업무 공유

통계 조회 기능 개발

실행한 가이드의 통계를 보고 싶다는 요구사항이 생겼다.

이전 기업과의 POC 과정에서 로그 수집 기능을 추가한 덕에, 로그 데이터 자체는 이미 존재하는 상황.

따라서 관리자 페이지에서 수집된 로그를 보여주기만 하면 되었다.

 

필요한 정보는 1) 어떤 가이드의 2) 어떤 스텝이 3) 몇 번 실행되었는지 정도.

크게 복잡한 데이터도 아니고, 이를 차트 형태로 풀어내기에는 스텝의 이름을 한눈에 알아보지 못해 오히려 불편하단 생각이 들었다.

그래서 일단 테이블 형태로 노출 수와 이탈률을 보여주자는 결론을 냈고, 이를 구현했다.

 

통계 테이블 자체는 크게 어려움이 없었다.

특정 버전에 대한 스텝 <-> 노출 수가 매핑된 데이터를 BE에서 반환하면

이를 FE에서 버전 내 스텝에 연결 짓고, 노출 수 / 이탈 / 이탈률 을 계산해 화면에 띄워주면 되었다.

 

역시 문제는... 기존 페이지 로직들!

layout과 서버 컴포넌트로 구성된 가이드 상세 페이지에서 Header가 등장하게 되면서

각 페이지 요소들을 다시 구성해야하나..?하는 고민이 들었다.

버젼 변경 시, 다른 페이지로 이동하면서 동일한 레이아웃이 동작해야했다.

하지만 1) 조만간 가이드 상세 페이지 UI가 변경될 예정이고 2) 버전 상세 페이지도 동일한 로직을 공유해야 하기 때문에

기존 layout, 서버 컴포넌트 전략은 그대로 유지한 채, search params에 따라 다른 children을 렌더 하는 switcher 컴포넌트를 구현해 사용하는 걸로 해결할 수 있었다.

 

회고

창업 팀의 철학

스타트업 커뮤니티 행사 이후, POC 기업이 3곳으로 늘어났다.

슬랙 커넥트를 통해 해당 기업 담당자와 실시간으로 소통하며 제품을 발전시키는 중.

 

그리고 그와 동시에 드는 고민. 어디까지 요구사항을 받아들여야 할까?

 

구현 자체는 일도 아니다.

문제는... 수많은 요구 사항을 모두 제품에 녹이다 보면, 복잡한 제품이 탄생하리라는게 불 보듯 뻔하다는 것.

하지만 그렇다고 해서 고객의 요구 사항을 무시하는 것도 말이 안 된다. 결국 정답은 사용자 만족에 있으니까.

 

그렇다면 어떻게 해야 할까?

답은 창업 팀의 철학이 무엇이냐 하는 것.

사용자에게 도움을 주는 SW 가이드는 어떤 모습이어야 할까?

물론 고객의 요구는 소중하다. 정답은 고객에게서 찾아야만 한다. 고객의 목소리를 듣고, 이를 반영해야만 한다.

하지만 이와 동시에, 창업 팀은 그들의 철학을 고객에게 제시해줘야 한다. 설득해야만 한다.

 

'당신의 이러이러한 요구사항을, 우리는 이런 방향으로 해결했습니다.'

'우리가 만든 서비스에는 이러이러한 철학이 담겨 있었습니다.'

'우리의 철학은, 이러이러한 점에서 다른 대안들보다 몇 배나 더 나은 해결책입니다.'

이런 얘기를 고객사 앞에서 당당하게 말할 수 있어야 한다.

 

만약 고객사가 공감하지 못한다면? 철학을 바꾸던지, 공감할 때까지 설득하던지.

중요한 것은... 어떤 철학을 가지고 있느냐. 이를 어떻게 정의할 수 있으며, 사람들에게 어떻게 제시할 것이냐.

 

철학이 없는 서비스는, 명확한 기준을 세울 수 없다. 

명확한 기준을 세우지 못하는 순간, 제품은 복잡해지고 팀 내부 의사결정은 어려워지며, 제품은 엉뚱한 방향으로 향하고 만다.