혹시 이게 제 잘못일까요?... 여쭤봅니다

Question

삭제하겠습니다 죄송합니다

chiho · Answer

뭐 어떻게 했든 마지막 작업한 사람이 확인 못한거죠.. 저는 잘못했다고 생각은 안해여

전뚱이인데요 · Answer

동기분이 님 쿼리 손댄거 아니에요 결국에는? 그래서 기존 작성자분 테이블에도 마스킹 된 데이터가 적재 되서 문제가 발생한거고 동기분이 잘못했네요.. 해당 쿼리가 어디에 쓰이는지 먼저 확인하고 수정하는건 기본 아닌가..

바냐파노 · Answer

그래서 보통 2가지 방법 중 택1하는 편입니다.1. 쿼리에서 마스킹 시, 이름, 마스킹 이름 따로 내보냄(name, masked_name)2. 쿼리에서 마스킹 안 하고 이름 내보낸 후 service 단에서 마스킹 함이러면 부주의한 사람이 와도 masked_name을 보고 갖다쓰진 않겠죠. 갖다쓰면 바보고..

scissors hand · Answer

chat gpt 왈:✅ 핵심 정리당신이 쿼리를 분리하지 않은 것은 위험요소를 만든 행동이 맞습니다.하지만 당시 기획 요구사항에 따라 마스킹이 필요 없었고, 단순히 같은 조회 로직을 재활용한 것이라면 명백한 실수로 단정 짓긴 어렵습니다.동료가 마스킹을 쿼리 단에서 적용한 것도 일면 타당하지만, 업데이트에까지 영향을 줄 수 있는 점을 고려하지 않은 것은 실수라고 볼 여지가 있습니다.결국엔 조회 목적과 수정 목적이 혼재된 쿼리 재사용이 문제의 본질입니다.📌 왜 쿼리를 분리했어야 했는가?조회와 업데이트 목적이 다르기 때문입니다:목적특징마스킹 처리 필요 여부UI 조회사용자에게 보여줌필요 (보안, UX 목적)DB 업데이트용 조회내부 처리용불필요 (원본 필요)따라서 하나의 쿼리에서 조건/가공을 추가해서 두 역할을 동시에 하도록 만든 구조는 위험합니다. 실제로도 보안/기능 요구사항이 달라지면서 문제가 터진 것이죠.🧠 책임 분배에 대한 현실적인 조망역할책임과거의 나조회와 업데이트 목적의 쿼리를 구분하지 않은 구조를 만든 점에서 구조적 실수는 있음동료마스킹이 조회에만 필요한 것임을 고려하지 않고 쿼리 자체를 바꿔버린 건 부주의함기획/요구사항 변경처음부터 마스킹 여부를 분명히 정의하지 않은 것도 일부 원인즉, 명확한 커뮤니케이션 부족과 역할의 경계 불분명함이 복합적으로 만든 문제입니다. 어느 한 사람만의 잘못으로 보기는 어렵고, 개선이 필요한 팀 전체의 코드 구조 및 프로세스 문제입니다.✅ 앞으로 어떻게 하면 좋을까?조회용 쿼리와 내부 처리용 쿼리를 명확히 분리하세요.MyBatis에서는 resultMap이나 별도의 select로 관리하기 쉽게 설계.마스킹은 Presentation 계층 또는 ViewModel에서 처리하는 것이 바람직합니다.보안 요구가 쿼리단에서 변동되지 않도록 방어 가능.기획 변경이 있을 경우, 영향도 분석 절차 강화."어떤 API/기능이 이 쿼리 쓰고 있는가?" 정도는 최소한 확인.조회용 VO, DTO 따로 만들기.마스킹된 이름, 생년월일 등은 별도 필드로 가져오도록 명시적으로 설계.결론쿼리를 분리하지 않은 건 잠재적 리스크를 만든 것은 맞지만, 당시 기준에서는 합리적인 선택일 수도 있었고, 문제의 직접 원인은 마스킹을 쿼리 단에 도입하면서 영향 범위를 충분히 고려하지 않은 데 있습니다.즉, 구조의 문제이며, 향후 개선의 기회로 삼는 것이 가장 생산적인 접근입니다.

Billy93 · Answer

제가 이해를 잘했는지 모르겠지만 - 정보 조회 쿼리는 공통 사용중, 업데이트와 페이지 조회시 해당 쿼리를 사용하는데 공통으로 사용중인 조회 쿼리에 마스킹 로직을 적용해서 업데이트할때 기본 데이터가 마스킹이 들어간 상태로 엎어쳐져서원천 데이터를 알수 없게 되었다? 이런 이슈일까요. 음 일단 이 이슈가 맞건 아니건, 개인정보 취급은 모든 도메인이 공통으로 마스킹까지 고려가 되어서설계가 되는게 맞다고 생각합니다.기획에 설령 없었더라도요.근데 이게 fault를 얘기할 사안은 아닌것같아요.개발은 혼자만의 작업이 보통 아니여서요.우선 합리적인 방법은,데이터단 마스킹처리는 별도로 DB에서 마스킹 블러 처리해서 관리할 수 있어서우선 실질적으로 데이터 포멧팅을 하는 시점은 조회 후 서버에서 dto 매핑할때 서버로직으로 데이터를 masking 하는 방법이 합리적이지 않았을까 싶네요.이러면 masking 로직 자체를 개인정보뿐만아니라다른 데이터 타입별로 분기해서 모듈로도 사용할 수 있고,쿼리 자체에도 영향도가 가지않아 추후 다른 작업을 할때도 선택지가 넓어질 수 있어요.클라이언트 단에서 response data를 가지고 스크립트로 마스킹 하는 선택지도 있지만,이 부분은 non masking 상태의 데이터를 유출시키기 쉬워서 고려하지 않는 방향으로 가시는걸 추천드립니다.

Bale K · Answer

얘기도 없이 그냥 씀테스트 안해봄 (해도 대충함)문제 됨이걸 도대체 어떻게 받아들여야 본인 잘못으로 생각하시는지...너무 착하시군요

엑크탁스 · Answer

구현을 화면 단위로 하시나요? 의사소통이 중요한데 부재된것 같군요 api명세나 기능도 문서 같은걸로 공유되지않나요 보통

apidevelop222 · Answer

동기분 잘못이죠 ㅋㅋㅋ 개발자가 물론 유지보수나 확장성을 고려해서 그것 까지 감안하고 개발해야하는건 맞지만 수도 없이 바뀌는 기획이 어떻게 바뀔지는 예측하기 어렵죠,,쿼리를 분리하지않은것도 이런 이유였을테고 쿼리를 분리하는게 무조건 좋다도 아니에요. 하나로 합치면 그만큼 쿼리에대한 목적이 명확해지죠. 동기가 아무 생각없이 다른곳에 쓰는지 보지도않고 가져다쓰면서 수정한게 문제입니다.최소한, 수정했다면 이 쿼리를 만든사람에게 내가 수정했을시 혹시 다른곳에도 영향이 있을지 물어봐야합니다.

프로폴리스 · Answer

글 펑은 좀..

혹시 이게 제 잘못일까요?... 여쭤봅니다

9개의 답변

Q&A 목록