디비를 날려보자

 

​

​

오늘 갑자기 밥먹다가 생각난게 있어서 공유드려봅니다.

신입 때 모두 여러분들만의 실수나 어려움이 있었을거예요.

저는 디비를 삭제했던 기억이 나는데요.

​

다행히도 테스트서버의 디비라서 복구하는데 큰 어려움이 없었어요.

그리고 도와주는 선배들도 있었구요.

근데 그 때 삭제했을때를 생각해보면 삭제하자마자 1초만에 제가 잘못한 거를 깨달았죠.

​

원래는 특정 테스트테이블을 삭제했어야 하는데, 서두르느라 테스트 디비 전체를 삭제하는 쿼리를 요청한거죠.

​

쿼리를 날리자마자 선배한테 뛰어갔어요. 큰일났다고.

다행히도 선배님은 침착하게 함께 보자고 말씀해주셨고 테스트디비라서 괜찮다고 하고 금방 복구하는데 피드백을 주셨죠.

​

그 때부터 저도 침착하게 대응하고 솔직하게 피드백 하는 법에 대해 연습을 했죠.

아무튼 바로 저는 인프라팀에 전화를 해서 테스트 디비 복구 요청을 했습니다. 복구하는 쿼리를 작성해서 인프라팀에 요청했고 인프라팀에서도 감사히 빠르게 복구해주셨죠.

​

이 때를 생각하면서 느낀게 있었어요.

데이터의 시작부터 중간까지, 그리고 중간의 중간, 데이터의 종착지까지의 흐름을 이해할 수 있었어요.

책에서만 보던 mysql의 흐름을 실제로 머리에 새길 수 있었죠.

​

​

그리고 다른팀, 여기서는 제가 소속됐던 IT지원팀, 인프라팀, 보안팀까지 어떤 일을 하는지 실제적으로 이해할 수 있었어요.

또한 데이터 서버실의 존재, 데이터 서버실에서 사용하는 운영체제와 프로그래밍 언어, 데이터 서버의 문제, 데이터 보안의 어려움을 공감할 수 있었죠.

​

여기서 핵심은 데이터 전체의 플로우를 이해하는거라 생각해요.

요즘은 내부디비보다 클라우드를 많이 쓰죠.

그런데도 아직 보안 이슈로 인해 내부디비를 쓰시는 분들이 많을거예요.

​

특히 보안업계, 금융업, 보험업 등 데이터 보안에 신경쓰는 경우에는 더 심하겠죠.

디비를 삭제해보면서 플로우를 익힐 수 있었는데요.

그러면 실제로 디비를 삭제해봐야될까요?

​

당연히 아니죠.

그러면 어떡해야 될까요?

가장 유사한 방법은 빅쿼리나 dbeaver와 같은 곳에서 테스트 디비를 활용해보는거예요.

​

클라우드에서의 상황과 로컬에서 쿼리를 동작시키는 방식이 다르다는 것을 이해해보는거예요.

가끔 타팀에 대한 이해없이 SQL만 활용하는 경우가 있죠. 다른 팀은 어떻게 일하는지 관심없을 수도 있어요.

​

하지만 다른 팀은 어떤 일을 왜 하는지, 데이터를 어떻게 왜 사용하는지, 또는 데이터를 왜 안쓰는지 관심을 가져야 데이터에 대한 제대로 된 이해를 가져갈 수 있다고 생각해요.

​

그리고 팀별로 다르겠지만, 데이터가 어디서 시작하고 끊기는지 회사에서 실제로 어떻게 돌아가는지 그림을 그려보시면 데이터에 대한 깊이있는 이해에 도움되실거라 생각합니다.