[SK네트웍스 Family 엔코아AI캠퍼스] AI 레디 데이터 엔지니어링 캠프 1기_10월 1주차 회고

About this offer

9/28(월) - 운영 지표를 화면에서 관찰하기 이번 주 초에는 게임 시스템에서 발생하는 요청을 단순히 처리하는 것에서 끝내지 않고, 실제 시스템이 어느 정도의 성능으로 동작하는지 확인하는 방법을 배웠다. 처리율, 평균 RTT, p95 같은 지표를 화면에서 확인할 수 있도록 구현하면서 운영 환경에서는 기능이 정상적으로 동작하는 것뿐만 아니라 얼마나 빠르고 안정적으로 처리되는지도 중요하다는 것을 알게 되었다. throughput = completed_requests / elapsed_time average_rtt = sum(rtt_values) / len(rtt_values) sorted_rtt = sorted(rtt_values) p95_index = int(len(sorted_rtt) * 0.95) p95 = sorted_rtt[p95_index] 특히 평균값만 보면 일부 느린 요청을 발견하기 어려울 수 있기 때문에 p95와 같은 지표를 함께 보는 이유도 이해할 수 있었다. 9/29(화) - Bronze 데이터 검증과 무결성 확인 Kafka에서 수집한 데이터를 Bronze 영역에 저장한 뒤, 파일이 제대로 저장되었는지 검증하는 과정을 진행했다. 이번에는 단순히 파일이 존재하는지만 확인하는 것이 아니라 bytes, SHA256, rows를 기준으로 데이터가 원본과 동일한지 확인했다. { "run_id": "capture-002", "observed": { "bytes": 28172873, "sha256": "fd07b340666f8fc2dcca17d143ae5c93c10c5a26fd82fb2c7691d7acbf019113", "rows": 33919 }, "checks": { "bytes": True, "sha256": True, "rows": True } } 세 가지 검증 결과가 모두 True 인 것을 확인했다. 이 과정을 통해 데이터 엔지니어링에서는 "파일을 저장했다"보다 "저장한 데이터가 원본과 동일하다는 것을 확인했다"가 더 중요하다는 것을 배웠다. 또한 Bronze 데이터를 바로 분석에 사용하는 것이 아니라 파싱해서 staging Parquet으로 만들고, 이후 Silver와 Gold 데이터로 발전시키는 전체적인 흐름도 조금씩 이해하기 시작했다. 9/30(수) - 중복 전달과 논리적 이벤트 구분 Kafka와 같은 메시지 시스템에서는 같은 데이터가 여러 번 전달될 가능성이 있기 때문에 물리적으로 전달된 횟수와 실제 사건의 개수를 구분해야 한다는 것을 배웠다. accepted = 3 logical = 2 duplicate_deliveries = accepted - logical print("duplicate_deliveries", duplicate_deliveries) 실행 결과는 다음과 같았다. accepted 3 logical 2 duplicate_deliveries 1 3개의 데이터가 들어왔다고 해서 실제 사건이 3개라는 의미는 아니다. event_id 를 기준으로 확인했을 때 실제 사건은 2개이고, 나머지 1개는 중복 전달일 수 있다는 것을 알게 되었다. 이전에는 데이터 개수만 맞으면 된다고 생각했는데 이번 수업을 통해 데이터의 개수뿐만 아니라 "같은 사건이 중복으로 들어온 것은 아닌가?"까지 확인해야 한다는 것을 배웠다. 10/1(목) - Parquet 압축 방식 비교 같은 데이터를 Parquet으로 저장하면서 Snappy와 Zstandard(zstd) 압축 방식을 비교했다. 처음 실행했을 때는 다음과 같은 결과가 나왔다. [ { "codec": "snappy", "rows": 33912, "write_seconds": 6.0283, "read_seconds": 1.4481 }, { "codec": "zstd", "rows": 33912, "write_seconds": 1.5716, "read_seconds": 0.4089 } ] 그런데 실행 순서를 변경해서 다시 측정했을 때는 결과가 달라졌다. [ { "codec": "zstd", "rows": 33912, "write_seconds": 6.3039, "read_seconds": 1.9649 }, { "codec": "snappy", "rows": 33912, "write_seconds": 1.3949, "read_seconds": 0.6079 } ] 이 결과를 통해 한 번 실행한 결과만 보고 "어떤 압축 방식이 무조건 더 빠르다"고 판단하면 안 된다는 것을 알게 되었다. 캐시, 디스크 상태, 실행 순서 등 여러 조건이 측정 결과에 영향을 줄 수 있기 때문에 같은 조건에서 여러 번 측정하고 비교해야 한다. 단순히 코드를 실행하는 것보다 실험 조건을 통제하고 결과를 해석하는 것이 중요하다는 점이 기억에 남았다. 10/2(금) - Django 인증과 MongoDB 데이터 상태 확인 Django 서버에서 요청을 처리하기 전에 로그인한 사용자인지 확인하는 인증 로직을 찾아보았다. if not request.user.is_authenticated: ... 프로젝트 안에서 인증 검사가 사용되는 위치를 직접 검색하면서 Django의 여러 기능이 결국 각각의 파일과 함수로 연결되어 있다는 것을 다시 확인할 수 있었다. 또한 MongoDB의 village_ads 데이터베이스와 campaigns 컬렉션 상태를 직접 확인했다. print(db.campaigns.count_documents({})) print({ "database": db.name, "campaigns": db.campaigns.count_documents({}) }) 결과는 다음과 같았다. 0 { 'database': 'village_ads', 'campaigns': 0 } 오류가 발생했다고 바로 코드를 수정하는 것이 아니라 현재 어떤 데이터베이스에 연결되어 있는지, 실제 데이터가 몇 건 존재하는지를 먼저 확인하는 과정이 중요하다는 것을 배웠다. 이번 주 전체적으로 이해한 흐름 이번 주에는 각각 다른 내용을 배운 것처럼 보였지만 전체적으로 연결해서 보면 하나의 흐름이 있었다. 데이터 발생 ↓ Kafka 등을 통해 데이터 전달 ↓ Bronze에 원본 데이터 저장 ↓ bytes / SHA256 / rows 검증 ↓ 파싱 및 Parquet 변환 ↓ event_id 기준 중복 확인 ↓ Snappy / Zstd 등 저장 방식 비교 ↓ Silver / Gold 등 분석 가능한 데이터로 가공 ↓ Django API에서 데이터 제공 ↓ 인증된 사용자가 조회 ↓ 처리율 / RTT / p95 등 운영 상태 관찰 예전에는 Kafka, Spark, Parquet, Django 같은 기술을 각각 따로 배우는 느낌이 강했다. 이번 주에는 데이터가 어디에서 만들어지고, 어떻게 전달되고, 어떻게 검증되고, 어떤 형태로 저장되고, 최종적으로 어떻게 서비스에서 사용되는지가 조금 더 연결되어 보이기 시작했다. 특히 데이터 엔지니어링에서는 데이터를 많이 처리하는 것만 중요한 것이 아니라 중복되지 않았는지, 원본이 손상되지 않았는지, 처리 결과를 다시 재현할 수 있는지 확인하는 과정이 중요하다는 것을 이해했다. Keep - 계속 유지하고 싶은 점 이번 주에도 결과만 보고 넘어가기보다는 이상한 결과가 나오면 원인을 확인하려고 했다. 특히 Snappy와 Zstd 비교에서 첫 번째 결과만 보고 결론을 내리지 않고 실행 순서를 바꿔 다시 측정해 본 것이 좋았다. 또한 MongoDB에서도 데이터가 없다는 결과가 나왔을 때 바로 코드를 수정하기보다 현재 DB 이름과 document 개수를 직접 확인했다. 최근 수업 내용이 점점 어려워지고 있지만 하나씩 출력값을 확인하면서 따라가면 전체 흐름은 이해할 수 있다는 것을 느끼고 있다. Problem - 어려웠던 점 이번 주에는 단순한 Python 문법보다 데이터 파이프라인과 운영 관점의 개념이 많이 등장해서 어려웠다. Bronze, staging, Silver, Gold처럼 데이터가 단계별로 나뉘는 이유와 event_id , 중복 전달, SHA256 같은 개념을 처음에는 각각 따로 이해하려고 해서 복잡하게 느껴졌다. 또한 성능 측정 결과가 실행할 때마다 달라질 수 있다는 점도 처음에는 혼란스러웠다. 코드가 정상 실행됐다고 해서 그 결과가 항상 정확한 결론을 의미하는 것은 아니라는 점이 이번 주에 가장 어려우면서도 중요한 부분이었다. Try - 다음 주에 보완할 점 다음 주에는 코드를 실행하기 전에 이 코드가 전체 파이프라인에서 어떤 역할을 하는지 먼저 생각해보려고 한다. 특히 다음 질문을 스스로 해보는 습관을 만들고 싶다. 1. 이 데이터는 어디에서 왔는가? 2. 지금 어떤 단계의 데이터인가? 3. 중복이나 손상 여부는 어떻게 확인하는가? 4. 이 작업의 결과는 어디에 저장되는가? 5. 다음 단계에서는 이 데이터를 어떻게 사용하는가? Kafka, Spark, Bronze, Silver, Gold, Django를 각각 외우기보다는 데이터 하나가 처음 발생해서 최종 화면에 나타날 때까지 이동하는 과정을 기준으로 복습할 예정이다. 한 주를 마치며.. 이번 주는 단순히 데이터를 처리하는 방법보다 "이 데이터를 믿어도 되는가?"를 확인하는 방법을 많이 배운 한 주였다. 처음에는 bytes, SHA256, 중복 전달, 압축 방식 비교 같은 내용이 왜 필요한지 잘 이해되지 않았지만 전체 흐름으로 연결해보니 실제 서비스를 운영하려면 반드시 필요한 과정이라는 것을 알게 되었다. 특히 이번 주를 지나면서 코드를 작성하는 것만큼 결과를 검증하고 이상한 부분의 원인을 찾아가는 과정이 중요하다는 것을 다시 느꼈다. 아직 모든 코드를 혼자 처음부터 작성할 수 있는 수준은 아니지만, 출력 결과를 보고 현재 어떤 단계인지 파악하고 문제가 생겼을 때 어디부터 확인해야 하는지는 전보다 많이 익숙해진 것 같다. 다음 주에는 개별 기술을 외우는 것보다 전체 데이터 흐름 안에서 각 기술이 어떤 역할을 담당하는지 더 확실하게 이해하는 것을 목표로 하고 싶다.