상세 주소를 필터링 하면서 아차 싶었던 건에 대하여

Matthew Woo·2022년 8월 14일
0

Work

목록 보기
1/3

회사에서 업무 도중에 아차. 싶었던 모먼트가 있었다. 스스로 일 하면서 아쉬웠던 부분인데 반성 겸 글을 남겨 놓고자 한다.


상황은 다음과 같다.
우리 Service에 외부에서 api 를 쏴서 유저 및 유저 기기에 대한 정보가 들어오는데, 일부 트래픽에서 해당 유저가 우리 Product을 사용하고 있는 장소의 IP를 기반으로 상세한 유저의 위치정보가 들어왔다. 이걸 그대로 내부에서 저장하고 있다보니 보안상의 이유로 문제가 되었다. 보안팀에서 개선을 요청하였고 이에 두 가지 작업이 필요했다.

  1. api 들어오는 부분에서 상세주소를 필터링 후 이후 로직을 타게한다.
  2. 기존에 이미 저장되어 있는 주소들을 가져와 상세주소는 필터링되도록 update 한다. (구, 군단위 까지만 저장되도록 하는 것이 보안팀의 요구사항이었다.)

담당자가 나로 지정되며 지라카드를 배정 받았고, CTO님이나 보안 팀등 관련에서 context가 있는 분들의 slack communication 내용을 참고하였다.

해당 slack에서는 redash 로 s3에 적재되어 있는 데이터들을 조회된 주소들을 볼 수 있었다.
저장된 데이터들의 양이 꽤나 많았다. 해당 주소는 DynamoDB에 저장되고 있었는데 주소가 저장되어 있는 테이블의 크기가 400 GB였고 이를 full scan하면서 수정해주어야했다. redash에서 나오는 주소들을 기반으로 코드를 작성했다.
주소들은 신주소 체계를 따르고 있었고 기존에 저장된 데이터를 보고 코드를 작성하였고 PR을 올리고 결과를 기다렸다.

여기서 본론이 나온다. 왜 아차 싶었는지.


이미지출처: http://www.gisdeveloper.co.kr/?p=1931

1. 나는 워낙 저장되어있는 주소 데이터가 많고, 주소체계라는 것이 비교적 변수가 많거나 양식이 다양하지 않아서, 기존 데이터들을 보면서 충분히 예외처리가 되었으리라 생각했다.

예외가 발생할 수 있는 테스트 케이스까지 작성을 충분히 해놓고 PR을 올린 시점에서 문득 든 생각. 나는 왜 신주소체계가 어떻게 정의되어있는지, 규정되어있는지 찾아보지 않았지..?
기존에 저장된 많은 주소들을 보면서 작업을 했고, 그 과정에서 예외가 발생할까봐 많은 케이스를 시간들여서 보았는데, 그냥 처음부터 신주소체계를 어떻게 정의하고, 어떻게 지역들을 구, 군, 시, 등으로 나눠놨는지 봤어야했다.
예외가 발생할까봐 꽤 신경을 많이 썻는데 그냥 주소체계를 봤으면 빠르게 작업할 수 있었던 부분이라 후회가 남았다.

2. 막상 PR을 올려놓고 나서, aws에서 해당 테이블에 들어가 주소값을 봤는데.. 어라..? 해당 region에 막상 보니 데이터가 들어가있지 않다..

이미 400GB에 해당하는 특정 테이블을 full scan하도록 PR까지 올려놨는데 막상 들어가보니 데이터가 없다..?
나는 s3 redash로 조회한 데이터들을 봤고, slack에서 CTO님이 알려주신 table에 작업하도록 코드를 짯는데 막상 보니 데이터가 없네..?
나는 이걸 왜 지금 코드 다 짜놓고 확인하고있지...?

다행스럽게도 결과적으로는 저 table의 reg이 내가 작업하고자 하는 부분이 맞았다. 다만 비어있는 데이터들이 워낙 많아서 위 이미지처럼 비어있는 페이지가 많았다. redash로 조회했던 주소들은 조건식으로 주소 데이터가 존재하고, 특정 길이 이상인 것을 조건문으로 주어서 나왔던 결과였다. 실제 db상에서든 대부분 주소가 없거나, 상세주소는 들어오고 있지 않았다. 다만 일 부분이 상세주소까지 들어오고 있으나 워낙 데이터가 많다보니 값이 존재하지 않는 데이터도 많았던 것이다.

CTO께서 특정 Table명까지 알려줬다고는 해도, CTO께서도 사람이니 실수할 수 있는 부분이고, 현재 회사에서 사용하는 디비가 하나가 아닌데 특정 Table명이 동일한게 존재한다거나 커뮤니케이션 상에 잘못 전달될 수 있는 부분인데 작업하는 담당자로서 먼저 실제 작업할 db의 데이터를 확인하지 않았다는 부분이 아쉬웠다.

2로 인해서 이미 작업한 결과물이 달라지진 않았으나 1의 과정에서 상세주소 중 '층'이 들어오는 것을 예외처리되지 못하였고 'O층' 이 필터링 되지 못하여 수정하게 되었다. 귀납적 접근 방식이 아니라 연역적으로 문제를 해결하려했어야하는데 아쉬움이 남는 부분이었다.

잘하자!

profile
Code Everyday

0개의 댓글