인프런 커뮤니티 질문&답변

mnp1031님 안녕하세요!

로그 설계 잘 진행해주셨네요! view 관련해서 이 부분 아시면 좋을 것 같아 작성해보면..

• view_main에서 trigger view라고 해주셨는데, 현재의 view에선 이렇게 작성해주셔 될 것 같아요

  • 만약 배너 광고나 우리가 마우스 스크롤을 하면서 특정 요소를 본다면(음식점 리스트가 나오는 화면에서 내려가면서 보는 경우) 여기선 view보단 impression이라는 용어를 사용하곤 합니다. 노출이라고 하는데, 이것에 대해 구체적으로 정의하는게 필요해요(이 문제에선 impression이 아닌 view입니다. 이 부분은 참고차 추가 설명드리는 부분!)

  • 예를 들어 스크롤을 내리면서 보는 경우엔 카테고리나 특정 요소가 몇% 보일 때 이벤트를 발생시킬 것인가? (이 %에 따라 이벤트 로그의 발생 수가 달라지고, 로그가 많아지면 비용이 많아지고 계속 서버에 전송해야 하니 성능의 이슈가 존재하게 됩니다)

  • 배너 광고 같이 옆으로 넘기는 경우엔(유저가 넘길수도 있지만, 자동으로 넘어가는 경우도 존재하지요) 목적에 따라 로그를 구체적으로 정의하기도 합니다. 자동으로 넘어가서 노출이 된 것인지 혹은 사용자가 직접 우측 스크롤을 했는지 등! 이 부분은 정답이 있는 것이 아니라 회의를 하면서 조율했던 경험이 있네요

질문 1. 저는 카테고리 열과 행(위치)이 유저들의 클릭 이벤트 수에 영향을 준다고 생각했는데 제 가설이 맞을까요? 아니면 다른 방법 추천해주시면 감사하겠습니다!

• 카테고리의 위치가 꽤 중요합니다. 그래서 제일 효과가 좋은 곳을 차지하고 싶어하는 여러 사업부의 니즈가 존재하곤 합니다. 회사에선 실제로 얼마나 영향이 있는지 파악해야 하는 경우도 존재하지요

• 그래서 할 수 있는 것이 위치를 바꿔가면서 영향이 얼마나 되는지 비교하는 방법을 쓰곤 합니다. 유저가 보기에 매우 많이 바뀌는 것이 애매할 수 있어 신규 유저 대상으로 한다거나 전체 중 10% 에게 실험한다거나 하곤 합니다

• 이 때 로그 설계를 작성해주신 것처럼 row, column으로 해도 괜찮고 또는 서버에서 특정 상황을 내려주고, 그 값을 기록할 수도 있습니다.

  • 예를 들어 서버에서 default-category-setting-240701이라고 내려줄 수도 있지요. 이 설정에 대한 내용이 문서에 기록되어 있다면, 어떻게 되었는지 알 수 있게 될거에요. 그리고 설정이 바뀌면 category-setting-240708 이렇게 기록해서 클라이언트에 내려주고, 클라이언트에선 그 값을 기입하면 됩니다

  • 왜 클라이언트가 아니라 서버에서 하나요? 라고 물어보시면 클라이언트 배포는 앱의 심사를 거쳐서 해야해서, 실험 같은 것을 할 때 유연하게 접근하는 것이 필요합니다. 그래서 배포가 상대적으로 유연한 서버에서 처리하고 클라이언트에선 그 로직을 받아 처리만 하곤 합니다. 그래서 서버에서 순서를 정해줘서 내려주면 클라이언트에선 그대로 만들면 되는 것이지요

  • 클라이언트에서 몇번째인지 기록하는 것도 방법이지만, 핸드폰의 사이즈에 따라 몇번째가 달라지는 경우가 있다면 이 부분이 애매하다고 말씀해주실거에요. 이 부분은 서버에서 내려줘도 비슷하기 때문에, 서버에서 row column이 아니라 sequence 같이 순서대로 내려주고, 그 순서를 클라이언트에서 뿌릴 수도 있지요

    • 1 2 3

    • 4 5 6

    • 7 8 9

    • 이런식으로 말이지요

• 어떤 방법이 좋냐?라고 하면 정답은 없고 회의하면서 정하곤 했네요. 저는 위에 대부분을 경험했었어요.

• 다만 분석하는 입장에서 서버에서 내려준 값이 무엇인지를 쿼리 상에 명시해야 할 수도 있는 점이 불편할 수 있는데, 이 부분은 문서를 자동으로 파싱해서 쓰거나 UDF로 만드는 방법을 사용하곤 했습니다

질문 2. 검색어와 검색된 음식의 유사도가 어느정도냐(검색 기술 수준)에 따라서 검색 기능이 잘 동작하는 지 확인할 수 있을 것 같아서 검색 유사도라는 파라미터를 삽입했는데 옳은 판단이었을까요?!

• 2번의 경우 일단 유사도를 생각하셨던 점이 너무 잘하셨다고 말씀드리고 싶네요!! 이렇게 생각하는 과정이 참 중요하더라구요.

• 데이터의 흐름도 같이 생각해보면 좋습니다. 검색 유사도라는 것은 클라이언트 사이드에서 알기 어렵고, 클라이언트가 서버에 요청하고, 서버에서 처리한 후에 클라이언트에 내려줍니다. 그 내려준 데이터가 클라이언트의 결과에 나오는 것이지요

  • 그래서 지금 로그 설계에 따르면 서버에 요청하고 => 서버가 유사도를 내려주고 => 그 유사도를 클라이언트에서 기록하는 구조입니다

  • 그래서 클라이언트에서도 필요하지 않은 데이터를 로그를 위해 받아야 한다고 생각할 수도 있고, 서버에서도 왜 내려줘야 하는지 의문을 제기할 수도 있습니다.

  • 그리고 이런 데이터가 클라이언트로 보내진다는 것은 앱이나 웹 관점에서 중간에 가로챌 수도 있습니다. 이런 경우는 보안과 관련되어서 주제가 넓어지긴 하지만.. API response에 담긴 데이터를 확인할 방법이 있다면 이런 유사도를 확인할 수 있고 지속적으로 검색을 요청해서 서버의 유사도 모델에 대한 성능이나 데이터를 확인할 수도 있을 것 같네요(뭘 할지는 더 생각해봐야 하겠지만 이런 내용으로 리버스 엔지니어링이 가능하기에..!)

• 그래서 저라면 이런 서버에서 진행되는 로그는 서버 로그로 저장할 것 같네요

  • 요청이 들어오는 시점에, 서버 로그에서 이 요청에 대해 어떤 유저가 어떤 키워드로 검색했고, 유사도가 얼마나 되었는지 기록!

  • 만약 클라이언트 사이드에도 이런 데이터를 활용하고 싶은 경우가 존재할 수 있는데, 그런 경우라면 클라이언트와 서버에서 같이 사용할 수 있는 key를 만들어서(uuid4 등으로 만들어서) 클라이언트에서 key만 로깅할 것 같아요

질문 남겨주셔서 감사합니다! 또 궁금한 내용이 있다면 질문 남겨주셔요 🙂

안녕하세요, 인프런 AI 인턴입니다.

질문 1에 대한 답변입니다. 네, 사용자의 클릭 이벤트 수에 영향을 미칠 수 있는 중요한 요소 중 하나로 카테고리의 열과 행(위치)을 고려하는 것은 매우 현명한 접근입니다. 사용자 경험(UI/UX) 연구에서도 정보의 배치와 구조가 사용자의 행동에 큰 영향을 미친다는 것이 여러 연구를 통해 입증되었습니다. 따라서, 사용자의 클릭 행동 분석을 위해 해당 요소들을 로그에 포함시키는 것은 사용자의 선호나 행동 패턴을 이해하는 데 매우 유용할 것입니다.

질문 2에 대한 답변입니다. 검색된 음식과 검색어의 유사도를 파라미터로 삽입하는 결정은 매우 옳았습니다. 이는 검색 알고리즘의 정확성과 효율성을 평가하는 데 중요한 지표가 될 수 있으며, 최종적으로 사용자 경험의 개선에 기여할 수 있습니다. 검색 기술의 수준을 평가하고 이를 바탕으로 개선점을 찾는 것은 검색 기능을 중요하게 여기는 모든 서비스에서 필수적인 과정입니다. 따라서, 이러한 접근은 검색 기능의 성능을 좀 더 미세하게 조정하고 사용자에게 더 적합한 결과를 제공하는 데 도움이 될 것입니다.

데이터 로그 설계에 대한 성공적인 접근 방법을 취하셨습니다. 추가 조언이 필요하거나 다른 궁금증이 있으시면 언제든 문의해 주세요.