현업에서 조회,수정,삭제 등 사용자의 사용 이력을 어떻게 관리하시나요?

11월 10일조회 2,850

현회사에서 조회, 수정, 삭제 등 사용자의 사용이력 관리를 위해 따로 history 테이블을 만든 후에, 조회나 수정 버튼을 누를 때 그 테이블에 사용자의 id와 화면id, 사용유형(조회, 수정, 삭제 등)을 저장할 수 있는 request를 프론트에서 보냅니다. - 테이블 예시 사용자id | 화면id | 사용유형코드 | ... ---------------------------------- 9999 | hr001 | 0 개인적으로 프론트에서 일일이 request를 보내는 것이 과연 효율적인가.. 하는 의문이 드는데요🤔 다른 회사에서는 이런 경우에 어떻게 이력을 관리하시는 지 궁금합니다!

이 질문이 도움이 되었나요?
'추천해요' 버튼을 누르면 좋은 질문이 더 많은 사람에게 노출될 수 있어요. '보충이 필요해요' 버튼을 누르면 질문자에게 질문 내용 보충을 요청하는 알림이 가요.

답변 5

인기 답변

김대현님의 프로필 사진

ㅎㅎ, 담당 백엔드 개발자의 API가 마음에 안 드시는군요? 그럴 수 있습니다. 내게는 뭔가 더 좋은 방안이 보이는데, 저 사람에게는 안 보이는 거 같고, 내 일은 아니니까 대놓고 뭐라고 하기는 좀 애매한 상황. 다른 회사에서 관리하는 방안이 다르다고 할 때, 어떻게 하실려구요? 딴데는 이렇게 저렇게 한다드라며 설득하시려는 건가요? 아니면, 아 딴 데는 내가 생각한대로 하는구나.. 라고 안심이 되기 위한 것인지요. 암튼, 질문에 답을 하자면, 저라면, 어떤 행위를 프론트엔드에서 요청했을 때, 파생되는 히스토리 관리는 백엔드에서 알아서 하겠습니다만, 님 팀의 다른 API와 현황이 어떤지 모르니 섵불리 판단하기 어려운 문제겠습니다. 해당 이슈는 백엔드파트에서 알아서 할 일이니 간섭하기는 어려운 부분이고, 정 문제가 심각하면 중재할 수 있는 팀장이나 (작은 회사라면) CTO를 통하시는 것도 방법이겠습니다. 백엔드 개발자가 질문자 님한테 리액트 클래스 컴포넌트를 아직도 쓰고 있으면 구린 거 아니냐, 딴데서는 다 함수형 컴포넌트 쓴다더라... 뭐 이런 식으로 의견을 주면 내 반응이 어떨지 생각해보시면 답이 되지 않을까 싶습니다.

진라님의 프로필 사진

진라

작성자

리액트 개발자11월 10일

전회사에서 백엔드할 때엔, 이런 로직들은 백엔드에서 처리했기 때문에 프론트엔드에서 request를 일일이 보내는 게 경우가 있는지 궁금했습니다! 그리고 다른 회사들은 이런 기능을 어떻게 개발하는 지 궁금했어요! 히스토리 테이블을 따로 안 빼고 각 테이블에 이력들을 넣어주는 경우도 있을 거라고 생각했거든요. 그리고 제가 백엔드 개발자분에게 업무지시를 받는 입장이라.. 설득시킬 위치는 전혀 못 되고, 그저 궁금했던 것 뿐입니다 ㅎㅎ 비효율적인 것 같다는 제 의견이 중간에 들어가있어서 좀 답정너처럼 보이는걸까요? ㅠㅠ 나중에 제가 제 서비스를 개발할 때, 이러한 기능이 필요해서 만들게 되면 어떤식으로 해야할지 미리 생각해보고 싶기도하구요. 계속 우물 안 개구리가 되는 것 같아서 다른 회사분들의 개발방향들도 알고 싶습니다. 댓글 달아주셔서 감사합니다 😄

인기 답변

김태경님의 프로필 사진

조회 수정 삭제 등의 히스토리 관리는 백엔드에서 관리하는게 일반적인데요. 이를 백엔드에 요청하더라도 충분히 합리적이라고 생각합니다. 애초에 프론트에서 이력 관리의 책임을 갖는다는 것부터가 이해하기 어려운데요. 사용자와의 인터렉션에서 어떤 오류가 발생할지 모르기 때문에 데이터의 히스토리는 그와 무관하게 남겨져야 한다고 생각합니다. 데이터로써의 가치도 중요하기 때문에 이를 관리하는 쪽에서 히스토리 관리도 맡아야할 것 같네요.

진라님의 프로필 사진

진라

작성자

리액트 개발자11월 16일

'사용자와의 인터렉션에서 어떤 오류가 발생할지 모르기 때문에 데이터의 히스토리는 그와 무관하게 남겨져야 한다고 생각합니다. ' 라는 말씀이 정말 와닿습니다. 댓글 감사합니다!

인기 답변

minw님의 프로필 사진

작성해주신 질문이랑 어느정도의 상상력을 더해서 답변드려봅니다 일단 그 히스토리라는게 정확하게 어떤걸 의미하는지 알아야 할것 같네요 말씀하신것처럼 정말로 어떤 테이블을 언제 어떻게 사용했고 업데이트 하였는지 히스토리를 남기려는 목적인지, 아니면 실제 사용자의 사용성이나 user journey 관점의 정보 수집이 목적인지 말이죠 그리고 제가 봤을땐 후자인것 같습니다 프론트 입장에서 백앤드가 어떤 동작을 하는지 정확하게 알수가 없습니다 반대로 백앤드에서는 프론트에서 어떠한 일들이 벌어지고 있는지 알수 없구요 동일한 동작을 두번 하는것 처럼 느끼시는것 같은데 제가보기엔 전혀 다른 의미의 동작으로 보여집니다 혹시나 정말 만약에 디비 crud의 히스토리만을 위한 추가호출이라면 백앤드 개발자가 혼나야죠 그런 히스토리 추가는 필터 등을 사용해서 저장했는지도 모르게 자동으로 남길수 있습니다

진라님의 프로필 사진

진라

작성자

리액트 개발자11월 20일

보안 관점에서 사용자들이 crud를 일으키거나 api 호출하는 인터랙션을 했을때, 그것들을 기록하여 추후 누가 이 화면에 접근하여 조회를 하고 데이터를 수정했는지 보는 목적입니다!

인기 답변

이양일님의 프로필 사진

안녕하세요! 제 생각도 백엔드에서 history 를 관리하는게 맞을것 같습니다. 이렇게 생각한 이유는 다음과 같습니다. 1. 클라이언트의 종류가 다양할 경우 각 클라이언트마다 history 관리에 필요한 요청을 신경써야 하고 실수로 누락될 가능성이 있습니다. 2. history 관리가 하나의 트랜잭션으로 묶이지 못하기 때문에 Backend 요청은 정상 처리 되었지만 history 는 남지 않는 현상이 발생할 수 있습니다. 3. history API 가 독립적으로 운영되는 것이기 때문에 Backend 에 요청을 전달하지 않더라도 History 를 남길 수 있거나 Backend 요청과 다른 History 를 남길 수 있습니다. 따라서 프론트에서 Backend 에 기능과 History 요청을 각각 보내는 것보다는 Backend 에서 History 까지 관리하는게 여러모로 장점이 많다고 봅니다. 저의 짧은 지식이 조금이나마 도움이 되시길 바라겠습니다.

진라님의 프로필 사진

진라

작성자

리액트 개발자11월 20일

명쾌한 답변 감사드립니다! 막연하게 프론트에서 history 관리는 비효율적이라고 생각했던게, 구체적으로 정리가 된 것 같습니다.

구본익님의 프로필 사진

백엔드에서 해줍니다. 굳이 프론트에서 요청을 두 번 할 이유가 없네요.. 조회 수정 삭제 까지 서버에슈 잘 이루어지면 후에 히스토리에 추가로 트랜잭션 묶습니다

진라님의 프로필 사진

진라

작성자

리액트 개발자11월 16일

저도 요청을 두 번 할 이유가 없다고 생각합니다 ㅠㅠ 서버에서 잘 이루어지면 트랜잭션 묶는 게 좋은 방법 같아요! 댓글 감사합니다~!

지금 가입하면 모든 질문의 답변을 볼 수 있어요!

현직 개발자들의 명쾌한 답변을 얻을 수 있어요.

또는

이미 회원이신가요?

비슷한 질문 1

Q. 목록 CRUD API를 어떻게 짜야할지 고민입니다.

유저와 1:N 관계인 테이블의 레코드 목록을 생성하고 수정하는 API를 개발하려 합니다. 커리어리의 "관심 분야 설정" 기능을 예로 들어보겠습니다. 다음 두 가지 방법을 생각중입니다. 1. 개별 CRUD: RESTful한 방법이라고 생각이 들고, 구현도 어렵지 않습니다. 다만 많은 업데이트가 있을 때 그만큼의 요청을 서버로 날려야 합니다. (ex: 관심 분야를 BE, FE, AI 에서 UI, 마케팅, 기획으로 바꾸려면 최소 PUT request를 3번 날려야 합니다. 초기 설정 시에도 POST request가 3번 날아갑니다.) 2. POST나 PUT으로 리스트를 제공하면 서버에서 덮어쓰기: 단일 endpoint, 단일 request로 생성, 수정, 삭제가 가능합니다. 다만 서버에서 DB 변경 시 덮어쓰기 방법이 고민됩니다. 가장 간단한 방법은 유저 ID가 FK로 걸려 있는 모든 레코드 삭제 후 리스트에 있는 레코드를 전부 추가하는 방법일텐데, 이런 SQL 로직을 써도 될지 잘 모르겠습니다. 어떤 방법으로 API를 개발하는 게 좋을까요? 혹시 더 좋은 방법이 있다면 알려주시면 감사하겠습니다~

1번 방법과 2번 방법 중 어떤 방법이 더 좋은지, 2번 방법의 데이터 관리가 괜찮은지에 대한 질문인 것 같아요 먼저 1번 방법의 경우 목록이 많아지면 많아질 수록 많은 요청과 자원이 필요하게됩니다 예시의 경우만 하더라도 6번의 요청과 6번의 응답, 3번의 삭제 쿼리, 3번의 추가 쿼리, 3번의 저장을 하게됩니다 2번의 경우 1번의 요청과 1번의 응답, 1 ~ 3번의 삭제 쿼리, 1 ~ 3번의 추가 쿼리, 1번의 저장을 하게 되겠죠 제 기준에서 좋은 방법은 효율적이면서 더 적게 요청하면서 더 적은 쿼리를 하는것이라 2번 방법이 좋아보입니다 2번 방법의 데이터 처리 방법은 괜찮아보입니다 보통 RESTful 하다고 이야기하는 것은 HTTP Method와 상태 중심적인 어떠한 스타일을 얘기하는 것이라 개별적으로 처리하는 것과 리스트로 처리하는 것은 RESTful한 API와는 관계가 없어보입니다 저는 관심 목록 같은 기능을 구현할 때 이렇게 구현했습니다 GET - 유저의 관심 목록을 데이터베이스에서 조회하고 반환합니다 POST - 요청된 목록을 중복이 아니라면 (중복 검사는 쿼리로 했습니다)데이터베이스에 추가하고 저장합니다 PUT - 유저의 관심 목록을 모두 삭제한 뒤 요청의 목록을 추가하고 저장합니다 PATCH - 요청된 목록과 유저의 관심목록을 비교해 삭제되어야할 항목과 추가되어야할 항목을 구분하고 데이터베이스에서 삭제 후 추가하고 저장합니다 DELETE - 요청된 목록을 모두 데이터베이스에서 삭제하고 저장합니다 최초 등록이나 이후 추가만을 원할 때는 POST로 배열을 담아 요청했습니다 질문에서처럼 일부만 변경하는 경우 변경 후의 결과를 배열에 담아 PATCH로 요청했습니다 전체 변경하려는 경우 변경 후의 결과를 배열에 담아 PUT으로 요청했습니다 태그같은 것이 아닌 식별이 가능한 개별 삭제의 경우에는 HTTP DELETE /:id 같은 end point를 활용합니다 저는 PATCH도 사용하긴 하는데 데이터의 내용을 수정하는게 아니라서 상황에따라 PUT으로 모두 삭제 후 추가하는 것이 더 빠를지는 모르겠습니다 그치만 아무래도 데이터가 커지면 PATCH가 효율적입니다

외 1개 답변 보러 가기

목록으로
키워드로 질문 모아보기

기술, 커리어 고민이 있다면

새로운 질문 올리기

지금 가입하면 모든 질문의 답변을 볼 수 있어요!

이메일로 가입하기