[공통] 데이터엔지니어 하면서 테스트 하는 방법

 

안녕하세요. 주형권입니다.

회사에서 파트장을 맡으면서 파트원들에게 이것저것 알려주다 보니 많은 생각이 들었습니다. 내가 처음에 회사를 들어왔을 때 누군가에게 배웠다기보다는 어깨 너머로 스스로 배웠다고 생각했던 것들이 많은데 요즘은 이게 어려운 거 같습니다. 워낙에 각자도생의 시대이고 서로 협업보다는 경쟁을 부 축이는 사회라서 그런지 세세하게 알려주거나 공유하는 문화가 거의 없다 보니 연차가 꽤 있음에도 제 생각엔 기본이라고 생각하는 것들을 모르는 경우가 많습니다. 

 

그래서 오늘은 그중에 하나인 테스트 하는 방법에 대해서 말씀 드리려고 합니다. 이 내용은 데이터엔지니어에 관련해서 제가 하는 방식을 그대로 적은것으므로 각자의 방법이 서로 다를 수 있습니다. 그러므로 본인이 하는 방법이 틀린 것은 아니고 이제 막 시작 하거나 테스트를 어떻게 해야 할지 막막한 분들에게 많은 도움이 되었으면 합니다. 

 

이 글에서는 데이터에 어떠한 조작이나 데이터를 이용한 테스트에 관한 글이며 여러가지 운영적인 테스트보다는 데이터 중점으로 글을 작성하였으므로 이점 참고 부탁 드립니다.

---

Step 1. 샘플 데이터 만들기

 

우선 테스트를 하기 위해서는 샘플 데이터를 만들어야 합니다. 샘플 데이터를 만드는 이유는 대부분의 데이터 엔지니어는 관리자 권한을 가지고 있기 때문에도 있고 실제 데이터를 사용할 경우 크기가 크기 때문에 컴퓨팅 자원이나 속도 측면에서 무언가를 하기가 어려울 수 있기 때문입니다. 

 

샘플 데이터는 주로 데이터엔지니어만 쓰는 공간에 만들어서 사용 하는게 좋습니다. 공용 공간에 넣어서 사용할 경우 사람들이 잘못 사용해서 잘못된 결과를 보고 오판을 하거나 할 수 있고 추후에 DROP 테이블이나 파일을 지우다 잘못 지우는 경우  복잡한 문제가 발생합니다. 그렇기 때문에 격리된 공간에서 샘플 데이터를 만들어서 테스트를 해보시는 것을 추천드립니다. 

 

테이블이 아닌 파일의 경우도 S3에서 Bucket을 새로 만들거나 폴더를 분기해서 완전히 격리된 공간에서 하는 것을 추천 드립니다. 이 부분도 위와 마찬가지로 사용자가 볼 수 없는 별도의 공간이 제일 좋습니다. 결국 중요한것은 어떠한 샘플을 만들든 격리된 공간에 만들고 관리자(데이터엔지니어)만 접근이 되는 또는 개인만 접근이 되는 환경에서 하는 게 가장 좋습니다. 

 

---

Step 2. 로직 테스트 

 

샘플을 만들었으니 로직을 샘플에 녹여서 테스트를 합니다. SELECT와 같이 조회를 테스트 하는 경우는 큰 이슈가 없으나 아무리 샘플이라도 데이터가 변경되는 경우는 샘플을 무제한으로 찍을 수 없기 때문에 번거로움이 있습니다. 그래서 테스를 할 때는 다음과 같이 살짝 바꿔서 할 수 있습니다. 

 

INSERT

결국 데이터가 잘 들어가는지를 테스트 하기 때문에 껍데기만 그대로 복사해서 데이터가 잘 적재되는지 테스트할 수 있습니다. INSERT를 테스트하는 경우는 보통 해당 테이블에 구문 오류 또는 데이터 타입이 정상적으로 들어와서 문제가 없이 적재가 되는지를 주로 테스트하기 때문에 껍데기만 복사해서 잘 적재되는지만 볼 수 있습니다. 즉, 샘플 데이터를 만들지 않고 할 수도 있습니다. 

 

DELETE

DELETE를 SELECT로 바꿔서 테스트 해볼 수 있습니다. 우선 샘플을 만들고 이 샘플에 DELETE FROM 이 아니고 SELECT FROM으로 구문을 실행합니다. 구문을 실행하면 실제 지워지는 대상자를 알 수 있고 추가적으로 소요되는 시간을 알 수 있습니다. DELETE를 하는 게 결국 SELECT를 해서 지우는 것이므로 이 부분도 함께 테스트를 할 수 있습니다. (물론 다릅니다. 짐작이 된다는 것이지요.) 

 

UPDAETE

샘플 데이터를 굉장히 소수 (10건 정도)만 복사해서 사용하고 특정 조건으로 UPDATE가 잘되는지 볼 수 있습니다. 결국은 UPDATE의 경우 이미 있는 데이터를 바꾸는 작업이므로 이 데이터가 내가 원하는 모양으로 잘 바뀌는지에 대한 테스트가 주 입니다. 그래서 굉장히 작은 샘플을 복사해서 테스트하고 TRUNCATE 후 다시 복사해서 하고 여러 번 반복해서 해보고 하는 방법이 좋다고 봅니다. 

 

SELECT

데이터를 조작하는 것이 아니지만 하실때 파티션, PK, 옵션등 테이블에 설정에 따라서 차이가 굉장히 심하게 나타나므로 이점을 확실히 실서버와 비슷하게 만들어서 해야 합니다. 실제로 그 양이 크지 않으면 샘플을 만들지 않고 실제 데이터를 가지고 하는 경우도 있지만 RDBMS의 경우 Lock이 발생하는 경우도 있고 자원을 독점해서 다른 작업에 지장을 줄 수 있기 때문에 별도의 공간에서 해도 좋다고 생각됩니다.

---

Step 3. 데이터 확인하기

 

당연한 이야기지만 테스트 후에 데이터 검증은 필수입니다. SELECT의 경우 자연스럽게 가능하겠지만 나머지 조작이 수반되는 데이터 테스트는 무조건 검증이 필요합니다. 검증을 하는 방법은 여러 가지 있는데요. 제가 생각나는 부분에 대해서 적어 보겠습니다. 

 

1. ORDER BY를 통한 검증

주로 날짜 데이터를 통해서 특정 일자를 업데이트하는 경우가 많습니다. 그렇기 때문에 해당 일자만 정상적으로 반영되었는지 확인하기 위해서는 ORDER BY의 ASC / DESC를 통해서 해당 일자의 값이 정상적으로 변경되었는지 알 수 있습니다. 데이터를 변경하고 WHERE 후에 ORDER BY로 해당 날짜로 정렬하면 값의 변화를 쉽게 알 수 있습니다.

 

2. 특정 값 조회 해보기

샘플 검증이라고 표현하면 좋을 거 같습니다. 내가 100명의 유저를 대상으로 업데이트를 진행했다고 가정하겠습니다. 그렇다면 내가 데이터를 조작했던 조건(WHERE) 값을 몇 개 샘플링해서 SELECT 해보고 실제로 변경이 잘 이루어졌는지 볼 수 있습니다. 특정 유저의 값을 따라가면서 하나씩 볼 수도 있습니다. 

 

3. DELETE 전에 SELECT로 대상자 확인

앞서 언급하였던 DELETE 부분의 내용입니다. DELETE를 할 때 아마도 WHERE에 특정 조건을 삭제하려고 하는 경우가 많습니다. 그렇기 때문에 DELETE -> SELECT로 변경하고 조건(내가 원하는 대상)이 맞는지 대상 Raw를 확인할 수 있습니다. 

 

4. 건수 체크

데이터를 ETL / ELT 하는 파이프라인을 구현할 때 건수가 정확히 원본 데이터와 맞는지 검사하여 기본적인 검사를 할 수 있습니다. 건수가 정확히 맞으면 일단 넘어온 것은 맞으므로 간단하게 검증이 가능합니다. 실제로 여러 가지 오류로 인해서 데이터가 깨져서 안 들어오거나 줄 바꿈 연산자 같은 기호 때문에 뻥튀기되어서 들어오는 경우도 많습니다. 

 

5. 중복 체크

전부는 아니지만 RDBMS 같은 정형 데이터의 경우 고유 값이 있습니다. 로그 번호 같은 숫자값이 있으면 베스트하고 유저 테이블을 가져올 때는 유저의 고유 값이 있기 마련입니다. 하지만 우리가 사용하는 분산처리 환경의 경우 PK를 지원하지 않는 경우가 많습니다. (있어서 유니크 값이 아닌 경우도 많음) 그렇기 때문에 중복으로 데이터가 적재되지 않았는지 GROUP BY와 HAVING을 통해서 검증이 가능합니다.

---

Step 4. 소요시간 계산하기

 

소요시간의 경우 보통 산술적인 수치로 계산해야 합니다. 예를 들면 내가 실제 데이터의 10%를 샘플로 만들었다고 예를 들어 보겠습니다. 10%의 샘플 데이터가 소요시간이 1분이 걸렸다고 가정하면 이를 단순히 1분 * 10을 해서 10분이라고 산술적으로 예상할 수 있습니다. 이외에 조금의 예외 사항이 있기 때문에 *20%를 하면 조금 더 좋다고 생각합니다.

 

물론 이건 어디까지나 산술적 수치이므로 정확하다고 볼 수 없습니다. 특히 분산처리 환경에서는 옵티마이저(계산하는 놈으로 생각하시면 됩니다.)가 판단할 때 작은 크기와 큰 크기는 엄청나게 다르게 계산하므로 대부분 맞진 않습니다. 그러므로 20% 정도 더 소요시간을 가중해서 계산하였습니다. 그리고 오히려 최대한 크게 잡아서 산정하고 더 빨리 끝난다면 더 좋으므로 최대한 모든 상황을 감안해서 길게 잡기를 권장합니다.

 

그렇다고 10분짜리를 100분으로 계산하면 너무 오래 걸리므로... 적당한 판단이 중요합니다. 아마도 많은 작업을 하다 보면 아 이 정도면 끝나겠다. 싶은 감이 생깁니다.

---

Step 5. 비용 계산하기 

 

테스트를 할 때는 비용이 빠질 수 없습니다. 주로 샘플 데이터를 가지고 하였으므로 이 크기를 실제 데이터의 크기와 비교해서 역산하여하는 게 좋습니다. 예를 들면 실제 데이터의 1/10로 테스트를 하였는데 총비용이 100원이면 이를 100 * 10으로 계산하여 할 수 있습니다. 물론 컴퓨팅이 크면 클수록 돈이 더 많이 들기 때문에 그 계산은 쉽지 않습니다.

 

그래서 많은 밴더사들이 수많은 계산기를 지원합니다. 계산도 쉽고 빠르게 가능하고 편하게 할 수 있습니다. 제가 알고 있는 사이트 몇 개를 추천드립니다. 아래의 사이트는 AWS와 Databricks용입니다. (제가 지금 주로 해서...)

 

 

 

Pricing Calculator (가격 계산기) | Databricks

 

Amazon EC2 Instance Comparison