StudyDad

데이터와 리포트 설계 시리즈 7/8운영 콘솔에서 데이터베이스를 쓴다고 해서 모든 쿼리가 같은 성격은 아니다.화면 조회를 위한 쿼리와 리포트 생성을 위한 쿼리는 다르다.운영 데이터와 리포트 데이터도 다르다.이 차이를 무시하면 대시보드가 느려지거나, 리포트 생성이 운영 DB에 부담을 주거나, 정산성 데이터의 기준이 흔들릴 수 있다.운영 화면의 데이터운영 화면의 데이터는 빠르게 보여주는 것이 중요하다.예를 들어:오늘의 요약최근 주문상태별 건수점포 또는 사용자 목록간단한 필터 조회이런 데이터는 사용자가 화면에서 반복적으로 본다.응답 시간이 중요하고, 쿼리는 자주 실행된다.따라서 connection pool, index, pagination, cache 같은 요소가 중요하다.리포트 데이터리포트 데이터는 성격이 다..

Volume 01. 나와 아이의 내면늦은 밤, 학원 공부를 마치고 돌아온 아들이 방으로 들어가고 난 후, 거실에는 아내와 나 둘만 남았다.식탁 등 아래에서 차를 마시던 아내가 문득 한숨을 내쉬며 조심스럽게 속마음을 털어놓았다.“여보, 요즘 OO이가 학교에서 친구들이랑 잘 지내는지 모르겠어. 집에 와서 물어봐도 그냥 다 똑같다고만 하잖아. 우리 애 혹시 겉도는 건 아닐까 걱정돼.”아내의 걱정은 깊고 애틋했다. 하지만 가만히 듣고 있다 보니 한 가지 사실이 눈에 들어왔다.아내는 지금 자신이 여자아이로 학창 시절을 지나오며 익숙하게 배웠던 관계의 기준으로 중학생 아들의 세상을 바라보고 있었다. 아주 가깝고 촘촘하게 마음을 나누어야 안전하고 괜찮은 친구 관계라고 여기는 엄마의 가이드라인이었다.그 이야기를 들으며..

데이터와 리포트 설계 시리즈 6/8운영 콘솔에는 통계 화면이 자주 등장한다.월별 매출, 주문 수, 사용자 수, 처리 건수, 리포트 합계 같은 지표를 보여준다.처음에는 화면이 열릴 때마다 원천 데이터를 조회해서 실시간 집계하면 된다고 생각할 수 있다.하지만 운영 통계는 매번 실시간으로 계산하는 것이 항상 좋은 선택은 아니다.반복 조회되는 통계는 미리 계산해두는 편이 더 안정적일 수 있다.문제 상황운영자는 대시보드에서 월별 통계를 자주 확인한다.통계는 여러 원천 데이터를 조합해서 계산해야 한다.데이터 범위가 넓거나 쿼리가 복잡하면 매번 화면 조회 시 집계하는 방식은 부담이 된다.특히 다음 문제가 생길 수 있다.대시보드 로딩이 느려진다.DB에 반복적인 집계 부하가 생긴다.같은 월 통계를 여러 사용자가 반복 조..

Volume 01. 나와 아이의 내면저녁을 먹고 온 가족이 거실에 모여 앉은 시간, 우리 집의 풍경은 그리 여유롭지 못하다.아직 아이만의 방이 따로 없다 보니 거실은 온 가족의 쉼터이자 아이의 공부방이 된다. 조그만 상 앞에 앉아 노트북으로 챗GPT 창을 띄워놓고 있는 아이. 학교에서 내어준 수행평가 과제를 채우기 위해서다.하지만 곁에서 아이가 자판을 두드리는 모습을 가만히 보고 있으면 마음이 복잡해진다. 질문을 던지고 답변을 받아 적는 아이의 손길에 아무런 생기가 없기 때문이다.당장 제출해야 할 숙제 앞에서 마음이 급해진 탓인지, 아이의 질문은 점점 짧고 기능적으로 변해갔다. 화면에 뜨는 텍스트를 자기 말로 다시 생각해보기보다 그대로 옮겨 적는 모습은, 기술을 영리하게 활용한다기보다 숙제의 빈칸을 서둘..

데이터와 리포트 설계 시리즈 5/8비동기 리포트 생성에서는 사용자가 작업 상태를 알아야 한다.가장 단순한 방법은 polling이다.프론트엔드가 일정 간격으로 상태 API를 호출한다.GET /api/jobs/{jobId}완료되면 다운로드 URL을 보여준다.Polling은 오래된 방식처럼 보일 수 있다. WebSocket이나 Server-Sent Events가 더 세련되어 보일 수도 있다.하지만 내부 운영 도구에서는 polling이 충분히 좋은 선택일 때가 많다.polling이란 무엇인가Polling은 클라이언트가 주기적으로 서버에 상태를 묻는 방식이다.예를 들어 2초마다 job 상태를 확인한다.0초: IN_PROGRESS2초: IN_PROGRESS4초: IN_PROGRESS6초: COMPLETE구현은 단순..

데이터와 리포트 설계 시리즈 4/8리포트 생성 작업을 job으로 모델링했다면 다음 질문이 생긴다.누가 실제 파일을 만들 것인가?API 요청을 받은 서버가 직접 만들 수도 있지만, 오래 걸리는 작업은 worker로 분리하는 편이 좋다.API는 작업을 접수하고, worker는 파일을 만든다. 결과 파일은 object storage에 저장한다.API와 worker를 나누는 이유API의 역할은 사용자의 요청을 받는 것이다.worker의 역할은 시간이 오래 걸리는 처리를 수행하는 것이다.둘을 나누면 장점이 있다.API 응답이 빨라진다.무거운 파일 생성이 일반 요청을 막지 않는다.worker 실패를 job 상태로 기록할 수 있다.파일 생성 작업의 timeout과 메모리를 별도로 조정할 수 있다.재시도와 모니터링이 ..

Volume 01. 나와 아이의 내면밤 10시 반, 셔틀버스에서 내린 아이가 지친 발걸음으로 들어선다.하지만 집은 곧바로 쉼터가 되지 못한다. 가방을 내려놓기 무섭게 아이는 다시 책상 앞에 앉는다. 학원 숙제와 학교 공부가 기다리고 있고, 그 옆에는 아내가 자리를 잡고 앉는다.두 사람 사이에는 이내 날카로운 말들이 오고 간다. 피곤함에 겨워 조는 아이를 보며, 하루 종일 일과 가사에 지친 아내의 목소리도 함께 높아진다.“집중 안 해? 아까 오자마자 게임을 하더니, 끝내놓고 했어야지.”아이는 짜증이 섞인 눈으로 모니터를 노려본다. 수행평가를 붙잡고 끙끙대는 아이와 이미 방전되어 버린 엄마 사이에 깊은 감정의 골이 서서히 드러난다. 밤이 깊어갈수록 방 안은 피로와 원망으로 무겁게 가라앉는다.그렇게 밤 12시..

데이터와 리포트 설계 시리즈 3/8오래 걸리는 리포트 생성을 비동기로 처리하려면 작업 상태를 저장할 곳이 필요하다.메모리에 상태를 들고 있으면 안 된다.서버가 재시작될 수 있고, Lambda는 실행 환경이 유지된다는 보장이 없으며, 운영자는 나중에 작업 이력을 확인해야 한다.그래서 job table이 필요하다.job table의 역할job table은 리포트 생성 작업의 기록장이다.사용자가 리포트를 요청하면 먼저 job row를 만든다.worker는 이 job을 처리하면서 상태를 갱신한다.프론트엔드는 job id로 상태를 조회한다.job table이 있으면 작업은 추적 가능한 단위가 된다.기본 상태 모델처음에는 단순한 상태만으로도 충분하다.PENDINGIN_PROGRESSCOMPLETEFAILED각 상태..

데이터와 리포트 설계 시리즈 2/8처음 리포트 다운로드 기능을 만들 때 가장 쉬운 방식은 동기 API다.사용자가 버튼을 누르면 API가 데이터를 조회하고, 엑셀을 만들고, 바로 파일을 응답한다.작은 데이터라면 이 방식도 괜찮다.하지만 데이터 범위가 넓어지고 생성 시간이 길어지면 동기 API 방식은 여러 문제를 만든다.가장 단순한 구조동기 방식은 이렇게 생겼다.사용자 클릭-> POST /api/reports-> DB 조회-> 엑셀 생성-> 파일 응답구현은 단순하다.프론트엔드도 요청 하나만 보내면 된다.서버도 파일을 만들어 바로 응답하면 된다.하지만 이 구조는 "작업이 짧게 끝난다"는 전제를 가진다.그 전제가 깨지면 문제가 시작된다.브라우저 대기 UX동기 API는 사용자가 요청이 끝날 때까지 기다려야 한다...

데이터와 리포트 설계 시리즈 1/8운영 콘솔에서 리포트 기능은 단순해 보인다.사용자는 조건을 선택하고 버튼을 누른다. 잠시 뒤 엑셀 파일을 내려받는다.겉으로 보면 "조회해서 파일로 만들면 되는 기능"처럼 보인다.하지만 실제로 만들어보면 리포트 기능은 단순 조회 API와 다르다. 데이터 조회, 집계, 파일 생성, 작업 상태, 저장, 다운로드, 실패 처리까지 함께 설계해야 한다.버튼 하나 뒤에 있는 일들사용자는 하나의 버튼을 본다.[리포트 다운로드]하지만 시스템 내부에서는 여러 단계가 이어진다.요청 파라미터 검증-> 작업 생성-> 데이터 조회-> 집계 또는 가공-> 엑셀 파일 생성-> 파일 저장-> 작업 상태 갱신-> 다운로드 URL 제공이 중 하나라도 실패하면 사용자는 파일을 받지 못한다.그래서 리포트 기..